October 26, 2015 - Habib Virji
The Essentials of IoTivity Connectivity
This article is part 1 of a 3 part series on how IoTivity handles security for the connected IoT world.
IoTivity is a Linux Foundation Collaborative Project that implements the Open Interconnect Consortium (OIC) standard. OIC is a consortium of over 100 companies that are working together to develop a standard for interoperability between the IoT devices. It includes a certification program to check interoperability between devices from different manufacturers.
The OIC has various task groups that each address different areas in the IoT domain. The primary group is the core group which defines the base layer and lays the foundation for the other task groups. The other prominent task groups include security and remote connectivity.
The security task group defines the base security layer that is expected in each device; this allows devices to secure trust and provide an access control policy for other devices in a house. Remote connectivity defines how an OIC device will communicate remotely. There are other groups which handle vertical such as home, industry, health, etc. These groups build on top of the core group and address specific details to that domain on top of the core IoTivity group. Based on the vertical a device belongs to, OIC will certify the devices as being interoperable between different vendors.
The IoTivity Client – Server Model
OIC is based on RESTful interface concept where devices communicate with each other over well-known interface (resource). Each resource can have multiple attributes and including a type, interface, the operations it’s capable of performing, and access control. The device that hosts the resources is the server and any device that queries resources is a client. The server makes the resource discoverable to clients.
The client must establish communication with the server to access resources, and the first resource must be discovered over the network. This discover process occurs by sending a multicast packet via CoAP (Constrained Application Protocol). CoAP is a REST based protocol that is a trimmed-down version of HTTP. The main difference between CoAP and HTTP is that CoAP uses smaller headers because it’s is targeted primarily for constrained devices.
Multicast packets are sent over the resource /oic/res and the device that matches the resource being looked for responds with a unicast communication to the querying device. This response provides the address and information for the querying device to connect to the device holding the resource and perform control operations. Control operations are typically to write, update or delete the resource attributes.
Discovery and access control of resources are based on the security settings that are established between the devices. The first step is to establish a device trust relationship which is done via Onboarding. Next, the resources are provisioned and the devices are able to establish a secure connection between each other. It uses DTLS (Datagram Transport Layer Security) to connect the devices using the key that was created during the onboarding process. This key is also used to encrypt and decrypt network communications. Finally, the access control policies control which device has access to which resources.
Remote connectivity of devices in OIC network is handled over XMPP, and devices in the home network that need to communicate remotely must have an XMPP client and they must login to the XMPP server in order to communicate with each other. The XMPP connection establishes an in-band bytestream that uses the same security mechanism as the local area network to establish device trust relationships.
About Habib Virji
Habib Virji is a Senior Software Engineer for the Samsung Open Source Group. He has contributed to many open source projects over the last 5 years including Webinos, an open source platform for secure communication between devices. Now, he is a committer for the Blink project and has contrbuted to areas including Keyboard Events, WebCrypto and HTML Forms; he is also a sub-maintainer for the device interoperability modules of the IoTivity Project.