Author Archives: calvinyeung1234

Secure personalization service safeguards your IP

Written by Steve Jarmusz

Afraid of having your IP/firmware stolen?  Don’t want unauthorized accessories in the marketplace taking revenue that’s rightfully yours and potentially damaging your brand equity?  Security concerns are serious and worth addressing, but what if you don’t have the expertise in cryptography or infrastructure?

Well, one turnkey solution that does not require security expertise are Atmel ATSHA204 CryptoAuthentication™ ICs.  Atmel provides a personalization service to customers of CryptoAuthentication products. This personalization service (configuring the CryptoAuthentication device for a specific application) is performed at final package test. Before this service can be performed, Atmel solicits secrets from the customer while never knowing the value of those secrets. The secrets are received from the customer encrypted and stay encrypted until they are requested by the test program at final package test. Because of the transport key mechanism innate to the ATSHA204 silicon, these secrets are even encrypted at the probe tips while they are being placed into the secure memory of the ATSHA204.

How does Atmel protect the secrets solicited from customers? We use a SafeNet Hardware Security Module (HSM), which are ranked #1 in worldwide markets. HSMs provide the highest performing, most secure transaction security solutions for enterprise and government organizations. They are used in banking, military, and other government applications where information security is paramount.

SafeNet, Hardware Safety Module

SafeNet, Hardware Safety Module

Atmel sends customers that are going to use the Secure Personalization Service the public key of a RSA key pair that was generated and stored on the HSM. Atmel also provides a template that represents the CryptoAuthentications memory contents and an encryption utility. Once the customer fills in this template with their specific data, it is encrypted with an AES key generated by the encryption utility. After AES encryption, the AES key is encrypted with the public RSA key and then deleted.

The encryption utility subsequently packages the AES encrypted template with customer secrets, the encrypted AES key and various other non-encrypted data used for data integrity into a file that is sent to Atmel. This file then is placed on the HSM system at locations performing the final ATSHA204 package tests. When the tester has determined that the ATSHA204 has passed all functional and electrical tests, that file is sent into the HSM for decryption. It is here that the secrets are placed into the ATSHA204 device’s secure memory. Both device and the SafeNet HSM are tamper proof. If a physical attack or tamper is detected, all data contents are destroyed.

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 3rd party programmers that can be purchased program the CryptoAuthentication before deployment.
  5. Atmel has also approved several 3rd 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.

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

Hardware Security on Host Side

A Closer Look at Secure Boot and Why It’s Important

By: Gunter Fuchs

Who has not experienced a misbehaving computer due to a  virus? Or, you may have at least seen your virus protection software catching one in the act. One especially nasty type of virus is one that is executed before the anti-virus (AV) software begins its process, because it can then manipulate your AV program in a way that it does not find the virus.

Two main programs are executed before your AV program: the binary input / output system (BIOS) and the operating system (OS). The central processing unit (CPU) executes these two programs as part of the “boot” process. Making this boot process secure can increase the overall security of a system in a big way.  By verifying the authenticity of the code for the OS, a secure boot process prevents any virus from sneaking in and compromising a system before the AV program can take over system security.

To be able to verify the code, it is stored along with a “signature” of it at the time of manufacturing or code update. The signature is the output of a cryptographic hash function. (A hash function is irreversible and “condenses” a big blob of information such as boot code into a quite tiny size, 32 bytes for example.) Its inputs are the code and a secret key, known only to the generator of the signature and the verifying routine inside boot code (BIOS) that gets executed immediately after power-up or system restart. This verifying routine calculates the signature the same way it was calculated before by the host (system at manufacturing plant, online site for updating, etc.), and compares it with the stored signature. Only if the calculated and stored signatures match does the boot process continue. Otherwise, the boot verification routine halts the system.

The paragraph above describes a system where the verification (calculation and key storage) is done in the boot ROM. The picture below shows a system where the calculation and key storage are loaded off into a hardware device (ATSHA204) offered by Atmel. Storing the key in very secure, tamper-safe hardware adds a big obstacle to any hack attempt.

Secure Boot

Secure Boot

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.

secure IP equal protecting your wallet - ensure multiple challenge-response pairs

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:

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.

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!

A Turnkey Security Solution for Accessories Authentication = $$$ in Your Pocket

By: Steve Jarmusz

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.

Atmel CryptoAuthentication Shield

Atmel CryptoAuthentication

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.