DS28S60 Based Bidirectional Authentication Example Using Jupyter Notebook

要約

This application note details the basic application of bidirectional authentication using the DS28S60 in tandem with the associated Jupyter notebook. It uses a step-by-step approach to walk through setting up the device and all associated software, creating a shared secret used to encrypt data via ECDHE Key Exchange, encrypting and decrypting data using AES-GCM, and completing mutual authentication via ECDSA Signature Generation and Verification.

Introduction

This application note discusses how to operate the DS28S60 cryptographic processor by outlining a step-by-step approach for using the device to set up a host and client-based system for key generation and exchange, encryption, and bidirectional authentication. This usage is detailed in the accompanying Jupyter notebook. First, let us discuss generating a shared secret or shared symmetric key to be used by the host and client through asymmetric key exchange. Next, let us outline using the shared symmetric key to encrypt communication between the device and the host. Finally, let us walk through the mutual authentication process using digital certificates and signatures.

System Encryption Overview

Before any data is exchanged among the members of a system, the DS28S60 first secures the communication among the parties by creating an encrypted channel. The parties in this example include the device, host, and third-party authority:

  • Device: Also known as the client. This is the entity that contains the DS28S60, and it must communicate with the host. For example, this could be a sensor node.
  • Host: Typically, a server or a computer. This is the entity that must communicate with the device.
  • Authority: Known as the third-party/certificate authority. This is a trusted party that provides certificates to both the host and device to verify one another.

Figure 1 shows the interaction between the Host and Device to establish and use an encrypted channel.

Figure 1. System overview of encrypted communication channel.

Figure 1. System overview of encrypted communication channel.

System Authentication Overview

System authentication, in short, is the process of verifying the public and private keys of both the host and the device to validate the identity of each party. Note that the communication between all parties is encrypted before any exchange of data pertaining to the key pairs or any other sensitive information is initiated. Figure 2 shows the interaction between the Host, Device, and Authority during the authentication process.

Figure 2. System overview of bidirectional authentication using the help of an authority entity

Figure 2. System overview of bidirectional authentication using the help of an authority entity

Hardware, Software, and Factory Setup

Hardware Setup


To run the Jupyter notebook for the DS28S60, two pieces of hardware excluding the DS28S60 are required, which are a part of the DS28S60 EV kit.

  • DS9121EQ+ evaluation TDFN socket board that acts as a hub for and holds the DS28S60 processor.
  • The DS9482P# USB-to-I2C/SPI/1-Wire adapter that connects the DS9121EQ+ socket board and the host.

Use the USB Micro B cable included in the EV kit to connect the host computer with the DS9482P# adapter.


Software Setup


Now that the hardware is configured, the next step is to acquire and initialize the software to run the Jupyter Notebook. These steps are as follows:

  1. Download a recent version of Python and its associated libraries to run the Jupyter Notebook:

    1. Visit Download Python | Python.org and download the most recent version of Python (check the 'Add Python to path' option when installing).
    2. Once Python is installed, if using Windows, open a command prompt or any similar terminal. To install a library, enter

      pip install *TARGET LIBRARY*

      The following libraries are needed to run the notebook.

      1. ecdsa
      2. pyserial
      3. cryptography
      4. pycryptodome
      5. AES
      6. SPI
  2. Install and run the Jupyter Notebook, then navigate to the DS28S60 Notebook folder and run the DS28S60 Jupyter Notebook file 'DS28S60_KeyExchange.ipynb'. For instructions to download the Jupyter Notebook, visit Project Jupyter | Installing Jupyter.

Note: Check that the packages are installed correctly, and the hardware is connected and working successfully by running the first two blocks of code in the Jupyter Notebook under the Hardware Connection Setup section.


Factory Setup: ECDSA Key Generation and Certificate Distribution


To generate the shared secret or shared symmetric key, first generate the public and private key for both the host and device.

The following steps outline the installation and storage of the key pairs, and the distribution of certificates. Note: From this point forward in the application note, each numbered step has one or more associated code segments in the Jupyter notebook that must be run sequentially to walk through the bidirectional authentication.

  1. Generate the host's elliptic curve digital signature algorithm (ECDSA) key pair and identifying information.

    1. In the Jupyter notebook, preselect the private key and public key arrays for consistency. Do not modify these values. Note: For an actual application, these arrays are never visible to anyone.
    2. The identifying information: Also preselect the Host_ID and Host_Location_Code. Do not modify these values.
  2. Initiate Authority to host certificate generation.

    1. Send all required information needed to generate a certificate to the authority. This requires packaging the public key, the Host_ID, and Host_Location_Code into a certificate message to send. The authority generates a certificate using this information and signs it with the authority private key.
  3. Generate the device's ECDSA key pair.

    1. Use the GenEcc256KeyPair function to generate the public key for the device. Note that this public key is visible, but the private key can never be revealed as it compromises security in an actual application.
  4. Initiate Authority to device certificate generation.

    1. Gather the device's identifying data by using the ReadMemory command to read the rom options page (116) of the device. This page contains the ROM_ID and MAN_ID needed to identify the particular DS28S60 device.
    2. Concatenate the device's public key, ROM_ID, and MAN_ID into a certificate message to send to the authority. The authority generates a certificate signed with the authority private key.
  5. Store the device certificate, authority private key, and feature data in the device.

    1. Write the device's certificate to its memory. For this application, page 0 and page 1 are chosen as memory locations.
    2. Write the authority's public key to the device's memory. Page 100 and page 101 are chosen for this application.
    3. Write the feature data to the device's memory. Page 4 is chosen for this purpose. Note: For more information on which memory page stores which information, refer to the DS28S60 user guide.
  6. Set appropriate memory protections for the stored information.

    1. To prevent tampering of the newly stored information, set write protections on the pages containing the device certificate and feature data. Note: For the Jupyter notebook, omit this step.

Encrypted Channel Creation Using ECDHE and AES-GCM

To establish an encrypted channel, both the host and device must first calculate a shared secret. To do so, the host and device generate an ECDSA key pair, but these keys are ephemeral. An ephemeral key is a temporary key. The host and device initiate an elliptic-curve Diffie-Hellman (ECDH) Key Exchange to exchange these ephemeral keys and securely generate a shared secret. This secret is then used to encrypt and decrypt data through AES-GCM. Figure 3 describes this key exchange interaction.

Note: Generate a new ephemeral key pair for each new communication session.

Figure 3. Host and device exchanging ephemeral keys to calculate the shared secret.

Figure 3. Host and device exchanging ephemeral keys to calculate the shared secret.

The following steps describe how to perform the ECDH Key Exchange:

  1. Define the Calculate_ECDH_Shared_Point and increment_aes_iv support functions.
  2. Generate the host's ephemeral key pair.

    1. Generate the keypair using the ecdsa.SigningKey.generate and .get_verifying_key commands.
    2. Convert the key pair to an array/list.
  3. Generate the device's ephemeral key pair using the GenEcc256KeyPair command.
  4. Calculate the AES secret (shared secret) and initial AES IV on the host's side.

    1. Use the Calculate_ECDH_Shared_Point function taking the device's public key and host's private key as parameters.
    2. Hash the calculated shared point using the SHA-256 hashing algorithm to generate the AES shared key and AES IV.
  5. Calculate the AES secret and initial AES IV on the device's side using the KeyExchange command taking the host's ephemeral public key as a parameter.

At this point, both sides generate the same AES Secret. Because of this, both parties can now encrypt and decrypt data sent between them using advanced encryption standard-galois/counter mode (AES-GCM). Figure 4 illustrates the encrypted communication channel offered by AES-GCM.

Figure 4. Host and device using the AES-GCM algorithm to exchange encrypted data. Note that the IV must be incremented on each transfer and must be synchronized on both sides.

Figure 4. Host and device using the AES-GCM algorithm to exchange encrypted data. Note that the IV must be incremented on each transfer and must be synchronized on both sides.

Bidirectional Authentication Using ECDSA

Mutual authentication can be described in two parts: verifying public keys using certificates and verifying private keys using digital signature and verification algorithms through ECDSA. The ECDSA algorithm involves communicating parties proving authenticity by generating a digital signature using private keys. These digital signatures are then verified by the opposing party using the signature, the public key of the party that sent the signature, and other data. Cryptographically secure random numbers are also used in both the signature and verification portions of this algorithm to increase security.


Verifying Public Keys with a Certificate Authority


The ECDSA algorithm is also used to verify public keys using the parties' certificates, the authority's public key, and the parties' identifying data. This identifying data is the Host ID data for the host, and the ROM ID and MAN ID for the device. Figure 5 describes the exchange of this information in terms of verifying the public keys of each party.

Figure 5. Host and device verifying each other's public keys using each other's certificates and the ECDSA verification algorithm.

Figure 5. Host and device verifying each other's public keys using each other's certificates and the ECDSA verification algorithm.

The following steps walk through how to authenticate the public key of the device (steps 1 to 4) and the host (steps 5 to 7):

  1. Gather the certificate and certificate message data from the device to send to the host.

    1. On the device side, use the ReadMemory command to read back the X and Y components of the device's public key. Repeat for the ROM and MAN IDs.
    2. Use the ReadMemory command to read back the 'r' and 's' components of the device's certificate.
  2. Encrypt the requested data and transmit it to the host.

    1. Concatenate the certificate message data (public key, ROM ID, and MAN ID), then concatenate the certificate (parts 'r' and 's').
    2. Use the certificate message data and certificate as parameters to the AesBulkEncrypt command.
  3. Decrypt, extract, and verify the data on the host's side. Ensure that the AES IV counter is incremented.
  4. Verify the extracted certificate message data and certificate on the host side to verify the public key.
  5. Gather the certificate and certificate message data from the host, encrypt it, and send it to the device.

    1. Package the X and Y components of the host's public key, the Host_ID, and Host_Location_Code.
    2. Encrypt the certificate and certificate message data using the encrypt_and_digest command. Do not forget to increment the AES IV counter.
  6. Decrypt the data on the device's side using the AesBulkDecrypt command.
  7. Verify the host's extracted certificate message data and certificate on the device side to verify the public key.

    1. Use the WriteMemory command to store the X and Y components of the host's public key.
    2. Validate the host's certificate using the AuthenticateECDSACertificate command.

Verifying Private Keys with Digital Signatures


After verifying the public key of the device, verify the private key of the device as well. To do so, first generate a digital signature using the private key of the device. The digital signature contains device feature data, the signature of the private key, and a string of random bytes sent by the host called a challenge. Figure 6 illustrates the exchange of information used in the ECDSA signature generation algorithm.

Figure 6. Host and device exchanging challenges to generate their own unique digital signatures derived from their respective private keys.

Figure 6. Host and device exchanging challenges to generate their own unique digital signatures derived from their respective private keys.

The following steps describe how to use the ECDSA signature generation and ECDSA signature verification algorithms to complete authentication of the device (steps 1 to 5) and the host (steps 6 to 9):

  1. Generate a challenge to send to the device.
  2. Create a digital signature and signature message using the challenge and additional feature data.

    1. Use the ComputeAndReadPageAuthentication command to create the signature.
    2. Concatenate the ROM ID, feature data, host challenge, data page, MAN ID, and command code bytes to create the signature message.
  3. Encrypt the signature and data using AesBulkEncrypt, then send it to the host.
  4. Decrypt and verify the data on the host's side, extract the signature and signature message data, and increment the AES IV counter.
  5. Reconstruct the signature message and verify the decrypted signature and signature message data using the device public key. Figure 7 describes the ECDSA signature verification algorithm and shows what pieces of information are needed for verification.

    1. Structure and concatenate the data needed to verify in the following order: ROM ID, feature data, host challenge, feature data page, MAN ID, command code.

    Figure 7. Host and device verifying one another's private keys using the ECDSA Signature Verification Algorithm and all associated data.

    Figure 7. Host and device verifying one another's private keys using the ECDSA Signature Verification Algorithm and all associated data.

  6. Generate a challenge to send to the host using the ReadRng command.
  7. Create a digital signature and signature message using the challenge and host data (Host_ID, Host_Location_Code, and Host Feature Data).
  8. Encrypt the feature data, signature, and signature message, and send it to the device. Do not forget to update the AES IV counter.
  9. Decrypt the received data on the device side using the AesBulkDecrypt command.
  10. Verify the signature and associated data using the VerifyEcdsaSignature command.

    1. Structure and concatenate the data needed to verify in the following order: Host ID, device challenge, host feature data, Host Location Code

Summary

Bidirectional authentication can be compartmentalized and demonstrated through the associated Jupyter notebook. Running through the notebook describes factory setup/key generation, ECDH key exchange, encrypting and decrypting data using AES-GCM, and communicating over a secure channel to mutually authenticate both the host and device. These steps are described here as well, in addition to the steps needed to configure and run the Jupyter notebook. Following both documents provides a fully authenticated system courtesy of the DS28S60 cryptographic processor.

Trademarks

  • ChipDNA is a registered service mark and registered trademark of Analog Devices International.
  • Windows is a registered service mark and registered trademark of Microsoft Corporation.