9. Protezione di CoAP

Questa sezione definisce il binding DTLS per CoAP.

Durante la fase di provisioning, a un dispositivo CoAP vengono fornite le informazioni di sicurezza di cui necessita, inclusi materiale di chiave e liste di controllo degli accessi. Questa specifica definisce il provisioning per la modalità RawPublicKey nella Sezione 9.1.3.2.1. Al termine della fase di provisioning, il dispositivo si troverà in una delle quattro modalità di sicurezza con le seguenti informazioni per la modalità considerata. Le modalità NoSec e RawPublicKey sono obbligatorie da implementare per questa specifica.

NoSec: Non esiste sicurezza a livello di protocollo (DTLS è disabilitato). Tecniche alternative per fornire sicurezza a livello inferiore DOVREBBERO essere utilizzate quando appropriato. L'uso di IPsec è discusso in [IPsec-CoAP]. Alcuni livelli di collegamento utilizzati con nodi vincolati forniscono anche sicurezza a livello di collegamento, che può essere appropriata con un'adeguata gestione delle chiavi.

PreSharedKey: DTLS è abilitato, esiste un elenco di chiavi pre-condivise [RFC4279], e ogni chiave include un elenco dei nodi con cui può essere utilizzata per comunicare, come descritto nella Sezione 9.1.3.1. All'estremo, può esserci una chiave per ogni nodo con cui questo nodo CoAP deve comunicare (rapporto nodo/chiave di 1:1). Al contrario, se più di due entità condividono una specifica chiave pre-condivisa, questa chiave consente alle entità di autenticarsi solo come membro di quel gruppo e non come peer specifico.

RawPublicKey: DTLS è abilitato e il dispositivo dispone di una coppia di chiavi asimmetriche senza certificato (una chiave pubblica grezza) che viene validata utilizzando un meccanismo fuori banda [RFC7250], come descritto nella Sezione 9.1.3.2. Il dispositivo dispone inoltre di un'identità calcolata dalla chiave pubblica e di un elenco di identità dei nodi con cui può comunicare.

Certificate: DTLS è abilitato e il dispositivo dispone di una coppia di chiavi asimmetriche con un certificato X.509 [RFC5280] che lo lega al suo subject ed è firmato da una radice di fiducia comune, come descritto nella Sezione 9.1.3.3. Il dispositivo dispone inoltre di un elenco di anchor di fiducia radice che possono essere utilizzati per validare un certificato.

Nella modalità "NoSec", il sistema invia semplicemente i pacchetti su normale UDP su IP, ed è indicato dallo schema "coap" e dalla porta predefinita CoAP. Il sistema è protetto solo impedendo agli attaccanti di poter inviare o ricevere pacchetti dalla rete con i nodi CoAP; vedere la Sezione 11.5 per un'ulteriore complicazione con questo approccio.

Le altre tre modalità di sicurezza sono ottenute utilizzando DTLS e sono indicate dallo schema "coaps" e dalla porta predefinita CoAP protetta da DTLS. Il risultato è un'associazione di sicurezza che può essere utilizzata per autenticare (entro i limiti del modello di sicurezza) e, sulla base di questa autenticazione, autorizzare il partner di comunicazione. CoAP stesso non fornisce primitive di protocollo per l'autenticazione o l'autorizzazione; ove ciò sia richiesto, può essere fornito dalla sicurezza di comunicazione (cioè IPsec o DTLS) oppure dalla sicurezza dell'oggetto (all'interno del payload). Si prevede che i dispositivi che richiedono l'autorizzazione per determinate operazioni richiedano una di queste due forme di sicurezza. Necessariamente, quando è coinvolto un intermediario, la sicurezza di comunicazione funziona solo quando tale intermediario fa parte delle relazioni di fiducia. CoAP non fornisce un modo per inoltrare a ulteriori intermediari o server di origine i diversi livelli di autorizzazione che i client possono avere con un intermediario -- pertanto può essere necessario eseguire tutta l'autorizzazione presso il primo intermediario.

9.1. CoAP protetto da DTLS

Proprio come HTTP è protetto utilizzando Transport Layer Security (TLS) su TCP, CoAP è protetto utilizzando Datagram TLS (DTLS) [RFC6347] su UDP (vedere la Figura 13). Questa sezione definisce il binding di CoAP a DTLS, insieme alle configurazioni minime obbligatorie da implementare appropriate per ambienti vincolati. Il binding è definito da una serie di delta rispetto al CoAP unicast. In pratica, DTLS è TLS con funzionalità aggiunte per gestire la natura inaffidabile del trasporto UDP.

+----------------------+
|      Application     |
+----------------------+
+----------------------+
|  Requests/Responses  |
|----------------------|  CoAP
|       Messages       |
+----------------------+
+----------------------+
|         DTLS         |
+----------------------+
+----------------------+
|          UDP         |
+----------------------+

Figura 13: Stratificazione astratta di CoAP protetto da DTLS

In alcuni nodi vincolati (flash e/o RAM limitati) e reti (larghezza di banda limitata o elevati requisiti di scalabilità), e a seconda delle specifiche suite di cifratura in uso, non tutte le modalità di DTLS possono essere applicabili. Alcune suite di cifratura DTLS possono aggiungere una significativa complessità implementativa nonché un certo overhead di handshake iniziale necessario per impostare l'associazione di sicurezza. Una volta completato l'handshake iniziale, DTLS aggiunge un overhead limitato per datagramma di circa 13 byte, senza includere eventuali vettori di inizializzazione/nonce (ad esempio 8 byte con TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), valori di controllo dell'integrità (ad esempio 8 byte con TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]) e il padding richiesto dalla suite di cifratura. Se l'uso di una determinata modalità di DTLS sia applicabile per un'applicazione basata su CoAP dovrebbe essere valutato attentamente considerando le specifiche suite di cifratura che possono essere applicabili, se la manutenzione della sessione la rende compatibile con i flussi applicativi e se sono disponibili risorse sufficienti sui nodi vincolati e per l'overhead di rete aggiuntivo. (Per alcune modalità di utilizzo di DTLS, questa specifica identifica una suite di cifratura obbligatoria da implementare. Si tratta di un requisito implementativo per massimizzare l'interoperabilità nei casi in cui tali suite di cifratura siano effettivamente appropriate. Le specifiche politiche di sicurezza di un'applicazione possono determinare l'insieme effettivo di suite di cifratura utilizzabili.) DTLS non è applicabile alla gestione delle chiavi di gruppo (comunicazione multicast); tuttavia può essere un componente di un futuro protocollo di gestione delle chiavi di gruppo.

9.1.1. Livello di messaggistica

L'endpoint che agisce come client CoAP dovrebbe agire anche come client DTLS. Dovrebbe avviare una sessione verso il server sulla porta appropriata. Una volta terminato l'handshake DTLS, il client può avviare la prima richiesta CoAP. Tutti i messaggi CoAP DEVONO essere inviati come "application data" DTLS.

Le seguenti regole vengono aggiunte per far corrispondere un messaggio Acknowledgement o un messaggio Reset a un messaggio Confirmable, o un messaggio Reset a un messaggio Non-confirmable: la sessione DTLS DEVE essere la stessa, e l'epoca DEVE essere la stessa.

Un messaggio è lo stesso quando viene inviato all'interno della stessa sessione DTLS e della stessa epoca e ha lo stesso Message ID.

Nota: Quando un messaggio Confirmable viene ritrasmesso, per ogni tentativo viene utilizzato un nuovo sequence_number DTLS, anche se il Message ID CoAP rimane lo stesso. Pertanto un destinatario deve comunque eseguire la deduplicazione come descritto nella Sezione 4.5. Le ritrasmissioni NON DEVONO essere eseguite attraverso le epoche.

Le connessioni DTLS nelle modalità RawPublicKey e Certificate vengono impostate utilizzando l'autenticazione reciproca, così possono rimanere attive ed essere riutilizzate per futuri scambi di messaggi in entrambe le direzioni. I dispositivi possono chiudere una connessione DTLS quando hanno bisogno di recuperare risorse, ma in generale dovrebbero mantenere la connessione attiva il più a lungo possibile. Chiudere la connessione DTLS dopo ogni scambio di messaggi CoAP è molto inefficiente.

9.1.2. Livello richiesta/risposta

Le seguenti regole vengono aggiunte per far corrispondere una risposta a una richiesta: la sessione DTLS DEVE essere la stessa, e l'epoca DEVE essere la stessa.

Ciò significa che la risposta a una richiesta protetta da DTLS DEVE sempre essere protetta da DTLS utilizzando la stessa sessione di sicurezza e la stessa epoca. Qualsiasi tentativo di fornire una risposta NoSec a una richiesta DTLS semplicemente non corrisponde alla richiesta e pertanto DEVE essere rifiutato (a meno che non corrisponda a una richiesta NoSec non correlata).

9.1.3. Identità dell'endpoint

I dispositivi DOVREBBERO supportare la Server Name Indication (SNI) per indicare la propria authority nel campo SNI HostName, come definito nella Sezione 3 di [RFC6066]. Ciò è necessario affinché, quando un host che agisce come server virtuale per più authority riceve una nuova connessione DTLS, sappia quali chiavi utilizzare per la sessione DTLS.

9.1.3.1. Chiavi pre-condivise

Quando si stabilisce una connessione verso un nuovo nodo, il sistema seleziona una chiave appropriata in base ai nodi che sta cercando di raggiungere e quindi stabilisce una sessione DTLS utilizzando una modalità PSK (Pre-Shared Key) di DTLS. Le implementazioni in queste modalità DEVONO supportare la suite di cifratura obbligatoria da implementare TLS_PSK_WITH_AES_128_CCM_8 come specificato in [RFC6655].

A seconda del modello di messa in servizio, le applicazioni potrebbero dover definire un profilo applicativo per gli hint di identità (come richiesto e dettagliato nella Sezione 5.2 di [RFC4279]) per consentire l'uso degli hint di identità PSK.

Si applicano le considerazioni di sicurezza della Sezione 7 di [RFC4279]. In particolare, le applicazioni dovrebbero valutare attentamente se necessitano o meno della Perfect Forward Secrecy (PFS) e selezionare una suite di cifratura appropriata (Sezione 7.1 di [RFC4279]). L'entropia della PSK deve essere sufficiente a mitigare gli attacchi di forza bruta e (quando la PSK non è scelta casualmente ma da un essere umano) gli attacchi a dizionario (Sezione 7.2 di [RFC4279]). La comunicazione in chiaro delle identità dei client può divulgare dati o compromettere la privacy (Sezione 7.3 di [RFC4279]).

9.1.3.2. Certificati di chiave pubblica grezza

In questa modalità, il dispositivo dispone di una coppia di chiavi asimmetriche ma senza certificato X.509 (chiamata chiave pubblica grezza); ad esempio, la coppia di chiavi asimmetriche è generata dal produttore e installata sul dispositivo (vedere anche la Sezione 11.6). Un dispositivo PUÒ essere configurato con più chiavi pubbliche grezze. Il tipo e la lunghezza della chiave pubblica grezza dipendono dalla suite di cifratura utilizzata. Le implementazioni in modalità RawPublicKey DEVONO supportare la suite di cifratura obbligatoria da implementare TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 come specificato in [RFC7251], [RFC5246] e [RFC4492]. La chiave utilizzata DEVE essere compatibile ECDSA. La curva secp256r1 DEVE essere supportata [RFC4492]; questa curva è equivalente alla curva NIST P-256. L'algoritmo di hash è SHA-256. Le implementazioni DEVONO utilizzare le estensioni Supported Elliptic Curves e Supported Point Formats [RFC4492]; il formato di punto non compresso DEVE essere supportato; [RFC6090] può essere utilizzato come metodo di implementazione. Alcune indicazioni rilevanti per l'implementazione di questa suite di cifratura si trovano in [W3CXMLSEC]. Il meccanismo per l'utilizzo di chiavi pubbliche grezze con TLS è specificato in [RFC7250].

Nota implementativa: Nello specifico, ciò significa che le estensioni elencate nella Figura 14 con almeno i valori elencati saranno presenti nell'handshake DTLS.

   Extension: elliptic_curves
    Type: elliptic_curves (0x000a)
    Length: 4
    Elliptic Curves Length: 2
    Elliptic curves (1 curve)
      Elliptic curve: secp256r1 (0x0017)

   Extension: ec_point_formats
    Type: ec_point_formats (0x000b)
    Length: 2
    EC point formats Length: 1
    Elliptic curves point formats (1)
      EC point format: uncompressed (0)

   Extension: signature_algorithms
    Type: signature_algorithms (0x000d)
    Length: 4
    Data (4 bytes): 00 02 04 03
      HashAlgorithm: sha256 (4)
      SignatureAlgorithm: ecdsa (3)

Figura 14: Estensioni DTLS presenti per TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8

9.1.3.2.1. Provisioning

La modalità RawPublicKey è stata progettata per essere facilmente sottoposta a provisioning nelle distribuzioni M2M. Si presume che ogni dispositivo abbia installata un'appropriata coppia di chiavi pubbliche asimmetriche. Un identificatore viene calcolato dall'endpoint dalla chiave pubblica come descritto nella Sezione 2 di [RFC6920]. Tutte le implementazioni che supportano la verifica delle identità RawPublicKey DEVONO supportare almeno la modalità sha-256-120 (SHA-256 troncato a 120 bit). Le implementazioni DOVREBBERO anche supportare identificatori di lunghezza maggiore e POSSONO supportare lunghezze minori. Si noti che le lunghezze minori forniscono meno sicurezza contro gli attacchi e il loro uso NON È RACCOMANDATO.

A seconda di come gli identificatori vengono forniti al sistema che li verifica, deve essere implementato il supporto per il formato URI, binario e/o leggibile dall'uomo [RFC6920]. Tutte le implementazioni DOVREBBERO supportare la modalità binaria, e le implementazioni che dispongono di un'interfaccia utente DOVREBBERO supportare anche il formato leggibile dall'uomo.

Durante il provisioning, l'identificatore di ciascun nodo viene raccolto, ad esempio leggendo un codice a barre sull'esterno del dispositivo o ottenendo un elenco precompilato degli identificatori. Questi identificatori vengono quindi installati nell'endpoint corrispondente, ad esempio un server di raccolta dati M2M. L'identificatore viene utilizzato per due scopi: associare l'endpoint a ulteriori informazioni sul dispositivo ed eseguire il controllo degli accessi. Durante il provisioning (iniziale e continuativo), DOVREBBE anche essere installata e mantenuta una lista di controllo degli accessi degli identificatori con cui il dispositivo può avviare sessioni DTLS.

9.1.3.3. Certificati X.509

Le implementazioni in modalità Certificate DEVONO supportare la suite di cifratura obbligatoria da implementare TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 come specificato in [RFC7251], [RFC5246] e [RFC4492]. Vale a dire, il certificato include un SubjectPublicKeyInfo che indica un algoritmo id-ecPublicKey con namedCurves secp256r1 [RFC5480]; il formato della chiave pubblica è non compresso [RFC5480]; l'algoritmo di hash è SHA-256; se inclusa, l'estensione key usage indica digitalSignature. I certificati DEVONO essere firmati con ECDSA utilizzando secp256r1, e la firma DEVE utilizzare SHA-256. La chiave utilizzata DEVE essere compatibile ECDSA. La curva secp256r1 DEVE essere supportata [RFC4492]; questa curva è equivalente alla curva NIST P-256. L'algoritmo di hash è SHA-256. Le implementazioni DEVONO utilizzare le estensioni Supported Elliptic Curves e Supported Point Formats [RFC4492]; il formato di punto non compresso DEVE essere supportato; [RFC6090] può essere utilizzato come metodo di implementazione.

Il subject nel certificato sarebbe costruito a partire da un identificatore univoco a lungo termine per il dispositivo, come l'EUI-64 [EUI64]. Il subject potrebbe anche essere basato sul Fully Qualified Domain Name (FQDN) utilizzato come parte Host dell'URI CoAP. Tuttavia, l'indirizzo IP del dispositivo non dovrebbe tipicamente essere utilizzato come subject, poiché cambierebbe nel tempo. Il processo di discovery utilizzato nel sistema costruirebbe la mappatura tra gli indirizzi IP dei dispositivi considerati e il subject di ciascun dispositivo. Alcuni dispositivi potrebbero avere più di un subject e avrebbero bisogno di più di un singolo certificato.

Quando viene stabilita una nuova connessione, il certificato del dispositivo remoto deve essere verificato. Se il nodo CoAP dispone di una fonte di tempo assoluto, il nodo DOVREBBE verificare che le date di validità del certificato siano nell'intervallo. Il certificato DEVE essere validato in modo appropriato ai requisiti di sicurezza, utilizzando funzionalità equivalenti all'algoritmo specificato nella Sezione 6 di [RFC5280]. Se il certificato contiene un SubjectAltName, l'authority dell'URI della richiesta DEVE corrispondere ad almeno una delle authority di qualsiasi URI CoAP trovato in un campo di tipo URI nell'insieme SubjectAltName. Se non c'è SubjectAltName nel certificato, l'authority dell'URI della richiesta DEVE corrispondere al Common Name (CN) trovato nel certificato utilizzando le regole di corrispondenza definite in [RFC3280], con l'eccezione che i certificati con caratteri jolly non sono consentiti.

Il supporto CoRE per la verifica dello stato dei certificati richiede ulteriori studi. Poiché una mappatura dell'Online Certificate Status Protocol (OCSP) [RFC6960] su CoAP non è attualmente definita e OCSP potrebbe anche non essere facilmente applicabile in tutti gli ambienti, un approccio alternativo potrebbe essere l'utilizzo dell'estensione TLS Certificate Status Request (Sezione 8 di [RFC6066]; nota anche come "OCSP stapling") o preferibilmente della Multiple Certificate Status Extension ([RFC6961]), se disponibile.

Se il sistema dispone di una chiave condivisa in aggiunta al certificato, DOVREBBE essere utilizzata una suite di cifratura che includa la chiave condivisa come TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA [RFC5489].