Symmetric Authentication with a non-secure MCU – Use Case Example
Authentication
to authenticate; to prove that something is real, true, or genuine.

In terms of system security, authentication is a process where a device provides information to the other to authenticate its identity. Depending on the use-case, there can be one-way authentication as well as two-way (mutual) authentication.

In this use case example, we will authenticate an object using one-way symmetric authentication. One-way symmetric authentication 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.

The object can be any accessory—peripheral, battery, cartridge, etc. 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.

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

The secrecy of the Secret Key is critical to this method. A compromised Secret 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.

Why you may want to use this method?

The Host Microcontroller does not contain a Secret key. Thus, compromise of the Secret Key is minimized. The Peripheral device does contain a hardware CryptoAuthentication™ device to store the Secret Key. This is an example of one-sided hardware protection using symmetric keys.

This method limits the target population and any hack to the one device, not the entire cryptosystem.

Implementation

Method A – If the Host Microcontroller has sufficient memory, the best solution is to calculate unique challenge-and-response sets for each device. These sets should be calculated in a secure production line. The challenge-and-response sets are compiled into the host microcontroller source code.

Method B – If the Host Microcontroller does not have sufficient memory, divide the production in some manner such as by work day, week, or month. This method has the advantages of (1) limiting any compromise to that subset of challenge-and-response sets, and (2) adding more variance and therefore making the ecosystem stronger.

Authentication Steps

Step 1:

The Host Microcontroller sends one of its precompiled challenges to the Peripheral device. The peripheral performs a Hash Function on the challenge and its securely stored Secret Key. This re-creates one of the Intermediate Keys precompiled in Flash.

Step 2:

The Host Microcontroller sends a random challenge to the Peripheral device. The Peripheral device performs a hash function with the random challenge and Intermediate Key.

The Host Microcontroller performs a hash function of the same random challenge and the associated precompiled Intermediate Key.

Step 3:

The result from the Peripheral device and the Host Microcontroller are compared. If the results are equal, the Peripheral device has been authenticated.

The comparison of the results can be performed either on the Host Microcontroller or Peripheral device.

sa-mcu-fig-01.png

You can make the hacking of the devices even more difficult by:

  • Obfuscate the challenge/response. The longer the code, the stronger the defense.
  • Hash state variables with stored challenge set. Use state variables with known values at certain points in the algorithm. Authenticate at these points.
  • Perform the challenge-and-response in multiple areas of the source code. Code them differently to make them more difficult to find. Use different challenge-and-response pairs.
  • Do not return an error message immediately after an authentication failure. Do housekeeping tasks and other non-essential functions before faulting.
  • If possible, randomly challenge. Avoid periodic challenges which can be anticipated.
© 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.