Alert Level: SEVERE
Posted on 02/23/2016 11:34:59 AM PST by Swordmaker
Did not realize my link is a shortened version. This one has 415 pages.
https://cryptome.org/2016/02/usg-apple-016.pdf
Just wow.
That illustration requires IMHO a bit of creative suspension of disbelief to interpret correctly. But whatever.
So we are supposed to note that the keys are stored in what... EEPROM? (umm, that seems OK, I imagine...)
Because, Ray, this is inclusive of ALL versions of iOS 9, including iOS 9.0, iOS 9.0.1, iOS 9.0.2, iOS 9.1 and iOS 9.2, all of which did nothing to change the security portions. That will not change until Apple changes to iOS 10. Are you THAT DENSE?
Make statements of fact and hold the insults.
I meant that one could emulate the entire iphone CPU and system in a powerful enough software emulator. All the Apple stuff would run on the emulator. Anything in hardware would be reverse engineered from examining the device and emulating it, and/or monitoring the signals in a non destructive manner. It’s a physical device, not a magic black box.
What would happen if someone in China, or NK, or ISIS had invented cell phones now in common use in the USA? How would we ever begin to enforce such an order on such a presumably antagonistic party in a foreign jurisdiction? I think we would put some geeks on it to reverse engineer it and build a replica, and then run the code on it. But if we could not do it in the USA, then I imagine that we would outsource it to Moscow or somewhere with inexpensive but very well educated labor. Whatever it takes. If we still could not do it, then own up to it as being too difficult. and live with it. I am probably missing a lot.
OK, fair enough.
And so... ?
We can presume that it is over-vague and will be regarded so upon higher review and/or appeal?
(Not that I would mind that, at all, but just seeking informational clarification...)
Since you have no clue as to what would actually be involved in creating a modified OS that would bypass the security, it is pointless to discuss the issue with you.
OK that is really confusing to come into and try to understand from the outside. I suggest employing precision in discussion. If we mention Secure Enclave, perhaps it would be best if we adhere to the formal technical definition of it in the sense that it runs in its own little processor component on the A7 and possibly beyond, but not the A6 which the iphone 5C in question uses. It sounds to me as if the iphone 5c from the snippets of definition I have seen floating around, by contrast, use some kind of EEPROM boot rom library security related routines that provide conceptually similar (though less secure in the absolute sense) security at some higher functional level. Does that make any sense? If not, I wonder where I might have strayed. If something like this is spelled out in each response (I know it is somewhat more lengthy) then perhaps folks will be less likely to go down semantic rabbit holes in discussions. Then someone can come in during the discussion and still understand it without having to learn thread specific shorthand that does not apply outside the thread (eg in the so called real world, for example). All standard disclaimers remain applicable. If I am babbling on, apologies to all.
Right, or at least seemingly so. (And that initially confused me very much, parachuting in from nowhere. I figured there was some kind of terminology rift somewhere.) FWIW, thanks.
Do you write code? I do. Till you tell me how much code you write, I'd rather not hear your opinion regarding how much I know about the subject.
Yes, I wrote code, though not in the past few years. I have also been an information security officer for 10 years, so I know a little about encryption and the like. Your comments about a 15 minute fix are ignorant and unsupportable. We are not talking about changing one procedure call - there are multiple systems involved, and without thorough testing, a quick fix like you suggest would most likely result in bricking the phone anyway. If you write code, you should know that any time you make a change in any part of the code, you risk introducing bugs that may affect parts of the code you hadn’t even considered.
Keeping that in mind, the claim of the DOJ that Apple refused to offer any help is simply not true. To infer the password was reset by someone in San Bernadino without mentioning the password was changed at the request of the FBI is a lie by omission.
On those 2 points alone, I would deny the motion because if the Dept of Justice is going into Court to force anyone to compel, they do not change or hide the facts. If I found out the FBI and the DOJ colluded in writing the Motion to Compel, there would be no need to discuss the technical issues of how any new program would be written,because I would throw the order out. But that's just me and my legal ignorance. Good thing I am not the magistrate. :)
Ah, first I dunno exactly what it takes to make any so called simple change. It all depends where in the system the change is made and what address space it shares with other routines, other threads, other processes, other kernels, yadayada, yes? And that might not still account for what could happen with interrupts... and yes, timer interrupts in particular...
I am a bit rusty but the timer that the user experiences could theoretically be implemented in several different ways depending on such things as the level and data space in which it (the timer code) operates. There could be unintended consequences. We prefer to think that there will not be any such consequences, but if we are wrong, then the consequences can come back and bite us in the butt. That is what system testing and reliability testing are all about. And even they don’t catch all the tiny but ultimately significant things that can bring down a system in a bad way at the wrong time and/or place. When was the last time you heard of a complex software project being delivered on time and on or under budget (and being 100% bug free)?
Beyond that I share concerns of many about bringing into life a software method of defeating a software mechanism whose sole stated, marketed, delivered and supported intention is to resist being defeated. That totally voids all the design, marketing, sales, and can open up a nightmare for support once the horse has left the barn. This simple code modification will already likely be the McGuffin of the next Mission Impossible sequel movie plot. It will be more valuable than plutonium and potentially just as dangerous (in the wrong hands).
I think we all need to take a deep breath, pause and step back a while to ponder whenever the government invokes some obscure law and uses it to demand unconditional compliance in a new venue. I’m probably not going to have time to read a 355 page Apple response tome filing. But by all accounts that I have seen, the government request seems overly broad. It should be more narrowly constrained at the very least to protect proprietary value, if granted at all. The government does not seem to feel obligated to balance Apple’s interests with its own at all. Should that not concern everyone? It is saying the equivalent of “you deal with the unintended consequences” to Apple. Well, Apple has lots of engineers and lots of lawyers and there seem as if there can be many unintended consequences. Why not hear Apple out? Why not reason with them? The government already admits it is an exceptional circumstance. Why such an openended order?
And is it true that the order was not signed by anyone? Maybe the actual order is a seperate document that is actually signed by the magistrate judge. It would then have a date of signing, signature, and date of implementation (yes?). Anyone see such a beast yet? (Just wondering.)
exactly. thanks.
And do I apologize. I was talking about the DOJ Motion and the link to which I referred was to the Court Order.
This is what happens when surrounded by talk of code- it is just like anything above basic algebra—my brain tends to get confused. Too abstract :)
My brain was permanently fried decades ago after working on a never-released and now forgotten processor and starting to dream in processor-specific object code binary. Ugh. Where is the mathematical elegance in that?
The retry counter could be incremented by 0 instead of by 1.
The retry delay code could be removed or branched around.
Read your PM.
Could... not... resist... sending... funny... sendup...
:-)
Steve, you may be wondering why this poster has grappled onto you like a drowning man. I don't expect you to care, but in the interest of truth and my own reputation (on this site and its predecessors for more than 20 years) I want to point out that this dispute and this posters' attacks have gone on across numerous threads.
His venom has no basis in fact, or in the validity of an argument; he's been caught in several lies, and has run from and refuses to acknowledge his real motivation in all of this.
By his own words, he is obsessed with Tim Cook's sex life, to the point of being completely unhinged. An armchair psychologist might speculate what it is inside a man that drives him to want to destroy another whose behavior he finds so offensive-- perhaps he fears it in himself? I'll leave it to others to speculate on that.
This poster has a vehement desire to ruin Apple, and is willing to take the rest their customers' privacy and liberty down with it, just to satisfy his own lust for... what? Revenge?
Don't believe for a minute that he sees this as a fight for the liberty of citizens, or the right of legitimate government. That's a new dress he put on for this thread. He, by his own admission, thinks this is about destroying (his words) "a faggot CEO".
His words are (among many examples) here and here.
Of course, he doesn't want you to know this.
It's worth considering this when making a judgement about his veracity.
I've been telling him he's on the wrong website. He belongs at DU with this authoritarian tripe-- they live it over there.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.