View
5
Download
0
Category
Preview:
Citation preview
Author: Florencia Irena Supervisor: Professor Sri Parameswaran
Introduction: Homomorphic Processor
CryptoBlaze Architecture
Results
To keep its confidentiality, cloud data has to be stored in encrypted format. As a result, cloud processors have to be able to compute on encrypted data. These processors can be located anywhere physically and should not be allowed to access the real value of data (plaintext). Hence, a special method is required to allow computation on encrypted data without decryption process, while maintaining the correct computation on the plaintext domain. This special method is called “homomorphic encryption”, which requires specific sequences of operations on encrypted data to be equivalent with operation in plaintext domain. The sequences of operations vary between different homomorphic algorithms, but require expensive computations in general. This motivates the creation of processors that support homomorphic operations on hardware level. Several architectures, such as HEROIC and FURISC, have existed to try solving this problem. Each has its own advantages and disadvantages. Based on these, we are building a new homomorphic processor to try improving the performance and security of existing designs. Our architecture, named CryptoBlaze, is a multiple instruction machine that supports homomorphic operation on the basis of Paillier cryptographic algorithm.
Design Overview • Homomorphic addition support using Paillier Encryption Algorithm: “A” x “B” mod n2 = “A + B”, where n = public key. • Non-deterministic encryption: same data can be encrypted into different values • 8 instructions support for encrypted data to ensure Turing completeness: data memory load/store, homomorphic
addition, homomorphic subtraction, register and public key copy, branching on negative or non-negative Implementation • Built on top of MicroBlaze architecture, with 5 stages pipeline. • Encrypted data size = 4b, where b = the size of public key (security parameter) n. The actual size of an encrypted
value is 2b as Paillier encryption is modulo n2 based. To support homomorphic subtraction, CryptoBlaze stores data as “X”:”-X” pair, where “X” corresponds to 2b bits encryption of real data, and “-X” is 2b bits encryption of the negation.
• 32 x 4b eRegister file, a special 4b keyRegister file (to hold the value of n2), program and data memory • Data memory load/store via 32-bit AXI bus, requires 4b/32 cycles that will stall the processor.
CryptoBlaze Performance: No Decryption on MicroBlaze (Server Side), Using Pre-Computed Array for Branching
Body text: Arial font, 24pt
Conclusion and Future Work CryptoBlaze is a multiple instruction machine that works on the basis of non-deterministic Paillier Cryptosystem. It supports 8 instructions for encrypted data, including homomorphic addition, subtraction, and branching, which ensures Turing completeness. As homomorphic operations are expensive, CryptoBlaze is designed to work with various ALU sizes to support multicycle operations. ALU size of 512 bits is found to be most optimum for big security key sizes. In general, CryptoBlaze performs faster compared to existing homomorphic processors (HEROIC and FURISC), given an efficient decryption process on server-side to compute branching decision. In terms of security, CryptoBlaze is more robust in keeping data confidentiality compare to HEROIC due to non-deterministic property. However, the client-server communication link might lead into security abuses, and therefore need some protective measures, such as authorisation and limit, to ensure higher security. Aside from improving security, a new homomorphic architecture can be built using other homomorphic encryption schemes, either partially homomorphic or fully homomorphic, to be compared with CryptoBlaze performance. Effort into increasing speed of decryption process can also help to improve the performance of CryptoBlaze.
Experimental Setup
Homomorphic Cryptographic Processor Design and Implementation: The CryptoBlaze Architecture
We vary security parameter size (b) and ALU size (k) to assess CryptoBlaze performance and determine the most efficient hardware configuration by measuring maximum frequency and number of cycles taken to execute benchmark programs on Xilinx Virtex-6 ML605 FPGA. The client-server communication for branching is modelled by having MicroBlaze as server to determine branching condition, which is connected to CryptoBlaze (client) via 32-bit AXI bus. As decryption process can be expensive, our testing mainly uses a pre-computed array of branching in server side to make it O(1) operation. We then compare the results with those using decryption process (a basic and unoptimised version) to analyse the effect of having server-side decryption to CryptoBlaze performance.
Most Efficient Configuration for each Security Parameter Size b b
(bits) Most Efficient k
(bits) Max Freq (MHz)
Bubble Sort Latency (ms)
Throughput/Area (/s.%area)
32 128 125 24.78 576.54 64 256 125 32.88 253.21
128 512 80 129.48 64.35 256 256 110 456.99 10.42 384 512 60 935.90 3.56 512 512 60 1663.46 1.59
1024 128* 60* 19757.83* 0.07* * = might not be most efficient as build fails for higher ALU sizes (k) due to
out of memory from synthesis tool.
CryptoBlaze Performance: Decryption vs No Decryption on Server Side
Server Side Branching Program Cycles Taken For CompuJng Factorial of “9”
b = 32, k = 32 b = 32, k = 64 b = 64, k = 32 b = 64, k = 64 No Decryp6on (Pre-‐Computed Array) 65741 41546 229757 130477
With Decryp6on (Basic, Inefficient) 980893237 980869042 8873259035 8873159755
CryptoBlaze vs HEROIC: #Instructions
Architecture Number of Executed InstrucJons Fibonacci Factorial Bubble Sort
HEROIC 1617294 1011994 1882234
CryptoBlaze 898 5657 112882
CryptoBlaze vs HEROIC vs FURISC Architecture + -‐
HEROIC Par$ally Homomorphic
• Encrypted Instruc6ons • Fast
• Single instruc6on • Determinis6c (Large LUTs Lookup)
FURISC Fully Homomorphic
• Encrypted Instruc6ons • Support all opera6ons • Non-‐determinis6c
• Single instruc6on • Slow due to recryp6on and bitwise
cryptosystem CryptoBlaze Par$ally Homomorphic
• Non-‐determinis6c • “Fast”, given efficient
server-‐side decryp6on • Mul6ple instruc6ons
• Performance highly dependent on decryp6on
• Security: Client-‐server communica6on abuse and unencrypted instruc6ons
We have successfully built CryptoBlaze for security parameter sizes (b) ranging from 32 to 1024 bits. For each key size, we vary ALU sizes (k) to examine trade-off between maximum frequency achieved and number of cycles taken for running a program. Each security parameter size has its optimum ALU size. In general, 512 bits security key size gives optimum configuration for large security key size. All built hardware passed tests for correctness. Assuming that the decryption operation in server-side to compute branching is O(1), CryptoBlaze outperforms both HEROIC and FURISC as it supports multiple instructions (except for the case of 1024-bit b, as built failed for high ALU sizes). However, decryption process can be expensive in reality and thus become the most determining factor of CryptoBlaze performance. In terms of security, CryptoBlaze has some security advantages compared to HEROIC, as it utilises non-deterministic encryption which is more robust against security attacks. However, CryptoBlaze does not encrypt program memory, and client-server communication for branching can be abused to gain information about data. CryptoBlaze do not have security advantage against FURISC, but is expected to perform faster.
• Homomorphic addition and subtraction are
supported on the basis of multicycle multiplier and divider (using hardware bit shifts and addition/subtraction), as these operations can be expensive for high bits data. The adders/subtractors in multiplication and division blocks are designed to be multicycle with customisable ALU size (k).
• Branching is supported via client-server communication, where CryptoBlaze acts as client that sends encrypted data to a trusted server. The server is then responsible to determine whether the encrypted data corresponds corresponds to a negative number, and sends signal (0/1) back to CryptoBlaze. CryptoBlaze will decide whether to do branching based on this received signal. The server can determine negative data by Paillier decryption process, since server is trusted and has access to the private key.
Recommended