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