Commentary by Mark Wahl
Organizing principles for identity systems:
The trust is out there: PKI root certificates and risks to importing a managed card (2006/9/20)
In Monday's post, introducing the mythology of PKI, I mentioned the links for removing vendor-provided certificates from a platform trusted root CA certificate set.
A primary policy decision made by today's web browsers is whether to allow a user to see a page accessed via HTTPS (HTTP over SSL/TLS).
If the user visits a web site, then the browser will obtain the server's certificate chain during the SSL establishment. The browser will attempt to validate the certificates in this chain based on one of its preconfigured root CA certificates. Once a path can be validated, the browser will display a lock icon or color the title bar.
Further interactions with that site, however, are generally not mediated by the browser. The browser does not prevent the user from revealing personal information to a web site: a phishing attacker simulating examplebank.com that sets up example-bank.org, can obtain an SSL certificate for that site, display examplebank.com text and logos on their site, and gather spoofed users' input over a SSL-protected session.
If the user visits a web site but the web browser cannot build a path to one of the platform root CA certificates, then the user's interactions with that site are interrupted. Not having a path to a root certificate in the certificate path returned by a web server while SSL is being established is a warning situation to the web browser.
For example, IE7 beta will report that "The security certificate presented by this website was not issued by a trusted certificate authority."
If the user chooses to continue to the web site, unless they go through a separate procedure to import the web site's certificate into one of their Windows platform certificate sets, the above warning page will reoccur every time the user visits the site.
Firefox reports "Unable to verify the identity as a trusted site".
Note however that a user of Firefox or other Mozilla NSS-based browser who Accept this certificate permanently will only incorporate into the user's NSS profile certificate set for use by other NSS-based applications on that system.
For PKI-based client applications other than web browsers, X.509 path validation failure is generally more serious, as there may not be a way for users to manage their certificates through these applications.
For example, the Microsoft CardSpace technology preview has a ceremony of a user importing a managed card from a .CRD file into their collection of infocards issued to them. This managed card is encoded in XML and signed using XML signature. The Technical Reference states that
"When an InfoCard is delivered out-of-band, it should be delivered inside a digitally signed envelope (i.e. enveloping signature) signed by the identity provider. The digitally signed envelope is the moral equivalent of a signed message, which provides a signed container, in which the application payload gets delivered to a recipient. In this case, the InfoCard itself is included as the element content of the ds:Object element inside the enveloping signature. The signature on the digitally signed envelope makes no implicit statement about the content of the InfoCard itself except providing data origin authentication.
The specific details of the XML digital signature [XMLDSIG] profile that should be used to sign the envelope carrying the InfoCard is as follows:
- ...The ds:KeyInfo element must be present in the signature carrying the signing key information in the form of an X509v3 certificate (or a X509v3 certificate chain) specified as one or more ds:X509Certificate elements within a ds:X509Data element."
When the user imports a managed card, the ceremony involves the CardSpace implementation (which has locked the screen) validating the certificate chain bundled with the managed card, by building a path back to one of the 100+ certificates included in the Windows platform root certificate set. If this validation fails as no path could be built, then an error dialog box appears, the import ceremony ends, and the user is not permitted to import their card.
In Monday's post I mentioned that within an organization, requiring the employees and other day-to-day participants of the organization's activities to add that organization's certificates to their root certificate sets on each of their platforms is generally accepted practice.
However, asking users to add to their platforms certificate stores the certificates of organizations that are not their employer/school/government, is less common. In the case of an Identity Metasystem, there will be organizations that are potential Identity Providers which may wish to issue managed cards to users who are not employees of that organization, and have only intermittent interaction with the user.
Examples of organizations which hold some information about me, which could conceivably wish to issue a managed card to me, include not only big-budget organizations such as:
- Government entities
- Financial institutions
- Educational institutions
- Telecommunications providers
- e-commerce: amazon, eBay, etc.
- Social Networking: myspace, tribe, linkedin, etc.
As well as small-budget operations,
- Blog hosting
- Wikis
- Mailing list hosts
- Community service discussion boards
While PKI has been very successful in establishing its myths, in scenarios involving the transfer of credit card numbers and similar from a customer to an e-commerce service, ensuring the origin of a managed card is from a particular identity provider is a different problem space with distinct semantics.
Some of the risks involved with verification of managed card signatures include:
- risk to integrity if a card is modified in transit
Inadvertant modification would be detected by signature verification, however, there are simpler means (such as a hash) to achieve this. And while an active attacker merely tweaking a field within the card would invalidate the signature, an active attacker can both modify the field and replace the signature with their own, based on a certificate from a user's trusted CA.
Thus, verifying the integrity also requires one of:
- the user only having certificates in their root set which have been issued by CAs which the user trusts to not issue certificates to active attacker,
- policies being attached to certificates to limit the scope of activities which a certificate can be used for,
- verifying the source through the channel (although HTTPS over SSL has this same limitation, and managed cards obtained from a file lacks the connection back to the association over which it was obtained), or
- displaying the path and names to the user and relying on the user to identify the elements of the trust path.
- risk to integrity if a deceptive card is incorporated into the user's card store - the user might inadvertantly select the wrong card to provide to a relying party
This requires that a card be verified to come from a suitable, nonmalicious source, for which the mere presence of a connection to a root CA does not provide.
Performing one of the above-listed additional verification steps would also be necessary to address this risk, as would one of:
- a probability-based detection system, such as is done to detect spam or phishing sites
- a reputation-based detection system
- risk to confidentiality if the use of a deceptive card causes the user to reveal information to a malicious system.
As with the previous two risks, merely verifying a signature does not protect against this risk in a network where attackers can obtain their own certificates, and additional checks are required to actually protect against the risk.
- risk to availability if a path could not be validated.
This risk is created by the PKI verification, if the user wishes to use the managed card but the PKI client cannot build the path (e.g. there is no common root, a certificate has expired or been revoked, or a online certificate status check service is not available). This may occur in many situations, such as if the identity provider does not make use of services of one of the CAs in the user's platform's root certificate set, that set changes, or some intermediate CA is changed.
Thus one danger of using PKI in the way implemented in the preview (prerelease) version of the Microsoft CardSpace component of the Identity Metasystem is that
- while it addresses one threat (an attacker who can modify data in transit),
- it fails to address another, very similar threat (an attacker who is able to obtain a certificate from a Microsoft-trusted root CA), and
- introduces availability risks of its own (where a user cannot obtain a managed card from the user-trusted identity provider if that provider does not have a certificate path to a Microsoft-trusted root CA).
A further danger is that the level of trust provided by path validation will be conflated in a user's mind with trust of identity providers, and in the future, with the trust of identities issued by that identity provider.
Today there is confusion between a user's trust of an organization operating a web site and the presence of a lock icon or taskbar color on the user's browser when viewing that web site. And as mentioned in an earlier post on leveraging PKI for anti-phishing, a phishing attacker can create a secure web site which resembles a well-known legitimate web site, and under possible criteria for certificate issuing checks, could still get a "green address bar" indicating that it is a legitimate site.
Also important is the question of who can or should be an identity provider, and for whom the provider can issue identities. In the current model, any organization can become a identity provider for the Internet, if it obtains a certificate from an issuer trusted by each of the platforms used by its potential customers and potential relying parties. While this covers e-commerce sites which have had to do this already to enable HTTPS for encouraging customers to provide credit card numbers online, it does not address organizations which have historically not used SSL, perhaps because their risk model indicates a very low level of threat or potential loss from compromise. (The OpenID participants, for one, have been looking into this problem space in their protocol development).
If organizations amenable to phishing or other fraudulent attacks are permitted to become identity providers, then policies are needed for relying parties to know whether and how to interact with these providers, and if users see these hostile identity providers and identities they manage, they need to have available tools for vetting this information, more than just the "trust" provided by a certificate path. In particular, we should ensure that external organizations in an identity metasystem should not be permitted to make trust assumptions and have those assumptions be forced upon the user through the user's platform, if those trust assumptions are not amendable by the user. (A social networking site does not decide who a user's friends are). Also, users should be able to make trust assumptions, even if a platform has a different set of assumptions. In these early days of a metasystem, the management of the processes for integrating identity providers and relying parties with a user requires ceremonies which have not yet been defined.
We are still a long way from being able to establish the "secure" online equivalences of the trust relationships between real-world individuals. For example, consider the set of identity providers that might are suggested by a definition of Trusted Adult, taken from the NetSmartz Internet Workshop of the National Center for Missing and Exploited Children, as used in a brochure on Cyber Safety , targeting a kid and teen computer audience, put out by the office of Greg Abbott, Texas Attorney General.
Trusted Adult. Someone who will help protect you and make you safer. Trusted adults can be people like
- family members,
- caregivers,
- family friends,
- teachers,
- counselors,
- coaches,
- clergy members,
- youth leaders,
- and law-enforcement officers.