Making embedded security scalable in your supply chain
01 July 2020
Microchip_Making embedded security scalable in your supply chain_580x280
For years, security has been a secondary concern for the majority of embedded device manufacturers. Often, OEMs took the view that protection could be traded off against convenience.
This article was originally featured in the July 2020 issue of EPDT magazine [read the digital issue]. Sign up to receive your own copy each month.
A typical approach was to give maintenance engineers a single password that could unlock any device in the family. In theory, it was kept secret (so-called ‘security by obscurity’) – but in practice, passwords leaked out, with the result that the most effective security for these systems was physical (in other words, restricted access). Here, Nicolas Demoulin, EMEA Marketing Manager for microcontroller & integrated circuit manufacturer, Microchip Technology’s Secure Products Group explains why this approach is not sustainable in the IoT age – and how Microchip can help make embedded security scalable…
If the device was locked away and inaccessible, then only authorised personnel would be allowed access. But once devices were connected to the internet, they became visible outside the home or factory – making them incredibly vulnerable. The consequences of using the same password for all systems in a product family became clear with attacks such as Mirai in 2016. The attack made it possible to recruit millions of embedded devices into botnets that were then used to launch denial-of-service (DoS) attacks on other systems.
The targets of Mirai were mass-market devices. Manufacturers of low-volume IoT products can take comfort in being unlikely targets for hackers keen to put new botnets together. But their profits are equally at risk from similar attacks as the IoT changes business models. Increasingly, revenue will be derived from services, and this income will dry up if devices are easily compromised. The ability to give each device its own unique trusted identity and access credentials is critical because it limits the scale of any attack. As part of an overall security strategy, the use of unique trusted identities makes IoT services harder to compromise.
With a unique trusted identity, cloud-based applications and other systems on the IoT can determine whether a device should have access to their services. However, this identity has to be guaranteed in some way to ensure hackers cannot simply use the credentials for one device and use a counterfeit implementation to gain access to the network and its services. Another angle of attack might be to compromise a single device and load new firmware into it that performs operations on the network that the hacker wants. Without some way of checking that the code an individual device runs is genuine, other systems have no way to determine whether they are talking to a legitimate, unhacked device, or not.
The key to bringing trusted identity and effective authentication is a secure element. This could be a secure area inside a microcontroller. But such a monolithic architecture shares resources such as power lines, clocks and registers that may lead to inadvertent disclosure of the credentials to a skilled hacker. In addition, there is significant extra cost in working with a new microcontroller architecture, because of all the additional software expertise needed to ensure the system is secure.
The additional cost of the more specialised microcontroller could the limit the competitiveness and flexibility of the solution in the market. There is no need to make this switch. Instead, the designers can take advantage of the functions offered by a secure element. This is a device that communicates with any microcontroller, typically using a serial interface, and combines a secure non-volatile memory with a crypto-accelerator designed to support algorithms that support the public-key infrastructure (PKI).
Figure 1. Example chain of certificates
Certificates & keys
PKI leverages asymmetric cryptography. This is a technique that links two numeric keys together mathematically. One is a public key, which is typically used to verify signed messages. The public key can be distributed widely without issue. The public key is used to validate messages: only the device with the private key can sign the information. This private key needs to be kept safe, stored on the device and never transmitted to any other system. Using the private and public keys, the PKI can construct structured security models such as digital certificates. These certificates are generally used to demonstrate the identity of a device and to confirm that it is authentic.
Under protocols such as the X.509 standard, digital certificates can form chains that refer back to a core root certificate. This chain is vital for determining the validity of each certificate. Typically, a system that wants to check a certificate will use the name of the issuer on a child certificate to obtain the public key for the immediate parent certificate. Checking the full hierarchy provides the user with the confidence that the signature of the certificate is legitimately that of the owner, and provides the means to counter spoofing attacks and other mechanisms hackers might attempt to gain access to a network or system. Through the exchange of certificates, not only can cloud services determine that a device is authentic, the device can also ensure it is talking to an authorised server using the same types of exchange.
Cloud services provide other means to control security. A key advantage of cloud-based management for service operators is that it facilitates repudiation if a device is no longer in use, for example. By removing the device and its keys from active service, a hacker cannot attempt to repurpose hardware thought to be deactivated in order to conduct an attack on the network.
Security & the supply chain
The use of digital certificates and signatures makes careful management of the electronics supply chain vital. A potential weakness in a system based on standard X.509 certificates is that problems in the supply chain can potentially lead to hackers manipulating certificates or intercepting private keys as they are programmed into a device on the production line. Ideally, a private key should never be disclosed outside the secure element. But to ensure that certificates can be linked to the correct keys, some implementations insert the key into the secure element after board assembly using a flash-memory programmer. A hacker with access to the programmer would be able to intercept the keys or insert their own certificates to help them gain access to the device after installation.
A more secure alternative is one employed in the manufacture of the Microchip ATECC608a and other components in the secure-element family. The secret credentials are created using Hardware Secure Modules (HSMs) that are installed in the Microchip factories. The generated credentials are not allowed to leave the secure element once each one is programmed. The ATEC608a doesn’t disclose the private key over the communications port and uses hardware-based tamper proofing to prevent physical attacks from being used to obtain the secrets stored inside.
Figure 2. The ordering/delivery flow of Microchip’s Trust Platform
For example, if an attacker cuts through a metal shield over the sensitive circuitry in an attempt to probe the device physically, the element will immediately cease functioning. Countermeasures against glitching attacks and passive side-channel analysis prevent the key data from being obtained using electromagnetic emissions.
Who holds the keys?
It is not enough just to provision secret keys and certificates into a secure element. The supply chain needs to implement mechanisms to generate certificates and transfer them to and from the manufacturing site, so that the OEM or operator can maintain a list of devices that will be allowed to connect to the network after installation. Some of these certificates will need to be transferred to the database used by the cloud service that manages device authentication. Clearly, the creation of such a manufacturing infrastructure is a complex and costly endeavor. Not only does it require the purchase and maintenance of hardware infrastructure, such as HSMs, for programming the secure elements, it incurs a high cost in terms of training and personnel management.
Because of the high cost of bringing secure programming in-house, one option is to have the operations outsourced to a contract electronics manufacturer or another service provider. However, this generally incurs high setup costs. Certificate generation and delivery services need to be customised for each product. To justify the overhead of the setup process, service providers will normally demand minimum orders of hundreds of thousands of units.
One response has been to offer a one-size-fits-all approach to key management. This involves a deep partnership between silicon and cloud-service providers, with one of them taking charge of certificate creation and management. All the certificates trace back to the cloud account owner, which acts as a central certificate authority. Its database is used to monitor all the IoT devices for which it holds the certificates and other data on behalf of each of the users. This does not demand that the customer is tied to a specific cloud service. Instead, the central service provides authentication and other security services which can be used by customers’ own cloud applications. This frees them from the day-to-day management of security and authentication and helps them focus on their core application. But under this model, the manufacturer cannot act as a certificate authority for its own devices and has to use the same cloud provider for all authentication services.
Many manufacturers want a more flexible approach to security management. The ideal certificate-management structure will depend on the application’s needs. In a typical IoT scenario, where a large number of devices need to be shipped to multiple customers, the root certificate is likely to be owned and managed by the OEM. However, more operations will be delegated to services that rely on further intermediate certificates.
For example, to incorporate the systems into their chosen network, each individual customer can use an intermediate-level certificate derived from that root to generate device-level certificates. This lets the customer’s servers or applications running in the cloud check identity and ensure they are working with the right IoT devices in the field.
Figure 3. Typical customer journey
To provide a more flexible approach to security and certificate management, Microchip developed its Trust Platform, based on the ATECC608a secure element as its hardware core. Wrapped around that are a number of automated services that make it possible for customers to choose the certificate strategy they need for each application, together with a body of development tools and source code that implement commonly used authentication and security-focused operations.
Three tiers of Trust
There are three tiers to Microchip’s Trust Platform. Trust&GO (www.microchip.com/TrustGO) is based around a device certificate only architecture, providing the ability to create secure authentication and ship them without the need to implement custom secret exchange. All of the onboarding operations are facilitated by trusted cloud partners, such as AWS, Google and Microsoft Azure. With just 10 units as the minimum order quantity, including key provisioning, the service is suited to prototyping and in-field testing, and low-volume products that will be used on LoRaWAN networks and with systems that will use TLS encryption.
With a minimum order quantity of 2,000 units, TrustFLEX (www.microchip.com/TrustFLEX) provides the ability to have a custom certificate provisioned into the secure element during the secure manufacturing process within Microchip’s HSM. The devices are also shipped with preconfigured generic certificates. The development support for TrustFLEX covers a wide range of use-cases, including secure boot, firmware verification, I/O protection and key rotation, which is important to maintaining long-term security.
TrustCUSTOM (www.microchip.com/TrustCUSTOM) offers maximum flexibility, with a fully customisable implementation and a minimum order quantity of just 4,000 units, including provisioning. Customers gain access to the provisioning capabilities of the HSMs used in Microchip’s factories, so they can insert the security credentials they require at manufacturing time. Tools appropriate to each level of access provide the ability to upload configuration files and the certificates needed to set up each secure element that will be produced by Microchip. As each device ships, Microchip provides a manifest file that includes the serial number and public key of each secure element, so that the details can be inserted into databases for when the end equipment is ready to connect. This information is not sensitive and so can be sent over non-secure channels.
Verifiable unique identity is a vital component of IoT: without it, secure operation is impossible to achieve. Up to now, bringing unique identity in a way that can be leveraged successfully for IoT applications has demanded a high degree of supply-chain customisation. This customisation creates added cost, as each microcontroller firmware becomes unique in a production environment. In a global fragmented IoT economy, embedded systems are cost sensitive, but such costs are incurred beyond the bill of material (BOM) and reflected in manufacturing costs. Microchip’s Trust Platform provides the means to bring the benefits of unique identity and remote authentication to every embedded system in a cost effective and scalable supply chain environment.
Contact Details and Archive...