An Easier Solution for Securely Connecting IoT Devices to the Cloud

Por Stephen Evanczuk

Colaboración de Editores de Digi-Key de América del Norte

Despite growing awareness of the need for security, developers too often find themselves taking shortcuts in security for connecting IoT devices to the cloud. In many cases, the conflicts between the complexity of suitable security mechanisms, the limited memory and processing resources available in tiny battery powered IoT devices, and the need to ship product, seem insurmountable.

To address these problems and simplify implementation of security features in IoT devices, Microchip Technology and Google collaborated to create an approach that combines Microchip’s secure hardware capabilities with a simple data structure called a JSON Web Token (JWT). The result is an easy method for ensuring mutual authentication between IoT devices and Google Cloud IoT Core services.

This article will describe the IoT device security threat and introduce devices currently being used to counter that threat. It will identify the security gaps and how developers and embedded system designers can use JWT to close them.

The security vulnerability of IoT devices

Attacks on IoT devices can take many forms and are by no means confined to large scale IoT deployments. Even the smallest IoT network is an attractive target to hackers looking to harness the resources of many individual devices in botnets intended for distributed denial of service (DDoS) attacks and others. As a result, designers of every class of IoT device inevitably face the necessity of protecting their systems with robust hardware-based security mechanisms able to thwart attack.

For example, the use of system memory or flash to store private keys used for encryption and authentication, leaves the IoT device vulnerable. Worse, hackers can steal those keys and use them to gain access to the IoT network and attached corporate resources.

Security ICs

Specialized security devices such Microchip Technology’s CryptoMemory and CryptoAuthentication ICs feature hardware-based mechanisms to protect private keys and other secret data. Integrated in these devices, an EEPROM array provides secure storage that can only be reached through cryptographically secure mechanisms accessed through the device's SPI or I2C serial interface (Figure 1). As a result, these devices provide a simple method to add secure storage and other security features to any IoT device design.

Diagram of Microchip Technology the AT88SC0204C CryptoMemory IC

Figure 1: Microchip Technology hardware security devices such as the AT88SC0204C CryptoMemory IC provide secure storage, using integrated cryptographic mechanisms to protect access to on-chip EEPROM. (Image source: Microchip Technology)

Members of the Microchip CryptoAuthentication family such as the ATECC608A enhance that secure storage foundation with support for cryptography algorithms commonly used in secure designs. Among its hardware features, the device features hardware acceleration for multiple algorithms including:

  • Asymmetric cryptography algorithms:
    • FIPS186-3 elliptic curve digital signature algorithm (ECDSA)
    • FIPS SP800-56A elliptic curve Diffie-Hellman (ECDH)
    • NIST Standard P256 elliptic curve cryptography (ECC)
  • Symmetric cryptography algorithms:
    • SHA-256 hash cryptography
    • Hash-based message authentication code (HMAC) cryptography
    • AES-128 cryptography
    • AES-GCM (Galois field multiply) cryptography
  • Key derivation functions (KDFs):
    • Pseudorandom function (PRF) KDF
    • HMAC-based extract-and-expand KDF (HKDF)

For cryptography experts, this set of crypto features represents a comprehensive list of mechanisms needed to support higher level security protocols for authentication and secure data exchange. For example, the KDF capability provides essential mechanisms required for the transport layer security (TLS) protocol for authenticating participants in a data exchange session before that exchange even begins.

In this protocol, a TLS session begins with a client sending the server a request to initiate a secure session. The server responds with its digital certificate, which the client uses to confirm the identity of the server. After the client authenticates the server in this way, session setup proceeds with the client generating a session key by using the server's public key to encrypt some random value created using a PRF KDF or more robust HDKF.

The TLS authentication protocol is fundamental to Internet security. An entire industry of certificate providers, called certificate authorities (CAs), has evolved to support this critical component of secure communications. Companies acquire trusted certificates from CAs to install on their own servers to support the standard TLS server authentication protocol described above.

For IoT applications, where networks connect broadly and deeply with corporate sources, this kind of one-way authentication is not enough to ensure protection. For example, hackers with fraudulent certificates could represent themselves as legitimate servers to IoT devices as part of a broader attack.

Despite the risk, IoT developers often struggle to implement the TLS mutual authentication protocol because the certificates, keys, and software needed to implement client authentication with TLS can exceed the capabilities of many IoT devices. Working in collaboration, Microchip Technology and Google have created an alternative approach that combines ATECC608A capabilities with a simple data structure called a JSON Web Token (JWT). The result is an easy method for ensuring mutual authentication between IoT devices and Google Cloud IoT Core services.

JWT-based authentication

Specified in RFC 7519, the JWT is an industry standard container for information, called claims, about the entity that prepares and transmits the JWT. The JWT structure itself comprises three sections:

  • Header, which includes JSON name:value pairs for the name ("alg") of the cryptography algorithm (for example, "EC256" for ECDSA using the NIST P-256 curve) used to sign the token and for the type ("typ") of token ("JWT" for these tokens)
  • Payload, which includes JSON name:value pairs for each claim
  • Signature, which uses the algorithm specified in the header to encode a secret key along with the header and claim set, each separately converted to base64 URL-encoded representation before encryption

RFC 7519 provides a great deal of flexibility for specifying claims in the payload or other sections. The standard even allows for unsecured JWTs, created without a signature or encryption, in which case, the header would include the name:value pair for the algorithm as {"alg":"none"}. For JWTs used with Google Cloud IoT Core services, Google requires the signature section as well as a payload with three mandatory claims including:

  • "iat" – the "issued at" time when the token was created in ISO 8601 UTC timestamp format as seconds since 1970-01-01T00:00:00Z (for example, 1561896000 for June 30, 2019 12:00:00 PM GMT)
  • "exp" – the UTC timestamp that specifies token expiration with a maximum 24 hours past "iat" value plus a ten-minute grace period to account for system clock skew between different clients and servers (for example, 1561982400 for July 1, 2019 12:00:00 PM GMT)
  • "aud" – a string containing the developer's Google Cloud project ID

Google's scheme for IoT device authentication blends normal server authentication based on TLS with IoT device authentication using a JWT created with these relatively simple claims. To start a new session, an IoT device opens a secure socket to the server and authenticates the server using the same TLS protocol described previously.

The next step in this process relies on the Google IoT cloud's use of the lightweight message queueing telemetry transport (MQTT) protocol for IoT network transactions. Using the secure socket to the authenticated server, the IoT device "logs in" to that server's MQTT host services, using its unique JWT as the login password (Listing 1).

Copy
/* Populate the buffer with the username */
int config_get_client_username(char* buf, size_t buflen)
{
    if(buf && buflen)
    {
        int rv = snprintf(buf, buflen, "unused");
 
        if(0 < rv && rv < buflen)
        {
            buf[rv] = 0;
            return 0;
        }
    }
    return -1;
}
 
/* Populate the buffer with the user's password */
int config_get_client_password(char* buf, size_t buflen)
{
    int rv = -1;
 
    if(buf && buflen)
    {
        atca_jwt_t jwt;
        
        uint32_t ts = time_utils_get_utc();
 
        rv = atcab_init(&cfg_ateccx08a_i2c_default);
        if(ATCA_SUCCESS != rv)
        {
            return rv;
        }
 
        /* Build the JWT */
        rv = atca_jwt_init(&jwt, buf, buflen);
        if(ATCA_SUCCESS != rv)
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "iat", ts)))
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "exp", ts + 86400)))
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_string(&jwt, "aud", config_gcp_project_id)))
        {
            return rv;
        }
 
        rv = atca_jwt_finalize(&jwt, 0);
 
        atcab_release();
    }
    return rv;
}

Listing 1: Included in the Microchip Technology software sample repository for Google Cloud Platform IoT Core, a module provides routines for generating a dummy username and JWT object for use as the password for client authentication with an MQTT host. (Code source: Microchip Technology)

Although the IoT device sends a username as part of this login sequence, the username is not used for authentication. Consequently, a dummy username is transmitted (Listing 2). Instead, authentication of the IoT device proceeds based on the JWT sent as the login password. Because the JWT signature is a combination of the header, payload, and the device's private key, Google Cloud IoT Core services can verify that the JWT truly originates from an authorized device. For this verification, Google Cloud IoT services uses the device's public key that was previously stored in the Google cloud by the IoT device developer using a key management process described below. In contrast with the use of TLS alone, this approach provides mutual authentication through a hybrid approach that speeds the process, while reducing IoT device resource requirements.

Copy
/* Connect the MQTT Client to the host */
static int client_connect(void* pCtx)
{
    MQTTPacket_connectData mqtt_options = MQTTPacket_connectData_initializer;
    struct _g_client_context* ctx = (struct _g_client_context*)pCtx;
    size_t buf_bytes_remaining = CLIENT_MQTT_RX_BUF_SIZE;
 
    mqtt_options.keepAliveInterval = MQTT_KEEP_ALIVE_INTERVAL_S;
    mqtt_options.cleansession = 1;
 
    /* Client ID String */
    mqtt_options.clientID.cstring = (char*)&ctx->mqtt_rx_buf[0];
    if(config_get_client_id(mqtt_options.clientID.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    /* Username String */
    mqtt_options.username.cstring = mqtt_options.clientID.cstring + strlen(mqtt_options.clientID.cstring) + 1;
    buf_bytes_remaining -= (mqtt_options.username.cstring - mqtt_options.clientID.cstring);
    if(config_get_client_username(mqtt_options.username.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    /* Password String */
    mqtt_options.password.cstring = mqtt_options.username.cstring + strlen(mqtt_options.username.cstring) + 1;
    buf_bytes_remaining -= (mqtt_options.password.cstring - mqtt_options.username.cstring);
    if(config_get_client_password(mqtt_options.password.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    return MQTTConnect(&ctx->mqtt_client, &mqtt_options);
}

Listing 2: Provided in the Microchip software sample repository, this function demonstrates the use of a JWT object as password that authenticates the IoT device to the MQTT server during the initial connection phase. (Code source: Microchip Technology)

Critical enablers

The capabilities of the ATECC608A and its supply chain are the critical enablers for this approach. Although any MCU could eventually generate a cryptographically encrypted signature from the JWT header and payload, any approach performed solely with software would still be vulnerable without hardware-based secure key storage. In addition, the processor load and execution delay required for a “software only” implementation could be prohibitive for many resource limited IoT devices or applications with tight response time requirements. Finally, developers without extensive experience in security algorithms and higher level protocols would be hard pressed to implement the required software functionality. Microchip addresses these concerns with its CryptoAuthLib library (Figure 2).

Diagram of CryptoAuthLib hardware abstraction layer (HAL)

Figure 2: Because the CryptoAuthLib uses a hardware abstraction layer (HAL) to separate the API functions and core primitives from underlying hardware, developers can target their software for a wide range of support devices. (Image source: Microchip Technology)

The Microchip CryptoAuthLib simplifies implementation of secure IoT features such as the Google JWT authentication protocol, reducing complex security operations to a set of function calls provided through the CryptoAuthLib application programming interface (API). Perhaps of most importance to IoT developers, the Microchip CryptoAuthLib core functions take full advantage of Microchip crypto ICs such as the ATECC608A to speed execution of security features in a design. For example, the call to atca_jwt_finalize() in Listing 1 uses an available crypto device such as the ATECC608A to create the JWT used as the password in Listing 2. In this case, the ATECC608A accelerates encryption of the JWT signature, reading the design's private key from its integrated secure storage to complete the signature creation process described earlier.

Even with the use of sophisticated software and security devices, however, IoT devices can remain vulnerable due to methods traditionally needed to manage keys and certificates. In the past, private keys needed to be generated externally and loaded into secure storage devices during manufacturing, distribution, or even deployment. Even with the use of hardware security modules and secure facilities, the ephemeral existence of these secrets outside of the only device that "needs to know" them represents a security weakness that can lead to their exposure by accident or intent. By leveraging the capabilities of the ATECC608A, Microchip and Google have largely eliminated this traditional weakness in security.

In this new approach, Microchip uses the ATECC608A's ability to generate key pairs without the private keys ever leaving the device (Figure 3). Microchip then signs the device generated public keys with an intermediate certificate that was provided by the customer and stored in a secure server within the Microchip secure facility. Finally, Microchip securely transmits the public keys to the customer's account in Google Cloud IoT Device Manager, which can store up to three public keys for each device to support key rotation policies. Once deployed, an IoT device can use ATECC608A security features to create the JWT used in the mutual authentication process described previously.

Diagram of Microchip Technology and Google Cloud IoT services (click to enlarge)

Figure 3: Microchip Technology and Google Cloud IoT services combine to simplify provisioning of keys and certificates, providing a protected mechanism designed to harden security for IoT applications. (Image source: Google)

This collaboration between Microchip and Google lets developers completely offload this critical key management process. For custom requirements, developers can nevertheless implement their own key management process, using the CryptoAuthLib API function atcab_genkey(), which causes the ATECC608A to generate a key pair, store the private key in its secure storage, and return the associated public key.

To explore key generation and other ATECC608A security capabilities, developers can quickly set up a comprehensive development environment built around the Microchip SAM D21 Xplained Pro evaluation kit. Based on the Microchip ATSAMD21J18A 32-bit Arm® Cortex®-M0+ MCU, the SAM D21 Xplained Pro kit provides a complete hardware platform supported by the Microchip Advanced Software Framework (ASF) of drivers and code modules.

For evaluating CryptoAuthentication devices including the ATECC608A, developers can simply plug a CryptoAuth XPRO-B add-on board into one of the Xplained Pro board's two expansion headers. Microchip provides sample software for evaluating security functionality of the CryptoAuthLib with the ATECC608A. Going further, developers can plug a Microchip ATWINC1500-XPRO Wi-Fi add-on board into the other header to run Microchip sample software that demonstrates the mutual authentication flow described in this article, including both TLS server authentication and JWT device authentication.

Conclusion

Although IoT application security brings multiple requirements, a critical challenge often lies in implementing mutual authentication for IoT devices and cloud resources. In resource-limited IoT systems, conventional protocols can exceed available memory and processing resources. Using the Microchip Technology CryptoAuthLib library and ATECC608A CryptoAuthentication IC, developers can implement a more efficient approach based on JSON Web Tokens for securely connecting IoT devices to Google Cloud IoT services.

Descargo de responsabilidad: Las opiniones, creencias y puntos de vista expresados por los autores o participantes del foro de este sitio web no reflejan necesariamente las opiniones, las creencias y los puntos de vista de Digi-Key Electronics o de las políticas oficiales de Digi-Key Electronics.

Acerca de este autor

Stephen Evanczuk

Stephen Evanczuk tiene más de 20 años de experiencia escribiendo para y sobre la industria de electrónica en un amplio rango de temas, entre ellos hardware, software, sistemas y aplicaciones, que incluyen IoT. Se doctoróen neurociencias (redes neuronales) y trabajó en la industria aeroespacial en sistemas seguros con distribución masiva y métodos de aceleración de algoritmos. Actualmente, cuando no escribe artículos sobre tecnología e ingeniería, trabaja en aplicaciones de aprendizaje profundo sobre sistemas de reconocimiento y recomendaciones.

Acerca de este editor

Editores de Digi-Key de América del Norte