A Pattern Language for Key Management

Pattern Language for Cryptographic Key Management

Sami Lehtonen VTT Information Technology E-mail: [email protected]

Juha Pärssinen VTT Information Technology E-mail: [email protected]

Abstract Many services in a distributed public network - like the Internet - require secure communications. Security in communications consists of confidentiality, integrity, authenticity, and non-repudiability. These aims can be achieved with cryptography. Key management plays a fundamental role in secure communications, as it is the basis of all cryptographic functions.

This paper describes a pattern language for key management. Ten patterns are described: Secure Communication, Cryptographic Key Generation, Session Key Exchange with Public Keys, Public Key Exchange, Public Key Database, Session Key Exchange with Server-side Certificate, Session Key Exchange with Certificates, Certificate Authority, Cryptographic Smart Card and Certificate Revocation. These patterns are designed to answer basic key management requirements in respect of secure communications.

1. Introduction

The aim of this paper is to present various solutions for key management in secure session- oriented communications. This information should make it easier to understand existing implementations. Each single process or communication phase has been written as a pattern. These patterns cannot be used alone as a basis for an implementation. However, most cryptographic algorithms are available off-the-shelf and this document can serve as a checklist when choosing algorithms.

A keying relationship is the state wherein communicating entities share common data (keying material) to facilitate cryptographic techniques. This data may include public or private keys, initialization values, and additional non-secret parameters. This fact leads to a definition of key management. Key management is the set of techniques and procedures supporting the establishment and maintenance of keying relationships between authorized parties. [Menezes96]

To ease up terminology we use the following dramatis personae throughout this document.

Alice First participant. Client A. Also known as initiator. Bob Second participant. Client B, Also known as responder. Eve Eavesdropper. Mallory Malicious active attacker. Trent Trusted arbitrator. Cast in a role of a certification authority (CA). Table 1. Dramatis Personae It is easy to refer to Alice as "she" and to Bob as "he" without a risk of misunderstanding. Capital letters indicate the role in communications. This naming system is widely used in literature and technical papers concerning cryptography. Schneier introduces this dramatis personae in [Schneier96]. Also other characters exist but only these are needed in this paper.

A basic key management system should be able to generate, store and exchange keys as well as to verify their authenticity. Additionally, it should be able to identify communicating parties. Usually, secure communications use symmetric keys for pure encryption (confidentiality and integrity) and asymmetric keys for symmetric key exchange and digital signatures.

Security in communications consists of confidentiality, integrity, authenticity, and non- repudiability. Confidentiality states that a message sent by Alice is only available to its intended receiver Bob. Integrity means that Bob should be able to verify that it has not been modified during the transfer. Authenticity means that Bob should be able to ascertain the origin of a message. Non-repudiability means that Alice should not be able to falsely deny that she sent the message.

In asymmetric encryption (Figure 1.), one key is used for encryption and another for decryption. In public key encryption, a pair of keys is generated; the public key is published and distributed to the public, and the private key is retained and kept secret by the owner. The public key is generated from the secret key with a one-way function. This allows Alice to encrypt a message using Bob's public key, thus ensuring that only Bob can decrypt the message using his own private key. Alternatively, When Alice encrypts data with her own private key, that data can only be decrypted using her public key. Thus, any user receiving the data encrypted with Alice's private key knows that the data could have come only from Alice. This is the essence of digital signatures, which ensure not only that the data came from a specific user, but also that the data was not altered during transmission. [Overview]

Plaintext Encrypt Ciphertext

Public

Private

Plaintext Encrypt Ciphertext Figure 1. Asymmetric encryption

In symmetric encryption (Figure 2.), the same key is used for both encryption and decryption. Access control is managed by key distribution-only those holding the key can read the data. If encrypted data is exchanged between two (or more) users, each must know the key for the data to be used. Asymmetric cryptography, described above, is sometimes used for this exchange of symmetric keys. [Overview]

Plaintext Encrypt Ciphertext

Plaintext Encrypt Ciphertext Figure 2. Symmetric encryption

Seeding material is used to generate keys (both symmetric and asymmetric). It is some random data from a source that is not available to any other than the key generator.

A certificate associates a public key with the real identity of an individual, server, or other entity, known as the subject. Information about the subject includes identifying information (the distinguished name), and the public key. It also includes the identification and signature of the Certificate Authority that issued the certificate, and the period of time during which the certificate is valid. It may have additional information (or extensions) as well as administrative information for the certificate Authority©s use, such as a serial number. [Hirsch1997]

2. Patterns

2.1 Common Key Management Patterns

2.1.1 Secure Communication

Context Alice wants to communicate with Bob but there might be somebody eavesdropping. They want to keep their secrets and not reveal them to Eve the eavesdropper.

Problem How to prevent data from being eavesdropped?

Forces Public encryption algorithms are widely tested and usually they are cryptanalyzed. On the other hand, secret algorithms aren©t more secure; they can (and usually will) be reverse-engineered. Symmetric cryptography is more effective than asymmetric cryptography in the means of key length. Symmetric algorithms require more complex key exchange. Asymmetric algorithms require more CPU power than symmetric algorithms. Encryption will cost you. More secure encryption usually needs more expensive system. Encryption must not be more expensive than the value of the data being encrypted.

Solution Alice and Bob use a public symmetric algorithm for encrypting data. They need much less CPU power with symmetric than asymmetric encryption. Alice uses some keying material to encrypt all data before transmission. Bob decrypts the data at the other end after receival. This is depicted in Figure 3. Plaintext Plaintext

A Encrypt Decrypt B

Public Ciphertext Internet Ciphertext

Figure 3. Alice and Bob use symmetric encryption.

Resulting Context Data is secured during the transfer. We have optimized the required processing power. Eve can©t directly read the data.

Implementation Examples When browsing the net, Alice can be quite sure there is somebody eavesdropping somewhere between her and the server. Banks, for instance, use Transport Layer Security (TLS), to secure their web applications. TLS is formerly known as Secure Sockets Layer (SSL). There are several secure symmetric algorithms (3DES, blowfish and IDEA just to name few) that are used to secure network connections.

Related Patterns Alice and Bob decided to use symmetric encryption to secure data during transfer. This introduces a new problem; how to create a good key and furthermore how to deliver it. These problems are solved in Cryptographic Key Generation and in three different Session Key Exchange patterns.

2.1.2 Cryptographic Key Generation

Context Secure communications between Alice and Bob are possible with encryption. Alice and Bob have decided to use symmetric encryption.

Problem How to generate good symmetric encryption keys securely?

Forces A weak key generation algorithm is easier to cryptanalyze than strong encryption algorithms. More bits in the seed of the random number generator means more secure. On the other hand, seeding material is not easy to gather, so it should be as long as (or a bit longer than) the session key needed. A strong key generation algorithm requires a random number generator for generating seeding material. A key generator algorithm generates always the same output with the same seeding material. A pseudo-random number generator is easier to implement and it can be cryptographically secure. Pseudo-random number generator can be secure if we use a one-way hash function and keep the seeding material secret. A session key should be long enough. A longer key requires more processing power to be cracked with brute force. Right now, a key of 128 bits long can be considered secure, but some export restrictions may force the use of a key of 56 bits maximum. If a session key is too long it requires too much processing power to be used. Every year and a half doubles processing power, which basically makes one bit uneffective. Solution Alice follows these steps: 1. Alice gathers enough seeding material from a reliable source. 2. She generates a 128-bit key with a one-way hash function from that seeding material. 3. Alice compares the generated key against a list of known weak keys of the encryption algorithm to be used. If the key is known to be weak, she goes to step 1.

This session key is used only in one particular communication session.

Resulting Context Alice and Bob are able to create strong session keys for symmetric encryption. Eve can©t crack the encrypted data even if she knows the key generation algorithm, because she can©t limit the possible seeds to a reasonably small group (furthermore, the possible session keys). The session key is the real thing in cryptography.

Implementation Examples When Alice opens a Transport Layer Security (TLS) secured web page, her browser generates a symmetric session key to be used in transfer.

Time between falls of a toddler learning to walk is truly random. Of course, this is not very easy to measure. An excellent random source is a piece of plutonium. The time between radiating gamma particles is random, allthough it slowly gets longer while your lifetime may get shorter. Westphal Electronic [Westphal] offers a computer attachable thermal noise based true random bit generator, which is capable of generating 800 000 random bits per second.

Related Patterns This pattern solves the problem introduced in Secure Communication. Now Alice and Bob have a problem with exchanging the session key that Alice just created. This problem can be solved in different ways. The first solution is presented in Session Key Exchange with Public Keys, second in Session Key Exchange with Server-side Certificate and third in Session Key Exchange with Certificates.

2.2 Key management without Trent's help

2.2.1 Session Key Exchange With Public Keys

Context Alice and Bob are going to encrypt data to be transferred between them. Alice has created a session key. They don©t have certificates because certificates are expensive.

Problem How to securely deliver the session key?

Forces Alice and Bob could have used a key determination algorithm to create and exchange the session key. However, this is vulnerable for man-in-the-middle attack if the participants are not authenticated. In a relatively small group of friends, it©s possible to manage everyone©s public keys, but for a Bob©s web store with millions of potential customers this isn©t the case. Certificates are expensive and Alice may not really need one or she has one on a smart card but does not have access to a smart card reader at the moment.

Solution Authentication requires digital signatures and furthermore, certificates or public keys. Alice encrypts the session key with Bob©s public key, adds a digital signature with her private key and sends it to Bob. Bob can verify the digital signature with Alice©s public key and decrypt the session key with his private key. Session key exchange is depicted in Figure 4.

Session key Session key A B

Bob's public key Private key of Bob Encrypt Decrypt

Private key of Alice Send Alice's public key Signature Verify Figure 4. Session key exchange with public keys

Resulting Context Alice can be sure that she is communicating with Bob because only Bob can decrypt the session key. Bob can also be sure he got the session key from Alice. Both of them have a digital verification of each other©s identities. The algorithms used to generate the keys are not restricted to key determination algorithms.

Implementation Example IPSec tunnel could be set up with pre-shared key configuration. For this purpose, PGP public key encryption could be used to secure the sharing of keys.

Related Patterns This pattern solves the problem of key delivery, which was introduced in Cryptographic Key Generation. Other solutions are presented in Session Key Exchange with Server-side Certificate and Session Key Exchange with Certificates. However, using this pattern leads to another problem. Alice and Bob need to exchange their public keys. This problem is solved in Public Key Exchange.

2.2.2 Public Key Exchange

Context Alice and Bob are going to encrypt data to be transferred between them. They have decided to use public key encryption for session key transfer. Alice and Bob have created asymmetric key pairs. a) They live in the same city, or b) on different continents.

Problem How to exchange public keys? Forces If public keys are sent over a network, Mallory could send the public key to Bob and pretend to be Alice. Bob could not know if it is Alice or not. Other possible threat is a man-in-the-middle attack. Mallory listens to a communication between Alice and Bob, and when they are exchanging their public keys Mallory hijacks those packets and replaces them with others. After this she simply decrypts the session key that Alice sends and encrypts it with another key and forwards it to Bob. Public keys could be in any format when traded, but it is convenient to hand them over in a digital format. Integrity could be assured by using a one-way hash of the public key that is delivered by phone or by keeping the public key always at hand and never let anyone to get hands on it. Authenticity can be assured by recognizing the other party. Alice really sees Bob or talks on the phone and verifies Bobs authenticity by voice and possibly some questions.

Solution Depending on the context either a) Both Alice and Bob write their public keys on a digital media (a floppy disk, for example). They meet each other face-to-face and hand over their public keys. Alice talks with Bob and may even see his driving license. Alice can be sure about Bob©s identity. b) Alice sends her public key to Bob via e-mail. Alice calls Bob, they talk to each other, and after she has verified Bob©s identity she tells a hash generated from her public key. Bob sees if the public key arrived unmodified by regenerating that same hash.

Resulting Context Alice and Bob can identify each other. In other words, they can be sure they got the public key from the real owner of that particular key.

Implementation Example People who use PGP (Pretty Good Privacy) use both of these solutions.

Related Patterns This pattern solves the problem of exchanging public keys that Session Key Exchange with Public Keys rises. Both Alice and Bob need a place to store other people©s public keys. This problem is solved in Public Key Database.

2.2.3 Public Key Database

Context Alice and Bob have created asymmetric key pairs and swapped their public keys. They may have several other public keys from other people.

Problem How to assure integrity and authenticity of public keys without losing accessibility?

Forces The private key must be available only to Alice, while public key must be easily distributed. Integrity of all keys must be ensured. Encrypting all keys will affect accessibility. Session keys must be accessible but they should not be kept outside the encrypting device or software. Solution Alice saves her private key on a digital media (a floppy disk, perhaps) and puts it in a place that is not accessible to others. She puts her public key on a floppy disk and makes some copies to be delivered to her friends. Other people©s public keys don©t need encryption but their integrity must be assured. Alice adds a digital signature, which is a calculation of her private key and the public keys in her database, and stores a backup copy of the key database in a safe place. If someone modifies Alice©s key database the digital signature won©t match anymore revealing the attempt to attack. If this happens, Alice can always fetch the backup copy.

Resulting Context Alice doesn©t need an additional password for her key database. Alice can check the integrity of stored public keys by verifying the digital signature. If the database is modified and/or corrupted she can restore the backup copy.

At this time, Alice and Bob are ready to start communicating with encrypted connections.

Implementation Examples PGP public keys may be stored in a similar way.

Related Patterns This pattern solves the public key storing problem that arose with the use of Public Key Exchange.

2.3 Key management with Trent

2.3.1 Session Key Exchange With Server-side Certificate

Context Alice and Bob are going to encrypt data to be transferred between them. Alice has created a session key. Alice wants to remain anonymous or she doesn©t have a certificate. Bob doesn©t care who Alice is. Both Alice and Bob know Trent. They trust him.

Problem How to deliver the session key?

Forces In a relatively small group of friends, it©s possible to arrange all public key exchanges as described in 2.2.2, but for a Bob©s web store with millions of potential customers this isn©t the case. Certificates are expensive and Alice may not really need one or she has one on a smart card but does not have access to a smart card reader at the moment. It is always polite to introduce oneself, but it might not be smart to leave a non- repudiable fingerprint if not forced to.

Solution Bob sends his certificate (public key is certified) to Alice. Alice verifies from Trent that the certificate is valid and then encrypts the session key with Bob©s public key and sends it to Bob. Bob decrypts the session key with his private key. Session key exchange with Bob©s certificate is depicted in Figure 5. Certificate 2. Valid? 1. Send T A B

Bob's public key Private key of Bob

Session key Session key Encrypt Decrypt Figure 5. Session Key Exchange with Bob's certificate

Resulting Context Bob gets the session key from Alice. Alice can be sure that she is communicating with Bob because only he can decrypt the session key. Alice never reveals her identity to Bob.

Implementation Example Web stores implement this pattern. Order buttons at web stores usually redirect the user to a TLS secured web page for entering credit card information. These web servers don©t really care who the user is. All that interests the store keeper is the credit card number.

Related Patterns This pattern solves the problem of key delivery, which was introduced in Cryptographic Key Generation. Other solutions are presented in Session Key Exchange with Public Keys and Session Key Exchange with Certificates. However, using this pattern leads to another problem. Bob needs a certificate from Trent. This problem is solved in Certificate Authority. Alice needs to know whether Bob©s certificate is valid or not. This is solved in Certificate Revocation.

2.3.2 Session Key Exchange With Client and Server-side Certificates

Context Alice and Bob are going to encrypt data to be transferred between them. Alice has created a session key. Both Alice and Bob require authentication. They know and trust Trent.

Problem How to deliver the session key?

Solution Alice and Bob exchange their certificates (public keys are certified). They both verify each others certificates from Trent. Alice encrypts the session key with Bob©s public key, adds a digital signature with her private key and sends it to Bob. Bob can verify the digital signature with Alice©s public key and decrypt the session key with his private key. Session key exchange with both sides certified is depicted in Figure 6. T

2. Valid? 2. Valid?

Certificate 1. Exchange A B

Session key Session key

Bob's public key Private key of Bob 3. Encrypt 6. Decrypt

Private key of Alice Send Alice's public key 4. Signature 5. Verify Figure 6. Session key exchange with both sides certified.

Resulting Context Bob gets the session key from Alice. Bob can also be sure he got the session key from Alice by verifying the digital signature with her public key. Alice can be sure that she is communicating with Bob because only Bob can decrypt the session key. Both of them have a digital verification of each other©s identities.

Implementation Example A smart card could be used to authenticate a user of an electronic bank application. A pin number prevents non-authorised use of the smart card.

Related Patterns This pattern solves the problem of key delivery, which was introduced in Cryptographic Key Generation. Other solutions are presented in Session Key Exchange with Public Keys and Session Key Exchange with Server-side Certificate. However, using this pattern leads to two new problems. Alice and Bob need to obtain certificates from Trent. This problem is solved in Certificate Authority. Alice needs to know whether Bob©s certificate is valid and vice versa. This problem is solved in Certificate Revocation.

2.3.3 Certificate Authority

Context Alice wants to exchange keys with certificates. Alice knows a trusted person, Trent.

Problem Alice needs a certificate.

Forces Sometimes Alice and Bob are not able to exchange their public keys themselves. A certificate signed by Trent can be used with anybody who knows Trent. Solution Alice calculates an asymmetric key pair and sends the public key to Trent. Trent creates a certificate for the public key. He adds a digital signature to the certificate. Trent delivers the certificate to Alice. This certification process is depicted in Figure 7.

Certificate

2. Create A a certificate T

1. Generate a key pair

Private key 2. Public key to Trent Public key

Figure 7. Certificate creation

Resulting Context The certificate and the certified key pair has to be stored somewhere.

Implementation Example There are companies that offer certificates for web servers. For example, [Verisign] can create key pairs and certify them. In Finland, The Finnish Population Register Centre acts as certificate authority.

Related Patterns This pattern solves the problem of obtaining certificates that was introduced in both Session Key Exchange with Server-side Certificate and Session Key Exchange with Certificates. Having a certificate rises a problem of a secure storage for it. This problem will be solved in Cryptographic Smart Card pattern.

2.3.4 Cryptographic Smart Card

Context Alice has her certified public key and a private key.

Problem Alice needs a storage for her keys.

Forces The authenticity and integrity of stored keys must be ensured without loosing accessibility. The private key must be available only to Alice.

Solution Alice©s key pair and certificate are stored on a smart card, which handles the use of these. Even Alice herself cannot read the private key. Resulting Context Alice has her key pair and certificate in a place she can easily access. A psychological benefit of smart card is that people understand physical keys, what they signify and how to protect them. Putting a cryptographic key in the same physical form makes storing and protecting that key more intuitive [Schneier96].

Implementation Example The Electronic ID Card [FinSmartCard] by the Finnish Population Register Centre contains an asymmetric key pair and a certificate. This card can be used as authentication when using web services provided by the Finnish authorities and some banks.

Related Patterns This pattern solves the problem of storing a certificate, which was introduced in Certificate Authority.

2.3.5 Certificate Revocation

Context It is possible that a certificate becomes insecure (the private key is compromised, for example). However, when exchanging the session key with certificate(s) Alice needs to know whether Bob©s certificate is valid or not.

Forces Alice has Trent©s public key. This key can be used to verify the digital signature in a certificate. The verification of the digital signature ensures that the certificate was - at one particular moment in the past - valid. It still may be.

Solution If Alice notices that her private key has been compromised, she informs Trent about it. Trent maintains a list of invalid certificates that have not been expired. This list is called a Certificate Revocation List (CRL). The CRL has it©s own expiration time, which is shorter than certificate©s.

Alice gets the CRL from Trent and stores it. When the CRL expires she gets a new CRL. When Alice gets a certificate from Bob she looks at the CRL if the certificate has been revoked. If Alice and Bob communicate with each other again and Alice has not obtained a new CRL there is no need to look again.

Implementation Example Certificate providers, such as [Verisign], have their own CRLs.

Related Patterns This pattern solves the problem introduced in Session Key Exchange with Certificates and Session Key Exchange with Server-side Certificate. 3. Conclusions and Future Work

Growing awareness of information security and the use of secure communciations have made cryptography an essential feature in many applications. Although these patterns do not answer the whole cryptographic problem domain - the scope of this paper is in cryptographic key management - they are handy when a software engineer wants to know how these things work. The cryptographic problem domain is considered in [TROPYC]. Other cryptography related patterns can be found in [Schumacher].

In the future, some java examples will make this paper more useful. The addition of rationales would explain further the use of these particular solutions.

4. Acknowledgements

We would like to thank our shepherd Andreas Rüping for showing us the way. Thanks to our workshop team at EuroPLoP2002. Also, we would like to thank Klaus Marquardt for shepherding us last year and all participants of our workshop at PLoP2001 for creative ideas that helped us to improve the paper. Last but not least, we would like to thank the PLoP2001 crew and attendees for making the conference a pleasant experience at such a hard time. References

[FinSmartCard] http://www.sahkoinenhenkilokortti.fi/default.asp?todo=setlang \ &lang=uk

[Hirsch1997] Frederick J. Hirsch, Introducing SSL and Certificates using SSLeay, World Wide Web Journal, Summer 1997 http://www.ultranet.com/~fhirsch/Papers/wwwj/article.html

[Menezes96] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1996

[Overview] http://www.itsc.state.md.us/info/internetsecurity/Crypto/ \ CryptoOverview.htm

[Schneier96] Bruce Schneier, "Applied Cryptography", Wiley & Sons, 1996

[Schumacher] http://www.securitypatterns.org

[TLS99] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, 1999

[TROPYC] Alexandre M. Braga, Cecilia M. F. Rubira, Ricardo Dahab, Tropyc: A Pattern Language for Cryptographic Software, PLoP-98

[Verisign] http://www.verisign.com

[Westphal] http://www.westphal-electronic.de