Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Developer-mode aprovisionamiento de claves
**importante**
Esta página hace referencia al Amazon-FreeRTOS repositorio que está en desuso. Recomendamos [empezar por aquí](freertos-getting-started-modular.md) al crear un nuevo proyecto. Si ya tiene un proyecto de Freertos existente basado en el Amazon-FreeRTOS repositorio ahora obsoleto, consulte la. [Amazon-FreeRTOS Guía de migración del repositorio de Github](github-repo-migration.md)
## Introducción
En esta sección se analizan dos opciones para obtener un certificado de X.509 cliente de confianza en un dispositivo de IoT para realizar pruebas de laboratorio. Según las capacidades del dispositivo, es posible que se admitan o no diversas operaciones relacionadas con el aprovisionamiento, como la generación integrada de claves ECDSA, la importación de claves privadas y la inscripción de certificados. X.509 Además, diferentes casos de uso requieren diferentes niveles de protección de claves, que van desde el almacenamiento flash integrado hasta el uso de hardware criptográfico específico. Esta sección proporciona la lógica para trabajar en las funciones criptográficas de su dispositivo.
## Opción \#1: importación de claves privadas desde AWS IoT
Para las pruebas de laboratorio, si su dispositivo permite la importación de claves privadas, siga las instrucciones de [Configuración de las demostraciones de FreeRTOS](freertos-prereqs.md#freertos-configure).
## Opción n.º 2: generación de claves privadas integrada
Si su dispositivo cuenta con un elemento seguro, o si prefiere generar su propio par de claves del dispositivo y certificado, siga las instrucciones siguientes.
**Configuración inicial**
En primer lugar, realice los pasos [Configuración de las demostraciones de FreeRTOS](freertos-prereqs.md#freertos-configure) indicados, pero omita el último paso (es decir, no haga lo siguiente *para formatear sus AWS IoT credenciales*). El resultado neto debe ser la actualización del archivo `demos/include/aws_clientcredential.h` con su configuración, pero no la actualización del archivo `demos/include/aws_clientcredential_keys.h`.
**Configuración del proyecto de demostración**
Abra la demostración de autenticación mutua de coreMQTT tal y como se describe en la guía de su placa en [Board-specific guías de introducción](getting-started-guides.md). En el proyecto, abra el archivo `aws_dev_mode_key_provisioning.c` y cambie la definición de `keyprovisioningFORCE_GENERATE_NEW_KEY_PAIR`, que está establecida en cero de forma predeterminada, a uno:
```
#define keyprovisioningFORCE_GENERATE_NEW_KEY_PAIR 1
```
A continuación, cree y ejecute el proyecto de demostración y continúe con el siguiente paso.
**Extracción de claves públicas**
Dado que el dispositivo aún no se ha aprovisionado con una clave privada y un certificado de cliente, la demostración no se podrá autenticar en AWS IoT. Sin embargo, la demostración de autenticación mutua de coreMQTT comienza ejecutando el aprovisionamiento de claves en modo desarrollador, lo que da lugar a la creación de una clave privada si aún no existe una. Debería ver algo similar a lo siguiente cerca del inicio de la salida de la consola de serie.
```
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
```
Copie las seis líneas de bytes clave en un archivo llamado `DevicePublicKeyAsciiHex.txt`. A continuación, utilice la herramienta de línea de comandos "xxd" para analizar los bytes hexadecimales en binario:
```
xxd -r -ps DevicePublicKeyAsciiHex.txt DevicePublicKeyDer.bin
```
Utilice "openssl" para dar formato a la clave pública del dispositivo codificado binario (DER) como PEM:
```
openssl ec -inform der -in DevicePublicKeyDer.bin -pubin -pubout -outform pem -out DevicePublicKey.pem
```
No olvide deshabilitar la configuración de generación de claves temporales que ha habilitado anteriormente. De lo contrario, el dispositivo creará otro par de claves y tendrá que repetir los pasos anteriores:
```
#define keyprovisioningFORCE_GENERATE_NEW_KEY_PAIR 0
```
**Configuración de la infraestructura de claves públicas**
Siga las instrucciones de [ Registro de su certificado de CA](https://docs.aws.amazon.com/iot/latest/developerguide/device-certs-your-own.html#register-CA-cert) para crear una jerarquía de certificados para el certificado de laboratorio de dispositivo. Deténgase antes de ejecutar la secuencia descrita en la sección *Creación de un certificado de dispositivo con su certificado de CA*.
En este caso, el dispositivo no firmará la solicitud de certificado (es decir, la solicitud de servicio de certificado o CSR) porque la lógica de X.509 codificación necesaria para crear y firmar una CSR se excluyó de los proyectos de demostración de Freertos para reducir el tamaño de la ROM. En su lugar, para las pruebas de laboratorio, cree una clave privada en su estación de trabajo y utilícela para firmar la CSR.
```
openssl genrsa -out tempCsrSigner.key 2048
openssl req -new -key tempCsrSigner.key -out deviceCert.csr
```
Una vez creada y registrada la autoridad de certificación AWS IoT, utilice el siguiente comando para emitir un certificado de cliente basado en la CSR del dispositivo que se firmó en el paso anterior:
```
openssl x509 -req -in deviceCert.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out deviceCert.pem -days 500 -sha256 -force_pubkey DevicePublicKey.pem
```
Aunque la CSR se haya firmado con una clave privada temporal, el certificado emitido solo se puede utilizar con la clave privada del dispositivo real. El mismo mecanismo se puede utilizar en producción si almacena la clave del firmante de la CSR en hardware independiente y configura la entidad de certificación para que solo emita certificados para las solicitudes firmadas por dicha clave. Esta clave también debe permanecer bajo el control de un administrador designado.
**Importación de certificados**
Con el certificado emitido, el siguiente paso es importarlo a su dispositivo. También tendrás que importar el certificado de la autoridad de certificación (CA), ya que es necesario para que la autenticación por primera vez se realice correctamente cuando AWS IoT utilices JITP. En el `aws_clientcredential_keys.h` archivo de su proyecto, configure la `keyCLIENT_CERTIFICATE_PEM` macro como el contenido del dispositivo Cert.pem y configure la `keyJITR_DEVICE_CERTIFICATE_AUTHORITY_PEM` macro como el contenido de. `rootCA.pem`
**Autorización de dispositivos**
Importe `deviceCert.pem` al AWS IoT registro como se describe en [Use su propio certificado](https://docs.aws.amazon.com/iot/latest/developerguide/device-certs-your-own.html#manual-cert-registration). Debes crear AWS IoT algo nuevo, adjuntar el certificado pendiente y una política al tuyo y, a continuación, marcar el certificado como ACTIVO. Todos estos pasos se pueden realizar manualmente en la AWS IoT consola.
Una vez que el nuevo certificado de cliente esté ACTIVO y se le haya asociado un objeto y una política, vuelva a ejecutar la demostración de autenticación mutua de coreMQTT. Esta vez, la conexión con el bróker AWS IoT MQTT se realizará correctamente.