10 ms·

(disclaimer, MS employee, non-security expert here). I've read through the article, here, and in other places, and I'm seeing sentiment that this is a big fuck

(disclaimer, MS employee, non-security expert here). I've read through the article, here, and in other places, and I'm seeing sentiment that this is a big fuck up on Microsoft's part. I might be completely misunderstanding, but I just don't see it. In order to use the backdoor, you've got to flash firmware, so, you've got to have physical access to the device. If an attacker has physical access to your device, you're already screwed. So, I don't doubt that the key exists (I had to use it myself when testing RT devices back in the win8 days), but what's the exploit here? Why is it, as the title suggests, a 'bad idea'? Isn't a secure boot policy that can be bypassed with physical access more secure than none?

Knuff 10y ago
The point the register makes is not that this allows unlocking devices (though that's interesting in it's own right), but that is done via a "secret key" that now got exposed. Very similar to what the government wants with key escrows and other backdoor mechanisms for decryption of communication. Maybe to clarify: it highlights the mechanism (golden key) is flawed. That Microsoft uses it for boot loaders is unimportant.
- astrodust 10y ago
  In other words, if Microsoft can't keep the proverbial cat in the bag what hope do other less tech-savvy companies or organizations have?
  - cptskippy 10y ago
    Like the IoT makers who lock their devices by means of clear text passwords hardcoded into the device firmware? Most companies don't go to the extent of having a cryptographically secure key validated by a TPM. At least MS is trying to secure the system.
    - beagle3 10y ago
      MS are trying to secure their monopoly. If they wanted to secure the system, key management would be up to the user.
      - cptskippy 10y ago
        But it's ok if Samsung, Google, Apple or whoever else lock you out of the device? Or at least they're not doing it to protect their monopoly. Also, we're talking about Microsoft ARM based devices so what monopoly are they trying to protect? The monopoly on landfill space they used to dump all the Windows RT devices they failed to sell?
        beagle3 10y ago
        > But it's ok if Samsung, Google, Apple or whoever else lock you out of the device? Or at least they're not doing it to protect their monopoly. No, it is not ok. Kindly point me to the place where I said it is ok. (That said, Google sells phones with unlocked boot loaders, and have similar "Developer Mode" support for Chromebooks. Samsung and Apple to the best of my knowledge do not sell unlocked phones but do sell unlocked laptops). > Also, we're talking about Microsoft ARM based devices so what monopoly are they trying to protect? The monopoly on landfill space they used to dump all the Windows RT devices they failed to sell? Ah, but they wouldn't have produced millions of these devices if they didn't think they could sell them. The ARM based devices were a test of the waters. Microsoft requires, on x86, that trust of the MS key be preinstalled and that it be possible to turn off UEFI - but they do not require (e.g.) that there be an ability for the user to remove the MS trust or add new trust. (All of these requirements support their monopoly). I cannot know, but I suspect Microsoft is playing the long game here, and that at some point after Win7 extended support (4 years from now), they plan to require that UEFI cannot be turned off for a machine to be certified to run Win10 "dominion edition". They've started with restricting kernel drivers in the "anniversary edition". I suspect The ARM UEFI was a test for this. If I am right, the failure of WindowsRT will not change the course of this long game; hopefully something else will (right now, the emergence of reasonable Chromebooks is the only thing that appears to have the potential to stop it)
- bradford 10y ago
  Ok, I get it. The message is "don't use backdoors, because they'll inevitably get leaked", which I agree with. Unfortunately, I don't think that's the message that's being interpreted by the vast majority of readers. I'm delving into opinion territory now, but when the word 'backdoor' is used, aren't most people going to assume that it's an FBI backdoor, instead of a test/development backdoor? This seems like the kind of article that fans the fuels of conspiracy theorists, and no one seems to be doing anything to correct the record.
  - pipio21 10y ago
    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 complete access to any computer in the world, then they worry when the Chinese and Russians find them.
    - bradford 10y ago
      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 anyone who's going to engineer the device. My main beef is that this article appears to be re-branding the engineering unlock as a backdoor, and confusion is obviously ensuing. Again, In my original post, I asked "What's the exploit"? and I understand that the existence of an exploit might not be the article's subject, but If you really think that there's a security problem here, I'll ask it again: "What's the exploit?"
      - Nullabillity 10y ago
        > 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. Then why bother trying to lock it down in the first place?
- ge0rg 10y ago
  I think thereg didn't get that quite right. From reading the original advisory, I would conclude that this is not a backdoor (a by-design security "override"), but an actual vulnerability in the boot loader, where it does not check the type of the signed data blob (policy vs. supplemental policy) and thus can be exploited to disable further signature checks. The effect is the same of course, both to attackers and to device owners. One could speculate if this is a backdoor created with plausible deniability, maybe paid for by some three letter agency. But the evidence doesn't really point into the direction of an intentional backdoor.
ge0rg 10y ago
I don't know the full set of security measures on Windows RT devices, but if it doesn't have an effective hardware-level flash write protection in place, you should be able to change the policy with admin/kernel code execution rights, allowing for remote installation of a rootkit. Besides, it is a worthy goal to protect a device from physical manipulation as well, i.e. to prevent border agents or secret agencies of a nondemocratic country from planting malware on your device. The recent Apple vs. FBI debate has brought up a large number of arguments pro and contra protection from physical attacks.
theandrewbailey 10y ago
From the last section: > To reiterate, these Microsoft-signed resources – the debug-mode policy and the EFI installation tool – are only meant to be used by developers debugging drivers and other low-level operating system code. In the hands of Windows RT slab owners, whose devices are completely locked down, they become surprisingly powerful. > It's akin to giving special secret keys to the police and the Feds that grant investigators full access to people's devices and computer systems. Such backdoor keys can and most probably will fall into the wrong hands: rather than be used exclusively for fighting crime, they will be found and exploited by criminals to compromise communications and swipe sensitive personal information.
- RHSeeger 10y ago
  Of course, the problem with a digital key is that once it's out in the wild, its out for everyone and forever.
  - theandrewbailey 10y ago
    Same issue with a physical one. The solution is the same, too: get a new key (and lock).
andrey_utkin 10y ago
> Isn't a secure boot policy that can be bypassed with physical access more secure than none? Of course it isn't. Impossibility of bypassing is the only reason for secure boot technologies to exist. They are invented so that you are NOT automatically screwed if an attacker has physical access to your device. Secure boot technology is fine in principle, it's just stupid position the manufacturers hold. They ignore recent history. At their own peril, I'd say. https://en.wikipedia.org/wiki/Clipper_chip https://en.wikipedia.org/wiki/Clipper_chip And I'm not even sure physical access factor is strictly necessary for adversarial bypassing. (I'm not a security expert, too.)
- bradford 10y ago
  >> Isn't a secure boot policy that can be bypassed with physical access more secure than none? >Of course it isn't. Really? Suppose that you are choosing a new device. You can choose one that let's a remote hacker install a rootkit via a malicious website, or you can choose one that let's a hacker install a rootkit only when they have physical access to your device. Which one do you choose, and why is it the latter?
  - s_tec 10y ago
    What about the third option, where a hacker can't install a rootkit even if they have physical access? That's what MS tried to build, but is now completely broken.
  - deleted 10y ago
    [deleted]
- sp332 10y ago
  You need admin rights, but not physical access.
  - bradford 10y ago
    requiring admin rights for an exploit is certainly a lower barrier to entry than is requiring physical access, but I think my point still stands: if someone has those rights, you're already screwed.
slipstream- 10y ago
MS' own advisory says you don't need physical access (only admin rights).
SideburnsOfDoom 10y ago
Don't the keys normally prevent "people with physical access to the device" from easily updating the firmware? This includes everyone from J. Random Hacker who wants to install on thier own hardware a linux (which might or might not be a good build), and an attacker who has borrowed your device from a hotel room to put some rootkit on it.
csydas 10y ago
I think the basic idea is that with physical access in general, the attacker may have an N% chance of accessing it. The adage about physical access isn't to guarantee they will get access, just that you must consider it as such and react appropriately. The adage isn't a declaration of the state of the machine, it's a declaration on how to respond to its loss. With a backdoor via any means, the attackers now basically have (N+1)% chance of getting that access, and arguably it's much more than a single increment since whereas other exploits "might" exist, these ones will guaranteed exist. The suggestion and complaint isn't that "no secure boot is better than one that's easily bypassed", the complaint is requiring such a bypass and not giving the actual owners of the machine control over setting up that secure boot. With the RT devices, the user has absolutely no say in the secure boot process, and they're entirely dependent on Microsoft or whatever organization to provide best security practices. Also, If the user sets up their own key and does it wrong, they have only themselves to blame. If a company or government does it, the user has no one to blame, since often legal contracts prevent any reparations as result of damage done by stuff like this. The US Government, for reasons of varying validity, needs to give you permission to sue it, meaning they can eschew any complaints should they lose the key. All in all, a mandated backdoor just increases the chance that there will be a violation, takes control away from the user, and provides no compensation if the forced backdoor results in damages to the user.
my123 10y ago
For Windows Mobile RDU, it isn't flashing firmware even :) It's a package to be flashed via iutool. For RT, the official unlocking way is on http://woaunlock http://woaunlock on the MS corporate network.
mtgx 10y ago
> If an attacker has physical access to your device, you're already screwed. Tell that to the FBI. They seem to have been quite upset about not being able to unlock some iPhones. Doesn't anyone wonder why you never seem to hear stories about FBI being unable to unlock encrypted user devices? Surely at the number of people who encrypt their Windows devices is in the tens of millions in the U.S. alone, and some of them must have been caught by law enforcement for various crimes.
TheSpiceIsLife 10y ago
If an attacker has physical access to your device, you're already screwed. I'm no security expert, but is this true? Say I use full drive encryption, with whatever the popular Linux distros are offering at install time, and Say I use a strong password of 30 random characters. Is it feasible to break this encryption in a reasonable time frame?
- andrey_utkin 10y ago
  See Evil Maid Attack https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html https://www.schneier.com/blog/archives/2009/10/evil_maid_att...
- jewel 10y ago
  There's a lot that can go wrong if an attacker has physical access to your device. As far as is publicly known, you're not directly vulnerable to having the password broken as long as the device is powered off when it falls into the wrong hands, but there are a lot of caveats. If it's powered on they can possibly extract the password from RAM using a "cold boot attack". They can also freeze the RAM to get its contents to last longer and then moving it to another computer and dump it, recovering your full-disk encryption key. If the attacker has temporary physical access, they have a number of ways that they can tamper with the device. For example, they can replace the BIOS, the bootloader, the firmware on your keyboard, etc. The new code can record your passwords or send your data to the attacker over the internet. One other way that you're physically vulnerable is that the attacker can possibly infect your hardware before it even arrives at your home, by replacing hardware while it's shipping. This is probably only available to nation-states.
IBM 10y ago
>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?
- boznz 10y ago
  I'm speculating here, but surely by this argument Apple has a backdoor to unlock the phone if it physically has it.
  - beagle3 10y ago
    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.
    - MichaelGG 10y ago
      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?
      - asimpletune 10y ago
        My loose understanding is that this is in the works (not an apple employee).
  - dredmorbius 10y ago
    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-phone-fbi/#3HUiZbMlzkqk 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. http://fortune.com/2016/04/27/fbi-apple-iphone-crack/ http://fortune.com/2016/04/27/fbi-apple-iphone-crack/
rdtsc 10y ago
Ok but then why bother with whole key thing then? That's a whole lot of code, API crap and other junk why not just force user to hold a key to specifically reboot to reflash / upgrade boot loader. So have to hold the devices in hand to do it. It seems to me the mechanism was created exactly not allow even an owner to boot a non-approved OS image.
- cptskippy 10y ago
  That was exactly the intent. Service Carriers often require devices be locked because they subsidize them and want to ensure they're only/always viable with their services.
rocqua 10y ago
Secure boot's intentions are to ensure a malicious modified OS cannot run (when taken at face value, there is also the potential for vendor lock-in, but noone will defend it based on that). Remember that I-phone the FBI wanted apple to hack? With this golden key, anyone could've hacked into that I-phone. I am not sure how e.g. bitlocker uses the TPM, but it might be that being able to load a modified OS allows for bypassing OS-implemented rate-limiting on TPM access.
- stable-point 10y ago
  The TPM controls the rate-limiting. A compromised OS shouldn't affect it. (Otherwise a live CD could compromise your disk encryption, as the encryption is usually done at the OS level, not in the BIOS/EFI).
  - rocqua 10y ago
    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.
    - MichaelGG 10y ago
      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 shifty looking from MS, though. Fortunately the broken Windows on ARM model died. Edit: I'd also note that, e.g. console gamers love this stuff. It allows them to pretty much rely on others not being able to cheat very well.
      - rocqua 10y ago
        So does it validate the bios/uefi firmware? Which then in turn can be setup to validate the OS (or not to validate it?)
babesh 10y ago
Like when the government intercepted routers in transit to install their own snooping devices. Now they can do that to all computers and it would be very hard to tell. And now it can be anyone not just the government.
scythe 10y ago
>Isn't a secure boot policy that can be bypassed with physical access more secure than none? Not if the bypass is a zero-day.
rbanffy 10y ago
I think the worst part is that the trusted boot environment can no longer be trusted.

Knuff 10y ago

The point the register makes is not that this allows unlocking devices (though that's interesting in it's own right), but that is done via a "secret key" that now got exposed. Very similar to what the government wants with key escrows and other backdoor mechanisms for decryption of communication. Maybe to clarify: it highlights the mechanism (golden key) is flawed. That Microsoft uses it for boot loaders is unimportant.

astrodust 10y ago
In other words, if Microsoft can't keep the proverbial cat in the bag what hope do other less tech-savvy companies or organizations have?
- cptskippy 10y ago
  Like the IoT makers who lock their devices by means of clear text passwords hardcoded into the device firmware? Most companies don't go to the extent of having a cryptographically secure key validated by a TPM. At least MS is trying to secure the system.
  - beagle3 10y ago
    MS are trying to secure their monopoly. If they wanted to secure the system, key management would be up to the user.
    - cptskippy 10y ago
      But it's ok if Samsung, Google, Apple or whoever else lock you out of the device? Or at least they're not doing it to protect their monopoly. Also, we're talking about Microsoft ARM based devices so what monopoly are they trying to protect? The monopoly on landfill space they used to dump all the Windows RT devices they failed to sell?
      - beagle3 10y ago
        > But it's ok if Samsung, Google, Apple or whoever else lock you out of the device? Or at least they're not doing it to protect their monopoly. No, it is not ok. Kindly point me to the place where I said it is ok. (That said, Google sells phones with unlocked boot loaders, and have similar "Developer Mode" support for Chromebooks. Samsung and Apple to the best of my knowledge do not sell unlocked phones but do sell unlocked laptops). > Also, we're talking about Microsoft ARM based devices so what monopoly are they trying to protect? The monopoly on landfill space they used to dump all the Windows RT devices they failed to sell? Ah, but they wouldn't have produced millions of these devices if they didn't think they could sell them. The ARM based devices were a test of the waters. Microsoft requires, on x86, that trust of the MS key be preinstalled and that it be possible to turn off UEFI - but they do not require (e.g.) that there be an ability for the user to remove the MS trust or add new trust. (All of these requirements support their monopoly). I cannot know, but I suspect Microsoft is playing the long game here, and that at some point after Win7 extended support (4 years from now), they plan to require that UEFI cannot be turned off for a machine to be certified to run Win10 "dominion edition". They've started with restricting kernel drivers in the "anniversary edition". I suspect The ARM UEFI was a test for this. If I am right, the failure of WindowsRT will not change the course of this long game; hopefully something else will (right now, the emergence of reasonable Chromebooks is the only thing that appears to have the potential to stop it)
bradford 10y ago
Ok, I get it. The message is "don't use backdoors, because they'll inevitably get leaked", which I agree with. Unfortunately, I don't think that's the message that's being interpreted by the vast majority of readers. I'm delving into opinion territory now, but when the word 'backdoor' is used, aren't most people going to assume that it's an FBI backdoor, instead of a test/development backdoor? This seems like the kind of article that fans the fuels of conspiracy theorists, and no one seems to be doing anything to correct the record.
- pipio21 10y ago
  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 complete access to any computer in the world, then they worry when the Chinese and Russians find them.
  - bradford 10y ago
    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 anyone who's going to engineer the device. My main beef is that this article appears to be re-branding the engineering unlock as a backdoor, and confusion is obviously ensuing. Again, In my original post, I asked "What's the exploit"? and I understand that the existence of an exploit might not be the article's subject, but If you really think that there's a security problem here, I'll ask it again: "What's the exploit?"
    - Nullabillity 10y ago
      > 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. Then why bother trying to lock it down in the first place?
ge0rg 10y ago
I think thereg didn't get that quite right. From reading the original advisory, I would conclude that this is not a backdoor (a by-design security "override"), but an actual vulnerability in the boot loader, where it does not check the type of the signed data blob (policy vs. supplemental policy) and thus can be exploited to disable further signature checks. The effect is the same of course, both to attackers and to device owners. One could speculate if this is a backdoor created with plausible deniability, maybe paid for by some three letter agency. But the evidence doesn't really point into the direction of an intentional backdoor.

ge0rg 10y ago

I don't know the full set of security measures on Windows RT devices, but if it doesn't have an effective hardware-level flash write protection in place, you should be able to change the policy with admin/kernel code execution rights, allowing for remote installation of a rootkit. Besides, it is a worthy goal to protect a device from physical manipulation as well, i.e. to prevent border agents or secret agencies of a nondemocratic country from planting malware on your device. The recent Apple vs. FBI debate has brought up a large number of arguments pro and contra protection from physical attacks.

theandrewbailey 10y ago

From the last section: > To reiterate, these Microsoft-signed resources – the debug-mode policy and the EFI installation tool – are only meant to be used by developers debugging drivers and other low-level operating system code. In the hands of Windows RT slab owners, whose devices are completely locked down, they become surprisingly powerful. > It's akin to giving special secret keys to the police and the Feds that grant investigators full access to people's devices and computer systems. Such backdoor keys can and most probably will fall into the wrong hands: rather than be used exclusively for fighting crime, they will be found and exploited by criminals to compromise communications and swipe sensitive personal information.

RHSeeger 10y ago
Of course, the problem with a digital key is that once it's out in the wild, its out for everyone and forever.
- theandrewbailey 10y ago
  Same issue with a physical one. The solution is the same, too: get a new key (and lock).

andrey_utkin 10y ago

> Isn't a secure boot policy that can be bypassed with physical access more secure than none? Of course it isn't. Impossibility of bypassing is the only reason for secure boot technologies to exist. They are invented so that you are NOT automatically screwed if an attacker has physical access to your device. Secure boot technology is fine in principle, it's just stupid position the manufacturers hold. They ignore recent history. At their own peril, I'd say. https://en.wikipedia.org/wiki/Clipper_chip https://en.wikipedia.org/wiki/Clipper_chip And I'm not even sure physical access factor is strictly necessary for adversarial bypassing. (I'm not a security expert, too.)

bradford 10y ago
>> Isn't a secure boot policy that can be bypassed with physical access more secure than none? >Of course it isn't. Really? Suppose that you are choosing a new device. You can choose one that let's a remote hacker install a rootkit via a malicious website, or you can choose one that let's a hacker install a rootkit only when they have physical access to your device. Which one do you choose, and why is it the latter?
- s_tec 10y ago
  What about the third option, where a hacker can't install a rootkit even if they have physical access? That's what MS tried to build, but is now completely broken.
- deleted 10y ago
  [deleted]
sp332 10y ago
You need admin rights, but not physical access.
- bradford 10y ago
  requiring admin rights for an exploit is certainly a lower barrier to entry than is requiring physical access, but I think my point still stands: if someone has those rights, you're already screwed.

slipstream- 10y ago

MS' own advisory says you don't need physical access (only admin rights).

SideburnsOfDoom 10y ago

Don't the keys normally prevent "people with physical access to the device" from easily updating the firmware? This includes everyone from J. Random Hacker who wants to install on thier own hardware a linux (which might or might not be a good build), and an attacker who has borrowed your device from a hotel room to put some rootkit on it.

csydas 10y ago

I think the basic idea is that with physical access in general, the attacker may have an N% chance of accessing it. The adage about physical access isn't to guarantee they will get access, just that you must consider it as such and react appropriately. The adage isn't a declaration of the state of the machine, it's a declaration on how to respond to its loss. With a backdoor via any means, the attackers now basically have (N+1)% chance of getting that access, and arguably it's much more than a single increment since whereas other exploits "might" exist, these ones will guaranteed exist. The suggestion and complaint isn't that "no secure boot is better than one that's easily bypassed", the complaint is requiring such a bypass and not giving the actual owners of the machine control over setting up that secure boot. With the RT devices, the user has absolutely no say in the secure boot process, and they're entirely dependent on Microsoft or whatever organization to provide best security practices. Also, If the user sets up their own key and does it wrong, they have only themselves to blame. If a company or government does it, the user has no one to blame, since often legal contracts prevent any reparations as result of damage done by stuff like this. The US Government, for reasons of varying validity, needs to give you permission to sue it, meaning they can eschew any complaints should they lose the key. All in all, a mandated backdoor just increases the chance that there will be a violation, takes control away from the user, and provides no compensation if the forced backdoor results in damages to the user.

my123 10y ago

For Windows Mobile RDU, it isn't flashing firmware even :) It's a package to be flashed via iutool. For RT, the official unlocking way is on http://woaunlock http://woaunlock on the MS corporate network.

mtgx 10y ago

> If an attacker has physical access to your device, you're already screwed. Tell that to the FBI. They seem to have been quite upset about not being able to unlock some iPhones. Doesn't anyone wonder why you never seem to hear stories about FBI being unable to unlock encrypted user devices? Surely at the number of people who encrypt their Windows devices is in the tens of millions in the U.S. alone, and some of them must have been caught by law enforcement for various crimes.

TheSpiceIsLife 10y ago

If an attacker has physical access to your device, you're already screwed. I'm no security expert, but is this true? Say I use full drive encryption, with whatever the popular Linux distros are offering at install time, and Say I use a strong password of 30 random characters. Is it feasible to break this encryption in a reasonable time frame?

andrey_utkin 10y ago
See Evil Maid Attack https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html https://www.schneier.com/blog/archives/2009/10/evil_maid_att...
jewel 10y ago
There's a lot that can go wrong if an attacker has physical access to your device. As far as is publicly known, you're not directly vulnerable to having the password broken as long as the device is powered off when it falls into the wrong hands, but there are a lot of caveats. If it's powered on they can possibly extract the password from RAM using a "cold boot attack". They can also freeze the RAM to get its contents to last longer and then moving it to another computer and dump it, recovering your full-disk encryption key. If the attacker has temporary physical access, they have a number of ways that they can tamper with the device. For example, they can replace the BIOS, the bootloader, the firmware on your keyboard, etc. The new code can record your passwords or send your data to the attacker over the internet. One other way that you're physically vulnerable is that the attacker can possibly infect your hardware before it even arrives at your home, by replacing hardware while it's shipping. This is probably only available to nation-states.

IBM 10y ago

>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?

boznz 10y ago
I'm speculating here, but surely by this argument Apple has a backdoor to unlock the phone if it physically has it.
- beagle3 10y ago
  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.
  - MichaelGG 10y ago
    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?
    - asimpletune 10y ago
      My loose understanding is that this is in the works (not an apple employee).
- dredmorbius 10y ago
  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-phone-fbi/#3HUiZbMlzkqk 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. http://fortune.com/2016/04/27/fbi-apple-iphone-crack/ http://fortune.com/2016/04/27/fbi-apple-iphone-crack/

rdtsc 10y ago

Ok but then why bother with whole key thing then? That's a whole lot of code, API crap and other junk why not just force user to hold a key to specifically reboot to reflash / upgrade boot loader. So have to hold the devices in hand to do it. It seems to me the mechanism was created exactly not allow even an owner to boot a non-approved OS image.

cptskippy 10y ago
That was exactly the intent. Service Carriers often require devices be locked because they subsidize them and want to ensure they're only/always viable with their services.

rocqua 10y ago

Secure boot's intentions are to ensure a malicious modified OS cannot run (when taken at face value, there is also the potential for vendor lock-in, but noone will defend it based on that). Remember that I-phone the FBI wanted apple to hack? With this golden key, anyone could've hacked into that I-phone. I am not sure how e.g. bitlocker uses the TPM, but it might be that being able to load a modified OS allows for bypassing OS-implemented rate-limiting on TPM access.

stable-point 10y ago
The TPM controls the rate-limiting. A compromised OS shouldn't affect it. (Otherwise a live CD could compromise your disk encryption, as the encryption is usually done at the OS level, not in the BIOS/EFI).
- rocqua 10y ago
  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.
  - MichaelGG 10y ago
    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 shifty looking from MS, though. Fortunately the broken Windows on ARM model died. Edit: I'd also note that, e.g. console gamers love this stuff. It allows them to pretty much rely on others not being able to cheat very well.
    - rocqua 10y ago
      So does it validate the bios/uefi firmware? Which then in turn can be setup to validate the OS (or not to validate it?)

babesh 10y ago

Like when the government intercepted routers in transit to install their own snooping devices. Now they can do that to all computers and it would be very hard to tell. And now it can be anyone not just the government.

scythe 10y ago

>Isn't a secure boot policy that can be bypassed with physical access more secure than none? Not if the bypass is a zero-day.

rbanffy 10y ago

I think the worst part is that the trusted boot environment can no longer be trusted.