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

  • Teggs
    replied
    Originally posted by Phoronix
    AMD, Google, Microsoft & NVIDIA
    I'd be interested if it was developed by Jason Donenfeld, not this rogue's gallery.

    Leave a comment:


  • dp_alvarez
    replied
    stormcrow Has Pluton been dropped? Do you have a link to that? AMD has indeed been very silent about it since the announcement.
    That would be relieving. fTPM is still very much enabled and active on most systems so there is still a way to implement remote attestation (which is the biggest threat), but much less dangerous.

    Leave a comment:


  • Jabberwocky
    replied
    Originally posted by jabl View Post
    How does this compare to https://opentitan.org/ ?
    I would like to know too.

    It's funny that Google is on both Caliptra and opentitan

    Leave a comment:


  • sdack
    replied
    Originally posted by linuxgeex View Post
    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.
    You go ahead and tell yourself whatever you want. Building a nuclear bomb and painting the red cross onto it does not change what it will do. You only took the bait, mate.

    Leave a comment:


  • timofonic
    replied
    Oh no, all this again...

    Leave a comment:


  • stormcrow
    replied
    Originally posted by dp_alvarez View Post

    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.
    Pluton as hyped is pretty much DOA. I believe even AMD who announced support for it, has quietly dropped it from upcoming iterations.

    But, the thing about "root of trust" is that you must be able to verify from source code to deployment to execution. AND you have to be able to verify that the root is actually authentic - it hasn't been usurped. Unless there is a method of verifying all the way from source code to actual execution then it doesn't matter if the whole thing is open source because you can't verify that source revision is actually what's running on the hardware. The devil, as usual, will be in the details and generally speaking none of these companies have been particularly good at transparency. In fact, outside of AMD possibly, they're all particularly bad at it, especially Microsoft and Nvidia. And then there's Google who never met a project they didn't want to kill.

    We'll have to wait and see.
    Last edited by stormcrow; 18 October 2022, 05:26 PM.

    Leave a comment:


  • Anux
    replied
    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.

    Leave a comment:


  • JEBjames
    replied
    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).

    Leave a comment:


  • linuxgeex
    replied
    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.

    Leave a comment:


  • CochainComplex
    replied
    linuxgeex remember UEFI approval by MS ?

    Leave a comment:

Working...
X