|
|||
Encrypting data with the Blowfish algorithmEncrypting data with the Blowfish algorithmBy Bill Gatliff, Courtesy of Embedded Systems Programming Jul 15 2003 (11:00 AM) URL: http://www.embedded.com/showArticle.jhtml?articleID=12800442 Many embedded systems depend on obscurity to achieve security. We often design 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;[1] and our automobiles record our driving habits.[2] 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 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 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). The Blowfish algorithm Blowfish is public domain, and was designed by Bruce Schneier expressly for use in performance-constrained environments such as embedded systems.[3] It has been extensively analyzed and deemed "reasonably secure" by the cryptographic community. Implementation examples are available from several sources, including the one by Paul Kocher that's excerpted in this article as Listing 1. (The complete code is available for download at ftp://ftp.embedded.com/pub/2003/08blowfish.) /* Blowfish requires about 5KB of memory. A careful implementation on a 32-bit processor can encrypt or decrypt a 64-bit message in approximately 12 clock cycles. (Not-so-careful implementations, like Kocher, don't increase that time by much.) Longer messages increase computation time in a linear fashion; for example, a 128-bit message takes about (2 x 12) clocks. Blowfish works with keys up to 448 bits in length. A graphical representation of the Blowfish algorithm appears in Figure 1. In this description, a 64-bit plaintext message is first divided into 32 bits. The "left" 32 bits are XORed with the first element of a P-array to create a value I'll call P', run through a transformation function called F, then XORed with the "right" 32 bits of the message to produce a new value I'll call F'. F' then replaces the "left" half of the message and P' replaces the "right" half, and the process is repeated 15 more times with successive members of the P-array. The resulting P' and F' are then XORed with the last two entries in the P-array (entries 17 and 18), and recombined to produce the 64-bit ciphertext. A graphical representation of F appears in Figure 2. The function divides a 32-bit input into four bytes and uses those as indices into an S-array. The lookup results are then added and XORed together to produce the output. Because Blowfish is a symmetric algorithm, the same procedure is used for decryption as well as encryption. The only difference is that the input to the encryption is plaintext; for decryption, the input is ciphertext. The P-array and S-array values used by Blowfish are precomputed based on the user's key. In effect, the user's key is transformed into the P-array and S-array; the key itself may be discarded after the transformation. The P-array and S-array need not be recomputed (as long as the key doesn't change), but must remain secret. I'll refer you to the source code for computing the P and S arrays and only briefly summarize the procedure as follows:
Of course, firmware upgrades and data logs are seldom exactly 64 bits in length. To encrypt long strings of data using Blowfish, carve the message up into 64-bit blocks, encrypt each block and save the results. Pad the message with a value of your choosing to end on a 64-bit boundary. The code in the main() of Listing 2 does exactly this. Listing 2: Example of Blowfish use #include <stdio.h> int Now is a good time to start thinking about adding data integrity and privacy capabilities to your embedded system. The Blowfish algorithm is an excellent choice for encryption, since it's lightweight, public domain, and considered secure even after extensive analysis. Bill Gatliff is a consultant who specializes in solving embedded development problems using free software tools. He's the creator of the gdbstubs library, a free collection of embeddable stubs for the GNU debugger. You can reach him at bgat@billgatliff.com.
|
Home | Feedback | Register | Site Map |
All material on this site Copyright © 2017 Design And Reuse S.A. All rights reserved. |