In this article by Drew Van Duren and Brian Russell, the authors of the book, Practical Internet of Things Security, we'll have a look at how establishing a structured identity namespace will significantly help manage the identities of the thousands to millions of devices that will eventually be added to your organization.

(For more resources related to this topic, see here.)

Establishingnaming conventions and uniqueness requirements

Uniqueness is a feature that can be randomized or deterministic (for example, algorithmically sequenced); its only requirement is that there are no others identical to it. The simplest unique identifier is a counter. Each value is assigned and never repeats itself. The other is a static value in concert with a counter, for example, a device manufacturer ID plus a product line ID plus a counter. In many cases, a random value is used in concert with static and counter fields. Nonrepetition is generally not enough from the manufacturer's perspective. Usually, something needs a name that provides some context. To this end, manufacturer-unique fields may be added in a variety of ways unique to the manufacturer or in conformance with an industry convention. Uniqueness may also be fulfilled by using a globally unique identifier (UUID) for which the UUID standard specified in RFC 4122 applies. No matter the mechanism, so long as a device is able to be provisioned, an identifier that is nonrepeating, unique to its manufacturer, use, application, or a hybrid of all these should be acceptable for use in identity management. Beyond the mechanisms, the only thing to be careful about is that the combination of all possible identifiers within a statically specified ID length should not be exhausted prematurely if at all possible.

Once a method for assigning uniqueness to your IoT devices is established, the next step is to be able to logically identify the assets within their area of operation in order to support authentication and access-control functions.

Naming a device

Every time you access a restricted computing resource, your identity is checked to ensure that you are authorized to access that specific resource. There are many ways in whichthis can occur, but the endresult of a successful implementation is that someone who does not have the right credentials is not allowed access. Although the process sounds simple, there are a number of difficult challenges that must be overcome when discussing identity and access management for the constrained and numerous devices that comprise the IoT.

One of the first challenges is related to the identity itself. Although identity may seem straightforward to you—your name, for example—that identity must be translated into a piece of information that the computing resource (or access-management system) understands. The identity must also not be duplicated across the information domain. Many computer systems today rely on a username, where each username within a domain is distinct. The username could be something as simple as <lastname_firstname_middleiniital>.

In the case of the IoT, understanding what identities, or names, to provision to a device can cause confusion. As discussed, in some systems, devices use unique identifiers such as UUIDs or Electronic Serial Numbers (ESNs).

We can see a good illustration by looking at how Amazon's first implementation of its IoT service makes use of the IoT device serial numbers of IoT devices. Amazon IoT includes a thing registry service that allows an administrator to register IoT devices, capturing for each the name of the thing and various attributes of it. The attributes can include data items such as:

• manufacturer
• type
• serial number
• deployment_date
• location

Note that such attributes can be used in what is called attribute-based access control(ABAC). ABAC access approaches allow access decision policies to be defined not just by the identity of the device but also its properties (attributes). Rich, potentially complex rules can be defined for the needs at hand.

The following figure provides a view of the AWS IoT service:

Even when identifiers such as UUIDs or ESNs are available for an IoT device, these are generally not sufficient for securing authentication and access-control decisions; an identifier can easily be spoofed without enhancement through cryptographic controls. In these instances, administrators must bind another type of identifier to a device. This binding can be as simple as associating a password with the identifier or, more appropriately, using credentials such as digital certificates.

IoT messaging protocols frequently include the ability to transmit a unique identifier. For example, MQTT includes a ClientID field that can transmit a broker-unique client identifier. In the case of MQTT, the ClientID value is used to maintain state within a unique broker-client communication session.

Secure bootstrap

Nothing is worse for security than an IoT-enabled system or network replete with false identities used in acts of identity theft, loss of private information, spoofing, and general mayhem. However, a difficult task in the identity lifecycle is to establish the initial trust in the device that allows it to bootstrap itself into the system. Among the greatest vulnerabilities to secure identity and access management is insecure bootstrapping.

Bootstrapping represents the beginning of the process of provisioning a trusted identity to a device within a given system. Bootstrapping may begin in the manufacturing process (for example, in the foundry manufacturing a chip) and be completed once delivered to the end operator. It may also be completely performed in the hands of the end user or some intermediary (for example, the depot or supplier) once delivered. The most secure bootstrapping methods start in the manufacturing processes and implement discrete security associations throughout the supply chain. They uniquely identify a device through:

• Unique serial numbers printed on the device.
• Unique and unalterable identifiers stored and fused in device read-only memory(ROM).
• Manufacturer-specific cryptographic keys used only through specific lifecycle states to securely handoff the bootstrapping process to follow-on lifecycle states (for example, shipping, distribution, and handoff to an enrollment center). Such keys (frequently delivered outofband) are used for loading subsequent components by specific entities responsible for preparing the device.

PKIs are often used to aid in the bootstrap process. Bootstrapping from a PKI perspective should generally involve the following processes:

1. Devices shouldbe securely shipped from the manufacturer (via secureshipping servicescapable of tamperdetection) to a trusted facility or depot. The facility should have robust physical security access controls, record-keeping, and audit processes in addition to highly vetted staff.
2. Device counts and batches should bematched against the shipping manifest.

Once they have been received, the steps for each device include:

1. Authenticating the device uniquely,using a customer-specific, default manufacturer authenticator (password or key).
2. Installing PKI trust anchors and any intermediate public key certificates (for example, those of the registration authority, enrollment certificate authority, or other roots).
3. Installing minimal network reachability information such that the device knows where to check certificate revocation lists, perform OCSP lookups, or perform other security-related functions.
4. Provisioning the device PKI credentials (public key signed by CA) and private key(s) such that other entities possessing the signing CA keys can trust the new device.

A secure bootstrapping process may not be identical to that described in the preceding list but should be one that mitigates the following types of threats and vulnerabilities when provisioning devices:

• Insider threats designed to introduce new, rogue, or compromised devices (whichshould not be trusted)
• Duplication (cloning) of devices no matter where in the lifecycle
• Introduction of public key trust anchors or other key material into a device that should notbe trusted (rogue trust anchors and other keys)
• Compromising (including replication) of a new IoT device's private keys during key generation or import into the device
• Gaps in device possession during the supply chain and enrollment processes
• Protection of the device when re-keying and assigning new identification material needed for normal use (re-bootstrapping as needed)

Given the security-critical features of smart chip cards and their use in sensitive financial operations, the smartcard industry adopted rigid enrollment process controls not unlike those described above. Without them, severe attacks would have the potential of crippling the financial industry. Granted, many consumer-level IoT devices are unlikely to have secure bootstrap processes, but over time,the authorsbelieve that this will change, depending on the deployment environment and the stakeholders' appreciation of the threats. The more connected devices become, the more their potential to do harm.

In practice, secure bootstrapping processes need to be tailored to the threat environment of the particular IoT device, its capabilities, and the network environment in question. The greater the potential risks, the more strict and thorough the bootstrapping process needs to be.

Credential and attribute provisioning

Once the foundation for identities within the device is laid, the provisioning of operational credentials and attributes can occur. These are the credentials that will be used within an IoT system for secure communications, authentication, and integrity protections. The authorsstrongly recommend using certificates for authentication and authorization whenever possible. If using certificates, an important and security-relevant consideration is whether to generate the key pairs on the device itself or centrally.

Some IoT services allow the central (for example, by a key server) generation of public/private key pairs. While this can be an efficient method of bulk-provisioning thousands of devices with credentials, care should be taken to address potential vulnerabilities the process may expose (that is, the sending of sensitive, private key material through intermediary devices/systems). If centralized generation is used, it should make use of a strongly secured key-management system operated by vetted personnel in secured facilities. Another means of provisioning certificates is through local generation of the key pairs (directly on the IoT device) followed by transmission of the public key certificate through a certificate-signing request to the PKI. Absent well-secured bootstrapping procedures, additional policy controls will have to be established for the PKI's registration authority(RA) in order to verify the identity of the device being provisioned. In general, the more secure the bootstrapping process, the more automated the provisioning can be. The following is a sequence diagram that depicts an overall registration, enrollment, and provisioning flow for an IoT device:

Local access

There are times when local access to the device is required for administration purposes. This may require the provisioning of SSH keys or administrative passwords. In the past, organizations frequently made the mistake of sharing administrative passwords to allow easeofaccess to devices. This is not a recommended approach, although implementing a federated access solution for administrators can be daunting. This is especially true when devices are spread across wide geographic distances, such various sensors, gateways, and other unattended devices in the transportation industry.

Account monitoring and control

After accounts and credentials have been provisioned, accounts must continue to be monitored against defined security policies. It is also important that organizations monitor the strength of the credentials (that is, cryptographic cipher suites and key lengths) provisioned to IoT devices across their infrastructure. It is highly likely that pockets of teams will provision IoT subsystems on their own; therefore, defining, communicating, and monitoring the required security controls to apply to those systems is vital.

Another aspect of monitoring relates to tracking the use of accounts and credentials. Assign someone to audit local IoT device administrative credential (passwords and SSH keys) use on a routine basis. Also, strongly consider whether privileged account-management tools can be applied to your IoT deployment. These tools havefeatures such as checking out administrative passwords to aid in audit processes.

Account updates

Credentials must be rotated on a regular basis; this is true for certificates and keys as well as passwords. Logistical impediments have historically hampered IT organizations' willingness to shorten certificate lifetimes and manage increasing numbers of credentials. There is a tradeoff to consider as short-lived credentials have a reduced attack footprint, yet the process of changing them tends to be expensive and time consuming. Whenever possible, look for automated solutions these processes. Services such as Let's Encrypt (https://letsencrypt.org/) are gaining popularity inhelping improve and simplify certificate-management practices for organizations. Let's Encrypt provides PKI services along with an extremely easy-to-use plugin-based client that supports various platforms.

Account suspension

Just as with user accounts, do not automatically delete IoT device accounts. Consider maintaining those accounts in a suspended state in case data tied to the accounts is required for forensic analysis at a later time.

Account / credential deactivation/ deletion

Deleting accounts used by IoT devices and the services they interact with will help combat the ability of an adversary to use those accounts to gain access after the devices have been decommissioned. Keys used for encryption (whether network or application) should also be deleted to keep adversaries from decrypting captured data later using those recovered keys.

Authentication credentials

IoT messaging protocols often support the ability to use different types of credentials for authentication with external services and other IoT devices. This section examines the typical options available for these functions.

Passwords

Some protocols, such as MQTT, only provide the ability to use a username/password combination for nativeprotocol authentication purposes. Within MQTT, the CONNECT message includes the fields for passing this information to an MQTT broker. In the MQTT version 3.1.1 specification defined by OASIS, you can see these fields within the CONNECT message (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html):

Note that there are no protections applied to support the confidentiality of the username/password in transit by the MQTT protocol. Instead, implementers should consider using the Transport Layer Security (TLS) protocol to provide cryptographic protections.

There are numerous security considerations related to using a username/password-based approach for IoT devices. Some of these concerns include:

• Difficulty in managing large numbers of device usernames and passwords
• Difficulty securing the passwords stored on the devices themselves
• Difficulty managing passwords throughout the device lifecycle

Though not ideal, if you do plan on implementing a username/password system for IoT device authentication, consider taking these precautions:

1. Create policies and procedures torotate passwords at least every 30 days for each device. Better yet, implement a technical control wherein the management interface automatically prompts you when password rotation is needed.
2. Establish controls for monitoring device account activity.
3. Establish controls for privileged accounts that support administrative access to IoT devices.
4. Segregate the password-protected IoT devices into less-trusted networks.

Symmetric keys

Symmetric key material may also be used to authenticate. Message authentication codes (MACs) are generated using a MAC algorithm (such as HMAC and CMAC) with a shared key and known data (signed by the key). On the receiving side, an entity can prove that the sender possessed the preshared key when its computed MAC is shown to be identical to the received MAC. Unlike a password, symmetric keys do not require the key to be sent between the parties (except ahead of time or agreed on using a key-establishment protocol) at the time of the authentication event. The keys will either need to be established using a public key algorithm, input out of band, or sent to the devices ahead of time, encrypted using key encryption keys (KEKs).

Certificates

Digital certificates, based on public keys, are the preferred method of providing authentication functionality in the IoT. Although some implementations today may not support the processing capabilities needed to use certificates, Moore's law for computational power and storage is fast changing this.

X.509

Certificates come with a highly organized hierarchical naming structure that consists of organizations, organizational units, and distinguished names(DNs) or common names(CNs). Referencing AWS support for provisioning X.509 certificates, we can see that AWS allowsone-click generation of a device certificate. In the following example, we generate a device certificate with a generic IoT device common name and a lifetime of 33 years. The one-click generation also (centrally) creates the public/private key pair. If possible, it is recommended that you generate your certificates locally by generating a key pair on the devices and uploading a CSR to the AWS IoT service. This enables thecustomized tailoring of the certificate policy in order to define the hierarchical units (OU, DN, and so on) that are useful for additional authorization processes.

IEEE 1609.2

The IoT is characterized by many use cases involving machine-to-machine communication, and some of them involve communications through the congested wireless spectrum. Take connected vehicles, for instance: an emerging technology wherein your vehicle will possess onboardequipment(OBE) that frequently automatically alerts other drivers in your vicinity to your car's location in the form of basic safety messages(BSM). The automotive industry, the US Department of Transportation (USDOT), and academia have been developing CV technology for many years, and it will make its commercial debut in the 2017 Cadillac. In a few years, it is likely that most new US vehicles will be outfitted with the technology. It will not only enable vehicle-to-vehicle communications but also vehicle-to-infrastructure (V2I) communications to various roadside and backhaul applications. The Dedicated Short Range Communications (DSRC) wireless protocol (based on IEEE 802.11p) is limited to a narrow set of channels in the 5-GHz frequency band. To accommodate so many vehicles and maintain security, it was necessary to secure the communications using cryptography (to reduce malicious spoofing or eavesdropping attacks) and minimize the security overhead within connected vehicles' BSM transmissions. The industry resolved to a new, slimmer, and sleeker digital certificate design: IEEE 802.16.

The 1609.2 certificate format is advantageous in that it is approximately halfthe size of a typical X.509 certificate while still using strong, elliptic curve cryptographic algorithms (ECDSA and ECDH). The certificate is also useful for general machine-to-machine communication through its unique attributes, including explicit application identifier (SSID) and credential holder permission (SSP) fields. These attributes can allow IoT applications to make explicit access-control decisions without having to internally or externally query the credential holder's permissions. They're embedded right in the certificate during the secure, integrated bootstrap and enrollment process with the PKI. The reduced size of these credentials also makes them attractive for other, bandwidth-constrained wireless protocols.

Biometrics

There is work being done in the industry today on new approaches that leverage biometrics for device authentication. The FIDO alliance (www.fidoalliance.org) has developed specifications that define the use of biometrics for both a passwordless experience as well as for use as a second authentication factor. Authentication can include a range of flexible biometric types, from fingerprints to voiceprints. Biometric authentication is being added to some commercial IoT devices (for example, consumer door locks) already, and there is interesting potential in leveraging biometrics as a second factor of authentication for IoT systems.

As an example, voiceprints can be used to enable authentication across a set of distributed IoT devices such as roadside equipment(RSE) in the transportation sector. This would allow an RSE tech to access the device through a cloud connection to the backend authentication server. Companies like Hypr Biometric Security (https://www.hypr.com/) are leading the way toward using this technology to reduce the need for passwords and enable more robust authentication techniques.

New work in authorization for the IoT

Progress toward using tokens with resource-constrained IoT devices has not fully matured; however, there are organizations working on defining the use of protocols such as OAUTH 2.0 for the IoT. One such group is the Internet Engineering Task Force (IETF), through the Authentication and Authorization for Constrained Environments (ACE) effort. ACE has specified RFC 7744,Use Cases for Authentication and Authorization in Constrained Environments (https://datatracker.ietf.org/doc/rfc7744/). The RFC use cases are primarily based on IoT devices that employ CoAP as the messaging protocol. The document provides a useful set of use cases that clarify the need for a comprehensive IoT authentication and authorization strategy. RFC 7744 provides valuable considerations the for authentication and authorization of IoT devices, including these:

• Devices may host several resources, wherein each requires its own access-control policy.
• A single device may have different access rights for different requesting entities.
• Policy decision points must be able to evaluate the context of a transaction. This includes the potential for understanding that a transaction is occurring during an emergency situation.
• The ability to dynamically control authorization policies is critical to supporting the dynamic environment of the IoT.

IoT IAM infrastructure

Now that we have addressed many of the enablers of identity and access management, it is important to elaborate on how solutions are realized in infrastructures. This section is primarily devoted to public key infrastructures(PKIs) and their utility in securing IAM deployments for the IoT.

802.1x

802.1x authentication mechanisms can be employed to limit IP-based IoT device access to a network. Note though that not all IoT devices rely on the provisioning of an IP address. While it cannot accommodate all IoT device types, implementing 802.1x is a component of a good access-control strategy that addresses many use cases.

Enabling 802.1x authentication requires an access device and an authentication server. The access device is typically an access point and the authentication server can take the form of a RADIUS or authentication, authorization, and accounting(AAA) server.

Summary

This articleprovided an introduction to the infrastructure components required for provisioning authentication credentials, with a heavy focus on PKI. A look at different types of authentication credentials was given and a new approaches to providing authorization and access control for IoT devices were also discussed.

Resources for Article:

Further resources on this subject:

• Internet of Things with BeagleBone [article]
• The Internet of Things [article]
• Internet of Things with Xively [article]