Earlier quoted context omitted.
I s there any difference between a test/development backdoor and a FBI backdoor?. If you let backdoors in the system, of course the secret services will demand to have it. In fact, backdoors that were put in place because secret services' pressure, will be suited as developer backdoors as an excuse when found by the mainstream. First they install backdoors in systems, in order for MS or the US gobertment to have comp…
I think you're missing my point (and my poor wording probably didn't help). A backdoor that requires physical access isn't a backdoor. If an attacker has such access, you're already screwed. A backdoor that requires administrative privileges isn't a backdoor. If an attacker has such access, you're already screwed. The so-called dev/test 'backdoor' really isn't a backdoor. It's a 'unlock' tool that's required for anyo…
Microsoft proves backdoor keys are a bad idea
71–80 of 106 posts
Re: Microsoft proves backdoor keys are a bad idea
#72Earlier quoted context omitted.
If a terrorist attack occurred and it was clear that it could have been prevented if the authorities could have read encrypted information, would that change your opinion of backdoors? If not, why are you criticizing the other side for being just as steadfast in their beliefs as you are in yours? The truth is that no policy is going to be 100% effective so I'm not sure why either side of the debate should overadjust…
I would not criticize the other side of the debate for being steadfast. I will however criticize the belief itself. I will base my criticism on actual events such as this one instead of hypotheticals. I do not think considering this case in the encryption/backdoor debate is an over-adjustment based on a single failure. I think this a relevant example of the risks of creating and using a golden key. If you discount ev…
The problem is that due to its nature, you only hear about one side of these events. We never hear about the attacks that were stopped or could have been stopped by backdoors. Many people take that as proof that these events don't happen but as the old saying goes absence of proof is not proof of absence. Without that proof, all we can do is provide hypotheticals.
I am not arguing that this story isn't relevant. I am arguing that people who feel this story should change their opponents minds are guilty of hypocrisy. In my personal view, both side in this debate have pros and cons. However, most in the tech community refuse to acknowledge that which results in zero progress.
Re: Microsoft proves backdoor keys are a bad idea
#73Earlier quoted context omitted.
Perhaps not rate-limiting, but on the i-phone, it was about circumventing the limit of 10 tries. Besides, doesn't secureboot block an unsigned live-CD? Otherwise, I don't see the point of secure boot past vendor lock-in.
It is supposed to prevent boot level malware or people otherwise compromising the device. Implemented correctly, it can be beneficial to security. As an end user, I like having a TPM, and I like having boot level protection measures. I wouldn't trust my life to them, but after seeing indictments/FBI testimony, they seem like they are enough to deter many attackers. The whole "only applies to RT devices" was a bit shi…
Re: Microsoft proves backdoor keys are a bad idea
#74Earlier quoted context omitted.
I s there any difference between a test/development backdoor and a FBI backdoor?. If you let backdoors in the system, of course the secret services will demand to have it. In fact, backdoors that were put in place because secret services' pressure, will be suited as developer backdoors as an excuse when found by the mainstream. First they install backdoors in systems, in order for MS or the US gobertment to have comp…
I think you're missing my point (and my poor wording probably didn't help). A backdoor that requires physical access isn't a backdoor. If an attacker has such access, you're already screwed. A backdoor that requires administrative privileges isn't a backdoor. If an attacker has such access, you're already screwed. The so-called dev/test 'backdoor' really isn't a backdoor. It's a 'unlock' tool that's required for anyo…
Re: Microsoft proves backdoor keys are a bad idea
#75Earlier quoted context omitted.
I s there any difference between a test/development backdoor and a FBI backdoor?. If you let backdoors in the system, of course the secret services will demand to have it. In fact, backdoors that were put in place because secret services' pressure, will be suited as developer backdoors as an excuse when found by the mainstream. First they install backdoors in systems, in order for MS or the US gobertment to have comp…
I think you're missing my point (and my poor wording probably didn't help). A backdoor that requires physical access isn't a backdoor. If an attacker has such access, you're already screwed. A backdoor that requires administrative privileges isn't a backdoor. If an attacker has such access, you're already screwed. The so-called dev/test 'backdoor' really isn't a backdoor. It's a 'unlock' tool that's required for anyo…
I'm finding your line of argument across multiple comments increasingly disingenuous. You're hurting your argument far more than you're helping.
Re: Microsoft proves backdoor keys are a bad idea
#76Earlier quoted context omitted.
>If an attacker has physical access to your device, you're already screwed. The FBI had physical access to the San Bernardino iPhone. If this were true, what was the point of the public fight with Apple and eventual purchase of a zero day exploit to get into it?
I'm speculating here, but surely by this argument Apple has a backdoor to unlock the phone if it physically has it.
What Apple had was the option of updating the phone with a compromised (or compromisable) security implementation.
Apple refused to do that.
The FBI did find an exploit (which AFAIR they've refused to disclose, in controvention of previous policy if not regulation and/or law), but that represents a flaw in implementation which Apple can then remedy.
http://mashable.com/2016/02/16/apple-hack-san-bernardino-pho...
Rather than asking Apple to obtain and provide the device’s passcode, Tuesday's ruling orders Apple to provide the FBI with special software that can act as a workaround for the iPhone's built-in security. Court documents suggest Apple should either provide software that bypasses the need for a passcode entirely or software that allows the FBI to unlock the phone by running an endless combination of passcodes until they are able to unlock the device. The latter method would also require software that disables the iPhone's auto-erase feature, which wipes a device after a certain number of unsuccessful attempts at unlocking.
Re: Microsoft proves backdoor keys are a bad idea
#77Earlier quoted context omitted.
I'm speculating here, but surely by this argument Apple has a backdoor to unlock the phone if it physically has it.
No. What Apple had was the option of updating the phone with a compromised (or compromisable) security implementation. Apple refused to do that. The FBI did find an exploit (which AFAIR they've refused to disclose, in controvention of previous policy if not regulation and/or law), but that represents a flaw in implementation which Apple can then remedy. http://mashable.com/2016/02/16/apple-hack-san-bernardino-pho...…
Re: Microsoft proves backdoor keys are a bad idea
#78Earlier quoted context omitted.
I would not criticize the other side of the debate for being steadfast. I will however criticize the belief itself. I will base my criticism on actual events such as this one instead of hypotheticals. I do not think considering this case in the encryption/backdoor debate is an over-adjustment based on a single failure. I think this a relevant example of the risks of creating and using a golden key. If you discount ev…
>I will base my criticism on actual events such as this one instead of hypotheticals. The problem is that due to its nature, you only hear about one side of these events. We never hear about the attacks that were stopped or could have been stopped by backdoors. Many people take that as proof that these events don't happen but as the old saying goes absence of proof is not proof of absence. Without that proof, all we…
I don't think this applies here. I suppose your point is goverment's exploits might be effective but they keep it low not to expose the fact of their existence.
Well, this might very well justify anything from 1984 or any other anti-utopia — "let us do whatever, it is effective and needed, but we won't give any facts or details, because it might compromise our system".
Re: Microsoft proves backdoor keys are a bad idea
#79Earlier quoted context omitted.
Of sorts. Apple (and unless they have been compromised, only Apple) could replace the firmware of a locked phone with a new firmware that will accept millions of unlock attempts without erasing the phone, at which point the password could be found by brute force. The FBI asked Apple to create this firmware, and Apple refused.
And presumably Apple could have designed it to not allow firmware updates without being unlocked. Or require overwriting of "secured" secrets if an update is applied anyways. It probably wasn't worth the potential user hassles?
Re: Microsoft proves backdoor keys are a bad idea
#80Earlier quoted context omitted.
I think you're missing my point (and my poor wording probably didn't help). A backdoor that requires physical access isn't a backdoor. If an attacker has such access, you're already screwed. A backdoor that requires administrative privileges isn't a backdoor. If an attacker has such access, you're already screwed. The so-called dev/test 'backdoor' really isn't a backdoor. It's a 'unlock' tool that's required for anyo…
The term "backdoor" derives from the very notion of a door. In the back whatever it is you're trying to secure. I'm finding your line of argument across multiple comments increasingly disingenuous. You're hurting your argument far more than you're helping.
I ask this because I'm still rather unclear about the argument that the original article is trying to make. I'm even more confused about what conclusions slipstream would have us draw from his web-post. Some comments here say that it's not an exploit, that instead its a lesson about why you shouldn't, as a matter of policy, include backdoors. Others say that it is a backdoor/security hole, and are appropriately up in arms over it. The only thing I'm confessing is confusion.
I understand that you think I'm being disingenuous, and the nice thing is that we really don't need to continue this conversation. If it is as bad as some are suggesting, than wouldn't an exploit be out in the near future? I'd expect such an exploit, or even evidence of a backdoor, to make further news, and if I see it then I'll obviously have my answer.