Tag Archives: MPU

Profile of an IoT processor for the industrial and consumer markets


 If there’s a single major stumbling block that is hindering the IoT take-off at the larger industrial scale, it’s security.


The intersection of data with intelligent machines is creating new possibilities in industrial automation, and this new frontier is now being increasingly known as the Industrial Internet of Things (IIoT). However, if there is a single major stumbling block that is hindering the IoT take-off at the larger industrial scale, it’s security.

It’s imperative to have reliable data in the industrial automation environment, and here, the additional security layers in the IoT hardware often lead to compromises in performance. Then, there is counterfeiting of products and application software, which is becoming a growing concern in the rapidly expanding IoT market.

sama5d2_google_1160x805_090215

Atmel’s answer to security concerns in the IIoT infrastructure: a microprocessor (MPU) that can deliver the security while maintaining the level of performance that Internet-connected systems require. The company’s Cortex A5 chip — the Atmel | SMART SAMA5D4 — securely stores and transfers data, as well as safeguards software assets to prevent cloning of IoT applications.

The SAMA5D4 series of MPUs enables on-the-fly encryption and decryption of software code from the external DRAM. Moreover, it boasts security features such as secure boot, tamper detection pins and safe erasure of security-critical data. The A5D4 processor also incorporates ARM’s system-wide security approach, TrustZone, which is used to secure peripherals such as memory and crypto blocks. TrustZone —comprising of security extensions that can be implemented in a number of ARM cores — is tightly integrated into ARM’s Cortex-A processors. It runs the processor in two different modes: First, a secure environment executes critical security and safety software, and secondly, a normal environment runs the rich OS software applications such as Linux. This lets embedded designers isolate critical software from OS software.

The system approach allows control access to CPU, memories, DMA and peripherals with programmable secure regions. That, in turn, ensures that on-chip parts like CPU and off-chip parts like peripherals are protected from software attacks.

Trust

Performance Uplift

The Atmel SMART | SAMA5D4 processor is based on the Cortex-A5, the smallest and simplest of the Cortex-A series cores that support the 32-bit ARMv7 instruction set. It’s targeted at applications requiring high-precision computing and fast signal processing — that includes industrial and consumer applications such as control panels, communication gateways and imaging terminals.

The use cases for SAMA5D4 span from kiosks, vending machines and barcode scanners, to smart grid, communications gateways and control panels for security, home automation, thermostats, etc. Atmel’s MPU features peripherals for connectivity and user interface applications. For instance, it offers a TFT LCD controller for human-machine interface (HMI) and control panel applications and a dual Ethernet MAC for networking and gateway solutions.

Apart from providing high-grade security, SAMA5D4 adds two other crucial features to address the limitations of its predecessor, SAMA5D3 processor. First, it uplifts performance through ARM’s NEON DSP engine and 128kB L2 cache. The NEON DSP with 128-bit single instruction, multiple data (SIMD) architecture accelerates signal processing for more effective handling of multimedia and graphics. Likewise, L2 cache enhances data processing capability for imaging applications.

The second prominent feature of the SAMA5D4 is video playback that boasts 720p resolution hardware video decoder with post-image processing capability. Atmel’s embedded processor offers video playback for H.264, VP8 and MPEG4 formats at 30fps.

A Quick Overview of the SAMA5D4

The SAMA5D4 processor, which got a 14 percent performance boost from its predecessor MPU, increasing operating speed to 528 MHz, is a testament of the changing microprocessor market in the IoT arena. Atmel’s microprocessor for IoT markets delivers 840 DMIPS that can facilitate imaging-centric applications hungry for processing power. Aside from that, the SAMA5D4 is equipped with a 32-bit wide DDR controller running up to 176 MHz, which can deliver up to 1408MB/s of bandwidth. That’s a critical element for high-speed peripherals common in the industrial environments where microprocessors are required to process large amounts of data.

sama5d4-block-diagram_734x612_large

Finally, the SAMA5D4 is configurable in either a 16- or 32-bit bus interface allowing developers a trade-off between performance and memory cost. There are four distinct chips in the SAMA5D4 family: SAMA5D41 (16-bit DDR), SAMA5D42 (32-bit DDR), SAMA5D43 (16-bit DDR along with H.264 video decoder)and SAMA5D44 (32-bit DDR along with H.264 video decoder).

The SoC-specific hardware security and embedded vision capabilities are a stark reminder of specific requirements of different facets of IoT, in this case, industrial and consumers markets. And Atmel’s specific focus on security and rich media just shows how the semiconductor industry is getting around the key IoT stumbling blocks.


Majeed Ahmad is the author of books Smartphone: Mobile Revolution at the Crossroads of Communications, Computing and Consumer Electronics and The Next Web of 50 Billion Devices: Mobile Internet’s Past, Present and Future.

IAR Systems provides tools for new Atmel | SMART SAMA5D2 series


IAR Embedded Workbench supports latest series of Atmel | SMART ARM Cortex-A5-based microprocessors with low power consumption and advanced security features.


Our friends over at IAR Systems have shared that the IAR Embedded Workbench for ARM now supports the Atmel | SMART SAMA5D2 series. With its highly optimizing build tools and comprehensive debugging capabilities, their popular development toolchain enables developers to fully leverage the high performance of the recently revealed MPU family.

template-monitor-b-perspective-micrum

The Atmel | SMART SAMA5D2 is based on the high-end ARM Cortex-A5 core and features an ARM NEON engine. ARM NEON is a Single Instruction Multiple Data (SIMD) architecture extension providing the top performance that is crucial to developers working for example with multimedia and signal processing applications. With the IAR Embedded Workbench for ARM, users will be able to benefit from this technology thanks to the automatic NEON vectorization available in the tools. By vectorizing their code, they can achieve faster application response time, improve application battery lifetime and further meet the market demands for low cost and low power.

What’s more, the SAMA5D2 boasts a robust security system including ARM TrustZone technology, along with secure boot, hardware cryptography, RSA/ECC, on-the-fly encryption/decryption on DDR and QSPI memories, tamper resistance, memory scrambling, independent watchdog, temperature, voltage and frequency monitoring and a unique ID in each device.

sama5d2_google_1160x805_090215

The complete development toolchain IAR Embedded Workbench for ARM features the powerful IAR C/C++ Compiler and the comprehensive C-SPY Debugger in a user-friendly integrated development environment. The toolchain offers extensive debugging and profiling possibilities such as complex code and data breakpoints, runtime stack analysis, call stack visualization, code coverage analysis and integrated monitoring of power consumption. For complete code control, IAR Systems provides integrated add-on tools for static and runtime analysis.

“We are excited to see early support for our latest low-power MPUs in IAR Systems’ leading development toolchain,” explains Jacko Wilbrink, Atmel Senior Director of MPUs. “In order to be able to develop next-generation industrial IoT and wearables applications, developers require more performance, lower power and additional security. The Atmel | SMART SAMA5D2 series and IAR Embedded Workbench deliver excellent performance and a wide range of features to fulfill these requirements and deliver truly differentiating products to help bring products faster to market.”

flowchart-componentsconverted2

Interested? You can head over to the IAR Embedded Workbench for ARM, as well as read up on the industry’s lowest power Cortex-A5-based MPU here.

Introducing the all-new Atmel | SMART SAMA5D2 series


The latest Atmel | SMART ARM Cortex-A5-based MPU is pushing the boundaries of performance and power for industrial IoT and wearable applications.


Exciting news — a new family of Atmel | SMART ARM Cortex-A5-based microprocessors have arrived! These MPUs deliver sub 200µA in retention mode with context preserved, 30µs ultra-fast wake-up and a new backup mode with DDR in self-refresh at only 50µA. The Atmel | SMART SAMA5D2 series provides great system integration with the addition of a complete audio subsystem, lower pin-count and ultra-small package for space constraints applications, and built-in PCI-level security targeting industrial Internet of Things, wearables and point of sale applications.

SAMA5D2_Google+_1160x805_090215

Expanding the Atmel SAMA5 family, the SAMA5D2 offers just the right price-to-performance ratio for applications requiring an entry-level MPU and extended industrial temperature range (-40 to 105°C ambient temperature). These MPUs are also a great migration path for designers using ARM926-based MPUs looking for higher performance and additional features including low power, higher security, DDR3 support, smaller footprint, audio, USB HSIC and Atmel’s patented SleepWalking technology.

“As a leader in ultra-low power MCU and MPU IoT solutions, we are excited to launch the new Atmel | SMART SAMA5D2 series for designers requiring a general, entry-level MPU,” explained Jacko Wilbrink, Atmel Senior Director of MPUs. “Designers for industrial IoT, wearables and POS applications are demanding more performance, lower power, smaller form factors and additional security for their next-generation applications. The Atmel SAMA5D2 is well positioned for these demanding requirements, delivering the world’s lowest power MPU, along with low-system cost and PCI level security.”

SAM

Featuring an ARM NEON engine, the new SAMA5D2 boasts 500MHz and 166MHz of system clocking. The memory system includes a configurable 16- or 32-bit DDR interface controller, 16-bit external bus interface (EBI), QSPI Flash interface, ROM with secure and non-secure boot solution, 128kB of SRAM plus 128kB of L2Cache configurable as SRAM extension. The user interface system for the SAMA5D2 is comprised of a 24-bit TFT LCD controller, an audio subsystem with fractional PLL, multiple I2S and SSC/TDM channels, a stereo class D amplifier, as well as digital microphone support.

The robust security system in the new SAMA5D2 is even equipped with the ARM TrustZone technology, along with secure boot, hardware cryptography, RSA/ECC, on-the-fly encryption/decryption on DDR and QSPI memories, tamper resistance, memory scrambling, independent watchdog, temperature, voltage and frequency monitoring and a unique ID in each device.

Ult

To support the SAMA5D2 MPUs, a free Linux distribution has been developed and published in the mainline kernel. For non-operating system users, Atmel delivers more than 40 peripheral drivers in C. Moreover, the company also collaborates with a global network of partners, including IAR, ARM, Free Electrons, Active-Semi, Micron, ISSI, Winbond, Segger, Lauterbach, FreeRTOS, Express Logic, NuttX and Sequitur Labs, that provide development tools, PMIC, memories and software solutions.

Interested? The SAMA5 Xplained Ultra kit is currently available for just $79. The board packs an embedded debugger and programmer and a wide range of compatible extensions boards. Standalone programmer debugger solutions supporting the SAMA5 family are available, too. Early samples of the SAMA5D2 are now ready, while those wishing for an ATSAMA5D2-XULT Xplained Ultra boards will have to wait until October. First production quantities of the SAMA5D2 series will ship in December 2015.

element14 debuts new Atmel SAMA5D4 Xplained board


The latest Atmel | SMART development kit features video decoder and advanced security features.


element14 has debuted the Atmel | SMART SAMA5D4-XUL Xplained board, featuring an ARM Cortex-A5 microprocessor. The newly-announced development kit enables users to evaluate, prototype and create high performance, application-specific designs. The SAMA5D4 Xplained Ultra is packed with 4Gb DDR2 external memory, one Ethernet physical layer transceiver, two SD/MMC interfaces, two host USB ports and one device USB port, one 24-bit RGB LCD and HDMI interface and debug interfaces.

60d37bec6b8da5029546c79a70c60635

The 720p video decoder and playback at 30fps alongside the LCD controller with graphics accelerator are targeted for consumer and industrial designs, including terminals and Internet of Things (IoT) applications. In addition, the SAMA5D4-XULT leverages the advanced security features found on the board’s microprocessor, like ARM Trust Zone, secure boot, encrypted DDR bus, tamper detection pins and secure data storage.

Seven headers, compatible with both the Arduino Uno and Due and two Xplained headers are available for various shield connections.

“Our partnership with Atmel continues to grow with the latest addition to the Atmel Xplained family of development kits,” explained David Shen, Premier Farnell Group CTO. “The comprehensive security features and display capabilities of the SAMA5D4-XULT are key to the advancement and implementation of IoT applications where the user interface and security information are critical.”

SAMA4d

As we’ve previously discussed on Bits & Pieces, the SAMA5D4 is optimized for control panel/HMI applications requiring video playback and is well suited for other use cases that require high levels of connectivity in the industrial and consumer Internet of Things market. The new ARM-based series is a high-performance, power-efficient Cortex-A5 MPU capable of running up to 528 MHz. Furthermore, the device integrates the ARM NEON SIMD engine for accelerated signal processing, multimedia and graphics as well as a 128 KB L2-Cache for high system performance.

The SAMA5D4 Xplained – priced at $93.50 – is now available and can be found on the element14 Design Center. Those interested in learning more can also head over to the development kit’s official page here.

Kaivan Karimi talks IoT building blocks with Design World

While ARM TechCon 2014 may be a thing of the past, product releases, discussions and trends from the show floor continue to make their way forward. Case in point, Design World’s Aimee Kalnoskas recently sat down with our very own Kaivan Karimi to discuss the building blocks of the ever-growing Internet of Things in a candid post-TechCon interview. During the conversation, the Atmel VP and GM of Wireless Solutions shares his insights and adds flavor and some color to this ‘thing’ commonly referred to as IoT.  You can read the entire interview — which was brought to our attention by our friends at ARM and whose original article can be found here — in its entirety below.

AK: What do you think the IoT infrastructure looks like? How does it compare to the current communications infrastructure?

KKThe first thing we must do is to define the IoT industry infrastructure properly – what kinds of devices are connected and how are they connected. We then define the infrastructure of IoT services to determine what the weak points within this infrastructure and how do we resolve them.

First, let us define the weak points. For a while, the cellular operators where the ones claiming that IoT was all about cellular “telemetry-like” services. In IoT, most “things” will be battery operated, requiring long battery lives. But if you assume a cellphone tower is making the connections through an LTE modem with less than two days of battery life, then you can see why edge nodes of IoT have practically nothing to do with cellular. Additionally, IoT is all about secure low data rate command- and control- type of communications, but cellular generally is not. The fact is that by the time IoT services role out, cellular pipes will only carry about five to 10 percent of the WAN traffic. There are many reasons why cellular is the wrong pipe.

IoT communications infrastructure would be based on a “smart” box inside of the home or premise –hierarchical gateways – but not the access points of today. Today’s access points only switch, route and collect information upstream or retrieve it from downstream. For IoT, there will be a new generation of smart gateways that will have intelligence on board to process the information, make decisions, and disperse that information. This “smart gateway” functionality could be an add-on to the existing access points or set-top boxes, or could be a standalone box, but the bottom line is that the “intelligence” will move to the customer premises versus only in the cloud today.

A smart gateway accesses the cloud using various WAN communication technologies, which would be different than BAN/PAN/LAN connectivity technologies used inside the home or on premise. Due to the variety of end segments IoT covers, the smart gateway can be installed anywhere, depending on the use case and application within a given IoT segment.

For example in a smart-highway use case, the gateway is inside a shiny cabinet on the side of a bridge, communicating with tiny seismic sensors (microphones) positioned on the bridge. In the Western world, we have an aging infrastructure, with multiple incidents of collapsing bridges in the past few years. Each of these inexpensive seismic sensors can generate a ping every 30 seconds measuring the integrity of the bridge every 30 minutes or so, and ensure against future bridge collapses.

In this case, communication from the sensor to the gateway or the box is short-range. That can be one of the many 802.15.4 (mesh) technologies such as ZigBee, 6LowPAN, Wireless Hart, etc. Communication through the gateway to the cloud, on the other hand, is WAN connectivity such as Fiber/Ethernet through local networks, cellular, satellite, PLM/PLC, or the next generation of IoT pipes in sub-GHz bands such as SigFox, Weightless, etc.

AK: What’s the role of the smart gateway with regards to provisioning a service?

KK: Think about how you create value as a service provider. It’s this idea of service provision. You need to be concerned not only about connecting the widget but the service delivery frameworks that sit on top of that connection and manage the overall system ensuring quality of service, as well as security of the service.

Smart gateways are key drivers for IoT communications. For instance, a smart gateway in a home could involve communication between thermostats to the gateway box but there is little value in simply connecting these widgets. You need to create a tangible value – the box needs to provision the IoT service. Also note that not everyone is technology savvy enough to program these connections….something we usually lose sight of in Silicon Valley. It needs to become foolproof so that a non-techy can use it just as easily. Again, service providers will play a key role in that.

There is a belief that the IoT edge nodes will generate massive amounts of data and this will all go to the cloud, so you need a lot of bandwidth, a lot of storage space, and data management in the cloud. This is a big fallacy advertised by the people who make money from big bandwidth or cloud storage.

Let’s illustrate what we mean here: For example, consider a thermostat in your home set between 73 and 75 degrees F. A sensor comes on every few seconds and notes what the temperature is. The gateway box gets that information and registers it but it doesn’t need to send it to the cloud because that’s not necessary (not a “cloud-worthy” event). The gateway captures the event from a certain time span and simply registers it – say from 1:25PM to 1:45PM it was 74 degrees F. Now, if the sensor communicates to the box that the temperature has gone to 76 degrees F, then the box activates the air conditioner (actuates). But it still doesn’t need to go to the cloud.

At some point, the thermostat might reach 90 degrees in a couple of readings and then, two intervals later, 110 degrees. The box determines that this is not a false reading but, perhaps, an event and alerts the smoke detector to the event. Smoke sensed by the device confirms the event.

The gateway then communicates this information to the cloud and an emergency call is triggered to the fire department. Test have shown that in a scenario like this, when the sensor device (i.e. thermostat) and gateway are involved, you shave about 15 to 18 minutes of police or EMT-response time off of an otherwise manual 911 call. This event is an exception that goes to the cloud right away. Think about how often someone’s house catches on fire, and you see that indeed this is an exception and not the rule.

In a mobile health (mHealth) application, you could monitor heart rate or check other biometrics with the gateway box perhaps every five minutes. The sensor simply delivers the information to the box as opposed to the scenario where a healthcare worker checks in with a patient every few hours and spends less than three seconds checking vitals. If you are monitoring a potential heart attack patient and the vitals are within range, then the box records the event as satisfactory. But if the patient is having a heart attack, that is an exception to the event and the box calls the hospital.

The bottom line is that it is not necessary to be continuously communicating to the cloud. Because you upload metadata and not all the data at scheduled intervals, you consume far less bandwidth and power.

AK: What are the real or perceived challenges with adding connectivity to devices for IoT?

KK: The reason the industry has challenges is that most wireless-device connectivity technologies (i.e. Wi-Fi, BT) traditionally have been designed for cellular, enterprise, and data communications. In these applications, the device is always on so the off state is not a consideration. These are also data-intensive applications that demand bandwidth to carry the data.  However, IoT devices such as the tiny sensors in thermostats, smoke detectors, or entries to a house, or those sensors on the bridges, or moister sensors in a farm, for example, are almost all battery-operated devices and spend most of their time in sleep or off condition.

If you architect it the traditional way then, yes, you will have power-consumption issues. In IoT, the total cost of ownership is extremely important, due to the large number of devices that will be deployed. Hence, it is not cost effective to send technicians out into the field to change batteries on these devices every four to six months. In consumer applications, the batteries need to last between four and five years, and in industrial anywhere from eight-12 years. What we need for IoT communication devices is a new generation of wireless connectivity solutions, built from the ground up for IoT applications and battery operation. Implementing Wi-Fi in an IoT application cannot be about simply retrofitting from another market where power consumption is far less of a consideration and using it now for IoT, which most vendors are doing today.

Connectivity in IoT is a new way of doing things, hence you need to enable additional modes of operation (including deep-sleep modes) from a software and device-architecture perspective. You also need to enable very fast shut down and wake-up time, as well as partial memory retention to bring the device back to a known state of connection with the least leakage current possible.

One size does not fit all in IoT connectivity and a broad portfolio is required. If a vendor does not have multiple wireless technology capabilities, they cannot offer a complete solution. Simply because you don’t have expertise in a technology or IP, does not mean that the technology is not applicable. Even in 802.15.4, you use ZigBee for lighting and use 6lowPAN for home automation, but you may also need Bluetooth Smart and/or NFC for secure pairing in a multimode solution.

AK: What role do microcontrollers play in this market?

KK: From an architecture perspective, IoT devices are smart devices and what makes them smart is the tiny MCU. All IoT edge nodes include an MCU or MPU, connectivity, sensors and sensing platforms, and an energy source. About 85 percent of IoT devices use MCUs, and the rest will use MPUs. Design an MCU into a toaster oven with a user interface and you can control it in a more predictable and systematic manner. It now has become a “smart” toaster. Add the appropriate connectivity and you can now communicate and control that smart toaster remotely. And because these devices are sleeping most of the time, they benefit from the nonvolatile memory (FLASH) in many MCUs. When the power is off, the device’s memory retains the content.

That’s why thousands of application developers are turning to MCUs. Maker movements are the perfect example of how MCUs in the hand of smaller players are fueling the innovations on the edge node side of IoT. There were nearly 17 billion MCUs sold in 2013 alone and approximately 170 to 200 billion over the past 10 year. Most of these were never connected wirelessly or networked in the traditional sense of “networking”.  Suddenly, MCUs are becoming even more popular because they are the intelligence behind IoT devices. They will go into the sensors which connect to gateways which connect to the cloud, yet a lot of MCU developers don’t necessarily have the expertise in connectivity, networking, and security.

AK: How will the industry address the learning curve of designers who must transform a previously non-IoT device into an IoT device?

KK: It’s true that many of the current MCU developers are not security and connectivity experts and that is a challenge. Remember that the majority of IoT – about 95 percent – is industrial IoT which is a wide application spread out among thousands of small- to medium-sized companies.  These SMEs aren’t in a position to hire another couple of dozen people simply for connectivity and security expertise. As an MCU supplier, you need to understand MCU designers and the fact they are using products without the full expertise needed to optimally use connectivity and security.

At Atmel, we have over 40,000 MCU customers. With that many customers, we have had to learn how to sell in a no-touch fashion, leveraging our tools and development environment. I believe we will measure success in the IoT market by how well you can get to the point with mass market MCU developers where they can “consume” connectivity and security in a no-touch fashion without needing to become experts at it.

AK: What types of companies stand to benefit the most from IoT and why do you feel the Maker community is a key component to success?

KK: There are two sets of players in the IoT market: the traditional MCU companies who have the channels and reach into the mass market, and the traditional wireless connectivity companies whom I call “elephant hunters” since they have traditionally been focused on tens – not thousands – of customers. Most traditional MCU companies don’t have the level of connectivity expertise or the IP required, or their understanding of “things” is elementary. On the other hand, connectivity companies while they have rich connectivity know-how, don’t have the channels and mass market reach or expertise – an absolute must have for this market. Loyalty in channels takes years to develop, and is not an overnight situation into which you can buy your way.

Based on the dynamics of the edge nodes where billions of devices are to be developed, I believe it is the MCU guys who are at the center of IoT-device development. The MCU player that can provide a broad range of MCUs and MPUs, and simultaneously a full portfolio of connectivity solutions (including Wi-Fi which is the toughest nut to crack between all short-range connectivity technologies), will be the winner and capture this market.

Just as in nearly any other market, the majority of innovation in electronics came from small players.  Because IoT is so wide and has so many different segments involved, there is the potential for thousands of starts ups to innovate.

Importantly for IoT, smaller players heavily equates to the Maker community. There are over 1.3 million Arduino users, and of course our partnership with them has made our MCUs prominent on Arduino platforms. You simply can’t establish these this kind of community, allegiances, customers, or critical channels overnight. It’s a 10- to 15-year investment. As an example we have 680,000+ AVR freaks in our community. How long do you think it will take for a newcomer to develop a technology community of that size?

IoT_Campaign_Google+_Final_Master_1080x608_Final

Atmel is committed to becoming the number one fully-integrated edge node provider in the world through an expanded MCU and MPU portfolio, sensing platforms, full IoT communications technologies built from the grounds up for battery operations, integrated security, and a whole host of software offerings related to service delivery and provisioning. Along with this we are establishing a robust ecosystem of partners that can jointly provide full IoT system solutions from the tiniest edge nodes to the service providers in the cloud seamlessly.

At each step along the way, we are bringing innovation, ease-of-use, and integrated solutions to conserve power, extend battery life, ensure data security, and conform to wireless standards in the next big connected design. It’s our way of powering the possibilities of next-generation ideas. Get started today enabling a smarter world of tomorrow!

Want to read more? Access the original Design World interview here.

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.