Author Archives: calvinyeung1234

What’s new in Atmel’s ARM MCU? picoPower!!

The SAM4L it is the first ARM device to feature Atmel’s picoPower technology, and takes low power to a new level.   There are many different characteristics that make a low power device; foremost it is the active power, the wake-up time and sleep mode power consumption. For the SAM4L, this can go down to 90 µA/MHz in active, down to 700 nA in sleep mode and down to 1.5 µs wake-up. Additionally the Cortex-M4 and Atmel’s fast flash technology allows your application to spend a shorter amount of time in active and spend more time in low power modes. All of this significantly reduces the total power consumption for your application.

picopower explained

Atmel SAM4L MCUs redefine the power benchmark, delivering the lowest power in both active (90uA/MHz) and sleep
modes (1.5uA with full random access memory (RAM) retention and 700nA in backup mode). They are the most efficient
MCUs available today, achieving up to 28 CoreMark™/mA using the IAR Embedded Workbench, version 6.40.

Check out this video for more information about picoPower in the SAM4L.  Also, please be sure to follow us on this blog to learn more on how these ARM devices become so power conscious and other neat application tutorials.  Or share, collaborate, and innovate with the other tens of thousands of engineers/builders in the vibrant AT91 community.

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

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 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.

Components to a truly secure system

By: James Tomasetta

In today’s increasingly connected world, the need for security is no longer just for communicating over the Internet, but is also needed to ensure that the user’s personal computer is free from malicious code.  In order to secure the user’s local computer, a root of trust  needs to be established, starting from the manufacturer of the hardware and continuing through the firmware and into the installed software.  The key components in securing this root of trust are a fixed or secured boot loader that is inherently trusted by the system and is used to start the authentication sequence, which can be implemented using many existing hardware security chips on the market, such as the ATSHA204 from Atmel.  The second key piece needed is a secure key vault used to store the keys used to sign different pieces of code loaded on the system back to their developers.  Once the code has been verified the boot ROM will start executing code and continue to repeat these steps until the system is fully booted.  Once the root of trust has been established for the system, the user can ensure that none of the code running on the system has been modified. 

secure boot

 

What is the Difference Between Encryption and Authentication?

By: Gunter Fuchs

Not considering how to actually do encryption or authentication, it is fairly simple for a native Latin speaker (http://www.etymonline.com/index.php?term=authentic, http://www.etymonline.com/index.php?term=crypto) to distinguish between the two. We authenticate something to prove to the receiver of the “something” that it actually came from us. We encrypt a message so nobody, including us, can read it. Why do we authenticate or encrypt? We authenticate so that the receiver is assured that what she received came from us and not from an imposter. This “thing” can be an item – a coin or painting for instance, or a piece of information, an email attachment or a speed command to a uranium centrifuge. We encrypt information so that only the intended receiver(s) can understand it.

So that was simple. But why do computer gurus go through great efforts to provide means of information authentication? Wouldn’t encrypting information be enough? Couldn’t the sender just include its name and address in the information and then encrypt? Well, no. The problem is that although a “man in the middle” will not understand the information, he will still be able to change it. For instance, in computer communication protocols a destination address (port) might be at a fixed position in a message. An adversary could copy such a message when it is on its way through some wire, change this value randomly, and monitor its own port/s until one of these messages – though still garbled – arrives. Once the adversary has received one message, he can now inject the encrypted port value for his own port for every message. One message would not be enough for a hacker to perform decryption,  but many makes this possible.  Not only would an adversary then be able to decipher messages that were not meant for her, but she can now also “break the code”, meaning deduce the encryption key. And with that key in hand, she can now send messages that are not authentic.

Therefore, a secure communication consists of authenticating the message and encrypting it.  To learn more about the importance of protecting your trade secrets, check out this white paper.

Weighing the Benefits of Hardware- vs. Software-only Security

By: Steve Jarmusz

I have seen many software programs touting that they have security built into the code.  I don’t think having the algorithm in software is such a bad thing, but having the keys or roots of trust stored in a non-secure, external Flash device or internal non-volatile memory within the MCU is.    I think it leaves the system vulnerable to attacks.  I have learned that software-based security schemes often use the hardware accelerators that are in a MCU or they implement them in software.  We have seen hack shops in Asia that will extract the keys from a binary file for a nominal fee, so that is not secure.  Even if the engineers bought a microcontroller that has crypto accelerators inside, normally the hardware accelerators inside the MCU are not protected from tampering.    In contrast, hardware-based security schemes use a device that has been created specifically to address a particular security need.  Hardware devices usually have secure key storage so that the key cannot be read from the outside nor changed.  The algorithms used by these devices are developed in hardware in a way that is secure and tamper resistant.  Hardware devices usually have built-in protection mechanisms in case they are being attacked either environmentally or physically.  So in your next design, I highly recommend that you spend a little time to research hardware security.

Symmetric vs. Asymmetric Encryption: Which Way is Better?

There are two fundamental ways to use keys or secrets for encryption:symmetric and asymmetric.  Symmetric encryption uses the identical key to both encrypt and decrypt the data.  Symmetric key algorithms are much faster computationally than asymmetric algorithms as the encryption process is less complicated.  The length of the key size is critical for the strength of the security.  NIST has recommendations on how long a key should be– in general, 160-512 bits.   There are inherent challenges with symmetric key encryption in that the key must somehow be managed.  Distributing a shared key is a major security risk.

symmetric encryption

symmetric encryption

Asymmetric encryption uses two related keys (public and private) for data encryption and decryption, and takes away the security risk of key sharing.  The private key is never exposed.  A message that is encrypted by using the public key can only be decrypted by applying the same algorithm and using the matching private key.   Likewise, a message that is encrypted by using the private key can only be decrypted by using the matching public key.

Asymmetric Encryption

Asymmetric Encryption

Are you building out for secure devices to protect your engineering designs and secure any potential hacking in your product? Receive a FREE Atmel CryptoAuthentication development tool?

This blog was written by Steve Jarmusz, Atmel Applications Manager for Crypto, Memory and Analog Devices. 

What’s the price on health? Wireless Hacking is No Joke.

Hackers have extended their reach beyond just computers and phones.  Some are targeting devices that go into a patient’s body, such as pacemakers, or that help administer drugs, such as insulin pumps.  Researchers have successfully demonstrated how a hacker can wirelessly hack into the system and take control.  As a result, a random level of electrical shock can be sent to the heart patient or the wrong dosage of drugs can be injected.  Although the incentive in such a hack is not obvious, who knows what goes on in the mind of a criminal?  Devices with inadequate security are prone to such attacks, and the financial liabilities to the manufacturers can be crippling.  Fortunately, these kinds of breaches can be easily prevented by implementing a hardware-level security device.