Tag Archives: key

Symmetric or asymmetric encryption, that is the question!


With the emergence of breaches and vulnerabilities, the need for hardware security has never been so paramount.


Confidentiality — one of the three foundational pillars of security, along with data integrity and authenticity — is created in a digital system via encryption and decryption. Encryption, of course, is scrambling a message in a certain way that only the intended party can descramble (i.e. decrypt) it and read it.

pillars

Throughout time, there have been a number of ways to encrypt and decrypt messages. Encryption was, in fact, used extensively by Julius Caesar, which led to the classic type of encryption aptly named, Caesar Cipher. The ancient Greeks beat Caesar to the punch, however. They used a device called a “Scytale,” which was a ribbon of leather or parchment that was wrapped around a rod of a diameter, of which only the sender and receiver were aware. The message was written on the wrapping and unfurled, then sent to the receiver who wrapped on on the rod of the same diameter in order to read it.

Skytale

 

Modern Encryption

Modern encryption is based on published and vetted digital algorithms, such as Advanced Encryption System (AES), Secure Hashing Algorithms (SHA) and Elliptic Curve Cryptography (ECC), among many others. Given that these algorithms are public and known to everyone, the security must come from something else — that thing is a secret cryptographic “key.” This fundamental principal was articulated in the 19th century by  Auguste Kerckhoffs, a Dutch linguist, cryptographer and professor.

Kerckhoffs’ principle states that a cryptosystem should be secure even if everything about the system, except the key, is public knowledge. In other words: “The key to encryption is the key.” Note that Kirchoffs advocated what is now commonly referred to as “open-source” for the algorithm. Point being, this open-source method is more secure than trying to keep an algorithm itself obscured (sometimes called security by obscurity). Because the algorithms are known, managing the secret keys becomes the most important task of a cryptographer. Now, let’s look at that.

kirchoff 1

Symmetric and Asymmetric

Managing the key during the encryption-decryption process can be done in two basic ways: 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 because the encryption process is less complicated. That’s because there is less processing involved.

The length of the key size directly determines the strength of the security. The longer the key, the more computation it will take to crack the code given a particular algorithm. The table below highlights the NIST guidelines for key length for different algorithms with equivalent security levels.  You can see that Elliptic Curve Cryptography (ECC) is a very compact algorithm. It has a small software footprint, low hardware implementation costs, low bandwidth requirements, and high device performance. That is one of the main reasons that ECC-based asymmetric cryptographic processes, such as ECDSA and  ECDH, are now being widely adopted. The strength of the sophisticated mathematics of ECC are a great ally of all three pillars of security, especially encryption.

table

Not only is symmetric faster and simpler; furthermore, a shorter key length can be used since the keys are never made public as is the case with asymmetric (i.e. Public Key Infrastructure) encryption. The challenge, of course, with symmetric is that the keys must be kept secret on both the sender and receiver sides. So, distributing a shared key to both sides is a major security risk. Mechanisms that maintain the secrecy of the shared key are paramount. One method for doing this is called Symmetric Session Key Exchange.

Asymmetric encryption is different in that it uses two mathematically related keys (a public and private key pair) for data encryption and decryption.  That takes away the security risk of key sharing. However, asymmetric requires much more processing power. Unlike the public key, the private key is never exposed. A message that is encrypted by using a public key can only be decrypted by applying the same algorithm and using the matching private key.

A message that is encrypted by using the private key can only be decrypted by using the matching public key. This is sort of like mathematical magic. Some of the  trade offs of symmetric and asymmetric are summarized below.

Symmetric

  • Keys must be distributed in secret
  • If a key is compromised the attacker can decrypt any message and/or impersonate one of the parties
  • A network requires a large number of keys

Asymmetric

  • Around 1000 times slower than symmetric
  • Vulnerability to a “man-in-the-middle” attack, where the public key is intercepted and altered

Due to the time length associated with asymmetric, many real-world systems utilize combination of the two, where the secret key used in the symmetric encryption is itself encrypted with asymmetric encryption, and sent over an insecure channel.Then, the rest of the data is encrypted using symmetric encryption and sent over the insecure channel in the encrypted format. The receiver gets the asymmetrically encrypted key and decrypts it with his private key. Once the receiver has the symmetric key, it can be used to decrypt the symmetrically encrypted message. This is a type of key exchange.

Note that the man in the middle vulnerability can be easily addressed by employing the other pillar of security; namely authentication. Crypto engine devices with hardware key storage, most notably Atmel’s CrypotoAuthentication, have been designed specifically to address all three pillars of security in an easy to design and cost-effective manner. Ready to secure your next design? Get started here.

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.         

Accessing your vehicle with Atmel

The automotive industry has certainly come a long way since Henry Ford’s Model T first rolled off the assembly line in 1908. To be sure, car (access) keys have radically evolved from the simple, unassuming steel key of yore to acting as the human interface to a vehicle.

Photographed at the Bay State Antique Automobile Club’s July 10, 2005 show at the Endicott Estate in Dedham, MA by Sfoskett

Similarly, Atmel’s automotive portfolio has also rapidly evolved since 1997 when we introduced our very first dedicated car access transmitter.

Indeed, Atmel now offers a wide range of car access devices that are ideal for developing complete system solutions with the highest levels of security and convenience, supporting remote keyless entry, immobilizer, passive entry/go or combi key applications.

“Remember, providing a high level of security is a must for car access applications, something which is also required by insurance companies worldwide,” an Atmel automotive engineering rep told Bits & Pieces.

“And that is why Remote Keyless Entry (RKE) systems combined with immobilizers are standard in nearly all cars today, while passive Entry/Go (PEG) applications offer the ultimate convenience for car users and are well-established in current luxury vehicles.”

Unsurprisingly, such features are increasingly making their way into medium-class cars. To meet these demands, developers require cost-efficient electronic system solutions that support a high level of integration.

As such, Atmel offers a comprehensive line of ICs (RF, LF, Atmel AVR microcontrollers) to create complete car access and remote start systems, along with dedicated RF transmitters, receivers and transceivers, as well as microcontrollers.

atmelcaraccessdiagram1

In addition, Atmel enables a uni-directional RF link for the keyless entry function to open or lock the doors. The immobilizer system is built with a bi-directional LF link operating with the AUT64 crypto algorithm.

And last, but certainly not least, Atmel supports a bi-directional RF link for the RKE function as well as for the extremely secure duplex RF link in a Passive Entry Go system. The lF link is used for the wake- up channel in a PEG system and the immobilizer function to start the RF communication.

atmelcaraccessdiagram2

Interested in learning more about Atmel’s expansive automotive portfolio? Be sure to check out some of our related blog posts from earlier this week, including “A closer look at Atmel’s vehicle portfolio,” “Atmel expands MaXTouch auto lineup,” and “LIN networking for the automotive masses.”

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.

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

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