Two-phase Authentication Protocol for Wireless Sensor Networks in Distributed IoT Applications

Wireless Sensor Network (WSN) is a key technological building block of IoT, which is considered the future evolution of the Internet.

 

Centralized Approach VS. Distributed Approach

1. Centralized Networks: there is little or no support to access the data sensing network devices directly.
1. Centralized WSN, data from the sensor nodes are transmitted to a single central location, which process, combine, and provide information acquisition for customers.
2. Due to the high data availability and massive network size, processing of data on a single location might be inefficient, processing of data on a single location might be inefficient, congested and undertaking a high risk at single entity failure.
2. Distributed networks: allowing the end-users and other network entities to obtain raw data straightway from the sensor nodes
1. The sensor nodes can retrieve, process and provide data for other entities and end-users.
2. Distributed architecture supports the IoT network applications by providing services at local level, and collaborating with all the network devices and users to achieve common goals
3. Due the network heterogeneity and device mobility, there can be many security threats and issues are encountering with distributed IoT

 

Design and evaluation of a two-phase authentication scheme for WSNs in distributed IoT applications

 -> the edge nodes and end-users exploit implicit certificates for mutual authentication, the protocol is lightweight and it supports the heterogeneity of the entities.

 

Registration Phase: to obtain security credentials from a trusted party as described below

1. Figure 1 network edge device and end-users request security credentials and certificates from the certificate authority
2. CA issues implicit certificates(절대적 증명)
3. stages
1. The protocol starts the handshaking with a Requestor Hello message, node identity(U), and cipher suites
2. CA  uses node or user identities to verify the legitimacy of the certificate requestors
3. CA agrees to one cipher suite combination from the received options, and sends CA Hello message with its public key
4. Upon receiving CA Hello message, the requestor generates a certificate request EC point and a true nonce, calculates their Message Authentication Code value and sends Certificate Request message to CA
5. CA first verifies the MAC value to identify the integrity of the request, and then calculates the implicit certificate and private key construction value
6. CA sends Certificate message including the two values followed by a nonce and MAC value.
7. Upon receiving Certificate and after verifying the MAC value, the requestor  computes its own private and public keys
8. The Finished message contains an encrypted message digest of previous handshake messages using the requestor's public key
9. CA answers with the Finished message to complete the handshake of the registration phase

 

Authentication Phase: to start mutually trusted communication between two network entities, using the obtained security credentials.

1. In order to establish authenticated communication, the edge nodes and end-users should possess implicit certificates for particular cipher suites
2. stages
1. The client sends the Client Hello message to the server followed by cipher suite options and its identity.
1. The client only sends the cipher suites, which its implicit certificates are composed of.
2. If the server possesses certificates, which matches the given list of cipher suites, it agrees to one cipher suite and replies with the Server Hello message and its identity.
1. Otherwise, the server abolishes the handshake by sending the End message.
3. Upon receiving the Server Hello message, the rest of the protocol can be further proceeded
4. The Client sends its certificate accompanied with a random cryptographic nonce and the MAC value
5. If the MAC verification is successful, the server calculates the client's public key, using the received certificate and CA's public key.
6. The server uses its private key and client's public key
7. The server sends its certificate, nonce, and MAC value
8. The client verifies MAC, computes the public key of the server, and derives the common key using own private key and the public key of the server
9. Exchanging the Finished messages concludes the handshake