GISFI Meeting # 11
Bangalore, India – Dec 17-19, 2012
GISFI_IoT_201212335
Agenda item:
WG IoT
Source:
TCS
Title:
Security Requirements and a proposal for IoT
Document for:
Discussion and approval to accept as input documents for the IoT
Framework Technical Report document
GISFI TR 06.001 V1.0.0 (2012-09)
Technical Report
Global ICT Standardisation Forum for India
Internet of Things
M-Health System Use cases
(Release 1)
GISFI TR 06.001 V1.0.0 (2012-09)
Technical Report
Global ICT Standardisation Forum for India;
Technical Working Group IoT;
Technical Report on Security Requirements and a proposal for IoT
The present document has been developed within GISFI and may be further elaborated for the purposes of GISFI.
Release 1
3
GISFI TR 06.001 V1.0.0 (2012-09)
Keywords
Internet of Things, Protocol, Elliptic Curve, Cryptography, Pairing, prime number, Identity
GISFI
GISFI office address
Global ICT Standardization Forum for India (GISFI),
Singhad Campus, Gat 308/309, Kusgaon (Bk.)
Off. Mumbai– Pune Expressway, Lonavala, India
Tel.: +91 2114 304 353 / 401 Fax: +91 2114 278304
Internet
http://www.gisfi.org
E-mail: info@gisfi.org
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© 2010, GISFI
All rights reserved.
GISFI
Release 1
4
GISFI TR 06.001 V1.0.0 (2012-09)
Contents
Intellectual Property Rights ................................................................................................................................ 5
Foreword............................................................................................................................................................. 5
Introduction ........................................................................................................................................................ 5
1
Scope ........................................................................................................................................................ 6
2
References ................................................................................................................................................ 6
2.1
3
3.1
3.2
4
Normative references ......................................................................................................................................... 6
Definitions and abbreviations................................................................................................................... 6
Definitions ......................................................................................................................................................... 6
Abbreviations ..................................................................................................................................................... 7
Secure Communication of Devices in IoT ............................................................................................... 7
4.1
IoT Security Requirements ................................................................................................................................ 7
4.1.1 Communication Security ........................................................................................................................................... 7
4.1.2 Storage Security ......................................................................................................................................................... 8
4.2
IBE Related Standards ....................................................................................................................................... 8
4.3
Proposed IBE Scheme for secure IoT communication ...................................................................................... 8
4.3.1 IoT secure communication protocol .......................................................................................................................... 9
4.3.1.1 Sensor/Device/Application Registration ................................................................................................................. 9
4.3.1.2 IoT Secure communication Protocols ..................................................................................................................... 9
4.3.1.2.1 One way Device to Application communication through gateway ...................................................................... 9
4.3.1.2.2 Two way Device to Application communication through gateway ................................................................... 10
4.3.1.2.3 Two way Device to device communication through gateway ........................................................................... 10
4.3.1.2.4 Two way Device to device communication without Gateway ........................................................................... 10
4.3.1.3 Group Communication ......................................................................................................................................... 11
4.3.1.4 Key Revocation .................................................................................................................................................... 11
4.3.2 IoT secure communication protocol APIs ............................................................................................................... 12
GISFI
Release 1
5
GISFI TR 06.001 V1.0.0 (2012-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to GISFI. The information
pertaining to these essential IPRs, if any, is publicly available for GISFI members and non-members, and can be
found in GISFI yyy: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to GISFI
in respect of GISFI standards", which is available from the GISFI Secretariat. Latest updates are available on the
GISFI Web server (http://www.gisfi.org).
Pursuant to the GISFI IPR Policy, no investigation, including IPR searches, has been carried out by GISFI. No
guarantee can be given as to the existence of other IPRs not referenced in GISFI yyy (or the updates on the GISFI
Web server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by GISFI WG Internet of Things (IoT).
The present document may be referenced by other TRs and Technical Standards (TS) developed by GISFI WG IoT.
Introduction
There is a rapid development in the area of Information Communication Technology (ICT) with smart digital
devices driving the future of Internet of Things (IoT). To enable this development, devices of IoT need to
communicate securely. The IoT is a paradigm which describes how to connect/bring the Diaspora of several
heterogeneous electronic digital devices under the umbrella of Internet. The purpose of IoT is to control or access
these smart digital devices through the Internet. The basic issues in IoT deployment [1-3] are: 1. Reference
Architecture/Standardization. 2. Identity and addressing. 3. Governance/Management. 4. Service openness and
Interoperability. 5. Privacy and Security.
In this work, we are addressing the security issues, which is one of the most fundamental issues that need attention.
The present document discusses general requirements related to identity based encryption for secure communication
in IoT and the approved content of this can be mapped to the security of IoT (Section XX, Draft GISFI_IOT_XXXXXXX) in future.
GISFI
Release 1
1
6
GISFI TR 06.001 V1.0.0 (2012-09)
Scope
The present document specifies issues related to security scheme for IoT device secure communications. The scope
of the document highlights Identity based Elliptic Curve crypto systems for secure communications (for proposed
GISFI IoT architecture).
2
References
2.1
Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1].
[2].
[3]
[4].
[5
[6]
[7]
Technical Report on IoT Reference Architecture (Draft - GISFI_IoT_201203175)
Technical Report on Naming and Addressing in IoT(Draft-GISFI_IoT_201209 292)
Frame-work document for Technical Report on IoT Service Requirements (Draft GISFI_IoT_201106103)
http://www.scribd.com/doc/81784648/ETSI-TS-102-690-v-1-1-2-2011
]http://tools.ietf.org/html/rfc3986
http://www.ietf.org/rfc/rfc2396.txt
http://tools.ietf.org/html/draft-shelby-core-resource-directory-04
2.2 Informative references
The following referenced documents are not essential to the use of the GISFI deliverable but they assist the user
with regard to a particular subject area. For non-specific references, the latest version of the referenced document
(including any amendments) applies.
[1].
[2]
ITU-T Study Group -2 document on National Numbering Plan (Docs related to ITU-T E.164)
Draft TISPAN MI [00058] V0.0.11 (2011-03), ETSI TISPAN Future Topics, March 2011
3
Definitions and abbreviations
3.1
Definitions
For the purposes of the present document, the following terms and definitions apply:
IoT System: IoT is an integrated part of the future Internet that could be defined as “a dynamic global network
infrastructure with self-configuring capabilities linking physical and virtual objects through the exploitation of data
capture and standard and inter-operable communication protocols”.
IoT Device: Entity capable of sensing the state/features of an object and has communication and computing
capability. It may run limited local applications. The IoT device connects to the IoT Core network either through a
gateway or directly through embedded gateway functionality.
IoT Limited Device: It is an IoT device without capability of local computing (applications). It can communicate to
another IoT device or gateway. From the IoT perspective, it is managed by the IoT device/gateway to which it
connected.
IoT Gateway: IoT Gateway acts as a proxy between the IoT devices and IoT Core network. It shall locally manage
the IoT devices (including IoT Limited Devices) and shall run IoT applications.
IoT Network: IoT Network includes the access network that connects the IoT devices to the gateway and core
network that connects the gateways to the IoT service platforms.
GISFI
Release 1
7
GISFI TR 06.001 V1.0.0 (2012-09)
IoT Service Platform: It provides an open interface to IoT functions that can be shared by multiple applications. It
hides the intricacies of underlying IoT system and eases the application development. Further various system
management and control functions are also taken care here.
IoT Applications: IoT applications are domain specific applications that use various services exposed by IoT
Service Platform.
3.2
Abbreviations
For the purposes of the present document, the following abbreviations apply:
IoT
IP
ARP
RFID
M2M
ID
PKI
URI
IBE
ETSI
4
Internet of Things
Internet Protocol
Address Resolution Protocol
Radio Frequency ID
Machine to Machine
Identity
Public Key Infrastructure
Uniform Resource Identifier
Identity based Encryption
European Telecommunications Standards Institute
Secure Communication of Devices in IoT
As discussed in the IoT reference architecture [1], the actors in IoT are devices, gateways and external applications/
devices. They communicate each other to improve the user experiences in real time (Example: disaster management
using IoT). Most of the time, the communication will be through wireless medium. Thus it brings the very critical
issue, the data/communication security, which is in greater threat and the questions the integrity of the IoT. So one
of the most fundamental issues in IoT is how to Implement a secure communication between the devices and also
authenticate the devices.
4.1
IoT Security Requirements
For secure communication and authentication between the devices, cryptography is an essential tool. In general,
cryptography with PKI is very popular, wherein the certificates contains the public and private keys are issued to the
users and users using these keys encrypt and decrypt their data and thus security is enabled. The same scheme is not
suitable for IoT scenario. The crypto system for IoT security has following requirements. The requirements are broadly
classified into two categories to ensure Confidentiality, Integrity and Availability.
1. Communication Security
2. Storage Security
4.1.1 Communication Security
The communication security deals to handle the security for the IoT communications. It has following requirements
1.
Secure Device to Device Communication: Here the cryptographic technique should enable secure IoT
communication across l1, l2 and l3 interfaces. The cryptographic technique should be lightweight.
2.
No Public Key Infrastructure (PKI): Number of devices in IoT is very large, maintaining keys at PKI is not
feasible. So cryptographic technique with no PKI is very essential
3.
Certificate less cryptography: IoT demands less infrastructure for security, hence the requirement here is to
design crypto systems with no certificates.
4.
No Key Exchange: One of goal of IoT is to reduce number of control/communication messages. So this is
applicable to secure communications also. Since device to device communications in IoT are very prevalent,
to minimize the message overheads, crypto system should support no key exchanges.
GISFI
Release 1
8
GISFI TR 06.001 V1.0.0 (2012-09)
5.
Anonymity: In IoT, prominently in the area of disaster management/mission critical operations, to avoid
attacks from the intruders, anonymity is required. So it is desirable that crypto system should support security
as well as anonymity also.
6.
Variable security requirement: Handling of heterogeneous devices with differing protocols
7.
Group Communication: In IoT, very often the Application(layer 4) requires data from different devices and
also need to control them
4.1.2 Storage Security
In future, IoT is the largest source of data for various diversified applications. How to store and archive the data at
devices, platform, and service providers robustly is a big challenge. So data should be delivered/distributed to
intended users/applications only in a secured and anonymized. So it is desirable to have a lightweight crypto system
for secure collection, storage, and archive and distribute.
So a scalable, lightweight, with no infrastructure, certificate less and no key exchange cryptographic technique is
essential for secure IoT communication. Thus using IBE, we can envisage the requirements of the secure
communication for IoT.
4.2
IBE Related Standards
 IEEE has a draft version standard on IBE cryptography IEEE P1363, which is very generic and not specific to
IoT/M2M communication.
 For M2M and IoT, the existing schemes proposed by ETSI based on IBE are through key exchange algorithms
(D-H algorithm) and authentication using IBAKE algorithm and uses Weil paring in cryptography. We
propose IBE cryptographic schemes with or without key exchanges along with anonymity, authentication and
signature schemes.
4.3
Proposed IBE Scheme for secure IoT communication
An IBE is a secure certificate-less cryptography scheme, wherein the devices can generate the public key of the
other devices by using publicly known identity of the devices such as device’s: id, owner’s id, mac-id, etc. and
encrypt the message with this public key and on the other hand the device which receives the encrypted message
shall decrypt the message using its’ private key (obtained during device registration/bootstrapping in IoT).
Thus the identities of the devices are very important aspect for the IBE scheme. Majority of the IoT devices have
unique identities such as device-id, URI, device’s network access id (NAI), Object Identifier OID (object-identifier
defines the domain the device belongs to + Data: unique for the given domain), The Internet Universal Resource
Name (URN: IETF RFC 1737). The URN name space includes ISSN,OID, ISBN, NBN, UUID, Nfc, Epc,
Epcglobal etc with namespace id (NID ) 3,4,9, 10,18,24,35, etc respectively. For example URN for a device/object
can be reference by urn:oid:ietf:xxxx.xxxx.xxxx. Similarly other way to given an identity to the device is using
ubiquitous code: ucode system which offers an end to end linking of objects to the IoT. The device number/id can be
obtained by registering to Ubiquitous ID center. Ucode is a 128 bit structure. Similarly DOI, URI and URL can also
be associated as an id to the device. We propose to use the device’s URI[2] as an Identity of the device along with
owner’s id
To perform secure IoT communication among the devices, they have to perform following operations
o
Setup: Public Key Generator (PKG) is established at Gateway [1].
o
Extract : Device Registers with its ID(Bootstrapping) with PKG(Gateway) and receives public and
private keys
o
Encrypt
o
Decrypt
GISFI
Release 1
9
GISFI TR 06.001 V1.0.0 (2012-09)
In this section, we describe our proposed IBE scheme and IoT secure communication protocol.
4.3.1 IoT secure communication protocol
We propose following operations/APIs for IoT Secure communication protocol.
1. Sensor/Device/Application Registration(Layer1)
2. IoT Secure communication Protocols
3. Group Communication Protocols.
4. Key Revocation.
4.3.1.1 Sensor/Device/Application Registration
With reference to IoT architecture [1], the Public key Generator (PKG) shall be placed at Platform services,
wherein it facilitates the sensor/device/application registration and also provides their public keys and private
keys on request. Figure-1 describes the registration scheme under IoT framework. The
sensor/device/Application submits their IDs during registration and receives the ECC parameters required for
the encryption and decryption. Table-1 describes the list of ECC parameters that service platform transmits to
the sensors/devices/applications.
4.3.1.2 IoT Secure communication Protocols
In IoT, the communications happens between the applications and the devices either to collect data from them or need
to send commands to control them. We envisage the following secure communications in IoT framework. For each of
the communication schemes, we propose to have separate IBE Protocol Interfaces (IPIs).
1.
One way Device to Application communication through gateway
2.
Two way Device to Application communication through gateway
3.
Two ways Device to Device Communication through Gateway.
4.
Two way Device to device communication without Gateway
5.
Group Communication
4.3.1.2.1 One way Device to Application communication through gateway
The scenario here is device1 wants to send a message to Application-1 through securely through gateway. The flow
is as follows (see Figure2).
1.
Device1 encrypts the message using Application1’s public id.
2.
Device1 encrypts the encrypted message+ Application1’s id using gateway’s public id.
3.
Device1 transmits the encrypted message done in step2 to gateway.
4.
Gateway upon receipt of the message decrypts the message using its’ private key
5.
Transmits the decrypted message to the Application1 using Application1’s address.
6.
Application1 decrypts the message using its private key.
The encryption in step 2 is required to annonmyze to the third part device that to whom the device1
sending the message. This scheme has added advantage that devie2 may not know, from whom it has
GISFI
Release 1
10
GISFI TR 06.001 V1.0.0 (2012-09)
received the message. Thus sender’s identity is preserved and thus this scheme ensures sender’s
anonymity.
4.3.1.2.2 Two way Device to Application communication through gateway
The scenario here is device1 and Applicatiion1 wants to exchange the messages each other through securely through
gateway. The flow is as follows (see Figure3).
1.
Device1 encrypts the message+ device1’s id using Applicatiion1’s public id.
2.
Device1 encrypts the encrypted message+ Applicatiion1’s id using gateway’s public id.
3.
Device1 transmits the encrypted message done in step2 to gateway.
4.
Gateway upon receipt of the message decrypts the message using its’ private key
5.
Transmits the decrypted message to the Applicatiion1 using Applicatiion1’s address.
6.
Applicatiion1 decrypts the message+ device1s id using its private key
7.
Similarly the steps 1 to 6 are repeated with changing roles of device1 and Applicatiion1.
The encryption in step 2 and step 7 are required to annonmyze both the sender and receiver to the third
part device.
4.3.1.2.3 Two way Device to device communication through gateway
The scenario here is device1 and device2 wants to exchange the messages each other through securely through
gateway. The flow is as follows.
1.
Device1 encrypts the message+ device1’s id using device2’s public id.
2.
Device1 encrypts the encrypted message+device2’s id using gateway’s public id.
3.
Device1 transmits the encrypted message done in step2 to gateway.
4.
Gateway upon receipt of the message decrypts the message using its’ private key
5.
Transmits the decrypted message to the device 2 using device2’s address.
6.
Device2 decrypts the message+ device1s id using its private key
7.
Similarly the steps 1 to 6 are repeated with changing roles of device1 and device2.
4.3.1.2.4 Two way Device to device communication without Gateway
In this scenario two devices with in the same gateway cluster want’s to communicate each other securely without
gateway. This is done through mutual authentication. The flow is as follows.
1.
Device1 encrypts a secrete message (for example hello) + device1s id using device2’s public id.
2.
Device1 transmits/broadcasts the encrypted message.
3.
Among all the recipients, only device2 can decrypt the message using its’ private key.
4.
Device2 re-encrypt the decrypted message+ device2’s id using device1’s public key.
GISFI
Release 1
11
GISFI TR 06.001 V1.0.0 (2012-09)
5.
Device2 transmits/broadcasts the encrypted message.
6.
Among all the recipients, only device1 can decrypt the message using its’ private key.
7.
Device1 verifies the message with its original message and if it is same then they start
communicating each other securely.
4.3.1.3 Group Communication
1. The set of devices and applications form a group.
2. The Application sends request to the service platform to generate group-id, group public key and group private
key.
3. The Application then transmits this information to the peer devices by encrypting individually with their public
ids.
4. The members of the group can decrypt any encrypted message, which is delivered to them using the group
private key and any device/Application which are not part of the group can send encrypted message using
group’s public key (generated from group public id).
SendECCParameter
Sensor/Device/Application-ID-of-the Vehicle
Elliptic Curve=y2=ax3+bx2+c
Prime number :p
Prime Torsion group order q
Torsion group Point P=T[q]
Torsion group Point Q=S[q]
Table-1:
SendECCParameter Details
Public Key
Private Key
4.3.1.4 Key Revocation
How to re-issue the secrete key to the device again in case of key leakage to third party? This is called keyrevocation which is a difficult issue to resolve in case of IBE. We propose the use of attribute based encryption
scheme using lattice based cryptography.
GISFI
Release 1
12
GISFI TR 06.001 V1.0.0 (2012-09)
4.3.2 IoT secure communication protocol APIs
We propose the following APIs for IoT secure communication protocols.
API
Interfaces
From
To
Through
I1/I2
Device(L1)
Service Platform(L3)
Gateway(L2)
doGWRegistration
I2
Gateway(l2)
Service Platform(L3)
-NA-
doApplicationRegistration
I3
Application(L4)
Service Platform(L3)
-NA-
sendECCParameters
I3/I2/I1/I4
Service
Platform(L3)
Device/Gateway/Application
Gateway/-
sendGW
I1
Device(L1)
Gateway(L2)
-NA-
I2/I3
Gateway(l2)/
Application(L4)
Service Platform(L3)
-NA-
I3
Service
Platform(L3)
Application(L4)
-NA-
I2
Service
Platform(L3)
Gateway
-NA-
deliverDevice
I1
Gateway(l2)/
Device(L1)
-NA-
doGroupRegistration
I3
Application(L4)
Service Platform(L3)
-NA-
doDeviceRegistration
SendSP
deliverApp
deliverGW
GISFI
Release 1
13
GISFI TR 06.001 V1.0.0 (2012-09)
I1
I2
doDevice Registration
(Device ID)
I3
IBE
Sensor/Device
doDeviceRegistration
(Device ID)
(ID: URI)
Gateway
ECC
doApplicationRegistrat
ion (ApID)
PKG
I3
(Setup)
I2
I1
sendECCParameters
sendECCParameters
Service
Platform
sendECCParameters
Figure-1 Sensor/Device/Application Registration at PKG
GISFI
Applications
Release 1
14
GISFI TR 06.001 V1.0.0 (2012-09)
Application1
Device1
Generate
qAp1=Application1’
s Public key using ID
=Application1
I1a
I1a
C=Enc(Enc(message,
qAp1)+Application1’
sID,qGID)
Service
Platform
Gateway
sendGW( C)
Qgid=Gateway’s
public key
sGID=gateway’s
secrete id.
Extract Application1’s
encrypted message
:EncAp1,and
address=Dec(C,sGID)
sAp1=Application1s
secrete id
I2
I3
sendSP(EncAp)
deliverApp(EncAp,
Application1)
message=Dec(EncAp,
sAp1)
Figure-2 One way Device to Application communication through gateway
GISFI
Release 1
15
GISFI TR 06.001 V1.0.0 (2012-09)
Application1
Device1
Gateway
sID1=Device1’s
secrete ID
Generate
qAp1=Application1’
s Public key using ID
=Application1
C=Enc(Enc(message
1,qAp1)+Application
1’sID,qGID)
Service
Platform
I1a
sendGW( C)
Qgid=Gateway’s
public key
sGID=gateway’s
secrete id.
Extract Device1’s
encrypted message
:EncAp1,and
address=Dec(C,sGID)
sAp1=Application1s
secrete id
I2
I3
sendSP(EncAp)
deliverApp(EncAp,
Application1)
I2
Message2=Dec(En
cAp,sid1)
I1a
Extract Application1’s
encrypted message
:EncDev,and
Device1’s
ID=Dec(C,sGID)
deliverGW(C)
deliverDevice(
EncDev)
Figure-3 Two way Device to Application communication through gateway
GISFI
I3
sendSP(C)
message1=Dec(EncA
p,sAp1)
Generate
qID1=Device1’s Public
key using ID =Device1
C=Enc(Enc(message2,qI
D1)+Device1’sID,qGID
)