Set minimo di funzionalità TLS per un dispositivo incorporato

5

Sto rivedendo la sicurezza di un sistema embedded, in particolare come usa il protocollo TLS o DTLS per comunicare in modo sicuro. Il sistema implementa come poche funzionalità del protocollo in quanto può farla franca. Non si discosta dal protocollo in quanto tale, ma potrebbe non essere sempre rigorosamente conforme a tutte le RFC applicabili. Il mio obiettivo è determinare se la scelta dei parametri di sicurezza sia sicura.

Dovrò farlo di nuovo per altri sistemi simili, quindi la mia domanda è piuttosto generale piuttosto che essere relativa a un sistema specifico.

Gli obiettivi di sicurezza dell'utilizzo di (D) TLS sono i soliti: un utente malintenzionato potrebbe intercettare il traffico di rete (uomo attivo nel mezzo). Vogliamo garantire che il client stia parlando al server con cui pensa di parlare e che una terza parte non possa ottenere o modificare i dati trasmessi (riservatezza e integrità del traffico sulla connessione). Talvolta si desidera anche l'autenticazione client.

Questi sono sistemi incorporati (IoT) con pochissime risorse e di solito interagiscono in ecosistemi controllati. Almeno, controlliamo i peer legittimi, quindi la compatibilità con diversi client e server antichi non è un problema: le preoccupazioni sono molto diverse dall'utilizzo di TLS sul web. Un tipico client endpoint parla solo una o due cipherrite (autenticazione server "classica" basata su firma, chiave precondivisa o una di ciascuna). A seconda dello scenario, l'infrastruttura PKI può essere o meno un sistema chiuso: alcuni dispositivi vivono in un mondo in cui possiamo affidarci alle CA solo per rilasciare certificati di un determinato modulo, mentre altri potrebbero fidarsi di una CA "pubblica".

Si tratta di dispositivi con vincoli stringenti sulla potenza di calcolo disponibile, sulla dimensione della RAM e sulla dimensione del codice. Di conseguenza, generalmente eseguono le librerie TLS ridotte con il minor numero possibile di funzionalità. Sto parlando di microcontrollore con 128-512 kB di RAM, non di dispositivi di fascia più alta con Linux.

Esistono estensioni (D) TLS o X.509 che sono importanti ? Non mi interessa la scelta delle ciphersuites (nessuno usa DES, RC4 o MD5 nel mio mondo, o ciphersuites senza autenticazione del server) o con le dimensioni delle chiavi. Quello di cui sono preoccupato è, ad esempio, un'implementazione che salta i controlli sui certificati (ad esempio la restrizione dell'utilizzo delle chiavi) che consentirebbe un uso improprio di un certificato. O un controllo mancante durante l'handshake che consente un qualche tipo di attacco di downgrade (un dispositivo endpoint di solito parla solo una versione a protocollo singolo, ma i server con cui parla potrebbero supportare più versioni). Oppure un'estensione mancante che consente a un MitM attivo di convincere le due parti a stabilirsi su parametri di sicurezza non corrispondenti o a rinegoziare in modo non preciso.

Che cosa dovrei cercare quando rivedi la configurazione TLS su un piccolo dispositivo incorporato?

    
posta Gilles 10.08.2017 - 00:21
fonte

1 risposta

6

Non è chiaro se stai guardando solo il client TLS o se stai rivedendo l'implementazione sia del client che del server. Assumerò entrambi.

Recentemente ho completato una revisione della sicurezza di WolfSSL (che viene fornita con una raccomandazione tra l'altro) e vari contenuti TLS proprietari, quindi questo è fresco nella mia mente. Ecco un elenco completo di cose che cerco:

X.509 Roba

  • Assicurati che il client verifichi che CN di DN corrisponda al dominio dell'URL richiesto.
  • Usa il tuo giudizio secondo cui la convalida della validazione ha senso nel contesto del sistema chiuso. Potrebbe essere necessario fare alcuni elenchi di quali sono i possibili casi d'uso, dato l'ambiente limitato, e assicurarsi che siano soddisfatti. Fai anche dei grattacapi che l'assenza di controlli per i casi d'uso che stai tralasciando non può essere abusata.
  • I certificati possono essere revocati in questo ambiente? Se sì, quale meccanismo? CRL? OCSP? Potrebbero esserci ulteriori estensioni che devi supportare qui.
    • Come si comporta il client se non riesce a recuperare i dati di revoca? È ragionevole, dato il caso d'uso?
  • Ci sono CA intermedie o tutti i certificati emessi direttamente dalla radice bloccata?
    • La gestione dei trust / trust dei root cert viene eseguita in modo intelligente?
    • Se i prodotti intermedi, quelli si aspettano di recuperare i dati dall'estensione AIA ? (se ci sono "CA Web pubbliche" coinvolte, allora questo è quasi certamente un Sì).
    • Se intermedi, probabilmente dovrai applicare basicConstraints per la lunghezza del percorso e cA per assicurarti che i jolly non stiano cedendo i certificati da un certificato di entità finale.

TLS Stuff

  • Macchina a stati: tutti i SMACK-TLS relativi a vulns (SKIP, FREAK) sono causati dall'aggressore che abusa del motore TLS macchina di stato, quindi assicurati che sia in vigore da ogni stato, quali sono gli stati successivi validi possibili. Più controllo sul server, ma rilevante per entrambi.
  • Cipher Suites: controlla la configurazione del client e verifica che il server combini l'ordine delle preferenze del cliente con le sue in modo intelligente. (BTT TLS 1.3 ha alcune modifiche qui, quindi se devi supportarlo, fai attenzione.)
  • Il solito array di gestione delle dimensioni del buffer, nullità del puntatore e controlli di gestione della memoria. Le cose brutte di solito si manifestano vicino alle chiamate recv socket.

Potrei andare avanti, ma potrei aver bisogno di chiedere un risarcimento: P

    
risposta data 10.08.2017 - 01:57
fonte

Leggi altre domande sui tag