Keywords: public key, private key, ecdsa, digital signature, elliptic curve, secure hash, sha-256, sha, ecc-256, hardware accelerator, integrated ecc-256, integrated sha, signature, authentic, asymmetric cryptography, crypto engine, cryptographic engine
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. The 8Kb of secured EEPROM provides a 4Kb user partition that is organized as 1 6 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.
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 write-protected public-key certificate as described in application note 6434, “How to Verify the DS28C36 ECDSA Certificate”. 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.
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.
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 written to the respective memory locations in the DS28C36. This can be done with the DS28C36 Write Memory command until write protection is set.
Figure 2. Key pair generation.
The key pair and its corresponding certificate (refer to application note 6434, “How to Verify the DS28C36 ECDSA 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.
The purpose of the signature is to provide cryptographic proof that the device is genuine. The signature is computed in real time by first hashing a concatenation of the DS28C36’s ROM ID, the manufacturer ID, page number, page data, and a 32-byte random challenge provided from the host and written to the DS28C36 buffer. The format of the concatenation of these values is shown in detail in Table 1. Page data can consist of EEPROM bytes, the decrement counter, or GPIO, which are mapped to memory page numbers.
Next, the SHA-256 hash feeds into the ECDSA engine together with the device’s private key and a random number that is automatically generated by the DS28C36. The resulting signature consists of two 32-byte components called R and S. This process is shown in Figure 3.
Figure 3. Signature generation by a DS28C36 device.Table 1. SHA-256 Input Data for ECDSA Signature
|BYTE 0||BYTE 1||BYTE 2||BYTE 3||BYTE 4||BYTE 5||BYTE 6||BYTE 7|
|RN + 0||RN + 1||RN + 2||RN + 3||RN + 4||RN + 5||RN + 6||RN + 7|
|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|
(RN + N): Byte N of the 64-bit ROMID; RN + 0 corresponds to the family code
(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.
A host obtains a page signature by issuing the DS28C36 Compute and Read Page Authentication command. To verify the signature, the host needs to know the ingredients that went into the SHA-256 hash computation that fed the ECDSA computation, including the memory page contents. This is especially true of the memory mapped, special function pages 28 and 29, since their contents can change on each read with the inclusion of a random page seed or GPIO change. An error is returned by the DS28C36 if the special function pages are not read before the authentication is requested. The host must also know the DS28C36 public key that was created in the Key Pair Generation step. This public key should be verified as part of the authentication system with a certificate (refer to application note 6434, “How to Verify the DS28C36 ECDSA Certificate”).
The host generates a challenge used in the SHA-256 hash computation to verify the DS28C36 can compute a valid response signature. The challenge should be a random number to prevent replay attacks. The challenge is written via the DS28C36 Write Buffer command and can be read via the DS28C36 Read Buffer command. Authentication does not fail if the challenge is not explicitly written, but this is not recommended. To further prevent a replay attack, the signature computation also includes a random number that is automatically generated by the DS28C36. This results in a signature that is different every time, even with the same challenge.
Once all necessary data, including the signature, is collected, the host performs the signature verification algorithm as shown in Figure 4. If the result is "pass," the DS28C36 is verified to have the private portion of device public key. This, in combination with the verification of the public key certificate, completes a full device authentication. If the result is “fail,” either because the public key is not valid for the DS28C36's private key or the signature is not computed correctly, the authentication fails and the system rejects the device.
Figure 4. Signature verification by the host.
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 Signature Verification sequences are performed in the application DS28C36_Setup_Verify_Signature.exe and shown in the source file ds28c36_setup_verify_signature.c. Similarly, Device Identification and Signature Verification can be found in the DS28C36_Application_Verify_signature.exe application and its source file ds28c36_application_verify_signature.c. These source files employ common routines from a collection of device-specific functions located in various modules included in the .zip package named: Deep_Cover_DS28C36_Verify_Signature_v1p0.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‘)