You can’t spell “cryptography” without a “why”

When considering adding cryptography to an embedded system (or any other information system) manufacturers always ask: “Why do I need cryptography?” That is, unless they have already been burned by a security breach. The answer is quite simple: “Because you have a lot to lose and the dangers are multiplying every day.”

Perhaps some of the closest analogies are driving without auto insurance, owning a house without fire and casualty insurance, living without health insurance…well, you get the picture. The point is, intentionally leaving an embedded system exposed to hacking, malware and cloning to save cost is simply not prudent from a financial perspective. Of course, safety, liability and brand equity also matter – a lot.

Cutting to the chase, dangerous exposure is directly linked to how exposed the cryptography key is to being accessed by unintended parties such as hackers and cyber-criminals. This has to do with how the key is stored. However, before we explore this topic, let’s look at the bigger picture.

The answer to “why” for product manufacturers? They need to protect their development investment, brand image and revenue in an increasingly hostile cyber-world replete with bad actors. As we noted in a previous article, the number of active Internet threat groups being tracked has risen to over 300, which is more than 400% higher than in 2011.  Nation-states have become hyper-active in cyber-espionage and cyber-attacks. This is because it is now possible to literally upload damage to a target, which is kind of a science fiction scenario come true.

In the same vein, secret information is easily downloaded. More than 95% of networks have become compromised in some way, and directed attacks will only get worse as mobile platforms continue to expand worldwide.

Vulnerable systems placed on the Internet are currently being compromised in less than 15 minutes. Frankly, these statistics aren’t really a surprise given the wildly disproportionate cost / ”benefit” of cyber meddling, which is devilishly tempting to malicious operators.

It is clear from the above statistics that hostilities have already broken out and cryptography is the best available shield—perhaps the only one.

Now that we have looked at the “why” in cryptography, what about the “what?” What is cryptography? Let’s focus on the two pillars of cryptography, which are described below:

      1. Authentication  

•   Making sure the data source is what it is supposed to be.

      2.  Encryption/decryption

•   Scrambling and descrambling data so only an intended receiver can see it.

Both encryption and authentication are contingent upon keeping secret keys secret. This is the key point.

However, there are many different encryption algorithms, types of authentication schemes, architectures and applications. There is also the choice of how to store the encryption keys. The last point – key storage – is probably the most significant consideration manufacturers can make regarding security.

In essence, cryptographic security is a function of three critical factors:

1. The length of the key used by the cryptographic algorithms,
2. The mathematical operations of the cryptographic algorithms, and
3. How securely the keys are stored (i.e. how vulnerable the keys are to attack).

Since the strength of security depends upon the key size and the specific mathematical properties of the algorithms, various combinations of key sizes and algorithms can potentially be stronger or weaker than any other combination. Meaning, manufacturers have to select one and the other according to their requirements. However, if the keys are not securely stored, well, then none of it matters all that much.

If the keys are not kept secret, then the information can be obtained by unintended outside parties, which defeats the entire purpose. Right? As such, the memory where the key is stored must be able to withstand attacks that try to read the key(s). Such attacks are always underway somewhere, which is a sad but true fact. Fortunately, hardware security devices, like Atmel CryptoAuthentication products, offer a proven method of protecting secret keys that not only restricts access, but also provides key generation and management.

Similarly, storing keys in general purpose (i.e. unsecured) memory in any system leaves the keys open to theft or authorized use via multiple paths. By definition, any system’s software must have access to memory, so any type of bug in the software can inadvertently reveal the key. Just look at the Heartbleed bug as an example. Specialty hardware devices, like CryptoAutentication products are designed for the express purpose of securely storing hardware keys. They do this by utilizing special defense mechanisms that only hardware can provide to repel attacks of various types.

As we’ve previously discussed on Bits & Pieces, secure storage in hardware beats general purpose storage every time. So, the “why” and “what” of cryptography boils down to this: Adding secure key storage is an inexpensive, easy, and ultra-secure way to protect firmware, software and hardware products from cloning, counterfeiting, hacking and other malicious threats.

The key to security is protecting the key. Plus, hard protection beats soft protection. It is that simple. This is precisely why Atmel’s ATSHA204A, ATECC108A and ATAES132 are all designed for secure authentication by providing a hardware-based storage location with a range of proven physical defense mechanisms, as well as secure cryptographic algorithms and processes. They represent over three generation of hardware security know-how, and experience matters when dealing with real world attacks.

Future Bits & Pieces posts will examine authentication schemes such as asymmetric and symmetric, and how Atmel key storage devices operate in the real world.

Hardware key storage stops the bleeding

The Heartbleed security bug is a really big deal, especially given today’s hyper-connected, information obsessed society. This nasty bug, which has been characterized as “catastrophic” by industry gurus, permits anyone on the Internet to access the memory of systems using various versions of OpenSSL software. This is ironic since that very software was specifically designed to protect data.

Nevertheless, Heartbleed exposes secret keys used for authentication and encryption, which are the two primary foundations of how security is generally ensured. By exposing keys Heartbleed thus exposes actual data, user names, and user passwords to anyone. This is virtually everything. Ouch!   Attackers (i.e. hackers, cybercriminals, spies, state-sponsored electronic armies, and others with malevolent intent) can observe and steal data without a trace, which is virtually the literal industry definition of the term “man-in-the-middle” attack.

The threat that Heartbleed represents has rightly gained widespread attention. Fortunately, such attention has stimulated a major market reaction and lead to whole scale changing of user passwords, proliferation of patches, and other fixes. It has also brought the need for more extensive code testing into the open. Heartbleed and other major security revelations are making people look at security much more seriously, which also extends to embedded systems.

Frankly, it is about time. Embedded system insecurity gained major notoriety recently with the revelation that commercial WiFi routers have old and buggy firmware that can be used as a back door into home and commercial networks. Such loopholes were in fact used by a criminal organization in Eastern Europe to steal cash. The risk was amplified by the revelation that mischievous “agencies” tasked with collecting and processing information without permission can exploit the vulnerabilities at will.

Embedded system firmware insecurity affects individuals, institutions, governments, and corporations—which is pretty much everyone. Highly respected market researchers have noted that bad behavior and bad actors are running rampant. For example, the number of active threat groups being tracked has risen to over 300, which is more than 400% higher than in 2011. Nation-states have become hyper-active in cyber-espionage and hacking. This is because it is now possible to literally upload damage to a target, which is kind of a science fiction scenario come true.

In the same vein, secret information is easily downloaded, especially with security vulnerabilities from Heartbleed, router back-doors, and others. More than 95% of networks have become compromised in some way, and directed attacks will only get worse as mobile platforms continue to expand worldwide. An unnerving figure is that vulnerable systems placed on the Internet are being compromised now in less than 15 minutes. That is not really a surprise given the wildly disproportionate cost / ”benefit” of cyber meddling, which is devilishly tempting to malicious operators.

The security situation is extremely complicated for embedded systems because embedded firmware is highly fragmented, difficult to update, hard to track, often obsolete, hard to access, and employs a wide range of processors and code languages. The router loopholes mentioned above are in fact a direct expression of the vulnerabilities endemic to embedded systems and the severe damage those vulnerabilities can cause downstream. It is now clear that embedded system vulnerabilities affect everyone. So, the question becomes, “What can be done to increase security in embedded systems?”

As Heartbleed and cyber attacks have illustrated, encryption and authentication keys must be protected. There is no other option. Cryptography may be mathematically and systematically ultra-detailed and uber-complicated, but the most important and fundamental security concept is beyond simple: namely, “Keep the secret keys secret.”  The best way to do that is to lock the secret keys in protected hardware devices.

Hardware key storage beats software key storage every time, which is one of the “key” lessons of the recent vulnerability revelations. But how does an embedded system manufacturer ensure their products are secure and protected from attack? Fortunately, the solution is simple, available, and cost effective, and that is to use hardware key storage devices such as Atmel’s ATSHA204A, ATECC108A  and ATAES132.

These products are all designed to secure authentication by providing a hardware-based storage location with an impressive range of proven physical defense mechanisms, as well as secure cryptographic algorithms and processes. Go to the links above for more details or the introduction page CryptoAuthentication.

Future Bits & Pieces posts will describe the different types of authentication and the various steps that the devices and associated processors implement.

Atmel’s SAM4L ARM Cortex-M4 MCU saves power with FreeRTOS tick suppression

FreeRTOS can best be described as a popular real-time operating system for embedded devices, including Atmel’s SAM4L ARM Cortex-M4 MCU (microcontroller). The real-time operating system is succinct, as it consists of three or four C files, and is written primarily in the same language.

So why use an RTOS? Well, a real-time operating system for embedded devices offers a wide variety of benefits, including an optimized design with cleaner interfaces, the ability to reuse code and the opportunity to benefit from low-power operation.

Applications coded to take advantage of an RTOS are designated as a set of of autonomous, communicating threads of execution. Specifically, in FreeRTOS each thread of execution is known as a task, with each typically spending varying degrees of time waiting for an event.

As Richard Barry of FreeRTOS explains, a task may have to wait for an interrupt, a time period to expire, or a message from another task.

“In FreeRTOS a task that is waiting for something to happen is said to be in the blocked state. An RTOS scheduler will not run a task that is in the blocked state. When all the tasks that were created by the application are in the blocked state the RTOS scheduler will run a task called the idle task, which is created by the RTOS itself,” Barry wrote in a recent blog post published on EE Times Embedded.

“An RTOS therefore provides a very convenient and automatic way of knowing when the application is idle, and therefore when the microcontroller on which the application is running can be placed into a low-power state.”

Indeed, FreeRTOS allows an app writer to add their own into the idle task via the definition of an idle task callback or hook function. It is therefore quite common to reduce the power consumed by the microcontroller on which FreeRTOS is running by exploiting the idle task callback to switch the microcontroller into a low power state.

However, the resulting power saving achieved by the above-mentioned method is limited if the RTOS requires a periodic exit of the low power state to process tick interrupts (periodic interrupts used by an RTOS to track time). Meaning, any energy savings will be outweighed if the frequency of the tick interrupt is excessive – for all but the lightest power saving modes.

Enter the FreeRTOS tickless idle mode, which halts (or suppresses) the periodic tick interrupt when the idle task is executing, subsequently making a correcting adjustment to the time maintained by the RTOS when the tick interrupt is restarted. This allows the microcontroller to remain in a deep power saving state until an interrupt occurs or the RTOS kernel transitions a task out of the blocked state.

“There is a run-time overhead associated with suppressing the tick interrupt: the peripheral used to generate the periodic tick must be reprogrammed before entering the low-power state, and again when exiting the low power state,” said Barry.

“For this reason, and to ensure correct processor time sharing between tasks of equal priority, the tick interrupt is not suppressed unless all the application tasks are in the blocked state.”

The tick suppression feature supported by FreeRTOS can perhaps be best illustrated by Atmel’s SAM4L ARM Cortex-M4 microcontroller, which is specifically designed for low power applications.

As you can see in the image below, the SAM4L evaluation kit (SAM4L-EK) includes a board monitor that displays the amount of current consumed by the microcontroller as it executes applications.

This particular image is a photograph of the board monitor display captured when the microcontroller was executing a simple FreeRTOS demo with the optional tick suppression feature enabled – clearly spending the majority of its time in the special retention low power mode of the SAM4L.

“The current readings taken when in retention mode resulted in the flat horizontal line visible along the bottom of the graph in the photograph. Every 500 and 500 + 20 milliseconds an application task briefly left the blocked state to perform a trivial piece of processing,” Barry noted.

“The current readings taken when an application task was executing resulted in the two small dots that appear four times on the graph above (the measurement resolution and screen resolution make the dots appear almost as one elongated dot). As four execution instances are visible on the graph it can be seen that the graph in the photograph covers a two second period.”

Additional information about Atmel’s SAM4L can be found here, while key data pertaining to FreeRTOS and its tick suppression feature is available here.