Introduction
Microchip’s (formerly Atmel’s) ATECC508A is a small IC with a cryptographic co-processor and secure, hardware-based key storage. It uses hardware acceleration to implement the ECDSA signature protocols, ECDH key agreement, and SHA-256 hashing. Each device has a unique 72-bit serial number, enough storage for up to 16 keys, 10Kb EEPROM, and a high-quality FIPS random number generator. Like all chips in the CryptoAuthentication family, system integration is easy due to the low pin count, low current consumption, and wide supply voltage range. The ATECC508A is well suited for many applications, including secure download and boot, message security, secure data storage, password checking, etc. However, the application of interest for this article is node authentication (and a bit of anti-counterfeiting) [1].
Node authentication occurs between two devices in a host-client configuration when the client’s identity must be verified before its connection to the host can be established. The term “node” in this context refers to the device being authenticated, i.e. the client. Common examples of nodes are end devices in IoT networks and device accessories such as batteries, printer cartridges, etc [2]. The concept of node authentication goes hand in hand with anti-counterfeiting because counterfeit (and possibly malicious) clients will fail the node authentication procedure and not be allowed to connect to the host.
Microchip’s only example project for the ATECC508A is an excellent all-in-one node authentication demonstration utilizing one SAM D21 Xplained Pro Evaluation Kit and one CryptoAuth Xplained Pro Evaluation Kit. These kits are first used to simulate a typical provisioning process before being used as both the host and client in the node authentication procedure. The project firmware along with an accompanying application note [2] can be found on Microchip’s website here (login required). This application note provides a good overview of the example project as well as a summary of each authentication step. Unfortunately for those just starting out, Microchip assumes a certain level of proficiency in cryptography and public key infrastructure. Therefore, the purpose of this article is not to replace the application note, but rather to supplement it by reviewing any relevant cryptography basics and illustrating how they are used to implement this realistic example. Before reading on, however, be sure to review the application note as it provides detailed information on hardware and software perquisites as well as how to get the example up and running.
Provisioning
Before the crypto device can be used in its intended application, it must be provisioned. This is the process of modifying the appropriate configuration data and loading security keys, certificates, and other application specific data [3]. Provisioning is a one-time step that is typically done before the end product is assembled, during the actual assembly, or during testing with the help of a Hardware Security Module (HSM) for large volumes or a provisioning toolkit for low volumes [4]. Once the process is complete, the device’s configuration and data zones will be locked to prevent changes and to keep the secrets safe.
To fully understand the way provisioning is implemented in this example, we will first consider how a device would be provisioned using Microchip’s provisioning toolkit. The overall process used by the toolkit to achieve a provisioned device is the same as that used by the example project, but since the toolkit is not an “all-in-one” implementation, it is easier to visualize how the individual components work together. Before we dive in, though, it will be helpful to quickly review some cryptography basics that are not only relevant in this section, but the following sections as well.
Background
Once provisioned, the keys and certificates loaded into the device act as its identification. Not only are they unique to the device, but they are also signed by a trusted authority (typically the manufacturer) which attests to the device’s legitimacy. Let’s take a closer look at these constructs in a bit more detail.
Keys
The ATECC508A utilizes Elliptic Curve Cryptography (ECC), which is a public key cryptosystem. This means that each crypto device must have at least one pair of keys associated with it, one private and one public. Any cryptographic operation done with the private key can only be undone with the corresponding public key and vice versa. As the names suggest, the private key is known only by the device whereas the public key can be freely distributed to other clients or hosts in the system. In fact, since the ATECC508A can implement all necessary ECC cryptographic operations with integrated hardware acceleration, there is no reason for the private key to ever leave the device. Therefore, once the key pairs are generated, the private key slots are permanently locked and cannot be read [1].
The reason public key cryptosystems work is because it is not computationally feasible to determine the private key knowing only the public key. ECC is the optimal cryptographic scheme to use on a small device like the ATECC508A because it allows smaller keys to be used without compromising security. On the ATECC508A, the keys are 256-bits long and provide far better security than a similar RSA cryptosystem using 2048-bit long keys [5].
Certificates
When using a public key cryptosystem, we must address the problem of how to associate a given public key with the device it belongs to. After all, these keys are public. What’s to stop a counterfeit device from using a legitimate device’s public key to masquerade as said legitimate device? One solution is for a trusted source to issue the legitimate device a certificate that vouches for its ownership of the public key. Then, when the counterfeit device presents a public key without a certificate (or an invalid certificate), the host will know it is not legitimate. The issuers of these public key certificates are called certification authorities (CAs) [5] and they are known and trusted by every host in the network of devices.
A certificate is simply a data structure that contains at least a public key, some naming information, and a digital signature [5]. The ATECC508A utilizes X.509 certificates that are stored on the device in a compressed format. Table 1 outlines the fields present in these certificates and what information they store.
Table 1: X.509 Certificate Fields [5]
| Version | X.509 version in use |
|---|---|
| Serial Number | A serial number for the certificate |
| Algorithm ID | Algorithm used to digitally sign the certificate |
| Issuer | Name of the certificate issuer |
| Validity | The date the certificate becomes valid and the date it expires |
| Subject | Name of the owner of the certificate |
| Subject Public Key Info | The certificate owner’s public key (and corresponding algorithm, length, etc.) |
| Issuer Unique Identifier | Optional information about the issuer of the certificate |
| Subject Unique Identifier | Optional information about the owner of the certificate |
| Extensions | More optional information |
| Signature | A digital signature that conforms to the ‘Algorithm ID’ field |
Signatures
Digital signatures must be included with certificates to prevent forgery. By understanding the signing process, we can see how they accomplish this. Figure 1 provides an overview of the entire procedure. It starts with the certificate data that needs to be signed, often called the To Be Signed (TBS) Data, being passed as input into the SHA-256 function. SHA-256 is a cryptographic hash function that takes an input of arbitrary length and outputs a fixed length number (in this case 256 bits) often referred to as a digest. Note that if so much as one bit of the input were to be changed, an entirely new digest would be created. What makes this function ‘cryptographic’ is the fact that it is very easy to compute the digest given the input, but practically impossible to compute the input given only the digest [5].
In Figure 1, the CA is the red signer module containing a public/private key pair. The private key is used to sign the 256-bit digest using the Elliptic Curve Digital Signature Algorithm (ECDSA) Sign function. The resulting signature is then appended to the end of the certificate data to create a complete certificate. When the time comes to verify the certificate’s authenticity, the complementary ECDSA Verify operation will be performed using the signature, TBS digest, and the signer module’s public key; as we will see later.
It should now be clear why forging a signed certificate is no easy task. Creating a counterfeit certificate from scratch would require the CA’s private key, which is locked inside the signer module and, thanks to the cryptographic strength of ECDSA, is unattainable given only an existing certificate [5]. Modifying the fields in an existing certificate is also out of the question because doing so would result in a completely different digest at verification time, causing the ECDSA Verify operation to fail.
Provisioning Overview
When provisioning devices to be used in some network or system, one CA is usually not enough. Typical systems will include nodes manufactured at different facilities or even produced by different manufacturers. Using a single CA would then require multiple copies of its private key do be distributed to every provisioning facility, which greatly increases the likelihood of a security breech. A better solution is to use multiple CAs and organize them into a Public Key Infrastructure (PKI). In the case of the X.509 standard, a hierarchical model is used to create a chain of certificates that extend trust from a globally trusted root CA to the end device [5]. To accomplish this, the root CA will issue certificates to a set of intermediate CAs, allowing them to issue certificate to end devices (or possibly other CAs) on the root CA’s behalf. This avoids undesirable decentralization of the root CA and further improves security by allowing the root CA to revoke certificates of intermediate CAs should they become compromised.
This PKI structure is employed by the AT88CKECCPROVISION provisioning kit (Figure 2), which is simply a combination of one AT88CKECCROOT kit and one AT88CKECCSIGNER kit. It comes with 3 USB root modules (one primary and two backups) which act as the root CA and 3 USB signer modules (again, one primary and two backups) which act as the intermediate CA. Microchip provides all the necessary software and documentation to get started with these modules and use them to provision the end devices. The first step, of course, is to generate the root module’s private/public key pair and lock the private key into the module. The public key is generally distributed to all nodes requiring it in the form of a self-signed certificate, which is the only kind that the root module can have since there is no CA more trusted then it. Next, the root module provisions the signer module by telling it to generate its own private/public key pair and assigning it a special certificate granting it CA privileges. The signer is then free to provision regular devices, as shown in Figure 3.
The provisioning process is controlled by a provisioning client, which is a piece of software that interacts with the ATECC508A device. The client connects to a provisioning server, which is another piece of software that interacts with the signer module. The implementation of the client and server components may vary from application to application. They may both be running on the same machine or running on different machines communication over a network. The client may even be embedded on the end node’s MCU, allowing the device to be provisioned after the product is assembled [6]. Regardless, the provisioning process outlined in Figure 3 will not change. Once the client is connected to the server and establishes communication with the ATECC508A, the process can begin.
- The first thing the client must do is modify the configuration zone as required by the application and then lock it. This may include changing the I2C address, customizing the slot configurations, setting up monotonic counters, etc. Once the configuration zone is locked, the client will be allowed to modify the data zone in the following steps [7].
- Now that the data zone can be personalized, the client instructs the ATECC508A to generate its private/public key pair(s). Recall that the device is capable of generating a random private key internally, storing it in a protected slot, and returning only the calculated public key to the client, keeping the private key completely secret [1].
- With the public key in hand, the client is free to request a certificate from the provisioning server. Using a template of the certificate, the device’s public key, and all other device information send by the client; the server constructs the device certificate’s TBS data [3].
- The TBS data is sent to the signer module to be signed. We can refer back to Figure 1 to recall how this works. The signer module first uses its internal SHA-256 algorithm to obtain the TBS digest. It then uses its internal ECDSA signature generation element and private key to create a signature based on the TBS digest. Finally, this signature is returned to the server.
- The server completes the device’s certificate by appending the signature to the TBS data. It then completes the client’s request by sending it not only the device’s certificate, but the signer’s certificate as well.
- The client will store both the device and signer certificates on the ATECC508A in a compressed format. The compressed certificates include the public keys, certificate elements, and signatures. This information can later be recombined with the certificate templates to construct the original certificates [3].
- If any other data required by the application needs to be written to the device, it will be done now before the data zone is locked. Once the appropriate slots in the data zone are locked (which may or may not include the certificate slots), the provisioning process is complete.
Provisioning Simulation
Now that we have a good idea of how provisioning works and what it accomplishes, we can return our focus to the example project. The main hardware components required to run this example are the SAM D21 MCU and the ATECC508A crypto device, but notice there is no signer or root module. This is because on top of providing cryptographic services for the node, the ATECC508A is also acting as the root module and the signer module by creating and storing two extra sets of keys. We can see this by executing the client-provision command in the serial terminal. After completing the first step by writing and locking the configuration zone, three private/public key pairs are generated and each of the public keys is shown as output. As the labels indicate, one key belongs to the device, another belongs to the signer, and the last belongs to the signer’s CA (i.e. the root CA). Since the root, signer, and device modules are all implemented on the same crypto device, there is no need to have separate threads acting as the provisioning client and provisioning server on the MCU. Instead, the project code contains only a single function that combines these two processes into a single thread of execution.
The next step then, according to Figure 3, is to build and sign the device certificate. However, this cannot be done until a certificate has been issued to the “signer module” by the “root module” giving it the authority to issue device certificates. Therefore, the signer certificate is first built and singed by the root CA’s private key before the device certificate is built and signed by the signer CA’s private key. Once these certificates are constructed, they are printed to the serial terminal in X.509 DER (Distinguished Encoding Rules) format as shown below. This data is not what is stored on the ATECC508A in the next step, but rather just a binary representation of the certificate. The compressed certificate is created by extracting the variable data that changes from certificate to certificate and storing it on the crypto device. The static data is stored in the MCU memory as a template that can be used to reconstruct the original certificate. Since both the device and signer certificates are stored on the ATECC508A, the application must have templates for both the device and signer certificates in order to reconstruct them.
client-provision output from [2]
$ client-provision
Signer CA Public Key:
02 54 9E 50 2F 7C 13 1E C5 DA 7A 8B BF 5E 0D 05
E1 3D 8E 11 F4 F1 04 D2 F6 CE 41 44 FA 40 E6 D4
02 3C A0 80 30 B1 DE F1 4A A7 CE A3 FF 12 4B 4B
A5 91 E0 F1 59 EF 67 A9 68 E5 CC 5C 0B FD E8 7A
Signer Public Key:
A3 AC C0 2F 35 17 15 08 68 B1 10 43 24 F9 EA 30
17 2C B1 11 AB A1 F0 B5 0B 4B 85 77 2B F3 14 08
70 C0 69 8E AF AA 6A 58 F9 8E 22 0F 3A 9E F8 35
C0 6A 5D FB C5 25 F4 56 5A A7 AB A9 E9 B1 44 E6
Device Public Key:
B9 17 F9 9F BA A0 AF 3C 67 61 B8 DB D8 2F 8E 6B
C1 CB D0 CF 87 82 08 0E 2B D3 EC EF E8 E9 C5 3B
E2 1C 2E 5D CC A1 92 A5 A1 22 68 EA FF 94 68 F5
C0 54 DD 32 40 F9 F6 C2 9B AF 0D 46 36 EC 5F 26
Signer Certificate:
30 82 01 B1 30 82 01 57 A0 03 02 01 02 02 03 40
C4 8B 30 0A 06 08 2A 86 48 CE 3D 04 03 02 30 36
31 10 30 0E 06 03 55 04 0A 0C 07 45 78 61 6D 70
6C 65 31 22 30 20 06 03 55 04 03 0C 19 45 78 61
6D 70 6C 65 20 41 54 45 43 43 35 30 38 41 20 52
6F 6F 74 20 43 41 30 1E 17 0D 31 34 30 38 30 32
32 30 30 30 30 30 5A 17 0D 33 34 30 38 30 32 32
30 30 30 30 30 5A 30 3A 31 10 30 0E 06 03 55 04
0A 0C 07 45 78 61 6D 70 6C 65 31 26 30 24 06 03
55 04 03 0C 1D 45 78 61 6D 70 6C 65 20 41 54 45
43 43 35 30 38 41 20 53 69 67 6E 65 72 20 43 34
38 42 30 59 30 13 06 07 2A 86 48 CE 3D 02 01 06
08 2A 86 48 CE 3D 03 01 07 03 42 00 04 A3 AC C0
2F 35 17 15 08 68 B1 10 43 24 F9 EA 30 17 2C B1
11 AB A1 F0 B5 0B 4B 85 77 2B F3 14 08 70 C0 69
8E AF AA 6A 58 F9 8E 22 0F 3A 9E F8 35 C0 6A 5D
FB C5 25 F4 56 5A A7 AB A9 E9 B1 44 E6 A3 50 30
4E 30 0C 06 03 55 1D 13 04 05 30 03 01 01 FF 30
1D 06 03 55 1D 0E 04 16 04 14 BB 5C 3D F7 4D 4C
93 D4 2B 50 D1 7F B3 23 C3 3A B0 2C 27 BA 30 1F
06 03 55 1D 23 04 18 30 16 80 14 14 B0 97 8A 1D
57 50 FF 52 F9 DF A8 90 60 77 60 C5 3C 6B 50 30
0A 06 08 2A 86 48 CE 3D 04 03 02 03 48 00 30 45
02 21 00 FB 08 10 99 B3 F0 A8 E5 D5 19 3F 1A A2
20 94 06 A1 63 D9 4A CE 18 6A 80 C6 6A E7 91 42
6C 58 7D 02 20 46 85 5F 9D 71 F2 B9 48 84 75 2E
49 2F D7 58 AD 1B EB BD 36 A5 74 64 2B 6B EA 02
26 5A 72 13 3F
Device Certificate:
30 82 01 8A 30 82 01 30 A0 03 02 01 02 02 0A 40
01 23 6F 12 D9 2C A5 71 EE 30 0A 06 08 2A 86 48
CE 3D 04 03 02 30 3A 31 10 30 0E 06 03 55 04 0A
0C 07 45 78 61 6D 70 6C 65 31 26 30 24 06 03 55
04 03 0C 1D 45 78 61 6D 70 6C 65 20 41 54 45 43
43 35 30 38 41 20 53 69 67 6E 65 72 20 43 34 38
42 30 1E 17 0D 31 35 30 39 30 33 32 31 30 30 30
30 5A 17 0D 33 35 30 39 30 33 32 31 30 30 30 30
5A 30 35 31 10 30 0E 06 03 55 04 0A 0C 07 45 78
61 6D 70 6C 65 31 21 30 1F 06 03 55 04 03 0C 18
45 78 61 6D 70 6C 65 20 41 54 45 43 43 35 30 38
41 20 44 65 76 69 63 65 30 59 30 13 06 07 2A 86
48 CE 3D 02 01 06 08 2A 86 48 CE 3D 03 01 07 03
42 00 04 B9 17 F9 9F BA A0 AF 3C 67 61 B8 DB D8
2F 8E 6B C1 CB D0 CF 87 82 08 0E 2B D3 EC EF E8
E9 C5 3B E2 1C 2E 5D CC A1 92 A5 A1 22 68 EA FF
94 68 F5 C0 54 DD 32 40 F9 F6 C2 9B AF 0D 46 36
EC 5F 26 A3 23 30 21 30 1F 06 03 55 1D 23 04 18
30 16 80 14 BB 5C 3D F7 4D 4C 93 D4 2B 50 D1 7F
B3 23 C3 3A B0 2C 27 BA 30 0A 06 08 2A 86 48 CE
3D 04 03 02 03 48 00 30 45 02 20 35 96 2E 3F F4
1A 3A DA E7 6F E1 FE 9D 7A 83 BE 36 FA 06 C5 01
79 55 F2 2C 8C FE 1D 43 38 19 CC 02 21 00 E8 53
87 83 A6 98 21 8E 43 A0 08 73 B3 FD B4 4B 7E 1C
EC FB 61 33 52 59 99 DF B1 E1 79 3E D7 8B
Once provisioning is complete, the configuration and data zones will be locked. So, what happens if we run the client-provision command a second time? As the output below shows, the slot used to store the root CA’s private key is not accessible. As a workaround, the application will only generate the signer’s and device’s private/public key pairs and the root CA will use the signer’s keys for signing and verification. As a result, the signer’s certificate will be self-signed and its link in the certificate chain will be redundant. As far as the rest of the example is concerned, though, these are perfectly valid certificates and will pass the node authentication procedure without a problem.
client-provision output when the device is already provisioned
Signer CA slot 7 not available. Signer CA and signer will be sharing a key.
Signer CA Public Key:
0E 50 F5 7B 67 1B F9 08 20 D8 49 D8 26 DE 43 38
F6 C8 2B 2C 8A 6E 1C 96 0E 8F A6 21 04 02 3D 66
8A 49 3D 41 86 1A DC E5 7C 8E 10 E3 A9 0A 7A 18
ED FC 66 7A 31 E4 5E 91 F3 83 32 52 6C 1E 38 7B
Signer Public Key:
0E 50 F5 7B 67 1B F9 08 20 D8 49 D8 26 DE 43 38
F6 C8 2B 2C 8A 6E 1C 96 0E 8F A6 21 04 02 3D 66
8A 49 3D 41 86 1A DC E5 7C 8E 10 E3 A9 0A 7A 18
ED FC 66 7A 31 E4 5E 91 F3 83 32 52 6C 1E 38 7B
Device Public Key:
8E 84 0F 32 3C 6E 75 5F F4 85 71 30 90 0C 8E C7
17 81 30 CB 99 33 0A 21 DE 94 87 DB EC BF 0F EB
13 1A B0 D3 DA 79 EB 84 7B F2 8F 3A 99 2D 98 B8
45 5A 64 EA AF 6A DC 06 5E F9 2A 69 01 AC 72 74
Signer Certificate:
30 82 01 F0 30 82 01 97 A0 03 02 01 02 02 11 7D
A2 58 75 4A CB D1 8D 93 2E AC 5C 4F 10 BB 59 01
30 0A 06 08 2A 86 48 CE 3D 04 03 02 30 43 31 1D
30 1B 06 03 55 04 0A 0C 14 45 78 61 6D 70 6C 65
20 4F 72 67 61 6E 69 7A 61 74 69 6F 6E 31 22 30
20 06 03 55 04 03 0C 19 45 78 61 6D 70 6C 65 20
41 54 45 43 43 35 30 38 41 20 52 6F 6F 74 20 43
41 30 20 17 0D 31 34 30 38 30 32 32 30 30 30 30
30 5A 18 0F 39 39 39 39 31 32 33 31 32 33 35 39
35 39 5A 30 47 31 1D 30 1B 06 03 55 04 0A 0C 14
45 78 61 6D 70 6C 65 20 4F 72 67 61 6E 69 7A 61
74 69 6F 6E 31 26 30 24 06 03 55 04 03 0C 1D 45
78 61 6D 70 6C 65 20 41 54 45 43 43 35 30 38 41
20 53 69 67 6E 65 72 20 43 34 38 42 30 59 30 13
06 07 2A 86 48 CE 3D 02 01 06 08 2A 86 48 CE 3D
03 01 07 03 42 00 04 0E 50 F5 7B 67 1B F9 08 20
D8 49 D8 26 DE 43 38 F6 C8 2B 2C 8A 6E 1C 96 0E
8F A6 21 04 02 3D 66 8A 49 3D 41 86 1A DC E5 7C
8E 10 E3 A9 0A 7A 18 ED FC 66 7A 31 E4 5E 91 F3
83 32 52 6C 1E 38 7B A3 66 30 64 30 12 06 03 55
1D 13 01 01 FF 04 08 30 06 01 01 FF 02 01 00 30
0E 06 03 55 1D 0F 01 01 FF 04 04 03 02 02 84 30
1D 06 03 55 1D 0E 04 16 04 14 63 13 1C DA 1F 05
0C 5C C2 C2 6E E4 26 29 92 AB BA AD 49 75 30 1F
06 03 55 1D 23 04 18 30 16 80 14 63 13 1C DA 1F
05 0C 5C C2 C2 6E E4 26 29 92 AB BA AD 49 75 30
0A 06 08 2A 86 48 CE 3D 04 03 02 03 47 00 30 44
02 20 50 28 9A 62 C4 04 23 F2 61 BE 40 BE C2 88
1C 49 DB 7C CB 9C C6 B9 AA 9C D8 C6 AE 37 5E 29
5F 50 02 20 35 5A ED FC 14 4B 4F C4 C1 94 56 E5
96 9D 2F 50 1E 39 1B A4 E3 4F 55 B4 87 36 B2 1D
F0 4E FA 18
Device Certificate:
30 82 01 AD 30 82 01 53 A0 03 02 01 02 02 11 42
FD D0 00 69 D4 57 0E A8 4D 7C A6 B1 2F 82 26 02
30 0A 06 08 2A 86 48 CE 3D 04 03 02 30 47 31 1D
30 1B 06 03 55 04 0A 0C 14 45 78 61 6D 70 6C 65
20 4F 72 67 61 6E 69 7A 61 74 69 6F 6E 31 26 30
24 06 03 55 04 03 0C 1D 45 78 61 6D 70 6C 65 20
41 54 45 43 43 35 30 38 41 20 53 69 67 6E 65 72
20 43 34 38 42 30 20 17 0D 31 35 30 39 30 33 32
31 30 30 30 30 5A 18 0F 39 39 39 39 31 32 33 31
32 33 35 39 35 39 5A 30 42 31 1D 30 1B 06 03 55
04 0A 0C 14 45 78 61 6D 70 6C 65 20 4F 72 67 61
6E 69 7A 61 74 69 6F 6E 31 21 30 1F 06 03 55 04
03 0C 18 45 78 61 6D 70 6C 65 20 41 54 45 43 43
35 30 38 41 20 44 65 76 69 63 65 30 59 30 13 06
07 2A 86 48 CE 3D 02 01 06 08 2A 86 48 CE 3D 03
01 07 03 42 00 04 8E 84 0F 32 3C 6E 75 5F F4 85
71 30 90 0C 8E C7 17 81 30 CB 99 33 0A 21 DE 94
87 DB EC BF 0F EB 13 1A B0 D3 DA 79 EB 84 7B F2
8F 3A 99 2D 98 B8 45 5A 64 EA AF 6A DC 06 5E F9
2A 69 01 AC 72 74 A3 23 30 21 30 1F 06 03 55 1D
23 04 18 30 16 80 14 63 13 1C DA 1F 05 0C 5C C2
C2 6E E4 26 29 92 AB BA AD 49 75 30 0A 06 08 2A
86 48 CE 3D 04 03 02 03 48 00 30 45 02 21 00 CB
19 C7 79 53 79 5F 9F 9A F5 B8 00 82 80 08 E2 51
A2 D3 7F 06 89 5A 21 1F 57 57 CD 60 52 3B 3C 02
20 59 0F 1E 57 BB EA 01 39 64 67 D5 50 5D 0F 60
B8 DF 45 6A EF 6B 75 91 AA 39 20 63 52 48 6D 81
23
Device Authentication
With provisioning out of the way, the application can change gears and take on two new roles: client and host. Whereas in the previous step the MCU acted as a provisioner (provisioning server and provisioning client combination) and the ATECC508A was being provisioned, from this point forward these two components will work together to simulate both a client device and a host device. The client is the actual node being authenticated while the host is the device performing the authentication. Microchip’s favorite example is that of a printer and a printer cartridge. Both devices will have an MCU and an ATECC508A IC. The cartridge is the client requesting authentication by the host, which in this case is the printer. Since our example project plays both roles concurrently, the labels on the command output will begin with either “CLIENT:” or “HOST:” so we can tell which entity is responsible for the operation performed.
Authenticating the client is done in two stages. The first is verifying the validity of the certificate chain that was created during provisioning. If the root CA is not the “root of trust” for the client, then the client will fail authentication. The second stage is verifying the client’s public key. Since the certificates in this example were not locked into their slots, it is possible that they may be stolen, allowing a counterfeit device to pass the first authentication step. We combat this by asking the client to sign a random number, often called a challenge or nonce , with its private key. If the host is then able to verify the signature with the client’s public key, it can be confident that the certificates indeed belong to the device they came from.
Verify the Certificate Chain
This stage is divided into two steps. First the certificates are retrieved from the client and then they are verified.
Client Build
Before it sends the certificates to the host, the client must rebuild them from the compressed certificates stored on the ATECC508A. It does this by combining the compressed certificate data with certificate templates stored locally on the MCU. We can see it is indeed successful because after executing the client-build command, the certificate data printed to the serial output is the same certificate data shown during the provisioning step. Notice that this time the output has the “CLIENT:” label, indicating that this operation was performed on the client device.
client-build output from [2]
$ client-build
CLIENT: Rebuilt Signer Certificate:
30 82 01 B1 30 82 01 57 A0 03 02 01 02 02 03 40
C4 8B 30 0A 06 08 2A 86 48 CE 3D 04 03 02 30 36
31 10 30 0E 06 03 55 04 0A 0C 07 45 78 61 6D 70
6C 65 31 22 30 20 06 03 55 04 03 0C 19 45 78 61
6D 70 6C 65 20 41 54 45 43 43 35 30 38 41 20 52
6F 6F 74 20 43 41 30 1E 17 0D 31 34 30 38 30 32
32 30 30 30 30 30 5A 17 0D 33 34 30 38 30 32 32
30 30 30 30 30 5A 30 3A 31 10 30 0E 06 03 55 04
0A 0C 07 45 78 61 6D 70 6C 65 31 26 30 24 06 03
55 04 03 0C 1D 45 78 61 6D 70 6C 65 20 41 54 45
43 43 35 30 38 41 20 53 69 67 6E 65 72 20 43 34
38 42 30 59 30 13 06 07 2A 86 48 CE 3D 02 01 06
08 2A 86 48 CE 3D 03 01 07 03 42 00 04 A3 AC C0
2F 35 17 15 08 68 B1 10 43 24 F9 EA 30 17 2C B1
11 AB A1 F0 B5 0B 4B 85 77 2B F3 14 08 70 C0 69
8E AF AA 6A 58 F9 8E 22 0F 3A 9E F8 35 C0 6A 5D
FB C5 25 F4 56 5A A7 AB A9 E9 B1 44 E6 A3 50 30
4E 30 0C 06 03 55 1D 13 04 05 30 03 01 01 FF 30
1D 06 03 55 1D 0E 04 16 04 14 BB 5C 3D F7 4D 4C
93 D4 2B 50 D1 7F B3 23 C3 3A B0 2C 27 BA 30 1F
06 03 55 1D 23 04 18 30 16 80 14 14 B0 97 8A 1D
57 50 FF 52 F9 DF A8 90 60 77 60 C5 3C 6B 50 30
0A 06 08 2A 86 48 CE 3D 04 03 02 03 48 00 30 45
02 21 00 FB 08 10 99 B3 F0 A8 E5 D5 19 3F 1A A2
20 94 06 A1 63 D9 4A CE 18 6A 80 C6 6A E7 91 42
6C 58 7D 02 20 46 85 5F 9D 71 F2 B9 48 84 75 2E
49 2F D7 58 AD 1B EB BD 36 A5 74 64 2B 6B EA 02
26 5A 72 13 3F
CLIENT: Rebuilt Device Certificate:
30 82 01 8A 30 82 01 30 A0 03 02 01 02 02 0A 40
01 23 6F 12 D9 2C A5 71 EE 30 0A 06 08 2A 86 48
CE 3D 04 03 02 30 3A 31 10 30 0E 06 03 55 04 0A
0C 07 45 78 61 6D 70 6C 65 31 26 30 24 06 03 55
04 03 0C 1D 45 78 61 6D 70 6C 65 20 41 54 45 43
43 35 30 38 41 20 53 69 67 6E 65 72 20 43 34 38
42 30 1E 17 0D 31 35 30 39 30 33 32 31 30 30 30
30 5A 17 0D 33 35 30 39 30 33 32 31 30 30 30 30
5A 30 35 31 10 30 0E 06 03 55 04 0A 0C 07 45 78
61 6D 70 6C 65 31 21 30 1F 06 03 55 04 03 0C 18
45 78 61 6D 70 6C 65 20 41 54 45 43 43 35 30 38
41 20 44 65 76 69 63 65 30 59 30 13 06 07 2A 86
48 CE 3D 02 01 06 08 2A 86 48 CE 3D 03 01 07 03
42 00 04 B9 17 F9 9F BA A0 AF 3C 67 61 B8 DB D8
2F 8E 6B C1 CB D0 CF 87 82 08 0E 2B D3 EC EF E8
E9 C5 3B E2 1C 2E 5D CC A1 92 A5 A1 22 68 EA FF
94 68 F5 C0 54 DD 32 40 F9 F6 C2 9B AF 0D 46 36
EC 5F 26 A3 23 30 21 30 1F 06 03 55 1D 23 04 18
30 16 80 14 BB 5C 3D F7 4D 4C 93 D4 2B 50 D1 7F
B3 23 C3 3A B0 2C 27 BA 30 0A 06 08 2A 86 48 CE
3D 04 03 02 03 48 00 30 45 02 20 35 96 2E 3F F4
1A 3A DA E7 6F E1 FE 9D 7A 83 BE 36 FA 06 C5 01
79 55 F2 2C 8C FE 1D 43 38 19 CC 02 21 00 E8 53
87 83 A6 98 21 8E 43 A0 08 73 B3 FD B4 4B 7E 1C
EC FB 61 33 52 59 99 DF B1 E1 79 3E D7 8B
In order to view this certificate data in a human readable format, it must first be written to a binary file. The easiest way to do this with a hex reader program like HxD (but it would also be easy to do with a scripting language like Python). Simply create a new file within the program, copy and paste the hexadecimal data from the serial terminal to the file, and save it with the .crt extension. You should then be able to open on the file from a file browser and view the certificate details. Another option is to use CertUtil on the Windows command line to dump the certificate data like so: CertUtil <filename>.crt . Listing 1 and Listing 2 show the output of this command for the signer certificate and device certificate respectively.
Listing 1: Signer Certificate Dump
X509 Certificate:
Version: 3
Serial Number: 40c48b
Signature Algorithm:
Algorithm ObjectId: 1.2.840.10045.4.3.2 sha256ECDSA
Algorithm Parameters: NULL
Issuer:
CN=Example ATECC508A Root CA
O=Example
NotBefore: 8/2/2014 15:00
NotAfter: 8/2/2034 15:00
Subject:
CN=Example ATECC508A Signer C48B
O=Example
Public Key Algorithm:
Algorithm ObjectId: 1.2.840.10045.2.1 ECC
Algorithm Parameters:
06 08 2a 86 48 ce 3d 03 01 07
1.2.840.10045.3.1.7 ECDSA_P256 (ECDH_P256)
Public Key Length: 256 bits
Public Key: UnusedBits = 0
0000 04 a3 ac c0 2f 35 17 15 08 68 b1 10 43 24 f9 ea
0010 30 17 2c b1 11 ab a1 f0 b5 0b 4b 85 77 2b f3 14
0020 08 70 c0 69 8e af aa 6a 58 f9 8e 22 0f 3a 9e f8
0030 35 c0 6a 5d fb c5 25 f4 56 5a a7 ab a9 e9 b1 44
0040 e6
Certificate Extensions: 3
2.5.29.19: Flags = 0, Length = 5
Basic Constraints
Subject Type=CA
Path Length Constraint=None
2.5.29.14: Flags = 0, Length = 16
Subject Key Identifier
bb 5c 3d f7 4d 4c 93 d4 2b 50 d1 7f b3 23 c3 3a b0 2c 27 ba
2.5.29.35: Flags = 0, Length = 18
Authority Key Identifier
KeyID=14 b0 97 8a 1d 57 50 ff 52 f9 df a8 90 60 77 60 c5 3c 6b 50
Signature Algorithm:
Algorithm ObjectId: 1.2.840.10045.4.3.2 sha256ECDSA
Algorithm Parameters: NULL
Signature: UnusedBits=0
0000 3f 13 72 5a 26 02 ea 6b 2b 64 74 a5 36 bd eb 1b
0010 ad 58 d7 2f 49 2e 75 84 48 b9 f2 71 9d 5f 85 46
0020 20 02 7d 58 6c 42 91 e7 6a c6 80 6a 18 ce 4a d9
0030 63 a1 06 94 20 a2 1a 3f 19 d5 e5 a8 f0 b3 99 10
0040 08 fb 00 21 02 45 30
Non-root Certificate
Key Id Hash(rfc-sha1): bb 5c 3d f7 4d 4c 93 d4 2b 50 d1 7f b3 23 c3 3a b0 2c 27 ba
Key Id Hash(sha1): 46 ce ef 82 75 c3 6b 4e 36 d2 d8 c2 21 54 c2 41 e5 9d 5a 75
Cert Hash(md5): 03 82 0e 24 c5 ed da 03 4e 16 c4 7b 37 de a4 31
Cert Hash(sha1): e5 62 9f 5d c4 13 7d b2 f1 78 c2 9b 09 9b 2b d1 3d e5 dd 25
CertUtil: -dump command completed successfully.
Listing 2: Device Certificate Dump
X509 Certificate:
Version: 3
Serial Number: 4001236f12d92ca571ee
Signature Algorithm:
Algorithm ObjectId: 1.2.840.10045.4.3.2 sha256ECDSA
Algorithm Parameters: NULL
Issuer:
CN=Example ATECC508A Signer C48B
O=Example
NotBefore: 9/3/2015 16:00
NotAfter: 9/3/2035 16:00
Subject:
CN=Example ATECC508A Device
O=Example
Public Key Algorithm:
Algorithm ObjectId: 1.2.840.10045.2.1 ECC
Algorithm Parameters:
06 08 2a 86 48 ce 3d 03 01 07
1.2.840.10045.3.1.7 ECDSA_P256 (ECDH_P256)
Public Key Length: 256 bits
Public Key: UnusedBits = 0
0000 04 b9 17 f9 9f ba a0 af 3c 67 61 b8 db d8 2f 8e
0010 6b c1 cb d0 cf 87 82 08 0e 2b d3 ec ef e8 e9 c5
0020 3b e2 1c 2e 5d cc a1 92 a5 a1 22 68 ea ff 94 68
0030 f5 c0 54 dd 32 40 f9 f6 c2 9b af 0d 46 36 ec 5f
0040 26
Certificate Extensions: 1
2.5.29.35: Flags = 0, Length = 18
Authority Key Identifier
KeyID=bb 5c 3d f7 4d 4c 93 d4 2b 50 d1 7f b3 23 c3 3a b0 2c 27 ba
Signature Algorithm:
Algorithm ObjectId: 1.2.840.10045.4.3.2 sha256ECDSA
Algorithm Parameters: NULL
Signature: UnusedBits=0
0000 8b d7 3e 79 e1 b1 df 99 59 52 33 61 fb ec 1c 7e
0010 4b b4 fd b3 73 08 a0 43 8e 21 98 a6 83 87 53 e8
0020 00 21 02 cc 19 38 43 1d fe 8c 2c f2 55 79 01 c5
0030 06 fa 36 be 83 7a 9d fe e1 6f e7 da 3a 1a f4 3f
0040 2e 96 35 20 02 45 30
Non-root Certificate
Key Id Hash(rfc-sha1): 72 97 4f 05 7c 0e 60 e4 0f e6 e7 9a 45 09 42 c0 c4 53 ad 20
Key Id Hash(sha1): 4f c0 ed 7c e2 a5 0f 66 63 09 3d f4 e1 d2 a8 f2 20 b0 3f 76
Cert Hash(md5): 80 e0 37 20 c2 90 41 f9 f6 9d 6d 15 c6 d4 0b eb
Cert Hash(sha1): 9b cd c9 64 91 a5 66 1f c5 9d 4f a0 9b 9d 80 00 7b c3 41 f7
CertUtil: -dump command completed successfully.
Inspecting these certificates, we see that required fields mentioned in Table 1 are present and accounted for. We also see that the public keys match what was shown in the provisioning step (disregarding the leading 0x04) and that the signer certificate has two extra extensions distinguishing it as a CA. Note that everything after the signature (starting at “Non-root Certificate”) is additional output from the CertUtil command and not part of the certificate.
Host Verify
Once these certificates are passed along to the host, it will verify their signatures in a process that closely resembles the signature generation procedure (Figure 1). The main difference is the use of the ECDSA Verify function rather than the ECDSA Sign function. ECDSA Verify requires three inputs: the same 256-bit digest used during provisioning, the certificate’s signature, and the public key of the CA that signed the certificate. Just as in the provisioning step, the certificate’s TBS data is hashed using the SHA-256 algorithm to create the 256-bit digest. The signature is extracted from the certificate being verified and the public key is extracted from the CA’s certificate. The output is a simple pass or fail depending on the validity of the certificate.
Figure 4 outlines the authentication of the certificate chain starting with the signer’s certificate and ending with the device’s certificate. The root CA’s self-signed certificate is shown in this diagram even though in this example project, the host only knows the root CA’s public key. The example still works, but just know that it is more typical for the entire certificate to be stored locally on the host. Once the signer’s certificate is proven to be authentic, it can be used to verify the signature on the device’s certificate, thereby proving that the device’s certificate is not a forgery. For simplicities sake, this example does not consider the certificates’ expiration dates which normally would also be used during validation.
When the host-chain-verify command is executed, this entire process runs behind the scenes on the host. The command’s output simply conveys the results of the ECDSA Verify function in the order performed. If both the signer and device certificates are verified, the host will know that the client’s public key is a trustworthy one. Whether or not the client actually owns said public key is another matter.
host-chain-verify output from [2]
$ host-chain-verify
HOST: Signer certificate verified against signer certificate authority (CA) public key!
HOST: Device certificate verified against signer public key!
Verify Public Key
The second node authentication stage is to verify that the client possesses the private key that corresponds to the public key in its certificate. Since private keys can never leave the ATECC508A, this stage provides sufficient evidence that the client is the true owner of the public key that was deemed trustworthy in the previous stage. Public key verification is typically done in a three-step challenge-response-verify model [1].
Host Generate Challange
This first step is the most straightforward. The host simply generates a 256-bit random number using the high-quality random number generator in the ATECC508A and sends it to the client. It is important that this number be random so the client cannot send back a pre-calculated signature in the next step. The output of the host-gen-chal command is the generated random number.
host-gen-chal output from [2]
$ host-gen-chal
HOST: Generated challenge:
14 84 E8 89 41 D5 9A 1C AD 1F 68 44 3A 09 C6 45
30 BF 27 38 D2 28 56 B7 DD D6 98 CF 92 AB 3D 69
Client Generate Response
Using the ECDSA Sign function, the client will sign the random challenge with its private key. This is very similar to the certificate signing procedure in Figure 1, except the challenge takes the place of the TBS digest and the signature is sent back to the host as a response. The signature is also printed as output when this step is executed via the client-gen-resp command.
client-gen-resp output from [2]
$ client-gen-resp
CLIENT: Calculated response to host challenge:
BB BD 18 73 C3 88 86 E7 86 4A 53 CF 8F 18 4D EC
1A 39 A2 B9 FC 0B FE 73 CE 51 42 0C FB 81 26 F9
63 C1 A0 AF A8 67 58 FB 3B 9D 19 6B FE 86 98 47
0C 13 C9 95 8D 37 C9 47 57 61 A0 F7 D4 52 42 45
Host Verify Response
Finally, the host uses the client’s response, the public key it extracted from the client’s certificate, and the random challenge as inputs to the ECDSA Verify algorithm. If the signature passes verification, the host can be confident that the client owns the certified public key and is, therefore, authentic. Performing this final step using the host-verify-resp command shows the extracted public key in the output along with the result of the ECDSA Verify function.
host-verify-resp output from [2]
$ host-verify-resp
HOST: Device public key from certificate:
B9 17 F9 9F BA A0 AF 3C 67 61 B8 DB D8 2F 8E 6B
C1 CB D0 CF 87 82 08 0E 2B D3 EC EF E8 E9 C5 3B
E2 1C 2E 5D CC A1 92 A5 A1 22 68 EA FF 94 68 F5
C0 54 DD 32 40 F9 F6 C2 9B AF 0D 46 36 EC 5F 26
HOST: Device response to challenge verified!
Conclusion
Microchip’s node authentication example is an excellent resource for getting started with the CryptoAuthenentication family of devices. However, security topics in general tend to have rather large learning curves and this node authentication example is no exception. The overview provided by the example’s application note is very concise and does not address every question a security novice may have. To help fill in the blanks, device provisioning and two stage authentication were discussed in greater detail to supplement said application note. After reviewing the basic concepts of keys, certificates, and signatures; we were able to better illustrate a typical provisioning process utilizing a public key infrastructure. By doing so, it became easier to understand what it means to verify a certificate chain and verify public key ownership in stages one and two of the node authentication procedure respectively.
References
[1] Atmel Corporation, “Atmel CryptoAuthentication Device,” ATECC508A Summary Datasheet , Feb. 2015 [Revised Oct. 2015].
[2] Atmel Corporation, “Node Authentication Example Using Asymmetric PKI,” Appl. Note 8983 , pp. 1-10.
[3] Atmel Corporation, “Compressed Certificate Definition,” Appl. Note 8974 , pp. 3-5.
[4] E. Asanghanwa, “More Secure, Less Costly IoT Edge Node Security Provisioning,” Nov. 9, 2015. [Online]. Available: http://www.atmel.com/Images/Atmel-8995-CryptoAuth-More-Secure-Less-Costly-IoT-Edge-Node-Security-Provisioning-Article.pdf. [Accessed Nov. 4, 2017].
[5] R. Oppliger, Contemporary Cryptography. Norwood, MA: Artech House, 2011.
[6] Atmel Corporation, “Production Provisioning Guide,” Appl. Note 8971 , pp. 3-14.
[7] Atmel Corporation, “CryptoAuthentication Personalization Guide,” Appl. Note 8845 , pp. 1-3.