Top problems with PKI, signatures and SSL

To avoid confusion: This article pertains primarily to open PKIs like in web browsers. PKI federations with strict control on policy and profile and implementations manage many of the issues. See also Patrick's comment.

Public key cryptography is widely believed to assure high levels of security and confidentiality in an otherwise untrusted Internet. SSL, digital signatures and public key infrastructures play a significant role in e-commerce and information system security.  It seems likely, moreover, that their role will continue to grow in the future. However, leading security experts warned that the good news is exaggerated because of flaws in the underlying model, specification, implementation and the human factor. The consequence is that the application of cryptography needs to be part of a wider security management system, and expectations need to be moderated.

The following list collects a number of issues that are quite well known in the security community.

A short list of X.509 security issues can be found in Wikipedia.

 

          “Cryptography is typically bypassed, not penetrated.”
 (Adi Shamir)


Ambition and reality of X.509

ITU-T standardized certificates in X.509 during the 1980ies. It is a quite ambitious standard, however it turned out to be too complex to be fully implemented and utilized. Since Peter Gutmann from Auckland University published the X.509 Style Guide in 2000, little has improved:

  • The X.509 specification is scattered across many standards, drafts and amendments from multiple standard bodies, leading to confusion and numerous profiles that lack interoperability.
  • X.509 utilizes features from other standards, like DNs from X.500 which are in itself complex and have little value in the Internet world today. That is undesirable as it provides unanticipated attack vectors.
  • Parts of the standard, even some that are related to key elements, are underspecified. That leads to ambiguity, unknown semantics and interoperability issues, like the country code, date/time formats in validity or path validation.

Implementation issues with X.509

Due to the complexity and vagueness of the specification there is no assurance that implementations are consistent and interoperable across different libraries and operating systems. As a consequence constraints must be put on the use of PKI. Basically there remain 2 options:

  1. Use only the minimal set of features in certificates and PKI; That is to use the binding of an identifier and name to a key pair and understand whether the certificate may sign other certificates or not. No additional attributes should be relied on, no complex path validations allowed.
  2. Use a specific profile of X.509 and validate it in a narrow set of implementations.

Revocation problems

PKI revocation services deploy the blacklist pattern that has been abandoned by the credit card industry long ago. There are several problems associated with CLRs and OCSP:

  • Revocation services are suspect to DoS-attacks. In general a poor operational service level of the OCSP responder will leading to failures first and frequently to temporary or permanent disabling of revocations services at the relying party later.
  • Implementation issues cause revocation services being disabled during deployment (like it is the case with many web browsers)
  • Distribution in a timely manner, performance issues and semantic inconsistencies add to the problem.
  • OCSP-implementations can be fooled by a MITM-attack to skip revocation checks. [Defeating OCSP with the Number 3].

PKI interoperability and federation

There were some advances in the area of PKI federation, most notably the bridge model around the US federal bridge that is being extended to Europe in some high-security areas like defense, national security, aerospace, airlines and pharmaceutical industries. Europe chose a somewhat different approach with the IDABC Trust List.

The EU Trust list is in its early stage and not yet feasible in cross-border projects. While the US-led bridge model is operational with > 100 millions of credentials it is not practical in Europe either, except in the sectors mentioned above.

The root trust issue

There is no easy, fast and effective method to revoke a root certificate

Revoking self-issued certificates in a large scale is difficult, on technical, organizational and business levels. Technically, there is no common protocol. On the organizational level requires contacting a multitude of organizations serving as trust anchors. This involves browser and OS vendors, many other tools vendors, like the Java runtime, and all organizations that manage their root trust store in an independent manner. This path is broken by definition.

CAs might be tempted to understate the problem

On the business level the problem is that anything less that a full compromise of the root key will tempt the CA to downplay the incident and revoke only certain certificates. This occurred with the DigiNotar-Hack, because the revocation of the root-CA would have interrupted the operation of many services.

CA liability questions

As Bruce Schneier pointed out in “Secrets and Lies” (2001) CAs usually limit their liability to the protection of their private key. As the CA plays the role of a trusted third party users of certificates are put in disadvantage. CAs are like a notary who would only be liable to keep his stamp secure.

Digital signatures are not manual signatures

Digital Signatures (dSig) are being hyped as the next big thing in e-commerce and e-government for well over 15 years and huge resources have been spent without significant uptake outside some small confined areas.

Jane Winn from Washington University wrote in 2001 her still valid critique that compares the substitution of wet signatures by dSig to “trying to fit a square peg into a round hole”. [The Emperor’s New Clothes:  The Shocking Truth About Digital Signatures and Internet Commerce]. In a nutshell, the term signature for dSig is simply misleading, because “traditional signatures play a surprisingly nuanced and complex role in traditional contracting practices that prove very difficult to map onto online security technology functions”.  Hence the equation of dSig with wet signatures in the EU electronic signature directive is a poor fit for the different semantics of wet signatures in respect to legal binding, enforceability and evidence.

In addition the duty to protect the private key is quite complex and unmanageable for the non-expert user, but in the context of dSig the onus of proof is reversed and moved to the signatory.

SSL in Web Browsers – pretty broken

SSL in the web browser is plagued by a variety of security issues, most notably the requirement that the end user has educated herself about the trustworthiness of certificates and the visual display of trust in web browsers.

But there are issues besides the end user, like

  • CAs are included in browsers by OS- and browser vendors without a common consistent policy. To be included in the trust store the vendor has to pay a fee. Only Microsoft requires a formal audit. As a result there is a sufficient number of weak and very weak CAs that are included in default certificate stores. In addition there is suspicion in the security community that governments use compelled certificates to tap Internet communication. As CAs from countries like China, France, Germany,  Turkey and Switzerland and the U.S. are trusted equal, the accumulated untrustworthiness applies to the whole system.
  • Clients certificates and their attributes have zero security value, because there are CAs that do not validate the attributes including attributes with arbitrary OIDs (P. Gutmann).
  • Some certificate stores contain funny root certificates that should be excluded on any serious security review.
  • SSL in the context of web browsers used to be target of several successful attacks, either directly on SSL (e.g. SSL renegotiation bug), the combination of https and http (SSL Strip), URL-forgery, and X.509-based attacks on ASN.1 and DN-parsing.

OWASP reports that PKI Authentication in web applications is not hack proof:

  • Secure in theory
    • Very strong encryption & authentication algorithms
    • Verified robust implementation (Common Criteria)
  • Fails in practice:
    Integration of the solution with the surrounding environment may allow compromise
    • End Point Integration (PC/User)
    • Web Application Integration
    • Allows performing real time attacks

 

SSL and PKI infrastructures are essential components in client device security, because they are used to bootstrap into higher-level security services such as software updates and digital signature services. Their vulnerability puts other security services at risk.

More references

The basic flaws of PKI have been analyzed 10 years ago, but most key challenges remain unanswered.

 

B. Schneier, Top 10 risks of PKI

P. Gutmann, Everything you Never Wanted to Know about PKI but were Forced to Find Out

P. Gutmann, RSA Catalyst 2011 conference proceedings

M. Marlinspike: New tricks to defeat SSL

D. Kaminsky: New Collision Attacks Against the Global X.509 Infrastructure