Currently this is true, but with the oncoming invention and use of quantum computing, a key-recovery attack on 256-bit AES will become trivial.
Nope. Even assuming practical QC is coming, it only halves the practical key size for symmetric ciphers. 256-bit AES becomes as strong as 128-bit AES. You don't need a Universe worth of time then, just the entire power output of the Sun for a few seconds (under impossibly ideal circumstances). Still not going to happen. And that's assuming Landauer's principle applies the same way to qubits, which I'm not even sure it does - qubits might be more expensive to handle energy-wise.
QC breaks (currently in use) asymmetric crypto. It doesn't break symmetric crypto, only weakens it.
Even with 128-bit keys, keep in mind that the largest symmetric key ever broken was a 64-bit key, and that was broken by a large distributed computing project (70k hosts). For QC to break a single 128-bit crypto key (64-bit difficulty in QC), we'd need to have quantum computing power equivalent to that. That's probably half a century away - QC is in its absolute infancy. And that's for a single key. By then we'll all be using 256-bit crypto for everything and it'll be completely moot. I use 128-bit FDE at home for my most important data and I don't feel the least bit insecure. I might switch to 256-bit in a couple years when I upgrade my boxes again and then I'll be set for eternity (unless some catastrophic flaw is discovered in AES).
I'm curious though, why would you just erase the key after 10 attempts. Surely they could just add a full 13-pass erase of all the data, and reset the phone back to factory settings.
The battery wouldn't last long enough for a 13-pass erase of the data. The whole point of FDE with an erasable key is that if you erase the key you don't have to do an actual data wipe. In practice, wiping the key is as good as wiping the data. Breaking that kind of crypto is outside the threat model, and if you can do that, then there are many other things you can do that would break security in other ways. Assuming an attacker can't break AES-256 is perfectly reasonable.
Or the NSA slipped a back door into the hardware and/or software allowing them access without needing the encryption key.
Unlikely, since Apple designed the chip and it's not manufactured in the US, and Apple controls the software end to end (it's signed).
It's also quite possible the NSA purposefully created a (known only to them) weakness in AES and how it generates "random" numbers to greatly reduce the key space they would need to search.
Unlikely, since AES neé Rijndael was designed by two Belgian cryptographers, has no "magic" unexplained numbers (unlike the Dual-EC-DRBG "random" number generator that we know the NSA backdoored, or the ECDSA curves which we suspect they might have), and has been extensively cryptanalyzed. AES doesn't "generate" any random numbers. It's a block cipher.
The NSA isn't some all-powerful entity. They're a bunch of sneaky bastards, but assuming they have backdoors in anything and everything is excessive application of a tinfoil hat. Snowden said so himself: good crypto works. And Apple are a bunch of paranoid bastards.
Actually, the encryption key that would be erased is the data partition's full disk encryption key (which is not unlocked/decrypted by the PIN, it's unlocked/decrypted internally using the phone's UID key). So even though your PIN only protects user data at a higher level using a separate key (not metadata, and not all files on the phone), once your 10 attempts are gone, the entire data partition's lower level FDE key is wiped and all of it, data and metadata, is as good as gone.
Personally, I think it's perfectly fair to say that a key-recovery attack on 256-bit AES is impossible. Modulo future cryptographic breaks (which are unpredictable), with currently known attacks, you need > 2^254 operations to perform key recovery on 256-bit AES. Assuming that happens at room temperature, Landauer's principle and some back of the envelope math says you'd need the entire power output of every single star in the Milky Way for about as long as the age of the Universe just to count that high, nevermind actually try an AES decryption operation. At some point it's just silly to keep talking about things like brute force being "possible but impractical" for certain key sizes. It's impossible, saying otherwise will just confuse people who don't understand the ridiculousness of the numbers involved.
RAM-resident firmware is still firmware. Ever used a Linux machine? Ever looked in/lib/firmware? All of those are firmware files to be loaded into RAM on various devices that require RAM-resident firmware to run.
Originally I actually used the words software and firmware interchangeably in the article, because the distinction is pretty much moot with devices like the iPhone which blur the line between embedded devices and general purpose computers, but I changed them all to "firmware" for consistency, to avoid confusing someone who doesn't understand the lack of distinction in this context. The old meaning of the term "firmware" in the sense of "something programmed into a ROM" stopped applying once we got devices with re-writable memory like EEPROM and Flash. Now it just means "software for an embedded device" (usually excluding things like apps and other add-ons). It doesn't matter what kind of memory it is stored on. There are devices out there that download their firmware from the Internet every time they boot up. It's still firmware.
If you want to be technically pedantic, what the FBI wants is a custom signed restore ramdisk (and associated iBEC and iBSS to boot it) that can be loaded from DFU mode. My article deliberately avoids going into pointless minutiae about the iPhone's boot process to keep it accessible to a wider audience.
Presumably the UID is written to a memory cell on the SoC using links that open (like a fuse) when a high current is passed through (like the old PROM memories used to).
Ah, this is where it gets fun. There are actually quite a few OTP storage technologies. Fuses, like what you mention, are one. They're not necessarily on top (indeed, they'd usually be on lower, finer pitch layers, since the whole point of a fuse is that it has to be thin), though, so to read them you'd still need to strip off metallization layers, but that's just a matter of a controlled acid bath. It's not really so much about burning/melting the fuse like a traditional macroscopic one: what actually happens is accelerated electromigration of the metal trace due to excessive current density, so it's not driven primarily by temperature and there isn't a need for the fuse to be on top (and no material is emitted, just somewhat scattered outward as the metal migrates). You'd probably need a scanning electron microscope at the densities used in modern chips, but even I have access to one of those, so that's not a huge deal (turns out secondhand SEMs are cheap these days).
However, these days antifuses are common. Those work, broadly speaking, by causing a short circuit across gate oxide in a transistor using excessive voltage, or a similar technology. You can't really read those out trivially because the change is buried in a thin layer somewhere. Can you come up with a process that would make them visible to a SEM? Maybe. This is actually something I'm interested in researching, personally. But it's far from trivial (and I'm relatively clueless about silicon design).
I have no idea what technology Apple used in their SoC, though they're paranoid enough about security that they probably chose something hard to read out.
Those unique keys are probably recorded at the time of manufacture and saved to a DB (against the serial number of the phone or board).
According to Apple, they UID key is generated during manufacturing and not recorded anywhere except on the device itself.
I'd expect the software would filter out touches less than 10ms or so.
Chinese PIN cracking devices for older versions of iOS (exploiting pin attempt counter flaws no longer available) did it via USB. I think it accepts USB HID input or something dumb like that. However, the retry time is dominated by the reboot required after every rollback. So you get 4-5 tries in a few seconds, then 90 or so seconds of waiting for it to reboot. The NAND reset can be instantaneous (for a decently designed emulator), but you still need to reboot the phone. Indeed, as I mention in the blog post, this is practical for 4-digit PINs (days), 5-digit PINs (a month or so), and gets annoying for 6-digit PINs (that's closer to a year, still useful if you really want the data, but not as much).
The NV memory part is also encrypted with a key derived from a unique key fused into the CPU SoC (that is too long to be bruteforceable). To do the attack as you describe, they'd have to take the plastic off of the SoC (not the NV part, you can just pull that off the board and read it), and then use a FIB workstation to modify the metal routing and read off the fused UID key to be able to decrypt the external memory and attempt a PIN bruteforce. I explained this and other attacks here. That attack is technically possible, but unlikely, as it has a high chance of failure and it's very expensive.
What they're likely actually doing is not that. They're probably just reading off the NV (NAND Flash) memory chip, then attaching an emulator to the phone instead, performing 4-5 PIN tries using the phone itself, then rolling back the emulated memory contents and trying again. This doesn't require any silicon-level hacking, just desoldering one chip and instead soldering in a (custom, but not terribly hard to develop) NAND emulator instead.
You got the "magical black box" part right, but you got the rest wrong.
All you have to do is use a passphrase (not a PIN) long enough to not be bruteforceable. Building a 100% secure device that limits the number of attempts at guessing an insecure PIN is impossible. Building a 100% secure device that protects your data using a secure passphrase is trivial: just use good encryption at rest.
Putting data in the cloud, at best, does nothing for you security-wise, and at worst, makes it that much easier to get to. It doesn't matter whether your data is in the cloud or on your phone. What matters is that it is encrypted with strong crypto, and that only you know the key. Then, as long as the crypto isn't broken, your data is safe. No (practical) crypto is "guaranteed" to never be circumvented, but modern crypto algorithms properly implemented are getting pretty close to there being a good chance nobody will ever be able to break them in a practical manner. Only time will tell.
If you want a phone secure against data extraction after being seized, you have two decent options: get an iPhone, or get an Android Nexus phone (anything else is probably not trustworthy, if only because most other manufacturers suck at security). The Nexus line has better data security at rest (it uses full disk encryption), while the iPhone line only encrypts most, but not all, data, and no metadata. In both cases, if you make sure the phone is powered down before it falls into the hands of an attacker, there is just about nothing they can do to get at your data.
Incidentally, we're talking about symmetric crypto here, not asymmetric crypto - quantum computing can implement a practical attack against current common asymmetric crypto algorithms, but not against symmetric crypto.
And Apple also knows the Secure Enclave can be by-passed too, by anybody who has the firmware signing key.
It is also vulnerable to exactly the same external memory replay attack that non-Secure-Enclave-equipped phones are vulnerable to (i.e. the Secure Enclave is completely irrelevant to what is currently the easiest, most likely way the FBI got into the phone). I explained how all the pieces fit together in this blog post.
Which is real simple to do. Put the Secure Enclave firmware in ROM, so it can't be upgraded.
That's not the solution - Apple needs to be able to update the Secure Enclave firmware too, it's too complex to be reasonable to bake into a ROM forever. What they need to do, which I also explained in that article, is two things: tie user encryption keys to the hash of the firmware running on the SEP (so that a malicious firmware update renders user data inaccessible), and harden anti-replay protection with a secure anti-rollback counter (either using authenticated external memory or burying the EEPROM inside the main SoC package).
The Secure Enclave doesn't have "firmware updates" because it doesn't have nonvolatile firmware memory. Its firmware is loaded on every boot, and is part of the overall firmware of the phone. The Secure Enclave has no control over what firmware runs on it other than ensuring that it is signed by Apple, and it has no persistence of its own - it's a completely state-less CPU that depends on external EEPROM and Flash memory that can be externally tampered with and rolled back/replayed.
There is a very easy, very reasonable trick that is guaranteed to work to get the data out of that phone with minimal risk (assuming it has a 4-digit PIN). It's not a mistake, it's not a bug, it's not something anyone has to "discover". It's simply an attack outside the threat model that Apple used when designing that particular iPhone (and, with minor differences, all currently released iPhones). I have no doubt Apple knows full well it will work and knew it would work when they designed the phone (it's blatantly obvious, and Apple's security engineers aren't idiots) - protecting against it is just not trivial (it cannot be solved by software, it requires support hardware) so, to this date, they've chosen not to. In fact, they added a minor roadblock against it on newer phones (but only a minor one that can also be bypassed - because doing better is Hard(TM) and costs money), which demonstrates they are fully aware of it. I explained how it works here (search for "replay attack"). I'm not the first one to mention this approach.
Making iPhone secure against all physical attacks is impossible. If your PIN is bruteforceable (as is the case here), then security relies on the PIN attempt counter. An attacker with physical possession of the phone can always find a way in. Apple just has to decide how much effort (and money) they want to put into making that harder. The current bar is at approximately the "a couple experienced hardware/software hackers and a couple thousand dollars in R&D costs" level. With some more money/effort they could raise it to the "a crazy dude like Chris Tarnovsky and a medium-budget silicon hacking lab" level. It's not going to get to the "noone will practically be able to do it" level without making the iPhone into a tamper-resistant hardware security module with physical defenses (i.e. not something likely to fit in your pocket).
It still baffles me why everyone is so concerned about how the FBI got in, when we know an easy way in already.
Because this has nothing to do with link speed. SATA doesn't deliver power over the data cable, and nobody wants to put a SATA (or USB) transceiver in USB power bricks. The resistor is used to signal current supply capability between "dumb" devices. USB devices already do intelligent negotiation of current capability and speed when the other end is a host and not a wall charger.
Medical and healthcare companies consistently seem to have *no idea* whatsoever about security, and *no idea* that they actually need to hire someone who knows security.
Anything with a computer in it needs to take into account security. If you're putting code into your product and don't know security and aren't hiring someone who does, you're doing it wrong. Medical devices, cars, even Bluetooth toilets. If it communicates with the outside world or is exposed to users who aren't authorized full control over the device, it needs security. If you don't do it, your product is a ticking time bomb waiting for a researcher, if you're lucky, or a malicious attacker, if you aren't, to notice the lack of security. This will keep happening until everyone gets the message.
How exactly do you alter the kernel to stop you from running kernel code when you can already run kernel code? I'd like to hear about this magical technology that Sony has invented.
Try better reading comprehension next time. This is just code. It's not a way to run code. Therefore, Sony can't do anything about it, because there's nothing to be done. Sony can't magically make code stop being code. That's like saying Microsoft is capable of making Linux stop working on an (open) machine you choose to install Windows on.
Because it's not FreeBSD. Just because Sony based their kernel on FreeBSD doesn't mean it has a FreeBSD userland, nor does it mean you can just slap on a FreeBSD userland and make it work.
You'd have to port FreeBSD all over again - and it turns out that Linux has better off-the-shelf support for the PS4 hardware than FreeBSD does. The only reason Sony didn't use Linux is because of the license, not because it isn't easier to make work on this hardware.
Indeed, perhaps it's nothing to do with the browser at all, and it just means that Symantec can issue these certs without being considered by Mozilla (the group) in breach of some agreed to policy, but that these certs still won't we accepted (if they were seen) by Mozilla (the browser).
That is exactly what I said and exactly what this means. In fact, one of the stipulations is that the certs will be added to CRLs so that browsers explicitly distrust them.
If that is the case, then really this isn't a big deal at all. Mozilla's response just gives Worldpay a little more time to get their shit together within the current framework (the alternative, cutting them off, could be less secure, as it would probably mean Worldpay would end up rolling their own SHA1 CA and distributing that root authority to their POS terminals, perpetuating the problem indefinitely rather than giving them a short grace period to catch up)
Agreed, it's not a big deal, but it's a slippery slope. It's yet another instance of a big CA getting to bend the rules because they messed up, and it sets a precedent.
One of the arguments in the e-mail discussion thread is actually reasonable: the rules say no new SHA-1 certs issued after January 1 2016, and no certs valid for >1 year. Which meant that a ton of people got last-minute certs issued in December. Those certs are valid for the whole year of 2016. WorldPay just fucked up and forgot - had they done so they would have the whole year to upgrade their terminals.
So, in a way, a 90-day cert issued today is less of a security problem than all the last-minute certs issued right at the end of 2015. From that point of view, perhaps the rules weren't defined very well. It would've made more sense to have only a NotAfter restriction: no SHA-1 certs expiring after December 31st this year, effectively a steadily decreasing maximum validity period as the year progresses. Then this wouldn't have happened.
Still, policy is policy, and the fact that Symantec is being allowed an exception (even if that exception makes some logical sense) is concerning.
As for why they need SHA-1 certs? Old POS terminals using public CA roots, and still without SHA-256 support. Welcome to the embedded world. And yes, I'm sure they have lots of other vulnerabilities.
And this has nothing to do with trusting SHA-1 certificates in browsers. This is purely a policy issue.
Symantec isn't asking for a whitelist. They aren't asking for an exception in browser policy. They aren't asking Mozilla to trust those certificates. What they're asking for is an exception to CA policy. They are asking to violate agreed upon CA rules by "merely" issuing certificates using a weak algorithm (browsers ought not to trust these certs, but that's irrelevant, it's the fact that they're issuing them at all that breaks the rules). In effect, what they're saying to Mozilla is "we're breaking the rules, but please don't kick us out from the root store".
If Symantec goes ahead and issues the certs, then any other trust store or entity in a position to enforce CA policy requirements (such as other browser vendors, MS, etc.) is well within their right to remove trust from Symantec roots due to a violation of CA policy.
Of course, since this is Symantec, it won't happen. They're too big to fail. They'll do it anyway and get a slap on the wrist at most. This is too minor a bending of the rules for anyone to seriously propose kicking them out. That's the problem with big CAs - nobody wants to be the guy to detrust them, because then what users will see is "this browser sucks, I can't access all these sites". And so big CAs get to ignore policy or have major security breaches (I'm looking at you, Comodo) with impunity.
Apple’s implementation of security with A7+ processors and the Secure Enclave also uses ARM TrustZone architecture with rather complicated composition of encryption keys.
Correct, though it's very different from standard TrustZone. But it does use some TrustZone technology.
But there is a hardware key specific to the Secure Enclave chip and cannot be accessed or queried outside of it (I’m ignoring expensive physical xray or FIB methods etc) and is unique to each device.
True, though this mechanism is not new to the Secure Enclave. Every iPhone ever has had a fused UID key that can be used to generate derived keys and is not itself readable or accessible by software, and is unique to each device. The Secure Enclave now has its own instance of this, but the idea has been along since the original iPhone.
A piece of this is generated whenever iOS is reset or reinstalled.
That doesn't make sense. It's a fused hardware key. It never changes. You can renegerate derived keys (by storing a salt/IV that is entangled with it in use) but you can't regenerate the UID key itself. Software policy can dictate that some such derived key is regenerated during the update process, but this isn't some kind of intrinsic hardware requirement. You can always DFU boot a phone and run arbitrary signed software on the AP and the Secure Enclave without wiping anything, and perform arbitrary actions.
The Secure Enclave is a separate chip built into the SoC running its own microkernel.
A separate CPU, not a separate chip. If it's built into the SoC, it's on the same chip.
It is updated separate from the rest of iOS.
Not really, it's just another firmware component of regular iOS updates. My point is that the Secure Enclave has little control over what firmware runs on it, other than that it is appropriately signed.
but there is reason to believe Apple could alter the update process such that the Secure Enclave firmware could behave distinctly and require the PIN to be entered correctly or it wipes part of the key.
Again, you're thinking of this from the wrong perspective. What you're trying to do is reactive security: "if stuff goes wrong, wipe the key". That only works if you have an HSM. The Secure Enclave is not an HSM and has no control over its own updates. Instead, what you want is proactive security: "if the firmware that happens to be running was not authorized by the user, encryption keys are not available".
Apple previously designed the passcode/encryption in a way specifically to allow them to comply with police warrants and requests.
Citation needed here. I see no evidence whatsoever that the encryption was in any way designed to comply with police warrants. Earlier iPhones (since 3GS) only had full-disk-encryption, with a hardware-bound key that is not related to the passcode. Later, file-layer encryption was added based on the passcode, and in more recent iOS versions, that has simply been made the default so that the vast majority of user data is doubly encrypted with a key derived from the user's passcode as well as the underlying FDE. At no point do police warrants enter this design picture, it's simply an evolution of security from Apple. There was no big flip from "we have the key" to "we don't" (older iOS versions already used this mechanism before iOS 8, just not to as full an extent) - in fact both mechanisms are completely tangential, and Apple can still use their old extraction mechanism to extract all the files from the filesystem just as before, including all the metadata (filenames) and some data that wouldn't have the file-based encryption applied yet. It's just that now most files have an additional layer of encryption which requires a PIN bruteforce to break.
Since passcodes are usually short, both classes of security end up boiling down to OS policy - without the policy requiring a delay between PIN attempts, the security is laughable. Therefore, in both cases, security depends on the trustworthiness of Apple's firmware, and they have the keys to bypass it (possibly on others' behalf).
It wasn't something new they designed but already had for the purpose of complying with warrants.
They had to write a restore image that dumps the filesystem instead of doing a normal OS install (the first time they got a request). That's something new they designed to comply with warrants.
They implemented security restrictions on brute forcing in the firmware and later in the Secure Enclave hardware.
Nope. Secure Enclave is just a CPU. They implemented security restrictions on brute forcing in the Secure Enclave firmware. Which is just another firmware component signed by Apple and therefore, even on newer iPhones with a Secure Enclave, Apple can bypass the bruteforcing restrictions just as well.
The Secure Enclave is designed to protect security-sensitive operations, like file encryption and fingerprint matching, from a compromised applications processor (e.g. a jailbroken phone, or anything that similarly uses an OS-level exploit). It is not designed to protect anything against rogue firmware updates. In fact, the Secure Enclave firmware is loaded into memory on every boot and is loaded from USB during restore, just like everything else on the phone, and Apple can freely replace it to do whatever it wants. Even if the FBI had to deal with a phone with a Secure Enclave, it would make no difference to the feasibility of this request.
Although not definitively established yet, there is evidence that the Secure Enclave is firmware updateable without enter the PIN. I expect Apple will udpate this such that future firmware updates cannot be loaded without the PIN unless the hardware key is wiped. That should eliminate the feasibility of these requests.
You're thinking in the wrong terms. Everyone mistakenly seems to think the Secure Enclave is some kind of secure, independent, tamper-resistant, little HSM inside the iPhone or something. Something with its own separately updatable firmware. It's not. It's really just another CPU, designed to remain secure in the face of compromise of the main application processor. Its firmware is really just part of the main firmware on the phone, and also part of the USB DFU restore process just like everything else. It doesn't have its own flash memory or its own firmware update proc
How do you think they "unlocked" previous iOS versions? By... uploading a new version of the OS/firmware restore bundle that allows them to do that. Which is implementing a completely new capability for electronically dumping the filesystem after it has been decrypted by the FDE key.
See how it really isn't that different? Sure, in this case the FBI wants to do the bruteforcing themselves, but that is a minor detail. Either way, Apple's writing (a small amount of) code to implement a security policy bypass for law enforcement.
Slashdot Mirror
Nope. Even assuming practical QC is coming, it only halves the practical key size for symmetric ciphers. 256-bit AES becomes as strong as 128-bit AES. You don't need a Universe worth of time then, just the entire power output of the Sun for a few seconds (under impossibly ideal circumstances). Still not going to happen. And that's assuming Landauer's principle applies the same way to qubits, which I'm not even sure it does - qubits might be more expensive to handle energy-wise.
QC breaks (currently in use) asymmetric crypto. It doesn't break symmetric crypto, only weakens it.
Even with 128-bit keys, keep in mind that the largest symmetric key ever broken was a 64-bit key, and that was broken by a large distributed computing project (70k hosts). For QC to break a single 128-bit crypto key (64-bit difficulty in QC), we'd need to have quantum computing power equivalent to that. That's probably half a century away - QC is in its absolute infancy. And that's for a single key. By then we'll all be using 256-bit crypto for everything and it'll be completely moot. I use 128-bit FDE at home for my most important data and I don't feel the least bit insecure. I might switch to 256-bit in a couple years when I upgrade my boxes again and then I'll be set for eternity (unless some catastrophic flaw is discovered in AES).
The battery wouldn't last long enough for a 13-pass erase of the data. The whole point of FDE with an erasable key is that if you erase the key you don't have to do an actual data wipe. In practice, wiping the key is as good as wiping the data. Breaking that kind of crypto is outside the threat model, and if you can do that, then there are many other things you can do that would break security in other ways. Assuming an attacker can't break AES-256 is perfectly reasonable.
Unlikely, since Apple designed the chip and it's not manufactured in the US, and Apple controls the software end to end (it's signed).
Unlikely, since AES neé Rijndael was designed by two Belgian cryptographers, has no "magic" unexplained numbers (unlike the Dual-EC-DRBG "random" number generator that we know the NSA backdoored, or the ECDSA curves which we suspect they might have), and has been extensively cryptanalyzed. AES doesn't "generate" any random numbers. It's a block cipher.
The NSA isn't some all-powerful entity. They're a bunch of sneaky bastards, but assuming they have backdoors in anything and everything is excessive application of a tinfoil hat. Snowden said so himself: good crypto works. And Apple are a bunch of paranoid bastards.
Actually, the encryption key that would be erased is the data partition's full disk encryption key (which is not unlocked/decrypted by the PIN, it's unlocked/decrypted internally using the phone's UID key). So even though your PIN only protects user data at a higher level using a separate key (not metadata, and not all files on the phone), once your 10 attempts are gone, the entire data partition's lower level FDE key is wiped and all of it, data and metadata, is as good as gone.
Personally, I think it's perfectly fair to say that a key-recovery attack on 256-bit AES is impossible. Modulo future cryptographic breaks (which are unpredictable), with currently known attacks, you need > 2^254 operations to perform key recovery on 256-bit AES. Assuming that happens at room temperature, Landauer's principle and some back of the envelope math says you'd need the entire power output of every single star in the Milky Way for about as long as the age of the Universe just to count that high, nevermind actually try an AES decryption operation. At some point it's just silly to keep talking about things like brute force being "possible but impractical" for certain key sizes. It's impossible, saying otherwise will just confuse people who don't understand the ridiculousness of the numbers involved.
RAM-resident firmware is still firmware. Ever used a Linux machine? Ever looked in /lib/firmware? All of those are firmware files to be loaded into RAM on various devices that require RAM-resident firmware to run.
Originally I actually used the words software and firmware interchangeably in the article, because the distinction is pretty much moot with devices like the iPhone which blur the line between embedded devices and general purpose computers, but I changed them all to "firmware" for consistency, to avoid confusing someone who doesn't understand the lack of distinction in this context. The old meaning of the term "firmware" in the sense of "something programmed into a ROM" stopped applying once we got devices with re-writable memory like EEPROM and Flash. Now it just means "software for an embedded device" (usually excluding things like apps and other add-ons). It doesn't matter what kind of memory it is stored on. There are devices out there that download their firmware from the Internet every time they boot up. It's still firmware.
If you want to be technically pedantic, what the FBI wants is a custom signed restore ramdisk (and associated iBEC and iBSS to boot it) that can be loaded from DFU mode. My article deliberately avoids going into pointless minutiae about the iPhone's boot process to keep it accessible to a wider audience.
Assuming the "Erase data after 10 failed passcode attempts" option was enabled, no.
Ah, this is where it gets fun. There are actually quite a few OTP storage technologies. Fuses, like what you mention, are one. They're not necessarily on top (indeed, they'd usually be on lower, finer pitch layers, since the whole point of a fuse is that it has to be thin), though, so to read them you'd still need to strip off metallization layers, but that's just a matter of a controlled acid bath. It's not really so much about burning/melting the fuse like a traditional macroscopic one: what actually happens is accelerated electromigration of the metal trace due to excessive current density, so it's not driven primarily by temperature and there isn't a need for the fuse to be on top (and no material is emitted, just somewhat scattered outward as the metal migrates). You'd probably need a scanning electron microscope at the densities used in modern chips, but even I have access to one of those, so that's not a huge deal (turns out secondhand SEMs are cheap these days).
However, these days antifuses are common. Those work, broadly speaking, by causing a short circuit across gate oxide in a transistor using excessive voltage, or a similar technology. You can't really read those out trivially because the change is buried in a thin layer somewhere. Can you come up with a process that would make them visible to a SEM? Maybe. This is actually something I'm interested in researching, personally. But it's far from trivial (and I'm relatively clueless about silicon design).
I have no idea what technology Apple used in their SoC, though they're paranoid enough about security that they probably chose something hard to read out.
According to Apple, they UID key is generated during manufacturing and not recorded anywhere except on the device itself.
Chinese PIN cracking devices for older versions of iOS (exploiting pin attempt counter flaws no longer available) did it via USB. I think it accepts USB HID input or something dumb like that. However, the retry time is dominated by the reboot required after every rollback. So you get 4-5 tries in a few seconds, then 90 or so seconds of waiting for it to reboot. The NAND reset can be instantaneous (for a decently designed emulator), but you still need to reboot the phone. Indeed, as I mention in the blog post, this is practical for 4-digit PINs (days), 5-digit PINs (a month or so), and gets annoying for 6-digit PINs (that's closer to a year, still useful if you really want the data, but not as much).
The NV memory part is also encrypted with a key derived from a unique key fused into the CPU SoC (that is too long to be bruteforceable). To do the attack as you describe, they'd have to take the plastic off of the SoC (not the NV part, you can just pull that off the board and read it), and then use a FIB workstation to modify the metal routing and read off the fused UID key to be able to decrypt the external memory and attempt a PIN bruteforce. I explained this and other attacks here. That attack is technically possible, but unlikely, as it has a high chance of failure and it's very expensive.
What they're likely actually doing is not that. They're probably just reading off the NV (NAND Flash) memory chip, then attaching an emulator to the phone instead, performing 4-5 PIN tries using the phone itself, then rolling back the emulated memory contents and trying again. This doesn't require any silicon-level hacking, just desoldering one chip and instead soldering in a (custom, but not terribly hard to develop) NAND emulator instead.
You got the "magical black box" part right, but you got the rest wrong.
All you have to do is use a passphrase (not a PIN) long enough to not be bruteforceable. Building a 100% secure device that limits the number of attempts at guessing an insecure PIN is impossible. Building a 100% secure device that protects your data using a secure passphrase is trivial: just use good encryption at rest.
Putting data in the cloud, at best, does nothing for you security-wise, and at worst, makes it that much easier to get to. It doesn't matter whether your data is in the cloud or on your phone. What matters is that it is encrypted with strong crypto, and that only you know the key. Then, as long as the crypto isn't broken, your data is safe. No (practical) crypto is "guaranteed" to never be circumvented, but modern crypto algorithms properly implemented are getting pretty close to there being a good chance nobody will ever be able to break them in a practical manner. Only time will tell.
If you want a phone secure against data extraction after being seized, you have two decent options: get an iPhone, or get an Android Nexus phone (anything else is probably not trustworthy, if only because most other manufacturers suck at security). The Nexus line has better data security at rest (it uses full disk encryption), while the iPhone line only encrypts most, but not all, data, and no metadata. In both cases, if you make sure the phone is powered down before it falls into the hands of an attacker, there is just about nothing they can do to get at your data.
Incidentally, we're talking about symmetric crypto here, not asymmetric crypto - quantum computing can implement a practical attack against current common asymmetric crypto algorithms, but not against symmetric crypto.
It is also vulnerable to exactly the same external memory replay attack that non-Secure-Enclave-equipped phones are vulnerable to (i.e. the Secure Enclave is completely irrelevant to what is currently the easiest, most likely way the FBI got into the phone). I explained how all the pieces fit together in this blog post.
That's not the solution - Apple needs to be able to update the Secure Enclave firmware too, it's too complex to be reasonable to bake into a ROM forever. What they need to do, which I also explained in that article, is two things: tie user encryption keys to the hash of the firmware running on the SEP (so that a malicious firmware update renders user data inaccessible), and harden anti-replay protection with a secure anti-rollback counter (either using authenticated external memory or burying the EEPROM inside the main SoC package).
Your source is an ex-Apple engineer who worked on iPhone security: https://twitter.com/JohnHedge/...
The Secure Enclave doesn't have "firmware updates" because it doesn't have nonvolatile firmware memory. Its firmware is loaded on every boot, and is part of the overall firmware of the phone. The Secure Enclave has no control over what firmware runs on it other than ensuring that it is signed by Apple, and it has no persistence of its own - it's a completely state-less CPU that depends on external EEPROM and Flash memory that can be externally tampered with and rolled back/replayed.
Of course they hacked the phone.
There is a very easy, very reasonable trick that is guaranteed to work to get the data out of that phone with minimal risk (assuming it has a 4-digit PIN). It's not a mistake, it's not a bug, it's not something anyone has to "discover". It's simply an attack outside the threat model that Apple used when designing that particular iPhone (and, with minor differences, all currently released iPhones). I have no doubt Apple knows full well it will work and knew it would work when they designed the phone (it's blatantly obvious, and Apple's security engineers aren't idiots) - protecting against it is just not trivial (it cannot be solved by software, it requires support hardware) so, to this date, they've chosen not to. In fact, they added a minor roadblock against it on newer phones (but only a minor one that can also be bypassed - because doing better is Hard(TM) and costs money), which demonstrates they are fully aware of it. I explained how it works here (search for "replay attack"). I'm not the first one to mention this approach.
Making iPhone secure against all physical attacks is impossible. If your PIN is bruteforceable (as is the case here), then security relies on the PIN attempt counter. An attacker with physical possession of the phone can always find a way in. Apple just has to decide how much effort (and money) they want to put into making that harder. The current bar is at approximately the "a couple experienced hardware/software hackers and a couple thousand dollars in R&D costs" level. With some more money/effort they could raise it to the "a crazy dude like Chris Tarnovsky and a medium-budget silicon hacking lab" level. It's not going to get to the "noone will practically be able to do it" level without making the iPhone into a tamper-resistant hardware security module with physical defenses (i.e. not something likely to fit in your pocket).
It still baffles me why everyone is so concerned about how the FBI got in, when we know an easy way in already.
Because this has nothing to do with link speed. SATA doesn't deliver power over the data cable, and nobody wants to put a SATA (or USB) transceiver in USB power bricks. The resistor is used to signal current supply capability between "dumb" devices. USB devices already do intelligent negotiation of current capability and speed when the other end is a host and not a wall charger.
Medical and healthcare companies consistently seem to have *no idea* whatsoever about security, and *no idea* that they actually need to hire someone who knows security.
Anything with a computer in it needs to take into account security. If you're putting code into your product and don't know security and aren't hiring someone who does, you're doing it wrong. Medical devices, cars, even Bluetooth toilets. If it communicates with the outside world or is exposed to users who aren't authorized full control over the device, it needs security. If you don't do it, your product is a ticking time bomb waiting for a researcher, if you're lucky, or a malicious attacker, if you aren't, to notice the lack of security. This will keep happening until everyone gets the message.
TFA says:
Which implies had 160 people to begin with, and they let 40 go, leaving them with 120. As usual, the bad math came from Slashdot.
How exactly do you alter the kernel to stop you from running kernel code when you can already run kernel code? I'd like to hear about this magical technology that Sony has invented.
Try better reading comprehension next time. This is just code. It's not a way to run code. Therefore, Sony can't do anything about it, because there's nothing to be done. Sony can't magically make code stop being code. That's like saying Microsoft is capable of making Linux stop working on an (open) machine you choose to install Windows on.
They can't remove this "ability" because this "ability" is just a piece of code that runs on any PS4 you can get kernel code to run on.
It's up to you to figure out how to run the code in the first place. That is affected by updates.
We already have 3D working. It's not production-quality but it runs real games with decent performance.
Because it's not FreeBSD. Just because Sony based their kernel on FreeBSD doesn't mean it has a FreeBSD userland, nor does it mean you can just slap on a FreeBSD userland and make it work.
You'd have to port FreeBSD all over again - and it turns out that Linux has better off-the-shelf support for the PS4 hardware than FreeBSD does. The only reason Sony didn't use Linux is because of the license, not because it isn't easier to make work on this hardware.
That is exactly what I said and exactly what this means. In fact, one of the stipulations is that the certs will be added to CRLs so that browsers explicitly distrust them.
Agreed, it's not a big deal, but it's a slippery slope. It's yet another instance of a big CA getting to bend the rules because they messed up, and it sets a precedent.
One of the arguments in the e-mail discussion thread is actually reasonable: the rules say no new SHA-1 certs issued after January 1 2016, and no certs valid for >1 year. Which meant that a ton of people got last-minute certs issued in December. Those certs are valid for the whole year of 2016. WorldPay just fucked up and forgot - had they done so they would have the whole year to upgrade their terminals.
So, in a way, a 90-day cert issued today is less of a security problem than all the last-minute certs issued right at the end of 2015. From that point of view, perhaps the rules weren't defined very well. It would've made more sense to have only a NotAfter restriction: no SHA-1 certs expiring after December 31st this year, effectively a steadily decreasing maximum validity period as the year progresses. Then this wouldn't have happened.
Still, policy is policy, and the fact that Symantec is being allowed an exception (even if that exception makes some logical sense) is concerning.
As for why they need SHA-1 certs? Old POS terminals using public CA roots, and still without SHA-256 support. Welcome to the embedded world. And yes, I'm sure they have lots of other vulnerabilities.
And this has nothing to do with trusting SHA-1 certificates in browsers. This is purely a policy issue.
Symantec isn't asking for a whitelist. They aren't asking for an exception in browser policy. They aren't asking Mozilla to trust those certificates. What they're asking for is an exception to CA policy. They are asking to violate agreed upon CA rules by "merely" issuing certificates using a weak algorithm (browsers ought not to trust these certs, but that's irrelevant, it's the fact that they're issuing them at all that breaks the rules). In effect, what they're saying to Mozilla is "we're breaking the rules, but please don't kick us out from the root store".
If Symantec goes ahead and issues the certs, then any other trust store or entity in a position to enforce CA policy requirements (such as other browser vendors, MS, etc.) is well within their right to remove trust from Symantec roots due to a violation of CA policy.
Of course, since this is Symantec, it won't happen. They're too big to fail. They'll do it anyway and get a slap on the wrist at most. This is too minor a bending of the rules for anyone to seriously propose kicking them out. That's the problem with big CAs - nobody wants to be the guy to detrust them, because then what users will see is "this browser sucks, I can't access all these sites". And so big CAs get to ignore policy or have major security breaches (I'm looking at you, Comodo) with impunity.
Correct, though it's very different from standard TrustZone. But it does use some TrustZone technology.
True, though this mechanism is not new to the Secure Enclave. Every iPhone ever has had a fused UID key that can be used to generate derived keys and is not itself readable or accessible by software, and is unique to each device. The Secure Enclave now has its own instance of this, but the idea has been along since the original iPhone.
That doesn't make sense. It's a fused hardware key. It never changes. You can renegerate derived keys (by storing a salt/IV that is entangled with it in use) but you can't regenerate the UID key itself. Software policy can dictate that some such derived key is regenerated during the update process, but this isn't some kind of intrinsic hardware requirement. You can always DFU boot a phone and run arbitrary signed software on the AP and the Secure Enclave without wiping anything, and perform arbitrary actions.
A separate CPU, not a separate chip. If it's built into the SoC, it's on the same chip.
Not really, it's just another firmware component of regular iOS updates. My point is that the Secure Enclave has little control over what firmware runs on it, other than that it is appropriately signed.
Again, you're thinking of this from the wrong perspective. What you're trying to do is reactive security: "if stuff goes wrong, wipe the key". That only works if you have an HSM. The Secure Enclave is not an HSM and has no control over its own updates. Instead, what you want is proactive security: "if the firmware that happens to be running was not authorized by the user, encryption keys are not available".
Citation needed here. I see no evidence whatsoever that the encryption was in any way designed to comply with police warrants. Earlier iPhones (since 3GS) only had full-disk-encryption, with a hardware-bound key that is not related to the passcode. Later, file-layer encryption was added based on the passcode, and in more recent iOS versions, that has simply been made the default so that the vast majority of user data is doubly encrypted with a key derived from the user's passcode as well as the underlying FDE. At no point do police warrants enter this design picture, it's simply an evolution of security from Apple. There was no big flip from "we have the key" to "we don't" (older iOS versions already used this mechanism before iOS 8, just not to as full an extent) - in fact both mechanisms are completely tangential, and Apple can still use their old extraction mechanism to extract all the files from the filesystem just as before, including all the metadata (filenames) and some data that wouldn't have the file-based encryption applied yet. It's just that now most files have an additional layer of encryption which requires a PIN bruteforce to break.
Since passcodes are usually short, both classes of security end up boiling down to OS policy - without the policy requiring a delay between PIN attempts, the security is laughable. Therefore, in both cases, security depends on the trustworthiness of Apple's firmware, and they have the keys to bypass it (possibly on others' behalf).
They had to write a restore image that dumps the filesystem instead of doing a normal OS install (the first time they got a request). That's something new they designed to comply with warrants.
Nope. Secure Enclave is just a CPU. They implemented security restrictions on brute forcing in the Secure Enclave firmware. Which is just another firmware component signed by Apple and therefore, even on newer iPhones with a Secure Enclave, Apple can bypass the bruteforcing restrictions just as well.
The Secure Enclave is designed to protect security-sensitive operations, like file encryption and fingerprint matching, from a compromised applications processor (e.g. a jailbroken phone, or anything that similarly uses an OS-level exploit). It is not designed to protect anything against rogue firmware updates. In fact, the Secure Enclave firmware is loaded into memory on every boot and is loaded from USB during restore, just like everything else on the phone, and Apple can freely replace it to do whatever it wants. Even if the FBI had to deal with a phone with a Secure Enclave, it would make no difference to the feasibility of this request.
You're thinking in the wrong terms. Everyone mistakenly seems to think the Secure Enclave is some kind of secure, independent, tamper-resistant, little HSM inside the iPhone or something. Something with its own separately updatable firmware. It's not. It's really just another CPU, designed to remain secure in the face of compromise of the main application processor. Its firmware is really just part of the main firmware on the phone, and also part of the USB DFU restore process just like everything else. It doesn't have its own flash memory or its own firmware update proc
How do you think they "unlocked" previous iOS versions? By... uploading a new version of the OS/firmware restore bundle that allows them to do that. Which is implementing a completely new capability for electronically dumping the filesystem after it has been decrypted by the FDE key.
See how it really isn't that different? Sure, in this case the FBI wants to do the bruteforcing themselves, but that is a minor detail. Either way, Apple's writing (a small amount of) code to implement a security policy bypass for law enforcement.