Announcement

Collapse
No announcement yet.

AMD, Google, Microsoft & NVIDIA Announce "Caliptra" Open-Source Root of Trust

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

  • #11
    The thing people seem to not be grasping is the fully open source nature of this project. While I'm sure this assemblage of <s>evil</s> corporations could find ways to subvert that with fun loopholes and such, it's at least potentially a good thing.

    Edit: does strikethrough not work?
    Last edited by mahurinj; 18 October 2022, 02:45 PM.

    Comment


    • #12
      In corporate parlance "trusted" = Not allowing you the user to be in control of your HW that you paid for so that corporations are in full control.

      Comment


      • #13
        Originally posted by mahurinj View Post
        The thing people seem to not be grasping is the fully open source nature of this project. While I'm sure this assemblage of <s>evil</s> corporations could find ways to subvert that with fun loopholes and such, it's at least potentially a good thing.
        The thing being open source does not matter, if replacing the software will be impossible.

        Comment


        • #14
          Originally posted by Danny3 View Post
          Another hardware backdoor?
          Every time I see the word "trust", "secure", whatever, I know something is fishy!
          This isn't a backdoor. It's a tool for guaranteeing that the boot environment and boot payload meet a set of security criteria so that it's provably safe from the POV of the engineers of the boot environment and the boot payload.

          Like any tool, it can be abused. It's the abuse that should be concerning, not the tool. Otherwise you should also be upset that there's factories making butter spreaders that could be used to stab you to death.

          I'm all for hardware root of trust. Without it, we can't have trusted compute environments which can safely hold things like our TOTP, FIDO2, fingerprint, etc authentication tokens, and we can't know that our systems haven't been backdoored at the UEFI firmware or boot payload level. If anything, we should be championing even deeper root of trust.

          However, there needs to be legislation put in place to ensure that consumers are protected from black boxes. That includes threats like manufacturer/engineer hubris and sloppy work, state hubris and sloppy work, middleman hubris and sloppy work, and bad actors at all levels. And the only way to ensure that is to legislate that all ROT firmwares and payloads are open-source so that consumers can verify the lack of hubris, sloppy work, and bad acting.

          Failing legislation enforcing open source for ROT firmware and payloads, then we need legislation enforcing 100% at retail taxation of black-box firmware and payloads, with the proceeds going towards consumer protection, and for that taxation to show up on the receipt so that consumers are painfully aware of the cost.





          Last edited by linuxgeex; 18 October 2022, 03:01 PM.

          Comment


          • #15
            Originally posted by linuxgeex View Post
            I'm all for hardware root of trust. Without it, we can't have trusted compute environments which can safely hold things like our TOTP, FIDO2, fingerprint, etc authentication tokens, and we can't know that our systems haven't been backdoored at the UEFI firmware or boot payload level. If anything, we should be championing even deeper root of trust.
            Just because it is open source does not mean the actual implementation as ship by vendors can or will not contain backdoors. I would rather assume that it is likely for some vendors to put backdoors into it, especially since it is open source and thus easier to modify. Sort of a "bait and switch"-tactic - bait the open source community to make it secure, then use it against them and put your own backdoor in.
            Last edited by sdack; 18 October 2022, 03:27 PM.

            Comment


            • #16
              Originally posted by Mat2 View Post
              The thing being open source does not matter, if replacing the software will be impossible.
              That is the core of the problem, hardware roots of trust, remote attestation, etc aren't necessarily evil by themselves.
              But they do create all the necessary foundations for corporations to take away any control users have over their devices.
              Google already started enforcing this with SafetyNet, Apple also has their mobiles very well locked down.
              Microsoft is very likely to be the next to try it, given they are developing Pluton.

              So in practical terms, new hardware-backed "security measures" are very likely to be bad news for user freedom.

              Comment


              • #17
                linuxgeex remember UEFI approval by MS ?

                Comment


                • #18
                  Originally posted by sdack View Post
                  Just because it is open source does not mean the actual implementation as ship by vendors can or will not contain backdoors. I would rather assume that it is likely for some vendors to put backdoors into it, especially since it is open source and thus easier to modify.
                  The difference is similar to leaving your bicycle locked at the entrance to a mall for 8 hours during the day, or for 8 hours overnight. During the day, with many eyes on it in broad daylight, it's much less likely to be stolen. Same thing with open source. It's not that it's impossible for bad actors to infiltrate open source in sneaky ways. However, once any backdoor has been discovered on one product, it becomes very easy to identify it on another product, because they are known to have the same sources. So there's orders of magnitude more chance of it being caught and removed, vs with a black box.

                  With a black box, manufacturers can be perfectly aware/wilfully ignorant of backdoors, happily accepting that their customers are being exploited because their shareholders can have larger yachts vs consumers having safer purchases. At least until there's specific CVEs against their products and bad press begins to motivate them.

                  Open source isn't a magical fix, but at least it makes problems visible enough that they can be recognised and addressed without years-long reverse-engineering projects, like happened with Intel ME.

                  When you say a vendor implementation - you imply shipping a black box based on open sources. That is completely ignoring the purpose and intent of the safety argument I was making - that the payload itself must be 100% open source. This can be proven. It can have a binary signature matching a hash of the binaries compiled with a specific version of GCC/LLVM/etc - the same way the SecureBoot versions of the Linux Kernel are done. Under my proposed protection, if a vendor shipped such a blob, it would either be against the law to sell, or be 100% taxable at retail.

                  The most important thing is that when a manufacturer ships something with a claim that it is secure, using a ROT, then either it must be provably secure by having a fully open implementation, or optionally, jurisdictions must enforce its security claim by taxing sales of it in order to create a consumer protection slush fund - which will make black boxes uncompetitive.

                  Let's face it, black boxes are more about avoiding patent licensing fees, "protecting IP", and hiding anti-consumer behaviour, than it is about backdoors. What we really want is to know that our products aren't turning us into unwitting products to be sold on black/grey markets.
                  Last edited by linuxgeex; 18 October 2022, 04:02 PM.

                  Comment


                  • #19
                    Michael

                    Typo/Grammar

                    "to be found with future" should probably be "to be found in future"

                    "Interestingly the reference implementation of caliptra makes use of a RISC-V core." should be "Interestingly, the reference implementation of Caliptra makes use of a RISC-V core." (missing comma and capitalization)

                    "As for the silicon Root-of-Trust goals with caliptra, per the new specification its stated goals are:" should be "As for the silicon Root-of-Trust goals with Caliptra, per the new specification, its stated goals are:" (missing capitalization. As written, this needs a comma).

                    Comment


                    • #20
                      Originally posted by mahurinj View Post
                      The thing people seem to not be grasping is the fully open source nature of this project.
                      The hardware part is still a blackbox. I couldn't see if it includes saving cryptokeys in the hardware but I would assume so. And that bends the word trust a little to far for me.

                      Comment

                      Working...
                      X