[Cryptech Tech] Question regarding Trusted Path Authentication

[Peter Gutmann]

Jakob Schlyter <jakob at kirei.se> writes:

>Peter; could you please elaborate on the challenges to get this right? I'm
>most likely missing something important.

>From the book:

  There are numerous security design situations in which, to quote the
  computer in the movie Wargames, “the only winning move is not to play”.
  Consider the use of threshold schemes for key safeguarding.  A threshold
  scheme allows a single key to be split into two or more shares, of which a
  certain number have to be recombined to recover the original key.  For
  example a key could be split into three shares, of which any two can be
  recombined to recover the original.  Anyone who gains possession of just a
  single share can’t recover the original key.  Conversely, if one of the
  shares is lost, the original key can be recovered from the other two.  The
  shares could be held by trustees or locked in a bank vault, or have any of a
  range of standard, established physical controls applied to them.

  Threshold schemes provide a high degree of flexibility and control since
  they can be made arbitrarily safe (many shares must be combined to recover
  the key) or arbitrarily fault-tolerant (many shares are distributed, only a
  few need to be recombined to recover the key).  In addition they can be
  extended in various fancy ways, for example to allow shareholders to vote
  out other shareholders who may no longer be trusted, or to recreate lost
  shares, or to allow arbitrary boolean expressions like ‘A and (B or C)’ for
  the combination of shares.

  Lets consider just the simplest case, a basic m-of-n threshold scheme where
  any m shares of a total of n will recover the key.  What sort of user
  interface would you create for this?

  There are actually two levels of interface involved here, the programming
  interface in which the application developer or user interface designer
  talks to the crypto layer that implements the threshold scheme, and the user
  interface layer in which the threshold scheme is presented to the user.  At
  the crypto API layer, a typical non-threshold-scheme crypto operation might
  be:

  encrypt message with key;

  or:

  sign message with key;

  Now compare this to what’s required for a threshold scheme:

  “add share 7 of a total of 12, of which at least 8 are needed, returning an
  error indicating that more shares are required”

  with a side order of:

  “using 3 existing valid shares, vote out a rogue share and regenerate a
  fresh share to replace it”

  if you want to take advantage of some of the more sophisticated features of
  threshold schemes.  If you sit down and think about this for a while, the
  operations are quite similar to what occurs in a relational database, or at
  least what a database API like ODBC provides.  Obviously full ODBC is
  overkill, but the data representation and access model used is a reasonably
  good fit, and it’s an established, well, defined standard.

  That immediately presents a problem: Who would want to implement and use an
  ODBC complexity-level API just to protect a key? And even if you can
  convince a programmer to work with an API at this level of complexity, how
  are you going to fit a user interface to it?

  The closest real-world approximation that we have to the process of applying
  threshold scheme-based shares to crypto keying is the launch process for a
  nuclear missile, which requires the same carefully choreographed sequence of
  operations all contributing to the desired (at least from the point of view
  of the launch officer [ ]) effect.  In order to ensure that the participants
  get this right, they’re pre-selected to fit the necessary psychological
  profile and go through extensive training and ongoing drills in mock launch
  centres, with evaluators scrutinising every move from behind one-way
  mirrors.  In addition to the normal, expected flow of operations, these
  training sessions expose the participants to a barrage of possible error and
  fault conditions to ensure that they can still operate the equipment when
  things don’t go quite as smoothly as expected.

  This intensive drilling produces a Pavlovian conditioning in which the
  participants mechanically iterate through pre-prepared checklists that cover
  each step of the process, including handling of error conditions.  Making a
  single critical error results in a lot of remedial training for the
  participant and possibly de-certification, which causes both loss of face
  and extra work for their colleagues who have to work extra shifts to cover
  for them, providing a strong incentive to users to get things right.

  Unfortunately for user interface designers, we can’t rely on being able to
  subject our users to this level of training and daily drilling.  In fact for
  the typical end user they’ll have no training at all, a technology usage
  mode sometimes termed “the accidental user” [ ], with the first time that
  they’re called on to use the threshold scheme for key recovery being when
  some catastrophic failure has destroyed the original key and it’s necessary
  to recover it from its shares.

  So we’re faced with the type of task that specially selected, highly
  trained, constantly drilled military personnel can have trouble with, but we
  need to somehow come up with an interface that makes the process usable by
  arbitrary untrained users.  Oh, and since this is a security procedure that
  fails closed, if they get it wrong by too much then they’ll be locked out,
  so it has to more or less work on the first try or two.

  This explains why no-one has ever seriously deployed threshold scheme-based
  key safeguarding outside of a few specialised crypto hardware modules where
  this may be mandated by FIPS requirements [ ] where they’re used to protect
  one-off, high-value keys like CA root keys in complex, carefully-
  choreographed ceremonies (this is the actual technical term for the
  procedure [ ][ ][ ]) and the odd designed-purely-for-geeks application.  The
  cognitive load imposed by this type of mechanism is so high that it’s
  virtually impossible to render it practical for users, with even the highly
  simplified “insert tab A in slot B” mechanisms employed by some crypto
  hardware vendors (which usually merely XOR two key parts together to recover
  the original rather than using a full threshold scheme) reportedly taxing
  users to their limits, to the extent that they’re little-used in practice.

  One example of what's in store for someone wanting to use a threshold scheme
  with an HSM presented itself during the key ceremony used to initialise the
  DNSSEC root key for a country.  After several full-day dress rehearals of
  setting up the key, the organisers had condensed things down to a 500-step
  checklist (that's not a misprint).  Even after all of the dress rehearsals,
  it still took a full day to run through, with the four-hour process of
  setting up the HSM being the single longest step.  Since no-one could enter
  or leave the secure area while they were waiting for the process to
  complete, the most important take-away from for next time was "bring
  boardgames".

Peter.