silabs 21Q2 dispositivo BLE sicuro Laboratorio di sicurezza

Manuale del laboratorio di sicurezza BLE

In questo laboratorio, vedrai come progettare un dispositivo BLE più sicuro. Inizieremo con un overview su come utilizzare alcune delle funzionalità dello stack e passare ad alcuni consigli generali sulle tecniche per connessioni più sicure e, infine, vedere come utilizzare i certificati dei dispositivi su BLE per identificare una periferica come autentica.

Iniziare

Il Bluetooth èampl'applicazione su cui andrai a costruire è pensata per essere usata con un bootloader. Se stai lavorando con un EFR32MG21B nuovo di zecca, non avrà un bootloader. Puoi trovare un bootloader pre-costruito in platform\bootloader\sample-apps\bootloader-storage-internalsingle\efr32mg21a010f1024im32-brd4181a cartella del tuo SDK.

1. Inizia con una s soc-vuotaampl'app. Questo èampL'app viene utilizzata come modello e costituisce un buon punto di partenza per qualsiasi applicazione BLE.
   1. Aprire la procedura guidata del progetto Silicon Labs da Simplicity Studio File menu -> nuovo.
   2. Selezionare BRD4181C e fare clic sul pulsante "Avanti".
   3. Fare clic sulla casella di controllo 'Bluetooth (9)' sotto il tipo di tecnologia.
   4. Evidenziare 'Bluetooth – SoC vuoto', quindi fare clic su Avanti.
   5. Fare clic sul pulsante "Fine".
2. Ora puoi aggiungere alcune caratteristiche per vedere come le caratteristiche protette e non protette vengono trattate in modo diverso.
   1. Aprire lo slcp del progetto file facendo doppio clic nella finestra Esplora progetti
   2. Evidenziare la scheda "COMPONENTI SOFTWARE" e aprire lo strumento di configurazione GATT come mostrato di seguito: E utilizzare lo strumento di importazione mostrato di seguito per importare gatt_configuration.btconf file dalla cartella del server nei materiali forniti.Il database GATT ha un servizio personalizzato, chiamato "Training", con alcuni dati protetti e altri no. Questo consente di confrontare cosa succede quando si tenta di accedere a una caratteristica protetta rispetto a una non protetta. Questo è un modo rapido per creare un dispositivo con una sicurezza molto elementare.
3. Utilizzeremo la porta seriale per stampare sulla console in Simplicity Studio per tenere traccia di cosa sta succedendo nell'applicazione. Il modo più semplice per trovare questi componenti è cercarli nella finestra di dialogo SOFTWARE COMPONENTS come mostrato:
   1. 1. Installare il componente USART IO Stream
      2. Installa il componente IO Stream Retarget STDIO
      3. Installare il componente I/O standard
      4. Installa il componente Log
      5. Aprire il componente Board Control e attivare 'Abilita Virtual COM UART'
      6. Fai clic con il pulsante destro del mouse sull'adattatore nel pannello 'Debug adapters' e seleziona 'Launch Console'. Seleziona la scheda 'Serial 1' e posiziona il cursore nel campo di immissione testo della finestra della console, quindi premi Invio per riattivare la console.
4. Crea una variabile locale in sl_bt_on_event(), che si trova in app.c, per salvare l'handle di connessione. La variabile deve essere statica poiché questa funzione viene chiamata ogni volta che un evento viene sollevato dallo stack e vogliamo che il valore sia persistente. L'handle di connessione verrà utilizzato in un secondo momentosezione del laboratorio.
5. Inserire alcune istruzioni app_log() per gli eventi per vedere quando siamo connessi, modalità di sicurezza, ecc.
   1. 1. Includere l'intestazione app_log.h file
      2. sl_bt_evt_connection_opened – stampa il bond handle e salva il connection handle. Se il bond handle è 0xFF, non esiste alcun bond tra i dispositivi connessi. Modifica il gestore eventi esistente in modo che assomigli a qualcosa del genere:
      3. sl_bt_evt_connection_parameters – modalità di sicurezza. Questo viene fatto in modo che tu possa vedere quando cambia la modalità di sicurezza. C'è una differenza nella numerazione delle modalità di sicurezza dove la modalità di sicurezza 1 è enumerata con il valore 0, ecc. Aggiungi il seguente gestore di eventi alla tua applicazione:
      4. sl_bt_evt_connection_closed_id. Questo gestore eventi viene modificato per aggiornare l'handle di connessione. Il valore 0xFF viene utilizzato per indicare che non c'è una connessione attiva. Il comando app_log() viene utilizzato per stampare il motivo della chiusura della connessione, l'elenco dei codici di stato è qui. Modifica il gestore eventi esistente in modo che assomigli a qualcosa del genere:
6. Compila e flasha il progetto. A questo punto, eseguiremo il sampl'app per vedere come si comporta senza alcuna modifica, oltre al database GATT.
7. Per connettersi all'app mobile EFRConnect, procedere come segue:
   1. 1. Tocca l'icona 'Browser Bluetooth'.
      2. Tocca l'icona "Connetti" sul dispositivo denominato "Allenamento".
8. Leggere la caratteristica non protetta come segue:
   1. 1. Tocca il link "Ulteriori informazioni" sotto il servizio sconosciuto con UUID a815944e-da1e-9d2a-02e2-a8d15e2430a0.
      2. Leggi la caratteristica non protetta, UUID f9e91a44-ca91-4aba-1c33-fd43ca270b4c toccando l'icona "Leggi". Nessuna sorpresa qui. Poiché la caratteristica non è protetta in alcun modo, verrà inviata in testo normale.
9. Ora leggi la caratteristica protetta, UUID d4261dbb-dcd0-daab-ec95-deec088d532b. Il tuo cellulare dovrebbe chiederti di associare e connetterti, il messaggio potrebbe variare a seconda del tuo sistema operativo mobile. Dopo aver accettato la richiesta di associazione, dovresti vedere un messaggio sulla console come segue: Nota: L'Appendice A alla fine di questo manuale contiene un riepilogo delle capacità I/O e dei metodi di associazione per riferimento. L'Appendice B riassume le modalità di sicurezza Bluetooth.

Configurazione del gestore della sicurezza

Il gestore della sicurezza fa parte dello stack Bluetooth che determina quali funzionalità di sicurezza vengono utilizzate. Tali funzionalità includono la protezione man-in-the-middle (MITM), le connessioni LE Secure (ovvero ECDH), la richiesta di conferma per il bonding, ecc. Il gestore della sicurezza gestisce anche le capacità I/O che vengono utilizzate per determinare quale metodo viene utilizzato per l'associazione/il bonding (vedere l'Appendice A per un riepilogo). In questa sezione vedrai una semplice configurazione.

1. Imposta SM con la configurazione desiderata. L'hardware per questo laboratorio semplifica la visualizzazione di una passkey sulla console. L'immissione della passkey è un requisito per abilitare la protezione MITM. Aggiungi il seguente codice al gestore di eventi sl_bt_system_boot_id. Ciò abilita il man-in-the-middle e informa il dispositivo remoto che abbiamo la possibilità di visualizzare una passkey, ma questo è tutto.
2. Per visualizzare la passkey sulla console, è necessario un gestore eventi come mostrato di seguito:
3. Imposta la modalità di legame, il numero massimo di legami, ecc. Utilizza il seguente codice per iniziare:Queste impostazioni possono essere utilizzate per limitare la capacità di un aggressore di associarsi al tuo dispositivo. Se il tuo prodotto ha bisogno di un solo utente, allora potresti limitare il numero massimo di associazioni a 1. Un buon posto per aggiungere queste chiamate è nel gestore di eventi sl_bt_system_boot_id. Non abiliteremo l'associazione in questo momento per rendere più fluido il resto del laboratorio, ma impostiamo una policy di associazione per consentire solo un'associazione. Per riferimento, la documentazione per queste API è disponibile qui e qui .
4. Aggiungere gestori di eventi per sl_bt_evt_sm_bonded_id e sl_bt_evt_sm_bonding_failed_id. L'uso principale di questi eventi è attualmente informativo, ma più avanti nel laboratorio aggiungerai funzionalità.
5. Compila e flasha sulla scheda target. Connettiti con EFRConnect e leggi la caratteristica protetta come prima. Questa volta, vedrai una passkey visualizzata sulla console. Inserisci questa passkey sul tuo cellulare quando richiesto.
6. Prova la conferma del bonding. Questa funzionalità consente all'utente di richiedere che le richieste di bonding siano confermate. In questo modo, l'applicazione ha il controllo sui dispositivi peer con cui si collega. Una possibilità è richiedere all'utente di premere un pulsante prima di consentire il bonding.
   1. Apri le impostazioni Bluetooth sul tuo cellulare e rimuovi il legame con il dispositivo EFR32. Le implementazioni dei cellulari variano, quindi questo passaggio potrebbe non essere necessario. Se non vedi il dispositivo "Training" nelle impostazioni Bluetooth, procedi semplicemente al passaggio successivo.
   2. Nei componenti software, installare un'istanza del gestore dei pulsanti semplici.
   3. Includi l'intestazione file sl_simple_button_instances.h nell'app.c
   4. Aggiungere un gestore per l'evento sl_bt_evt_sm_bonding_confirm_id. Il compito principale di questo gestore di eventi è informare l'utente che un dispositivo remoto sta richiedendo un nuovo bond.
   5. Aggiungere una funzione di callback per il gestore di pulsanti semplice per inviare un segnale allo stack Bluetooth indicando che è stato premuto un pulsante. Ciò sostituisce il callback predefinito che semplicemente restituisce.
   6. Aggiungere un gestore di eventi di segnale esterno. Questo evento viene generato in risposta alla ricezione di un segnale, come nel passaggio precedente. L'evento di segnale esterno verrà utilizzato per confermare il bonding.
   7. Modificare la chiamata a sl_bt_sm_configure per richiedere la conferma del bonding come
   8. Ricostruisci e flasha.
   9. Connettiti con EFRConnect e leggi la caratteristica protetta come prima. Ora vedrai un messaggio sulla console come segue:Premere PB0 per confermare il bonding. Ora la console visualizzerà la passkey da immettere sul telefono cellulare per il bonding. Immettere la passkey per completare il processo di bonding.

 

Mancia: Usa il caso predefinito nel gestore eventi per stampare un messaggio quando lo stack invia un evento che non è gestito. Lo stack potrebbe cercare di dirti qualcosa di importante.

Oltre le basi

A questo punto, hai preso vantaggiotage delle funzionalità di sicurezza che il nostro stack ha da offrire. Ora miglioriamo l'implementazione tramite un uso oculato delle funzionalità a nostra disposizione. I seguenti passaggi sono facoltativi e indipendenti l'uno dall'altro, puoi compilare e flashare dopo ognuno per vedere il comportamento o provarli tutti insieme.

1. Disconnettiti in caso di tentativi di vincolo falliti. Questo è un buon punto per rilevare le minacce. Se il dispositivo remoto non supporta la crittografia/autenticazione o semplicemente non ha le chiavi corrette, potrebbe trattarsi di un hacker. Quindi, interrompiamo la connessione. Prova ad aggiungere una chiamata a sl_bt_connection_close() nell'evento sl_bt_sm_bonding_failed_id. L'API è documentata qui.È possibile testare questa funzionalità immettendo la passkey errata.
2. Consentire il bonding solo in determinati momenti. Ciò limita il tempo a disposizione di un aggressore per formare un bond e rende possibile l'uso della funzionalità "only allow bonded connections". Il progettista può scegliere come abilitare o disabilitare la modalità bondable. A scopo dimostrativo, abiliteremo una "modalità di configurazione" con PB1 e utilizzeremo un timer per disabilitarla dopo 30 secondi.
   1. Installa una seconda istanza dell'interfaccia semplice dei pulsanti. Ciò consentirà l'uso di PB1.
   2. Modifica il callback per inviare un segnale diverso allo stack per abilitare/disabilitare il bonding. Il risultato dovrebbe essere simile a questo:
   3. Modificare il gestore eventi del segnale esterno in modo che gestisca questo nuovo segnale. Il risultato dovrebbe essere simile a questo:
   4. Aggiungere un gestore eventi per l'evento sl_bt_evt_system_soft_timer_id. Questo verrà utilizzato per disabilitare la modalità di configurazione.
   5. Il seguente codice può essere utilizzato per abilitare la modalità bondable e consentire tutte le connessioni oppure per disabilitare la modalità bondable e consentire solo le connessioni dai dispositivi bonded:
   6. Aggiungere la seguente chiamata nel gestore eventi sl_bt_system_boot_id
   7. Compila il progetto e installalo sul dispositivo.
   8. Prova a connetterti al dispositivo con EFRConnect. La connessione dovrebbe fallire.
   9. Ora prova a premere PB1 prima di connetterti con EFRConnect. Questa volta la connessione avrà successo. Dopo 30 secondi vedrai un messaggio sulla console che indica che il dispositivo sta uscendo dalla modalità di configurazione. Ciò significa che la modalità bondable è ora disabilitata.
3. Aumenta la sicurezza quando si forma una connessione. Poiché la sicurezza è facoltativa, dovremmo richiedere una connessione crittografata il prima possibile anziché affidarci alle caratteristiche GATT. L'API è documentata qui. Un buon posto per chiamare questa API è nell'evento sl_bt_evt_connection_opened_id. L'handle di connessione è disponibile nella variabile di connessione.

Identità sicura

Ora che abbiamo un dispositivo Bluetooth più sicuro, miglioriamo la fase di autenticazione. Hai già visto come verificare l'identità sicura dei dispositivi vault con la riga di comando nei precedenti laboratori di formazione. In questa sezione, vedremo come un dispositivo BLE può verificare l'identità di un altro dispositivo BLE richiedendo la sua catena di certificati e inviando una sfida. Tutte le parti del vault sicuro detengono il proprio certificato dispositivo e il certificato batch. I certificati di fabbrica e radice sono codificati in modo rigido nell'applicazione client per abilitare la verifica dell'intera catena di certificati. Fai riferimento ad AN1268 per maggiori dettagli sull'identità sicura.

1. Definire un buffer globale per memorizzare la firma di attestazione del dispositivo come di seguito:
2. Imposta la configurazione del gestore di sicurezza per usare l'associazione JustWorks. Questo viene fatto in modo che la connessione sia crittografata. In pratica, dovrebbe essere usata la protezione MITM ma per mantenere il laboratorio semplice, useremo JustWorks. Modifica la chiamata a sl_bt_sm_configure di nuovo come segue:Inoltre, commentare la chiamata a setup_mode(true) nel gestore eventi system_boot.
3. Aprire helpers.c dai materiali forniti e copiare il contenuto in app.c. Queste funzioni di callback eseguono attività come la segmentazione dei certificati in modo che possano essere inviati tramite BLE, la verifica della catena di certificati e la generazione/verifica della sfida.
4. È necessario determinare la dimensione massima dell'unità di trasferimento (MTU) in modo che i certificati possano essere segmentati e riassemblati. Definire una variabile globale per salvare l'MTU come mostrato qui:Quindi aggiungere un gestore eventi per l'evento scambiato MTU GATT come mostrato di seguito:
5. Ci sono tre caratteristiche dei dati utente che possono essere lette. Queste caratteristiche sono utilizzate per comunicare il certificato del dispositivo, il certificato batch e la sfida. Una funzione di callback è utilizzata per gestire queste richieste di lettura utente. Aggiungere un gestore per chiamare questa funzione come mostrato di seguito:Il callback usa l'MTU del passaggio n. 2 per segmentare e inviare i certificati come necessario. Gestisce anche l'invio della sfida firmata.
6. Il client invia una sfida, un numero casuale che deve essere firmato dal server, scrivendo una delle caratteristiche GATT. Per questo motivo, l'applicazione deve avere un gestore per l'evento di richiesta di scrittura dell'utente come di seguito:
7. Aggiungere supporto per identità sicura files al progetto:
   1. app_se_manager_macro.h, app_se_manager_secure_identity.c e app_se_secure_identity.h dai materiali forniti al progetto. Questi filecontengono alcune funzioni di supporto per attività quali l'ottenimento della dimensione del certificato, l'ottenimento della chiave pubblica del dispositivo e la firma di una sfida.
   2. Includere app_se_manager_secure_identity.h in app.c.
8. Importa il gatt_configuration-attest.btconf fornito dai materiali forniti. Questo database GATT chiamato attestazione sicura include quattro caratteristiche che saranno utilizzate per verificare l'identità del nostro dispositivo. Queste includono il certificato del dispositivo, il certificato batch, la sfida e la risposta.
9. Il client, che viene utilizzato per simulare un dispositivo come il gateway, viene fornito come progetto completo poiché è più complesso da costruire. In generale, il funzionamento del client è il seguente:
   1. Esegue la scansione dei dispositivi che pubblicizzano il servizio di attestazione sicura e si connette ad essi.
   2. Scopri i servizi e le caratteristiche del database GATT.
   3. Legge i certificati del dispositivo e del batch e verifica la catena di certificati utilizzando il certificato di fabbrica e quello radice memorizzati nella memoria flash.
   4. Invia una sfida casuale al server.
   5. Tenta di verificare la risposta alla sfida.
   6. Chiude la connessione se una delle verifiche fallisce.
10. Compila e flasha il progetto del server sul tuo server WSTK/radioboard.
11. Importa il progetto client dalla cartella client nei materiali forniti. Compila e flasha il progetto client sul tuo client WSTK/radioboard.
12. Premi reset sul client WSTK e apri la console seriale. Il client inizia a cercare dispositivi che pubblicizzano il nostro servizio di identità sicura e si collegherà quando ne troverà uno.
13. Il client visualizzerà alcuni messaggi per indicare che ha trovato il server con il servizio desiderato e messaggi di stato sulla verifica della catena di certificati.
14. Se la verifica passa, il client genererà un numero casuale, chiamato sfida, e lo invierà al server. Il server firmerà la sfida con la sua chiave privata del dispositivo conservata in modo sicuro e la firma al client, questa è chiamata risposta alla sfida. Il client usa quindi la chiave pubblica nel certificato del dispositivo ricevuto in precedenza per verificare la firma. Questo viene fatto per confermare che il server ha davvero la chiave privata che ha dichiarato di avere. Se la sfida è verificata correttamente, viene visualizzato un messaggio in tal senso; in caso contrario, la connessione viene chiusa e viene visualizzato un messaggio che spiega il motivo.
15. Ora invia un certificato non valido per confermare che la verifica funziona davvero. Puoi modificare user_read_request_cb() per corrompere i dati del certificato o la risposta di sfida.

Appendice A – Capacità di I/O e metodi di associazione
Appendice B – Modalità e livelli di sicurezza

La modalità di sicurezza 1 è l'unica modalità supportata per Bluetooth Low Energy nello stack di Silicon Labs. I livelli sono i seguenti:

• Livello 1 senza sicurezza
• Associazione non autenticata di livello 2 con crittografia
• Accoppiamento autenticato di livello 3 con crittografia
• Connessioni sicure autenticate di livello 4 con crittografia avanzata (scambio di chiavi ECDH)

 

Documenti / Risorse

silabs 21Q2 dispositivo BLE sicuro Laboratorio di sicurezza [pdf] Manuale d'uso 21Q2 dispositivo BLE sicuro Security Lab, dispositivo BLE sicuro Security Lab, Security Lab

Riferimenti

• Manuale d'uso