I must be missing something. This claims that it addresses the type of supply chain attack that bit SolarWinds, and the load bearing defense here appears to be digital signatures. Didn’t the malware that got introduced into the SolarWinds product have a valid digital signature?
Maybe I’ll spot what I’m missing after some more coffee.
This claims that it addresses the type of supply chain attack that bit SolarWinds, and the load bearing defense here appears to be digital signatures. Didn’t the malware that got introduced into the SolarWinds product have a valid digital signature?
It’s probably too subtle for Before Coffee o’clock.
I recommend reading Taylor Hornby’s Triangle of Secure Code Delivery.
With Gossamer, it isn’t just signatures. It’s also a transparency log and third-party verification (thus, attestations).
What this buys you is more than “don’t run unsigned code”. It’s also “don’t run code unless it was reproduced by $trustedThirdParty from the source code” and/or “don’t run code unless it’s been reviewed by $trustedVendors” too.
This adds more mechanisms for mitigating supply chain attacks, as well as unavoidable transparency that prevents stealth operation.
Your first key is sorta TOFU but with transparency (since it’s published in the ledger).
There is nothing approximating WOT or key signing parties. Looking at it through the PGP lens will lead to confusion.
To verify keys in advanced threat models, you need only confirm that peers see the same view of the ledger. You can compare Merkle roots (Trillian) or summary hashes (Chronicle). Or the lazy way: query Gossamer Servers in addition to running the Synchronizer locally.
(These ledgers are centralized-publish, decentralized-verify, so we don’t need to deal with distributed consensus.)
so we don’t need to deal with distributed consensus
Not in the sense that you need to find agreement, but you still need to notice when you don’t agree to be able to check if this disagreement is a compromise.
Is there even a failure that a log without distributed inconsensus detection can detect that non-chained simple signatures won’t provide?
That makes sense. FWIW, I have an easier time considering the merits without thinking about the SolarWinds mess. That combined with my earlier lack of caffeine obfuscated it a bit for me.
I like the transparency log, especially.
Now we need reproducible builds in a widespread way to give this some teeth.
Getting the various tools to cooperate to that end is such a headache.
It feels like a relatively small budget spent on sponsoring an easy/reliable way to do it for C and C++ projects that use cmake and autotools would have an outsized impact.
Hi, sarciszewski! This looks quite similar to in-toto + TL (e.g., Rekor[3]). Did you have a chance to review [1] or [2]? how do you think this compares to it?
I wonder if we could merge efforts? or at least ensure interoperability, now that there are some implementations of in-toto in the wild, along with tooling for verification/metadata generation.
Gossamer uses Ed25519 and BLAKE2b everywhere it can. (It only uses SHA384 for WordPress compatibility, and only for prehashing before Ed25519.)
It doesn’t support RSA, SHA256, etc. The cryptography is intentionally very minimalistic, and only uses what libsodium provides. No certificates or X.509 either.
To that end, the ledger currently supported is Chronicle, not Trillian. Adding support for Trillian is an open issue that has received zero feedback from the PHP community.
Interop with other designs is as-of-yet a non-goal for Gossamer, unless it can be guaranteed without increasing the cryptography primitive footprint.
For Composer, its hosting burden would be rolled into Packagist’s.
For WordPress, its hosting burden would be rolled into the WordPress.org servers’.
We’ve run Chronicle on a cheap VPS that gets constantly hammered by thousands of users, due to being queried by Certainty which is used by AzuraCast and password_exposed. Running a primary ledger and exposing a small set of replica instances–and having users query the replica instances–is a really easy way to scale horizontally and keep costs low.
Worst comes to worst, I can personally afford to donate the $50/year for Digital Ocean or LowEndBox for these projects.
Interesting. That is likely the right design, as there would otherwise be problems with e.g. namespacing.
I would like to understand the cryptographic ledger better and how it is protected against abuse. Your link mentions using public keys in the context of server communication, so I’m guessing this mechanism stops random people from adding pure junk to the ledger. I understand from the main page that revocations are handled by adding to the ledger. Is it ever possible to remove something completely from the ledger once the data is on it, or is it there forever? If not, is there a human in the loop to review transactions before they are added to the ledger?
Under what condition and how can a client detect that another client noticed and proved that the log gave an incorrect answer? When does this other client do the additional work to notice this if not every client does that work?
Some incorrect answer of interest: giving a different answer to some clients (split view), an entry that was there before isn’t there any more (truncate), missing entry (as not every client validates the full log), response with an additional entry not seen in the log when walking it, a write was tried but is not seen on trying to read it.
I must be missing something. This claims that it addresses the type of supply chain attack that bit SolarWinds, and the load bearing defense here appears to be digital signatures. Didn’t the malware that got introduced into the SolarWinds product have a valid digital signature?
Maybe I’ll spot what I’m missing after some more coffee.
It’s probably too subtle for Before Coffee o’clock.
I recommend reading Taylor Hornby’s Triangle of Secure Code Delivery.
With Gossamer, it isn’t just signatures. It’s also a transparency log and third-party verification (thus, attestations).
What this buys you is more than “don’t run unsigned code”. It’s also “don’t run code unless it was reproduced by $trustedThirdParty from the source code” and/or “don’t run code unless it’s been reviewed by $trustedVendors” too.
This adds more mechanisms for mitigating supply chain attacks, as well as unavoidable transparency that prevents stealth operation.
Hi Scott! Been a while :) How does one find developer pub keys in Gossamer?
A few ways come to mind:
/verification-keys/:provider-name)But most people will use the easy button:
This returns an array of strings representing the (hex-encoded, IIRC) Ed25519 public keys currently trusted by the universe.
(This actually does up to two of the things I listed, under the hood, depending on config.)
So does trust in a provider’s keys basically come from votes in the transparency log? If so, whose votes do you trust? Is that manual?
New keys are signed by your old keys.
Your first key is sorta TOFU but with transparency (since it’s published in the ledger).
There is nothing approximating WOT or key signing parties. Looking at it through the PGP lens will lead to confusion.
To verify keys in advanced threat models, you need only confirm that peers see the same view of the ledger. You can compare Merkle roots (Trillian) or summary hashes (Chronicle). Or the lazy way: query Gossamer Servers in addition to running the Synchronizer locally.
(These ledgers are centralized-publish, decentralized-verify, so we don’t need to deal with distributed consensus.)
Not in the sense that you need to find agreement, but you still need to notice when you don’t agree to be able to check if this disagreement is a compromise.
Is there even a failure that a log without distributed inconsensus detection can detect that non-chained simple signatures won’t provide?
That makes sense. FWIW, I have an easier time considering the merits without thinking about the SolarWinds mess. That combined with my earlier lack of caffeine obfuscated it a bit for me.
I like the transparency log, especially.
Now we need reproducible builds in a widespread way to give this some teeth.
One of the defined attestation types is
reproduced(i.e. for reproducible builds) for this exact reason.Getting the various tools to cooperate to that end is such a headache.
It feels like a relatively small budget spent on sponsoring an easy/reliable way to do it for C and C++ projects that use cmake and autotools would have an outsized impact.
Well, this is starting with PHP first, not a compiled language yet :)
Add Java to it and you get a pretty decent amount of software more secure.
Hi, sarciszewski! This looks quite similar to in-toto + TL (e.g., Rekor[3]). Did you have a chance to review [1] or [2]? how do you think this compares to it?
I wonder if we could merge efforts? or at least ensure interoperability, now that there are some implementations of in-toto in the wild, along with tooling for verification/metadata generation.
[1] https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias [2] https://bora.uib.no/bora-xmlui/handle/1956/20411 [3] https://github.com/projectrekor/rekor
Gossamer uses Ed25519 and BLAKE2b everywhere it can. (It only uses SHA384 for WordPress compatibility, and only for prehashing before Ed25519.)
It doesn’t support RSA, SHA256, etc. The cryptography is intentionally very minimalistic, and only uses what libsodium provides. No certificates or X.509 either.
To that end, the ledger currently supported is Chronicle, not Trillian. Adding support for Trillian is an open issue that has received zero feedback from the PHP community.
Interop with other designs is as-of-yet a non-goal for Gossamer, unless it can be guaranteed without increasing the cryptography primitive footprint.
Who hosts this ledger? Who pays for it, and how?
For Composer, its hosting burden would be rolled into Packagist’s.
For WordPress, its hosting burden would be rolled into the WordPress.org servers’.
We’ve run Chronicle on a cheap VPS that gets constantly hammered by thousands of users, due to being queried by Certainty which is used by AzuraCast and password_exposed. Running a primary ledger and exposing a small set of replica instances–and having users query the replica instances–is a really easy way to scale horizontally and keep costs low.
Worst comes to worst, I can personally afford to donate the $50/year for Digital Ocean or LowEndBox for these projects.
Is there a single cryptographic ledger in the world, or is it one per e.g. package manager or programming language?
One per microcosm.
Optionally, these can cross-sign onto each other for greater resilience. See cross-signing in Chronicle.
Interesting. That is likely the right design, as there would otherwise be problems with e.g. namespacing.
I would like to understand the cryptographic ledger better and how it is protected against abuse. Your link mentions using public keys in the context of server communication, so I’m guessing this mechanism stops random people from adding pure junk to the ledger. I understand from the main page that revocations are handled by adding to the ledger. Is it ever possible to remove something completely from the ledger once the data is on it, or is it there forever? If not, is there a human in the loop to review transactions before they are added to the ledger?
AuthN/AuthZ for ledger publishing is handled by the existing update infrastructure, which Gossamer treats as a black box.
Everything is immutable: once published, it cannot be removed. Thus, append-only.
Under what condition and how can a client detect that another client noticed and proved that the log gave an incorrect answer? When does this other client do the additional work to notice this if not every client does that work?
Some incorrect answer of interest: giving a different answer to some clients (split view), an entry that was there before isn’t there any more (truncate), missing entry (as not every client validates the full log), response with an additional entry not seen in the log when walking it, a write was tried but is not seen on trying to read it.