アプリケーションノート 6465

How to Generate a DS28C36 Session Key

筆者: Clay Greene

要約: The DS28C36 is a secure authenticator providing a core set of cryptographic tools derived from integrated asymmetric (ECC-256) and symmetric (SHA-256) security functions. In addition to the security services provided by the hardware crypto engines, the device integrates a FIPS/NIST true random number generator (TRNG), 8Kb of secured EEPROM, a decrement-only counter, two pins of configurable GPIO, and a unique 64-bit ROM identification number (ROM ID). This application note describes the procedures for setup and generation of a Session Key on the DS28C36. An example of these procedures is referenced in the Appendix.


この文書は極めて特定的なアプリケーションに向けて書かれたものであり、独自技術に関する情報を含んでいるため、その開示は該当アプリケーションに直接関わっているお客様のみに限定させていただいております。この文書を請求される方は以下のフォームに必要事項を記入してください。適当と判断された場合は2営業日以内にご連絡いたします。

以下の情報はすべて英語で記入してください。

Introduction

The DS28C36 (Figure 1) is a DeepCover® ECDSA (elliptic curve digital signature algorithm) and SHA-256 (secure hash algorithm, 256-bit) authenticator, which is operated over the I2C interface. The three ECDSA private and public key pairs for signature generation and verification can be computed by the device or installed by the user and optionally locked. The 8Kb of secured EEPROM provides a 4Kb user partition that is organized as 16 pages of 256 bits and can be left unprotected or irreversibly write-protected, read-protected, authentication-protected, encrypted, or set up for EPROM emulation mode. The DS28C36 also features a FIPS-grade TRNG (true random number generator), and a one-time settable, nonvolatile, 17-bit decrement-only counter, which can be used to electronically control the lifetime of the object with which the DS28C36 is associated. Each device has its own unique 64-bit ROM ID, factory programmed into the chip and used as input for cryptographic operations.

DS28C36 block diagram. Figure 1. DS28C36 block diagram.

Device Setup

A DS28C36 "fresh from the factory" is not ready for use. It must first be set up. For ECDSA-based authentication, required setup steps are the installation of a key pair (private and public key) and the installation of a write-protected public-key certificate as described in Application Note 6434, "How to Verify the DS28C36 ECDSA Certificate". To simplify this application note, the Application Note 6434 “verify” certificates have been omitted. This application, however, does require ECDH Authorization certificates that are very similar to the "verify" certificates in Application Note 6434. To prevent unauthorized changes, the key pair must be write-protected. Although used in the authentication process, the actual contents of the user memory are not relevant to the key pair generation process. Programming the user memory for other application purposes is a separate step. Additionally, other device setup, including initialization of the 17-bit counter, installation of SHA-256 keys, and device protection settings are outside the scope of this application note. As a value-add option, Maxim offers a factory personalization service to completely pre-configure devices according to customers specifications prior to shipment.

Device Identification

A DS28C36 attached to the system is identified by reading the "ROM Options Page" (Page 28) using the DS28C36 Read Memory command. From this operation, the unique 64-bit ROM ID and 16-bit manufacturer ID (MANID) are obtained, and are used device authentication.

Key Pair Installation

A key pair consists of a 32-byte private key and a 2 × 32-byte public key. The easiest way to install a public/private key pair is through the DS28C36 Generate ECC-256 Key Pair command, which creates a key pair as shown in Figure 2 and loads the keys into the specified key storage spaces. This method of key generation ensures unique key pairs for each device and does not expose the private key. The DS28C36 has designated memory pages to store up to three key pairs (A, B, and C) consisting of the X and Y values of the public key and corresponding private key. The DS28C36 Generate ECC-256 Key Pair command automatically writes the generated key pair to the memory pages requested if they are not already protected. If desired, the public/private key pair can be write-protected during installation or in a separate step.

Key pair generation. Figure 2. Key pair generation.

To illustrate the design choices in the demo outlined in the Appendix, Figure 2 indicates that Key Pair A is chosen for the device public/private key pair. Additionally, the demo computes the Authority Public Key externally and writes it to the DS28C36 via the Write Memory command and sets write protection. The demo does not share the Authority Private Key with the DS28C36, but instead fills the DS28C36 Page 24 with random data. The Authority Public Key resides in Key Pair C with a special "Authority" protection setting. The Authority Public Key is used on the DS28C36 to authorize an external key pair to perform a key exchange. The command flows for generating session keys are detailed below.

Device Public Key ECDH Authorization Certificate Installation

Like the process described in Application Note 6434, the key management setup demo outlined in the Appendix generates and writes an ECDH Authorization Certificate for the Device Public Key stored in Key Pair A. For simpler demonstration, the device ROM ID and MANID are not included in the calculation for the demo. The ECDH Authorization certificate generation with the Authority Private Key is shown in Figure 3 and Table 1.

Figure 3. Device public key ECDH authorization certificate generation by a key management system. Figure 3. Device public key ECDH authorization certificate generation by a key management system.

Table 1. SHA-256 Input Data for ECDH Authorization Certificate Generation

BYTE 0 BYTE 1 BYTE 2 BYTE 3 BYTE 4 BYTE 5 BYTE 6 BYTE 7
PX + 0 PX + 1 PX + 2 PX + 3 PX + 4 PX + 5 PX + 6 PX + 7
 
BYTE 8 BYTE 9 BYTE 10 BYTE 11 BYTE 12 BYTE 13 BYTE 14 BYTE 15
PX + 8 PX + 9 PX + 10 PX + 11 PX + 12 PX + 13 PX + 14 PX + 15
 
BYTE 16 BYTE 17 BYTE 18 BYTE 19 BYTE 20 BYTE 21 BYTE 22 BYTE 23
PX + 16 PX + 17 PX + 18 PX + 19 PX + 20 PX + 21 PX + 22 PX + 23
 
BYTE 24 BYTE 25 BYTE 26 BYTE 27 BYTE 28 BYTE 29 BYTE 30 BYTE 31
PX + 24 PX + 25 PX + 26 PX + 27 PX + 28 PX + 29 PX + 30 PX + 31
 
BYTE 32 BYTE 33 BYTE 34 BYTE 35 BYTE 36 BYTE 37 BYTE 38 BYTE 39
PY + 0 PY + 1 PY + 2 PY + 3 PY + 4 PY + 5 PY + 6 PY + 7
 
BYTE 40 BYTE 41 BYTE 42 BYTE 43 BYTE 44 BYTE 45 BYTE 46 BYTE 47
PY + 8 PY + 9 PY + 10 PY + 11 PY + 12 PY + 13 PY + 14 PY + 15
 
BYTE 48 BYTE 49 BYTE 50 BYTE 51 BYTE 52 BYTE 53 BYTE 54 BYTE 55
PY + 16 PY + 17 PY + 18 PY + 19 PY + 20 PY + 21 PY + 22 PY + 23
 
BYTE 56 BYTE 57 BYTE 58 BYTE 59 BYTE 60 BYTE 61 BYTE 62 BYTE 63
PY + 24 PY + 25 PY + 26 PY + 27 PY + 28 PY + 29 PY + 30 PY + 31
 
BYTE 64 BYTE 65 BYTE 66 BYTE 67 BYTE 68 BYTE 69 BYTE 70 BYTE 71
CB + 0 CB + 1 CB + 2 CB + 3 CB + 4 CB + 5 CB + 6 CB + 7
 
BYTE 72 BYTE 73 BYTE 74 BYTE 75 BYTE 76 BYTE 77 BYTE 78 BYTE 79
CB + 8 CB + 9 CB + 10 CB + 11 CB + 12 CB + 13 CB + 14 CB + 15

(PX + N): Byte N of Public Key X; 0 ≤ N ≤ 31
(PY + N): Byte N of Public Key Y; 0 ≤ N ≤ 31
(CB + N): Byte N of System Constant; 0 ≤ N ≤15



Device Public Key ECDH Authorization Certificate Verification

Like in Application Note 6434, Figure 4 illustrates the host reading the ingredients, assembling them per Table 1, and verifying their Certificate to determine if a DS28C36 is authorized to perform ECDH key exchange. Only a certified DS28C36 Device Public Key should be used for generation of a Session Key.

Device public key ECDH authorization certificate verification. Figure 4. Device public key ECDH authorization certificate verification.

Figure 4 illustrates a host that reads the Certificate calculation ingredients from connected DS28C36 devices. As an alternative to this, the Master Application demo outlined in the Appendix represents a key management system with local storage of Device Public Keys and Certificates read from a file.

Master Public Key Certificate Generation

In order to complete an ECDH key exchange, a key management system must also generate a Master Public Key and corresponding ECDH Authorization Certificate generated with the Authority Private Key. The process for generating Master Public Key ECH Authorization Certificate is similar to that used for the Device Public Key and is shown in Figure 5 and Table 1. In the Master Application demo, the Authority Public Key and Master Public Key are preloaded as constants, along with the Master Public Key ECDH Authorization Certificate. This approach highlights the secrecy of the Authority Private Key, which is not necessarily known by the key management system.

Master public key ECDH authorization certificate generation by a key management system. Figure 5. Master public key ECDH authorization certificate generation by a key management system.

ECDH Key Exchange (Host Side)

To generate an ECDH session key on the host with a DS28C36, the host must collect the Device Public Key, MANID, and page data from the DS28C36. As shown in Figure 6 the Device Public Key and Master Private Key are used to calculate a new shared point on the elliptic curve. The X coordinate of this point is then combined with ECDH custom fields (shown in Table 2) to feed a SHA-256 operation in order to generate a Shared Secret "S." The Shared Secret "S" is then used as the key for the HMAC operation on a message assembled per Table 3 with a random Challenge, and fields collected from the DS28C36.

ECDH key exchange on the host side. Figure 6. ECDH key exchange on the host side.

The result of the HMAC is used as a Session Key for future communication between the host and the target device containing the DS28C36. Additional Session Keys can be generated by just repeating the last step with a new challenge.

Table 2. SHA-256 Input Data for Shared Secret Generation

BYTE 0 BYTE 1 BYTE 2 BYTE 3 BYTE 4 BYTE 5 BYTE 6 BYTE 7
X + 0 X + 1 X + 2 X + 3 X + 4 X + 5 X + 6 X + 7
 
BYTE 8 BYTE 9 BYTE 10 BYTE 11 BYTE 12 BYTE 13 BYTE 14 BYTE 15
X + 8 X + 9 X + 10 X + 11 X + 12 X + 13 X + 14 X + 15
 
BYTE 16 BYTE 17 BYTE 18 BYTE 19 BYTE 20 BYTE 21 BYTE 22 BYTE 23
X + 16 X + 17 X + 18 X + 19 X + 20 X + 21 X + 22 X + 23
 
BYTE 24 BYTE 25 BYTE 26 BYTE 27 BYTE 28 BYTE 29 BYTE 30 BYTE 31
X + 24 X + 25 X + 26 X + 27 X + 28 X + 29 X + 30 X + 31
 
BYTE 32 + 0 BYTE 32 + 1   BYTE 32 + (N-1) BYTE 32 + N
EC + 0 EC + 1   EC + (N-1) EC + N

(X + N): Byte N of X Coordinate
(EC + N): Byte N of ECDH customization field (minimum 1 bytes, maximum 48 bytes).

Table 3. SHA-256 Input Data for HMAC

BYTE 0 BYTE 1 BYTE 2 BYTE 3 BYTE 4 BYTE 5 BYTE 6 BYTE 7
FFh FFh FFh FFh FFh FFh FFh FFh
 
BYTE 8 BYTE 9 BYTE 10 BYTE 11 BYTE 12 BYTE 13 BYTE 14 BYTE 15
PD + 0 PD + 1 PD + 2 PD + 3 PD + 4 PD + 5 PD + 6 PD + 7
 
BYTE 16 BYTE 17 BYTE 18 BYTE 19 BYTE 20 BYTE 21 BYTE 22 BYTE 23
PD + 8 PD + 9 PD + 10 PD + 11 PD + 12 PD + 13 PD + 14 PD + 15
 
BYTE 24 BYTE 25 BYTE 26 BYTE 27 BYTE 28 BYTE 29 BYTE 30 BYTE 31
PD + 16 PD + 17 PD + 18 PD + 19 PD + 20 PD + 21 PD + 22 PD + 23
 
BYTE 32 BYTE 33 BYTE 34 BYTE 35 BYTE 36 BYTE 37 BYTE 38 BYTE 39
PD + 24 PD + 25 PD + 26 PD + 27 PD + 28 PD + 29 PD+ 30 PD + 31
 
BYTE 40 BYTE 41 BYTE 42 BYTE 43 BYTE 44 BYTE 45 BYTE 46 BYTE 47
CH + 0 CH + 1 CH + 2 CH + 3 CH+ 4 CH + 5 CH + 6 CH + 7
 
BYTE 48 BYTE 49 BYTE 50 BYTE 51 BYTE 52 BYTE 53 BYTE 54 BYTE 55
CH + 8 CH + 9 CH + 10 CH + 11 CH + 12 CH + 13 CH + 14 CH + 15
 
BYTE 56 BYTE 57 BYTE 58 BYTE 59 BYTE 60 BYTE 61 BYTE 62 BYTE 63
CH + 16 CH + 17 CH + 18 CH + 19 CH + 20 CH + 21 CH + 22 CH + 23
 
BYTE 64 BYTE 65 BYTE 66 BYTE 67 BYTE 68 BYTE 69 BYTE 70 BYTE 71
CH + 24 CH + 25 CH + 26 CH + 27 CH + 28 CH + 29 CH + 30 CH + 31
 
BYTE 72 BYTE 73 BYTE 74  
PG MANID + 0 MANID + 1  

(PD + N): Byte N of Page (EEPROM and memory-mapped feature) Data; 0 ≤ N ≤ 31
(CH + N): Byte N of Challenge (stored in Buffer); 0 ≤ N ≤ 31
PG: Page Number
(MANID + N): Byte N of the 16-bit manufacturer ID; MANID + 0 is the LSbyte.

ECDH Key Exchange (Device Side)

Before performing an ECDH Key Exchange, the Master Public Key must be certified with the DS28C36 Authenticate ECDSA Public Key command shown in Figure 7. The host writes its Master Public Key into the Volatile Public Key S on Pages 30 & 31. The host also writes a byte sequence to the DS28C36 Buffer containing the 16-byte system constant (See AN 6434) beginning at Byte0, and the ECDH Customization Field beginning at Byte 32 for later use. The DS28C36 then assembles a message according to Table 3, feeding that message into the SHA-256 algorithm, whose digest is then fed into the ECDSA Verification Algorithm with the Authority Public Key loaded in Pages 20 & 21 during setup. The host sends the Master Public Key ECDH Authorization Certificate in the command for verification. This verifies that the Master Public Key is valid to perform the key exchange.

Certifying the Master Public Key. Figure 7. Certifying the Master Public Key.

If the Master Public Key ECDH Authorization Certificate is authenticated, and the ECDH bit is set in the command parameter, the DS28C36 automatically initiates the ECDH process shown in Figure 8. Just as the host uses the Master Private Key and Device Public Key with the ECDH algorithm to calculate a new point on the elliptic curve, the DS28C36 uses its Device Private Key and Master Public Key through the same algorithm to arrive at the same shared point. The X coordinate of this point is likewise combined with ECDH custom fields (see Table 2) to feed a SHA-256 operation, generating a Shared Secret S.

ECDH key exchange on the device side. Figure 8. ECDH key exchange on the device side.

The Shared Secret S, calculated in Figure 8, is stored in a volatile memory area in the DS28C36 accessible only by onboard operations. When the DS28C36 Compute and Read Page Authentication command is issued, selecting Secret S in the parameter byte, the shared secret is used as the key for the HMAC operation on a message assembled per Table 3. As a prerequisite to this command, the host’s random Challenge must already be written to the initial 32 bytes of the Buffer. This and other fields collected from DS28C36 memory locations are shown in Figure 9. The ANON byte in the ROM_OPTIONS_PAGE (Page 28) of the DS28C36 must be AAh in order to remove the ROM ID from the message and replace it with all 1s for "Anonymous" operation used in the demo outlined in the Appendix.

ECDH key exchange on the device side. Figure 9. ECDH key exchange on the device side.

The result of the HMAC is a Session Key identical to the host's calculation for future communication between the host and the target device containing the DS28C36.

Multiple Devices

The demo outlined in the Appendix is written with the host as a master of a connected DS28C36. However, inspection of Figure 6, compared with the combination of Figure 8 and Figure 9, reveals the similarities of the development of a session key between the two parties. A system can also be realized as a peer-to-peer scheme, where one DS28C36-enabled node can initiate a key exchange with another, utilizing the flows outlined in Figure 7, Figure 8 and Figure 9 substituting Master Keys with the initiating device’s Public and Private Keys. The flexibility of the DS28C36 feature set enables diverse security implementations tailored to the needs of each unique application.

Peer-to-peer network. Figure 10. Peer-to-peer network.

Example ECDH Key Exchange Sequence Between Master and One Slave

  1. Master requests secure channel from Slave MCU.
    1. Slave MCU uses Read Memory command to read Device Public Key A.
    2. Slave MCU uses Read Memory command to read Certificate stored in user memory.
    3. Slave MCU sends the Public Key and Certificate to Master.
  2. Master sends Master Public Key, Certificate, and Session Challenge to Slave MCU.
    1. Master sends Master Public Key.
    2. Master sends Certificate.
    3. Master generates a 32-byte Session Challenge and sends to Slave MCU.
  3. Master computes the shared secret using ECDH.
    1. Master uses Master Private Key * Device Public Key (from Slave) to get shared secret.
  4. Slave Computes the shared secret using ECDH.
    1. Slave MCU uses Write Memory to write Master Public Key to Public Key S.
    2. Slave MCU uses Write Buffer to write the custom fields for verification of the certificate.
    3. Slave MCU uses Authenticate ECDSA Public Key to authenticate the Master Public Key stored in Public Key S, then if successful compute the shared ECDH secret and store in SECRET_S.

      [At this point, both Master and Slave have the same shared secret.]

  5. Compute Session Key on Slave with the Session Challenge and the ECDH shared secret.
    1. Slave MCU sets ANON on ROM Options page using Write Memory, enabling anonymous mode.
    2. Slave MCU uses Write Buffer to write the Session Challenge to the Buffer.
    3. Slave MCU uses Compute and Read Page Authentication with HMAC/SECRET_S option using the Session Challenge (already in buffer). Note the contents of the page need to be the same between Master and Slave. It could be part of the original key exchange or preselected. Ideally it would be a page that was written and read protected.
    4. The output HMAC is the shared Session Key.
  6. Compute Session Key on Master with the Session Challenge and the ECDH shared secret.
    1. Compute HMAC using shared secret as the "key." The "message" is the static page data and session challenge. The HMAC is the Session Key for use in encrypting future communication.

Example ECDH Key Exchange Sequence Between Two Peer Devices

Note that the devices need to have the same MANID.

  1. Send Node #1 Public Key, Certificate, ROM ID, and Session Challenge to Node #2.
    1. Use Read Memory command to read Device Public Key A or B.
    2. Use Read Memory command to read Certificate stored in user memory.
    3. Use Read RNG to generate a 32-byte Session Challenge.
    4. Use Read Memory to read the ROM ID of the device.
    5. Send the Public Key, Certificate, ROM ID, and Session Challenge to Node #2
  2. Send Node #2 Public Key, Certificate, and ROM ID to Node #1.
    1. Use Read Memory command to read Device Public Key A or B.
    2. Use Read Memory command to read Certificate stored in user memory.
    3. Send the Public Key and Certificate to Node #1.
  3. Compute the shared internal secret using ECDH on Node #1.
    1. Use Write Memory to write Node #2's Public Key to Public Key S.
    2. Use Write Buffer to write ROM ID of Node #2. This is the custom certificate fields for verification of the certificate. There can also be custom fields for the ECDH calculation.
    3. Use Authenticate ECDSA Public Key to authenticate the Public Key store in S, then if successful, compute the shared ECDH secret and store in SECRET_S.
  4. Compute the shared internal secret using ECDH on Node #2.
    1. Use Write Memory to write Node #1’s Public Key to Public Key S.
    2. Use Write Buffer to write ROM ID of Node #1. This is the custom certificate fields for verification of the certificate. There can also be custom fields for the ECDH calculation.
    3. Use Authenticate ECDSA Public Key to authenticate the Public Key store in S, then if successful, compute the shared ECDH secret and store in SECRET_S.

      [At this point, both Node #1 and #2 have the same SECRET_S.]

  5. With Session Challenge and ECDH shared secret, each node computes a Session Key.
    1. Use Write Memory on ROM Options page to set flag ANON to enable anonymous mode.
    2. Use Write Buffer to write the Session Challenge to the Buffer.
    3. Use Compute and Read Page Authentication with HMAC/SECRET_S option using the Session Challenge. Note the contents of the page needs to be the same between Devices #1 and #2. It could be part of the original key exchange or preselected. Ideally it would be a page that was written and read protected.
    4. The output HMAC is the shared Session Key for use in encrypting future communication.

Summary

Traditionally, authentication systems relied on symmetric algorithms that required secret keys. The management and protection of the secret keys, however, can be challenging. The DS28C36 provides an alternative to this logistic problem by using the asymmetric ECDSA, which is public-key based. As this application note shows, the communication with the DS28C36 for device setup and authentication can be broken into short sequences ("steps") that are easily implemented in a host processor. For the DS28C36 DeepCover secure authenticator, Maxim provides a trusted preprogramming service to factory personalize devices by installing the key pair, certificate, memory data and preset the decrement-only counter prior to shipment. For details about this secure service, submit a tech support request on the Maxim Technical Support site.

Appendix

An example of the procedures outlined in the application note are implemented in a C code demonstration package targeted for the Microsoft Visual Studio® build environment. This package is provided along with this application note and can aid in the creation of host software communicating with the DS28C36. DS28C36_Setup_Session_Key.exe installs into the DS28C36 the Device Key Pair, Device ECDH Authorization Certificate, and Authority Public Key. It also writes all zeros to user memory pages, and generates Master and Device Public Key and Certificate lookup files. Running application_master_session_key.exe reads the Device Public Key and ECDH Authorization Certificate from the lookup file, verifies that Certificate, generates a Random Challenge file, and produces the Session Key according to the process outlined in Figure 6, assuming device page data is all zeros. Running DS28C36_Application_Slave_Session_Key.exe reads the Master Public Key and Certificate from the file generated by DS28C36_Setup_Session_Key.exe, writes the Master Public Key to the DS28C36 Volatile Public Key S, writes the DS28C36 Buffer with a fixed customization field, and executes the DS28C36 Authenticate ECDSA Public Key command with the Master Public Key Certificate to generate SECRET_S. After completion of this step, DS28C36_Application_Slave_Session_Key.exe sets up and executes the DS28C36 Compute and Read Page Authentication command with the challenge generated by application_master_session_key.exe to produce the Session Key according to Figure 9. The source files for these demo applications employ common routines from a collection of device-specific functions located in various modules included in the .zip package named: Deep_Cover_DS28C36_Session_Key_v1p0_111017.zip.

A brief outline of these files is shown below:

Source (see 'src' folder):

  • (install folder)\src\Demos\
    • ds28c36_setup_session_key.c
      • Main for DS28C36_Setup_Session_key to setup demo
    • application_master_session_key.c
      • • Main for DS28C36_Application_Slave_Session_Key
  • (install folder)\src\Deep_Cover_Coproc_SW\
    • deep_cover_coproc_SW.c
      • Software implementation of Coprocessor functions
  • (install folder)\src\DS28C36\
    • ds28c36.c - Device module for DS28C36
  • (install folder)\src\ECDSA_SW\
  • bignum.c
  • ecdsa_generic_api.c
  • ecdsa_high.c
  • sha256_stone.c
  • ucl_rng.c
  • ucl_sha256.c
  • ucl_sia256.c
  • ucl_sys.c

Maxim Free Cryptographic Library
(FCL) implementing ECDSA

  • (install folder)\src\HMAC\
    • sha256_hmac.c
      • Software HMAC SHA-256 implementation
  • (install folder)\src\I2C\
    • i2c_ds9481p_ds9400.c
      • I2C module for DS9481P-300 or DS9400
    • serial_win32ex.c
      • Serial module, used by I2C module
  • (install folder)\src\SHA256\
    • sha256_software.c
      • Software implementation of SHA-256

    Microsoft Visual Studio 2015 Project (see '(install folder)\builds' folder):

    • DS28C36_Setup_Session_Key
    • application_master_session_key
    • DS28C36_Application_Slave_Session_Key

    Folders Required:
    Demos, Deep_Cover_Coproc_SW,
    DS28C36, ECDSA_SW, I2C

    Documentation: (see ‘\doc\html\index.html‘)


アプリケーションノート 6465,AN6465, AN 6465, APP6465, Appnote6465, Appnote 6465