S E C U R I T Y
Identity-Based Encryption Comes of Age Luther Martin Voltage Security
Public-key technology is due for another round of useful innovations.
O
n June 3 and 4, 2008, the National Institute for Standards and Technology (NIST) held the Applications of Pairing Based Cryptography: Identity Based Encryption and Beyond workshop (www.nist.gov/ibe). Significantly, identity-based encryption (IBE) has now received enough interest to warrant such a workshop, which probably indicates the technology’s general acceptance. But a look at the history of public-key cryptography shows that IBE is just one of the many steps in the technology’s evolution.
public-key evolution
The history of public-key cryptography began in 1977 when Whitfield Diffie and Martin Hellman invented the Diffie-Hellman key exchange (www.bletchleypark.net/cryptology/ Diffie_Hellman.html). This lets two parties agree on a shared secret that they can then use to encrypt sensitive information. In 1978, Ron Rivest, Adi Shamir, and Ken Adelman (R.L. Rivest, A. Shamir, L. Adleman, “A Method for Obtaining Digital Sig-
natures and Public-Key Cryptosystems,” Comm. ACM, vol. 21, no. 2, 1978, pp. 120-126) invented the RSA scheme, which added the ability to encrypt information and create digital signatures. Later in 1978, Loren Kohnfelder invented digital certificates (L. Kohnfelder, “Toward a Practical Public-Key System,” BSc thesis, MIT Dept. of Electrical Engineering, 1978), the technology that allowed the creation of the public-key infrastructure (PKI). Since this initial burst of innovation, researchers have published hundreds of papers that describe new publickey schemes. Most of these remain of purely academic interest, but now and then an idea worth implementing comes along. Examples of this include ElGamal encryption (1984), elliptic curve cryptography (1985), and the Menezes-Qu-Vanstone (MQV) authenticated key exchange (1995), each of which commercial products now implement. Despite more than 30 years of research and development, some practical issues still limit the widespread use of public-key technology.
Many of these relate to the challenges involved in using the version of PKI that became standardized, and not to public-key technology in general.
less than ideal
PKI proved useful, but it can still be difficult to implement, which has limited its acceptance and use. Although it sounds easy, finding a user’s public key actually presents a tricky problem for which no good solution has been found. Digital certificates can have lifetimes of a year or more, so it’s often necessary to ensure that they are still valid before using them. This problem has proven fairly challenging in practice.
Backup and recovery
A PKI system must also back up encryption keys securely. This ensures that the loss of a private key does not result in the loss of all the data encrypted with it. Key recovery—a necessary feature of any system used to encrypt business data—also adds complexity to a system and creates a good target for an attacker. If attackers can compromise a key recovery system, potentially they can get any private key the keyrecovery system manages.
Success with SSL/TLS
Probably the most successful application of PKI, the SSL/TLS protocol identifies web servers and encrypts connections to them. The success of SSL/TLS rests on its ability to avoid some of the problems that make other PKI applications tricky to use: SSL/TLS requires no key lookup, no key recovery, and few SSL/TLS clients actually perform key validation. Aside from SSL/TLS, other PKI uses have not been as successful. In 1984, Adi Shamir proposed IBE as a potential alternative to PKI (www. iseca.org/downloads/Shamir47.pdf), arguing that IBE would be simpler and easier to use than existing public-key technologies. August 2008
93
S E C U R I T Y
Public parameter server
Private-key generator
Private key
Public parameters
certificate authority (CA). If attackers compromise a CA’s private key, at worst they can forge certificates and certificate revocation information. In an IBE system, however, if adversaries can compromise a PKG, they can use the PKG to calculate any private key they want. So in a PKI, the PKG’s security becomes as important as the key recovery system’s security.
Securing IBE
Alice
Bob Encrypted message
Figure 1. IBE system operation. With this public-key technology the sender of a secure message calculates the recipient’s public key from an arbitrary string that represents the recipient’s identity.
Identity-based Encryption
IBE is a public-key technology in which a secure message sender calculates the recipient’s public key from an arbitrary string that represents the recipient’s identity. The recipient of an IBE-encrypted message then downloads the corresponding private key from a secure server called a private-key generator (PKG). This contrasts with other publickey technologies in which private keys are either random or calculated from random components. Another feature defining an IBE scheme is that users can calculate any public keys they want after fetching just a single set of public parameters from a public parameter server (PPS). This means that a system in which a user retrieves public keys from a server does not qualify as an IBE system, even if the server calculates public keys from users’ identities. Figure 1 shows the operation of an IBE system. IBE solves some of the practical difficulties that have plagued PKI. Because IBE public keys are calculated, the problem of looking up a user’s public key no longer exists. And because it’s relatively easy to 94
Computer
calculate IBE public keys, it’s also possible to change them frequently. Using short-lived keys makes it possible to address the problem of ensuring that keys are valid before using them.
Inventing a practical and secure IBE scheme has proven to be a significant research problem for cryptographers, but Dan Boneh and Matt Franklin finally invented the first secure and practical IBE scheme in 2001 (http://crypto. stanford.edu/~dabo/papers/bfibe. pdf), 16 years after Shamir first proposed the idea. Since then, the technology has gained rapid acceptance. By the most conservative estimate, worldwide at least 6 million people currently use IBE, a level of acceptance apparently sufficient to justify NIST holding a workshop to discuss the technology and its uses.
Offline operation
The requirement for offline operation also proves useful in many cases. In large, distributed computing environments, many network connections might be down at any given time. In practice, commonly 2 percent of such connections can be down. The possibility of being unable to immediately encrypt data 2 percent of the time might be acceptable to individual users, but businesses that must encrypt all sensitive data to be regulatorycompliant face an unacceptable level of risk if unable to encrypt data during such a network outage.
Limitations
On the other hand, IBE also has limitations that other public-key technologies might not have. IBE use is limited to encryption, such that creating digital signatures requires another public-key technology. A PKG is also more sensitive than a
NIST Workshop
In addition to giving an overview of the technology and its applications, presenters at the 2008 NIST IBE Workshop discussed the reasons behind IBE’s rapid adoption, applications that both researchers and commercial customers have found for IBE, and potential next steps in the technology’s evolution. All the workshop’s presentations can be accessed from the its website (http://csrc.nist.gov/groups/ST/IBE/ ibe08_agenda.html).
Panel discussion
An especially interesting part of the workshop, the panel discussion—“Identity-Based Encryption: Is It Needed?”—featured both outspoken proponents and opponents of the technology. A common theme at the NIST IBE Workshop was the assertion that IBE allows construction of simpler
systems. These systems are in turn cheaper and easier to operate than traditional PKI systems. One speaker discussed research that suggested IBE systems are approximately three to five times cheaper to operate than traditional PKI systems, which might explain IBE’s relatively rapid adoption. So although there is essentially no IBE system property that can’t be duplicated or emulated with other cryptographic technologies, there might be cases where there is good reason to use IBE instead of more traditional techniques.
key calculations
Another theme was how the ability to calculate keys makes it possible to encrypt information for users without needing them to enroll in an IBE system. This means that it’s possible to encrypt information to users without requiring that they enroll in another system. It’s then possible to use any existing identity-management infrastructure to authenticate users before granting them their IBE private keys.
This can be particularly useful in cases where it’s not practical to enroll a large number of users, either due to the costs involved or because it’s not known in advance who the users will be. A large bank, for example, might not want to require its customers to enroll in a separate encryption system due to the support costs involved. Or a government agency that coordinates responses to disasters might not know exactly what other organizations it will need to communicate with in the event of a disaster: a chemical spill in Maryland requires a completely different set of responders than a hurricane in Texas, for example. Along with adoption comes standardization, and IBE has already made some progress in this area. RFC 5091 (www. ietf.org/rfc/rfc5091.txt) defines two IBE schemes, and the IEEE P1363.3 Standard for IdentityBased Cryptographic Techniques using Pairings (http://grouper.ieee. org/groups/1363/IBC/) should be complete in 2009. NIST’s interest in
the technology indicates that there might even be government standards activity soon.
U
seful innovations in publickey technology seem to come along every few years. It has been quite a while since IBE’s invention, which means we might be due for another innovation soon. It will be interesting to see how the technology evolves. Look for another workshop from NIST in the future that will discuss whatever comes next. ■ Luther Martin is the chief security architect at Voltage Security. Contact him at
[email protected].
Editor: Jack Cole, US Army Research Laboratory’s Information Assurance Center,
[email protected]; http:// msstc.org/cole
Silver Bullet Security Podcast I n - d e p t h i n t e r v i e w s w i t h s e c u r i t y g u r u s . H o s t e d b y G a r y M c G r a w.
w w w.c omput er.or g /s e c ur it y /po dc as t s Sponsored by
August 2008
95
