The Basics of Using the DS28S60

Introduction

This application note details how to use the DS28S60 cryptographic processor with the ChipDNA™. It describes the required set up of the DS28S60. Then it describes a step-by-step approach to use the asymmetric key exchange to securely generate a shared symmetric key between a host and a client. Next, it provides a walk through on how to use the symmetric key to exchange encrypted data between a Host and a Client. Finally, the note walks through an example of a bidirectional authentication process with the DS28S60 using an ECDSA.

Terminology Defined

Let us look at the terminology used in this application note:

• Device or Client - the device that contains the DS28S60. It needs to communicate with the Host. For example, a sensor node.
• Host or Remote Peer - entity that needs to communicate with the device. For example, an application server.
• Authority - trusted party that creates certificates using the authority key pair, that the Device and Remote Peer can use to verify each other as a part of the system.

Figures 1 and 2 show how the Device, Client, and Authority interact with each other at a high level in the system.

Basic Commands and Device Factory Setup

Set up the device first before using the DS28S60 in the field for the security needs. This involves installing and/or generating device key pairs, secrets, and certificates. This is done at a secure location such as a factory.

DS28S60 setup steps:

1. Generate and install the device public key pair:
   
   
   1. First, use the Generate ECC-256 key pair command to generate and install an ECDSA key pair for the device to the key pair A memory block. Note, instead of having the DS28S60 generate its own key pair, it is possible to use the write memory command to write a key pair created elsewhere to the DS28S60.
   2. Next, use the set block protection command to write protect the key pair block A so that this key pair cannot be modified.
2. Have the authority create the certificate for the public key:
   
   
   1. After installing the device key pair, send the public key along with the DS28S60's ROM ID and MAN ID to the Authority so that it can generate a certificate for the key pair (Figure 3). Note that the ROM ID and MAN ID are data elements programmed into the device during the Maxim manufacturing.
3. Write the certificate to the DS28S60:
   
   
   1. Write the certificate to the user memory pages once the generated certificate is received.
4. Write the authority public key and feature data to the DS28S60:
   
   
   1. Write the authority public key to the authority key A block. Refer to the DS28S60 user guide for the device memory map and more information. Once the key is written, write protect the authority key A block to prevent it from being modified.
   2. Next, write any feature data to the DS28S60. The feature data can be any data required for the application such as testing information, serial number, device trim information, manufacturing date, etc. Use as many pages as necessary.
5. Set the appropriate protection on the installed keys, secrets, and certificates:
   
   
   1. Write protect (WP) the device certificate and feature data once the feature data is written. If different protections are needed for the feature data, place them in a different memory block. Use the set block protection command to set the WP protection.
6. Lockout the unused key pair blocks and secret blocks.
   
   
   1. Finally, write the randomly generated data to each of the unused secret and key pages, and write protect them to prevent them from being used.

Encrypted Communication Using the Asymmetric Key Exchange

The Host and Device each generate an ECDSA key pair referred to as the ephemeral key pair to set up an encrypted channel. New ephemeral key pairs must be generated for each communication session. Once the keys are generated, the Host and the Device use the ECDHE Key Exchange to securely calculate a shared secret to encrypt and decrypt in a subsequent AES-GCM session.

Encrypted Channel Creation Steps

1. The Host generates its ephemeral key pair.
2. The Device generates its ephemeral key pair:
   
   
   1. The Device uses the generate ECC-256 key pair command to generate an ephemeral key pair.
   2. Specify the ephemeral key 0 as the storage location. Note: The ephemeral key storage pages lose the key pair if the DS28S60 loses power.
3. The Host requests and receives the Device's ephemeral public key.
4. The Device requests and receives the Host's ephemeral public key.
5. The Host uses the ECDHE to calculate the shared secret (Figure 4).
6. The Device uses the ECDHE to calculate the shared secret (Figure 4).
   
   
   1. Issue the key exchange command to the DS28S60 to calculate the shared secret.

   

7. The Host and Device can now use the AES-GCM to send encrypted data and decrypt the received data (Figure 5).

Bidirectional Authentication

Bidirectional authentication has two stages. The Host and Device verify that each other's public key is a part of the system in the first stage by using the certificates created by the Authority along with the Authority's public key (Figure 6). Once the public keys are verified, the Host and the Device verify in the second stage that they each possess the private keys that correspond to the verified public keys. This is accomplished by exchanging signatures generated with their respective private keys and using the verified public keys to verify the signatures. Figures 7 and 8 show the private key verification process.

Stage 1. Public Key Verification

1. The Host requests and receives the Device's public key:
   
   
   1. When the Host requests the Device's public keys, the Device reads the public keys from the DS28S60 using the read memory command twice to read the public key A x and y components, and then send the public key to the Host.
2. The Host requests and receives the Device's certificate and certificate message data:
   
   
   1. When the Device gets the request for its certificate, it uses the read memory command to read its certificate from its user pages from the DS28S60, and then transmit it to the Host.
3. The Device requests and receives the Host's public key:
   
   
   1. When the Device requests and receives the Host's public key, it uses the write memory command to write it to the public key SA block.
4. The Device requests and receives the Host's certificate and certificate message data.
5. The Host verifies the Device's certificate by passing the certificate, SHA-256 hash of the certificate message data, and Authority public key to the ECDSA verification algorithm.
6. The Device verifies the Host's certificate by passing the certificate, SHA-256 hash of the certificate message data, and Authority public key to the ECDSA verification algorithm.
   
   
   1. The Device uses the authenticate ECDSA certificate command specifying the PUBKEY_SA for the key, setting ECDH = 0 and WPE = 0, and passing the certificate along with the certificate data to verify the Host's certificate. Refer to the user guide for details about the command.

Stage 2. Private Key Verification

1. The Host generates the 32-byte challenge and requests the Device to generate a signature using the challenge and some page data.
2. The Device responds with signature and data used to generate the signature:
   
   
   1. Once the Device receives the challenge, it uses the compute and read page command to generate a signature using the feature data page. Once the signature is generated, the device sends the signature along with the message data used for the signature generation, which is the DS28S60's Rom ID, feature data, feature data page number, and Man ID, Command byte (0xA5).
3. The Device generates the 32-byte challenge and requests the Host to generate a signature using the challenge and some data:
   
   
   1. The Device generates a 32-byte challenge by using the read RNG command on the DS28S60. Once the challenge is generated, the Device sends the challenge to the Host, requesting the Host to generate a certificate.
4. The Host responds with the signature and data used to generate the signature:
   
   
   1. The Host generates a signature using the challenge and some data using the following format: challenge || data. The Host sends the challenge along with the data used to generate the signature to the Device.

      

5. The Host verifies the Device's signature using the ECDSA verification algorithm by providing it the Device's public key, SHA-256 hash of the data with the challenge and signature.
6. The Device verifies the Host's signature using the ECDSA verification algorithm by providing it the Host's public key, SHA-256 hash of the data with the challenge and signature:
   
   
   1. Once the Device receives the signature and data, it appends the data to the challenge it sent to the Host, uses the DS28S60 verify signature command specifying the public key SA, and uses the message as the ECDSA input parameter.

Recommended Infield Flow

Now that the building blocks are covered, let us discuss how to put them together. The setup steps are done in a secure trusted location such as the factory. Once the setup is done, the Device is out in the field, and the Host is up and running, the Device and Host first establish an encrypted channel using the steps described above. Once the encrypted channel is established, the Device and Host authenticate each other to ensure they are a part of the same system. They start communicating with each other once they mutually authenticate each other successfully.

Summary

This application note covers the required commands and steps to set up and use the DS28S60 as part of a system that requires mutual authentication and a secure encrypted communication channel.

Trademarks

ChipDNA is a trademark of Maxim Integrated.