11 Authentication for IOT
Internet of Things (IoT) is a terminology used for a network of low-cost and low-power devices used for sensing and actuating in day to day life. A heterogeneous system combining sensors and actuators with general purpose computing elements consisting of hundreds to thousands of nodes. These devices are deployed globally and can collect various data and actuate or perform specific actions automatically with minimal human interaction.
IoT devices can be deployed to create smart cities, smart grids, smart logistics, etc. IoT devices are also termed as constrained devices because they have limited computational capacity, lifetime, throughput, etc. Sensor nodes form multi-hop wireless network with aggregation capability and sensors communicate with the nearest base station.
IoT brings with itself unlimited opportunities as well as tremendous challenges. A main challenge is different devices utilize different protocols and standards in their network and these networks need to communicate with each other securely as well as efficiently. From a security point of view, attackers find it convenient to exploit constrained devices and use them to mount DDoS attacks. Standard network security protocols cannot be used for IoT because they need high computational complexity. So, there is a requirement of light weight security protocols for IoT environment.
No standards for IoT authentication schemes have been proposed so far. Various schemes are proposed based on the centralized servers for mutual authentication using different primitives. The authentication scheme proposed by Amin et al. is described in some detail highlighting the kind of cryptographic operations .
Amin et al. proposed light weight authentication method in distributed cloud environment . Their scheme is based on a central control server for several cloud servers providing control sequence for authentication in a distributed environment as shown in Figure 6. This scheme makes use of the smart card and based on hash function .
Both the cloud server and the client have to perform registration as shown in Figure 7 and Figure 8. The cloud server sends the server identity, ServID and the random “d”. The Control Server (CS) uses hash function h() and uses its own secret “y” to compute BSm and the cloud server stores BSm and “d”.
The user registration uses the password Pi, random b1 and b2, computes Ai and PIDi and sends it to the CS. The CS uses its secret x to compute Di and sends ⟨ci, Di, Ei⟩. The smart card computes DP=h(UIDi||pi) xor b2 saves ⟨ci, Ei, bb, DP⟩. The user sends IDi and the password Pi the smart card and it computes c’i and if tallies with ci, proceed to choose a random 128-bit “Ni” and computes ⟨Gi, Fi, Zi, PIDi, TSi⟩ to the server where TSi is the time stamp. The server chooses random Nm and computes Jm=BSm xor Nm and “km=h(Nm||BSm||Gi||TSm)” and sends ⟨Jm, km, PSIDm, Gi, Fi, Zi, PIDi, TSi, TSm⟩ to the central server. The central server computes D’i as it knows its own secret “x”. Next “D’i” is computed and “N’i” recovered to find SID’m. The final “G’i” is obtained by hashing the concatenated messages. If G’i matches Gi, the central server finds N’m and computes “k’m”. If “km” matches “k’m” the authentication is considered successful. It next proceeds to computing session keys to be used for the session.
Amin et al. show that their scheme provides user anonymity, session key agreement, mutual authentication as well as early wrong password detection. They also show that their scheme is secure against off-line password guessing attack, insider attack, user impersonation attack, session key disclosure attack and replay attack. This scheme uses a centralized control server for the flow of authentication data and provides mutual authentication between all the entities. As we can see mutual authentication occurs between the user, the cloud and the control server, it is evident that the chances of a DoS or DDoS attack increases significantly. In Amin et al.’s scheme, if the centralized control server failure is a single point of failure. However, Amin et al. provides no genuine countermeasure for avoiding a DoS attack.
There are other authentication schemes making use of centralized servers for authentication. Huang et al. describe an authentication method using one-way accumulator, which is a one-way hash function that has quasi-communicative property and uses IoT nodes and a proxy server . Another authentication using an elegant variation of Lamport’s One-Time-Password (OTP) and identity based elliptic curve cryptography is given in .
12 Authentication in Unique Identification Authority of India (UIDAI)
UIDAI has been created with the objective to issue Unique Identification numbers (UID), named as “Aadhaar”, to all residents of India that is (a) robust enough to eliminate duplicate and fake identities, and (b) can be verified and authenticated in an easy, cost-effective way. UIDAI is responsible for Aadhaar enrolment and authentication and also required to ensure the security of identity information and authentication records of individuals. The unique Aadhaar identity enables the Government of India to directly reach residents of the country in delivery of various subsidies, benefits and services by using the resident’s Aadhaar number only.
The UIDAI has set up a scalable ecosystem for the purpose of instant authentication of residents. The Aadhaar authentication ecosystem is capable of handling tens of millions of authentications on a daily basis, and can be scaled up further as per the demand. The UIDAI has appointed a number of Authentication Service Agencies (ASAs) and Authentication User Agencies (AUAs) from various Government and non-Government organizations. AUA is an organization or an entity using Aadhaar authentication as part of its applications to provide services to Aadhaar holders. All AUAs (Authentication User Agencies) must be registered within Aadhaar authentication server to perform secure authentication. ASA is an organization or an entity providing connectivity using private secure network to UIDAI’s data centers for transmitting authentication requests from various AUAs.
UIDAI defines “Aadhaar Authentication” as a process by which the Aadhaar number along with demographic information (such as name, date of birth, gender etc.) or biometric information (Fingerprint or Iris) of an individual is submitted to UIDAI’s Central Identities Data Repository (CIDR) for its verification and UIDAI verifies the correctness of the details submitted, or the lack thereof, on the basis of information available with it.
Aadhaar authentication service is exposed as stateless service over HTTPS. Usage of open data format in XML and widely used protocol such as HTTPS allows easy adoption and deployment of Aadhaar authentication. It is mandated that user’s identity data to be encrypted at the time of capture and must not be stored for security reasons. It is essential that ASA and AUA should maintain audit records of authentication transactions and should validate TLS certificates against revocation list online. Aadhaar authentication uses XML as the data format for input and output. UIDAI requires AUA and ASA should digital sign authentication request messages in XML format. This assures message security and integrity. AUA can digitally sign after forming the input XML. ASA can digitally sign the request XML if it is a domain-specific aggregator and forms the request XML on behalf of the AUA.
Aadhaar authentication supports authentication using multiple factors. These factors include demographic data, biometric data, PIN, OTP, possession of mobile, or combinations thereof. Adding multiple factors increases the strength of authentication. Applications using Aadhaar authentication need to choose appropriate authentication factors based on risk level of the transaction. AUAs can add their own factors to strengthen authentication.
A typical authentication flow and is a case of an operator assisted transaction at a PoS terminal:
a. Aadhaar holder provides Aadhaar Number, necessary demographic and biometric details to the terminal device belonging to the AUA.
b. The device packages these input parameters as a Personal Identity Data (PID) block, encrypts it, and sends it to AUA server.
c. AUA server, after validation, adds necessary headers such as AUA specific wrapper XML with signature and passes the request through ASA server to UIDAI CIDR.
d. Aadhaar authentication server returns a “yes/no” based on the match of the input parameters.
e. Based on the response from the Aadhaar authentication server, AUA conducts the transaction.