"BTW I simply don;t have access to the technical language that captures Apple's brand design of the security systems in their iPhones"
This statement is jibberish. Miss South Carolina-level jibberish. I didn't ask about your credentials, I asked whether you could answer a question. You can't.
"....Your inferring I am simply lacking understanding is amusing"
The preceding jibberish alone suffices to support my inference.
Nothing you've said would contradict the assertion that this is a low-complexity/high-criticality code deliverable. Your argument that if it were so, Apple would not be needed suggests that you have no working knowledge of code signing.
Your reply doesn't speak in any real technical terms, not even simple ones. I'm guessing you are not a developer.
I'm sorry to be blunt, but I think you find this technology breathtakingly esoteric because you have no actual understanding of it.
Nothing you've said would contradict the assertion that this is a low-complexity/high-criticality code deliverable. Your argument that if it were so, Apple would not be needed suggests that you have no working knowledge of code signing.
Your reply doesn't speak in any real technical terms, not even simple ones. I'm guessing you are not a developer.
I'm sorry to be blunt, but I think you find this technology breathtakingly esoteric because you have no actual understanding of it.
CB> There is nothing technologically esoteric about this at all.
KH> Oh, but there is-- to a breathtaking degree.
Could you please explain for us- in pure technology terms, not in terms of presumed social, legal our business consequences- what makes this technologically esoteric at all, let alone to a degree that should take ones breath away.
I have asked what there would be in the technical dimensions of performing the order that would contradict the assertion that this is a low-complexity/high-criticality code deliverable.
I had a thought about this: the update must be transparent. Once done, the user-in-possession must be able to see and/or hear that this is a seized phone, on the screen and with an audible tone. This can be done even in complying with the present order (where it doesn't matter).
Whether the phone is in possession of law enforcement, it cannot be made into a wiretap.
Could the Vendor be compelled to enable espionage against persons who don't enjoy the protection of U.S. privacy law? There is probably settled law to the contrary, but I really don't know.
Selling a phone in a foreign jurisdiction which would yield to a U.S. federal warrant may violate that jurisdiction's own privacy laws. I suspect there are settled principles in international law with respect to this, maybe embodied in treaties. Again, I don't know.
Apple could use the opportunity to narrow the precedent established by the order.
I know what questions to ask to test this off-the-cuff idea.
I'm saying that it is not even a legal precedent. This order, once upheld, does not affect the prospects of any future order where a judge says, "open this specific phone", and does not legally enable further activity, e.g. installing a covert wiretap.
Apple claims that the Government's request is unprecedented. In opposing the order, it is Apple, not the Government, who seeks to make new law.
Apple lost this round when they tried and failed to build a device secure against themselves. It's embarrassing. Too bad. Build a more secure phone next time, boys.
Can you imagine a theory under which a safe manufacturer could refuse to help defeat a safe in the shooters' storage space? "But, then the Government will know how easy it is, and may ask more of us in the future!" The government already knows how easy it is, and yes they might ask more in the future. That's for a judge to decide then, and having opened this safe today won't affect it.
AC> Code signing only states that the code comes from the signer, and is only useful so long as their signing key is not compromised, and it has nothing to do with targeting an actual device.
Code signing is not a mere autograph, if it is not signed, it will not run on any Apple device requiring a valid key, correct? The code targets a single device, the signature enables it, the code cannot be modified and still function. Can you not concede this point?
Compromised keys are a separate discussion, and only Apple's problem. They lost this round. Build a better phone next time.
"The operative word is putative, especially after several hundred warrants have been served on the company to produce a compromised version."
If your suggesting that Apple will weary of protecting its customers and open the flood gates, that is a different discussion. If you are suggesting that the Government will demand Apple covertly install a digital wiretap on a future target, that is also a different discussion.
I am disputing the notion that specific compliance with this order gives the Government a broader capability. Those who say that the Government can change the code appear not to understand code signing, but are numerous in the discussion.
AC> That is once the compromised version of the OS is written, the OS is compromised wherever that version is deployed.
Why is it compromised? That update on your otherwise identical phone will not function, as the serial number check putatively included in the update will fail, won't it?
Before we get to next steps, are my two technical assumptions (required key, unspooffable s/n), and the specific inference (the code to be provided in the order can only be used for the one device) correct?
I am a developer, but am not as familiar with iPhone as with Android.
I believe these two things to be true (please tell me if these are wrong),
* An update must be signed by a secret key secured by Apple * S/N in HW can be unspoofably interrogated in signed update
If the signed update says "if s/n equals bad-guy-phone open command pipe over wifi and bypass authentication-attempt delays", why does it matter whether the FBI (or anyone else) has it?
This order should change nothing in either legal precedent or user security, and may be performed with a modicum of low-complexity code.
* An update must be signed by a secret key secured by Apple * S/N in HW can be unspoofably interrogated in signed update
If the signed update says "if s/n equals bad-guy-phone open command pipe over wifi and bypass authentication-attempt delays", why does it matter whether the FBI (or anyone else) has it?
This order should change nothing in either legal precedent or user security, and may be performed with a modicum of low-complexity code.
What am I missing here?
-BNAD
Techdirt has not posted any stories submitted by smaines.
Re: Re: Apple Must Open The San Bernardino Terrorist's IPhone.
"BTW I simply don;t have access to the technical language that captures Apple's brand design of the security systems in their iPhones"
This statement is jibberish. Miss South Carolina-level jibberish. I didn't ask about your credentials, I asked whether you could answer a question. You can't.
"....Your inferring I am simply lacking understanding is amusing"
The preceding jibberish alone suffices to support my inference.
Re: Re: Apple Must Open The San Bernardino Terrorist's IPhone.
Nothing you've said would contradict the assertion that this is a low-complexity/high-criticality code deliverable. Your argument that if it were so, Apple would not be needed suggests that you have no working knowledge of code signing.
Your reply doesn't speak in any real technical terms, not even simple ones. I'm guessing you are not a developer.
I'm sorry to be blunt, but I think you find this technology breathtakingly esoteric because you have no actual understanding of it.
Re: Re: Apple Must Open The San Bernardino Terrorist's IPhone.
Nothing you've said would contradict the assertion that this is a low-complexity/high-criticality code deliverable. Your argument that if it were so, Apple would not be needed suggests that you have no working knowledge of code signing.
Your reply doesn't speak in any real technical terms, not even simple ones. I'm guessing you are not a developer.
I'm sorry to be blunt, but I think you find this technology breathtakingly esoteric because you have no actual understanding of it.
Re: Re: Apple Must Open The San Bernardino Terrorist's IPhone.
CB> There is nothing technologically esoteric about this at all.
KH> Oh, but there is-- to a breathtaking degree.
Could you please explain for us- in pure technology terms, not in terms of presumed social, legal our business consequences- what makes this technologically esoteric at all, let alone to a degree that should take ones breath away.
I have asked what there would be in the technical dimensions of performing the order that would contradict the assertion that this is a low-complexity/high-criticality code deliverable.
Re: Re: Oh PUH-LEAZE
I had a thought about this: the update must be transparent. Once done, the user-in-possession must be able to see and/or hear that this is a seized phone, on the screen and with an audible tone. This can be done even in complying with the present order (where it doesn't matter).
Whether the phone is in possession of law enforcement, it cannot be made into a wiretap.
Could the Vendor be compelled to enable espionage against persons who don't enjoy the protection of U.S. privacy law? There is probably settled law to the contrary, but I really don't know.
Selling a phone in a foreign jurisdiction which would yield to a U.S. federal warrant may violate that jurisdiction's own privacy laws. I suspect there are settled principles in international law with respect to this, maybe embodied in treaties. Again, I don't know.
Apple could use the opportunity to narrow the precedent established by the order.
I know what questions to ask to test this off-the-cuff idea.
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: This is a non-issue, isn't it?
I'm saying that it is not even a legal precedent. This order, once upheld, does not affect the prospects of any future order where a judge says, "open this specific phone", and does not legally enable further activity, e.g. installing a covert wiretap.
Apple claims that the Government's request is unprecedented. In opposing the order, it is Apple, not the Government, who seeks to make new law.
Apple lost this round when they tried and failed to build a device secure against themselves. It's embarrassing. Too bad. Build a more secure phone next time, boys.
Can you imagine a theory under which a safe manufacturer could refuse to help defeat a safe in the shooters' storage space? "But, then the Government will know how easy it is, and may ask more of us in the future!" The government already knows how easy it is, and yes they might ask more in the future. That's for a judge to decide then, and having opened this safe today won't affect it.
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: This is a non-issue, isn't it?
You're right, and they would be required to do so, or risk compromising user data outside of the protection of the court's (very specific) order.
I'm finding there is a pervasive lack of clarity on the mechanics of code signing and update distribution, so don't feel bad! =D
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: This is a non-issue, isn't it?
The installer doesn't target the machine, nor does the signature. The signed code does.
Re: Re: Re: Re: Re: Re: Re: Re: This is a non-issue, isn't it?
AC> Code signing only states that the code comes from the signer, and is only useful so long as their signing key is not compromised, and it has nothing to do with targeting an actual device.
Code signing is not a mere autograph, if it is not signed, it will not run on any Apple device requiring a valid key, correct? The code targets a single device, the signature enables it, the code cannot be modified and still function. Can you not concede this point?
Compromised keys are a separate discussion, and only Apple's problem. They lost this round. Build a better phone next time.
Re: Re: Re: Re: Re: Re: This is a non-issue, isn't it?
"The operative word is putative, especially after several hundred warrants have been served on the company to produce a compromised version."
If your suggesting that Apple will weary of protecting its customers and open the flood gates, that is a different discussion. If you are suggesting that the Government will demand Apple covertly install a digital wiretap on a future target, that is also a different discussion.
I am disputing the notion that specific compliance with this order gives the Government a broader capability. Those who say that the Government can change the code appear not to understand code signing, but are numerous in the discussion.
Re: Re: Re: Re: This is a non-issue, isn't it?
AC> That is once the compromised version of the OS is written, the OS is compromised wherever that version is deployed.
Why is it compromised? That update on your otherwise identical phone will not function, as the serial number check putatively included in the update will fail, won't it?
Re: Re: This is a non-issue, isn't it?
SM>> What am I missing here?
AC> The next step....
Thanks for replying.
Before we get to next steps, are my two technical assumptions (required key, unspooffable s/n), and the specific inference (the code to be provided in the order can only be used for the one device) correct?
-SM
This is a non-issue, isn't it?
I am a developer, but am not as familiar with iPhone as with Android.
I believe these two things to be true (please tell me if these are wrong),
* An update must be signed by a secret key secured by Apple
* S/N in HW can be unspoofably interrogated in signed update
If the signed update says "if s/n equals bad-guy-phone open command pipe over wifi and bypass authentication-attempt delays", why does it matter whether the FBI (or anyone else) has it?
This order should change nothing in either legal precedent or user security, and may be performed with a modicum of low-complexity code.
What am I missing here?
-SM
This is a non-issue, isn't it
I believe these two things to be true,
* An update must be signed by a secret key secured by Apple
* S/N in HW can be unspoofably interrogated in signed update
If the signed update says "if s/n equals bad-guy-phone open command pipe over wifi and bypass authentication-attempt delays", why does it matter whether the FBI (or anyone else) has it?
This order should change nothing in either legal precedent or user security, and may be performed with a modicum of low-complexity code.
What am I missing here?
-BNAD