anchor.diff:     all CNs up and running
   
    . Before beginning to set up hardware, run tools (on laptop) to generate root
  -   key and program Yubikey for initial set of headnodes. Set up 3 DVD-Rs as
  -   backup media (as multi-track UDF), burn media key and initial metadata to
  -   first track, followed by backups of root key and disk encryption secrets for
  -   the headnodes.
  +   key and program Yubikey for initial set of Trusted CNs, including at least
  +   one headnode. Set up 3 DVD-Rs as backup media (as multi-track UDF), burn
  +   media key and initial metadata to first track, followed by backups of root
  +   key and disk encryption secrets for the initial nodes.
    . Run tool to update the USB flash drive image for booting headnodes. Copies
      the root public key into it, as well as the top-level certificates for the
      initial set of headnodes (edits the .img file in one step).
  
positive.code: service attacks on the admin VLAN, but these are out of scope for this design.
  
  Threat 2:: An intruder has escalated their network access into the admin VLAN, by
  compromise of a compute node (privilege escalation and zone escape).
  Goal 2:: The goal is to give this attacker only the minimum access required for
  the normal operation of the CN. They will be able to control other zones on that
  CN, as well as the information reported about them back to the rest of Triton.
  They will under no circumstances be able to gain control of a headnode from this
  position. Their access to the system can be terminated by revoking the
  credentials of the CN, they cannot extract any long-lived key material, and
  cannot take any actions that would escalate or allow sideways movement into
  other CNs.
  
  Threat 3:: An intruder has taken control of a public-facing headnode service (e.g.
  CloudAPI), by making use of a vulnerability in that service.
  Goal 3:: The goal is to give this attacker only the minimum access required by
  the normal operation of that service. This means, for example, that CloudAPI
  would not be able to run arbitrary commands on CNs or directly interface with
  
negative.code: will compute the HMAC of the challenge data with its secret key (without
  revealing that secret key to the host).
  
  Then, a secret key stored in a headnode service will be retrieved over a
  TLS-protected authenticated channel and used as the secret key for another HMAC
  operation on the output of the first one.
  
  The final output is the master key to unlock the ZFS crypto framework for the
  pool. A single master key will be used for the whole pool, rather than a key
  per zone or per customer: in the current Triton design, CNs are the source of
  truth about what zones run on them (and changing that here is out of scope), so
  there is no real benefit in using a finer-grained scheme.
  
  We incorporate the 3 pieces of data into the key so that the only sufficient
  condition to successfully decrypt the data on the disks is to have all 3 of:
  