Watch out, because key escrow can create a new security vulnerability
You might think that archiving the private key of everyone within an organization would be a good thing.
You might think that archiving the private key of everyone within an organization would be a good thing.
After all, that way you can decrypt data even if an employee moves to another job or dies, or if the device is taken out of service.
But despite the government's desire that all encryption keys be stored, or escrowed, so that law enforcement agents can decrypt messages with criminal content, key escrow tends to degrade a system's security.
A key escrow system becomes an incredibly appealing target for attackers.
Successfully breaking into a key escrow system means compromising not just that system but any system under the control of any entity holding one of that system's certificates.
Open invitation
Compromising an agency's escrow system means that every system on every network is open to the attacker.
It also means that every bit of data ever encrypted with any of those keys is now susceptible to being decrypted by the attacker.
This raises a second problem with key escrow: backward security. A compromised certificate can be revoked, but if the private key of a public-key pair is compromised, none of the data ever encrypted with that private key can be considered secure. As long as the secret key is stored somewhere, all data encrypted with that secret key is also at risk.
Encrypted data is at risk in this scenario, but so is digitally signed data. There is no way to distinguish between data that was legitimately signed from data that was signed without authorization by an attacker who has gained control over a private key.
Revoking the certificate could mean that a fair amount of legitimately signed data must be discarded if the attacker had access to the private key any time before the attack was detected.
That said, few organizations are entirely willing to accept the risk of losing access to important data. But there are alternatives that do not necessarily put your entire public key infrastructure at risk.
Depending on the software you use to encrypt data, you may be able to require all users to encrypt data not just to a recipient but also to a security manager.
Or, users could encrypt to a special public key that can be unlocked only by a select group of previously authorized users'for example, three of five deputy directors plus the director.
By keeping the functions separate, it makes an attacker's job just that much more difficult.
'Pete Loshin
NEXT STORY: Lock, stock and barrel