|
Maybe it's me, but I am pretty confident the FBI is on the completely wrong track with this iPhone business.
As I understand it they want Apple to create a customized version of iOS that disables the "self-destruct", reduces the artificially inflated time-interval between passcode attempts, and would allow the passcodes to be attempted electronically rather than through the touch screen.
Even if the FBI got what it wanted, the attempts would still be made via the iPhone itself, using its single 1.3GHz A6 chip. According to Apple, however, there is a minimum of 80 ms required between attempts by virtue of a large iteration count. The most logical conclusion is that they're taking the PID plus the passcode, running it through a SHA algorithm 10,000 or so times (probably more depending on the CPU speed), and using the result to encrypt/decrypt a permanent 256-bit AES key which actually gets you to the data.
With a 6-digit passcode, assuming just uppercase letters, lowercase letters, and 0-9, there are 56.8 billion possible combinations (62^6), which given the unavoidable 80 ms delay would take the iPhone 5C 4.5 billion seconds, or 144 years to complete. So in the worst case scenario, what the FBI is asking for may well wind up being useless.
Of course if the passcodes are just numeric, or 4 characters instead of 6, that changes things dramatically. A 4 digit numeric passcode would only take 22 hours for example. I tried but cannot find details on what kind of passcode the scumbag terrorists were using. But let's assume for the sake of argument it is something small enough to crack in a reasonable amount of time, even on the iPhone 5C.
There's still a compelling technical argument (leaving aside the legal and constitutional issues) for why the FBI's request is overbroad: with only modest help from Apple, they could wage the brute force attack themselves. Apple almost certainly has the capability of extracting the encrypted data from the storage device, and of extracting the PID off of the chip. I realize this would be an extremely delicate and risky process for a hacker who doesn't have the exact specs at hand, but are we really to believe Apple doesn't have the ability to do this safely and relatively easily? And if they do, this strikes me as a very reasonable thing to order Apple to do, especially when the owner of the phone supports doing so.
The only other piece of information needed would then be the precise hashing procedure employed by iOS - information which can hardly be considered a trade secret considering almost everyone uses the same algorithms and similar procedures for these sorts of locks, and which could likely be reverse engineered with relative ease anyway (if it hasn't been already). Clearly this would be fair game for a subpoena, even in a civil case, let alone a criminal one.
With that, the FBI could just take the data and try to decrypt it by brute force on their own machines and maybe 100 lines of code. With a GPU farm, the likes of which we all know the government has access to, even the 144 years for the 6-character case sensitive alphanumeric code could be brought down by a couple orders of magnitude. But most importantly, it would obviate the FBI's overreaching request and pretty much moot Apple's opposition. It truly would be a "one shot" thing as there would be no risk of some new piece of software leaking its way onto the Internet for others to exploit. It would be analogous to forcing a bank to let the police into the vault and telling them what kind of lock protects the safety deposit box.
Of course, I suspect neither side has any interest in this course of action. The FBI would almost certainly prefer a permanent iPhone skeleton key - even if it's controlled by Apple - for future cases and seems to be using the compelling facts of this case as its best chance to get it. Apple on the other hand no doubt benefits from the positive publicity of standing up for its customers, and is not about to volunteer a more reasonable way for the government to get what it wants when (and this is my personal opinion) it is likely to win in the courts because of the government's overreaching.
(I am a lawyer, incidentally, and the reason I think they should win legally is pretty much what they said in their response to the court - the government can't make them write code. That sort of thing is prohibited by the 13th amendment, among others. The only time I'm aware of that the government can draft a company into its service is during a genuine war, where it's a question of resources, and at minimum Congress would have to authorize it and compensate for it).
Those are just my $0.02 anyway. Would love to hear if there are opposing views or if any of my assumptions are wrong.
Peter
|
|
|
|
|
0) Nice post. I agree with much of it.
1) Gird yourself. A few of the Apple haters here will likely swarm.
2) The "compelling facts of this case" are part of the national narrative of fear stoked by our government and media. Lions and tigers and terrorists, oh my!
3) One area that isn't getting much press is the forensic rules that are likely to play out if/when the FBI's requested backdoor is used to unlock a living defendants iPhone. At trial his/her defense attorney will demand access to the source code of the backdoor so "experts" can decide if the data was corrupted. Might as well publish the hack in an article here at CP. 
There are two types of people in this world: those that pronounce GIF with a soft G, and those who do not deserve to speak words, ever.
|
|
|
|
|
Mike Mullikin wrote: One area that isn't getting much press is the forensic rules that are likely to play out if/when the FBI's requested backdoor is used to unlock a living defendants iPhone. At trial his/her defense attorney will demand access to the source code of the backdoor so "experts" can decide if the data was corrupted. Might as well publish the hack in an article here at CP.
Interesting point. If the defendant were alive, I believe they could be compelled to unlock the phone pursuant to a valid search warrant, and if they refused, be jailed for contempt. One would also hope that the government had enough evidence to convict the person without data from the phone, and if they didn't, they probably have no business hacking the phone anyway.
But of course, if the government needed the data for other reasons - like a perceived imminent threat to the public - they may well use the tool. In that case I hope they'd be smart enough not to try to use whatever they find on the phone in a court case, because you're right, if they did, the defense would have a valid argument for being able to inspect every detail of "GovtOS". My understanding is they generally try not to actually use the evidence from their best sources in public court cases for precisely this reason. As long as they only use the phone data for leads and not directly to incriminate a particular person, I think they'd be able to keep the tool away from scrutiny.
|
|
|
|
|
I already considered much of what you've said here. Granted, I don't know enough about Apple's internals to have gone into as much detail as you have.
To me it certainly seems perfectly reasonable to extract the encrypted data and whatever other relevant pieces (the PID) needed to do an offline brute force of the data.
The only counter argument I can fathom is that the FBI thinks it will be faster to do it the way they want, and "time is of the essence." Of course I would argue that at this point, the data is so old that they aren't going to find much of use anyway, so the time element of getting the decrypted data isn't terribly important.
|
|
|
|
|
Peter Moore - Chicago wrote: Apple almost certainly has the capability of extracting the encrypted data from the storage device
Why? What would be the purpose of such a procedure? Back-ups are automatically made to iCloud (and the contents of these are already in the FBI's hands) so there is no need for data ever to be extracted directly from the chip. In any case it has been Apple policy since 2014 to manufacture phones which even they cannot hack, crack or otherwise abuse precisely so they cannot be compelled by FBI or terrorists (not that there's much difference between the two at times) at gunpoint or otherwise to compromise security of a user. So there's no reason to believe that they are not telling the God's honest when they say this is not possible in this or any other case and the only route is to 'update' the OS to allow an infinite number of monkeys to try to guess the password.
I am not a number. I am a ... no, wait!
|
|
|
|
|
Has Apple actually said that the "only route is to 'update' the OS?" I thought that came from the government's IT expert, not from Apple. Apple has - accurately - stated that they cannot decrypt the phone except by brute force, but I am not aware of Apple claiming that they do not have the technical ability to read the encrypted storage, and extract the PID, using physical extraction. Can you point me to where they've said that?
Assuming they have not made that claim, my answer to your question of "Why" is simply that they designed the system; they know exactly where the components are and how to access them.
It's been awhile since I've tinkered with chips in college, but I do know that any hardware that can be accessed by code can also be accessed physically. The right chips would need to be be identified, de-soldered off the motherboard (a delicate but perfectly possible procedure), placed on a breadboard, and then accessed with a general purpose programmable controller. All of this can be done in a fairly straightforward fashion with knowledge of the design. Apple could clearly be compelled - lawfully and constitutionally - to divulge the information needed. But since the FBI hasn't asked for what I'm suggesting, Apple is understandably not going to volunteer it.
I'm not suggesting either side is lying. I actually agree with Apple's stance given the ridiculous over-breadth of the order. I think the government's technical ignorance is what's to blame and Apple has no obligation to volunteer a better solution that the government isn't asking for.
|
|
|
|
|
The crucial point, as I understand it, is that the encryption key is not part of the data or OS but is hardwired in the chip in a way that cannot be read. As the individual keys are constructed independently from any chip identification methods Apple simply does not know what the encryption key on any phone is and has no way of reconstructing it. So whilst you can transfer data from the chip it is only ever in encrypted form and you cannot bring the encryption key with it. You would therefore be faced with brute forcing the 256 bit encryption key which is effectively impossible ...
Quote: If every atom on earth (about 1.3 * 10^50 atoms) was a computer that could try ten billion keys a second, it would still take about 2.84 billion years
So, yes, whether or not Apple have actually said this publicly, modifying the OS to allow brute forcing the 4 digit PIN really is the only feasible route to such useful data as there may be (or, let's face it, probably isn't!) on the phone.
I am not a number. I am a ... no, wait!
|
|
|
|
|
9082365 wrote: The crucial point, as I understand it, is that the encryption key is not part of the data or OS but is hardwired in the chip in a way that cannot be read.
I guess that last part is assumption that I'm questioning. I don't know that it cannot be read and I'm trying to find where and if Apple's actually said that. They do say the UID is "fused ... into the application processor." I'd like to know a little more about what that means exactly.
According to this article, the UID (sorry I've been calling it the PID) is actually encoded in binary somewhere on the chip's physical structure, which makes sense, and could be examined with a microscope. The author doesn't cite any sources for this, but if he's right, it seems like a perfectly viable option particularly if Apple were on hand to tell the government exactly where to look and what they needed to know to perform the procedure safely.
I'm not saying it would be easy or not labor intensive - but the "GovtOS" option is no easier, and the burden SHOULD be on the government anyway, not the innocent third party. Moreover, this method leaves no risk of easy repetition (it'll take precisely as much effort to do this to the next phone as it would to the current one) and doesn't unconstitutionally compel Apple to create a hacking device for the government to use whenever it pleases. In the end all it would require Apple to do is provide INFORMATION, which the law does permit the government to obtain.
|
|
|
|
|
Most experts seem to be saying that in older models there is a theoretical possibility of retrieving the UID from the chip but only using an electron scanning microscope and accepting a strong possibility of damaging the chip or destroying the UID in the process which makes it effectively a non starter. In newer models the chip is constructed specifically to exclude any possibility at all. Apple's reluctance to actually make the exact details public is, of course, totally understandable so we are left to rely on reports from those hackers (both white and black hatters) who have tried. So far I've not been able to find anyone who thinks it can be done with any guarantee of success.
I am not a number. I am a ... no, wait!
|
|
|
|
|
Well, ok, but you seem to still be overlooking my main assumption: Apple being involved. There's a huge difference between hacking without guidance, and having the designer of the device give you the information that would enable you to find the precise location of the UID and read it.
My argument is not that the FBI should try this themselves (as others have suggested). It's that they should be asking the court to compel Apple to divulge its knowledge and provide reasonable assistance to the FBI while making the attempt. This is a better legal solution, and maybe a better technological solution (depending on what kind of passcode is at issue), than the one ordered.
|
|
|
|
|
Surely we can draw some conclusion from the fact that this is not what the FBI is asking for though? It cannot be the case that they don't have access to plenty of technical advisors nor that there were not protracted discussions with Apple prior to the decision to invoke this arcane piece of legislation to compel action bringing it out into the public arena. It seems to me that we have to conclude that Apple has persuaded them, and their own experts have confirmed, that even within Apple's labs the process is either impossible or so risky as to be impractical. I find it impossible to believe that they're going to the very edge of legality for the 'solution' they've hit on unconvinced that no other option is available. The only alternative explanation would be legal advice that it is so blatantly illegal that there is zero chance of getting a court order on that basis but clearly that is not your opinion so it seems unlikely.
I am not a number. I am a ... no, wait!
|
|
|
|
|
My guess based on something I read somewhere at some point.. is that there is more to this than Apple releasing the data to the FBI.
Apple are perhaps having to play a very careful political/marketing game here - if Apple agree to help the FBI then hackers around the world may be given something of a clue as to the vulnerability of Apple devices.
Apple may need to play the 'our device is impossible to crack' game in order to impress their market, while trying to figure out how they are going to get the FBI the data they need without the whole think 'leaking out to the public.
As I have read elsewhere - I doubt there is much to do with ethics in this whole thing, as there are a number of serious ethical issues connected with mineral mines and factories that are connected with the mobile device market and Apple have not so far made a point of proving how clear they are of these problems.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: as there are a number of serious ethical issues connected with mineral mines and factories that are connected with the mobile device market and Apple have not so far made a point of proving how clear they are of these problems.
Actually they have...
Environment - Apple[^]
Supplier Responsibility - Apple[^]
There are two types of people in this world: those that pronounce GIF with a soft G, and those who do not deserve to speak words, ever.
|
|
|
|
|
|
I watched the video. Apparently this is a spectator sport - at least for the blokes sporting English accents.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Does that imply that there is a scenario where there is not a nasty surprise when trying to eat an elephant through the anus?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Science, I've got your coat.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
The hyena might find success in Washington D.C. 
|
|
|
|
|
The hyena has a remarkable resemblance to Trump! 
Marc
|
|
|
|
|
In The Zone[^], by Richard Elliott
Yeah, it's elevator music. So?
Software Zen: delete this;
|
|
|
|
|
Quote: This video is not available.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Hmm. Not to quote a line, but it works at my desk. Try this[^] instead.
Software Zen: delete this;
|
|
|
|
|
Richard Deeming wrote: This video is not available.
Consider yourself lucky. 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Gary Wheeler wrote: So?
So, I don't live, work, or otherwise exist in an elevator? I go out of my way to avoid elevators at least in part because of elevator music (plus the stairs are always healthier and usually quicker anyway!) There are clubs for people who like muzak. Please take it there! 
I am not a number. I am a ... no, wait!
|
|
|
|
|
I just found out about this and thought it was very cool.
Edit: fixed link
If you get the latest version of the free SysInternals tool Process Explorer[^], you can easily scan your running processes using VirusTotal.com (which checks against 57 different virus scanner's definitions).
It's super fast and very cool.
Unfortunately, I can't paste images in here to show you but here are steps to using it shown in the following linked images.
1. Start up ProcessExplorer
2. Start the virustotal.com scan of running processes:
http://raddev.us/images/sysinternals/procexp3.png[^]
You'll see ProcExp examining all the hashes of the running procs:
http://raddev.us/images/sysinternals/procexp1.png[^]
Finally, you'll see the results.
0/57 means none of the 57 virus checkers saw any problem.
You can see that one virus scanner thought my notepad++ was possibly malicious.
If you click the link it'll take you to virustotal.com so you can examine more info.
http://raddev.us/images/sysinternals/procexp2.png[^]
Check it out, I think you'll like it.
Disclaimer: I am not affiliated with sysinternals at all. I wish I was. 
modified 26-Feb-16 11:18am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
