Keywords

1 Introduction

CCN and its importance: Since 2009, content-centric network (CCN) is envisaged as a future Internet architecture to cope up with the ever-increasing need for information exchange in current technological era. CCN is designed to leverage scalable content distribution over the Internet. In CCN, information/content gets more importance than the host where it is available and security is provided separately on the piece of content [1,2,3,4]. CCN uses human-readable hierarchical content naming approach to uniquely identify any content over the network [3]. Thus, CCN replaces the IP-based routing with name-based routing and uses content caching mechanism in intermediate routers to reduce network latency time. CCN router uses a limited buffer called content source (CS) to cache popular content for future use. Routers also maintain a forwarding information base (FIB) and a pending Interest table (PIT) to facilitate name-based routing. The major entities of CCN are content provider, publisher, consumer, and network router. CCN consumer sends Interest packet as a request for content. Any CCN router which receives the Interest checks the availability of the requested content in its CS. If it is available, the router consumes the Interest and sends back the requested content to the respective consumer. Otherwise, the Interest is forwarded to the content provider. Content provider supplies the content to its interface publisher for publishing in CCN. Finally, the requested content is forwarded to the requesting consumer following the reverse Interest path. As CCN enhances smooth delivery of content over the Internet, it can easily support the huge need for data/content exchange in Internet of things (IoT) framework.

IoT and its importance: With the advancement in consumer electronics, wireless communication, and intelligent sensors, IoT is becoming a reality where several heterogeneous things are interconnected through the Internet for information exchange and operated remotely without any human intervention. One of the most significant challenges in IoT framework is security which includes infrastructure-level security, application-level security, general system security, and communication security [5,6,7,8,9,10,11]. Now, a brief discussion on IoT communication framework is given here. IoT framework involves three significant entities, namely IoT devices, gateway server, and IoT end users. IoT device includes intelligent sensor devices and actuators which are deployed in the field such as a smart factory, smart home, hospital (in case of smart health care). In IoT network, intelligent sensor devices gather data from the environment and feed them to the gateway server. IoT gateway server manages security of the data communication and gives access of the gathered data to the authorized users who in return may give some commands to the IoT actuators via gateway server.

Background study: CCN as a future Internet architecture is ideally designed to address the emerging technology like IoT and its challenges at its design level [5,6,7,8,9,10,11]. In this regard, different researchers [6,7,8,9,10] have focused on IoT as a challenging Internet technology that can be significantly benefitted from CCN. Later, Suarez et al. [11] proposed an IoT management architecture based on information-centric network. Though the authors have addressed the overall IoT management architecture and its different aspects, the paper [11] lacks the cryptographic details of security measures used. In this paper, we have outlined a CCN-based IoT framework and designed a detailed communication security architecture using ECC [12,13,14,15,16].

Our contribution: In this paper, we have addressed an IoT communication framework which operates in CCN environment. As security of IoT communication is an important challenge, we have proposed an ECC-based efficient and secure architecture for IoT communication. Considering the limited resource of IoT devices, a certificateless ECC-based security architecture is designed that uses identity-based private keys for users and IoT devices. Moreover, a thorough security analysis is done to ensure that the proposed scheme is well protected from relevant cryptographic attacks.

Paper organization: The rest of the paper is organized as follows. In Sect. 2, the proposed scheme is presented and its security analysis is discussed in Sect. 3. Finally, Sect. 4 concludes the paper.

2 Proposed Scheme

In this section, we have designed a lightweight and secure IoT communication framework in CCN considering security of IoT communication as a major concern. The proposed IoT communication framework is depicted in Fig. 1 where the IoT gateway server is connected with the IoT devices and IoT end users using CCN framework. The connection is usually achieved through wireless connectivity where gateway server acts as a trusted authentication server (AS) and handles the security measures of the IoT communication system.

Fig. 1
figure 1

Proposed IoT communication framework in CCN

Full size image

In the proposed scheme, we have used Interest, Content, and Manifest packets for communication among user, AS, and IoT device. The general structure of these packet types is shown in Fig. 2. In addition, general structures of two databases maintained by AS, namely IoT device database and IoT user database, are given in Fig. 3.

Fig. 2
figure 2

General structure of different CCN packets

Full size image
Fig. 3
figure 3

General structure of IoT device database and IoT user database

Full size image

“Name prefix space” column of both the databases can have values for all the CCN namespaces involved in the IoT framework. The name prefix spaces are IoT_dev, IoT_user, IoT_admin, and IoT_as. The “commands” column of IoT device database has values like increase, decrease, print. The “device access permission” column stores the IoT device names for which the user has access. Similarly, “commands permitted” column lists the permitted commands which are used by a user to a particular IoT device. In our scheme, hierarchical CCN name is used for the IoT devices and end users. The example of CCN naming approach for the proposed IoT framework is shown in Fig. 4.

Fig. 4
figure 4

Example of CCN naming approach used for proposed IoT framework

Full size image

Multiple end users may access an IoT framework but depending on their authorization, specific access is allowed by the gateway/AS. We have used Manifest packet [4] to share access control information between the user and the AS. Manifest is also used by user to send commands to the IoT devices via AS. The proposed security framework is divided into three phases, namely (1) system initialization phase, (2) registration phase, and (3) authentication and session key negotiation phase. The details of these three phases are briefly described in the following subsections.

2.1 System Initialization

In this phase, the AS selects all the security parameters and publishes them in the respective CCN where the IoT framework operates. AS selects an elliptic curve E with prime order p and generator G and two secure one-way hash function h and h1 where h1: {0, 1}* ➔ \( {\mathbb{Z}}_{p}^{*} \). AS also chooses a random secret s ϵ \( {\mathbb{Z}}_{p}^{*} \) and calculates its public key PUAS = s · G. Finally, AS publishes the security parameters as {E, p, G, h, h1, PUAS}.

2.2 Registration Phase

Initially, all the users and the IoT devices need to register to the AS in order to be included in the IoT framework. The registration phase is conducted through a secure channel where the user and IoT device get their private keys from AS depending on their CCN name prefix which is unique and treated as identity. The identity of any user or IoT device is verified by the AS at the time of registration. Any IoT device is registered at the time of its deployment in the network, and its private key gets hardcoded in the respective device through the registration procedure. The private key of the IoT device is used for symmetric encryption of the transmitted data between the IoT device and AS. In the registration process, user provides its identity IDU to the AS and gets its private key s · h1(IDU). Similarly, an IoT device with identity IDD gets its private key s · h1(IDD).

2.3 Authentication and Session Key Negotiation Phase

The user needs to login to AS in order to access IoT framework for which he/she is registered. After successful mutual authentication between the user and AS, a contributory secret session key is negotiated. The session key is changed in each session/user login to ensure security. Now, the detailed procedure is depicted in Fig. 5 and discussed stepwise where \( X \to Y:M \) means sender X sends message M to receiver Y. Here, E/DX means symmetric encryption/decryption using key X. In addition, dot operator (.) and concatenation operator (||) are used for ECC point multiplication and message concatenation, respectively.

Fig. 5
figure 5

Mutual authentication and session key negotiation between user and AS

Full size image

Step 1: User ➔AS: \( \{ Interest,Manifest_{L} ,ID_{U} ,R_{U} ,Auth_{U} \} \)

Initially, the user selects a random number \( r_{i} \in {\mathbb{Z}}_{p}^{*} \) and calculates \( R_{U} = r_{i} \, \cdot \,G \), \( R = r_{i} \, \cdot \,PU_{AS} \), and \( Auth_{U} = h\left( {s\, \cdot \,h_{1} (ID_{U} } \right)\left| {\left| {R_{U} } \right|} \right|R) \). Finally, the user sends an Interest, requesting the content, a ManifestL for sending access control information regarding login process, along with identity IDU, RU, and authentication parameter AuthU to the AS. Here, Interest name prefix signifies the requested content name as shown in Fig. 4a.

Step 2: AS ➔ IoT Device: \( {\{ }\varvec{Interest}{\} } \)

After receiving the authentication request from step 1, the AS initially checks whether RU is received before. If yes, AS drops the login request. Else, searches if IDU is present in IoT user database. If yes, AS calculates \( R^{*} = R_{U} \, \cdot \,s \), \( Auth_{U}^{*} = h\left( {s\, \cdot \,h_{1} \left( {ID_{U} } \right)\left| {\left| {R_{U} } \right|} \right|R^{*} } \right) \) and checks \( Auth_{U}^{*} = Auth_{U} ? \) If yes, the user is authenticated; otherwise, AS drops the session. After successful authentication of the user, AS finds IoT name prefix from received Interest prefix and checks if IDU has access to requested IoT device. If yes, AS forwards the Interest to the respective IoT device (IDD).

Step 3: IoT Device ➔AS:\( \{ \varvec{E}_{{\varvec{s} \cdot \varvec{h}_{1} \left( {\varvec{ID}_{\varvec{D}} } \right)}} \left( \varvec{C} \right), \varvec{h}\left( \varvec{C} \right)\} \)

After receiving the Interest from step 2, the IoT device finds content item prefix from Interest name prefix. Then, it collects information/content C from the environment. It calculates h(C) and also encrypts C using its private key s · h1(IDD) as \( E_{{s.h_{1} \left( {ID_{D} } \right)}} \left( C \right) \). Finally, the IoT device sends the encrypted content to AS along with the content hash digest h(C).

Step 4: AS ➔User:\( \{ \varvec{Content}_{\varvec{C}} , \varvec{h}\left( \varvec{C} \right), \varvec{R}_{{\varvec{AS}}} \} \)

After receiving in step 3, AS decrypts the content as \( D_{{s \cdot h_{1} \left( {ID_{D} } \right)}} \left( {E_{{s \cdot h_{1} \left( {ID_{D} } \right)}} \left( C \right)} \right) \) and gets requested content C. Then, AS calculates hash digest of decrypted Cas h(C), and checks if calculated h(C) = received h(C). If yes, selects a random number \( r_{j } \in {\mathbb{Z}}_{p}^{*} \) and calculates \( R_{AS} = r_{j } \, \cdot \,PU_{AS} \) and contributory session key \( SK = r_{j} \, \cdot \,R^{*} \). Finally, AS encrypts C using SKas \( E_{SK} \left( C \right) \), generates content packet ContentC with the encrypted content, and sends ContentC, h(C) and key part RAS to the user.

After receiving the message in step 4, the user calculates contributory session key \( SK = r_{i} \, \cdot \,R_{AS} \). User gets encrypted content from ContentC packet and decrypts as \( D_{SK} \left( {E_{SK} \left( C \right)} \right) \) to get C. The user also calculates hash digest of decrypted C as h(C) and checks if calculated h(C) = received h(C). If yes, the AS is authenticated, SK is negotiated, and the received content C is accepted. Any further communication in the current session between the user and AS is encrypted using the negotiated contributory session key SK.

3 Security Analysis

In this section, several relevant cryptographic attacks are analyzed to show that our scheme is well protected.

3.1 Mutual Authentication

Mutual authentication is an important parameter of any security framework that is being taken care of in our scheme. In the proposed scheme, the user sends AuthU which is dependent on user’s secret key and random value ri and can be verified only by the AS. Accordingly, AS authenticates the user. Similarly, AS sends encrypted content, content hash digest h(C), and key part RAS. Upon calculating SK using RAS, the user decrypts the content, calculates its hash digest, and verifies received h(C) with calculated h(C). If verified, the user authenticates AS. Thus, the mutual authentication is completed.

3.2 Confidentiality

Confidentiality property is maintained in our scheme as none of the secret keys, session key SK, requested content, or authentication parameter AuthU travels openly rather either they are hashed or encrypted.

3.3 Replay Attack Resilience

In our scheme, replay attack by an intruder is successfully prevented as in step 2 of the authentication phase, AS checks whether RU is received before. If yes, AS drops the login request. Here, value of RU is dependent on a random value ri which is changed in each session. Hence, any repetition in the value of RU is detected by the AS.

3.4 Man-in-the-Middle Attack Resilience

As mutual authentication and confidentiality are maintained in the proposed scheme, any attempt of message modification or replay by an intruder will be identified by the user or AS. Hence, man-in-the-middle attack is prevented.

3.5 Perfect Forward Secrecy

Perfect forward secrecy is a property which ensures that even if the long-term keys are compromised at a point in time, the sessions before that time are still secure. As the proposed scheme uses random values ri and rj to calculate SK in each session, even if user’s long-term key (s · h1(IDU)) becomes compromised nobody will be able to compute SKs before that time.

3.6 Known Session Key Attack Resilience

Known session key attack means the knowledge of one session key reveals other session keys of different sessions. This is successfully prevented in our scheme because SK is calculated by using random values ri and rj which are changed in every session.

3.7 Brute Force Attack Resilience

Our scheme is resilient to brute force attack as an intruder cannot guess SK. Strength of SK is dependent on three secret random numbers ri, rj, and s from \( {\mathbb{Z}}_{p}^{*} \). Moreover, SK is a point on the elliptic curve. Hence, based on the security strength of elliptic curve discrete logarithmic problem, it is impossible to guess SK in polynomial time.

4 Conclusion

In this paper, a CCN-based IoT communication framework is proposed. Considering the openness of wireless connectivity and limited capacity of resource-constrained IoT devices, we have presented a lightweight security framework for CCN-based IoT communication using ECC. As ECC uses efficient point multiplication operation and smaller key size (160-bits) than other public key cryptosystems such as RSA (1024-bits) to provide same level of security, our scheme incurs low computation and communication overheads. Moreover, as identity-based private keys are used for user and IoT devices, the overheads of public key certificate generation, verification, management, etc., are eliminated. Finally, an in-depth security analysis ensures that the proposed scheme is resilient against relevant cryptographic attacks.