What happens when encryption and security certificates go awry?

What happens when a compromised certificate is used to conduct malicious activities that result in data loss or a breach? Two researchers at Carnegie Mellon University asked that exact question and found that

Carnegie's CERT system team software engineer Aaron Reffett and Thomas Scanlon released research this month

They say that in situations where a private key is stolen or lost from a public key infrastructure (PKI) environment, there is potential for compromised end-entity certificates to be abused.

This can result in breaches because anyone who holds a private key can essentially impersonate the intended user.

Reffett and Scanlon argue that losing a private key is essentially the same as losing a password, but unlike passwords, private keys are more difficult to replace and harder to recover from.

On top of that, compromised client-authentication certificates are essentially similar to usernames and passwords because attackers can spoof a trusted service. Attackers can then grab confidential information sent by unwitting victims to that breached service, researchers say.

Private keys and certificates are rarely audited. Certificates may have validity for between one and three years, so attackers may be able to compromise both the key and certificate for a very long time.

Reffett and Scanlon also explain that keys can be lost or stolen in different ways, including system crashes, hacks, and even in cases where people accidentally send their private key instead of the public one in a message.

"Another possibility is that a key might be exposed for some period of time. This case is the digital equivalent of leaving a written secret on a desk in a public area where people walk by and could potentially copy it. Organisations using PKI need to institute and document measures that assure proper custody of private keys," they explain.

" A principle that everyone using PKI should adopt is: if you think it's possible that you have lost control of your key, you have effectively lost control of your key. Regardless of whether you know you've lost it, think you've lost it, or don't know whether you've lost it, the actions you should take to mitigate the problem are identical.

The researchers suggest that organisations need to have a first response plan – typically this would be to revoke the certificate and inform users that the certificate is not valid. This can be done through the online certificate status protocol (OCSP).

The certificate issuer must also do their part to ensure it shares a list of revoked certificates to users.

Researchers explain that most modern web browsers rely on lists of bad certificates at update time.

"When clients update, they receive a new list of blacklisted certificates. It is assumed that the scope of each breach is known and that a discrete set of compromised certificates can be collected. It is also assumed that the certificates will be properly revoked via appropriate channels by the issuing certification authority (CA).

"Browser makers prefer this scenario to one where each connection is checked, with the consequent performance penalty.

But researchers say there are problems with this setup.

"It does not protect against the unknown compromised certificate since there is lag time between an event's occurrence and discovery of the event, along with the time it takes to make the changes and push out updates. This lag time represents a window of opportunity to exploit the vulnerability.

"This scenario also relies on all users keeping updated versions of browsers, which we know not everyone does. Moreover, for a certificate to appear on a blacklist, there must have been some exploit or compromise that has taken place to put it there. As a result, someone paid a price for every certificate that is on the blacklist.

The researchers explain that there are a number of ways organisations can mitigate problems:

• Principal mapping
• Client certificates
• Add compromised certificates to a system certificate blacklist
• Updating non-system NSS database stores
• Application-specific mitigations for TLS/SSL handling
• Network mitigation such as introducing an SSL-terminating proxy
• Intrusion prevention systems that conduct deep packet inspections on SSL session handshakes
• Post-cleanup monitoring
• Intrusion detection systems
• Application audit logging.