Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Distribuzione delle chiavi in modalità sviluppatore
Importante
Questa pagina fa riferimento al repository Amazon-FreeRTOS che è obsoleto. Per esempio l'output visualizzato sarà simile al testo visualizzato sarà simile al testo visualizzato sarà simile al testo visualizzato sarà simile al testo visualizzato sarà simile Se disponi già di un progetto FreeRTOS esistente basato sull'ormai obsoleto repository Amazon-FreeRTOS, consulta ilGuida alla migrazione del RTOS repository Github gratuito da Amazon.
Introduzione
In questa sezione vengono illustrate due opzioni per ottenere un certificato client X.509 attendibile su un dispositivo IoT per i test di laboratorio. A seconda delle funzionalità del dispositivo, è possibile o meno supportare varie operazioni correlate al provisioning, tra cui la generazione di chiavi ECDSA integrate, l'importazione di chiavi private e la registrazione di certificati X.509. Inoltre, diversi casi d'uso richiedono diversi livelli di protezione delle chiavi, che vanno dall'archiviazione flash integrata all'uso di hardware crittografico dedicato. Questa sezione fornisce la logica per lavorare nelle funzionalità crittografiche del dispositivo.
Opzione 1: Importazione di chiavi private da AWS IoT
Per scopi di test di laboratorio, se il dispositivo consente l'importazione di chiavi private, seguire le istruzioni riportate in Configurazione delle demo gratuite RTOS.
Opzione 2: Generazione di chiavi private integrate
Se il dispositivo dispone di un elemento di sicurezza o se preferisci generare una coppia di chiavi e un certificato personalizzati, segui le istruzioni riportate di seguito.
- Configurazione iniziale
-
Innanzitutto, eseguire la procedura Configurazione delle demo gratuite RTOS, ma ignorare l'ultima fase (ovvero, non eseguire Per formattare le credenziali AWS IoT). Il risultato finale dovrebbe essere che il file
demos/include/aws_clientcredential.h
è stato aggiornato con le impostazioni, ma non il filedemos/include/aws_clientcredential_keys.h
. - Configurazione del progetto demo
-
Apri la demo di autenticazione reciproca CoreMQTT come descritto nella guida della tua scheda inGuide alle operazioni di base specifiche per la scheda. Nel progetto, aprire il file
aws_dev_mode_key_provisioning.c
e modificare la definizione dikeyprovisioningFORCE_GENERATE_NEW_KEY_PAIR
(che è impostata su zero per impostazione predefinita) su uno:#define keyprovisioningFORCE_GENERATE_NEW_KEY_PAIR 1
Quindi creare ed eseguire il progetto demo e passare alla fase successiva.
- Estrazione di chiavi pubbliche
-
Poiché al dispositivo non sono stati forniti una chiave privata e un certificato client, la demo non riuscirà ad autenticarsiAWS IoT. Tuttavia, la demo di autenticazione reciproca CoreMQTT inizia eseguendo il provisioning delle chiavi in modalità sviluppatore, con conseguente creazione di una chiave privata se non ne era già presente una. L'output visualizzato sarà simile all'output visualizzato sarà simile all'output visualizzato sarà simile all'output visualizzato sarà simile all'output visualizzato sarà simile all'output visualizzato sarà simile all'output visualizzato
7 910 [IP-task] Device public key, 91 bytes: 3059 3013 0607 2a86 48ce 3d02 0106 082a 8648 ce3d 0301 0703 4200 04cd 6569 ceb8 1bb9 1e72 339f e8cf 60ef 0f9f b473 33ac 6f19 1813 6999 3fa0 c293 5fae 08f1 1ad0 41b7 345c e746 1046 228e 5a5f d787 d571 dcb2 4e8d 75b3 2586 e2cc 0c
Copiare le sei righe di byte della chiave in un file denominato
DevicePublicKeyAsciiHex.txt
. Quindi utilizzare lo strumento a riga di comando "xxd" per analizzare i byte esadecimali in formato binario:xxd -r -ps DevicePublicKeyAsciiHex.txt DevicePublicKeyDer.bin
Utilizzare "openssl" per formattare la chiave pubblica codificata in formato binario (DER) del dispositivo come PEM:
openssl ec -inform der -in DevicePublicKeyDer.bin -pubin -pubout -outform pem -out DevicePublicKey.pem
Non dimenticare di disabilitare l'impostazione temporanea di generazione delle chiavi abilitata in precedenza. Altrimenti, il dispositivo creerà un'altra coppia di chiavi e sarà necessario ripetere le fasi precedenti:
#define keyprovisioningFORCE_GENERATE_NEW_KEY_PAIR 0
- Configurazione dell'infrastruttura a chiave pubblica
-
Seguire le istruzioni riportate in Registrazione del certificato CA per creare una gerarchia di certificati per il certificato del laboratorio dei dispositivi. Arrestare prima dell’esecuzione la sequenza descritta nella sezione Creazione di un certificato del dispositivo tramite il certificato CA.
In questo caso, il dispositivo non firmerà la richiesta di certificato (ovvero la Certificate Service Request o CSR) perché la logica di codifica X.509 richiesta per creare e firmare un CSR è stata esclusa dai progetti demo di FreeRTOS per ridurre le dimensioni della ROM. Invece, per scopi di test di laboratorio, creare una chiave privata sulla workstation e utilizzarla per firmare il CSR.
openssl genrsa -out tempCsrSigner.key 2048 openssl req -new -key tempCsrSigner.key -out deviceCert.csr
Dopo aver creato e registrato l'autorità di certificazione con AWS IoT, utilizzare il comando seguente per emettere un certificato client basato sul CSR del dispositivo firmato nella fase precedente:
openssl x509 -req -in deviceCert.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out deviceCert.pem -days 500 -sha256 -force_pubkey DevicePublicKey.pem
Anche se il CSR è stato firmato con una chiave privata temporanea, il certificato emesso può essere utilizzato solo con la chiave privata effettiva del dispositivo. Lo stesso meccanismo può essere utilizzato in produzione se si memorizza la chiave del firmatario CSR in un hardware separato e si configura l'autorità di certificazione in modo che emetta solo certificati per le richieste firmate da tale chiave specifica. Tale chiave dovrebbe inoltre rimanere sotto il controllo di un amministratore designato.
- Importazione di certificati
-
Con il certificato emesso, la fase successiva è importarlo nel dispositivo. Sarà inoltre necessario importare il certificato dell'autorità di certificazione (CA), operazione necessaria affinché la prima autenticazione su AWS IoT abbia esito positivo quando si utilizza JITP. Nel file
aws_clientcredential_keys.h
nel progetto, impostare la macrokeyCLIENT_CERTIFICATE_PEM
come contenuto di deviceCert.pem e impostare la macrokeyJITR_DEVICE_CERTIFICATE_AUTHORITY_PEM
come contenuto dirootCA.pem
. - Autorizzazione dispositivo
-
Importare
deviceCert.pem
nel registro AWS IoT come descritto in Uso di un certificato personale. È necessario creare un nuovo oggetto AWS IoT, allegare il certificato IN SOSPESO e una policy all'oggetto, quindi contrassegnare il certificato come ATTIVO. Tutti queste fasi possono essere eseguite manualmente nella console AWS IoT.Una volta che il nuovo certificato client è ATTIVO e associato a un oggetto e a una policy, esegui nuovamente la demo di autenticazione reciproca CoreMQTT. Questa volta, la connessione al broker AWS IoT MQTT avrà esito positivo.