|
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
