SHELDB: Client Storage Aware Homomorphic Encrypted Database Processing Framework With Low Communication Overhead
Database as a service (DBaaS) in cloud raises severe concern in terms of data security. Storing data in encrypted form may confirm data confidentiality. But, database processing cannot be supported in this encrypted form. Theoretically, homomorphic encryption is a solution to support direct encrypte...
Gespeichert in:
| Veröffentlicht in: | IEEE transactions on services computing Jg. 18; H. 2; S. 1026 - 1038 |
|---|---|
| Hauptverfasser: | , |
| Format: | Journal Article |
| Sprache: | Englisch |
| Veröffentlicht: |
IEEE
01.03.2025
|
| Schlagworte: | |
| ISSN: | 1939-1374, 2372-0204 |
| Online-Zugang: | Volltext |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Zusammenfassung: | Database as a service (DBaaS) in cloud raises severe concern in terms of data security. Storing data in encrypted form may confirm data confidentiality. But, database processing cannot be supported in this encrypted form. Theoretically, homomorphic encryption is a solution to support direct encrypted data processing. In this work, we highlight one of the major challenges of FHE- encrypted query processing that demands huge data transfer requirements from cloud to client for final decryption at the end of SQL query execution. We show in light of Chosen Plaintext Attack (CPA) that in spite of performing conditional filtering through SQL queries over encrypted databases, the size of the resultant dataset cannot be less than the original size of the database. In this work, we make an effort to propose a new encrypted query processing framework termed as SHELDB which supports client storage compatibility and low communication overhead using block-wise final result transmission from cloud to client by extending the concept of TOP operator implementation in standard SQL. However, it is to be noted that realization of such optimization is not straightforward because of circuit-based implementation requirements with FHE gates. Our experimental demonstration shows that the proposed framework is capable of executing all TPC-C standard SQL queries with the aid of 8-core parallel processing within <inline-formula><tex-math notation="LaTeX">\sim 12.65</tex-math> <mml:math><mml:mrow><mml:mo>∼</mml:mo><mml:mn>12</mml:mn><mml:mo>.</mml:mo><mml:mn>65</mml:mn></mml:mrow></mml:math><inline-graphic xlink:href="parbat-ieq1-3539189.gif"/> </inline-formula> minutes for an encrypted database of <inline-formula><tex-math notation="LaTeX">768 \times 9</tex-math> <mml:math><mml:mrow><mml:mn>768</mml:mn><mml:mo>×</mml:mo><mml:mn>9</mml:mn></mml:mrow></mml:math><inline-graphic xlink:href="parbat-ieq2-3539189.gif"/> </inline-formula> size with 16-bits elements each. Though the computation time is linear with the number of rows, we have explored map-reduce type parallel processing techniques to reduce the timing requirements for databases with larger rows. Consequently, our new query processing framework reduces the communication overhead from m to <inline-formula><tex-math notation="LaTeX">\delta k</tex-math> <mml:math><mml:mrow><mml:mi>δ</mml:mi><mml:mi>k</mml:mi></mml:mrow></mml:math><inline-graphic xlink:href="parbat-ieq3-3539189.gif"/> </inline-formula> rows (<inline-formula><tex-math notation="LaTeX">1 \leq \delta \leq block</tex-math> <mml:math><mml:mrow><mml:mn>1</mml:mn><mml:mo>≤</mml:mo><mml:mi>δ</mml:mi><mml:mo>≤</mml:mo><mml:mi>b</mml:mi><mml:mi>l</mml:mi><mml:mi>o</mml:mi><mml:mi>c</mml:mi><mml:mi>k</mml:mi></mml:mrow></mml:math><inline-graphic xlink:href="parbat-ieq4-3539189.gif"/> </inline-formula>) where the encrypted database contains m rows, <inline-formula><tex-math notation="LaTeX">\delta</tex-math> <mml:math><mml:mi>δ</mml:mi></mml:math><inline-graphic xlink:href="parbat-ieq5-3539189.gif"/> </inline-formula> is the number of blocks to be transmitted each time with <inline-formula><tex-math notation="LaTeX">k</tex-math> <mml:math><mml:mi>k</mml:mi></mml:math><inline-graphic xlink:href="parbat-ieq6-3539189.gif"/> </inline-formula> = (<inline-formula><tex-math notation="LaTeX">m/block</tex-math> <mml:math><mml:mrow><mml:mi>m</mml:mi><mml:mo>/</mml:mo><mml:mi>b</mml:mi><mml:mi>l</mml:mi><mml:mi>o</mml:mi><mml:mi>c</mml:mi><mml:mi>k</mml:mi></mml:mrow></mml:math><inline-graphic xlink:href="parbat-ieq7-3539189.gif"/> </inline-formula>) rows. In spite of <inline-formula><tex-math notation="LaTeX">k</tex-math> <mml:math><mml:mi>k</mml:mi></mml:math><inline-graphic xlink:href="parbat-ieq8-3539189.gif"/> </inline-formula> being a controllable parameter according to client storage and <inline-formula><tex-math notation="LaTeX">\delta</tex-math> <mml:math><mml:mi>δ</mml:mi></mml:math><inline-graphic xlink:href="parbat-ieq9-3539189.gif"/> </inline-formula> is dependent on the query parameters, final security analysis explains why the proposed technique is general database attack-resistant. |
|---|---|
| ISSN: | 1939-1374 2372-0204 |
| DOI: | 10.1109/TSC.2025.3539189 |