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
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!
Atmel | Bits & Pieces 