nCipher Security Blog

Can Certificate Authorities Be Trusted?

Following the catastrophic security failures at both DigiNotar and Comodo that led to a single attacker obtaining numerous falsified SSL certificates and the subsequent large scale misdirection of traffic in Iran, 2011 looks set to be a defining year that may change the landscape in the PKI world for years to come.

While vendors, consultants and regulators have advocated the benefits of PKI and define security practices and standards to ensure the integrity of the infrastructure upon which all e-commerce depends, attacks have typically been theoretical. Now there’s undeniable evidence that the threat is real. And while the recent attacks have (eventually) become public knowledge I cannot help but wonder how many other breaches remain undiscovered or unannounced.

These attacks have thrown into sharp focus several weaknesses that stem from the widespread assumption that a Certificate Authority’s systems are always trustworthy and that a certificate is only revoked if the holder loses their private key (e.g. if a web server is hacked), or if the holder’s entitlement is withdrawn (e.g. when an ID card is revoked at the end of an employment). In other words it has previously been assumed that a certificate is always genuine and valid on the day it is issued.

It can be tempting to assume that certificate revocation solutions such as the Online Certificate Status Protocol (OCSP) are effective at controlling the impact of a CA breach. However as currently implemented, OCSP isn’t a reliable solution to the threat of falsified certificates. Firstly not all applications support OCSP (such as mobile devices and older XP based systems), and where OCSP is supported, the default configuration is often to trust a certificate even if the revocation service cannot be contacted (this is the default with IE9 and FireFox 6). As a result, any attacker who can hijack IP routing or DNS can simply block access to the corresponding OCSP responder. Secondly, browsers only check for certificate revocation using the OCSP responder that’s listed in the certificate they’re validating. If that certificate is falsified this revocation information cannot be trusted anyway unless the entire CA is revoked!

Relying upon timely and effective revocation using mechanisms like OCSP can never be the complete answer; especially since one of the primary benefits of many PKI based solutions is the ability to validate identity in an offline environment. The industry needs to find ways to increase the integrity of the certificate issuance process itself. The response to the recent attacks is likely to be a series of more rigorous standards that mandate system-wide protection for certificate issuance, much as PCI-DSS has become a standard defining system-wide protection for credit card information. Standards may be defined by browser vendors who can choose which root certificates to include in their products. As recent events have shown these application vendors have a unique role in determining which CAs are trusted and ultimate responsibility for revoking untrustworthy CAs. Mozilla have already written to the CAs whose certificates they incorporate, requesting they undertake an immediate audit. Where PKI is already regulated (for example as used within Europe for e-invoice signatures), these regulators will be looking to strengthen the standards they enforce. Alternatively, the CA industry may choose to tighten self regulation in certain sectors, perhaps in an attempt to avoid external mandates.

CAs do now offer premium certificates in the form of Extended Validation (EV) certificates that promise increased assurance by defining an elevated standard for the procedural elements of identity verification. Unfortunately EV certificates place few additional responsibilities on the issuing CA to increase the protection of their internal IT systems and therefore don’t serve to protect against targeted hacking attempts.

Once identity checks are complete a CA uses a series of highly sensitive cryptographic keys to issue a certificate request. Today it’s routine for these valuable keys to be protected in a security appliance called a Hardware Security Module (HSM). By moving these keys away from standard servers and into an HSM they are protected from risks such as viruses and hackers. However other critical parts of the certificate issuance process still typically run on general purpose servers where, as in the case of DigiNotar, they can be vulnerable to attack.

The risk of a successful attack could be significantly reduced by moving more of the certificate issuance process into the protective environment of an HSM. Firstly this would ensure that all certificates are issued with accurate attributes including revocation details and date information. Secondly this will enable accurate and hardware enforced reconciliation between authorised certificate requests and certificates that are issued. For anything other than the least valuable certificates, where the identity checks are themselves automated, this issuing process should require manual two factor approval; e.g. requiring the physical presentation of a smartcard to confirm identity checks have been completed and to authorize the issuance of a certificate. The issuing HSM would then have the opportunity to validate this authorization and other business rules (for example checking the certificate is issued during normal working hours), before producing the requested certificate. This approach would dramatically increase the barriers a hacker must overcome to issue fake certificates.

Moving sensitive business processes into HSMs will take time, as existing certificate issuing applications will need modification. Other interim approaches exist; for example HSMs can provide a simple key use counter that provides an authoritative count of certificates that have been issued. Such counting features should be enabled and in the event of a mismatch, certificate issuance should cease immediately.

Until these issues are addressed and confidence is restored there’s a question mark hanging over the widespread trust of cloud based services. The assumption that a padlock symbol in a browser proves your connection to a service can be trusted is starting to be questioned. However while we should all be cautious, SSL and “https” will undoubtedly remain far safer than plain old “http”.