in-toto-sign
Sign software artifacts using in-toto attestations
TLDR
Sign 'unsigned.layout' with two keys and write it to 'root.layout'
Replace signature in link file and write to default filename
Verify a layout signed with 3 keys
Sign a layout with the default GPG key in default GPG keyring
Verify a layout with a GPG key identified by keyid '...439F3C2'
SYNOPSIS
in-toto-sign [OPTIONS] <METADATA_PATH>
Example: in-toto-sign --key my-private-key.pem unsigned-layout.json --output signed-layout.json
PARAMETERS
--key <KEY_PATH>
Specifies the path to the private key file used for signing the metadata. This key is typically generated beforehand using in-toto-keygen.
--output <OUTPUT_PATH>
Specifies the path where the signed metadata file will be saved. If omitted, the input metadata file is often modified in place or the signed content is printed to standard output.
<METADATA_PATH>
The path to the unsigned in-toto layout or link metadata file that needs to be signed. This is a mandatory positional argument.
--prompt
Prompts for the private key's passphrase if the key is encrypted. Useful for interactive signing.
--help
Displays a help message and exits.
--version
Shows the program's version number and exits.
DESCRIPTION
in-toto-sign is a crucial command within the
in-toto supply chain security framework. Its primary function is to cryptographically sign in-toto metadata files, ensuring their authenticity and integrity. These metadata files can be either "layout" metadata, which defines the entire supply chain workflow, or "link" metadata, which records a specific step performed by a functionary. By signing these files with a private key, in-toto-sign allows downstream consumers to verify that the metadata originated from a trusted source and has not been tampered with. This command is a fundamental building block for establishing verifiable and secure software supply chains, enabling the detection of unauthorized modifications or steps throughout the software development and deployment lifecycle. It is often used by human functionaries or automated systems to attest to their actions within the supply chain.
CAVEATS
The security of the signed metadata heavily relies on the security of the private key used for signing. Keep private keys secure and do not expose them. in-toto-sign only signs the provided metadata; it does not verify the contents or structure of the metadata against a layout during the signing process.
SIGNING PROCESS
in-toto-sign reads the specified in-toto metadata file (typically a JSON document), cryptographically signs its contents using the provided private key, and then embeds the resulting signature into the metadata structure. This process appends a "signatures" field to the JSON metadata, containing information about the key used (e.g., key ID) and the actual signature data, allowing for later verification.
KEY MANAGEMENT
Users are responsible for securely managing their private keys. If the private key is passphrase-protected, in-toto-sign will typically prompt for the passphrase unless specified otherwise. Best practices dictate keeping private keys encrypted and isolated.
HISTORY
The in-toto framework was initially developed at NYU Tandon School of Engineering with significant contributions from the Google Open Source Security Team (GOST). It was created to address vulnerabilities in software supply chains, such as those exposed by the Heartbleed bug. The project officially launched around 2017 and has since become a CNCF (Cloud Native Computing Foundation) sandbox project, gaining adoption in various security initiatives like SLSA. in-toto-sign is a core utility that has been part of the in-toto toolset since its early development, providing the fundamental capability to attest to the authenticity of supply chain steps.
SEE ALSO
in-toto-run(1), in-toto-gen-layout(1), in-toto-verify(1), in-toto-keygen(1)