October 7, 2014
Andrew Zonenberg, writing on the October 4, 2012 website, SiliconExposed.com, says that “recent headline news have made a big deal of Apple encrypting more of the storage on their handsets; and, claiming not to have a key. Depending on who you ask. this is either a huge win for privacy; or, a massive blow to intelligence collection and law enforcement capabilities” Mr. Zonenberg notes up front, that he is “going to try and avoid expressing any opinions of government policy; and instead, focus on the technical details of what is possible — and, what is not possible — and why encryption as much of a major game-changer as people seem to think “
Mr. Zonenberg commends a recent article by Matthew Green at Johns Hopkins; but, says he feels compelled to address “a few points he feels,” need additional intellectual nourishment. “The general case here.” he writes, “is that of two people, Alice and Bob, communicating with iPhones — while a third party, Eve — attempts to discover something about their communications
“First off,” Mr. Zonenberg writes, “the changes in iOS 8 are encrypting data on disk. Voice calls, SMS, and Internet packets still cross the carrier’s network in clear text. These companies are legally required (by CALEA in the U.S., and similar laws in other countries) to provide a means for law enforcement or intelligence agencies to access this data. In addition, if Eve can get within radio range of Alice or Bob, she can record the conversation off the air. Although the radio links are normally encrypted, many of the cryptosystems are weak; and, can be defeated in a reasonable amount of time by cryptanalysis. Numerous methods are available for executing man-in-the-middle attacks between handsets, and cell towers, which can further enhance Eve’s interception capabilities.”
“Second,” he argues, “if Eve is able to communicate with Alice or Bob’s phone directly (via WiFi, SMS, MITM, of the radio link, MITM further upstream on the Internet, physical access to a USB port, or using spear-phishing techniques to convince them to view a subtly crafted e-mail, or website) she may be able to use a Zero Day exploit to gain code execution on the handset; and, bypass any/all encryption by reading the clear text out of RAM — while the handset is unlocked. Although this does require that Eve have a staff of skilled hackers, to find a Zero Day, or deep pockets to buy one, when dealing with a nation/state level adversary this is hardly unrealistic.”
“Although this does not provide Eve with the ability to exfiltrate the device’s encryption key directly,” Mr. Zonenberg argues, “this is unnecessary if clear text can be read directly. This is a case of the general trend we’ve been seeing for a while — encryption is no longer the weakest link, so attackers figure out ways to get around it…rather than smash through.”
“Third,” Mr. Zonenberg contends, “in many cases the contents of SMS/voice are not even required. If the police wish to geo-locate the phone of a kidnapping victim, (or a suspect) then triangulation via cell towers and the phone’s GPS, using the existing 911 infrastructure, may be sufficient. If intelligence [agencies] are attempting to perform contact tracing from a known target — to other entities who might be of interest, then the “who called who when” metadata is of much more value than the contents of the calls.”
“There is only one situation where disk encryption is potentially useful,” Mr. Zonenberg contends: “If Alice or Bob’s phone falls into Eve’s hands while locked; and, she wishes to extract information from it. In this narrow case, disk encryption does make it substantially more difficult, even impossible, for Eve to recover the clear text of the encrypted data.” “Unfortunately for Alice and Bob.” he writes, “a well-equipped attacker has several options here (which may vary depending on exactly how Apple’s implementation works; many of the details not public).”
“If the Secure Enclave code is able to read the UID key, then it may be possible to exfiltrate the key using software-based methods,” Mr. Zonenberg writes. “This could potentially be done by finding a vulnerability in the Secure Enclave (as was previously done with the TrustZone kernel on Qualcomm Android devices to unlock the bootloader). In addition, if Eve works for an intelligence agency, she could potentially send an NSL to Apple, demanding that they write firmware, or sign an agency-provided image, to dump the UID off handset.”
“In the extreme case, it might even be possible for Eve to compromise Apple’s network and exfiltrate the certificate used for signing Secure Enclave images. (There is precedent for this sort of attack — the authors of Stuxnet appear to have stolen a driver-signing certificate from Realtek).”
“If Apple did their job properly,” Mr. Zonenberg writes, “the UID would be completely inaccessible to software and locked up in some kind of on-die hardware security module (HSM). This means that even if Eve is able to execute arbitrary code on the device while it is locked, she must brute-force the passcode on the device itself — a very slow and time-consuming process.”
“In either case,” Mr. Zonenberg states, “an attacker may still be able to execute an invasive, physical attack. By de-packaging the SoC, etching or polishing down to the poly-silicon layer; and, looking at the surface of the die with an injection microscope the fuse bits can be located and read directly off the surface of the silicon.”
“Since the key is physically burned into the IC, once power is removed from the phone there’s no practical way for any kind of self-destruct to erase it. Although this would require a reasonably, well-equipped attacker, I’m pretty confident — based on my previous experience that I could do it myself — with equipment available to me at school, if I had a couple of phones to destructively analyze and a few tens of thousands of dollars to spend on lab time. This is pocket change for an intelligence agency,” Mr. Zonenberg observes.
“Once the UID is extracted, and the encrypted disk contents dumped from the flash chips, an offline brute-force, using GPUs, FPGAs, or ASICs could be used to recover the key in fairly short time. Some very rough numbers I ran recently suggest that a 6-character upper/lowercase alphanumeric SHA-1 password could be brute-forced in around 25 miliseconds (1.2 trillion guesses per second) by a 2-rack, 2500 chip FPGA cluster costing less than $250,000. Luckily, the iPhone uses an iterated key-deviation function which is substantially slower.”
“The key deviation function used on the iPhone takes approximately 50 mili-seconds on the iPhone’s CPU, which comes out to about 70 million clock cycles. Performance studies of AES on a Cortex-A8 show about 25 cycles per byte for encryption, plus 236 cycles for the key schedule. The key schedule setup only has to be done once — so if the key is 32 bytes, then we have 800 cycles per iteration, or about 87,500 iterations.”
“It’s hard to give exact performance numbers for AES brute-forcing on an FPGA, without building a cracker, but if pipelined to one guess per clock cycle at 400 MHz (reasonable for a modern 28mm FPGA) an attacker could easily get around 4500 guesses per second — per hash pipeline,” Mr. Zonenberg notes. “Assuming at least two pipelines per FPGA, the proposed FPGA cluster would give 22.5 million guesses per second — sufficient to break a 6-character, case-sensitive, alphanumeric password in around half an hour. If we limit ourselves to lower case letters and numbers only, it would only take 45 seconds — instead of five and one-half years Apple claims brute-forcing on the phone would take. Even 8-character alphanumeric, case-sensitive passwords could be within reach (about eight weeks on average, or faster if the password contains predictable patterns like dictionary words).”
In other words, a clever and determined adversary will find a way in. There is no fool-proof, impregnable system out there — in the Internet of Things. V/R, RCP
No comments:
Post a Comment