Tag Archives: secure boot

There’s good news about BadUSB

The good news about the recently-revealed BadUSB is that there actually is a cure: Atmel CryptoAuthentication. Hardware crypto engines were invented to protect software, firmware and hardware from exactly these types of attacks, among many others. These uber-tiny, ultra secure hardware devices can be easily and cost-effectively added to USB sticks (and other peripherals) by manufacturers, who are seeking to protect their customers by ensuring that only the proper and intended code is downloaded and used. Once installed into the peripherals, CryptoAuthentication devices will block the bad code. Period.

Let’s look at what Bad USB has uncovered: It is that everything with a processor is vulnerable to attack. Most people don’t really think of a USB stick, modern thermostat, home router, fax machine, PC mouse or trackpad, a camera, iPod, microwave, and other “things” as being computers; however, they are. In fact, they all have at least one processor, memory, ways to get stuff in and out, and code (firmware) that tells the processor what to do. That last piece is where the danger lies.

As any PC or smartphone user knows, code gets updated all the time to get rid of bugs and add features. Updating code opens up a processor that was previously running good code, to code altered by people with mal-intent, i.e. malware. This is how good embedded systems go bad. We recently saw malware that allowed an ATM to spit out 40 bank notes at a time if a certain code was entered. Real nice for those who know the code!

BadUSB is Bad for More Than Just USB

All systems with processors are vulnerable to bad code, which can do bad things to good systems. All it takes is a way to transfer bad code from one processor to another… and, that happens all the time. USB sticks, USB accessories, the Internet, wireless links like Wi-Fi or Bluetooth — you name it — can be vectors for diseased code. What BadUSB has revealed to us is that all embedded systems, unless equipped with robust protection mechanisms, are now vulnerable to catching diseased code. (Embola?)

embola 3


One contracted, a machine infected with Embola can send private and sensitive information to bad guys, or let them take over your system for ransom or other mal-purposes. They can turn on cameras and microphones to spy, grab your photos and bank account information, or even mess with your car. Whatever they want they can have, and you most likely will never know it.

By now you should see the point, which is that every embedded system and PC needs protection. Everything that runs software is vulnerable such as wearables, phones, USB accessories, USB sticks, cameras, cars, printers, thermostats, ATMs, meters, microwaves, appliances, and whatever the IoT will become. Simply put: If it has a processor and connects to something else, it is hackable.

So, what can you do to protect against Embola? The answer is twofold:

1. Don’t let the bad code in, and
2. If it does get in, don’t let it run.

While this sounds pedantically simplistic, these steps are NOT being taken. These two functions have the self-explanatory names of secure download and secure boot.

Secure Download

Secure download uses encryption to ensure that the code that is received by the embedded system is kept away from hackers. The code is encrypted using an algorithm such as Advanced Encryption Standard (AES) by using an encryption key. That encryption key is created using a secret that is only shared with the target system. The encrypted code is sent to the target embedded system to be decrypted and loaded for its use. Along with the encrypted code, a seed is also sent to the target system.

The seed is a number (typically unique with each session) that is hashed during the encryption session with a secure secret key. The result of that hashing is called the digest or Message Authentication Code (MAC) and it is used to encrypt the code (i.e. the MAC is the actual encryption key). The seed is sent to the target system to enable decryption, and not useful to anyone unless it is hashed with the secret key, which is what the target system will do. The target system runs the same hashing algorithm with the identical shared secret key stored there and the seed, which results in the same digest (MAC) that was used to encrypt the code. That MAC can now be used as the decryption key to decrypt the code. At this point, the decrypted code can be ran in the target embedded system.


However, there is another step that can be taken that adds even more security, which is authentication using a digital signature. To use authentication, the unencrypted original code is hashed and signed by the code originator at the same time as the original encryption process. The originator uses a signing key on that hash of the code to make a signature. That signature is sent with the encrypted code and seed to the target system. Once the encrypted code is decrypted using the process noted above, the newly decrypted code will be hashed by the target system, just like was done by the originator, and then signed with the signing key stored in the target system. That signing key is the same as on the originator’s signing module, so if the decrypted code has not been altered, the signature made on the digest of that decrypted code and the signing key will be exactly the same as the signature that was sent over. These two signatures are compared and if they match then the code has been authenticated and can be safely run on the target system. What does this mean? No risk of Embola!

The two levels or security provided by secure down load with authentication is obviously very robust. It will ensure that code that was received has been kept secret during transmission and has not been tampered.

Secure Boot

Secure boot also uses digital signatures to ensure that the code to be booted when the target system starts up matches the code that the manufacturer intended and has not been tampered with. It sort of works in a similar way as secure download. If the code to be booted has been altered, then the signature made by hashing the digest of that code with a secret signing key will not match the signature from the manufacturer. If they don’t match, the code will not load.

These methods are easy and inexpensive to implement and already exist. You should be able to see by now how Atmel has you covered. Ready, set, get secure!


A Closer Look at Secure Boot and Why It’s Important

By: Gunter Fuchs

Who has not experienced a misbehaving computer due to a  virus? Or, you may have at least seen your virus protection software catching one in the act. One especially nasty type of virus is one that is executed before the anti-virus (AV) software begins its process, because it can then manipulate your AV program in a way that it does not find the virus.

Two main programs are executed before your AV program: the binary input / output system (BIOS) and the operating system (OS). The central processing unit (CPU) executes these two programs as part of the “boot” process. Making this boot process secure can increase the overall security of a system in a big way.  By verifying the authenticity of the code for the OS, a secure boot process prevents any virus from sneaking in and compromising a system before the AV program can take over system security.

To be able to verify the code, it is stored along with a “signature” of it at the time of manufacturing or code update. The signature is the output of a cryptographic hash function. (A hash function is irreversible and “condenses” a big blob of information such as boot code into a quite tiny size, 32 bytes for example.) Its inputs are the code and a secret key, known only to the generator of the signature and the verifying routine inside boot code (BIOS) that gets executed immediately after power-up or system restart. This verifying routine calculates the signature the same way it was calculated before by the host (system at manufacturing plant, online site for updating, etc.), and compares it with the stored signature. Only if the calculated and stored signatures match does the boot process continue. Otherwise, the boot verification routine halts the system.

The paragraph above describes a system where the verification (calculation and key storage) is done in the boot ROM. The picture below shows a system where the calculation and key storage are loaded off into a hardware device (ATSHA204) offered by Atmel. Storing the key in very secure, tamper-safe hardware adds a big obstacle to any hack attempt.

Secure Boot

Secure Boot

Components to a truly secure system

By: James Tomasetta

In today’s increasingly connected world, the need for security is no longer just for communicating over the Internet, but is also needed to ensure that the user’s personal computer is free from malicious code.  In order to secure the user’s local computer, a root of trust  needs to be established, starting from the manufacturer of the hardware and continuing through the firmware and into the installed software.  The key components in securing this root of trust are a fixed or secured boot loader that is inherently trusted by the system and is used to start the authentication sequence, which can be implemented using many existing hardware security chips on the market, such as the ATSHA204 from Atmel.  The second key piece needed is a secure key vault used to store the keys used to sign different pieces of code loaded on the system back to their developers.  Once the code has been verified the boot ROM will start executing code and continue to repeat these steps until the system is fully booted.  Once the root of trust has been established for the system, the user can ensure that none of the code running on the system has been modified. 

secure boot