Mise en service de clés en mode développeur

Tout d'abord, effectuez les étapes décrites dans Configuration des démos de FreeRTOS, mais ignorez la dernière étape (en d'autres termes, n'exécutez pas l'étape Pour formater vos informations d'identification AWS IoT). 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 forum enManuels de mise en route spécifiques aux cartes. 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é doté d'une clé privée ni d'un certificat client, la démo ne parviendra pas à s'authentifierAWS IoT. Toutefois, la démo de CoreMQTT Mutual Authentication commence par l'exécution du provisionnement de clés en mode développeur, ce qui entraîne la création d'une clé privée si aucune clé n'était déjà présente. Vous devriez voir quelque chose ressemblant à 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 codage X.509 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 d'AWS IoT, utilisez la commande suivante pour émettre un certificat client basé sur la CSR d'appareil qui a été signée à 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 requis pour que la première authentification auprès d'AWS IoT réussisse lors de l'utilisation de JITP. Dans le fichier aws_clientcredential_keys.h de votre projet, définissez la macro keyCLIENT_CERTIFICATE_PEM comme étant le contenu de deviceCert.pem et définissez la macro keyJITR_DEVICE_CERTIFICATE_AUTHORITY_PEM comme étant le contenu de rootCA.pem.

Importez deviceCert.pem dans le registre AWS IoT comme décrit dans Utiliser votre propre certificat. Vous devez créer un nouvel objet AWS IoT, attacher le certificat PENDING (EN SUSPENS) et une stratégie à votre objet, puis marquer le certificat comme étant ACTIVE (ACTIF). Toutes ces étapes peuvent être effectuées manuellement dans la console AWS IoT.

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 à l'agent MQTT AWS IoT va réussir.