547,427 active members*
1,794 visitors online*
Register for free
Login Register

Perfection in Protection, Licensing, and Security

It is time for those in the IoT arena to “Up Their Security Game”. Here’s why…

March 2020
Author: med_wibu-systems
It is time for those in the IoT arena to “Up Their Security Game”. Here’s why…

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.

Blog Archiv

September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
October 2016
September 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016