Tag Archives: MCU

What’s ahead this year in digital insecurity?


Here’s a closer look at the top 10 cyber security predictions for 2015.


In 2014 worries about security went from a simple “meh” to “WTF!” Not only did high-profile attacks get sensational media coverage, but those incidents led to a pivotal judicial ruling that corporations can be sued for data breaches. And as hard as it is to believe, 2015 will only get worse because attack surfaces are expanding as mobile BYOD policies overtake enterprises, cloud services spread, and a growing number of IoT networks get rolled out. Add m-commerce, e-banking, and mobile payments to the questionable tradition of lax credit card security infrastructure in the U.S. and you get a perfect storm for cybercrime.

In fact, 92% of attacks across the range of segments come from nine basic sources (seen in the diagram below), according to Verizon. More numerous and sophisticated cyber crimes are anticipated for this year and beyond.

z1

 1. More companies to get “Sony’d”

2014 saw the release of highly-evolved threats from criminals that in the past only came from governments, electronic armies and defense firms. A wide-range of targets included organizations in retail, entertainment, finance, healthcare, industrial, military, among countless other industries. As a repeat offender, Sony is now the cyber-victim poster child, and the term “Sony’d” has become a verb meaning digital security incompetence. Perhaps Sony’s motto should be changed from “make.believe.” to “make.believe.security.” Just saying!

Prior to 2014, companies on a wholesale basis tended to simply deny cyber vulnerabilities. However, a string of higher profile data breaches — such as Sony, Heartbleed, Poodle, Shellshock, Russian Cyber-vor, Home Depot, Target, PF Chang’s, eBay, etc. — have changed all of that. Denial is dead, but confusion and about what to do is rampant.

2. Embedded insecurity rising

Computing naturally segregates into embedded systems and humans sitting in front of screens.  Embedded systems are processor-based subsystems that are “embedded” into other machines or bigger systems.  Examples are routers, industrial controls, avionics, automotive engine and in-cabin systems, medical diagnostics, white goods, consumer electronics, smart weapons, and countless others.  Embedded security was not a big deal until the IoT emerged, which will lead to billions of smart, communicating nodes.  15 to more than 20 billion IoT nodes are being forecast by 2020, which will create a gigantic attack platform and make security paramount.

IoT Installed

A recent study by HP revealed that 70% of interconnected (IoT) devices have serious vulnerabilities to attacks. The devices they investigated consisted of “things” like cloud-connected TVs, smart thermostats and electronic door locks.

“The current state of Internet of Things security seems to take all the vulnerabilities from existing spaces — network security, application security, mobile security and Internet-connected devices — and combine them into a new, even more insecure space, which is troubling,” HP’s Daniel Miessler stated.

Issues HP identified ranged from weak passwords, to lack of encryption, to poor interfaces, to troubling firmware, to unencrypted updating protocols. Other notable findings included:

  • 60% of devices were subject to weak credentials
  • 90% collected personal data
  • 80% did not use passwords or used very weak passwords
  • 70% of cloud connected mobile devices allowed access to user accounts
  • 70% of devices were unencrypted

Investigators at the Black Hat Conference demonstrated serious security flaws in home automation systems. At DEFCON, investigators hacked NFC-based payment systems showing that passwords and account data was vulnerable. They also revealed that the doors of a Tesla car could be hacked to open while in motion. Nice! Other attacks were exploited on smart TVs, Boxee TV devices, smartphone biometric systems, routers, IP cameras, smart meters, healthcare devices, SCADA (supervisory, control and data acquisition) devices, engine control units, and some wearables. Even simple USB firmware was proven to be highly vulnerable… “Bad USB.”

These are just the tip of the embedded insecurity iceberg. Under the surface is the entire Dark Net which adds even more treacherousness. Security companies like Symmantic have identified home automation as a likely early IoT attack point. That is not surprising because home automation will be an early adopter of IoT technologies, after all. In-house appliances also represent an attractive attack surface as more firmware is contained in smart TVs, set top boxes, white goods, and routers that also communicate. Node-to-node connectivity security extends to industrial settings as well.

Tools like Shodan, which is the Google of embedded systems, make it very easy for hackers to get into the things in the IoT.  CNN recently called Shodan the scariest search engine on the Internet. You can see why since everything that is connected is now accessible. Clearly strong security, including hardware-based crypto elements, is paramount.

 3. More storms from the cloud

z5

It became clear in 2014 that cloud services such as iCloud, GoogleDrive, DropBox and others were rather large targets because they are replete with sensitive data (just ask Jennifer Lawrence). The cloud is starting to look like the technological Typhoid Mary that can spread viruses, malware, ransomware, rootkits, and other bad things around the world. As we know by now, the key to security is how well cryptographic keys are stored.   Heartbleed taught us that, so utilizing new technologies and more secure approaches to maintain and control cryptographic keys will accelerate in 2015 to address endemic cloud exposure. Look for more use of hardware-based key storage.

4. Cyber warfare breaks out

eBay, PF Chang’s, Home Depot, Sony, JP Morgan, and Target are well-known names on the cybercrime blotter, and things will just get worse as cyber armies go on the attack. North Korea’s special cyber units, the Syrian Electronic Army, the Iranian Cyber Army (ICA), and Unit 61398 of the People’s Liberation Army of China are high profile examples of cyber-armies that are hostile to Western interests. Every country now seems to have a cyber-army units to conduct asymmetric warfare. (These groups are even adopting logos, with eagles appearing to be a very popular motif.)

z6

Cyber warfare is attractive because government-built malware is cheap, accessible, and covert, and thus highly efficient. Researchers have estimated that 87% of cyber-attacks on companies are state-affiliated, 11% by organized crime, 1% by competitors, and another 1% by former employees. Long story short, cyber war is real and it has already been waged against non-state commercial actors such as Sony. It won’t stop there.

 5. Cybercrime mobilizes

According to security researchers, mobile will become an increasingly attractive target for hackers. Fifteen million mobile devices are infected with malware according to a report by Alcatel-Lucent’s Kindsight Security Labs. Malvertising is rampant on untrusted app stores and ransomware is being attached to virtual currencies. Easily acquired malware generation kits and source code make it extremely easy to target mobile devices. Malicious apps take advantage of the Webkit plugin and gain control over application data which hands credentials, bank account, and email details over to hackers. What’s more, online banking malware is also spreading. 2014 presented ZeuS, which stole data, and VAWTRAK that hit online banking customers in Japan.

Even two-factor authentication measures that banks employ have recently been breached using schemes, such as Operation Emmental. Emmental is the real name of Swiss cheese, which of course is full of holes just like the banking systems’ security mechanisms.  Emmental uses fake mobile apps and Domain Name System (DNS) changers to launch mobile phishing attacks to get at online  banking  accounts and steal identities. Some researchers believe that cybercriminals will increasingly use such sophisticated attacks to make illegal equity front running and short selling scams.

z7

6. Growing electronic payments tantalize attackers

Apple Pay could be a land mine just waiting to explode due to NFC’s susceptibility to hacking. Google Wallet is an example of what can happen when a malicious app is granted NFC privileges making it capable of stealing account information and money. M-commerce schemes like WeChat could be another big potential target.

z8

E-payments are growing and with that so will the attacks on mobile devices using schemes ranging from FakeID to master key. Master key is an exploit kit similar to blackhole exploit kit that specifically targets mobile, where FakeID allows malicious apps to impersonate legitimate apps that allow access to sensitive data without triggering suspicion.

7. Health records represent a cyber-crime gold mine

Electronic Health Records (EHR) are now mandatory in the U.S. and a vast amount of personal data is being collected and stored as never before. Because information is money, thieves will go where the information is (to paraphrase Willie Sutton). Health records are considered higher value in the hacking underground than stolen credit card data. Criminals throughout both the U.S. and UK are now specializing in health record hacking. In fact, the U.S. Identity Theft Resource Center reported 720 major data breaches during 2014 with 42% of those being health records.

8. Targeted attacks increase

Targeted attacks, also known as Advanced Persistent Threats (APTs), are very frightening due to their stealthy nature. The main differences between APTs and traditional cyber-attacks are target selection, silence, and duration of attack. According to research company APTnotes, the number of attacks by year went from 3 in 2010 to 14 in 2012 to 53 in 2014. APT targets are carefully selected, in contrast to traditional attacks that use any available corporate targets. The goal is to get in quietly and stay unnoticed for long periods of time, as seen in the famous APT attack that victimized the networking company Nortel. Chinese spyware was present on Nortel’s systems for almost ten years without being detected and drained the company of valuable intellectual property and other information. Now that’s persistent!

9. Laws and regulations try to play catch up

A number of cyber security laws are being considered in the U.S. including the National Cybersecurity Protection Act of 2014, which advocates the sharing of cybersecurity information with the private sector, provide technical assistance and incident response to companies and federal agencies.   Another one to note is the Federal Information Security Modernization Act of 2014 that is designed to better protect federal agencies from cyber-attacks. A third is the Border Patrol Agent Pay Reform Act of 2013 to recruit and retain cyber professionals who are in high demand. Additionally, there is the Cybersecurity Workforce Assessment Act, which aims to enhance the readiness, capacity, training, recruitment, and retention of the cybersecurity workforce. President Obama stated that wants a 30-day deadline for notices and a revised “Consumer Privacy Bill of Rights.”

One of the more interesting and intelligent recommendations came from the FDA, who issued guidelines for wireless medical device security to ensure hackers could not interfere with things such as implanted pacemakers and defibrillators. This notion was is part stimulated by worry about Dick Cheney’s pacemaker being hacked. In fact countermeasures were installed by on the device by Cheney’s surgeon. More regulation of health data and equipment is expected in 2015.

“Security — or the lack of it — will largely determine the success or failure of widespread adoption of internet-connected devices,” the FTC Commissioner recently shared in an article. The FTC also released a report entitled, “Privacy & Security in a Connected World.”

10. Hardware-based security may change the game

According to respected market researcher Gartner, all roads to the digital future lead through security. At this point, who can really argue with that statement? Manufacturers and service providers are seeing the seriousness of cyber-danger and are starting to integrate security at every connectivity level. Crypto element integrated circuits with hardware-based key storage are starting to be employed for that. Furthermore, these crypto elements are a kind of silver bullet given that they easily and instantly add the strongest type of security possible (i.e. protected hardware-based key storage) to IoT endpoints and embedded systems. This is a powerful concept whose fundamental value is only starting to be recognized.

IoT Node Chart 1

Crypto elements contain cryptographic engines to efficiently handle crypto functions such as hashing, sign-verify, ECDSA, key agreement (e.g.  ECDH), authentication (symmetric or asymmetric), encryption/decryption, message authentication coding (MAC), run crypto algorithms (e.g. elliptic curve cryptography, AES, SHA) and many other functions.

The hardware key storage plus crypto engine combination in a single device makes it simple, ultra-secure, tiny, and inexpensive to add robust security. Recent crypto element products offer ECDH for key agreement and ECDSA for authentication. Adding a device with both of these powerful capabilities to any system with a microprocessor that can run encryption algorithms (such as AES) brings all three pillars of security (confidentiality, data integrity and authentication) into play.

2014-Crypto-Security-at-our-Core-Atmel-Has-You-Covered

With security rising in significance as attack platforms increase in size and threats become more sophisticated, it is good to know that solutions are already available to ensure that digital systems are not only smart and connected, but robustly secured by hardware key storage. This could be the one of the biggest stories in security going forward.

Symmetric or asymmetric encryption, that is the question!


With the emergence of breaches and vulnerabilities, the need for hardware security has never been so paramount.


Confidentiality — one of the three foundational pillars of security, along with data integrity and authenticity — is created in a digital system via encryption and decryption. Encryption, of course, is scrambling a message in a certain way that only the intended party can descramble (i.e. decrypt) it and read it.

pillars

Throughout time, there have been a number of ways to encrypt and decrypt messages. Encryption was, in fact, used extensively by Julius Caesar, which led to the classic type of encryption aptly named, Caesar Cipher. The ancient Greeks beat Caesar to the punch, however. They used a device called a “Scytale,” which was a ribbon of leather or parchment that was wrapped around a rod of a diameter, of which only the sender and receiver were aware. The message was written on the wrapping and unfurled, then sent to the receiver who wrapped on on the rod of the same diameter in order to read it.

Skytale

 

Modern Encryption

Modern encryption is based on published and vetted digital algorithms, such as Advanced Encryption System (AES), Secure Hashing Algorithms (SHA) and Elliptic Curve Cryptography (ECC), among many others. Given that these algorithms are public and known to everyone, the security must come from something else — that thing is a secret cryptographic “key.” This fundamental principal was articulated in the 19th century by  Auguste Kerckhoffs, a Dutch linguist, cryptographer and professor.

Kerckhoffs’ principle states that a cryptosystem should be secure even if everything about the system, except the key, is public knowledge. In other words: “The key to encryption is the key.” Note that Kirchoffs advocated what is now commonly referred to as “open-source” for the algorithm. Point being, this open-source method is more secure than trying to keep an algorithm itself obscured (sometimes called security by obscurity). Because the algorithms are known, managing the secret keys becomes the most important task of a cryptographer. Now, let’s look at that.

kirchoff 1

Symmetric and Asymmetric

Managing the key during the encryption-decryption process can be done in two basic ways: symmetric and asymmetric. Symmetric encryption uses the identical key to both encrypt and decrypt the data. Symmetric key algorithms are much faster computationally than asymmetric algorithms because the encryption process is less complicated. That’s because there is less processing involved.

The length of the key size directly determines the strength of the security. The longer the key, the more computation it will take to crack the code given a particular algorithm. The table below highlights the NIST guidelines for key length for different algorithms with equivalent security levels.  You can see that Elliptic Curve Cryptography (ECC) is a very compact algorithm. It has a small software footprint, low hardware implementation costs, low bandwidth requirements, and high device performance. That is one of the main reasons that ECC-based asymmetric cryptographic processes, such as ECDSA and  ECDH, are now being widely adopted. The strength of the sophisticated mathematics of ECC are a great ally of all three pillars of security, especially encryption.

table

Not only is symmetric faster and simpler; furthermore, a shorter key length can be used since the keys are never made public as is the case with asymmetric (i.e. Public Key Infrastructure) encryption. The challenge, of course, with symmetric is that the keys must be kept secret on both the sender and receiver sides. So, distributing a shared key to both sides is a major security risk. Mechanisms that maintain the secrecy of the shared key are paramount. One method for doing this is called Symmetric Session Key Exchange.

Asymmetric encryption is different in that it uses two mathematically related keys (a public and private key pair) for data encryption and decryption.  That takes away the security risk of key sharing. However, asymmetric requires much more processing power. Unlike the public key, the private key is never exposed. A message that is encrypted by using a public key can only be decrypted by applying the same algorithm and using the matching private key.

A message that is encrypted by using the private key can only be decrypted by using the matching public key. This is sort of like mathematical magic. Some of the  trade offs of symmetric and asymmetric are summarized below.

Symmetric

  • Keys must be distributed in secret
  • If a key is compromised the attacker can decrypt any message and/or impersonate one of the parties
  • A network requires a large number of keys

Asymmetric

  • Around 1000 times slower than symmetric
  • Vulnerability to a “man-in-the-middle” attack, where the public key is intercepted and altered

Due to the time length associated with asymmetric, many real-world systems utilize combination of the two, where the secret key used in the symmetric encryption is itself encrypted with asymmetric encryption, and sent over an insecure channel.Then, the rest of the data is encrypted using symmetric encryption and sent over the insecure channel in the encrypted format. The receiver gets the asymmetrically encrypted key and decrypts it with his private key. Once the receiver has the symmetric key, it can be used to decrypt the symmetrically encrypted message. This is a type of key exchange.

Note that the man in the middle vulnerability can be easily addressed by employing the other pillar of security; namely authentication. Crypto engine devices with hardware key storage, most notably Atmel’s CrypotoAuthentication, have been designed specifically to address all three pillars of security in an easy to design and cost-effective manner. Ready to secure your next design? Get started here.

What is Ambient Security?

New technology and business buzzwords pop up constantly. Hardly a day goes by that you don’t see or hear words such as “cloud”, “IoT,” or “big data.” Let’s add one more to the list: “Ambient security.”

Ambient 1

You’ll notice that big data, the cloud, and the IoT are all connected, literally and figuratively, and that is the point. Billions of things will communicate with each other without human intervention, mainly through the cloud, and will be used to collect phenomenal and unprecedented amounts of data that will ultimately change the universe.

As everything gets connected, each and every thing will also need to be secure. Without security, there is no way to trust that the things are who they say they are (i.e. authentic), and that the data has not been altered (i.e. data integrity). Due to the drive for bigger data, the cloud and smart communicating things are becoming ambient; and, because those things all require security, security itself is becoming ambient as well.  Fortunately, there is a method to easily spread strong security to all the nodes. (Hint: Atmel CryptoAuthentication.)

Big Data

At the moment, big data can be described as the use of inductive statistics and nonlinear system analysis on large amounts of low density (or quickly changing) data to determine correlations, regressions, and causal effects that were not previously possible. Increases in network size, bandwidth, and computing power are among the things enabling this data to get bigger — and this is happening at an exponential rate.

Big data became possible when the PC browser-based Internet first appeared, which paved the way for data being transferred around the globe. The sharp rise in data traffic was driven to a large extent by social media and companies’ desire to track purchasing and browsing habits to find ways to micro-target purchasers. This is the digitally-profiled world that Google, Amazon, Facebook, and other super-disruptors foisted upon us.  Like it or not, we are all being profiled, all the time, and are each complicit in that process. The march to bigger data continues despite the loss of privacy and is, in fact, driving a downfall in privacy. (Yet that’s a topic for another article.)

Biggering

The smart mobile revolution created the next stage of “biggering” (in the parlance of Dr. Seuss). Cell phones metamorphosed from a hybrid of old-fashioned wired telephones and walkie-talkies into full blown hand-held computers, thus releasing herds of new data into the wild. Big data hunters can thank Apple and the Android army for fueling that, with help from the artists formerly known as Nokia, Blackberry, and Motorola. Mobile data has been exploding due to its incredible convenience, utility, and of course, enjoyment factors. Now, the drive for bigger data is continuing beyond humans and into the autonomous realm with the advent of the Internet of Things (IoT).

biggering 1

Bigger Data, Little Things

IoT is clearly looking like the next big thing, which means the next big thing will be literally little things. Those things will be billions of communicating sensors spread across the world like smart dust — dust that talks to the “cloud.”

big data

More Data

The availability of endless data and the capability to effectively process it is creating a snowball effect where big data companies want to collect more data about more things, ad infinitum. You can almost hear chanting in the background: “More data… more data… more data…”

More data means many more potential correlations, and thus more insight to help make profits and propel the missions of non-profit organizations, governments, and other institutions. Big data creates its own appetite, and the data to satisfy that growing appetite will derive from literally everywhere via sensors tied to the Internet. This has already started.

Sensors manufacture data. That is their sole purpose. But, they need a life support system including smarts (i.e. controllers) and communications (such as Wi-Fi, Bluetooth and others). There is one more critical part of that: Security.

No Trust? No IoT! 

There’s no way to create a useful communicating sensor network without node security. To put it a different way, the value of the IoT depends directly on whether those nodes can be trusted. No trust. No IoT.  Without security, the Internet of Things is just a toy.

What exactly is security? It can best be defined by using the three-pillar model, which (ironically) can be referred to as “C.I.A:” Confidentiality, Integrity and Authenticity.

pillars

CIA

Confidentiality is ensuring that no one can read the message except its intended receiver. This is typically accomplished through encryption and decryption, which hides the message from all parties but the sender and receiver.

Integrity, which is also known as data integrity, is assuring that the received message was not altered. This is done using cryptographic functions. For symmetric, this is typically done by hashing the data with a secret key and sending the resulting MAC with the data to the other side which does the same functions to create the MAC and compare. Sign-verify is the way that asymmetric mechanisms ensure integrity.

Authenticity refers to verification that the sender of a message is who they say they are — in other words, ensuring that the sender is real. Symmetric authentication mechanisms are usually done with a challenge (often a random number) that are sent to the other side, which is hashed with a secret key to create a MAC response, before getting sent back to run the same calculations. These are then compared to the response MACs from both sides.

(Sometimes people add non-repudiation to the list of pillars, which is preventing the sender from later denying that they sent the message in the first place.)

The pillars of security can be  implemented with devices such as Atmel CryptoAuthentication crypto engines with secure key storage. These tiny devices are designed to make it easy to add robust security to lots of little things – -and big things, too.

So, don’t ever lose sight of the fact that big data, little things and cloud-based IoT are not even possible without ambient security. Creating ambient security is what CryptoAuthentication is all about.

Tutorial: Building cool projects with MCUs (Part 5)

I finally received the circuit boards! And, in this fifth and final part of the microcontroller tutorial, we are going to solder the components to the circuit board and program the MCU using the USB port of a computer.

Just to refresh our memories, so far we have learned:

Microcontroller PCB

I recently ordered the PCBs from Seeed Studio. In order to expedite their delivery, I used a more expensive shipping option from UPS. I did get the boards pretty fast – but I also got an unexpected bill from them because they had to take it through customs.

So, even though the boards were only $10, I ended up with paying about $60 in shipping and customs… But luckily, there exists a much cheaper shipping option (about $3-4) – you just have to wait a little bit longer for the boards to arrive.

Let’s solder the board!

I wanted to make this circuit in such a way that it was possible to make it at home. To solder the circuit, I’m going to use my old Ersa soldering iron and some standard solder wire. The tip of the iron is a bit thick, so it’s really not ideal for this job. However, I know many people only have a simple soldering iron like this lying around the house – so it’s the perfect test to see if this is something that anyone can build from the comfort of your home.

Ersa30 Soldering Iron

The first thing we’re going to solder is the MCU chip. This is also the hardest part to solder. I have to admit – when I looked at my soldering iron, then looked at the chip – I was a bit worried that it was going to be hard. But the main trick here was to be patient!

To solder the surface mount components, we can use the techniques described in this smd soldering article.

First, we solder one corner pin of the chip. When we have managed to solder this one pin correctly – and all the pins are aligned over their pads – we move on to the corner on the other side. With two corners soldered properly, all we need to do is to add a tiny bit of solder to all the other pins and pads.

MCU chip soldered

Don’t rush it. Take your time. Inspect the pins closely to see if they are soldered and that they don’t have a “solder bridges” to their neighbors. And, don’t worry if it looks a bit like a war-zone with solder all over – just look at mine above – it still works!

Now, safe to say that the worst part is over. The other components are pretty straightforward to solder. Just make sure the LED and the polarized capacitor is placed in the correct direction.

Microcontroller circuit board

Programming the circuit

Once we are confident that the components are soldered properly, it’s time to test it! First, we need to check if the USB interface works. Otherwise, we won’t be able to program the circuit. To test the USB interface, all we need to do is to connect a USB cable and connect the circuit to our computer. From there, we can just check if it pops up as a USB device on the computer.

And… it does!

So, let’s program the MCU. A simple way of testing it is to make an LED-blink program. This is a simple program that, well, makes our LED blink. It looks like this:

#define F_CPU 1000000 // The chip runs at 1 MHz as default (even if you are using a 8MHz crystal)

#include
#include

int main(void)
{
DDRC = (1<<PC7); //Sets the direction of the PC7 to output
PORTC = (1<<PC7); //Sets PC7 high

while(1)
{
_delay_ms(500); //Wait 500 milliseconds
PORTC &= ~(1<<PC7); //Turn LED off

_delay_ms(500); //Wait 500 milliseconds
PORTC |= (1<<PC7); //Turn LED on
}

return 0;
}

We save this code in a file called led-blink.c

Compiling our code

The first thing we need to do is to compile our code into machine code that the MCU can read. One way of doing this is through Atmel Studio. But, since I am a big fan of using the Linux terminal, I’ll show you how to compile and upload a program using Ubuntu.

First, install avr-gcc with the command:

sudo apt-get install avr-gcc

Then, compile the code and make it into the right format with the following commands:

avr-gcc -mmcu=atmega32u2 -Os blink-led.c -o blink-led.out
avr-objcopy -j .text -j .data -O ihex blink-led.out blink-led.hex

The resulting file – blink-led.hex – can now be uploaded to the microcontroller. You can find more information on the commands here.

Uploading the code to the MCU

Time to upload the program and see if it works. One way to do this is by using Atmel’s FLIP software. But, once again, let’s see how we can do it with the Linux terminal.

Install dfu-programmer with the command:

sudo apt-get install dfu-programmer

Then, erase the old flash memory on the MCU and upload the compiled .hex file:

sudo dfu-programmer atmega32u2 erase
sudo dfu-programmer atmega32u2 flash blink-led.hex

Unplug the circuit from your computer, then plug it in again. And what do you know, the LED starts to blink!

Blink LED microcontroller circuit

Making something cool

Now that we’ve got it working, we’re ready to make something cool. There are so many cool things you can make with a microcontroller. For example, you can connect it to this Wi-Fi module and make the LED blink every time @AtmelMakes posts a new tweet.

Or, how about connecting it to this sound module and this motion sensor, and make it play a Christmas song every time someone goes near your Christmas tree? As Atmel always says, the possibilities are truly endless.

If you missed any of the previous parts of this tutorial – you can find them here:

Getting up close and personal with symmetric session key exchange

In today’s world, the three pillars of security are confidentiality, integrity (of the data), and authentication (i.e. “C.I.A.”). Fortunately, Atmel CryptoAuthentication crypto engines with secure key storage can be used in systems to provide all three of these.

Corinthium column in antique town Jerash

Focusing on the confidentiality pillar, in a symmetric system it is advantageous to have the encryption and decryption key shared on each side go through a change for every encryption/decryption session. This process, which is called symmetric session key exchange, helps to provide a higher level of security. Makes sense, right?
 nsa 1

So, let’s look at how to use the capabilities of the ATSHA204A CryptoAuthentication device to create exactly such a changing cryptographic key. The way a key can be changed with each session is by the use of a new (and unique) random number for each session that gets hashed with a stored secret key (number 1 in the diagram below). While the stored key in the ATSHA204A devices never changes, the key used in each session (the session key) does. Meaning, no two sessions are alike by definition.

The video below will walk you through the steps, or you can simply look at the diagram which breaks down the process.

The session key created by the hashing of the stored key and random number gets sent to the MCU (number 2) and used as the AES encryption key by the MCU to encrypt the data (number 3) using the AES algorithm. The encrypted data and the random number are then sent (number 4) to the other side.

session key exchange r0

Let’s explore a few more details before going on. The session key is a 32 byte Message Authentication Code or “MAC.” (A MAC is defined as a hash of a key and message.) 16 bytes of that 32 byte (256 bit) MAC becomes the AES session key that gets sent to the MCU to run the AES encryption algorithm over the data that is to be encrypted.

It is obvious why the encrypted code is sent, but why is the random number as well? That is the magic of this process. The random number is used to recreate the session key by running the random number through the same SHA-256 hashing algorithm together with the key stored on the decryption side’s ATSHA204A (number 5). Because this is a symmetric operation, the secret keys stored on both of the ATSHA204A devices are identical, so when the same random number is hashed with the same secret key using the same algorithm, the 32 byte digest that results will be exactly the same on the decrypting side and on the encrypting side. Just like on the encrypting side, only 16 bytes of that hash value (i.e. the MAC) are needed to represent the AES encryption/decryption key (number 6). At this point these 16 bytes can be used on the receiving side’s MCU to decrypt the message(number 7).

And, that’s it!

sha 204

Note how easy the ATSHA204A makes this process because it stores the key, generates the random number, and creates the digest. There’s a reason why we call it a crypto engine! It does the heavy cryptographic work, yet is simple to configure the SHA204A using Atmel’s wide range of tools.

Not to mention, the devices are tiny, low-power, cost-effective, work with any micro, and most of all, store the keys in ultra-secure hardware for robust security. By offering easy-to-use, highly-secure hardware key storage crypto engines, it’s simple to see how Atmel has you covered.

Tinusaur dev board packs an ATtiny85 MCU

The Tinusaur — powered by an ATtiny85 MCU — is a simple, inexpensive and quick-start platform targeted at both Makers and developers alike.

“The Tinusaur is a minimal microcontroller hardware configuration based on Atmel’s AVR ATtiny family of products, and more specifically, those with DIP-8 case such as ATtiny25/ATtiny45/ATtiny85, ATtiny13 as well as their variations,” project creator Neven Boyanov explained in a recent Hackster.io post.

Aside from the ATtiny85, additional key platform specs include:

  • DIP-8 socket
  • H1 header
  • H2 header
  • 
ISP header
  • 
Reset button
  • Power header
  • Battery header
  • Battery jumper
  • C1 capacitor
  • C2 capacitor
  • C2 capacitor
  • R1 resistor
  • 
Battery holder
  • 3V battery

“All the components are easy to find, and of course, cheap. Only the minimum required components should be part of the circuit.”

In addition, the two-row headers H1 and H2 can be used as a breadboard, or to facilitate the placement of a shield. Tinusaur also includes an optional mount for a button cell battery on the bottom and a jumper to toggle the unit on or off.

On the software side, the board offers cross-platform support, as well as compatibility with the official Arduino IDE.

20140618_150209_tinusaur_board_36_c640x640

According to Boyanov, the goal of the Tinusaur project is to offer a simple, cheap and accessible quick-start platform for everyone interested in learning and making things. Sound like you? You can check out the project’s official page and its Hackster.io post here.

How far can you take the ATtiny10?



Atmel’s stalwart tinyAVR lineup has been a Maker favorite for years, with the microcontrollers powering a wide-range of devices and platforms.

c57b1f48465b91ffda007158d190b710

Recently, a Maker by the name of Tim (aka cpldcpu) decided to find out just how far he could take the versatile ATtiny10 with his µ-Wire project.

“I previously used the ATtiny10 in the TinyTouchbutton, a touchbutton controlled light with WS2812 LEDs. This time I aimed higher: Is it possible to turn the ATtiny10 into a USB compatible device?” Tim wrote in a recent blog post.

“My goal was to implement a subset of the little-wire functionality to control a WS2812 LED by USB. This takes 3 I/O lines, which is exactly the number of free pins on the ATtiny10.”

As Tim notes, little-wire supports a number of functions to control WS2812 LEDs on arbitrary I/O ports. However, he simplified this approach by only supporting a single LED on a specific pin, while still retaining protocol compatibility. Meaning, all the little-wire host programs were still functional, with the finished device fully capable of being used as an RGB indicator LED similar to the Blink1.

“The V-USB USB interface requires more than 1.5kb of flash in its smallest implementation and uses more than 50 bytes of RAM, including stack usage,” he explained. 

”Additional code is required to implement the little-wire interface and to write to the WS2812. The ATtiny10 has 1kb of flash, 32 bytes of SRAM and 16 instead of 32 registers. So this ended up as a nice exercise in cutting down V-USB to its bare essentials – and further.”

One critical step towards reducing the memory footprint, Tim admits, was adopting an interrupt-free implementation of V-USB, as developed for micronucleus. This allowed him to lower the SRAM footprint by omitting register saving on the stack and avoiding double buffering — all while facilitating the reduction of program size.

Further measures to reduce code size include clocking the controller at 12 MHz (using the internal RC oscillator), manually remapping numerous registers in V-USB to avoid collisions with the GCC, removing all handling of the reset signal on the USB-Bus and altering the code to support replies from the SRAM.

Final stats?

  • 

Flash: 988 of 1024 bytes used (96.4%)
  • SRAM: 28 (variables)+2 (stack) of 32 bytes used (93.8%)

“This is most likely the most complex firmware ever loaded into an ATtiny10,” Tim added. “[Plus], it also works with the new 8mm WS2812 LEDs.”

Interested in learning more? You can check out the relevant files on Github, as well as read Tim’s detailed blog post here.

Kaivan Karimi talks IoT building blocks with Design World

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AK: What role do microcontrollers play in this market?

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

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

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

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

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

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

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

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

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

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

IoT_Campaign_Google+_Final_Master_1080x608_Final

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

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

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

Don’t be an “ID-IoT”


Authentication may just be the “sine qua non” of the Internet of Things. 


Let’s just come out and say it: Not using the most robust security to protect your digital ID, passwords, secret keys and other important items is a really, really bad idea. That is particularly true with the coming explosion of the Internet of Things (IoT).

Hacker

The identity (i.e. “ID”) of an IoT node must be authenticated and trusted if the IoT is ever to become widely adopted. Simply stated, the IoT without authenticated ID is just not smart. This is what we mean when we say don’t be an ID-IoT.

It seems that every day new and increasingly dangerous viruses are infecting digital systems. Viruses — such as Heartbleed, Shellshock, Poodle, and Bad USB — have put innocent people at risk in 2014 and beyond. A perfect case in point is that Russian Cyber gangs (a.k.a. “CyberVor”) have exposed over a billion user passwords and IDs — so far. What’s scary is that the attacks are targeted at the very security mechanisms that are meant to provide protection.

If you think about it, that is somewhat analogous to how the HIV/AIDS virus attacks the very immune system that is supposed to protect the host organism. Because the digital protection mechanisms themselves have become targets, they must be hardened. This has become increasingly important now that the digital universe is going through its own Big Bang with the explosion of the IoT. This trend of constant connectivity will result in billions of little sensing and communicating processors being distributed over the earth, like dust. According to Gartner, processing, communicating and sensing semiconductors (which comprise the IoT) will grow at a rate of over 36% in 2015, dwarfing the overall semiconductor market growth of 5.7%. Big Bang. Big growth. Big opportunity.

The IoT will multiply the number of points for infection that hackers can attack by many orders of magnitude. It is not hard to see that trust in the data communicated via an ubiquitous (and nosey) IoT will be necessary for it to be widely adopted. Without trust, the IoT will fail to launch. It’s as simple as that. In fact, the recognized inventor of the Internet, Vint Cerf, completely agrees saying that the Internet of Things requires strong authentication. In other words, no security? No IoT for you!

BxLpafwIcAAMcG0

There is much more to the story behind why the IoT needs strong security. Because the world has become hyper-connected, financial and other sensitive transactions have become almost exclusively electronic. For example, physical checks don’t need to be collected and cancelled any more — just a scanned electronic picture does the job. Indeed, the September 11th terror attacks on the U.S. that froze air travel and the delivery of paper checks accelerated the move to using images to clear checks to keep the economy moving.

Money now is simply electronic data, so everyone and every company are at risk of financial losses stemming directly from data breaches. See?  Data banks are where the money is now kept, so data is what criminals attack. While breaches are, in fact, being publicized, there has not been much open talk about their leading to significant corporate financial liability. That liability, however, is real and growing. CEOs should not be the least bit surprised when they start to be challenged by significant shareholder and class action lawsuits stemming from security breaches.

lawsuits

Although inadvertent, companies are exposing identities and sensitive financial information of millions of customers, and unfortunately, may not be taking all the necessary measures to ensure the security and safety of their products, data, and systems. Both exposure of personal data and risk of product cloning can translate to financial damages. Damages translate to legal action.

The logic of tort and securities lawyers is that if proven methods to secure against hacking and cloning already exist, then it is the fiduciary duty of the leaders of corporations (i.e. the C-suite occupants) to embrace such protection mechanisms (like hardware-based key storage), and more importantly, not doing so could possibly be argued as being negligent. Agree or not, that line of argumentation is viable, logical, and likely.

A few CEOs have already started to equip their systems and products with strong hardware-based security devices… but they are doing it quietly and not telling their competitors. This also gives them a competitive edge, besides protecting against litigation.

Software, Hardware, and Hackers

hacker_inside_intel

Why is it that hackers are able to penetrate systems and steal passwords, digital IDs, intellectual property, financial data, and other secrets? It’s because until now, only software has been used to protect software from hackers. Hackers love software. It is where they live.

Rogue

The problem is that rogue software can see into system memory, so it is not a great place to store important things such as passwords, digital IDs, security keys, and other valuable things. The bottom line is that all software is vulnerable because software has bugs despite the best efforts of developers to eliminate them. So, what about storing important things in hardware?

Hardware is better, but standard integrated circuits can be physically probed to read what is on the circuit. Also, power analysis can quickly extract secrets from hardware. Fortunately, there is something that can be done.

Several generations of hardware key storage devices have already been deployed to protect keys with physical barriers and cryptographic countermeasures that ward off even the most aggressive attacks. Once keys are securely locked away in protected hardware, attackers cannot see them and they cannot attack what they cannot see. Secure hardware key storage devices — most notably Atmel CryptoAuthentication — employ both cryptographic algorithms and a tamper-hardened hardware boundary to keep attackers from getting at the cryptographic keys and other sensitive data.

tamper

The basic idea behind such protection is that cryptographic security depends on how securely the cryptographic keys are stored. But, of course it is of no use if the keys are simply locked away. There needs to be a mechanism to use the keys without exposing them — that is the other part of the CryptoAuthentication equation, namely crypto engines that run cryptographic processes and algorithms. A simple way to access the secret key without exposing it is by using challenges (usually random numbers), secret keys, and cryptographic algorithms to create unique and irreversible signatures that provide security without anyone being able to see the protected secret key.

Crypto engines make running complex mathematical functions easy while at the same time keeping secret keys secret inside robust, protected hardware. The hardware key storage + crypto engine combination is the formula to keeping secrets, while being easy-to-use, available, ultra-secure, tiny, and inexpensive.

hash

While the engineering that goes into hardware-based security is sophisticated, Atmel does all the crypto engineering so there is no need to become a crypto expert. Get started by entering for your chance to take home a free CryptoAuthentication development tool.

Tutorial: Building cool projects with MCUs (Part 3)

As we proceed onto the third portion of this microcontroller tutorial, let’s first revisit what we have accomplished thus far.

In Part 1, we defined what a microcontroller actually was. I wanted to get everybody on-board (no pun intended) for this, so I started from scratch. Feel free to jump back there if you need a refresher.

Then in Part 2, we looked at the various types of MCUs. And, it turns out that there were a lot! However, by using Atmel’s selection tool, we managed to narrow it down to a few different ones, before choosing a winner — an ATmega32U2. Why? Mainly because it can be programmed through the USB interface without any extra components or tools, and since it did not have too many pins – so we should be able to solder it at home.

Now, the time has come for us to design the circuit diagram. We’ll start with outlining what we need, then we’ll dive into the datasheet to figure out exactly how we can do this.

Microcontroller in a circuit

What Components Do We Need?

If you’ve never done it before, putting all the necessary components onto the circuit diagram is not a super easy task. Well, the process is not that hard; but until you know how to do it, it will seem a bit difficult. So, let me take you through my thought process:

We need to power the chip somehow. There are some pins on the microcontroller that need power. We have to figure out which pins that need power, and what voltage they need.

We also want to program the chip trough USB, so we need a USB connector and learn how to connect it to the chip.

Then, there is extra stuff. Like maybe an LED to play around with, and definitely some connection pins that we can connect other stuff to later when we want to experiment.

So, we need to figure out:

  • How to power the circuit
  • How to connect the USB part
  • How to connect pins to the chip

Using the Datasheet to Find the Details of Our Circuit

The datasheet for the ATmega32U2 is a must when we are designing our circuit. Here, we can find all the necessary technical details.

We don’t have to read it from beginning to end; instead, we simply look up the parts we are curious about, and study them in more depth. We can find a table of contents at the end of the document.

For instance, if we wanted to use the timer of the MCU, we’d look up the part about timers. If we wanted to use the SPI communication part, we would look that up.

Connecting Power and USB

As you probably know, USB devices can be powered through, well, USB. By doing this, we simplify our circuit and require less components. So, let’s do this.

To figure out exactly HOW we can do this, we’re going to read the datasheet. By going to the table of contents, we find that the section that describes the USB part of the microcontroller is on page 186.

Here, there are different images showing how to connect the USB connector to the microcontroller to make it a USB powered device. For our circuit, we’ll use the bus-powered 5V version:

How to setup the MCU as a USB-powered device

Under Design Guidelines on page 189, we find the exact values we need for the resistors. It’s also there that we learn it’s highly recommended to use a 10µF capacitor on the VBUS, so let’s add that too.

Adding a Crystal

Another interesting thing to note from the image of how to connect the USB, is that there is also a crystal and a couple of capacitors connected to the XTAL1 and XTAL2 pins. This gives us the idea that we probably need a crystal too. But why?

Microcontrollers rely on clock signals to work. Every time the clock signal gives a pulse, something will happen in the processor. Most MCUs come with an internal RC-oscillator that can create this clock signal; however, the USB part of the microcontroller cannot operate from this internal clock — it needs a crystal oscillator to work.

To create a crystal oscillator, we need to connect a crystal and two capacitors to XTAL1 and XTAL2. By looking up “Crystal Oscillator” in the datasheet on page 36, we can also identify exactly what crystal and which capacitors are required.

Connecting an LED And Some Pins

By now, we have everything we need for the microcontroller circuit to work. But, we won’t be able to have much fun with it if we don’t add some connections to the input and output pins. And, it’s also good to add an LED. Everything gets better with an LED!

The LED needs to be connected through a resistor. We call this a current limiting resistor — this is to control the amount of current going through it.

From there, we will need a few physical pins that we can use to connect other stuff to our circuit. There are 22 I/O pins on the ATmega32U2, yet some of the pins are used for other purposes (like XTAL2), so we can’t use them all. For this circuit, we’ll add 16 I/O pins, as it’s a nice and round number.

What Else Do We Need?

On MCU circuits, it’s very common to include a RESET button. This makes it possible to reset the MCU without removing the power connection. This will add a couple of more components to our circuit and isn’t necessary to make it work, but it’s very handy, so let’s add it.

In the datasheet, we can see that pin 24 on the chip is the reset signal. It has a line over itself, which means that it’s activated when pulled low.

To make the reset signal stay in a high-state when the button is not pushed, we’ll add a pull-up resistor. This is a resistor up to VCC. And, we connect the button so that it will pull the reset-pin to ground when pushed.

The pull-up resistor should have a value of around 10k Ohm. For reference, SparkFun has a good article on how to choose a pull-up value.

Our Microcontroller Circuit Diagram

Now that we have figured out the different pieces of the circuit, it’s time to put them all into one circuit diagram. By adding everything into one circuit diagram, we end up with this:

Complete microcontroller circuit

Next, we need to create a circuit board out of this. Creating a circuit board does not have to be very complicated. In the subsequent part of the microcontroller tutorial series, we’ll design and make the circuit board.

Stay tuned for Parts 4-5 in the coming days…