# TAKT Escrow Box Rider This rider forms part of every order with source escrow between ABX DEVELOPMENT LLP, registered in Scotland under number SO301872, trading as TAKT (the **Provider**), and its client (the **Client**) under the Provider's Terms of Service (the **Terms**). It prevails over any conflicting term of the order. Words defined in the Terms, clause 8, have the same meaning here. 1. **Schedule.** The order records, for the escrow: - the version of this rider; - the **platform**: the cloud provider and the virtual machine type, with a TPM 2.0, on which the Client runs the image; - the SHA-256 of the image, of the unencrypted source and of the delivered build; - the TPM measurements the order key is sealed to: PCRs 4, 9, 11, 12 and 13 of the SHA-256 bank; - the fingerprints of the Provider's heartbeat keys, main and backup; - the Client's SSH public key, and the fingerprint of the Provider's provisioning key. 2. **The platform.** The escrow runs only on the recorded platform: - in a virtual machine on that platform, booting the image directly, with no other boot program before it; - that is a genuine confidential or Shielded instance, so that the party operating it at a given time, and anyone acting for it, cannot read its memory or TPM state — the Provider while it provisions, the Client after handover — and so that no party excluded by the recorded trust model can read them. The account holding the virtual machine is the Provider's while it provisions and is transferred to the Client at handover, as clause 3 and the Schedule set out. For each provisioning and handover, the recorded virtual machine is used from its first boot through the Client's acceptance without substitution. This does not prevent replacement under clause 7; each replacement is provisioned and handed over under clauses 2 and 3 and recorded for the order. Neither party runs the image on hardware or a hypervisor it controls, attaches a debugger to it, alters it, or attempts to obtain the secret or the order key other than through the commands in clause 4. The Schedule identifies the platform's required protections and trust model, including whether the parties rely on the cloud operator for memory and TPM confidentiality. The recorded instance label alone is not evidence of those protections. Platform qualification must cover initial provisioning, every operation that unseals the key, and the permitted restart, recovery and migration paths. It must establish that usable TPM state cannot be transferred or retained in a configuration that permits the Client or another party excluded by that trust model to read protected memory or TPM secrets. A configuration change that cannot preserve these protections requires a new qualified provisioning; the Client must not continue operating the escrow in that configuration. 3. **Provisioning and handover.** The Provider provisions in an account it controls, with exclusive control of the deployment and receiving path, so that no other party can substitute the image or the endpoint during provisioning. It creates the recorded virtual machine — a genuine confidential or Shielded instance — deploys the image whose SHA-256 is recorded in the Schedule, and provisions it so the image seals the order key to that virtual machine's TPM and the recorded measurements. In each phase, the controlling party verifies the agreed UKI and the effective boot configuration through the trusted platform control plane, independently of the guest, and prevents changes between that verification and boot. Before any order key is transmitted, or any check, verify or pcrs response is relied upon, the receiving channel must be independently bound to the recorded virtual machine and the verified boot. A reported IP address, a guest-reported fingerprint or acceptance of an unverified SSH host key is insufficient. Only after this verification does the Provider transmit the key; the image checks that it opens the encrypted source and seals it. The result, the sealed key, is kept on the image's data disk, and the Client can obtain it with the command **sealed**. The provisioning key can do nothing but provision. The image refuses a second provisioning while a sealed key is on its data disk. At handover the Provider transfers the account to the Client and the Client takes exclusive control. The Client rotates every credential and access path and removes every Provider principal; handover includes replacement of server-authentication material that the Provider could retain, or establishment of a trusted resource-bound channel that does not rely on that material. The Client's acceptance boot must start the verified image from a fully stopped state without resuming saved guest memory. Before relying on the escrow, the Client independently verifies, through the trusted platform control plane and a channel bound to the recorded virtual machine and that boot, that the running instance is the agreed image on the recorded platform; reading the boot-image file and the image's pcrs output alone does not establish which image is currently executing, and expected measurements must be defined for the recorded platform and boot configuration. The Client then runs check and verify against the order's recorded checksums. The acceptance record identifies the account, the virtual machine, the verified image hash, the boot configuration, the control-transfer result, the channel-verification method and the check and verify results against the order's checksums; the Client signs the acceptance only after these succeed. This procedure concerns the escrow order key supplied and retained by the Provider under this rider. It does not establish that this key, or a wallet secret created under a different protocol, has never been known to the Provider; any claim of Provider-blind secret generation requires a separate generation, provenance and handover protocol. 4. **Commands.** Apart from provisioning, the image accepts only the Client's SSH key, and with it only these commands: - **check:** confirms that the sealed key opens here and that it opens the encrypted source; - **verify:** additionally rebuilds the delivered build from the source, without network access, as its instructions state, and compares the result with the delivered build byte for byte; - **status:** shows the release rule's current decision with its evidence; - **unlock:** gives the source to the Client if a release event under clause 5 has occurred, and otherwise refuses with the reason; - **sealed** and **pcrs:** show the sealed key and the TPM measurements of the current boot. The commands show checksums, results and evidence, never the source, before release. The build log stays inside the image. 5. **Release rule.** The image holds while Companies House shows a status of the Provider that is not terminal and a valid heartbeat is present. The image gives the source on **unlock** when any of these holds: - Companies House shows the Provider's status as dissolved, in liquidation, administration, receivership, insolvency proceedings or a voluntary arrangement, converted or closed, or removed; - no valid heartbeat issued within the last 90 days is present; - the heartbeat repository has been deleted or not public for 14 consecutive days. The image records the start of the absence on its data disk and clears it when the repository is public again. This rule relies on the observations retained by the image and is subject to the state-preservation and availability limits in clause 10; - a valid heartbeat dated more than one hour after the decision time is present. Any command that reads the rule records this as a release as soon as the image has fully validated it, and the hourly self-check records it even while no command is run; once it has been recorded, the release stays available even after that date has passed. A heartbeat is **valid** if it is a file `heartbeats//.txt` at the head of the default branch of https://github.com/abx-takt/takt-heartbeat, signed (namespace takt-heartbeat) with a heartbeat key in the Schedule, and its signed issue time equals its name. **Time** is taken only from the HTTPS answers of GitHub and Companies House. Their `Date` headers must agree within ten minutes, and the earliest of them is used. When those sources do not answer, do not answer consistently, or cannot be read, the image makes no decision, and nothing is released on that ground. 6. **Release outside the image.** The Provider gives the Client the order key, or the source, on request in either of these cases: - a release event under the Terms, clause 8, occurs and the image does not release, for example because the Provider has ceased to provide the service while heartbeats continue, or because the image can no longer read its sources; - the image is unusable after the Provider has ceased to provide the service. The Provider keeps the order key in confidence for as long as the escrow lasts, and uses it only for provisioning and under this clause. 7. **Replacements.** The sealed key opens only with the TPM in which it was provisioned and only under the measurements in the Schedule. While the Provider provides the service, it provisions a replacement for the same order, with the same source, at the Client's request: - after the virtual machine or its TPM is lost; - after a platform change alters the measurements; - after a change of the heartbeat keys or of the sources' formats; - after a defect is found in the image. A replacement for a defect in the image is at the Provider's cost. Other replacements cost what the order states, and nothing if it states nothing. After the Provider has ceased to provide the service, keeping the virtual machine and its TPM is the Client's responsibility. 8. **Costs.** The Client pays for the platform, including running and storing the virtual machine. 9. **Confidentiality and use.** After release, the Client may use the source only as the Terms, clause 8, allow: to maintain, correct and rebuild the delivered build for the licensed use. The NDA continues to apply. 10. **Limits.** The Provider does not control the platform, GitHub or Companies House and does not guarantee their availability. The image depends on them as clause 5 states. The image's release latch and its record of when an absence was first observed are held on its data disk. Their contents are authenticated, but their freshness is not protected by this mechanism. Restoring an earlier copy can remove a recorded release authorization, shorten the grace period by restoring an earlier start time, or restart it by restoring a state with no start time. Repeated restoration can postpone release indefinitely. The fourteen days in clause 5 describe the decision rule applied to the retained observations; they are neither an unconditional minimum nor a guaranteed maximum time to release. The rule operates while the image is running and can obtain the required consistent evidence. Any additional protection of state freshness must be specified and verified for the platform in the Schedule. 11. **Changes and term.** This rider and the Schedule of an order change only by a document signed by both parties. The escrow lasts for as long as the Client keeps the image of the order. 12. **Law.** This rider is governed by the law of Scotland, and the courts of Scotland have exclusive jurisdiction. This is without prejudice to either party's right to seek interim relief in any court.