What can a hardware security chip do for you?

By: Maurice Jackson

When you embark on your next design, you should seriously consider what, in your design, is valuable—and, therefore, vulnerable to security breaches by thieves or hackers.   Make a list, check it twice, and I am certain that the Atmel CryptoAuthentication™ family of high-security hardware authentication devices can help.  The devices offer a flexible command set that allows use for many applications, including the following:

•  Anti-counterfeiting

Validate that a removable, replaceable, or consumable client is authentic. Example clients could be printer ink cartridges, electronic daughter cards, or other spare parts. It can also be used to validate a software/firmware module or memory storage element.

•  Protection for Firmware or Media

Validate code stored in Flash memory at boot to prevent unauthorized modifications (aka secure boot), encrypt downloaded media files, and uniquely encrypt code images to be usable on a single system only.

•  Session Key Exchange

Securely and easily exchange stream encryption keys for use by an encryption/decryption engine in the system microprocessor to manage such things as a confidential communications channel or an encrypted download.

•  Secure Data Storage

Store secret keys for use by crypto accelerators in standard microprocessors. It can also be used to store small quantities of data necessary for configuration, calibration, ePurse value, consumption data, or other secrets. Programmable protection up through encrypted/authenticated reads and writes.

•  User Password Checking

Validate user entered passwords without letting the expected value become known, map simple passwords to complex ones, and securely exchange password values with remote system.

•  Guaranteed Unique Serial Number

Each device has a unique 72-bit serial number.  The device can double as a storage for the unique serial number.

•  High-Quality Random Number Generator

The device includes an internal, high-quality random number generator (RNG).  As such, the device can be used as the source of an RNG.

Diversified Key with Random Challenge Response

By: Gunter Fuchs

Previously, in this space, we briefly discussed the four different authentication models that one can employ in an embedded design. Now, we’d like to take a deeper dive into the nuances of combining a diversified key model with the random challenge response model and the steps it takes in authenticating.

The following are the unique characteristics of this model:

• Each client has a unique serial number and a diversified key that are related by some cryptographic function
• A root key for the cryptographic function is stored on the host
• The hash algorithm is implemented on both the host and client
• A random number generator is required on the host

And the following outlines what is  going on inside the chips during the authentication process:

• The host reads the unique serial number from the client
• The host calculates the diversified key internally using the cryptographic function
• The host generates a random number for use internally and also sends it to the client as the challenge
• Both host and client perform the hash function using the diversified keys
• Host requests the calculated MAC from the client

Host compares the two calculated MACs to authenticate the client. Although complexity of implementing this “hybrid” increases, the benefit that comes with it is the added level of security.  Please stay tuned on this blog to learn more about tips and tricks on how you can secure your design or check out these useful resources on security.

A Deep Dive Into the Unique Challenge Authentication Model

By: Nelson Lunsford

Let’s take a closer look at the unique challenge authentication model, using an Atmel CryptoAuthentication IC, for protecting your design’s intellectual property (IP). At its most basic, the Atmel ATSHA204 CryptoAuthentication IC 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 ATSHA204 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. What if a malicious entity (a hacker) had been monitoring the bus where the host and the client are exchanging the challenge and the subsequent response? If the challenge was the same value, then the response would be the same every time and the hacker would know that response without ever knowing the embedded secret in the ATSHA204 device. This would enable the use of a knock off product even when a company took steps to prevent it.

One simple solution to this specific problem would be to prevent the hacker from having prior knowledge of what the response is. If the challenge was different every time it is sent to the ATSHA204 IC, then the response would be different every time. A unique challenge does exactly that. Even if the hacker has a list of challenges and associated responses, they will not have the correct response or it will take too long to find it in a pre-compiled list.  A unique challenge is a perfect method for defending a system against replay-style attacks. If you are using a hardware security device on the host side, you would use the random number generator (RNG) within the hardware to generate the challenge, thus making the response completely random. However, many embedded systems do not have a high-quality RNG. An alternative to an RNG would be simply to use the date and the time of day combined. If a time of day is not available in the system, then a counter could be used. A counter with the combination of the serial number of the client device can be used. A counter does not have to increment by ‘1’; some multiplier function could be used instead.

Random Challenge / Response Authentication in Plain English

By: Gunter Fuchs

Working deep down in the guts (bits and bytes) of a computer, it becomes hard to explain concepts, once the electronic world has taken them over. I wondered about a simple way to explain authentication without referring to the world of computers, so that someone who isn’t savvy with technology can readily understand it.  Well, there is an authentication scenario in one’s modern day-to-day affairs that does not involve any computer (except if you consider the human brain to be one). This scenario is plain and simple: putting a signature on a piece of paper.

How can we describe a signing process in system security terms for authentication? Specifically, what has putting one’s signature on a contract or bill to do with “challenge / response authentication”? The analogy is quite simple. The challenge is the request by – say – the cashier to sign the bill. The response is your signature. That way, you prove that you are the person who owns the credit card. The cashier authenticates your signature by comparing it with the one on your credit card. In computer security terms, that means that the host (cashier) compares a stored response (your signature on the credit card) with the actual response (your signature on the bill). If the host (cashier) comes to the conclusion that both signatures are equal, it accepts the generator of the response as being authentic.

This scenario is quite insecure because someone can easily forge a signature. The reason in cryptographic terms is because this system can generate only one challenge / response pair. An adversary knows what the challenge will be, and if she has seen / copied the response (signature) only once, she can, after some practice, reproduce it relatively fast and easily. A way to improve the security in such a system is to increase the number of possible challenge / response pairs. An example in the online world is a list of question / answer pairs. Sometimes when you log in, a question pops up asking the name of your favorite pet, teacher, or band. Only you and the online host know the correct answer. Such a list increases the security of a system, but since this list is usually short, finding out the few answers by eaves-dropping is not a huge obstacle for an adversary. The advantage of such a short list of challenge / response pairs is that a human brain can manage it. But in a system where only computers play with each other, we can introduce much bigger lists. They are nowadays pairs  as big as 2^32. In such a system, with a huge number of challenge / response pairs, the host chooses one randomly. An adversary would now have to replicate this huge table, and once it has done that, search through this table for the challenge to find the correct response. Well, you could argue, why not? And how can an authentic client find the correct response in a feasible time? This issue is solved by introducing a cryptographic algorithm and a key into the system. By using a key and an algorithm, tables of challenge / response pairs don’t have to be generated and stored, but a host only has to generate a random number to “choose” a challenge. When the client receives this random number as a challenge, it combines it with a key using a cryptographic algorithm and sends the result back to the host (response). (The cryptographic algorithm “hides” the key so that an adversary cannot extract it from the response.) The host now performs the same calculation using the same key and compares the received response with its calculated one. If the two match—voila!—the host finds the client to be authentic.

With a system that incorporates the process of random challenge / response authentication, an adversary would have to monitor many, many (depending on the biggest number – “number space” – used in this system) authentication sequences between host and client and store them in a table. And after that, it would have to find the challenge in this table to come up with the correct response if it wants to pretend to be the authentic client. Finding it would practically take eternities, “would be infeasible” in cryptographic terms. The quality of the randomness of the random number is important, because the better the quality of the random number generator the less an adversary can predict the next challenge. If an adversary could predict the next challenge, he could search his table in advance.

random challenge response, cryptographic algorithm