Azure IoT 디바이스 제조업체를 위한 보안 방식

  • 아티클

IoT 디바이스를 출시하는 제조업체가 증가하기 때문에, 일반적인 방식에 대한 지침을 확인하는 것이 유용합니다. 이 문서에는 Azure IoT DPS(Device Provisioning Service)에서 사용할 디바이스를 제조할 때 고려할만한 권장 보안 방식이 요약되어 있습니다.

  • 디바이스 인증 옵션 선택
  • IoT 디바이스에 인증서 설치
  • TPM(신뢰할 수 있는 플랫폼 모듈)을 제조 프로세스에 통합

디바이스 인증 옵션 선택

IoT 디바이스 보안 조치의 궁극적인 목표는 보안 IoT 솔루션을 만드는 것입니다. 하지만 하드웨어 제한, 비용 및 보안 전문 지식 수준과 같은 모든 문제는 선택하는 옵션에 영향을 줍니다. 또한 보안에 대한 접근 방식은 IoT 디바이스가 클라우드에 연결되는 방식에 영향을 줍니다. IoT 보안의 여러 요소를 고려해야 하지만 모든 고객이 직면하는 주요 요소는 사용할 인증 유형입니다.

널리 사용되는 3가지 인증 유형은 X.509 인증서, TPM(신뢰할 수 있는 플랫폼 모듈) 및 대칭 키입니다. 다른 인증 유형도 있지만 Azure IoT에서 솔루션을 구축하는 대부분의 고객은 이 3가지 유형 중 하나를 사용합니다. 이 문서의 나머지 부분에서는 각 인증 유형을 사용하는 장점과 단점을 둘러봅니다.

X.509 인증서

X.509 인증서는 인증에 사용할 수 있는 일종의 디지털 ID입니다. X.509 인증서 표준은 IETF RFC 5280에 문서화되어 있습니다. Azure IoT에는 인증서를 인증하는 두 가지 방법이 있습니다.

  • 지문. 지문 알고리즘은 인증서에서 대해 실행되어 16진수 문자열을 생성합니다. 생성된 문자열은 인증서의 고유 식별자입니다.
  • 전체 체인을 기반으로 하는 CA 인증. 인증서 체인은 EE(최종 엔터티) 인증서를 인증하는 데 필요한 모든 인증서의 계층적 목록입니다. EE 인증서를 인증하려면 신뢰할 수 있는 루트 CA를 포함한 체인의 각 인증서를 인증해야 합니다.

X.509의 장점:

  • X.509는 Azure IoT에서 지원되는 가장 안전한 인증 유형입니다.
  • X.509는 인증서 관리를 위한 높은 수준의 제어를 허용합니다.
  • 많은 공급업체에서 X.509 기반 인증 솔루션을 제공할 수 있습니다.

X.509의 단점:

  • 많은 고객이 인증서를 위해 외부 공급 업체에 의존해야 할 수 있습니다.
  • 인증서 관리 비용이 많이 들고 전체 솔루션 비용에 추가될 수 있습니다.
  • 세부 계획을 제대로 고려하지 않으면 인증서 수명 주기 관리가 어려울 수 있습니다.

TPM(신뢰할 수 있는 플랫폼 모듈)

TPM은 ISO/IEC 11889라고도 하며 암호화 키를 안전하게 생성하고 저장하기 위한 표준입니다. TPM은 표준을 구현하는 모듈과 상호 작용하는 가상 또는 물리적 I/O 디바이스를 말하기도 합니다. TPM 디바이스는 개별 하드웨어, 통합 하드웨어, 펌웨어 기반 모듈 또는 소프트웨어 기반 모듈로 존재할 수 있습니다.

TPM과 대칭 키 사이에는 두 가지 주요 차이점이 있습니다.

  • TPM 칩은 X.509 인증서도 저장할 수 있습니다.
  • DPS의 TPM 증명은 비대칭 인증의 한 형태인 TPM EK(인증 키)를 사용합니다. 비대칭 인증에서는 공개 키가 암호화에 사용되고 별도의 프라이빗 키가 암호 해독에 사용됩니다. 이에 비해 대칭 키는 암호화와 암호 해독 모두에 프라이빗 키가 사용되는 대칭 인증을 사용합니다.

TPM의 장점:

  • TPM은 많은 Windows 디바이스에 표준 하드웨어로 포함되며, 운영 체제에 대한 지원이 기본 제공됩니다.
  • TPM 증명은 SAS(공유 액세스 서명) 토큰 기반 대칭 키 증명보다 보안이 더 쉽습니다.
  • 디바이스 자격 증명을 쉽게 만료 및 갱신하거나 롤링할 수 있습니다. DPS는 TPM 디바이스를 다시 프로비전해야 할 때마다 IoT Hub 자격 증명을 자동으로 롤링합니다.

TPM의 단점:

  • TPM은 복잡하고 사용하기 어려울 수 있습니다.
  • TPM을 사용한 애플리케이션 개발은 물리적 TPM이나 고품질 에뮬레이터가 없으면 어렵습니다.
  • 하드웨어에 TPM을 포함하도록 디바이스의 보드를 다시 설계해야 할 수 있습니다.
  • TPM에서 EK를 롤링하면 TPM의 ID가 제거되고 새 ID가 생성됩니다. 물리적 칩은 동일하게 유지되지만 IoT 솔루션에 새 ID가 사용됩니다.

대칭 키

대칭 키를 사용하면 동일한 키를 사용하여 메시지를 암호화하고 해독합니다. 결과적으로, 디바이스와 이를 인증하는 서비스 모두에 동일한 키가 알려집니다. Azure IoT는 SAS 토큰 기반 대칭 키 연결을 지원합니다. 대칭 키 인증에는 키를 보호하고 X.509 인증과 동일한 수준의 보안을 달성하기 위해 상당한 소유자 책임이 필요합니다. 대칭 키를 사용하는 경우 권장되는 방법은 HSM(하드웨어 보안 모듈)을 사용하여 키를 보호하는 것입니다.

대칭 키의 장점:

  • 대칭 키를 사용하는 것은 인증을 시작하는 가장 간단하고 저렴한 방법입니다.
  • 대칭 키를 사용하면 추가로 생성할 항목이 없으므로 프로세스가 간소화됩니다.

대칭 키의 단점:

  • 대칭 키는 키의 보안을 유지하기 위해 상당한 노력이 필요합니다. 디바이스와 클라우드 간에 동일한 키가 공유되므로 두 위치에서 키를 보호해야 합니다. 반면 TPM 및 X.509 인증서의 어려운 점은 프라이빗 키를 공개하지 않고 공개 키의 소유를 증명하는 것입니다.
  • 대칭 키를 사용하면 열악한 보안 방식으로 보안이 저하될 수 있습니다. 대칭 키의 일반적인 추세는 디바이스에서 암호화되지 않은 키를 하드코딩하는 것입니다. 이 방식은 편리하지만 키가 공격에 취약해집니다. 디바이스에 대칭 키를 안전하게 저장하여 일부 위험을 완화할 수 있습니다. 하지만 최우선 순위가 편의성보다는 궁극적인 보안에 있다면 X.509 인증서 또는 TPM을 인증에 사용하는 것이 좋습니다.

공유 대칭 키

공유 대칭 키라고 하는 대칭 키 인증의 변형이 있습니다. 이 방식은 모든 디바이스에서 동일한 대칭 키를 사용합니다. 공유 대칭 키는 디바이스에서 사용하지 않는 것이 좋습니다.

공유 대칭 키의 장점:

  • 구현이 간단하고 저렴하게 대규모로 생성할 수 있습니다.

공유 대칭 키의 단점:

  • 공격에 매우 취약합니다. 구현이 간단하다는 장점이 있지만 위험이 훨씬 더 큽니다.
  • 공유 키만 얻으면 누구나 디바이스를 가장할 수 있습니다.
  • 손상된 공유 대칭 키에 의존하는 경우 디바이스에 대한 제어권이 손실될 수 있습니다.

디바이스에 적합한 선택

인증 방법을 선택하려면 자체 제조 프로세스에 대한 각 접근 방식의 이점과 비용을 고려해야 합니다. 디바이스 인증의 경우 일반적으로 주어진 방식의 안전성과 편리성 사이에는 반비례 관계가 있습니다.

IoT 디바이스에 인증서 설치

X.509 인증서를 사용하여 IoT 디바이스를 인증하는 경우, 이 섹션에는 인증서를 제조 프로세스에 통합하는 방법에 대한 지침이 제공됩니다. 몇 가지 사항을 결정해야 합니다. 여기에는 공통 인증서 변수, 인증서 생성 시기 및 설치 시기에 대한 결정이 포함됩니다.

암호 사용에 익숙하다면 모든 디바이스에 동일한 암호를 사용할 수 있듯이, 모든 디바이스에서 동일한 인증서를 사용할 수 없는 이유를 물을 수 있습니다. 우선, 모든 곳에서 동일한 암호를 사용하는 것은 위험합니다. 그런 방식을 따르면, 기업이 주요 DDoS 공격에 노출됩니다. DDoS 공격 때문에 몇 년 전 미국 동부 해안에서 DNS가 중단된 적이 있습니다. 개인 계정을 사용하더라도 모든 곳에서 동일한 암호를 사용하지 마십시오. 둘째, 인증서는 암호가 아니라 고유한 ID입니다. 암호는 보안 건물에서 문을 여는 데 누구나 사용할 수 있는 비밀 코드와 같습니다. 여러분이 알고 있는 것이며 누구에게나 암호를 제공하여 출입할 수 있습니다. 인증서는 보안 건물에 들어가기 위해 경비원에게 보여줄 수 있는 사진과 기타 세부 정보가 포함된 운전 면허증과 같습니다. 사용자가 누구인지를 보여줍니다. 경비원이 사람과 운전 면허증을 정확히 대조할 수만 있으면 본인만 면허증(신분증)을 사용하여 출입할 수 있습니다.

인증서 결정과 관련된 변수

다음 변수와 각 변수가 전반적인 제조 프로세스에 미치는 영향을 고려합니다.

신뢰할 수 있는 인증서 루트를 가져오는 위치

PKI(공개 키 인프라)를 관리하려면 비용이 많이 들고 복잡할 수 있습니다. 회사에서 PKI를 관리한 경험이 없는 경우에는 특히 그렇습니다. 옵션은 다음과 같습니다.

  • 타사 PKI를 사용합니다. 타사 인증서 공급업체에서 중간 서명 인증서를 구입할 수 있습니다. 또는 사설 CA(인증 기관)를 사용할 수 있습니다.
  • 자체 관리형 PKI를 사용합니다. 자체 PKI 시스템을 유지 관리하고 자체 인증서를 생성할 수 있습니다.
  • Azure Sphere 보안 서비스를 사용합니다. 이 옵션은 Azure Sphere 디바이스에만 적용됩니다.

인증서가 저장되는 위치

인증서 저장 위치를 결정하는 데 영향을 주는 몇 가지 요소가 있습니다. 이러한 요소에는 디바이스 유형, 예상 이익률(보안 스토리지 비용을 감당할 수 있는지 여부), 디바이스 기능, 사용할 수 있는 디바이스의 기존 보안 기술이 포함됩니다. 다음 옵션을 살펴보세요.

  • HSM(하드웨어 보안 모듈). HSM을 사용하는 것이 좋습니다. 디바이스의 제어 보드에 이미 HSM이 설치되어 있는지 확인합니다. HSM이 없는 경우 하드웨어 제조업체와 협력하여 요구 사항에 맞는 HSM을 식별합니다.
  • TEE(신뢰 실행 환경)와 같은 디스크의 안전한 장소.
  • 로컬 파일 시스템 또는 인증서 저장소. 예: Windows 인증서 저장소.

팩터리에 대한 연결

팩터리에 대한 연결에 따라 디바이스에 설치할 인증서를 받는 방법과 시기가 결정됩니다. 연결 옵션은 다음과 같습니다.

  • 연결. 연결이 있는 것이 가장 좋습니다. 로컬에서 인증서를 생성하는 프로세스를 간소화합니다.
  • 연결이 없습니다. 이 경우 CA에서 서명된 인증서를 사용하여 로컬 및 오프라인에서 디바이스 인증서를 생성합니다.
  • 연결이 없습니다. 이 경우, 미리 생성된 인증서를 가져올 수 있습니다. 또는 오프라인 PKI를 사용하여 로컬에서 인증서를 생성할 수 있습니다.

감사 요구 사항

생성하는 디바이스 유형에 따라, 디바이스 ID가 디바이스에 설치되는 방식에 대한 감사 내역을 만들기 위한 규제 요구 사항이 있을 수 있습니다. 감사는 상당한 생산 비용을 추가합니다. 따라서 대부분, 필요한 경우에만 수행합니다. 감사가 필요한지 여부를 확신할 수 없으면 회사의 법무 부서에 문의하세요. 감사 옵션은 다음과 같습니다.

  • 중요한 업계가 아닌 경우. 감사가 필요하지 않습니다.
  • 중요한 업계. 인증서는 규정 준수 인증 요구 사항에 따라 보안 공간에 설치해야 합니다. 인증서를 설치할 보안 공간이 필요한 경우에는 인증서가 디바이스에 설치되는 방법을 이미 알고 있을 수 있습니다. 그리고 감사 시스템을 이미 갖추고 있을 수 있습니다.

인증서 유효 기간

운전 면허증처럼 인증서는 생성 시 설정되는 만료 날짜가 있습니다. 인증서 유효 기간에 대한 옵션은 다음과 같습니다.

  • 갱신 불필요. 이 방식은 긴 갱신 기간을 사용하므로 디바이스의 수명 기간에 인증서를 갱신할 필요가 없습니다. 이런 방식은 편리하지만 위험하기도 합니다. 디바이스에서 HSM과 같은 보안 스토리지를 사용하여 위험을 줄일 수 있습니다. 하지만 권장되는 방식은 수명이 긴 인증서를 사용하지 않는 것입니다.
  • 갱신 필요. 디바이스의 수명 기간에 인증서를 갱신해야 합니다. 인증서 유효 기간은 컨텍스트에 따라 다르며 갱신 전략이 필요합니다. 전략에는 인증서를 가져오는 위치 및 갱신 프로세스에서 디바이스가 사용해야 하는 무선 기능의 유형이 포함되어야 합니다.

인증서 생성 시기

팩터리의 인터넷 연결 기능은 인증서를 생성하는 프로세스에 영향을 줍니다. 인증서를 생성하는 시기에는 몇 가지 옵션이 있습니다.

  • 미리 로드된 인증서. 일부 HSM 공급업체는 고객을 위해 HSM 공급업체가 인증서를 설치해주는 프리미엄 서비스를 제공합니다. 우선, 고객이 서명 인증서에 대한 액세스 권한을 HSM 공급업체에 부여합니다. 그러면, HSM 공급업체는 서명 인증서로 서명된 인증서를 고객이 구매한 각 HSM에 설치합니다. 고객은 디바이스에 HSM을 설치하기만 하면 됩니다. 이 서비스는 비용을 추가하지만 제조 프로세스를 간소화하는 데 유용합니다. 또한 인증서 설치 시기에 대한 질문을 해결합니다.
  • 디바이스에서 생성된 인증서. 디바이스가 내부적으로 인증서를 생성하는 경우 디바이스에서 공용 X.509 인증서를 추출하여 DPS에 등록해야 합니다.
  • 팩터리에 연결됨. 팩터리에 연결된 경우 필요할 때마다 디바이스 인증서를 생성할 수 있습니다.
  • 자체 PKI가 있는 오프라인 팩터리. 팩터리에 연결되지 않은 상태에서 오프라인으로 지원되는 자체 PKI를 사용하는 경우 필요할 때 인증서를 생성할 수 있습니다.
  • 타사 PKI가 있는 오프라인 팩터리. 팩터리에 연결되어 있지 않고 타사 PKI를 사용하는 경우에는 미리 인증서를 생성해야 합니다. 그리고 연결된 위치에서 인증서를 생성해야 합니다.

인증서 설치 시기

IoT 디바이스용 인증서를 생성한 후 디바이스에 설치할 수 있습니다.

HSM과 함께 미리 로드된 인증서를 사용하면 프로세스가 간소화됩니다. 디바이스에 HSM이 설치되면 디바이스 코드로 액세스할 수 있습니다. 그런 다음, HSM API를 호출하여 HSM에 저장된 인증서에 액세스합니다. 이 방식은 제조 프로세스에서 가장 편리합니다.

미리 로드된 인증서를 사용하지 않는 경우, 생산 프로세스의 일부로 인증서를 설치해야 합니다. 가장 간단한 방법은 초기 펌웨어 이미지를 플래시하는 동시에 HSM에 인증서를 설치하는 것입니다. 프로세스에서 각 디바이스에 이미지를 설치하는 단계를 추가해야 합니다. 이 단계가 끝나면 디바이스를 포장하고 배송하기 전에 최종 품질 검사 및 기타 단계를 실행할 수 있습니다.

한 번에 설치 프로세스와 최종 품질 검사를 실행할 수 있는 소프트웨어 도구가 있습니다. 이러한 도구를 수정하여 인증서를 생성하거나 미리 생성된 인증서 저장소에서 인증서를 가져올 수 있습니다. 그런 다음, 소프트웨어를 통해 필요한 곳에 인증서를 설치할 수 있습니다. 이런 유형의 소프트웨어 도구를 사용하면 생산 품질 제조를 대규모로 실행할 수 있습니다.

디바이스에 인증서를 설치한 후 다음 단계에서는 DPS에 디바이스를 등록하는 방법을 알아봅니다.

TPM을 제조 프로세스에 통합

TPM을 사용하여 IoT 디바이스를 인증하는 경우, 이 섹션에 지침이 제공됩니다. 이 지침에서는 HMAC(해시 기반 메시지 인증 코드) 키를 지원하는 널리 사용되는 TPM 2.0 디바이스에 대해 설명합니다. TPM 칩에 대한 TPM 사양은 TCG(신뢰할 수 있는 컴퓨팅 그룹)에서 유지 관리하는 ISO 표준입니다. TPM에 대한 자세한 내용은 TPM 2.0 및 ISO/IEC 11889에 대한 사양을 참조하십시오.

TPM 소유권 가져오기

TPM 칩이 있는 디바이스를 제조하는 경우 중요한 단계는 TPM의 소유권을 가져오는 것입니다. 이 단계는 디바이스 소유자에게 키를 제공하기 위해 필요합니다. 첫 번째 단계는 디바이스에서 EK(인증 키)를 추출하는 것입니다. 다음 단계는 실제로 소유권을 주장하는 것입니다. 수행하는 방법은 사용하는 TPM 및 운영 체제에 따라 달라집니다. 필요한 경우 TPM 제조업체나 디바이스 운영 체제 개발자에게 문의하여 소유권을 주장하는 방법을 확인합니다.

제조 프로세스에서 다양한 시기에 EK를 추출하고 소유권을 주장할 수 있기 때문에 유연성을 높일 수 있습니다. 많은 제조업체가 HSM(하드웨어 보안 모듈)을 추가하여 디바이스의 보안을 강화함으로써 이러한 유연성을 활용합니다. 이 섹션에서는 EK를 추출하는 시기, TPM의 소유권을 주장하는 시기, 이러한 단계를 제조 타임라인에 통합하기 위한 고려 사항에 대한 지침을 제공합니다.

Important

다음 지침에서는 개별, 펌웨어 또는 통합 TPM을 사용한다고 가정합니다. 이러한 가정이 적용되는 경우에는, 비분리형 또는 소프트웨어 TPM 사용에 대한 참고 사항이 지침에 추가됩니다. 소프트웨어 TPM을 사용하는 경우, 이 지침에 포함되지 않은 추가 단계가 있을 수 있습니다. 소프트웨어 TPM에는 다양한 구현이 있으며, 그 내용은 이 문서의 범위를 벗어납니다. 일반적으로 다음과 같은 일반 제조 타임라인에 소프트웨어 TPM을 통합할 수 있습니다. 단, 소프트웨어로 에뮬레이트된 TPM은 프로토타입 생성 및 테스트에 적합하지만 개별, 펌웨어 또는 통합 TPM과 동일한 수준의 보안을 제공할 수 없습니다. 일반적으로 프로덕션 환경에 소프트웨어 TPM을 사용하지 마십시오.

일반 제조 타임라인

다음 타임라인은 TPM이 프로덕션 프로세스를 거쳐서 디바이스에서 끝나는 방식을 보여줍니다. 각 제조 프로세스는 고유하며, 이 타임라인은 가장 일반적인 패턴을 보여줍니다. 타임라인은 키를 사용하여 특정 작업을 수행할 시기에 대한 지침을 제공합니다.

1단계: TPM이 제조됨

  • 디바이스에 사용할 TPM을 제조업체에서 구입하는 경우 제조업체가 공용 인증 키(EK_pubs)를 추출해주는지 확인합니다. 제조업체가 배송되는 디바이스와 함께 EK_pubs 목록을 제공해주면 유용합니다.

    참고 항목

    프로비전 서비스에서 공유 액세스 정책을 사용하여 등록 목록에 대한 쓰기 권한을 TPM 제조업체에 부여할 수 있습니다. 이 방식을 통해 제조업체가 TPM을 등록 목록에 추가할 수 있습니다. 단, 제조 프로세스의 초기 단계에서 가능하며 TPM 제조업체에 대한 신뢰가 필요합니다. 이에 대한 위험은 사용자의 책임입니다.

  • 디바이스 제조업체에 판매할 TPM을 제조하는 경우, 고객에게 물리적 TPM과 함께 EK_pub 목록을 제공하는 것이 좋습니다. EK_pubs를 고객에게 제공하면 고객의 프로세스를 한 단계 줄일 수 있습니다.

  • 자체 디바이스에서 사용할 TPM을 제조하는 경우, 프로세스의 어느 지점에서 EK_pub를 추출하는 것이 가장 편리한지 확인합니다. 타임라인의 나머지 지점 어디에서든 EK_pub를 추출할 수 있습니다.

2단계: TPM이 디바이스에 설치됨

생산 프로세스의 이 시점에, 디바이스가 어떤 DPS 인스턴스를 사용할지 알아야 합니다. 그러면 자동 프로비전을 위해 등록 목록에 디바이스를 추가할 수 있습니다. 자동 디바이스 프로비저닝에 대한 자세한 내용은 DPS 설명서를 참조하세요.

  • EK_pub를 아직 추출하지 않았다면 이 시기에 추출하는 것이 좋습니다.
  • TPM의 설치 프로세스에 따라서는, 이 단계가 TPM의 소유권을 주장하기 좋은 시기일수도 있습니다.

3단계: 디바이스에 펌웨어 및 소프트웨어가 설치됨

프로세스의 이 시점에 DPS 클라이언트를 프로비전을 위한 ID 범위 및 전역 URL과 함께 설치합니다.

  • 이제 EK_pub를 추출할 마지막 기회입니다. 타사가 디바이스에 소프트웨어를 설치하는 경우에는 먼저 EK_pub를 추출하는 것이 좋습니다.
  • 제조 프로세스의 이 시점에 TPM의 소유권을 가져오는 것이 가장 좋습니다.

    참고 항목

    소프트웨어 TPM을 사용하는 경우 지금 설치할 수 있습니다. 동시에 EK_pub를 추출합니다.

4단계: 디바이스를 포장하여 웨어하우스로 보냄

디바이스는 DPS를 사용하여 배포 및 프로비전될 때까지 최대 1년 동안 웨어하우스에 보관될 수 있습니다. 배포 전 디바이스를 오랫동안 웨어하우스에 보관하는 경우 디바이스를 배포하는 고객은 펌웨어, 소프트웨어 또는 만료된 자격 증명을 업데이트해야 할 수 있습니다.

5단계: 디바이스가 위치에 설치됨

디바이스가 최종 위치에 도착하면 DPS를 통한 자동 프로비전을 거칩니다.

자세한 내용은 프로비전 및 TPM 증명을 참조하세요.

리소스

이 문서에 포함된 권장 보안 방식 외에, Azure IoT는 보안 하드웨어를 선택하고 보안 IoT 배포를 만드는 데 유용한 리소스를 제공합니다.