FBI paid professional hackers one-time fee to crack San Bernardino iPhone (video at link)

Washington Post ^ | April 12th, 2016 | By Ellen Nakashima

[Coronal]

Here’s a page describing what may have been the attack used. I lack the technical expertise to determine its feasibility.

https://deadhacker.com/2016/03/25/the-terrorists-phone/

[Swordmaker]

But if false testimony/evidence was used to get the warrant, any evidence obtained through the warrant is contaminated.

I sincerely doubt that false testimony/evidence was used to get the warrant. The problem is the means used to open the device. . . by an unqualified and uncertified to testify person.

How is using a Criminal Grey or Black hat cracker going to be useful? Any data extracted from that iPhone 5C that might result in an arrest and trial of a suspect will be hopelessly compromised by the source of the hack. The cracker is not a qualified forensic laboratory the prosecutor can bring into court to testify with any hope of surviving cross-examination. I can see how it might go down in cross examination:

“Sir, what is your certification as a Forensic IT examiner?”

“None. I’m a hacker.”

“What evidence of expertise do you bring to this court to demonstrate your ability?”

“Well, I found the vulnerability and developed the exploit that infected 100 million Android phones that allowed PirateJoe to steal $2 billion from their owners bank accounts last year! I’m pretty proud of that. He paid me $100,000 for that vuln! And just last month, I created a really cool hack into Windows 10 that bypasses their anti-virus and looks for credit card and ID info on users, then connects to a remote server. That one I sold to a guy in Siberia. It should be good for a couple of weeks before the AV people detect it when it gets put on line and Microsoft patches it. That one I got $50K for.”

“I see. So do you consider yourself a black hat or a white hat?”

“Oh, I’m more of a gray hat. I found this sorta vuln in FLASH that could kinda turn into a exploit if you looked at it sideways while playing one of their games. Adobe paid me $2000 for that one. See I play both sides. . . and of course the FBI paid me to see what I could do with this iPhone thing.”

“Given your history, why didn’t the FBI arrest you?”

“Oh, because, I told them I could open the iPhone for them. They gave me immunity for all that and paid me to boot! Twenty Grand, GREAT!”

Defense: "Your honor, this criminal is not in any way qualified to be certified an expert IT forensic examiner and his techniques are certainly not certified by any Federal court. The Defense moves to suppress the evidence from the iPhone and all results derived therefrom. We request dismissal of all charges!"

Judge: "All evidence derived from anything ensuing from evidence found in the iPhone is suppressed. . . Fruit of the poisoned tree. "

Prosecutor: "But your honor, our entire case rests on that evidence!"

Judge: "Too bad! Case dismissed! Find some evidence that does not derive from anything you found on that iPhone and bring it back! However, you've hopelessly tainted everything that was on that phone! No evidence that derives from that can be used to further your investigation! If you use any of it to further your investigation, I will dismiss the case with prejudice! "

[tioga]

Put your trust in God. Man and law will always disappoint.

[discostu]

All the FBI has to do is declare they’re confidential informants. They’ve got lots of known criminals on the payroll because they give them information on worse bad guys.

[Coronal]

When He chooses to speak on this matter, we can take that as the ultimate authority on it. Until then, going by the law is the route likeliest to produce the outcome most in accordance with His will.

[i_robot73]

>
SCOTUS In 2014, by a 9-0 vote, the justices said smart phones and other electronic devices were not in the same category as wallets, briefcases, and vehicles — all currently subject to limited initial examination by law enforcement. Generally such searches are permitted if there is “probable cause” that a crime has been committed, to ensure officers’ safety and prevent destruction of evidence.
>

Who cares one whit what tyrants in black robes decree? As if they knew their ass from their elbows in the matter of *ANYTHING* Constitutional.

Maybe they need a remedial English course. My electronic device(s) ARE my effects, as secure as my home and papers. SCOTUS can FOAD.

**

Back on point, we already know we have 2 Americas: We and govt. Ask the tax cheats Rangle/Sharpton, or Clinton vis-a-vie handling of classified material (where would YOU be by doing the same), or....

‘Legal’ matters only that which they can convict those they WISH to prosecute. Else, they can make up the rest as they go (as usual)

[Swordmaker]

Here’s a page describing what may have been the attack used. I lack the technical expertise to determine its feasibility.

https://deadhacker.com/2016/03/25/the-terrorists-phone/

That's essentially the process I outlined several months ago . . . minus a couple of issues that it ignores.

First, the iPhone 5C doesn't use a Secure Enclave. It has an earlier iteration of the technology that is actually imbedded in the Apple A6 processor called the Encryption Engine which is a dedicated co-processor.

Inside that Encryption Engine is where the count-down timer functions and encryption event occur, handled by a processor unaccessible to the data processor of the A6 and anything stored inside the Encryption Engine is unreadable by the A6's data processor. There is an EEPROM where the device specific key, the Group ID (GID), and a Unique Device ID (UDID) assigned when the processor was made and not record anywhere, and one more that the article fails to mention: a truly entropic random number generated when the user first entered his passcode constructed from data derived from the device's camera, microphone, and accelerometer. Combined with the User's passcode, these three hidden components are combined to construct the data encryption key. This key is NOT stored on the NAND but reconstructed by algorithm each time the device is accessed by passcode, so it cannot be read by anything.

Also stored in that EEPROM is a one-way hash of the user's passcode. This is stored instead of a copy of the passcode and the algorithm used to create the one-way hash recreates it each time the user inputs his passcode and that one-way hash is compared to the one in memory as a test to see if it matches. If it does, then the data encryption key is regenerated by entangling all four pieces and the iPhone is unlocked. If not, the count is iterated, and another passcode attempt is permitted. Four attempts are allowed with no delay, then several more with escalating time factors. On the tenth attempt, it is NOT the data encryption key that gets erased , but the stored one-way hash of the user's passcode, forever preventing the reconstruction of the data encryption key.

Without that user passcode part of the encryption key to entangle with the other stored pieces, the key can never be reconstructed. The only way to use the device again is to use the Apple ID and restore the data from an accessible backup.

Add in the random number, realize that those things are NOT stored on the NAND, and the described technique might work for the iPhone 5C.

However, It would be much more difficult for the iOS devices on A7 and later devices with the Secure Enclave which is much more highly protected from reading anything stored on them. . . and each of four different ICs have to be registered with each other and recognize if they have been removed by from the circuit and replaced or modified, requiring they be re-registered, a process that only Apple can do.

[taxcontrol]

Well the Constution / 4th Amendment says:

The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.

To address the requirement, the FBI showed probable cause (a crime having been committed) and and made a sworn statement to that effect and obtained a warrant.

I really don’t understand the anger / frustration towards the FBI when they followed the rules.

[Timocrat]

The new information was then used to create a piece of hardware that helped the FBI to crack the iPhone’s four-digit personal identification number without triggering a security feature

If the Black hat/Grey hat told the FBI ( and assuming the FBI is in lawful possession of the phone) how to construct the Hardware and then how to use it to crack the code, an FBI computer expert can go in to court and testify that we, the FBI, did A B C & D and bingo we cracked the code. If a person of dubious character can draw the FBI a map and the FBI then uses that map to collect evidence why is it illegal ?

[tioga]

So, manmade law is most in accordance with His will...that is the standard? Legalized slavery happened in this country, would you have turned in those helping the slaves escape via the Underground Railroad?

[taxcontrol]

Actually, when a police agency is operating under a warrant, and hires someone to perform some activity, the hired person or company becomes and “agent”, at least from the legal view, of the FBI. As such, they are held to the same level of evidence collection, safeguarding and documentation.

So if the technique was developed but the FBI techs actually executed the “hack”, then the FBI could remain in compliance with all the rules of evidence. Based upon the press release of the FBI director, this seems to be what happened.

HOWEVER

If the hack was executed by a third party, this becomes much more problematic as you pointed out.

[Coronal]

As opposed to what? A million different interpretations of Scripture? Individual consciences that will disagree on a number of things? Law isn’t perfect by any means, but in matters of how we live in this world, it’s the least bad option.

[i_robot73]

1) My reply was RE: SCOTUS, not specifically the FBI. But the latter, using the flawed/illogical decisions of the former...

2) IIRC, the original request was NOT ‘Oh, open this FOR us’, but ‘Give us the skeleton key’

3) Plus, given that the FBI used criminal elements, and PAID them, for the exploit, shows:

A) lack the capability
B) willing to break the law to suit their needs

Course, the EASIEST solution would be to NOT allow ‘em in the front door!

[Scrambler Bob]

but now they can use it in court...
= = =

Or use this phone’s alledged contents as an excuse to use it in court?

[null and void]

Yeah. That too.

[cyphunk]

Hi Coronal,
thanks for your clarifications. I wrote the deadhacker article and will be the first to admit I may have missed something. I went back and double checked the iOS documentation and I think I’m confused by your wipe description.

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

“The metadata of all files [metadata includes wrapped per-file key] is encrypted with a random key, which is created with iOS is first installed or when the device is wiped by a user. The file system key is stored in Effaceable Storage. Since it’s stored on the device, the key is not used to maintain the confidentiality of data; instead, it’s designed to be quickly erased on demand. ... Erasing the key in this manner renders all files cryptographically inaccessible.” (page 11)

Documentation also indicates Effaceable Storage is stored on NAND. So this key, sitting on NAND, that is used to wipe is stored on a chip external to the A* processor.

“Securely erasing saved keys is just as important as generating them. It’s especially challenging to do so on flash storage, where wear-leveling might mean multiple copies of data need to be erased. To address this issue, iOS devices include a feature dedicated to secure data erasure called Effaceable Storage. This feature accesses the underlying storage technology (for example, NAND) to directly address and erase a small number of blocks at a very low level.” (page 10)

In your description you suggest that it is the “stored one-way hash of the user’s passcode” that is deleted on wipe, not some other key. I’d be happy for a pointer to some dox giving some detail of that procedure so I can clear up my confusion.

[Swordmaker]

Hi Cyphunk, Actually it was not Coronal but me, Swordmaker, who wrote the explanation on how the Apple system works. Let me see if I can explain it better.

Documentation also indicates Effaceable Storage is stored on NAND. So this key, sitting on NAND, that is used to wipe is stored on a chip external to the A* processor.

First of all your link goes to the latest iOS Security Guide PDF for iOS 9 and later, which if we are discussing the security in place on the hardware for the iPhone 5C is the wrong one to be referencing. The one you want to find is the one for iOS 7. The A6 was somewhat different, and not so secure.

However the important difference in what Apple has done is that for the A6 processors Encryption Engine co-processor section and for the later A7 processors which have an external registered Secure Enclave co-processor IC, there is a separate, internal Effaceable Storage FLASH memory area built in to these sub-processors inaccessible to the data processors. It is NOT on the separate FLASH memory IC where the data is stored, but rather inside these special sub-processors for secure encryption. It is this NAND to which Apple's iOS Security Guide is referring. . . and it is also why all decryption has to occur on the device.

Since it is not stored on the FLASH memory IC, that memory IC cannot be removed from the device with the means to re-construct the data key, or where it is stored away from the actual data, in an inaccessible NAND buried in either the Encryption Engine or the Secure Enclave, one cannot merely duplicate the Memory IC and repeatedly at high-speed try memory keys to try to brute force copies until one hits a correct key. Nor can one merely search the Memory IC seeking the storage location of the data key.

Nor, can the Memory IC be duplicated and placed in a myriad of duplicate iPhones where multiple user keys can be attempted, because, again the keys are not kept on the Memory IC, but rather in the imbedded NAND inside the Endryption Engine on the A6 processor, or later, inside the registered A7, A8, and A9 and later processors' Secure Enclaves.

All memory locations on the regular FLASH memory IC is Read/Write accessible to the Data processor. That does not meet the criteria of the security requirements of the NAND needed for true security. What Apple needed was a place to be able to securely store volatile user data which was NOT accessible by anything the data processor could read or modify. The answer was to create a secure area with its own sub-processor that would handle everything associated with security and encryption. Ergo, the creation of the Encryption Engine sub-processor with its own NAND originally within the processor IC and later divorcing it entirely from the processor in the Secure Enclave where it could just sit on the data pathway.

From my understanding, this small internal to the Secure location NAND, holding the one-way hash and perhaps the actual already constructed entangled data key (Apple is silent on this matter), is what gets erased when the ten tries without a match with the one-way hash is exceeded.

Does that help?

[Swordmaker]

Here is a Security Paper from 2012/2013 which might give you some insight into the inherent security in the A6/iOS7 combo of the iPhone 5, 5C and the iPad fourth generation that used that processor, and also the inherent vulnerabilities that were later closed with the introduction of the actual Secure Element sub-processor approach of the registered separate ICs in the A7 and later based iPhone/iPads.
iOS Encryption Systems
Deploying iOS Devices in Security-Critical Environments

Keep in mind that with the introduction of the A7 processor with the Secure Enclave is far more secure than what was included with the A6 and earlier processors with their Crypto Engines (I mis-recalled the actual name of the Security sub-processor section of that device) built into the actual processor IC. Apple's new Secure Enclave is a multi-layer IC processor that does not lend itself to laser reading of any data that is hidden on it. It is also hardened against being read by either software or hardware intrusion means.

[PLMerite]

“It’s a question of how they went about it. The legality of the method by which this was obtained appears to be dubious.”

They had a warrant and didn’t waterboard it, so no foul.

[cyphunk]

Hi, I started going over the document you sent. Thanks. First though I was able to go through the documents it references. I saw several indications that since iOS4 the File System Key (also called EMF at different points) is what is used to wipe the phone. This key is stored in Effaceable Storage. I couldn’t find anything that indicates if this storage may be within secure memory within the Secure Enclave, or not. Apple should clarify if the File System Key is stored on NAND or not.

https://www.trailofbits.com/resources/ios4_security_evaluation_paper.pdf

> Now [iOS4], the entire filesystem can be rendered unreadable by simply wiping a single encryption key (referred to here as the File System Key)