Can’t stop myself..

I’m on a one post per day ratio on a blog these days.. I’m quite surprised myself to be honest I’ve found out that writing (on a blog) actually is a good way of organising your thoughts; new ideas keep on coming now. So let’s go on..

I’ve blogged a couple of times on two-factor authentication and managing identities locally (on a device). I will call this client side Identity Management (c-IdM). The obvious counterpart of this would be server side IdM (s-IdM?). Now, s-IdM is an area where a lot discussion takes place, especially via the blogosphere. Server side IdM is about managing and simplifying communication of your identity in the network, via a set of protocols (SAML2.0, OpenID, WS-Federation etc.) and entities called Identity Providers.

For me it’s interesting how these two ’sides’ of IdM interact with each other:

As we strive to reduce sign on/authentication events by aggregating them via IdPs, strong authentication becomes much more important; impersonating the user at the IdP can grant access to multiple services! So, the more you federate your identity, the more you require strong authentication.

The multi-factor approach of the Identity OS (c-IdM!) is therefore fundamental for the success of federation and reduced sign on (s-IdM).

Challenges of two factor authentication

The wikipedia link for two factor authentication lists some of the challenges involved to make it successful.  I’ll give some comments on how the Identity OS will solve this:

• Product proliferation. By standardizing an Identity OS and its interface it will become possible to deploy all the different two factor auth solutions on one platform and one interface. The Advanced Client standard seems a safe bet to me. Also think of a Cardspace-like GUI to select your credentials.
• User password management. A solution to the password problem would be to have one password to authenticate to the Identity OS. Users will most likely choose the same PINs/passwords for their different credentials anyway (or am I the only one who chooses the same PIN for my different SIMs?). This would still be two factor authentication as the credential on the Identity OS platform is something you have and the password to access it is something you know.
• Interoperability of authentication mechanisms. Mentioned before. Liberty Alliance’s Advanced Client specs could be the starting point.
• Cost effectiveness. A hardware token deployment is of course much more challenging and expensive than a simple software deployment; downloading a credential to the Identity OS is cost free!
• Password and software security. The security of the credentials and the software is dependent of the deployment of the Identity OS. As I mentioned in my previous approach, Cardspace and ICP are examples of an Identity OS with different levels of security; OS layer and device layer. The hardware approach sounds like the safest option, but care should be taken that applications making use of the credentials in the Identity OS should never release the credentials. The deployment of the credentials into the Identity OS is also of importance. Provisioning protocols have to support confidential supplier-to-Identity OS communication.

Based on these arguments a well implemented Identity OS should be able to remove the current challenges in two-factor authentication. Feel free to disagree with me on some of my points though!

Searching for the second factor (The Identity OS)

That should be a catchy title for this post!

I have been thinking lately about multi-factor authentication. Two factor authentication (a requirement for many critical systems) is frequently described as ’something you know’ and ’something you have’. On the Internet most applications apply single factor authentication in the form of username/password.

There are some examples of two factor authentication out there though. Banks have issues their customers with hardware tokens, while network operators use SIMs to access the network (in the SIM case the physical SIM is ’something you have’ while the PIN serves as ’something you know’).

All those second factors have one thing in common: it’s hardware dedicated to a limited set of applications on a ‘closed’ and proprietary platform. Wouldn’t it be great to have a single reusable platform for second factors?

This is where Microsoft Cardspace and Intel’s Identity Capable Platform come into the picture. I think both can be considered platforms for second factors, and both have different approaches. A second factor has to be ’something you have’, which can be interpreted as ’something that can’t be copied or stolen to some other place’. It basically implies that our customizable second factor platform is an environment where we can insert and remove credentials (the second factors), in a secure way.

• Cardspace qualifies as such an environment as it is able to add ‘Information Cards’ (second factor) and store/execute these securely. Cardspace also allows local user authentication through username/password (first factor) and in the future biometrics (third factor!). Microsoft were in an (obviously) unique position to do this the right way because they own the OS. A ‘normal’ application would be vulnerable to a large range of virus and malware threats, where an OS native application has more protections in place. Still, Cardspace is as secure as the operating system it is built in and time will tell if this is good enough to provide a second factor. It will definitely take some time to convince critical applications like online banking that Cardspace is trustworthy for multi-factor authentication.
• Intel’s ICP (and also ARM Trustzone) are hardware environments with a limited operating system that allow the inserting, executing and removing of credentials. These hardware platforms are able to do the same things as Cardspace but are implemented in silicon (therefore potentially more secure than Cardspace). These technologies rely on the security of hardware with a limited software functionality instead of the more general purpose operating system that is Windows.

In both cases the security of the whole credential life-cycle (protocols!) determines the level of trust people will have in the second factors provided by their platforms. Microsoft allows users to manually import their Information Card into the Cardspace Client, while the ICP is based on Liberty Alliance Advanced Client protocols.

This has lead me to believe that there should actually be an Identity OS, which is a set of functions that is just able to provide the right amount of identity related services (more on this in later posts). By keeping the functionality small, the risk of a vulnerability will be mitigated. This Identity OS could then be implemented either in silicon, on a USB dongle, an SD card or in the OS.

The Identity OS could solve interoperability issues with two-factor authentication and provide a uniform and extensible (mooooore factors) platform for identity management. Let me know what you think..