Key Recovery
Encryption poses certain questions and concerns. By using encryption, a company can keep confidential information secret while utilizing a public network. It can be used in e-commerce situations in fact, e-commerce must use encryption because otherwise credit card and personal information would be transmitted from customer to store insecurely. Encryption can also be used by unscrupulous individuals to hide their nefarious acts. For instance, a child pornographer could encrypt all evidence of his illegal activity or terrorists could use IPSec to securely plan and carry out acts of terrorism.
Because of the latter, many governments in the world severely restrict when, where, and by whom encryption can be used. This makes it easier to keep tabs on certain groups or individuals, but also prevents the Internet from being used to its full advantage.
In an attempt to balance the competing concerns of law enforcement, business, and individuals, a concept of key recovery has been proposed. The idea is that the key(s) used for encryption will be stored in a repository maintained by a bonded company that will only give up the keys when presented with a lawful warrant. It sounds nice in theory, but in practice has many problems that are not properly addressed. A thorough evaluation of key recovery was compiled by several noted cryptographers (Abelson, Anderson, Bellovin, Benaloh, Blaze, Diffie, Gilmore, Neumann, Rivest, Schiller, and Schneier) in the paper "The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption" and readers are encouraged to find a copy of this paper.
It should also be noted that, ignoring all the technological problems of implementing a key recovery infrastructure, there are also very serious civil liberty concerns. Few people have an implicit trust of their government and there is ample evidence of government agencies, from almost every country in the world, engaging in illegal collection of evidence and illegal spying. Making technological allowances for what is for all intents and purposes spying outrages many people. It may also be in violation of law in certain countries. The Fourth Amendment to the United States Constitution provides for search and seizure by lawfully authorized government agents, but nothing states that the targets of the search must make affirmative efforts to guarantee the success of the search. In fact, the Fifth Amendment states that a man cannot be forced to be a witness against himself, which is basically what forced key recovery is doing. This is an emotional issue that probably cannot be resolved. There are just too many strongly held beliefs on each side.
Cryptography is no longer a science reserved to governments or their militaries. The genie is out of the bottle, so to speak, when cryptographic tools are readily available at local computer stores or on the Internet. The notion of key recovery may be too late.
IPSec and Key Recovery
IKE uses an ephemeral Diffie-Hellman exchange to derive the shared secret used for IPSec key generation. Through the beauty of Diffie-Hellman, only the active participants in the exchange know the secret. Also, each flow (protected by a single SA or SA bundle) has unique session keys. There is no long-term secret (as in months or years) that could be stored with the key recovery center to enable key recovery of IPSec-protected sessions. The long-term keys IKE uses are for authentication only and there is no reason why these keys should be escrowed at a key recovery center. This makes key recovery in IPSec very problematic.
A proposal has been made on how to extend IKE to do key recovery. This proposal takes advantage of the fact that additional, optional payloads can be chained on to any IKE message. It also makes use of ISAKMP options for the commit bit flag and the authentication-only flag.
Remember, when the commit bit is used in an IKE quick mode exchange, the exchange is extended on a single message. This message is not very interesting and only consists of the authenticating hash and a message saying "I'm connected." There is nothing particularly secret there, and passing that final message in the clear would not be a serious detriment to the security of the overall quick mode exchange.
The key recovery extension to IKE passes this last message in the clear by setting the authentication-only (i.e., no encryption) flag. (The message remains authenticated because the hash is included, but none of the payloads are encrypted.) It also adds a new payload, a key recovery payload, to the message. This payload contains the SA information, including the keys, and is encrypted in the public key of the key recovery center.
To "recover" the keys, the agents send a copy of the key recovery payload to the key recovery center (along with their warrant, of course!). The payload is decrypted by the center and the resulting information SPI, algorithms, keys is given back to the agents who use it to decrypt the targeted traffic.
Interestingly, an IKE implementation that implements this proposal could interoperate with another implementation that doesn't. Of course, this has problems because it works only if the responder is the party that wishes to do key recovery. If the initiator of the quick mode desires to do key recovery (for whatever reason) and the responder does not, the key recovery payload will not be sent. The initiator has no way of forcing the responder to send this information. Should the initiator terminate the session because the key was not leaked? That's not really clear.
This proposal to add key recovery capability to IKE was not introduced in the IETF, where all the other documents that define IKE and IPSec were, because the IETF has made a public statement against key recovery. RFC1984 (the number selection was probably intentional) is the statement of the Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG) which formally declares the IETF's opposition to key recovery. Even without the formal statement represented by RFC1984 it is doubtful that the IPSec working group of the IETF would embrace this proposal. There are just too many technical, legal, and political issues that surround key recovery.
Top IPSec (2nd Edition) ISBN: 013046189X
EAN: 2147483647 Year: 2004
Pages: 76 Authors: Naganand Doraswamy, Dan Harkins
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |