The importance of end-to-end security schemes for IoT deployments
Identity is the key to secure projects
By Guillaume Crinon
In the world of IoT, security really comes down to identity.
We, as people, trust communication with other people or machines we don’t know by verifying the institution with which someone or something is aligned.
Say a citizen of Spain wants to travel to the United States. Because the U.S. trusts that EU-member Spain can issue reliable passports, the U.S. customs agent would simply trust a valid passport, authenticate it and confirm it matches the traveler—rather than calling Spain’s embassy.
In the IoT, machines are doing the communication but the same concept applies. If each has a unique trusted identity and appropriate documents proving that identity, they can exchange information as safely as humans do.
Secure elements give machines and devices identities—and highlight hardware security needs
Secure elements are the passports of IoT, and they are everywhere: in the chip on your banking card, the SIM card in your cellphone, the trusted platform module in your computer’s motherboard or inside more and more connected devices.
A secure element is a tiny security chip able to perform cryptofunctions such as encryption, decryption, true random number generation, signature and verification with primitives like AES, SHA, ECC. The chip is used to keep secret keys safely hidden from the outside world. Its unique serial number, MAC address, IEEE device address, private and public key pair create its “identity.” These are altogether assembled into one identity document, the device’s “certificate,” which is signed by a trusted certification authority. Unlike ordinary MCUs and memories, a secure element is very robust against physical attacks and can be neither read nor counterfeited. It comes programmed and personalized with unique IDs and secret keys so it can interface with its host MCU via an I2C, a 1-wire or a SPI bus.
Software-based implementations of identities and security are functional but very weak as software can be more easily changed, read and hacked—this is very much like writing a passport with erasable ink. In contrast, the hardware in certified secure elements is designed to resist to such attacks with state-of-the-art countermeasures.
End-to-end security for connected devices
Connected sensors and actuators ultimately exchange data with distant computers, most often servers, across many layers of networks: local area networks, cellular networks, operator-to-operator, internet service providers, with as many gateways bridging between them.
Although these networks offer their own layers of security, gateways bridging between networks also bridge between their security protocols, breaking the end-to-end route. It is therefore very difficult to secure an end-to-end path with so many gateways in the way, provided that they can even be known in advance.
This is why end-to-end security from the device itself to the final application server is so important. It’s very similar to the end-to-end security implemented on the internet with the HTTPS and MQTTS protocols, which guarantees a truly end-to-end tunnel between a web browser and the visited web site enabling users to confidently access the internet from any public WiFi.
How does end-to-end IoT security work? By ensuring three secure communication characteristics:
- Mutual authentication: devices and servers should and can prove true and unique identities to each other
- Message integrity: messages sent between devices and servers should be able to be sent safely so that they can’t be hacked, altered or changed by an interfering party—a main center of data privacy
- Message confidentiality: messages should also be able to be coded so only parties authorized to receive them can read what they say
Under IP communications, these characteristics are conveniently handled by the TLS (Transport Layer Security) protocol and X.509 certificates.
When dealing with non-IP communications such as Bluetooth, LoRaWAN, Zigbee or any proprietary link, a TLS-like layer can be implemented compliant with X.509 certificates so that the server side can handle security seamlessly.
Once you’ve got the right element, the security stack becomes easier
What’s bringing the entire end-to-end security scheme together today is an end-to-end security stack managing a secure element. But it all starts with this secure element safely hosting the device’s unique identity credentials, equipped with the ability to run the appropriate cryptography primitives. From there, security can move from personalization services to host MCU stacks and front-end server security. Then, certification authority services, PKI/key management services and identity management services can ensure you are secure from development through deployment and all the way to end of life.
This is a wide variety of pieces for a company to manage. So, it’s important to streamline the process with a small set of the right partners to help continually maintain a secure IoT project—with one internal or external point person that’s looking out for the whole solution.
Guillaume Crinon is the Global IoT Strategy Manager at Avnet, responsible for security and connectivity solutions. He has more than 20 years of experience in the semiconductor industry, mostly in radio-frequency circuit design, but also has extensive experience in metering, building/home automation and security systems. He joined Avnet in 2011. Guillaume graduated from SUPELEC in Paris (MSc in EE) and has co-authored 12 international patents in wireless systems, IC architectures and design to date.
AI From A-Z: The biggest buzzwords around artificial intelligence
Companies across markets from consumer electronics to factory floors are finding power in the introd...
The Building Blocks of IoT: You Just Can't Stack Them Up
I’ve spent my entire career in the business of technology, and I’ve watched many ideas go from “shin...
Increasingly powerful chips driving artificial intelligence
AI-supported applications must keep pace with rapidly growing data volumes and often have to respond...