The attribute data are protected by our proposed look-ahead encryption scheme. It uses the l.seed instruction to load the encryption seed into an on-chip regis-
ter Regseed and compute the encryption pad, l.sload/l.sstore to load (or store)
and decrypt (or encrypt) the data, and uses l.shi ft to shift the encryption pad accordingly (see Section 5.2). As this l.shi ft instruction is used every time to shift the encryption pad, it introduces additional instruction and execution overhead. To alleviate these drawbacks, a hardware shifter is used to shift the encryption pad automatically after each l.sload/l.sstore instruction based on the observation that the attribute data are usually accessed in sequence from the first byte to the last byte.
Figure 6.5 depicts the flow chart of the hardware shifter. The key idea of this hardware shifter is to perform encryption pad shifting implicitly after each
l.sload/l.sstoreinstruction but allows explicit shifting using l.shi ft and l.seed
instructions. The hardware shifter is able to implicitly shift the encryption pad in accordance with the granularity of the l.sload/l.sstore instruction. l.shi ft can override l.sload/l.sstore to shift the encryption pad to the value indicated in the operand. The total number of bits being shifted is recorded and stored
in a special register Regshi f t. When the encryption pad is shifted to the end
(Regshi f t 16), a new encryption pad is generated for the use of AES-OFB en-
cryption. To decrypt/encrypt another attribute datum, the l.seed instruction
can generate a new encryption pad and reset Regshi f t to zero.
6.4.1 DBPage Seed Buffer
The purpose of the DBPage seed buffer is to store a subset of attribute seeds to on-chip memory, so that the attribute seeds can be served faster when needed. As described in Section 5.3, each attribute datum requires an attribute seed in our proposed look-ahead encryption scheme. This attribute seed is formulated
l.sload/ l.sstore? Regshift = 16? encPad = AES(encPad) Regshift = 0 START l.seed? encPad = AES(seed) Regshift = 0 END l.shift? encPad << y Regshift = y
YES YES YES
YES
NO
Regshift: Total number of bits being
shifted
encPad: encryption pad
x: Granularity of l.sload instruction y: Number of bits to shift indicated
by the l.shift instruction
x l.sload/l.sstore 4 load/store word 2 load/store half 1 load/store byte encPad << x
Regshift = Regshift + x
Figure 6.5: A flow chart describing the hardware shifter that implicitly shifts the encryption pad for different granularity of l.sload/l.sstore instructions. The l.shi ft and l.seed can override the operation of hardware shifter to explicitly set the value of Regshi f t.
execution. The only seed component requiring extra storage is the record counter, which is shared by all attributes within a record. A mapping table is used to take rowID as the input to retrieve the corresponding record counter. Without the DBPage seed buffer, off-chip memory access of the record counter is necessary to encrypt/decrypt each attribute being stored/loaded. One of the key ideas of our proposed encryption scheme is to pre-compute the encryption pad so as to hide the encryption latency from the program execution. An off-chip memory access of the record counter virtually lengthens the latency of the encryption pad computation by an off-chip memory access latency. This requires l.seed to be issued even earlier which makes the task of encryption latency hiding much more difficult (see Section 5.2.1).
The DBPage seed buffer can reduce the frequency of off-chip memory access by keeping a number of record counters in the buffer. As fetching the record counters in an on-chip buffer can be achieved in a few processor cycles, it is much faster than off-chip memory access which takes hundreds of cycles to complete. Figure 6.6 depicts a flow chart of our proposed encryption scheme with the assistance of a DBPage seed buffer. We can see that l.seed is used to fetch the record counter in SeedMem. This operation is redirected to the DBPage seed buffer. The DBPage seed buffer calls a function seed(rowID) to search for the record counter locally. If the record counter is stored in the buffer, it can be used directly to compute the encryption pad; otherwise, the record counter is fetched from the off-chip memory. The execution flow along data path 2 is very similar to data path 1 , except that the data being fetched/stored need to wait for the encryption pad until it is ready and undergoes decryption/encryption (XOR operation) before being written into cache/off-chip memory.
start
program execution
l.seed?
DBPage buffer hit?
load seed from off-chip memory compute
encryption pad
encryption pad ready?
write decrypted (or encrypted) sensitive data to cache (or off-chip memory)
end
load/store sensitive data load/store metadata
write metadata to cache/ off-chip memory
Normal data execution (data path 1) Secure data execution (data path 2)
P ar al le l e xe cut ion Yes No No Yes Yes
Figure 6.6: A flow chart describing the execution flow of data path 1 and data path 2 with the assistance of a DBPage seed buffer. The DBPage buffer can reduce the frequency of off-chip memory access to fetch the attribute seed.