## 3 Background
### Proposed Robust and Tamper-Resistant Authentication Framework  
In most of the IoT applications, CoAP is utilized as an application layer protocol. CoAP does not provide any security for data transmission between two constrained nodes. The CoAP server and client communication can be secured with DTLS, however, as mentioned in the preceding section, DTLS is not suitable for IoT constrained devices and it causes computational overhead and complexity on constrained nodes. Therefore, ro  
Figure 4: CoAP architecture. Figure 3: CoAP packet format. bust and tamper-resistant authentication framework between CoAP server and client is proposed to ensure data integrity and authenticity. The proposed CSFSA framework is computationally efficient and is resilient against various cyber security attacks i.e., replay attacks, DoS attacks and resource exhaustion. It avoids the need to develop the additional security protocol. Like HTTP, CoAP is based on client/server model architecture to establish connection when client sends request to server and server sends response to the client. For observation of resources, all the server and clients used the CoAP protocol. In order to observe resource, the server first authenticates the client identity. If the client is authentic, the server will establish session with that client and will respond to the client. On the client side while receiving response message from server, the client checks the server authenticity. Once both client and server are authenticated, they proceed and exchange data between them. The proposed CSFSA framework uses the AES encryption techniques and hash based message authentication code algorithm HMAC-SHA-224 by ensuring message integrity and authenticity. Before starting communication, the CoAP client and server first agree on sequence ID and pre-shared secret key \(\mathrm{K_{pre}}\). The server stores each device sequence ID and \(\mathrm{K_{pre}}\) in its own repository for device identification and to fetch associated \(\mathrm{K_{pre}}\) for that device. Now whenever client wants to start communication with server, it will send request to server, after receiving request from server, server will check client authenticity first. Figure 5 shows the proposed CSFSA authentication architecture. On the client side, the server verifies and authenticate the client identity. The client first generates timestamp T1 in order to prevent from replay attacks and calculates hash value of \(\mathrm{K_{pre}}\) and T1 using HMAC-SHA-224 hash algorithm. This hash value is then concatenated with the device sequence ID and T1 as follow:  
\[\mathrm{H_{C}}=\mathrm{HMAC}\ (\mathrm{K_{pre}},\mathrm{T1}) \tag{1}\]  
\[\mathrm{C_{MP}}=\mathrm{ID}\ |\ \mathrm{T1}\ |\ \mathrm{H_{C}} \tag{2}\]  
where \(\mathrm{C_{MP}}\) is the client message payload. The client then sends its final message \(\mathrm{C_{MP}}\) to the server. On the server side, while receiving message from client, the server checks client message authenticity. The server first checks the sequence ID in its repository, if it's not present in repository, the connection will be then rejected, otherwise server will fetch associated \(\mathrm{K_{pre}}\) for that device in its repository. The server then generates its own hash value of \(\mathrm{K_{pre}}\) and T1 as follow:  
\[\mathrm{H_{S}}=\mathrm{HMAC}\ (\mathrm{K_{pre}},\mathrm{T1}) \tag{3}\]  
where \(\mathrm{H_{S}}\) is the server hash value. The server compares its own generated hash value \(\mathrm{H_{S}}\) with the received hash value \(\mathrm{H_{C}}\) from the client. If both hash values are not same, the server then rejects the client request. If both values are same, then the server authenticates client for services. Once client is authenticated by server, the server creates reply message for the message received from authentic client. Therefore, the server generates timestamp T2 and session key KS.