Documentazione/documentazione.md

# Protocollo TCN

## Descrizione del protocollo

Il protocollo TCN, Temporary Contact Number, è un protocollo di tracciamento dei contatti decentralizzato, ideato dalla TCN Coalition. Quest'ultima è una comunità di persone che durante l'emergenza COVID-19 hanno sviluppato questo supporto per lo sviluppo di applicazioni per notificare l'esposizione al contagio. 
Il protocollo non richiede, informazioni personali ed è compatibile con autorità sanitarie.
I dispositivi degli utenti inviano un identificativo agli utenti vicini tramite Bluetooth e successivamente, se un utente è risultato positivo al contagio, può notificarlo ai suo contatti.  

Per aumentare la scalabilità la TCN Coalition ha scelto di non generare randomicamente tcn, ma di generarli in modo deterministico da un seed. 
In questo modo si riduce la dimensione del report da inviare, in quanto contiene solo le informazione necessarie per calcolare i tcn e non l'elenco intero di tcn. 
L'utente può caricare diversi report di dimensioni minori in modo da non caricare l'intera cronologia dei contatti. 

### Chiavi di autenticazione e verifica

L'user agent crea una chiave di autorizzazione *rak* (report authorization key) e una chiave di verifica *rvk* (report verification key).

A partire dalla rak è possibile ricavare la chiave di contatto iniziale tck_0. 

```
tck_0 ← H_tck(rak)
```

dove `H_tck` è una funzione di hash con 256 bit di output.

### Chiave temporanea di contatto

Ogni report può contenere al massimo $2^{16}$ chiavi di contatto.

Partendo un tcn se ne può derivare il prossimo tcn come mostrato di seguito:

```
tck_i ← H_tck(rvk || tck_{i-1})
```

dove `||`indica una concatenazione.

### Numeri temporanei di contatto

Per ogni tck viene generato un numero di contatto temporaneo come mostrato di seguito:

```
tcn_i ← H_tcn(le_u16(i) || tck_i)
```

dove `H_tcn` è una funzione di Hash con 128 bit di output.

Dalla chiave rak è possibile generare la chiave rvk e la chiave tck_0, dalle quali è possibile generare le successive tck e quindi tutti i successivi tcn. 

```
      ┌───┐
  ┌──▶│rvk│─────────┬──────────┬──────────┬──────────┬──────────┐
  │   └───┘         │          │          │          │          │
┌───┐       ┌─────┐ │  ┌─────┐ │  ┌─────┐ │          │  ┌─────┐ │
│rak│──────▶│tck_0│─┴─▶│tck_1│─┴─▶│tck_2│─┴─▶  ...  ─┴─▶│tck_n│─┴─▶...
└───┘       └─────┘    └─────┘    └─────┘               └─────┘
                          │          │                     │
                          ▼          ▼                     ▼
                       ┌─────┐    ┌─────┐               ┌─────┐
                       │tcn_1│    │tcn_2│      ...      │tcn_n│
                       └─────┘    └─────┘               └─────┘
```

### Report

Un utente che vuole caricare il proprio report del periodo compreso tra `j1` e `j2`, lo farà nel seguente modo:

```
report ← rvk || tck_{j1-1} || le_u16(j1) || le_u16(j2) || memo
```

dove `memo` è una stringa di byte di lunghezza variabile che va da 2 a 257 byte. 
Inoltre si utilizza il rak per produrre una firma`sig` per il report `report` e verrà mandata la concatenazione di `sig` || `report` al server.

Chiunque può verificare l'integrità della sorgente e ricavare il tcn tramite sig, report e rvk, per poi confrontare questo tcn ottenuto con le proprie osservazioni.

```
tck_j1 ← H_tck(rvk || tck_{j1-1})              # Ratchet
tcn_j1 ← H_tcn(le_u16(j1) || tck_{j1})         # Generate
tck_{j1+1} ← H_tck(rvk || tck_{j1})            # Ratchet
tcn_{j1+1} ← H_tcn(le_u16(j1+1) || tck_{j1+1}) # Generate
...
```

**non so se mettere o no questa parte di codice**

Si noti che il tcn deriva dal `tck_1{j1-1}`che non è incluso nel report, perchè il destinatario non può verificare se è associato al rvk. 
Se la verifica del client non è importante, il server, in modo arbitrario, può rmuover i 64 byte finali da ciascun report.










## Implementazione del protocollo per la JMV

# Applicazione

## Bluetooth

### Trasmissione

### Scansione

### Stima della distanza

## UI

## Memorizzazione

## Rete