Tag Archives: MAC

The “Key” to Reality

If we wanted to reduce the definition of authentication to its most Zen-like simplicity, we could say authentication is “keeping things real.” To keep something real you need to have some sort of confirmation of its identity, as confirmation is the key (so to speak).

The equation could be as follows:

Identification + Confirmation = Authentication

Confirming or validating the identity of a document, item, data, etc. is what keeping things real is all about. Some of the “things” that can be authenticated with cryptographic methods are mobile, medical, and consumer accessories; embedded firmware; industrial network nodes; and sensors, among others. Soon IoT and vehicle-to-vehicle communication will join in.

Authentication is far more important than many people realize, especially in our growing hyper-connected world that now links billions of people (and things). In cyber-land, authentication is accomplished by deploying cryptographic keys and algorithms. Keys are fundamental to keeping things real—so that is what we mean by “the key to reality.”

Key real 1

There are two primary types of Authentication: Symmetric and Asymmetric. Atmel offers secure key storage devices for both types. These two important techniques take their names directly from whether the keys on each side (i.e. the host and client sides) are the same or different.

Symmetric Authentication

If the same secret key is used on the client and on the host, then the application is symmetric, just like the name suggests. Both of the symmetric keys must be protected because if either one gets out then the security will be lost. This is perhaps analogous to having two sets of car keys. Meaning, losing either one makes it easy for a thief to drive away with your car. So, the secret keys must stay secret.

Key sym

Symmetric Keys are the Same

The identical keys on the host and client are used in mathematical calculations to test the reality of client devices. A very common mathematical calculation that is used is a hash function based upon a cryptographic algorithm (such as SHA). A hash operation produces a hash value (also called “digest”), which is a number of a specified length that is usually smaller than the numbers used as the inputs. A hash is a one-way operation, which means that the inputs cannot be recreated from the hash value.

With symmetric authentication a typical process is to challenge the client device to be authenticated by sending it a random number. The client then puts the random number challenge and a secret key into the hash algorithm to create a hash value, which is known as the “response.” Each challenge will generate a unique response.

It should be noted that cryptographers call a hash of a random number with a secret key a “Message Authentication Code” or “MAC.” The diagram below illustrates this process. Because the host key is the same on the host and client sides, the exact same calculation can run on the host. Once that happens, the hash values (“MACs”) from each can be compared. If the hash values match, the client is considered to be real. You can see that symmetric authentication is really a simple process, but it is loaded with mathematical elegance. Now let’s look at asymmetric authentication.

Hash Value 1

Hashing a Random Number with a Secret Key


Asymmetric Authentication.

Asymmetric keys are presented in public-private pairs. More specifically, the public and private keys are related to each other via a mathematical algorithm. An example would be the Elliptic Curve Cryptography (or “ECC”) algorithm. Only the private key has to be securely stored. Because the keys are different, asymmetric authentication cannot use the same calculate-and-compare process as symmetric.

Asymmetric requires more complicated techniques such as making digital signatures that are verified for authenticity (this is called “Sign-Verify”). An example of asymmetric authentication using ECC algorithms is Elliptic Curve Digital Signature Algorithm (or “ECDSA”).  A major benefit of the Atmel ATECC108A device is that it can be used to easily implement ECDSA sign-verify. (The steps of ECDSA are very interesting, but they will be covered in a separate article). Note that an important trade-off between symmetric and asymmetric authentication is the speed of operation. For example, authentication time for the Atmel ATSHA204A is 12ms (typical) for symmetric versus more than a second for many microcontrollers to execute an asymmetric ECDSA operation.

Getting back to the keys:   The secret keys must stay secret. If keys are the keys to authentication (i.e. reality),  then secure storage of the secret keys is the key to SECURE authentication. And that is the real point here.

So the, how is secure storage implemented? The best way is to use hardware key storage devices that can withstand attacks that try to read the key(s). Atmel CryptoAuthentication products such as the ATSHA204AATECC108A  and ATAES132 implement hardware-based storage, which is much stronger than software based storage because of the defense mechanisms that only hardware can provide against attacks. Secure storage in hardware beats storage in software every time. Adding secure key storage is an inexpensive, easy, and ultra-secure way to protect firmware, software and hardware products from cloning, counterfeiting, hacking, as well as other malicious threats.

For more details on Atmel CryptoAuthentication products, please view the links above  or the introduction page CryptoAuthentication. Future Bits & Pieces articles will take in an in-depth look at how symmetric and asymmetric authentication is accomplished.         

Process instruments packing Atmel tech

Process instruments employ a variety of sensors and methods to precisely measure process variables, such as temperature, pressure, level and flow.

Clearly, power consumption in active mode is critical for these products, as most field instruments are powered via a 4-20mA current loop interface, which significantly limits power budgets. In addition, process instruments should be capable of operating in hazardous areas.

Atmel’s versatile portfolio of microcontrollers (MCUs) can be used by manufacturers and engineers to design a wide range of industrial process instruments. Perhaps most importantly, our 32-bit microcontrollers are capable of operating down to 1.62V and achieving sub 1mW/DMIPS power consumption figures. In addition, process instruments often operate the microcontroller at low frequencies to reduce power consumption, which is why Atmel optimizes Flash read accesses for such scenarios.

“Both the Atmel AVR 32-bit microcontroller and the Atmel ARM Cortex-M3 processor-based SAM3 family provide modern and efficient RISC architectures, supporting more complex signals. Atmel’s Embedded DSP functionalities (MAC, saturating arithmetic) and FPU, along with middleware libraries to support them, considerably simplify signal conditioning,” an Atmel engineering rep told Bits & Pieces.


“Plus, complex signal algorithms, field bus or industrial Ethernet support, functional safety test routines, and multi-language menus, require increasingly large embedded Flash support. And that is why we offer 32-bit microcontrollers with embedded Flash up to 512KB. Atmel MCUs also integrate dedicated hardware mechanisms to support the implementation of the IEC61508 safety standard.”

In terms of wireless communications, Atmel’s wireless microcontroller lineup provides the required hardware for engineers to build products compatible with the popular Wireless HART protocol. Meanwhile, Atmel’s best-in-class RF properties help increase range and make RF links more robust, yet highly efficient.

“In short, Atmel’s SAM3, SAM7 and the AVR UC3 32-bit families deliver a unique combination of low power and excellent signal processing capabilities, as well as low power consumption, efficient signal processing (DSP and FPU), wide Flash size availability, sensor element and field bus connection, capacitive touch and wireless microcontrollers,” the engineering rep added.

Interested in learning more about Atmel’s process instruments portfolio? Be sure to check out our extensive device breakdown here.

A closer look at Atmel’s AT24CS Serial EEPROM

Yesterday, Bits & Pieces got up close and personal with Atmel’s AT24MAC family which provides a pre-programmed MAC address inside of a serial EEPROM device – without consuming any user memory area.


And today we will be taking a closer look at Atmel’s AT24CS Serial EEPROM. Simply put, practically every application in production today can benefit from or (already) requires a unique identifier or serial number.

“This number allows identification and tracking for multiple purposes including node identity, build control, version control, customer tracking and authenticity check,” an Atmel engineering rep told Bits & Pieces.

“However, building and maintaining an infrastructure to assign and maintain the serialization of products, particularly in high-volume production lines across multiple locations, can be challenging.”

And that’s precisely why Atmel’s AT24CS lineup of devices includes a unique, factory-programmed, read-only 128-bit serial number to help engineers simplify inventory control of mass production lines, all while enhancing product trace-ability.

“The CS family comes in multiple EEPROM array densities from 1Kb through 64Kb,” the Atmel engineering rep continued. “As an application’s needs grow over time and greater memory densities are required, the 128-bit serial number contained within any CS series Serial EEPROM product remains unique, enabling the value to remain distinctive across the entire portfolio of applications.”

As expected, the AT24CS series maintains all of the features that make serial EEPROMs a must-have element in most designs, including one million cycle write endurance, 100-year data retention, byte write capability, along with very low active and standby current consumption. Plus, the read-only serial number is stored in a separate area and does not reduce the user portion of  the memory array.

Interested in learning more about Atmel’s AT24CS and AT24MAC? Be sure to check out our official product page here.

Atmel’s MAC Serial EEPROMs for the IoT

As previously discussed on Bits & Pieces, the Internet of Things (IoT) refers to a future world where all types of electronic devices link to each other via the Internet. Today, it’s estimated that there are nearly 10 billion devices in the world connected to the Internet, a figure expected to triple to nearly 30 billion by 2020.

To be sure, the Internet of Things (IoT) is rapidly transforming products that have traditionally been categorized as stand-alone devices into smart products which are accessible via the Internet or capable of interacting with similar devices on a local network.

In order to successfully operate on the network, each device requires a unique identifying number which is commonly referred to as a MAC address. However, acquiring and maintaining a database of MAC addresses can be very cumbersome indeed. Fortunately, Atmel’s AT24MAC family provides a pre-programmed MAC address inside of a serial EEPROM device – without consuming any user memory area.

“By utilizing AT24MAC devices with globally unique hardware addresses embedded on-board, designers no longer need to absorb the management costs and time associated with acquiring, using and managing an allotment of MAC/EUI addresses,” an Atmel engineering rep told Bits & Pieces.

“The AT24MAC series makes it simpler, faster and less expensive to develop Internet-connected products. As it is based on Atmel’s proven and optimized serial EEPROM technology, the AT24MAC series of products provide the same high levels of endurance and data retention that engineers expect from us.”

It should also be noted that the AT24MAC series maintains byte-write capability and low power consumption. Meaning, engineers don’t have to sacrifice features or performance when adding  MAC address functionality to a design.

Additional key features include a unique pre-programmed MAC/EUI address, permanent and reversible EEPROM write protection, the ability to store and protect vital system data, an entire EEPROM array (available for use), unique serial numbers, pre-programmed true EUI-64 addresses and a pre-programmed, read-only 128-bit serial number.

Interested in learning more? Be sure to check out our official AT24MAC (series) product page here.

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.

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.