BlackBerry Leaves Pakistan Rather Than Provide a Government Backdoor

BlackBerry has chosen to shut down operations in Pakistan rather than provide the government with backdoor access to encrypted communications.

Pakistan is a relatively small market, but still.

EDITED TO ADD (12/14): Another news article.

Posted on December 4, 2015 at 6:40 AM • 30 Comments

Comments

Nicholas WeaverDecember 4, 2015 7:07 AM

It isn't just a backdoor. Consumer Blackberry, by design, is backdoored: If the police come with a warrant, they can get the consumer's communication. (The business servers are the same way, again that is a feature).

Pakistan apparently wasn't satisfied with this arrangement, and wanted bulk access to the consumer servers.

How long before David Cameron insists that the UK gets the same deal?

clive RobinsonDecember 4, 2015 7:56 AM

From the article,

Governments, accustomed to tapping phone lines and opening mail in decades past, want access to people's digital data to help stop crime and security threats.

History shows us that Pakistan's reasons have little to do with "crime and security threats", they want to "punish the young" for daring to be human... Oh and economic espionage (that goes almost without saying in that part of the world).

As I've said in the past Pakistan has more to lose from this than Blackberry, I already know of one engineering company pulling the plug on Pakistan because of the on going IP theft from breaking into their local facilities and tapping of communications...

I guess they might learn, but I doubt it will be before the ordinary citizen gets hurt by lack of economic chance...

Tommy DohnDecember 4, 2015 8:20 AM

Only because they don't control the private keys to BES servers - their corporate customers do. They would have to change that to comply with Pakistan's request.

For BBM and BIS email for consumers, however, BlackBerry doesn't have a problem to give governments the one and only private key to those conversations, as it already has for India, Saudi Arabia, UAE, and probably Canada, US, and others.

Just something to keep in mind before everyone mindlessly starts parroting that "Blackberry cares about your privacy". The company itself has said it doesn't want to go all crazy about encryption and that it wants to comply with "lawful intercepts" (read: backdoors) mere weeks ago.

Clive RobinsonDecember 4, 2015 9:11 AM

@ Tommy,

Yup Blackberry do not have an enviable reputation as far as "privacy" is concerned.

In the UK the phones used to be popular with activists and teenagers etc. Then the Police let slip Blackberry had been releasing message traffic... And all of a sudden their phones were nolonger popular.

As far as Saudi is concerned the story is that they were after "unapproved behavior" in Women, both unmarried and married, and any LBGT behaviour. Apparantly evidence from Blackberry secure messaging has been used in their medieval justice system...

The thing is people in the West tend to forget about "what is a crime" in some parts of the world so the idea of releasing data of "criminals" is just a way to say "unaproved behaviour" as a way to hide what is really happening on the ground.

Oh and remember "chewing gum" and "bringing gum" into Pakistan has been treated as serious criminal behaviour, so you can kind of guess what "criminal" means there...

WaelDecember 4, 2015 9:30 AM

@Clive Robinson,

Oh and remember "chewing gum" and "bringing gum" into Pakistan...

I believe it's Singapore.

FM RadioDecember 4, 2015 9:51 AM

@Clive Robinson

The funny thing about Saudis is that homosexuality is practiced a lot between men who don't have a wife and it isn't considered that bad as long as it stays secret. However some people are not happy with that arrangement and want to have their gay parades and official recognition. Some people are never happy with whatever they have.

albertDecember 4, 2015 10:17 AM

@FM Radio,

Maybe they just don't want to risk having their nuts cut off if they get caught.

. .. . .. _ _ _ ....

AndrewDecember 4, 2015 10:23 AM

Oh, come on! Don't get so excited over it.
Get excited once they do the same with UK's ahem... cough... "request" for backdoor.

If that ever happens...

Who?December 4, 2015 11:44 AM

If I remember right, successful NSA access to either BlackBerry devices or RIM servers was confirmed when Snowden leaks started two years ago.

Tony H.December 4, 2015 12:24 PM

It's not really clear who's doing what. The government of Pakistan issued a "compliance order" requiring them (BB) to give the government access to customers' BES servers by Nov 30. BB refused, and the government announced an "extension" to Dec 30. Nobody seems to have caved, but neither has BB actually left Pakistan. They continue to say they won't comply, so there could well be another extension as year end approaches. Who has the most to lose...?

This CP wire item on CBC casts it in a slightly different light than the Australian CNET story.

rgaffDecember 4, 2015 12:31 PM

All smoke and mirrors, Blackberry is backdoored anyway... as is every other phone system and proprietary thing imaginable. Any that aren't yet are just a matter of time, they're all caving one by one.

Who?December 4, 2015 2:33 PM

@rgaff

Not to say the phone protocols themselves (standard voice calls, SMS, MMS, VoIP...); the phone system is not something to be trust. Even if new end-to-end encrypted alternatives are ok (they aren't in most cases) the underlying operating system is seriously broken.

ThothDecember 5, 2015 4:42 AM

@Wael, Clive Robinson
Yes, Singapore pubishes anyone locals who do not behave heavier than foreigners. You foreigners can get away a little but the locals get the nastier end. Anyway, all chewing gum, non-licensed tobacco and non-licensed alcohol are a rather serious crime with least warranting a heavy fine or worse warranting a little black bean rice time (jail sentence as they serve black bean rice in the past).

Blackberry as a commercial entity that tries to please the local govts with data are not even trusted at all. Pakistan is not a significant market so it's liekly ok to close shop.

I wonder if their current targets are the European Govt market. The reason being Angela Merkel touting a Blackberry with the newly acquired SecuSmart technology which us actalually a smartcard hsm in MicroSD form factor and supporting AES keys. I wonder "how secure" and Angela herself being the "poster person" for the new "unbreakable" Blackberry + Secusmart SD card HSM combo....

TõnisDecember 5, 2015 7:46 AM

BlackBerry isn't backdoored, all communications are with this CALEA nonsense. Sprint, Verizon, T-Mobile, AT&T, Google, facebook, Twitter, etc. are all the primary NSA collaborators as Snowden has confirmed. BlackBerry communications over BIS were never meaningfully encrypted. They were at most scrambled (all encrypted with the same key), and they may have taken a different path/tunnel over the BlackBerry network. When cops in London wanted and were given access to certain BBM communications during the riots they weren't given anything other than certain consumers' already inherently unsafe communications. So, when BlackBerry says it will help cops, this is all it means, that BlackBerry will give the cops what it can. BlackBerry's BES communications are fully encrypted and the keys are only on the user's BES server. BlackBerry has always said that it cannot access BES users' communications. It has never been admitted by BlackBerry or anyone else that BES is backdoored or otherwise compromised. In fact, BlackBerry has stated many times that it does not believe in or install back doors.

Communications are only one side of security. The other side is the protection of data at rest. I'm on BlackBerry 10 which runs over ordinary (not even BIS) data. I have no delusions about my communications being safe from spying because, as I pointed out above, the entire communication system is compromised. What I am reasonably sure of is that the encrypted data at rest on my password locked BlackBerry 10 smartphone is secure. It cannot be accessed with little exploits like the ones people have demonstrated on youtube when they find ways to circumvent iphone and android PIN locks and passcodes. I'm reasonably sure that the encrypted data at rest on my password locked BlackBerry 10 smartphone can't even be meaningfully accessed by state police forensics labs.

SeanDecember 5, 2015 8:03 AM

http://www.theregister.co.uk/2012/08/02/rim_keys_india/ Blackberry used to be sold as secure communications, I mean, why else would all of the US Congress be using them? There have always been better solutions and they finally began their decline and then they started giving up the keys, which was arguably their only advantage. Now they're trying to reverse that somehow?

ThothDecember 5, 2015 8:57 PM

@Tõnis
I do not believe Blackberry is as miraculously safe although somewhat much safer but still can be compromised by properly conducted forensics and hacking (if the nation state decides to devote nation state ICs like NSA/GCHQ to chase after a target or a few targets).

Let's dissect some surface specs on the Blackberry Z/Q10 phones and their protection from what can be observed. They both use Qualcomm Snapdragon S4 and from that we can deduce the following features:

- QSEE (Qualcomm Secure Execution Environment) a.k.a ARM TrustZone re-branded for Qualcomm
- ARM architecture with TrustZone built-in
- QNX OS (microkernel and "security" designed)

What we will not go into are more advanced attacks like decapping chips or using RF fault injection that @Clive Robinson talked about which he once experimented (a very formidable attack vector reserved for nation states at the highest levels I guess).

So let's go about trying to understand how these stuff influence Blackberry 10. We start from the chip which is actually a Qualcomm ARM chip with ARM TrustZone. ARM TrustZone has been defined by ARM company as "Not Tamper Resistant" and thus the chip itself is not hardened against hardware and probably even software attacks. Most CC EAL 4/5+ smart card chips or hardware crypto chips are somewhat tamper resistant to at least resist electrical glitching attacks and faults (DFA) and DPA and SPA. Thus, we can quickly conclude that if ARM TrustZone chips are not DPA, DFA or SPA protected, that means you can tap into the wire lines to glitch the chip logic or mount SPA or DPA attacks to understand the code execution and even retrieve secret keys (hardware and software keys). There goes the encryption :S . Research have shown you don't need more than $5000 USD these days to obtain equipments capable of not only glitching circuits but also deducing secret keys and logic from SPA and DPA attacks once you have captured the phone and only needing to tap into the data buses without decapping the chip.

Next, we take a look at Qualcomm's implementation of it's Crypto Engine and QSEE/TrustZone. QSEE being Qualcomm's interpretation and implementation of the ARM TrustZone technology (because ARM doesn't have reference TrustZone implementation and relies on partners to implement and they give feedbacks) are not the cleanest TrustZone implementation. The QSEE library have been found to contain software vulnerabilites (which most have been patched) that leads to exploit on the TrustZone's security. Due to inaccessibility of these chips and NDA agreements, there are no known physical decapping of such TrustZone chips so it's hard to tell if the hardware implementation are correct but the software implementations from Qualcomm via QSEE is flawed (but patched). TrustZone being a closed technology that relies on secrecy of the design have been inaccessible to most security researchers thus it is hard to assert if chip manufacturer's implementations on hardware and software are secure and compliant but Qualcomm being the biggest manufacturer and seeing the most deployment in modern smartphones that rely on such security technology (Apple's iPhone Secure Enclave and Samsung's KNOX are also ARM TrustZone technologies being re-branded). Knowing that Qualcomm has shown flaws in it's QSEE technology from security research into it's software libraries to access the hardware side of the QSEE (hardware crypto and security), it is likely more bugs are hidden and thus untrusted.

QNX OS is a closed source proprietary microkernel with main OS and is known to be engineered to be as secure as it can from the ground. The good thing with a security centric microkernel is you have a very small software TCB and a bunch of securely isolated process and objects which the objects can be a normal running userspace kernel or some sensitive libraries. From what I can deduce, the QNX might be running on both the secure and insecure userspace of the TrustZone (leveraging on TrustZone via QSEE implementation). A properly implemented security microkernel running on TrustZone (assuming Qualcomm's implementation called the QSEE) is correct and flawless would increase software security with hardware backing but the fact that QSEE implementation is found to have flaws makes it less likely that a security microkernel can manifest it's potential fully as depicted in the ARM TrustZone technology. Due to the QNX's closed nature, it is hard to assert if it is truely secure.

On the hardware side, DFA, DPA and SPA can be applied on the data buses to manipulate and listen on the chip (cost less than USD$5000 for equipment) and the software can be explored due to known holes (although being patched) of the QSEE. QNX have some flaws hovering around in it's history as well.

You mentioned that data-at-rest are mostly safe from organized groups may not be as secure as was thought as the chip itself was not designed to withstand more advanced threat models. It is only simply to deter minor hacking and accidents (which can turn severe) from the software side. It is unknown of the software level of quality but definitely on the hardware side, it leaves much to be desired due to it not being tamper resistant and not DPA, SPA and DFA protected (baseline for most smartcard and hardware crypto chip must protect from those 3 attacks to a degree to be used for banking).

Comey and those advocates for weaking or removal of encryption already know they can easily walk up to a phone and without needing to decap a chip, tap it's data lines and mount attacks and listen on the phone using the crypto keys but their crying out loud on anti-security measures is either a false flag for their known capabilities or they just want to avoid needing the trouble to grab all the phones and tap all the bus lines and to simply read all messages in clear en mass. It wouldn't be difficult for Comey et. al. to get their guys to tap bus lines with very little cash from the Black Budget (USD$5000 isn't a lot for these guys). The NSA/GCHQ/BND et. al. would already have more advance technology than FBI to do all these (probably even mount a massive RF/EM sniffing or implants to do mass sniffing via RF/EM faults).

If you have secrets, leave them out of the phone and use a HSM or smartcard and always do split secret keys. Smartcards are easily available and with some effort you can get a script on a JavaCard type of crypto smartcard up and running with split secret keys and that is a much safer option. I have been busy playing with crypto on JavaCard type of smartcards for a little while and once you are used to the initial steep learning phase (if you have never done low level programming like assembly) you would probably be fine afterwards. Just don't store the keymats in a single smartcard and you are mostly fine :) .

FigureitoutDecember 5, 2015 10:38 PM

Thoth
a very formidable attack vector
--As a defender, if you force exotic RF attacks, polymorphic cross-platform malware on memory sticks, or the last resort physical ones, you win as a technologist. An organization needs 24/7 monitoring and some $$reasons$$ to protect from physical break-ins. There's a lot of variables that make those attacks by default unreliable or risky compared to some internet virus. Plus the more often these attacks get used the better chance they'll be seen, revealed, studied, and then defeated again. :)

ThothDecember 5, 2015 11:36 PM

@Figureitout
That's why it is reserved for the most critical operations by nation states. You won't see it daily I guess.

freeDecember 7, 2015 2:01 PM

Well, of course. Blackberrry only provides anglo-american governments, that is, criminals, with backdoors.

Iphone SecurityDecember 8, 2015 1:31 PM

@Nicholas Weaver, @all

Relatively speaking, regardless of other issues or features, from a security perspective is there a preferred device(s) amongst iphone:
5s, 6, 6 plus, 6s, 6s plus?

ThothDecember 9, 2015 7:11 PM

@Iphone Security
The current state of ***all smartphones*** regardless of brand are very vulnerable although things like TrustZone does help just a little but not by much. Don't bet on the smartphones and always keep sensitive stuff away and always enable so-called Fill-Disk Encryption whenever possible at the slightest opportunity (there are debates about FDE but it's better than nothing). All the above iPhone versions by default support and already uses the iPhone Secure Enclave a.k.a TrustZone technology so it makes very little difference and most difference are just tweaks and bugs related. There is not a lot TrustZone allows them to tweak anyway since it's not Apple's technology but ARM's (in the very core it's a ARM chip design).

ThothDecember 9, 2015 8:06 PM

@Iphone Security
It really doesn't matter if it is iPhone 5 or 6. They are using the same technology (Apple's Secure Enclave a.k.a ARM TrustZone). The security technology actually belongs to ARM just that Apple is licensed to use and distribute it under NDA. The differences probably are features, tweaks and bugs that's all.

You should not be storing sensitive information on any smartphones despite the existence of technology like TrustZone and such as their security benefits are usually minor if you consider the overall picture of implementation, distribution and end user usage.

ianfDecember 10, 2015 12:43 AM


@ Thoth

Re: Apple's Secure Enclave a.k.a ARM TrustZone

There is not a lot TrustZone allows them [WHO/WHAT exactly?] to tweak anyway since it's not Apple's technology but ARM's (in the very core it's a ARM chip design).

Since you apparently are familiar with that tech, could you please write up a few paragraphs on that ARM TrustZone's main facilities(?), abilities(?), restrictions or whatnot. All that can be gleaned from Apple's support (non-developer) sites is that the iOS sandboxes all the apps, but there's basically no mention of the hardware CPU, the microkernel, and the like. So any "pop-scientific" description of that would be a good start. Thanks in advance.

ThothDecember 10, 2015 6:16 AM

I will put thr TrustZone technology in the attached links. The PDF is written by ARM while the webpage from Genode is for the "tl;dr".

Put in simple, he chip supports 2 types of world. A secure world and insecure world. Both worlds are isolated by a sort of "manager". All your trusted codes are kept in the secure world and untrusted stuff in the insecure world. Both worlds run their own OSes although they cannot be truely considered virtualize though.

The thing is both worlds are simply separated domains with a monitor/manager to isolate them, inspect and relay RPC calls for cross-domain functions. If thebOS in the secure world is compromised, it would affect the entire secure world and the use of a microkernel in the secure world is to isolate, breakdown and simplify the secure world's OS processes and objects in a bid to raise the security and resilience of the secure world due to the use of a security microkernel so that the secure world doesn't fall that easily if something nasty happens in the secure world.

Samsung took a literal approach for TrustZone by implementing KNOX that opens up yhe secure world for users to use. You can interact with the insecure world or login to KNOX and enter into the secure world and you can duplicate and application from insecure world into secure world which an example is the Openpgp keychain app that normally runs in insecure can be moved into secure world if you trust Openpgp keychain. The KNOX architecture shows the cladsical secure/insecure split.

Although Apple doesn't clearly state how they implemented TrustZone in their Secure Enclave, from their whitepapers, I guess that every iPhone application hasba secure and insecure side which iOS would under the hood partition and manage. If my assumptions are right, all applications would enter a secure state initially and downgrade to insecure state with a secure world "shadow".

Best the base technology both Secure Enclave and KNOX uses are the TrustZine technology, they are ultimately bound to ARM's specifications. Due to the TrustZone being a NDA-ed technology, the depths of exactly what specifics are kept behind agreement-walls and cash-walls.

Apple released the iOS 9 security whitepaper and it includes stuff like microkernel, TouchID designs and security, usage of DJB's Curve25519 and algos and all that stuff. It gives some details but not a while lot. I have linked it below too.

Links:
- http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf
- http://genode.org/documentation/articles/trustzone
- https://www.apple.com/business/docs/iOS_Security_Guide.pdf

ianfDecember 10, 2015 7:18 AM


Thank you, Thoth. It was interesting to read, though way above the pop-technical insight level that I requested. There's no point in me touching the supplied links, as they'd only enlarge the depth of my ignorance… I suppose what I wanted to hear were the mechanics of the code flow, and (power-wise, technical, etc) benefits of a RISC chip running its own OS—let alone two!—governed by a manager [which I take to be something like a *Nix memalloc() disk segment controller] from the onboard microkernel.

Since the latter is embedded in silicon, it probably contains hooks for rectifying potential bugs discovered after the fact, which, alas, also make potential entry points for backdoors (e.g. Ed Snowden's various "smurfs," that the NSA/ GCHQ manage to get onboard the secure chip anyway). I assume it executes some p-code, which it translates after first validating in real time from iOS-supplied object code—but that's about the extent of my knowledge of RISC. So please make another try, but this time KEEP IT SIMPLE, pretend I'm stoopid if there's no other way.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.