An accessory could be really anything that works with a host or base system. It could be a power charger, pair of speakers, cable, or as I mentioned, anything. There are number of reasons why you would want to authenticate your accessories, to guard them against cloning and counterfeiting. You may want to protect your brand or company’s reputation. Apple does this with the “MFI” policy that they have initiated. You might want to protect customer safety. Having a cloned surgical instrument or medical device that does not possess the same quality as the authentic product could be risky. There have been a number of cases publicized where the cloned product does not perform as well as the original. A battery in cell phones and portable devices is one that comes to mind. You can get really cheap knockoffs on E-Bay, but they may not last or have the storage capability as the OEM versions. There are a number of authentication schemes that could be used to perform the accessory authentication sequence. The most popular method that we have found is the Random Challenge Response method.
By adding an Atmel ATSHA204 CryptoAuthentication device to the host, the system is able to 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 the system secrets. This dramatically limits the ability of an unauthorized device from producing the correct response. You could also do this without a hardware device on the host, but the downside is less security. Security is also very critical in many other applications. To learn more, check out this white paper on the technology and various use cases.
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.