The CryptoCape extends the hardware cryptographic abilities of the BeagleBone Black.
With the insecurity of connected devices called into question time and time again, wouldn’t it be nice to take comfort in knowing that your latest IoT gadget was secure? A facet in which many Makers may overlook, Josh Datko recently sought out to find a better way to safeguard those designs, all without hindering the DIY spirit. The result? The CrytpoCape — which initially debuted on SparkFun last year — is a dedicated security daughterboard for the BeagleBone that easily adds encryption and authentication options to a project.
Generally speaking, cryptography offers a solution to a wide-range of problems such as authentication, confidentiality, integrity and non-repudiation, according to Datko. SparkFun notes that the $60 Atmel powered cape adds specialized ICs that perform various cryptographic operations, amplifying a critical hardware security layer to various BeagleBone projects.
The CyrptoCape is packed with hardware, including 256k EEPROM with a defaulted I2C address (plus write protection), a real-time clock (RTC) module, a Trusted Platform Module (TPM) for RSA encryption/decryption, an AES-128 encrypted EEPROM, an ATSHA204 CrypoAuthentication chip that performs SHA-256 and HMAC-25 and an Atmel ATECC108 tasked with the Elliptic Curve Digital Signature Algorithm (ECDSA).
“You will also find an Atmel ATmega328P microcontroller and a large prototyping area available on the board. The ATmega is loaded with the Arduino Pro Mini 3.3V bootloader and has broken out most of the signals to surrounding pads,” its SparkFun page reveals.
Beyond that, each easy-to-use CryptoCape comes with pre-soldered headers making this board ready to be attached to your BeagleBone right out of the box. The only additional item a Maker will need to get the CryptoCape fully-functional is a CR1225 coin-cell battery.
Taking a closer look at how ATECC508A CryptoAuthentication devices can help in providing robust authentication.
Forward secrecy, which is often referred to as Perfect Forward Secrecy (PFS), is essentially the protection of ciphertext with respect to time and changes in security of your cryptographic session keys and/or primary keying material over time.
A cryptographic session key is used to authenticate messages and encrypt text into ciphertext before it is transmitted. This thwarts a “man in the middle” from understanding the message and/or altering that message. These keys are derived from primary keying material. In the case of Public Key Cryptography, this would be the private key.
Unless you are implementing your own security in the application layer, you probably rely on the TLS/SSL in the transport layer.
The Problem
One can envision a scenario in which ciphertext was recorded by an eavesdropper over time. For a variety of reasons out of your control, your session keys and/or primary keying material are eventually discovered and this eavesdropper could decipher all of those recorded transmissions.
Release of your secret keys could be the result of a deliberate act, as with a bribe, a disgruntled employee, or even someone thinking they are “doing the right thing” by exposing your secrets. Or, it could be the result of an unwitting transgression from protocol. Equipment could be decommissioned and disposed of improperly. The hard drives could be recovered using the infamous dumpster dive attack methodology, thus exposing your secrets.
If you rely solely on transport layer security, your security could be challenged knowingly or unknowingly by third parties controlling the servers you communicate with. Recently leaked NSA documents shows powerful government agencies can (and do) record ciphertext. Depending on how clever or influential your snoopers are, they could manipulate the server system against you.
There are many ways your forward security could be compromised at the server level, including server managers unwittingly compromise it due to bad practices, inadequate cipher suites, leaving session keys on the server too long, the use of resumption mechanisms, among countless others.
Let’s just say there are many, many ways the security of your session keys and/or primary keying material could eventually be compromised. It only takes one of them. Nevertheless, the damage is irreversible and the result is the same: Those recorded ciphertext transmissions are now open to unintended parties.
The Solution
You can wipe out much of your liability by simply changing where encryption takes place. If encryption and forward secrecy are addressed in the application layer, session keys will have no relationship with the server, thereby sidestepping server based liabilities.This, of course, does not imply transport layer security should be discarded.
A public/private key system demonstrates the property of forward secrecy if it creates new key pairs for communication sessions. These key pairs are generated on an as-needed basis and are destroyed after a single use. Their generation must be truly random. In fact, they cannot be the result of a deterministic algorithm. Once a session key is derived from the public/private key pair, that key pair must not be reused.
Atmel’s newly-revealed ATECC508A CryptoAuthentication device meets this set of criteria. It has the ability to generate new key pairs using a high quality truly random number generator. Furthermore, the ATECC508A supports ECDH, a method to spawn a cryptographic session key by knowing the public key of the recipient. When these spawned session keys are purposely short-lived, or ephemeral, the process is known as ECDHE.
Using this method, each communication session has its own unique keying material. Any compromise of this material only compromises that one transmission. The secrecy of all other transmissions remains secure.
The Need for Robust Authentication
Before any of the aforementioned instances can occur, the identity of the correspondents needs to be robustly authenticated. Their identities need to be assured without doubt (non-repudiation), because accepting an unknown public key without robust authentication of origin could authorize an attacker as a valid user. Atmel’s ATECC508A provides this required level of authentication and non-repudiation.
Not only is the ATECC508A a cost-effective asymmetric authentication engine available in a tiny package, it is super easy to design in and ultra-secure. Moreover, it offers protective hardware key storage on-board as well a built-in ECC cryptographic block for ECDSA and ECDH(E), a high quality random number generator, a monotonic counter, and unique serial number.
With security at its core, the Atmel CryptoAuthentication lineup is equipped with active defenses, such as an active shield protecting the entire device, tamper monitors and an active power supply circuit which disallows the ability to “listen” for bits changing. The ECC-based solutions offer an external tamper pin, so unauthorized opening of your product can be detected.
Atmel becomes first to ship ultra-secure crypto element enabling smart, connected and secure systems.
Just announced, the Atmel ATECC508A is the first device to integrate ECDH (Elliptic Curve Diffie–Hellman) security protocol — an ultra-secure method to provide key agreement for encryption/decryption, along with ECDSA (Elliptic Curve Digital Signature Algorithm) sign-verify authentication — for the Internet of Things (IoT) market including home automation, industrial networking, accessory and consumable authentication, medical and mobile, among many others.
Atmel’s ATECC508A is the second integrated circuit (IC) in the CryptoAuthentication portfolio with advanced Elliptic Curve Cryptography (ECC) capabilities. With built-in ECDH and ECDSA, this device is ideal for the rapidly growing IoT market by easily providing confidentiality, data integrity and authentication in systems with MCU or MPUs running encryption/decryption algorithms (such as AES) in software. Similar to all Atmel CryptoAuthentication products, the new ATECC508A employs ultra-secure hardware-based cryptographic key storage and cryptographic countermeasures which are more secure than software-based key storage.
This next-generation CryptoAuthentication device is compatible with any microcontroller or microprocessor on the market today including Atmel | SMART and Atmel AVR MCUs and MPUs. As with all CryptoAuthentication devices, the ATECC508A delivers extremely low-power consumption, requires only a single general purpose I/O over a wide voltage range, and available in a tiny form factor, making it ideal for a variety of applications that require longer battery life and flexible form factors.
“As a leader in security, Atmel is committed to delivering innovative secure solutions to the billions of devices to be connected in the IoT market,” explained Rob Valiton, SVP and GM of Atmel’s Automotive, Aerospace and Memory Business Units. “Atmel’s newest CryptoAuthentication IC is the first of its kind to apply hardware-based key storage to provide the full complement of security capabilities, specifically confidentiality, data integrity and authentication. We are excited to continue bringing ultra-secure crypto element solutions to a wide range of applications including IoT, wireless, consumer, medical, industrial, and automotive, among others.”
Key security features of the ATECC508A include:
Optimized key storage and authentication
ECDH operation using stored private key
ECDSA (elliptic-curve digital signature algorithm) sign-verify
Support for X.509 certificate formats
256-bit SHA/HMAC hardware engine
Multilevel RNG using FIPS SP 800-90A DRBG
Guaranteed 72-bit unique ID
I2C and single-wire interfaces
2 to 5.5V operation, 150-nA standby current
10.5-kbit EEPROM for secret and private keys
High-Endurance Monotonic Counters
UDFN, SOIC, and 3-lead contact packages
In the wake of recent incidents, it is becoming increasingly clear that embedded system insecurity impacts everyone and every company. The effects of insecurity may not only be personal, such as theft of sensitive financial and medical data, but a bit more profound on the corporate level. Products can be cloned, software copied, systems tampered with and spied on, and many other things that can lead to revenue loss, increased liability, and diminished brand equity.
Data security is directly linked to how exposed the cryptographic key is to being accessed by unintended parties including hackers and cyber-criminals. The best solution to keeping the “secret key secret” is to lock it in protected hardware devices. That is exactly what this latest iteration of security devices have, are and will continue to do. They are an inexpensive, easy, and ultra-secure way to protect firmware, software, and hardware products from cloning, counterfeiting, hacking, and other malicious threats.
While some sort of IoT is possible without security, without security it would really just be a toy.
The Internet of Things (IoT) is arguably the most hyped concept since the pre-crash dot-com euphoria. You may recall some of the phrases from back then such as “the new economy,” “new paradigm,” “get large or get lost,” “consumer-driven navigation,” “tailored web experience,” “it’s different now,” among countless other media fabrications.
The IoT is the new media darling. In fact, it has been dubbed everything from the fifth wave of computing, to the third wave of the Internet, to the next big thing, to the next mega-trend, to the largest device market in the world, to the biggest efficiency booster/cost reduction technology. You get the picture.
Now, the question is whether or not the IoT will indeed be more real than just hype, as is the case with any media powered feeding frenzy. Let’s start by looking at the numbers.
Respected market researchers and giant networking companies are predicting gigantic numbers of connected devices to the tune of 20 to 50 billion units of installed base by 2020 or 2025, with some estimates even going higher. With numbers like that coming from the world’s most-followed, reputable sources, it won’t be long before high roller investors start placing enormous bets on who will be the winners of the IoT game; a game that will be make Vegas action look like a game of marbles. The IoT casino is now open.
There is really big money at stake because IoT represents a perfect storm of opportunity for venture capitalists and bold corporate acquirers — that is because many believe that half the successful IoT companies don’t even exist yet. Conditions don’t get much more attractive than that when it comes to risk capital.
Here’s a hot tip: Only bet on the companies offering systems that articulate a clear strategy that put strong security (especially authentication) as a top priority. This tip is derived from the observations of Dr. Vint Cerf (the acknowledged creator of the Internet) who declared that the IoT will require strong authentication. And, he’s right. Note well that the strongest authentication comes from hardware-based cryptographic key storage because hardware key storage beats software-based key storage every time. Inexpensive and easy-to-use integrated circuit devices already exist to do just that. The media should grasp that but don’t seem to get it yet.
The dirty little secret of the constantly-connected era is that without security, the IoT will just be a toy that consumers, governments, and corporations cannot take seriously. What good is a system of billions of interconnected things sensing and sending data (often through the cloud) that can be intercepted, corrupted, and spoofed? Not very much. IoT growth is dependent upon security.
Charting the Growth
The graphs below show estimated unit shipments and the resulting installed base of IoT devices. What has also been called out in each chart are devices with on-board security, mainly hardware-based security, and those that do not have built in hardware security. Most market estimates out there tend to show the growth of the IoT in terms of installed bases, growing to many billions by 2020. Typically speaking, you will see a chart like the one below, but without the divisions between secure and insecure nodes.This is a case of the devil being in the details, because installed base charts can be very misleading. Data jockeys such as market researchers and statisticians know very well that installed base is a tricky way to present data. Fair warning: Beware of drawing conclusions from installed base charts only.
The IoT case is a perfect example of how to hide the important information, because even if you remove the secure nodes, the chart still looks like there will be enormous growth. However, that masks the fact that growth will plateau without the secure nodes being a part of the picture. It is a an illusion caused by the fact that the early days of the IoT will build a base of significant numbers, but the volume shipments will fall off quickly as users reject insecure solutions precisely because they are insecure.
The installed base IoT chart is analogous to chart of automobiles in the time of Henry Ford showing the installed base of black cars (remember Model Ts came in any color as long as it was black). That would show that black cars were the overwhelming color and it would be impossible from that chart to conclude anything other than they always would be. Obviously, such a chart would mask the market changes that in fact happened and the inflection points as to when the changes happened. Masking is exactly what the IoT installed base chart does.
It fails to show that the inflection point towards secure nodes that is starting right now, which is a shift that will happen quickly. Reason being, the need for security is becoming clear (just ask Sony, Target, Home Depot, JP Morgan, and Iranian nuclear scientists about that). As aforementioned, inexpensive hardware-based devices are available now that can provide strong security to IoT nodes.
Security matters because users must trust that the nodes are who they say they are (i.e. are authentic). Additionally, confidentiality of the data is important to keep unauthorized third parties from getting the data and misusing it. Also, without data integrity mechanisms there is no way to ensure that the data have not been tampered with or corrupted. All three of these matter. A lot.
However, with all the press that the IoT receives and all the tremendous predictions of giga-volumes, you just don’t hear much other than passing comments about security. Security should, in fact, be the prerequisite of any article, discussion, or plan for IoT-based anything. Talking about the Internet of Things without addressing the security question (with specifics) is like talking about scuba diving without mentioning water.
Security gets short shrift even though it is pivotal to the IoT’s existence (and important to literally everyone in the digital universe, including the readers of this article). One main reason is that the meaning of security is not really well understood. As a result, engineers, executives, investors, and researchers alike have been mainly whistling past the graveyard hoping that their digital interests will not be attacked too badly. However, with the increasing frequency, variety, and creativity of security breaches and especially with the advent of breach-based litigation, the danger is increasing and finally more attention is getting paid. It is not hard to envision ambulance-chaser legal firms moving from class action suits regarding asbestos, medical devices, and pharmaceuticals to seeking data-breach damage rewards. In actuality, this has already started. You can almost hear the cloying ads already.
Security Defined
There are two important and fundamental questions about security and the IoT:
1. What is IoT security?
2. How do you implement it now?
To address the first item, the best way to understand it is to break it down into the three pillars of security, which are confidentiality, data integrity, and authentication (ironically referred to as “CIA”). The second inquiry is related directly to the first because implementing security is a function of how well you address the three pillars.
It is critical to address security right now because putting insecure systems into the world is just asking for trouble. There is no time to wait. Assembling a network or product dependent on a network that is filled with vulnerabilities is bad practice. The good news is that thanks to cryptographic engine integrated circuits with hardware-based secure key storage powerful solutions are clear and present.
Crypto Elements
Crypto element refers to a dedicated integrated circuit devices with crypto engines that handle crypto functions such as hashing, sign-verify (e.g. ECDSA), key agreement (e.g. ECDH), authentication (symmetric or asymmetric), encryption/decryption, message authentication coding (MAC), run crypto algorithms (e.g. elliptic curve cryptography, AES, SHA), and perform many other functions. The other critical part of the equation that makes crypto elements so valuable is their ability to store cryptographic keys in ultra-secure hardware. (The CTO of a major home networking company recently described storing cryptographic keys in software being like storing a key in a wet paper bag.)
Providing the exact type of security needed for the IoT to grow is what crypto engines like CryptoAuthentication solutions are all about. They make security both easy and cost effective. The amazing thing is that crypto engine devices were invented before the IoT even existed. Now they are arguably the ideal catalyst to drive IoT growth when they are added to the other fundamental elements of the IoT. So, it should be clear that there are now four elements to a serious IoT node:
1. Intelligence (Microprocessors)
2. Communications (Wi-Fi, Bluetooth, etc.)
3. Sensors
4. Security
These four items will be the recurring theme of IoT nodes. The story from here will be which communications standards are supported, the level of integration, how security is handled (standards and methods), performance, speed, power, size, etc., not if security is there or not.
Long story short: While some sort of IoT is possible without security, without security it would really just be a toy.
One of the companies that is best positioned to supply components into the Internet of Things (IoT) market is Atmel. For the time being most designs will be done using standard components, not doing massive integration on an SoC targeted at a specific market. The biggest issue in the early stage of market development will be working out what the customer wants and so the big premium will be on getting to market early and iterating fast, not premature cost optimization for a market that might not be big enough to support the design/NRE of a custom design.
Here is Atmel’s latest product in the SmartConnect family, the SAM W25 module
Atmel has microcontrollers, literally over 500 different flavors and in two families, the AVR family and a broad selection of ARM microcontrollers ad processors. They have wireless connectivity. They have strong solutions in security.
Indeed last week at Electronica in Germany they announced the latest product in the SmartConnect family, the SAM W25 module. It is the industry’s first fully-integrated FCC-certified Wi-Fi module with a standalone MCU and hardware security from a single source. The module is tiny, not much larger than a penny. The module includes Atmel’s recently-announced 2.4GHz IEEE 802.11 b/g/n Wi-Fi WINC1500, along with an Atmel | SMART SAM D21 ARM Cortex M0+-based MCU and Atmel’s ATECC108A optimized CryptoAuthentication engine with ultra-secure hardware-based key storage for secure connectivity.
Atmel at Electronica 2014
That last item is a key component for many IoT designs. Security is going to be a big thing and with so many well-publicized breaches of software security, the algorithms, and particularly the keys, are moving quickly into hardware. That component, the ATECC108A, provides state-of-the-art hardware security including a full turnkey Elliptic Curve Digital Signature Algorithm (ECDSA) engine using key sizes of 256 or 283 bits – appropriate for modern security environments without the long computation delay typical of software solutions. Access to the device is through a standard I²C Interface at speeds up to 1Mb/sec. It is compatible with standard Serial EEPROM I²C Interface specifications. Compared to software, the device is:
Edge nodes are becoming integrated into everyone’s life
As it says in the white paper:
On first inspection, the requirements of an IoT edge device appear to be much the same as any other microcontroller (MCU) based development project. You have one or more sensors that are read by an MCU, the data may then be processed locally prior to sending it off to another application or causing another event to occur such as turning on a motor. However, there are decisions to be made regarding how to communicate with these other applications. Wired, wireless, and power line communication (PLC) are the usual options. But, then you have to consider that many IoT devices are going to be battery powered, which means that their power consumption needs to be kept as low as possible to prolong battery life. The complexities deepen when you consider the security implications of a connected device as well. And that’s not just security of data being transferred, but also ensuring your device can’t be cloned and that it does not allow unauthorized applications to run on it.
IoT design requirements: Software / development tools ecosystem
For almost any application, the building blocks for an IoT edge node are the same:
Embedded processing
Sensors
Connectivity
Security
And while not really a “building block,” ultra-low power for always-on applications
My view is that the biggest of these issues will be security. After all, even though Atmel has hundreds of different microcontrollers and microprocessors, there are plenty of other suppliers. Same goes for connectivity solutions. But strong cryptographhic solutions implemented in hardware are much less common.
Part 2 of The ABCs of ECDSA (“Sign-Here”) will describe how digital certificates are made and signed. In the previous article (The ABCs of ECDSA: Part 1), we examined the steps of ECDSA performing asymmetric authentication using digital certificates. You may have noticed that both Part 1 and Part 2 are in reverse chronological order; however, it makes better sense to first understand a bit about the actual authentication process before dissecting the details of making the certificate. (Just trust me on that.) Before we get into the nuances of the certificate, let’s recall that authentication is about keeping something real. Such things would be mobile, medical and consumer accessories; embedded firmware; industrial networks; and soon the new platforms of IoT, home automation, and vehicle-to-vehicle communications. Aside from those, there are several others given the fact that the need for authentication is increasing exponentially as more things communicate with each other, and through the cloud, are creating more opportunities for bad actors to apply their mal-intent.
Especially with the increased use of the Internet and the cloud for financial transactions and transmission of confidential personal/medical information, it’s critical to ensure that the sender of information is exactly who they are supposed to be, as well as that the data has not been tampered with. That is where authentication and hardware key storage come in. Here we will focus on asymmetric authentication. Asymmetric authentication using ECDSA is based upon a digital certificate, which in this case, is stored in the ATECC108A device.
So, now let’s go into the chip factory and see how the ECDSA certificate is made and stored in the device. Remember that ECDSA stands for Elliptic Curve Digital Signature Algorithm. The words “Elliptic Curve” are in the name because Elliptic Curve Cryptography (“ECC”) algorithms are used. No mystery there. The benefit of ECC is that it provides extremely strong security with shorter key lengths than other popular algorithms. Bitcoin, for example uses ECC predominantly for that reason. (We won’t go into Bitcoin here.) “DSA” points to the fact that digital signatures are the key element of the process, which is also fairly self evident. The digital signing process is what we describe here, step by step. “Certificate” is the name given to the concept of putting certain types of data together in a prescribed format and then signing that data using hashing algorithms and signing algorithms. (Again, the usage of the certificate is covered in Part 1.)
While we are fully immersed here in cryptographic alphabet soup, we might as well add one more thing to it: The prescribed format used in the ECDSA in the ATECC108A is called ASN.1. ASN.1 basically defines what is what in the certificate, including the serial number, the public key and that sort of thing. It also defines the length of those data elements.
Now, back to building the certificate: The certificate is made and loaded in the key storage device in the chip factory. It is made from two main components:
1. The certificate data 2. The signature
The certificate data is a collection of data from three sources:
1. Static data: Boiler plate type data that does not change, such as the name and address of the manufacturer. (This is the ASN.1 encoded stuff.)
2. Dynamic data: Data from the tester that can change with each device such as time, date, and serial number.
3. Client device’s public key, which has an algorithmic relationship to the client’s private key that will be securely stored in the client device.
The certificate data is formatted according to X.509 specifications (yes, more crypto jargon). X.509 defines the elements and order of the elements in the certificate, such as serial number, public key, subject’s common name (i.e. the name of the certificate), authority ID (normally a SHA-1 hash of the public key), authority common name (i.e. the name of the authority that signs the certificate data), among other things. We will leave more about X.509 for another day.
The certificate data comprises just half of the certificate, the other half is the signature. What is a little tricky to understand at first is that the certificate data do two things: (1) become part of the certificate as it is, and (2) gets hashed and signed to make the signature. Both the certificate data itself and the signature make up the certificate.
The specific steps in order to make the signature begins with a copy of the certificate data being put through a hash algorithm to create a number called a hash value (or digest). ECDSA specifies a 32 byte digest length and SHA256 as the hashing algorithm. Once created, the digest is ready to be signed by the sign module in the factory.
The sign module is a piece of equipment that securely stores the signer’s private key. No one can get access to that key. The sign module uses the ECC sign algorithm to sign the digest of the certificate data with the signer’s private key. The result of that process becomes the “signature.” The signature then joins the original (i.e. unhashed) certificate data to complete the certificate. Note that the signing key is tied to the OEM’s root key to create the root of trust (the notion of root of trust will be addressed in another article).
The certificate is now finished and can be installed into the crypto device. Once the device is finished, it is then shipped to the customer’s factory to be assembled into an accessory, consumable, board or any number of things, i.e. a consumable water filter that later gets installed into refrigerator. In this scenario, when a new filter is installed by the consumer into the refrigerator when the old filter expires, the new filter will be authenticated by the host processor in the refrigerator according to the ECDSA process as described in The ABCs of ECDSA (Part 1).
Below is a video (sorry, no sound) that will visually help walk you through the steps noted above.
Benefits of asymmetric authentication with ECDSA include:
Increased security because asymmetric authentication does not need secure key storage on the host (only the client)
No need to update the host with secrets in the field (can update the public key at any time.)
Uses the advantages of Elliptic Curve Cryptography (high security, short key, less computation)
Atmel CryptoAuthentication™ products such as Atmel’s ATSHA204A, ATECC108A and ATAES132 implement hardware-based storage, which is much stronger then 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, and other malicious threats.
One of the major difficulties in explaining anything cryptographic, among many other things, is what I call “Acry-phobia” which is fear of cryptographic acronyms. This is a justified condition.
Acryphobia is far from irrational because in cryptography (since it is math) every little thing and the relationships between them must be defined, specified, examined, theorized, tested, formulated, processed, scrutinized, proved, and…. well, you get the picture. Simply stated, this means there’s a whole lot to it. Therefore, in order to teach cryptographic concepts, it’s imperative to focus on a specific area at a time and then break that down further into its fundamentals: That is sort of like breaking down the works of Shakespeare first into episodes, then into Old English then modern English and finally the ABCs. In pretty much similar fashion, that is what we want to do here. Namely, focus on one type of authentication scheme and break it down into its fundamentals and explain those one step at a time.
The specific fear-inducing cryptographic acronym we will try to overcome during this session (and one more after it) is ECDSA, or Elliptic Curve Digital Signature Algorithm.
To quickly dispel some of the Acryphobia, let’s look at authentication from a less mathematical viewpoint.
The basic idea of authentication (just like the name says) is to authenticate, meaning to confirm that the sender of a message is exactly who they say they are. Confirmation is the key to authentication and it requires using some type of trusted credential from another party to verify a declared identity. As noted in an earlier article, this identity confirmation process is sort of like those scenes in old movies where a guard of some type challenges an approacher by saying, “Halt! Who goes there?”
Once challenged, the approacher must respond by identifying himself (or herself) and produce a document (certificate) with the signature or seal of the king, general, or some other trusted authority to confirm that the bearer is not an impostor. That seal or signature links the approacher to a recognized, trusted signer/sealer. The signer/sealer can be described therefore as the certificate authority. (Note that “Certificate Authority” is in fact a technical cryptographic term.)
Cryptographic authentication is just the mathematical version of this challenge-response-certificate-signing-verification process. It uses digital processors, rather than people with bayonets or other weapons of choice.
Getting back to the math, the type of authentication we are discussing in this article is asymmetric, meaning that the secret key is not stored on both the host and client (like with symmetric authentication). Asymmetric authentication stores the secret key on the client side only and then the uses certain mathematical algorithms on certain prescribed information that the client sends it for the ultimate purpose of verifying that the client is real. ECDSA is one of the available types of processes, and what we are going to explore throughout the rest of the article, in a step-by-step fashion. Later on, in an upcoming article, we will address the details about how the crypto devices are originally loaded in the chip factory with the important information needed to make ECDSA authentication happen out in the real world.
So, let’s get into the asymmetric authentication process, which typically begins when a client device is inserted into a host system or the host system wants to know what exactly is connected to it. Examples include a printer ink cartridge being inserted into a printer, a thermostat control block wanting to talk to a remote temperature sensor, a cell phone connecting to a wall charger, among a number of others.
ECDSA (Elliptic Curve Digital Signature Algorithm) is a two-phased process:
Phase 1is to verify that the public key on the client
Phase 2 is to verify the private key on the client.
If both phases pass these two verify calculations then the client is verified as real (i.e. by showing that there is a valid private-public key pair in the client).
(Remember that authentication of any type is meant to keep something real. How the keys are used defines if the process is symmetric or asymmetric.)
The steps of ECDSA are depicted in the diagrams below. In this particular example, the illustrations are based upon a host system that contains a microcontroller and a client (accessory) equipped with an ATECC108A secure key storage device.
Phase 1 starts with the host requesting information to be sent over by the client (accessory). That information comes over to the host as a “certificate.” This certificate is made and then programmed into the crypto device in the chip factory. For now, we’ll start with the already assembled, stored and ready-to-use certificate.
The certificate contains two main things:
Certificate data (made up of the client’s public key + static data + dynamic data)
Signature (made by hashing that certificate data and the signer’s secret key in the chip factory)
When the host receives the certificate, it extracts the certificate data (static data, dynamic data, and client public key) and the signature (made by the signing module in the chip factory). The host runs the same hashing that was used in the chip factory on the certificate data it just received, creating a 32-byte message digest that will be used in the phase one ECDSA calculation. If the client is real, then this hash function run in the host should have the exact same result (digest) as the one that was run the chip factory to create the signature.
On the host, the message digest made from the received certificate data, the signer’s public key, which also came over from the client (more on how that arrives will be in yet another article), and the signature from the certificate are put into the ECDSA verify calculation. If the ECDSA calculation is successful, the client’s public key is considered to be real. That then starts phase 2 to verify the client’s private key.The whole point of this two-phase process is to verify mathematically that the client’s private key and public key are indeed a valid key pair.
The goal of phase two is to verify the client’s private key. This phase begins with the host generating a random number challenge and sending it to the client. The client device uses the ECDSA signature engine in the ATECC108A to create a new signature using this random number and the client’s (secret) private key stored there. That new signature is then sent to back the host, which uses it along with the random number and the client’s public key (that was verified in phase one) as inputs to another ECDSA verify calculation. If that calculation succeeds, the host has then proven that the accessory (client) is real (i.e. contains a valid private-public key pair)
As you can see, the ATECC108A does all the heavy mathematical lifting, and Atmel provides what users need to make it easy to program the microcontroller to do its part of the process. The engineering and mathematics behind authentication using sophisticated algorithms may not be easy in theory, but that does not matter as Atmel makes it simple to implement cryptography without having to be a cryptography expert…. and that is the “REAL” point here.
The video (now with sound) will step you through the two phases of the ECDSA process described above.
So, in summary, the key aspects of asymmetric authentication with ECDSA include:
Increased security because asymmetric authentication does not need secure key storage on the host (only the client)
No need to update the host with secrets in the field. (can update the public key at any time.)
Uses the advantages of Elliptic Curve Cryptography (high security, short key, less computation)
Atmel CryptoAuthentication™ products such as Atmel’s ATSHA204A, ATECC108A and ATAES132 implement hardware-based storage, which is much stronger then 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, and other malicious threats. For more details on Atmel CryptoAuthentication products, head on over to its introduction page here.
HackADay’s Brian Benchoff was lucky enough to catch up with Josh and asked him to break down how the nifty device works.
“If you need to add security to your project or you want to learn more about embedded security the CryptoCape adds encryption and authentication options,” the Maker added.
As its webpage notes, the CryptoCape functions as the BeagleBone’s first dedicated security daughterboard. Known as a BeagleBone Cape, the device attaches to the expansion headers of the BeagleBone and “adds specialized ICs that perform various cryptographic operations which will allow you to add a hardware security layer to your BeagleBone project.”
Previously discussed on Bits & Pieces, the CyrptoCape is packed with hardware, including 256k EEPROM with a defaulted I2C address (plus write protection), a real-time clock (RTC) module, a trusted platform module (TPM) for RSA encryption/decryption, an AES-128 encrypted EEPROM, an Atmel ATSHA204 authentication chip that performs SHA-256 and HMAC-25 and an Atmel ATECC108 that performs the Elliptic Curve Digital Signature Algorithm (ECDSA).
The reasoning behind the developer’s choice to use the SHA-256 Authenticator? “It creates 256-bit keys that can be used in keyed Message Authentication Codes (MACs), or HMAC, to prove the authenticity of the device.” In addition, the authenticator allows the device to “implement an anti-counterfeiting system with the exchange of nonces and MACs between other embedded devices.”
If you are interested in boosting the security of your Maker project or learning more about the CryptoCape, you can head to the product’s official SparkFun page here.
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.”
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.
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.
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 ATSHA204A, ATECC108A 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.
Yesterday we took our first ATECC108 deep dive, exploring various features and capabilities of the device, including firmware protection, anti-counterfeiting and secure data storage. Today, we will take a closer look at the ATECC108’s advanced cryptographic operation.
As previously discussed on Bits & Pieces, Atmel’s ATECC108 implements a complete asymmetric (public/private) key cryptographic signature solution based on Elliptic Curve Cryptography and the ECDSA signature protocol. The device also features hardware acceleration for the NIST standard P256, B283 and K283 binary curves – while supporting the complete key life cycle from high quality private key generation, ECDSA signature generation and public key signature verification.
It should be noted that the hardware accelerator is capable of implementing asymmetric cryptographic operations 10 to 1,000 times faster than software running on standard microprocessors – without the usual high risk of key exposure.
“In addition, the device is designed to be able to securely store multiple private keys along with their public keys and the signature components of the corresponding certificates. The signature verification command can use any stored or external ECC public key,” an Atmel engineering rep told Bits & Pieces.
“Public keys stored within the device can be configured to require validation via a certificate chain to speed up future device authentication, while random private key generation is supported internally within the device to ensure the private key can never be known outside the device. The public key corresponding to a stored private key is always returned when the key is generated and may optionally be computed at a later time.”
Atmel’s ATECC108 also supports a standard hash-based challenge response protocol to simplify programming for developers and engineers. At its most basic, the system sends a challenge to the device, combining it with a secret key via the MAC command and subsequently returning a response. More specifically, the device employs a SHA-256 cryptographic hash algorithm for the combination such that an observer on the bus cannot derive the value of the secret key – although the recipient can verify that the response is correct by performing the same calculation with a stored copy of the key.
“Due to the flexible command set of the ATECC108, these two basic operation sets (ECDSA signatures and SHA-256 challenge-response) can be expanded in many ways,” the engineering rep continued.
“Using the GenDig command, the values in other slots can be included in the response digest or signature, which provides an effective way of proving that a data read really did originate from the device, as opposed to being inserted by a man-in-the-middle attacker. This same command can be used to combine two keys with the challenge, which is useful when there are multiple layers of authentication to be performed.”
Meanwhile, the DeriveKey command implements a key rolling scheme. Depending on the command mode parameter, the resulting operation can be similar to one implemented in a remote-controlled garage door opener. Meaning, each time the key is used, the current value of the key is cryptographically combined with a value specific to that system, and the result forms the key for the next cryptographic operation. So even if an attacker obtains the value of one key, that key will actually be gone forever with the next use.
As expected, the DeriveKey command can also be used to generate new random keys that may be valid only for a particular Host ID, for a specific time period, or for some other restricted environment. Of course, each generated key is different than any other key ever generated on any device. By activating a Host-Client pair in the field in this manner, a clone of a single client will not work on any other Host.
In a Host-Client configuration, where the Host (for instance a mobile phone) is required to verify a client (for instance an OEM battery), there is a need to store the secret in the Host in order to validate the response from the Client. The ATECC108‘s CheckMac command allows the device to securely store the secret in the Host system, concealing the correct response value from the pins by returning only a yes or no answer to the system. Where a user-entered password is required, the CheckMac command also provides a way to both verify the password without exposing it on the communications bus, as well as mapping the password into a stored value with a much higher entropy.
“The hash combination of a challenge and secret key can be kept on the device and XOR’d with the contents of a slot to implement an encrypted Read command, or it can be XOR’d with encrypted input data to implement an encrypted Write command,” the engineering rep added.
“All hashing functions are implemented using the industry-standard SHA-256 secure hash algorithm, which is part of the latest set of high-security cryptographic algorithms recommended by various governments and cryptographic experts. And yes, the SHA-256 algorithm can also be included in a HMAC sequence, with the ATECC108 employing full-sized 256 bit secret keys to prevent any kind of exhaustive attack.”
Atmel | Bits & Pieces 