Tag Archives: ECDSA

The CryptoCape is the BeagleBone’s first dedicated security daughterboard


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.

Interested? You can check out the product’s official SparkFun page here. Meanwhile, those looking to learn more should also pick up a copy of Datko’s book entitled “BeagleBone for Secret Agents.” The third chapter of the resource is devoted to the CryptoCape where Makers will learn how to combine a fingerprint sensor, the on-board ATmega328P, and the crypto chips to make a biometric authentication system.

Forward secrecy made real easy


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 launches next-generation CryptoAuthentication device


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_September2014_pg2

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

CryptoSecurityALT_HPBanner_980x352_Final_v_2

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.

Interested in learning more? Discover the latest in hardware-based security here. Meanwhile, you may also want to browse through recent articles on the topic, including “Is the Internet of Things just a toy?,” “Greetings from Digitopia,” “What’s ahead this year for digital insecurity?,” and “Don’t be an ID-IoT.

Is the Internet of Things just a toy?


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.

Picture1

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.

Picture2

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.

IoT Installed

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.

IoT Node Chart 1

The unit shipment slide is what tells the real story. And, that is that security is becoming a requirement of IoT if growth is to be sustainable.  Simply stated: Without real security, the IoT will falter.

BxLpafwIcAAMcG0

Security Maters

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.

lawsuits

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.

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

tamper

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.

Atmel and IoT and Crypto, oh my!

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.

Latest product in Atmel's SmartConnect family, the SAM W25 module

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

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:

  • Higher performance (faster encryption)
  • Lower power
  • Much harder to compromise

Atmel has a new white paper out, Integrating the Internet of Things, Necessary Building Blocks for Broad Market Adoption. Depending on whose numbers you believe, there will be 50 billion IoT edge devices connected by 2020.

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

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.

The new IoT white paper is available for download here.

This post has been republished with permission from SemiWiki.com, where Paul McLellan is a featured blogger. It first appeared there on November 19, 2014.

The ABCs of ECDSA (Part 2)

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

certificate-1

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.

certificate-2

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.

certificate-3

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

certificate

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

certificate-4

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

If you have yet to read the first portion of this article, you can find The ABCs of ECDSA (Part 1) here.

 

 

 

The ABCs of ECDSA (Part 1)

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.

ABCs of ECDSA

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.

TLA

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?”

halt

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 1 is 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.)

filepicker-Gw4aY4VjRsGRCvFqStvm_keep_it_real

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:

  1. Certificate data (made up of the client’s public key + static data + dynamic data)
  2. Signature (made by hashing that certificate data and the signer’s secret key in the chip factory)

Certificate

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.

ECDSA 1

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

Plese read   The ABCs of ECDSA (Part 2: Sign Here) to see how the certificate is built and signed in the chip factory.