Hardware: The Safe Anchor

Last year (a couple of months after Apple’s announced the availability of Touch ID enabled iPhones), I blogged about mobile biometrics, stating the need for biometric solutions to “blend” with the rest of the moving parts of a multi-factor auth ecosystem.

Over the past year, a “series” of related events have occurred; we’re seeing both the availability and adoption of various biometric methods and technologies:

• Samsung releasedthe Galaxy S5 smart phone with built-in biometric support
• Fujitsu, Microsoft and others have given us sneak-peeks at Iris, fingerprint and 3-D face recognition equipped devices. Iris recognition is pretty interesting (or maybe I should say more promising), in that the method provides a better acceptance rate and a lower chance of users being impersonated than all other biometric methods out there today.
• Recently at Google IO, Google announcednative fingerprint enrollment & verification APIs in the upcoming Android M. These APIs can be used by any mobile app, including financial applications that are looking for built-in support for biometrics as part of a payment process. Now, its up to hardware device makers, to take advantage of these biometric capabilities.
• Multiple companies (including Apple, PayPal, Samsung, Google and others) have either released or announced imminent plans to make ‘payment’ services available that heavily rely on device-side biometric recognition for user verification.
• The FIDO alliance has now 2 published specification drafts, that have been used in implementations by the likes to DOCOMOto provide biometric protected access for their users, to their online services.
• At RSA, we launched a solution (VIA) that (among many other features), can use existing biometric capabilities on mobile devices (in combination with many other methods) to provide strong user authentication.

“Lots” of activity, mainly, trending towards empowering users with convenient & secure biometric methods for verification.

I’d like to highlight 3 important commonalities & perspectives regarding these activities.

1) In the Device We Trust


We’re witnessing a massive shift towards “trusting” device-based user authentication.

This is big. Let me explain.

We wake up these days to Groundhog Day recurrence of news about yet another site/service being hacked, where tons of sensitive user information has been compromised. And what was compromised? Often: User credentials. So, a hacker uses someone’s stolen user-name/passwords to hacks into a site, gets access to tens of millions of more user credentials. And so forth and so on…

To stop this cycle, we need to do one/many of the following:

1. A) Less is more:Stop hosting all such user credentials in easy to smash-and-grab places

And/or

1. B)You got nothin':Reduce the importance/significance of the credentials we’re on the server, if compromised,

And/or

1. C)You can’t touch this: Make it more difficult for hackers to ‘impersonate’ real users (or steal their login credentials).

Establishing a stronger “trust” relation with devices, from which all users actually access sites & services, resonates with all of these approaches.

Once we’ve trusted the device, then we can trust the user using the device, and to get there, we move (at least part) of the user credentials away from the servers, and onto the trusted devices; a distribution that changes the threat model dramatically:

Less data on the server => Reduced importance of user credentials on the server.

Now, for a hacker to get their hands on the same tens of millions of credentials, and to make use of user credentials, they would have to physically steal that many actual devices (phones and tablets), AND hack into each and every one of them.

Doable, just not practical.

What about attacks against specific users? Did we make that easier? Or as my colleague Chris McLaren asks: “Shift-to-device makes the device a more interesting place to harvest credentials for a targeted, single person. In other words, have the service providers decreased their exposure by making it my problem to make sure that my credentials are safe on my personal device?”

How do we make it really difficult for hackers to get access to sensitive data that’s stored on our devices, to make them trust-worthy?

See number 2 below…

2) The Safe anchor: Hardware

The applications we typically download and install on our mobile devices run in an environment, known as the rich mobile operating system or Rich OS.

While the Rich OS is great for running applications, it doesn’t inherently do a good enough job of protecting sensitive data and preventing sensitive operations from attacks (especially brute force attacks on rooted/jail-broken/hijacked devices or devices infected with malware).

As a result, unauthorized/unintended access to data can’t be prevented 100 percent, especially for the data at rest, even if such data is being encrypted.

To solve this, many devices are now equipped with an alternative, more protected environment, that runs in parallel to the Rich OS.

There are a variety of these protected environments. Secure Elements (SE), Trusted Execution Environments (TEE), Trusted Platform Modules (TPM) and Secure Enclaves (SEn) to name some of the more popular implementations available today.

Each of these protected environments have their strengths, weaknesses and market footprints, which I’ll review in a separate upcoming blog. Regardless, they share one key characteristic:

They enable protection of sensitive data and enable performing sensitive operations on such data by creating a Hardware Root of Trust, or a Hardware Anchor.

Let me also tell you more about Hardware anchors, or as I like to call them: Portable HSMs…

We’re seeing a common design philosophy, shared by Apple, Microsoft, Samsung, Google and other key device makers: They are all moving towards one-form-or-the-other-of Mobile (or portable) Hardware Security Module (HSM).

HSM is a facility that has been historically used by software running on servers to store/execute sensitive data/operations.

So what could applications “stick” into these mobile HSMs and what operations can we perform there?

Here are some examples:

• Store Private keys used in a public-key encryption process (symmetric/asymmetric) & sign/encrypt requests, in the portable HSM using these keys,
• Store premium content (for example high-definition videos) that are copyright/copy protected
• Store & process tokenized data that can be used to identify a users credit-card/Bitcoin wallet during a payment transaction
• Store user identity information that needs to be well protected
• Store and process user biometric template data, perform verification operations on Pins & Passwords,
• , etc.

3) Need for multi-factor auth, for the foreseeable future


While mobile security highly benefits from using mobile or portable HSM solutions, we face multiple roadblocks that need to be overcome:

• Not ubiquitousOnly a small fraction of laptops, smart-phones, tablets and phablets are currently equipped with the proper HW for portable HSMs
• Not easy to leverage:Of the devices equipped with portable HSM, only a subset allow for convenient use of the protected environments by application developers. Usage is still kludgey; in some cases they require establishing expensive and complex partnerships with the mobile operators, hardware device makers, and operating system providers.
• Not all bullet proof:Not all mobile HSM environments are tamper proof or even tamper resistant, and some have exposed vulnerabilities that allowed for side-channel leak of sensitive info.

In addition, hackers have not stayed stagnant. They have copied user biometric data (such as Fingerprints, voice prints and face prints) & used such data to successfully impersonate users and the devices those users use; they’ve stolen sensitive data from devices using malware, by targeting devices that lacked adequate secure sensitive data protection, lacked hardware anchors or were not properly patched.

To summarize, while the device eco-system is getting much stronger from a security perspective, we’re still in a transformational phase, as we move towards trusting devices en-masse, a phase which could last for many years to come.

So, while we will leverage mobile HSM when and where possible, we will also need to continue to blend mobile biometrics solutions with the rest of the moving parts of a multi-factor auth ecosystem.

Following this model, to verify users, with a high level of assurance & across a large range of devices, multi-factor auth solutions should blend biometrics with other methods, such as out of band messaging, tokens (be it hardware or software based tokens that generate one-time-passwords), behavioral risk analysis, and, yes, when it makes sense, use good-old Passwords

In my next blogs, I’ll discus how mobile biometrics can be blended with other authentication methods, describe the different types of portable HSM & why it only matters if all the components in a chain of trust have some form of a HW Anchor, I’ll provide practical usage examples of hardware anchors, and why having HW anchors is important in the emerging world of IoT devices. Stay tuned :->

Thanks to Chris McLaren and Alison Raymond Walsh for their contribution to this blog.

The post Hardware: The Safe Anchor appeared first on Speaking of Security - The RSA Blog and Podcast.