개발자 모드 키 프로비저닝 - 무료RTOS
소개옵션 #1: AWS IoT에서 프라이빗 키 가져오기옵션 #2: 온보드 프라이빗 키 생성

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

개발자 모드 키 프로비저닝

중요

이 페이지는 더 이상 사용되지 않는 Amazon-FreeRTOS 리포지토리를 참조합니다. 새 프로젝트를 생성할 때는 여기서 시작하는 것이 좋습니다. 현재 사용되지 않는 Amazon-FreeRTOS 리포지토리를 기반으로 하는 기존 FreeRTOS 프로젝트가 이미 있는 경우에는 Amazon-FreeRTOS Github 리포지토리 마이그레이션 가이드 섹션을 참조하세요.

소개

이 섹션에서는 랩 테스트를 위해 IoT 디바이스에 신뢰할 수 있는 X.509 클라이언트 인증서를 가져오는 두 가지 옵션에 대해 설명합니다. 디바이스의 기능에 따라 온보드 ECDSA 키 생성, 프라이빗 키 가져오기 및 X.509 인증서 등록을 비롯한 다양한 프로비저닝 관련 작업이 지원되거나 지원되지 않을 수 있습니다. 또한 다양한 사용 사례는 온보드 플래시 스토리지에서 전용 암호화 하드웨어 사용에 이르기까지 다양한 수준의 키 보호를 요구합니다. 이 섹션에서는 디바이스의 암호화 기능 내에서 작업하기 위한 로직을 제공합니다.

옵션 #1: AWS IoT에서 프라이빗 키 가져오기

랩 테스트를 위해 디바이스에서 프라이빗 키 가져오기를 허용하는 경우 무료RTOS 데모 구성의 지침을 따르십시오.

옵션 #2: 온보드 프라이빗 키 생성

디바이스에 보안 요소가 있거나 사용자 고유의 디바이스 키 페어 및 인증서를 생성하려는 경우 여기 나와 있는 지침을 따르십시오.

초기 구성

먼저 무료RTOS 데모 구성의 단계를 수행하고 마지막 단계는 건너뜁니다. 즉, AWS IoT 자격 증명 포맷을 수행하지 않습니다. 최종 결과는 demos/include/aws_clientcredential.h 파일이 사용자 설정으로 업데이트되었지만 demos/include/aws_clientcredential_keys.h 파일은 업데이트되지 않은 것입니다.

데모 프로젝트 구성

보드별 시작 안내서의 보드 안내서에 설명된 대로 coreMQTT 상호 인증 데모를 엽니다. 프로젝트에서 aws_dev_mode_key_provisioning.c 파일을 열고 기본적으로 0으로 설정된 keyprovisioningFORCE_GENERATE_NEW_KEY_PAIR의 정의를 1로 변경합니다.

#define keyprovisioningFORCE_GENERATE_NEW_KEY_PAIR 1

그런 다음 데모 프로젝트를 빌드 및 실행하고 다음 단계를 계속합니다.

퍼블릭 키 추출

디바이스가 아직 프라이빗 키 및 클라이언트 인증서로 프로비저닝되지 않았으므로, 데모는 AWS IoT에 대한 인증이 실패합니다. 그러나 coreMQTT 상호 인증 데모는 개발자 모드 키 프로비저닝을 실행하여 시작되므로 프라이빗 키가 없으면 생성됩니다. 직렬 콘솔 출력 시작 부분에 다음과 같이 표시되어야 합니다.

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

6줄의 키 바이트를 DevicePublicKeyAsciiHex.txt 파일에 복사합니다. 그런 다음 명령줄 도구 “xxd”를 사용하여 16진수 바이트를 바이너리로 구문 분석합니다.

xxd -r -ps DevicePublicKeyAsciiHex.txt DevicePublicKeyDer.bin

“openssl”을 사용하여 바이너리 인코딩(DER) 디바이스 퍼블릭 키를 PEM으로 포맷합니다.

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

위에서 활성화한 임시 키 생성 설정을 비활성화해야 합니다. 그렇지 않으면 디바이스가 또 다른 키 쌍을 생성하며 이전 단계를 반복해야 합니다.

#define keyprovisioningFORCE_GENERATE_NEW_KEY_PAIR 0
퍼블릭 키 인프라 설정

CA 인증서 등록의 지침에 따라 디바이스 랩 인증서에 대한 인증서 계층 구조를 만듭니다. CA 인증서를 사용하여 디바이스 인증서 생성 섹션에 설명된 시퀀스를 실행하기 전에 중지합니다.

이 경우 ROM 크기를 줄이기 위해 CSR을 생성하고 서명하는 데 필요한 X.509 인코딩 로직이 FreeRTOS 데모 프로젝트에서 제외되었으므로 디바이스가 인증서 요청(즉, 인증서 서비스 요청 또는 CSR)에 서명하지 않습니다. 대신 랩 테스트를 위해 워크스테이션에 프라이빗 키를 만들어 CSR에 서명하는 데 사용합니다.

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

인증 기관이 생성되고 AWS IoT에 등록되면 다음 명령을 사용하여 이전 단계에서 서명된 디바이스 CSR을 기반으로 클라이언트 인증서를 발급합니다.

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

CSR이 임시 프라이빗 키로 서명되었더라도 발급된 인증서는 실제 디바이스 프라이빗 키에만 사용할 수 있습니다. 별도의 하드웨어에 CSR 서명자 키를 저장하고 해당 특정 키로 서명된 요청에 대해서만 인증서를 발급하도록 인증 기관을 구성하는 경우 동일한 메커니즘을 프로덕션에서 사용할 수 있습니다. 이 키는 지정된 관리자의 통제 하에 있어야 합니다.

인증서 가져오기

인증서를 발급한 후 다음 단계는 인증서를 디바이스로 가져오는 것입니다. JITP를 사용할 때 처음 AWS IoT에 대한 인증이 성공하려면 인증 기관(CA) 인증서를 가져와야 합니다. 프로젝트의 aws_clientcredential_keys.h 파일에서 keyCLIENT_CERTIFICATE_PEM 매크로를 deviceCert.pem의 콘텐츠로 설정하고 keyJITR_DEVICE_CERTIFICATE_AUTHORITY_PEM 매크로를 rootCA.pem의 콘텐츠로 설정합니다.

디바이스 승인

자체 인증서 사용에 설명된 대로 deviceCert.pem을 AWS IoT 레지스트리로 가져옵니다. 새 AWS IoT 사물을 생성하고 PENDING 인증서와 정책을 사물에 연결한 다음 인증서를 ACTIVE로 표시해야 합니다. 이러한 모든 단계는 AWS IoT 콘솔에서 수동으로 수행할 수 있습니다.

새 클라이언트 인증서가 활성 상태이고 사물 및 정책과 연결되면 coreMQTT 상호 인증 데모를 다시 실행합니다. 이제 AWS IoT MQTT 브로커와 성공적으로 연결됩니다.