Hacker Claims To Have Decrypted Apple's Secure Enclave Processor Firmware (iclarified.com)

← Back to Stories (view on slashdot.org)

Hacker Claims To Have Decrypted Apple's Secure Enclave Processor Firmware (iclarified.com)

Posted by BeauHD on Thursday August 17, 2017 @10:00AM from the mobile-security dept.

According to iClarified, a hacker by name of "xerub" has posted the decryption key for Apple's Secure Enclave Processor (SEP) firmware. "The security coprocessor was introduced alongside the iPhone 5s and Touch ID," reports iClarified. "It performs secure services for the rest of the SOC and prevents the main processor from getting direct access to sensitive data. It runs its own operating system (SEPOS) which includes a kernel, drivers, services, and applications." From the report: The Secure Enclave is responsible for processing fingerprint data from the Touch ID sensor, determining if there is a match against registered fingerprints, and then enabling access or purchases on behalf of the user. Communication between the processor and the Touch ID sensor takes place over a serial peripheral interface bus. The processor forwards the data to the Secure Enclave but can't read it. It's encrypted and authenticated with a session key that is negotiated using the device's shared key that is provisioned for the Touch ID sensor and the Secure Enclave. The session key exchange uses AES key wrapping with both sides providing a random key that establishes the session key and uses AES-CCM transport encryption. Today, xerub announced the decryption key "is fully grown." You can use img4lib to decrypt the firmware and xerub's SEP firmware split tool to process. Decryption of the SEP Firmware will make it easier for hackers and security researchers to comb through the SEP for vulnerabilities.

111 comments

Min score:

Reason:

Sort:

First! by Anonymous Coward · 2017-08-17 10:06 · Score: -1

First!
1. Re:First! by Anonymous Coward · 2017-08-18 00:28 · Score: 0
  
  Too late I am!
2. Re: First! by Anonymous Coward · 2017-08-18 06:19 · Score: 0
  
  It is the usual master key punishment the world we live in deals us, and we can get it for laziness and stupidity. Apple are suffering it for using a static key to encrypt their security module firmware. Now the security module code will be examined for vulnerabilities of which there will be a bunch. People might be able to rescue Error-53 phones too after this, so this is a real tangible loss for Apple right there.
Not really a surprise by gweihir · 2017-08-17 10:06 · Score: -1

While this is clearly an advanced exercise, there are enough people with the smarts, the education and the opportunity needed to do this. And since they make an instant name for themselves in the security-community, there is also ample motivation.
So congratulations! But really, it was only a question of time.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
1. Re:Not really a surprise by Anonymous Coward · 2017-08-17 11:16 · Score: 0
  
  And since they make an instant name for themselves in the security-community, there is also ample motivation.
  Oh cool so I should include a "secret hacker handle" section on my resume and claim to be the anonymous hacker known as "xerub" and apply to all the security companies?
2. Re:Not really a surprise by cryptizard · 2017-08-17 11:23 · Score: 5, Interesting
  
  I would say it is at least a little surprising. I can't find anywhere where it is described how the key was obtained, but it is large enough that it couldn't have been brute forced. And, ostensibly, it only exists inside the secure enclave and in Apple's care. A breach in either place would be surprising.
3. Re:Not really a surprise by viperidaenz · 2017-08-17 12:15 · Score: 1
  
  It could have been brute forced, and the guy just got lucky.
4. Re:Not really a surprise by cryptizard · 2017-08-17 12:56 · Score: 0
  
  I mean, it would be roughly the same chances as you buying one lottery ticket and it being the winning one every day of your life for 100 years. So... probably not.
5. Re: Not really a surprise by Anonymous Coward · 2017-08-17 13:00 · Score: 0
  
  Probably not, but still possible.
6. Re:Not really a surprise by alvinrod · 2017-08-17 13:03 · Score: 2
  
  You just don't understand just how lucky he would have to get. I don't know what key size Apple is using but AES supports up to 256-bit keys. Here's a quote from HHGTG:
  
  Space is big. Really big. You just won't believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it's a long way down the road to the chemist, but that's just peanuts to space.
  2^256 is just as massive. The lower bound for the estimated number of atoms in the known observable universe is 10 ^ 78, which is only slightly more than the number of combinations you can have with a 256-bit key. So everything that exists in that really big space is only slightly more numerous than the possible combinations for one key.
  
  It's way more likely that someone who designed the secure enclave made a mistake while doing so that left the system open to attack.
7. Re: Not really a surprise by cryptizard · 2017-08-17 13:16 · Score: 2
  
  There are a lot of things that are possible but so unlikely that they aren't worth talking about. A colony of ants could randomly spell out the encryption key in the dirt but it is so stupidly unlikely that nobody is going to bother making a post about it. Brute forcing a 256-bit encryption key is the same thing.
8. Re:Not really a surprise by viperidaenz · 2017-08-17 13:20 · Score: 1
  
  yeah... hence the <em> tags around "could"
9. Re:Not really a surprise by arglebargle_xiv · 2017-08-17 13:53 · Score: 1
  
  ostensibly, it only exists inside the secure enclave
  If they're referring to unmodified TrustZone then it's secure by emphatic assertion of Arm's marketing department. "This bit is secure, because we've said it is". I don't know whether Apple have made further changes or done their own firmware, but hacking TrustZone isn't that hard.
10. Re:Not really a surprise by arglebargle_xiv · 2017-08-17 14:01 · Score: 1
  
  Following up to my own post: OK, it's not (don't)TrustZone but a distinct processor. Well done Apple for doing it properly (although this ref then claims it's just TrustZone, which doesn't seem to be the case).. I'm assuming the guy found a flaw in the SEP, which for example has it's own I/O lines for GPIO, SPI, I2C, etc, so you've got a large attack surface and direct access to the CPU.
11. Re: Not really a surprise by Anonymous Coward · 2017-08-17 14:07 · Score: 0
  
  Pretty sure they could figure out you don't have that skill within three questions.
12. Re: Not really a surprise by TheOuterLinux · 2017-08-17 14:51 · Score: 1
  
  First of all, love the H2G2 quote, but I think AES supports 512. It's the default level of encryption OpenSUSE asks during installation; it actually says "AES 512" on the screen. I could be wrong or misunderstanding, but that's what the installer says and my system immediately asks for a password before mounting my swap and home partitions during boot.
13. Re:Not really a surprise by gweihir · 2017-08-17 15:02 · Score: 1
  
  I would recommend reading "Hacking the Xbox" by Bunny. Also, most of the security community assumes that an attacker with physical access will get in eventually, with the only possible exception being a real HSM (at, say, $50'000 and up per piece). A HSM would eventually get hacked as well I expect, but they are too expensive and too uninteresting (due to very limited deployment) for that to happen.
  I do hope we get a detailed write-up of the hack, these are always pretty interesting.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
14. Re:Not really a surprise by gweihir · 2017-08-17 15:04 · Score: 2
  
  Unless you believe in magic, not really.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
15. Re: Not really a surprise by BDeblier · 2017-08-17 16:54 · Score: 1
  
  You are wrong. AES supports either a 128 bit or 256 bit key.
16. Re:Not really a surprise by Anonymous Coward · 2017-08-17 17:54 · Score: 0
  
  Bruteforced keys do not "grow". You do not get "partial" results.
  So, just forget bruteforcing. That was not the way.
17. Re: Not really a surprise by Anonymous Coward · 2017-08-17 17:55 · Score: 1
  
  On filesystems, there's one method of setting it up that basically requires two keys: this is sometimes called (whatever) 512 for a 256 bit key. So "AES-512", while not accurate, is how some people have read AES-256 XTS, with one 256 bit key for the cipher and one 256 bit key for the IV.
18. Re: Not really a surprise by kn · 2017-08-17 18:25 · Score: 2
  
  192 bit keys are also defined.
19. Re:Not really a surprise by TheRaven64 · 2017-08-17 20:45 · Score: 1
  
  And, ostensibly, it only exists inside the secure enclave and in Apple's care
  It only exists unencrypted there. It also exists encrypted in the firmware update blobs that Apple ships. It's entirely possible that Apple's use of encryption in their distribution chain included some flaws. This wouldn't be the first time: there was a vulnerability in FileVault2 (Apple's full-disk encryption code) caused by incorrect use of AES keys, which dramatically reduced the search space.
  
  --
  I am TheRaven on Soylent News
20. Re:Not really a surprise by Anonymous Coward · 2017-08-17 23:05 · Score: 0
  
  Challenge accepted. j/k
21. Re:Not really a surprise by deKernel · 2017-08-18 01:31 · Score: 1
  
  Actually, I would bet a true HSM (host security module) would not get hacked for the main reason that it must have physical security surrounding the key storage so if there is a physical breach, the keys are destroyed.
22. Re:Not really a surprise by gweihir · 2017-08-18 01:40 · Score: 1
  
  1. It is called "Hardware Security Module"
  2. What makes you think there is only one device involved in finding out how to bypass exactly these detectors?
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
23. Re: Not really a surprise by ctilsie242 · 2017-08-18 02:08 · Score: 1
  
  I have some people try to do "AES 512" by chaining AES, or even doing triple AES (encrypt-decrypt-encrypt) like how triple DES was done. This is brain dead, and shows the person who wrote this doesn't have a clue about crypto.
  Want more bits? Cascade different encryption algorithms, similar to how TrueCrypt/VeraCrypt does it. It is wise to use a multi-algorithm cascade anyway, because if one gets broken, there are two others. For asymmetric algorithms, same thing. Cascade RSA, some elliptic encryption, and maybe a lattice algorithm, and have each of them have a chunk of the key.
  Writing security programs and doing the job right isn't trivial. Computing is littered with many, many broken and worthless crypto programs because of people trying to reinvent the wheel, making their own worthless algorithms, or implementing existing algorithms in a brain-dead manner (ECB, for example.)
24. Re:Not really a surprise by ctilsie242 · 2017-08-18 02:13 · Score: 1
  
  Is TrustZone like a hypervisor, or is it like a LXC, managing containers/worlds? It would be nice if ARM supported VMs on the chip level with a standardized hypervisior.
25. Re: Not really a surprise by Anonymous Coward · 2017-08-18 02:24 · Score: 0
  
  "A colony of ants could randomly spell out the encryption key in the dirt"
  That explains the "ugly bags of mostly water, we need more lettuce" messages I've been seeing next to my garbage can.
26. Re: Not really a surprise by zippthorne · 2017-08-18 03:26 · Score: 1
  
  Does combining algorithims really combine the keysizes? or does it actually just have the same key size but in a third algorithm you just haven't discovered?
  
  --
  Can you be Even More Awesome?!
27. Re: Not really a surprise by ctilsie242 · 2017-08-18 03:49 · Score: 1
  
  Having two algorithms result in an unxpected third transformation is called a "group". Realistically, with TrueCrypt/VeraCrypt's cascades, you are not getting 3*256, or 768 bits, but somewhere between 258 bits and 768 bits. There is a lot of advanced crypto study on this, especially if one algorithm when used may weaken the second algorithm used after that. However, 99.99999% of the cryptographic breaks tend to be along the lines of weak key management and storage, or failure to implement existing algorithms in a secure fashion.
28. Re:Not really a surprise by TheFakeTimCook · 2017-08-18 05:26 · Score: 1
  
  Following up to my own post: OK, it's not (don't)TrustZone but a distinct processor. Well done Apple for doing it properly (although this ref then claims it's just TrustZone, which doesn't seem to be the case).. I'm assuming the guy found a flaw in the SEP, which for example has it's own I/O lines for GPIO, SPI, I2C, etc, so you've got a large attack surface and direct access to the CPU.
  From what I understand from previous flame-wars on the subject, it is NOT TrustZone-based, but rather completely home-grown by Apple. Since Apple has an Architecture-level license with ARM (one of the few companies that do), they can pretty much do what they please inside of even the ARM core, let alone any peripheral subsystems.
29. Re:Not really a surprise by deKernel · 2017-08-18 07:19 · Score: 1
  
  Well, first, since both the Thales and Futurex manuals I have refer to their own products as "host security modules", I still stand by my first statement. Second, if you actually look at the internal setup, you will notice that any attempt to breach the area where the master key is stored, the electronics are damaged to where the keys are permanently unrecoverable.
30. Re: Not really a surprise by Brockmire · 2017-08-18 08:17 · Score: 1
  
  The hacker is actually a /. editor and it was a typo meant to be "known".
31. Re:Not really a surprise by gweihir · 2017-08-18 20:06 · Score: 1
  
  Interestingly, their websites call it "Hardware Security Module", you know, like everybody else does:
  - https://www.futurex.com/produc...
  - https://www.thalesesecurity.co...
  As to you second remark, do you actually think a HSM is unhackable? That would be pretty dumb.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
32. Re: Not really a surprise by Anonymous Coward · 2017-08-18 22:20 · Score: 0
  
  I am not sure of the "typo" explanation here.
  That doesn't really match the twitter timeline.
  He first posted a portion of the key, mentioning "a key is growing":
  https://twitter.com/xerub/status/892916164657065985
  And a partial key was posted.
  Then he posted the complete key. with a "key is fully grown"
  https://twitter.com/xerub/status/897896081874329600
  And the full key was posted.
  Unless he deliberately withheld a part of the key, the key actually "grew".
  And if it did, that is incompatible with any bruteforcing that can be performed on AES.
33. Re: Not really a surprise by zippthorne · 2017-08-19 03:43 · Score: 1
  
  ...especially if one algorithm when used may weaken the second algorithm used after that.
  That is a concept I can't wrap my head around. Wouldn't that open up the possibility of using an intermediate encryption before an attack? Or is that just if you re-use the same key for the second algorithm?
  
  --
  Can you be Even More Awesome?!
34. Re: Not really a surprise by ctilsie242 · 2017-08-20 15:13 · Score: 1
  
  There might be an algorithm C which is equivilent to (A(B()). However, the chance of that is quite unlikely, especially if a proper implementation of the cipher is used (CBC, for example, or XEX), it makes this almost impossible... likely less than the chance of brute forcing the key.
  As for reusing keys, if one has three different algorithms (AES, Twofish, and Serpent), three different keys should be used. This ensures that if one of the algorithms coughs up a key somehow, the other two are still working.
Great news for law enforcement ... by perpenso · 2017-08-17 10:10 · Score: 4, Interesting

Great news for law enforcement, this should help them get through that backlog of iPhones they want to examine. :-(
1. Re:Great news for law enforcement ... by AmiMoJo · 2017-08-17 10:16 · Score: 2
  
  I've long been thinking that we need a time limited storage system for our secrets like encryption keys.
  I'd suggest storing such data in SRAM. A small capacitor can keep it powered (only needs nanoamps to maintain).
  If the phone is powered off for too long or powered but the user doesn't enter the passkey for a day or two it wipes itself.
  Prevents this kind of attack, prevents any kind of slow attack in fact.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
2. Re:Great news for law enforcement ... by Anonymous Coward · 2017-08-17 10:23 · Score: 0
  
  But at great cost if you lose your phone down the back of the sofa for a couple of days.
3. Re:Great news for law enforcement ... by networkBoy · 2017-08-17 10:24 · Score: 1
  
  I like this plan, but the SRAM itself should still be encrypted with the device key HMAC'd with some other identifier as well (PIN ideally).
  
  --
  whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
4. Re:Great news for law enforcement ... by Sarten-X · 2017-08-17 10:26 · Score: 1
  
  New standard procedure: Clip this thing onto that circuit board until the nerds arrive with their magic box.
  
  --
  You do not have a moral or legal right to do absolutely anything you want.
5. Re:Great news for law enforcement ... by ledow · 2017-08-17 10:32 · Score: 4, Insightful
  
  Suicide chips were common for a long time. And although effective are MUCH more trouble than they're worth.
  For example, you'll lose ten times more "genuine" evidence (e.g. witnesses willingly handing their phones over for evidence, then the chip dying while in court storage) than anything you'll save on personal privacy.
  Not to mention, get one duff battery/capacitor and one day your phone just stops working permanently with no possibility of restoration whatsoever.
  This isn't an attack stopped by a suicide chip, either. You buy one device, let it wipe itself a thousand times in testing, get the key out of it eventually, and then you can attack ALL the security chips in ALL the phones way within your "day or two".
  Plus, there's almost no way to ensure the timer is running. Isolate the suicide chip's clock (especially if it has to track real time and be running all the time) and you can pretty much stop it dead so it never gets to the point it can do anything about wiping the data.
  Look into the old arcade stuff. Lots of old arcade games had suicide chips. Lots of them are still emulated. In many cases, people just ignored it and - like this - determined the keys in other ways (lots of arcade games have the equivalent of rainbow tables for their encryption in common emulators because the key itself was never found), in others they de-capped and imaged the chips while they were still working, which lets you basically pluck the stored data and logic of their semiconductors out of a microscope image of the silicon.
  It's a lot of effort to go to, for a lot of risk. But what you describe is basically a proper TPM chip. I don't think anyone has ever successfully broken a TPM chip / keys, have they?
6. Re:Great news for law enforcement ... by Anonymous Coward · 2017-08-17 10:34 · Score: 1
  
  and apple will get to sell a lot more of the next model iphones with a different security scheme.
7. Re: Great news for law enforcement ... by Anonymous Coward · 2017-08-17 10:36 · Score: 0
  
  Because it takes days to search a sofa?
8. Re:Great news for law enforcement ... by AmiMoJo · 2017-08-17 10:55 · Score: 1
  
  It's certainly not for everyone. The clock thing is a non issue though. Ultra low power RC oscillator on chip, only +/-30% but that's all you need to measure a couple of days approximately. Protected the same way as the secure enclave.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
9. Re:Great news for law enforcement ... by AmiMoJo · 2017-08-17 11:01 · Score: 1
  
  There is nothing you could attach that would extend the time limit. Also, cops aren't going to take the phone apart and connect stuff to the PCB.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
10. Re:Great news for law enforcement ... by Kjella · 2017-08-17 12:08 · Score: 1
  
  If the phone is powered off for too long or powered but the user doesn't enter the passkey for a day or two it wipes itself.
  And when you end up in the emergency room because you were in a traffic accident you'll find that everything you had on your phone is gone forever. For the vast majority the problem is they lose information because they don't have backups and forget keys. The second biggest problem is that the user is hacked, tricked or forced so the attacker has the user's credentials, doesn't matter how good the lock is if the attacker has the key. If you're trying to hack a locked iPhone you're a little bit past script kiddies trying to steal celeb nudes, I'm think law enforcement, military intelligence and industrial espionage.
  If you really care about all the exotic ways to preserve the information and the possibility that someone will eventually break down the locks I'd suggest to move the problem outside the phone, crypto-virus style. Basically, you upload the decryption key to a remote server via TOR. That server will wipe the key after a given period of time. The FBI/CIA/NSA can store the phone all they like, unless they can find the remote server and stop it from deleting the key before it expires, the key is permanently gone. Of course you could XOR it with a local self-destructing key, if either half is lost/unavailable it's gone.
  
  --
  Live today, because you never know what tomorrow brings
11. Re: Great news for law enforcement ... by Anonymous Coward · 2017-08-17 12:08 · Score: 0
  
  Yes because every slashdotter is a highly paid middle aged middle manager and we all have extra large sofas on account of our high status in life.
12. Re: Great news for law enforcement ... by Anonymous Coward · 2017-08-17 12:34 · Score: 0
  
  This will not help law enforcement break into a locked device. The SEP is a completely separate SoC that is not really accessible from the application processor except through the kernel. Which if you have access at that level you are already owned.
  Law enforcement would be better off trying to find an exploit in the kernel USB stack or in the lockdown daemon that talks to iTunes to get into a locked device.
13. Re: Great news for law enforcement ... by Anonymous Coward · 2017-08-17 12:45 · Score: 0
  
  And when you end up in the emergency room because you were in a traffic accident you'll find that everything you had on your phone is gone forever.
  
  That's less than the number of people who lose/damage their phones beyond recovery.
  Just because you found one counter example doesn't mean it's a bad idea.
  People cut themselves accidentally every day. Does that mean we should ban knives in kitchens around the world?
14. Re: Great news for law enforcement ... by Anonymous Coward · 2017-08-17 13:39 · Score: 0
  
  Oh, in that case you can just buy a new phone. Cuz we all know you are just lazy and probably fat too with that "high status" bullshit.
15. Re: Great news for law enforcement ... by arglebargle_xiv · 2017-08-17 18:49 · Score: 1
  
  The SEP is a completely separate SoC that is not really accessible from the application processor except through the kernel.
  And through several hundred pins on the chip, and its I/O ports and protocols, and its boot loader, and its memory, and the shared memory areas with the AP, and ...
16. Re: Great news for law enforcement ... by Anonymous Coward · 2017-08-17 18:52 · Score: 0
  
  I forgot a phone at a place I couldn't visit for a week, behind a lock only I could open. This summer I didn't have any reason to use my work phone for a month, and forgot to check that the charger cable was plugged all the way in.
17. Re: Great news for law enforcement ... by Anonymous Coward · 2017-08-17 19:02 · Score: 0
  
  When I drop a phone out of my own clumsiness, I accept the loss.
  When it dies permanently because I don't baby it by keeping it on and charged when I have better things to do, I rage at the idiotic manufacturer. This feature is incompatible with real-world humans.
18. Re:Great news for law enforcement ... by AmiMoJo · 2017-08-17 19:38 · Score: 1
  
  I generally don't worry too much about losing the information on my phone, because I cross borders regularly and have to backup and wipe it anyway. Encrypted backups stored on my server mean I don't need to carry sensitive stuff through border security.
  My main concern is that an attacker gets hold of the phone before I can sanitize it. I want to be able to store private information on it, but obviously can't if it isn't secure.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
19. Re:Great news for law enforcement ... by Bob+the+Super+Hamste · 2017-08-18 00:20 · Score: 1
  
  If wanting to store private info on your phone I would consider something like OpenKeychain. While not a nice as VeraCrypt as OpenKeychain will leak info since it encrypts and decrypts to and from a file it is still better than nothing. Unfortunately I haven't found anything like VeraCrypt for android that will create an encrypted file that can be mounted as a file system. If anyone knows of one I am sure others would like to know about it.
  
  --
  Time to offend someone
20. Re: Great news for law enforcement ... by k2r · 2017-08-18 02:08 · Score: 1
  
  No, having access to the unencrypted firmware does only make a system less secure if you believe in security by obscurity.
  This will make the system MORE secure in the end.
21. Re:Great news for law enforcement ... by Anonymous Coward · 2017-08-18 02:28 · Score: 0
  
  Why not a shared storage system? A bunch of people have an app on their phones. You have a private key that gets split apart among them, with some recovery, so say 7 out of 11 pieces are needed to reassemble the key. Before the key is recovered, it is stored on the other devices with a manifest to not allow it to be recovered unless some rules are met (valid/expiration dates, a passphrase that is hashed, etc.) Add another rule to destroy the key if another hash is sent, then one has an ideal duress system, and because it is distributed, this ensures that compromise of 1-2 devices won't allow the key to be revealed.
22. Re: Great news for law enforcement ... by Brockmire · 2017-08-18 08:25 · Score: 1
  
  In future versions. Many of them. Do they still get jailbroken every version?
A LUDDITE chip in an APP device?! by Anonymous Coward · 2017-08-17 10:12 · Score: -1

The modern app appers at Apple should know better than to use LUDDITE chips in their modern app apping device! That's the only reason why LUDDITE hackers have hacked it!

Apps!
1. Re: A LUDDITE chip in an APP device?! by Anonymous Coward · 2017-08-17 10:35 · Score: -1
  
  A day without you is like a day without sunshine.
2. Re: A LUDDITE chip in an APP device?! by Anonymous Coward · 2017-08-17 17:58 · Score: 0
  
  He is the best slashdot troll. Though I admit to smiling at the "where are my cock eggs" cracks too.
3. Re: A LUDDITE chip in an APP device?! by Anonymous Coward · 2017-08-18 03:40 · Score: 0
  
  Doesn't seem like the real guy. Too many words that are not "app" derivatives.
Honest Question by Anonymous Coward · 2017-08-17 10:24 · Score: 0

Maybe I'm out of the loop but please humor me on this one:
WHY do people post vulnerabilities? Especially choosing to not reach out to company beforehand?
- to embarrass the company?
- to make money somehow?
- for e-peen or digi-cred?
- or finally, just because they can?
If I find someone's wallet I look for the drivers license address & fucking mail them their wallet. I don't take out a billboard & announce to the world that their dumb-ass lost their wallet. What's with posting the numerous & infinately INEVITABLE loopholes in systems?
thx- genuinely curious.
1. Re:Honest Question by Anonymous Coward · 2017-08-17 10:34 · Score: 1
  
  Could be many reasons. I would rather they communicate to the company first, then publish. But it's better to get the knowledge out there. Vulnerabilities that are hidden are ripe for zero day exploits. Those can be abused by criminals, law enforcement, and intelligence agencies.
  But getting credit for it is probably what most hackers want. Curiosity is a large part of it. Money, maybe. Embarrass the company is likely low on the list.
2. Re: Honest Question by Anonymous Coward · 2017-08-17 10:36 · Score: 3, Informative
  
  Will firstly there is no vulnerability here.
  This does not effect the ability of the secure enclave to protect the user, it does not help law enforcement or any one to crack user data.
  This is simple the code of what it does. If upon examination someone finds a vulnerability, then presumably they will let apple know...
3. Re:Honest Question by turkeydance · 2017-08-17 10:38 · Score: 4, Informative
  
  to get a job. (either ethical or criminal) "i did this, which means i'm good". show me the money.
4. Re: Honest Question by Anonymous Coward · 2017-08-17 10:40 · Score: 2, Informative
  
  Because just saying "look at this bug I found" gets you ignored.
  If you want the problem solved, you give everyone a tool to exploit it for the quickest fix. Also, even going that far, you may still be ignored.
5. Re:Honest Question by Anonymous Coward · 2017-08-17 11:23 · Score: 0
  Hackers: Heroes of the Computer Revolution
  Hacker Ethic:
  Access to computers—and anything which might teach you something about the way the world works—should be unlimited and total. Always yield to the Hands-on Imperative!
  All information should be free.
  Mistrust authority—promote decentralization.
  Hackers should be judged by their hacking, not bogus criteria such as degrees, age, race or position.
  You can create art and beauty on a computer.
  Computers can change your life for the better.
6. Re: Honest Question by Anonymous Coward · 2017-08-17 12:38 · Score: 0
  
  All of the above and one more: to put pressure on the company to actually fix it. Some companies ignore vulnerabilities that are privately reported. Putting it out in the open is sometimes the only way to get it fixed.
  But this is not a vulnerability. Itâ(TM)s actualky good for security because now researchers can investigate it for vulnerabilities.
7. Re: Honest Question by Anonymous Coward · 2017-08-17 12:57 · Score: 0
  
  You WANT people to post these disclosures. Because the first person to POST an exploit is rarely the first to USE the exploit.
8. Re: Honest Question by Jesus+H+Rolle · 2017-08-17 16:59 · Score: 1
  
  You forgot one: No girls allowed!
9. Re: Honest Question by AmiMoJo · 2017-08-17 22:31 · Score: 1
  
  If upon examination someone finds a vulnerability, then presumably they will let apple know...
  Or sell it for a million on the vulnerability market.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
10. Re:Honest Question by Anonymous Coward · 2017-08-17 22:59 · Score: 1
  
  Mistrust authority—promote decentralization.
  You'll love this Hacker Ethic until one day when your own and your loved ones' personal details are hacked and uploaded to torrent or reddit.
11. Re:Honest Question by Anonymous Coward · 2017-08-18 02:36 · Score: 0
  
  Perhaps to get the company to fix their shit. If you tell them the bug, you will get served with a gag order in the mail, and it won't get addressed, or you might even get arrested for a CFAA violation here in the US. However, if you post it for the world to see, the company will actually get around to fixing it.
  Remember: Security has no ROI. It takes a fire lit under a business's derriere, be it PR, compliance, legal, or other means for them to lift a finger to fix something.
12. Re:Honest Question by Anonymous Coward · 2017-08-18 05:27 · Score: 0
  
  >Computers can change your life for the better.
  Yes, they've been saying that.
  How about when you call customer service & they say "thanks for your patience our computers are sooo slow".
  You can only answer with "Yeah I understand, my work's computers are the same, haahaa. Putting all our trust, daily interactions, and infrastructure on computer- the wave on the future!"
  Computers are great for storing, duplicating, and sharing data. But our lives are WAYYYYY too dependant on them, jeesh.
Welp by Anonymous Coward · 2017-08-17 10:25 · Score: 0

He's a hacker, therefore a criminal, therefore lock him up already, it's the law.
This is great! by Gravis+Zero · 2017-08-17 10:46 · Score: 2

What people aren't grasping is that this is actually good news. When someone breaks security, it forces the device maker to improve their security tactics (lest they be considered insecure devices). The result is that people will get better security. The same is not true about cell towers because telecom companies don't care if your shit is insecure. :/

--
Anons need not reply. Questions end with a question mark.
1. Re:This is great! by cryptizard · 2017-08-17 11:21 · Score: 5, Informative
  
  To clarify though, no security was actually broken here. All he did was decrypt an obfuscated portion of the firmware. This may lead to some vulnerabilities in said firmware being discovered, but as of yet iOS is just as secure as it was yesterday.
2. Re:This is great! by Anonymous Coward · 2017-08-17 11:46 · Score: 0
  
  " telecom companies don't care if your shit is insecure"
  I am amazed at the number of people who actually think they have secrets somebody or some agency give a shit about. Everyone is acting like they are protecting the "nuclear launch codes" in a spreadsheet saved on their computer. The government already has enough information to identify and produce a dossier on the vast majority of citizens. They hardly need to waste resources trying to collect information they already have. Ever filed a tax return? Do you have a drivers license? Is your personal property registered with your local or state government? Have you ever applied for a marriage license? Have you ever applied for a government backed mortgage loan? How about applied for a government backed student loan? Do you receive power and water utility services from your local state, county, or city provider? Ever had to provide information for a background check before purchasing a firearm? Ever been required to submit to a government security clearance and background check? The list goes on and on and on. No law enforcement agency needs a warrant to get access to all the data collected in the above noted cases. You can not live a normal life in today's society and expect anonymity. Now privacy is different. Privacy is the government not publishing every single piece of data they have collected on you in an unrestricted private forum? Privacy is not collecting and storing every piece of transactional data you generate everyday. Collecting personal phone taps and personal e-mails without a warrant is a breach of privacy and a breach of your 4th Amendment rights. Contrary to the popular rhetoric law enforcement agencies do need a court issued warrant if they want access to any of your property, which would include any computing devices. If a warrant is provided it is no secret that the government and law enforcement agencies have the resources to gain access even when the user does not provide password or similar information. If law enforcement gets a warrant to search your house and you do not unlock the door or open a window it is perfectly legal for them to break down the door or window and enter your house.
3. Re:This is great! by Anonymous Coward · 2017-08-17 12:04 · Score: 0
  
  I expect complete anonymity on slashdot. Is that not normal?
4. Re: This is great! by Anonymous Coward · 2017-08-17 13:52 · Score: 0
  
  You don't fucking get it.
  Government doesn't give a damn about you or some stupid laws you think protect you. They want your money. And they will imprison, torture, and kill you for it if they have to.
5. Re:This is great! by Khyber · 2017-08-17 15:13 · Score: 1
  
  Decryption was essentially negated. That's breaking a layer of security if there ever was one. Otherwise, why would the encryption be in place in the first place? That is the point of encryption, correct? To secure things?
  
  --
  Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
6. Re:This is great! by tlhIngan · 2017-08-17 19:17 · Score: 1
  
  Decryption was essentially negated. That's breaking a layer of security if there ever was one. Otherwise, why would the encryption be in place in the first place? That is the point of encryption, correct? To secure things?
  A minor form. The secure enclave doesn't actually have to be encrypted, it could just be signed. All you need to know is when you start up, you verify that the image is properly signed and then you start the processor up. Encryption makes it so you don't actually have to verify it decrypted correctly - if someone tampered with the firmware, then the secure processor will crash. This lets you bypass a potential weakness in signature verification - it all boils down to a simple comparison in the end - does, and if you power spike the CPU at the right time, you might be able to tilt the comparison in your favor. With an encrypted blob, you're not doing a verification check - if it decrypts incorrectly, it will crash. On startup, the secure enclave can do a simple checksum of its image as well to make sure it decrypts correctly or lock up. But if you tampered with the encrypted blob, and it corrupted the image self-check, then at some point it will hit garbage and throw an exception.
  It's not a huge deal it was decrypted, because presumably you cannot use the key to encrypt your own firmware. In fact, it's a good thing - one can analyze it for security flaws. As long as you can't inject your own firmware in (no encryption key) the system security is not compromised by release of the decryption key. The only compromise would come from bugs in the decrypted firmware, which is a good thing.
7. Re:This is great! by v1 · 2017-08-18 00:11 · Score: 4, Interesting
  
  Decryption was essentially negated. That's breaking a layer of security if there ever was one.
  This was a small shade of "security through obscurity" but is only a thin veil. The performance of GOOD security or cryptography isn't affected by exposure of its methods. Like you see in the movies, where the criminals get the floorplan of the vault, the schedule of the guards, placement of the cameras etc etc, and manage to come up with a plan. That means the security was actually quite poor. They should have looked at it and said "Well... I guess there's just NO way to break into this place without getting caught." Now that still doesn't mean they publish their guard's schedule on the web page.
  The reason of course is that vulnerabilities may (and usually DO) still exist, and obfuscation or hiding of your security information does help a bit to mitigate that, but should not be seen as a solution. That's why good security is constantly changing and improving itself.
  You could even look at this as a good thing for them. Hackers love a challenge. A few of them will find a few holes, and publish them. (either for the credit, or the bounty, or on the darkweb etc) And any of those that are made public will get patched. There'll still be a few zero-days, the kind that either lurk in the kernel for years in plain sight without being discovered (think ShellShock) or the kind that teams of state-actors dig up and use for espionage. (think NSA dump)
  
  Otherwise, why would the encryption be in place in the first place? That is the point of encryption, correct? To secure things?
  In this case, there are two types of encryption going on. One is just obfuscation. The reason is that the key is there. The hardware decrypts the firmware and runs it. It has to be able to decrypt it unless you're going to key in a 128/256 bit key every time you turn on your phone, hence the symmetrical cipher. So it may as well not really even BE encrypted. To say you "negated" something that was already negated is silly. I wouldn't even call this "encrypted". The key is right there, so it's really more "encoded" than "encrypted". "Encrypted" means you know the process but you need the key, "encoded" means you have the key (if there even is one) but you need to figure out the process.
  The other encryption, the Asymmetric one, is the one that signed the firmware. The hardware decrypts the firmware, then checks the signature to make sure it hasn't been changed. No amount of searching the hardware or firmware will reveal the code to do the signing, as it doesn't exist. The public key is there, but not the private key. Now if the hackers had figured out THAT one, okay, NOW you can call it actually hacked. This wasn't hacked, it was simply researched. BIG difference.
  TL/DR time?
  OK that was a bit long-winded (but necessary) groundwork. What does this mean for ME? It's always safest to assume that people can and will do anything that's reasonably possible to be done. Digging out the obfuscation key is just something that's going to happen sooner or later. Where does that leave us? Since there's no private key to be dug out, and the crypto that's used in the signing isn't going to be brute-forced anytime soon, here's your options on how to leverage the firmware:
  1) you could find a bug in it that you can take advantage of. Maybe a timing condition or a race. Maybe a back door. (VERY unlikely in this case) For example, they may find that if you wait EXACTLY 83 seconds between passcode attempts, there's a bug in the firmware that doesn't increment the attempt count toward a device wipe. LEA would find this useful, and someone would make a lego mindstorm or arduino contraption that would guess your pin in a few weeks. (go look for the Garmin ones on youtube) They may even find a way to get it to unlock without the correct code, but this is far less likely. (though not com
  
  --
  I work for the Department of Redundancy Department.
8. Re:This is great! by Anonymous Coward · 2017-08-18 02:36 · Score: 0
  
  It hasn't worked with SS7 yet. Everything is still available from everywhere if you are using a phone.
9. Re:This is great! by Anonymous Coward · 2017-08-18 03:41 · Score: 0
  
  I do not think "TL/DR" means what you think it means
10. Re: This is great! by Brockmire · 2017-08-18 08:28 · Score: 1
  
  To clarify, there was no sex. He just put his penis in her vagina, moved around a bit. In 9 months there will be a result of this no sex.
11. Re:This is great! by Anonymous Coward · 2017-08-18 09:42 · Score: 0
  
  Or, the attack vector I would choose:
  - Use a known good access (my phone, my finger), see what bits transfer between for "success"
  - Get a few different bad passes to see if there is some sort of CRC / checkdigit going on for fail / success.
  - Emulate the success bits on the bus when you want in.
  Granted, different teams think of different vectors; and I know nothing about this hardware chain, but you had some lovely options that inspired my imp.
Interesting by Anonymous Coward · 2017-08-17 10:56 · Score: 0, Offtopic

That's the same key I use on my luggage.
Is this all iPhones, or just iPhones 5s? by Proudrooster · 2017-08-17 10:58 · Score: 2

Phone Wiki
1. Re:Is this all iPhones, or just iPhones 5s? by MatthiasF · 2017-08-17 11:30 · Score: 2
  
  I am assuming each version of the iPhone SEP firmware is encrypted with it's own unique key, so we're talking just iPhone 5s with this particular version of firmware I think, unless I'm understanding this wrong.
  
  It's a big step anyway, because once you know what's inside an encrypted file it is easier to decrypt later generations of that same file.
  
  So, hacks are probably already out there splitting up this decrypted firmware and attempting to decrypt later versions.
2. Re:Is this all iPhones, or just iPhones 5s? by Anonymous Coward · 2017-08-17 14:33 · Score: 0
  
  Its also a question of how did they do this ?
  Is it a technique unique to the 5s, did they just get incredibly lucky, or can it be applied to a broader range of devices ?
3. Re:Is this all iPhones, or just iPhones 5s? by AmiMoJo · 2017-08-17 22:30 · Score: 1
  
  I am assuming each version of the iPhone SEP firmware is encrypted with it's own unique key
  It can't be. The SEP has to decrypt it, which means it needs the decryption key. Doesn't matter if you use symmetric or public key crypto, in the end you need to store a secret key in the SEP and compromising that key means you can decrypt every bit of firmware released for it.
  This is similar to how battery management processor firmware updates work on their laptops. AES encrypted with a secret key, which they accidentally leaked themselves. The key is protected by the processor's secure memory, which has physical protections against reading it.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
4. Re:Is this all iPhones, or just iPhones 5s? by MatthiasF · 2017-08-23 14:54 · Score: 1
  
  That's how a figured it too, but I highly doubt every phone of a generation is using the same decryption key. They probably have different keys for different runs of the particular version of chipset. Can't imagine every phone of the generation has the exact same SEP chip version in it.
Great news for Trump. by Anonymous Coward · 2017-08-17 11:05 · Score: 0

Kind of ironic a nation-state couldn't do this already.
1. Re:Great news for Trump. by rogoshen1 · 2017-08-17 11:13 · Score: 1
  
  They wouldn't need to. they have all the pipe wrenches they'd ever need. (And by pipe wrenches, i mean physical pipe wrenches, as well as whatever metaphorical pipe wrenches you can think of for compelling someone's cooperation)
2. Re: Great news for Trump. by Anonymous Coward · 2017-08-17 12:48 · Score: 0
  
  The term you're looking for is: rubber hose cryptography.
  See also: thermorectalcryptanalysis.
3. Re: Great news for Trump. by Anonymous Coward · 2017-08-17 18:06 · Score: 0
  
  Oblig xkcd
NSA responds that's' so 2015 by Anonymous Coward · 2017-08-17 11:28 · Score: 2, Insightful

Given the assets available to the NSA, and their propensity to hide defects they find, I would not be surprised if this was already known to the NSA.
THIS PROVES THERE IS A GOD! by Anonymous Coward · 2017-08-17 13:08 · Score: 0

and he lives in HELL!!
Ah Ha! We Now Know ... by Anonymous Coward · 2017-08-17 14:48 · Score: 0

We now know why iOS is so slooooooooooooooow!
Among other things iOS transfers our Loli images in Pictures to the FBI But the FBI chaps get so "worked up" that the "directories and images" get flushed down the toilet with the Kleenex tissues!
Haa hhahaha
What does 'apple root certificate' do? by Anonymous Coward · 2017-08-17 16:40 · Score: 0

What does the 'apple root certificate' do?
If a nation state had a copy of the root certificate, would that be equal to eavesdropping capabilities?
I think there is no way NSA would not end up demanding that root certificate, or any other digital certifictate.
I wish I was an expert in this field, because I think US have a copy of all root digital certificates for the internet, making me think that TLS over HTTPS is just a joke as far as security goes. A nation state tool for surveillance that nobody talks about, though I could be wrong, because I don't know what the value of root certificates are for encrypting the web with TLS and with the use of digital certificates.
Maybe a root certificate incorporates a crypto backdoor into what one could derivatives digital certificates? Or could each digital certificate be uniquely random, so as to guarantee not having a built in backdoor into the numbers?
1. Re:What does 'apple root certificate' do? by ledow · 2017-08-17 20:13 · Score: 2
  
  I wish you were an expert in this field too.
  If the US has a copy of all root digital certificates in the world, it doesn't help them decrypt a conversation one jot.
  Those certs have a private and public key. Public keys encrypt. Private keys decrypt. You can't make/discover/etc. the private one from the public one. You literally GIVE AWAY the public key to anyone and never reveal the private one. They can then encrypt a message to you knowing that ONLY the private key can unlock that message.
  A cert is generated by:
  - Making your own private key, that you NEVER REVEAL.
  - "signing" a message that includes your public key (a "CSR" - certificate signing request). This signing does not involve ANY INFORMATION about your private key leaking. But it can be verified that ONLY your private key could have done that signing (hence it could ONLY be you signing it).
  - giving that CSR to a CA who sign it with their private key (which you never know, but can prove they own it).
  - the general public are then given copies of your public "encryption" key (if you like), which you and and the CA are signing to say are "genuine" (they ensure you own the domain you claim you do).
  AT NO POINT does the CA have, can derive, or require access to YOUR private key. They don't have any way to decrypt communications encrypted for you or by that certificate by an end-user. Your private encryption key NEVER LEAVES YOUR COMPUTER, never gets sent to a CA, is never required except on the HTTPS server itself to decrypt the messages people are sending you.
  No certificate in the world can contain a private key that will decrypt things encrypted with that public key (that you've both signed as "genuine"). If they try to fake that key, it will flag - your users will get errors, people will notice, you can even configure your DNS to tell people what the key SHOULD BE and to STOP USING IT if it ever changes.
  But the SSL certificate is nothing more than "John owns domain.com", and you saying "you can send domain.com a secret message that only domain.com can read using these details". If they fake the first, or try to change the certificate used, your users will ALL see errors in their browsers with dire warnings (even smartphones, etc. will flag if Facebook/Google are being intercepted!).
  CA's DO NOT and CANNOT decrypt your messages. Otherwise one hack of Thawte and the entire world's banking would be accessible. That's not how it works.
  The only person in the entire world who knows how to decrypt the messages you send to a TLS-secured website - without flagging up errors BEFORE you send any critical data - is the guy who created the private key that has probably NEVER left the machine he made it on. Nobody in the process from then on can hack it, derive it, fake it, replace it, change it, eavesdrop on it, or anything else.
  The US can be required to sign every .com on the planet. It wouldn't give them the keys that decrypt the messages encoded with it, and any tricks they play will flag up in any vaguely modern browser as a certificate error before you even start. You USED to be able to, say, make a fake domain.com certificate and pretend it was the genuine one. Now, with things like HSTS, public records of TLS certificates, etc. any changes made to the certificate used on a service immediately flag and error people's browsers.
  The reason nobody talks about it? Because you don't have the first clue what you're talking about. They can have the private key to every root certificate of every CA on the planet. Nothing would happen. People would still sign their certs with those CAs. And people's websites would still all be secure.
  Only idiots that don't use the modern standards to say "This is my cert, and if it ever changes without me signing the change, scream like fuck" would ever be affected, but that's literally the 90's tech that shouldn't be on the net and is using insecure algorithms anyway.
  It's people like you that genuinely think the crap about "acres of datacenters" or "listening to every phone call" actually does fuck all.
2. Re:What does 'apple root certificate' do? by Anonymous Coward · 2017-08-17 22:02 · Score: 0
  
  Well, let me put it this way instead:
  If the private key for any root certificate was known to an adversary, would they then be able to eavesdrop on your encrypted traffic?
  I think this is a fairly sensible question to ask.
3. Re:What does 'apple root certificate' do? by Anonymous Coward · 2017-08-17 22:15 · Score: 0
  
  Not knowing how computer security really work with regard to the use of TLS and digital certificates, I can easily imagine the whole system of trust using digital certificates being equal to functioning like a giant system for eavesdropping.
4. Re:What does 'apple root certificate' do? by Anonymous Coward · 2017-08-17 22:40 · Score: 0
  
  > If the private key for any root certificate was known to an adversary, would they then be able to eavesdrop on your encrypted traffic?
  Yes. It's called MITM attack. You think you talk to the other party, backed by the cert, and in reality you are talking to the Man In The Middle (who proxies to the other party, so you think all is well).
  Remember: no privacy without authenticity.
Secure architecture cuts both ways. by Anonymous Coward · 2017-08-17 18:41 · Score: 0

This "bastion within the SoC" approach (all of 'em do that somehow) seems to make a lot of sense when you think of those FBI's attempts to crack single iPhones.
When you realize that your phone vendor is in bed with their DRM vendor, or even worse, with an authoritarian government (or with both!), and that you don't own the bastion... you are happy for each and every hack like the present.
Now let's hope publishing those hacks doesn't get shut down under some DMCAish regime, or "the tarrists"/"the children".
a five year old could do it by Thud457 · 2017-08-18 07:49 · Score: 1

The way to brute force is simple and widely known.
1.Simply create a pocket universe where time run many many times faster than ours
2. drop your computer in there
3. run the brute force
5. retrieve the computer with the results from the pocket universe
6. make sure to safely deallocate the pocket universe when done.

good grief, do I have to tell you monkeys how to do everything?!!!

--
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff