The problem is self-signed certificates.

A CA is not a great solution:

Using a Certification Authority (CA) could solve the attack but at the same time introduces a new set of attack vectors:

1. The CA becomes a single point of failure. It becomes the juicy/high-value target for the attacker. Single point of failures are not good. Attractive targets are not good.

   Any person with access to the CA key can undetectably fake passports. Direct attacks, virus, misplacing the key by accident (the UK government is good at this!) or bribery are just a few ways of getting the CA key.

2. The single CA would need to be trusted by all governments. This is not practical as this means that passports would no longer be a national matter.

3. Multiple CA's would not work either. Any country could use its own CA to create a valid passport of any other country. Read this sentence again: Country A can create a passport data set of Country B and sign it with Country A's CA key. The terminal will validate and display the information as data from Country B.This option also multiplies the number of 'juicy' targets. It makes it also more likely for a CA key to leak.

   Revocation lists for certificates only work when a leak/loss is detected. In most cases it will not be detected.

So what's the solution? We know that humans are good at Border Control. In the end they protected us well for the last 120 years. We also know that humans are good at pattern matching and image recognition. Humans also do an excellent job 'assessing' the person and not just the passport. Take the human part away and passport security falls apart.

In particular, SSL certificates (as used to identify https websites) might contain one of these weak keys — and so it would be possible for an attacker to successfully impersonate a secure website. Of course the attacker would need to persuade you to mistakenly visit their site — but it just so happens that one of the more devastating attacks on DNS has recently been discovered; so that’s not as unlikely as it must have seemed back in May.

Anyway, my old friend Ben Laurie (who is with Google these days) and I have been trawling the Internet to determine how many certificates there are containing these weak keys — and there’s a lot: around 1.5% of the certs we’ve examined.

But more of that another day! because earlier this week, Ben spotted that one of the weak certs was for Sun’s “OpenID” website, and that two more OpenID sites were weak as well (by weak we mean that a database lookup could reveal the private key!)

OpenID, for those who are unfamiliar with it, is a scheme for allowing you to prove your identity to site A (viz: provide your user name and password) and then use that identity on site B. There’s a queue of people offering the first bit, but rather less offering the second : because it means you rely on someone else’s due diligence in knowing who their users are — where “who” is a hard sort of thing to get your head around in an online environment.

The problem that Ben and I have identified (advisory here), is that an attacker can poison a DNS cache so it serves up the wrong IP address for openid.sun.com. Then, even if the victim is really cautious and uses https and checks the cert, their credentials can be phished. Thereafter, anyone who trusts Sun as an identity provider could be very disappointed. There’s other attacks as well, but you’ve probably got the general idea by now.

In principle Sun should make a replacement certificate and that should be it (and so they have — read Robin Wilton’s comments here). Except that they need to put the old certificate onto a Certificate Revocation List (CRL) because otherwise it will still be trusted from now until it expires (a fair while off). Sadly, many web browsers, and most of the OpenID codebases haven’t bothered with CRLs (or they don’t enable their checking by default so it’s as if it wasn’t there for most users).

One has to conclude that Sun (and the other two providers) should not be trusted by anyone for quite a while to come. But does that matter ? Since OpenID didn’t promise all that much anyway, does a serious flaw (which does require a certain amount of work to construct an attack) make any difference? At present this looks like the modern equivalent of a small earthquake in Chile.

All provisioning solutions provide some facilities for:

• Reduction of paper-based processes in favor of electronic requests and work flows
• Reduction of manual updates in favor of automated entitlement updates

All provisioning solution providers strive to have a compelling story for these items. Additionally, these were the focus of the first generation of solutions which emerged in the ’90s.

For the Identity Management programs with which I have been involved, automation and risk management have been equally important. This is somewhat reflected in the definition I use for provisioning:

Provisioning is the processes and systems which:

• Manage the entire Lifecycle of an Entitlement from request, through approval processes, onto issuance, and eventual revocation

• Provide transparent views of the status and history of each step in the Entitlement Lifecycle through the creation of durable and detailed records, which include all the information required to provide non-repudiation and event reconstruction for each step in an Entitlement Lifecycle

Note: Fulfilling these objectives always involves a mix of manual and automated activities, technical and procedural controls.

Based on my experiences, having prepared several product selection scorecards in this space, there are two major approaches (philosophies), that provisioning products take in this space:

The provisioning system “sees itself as”…

• Coordinating identity and entitlement activities among systems with the objective of providing automation

- - - OR - - -

• Maintaining a single centralized record of reference for identity and entitlement, as well as providing tools to automate approval, issuance, revocation, and reconciliation

The “Centralized Record of Reference” concept is the watershed between these two. The systems that are designed purely for automation tend to focus on “Coordination” of external events. These systems often do not contain an internal store of entitlements. The systems that maintain a “Centralized Record of Reference” approach have the ability, through reconciliation, to validate that the entitlements in the “wild” (e.g., in AD, LDAP, within local applications, etc.) match the “official” state (which they maintain). This enables these systems to detect changes and take action (e.g., drop the privilege, report the discrepancy, trigger a follow-up work flow, etc.)

Which system is right for you?

This really depends on what percentage of your systems require tight oversight. If you are in an industry with low-IT regulation, and the data of your core business is low risk, then it may make more sense to invest in routine manual audits of a few systems, rather than monitoring your entire IT world. On the other hand, if you are in an industry that is highly regulated, with high-risk data, then the automated oversight and reconciliation capabilities are likely a good fit for you.

FYI, last week I co-taught a one-day class on Identity and Access Management Architecture at RSA 2008. For the last 3rd of the class, Dan Houser and I had a list of advanced topics for the class to vote on. I prepared a module on Provisioning, but alas it was number 4 out of 7 options, and we only had time to cover 3… As a result, a Provisioning slidecast is “coming soon” to the Art of Information Security podcast.

Cheers, Erik

Art of Information Security would love your feedback !

Risk ROI for –Some– Provisioning Solutions…

The VeriSign revocation list may impact a variety of operations. For example, verification checks that request online CRL validation will fail, which is more common for user mode operations. This can also extend to functions such as online time stamping combined with signing of new code. The frequency of these checks is application specific, and also depends on factors such as the requested CRL verification policy (online network, vs. offline without fresh cached CRLs, etc).

Perhaps I was the one who alerted Microsoft, but it responded tonight pretty strongly. As described by Scott Field, Windows Security Architect, in the Windows Vista Security blog, Microsoft has taken the following actions:

• It (actually VeriSign) has revoked the code-signing certificate used in Atsiv. Such certificates from VeriSign cost at least $431/year, and that's if you commit to several years.
• Microsoft is thinking of adding it to their own revocation list. This confuses me; why would it be good enough for VeriSign's revocation list, but Microsoft is only looking into putting it in its own? I've asked.
• Best of all: It has added signatures to Windows Defender to detect Atsiv, at least the current version of it. Source for Atsiv is supposedly available (although I didn't see a link for it on the Linchpin Labs site), so it should be possible to write a new version that Defender won't detect if you're looking forward to losing your own code-signing certificate.