Why Should You Consider Hardware Security on the Host Side?

By: Rocendo Bracamontes

Over the last year, I’ve come across many different applications and systems that require security. The majority of them can be categorized as follows:  accessory authentication, consumables, system anti-cloning and session key exchange.

Since the ATSHA204, the latest Atmel CryptoAuthentication™ device, uses a symmetric algorithm, the system where the security is implemented requires the same key at the host and the client.

To provide the best security, designers are recommended, with few exceptions, to include a “host” chip ATSHA204 that holds the system’s symmetric keys.

The following example illustrates a critical application where the usage of hardware security on the transmitter (host) is crucial to perform a receiver (client) authentication over a network. For example, this applies to smart meters, industrial lighting and sensitive sensor networks.

Without it, the transmitter would have to store the secret keys in Flash and perform the cryptographic functions by software, making the system vulnerable to malicious hacks, and impacting overall system performance.  To learn more about why hardware security is recommended over software security, check out our previous blog post on this topic.

Hardware Security on Host Side

Authenticating Consumable Products — Fakes Kill

By:Tom Moulton

How do you know whether that ink cartridge, air purification filter or medical test strip is really from the vendor on the sticker, or if you bought a cheap knockoff?  From an OEM perspective, how do you know your customers aren’t using those knockoffs, rather than something made or authorized by you? That guessing game can be eliminated with the addition of a simple, inexpensive crypto device in the design of your consumable products. The crypto device can be embedded in the consumable (client). When the consumable is installed or first used in the system (host), it is sent a challenge from the host. This challenge could be a fixed or random value. The host sends the challenge to the client, and the chip in the client calculates the response and sends the response back to the host. Upon receiving the response, the host compares it with the expected response. Only a consumable that provides the expected response can be used in the system. Sounds simple doesn’t it? This type of consumable authentication system is inexpensive and easy to implement.

In fact, a number of other configurations are available in these devices and can make the system even more secure. Some of these include: limiting the usage amount of the consumable attached to the system using a special key which can be used only for a limited number of times or by creating a unique key in the chip which is diversified based on its serial number. The benefit is that if an accessory is compromised, it would not affect other accessories because each accessory has its own unique key. And for the ultimate solution to consumable authentication, put a crypto chip in both the host and the client! The expected response can now be stored in hardware instead of embedding it in the host microprocessor code. This makes the response irretrievable for hackers who are attempting to circumvent the system. Isn’t a company’s reputation more important than the effort it would take to implement a simple solution like this? My suggestion is to only buy consumable products that use this type of hardware authentication solution.  Who knows, some day your life might depend on having the right consumable in a company’s product!

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

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.

4 Different Authentication Models—Which One is Right for You?

By: Rocendo Bracamontes

Atmel’s ATSHA204 CryptoAuthentication™ device  allows four different ways to perform symmetric cryptographic authentication on a system:

• Fixed Challenge Authentication
  • Fixed Challenge Authentication is an easy way to add security to a product without the expense of added hardware to the host, interactive testing, or extensive software development. With Fixed Challenge Authentication, the client requires an ATSHA204 device programmed with secret keys. The host is able to use any number of pre-calculated challenge/response pairs to validate the presence of a valid ATSHA204 on the client side.

• Random Challenge Authentication
  • Random Challenge Authentication improves on the Fixed Challenge method by adding a Random Changing Challenge to each request. This feature enables the system to defend against replay-style attacks.
  •  By adding an ATSHA204 device to the host, the system can generate a Random Challenge for the client on the fly. In addition, by generating the challenge internally with the host’s ATSHA204 device, the response is unknown to the system, allowing the use of an unsecured processor without the threat that an attacker will be able to learn system secrets. This dramatically limits the ability of an unauthorized device from producing the correct response.

• Unique Challenge Authentication
  • Unique Challenge Authentication improves on the Fixed Challenge by adding a Unique Challenge to each request. This authentication feature enables the system to defend against replay-style attacks.
  • By adding an ATSHA204 device to the host, the system can generate a challenge for the client on the fly. This allows a unique challenge to be sent for every validation request.

• Diversified Key Authentication
  • This method includes the unique serial number of each ATSHA204 as part of the Cryptographic Authentication calculation. Diversified Key Authentication enables the host to identify the specific accessory that is trying to authenticate with it. This approach also enables the use of access lists (black lists) by the system.

With so many different options of authentication models, you can select the approach that best fits your design’s requirements, keeping your valuable intellectual property (IP) safe from malicious attacks or cloning.  To learn more about designing with the ATSHA204, including some design tips and tricks, check out this white paper.  Also stay tuned for further deep dives into each these models in the weeks to come.