SYSTEMD-....SERVICE(8)

🎀 SYSTEMD-....SERVICE(8) 🎀

okay bestie, sit down, hydrate, because we're talking about systemd-report-sign-tpm2@.service, systemd-report-sign-tpm2.socket and systemd-report-sign-tpm2 — that's the manual page name up there in the corner, and yes it's a mouthful, but it's our mouthful 💅

---

✨ NAME ✨

systemd-report-sign-tpm2@.service, systemd-report-sign-tpm2.socket, systemd-report-sign-tpm2 — they sign system reports with a whole set of signed TPM2 attestations. that's the whole job. that's the assignment. 🫶

---

🌸 SYNOPSIS 🌸

systemd-report-sign-tpm2@.service

systemd-report-sign-tpm2.socket

/usr/lib/systemd/systemd-report-sign-tpm2

---

💖 DESCRIPTION 💖

so systemd-report-sign-tpm2@.service is a system service that signs the system reports made by systemd-report(1). it's literally the signing backend for that tool's --sign= logic — it implements the io.systemd.Report.Signer.Sign() Varlink method, and you reach it through a socket that's linked into the /run/systemd/report.sign/ directory, and that socket is named tpm2. iykyk 🔥

the service is socket-activated, so it's one instance per connection, and that's handled by systemd-report-sign-tpm2.socket. and here's the thing: it does not just hand back one single signature. nope. it uses a TPM2 device to generate a whole set of signed attestations that also bind the report digest you passed in, and together those give a verifier evidence about the state of the system that produced the report. it's giving forensic main character energy ✨

the returned report is made of several signed components, and each one carries a JSON encoded attestation structure plus its corresponding signature. the signature shows up as a JSON encoded TPMT_SIGNATURE structure and in PEM encoded form. the signed component types are:

• A PCR quote, generated with TPM2_Quote
• One attestation per NvPCR, generated with TPM2_NV_Certify. each component also includes the readable name of the NvPCR, the NV index public area (as a JSON encoded TPMS_NV_PUBLIC structure), and a JSON blob of authenticated data — the NvPCR name and priority — that gets digested and supplied as the qualifying data to the certify command.
• An audit session attestation, generated with TPM2_GetSessionAuditDigest. this one is always the last component, periodt. the report digest passed in via Varlink is supplied as its qualifying data.

the report additionally includes the measurement event log, and the public area of the signing key. that public area comes as a JSON encoded TPMT_PUBLIC structure, and also in PEM encoded form. two formats, because we contain multitudes 🦋

all the components above run under the audit session, and the report is only generated if that session stays exclusive the whole time. why does that matter? because the audit session attestation records whether the session was still exclusive when it was signed — so a verifier gets evidence that the report is a single, consistent snapshot of the system, with no other TPM commands interleaved while it was being generated. no sneaky little commands cutting the line. 🙈

the set of attested PCRs and NvPCRs is currently fixed. it covers all firmware PCRs except PCR 6, all other S-RTM PCRs except the IMA PCR (which is not useful without the IMA log), and all defined NvPCRs.

---

🔑 SIGNING KEY 🔑

the attestation signing key lives as a JSON file named default.key inside /var/lib/systemd/report.sign.tpm2/. three kinds of key are supported:

1. an ordinary object protected by an existing persistent object such as the SRK or EK
2. a persistent object
3. a primary object that is recreated from a template on each use

in all cases the key must be a restricted signing key, no exceptions bestie. and if no key exists at all? an ordinary key gets generated automatically on first use. cute of it 🎀

for ordinary and primary keys, the loaded object context is cached in the service's runtime directory as /run/systemd/report.sign.tpm2/default.context and reused on subsequent invocations — which avoids a repeated TPM2_Load (that one needs authorization with the parent key) or a primary key recreation. efficiency slay 💅

the key may optionally have an associated voucher, stored right alongside it as default.voucher. this is an opaque credential — like, for example, one issued by a CA during onboarding — that gets attached to the signed report and presented to a verifier as proof that the attestation key is authentic. and it is deliberately not required to be any particular format (such as an X.509 certificate). it's whatever it wants to be. we respect that. 🌈

---

👀 SEE ALSO 👀

• systemd(1)
• systemd-report(1)

---

and that's the whole vibe, bestie — this page ships with systemd 262.1, so go forth and sign those reports 💖✨🌸🦋