Practical Industrial Internet of Things (Industrial IoT) Security: How to make IIoT secure

This practical Industrial IoT is a guide about how to make IIoT secure

Learn about authentication and authorization frameworks for IIoT in this guest post by Sravani Bhattacharjee, the author of Practical Industrial Internet of Things Security.

While evaluating the practical applicability of IT-based authentication and authorization techniques for IIoT use cases, it is important that you keep in perspective the unique demands of the cyber-physical world.

The following figure summarizes the three main approaches of authentication:

Access security mechanism

Password-based authentication

Password-based authentication is the most widely used proof of identity for people to interact with a device or a system. It belongs to the “something I know” bucket as shown in the above diagram, and allows managing multiple levels of account privileges. In addition to the client-server applications, passwords are also used as secrets for securing access to operating system resources.

Many consumer and industrial IoT products manufactured today have factory default passwords. Default passwords are usually easy-to-guess phrases (such as password123), and are meant to be replaced by stronger passwords when the device has been deployed. Historically, these default passwords have often given the device owners/administrators a false sense of security, meaning that they fail to replace the factory default password.

Most security breaches where compromised IoT devices are used as attack vectors trace back to default password exploits. Some security experts are of the opinion that, from a security perspective, it may serve the world well if manufacturers discontinue the practice of providing default passwords, thereby mandating that administrators provision new passwords.

Some of the IoT messaging and communication protocols have built-in support for password-based authentication. MQTT, a publish/subscribe messaging protocol designed mainly for scalable IoT infrastructures, has username/password fields in its CONNECT message (OASIS-OPEN). MQTT handles these fields in plaintext. So, for ensuring cryptographic security, TLS needs to be used in conjunction.

However, password-based authentication was never designed for the M2M world and, as such, this method presents multiple challenges for IIoT deployments. Some of the concerns are as follows:

• Scalability: Provisioning and managing usernames and passwords for a very large number of devices is a practical hurdle—both in terms of effort and accuracy.
• Managing passwords: It is hard to automate the initial deployment and periodic password updates in highly scaled use cases.
• Secured storage: Securely storing the passwords as secrets in the device is not easy and provides a backdoor for intrusion.
• Defaulter syndrome: When the barriers are high, operators rely on default options and do not bother to override the factory-default passwords. However, the rise of IoT botnets proves the bad consequences of using default passwords.

In some small-scale and less vulnerable deployments, password-based authentication may still be applicable. If used, the following precautions must be taken:

• Implement password rotation policies in 30 or 40-day cycles for each device. Consider augmenting these policies with an alert mechanism that automatically prompts administrators when password updates for a group of devices are due.
• Establish event logging to monitor device account activity.
• Create privileged accounts to support administrative access to IoT devices.
• Segregate the password-protected IoT devices onto less trusted networks.
• Create a policy that disallows default passwords and enforces password strength requirements.
• Ensure password encryption is implemented in the transport layer.

Biometrics

The use of biometrics as an authentication factor is becoming more and more common. Biometrics not only provides the convenience of password-less authentication, but can also be used as a second factor in multi-factor authentication schemes. Fingerprints, facial geometry, voiceprints, etc. are various unique attributes used in biometrics-based authentication.

It is true that biometrics comes into play in human-to-machine interfaces, for example, to authenticate an operator who accesses machines and resources. Consider the example of the transportation sector, where a field technician wants to repair a piece of roadside equipment (RSE). The technician can use voiceprints to access the device through a cloud connection to the backend authentication server (IOT-SEC).

So, in industrial IoT IAM strategies, biometrics is to be considered in conjunction with other schemes used for device authentication.

Biometric authentication involves a centralized biometric server that stores biometric data associated with various users. This database is used by the biometric authenticator. Having a centralized authentication has the vulnerability of being the single point of failure in the case of a malicious attack that targets this sensitive biometric data.

Biometric security companies such as Hypr (www.hypr.com) are promoting the concept of decentralized biometric tokenization. In a decentralized architecture, no two persons’ biometric data is stored on the same server. Biometric tokenization allows the biometric data to be translated into a random token for safe storage on a user’s mobile device.

A cryptographic challenge-response function allows an action-specific or timestamped verifier to be drawn from the biometrics and sent via the cloud or local server to activate the login, vehicle start, or any other function the mobile app is designed to perform. The blockchain technology is also increasingly being considered to develop decentralized biometrics solutions.

Biometrics-based security, also known as Bio-T, is finding faster adoption in the consumer IoT use case, which includes keyless home and automotive access, biometric locks, and so on. The FIDO alliance (www.fidoalliance.org) has developed the open standards that define the use of biometrics-based authentication.

Multi-factor authentication

At the beginning of this section, you saw three common authentication factors. Authentication using any one of these factors is no doubt useful, but single-factor authentication has the vulnerabilities associated with the corresponding authentication factor it uses. For example, an attacker can compromise a password by launching a dictionary attack. However, if the authentication process requires two different authentication factors, such as a password and a smart-card-generated one-time token, the chances of a breach are drastically decreased. This illustrates the value of implementing multi-factor or two-factor authentication.

Multi-factor authentication is widely used in client-server sessions, and is also recommended for edge to cloud communications. IoT cloud providers such as AWS and Microsoft Azure use multi-factor authentication (primarily in human-to-machine use cases).

Key-based authentication

Key-based authentication is a fully automated authentication technique wherein encryption keys are used as secrets. This method heavily relies on cryptographic algorithms. Before discussing key-based authentication, you must understand some key cryptography concepts.

Cryptography utilizes encryption algorithms to perform two basic operations:

1. Encryption: Converts information from its plaintext form into an encrypted version, known as ciphertext, using encryption keys
2. Decryption: Performs the reverse transformation, to transform the encrypted ciphertext back into the plaintext format

One of the challenges in choosing the right encryption algorithm is in determining the length of the key or key pair used for encryption and decryption without compromising key strength (in terms of resilience). Longer keys ensure greater security, as shown in the following graph:

But this benefit comes at the expense of performance; longer keys involve greater resource consumption. In resource-constrained environments, this is a major consideration. Based on the security goals of a specific use case, it is recommended to determine the cost per key (cost/key) of the encryption algorithm in addition to its encryption/decryption speed, memory, CPU, and power usage.

Another point to consider is the type of cryptography to implement. Depending on the usage of keys and key exchange mechanism, there are two main categories of key-based authentication, as discussed in the coming sections.

Symmetric keys

In symmetric key cryptography, the sender and receiver share a common secret to encrypt and decrypt messages. Unlike a password, in symmetric key-based authentication, keys are not required to be sent between the parties at the time of the authentication event. The keys are usually established before a session is initiated using a public key algorithm. The key is sent either out-of-band, or ahead of time to the devices, encrypted using key encryption keys(KEK). The following diagram shows the workflow involved in symmetric key-based cryptography:

There are multiple symmetric encryption algorithms that use block or stream ciphers. The Advanced Encryption Standard (AES), considered a secured algorithm, is commonly used and offers 128, 192, and 256-bit keys. Blowfish and Twofish are also block cipher symmetric algorithms. RC2 is a stream cipher-based symmetric key algorithm used in network communications. Wi-Fi, WEP, and TLS standards allow the use of RC2.

The benefits of symmetric key encryption depend on the specific implementation. The following are some of the generic benefits touted by symmetric key solution vendors:

• Simpler to provision and revoke
• Easier to protect while being used
• Faster speed of execution
• Lower power, memory, and CPU usage (compared to RSA and ECC)
• Lower cost per key

A drawback of the symmetric-key-based approach is that the number of keys increases exponentially with the number of parties involved, as shown in the following image:

Asymmetric keys

Asymmetric cryptography, also known as public key cryptography, solves the scalability problem of symmetric cryptography by issuing a pair of keys—one private and one public—to each participant. As shown in the following figure, in public key cryptography, a key pair is used, one of which is published, the other of which is used by the receiver as a secret and used only for decryption. The robustness of the public key-based approach depends on the degree of computational difficulty in deriving the private key using the public key:

One of the most common asymmetric key algorithms in use today is RSA, where a key pair (one public and one private) is generated to initiate communication. RSA utilizes two very large randomly generated prime numbers to calculate the key pair, and uses variable length keys ranging between 1,024 and 4,096 bits. As long as the private key is kept secure, decrypting the message is very unlikely.

Elliptic curve cryptography (ECC) is another asymmetric algorithm. Instead of the prime factorization problem, it uses the elliptic curve discrete logarithm problem. ECC is more resource-efficient and hence more applicable to resource-constrained edge devices.

Asymmetric cryptography is based upon the difficulty of solving complex mathematical problems. In the case of the RSA algorithm, the security of the algorithm depends upon the difficulty of factoring the product of two large prime numbers.

For the same reason, they provide higher confidentiality of the encrypted message. Also, non-repudiation is possible only with asymmetric cryptography. These benefits, however, come at the cost of slower speed and intensive use of power and computational resources.

Zero-knowledge keys

In IEEE P1363.2, the term zero-knowledge password proof (ZKPP) is used to explain the concept wherein party-1 (the prover) proves to party-2 (the verifier) that it knows a value of a password, without revealing the password itself to the verifier. This scheme is mainly designed to protect against dictionary attacks. The concept of zero-knowledge keys is similar, but not limited to passwords only.

The concept of proving the knowledge of an assertion without revealing any information about the assertion itself offers benefits over existing options such as shared key and public key cryptography.

In shared key cryptography, two parties agree on a common secret before they begin any communication. As discussed in the Password-based authentication section, this approach is vulnerable to eavesdropping, spoofing, and dictionary attacks. In public key cryptography, a key pair is used, one of which is published and the other is used by the receiver as a secret and used only for decryption. The robustness of the public key approach depends on the degree of computational difficulty of deriving the private key using the public key.

In zero-knowledge cryptography, the prover is able to prove its knowledge of the secret to the authenticator without having to reveal the secret itself at any time during the operations. The authenticator can ask questions to confirm the prover indeed knows the secret, but it is impossible for the authenticator or any third party to discover information about the secret.

As long as the authentication messages are handled securely, an eavesdropper can’t learn anything about the secret or convince any party that they know the secret. A good zero knowledge-based protocol should also be resilient against a malicious man-in-the middle who might try to send, modify, or destroy the message (SANS-1).

Scalability and cryptographic resilience of zero-knowledge keys make them relevant in IIoT IAM considerations. This approach is particularly attractive in proving mutual identity, or during the key-exchange step of a cryptographic application.

Some IIoT identity vendors are already using zero-knowledge key-based authentication services, wherein an IoT device uses the zero-knowledge key as proof of identity, without knowing the actual value of the key.

While using zero-knowledge key-based authentication, it is recommended to evaluate the complexity of the infrastructure matrix providing the service, resource requirements, ease of maintenance, and cost-effectiveness.

Certificate-based authentication

Certificate-based authentication goes a step further. It uses the public key cryptography framework, where the public key is signed by a trusted certificate authority (CA). The CA uses its private key to sign the requester’s public key. This assures the remote endpoint that the originating endpoint has the private key and also serves as the proof of identity. Certificate-based authentication may be used for mutual authentication of server-to-server or device-to-server connections.

From automation and scalability standpoints, public key-based digital certificates are a promising authentication method in IIoT use cases. Considering the resource-intensive nature of certificate-based authentication, using this technique in resource-constrained environments can be particularly challenging. However, with industry efforts focused to overcome these challenges, improvements can be expected.

If you found this article interesting and wish to explore more, you can refer to Practical Industrial Internet of Things Security. Written by Sravani Bhattacharjee, the book explains the key areas of IIoT security, safety and reliability implications, and the security challenges associated with IT/OT convergence.