Transparent Logs and TUF: clarify compromise recovery

[trishankatdatadog]

From @FiloSottile:

"About compromise recovery, our story is very simple: there is always a client involved and that client has an update mechanism (Go releases, for us), so if there is a compromise we'd roll the tree key, and make a release."

"...I think most TL systems can build PEP 458-level compromise recovery over their existing software update channel."

[FiloSottile]

Oh and I should mention that sumdb signed tree heads can be signed by multiple keys, allowing such key rolls to happen without loss of availability.

See golang.org/x/mod/sumdb/note.

[JustinCappos]

If there is a stolen / accidentally disclosed key, how would a client know they are talking to you versus getting a malicious update from an attacker?

…

On Mon, Feb 3, 2020 at 9:43 PM Filippo Valsorda ***@***.***> wrote: Oh and I should mention that sumdb signed tree heads can be signed by multiple keys, allowing such key rolls to happen without loss of availability. See golang.org/x/mod/sumdb/note <https://pkg.go.dev/golang.org/x/mod/sumdb/note>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#95>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD6B6YOPU4PIBNMYCZTRBDI5HANCNFSM4KPO5OCQ> .

[FiloSottile]

If there is a stolen / accidentally disclosed key, how would a client know they are talking to you versus getting a malicious update from an attacker?

The client software update is out of band, the sumdb protects the Go module ecosystem, not the Go releases themselves. (The latter are currently just signed in a platform-specific way and distributed via HTTPS and package managers, we are working to make them easily reproducible.)

So in a sense, we do have two layers of keys, although exercising the releases key is a much more noisy action, as it involves making a new Go release.

With TUF, how does a client know to trust the offline key but not the compromised online one?

[JustinCappos]

The root metadata in TUF ( https://theupdateframework.io/metadata/#root-metadata-rootjson ) is signed with keys kept offline that are only needed when a top level role is compromised. A new root metadata file is pushed out which revokes the old key and adds a new one. In practice compromising a targets role (which you need to do to provide malicious software) usually also requires compromise of an offline key and is restricted to only the projects that party is trusted for. In practice these are each often thresholds of keys, so require multiple offline key compromises...

…

On Tue, Feb 4, 2020 at 2:42 AM Filippo Valsorda ***@***.***> wrote: If there is a stolen / accidentally disclosed key, how would a client know they are talking to you versus getting a malicious update from an attacker? The client software update is out of band, the sumdb protects the Go module ecosystem, not the Go releases themselves. (The latter are currently just signed in a platform-specific way and distributed via HTTPS and package managers, we are working to make them easily reproducible.) So in a sense, we do have two layers of keys, although exercising the releases key is a much more noisy action, as it involves making a new Go release. With TUF, how does a client know to trust the offline key but not the compromised online one? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#95>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRODYZOJGN3Z4N6KL2K5LRBEL5XANCNFSM4KPO5OCQ> .

[trishankatdatadog]

So, if I understand you both correctly:

• In Go sumdb, it is possible to use multiple signing keys to sign the MHT. You use one of them at any time, but keep the rest offline until you need to switch. When the current online key is compromised, you use the Go release key to build a new Go binary that will revoke trust in the current online key, and install trust in a new reserved one.
• In TUF, if an online signing key is compromised, you don't need to use a binary release key to issue a new software update. However, you will use an offline key to revoke and replace trust in the online signing key using purely signed metadata instead of a software update.

Does this capture everyone's thoughts accurately?

[FiloSottile]

• In Go sumdb, it is possible to use multiple signing keys to sign the MHT. You use one of them at any time, but keep the rest offline until you need to switch. When the current online key is compromised, you use the Go release key to build a new Go binary that will revoke trust in the current online key, and install trust in a new reserved one.

Almost, the future keys don't exist yet (so they are perfectly secure! 😉), and would be created when the new release is issued. The advantage of multiple keys signing the tree head is that old clients wouldn't break (unless we want them to).

Aside from that, yep, and AFAICT this is semantically equivalent to the TUF recovery mechanism at the PEP 458 level (although it can differ in key management, like whether the key is offline, depending on implementation decisions).

[trishankatdatadog]

Almost, the future keys don't exist yet (so they are perfectly secure! 😉), and would be created when the new release is issued. The advantage of multiple keys signing the tree head is that old clients wouldn't break (unless we want them to).

Sorry, I'm a bit confused. Let's say that before time N, online key 1 was used. At time N, online key is compromised. After time N, a new Go release is issued to trust online key 2 instead.

In order to preserve backwards-compatibility with older Go clients, is the expectation that both online keys 1 and 2 will be used going forward to sign the MHT? Or not, in this case, because online key 1 was compromised, and so Go will break signatures for older clients? In what conditions will multiple signing keys be used?

[FiloSottile]

Almost, the future keys don't exist yet (so they are perfectly secure! 😉), and would be created when the new release is issued. The advantage of multiple keys signing the tree head is that old clients wouldn't break (unless we want them to).

Sorry, I'm a bit confused. Let's say that before time N, online key 1 was used. At time N, online key is compromised. After time N, a new Go release is issued to trust online key 2 instead.

In order to preserve backwards-compatibility with older Go clients, is the expectation that both online keys 1 and 2 will be used going forward to sign the MHT?

Yes, that's the plan. Older clients would be vulnerable, but that's just akin to any other security vulnerability in the Go client, which users are expected to apply the patches for.

(FWIW, we don't expect key compromise to be likely at all, as we are relying on the most secure infrastructure that was available to us within Google. But I understand that only works for us, so is pretty irrelevant.)

[trishankatdatadog]

Yes, that's the plan. Older clients would be vulnerable, but that's just akin to any other security vulnerability in the Go client, which users are expected to apply the patches for.

Thanks for the clarification! TBF, that will also be the case for TUF if a threshold of the root keys themselves are compromised. (However, the bar is expected to be very high here, as the expectation is that you use multiple, offline root keys, possibly even using different signing algorithms.) The difference is that TUF will switch users from the old to the new root keys permanently (which can be done safely provided that attackers no longer control the repository, and the repository is also using TLS).

(FWIW, we don't expect key compromise to be likely at all, as we are relying on the most secure infrastructure that was available to us within Google. But I understand that only works for us, so is pretty irrelevant.)

Yes, I think that's probably one of the biggest differences in assumptions between both systems.

Let me try sending out a PR tomorrow that everyone here can vet...

[FiloSottile]

The difference is that TUF will switch users from the old to the new root keys permanently (which can be done safely provided that attackers no longer control the repository, and the repository is also using TLS).

I think I'm still missing the semantic difference (that is, beyond where and how the keys are stored). The online keys in TUF are the tree signing keys in the sumdb, the root keys in TUF are the release signing keys in Go, all keys rotate permanently upon update (the signatures by the old untrusted key would be just ignored by updated clients), and if you have a TLS connection to an entity you trust you can pull it off securely.

[trishankatdatadog]

I think I'm still missing the semantic difference (that is, beyond where and how the keys are stored). The online keys in TUF are the tree signing keys in the sumdb, the root keys in TUF are the release signing keys in Go, all keys rotate permanently upon update (the signatures by the old untrusted key would be just ignored by updated clients), and if you have a TLS connection to an entity you trust you can pull it off securely.

I think one difference is that in sumdb, you need to update the client to permanently switch root keys, whereas in TUF (PEP 458, for apples-to-apples comparison), you don't need to update the client at all. I'll have to think if other differences exist.

[JustinCappos]

The keys used to revoke trust in TUF are not the same ones used to sign a new release. They are only used when revoking trust. You don't need to update the TUF software to change the keys used to sign a new release.

…

On Wed, Feb 5, 2020 at 10:12 AM Trishank Karthik Kuppusamy < ***@***.***> wrote: I think I'm still missing the semantic difference (that is, beyond where and how the keys are stored). The online keys in TUF are the tree signing keys in the sumdb, the root keys in TUF are the release signing keys in Go, all keys rotate permanently upon update (the signatures by the old untrusted key would be just ignored by updated clients), and if you have a TLS connection to an entity you trust you can pull it off securely. I think one difference is that in sumdb, you need to update the client to permanently switch root keys, whereas in TUF (PEP 458, for apples-to-apples comparison), you don't need to update the client at all. I'll have to think if other differences exist. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#95>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRODYA76TYJJHB3OUPXD3RBLJODANCNFSM4KPO5OCQ> .