AWS, Microchip deliver trust anchor for end-to-end IoT security


Digital certificates, such as X.509 used by the transport layer () protocol, are ingrained in almost every aspect of our digital lives. Whether sending a secure e-mail, checking a bank account balance, or performing any other action that requires an encrypted online connection, these certificates authenticate the identity of parties involved in the electronic exchange of information to prevent, for example, man-in-the-middle attacks whereby a malicious actor impersonates one entity and potentially alters or misrepresents the content being exchanged.

Certificate authorities (CAs) sign digital certificates as proof that they have validated a root certificate containing an entity’s public key, which is mathematically associated with a unique private key that remains secret as part of an entity’s asymmetric public/private key pair (Figure 1). This key exchange and verification mechanism between user and CA instills confidence in any recipient of the digital certificate that its sender is in fact who they attest to be.

[Figures 1a and 1b | As shown in Figure 1A, digital certificates are generated by certificate authorities (CAs) who sign off on the public key of entities attempting to establish secure online connections (Figure 1B).]

However, outside of the enterprise/IT community digital certificates have primarily been used to validate servers only. Client authentication is typically not implemented in most applications because it requires certificate provisioning for large sets of heterogeneous end users, which complicates the management of a public key infrastructure (PKI). But with the (IoT) introducing billions of clients that not only retrieve information from the but also send data to it, the requirement for mutual authentication – or the immediate two-way authentication of both clients and servers – has steadily increased to ensure overall system integrity.

AWS, mutual authentication, and Just-In-Time Registration

With the release of the platform last year, (AWS) introduced mutual authentication to the IoT space. As mentioned, mutual authentication technology helps verify the integrity of all parties in a system of systems architecture, but also introduces problems related to certificate provisioning for client-side devices.

In response, AWS released a service this April called “Use Your Own Certificate,” which allows original equipment manufacturers (OEMs) to register digital certificates signed by a third-party CA with the AWS IoT platform using an API. The Use Your Own Certificate feature implies that the key exchange required for the creation of a digital certificate can occur independent of a client connection with AWS IoT servers, and perhaps even before the device itself is connected to the Internet, introducing a new possibility for OEMs: Unique cryptographic keys can be generated for each device during production, signed by a CA as part of an offline digital certificate verification process, and then loaded into the AWS IoT platform to await a service request from systems containing the corresponding key pairs. This process also lays the groundwork for the latest capability in the AWS IoT portfolio, Just-In-Time Registration (JITR), announced in August.

JITR is somewhat of a turning point for the IoT in that, as the term implies, devices can automatically connect to and be recognized by the AWS IoT cloud the first time they request service from the platform. This type of immediate, autonomous onboarding of devices with cloud services is critical given the projected number of IoT connections, but is contingent upon the devices connecting being pre-equipped with unique, trusted private keys in order to enable services such as the Use Your Own Certificate API and to prevent impersonation attacks (Figure 2). It also requires that devices be equipped with the correct server configurations and policies to help facilitate the onboarding process, which must also be kept secure.

[Figure 2 | Just-in-time registration (JITR) allows devices to connect with AWS IoT servers the first time they attempt a service connection, but requires that the Use Your Own Certificate API be leveraged first to upload device certificates into AWS IoT.]

The challenge of device manufacturers is to ensure that these keys and policies remain secret and secure from the time a device is manufactured, through the onboarding process, and even after a product reaches end of life (EOL). Previously this has been attempted through the installation of security modules (HSMs) in secure rooms at factories, periodic factory security audits, and time box protocols that attempt to define an acceptable onboarding period for devices. Unfortunately, these methods tend to be either expensive or inexact, and also don’t account for threats that could compromise systems deployed in the field, such as physical tampering.

Hardware-based elliptic curve cryptography anchors trust in IoT

2016 has also seen significant news from the other side of the IoT technology spectrum, as semiconductor vendor acquired competitor Atmel for approximately $3.6 billion earlier this year. Among other technologies, the purchase netted Microchip access to Atmel’s portfolio of security ICs, including elliptic curve cryptography-based (ECC-based) CryptoAuthentication devices such as the ECC508A (Figure 3).

[Figure 3 | The ECC508A is a 2 mm x 3 mm tamper-resistant CryptoAuthentication device based on elliptic curve Diffie-Hellman (ECDH) cryptography algorithms that provide hardware-based cryptographic key generation, storage, and countermeasures.]

The ECC508A is noteworthy in the framework of AWS IoT’s mutual authentication, Use Your Own Certificate, and JITR capabilities in that the elliptic curve Diffie-Hellman (ECDH) key agreement protocol it employs enables the internal generation and storage of private keys. These keys remain protected through the life of the device due to tamper-resistant architectural features of the chip, including internally encrypted memory, isolated power rails, a memory and logic shield, internal clock generation, and a lack of probe points that protect against real-world threats such as emissions analysis, microprobe, power cycling, and timing attacks. This secure storage space can also be used to house pre-configured AWS server policies, resulting in a device that contains all of the information needed for digital certificate authentication and onboarding required by JITR.

As seen in ’s wolfCrypt benchmark of an embedded SSL/TLS stack running on the ECC508A, the hardware-based crypto acceleration of the chip also offloads encryption tasks from a host processor, resulting in improved overall system performance (Figure 4).

[Figure 4 | The wolfCrypt ECC benchmark shown here illustrates performance metrics of a TLS transaction running the lightweight (20 Kb – 100 Kb) wolfSSL embedded SSL/TLS library on the ECC508A hardware-based crypto accelerator versus in software. The average TLS establishment time for the ECC508A is 2.342 seconds, compared to 13.422 seconds in software, good enough for a 5.73x improvement. Graph courtesy wolfSSL.]

ECC508A and AWS IoT: The process

As discussed previously, private keys are mathematically correlated with the public keys required for the creation of digital certificates. Therefore the ECC508A becomes the root of trust for any device that equips it.

In the context of a mutually authenticated AWS IoT deployment leveraging the ECC508A, Microchip can act as the CA, both generating and signing device certificates in parallel as part of the certificate chain verification process for an IoT OEM. The OEM would then load the resulting digital certificates into their AWS IoT account through the Use Your Own Certificate API, where they would remain until an incoming TLS request from a device containing the partnered ECC508A key pair triggers the JITR process.

The procedure, from key generation through cloud onboarding, requires a one-time setup, shown in Figure 5. As keys are generated in a secure Microchip facility and the key management infrastructure is already in place, OEMs are able to access robust security and automatic cloud authentication by adding a single component to their bill of materials (BoM).

[Figure 5 | With the ECC508A acting as the root of trust, Microchip can act as a third-party CA, signing device certificates in an offline verification process and providing them to an original equipment manufacturer (OEM) for upload to an AWS IoT account.]

Dropping anchor on IoT security

Security is essential to the continued rollout of IoT in every market, and discrete solutions that allow device makers to separate security from business functions and value adds will enable more innovative products in the future. An ECC508A evaluation kit is available for interested parties through Microchip and distributors such as DigiKey and Mouser, with trials and tutorials of AWS IoT accessible at

[Figure 6 | The ECC508A AT88CKECC-AWS-XSTK evaluation kit is available for developers of secure, connected applications for $249.]