Embedding security in the real world

Here’s how to achieve secure machine-to-machine communication without a secure MCU

BY EUSTACE ASANGHANWA
Senior. Applications Engineer and Product Manager
Atmel
www.atmel.com

You are an electronics engineer who has been hired to add embedded security to a fleet of soda-pop-vending machines. You impressed your new employer with your deep knowledge of cryptography during the interview. Now it’s time to deliver. At face value, the job should be as simple as picking a chip with a good crypto algorithm, right? The real world is not that simple.

Why call in the brigade to protect a soda machine?

The security concern is real and shared among machine manufacturers all over the world. There is increasing trend to add security at the firmware level to machines that, at first glance, seem to not need it. Soda-vending machines are a convenient example in this article, but it’s easy to envision other examples: parking meters, washers and dryers in laundromats, toll booths, and ticket vending.

Machines are being networked to gain visibility into real-time information that can help cut operating costs and boost revenue. The owner now can tell which machines need servicing, and has the data to determine and install machines with the right product mix. Real-time information is a weapon to competition and robbers. Competitors tapping into this information stream can either use the information to mount a stronger competition or suppress the owner information (for example, denial-of-service attack). Similarly, robbers now know just which machines to rob and when to rob them.

OK, what’s next?

You have been briefed and the objective is clear: protect information leaving the vending machines. Analysis reveals a fairly simple solution. Encrypt information over the network, and prevent the encryption keys and firmware in the vending machine from unauthorized access.

Encrypting information over the network is the straightforward part. First, decide on a good encryption algorithm. The best candidates are openly known algorithms that have withstood public scrutiny, as opposed to private ones. A good example is the Advanced Encryption Standard (AES) algorithm. Next, avail this algorithm in the MCU of the vending machine. You can do so by either implementing the algorithm in firmware or choosing an MCU with this algorithm built in hardware.

Last but certainly not least, use the algorithm in a recommended mode. Securing information with cryptographic algorithms requires more than just cranking clear text through to obtain encrypted text. Most publicly known algorithms have recommended modes of operation to assure confidentiality of the data they encrypt.

Example modes available for AES include cipher-block chaining (CBC), cipher feedback (CFB), propagating cipher-block chaining (PCBC), output feedback (OFB) and counter (CTR) which can be used in different combinations to improve strength. In-depth discussion on types and usage of these algorithms is beyond the scope of this article. The point to take away is that the algorithm alone is not security.

Preventing unwarranted knowledge to keys or unauthorized access to firmware is less straightforward and least understood. For many security implementations, this is the greatest source of vulnerability. This weakness stems from underestimation of attacker resources and under-appreciation of the value of integrated circuit hardening against intrusion and tampering. Often, people equate encryption to security and don’t see the value of investing in tamper-protected ICs.

Fig. 1: More and more applications see value in networking machines, thereby creating the need for embedded security.

Keep it simple or should you?

Being the esteemed EE professional you are, one who stays current with industry trends by reading this magazine, you can quickly analyze the facts and propose a foolproof solution: replace the MCU in the vending machines with a secure MCU and just add a little bit of extra firmware. Secure MCUs protect firmware and keys, encrypt communications, and come hardened against tampering and intrusions.

In fact, they can detect many kinds of sophisticated attacks and take actions that range from simple delayed response to shut-down. Secure MCUs are the kinds of ICs banks trust to operate ATM machines. So what is not to like about them? You are now told to design a solution that does not involve the secure MCU. Huh?

The fact is secure MCUs cost more and your company may want to stick with their standard processor. Secure MCUs are also difficult to write code for, leading to higher engineering costs.

Engineering solutions in the real world

What is an engineer to do when marketing, procurement, and even fellow engineers collectively vote one out of a seemingly slam dunk solution? Reset your expectations. In our example, this means not counting on having a secure MCU, not expecting lots of memory for firmware, and not treating any change as trivial.

Reevaluate your strategy. Instead of amassing everything into a single blob to put inside a single protective enclosure of a secure microcontroller, split the system into nonsecure and secure portions in a manner that does not compromise security. The nonsecure portion will comprise the core business (vending) logic of the machine. The secure portion will include two subcomponents one to protect encryption keys and the other to verify the integrity of the system.

Key protection needs storage and usage under physical protection similar to that offered by secure MCUs. This requires the use of an IC that has the same physical fortification of a secure microcontroller, but without the other stuff.

You also should protect system integrity prevent system operation from rogue firmware that can do things like bypass encryption, tamper with data, or send data to unauthorized recipients. The best protection to system integrity is detection of unauthorized change in firmware using a hash algorithm and taking action accordingly.

Hash algorithms generate a condensed fingerprint called a digest for a given piece of information. Just like human fingerprints, this digest is unique. An example of a good hash algorithm is the well-known and widely used Secure Hash Algorithm (SHA). So to detect firmware tampering, you will need to periodically generate its digest in the field and compare with a factory generated reference. You may already be wondering what keeps anyone from faking the digest or the reference.

In our example, we need to secure both the digest and its reference from getting faked. We do this by appending a piece of arbitrary length extra information to the firmware before feeding it into the hash algorithm to generate the factory reference. If you keep the extra information secret, then only you can re-generate the same digest which is how you keep the digest from getting faked.

The way to keep the reference from getting faked in the field is to store it in secured memory. Knowing that the digest has not been faked takes authentication, which in this case is based on knowledge of a secret key embedded inside a secure IC.

So, more than encryption, which only scrambles data, authentication is the real foundation to securing systems. Knowing this, it is worth noting that cryptographic hash algorithms are naturally suited for authentication. This is because of three fundamental properties a good hash algorithm must possess.

First, their operations are irreversible. This means it is impossible to recover the original message from the digest, and private information is secure. The second is noncollision, meaning different inputs must generate unique digests. Unique digests impart trust on the integrity of the firmware under verification. The third and final property is termed avalanche, meaning any change to the input of a hash algorithm, no matter how small, must produce a dramatic change to the digest.

Well-analyzed open methods exist that allow use of encryption algorithms to perform the roles traditionally done by hash algorithms. Such systems, then, both authenticate and encrypt. Similarly, while encryption algorithms are naturally suited for scrambling data, the security from them is only as good as the secrecy of the encryption keys. The authentication features of hash algorithms complementarily enable secure management of encryption keys in a secure system.

Different cryptographic algorithms enables protection of different aspects of a secure system, and a clear understanding of their subtle roles, strengths, differences, and interplay permits use of a fewer set of algorithms for a robust security implementation. This is especially important to challenges like ours where there is limited code space.

Fig. 2: A security companion IC is small, costs less, and demands very little system resources while offering the same physical protection of a secure microcontroller.

Security companionship

For your task, you know at the minimum you need firmware space and resources from a tamper and intrusion protected secure IC. The solutions come in the form of security companion IC. These are secure ICs with the same hardening against tampering and intrusion like secure MCUs, but streamlined to offer application-specific functions and thus cost less.

In our example, the security companion IC will protect and manage cryptographic keys to complement the security offered by encryption. They also perform various types of authentication to enable verification of system integrity. They can do a lot more including securing storage and enabling trusted firmware field upgrades. They do so by offering a smart and easy-to-use API so you do not need a solid grasp on cryptography or much code space to use them.

Unlike secure microcontrollers that offer processing and memory so you write all your functions in firmware, the functions in security companion IC are hardwired, making them compact which is why they cost much less. An example is the Atmel family of CryptoAuthentication products. Using these low-cost ($0.50 each in quantity) ICs you can appease your engineering colleagues because you can write and tag on the little additional firmware on the existing platform. ■