Literature Review on Image Signing

[shizhMSFT]

Introduction

Distributing software in modern computing is not only to operating systems [1-3] but also clouds [4-5]. As applications are installed in a wide range of devices and clouds, security of the software centers is important as they are easily targeted. Several security systems [6-9] attempted to defend various attacks against those software centers. In addition to the software, air gapped environment is more preferable in terms of the physical security. In this thread, container registries [10-11] are focused.

Related Work

Atomic [12] leverages GnuPG [6] to sign container images with metadata in the simple signing format [13]. It provides basic security and nothing else.

As inspired by [14], Samuel et al. [7] proposed The Update Framework (TUF) and prevents many security attacks, including freeze attack, under a formal threat model. The design principles of TUF are separating responsibilities to multiple roles, use of threshold signature to spitting trust, explicit and implicit revocation, and minimizing risk by reducing the attack surface of keys. Assuming PKI is vulnerable, TUF is designed without PKI. In the world of Docker Registry [11], Docker Notary [15] is implemented with a branding name of Docker Content Trust using TUF as a building block. However, the usability of Notary is not good as expected. Since a container registry has many repositories and each repository is a TUF collection, the registry owners have too many keys to maintain. It is easier for small organizations to have security issues with the keys [7]. There are other pitfalls in the Docker Notary implementation. The root trust of a TUF collection is based on Trust On the First Usage (TOFU). Due to lack of the PKI integration, a compromise of the trust collection storage will compromise all new clients except that the new clients has set up trusting pinning, which is uncommon. Although Docker Notary supports YubiKey [16], it does not support other Hardware Security Modules (HSM) or remote key management services [17-19], making key management harder with keys on the local devices. Docker Notary is often integrated with distributed systems and thus it requires scalability. The snapshot role (or the release role in TUF) maintains all hashes of all delegation roles in a single JSON file, and the snapshot role renders concurrent signing not practical. Therefore, Docker Notary is not scalable in practice. In addition, since the root trust of the signature is from the root role, it renders signature movement impossible between registries or other mediums, especially registries in air gapped environments.

In order to improve the security and usability of above systems, the Notary v2 project [8] was emerged. The alpha.1 version of notation can achieve the security equivalent to the Atomic tool but better usability and better integration with the registry. Additionally, it supports optional time stamping to prolong the signing certificate expiry. The Notary v2 project is under development and will have advanced security with trust control in future releases. Meanwhile, the Notary v2 project is also trying to adapt TUF to a notation-compatible implementation with usablity issues in Notary v1 resolved.

Sigstore [9] is another attempt to improve the security and usability. It consists of multiple components: Rekor for signature transparency log, Fulcio as a private root Certificate Authority (CA) to issue short-lived certificates, and Cosign as a tool for signing and storing signatures in the registry. Sigstore supports various signing and verification flows with local keys, hardware tokens, HSMs, and KMSs. It is also extensible to any PKIX-compatible signing tools such as OpenSSL. Optionally, Sigstore works with OIDC [20] based PKI, using ephemeral keys and short-lived certificates from the Fulcio CA. When TSA is utilized, Sigstore provides several TSA options, offering a transparency log to mitigate TSA compromise. Depending on the scenarios, Sigstore can be configured to work in air-gapped environments as well as hybrid environments where artifacts are signed in the outside of the air-gapped environment and verified inside.

References

[1] Debian apt-get. https://wiki.debian.org/apt-get.
[2] Python Package Index. https://pypi.org/.
[3] NuGet Gallery. https://www.nuget.org/.
[4] Helm. https://helm.sh/.
[5] Cloud Native Application Bundle. https://cnab.io/.
[6] The GNU Privacy Guard. https://gnupg.org/.
[7] Justin Samuel, Nick Mathewson, Justin Cappos, and Roger Dingledine. 2010. Survivable key compromise in software update systems. In Proceedings of the 17th ACM conference on Computer and communications security (CCS '10). Association for Computing Machinery, New York, NY, USA, 61–72. DOI:https://doi.org/10.1145/1866307.1866315
[8] Notary v2. https://github.com/notaryproject/notaryproject.
[9] sigstore. https://sigstore.dev/.
[10] Docker Registry. https://docs.docker.com/registry/.
[11] OCI Registry. https://github.com/opencontainers/distribution-spec.
[12] REHL Signing Container Images https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/managing_containers/signing_container_images.
[13] Container Image Signing. https://www.redhat.com/en/blog/container-image-signing.
[14] Justin Cappos, Justin Samuel, Scott Baker, and John H. Hartman. 2008. A look in the mirror: attacks on package managers. In Proceedings of the 15th ACM conference on Computer and communications security (CCS '08). Association for Computing Machinery, New York, NY, USA, 565–574. DOI:https://doi.org/10.1145/1455770.1455841
[15] Docker Notary. https://docs.docker.com/notary/.
[16] YubiKey. https://www.yubico.com/.
[17] Azure Key Vault. https://azure.microsoft.com/services/key-vault/.
[18] AWS Key Management Service. https://aws.amazon.com/kms/.
[19] Cloud Signature Consortium. https://cloudsignatureconsortium.org/.
[20] OpenID Connect. https://openid.net/connect/.

[dlorenc]

A couple of the sigstore details here are incorrect/out of date. Are you interested in corrections?

[dlorenc]

Here's how I would suggest rewording it:

Sigstore [9] is another attempt to improve the security and usability. It consists of multiple components: Rekor for signature transparency log, Fulcio as a private root Certificate Authority (CA) to issue short-lived certificates, and Cosign as a tool for signing and storing signatures in the registry. Sigstore supports many signing and verification flows, including fixed keys on disk, KMS integrations, hardware tokens and HSMs.

Sigstore can be used without PKI, with existing PKI, or with Sigstore's OIDC based PKI, which works using ephemeral keys from the Fulcio CA.

All of this can be run fully internally by enterprises, or in hybrid configurations that rely on the Sigstore trust root, which is backed by TUF.

Sigstore includes several different TSA options as well, including one backed by a transparency log to mitigate TSA compromise. Sigstore can be used in fully airgapped environments as well as hybrid environments, where artifacts are signed outside the airgapped environment and then verified inside.

In particular I'm confused by these claims:

sigstore is not enterprise friendly

Sigstore is in production use by many large enteprises in sensitive and regulated environments. This is just false.

and

making the system more complex and less secure.

I think this represents a misunderstanding of how the TSA works, and is also false.

[shizhMSFT]

Thanks for the correction. This LR was pretty old / outdated and I've updated it after reviewing the doc at https://docs.sigstore.dev/cosign/overview.

I noticed the KMS support is documented in cosign. However, I did not find any implementation in the github repo. Could you point me to the implementation so that I can revise the doc?

[dlorenc]

It's implemented in this library and imported into cosign: https://github.com/sigstore/sigstore/tree/main/pkg/signature/kms

[shizhMSFT]

Cool. I've updated the doc with KMS.

[mnm678]

Another thing I'd add here would be the tuf-notary part of the Notary v2 effort that is looking to address some of the usability concerns with the original Notary project (by placing the TUF root of trust above the repository level to allow for key management across repos and prevent TOFU). The goal of this effort is to design an implementation of TUF that can be used by the notation library or elsewhere in the Notary v2 effort.

[shizhMSFT]

Thanks for the reminder. I've added it in.

[sudo-bmitch]

I'm confused by the lumping of TUF together with Notary v1. It seems to imply that since v1 had issues that we shouldn't use TUF. That's a bit like saying Notary v1 implemented image signing and supported YubiKeys, but v1 failed so our project should avoid implementing image signing and shouldn't include YubiKey support. I hope I'm just misreading the intentions of the association, but we should probably be assessing components individually rather than judging them by association.

[shizhMSFT]

Thanks for noticing this. I've reworded so that TUF is a building block of Notary v1.