Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
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 1 '11 at 12:29
    
Exactly. Just not "in escrow" but the solution is technically equivalent. –  Georgios Nov 1 '11 at 13:05

2 Answers 2

up vote 24 down vote accepted

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.

share|improve this answer
    
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. –  Georgios Nov 2 '11 at 8: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. –  Georgios Nov 2 '11 at 8:07

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.

share|improve this answer
    
If an administrator can circumvent it, then why get into double the trouble? –  Georgios Nov 1 '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 1 '11 at 20:53
4  
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 1 '11 at 21:22

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.