Fear the Cowboy

James Manger asks a couple of pertinent questions, considering my last post on PPIDs:

What is the “Master Key” that is used to create the key-pair and PPID? Could you
explain this process?

Whoa! You might as well ask what's in them sausages you just ate...

Seriously, the Master key is a posse' of bytes that we use to seed the entropy for creating the PPID and the private/public key-pairs.

The Master Key is generated by the CardSpace built-in STS when you create a personal card, and is stored with the rest of the data in the cardstore. It is the only peice of data in the card that the user doens't have control over.

I don't have the exact algorithm in my hands (I'm at the RSA Conference in San Francisco!), but I'll post it when I get back. If I recall correctly, it's kina along the same lines as GUID generation (takes a bunch of different data bits) and corrals them together to generate a stream of bytes.

I always like it when people ask questions about CardSpace's implementation, the cryptography behind it or really, any other security questions... It reminds me of somethin' my pappy told me... "Always take a good look at what you're about to eat. It's not so important to know what it is, but it sure is crucial to know what it was." That kind of advice works really well for security, just as it did for those odd-tastin'' sausages we barbeque'd up that night.

Labels: CardSpace, fearthecowboy, PPID

 

Miha replied to my post on PPIDs, with some interesting questions.

However, everybody says "no passwords" -- I beg to differ. This is exactly the same situation as it is with client certificates.

You are quite correct sir. Using personal information cards are very very very similar to using client certificates.  So, what's the difference? Infrastructure, and simplicity.  CardSpace essentially brings cheap, easy PKI to the people. Using client-certificates certainly fits the bill, but unfortunately, the tools, management and concepts aren't built for my Mom, (but built for me).  That is, I get it, but my mom has no idea what the heck I'm talking about.

 

 

Why would you need a password, if a user logs in with the client certificate?

 

You wouldn't. I assume, that Miha isn't from North America. I've found the use of client certs far more prevalent outside of the US and Canada.  Somehow, the concept isn't very popular around here... I guess we'll have to get Senator Stevens to buy us some more pipes so that we can fit bigger pipes to the internets.  Again, client certs work fine, but aren't fine to work with.

 

Certificate was issued with someone you can trust (and verify), the certificate is valid, the data is signed with the user's private key (and you have the public key).

No argument there.

 

Now, all the sites I visit, that require client certificate, require the password too.

Are you indicating that you use a password and a certificate, or a password-protected certificate (aka, a pin-protected certificate)?

 

With a pin-protected certificate, we're getting to the crux of the matter. With a certificate that requires a PIN (and what is a PIN, other than a password) you are accessing protected content.  The difference is, the pin your gatekeeper to your private key, not the secret shared with the website.  You never, ever, need to tell someone your PIN/Password for a certificate. Not the RP, not the IP, not-nobody-not-nohow.

 

Otherwise, someone, that gets hold of my computer (notebook) could log into my bank account without knowing anything.

Bingo. You betcha. Unless your private key material is protected by a PIN, you're wide open for that.  Security is about "Something you have" and "Something you know".  So, if someone steals your laptop and your certificate is PIN protected, you have the knowledge that they aren't likely going to get around that (provided a good enough PIN). 

 

Sure, it is more secure, if certificate is guarded with a password (high security in IE, master password in firefox), but infocard(s) isn't (aren't) guarded with a password.

 

So, what if I told you that CardSpace DOES protect each and every one of your cards with not just one, but two passwords. AND gives you the option for a third!

 

The CardStore that you have is twice encrypted, once with the machine key, and once with the user key.  Encrypting with the machine key, ensures that if the cardstore is taken off-box, it's rendered useless, as the key for decryption is stored on that box. Either the attacker needs to get administrator access to the machine and compromise the machine’s DPAPI key, or he needs to be able to run code on the machine to call the decryption function. It's not making it impossible, but it's putting a protection countermeasure in his way to slow down the attack. ¹

 

The second layer of encryption is with the user's key. Because the card store is encrypted with the user’s credentials, when the user is not logged in to the machine, her key is not present on the machine at all.

 

So, wait a second.... The information cards are password protected. If you have lost your laptop, and someone steals it, unless they login with your password, they can't access the cards.  Even if they use the various physical-box methods (or any method really...) to reset your password , the keys won't match and they will render the card store useless permanently.

 

And finally, if you don't have the security around your logged in laptop, or you simply want to stop those kids from using your information cards from your always-logged in home PC, you have the option to individually PIN protect each and every card separately.

 

What's wrong with passwords anyway?

I know, I'm just throwin' good judgement into the wind on this, but let me make a couple of points.

 

Passwords that are used as shared secrets are the absolute biggest hole in security today. As my pappy use'd to say "Lettin' the cat outta the bag is a whole lot easier than puttin' it back".  If I give a site a password, and they require me to divulge the password back to them before granting me access, It's my butt between the bull and the fence if the connection between me and them ain't secure.  And for every other person I tell that same secret to, I lose security on another order of magnitude.  Given that folks tend to use the same  5 or less passwords at all the sites they visit, the world is a heckofa lot less secure that it should be.

 

Cryptography gives us the tools to correct the wrongs we've done with passwords. CardSpace brings cryptography to everyone.

 

<feeling musical, queue's up some Kiss, mangles the words>

...

God gave cryptography to you, gave cryptography to you
Gave cryptography to everyone (oh yeah)
God gave cryptography to you, gave cryptography to you
Put it in the soul of everyone

...

 

So, what have we learned?

 

1. Passwords, when used as a shared secret, are the epitome of insecurity.

2. All information cards stored in CardSpace are in effect, password protected with your login credentials and the machine key of your PC..

3. If that isn't enough, PIN protect them again.

 

 

---

For a quick bit of useful information about DPAPI, the machine key, and the user key, check out the text by the very excellent Keith Brown.

Labels: CardSpace, fearthecowboy, Login, PKI, PPID, Security Tokens

 

I promised Vittorio that I'd write a post on PPIDs (Priavte Personal Identitifers), especially since he's gotten around to his. :D

 

With CardSpace, the PPID is a claim that the built-in STS will generate. It's the only claim that a personal card can have that the user doesn't get to control.

 

How it is made

When a user goes to present a personal card to a relying party, and generate a security token, CardSpace takes the SSL certificate of the relying party, and, with the Master Key, uses data from the certificate to create two things: a public/private key-pair and the PPID.  The data that it uses from the certificate depends on what type of certificate it is.

 

For an Extended Validation (EV) SSL certificate, Cardspace uses the O, L, S, C fields from the Subject field of certificate. These represent the Oraganization, Location, State and Country of the subject (the RP).  Given that the CA has done some extended validation to verify the details of the subject, the subject gains the security that no other EV SSL certificate will have the same fields (unless issued to the same organization).  This also grants the benefits that a organization can have a certificate re-issued with a new public/private key pair, and not affect the identities stored based on it.

 

For a regular SSL certificate, CardSpace uses the subject fields from all the certificate in the chain, all the way to the root certificate.public key of the certificate. This of course makes the PPIDs and key-pairs generated from that dependent on the issuance chain in the certificate. This may be a problem, if the certificate needs to be re-issued with a different chain later.

 

This is different than I had said in the past (where I said it was all calculated off the public-key of the RP's certificate), I was apparently behind-the-times with this. Thanks Caleb. Dern newfangled-cryptography!

 

The net effect of this, is that the PPID and the public/private keypair are completely different for each and every relying party, even when the same personal card is used.  This allows people to use the same personal card everywhere, and not worry about someone replaying their credentials.

 

So, I can rely on the PPID then?

 

What? Are you crazy!?

 

Anyone <glares at Caleb> could craft a token by hand that could contain the PPID. You can't rely on that. ... Alone.

 

In order to validate the identity of the person presenting the PPID, you have to also verify that they possess the private key which matches to the public key they presented to you with the PPID. The public key is delivered in the form of the Issuer's public key in the SAML assertion.  The token is signed by the Issuer's private key, providing  proof of possession of the private key. This signature can be cryptographically verified by the relying party.

 

So, you can rely on the PPID, if you verify the signature of the SAML assertion. And, you should store the public key, so that someone else can't craft a token with someone elses PPID, and sign it. So, you have to check both the PPID and the public key, after verification.

 

Or, you can get lazy as heck.

 

The TokenProcessor code I wrote verifies the token, and since unverified tokens will throw an exception, this makes this pretty easy.  As an additional step, the class provides a UniqueID field, which is the cryptographic hash of the issuer's public key and a claim that is unique to that issuer (defaulting to the PPID).

 

So, I can rely on the UniqueID then?

 

As long as the signature is valid (and the Token object won't get through the constructor otherwise), the UniqueID is what it says it is. Unique to that user. For the relationship that you have with that user. That user will have a different UniqueID than everyone else.

 

How about Managed Cards?

 

This works just as fine for Managed Cards as well. You can get the UniqueID for the user based off of the issuer's public key and any field that the Issuer claims is unique in their database.  An issuer may claim that any ID they issue tokens for will have a unique email address, so that the token they give to the relying party (via the user!) is their assertion that the user is who they (the IP) says they are.

 

Hang on here, something seems oddly familiar.

 

Uh-oh. My pappy used to remind me of two things about gettin' into trouble. First, "Never slap a man who's chewing tobacco." .. that's good advice you can't afford to forget. The second is a little more on-topic, "If you find yourself in a hole, stop diggin' ."

 

If you have two things which constitute credentials, only one of which is provin' that the user has something that you don't know, isn't  "PPID" and "Issuer's public key"  just like "Username" and "Password" ? ... Why of course it is!. Except that the password isn't sent. The proof of the possession of the password is sent by virtue of the token being signed by the private key.  And the when public key is sent along with the signed token, the relying party is verifying the password.

 

Finally, you get to the point.

So, if'n yer lazy, you can add a column to your user database, call is UniqueID, and just verify the token, and get the UniqueID field, and look it up to log em in.

 

Or, if'n yer stubborn, you can put the PPID into the UserID field of your database, and the issuer public key into the password. I just hope that the password field in your database takes 2048 byte passwords. (heh-heh)... You may want to store the hash of the Issuer's public key. Then you don't have to touch the database, you don't have to change anything, except for a tiny few lines of code to extract the "username" and "password" from the token.

 

And, now a word from the paranoid bull in the corner.

 

I've seen a few bits of Relying Party code pop up on the Internet, and I haven't looked at many of them in detail. I will however grant you this word of advice.

 

IF YOU ARE WRITING CODE TO DECRYPT A SECURITY TOKEN AND ACCESS THE CLAIMS IN IT, YOU MUST VERIFY THE SIGNATURE ON THE TOKEN. DO NOT SKIP THIS STEP

I can not stress this enough.  I've seen some people posting code on the net in different languages, but not performing the signature validation. That's akin to asking for a username, but not checking the password and logging them in.

 

Y'all relax and enjoy.

Labels: CardSpace, fearthecowboy, Login, PPID, Security Tokens

Chuck just dropped me a line, he's taken the XPCOM interface that Kevin defined in his FireFox extension for CardSpace and implemented the interface to allow his code to work in the same vein.  He's also added the code for a configuration dialog, which Kevin hadn't done yet, so now you can switch between the different Card Selectors in FireFox from a configuration dialog.

One word describes this: SWEET.

 

Chuck says it just perfectly:

The great news is that people implementing selectors will no longer need to worry about augmenting the browser. Now hopefully we can all quickly agree on a preferences structure to allow any implementation to easily add itself to the list.

If you're interested in writing you're own plugin, it's pretty simple...here's the basics of an XPCOM component that implements the plugin interface:

http://openinfocard.googlecode.com/svn/trunk/firefox/components/Identityselector.js

I was recently asked about this idea that there should be multiple card selectors, and doesn't that somehow break rule #7 "Consistent Experience Across Contexts" ?

 

The answer is, No, not really. It's important that each user is given a consistent experience across each context, not that different users experience the same thing.  As a matter of fact this impairs phishing attempts due to the phisher not really knowing what Identity selector they would have to fake out to dupe the user. 

This is just more Good News on the Identity Frontier.

Labels: CardSpace

Detecting support for CardSpace, or more importantly information cards in the browser is pretty important, as it would allow the web developer the opportunity to appropriately show the "sign in with your information card" button/link or other text as needed.

The following Javascript will return true if you have support for information cards.

function AreCardsSupported() {   var IEVer = -1;   if (navigator.appName == 'Microsoft Internet Explorer')     if (new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})")        .exec(navigator.userAgent) != null)       IEVer = parseFloat( RegExp.$1 );    // Look for IE 7+.   if( IEVer >= 6 )   {     var embed = document.createElement("object");     embed.setAttribute("type", "application/x-informationcard");     if(  ""+embed.issuerPolicy != "undefined" )       return true;     return false;           }       // not IE (any version)   if( IEVer < 0 && navigator.mimeTypes && navigator.mimeTypes.length)   {     // check to see if there is a mimeType handler.     x = navigator.mimeTypes['application/x-informationcard'];     if (x && x.enabledPlugin)       return true;     // check for the IdentitySelector event handler is there.     var event = document.createEvent("Events");     event.initEvent("IdentitySelectorAvailable", true, true);     top.dispatchEvent(event);     if( top.IdentitySelectorAvailable == true)       return true;   }   return false; }

Labels: CardSpace

This is very exciting news.

Kevin Miller, has released his FireFox extension for CardSpace. We have been collaborating for the last several weeks in order to for him to deliver this really critical piece of the Identity Metasystem.

Kevin's work on this has been nothing less than fantastic. I assisted him where I could, mostly in helping him test it, and giving him the sample code that I provide at the CardSpace Website. 

The extension, in it's first release is pretty damn impressive. It's got support for the whole <object> tag syntax, as well as the alternative <ic:information card> syntax, it's fully supported by scripting, and it seems to work pretty much exactly as the support in Internet Explorer 7.0.

Of course, it does rely on the .NET 3.0 framework, as this actually uses CardSpace to deliver the security token back to the browser. (which kinda limits it to Windows, right?)

 

BUT WAIT, THERE'S MORE?

He's built it in such a way that another identity selector can be plugged in, simply by implementing an XPCOM interface. This makes it significantly easier for other developers to get the same level of support from FireFox as CardSpace! (Hey, even IE can't do that...  yet!) I suspect this will accelerate much of the open-source identity selectors we're likely to see.

 

So how can we know that it's there?

Well, I confess, I've gotten to play with it a lot over the last week or two. Which means that I was able to jump the gun and figure out how to detect it. (Actually Kevin had to put some code in to *allow* me to detect it. FireFox-R-A-Tricksey browser!). I'll make another post here later today that demonstrates that.

Labels: CardSpace