Setting up an IoT device is a crucial step. If we take the case of a consumer product, this process is expected to be done once when unpacking each of the purchased products. The main challenge for set up is that it must be both a seamless experience and a secure procedure: the device must be uniquely authenticated and set-up cannot expose vulnerabilities. This set-up procedure needs to be designed and executed correctly, otherwise it can impair either security, or market success. Hence, it is no surprise that security has been severely undermined in the past years, with vendors preferring easy but unsecure pairing. One can think for instance of the many IoT device manufacturers that have been using a common login/password (e.g. admin/password) for all their products. This has created a huge security hole exploited by MIRAI bots. Successful device setup should therefore combine both ease of use and security for the consumer. We will discuss this in more detail in this paper.
Onboarding a consumer product
Retail IoT products need to be first set up, and usually maintained by the most tech-savvy person in the household. After the device has been connected to the wired or wireless network, the device must be configured to be used by the end user or by other IoT devices and applications. We compare this configuration to personnel onboarding – the comprehensive human resource process where new employees are integrated into a company. When this happens, several different departments within an organization execute various processes to set new employees up with email, computers, phone, tax paperwork, payroll, benefits, and relevant training enrollment. Similar to employee onboarding, device onboarding for IoT devices executes multiple processes to bring new IoT devices into an IoT secure domain:
- Successful ownership transfer from manufacturer to purchaser, or from one purchaser to the next. The first step of onboarding is to establish ownership of the device, which also establishes the device as a member of the IoT security domain. Once owned, it should be possible for another owner to own the device only by relinquish ownership, returning the device to the not-owned state either using a hardware reset or executing an appropriate API call. This is important so the inherent security of the device can be maintained. Today, a manual process exists where device ownership is transferred, activated in the field, configured on the network, and registered with the device owner in an IoT management platform. This time-intensive and costly process is fraught with security holes. With device onboarding for IoT devices, the process brings new IoT devices into an IoT secure domain.
- Credential provisioning: the device is provisioned with credentials for establishing mutually-authenticated secure connections with other devices in the IoT secure domain.
- Granular access control: with onboarding, a device can be provisioned with varying levels of security. For example, maybe only the parents in a house can program the thermostat, but the children can only turn it up and down.
There are proprietary solutions which offer onboarding at scale, but their interface is restricted in the worst case to one device product or, more likely, to a number of device products within a manufacturer’s product range. The motivation for using a proprietary API can be vendor lock-in and/or the lack of standard APIs supporting the device’s functionality. Some of the limits of proprietary software include high cost, lack of developer support, security issues, and lack of customization options.
An Introduction to the OCF
The Open Connectivity Foundation (OCF) is a global standard body helping the emergence of a real Internet of Things, meaning across all vertical industries. OCF is built on three pillars: public specification, open source code, and certification. OCF publishes open specifications certified as international standards by the International Standards Organization (ISO) and International Electrotechnical Commission (IEC). OCF runs the IoTivity project that manages two open source implementations of the OCF Specification available on Github: IoTivity for hub, and IoTivity lite for end points. Having concrete implementations eliminates ambiguity for developers, reduces time to market for device manufacturers, and forges interoperability. Lastly, OCF runs a certification program delivering an OCF Certified label and maintaining a database of Certified device products, and an associated OCF Public Key Infrastructure which can be used to issue manufacturer certificates for OCF Certificated devices.
The foundation believes in helping the industry by offering tools for seamless bridging to other ecosystems. This bridging framework helps manufacturers to span multiple vertical industries and maximize their development investment to increase cross-market opportunities. OCF bridging capabilities also enable companies to fully integrate OCF-Certified products into proprietary and legacy solutions without losing their current investments. For the purpose, OCF maintains OneIoTa, a database of data models: it is open for public contribution and allows developers to translate automatically from any included data model to any others. Anyone can contribute by specifying their data model in OpenAPI 2.0. Note that the tools to generate code and translate are available on Github.
OCF uses REpresentational State Transfer (REST) for messaging between devices. For each logical set of information, a resource is designed. The resources are designed in Open API (using JSON), but are transferred on the wire as CBOR, an automatic translation into binary format that reduces the size of the payloads (similar like zip). This means that OCF supports the ease of using internet technologies (RESTful and Open API/JSON) while being suitable for small devices due to the use of binary payloads.
OCF Solution for Security
OCF mandates that device provisioning can happen only when the client is on the same secure domain. The provisioning instructions are sent over a secure connection, encrypted by Datagram Transport Layer Security (DTLS).
The onboarding on the secure domain is split technically into ownership transfer of the device and provisioning the device. The whole process is defined as a set of state transitions and described in the following picture (simplified):
- Ready for Ownership Transfer Method (RFOTM)
- Ready for PROvisioning (RFPRO)
- Ready for Normal OPeration (RFNOP)
click for larger image
(Source: Open Connectivity Foundation)
The below schematics define how the operations proceed in time. Successful ownership transfer means that the device state will go into normal operation (RFNOP).
click for larger image
(Source: Open Connectivity Foundation)
Ownership transfer locks the device down to a secure domain. Only the owner of the secure domain can change it. If an application or other IoT device wants to communicate to the device, it needs to be part of the same secure domain. Only devices that are part of the secure domain can talk securely to each other.
OCF defines three ownership transfer methods (OTMs) or algorithms:
- Just Works, based on Anonymous Diffie-Hellman, provides no authentication of the new device nor onboarding tool (OBT).
- Random Pin: requires that the device can display a PIN during the ownership transfer, the PIN is generated randomly during onboarding time. This mechanism provides mutual authentication of the Device and OBT. Devices without the capability of displaying the PIN can’t use this onboarding mechanism.
- Manufacturer Certificate using a Public Key Infrastructure (PKI), needs an additional infrastructure to create and store certificates in the Device. Hence cost-wise Certificate is more expensive than Just Works. Random Pin requires a display which if not serving another purpose would be more expensive. This mechanism provides authentication of the Device but not authentication of the OBT.
Which of these different techniques is provided is a device manufacturer choice depending on their needs, and the capabilities of the device.
Access to a resource is governed by entries matching the resource in the Access Control List (ACL), which also specify:
- Permission of access: create/read/update/delete/notify (CRUDN) of the resource.
- Device identifier, role identifier (discussed further in a later section) or connection type of the Client gaining access to the resource.
When all provisioning steps are completed, the device will go to the “Ready for Normal operation” state. This means that all incoming actions will be checked against:
- If the connecting device is a member of the same secure domain
- if the connecting device has access to perform the requested action on the resource.
When all steps are granted, the action will be performed by the device.
Protecting the Device
As mentioned in the introduction, it is important that a device neither be attacked nor be permitted to attack other systems with which it has no business communicating. A layered approach is taken: role-based access control and manufacturer usage descriptions. The former addresses device security, while the latter adds an additional layer of protection from the network.
Role-based access control
When device identifiers are used to grant access, then each device has to be set up to grant each client access. A simpler and more scalable solution is using role-based access control (RBAC). In this case the ACL entry has a unique identifier that represents the role that a client can perform. This role is then configured on the client, without which the device would have to be reconfigured.
In this way different access levels can be created:
- Administrator access
- Guest access
- Normal operation access
- Maintenance access
The device must be configured for each supported role, rather than be configured for each device.
OCF has defined a standardized solution to safely onboard a consumer product. However, setting up an enterprise product in an existing infrastructure network is a different challenge. First, IT people cannot go through a one-by-one installation procedure for every device. It would not be reasonable to expect them to repeat the same lengthy procedure for all light bulbs in an office, one by one. Second, the installation requires more choices: the network administrator must decide what network and what resources they will be allowed to access. Said differently, the challenge is in scaling deployment over multiple offices and/or buildings without compromising security either. Here as well, poor implementation can have catastrophic impact. In 2018, a casino fell victim to hackers thanks to a smart thermometer monitoring the water of an aquarium installed in the lobby. The hackers managed to find and steal information from the casino’s high-roller database by connecting to the thermometer. Using an otherwise-innocuous device that had not been secured for the IoT, some very confidential information can fall easily into the wrong hands. We will not describe enterprise products here but will cover that in a future article.
Oleksandr Andrieiev is Standards Engineer at Samsung Electronics and chair of the Open Connectivity Foundation Security Work Group.
Philip Hawkes is Principal Engineer at Qualcomm and vice chair of the Open Connectivity Foundation Security Work Group.
The post IoT device security: A path to standardization appeared first on Embedded.com.