On October 21, 2016, the Internet saw a significant distributed denial of service (DDoS) attack, conducted via a botnet comprising many co-opted Internet-connected devices. The attackers of the network infrastructure were able to control these Internet-of-Things (IoT) devices for a number of reasons, including a lack of strong authentication. Loaded software turned the machines into puppets that interfered with Internet traffic for millions of users.

Analysts estimate that between 20-40 billion devices will be connected to the Internet by 2020. In order to prevent technology takeovers, we need to take several steps to implement confidentiality, integrity, and availability (known as the “CIA” of computer security) for our IoT networks. A previous Sensor Technology article (October 2016) addressed encryption as a means to implement data confidentiality. In this month's article, we will focus on digital certificates, digital signatures, and code-signing techniques as a way of addressing availability and authentication.

Digital Certificates

A digital certificate is an electronic means of asserting the identity of computers, individuals, or other entities on the network. The digital “passport” is both unique and unforgeable. Typically, certificates include a public encryption key and the identity of the owner.

The certificates are generally issued by an entity known as a Certificate Authority (CA). The CA must validate the identity of the certificate owner before issuing the certificate, as well as when the certificate is used as an identification mechanism.

Most of us encounter certificates daily, although we may not be aware of it. Certificates are the basis of trust in our Web browsers, to ensure that sites like Amazon, Google, or Microsoft are the legitimate destinations and not man-in-the-middle attempts to get your user ID and password. The certificates are stored on your computer, and the Web browser often comes with several certificates pre-installed. The secure socket layer (SSL) / transport layer security (TLS) certificates are used whenever a secure “https://” link is established between your browser and the destination Web site.

Certificate Request and Distribution Structure.

A CA entity, usually a trusted third party, verifies the certificate holder's identity before issuing the certificate. The original certificate creation request comes into the CA via a front-end known as a registration authority (RA). Once the identity is verified, the CA generates the certificate and stores it in a certificate repository (CR) for subsequent attestation requests. Future attestation requests will then verify the authenticity of the certificate being questioned against the certificate stored in the CR. This structure can be seen in Figure 1.

Once verified by the CA, the requestor has some level of trust that can be associated with the certificate holder, based on the capabilities indicated in the certificate itself:

  • Encryption: The certificate includes cryptographic keys for use in data encryption/decryption (the public key of the certificate holder).
  • Signature: The certificate contains cryptographic keys that are valid only for verifying a digital signature.
  • Signature and Encryption: The certificate contains keys that are valid for both encryption/decryption of data, verification of a signature, and initial logon using a physical token such as a smartcard.
  • Signature and Smartcard Logon: A certificate with this capability allows for logon with the use of a smartcard and digital signatures, but not the ability to encrypt/decrypt data.

The longer a secret is in use, the more likely that secret will be compromised. The same is true of the use of private-public keys. Certificates can be associated with a valid date, and revoked accordingly. After a defined time, the certificate can “time out” and require a new certificate to be generated with a new set of private-public keys. Also, if the private keys are known to be compromised, the certificate can be placed in the Certificate Revocation List (CRL) maintained by the CA. Then, using the Online Revocation Protocol or the Online Certificate Status Protocol, devices such as sensors can examine a presented certificate to determine its validity.

In order to apply the CA approach to an IoT sensor network and ensure system integrity, we will need to generate, store, and maintain the certificates. Typically, for an IoT sensor system, such as what might be found at a factory with complex processes, we will want to replicate the CA structure within the facility. A CA-like entity will minimize communication delays for critical real-time processes as well as restrict access from outsiders.

Digital Signatures and Code Signing

We often find ourselves in the position of needing a legal signature on a document. A digital signature avoids the costly process of packaging and sending documents via courier, and provides a legally binding way to verify the documents digitally for electronic transfer. The digital signature, an optional extension to the digital certificate, turns the public-private key concept on its head.

In this usage, if person “Bob” wants to send a digitally signed document to person “Alice,” he would first create the message and compute a cryptographic hash of the message. This hashing algorithm, a one-way function, will not permit the extraction of the message from the hash itself. Additionally, any changes to the message will result in a completely different hash result. Typical cryptographic hash functions include the HMAC-SHA-256 and HMAC-SHA-512, with a 256-bit and 512-bit resulting hash respectively. The message hash (also known as a message digest) is then encrypted with Bob's private key, and the message and encrypted digest are forwarded to Alice.

Next, Alice computes the cryptographic hash on the message and decrypts the encrypted hash that Bob sent using Bob's public key. This key can be retrieved from Bob's digital certificate. If the two hashes match, then Alice knows two pieces of information: The message has not been modified, and Bob was the originator of the message (since only Bob has his private key). This process can be seen in Figure 2.

In a similar fashion, we can apply the digital signature concept to a software update. That is, we package the software update and compute the cryptographic hash of the software blob. Then, the developer encrypts the message hash with a private key, creating a signed collection of software. The receiving system can then calculate the hash of the blob and compare it to the cryptographic hash supplied by the developer, after decrypting the hash with the developer's public key. If the hashes match, then the software is intact and was generated by the specified developer.

The technique is commonly used in software update repositories for operating systems such as Linux, Windows, and OS/X. Without this sort of approach, malicious actors could install arbitrary code on a platform or conduct denial-of-service attacks against other systems.

Given that software is written by humans, it is unlikely that the code running on sensors will be error free. Because software updates are a foregone conclusion, code signing techniques are critical for IoT devices controlling critical processes within a factory setting. Otherwise, outside entities could potentially load malicious code onto the sensors, which would either result in a denial of service or in the interference with a facility's critical controls.

Combining Technologies for the IoT

With this background, let's imagine an IoT scenario: Our remote sensor in the oil distillation facility needs to communicate with the command and control (C2) facility. First, we can use encryption to secure the communications links. Mere encryption, however, is not enough to ensure secure operations. We must also:

  • Authenticate any commands coming from the C2 facility, to validate that the command is legitimate.
  • Authenticate that the sensor is, in fact, a legitimate device in the network, and not a malicious third party injecting false readings.
  • Determine if a fellow sensor has been compromised, and isolate that device from the network.
  • Attest to the validity of software updates.

The sensors will often come from the supplier with no security credentials installed, and will therefore need to be provisioned with network addresses and identifications before being sent to the field for installation. The facility's security personnel must first take each sensor unit and examine it for obvious signs of tampering, such as an opened box or extraneous wires on the device.

Bob sends a signed message to Alice.

After inspection, we need to generate a unique certificate for the device and store the information into the certificate repository. We would typically use some unique characteristic of the device, such as an embedded serial number, as the identity or seed for the certificate. The certificate would be transferred to the device, along with the certificate for the facility's C2 operations computers. In this case, the command and control facility becomes the CA for the system, so the sensors do not need to send traffic across the Internet to contact the CA for authentication.

The wireless radios for the sensors may provide link encryption for the unit. We're interested, however, in end-to-end (i.e., application-to-application) security. If we pre-store a certificate on each device before it is shipped, we can establish some preliminary authentication based on the certificate created from some immutable characteristic of the unit itself, such as a universally unique identifier (UUID). The 128-bit number, combined with the use of the Datagram Transport Layer Security (DTLS) protocol, would allow the security mechanisms to be verified on small, resource-constrained devices. DTLS, a lighter-weight version of TLS, uses UDP/IP instead of the larger TCP/IP stack, thereby saving memory resources.

Therefore, both commands from the C2 facility as well as sensor readings from the sensors themselves can be authenticated via the DTLS transfer, using the certificates as the basis of trust. Before accepting any communications for neighboring sensors or from the C2 facility, the sensors can also periodically check into the Certificate Revocation List to see if there are any sensors whose certificates have been revoked.

After sensor authentication, the fourth goal, validating software updates, requires the digital signature to be applied to the software using the C2 facility's certificate. If the hash of the software matches the decrypted hash of the code from the source certificate, then the software is intact and authenticated for update on the sensor device.

Summary

In this article, we have outlined the concepts behind digital certificates, digital signatures, and code signing. These concepts apply to all computers, not just the IoT. With the potential of thousands of sensors in a given facility, however, the need for authentication and secure code updates cannot be underestimated. For an IoT project, addressing security concerns during the design phase will be time well spent, and certificates are an important part of that effort.

This article was written by Mike Anderson, CTO and Chief Scientist for The PTR Group, Inc. (Ashburn, VA). With over 35 years in the embedded and real-time computing industry, Mike works with a number of applications ranging from satellites and robotics to SCADA platforms. His recent focus has been the use of Linux and Android in embedded sensor applications and the deployment of the Internet of Things. For more information, Click Here .


Sensor Technology Magazine

This article first appeared in the March, 2017 issue of Sensor Technology Magazine.

Read more articles from this issue here.

Read more articles from the archives here.