A User Centric Security Model for Tamper-Resistant Devices

8.3 Runtime Protection Mechanism
and integrity stack, respectively. Furthermore, the runtime security manager will also
generate a random number and stores it as S r . The rationale for using the random number
will become apparent in the subsequent discussion.
V 7
Push(V 7 )
V 7
Push(V Ins-7 = V Ins-6 ⊕V 7 )
V Ins-7
V 6
Push(V 6 )
V 6
Push(V Ins-6 = V Ins-5 ⊕V 6 )
V Ins-6
V 5
Push(V 5 )
V 5
Push(V Ins-5 = V Ins-4 ⊕V 5 )
V Ins-5
V 4
Push(V 4 )
V 4
Push(V Ins-4 = V Ins-3 ⊕V 4 )
V Ins-4
V 3
Push(V 3 )
V 3
Push(V Ins-3 = V Ins-2 ⊕V 3 )
V Ins-3
V 2
Push(V 2 )
V 2
Push(V Ins-2 = V Ins-1 ⊕V 2 )
V Ins-2
V 1
Push(V 1 )
V 1
Push(V Ins-1 = S r ⊕V 1 )
V Ins-1
Operand Stack
Integrity Stack
Figure 8.5: Operand and integrity stack push operations
Consider there are seven values (V 1 , V 2 , V 3 , ... , V 7 ) that are going to be pushed onto an
operand stack. The operations performed at each push operation for these seven values are
shown in gure 8.5. When V 1 is pushed onto the operand stack, the integrity stack does not
have any value. Therefore, at the beginning integrity stack will XOR V 1 with the generated
random value S r : it is the starting point of the integrity calculation. When an item is
pushed on to the operand stack, we XOR the pushed value with the value on the top of the
integrity stack. The result is pushed back on to the integrity stack. The push operation
can be represented as V Ins-n =V Ins-(n-1) ⊕V n , where n is index to the integrity stack, V Ins-n
is the value stored on the integrity stack. Furthermore, the value on the top of an integrity
stack is V Ins-n =S r ⊕Σ n i=1 V i. Therefore, if a card manufacturer wants to implement the α
as proposed by the Barbu et al. [217] then it can simply do it by α = S r ⊕V Ins-n .
The rationale for using a random number is to avoid parallel fault injections that try to
change the values on both operand and integrity stack simultaneously. Such a parallel
fault injection will become dicult if an adversary cannot predict the values stored on the
integrity stack, as each value on the integrity stack will be chained with the generated
random number. One point to note is that, although the attacker's capability dened in
section 8.3.2 prohibits parallel fault injection but we still try to accommodate it in our
proposals; as such attacks might become realistic in future.
When a value is popped out of the operand stack, we also pop the integrity value from the
integrity stack, XOR it with the popped value from the operand stack and compare it with
the new top value on the integrity stack. If the values match then integrity of the popped
value from the operand stack is veried; otherwise, it has been corrupted and the runtime
security manager requests the JCVM to terminate the execution as shown in listing 8.2.
To explain it further, consider that we pop V 7 from the operand stack in gure 8.5. The
runtime security manager will also pop V Ins-7 from the integrity stack, calculate InsValue
= V Ins-7 ⊕V Ins-6 and compare the InsValue with the V 7 . If InsValue and V 7 match, then
the JCVM will proceed with the execution; otherwise, it will abort the execution.
202