Mise à jour terminée. Pour connaître les apports de la version 13.8.4 par rapport à notre ancienne version vous pouvez lire les "Release Notes" suivantes :

robertImplementationModalities.txt 4.5 KB
Newer Older
1 2
Implementation modalities -- Change Log

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
* Concerning section 3.1 on Server Set Up

When the server is initialized, we assume that it is configured with KS (“Server Key”): a L-bit long key, L >= 128, only known by the server. The server key K_S is  used by backend server to generate EBIDs, stored by the server. 

As mentioned in the footnote (5) in [1] : this key can be renewed every few epochs for better security. In this case, the server needs to store all the keys that were generated during the last CTK epochs, where CTK = 86400 * CT/epoch_duration_sec

We do implement the K_S key rotation

If an app runs out of EBIDs that are less than 14 days old, it will never be able to communicate with the back-end. The mobile app must detect this case and propose to "recreate/reactivate" an account.

We must be able to generate K_S for the last 14 days + today + the next X-1 days where X is the number of days for which we send EBID batches to the apps (e.g. X=4 so 3 K_S keys of the future)

- The mobile app must provide a new parameter in addition to (EBID, time, MAC) currently: epochId and the MAC must now cover (EBID, epochId, time). This epochid allows to find the right K_S key:
- epochId == first epochID of the day AND (timestamp % epoch_duration < 3) then test with key K_S of the day before
- epochId == last epochID of the day  AND (timestamp % epoch_duration > epoch_duration - 3) then test with key K_S of the next day

20 21 22 23 24 25 26

* Concerning section 4 on Generation of the Ephemeral Bluetooth Identifiers of [1]
Change in the implementation:
For the EBIDA,i (”Ephemeral Bluetooth IDentifier for A”), the 64-bit identifier generated for the epoch i as: EBIDA,i = ENC(KS,i | IDA)
where ENC is a block-cipher with 64-bit block size. The choice made is skinny-cipher64 instead of 3-key TripleDES.

27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
In order reinforce the blindness of the front end, we implement an Over-encryption of the EBIDs generated by the backend and sent to the App. In other words, the front end is "blind" to all data exchanges concerning the EBIDs. 
The protocol is the following :  
1. Generation of a static crypto back-end key pair. 
2. The public part of this key is embedded in the mobile apps.
3. The mobile app generates a key pair when it starts up.
4. It will send the public key in the /register
5. It uses the private part to combine with the public key back-end crypto to get the shared secret.
6. It then derives with an HMAC-SHA256 and a predefined string (known by the server and the app, e.g. "ka") the key K_A (used to generate the MACs of the /status, /unregister and /deleteExposureHistory calls)
7. It derives with a HMAC-SHA256 and a predefined string (known by the server and the app, e.g. "ebid") the key K_E_A which will be used to decipher the tuples batches (epoch_id, EBID, ECC) returned by the backend.
8. It stores K_A and K_E_A in a secure storage (keychain)
9. The backend doesn't send its public keys, they are already embedded in the apps.

When receiving a /register call, the crypto backend uses the public client key and its private static crypto backend key to obtain the shared secret and derive K_A and K_E_A
The crypto back-end uses K_E_A to encrypt the tuples (epochid, EBID, ECC)
K_A is only used to decrypt the different MACs received from the client.

45 46 47 48 49 50 51 52 53 54 55 56
* Concerning section 6.1 on the Upload Mechanism of [1]
Current version:
The LocalProximityList and the token given as a proof of the diagnostic, is upload in one upload/batch to the server. In order to guard against the possibility of reconstruction of the social graph, as specified in the security recommandation [2] provided by ANSSI, we have set up :
	* a reverse proxy for all the APIs;
	* a strict segmentation of the backend into several zones.  (Ref 2 in [2])
	* a strict clean of meta-data (IP address, port, authentification token) in the frontend of the server. (Ref 4 in [2])
TODO: implement a multiplexing queue with random delays in order to mix the treatment of LocalProximityList elements.

* Concerning section 7 on the Exposure Status Request (ESR) of [1]
Change in the implementation. 
A application that receive a positive result after an ESR, will continue to do ESR, once a day. The EBIDs that where used in the computation of the risk received will not be take into consideration in oncoming ESRs. The privacy impact is the same as stopping to do ESR ans uninstalling/reinstalling an App.

57 58

[1] ROBERT: ROBust and privacy-presERving proximity Tracing, PRIVATICS team, Inria, France Fraunhofer AISEC, Germany April 19, 2020 v1.0
[2] Recommandations de l'ANSSI pour la sécurisation de StopCovid