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.