Symmetric 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.

This method avoids the need for an Internet connection and white (or black) list. A white list is a lookup table for identifying approved units. A black list is a lookup table for identifying non-approved units.

This method also allows for a limited number of uses. If the object is to only be used a limited number of times, a counter counts the number of uses. Once the specified number of uses has been reached, authentication ceases and the object can no longer be used.

Symmetric authentication uses symmetric key algorithms (also known as secret key algorithm).

The secrecy of the Parent Key is critical to this method. A compromised Parent Key compromises the entire system of products. Hardware tamper protection is highly recommended. It is a best practice to limit the distribution of the Parent Key to an absolute minimum.

The Provisioning Process (Factory Setup)

The Authority creates a Secret Key which will be used as the Parent Key for the system.

Step 1:

The Parent Key is sent to each Manufacturing Module. Each manufacturing site will have its own Manufacturing Module.

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

Step 2:

The unique serial number of the end product Peripheral is sent to the Manufacturing Module.

Step 3:

The Manufacturing Module performs a hash function on the unique serial number and the Parent Key which creates a Derived Key uniquely associated with the end product Peripheral. The Derived Key is loaded into the End Product.

Step 4:

The device which will act as the “Host” in the field needs to have knowledge of the Parent Key.

The Parent Key stored in the Host needs to be protected from being copied or modified.

This completes the provisioning stage done during the time of manufacture.

sa-fig-02.png
FIGURE 2: Authenticating the End Product at Manufacture Time

The Authentication Process (Running in the field)

The next two figures show the run-time authentication process the Host uses to prove that the Peripheral is genuine. All aspects of the authentication process are done through runtime firmware.

Step 1:

The Host must now recreate the Derived Key, which is unique to this Peripheral. The Host requests the unique serial number of the Peripheral and performs a hash function with the Parent Key which creates a Derived Key uniquely associated with the end product Peripheral.

a

Since this is the exact same process done during the time of manufacturing, the Host Derived Key should match the Peripheral Derived Key.

b

Both the Host and the Peripheral now share a secret symmetric key unique to the Peripheral.

Step 2:

The Host generates a "random challenge" which is sent to the Peripheral. Both the Peripheral and the Host perform a Hash function on the random challenge and their own Parent Key

Step 3:

The Host asks for the result from the Peripheral and compares it against the result it generated. If the two results match, then the Peripheral is genuine.

sa-fig-03.png
FIGURE 3: Authenticating the Peripheral

Step 4:

If the Peripheral should only be used a limited number of times, a monotonic counter is decremented each time an authentication occurs. When the counter reaches zero, no more hashing results are produced. The device cannot be authenticated and therefore should be disposed and replaced.

sa-fig-04.png
FIGURE 4: Authenticating the Peripheral for Limited Number of Uses
© 2024 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.