Skip to content
Patrick Jattke edited this page Aug 6, 2020 · 13 revisions

Task

The cardio benchmark is based on a medical diagnostic algorithm that was presented by Carpov et al. in Practical privacy-preserving medical diagnosis using homomorphic encryption as demonstration for a cloud-based and privacy-preserving cardiac risk factor assessment service. The algorithm is used by Cingulata as an example/test application.

The cardio program has in total 7 encrypted inputs. The inputs of the program are:

  • sex (1 bit): female (false) or male (true)
  • antecedents (1 bit): true if there was a cardiology disease in the family history, otherwise false
  • smoker (1 bit): no (false) or yes (true)
  • diabetes (1 bit): no (false) or yes (true)
  • high_blood_pressure (1 bit): high blood pressure (true) or normal blood pressure (false)
  • age (8 bit): the age in years
  • hdl_cholesterol (8 bit): the HDL cholesterol level
  • height (8 bit): height in centimeters
  • weight (8 bit): weight in kilograms
  • phy_activity (8 bit): physical activity in minutes per day
  • drinking_habits (8 bit): number of glasses of alcoholic beverages per day

The cardio program uses trans-ciphering that allows to switch from some data encrypted under a classic overhead-free symmetric cryptosystem to the same data encrypted under FHE, without exposing the data in clear text at any time. For that, the program uses the stream cipher Kreyvium, a 128-bit version of the Trivium algorithm that allows efficient FHE execution by only involving XOR operations.

The inputs are encrypted on the client-side using a key-stream generated by the Kreyvium cipher with the private key SYMSK and an initialization value IV. In our benchmark program, we use a precomputed keystream (like in the Cingulata test program). The encryption is a simple XOR operation and as such can be performed efficiently on a device with low resources. On the server-side, the Kreyvium algorithm is executed homomorphically using the FHE-encrypted private key [SYMSK]FHE with the same IV to ensure that client and server use the same key-stream. This process is called key-stream mining and takes places in advance to minimize latency. After receiving the data from the client and homomorphically executing the Kreyvium algorithm on the server, which basically consists of simple XOR operations, the data is encrypted under FHE and can be processed further. This transciphering procedure is depicted in Figure 1.

Figure 1: The computation workflow of the cardio program using transciphering and FHE. Image taken from Carpov et al.

The main part is the homomorphic execution of the cardiac risk factor assessment algorithm. This consists of a set of rules that are given in Listing 1. These rules compute a score between 0 and 9 where a larger value means a higher risk for a cardiology disease.

+1  if man and age > 50 years
+1  if cardiology disease in family history
+1  if smoking
+1  if diabetic
+1  if high blood pressure
+1  if HDL cholesterol less than 40
+1  if weight > height-90
+1  if daily physical activity less than 30 minutes
+1  if man and alcohol consumption more than 3 glasses/day
+1  if woman and alcohol consumption more than 2 glasses/day

Listing 1: Rules of the cardiac risk factor assessment algorithm.

Implementation in Tools

Cingulata

The implementation in Cingulata uses an illegal transformation of the initial rule that is described in the paper (Practical privacy-preserving medical diagnosis using homomorphic encryption):

Original rule:
+1 if weight > height-90

Cingulata's Cardio implementation:
+1 if height+10 < weight

Also, the addition (+10) did not work properly as 10 must be declared as a CiInt to make use of the overloaded addition. The error was fixed by changing the rule to +1 if height < (weight+90) and declaring 90 as CiInt. This change is also considered in the implementation of cardio in all other tools.

Cingulata encodes the inputs as 7*8 bit = 56 bits. The 1-bit flags (sex, antecedents, smoker, diabetes, and high_blood_pressure) are encoded in a single 8-bit ciphertext.

SEAL-BFV

SEAL does not provide a native support for binary data and computation. Binary support was emulated by choosing the plaintext poly modulus degree 2 and implementing binary circuits for the following arithmetic functions manually:

  • Addition (Sklansky adder by Harris)
  • Lower operator (Logarithmic depth lower comparator by Garay et al.)

Each bit is represented by a single ciphertext. Eight ciphertexts are united into a vector (std::vector<seal::Ciphertext>) to represent each cardio input in a 8-bit binary representation. This bit vector is also the input type for the manually implemented arithmetic functions, however, these functions itself work on the bit-/ciphertext-level by using the arithmetic functions provided by SEAL (addition, multiplication).

The cardiac risk factor assessment algorithm is implemented based on the Cingulata implementation. The only deviation from that is that involved constants (e.g., 50 in man && age > 50) are also encrypted, i.e., represented as vector consisting of seal::Ciphertexts. This is made to facilitate the implementation as otherwise some changes in the manually implemented arithmetic circuits would be required, e.g., we need to use special SEAL operations that accept a seal::Plaintext as argument.

SEAL-BFV-SIMD

For implementing cardio using batching in SEAL-BFV, we reformulate the conditions to have a unified structure:

+1  if man                                  && 50 < age
+1  if cardiology disease in family history && 0 < 1
+1  if smoking                              && 0 < 1
+1  if diabetic                             && 0 < 1
+1  if high blood pressure                  && 0 < 1 
+1  if TRUE                                 && HDL < 40 
+1  if TRUE                                 && height < weight+90
+1  if TRUE                                 && phy_act < 30
+1  if man                                  && 3 < alc_consumption
+1  if (!man)                               && 2 < alc_consumption
Clone this wiki locally