| Literature DB >> 35531323 |
Kundan Munjal1,2, Rekha Bhatia3.
Abstract
Cloud computing and cloud storage have contributed to a big shift in data processing and its use. Availability and accessibility of resources with the reduction of substantial work is one of the main reasons for the cloud revolution. With this cloud computing revolution, outsourcing applications are in great demand. The client uses the service by uploading their data to the cloud and finally gets the result by processing it. It benefits users greatly, but it also exposes sensitive data to third-party service providers. In the healthcare industry, patient health records are digital records of a patient's medical history kept by hospitals or health care providers. Patient health records are stored in data centers for storage and processing. Before doing computations on data, traditional encryption techniques decrypt the data in their original form. As a result, sensitive medical information is lost. Homomorphic encryption can protect sensitive information by allowing data to be processed in an encrypted form such that only encrypted data is accessible to service providers. In this paper, an attempt is made to present a systematic review of homomorphic cryptosystems with its categorization and evolution over time. In addition, this paper also includes a review of homomorphic cryptosystem contributions in healthcare.Entities:
Keywords: Cryptonets; Fully Homomorphic Encryption; Health Informatics; Homomorphic Encryption; Secure Learning
Year: 2022 PMID: 35531323 PMCID: PMC9062639 DOI: 10.1007/s40747-022-00756-z
Source DB: PubMed Journal: Complex Intell Systems ISSN: 2199-4536
Fig. 1Homomorphic encryption in healthcare
Fig. 2Steps in systematic review
Research questions
| Research Questions | Motivation |
|---|---|
| 1. | Homomorphic encryption techniques are built on the foundation of partial and somewhat homomorphic encryption. It’s crucial to review by comparing all types of homomorphic systems. These homomorphic encryption approaches are examined based upon hard problems, efficiency, and accuracy. |
| 2. Revolutionary work in Homomorphic Encryption 1. Why Craig Gentry work is considered as revolutionary work in homomorphic encryption? 2. How somewhat homomorphic encryption act as fully homomorphic encryption using bootstrapping? | Craig Gentry provided the first FHE approach. The implementation of Gentry’s groundbreaking FHE method resulted in a slew of advancements that established the basis for a slew of subsequent projects. This development has been classified in a variety of ways. At first, the Gentry Scheme was somewhat homomorphic, but bootstrapping made it fully homomorphic. It is important to study and understand the Craig gentry approach as it leads to advancement in fully homomorphic encryption mainly in the area of machine learning [ |
| 3. Homomorphic Encryption in Healthcare and medical Informatics 1. What are the various approaches of homomorphic encryption in healthcare and medical informatics? 2. How has homomorphic encryption in healthcare industry is evolved over time? 3. What evaluation methods have been used to check the correctness of these approaches? | Digitizing a patient’s health information is expected to increase care quality and efficacy while lowering costs. On the other hand, patient records include a great deal of sensitive information. As a result, a simple, trustworthy, efficient, and secure method is required in which patients may quickly permit a variety of medical affiliates to access their sensitive information. Therefore, it’s critical to investigate the use of homomorphic encryption in healthcare and evaluate different homomorphic methods for disease prediction, querying of data, while maintaining patient data privacy. |
Fig. 4Research articles selection procedure
Fig. 3Scientific Articles from year 2009 to 2021
Fig. 5Classification of homomorphic encryption
Comparison of partial homomorphic encryption schemes
| Name of algorithm | Additive homomorphic | Multiplicative homomorphic | Hard problem base | Key generation | Encryption | Decryption |
|---|---|---|---|---|---|---|
| [ | No | Yes | Large prime factorization | |||
| [ | Yes | No | Quadratic residuosity | n=pq and random y as quadratic non residue modulo n i.e.. | ||
| [ | No | Yes | Discrete logarithms | Public key is | ||
| [ | Yes | No | High residuosity problem | Two large prime numbers with a block size | ||
| [ | Yes | No | Composite residuosity problem | |||
| [ | ||||||
| [ | ||||||
| [ | ||||||
| [ | ||||||
| [ | ||||||
Fully homomorphic encryption schemes
| Name of algorithm | Lattice based | Integer based | (R)LWE | NTRU | Hard problem base |
|---|---|---|---|---|---|
| [ | Bounded distance decoding problem over ideal lattices and sparse subset sum problem for squashing the decryption circuit | ||||
| [ | Approximate greatest common divisor | ||||
| [ | Ring based learning with error | ||||
| [ | RLWE and Decisional Small polynomial Ratio (DSPR) Assumption | ||||
| [ | SWHE uses hardness of RLWE and Squashing step uses SSSP (Sparse subset sum problem) | ||||
| [ | Shortest Independent Vector Problem | ||||
| [ | Bounded distance decoding problem for SWHE, Sparse subset sum problem for bootstrapping | ||||
| [ | Decisional approximate-GCD problem and error-free approximate GCD | ||||
| [ | GapSVP | ||||
| [ | Approximate-GCD problem | ||||
| [ | Approximate Eigen vector method |
Fully homomorphic encryption in libraries
| Library | Implemented algorithms | Summary |
|---|---|---|
| HElib [ | [ | Helib is licensed under Apache 2.0 and created by IBM in C++. HElib also optimizes efficient homomorphic evaluation, with a focus on the Gentry-Halevi-Smart optimizations also using ciphertext packing techniques effectively |
| TFHE [ | [ | TFHE is a C/C++ package that provides gate-by-gate bootstrapping at a high speed. The utility allows us to evaluate any binary gated Boolean circuit over encrypted data without disclosing any data specifics |
| Seal [ | [ | SEAL stands for Simple Encrypted Arithmetic Library is an open-source platform software library developed by Microsoft cryptography and privacy research group. Microsoft SEAL is an MIT-licensed developed in C++ that is simple to compile and run |
| FHEW [ | [ | FHEW is free software provided under the terms of the GNU General Public License. The library is written in the C programming language. The library utilises a symmetric encryption method to encrypt (and decrypt) single bit communications and allows evaluation of arbitrary Boolean circuits homomorphically over encrypted data using a public (evaluation) key. |
| HEAAN [ | [ | HEAAN is a software library that enables fixed point arithmetic with homomorphic encryption (HE). This C++ library allows you to perform approximate operations on rational numbers. The approximate error is affected by a number of factors, and the same is true for floating point operation errors |
| NFLIB [ | [ | The homomorphic encryption algorithm is implemented by FV-NFLlib, a software library (HE). FV-NFLlib is built on the NFLlib C++ library for ideal lattice cryptography and implements the Fan-Vercauteren (FV) scheme |
| PALISADE [ | [ | PALISADE implements lattice cryptography building blocks and popular homomorphic encryption approaches in an optimized way |
| CINGULTA[ | [ | Cingulata is a C++ compiler toolchain and RTE that uses fully homomorphic encryption approaches to run C++ programmes over encrypted data |
| Lattigo [ | [ | Lattigo is a Go module that implements homomorphic encryption primitives based on Ring-Learning-With-Errors and secure protocols based on Multiparty-Homomorphic-Encryption |
| Pyfhel [ | Microsoft Seal, HElib, Palisade | Perform encrypted homomorphic computations such as addition, multiplication, scalar product, or matrix multiplication in Python with NumPy compatibility using PYthon For Homomorphic Encryption Libraries. Backends are SEAL/PALISADE |
| [ | ||
| cuYashe [ | [ | cuYASHE is the first GPGPUs implementation of the YASHE levelled fully homomorphic technique. To achieve significant speed increases, this library uses the CUDA platform and several algebraic techniques such as CRT, FFT, and polynomial and modular reduction optimizations |
Comparison of homomorphic encryption in Healthcare based upon disease prediction and performance
| Paper | Database used | Disease prediction | Encryption time | Decryption time | Addition time | Multiplication time | Any other Processing Time | System Specifications |
|---|---|---|---|---|---|---|---|---|
| [ | ECG Monitoring [ | LTQC (Long QT Syndrome) | 1.65 sec with BGV and 1.45 s with Gentry | 0.65 s with BGV and 0.2 s with gentry | 0.11 with BGV and | 0.8 in BGV and 1.79ms in Gentry | 24.95 ms in gentry | dual-Xeon model E5450 node with 16 GB RAM, quad-cores frequency 3 GHz |
| [ | Live data | Cardiovascular disease | 13ms | 11ms | < 1ms | 39ms | - | Intel Core i7-3520 M at frequency 2893.484 MHz with polynomial degree 4096 and coefficient size 128 bit |
| [ | Live data | Cardiovascular disease | 577ms | 549ms | 1ms | 5056ms | - | Intel Core i7-3520 M at frequency 2893.484 MHz with 16384 coefficients of size 512 bit |
| [ | ECG Monitoring THEW [ | LQTC (Long QT Syndrome) | 0.41 s with ECG data interval of 24 hrs | 0.31 s with ECG data interval of 24 hrs | – | - | – | Intel Xeon model E5-2695 processor with ram 252GB |
| [ | – | Blood pressure | 23ms with CPU and 0.16ms with GPU | 5ms with CPU and 1ms with GPU | 0.25ms with CPU and 0.07ms with GPU | 87.8ms with CPU and 0.838ms with GPU | – | Intel Core-i7 5930K with frequency 3.5GHZ,DDR4 Ram 32 GB, GPU NVIDIA GeForce GTX980 with frequency 1126 MHz and 4GB memory |
| [ | ECG monitoring THEW[ | LQTS (Long QT Syndrome) | 1.80 s and 0.26 s with bit length 32 and 16 respectively in 24 hr monitoring data | 0.85 s and 0.25 s with bit length 32 and 16 respectively in 24 h monitoring data | 502 min with bit length 32 and 1165 min with bit length 16 respectively in 24 hr monitoring data | – | Intel-Xeon workstation W3565 work with 4 cores and 8 threads, RAM 24 GB running 64-bit Ubuntu 15.04 | |
| [ | ECG Monitoring THEW[ | Average Heart rate detection | 560ms | 550ms | 9.7 s only for additive operation as it is partial and additive homomorphic scheme | – | Intel-Xeon workstation W3565 work with 4 cores and 8 threads, RAM 24GB running 64-bit Ubuntu 15.04 | |
| [ | – | LQTS, Average Heart Rate | 635.42ms, 907.86 ms, 1254.71 ms, 1721.49 ms, 2241.55 ms with security parameter 200, 250, 300, 350, 400 respectively | – | Two Intel (R) Core(TM) i5-3470 CPU processors, frequency 3.20 GHz, RAM 8.00 GB, and 4:00 GB Virtual memory storage allocated, Operating system with single processor Ubuntu 12.04 | |||
| [ | i2b2 demo dataset from three different sites total of 32,301 rows | No Disease Prediction only querying of Data | 13.77ms including interactive two party encryption protocol | 0.9 ms | – | – | 0.004ms Homomorphic aggregation | Intel Xenon E5645 processor with frequency 2.40GHz and RAM 4 GB |
| [ | Sensor data of 45 patients using Polar H7 device and 500 patient dataset | Delayed Repolarization of Heart Syndrome | Performance time is 0.35 in 24 h monitoring data with 2079 cipher texts and 7.3 GB uploaded and 9.6 GB downloaded data including storage ratio of 53.6 | – | Data stored in IBM Cloudant infrastructure homomorphic processing is done in Apache spark service in IBM Bluemix Platform and for event based handlers IBM OpenWhisk programming service | |||
| [ | Simulation dataset based of statistical data by referring data given by Japan ministry of Health, Labour and Welfare | Query Generation | When no threading was in use then total Time is 236.72 s with FHE time is 195.82 s and with 28 maximum 28 threads total time was 61.74 s with FHE execution time at 11.33 s | – | Client Server equipped with Intel 8-cores i7-8770 CPU with RAM 16 GB, frequency 3.20 Ghz and cloud server with 28 virtual CPUs and Physical layer Memory of 256 Gb and 28 Intel Xeon model E52697-A v4 CPU with frequency 2.60 GHz, Ubuntu linux 18.04 OS used is n both setups | |||
| [ | Simulated dataset of 5000 patients | Identification of exceptional survivor and Identification of drug exposures | 1583.8 s with 256 bit security (exceptional survivor) and 56.8 s (drug exposure) | 0.8 s for both exceptional survivor and drug exposure | 2512.2 s (exceptional survivor) 5.3 s (drug exposure) for one patient | 25,120 s (exceptional survivor) and 42.4 s (drug exposure) for one patient | – | – |
Comparison of homomorphic encryption in healthcare based upon computation and communication overhead
| Paper | Base Approach | Type of HE | Computation overhead analysis | Communication overhead analysis | Overall analysis |
|---|---|---|---|---|---|
| [ | Gentry [ | Ideal Lattices | Requires an extra Recryption operation that requires 99.9 % of execution time | Nearly 4.8 GB of Storage Space is required for one hour patient encrypted ECG record. Communication cost increases due to storage overhead | In terms of computing and storage, it is inapplicable for a long-term monitoring system |
| [ | BGV [ | Leveled homomorphic using modulus switching (RLWE) | 24-hour Average heart rate of patient can be calculated in around 70 ms | Storage of 24 hrs patient records requires around 28 MB. Communication overhead is less comparison to Gentry FHE | In terms of computing and storage BGV scheme is acceptable as it requires very less storage and there is no recryption operation |
| [ | Stehle [ | NTRU and Leveled homomorphic using modulus switching (RLWE) | Computational Cost with Parameter set P1 ( to allow computation in logistic regression function) is 64 ms | Size of a single encrypted value using parameter P1 is 64 KB. Communication overhead is more | Although Communication overhead is more but still it is practical to implement this approach |
| [ | Stehle [ | NTRU and Leveled homomorphic using modulus switching (RLWE) | Computational Cost with Parameter set P2 ( to allow computation of Taylor Series up to degree 7) is more as 5 s of time is required in ciphertext multiplication and Taylor computation up to degree 7 requires more than 30 s | Size of one ciphertext grows to 1 MB. Communicational overhead is huge | Both Computational and Communicational cost is high due to huge size of ciphertext and multiplication operation cost |
| [ | BGV [ | leveled homomorphic using modulus switching (RLWE)and HElib library | When data is delivered one minute at a time, the computational cost is smaller. With an FHE level of 7, the computation time for one chunk is 3.9 s. FHE level 18 computations are slower with whole 24 h data, i.e. 2093 chunks | The cost of communication lowers as the degree of FHE increases, as seen by the fact that 24 h data requires 4.1 MB of findings to be sent to the doctor, but 1 min data requires 1296.1 MB | Despite the fact that performance is not up to par, healthcare organizations may use these services because many cloud service providers only charge for incoming data, i.e. sending encrypted results data back to the doctor will cost, but sending encrypted data to the cloud will not, and communication costs will be reduced as the level of FHE is increased |
| [ | [ | NTRU | An optimized NTRU based HE results with less noise and high speed using GPU implementation ( | Dividing the work among all four GPUs achieved a speedup of 3.946x, resulting into hiding almost all of the communication cost by splitting large problems into small ones | A huge speedup with less communication overhead is achieved. The results were compared with other RLWE and NTRU schemes |
| [ | Paillier[ | Partial homomorphic (Additive) | Average heart rate Computed using paillier Algorithm in which addition operation requires 0.11 ms and average heart rate for 24-hr data requires 9.7 s. While Encryption and Decryption operations were performed in 560 and 550 ms respectively | Ciphertext with 12,288 integers. Security parameter with 128-bit requires 3072-bit primes | Computation time of Paillier for Average heart rate detection is 3100 times faster then BGV but due to partial homomorphic property it is restricted only to addition operation. However, Encryption and Decryption time are slow in both the algorithms. Storage Requirement is 96 times more than AES algorithm |
| [ | BGV[ | Leveled homomorphic using modulus switching (RLWE) | For Average Heart Rate with 24 hr Monitor Interval, slots 2198 and level 31 Encryption and Decryption requires 1.8 and 0.85 s respectively with execution time of 502 min and LQTS detection with Slots 2093 and Level 18 requires 0.26 s for Encryption and 0.25 s for Decryption with execution time of 1165 min | For Average Heart Rate with 24 hr Monitor Level, slots 2198 and level 31. Size of ciphertext is 20.3 MB and for LQTS detection with same specification the size of ciphertext is 4.3 MB | Both LQTS and Average heart rate computation requires higher value of Level for longer ECG monitoring As a result it requires higher number of ciphertexts thereby requiring less network traffic for better communication |
| [ | Dowlin [ | Ring-Learning With Errors (RLWE) | In comparison to Kocabas [ | The communication cost of computing average heart rate is reduced since only one ciphertext is provided to the receiver, as opposed to two ciphertexts containing the cumulative total and number of samples in Kocabas approach [ | With security parameters ranging from 200 to 400, the implementation time for detecting long QT Syndrome has been significantly reduced. When computing average heart rate, the overhead of ciphertext is also decreased |
| [ | El Gamal [ | Discrete Logarithms | The computation load is linear since it employs the El Gamal partial homomorphic technique, which takes 13.77 ms to encrypt and 0.9 milliseconds to decrypt. With 0.004 ms, additional homomorphic aggregation is required for an aggregated Query | Communication overhead is 576 ms i.e the time for sending query and receiving encrypted results | Although the storage cost is higher, it is still feasible because the encrypted version is just 4x the size of the unencrypted version |
| [ | BGV[ | Leveled homomorphic using modulus switching (RLWE) | With 2079 slots/ciphertexts, the processing speed at Level 17 and 24 hr monitoring is 0.35, which is computed by dividing the time required to transfer data from the client to the backend by the time required to process the data at the backend. This demonstrates that the cost of computing is lower | The communication overhead for calculating Delayed Repolarization of Heart Syndrome diminishes as the level of granularity increases, requiring 1102 GB of data to be transferred for 1 mint monitoring and 9.6 GB for 24 hr monitoring | Healthcare organizations may use these services because many cloud service providers only charge for incoming data. For example, sending encrypted results data back to the doctor will cost, but sending encrypted data to the cloud will not, and communication costs will decrease as the granularity of FHE is increased |
| [ | Smart and Vercauteren [ | SIMD Style FHE | Without Threading with filtered database of 4911 total FHE execution time 195.82 sec and with Threading FHE execution time 11.33 sec | Without Threading communication time 43.18 sec and with threading communication time 50.17 sec | A very time efficient FHE query system. Communication cost is higher with or without threading but still practical |
| [ | Fan and Vercauteren[ | Lattice based leveled homomorphic (RLWE) | Computation time depends upon a threshold of survival duration. Computation time are longer compare to standard analysis | With increase in multiplicative depth. More communication cost is incurred | More computation time is required. In comparison to delays caused by a lack of learning from real-world events, computing time is insignificant. Patients and doctors will be more likely to engage in research if they know the data from their health records will never be decrypted, resulting in faster learning owing to improved statistical power |