This feels like a somewhat odd design choice - you have a TEE, most TEEs (outside TPMs) are fast so there's little overhead in pushing your signing through there, why bother with short-lived credentials instead of just attesting to private key material ownership and having that be what the SPIFFE cert is issued to? Bearer token SVIDs are an awful thing that we should be getting as far away from as possible.
I helped design the attestation framework for https://docs.cloud.google.com/transfer-appliance/docs/4.0/re... - the goal was to ensure that the device you're about to copy a bunch of sensitive information onto is actually the device you were shipped and is running the expected software. This is definitely used in the real world.
A dedicated HSM will give you stronger trust that the private key material can't be extracted, but there's no real way to bind an HSM to a specific client and that's a very easy thing to do in the vTPM case.
How often do we need to bind a specific machine to a specific key in the case of TLS?
In every case of TLS I've seen we are concerned with organizational identity, not machine identity. This effectively extends to client certificates in cases like B2B & vendor integration.
In both scenarios you would definitely want to use an HSM style solution.
Protecting the HSM from inappropriate use (proving you are allowed to sign using the keys within) is a problem orthogonal to protecting the key material. In cloud HSM applications, you often combine the cloud vendors managed identity solution and HSM policies to effectively bind a set of machines to a set of keys.
Any time you've got hardware and want to attest that it hasn't been tampered with before allowing it to interact with something like an API endpoint.
At work we deploy industrial IoT gateways, these are very much not end-user devices. We are actually concerned about the device's identity, and more specifically about being able to attest that the device is in fact the one we thought it was and it hasn't been tampered with. By putting the key for TLS client certificate in the device's TPM, locked behind attestation that what's been booted is what we expected to boot, we can have a reasonable degree of confidence that we're communicating with the device we thought we were rather than just someone who managed to copy the private key off disk.
In the given case - you want to bind communication to a given confidential compute instance, which means you want to be able to ensure that the communication is coming from within the confidential compute instance, which means you want to be able to prove that the private key is only accessible from within that instance. An HSM buys you nothing more there.
The benchmarks are from GCP, where the vTPM is implemented in the hypervisor rather than on something that's plausibly an 8051[1]. Doing this on actual client hardware is going to be a bunch slower.
[1] Typically ARM these days, but most system vendors aren't picking TPM vendors based on performance
What mjg59 says. The benchmarks are against a vTPM, that was what I had access to, and it's the environment I'm implementing the RATS side in.
Worth adding that not every outbound connection needs to go through the TPM (IMO). It's for the handful of services where the machine-identity actually matters, a secret store, or an HSM releasing key material onto an attested confidential VM, in my case.
You didn't really go into actually verifying the machine identity - obviously if you have a trusted mechanism to do that in advance then that's easy enough, but otherwise you'd want something like https://github.com/google/go-attestation and then to use control plane APIs to identify the vTPM EK to tie the TPM to the VM.
I teach OS security for a masters course. I don't know where my students are for any given semester - it's a mixture between experts who need a certification (I have taught someone who literally wrote the book on a major OS's security model) and people who have ended up on security entirely by accident. It is extremely hard to write something that lands for that entire range. "Finished highschool" is really not a precise determinator in the way "I am literally 5" is.
If distributing under 3(b) then it's legitimate to only supply source on request. Historically source has been distributed without revision control history or metadata and been considered acceptable (the source tarballs on gnu.org are snapshots, for instance) so I think the preferred form argument is also tricky. I agree that there's huge value in having the individual commits, but from a GPL perspective we had this argument when Red Hat started flattening all patches in the RHEL kernel source 15 years ago.
When the build system expects a certain metadata which is removed by the force pushes or tag removal, then that is arguably not the preferred form. Grapheneos notes this elsewhere in the thread. [1]
I've been wondering about the Red Hat model! Seems like so much of modern development involves git blame or whatever to make sense of how the code came to be, and sometimes rule out an "obvious" modification that actually turns out to be a bad idea now that you know the historical context.
GrapheneOS might have a better case though if it's not just about understanding the code but about how the Android build system expects that everything is in Git.
I don't know what "Red Hat model" you mean, but if you're referring to their code delivery: It's not a problem for their internal developers, because they can use git lol. You can theoretically go to the upstream projects individually and merge the code drop with their nearest branch, and THEN do git blame/diff to figure out the delta and history of some lines of code. There are probably a few upstream open-source projects out there with no public VCS, but those are rare.
The license requires that it be distributed on a medium customarily used for software interchange, and I don't think you'd stand a good chance of arguing that paper satisfies that.
My personal website isn't customarily used for software interchange, but http is. I think getting into discussions about which websites are acceptable and which aren't feels like a bad place.
Unfortunately, I know more than a few companies who do that. The same kind of developer who used SourceSafe to just checkout the entire project (thus locking it) while busy with it. And then pop a intranetcrm_200826_0713.zip on SharePoint. Enough of them around still unfortunately.
1) floppy disks are not customarily used for software interchange - where they are still used (aircraft software updates, bits of San Francisco's streetcar infrastructure) it's weird enough to be remarked upon.
2) the cost to Google of finding enough working floppies and paying someone to dump that much code onto them, then mailing them out, then having the other end just say "disk 323 was corrupted by USPS X rays, please send again" 20 times, would massively outweigh the benefits of making this awkward
Mostly agreed. However you can solve the problem of having x% of disks corrupted via error correcting codes. It's what Google already does for their own internal storage: when you own millions of hard disks, some of them will inevitably fail.
It was initially taking under a business day for them to respond, but our recent requests have often taken weeks for them to get back to us. We want the code for all the Beta releases and are entitled to it.
There are other branches there with it for Android 17 QPR1 Beta and Android 17 QPR2 Beta.
Google could save everyone including themselves a lot of hassle by simply publishing it to GitHub. If they don't want to push it to AOSP for weird organizational reasons as part of saying AOSP doesn't support Pixels, fine. Taking weeks or more to get back to us isn't reasonable for one the largest tech companies in the world.
It's also questionable whether what they're providing is truly the preferred form for modification considering the build system is quite unhappy about the lack of Git repositories. They had to provide a repo manifest metadata file to work around part of it.
It also isn't only them pushing the boundaries of the GPL.
Pixel 9a and earlier were sold as the official Android Open Source Project (AOSP) reference devices. They made a commitment to providing 7 years of updates for the Pixel 8 and later. Android 16 declared Pixels were no longer AOSP reference devices and stopped providing any support for them. From our perspective, Google hasn't fulfilled their update commitment for the Pixel 6 through Pixel 9a. It's fair to say the Pixel 10 and later weren't sold as AOSP reference devices and didn't have any commitment to providing sources as part of the updates, but that isn't the case for the earlier devices.
No it's not, because "one person" has to keep sitting up and begging for access, every time there's a new release, over and over and over and over and over.
Submitting the form isn't too hard, so there's not much to be gained by getting a non-affiliated volunteer to do it. Also if they're not the ones requesting it, it becomes hard to ascertain the authenticity of the links (eg. it doesn't contain a backdoored kernel).
My experience is that they're better than me at a lot of the process, so probably worse than someone who's a full time reverse engineer but as good as or better than most. They'll definitely get some small details wrong that would derail the entire thing, so having some skills that are pretty much "This smells wrong" helps a lot, but I think for many scenarios they'll unblock someone who has little RE experience.
reply