Developer-mode provisionnement des clés

Tout d'abord, effectuez les étapes indiquéesConfiguration des démos de FreeRTOS, mais sautez la dernière étape (c'est-à-dire, ne faites pas Pour formater vos AWS IoT informations d'identification). Comme résultat, le fichier demos/include/aws_clientcredential.h devrait avoir été mis à jour avec vos paramètres, mais pas le fichier demos/include/aws_clientcredential_keys.h.

Ouvrez la démo d'authentification mutuelle CoreMQTT comme décrit dans le guide de votre tableau dans. Board-specific guides de démarrage Dans le projet, ouvrez le fichier aws_dev_mode_key_provisioning.c et modifiez la définition de keyprovisioningFORCE_GENERATE_NEW_KEY_PAIR (qui est définie sur zéro par défaut) à un :

#define keyprovisioningFORCE_GENERATE_NEW_KEY_PAIR 1

Ensuite, générez et exécutez le projet de démonstration, puis passez à l'étape suivante.

Étant donné que l'appareil n'a pas été approvisionné avec une clé privée ni un certificat client, la démo ne parviendra pas à s'authentifier. AWS IoT Cependant, la démo d'authentification mutuelle CoreMQTT commence par exécuter le provisionnement des clés en mode développeur, ce qui entraîne la création d'une clé privée si aucune n'était déjà présente. Vous devriez voir quelque chose comme ceci au début de la sortie de la console série.

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 

Copiez les six lignes d'octets de la clé dans un fichier appelé DevicePublicKeyAsciiHex.txt. Ensuite, utilisez l'outil de ligne de commande « xxd » pour analyser les octets hexadécimaux en binaire :

xxd -r -ps DevicePublicKeyAsciiHex.txt DevicePublicKeyDer.bin

Utilisez « openssl » pour formater la clé publique de l'appareil codée en binaire (DER) au format PEM :

openssl ec -inform der -in DevicePublicKeyDer.bin -pubin -pubout -outform pem -out DevicePublicKey.pem

N'oubliez pas de désactiver le paramètre de génération de clé temporaire que vous avez activé ci-dessus. Sinon, l'appareil créera une autre paire de clés, et vous devrez répéter les étapes précédentes :

#define keyprovisioningFORCE_GENERATE_NEW_KEY_PAIR 0

Suivez les instructions de la section Enregistrement de votre certificat CA pour créer une hiérarchie de certificats pour votre certificat d'atelier d'appareil. Arrêtez avant d'exécuter la séquence décrite dans la section Création d'un certificat d'appareil à l'aide de votre certificat de CA.

Dans ce cas, l'appareil ne signera pas la demande de certificat (c'est-à-dire la demande de service de certificat ou CSR) car la logique de X.509 codage requise pour créer et signer une CSR a été exclue des projets de démonstration de FreeRTOS afin de réduire la taille de la ROM. Au lieu de cela, à des fins de test en atelier, créez une clé privée sur votre poste de travail et utilisez-la pour signer la CSR.

openssl genrsa -out tempCsrSigner.key 2048
openssl req -new -key tempCsrSigner.key -out deviceCert.csr 

Une fois que votre autorité de certification a été créée et enregistrée auprès de celle-ci AWS IoT, utilisez la commande suivante pour émettre un certificat client basé sur le CSR de l'appareil qui a été signé à l'étape précédente :

openssl x509 -req -in deviceCert.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out deviceCert.pem -days 500 -sha256 -force_pubkey DevicePublicKey.pem 

Même si la CSR a été signée avec une clé privée temporaire, le certificat émis ne peut être utilisé qu'avec la clé privée réelle de l'appareil. Le même mécanisme peut être utilisé en production si vous stockez la clé de signataire de CSR dans un matériel distinct et que vous configurez votre autorité de certification pour qu'elle émette des certificats uniquement pour les demandes signées par cette clé spécifique. Cette clé devrait également rester sous le contrôle d'un administrateur désigné.

Une fois le certificat émis, l'étape suivante consiste à l'importer dans votre appareil. Vous devrez également importer votre certificat d'autorité de certification (CA), car il est nécessaire pour que la première authentification réussisse lors de l'utilisation AWS IoT de JITP. Dans le aws_clientcredential_keys.h fichier de votre projet, définissez la keyCLIENT_CERTIFICATE_PEM macro comme étant le contenu de l'appareil Cert.pem et définissez la keyJITR_DEVICE_CERTIFICATE_AUTHORITY_PEM macro comme le contenu derootCA.pem.

Importez deviceCert.pem dans le AWS IoT registre comme décrit dans Utiliser votre propre certificat. Vous devez créer un nouvel AWS IoT objet, joindre le certificat EN ATTENTE et une politique à votre objet, puis marquer le certificat comme ACTIF. Toutes ces étapes peuvent être effectuées manuellement dans la AWS IoT console.

Une fois que le nouveau certificat client est ACTIF et associé à un objet et à une politique, exécutez à nouveau la démo d'authentification mutuelle CoreMQTT. Cette fois, la connexion au broker AWS IoT MQTT sera établie.