4 ms·

I've been working on technology like this for the past six years. The benefits of transparent systems are likely considerable. The combination of reproducible

by kfreds 2y ago

I've been working on technology like this for the past six years. The benefits of transparent systems are likely considerable. The combination of reproducible builds, remote attestation and transparency logging allows trivial detection of a range of supply chain attacks. It can allow users to retroactively audit the source code of remote running systems. Yes, there are attacks that the threat model doesn't protect against. That doesn't mean it isn't immensely useful.

deleted 2y ago
[deleted]
dboreham 2y ago
I've also worked in this field but it feels like a foundation built on quicksand. You depend on so many turtle layers and only one of them has to be adversarial and game over.
- bitexploder 2y ago
  Each layer needs more than one safeguard then. If breaking the layer breaks the system then the layer needs better safe guards.
- kfreds 2y ago
  > it feels like a foundation built on quicksand. You depend on so many turtle layers and only one of them has to be adversarial and game over Interesting. Please elaborate. Here's how I see it. Reproducible builds: I think we'll eventually see Linux distributions like Debian make reproducible builds mandatory by enforcing it in apt-get's trust policy. The trust policy could be expressed as "I will only trust .deb packages where their build hash and source hash are signed by three different build pipelines I trust". Remote attestation: If you ensure that the server's CPU SoC and the TPM have different supply chains, you could construct a protocol where the supply chain attacker would have to own both supply chains in order to impersonate the server. Transparency logging: One of the projects I've been working on for the past four years is Sigsum (sigsum.org). It is a transparency log with distributed trust assumptions. Our goal was to figure out the essence of transparency logging technology, identify the most significant design parameters, and for each parameter minimise the attack surface. You'll find the threat model on our website. Here's a recent presentation by my colleague Rasmus on the subject: https://www.youtube.com/watch?v=Mp23yQxYm2c https://www.youtube.com/watch?v=Mp23yQxYm2c Here's a recent presentation by me on the subject of system transparency / runtime transparency / the technology underlying Apple PCC: https://www.youtube.com/watch?v=Lo0gxBWwwQE https://www.youtube.com/watch?v=Lo0gxBWwwQE
  - 1oooqooq 2y ago
    sadly linking to youtube this week is like linking to xitter earlier. i cannot see any of the content as google now requires me to create an account. ironically when talking about losing control of cloud compute.
    - quite 2y ago
      Mmm. These kind of project should really post videos on or even host a PeerTube instance
- liuliu 2y ago
  I think the only shaking part, is the Secure Enclave, which provides the root of the guarantees. From there, everything is attested so if one layer is adversarial, other layers can notice.
bitexploder 2y ago
The xz backdoor would have been a yawn instead the many hands fire drill it was at most big orgs. It was scary.

by kfreds 2y ago

deleted 2y ago

[deleted]

dboreham 2y ago

I've also worked in this field but it feels like a foundation built on quicksand. You depend on so many turtle layers and only one of them has to be adversarial and game over.

bitexploder 2y ago
Each layer needs more than one safeguard then. If breaking the layer breaks the system then the layer needs better safe guards.
kfreds 2y ago
> it feels like a foundation built on quicksand. You depend on so many turtle layers and only one of them has to be adversarial and game over Interesting. Please elaborate. Here's how I see it. Reproducible builds: I think we'll eventually see Linux distributions like Debian make reproducible builds mandatory by enforcing it in apt-get's trust policy. The trust policy could be expressed as "I will only trust .deb packages where their build hash and source hash are signed by three different build pipelines I trust". Remote attestation: If you ensure that the server's CPU SoC and the TPM have different supply chains, you could construct a protocol where the supply chain attacker would have to own both supply chains in order to impersonate the server. Transparency logging: One of the projects I've been working on for the past four years is Sigsum (sigsum.org). It is a transparency log with distributed trust assumptions. Our goal was to figure out the essence of transparency logging technology, identify the most significant design parameters, and for each parameter minimise the attack surface. You'll find the threat model on our website. Here's a recent presentation by my colleague Rasmus on the subject: https://www.youtube.com/watch?v=Mp23yQxYm2c https://www.youtube.com/watch?v=Mp23yQxYm2c Here's a recent presentation by me on the subject of system transparency / runtime transparency / the technology underlying Apple PCC: https://www.youtube.com/watch?v=Lo0gxBWwwQE https://www.youtube.com/watch?v=Lo0gxBWwwQE
- 1oooqooq 2y ago
  sadly linking to youtube this week is like linking to xitter earlier. i cannot see any of the content as google now requires me to create an account. ironically when talking about losing control of cloud compute.
  - quite 2y ago
    Mmm. These kind of project should really post videos on or even host a PeerTube instance
liuliu 2y ago
I think the only shaking part, is the Secure Enclave, which provides the root of the guarantees. From there, everything is attested so if one layer is adversarial, other layers can notice.

bitexploder 2y ago

The xz backdoor would have been a yawn instead the many hands fire drill it was at most big orgs. It was scary.