A secure solution that connects IoT devices to the cloud

　　Although people are increasingly aware of the need for security, developers often find themselves taking shortcuts to connect IoT devices to the cloud. In many cases, the conflict between the complexity of appropriate safety mechanisms, the limited memory and processing resources available in microbattery-powered IoT devices, and the demand for transporting products seems insurmountable.

　　To address these issues and simplify the implementation of security features in IoT devices, Microchip Technology and Google have collaborated to create a method that combines Microchip's secure hardware features with a simple data structure called JSON Web Token (JWT). The result is a simple way to ensure mutual authentication between IoT devices and Google Cloud IoT core services.

　　This article will introduce security threats to IoT devices and present the devices currently used to address these threats. It will identify security vulnerabilities and how developers and embedded system designers use JWT to shut them down.

　　Security vulnerabilities in IoT devices

　　Attacks on IoT devices can take many forms and are far from limited to large-scale IoT deployments. For hackers looking to exploit resources from many individual devices in botnets used for distributed denial-of-service (DDoS) attacks, even the smallest IoT is an attractive target. Therefore, designers of every type of IoT device inevitably need to protect their systems through robust hardware-based security mechanisms to prevent attacks.

　　For example, using system memory or flash storage to store private keys for encryption and authentication makes IoT devices vulnerable to attacks. Worse still, hackers can steal these keys and use them to access IoT networks and additional company resources.

　　Safety IC

　　Dedicated security devices such as Microchip Technology's CryptoMemory and CryptoAuthentication ICs feature hardware functions based on mechanisms to protect private keys and other secret data. EEPROM arrays are integrated into these devices, providing secure storage and encryption security mechanisms accessible only through the device's SPI or I2C serial interface (see Figure 1). Therefore, these devices offer a simple way to add secure storage and other security features to any IoT device design.

　　Figure 1: Microchip Technology hardware security devices (such as AT88SC0204C CryptoMemory IC) provide secure storage and use integrated encryption mechanisms to protect access to on-chip EEPROMs. (Image: Microchip Technology)

　　Members of the Microchip CryptoAuthentication series (such as ATECC608A) enhance the foundation of secure storage and support encryption algorithms commonly used in security design. Among its hardware features, the device features hardware acceleration for various algorithms, including:

　　Asymmetric Encryption Algorithm:

　　FIPS186-3 Elliptic Curve Digital Signature Algorithm (ECDSA)

　　FIPS SP800-56A Elliptic Curve Diffie-Hellman (ECDH)

　　NIST Standard P256 Elliptic Curve Encryption (ECC)

　　Symmetric encryption algorithm:

　　SHA-256 hash code

　　Hash-based Message Authentication Code (HMAC) cryptography

　　AES-128 Cryptography

　　AES-GCM (Galois Field Multiplication) cryptography

　　Key Derivation Function (KDF):

　　Pseudo-random function (PRF) KDF

　　HMAC-based extraction – and expanding KDF (HKDF)

　　For crypto experts, this set of encryption features represents a comprehensive list of mechanisms needed to support higher-level security protocols. Authentication and secure data exchange. For example, the KDF feature provides the basic mechanisms required for Transport Layer Security (TLS) protocols to verify participants in data exchange sessions before exchanges or even begin.

　　In this protocol, TLS sessions send requests from clients to the server to initiate a secure session. The server responds using its digital certificate, which the client uses to confirm the server's identity. After the client verifies the server in this way, the session settings continue to generate session keys using the server's public key to encrypt some random values created using PRF KDF or the more powerful HDKF.

　　The TLS authentication protocol is the foundation of Internet security. The entire certificate provider industry, known as Certificate Authority (CA), has evolved into a key component supporting secure communications. The company obtains a trusted certificate from the CA to install on its own servers, supporting the aforementioned standard TLS server authentication protocol.

　　For IoT applications, networks are widely and deeply connected to companies, and such one-way authentication is insufficient to guarantee protection. For example, hackers with fraudulent certificates could present themselves as legitimate servers for IoT devices as part of a broader attack.

　　Despite the risks, IoT developers often struggle to implement TLS mutual authentication protocols because certificates, keys, and software required for client authentication using TLS may exceed the capabilities of many IoT devices. Through collaboration, Microchip Technology and Google have created an alternative approach that combines ATECC608A functionality with a simple data structure called JSON Web Token (JWT). The result is a simple way to ensure mutual authentication between IoT devices and Google Cloud IoT core services.

　　Authentication based on JWT

　　RFC 7519 specifies that JWT is an industry-standard container for information about the entity preparing and transmitting JWT, known as a claim. The JWT structure itself consists of three parts:

　　Titles, including the JSON name: the name of the cryptographic algorithm ("alg") (for example, ECDSA's "EC256" uses the NIST P-256 curve) for signing tokens and token types ("typ") (the "JWT" of these tokens)

　　Payload, including the JSON name: value pair for each claim

　　Signature: It uses the algorithm specified in the header to encode the key, header, and declaration set, each individually converted into the base64 URL encoding before encryption

　　RFC 7519 offers great flexibility for specifying claims in payloads or other parts. The standard even allows unsafe JWTs created without signature or encryption, in which case the header will include the algorithm's name: value pair {{alg":"none"}. For JWTs used with Google Cloud IoT core services, Google needs a signature section and a payload containing three mandatory declarations, including:

　　"iat" - The "issuance time" when creating the token in ISO 8601 UTC timestamp format, the number of seconds since 1970-01-01T00:00:00Z (for example, 1561896000 12:00 GMT on June 30, 2019)

　　"exp" - The UTC timestamp specifying the token expiration time, up to 24 hours exceeding the "IAT" value plus a 10-minute grace period, to address different system clock biases between client and server (e.g., July 1, 2019 1561982400, GMT 00:00 00:00)

　　"aud" - a string containing the developer's Google Cloud project ID

　　< p> Google's IoT device authentication solution combines conventional TLS-based server authentication with JWT created with these relatively simple declarations for IoT device authentication. To start a new session, the IoT device opens a secure socket to the server and authenticates the server using the same TLS protocol described earlier.

　　The next step in this process relies on Google IoT Cloud's lightweight message queue telemetry transmission (MQTT) protocol for IoT network transactions. Using a secure socket to an authenticated server, the IoT device uses its unique JWT as the login password to "log into" the MQTT host service on that server (Inventory 1).

　　Although IoT devices send usernames as part of this login sequence, usernames are not used for authentication. Therefore, a virtual username (Listing 2) was transferred. Instead, IoT device authentication is based on JWT sent as the login password. Since JWT signatures are a combination of headers, payloads, and device private keys, Google Cloud IoT core services can verify whether JWT truly comes from authorized devices. For this verification, Google Cloud IoT Services uses device public keys previously stored in Google Cloud by IoT device developers using the key management process described below. Compared to using TLS alone, this approach provides mutual authentication through a hybrid approach, speeding up processes while reducing resource requirements for IoT devices.

　　Key enablers

　　ATECC608A and the functionality of its supply chain are key drivers of this approach. While any MCU can eventually generate encrypted encryption signatures from JWT headers and payloads, any software-only method is still vulnerable to attacks without hardware-based security key storage. Additionally, for many resource-limited IoT devices or applications with strict response time requirements, processor load and execution latency required for "software-only" implementation may be prohibited. Finally, without extensive security algorithms and more advanced protocol experience, it is difficult for developers to implement the required software functions. Microchip addresses these issues through its CryptoAuthLib library (Figure 2).

　　Figure 2: Because CryptoAuthLib uses the hardware abstraction layer (HAL) to separate API functions and core primitives from the underlying hardware, developers can position their software for various supporting devices. (Image: Microchip Technology)

　　Microchip CryptoAuthLib simplifies the 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). For IoT developers, perhaps the most important is the Microchip CryptoAuthLib core feature that fully leverages Microchip encryption ICs such as ATECC608A to accelerate the execution of security features in design. For example, in Listing 1, a call to atca_jwt_finalize() uses available encryption devices (such as ATECC608A) to create a JWT for the password in Listing 2. In this case, ATECC608A accelerate the encryption of JWT signatures, read the design from its integrated secure storage key to completing the signature creation process described earlier.

　　However, even with complex software and security devices, IoT devices remain vulnerable to attacks due to traditional methods for managing keys and certificates. In the past, private keys had to be generated externally and loaded onto secure storage devices during manufacturing, distribution, or even deployment. Even when using hardware security modules and security facilities, briefly existing secrets beyond the only device "need-to-know" them represents security vulnerabilities that could be accidentally or intentionally exposed. By leveraging ATECC608A capabilities, Microchip and Google have largely eliminated traditional security vulnerabilities.

　　In this new approach, Microchip uses the ATECC608A's ability to generate key pairs without leaving the device with a private key (Figure 3). Microchip then uses an intermediate certificate to sign the public key generated by the device, which is provided by the customer and stored on a secure server within Microchip's security facilities. Finally, Microchip securely transmits the public key to the customer account in the Google Cloud IoT Device Manager, which can store up to three public keys per device to support key rotation policies. After deployment, IoT devices can use ATECC608A security features to create JWTs used in the mutual authentication process described earlier.

　　Figure 3: The combination of Microchip Technology and Google Cloud IoT services simplifies key and certificate configuration, providing a protected mechanism aimed at strengthening IoT application security. (Image: Google)

　　This collaboration between Microchip and Google allows developers to completely offload this critical key management process. For custom requirements, developers can use the CryptoAuthLib API function atcab_genkey() to implement their own key management process, which leads to ATECC608A generate key pairs, store private keys in their secure storage, and return the associated public key. /p>

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

　　To evaluate CryptoAuthentication devices, including ATECC608A, developers can simply insert the CryptoAuth XPRO-B add-on board into one of the two extension heads of the Xplained Pro board. Microchip provides example software for evaluating the security features of CryptoAuthLib and ATECC608A. Furthermore, developers can insert the Microchip ATWINC1500-XPRO Wi-Fi add-on board into another header to run Microchip sample software, which demonstrates the mutual authentication process described in this article, including TLS server authentication and JWT device authentication.

　　Conclusion

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