Tag Archives: authentication

Why the IoT needs multi-layer security


When it comes to the Internet of Things, you’re only as a strong as your weakest link. 


The notion of security being only as strong as its weakest link is especially true for the Internet of Things. When it comes to connected devices, security must be strong at all layers, closing any possible open doors and windows that an attacker can crawl through. Otherwise, if they can’t get in on ther first floor, they will try another.

Security_SS_147872255

Internet security has been built mainly upon Transport Layer Security, or TLS. TLS provides confidentiality, data integrity and authentication of the communication channel between an Internet user and a secure website. Once a secure communications channel is set up using a TLS method, for example, the other half of the true security equation is needed, namely applications layer security.

To understand this notion, think of logging into your bank account on the web. First, you go to the bank’s website, which will set up a secure channel using TLS. You know TLS is successful when you see the lock symbol and https (“S” for secure) in the browser. Then, you will be brought to a log-in page and prompted to enter your credentials, which is how the bank authenticates your identity, ensuring that you’re not some hacker trying to gain access into an unauthorized account. In this scenario, your password is literally a secret key and the bank has a stored copy of the password which it compares to what you entered. (You may recognize that this is literally symmetric authentication with a secret key, though the key length is very small.) Upon logging in, you are, in fact, operating at the application. This application, of course, being electronic banking.

So, as autonomous IoT nodes spread around the world like smart dust, how do those nodes ensure security? This can essentially be achieved using the same two steps:

  • Set up Transport Layer Security to secure the communications channel using TLS or another methodology to get confidentiality, data integrity and confidentiality in the channel. This channel can be either wired or wireless.
  • Set up Applications Layer Security to safeguard the information that will be sent through the communications channel by using cryptographic procedures. Among proven cryptographic procedures to do so are ECDSA for authentication, ECDH key agreement to create session keys, and encryption/decryption engines (such as AES that use the session keys) for encrypting and decrypting messages. These methods make sure that the data source in the node (e.g. a sensor) is authentic, the data is confidential and has not been tampered with in any degree (integrity).

Un

The reason that multi-layer security, particularly application layer security, is required is that attackers can get into systems at the edge nodes despite a secure channel. Long story short, TLS is not enough.

IoT nodes collect data, typically through some kind of sensor or acting on data via an actuator. A microcontroller controls the operation of the node and a chosen technology like Wi-Fi, Bluetooth and Zigbee provides the communications channel. The reason that application layer security needs to be added to the TLS is that, if an attacker can hack into the communications channel via any range of attacks (Heartbleed, BEAST, CRIME, TIME, BREACH, Lucky 13, RC4 biases, etc.), they can then intercept, read, replace and/or corrupt the sensor/actuator or other node information.

Attack

Unfortunately in the real world, TLS gets breached, making it not sufficient. As a result, true security requires both Transport Layer and Applications Layer Security. Think of it as a secure pipeline with secure data flowing inside. The crypto element — which are an excellent way to establish the Applications Layer Security for the IoT — gets in between the sensor and the MCU to ensure that the data from the sensor has all three pillars of security applied to it: confidentiality, integrity, and authentication (also referred to as “CIA”). CIA at both the transport and application layers is what will make an IoT node entirely secure.

Fortunately, Atmel has an industry-leading portfolio of crypto, connectivity and controller devices that are architected to easily come together to form the foundation of a secure Internet of Things. The company’s wireless devices support a wide spectrum of standards including Wi-Fi, Bluetooth, Bluetooth Low Energy and Personal Area Networks (802.15.4), not to mention feature hardware accelerated Transport Layer Security (TLS) and the strongest link security software available (WPA2 Enterprise).

MCU1

Crypto elements, including CryptoAuthentication and Trusted Platform Modules (TPM) with protected hardware-based key storage, make it easy to provide extremely robust security for IoT edge nodes, hubs, and other “things” without having to be a crypto expert. Built-in crypto engines perform ECDSA for asymmetric authentication and ECDH key agreement to provide session keys to MCUs, including ARM and AVR products that run encryption algorithms.

Why should you care about securing your IoT devices?


In this blog, Zymbit’s Scott Miller reviews some of the security features of Zymbit.Orange, how they work, and more importantly, why they matter.


Internet of Things (IoT) devices are, by nature, light on resources, diverse, widely proliferated and often at the ‘edge’ of the network beyond the control of any network administration; perfect ingredients for digital chaos and anarchy!

11245478_1091243084226194_4187312776059801785_n1

Cloud and big data applications depend on the quality of the data they ingest and key factors in quality are the authenticity, integrity and privacy of data they collect from the edge for the network. For the IoT to get real sustainable traction, the data coming from such edge devices must be “trusted” — from the core silicon all the way to the data services.

Fortunately, the Zymbit platform addresses many of the common security threats found in real world applications, whether using embedded ARM CPUs or Maker development boards. For Raspberry Pi and Arduino developers, Zymbit.Orange IoT motherboard makes it easy for developers to implement applications with secure access to communications interfaces as well as cryptographic services. What’s more, Zymbit.Orange can also be used standalone.

Zymbit-Orange-in-Hand-RPI-Atmel-Wing

In this blog, Zymbit VP of Embedded Scott Miller reviews some of the key security features of Zymbit.Orange, how they work, and more importantly, why they matter.

Who Should Read This Blog?

  • Anyone building IoT devices who is not a security expert, and doesn’t have the time or budget to become one;
  • Anyone who has deployed a connected embedded design;
  • Any Maker using Raspberry Pi or Arduino at the edge of the network… and now needs to add security.

Security Considerations for IoT Edge Devices

Securing IoT devices requires a system architecture that addresses some fundamental needs. Let’s take a look at them:

Data Privacy

Generally speaking, data should be kept private if it is integral to a proprietary process or if it is personal in nature. In each case, the data must be protected from prying eyes using encryption techniques that extend from the publishing source — the IoT edge device — to the cloud and onwards to subscribers. Additionally, the administrator of the data should be able to select who or what is able to subscribe to the data stream.

Data Authentication

Most data transactions/interactions are based upon the assumption that you know that the data really came from the presumed edge device. But how can you be sure? And, how can you be sure that your subscribers are receiving that authentic data?

In order for data to be trusted, it must be proven that it originated from a given edge device at the time that it was reported to have been recorded. Data authentication can be accomplished in many ways, but a digital signature is generally regarded as one of the most secure. One application of a digital signature applied to a timestamped block of data involves computing a one-way hash (e.g. SHA-256) of the timestamped data block and then asymmetrically encrypting the hash using a private key. When the data is received at the cloud, the hash of the data is computed and is compared to the hash that accompanied the data block after it is decrypted using the public key. If the hashes are the same, the data is optionally stored on the Zymbit cloud server along with the signature and transferred to the subscribers in a manner similar to the way the edge device transferred it to the cloud.

IP Protection & Threats from Counterfeits

Counterfeit products have an adverse economic impact on businesses and they also introduce serious vulnerability into enterprise systems. In the industrial sectors there have been numerous examples of ‘black market’ spares and generic devices that have introduced back doors into large scale enterprise systems, so much so that the U.S. Government has its own hotline for reporting such breaches.

Zymbit.Orange employs a number of architectural strategies with the goal of protecting software IP:

  • Isolate embedded services in special purpose hardware (e.g. dedicated embedded CPUs) so that it becomes harder to “hack & crack” an application running on an app CPU:

Security-Orange-Mother-Board-2

  • Some of these embedded services include:
    • Securely transacting data through otherwise unsecured channels:
      • Ethernet
      • Wi-Fi
      • Cellphone modem
      • Low-power radio
    • Interacting with and controlling attached user interfaces
    • Collecting physical data from sensors that are serviced by the embedded services hardware cluster
    • Generic encryption/decryption and data authentication/validation
    • Application image update and application health monitoring
  • These isolated embedded services require valid credentials in order to authenticate the users (e.g. applications running on Arduino or Raspberry Pi) of those services.
  • The special purpose CPUs must have their hard programming paths (e.g. JTAG or SWD) disabled so that the firmware that runs on them cannot be hijacked, replaced or corrupted.
  • Tamper event detection (e.g. attempts to open the case or manipulate the real time clock) — when a tamper event is detected various actions can be taken. Some of these actions might include:
    • Recording the tamper event
    • Deliberately “bricking” the system by erasing critical firmware
    • Erasing critical data which would take the system offline
    • The above actions can be configured by the system administrator
  • Application designers must have the means to encrypt and attach digital signatures for the application images they produce. Image decryption and signature validation are accomplished using the embedded services mentioned above.
  • Software updates can be exclusively disseminated via a secure cloud network utilizing encryption and image authentication.

Malicious Attack Defense

Although we aren’t hearing too much about it yet in the press, malicious attacks will soon be launched on IoT devices in a manner similar to PC viruses and cell phones today. Motivations will range from ‘hackers because they can’ to corporate espionage to cyber terrorism. And the the consequences of such attacks can be much more serious than data loss; many IoT devices interact with the physical world and that can cause bodily harm even loss of life. If you think this is sensationalist then wait until the first examples begin to surface.

The good news is that the serious innovators amongst us are thinking about this and looking for solid and practical solutions. Malicious attacks can be prevented or made very difficult to achieve using the same countermeasures we reviewed earlier in IP protection.

Securing Your Edge Devices – Raspberry Pi and Arduino, Too

We love the accessibility and affordability of open source devices and support the communities that are building amazing applications using Arduino and Raspberry Pi. Yet neither was designed with core security in mind and consequently, before applications can be scaled, their vulnerabilities need to be addressed. So let’s first explain their security shortcomings:

Security Vulnerabilities – Raspberry Pi:

  • No built in cryptographic engine
    • While the Pi can perform encryption in software, overall performance suffers as a result.
  • Removable SD card – no physical security
    • This means that an attacker with direct access to a Raspberry Pi based device can steal and clone the software and data on the card or deliberately corrupt the contents of the card.
  • No secure key store
    • Because the SD card is removable and the SD card is the only means of storing anything on the Pi, shared static keys and private certificates are now completely viewable and modifiable. Even if one chooses to encrypt a data volume for key and certificate storage, the key for decrypting the data volume must be exposed at some point. This fact makes data authentication on the Pi infeasible.
  • Susceptibility to power cycling exploits
    • Because there is frequently no intrusion detection or monitoring, simple repeated power cycling of the device may lead to failure and thus denial of service.
  • Lack of real-time clock
    • Prevents the system from responding properly in case of communications outage.

Security Vulnerabilities – Arduino:

  • No built in cryptographic engine
    • Crypto shields are available for purchase, but packaging Arduino shields tends to be very clumsy and difficult to deploy, not just due to the physical size issues associated with stacking shields but also because the Arduino shield framework suffers from resource bus (SPI/I2C) and GPIO pin allocation issues, so simply stacking a new shield on an Arduino may prove to be impossible when other shields are stacked.
  • No way to validate or secure the Arduino executable image if the debugging/programming interface is available. Even if an Arduino based “thing” had a crypto shield attached, an attacker with direct access could potentially:
    • Corrupt or erase the executable image.
    • Gain access to shared keys stored in RAM or flash.
    • “Patch” in their own code which would allow them to take control of the system.
  • Many Arduinos have very limited amounts of RAM and flash, making it extremely difficult to implement robust, secure communications solutions.

Zymbit has solved these problems for Raspberry Pi and Arduino developers by implementing an isolated security framework on the Zymbit.Orange IoT motherboard.

Adding Security With the Zymbit.Orange IoT Motherboard

At the heart for the Zymbit.Orange architecture is a Secure Services Cluster that isolates edge facing application CPUs from each other and from the outbound network connection. Isolation is achieved using a combination of data security (authenticate and encrypt), power security (turn off the CPU) and physical security (tamper proof and enclosure intrusion detection).

Security Orange Mother Board

We use Atmel silicon for all three aspects of security because their solutions are well thought out, affordable and have good performance characteristics.

Secure Silicon Review

The security services cluster within Zymbit.Orange is comprised of three blocks:

Secure Communications Hub

  • Atmel | SMART SAM E70 – high performance advanced connectivity CPU
  • Primary purpose:
    • Provides secure access to communications and UI interfaces
    • Performs tamper detection
    • Provides secure software updates for applications processors via the Zymbit cloud
  • CPU features:
    • 300MHz Cortex-M7
    • AES encryption engine
    • Low latency TRNG (True Random Number Generator)
    • Integrity Check Monitor (ICM) for generating and comparing digests of certain memory areas

Supervisory MPU

  • Atmel | SMART SAML21J17A – ultra low-power microcontroller unit
  • Primary purpose:
    • Power supervision and monitoring
    • Real-time clock
    • Secure programming and debugging interface for the on-board Arduino Zero application CPU
  • CPU features:
    • 48MHz Cortex-M0+
    • AES encryption engine
    • Low latency True Random Number Generator (TRNG)

Secure Key Generation and Storage

  • Atmel ATECC508
  • Primary purpose:
    • Asymmetric (public key) crypto
    • Digital signature generation/validation
    • Password validation
  • Features:
    • Secure key storage
    • Asymmetric encryption
    • Ephemeral key generation

Using these components, Zymbit.Orange provides a secure interface to all essential services for user applications running on the on-board Arduino Zero and/or Raspberry Pi. The dedicated on-board hardware significantly increases the overall security of these platforms without interfering with user applications. It is just as easy to develop an Arduino or Linux project on Zymbit.Orange from scratch or to adapt an existing application to take advantage of the on-board services because they do not interfere with the application CPU programmability.

SecureAxcess is a secure and encrypted USB token


This cybersecurity solution will keep the bad guys away from your personal information. 


With each week seemingly bringing news of another data breach, it’s no wonder a vast majority of people are gripped by anxiety. Fortunately, one Clearwater, Florida startup has developed a new way to put that uneasiness to rest, by ensuring that their most sensitive information is protected from malicious hacking, phishing, snooping, mining and any other form of cyber crimes. Vir-Sec’s solution? The aptly named SecureAxcess

Steal

The company has created and patented what they are billing as “the world’s first, and only, method of secure communication.” Designed with speed and simplicity in mind, a user plugs the flash drive-like token into the USB port of any computer, enters their password and launches a “browser-less” platform called SecureCommuniquea closed messaging, file transfer and chat application that operates inside of SecureAxcess. This limited distribution tool enables users to send emails and documents, as well as engage in other forms of communication in a secure environment, without the threat of intruders. What’s more, the individual’s data and login page cannot be accessed by anyone other than them, and their token.

“It has the look and feel of a browser, but it’s not one! Browsers are bad for accessing secure data. Most major vulnerabilities and methods of attack come from browsers. Eliminating the browser eliminates that threat,” its creator Chris Murphy explains. “The IP address is constantly shifting and is unique to your token so hackers can’t find where to try and break in. It’s like your front door keeps moving around and you can only find it if you have the correct key.”

SecureAxcess also promises true two-factor authentication, requiring both something physical (their token) and something a user knows (their password) in order to access the confidential data.

“When you physically go to the bank, do you just give a name and password to withdraw cash? Of course not, but then why have we allowed it to be so online? Our token acts like you online, physically showing you are who you say while accessing important data,” Murphy adds.

Steal2

Another nice feature is that the program runs entirely from RAM on the token itself, not the computer. Reason being, hackers can compromise browsers and other installed software quite easily. As for its hardware, the pocket-sized device is based on an Atmel | SMART SAMA5 Cortex-A5 MPU and boasts built-in cryptographic security (AES).

“The best way to secure data is to allow authentication to happen at a secure, off-site location, free from software and browsers. Also you can’t open the token and access the parts. The token is a solid fused piece of plastic that cannot be opened without destroying the data.”

Looking for a peace of mind when it comes to safeguarding your online information? Head over to SecureAxcess’ official Kickstarter page, where Vir-Sec is currently seeking $250,000. 

Hackers can take over robotic arms performing your surgery


Researchers are table to hijack a medical telerobot, raising questions around the security of remote surgery. 


In a scenario that sounds straight out of a Hollywood thriller, researchers at the University of Washington have discovered a flaw in surgical robotic arms that allows them to be easily hacked. The experts were able to take control of a Raven II telerobot through a series of cyber attacks, thereby enabling them to change the speed of the arms of the robot and their orientation, making it impossible for the machines to carry out a procedure as directed.

Telesurgery

The first successful telesurgery took place back in 2001 when a doctor in New York completed a gall bladder surgery of a patient 3,700 miles away in France, and since then, long-distance robotic surgery has taken off. Though robotic surgery has yet to become the industry standard, sales of medical robots are increasing by 20% each year. Meaning, vulnerabilities can certainly wreak havoc on operations should the proper security measures not be implemented.

In the case of Raven II, a remote operator uses two winglike arms to perform complex procedures where otherwise their hands might not be capable. While this experiment was performed in a controlled environment and not on the operating table, it’s apparent that more stringent security measures be taken. Raven II runs on a single PC, and communicates with a control console using a standard communications protocol known as Interoperable Telesurgery Protocol. But rather than take place over a secure private channel, commands are sent over public networks instead — and therein lies the potential risk.

For their study, the team performed various types of cyberattacks to see just how easily the arm could be disrupted. This included changing the commands sent by an operator, modifying signals and even completely taking over the robot. The researchers note that while their test applies only to Raven II, other surgical mechanisms that use similar teleoperation were likely also at risk.

“In hijacking attacks, a malicious entity causes the robot to completely ignore the intentions of a surgeon, and to instead perform some other, potentially harmful actions. Some possible attacks includes both temporary and permanent takeovers of the robot, and depending on the actions executed by the robot after being hijacked, these attacks can be either very discreet or very noticeable,” the team writes.

Since surgery requires the upmost precision, any minor glitch at a critical moment could prove to be deadly for a patient. Subsequently, researchers suggest a number of ways that telesurgery can be more secure, including encrypting data as it’s transferred from surgeon to robot, making the software more sensitive to errors and attempted data changes, and better monitoring of the network status before and during surgery.

“Some of these attacks could have easily been prevented by using well-established and readily-available security mechanisms, including encryption and authentication,” the researchers note.

It’s becoming increasingly clear that embedded system insecurity affects everyone, and not only can these effects of insecurity lead to sensitive financial and medical data theft, but in some cases, could even lead to greater harm or fatality. This is why CryptoAuthentication protection is so paramount. As Atmel resident security expert Bill Boldt explains, “Hardware protection beats software protection every time. That is because software is always subject to bugs, tampering and malware, just as these attacks are proving. Again and again and again.”

Want to learn more? Download the entire paper here.

Keeping consumables real


The most cost-effective and secure way to keep things real is through symmetric authentication without secret storage on the host using a fixed challenge.


With the ever present threat of counterfeiting, having a cost-effective and highly-secure way to ensure that a consumable product is real is a great idea. In fact, there is a proven industry standard approach to apply sophisticated cryptographic engineering and mathematics to fight counterfeiting; namely, crypto elements like the Atmel ATSHA204A device.

Crypto elements can attach to a consumable good, such as the classic example of an ink cartridge, even without being soldered in. The device can be glued directly outside of the product. When the ink or other consumable is inserted into the host system (where the MCU is), the crypto element makes contact and the host is able to communicate with the item to validate whether or not it is real. This is called authentication.

consumable

The most cost-effective yet secure way to authenticate is through symmetric authentication without secret storage on the host using a fixed challenge.

With symmetric authentication, a client and the host run the exact same calculation on each side, and if the client (the consumable) is real, then the results of those calculations (called the “responses”) will match. There is a way to go about using a very inexpensive MCU without running the crypto calculations within the host side’s MCU. That is where the concept of fixed challenge comes into play. The idea of a fixed challenge is that the calculation done for the host is conducted ahead of time, and the challenge/response pair from that calculation is loaded into the host.

The fixed challenge method is ideal when certain considerations are in play, such as the folowing:

  1. Very limited processing power (e.g. low-cost MCU)
  2. Abundance of available memory to easily store challenge-response pairs (e.g. in a smartphone)
  3. Need to get something out quickly or temporarily (e.g. time to market)
  4. Need a very low cost on the host (e.g. can’t afford adding a key storage device)
  5. Desire to not store a secret key in the host

So, how does a fixed challenge work? Like with other challenge-response operations, the process starts with the host controller sending the client a numerical challenge to be used in a calculation to create a response, which then gets compared to a “response” number in the host. What makes this “fixed” is that, because there is no crypto device in the host to generate random numbers (or make digests using hashing algorithms), the challenge cannot be random. That means that the challenges and their corresponding responses must be pre-calculated using the client’s secret key and the challenge and response pair loaded into the memory of the host. This can be looked at as effectively time-shifting the calculations used for authentication.

fixed 1

Let’s look at an example using the ATSHA204A installed in the client.

Step 1: In the factory when the host manufactured challenges are loaded into the host MCU memory together with a response that is calculated by hashing the client’s secret with that challenge.

Step 2: When the consumable is inserted into the host machine out in the field, the host MCU will ask the client (consumable) to prove it is real by sending it the preloaded challenge.

Step 3: The client will then run the hash algorithm on that challenge number using its stored secret key to generate a response, which it sends back to the host.

Step 4: The host will compare the response from the clients with the preloaded response value stored in its memory.

Step 5: If the client is real, the response from the client (which is the hash value based on the secret key and the challenge) will be the same as the response value that was preloaded in the host.

Since each host is loaded with a different challenge/response pair, each product that the host is incorporated into is then unique by definition. Cloning beyond only one copy is impossible; thus, this is a highly-secure and very cost-effective technique as it can be easily implemented with very inexpensive MCUs.

This approach can be used for firmware protection and designs with no secrets in the host (as noted), as well as be implemented with very low-cost MCUs that do not have the processing power to run the hashing algorithms.

The many benefits of fixed challenge authentication:

  • Symmetric authentication is fast
  • No secrets in the host
  • Can use low-cost MCU of host because less computation is needed for a fixed challenge
  • Prevents cloning
  • Protects investments in firmware
  • Enhances safety
  • Protects revenue stream
  • Protects brand image
  • Better control of the supply channel

Atmel crypto element devices — including ATSHA204AATECC108AATECC508A and ATAES132A — implement hardware-based key storage, which is much stronger than software based storage due to 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.

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.