Cryptology is the study of cryptography and cryptanalysis, the theory and practice of analyzing cryptography. Public key cryptography, which uses a different key for encryption than for decryption, provides data security and privacy with technical features that are ideally suited to network computing. In the next two newsletters, Ill look at creating and managing cryptographic keys and Ill show how data security can be achieved using a public key CryptoStream in C# to encrypt and decrypt data using IO streams.
Complex programmable computers with bloated operating systems are nearly impossible to fully protect from malicious tampering. To ensure optimal data security, one need only to generate random encryption keys, use them to encrypt data, save the encrypted data (ciphertext) to a reliable storage device (backup tape, for instance), write the encryption keys on a piece of paper, and then destroy the computer that was used to perform the encryption (at least destroy its storage devices and nonvolatile RAM). This guarantees that all copies of the encryption keys, other than the printed copy, are destroyed. Even if malicious code was present on the encrypting computer and it managed to intercept the encryption keys, the unauthorized copies made by the malicious code get destroyed when the computer is destroyed. Without a communications device connected to the computer, there are only three ways for a third party to obtain the original unencrypted data (plaintext). Even optimal data security with encryption leaves the following three points of vulnerability:
- Encryption can be broken through cryptanalysis.
- A third party can intercept the paper copy of the encryption keys.
- An eavesdropper in a remote location with extremely sensitive listening devices designed to pick-up electromagnetic radiation (called TEMPEST or EMSEC) can observe the computer during encryption.
Computer security threats plague even the best software-based cryptographic systems. It is presently impossible for us to know whether malicious or flawed code is in control of a trusted computer system that we rely on to encrypt sensitive data. Assuming that the encrypting computer is shielded to guard against EMSEC as well as protection from someone simply looking over your shoulder, its irrelevant whether there happens to be malicious code executing while key generation and encryption occur. Resistance to decryption through cryptanalysis, the theory and practice of solving cryptographic systems, and the safety of physical storage for the paper copy of the encryption keys determine the effective degree of data security.
Managing Trust in Cryptography
It may be impractical for your organization to implement an elaborate EMSEC policy including purchasing expensive EMSEC-hardened computer equipment from a government-approved vendor. And it would be absurd to toss hard drives into a furnace after each use, but the mental exercise is important so that you can evaluate how close you come to achieving optimal data security with any cryptography you deploy. Data encryption must typically be performed in a trusted environment where the plaintext is not accessible to malicious code. The Catch-22 of encryption is that when trust is compromised, so too are encryption keys, thus rendering pointless any future encryption and unlocking all existing ciphertext produced in the past using those same encryption keys. That is, when the encryption employed uses a symmetric encryption algorithm, where the same key is used for both encryption and decryption, the computer that applies the encryption must never become compromised or else its encryption keys and all data security are also compromised. Encryption applied using a symmetric algorithm in an untrustworthy environment is either untrustworthy or pointless. If untrustworthy is good enough, why bother with encryption? Conversely, why bother with encryption if you know you can trust your computing environment?
The Secure Sockets Layer (SSL) protocol was developed to implement encryption for untrustworthy settings like the Internet. The SSL protocol employs symmetric cryptography to encrypt and decrypt data so that third parties who do not have control over either the client or the server but who do have the ability to eavesdrop on the network are unable to decipher the content of the communication. Since symmetric encryption is employed for privacy by SSL, both client and server must have a copy of the encryption key. To exchange the symmetric key across the untrustworthy network, SSL uses the RSA asymmetric encryption algorithm (where there are different keys for encryption and decryption), discovered by three researchers at MITRivest, Shamir, and Adlemanin the 1970s. The RSA algorithm is used in SSL for key exchange but not for bulk data encryption because of the amount of time it takes to compute the decryption transformation from ciphertext to plaintext using the RSA algorithm. Even a fast computer by modern standards can require over 60 seconds to decrypt 1 MB of RSA ciphertext produced using a 1024-bit key. RSA encryption is computationally easy relative to decryption, with the same computer able to encrypt 1 MB of plaintext in about 4 seconds with a 1024-bit key. This encryption speed is nearly adequate for real-time data security if the computer doing the decryption is 15 times as powerful as the one doing the encryption. Of course, this assumes that the full resources of both computers are devoted to the task of encryption and that encryption tasks arent performed in parallel. Hardware encryption accelerators can further speed up both sides of the equation, but the cost to scale is prohibitive as parallel demand grows.
It is important to draw a distinction between encryption for the purpose of privacy to guard against eavesdroppers and encryption for the purpose of data security to protect data from unauthorized access. The former is the goal of SSL, while the latter is left to the client and server to implement in application-specific ways. It is this type of encryption for data security that is too often skipped when developers create automated data processing applications because of the Catch-22 of symmetric encryption. If the application needs automated access to data, then it must be able to automatically encrypt and decrypt that data, meaning it must have a copy of the symmetric encryption key. Any third party who gains control over the computer also gains control over the key. As a result its far more important to restrict unauthorized access to sensitive computer systems than to go through the motions of encryption and decryption automatically with a symmetric key algorithm. Adding encryption does little to increase data security because ultimately, that security hinges on protecting the computer from unauthorized access.
Symmetric encryption decreases the likelihood that unauthorized third parties can gain access to data by ensuring that a copy of the symmetric key is in the possession of any person or computer that reads the data. Possession of a copy of the symmetric key functions as an authentication credential. The key provides proof that the person or computer is authorized to access the plaintext data, assuming the key is kept secret. Without the symmetric key, access to the data is denied due to the fact that the ciphertext is unintelligible without lengthy and complex cryptanalysis. Symmetric encryption that is applied on-demand by a human user offers security that can be considered superior to symmetric encryption performed automatically by any computer application. We will always be faced with practical risks of key management in our automated systems that we don't have to contend with when keys are controlled exclusively by human users. A third party attacker may find it easier to break into a computer and take control of an application that can automatically decrypt ciphertext than to break the will of a human and compel them to reveal the secret encryption key.
An automated system that must overcome this Catch-22 must encrypt plaintext data in such a way that even the encrypting system itself is incapable of decrypting it. Asymmetric encryption algorithms provide a way to transform plaintext into ciphertext using an encryption algorithm and a key that are useless for decryption. There are many reasons that an application might need to automatically encrypt data that it has no business ever automatically decrypting. By using asymmetric encryption, all ciphertext is completely secured from unauthorized decryption, even if a third party gains control over the computer that performs the encryption and intercepts the ciphertext. Symmetric encryption is useful to protect data on demand, where only an authorized user with a copy of the encryption key can decipher and use the data and the key is never stored on the computer for it to use later in automatic decryption. But only asymmetric encryption can provide optimal data security for automated systems. Automated symmetric encryption is good for privacy, but does little to enhance data security. Ciphertext produced by an automated system using symmetric key encryption must not be stored in a location that is accessible to the automated system or there is a perpetual risk that systems security will be compromised, its secret symmetric keys intercepted, and all ciphertext produced by the system easily decrypted. Asymmetric cryptography is a viable solution to these data security problems.
Applying Public Key Cryptography to Data Stream Encryption
Cryptographers Diffie and Hellman are credited with conceiving a cryptographic algorithm where the user generates a pair of keys and keeps one private but reveals the other key in the public. Encryption performed using the public key produces ciphertext that can be decrypted only with the private key. Thus asymmetric cryptography became known as public key cryptography and is sometimes referred to as Diffie-Hellman public key cryptography. The RSA algorithm was licensed exclusively to RSA Security Inc. by MIT in 1983. Recently, on September 6, 2000, two weeks before MITs patent was set to expire, RSA Security announced that it was placing the patent in the public domain to clearly explain its view that the algorithm was no longer its protected intellectual property and anyone was free to use the invention for any purpose. On September 20, 2000 the RSA patent expired.
Public key cryptography is much slower than symmetric key cryptography. As a result, public key encryption is commonly used only for symmetric key exchange as in the SSL protocol. But public key encryption does work for bulk encryption and it provides unmatched data security for automated systems. Consider how a malicious attack might occur against a system that employs symmetric encryption. One option is to intercept only the symmetric key at the point of encryption and then intercept a copy of the ciphertext at a later time. Another option is to intercept the plaintext before encryption occurs. The symmetric key is usually very small compared to the plaintext data, so the preferred attack would be to intercept only the key at the point of encryption since intercepting all of the plaintext would require more effort and more likely produce signs of theft and system penetration. If 10 GB of plaintext are being encrypted using a 128-bit symmetric encryption key, malicious code has a much higher chance of intercepting the 128-bit key and transporting it to the attacker without being detected than dumping a copy of the plaintext out to a file or a network stream. Theft of the encryption key does nothing to impact data security in asymmetric encryption because the encryption key is not used for decryption. Stealing the plaintext before it is encrypted is the only option for an attacker, so the complexity of the attack is increased substantially. Countermeasures are possible to detect and halt the theft of large amounts of plaintext that just aren't possible to defend against theft of small symmetric encryption keys. Symmetric encryption keys can literally fly out a window; transported to an attacker via cellular network or just leaked as electromagnetic radiation. Applying public key cryptography to bulk encryption is the solution to the problem of key theft and undetected malicious third-party control over automated systems that must achieve optimal data security. In the next newsletter, I'll show a C# example that applies the RSA public key encryption algorithm to the task of file encryption using IO streams.
Jason Coombs works as forensic analyst and expert witness in court cases involving
digital evidence. Information security and network programming are his areas
of special expertise. He can be reached at [email protected].