Announcement

Collapse
No announcement yet.

Linux Group Files Complaint With EU Over SecureBoot

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by Sonadow View Post
    I don't even need to do that because you are the one who has proven himself to be too obstinate to listen to logic. Every single last allegation or claim you cooked up in the previous pages have been soundly and utterly debunked by Matthew himself, the writer of the shim loader that is being used by Ubuntu, OpenSUSE and Fedora to boot Linux with SB enabled.
    As long as we're appealing to authority, Linus himself has said secure boot does not improve security and is pointless the way it is implemented.

    You made wild allegations about Microsoft distributing keys when Microsoft NEVER distributes keys.
    Microsoft decides who gets the keys. Same diff.

    You conveniently ignored the fact that users CAN and HAVE the ability to enroll their own user-generated keys into the UEFI key lists. Mathhew and Bottomley have ALREADY published extensive information on this in their blogs.
    I ignore nothing. Doesn't really matter as it is not a realistic thing to expect from the average user who just wants to try some other OS.

    You conveniently ignored the fact that abused keys can be shut down by Microsoft, OpenSUSE, Fedora, Ubuntu since they are within the circle of trust with regards to signing., and also ignored Matthew's report that SB keys are NOT obsfucated, just plain RSA keys.
    Hooray, so there are three distros kissing MS ass and enabling their behaviour. Circle of trust? Rather, a circle-jerk of trust - and you can be sure it won't be microsoft that ends up eating the cookie...

    Seriously, I don't really want Canonical, Redhat or OpenSUSE controlling my hardware either.

    You made a wild claim that Verisign is in Microsoft's pocket when their only job is to validate the requester's identity, NOT to sign the keys.
    Doesn't really matter. We all know it's microsoft that controls who gets signed and who doesn't. Microsoft decides the qualifications, and has veto power over signing.

    You made a wild claim that Microsoft is against signing FOSS binaries just because they refuse to sign GPLv3-licensed binaries when they have clearly demonstrated that they are perfectly fine with signing GPLv2 binaries. You conveniently ignored the facts once again that Microsoft is simply adverse to GPLv3. Matthew himself pointed out this fact explicitely.
    Yes, just the most commonly used bootloader in the linux world is GPLv3-licensed. No coincidence there. Microsoft is adverse to GPLv3 because they're adverse to freedom.

    You made a ridiculous claim of fact that anybody can grab hold of Red Hat's and the LF's keys when those keys are not even distributed, period. All that is distributed is a signed binary, NOT the signing key.
    I haven't made such a claim. But anyone can pick up Red hat's or LF's bootloader, and those bootloaders (at least LF's) can be used to bootload anything. This type of single-source-of-trust model simply isn't compatible with free software where anyone can modify their kernels.

    Every last word I have discussed in this topic can be backed up by Bottomley, Matthew AND Microsoft, the first 2 of which are authorities on this whole hoo-ha with SB support for Linux. YOU, on the other hand, have nothing to back your claims other than the tired 'Microsoft-has-screwed-people-over-before-so-they-will-do-it-again-with-SB' paranoia.
    More appeals to authority? Ok. Let me just remind you then, that a definition of insanity is doing the same thing over and over, and expecting different results. Plenty of people have trusted microsoft, and every time they have gotten burned by it - the history is full of examples. But now you say they have changed their evil ways and we should (again) give them another chance... ok, feel free to put your trust in microsoft if you wish, but don't force that decision on others.

    You have proven that you have no qualms about lying your way through when the black-and-white facts have already been thrown against your face just to justify your crusade against Microsoft and you still can accuse me of spouting nonsense when I call your bluff. Who's the one making up points and spreading FUD now?
    I accuse people of spouting nonsense when they do so. You are still spouting nonsense. You think we should just bend over and accept microsoft's control over our hardware and software, when it's clear that trusting microsoft is the most stupid thing anyone can do - just look at Nokia, they trusted microsoft, and look where it got them... why should we trust microsoft when they constantly attack Linux and other free software with software patents? When they are trying to artificially inflate the cost of using Linux in order to be competitive with it? When they are trying to exert control over the development of Linux?

    EDIT: Congratulations, you are the second person to have actually succeeded in making me lose my cool over a single forum post. Achievement unlocked.
    No need for congratulations, it was pretty easy, after all.

    Comment


    • Originally posted by nomadewolf View Post
      Doesn't matter. With enough time and processing power it can be done.
      You're right, with enough time and processing power it can be done. Current estimates are that if you had an incredible amount of computing power available you might be able to break the key by 2030. At which point everyone can just migrate to a new key without even requiring a firmware update.

      Also, and much easier, Linux Foundation will provide a general bootloader with a kernel which in turn will be responsible to boot the various, numerous distros around. All that a hacker has to do is to use that.
      The Linux Foundation have already provided their general bootloader. Please do demonstrate how it could be used to launch malware.

      There's no way Microsoft will be able to ban and create new keys at the same pace as they're exploited.
      Time taken to generate a 2048-bit RSA key: significantly less than a second
      Time taken to crack a 2048-bit RSA key: Over 15 years

      SecureBoot, is not secure!!!
      More exclamation marks don't make it more true.

      Comment


      • Originally posted by TAXI View Post
        1) Write some malicious software which simply modifies the hosts file so the address for microsofts update server points to another (your own / a compromised) one.
        2) Wait for windows to start the next automated update.
        Ok so far.

        3) Now do a man-in-the-middle attack
        Which will fail because the SSL certificate will fail to validate. But even if it succeeded...

        and when it goes to updating UEFI keys tell the microsoft key has been compromised and must be replaced. Give your own key (signed with the tools some guys use (someone in this thread wrote about it) or pay $99).
        No. You never receive a signing key (Microsoft keep that), and it doesn't matter, anyway - the key used to sign blacklist/whitelist updates is completely different.

        4) While doing the regular update also give a compromised update for the MBR (or whatever UEFI boots from) signed with the key from 3).
        And, as a result, this won't work.

        What would stop a hacker from doing this to compromise your "secure" boot?
        Cryptography.

        Comment


        • His example may not have been the most technically sound, but in some way or another it's going to be hacked. It'll probably be in some way that the Secureboot developers never even thought of.

          Comment


          • Originally posted by duby229 View Post
            His example may not have been the most technically sound, but in some way or another it's going to be hacked.
            You keep saying that. And, like I said, specific implementations may well be hacked. But I have not found a single actual security expert who believes that it's fundamentally broken.

            Comment


            • Originally posted by mjg59 View Post
              No. You never receive a signing key (Microsoft keep that), and it doesn't matter, anyway - the key used to sign blacklist/whitelist updates is completely different.
              Wait, whose key is that, then?

              Comment


              • Originally posted by GreatEmerald View Post
                Wait, whose key is that, then?
                DB updates? Microsoft or your hardware vendor.

                Comment


                • It's just a matter of time. I don't have any empirical evidence to show, but just past history tends to repeat itself. every single "unhackable" "security" measure has been hacked. All of them. I'm certain that Secureboot won't be any differnet. Especially with the amount of resources being put into its demise.

                  Comment


                  • Originally posted by mjg59 View Post
                    DB updates? Microsoft or your hardware vendor.
                    Hum. If you remove the MS keys, then it should ignore updates signed by Microsoft, right? And if it has to be signed by the hardware vendor, fair enough, but it sounds like something hardware vendors would be lazy to do and neglect. Especially given that there are plenty of different hardware vendors, and they all have to personally sign the same update.

                    Comment


                    • Originally posted by GreatEmerald View Post
                      Hum. If you remove the MS keys, then it should ignore updates signed by Microsoft, right? And if it has to be signed by the hardware vendor, fair enough, but it sounds like something hardware vendors would be lazy to do and neglect. Especially given that there are plenty of different hardware vendors, and they all have to personally sign the same update.
                      There's two relevant levels of key here. Keys in DB control whether or not something will boot. Keys in KEK are used to authorise updates to DB. Microsoft have a key in DB (which means they can sign things that boot systems) and a key in KEK (which means they can sign updates for the blacklists and whitelists). If you replace Microsoft's key in DB then you probably also want to replace Microsoft's key in KEK.

                      Comment


                      • Originally posted by mjg59 View Post
                        There's two relevant levels of key here. Keys in DB control whether or not something will boot. Keys in KEK are used to authorise updates to DB. Microsoft have a key in DB (which means they can sign things that boot systems) and a key in KEK (which means they can sign updates for the blacklists and whitelists). If you replace Microsoft's key in DB then you probably also want to replace Microsoft's key in KEK.
                        Yea, that's good to know.

                        Comment


                        • Originally posted by duby229 View Post
                          It's just a matter of time. I don't have any empirical evidence to show, but just past history tends to repeat itself. every single "unhackable" "security" measure has been hacked. All of them. I'm certain that Secureboot won't be any differnet. Especially with the amount of resources being put into its demise.
                          All of them? Where's the jailbreak for the AppleTV 3? Where's the boot-level jailbreak for iOS 6 on the iPhone 5? There's several Android devices that have locked bootloaders and no workaround.

                          Comment


                          • Are you asserting that an unhackable system is possible?

                            Comment


                            • Originally posted by mjg59 View Post
                              All of them? Where's the jailbreak for the AppleTV 3? Where's the boot-level jailbreak for iOS 6 on the iPhone 5? There's several Android devices that have locked bootloaders and no workaround.
                              Maybe not yet, but they will. Just like everything else they will.

                              Comment


                              • Originally posted by duby229 View Post
                                Maybe not yet, but they will. Just like everything else they will.
                                So when you said
                                every single "unhackable" "security" measure has been hacked. All of them.
                                , you were wrong?

                                Comment

                                Working...
                                X