[arch-dev-public] Signing enclave
Hi all The lack of package database signing was mentioned yet again and I think it is time to get the "Signing enclave" project rolling. A design was sketched two years ago[1], and based on that design I'm proposing a new design, without a HSM, which should be implementable today. The initial goal would be setting up the necessary infrastructure for us to be able to implement package database signing. Afterwards we can iterate and adapt the solution for more use-cases (ex: releng signing). Hosting: - Hosted on a Hetzner cloud VM as most of our infrastructure - Managed by the DevOps team Key management: - A master key is generated and stored encrypted in the infrastructure repository[2] - A subkey for signing is generated and stored encrypted in the infrastructure repository[2] and unencrypted on the signing server Signing: - SSHing to a restricted UNIX user with ForceCommand=signing-script - All signing operations are logged - Only signing requests from gemini's WireGuard IP address is allowed [1] https://gitlab.archlinux.org/archlinux/signstar [2] https://gitlab.archlinux.org/archlinux/infrastructure Best regards Kristian Klausen
On Sat, Jan 29, 2022 at 06:22:29PM +0100, Kristian Klausen via arch-dev-public wrote:
Signing: - SSHing to a restricted UNIX user with ForceCommand=signing-script - All signing operations are logged - Only signing requests from gemini's WireGuard IP address is allowed
Some general thoughts about how we suppose to log these options. We should preferably use a Transparency Log for these as it would give us tamper evidence if our signing enclave gets compromised. For people unfamiliar with Transparency Logs; https://transparency.dev/verifiable-data-structures/ It's the same technology as Certificate Transparency; https://datatracker.ietf.org/doc/html/rfc6962 We have few options here: * Implement our own Trillian Log * Use an existing implementation * Use sigstore[1]. I'm a bit biased towards just using sigstore as it's essentially a continuation of stuff i wrote about in my master thesis. It's also fairly trivial to integrate towards and we don't need to host anything ourself. It's also funded by our own Santiago :) We would be using `rekor-cli` which would give us a lot of this for free.[2] The other option is hosting our own log. This is not super trivial as we want monitors and people replicating the log outside of our own organization to ensure nobody can tamper with the log. The LVFS has opted for such an implementation. I personally think this is an important part of our signing infrastructure. In the future we could have pacman ensure database signatures are present on the Transparency Log which would prevent most of the trivial compromises of our signing enclave. Does anyone have any opinions around this or have any questions? [1]: https://www.sigstore.dev/ [2]: https://docs.sigstore.dev/rekor/CLI -- Morten Linderud PGP: 9C02FF419FECBE16
On 30/1/22 03:22, Kristian Klausen via arch-dev-public wrote:
Hi all
The lack of package database signing was mentioned yet again and I think it is time to get the "Signing enclave" project rolling.
A design was sketched two years ago[1], and based on that design I'm proposing a new design, without a HSM, which should be implementable today.
The initial goal would be setting up the necessary infrastructure for us to be able to implement package database signing. Afterwards we can iterate and adapt the solution for more use-cases (ex: releng signing).
Hosting: - Hosted on a Hetzner cloud VM as most of our infrastructure - Managed by the DevOps team
Key management: - A master key is generated and stored encrypted in the infrastructure repository[2] - A subkey for signing is generated and stored encrypted in the infrastructure repository[2] and unencrypted on the signing server
Signing: - SSHing to a restricted UNIX user with ForceCommand=signing-script - All signing operations are logged - Only signing requests from gemini's WireGuard IP address is allowed
[1] https://gitlab.archlinux.org/archlinux/signstar [2] https://gitlab.archlinux.org/archlinux/infrastructure
Do it! If you get this done soon, I will write the dbscripts changes to automatically build for secondary archtiecture(s) for any package that is uploaded in the primary architecture only. I can not guarantee I will have time in a month... Allan
participants (3)
-
Allan McRae
-
Kristian Klausen
-
Morten Linderud