How to program your secrets into a chip with hardware-based security

Written by Nelson Lunsford

Implementing security into your design may seem somewhat daunting and time-/resource-intensive at first glance.  You may be thinking that you don’t have the luxury for it.  Fortunately, Atmel makes it easy when using the turnkey Atmel CryptoAuthentication IC.

At its most basic, the CryptoAuthetication device receives a challenge from a host system and a response is sent back to that host system. That challenge is combined with a secret key stored in the secure memory of the CryptoAuthetication using the MAC command. Then the result or response is sent back to the host system. If the response is correct as determined by the host system, then the operation can proceed.

How does that secret get into the CryptoAuthetication IC in the first place? Well, the CryptoAuthetication device requires that it be personalized or programmed with a known configuration for the application that it is intended to solve. Personalization of the device simply means configuring it to do what you want it to do.

The following methods can be used to place secure information into the CryptoAuthentication device:

1. You can program the IC using the available communications interfaces provided by the IC, namely SWI or TWI.
2. Atmel provides a software package and a hardware kit. This package is the Atmel CryptoAuthentication Evaluation Studio (ACES) and the AT88CK101STK8 or AT88CK109STK8 hardware.
3. Atmel has produced a Secure Personalization or Programmer Kit (combination hardware and software) that can be purchased to program the CryptoAuthentication in greater quantities than the ACES tool.
4. Atmel has approved several 3^rd party programmers that can be purchased program the CryptoAuthentication before deployment.
5. Atmel has also approved several 3^rd party companies that will program the CryptoAuthentication once the secrets have been securely received.
6. Atmel provides a service to their larger customers enabling the CryptoAuthentication to be personalized at final package test.
7. This service is for programming larger numbers of ICs where it is not conducive for you to manage it yourself.

Any of the 6 methods mentioned above will work for placing your specific data into the CryptoAuthentication device in order to protect your IP.

Using the ATSHA204 for Firmware IP Protection

By: Ronnie Thomas

Read almost any major newspaper and you will see companies world-wide that have lost money due to theft of their intellectual property in the form of proprietary software or embedded firmware. The Atmel ATSHA204 CryptoAuthentication device is a great product to protect intellectual property by providing an inexpensive solution to protect software. The ATSHA204 capabilities include challenge-response functionality, diversified key schemes, rolling keys, and other protections to thwart would-be thieves.

Multiple challenge-response pairs

 

In addition, there are other counter-hacker techniques that could be leveraged with the ATSHA204 IC to provide more software theft protection, including:

• Multiple challenge-response pairs

When you use multiple challenge-response pairs, the system will choose a set of challenge/response pairs based on some algorithm in the system code. This could be a function call to the c library rand() or a fibonchi lfsr. The number of challenge/response pairs are limited by the amount of space that a given system has to store the support code and challenge/response pairs. In addition, this scenario could be made more complex by offsetting the where the challenge and its corresponding response or held in memory (i.e. the challenge could be held in array 5, while the response could be held in array 23.

• Chaining challenge-responses

In the chaining Challenge Response Technique, each response from the ATSHA204 can be fed back out as the new challenge. At some point the response would be evaluated and checked that the authentication verified successfully. By not evaluating the response each time the system gets the response from the client, the chain could execute a specified number of rounds without triggering a negative effect. If a hacker were monitoring the bus and failed the authentication check, they would not know which challenge/response was invalid.

• Code Misdirection

Code misdirection is the addition of code in the equation that obfuscates to some degree the code path that is being executed, thereby making it harder for would-be hackers to clone a device.  A function pointer is declared, a check is done with in a local function. Once the answer is received the function pointer is set to null. This makes it harder to de-compile the source code and clone a device. Code misdirection could also be used to point to code that causes severe penalties if the response to a given challenge is incorrect, such as pointing to a infinite loop or code that does something destructive.

• Move the Challenge to TempKey

In this example technique, a challenge could be stored in a reserved 32-byte register. At some point much later, the MAC command could be ran on the stored challenge and the response then could be sent back to the system. In this way it is much harder to pair a given challenge to that response.

• Rolled Key Mechanism

Instead of using a “static” key in the authentication calculation, the rolled key function in the ATSHA204 adds security by changing the key value used in the calculation by combining some offset values and creating a new key. The offset value could be something meaningful like the serial number, time stamp, random number, etc.  This new key would permanently remove the original key. After the key has been changed, there is no way to recover the original key. Instead of the challenge and response being the main source of protection, the keys themselves become that protection.

These are just a few examples of techniques that could be used. The examples could be used in combination with one another or with some other technique not mentioned. The end result should be the same when these measures fail by either:

• Reducing functionality
• Making a device inoperable
• Sending error messages
• Blacklisting the device
• Having code do something unexpected or incorrect
• Some other creative approach

If you are interested in learning more about using the ATSHA204 CryptoAuthentication device to protect against these counter-hacker techniques, please contact one of our security experts at crypto@atmel.com.

Securing Your Design with the Fixed Challenge Authentication Model

By: James Tomasetta

Fixed challenge authentication is an easy way to add security to your product without the added expense of additional hardware to the host or client, interactive testing, or extensive software development.

Fixed Challenge Response

Fixed challenge authentication is the only authentication model that does not require a key or calculation on either the host or client.  With the fixed challenge model the host sends the same challenge every time authentication is needed and the client always responds with the same response.  By ensuring the same challenge and response are used both sides can have a pre-calculated version of the challenge response pair.

The major weakness in this model is that an attacker can monitor the bus and record the challenge/response pair and then use the recording to fool the system into validating a fake device.  This is known as a replay attack and is one of the easiest forms of attacks.  To counter this, the host can have a list of challenge/response pairs and randomly select from the list requiring the attacker to record multiple transactions on the bus prior to fooling the system.

Another key weakness in the system is that the challenge/response pairs need to be stored in memory, making them easy to extract from the host.  One solution to this is to add a hardware authentication device to the host.  Adding a hardware device like the Atmel ATSHA204 CryptoAuthentication IC allows the system to increase the level of security without the need to change any client device already in the field.

Weighing the Benefits of Hardware- vs. Software-only Security

By: Steve Jarmusz

I have seen many software programs touting that they have security built into the code.  I don’t think having the algorithm in software is such a bad thing, but having the keys or roots of trust stored in a non-secure, external Flash device or internal non-volatile memory within the MCU is.    I think it leaves the system vulnerable to attacks.  I have learned that software-based security schemes often use the hardware accelerators that are in a MCU or they implement them in software.  We have seen hack shops in Asia that will extract the keys from a binary file for a nominal fee, so that is not secure.  Even if the engineers bought a microcontroller that has crypto accelerators inside, normally the hardware accelerators inside the MCU are not protected from tampering.    In contrast, hardware-based security schemes use a device that has been created specifically to address a particular security need.  Hardware devices usually have secure key storage so that the key cannot be read from the outside nor changed.  The algorithms used by these devices are developed in hardware in a way that is secure and tamper resistant.  Hardware devices usually have built-in protection mechanisms in case they are being attacked either environmentally or physically.  So in your next design, I highly recommend that you spend a little time to research hardware security.

What’s the price on health? Wireless Hacking is No Joke.

Hackers have extended their reach beyond just computers and phones.  Some are targeting devices that go into a patient’s body, such as pacemakers, or that help administer drugs, such as insulin pumps.  Researchers have successfully demonstrated how a hacker can wirelessly hack into the system and take control.  As a result, a random level of electrical shock can be sent to the heart patient or the wrong dosage of drugs can be injected.  Although the incentive in such a hack is not obvious, who knows what goes on in the mind of a criminal?  Devices with inadequate security are prone to such attacks, and the financial liabilities to the manufacturers can be crippling.  Fortunately, these kinds of breaches can be easily prevented by implementing a hardware-level security device.

Housekeeping? Nope!!! A DIY Breach That Can Be Easily Prevented with Encryption

In an attempt to expose the vulnerability of a hotel room lock manufactured by certain big lock company, a hacker has posted his hack of it online.  There are more than 4 million hotel rooms in the world that could potentially be affected.  And the most disturbing part? It doesn’t take any sophisticated equipment to carry out such a breach: simply an Arduino kit (a mini computer for tinkerers that costs less than $50) and some basic coding skills!  The hacker “found that he could simply read this 32-bit key out of the lock’s memory. No authentication is required”.  It’s a scary incident but also one that can be prevented quite easily. By integrating one of today’s turnkey security chips into the design of the lock, the lock manufacturer can prevent hacking and other security breaches.

Avnet Certified to Program CryptoAuthentication Chips

Avnet Electronics Marketing has been certified as a programming service provider for the Atmel SHA204 CryptoAuthentication high-security authentication devices. For design engineers, this certification means that you’ll be able to more easily pair any microcontroller on the market with our SHA204 chips. This should help you bring your secure, differentiated products to market more quickly.

Atmel SHA204 chips are the first device in the CryptoAuthentication line to integrate the SHA-256 hash algorithm with a 4.5-Kbit EEPROM that can be used for storage of keys, miscellaneous read/write, read-only or secret data, consumption logging and security configuration.