IoT devices have long passed through the “early adopter” phase and should no longer be considered as new or emerging technologies. Such “things” as smart doorbells, smart surveillance cameras, smart coffee makers and even smart toilets have gained wide-spread adoption among consumers worldwide. The promises of more convenience and better use of time have been realized by many of these consumer “things”.
However, there are now enough smart devices in consumer’s homes that we are starting to hear more than a few horror stories about hackers gaining unauthorized access to these devices and causing mischief, if not outright fear. Popular Mechanics reported in a December 16, 2019, article an instance where some sort of racist creep had a verbal exchange with an eight-year-old girl when she noticed the blue light blinking on the security camera installed in her bedroom. (The blinking blue light meant someone was watching her.) The parents were horrified when they replayed the recording of the verbal exchange. Apparently, the hacker was able to access the camera because “non-secure passwords, reused too many times left the security service vulnerable”. Further, it appears this hack was endemic and not the result of user error caused by this little girl’s parents.
As nauseating and troublesome as these stories are, they pale in comparison to what havoc might be wrought if the “thing” hacked is a train traffic sensor… instead of a Ring doorbell or an Alexa microphone.
Asking, or even requiring, users of “things” to change default passwords is a solution for the last decade and is not good security practice for the 2020s. Two-factor authentication and the use of public/private key exchanges are among the technologies that should become mandatory for “things” designed for Healthcare, Smart Cities or any IoT device sold into the manufacturing or public service sectors. Such security technology should be designed into these devices… beginning now.
Marcellus Buchheit, CEO at Wibu-Systems USA, Inc. and a member of the IIC Security Committee’s Trustworthiness Task Group, said the IIC has designated, in a recent report, several technologies mature enough for immediate implementation. They include:
Secure Communications
A secure end-to-end communications protocol stack is required, including as appropriate:
- Support for extensible authentication protocols with endpoint level non-repudiation or authentication,
- Support for cryptographically protected endpoint-to-cloud connectivity, when appropriate,
- Support for cryptographically protected endpoint-to-endpoint connectivity (for example based on standards-based group key PKI for key lifecycle management),
- Trusted data transport based on secure public-private key pairs (PKI), and use of modern quantum resistant cipher suites.
Cryptographic Services
Comprehensive endpoint security requires proper use and implementation of cryptography across transport protocols (data-in-motion), storage (data-at-rest), and applications (data-in-use). Confidentiality and integrity should be protected with:
- PKCS standards-based asymmetric and symmetric cipher suites, hashing functions, and random number generators of appropriate strength,
- NIST/FIPS standards-based validated cryptographic algorithm implementations,
- Cryptographic algorithm agility with in-field upgrade capability, especially in light of the rise of quantum computing and the expected need to deploy post-quantum cryptography,
- Dynamically deployed policy-based control of application use of cryptographic functions based on permissible cipher algorithms and suites and
- Interoperability of cryptographic key types and certificates across multi-vendor systems, as needed to enable secure communications within an ecosystem.
Secure Boot
Secure boot attestation of the firmware (immutable or cryptographically protected bootstrap code executed at power on) and UEFI or U-Boot bootloaders for multi-stage boot may be performed using PKCS standards based cryptographic key hashes.
Root of Trust
Each endpoint contains a Root of Trust (RoT) that forms the basis for the endpoint’s security. For enhanced or critical security levels, the RoT should be implemented in hardware (SLE, SLC).
FURTHER, devices should be designed so that security update patches can happen automatically.
IoT manufacturers need to design several security layers into their devices; not just for market advantage. But because, the reality is, the regulatory climate in many jurisdictions is undergoing changes that will mandate new levels of security compliance. The wise company will be ahead of these regulators.
