In the midst of a continuous drumbeat of press stories on IoT cybersecurity vulnerabilities, a bill that surfaced in the U.S. Senate calling for IoT manufacturers to follow certain cybersecurity procedures gained a lot of attention. If it does pass, it could bring about some major changes to IoT device security, particularly in the way these devices are provisioned with certificates.
The bill in question is called the Internet of Things Cybersecurity Improvement Act of 2017. It would change U.S. federal government procurement standards to require a certain number of cybersecurity measures for IoT devices sold to the federal government. Specifically, it would require IoT devices to:
- Allow any preinstalled passwords to be easily updated by the end user
- Be free from any known vulnerabilities identified by the U.S. government
- Run on software/firmware that can be securely updated
- Use current industry standards for communications, encryption and interconnections with other devices
If passed, the act would likely affect many IoT products since there is a precedent for U.S. government procurement standards making a major impact on cybersecurity. In 1994, National Institute of Standards and Technology published the Federal Information Processing Standards (FIPS) 140 standard for cryptographic modules used by the U.S. government. Now in its second iteration, FIPS 140-2 certification is also often a requirement in cryptographic products used in private industry as well.
Mandating secure field certificate updates
If the bill is passed, one of the likely outcomes is that field updates for IoT device certificates will end up being mandated. Typically, when a user wants to install and/or administer an IoT device, they provide a valid username and password as their credentials in a login screen. When the device is first installed or if the password is compromised, the bill requires that a new password can be assigned. But there is more to be considered.
When an IoT device communicates with a cloud-based service, it typically uses an X.509 digital certificate as its authentication credential. Should the IoT device become compromised, its certificate can be put onto a certificate revocation list (CRL) which is maintained by the certificate provider, known as a certificate authority. When the cloud-based service receives the certificate from the IoT device, it checks the CRL and can deny access if the certificate is on the list. If this happens, how can a new certificate be assigned to the IoT device? IoT device manufacturers typically order their digital certificates in batches and install them on the factory floor, a process known as offline provisioning. The first certificate in the batch is assigned to the first device and marked as used, and then the process is repeated.
There are two problems with this process:
- Handling keys on the manufacturing floor could introduce a vulnerability. It is also tedious to keep track of them and to program each device with unique certificates.
- While the CRL is used by the cloud-based service to deny access to a compromised device, there needs to be a mechanism to reprovision the device with a new certificate if needed.
Advantages of online provisioning
Some certificate authorities overcome the limitations in offline provisioning with a technique known as online provisioning. Each batch of certificates is securely stored in a cloud-based service. An IoT device gets a specialized certificate called a bootstrap key installed when it is manufactured. When the device first boots, it communicates with the online provisioning service holding all of the certificates. The device provides its bootstrap key and other unique information, such as its serial number, Ethernet address and any number of name-value pairs. If this information checks out, the provisioning service delivers a valid certificate and associated private key to the device.
There are two advantages to this approach:
- Keys are not handled by manufacturing personnel and are automatically tracked by the provisioning service. This raises the security posture while simplifying the manufacturing process
- There are no hard-coded credentials because the certificate is assigned at first boot. Should a device become compromised, it can be overwritten with new software that, when booted again, would get a new, uncompromised certificate and associated private key.
Should the Senate IoT bill become law, IoT device manufacturers will be incentivized to include the ability to do field certificate updates, hopefully becoming an industry best practice. By making the certificate update process both simpler and more secure, IoT security as a whole can be improved, allowing all of us to rest a little easier at night.
All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.