The Top IoT Authentication Methods and Options

Gartner recently labeled Internet of Things Authentication as a high benefit in 2020 Gartner Hype Cycle for IAM Technologies. This blog covers your options for Internet of Things Authentication.

Want to read the report? Skip the blog and click ‘Download Report’ below.

IoT authentication is a model for building trust in the identity of IoT machines and devices to protect data and control access when information travels via an unsecured network such as the Internet. 

Strong IoT authentication is needed so that connected IoT devices and machines can be trusted to protect against control commands from unauthorized users or devices. 

Authentication also helps prevent attackers from claiming to be IoT devices in the hope of accessing data on servers such as recorded conversations, images, and other potentially sensitive information. 

There are several methods by which we can achieve strong authentication to secure IoT device communications: 

• One-way authentication: in the case where two parties wish to communicate with each other, only one party will authenticate itself to the other, while the other party will not be authenticated. 

• Two-way authentication: is also referred to as mutual authentication, in which both entities authenticate each other. 
• Three-way authentication: is where the central authority authenticates the two parties and helps them to authenticate each other. 
• Distributed: using a distributed straight authentication method between the parties to the communication. 
• Centralized: using a centralized server or a trusted third party to distribute and manage the authentication certificates used. 

The Internet of Things (IoT) is not just a single technology, but a connected environment of various machines (“things”) that work together independently – without human interaction. 

The authorization process is the tool used to validate the identity of each endpoint in the IoT system. The certification process is configured upon enrollment entry and informs the service provider of the method to be used when checking the system’s identity during registration. 

Machine Identity Management aims to build and manage confidence in a machine’s identity that interacts with other devices, applications, clouds, and gateways. 

This may include the authentication and authorization of IoT devices such as: 

• Industrial Control Systems 
• Connected medical devices 
• Vehicle ECUs (Engine Control Units) 
• Security cameras 

• Home security systems 
• Mobile devices 
• Smart speakers, lights, outlets, and other equipment. 

Each IoT machine needs a unique digital identity when connecting to a gateway or a central server to prevent malicious actors from gaining control of the system.  This is accomplished through binding an identity to a cryptographic key, unique per IoT device. 

• For trusted platform module (TPM) implementations, the registration ID is issued by the TPM itself. 
• For X.509 certificates, the registration ID is issued by a globally trusted Certificate Authority (CA). 

Machine identity management approaches are specifically responsible for discovering the credentials used by machines and the management of their life cycle. 

IoT devices are often hacked remotely, involving a hacker trying to enter the device using an internet connection. If an IoT device is only allowed to communicate with an authenticated server, any outside attempts to communicate will be ignored. 

According to the 2018 Symantec threat report, the number of IoT attacks increased by 600 percent between 2016 and 2017, from 6,000 to 50,000 attacks, respectively. 

Therefore, when IoT devices are implemented within corporate networks, , security needs to be given much more attention. To address this issue, powerful but efficient cryptography solutions must be used to standardize secure communication between machines. 

However, it is a tough decision to choose the right IoT authentication model for the job. Before deciding which architecture model is ultimately the best IoT authentication, you need to consider several factors, such as energy resources, hardware capacity, financial budgets, security expertise, security requirements, and connectivity. 

The X.509 protocol (IETF RFC 5280) provides the most secure digital identity authentication type and is based on the certificate chain of trust model. The use of X.509 certificates as a certification mechanism is an excellent way to scale up production and simplify equipment delivery. 

Public key infrastructure (PKI) consists of a tree-like structure of servers and devices that maintain a list of trusted root certificates. Each certificate contains the device’s public key and is signed with the CA private key. A unique “thumbprint” provides a unique identity that can be validated by running a crypto algorithm, such as RSA. 

Digital certificates are typically arranged in a chain of certificates in which each certificate is signed by the private key of another trusted certificate, and the chain must return to a globally trusted root certificate. This arrangement establishes a delegated chain of trust from the trusted root certificate authority (CA) to the final entity “leaf” certificate installed on the device through each intermediate CA. 

It requires a lot of management control, but there are many vendor options out there. 

However, X.509 certificate lifecycle management can be a challenge due to the logistical complexities involved and comes at a price, adding to the overall solution cost. For this reason, many customers rely on external vendors for certificates and lifecycle automation. 

The Hardware Security Module, or HSM, is used for secure, hardware-based device secret storage and is the safest form of secret storage. Both the X.509 certificate and the SAS token can be stored in the HSM. HSMs may be used with the two attestation mechanisms supported by the provisioning service. 

Alternatively, device secrets may also be stored in software (memory) but is a less secure form of storage compared to an HSM. 

It is essential to check the device’s identity that communicates with the messaging gateway in IoT authentication deployments. The usual method is to generate key pairs for devices that are then used to authenticate and encrypt traffic. However, the disk-based key pairs are susceptible to tampering. 

TPMs come in a number of different forms, including: 

• Discreet hardware devices 
• Embedded hardware equipment 
• Implementation of firmware 
• Implementation of software 

While a typical TPM has several cryptographic capabilities, three key features are relevant to IoT authentication: 

• Secure boot-up 
• Establishing the root of trust (RoT) 
• Identification of device 

Device manufacturers cannot always have full confidence in all entities in their supply chain (for example, offshore assembly plants). Still, they cannot give up the economic benefits of using low-cost suppliers and facilities. The TPM can be used at various points along the supply chain to verify that the device has not been incorrectly modified. 

The TPM has the capability to store the keys securely in the tamper-resistant hardware. The keys are generated within the TPM itself and are therefore protected from being retrieved by external programs. Even without harnessing the capabilities of a trusted hardware root and a secure boot, the TPM is just as valuable as a hardware key store. Private keys are protected by hardware and offer much better protection than a software key. 

With TPM, you can’t roll the key without destroying the identity of the chip and giving it a new one. It’s like if you had a clone, your clone would have the same physical characteristics as you, but they’re a different person in the end. Although the physical chip remains the same, your IoT solution has a new identity. 

Some key differences between TPMs and symmetric keys (discussed further below) are as follows: 

• TPM chips can store X.509 certificates as well. 
• The TPM certificate in the Device Provisioning Service uses the TPM endorsement key (EK) which is a form of asymmetric authentication, while the symmetric keys are symmetric authentication. 
• TPM certification is more secure than SAS token-based symmetric key attestation. 
• Difficult to develop without either a physical TPM or a quality emulator. 
• May require a redesign of the board to be included in hardware. 
• New IoT devices should be fundamentally designed to support a TPM. 

Symmetric Key Certification is a simple approach to authenticating a device with a Device Provisioning Service instance. This certification method is the “Hello World” experience for developers who are new to or do not have strict safety requirements. Device attestation using a TPM or an X.509 certificate is more secure and should be used for more stringent safety requirements. 

Symmetric key enrollments also provide a great way for legacy devices with limited security features to boot into the cloud via Azure IoT. 

The symmetric key attestation with the Device Provisioning Service is carried out using the same security tokens supported by IoT hubs to identify the devices. These security tokens are SAS (Shared Access Signature) tokens. 

SAS tokens have a hashed signature created using a symmetric key. The signature shall be recreated by the Device Provisioning Service to verify whether or not the security token presented during the certification is authentic. 

When the device certifies with an individual enrollment, the device uses the symmetric key defined in the individual enrollment entry to create a hashed signature for the SAS token. 

Shared symmetric keys may be less secure than X.509 or TPM certificates because the same key is shared between the device and the cloud, which means that the key needs to be protected in two places. Designers using symmetric keys sometimes hardcode the clear (unencrypted) keys on the device, leaving the keys vulnerable, which is not a recommended practice 

Proper implementation of IoT authentication has many beneficial effects on IoT security. However, choosing the right method can be challenging, and the wrong choice can increase risks by tenfold. 

Some risks can be mitigated by securely storing the symmetric key on the device and following best practices around key storage, It’s not impossible, but when symmetric keys are used solely, they can be less secure then HSM, TPM, and X.509 implementations. 

In the case of certificates, HSM, TPMs, and X.509 applications, the main challenge is to prove possession of the key without revealing the key’s private portion.