52

At a large enterprise environment I have come across a deployment approach for Digital Certificates where each user is issued two (2) key pairs:

One for signing documents, emails, etc. that is completely "personal" (perhaps kept only by him in an e.g. smart card)

One for encryption. To avoid any situations of user unavailability, blackmail etc. encryption by this latter key pair can be circumvented by the key management system (using appropriate policies etc.)

This approach is supposed to safeguard from an administrator signing as a user but I find certain usage scenarios making things complicated. E.g. how about sending signed and encrypted emails? Two public keys maintained for each user in the contact list?

So, is this an overall preferred (and widely used) design? Or should we just use it in certain cases where prevention of impersonation is the highest priority?

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
George
  • 2,813
  • 2
  • 23
  • 39
  • Are you sure the organization does not simply have a purely technical need to generate two key pairs due to system design limitations? Also are you suggesting the enterpirse is only keeping one of the two private keys in escrow? – zedman9991 Nov 01 '11 at 12:29
  • Exactly. Just not "in escrow" but the solution is technically equivalent. – George Nov 01 '11 at 13:05
  • possible duplicate of [Why should one not use the same asymmetric key for encryption as they do for signing?](http://security.stackexchange.com/questions/1806/why-should-one-not-use-the-same-asymmetric-key-for-encryption-as-they-do-for-sig) – Iszi May 21 '15 at 15:12

2 Answers2

96

In a sane organization, it is actually necessary to have two distinct keys, one for signing and one for encryption.

When you receive some encrypted data (e.g. an encrypted email, as in S/MIME or PGP), you normally store the encrypted data (that's what happens by default for email). Therefore, if your private key becomes "unavailable", you cease to be able to read previously stored data: this is a data loss situation. "Unavailability" of the private key can take multiple forms, including hardware failure (your dog chew your smartcard to death) or "hardware" failure (the key holder is hit by a bus, or unceremoniously fired, and his successor should be able to read previously received business emails). To remove the risk of data loss through key loss, a backup of the private key must be stored somewhere (e.g. printed on a paper, in a safe)(this is often called escrow). In short words: encryption keys MUST be escrowed.

Loss of a signature private key does not imply any kind of data loss. Signatures which where previously generated keep on being verifiable. Recovering after a signature key loss involves getting a new key, and that's all. So there is no strong need for key backup here. On the other hand, signatures are normally meant to have legal value (there is little point in requesting a signature if you cannot use it against the signer, should he later on fail to follow on his promises). The legal value is conditional to the impossibility for any other individual than the key owner to generate a signature; this does not mix well at all with an escrow on the key. Hence, a signature key MUST NOT be escrowed.

Since a key cannot be both escrowed and non-escrowed simultaneously, you need two keys.

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 2
    Wow! Although I understood the possible advantages of having a two key solution I had never pinpointed it specifically to key escrow. Thanks for putting everything in perspective. – George Nov 02 '11 at 08:02
  • For completeness to add that in many commercial solutions (e.g. PGP Netshare, Microsoft EFS) encrypted material is safeguarded against key loss etc. not by duplicating the key but by creating a second administrator key with access to the data. – George Nov 02 '11 at 08:07
  • 4
    But if people can gain access to your escrowed private keys, they can decrypt your data! Why does your argument for the signatures not apply to encryption? – Elliot Gorokhovsky Mar 16 '15 at 04:55
  • 2
    @RenéG: From the perspective of an organization, members (usually employees) should not be able to essentially destroy data by deleting their private key, dying, etc.—hence, private encryption keys should be escrowed. On the other hand, for legal reasons members should not be able to sign as other members, and the organization should take measures to preclude this scenario—hence, private signature keys should NOT be escrowed. – Lawrence Velázquez Jun 01 '16 at 21:03
  • In the context of PGP, how is this handled in practice? I thought the master key always had encryption capabilities, _AND_ the master key is needed for other important things, such as issuing subkeys and revocation, which suggests that it MUST be escrowed, contradicting your point. Is this correct, or have I misunderstood something? – Betamos Feb 15 '17 at 02:18
  • Ah, I think I understand now. A signature contains the signature key. That means that _even if you have the master key_ you can't fake a signature with a subkey that you no longer have. This makes sense now. – Betamos Feb 15 '17 at 02:24
12

Using different keys for signing and encryption is quite common. Make sure to flag the keys appropriately.

A dedicated signing key, however, will offer no real protection against a rogue administrator. The admin is able to manipulate the application that is doing the signing. Note this is even true for smartcard: The administrator can manipulate the application that talks to the smartcard reader and submit manipulated data to it.

Smardcard readers with a display offer some protection, for e.g. money transfer. In most business cases, however, the signed information does not fit onto the display but is a pdf file.

Hendrik Brummermann
  • 27,158
  • 6
  • 80
  • 121
  • If an administrator can circumvent it, then why get into double the trouble? – George Nov 01 '11 at 13:06
  • I don't see how an admin can circumvent a smart card... Isn't it the case that the smart card is the only place the private key is stored? If the admin does not have access to the card, they have no way of generating a signature. No amount of "manipulating the application" will generate a fake signature (assuming the public key remains genuine). – SplashHit Nov 01 '11 at 20:53
  • 10
    The idea behind the attack is this: The user wants to sign document A, but in the background the manipulated application signs document B, then confirms to the user that document A was signed. Smartcard readers from banks prevent this kind of attack by displaying the amount and target of a money transaction on their own display. But this does not work for complex documents. – Hendrik Brummermann Nov 01 '11 at 21:22