Saturday, June 26, 2004

SEC: How to use cryptography in computer security

IT Manager's Journal | How to use cryptography in computer security

Title How to use cryptography in computer security
Date 2004.06.24 12:01
Author editingwhiz
Topic Security

Cryptography is the mathematics underlying computer security. While a Ph.D. in cryptography is hardly a requirement for keeping one's systems secure, an understanding of the basics helps in decision making about security, both for system administrators and IT managers. In this article, I present a non-technical overview of a few key concepts in cryptography that are relevant to consumers of security solutions. I then look at some widespread myths about cryptography, and give some advice on practical matters relating to cryptography.

Cryptography basics

Encryption. Suppose your company has a confidential database which you wish to backup offsite with a storage provider. This is a typical application of encryption. An encryption algorithm, or a cipher, takes the data and a small key (think of it as a phassphrase) and produces garbled data. For someone who doesn't have the key, there's no way to make sense of the garbled data (more precisely, doing so would take an insane amount of time), but if you have the key, you can easily get the original data back. So you retain the key and send the garbled data to the backup provider.

Encryption can also be used if you want to communicate with your business partner across the world and you don't want anyone to eavesdrop. In this case, you'd both have to have a shared key which no one else has. Setting up this key can be a problem, which I will explain a bit later.

Message digest. You also want to make sure the backup provider gives you the data back correctly if your copy is lost. For this, you'd use a message digest algorithm -- which takes the data, and no key -- and produces a short digest. The digest gives nothing away about the data. At the same time, it ensures that any two different pieces of data are extremely unlikely to have the same digest. If you compute and retain the digest at the time of backup, you can verify whether the data is uncorrupted, even though your copy of the data has been destroyed.

A message digest can also be used by a Web site that wishes to have its data mirrored but does not trust the mirroring site. It can put up the message digest on its Web site, so that the user can verify that the data they downloaded is not corrupted by computing the digest of the downloaded data.

Yet another -- and very common -- use of message digests is in storing and communicating passwords. On modern Unix systems, passwords are not stored on disk, so that even if the system is compromised, the attacker cannot get the passwords. Instead, only password digests are stored. When a user supplies her password, verification is done by computing its digest and comparing it to the stored value. Many Web sites adopt a similar approach to avoid transmitting cleartext passwords over the Internet.

Key agreement. Key agreement solves the problem of setting up a shared secret key with your partner. Since the whole point of encrypting communications is that someone could be eavesdropping, you don't want to send a secret key through the same medium. A key agreement protocol can be used to get hold of a shared secret key, provided that both parties are sure they are talking to the right person and that no one can tamper with the messages they send each other.

Key agreement is based on assymmetric encryption, also called public key encryption. How it works is that when a business relationship is first established, you look up your partner's public key from a trusted source. Your partner has the corresponding private key, and no one else. Then you use the public key to encrypt the shared key, with the assurance that an eavesdropper cannot read it. Your partner recovers the shared key using their private key, and you both use the shared key to encrypt the rest of the data using a regular encryption algorithm.

You could have used an assymmetric encryption algorithm for encrypting the whole data, but it would be hundreds of times slower.

Digital signature. A digitally signed message carries with it an assurance of integrity and authenticity. After you encrypt the message that you're going to send to your partner using their public key, you sign it using your private key. Your partner gets your public key from the same trusted source and verifies that the signature is correct. They then know that no one except you could have sent the message, and that it was not modified during transmission.

Going back to the data backup example, if both parties digitally sign a document recording the original transaction, including the digest of the data, then you have a firm basis to sue the storage provider in case the data you get back is corrupted -- they can't deny having signed the document. It also protects the storage provider from being sued, as long as they do produce the data accurately when you want it.

Public key infrastructure. A public key infrastructure is used to solve the trusted source problem in the above example. Among other things, it issues a certificate connecting an individual's or organization's public key with their identity. Further, the certificate is digitally signed by the certifying authority.

A directory service is a public key infrastructure that integrates various information about the entities and resources with the certificate access mechanism.

Cryptographic standards. As with any other computer protocol, cryptographic algorithms and protocols need to be standardized. DES (Data Encryption Standard) used to be the standard for symmetric encryption; it has been replaced by AES (Advanced Encryption Standard) because the key size of DES was too small. MD5 (Message Digest) and SHA-1 (Secure Hash Algorithm) are the two popular standards for message digests. RSA (Rivest-Shamir-Adleman) is a well known assymmetric cryptosystem which is used for both key exchange and digital signatures. DSA (Digital Signature Algorithm) is another standard for signatures, and Diffie-Hellman is a standard for key exchange. X.509 is an example of a standard certificate format, and LDAP (Lightweight Directory Access Protocol) is the most popular directory standard.
Myths about cryptography

Myth 1: Increased key length gives increased security.

To see why such a blanket statement is not true, we need to understand that there are two factors that are necessary for a cipher (whether symmetric or assymmetric) to be secure:

* The algorithm must not have weaknesses.
* The key must be sufficiently long.

It can never be proven that the algorithm doesn't have weaknesses. But if it is a well-known cipher which the cryptographic community has analyzed and no weaknesses have been found, then one can place a high degree of confidence in its security.

Key length depends on the type of cipher. Since the math of symmetric and assymmetric ciphers is different, so are the key lengths required for security. For symmetric ciphers, 128 bit keys are thought to be good enough for the forseeable future, and for assymmetric ciphers it is 1024 bits. For long-term security, 2048 bits might be advisable. The difference between the key length of the two types of ciphers is one of the most frequently encountered points of confusion among non-cryptographers.

The amount of time needed to break a cipher depends on the key length. This dependence is described by an exponential functions, which are weird things. You don't often encounter them in real life. Basically, it means that if you increase the size of the key by a single bit, the time required to break the cipher doubles. Thus, it is fairly easy to make your key long enough that it would take more years to break the cipher than there are atoms in the universe.

All this holds only if there are no mathematical weaknesses in the algorithm. If there are, then the whole thing breaks down, the cipher becomes trivially breakable, and key length is largely irrelevant. Unfortunately, calculations of how long it would take to break the security of a security product based on the key length alone are frequently used as a smokescreen to deflect objective thinking about its security. This is a trap against which the consumer must always be on the guard.

Myth 2: Assymmetric key ciphers are more secure than symmetric key ciphers.

While it is true that the discovery of assymmetric cryptosystems heralded a new era in cryptography, the reason is not that such ciphers are more secure, but that they are applicable to problems such as key agreement and digital signatures, for which conventional ciphers do not work.

Perhaps another reason why assymmetric key ciphers are often mistakenly considered more secure is that their hardness is typically based on an easy-to-understand mathematical problem, such as factoring a large number. On the other hand, symmetric ciphers have no particular mathematical elegance. While it is easy to get an intuition for why factoring is hard, this does not mean that it is more secure; ultimately, the guarantee of security boils down to how long and how hard the cryptographic community has been trying to find weaknesses, which is roughly the same for both kinds of cryptosystems. As long as the key length is chosen appropriately, the two should give commensurate security.

Myth 3: Secrecy is important for security.

The prevalence of this myth may be attributed to the historical confusion between keeping your data secret and keeping your security algorithms themselves secret. On the contrary, the only worthwhile insurance of security comes from having your algorithm published and well analyzed by as many cryptographers as possible. The principle that security should not rely on algorithms being secret has been well-established for over a century, and various pithy restatements of it are often cited: "Security should reside only in the key" (Kerckhoff), "The enemy knows the system" (Shannon), and "Anyone can design a cryptosystem which he himself cannot break" (Schneier).

The situation is somewhat analogous to the higher security of open source software, but there are differences which make the case for open cryptosystems far more clear cut: firstly, the techniques of cryptanalysis are such that the benefit in keeping your cipher secret is small. Secondly, even if you keep your system secret, there's a very good chance that it will evenually fall into the enemy's hands -- not the least because many attacks involve insider co-operation. Thirdly, there exist techniques to write provably secure code, but that's not possible with ciphers.

Myth 4: The government can crack any cipher.

It is true that until recently (certainly until World War II, and arguably until the 1960s), cryptography was the exclusive domain of secretive governments. The NSA knew about a technique called "differential cryptanalysis," which influenced design of DES in the early 1970s, something that wouldn't be discovered in public until 1990. In the last 30 years, however, the situation has changed dramatically, and the number of cryptographers and cryptanalysts has exploded. Governments can no longer match the scale of public cryptography. The point is worth repeating that the only determinant of the security of a cipher is the amount of effort that is gone into attempting to break it. As Shamir (the 'S' in RSA) said: "Once the encryption genie was out of the bottle, there was no way of putting it back." The recent U.S. government relaxation of export controls on cryptography shows their acceptance of this reality. Thus, one can use a standard cipher such as AES with a reasonable degree of confidence of security, even against governments.

So, how do you apply knowledge of cryptography in practice? Cryptography is typically bypassed, not penetrated. What this means is that designing a secure cipher is the easy part. The hard part is to make sure that the algorithms you are deploying are implemented correctly and exactly match the security requirements that you have. This is why it is important for administrators to learn the basics of cryptography. It cannot be left to mathematicians; it has to be deployed by someone with an intimate knowledge of the overall IT system of the organization.

It is important to have a threat model and a well-defined and well-enforced security policy. The threat model answers such questions as "What are the sensitive data sets in the system?" and "Who are the untrusted people on the network?" The security policy addresses issues such as "How often must passwords be changed?" and "Are employees allowed to plug in their personal laptops to the company network?" Adding another dimension of complexity is the fact that security is a process, not a product. As the IT environment continually changes, the security policy, too, must adapt constantly. Frequent security audits and reviews are essential.

Finally, there is no such thing as perfect security. The more the expenditure, the greater the assurance of security that can be achieved. However, after a point increasing security comes at the expense of deceasing usability of the system. The security budget and security policy must therefore be finely balanced, taking into consideration various factors such as the overall IT budget, the sensitivity of the data, the experience of the users, and so on.

Arvind Narayanan is a programmer and free-lance writer based in Madras, India. He is the author of gretools, a vocabulary building tool for GNOME, and gtkboard, a board games system.

1. "gretools" - http://theory.cs.iitm.ernet.in/~arvindn/gretools/
2. "gtkboard" - http://gtkboard.sourceforge.net/


Post a Comment

<< Home

Get Firefox!