A closer look at Atmel’s Trusted Platform Module (TPM)

Last week, Bits & Pieces embarked on a deep dive of the ATECC108 solution, an elliptical curve cryptography (ECC) product. Today, we will be taking a closer look at Atmel’s Trusted Platform Module (TPM), which provides a strong hardware-based public key (RSA) for both personal computers and embedded processors on a single chip.

Essentially, the Trusted Platform Module can best be described as a complete turnkey system that integrates industry-leading Atmel AVR microcontroller architecture, Atmel EEPROM technology and Atmel security technology.

“Implementing version 1.2 of the Trusted Computing Group (TCG) specification for TPMs, the chip delivers intellectual property protection, system integrity, authentication and secure communications,” an Atmel engineering rep told Bits & Pieces.

“Plus, it should probably be noted that the Trusted Platform Module Embedded TWI Development Kit received a 2008 Readers Tech Choice Award from eg3, an independent news source devoted to electronic design.”

In addition, the TPM includes integrated, protected nonvolatile storage for cryptographic keys, secrets and authorization information. As expected, the platform also offers full TCG compliance, boasting a high-quality hardware random number generator, active shielding and a variety of tamper-detection and response circuits.

In terms of performance, the TPM’s cryptographic accelerator is capable of computing a 2048-bit RSA signature in 200ms, with the platform supporting SIRQ for interrupts and CLKRUN to permit clock stopping for power savings in mobile computers. The TPM is also equipped with two interfaces: a 33 MHz LPC interface for PC integration and a dual-wire interface for non-PC and embedded computing systems.

And last, but certainly not least, BIOS and hardware drivers are available for both Windows and Linux, along with third-party system and application software.

Interested in learning more about Atmel’s extensive and versatile security portfolio? Be sure to check out our official security page here .

Atmel MCUs for fire and security

Atmel’s versatile MCUs power a number of fire and security applications – allowing vendors to design advanced systems that effectively safeguard people, property and business resources.

“Atmel offers a wide range of ARM-based AT91SAM and AVR 32-bit microcontrollers for such applications,” an Atmel engineering rep told Bits & Pieces. “More specifically, the SAM3 family and AVR UC3 families support entry-level systems, while advanced controllers with Ethernet connectivity are based on the SAM9 and AVR UC3 families.”

Backup mode and diverse connectivity options include an embedded soft modem, Wi-Fi extension board, Ethernet and RS485 connectivity, with Atmel CryptoAuthentication enabling node authentication and secure communication. Top-level security can be provided by AVR XMEGA hardware AES/DES crypto module and AES/DES bootloaders for megaAVR, tinyAVR and AVR XMEGA.

“It should also be noted that low-power 8-bit microcontrollers minimizes power consumption, with Atmel’s ATmega128RFA1 single-chip, allowing devs to design ZigBee smoke and motion detectors with extremely low power consumption,” the engineering rep continued. “Plus, Atmel’s XMEGA analog delivers optimal performance with 12-bit ADC resolution up to 2Msps with internal gain stage (up to X64), while optimizing BOM by removing its external gain stage.”

So let’s look at some specific example of how Atmel MCUs can be used to power a wide range of fire and security devices:

• Control Panels – The primary point of contact for home and building automation consumers. Atmel’s portfolio supports a wide range of designs, meeting simple or complex needs.
• Detectors – Known as the eyes and ears of fire and security solutions. Our low-power solutions are capable of supporting motion detectors, smoke detectors, sounders and glass break detectors based on the Atmel tinyAVR, megaAVR, AVR XMEGA and MCU Wireless (single-chip microcontroller +RF) families.
• PIR (Camera) Detector – Atmel’s AVR picoPower technology significantly improves detector battery life, delivering the reliability that Passive Infrared (PIR) camera-based detectors require.

“Flexible connectivity is key for home gateway and control panel applications. That is why Atmel’s microcontrollers (MCUs) help vendors achieve a rapid time-to-market by providing validated connectivity via Ethernet, USB, soft modem (PSTN), Wireless LAN and RS-485 interfaces with backup mode,” the engineering rep added. “In the event the main power supply cut off, the control panel can automatically switch to battery operating mode to maintain connectivity.”

Interested in learning more? Additional information about Atmel’s extensive fire and security portfolio can be found here.

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

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.

Achieving a secure lockdown with Atmel’s ATSHA204

Despite its obvious importance, security often takes a backseat when it comes to designing a device or electronic component.

Perhaps one of the most shocking examples of security failure in the electronic world was highlighted last year during the Black Hat conference when a hacker demonstrated how he used a simple microcontroller to compromise hotel room doors by accessing 32-bit keys.

Unfortunately, the above-mentioned breach is hardly an isolated incident, as hacks for poorly secured hardware can be found swirling around the internet ether where they are routinely bought and sold by less-than-savory elements.

While it may seem somewhat daunting, securing a device can be made easier with an optimized authentication chip like Atmel’s ATSHA204 which includes a 4.5Kb EEPROM. This array can be used for the storage of keys, miscellaneous read/write, read-only, password or secret data. As expected, access to various sections of memory can be restricted in a variety of ways, with the configuration locked to prevent changes.

The chip also boasts a number of defensive mechanisms specifically designed to prevent physical attacks on the silicon itself or logical attacks on the data transmitted between the chip and the system. Plus, each ATSHA204 ships with a unique 72-bit serial number. By using the cryptographic protocols supported by the chip, a host system or remote server is able to prove the serial number is authentic and not a copy.

In addition, the ATSHA204 is capable of generating high-quality random numbers and employing them for any purpose, including usage as part of the crypto protocols of the chip. Access to the silicon is granted via a standard I²C interface at speeds up to 1Mb/sec. And last but certainly not least, it is compatible with most UART or serial IO controllers.

So that’s the physical spec rundown, but what about specific attacks ATSHA204 is designed to shield against? Well, the authentication chip is capable of helping to protect devices from a variety of nefarious threats, including algorithmic, protocol, microprobe, environmental, timing, bug, dumpster diving, emissions, fault and power cycling.

Meanwhile, a secure boot system prevents unauthorized modification of host firmware and protects against hackers enabling extra features without payment. And last, but certainly not least, the ATSHA204 helps thwart illicit system copies, piracy and code reverse engineering.

So while securing a device may seem like somewhat of a daunting task, especially in the face of so many critical threats, Atmel’s ATSHA204 is a comprehensive hardware-based solution that offers full applications support for both AVR and ARM systems, while helping to streamline and optimize the lockdown process.

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.

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

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

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.

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

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.