IoT 보안 기본 사항 - 3부: 보안 부트 및 펌웨어 업데이트 확인

편집자 주: IoT 장치의 확산에도 불구하고, 공격이 성공할 경우 회사 데이터와 개인 데이터가 손상될 수 있는 산업용 IoT(IIoT)와 핵심 응용 분야에서 보안 위협은 연결 장치를 채택하는 데 장벽이 되는 만큼, 이러한 장치를 보호하는 것은 지속적인 문제로 남아 있습니다. IoT 응용 제품을 보호하는 것이 까다로울 수도 있지만, 실제로 IoT 장치 보안은 하드웨어 보안 장치에서 지원하는 상대적으로 간단한 몇 가지 원칙으로 구축할 수 있습니다. 체계적인 보안 방법에 따라 문제를 해결할 수 있습니다. 여러 단원으로 구성된 이 시리즈에서는 개발자가 시작 단계부터 모범 사례를 따르도록 도와주는 실용적인 지침을 제공합니다. 1부에서는 보안 설계의 기반이 되는 암호화 알고리즘에 대해 설명합니다. 2부에서는 보안 IoT 설계에서 개인 키, 키 관리 및 보안 스토리지의 역할에 대해 설명합니다. 본 3부에서는 IoT 장치에 대한 다른 유형의 위협을 완화하기 위해 보안 프로세서를 기반으로 구축된 메커니즘을 살펴봅니다. 4부에서는 고급 프로세서에 보안 메커니즘을 적용하여 IoT 장치의 런타임 환경에서 공격을 완화하는 데 필요한 분리 상태를 보장하는 방법을 확인하고 보여줍니다. 5부에서는 이러한 장치를 IoT 클라우드 리소스에 연결하는 데 사용되는 더 높은 수준의 보안 조치까지 IoT 장치의 보안을 계속해서 살펴봅니다.

조합 방식으로 사용되는 하드웨어 기반 암호화와 보안 스토리지는 보안 사물 인터넷(IoT) 설계를 구현하는 데 필요한 중요 기능을 제공합니다. 하지만 배포된 IoT 장치는 장치를 훼손하거나, 즉각적으로 공격을 실행하거나, 미묘하고 진화된 영구 위협을 위해 고안된 다양한 위협에 노출됩니다.

이 기사에서는 Maxim Integrated, Microchip Technology, NXP Semiconductors, Silicon Labs 등의 보안 프로세서에서 소프트웨어 실행을 위한 신뢰할 수 있는 환경을 제공하는 기본 보안 메커니즘의 바탕이 되는 신뢰점을 활용하여 IoT 장치에서 보안을 강화할 수 있는 방법을 설명합니다.

신뢰점이란 무엇이고 왜 필요한가?

암호화 방법과 보안 키는 연결된 장치에 대한 보안에서 중대한 조력자 역할을 합니다. 이 시리즈의 1부와 2부에서 언급한 대로 이러한 기능은 상위 수준 프로토콜에서 데이터 및 통신을 보호하는 데 사용되는 기본 메커니즘을 제공합니다. 시스템을 보호하기 위해 개발자는 내장형 시스템의 소프트웨어 실행과 시스템 작동에 영향을 줄 수 있는 취약성을 고려해야 합니다.

일반 내장형 시스템에서 정전이나 중요 소프트웨어의 예외 사항으로 인해 시스템이 재설정될 경우 소프트웨어 부트 공정이 실행되어 비휘발성 메모리에서 펌웨어 이미지를 다시 로드합니다. 일반적으로 소프트웨어 재부트는 실수로 또는 고의로 불안정해진 시스템 기능을 복원하는 데 사용되는 중요한 안전 메커니즘입니다. 연결된 시스템에서는 해커가 다양한 블랙햇 도구를 사용하여 소프트웨어를 훼손하기 때문에 보안 전문가는 재부트를 활용하여 소프트웨어 실행에 영향을 주는 침입에 대응하는 것이 좋습니다. 예를 들어 2018년에 FBI는 소비자 및 비즈니스 소유자에게 라우터를 재부트하여 당시에 성행하던 대규모 해킹 캠페인을 차단할 것을 권고했습니다.

실제로 재부트가 시스템 무결성을 보장하지는 않습니다. 손상된 펌웨어 이미지로 재부트할 경우 시스템은 여전히 해커의 통제를 받게 됩니다. 이러한 위협을 완화하기 위해 개발자는 소프트웨어가 부트 시 설정된 신뢰점을 기반으로 하여 실행되고 소프트웨어 실행 환경의 모든 계층을 통해 확장되는지 확인해야 합니다. 이러한 수준의 보안을 달성하려면 부트 공정에서 신뢰할 수 있는 펌웨어가 시작되는지 확인해야 합니다.

보안 부트용 펌웨어 이미지 확인

내장형 시스템에서 호스트 프로세서는 펌웨어 이미지를 플래시에서 주 메모리로 로드한 후 시작하거나 XIP(execute-in-place) 기능을 사용하여 플래시에서 직접 실행합니다. 해커가 펌웨어 이미지를 훼손한 경우 부트 공정에서 시스템이 손상됩니다.

펌웨어로 부트하기 전에 펌웨어 무결성을 확인하기 위해 개발자는 공급망에서 초기에 시작되는 코드 서명 공정을 사용합니다. 보안 시설 내에서 시스템의 펌웨어 이미지는 타원 곡선 디지털 서명 알고리즘(ECDSA)과 같은 강력하게 암호화된 알고리즘으로 생성된 개인-공용 키 쌍에서 개인 키로 서명됩니다. 개인 키는 시설을 벗어나지 않지만 시스템 공용 키는 시스템과 함께 제공됩니다. 부트 중에 프로세서는 이 시스템 공용 키를 적용하여 이미지를 사용하기 전에 펌웨어 서명을 확인합니다.

여기서 설명한 공정에서 공용 키는 그 자체로 취약하며, 다 나아가 시스템 펌웨어도 무단 대체에 취약하게 만듭니다. 내장형 시스템에서 공용 키가 보호되지 않은 상태로 유지될 경우 해커가 직접 생성한 개인-공용 키 쌍의 공용 키로 해당 공용 키를 대체할 수 있습니다. 해커가 시스템의 펌웨어 이미지를 본인 소유의 연결된 개인 키로 서명된 악의적인 펌웨어로 교체한 경우, 손상된 펌웨어 서명이 확인 공정을 통과하고 부트 공정이 계속 진행되어 시스템이 손상됩니다.

따라서 보안 시스템에서는 보안 시설 내 보안 요소에서 프로비저닝되는 유효한 공용 키를 사용합니다. Maxim Integrated의 DS28C36 및 Microchip Technology의 ATECC608A와 같은 보안 IC는 기존 보안 요소에 대한 보안 스토리지를 제공하는 동시에 펌웨어 서명 확인을 위해 인증 알고리즘(예: ECDSA)을 보안된 방식으로 실행합니다.

예를 들어 부트하기 전에 호스트 프로세서에서 직렬 인터페이스를 통해 펌웨어를 DS28C36에 전송할 수 있습니다. 그러면 DS28C36에서는 보안 시설에서 이전에 프로비저닝된 시스템 공용 키를 사용하여 펌웨어 서명이 실제로 동일한 보안 시설 내에서 연결된 개인 키를 사용하여 생성되었는지 확인합니다. 마지막으로 DS28C36은 확인 결과를 호스트 프로세서에 전달합니다. 서명이 유효하면 펌웨어 이미지가 로드됩니다(그림 1).

그림 1: 개발자는 Maxim Integrated DS28C36과 같은 보안 IC를 통해 펌웨어 서명을 확인하여 호스트 프로세서에서 손상된 펌웨어를 부트하지 않도록 차단할 수 있습니다. (이미지 출처: Maxim Integrated)

많은 보안 부트 공정에서 펌웨어 이미지를 보호하여 손상된 키 또는 이미지 관련 문제를 제거합니다. 보안 스토리지 및 암호화 가속기를 사용하여 Silicon Laboratories의 Gecko Series 2 프로세서, NXP의 LPC55S69JBD100, Maxim Integrated의 MAX32520, Microchip Technology의 ATSAML11D16A 등 점점 더 많은 프로세서에 효과적인 보안 부트 기능이 내장되고 있습니다. 이 클래스의 보안 프로세서에서는 이러한 기능을 사용하여 시스템 및 응용 소프트웨어를 실행하는 신뢰할 수 있는 환경을 구축하는 데 필요한 신뢰점을 제공할 수 있습니다.

보안 부트를 통해 신뢰점 제공

이 클래스의 보안 프로세서는 신뢰점을 기반으로 하여 펌웨어 이미지의 무결성을 확인하도록 고안된 보안 부트 옵션을 제공합니다. 예를 들어 Silicon Laboratories의 EFR32MG21A 및 EFR32BG22 Gecko Series 2 프로세서는 각각 하드웨어 보안 요소와 가상 보안 요소(VSE)를 기반으로 다중 스테이지 부트 공정을 통해 신뢰점을 구축합니다(그림 2).

그림 2: Silicon Laboratories의 Gecko Series 2 EFR32MG21A 프로세서는 여기에 나와 있는 다중 스테이지 부트 공정의 1단계에서 통합 하드웨어 보안 요소를 사용하고, EFR32BG22에서는 가상 보안 요소를 사용하여 다중 스테이지 부트 공정을 시작합니다. (이미지 출처: Silicon Laboratories)

EFR32MG21A에서 전용 프로세서 코어는 보안 키 스토리지용 하드웨어 보안 요소와 함께 암호화 기능을 제공합니다. 이 전용 기능에 의해 지원되는 프로세서에서는 읽기 전용 메모리(ROM)에 저장된 코드로 부트 공정을 시작하여 1단계 부트로더(FSB) 코드를 확인합니다. 확인이 완료되면 FSB 코드가 실행되어 2단계 부트로더(SSB)의 코드 서명을 확인합니다. 부트 시퀀스에서 확인된 SSB를 계속 실행하여 응용 코드의 서명을 확인합니다. 응용 코드는 일반적으로 시스템 레벨 코드와 상위 수준 응용 코드를 모두 포함합니다. 마지막으로 확인된 응용 코드가 실행되고 응용 제품의 요구에 따라 시스템 작동이 진행됩니다.

이 공정은 ROM 코드로 시작되고 확인된 FSB, SSB 및 응용 코드만 실행하므로 이 방식에서는 코드 실행을 위해 확인된 신뢰 체인을 생성합니다. 이 신뢰 체인의 첫 번째 링크에서는 수정할 수 없는 ROM 코드를 사용하므로 체인의 각 후속 링크에서 이 신뢰할 수 있는 환경을 확장합니다. 또한 이 접근 방식을 사용하면 개발자가 응용 코드와 1단계 및 2단계 부트로더 코드를 안전하게 업데이트할 수 있습니다. 각 코드 패키지에서 확인된 서명을 제공하는 한 신뢰할 수 있는 환경은 그대로 유지됩니다.

신뢰점을 통해 이러한 종류의 보안 부트를 제공하는 프로세서는 일반적으로 다양한 모드와 옵션을 지원합니다. 예를 들어 Silicon Laboratories의 Gecko Series 2 프로세서는 강력한 인증서 기반 보안 부트 기능을 제공합니다.

루틴 공용 키 인프라(PKI) 트랜잭션에서 사용되는 인증서에는 인증 기관(CA)에서 부여한 루트 인증서를 가리키는 하나 이상의 연결된 인증서에 대한 참조와 함께 공용 키가 포함되어 있습니다. 이 체인의 각 인증서는 하위 인증서를 확인하여 신뢰할 수 있는 CA를 기반으로 신뢰 체인을 생성합니다. 브라우저에서 TLS(전송 계층 보안)의 인증 단계 중에 이 신뢰 체인을 사용하여 웹 서버의 ID를 확인합니다. 동일한 방법으로 내장형 시스템에서 인증서를 사용하여 부트로더 또는 응용 코드의 소스 ID를 확인할 수 있습니다. 앞서 설명한 대로 여기서 다중 스테이지 부트 공정이 계속 진행되지만 각 스테이지와 연결된 인증서를 추가적으로 확인합니다(그림 3).

그림 3: Silicon Laboratories의 Gecko Series 2 프로세서는 부트 공정의 각 스테이지에서 서명 확인 중에 사용된 공용 키에 대한 인증서를 확인하여 시스템 보안을 강화합니다. (이미지 출처: Silicon Laboratories)

NXP LPC55S69JBD100과 같은 다른 프로세서에서는 펌웨어 이미지에 대한 다양한 옵션을 지원합니다. 서명된 펌웨어 이미지 이외에 이러한 프로세서에서는 Trusted Computing Group의 DICE(장치 식별자 구성 엔진) 산업 표준을 사용하여 부트 이미지를 지원합니다. 세 번째 옵션을 사용하면 개발자가 PRINCE 암호화를 지원하는 프로세서 플래시의 특수 영역에 이미지를 저장할 수 있습니다. PRINCE 암호화는 다른 암호화와 비슷한 보안 강도를 달성할 수 있지만 훨씬 작은 실리콘 영역을 차지하는 대기 시간이 짧은 블록 암호화입니다. LPC55S69JBD100에서 구현되는 PRINCE 암호화는 프로세서의 전용 PRINCE 플래시 영역에 저장된 암호화된 코드 또는 데이터를 즉석에서 암호 해독할 수 있습니다. 암호 해독에 사용되는 보안 키는 PRINCE 암호화 엔진에서만 액세스할 수 있으므로 이 암호 해독 공정은 안전하게 유지됩니다. 실제로 이 보안 키는 LPC55S69JBD100의 PUF(물리적 복제 불가) 기능에서 생성되는 키 암호화 키(KEK)에 의해 보호됩니다. PUF 및 KEK 사용에 대한 자세한 내용은 2부를 참조하십시오.

이 접근 방식을 사용하면 개발자가 추가 펌웨어 이미지를 저장할 수 있습니다. 이 기능은 장치를 "방해"할 위험 없이 IoT 장치에 펌웨어 무선(FOTA) 업데이트 방법을 제공하는 데 필요합니다. 프로세서에서 펌웨어 이미지를 한 곳에만 저장할 수 있는 경우 펌웨어 이미지에 결함이 발생하면 프로세서가 비확정 상태나 잠금 상태로 전환되어 장치가 잠기거나 차단될 수 있습니다. LPC55S69JBD100의 PRINCE 지원 플래시 영역에 펌웨어 이미지를 저장하면 개발자는 새 버전이 작동되지 않는 상태로 부트될 경우 작동하는 이전 펌웨어 버전을 복원하는 백오프 전략을 사용할 수 있습니다.

모든 새 펌웨어 이미지가 기본 부트 공정에 필요한 서명 확인 검사를 통과해야 하므로 개발자는 보안 FOTA를 최대한 활용하여 시스템 또는 신뢰 체인을 훼손하지 않고 새 기능을 추가하거나 버그를 수정할 수 있습니다.

결론

시스템 및 응용 제품 레벨 보안에서는 인증된 소프트웨어만 작동할 수 있는 실행 환경이 필요합니다. 코드 서명 확인은 이러한 유형의 환경을 지원하는 데 필수적인 기능이지만 보안 시스템에서 신뢰할 수 있는 소프트웨어를 실행하는 데 필요한 신뢰 체인을 구축하려면 더 포괄적인 기능이 필요합니다. 이러한 신뢰할 수 있는 환경은 보안 프로세서에서 지원되는 보안 부트 메커니즘을 통해 제공되는 신뢰점을 기반으로 구축됩니다. 이 클래스의 프로세서를 사용하여 개발자는 시스템에서 소프트웨어 실행을 무력화하거나 전체 시스템을 불법으로 이용하기 위해 고안된 공격을 견딜 수 있는 보안 IoT 장치를 구현할 수 있습니다.