This document is written for a highly specific application and contains information about proprietary technology, and is only available to customers whose requirements closely match the application. To request the full document, please complete the form below.Please enter information in English only.
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. Separate memory space may be used to store and lock a public-key certificate. 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 guaranteed unique 64-bit ROM ID, factory programmed into the chip. This ROM ID is an input parameter for cryptographic operations.
Figure 1. DS28C36 block diagram.
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 public-key certificate. To prevent unauthorized changes, the key pair and certificate must be write-protected. Although used in the authentication process, the actual contents of the user memory are not relevant to the key pair(s) and certificate(s) process. Other than certificate installation described herein, 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 preconfigure devices according to customers specifications prior to shipment.
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 in generation and verification of the certificate and other components of device authentication.
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 (see the "Protections" section in this application note).
If desired, the key pair can be computed externally and directly written to the respective memory locations in the DS28C36. These can be done with the DS28C36 Write Memory command until write protection is set.
Figure 2. Key pair generation.
Typically, the certificate is computed at the same time and location where the private/public key pair is installed. Maxim recommends that the certificate be computed with SHA-256 input data including the full 2 x 32-byte device public key, followed by the concatenation of a 16-byte system constant, the ROM ID, and 16-bit manufacturer ID for the second message block (Figure 3). For the certificate, the ECDSA computation uses the system private key. In the end application, the corresponding system public key must be known to the host controller operating with the DS28C36 to verify the public key’s authenticity using the certificate.
Like the system public key, the 16-byte system constant must also be known to the host controller operating with the DS28C36 to verify the public key’s authenticity using the certificate. The contents of 16-byte system constant are chosen by the customer and assigned in a manner suitable to the application. For example, the 16-byte system constant can be all zeros (i.e., "blank"), a system-wide "password," or a value assigned to subsets of the overall system population, as long as that value can be predetermined by a given host controller for verification of authenticity.
Before the certificate can be computed and installed, the host key-management system in charge of this task needs to know the full device public key and the system private key. If the private/public key pair to be used was installed using the Generate ECC-256 Key Pair command, the corresponding public key pages must be read from the DS28C36. Then the host computes the certificate with the SHA-256 input data from Table 1. The resulting values (r = certificate part 1, s = certificate part 2) are then written to the chosen memory pages of the DS28C36.
Figure 3. Certificate generation by a key management system.
Table 1. SHA-256 Input Data for ECDSA Certificate Generation/Verification/Preprogramming
|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|
|BYTE 80||BYTE 81||BYTE 82||BYTE 83||BYTE 84||BYTE 85||BYTE 86||BYTE 87|
|RN + 0||RN + 1||RN + 2||RN + 3||RN + 4||RN + 5||RN + 6||RN + 7|
|BYTE 88||BYTE 89|
|MANID + 0||MANID + 1|
(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
(RN + N): Byte N of the 64-bit ROMID; RN + 0 corresponds to the family code
(MANID + N): Byte N of the 16-bit manufacturer ID; MANID + 0 is the LSbyte
The key pair and certificate form an entity that must remain intact to allow authentication. Therefore, key pair and certificate must be write-protected after the correct installation is verified.
To verify the certificate, besides the system public key and the system constant, the host needs to know the other ingredients that went into the SHA-256 hash computation to compute the certificate, as well as the certificate itself. Obtaining these data elements requires multiple reads of DS28C36 in any order. As shown in Figure 4, the host reads device memory and performs a signature verification algorithm for the certificate. If the result is "pass," the public key is valid in the system. If the result is "fail," the part does not belong to the system and there is no need to interact further.
A verified certificate alone does not guarantee that the host is communicating with a genuine DS28C36. The data used so far could as well have come from an emulator that tries to perform a replay attack. Therefore, verification of a signature based on random data provides cryptographic proof that the device is genuine. The steps required to verify a DS28C36 signature are outlined in application note 6435, "How to Authenticate DS28C36 Data (User Memory/CPIO/Decrement Counter) with ECDSA".
Figure 4. Certificate verification.
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.
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. Device Identification, Key Pair Installation, and Public Key Certificate Installation sequences are performed in the application DS28C36_Setup_Verify_Certificate.exe and shown in the source file ds28c36_setup_verify_certificate.c. Similarly, Device Identification and Certificate Verification can be found in the DS28C36_Application_Verify_Certificate.exe application and its source file ds28c36_application_verify_certificate.c.
The source files mentioned above employ common routines from a collection of device-specific functions located in various modules included in the .zip package named: Deep_Cover_DS28C36_Verify_Certificate_v1p0_042417.zip.
A brief outline of these files is shown below:
Source (see 'src' folder):
Microsoft Visual Studio 2015 Project (see '(install folder)\builds' folder):
Documentation: (see ‘\doc\html\index.html‘)