Overview#

There are a lot of things that can go wrong with the Public Key Infrastructure and the related Certificates. Without a Public Key Infrastructure that has integrity and maintains confidentiality for the Private Key the Public Key Infrastructure will fail to be trustworthy.

The certification model for X.509 Certificates has often been criticized, not really on technical grounds, but rather for politico-economic reasons. The certification model for X.509 concentrates validation power into the hands of a few players, who are not necessarily well-intentioned, or at least not always competent. Now and again, proposals for other systems are published (e.g. Convergence or DNSSEC or Decentralized Public Key Infrastructure) but none has gained wide acceptance (yet).

For certificate-based user-agent authentication, it is entirely up to the server to decide what to do with a user-agent certificate (and also what to do with a user-agent who declined to send a certificate).

Security Risk of Keys Being Unprotected#

If the Private Keys for any of the Certificates within the Certificate Chain are not properly safeguarded, digital forgery can become a major concern as the Private Keys is considered to be a Bearer Tokens.

The Usability of Public Key Infrastructure#

Even if third-party certificate Authority and the Registration Authority could be trusted, the current PKI system has major usability problems. A group from Brigham Young University investigated the usability of Mailvelope, a browser extension that supports GPG-encrypted communication through third-party websites like Gmail. Their research demonstrated a 90% failure rate in secure communication attempts among the participants. Public Key management, the study found, was the main reason that users were unable to use the application correctly. [2]

Even TextSecure/Signal — a secure messaging system endorsed by Edward Snowden for its security and ease of use — has usability problems due to its inability to smoothly handle Public Key changes. If a user deletes and reinstalls the app, their friends are warned that their public key "fingerprint" has changed. This scenario is indistinguishable from a Man-In-The-Middle attack, and few users are likely to understand or bother verifying that they received the correct Public Key.[2]

user-agent warnings[1]#

The major lesson that we’ve learned from the history of security (un-)usability is that technical solutions like PKI and access control don’t align too well with user conceptual models so that, as a pair of US government program managers with extensive PKI experience put it, "users find it easier to just turn PKI off rather than to try to figure out what actions they need to take to use it". As a result, calling in the usability people after the framework of your application or device’s security measures have been set in concrete by purely technology-driven considerations is doomed to failure, since the user interface will be forced to conform to the straightjacket constraints imposed by the security technology rather than being able to exploit the full benefits of years of usability research and experience. Security and security usability need to be baked in, not brushed on. Blaming security problems on the user when they’re actually caused by the security system design is equally ineffective, but unfortunately even now, after ten years of work on security usability, still very popular.

User do not understand the warnings presented and how to react to such warnings. Phishing is also an issue for these type of user-agent warnings.

user-agent warnings are part of a Human Limitation for Public Key Infrastructure Weaknesses

No user-agent warning#

A user-agent will give no warning to the user if a web site suddenly presents a different certificate, even if that certificate has a lower number of key bits, even if it has a different provider, and even if the previous certificate had an expiry date far into the future.

A change from an Extended Validation Certificate to a non-Extended Validation Certificate will ONLY be apparent as the green bar will no longer be displayed. Where certificate providers, Registration Authority or Certificate Authority, are under the jurisdiction of governments, those governments may have the freedom to order the provider to generate any certificate, such as for the purposes of Law Enforcement Agency. Subsidiary wholesale certificate providers also have the freedom to generate any certificate.

Registration Authority#

A Certificate is a credential and an Identity Document issued by a Certificate Authority which has (Hopefully) gone through Credential Enrollment by a Registration Authority.

Typical user-agents come with a built-in list of Certificate Authority, many of which are controlled by organizations that may be unfamiliar to the user. The end-User trust that the Registration Authority to properly perform their job of Identity Proofing of the entity during the Credential Enrollment to obtain the Certificate. Each of these Registration Authority is free to issue any certificate for any website and have the guarantee that user-agents that include its root certificates will accept it as Authentic.

This is further complicated by the risk of coercion or Compromised Certificate of a Certificate Authority. Because of these dangers, users cannot be certain that their communications are not being compromised by a fraudulent certificate allowing a Man-In-The-Middle attack.

In addition end users must rely on the developer of the user-agent software to manage its built-in list of certificates and on the certificate providers to behave correctly and to inform the user-agent developer of problematic certificates. While uncommon, there have been incidents in which fraudulent certificates have been issued:

Extension of user-agents Trusted Certificates#

The list of built-in Trust Anchors is also not limited to those provided by the browser developer. Users and to a degree applications are free to extend the list of Trust Anchors for special purposes such as for company intranets. This means that if someone gains access to a machine and can install a new Trust Anchor in the user-agent, that user-agent will recognize websites that use the inserted certificate as legitimate.

For provable security, this reliance on something external to the system has the consequence that any public Key certification scheme has to rely on some special setup assumption, such as the existence and trustworthiness the certificate Authority and the Registration Authority.

Certificate Validation#

Many user-agents may fail to properly perform Certificate Validation. There are some constrained environments where they may not be able to perform proper Certificate Validation. The user-agent may not have sufficient CPU or memory for these purposes.

Possible Assistance for Public Key Infrastructure Weaknesses#

More Information#

There might be more information for this subject on one of the following:

This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop