In this segment of the series, the co-inventor of the AVR microcontroller chip talks about the famously low power that the chips consume.
I had heard that one of the clever things Atmel does to save memory power is that we turn on the memory, fetch four instruction op-codes then turn the memory off again. Now, if there is a branch in these four op-codes that change the program flow, well, we have to turn on the memory and grab another four instructions. But, you can imagine just how often that the chips are executing all for instructions, so that we get those four op codes for the power cost of one fetch.
Vegard Wollan jokes will fellow Norwegian Andreas Eieland [off camera] about divulging the secrets to Atmel’s ultra-low power.
Vegard confirmed that Atmel does this on both the latest AVR and on our Atmel | SMART ARM-based chips. I love this clip since this is where we break the 4th wall as Vegard jokes to the crew that I am giving away too many secrets. I also confirmed that some of our ARM chips have a switching regulator controller built in. For instance, the SAM4L has one switching and one linear regulator built in. Now we don’t put any giant inductors inside the chip, you supply the external inductor, but all the control circuitry is available so you can really minimize the BOM (bill-of-materials).
To allow single-supply operation the ARM-based SAM4L microcontroller has a switching regulator on board, you only need to supply an external inductor.
This is yet another thing that differentiates our ARM-core parts from the competition. Most engineers know how cool and revolutionary the AVR was, but we have applied all the “cool” and more to our ARM-based chips. As Vegard noted, we have many tricks and innovations to sip the lowest amount of power, and that includes having our own processes at our Colorado Springs fabrication facility.
Makers Pierre Emm, Piotr Widelka and Johan Da Silveira have replaced the extruder of an [Atmel powered] Makerbot Replicator with a tattoo instrument, effectively transforming the 3D printer into a fully-functional, permanent inking machine.
The hacked device, dubbed Tatoue, attaches a traditional tattoo gun on rails to a square metal frame. These components move along three axes, enabling Tatoue to follow the path of any line or curve of the human body. An embedded sensor can read the skin’s surface, which allows the needle respond to changes in texture and dimensions of the inserted limb.
The idea for Tatoue first came about following a workshop at Paris design school ENSCI les Ateliers back in October 2013, which encouraged students to use digital material available in the public domain to make something new. The team initially replaced the extruder with a pen before inserting an actual tattoo instrument, testing it on artificial skin and ultimately, on a human volunteer.
So, how does it work? First, a user simply selects a tattoo design from a library of graphic files or uploads their own. That file is then uploaded into the hacked 3D printer. Upon inserting an arm into the frame, the design is then inked onto the skin of the person. Impressively, the modded machine inserts ink into a person’s skin at speeds of up to 150 times per second.
According to its creators, they are still developing more user-friendly software for tattoo artists.
“The idea of our machine is to give tattoo artists a new tool that offers plenty of new possibilities,” the Makers recently Dezeen.
A 15-year-old Maker by the name of Angelo has designed a homebrew pulse monitor using an Atmel basedArduino board, a grippy clothes hanger, clear/bright red LED and a light dependent resistor (LDR).
“Movies look cool with those EKG (electrocardiogram), the one that beeps and detects heart activities. A few months ago, we had to shoot a hospital scene for our school project. We needed an EKG instrument,” Angelo explains.
“To keep the movie authentic, we didn’t want to fake the readings so we made the next best thing, a pulse monitor. This project works and can actually monitor your pulse. [However], due to the lack of research and experimentation, the homebrew pulse monitor cannot be used for medical purposes.”
Have a friend or foe who continuously tells fibs? Good news! According to Angelo, the homebrew device can even be used as a rudimentary lie detector.
“When a person lies, you’ll notice a sudden change on the [pulse] graph,” he said.
On the software side, Angelo employs Processing 2 for graphing, along with a specially coded Arduino IDE sketch. Both are required to run the homebrew project.
Evident by a recent infographic published by Forbes, it appears people are finally cognizant of the urgent need for security. It’s clearer than ever that hacking has become a real problem over the web and into electronic devices. With the emergence of the Internet of Things (IoT), we consistently find ourselves connecting these gadgets and gizmos to the web. As a result, security becomes a key issue throughout the entire chain.
Analog Aficionado Paul Rako recently had the chance to catch up with Bill Boldt, Atmel’s resident security expert, to explore the latest threats and trends in security as well as how Atmel can help secure products across the spectrum. Not in the reading mood? There’s a pretty sweet playlist of all the footage from the 1:1 interview here.
In the first segment of the interview, Boldt discusses how an engineer or designer can use Atmel’s CryptoAuthentication chips to ensure that the accessories to a particular product are genuine. Here, the security expert talks about using symmetrical authentication to certify that only a drill manufacturer’s batteries will work on its own drill.
If you recall, Boldt provided an in-depth exploration into this same demo, which can be found here. Though securing hardware is great, if you wanted, you could make this symmetrical authentication protect any kind of plug-in or device, even if it is not electronic. In fact, this safeguard is used on things ranging from ink cartridges to e-cigarettes; moreover, medical device manufactures love this technology since it protects them from liability from knockoff products.
This can help secure products with add-ons or attachments, but an even greater value for hardware security comes when you use these chips to make sure that your device has not had its code or operating system hijacked. Since the interface between the microcontroller and the crypto chip is only sending a random number from the micro, and the one-time result from the crypto chip in response, snooping on the SPI port will not help you crack the code. Now, your microcontroller firmware can query the chip and ensure that it indeed gets the proper result — if someone attacks the firmware and puts their own code, it won’t execute since it cannot get past the protected part of the chip code that has to get a valid response from the crypto chip.
You can extend this to secure downloads as well. As long as your code requires the downloaded segment to query and respond to the tiny crypto chip, only your code will work since only you know the secret key programmed into the chip.
“As a hardware engineer, I am just as fascinated by the cool packages we use as well as all the math and firmware algorithms,” says Rako.
In the subsequent video of the interview, Boldt describes the packaging for the crypto chips, in addition to a unique three-pad package manufactured by Atmel that does not need to be mounted on a circuit board at all.
During the segment, Boldt also delves deeper into some security scenarios for the IoT, incuding some great analogies. Furthermore, the security guru reminds viewers that these Atmel CryptoAuthentication chips will work with any company’s microcontroller, not just Atmel’s.
One thing you hear bandies about in security are the dissimilarities between both symmetric and asymmetric. The aforementioned drill demo was symmetric, since both the drill and the battery had the secret key programmed into the MCU and the crypto chip, respectively. Here, Boldt expands on the topic and how Atmel does all the hard math so you don’t have to worry about it.
Concluding his interview with Rako, Boldt addresses the fact that you can use the crypto chip not only in a drill, but in the charger as well to guarantee that only your OEM charge will charge your OEM batteries. The resident security expert wraps up by noticing that people can counterfeit those holograms on a product’s box, but they can’t hack hardware security chips.
Don’t you hate rushing around like a lunatic just to find out that your train is running late? Well, the iStrategyLabs crew recently debuted a solution to that very problem: a slick LED matrix sign that displays data about the next four trains arriving at the nearest metro station.
Dubbed Transit, the sign also lists how many bikes are available at the closest bikeshare station, along with the current local temperature. The data is pulled from various APIs via an Electric Imp platform, while an Arduino Mega (ATmega1280) is tasked with processing the information and powering the six LED matrices.
Guidon also noted that he first prototyped all the components on a breadboard to ensure the code was being properly executed.
“The biggest issue was learning how to handle the Washington Metropolitan Area Transit Authority API. They have a great API, but their trains do not run 24/7, so there needed to be logic in place to handle blank data being pushed over night,” he told Gizmag.
The final unit is mounted on the wall between the office’s two elevators, making it easy for people to see the information they need before they head out of the office. The sign refreshes every 30 seconds with data from each of the APIs.
Total time of assembly? One day. Total cost? Approximately $250.
Want to check out some of iStrategyLabs’ other innovative creations? We’d recommend the Atmel based selfie-taking mirror or its Uber-calling shoe clip — both of which can be found here.
Maker Stefano Guglielmetti recently brought to our attention a capacitive sensor-controlled, LED skull lamp that’ll make for quite the spook-tacular decoration for your next All Hallow’s Eve festivities. Powered by an ATtiny85 MCU, his artisanal skull project is a perfect blend of fun and humor with a touch of DIY.
The idea of this hack came shortly after Guglielmetti’s first encounter with the ceramic lamp dubbed Yorick from vión design. According to its website, the lamp is a timeless sculptural skull symmetrically divided in two by light and fitted with a fabric flex, mounted switch.
“As soon as I saw one of these [Yorik] lamps, I decided to experiment with them because they’re so beautiful that the classic on/off switch didn’t do them justice.”
After recently studying the Arduino capsense library, Guglielmetti felt that a capacitive sensor would be an innovative way to turn the lamp on and off without the use of an ordinary switch. To enable this, the basic idea was to paint the lamp’s interior with some electric ink from our friends at Bare Conductive.
To facilitate his prototype, the Maker decided to use an ATtiny85.
“The best thing about ATtiny is that you can use Arduino for prototyping, and then, with very small code adjustments, burn the code into the ATtiny, make the circuit supersmall, and go to production,” Guglielmetti revealed in a detailed blog tutorial.
Are you ready for Halloween? Are you queuing up some old Misfits MP3s, watching The Crow and breaking out those twinkling jack-o-lanterns for All Hallows’ Eve? Don’t want to use traditional wax candles or buy a jack-o-lantern light? Well, you can always do what Maker Johannes Bauer did and code your very own pseudo-random flickering LED.
In order to accomplish this feat, the Maker only required a few components: four slightly depleted AA batteries, a super bright LED, 680 ohm resistor and a custom code on an 8-pin ATtiny13 MCU.
Essentially, Bauer used avr-gcc to compile, package his code and build scripts for download. As expected, the hex file can be flashed over to the chip using avrdude or AVR Studio.
A fan of carving pumpkins? Have a few tinyAVRs laying around? Go ahead and create your own ‘hack’-a-lantern!
Product design teams endeavor to plan the safe launch of electronics products to prevent re-discovering issues that should have been learned from the previous project. Many Serial Electrically Erasable Programmable Read-Only Memory (SEEPROM) users have never utilized such components and therefore may not have knowledge of potential issues. Here is a personal story from several years ago when I was asked to support a customer working on an issue on a weekend. (You may have already guessed that the call came to me that weekend was from my boss’s boss’s boss.)
Here’s the issue that was described to me over the phone by the customer engineers (hardware and firmware) while they were in their laboratory troubleshooting:
We exchanged emails with DSO (digital storage oscilloscope) captures of the serial protocol after which I would request another DSO capture or two. Once we were drilling down to the issue, a customer firmware engineer held the phone line while the customer hardware engineers made more measurements. The customer firmware engineer asked me, “Why would someone drive the SEEPROM /CS signal low (true) and then back high (false) with no clocks or data in?” I quickly whipped out, “That is a chip select toggle that is utilized to recover from power interruption of the host microcontroller or from a protocol violation, and we have a Juraasic period FAQ about that buried deep in our website.” The customer firmware engineer said, “Uh oh, I didn’t know why anyone would do that, so I took it out.” Soon, the hardware engineers emailed me a DSO capture showing a protocol violation and then no communication from the SEEPROM. I announced that the firmware engineer has the solution to this issue and should be able to produce a new firmware build to mitigate this situation in the future.
Several product lines were brought to a standstill because the task to reduce firmware lines of code took precedence over why the code was there to begin with. Numerous engineers (including myself) have worked weekends unnecessarily. The moral to the story is that if you have product firmware that communicates properly with an Atmel SEEPROM and you do not know why a few lines of code exist, then you may want to ask yourself about the expected benefit of modifying that code before you throw the baby out with the bath water. Sometimes things are there for a reason that may not be all that obvious.
Stick to the adage: “When in doubt, don’t leave it out.”
Oh, and one more thing… Please comment your firmware source files adequately to help the next firmware developer. Remember that person may just end up being a future version of you!
This blog was written by Clay Tomlinson, Atmel Staff Applications Engineer
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.)
Growth in adoption of connected cars has exploded as of late, and is showing no signs of slowing down, especially the vehicle-to-infrastructure and vehicle-to-retail segments. As adoption grows exponentially, the challenges in how we develop these apps emerge as well.
One of the biggest challenges to consider will be connectivity, and how we connect and network the millions of connected cars on the road. How can we ensure that data gets from Point A to Point B reliably? How can we ensure that data transfer is secure? And how do we deal with power, battery, and bandwidth constraints?
1. Signaling
At the core of a connected car solution is bidirectional data streaming between connected cars, servers, and client applications. Connected car revolves around keeping low-powered, low-cost sockets open to send and receive data. This data can include navigation, traffic, tracking, vehicle health and state (Presence); pretty much anything you want to do with connected car.
Signaling is easy in the lab, but challenging in the wild. There are an infinite amount of speed bumps (pun intended) for connected cars, from tunnels to bad network connectivity, so reliable connectivity is paramount. Data needs to be cached, replicated, and most importantly sent in realtime between connected cars, servers, and clients.
2. Security
Then there’s security, and we all know the importance of that when it comes to connected car (and the Internet of Things in general). Data encryption (AES and SSL), authentication, and data channel access control are the major IoT data security components.
In looking at data channel access control, having fine-grain publish and subscribe permissions down to individual channel or user is a powerful tool for IoT security. It enables developers to create, restrict, and close open channels between client apps, connected car, and servers. With connected car, IoT developers can build point-to-point applications, where data streams bidirectionally between devices. Having the ability to grant and revoke access to user connection is just another security layer on top of AES and SSL encryption.
3. Power and Battery Consumption
How will we balance the maintaining of open sockets and ensuring high performance while minimizing power and battery consumption? As with other mobile applications, for the connected car, power and battery consumption considerations are essential.
M2M publish/subscribe messaging protocols like MQTT are built for just this, to ensure delivery in bandwidth, high latency, and unreliable environments. MQTT specializes in messaging for always-on, low-powered devices, a perfect fit for connected car developers.
4. Presence
Connected devices are expensive, so we need a way to keep tabs on our connected cars, whether it be for fleet and freight management, taxi dispatch, or geolocation. ‘Presence’ functionality is a way to monitor individual or groups of IoT devices in realtime, and has found adoption across the connected car space. Developers can build custom vehicle states, and monitor those in realtime as they go online/offline, change state, etc.
Take fleet management for example. When delivery trucks are out on route, their capacity status is reflected in realtime with a presence system. For taxi and dispatch, the dispatch system knows when a taxi is available or when its currently full. And with geolocation, location data is updated by the millisecond, which can also be applied to taxi dispatch and freight management.
5. Bandwidth Consumption
Just like power and battery, bandwidth consumption is the fifth connected car challenge we face today. For bidirectional communication, we need open socket connections, but we can’t have them using massive loads of bandwidth. Leveraging M2M messaging protocols like the aforementioned MQTT lets us do just that.
Building the connected car on a data messaging system with low overhead, we can keep socket connections open with limited bandwidth consumption. Rather than hitting the servers once multiple times per second, keeping an open socket allows data to stream bidirectionally without requiring requests to the server.
Solution Kit for Connected Cars
The PubNub Connected Car Solution Kit makes it easy to reliably send and receive data streams from your connected car, facilitating dispatch, fleet management applications and personalized auto management apps. PubNub provides the realtime data stream infrastructure that can bring connected car projects from prototype to production without scalability issues.
