Product category

Home > Industry News > Use a Crypto Chip to Add Secure Boot to IoT Device Designs

Use a Crypto Chip to Add Secure Boot to IoT Device Designs

Release on : Jun 28, 2018

Despite their best efforts, developers can leave Internet of Things (IoT) designs exposed to attack by the very code expected to maintain security. Hackers often attack even seemingly secure designs by replacing the firmware with compromised code. Secure boot methods can mitigate these attacks, but proper implementation can be challenging.

Developers need simpler methods to implement secure boot as part of an overall strategy for ensuring IoT device security.

This article very briefly reviews common attack surfaces in IoT device designs, and the role of basic security methods including secure key storage, encryption, and authentication. The article then introduces a security chip that lets developers add secure boot among other features needed in an overall strategy for ensuring IoT device security.

IoT device vulnerabilities

To hackers, IoT devices can provide any number of entry points for disruption of the devices themselves, their networks, and even their ultimate applications. Although developers can use a variety of techniques to strengthen network and application security, IoT device security has remained a challenge due to the limited memory and processing resources available on these devices.

Although developers are employing encryption methods to protect data, many devices are designed without the secure authentication capabilities needed to prevent hackers from intercepting communications by posing as authorizing servers, gateways, or other IoT devices. In some cases, devices using valid but weak authentication methods can remain vulnerable to sophisticated exploits that intercept and reuse otherwise valid security keys used in seemingly private communications sessions.

IoT device update

An even more fundamental security weakness relates to use of over-the-air (OTA) update capabilities built into a rapidly growing number of IoT devices. OTA updates provide an important feature in the fast moving IoT marketplace. Developers can respond to changing customer demand for new features (or fix bugs) by upgrading the firmware of deployed devices. In a typical OTA update process, the IoT device will periodically look for updates, download the new code when it becomes available, and perform a series of system calls to complete the update process.

For a Microchip Technology SAM D21 MCU-based IoT device, for example, the device firmware would include OTA update code that downloads the image from some preset endpoint, check for success, then switch to the new firmware set (Listing 1). In this listing from Microchip’s Advanced Software Framework package, after initialization (m2m_ota_init()) of the OTA firmware, a callback routine, OtaUpdateCb(), switches to the new firmware set (m2m_ota_switch_firmware()) after the OTA firmware has downloaded the new code image and a system reset causes the MCU to reboot into the updated firmware.

Copy

static void OtaUpdateCb(uint8 u8OtaUpdateStatusType ,uint8 u8OtaUpdateStatus)

{

    if(u8OtaUpdateStatusType == DL_STATUS) {

        if(u8OtaUpdateStatus == OTA_STATUS_SUCSESS) {

            //switch to the upgraded firmware

            m2m_ota_switch_firmware();

        }

    }

    else if(u8OtaUpdateStatusType == SW_STATUS) {

        if(u8OtaUpdateStatus == OTA_STATUS_SUCSESS) {

            M2M_INFO("Now OTA successfully done");

            //start the host SW upgrade then system reset is required (Reinitialize the driver)

        }

    }

}

 

void wifi_event_cb(uint8 u8WiFiEvent, void * pvMsg)

{

    case M2M_WIFI_REQ_DHCP_CONF:

    {

        //after successfully connection, start the over air upgrade

        m2m_ota_start_update(OTA_URL);

    }

    break;

    default:

    break;

}

 

int main (void)

{

    tstrWifiInitParam param;

    tstr1xAuthCredentials gstrCred1x    = AUTH_CREDENTIALS;

    nm_bsp_init();

   

    m2m_memset((uint8*)&param, 0, sizeof(param));

    param.pfAppWifiCb = wifi_event_cb;

   

    //Initialize the WINC Driver

    ret = m2m_wifi_init(&param);

    if (M2M_SUCCESS != ret)

    {

        M2M_ERR("Driver Init Failed <%d>\n",ret);

        while(1);

    }

    //Initialize the OTA module

    m2m_ota_init(OtaUpdateCb,NULL);

    //connect to AP that provide connection to the OTA server

    m2m_wifi_default_connect();

 

    while(1)

    {

       

        //Handle the app state machine plus the WINC event handler                                                                    

        while(m2m_wifi_handle_events(NULL) != M2M_SUCCESS) {

           

        }

       

    }

}

Listing 1: In this over-the-air (OTA) code sample from the Microchip Advanced Software Framework package, a Wi-Fi event handler callback wifi_event_cb() starts the OTA update m2m_ota_start_update(OTA_URL) using the specified URL and switches to the new firmware m2m_ota_switch_firmware() on successful completion OtaUpdateCb(). (Code source: Microchip Technology)

To check that the downloaded code is valid, developers have long relied on code signing certificates issued by a recognized certificate authority. Even so, weaknesses in secure data storage, validation technique implementation, and certificate protection provide hackers with multiple avenues for taking over an IoT device.

Even with conventional security techniques, a device's own firmware update process can be fooled into replacing its valid code with compromised code. On reboot, the device becomes a tool that the hacker can use to penetrate more deeply into the IoT network, the IoT application, and even the enterprise's internal resources.

In this scenario, the ability to securely boot the IoT device serves as a critical line of defense. For the developer, however, implementation of secure boot carries multiple requirements for secure storage, encryption, authentication, and code validation mechanisms.

Implementing secure boot in software leaves the update process exposed to attack methods focused on retrieving secure keys from device storage, intercepting encrypted data, spoofing authentication mechanisms, and compromising code validation algorithms. In practice, IoT designs typically lack the extra memory and processing power that would be required for a software solution in any event. Even so, a hardware implementation cannot always promise security.

To implement secure boot in hardware, IoT devices until recently required a number of specialized devices that would significantly increase design complexity and cost. Even if developers integrated these separate devices, determined hackers could easily procure a sample of the target IoT device and attack the individual security devices through their bus and signal interconnect. In contrast, Microchip Technology's ATECC608A is a single-chip solution that allows developers to add secure boot without exposing the underlying secrets or security mechanisms.

Security IC

The ATECC608A is an 8-pin security device designed to support a host MCU with a sophisticated complement of security features through a simple serial interface (Figure 1).

Image of Microchip Technology ATECC608A is an 8-pin cryptographic coprocessor

Figure 1: The ATECC608A is an 8-pin cryptographic coprocessor with secure hardware-based key storage. (Image source: Microchip Technology)

The device provides a complete hardware-based security solution that combines its integrated crypto accelerators with on-chip secure storage to support a variety of encryption algorithms including SHA-256, AES-128, and robust elliptic curve algorithms including Elliptic Curve Digital Signature (ECDSA), Elliptic Curve Diffie-Hellman (ECDH), and NIST Curve P-256. Beyond these crypto mechanisms, the device supports higher level Transport Layer Security (TLS) protocols including TLS 1.3. Unlike earlier devices, the ATECC608A can generate and securely store session keys, which helps mitigate a common source of threats found with use of TLS authentication.

These features play a fundamental role in securing normal operations of an IoT device, but the ATECC608A's support for secure boot extends security coverage to the fundamental firmware update process. Here, the ATECC608A validates the new code set and returns a message to the MCU signifying success or failure. At that point, depending on existing security policies, the MCU can retry the update, send a warning message to a security monitor endpoint, halt, or ignore the update and reboot into the original code.

Hardware integration

For the developer, the ATECC608A adds relatively few additional requirements for adding secure boot and the other security features to an MCU-based design. On the hardware side, the designer needs to deal with at most four connections; VCC, GND, serial clock input (SCL), and serial data (SDA). The remaining four pins are not connected. Aside from connecting VCC to a 2.0 V to 5.5 V supply source, the only remaining decision is the serial connection to the MCU.

Designers can connect the device's SCL and SDA pins to the MCU for conventional I2C connectivity. Alternatively, designers can take advantage of the device's support for Microchip's 1-wire interface. Here, developers connect the device's SDA port to an MCU GPIO pin and use Microchip's 1-wire timing protocol to transmit logic 0 and 1 values (Figure 2).

Diagram of Microchip 1-wire serial protocol

Figure 2: In the Microchip 1-wire serial protocol, a sequence of waveform transitions of specified duration signal a logic 0 or logic 1. (Image source: Microchip Technology)

In this protocol, a logic value transmission between the ATECC608A and the MCU begins with a start pulse (tSTART) of a specified duration. After the start pulse, the protocol defines a logic 0 as a cycle of a zero transmission high pulse (tZHI) followed by a zero transmission low pulse (tZLO) of specified duration. Similarly, a sustained high level signifies a logic 1 transmission.

In either case, the protocol expects a signal to go low within a specified bit time (tBIT). Following a series of bit transmissions, if the serial line becomes inactive after a specified IO timeout duration, the device can be programmed to automatically enter sleep mode. To work with the ATECC608A, however, developers rarely need to concern themselves with the timing details of this protocol: Microchip defined the key timing parameters to be compatible with a standard UART running at 230.4 Kbaud.

Device configuration

At the device level, the ATECC608A requires minimal configuration settings. Using the I2C or 1-wire serial interface, developers can load settings such as the I2C address or set a few features such as self-test on wakeup or power on. The device does provide a configuration setting that could be particularly relevant for ultra-low-power IoT designs.

In these designs, the ATECC608A adds relatively little to the overall power budget in its idle or sleep modes – likely the most common states in a typical IoT design. In idle mode, the device consumes about 800 microamps (μA); in sleep mode, power consumption is 150 nanoamps (nA) or less depending on configuration. When the MCU wakes the device to execute some security process, the device's power consumption still reaches only 14 milliamps (mA) during active operation. Even so, designs with very tight power budgets may require even lower active power levels.

To support these designs, the device provides a configuration option that lets developers select three different operating modes that trade execution speed for lower power consumption. Thus, developers can reduce active power consumption from 14 mA at maximum execution speed to 6 mA or 3 mA with correspondingly lower execution speeds.

Aside from various low level configuration items, a security device such as the ATECC608A is more effective when its secure information is already in place well before development. Mistakes or exploits of secure keys and certificates performed during development can obviate even the best security efforts. To address this possible threat, Microchip's trusted provisioning service loads secure data including keys and certificates as part of the manufacturing process.

After the secure information is loaded in a secure environment at the factory, it remains protected from accidental or intentional discovery even as the device passes through normal handling processes in the supply chain. The ATECC608A includes a special transport lock feature that disables use of the device until it is enabled cryptographically using a known key transmitted from the eventual host MCU.

Once enabled by the host MCU, the ATECC608A randomly generates a secret key called the IO protection key that it shares with the MCU. Subsequent communications between the ATECC608A and MCU are encrypted with this IO protection key – a mechanism that provides additional authentication during secure boot and other secure processes.

If hackers expect to spoof the validation process by cutting the connection to the ATECC608A and feeding their own "success" signal to the MCU, this IO protection key mechanism would cause the MCU to ignore the false signal. Even if a hacker would somehow compromise an ATECC608A device and try to use it on a different system, the IO protection key mechanism would effectively prevent its use.

Software integration

For all its sophisticated features and protection mechanisms, the ATECC608A remains straightforward to apply to an MCU-based design. Besides implementing the simple hardware interface and configuration settings mentioned earlier, developers work with an application programming interface (API) that abstracts the details of security operations. Microchip's CryptoAuthLib crypto authentication library provides a comprehensive software package with definitions, structures, and API calls required to take full advantage of ATECC608A features. The library serves as a hardware agnostic layer, working through the hardware abstraction layer (HAL) API and drivers for specific hardware targets (Figure 3).

Image of Microchip's CryptoAuthLib library

Figure 3: Microchip's CryptoAuthLib library provides a crypto services layer between an application and underlying hardware accessed through a hardware abstraction layer above hardware specific drivers, providing portability across different hardware sets. (Image source: Microchip Technology)

Developers use CryptoAuthLib API routines such as io_protection_set_key() to create an IO protection key and atcab_secureboot() to execute the ATECC608A's secure boot validation mechanism against the code digest or signature included in the calling parameters.

Although the API commands are straightforward, the specific setup, administrative, and operational steps required to implement security can be challenging. The very security mechanisms that developers are attempting to put into place can cause delays if key steps are missing or performed out of sequence.

Using Microchip's SAM D21 MCU-based ATSAMD21-XPRO development kit and its ATECC608A equipped ATCRYPTOAUTH-XPRO-B add-on board, developers can rapidly gain experience working with these general mechanisms and with the specific capabilities of the ATECC608A. Microchip offers an extensive secure boot software package designed to run on the ATSAMD21-XPRO and ATCRYPTOAUTH-XPRO-B, using a Microchip ATOLED1-XPRO to provide a basic display interface for sample applications (Figure 4).

Image of Microchip SAM D21 MCU-based ATSAMD21-XPRO development kit

Figure 4: Developers can rapidly evaluate the secure boot process using Microchip software and the SAM D21 MCU-based ATSAMD21-XPRO development kit combined with the ATECC608A equipped ATCRYPTOAUTH-XPRO-B add-on, and the ATOLED1-XPRO display add-on. (Image source: Microchip Technology)

Included in the SAM D21 demo package, a complete secure boot routine illustrates the key software design patterns used to set up, execute, and check the status of a secure boot operation (Listing 2). Using this hardware platform and demo software package, developers can rapidly evaluate use of the ATECC608A for remote boot and modify the sample software as needed to meet their own requirements.

Copy

/** \brief Handles secure boot functionality through initialization, execution,

 *         and de-initialization.

 *  \return ATCA_SUCCESS on success, otherwise an error code.

 */

ATCA_STATUS secure_boot_process(void)

{

    ATCA_STATUS status;

    secure_boot_parameters secure_boot_params;

    uint8_t secure_boot_mode;

    bool secure_boot_app_valid = false;

 

    /*Initialize secure boot */

    if ((status = secure_boot_init(&secure_boot_params)) != ATCA_SUCCESS)

    {

        return status;

    }

 

    do

    {

        .

        .

        .

        #if SECURE_BOOT_DIGEST_ENCRYPT_ENABLED

        .

        .

        .

        /*Get IO Protection Key*/

        if ((status = io_protection_get_key(secure_boot_params.io_protection_key)) != ATCA_SUCCESS)

        {

            return status;

        }

 

        if ((status = atcab_secureboot_mac(secure_boot_mode,

                                           (const uint8_t*)&secure_boot_params.app_digest,

                                           (const uint8_t*)&secure_boot_params.memory_params.signature,

                                           (const uint8_t*)secure_boot_params.randomnum,

                                           (const uint8_t*)secure_boot_params.io_protection_key,

                                           &secure_boot_app_valid)) != ATCA_SUCCESS)

        {

            break;

        }

        #else

        if ((status = atcab_secureboot(secure_boot_mode,

                                       0,

                                       (const uint8_t*)&secure_boot_params.app_digest,

                                       (const uint8_t*)&secure_boot_params.memory_params.signature,

                                       NULL)) != ATCA_SUCCESS)

        {

            break;

        }

        secure_boot_app_valid = true;

        #endif

 

        /*Check whether the secure boot command executed successfully with the correct return mac  */

        if (!secure_boot_app_valid)

        {

            break;

        }

        .

        .

        .

    }

    while (0);

 

    /* De-initialize memory interface and release its resources*/

    secure_boot_deinit_memory(&secure_boot_params.memory_params);

 

    return status;

}

Listing 2: This snippet from Microchip's SAM D21 demo package demonstrates the key design patterns for secure boot, including checking for an IO protection key (io_protection_get_key()) and validating the firmware using its digest, signature, and other parameters (atcab_secureboot_mac() or atcab_secureboot() depending on selected configuration). (Code source: Microchip Technology)

Conclusion

IoT devices present multiple threat surfaces for hackers intent on using compromised devices as an entry to IoT networks, applications, and enterprise resources. Among mitigation techniques, secure boot arises as a critical element in a broader security strategy. Yet, implementation of secure boot brings its own set of requirements that can leave the system exposed if not handled correctly.

The Microchip Technology ATECC608A security IC provides a comprehensive solution in a single package that developers can easily add to any MCU-based design. Using the ATECC608A, developers can dramatically enhance security and ensure secure boot in their IoT designs.