systems to download unsigned or unencrypted firmware upgrades or store unencrypted user data, a practice we justify because it’s invisible to the end user and makes our lives easier. The stealthy practice, however, is no longer kosher. With the help of this public-domain encryption algorithm, we can clean up our act.
Modern embedded systems need data security more than ever before. Our PDAs store personal e-mail and contact lists; GPS receivers and, soon, cell phones keep logs of our movements; and our automobiles record our driving habits. On top of that, users demand products that can be reprogrammed during normal use, enabling them to eliminate bugs and add new features as firmware upgrades become available.
Data security helps keep private data private. Secure data transmissions prevent contact lists and personal e-mail from being read by someone other than the intended recipient, keep firmware upgrades out of devices they don’t belong in, and verify that the sender of a piece of information is who he says he is. The sensibility of data security is even mandated by law in certain applications: in the U.S. electronic devices cannot exchange personal medical data without encrypting it first, and electronic engine controllers must not permit tampering with the data tables used to control engine emissions and performance.
Data security techniques have a reputation for being computationally intensive, mysterious, and fraught with intellectual property concerns. While some of this is true, straightforward public domain techniques that are both robust and lightweight do exist. One such technique, an algorithm called Blowfish, is perfect for use in embedded systems.
Terminology
In cryptographic circles, plaintext is the message you’re trying to transmit. That message could be a medical test report, a firmware upgrade, or anything else that can be represented as a stream of bits. The process of encryption converts that plaintext message into ciphertext, and decryption converts the ciphertext back into plaintext.
Generally speaking, encryption algorithms come in two flavors, symmetric and public key. Symmetric algorithms, such as Blowfish, use the same key for encryption and decryption. Like a password, you have to keep the key secret from everyone except the sender and receiver of the message.
Public key encryption algorithms use two keys, one for encryption and another for decryption. The key used for encryption, the “public key” need not be kept secret. The sender of the message uses that public key to encrypt their message, and the recipient uses their secret decryption key, or “private key”, to read it. In a sense, the public key “locks” the message, and the private key “unlocks” it: once encrypted with the public key, nobody except the holder of the private key can decrypt the message. RSA is a popular public key encryption algorithm.
Most credible encryption algorithms are published and freely available for analysis, because it’s the security of the key that actually makes the algorithm secure. A good encryption algorithm is like a good bank vault: even with complete plans for the vault, the best tools, and example vaults to practice on, you won’t get inside the real thing without the key.
Sometimes an encryption algorithm is restricted, meaning that the algorithm itself is kept secret. But then you can never know for sure just how weak a restricted algorithm really is, because the developer doesn’t give anyone a chance to analyze it.
Encryption algorithms can be used for several kinds of data security. Sometimes you want data integrity, the assurance that the recipient received the same message you sent. Encryption algorithms can also provide authentication, the assurance that a message came from whom it says it came from. Some encryption algorithms can even provide nonrepudiation, a way to prove beyond a doubt (say, in a courtroom) that a particular sender was the originator of a message. And of course, most encryption algorithms can also assure data privacy, a way to prevent someone other than the intended recipient from reading the message.
Data security in practice
Let’s say an embedded system wants to establish a secure data-exchange session with a laptop, perhaps over a wireless medium. At the start of the session, both the embedded system and laptop compute a private Blowfish key and public and private RSA keys. The embedded system and laptop exchange the public RSA keys and use them to encrypt and exchange their private Blowfish keys. The two machines then encrypt the remainder of their communications using Blowfish. When the communications session is over, all the keys are discarded.
In this example, it doesn’t matter if someone is eavesdropping on the entire conversation. Without the private RSA keys, which never go over the airwaves, the eavesdropper can’t obtain the Blowfish keys and, therefore, can’t decrypt the messages passed between the two machines. This example is similar to how the OpenSSH command shell works (although OpenSSH takes additional steps to prevent the public keys from being tampered with during transit).
Now let’s say that a server wants to send a firmware upgrade to a device and wants to be sure that the code isn’t intercepted and modified during transit. The firmware upgrade may be delivered over a network connection, but could just as easily be delivered via a CD-ROM. In any case, the server first encrypts the firmware upgrade with its private RSA key, and then sends it to the device. The recipient decrypts the message with the server’s public key, which was perhaps programmed into the device during manufacture. If the firmware upgrade is successfully decrypted, in other words a checksum of the image equals a known value, or the machine instructions look valid, the firmware upgrade is considered authentic.
The RSA algorithm is computationally expensive, although not unreasonably so for the level of functionality and security it provides. A lighter-weight approach to firmware exchange with an embedded system would be to encrypt the image with Blowfish, instead of RSA. The downside to this approach is that the Blowfish key in the embedded system has to be kept secret, which can be difficult to achieve for a truly determined attacker with hardware skills. In less extreme cases, however, Blowfish is probably fine since an attacker with such intimate knowledge of the target system and environment will likely find another way into the device anyway (in other words, simply snatching the firmware upgrade from flash memory once it’s decrypted).