Kapil Sachdeva's Blog - SmartCard Serenity

I have seen many architects worried about the fact that going for secure strong credential store like smart cards may result in carrying many tokens in their key chains or wallet full of plastics on account of each of us having multiple identities. And Kim Cameron raises this concern again

<quote_kim_cameron>

If we don’t clearly make this distinction,, we’ll end up in a “fist full of dongles” nightmare that will even make Clint Eastwood run for the hills.

</quote_kim_cameron>

Fortunately this is not true, smart cards run a variety of programmable frameworks such as Java and .NET which are fully capable of hosting multiple applications from multiple vendors (yes they are interoperable) with a firewall among them (to make this situation work securely). Smart card based Banking and Airline miles cards are an example of this. Not to mention that vanilla CSP or PKCS#11 based smart cards do not distinguish between certificates coming from different vendors.

While I am on this topic I fully agree that certificate selection from clients (os and applications) has never been as easy and natural for end users as CardSpace makes it. Thanks CardSpace for this. 

<quote_kim_cameron>

Speaking of smart card credentials, one of the big problems in last-generation use of smartcards was that if a Trojan was running on your machine, it could use your smartcard and perform signatures without your knowledge. 

</quote_kim_cameron>

Yes a Trojan may get a digital signature from the smart card with out user's knowledge if the smart card application was written without following best practices for writing a secure application. BTW the same applies to Windows apps as well. A typical smart card application must utilize end-to-end secure channels for communication and should authenticate the client applications it is talking to. Now there is a problem of authenticating the client applications ... can't put the shared keys in them.... so there are limitations but as we go further we address them or technologies vertical to us do.  NIM, which is the latest offering from Gemalto does that by validating the remote servers using PKI and I would show case in coming days how [traditional] smart cards could help in reducing the phishing attacks if not eliminate them for web based transactions.

The thing to note here is that smart cards alone are not capable to solve all security problems (phishing, impersonation, trojans) but their usage in smart environments such as that of CardSpace brings value to everybody. A complete secure technology would be a joint effort from different actors which compliment each other and I am sure we would see that happening. Amen.

<quote_kim_cameron>

</quote_kim_cameron>

http://projectliberty.org/resources/whitepapers/SIM_Strong_Authentcation_Whitepaper.pdf

"This paper presents an innovative service called SIM strong authentication service that extends the usage of GSM SIM authentication to Internet Web services. The goal of this proof-of-concept is to demonstrate the possibility of implementing innovative service in a heterogeneous environment using Liberty Alliance Federation Standard. Telenor, Axalto, Linus and Oslo University College have implemented a proof-of-concept prototype in Oslo. The architecture is based on a multi-vendor environment where SUN provides the Identity Provider, IBM the Identity Provider and Service Provider Proxy to connect non-Liberty Alliance Service Providers to the system, Lucent Technologies the Radius server and Ulticom the SS7 MAP Authentication Gateway connecting the prototype to the Telenor mobile network. A typical user flow for such a service would be the case of a user browsing on the World Wide Web from home, a customer premise, an Internet café, etc. When trying to access a protected resource such as Webmail, company portal, or bank account, he logs on to the requested secured site simply by placing his mobile phone close by and communicating with his PC via Bluetooth, or using a SIM card-equipped dongle, card reader, or 2G/3G PC card. This service is available anywhere and can support any Internet services. It is ideal for services like Internet Banking, eAdministration or enterprise internal web pages. The SIM strong authentication is both user-friendly and cost efficient, with a low deployment threshold. The technology is also capable of supporting other Smart-Card based identity services such as USIM (UMTS), certificate based schemes (E.g. TLS) and One Time Password schemes (OTP). A demonstration of the SIM based service is being demonstrated at the 3GSM World Congress in Barcelona, February 2006."

Rohan writes:

InfoCard or JavaCard // Identity Management
Kim had posted a nice article on A simple managed payment card example a while ago. So basicaly
what happens with a "issued" infocard is that the infocard only contains a pointer to where the 
user information is to be obtained from (in this case as per Kim's example the issuer happens 
tobe Bank Of America, and the requestor is amazon.com). Well, Kapil had a nicer post on
Smartcards and Federated Identity. Kapil quotes Smartcards are the actually the real enabler of
biggest network of identity federations world has known till date i.e GSM.

[...]

various standards like SAML, Liberty, InfoCard/WS-Trust, WS-Federation etc for identity 
federationrespect and understand the usefulness of security devices like Smartcards. All 
these standards propose the solution to same set of problems in almost same way and differ
mostly in wire protocols used. SAML and Liberty has a profiles ECP (Enhanced client proxy)
and LECP (Liberty enabled client or proxy) respectively which enables a Smartcard based
authentication where as InfoCard (a profile of WS-Trust) treats Smartcard as another Security
token service which can generate self issued security tokens.
 
nice... I see the light at the end of the tunnel. infocard treats a smartcard as a personal 
security token service (PSTS) which can issue security token in form of SAML assertions. 
and so i thought... or rather... continue to think...
Whats the difference between the long existent JavaCard/Liberty vs InfoCard/WS-Federation ? 

JavaCard/Liberty vs InfoCard/WS-Federation : There is no comparison matrix like this because:

JavaCard technology is not tied to Liberty Alliance and vice versa. Liberty Alliance specifies that security devices (and smart card is one example) can be used to do the authentication. How to communicate to them is unspecified and which makes sense as they will have to specify the protocol for every device that is our there. Now, JavaCard is one type of smart card which has virtual machine, run time and libraries specified by SUN microsystems which we smart card manufacturers implement and put on top of our smart card operating system. There are other types of smart cards for eg. native smart cards which do not have capabilities to run managed code, there is a .NET Smart card which has a virtual machine, run time and libraries specified by ECMA [our implementation is a subset of ECMA specifications for .NET like JavaCard specifications are subset of core Java specifications], and there is one more type which is called Multos smart card.

That said, you could use .NET Smart card in products/implementations of Liberty Alliance. As a matter of fact all the demos that I have done with Liberty Alliance & InfoCard/WS-trust/WS-Federation are with .NET Smartcard. Reason for using .NET Smart card is because it supports richer set of APIs (Hashtable,ArrayList...), language features (strings,long..) and Xml parsing. These features are not availbale in exisiting JavaCards (2.2) and would be part of JavaCard 3.0.

Now, the way you put the matrix it seems that you are thinking of some relation between JavaCard & InfoCard. InfoCard does have a "card" as a suffix but it does not mean it is a smart card. InfoCard is a metadata expressed in XML which describes how a user could authenticate, where the identity provider/security token service is located and what are claims that are supported and JavaCard is a platform for which you could write applications that would store credentials and process requests to use them.

I remember sometime back I had read an article on Microsoft Employees Get Carded" by Karen 
EpperHoffman via Kapil's Blog. Well, Scott made us use these along from a long time ago...And
Microsoft's views on smartcards are no different. 

Smart card technology is a proven security technology and hope technologists around the world appreciate its importance for web security also.

Hubert has put together a nice demo of how a using Liberty’s ID-WSF protocols, we can create a 
module that greatly helps the user in dealing with his digital identities. Currently laptops,
sunray 1g, sunray 170 and desktops ARE available with builtin smartcard readers. 

and hence my dilema...

This is really an excellent demo, I am also working on a smiliar type of demo (Liberty Alliance) in which the authentication is done using a challenge-response algorithm (like CRAM-MD5) where the response is generated by Smart card instead of using username/passoword (as done in Hubert's demo). It is another thing that I will  use a theme other than the famous wine shop example as I am a teetotaler :) .

http://www.ovum.com/news/euronews.asp?id=3636

Key Points:

• Identity management has been the fastest growing security sector, and we are pleased to report good progress in getting acceptance of the Liberty Alliance and SAML 2 standards. 
• Identity management will become even more prominent, but in the enterprise space it will mostly be intra-enterprise, with inter-enterprise initiatives, which are still a couple of years away.
• Much faster development of identity and identification infrastructure in the government sector, both for law enforcement and for accessing public services.

A very interesting example from Kim Cameron on the use of InfoCards to send the credit-card number. To make it more interesting and validating the philosophy of InfoCard system being user centric and not PC centric and its extensibility I can give one more scenario regarding payment cards. As I wrote in entries here and here InfoCard sees the security device like Smartcard as a personal security token service (PSTS) which can issue security token in form of SAML assertions and so in the picture the identity provider (bank) can be replaced by the Smartcard (actually the bank issued you the Smartcard as its offline representative). Instead of downloading the one time credit card identity token from the user's bank, the InfoCard system request the Smartcard (PSTS) for SAML assertion (security token) which would contain the credit card number (can be one time valid or static), attributes of user such as name, billing address etc. Of course assertion would be digitally signed (XML signature) & encrypted (XML Encryption or SSL) and would be validated by bank once transaction is sent by the shopping site.

You can appreciate that fact that the sensitive data like credit card number, expiration etc is not on your PC but on Smartcard and you avoid a round trip to Identity provider. Smartcard as PSTS not only enable the transactions on PC but also can be used in Kiosk, ATM etc thanks to its mobility aspect. Automation (no need to type the details on web forms), good user experience and security are achieved in this model.

James McGovern recently asked "How should we think about SmartCards within our own infrastructure and how it plays with federated identity?". I have been talking about the demos we have done with Smartcard in Identity management space but never really talked about the essence of using Smartcards in this domain. I take this oppurtunity to try to explain how Smartcard plays a vital role in federated identity.

Identity federation although new to Internet (www) and world of web services, is not a new concept for the Smartcards. Smartcards are the actually the real enabler of biggest network of identity federations world has known till date i.e GSM. It is this small computer which enables the roaming in the GSM network and let us make use of our mobile phones at places where our operators do not have presence. GSM was devised with the core objective of business harmonization - "you can use my network even though your are a subscriber of another network in another country" which required technical harmonization. Problem is that network 1 does not have an account for you and cannot bill you but they can get your and your operator's (network 2) identity from the phone and ask your operator if they will pay the charges. Of course the operator would want a strong proof of if you are you and not somebody who has stolen your account number. Need is to have a strong authentication for eg using shared key cryptographic where there are exactly 2 copies of secret key - one residing in mobile phone and other at operator's end. The figure below illustrate how a basic GSM authentication is done (it is actually more complicated but for simplicity I am giving this example) :

Basically the user's network sends a random number and result after its encryption with shared key to the visiting network and says that if user's phone gives the same encryption result for the random number I will pay the bill. As you can see there is not only a requirement of strong authenitcation but secure storage of shared key (not even accessible to user) and what better technology to use than Smartcard which has the secure, tamper resistant hardware and secure computing capabilities. Computing capabilities are equally important as it is of no use storing the key in Smartcard and giving it to phone for performing cryptographic operation.

Now federated identity for intrenet and intratnet are no different conceptually than the case that I presented. Only the protocols (SAML, WS-Trust etc) used by service providers and identity providers on www are different for obvious reasons. In today's internet the identity of user is of prime interest both to user and to the service provider and hence the need of Strong authentication.

Fortunately various standards like SAML, Liberty, InfoCard/WS-Trust, WS-Federation etc for identity federation respect and understand the usefulness of security devices like Smartcards. All these standards propose the solution to same set of problems in _almost_ same way and differ mostly in wire protocols used. SAML and Liberty has a profiles ECP (Enhanced client proxy) and LECP (Liberty enabled client or proxy) respectively which enables a Smartcard based authentication where as InfoCard (a profile of WS-Trust) treats Smartcard as another Security token service which can generate self issued security tokens.

Other than Strong authentication, secure storage of attributes/credentials and computing capability, mobile nature of Smartcards is an added advantage for user.

Thanks to Kim's explanation finally I have a clear understanding of how the InfoCard selection mechanism (GUI) will work.

In my blog here I was saying that what is displayed in wireframe GUI that comes with Indigo BETA SDK is an attribute card and not Infocard. My understanding was wrong. He corrects me here

“Well, the question is, does the user have to know about the metadata connecting the InfoCard to the Identity Provider?  I don't think so.  Therefore we "dereference" the metadata and show the underlying identity information.  Developers might find this confusing at first, but what do developers like better than a level of indirection????

Here's our thinking.  The InfoCards contain "metadata" just as Kapil says.  But when a user looks at an InfoCard, we don't show her the metadata (which would be meaningless to her).  Instead, we use the metadata to procure a token, and show the information the identity provider is capable of releasing (in other words the set of claims that go along with that identity). “

So, what is displayed is a portion of InfoCard i.e set of claims supported by STS (whose representive this InfoCard is).

But in wirefram GUI I am able to see the attributes (data) which I can also edit, it goes against the notion that InfoCard is just a metadata.

Trevor Lawrence throws a light on this as a comment in Kim's blog.

“It looks at the moment as if the InfoCard UI has a special case built in to allow you to edit your claims in the self-asserted IP that is included. In general, as I understand it, out-of-band mechanisms are likely to be needed to change the claim data that an external IP asserts for a user. (In an authoritive IP I can't just change my passport number without by some other means proving to this IP that that indeed is the number of a new passport issued to me.) “

Now this makes everything clear. What is displayed are supported claims in InfoCard (minus the geekey part) and if these claims reside on user's machine (PC as a local identity provider) then you can edit and see the claims else you need an out of band mechanism to do that. Mostly knowing that these are claims [not data] (displayed in wireframe GUI) which will be transmitted by my IDP to relying party should be enough.

Many thanks to Kim and Trevor for insight.

Kim answers my question on confusion regarding Identity metasystem architecture here.

My question was how Liberty based systems which use different protocol (other than WS-Trust) to exchange security tokens would be suppoed in Identity metasystem (mostly to take advantage of InfoCard system Microsoft has put in place).

Kim points out the problem is not only for Liberty enabled providers but for existing islands of identity systems if they want to use the metasystem.

“The truth is, to get to a metasystem, it wouldn't only be Liberty or SAML implementors who would have add the token exchange capability -changes would be required in all the systems asserting corporate and government identities;  in operating systems, mobile devices, online services, smartcards; and in every other technology mentioned in our whitepaper.  No one, including Microsoft, has WS-Trust rolled out at this point in time, so everyone would have to take the plunge.”

This is exactly true.

As a solution to this he proposes

“I was really trying to point out that everything SAML users and vendors already had in place could continue to work just as it does now, while with a small incremental effort their systems could embrace the metasystem.  Sure, it would mean supporting WS-Trust - a protocol designed for metasystem purposes:  exchanging one security token for another different security token.  But the people who've built SAML systems will have little difficulty going this extra step. “

So basically the problem can be approached in 2 ways.

•  Liberty or SAML systems move to WS-Trust protocol completely (which I do not think they will do) or
•  Liberty or SAML systems add translators (protocol translators WS-Trust to SAML Request and vice versa) at the server side.

There is a nice blog from Andy Harjanto on InfoCard System so do not want to explan here the basic concepts. He has done a great job describing with some sample code all the elements of InfoCard system.

I was recently playing with the Avalon and Indigo BETA SDK to see the InfoCard systems in action. There is something which may be confusing (seems like today I am going to talk only about confusions :) ) to some people. With Indigo comes a Windows service called Microsoft Digital Identity service (InfoCard system) which displays a GUI where you could create sets of attributes. These sets are called “Cards”. Lot of people will take this to be “InfoCards”.

An InfoCard is just a metadata which says what is the authentication mechanism to be used at STS .. what are supported claims at STS etc. It does not contain the data or attributes about user. 

Microsoft InfoCard 1.0 Beta 1 GUI displays digital identities of user and not the Info cards. Wish there is a better word MSFT can use for these set of attributes instead of “Cards” to avoid possible confusion.

Now this also raises a question, the GUI from Digital Identities service is for selecting a set of attributes not info cards (if my understanding is correct) so will there be a selection mechanism for InfoCards also ?.... A use case can be imagined in which I have 2 InfoCards (for eg 2 authentication mechanisms) for the same relying party then client on my PC should know of a way to select the correct InfoCard.

From Identity metasystem whitepaper at MSDN

“Participants in the identity metasystem can include anyone or anything that uses, participates in, or relies upon identities in any way, including, but not limited to existing identity systems, corporate identities, government identities, Liberty federations, operating systems, mobile devices, online services, and smartcards. Again, the possibilities are only limited by innovators' imaginations.”

Identity Metasystem Architectural Diagram

Going by this diagram which is based on WS-Trust as a request/response protocol for security tokens I do not understand how this architecture of Identity metasystem connects different participants as mentioned in statement above.

If I have a Liberty ID-FF or SAML 2.0 enabled IDP which use SAMLRequest and SAMLResponse for security tokens this architecture does not help.

My understanding is that this identity meta system is for service providers, identity providers and client machines (infocard system) which are based on WS-Trust and so saying that other participants such as Liberty could participate in this meta system may not be correct.

If some one could clarify ?

Blogging after a long time ... have been busy working on new versions of .NET Smart card.

In May I participated in Liberty conformance event in New Jersey and successfully interoperated our Smart card solution which consists of ID-FF 1.2 LECP profile and ID-WSF 1.1 LUAD-WSC with other vendors and got the certification.

Here is a link to the press release.

http://www.projectliberty.org/press/details.php?item_id=115

From the release:

At the test event hosted by the IEEE Industry Standards and Technology Organization (IEEE-ISTO) and held in Piscataway, New Jersey, during the week of May 9-13, 2005, the following products and services demonstrated conformance with the Liberty Alliance Identity Federation Framework version 1.1 and 1.2 (ID-FF1.1 and ID-FF1.2), and the Liberty Alliance Web Services Framework version 1.0 and 1.1 (ID-WSF 1.0 and ID-WSF 1.1):

Axalto –Axalto’s robust iClient 1.0 technology package is a set of client components and a programmable smart card that supports the Liberty ID-FF 1.2 Liberty Enabled Client Profile (LECP) and Liberty ID-WSF 1.1 Liberty User Agent or Device (LUAD) WSC profiles. By supporting the LECP profile and acting as a LUAD-WSC, the Axalto iClient allows support for secure and mobile usage of user credentials using smart cards.

I have been waiting and knew this would happen and is definitely a good thing to happen. I have been working with the both specifications and in spirituality they are the same and differ mostly at schema level, after all there can not be many ways to solve the same problem.

Kudos to SUN and MSFT to come together and have industry march towards better inter-operable solutions.

Following are the links where the initial drafts of the specifications can be found

http://msdn.microsoft.com/library/en-us/dnglobspec/html/websso.pdf

An interoperability profile for Liberty ID-FF1.2 and WS-Federation Passive: this document is a profile of WSSOMEX that allows using either Liberty's ID-FF 1.2 (browser POST profile) or WS-Federation Passive Requestor Interoperability Profile to interact with a service.

http://msdn.microsoft.com/library/en-us/dnglobspec/html/websso-mex.pdf

A web single sign-on metadata exchange protocol (WSSOMEX) that defines a mechanism whereby a Service Provider can determine the protocol suites supported by a client's Identity Provider and use a commonly supported protocol suite to perform SSO-based operations. Simply put, this protocol lets a Service Provider ask "what protocol suites do you speak?" to an Identity Provider.

Except for Ping identity package for .NET (where they used the xsd generated classes) for Liberty & SAML specifications I do not see single .NET implementation of either specifications. I am surprised why ASP.NET community and companies who use ASP/ASP.NET are not concerened about these standards or may be they are waiting for Microsoft to provide WS-Federation support.

I am in the process of writting SAML 2.0 implementation in C# and will open source it once I have a working version. I am using WSE 2.0 frameworks for the implementation.

SAML is a :

• XML Framework for defining tokens / assertions
• Protocol Binding framework
• Solution for SSO

With these questions in mind I started wondering if SAML provides everything then what does Liberty do. I asked this question in OASIS SSTC newsgroup and got some good explanation which I am posting here also.

Below is the answer from Conor P. Cahill from AOL who actively participates/contributes in SAML group.

---------

SAML1.1 does provide a framework upon which you can build a fully operational, privacy aware SSO environment.  This is, in fact, what Liberty did.  Liberty added functionality in the areas of:

• Identity Federation Protocols (how 2 parties agree on an identity handle for the user)
  
• Single Logout Protocols
• Privacy protection
• Authentication Context
• Metadata distribution
• Authentication request extensions
  
• IDP location (Common domain cookie)
• Enabled Client/Proxy
  
• Identity Affiliations
  

Liberty subsequently contributed their work back into the SSTC and the SSTC has incorporated it into the SAML 2.0 work that is currently in progress.   People who understand or have implemented Liberty ID-FF, will feel right at home with SAML 2.0.

-----------

Complete discussion can be found here.