4.2.1 ATECC608B Example Application

Secure IoT Gateway Application Overview:

This application demonstrates the anti-cloning feature on the PIC32CM LS60 microcontroller (MCU). Initially, the host application initiates the symmetric authentication process of the client connected to it. The host also connects to AWS IoT cloud. The PIC32CM LS60 MCU host's connection to PIC32CM LS60 client MCU would be successful as the authentication (through the ATECC608B) would be successful because of the presence of ATECC608B Secure Element and the sensor data will be received by host and displayed on MIKROE OLED C Click board™, and this data will also be published to AWS cloud. However, the PIC32CM LE00 client would fail the authentication process as there is no inbuilt ATECC608B. If the authentication fails, the data will not be displayed on the host side or published to the cloud.

Authentication Sequence

The authentication begins with the PIC32CM LS60 MCU host asking for the serial number of the remote device (client). The host sends a random number, which it expects the remote device to hash with the shared secret key. This is called a challenge because it challenges the remote device to provide a correct answer.

The remote device hashes the random number with the shared key and the unique serial number. Then it sends back the resulting hash output, which is referred to as a Message Authentication Code (MAC). The host checks the returned MAC by repeating the same operation. It hashes the shared key with the random number and the unique serial number of the remote device. The host compares the two results. A matching result indicates that the remote device has successfully responded to the challenge and the host can trust the external device. This will be the case if the remote device is also PIC32CM LS60 MCU.

If the remote device is a PIC32CM LE00 (it does not have an ATECC608B), the authentication will fail.

The host also connects to the AWS IoT cloud. Once the SW0 button on the host device is pressed, the random number from the inbuilt ATECC608B is sent across the USART pins to the client, and the result is awaited. Once the client is authenticated, the sensor data is received and displayed on the MIKROE OLED C Click board. The data is also published to the AWS IoT Core at timely intervals. The LED0 on the host toggles each time the data is published to the cloud.

Figure 4-13. Block Diagram of Authentication

AWS Account Setup

In order to run the application, an Amazon Web Services (AWS) account is required. Refer to the readme.md for more information and steps to create an AWS account.

AWS Cloud IoT Provisioning

Microchip Trust Platform Design Suite (TPDS) tool helps provision the device (the ECC608B secure element) with the AWS cloud platform.

In the TPDS, launch the AWS IoT Authentication use case by following the steps mentioned in the section AWS Cloud IoT Provisioning Guide in the readme.md file and perform the provisioning.

Figure 4-14. Trust Platform Design Suite - AWS IoT Authentication Use-Case Transaction Diagram

Configuration

Host

In the following figure, blocks indicated in red show the ATECC608B secure element configuration in the Project Graph Window, and the CA_LIB indicates the CryptoAuth library. SERCOM1 is configured as an I²C to write data into slots of the ATECC608B element.

The SYS_CONSOLE configuration indicated in green facilitates communication to establish a WiFi connection. The SYS_CONSOLE enables console printing, and it allows the user to enter the command to establish a WiFi connection through CLI with SERCOM 5 configured as a UART to achieve this communication.

The block indicated in orange is for TrustZone provisioning, which enables TrustFLEX certificates.

Figure 4-15. Project Graph of the Host MCU

Client

Figure 4-16. Project Graph Configuration of an Authentic Client

The authentic client has a similar configuration to the host configuration but it does not have the Trust&Go module added to the project graph because it does not need to connect to the cloud or verify certificates with the cloud.

Figure 4-17. Project Graph Configuration of a Bad Client

The client device that is not authentic will not have the ATECC608B secure element, so the ATECC608B block is not present in the project graph. As it does not have ATECC608 secure element, it cannot respond to the challenge sent by the host device and the authentication fails.

Flowcharts - Host

Figure 4-18. Flowchart for Host Initialization

Figure 4-19. Flowchart for Host Cloud Connection

Figure 4-20. Flowchart for Host Authentication Initialization

slot_write() checks if the secret key in slot five and the I/O Protection key in slot six are written correctly. Slots in the ATECC608B secure element are data zones where keys are stored.

Note: Here, in the case of symmetric authentication, slot five is dedicated to store secret key shared between host and client.

The I/O Protection key in slot six ensures that data transmission occurs securely between the host and the client.

Flowcharts - Client

Figure 4-21. Application Flowchart of Client System Initialization

Figure 4-22. Application Flowchart of the Client

Figure 4-23. Overall Application Flowchart of the Client

Figure 4-24. Authentication Process

Implementation

This application uses the CryptoAuth library APIs to achieve symmetric authentication between host and client devices. ATCA_STATUS atcab_init(ATCAIfaceCfg* cfg) creates a global ATCA Device object used by basic API.

Returns ATCA_SUCCESS on success. Otherwise, an error code. This is used by check_device_type_in_cfg() to obtain the device details and initialize crypto operations on the device.

ATCA_STATUS atcab_info(uint8_t_revision ) uses the Info command to obtain the device revision (DevRev).

ATCA_STATUS atcab_read_serial_number (uint8_t_serial_number) is used in the application, which returns 9-byte serial number of the device.

ATCADeviceType get_device_type_id(uint8_t_revision_byte) checks the type of secure device present on the chip, for example, ATECC608B or ATECC508A.

APIs and Functions for Host project:

uint8_t slot_write(uint8_t slot_num) : Writes data to data zone slots of ATECC608B secure element.

uint8_t generate_RNG(): Generates a random number at the host to send to the client.

uint8_t calculate_host_mac(void): Calculates the MAC of the host device.

ATCA_STATUS mac_compare(void): Compares the MAC received from the client with the MAC generated at the host.

APIs and Functions for Client project:

secure_generate_device_mac(): Generates the device MAC of the client device.

secure_pass_sensor_data(): Sends sensor data to the host if the client is authentic.

secure_transmit_data(): Transmits the generated MAC and RNG(32 bytes) to the host for authentication.

secure_receive_data(): Receives a random number for MAC computation.

secure_receive_state(): Checks if a random number is received.

Analogy with Printers and Cartridges Use Case

A major challenge for printer and cartridge companies is counterfeiting. Let's explore how symmetric authentication secures these devices and ensures genuine cartridges are used.

In this scenario, the printer acts as the host MCU (PIC32CM LS60 Curiosity Pro) and the genuine cartridge is the client device (LS60). When a new cartridge is inserted, the printer initiates authentication. It sends a random number challenge to the cartridge.

The cartridge's secure element, the ATECC608B, verifies its authenticity. It calculates a Message Authentication Code (MAC) by hashing the random number with a shared secret key and the cartridge's unique serial number. The printer's ATECC608B performs the same calculation, generating its own MAC.

The printer then compares the received MAC from the cartridge with its own calculated MAC. If they match, the cartridge is deemed genuine (produced by the company, LS60 in this case), and printing proceeds. If the MACs do not match, authentication fails, indicating a counterfeit cartridge, and printing is blocked.