4 reasons why Atmel is ready to ride the IoT wave

---

The IoT recipe comprises of three key technology components: Sensing, computing and communications.

---

In 2014, a Goldman Sachs’ report took many people by surprise when it picked Atmel Corporation as the company best positioned to take advantage of the rising Internet of Things (IoT) tsunami. At the same time, the report omitted tech industry giants like Apple and Google from the list of companies that could make a significant impact on the rapidly expanding IoT business. So what makes Atmel so special in the IoT arena?

The San Jose, California–based chipmaker has been proactively building its ‘SMART’ brand of 32-bit ARM-based microcontrollers that boasts an end-to-end design platform for connected devices in the IoT realm. The company with two decades of experience in the MCU business was among the first to license ARM’s low-power processors for IoT chips that target smart home, industrial automation, wearable electronics and more.

Goldman Sachs named Atmel a leader in the Internet of Things (IoT) market.

Goldman Sachs named Atmel a leader in the Internet of Things (IoT) market

A closer look at the IoT ingredients and Atmel’s product portfolio shows why Goldman Sachs called Atmel a leader in the IoT space. For starters, Atmel is among the handful of chipmakers that cover all the bases in IoT hardware value chain: MCUs, sensors and wireless connectivity.

1. A Complete IoT Recipe

The IoT recipe comprises of three key technology components: Sensing, computing and communications. Atmel offers sensor products and is a market leader in MCU-centric sensor fusion solutions than encompass context awareness, embedded vision, biometric recognition, etc.

For computation—handling tasks related to signal processing, bit manipulation, encryption, etc.—the chipmaker from Silicon Valley has been offering a diverse array of ARM-based microcontrollers for connected devices in the IoT space.

Atmel has reaffirmed its IoT commitment through a number of acquisitions.

Finally, for wireless connectivity, Atmel has cobbled a broad portfolio made up of low-power Wi-Fi, Bluetooth and Zigbee radio technologies. Atmel’s $140 million acquisition of Newport Media in 2014 was a bid to accelerate the development of low-power Wi-Fi and Bluetooth chips for IoT applications. Moreover, Atmel could use Newport’s product expertise in Wi-Fi communications for TV tuners to make TV an integral part of the smart home solutions.

Furthermore, communications across the Internet depends on the TCP/IP stack, which is a 32-bit protocol for transmitting packets on the Internet. Atmel’s microcontrollers are based on 32-bit ARM cores and are well suited for TCP/IP-centric Internet communications fabric.

2. Low Power Leadership

In February 2014, Atmel announced the entry-level ARM Cortex M0+-based microcontrollers for the IoT market. The SAM D series of low-power MCUs—comprising of D21, D10 and D11 versions—featured Atmel’s signature high-end features like peripheral touch controller, USB interface and SERCOM module. The connected peripherals work flawlessly with Cortex M0+ CPU through the Event System that allows system developers to chain events in software and use an event to trigger a peripheral without CPU involvement.

According to Andreas Eieland, Director of Product Marketing for Atmel’s MCU Business Unit, the IoT design is largely about three things: Battery life, cost and ease-of-use. The SAM D microcontrollers aim to bring the ease-of-use and price-to-performance ratio to the IoT products like smartwatches where energy efficiency is crucial. Atmel’s SAM D family of microcontrollers was steadily building a case for IoT market when the company’s SAM L21 microcontroller rocked the semiconductor industry in March 2015 by claiming the leadership in low-power Cortex-M IoT design.

Atmel’s SAM L21 became the lowest power ARM Cortex-M microcontroller when it topped the EEMBC benchmark measurements. It’s plausible that another MCU maker takes over the EEMBC benchmarks in the coming months. However, according to Atmel’s Eieland, what’s important is the range of power-saving options that an MCU can bring to product developers.

“There are many avenues to go down on the low path, but they are getting complex,” Eieland added. He quoted features like multiple clock domains, event management system and sleepwalking that provide additional levels of configurability for IoT product developers. Such a set of low-power technologies that evolves in successive MCU families can provide product developers with a common platform and a control on their initiatives to lower power consumption.

3. Coping with Digital Insecurity

In the IoT environment, multiple device types communicate with each other over a multitude of wireless interfaces like Wi-Fi and Bluetooth Low Energy. And IoT product developers are largely on their own when it comes to securing the system. The IoT security is a new domain with few standards and IoT product developers heavily rely on the security expertise of chip suppliers.

Atmel offers embedded security solutions for IoT designs.

Atmel, with many years of experience in crypto hardware and Trusted Platform Modules, is among the first to offer specialized security hardware for the IoT market. It has recently shipped a crypto authentication device that has integrated the Elliptic Curve Diffie-Hellman (ECDH) security protocol. Atmel’s ATECC508A chip provides confidentiality, data integrity and authentication in systems with MCUs or MPUs running encryption/decryption algorithms like AES in software.

4. Power of the Platform

The popularity of 8-bit AVR microcontrollers is a testament to the power of the platform; once you learn to work on one MCU, you can work on any of the AVR family microcontrollers. And same goes for Atmel’s Smart family of microcontrollers aimed for the IoT market. While ARM shows a similarity among its processors, Atmel exhibits the same trait in the use of its peripherals.

Low-power SAM L21 builds on features of SAM D MCUs.

A design engineer can conveniently work on Cortex-M3 and Cortex -M0+ processor after having learned the instruction set for Cortex-M4. Likewise, Atmel’s set of peripherals for low-power IoT applications complements the ARM core benefits. Atmel’s standard features like sleep modes, sleepwalking and event system are optimized for ultra-low-power use, and they can extend IoT battery lifetime from years to decades.

Atmel, a semiconductor outfit once focused on memory and standard products, began its transformation toward becoming an MCU company about eight years ago. That’s when it also started to build a broad portfolio of wireless connectivity solutions. In retrospect, those were all the right moves. Fast forward to 2015, Atmel seems ready to ride on the market wave created by the IoT technology juggernaut.

Interested? You may also want to read:

Atmel’s L21 MCU for IoT Tops Low Power Benchmark

Atmel’s New Car MCU Tips Imminent SoC Journey

Atmel’s Sensor Hub Ready to Wear

---

Majeed Ahmad is 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.

Atmel and IoT and Crypto, oh my!

One of the companies that is best positioned to supply components into the Internet of Things (IoT) market is Atmel. For the time being most designs will be done using standard components, not doing massive integration on an SoC targeted at a specific market. The biggest issue in the early stage of market development will be working out what the customer wants and so the big premium will be on getting to market early and iterating fast, not premature cost optimization for a market that might not be big enough to support the design/NRE of a custom design.

Here is Atmel’s latest product in the SmartConnect family, the SAM W25 module

Atmel has microcontrollers, literally over 500 different flavors and in two families, the AVR family and a broad selection of ARM microcontrollers ad processors. They have wireless connectivity. They have strong solutions in security.

Indeed last week at Electronica in Germany they announced the latest product in the SmartConnect family, the SAM W25 module. It is the industry’s first fully-integrated FCC-certified Wi-Fi module with a standalone MCU and hardware security from a single source. The module is tiny, not much larger than a penny. The module includes Atmel’s recently-announced 2.4GHz IEEE 802.11 b/g/n Wi-Fi WINC1500, along with an Atmel | SMART SAM D21 ARM Cortex M0+-based MCU and Atmel’s ATECC108A optimized CryptoAuthentication engine with ultra-secure hardware-based key storage for secure connectivity.

Atmel at Electronica 2014

That last item is a key component for many IoT designs. Security is going to be a big thing and with so many well-publicized breaches of software security, the algorithms, and particularly the keys, are moving quickly into hardware. That component, the ATECC108A, provides state-of-the-art hardware security including a full turnkey Elliptic Curve Digital Signature Algorithm (ECDSA) engine using key sizes of 256 or 283 bits – appropriate for modern security environments without the long computation delay typical of software solutions. Access to the device is through a standard I²C Interface at speeds up to 1Mb/sec. It is compatible with standard Serial EEPROM I²C Interface specifications. Compared to software, the device is:

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

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

Edge nodes are becoming integrated into everyone’s life

As it says in the white paper:

On first inspection, the requirements of an IoT edge device appear to be much the same as any other microcontroller (MCU) based development project. You have one or more sensors that are read by an MCU, the data may then be processed locally prior to sending it off to another application or causing another event to occur such as turning on a motor. However, there are decisions to be made regarding how to communicate with these other applications. Wired, wireless, and power line communication (PLC) are the usual options. But, then you have to consider that many IoT devices are going to be battery powered, which means that their power consumption needs to be kept as low as possible to prolong battery life. The complexities deepen when you consider the security implications of a connected device as well. And that’s not just security of data being transferred, but also ensuring your device can’t be cloned and that it does not allow unauthorized applications to run on it.

IoT design requirements: Software / development tools ecosystem

For almost any application, the building blocks for an IoT edge node are the same:

• Embedded processing
• Sensors
• Connectivity
• Security
• And while not really a “building block,” ultra-low power for always-on applications

My view is that the biggest of these issues will be security. After all, even though Atmel has hundreds of different microcontrollers and microprocessors, there are plenty of other suppliers. Same goes for connectivity solutions. But strong cryptographhic solutions implemented in hardware are much less common.

The new IoT white paper is available for download here.

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

ECDH key exchange is practical magic

What if you and I want to exchange encrypted messages? It seems like something that will increasingly be desired given all the NSA/Snowden revelations and all the other snooping shenanigans. The joke going around is that the motto of the NSA is really “Yes We Scan,” which sort of sums it up.

Encryption is essentially scrambling a message so only the intended reader can see it after they unscramble it. By definition, scrambling and unscrambling are inverse (i.e. reversible) processes. Doing and undoing mathematical operations in a secret way that outside parties cannot understand or see is the basis of encryption/decryption.

Julius Caesar used encryption to communicate privately. The act of shifting the alphabet by a specific number of places is still called the Caesar cipher. Note that the number of places is kept secret and acts as the key. Before Caesar, the Spartans used a rod of a certain thickness that was wrapped with leather and written upon with the spaces not part of the message being filled with decoy letters so only someone with the right diameter rod could read the message. This was called a skytale. The rod thickness acts as the key.

A modern-day encryption key is a number that is used by an encryption algorithm, such as AES (Advanced Encryption Standard) and others, to encode a message so no one other than the intended reader can see it. Only the intended parties are supposed to have the secret key. The interaction between a key and the algorithm is of fundamental importance in cryptography of all types. That interaction is where the magic happens. An algorithm is simply the formula that tells the processor the exact, step-by-step mathematical functions to perform and the order of those functions. The algorithm is where the magical mathematical spells are kept, but those are not kept secret in modern practice. The key is used with the algorithm to create secrecy.

For example, the magic formula of the AES algorithm is a substitution-permutation network process, meaning that AES uses a series of mathematical operations done upon the message to be encrypted and the cryptographic key (crypto people call the unencrypted message “plaintext“). How that works is that the output of one round of calculations done on the plaintext is substituted by another block of bits and then the output of that is changed (i.e. permutated) by another block of bits and then it happens over and over, again and again. This round-after-round of operations changes the coded text in a very confused manor, which is the whole idea. Decryption is exactly as it sounds, simply reversing the entire process.

That description, although in actual fact very cursory, is probably TMI here, but the point is that highly sophisticated mathematical cryptographic algorithms that have been tested and proven to be difficult to attack are available to everyone. If a secret key is kept secret, the message processed with that algorithm will be secret from unintended parties. This is called Kerckhoffs’ principle and is worth remembering since it is the heart of modern cryptography. What it says is that you need both the mathematical magic and secret keys for strong cryptography.

Another way to look at is that the enemy can know the formula, but it does him or her no good unless they know the secret key. That is, by the way, why it is so darn important to keep the secret key secret. Getting the key is what many attackers try to do by using a wide variety of innovative attacks that typically take advantage of software bugs. So, the best way to keep the secret is to store the key in secure hardware that can protect if from attacks. Software storage of keys is just not as strong as hardware storage. Bugs are endemic, no matter how hard the coders try to eliminate them. Hardware key storage trumping software is another fundamental point worth remembering.

Alright, so now that we have a good algorithm (e.g. AES) and a secret key we can start encrypting and feel confident that we will obtain confidentiality.

Key Agreement

In order for encryption on the sender’s side and decryption on the receiver’s side, both sides must agree to have the same key. That agreement can happen in advance, but that is not practical in many situations. As a result, there needs to be a way to exchange the key during the session where the encrypted message is to be sent. Another powerful cryptographic algorithm will be used to do just that.

There is a process called ECDH key agreement, which is a way to send the secret key without either of the sides actually having to meet each other. ECDH uses a different type of algorithm from AES that is called “EC” to send the secret key from one side to the other. EC stands for elliptic curve, which literally refers to a curve described by an elliptic equation.   A certain set of elliptic curves (defined by the constants in the equation) have the property that given two points on the curve (P and Q) there is a third point, P+Q, on the curve that displays the properties of commutivity, associativity, identity, and inverses when applying elliptic curve point multiplication. Point-multiplication is the operation of successively adding a point along an elliptic curve to itself repeatedly. Just for fun the shape of such an elliptic curve is shown in the diagram.

The thing that makes this all work is that EC point-multiplication is doable, but the inverse operation is not doable. Cryptographers call this a one-way or trap door function. (Trap doors go only one way, see?)  In regular math, with simple algebra if you know the values of A and A times B you can find the value of B very easily.  With Elliptic curve point-multiply if you know A and A point-multiplied by B you cannot figure out what B is. That is the magic. That irreversibility and the fact that A point-multiplied by B is equal to B point-multiplied by A (i.e. commutative) are what makes this a superb encryption algorithm, especially for use in key exchange.

To best explain key agreement with ECDH, let’s say that everyone agrees in advance on a number called G. Now we will do some point-multiply math. Let’s call the sender’s private key PrivKeySend.  (Note that each party can be a sender or receiver, but for this purpose we will name one the sender and the other the receiver just to be different from using the typical Alice and Bob nomenclature used by most crpyto books.) Each private key has a mathematically related and unique public key that is calculated using the elliptic curve equation.  Uniqueness is another reason why elliptic curves are used. If we point-multiply the number G by PrivKeySend we get PubKeySend. Let’s do the same thing for the receiver who has a different private key called PrivKeyReceive and point-multiply that private key by the same number G to get the receiver’s public key called PubKeyReceive.   The sender and receiver can then exchange their public keys with each other on any network since the public keys do not need to be kept secret. Even an unsecured email is fine.

Now, the sender and receiver can make computations using their respective private keys (which they are securely hiding and will never share) and the public key from the other side. Here is where the commutative law of point-multiply will work its magic. The sender point-multiplies the public key from the other side by his or her stored private key.  This is equates to:

PubKeyReceive point-multiplied by PrivKeySend which = G point-multiplied by PrivKeyReceive point-multiplied by PrivKeySend

The receiver does the same thing using his or her private key and the public key just received. This equates to:

PubKeySend point-multiplied by PrivKeyReceive  = G point-multiplied by PrivKeySend point-multiplied by PrivKeyReceive.

Because point-multiply is commutative these equations have the same value!

And, the rabbit comes out of the hat: The sender and receiver now have the exact same value, which can now be used as the new encryption key for AES, in their possession. No one besides them can get it because they would need to have one of the private keys and they cannot get them. This calculated value can now be used by the AES algorithm to encrypt and decrypt messages. Pretty cool, isn’t it?

Below is a wonderful video explaining the modular mathematics and discrete logarithm problem that creates the one-way, trapdoor function used in Diffie-Hellman key exhange. (Oh yeah, the “DH” in ECDH stands for Diffie-Hellman who were two of the inventors of this process.)

Are you building out for secure devices?  Protect your design investments and prevent compromise of your products? Receive a FREE Atmel CryptoAuthentication™ development tool.

Secure at any IoT deed

In his classic book, “Unsafe at Any Speed,” Ralph Nader assailed the auto industry and their approach to styling and cost efficiency at the expense of safety during the 1960s. He squared up on perceived defects in the Chevrolet Corvair, but extended his view to wider issues such as tire inflation ratings favoring passenger comfort over handling characteristics.

History has not treated Nader’s work kindly, possibly because of his politics including a crusade on environmental issues which spurred creation of the US Environmental Protection Agency. Sharp criticism of Nader’s automotive fault-finding came from Thomas Sowell in a book “The Vision of the Anointed”. He targeted “Teflon prophets,” Nader foremost among them, who foretell of impending calamity using questionable data, unless government intervenes as regulatory savior.

Sowell’s most scathing indictment of Nader was for failing to understand the trade-off between safety and affordability. Others targeted Nader’s logic by suggesting some non-zero level of risk and injury is acceptable if society progresses, supported by data the Corvair was actually no worse in terms of safety among its contemporaries on the automotive market at the time.

Yet, almost five decades later, we have Toyota sudden acceleration damage awards, GM ignition switches and massive recalls in progress, and the prospect that someday soon an autonomous car may go haywire. The problem seems to be not errors of commission, but errors of omission; complex engineering requirements, design, and test are becoming increasingly difficult. Getting all that done at volumes and prices needed to drive model year expectations and consumer market share is a big ask.

In an industrial context of the IoT, “safety critical” design is a science, with standards, and certification, and independent testing. In application segments such as aerospace and defense, medical, industrial automation, and others – even the automotive industry, which has made huge strides in electronics and software development – safety and risk are proactively managed.

Security of consumers on the IoT is another matter. Devices are inexpensive, often created by teams with little to no security experience. Worse yet, there is a stigma around many security features as unnecessary overkill that would slow down performance, get in the way of usability, or increase costs beyond competitiveness. This is an accident waiting to happen.

Or perhaps, one already in progress, if we believe the recent study on firmware in a sampling of consumer devices. A lot of folks think benevolent hackers are also polytetrafluoroethylene-coated, but it is hard to dispute there is cause for concern among embedded devices when it comes to security — especially when those devices connect to networks.

One of the areas cited in the study is encryption, and some rather sloppy handling of keys when it is used. Across the industry, embedded software is wildly inconsistent in approaches to encryption. As the study points out, developers are prone to stamp out copies of aged, flawed solutions because they are comfortable with and invested in a particular approach.

Regulation is the last thing we need here. Engineers need a lot more education, starting from the basics of including and using hardware encryption units on MCUs and SoCs, through the state-of-the-art knowledge in cryptography and certificate management, and up to IT-style approaches such as over-the-air software updates and two-factor authentication.

We also need some deeper thought on encryption implementations, beyond just NIST recommendations. In a web context, we have Transport Layer Security (TLS), but that protocol requires a full IP stack and a lot more horsepower than many small embedded devices can afford. On top of that, hardware encryption is currently very vendor-dependent. Vendors like Atmel are working with ARM on TrustZone technology to create newer implementations based on Trusted Exectuion Environment APIs, tuned for IoT devices instead of data center use.

Historically, encryption has been applied to securing closed systems – the IoT presents a paradox. If it devolves into a myriad of smaller, effectively closed systems that only intermittently share data, we may gain some benefit, but will never reach the vision.

The best case scenario is an effective set of industry practices emerge for encryption in consumer IoT devices before problems become widespread, defeating the very purpose of sharing data with the cloud. We need developers to not avoid encryption, but for that to happen it has to be cost- and implementation-effective for easier use.

This post has been republished with permission from SemiWiki.com, where Don Dingee is a featured blogger. It first appeared there on August 25, 2014.

Atmel’s AVR XMEGA MCU: High integration and ultra-low power

Earlier this week, Bits & Pieces took a close look at Atmel’s AVR UC3 which is built around high-performance 32-bit AVR architecture and optimized for highly integrated applications. Today, we are getting up close and personal with Atmel’s AVR XMEGA, an MCU designed for real-time performance, high integration and ultra-low power.

Powered by an Atmel AVR CPU, the AVR XMEGA is tuned to minimize code size and maximize execution speed. Indeed, its true single-cycle execution of arithmetic and logic operations allows AVR XMEGA microcontrollers to perform close to 1 MIPS per MHz. The fast-access register file with 32 x 8-bit general-purpose working registers is directly connected to the arithmetic logic unit (ALU). During a single clock cycle, the ALU can be fed two arbitrary registers, do a requested operation and write back the result. It provides efficient support for 8-, 16-, and 32-bit arithmetic. Plus, 12-bit analog-to-digital converters (ADCs) with gain stage offer a combined throughput of 4MSPS, while fast 12-bit digital-to-analog converters (DACs) with high drive strength, as well as other functions, reduce the need for external components.

As noted above, the AVR XMEGA boasts real-time performance, with an Event System that facilitates inter-peripheral signaling with 100% predictable response time. To help offload the CPU, all peripherals can use direct memory access (DMA) for data transfer. Meanwhile, Atmel’s stalwart picoPower technology enables true 1.6V operation, down to 100nA RTC operation with full SRAM retention for fastest possible wake-up time.

“In terms of integration, AVR XMEGA devices include Advanced Encryption Standard (AES) and Data Encryption Standard (DES) crypto modules, up to 32 pulse-width modulation (PWM) outputs, 8 UARTs, 4 TWI (I2C) and 4 serial peripheral interface (SPI) channels, a cyclic redundancy check (CRC) generator module and more,” an Atmel engineering rep told Bits & Pieces.

“On the USB connectivity side, the AVR XMEGA delivers full-speed operation without the need for external crystals, 31 endpoints, along with a special multi-packet function that maximizes data transfer rates while minimizing CPU load.”

AVR XMEGA devices also feature an innovative XMEGA  consisting of two independent 8-bit timers/counters and two lookup tables used for defining glue logic. It is designed to reduce bill of material (BOM) and PCB size as the XCL can replace external circuitry such as delay elements, RS-latches, D-latches, D-flip-flops chip-select logic, AND, NAND, OR, NOR, XOR, XNOR, NOT, MUX AND/OR/XOR logic gates. In addition, it can, in conjunction with the USART, enable customized communication protocols.

And last, but certainly not least, Atmel’s AVR Software Library include a plethora of device drivers and communication stacks that save time and development effort, allowing engineers to focus on more important design tasks. Similarly, Atmel’s QTouch Sensing Library helps devs to easily integrate robust capacitive touch sensing interfaces for buttons, sliders and wheels.

Interested in learning more? Additional Atmel AVR XMEGA technical details are available here.