github.com/jlmucb/cloudproxy@v0.0.0-20170830161738-b5aa0b619bc4/Doc/Replay.txt

Replay Resistant State
----------------------

The current Tao interface does not offer support for protecting state against
replay attacks or building any storage facilities that do so. That is, Tao
itself doesn't have any storage API, and none of the other existing APIs would
be useful for building one.

Simple example:

Suppose we want to build an CA that hands out X509 certificates for https. The
CA needs to keep track of the serial numbers it has handed out so far. It can
store the next SN in a file, and it can sign or encrypt that file using
Tao-protected keys, but there is still no guarantee that the file is fresh.

Prior Work
----------

TPM offers monotonic counters that can posibly help with replay-resistance. But
these are limited: Only a few exist (four or so), and only one can be "active"
during any boot cycle. 

Some prior work looks at using merkle hash trees and the TPM counters to
bootstrap many more counters. This works without needing any trusted OS or
trusted software beyond the TPM itself---essentially, the TPM is used as a
trusted log, with the TPM counter providing replay resistance for the log.

Other related work? To do...

Replay resistance in Tao
------------------------

Option 0: Do nothing. Assume there is a trusted replay-resistant mechanism
elsewhere.

Option 1: Implement hash-tree work outside Tao. The TPM implements the counter
and small NV storage at the base. Some storage service on top of that,
independent of Tao, implements the hash-tree approach. Applications at layers of
Tao would talk to that same storage service. Tao API is left unchanged.

Option 2: Implement hash-tree work inside Tao at a single level. The TPM
implements the counter and small NV storage at the base. The first Tao host
above that implements the hash-tree approach and exposes that interface to each
hosted program. Subsequent stacked Tao hosts would either just re-expose the
same interface. It's not clear what each level would provide beyond the first
level, though. Perhaps each higher level would do authorization checks specific
to that level while just passing the operation down when the auth check
succeeds. Or perhaps it would just forward all calls downward and let
authorization happen at the first level above the TPM. The Tao API would include
interfaces for creating, managing, and manipulating counters.

Option 3: Provide support at every Tao level for hash-tree or other approaches.
Every Tao host, including the TPM, implements a set of counters and some NV
storage. Presumably, every hosted program would get one dedicated counter and a
small amount of NV storage. If a hosted program needs more than what the host
Tao provides, then the hosted program can use a hash-tree approach or any other
similar approach internally. In particular, a hosted Tao would presumably need
to use hash-trees or something similar to multiplex the the counter provided by
its own host Tao. The Tao API would include a few simple calls for hosted
programs to access the limited counters provided by the host Tao.

Option 4: Provide support for hash-trees at every level (except TPM). The TPM
provides one counter and some NV storage. Every other Tao level provides a
higher-level API for creating, managing, and manipulating counters and/or NV
storage. A hosted application might use these counters directly, or just use a
small number of them combined with something like the hash-tree approach.
Similarly, a hosted Tao could either pass calls from its own hosted programs
down to the underlying Tao (ala option 2), or the hosted Tao could locally
implement a hash-tree approach using just one or two counters from the
underlying Tao (ala option 3). 

Option 5: Implement replay-resistant storage without counters. Don't use
counters at all, rely instead on policies to control access to storage. Each Tao
provides:
  void Put(policy, name, data) // creates new slot containing data
  data = Get(policy, name) // get data from previously created slot
  void Set(policy, name, data) // overwrite slot with new data
  void Delete(policy, name) // delete slot
Note that policy is used in two ways: it defines a namespace to avoid
unintentional collisions for the name parameter; and it governs access to the
data. Each Tao level might have resources for storing only a few pieces of data,
or for storing only small data. Hosted programs can avoid large data by storing
the actual data elsewhere (e.g. in encrypted but replay-susceptible storage) and
storing only hashes in the Tao. Hosted programs can avoid using too many slots
by merging multiple data items into a single slot.

Comments: Counters vs Non-volatile storage
------------------------------------------

Monotonicic counters are a nice primitive, but
they are not necessary if replay-resistant non-volatile storage with
fine-grained authorization is available. Since Tao can authenticate and
authorize at the level of individual hosted programs (or smaller), a hosted
program can be sure that no other entity rolled back changes to its data, since
no other entity has access to the data. Or, at least, that such changes would be
detected.

Some levels of Tao could just pass all Put/Get/Set/Delete calls down to lower
layers. The TPM implements particularly restricted storage, so perhaps the first
Tao layer (i.e. LinuxTao) should implement a version with more available space.

Comments: Rate limiting and buffering
-------------------------------------

The TPM, at the lowest layer, simply can not perform efficient updates to
non-volatile storage (or counters). A TPM NV update might take a second or more,
and we may be rate-limited to around one update per five seconds. Simplistic
buffering and write-aggregation ruin replay resistance.

During write operations (Put, Set, and Delete), Tao should buffer the write and
pass back a token T. The hosted process can subsequently invoke Commit(T) which
will either force or wait for a buffer flush. When Commit(T) returns, the caller
knows that the corresponding write, and all previous writes, have been
committed. If the system crashes with dirty buffers, upon startup everything
rolls back to the state at the last successful commit. (Perhaps we could attempt
to roll forward some, e.g. if we have signed logs showing changes made since the
last commit.) The system will then have to make some conservative estimate of
how much the data may have changed since the last commit.

Consider, for example, an app that issues certificates each marked with a unique
serial number. The serial numbers need not be sequential, but they need to be
unique and never reused. The app can store the last-issued serial number in the
host Tao like, and limit bufferring to (say) N=5 writes like so:
  During installation:
    t = Put(self, "serialnum", 0)
	WriteFile("state.txt", "0")
	Commit(t)
  During each startup:
    x = Get(self, "serialnum")
	y = ReadFile("state.txt")
	if (x != y) {
      // y could be a little ahead or behind x due to buffering of file writes
      // and/or NV writes. Here, we can just take the NV value and ignore the
      // file value. Other apps might need to keep (or generate) multiple y
      // file values to find one that matches x.
      y = x
	}
    // x is reasonably fresh, and there have been no more than N writes
    // since then, so start issueing from x+N
    last_issued_serial = x+N
  During normal operation:
    last_commit = last_issued_serial
    loop {
	  ...
	  cert.serial = ++last_issued_serial;
	  WriteFile("state.txt", cert.serial)
	  t[i] = Put(self, "serialnum", cert.serial)
	  if (last_issued_serial >= last_commit + N) {
	    Commit(t[i-N])
	  }
	  ...
	}