Checking Data Structures

1
Checking Data Structures

• Greg Bronevetsky

2
The Problem

• So far covered ways to check results of
  algorithms
• Real computing systems have state
• Need ways to ensure this state not corrupted

3
The Problem

• Secure data structures allow checker flexibility
• Checkers frequently assumed to be reliable
• Thus must run on secure hardware
• If can validate data structures, can use
  unsecured memory for checker storage
• Oftentimes, just want to keep data safe
• Ex trustworthy databases

4
The Papers

• BEGKN Blum, Evans, Gemmell, Kannan and Naor,
  Checking the Correctness of Memories, 1991
• Online and offline checkers for Random Access
  Memories, Stacks and Queues
• Lower bounds on checking
• Polynomial-time and Infinite Power Adversaries
• DS Devanbu and Stubblebine, Stack and Queue
  Integrity on Hostile Platforms, 1998
• Offline checkers for Stacks and Queues
• Weaker adversary

5
Outline

• Definitions

• Offline Checkers
• RAMs
• Stacks
• Queues

• Online Checkers
• RAMs
• Stacks
• Queues

BEGKN

• Lower Bounds
• 3 Offline Checker Bounds

• Offline Checkers
• Stacks
• Queues

DS
6
Data Structure

• Defined by operations and their return values
• Ex for stack ltpush a, push b, pop, popgt must
  returnlt?, ?, b, agt
• Checker must detect any deviation from target
  behavior

7
Memory Checker

• Reliably implements target data structure
• May use original implementation or implement its
  own
• Invasive Checker checker stores own data in
  data structure
• Non-invasive Checker all checker data outside
  data structure
• If data corrupted by adversary, checker reports
  error

8
Memory Checker

• Checker has small amount of reliable memory,
  large amounts of unreliable memory
• Reliable unchangeable by adversary, in few
  cases invisible to adversary
• Small ? checker cant implement whole data
  structure in reliable memory
• Offline Checker at end of run reports if data
  corrupted mid-run
• Online Checker reports on errors during run
• Not necessarily promptly

9
Adversary

• Polynomial-time probabilistic algorithm
• Goal
• If original data structure works perfectly,
  checkers implementation works with probability gt
  ¾
• In checkers presented Prob1
• If data structure incorrect for some operation,
  checker reports error with probability gt ¾

10
Overall Picture
User
Checker
Reliable Memory
Unreliable Memory
Adversary
11
Outline

• Definitions

• Offline Checkers
• RAMs
• Stacks
• Queues

• Online Checkers
• RAMs
• Stacks
• Queues

BEGKN

• Lower Bounds
• 3 Offline Checker Bounds

• Offline Checkers
• Stacks
• Queues

DS
12
?-biased Hash Functions

• Presented in Naor and Naor, Small Bias
  Probability Spaces Efficient Constructions and
  Applications, 1990.
• Given n-bit x creates k-bit hash h(x)
• If x?y then h(x)h(y) with Prob ?1/2k
• Uses O(log n k) random bits
• kltn

x
h(x)
y
h(y) h(z)
Low Probability
z
13
?-biased Hash Functions

• Basic idea
• Given inputs x and y of length n
• Pick lO(k) random distinguisher vectors r1,
  rl, of length n
• Special choices, not just uniform
• Compute inner products x?ri and y?ri, ?i
• h(x) ltx?r1, x?rlgt
• If x?y then Probx?ri y?ri for all i ?1/2k
• Better than comparing (x mod pi) and (y mod pi)
  for random prime pis

14
Updating a Hash

• Given x and h(x)
• Wrote 1 to xj
• Need to change h(x) to reflect change in x
• For all O(k) distinguishers r1, rl see if
  rij1
• If rij1 then x?rj1
• Thus, set i-th bit of h(x)1
• Total work required O(k)

15
Offline Checkers

• Maintain record of reads and writes R and W
• R and W encoded s.t. when finished, RW
• Want to keep R and W in checkers private memory
• Too large, so keep h(R) and h(W)
• When finished if R?W then h(R)?h(W) with high
  probability

16
Checking RAMs

• Assume memory of size n
• Contains log(n)-bit words
• R and W will maintain entire history of changes
  to RAM
• Contain records ltv, a, tgt
• v value written/read
• a address
• t unique timestamp
• v, a, t all log(n)-bit words
• R and W vat 1 ? ltv, a, tgt written to R or
  W
• RWO(n3)
• h(R) h(W) log(n)

17
Checking RAMs

• Data locations keep last-access timestamp
• ltvi, tigt
• Checker maintains global timestamp
• Unique
• Greater than any timestamp used so far

18
Write to RAM

• Wish to write value v to address a
• Read from address value v?, timestamp t?
• t global timestamp
• Check that t?ltt
• Increment global timestamp
• Update h(R) with ltv?, a, t?gt
• Makes sure value not corrupted since last touch
• Write ltv,tgt to address a
• Update h(W) with ltv, a, tgt
• Records new value/timestamp for future operations

19
Read from RAM

• Wish to read value from address a
• Read value v?, timestamp t?
• t global timestamp
• Check that t?ltt
• Increment global timestamp
• Update h(R) with ltv?, a, t?gt
• Makes sure value not corrupted since last touch
• Write ltv?, tgt to address a
• Update h(W) with ltv?, a, tgt
• Records new timestamp for future operations

20
Basic Picture
Read After Write
Read After Read
write(v2)
read()

• read ltv1, t1gt
• ltv1, a, t1gt ? h(R)
• ltv2, a, t2gt ? h(W)

• read ltv1, t1gt
• ltv1, a, t1gt ? h(R)
• ltv1, a, t2gt ? h(W)

read()
read()

• read ltv2, t2gt
• ltv2, a, t2gt ? h(R)
• ltv2, a, t3gt ? h(W)

• read ltv1, t2gt
• ltv1, a, t2gt ? h(R)
• ltv1, a, t3gt ? h(W)

• Two adjacent accesses to same locations
• Leave identical records in h(R) and h(W)

21
Basic Picture
Write After Write
Write After Read
read()
write(v2)

• read ltv1, t1gt
• ltv1, a, t1gt ? h(R)
• ltv2, a, t2gt ? h(W)

• read ltv1, t1gt
• ltv1, a, t1gt ? h(R)
• ltv1, a, t2gt ? h(W)

write(v3)
write(v2)

• read ltv2, t2gt
• ltv2, a, t2gt ? h(R)
• ltv3, a, t3gt ? h(W)

• read ltv1, t2gt
• ltv1, a, t2gt ? h(R)
• ltv2, a, t3gt ? h(W)

• Two adjacent accesses to same locations
• Leave identical records in h(R) and h(W)

22
Final Reads

• When finished with RAM,
• Perform reads on all memory locations
• Update h(R) with most recent vs ts
• Reflects change made by last write to location
• Just like regular read without final update to
  h(W)
• No operation follows it
• Thus, no h(R) entry would match it

23
Checking for Errors

• Confirm that h(R)h(W)
• Claim If data got changed by attacker, R?W
• Thus, with high Prob, h(R)?h(W)

24
Proof of Correctness

• In order to fool checker into accepting erroneous
  RAM, adversary must change data between
  operations
• For example, Read-After-Write
• (Same argument for all combinations)

write(v2)

• read ltv1, t1gt
• ltv1, a, t1gt ? h(R)
• ltv2, a, t2gt ? h(W)

read()

• read ltv2, t2gt
• ltv2, a, t2gt ? h(R)
• ltv2, a, t3gt ? h(W)

25
Proof of Correctness

• Take last such occurrence
• Now read performs ltv78, a, t2gt ? h(R)
• To make h(R)h(W) adversary must force checker to
  do ltv2, a, t2gt ? h(R)

write(v2)

• read ltv1, t1gt
• ltv1, a, t1gt ? h(R)
• ltv2, a, t2gt ? h(W)

Adversary changes v2 to v78
read()

• read ltv78, t2gt
• ltv78, a, t2gt ? h(R)
• ltv78, a, t3gt ? h(W)

26
Proof of Correctness

• To force checker to ltv2, a, t2gt?h(R) must change
  data at address a
• Since a is in desired tuple
• v2 ?v78 was last change
• Adversary must make another change before that
• To force ltv2, a, t2gt?h(R) must modify a to ltv2,
  t2gt

write(v-9)

• read ltv-10, t1-10gt
• ltv-10, a, t1-10gt ? h(R)
• ltv-9, a, t-9gt ? h(W)

ltv2, t2gt
read()

• read ltv-9, t-9gt
• ltv-9, a, t-9gt ? h(R)
• ltv-9, a, t-8gt ? h(W)

write(v2)

• read ltv1, t1gt
• ltv1, a, t1gt ? h(R)
• ltv2, a, t2gt ? h(W)

read()

• read ltv78, t2gt
• ltv78, a, t2gt ? h(R)
• ltv78, a, t3gt ? h(W)

27
Proof of Correctness

• But recall, in every operation checker reads
  recorded timestamp
• Checks if recorded timestamp lt global timestamp
• Global timestamp always increases
• During prior adversary change global timestamp lt
  t2
• Thus, when next operation read t2, would declare
  error

write(v-9)

• read ltv-10, t1-10gt
• ltv-10, a, t1-10gt ? h(R)
• ltv-9, a, t-9gt ? h(W)

ltv2, t2gt
read()

• read ltv2, t2gt
• ltv2, a, t2gt ? h(R)
• ltv2, a, t-8gt ? h(W)

write(v2)

• read ltv1, t1gt
• ltv1, a, t1gt ? h(R)
• ltv2, a, t2gt ? h(W)

read()

• read ltv78, t2gt
• ltv78, a, t2gt ? h(R)
• ltv78, a, t3gt ? h(W)

28
Summary

• Similar argument for changes to timestamps
• Probability of poly-time probabilistic adversary
  of making unnoticed change ?
• Since only possible attack is breaking h(R), h(W)
  hashing property
• Reliable storage requirements
• O(log n k) bits to store ?-biased hash function
• h(W) and h(R) each klog n bits long
• (n words in memory)

29
Outline

• Definitions

• Offline Checkers
• RAMs
• Stacks
• Queues

• Online Checkers
• RAMs
• Stacks
• Queues

BEGKN

• Lower Bounds
• 3 Offline Checker Bounds

• Offline Checkers
• Stacks
• Queues

DS
30
Checking Stacks

• Stack checker follows same idea
• Key difference
• On push() new location is empty
• Thus, no need to update h(R)
• On pop() popped location becomes empty
• Thus, no need to update h(W)
• Must ensure that on pop(), stack returns value
  last pushed at that level

31
Basic Picture

• For any given sequence of pushes and pops
• Corresponding pushes and pops must have same value

32
Basic Picture
Must Match
push(v5)
push(v4)
push(v3)
push(v2)
push(v1)

• For any given sequence of pushes and pops
• Corresponding pushes and pops must have same value

33
Protocol

• Keep around global timestamp t
• On Push(vi)
• Write to next location ltvi, tgt
• Update h(W) with ltvi, a, tgt
• Increment t
• On Pop()
• Read ltvi, tigt from current location
• Ensure tiltt
• Update h(R) with ltvi, a, tigt
• At end do Pop() on rest of stack
• No errors ? RW
• So small probability of error if h(R)h(W)

34
Outline

• Definitions

• Offline Checkers
• RAMs
• Stacks
• Queues

• Online Checkers
• RAMs
• Stacks
• Queues

BEGKN

• Lower Bounds
• 3 Offline Checker Bounds

• Offline Checkers
• Stacks
• Queues

DS
35
Checking Queues

• Address means
• For enqueues number of prior enqueues
• For dequeues number of prior dequeues
• Enqueue and dequeue have same address ? refer to
  same queue location
• Since addresses unique, no need for timestamps
• Otherwise same as for stacks

36
Checking Queues

• On Enqueue(vi)
• Write to next location ltvigt
• Update h(W) with ltvi, agt
• a number of prior enqueues (address)
• Dequeue()
• Read ltvigt from front location (address a)
• Update h(R) with ltvi, agt
• At end do empty queue via Dequeue()s
• No errors ? RW
• Small probability of error if h(R)h(W)
• Note queue protocol non-invasive

37
Checking Graphs

• Two representations for graphs
• Adjacency matrix
• Adjacency list
• Adjacency matrix checker
• Use RAM checker
• Adjacency list checker
• Variant of queue checker checks multiple lists
• List IDs and headers kept in array
• Array checked via RAM checker
• Adds list ID to each h(R) and h(W) record

38
Outline

• Definitions

• Offline Checkers
• RAMs
• Stacks
• Queues

• Online Checkers
• RAMs
• Stacks
• Queues

BEGKN

• Lower Bounds
• 3 Offline Checker Bounds

• Offline Checkers
• Stacks
• Queues

DS
39
Online Checkers

• If adversary changes data want to know before
  program end
• Dont want to use erroneous data
• Solutions more expensive and restrictive
• Restrictions on word sizes
• Less memory available to application
• Sometimes private memory must be secret

40
Basic Online RAM Checker

• Build binary tree
• Leaves are actual data locations
• Internal nodes contain sum of children

wxyz
Internal NodesHash of children
wx
yz
Leaves UserMemory Cells
w
x
y
z
41
Basic Online RAM Checker

• On every read or write, verify sums
• Since cant verify root, must keep it in private
  memory

Root kept in private memory
wxyz
Internal NodesHash of children
wx
yz
Leaves UserMemory Cells
w
x
y
z
42
Tolerating Changes

• If adversary modifies some node x?x?
• Sum in parent changed
• Will notice if compare child values to parent sum

Root kept in private memory
wxyz
Internal NodesHash of children
wx
yz
Leaves UserMemory Cells
w
x
y
z
43
Limits of Encoding

• However, if w?wq and x?x-q then sum in parent
  doesnt change
• Will not notice change

Root kept in private memory
wxyz
Internal NodesHash of children
wx
yz
Leaves UserMemory Cells
w
x
y
z
44
Alternate Encoding

• Sums are poor encoding
• Need something better
• Use two encoding techniques
• Universal one-way hash functions (UOWHF)
• Pseudorandom functions

45
Adversary

• Chooses read/write operations
• Returns any value to non-private memory reads
• Probabilistic algorithm
• Runs in time polynomial in memory size

46
Universal One-Way Hash Functions

• Hash function good if few inputs map to same
  outputs (collide)
• UOWHFs good against poly-time probabilistic
  adversary looking for collisions
• Presented in
• M. Naor and M. Yung, Universal One-Way Functions
  and Their Cryptographic Applications, 1989
• J. Rompel, One Way Functions are Necessary and
  Sufficient for Secure Signatures, 1990

47
Universal One-Way Hash Functions

• Definition
• Given hash function h 0,1k?0,1m
• m polynomially smaller than k
• A probabilistic polynomial time adversary
• Chooses input x
• Hash function h picked randomly
• Tries to find y?x s.t. h(x)h(y)
• ProbA(x,h)y, y?x, h(x)h(y) lt 1/poly(k)
• ? polynomials worse than poly-small prob of
  success
• Need hash functions describable in poly bits,
  computable in poly time
• Need to pick hash functions uniformly at random

48
Checking RAMs Encoding Tree
Internal NodesHash of children
Leaves UserMemory Cells
Hash of children
ID ofhash function (different nodes have their
own)
h(leftright)
Each Internal Node
h
49
Checking RAMs Encoding Tree
Hash of children ( is concatenation)
ID ofhash function
Internal NodesHash of children
h(uv)
h


u
v
Leaves UserMemory Cells
50
Checking RAMs Encoding Tree
General hash application
h(xuhuxvhv)
h
Node u
Node v
xu
xv
Hash Nodes
hu
hv
Memory
51
Checking RAMs Encoding Tree
Root kept in private memory (keeps identities of
2nd level hash functions safe)
Internal Hash Nodes
Memory
52
RAM Operations

• Read
• Look at target memory node xu
• Walk up tree, check encodings
• Write
• Modify xu
• Walk up tree, changing encodings accordingly
• Pick new hash function for all nodes

53
On Adversary Change

• Adversary changes some node u?u?
• Cant find another value that results in same
  hashcode in parent node
• Low probability
• Thus, parents encoding wont match childs
• Will detect error before erroneous value used

h(xuhuxvhv)
h
Node u
Node v
xu
xv
hu
hv
54
Checking RAMs Details

• Memory of k-bit words, n words total
• Our adversary runs in time poly(n)
• UOWHF adversary runs in time poly(k)
• Thus, need k n? for ?gt0
• If kltO(poly(n)) then poly(n) adversary could
  enumerate all possibilities
• Set k n? to make two adversaries same

55
Alternative Tradeoffs

• Using UOWHFs places poly-size minimum on word
  size
• Can we do better?
• Another possibility trade small words for secret
  private memory
• Use pseudo-random functions

56
Pseudorandom Functions

• So close to random that poly-time algorithm cant
  differentiate
• Given random seed S, get pseudorandom fS
• fS 0,1k? 0,1m
• S?poly(k)
• Poly-time adversary given either random function
  or fS(x)
• Probability of telling apart lt 1/poly(k)
• ? polynomials worse than poly-small prob of
  success

57
Pseudorandom Functions

• Reported in O. Goldreich, S. Goldwasser and S.
  Micali, How to Construct Random Functions,
  1986.
• Construction requires private memory to be secret
  from adversary
• Keep pseudorandom function there so adversary
  doesnt know what it is
• No minimum on word size

58
Checking RAMs with Pseudorandom functions

• Memory location i, value vi
• Augment with signature
• Signature fS(vi)
• Each node contains ltvi, fS(vi)gt
• Since adversary doesnt know fS, cant just
  change vi?vi? and regenerate signature
• Must figure out fS(vi?)fS(vi) on its own

59
Secure Against Tampering

• If adversary can find vj s.t. fS(vi) fS(vj)
  then can tell pseudorandom from random
• Let Q be algorithm for finding vj with prob ?
  1/poly
• On any input vi, use Q to generate partner tuple
  vj
• If fS(vi) fS(vj) then return Pseudorandom
• Else, return Truly Random
• Algorithm differentiates with prob ? 1/poly
• Contradiction!

60
Limitation of Encoding

• Not secure against replay
• Adversary can repeat earlier valid encodings
  later on
• Must keep timestamp generation secure

61
Tree Encoding

• Construct complete binary tree
• Leaves user memory locations
• Every node has timestamp
• Time stamp of parent iti tj tk

Node i
vi, ti, i
Node j
Node k
vj, tj, j
vk, tk, k
62
Tree Nodes

• Node signatures include node ID, timestamp
• Leaf Node
• Internal Node i
• Root node in private, secret memory

ltvi, fS(vi, ti, i)gt
lttjtk, fS(0, tjtk, i)gt
63
Reading

• Read contents of target node
• Walk up tree, verify
• Encoding
• Child-parent timestamp relationships

Private, secret memory
v0, fS(0, t0, 0)
t7t8t4, fS(0, t7t8t4, 1)
v2, fS(0, t2, 2)
t7t8, fS(0, t7t8,3)
v4, fS(0, t4, 4)
v8, fS(v8, t8, 8)
v7, fS(v7, t7, 7)
Read node 8, check path to root
64
Writing

• Walk down tree, verify
• Encoding
• Child-parent timestamp relationships
• Write new value into target node
• Increment its timestamp
• Walk up tree, incrementing node timestamps
• (ti1) tj (titj) 1

65
Proof of Correctness

• Node contents secure against tampering
• Shown above
• Poly-time adversary has lt 1/poly Prob of success
• Replay attacks
• Can adversary overwrite nodes with valid old
  ltvalue, signaturegt?
• Node address part of signature fS(vi, ti, i)
• Thus, can only place old ltvalues, signaturegt at
  original address

66
Proof of Correctness

• Adversary changed some node
• Pick highest change in tree
• Old ltv?i, fS(v?i, t?i, i)gt ? New ltvi, fS(vi, ti,
  i)gt
• Must pick pair from same address since node ID is
  in signature
• Node timestamps always increase t?iltti
• Node i has parent p, sibling s
• Node s may be changed
• Node p not changed (since this highest change)
• Root in private memory, so always safe

67
Proof of Correctness

• Old ltv?i, fS(v?i, t?i, i)gt ? New ltvi, fS(vi, ti,
  i)gt
• Node timestamps always increase t?iltti
• Node i has parent p, sibling s
• Node s may be changed
• Node p not changed (since this highest change)
• Root in private memory, so always safe
• On next read or write will check that tp t?i
  t?s
• t?i lt ti (since i definitely changed)
• t?s ? ts (since s possibly changed)
• Thus, t?i t?s lt tp
• Error detected on next read or write

68
Checking RAMs Summary

• Two online techniques for checking RAMs
• Use different cryptographic encodings
• Universal One-Way Hash Functions
• Require minimum word size
• Pseudorandom functions
• Requires small secret private memory
• Both build trees on top of RAM
• Detect error on next operation
• Protect RAM against polynomial-time randomized
  adversary

69
Outline

• Definitions

• Offline Checkers
• RAMs
• Stacks
• Queues

• Online Checkers
• RAMs
• Stacks
• Queues

BEGKN

• Lower Bounds
• 3 Offline Checker Bounds

• Offline Checkers
• Stacks
• Queues

DS
70
Review of Stack Offline Algorithm

• t global timestamp
• On Push(vi) (to stack height a)
• Write to next location ltvi, tgt
• Update h(W) with ltvi, a, tgt
• Increment t
• On Pop() (from stack height a)
• Read ltvi, tgt from current location
• Update h(R) with ltvi, a, tgt
• At program end do Pop() on rest of stack
• No errors ? RW
• So small probability of error if h(R)h(W)

Matching pushes and pops change R and W in
same ways
71
Checking Stacks Online

• Trivial solution
• h(R) and h(W) keep track of pushes and pops
• After every operation empty stack
• Check that h(R) h(W)
• Very expensive
• Quadratically more operations
• Real solution follows similar idea
• Uses multiple sub-stacks
• Spillschecks at sub-stack boundaries
• Auxiliary stack needed to perform stack spills
• Two real stacks can be each others auxiliary

72
Stack Organization
Stack of height H turned into log(H)
stacks Stack i contains 2 blocks of items, each
2i words long Stacks filled from highest to
lowest
2 words
Stack 0
2 blocks of 21 words
Stack 1

Stack i
2 blocks of 2i words
73
Stack Organization

• All operations first done with Stack 0
• Push and pop normally

Stack 0
Stack 1

Stack i
74
Stack Organization

• All operations first done with Stack 0
• When pushing onto full Stack 0

Stack 0
Stack 1

Stack i
75
Stack Organization

• All operations first done with Stack 0
• When pushing onto full Stack 0
• Move Stack 0 contents onto Stack 1
• Pop off onto auxiliary stack
• Push onto Stack 1
• Called a block operation

Stack 0
Stack 1

Stack i
76
Stack Organization

• All operations first done with Stack 0
• When pushing onto full Stack 0
• Move Stack 0 contents onto Stack 1
• Pop off onto auxiliary stack
• Push onto Stack 1
• Called a block operation
• Push new element into Stack 0

Stack 0
Stack 1

Stack i
77
Stack Organization

• All operations first done with Stack 0
• When pushing onto full Stack 0 again

Stack 0
Stack 1

Stack i
78
Stack Organization

• All operations first done with Stack 0
• When pushing onto full Stack 0 again
• Move Stack 0 contents onto Stack 1
• Push new element into Stack 0
• Next time Stack 1 overflows
• Push onto Stack 2

Stack 0
Stack 1

Stack i
79
Stack Organization
Pop

• When popping off empty Stack 0

Stack 0
Stack 1

Stack i
80
Stack Organization
Pop

• When popping off empty Stack 0
• Move top block of Stack 1 onto Stack 0
• Via auxiliary stack

Stack 0
Stack 1

Stack i
81
Stack Organization
Pop

• When popping off empty Stack 0
• Move top block of Stack 1 onto Stack 0
• Via auxiliary stack
• Pop off Stack 0
• If Stack 1 is emptied, refilled from Stack 2, etc.

Stack 0
Stack 1

Stack i
82
Stack Organization
Pop
Stack 0
Stack 1
Note These stacks can be implemented as a single
stack

Stack i
83
Checking Stack Operations Push

• Check every stack operation
• On block push to Stack i
• Add all sub-pushes to h(W)
• Then pop off entire stack (pops added to h(R))
• Onto auxiliary stack
• Verify that h(W) h(R)
• Push stack back in place
• Time cost
• O(2i) operations per block operation
• O(2i) operations to check each block operation
• Total time O(2i)

84
Checking Stack Operations Pop

• Check every stack operation
• On block pop from Stack i
• Add all sub-pops to h(R)
• Then pop off entire stack (pops added to h(R))
• Onto auxiliary stack
• Verify that h(W) h(R)
• Push stack back in place
• Time cost
• O(2i) operations per block operation
• O(2i) operations to check each block operation
• Total time O(2i)

85
Amortized Overhead

• Theorem to service n user operations reliable
  stack performs O(nlog H) operations
• (H maximum height of stack)
• Proof
• Lemma 1 at most 1 in 2i user operations cause a
  block operation in Stack i
• Base Case
• Every user operation causes operation in Stack 0
• Inductive Case
• ? every other push to Stack i-1 causes Stack i
  push
• ? every other pop from Stack i-1 causes Stack i
  pop
• Thus, takes ? Stack i-1 ops to cause Stack i op

86
Amortized Overhead

• Theorem to service n user operations reliable
  stack performs O(nlog H) operations
• (H maximum height of stack)
• Proof
• At most 1 in 2i user operations cause a block
  operation in Stack i
• Each Stack i block operation costs O(2i) time
• Total cost per user operation

87
Outline

• Definitions

• Offline Checkers
• RAMs
• Stacks
• Queues

• Online Checkers
• RAMs
• Stacks
• Queues

BEGKN

• Lower Bounds
• 3 Offline Checker Bounds

• Offline Checkers
• Stacks
• Queues

DS
88
Checking Queues

• Can check queues like stacks
• Create multiple queues
• Spill from smaller to larger queues
• Empty and check queues on every operation
• Not known how to merge sub-queues into single
  queue

89
Outline

• Definitions

• Offline Checkers
• RAMs
• Stacks
• Queues

• Online Checkers
• RAMs
• Stacks
• Queues

BEGKN

• Lower Bounds
• 3 Offline Checker Bounds

• Offline Checkers
• Stacks
• Queues

DS
90
Checker/Adversary Properties

• Checker
• Works offline
• Private memory is secret
• Deterministic
• Adversary
• Arbitrary power to change memory
• Does not know
• Users operations
• Checkers memory state (its secret afterall)

91
Checking Scenario

• Memory size n
• Assume that user issues
• n writes to distinct locations
• Followed by n reads to those locations
• Possible usage pattern can use to establish
  lower bound
• x tuple of memory locations/values written by
  user (unknown to adversary)
• c checkers private, secret memory
• M fallible main memory

92
Picture of Checker
Main Memory M
Checker Memory c
size m
size n
Request Sequence x
Checker
size n
93
Theorem

• Checker needs ?log(n)-1 bits of private memory to
  avoid being fooled by adversary
• Else, may decode written tuple x as other tuple y
• Proof Outline
• Count number of possible system configurations
• Show if too few checker memory bits, gt1 valid
  main memory states for same checker memory
  configurations for same
• Thus, adversary can freely change main memory
  from one such valid state to another

94
Proof

• n size of main memory
• m lt log(n)-1 size of checker memory
• x input string of writes, length n
• sphere(x, M) vector of length 2m
• (one entry per checker memory state)
• sphere(x, M)cA if ltM,cgt is possible state of
  main and checker memory on input x
• sphere(x, M)c if ltM,cgt is possible state of
  main and checker memory on input ? x
• sphere(x, M)cI if ltM,cgt is not a possible
  state of main and checker memory on any input

95
Picture of sphere(x, M)
c
x,M
0,0..0
A
x,M
0,0..1
I
x,M
.

.
x,M
Is ltM,cgt possible encoding of x?
Checker Memory States(2m of them)

x,M
.
A
.
.
x,M
.
.
x,M
x,M
1,1..1
I

• If memory unchanged, checker must decode ltM,cgt as
  x with Prob1
• x was set of values written, so must be retrieved

96
Picture of sphere(x, M)
c
x,M
0,0..0
A
x,M
0,0..1
I
x,M
.

.
x,M
Is ltM,cgt possible encoding of x?
Checker Memory States(2m of them)

x,M
.
A
.
.
x,M
.
.
x,M
x,M
1,1..1
I

• Invariant 1 On input x, state of M and c must be
  s.t. sphere(x,M)c A
• By definition of sphere()

97
Invariant 2

• On inputs x?y, ?c,M sphere(x,M)c
  sphere(y,M)c cant both A
• Otherwise two inputs could map to same
  checker/main memory state
• Both if ltM,cgt gets mapped to by some other
  input z
• Both I if no input maps to ltM,cgt

98
Picture of sphere(x, M)
c
x,M
0,0..0
A
x,M
0,0..1
I
x,M
.

.
x,M
Is ltM,cgt possible encoding of x?
Checker Memory States(2m of them)

x,M
.
A
.
.
x,M
.
.
x,M
x,M
1,1..1
I

• If ?x s.t. ?M, ?y?x and M? s.t. sphere(x, M)
  sphere(y, M?) then on input x adversary can cause
  checker to decode y by changing M?M?

99
Proof of Claim

• Claim If ?x s.t. ?M, ?y?x and M? s.t. sphere(x,
  M) sphere(y, M?) then adversary can cause
  checker to decode y by changing M?M?
• Proof
• Checker gets input x, produces M, c s.t.
  sphere(x,M)c A
• For this M ?y, M? with same sphere
• Thus, sphere(y,M?)c A
• Therefore, if adversary switches M?M? then
  checker decodes ltM?, cgt as y
• Error undetected. Checker fooled!

100
Breaking the Checker

• Adversary needs to break checker on only one
  input x
• Thus, always guesses that inputx and always
  replaces M with M? (appropriate for this x)
• Uses M?M? mapping table (? Ms)
• Note
• If memory stateM but input is z?x,y then
  sphere(x,M)c sphere(y,M?)c
• Thus, if adversary M?M? then checker will still
  decode some input w (not x or y)
• Error undetected. Checker fooled!

101
Is This Possible?

• To defeat adversary checker needs
• For each x, ? M s.t. sphere(x, M) unique
• If so, checker can safely set memory to M on
  input x
• Will prove Collision Lemma? input x s.t. ?M. ?
  y?x and M? where sphere(x,M) sphere(y,M?)
• For n possible inputs x, n unique main memory
  states M
• Since checker deterministic
• Assumption total number of spheres a lt
  lt total number of inputs/memory states b

102
Visualization of Collisions
? input x s.t. ?M. ? y?x and M? where
sphere(x,M) sphere(y,M?)

• For each of b inputs, b main memory states
• For each state, one of a possible spheres
• altb

b MainMemoryStates
b Inputs
103
Visualization of Collisions
? input x s.t. ?M. ? y?x and M? where
sphere(x,M) sphere(y,M?)

• Must find some column s.t.
• For every entry in column

n MainMemoryStates
n Inputs
104
Proof of Lemma

• Will go left to right looking for our column
• Look at leftmost column

n MainMemoryStates
n Inputs
105
Proof of Lemma

• Will go left to right looking for our column
• Look at leftmost column

• If is it, then done
• If not, then ? entry in column with value
  contained in no other column

Not A
n MainMemoryStates
A
n Inputs
106
Proof of Lemma

• Same thing for other columns

• If target column, then done
• If not, then ? entry in column with value
  contained in no other column

n MainMemoryStates
Not Q
Not Q
Q
n Inputs
107
Proof of Lemma

• At each step, either finished or rightmost
  columns have 1 less possible value

n MainMemoryStates
n Inputs
108
Proof of Lemma

• At each step, either finished or rightmost
  columns have 1 less possible value

n MainMemoryStates
A
n Inputs
109
Proof of Lemma

• At each step, either finished or rightmost
  columns have 1 less possible value

n MainMemoryStates
A
B
n Inputs
110
Proof of Lemma

• At each step, either finished or rightmost
  columns have 1 less possible value

n MainMemoryStates
A
B
C
n Inputs
111
Proof of Lemma

• Reach 2nd to last column on step b-1
• (If not already finished)

• Total possible values lt b
• Thus, 1 value remains
• Last two columns satisfy criterion

Z
Z
Z
Z
n MainMemoryStates
Z
Z
Z
Z
Z
Z
Z
Z
n Inputs
112
Proof of Lemma
? input x s.t. ?M. ? y?x and M? where
sphere(x,M) sphere(y,M?)
Z
Z
Z
Z
n MainMemoryStates
Z
Z
Z
Z
Z
Z
Z
Z
x
y
n Inputs
113
Proving That Too Few Spheres

• Must still prove that fewer spheres than inputs
• Total inputs states a 2n
• Total unique spheres b (2m 3-ary values)
• mltlog(n)-1 and so,
• Fewer spheres than inputs
• blta
• Thus, Collision Lemma precondition satisfied

114
Checker Fooled

• Adversary can find x?y s.t. sphere(x,M)
  sphere(y,M?) ?M
• Since checker known
• Determines main memory remapping table M?M?
• For each M picks M? s.t. spheres equal
• For any input remaps main memory according to
  table
• If inputx, memory changed to M?M? and checker
  decodes it as y
• Error undetected. Checker fooled!

115
Deterministic ? Probabilistic

• Paper describes proof in fairly deterministic
  terms
• But seems to be saying that proof works for
  probabilistic checkers
• Seems plausible, but should check

116
Checkers With 2-sided Error

• Above theorem extended to relate reliability to
  number of bits in checker memory
• Applies to checkers with 2-sided error
• If main memory untouched by adversary, checker
  correctly decodes with Prob ? p
• If main memory corrupted, checker notices or
  correctly decodes with Prob ? p
• Theorem
• If decoding probability p ? ½ ½l1 then checker
  private memory must have m ? log n log l bits
• l ? 1

117
Meaning of Theorem

• Theorem
• If decoding probability p ? ½ ½l1 then checker
  private memory must have m ? log n log l bits
• l ? 1
• Meaning
• The fewer bits in checkers memory, the closer
  prob of success gets to ½.
• Prob ½ ? user cant differentiate success from
  failure

118
Meaning of Theorem

• Theorem
• If decoding probability p ? ½ ½l1 then checker
  private memory must have m ? log n log l bits
• l ? 1
• Connection to last theorem
• Case where 100 Prob of decoding non-corrupted
  (i.e. l0) covered by last theorem
• Need log n 1 bits
• This theorem generalizes last theorem
• Will now relate probability of success to
  reliable memory size

119
Proof

• Last proof looked at encoding process
• sphere(x,M)c is input x encodable into ltM,cgt?
• This proof looks at decoding
• sphere(x,M)c l-bit approximation of
  Probchecker decodes ltM,cgt into x
• sphere(x,M) is l?2m bit vector
• Number of spheres
• Number of inputs
• Suppose opposite m lt log n log l
• Then
• Fewer spheres than inputs

120
Collision Lemma

• Fewer spheres than inputs
• Recall Collision Lemma? input x s.t. ?M. ? y?x
  and M? where sphere(x,M) sphere(y,M?)
• Thus, adversary can find input x for which it can
  switch main memory M?M?
• Claim Probability of success gt1-p
• Recall Checker must have success Prob ?p

121
Playing Probabilities

• Let
• Given x was input
• q Prob of decoding x with untouched memory
• q? Prob of decoding y with corrupted memory
• Assuming adversary switched M with M?

122
Playing Probabilities

• sphere(x,M)c l-bit approximation of
  Probchecker decodes ltM,cgt into x
• Thus, Probchecker decodes ltM,cgt into x lt
  sphere(x,M)c ½ l
• Know that ? input x s.t. ?M. ? y?x and M? where
  sphere(x,M) sphere(y,M?)
• Since fewer spheres than inputs
• Thus
• Probchecker decodes ltM,cgt into x lt
  Probchecker decodes ltM?,cgt into y ½l

123
Playing Probabilities

• Probchecker decodes ltM,cgt into x lt
  Probchecker decodes ltM?,cgt into y ½l
• Via basic algebra q?gtq- ½l
• q Prob of decoding x with untouched memory
• q? Prob of decoding y with corrupted memory
• By definition, p prob of success
• ?p Prob of correct operation or fault detection
• p ? q
• Since q is probability of correct operation on
  input x
• q? ? 1-p
• Since q? is probability of not detecting x?y
  decoding

124
Playing Probabilities

• q?gtq- ½l
• q Prob of decoding x with untouched memory
• q? Prob of decoding y with corrupted memory
• p?q, q??1-p
• q? gt q- ½l1-p ? q? gt q- ½l ? p- ½l
  1-p gt p- ½l 1½l gt 2p ½½l1 gt p
• (Assumption was m lt log n log l)
• If decoding probability p ? ½ ½l1 then checker
  memory has m ? log n log l bits

125
Checker with Public Memory

• Previous checkers had secret memories
• What if checker has some public memory?
• (Public but incorruptible)
• Can we get away with less private memory?
• Will give proof for sequences of n writes
• Checker gets d?n public memory, dlt1
• (if d1 then checker can save writes in memory)
• Will show checker needs bits of secret memory

New Element
126
Public Memory Theorem

• Theorem If checker functions correctly with Prob
  p ? ½ ½l1 then checker secret memory must
  have bits
• Proof
• Assume opposite
• Let
• M corruptible main memory
• B incorruptible public checker memory
• c incorruptible private checker memory

127
Proof of Theorem

• Spheres defined as in last proof
• old_sphere(x,M)c l-bit approximation of
  Probchecker decodes ltM,cgt into x
• New element spheres depend on Bs state
• sphere(x,M,B)c l-bit approximation of
  Probchecker decodes ltM,B,cgt into x
• Still possible spheres
• possible public memory configurations

128
Proof of Theorem

• As before adversary assumes input is x
• Since only needs to fool on one input
• Adversary wants some M?M? mapping s.t. ltM?, c, Bgt
  decoded as y
• Will work if sphere(y,M?,B) sphere(x,M,B)

ltM,c,Bgt
x
Adversary
y
ltM?,c,Bgt
129
Proof of Theorem

• Adversary wants sphere(y,M?,B) sphere(x,M,B)
• Since (number of spheres ) lt (number
  of inputs ) apply Collision Lemma
• ?ltx,Bgt s.t. ?M ?y?x and M? s.t. sphere(y,M?,B)
  sphere(x,M,B)
• Now must show Prob of fooling checker gtp

130
Playing Probabilities

• As before, assuming x was input, compute
• q Prob of decoding x with untouched memory
• q? Prob of decoding y with corrupted memory
• Via algebra q?gtq- ½l
• p prob of success, ?q, ? 1- q?
• Basic Algebra ? p lt ½ ½l1
• (Assumption was
  )
• If decoding probability p ? ½ ½l1 then secure
  memory has
  bits

131
Summary

• Showed lower bounds for checker memory sizes
• Deterministic checker
• ? log(n)-1 bits of reliable, secret checker
  memory
• 2-sided error checker
• ? log n log l bits of reliable, secret memory
• Probability of success ? ½ ½l1
• Checker with d?n bits reliable, public memory
• log(n) log(1/(1-d) bits reliable, secret memory
• Probability of success ? ½ ½l1

132
Outline

• Definitions

• Offline Checkers
• RAMs
• Stacks
• Queues

• Online Checkers
• RAMs
• Stacks
• Queues

BEGKN

• Lower Bounds
• 3 Offline Checker Bounds

• Offline Checkers
• Stacks
• Queues

DS
133
Different Flavor of Checking

• DS Devanbu and Stubblebine, Stack and Queue
  Integrity on Hostile Platforms, 1998
• Offline checkers for Stacks and Queues
• Weaker adversary
• Adversary constant factor faster than checker
• No explanation for adversary limitation
• Time Overhead constant factor
• Space Overhead constant sized trusted memory
  (secret?)

134
Mechanisms

• Assumes signature scheme s.t.
• Collision resistant computationally infeasible
  to find two inputs that map to same output
• 2nd preimage resistant given an input,
  computationally infeasible to find other input
  mapping to same output
• Creates hashes of prior stack activity
• Stores hashes with stack elements

135
Checking Stacks

• Every stack element also contains signature
• Signature encoding of all elements below
• ? signature function

• Stack initially empty

Trusted Memory
Main Memory
136
Checking Stacks Push

• Every stack element also contains signature
• Signature encoding of all elements below
• ? signature function

• First push
• User pushes x1
• Checker pushes ltx1, srandgt
• srand is random
• Trusted Memory
• srand
• s1 ?(x1, srand)

srand
s1 ?(x1, srand)
ltx1, srandgt
Trusted Memory
Main Memory
137
Checking Stacks Push

• Every stack element also contains signature
• Signature encoding of all elements below

• General Push
• Given user op push(xi)
• Issue push(xi, sh)
• sh is stack signature
• New stack signaturesh1 ?(xi, sh)

srand
s1 ?(x1, srand)
ltx1, srandgt
Trusted Memory
Main Memory
138
Checking Stacks Pop

• Invariant stack signature computable from top
  element

• Pop
• Pop alleged ltxi, shgt off stack
• Check if sh1 ?(xi, sh)
• Sh1 is stack signature
• sh new stack signature

srand
s4 ?(x4, s3)
ltx4, s3gt
s3 ?(x3, s2)
s3 ?(x3, s2)
ltx3, s2gt
s2 ?(x2, s1)
s2 ?(x2, s1)
ltx2, s1gt
s1 ?(x1, srand)
s1 ?(x1, srand)
ltx1, srandgt
Trusted Memory
Main Memory
139
Checking Stacks Pop

• Invariant stack signature computable from top
  element

• Pop
• Pop alleged ltxi, shgt off stack
• Check if sh1 ?(xi, sh)
• Sh1 prior stack signature
• sh new stack signature

srand
ltx4, s3gt
s3 ?(x3, s2)
ltx3, s2gt
s2 ?(x2, s1)
s2 ?(x2, s1)
ltx2, s1gt
s1 ?(x1, srand)
s1 ?(x1, srand)
ltx1, srandgt
Trusted Memory
Main Memory
140
Checking Stacks Pop

• Invariant stack signature computable from top
  element

• Pop
• Pop alleged ltxi, shgt off stack
• Check if sh1 ?(xi, sh)
• Sh1 prior stack signature
• sh new stack signature
• Invariant Preserved

srand
s3 ?(x3, s2)
ltx3, s2gt
s2 ?(x2, s1)
s2 ?(x2, s1)
ltx2, s1gt
s1 ?(x1, srand)
s1 ?(x1, srand)
ltx1, srandgt
Trusted Memory
Main Memory
141
Intuition to Encoding

• Encoding has simple intuition
• ?() calls nested in stack fashion

ltx4, s3gt
ltx3, s2gt
ltx2, s1gt
s4 ?(x4, s3) ?(x4, ?(x3, s2)) ?(x4,
?(x3, ?(x2, s1))) ?(x4, ?(x3, ?(x2, ?(x1,
srand))))
ltx1, srandgt
142
Cant Pop Wrong Entry

• Suppose wrong entry popped
• Shouldve been ltxi, shgt
• Was ltx?j, s?qgt
• But sh1 ?(xi, sh) was in trusted memory
• To escape detection ltx?j, s?qgt must be
  s.t.?(x?j, s?q) ?(xi, sh) sh1
• Computationally hard to pick such ltx?j, s?qgt
• Since ? is 2nd preimage resistant

143
Popping Empty Stack

• On pop of last element stack signature srand
• Cant be fooled into popping more

• To fool, adversary must produce ltxi, sgt
  s.t.?(xi, sh) srand
• This is computationally hard
• ? is 2nd preimage resistant

srand
Trusted Memory
Main Memory
144
Checking Stacks Summary

• Trusted memory keeps digest of stack state
• Preserved across pushes, pops
• Small trusted memory size
• Unknowns
• Where is signature function recorded?
• Must be trusted memory
• What is power limit of adversary?

145
Outline

• Definitions

• Offline Checkers
• RAMs
• Stacks
• Queues

• Online Checkers
• RAMs
• Stacks
• Queues

BEGKN

• Lower Bounds
• 3 Offline Checker Bounds

• Offline Checkers
• Stacks
• Queues

DS
146
Checking Queues

• Stack checker keeps digest of stack contents
• Works because encodings function calls nest in
  stack fashion
• Function calls dont nest like queues
• No clear way to remove bottom call
• If keep digests of all elements ever enqueued, no
  need to remove

147
Checkers Digests

• Keep two digests
• sq signature of all items ever enqueued
• Including dequeued items
• sdel signature of all dequeued items
• Both sets act like queues
• New data gets pushed
• Nothing gets popped

148
Initial State

• srand initial random signature
• sq sdel ?(srand)
• Pretend that enqueued and dequeued srand

sdel ?(srand) sq0
TrustedMemory
sq0 ?(srand)
srand
?(srand)srand
MainMemory
Queue nodes
Dequeued nodes (not stored)
149
First Enqueue

• User operation enqueue(x1)
• Issued operation enqueue(?(x1, sq1))
• sq1 ?(x1, sq0)

sq0 ?(srand)
srand
sdel ?(srand) sq0
TrustedMemory
sq1 ?(x1,sq0)
same
?(srand)srand
sq1x1
MainMemory
Queue nodes
Dequeued nodes (not stored)
150
General Enqueues

• User operation enqueue(xi)
• Issued operation enqueue(?(xi, sqj))
• Sqj1 ?(xi, sqj)

srand
sdel ?(srand) sq0
TrustedMemory
same
?(srand)srand
MainMemory
Queue nodes
Dequeued nodes (not stored)
151
First Dequeue

• User operation dequeue()
• Issued operation dequeue() ? ltx1, sq1gt
• Recall sq1 ?(x1, sq0) ?(x1, srand)
• In general, dequeued sqj ?(x1, sdel)

sdel ?(srand) sq0
srand
TrustedMemory
sq1 ?(x1,sq0)
sq2 ?(x2, sq1)
sq3 ?(x3, sq2)
sq4 ?(x4, sq3)