anchor.diff:  single point of hardware failure that results in all data on the node being
   irretrievable. As a result, an additional step is added where as well as
   creating an encrypted DH box keyed to the hardware token for that CN, we create
  -a second box keyed to an offline "recovery key" for the datacenter. The public
  -half of the recovery key is distributed to all CNs for this purpose, but the
  -private half is kept in offline redundant secure storage to only be used in
  -emergencies. This is explored further in <<prov-backups>>.
  +a second box keyed to a set of offline "recovery keys" for the datacenter. The
  +public half of the recovery keys are distributed to all CNs for this purpose,
  +but the private half is kept in offline redundant secure storage to only be used
  +in emergencies. This is explored further in <<prov-backups>>.
   
   ### Overview: authentication
   
  
positive.code: cannot be flushed out (containing both the code and data used in the sensitive
  operation).
  
  This prevents most known mechanisms of memory timing side-channel leakage from
  the cryptographic algorithms run in the soft-token, including Flush+Reload and
  other related attacks. We are also aided here by the fact that KSM (kernel
  same-page merging) is not implemented or supported by illumos (and will not be),
  and the fact that the soft-token binary will not be in any of the filesystems
  accessible to non-global zones (so they cannot `mmap` it, or any of its
  cryptographic libraries, which are statically linked into the binary).
  
  As well as this direct mitigation, the algorithms chosen (see the
  <<crypto-algos>> section) for soft-token usage are chosen with side-channel
  leak prevention in mind.
  
  [[hardware]]
  ## Hardware implementation
  
negative.code: 
  Unfortunately, hardware tokens are generally only capable of storing a small
  number of asymmetric keys, and the number of zones on a CN or headnode may be
  quite large by comparison. The performance limitations of hardware tokens (given
  the "inexpensive" price constraint we've already accepted) also mean that
  scaling their usage up with the number of customer zones on a machine is likely
  to be infeasible. So the keys used for zone-to-zone authentication cannot reside
  directly on the hardware tokens.
  
  Instead, a "soft token" design will be used. A randomly generated symmetric key
  will be used to encrypt a keystore for that zone, and the key will be placed in
  