Figure 6.3 depicts the architectural model of the CypherDB processor. The key idea behind the CypherDB architecture is to deploy dedicated hardware data paths to separately handle the aforementioned three different types of data commonly found in any database application. These three different types of data are stored in different locations in off-chip memory, which are desig- nated as “compartments”: Seed Memory Compartment (SeedMem) for storing encryption seeds, Secure Memory Compartment (SMC) for storing execution data, and Database Page Compartment (DBPage) for storing attribute data and metadata. Three data paths are designed to load the data into the proces- sor in DBPage and SMC memory compartments securely and efficiently (see Figure 6.3):
ALU Register file
L1 D-Cache
Random number generator
L2 D-Cache
DBPage seed buffer SMC seed buffer SMC (execution data) SeedMem (encryption seeds) DBPage (attribute data, metadata)
Memory
CypherDB Secure Processor
1 2 3 me tad at a at tr ibute da ta AES Encryption Engine On-Chip Private Key
Database encryption key Query encryption key
SMC encryption key Encryption Key Registers
AES Encryption Engine
Non-volatile memory Volatile memory Protection Boundary S bit S bit
Figure 6.3: Proposed architecture of the CypherDB secure processor. Off-chip mem- ory is partitioned into three compartments. Three data paths are set up to execute the three different types of data. The components in grey indicate additional hard- ware features.
• Data path 1 : It is an unmodified data path akin to that used in a conventional processor to process non-sensitive metadata, which causes no processing penalty.
• Data path 2 : The attribute data are executed on this data path with the use of our proposed look-ahead encryption scheme. Since registers are the only visible storage for software, the AES encryption engine is therefore placed between the level 1 data cache and the register files. • Data path 3 : All execution data have to follow this data path where
the AES encryption engine is placed closest to the chip boundary. The encryption or decryption is done on the entire cache line which is com- pletely transparent to the application software.
Four new special registers are used to store the encryption keys. There is no instruction to read the contents of these registers, which protect these encryp- tion keys from any malicious software. A random number generator is used to create random bit vectors for security purposes. An addition bit (S_bit) is appended to each data cache line entry to indicate whether protection is required. DBPage and SMC seed buffers are on-chip memory used to store the attribute seeds and the SMC encryption seeds, respectively. The purpose of these on-chip buffers is to reduce the off-chip memory access of fetching the seed for encryption.
6.2.1 Private Key Registers
There are four encryption keys employed in our secure query processing: on- chip private key, database encryption key, query encryption key and SMC encryption key. Their functionalities are summarized in Table 6.1.
An on-chip private key is written into the on-chip non-volatile register dur- ing chip manufacturing. There is no instruction support to modify or extract this key from the register. For the other three encryption keys, there is only
Table 6.1: A summary of the functionality of the four encryption keys used in secure query processing
Encryption Keys Functionality
On-chip Private Key
Encrypt or decrypt the database encryption and query encryption key in key encapsulation mechanism, and sign the digital certification for secure processor attestation
Database Encryption Key Encrypt or decrypt the attribute data duringsecure query processing in our proposed encryp-
tion scheme
Query Encryption Key Encrypt the query result using our proposed en-cryption scheme
SMC Encryption Key Encrypt or decrypt the cache line in SMC toprotect execution data during query processing
instruction support to store the keys in these on-chip registers but not to ex- tract them. Database and query encryption keys are obtained from the key encapsulation mechanism described in Section 4.2.1. They can be dynamically stored in the on-chip registers with special instructions. A SMC encryption key is generated by the on-chip random number generator at the beginning of a secure query execution.
6.2.2 New Security Instructions
The new instructions and their functionalities to support CypherDB are sum- marized in Table 6.2. The architecture of these new instructions on OpenRISC (our implementation prototype) is presented in Appendix A.
During the key exchange process between the database owner and the
cloud servers, the database encryption key Kdb and query encryption key
KQ are stored in the on-chip registers via the load_encKey instruction. The
load_encKey instruction takes EPK(Key) as the input which contains either
an encrypted database or query encryption keys and decrypts it using the on-chip private key. The switch_encKey instruction is used to switch the use of encryption key, between database encryption key and query encryption
Table 6.2: New Instructions in CypherDB
New Instructions Description
start_cypherdb_query Allocate SMC and generate SMC encryption key, andinitiate the encryption seed in SeedMem
end_cypherdb_query Dis-allocate SMC and destroy SMC encryption key
l.seed Load/Store attribute seed for attribute decryp-tion/encryption
l.shift Shift the encryption pad according to the value indi-cated in the operand of the instruction
l.sload/l.sstore Decrypt/encrypt attribute data with the encryptionpad
set_sr Set a security register value which stores the param-eter to be used in the proposed architecture
load_encKey Load the encrypted database key and encryptedquery key; and decrypt the keys with private key and
store in on-chip registers
switch_encKey Switch the encryption key used in the AES encryptionengine along data-path 2 between database key and
query key
verify_encKey Verify the database key and query key by checkingthe digital signature Sig(EPKC(Kdb),EPKC(KQ))for on-
chip verification of the query encryption key
cate Sig(EPK(Kdb,KQ))by checking the signature, decrypting EPK(Kdb,KQ)and
comparing the Kdb and KQ with the on-chip key value. The sign_cert instruc-
tion uses the on-chip private key to generate a digital certificate for processor attestation.
To start the query execution, the start_cypherdb_query instruction is ex- ecuted to perform three tasks: 1) allocate the SMC memory, 2) generate a per-query SMC encryption key and 3) initiate the encryption seed in Seed- Mem. The l.sload, l.sstore, l.shift and l.seed instructions are used to realize our proposed encryption scheme. The set_sr instruction is used to write or read some parameters in our proposed architecture to security registers (e.g. SMC and SeedMem memory boundary address). To end the query execution, the end_cypherdb_query instruction is executed to free the SMC memory and destroy the SMC encryption key.