KR20070017455A - 프로세서 내에서의 보호된 리소스들로의 억세스에 대한안전한 보호 방법 - Google Patents

Abstract

본 발명의 컴퓨팅 플랫폼(10)은 제조자 증명서(36)를 이용하여 시스템 펌웨어(30)를 보호한다. 제조자 증명은 시스템 펌웨어(30)를 특정 컴퓨팅 플랫폼(10)에 결합(bind)한다. 보안 런타임 플랫폼 체커(200) 및 보안 런-타임 체커(202)는 그 컴퓨팅 플랫폼(10)의 동작동안 시스템 펌웨어를 체크하여 시스템 펌웨어(30) 및 제조자 증명(36) 내의 정보가 수정되지 않았음을 보장한다. 어플리케이션 소프트웨어 파일(32) 및 데이터 파일(34)은 플랫폼 증명서(38)에 의해 특정 컴퓨팅 디바이스에 결합된다. 테스트 구성으로의 억세스와 같은 디바이스의 임의의 구성으로의 억세스는 패스워드를 입력함으로써 시작된다. 패스워드는 사이즈를 줄이기 위해 해싱 처리를 통해 암호화되고, 해싱되어 컴퓨팅 플랫폼 상에 저장된 억세스 코드와 비교된다.

컴퓨팅 플랫폼, 제조자 증명서, 시스템 펌웨어, 플랫폼 증명서, 해싱 처리

Description

프로세서 내에서의 보호된 리소스들로의 억세스에 대한 안전한 보호 방법{SECURE PROTECTION METHOD FOR ACCESS TO PROTECTED RESOURCES IN A PROCESSOR}

관련 출원의 교차 참조

본 출원은, Balard et al에 의해 2002년 7월 30일 출원된 발명의 명칭이 "펌웨어 런-타임 인증"인 공동계류중인 미국 임시출원번호 제60/399,592호의 이익을 주장한다.

본 출원은 또한 유럽 특허청에서 2002년 12월 10일 출원번호 제02293057.2호의 지적재산권 보호를 위한 파리조약 하에서 우선권을 주장한다. 동일 특허대상에 대한 어떠한 외국 출원도 2002년 12월 10일 이전에 제출된 적이 없다.

기술분야

본 발명은 전체적으로 처리 디바이스, 보다 구체적으로는 보안 컴퓨팅 시스템에 관한 것이다.

오늘날, 컴퓨팅 디바이스는 많은 형태 및 모양들을 갖는다. 전형적인 컴퓨팅 디바이스는 퍼스널 컴퓨터를 포함한다. 최근에는, PDA(personal digital assistants)와 같은 이동 컴퓨팅 디바이스 및 스마트 폰이 컴퓨팅 디바이스와 통신 디바이스 간의 구별을 흐리게 하고 있다. 또한, 컴퓨팅 디바이스는 자동차 내부의 콘트롤러와 같은 사용자에게 실제로 보이지 않는 방식으로 이용되고 있다.

컴퓨팅 디바이스의 제조자, 또는 프로세서와 같은 컴퓨팅 디바이스의 부품들은 지금까지 그 디바이스의 동작에 보안을 제공할 수 없었다. 잘 공지되어 있는 일특정 보안 위험요소는 제3자에 의한 컴퓨터 디바이스로의 공격을 포함한다. 각종 기술을 사용하여, 공격자들은 시스템 파일, 어플리케이션 파일 또는 그 컴퓨팅 디바이스 내의 데이터를 변경할 수 있다. 어떤 경우에는, 그 공격들은 단지 성가신 것일 뿐이나, 또 어떤 경우에는, 소유자에게 엄청난 비용 손실을 초래할 수 있다.

컴퓨팅 디바이스의 승인되지 않은 모든 변경들이 제3자에 의해 야기되는 것은 아니다. 컴퓨팅 디바이스의 의도된 동작들의 몇몇 변경들은 사용자에 의해 야기된다. 예를 들어, 사용자는 디바이스의 동작을 "향상"시키기 위해 때때로 인증되지 않은 소프트웨어로 디바이스의 지정되어 있는 설정을 변경할 수 있다. 어떤 경우에는 자동차의 콘트롤러에 대한 펌웨어의 변경과 같은 것은 매우 위험할 수 있다.

또 어떤 경우에는, 사용자는 제1 디바이스로부터 제2 디바이스로 데이터 또는 프로그램을 송신하기를 원할 수 있다. 이는 저작권 제한에 기인하여 부적절할 수 있으며, 안정하지 못한 플랫폼으로 소프트웨어를 이동시키는 것을 포함할 수 있다.

제조자들은 점점더 시스템 펌웨어, 소프트웨어 및 데이터의 시초(origin) 및 무결성(integrity)을 입증할 필요가 있음을 인식하고 있다. 일부 메카니즘은 소프 트웨어 제공자의 시초를 입증하기 위해, 디지털 증명서와 같이 일부적으로 성공을 거두었으나, 이러한 방법들은 특히 매우 기교있는 공격자 또는 사용자에 의해 완전하게 입증되지 못하며, 쉽게 피해갈 수 있다.

따라서, 보안 컴퓨팅 플랫폼의 필요성이 제기되었다.

발명의 개요

본 발명에서는, 공지된 메모리 위치 내의 암호화된 억세스 코드를 그 컴퓨팅 디바이스에 저장함으로써 컴퓨팅 디바이스 내의 리소스로의 억세스를 방지한다. 리소스에 억세스하기 위한 패스워드를 컴퓨팅 디바이스에 수신하여, 그 패스워드를 암호화함으로써 암호화된 패스워드를 생성한다. 암호화된 패스워드는 암호화된 억세스 코드와 비교되며, 그 암호화된 억세스 코드가 암호화된 패스워드와 일치할 경우에만 리소스로의 억세스가 허용된다.

본 발명은 종래 기술에 비해 현저한 이점을 제공한다. 암호화된 억세스는 패스워드보다 훨씬 작아질 수 있으므로, 억세스 코드 정보를 저장하는데 필요한 메모리 양을 현저하게 줄일 수 있지만, 억세스를 얻는데 필요한 패스워드는 풀사이즈로 남게 된다.

본 발명 및 그 이점들의 보다 완벽한 이해를 위해, 이제 첨부 도면과 관련하여 다음 상세한 설명을 참조할 것이다.

도 1은 이동 컴퓨팅 환경에서 펌웨어, 어플리케이션 소프트웨어 및 데이터를 보호하는데 사용되는 각종 보호 메카니즘을 도시하는 기본적인 블록도.

도 2는 도 1에 도시된 제조자 증명서에 대한 바람직한 실시예를 도시하는 도면.

도 3은 보안 부트 로더 및 보안 부트 체커 프로그램에서의 제조자 증명서의 사용을 도시하는 플로우차트.

도 4는 제조자 증명서에 저장된 제조자의 공개 키의 인증을 설명하는 플로우차트.

도 5는 제조자 증명서 내의 증명 서명 필드의 인증을 설명하는 플로우차트.

도 6은 제조자 증명서 내의 발안자(originator)의 공개 키의 인증을 설명하는 플로우차트.

도 7은 제조자 증명서과 결합된 펌웨어를 인증하는 플로우차트.

도 8은 제조자 증명서 내의 다이 식별 코드 입증을 설명하는 플로우차트.

도 9는 보안 런타임 플랫폼 데이터 체커 및 보안 런타임 체커의 동작을 설명하는 플로우차트.

도 10은 플랫폼 증명을 통해 어플리케이션 파일 또는 데이터 파일이 컴퓨팅 플랫폼에 결합되어 있음을 도시하는 도면.

도 11은 어플리케이션 또는 데이터 파일이 어플리케이션을 실행하거나 어플리케이션 내의 데이터 파일을 사용하는데 필요한 플랫폼 증명서로부터 결합되어 있지 않음을 설명하는 도면.

도 12는 외부 메모리 내의 IMEI(International Mobile Equipment Identity) 수를 안전하게 저장하기 위해 제조자 및/또는 플랫폼 증명서의 특정 사용을 설명하 는 도면.

도 13은 디바이스의 동작을 제어하기 위해 제조자 증명서 내의 필드를 사용하는 블록도.

도 14는 구성 데이터가 플랫폼 증명에 의해 보호되는 데이터 파일 내에 저장되는 도 13의 변형을 도시하는 도면.

도 15는 디바이스(10)를 억세스하기 위한 대안의 설계는 테스트 모드와 같은 임의의 모드임을 도시하는 도면.

본 발명은 도 1 내지 도 15를 참조하면 잘 이해될 수 있으며, 여러 도면에서의 같은 구성요소에 대해서는 같은 참조번호가 사용되었다.

도 1은 이동 컴퓨팅 환경에서 펌웨어, 어플리케이션 소프트웨어 및 데이터를 보호하는데 사용되는 각종 보호 메카니즘을 도시하는 기본적인 블록도를 도시한다. 본 발명은 이동전화 또는 PDA와 같은 이동 컴퓨팅 디바이스에 관해서 논의되고 있지만, 다른 컴퓨팅 디바이스에도 적용가능하다.

도 1의 이동 컴퓨팅 디바이스(10)의 회로는 3개의 큰 블록으로 분할된다. 이는 기저대역 처리 시스템(12), 외부 비휘발성 메모리(14) 및 RF(무선 주파수) 시스템(16)이다. 기저대역 처리 시스템은 RF 변조에 앞서 데이터를 처리할 의무가 있다. 도 1에서, 기저대역 처리 시스템(12)에는 SRAM(정적 랜덤 억세스 메모리)(20), ROM(리드 온니 메모리)(22) 및 퓨즈를 갖는 메모리 어레이(eFuse)(24)를 포함하는 내부 메모리 서브시스템(18)이 임베딩되어 있다. 범용 처리기, 디지털 신 호 처리기 및 보조 처리기와 같은 하나 이상의 처리 디바이스(26)가 내부 메모리 서브시스템(18)에 결합된다. 입출력(I/O) 회로(28)는 처리기(들)(26) 및 내부 메모리 서브시스템(18)에 결합된다.

펌웨어(30), 어플리케이션 소프트웨어(32) 및 데이터 파일(34)는 외부 비휘발성 메모리 시스템(14)에 저장된다. 펌웨어(30)는 판매 전에 제조자에 의해 디바이스에 저장되는 기본 시스템 코드이다. 펌웨어(30)는, 기능을 추가하거나 에러를 정정하기 위해 제조자에 의해 업데이트 될 수도 있지만, 플랫폼 상에 영구적으로 존재한다. 많은 경우에, 제조자에 의해 디바이스(10) 상에 배치된 펌웨어(30)만을 사용해야 하며, 그 펌웨어가 제조자 이외의 누군가 또는 제조자의 권한하에서 일하는 누군가에 의해 변경되거나 대체되지 않아야 하는 것은 매우 중요하다. 그러므로, 펌웨어(30)에 관해 보안이 특히 중요시되는 문제이다. 부가적으로, 인증되지 않은 펌웨어는 실행하지 않는 것이 중요하다. 보안은 또한 어플리케이션 소프트웨어(32) 및 데이터 파일(34)에 관해서도 문제가 될 수 있다. 어플리케이션 소프트웨어(32) 및 데이터 파일(34)에 대해, 이 파일들의 무결성을 보장하는 것이 종종 중요시된다; 예를 들어, 파일들이 다른 "바이러스" 소프트웨어에 의해 변경, 삭제 또는 대체되지 않도록 보장하는 것이 바람직하다. 또한, 기초 작업의 소유주의 저작권을 보호하기 위해 어플리케이션 (음악 및 비디오 파일과 같은) 소프트웨어(32) 및 데이터 파일(34)의 복제를 방지하는 것이 종종 중요시된다.

도 1에 도시된 바와 같이, 종종 쉽게 억세스할 수 있는 외부 메모리의 내용을 방지하는데 두가지 형태의 보호 메카니즘이 사용될 수 있다. 펌웨어에 관해, " 제조자" 증명서(36)는 펌웨어를 특정 컴퓨팅 디바이스(10)에 결합한다 (다수의 제조자 증명서가 각각의 펌웨어 태스크에 결합될 수 있다). 마찬가지로, 어플리케이션 소프트웨어(32) 및 데이터 파일(34)은 각각의 "플랫폼" 증명서(38)에 의해 특정 컴퓨팅 디바이스(10)에 결합된다. 이하 상세히 기술되는 이러한 증명서들은 펌웨어, 어플리케이션 소프트웨어 및 데이터의 변경을 방지하고(그리고, 이들의 기밀성을 선택적으로 보존하고), 그러한 펌웨어, 어플리케이션 소프트웨어 및 데이터를 다른 디바이스에 복제하는 것을 방지하는데 사용될 수 있다.

본 명세서에 기술된 보안 특징은 몇몇 암호화 기술을 사용한다. "대칭-키(symmetric-key)"(또는 "비밀 키") 암호화에서는, 동일한 비밀키가 암호화 및 해독 모두에 사용된다. 대칭키 암호화의 일례는 DES(Data Encryption Standard)이다. "비대칭"(또는 "공개키") 암호화에서, 비밀 키 및 공개 키의 한쌍의 키가 사용된다. 키 생성 알고리즘은 일치된 키 쌍을 생성하므로, 그 정보는 공개 키(예상 송신자에게 발행될 수 있음)를 사용하여 암호화되어 개인 키(수신자에 의해 비밀로 유지됨)를 사용하여 해독될 수 있으며, 역으로, 개인 키로 암호화된 정보는 공개 키로 해독될 수 있다. 공개 키로부터 개인 키를 추론하는 것은 계산적으로는 실현할 수 없다. 비대칭 암호시스템(asymmetric cryptosystem)을 사용하면, 그 개인 키가 보안 채널을 통해 송신될 필요가 없기 때문에, 어떤 이전의 보안 배치를 갖고 있지 않은 사람도 정보를 교환할 수 있다. RSA 암호화(RSA 시큐러티, 인크에 의해 개발됨)는 공개 키 암호화의 일례이다.

단방향 해시 함수(one-way hash function)는 가변 길이 입력을 취하여 "메시 지 다이제스트(message digest)" 또는 "해시"로서 공지되어 있는 고정 길이 출력을 생성한다. 그 해시 함수는 정보가 임의의 방식으로 변경될 경우, 전체적으로 다른 출력 값이 생성됨을 보장한다. 해시 알고리즘은 통상적으로 데이터의 무결성 입증시 사용된다. SHA-1(160 비트 해시) 및 MD5(128 비트 해시)는 단방향 해시 함수의 예들이다.

디지털 서명은 정보의 수신인이 정보 발안의 신뢰성을 입증하고, 또한 그 정보가 변하지 않았음을 입증할 수 있도록 한다. 통상적으로, 송신자는 해시를 계산하고 송신자의 개인 키로 그 해시를 암호화함으로써 메시지에 서명한다. 수신인은 송신자의 공개 키로 그것을 해독하고(그러므로 송신된 해시를 획득하고), 그 수신된 메시지의 해시를 계산하여, 그 둘을 비교함으로써 그 메시지 상의 서명을 입증한다. 그러므로, 공개 키 디지털 서명은 인증 및 데이터 무결성을 제공한다. 디지털 서명은 또한 송신자가 정보의 시초를 포기하는 것을 방지한다는 의미인 부인 방지(non-repudiation)를 제공한다. DSA(디지털 서명 알고리즘)은 디지털 서명 암호시스템의 일례이다.

공개 키 암호시스템의 한가지 문제점은 (공격자가 데이터 스트림 내의 패킷들을 가로채어, 그 패킷들을 변경하고, 최초의 송신자가 될 것을 요구함으로써 그들이 의도한 목적지로 전달하는) 끼어들기(man-in-the-middle) 공격에 대해 보호되도록 사용자가 정정 공개 키(correct public key)를 암호화 또는 해독하고 있음을 보장하기 위해 끊임없이 주의해야 한다는 것이다. 디지털 증명서는 공개 키가 정평이 나 있는 소유자의 진짜 소유자인지를 확인하는 태스크를 간소화하는 디지털 허가증 또는 증명서의 형식이다. 가장 간단한 형태로서는, 증명서는 증명서 권한자와 같은 신뢰된 누군가에 의해 디지털로 서명된 사용자 공개 키이다. 증명서는 또한 버전 수, 사용자 ID 수, 만료일 등과 같은 부가적인 정보를 포함할 수 있다.

임의의 코드 및 키들은 다른 보안 특징을 위해 기저대역 처리 시스템(12) 상에 내부적으로 유지된다. 몇몇 시스템 프로그램은 임의의 악성 기질을 방지하기 위해 ROM(22)에 위치된다. 프로그램은 (도 3에 관하여 상세하게 기술된) 보안 부트 로더, (도 3에 관하여 상세하게 기술된) 보안 리셋 부트 체커, (도 9에 관하여 상세하게 기술된) 보안 런타임 플랫폼 데이터 체커, (도 9에 관하여 상세하게 기술된) 보안 런타임 체커, (도 10 및 도 11에 관하여 상세하게 기술된) 보안 런타임 로더 및 데이터 암호화 및 해싱을 지원하기 위해 각종 암호화 소프트웨어를 포함한다. 암호화 기술의 일부 또는 전부는 전용 암호화 처리기에 관련하여 수행될 수 있다.

또한, 바람직한 실시예에서, 임의의 시스템 데이터는 eFuse Array(24)(또는 기저대역 처리 시스템(12) 내부의 다른 영구적인 메모리) 상에 유지된다. 데이터가 어레이에 기입된 후에는, 특정 위치로의 추가적인 기입이 디스에이블되므로, 데이터가 겹쳐쓰기될 수 없다.

다이 식별 번호는 각 개별 디바이스와 연관된 고유의 번호이다. 바람직한 실시예에서, 이 번호는 제조시에 eFuse 어레이(24)에서 DIE_ID_FUSE로 저장된다. 이 식별 코드는 비밀로 간주되지 않으며, 비보안(non-secure) 소프트웨어에 의해 판독될 수 있다.

제조자의 공개 키("제조자"는 디바이스(10)의 제조자임)는 또한 H_Man_Pub_Key로 해싱한 후에 eFuse 어레이(24)에 저장된다. 제조자의 공개 키가 비밀이 아니기 때문에, H_Man_Pub_Key를 저장하는 위치는 외부 억세스로부터 보호될 필요가 없지만; 기입 후에는 변경이 방지되어야 한다. H_Man_Pub_Key의 사용은 도 4에 관하여 보다 상세하게 논의된다. 제조자의 공개 키의 해싱이 선택적인 것임을 주의해야 하며; 해싱은 조밀하고 긴 키에 사용되어 키를 저장하는데 필요한 메모리 양을 줄인다.

테스트 ID 또는 다른 억세스 ID가 또한 해싱되어 eFuse 어레이(24) 내에 저장될 수 있다. 해싱된 테스트 ID(H_Test_ID)는 테스트 모드에서의 인증되지 않은 디바이스로의 억세스를 방지하는데 사용될 수 있으며, 임의의 보호들이 디스에이블된다. 이러한 양상은 도 15에 관련하여 보다 상세하게 논의된다.

키 암호화 키(KEK)는 디바이스 제조시에 기저대역 처리기 내부의 랜덤수 발생기에 의해 바람직하게 생성된 비밀 키이다. KEK는 eFuse 어레이(24)에 저장되고, 변경불가, 즉 외부 억세스 불가이다. 그러므로, 특정 디바이스에 대한 KEK는 심지어는 제조자에 의해서도 결정될 수 없다. KEK는 도 10 및 도 11에 관련하여 보다 상세하게 기술되는 바와 같이, 플랫폼 증명(38)에 대한 부가적인 암호화 키들을 동적으로 제공하는데 사용된다.

도 2는 제조자 증명서(36)에 대한 바람직한 실시예를 도시한다. 특정 디바이스에 대한 제조자 증명서(36)는 도 2에 도시된 실시예보다 더 많은 필드를 포함할 수도 있고 더 적은 필드를 포함할 수도 있음을 이해해야 한다. 도 2의 제조자 증명서(36)에 대한 필드의 요약이 표 1에 기술된다.

제조자 증명서

필드명	함수	보안
CERT_SIZE	증명서 사이즈(바이트단위)
CERT_TYPE	증명서 형태: 제조자
DEBUG_REQ	디버그 요청
CODE_ADDR	증명할 코드가 저장된 어드레스
CODE_SIZE	소프트웨어 모듈의 사이즈(바이트 단위)
CODE_START_ADDR	소프트웨어 입력 포인트의 어드레스
MAN_PUB_KEY	제조자의 공개 키
ORIG_PUB_KEY	발안자의 공개 키
ORIG_PUB_KEY_SIG	제조자에 의한 발안자의 공개 키 서명	제조자의 개인 키를 이용하여 해싱되어 암호화된 발안자의 공개 키
SW_SIG	발안자에 의한 소프트웨어 서명	발안자의 개인 키를 이용하여 해싱되고 암호화된 첨웨어 코드
DIE_ID	다이 ID 번호
CONF_PARAM	플랫폼 구성 파라미터: - DPLL 주파수 - 메모리 억세스 대기상태 RF 파라미터(필터, 이득) 또는 배터리 관리 파라미터(충전 곡선)과 같은 HW 구성 파라미터의 초기치
PLATFORM_DATA	하드웨어 플랫폼에 관련된 데이터 - IMEI 번호
SIG_CERT	제조자에 의한 증명서 서명	제조자의 개인 키를 이용하여 해싱되고 암호화된 제조자 증명서 필드

증명서 사이즈(CERT_SIZE) 및 증명서 형태(CERT_TYPE) 필드는 제조자 증명서(36)의 사이즈와 형태(즉, "제조자")를 나타낸다. 디버그 요청(DEBUG_REQ)은 제조자에 의해 설정되어 그 디바이스 상의 에뮬레이션을 인에이블 또는 디스에이블할 수 있다. 이하에 기술된 바와 같이, 제조자만이 이 필드의 값을 설정할 수 있다. 코드 어드레스(CODE_ADDR) 필드는 외부 메모리(14)의 코드의 시작 어드레스를 나타낸다. 코드 사이즈 필드(CODE_SIZE)는 펌웨어의 사이즈(바이트 단위)를 나타낸다. 코드 스타팅 어드레스(CODE_START_ADDR)는 실행시 펌웨어의 엔트리 포인트를 나타낸다.

제조자 증명서(36)는 제조자의 공개 키(MAN_PUB_KEY) 및 소스트웨어 발안자의 공개 키(ORIG_PUB_KEY)를 더 포함하며; 이는 펌웨어가 자체 서명으로 제3자에 의해 생성되는 것으로 가정한 것이다. 펌웨어가 제조자에 의해 생성되면, 제조자의 제2 공개 키는 선택적으로 사용될 수 있다. 발안자의 공개 키에 대한 서명은 제조자의 개인 키(MAN_PRI_KEY)를 이용하여 ORIG_PUB_KEY를 해싱하고 그 해싱된 ORI_PUB_KEY를 암호화함으로써 생성된다.

소프트웨어 서명은 발안자의 개인 키(ORIG_PUB_KEY)를 이용하여 펌웨어(30)의 코드를 해싱하고 결과의 해싱된 코드를 암호화함으로써 생성된다. ORIG_PRI_KEY는 발안자 개인의 소유이므로, SW_SIG는 발안자에 의해 제조자에게 제공되어야 한다.

특정 디바이스(10)의 DIE_ID는 제조자 증명서(36)에 추가된다. 이는 펌웨어를 다른 디바이스에 복제하는 것을 방지하기 위해 코드를 단일의 디바이스에 결합한다.

구성 파라미터가 제조자 증명서(36)의 CONF_PARAM 필드에 설정된다. 도 13 및 도 14에 관련하여 기술된 바와 같이, 이 필드 내의 정보는 디바이스(10)의 기능성을 설정하는데 사용될 수 있다. 예를 들어, CONF_PARAM 필드 내의 파라미터들은 DPLL(digital phase lock loop) 주파수, 메모리 억세스 대기 상태, RF 회로(16) 내의 필터 및 이득 값 및 (충전 곡선과 같은) 배터리 관리 파라미터를 설정하는데 사용될 수 있다.

특정 디바이스에 고유한 데이터는 PLATFORM_DATA 필드에 저장될 수 있다. 예를 들어, IMEI 번호는 이 필드 내에 저장될 수 있다. 이러한 양상은 도 12와 관련하여 보다 상세하게 설명된다.

제조자 증명서 서명(SIG_CERT)은 제조자 증명서(36)의 임의의 필드로의 간섭을 방지한다. SIG_CERT는 제조자 증명서의 다른 필드를 해싱하여 그 해싱된 코드를 MAN_PRI_KEY로 암호화함으로써 생성된다.

도 3은 보안 부트 로더(50) 및 보안 부트 체커 프로그램(52)에서 제조자 증명서(36)를 사용하는 것을 도시하는 플로우차트이며, 프로그램 플로우가 변경하는 것을 방지하기 위해 바람직하게는 ROM(22)에 저장된다. 보안 부트 로더는 부트 시스템 펌웨어가 파워업시에 업로딩을 위해 이용가능한지를 판정한다. 그렇다면, 보안 부트 로더는 우선 플래쉬 프로그래머를 로딩한다. 그 플래쉬 프로그래머는 시스템 부트 펌웨어를 로딩하는데 사용된다. 플래쉬 프로그래머는 또한 제조자 증명서(36)를 가져야 하고, 보안 부트 로더는 그 플래쉬 프로그래머의 제조자 증명서 및 그 플래쉬 프로그래머의 임의의 실행 이전에 플래쉬 프로그래머 프로그램 코드의 신뢰성 및 무결성을 보장할 의무가 있다. 이어서, 플래쉬 프로그래머는 시스템 부트 펌웨어를 업로드한다.

보안 리셋 부트 체커(52)는 실행 전에 외부 메모리(14)에 저장된 시스템 부트 펌웨어(및 임의의 다른 펌웨어)의 증명서의 신뢰성 및 무결성을 체크한다. 보안 부트 로더(50) 또는 보안 리셋 부트 체커(52)의 실행시, 디바이스(10)는 완료 이전에 실행의 임의의 중단 또는 다른 바이패스를 허용하지 않도록 구성된다.

단계 54에서, 보안 부트 로더(50) 및 보안 리셋 부트 체커(52)는 파워온 또는 시스템 리셋을 대기한다. 단계 56에서, 파워온 또는 시스템 리셋시, 보안 부트 로더(50)가 인터페이스 물리 버스 상의 동기화 신호를 위해, UART(universal asynchronous receiver/transmitter)와 같은 선택된 인터페이스를 점검한다. 타임아웃 또는 와치도그(watchdog) 리셋(단계 58) 후에 물리 버스 상에서 어떠한 동작도 검출되지 않는다면, 어떠한 시스템 펌웨어 다운로드도 얻을 수 없으며 제어가 보안 리셋 부트 체커(52)로 스위칭할 것으로 예상된다.

다운로드 동작이 물리 버스 상에서 검출된다고 추측하면, 단계 60 내지 70은 플래쉬 프로그래머의 임의의 실행에 앞서 플래쉬 프로그래머의 제조자 증명서(36)를 점검한다. 단계 60에서, 플래쉬 프로그래머의 제조자 증명서로부터의 제조자의 공개 키(MAN_PUB_KEY)가 인증된다. MAN_PUB_KEY의 인증이 도 4에 도시된다.

도 4는 제조자 증명서(36)에 저장된 바와 같은 제조자의 공개 키의 인증을 기술하는 플로우차트를 도시한다. 단계 100에서, 펌웨어(이 경우, 플래쉬 프로그래머)의 제조자 증명서로부터의 MAN_PUB_KEY가 해싱되고, 단계 102에서, 그 결과의 해시는 eFuse 메모리 어레이(24)로부터 H_MAN_PUB_KEY와 비교된다. 단계 104에서 일치가 존재하면, 인증은 "통과"로 리턴하며; 그렇지 않으면, 실패가 리턴된다.

대안의 실시예에서, 제조자의 공개 키에 대한 해싱된 값은 제조자 증명서(36)에 저장되며; 이 경우, 해싱 단계(100)는 생략될 수 있다. 또한, 해싱된 제조자 공개 키의 소정수의 최하위 비트만이 eFuse 메모리(14)에 저장될 수 있으며; 이 경우, 해당 비트들만이 단계 104에서 비교될 것이다.

다시 도 3을 참조하면, 제조자의 공개 키의 인증이 단계 62에서 "실패"가 되면, 단계 64에서 처리가 중단되고, 플래쉬 프로그래머의 로딩은 중지된다. 디바이스(10)는 리셋되고 플래쉬 프로그래머의 다운로딩은 재시도될 수 있다.

제조자 공개 키의 인증이 단계 62에서 "통과"가 되면, 단계 66에서 증명서 서명(SIG_CERT)이 인증된다.

도 5는 SIG_CERT 인증을 설명하는 플로우차트를 도시한다. 단계 110에서, SIG_CERT 필드와는 다른 제조자 증명서(36)의 필드는 해싱된다. 단계 112에서, 제조자 증명서(36)의 SIG_CERT필드는 MAN_PUB_KEY를 이용하여 해독된다. 제조자 증명서의 인증은 MAN_PUB_KEY의 인증 후에 수행되며; 따라서, SIG_CERT는 처음에 제조자의 개인 키를 이용하여 암호화된 경우에만 적절하게 해독될 수 있다. 단계 110으로부터의 증명서의 해시는 단계 114에서 해독된 SIG_CERT와 비교된다. 단계 116에서 일치가 존재한다면, 인증이 통과되고, 그렇지 않으면, 실패된다. 실패된 인증은 펌웨어에 대한 제조자 증명서(36)의 하나 이상의 필드가 변경되었음을 나타낸다.

다시 도 3을 참조하면, 제조자 증명서 서명의 인증이 단계 68에서 "실패"가 되면, 처리는 단계 64에서 중단되고, 플래쉬 프로그래머의 로딩은 중지된다. 디바이스(10)는 리셋되고 플래쉬 프로그래머의 다운로딩은 재시도될 수 있다.

제조자 증명서 서명의 인증이 통과된다고 가정하면, 단계 70은 제조자 증명서(ORIG_PUB_KEY)의 발안자 공개 키를 인증하고, 발안자의 공개 키 및 소프트웨어 서명(SW_SIG)에 대해 실제 펌웨어 코드를 인증한다.

도 6은 ORIG_PUB_KEY의 인증을 설명하는 플로우차트를 도시한다. 단계 120에서, ORIG_PUB_KEY는 MAN_PUB_KEY를 사용하여 해독된다. 제조자 증명서(36)의 ORIG_PUB_KEY 필드는 단계 122에서 해싱되어 단계 124에서 해독된 서명과 비교된다. 판정 블록(126)에서 일치가 존재하면, 인증은 통과되고; 그렇지 않으면 실패되어, ORIG_PUB_KEY 또는 ORIG_PUB_KEY_SIG 중 하나가 변경되었음을 나타낸다.

도 7은 제조자 증명서(36)에 결합된 펌웨어를 인증하는 플로우차트를 도시한다. 단계 130에서, 제조자 증명서(36)의 SW_SIG 필드는 이전에 인증된 ORIG_PUB_KEY를 사용하여 해독된다. 단계 132에서, 펌웨어(30)는 해싱된다. 결과적인 해시는 블록(134)에서 해독된 서명과 비교된다. 판정 블록(136)에 일치가 존재하면, 인증은 통과되고; 그렇지 않으면, 실패되어, 펌웨어가 변경되었음을 나타낸다.

다시 도 3을 참조하면, 발안자의 공개 키 또는 펌웨어(이 경우, 플래쉬 프로그래머) 중 하나의 인증이 단계 72에서 실패하면, 처리는 단계 64에서 중단되고, 플래쉬 프로그래머의 로딩은 중지된다. 디바이스(10)는 리셋되고 플래쉬 프로그래머의 다운로딩은 재시도될 수 있다.

모든 인증 테스트가 통과되면, 플래쉬 프로그래머는 블록(74)에서 실행한다. 플래쉬 프로그래머는 시스템 부트 소프트웨어를 로딩하여 단계 76에서 강제로 리셋한다. 통상적으로, 플래쉬 프로그래머는 리셋 이전에 메모리로부터 삭제된다.

보안 리셋 부트 체커(52)는 판정 블록(58)에서 타임아웃 후에 실행될 것이다. 이는 보통 플래쉬 프로그래머 실행의 완료 후(다른 펌웨어 다운로드가 존재하지 않으면) 또는 진행중인 어떤 펌웨어 다운로드도 없는 경우 파워온 또는 리셋 후에 발생할 것이다. 보안 리셋 부트 체커는, 보안 부트 로더의 동작과 관련하여 논의된 바와 같이, 플래쉬 프로그래머의 제조자 증명서와는 대조적으로, 시스템 부트 소프트웨어의 필드들을 인증한다.

단계 78에서, 시스템 부트 소프트웨어와 연관된 제조자 증명서(36)의 제조자 공개 키는 도 4에 도시된 인증 처리를 사용하여 인증된다. 인증이 판정 블록(80)에서 실패하면, 처리는 블록(64)에서 중단된다.

판정 블록(80)에서 제조자 공개 키 인증이 통과되면, 블록(82)에서 시스템 부트 펌웨어 증명서(CERT_SIG)가 인증된다. 펌웨어 증명서의 인증이 도 5에 도시된다. 판정 블록(84)에서 인증이 실패하면, 블록(64)에서 처리가 중단된다.

판정 블록(84)에서 펌웨어 증명서 인증이 통과되면, 발안자의 공개 키(ORIG_PUB_KEY)는 블록(86)에서 인증된다. 발안자의 공개 키 인증은 도 6에 도시된다. 판정 블록(88)에서 인증이 실패하면, 블록(64)에서 처리가 중단된다.

판정 블록(88)에서 발안자 공개 키 인증이 통과되면, 블록(90)에서 시스템 부트 펌웨어가 인증된다. 펌웨어의 인증은 도 7에 도시된다. 판정 블록(92)에서 인증이 실패하면, 블록(64)에서 처리가 중단된다.

판정 블록(92)에서 펌웨어 인증이 통과되면, 블록(94)에서 다이 식별 코드가 증명된다. 도 8은 다이 식별 코드 증명을 설명하는 플로우차트이다. 단계 140에서, 제조자 증명서(36)의 DIE_ID 필드가 "0"으로 설정되면, "0"이 리턴된다. 그렇지 않으면, DIE_ID 필드는 eFuse 메모리(14)에 저장되어 있는 DIE_ID_FUSE와 비교된다. 두 개의 필드가 일치하는지의 여부를 나타내는 값이 리턴된다.

다시 도 3을 참조하면, DIE_ID 필드가 "0"으로 설정되면, 다이 ID 유효 상태가 리턴되어 처리는 블록(96)으로 진행한다.

DIE_ID필드가 "0"으로 설정되지 않고, 제조자 증명서(36) 내의 다이 ID가 eFuse 메모리(24) 내의 DIE_ID_FUSE와 일치하지 않으면, 임의의 특징임이 디스에이블될 수 있지만; 긴급 호출 기능과 같은 일부 특징들을 여전히 이용가능하다.

보안 부트 로더 및 보안 리셋 부트 체커는 단지 유효 펌웨어가 제조시 또는 업그레이드동안 디바이스(10) 상에 로딩됨을 보장한다. 제조자의 개인 키를 이용한 암호화 없이는 어떠한 시스템 펌웨어도 로딩될 수 없기 때문에, 저장된 펌웨어의 사용자 또는 제3자 변경 또는 대체가 방지된다.

펌웨어의 설치가 보호되어 있음에도 불구하고, 펌웨어의 실행동안 펌웨어의 변경 또는 특정 데이터의 변경을 방지하기 위한 부가적인 방법이 취해진다. 이러한 부가적인 보안은 실행 특권을 변경함으로써 디바이스에 저장된 데이터의 공개 또는 인증되지 않은 펌웨어에 의한 디바이스(10)의 재사용을 방지한다.

디바이스(10)의 동작동안, 그 시스템 펌웨어를 로딩한 후에, 보안 런타임 플랫폼 데이터 체커 및 보안 런타임 체커는 시스템 소프트웨어가 변경되지 않도록 보장하며, 시스템 소프트웨어의 제조자 증명서(36)의 PLATFORM_DATA 필드에 제공되어 있는 설정을 보장한다.

도 9는 보안 런타임 플랫폼 데이터 체커 및 보안 런타임 체커의 동작을 설명하는 플로우차트이다. 보안 런타임 플랫폼 데이터 체커(200)는 제조자 증명서(36)의 PLATFORM_DATA 필드에 저장되어 있는 디바이스(10)와 연관된 특정 데이터의 변경을 방지한다. 보안 런타임 체커(202)는 펌웨어의 변경 또는 스와핑(swapping)을 방지한다.

단계 204에서, 보안 서비스 호출이 개시된다. 바람직한 실시예에서, 보안 서비스 호출이 처리기(들)(26)의 휴지 기간의 삭제시에 개시되어, 체커(200 및 202)가 다른 어플리케이션과의 최소의 간섭을 야기하도록 한다. 이러한 보안 서비스 호출은 또한 이용가능 휴지 기간에 무관하게 서비스 호출이 프리셋 타임동안 수행됨을 보장하는 온칩 하드웨어 타이머로부터 개시될 수도 있다. 그 프리셋 타임은 제조자 증명서(36)의 CONFIG_PARAM 필드에 저장된 구성 파라미터에 따른 부트 시간으로 구성될 수 있다. 또한, 보안 서비스 호출은 소프트웨어 어플리케이션으로부터의 요청시 개시될 수 있다. 일단 보안 서비스 호출이 개시되면, 모든 인터럽트는, 보안 런타임 플랫폼 데이터 체커(200) 및 보안 런타임 체커(202)를 실행하는 처리기가 완료시까지 체커 태스크의 실행으로부터 인터럽트될 수도 벗어날 수도 없도록 디스에이블된다.

보안 런타임 플랫폼 데이터 체커에 관해, 도 4에 관련하여 앞서 기술된 바와 같이, 단계 206에서, 제조자 증명서(36)에 저장된 제조자의 공개 키(MAN_PUB_KEY)가 인증된다. MAN_PUB_KEY를 인증하는 것은 이후의 인증 단계동안 잘못된 공개 키/개인 키의 조합으로 대체되는 것을 방지한다.

제조자의 공개 키 인증이 단계 208에서 실패한다면, 보안 런타임 플랫폼 데이터 체커 처리(200)는 중단되고 디바이스는 단계 210에서 리셋된다.

제조자의 공개 키 인증이 단계 208에서 통과된다고 가정하면, 시스템 부트 펌웨어 증명서는 단계 212에서 인증된다. 시스템 부트 펌웨어 증명서의 인증은 앞서 도 5에 관련하여 기술된 바와 같이 수행된다. 이 단계는 제조자 증명서(36) 내의 데이터, 특히 PLATFORM_DATA 필드에 저장된 값으로의 어떠한 변화도 행해지지 않았음을 보장한다.

시스템 부트 펌웨어 증명서가 단계 214에서 실패하면, 보안 런타임 플랫폼 데이터 체커 처리(200)는 중단되고 디바이스는 단계 210에서 리셋된다.

제조자 증명서의 DIE_ID가 영으로 설정되지 않으면, DIE_ID 필드는 eFuse 메모리(24)에 저장된 DIE_ID_FUSE와 비교된다. 성공적인 비교는 제조자 증명서 내의 플랫폼 관련 데이터가 플랫폼에 속함을 보증한다. 제조자 증명서의 DIE_ID가 0으로 설정되면, 플랫폼 증명서(38)와 연관된 PLATFORM_DATA 필드와 제조자 증명서(36)로부터 판독된 PLATFORM_DATA 필드의 성공적인 비교는 제조자 증명서 내의 플랫폼 관련 데이터가 그 플랫폼에 속함을 보증한다.

플랫폼 데이터의 유효성 상태는 단계 218에서 호출 소프트웨어로 (있다면) 리턴된다. 플랫폼 데이터가 예상되는 플랫폼 데이터와 일치하지 않으면, 디바이스의 임의의 특징이 디스에이블될 수 있으나; 긴급 호출 기능과 같은 일부 특징들은 여전히 이용가능할 수 있다.

단계 220 내지 단계 240은 보안 런타임 체커(202)의 동작을 설명한다. 이 단계들은 각 펌웨어 태스크 중에 실행될 수 있다. 단계 220에서, 테스트 대상인 펌웨어의 제조자 증명서(36)에 저장된 제조자의 공개 키(MAN_PUB_KEY)는 도 4에 관련하여 앞서 기술되어 있는 바와 같이 인증될 수 있다. MAN_PUB_KEY를 인증하는 것은 이후의 인증 단계동안 잘못된 공개키/개인키 조합으로 대체되는 것을 방지한다.

제조자의 공개 키 인증이 단계 222에서 실패하면, 테스트 대상인 펌웨어가 시스템 부트 펌웨어인 경우(단계 224), 보안 런타임 체커 처리(202)는 단계 210에서 중단되어 그 디바이스는 리셋된다. 테스트 대상인 펌웨어가 시스템 부트 펌웨어와 다르면, 실행이 단계 226에서 중단된다.

제조자의 공개 키 인증이 단계 222에서 통과된다고 가정하면, 테스트 대상인 펌웨어의 펌웨어 증명서(SIG_CERT)는 단계 228에서 인증된다. 펌웨어 증명서의 인증은 앞서 도 5와 관련하여 설명된 바와 같이 수행된다.

펌웨어 증명서 인증이 단계 230에서 실패하게 되면, 테스트 대상인 펌웨어는 시스템 부트 펌웨어인 경우(단계 224), 보안 런타임 체커 처리(202)는 단계 210에서 중단되어 디바이스가 리셋된다. 테스트 대상인 펌웨어가 시스템 부트 펌웨어와 다르면, 실행은 단계 226에서 중단된다.

펌웨어 증명서 인증이 단계 230에서 통과된다고 가정하면, 발안자의 공개 키(ORIG_PUB_KEY)는 단계 232에서 인증된다. 테스트 대상인 펌웨어의 제조자 증명서의 ORIG_PUB_KEY의 인증은 도 6에 관련하여 설명된 바와 같이 수행된다.

발안자의 공개 키 인증이 단계 234에서 실패하게 되면, 테스트 대상인 펌웨어가 시스템 부트 펌웨어인 경우(단계 224), 보안 런타임 체커 처리(202)는 단계 210에서 중단되어 디바이스가 리셋된다. 테스트 대상인 펌웨어가 시스템 부트 펌웨어와 다르다면, 실행은 단계 226에서 중단된다.

발안자의 공개 키 인증이 단계 234에서 통과되면, 펌웨어는 단계 236에서 인증된다. 펌웨어 인증이 도 7과 관련하여 설명된 바와 같이 수행된다.

펌웨어 인증이 단계 238에서 실패하면, 대스트 대상인 펌웨어가 시스템 부트 펌웨어인 경우(단계 224), 보안 런타임 체커 처리(202)는 단계 210에서 중단되어 디바이스가 리셋된다. 테스트 대상인 펌웨어가 시스템 부트 펌웨어와 다르다면, 실행은 단계 226에서 중단된다.

모든 인증 테스트가 통과되면, 다이 ID는 단계 240에서 증명된다. 다이 ID의 증명은 앞서 도 8에 관련하여 설명된 바와 같이 수행된다.

다이 ID의 유효성 상태는 단계 242에서 호출 소프트웨어로 (있다면) 리턴된다. DIE_ID 필드가 "0"으로 설정되지 않고, 제조자 증명서(36) 내의 다이 ID가 eFuse 메모리(24)에서 DIE_ID_FUSE와 일치하지 않으면, 임의의 특징은 디스에이블될 수 있으나; 긴급 호출 기능과 같은 일부 특징들이 여전히 이용가능하다.

체커 태스크 200 및 202의 완료 후, 펌웨어가 성공적으로 테스트되면, 이전의 처리는 중지 점으로부터 재개되고 인터럽트는 다시 인에이블된다.

펌웨어 실행동안 펌웨어 및 플랫폼 데이터 인증을 수행함으로써, 개시 후의 펌웨어 대체(replacement)가 검출되어 방해될(thwarted) 수 있다. 체킹 태스크(200 및 202)를 실행하기 전과 후에 처리기의 상태를 관리함으로써, 태스크는 시스템을 다시 초기화하지 않고도 실행될 수 있다.

도 10은 어플리케이션 파일(32) 또는 데이터 파일(34)에의 플랫폼 증명서(38)의 결합을 도시한다. 표 2는 플랫폼 증명서의 바람직한 실시예에 대한 필드들을 리스트한다.

플랫폼 증명서

필드명	함수	보안
CERT_SIZE	증명서 사이즈(바이트 단위)
CERT_TYPE	증명서 형태: 플랫폼
CONFID_REQ	기밀성 요청(S/W 암호화)
APPLI_ID	이 증명서에 의해 증명된 코드 및/또는 데이터의 어플리케이션 소유자 식별자
CODE_ADDR	입증할 코드 및/또는 데이터가 저장된 어드레스
CODE_SIZE	증명된 코드 및/또는 데이터의 사이즈(바이트 단위)
IV	CBC 모드에서 벌크에 대한 초기 벡터 값 암호화/해독
ENC_SW_KEY	암호화된 SW 대칭키	KEK를 사용하여 암호화된 랜덤수
SW_SIG	SW 대칭키에 의해 코드 및/또는 데이터 서명	랜덤수 키(SW_KEY)에 의해 암호화된 어플리케이션 코드 해시
SIG_CERT	SW 대칭키에 의해 증명서 서명	랜덤수 키(SW_KEY)에 의해 해싱되고 암호화된 제조자 증명서 필드

플랫폼 증명서(38)는 eFuse 메모리(14)에 저장된 KEK를 사용한다. 바람직한 실시예에서, KEK는 생산동안의 랜덤수 생성 온칩이므로, KEK의 값은 아무에게나 공지되어 있는 것이 아니다. eFuse 메모리(14) 내의 KEK는 I/O 포트를 통해 또는 어플리케이션 소프트웨어에 억세스할 수 없도록 한 것이다. 각 칩의 KEK가 다른 프로그램들에 의해 외부적으로 판정 또는 저지될 수 없는 방식으로 사용되어야 한다는 것이 소망된다. eFuse 메모리(14) 내의 KEK의 저장이 퓨즈 메모리 내의 퓨즈들의 물리적 관찰을 통해 판정할 수 있지만, 그러한 관찰은 단지 칩 자체의 파괴시에만 가능하다; 각 칩이 자신의 KEK를 생성하기 때문에, 하나의 칩의 KEK의 정보는 다른 칩들의 보안과 일치하지 않을 것이다.

KEK는 디바이스의 동작동안 랜덤하게 생성되는 다른 소프트웨어 키들을 암호화하는데 사용된다. 도 9에 도시된 바와 같이, (하드웨어 또는 소프트웨어 구현 중 하나가 될 수 있는) 랜덤수 발생기(250)는 랜덤 소프트웨어 키(SW_KEY)를 필요한만큼 생성한다. 그러므로, 각 어플리케이션은 다른 소프트웨어 키와 연관될 수 있다. SW_KEY는 단계 252에서 KEK를 사용하여 암호화되고 ENC_SW_KEY로서 플랫폼 증명서(38)에 저장된다. ENC_SW_KEY가 단지 KEK만을 이용하여 해독될 수 있기 때문에, 그리고 그 KEK가 비밀성이며 칩 내부에 있기 때문에, ENC_SW_KEY는 단지 KEK에 억세스하는 어플리케이션으로 해독될 수 있다. 그러므로, ROM 내의 시스템 소프트웨어만이 KEK에 억세스해야 한다.

플랫폼 증명서(38) 내의 다른 보안값들은 SW_KEY를 이용하여 암호화된다. 증명서 자체의 일부가 아니더라도, 그 어플리케이션 파일(32) 또는 데이터 파일(34)은 암호화 단계 254 및 256에 도시된 바와 같이 신뢰성 요청에 응답하는 SW_KEY에 의해 선택적으로 암호화될 수 있다. 어플리케이션 파일(32) 또는 데이터 파일(34)이 암호화될 것인지의 여부는 소프트웨어 서명(SW_SIG) 또는 서명 증명서(SIG_CERT)에도 영향을 미칠 것이다. 소프트웨어 파일(32) 또는 데이터 파일(선택적으로 암호화됨)은 단계 258에서 해싱되어 단계 260에서 SW_KEY에 의해 암호화된다. 이 값은 SW_SIG로서 저장된다. 증명서 필드는 단계 262에서 해싱되어 단계 264에서 SW_KEY에 의해 암호화된다. 이 값은 SIG_CERT로서 저장된다.

플랫폼 증명서는 어플리케이션 또는 데이터 파일을 로딩된 디바이스(10)와 연관시킨다. 일단 연관되기만 하면, 플랫폼 증명서가 유효하지 않을 것이기 때문에, 어플리케이션 또는 데이터 파일은 다른 디바이스로 전달될 수 없다. 추가로, APPLI_ID 필드는 어플리케이션 파일(32) 또는 데이터 파일(34)을 특정 프로그램과 연관시키는데 사용될 수 있다. 오디오 또는 비디오 파일의 포맷이 각종 어플리케이션에 의해 재생될 수 있는 표준 포맷이었다고 해도, 예를 들어, 단지 특정 미디어 플레이어 어플리케이션과 관련한 오디오 또는 비디오 파일로만 억세스를 허용하도록 사용될 수 있다.

도 11은 어플리케이션을 실행하고 어플리케이션 내의 데이터 파일을 사용하는데 필요한 플랫폼 증명서로부터의 어플리케이션 또는 데이터 파일의 비결합(unbinding)을 도시한다. 단계 270에서, SW_KEY는 eFuse 메모리(14)로부터의 KEK를 이용하여 플랫폼 증명서(38)의 ENC_SW_KEY로부터 얻어진다. SW_KEY는 단계 272에서 플랫폼 증명서(38)의 SIG_CERT 필드를 해독하고, 단계 274에서 SW_SIG 필드를 해독하는데 이용된다.

SIG_CERT 필드와는 다른 플랫폼 증명서(38)의 필드는 단계 276에서 해싱된다. 해시는 단계 278에서 암호화된 SW_CERT와 비교된다. 유사하게, 저장된 어플리케이션 또는 데이터 파일은 단계 280에서 해싱되고 그 해시는 단계 282에서 단계 274로부터의 해독된 SW_SIG 필드와 비교된다. 단계 278에서의 비교 또는 단계 300에서의 비교 중 하나가 불일치를 나타내면, 시스템 에러가 단계 302에서 발생한다. 그렇지 않으면, 단계 304 및 단계 306에서 선택적인 해독 후에 어플리케이션이 실행된다(또는 데이터 파일이 어플리케이션에 의해 사용된다).

플랫폼 증명서는 종래 기술에 비해 현저한 이점을 제공한다. 소프트웨어 또는 데이터 파일의 디바이스(10)에의 결합은 최초 소프트웨어 모듈의 임의의 변경을 찾아내는 것을 도우며, 그 소스의 임의의 복제가 또 다른 유사한 플랫폼 상에서 실행되고, 클로닝(cloning) 공격에 대한 효율적인 보호, 특히 중요한 저작권 관리 및 매체 보호를 제공하는 것을 방해한다.

이에 대한 해결책은 플랫폼 서명 및 입증을 위한 단방향 해시 및 벌크 암호화와 같은 강력한 암호 기법에 기초하기 때문에 고레벨의 보안을 제공한다. 그 해결책은 임의의 컴퓨터 하드웨어 플랫폼에 쉽게 적응될 수 있다. 결합시에 랜덤하게 발생되는 소프트웨어 키 및 KEK의 사용은 외부 메모리 내의 암호화된 키의 외부 저장을 고려한다. 무수한 다른 소프트웨어 키들이 어플리케이션 및 데이터 파일에 사용될 수 있다. 추가로, 서명의 계산을 위한 대칭 벌크 암호화 기술의 사용은 비대칭 기술에 비해 처리기 컴퓨팅 부하를 현저히 줄인다.

도 12는 외부 메모리 내의 IMEI(국제 이동 장비 식별) 넘버를 안전하게 저장하기 위해 제조자 및/또는 플랫폼 증명서의 특정 사용을 기술한다. IMEI 넘버는 클론에 대한 전화 제조자 및 오퍼레이터 및 쓸모없게 되거나 비순응 사용자 장비 둘 모두를 보호하기 위해, UMTS(통합 이동전화 서비스) 표준, 공개 5로 특정된다. IMEI 넘버는 이동 전화 내의 어딘가에 저장되어 주문형 서비스 내트워크로 보내져야 한다. 임의의 수단(하드웨어, 소프트웨어 또는 물리)에 의해 탬퍼링에 대한 IMEI 넘버의 보호는 이동 디바이스의 요구되는 보안 레벨을 현저히 증가시킨다. 탬퍼링을 방지하기 위해, 많은 제조자들은 각 전화마다 고유한 IMEI 넘버를 생산 처리 후반에 칩 상에 저장한다. 그러나, 탬퍼 프루프(temper-proof) 기법으로 그 넘버를 칩상에 저장하는 것은 고가의 방식이다.

도 12에 도시된 바와 같이, IMEI는 각 전화마다 주문 제작된 제조자 증명서(구체적으로, PLATFORM_DATA 필드) 내의 외부 메모리 및/또는 플랫폼 증명서에 결합된 외부 메모리에 저장될 수 있다. 기저대역 처리 시스템(12)은 시스템 부트 펌웨어의 제조자 증명서(36) 또는 플랫폼 증명서(38)에 결합된 메모리 위치로부터 외부 메모리 내의 IMEI에 억세스할 수 있다.

IMEI 넘버가 제조자 증명서(36)의 PLATFORM_DATA 분야에서 변경된다면, 시스템 부트 소프트웨어의 실행 이전에 보안 리셋 부트 체커에 의해 검출될 것이다. 시스템 부트 소프트웨어가 로딩된 후에 변경된다면, IMEI 넘버에서의 변화가 보안 런타임 플랫폼 데이터 체커에 의해 검출될 것이다.

IMEI가 플랫폼 증명서에 결합된 외부 메모리에 저장되면, IMEI 내의 임의의 변화는 유효하지 않은 SW_SIG로서 검출될 것이다. 플랫폼 증명서를 이용하면, IMEI는 외부 메모리의 임의의 위치에 저장될 수 있다.

디바이스(10)는 IMEI가 유효하지 않은 제조자 증명서(36) 및 유효하지 않은 플랫폼 증명서(38)를 초래해도 긴급 호출은 허용하도록 프로그램될 수 있다.

도 13은 디바이스(10)의 동작을 제어하기 위해 제조자 증명서(36) 내의 필드를 이용하기 위한 블록도를 도시한다. 도 13에 도시된 바와 같이, 제조자 증명서(36)의 DEBUG_REQ 필드는 테스트 억세스 및 에뮬레이션 회로(320)를 제어하는데 사용된다. 제조자 증명서(36)의 CONF_PARAM 필드에서 설명되는 파라미터들은 블록 322 및 324에 도시된 바와 같이 하드웨어 또는 소프트웨어를 적절하게 구성함으로써, 디바이스(10)의 임의의 동작 특성을 제어하는데 사용될 수 있다.

동작시, 시스템 부트 소프트웨어가 하드웨어 및 소프트웨어 리소스를 구성하기 위해 제조자 증명서로부터의 구성 파라미터에 억세스한다. 제조자의 증명서(36) 내에 구성 파라미터들을 배치하는 것은 제조자가 유연성 하드웨어 및/또는 소프트웨어 구성을 갖는 디바이스를 설계하여 그 디바이스를 적절하게, 안전하고 확실하게 구성하도록 한다.

제조자 증명서(36) 내에 구성 파라미터를 안전하게 저장하는 한가지 사용은 디바이스(10)가 제어 상황시 구성을 입력하도록 허용할 것이며, 그 구성은 디바이스(10)가 공격에 취약한 채로 둘 것이다. 예를 들어, 테스트 모드동안, 그 디바이스(10)는 임의의 통상의 숨겨진 메모리 위치가 판독 및/또는 기입에 억세스할 수 있는 구성으로 배치될 수 있다. 또한, 메모리 성능 설정, 버스 속도, 처리 속도 등과 같은 임의의 하드웨어 파라미터는 시스템 동작을 분석하기 위한 테스트 모드동안 변경될 수 있다.

제조자 증명서에 구성 파라미터를 저장하는 제2의 보안 사용은 디바이스(10)의 성능을 제어할 것이다. 컴퓨팅 산업에 잘 공지되어 있는 바와 같이, 일부 사용자들은 하드웨어 및/또는 소프트웨어 파라미터를 재구성하여 디바이스 한계까지 설정할 것이다. 예를 들어, 많은 사용자들은 시스템 클럭 속도 또는 처리기가 동작하는 다수의 시스템 클럭을 변경함으로써 퍼스널 컴퓨터 처리기 속도를 "오버클럭"한다. 부가적으로, 메모리 설정은 메모리 억세스 및 처리량을 개선하기 위해 변경될 수 있다. 오버클럭킹은 컴퓨팅 디바이스의 성능을 개선시킬 수 있지만, 그 사양을 벗어난 온도로 하드웨어를 동작시킴으로써 하드웨어 수명을 줄일 수도 있다. 추가로, 컴퓨팅 디바이스는 오버클럭 설정으로 엉뚱하게 동작할 수 있다. 따라서 오버클럭 설정은 보증 및 지원에 의해 제조자에게 고가일 수 있다.

제조자 증명서(36)에 설정은 제조자 권한 하에서만 변경될 수 있다고 정의되어 있기 때문에, 제조자 증명서(36) 내의 파라미터들을 설정함으로써 성능 설정을 변화시키는 시도는 실패할 것이다. 시스템 부트 소프트웨어는 정의된 파라미터로의 리셋 후에 디바이스를 구성할 것이다. 증명서 내의 권한 설정을 변경하기 위한 임의의 시도는 보안 리셋 부트 체커(52)(리셋후) 또는 보안 런타임 체커(202)에 의해 검출될 것이다. 시스템 펌웨어의 외부에 소프트웨어에 의한 구성 파라미터를 변화시키기 위한 임의의 시도는 보안 런타임 플랫폼 데이터 체커(200)에 의해 검출될 것이다.

제조자 증명서 내의 구성 파라미터를 저장하는 제3의 보안 사용은 다른 성능 특성 및 또는 다른 기능 설정을 갖는 단일 디바이스를 제공할 것이다. 그 디바이스는 제조자 증명서(36)에 저장되어 있는 구성 설정에 따라서 판매될 수 있으므로, 구성은 사용자 또는 제3자에 의해 변경될 수 없다. 디바이스(10)는 제조자에 의해 쉽게 업그레이드될 수 있다.

예를 들어, 이동 컴퓨팅 디바이스 플랫폼은 다수의 처리기 속도로 실행하도록 설계될 수 있고, 무선 네트워킹, 오디오 및 비디오 기능과 같은 다른 선택적 기능을 가질 수 있다. 디바이스는 PC 카드 또는 메모리 포트 개선과 같은 고가의 하드웨어 업그레이드 없이 후에 업그레이드될 수 있는 소망의 구성으로 판매될 수 있다.

도 14는 구성 데이터가 플랫폼 증명서에 의해 보호되는 데이터 파일(34)에 저장되는 도 13에 대한 변동을 도시한다. 구성 파라미터를 저장하는 데이터 파일(34)을 변경하는 임의의 시도는 시스템 펌웨어에 의해 검출될 것이다. 보안 런타임 플랫폼 데이터 체커(200)는 디바이스의 동작동안 데이터 파일의 콘텐츠를 체크하도록 변경될 수 있다.

도 15는 디바이스(10)에 억세스하기 위한 대안의 설계가 도 15에 도시된 테스트 모드와 같은 임의의 모드임을 도시한다. 이 설계는 억세스 코드(H_Test_ID)의 해시를 저장한다. 이 코드는 eFuse 메모리(24)에 저장될 수 있다. 테스트 모드에 억세스하기 위해, 당사자는 억세스 코드(Input_Test_ID)를 입력할 필요가 있을 것이다. Input_Test_ID는 블록 330에서 해싱되고 블록 332에서 H_Test_ID와 비교된다. 블록(330)으로부터 해시된 억세스 코드가 저장되어 있는 해시된 억세스 코드와 일치한다면, 그 모드의 엔트리는 인에이블된다.

동작시, H_Test_ID는 통상 억세스 코드를 저장하는데 필요한 저장 공간을 줄이는 Input_Test_ID보다 사이즈가 현저히 작을 것이다. 그러나, 원하는 모드로의 엔트리를 얻기 위해, 당사자는 훨씬 큰 수를 공급할 필요가 있을 것이다. 가능한 많은 입력들이 H_Test_ID와 일치하기 위해 해시할 수 있지만, 부적절한 입력 억세스 코드가 SHA-1 또는 ND5와 같은 오늘날의 해싱 알고리즘을 이용하여 일치될 것이라는 것은 통계적으로 확률없는 것이다.

부가적으로, 도 15의 설계는 부가적인 보안 이득을 제공한다. 저장된 해시, H_Test_ID가 공지되어 있다 해도, H_Test_ID로 해싱하는 입력 코드의 판정은 계산적으로 어려울 것이다.

해싱된 억세스 코드의 사용이 테스트 모드 억세스에 관련하여 기술되어 있지만, 상술된 바와 같이 시스템 파라미터를 변화시키기 위한 억세스와 같은 임의의 적절한 상황에 보안을 제공하도록 사용될 수 있다.

본 발명의 상세한 설명이 임의의 예시적인 실시예들에 관련되어 있을지라도, 이러한 실시예들의 여러가지 변경 및 대안의 실시예들이 본 기술분야의 숙련자들에게 제시될 것이다. 본 발명은 청구범위에 해당하는 임의의 변경 또는 대안의 실시예들을 포함한다.

Claims (12)

1. 컴퓨팅 디바이스 내의 리소스로의 억세스를 보호하는 방법으로서,

   상기 컴퓨팅 디바이스의 공지된 메모리 위치에 암호화된 억세스 코드를 저장하는 단계;

   상기 리소스에 억세스하기 위해 패스워드를 수신하는 단계;

   상기 패스워드를 암호화하여 암호화된 패스워드를 생성하는 단계;

   상기 암호화된 패스워드를 상기 암호화된 억세스 코드와 비교하는 단계; 및

   상기 암호화된 억세스 코드가 상기 암호화된 패스워드와 일치하면 상기 리소스로의 억세스를 허용하는 단계

   를 포함하는 억세스 보호 방법.
2. 제1항에 있어서,

   상기 암호화된 억세스 코드를 저장하는 단계는 해시된 억세스 코드를 저장하는 단계를 포함하는 억세스 보호 방법.
3. 제2항에 있어서,

   상기 패스워드를 암호화하는 단계는 패스워드를 해싱하는 단계를 포함하는 억세스 보호 방법.
4. 제1항에 있어서,

   상기 암호화된 억세스 코드는 외부에서는 변경할 수 없는 메모리 내에 저장되는 억세스 보호 방법.
5. 제1항에 있어서,

   상기 억세스 허용 단계는 상기 암호화된 억세스 코드가 상기 암호화된 패스워드와 일치하면 리소스의 테스팅 억세스를 허용하는 단계를 포함하는 억세스 보호 방법.
6. 제1항에 있어서,

   상기 억세스 허용 단계는 상기 암호화된 억세스 코드가 상기 암호화된 패스워드와 일치하면 시스템 파라미터 변경 억세스를 허용하는 단계를 포함하는 억세스 보호 방법.
7. 컴퓨팅 디바이스에 있어서,

   처리 시스템;

   암호화된 억세스 코드를 저장하기 위한 메모리; 및

   상기 리소스에 억세스하기 위해 패스워드를 수신하는 입력 회로

   를 포함하고,

   상기 처리 회로는:

   상기 패스워드를 암호화하여 암호화된 패스워드를 생성하고;

   상기 암호화된 패스워드를 상기 암호화된 억세스 코드와 비교하고;

   상기 암호화된 억세스 코드가 상기 암호화된 패스워드와 일치하면 상기 리소스로의 억세스를 허용하는

   컴퓨팅 디바이스.
8. 제7항에 있어서,

   상기 암호화된 억세스 코드는 해시된 억세스 코드를 포함하는 컴퓨팅 디바이스.
9. 제8항에 있어서,

   상기 암호화된 패스워드는 해시된 패스워드를 포함하는 컴퓨팅 디바이스.
10. 제7항에 있어서,

    상기 암호화된 억세스 코드는 외부에서는 변경할 수 없는 메모리에 저장되는 컴퓨팅 디바이스.
11. 제7항에 있어서,

    상기 처리 시스템은 상기 암호화된 억세스 코드가 상기 암호화된 패스워드와 일치하면 리소스의 테스팅 억세스를 허용하는 컴퓨팅 디바이스.
12. 제7항에 있어서,

    상기 처리 시스템은 상기 암호화된 억세스 코드가 상기 암호화된 패스워드와 일치하면 파라미터로의 억세스를 허용하는 컴퓨팅 디바이스.

Images