CardSpace Team Blog

You will find this interessting: http://blogs.msdn.com/card/

2007 IDDY Award goes to Rearden Commerce

Chuck Mortimore today received the 2007 IDDY Award of the Liberty Alliance Project on behalf of Rearden Commerce. Chuck is the original author of the openinfocard id selector and the xmldap STS an RP. Congratulations!

Win an iPhone

The Bandit Project gives you the chance to win an iPhone if you get an Information Card here: https://cards.bandit-project.org/

So... You don't care about Information Cards and just want that iPhone? What is the shortest way to this goal?

If you have Windows Vista, then this is easy. Everything will just work out of the box.
If you have an older version of Windows or an "alternative operating system", then download the best browser on earth: Firefox and get an Id Selector e.g. the openinfocard id selector or something from here.

If you have Windows XP, then as an alternative way you might get IE7 and .NET3. And don't forget to visit update.microsoft.com afterwards.

Thanks to the Bandit Project for this promotion of information cards.

BTW: If I win, I would prefer the T-Mobile version. :-)

DIDW 2007 09 24 WLAN

This is off topic, but I am astonished by the number of WLAN access points "visible" in my hotel room. Maybe an error in my WLAN software?

IA Management

The openinfocard id selector now has a "Manage Cards" button on its preferences page.

The preferences are displayed when you choose the menu item "options" from the "tools" menu. Pressing the "Manage Cards" button opens the same window that pops up when you visit a relying party. You can create and delete self-issued cards from here and you can import and delete managed cards from here. You can't (currently) retrieve the values of a managed card from this dialog.

The new version (xmldap-0.9.8.200709212108.xpi) of the openinfocard id selector can be found here. I will update the version number to 0.9.8 after I added some more features; like displaying the privacy statement. This can't currently by done because Kevin Miller's Firefox extension uses privacyPolicy instead of privacyUrl and privacyPolicyVersion instead of privacyVersion. (And because the openinfocard id selector uses Kevin's selector selector.) I hope that either Kevin or Garrett will fix this soon.

Another needed feature for the openinfocard id selector is "phishing defense". This should not be too complicated to implement, but will make an update of the internal card store format necessary.

Anyway: Manage your cards!

Smartcards as a trusted security anchor

Today I am attending a CAST workshop about smartcards and their use to solve security problems.

The first talk is held by Michael Senkbeil from the Sparkassen Informationszentrum.
They have 64 million smartcards issued in Germany.
These cards are mandatory in Germany if you want to buy cigaretts. The card is used to proof that the buyer is old enough to buy cigaretts.
Mr. Senkbeil will tell us today how this scenario can be transferred to Internet usages.

First the user needs a smartcard reader and a browser plugin. Get the Plugin for Firefox here.
The browser plugin is triggered by the relyingparty. It contacts the smartcard and gets encrypted data from the card that it transfers to the relying party. The relying party has (multiple) server cards that decrypt the data and present the readable content to the RP. The server card(s) are issued by the Sparkasse too.
Phishing protection is not a main feature of this solution.
Mr. Senkbeil recomments to add this mechnism to the "normal" username/password scenario. If the card gets lost then there is no additional security on the card. It is not PIN-protected. So everybody can use the card. To minimize this risk he proposes to use a password in combination with this new scheme.

Feature list:

• age verification
• Laden der Geldkarte
• Internet Login

Q&A:

Q: Is this a Sparkasse only solution?
A: No. Every german "EC-Card" should work.

Q: API
A: PC/SC

Q: Demo had no password input
A: Card number is the userid. The password is the password of the relying party.
The password needs not be used.

Q: is the plugin signed
A: Yes it is.

Q: Profiling? Linkability.
A: is possible. The card number is a unique number.
My comment: This is not good. We need to integrate this with CardSpace.

Q: How does the user recognize the server? How does he verify that the server is the true one?
A: SSL. The proposed solution has no mutual authentication.

Q: How does the challenge-response mechanism work?
A: The RP generates a challenge that is used by the card. The plugin transfers the challenge to the card and receives an encrypted block of data. The RP has cards too, that decrypt the data and compare the challenge.

Q: Sparkassen Internet Banking: Will the Sparkassen use this mechanism to secure it's own internet banking?
A: A new class of smartcard reader is currently worked on. This will be released to the public next year.
Comment: This answer means: No.

Q: Is the cryptography symmetric or asymmetric?
A: Symmetric with derived keys.

Smartcards for Tachographs

The second talk is held by Mr. Klaus-Peter Schmidt from Sagem-Orga GmbH.

Security Evaluation of Smartcards

The third talk is held by Mr. Detlef Kraus from SRC Security Research & Consulting GmbH.

Crypto Algorithms for Environments with limited resources

The fourth talk is held by Mr. Axel Poschmann from the Ruhr-University of Bochum.
CPU-Market: PCs 0,2% -- embedded systems 99,8%

Smartcards: 8Mhz, 8bit, a few kilobytes memory

Metrics and tradeoffs for light-weight crypto

• security
• low cost
• performance

Mr. Poschmann explains the features of PRESENT (an ultra-lightweight block cipher).

The Identity of the Connector

Talk by Dr. Jens Urmann from InterComponentWare AG about a part (the connector) of the German health care system infrastructure. -> This usally gets messy really quick if you dive into the details... (not blog compatible)

Security anchors for mobile devices

Mr. Michael Kasper gives an overview over xSIM architectures.

• USIM
• MegaSIM
• Dual Trust-Anchor Architecture using (U)SIM and MTM (mobile trusted module)
• Single Trust-Anchor Architecture using virtual SIMs and a MTM

Next he gives an introduction to the Trusted Computing Group's Mobile Phone Working Group (https://www.trustedcomputinggroup.org/groups/mobile).
Then he describes his work about virtual SIM cards that are based on a MTM.
-> OpenMTM http://sourceforge.net/projects/openmtm/
EMSCB Turaya http://www.emscb.com/

SIM and USIM Application Toolkit

Talk by Mr. Harald Summer from Giesecke & Devrient.
Mr. Summer explains the file system of the SIM. He shows a tool by G&D to view the file system. Next he shows the internals of a SAT application and explains what bytes flow from where to where. Hard core tech talk.

Enabling Trusted Mobile Applications with the SIM

Talk by Mrs. Stephanie Manning from Vodafone Group R&D. The focus of the talk is about how to integrate NFC and mobile phone technology. She describes her projects and the techonological challenges. Applications/Products are to be expected in the first half of 2008... They are using Global Platform 2.2 for their projects. Vodafone and Deutsche Bahn will have a trial this year: http://www.touchandtravel.de/. Mrs Manning does not expect that Vodafone will deploy applications to the phone's SIM because then application providers would have to have contracts with every mobile operator. Trusted Services Providers will take the role of deployer of applications to "rented" space on the (U)SIM.

Multi-application security platform UICC

Talk by Mrs. Chen Hao from Giesecke & Devrient GmbH.
Mrs. Chen Hao talks about the single wire protocol and the new developments in UICC technology in general. A further example of these new technologies is the definition of a USB 2.0 interface directly to the UICC. This will allow for having gigabytes of memory on the UICC.

openinfocard id selector for Firefox signature validated

Finally! The signatures generated by the openinfocard id selector and the openinfocard STS are now accepted at relying parties that are based on Microsoft code. Mark Oluper from Microsoft's CardSpace team put the generated SAML assertions under his microscope and found the offending byte.

Axel,

The issue is that the key length doesn't match the signature length. The Windows CryptVerifySignature API verifies that the key length in bytes matches the signature length in bytes.

If you look at the modulus value for the Firefox identity selector generated assertion you will note that the value does not have the base 64 padding character whereas the signature value does. This results in a key length of 1032 bits (129 bytes) whereas the signature value is 1024 bits (128 bytes).

For the CardSpace generated assertion both the key length and signature length are equal to 2048 bits (256 bytes).

Regards,
Mark

So, what is the reason for this extra byte and why are the signatures accepted by relying parties that are Java based? Well, Java's BigInteger class introduces an extra null byte as the first byte when it converts a BigInteger into a byte array. I removed this extra null byte before base64 encoding the modulus of the signature key and now it works! AND the Java signature validation still works too!
Why does it work? Because Java just decodes the base64 encoded modulus and the constructor of BigInteger ignores extra null bytes but does not require them. There could be hundrets of null bytes and Java would still construct the same BigInteger modulus.

I did a quick check with self-issued and managed cards at several relying parties and all looks good.

- openinfocard RP (Java): local installation

- Bandit Project RP: https://wag.bandit-project.org/BanditIdP/index.jsp

- jinformationcard demo shop (Java): https://zeno.fokus.fraunhofer.de/MiniShop/home.jsp

- FuGen Solutions' Demo RP: Microsoft Code https://socialphotos.federationportal.com/

- FriendsWithCards RP: Microsoft Code https://www.cardspacedemos.com/FriendsWithCards/

The new - latest and greatest - version of the id selector is here in the openinfocard download area.
Thanks again to Mike Jones and Mark Oluper for helping with this issue!

Populate Attribute From Infocard

This is the real application for information cards. Using them for authentication purposes is fine, but the transportation of claims/attributes is the real thing.

The id selector used here was, of course, the xmldap id selector for Firefox in its latest version 0.9.7.200709111523. I used a self-issued card and a managed card from the current openinfocard STS. The RP used was the Bandit's project server for the next interoperathon (sorry, you have to login at OSIS to read this. Don't ask me why.) in Barcelona.

DIDW 2007

Meet me there.

OSIS Identification Required

Why do I have to identify myself when I just want to view the new OSIS timeline?

What about "Minimal Disclosure for a Constrained Use"?! Or the German Bundesdatenschutzgesetzt §3: Datenvermeidung und Datensparsamkeit?

And then this:

I can not view the new OSIS timeline because my IdP is offline.
This should never happen ;-) /* my favorite comment in C programs */

But then you think "pseudonyms are cheap". Let's just choose another openid. BUT:

Signon.com tells me that this is my openid: ignisvulpis.signon.com


Just in case somebody thinks this might be Firefox specific or has anything to do with the xmldap id selector (0.9.6). It has not. Here is the IE7 result:

Stranded in the Metasystem.

Openidcards

Thanks to Johnny Bufu's help I finally improved the xmldap Firefox id selector to be able to handle openidcards.



The id selector was retricted to SAML assertions as token type and could not handle "AppliesTo" correctly.
The new version can be downloaded here. Try it!

Again I want to thank Johnny for his patience and support. Without him I would not have found out about the wrong namespaces, missing elements etc. Thanks to Mike Jones too who did, as always, a great job bringing parties together.

AudienceRestriction

The xmldap relyingparty (svn version 339 or newer) now displays the subject's confirmationmethod:

urn:oasis:names:tc:SAML:1.0:cm:bearer or urn:oasis:names:tc:SAML:1.0:cm:holder-of-key

and the audience restriction.

...
<saml:Conditions 
 NotBefore="2007-08-21T07:18:50.605Z" 
 NotOnOrAfter="2007-08-21T08:18:50.605Z">
 <saml:AudienceRestrictionCondition>
  <saml:Audience>
   https://w4de3esy0069028.gdc-bln01.t-systems.com:8443/relyingparty/
  </saml:Audience>
 </saml:AudienceRestrictionCondition>
</saml:Conditions>
<saml:AttributeStatement>
 <saml:Subject>
  <saml:SubjectConfirmation>
   <saml:ConfirmationMethod>
    urn:oasis:names:tc:SAML:1.0:cm:bearer
   </saml:ConfirmationMethod>
  </saml:SubjectConfirmation>
 </saml:Subject>
 ...

Here are two screenshots of the relying party:
First the assertion generated by the Firefox id selector:

Second the assertion generated by Windows CardSpace:

The scrupulous reader of this blog will notice that this Firefox id selector generated a bearer token, while I claimed here, that it generates holder-of-key tokens. I am still investigating why the Microsoft Demosite FriendsWithCards does not accept my tokens :-| It still says that the signature is wrong... That's why I want the token to be as similar to the CardSpace one as possible.
Anyways, with the help of Microsoft we will find the reason for this. Thanks to Marc, Mike and Kim.
Back to the topic of this post: It is good that the xmldap relyingparty now shows the audience restriction.

LiveId not supporting Firefox Id Selector (or vice versa?)

Christian Arnold reports that Microsoft Live is now supporting (beta) Information Cards.
I tried this with the Firefox Id Selector but...


Well, I don't know what's wrong here. Maybe it is the same issue as with FriendsWithCards...? Mike Jones told me he will have somebody look into the FWC issue. I fixed the computation of the thumbprintsha1 inside the Firefox Id Selector, which now computes the digest of the entire certificate bytes (instead of the digest of the public key bytes). FWC could not find the certificate, while other relying parties just use the certificate of the SSL connection, instead of searching for the certificate.
But still FWC does not like the SAML assertion generated by the Firefox Id Selector :-(

Besides: LiveId is no major Internet business according to Microsoft CardSpace:

BTW: How do I remove my information card from the LivID profile? Could not find this option. Maybe a typical user management one way street?

Self-Issued Cards, SIC!

I feel that the focus of Windows CardSpace changed from providing claims to be a mere login mechanism with claims dangling behind it.

Are relying parties really using the provided claims? Will relying parties use the provided claims in the future?

I think that enabling the user to control the claims provides a way to get rid of most of the user management at the RP.
No more "Edit your profile" webpages which are different from site to site.
Just edit your information card and use it. All sites will get the new updated information about you.
But what if the RP needs more/different claims than the standard self-issued ones. Today we would need to introduce an identity provider that issues managed cards with that set of claims.
Why are we not extending the self-issued token server to serve any set of claims?

The user would still be in control of his claims.

Habits

Yes, I read xkcd and hope the author does not mind my abuse of this comic strip.
Read this to understand the tooltip in the original comic.

Presentation of Claims

As I wrote in a previous post I added a demo geopriv STS to the openinfocard code repository which manages civic addresses. As claim's identifiers I used URLs inspired by rfc4119 e.g.
urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc:A6 (street name without number)
You might have seen here and in the image above that the presentation of these claims in the id selectors GUI is, well, not satisfying.
The displaytag and the claim's description from the information card are not very helpful in the case of civic addresses. Maybe the rendering information should be attached to the DisplayToken instead of to each DisplayClaim.
The format of an rfc4119 civic address was designed to work around the globe which makes it a little bit difficult to handle.

Which choices do I have as an id selctor and/or STS?

• I could use a (deep versus flat) claim: ietf:civicaddress which has an XML civicaddress as it's value.
  Current id selectors would display this in one line... Not pretty
  Future id selectors would know that the value of the claim ietf:civicaddress is not a plain text but XML which should be rendered as a user expects it.


• I could enhance the id selector to render claims of this kind appropriately.
  I would have to do this for every new set of claims. -> not elegant


• The STS could include an XSLT (XML geopriv civicaddress to HTML) script to render the claims in the id selector.
  Maybe the RP does know how to render the claims better?
  Maybe the user knows how to render the claims better?


• The RP could render the claims while I chose which card to present.
  This is not desirable, because the RP would learn about all my cards.


• The id selector could render the claims using CSS/XSLT provided by the RP
  Do I trust the RP this much?


• The id selector could render the claims using it's own (provided by the user?) CSS/XSLT script.
  Only a few users will be able to understand this.

More questions than answers. Sorry.

The flat versus deep claim's value needs more discussion too. Maybe it is another side of the same coin? Not.
Mark Wahl has put this far better than me in this short post. His posts are here and here.

Issuer Logo

The Firefox id selector (0.9.4) now displays the issuer logo from the relying party's X509 certificate again. I had added that code last autumn but the code calling this code was lost when Chuck redesigned the GUI in preparation of an IIW. I never cared much to put it back in, because I was kind of frustrated with EV certificates. I tried really hard to generate an EV certificate; I generated a CA certificate and put in the "trusted" store. Next I used that to generate a SSL server certificate which had everything in it what is required to comply to the Certificate Guidelines. But neither IE7 nor Cardspace accepted this as an EV certificate. Then I learned that being an EV certificate is not a matter of the certificate but a matter of the certificate store. Microsoft developers have a custom tool to turn a certificate inside the store into an EV certificate :-{
Well, this weekend I put the code back in. Here are two pictures of the Firefox id selector displaying the issuer logo from my own local relying party

and the issuer logo from verisign's PIP relying party.

The logotype ASN.1 stuff is here. The java code to generate my own SSL server certificate with logotype support is here in org.xmldap.util.CertsAndKeys.java.
Example code how to use the code is in the JUNIT test org.xmldap.asn1.LogotypeTest.java.

jinformationcard improved minishop

In yesterdays post I wrote that the jinformationcard minishop does not accept the security tokens generated by the Firefox id selector.
Today Steffen Konegen sent me an email that he fixed this in the jinformationcard relyingparty. Cool.

Microsoft CardSpace Demo Site is not working with Firefox Id Selector

I just tried to login using my self-issued informationcard


at Fabrikam Friends. But it throws an error page at me.


My guess is that Fabrikam Friends can only handle bearer tokens not holder-of-key tokens. I noticed the same behaviour at the jinformationcard demo shop.
The internal STS in Windows CardSpace issues bearer tokens


while the Firefox ID selector issues holder-of-key tokens.


Bummer!
Kim's Identityblog is still accepting my tokens. Good.

Though I won't rule out that something is wrong with the Firefox id selector tokens. When 's the next interop?

New Version of the Firefox ID Selector

Today I committed new code to the openinfocard repository.
This has the version number 0.9.3.

• It improves support for managed claims in the Firefox ID selector


• It implements a sample relying party and STS for geopriv claims (civic address)
  

First a managed cards is created, that holds the civic address of my office:

Then the relying party is visited:

The managed card is chosen:

Here are the provided claims:

The managed claims url's are "inspired" by rfc4119.
Besides serving static addresses the new geopriv_sts could issue a security assertion that is based on the current location of the requestor. For this the STS should be operated by the access provider. The authentication to the STS should be by self-issued information card and/or IP-Address (The usual NAT/STUN problems/solutions have to be considered, of course). The client could be a VoIP phone.
In my opinion many topics in the ECRIT mailing list could be addressed by this kind of STS.