Microchip's ATECC608A 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, AES-128 encryption/decryption, and SHA-256 hashing. Each device has a unique 72-bit serial number and an EEPROM array to securely store keys, certificates, and data. It also contains a high-quality 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 ATECC608A is designed to be backwards compatible with its predecessor, the ATECC508A. The updated IC offers some major improvements, however. These include secure boot support, an AES hardware accelerator, and an updated random number generator. This makes it even better for applications such as secure download/boot, message security, secure data storage, password checking, etc. . However, the application of interest for this article is node authentication.
Node Authentication Overview
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. . The concept of node authentication goes hand in hand with anti-counterfeiting because (possibly malicious) counterfeit clients will fail the node authentication procedure and not be allowed to connect to the host.
Microchip provides an excellent node authentication example project originally designed for the ATECC508A. It uses one SAM D21 Xplained Pro Evaluation Kit and one CryptoAuth XPRO-B Evaluation Kit to simulate a typical provisioning workflow before taking on the roles of both the host and the client to demonstrate the node authentication procedure. There is an application note  available to provide an overview of the example project as well as a summary of each authentication step. Unfortunately for those just starting out, this document assumes a certain level of proficiency in the fundamentals of 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.
To get the example up and running, start by going to the CryptoAuthLib Download Page and downloading the current releases of the node-auth-basic project, the cryptoauthlib library, and the application note. Unzip both the project and the library archives and navigate to the
./cryptoauthlib-<release_date>/ directory. Copy the entire lib directory and paste it into the
./node-auth-basic-<release_date>/node-auth-basic/src/cryptoauthlib/ directory. Note that at the time of writing, the comments in the node-auth-basic project still refer to the ATECC508A. However, the current version of the cryptoauthlib library (which we just added to the project) utilizes the ATECC608A by default.
Because this project was designed to utilize the ATECC508A, we need to follow the migration instructions provided in  to properly upgrade to the ATECC608A. Luckily, this simply involves changing a few bytes of the configuration data. Open the project in Atmel Studio and open the
provision.c file. Modify the
g_ecc_configdata array as specified in Table 2 of . It should match the array shown below in Listing 1. You can now follow the instructions in  to connect the hardware, program the development board, and start the console interface.
Before the CryptoAuth device can be used in its intended application, it must be provisioned. This is the process of setting the appropriate configuration data and loading security keys, certificates, and other application specific data . Provisioning is a one-time step that is typically performed at the production facility and can be done either before or after the device is soldered onto the circuit board. 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 application, we will first consider how a device would be provisioned in a typical production scenario. We then show that the example project uses the same process to achieve a provisioned device by combining the provisioning components to create an "all-in-one" implementation. Before we dive in, though, it will be helpful to review some cryptography basics that are relevant in the rest of the article.
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.
The ATECC608A utilizes Elliptic Curve Cryptography (ECC), which is a public key cryptosystem. This means that each CryptoAuth 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 ATECC608A 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 .
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 ATECC608A because it allows smaller keys to be used without compromising security. For instance, on the ATECC608A, the keys are 256-bits long and provide far better security than a similar RSA cryptosystem using 2048-bit long keys .
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 and act as identification for the devices. 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 valid certificate, the host will know it is not legitimate. The issuers of these public key certificates are called certification authorities (CAs)  and they are known and trusted by every host in the network of devices (typically the OEM or a third-party certificate authority provider).
A certificate is simply a data structure that contains at least a public key, some naming information, and a digital signature . The ATECC608A 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 
X.509 version in use
A serial number for the certificate
Algorithm used to digitally sign the certificate
Name of the certificate issuer
The date the certificate becomes valid and the date it expires
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
More optional information
A digital signature that conforms to the ‘Algorithm ID’ field
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. It's important to note that if so much as one bit of the input data were to be changed, an entirely new digest would appear at the output. 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 .
In Figure 1, the CA is the red signer module which securely stores a public/private key pair of its own. 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 complete the certificate. When the time comes to verify the certificate's authenticity, the complementary ECDSA Verify operation will be performed using the signature, the TBS digest, and the signer module's public key; as we will see later in the Device Authentication section.
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 . 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.
Figure 1: Device certificate signing procedure
Public Key Infrastructures
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 . 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 the 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.
A Typical Provisioning Scenario
The provisioning process is controlled by the provisioning client, which is a piece of software that interacts with the CryptoAuth device. The client connects to a provisioning server, which is another piece of software that interacts with the signer module. The signer module can take many forms, such as a USB stick housing specialized, secure hardware (possibly another ATECC608A IC) acting as the device CA. It securely stores its own private/public key pair which it uses to sign the device certificates. The signer module is likely part of a PKI, meaning it contains its own certificate signed by the root module – giving it the authority sign device certificates.
Depending on the point in the production process in which provisioning takes place, there are several possible configurations of the provisioning components. The configuration shown below in Figure 2 closely resembles the scenario simulated by the example application. It assumes that the user's product has already been assembled, meaning the ATECC608A has been soldered to the circuit board along with the microcontroller (MCU) and they communicate with each other over an I2C bus. For larger-scale production, it is more likely that the ATECC608A devices will be provisioned in a programmer before being soldered to the circuit board, in which case the provisioning client would communicate directly with the programmer rather than the user's product .
Figure 2: Possible configuration for provisioning a CryptoAuth device already installed in the user's end product (derived from )
The configuration shown in Figure 2 shows the client and server components implemented as separate processes running on the same PC. However, they could be running on separate machines communicating over a network. It's even possible for the client component to be implemented as part of the MCU's firmware, allowing provisioning to occur at the time of product deployment. Regardless of the component configuration, the provisioning process (outlined below in Figure 3) will stay the same.
Figure 3: Overview of the provisioning process (derived from )
Once the client is connected to the server and establishes communication with the ATECC608A, the process can proceed as follows:
- 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 .
- Now that the data zone can be personalized, the client instructs the ATECC608A 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 .
- 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 .
- 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 accelerator 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 certificate of the signer module as well.
- The client will store both the device and signer certificates on the ATECC608A 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 .
- 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.
Now that we have a good idea of what provisioning accomplishes and how it works, we can return our focus to the example application. The goal at this point is to simulate the provisioning process using minimum hardware for demonstration purposes. Figure 4 shows the configuration of the provisioning components. Notice that all components shown in Figure 2 are present but implemented using only two development boards. The MCU on the SAM D21 Xplained Pro Evaluation Kit implements the functionalities of both the provisioning client and the provisioning server. It communicates directly with the ATECC608A on the CryptoAuth XPRO-B Evaluation Kit, which is now playing three roles in the provisioning process. In addition to acting as the CryptoAuth device being provisioned, it now also simulates the roles of both the signer module and the root module. It does this by creating and storing two extra sets of private/public key pairs and the necessary certificates.
Figure 4: Configuration used by the example application for provisioning the CryptoAuth device (derived from )
client-provision command causes the MCU to provision the CryptoAuth device using a slightly modified version of the provisioning process outlined in Figure 3. Step 1 is completed as normal by writing and locking the configuration data (Listing 1) to the device's configuration zone.
This is a permanent step! Testing different configuration zone options will require starting with a brand new, not yet provisioned ATECC608A device.
In Step 2, the private/public key pairs are generated. We can see in the output of the
client-provision command, provided in Listing 2, that three such pairs are generated: one for the CryptoAuth device, one for the signer module, and one for the root module. The signer module and root module keys will be required to create the certificates in the following steps. Note that only the public keys are shown in the output because the private keys are locked inside the device.
Recall that, in addition to storing a key pair, the signer module also stores a certificate that was signed by its CA (i.e. the root module). Because in this example we are merely simulating a signer module, we will have to create this certificate before moving onto requesting a device certificate in Step 3. This will not only give our "signer module" permission to issue a certificate to the CryptoAuth device, but it will also allow us to properly validate the certificate chain in the Device Authentication section. The command output (Listing 2) shows the signer's certificate printed in X.509 DER (Distinguished Encoding Rules) format after it is constructed and signed using the private key of the "root module". This data is not what is eventually stored on the ATECC608A, but rather just a binary representation of the certificate. The Client Build section provides details on how to view this information in a human readable form.
Now, we can move onto Steps 3–4 , where the CryptoAuth device's certificate is built and signed by the private key of the "signer module" as previously demonstrated in Figure 1. Once completed, this certificate is also printed to the console as part of the command output in X.509 DER format (Listing 2).
Finally, with both the device's and the signer's certificates in hand, we can complete Steps 5–7 and save them to the CryptoAuth device in a compressed format. This is done by extracting the variable data that changes from certificate to certificate (e.g. the public key, expiration date, signature, etc.) and storing only that data on the ATECC608A. The static data that does not change from certificate to certificate is stored in the MCU memory in the form of a certificate template.
After running the
client-provision command, the configuration data (written and locked into the device in Step 1) can never again be changed. However, the configuration in this example does allow the device to be re-provisioned if the
client-provision command is run again. It does this by generating new keys and certificates for the device.
With provisioning out of the way, the application can change gears and take on two new roles: client and host. Whereas in the previous section, the MCU acted as a provisioner (provisioning server and provisioning client combination) and the ATECC608A was the CryptoAuth device 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 node being authenticated while the host is the device performing the authentication. As an example of this, consider a printer and an ink cartridge. The printer (the host) will contain among its circuitry an MCU and an ATECC608A device. The ink cartridge (the client) will also contain an ATECC608A device. When the cartridge is installed in the printer, a direct serial communication connection will be made between the printer MCU and the cartridge CryptoAuth device, as summarized in Figure 5. This allows the printer to authenticate the ink cartridge and ensure it is a genuine, compatible product.
Since the example project plays both roles concurrently, the labels on the command outputs will begin with either "CLIENT:" or "HOST:" so we can tell which device is responsible for the operation performed.
Figure 5: Example host-client configuration for node authentication based on the printer/cartridge example (derived from )
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 that presented them.
Stage 1: Verify the Certificate Chain
This stage is divided into two steps. First the certificates are retrieved from the client and then they are verified by the host.
Before it sends the certificates to the host, the client must rebuild them from the compressed certificates stored on the ATECC608A. 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 console output (Listing 3) is the same certificate data shown during the provisioning step (Listing 2). Notice that this time the output has the "CLIENT:" label, indicating that this operation was performed on the client device.
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. 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 extension ".crt". You should then be able to open the file from a file browser and view the certificate details. Another option is to use a command line utility to display the certificate data. Windows users can open a command prompt and type the command
CertUtil <filename>.crt, replacing
<filename>.crt with the name of the certificate file. Linux/MacOS users can do the same with the openssl utility like so:
openssl x509 -in <filename>.crt -inform der -noout -text. Listing 4 and Listing 5 show the output of this command for the signer certificate and device certificate respectively.
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 Listing 2 during the provisioning step (disregarding the leading 0x04) and that the signer certificate has two extra extensions distinguishing it as a CA.
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 6 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 the 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 (Step 1 in Figure 6), it can be used to verify the signature on the device's certificate (Step 2 in Figure 6), 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.
Figure 6: Verifying the certificate chain
host-chain-verify command is executed, this entire process runs behind the scenes on the "host". The command's output, shown in Listing 6, simply conveys the results of the ECDSA Verify function in order from root to device. 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 will be determined in the second stage of device authentication.
Stage 2: 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 ATECC608A, 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 .
Host Generate Challenge
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 ATECC608A 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, as shown in Listing 7.
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 send 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 (Listing 8).
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 (Listing 9).
Microchip's node authentication example is an excellent resource for getting started with the CryptoAuthenentication family of devices. Security topics in general tend to have rather large learning curves, however, and the 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, signatures, and PKIs; 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 to verify public key ownership in the device authentication procedure.
Contact the Author
 Microchip Technology Inc., "CryptoAuthentication Device Summary Datasheet," ATECC608A, October 2018.
 Atmel Corporation, "Node Authentication Example Using Asymmetric PKI," Appl. Note 8983, pp. 1-10.
 Microchip Technology Inc., "Differences Between the ATECC608A and ATECC508A CryptoAuthentication Devices," Appl. Note 2589, pp. 1-7.
 Atmel Corporation, "Compressed Certificate Definition," Appl. Note 8974, pp. 1-11.
 R. Oppliger, Contemporary Cryptography, Norwood, MA: Artech House, 2011.
 Atmel Corporation, "Production Provisioning Guide," Appl. Note 8971, pp. 1-5.
 Atmel Corporation, "CryptoAuthentication Personalization Guide," Appl. Note 8845, p. 1.