The malware leverages a phishing attack and an Adobe Reader vulnerability for installation on the user’s workstation. If this sounds familiar to you, it is because this technique was used as part of the attack on RSA SecurID system in 2011. The malware includes a keylogger to capture the smart card PIN, which enables it to open the card. The Sykipot attack does not compromise the user’s smart card and it does not steal the credentials stored on smart card. Rather, it sends data down to the card for cryptographic processing for as long as the smart card is in the reader.

The Sykipot attack should not be surprising. I discussed this attack vector as far back as 2006 with my research document Consumer Authentication and the FFIEC Guidance and my technical position on User Authentication (subscription required). I also discuss the attack vector in my 2007 blog Nothing is Bulletproof. Our clients have seen similar attacks in the wild for at least three years.

There are several important lessons that we can derive from the Sykipot attack. First, no authentication method is bulletproof. Smart card authentication is widely held as the gold standard for commercial user authentication. That’s a perspective I share, by the way. But even smart cards can be compromised, regardless of their resistance to hardware tampering. The layering of additional techniques—including anti-malware software, user activity analysis, and network forensics—is required. Second, like the RSA SecurID attack, the Sykipot attack is another example of an advanced persistent threat. U.S. military secrets are under attack like no other time in history; willful and proactive actions are required to protect them.

The pilot has fueled an already intense industry interest regarding the use of NFC and smartphones. NFC-enabled smartphones are entering into the market, with Samsung, Blackberry, HTC (and others) introducing new models this year. The industry interest in NFC today is primarily focused on “tap to pay” at retail point-of-sale environments. I’ll be speaking more about Google Wallet and ISIS (competing payment systems) in a future blog post. The next logical application of NFC after payments will be authentication, including to physical access control systems (PACS).

Per review of available information, the pilot has some interesting technical details.

• First, the students were issued fully-personalized smartphones for the pilot. The phones already possessed the HID iClass credential stored in the NFC secure element (the smart card embedded in the NFC chipset).
• The smartphones (primarily Blackberry, but also iPhone) did not have native NFC capabilities. Instead ASU leveraged NFC chipsets from Device Fidelity. The Blackberry used the microSD card with an embedded NFC chipset (including antenna). The antenna from the chipset was extended to the exterior of the phone to better facilitate access to the PACS door reader. In the case of the iPhone—which does not have a microSD port—the pilot used an innovative phone case with embedded NFC capability.
• The users activated an app on the phone prior approaching the door. The application enabled the use of the iClass credential for 30 seconds. The students initially ran into some application usability problems because of the timeout period.
• The pilot did not require any modification the Lenel PACS because the smartphones emulated HID iClass cards.

The pilot is an important first step towards using NFC-enabled mobile devices for PACS access, but don’t expect this capability at work anytime soon. NFC smartphones are a rare breed. Gartner estimates that 50% of smartphones will have NFC capability by 2015, which improves the viability of opening doors with phones. Second, management needs to catch up with raw technology: consider the integration, scalable provisioning of credentials to employee-owned phones and binding those credentials to identity repositories in the enterprise.

I am expecting that the percentage of NFC-enabled phones will increase to a tipping point where their usage for broad scale authentication becomes viable. The mobile device management vendors will pick up the ability to manage and provision enterprise credentials to the secure element in a way that does not compromise the user’s payment credentials. Finally, those enterprise credentials will be both proprietary and standards-based, including HID iClass, X.509 certificate, OAuth, SecurID OTP, and OATH-based OTP. The credentials will enable access to both physical and logical systems.

I discuss NFC smartphones my “Mobility and Authentication” document, which will be published in the coming weeks. Two other documents—Let’s Get Logical: The Convergence of Physical Access Control and Identity Systems and Road Map: Replacing Passwords with Smart Card Authentication (subscription required)—discuss PACS systems and contactless authentication.

In the document (Market Profile: Identity Management as a Service (IDaaS) [subscription required]), I discuss over 20 vendors and classify their product capabilities (that is, federation IDP, directory sync, provisioning, strong authentication as a service, federation SP, web access management, identity and access governance, XACML authorization, consumer authentication, and password vault). I also discuss recent IDaaS acquisitions, including Arcot, idOnDemand, Nordic Edge, and TriCipher.

In addition to discussing the market, the document examines three use cases that intersect identity management and cloud computing:

• To the Cloud.Organizations that want to extend their existing identity management processes to manage users in SaaS or partner applications. This use case is the most prevalent and aligns with larger established companies that have significant on-premises IT infrastructure.
• In the Cloud.Smaller organizations whose core IT functions are delivered via SaaS applications. These organizations are searching for off-premises, turnkey identity management solutions for users and applications in the cloud. Alternatively, larger organizations with distinct user constituencies might leverage an “in the cloud solution” for a specific user population.
• From the Cloud.This is perhaps the most forward-looking use case. Some organizations want to leverage off-premises IDaaS for on-premises identities and applications. Many organizations aren’t comfortable yet with storing user information in an IDaaS application. Therefore, many of the “from the cloud” vendors offer a hybrid solution that stores user information on-premises.

Speaking of “hybrid”, the document discusses an important emerging IDaaS concept: the identity bridge. As organizations straddle on-premises and off-premises identity management, a single, bi-directional, on-premises component becomes essential. Preferably, this component should be delivered as a virtual appliance. Today, most on-premises IDaaS helper gateways are single-function and unidirectional; they work well for simpler use cases. They won’t be up for the task as the organizations add more identity management functions and distribute those functions more evenly between the on-premises environment and the cloud.

Identity Bridge

• Vintela (Active Directory Bridge – 2005)
• Völcker Informatik AG (provisioning/access governance – late 2010)
• e-DMZ Security—privileged account management – early 2011)

Today, Quest announced the acquisition of Symlabs, a vendor with virtual directory and federation products.

In its early days, virtual directories dramatically decreased the deployment time associated with web access management (WAM) systems. Customers were able to present a single data view to the WAM system without a multi-year meta-directory project on the critical path. Over time, virtual directories became more valuable, particularly for federation identity provider (IdP) deployments.

The latest trend in enhanced directory services is the synchronization (sync) server, which will happily replicate user accounts from the enterprise directory store to SaaS applications. Account replication (and yes, federation) is an essential component for extending existing enterprise identity management to Cloud-based applications. The synchronization server is built into federation systems from CA (previously Arcot), Ping Identity, and VMware (formerly TriCipher). Unbound ID has a standalone sync server, and Radiant Logic has integrated the capability into its virtual directory products.

The purchase of the virtual directory and federation products is a good one and will serve Quest customers well. The federation product functions well for the “to” the Cloud scenario described above. In order to be competitive and support the same important scenario, the Virtual Directory must pick up sync server capabilities ASAP. The two products will then work in harmony to provision users and sign them into SaaS applications.

I’ll be talking about identity and Cloud applications at this year’s Catalyst Conference in late July.

Helpful Links

• Virtual Directories: Valuable Present, Promising Future (subscription required)
• Privileged Account Management: Addressing the Seedy Underbelly of Identity (subscription required).
• Markets Colliding: UNIX Security, Active Directory Bridge, and Privileged Account Management (subscription required) 

RSA SecurID customers should demand replacement tokens, and the delivered tokens must be manufactured after implementation of RSA’s post-attack security procedures. Until RSA customers receive the replacement tokens and endure the subsequent pain and suffering of distributing them, customers should follow RSA’s instructions that were received after the initial attack.

While we are talking about the protection of SecurID token information, the attack vector that organizations dismiss at their peril is the on-premises secure storage of the token information. I have seen many seed record CDs (OK, floppies back in the day) on the desks of system administrators or sitting on top of the SecurID server. Also, the token information can be retrieved out of the server by the knowledgeable SecurID system administrator.

The reputation of the RSA SecurID OTP technology may be badly tarnished due to this attack. However, the real damage is limited to the token information that was stolen. In other words, tokens created by RSA after the attack should not be vulnerable, assuming that RSA’s new precautions are effective. By the way, did you notice that most of RSA’s competitors were publically quiet after the March attack? You can bet that that they were shoring up their OTP security. We’ll be talking about stronger authentication at the Catalyst Conference.

Gartner Links

• Perspectives on OTP Authentication and Migration (blog)
• SecurID Redux (blog)
• Just What Happened to SecurID? (blog)
• Road Map: Replacing Passwords with OTP Authentication (research document – subscription required)

Other Links

• Analysis: Lockheed hack highlights cyber-blame snags (Reuters)
• InsecureID: No more secrets? (Bob Cringely’s blog)
• Data Breach at Security Firm Linked to Attack on Lockheed (New York Times)
• Second Defense Contractor L-3 ‘Actively Targeted’ With RSA SecurID Hacks (Wired)

Several weeks ago, a specification for provisioning was released—Simple Cloud Identity Management (SCIM). It is an important step forward in the important goal of standards-based provisioning. Representatives from Google, salesforce.com, Ping Identity, VMware, UnboundID, Okta, Sailpoint, and other organizations are working on the initiative.

SCIM comes with four important benefits. SCIM is simple; it leverages REST and JSON, not SOAP and XML. SCIM focuses on essential CRUD (create, read, update, and delete) operations. It avoids the complexity of the LDAP object class inheritance model. Second, it doesn’t place an undue burden on the target application like SPML does (check out our research for the details). Third, SCIM has an extensible user schema (think LDAP’s inetOrgPerson), something that was sorely lacking in SPML. Lastly, SCIM comes with support from the major Cloud application vendors (e.g., salesforce.com and Google).

Some folks in the identity community state that SCIM needs to support the functionality provided by the SPML Capabilities (e.g., Reference, Batch, etc.). Based upon our research, these capabilities are rarely (if ever) used in the wild. The functionality provided by these Capabilities can exist outside SCIM, with the added benefit of not overburdening the target application. Let’s have that debate; please provide a comment to get it going.

Several identerati have advocated rolling SCIM into the PSTC work for the next release of SPML. Until last fall, the OASIS PSTC was largely dormant for nearly four years. With all apologies to the really smart people who are on the committee, a harmonization effort will take years and delay the release of a viable provisioning standard. What is the point of harmonizing SCIM to a largely unadopted, broken standard?

Others have stated that SCIM is suited only for Cloud applications. I disagree. If SCIM works for cloud applications, then it will work for on-premises applications.

SPML may still live on for specific use cases. For example, some organizations have utilized SPML to connect disparate provisioning systems (despite the fact that none of the major provisioning systems have a conformant SPML service). This is still a valid use case; if it ain’t broke, don’t fix it.

My unsolicited guidance for the folks working the SCIM specification: be disciplined. Keep the specification as simple as possible. Avoid the “everything but the kitchen sink” philosophy that sunk SPML v2. Focus on the end goal of providing a viable provisioning standard; don’t bother trying to harmonize SCIM with SPML—few organizations are using SPML today. Implement the standard as quickly as possible in your company’s products and services to spur adoption.

Gartner/Burton Group Recommended Reading

Directory Services, Federation, and the Cloud  (2010 Assessment Document – subscription required)

Consensus on the Future of Standards-Based Provisioning and SPML (2010 blog)

OASIS or Mirage: Standards-Based Provisioning (2010 Technical Case Study – subscription required)

SPML: Life Support Redux (2010 blog)

SPML Is On Life Support …. (2010 blog)

The Value of SPML Gateways (2009 blog)

New Year’s Resolution: Let’s Talk More about SPML (2009 blog)

The Latticework of Identity Services (2007 blog)

SPML: Gaining Maturity (2006 Technology and Standards Document – subscription required)

Recommended Reading from Wicked Smaaht People

Patrick Harding: Why SCIM over SPML? Why not?

John Fontana: From SPML churn rises new crack at provisioning standard

Nishant Kaushik: SCIMming the Surface of User Provisioning

Dave Kearns: SCIMing the provisioning landscape

Martin Kuppinger: SCIM – will SPML shortcomings be reinvented?

SCIM Specification

If the client wishes to move to smart cards, then we discuss when the next OTP renewal is coming. The renewal is a milestone because it requires a cash outlay and represents a commitment to the OTP solution for several years. The typical answer is that the renewal is coming six months. A client in this situation will not be able to move to smart cards; Smart deployments are multi-year engagements (particularly if physical access control systems [PACS] are involved).

If the client is in a position to move to another OTP vendor, the question of application support arises. Authentication solutions are useless if they don’t work with the customer’s applications. If the current OTP solution is protecting many different application types, the customer may need to make a decision about moving to another vendor—at the expense of excluding one or more specific applications from protection. If the client is using the OTP solution for RADIUS-based applications and a small list of web platforms, a switch is likely possible.

Given all these complications, few customers elect to switch OTP vendors because of inertia. First, the customer has invested time and money implementing the current OTP solution. Customers typically have “rolling” token renewals, so a multi-vendor solution would be required for a period of time (most likely years).

In IT you CAN replace anything with time and money, but it is best not to underestimate the effort of doing so. Some OTP vendors provide a RADIUS proxy to broker authentication requests back to the original OTP infrastructure, which can help with transitioning to another OTP solution.

Let’s work from the perspective that the customer is concerned that specific OTP devices have been compromised. Are other vendors’ OTP solutions immune from this type of compromise? Is it faster and cheaper for the customer to distribute replacement OTP devices from the first vendor, particularly if the vendor provides free replacement tokens?

To me, the macro-level dialogue we can (and do) have with our customers is about matching authentication methods to resources based upon risk. All authentication types have strengths and weaknesses. Even the gold standard for authentication—the smart card—can be compromised: once the user has authenticated to the smart card, a trivial piece of malware can send data down to the card for private key signing functions, enabling the attacker to authenticate to PKI-enabled applications. OTPs are subject to man-in-the middle attacks, particularly in consumer phishing scenarios. Consumer authentication solutions have holes in them (e.g., lightweight device IDs that are easily impersonated, risk analytic solutions with high false accept rates). Software PKI solutions are subject to many of the same types of attack as passwords. In the end, the layering of authentication methods and other techniques can improve identity assurance. My blog post from 2007 discusses these concepts in more detail.

Recommended Reading (subscription required):
Authentication System Selection Decision Point
Road Map: Implementing OTP Authentication
Road Map: Implementing Smart Card Authentication (soon to be published)

Every SecurID OTP device has a serial number. The serial number is plainly visible on the back of the OTP device, the shipping packaging, in electronic form in many places, and (potentially) on shipping documentation. OTP devices that are shipped to customers are sequentially numbered.

It is easy to imagine the disclosure of one OTP serial number, including direct visualization, social engineering, insider knowledge, etc. The attacker would need to know the username associated with the OTP serial number as well as the user’s PIN. I discuss the ways this information can be captured in my last blog entry on the topic (March 21). If the attacker can acquire even one customer OTP serial number, it can get many customer serial numbers because the devices are sequentially numbered.

If the attack on the SecurID OTP system enables the calculation of the seed based upon the serial number, it presents risk to customer deployments. I am keen to hear more actionable information from RSA on its recent attack. Our clients are asking us for guidance. Without knowing exactly what transpired, we have to be mindful of the worst outcome and advise accordingly.

The attacker’s challenge is correlating the stolen seed to a real user. To do this, the attacker must capture a one-time password and the username. Both are provided when the user authenticates to a resource, and both can be captured at least two ways.

First, The OTP and username can be captured over the network in cases where session encryption is not used for the authentication transaction (between user and resource, and between resource and Authentication Manager). Today, it is relatively rare not to use transport security, but it does happen. Second, the username and password could be captured via user malware at the workstation. My colleague Avivah Litan discusses this type of malware attack on her blog.

Once a single OTP and username is captured, the attacker knows the user’s PIN and can correlate the passcode to the stolen seed (please see my prior entry for information about how the PIN and passcode are combined to make the OTP). This correlation would not be a herculean effort by any means. Run all the stolen seeds and the time of authentication through a software generator, and then compare the calculated passcode to the captured one. Once the attacker finds a match, he has the user’s PIN and device seed, and can use both to impersonate the user during future authentication attempts. The attacker would need to compensate for “clock drift”, which means that the attacker would likely calculate about 10 passcodes per seed to match the captured passcode.

Ironically, the modern version of RSA’s SecurID software OTP device may be less susceptible to attack as compared to the hardware OTP device. In general, hardware OTP devices are more secure due their tamper resistance capability. The software OTP device supports the CT-KIP protocol. The CT-KIP protocol enables the software OTP device and server to negotiate a new seed, which is not mathematically related to the seed that RSA shipped to the customer. The seed in the hardware OTP device cannot be changed and is the same as the seed that RSA ships to the customer with the device.

My assessment is that capturing a username and single OTP is hardly theoretical and has real world implications to SecurID customers if their seeds have been stolen. But what seeds—if any—were compromised at RSA? This is the magic question, the one we do not yet know the answer to. None, all, or seeds associated with specific organizations? If all of the seeds have been stolen, then the attacker can mount a generalized attack on any SecurID authentication. If seeds associated with a specific organization have been compromised, then the attacker must target users associated with that specific organization. Hopefully, RSA will disclose more about the attack so that its customers can take the appropriate next steps. As an aside, many customers do not adequately secure the seeds upon receipt from RSA, regardless of the recent attack on RSA; this is another vector for an attack on SecurID.

Many thanks to Merritt Maxim (my colleague at CA and RSA; twitter: merrittmaxim, blog: http://community.ca.com/blogs/iam/default.aspx) for reviewing this entry prior to its publishing.

RSA SecurID leverages a symmetric key algorithm to generate one-time passwords. The device stores the symmetric key (in SecurID speak – the “seed”) and passes it through the time-based algorithm. Voila: the passcode appears on the screen. The passcode is concatenated with the user’s static PIN (think ATM card PIN) to build the one-time password.

There are two items in the SecurID secret sauce: the algorithm and the seed. From a cryptography 101 perspective, algorithms should be public and keys should be private. Nevertheless, the SecurID algorithm is ostensibly “private”. We should not consider this algorithm secret and it is distributed more broadly than you would expect.

So the security of the SecurID system quite rightly rests with the seeds. When RSA ships OTP devices to its customers, it also ships a seed file, which contains all of the symmetric keys associated with the OTP devices in the order. The seed file is sent for both hardware- and software-based devices, and is loaded into the Authentication Manager. As an aside, many SecurID customers don’t protect these seeds adequately.

Let’s conjecture about the attack might look like. If the algorithm was stolen, RSA may not be happy about it, but I think the hoof prints are already visible outside the barn door. If any customer seed records were stolen (or the ability to create them based upon the device serial number), this is a significant attack that directly compromises customer SecurID deployments.

If the seeds have been stolen, one might argue that the user’s PIN will save the day; not so. First, the PIN is a weak password. Second, not all OTP devices have PINs. Devices that have not been distributed yet don’t have a PIN. Deployed tokens that will be redistributed to new users will have their PIN reset.

Now, we wait and learn more about the attack.

Recommended reading (subscription required):

Authentication Decision Point

Road Map: Replacing Passwords with OTP Authentication

Strong Authentication: Increased Options, but Interoperability and Mobility Challenges Remain