Vrftjkry

Wikipedia says:

Key Wrap. Key Wrap constructions are a class of symmetric encryption algorithms designed to encapsulate (encrypt) cryptographic key material. The Key Wrap algorithms are intended for applications such as protecting keys while in untrusted storage or transmitting keys over untrusted communications networks.

Now key wrapping needs another key for wrapping. Isn't it like a chicken-egg problem. We now need to protect another key.

If someone needs to transfer key over network, wouldn't he/she use SSL/TLS rather than wrapping key?

For storing keys, wouldn't someone use the password protected keystore?

It all depends on the key wrapping used. Key wrapping is little more than encryption of a key with another key. Although key wrapping schemes certainly exist (and are considered rather secure in general) other key schemes may use common methods of encryption, both symmetric and asymmetric. And in the end, how strong the encryption is depends on the method used.

I've seen AES keys being encrypted using AES-CBC, which is perfectly fine for AES-128 and AES-256 keys. Wrapping an AES-192 key that way could already make it vulnerable padding oracle attacks. Encrypting a structured RSA key using CBC and an IV of zero bytes (as used by many HSM's) may even passively leak information to adversaries.

Encryption itself is already a chicken egg problem. You've got this data you want to keep confidential. Now you can encrypt it, but you'd need to secure the key now.

So why is encryption or wrapping useful? Well, not all keys have the same properties. Some keys such as public key for asymmetric systems can be distributed using a public key infrastructure, but they can perfectly use to wrap AES keys to perform key establishment. Other keys are distributed in advance, taking advantage of the moment in time that the key can be established. Yet others take advantage of hardware protection in HSMs or smart cards. So key wrapping is an important tool to perform key management. Note that one wrapping key can be used to wrap many other keys.

As for your examples: yes, a key can be transported over TLS. However, TLS is point to point transport security. After TLS is stripped you'd just have the key. It is much more secure to wrap the key and provide end-to-end security. With a bit of luck the key may be unwrapped directly within a HSM and never even appear in memory. Note that earlier forms of TLS, the TLS_RSA ciphersuites, actually perform a form of key wrapping to establish the master secret to derive the session keys from.

A password protected store can be used. Often the keys in those key stored can be protected separately as well. PKCS#8 could be seen as a high level form of key wrapping, for instance.

However, such key stores are not always useful. For instance, you may want to wrap a key in a HSM to sync it with another HSM. In that case you'll need a wrapping key in both devices. Generally HSM's cannot simply create a password protected key store for that.

Similarly, a device can offload wrapped keys if the memory is limited. This is a common method within TPM modules in PC's: instead of having a high end smart card chip, keys are wrapped with a TPM specific key and stored on the system's drive. When they are needed they are simply put back and used. This way the keys can be secure both at rest and when in use, even though they are not stored in the hardware device.

Wrapping / unwrapping a single symmetric key with another symmetric key that has the same access level probably doesn't make too much sense. But for key management key wrapping is a very important - if not essential - tool.

It's not meant to provide extra security in a quantifiable sense. It's supposed to provide other security advantages, like for example, serve as a tool for key management systems.

One example is what in some systems is called envelope encryption, where there are two kinds of encryption key:

• 
  Key encryption keys, also known as KEKs or master keys


• 
  Data encryption keys, also known as DEKs

There is a key management system (KMS) that owns the KEKs and works as a server. To encrypt data, clients follow this protocol:

1. Client requests a fresh DEK from the KMS


2. The KMS logs the request, generates a fresh DEK, and returns two versions thereof—one plain, one wrapped with the KEK


3. The client encrypts data with the plain DEK


4. The client writes out the wrapped DEK to storage along with the data ciphertexts, and discards the plain DEK.

To decrypt data:

1. Client reads ciphertext and wrapped DEK from storage


2. Client requests from the KMS that it unwrap the DEK


3. The KMS logs the request, authenticates the client and checks that it's authorized for that DEK


4. If so, the KMS unwraps the DEK and sends the result to the client


5. Client uses decrypted DEK to decrypt the data

Some advantages of such a setup are:

• Properly implemented clients don't store long-term data encryption keys.


• The KMS authenticates clients, enforces authorization policies, and logs all operations. So you can for example quickly revoke access to a client if you suspect it's been compromised, and identify which DEKs it managed to get the KMS to unwrap for it.

But as I said, these don't amount to a quantifiable improvement of security in the sense of "the encryption got stronger." They're practical architectural improvements over more naïve approaches to key management (e.g., using a single long-term key to encrypt all data, and putting copies of that key on all of your machines).