Format Preserving Encryption (FPE)

In cryptography, format-preserving encryption (FPE), refers to encrypting in such a way that the output (the ciphertext) is in the same format as the input (the plaintext).

The meaning of "format" varies. Typically only finite domains are discussed, for example:

To encrypt a 16-digit credit card number so that the ciphertext is another 16-digit number.
To encrypt an English word so that the ciphertext is another English word.
To encrypt an n-bit number so that the ciphertext is another n-bit number (this is the definition of an n-bit block cipher). Example below shows comparing between FPE and AES on the same plaintext input.

In CareBud application when we come to term of encryption in client side many questions come to our mind, can user’s device handle the encryption and decryption process in matter of speed or time related issues. After testing in client side for multiple size of data we can encrypt about 4MB of data in around 7.88 Millisecond and store it in the cloud database.

When user start using these strategies, his or her data will never be exposed to the DAS service providers and all encryption and decryption process will be done in the client device. CareBud 46 project is an example for implementing our methodologies (Key management, ACL and Encryption) and this scenario includes three user categories (Patient, Doctor and Relative).

In the diagram above P1 is a patient who is trying to access or signup with his details which are provided in plaintext. The first thing a key will be generated (k1) along with that process and any information for the (P1) will be encrypted using (k1) and the encrypted data will be transferred to the cloud (DAS) using Representational State Transfer RESTful APIs or HTTP requests. Same case when user queries about any data in the cloud, it will be queried using document ID which will not be relevant or referred to any specific information or user-related data.

When patient start to submit his data, the encryption process will start using Format-Preserving Encryption algorithm which is only one use of tweakable block ciphers. Because tweakable block ciphers are so much more powerful than (regular) block ciphers. We are using FF1 with this method:

Ciphertext = Fpe.encrypte(encryptionPattern, message , encryptionkey)

Encryption pattern or domain represents the easiest implementation of a domain. A valid pattern should be able to transform text input into a numeric or alphabet string and alphabet or numeral string to text.

The pattern of an instance has three elements:

Alphabet: A subset of characters that are valid to create a text input for an instance and this is include Upper-Case and Lower-Case letters of English alphabet.
Numbers: A subset of numbers that are valid to create a numeric input for an instance which defined from (0-9).
Symbols: set of symbols that can be used in the text input defined as (\s!@#$%\/^&-*+_=]) it’s related to user password encryption.
Transformers: Functions (Class) that are able to transform text to numeral string or numeral string to text.

The default pattern (Domain) is specified as follow:

FPE_TWIC_Pattern = (/^[a-zA-Z0-9\s!@#$%\/^&-*)(+=._]*$/);

Message is the input data given by the (P1) it’s plaintext message or inputs include characters, numbers and symbols.

message= (“message/ any text”);

Encryption Key is key generated by the user himself, when the user creates his account using a compensation between the username and the user password, which will be generated each the user access his account and it will be never stored neither cloud backend nor local device or local storage. It’s can be done using the following method:

username = loginAuth.username;
userPassword = loginAuth.userPassword;
encryptionKey = generateKey(username , userPassword);

Three aspects will be as input to the encryption algorithm and it will return an encrypted text. Few things I were worried about when it comes to the idea which is in the encrypted data the size will be increased regarding the encryption key.

Plaintext = Fpe.decrypt (encryptionPattern, Ciphertext, encryptionkey)

Whatever the data size it is the encrypted data it will be expanded and the processing time will be too much and those things it’s a challenge for me to be managed as well as the number of keys will increase along with controlling the resources in the client side, but after I did tests experiments with the help of some algorithms I successfully managed the encrypted data size and the processing time, for example, the above process (F 15) the patient data size is 1kb:

Input data is = 1kb (Plaintext) => Output data = 1kb (Encrypted text)

The Processing time for encrypting and decrypting P1 data is around (0.617 Milliseconds), I also I have test it on different data size like 1.18KB, 1.15MB, 2.3MB and 3.10MBFile size, which that include reading from Iot device in our case is the smart watch, storing in the database, time for make a query and search information and the total time for transferring data back to the user. The below charts and tables show the results (In Seconds):

Data in diff sizes

Reading from IoT device(ms)

Encryption time (ms)

Store db time(ms)

Total time for storing the database (ms)

Total search from data base(ms

Decryption time

Send data in user time(ms)

18,944 bytes

1,214,976 bytes

33310

25599

9250

42560

14699

2210

25361

2,678,784 bytes

66391

63136

29449

125840

43471

17794

71653

3,108,155 bytes

115650

86135

38699

158400

58170

19304

97014

Input Size

18,944 bytes

1,214,976 bytes

2,678,784 bytes

3,108,155 bytes

Total time for plain text

82620

240964

303584

Total time for cipher text

110429

321894

532858

In our case CareBud application, when P1 starts to signUp, at that time all data entered will be encrypted using an encryption handler then it will call an API method (_userSignUp()) to store that encrypted data in the CareBud cloud backend using post request. From that data, we classify the user type, depending in that we navigate to the next process. Following a sequence diagram shows the communication between CareBud app and its backend, when the patient starts to signUp:

Like the sequence diagram above the user type is Patient (P1), after getting a response (success 200) from the cloud backend, it will trigger a request to the virtual SmartWatch to do a health report scanning for P1 and send it back to CareBud App. The App will encrypt P1 health report along with any reports entered manually then it will be posted to the cloud as encrypted data records.

Every ten seconds the virtual smartwatch will scan patient health status then it will be reported to CareBud App, that data will be matched with the previous health reports, if no match has accrued then Api method from ReportHandler called (creatingPatientHealthReportHistory) will be fired and it will store the previous health reports in encrypted format in the cloud. When the app gets successful response, it will take the new health report and doing an encrypted process then store it back in the cloud as well.

Same process here on Figure 18, when patient needs to access his account he should provide username and passwords, in order to verify that account an API method called (_signIn) in Signin handler in where username will be used to get that response account details which will be in encrypted format, that response will be decrypted to be matched with the details entered by (P1).

The generated key will be used in the entire process for encrypting and decryption user data. Same process includes all entities used in this project. Few questions cross our minds is how the user will interact with each other? Is there cross point between them? How the encryption and decryption process for shared user data? Is there rules and boundaries need to be controlled in the system? Are there parts in the system need strong privileges? That’s will be explained more in the next sections.

PreviousNode.Js NextUser management and Crypto Key Management

Last updated 6 years ago

Was this helpful?