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

Quando viene richiesto di caricare i dati dell'utente, è possibile eseguire l'upload di un report compatto. Infatti grazie alla derivazione deterministica, è possibile inviare tutti gli identificativi utilizzati nel periodo `j1` e `j2`, caricando unicamente la rvk, tck_{j-1}, e i due indici `j1` e `j2`. Di seguito è illustrato come costruire il report: 

```
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 e verrà inviata al server la concatenazione di sig e report.

Poichè la rvk è contenuta all'interno del report, chiunque può verificare l'integrità del report e ricavare i vari. 



## Implementazione del protocollo per la JMV

# Applicazione

## Bluetooth

### Trasmissione

### Scansione

### Stima della distanza

## UI

## Memorizzazione

## Rete