The Pwnie award winners were announced yesterday at the Blackhat Briefings in Las Vegas. In some categories, there was little suspense, with the winners almost a complete lock-in. Not surprisingly RSA got the nod for Lamest Vendor Response. This is a good time to revisit what made thxe RSA incident particularly significant.
The issue is not the breach itself: security incidents are a part of life. Even organizations with strong culture of risk management are not prefect. It’s instructive to note that RSA did not win for Most Epic Fail; surely they had formidable competition in Sony, almost untouchable for its string of remarkably bone-headed moves in 2011 culminating with the PlayStation network breach. What made the SecurID case stand-out was deliberate, pernicious and persistent attempts by RSA to conflate company bottom-line with customer best-interest, in the face of clear cut evidence to the contrary.
For background: RSA has presence in several product lines, ranging from licensing their cryptographic library BSAFE (which used to power Windows crypto API in the ancient days before it was retired in favor of Peter Montgomery’s native implementation) to providing a data-loss prevention suite. Yet the 2-factor authentication product SecurID stands out as one of the main revenue generators. SecurID is a small, tamper-resistant gadget which stores a secret key (the “seed”) and uses that seed to generate so-called one-time passwords or OTPs. Typically an OTP is sequence of 6 digit numbers that change over time or with the press of a button on the gadget. These numbers are used to authenticate users, usually in combination with a password, providing an additional degree of assurance that the user is who they claim to be. Unlike passwords, OTPs change constantly. This is good news for the user and bad news for prospective attackers: tricking the legitimate user into revealing one OTP does not help to predict the next one that would be required to masquerade as that user.
In reality SecurID model involves two very different and completely orthogonal businesses bundled into one:
- Selling hardware that generates OTPs according to a sound cryptographic algorithm. Here we have a traditional market in physical goods. One unit is sold for each user and it is strictly a transactional business. Short of replacements for lost/malfunctioning tokens, there is no ongoing relationship with the customer.
- Managing the life-cycle of identities associated with the dongles. This is the catch associated with OTP generation: the same secret sauce used to generate an OTP is also required to verify when a user submits one. That means whoever is charged with verifying OTPs must have access to the same secrets. This is an ongoing service, not a one-time sale. Each time a user shows up to authenticate and submits what they claim to be their OTP, there must be code running on some machine which accepts the user claim as input, compares it against the correct OTP generated from a copy of the secret key and responds with yay/nay.
In the case of SecurID, it is always RSA programming the SecurID tokens with seeds that are generated by RSA and it is always RSA running the servers that can authoritatively declare whether an OTP submission is correct or not. Customers have no choice in the matter. Yet this bundling is far from a foregone conclusion. It is perfectly possible to produce tamper-resistant OTP hardware which can be programmed in the field by customers, and provisioned with new keys that are not known to the manufacturer. Case in point is the Yubikey, a USB-based token that “injects” OTP directly into an application as a sequence of keystrokes. In this model, the hardware provider simply ships the gadgets to an organization. The IT department in the organization is responsible for programming them with keys, assigning the gadgets to their users, keeping track of which user got which gadget and the associated seeds.
Why did RSA insist on doing both? Simply because selling hardware is a commodity business where vendors can only compete on price. Granted, not all hardware is identical and there are indeed varying qualities of tamper resistance. Extracting the seed from the OTP generator by cracking open the case and inspecting the circuity inside would be considered a fatal attack on the system. Over the years different designs have exhibited different levels of difficulty in resisting such attacks. But few customers worry about such nuances: given an agreed-upon scheme for generating these OTPs (for example the open-standard OATH— incidentally not used by SecurID which has a proprietary algorithm) most enterprises would be interested in the cheapest hardware that can do the job. That would be a very competitive market where prices decline and no-vendor has lock in power. If vendor Bob decided to over-charge for their tokens, vendor Alice could undercut him with cheaper units that generated the same OTPs and functioned identically. Even worse, selling hardware is a one-time transaction. Short of replacing the gadget, there are few other revenue opportunities, certainly no lock-in effects. That means the vendor is faced with the choice of either shipping low-quality hardware that breaks down often– preferably just outside the warranty period– and requires frequent replacements, leading to unhappy customers (keeping in mind, this is critical authentication infrastructure: if the OTP generator breaks down, the user can not get their work done) or shipping a bullet-proof product that all but guarantees they will never hear from that customer for another 5 years.
The RSA solution to this dilemma is to bundle the service with the hardware. The nice thing about a service is that the customer must continue paying for it every year. By inserting themselves into the middle of every authentication event between an organization and one of their employees, RSA ensures a steady revenue, artificially rendering itself “indispensable” to the organization in question. But at what cost? The downsides to this arrangement are obvious, and in retrospect did not require a spectacular security breach with suspected nation-state sponsor:
- Availability: there is a massive single point-of-failure in the service maintained by RSA for verifying every OTP transactions from every SecurID token in existence. If for some reason, that service is not accessible or experiences an outage, every single customer of SecurID is impacted. In effect work grinds to a halt because nobody can authenticate. (Note there is an entirely different deployment problem in trying to use SecurID inside an air-gapped network disconnected from the Internet: in this case RSA services are not even reachable.) This is not purely a question of whether RSA can build services with higher uptime than a particular customer. For some customers it may well be the case that they are better off outsourcing this to RSA. In other cases it is not clear which side can maintain higher availability and lower latency: when this blogger was working on Windows Live ID, one of the primary concerns leading to the rejection of SecurID centered around taking a dependency on a third party for user authentication. If employees in an organization can not get their work done because authentication is failing, the organization bears the cost directly. RSA may refund some of their SecurID service fees, but the liability remains limited compared to the unbounded cost for the customer.
- Security: More importantly, RSA becomes a critical security dependency on an ongoing basis. A vendor delivering hardware must be trusted to have built decent tamper-resistance, not have any secret backdoors installed into the unit etc. But this is a one-time event. Once the hardware has been etched, potted, molded and put in a crate for delivery, any news that the manufacturer got 0wned can be met with a shrug. By contrast if the verification service with a copy of all OTP seeds ever gets breached– demonstrated in dramatic fashion by RSA– it is an emergency for all customers.