Paresh Borkar

Paresh Borkar

Paresh Borkar is Principal Architect at GS Lab.

Posted by on in Thoughts

Gartner’s 10 strategic predictions for 2017 and beyond, makes me unwillingly delve into imagining what the future holds.

As John leaves work and heads to the building lobby, his car is already waiting for him. Self-driving cars are almost mainstream. He just indicates to his car, “Drive me home”. After arriving home, which is already cooled/heated to his preference, he picks up the freshly brewed pot of coffee to pour himself a cup. As he walks into the living room, he says “Play HBO” and the TV turns on with HBO channel playing. Deeply engrossed in the movie, John is suddenly reminded by his virtual assistant (AWS Echo) reminding him about a dinner party scheduled for later in the evening. He tells his virtual assistant to buy some flowers and a good bottle of wine. Using virtual reality, he is immediately present in the virtual mall and able to hand pick these items. As he does a virtual checkout, these selected items are being delivered by a drone to his home in another half an hour and John is all set for the party.

In some time technology will make all of this a reality. Some of it is already a reality though. Let us now look at the technology underlying all of this. At the fundamental level we have Internet of Everything. All devices are connected to the grid all the time. This allowed John’s car to estimate and share his arrival time with devices at home. This in turn allowed his air conditioner to set the appropriate temperature level and coffee maker to brew his preferred coffee beforehand. Almost all the interactions are voice based rather than some clicks on a screen. Devices with audio input will be trained to be activated only on specific person’s voice (biometric audio-based authentication is implicit). Even the acting of purchasing something is not happening on the mobile application anymore. Most of the shopping will be using virtual reality channel and the experience will be most gratifying. No more running to the local store for last minute errands. Deliveries happen by drone in the most efficient manner possible.

Virtual stores of the future will have no physical stores nor warehouses, instead they will rely on JIT inventory from the suppliers directly. Goods will be shipped from the supplier directly to the consumers based on orders received by the virtual stores. The virtual store will completely change shopping experience for its consumers using virtual reality. It will allow consumers to touch and feel objects prior to purchasing theses. Credit transactions will happen transparently in the background based on bio-metric approval from the consumer. The virtual reality googles will perform an IRIS scan to authenticate the consumer and digitally sign the transaction and approve it. Block chain will be used by merchants to maintain these financial transactions in an authentic, non-repudiate-able fashion.

All devices in the home will be connected and share analytics metrics with manufacturers. For example – the air-conditioning/heating unit will share detailed metrics on performance of the compressor, power consumption trends, etc. with its manufacturer. This allows the manufacturer to leverage this data to perform analytics to predict outages and faults well in advance. This in turn ensures that the service technician (possibly a robot) does a home visit before the device breaks down. Preventive maintenance will help continuity and prevent outages. Consumers alongside businesses will help benefit tremendously from this.

Overall life style and experience will change dramatically. People will leverage fitness bands/trackers and share data with their healthcare provider as well as Health Insurance Company. This will enable the healthcare provider to proactively track health of an individual (again through analytics) to detect issues before these arise. Also, insurance companies will base the premium based on the healthiness level of an individual alongside life style patterns. The latter will include diet / food habits (from your virtual store grocery shopping), exercise regime (fitness tracker), etc.

With everything integrated – security is the key. With IoT devices, it is imperative that security is baked in at multiple levels.





Let us look at these in more detail below:


Device security – The device needs to protect itself from attackers and hackers. This includes (but is not limited) to the following: hardening the device at OS level, securing confidential information on the device (data at rest on the device), firewalling the device, etc.


Authentication – Each entity (device, cloud service, edge node/gateway, etc.) needs to authenticate itself to the corresponding entity. If there are default username/passwords in the device, then it needs to enforce password reset on initial power-on (along with factory reset option). Ideally the device should not use static password for authentication. In our earlier post on OTP – based device authentication for improved security we have discussed a novel approach which helps address the challenges faced by IOT device manufacturers today.


You can read more about OTP – based device authentication for improved security by clicking here.


Network communication channel security – Today there are various communication channels at play, for example – devices communicating with their respective cloud service providers, devices communicating with fog/edge computing services/devices, devices interacting with other devices, etc. It is important that each communication channel is secured and there exists trust between the communicating endpoints. The channel can be secured using TLS as appropriate.


Cloud service security – The cloud service provides the backbone for services provided. The attack vector surface needs to be minimal and hardened / firewalled for DDoS attacks. Data from the devices is collected at the cloud service end and needs to be secured (data at rest). This data need not be visible to the cloud service provider as well (depending on the nature of the data and service provided). Provider needs to ensure that appropriate backup and disaster recovery plans are in place. Also, the provider needs to present their business continuity plan to its subscribers. Cloud Security Alliance (CSA) provides good guidance to cloud service providers.


Privacy – This relates more to data sharing across disparate service providers. With IoT, devices will end-up communicating with devices / services from other providers. How much information can be shared across service providers with user content needs to be carved out explicitly? Service providers will need to incentivize users to allow sharing information with other providers. The user needs to benefit from the sharing eventually to allow it.


To summarize security is a key aspect for success of IoT.


Tagged in: IoT security
Last modified on
Hits: 318
Rate this blog entry:

The recent massive distributed denial of service (DDoS) attack on 21st October 2016 affected numerous cloud service providers (Amazon, Twitter, GitHub, Netflix, etc.). It is interesting to note that this attack leveraged hundreds of thousands of internet connected consumer devices (aka IOT devices) which were infected with malware called Mirai. Who would have suspected that the attackers involved were essentially consumer devices such as cameras and DVRs?

A Chinese electronics component manufacturer (Hangzhou Xiongmai Technology) admitted that its hacked products were behind the attack (reference: ComputerWorld). Our observation is that the security vulnerabilities involving weak default passwords in vendor’s products were partly to blame. These vulnerable devices were first infected with Mirai botnet and subsequently these Mirai infected devices launched an assault to disrupt access to popular websites by flooding Dyn, a DNS service provider, with an overwhelming amount of internet traffic. Mirai botnet is capable of launching multiple types of DDoS attacks, including TCP SYN-flooding, UDP flooding, DNS attack, etc. Dyn mentioned in a statement – “we observed 10s of millions of discrete IP addresses associated with the Mirai botnet that were part of the attack” – such is the sheer volume of the attack by leveraging millions of existing IOT devices out there.

Subsequently Xiongmai shared that it had already patched the flaws in its products in September 2015, which ensures that the customers have to change the default username and password when used for the first time. However, products running older versions of the firmware are still vulnerable.

This attack reveals several fundamental problems with IOT devices in the way things stand today:

  • Default username and passwords
  • Easily hackable customer-chosen easy-to-remember (read as “weak”) passwords
  • Challenges with over-the-air (OTA) updates etc.

The first two problems are age old issues and it is surprising to see these come up with newer technologies involving IOT devices as well. Vendors have still not moved away from these traditional techniques of default username and passwords, nor have customers adopted strong passwords. Probably it is time, we simply accept the latter will not happen and remove the onus from customer having to set strong passwords (it is just not going to happen!).

One-time passwords (OTP) can be quite helpful here. One-time password, as the name suggests, is a password that is valid for only one login session. It is a system generated password which is essentially not vulnerable to replay attacks. There are two relevant standards for OTP – HOTP [HMAC-based One-Time Password] and TOTP [Time-based One-Time Password]. Both standards require a shared secret between the device and authentication system along with a moving factor, which is either counter-based (HOTP) or time-based (TOTP).

GS Lab’s OTP-based device authentication system presents a novel approach which helps address the challenges faced by IOT device manufacturers today. It provides unstructured device registry which is flexible enough to include information on various types of devices and an authentication sub-system which caters to authenticating IOT devices tracked in the device registry via OTP. The authentication sub-system is built on top of existing OTP standards (HOTP and TOTP) and helps alleviate the need for static (presumably weak) passwords in IOT devices. It provides support for MQTT and REST protocols which are quite prevalent in the IOT space. More support for additional protocols (like CoAP, etc.) is already planned and in the works. OTP-based device authentication system is built on top of our open source OTP Manager library.

Here are some of the advantages of using GS Lab’s OTP-based device authentication system:

  • Strong passwords – system generated based on shared secret key
  • Not vulnerable to replay attacks – passwords are for one-time use only
  • Freedom from static user-defined passwords
  • Standards based solution – HOTP and TOTP standards
  • Relevant for resource constrained devices – crypto algorithms used by HOTP and TOTP standards work with devices with limited CPU, memory capabilities.
  • Ability to identify malicious devices – rogue devices can be identified using HOTP counter value
  • Provides device registry for simplified management



Last modified on
Hits: 484
Rate this blog entry:

Posted by on in Technology


There has been much discussion around various authentication methods, which range from username-password to leveraging OTPs, hardware tokens or biometrics, to client certificates etc. Each of these methods provide varying level of confidence in the overall authentication process. This makes one wonder which authentication method is best for a particular organization’s needs. The fundamental question is - is there is any one ‘silver bullet’ authentication method? The answer is ‘no’. You may need to decide which one to use depending on the environment and context.

Understanding the need

As an example – let’s compare an employee who is logged on to your corporate intranet (probably using AD domain authentication), requesting access to an intranet application, with someone from outside. In the latter case, you would want to request for stronger authentication to ascertain the identity of the person. Here you may choose to ask for OTP in the authentication process as an additional factor. This is a good example of leveraging context to determine the type of authentication required.

Let us consider another scenario where someone is trying to access a privileged application outside of business hours or from an unknown IP address. In such a case, again you would want to request stronger authentication depending on the nature of the privileged application.

Understanding the authentication context

Context is essentially the surrounding detail about the environment, which can be determined passively (i.e. without need for user intervention). Some typical examples of context include:

  • Location context - Using geo-location to determine where the user is logging in from.
  • Known machine - Has the user logged in using this machine before? This is typically done by computing something known as a device fingerprint and tracking it.
  • Time of the day - Is the user logging in at an odd time of the day or night, which does not match with the users' typical login patterns?
  • IP address – Has the user logged in from the same IP address before?

If we look at the above pieces of information which form the context, then we realize that leveraging context-aware authentication essentially means ‘compare the current context with what is considered normal for that user’. Thus, we have to first establish what can be considered normal behaviour for any given user. This is where analytics come in to play. Using intelligent analytics, we can identify typical normal patterns for users and this system keeps on learning newer patterns or registers outliers. Based on these learnings, it can request for step-up authentication whenever required.

How does this work?

The solution closely follows and tracks user activity to determine normal patterns (using analytics). For every new authentication attempt, the system compares the authentication context with what is considered normal for given user. It identifies the variance from the normal level, and translates that variance to a risk score. Depending on the risk score identifies, it determines the need for step-up authentication along with the type of step-up required.

For example – a user’s typical pattern is to login from North America during business hours. Now this user tries to login from Asia Pacific region from a known machine, then she/he will be prompted for OTP as well. If this user tried to login from Asia Pacific region from an unknown machine, then she/he could be prompted for biometric authentication as well.

How does this help?

The end user is not prompted for strong authentication unless there is an explicit need for it. This helps provide a better user experience while doing the delicate balancing act of providing strong authentication whenever required. Best of both worlds!

Last modified on
Hits: 1171
Rate this blog entry:

Posted by on in Technology

Passwords are a necessary evil, and are everywhere. Many organizations still rely completely on passwords for authentication purposes. While most of us are well aware of the limitations of passwords, we rarely move beyond them. How many of us use Two Factor Authentication (2FA) provided by cloud service providers like Google for all the services we use? Very few if any. In this blog post, I hope to steer you towards stronger authentication measures which are cost effective and reduce your reliance on passwords.

What options are available to strengthen security and reduce the dependence on passwords? There are several and before we dive into these, let us understand how different factors are used. There are essentially three factors that can be used in the authentication process:

  • What the user knows: Passwords, PINs, etc.
  • What the user has: Something that the user possesses like a hardware or software token.
  • What the user is: Something intrinsic to the user such as a biometric (finger print, retina scan, etc).

Additional factors can be brought in to strengthen the authentication process. For example: a banking application uses login and password for authentication. But when a high value transaction is to be carried out, then the user needs to enter a One Time Password (OTP). The OTP can be generated on the users mobile device or it can be sent to the device. Essentially, the mobile device is something that the user has in her possession.

OTP has several advantages:

  • standard based support (HOTP - RFC 4226, TOTP - RFC 6238, OATH)
  • as the name suggests these values are valid for one time use only.
  • it is very difficult to predict the next OTP value
  • OTP is generated or delivered out of band.

Most organizations that use this method require the OTP to be delivered using SMS or text messaging. However, this implies that the user (receiver) needs to bear charges associated with text messaging and needs to be in a mobile coverage area. Also, SMS based delivery is not secure.

A good alternative is to use standard based OTP generation on the smartmobile device instead of a delivery based approach. OTP standards like HOTP (HMAC-based One-Time Password Algorithm) and TOTP (Time-based One-Time Password Algorithm) facilitate an OTP generation based model on mobile devices. Both these standards are quite similar, in that they require a shared secret that is shared between the mobile device and the application utilizing OTP services. The only difference is that HOTP uses a counter based synchronization mechanism whereas TOTP is time-based. These standards are blessed by the Internet Engineering Task Force (IETF) and offer dependability.

There are free mobile applications available which take care of locally generating the OTP. Google Authenticator is a good example and supports most mobile flavors from iOS, Android, BlackBerry, etc. I would recommend a free application like Google Authenticator, as it is already leveraged by industry leaders like Google, Amazon Web Services (AWS), etc. The setup process for Google Authenticator is simple and user-friendly.

The server application leveraging OTP will need to be enhanced to add the required support. GS Lab has an OTP library which is standards based and supports both HOTP and TOTP standards. This library is currently geared for Java/ J2EE applications and provides a means to quickly enable your application to support strong two factor authentication. The OTP library works with the free, off-the-shelf Google Authenticator mobile application, which simplifies the deployment process considerably for your users. If you are interested to know more about our OTP library, do drop us a line at

In future blog posts, we will do a deep dive on OTP standards and more interesting stuff around context-aware authentication and other concepts.

Last modified on
Hits: 1817
Rate this blog entry:
Very low screen size go to mobile site instead

Click Here