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.
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.
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.
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.
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.
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.
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.”
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.
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.”
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.
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.
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.
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.”
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.
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?
KK: The 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?
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!
Part 2 of The ABCs of ECDSA (“Sign-Here”) will describe how digital certificates are made and signed. In the previous article (The ABCs of ECDSA: Part 1), we examined the steps of ECDSA performing asymmetric authentication using digital certificates. You may have noticed that both Part 1 and Part 2 are in reverse chronological order; however, it makes better sense to first understand a bit about the actual authentication process before dissecting the details of making the certificate. (Just trust me on that.) Before we get into the nuances of the certificate, let’s recall that authentication is about keeping something real. Such things would be mobile, medical and consumer accessories; embedded firmware; industrial networks; and soon the new platforms of IoT, home automation, and vehicle-to-vehicle communications. Aside from those, there are several others given the fact that the need for authentication is increasing exponentially as more things communicate with each other, and through the cloud, are creating more opportunities for bad actors to apply their mal-intent.
Especially with the increased use of the Internet and the cloud for financial transactions and transmission of confidential personal/medical information, it’s critical to ensure that the sender of information is exactly who they are supposed to be, as well as that the data has not been tampered with. That is where authentication and hardware key storage come in. Here we will focus on asymmetric authentication. Asymmetric authentication using ECDSA is based upon a digital certificate, which in this case, is stored in the ATECC108A device.
So, now let’s go into the chip factory and see how the ECDSA certificate is made and stored in the device. Remember that ECDSA stands for Elliptic Curve Digital Signature Algorithm. The words “Elliptic Curve” are in the name because Elliptic Curve Cryptography (“ECC”) algorithms are used. No mystery there. The benefit of ECC is that it provides extremely strong security with shorter key lengths than other popular algorithms. Bitcoin, for example uses ECC predominantly for that reason. (We won’t go into Bitcoin here.) “DSA” points to the fact that digital signatures are the key element of the process, which is also fairly self evident. The digital signing process is what we describe here, step by step. “Certificate” is the name given to the concept of putting certain types of data together in a prescribed format and then signing that data using hashing algorithms and signing algorithms. (Again, the usage of the certificate is covered in Part 1.)
While we are fully immersed here in cryptographic alphabet soup, we might as well add one more thing to it: The prescribed format used in the ECDSA in the ATECC108A is called ASN.1. ASN.1 basically defines what is what in the certificate, including the serial number, the public key and that sort of thing. It also defines the length of those data elements.
Now, back to building the certificate: The certificate is made and loaded in the key storage device in the chip factory. It is made from two main components:
1. The certificate data 2. The signature
The certificate data is a collection of data from three sources:
1. Static data: Boiler plate type data that does not change, such as the name and address of the manufacturer. (This is the ASN.1 encoded stuff.)
2. Dynamic data: Data from the tester that can change with each device such as time, date, and serial number.
3. Client device’s public key, which has an algorithmic relationship to the client’s private key that will be securely stored in the client device.
The certificate data is formatted according to X.509 specifications (yes, more crypto jargon). X.509 defines the elements and order of the elements in the certificate, such as serial number, public key, subject’s common name (i.e. the name of the certificate), authority ID (normally a SHA-1 hash of the public key), authority common name (i.e. the name of the authority that signs the certificate data), among other things. We will leave more about X.509 for another day.
The certificate data comprises just half of the certificate, the other half is the signature. What is a little tricky to understand at first is that the certificate data do two things: (1) become part of the certificate as it is, and (2) gets hashed and signed to make the signature. Both the certificate data itself and the signature make up the certificate.
The specific steps in order to make the signature begins with a copy of the certificate data being put through a hash algorithm to create a number called a hash value (or digest). ECDSA specifies a 32 byte digest length and SHA256 as the hashing algorithm. Once created, the digest is ready to be signed by the sign module in the factory.
The sign module is a piece of equipment that securely stores the signer’s private key. No one can get access to that key. The sign module uses the ECC sign algorithm to sign the digest of the certificate data with the signer’s private key. The result of that process becomes the “signature.” The signature then joins the original (i.e. unhashed) certificate data to complete the certificate. Note that the signing key is tied to the OEM’s root key to create the root of trust (the notion of root of trust will be addressed in another article).
The certificate is now finished and can be installed into the crypto device. Once the device is finished, it is then shipped to the customer’s factory to be assembled into an accessory, consumable, board or any number of things, i.e. a consumable water filter that later gets installed into refrigerator. In this scenario, when a new filter is installed by the consumer into the refrigerator when the old filter expires, the new filter will be authenticated by the host processor in the refrigerator according to the ECDSA process as described in The ABCs of ECDSA (Part 1).
Below is a video (sorry, no sound) that will visually help walk you through the steps noted above.
Benefits of asymmetric authentication with ECDSA include:
Increased security because asymmetric authentication does not need secure key storage on the host (only the client)
No need to update the host with secrets in the field (can update the public key at any time.)
Uses the advantages of Elliptic Curve Cryptography (high security, short key, less computation)
Atmel CryptoAuthentication™ products such as Atmel’s ATSHA204A, ATECC108A and ATAES132 implement hardware-based storage, which is much stronger then software based storage because of the defense mechanisms that only hardware can provide against attacks. Secure storage in hardware beats storage in software every time. Adding secure key storage is an inexpensive, easy, and ultra-secure way to protect firmware, software, and hardware products from cloning, counterfeiting, hacking, and other malicious threats.
One of the major difficulties in explaining anything cryptographic, among many other things, is what I call “Acry-phobia” which is fear of cryptographic acronyms. This is a justified condition.
Acryphobia is far from irrational because in cryptography (since it is math) every little thing and the relationships between them must be defined, specified, examined, theorized, tested, formulated, processed, scrutinized, proved, and…. well, you get the picture. Simply stated, this means there’s a whole lot to it. Therefore, in order to teach cryptographic concepts, it’s imperative to focus on a specific area at a time and then break that down further into its fundamentals: That is sort of like breaking down the works of Shakespeare first into episodes, then into Old English then modern English and finally the ABCs. In pretty much similar fashion, that is what we want to do here. Namely, focus on one type of authentication scheme and break it down into its fundamentals and explain those one step at a time.
The specific fear-inducing cryptographic acronym we will try to overcome during this session (and one more after it) is ECDSA, or Elliptic Curve Digital Signature Algorithm.
To quickly dispel some of the Acryphobia, let’s look at authentication from a less mathematical viewpoint.
The basic idea of authentication (just like the name says) is to authenticate, meaning to confirm that the sender of a message is exactly who they say they are. Confirmation is the key to authentication and it requires using some type of trusted credential from another party to verify a declared identity. As noted in an earlier article, this identity confirmation process is sort of like those scenes in old movies where a guard of some type challenges an approacher by saying, “Halt! Who goes there?”
Once challenged, the approacher must respond by identifying himself (or herself) and produce a document (certificate) with the signature or seal of the king, general, or some other trusted authority to confirm that the bearer is not an impostor. That seal or signature links the approacher to a recognized, trusted signer/sealer. The signer/sealer can be described therefore as the certificate authority. (Note that “Certificate Authority” is in fact a technical cryptographic term.)
Cryptographic authentication is just the mathematical version of this challenge-response-certificate-signing-verification process. It uses digital processors, rather than people with bayonets or other weapons of choice.
Getting back to the math, the type of authentication we are discussing in this article is asymmetric, meaning that the secret key is not stored on both the host and client (like with symmetric authentication). Asymmetric authentication stores the secret key on the client side only and then the uses certain mathematical algorithms on certain prescribed information that the client sends it for the ultimate purpose of verifying that the client is real. ECDSA is one of the available types of processes, and what we are going to explore throughout the rest of the article, in a step-by-step fashion. Later on, in an upcoming article, we will address the details about how the crypto devices are originally loaded in the chip factory with the important information needed to make ECDSA authentication happen out in the real world.
So, let’s get into the asymmetric authentication process, which typically begins when a client device is inserted into a host system or the host system wants to know what exactly is connected to it. Examples include a printer ink cartridge being inserted into a printer, a thermostat control block wanting to talk to a remote temperature sensor, a cell phone connecting to a wall charger, among a number of others.
ECDSA (Elliptic Curve Digital Signature Algorithm) is a two-phased process:
Phase 1is to verify that the public key on the client
Phase 2 is to verify the private key on the client.
If both phases pass these two verify calculations then the client is verified as real (i.e. by showing that there is a valid private-public key pair in the client).
(Remember that authentication of any type is meant to keep something real. How the keys are used defines if the process is symmetric or asymmetric.)
The steps of ECDSA are depicted in the diagrams below. In this particular example, the illustrations are based upon a host system that contains a microcontroller and a client (accessory) equipped with an ATECC108A secure key storage device.
Phase 1 starts with the host requesting information to be sent over by the client (accessory). That information comes over to the host as a “certificate.” This certificate is made and then programmed into the crypto device in the chip factory. For now, we’ll start with the already assembled, stored and ready-to-use certificate.
The certificate contains two main things:
Certificate data (made up of the client’s public key + static data + dynamic data)
Signature (made by hashing that certificate data and the signer’s secret key in the chip factory)
When the host receives the certificate, it extracts the certificate data (static data, dynamic data, and client public key) and the signature (made by the signing module in the chip factory). The host runs the same hashing that was used in the chip factory on the certificate data it just received, creating a 32-byte message digest that will be used in the phase one ECDSA calculation. If the client is real, then this hash function run in the host should have the exact same result (digest) as the one that was run the chip factory to create the signature.
On the host, the message digest made from the received certificate data, the signer’s public key, which also came over from the client (more on how that arrives will be in yet another article), and the signature from the certificate are put into the ECDSA verify calculation. If the ECDSA calculation is successful, the client’s public key is considered to be real. That then starts phase 2 to verify the client’s private key.The whole point of this two-phase process is to verify mathematically that the client’s private key and public key are indeed a valid key pair.
The goal of phase two is to verify the client’s private key. This phase begins with the host generating a random number challenge and sending it to the client. The client device uses the ECDSA signature engine in the ATECC108A to create a new signature using this random number and the client’s (secret) private key stored there. That new signature is then sent to back the host, which uses it along with the random number and the client’s public key (that was verified in phase one) as inputs to another ECDSA verify calculation. If that calculation succeeds, the host has then proven that the accessory (client) is real (i.e. contains a valid private-public key pair)
As you can see, the ATECC108A does all the heavy mathematical lifting, and Atmel provides what users need to make it easy to program the microcontroller to do its part of the process. The engineering and mathematics behind authentication using sophisticated algorithms may not be easy in theory, but that does not matter as Atmel makes it simple to implement cryptography without having to be a cryptography expert…. and that is the “REAL” point here.
The video (now with sound) will step you through the two phases of the ECDSA process described above.
So, in summary, the key aspects of asymmetric authentication with ECDSA include:
Increased security because asymmetric authentication does not need secure key storage on the host (only the client)
No need to update the host with secrets in the field. (can update the public key at any time.)
Uses the advantages of Elliptic Curve Cryptography (high security, short key, less computation)
Atmel CryptoAuthentication™ products such as Atmel’s ATSHA204A, ATECC108A and ATAES132 implement hardware-based storage, which is much stronger then software based storage because of the defense mechanisms that only hardware can provide against attacks. Secure storage in hardware beats storage in software every time. Adding secure key storage is an inexpensive, easy, and ultra-secure way to protect firmware, software, and hardware products from cloning, counterfeiting, hacking, and other malicious threats. For more details on Atmel CryptoAuthentication products, head on over to its introduction page here.
The Internet of Things (IoT), as noted in previous Bits & Pieces articles, is really just a concept at this point because the “things” are undefined. As those “things” become more defined, the IoT’s things stop being just things and become something. So, the main question right now: What are those things going to be? Perhaps the IoT should more accurately be called the “IoXT”with “X” being the variable describing what that particular thing actually is. An example could be the Internet of wearable fitness trackers, factory robots, home automation, smart appliances, vehicle to vehicle communication, traffic control… well, you get the picture. The X can (and will) be many different things.
Clearly, for the IoT to be meaningful, the X must be identified in detail. The IoT must evolve from the ultra-general (i.e. “things”) to specific applications, components, systems, and integrated circuits, among others. There appears to be an emerging need for a classification hierarchy to describe the IoT as it differentiates and evolves. The Linnaeus classification model that is used in biology to describe living “things”, comes to mind. The same classification process can apply to silicon-based things and not just carbon-based things (beings).
Do you see the connection?
In a silicon-based classification regime, the term “IoT” would probably lie somewhere between phylum and family. Though it is not entirely clear exactly where yet, that does really not matter at this point; however, what matters is that engineers and product managers must push product definition to the genus and species levels for the IoT to ever truly matter.
In the early stages of IoT’s evolution, there could easily be a type of Cambrian explosion with the genesis of an insane number of new devices covering a wide spectrum of applications that from the truly inspired to the ridiculous. Economic Darwinism would later surely take over to narrow down the numbers overtime with many going extinct and others continuing to adapt into world-changing “things.”
Because the IoT’s silicon building blocks (i.e. the DNA of IoT) are getting into place, it will become very easy to create, modify, and adapt countless smart, sensing, secure, communicating devices. That ease of design is what is making IoT’s potential staggering, and why so many companies (especially silicon companies) are aggressively pursuing the IoT market.
As for the numbers, Gartner believes 26 billion devices will have connectivity by 2022, while Ericsson and Cisco both forecast the number being even higher at 50 billion units by 2020 and 2022, respectively. McKinsey Global Institute (MGI) expects IoT to have an economic impact of $2.7 to $6.2 trillion by 2025. Gartner notes that IoT suppliers will generate incremental product and service revenue exceeding $300 billion in 2020, resulting in over $1.9 trillion in global economic value-add in diverse end-markets. According to IDC, the installed base of IoT will be 212 billion by the end of 2020, with 30.1 billion of that being connected autonomous things.
The following chart from McKinsey Global Institute details their view of the impact from various economic categories. Note that healthcare is the largest, which makes perfect sense given the affinity of bio-sensors, continuous monitoring, wearable devices, and wireless communication. Subsequently, it is no accident that the major mobile platform and consumer product companies are pursuing bio-metric capabilities for wearable products.
With an increasing demand for medical care as populations age in Western countries, remote telemedicine to cover under-served populations makes great sense. Telemedicine could easily revolutionize medical care, and connected-sensing devices could revolutionize telemedicine. There is little to hold the growth of medical sensing and communicating networks back, especially since governmental agencies are on a mission to extend the provision of health care universally. Perhaps this is a perfect storm.
Health networks will be joined by networks of many types; each of those will be driven by the ability to create IoT devices from their four main building blocks:
1. Brains (MCU) 2. Wireless Communications 3. Sensors of Various Types 4. Security.
Devices with those fundamental IoT building blocks will differentiate on each of those four axes depending upon what they need to do. Some of the types of networks that could show up and drive the IoT’s evolution are noted below:
M2M: Machine to Machine network
V2V: Vehicle to Vehicle network
Personal medical network
PAN: Personal area network (wearable network)
Home entertainment network
Personal social network.
Home automation/security network
Personal fitness network.
Car infotainment network
Highway sensor network
Hazardous material sensing network
Smart appliance network
Augmented reality network
Multi-screen network
Energy management network
There are of course others, too.
One last thing: The dirty little secret of the IoT is that there probably cannot be such a thing as the Internet of Things if those things are not secure. That is where devices like Atmel CryptoAuthentication ICs play an important, if not catalytic role. Making sure that the nodes in the various networks are authentic and that the data being transmitted have not been tampered with is what CryptoAuthentication devices do. It is easy to see why security is important when there are billions of things keeping track of you, right?
So, authentication may in actual fact be the sine qua non (“without which there is nothing”) of the IoT.
Or, to put it another way: No security? No IoT for you.
Atmel has introduced the ATM90E26, a low-cost metering Analog Front End (AFE) IC. According to an Atmel engineering rep, the ATM90E26 is specifically designed for smart grid communications, electricity metering systems and energy measurement applications.
“The Atmel Smart Energy platform includes several System-on-Chip (SoC) devices built around a unique dual-core ARM Cortex M4-based architecture. The platform includes the SAM4C with advanced security, in addition to metrology-enabled versions for single- and poly-phase metering (SAM4CMx) and Power-Line Communications (PLC) enabled solution (SAM4CPx),” the Atmel engineering rep told Bits & Pieces.
“The new ATM90E26 is pin-to-pin compatible with the IDT 90E22/23/24/25 devices, featuring UART support and improved power measurement resolution. By providing the discrete metrology AFE ATM90E26 as well as various MCU/MPU and PLC/wireless solutions, our Smart Energy Platform offers designers multiple options and various levels of integration to address their smart metering designs. For example, the ATM90E26 can be bundled with the SAM4CPx for a complete smart metering architecture.”
Key ATM90E26 features include:
Dynamic range of 5000:1 with 0.1% kWh accuracy and 0.2% kvarh accuracy.
Temperature co-efficient of reference voltage 15ppm/ºC (typ.).
Single-point calibration for active energy.
Up to 24x PGA to support shunt sensing in L line current channel.
Programmable startup and no-load power threshold.
Measures Vrms, Irms, P(Q/S), frequency, power factor and phase angle. Enhanced resolution for RMS and mean power.
Measurement accuracy better than 0.5%.
Configurable high-pass filter (HPF) in each ADC channel.
On-chip parameter diagnosis function and programmable interrupt output to reduce complexity and increase robustness of the meter.
Standard four-wire, simplified three-wire SPI interface, or a UART interface.
Dedicated voltage zero-crossing output pin (ZX); voltage sag detection.
Software reset available.
3.3V single power supply; 5V compatible for digital input.
It should also be noted that Atmel’s ATM90E2x single-phase energy metering demo board can be used to evaluate and test ATM90E2x chips. More specifically, the board is capable of sampling single-phase voltage/current, meter active/reactive energy, output active/reactive energy pulses, as well as measure parameters such as voltage, current and power.
Interested in learning more about Atmel’s smart energy platform? You can check out our detailed deep dive here.
Additional key specs include up to 512 MB RAM, up to 256 MB Flash, serial EEPROM, micro SD card slot, three USB host ports, JTAG soldering pads on SoM, serial port via SoM connectors and an Ethernet PHY.
The Acqua A5 also features RGB I/F @ 24 bits for LCD TFT + Resistive touch panel I/F, up to 3 TWI compatible I2C, up to 6 serial ports, up to 120 GPIOs, up to 6 PWM and up to 12 A/D @ 12 bits.
“For environments with lots of electromagnetic noise (e.g. DC motors), a metallic shield made by Wurth Elektronik is available as an option. They currently have a very basic baseboard called Berta A5 basic (9 Euros) with the three connectors for the SoM board, and breadboard area (2.54 pitch) for easier access to various signals,” a CNX Software writer explained.
“The company also provides software documentation showing how to build Linux 3.10, generate an Embedded Debian Grip 7.3 root file system, as well as various tutorials. The board is software compatible with Atmel’s SAMA5D3 Xplained board, so the instructions to use the Yocto Project or Debian 7.4 should also work.”
Acqua’s A5 SoM is currently shipping for 49 ($67) to 69 ($94) Euros in single quantity depending on options and as low as 37.24 Euros ($50) in 5K+ quantities.
It should be noted that the Open Yooquik – a recently debuted home automation system – is built around Acme’s Acqua A5 System on Module (SoM).
Aside from the SAMA5D3 MPU, key Yooquik hardware features include:
“[However], we have chosen a different way: the main controller behaves as an access point or as a WiFi client connected to your home network, whereas all remote devices are connected to the main controller with a RF radio. About 700 meters are covered without repeaters.”
On the software-server side, the Yooquik crew has deployed Node.js, while the RF modules arrive preloaded with firmware to facilitate a true plug-and-play experience. Yooquik also offers easy access to cloud, allowing users to manage multiple devices with a simple API.
“To develop your iOS or Android native app, you can use our Javascript libraries and the amazing Cordova/PhoneGap project,” the rep added. ”Nothing could be easier to control your home automation system from your smartphone. Forget router NAT configurations: connect your app to our cloud and you manage all your Yooquik devices.”
Atmel | Bits & Pieces 