Schneier on Security

Thoth • December 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 🙂 .

Thoth • December 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.

Thoth • December 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).