Controllo accessi per dispositivo incorporato

Naviga le tue risposte
1

Sviluppiamo un protocollo per il controllo remoto da computer di un certo tipo di giocattolo. È fondamentalmente una rete di sensori e attori che di solito è collegata al PC dell'utente tramite porta seriale o USB. Ora alcuni utenti desiderano connettersi tramite Ethernet e vogliamo progettare una sorta di gateway in un dispositivo incorporato.

È previsto che venga utilizzato solo nelle LAN domestiche (ad esempio dai dispositivi mobili tramite un router WiFi), ma non dovrebbero essere considerati sicuri e c'è sempre la possibilità di essere esposti a Internet. I rischi coinvolti sono molteplici:

  • quei giocattoli sono costosi e potrebbero essere distrutti dall'abuso
  • l'ambiente potrebbe essere danneggiato da problemi con gli alimentatori degli attori
  • i dispositivi sono in grado di aggiornamenti del firmware (non protetti) e potrebbero essere rilevati o murati
  • disturbo generico dell'operazione di servizio
  • intercettazioni su dati privati

Il dispositivo gateway incorporato potrebbe esporre un tipo di server che accetta connessioni, che devono essere limitate a quelle autorizzate. Come fare questo?

Dopo l'idea iniziale di avvolgere il nostro protocollo seriale in pacchetti UDP (per bassa latenza e basso sovraccarico), abbiamo considerato TCP di evitare di occuparsi della perdita di pacchetti nelle reti wireless. TLS è il prossimo passo logico, che fornisce la crittografia 1 . Ma come eseguire l'autenticazione e l'autorizzazione?

Il TLS è applicabile a tutti, se utilizzato in un contesto non web? Non abbiamo necessariamente nomi di host o persino l'accesso a Internet e non so come convalidare i certificati. Non possiamo usare una CA, quindi la nostra PKI sarebbe diversa e non so quali buchi di sicurezza vengano introdotti gestendo manualmente i certificati. Probabilmente è già abbastanza di un problema per ottenere ogni server - ogni dispositivo - il proprio certificato generato casualmente. (Ho anche trovato questi due domande che trattano problemi simili)

Un qualche tipo di processo di accoppiamento (simile a Bluetooth o WPS) risolverebbe il problema con certificati non convalidati? Il dispositivo incorporato sarebbe dotato di un semplice pulsante per accettare un client 2 e il client dovrebbe ricordare ("pin"?) Il certificato del server. Questa prima connessione sarebbe suscettibile a un attacco MITM, ma le connessioni successive non lo farebbero. Suona valido e sicuro? Sono dubbioso sui programmi fatti in casa.

Un'alternativa all'accoppiamento che ho considerato sarebbe uno schema di autorizzazione della password, in cui il client invia una password al server per ottenere l'accesso. 3 Tuttavia, gli utenti tendono a scegliere password deboli, e anche io non ho idea di come (cioè quale protocollo utilizzare) per inviare la password tramite la connessione non protetta - non avendo ancora convalidato alcun certificato -, evitando attacchi MITM o replay.

Per favore aiutami a trovare una buona soluzione - rispondendo alle domande di cui sopra o suggerendo un approccio completamente diverso che mi mancava del tutto. I nostri principali obiettivi / restrizioni sono:

  • buona usabilità anche per utenti non tecnici - senza alcuna manutenzione amministrativa
  • implementazione semplice con librerie ampiamente disponibili per molti linguaggi di programmazione
  • alto livello di sicurezza (se necessario, ignorando la fase di configurazione dove potrebbe essere impossibile)

1: finché usato con le giuste impostazioni, ho raccolto.
2: Suppongo che non dobbiamo dimenticare un modo per rimuovere i client
3: con la password iniziale assegnata in modo casuale a ciascun dispositivo e stampata in basso

    
posta Bergi 04.05.2017 - 04:27
fonte

1 risposta

1

Questa è una domanda piuttosto ampia, quindi non posso dare altri suggerimenti. Prima al suo livello più basso, la libreria SSL / TLS (OpenSSL) richiede solo che entrambe le parti coinvolte in una comunicazione abbiano chiavi private e pubbliche e che ciascuna conosca la chiave pubblica dell'altro. Questo è il modo in cui viene utilizzato ad esempio in OpenSSH. Le infrastrutture PKI e CA e solo un modo per convalidare le chiavi pubbliche per le entità che non si conoscono.

Nel tuo caso d'uso, potresti usare un'autorità di certificazione (privata) per convalidare i certificati per i dispositivi e infine i certificati per i PC client. Ma nel caso in cui una chiave fosse compromessa, il rinnovo di un certificato sarebbe difficile mentre non aggiunge molta sicurezza a un semplice scambio di chiavi pubbliche come fa OpenSSH.

Quindi il mio consiglio sarebbe:

  • trova / crea un modo accettabile per generare coppie di chiavi casuali sui dispositivi e sul software client. Il punto positivo è che il dispositivo è venduto, il nuovo proprietario può installare una nuova chiave su di esso.
  • immagina e sviluppa un modo per scambiare le chiavi pubbliche tra un dispositivo e un PC. Qualcosa come trasmetterli in una finestra temporale seguita da un protocollo di accordo se è stata ricevuta una sola chiave. Dopo quel punto, la chiave peer dovrebbe essere bloccata su ogni parte

Da ora in poi, il dispositivo dovrebbe rifiutare qualsiasi richiesta di connessione che non può dimostrare la conoscenza della sua chiave peer. Ciò ti consente di:

  • si basano sulla libreria OpenSSL (o probabilmente LibreSSL) di alta qualità.
  • consente al proprietario di modificare a piacimento le chiavi sul suo dispositivo se sospetta che il suo PC o dispositivo possa essere stato compromesso, o se per qualsiasi motivo il dispositivo o il PC ha perso la sua chiave precedente (ad esempio la memoria del dispositivo ha dovuto essere sostituito, o se il disco del PC si è bloccato)
  • non richiede più 2 pulsanti (genera una nuova chiave e avvia un'associazione) sul dispositivo o anche un solo pulsante se una nuova associazione può utilizzare in modo coerente una nuova chiave

In alternativa, è possibile impostare una modalità speciale (attivata da un pulsante sul dispositivo) in cui qualsiasi certificato verrà accettato durante una finestra temporale e tale certificato verrà bloccato per ulteriori scambi a condizione che ne venga ricevuto uno e uno solo. In quella modalità solo la connessione dovrebbe essere possibile e nessun comando verrebbe elaborato. Questa variante evita l'impostazione di un protocollo di scambio di chiavi e si basa semplicemente sulla capacità di SSL di superare i certificati. Quindi finisci da entrambi i lati con:

  • generazione di un nuovo certificato autofirmato
  • in modalità speciale che consente il blocco di un certificato peer
  • tutti gli altri scambi si basano sul fatto che l'invio del certificato è uguale al certificato aggiunto

So che non è una risposta definitiva, ma potrebbe consentire di porre domande più precise qui o su StackOverflow ...

    
risposta data 04.05.2017 - 10:24
fonte

Leggi altre domande sui tag

È possibile valutare le connessioni che Tor Browser effettua quando accediamo a un sito web? In che modo sslsniff firma un certificato con un certificato foglia nella catena di fiducia?