InfoCard Architecture and Security

The InfoCard system installed with WinFx consists logically of three things:

• An InfoCard service responsible for creating self-issued security tokens and retrieving security tokens from security token services

• An InfoCard data store

• A user interface component that is used to manage and select InfoCards

Figure 14.5 shows the logical architecture of the InfoCard system.

Figure 14.5. InfoCard architecture.

The central part of the system is the infocard.exe service, which handles all token and management requests and runs as Local System. It creates the UI Agent process, icardagt.exe, to interact with the user, and this runs as the user on a private desktop, communicating with infocard.exe via RPC.

Running the UI in a separate desktop helps ensure that personal identity information is displayed in a secure way, protecting against phishing and shatter attacks and disclosure of personal information.

There is one component, infocardapi.dll, that handles all entry points into the InfoCard system and is loaded into the client process (the browser, a WCF app, or the Control Panel applet). It has no public types but is dynamically loaded by System.IdentityModel.Selectors.dll in WCF clients and by icardie.dll in IE7.

The only other process is created when the user needs to use the Open File dialog, such as when importing or exporting a card or choosing an image. This process runs in the context of the user on the normal user desktop.

The icardie.dll component is the bridge between IE7 and the InfoCard system and it ships with IE7 (from the IE7 Beta 2 Preview onward). The InfoCard system is exposed to web developers in two ways, a binary behavior and a COM object, but they have a shared implementation for accessing infocardapi.dll using the GetBrowserToken() API.

Both binary behaviors and ActiveX objects are compatible with other browsers (a mandatory requirement for any browser solution), have minimal impact on existing sites, and provide a seamless user experience should InfoCard not be present on the user's system, that is, if WinFx has not been installed.

ActiveX controls have the advantage of being well-known to web developers but can be disabled in high-security environments. Binary behaviors, though less familiar, are available even when the browser is configured to use high security settings and ActiveX controls are disabled.

WCF applications access InfoCard via System.IdentityModel.Selectors.dll. This .dll is installed in the global assembly cache (GAC), and the API used is GetToken(). However, as far as WCF developers are concerned, they simply need to add a reference to System.ServiceModel and select the IssuedToken client credential type to launch the InfoCard process.

Both the GetToken() and the GetBrowserToken() methods return signed and encrypted (using the identity of the recipient) security tokens ready to be dispatched to the server/service.

The identity selector module in infocard.exe is the component that does all the hard work. It retrieves IP and RP policies using WS-MetadataExchange, evaluating what identity information is required and determining which possible digital identities (that is, InfoCards) can be used. It then calls the UI process, icardagt.exe, to display those cards to the user (cards not meeting the RP's policy are greyed out).

If the user selects a card, the identity selector knows which identity provider (and STS) to contact from the card's metadata. It may have to ask the IP/STS for its security policy via WS-MEX, but in any case the identity selector does the WS-Trust dance with the IP/STS. It sends an RST asking for a security token containing the claims required by the relying party's policy. The IP/STS then returns an RSTR containing a signed security token for the RP, a proof-of-possession key, and, optionally, a display token to show the user what's in the security token proper. As the name implies, the proof key enables the user to prove to the relying party that he/she/it is the rightful bearer of the security token.

The identity provider STS can be an external service (for example, my bank or my company), in which case it is represented by a provider card supplied to me by the identity provider. Or it can be my personal STS that provides the security token, in which case it is represented by a personal card. In either case, the logical semantics are the sameand furthermore, extend to portable, device-based STSesbut in the case of personal cards it is the InfoCard system, infocard.exe, that creates a SAML 1.1 security token using data stored locally in the InfoCard store.

After the InfoCard system has received a security token from the IP, the user is prompted (via the UI agent) whether to send the token to the relying party to gain access to the site or service.

Relying parties are required to have an X.509 certificate (preferably a high-assurance certificate) to identify themselves but also so that security tokens sent to them can be encrypted using the certificate's public key. What this means is that a security token destined for a relying party is totally opaque to the InfoCard system. This is by design: Identity selectors need to be security token agnostic, and it follows that there shouldn't be a requirement for InfoCard to understand every token that passes by. However, the user needs to have a way to see the contents of the token in order to know what personally identifiable information is being sent to the RP.

The solution is to have an optional display token sent by the identity provider to the user along with the normal security token (which is destined for the relying party). It is the display token that is displayed to the user so that the user makes an informed decision on whether to proceed.

At the relying party, the recipient of the security token can be either a service endpoint or a relying party STS (aka a resource STS) which controls access to the relying party's site or service. The relying party cracks open the token and authenticates and authorizes the user based on the claims in the token (and the provider of those claims). In the browser case, the RSTR from the resource STS is a browser cookie. This means that access to a website after authenticating via InfoCard is exactly the same as an existing solution using username and password authentication.

WCF services can also use a resource STS. That way, once the user has authenticated using a security token from an IP, access to a service is controlled by the relying party and there is no longer a requirement for an IP security token. Although the client app can cache the IP's security token as a performance optimizationat least until the token is no longer freshthis gives the relying party control.

After you receive a provider InfoCard from an identity providerin a way that enables you to trust that the card is authenticyou can use the cryptographic information it contains to authenticate to the identity provider and communicate securely.

Personal InfoCards and their (limited) information are created by the user and stored locally, but they also contain an RSA key pair to enable security tokens to be signed by the personal IP. I will cover how this is generated in a moment.

The InfoCard system is an interactive system (not programmatic) that does not authorize release of personal information without explicit user approval. It is therefore the user who is responsible for protecting his personal information. The system aids the user in making intelligent decisions by providing an intuitive user interface and detailed information about the entity requesting a security token. Information is gathered from the recipient's X.509 certificate including logos (when present) and displayed to the user. This UI, combined with the use of high-assurance certificates, enables the user to make an informed decision to trust the recipient. Furthermore, all UI and display of this info is done using a private desktop accessible only by the LSA that hides the user's desktop. This helps to prevent phishing and screen-scraping attacks.

There is an encrypted and signed InfoCard store per user and it is ACL'd for Local System access only. Data in the store is encrypted using AES256, and the symmetric key used is doubly encrypted using DPAPI (256-bit AES keys), first using the user's DPAPI key and then again using the System DPAPI key. InfoCard allows only one level of role accessnormal user access. This way only the user can access the data and only via a System process (that is, Infocard.exe) that impersonates the user. Even when this data is loaded into memory, it remains encrypted until it is needed.

Individual InfoCards can also be protected by a password, which is useful for cases in which a Windows login is shared. However, this feature notwithstanding, if someone learns your Windows password, they will have access to your InfoCards. The mitigation here is to have a device like a portable STS or a smartcard to provide multifactor authentication. I should also point out that if you log in with admin privileges and run some malware, it doesn't matter how well designed a piece of software isbut there's nothing new here. The mitigation is to try to not log in as an administrator (the default in Vista) and to avoid running software of dubious origin.

InfoCards are XML documents issued by identity providers (including self-issued) and stored by the user on the storage device of their choice. An InfoCard does not contain any security sensitive data per se. It simply represents the security token issuance relationship of the user with an identity provider. The actual request and issuance of the corresponding security tokens will be authenticated and secure. You should note that the metadata exchanges to retrieve policy are in plain text.

Each card includes in its metadata an element called CardID that is a globally unique URI for that card. It is generated by, and only meaningful to, identity providers. For personal cards, the CardID is assigned by the system automatically at the time of card creation. For provider cards, the identity provider assigns a unique CardID for each card it issues, and this is included in requests for security tokens by the user.

As mentioned earlier, with personal cards the user is represented by a PrivatePersonalIdentifier (PPID) claim. This is created by hashing together the CardID and the relying party's organizational ID (the OLSCID derived from the X509 certificate of the site or service). This means a user can use the same card at multiple sites and there will be a different PPID for each one: Sites are unable to collude and track the user. It is this claim that is used when a user authenticates to an identity provider STS using a personal card.

Identity providers may or may not need to provide a user identifier to the relying party. The identity provider may just need to supply a security token with, say, an "over 21" age claim. However, if the identity provider does need to provide a user identifier, the PPID claim is a good choice. An identity provider can choose to use any mechanism of its choice to generate the PPID for the user as long as it can consistently reproduce it for that user.

Ultimately it is at the discretion of the relying party and identity provider in any given business context as to what is suitable as a persistent user identifier. For a government-run identity provider, a Social Security number may be a good identifier and an ISP could provide an email address. Both could also support PPID as a generic identifier (and a method to generate it) if they chose to.

Security tokens generated by an identity provider have to be signed with a trusted/well-known key that the recipient of the token can validate. For provider cards this is done by the identity provider using an X.509 certificate.

However, with personal cards we have two technical problems to overcome. We need an asymmetric key pair to sign security tokens but, more than that, we would like a key pair per site to again avoid correlation issues between sites. Also, once we have these keys, we need a way to roam them with the cards for a consistent user experience.

The solution is to use a master key per card. This is a 256-bit random number that is hashed with the relying party's organizational ID to create a seed for the Crypto API to generate per-site, per-card (and ANSI X9.31compliant) RSA key pairs. To be able to roam the store itself, InfoCard uses the Crypto API and PKCS#5 to generate a 256-bit AES key from the user's password.

Relying parties must have a public key pair for identity and encryption. The public key is used to encrypt security tokens destined for the relying party. Similarly, any tokens from an identity provider that are destined for the user (such as display tokens) must be encrypted to ensure that the claims are visible to the IP, the RP, and the user only. When username and password authentication is used with an IP/STS, the channel must be secured using SSL. For Kerberos a symmetric key is used, and for hardware- and software-based X.509 an asymmetric key pair is used. Authentication to an STS using a personal card can use either a symmetric or an asymmetric key pair for the security binding. Authentication to an STS using a provider card is not permitted.

One final security feature to note: InfoCard is able to obtain a security token from an identity provider without revealing the identity of the relying party to the identity provider. This is the default mode and we refer to the security token as an unscoped token. This is Law 2 at work!

Now let's write some code to see how InfoCard is accessed.