Adding security to IoT endpoints shouldn’t be an option
Secrets have a way of leaking out and invariably people are the cause. In the IoT, it isn’t the things that will be the main cause of cybercrime, but the people exploiting the weak security provided by those things. The list of examples illustrating this very real threat gets longer every day.
Guest blog written by Mark Patrick, Mouser Electronics.
It’s probably true to say that the responsibility of ensuring that every device added to a network is secure rests with the person putting that device into service, but how many people actually have the time, inclination or ability to check that a device is actually secure before adding it to a network?
Manufacturers are not exactly forthcoming in broadcasting the security credentials of their products and even the most diligent consumer may find it simply impossible to find out what security features a connected home appliance has, short of calling the manufacturer and asking to speak to the lead engineer.
So are we, as consumers, supposed to accept that our devices may not offer the most appropriate level of security when adding them to our home or office network, and if we do are we also accepting liability for any data theft that could happen as a result? The answer should be no, but it probably isn’t that simple. Legal liability for the results of cybercrime are likely to be tested extensively in courts around the world over the next five to ten years, until the consequences make it unattractive for manufacturers to persist in the market, or laws are passed to enforce manufacturers to employ at least an agreed base level of security.
Manufacturers should take control
The European Commission recently published initiatives including a proposal for a Cybersecurity Act, which could see a Cybersecurity Certification Framework being put in place. One of the objectives of such a plan is to raise consumer trust in products, by decentralising the enforcement to member states. Each state would be expected to create a certification supervisory authority, which would be empowered with the ability to investigate products for non-compliance and, presumably, prosecute those companies not complying.
This would be an important and positive step in the right direction, but should it fall to governments to legislate security in the IoT, or should manufacturers be leading the way by demonstrating that their products have been designed to be secure? At the very least it would provide a competitive edge, particularly as consumer awareness of security threats within the IoT grows.
Part of the problem could be understanding the solution. Security is well understood in the IT domain, where large servers are able to run processor-intensive security measures, or on PCs where the person using the computer forms part of the solution. But in the IoT, where endpoints are numerous, disparate and resource-limited, implementing conventional security measures becomes more of a challenge.
If encryption is the key, where is the key?
Cryptography describes the process of encrypting data for transmission and it is, for the most part, well understood. Perhaps the most prevalent form of encryption used, even in the embedded space, is the Advanced Encryption Standard, or AES. The integration of hardware-accelerated AES is becoming increasingly common, even in relatively small microcontrollers, mainly because the process is compute-heavy and the core would struggle to handle the process and maintain normal operation. In a hard real-time system the challenge would be even greater.
The IoT isn’t entirely responsible for the use of AES in embedded systems, it is a common method used to encrypt data stored in external Flash memory, such as FPGA configuration files, firmware and other IP, as well as regular data. The need to protect IP predates ubiquitous connectivity but the same technology is appropriate, however the way it is used has changed.
Keys are crucial to the use of AES, they are used in the encryption and decryption process. In order for one party, let’s call her Alice, to encrypt something and send it another party, let’s call him Bob, using asymmetric cryptography, it is necessary to use two keys; one public key that is shared between both parties and two private keys, one for each party. When both parties are on the same PCB, such as an FPGA and Flash memory, key management is simple, but when the parties are connected over an open network, like the Internet, key management becomes more of a challenge.
In an effort to address the challenge, particularly for IoT endpoints and other embedded devices, Microchip created the ATECC508A and ATECC608A, part of its CrytoAuthentication family of products. These tiny, low-power devices are designed to sit alongside a microcontroller and provide crucial security functions, in hardware.
The main security functions include firmware and data protection, secure boot and authentication, but perhaps most significantly they support key creation and agreement, and public key algorithms. As these functions are implemented in hardware, the devices are able to execute complete asymmetric key cryptography using public and private keys up to 1000 times faster than a software implementation. This also helps with provisioning, as the devices are able to generate and securely store a private key, and from that generate a public key that can be shared with other authenticated devices. This overcomes one of the major problems with AES and asymmetric encryption; that of secure key provisioning.
So it seems it is possible to implement security in the IoT, even for resource-constrained devices. But of course, those products we trust most will already be secure, wont’ they?