Firefox Personas and openinfocard

If you have personalized your Firefox with Personas then your openinfocard selector window now shows the same background image.


Which is nice and a security feature too. A malicious website could try to create a window that looks like your favorite openinfocard selector but the website does not know how you personalized your browser. So if your card selector window does not show the same background image as your browser then something is phishy!

Get the current (xmldap-0.9.9.201002251149.xpi) version of openinfocard now!

Did I say that openinfocard runs on MacOS Snowleopard too?

Auth-napping OpenId by Weave

My first feeling was that this is a bit intrusive but then...

Here is a picture of the authnapped OpenId form:

Here is a picture of the original OpenId login:

It is the user's decision to install and use Mozilla Lab's project "weave" or not. And this solves parts of the NASCAR problem. Why should the service provider suggest some OpenId providers using the NASCAR? Well, if he has a whitelist of trusted OPs then yes.
But the OpenId-NASCAR is a cludge anyway.
I think that there should be an XRD description of which authentication methods and providers and token formats and so on a service provider supports or requires. Then a client component - read Browser extension - could help the user to make a good decision and prevent phishing attacks and more.
The user does not care whether the protocol is OpenId or Information Card or if the token format is SAML2 or what not. A unique user experience is desired. Ease of use is required. User consent is required. Security and Privacy need to be protected.

This should be "in the browser"! Secure by default. Privacy protecting by default.
I guess I don't have to repeat that I prefer the Information Card metaphor and UI. A client component is a good thing and it should be ubiquious, build-in but replacable and configurable at the user's choice.

Identification, authentication and claims/attribute transfer is not the primary service provider's interest. Those tasks should be moved outside of the website's code into an authnapping module of the user's browser.

Authnapping is good!

Information Cards: Unused (Security) Information

It seems that I have to make up for not posting while my new house was build...

Here is another post for today in the series (1,2,3) of posts around things you always wanted to know about Information Cards but never had the heart to ask.

Did you know that CardSpace does not use the Identity information in an identity enabled EndpointReference? Shocking.
Here is what I heard...

When you import a managed card from a .crd file there is something inside the file that is called the TokenServiceList that contains a sequence of TokenService(s) that contain an EndpointReference. This is defined in WS-Addressing and in our case extended to contain an element "Identity" from the namespace "http://schemas.xmlsoap.org/ws/2006/02/addressingidentity".

<Identity
 xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
 <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
  <X509Data>
   <X509Certificate>
MIICfTCCAeagAwIBAgIBATANBgkqhkiG9w0BAQUFADAqMQ0wCwYDVQQKEwRPU0lTMRkwFwYDVQQLExBJ
bnRlcm9wIEJvZ3VzIENBMB4XDTA4MDYxMTE2MTIxM1oXDTA5MDYxMTE2MTIxM1owSzENMAsGA1UEChME
T1NJUzEZMBcGA1UECxMQSW50ZXJvcCBCb2d1cyBDQTEfMB0GA1UEAxMWdGVzdC5wYW1lbGFwcm9qZWN0
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAz9qsJnJd/ZD8Fr/uGSojxMVoD53w28O14RLB
Hfm3scuFd9ypxy7KU8fOkDyOtKWoHqAVpPd/TRHIYiyRVorEyIiqQpbKCcqUd2YJM9nVxHuOHYvrVXRj
QAVV3Fu4Ncy22Tl+lJRJzWgcfc89aqFoyIv2tmqvAisRyNf6+1eppmcCAwEAAaOBkTCBjjAJBgNVHRME
AjAAMBEGCWCGSAGG+EIBAQQEAwIGQDALBgNVHQ8EBAMCBaAwKgYDVR0lBCMwIQYIKwYBBQUHAwEGCWCG
SAGG+EIEAQYKKwYBBAGCNwoDAzA1BglghkgBhvhCAQ0EKBYmT3BlblNTTCBDZXJ0aWZpY2F0ZSBmb3Ig
U1NMIFdlYiBTZXJ2ZXIwDQYJKoZIhvcNAQEFBQADgYEAIppR+riUA/cxJJBaNGslzoa297XMUqQelJ15
1UcGUWCqTxer2/b5nUG2TpmnA0/7CPCjE2t44st6MImB2tqDtI7DNSCKz19aNlhpoHa8MrCjPKHlDNIU
nqg3ZylCxbwm40G5NFiAXXCUznYyD9J6AhDesSvGCRCo3OStKaxr7jM=
   </X509Certificate>
  </X509Data>
 </KeyInfo>
</Identity>

Can you imagine: CardSpace just throws away this certificate and never uses it!

What is this certificate anyway? Some clever people came up with the idea that EndpointReferences need more security and should be protected by Identity. One way to provide endpoint identity information is to specify which certificate will be used by the (security token issuer) endpoint. This for the theory; in practice CardSpace does not use this information.

Why? Well, when the certificate is valid at the time the information card is issued but invalid after some time then the issuer would have to re-issue all cards that contain an EndpointReference with that certificate attached...
Microsoft thinks, I guess, that in general people - even professionals - are to stupid to handle the crypto-thingy correcly.
I don't know. I think that we should expect an Identity Provider to know its business and part of that business is to handle the certificates/keypairs etc so that the Identity Metasystems handles a renewed certificate without hickups.

An alternative to specifing a certificate is to specify an RsaPublicKey. This has no validity dates attached to it so it can not become invalid. If the STS specifies the public key then it can change certificates or part of the information in the certificate as long as the keypair stays the same.
This advantage of keypairs in contrast to certificates is an disadvantage too. Should the private key of the keypair be compromised then all information cards have to be re-issued (Super-GAU). Well, this falls in the category "This should never happen". We should expect to see this not too often.

Enough gossip for now. Time to call it a day.

Enjoy.

XKCD measures and controls

There should be controls in place that the Anti-Virus SW is not interfering with the voting SW.
There should be controls in place that there are no holes in the AV-SW that lets Viruses slip through.
The voting machines should be regularly checked that they were not harmed by the AV-SW.

Now for the analogy...

As a parent I don't like the analogy...

Carnards Die Hard

A while ago two students, Xuan Chen and Christoph Löhr, from Ruhr University Bochum claimed to have "broken" CardSpace. There were some blog reactions to this claim. The authoritative one of course is from Kim.

Today I browsed through a magazine lying on the desk of a colleague of mine. This magazine with the promising title "IT-Security" repeats the false claim and reports that the students proved that CardSpace has severe security flaws... Well, when you switch off all security mechanism then, yes, there are security flaws (The security researcher in front of the computer).

What can I say?! The existence of this magazine was new to me, but sure they have some readers. The IT-Verlag charges 20€ for this pile of rubbish (Sorry) not very well researched article (page 42).

Interestingly Microsoft is having an ad (the whole second page) in this gazette…

There is still a lot of work for the Information Card Foundation to do.
One of my tasks (privately and not as a member of the ICF) today is to question my colleague about the value of his magazine subscrition...

Stealing the Security Token

The Ruhr Uni Bochum claims that they can steal the security token in a CardSpace scenario.... The experts from the German computer magazine c't could not verify the attack...
After reading the paper that describes the attack I must say that I find it very unrealistic.

The attack is described for managed cards. The browser is tricked to load malicious code and then the real RP's code is loaded and presented to the user. The malicious code then loads the root certificate for the malicious RP's SSL certificate and asks the user to install it into the trusted store. This is the biggest assumption in the scenario. Next the user clicks the purple CardSpace icon.

Case 1) Auditing Mode
Assume that CardSpace is tricked to request a token for the malicious RP. When this is the first time CardSpace sees this RP (which is likely) then there might be little CardSpace can do to help the user to recognize the malicious site (because of the installed root certificate). When this is not the first time then CardSpace will warn the user who will probably terminate the transaction.
But who installs a root cert into a trusted store might continue the transaction even when CardSpace raise all flags and blinks all warning lights.

First: The IdP might reject to issue a token to an RP with which it does not have a contract or is outside the (enterprise) circle of trust. Then this attack does not work.
Second: When the IdP issues a token to the malicious RP then that RP can decrypt the token and read the (private) claims. Then it encrypts the assertion for the real RP. The malicious code in the browser (loaded from the malicious server) receives the newly encrypted token and presents it to the form for it to be submitted. The assumption that the malicious code can now reuse the security token to whatever purpose it likes at the RP is not true because the auditing mode restrict its use to the malicious RP.

Case 2) Non-Auditing Mode
Assume the same prerequisites as in case 1. The user is super stupid and the token is stolen and not restricted to the malicious RP. So whenever the real RP expects a security token the malicious code in the browser can provide it.

Do I have to say that an attackers code running inside my browser is probably deadly anyway? Even when the token is not stolen the likelihood that the claims will be a visible part of the "next" page is high, so they can be stolen this way too.

Can't wait to hear what Microsoft writes about this. I had a long busy day and will rethink the whole thing tomorrow.

Disposable Temporary E-Mail Address

While musing about reputation and trustworthyness of information I came across http://www.trustme.com/. They provide you with a disposable temporary email address that is valid for 15 minutes. This seems quite usefull if some RP requires to know your email address before it serves out some information like e.g. a whitepaper. Now you can receive that one-time-link from the RP, use it for email-verified-login, download that paper and forget the RP again.

But why is trustme.com doing this? Altruism?
Can I trust Steve Cannon, 5699 Kanan Road #115, Agoura Hills, CA 91301, US not to read my temporary email? What is his reputation? Probably his address is outdated anyway?!

KeeLoq Broken

KeeLoq, the major remote keyless entry system for cars and buildings is hacked - again.

The CryptoLab of Ruhr University Bochum published an attack on the most widely used remote keyless entry system. The researches used a differential power analysis to recover the manufacturer key. With that key all you need is two messages between the key and the door/car. These messages can be picked up from 100m away. Knowing the manufacturer key allows for creating an arbitrary number of valid new keys and generating new remote controls.

This is a new attack and should not be confused with an older ones.

CardSpace getting FAT

The CardSpace team blogged about a new "feature" of .net 3.5. You can now work with CardSpace on a windows system that has its system drive formatted with the FAT filesystem...


They write:

We’ve received a surprising amount of feedback (some of the earliest from Pamela Dingle) that customers are still using FAT file systems and this is causing problems.

I am surprised too. What will be next? CardSpace running on windows95? Help!

Sure, the cardstore is still encrypted twice... but still...
I believe that this is a step back. Security sacrificed on the altar of (what?) laziness/stupidity/...

As a security auditor I would question the risk management of anyone who still uses FAT in 2007.