BlackBerry's Security Chief On The Priv, And Raising The Bar On Cybersecurity

Although BlackBerry didn’t make any major hardware announcements at CES, we did sit down with David Kleidermacher, BlackBerry’s Chief Security Officer to talk about the Priv’s security and its new CHACE initiative.

Lingering Questions On The BlackBerry Priv

Tom’s Hardware: Although the BlackBerry Priv is still running Android Lollipop [5.1.1], you’ve been pushing out Google’s monthly security updates regularly. In fact, I think one came out in early-December even before Google released it for its Nexus phones, which was great to see.

David Kleidermacher: This is something we have not yet made a big deal about that is a really big deal. We said a whole lot about how we’re going to do this frequent security patching, and now we’ve delivered on that promise.

TH: It is a big deal that you kept that promise, because other OEMs are not delivering updates as fast as they should be.

When it comes to Android, there’s the core OS and its built-in security features, and then these monthly patches to address exploits that Google may discover out in the wild. What is more important, the base securing of the device or the timely delivery of the security monthly updates?

DK: I wouldn’t say either is more important. You have to have a defense in depth strategy, which means that you need to build as much security as you can from the ground up. [It’s] all the things mentioned on our [Inside BlackBerry] blog about building [security] into the hardware, firmware and into the Linux kernel, into the Android stack. The things we do to harden all those things are very important, but it’s naive to think that no matter how good a job you do when you have something as sophisticated and complicated as Android, that it’s not going to have problems. It’s going to have problems, and you must do the patching.

So to do a good job on Android security, you need to build it in from the ground up, and you need to be able to react quickly if there is a problem. Both are important as a defense in-depth strategy. I wouldn’t say either are more important than the other.

TH: Are you able to say why you think what you’ve done to the underlying core of Android on the Priv is better than what your competition has done?

DK: Well I can, it’s just that there are two problems: I’m not an expert on everyone else’s device. They don’t disclose all details, so for me to speculate – “Hey, we do x, y and z they do a, b, c, and mine is better than theirs,” would not be appropriate. So my approach has been, let’s explain in the public domain the things that we do that we think the public should know about. We actually go above and beyond what AOSP does. We’ve done a lot of that. We’ve written a lot of material on that, and we’ll continue to do more. But I think it’s kind of unprecedented how much information we’ve actually put out there.

You’ve seen “insert favorite Android vendor,” they don’t talk about this stuff. As an example, we talk about how Google Android has some facilities built-in for integrity validation, so how do you know it’s running the known good version of Android that was shipped by the OEM? Well, Google has some stuff that they’ve built into Android [that] is essentially self-validating the system image. To know that it passes signature checks – if someone tampered with that system image, it would be detected. That’s really important for protecting against rooting and malware.

But one of the things it does not do is runtime integrity protection, so [what it does now] is kind of a boot time check. Which is great, really useful, but if malware gets into the system, and it’s able to get a hook into the system at runtime, you’ve not modified the flash firmware, but you’ve changed the runtime image. That’s also bad -- arguably worse -- because you can’t detect that.

We have something we call the BlackBerry Integrity Detection Engine -- we call it internally “BIDE.” And it is a runtime validation of the system, so we’re essentially underneath Android, something Google really can’t do, because it’s done in the firmware of the device. We’re looking up at Android; while it’s running, we’re watching it and measuring it, and observing it, and saying, “Does everything look okay?” That’s a really good example of something we do that your standard platform doesn’t do.

What About Marshmallow, And Smartphone Security?

TH: Let’s talk about Marshmallow [Android 6] -- I know it is coming to the Priv, so we know it’s going to happen. However, some people have been saying that Marshmallow has a couple of security features that Lollipop [Android 5.1.1 that the Priv runs] doesn’t have, which means in a few areas, a Marshmallow device could be more secure than the Priv. Do you agree or disagree?

DK: I think there’s two different questions there. One is, “Do there exist improvements in M that are improving Android security?” I would say yes to that question. The second question is, “Overall, if you look at the entire platform, and as an enterprise or a consumer buying a phone, would you consider a Priv running Lollipop less secure than ‘insert random OEM device running Marshmallow,’” and I would say absolutely not. I would disagree with that.

TH: The crux of many of the arguments is why did the Priv launch with Lollipop when Marshmallow was already out?

DK: There is an immense amount of engineering that goes into securing the overall Android platform, and, you know, Marshmallow’s improvements to Permission Controls for apps is a really great thing. I don’t want to make it sound like that’s not important, but it’s this little thing in this immense ocean of security that goes into securing a device. There’s a lot of special sauce right now [in the Priv] that is important, so yeah, I’d say we’re really proud of the Android L-level overall platform that we have, and are just going to make things better.

TH: Will your Marshmallow be the most secure?

DK: I believe it will be, just the same way we feel about Lollipop and its place in our overall platform -- we’re taking all the other platform pieces like the one I just described, that extra level of integrity checking, and that’s going to be in our Marshmallow, and in other [OEMs’] systems it won’t be. I’m confident that our [Android 6] will be the state of the art gold standard for Android security.

TH: So Ron [Louks, BlackBerry's President of Devices] said Q1 for the update -- we are on track for that, right?

DK: As far as I know, but good security companies have this compartmentalization so if you don’t need to know…I know it’s being actively worked on as fast as we can, but if there is an exact date, I don’t personally know it.

TH: How does a business customer evaluate all the secure smartphones available on the market, and how do they know what they’re buying is the most secure?

DK: You’re right though -- anyone who has done great [security] work in the past doesn’t guarantee great things in the future. But it’s definitely a piece of evidence that you can use [to evaluate them now], and that’s great.

Over time, you want to do better than that, you want more of a scientific approach to evaluation. There’s a number of security standards out there; there’s FIPS 140-2 for crypto assurance, there’s Common Criteria certifications that the government puts mobile devices through…I look at all of those certifications as trying to weed out all the really bad stuff out there.

They’re trying to make sure that you are using the right protocols for SSL…it’s all good stuff. But in the end, do those certifications give you a very high level of confidence that something can’t be hacked? I don’t think anyone would claim that. If you read the fine print, you’ll know what they’re trying to do, and it’s like basic commercial best practices. It’s not, “How do I know that nation state attackers or sophisticated criminals can’t hack into this thing.” That’s not what they’re trying to do, and ultimately that’s where BlackBerry wants to go.

One of the things that I’m working on is a very strategic effort to come up with a common framework, a common methodology for the following: Anything that has security -- not just a phone, but a medical device, an insulin pump, a piece of software, anything -- how do you specify the security capabilities it should have?

In some devices you need encryption. In other kinds of devices you might not… so what kind of security things do you first need and can you define those things in a common way? Can you create a common framework for defining security requirements? That’s the first important part.  There’s no way of doing that today. Well, Common Criteria is a way of doing that, but it’s not very widely used.

The second thing you need to do, once you specify the requirements, is how do you go about evaluating that the device or thing, or piece of software, actually, faithfully implements the security that [the manufacturer] has claimed. This is huge; this is the thing that’s missing right now.

Ultimately, pedigree only goes so far. Ultimately, to get a high level of assurance, you need to evaluate the security. When I say “evaluate,” that means a number of different things, but probably the most important thing is you have to try to hack the thing. You have to have really good hackers that are taking potshots at the thing and trying to figure out how to get in.

Yes, that does already happen. Some top customers who can afford it do that already. But that doesn’t really scale [to smaller organizations]. We need to have a single entity, a non-profit evaluation lab that will do that -- the hacking, the evaluation of the [security] design. For us, for all buyers out there, so that it’s economical. So you can get a high level of assurance in an economical and practical way. That’s the strategic goal.

Chasing CHACE

DK: At BlackBerry we have this thing called CHACE, the Center for High Assurance Computing Excellence. It’s a general corporate initiative of BlackBerry. Our goal is to raise the bar on assurance.

Two things go into that: One is obviously engineering. What are the cool, special sauce things we can do to build better security from the ground up. That’s something that CHACE is focusing on…of course, all of BlackBerry is focusing on [it], but CHACE is the leading edge of R&D in this area.

The second thing, is, “Okay you’ve done all these great [security] things you claim you’ve done, but how do independent observers have confidence?” That’s where our evaluation standard comes in.

Right now we’re targeting medical equipment, simply because there are people out there worried about all these connected healthcare devices that they’re using for more and more critical things like insulin delivery. They’re really worried about hackers getting into those things and killing people, so there’s a real appetite for getting that level of [security] evaluation, so we’ve started there. But our vision is that we can apply this to anything.

TH: Where are you with CHACE right now?

DK: In its current state, it’s nickname right now is DTSec [a medical device cybersecurity standard], and it has been published for public review. There has been an email blast to all these people we know, like the FDA, who is actually involved in helping us build the standard, a bunch of medical device manufacturers, independent cyber security experts like BlackBerry and physicians. It’s an international coalition of people, it’s not just a U.S. standard -- this is international, so Health Canada, for example, has been involved in it, the Department of Homeland Security, so on and so forth.

We’ve put it out for public review, and it’s targeting a certain class of diabetic devices for now, just because we have to start somewhere, but it will be ratified likely toward the end of this quarter, in the March time frame. Then there will be version one, then the first devices -- the first insulin pumps and glucose meters -- will go through the [security] evaluation process, they’ll get certified, and we will then have an example that we can show people how this can be done.

TH: How long before this grows to encompass devices outside healthcare?

DK: It’s a marketing problem. We’re breaking the back of the technical problem. We built the framework, we’re showing people how you specify the requirement. By the way, while it’s a new standard, we’re leveraging existing standards. We’re not trying to reinvent the wheel. Common Criteria has a very good framework for specifying requirements, and we’ve adopted that.

The part that’s really important is the evaluation program. Bringing a product in and having a lab go through and look through the design. actually go and try to hack it, those are things that haven’t been done in any kind of standardized way. There have been little pockets of government that’s tried to do it here and there, but no general independent standards.

It’s simply a marketing problem -- it’s getting the right industry organizations like SAE [Society of Automotive Engineers] in the automotive sphere, and similar organizations in the industrial sphere, it’s getting them all aware and bought into what we’re doing and adopting it.

TH: This sounds very interesting. Once it becomes the standard in every industry, it’s going to solve a lot of problems and address questions people have about the security of devices.

DK: Here’s my favorite quote that I love, because it succinctly explains the problem: “If we want to raise the bar on cybersecurity, we have to know how to measure its height.”

Alex Davies is an Associate Contributing Writer for Tom's Hardware and Tom's IT Pro, covering Smartphones, Tablets, and Virtual Reality. You can follow him on Twitter. Follow Tom's Hardware on Twitter, Facebook, and Google+.