My customer wants my organisation to evolve their system such that keys currently used to protect the confidentiality of other keys during transport are also used to protect data confidentiality in the same message. I suspect this might be a bad idea, but is that generally true in all cases, and if so why?

Further details

The KEKs are protecting keys being sent to the recipient in the present message. It is a layered key model; it doesn't matter what the transmitted keys are used for. The same message is sent to multiple recipients, but only a subset are permitted to access the keys it contains. My organisation is requested to use the same KEK to protect certain data in the message as well. As for the keys, only a subset of recipients are permitted to access that data. The point of the question is whether the protection of the data should be a separate concern from the protection of the keys.

More formally (as requested):

  • A posts message M to a public place where it can be retrieved by recipients B, C and D.
  • Message M contains sub-messages Mb, Mc and Md intended only for the corresponding recipient, B, C or D respectively.
  • Key Encryption Keys Kb, Kc and Kd have previously been issued to B, C and D via an offline medium.
  • Each sub-message Mn contains an encrypted key intended for recipient N, K'n, protected by the KEK previously issued: E(K'n, Kn).
  • Each sub-message Mn also contains plain text data, Di, intended for recipient I but currently readable to the other recipients. Under this evolution, this will be replaced with E(Dn, Kn).

So: A --> B, C, D: M

where (today):

M = E(K'b,Kb) + E(K'c,Kc) + E(K'd,Kd) + Db + Dc + Dd

and after the evolution:

M = E(K'b,Kb) + E(K'c,Kc) + E(K'd,Kd) + E(Db, Kb) + E(Dc, Kc) + E(Dd, Kd)

  • What are "other keys (protected) during transport"? How do they relate to the current transmission? If not at all, they are just data, like any other...
    – techraf
    Apr 17, 2016 at 8:30
  • @techraf These keys are the ones being sent to the recipient in the present message. It is a layered key model. It doesn't matter what they are used for. The point of the question is whether the protection of data should be a separate concern from the protection of keys.
    – D.H.
    Apr 17, 2016 at 9:27
  • If it doesn't matter enough to provide the information to potential answerers, I don't get what this question is about.
    – techraf
    Apr 17, 2016 at 9:42
  • @techraf I see your point. I've added more clarification to the question. Hopefully the context is clearer now and will enable you to ask more specific questions or actually answer the question.
    – D.H.
    Apr 17, 2016 at 10:31
  • Can you provide some pseudocode and "diagrams" to demonstrate what you are doing? The question as it stands is particularly verbose. e.g. E(M,K) encrypts message M with key K, and A --> B: E(M,K) depicts party A sending the encrypted message to party B. Apr 17, 2016 at 16:29

1 Answer 1


It seems OK.

Key Encrypting Key (KEK) is quite a confusing name. It puts emphasis on the fact that a particular key is used to encrypt another key (which in turn encrypts data), as if this bare fact somehow increased the security. It doesn't. The additional security comes from something else, and (by me) the name of this scheme should really be Separately Encrypted Key to reflect what really is important here.

The added security comes from the fact that software modules or people or devices that can see keys or data (either encrypted or plain) can be divided. You separate some inner environment and leave the rest in the outside security perimeter. The outside:

  • doesn't know the most important secret (aka the KEK)
  • but is more accessible to outsiders, as it provides many functions and needs to accept various data inputs

The inside has to be separate from this; it needs to have exactly opposite characteristics. The inside is typically just the key encryptor (a software module), key decryptor (ditto), the storage which holds the KEK (a software module or hardware device) and people who can access these.

In your situation, I understand customer requests to add some NewData (to be KEK-encrypted). I think it is safe if and only if is not exposing the Inside to any additional risks that is:

  • obtaining the NewData does not involve any additional risk; that is NewData does not come from the outside app perimeter, so it is injection/overflow free
  • delivering the NewData to destination does not involve any additional risk; doesn't require to contact any parts from the outside perimeter
  • (obviously) encryption and decryption of NewData is done by the same components that already know KEK - the KEK is not put at any additional risk by leaking it to some other components,
  • (obviously) you use a normal cipher, like AES, which is immune to known-plaintext attacks. The keys that you used to encrypt were pseudo-random, but NewData could be known to attacker,
  • (obviously) the NewData does not require any additional people to have access to the Inside.

If all these don't hold true you already have some starting points to analyze and communicate the risks involved.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .