[kvinwang]

Problem

The LAUNCH_TOKEN pattern runs in the guest: the app-layer variant checks the token after the KMS has already released keys, and requirements.launch_token_hash relies on the guest OS enforcing it before key provisioning. Either way the guest OS must be bug-free, and rotating the token means changing the compose hash.

Fix

Gate key release on a launch ticket that the contract checks before the KMS hands out anything.

• Contracts. AuthorizationRequest gains launchTicketHash (breaking; 0.6.4 contracts are not deployed yet). DstackApp adds setRequireLaunchTicket, addLaunchTicket(hash, label), removeLaunchTicket and launchTickets(), checked first for app_get_key/app_get_cert at every app epoch; a missing or unknown ticket is rejected as "Invalid launch ticket". Labels are only logged in the added event. DstackKms adds the same for KMS instances, checked only for kms_import_keys, the one operation that hands a joining KMS the root keys. A required ticket refuses the legacy isAppAllowed/isKmsAllowed, so old KMS binaries and auth backends fail closed.
• Hash. sha256("dstack-launch-ticket/v1:" || ticket), for apps and KMS instances alike. Orthogonal to requirements.launch_token_hash. The KMS and VMM refuse tickets outside 32..1024 bytes or with surrounding whitespace.
• Auth backends. auth-eth and dstack-auth forward or check the hash, and GET / reports rootCaPubkey, the CA key of the current root epoch.
• Guest and KMS. The ticket is a new launch_ticket field of sys-config, not of vm_config, which attestations embed. The guest sends it in GetAppKey and SignCert; a joining KMS takes it in Onboard and sends it in GetKmsKey.
• Onboarding pin. RaClient runs its cert validator only on the response, so the ticket and source_token would reach any TEE answering at the source URL. ra-rpc can now pin issuer keys in the rustls verifier (non-CA leaf, given special usage, valid, signed by a pinned key; https only, no redirects), and onboarding pins a kms:rpc leaf of the current root CA from its own auth API: nothing is sent to a source without the registered roots.
• VMM and CLI. The VMM stores the ticket and writes it to sys-config at every boot, keeps VM work directories at 0700, and returns only the ticket's hash (VmInfo.launch_ticket_hash). vmm-cli launch-ticket new|hash, deploy --launch-ticket-file, update --launch-ticket-file|--no-launch-ticket, dstack-util get-keys --launch-ticket-file, and a field in the web UI.
• Errors. A denial for a missing ticket says none was presented, since an older VMM or guest drops it silently.

DstackKms is 24,113 bytes after this (EIP-170 limit 24,576).

A guest sends its ticket before it has authenticated the KMS, so the ticket's secrecy also rests on the CVM-to-KMS network path; a non-bearer scheme could close that in a follow-up.

Compatibility

Tickets need the VMM, the KMS and the auth backend at 0.6.4 or later, and a guest OS at 0.6.4 or later or a 0.5.x release with the launch ticket backport (#1579). Upgrade every KMS instance before setRequireKmsLaunchTicket(true): older ones authorize serving through isKmsAllowed, which then refuses. Onboarding needs the auth backend's GET / to report rootCaPubkey and an https:// source URL, so upgrade the auth backend before the KMS.

Testing

forge test --ffi (116), halmos on the four symbolic suites (39 checks), auth-eth bun run check, cargo test for dstack-kms, dstack-auth, ra-rpc (including a TLS test that a server failing the pin, by issuer, usage, CA flag or expiry, receives no request bytes), dstack-vmm, cert-client, dstack-types and dstack-util, vmm-cli unittest and the VMM UI tests.

End to end on TDX hardware, with a guest image, VMM, KMS and contracts built from this branch (KMS in CVMs, contracts on anvil behind auth-eth):

• App: no requirement boots; required with no ticket, an unlisted ticket, or a ticket removed on chain is denied as Invalid launch ticket; an allowed ticket boots and gets a KMS-signed certificate. The ticket appears in no VmInfo, guest-agent Info, vm_config or certificate DER.
• Onboarding: no ticket and an unlisted ticket are denied; an allowed ticket onboards with the source's roots. An http:// source is refused, and a KMS with unregistered roots fails the handshake and receives no request.
• Mixed versions (old = v0.6.4 before this PR, or 0.5.14), with the rest from this branch: old 0.6.4 and 0.5.14 guests, an old VMM, and an old KMS all boot when no ticket is required and are denied when one is; a 0.5.x guest with backport(v0.5.x): present the launch ticket to the KMS #1579 boots with a ticket. An old joining KMS onboards from a new source only when no KMS ticket is required, and so does a new joiner from an old source. An old auth-eth with the new contract, and a new auth-eth with the old contract, fail closed; an old auth-eth ignores launchTicketHash; onboarding against an old auth-eth fails for want of rootCaPubkey.