 |  |
C.4. What Makes a Protocol Secure?
The encryption algorithm is not the only thing that determines how secure a transaction is. Knowing what encryption algorithm is being used is like knowing what kind of safe somebody owns; it doesn't tell you anything about how secure the information actually is. You can have a completely burglar-proof safe but never bother to put documents in it, or put documents into it without locking the safe, or put documents into it and lock the safe using a combination that lots of people know or can guess.Just as many people buy expensive and secure safes and use them badly, many people take good encryption algorithms and build them into insecure systems.
In order for a client and a server to have an authenticated and secure private communication session, the following are needed:
- The client and server must agree on what cryptographic algorithms they wish to use.
- The client must be able to tell it is talking to the right server, and the server must be able to tell what client it is talking to.
- The client and server must share a secret that nobody else can know or independently determine.
- The client and server must be able to tell if someone has altered any messages (particularly during the initial stages of communication).
- At the end of the session, the shared secret must be destroyed, and there should not exist a way for it to be recreated.
C.4.1. Selecting an Algorithm
In a perfect world, it would be possible to select the perfect encryption algorithm for clients and servers to use once, and no negotiation would be necessary. The real world doesn't work this way. Sometimes it's necessary for some clients or servers to use relatively weak encryption (either because they have computational limits and can't do stronger encryption fast enough to keep up, or because legal or licensing restrictions control what kind of encryption they can do). In this situation, you don't want to hold back all connections to the lowest common denominator, so you need to support negotiation.Even when this kind of negotiation isn't needed, most protocols support negotiation in order to allow future implementations to change the encryption algorithm that is used. New encryption algorithms are frequently discovered, and so are new problems with old encryption algorithms. You don't want to be stuck using an encryption algorithm that somebody has figured out how to decrypt easily, or an algorithm that's half the speed of the newest and best thing. Once again, you need to be able to negotiate.
Safe negotiation is difficult. It should be possible for each end of the connection to specify what algorithms are acceptable. If one end can convince the other to negotiate little or no security, a hostile client or server can force connections that will leak information. Even more importantly, it should not be possible for any third party to influence the negotiation. You do not want an attacker to be able to select the encryption that's easiest to break!
A secure protocol uses a negotiation that:
- Allows each side to specify an ordered list of algorithms (from the most desirable to the least desirable)
- Always selects the most desirable possible algorithm
- Fails altogether if no algorithm is acceptable to both sides
Uses message integrity protections to prevent third-party tampering (see the earlier discussion for more information on message integrity)
C.4.2. Mutual Authentication
In general, when people worry about authentication, they worry about client authentication; how does the server tell that it is offering services to the right client? In a secure protocol, it is also important for the client to be sure about what server it is talking to. The client is going to offer authentication data to the server. That authentication data is valuable to an attacker, and you don't want to blindly hand it out to anybody that asks.A secure protocol therefore provides for mutual authentication; the server authenticates itself to the client, and the client authenticates itself to the server. There are various ways of doing this, most of them based on the same trick where each side proves that it can decrypt a value with a secret that only the authentic participant could know. This secret could be a key used with a symmetric algorithm, or it could be the private half of a public key/private key pair; it makes a difference in configuring the servers and clients but doesn't change the basis for the authentication. In either case, each side sends the other an unpredictable value and gets it back in a form that proves the other side could decrypt it.
C.4.3. Sharing a Secret
As we've mentioned before, public key cryptography is slow. Very few network protocols can rely on public key cryptography to protect data simply because it takes too long. Protocols therefore need to have a shared secret that can be used for symmetric encryption. That secret can be something they both know already, but there are a number of reasons why it is convenient to use a temporary key (sometimes known as a session key) for most transactions, and to discard the key when the transaction is over:
- In general, the more ciphertext that uses the same key that is available to an attacker, the easier it is for the attacker to discover the plaintext (this is particularly true of one of the fastest classes of encryption algorithms).
- The longer a key is in existence, the more likely it is to be inadvertently disclosed.
C.4.4. Identifying Altered Messages
Encryption by itself will not keep people from altering data. A secure protocol needs to add something that will. In general, it will be some form of message integrity checksum, as discussed earlier in this appendix in the section about integrity protection.
C.4.5. Destroying the Shared Secret
Once you have decided to use a temporary shared secret, it is also important to destroy the secret when you are done with it. If there is a way to recreate the secret, then someone who recorded the session could, once they had the right information, decrypt it. If there is no way to recreate the secret, even with unlimited access to the computers on both sides of the communication, then you have achieved a cryptographic property called perfect forward secrecy.Perfection is normally difficult or expensive to obtain, and perfect forward secrecy is no exception. In general, temporary keys are generated using information that is available to one or both sides of the transaction, and there are also usually situations where one side or the other is not sure whether or not the transaction has completed, and needs to keep the key around until the situation is clarified. For practical reasons, most systems implement partial perfect forward secrecy, where there is some period of time during which it is possible to recreate the shared secret. After this time period, things are reset, and the secret is destroyed.
