Passa al contenuto principale

9. Securing CoAP (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 ha bisogno per operare, inclusi materiali di chiavi e liste di controllo degli accessi. Questa specifica definisce la configurazione per la modalità RawPublicKey nella Sezione 9.1.3.2.1. Alla fine della fase di provisioning, il dispositivo sarà in una delle quattro modalità di sicurezza e avrà le informazioni per quella modalità come descritto di seguito. Le modalità NoSec e RawPublicKey sono obbligatorie da implementare per questa specifica.

NoSec: Non c'è 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 una gestione delle chiavi adeguata.

PreSharedKey: DTLS è abilitato, c'è un elenco di chiavi pre-condivise [RFC4279], e ogni chiave include un elenco di 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 1:1). Al contrario, se più di due entità condividono una chiave pre-condivisa specifica, questa chiave consente solo alle entità di autenticarsi come membro di quel gruppo e non come peer specifico.

RawPublicKey: DTLS è abilitato e il dispositivo ha 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 ha anche un'identità calcolata dalla chiave pubblica e un elenco di identità dei nodi con cui può comunicare.

Certificate: DTLS è abilitato e il dispositivo ha una coppia di chiavi asimmetriche con un certificato X.509 [RFC5280] che lo vincola al suo soggetto ed è firmato da una radice di fiducia comune come descritto nella Sezione 9.1.3.3. Il dispositivo ha anche un elenco di ancore di fiducia radice che possono essere utilizzate per validare un certificato.

Nella modalità "NoSec", il sistema invia semplicemente i pacchetti su UDP normale su IP. Questo è indicato dallo schema "coap" e dalla porta predefinita CoAP. Il sistema è protetto solo impedendo agli aggressori di essere in grado di inviare o ricevere pacchetti dalla rete con i nodi CoAP; vedere Sezione 11.5 per complessità aggiuntive in questo approccio.

Le altre tre modalità di sicurezza utilizzano 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 l'autenticazione (entro i limiti del modello di sicurezza) e, basandosi su questa autenticazione, autorizzare il partner di comunicazione. CoAP stesso non fornisce primitive di protocollo per l'autenticazione o l'autorizzazione; dove questo è richiesto, può essere fornito dalla sicurezza della comunicazione (cioè IPsec o DTLS) o dalla sicurezza dell'oggetto (all'interno del payload). I dispositivi che richiedono l'autorizzazione per alcune operazioni sono previsti richiedere una di queste due forme di sicurezza. Necessariamente, quando la sicurezza della comunicazione è utilizzata con un proxy, questo funziona solo quando quel proxy fa parte delle relazioni di fiducia. CoAP non fornisce un modo per inoltrare diversi livelli di autorizzazione che i client possono avere con un intermediario a ulteriori intermediari o server di origine -- questo è un problema condiviso con HTTP, dove è consueto che il primo intermediario esegua tutte le autorizzazioni.

9.1. DTLS-Secured CoAP (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 Figura 13). Questa sezione definisce il binding CoAP a DTLS, insieme alle configurazioni minime obbligatorie da implementare appropriate per ambienti vincolati. Il binding è definito da una serie di delta al CoAP unicast. In effetti, DTLS è TLS con funzionalità aggiuntive 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 requisiti di scalabilità elevati), e a seconda della particolare suite di cifratura in uso, non tutte le modalità di DTLS saranno applicabili. Alcune suite di cifratura DTLS possono aggiungere una complessità di implementazione significativa così come un certo overhead di handshake iniziale richiesto per impostare l'associazione di sicurezza. Una volta completato l'handshake iniziale, DTLS aggiunge un overhead limitato per datagramma di circa 13 byte, non includendo alcun vettore di inizializzazione/nonce (ad es. 8 byte per TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), valore di controllo dell'integrità (ad es. 8 byte per TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]), e padding richiesto dalla suite di cifratura. Se una data modalità di DTLS è applicabile per l'uso con un'applicazione basata su CoAP dovrebbe essere valutato attentamente considerando la specifica suite di cifratura che può essere applicabile, se la manutenzione della sessione la rende compatibile con i flussi dell'applicazione, e se ci sono risorse sufficienti sui nodi vincolati e per l'overhead di rete aggiunto. (Per alcune modalità di utilizzo di DTLS, questa specifica identifica suite di cifratura obbligatorie da implementare; questo è un requisito di implementazione per massimizzare l'interoperabilità nei casi in cui queste suite di cifratura sono effettivamente appropriate. La politica di sicurezza specifica di un'applicazione può determinare l'insieme effettivo di suite di cifratura che possono essere utilizzate.) 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. Endpoint Identity (Identità dell'Endpoint)​

Lo schema "coaps" si basa sullo schema "coap", e le considerazioni sulla sicurezza nella Sezione 11.1 di [RFC3986] si applicano anche. La sicurezza fornita dallo schema "coaps" è al livello IP (IPsec) o al livello di trasporto (DTLS); di conseguenza, gli intermediari possono aprire e chiudere messaggi "coaps", pur essendo in grado di verificare la correttezza di eventuali controlli di integrità a livello di applicazione. Questo è di particolare importanza per i proxy cross-protocol HTTP/CoAP (vedere Sezione 10). Inoltre, le chiavi di gruppo possono essere utilizzate per fornire riservatezza per le comunicazioni multicast, ma non possono essere utilizzate per validare l'origine (Sezione 11.3).

9.1.2. Security Modes (Modalità di Sicurezza)​

Le quattro modalità di sicurezza descritte all'inizio della Sezione 9 sono implementate utilizzando DTLS o nessuna sicurezza a livello di protocollo CoAP. I requisiti di implementazione (obbligatorio da implementare, ecc.) possono essere trovati nella Sezione 9.1.6.

9.1.3. Pre-Shared Keys (Chiavi Pre-Condivise)​

9.1.3.1. PSK Mode (Modalità PSK)​

DTLS supporta l'uso di chiavi pre-condivise (PSK). DTLS con chiavi pre-condivise come descritto in [RFC4279] abilita l'autenticazione e la riservatezza. Le modalità PSK specificate in [RFC4279] sono supportate dai nodi CoAP abilitati DTLS che implementano questa modalità.

TLS_PSK_WITH_AES_128_CCM_8, come profilato per l'uso in CoAP in [RFC7251], è la suite di cifratura obbligatoria da implementare per i nodi CoAP che implementano questa modalità.

Alcune distribuzioni potrebbero dover utilizzare certificati, chiavi pubbliche grezze o altri metodi di autenticazione invece di PSK. Se un'implementazione CoAP vuole essere utile nella più ampia gamma di distribuzioni, dovrebbe supportare tutte e quattro le modalità di sicurezza definite.

9.1.3.2. RawPublicKey Mode (Modalità RawPublicKey)​

TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, come profilato in [RFC7251], è la suite di cifratura obbligatoria da implementare per i nodi CoAP che implementano questa modalità. Le implementazioni in questa modalità DEVONO utilizzare [RFC7250] per inviare e ricevere chiavi pubbliche grezze.

9.1.3.2.1. Provisioning​

La modalità RawPublicKey necessita di un provisioning appropriato del materiale di chiavi del dispositivo (chiavi asimmetriche, materiale di ancoraggio di fiducia).

Un'implementazione può scegliere di determinare il materiale di chiavi utilizzando una modalità fuori banda, tramite il cosiddetto provisioning implicito.

In alternativa, oltre al provisioning implicito, un'implementazione PUÒ supportare l'uso di protocolli di provisioning in banda basati sulla chiave pubblica grezza. Si noti che un protocollo di provisioning in banda completo può essere costruito solo sopra un protocollo di bootstrap.

9.1.3.3. Certificate Mode (Modalità Certificato)​

TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, come profilato in [RFC7251], è la suite di cifratura obbligatoria da implementare per i nodi CoAP che implementano questa modalità. Le implementazioni in questa modalità DEVONO supportare [RFC5280].

I certificati, e la struttura delle catene di certificati, sono come specificato in [RFC5280]. Il tipo di identificatore URI-ID dalla Sezione 6.4.3 di [RFC6125] DEVE essere supportato.

9.1.4. Server Name Indication (Indicazione del Nome del Server)​

I server vincolati spesso non avranno un modo per identificare facilmente quale URI (o più in generale quale contesto di sicurezza) è di interesse per il client. Le implementazioni possono trovare particolarmente utile utilizzare l'estensione Server Name Indication a DTLS/TLS [RFC6066] per aiutare a identificare il contesto di sicurezza per elaborare la richiesta in arrivo.

9.1.5. New Associations (Nuove Associazioni)​

Ogni endpoint seleziona i parametri di sicurezza utilizzati, inclusa la suite di cifratura, in conformità con i requisiti dell'applicazione e del sistema. Quando un client apre una nuova sessione con un server, richiede che quella sessione sia associata ai parametri di sicurezza richiesti dal server. Le suite di cifratura che sono obbligatorie da implementare sono definite nelle sezioni per ogni modalità di operazione DTLS (Sezioni 9.1.3.1, 9.1.3.2 e 9.1.3.3). Queste suite di cifratura MTI potrebbero non essere la scelta giusta per ogni applicazione o distribuzione: è possibile disabilitarle e utilizzare suite di cifratura diverse che potrebbero essere più appropriate.

9.1.6. DTLS Version (Versione DTLS)​

Le implementazioni in modalità "PreSharedKey", "RawPublicKey" e "Certificate" DEVONO supportare e DOVREBBERO preferire l'uso di DTLS versione 1.2 [RFC6347]. Se un'implementazione rileva che un'implementazione peer è capace solo di DTLS versione 1.0, PUÒ utilizzare DTLS 1.0 per interoperabilità. DTLS 1.0 NON DOVREBBE essere utilizzato con comunicazione di gruppo protetta da DTLS.

9.1.7. DTLS Connection Management (Gestione della Connessione DTLS)​

Finché l'handshake DTLS non è completato, un nodo DOVREBBE attendere che l'handshake sia completato prima di inviare una richiesta. Tuttavia, se l'handshake fallisce, l'handshake di sicurezza dovrebbe essere considerato fallito. Alcuni dettagli aggiuntivi sulla gestione della connessione sono necessari qui, ma questo è rinviato per una versione successiva della specifica.

Ultimo aggiornamento il