Take the Zero-Touch Approach to Securely Lock Down an IoT Device

The demonstrated ability of hackers to penetrate IoT devices says more about the level of security of these devices than the skill of the hackers: in most cases, the affected products lack the most basic security provisions. That said, basic security is simple conceptually, but its implementation requires careful attention at every node in a system to avoid vulnerabilities.

A pre-built security solution from Microchip Technology allows developers to implement zero-touch device provisioning in IoT applications built around the Amazon Web Services (AWS) IoT service.

Security requirements

A world of IoT connected devices presents a rich prize to hackers intent on controlling, disrupting, or corrupting critical applications in industry, transportation, health, and emergency services, among others. Increasingly, IoT developers are addressing the safety of data in transit by encrypting communications between devices and their hosts. Yet, data encryption represents only a portion of the requirements for end-to-end security.

A secure IoT application also depends upon secure authentication to ensure that known devices communicate with trusted hosts. The lack of assurance in device or host identity leaves an open door for attackers to take control of the data stream using man-in-the-middle attacks. In these attacks, bad actors represent themselves as trusted end devices in order to insert corrupted data streams into an application. Alternatively, attackers falsely represent themselves as known hosts to take control of IoT devices.

Although their ability to break encryption lies at the heart of these approaches, the real damage lies in their ability to intrude themselves as authorized entities into trusted networks with all the potential harm that might entail. Consequently, IoT applications lend themselves to more sophisticated service platforms that address security on a broad level.

Use a secure cloud platform

Amazon Web Services (AWS) IoT platform provides a comprehensive environment that embeds security as a fundamental capability as it serves the diverse functional requirements of IoT applications. As a specialized front end to diverse AWS services, AWS IoT sits between the IoT device and its application, using a message-based architecture to secure and administer IoT devices (Figure 1).

Figure 1: The Amazon Web Services IoT platform connects IoT devices with the broad family of AWS services, leveraging AWS security mechanisms to perform mutual authentication between IoT devices and the AWS platform. (Image source: Amazon Web Services)

As messages arrive from IoT end devices, developer-defined rules initiate appropriate actions involving other AWS services that work on behalf of the IoT application. In turn, the IoT application software interacts with cloud-based device shadows that maintain the last known state of the corresponding physical IoT devices. This shadowing ensures continued operation of the IoT application, even if the physical devices momentarily go offline. This service model depends upon a sophisticated set of security mechanisms that are designed to identify trusted entities and control their access to available resources.

At the heart of the AWS security model are identity and access management (IAM) policies. These spell out which devices, users, or services are permitted to access which specific resources within the IoT network, AWS environment, or the application. To a large extent, the success of this security model hinges upon reliable authentication of the entity (user, device, or service) requesting access to a particular resource. If bad actors are able to fool the security system into authenticating them as fully trusted users, the barriers presented by access rights rules effectively dissolve.

As with general web access, AWS uses public key infrastructure (PKI) keys and standard X.509 certificates. In fact, AWS security services use an authentication model familiar to web users. For secure web links, web browsers rely on underlying mechanisms such as transport layer security (TLS) services that check site certificates to authenticate the host server prior to establishing secure communications. More sensitive web-based applications supplement host authentication with client authentication, using a client certificate in the user’s browser to confirm the user’s identity.

Deployments of this kind of mutual authentication remain relatively rare in general web usage because few users are willing or able to take the steps needed to acquire their own client certificates and provision their browsers with those certificates. Yet, mutual authentication is key to reducing the attack surfaces available to bad actors. In fact, the AWS IoT service requires mutual authentication between an IoT device and the AWS cloud. If mutual authentication is difficult in general web usage, it presents significant challenges to IoT developers.

To implement mutual authentication in IoT devices, developers need to overcome multiple hurdles. Besides dealing with the logistics of key and certificate acquisition, developers need to store those secrets securely with no possibility of unauthorized access. In addition, the IoT device needs the ability to execute encryption algorithms in a way that remains immune to penetration, all the while maintaining the overall performance of the IoT device.

Developed in collaboration with AWS, pre-configured versions of the “generic” Microchip ATECC508A CryptoAuthentication device meets these requirements, providing a simple drop-in solution for designers building devices for AWS IoT.

Dedicated crypto

Created specifically for secure authentication, the ATECC508A IC combines hardware-based PKI algorithms and secure storage in a design that resists attack through physical, electrical, or software means. The device connects through its I²C interface to a design’s host CPU. The host CPU then uses a simple command set to perform encryption, update the stored certificate, and access other ATECC508A functions. In fact, the ATECC508A internally generates private keys and stores them securely, eliminating the need for off-chip key management. Because the integrated crypto engine works with secure data within the same chip, the crypto secrets are never exposed on the external bus where they might be intercepted.

In offloading crypto execution from the host processor, the ATECC508A not only enhances security, but it does so without compromising performance. Designs using the ATECC508A can achieve TLS connections significantly faster than software-only TLS implementations. In benchmark tests, ATECC508A-based systems completed TLS connections more than five times faster on average than software-only implementations using a high performance ARM® Cortex®-M0-based processor¹.

The ATECC508A offers substantial benefits for IoT designers, but in its generic form it remains essentially a blank slate for authentication applications. Although the device internally generates private keys, it requires development organizations to acquire and load trusted X.509 certificates. Certificates build on a hierarchy of trust, where root certificates sign certificates used on hosts and clients. Building this trust hierarchy is fundamental to secure systems and applications. For developers, however, the detailed logistics of certificate generation and registration represents a significant complication. Worse, certificate generation for prototypes or pre-production systems can simply be a waste of time when production units use a separate root certificate or a different chain of certificates. A pre-configured ATECC508A provides a simpler solution for engineers using the AWS IoT platform in pre-production designs.

Using the pre-configured ATECC508A devices, designers can implement authentication simply by dropping the device into their designs and connecting it to their host MCU through an I²C port. Available in 8-lead UDFN (ATECC508A-MAHAW-S) and 8-lead SOIC (ATECC508A-SSHAW-T) versions, the devices are pre-provisioned with the necessary client certificates and pre-configured to work with AWS IoT. Developers can solder the device into their own designs and interact with AWS IoT using application programming interfaces (APIs). These APIs reside within the AWS software development kit (SDK) libraries hosted on their target system.

Alternatively, they can evaluate the device using the Microchip AT88CKECC-AWS-XSTK AWS zero-touch provisioning kit (Figure 2).

Figure 2: The Microchip Technology AT88CKECC-AWS-XSTK AWS Zero Touch Provisioning Kit provides a complete wireless IoT design built around a SAM G MCU board (center), ATECC508A-xxxAW device board (left), ATWINC1500-XSTK RF board (right), and ATOLED1-XPRO display board with buttons and switches to mimic IoT events (bottom). (Image source: Microchip Technology)

Along with ATCRYPTOAUTH-XPRO Crypto eval boards for the ATECC508, the kit provides a complete IoT design prototype, comprising the ATSAMG55-XPRO SAM G MCU board, ATWINC1500-XSTK RF board, and the ATOLED1-XPRO board with display, buttons, and switches used to simulate IoT data events.

Zero-touch provisioning

Whether working from a custom prototype or the starter kit, developers can implement AWS mutual authentication with the ATECC508A-xxxAW by simply plugging the device into a design. The advantages of the ATECC508A-xxxAW become evident the first time the device connects with AWS IoT.

On initial connection, the ATECC508A-xxxAW device interacts with AWS IoT to automatically complete the AWS just-in-time registration (JITR) process that uniquely identifies each IoT device within AWS IoT. Additionally, IoT developers can extend this concept of zero-touch provisioning beyond designs based on these pre-configured ATECC508A versions.

Commonly used in IT network environments, zero-touch provisioning (ZTP) allows network equipment deployments to proceed without user intervention. At startup, the network identifies new network equipment and authorizes its connection to the network, just as AWS JITR automatically provisions pre-configured IoT devices. For IoT applications expected to encompass massive numbers of devices, ZTP represents a particularly important concept. Using the Microchip AT88CKECC-AWS-XSTK starter kit, developers can gain a better understanding of the details behind certificate provisioning and ZTP using AWS JITR. In particular, developers can explore the use of custom software using AWS’s serverless Lambda service to address unique requirements for the ZTP process.

Along with the IoT design hardware mentioned above, the starter kit comes with the Microchip AT88CKECCROOT root module utility and AT88CKECCSIGNER signer module utility. The root and signer modules each come with a USB dongle that contains root keys and signing keys, respectively.

Working with the starter kit, developers connect the AT88CKECC-AWS-XSTK and modules via USB to their PC, which should be running the starter kit software package. The starter kit application walks users through the details of registering certificates on AWS IoT. It uses the root and signer modules mentioned above to represent the roles of the actual root certificates and signing certificates that will eventually be used during manufacturing. For production units, a similar process would occur in the Microchip manufacturing facility where “blank” ATECC508As are configured using certificates that build upon the development organization’s own root of trust (Figure 3).

Figure 3: Although the ATECC508A-xxxAW series comes pre-configured by Microchip for AWS IoT, production of devices for customer designs would use a tool such as the AT88CKECCSIGNER signer module to create custom device certificates that build on the development organization’s root of trust. (Image source: Microchip Technology)

Microchip supports the starter kit with a software package that reduces operations and interactions with AWS IoT to a few simple software calls. For example, the main routine in the sample application calls aws_demo_tasks_init(), which launches a series of separate tasks associated with each hardware component in the starter kit.

Developers can leverage the sample code set to create their own ATECC508-based designs for AWS IoT applications. In fact, the kit builds on the same CryptoAuthLib C-language offered as a standard package for ATECC508 software support. The starter kit simply converts higher-level calls to a series of low-level calls to the CryptoAuthLib library’s “at” routines (Listing 1).

/**

 * \brief Send a command array to ATECC508A over I2C.

 *

 * \param[in] tx_buffer        Buffer to be sent

 * \return ATCA_SUCCESS        On success

 */

uint8_t aws_prov_send_command(uint8_t *tx_buffer)

{

      uint8_t status = ATCA_SUCCESS;

      uint8_t cmd_index;

      uint16_t rx_length;

      uint16_t execution_time = 0;

      uint8_t *cmd_buffer;

      ATCADevice  _gDevice = NULL;

      ATCACommand _gCommandObj = NULL;

      ATCAIface   _gIface = NULL;

      do {

            if (tx_buffer == NULL)

                  break;

            /* Collect command information from TX buffer. */

            if (aws_prov_get_commands_info(tx_buffer, &cmd_index, &rx_length) != ATCA_SUCCESS)

                  break;

            cmd_buffer = (uint8_t *)malloc(tx_buffer[0] + 1);

            memcpy(&cmd_buffer[1], tx_buffer, tx_buffer[0]);

            /* Initialize every objects. */

            _gDevice= atcab_getDevice();

            _gCommandObj = atGetCommands(_gDevice);

            _gIface = atGetIFace(_gDevice);

            /* Get command execution time. */

            execution_time = atGetExecTime(_gCommandObj, cmd_index);

            if ((status = atcab_wakeup()) != ATCA_SUCCESS )

                  break;

            /* Send command. */

            if ((status = atsend( _gIface, (uint8_t *)cmd_buffer, tx_buffer[0])) != ATCA_SUCCESS)

                  break;

      .

      .

      .

      } while(0);

      return status;

}

Listing 1: The starter kit software package builds on the standard ATECC508 CryptoAuthLib C library, using a series of CryptoAuthLib “at” calls to implement higher order functionality such as sending commands from the MCU to the ATECC508A. (Code source: Microchip Technology)

For developers working in custom environments, the CryptoAuthLib provides a well-defined architecture that isolates hardware dependencies into a hardware abstraction layer (HAL) (Figure 4). By modifying the HAL routines, developers can build in support for their unique operating environments.

Figure 4: The multilayered CryptoAuthLib architecture isolates hardware dependencies into a hardware abstraction layer that simplifies porting the library to different operating environments. (Image source: Microchip Technology)

Conclusion

Mutual authentication provides the most secure approach to communications between devices, users, and services, and has emerged as a requirement in AWS IoT. Yet, implementation of mutual authentication presents significant challenges for IoT device deployments. Its success depends on efficient methods for reliably provisioning IoT devices with the intellectual property underlying secure communications protocols.

Microchip’s pre-configured ATECC508 devices remove traditional barriers to implementation of mutual authentication and provide developers with a drop-in solution to IoT applications designed for AWS IoT. Using these devices, developers can implement ZTP that eliminates manual intervention in IoT device deployment, relying instead on automatic recognition and registration of IoT devices.

Reference:

1. wolfSSL Atmel ATECC508A