Asymmetric Authentication - Use Case Example
Authentication
to authenticate; to prove that something is real, true, or genuine.

In terms of computer security, it is a process in which two entities exchange information to authenticate the identity of the other.

In this use case example, we will authenticate an object. It can be an accessory, peripheral, battery, or cartridge. Generally, an object that is removable and replaceable by the consumer. The purpose of authenticating an object is to ensure that it is genuine and it is authorized to connect to a product. Another purpose is to prevent cloning and counterfeiting.

Asymmetric authentication uses asymmetric key algorithms (also known as public key cryptography) where each entity has a public and private key.

The Provisioning Process (Factory Setup)

Initially, we start with an Authority Module pre-provisioned with the Authority Private and Public keys. We also have the Manufacturing Module pre-provisioned with the Manufacturer Private and Public keys. Each manufacturing site will have its own Manufacturing Module.

Authenticating the Manufacturing Module

Step 1:

The Manufacturing Public key is sent to the Authority Module to be signed by the Authority Private key.

Step 2:

The resultant Manufacturing Certificate is sent back to the Manufacturing Module. This establishes the manufacturing site as a genuine authorized producer of end products.

aa-fig-01.png
FIGURE 1: Authenticating the Manufacturing Module

Authenticating the End Product

Step 3:

During production, provisioning firmware is run which supplies the End Product (device) Public Key to the Manufacturing Module.

Step 4:

The Manufacturing Module signs the device public key with its Private key and supplies a Device Certificate to the end product.

Step 5:

The Manufacturing public key and the Manufacturing certificate are placed in the end product at the time of manufacture.

aa-fig-02.png
FIGURE 2: Authenticating the End Product

This completes the provisioning the Chain of Trust.

The Authentication Process (Running in the field)

All aspects of the authentication process will be done through runtime firmware

Authenticating the Peripheral

Step 1:

Verify Signer Public Key: The Host requests the Manufacturing Public key and Certificate. The Host verifies the certificate with the Authority Public key.

Step 2:

Verify Device Public Key: If the verification is successful, the Host requests the Device Public key and Certificate. The Host verifies the certificate with the Manufacturing Public key.

Up until this point, everything could be recorded and replayed so we need to test (challenge) if the device contains the private key associated with the public key we just verified.

Step 3:

Challenge – Response: If the verification is successful, the Host creates a random number challenge and sends it to the End Product (Peripheral). The End Product signs the random number challenge with the Device Private key.

Step 4:

The signature is sent back to the Host for verification using the Device Public key.

The Chain of Trust has been verified back to the Root of Trust.

aa-fig-03.png
FIGURE 3: Authenticating the Peripheral
© 2018 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.