4 ms·

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 n

by 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)
        cptskippy 10y ago
        > Google sells phones with unlocked boot loaders They also sell carrier editions with locked boot loaders just like everyone else. Locking boot loaders is usually a carrier requirement imposed on manufacturers, not something OEMs arbitrarily decide to do, unless you're TP-Link. > have similar "Developer Mode" support for Chromebooks. CoreBoot on Chromebooks is just as locked down as UEFI Secure Boot if not more so. The RW Firmware isn't loaded unless the RO Firmware permits it and you can't modify or replace the RO Firmware by software. It requires hardware modification. Enabling Developer Mode on a Chromebook is analogous to disabling Secure Boot in UEFI. > Samsung and Apple to the best of my knowledge do not sell unlocked phones but do sell unlocked laptops). Samsung UEFI laptops have been known to brick if you try to boot Linux, not fail to boot but BRICK. Apple's laptops are absolutely locked down using EFI, you can't install any other OS unless Bootcamp allows it. > Microsoft requires, on x86, that trust of the MS key be preinstalled and that it be possible to turn off UEFI Secure boot is a security feature that validates code prior to execution via PKI in a signature database. The PK, is created and owned by the OEM and it can add KEKs from vendors (or distros) to allow them to sign their code. This database is owned, controlled and populated by the OEM, not Microsoft. Microsoft has no control over it beyond making their software refuse to function on not compliant systems. However the purpose of the feature is the inverse of that. That being said, there are several Linux Distros that support Secure Boot and offer PKIs for vendors. Starting with Windows 8.1, Microsoft requires that new systems support Secure Boot have it enabled with Microsoft's PKI. That doesn't stop you from disabling it to use another OS. It doesn't inherently lock anyone out using whatever software they want, that decision is made by the vendor. The whole point of the system is to protect users from a compromised system, if someone tampers with Windows or it's drivers then the UEFI will refuse to boot it. It has absolutely nothing to do with locking people out. Now on their RT/Mobile devices you can't disable UEFI Secure Boot. That's akin to locked ROMs and it's a requirement from Microsoft. There's no expressed reason for this but it's obviously because Microsoft gives OEMs subsidies to make Windows RT/Mobile devices so the hardware is often less expensive than comparable Android hardware. The last thing MS wants is for people to replace Windows on the devices with CyanogenMOD. > They've started with restricting kernel drivers in the "anniversary edition". Your implication is that this is a user hostile action when it's really a security measure to prevent naive users from installing hostile drivers. You can disable the feature by turning on developer mode. Now that's ok for Google's Chromebooks but not Windows? You're attacking Microsoft for things you're giving everyone else a pass on.
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.

by Knuff 10y ago

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)
      - cptskippy 10y ago
        > Google sells phones with unlocked boot loaders They also sell carrier editions with locked boot loaders just like everyone else. Locking boot loaders is usually a carrier requirement imposed on manufacturers, not something OEMs arbitrarily decide to do, unless you're TP-Link. > have similar "Developer Mode" support for Chromebooks. CoreBoot on Chromebooks is just as locked down as UEFI Secure Boot if not more so. The RW Firmware isn't loaded unless the RO Firmware permits it and you can't modify or replace the RO Firmware by software. It requires hardware modification. Enabling Developer Mode on a Chromebook is analogous to disabling Secure Boot in UEFI. > Samsung and Apple to the best of my knowledge do not sell unlocked phones but do sell unlocked laptops). Samsung UEFI laptops have been known to brick if you try to boot Linux, not fail to boot but BRICK. Apple's laptops are absolutely locked down using EFI, you can't install any other OS unless Bootcamp allows it. > Microsoft requires, on x86, that trust of the MS key be preinstalled and that it be possible to turn off UEFI Secure boot is a security feature that validates code prior to execution via PKI in a signature database. The PK, is created and owned by the OEM and it can add KEKs from vendors (or distros) to allow them to sign their code. This database is owned, controlled and populated by the OEM, not Microsoft. Microsoft has no control over it beyond making their software refuse to function on not compliant systems. However the purpose of the feature is the inverse of that. That being said, there are several Linux Distros that support Secure Boot and offer PKIs for vendors. Starting with Windows 8.1, Microsoft requires that new systems support Secure Boot have it enabled with Microsoft's PKI. That doesn't stop you from disabling it to use another OS. It doesn't inherently lock anyone out using whatever software they want, that decision is made by the vendor. The whole point of the system is to protect users from a compromised system, if someone tampers with Windows or it's drivers then the UEFI will refuse to boot it. It has absolutely nothing to do with locking people out. Now on their RT/Mobile devices you can't disable UEFI Secure Boot. That's akin to locked ROMs and it's a requirement from Microsoft. There's no expressed reason for this but it's obviously because Microsoft gives OEMs subsidies to make Windows RT/Mobile devices so the hardware is often less expensive than comparable Android hardware. The last thing MS wants is for people to replace Windows on the devices with CyanogenMOD. > They've started with restricting kernel drivers in the "anniversary edition". Your implication is that this is a user hostile action when it's really a security measure to prevent naive users from installing hostile drivers. You can disable the feature by turning on developer mode. Now that's ok for Google's Chromebooks but not Windows? You're attacking Microsoft for things you're giving everyone else a pass on.

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.