Correction to Pseudo-Code in

1
Correction to Pseudo-CodeinVirtual Monotonic
Counters and Count-Limited ObjectsPaper

• Luis F. G. Sarmenta (lfgs_at_mit.edu)
• MIT Computer Science and A.I. Laboratory (CSAIL)
• June 26-27, 2007

2
Correction to Pseudo-code in ACM STC 06 paper

• Background
• Pseudo-code published in ACM STC 06 and MIT
  CSAIL TR-2006-64 papers has a bug in the code for
  the RESET operation
• This problem and its solution were known to us at
  the time of writing, but errors were somehow
  introduced (and left unnoticed) while we were
  preparing the figures for the paper
• These slides are excerpts from a presentation
  given last June 26-27, 2007

3
Bug in Pseudo-code for RESET operation

• Problem
• For the RESET operation, the code doesnt check
  the inputted hashes against the trusted internal
  roothash
• This allows owner to set the tree to whatever he
  wants to by resetting a subtree and setting
  everything else as he wants!
• Correction
• Remove the exception for the RESET operation
  (Step 6b)
• Note that input counter blob for RESET
  operation is actually a different data structure
  containing
• address of internal node corresponding to subtree
  to be reset
• hash value at that node
• How it works
• If you lose the data for a leaf or a subtree, you
  can reset the PARENT subtree, assuming you still
  have the internal hash value of the parent node
  stored on disk
• The catch you will also lose the sibling subtree
  of the lost subtree, but, at least other subtrees
  are recoverable

4
Published Pseudo-code
5
Correction to Pseudo code
Additionally,hts.curOrigHash hash value taken
from input counterBlob(which is in a special
format)
and the internal hash tree node value at that
node. TPM owner authorization is required for
RESET
6
How it works
Hash Tree State (volatile)

• Suppose you lost the counter blob for c1101 and
  its hash h1101
• Cant just replace c1101 with a blank blob
  because we need the original h1101 to recreate
  the original roothash, so that TPM can verify the
  rest of the hash tree nodes against its internal
  stored value
• If we have the original value of h110 stored on
  disk, then we can provide that for verification,
  and then the TPM can reset that node (h110) to
  the appropriate known null value at that level
• Given h110, we can recreate the original
  rootHash, and also a new rootHash, assuming that
  h110 is nulled
• If computed rootHash matches stored stored
  rootHash, then update the rootHash
• Note that we have to reset the whole subtree
  under h110, so we also lose c1100 even if we
  still have it on disk
• The reason we cant use the saved copy of c1100
  even if we have it is because there is no way to
  verify that it is valid/up-to-date without
  knowing h1101 (which we lost)

TPM chip
aikHandle
mode
(TRUSTED)
nonce
Is Computed orig rootsame as stored root?
newCounterBlob
NVRAM
curPosition
rootHash
curOrigHash
curNewHash
New rootHash
( aikHandle, RESET, nonce,
TPM_ExecHashTree
address110,hashh110, h1100, h111, h10
)
rootHash
h11
h10
h10
h10
h110
h111
h1100
h1101
h1100
h1100
c1101
c1100
c1011
c1010
c1001
c1000
c1110
c1111
7
Additional Notes on RESET

• Note that once a subtree is RESET, all counters
  created under the subtree are invalidated, not
  rewound
• Recall that virtual counter ID consists of
  address, and randomID
• address is re-usable, but randomID is created at
  random by CREATE operation
• If you reset an address, and then create a new
  counter at the same address, it will have a
  different counter ID from the previous counter at
  that address
• Thus, you cant rewind a counter using RESET
• Note that resetting the top-level rootHash itself
  to null is a special case of the RESET operation
• doesnt require old rootHash, but invalidates the
  entire tree