Newer
Older
# ICNML web application
This repository contains the web app at the core of the plateform.
It contains the python code to run the web interface, file processing and external libs serving (CDN).
The other libs mendatory for this application to run (NIST, MDmisc, PMlib, PiAnoS and WSQ) are located in the docker repository (https://esc-md-git.unil.ch/ICNML/docker).
This repository can not (and is not indended) to be run as-is since the mendatory libraries are not located here.
For developpement, install those libraries separatly in your dev enviroment.
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
# Encrpytion keys and Hashing functions
All the data that is "encrypted" is encrypted with AES256. The passed in parameter is hashed with a SHA256 function to uniformize the enryption key ("key"). The initialization vector are always set to a random value (with the Crypto library), every time a value is encrypted. The encryption function as noted as follow:
AES( data, key )
The hashing process is done with a key derivation function, in particular PBKDF2 with a SHA512 hashing function. The data and the salt are described as needed. The function is as follow:
PBKDF2( data, salt, iterations )
If the number of iterations is not indicated, the default value is 20'000.
# Login
## Password
The login process is done in multiple steps. First, the password is hashed as follow on the cilent side (HPWCS - Hashed Password Client Side):
HPWCS = PBDKF2( password, "icnml_" + username, 20'000 )
This hash is done to not transmit the user password in clear to the server (avoiding a memory dump or any stealing of the password). This hasing is done on the client-side, 20'000 iterations for performance issues.
This hashed password is hashed a second time on the server side as follow (HPWCSSS):
HPWCSSS = PBDKF2( HPWCS, random_data( 65 ), 50'000 )
This hash is one with some random data as salt, and with more iterations (more performances possible on the server). This second step is done because the user input can never be trusted (computer basic rule) and to be able to change the security of the stored hashed (the number of iterations can be changed as needed on the client side without impacting the performance on the client-side.
This final hash is stored in the database and used to login the users.
## Client-Side Key
While logging-in, a secondary key is derived from the password as follow:
CSK = PBDKF2( password, "icnml_" + username + "_localpassword", 50'000 )
This key never leave the browser of the user. This key is used as encryption key for the client-side encrypted data. This key is stored in the browser with a session encryption key manadged by the server.
## Second factor
One second factor is mendatory for all accounts. For non-admin account, a Time Based One Time Password (TOTP) is sufficient. For the admin accounts, a physical security key (yubikey) is mendatory.
# Data encryption workflow
All the data is protected by differents solutions, according to the type of data and usage. The submission process contains multiple fields.
## Nickname
The "nickname" is a field used by the submitter to identifiy the donor. This field is encrypted on the client-side with AES with the CSK as encryption key.
## Email
The "donor email" address is encrypted with AES (CSK key) on the client side (to be able to show it to the submitter while updating the upload data).
On the creation of the upload process, the email is sended to the server in clear (to be able to send the email to the donor), and hashed directly on the server side (PBKDF2 with 100 character of random data and 50'000 iterations of SHA512).
## Data Encryption Key (DEK)
When a new donor is created, a Data Encryption Key (DEK) is created to encrypt all images. The DEK is generated as follow:
DEK = PBDKF2( username + ":" + email, random_data( 100 ), 500'000 )
This key is used as AES encryption key for all the images and donor related informations. The derivarion of this key is done based upon the username and the email address of the donor. Those informations are only known by the submitter and the donor for the email and only by the donor and the server for the donor username. This key can not be reconstructed only by the server operator.
To delete his informations, the donor will only delete the DEK, hence removing any possibility to get the images from the live database AND ALL the backups. The submitter will have the possibility to see the images but is not a problem because his has access to the original images anyway. This feature is done to protect the privacy of the donor : the submitter can not know if the data of the donor is still available or not because he will see his submission as usual, even if the data is not decryptable for the users.