죄송합니다. 더 이상 지원되지 않는 웹 브라우저입니다.

보안 요소를 통한 펌웨어 검증 활용 사례

PDF 다운로드

글/Xavier Bignalet, Microchip Technology 보안 제품 매니저

오늘날 시장에서 임베디드 전자 시스템은 매우 다양하며, 산업용 애플리케이션을 위한 IEC62443 보안 표준이나 애플리케이션 동작의 주요 특성에 따라 달라지는 여러 규정의 대상이 되고 있다. 그러나 보안은 규정 그 이상의 것이며 근본적이고 책임 있는 작업 방식을 구현하는 것이다. 오늘 우리는 작고 제한된 임베디드 시스템에 대한 펌웨어 검증에 대해 논의하고자 한다. 각 임베디드 시스템은 실행되는 코드(펌웨어, 소프트웨어, RTL 등)를 기반으로 동작한다. 

이 글에서는 펌웨어가 공격을 받을 경우 연결된 심박 조율기(pacemaker), 산업용 게이트웨이, IoT 베이비 모니터 또는 산업용 기계의 모터에 어떤 일이 발생할 수 있는지 살펴보겠다.

제품의 코드에는 회사의 수많은 지적 재산(IP)이 상주한다. 연결된 심박 조율기의 코드는 인간의 삶을 제어하며 매우 중요한 역할을 담당한다. 이 심박 조율기 또한 인증 대상이다. 산업용 펌프의 경우 코드는 경쟁 제품보다 속도 및 토크 조절을 더 잘 처리하여 모터 성능을 향상시키는 역할을 한다. 산업용 게이트웨이 코드는 복잡한 스마트 공장 네트워크에서 시장에서 가장 빠른 속도로 매우 큰 페이로드를 처리하도록 설계되었지만, 그 게이트웨이의 뒤에는 머신과 운영업체로 이루어진 산업용 네트워크가 있다. 이는 기계 동작이 변경될 경우 공장 내 개인의 안전 문제를 야기할 수 있다. IoT 베이비 모니터 코드는 네트워크와의 강력한 연결을 보장할 뿐만 아니라 부모에게 아기에 대한 관련 개인 정보를 제공해 준다. 다음은 기업의 코드가 IP에 매우 중요한 영향을 미치는 4가지 이유이다. 기업은 여기에 언급된 다양한 기존 표준에 정의된 위협 모델을 고려해야 한다.

1. 원격 디지털 공격: 익스플로잇(exploit, 취약점을 겨냥해 공격을 실행한다는 의미)이 원격으로 코드에 액세스하여 대상 또는 전체 제품에 영향을 미치는가?

2. 원격 논리 공격: 해커가 네트워크를 통해 원격으로 공격을 확장하는 데 도움이 될 수 있는 코드의 버그에 익스플로잇이 초점을 맞추고 있는가?

3. 로컬 물리적 공격: 해커가 제품에 물리적으로 액세스할 수 있는 경우 버그를 악용하지 않고 코드에 무엇을 실행할 수 있는가?

4. 로컬 논리 공격: 해커가 제품에 물리적으로 액세스할 수 있는 경우 코드 버그에서 악용될 수 있는 것은 무엇인가?

위의 문제를 해결하고자 최근 몇 년 동안 정부와 업계에서는 표준을 확립하기 위해 IoT 보안 규정을 만들기 시작했다. 예를 들어, 산업 시장에서 ISA/IEC62443 표준은 산업 제품을 설계하기 위한 보안 관행을 문서화한다. 유럽에서 추진되는 EN303656은 유럽 정부의 보안 규정 및 지침에 따라 현지 소비자 시장에서 IoT 제품을 판매한다. 소프트웨어 보안 관행에 중점을 두고 시작된 UL2900은 이제 소비자 시장을 위하여 주요 기업에서 검토중이다. 모든 주요 표준 또는 규정 내에서 찾을 수 있는 공통 요구 사항은 코드가 정품인지 확인하도록 권장하는 것이다. 

그렇다면 이 코드를 보호하기 위해 무엇을 할 수 있으며, 그에 따른 장단점은 무엇일까? 코드가 진짜인지 확인하려면 암호화 작업으로 코드를 확인해야 한다. 이러한 검증은 임베디드 시스템 운용 중 다양한 시점에서 수행될 수 있다.

코드의 진위 여부를 언제 확인하나?

1. 부팅 시: 일반적인 기술 용어는 시큐어 부트(secure boot)로, 다이제스트, 서명 또는 전체 코드 이미지만 확인하는 대칭 키 또는 비대칭 키를 사용하여 다양한 방식으로 구현되는 것이다. 보안 부팅 프로세스는 대상 임베디드 디자인에서 정품 코드만 실행되도록 하기 위한 것이다.

2. 런타임 중: 보다 일반적인 용어는 IP 보호(IP protection)이다. 펌웨어 엔지니어는 보안 부팅 및 OTA(Over-The-Air) 업데이트를 제외하고 시스템 동작 중 관련 시점에서 코드 검증을 구현하여 변조되지 않았는지 확인할 수 있다.

3. OTA 업데이트 후: IoT 세계에서 기존 이미지를 대체하기 위해 네트워크를 통해 “무선”으로 새 코드 이미지가 푸시되면 이 새 코드가 실행되기 전에 정품인지 확인해야 한다.

위에서 설명한 세 가지 임베디드 보안 기능은 전반적으로 코드 검증 관행과 관련되어 있다.

이제 구현 기술을 살펴보고 그 장단점을 검토해 보겠다. 기본적으로 코드는 이상적으로 안전한 기업 환경에서 “서명”되어야 하고 임베디드 시스템 내부에서 “검증”되어야 한다. 이러한 “서명” 및 “확인” 작업은 암호화 알고리즘과 대칭 또는 비대칭 키 세트에 의해 수행된다. 아래 다이어그램과 같이 4가지 주요 단계가 있다. 첫 번째는 제조 과정에서 일어나는 일과 코드 암호화 및 서명이 처리되는 방식을 살펴보는 것이다. 두 번째는 코드가 임베디드 시스템에 로드되는 방식이다(보안 로더). 세 번째 단계에서는 코드가 임베디드 시스템으로 다운로드되는 방법을 다룬다. 네 번째 단계는 대상 애플리케이션에서 실행되는 코드가 실제로 정품인지 확인하기 위해 임베디드 시스템이 제조된 후 내부에서 일어나는 일에 초점을 맞춘다.

제조 과정에서의 대칭 키를 사용한 서명 작업

대칭 암호화는 공유 키 아키텍처, 즉 동일한 두 키 쌍(대칭 키 또는 공유 키라고도 함)을 기반으로 한다. 주요 단점은 누군가가 하나의 키에 액세스하는 경우 다른 공유 키가 이와 동일하며, 시스템이 쉽게 실패한다는 것이다. 또한 기본적인 관행은 각 디바이스에 대해 서로 다른 대칭 키를 보유해야 하므로, 이는 전체 장치 집합에 고유한 대칭 키를 프로비저닝할 수 있는 방법이라는 논리 역설을 생성한다. 그 결과 개발자는 구현의 용이성과 프로젝트 일정 제약으로 인해 전체 디바이스 집합에 대해 동일한 대칭 키를 사용하게 되므로 이러한 키에 대한 노출이 악영향을 가져오게 된다. 보다 자세히 살펴보겠다. 첫 번째 단계는 회사 환경에서 발생한다.

• 귀하의 코드는 OEM(Original End Manufacturer)으로서 “해시” 기능을 통해 전달된다. 여기서는 SHA256을 예로 사용하고 있다. 이 해시의 출력은 코드 이미지의 32바이트 다이제스트이다.

• 해당 해시는 대칭 키(OEM 키 서명)를 사용하여 수행된다.

• 출력은 “MAC” 또는 메시지 인증 코드이다.

• MAC은 생산 현장에서 메인 컨트롤러를 플래시할 계약 제조업체(CM)에게 제공된다. MAC과 대칭 키 모두 이 단계에서 CM에 의해 로드된다.

• 키가 절대 노출되어서는 안 되며 제조 중이나 마이크로컨트롤러 내부에서도 절대 노출되어서는 안 되므로, 공급망 취약점이 발생할 수 있다는 점에 유의하십시오. 이 경우 OEM에서 먼저 MAC을 수행하지 않았다면 MAC을 수행할 공장 및 장비 내부의 운영자에게 키가 노출되게 된다.

제조 과정에서의 비대칭 키를 사용한 서명 작업

보다 강력하고 확장 가능한 방법은 대칭 키 대신 비대칭 키를 활용하는 것이다. 비대칭 키는 두 개의 키가 다르지만 암호화 알고리즘에 의해 수학적으로 관련되어 있는 키 쌍이다. 예를 들어 임베디드 시스템에서는 가장 일반적이고 효율적으로 사용되는 알고리즘 중 하나인 ECC-P256을 사용한다. 개인 키는 코드에 서명하고 공개 키(개인 키로 계산)는 서명 및/또는 다이제스트를 확인한다.

제조 과정에서 누가 키에 액세스할 수 있는지 자문해 보자.

대칭 아키텍처를 선택하든 비대칭 아키텍처를 선택하든 스스로에게 몇 가지 중요한 질문을 던져보아야 한다. 이미지를 확인하려면 임베디드 시스템 내부에 암호화 키를 로드해야 하므로 다음을 확인해 보자:

• 서명된 코드를 보호하는 키에 대하여, 계약한 제조업체를 신뢰할 수 있는가? 귀하의 코드는 회사 IP임을 기억하자. 키가 있으면 코드에 액세스할 수 있다.

• CM이 서명 키 또는 확인에 사용된 키에 액세스할 수 있는가? 하나 또는 여러 제조업체를 변경하려는 경우 키는 어떻게 되는가?

• 계약한 제조업체가 키를 소유하고 있다는 이유로 그들에게 의존하고 있는가?

• 여러 계약 제조업체를 고용하는 경우 다양한 키 쌍 세트를 어떻게 관리하는가?

• 계약 제조업체에서 키를 어떻게 보호하는가?  보안 감사 결과는 어떤가?

또한 제조 과정에서 키를 취급하는 흐름과 관련하여 고려해야 할 여러 공급망 질문이 있다. 서명 키는 항상 HSM을 사용하는 것이 이상적이며 모든 사물과 가능한 모든 사람으로부터 격리하는 데 가장 중요한 키이다. 그러나 이제 귀하는 코드에 대한 검증이 매우 중요한 목표인 상황이다. 이는 곧 귀하가 코드를 얼마나 잘 보호하는지에 달린 문제이기 때문이다 (코드는 귀하의 기업 IP임을 잊지 말자). 이제 키는 취약성 노출을 발생시킬 수 있는 계약 제조업체의 손에 달려 있다. 다음에 대해 스스로에게 질문해 보자:

• 키가 안전하게 저장되거나 직원 간에 공유되는지 알고 있는가?

• 제조 장비 네트워크 보호가 열악하여 공장 외부에서도 키에 원격으로 액세스할 수 있는가?

• 직원이 USB 스틱을 사용해 인증 키를 담아 공장을 나가는 것이 가능한가? 이 키가 어떻게 감사 및 신뢰되고 있는가?

• 키를 담당하는 직원이 계약 제조업체에서 퇴사하면 열쇠는 어떻게 되는가?

임베디드 시스템의 키는 어디에 있는가?

기존 마이크로컨트롤러 플래시 내부에 펌웨어를 확인하는 공개 키가 있는지 다시 생각해 보자. 이 경우 암호화는 코드의 바이너리 이미지의 일부가 된다. 예전의 엔지니어는 마이크로컨트롤러나 프로세서의 플래시에 키(공개 또는 대칭)를 로드하기만 했을 것이다. 스스로에게 물어야 할 질문과 생각해야 할 답에 대해 이야기해 보자.

이 키는 얼마나 가치가 있으며 공격자는 이 키를 가지고 무엇을 할 수 있나?

현재로서는 플래시 메모리가 없는 곳에 키를 저장하는 수많은 디바이스가 존재한다. 공격자의 기본 전략 중 일부는 버퍼 오버플로우(예: Heartbleed), HEX 파일 추출 또는 메모리에 있는 키에 액세스하기 위한 여러 방법과 같은 다양한 기술을 사용하여 디바이스 메모리에 액세스하려고 시도하는 것이다. 이는 매우 실제적인 공격이며 여러 기업 시스템에서 이러한 취약점들이 보고되고 있다. 현 시점에서는 확장 가능한 공격을 위한 다양한 시도가 일어나고 있다.

바이너리 이미지에 있는 모든 키에 액세스할 수 있는 경우, 이들은 변경 가능하고 재현 가능해지며 대규모 집합에 대한 원격 액세스가 점점 더 가능해집니다. 앞에서 설명했듯이 대칭 키를 사용하는 것은 코드 서명을 위한 가장 강력한 전략이 아닙니다. 이제 코드가 컨트롤러 내의 OTP 내부에 있는지 확인하는 키를 가정해 보겠다. OTP 접근 방식은 키가 불변 메모리 영역에 있으므로, 시스템을 좀 더 강력하게 만들기 위한 논리적인 첫 번째 단계이다. 변경할 수 없다는 것은 액세스할 수 없거나 읽을 수 없다는 의미가 아니라 단지 이를 변경할 수 없다는 의미이다. 코드의 값은 코드에 얼마나 많은 값 또는 IP가 있는지에 따라 키를 평가하게 된다. 따라서 키에 액세스할 수 있다면 이를 읽고, 복사하고, 재사용할 수 있다. 악성 사용자들 역시 해당 키를 합법적으로 사용하여 자신의 코드를 확인할 수 있게 된다.

• 대칭 키인 경우 특히 시스템이 클라우드에 연결된 경우 최악의 시나리오가 된다. 키에 액세스가 가능해지면 공격자는 이제 악성 코드의 MAC을 수행할 수 있으며, 대칭 키에 서명하는 것은 코드를 확인하는 대칭 키와 동일하므로 checkMAC로도 쉽게 확인할 수 있다. 이에 더해 키 다양화(key diversification)를 사용하지 않은 경우 전체 디바이스에 대한 키를 보유한 사람들의 목록을 검토하는 것이 매우 중요한다. 산업용 머신에 연결된 모든 베이비 모니터가 위조될 수 있고, 모든 OTA 업데이트가 손상될 수 있으며 더 나쁜 상황이 초래될 수 있다.

• 컨트롤러 플래시의 공개 키 또는 액세스 가능한 OTP의 경우 불량 사용자는 이제 키를 복사하고 마음대로 재사용하여 사용자 인증을 합법화하고 추가로 불량 코드를 설치하여 이를 대상 마이크로컨트롤러에서 실행할 수 있게 된다.

대칭 키 아키텍처 대신 공개 키 인프라를 사용하는 것은 코드를 서명하는 개인 키가 다르지만 공개(public) 코드 검증과 수학적으로 관련되어 있기 때문에 훨씬 더 강력하다. 즉, 공개 키에 대한 액세스 권한이 있으면 공격자가 코드의 확인뿐만 아니라 암호 해독이 실행되기 전에 이를 확인하고 트리거할 수 있다. 이 시점에서는 “코드를 봤으니 코드를 변경하고 공개 키로 검증을 우회하면 어떻게 되는가”라는 질문이 나오게 될 것이다. 이 문제를 해결하려면 Microchip 보안 요소인 ECC-P256과 같은 적절한 암호화 가속기와 함께 마이크로컨트롤러 또는 프로세서 내부의 BootROM 기능이 필요하다. BootROM은 컨트롤러가 확인 명령을 실행하는 메모리 영역도 변경할 수 없고 우회할 수 없도록 한다. 그러나 공개 키에 대한 액세스 권한은 여전히 근본적인 문제로 남아 있다.

펌웨어 검증에 대칭 키와 비대칭 키를 사용하는 경우의 장단점은 무엇인가?

이 글에서는 애플리케이션에서 펌웨어 검증을 구현하는 것의 중요성에 대해 자세히 논의했다. 애플리케이션 코드가 정품인지 확인하려면 암호화 작업으로 코드를 확인해야 한다. 부팅 시, 런타임 시, 보안 펌웨어 업그레이드 등 임베디드 시스템 동작 중 다양한 시점에서 검증을 수행할 수 있다. 비대칭 및 대칭 암호화 알고리즘을 사용하여 펌웨어 검증을 구현하는 많은 기술이 존재한다. 이러한 각 기술에는 고유한 장점과 장단점이 있다. 

leekh@seminet.co.kr
(끝)
<저작권자(c) 반도체네트워크, 무단 전재-재배포 금지>