Burton Group Identity Blog

The MIFARE Classic Card is Hacked

Blogger: Mark Diodati

Some of you may have read that the proprietary symmetric key cryptographic algorithm of the MIFARE Classic card has been broken. The MIFARE Classic card is used in physical access control systems (PACS) and contactless payment systems (including tollway and public transportation systems).  By some estimates, there are 500 million MIFARE cards deployed worldwide, and the majority of them are MIFARE Classic cards.  Karsten Nohl and his team completed the hack, and the team was able to clone a MIFARE Classic card in less than two minutes (the “skimming” or reading of the card takes less than a few seconds).  Perhaps not co-incidentally, NXP (the owners of the MIFARE intellectual property) announced on March 10 that they have a new-and-improved MIFARE card that leverages AES 128-bit encryption.  The first samples will be available in Q4 of 2008.  The refreshment of hundreds of millions of cards will be completed at a much later date.

You may be aware of the MIFARE vs. HID Prox card religious war in the PACS space.  From my experience talking with customers, there are more HID Prox cards used in PACS in the United States as compared to the MIFARE card.  The MIFARE proponents consistently tout the security value of MIFARE technology over HID Prox technology, and have pointed to the fact that HID Prox cards could be readily cloned.  You can see a video of the HID Prox card clone, from the 2007 RSA Conference here.  The conventional wisdom was that the MIFARE card was unclonable.  The conventional wisdom was wrong.

The impact of the MIFARE hack for those reliant payment systems (and its consumers) is increased fraud.  The cloning of the card does not require possession, only proximity.  I am unaware of any preventative measures that would preclude a fraudster from walking around a parking garage and cloning those tollway cards that are mounted in everyone’s windshield.  Some people might consider this an act of civil disobedience, particularly if they drive on the Illinois Tollway with any frequency (as Triumph the Insult Comic Dog would say “I keed!”).  Also, skimming and cloning the user’s public transportation card while they ride the train is a likely outcome.  If you are aware of any preventative measures, please let me know.

What is the impact to PACS security?  The reality is that many PACS deployments did not leverage the MIFARE encryption features.  The management of symmetric keys across the relatively complex PACS environment (specifically, cards, readers, controllers, and hosts) remains a daunting process.  For these deployments without encryption, it’s business as usual.  Those organizations that deployed the MIFARE technology with encryption should realize that they are not as secure as they thought.  Either way, as we have said before, no authentication method is bulletproof.  Organizations should be using other controls – like auditing and security event correlation – to enhance the security of their PACS. 

Finally, when will people learn their lesson?  Cryptographic algorithms should be public so that they can be scrutinized and tested.  Secret algorithms aren’t more valuable because they are secret.  Bruce Schneier has been saying this for years.

If you are interested more details on PACS architecture and components, I recommend my recent Burton Group research document “Let’s Get Logical: The Convergence of Physical Access Control and Identity Systems” (subscription required).

Why Enterprise Single Sign-On (E-SSO) is More Than Just a Tactical Add-on

Blogger: Phil Schacter

Today’s announcement of IBM’s acquisition of Encentuate, primarily positioned as a supplier of enterprise SSO technology, is a significant milestone in the maturing of the market for E-SSO. Two years ago E-SSO was viewed as a standalone product that was somewhat complementary to the deployment of stronger authentication and a convenient way to support legacy applications with internal logic that prompted for login credentials, typically a user id and a simple password.

Most identity and access management vendors were content to license or resell technology obtained from smaller specialist firms. IBM, Oracle and Sun partnered with Passlogix, while Novell works with ActivIdentity and Quest with Evidian. CA has its own E-SSO offering stemming from an earlier acquisition of Platinum/Memco.

However, the identity and access management vendors discovered that E-SSO was both a market accelerator and offered some important features of interest to customers with regulatory compliance requirements. E-SSO has a shorter sales cycle (typically six months or less) and is able to deploy more rapidly (one to three months depending on the complexity of the environment). Cost for E-SSO varies but many deals are less than $100K, which is easier on the IT budget than most user provisioning software and service projects. Customers could start with E-SSO and then over time add user provisioning, web SSO, federated SSO, and other components of the identity management suites. E-SSO technology also can provide an audit trail of user sessions and any interactions with applications accessed through the E-SSO system.

So who wins in the IBM deal to acquire Encentuate? First, it’s a big win for Encentuate’s 80 plus customers that can look forward to continued support and a more aggressive product roadmap funded by a premier vendor. Although no financial numbers were shared the deal provides an exit strategy for investors that poured about $24M into Encentuate over the years. The 160 plus customers of IBM’s TAM ESSO v6 will have support from IBM for three years from v6’s general availability date of February 2007. They also will have to choose between continuing to use ESSO v6, and transitioning to become a direct Passlogix customer, or migrating to IBM’s new v7 offering, based on the technology acquired from Encentuate. TAM ESSO v7 is expected to be available in Q3 2008 and will include planned enhancements to Encentuate’s product plus address IBM’s integration requirements.

IBM also plans to build on the engineering talent obtained as a part of this acquisition to build out a Security Software Lab in Singapore for more than just the E-SSO and former Encentuate product lines. This area offers high quality engineering talent and a more efficient operational infrastructure and cost than labs based in some other regions. Another key reason for IBM’s shift to a new technology provider is that Encentuate builds on a J2EE foundation, as do most other Tivoli product offerings.

Another interesting question is what is the impact of the IBM deal on their former partner, Passlogix? Clearly IBM will try hard to convince existing customers that they should migrate to TAM ESSO v7, but any migration is hard and it’s not clear who will fund the professional service cost of doing so. Passlogix expects to derive significant ongoing maintenance revenue from a portion of IBM’s 160 customers, and that this revenue stream will more than offset any lost OEM royalties. There is also the question of what happens to the healthy pipeline for ESSO v6 and whether Passlogix can convert any of these prospects into direct customers. Overall Passlogix is prospering in a strong market for E-SSO and related offerings, and indicates that no one source contributes more than a sixth of overall business revenue.

One final observation about the impact of this deal is that it’s likely to start one final wave of consolidation, with Oracle and Sun considering the business risk of the other acquiring Passlogix first. Another acquisition that should probably happen is for Novell to buy ActivIdentity. Novell already provides the channel for 80% of ActivIdentity’s business, so why not bring this important function inhouse?   

Sxip-Ping to a new beat

Bloggers: Gerry Gebel and Bob Blakley

Today, Ping Identity announced it is acquiring Sxip Access, the portion of Sxip Identity that provided identity management for software-as-a-service applications. Sxip Identity will still exist and focus its energies on Sxipper and other Identity 2.0/Web 2.0 technologies.

This appears to be a good strategy for both parties. Sxip is free to focus solely on the realm of user centric identity technology and approaches. Ping is able to immediately add support for SaaS applications to its federation portfolio, bolstering is ability to address the growing needs of organizations with distributed applications and a dispersed workforce.

Of course, adoption of SaaS applications is on a strong growth trend across the industry so there are many vendors seeking to enter this market and provide potential solutions. For example, TriCipher just announced their myOneLogin hosted authentication service that supports SAML and a number of other authentication mechanisms, Conformity is developing security, audit, and identity solutions for SaaS applications, and Symplified is working on identity on demand offerings for SaaS (Symplified and Conformity offerings are at the beta testing stage). It turns out, of course, that federation protocols don’t address some single sign-on scenarios if your workforce doesn’t adhere to the preferred confines of the SAML protocol. While technically feasible, it is can be difficult, in reality, to accommodate workforce members authenticating from on premises, from partner locations, or while traveling.

It appears also, that SaaS vendors have gotten more serious about authentication security as a result of recent published attacks against SalesForce.com. In summary, the acquisition, recent product offerings, and multiple startups suggest a segmentation for SaaS applications. First, there is a server side SaaS federation market and second, a client side consumer authentication as a service market. Both segments are good developments and necessary for the industry. Indeed, both segments are likely to grow over time.

So many identity conferences, so little time

Blogger: Gerry Gebel

If you use conferences as a guide, then identity management is hotter than ever. It seems a month doesn’t go by without at least one event that is identity related and March 2008 is no exception. In fact, I’m participating in two conferences this week in Europe – where the list of interesting identity-related events continues to grow. On Monday, I’ll be at the Net ID 2008 conference in Basel, Switzerland talking about SharePoint access and identity management. I’ll also be on a panel discussing interoperability – a favorite topic of mine, so this should be fun.

Later in the week, I’ll be presenting at the ic Consult conference at BMW World in Munich. My presentation is titled “IdM Markkt, Schwerpunkt SSO” (IdM Market, Focus on SSO) in the program, but rest assured I will be doing this in English and not torturing the audience with my meager German language skills!  The guys at ic Consult always put on a great program – I’ve had the great fortune to participate in their fall event that happens to coincide with Oktoberfest… In any language, it’s remarkable that, as an industry, we haven’t done more to ease the authentication burden for end users. Certainly, there are enough technologies to choose from: passwords, smart cards, PKI, federation, E-SSO, Kerberos, SPNEGO, GSS-API, and the list goes on. But the problem, if anything, is getting worse.

In addition to talking about SSO in Munich, we’ll be focusing quite a bit of attention to authentication at Catalyst this June. My colleague, Mark Diodati, is leading the charge on that topic and you’ll hear more from him about it between now and the conference.

Novell rounds out the March conference schedule with their BrainShare event in Salt Lake City. While not exclusively focused on identity, Novell includes a heavy dose of it on the agenda. And one of the better features is that this conference is local to the Burton Group headquarters. Hope to see you on the road, or on home territory this month. 

The Latticework of Identity Services

You may have seen/heard/read that the Burton Group is working with customers to define an interoperable services model for identity. It’s a topic on the tip of many of our customers’ tongues.  To date, we have interviewed some customers to begin the process of defining identity services, gathering their respective requirements, and thinking of potential roadmaps towards productization of these services.  In Q2 and at Catalyst, you can expect to see additional developments in this area.

Multiplicity of Services – One Is Not Enough
One truth that became clear in our interviews is that organizations require multiple identity services.  They include (in prioritized order) authorization, authentication/credentialing, provisioning, and attribute (which is potentially rolled into the authorization service). While authorization is by far the most desired identity service (and thus far, the most implemented—albeit as custom code), those customers who have built and implemented an authorization service say that other services (notably, an authentication/credentialing service) are required to support it.  It’s also evident that identity services are not just required for users; they are required for endpoints (for example, policy decision points and policy enforcement points).  Like users, these endpoints require authentication and authorization.

While at a high level the list of services is self-evident, several need further description.  The authentication/credentialing service is responsible for validating the multiplicity of user credentials that are presented when accessing services.  The credentialing service also must be able to transition credentials to other mediums – otherwise known as a security token service (STS).  For example, the credentialing service may transition the user’s SAML credentials to a “local” credential for the authorization service.  Additionally, some customers are looking for session or global logout capabilities from this service.  The attribute service is more of a DSML-type service to assist applications in personalizing user sessions.  The attribute service may be tightly coupled with the authorization service, or may be a standalone service that is called by the authorization service.

From discussion with our customers and other folks in the industry, it appears that a provisioning service is not a priority, even in federation use cases.  Within the enterprise, organizations are “getting by” with provisioning and directory tools.  For federation scenarios, organizations are using all kinds of tools (including Microsoft Excel spreadsheets) – everything except a federated provisioning service.  We hope that the promise of endpoint interoperability and transactional capabilities will drive the need for provisioning services – it’s still pretty early in SPML v2 standard (for example, some schema issues remain unaddressed).

Realistic Expectations
Those customers who have built and implemented custom identity services (again, usually authorization) realize that the service can serve only a subset of applications.  One example is the existence of an authorization service for web applications with finer-grained authorization requirements, but not for mainframe applications.  Additionally, a WAM system may be utilized for coarser-grained web applications.  This environment requires an authentication/credentialing service to transition WAM and federation credentials for the authorization service

The Standard Is Not the Service
What is the role of the various identity-based standards (for example, SPML, XACML, WS-Trust, and SAML) in identity services?  The standard (while crucial) does not equal the service, because the standard generally does not provide the necessary authentication, authorization, confidentiality, and integrity features – and it’s not the right level of abstraction.  By the way, the answer is not to build these security features into the identity-based standard because these features exist within other standards (including WSS).  Also, adding these features to the already complicated standards would make them too burdensome to implement.

For example, there are no built-in authorization capabilities within SPML.  When building SPML-based services, organizations must ensure that only authorized requestors are allowed to create users at the provisioning service point. Very course-grained authorization can be achieved via a CA certificate trust list.  This approach won’t scale for an environment with many requestors and provisioning service points. We discuss this issue within our (publicly available, registration required) SPML research document.

XACML faces similar hurdles.  The standard does not provide the necessary authentication/credentialing services required for PDP-PEP interaction.  The OASIS XACML TC recognizes this fact, and has proposed a profile for using WSS with XACML.

In general, most identity services today travel the path of least resistance– over SSL (which provides confidentiality and integrity, but may not address the identity service’s authentication requirements).  We know why this is the case - the process for securing SOAP is too hard for most people.  However, SOAP remains a preferred binding for identity services, so the issue of securing SOAP messages isn’t going away any time soon.

Our Plans
We’ll continue to interact with our customers via a Burton Group identity service “working group”.  As the working group gets seasoned and refined requirements emerge from it, we’ll pull in “trusted” vendors that have been considering identity services to compare customer requirements and product roadmaps.  Identity services will be a substantial topic on our Catalyst Conference Day 2 agenda in late June. Who knows what will happen after that?

[posted by Mark Diodati]