Apart from social engineering exist two ways to break an encryption key like AES, brute force and cryptanalysis. Find out here whether AES encryption can be cracked any time soon, along with the latest AES development and recommendations from IT security evangelist Bruce Schneier.
Besides social engineering exist two ways to break any encryption key, brute force and cryptanalysis. After the introduction we look at why AES and similar encryption schemes are secure against brute-force attacks using computer power to crack a key. Then you will find the latest development from the studies of AES by means of cryptanalysis. If you are not familiar with encryption it is recommended reading Bright Hub’s article What is AES Encryption? and Types of Encryption.
Brute Force
Mathematicians have discovered that any positive integer greater than one can be expressed as the product of its prime factors; the prime decomposition of the number 22 for instance is 2 x 11. There are a number of algorithms for integer factorization, but the difficulty and complexity to find the prime factor increases at the last sub-exponentially with the size of the integer.
This essentially means that the prime decomposition of large numbers is computationally infeasible with traditional computers. As the strongest encryption algorithms in use today, such as, for instance, Rijndael, which has become the Advanced Encryption Standard (AES), employ large integer factorization, AES in unbreakable – again with the premise of traditional computers in mind.
A quantum computer operating on qubits instead of bits offer polynomial speed for some computing problems including Integer factorization, so that taking into account Cobham’s thesis we know that the traditional encryption algorithm keys can be feasibly computed. Therefore, when quantum computing gets out of the lab will ciphertext produced by traditional cryptography no longer be secure.
Cryptanalysis
The Advanced Encryption Standard can be used with 256-bit keys, immune against Moore’s Law for the years to come. However, cryptanalysts studying the inner working of an algorithm are constantly trying to find a weakness in the encryptions algorithms or to break it. Most “vulnerabilities” are usually of rather theoretical nature, so there is nothing to worry about for an ordinary computer user as the subject is being watched and followed by the IT security community which has been trying to crack publicly documented encryption schemes including AES for years.
Yet, it was only recently when Bruce Schneier, the inventor of Twofish and Blowfish AES competitors stipulated “that the safety margin of AES is much less than previously believed [1].” Schneier demands that AES implements more round of Rijndael for any key length “and for new applications I suggest that people don’t use AES-256. AES-128 provides more than enough security margin for the foreseeable future
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).