[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, "dstack-kms-launch-ticket/v1:" for KMS. 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, but never returns it. vmm-cli launch-ticket new|hash, deploy --launch-ticket-file, update --launch-ticket-file|--no-launch-ticket, and a field in the web UI.

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.

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. Not exercised end to end on TDX hardware.