One-Pass HMQV and Asymmetric Key-Wrapping [chapter]

Shai Halevi, Hugo Krawczyk
2011 Lecture Notes in Computer Science  
Consider the task of asymmetric key-wrapping, where a keymanagement server encrypts a cryptographic key under the public key of a client. When used in storage and access-control systems, it is often the case that the server has no knowledge about the client (beyond its public key) and no means of coordinating with it. For example, a wrapped key used to encrypt a backup tape may be needed many years after wrapping, when the server is no longer available, key-wrapping standards have changed, and
more » ... ven the security requirements of the client might have changed. Hence we need a flexible mechanism that seamlessly supports different options depending on what the original server was using and the current standards and requirements. We show that one-pass HMQV (which we call HOMQV) is a perfect fit for this type of applications in terms of security, efficiency and flexibility. It offers server authentication if the server has its own public key, and degenerates down to the standardized DHIES encryption scheme if the server does not have a public key. The performance difference between the unauthenticated DHIES and the authenticated HOMQV is very minimal (essentially for free for the server and only 1/2 exponentiation for the client). We provide a formal analysis of the protocol's security showing many desirable properties such as sender's forward-secrecy and resilience to compromise of ephemeral data. When adding a DEM part (as needed for key-wrapping) it yields a secure signcryption scheme (equivalently a UC-secure messaging protocol). The combination of security, flexibility, and efficiency, makes HOMQV a very desirable protocol for asymmetric key wrapping, one that we believe should be incorporated into implementations and standards. For example, consider a typical tape-encryption setting, where backup tapes are encrypted and then stored for future need by a potential client Alice who may need them one day. To enable decryption, Bob "wraps" the encryption key under some public key and stores the wrapped key to the tape itself. Note that Alice is off-line (or perhaps does not even exist) when the encryption key is wrapped, so no interaction can take place. Later, when Alice comes to need the backup tape, she asks her key-management module for the private key corresponding to the public key used by Bob, and then she can unwrap the decryption key and decrypt the backup tape. Such one-way communication can be viewed as one-pass key-exchange protocols with implicit client authentication (and in some cases also server authentication). In the case that a pre-set key is transmitted (as in the tape encryption example), the operation is referred to as key wrapping. Key-wrapping (and key-management in general) is a topic of intensive activity in the industry, with many competing services and many standardization efforts (e.g., PKCS #11, FIPS SP 800-57 and 800-130, IETF KeyProv, OASIS KMIP, IEEE 1619.3, IEEE P1363, etc.) Symmetric key-wrapping was addressed in the work of Rogaway and Shrimpton [16] and later Gennaro and Halevi [8], with a focus on using deterministic encryption for this purpose. In this work, however, we focus on asymmetric key-wrapping, where Bob uses Alice's public key to wrap the symmetric key. In this context the added complexity of using randomization is insignificant in comparison to the public-key operations that are needed. Hence we just use standard encryption, and view key-wrapping as a target application rather than a separate security goal. Many real-world implementations of asymmetric key wrapping are based on RSA, but the increase in the use of elliptic-curve cryptosystems suggest that they will be useful for key wrapping as well. The leading mechanisms in this respect is the "elliptic-curve integrated encryption scheme" (ECIES) [12], which is based on the "Diffie-Hellman integrated encryption scheme" (DHIES) encryption scheme of Abdalla et al. [1] . DHIES is an Elgamal-based encryption scheme, proven CCA secure under the "hashed Diffie-Hellman" assumption. (Alternatively, under the Gap Diffie-Hellman assumption in the random-oracle model.) On a high level, in DHIES Alice has a secret exponent a, and the corresponding public key is the group element A = g a (where g is a generator in a prime-order group). To encrypt a message M , Bob chooses a random exponent y and computes Y = g y , then computes the Diffie-Hellman value σ = A y and uses K = H(σ, Y ) as a key in a symmetric-key authenticated-encryption scheme to encrypt M . Note that DHIES is an instance of the KEM/DEM paradigm [17] . When used for key-wrapping (i.e., when M is a cryptographic key), this encryption scheme can also be viewed as a key-exchange protocol where only the client is implicitly authenticated. However, there are applications where the server too should be authenticated. For example, consider the tape-backup application from above where Alice is a third party that provides backup/restore services. When Alice gets a tape with a wrapped key on it, she wants to consult the policy of the original server Bob to know if decryption is permitted. So in particular Alice needs to be able to authenticate the source of the wrapped key.
doi:10.1007/978-3-642-19379-8_20 fatcat:ysd6chk44fhajolaof6x3alrwe