bluegate010
Joined 14 years ago
Karma
274
Submissions
39
Member since
Jan 19
Recent submissions
Comment · 3 years ago
Comment · 3 years ago
Another talk about LMS / SPHINCS+: https://www.youtube.com/watch?v=lZ1PnJml1CY
Comment · 3 years ago
Not a stupid question. CDIs are groovy for minting secrets that are bound to the exact firmware that's running, but are a bit less ergonomic out of the box when it comes to keeping long-lived secrets around across a firmware update. Firmware changes --> CDI changes --> anything derived from or sealed to the CDI is gone, by design.
A more ergonomic approach for sealing long-lived data is to use something like a hash chain [0], where the chain starts with the equivalent of a DICE UDS, and the chain's length is (MAX_VERSION - fw.version). The end of that chain is given to firmware, and the firmware can lengthen the chain to derive older firmware's secrets, but cannot shorten it to derive newer firmware's secrets.
This presumes that the firmware is signed of course, since otherwise there'd be no way to securely associate the firmware with a version number. If the public key is not baked into the HSM, then the hash of the public key should be used to permute the root of the hash chain.
Comment · 3 years ago
Comment · 5 years ago
It sounds like, unless someone is an owner or maintainer of a critical open-source project, the blog post isn't necessarily calling for that person's deanonymization. For projects that are both critical and owned/maintained by anonymous entities, I think it's reasonable for an organization to think twice before taking a dependency on such projects, given the sort of anonymous attacks mentioned in the article.
Disclaimer: opinions are my own, not my employer's (Google)
Comment · 5 years ago
From the second link:
> It is conceivable that contributors, unlike owners and maintainers, could be anonymous, but only if their code has passed multiple reviews by trusted parties. It is also conceivable that we could have “verified” identities, in which a trusted entity knows the real identity, but for privacy reasons the public does not. This would enable decisions about independence as well as prosecution for illegal behavior.
Comment · 8 years ago
Many of us on the Asylo team share your reservations about DRM. However, the capability to run software in a not-entirely-trustworthy environment leads to many positive possibilities. For instance, you could imagine a world in which customers didn’t have to trust their cloud vendor or worry about their data falling into unauthorized hands. Or you could implement chat applications which can prove to you that your communications really are being encrypted end-to-end.
In our view, trusted computing has applications well beyond DRM.
Comment · 8 years ago
Asylo is not tied to EPID; the framework aims to abstract away any unique behavior specific to TEE implementations, and provide a common backend interface that developers can code against. The goal is to allow developers to easily migrate their apps between backends with little to no source-code changes.
Specifically for attestation purposes, Asylo defines the EnclaveAssertionGenerator[1] and EnclaveAssertionVerifier[2] interfaces; these will need technology-specific implementations.
In this initial release we only support a simulated backend, for experimental development. We'll continue looking into specific TEE technologies going forward.
[1] https://github.com/google/asylo/blob/master/asylo/identity/e...
[2] https://github.com/google/asylo/blob/master/asylo/identity/e...
Comment · 8 years ago
Thanks for the helpful feedback. To answer your question: Asylo is currently x86 specific and provides a simulated enclave backend. We plan on evaluating additional enclave technologies going forward, with the goal of supporting those which gain the most market traction and community support.
Obvious disclaimer: currently working at Google on Asylo.
Comment · 9 years ago
A couple practical benefits of Titan is that we can use it in many different environments where traditional secure boot is not available. For example, we're using it in both servers and in our custom networking card.
In addition, traditional secure boot doesn't give us a hardware root of trust, nor does it enable tamper-evident logging.
Comment · 9 years ago
Titan is one of the tools we use to protect against tampering, even down to the bootloader.
Comment · 9 years ago
If the flash chip holding the boot firmware isn't really a flash chip, then indeed this could present an issue. However, since Titan interposes between flash and the PCH/BMC, it can observe the bytes actually being served.
Comment · 9 years ago
Titan is just one of several measures we take to harden our stack, and helps us be confident in the software we run. It's a good point though, there are no absolutes in security.
Comment · 9 years ago
The log signing prevents undetected tampering after-the-fact; the goal is to make it readily apparent when log messages are altered or deleted, even by parties with root access.
Video: https://youtu.be/F-Y7fhIasjM