[Nexus White Paper] IoT and IIoT Security_Zero Trust using Secure Device Identities

WHITE PAPER

IoT and IIoT security:

Achieving Zero Trust with Secure Device Identities

Introduction In IoT, IIoT, or industrial automation, it is all about connected devices: To create additional value with fleet-management, predictive maintenance, production automation, goods tracking, animal health monitoring, etc., small computing devices, sensors and actuators are connected to the Internet or to an industrial network and interchange data with each other or with IoT/IIoT services.

With connecting devices to networks, cybersecurity threats arise. Even OT networks are not natively secure against cyberattacks once they are connected to IT or use wireless communication, which do not respect the factory fence. An intruder can eavesdrop messages on a network and replay them (and by that, cause faulty actions in production), can impersonate a sensor or a controller (by that, start sending faulty sensor data and unauthorized commands to equipment), or can hijack a network device (and tamper with it or distribute malware to other devices). Criminal power and the ways of causing damages are seemingly infinite.

Figure 1. Possible sources of threat in a connected manufacturing environment

The origin of the security problem is that a connected device cannot easily distinguish an authorized, healthy (non-hacked) device from a rouge (hacked or hijacked) device. It cannot either easily recognize if a message is authentic (i.e., it comes from a true device) or it was created, manipulated, or simply resent with fraudulent purpose by a rouge device or malicious software running elsewhere in the network and impersonating a true device.

2

3

Zero Trust

Establishing secure communication

Security without a defined security perimeter can be achieved by a defensive ‘Zero Trust’ policy, which is promoted by security experts across industries. The Zero Trust principle can be translated into following design principles:

Authentication Giving evidence of identity (or of authorization) over a network is done by means of cryptographic authentication protocols. What is common across these protocols is that they all work with a secret.

In the simplest protocols, the secret is a password, which is shared by the authorized devices. The use of the shared secret is illustrated below in a simplified protocol:

• Assume the network is compromised, the enemy is in the network.

• No party shall trust any other communicating party unless it gives an unforgeable evidence of identity or authorization.

• Assign the necessary least privileges to the networking parties to do the work.

• Segment the network to minimize the effect of a breach.

• Have a plan to recover from compromise.

The Zero Trust principle obligates a device: • not to trust any communicating party being that it claims to be unless it gives proof • not to trust received data unless it can be verified that it is from an authorized source, is authentic (not manipulated), and is intentionally sent (not only a replay of an earlier message) • to assign only the necessary least privilege to the other party when serving the received request.

Read more about the motivation of “Zero Trust” here.

Figure 2. Identification and authentication using a shared secret

4

With help of the secret, the sender can prove its claimed identity ’Robot11’ and can also add a message authentication code (MAC) to the message it sends. In knowledge of the same secret, the receiver can verify the identity of the sender as well as the origin and integrity of the message. An intruder cannot generate this evidence. Replaying intercepted messages later would not work either, as the PLC’s MAC depends on the random challenge that Robot11 had sent earlier in the protocol.

Encryption For privacy or cybersecurity reasons, it is often desirable to send a confidential message, for example password or a secret key, to a device or to a service in an encrypted format, so that it cannot be intercepted by an intruder.

Using encryption, sensitive data can be sent securely over an untrusted network. The cryptographic encryption, too, needs the communicating endpoints to share a secret encryption key.

Once a secret is established for authentication, there are secure key exchange protocols and key derivation functions to exchange or derive another key for encryption.

How to share a secret?

There is “chicken-egg” issue with sharing a secret over an untrusted network: Initially, without a shared secret, it is not possible to securely send a secret to endpoints or for them to exchange one. Key exchange protocols (e.g., Diffie-Hellmann) enable two parties to negotiate a shared secret over a network without announcing the secret, but they assume that the parties have authenticated each other prior to key exchange. So, such protocols cannot establish a secret for authentication. As a matter of fact, it is impossible to provision or negotiate a secret in a secure way over an unauthenticated network.

Instead, some trusted “out-of-band” method must be used, that no malicious party can interfere with. In practice, an operator must execute a “physical touch” on the target devices. The physical touch can mean typing in the secret over the user terminal, carrying it on a USB stick between the devices or pressing buttons on the devices to perform “pairing” (i.e., key exchange) within a relatively short time window. All these methods are common on WLAN routers and devices.

Zero Touch provisioning with PKI PKI and Device IDs - the better way to create trust in a network Public key cryptography comes to help about the mentioned issues:

• With public key cryptography, there is no need to share secrets. A secret private key must be

stored only in the sending endpoint, while the receiving endpoint can use the corresponding public key to verify that the sender owns the private key. The public key need not be secret.

One only needs to make sure to store the right public key of the receiver, i.e., that the receiver holds an authentic copy of the public key of the sender. Managing public keys is much simpler than sharing secrets.

• In a Public Key Infrastructure (PKI), the public key of a device is included in a Device ID (a.k.a.

digital certificate). This Devie ID holds the device public key, its unique identifier (vendor ID and serial number, network adapter number, IPv6 address, or other), and the digital signature of the Certificate Authority (CA) that issued the certificate. With the signature, the CA attests that the device with the given identity physically holds the private key.

• During authentication, the sender presents its Device ID to the receiver. The receiver uses

the Device ID to verify that the sender indeed owns the corresponding private key and is the device named in the Device ID. It can rely on this proven identity to assign permissions to the sender. Finally, the receiver verifies the authenticity of the Device ID itself by means of the CA’s own public key or CA certificate.

• With the help of a Device ID, an encryption key can also be derived or agreed upon over an untrusted network.

• Note that pre-sharing all Device IDs in the network is not necessary, but only an authentic

copy of the CA certificate needs to be distributed to and stored in the endpoints. This highly simplifies the security management.

Figure 3. An operator performs manual pairing actions on devices

Figure 4. Establishing trust over a network with PKI

6

7

Zero Touch provisioning of a Device ID In relation to Device ID, one desired feature was not yet discussed: Can a Device ID be provisioned over an untrusted network with Zero Touch?

Let’s investigate this. The Certificate Authority that issues the Device ID (or a Registration Authority that submits the certificate request to the CA) must assure that: • the private pair of the certified public key is physically linked to (stored in) the intended device, and • the unique device identifier asserted in the certificate belongs to the same intended device.

This assumes that the true unique identity of the device can be determined or defined during the certification process.

Without the physical presence and a trusted (i.e., authenticated, not necessarily confidential) connection to the device, it is unfortunately impossible to assure these.

So, we face the same “chicken-egg” issue as with shared secrets: provisioning a Device ID requires • either a trusted network, or • “physical touch” (entry via user interface, provision via dedicated wired connection, e.g., USB, serial port, LAN port), or • some pre-provisioned authenticator (password, cryptographic key or Device ID) that can be used for authentication over the untrusted network.

Factory Device ID – Operator Device ID The best time to provision an initial Device ID is during manufacturing, where the device is in a trusted, managed environment and has a direct wired connection to trusted manufacturing equipment (e.g., a programming station). A Device ID provisioned at this time is called Initial Device ID (IDevID), Factory ID, Factory Certificate, Vendor Certificate, or Birth Certificate.

PKI in security standards for industry and IoT PKI and PKI-based digital identities have been widely used, mature technologies in citizen IDs, bank cards, IT, and the Web since decades. In particular, the combination of a Factory ID with an Operator ID is adopted by several industry standards in telecommunications, industry automation (IIoT) and IoT, for example.

• 3GPP Technical Specification TS 33.310: This specification introduced for the first time the use of a “vendor certificate” in LTE networking products and its remote replacement with an “operator certificate” in the MNO network upon installation.

• 802.1AR-2018 – IEEE Standard for Local and Metropolitan Area Networks – Secure Device Identity: This standard defines the Initial Device ID (IDevID) and the Local Device ID (LDevID) as introduced in this paper for the LAN context but is referenced by other standards below.

• Matter Specification: This interoperability specification applies to smart home devices and mandates a factory certificate (Device Attestation Certificate) to attest the device being a genuine, matter-certified device. During onboarding to a home network, the device receives an operator certificate (called Node Operational Certificate), which enables secure encrypted communication with (and only with) other devices within the same network.

• Open Platform Communications – Unified Architecture (OPC UA): One part of this specification describes an infrastructure service (Global Discovery Service) that helps secure automated onboarding of industrial equipment into an operator network.

• Lightweight Machine to Machine Technical Specification: This specification promotes certificate-based identities in low-powered, constrained sensor devices and their automatic (remote) management.

After the device is shipped from the manufacturer, it may pass several stages in the supply chain until it arrives at the ultimate operator, a business, or an end consumer. The operator installs the device and connects it to the local network or to the Internet. To distinguish the device from its factory mates and attach exclusive access rights to it for connecting to the operator’s network and service accounts, the operator may want to provision an Operator ID to the device using the Operator CA. This ID is also called a Local Device ID (LDevID). In the operator network (or the Internet), the Factory ID securely identifies and authenticates the device and enables Zero Touch provisioning of the Operator ID even over an untrusted network.

Figure 5. Using Factory ID for Zero Touch provisioning of Operator ID

8

9

Nexus’ proposition for IoT:

Factory CA – Operator CA Nexus offers PKI solutions for both the Factory CA and the Operator CA, which provide Secure Device Identities throughout the supply chain and the product lifecycle: The Factory CA typically needs to be established on the device manufacturing factory premises and connected directly to production equipment (such as a programming station). This is to avoid dependency on communication networks, which may lie beyond the control of the manufacturer, as well as to enable secure provisioning even within a factory site that is potentially not owned and controlled by the device manufacturer and, hence, cannot be trusted. The secure controlled zone in this case is the programming equipment and the Factory CA solution shall be hosted inside the programming system’s physical boundary. Nexus delivers a turn-key Factory CA solution based on agreed specification and including a Hardware Security Module (HSM) for the secure store and operation of the CA private key.

In another setup, a delegated Registration Authority server (the Factory RA) connects to the device and provisions the Factory ID. The Factory RA has a secure (authenticated and encrypted) network connection to the Factory CA, which may be hosted elsewhere in the factory or possibly operated in the cloud, such as in the Nexus GO IoT service.

About Nexus This white paper is authored by Nexus.

Nexus, part of IN Groupe, is a pioneer and leader in PKI and cryptography. We have stayed ahead of the curve by always anticipating and preparing for the next technological transformation. Our futureforward solutions create a trusted society by helping governments defend their sovereignty, en-abling enterprises to preserve their integrity, and empowering citizens to exercise their rights.

Nexus offers robust PKI solutions for both Factory and Operator CAs, ensuring secure device identities throughout the supply chain and product lifecycle. Whether you need a locally operated Factory CA or a cloud-based Operator CA, Nexus offers flexibility and high-security options tailored to your specific requirements. www.nexusgroup.com

If the IoT product is a consumer device or an Internet-connected industrial device, which needs to connect to cloud services, it may be most suitable to choose a cloud-based Operator CA, e.g., one operated in the Nexus GO IoT service. Nexus offers this high-security PKI service with full flexibility in view of certificate contents (cryptographic algorithms, device name attributes, validity, extensions), device pre-registration and certificate provisioning API, CA hierarchy, revocation service options, and certificate volumes.

In a closed industrial environment, such as an OT network, it may also be required to establish a locally operated Factory CA. Nexus can provide this as turn-key solution too.

Figure 6. Issuing and establishing trusted device identities

10

11

”

Our commitment to excellence and innovation drives us to build a secure tomorrow with trusted identities

”