KR101523420B1

KR101523420B1 - 부팅 처리에서의 단계화 제어 해제

Info

Publication number: KR101523420B1
Application number: KR1020127029639A
Authority: KR
Inventors: 인혁 차; 요겐드라 씨 샤; 로렌스 케이스
Original assignee: 인터디지탈 패튼 홀딩스, 인크
Priority date: 2010-04-12
Filing date: 2011-04-12
Publication date: 2015-05-27
Also published as: CN102844764B; CN102844764A; KR20130020734A; TW201628368A; EP2558972A1; US20150026471A1; JP2013524385A; TW201202999A; US9679142B2; CN105468982A; SG184853A1; US20110302638A1; KR20120130793A; JP2017022781A; JP5647332B2; US8856941B2; TWI584625B; US20170277895A1; TW201741925A; JP2015035831A

Abstract

네트워크 장치의 무결성 확인이 수행될 수 있다. 보안 하드웨어 모듈을 포함한 네트워크 장치는 루트 키를 수신할 수 있다. 보안 하드웨어 모듈은 제1 코드 측정치를 또한 수신할 수 있다. 보안 하드웨어 모듈은 루트 키 및 제1 코드 측정치에 기초하여 제1 키를 제공할 수 있다. 보안 하드웨어 모듈은 제2 코드 측정치를 수신하고 제1 키 및 제2 코드 측정치에 기초하여 제2 키를 제공할 수 있다. 코드 측정치에 기초한 키의 해제는 각 단계에서의 인증을 제공할 수 있다.

Description

부팅 처리에서의 단계화 제어 해제{STAGED CONTROL RELEASE IN BOOT PROCESS}

관련 출원에 대한 교차 참조

이 출원은 2010년 4월 12일자 출원한 미국 가특허 출원 제61/323,248호 및 2010년 6월 22일자 출원한 미국 가특허 출원 제61/357,474호를 우선권 주장하며, 이 우선권 출원들의 전체 내용은 여기에서의 인용에 의해 본원에 통합된다.

전통적인 보안 방법은 리세트(reset)로부터 성공적인 보안 부팅에 기초하여 인증을 행하기 위해 사용되는 단일 키와 같은 자원의 해제시에 이진 결정(binary decision)을 할 수 있게 한다. 문제점은 리세트로부터 성공적인 부팅이 발생하지 않은 때 발생할 수 있다.

네트워크 장치의 무결성 확인(integrity validation)을 수행하기 위한 시스템, 방법 및 설비가 개시된다. 네트워크 장치는 보안 메모리를 포함할 수 있다. 예를 들면, 보안 메모리는 보안 하드웨어 모듈에 포함될 수 있다. 보안 메모리는 루트 키(root key)를 수신할 수 있다. 예를 들면, 루트 키는 제조시에 또는 공급시에 보안 메모리에 의해 수신될 수 있다. 루트 키는 보안 메모리에 저장될 수 있고, 보안 하드웨어 모듈 외부의 소프트웨어 또는 하드웨어에게 보이지 않을 수 있다.

보안 하드웨어 모듈은 제1 코드 측정치(제1 코드의 측정치)를 수신할 수 있다. 예를 들면, 보안 하드웨어 모듈을 포함한 네트워크 장치와 연관된 프로세서 등의 프로세서는 측정할 코드의 제1 부분을 선택할 수 있다. 코드의 제1 부분은 네트워크 장치와 연관된 메모리, 예를 들면, ROM 메모리, RAM 메모리 등에 저장될 수 있다. 프로세서는 코드의 선택된 제1 부분을 측정하여 제1 코드 측정치를 발생할 수 있다. 프로세서는 이 측정치를 보안 하드웨어 모듈에 제공할 수 있다.

보안 하드웨어 모듈은 루트 키 및 제1 코드 측정치에 기초하여 제1 키를 발생할 수 있다. 예를 들면, 보안 하드웨어 모듈은 제1 키를 유도 또는 해제(release)할 수 있다. 발생된 제1 키는 제1 코드 측정치가 유효일 때 유효이고, 제1 코드 측정치가 무효일 때 무효이다. 예를 들면, 보안 하드웨어 모듈은 부분적으로 제1 코드 측정치에 기초하여 제1 키를 유도할 수 있다. 만일 제1 코드 측정치가 무효이면, 유도된 제1 키도 역시 무효이다. 발생된 제1 키는 자원에 대한 액세스를 제공하기 위해 보안 하드웨어 모듈에 의해 발생될 수 있다. 자원에 대한 액세스는 코드가 보안 메모리에 저장되어 있으면 코드 측정치 없이 제공될 수 있다.

제1 키는 제1 기능과 연관된 제1 신뢰 단계(stage)에 관한 것일 수 있다(예를 들면, 하나 이상의 자원이 제1 기능과 연관될 수 있다). 또한, 제1 이해관계자(stakeholder)는 유효한 제1 키를 이용하여 제1 기능에 액세스할 수 있다. 만일 제1 키가 유효가 아니면, 제1 이해관계자는 제1 기능에 액세스할 수 없다. 즉, 보안 하드웨어 모듈은 제1 코드 측정치가 무효일 때 제1 기능에 대한 액세스를 금지할 수 있다.

보안 하드웨어 모듈은 제2 코드 측정치(제2 코드의 측정치)를 수신할 수 있다. 보안 하드웨어 모듈은 제1 키와 제2 코드 측정치에 기초하여 제2 키를 발생할 수 있다. 제2 키는 제2 기능과 연관된 제2 신뢰 단계에 관한 것 있을 수 있다(예를 들면, 하나 이상의 자원이 제2 기능과 연관될 수 있다). 또한, 제2 이해관계자는 유효한 제2 키를 이용하여 제2 기능에 액세스할 수 있다. 키 해제는 최종의 공지된 양호한 부팅 단계(boot stage)(예를 들면, 성공적 인증이 있었던 최종의 공지된 부팅 단계)로 제한될 수 있다.

하드웨어, 코드 및/또는 데이터의 무결성 측정치에 기초한 키 및 기능 등의 자원의 발생 및/또는 해제는 각 단계에서의 인증을 제공할 수 있다. 예를 들면, 장치는 수 개의 층을 포함하고 각 층은 그 자신의 인증 비밀을 가질 수 있다. 각 인증 비밀은 제조자 펌웨어, 신뢰성 실행 코드, 운영체제, 및 제3자 애플리케이션과 같은 장치 능력의 계층에 있는 특수 이해관계자에 대응할 수 있다. 다른 예로서, 유효한 제1 키는 제1 부팅 단계에 대한 유효 인증과 연관될 수 있다. 유효한 제1 키는 네트워크 장치의 펌웨어에 액세스하여 펌웨어에서의 교정(remediation)을 수행하기 위해 장치 제조자(예를 들면, 제1 이해관계자)에 의해 사용될 수 있다. 유효한 제2 키는 나중의 부팅 단계(예를 들면 중간 부팅 단계) 중에 하나 이상의 소프트웨어 컴포넌트의 유효 인증과 연관될 수 있다. 유효한 제2 키는 소프트웨어 컴포넌트에 액세스하여 예를 들면 소프트웨어의 교정을 수행하기 위해 장치 관리자(예를 들면, 제2 이해관계자)에 의해 사용될 수 있다. 성공적으로 인증된 단계에 대한 유효 키를 제공함으로써, 인증에 실패하지 않은 최종 단계에 상응한 액세스가 수여될 수 있다.

개시되는 다단계 인증에서의 단계(stage)의 수는 다르게 할 수 있고 제한되지 않는다. 또한, 복수의 인증 경로가 제공될 수 있다. 즉, 인증은 소정의 무결성 체크 단계에서 여러 가지 방법으로 나누어질 수 있다. 예를 들면, 각 이해관계자는 하나 이상의 인증 단계에 관한 하나 이상의 정책(policy)을 제공할 수 있다. 각 단계에서, 인증은 이해관계자 정책에 기초하여 여러 가지 방법으로 나누어질 수 있다. 이해관계자는 그 정책을 외부에서 관리할 수 있다.

본 발명은 첨부 도면과 함께 예로서 주어지는 이하의 설명으로부터 더 구체적으로 이해할 수 있다.
도 1은 예시적인 롱텀 에볼루션(LTE) 무선 통신 시스템을 보인 도이다.
도 2는 예시적인 LTE 무선 통신 시스템의 블록도이다.
도 3은 장치 확인(validation)과 장치 인증(authentication) 간에 결속(binding)이 있는 예시적인 장치를 보인 도이다.
도 4는 공통 신뢰 환경(TrE)을 이용한 무결성 체크 및 인증의 물리적 결속의 예를 보인 도이다.
도 5는 확인과 사전 공유 비밀 기반 장치 인증 간의 결속의 예를 보인 도이다.
도 6은 확인과 사전 공유 키 기반 인증의 예를 보인 도이다.
도 7은 조건적 액세스를 허가하는 TrE에 기인하는 결속의 예를 보인 도이다.
도 8은 확인과 증명서(certificate) 기반 장치 인증 간의 결속의 예를 보인 도이다.
도 9는 확인과 증명서 기반 인증의 결속의 예를 보인 도이다.
도 10은 조건적 액세스를 허가하는 TrE에 기인하는 결속의 예를 보인 도이다.
도 11은 게이팅 기능을 이용한 결속의 예를 보인 도이다.
도 12는 예시적인 부팅 처리에 관한 복수의 단계에서의 인증의 예를 보인 도이다.
도 13a는 본 발명의 시스템 및 방법의 실시형태가 구현될 수 있는 예시적인 칩을 보인 도이다.
도 13b는 본 발명의 시스템 및 방법의 실시형태가 구현될 수 있는 예시적인 칩을 보인 도이다.
도 13c는 본 발명의 시스템 및 방법의 실시형태가 구현될 수 있는 예시적인 칩을 보인 도이다.
도 14는 예시적인 키 유도 함수를 보인 도이다.
도 15는 서명 메카니즘을 포함한 예시적인 키 유도 세부를 보인 도이다.
도 16은 예시적인 다단계 키 유도 세부를 보인 도이다.
도 17은 예시적인 부팅 시퀀스를 보인 도이다.
도 18은 예시적인 부팅 시퀀스 흐름을 보인 도이다.
도 19는 다단계 인증에 관한 예시적인 네트워크 통신을 보인 도이다.
도 20은 예시적인 시동 및 시동 후 구성 절차를 보인 도이다.
도 21은 본 발명의 시스템 및 방법의 실시형태가 구현될 수 있는 예시적인 칩을 보인 도이다.
도 22는 UE 통신을 위해 무결성 체크 처리를 연장하는 예를 보인 도이다.

첨부 도면은 본 발명의 시스템, 방법 및 설비들이 구현될 수 있는 예시적인 실시형태와 관련이 있다. 그러나, 본 발명이 예시적인 실시형태에 관련하여 설명되지만, 본 발명은 그 설명으로 제한되는 것이 아니고, 다른 실시형태를 이용할 수도 있고, 본 발명의 범위로부터 벗어나지 않고 본 발명과 동일한 기능을 수행하도록 본원에서 설명하는 실시형태에 대하여 수정 및 추가가 이루어질 수 있다. 개시된 시스템 및 방법들 중의 일부는 보안성의 다단계 인증을 제공할 수 있다. 비록 무선 장치 및 네트워크에 관련하여 개괄적으로 설명하지만, 본 발명의 시스템, 방법 및 설비는 그러한 응용으로 제한되는 것이 아니고, 개시된 인증을 구현할 수 있는 임의의 적당한 장치, 네트워크 및/또는 시스템에도 적용할 수 있다. 또한, 이하에서는 부팅 단계(boot-stage) 행동에 관련한 다단계 인증이 설명된다. 그러나, 그 설명은 단지 예시를 위한 것이며, 본 발명의 시스템, 방법 및 설비는 부팅 단계 구현으로 제한되는 것이 아니다. 다단계 인증은 임의의 적당한 다단계 처리의 구현에도 폭넓게 적용할 수 있다.

이하에서 인용되는 용어 "무선 송수신 유닛"(wireless transmit/receive unit; WTRU)은, 비제한적인 예를 들자면, 사용자 장비(UE), 이동국(MS), 진보형 이동국(advanced mobile station; AMS), 스테이션(STA), 고정식 또는 이동식 가입자 유닛, 페이저, 셀룰러 전화기, 개인용 정보 단말기(PDA), 컴퓨터, 또는 무선 환경에서 동작할 수 있는 임의의 다른 유형의 장치를 포함한다. 용어 WTRU와 UE는 상호교환적으로 사용될 수 있다. 이하에서 인용되는 용어 "기지국"은, 비제한적인 예를 들자면, 노드-B, 진보형 기지국(advanced base station; ABS), 사이트 제어기, 액세스 포인트(AP), 홈 노드-B(HnB) 또는 무선 환경에서 동작할 수 있는 임의의 다른 유형의 인터페이스 장치를 포함한다. 용어 "WTRU"와 "기지국"은 서로 배타적인 것이 아니다.

도 1은 진화형 범용 지상 무선 액세스 네트워크(E-UTRAN)(105)를 포함하는 예시적인 롱텀 에볼루션(LTE) 무선 통신 시스템/액세스 네트워크(100)를 보인 것이다. E-UTRAN(105)은 수 개의 E-UTRAN 노드-B(eNB)(120), 홈 eNB(HeNB)(122), 및 HeNB 게이트웨이(HeNB GW)(132)를 포함한다. WTRU(110)는 eNB(120), HeNB(122) 또는 이들 모두와 통신할 수 있다. eNB(120)는 X2 인터페이스를 이용하여 서로 인터페이스 접속한다. 각각의 eNB(120)와 HeNB GW(132)는 S1 인터페이스를 통해 이동성 관리 엔티티(MME)/서빙 게이트웨이(S-GW)(130)와 인터페이스 접속한다. HeNB(122)는 S1 인터페이스를 통하여 HeNB GW(132)와 인터페이스 접속하고 S1 인터페이스를 통하여 MME/S-GW(130)와 인터페이스 접속하며, 또는 이들 모두와 인터페이스 접속한다. 비록 도 1에는 하나의 WTRU(110)와 하나의 HeNB 및 3개의 eNB(120)가 도시되어 있지만, 임의의 무선 장치 및 유선 장치의 조합이 무선 통신 시스템/액세스 네트워크(100)에 포함될 수 있다는 것을 이해할 것이다.

도 2는 WTRU(110), eNB(120) 및 MME/S-GW(130)를 포함한 LTE 무선 통신 시스템(200)의 예시적인 블록도이다. 비록 eNB(120)와 MME/S-GW(130)가 간단히 도시되어 있지만, eNB(120)와 MME/S-GW(130)의 예는 실질적으로 유사한 특징을 갖는 것으로 이해하여야 한다. 도 2에 도시된 바와 같이, WTRU(110), eNB(120) 및 MME/S-GW(130)는 모바일 지향 절전 모드를 지원하도록 구성될 수 있다.

전형적인 WTRU에서 찾을 수 있는 컴포넌트들 외에, WTRU(110)는 선택적으로 연결되는 메모리(222)를 구비한 프로세서(216), 적어도 하나의 송수신기(214), 선택적인 배터리(220) 및 안테나(218)를 구비한다. 프로세서(216)는 대역폭 관리를 수행하도록 구성될 수 있다. 송수신기(214)는 프로세서(216) 및 안테나(218)와 통신하여 무선 통신의 송신 및 수신을 수행한다. 선택적인 배터리(220)는 송수신기(214) 및 프로세서(216)에 전원을 공급하도록 WTRU(110)에서 사용될 수 있다.

전형적인 eNB에서 찾을 수 있는 컴포넌트들 외에, eNB(120)는 선택적으로 연결되는 메모리(215)를 구비한 프로세서(217), 송수신기(219) 및 안테나(221)를 구비한다. 프로세서(217)는 대역폭 관리를 수행하도록 구성될 수 있다. 송수신기(219)는 프로세서(217) 및 안테나(221)와 통신하여 무선 통신의 송신 및 수신을 수행한다. eNB(120)는 선택적으로 연결되는 메모리(234)를 구비한 프로세서(233)를 가진 이동성 관리 엔티티/서빙 게이트웨이(MME/S-GW)(130)에 접속될 수 있다.

도 1 및 도 2에 도시된 LTE 네트워크는 특수한 통신 네트워크의 일 예일 뿐이고, 다른 유형의 통신 네트워크가 사용될 수 있다. 각종 실시형태는 임의의 무선 통신 기술로 구현될 수 있다. 무선 통신 기술의 일부 예시적인 유형으로는, 비제한적인 예를 들자면, WiMAX(Worldwide Interoperability for Microwave Access), 802.xx, 글로벌 이동통신 시스템(GSM), 코드분할 다중 접속(CDMA2000), 범용 이동통신 시스템(UMTS), 또는 임의의 미래 기술이 있다.

이하에서 인용되는 용어 "매크로 셀"은 비제한적인 예를 들자면 기지국, E-UTRAN 노드-B(eNB), 또는 무선 환경에서 동작할 수 있는 임의의 다른 유형의 인터페이스 장치를 포함한다. 이하에서 인용되는 용어 "홈 노드-B(HNB)는 비제한적인 예를 들자면 기지국, 홈 진화형 노드-B(HeNB), 펨토셀, 또는 폐쇄 가입자 그룹 무선 환경에서 동작할 수 있는 임의의 다른 유형의 인터페이스 장치를 포함한다.

설명의 목적상, 각종 실시형태는 롱텀 에볼루션(LTE)에 관련하여 설명되지만, 각종 실시형태는 임의의 무선 통신 기술로 구현될 수 있다. 무선 통신 기술의 일부 예시적인 유형으로는, 비제한적인 예를 들자면, WiMAX(Worldwide Interoperability for Microwave Access), 802.xx, 글로벌 이동통신 시스템(GSM), 코드분할 다중 접속(CDMA2000), 범용 이동통신 시스템(UMTS), 또는 임의의 미래 기술이 있다.

용어 클라이언트와 장치(device)는 동의어적으로 사용될 수 있다. 또한, 용어 '장치 무결성 확인(integrity validation)', '장치 확인' 및 '확인'도 역시 동의어적으로 사용될 수 있다. 확인(validation)은 종합적으로 통신 또는 컴퓨팅 장치를 구성하는 부품 또는 전체 컴포넌트의 무결성을 검증하는 처리일 수 있다. 부품 또는 컴포넌트는 예를 들면 하드웨어(HW), 소프트웨어(SW), 펌웨어(FW), 및/또는 구성 데이터일 수 있다. 장치 인증은 통신 또는 컴퓨팅 장치의 아이덴티티가 그 진정성(authenticity)에 대하여 검증자에게 검증되는 처리를 말할 수 있다.

H(e)NB에 관련하여, H(e)NB의 장치 무결성 확인의 결과를 장치 인증의 절차 또는 결과와 결속(binding)하는 것과 같은 절차의 결속이 수행될 수 있다. 장치 확인과 장치 인증의 결속을 수행하는 각종 방법이 사용될 수 있다.

비록 장치 무결성 확인 및 장치 인증에 적용되는 결속 방법의 예가 3GPP H(e)NB에 대한 것이지만, 이러한 방법은 장치 무결성 확인뿐만 아니라 장치 인증의 필요성이 있는 임의의 다른 통신 또는 응용 장치에 적용될 수 있다는 것을 이해하여야 한다.

H(e)NB에서의 전형적인 장치 인증 절차는 신뢰 환경(Trusted Environment; TrE)에 포함된 AKA 크리덴셜을 검증하는 것으로 제한될 수 있다. 이러한 절차는 장치 인증 또는 확인 및/또는 장치 인증에 호스팅 관계자 인증을 결속하는 가능성을 취급하지 않을 수 있다.

확인된 장치와 처리 및/또는 장치 인증의 결과 간의 결속이 수행될 수 있다. 2가지 유형의 결속이 수행될 수 있다. 즉, 장치 확인의 처리에서 사용되거나 장치 확인에 의해 사용되는 논리적 엔티티(또는 엔티티 또는 프로세스 또는 데이터)와 장치 인증의 처리에 의해 사용되는 논리적 엔티티(또는 엔티티 또는 프로세스 또는 데이터) 사이에서 논리적 대응이 요구되고 검증되는 논리적 결속과, 장치 확인 처리에서 사용되거나 장치 확인 처리에 의해 사용되는 특수한 물리적 엔티티(예를 들면 물리적 TrE 및/또는 엔티티가 갖는 특수한 비밀 또는 키)가 장치 인증 처리에서 사용되거나 장치 인증 처리에 의해 사용되는 물리적 엔티티(예를 들면 응용 소프트웨어 파일 또는 데이터 또는 키)에 대한 직접 대응 관계를 가지는 물리적 결속이 수행될 수 있다.

도 3은 장치의 기능으로서 표시된 2가지 다른 유형의 결속을 보인 도이다. 양자의 경우에, 실제 장치 무결성 확인 절차는 신뢰성 엔티티, 예를 들면 장치에 보안적으로 매립된 하드웨어 기반 보안 환경에 의해 수행될 수 있다. H(e)NB와 관련해서, 이러한 신뢰성 엔티티는 H(e)NB의 TrE라고 부른다. 도 4는 1) 장치의 무결성 체크뿐만 아니라 2) 장치 인증의 중요한 또는 민감한 기능을 수행하는 공통 TrE를 이용하는 결속 메카니즘을 보인 도이다.

도 4에서, 보안 및 신뢰성 TrE는 통신 또는 컴퓨팅 장치 내에 위치할 수 있다. TrE는 하나 이상의 하기 기능을 수행한다. 확인이 장치에서 국부적으로 수행될 수 있는 경우에 장치 무결성 확인과 같은 장치 무결성 체크. TrE는 도 4의 인터페이스 (1) 및 TrE 내에 또는 TrE에 의해 저장된 확인용의 크리덴셜에 액세스 및 사용하기 위한 능력을 포함할 수 있다. TrE는 도 4의 인터페이스 (3) 및 TrE 내에 또는 TrE에 의해 저장된 장치 인증용의 비밀 크리덴셜에 액세스 및 사용하기 위한 능력을 포함한 보안 처리를 요구하는 장치 인증 처리의 보안 부분일 수 있다. 다른 능력은 보안 민감성 처리를 필요로 하는 TrE의 외측에 있는 응용들을 지원하기 위해 보안 처리를 수행하는 것을 포함할 수 있다. 이 응용들은 그들 자신의 비밀 크리덴셜(도 4에는 도시되지 않음)에 액세스 또는 사용할 수 있다. TrE는 TrE의 외측에 있는, 장치의 기능/응용에 대한 인터페이스를 포함할 수 있다. 그 예로는, 비제한적인 예를 들자면, 장치에서 장치 인증 처리를 위한 도 4의 인터페이스 (2), 및/또는 TrE 내로부터 보안 처리를 요구하는 다른 비인증 응용을 위한 도 4의 인터페이스 (5)가 있다.

또한, 장치의 비 TrE 부분은 하나 이상의 하기 유형의 기능을 수행할 수 있다. 하나의 기능은 장치 인증 기능의 비 보안 부분일 수 있다. 다른 하나의 기능은 TrE로부터 보안 처리를 요구하지 않는 응용을 위한 것일 수 있다. 다른 하나의 기능은 TrE로부터 보안 처리를 요구하는 응용(장치 인증 이외의 것)을 위한 것일 수 있다. 장치의 비 TrE 부분은 장치 인증, 장치 능력 간의 메시지 교환(d) 및/또는 네트워크 기반 AAA 서버(g)를 위한 도 4의 인터페이스 (4)를 포함한 인터페이스를 지원할 수 있다. 도 4의 인터페이스 (6)은 장치 측의 TrE 내로부터 보안 처리를 요구하는 기능에 대한 메시지 교환을 위해 사용될 수 있다. 도 4의 인터페이스 (7)은 장치 측의 TrE 내로부터 보안 처리를 요구하지 않는 기능에 대한 메시지 교환을 위해 사용될 수 있다. 장치 인증을 위해 사용되는 크리덴셜 및 장치 무결성 확인을 위해 사용되는 크리덴셜은 동일하지 않을 수 있다. 그러나, 이러한 크리덴셜은 서로에 결속되도록 구성될 수 있다.

도 4는 H(e)NB에서 물리적 결속을 이용할 수 있는 장치의 예를 보인 것이다. 예를 들면, 물리적 결속은 확인 및 장치 인증 둘 다를 위해 TrE를 이용하여 수행될 수 있다. 예를 들면, H(e)NB에서, TrE는 장치 확인에 필요한 전체 처리를 수행하도록 설계될 수 있다. 이러한 처리는 장치 인증에 필요한 처리의 가장 안전하거나 신뢰성있는 처리를 요구하는 처리의 적어도 일부 또는 전체 처리 자체를 포함할 수 있다. 예를 들어서, 만일 장치 인증 프로토콜이 EAP-AKA와 같은 사전 공유된 키 기반 방법을 사용하도록 설계되면, AKA 크리덴셜을 보유하는 TrE 및 H(e)NB는 서로에게 더욱 결속될 수 있다. 예를 들면, H(e)NB는 장치 인증에 사용되는 AKA 크리덴셜을 계산하는데 필요한 데이터를 암호화하고, 이 암호화가 데이터를 TrE에 운반하기 전의 TrE에 제한되게 할 수 있다. TrE는 이 데이터를 복호하는데 필요한 키를 안전하게 저장할 수 있다. 또한, IKEv2와 같은 공통 보안 프로토콜의 동일한 세션에서 장치 확인 및 장치 인증에 관한 정보의 결합에 의해 추가의 결속이 획득될 수 있다. 이 경우에, 이러한 결속에 적합한 장치 확인은 H(e)NB(및 그 TrE)와 네트워크 엔티티 간에 특정의 상호작용 및 메시지 교환을 요구하도록 될 수 있다.

앞에서 설명한 것처럼, 논리적 결속은 장치 확인 및 인증을 위해 사용되는 다른 유형의 결속이다. 논리적 결속의 예는 장치 확인 및 장치 인증의 목적으로 장치 외부로 전송될 필요가 있는 메시지를 수행하기 위해 동일한 또는 공통 통신 프로토콜 메시지의 동일한 패킷, 메시지, 세션 또는 연속 세션을 사용할 수 있다. 물리적 결속 방법 및 논리적 결속 방법은 서로 조합되어 사용될 수 있다.

장치 확인은 사전 공유된 비밀 기반 클라이언트 인증을 위해 결속될 수 있다.

H(e)NB의 장치 확인은 하기의 물리적 및/또는 논리적 결속 메카니즘 중의 하나 또는 임의의 조합에서 사전 공유된 키 기반 인증에 결속되도록 수행될 수 있다. TrE와 나머지 H(e)NB 간의 메시지 교환을 위한 암호화 키 및 크리덴셜을 이용하여 신뢰성 환경(TrE)을 H(e)NB에 물리적으로 결속함으로써, 키 및 크리덴셜은 적어도 TrE 및 H(e)NB 내에서 보호될 수 있다. 이것은 장치 인증을 위해 TrE와 H(e)NB 간의 메시지 교환에 적용할 수 있다.

도 5를 참조하면, TrE는 H(e)NB의 무결성을 먼저 체크할 수 있다. 만일 성공이면, TrE는 도 5의 링크 (2)로 진행하고, 만일 성공이 아니면 TrE는 링크 (2)로 진행하지 못하지만 그 대신에 아마도 H(e)NB의 장치 인증 기능을 포함한 기능을 잠금(lock)할 수 있다. H(e)NB의 무결성을 체크하기 위해, TrE는 TrE에 저장된 장치 확인 크리덴셜을 이용할 수 있다(도 5의 링크 (1) 참조).

링크 (2)에서, TrE는 키 쌍을 구비할 수 있고, 그 중에서 개인키 부분은 TrE 내측에 보안적으로 저장되고 공개키 부분은 H(e)NB가 이용할 수 있다. H(e)NB의 제조자는 이 키 쌍을 생성하여 공개키가 H(e)NB에게 이용가능으로 되게 하는데 필요한 증명서(certificate)를 제공할 수 있다. TrE의 장치 확인 기능은 TrE 개인키를 이용하여 (도 5에 도시된 링크 (2)에서) 메시지를 서명하여 예컨대 하기의 것 중 하나 이상을 TrE 외부의 장치 인증 기능에 표시할 수 있다: TrE의 ID, TrE가 나머지 H(e)NB의 무결성을 성공적으로 검증하였음을 표시하는 메시지, 및/또는 TrE가 장치 인증 기능을 인가하고 장치 인증 절차로 진행하도록 인가되었음(authorized)을 표시하는 인가(authorization) 데이터. TrE 개인키는 이 인가 메시지를 서명하기 위해 사용될 수 있다. 이 인가 메시지는 H(e)NB 장치에서의 장치 인증 기능에 의해 TrE의 일부 보안 처리 기능의 사용을 인가할 수 있다.

TrE로부터 TrE 외부의 장치 인증 기능으로 서명된 메시지를 전송하는 것은 도 5에서 링크 (3)으로 도시되어 있다. H(e)NB는 위의 링크 (2)에서 묘사된 서명을 검증할 필요가 있는 TrE 공개키를 이용할 수 있다. 공개키는 증명서로 사전 공급될 수도 있고, 그렇지 않고 그 사용 전에 장치 인증 기능에 이용가능하게 될 수도 있다. 공개키의 사용은 도 5에서 라인 (4)로 표시되어 있다.

장치 인증 기능은 TrE 내에 존재하는 장치 인증을 위한 보안 처리 능력을 이용하여, 후자에 대하여, 장치 인증 절차에 필요한 보안 민감성 기능을 수행할 수 있다. 이 서비스를 요청하고 획득하기 위한 인터페이스는 도 5에서 라인 (5)로 표시되어 있다. 장치 인증을 위한 보안 처리 능력은 TrE에 사전 저장된 비밀 장치 인증 크리덴셜을 이용하여, 장치 인증 기능이 후자에 대하여 H(e)NB 장치를 인증하기 위해 AAA 서버에 전송할 필요가 있는 데이터를 계산할 수 있다. 이것은 도 5에서 라인 (6)으로 표시되어 있다.

장치 인증 기능은 AAA 서버가 H(e)NB 장치의 아이덴티티를 인증할 수 있도록, AAA 서버와 함께 TrE에 의해 제공된 장치 인증을 위한 보안 처리 능력으로부터 계산된 데이터를 포함한 데이터를 교환하도록 진행할 수 있다. 이것은 도 5에서 라인 (7)로 표시되어 있다. 이 기능은 적당한 메시지 교환 프로토콜로 운반될 수 있다. 예를 들면, H(e)NB의 경우에, IKEv2, TLS, TR069(애플리케이션 층 프로토콜), OMA-DM 프로토콜과 같은 프로토콜, 또는 HTTPS와 같은 상위 계층 프로토콜까지도 생각할 수 있다. 장치 인증 기능은 보안 비민감(security-insensitive) 기능 자체를 수행할 수 있다는 점에 주목한다.

확인 및 장치 인증은 장치 확인의 절차 및 동일한 패킷 또는 동일한 메시지를 이용한 인증 절차의 지정된 부분을 H(e)NB 및 TrE가 종합적으로 수행하게 함으로써 결속될 수 있다. 이것은 공통 통신 세션 또는 공통 보안 프로토콜의 연속 세션에서 수행될 수 있다. 이러한 프로토콜의 예로는 IKEv2 프로토콜, TLS, TR069, OMA-DM 및 HTTPS가 있다. 프로토콜은 사전 공유 비밀 기반 프로토콜, 비대칭 키 기반 프로토콜, 대칭 키 기반 프로토콜 등을 이용할 수 있다.

도 6은 확인 데이터 및 인증 데이터의 일부가 동일한 프로토콜/세션/메시지로 보내질 수 있는 이러한 결속 메카니즘의 예를 보인 것이다. 도 6에서, 라인 (1)은 TrE 내측의 장치 확인 기능(device validation function; DVF)이 필요한 장치 무결성 체크를 수행하여, H(e)NB의 컴포넌트의 무결성이 보전되어 있는지 여부를 장치 확인 크리덴셜을 이용하여 검증하는 것을 나타내고 있다. DVF는 TrE의 크립토그래픽 능력(TrE's cryptographic capability; TCC)에 의해 제공된 기능을 이용하여 장치 무결성 체크 및 검증을 위해 필요한 일부 기능을 수행한다는 점에 주목한다. 이 관계는 도 6에서 점선 (A)로 표시되어 있다.

어떤 나중의 시간에, H(e)NB 내측의 장치 인증 기능(device authentication function; DAF)은 디피-헬만(D-H) 절차와 같은 절차를 수행하여 그 자체와 외부 AAA 서버 간의 암호화 및 서명을 위한 비인증 공유키를 설정할 수 있다. 이 단계는 라인 (7-a)로 표시되어 있고, 장치 인증을 위한 전조 단계일 수 있으며, 메시지 프로토콜에 따르는 장치 인증 중에 사용하기 위한 비인증 크립토그래픽 키를 구성할 수 있다. DAF는 TrE의 크립토그래픽 능력(TCC)에 의존하여 D-H 절차에 필요한 중간 단계(interim-step)의 일부를 수행할 수 있다는 점에 주목한다. 점선 (C)는 DAF가 TCC로부터 크립토그래픽 서비스를 요청 및 획득하기 위해 사용할 수 있는 TCC와 DAF 간의 인터페이스일 수 있다.

DAF는 장치_인증_개시_요청(Dev_Auth_Init_Request) 메시지를 AAA 서버에 전송함으로써 장치 인증 절차를 개시할 수 있다. 예를 들어서, 만일 IKEv2 프로토콜이 사용되었으면, 이 메시지는 IKE_SA_INIT 요청 메시지로 운반될 수 있다. 이 장치_인증_개시_요청 메시지에서, DAF는 헤더(HDR), 다른 무엇보다도 AAA 서버에 대한 보안 파라미터 지수(security parameter index; SPI)를 제안하는 보안 연합(security association; SA), D-H 처리에서 발생된 서버의 공개키 KE_DH, 및/또는 장치 자신의 ID(Dev_ID)를 포함할 수 있다. 이 단계는 도 6에서 라인 (7-b)로 표시되어 있다.

AAA 서버는 DAF의 장치_인증_개시_응답(Dev_Auth_Init_Response)(만일 IKEv2가 프로토콜로서 사용되었으면 IKE_SA_INIT 응답 메시지)을 장치의 DAF에 전송할 수 있다. 이 메시지는 헤더(HDR), D-H 처리에서 발생된 장치의 공개키(KE_DH), 및 서버 자신의 ID(svr_ID)와 같은 정보 요소를 포함할 수 있다. 이 단계는 도 6에서 라인 (7-c)로 표시되어 있다.

DAF는, 도 6에 라인 (7-d)로 표시된 것처럼, 헤더, SA, Dev_ID, 구성(CONFIG), 및/또는 선택적인 서버 증명서 요청(Svr_Cer_REQ)과 같은 요소를 장치_인증_요청(Dev_Auth_Request) 메시지(이것은 IKEy2가 선택된 프로토콜인 경우에 IKE_AUTH 요청 메지시일 수 있다)로 AAA 서버에 전송할 수 있다. 여기에서부터, 정보 요소의 일부는 D-H 처리로부터 발생된 키에 의한 암호화 및 서명에 의해 보호될 수 있다는 점에 주목한다. 예를 들면, Dev_ID, 세션_ID, CONFIG, 및 선택적인 서버 증명서 요청은 D-H 처리에서 발생된 키를 사용함으로써 비밀성 및 무결성이 모두 보호될 수 있다. DAF는 D-H 발생 키를 이용하여 암호화 및 서명을 수행하기 위해 TrE 크립토그래픽 능력(TCC)을 이용할 수 있다는 점에 주목한다. 이 관계는 도 6에 라인 (B)로 표시되어 있다.

AAA 서버는, H(e)NB와 AAA 서버 간의 공유 인증 비밀(도 6에서 TrE 내에 저장되는 것으로 도시됨)에 기초한 인증 도전(Auth-Challenge)이 DAF에 의해 요청된 경우에, 다른 무엇보다도, 헤더, Svr_ID, 세션_ID, 및 선택적으로 서버 증명서(Svr_Crt)와 같은 요소를 포함한 장치_인증_응답(Dev_Auth_Response) 메시지(이것은 IKEy2가 프로토콜로서 사용된 경우에 IKE_AUTH 응답 메지시일 수 있다)를 DAF에게 전송할 수 있다. 이것은 도 6에 라인 (7-e)로 표시되어 있다.

DAF는, 다른 무엇보다도, 헤더, Dev_ID, 세션_ID, 인증 도전 응답(AUTH) 및/또는 확인 데이터(Validation_Data) 등을 포함한 장치_인증_요청(Dev_Auth_Request) 메시지(이것은 IKEv2가 사용된 경우에 다른 IKE_AUTH 요청 메지시일 수 있다)를 AAA 서버에게 전송할 수 있다. 이것은 도 6에 라인 (7-f)로 표시되어 있다. DAF는 도 6에서 라인 (3)으로 표시된 것처럼 AUTH를 계산하고 회송하기 위해 TrE에서 장치 인증을 위한 보안 처리 능력(Secure Processing Capability for Device Authentication; SPC_DA)에 의존할 수 있다는 점에 주목한다. SPC_DA는 도 6에서 라인 (4)로 표시된 것처럼 TrE에 저장된 사전 공유 인증 비밀 크리덴셜을 이용하여 AUTH를 계산할 수 있다는 점에 주목한다. 또한, SPC_DA는 TrE의 크립토그래픽 능력(TCC)에 의존할 수 있다(점선 (C) 참조). SPC는 AUTH를 계산할 수 있다는 점에 주목한다. 장치 확인 기능(DVF)은 도 6에서 라인 (5)로 표시된 것처럼 확인 데이터를 DAF로 회송하기 전에 TrE 개인키를 이용하여 확인 데이터 및 임의의 추가의 관련 보충 데이터를 또한 서명할 수 있다. DVF와 TrE 개인키 간의 인터페이스는 확인 데이터를 DAF로 회송하기 전에 확인 데이터를 서명하기 위해 사용될 수 있고, 이것은 라인 (2)로 표시되어 있다. 이 예에서, 확인 및 장치 인증(또는 그 일부 보안 필요 부분)을 수행하기 위해 공통 TrE 및 그 자산(asset)을 이용한 물리적 결속 외에, 다른 논리적 결속 메카니즘이 사용될 수 있다. 동일한 프로토콜, 동일한 세션 및 동일한 메시지가 장치 확인(즉, 확인 데이터) 및 장치 인증(즉, AUTH)의 결과에서의 정보 요소를 장치로부터 AAA 서버로 전송하기 위해 사용될 수 있다.

이전의 장치_인증_요청(Dev_Auth_Request) 메시지로부터 AUTH 파라미터 및 확인 데이터를 수신하고 평가한 후에(6 참조), AAA는 AAA 서버가 인증을 성공으로서 평가하는지 아닌지를 장치의 DAF에게 표시하기 위한 장치_인증_응답(Dev_Auth_Response) 메시지를 전송할 수 있다. 이것은 도 6의 라인 (7-g)로 표시되어 있다.

결속 메카니즘에 있어서, TrE는, DAF에 대하여 또는 SPC_DA에 대하여, 인증의 성공적 완료를 위한 필요한 출력을 계산하는데 필요할 수 있는 민감성 기능 또는 민감성 데이터에 대한 액세스를 제어 및 해제할 수 있고, 이것은 액세스가 허용되도록 성공적으로 완료되는 장치 확인 절차에서 먼저 조절될 수 있다. 이 유형의 결속 메카니즘은 물리적 및 논리적 결속 메카니즘으로서 고려될 수 있다. 도 7은 그러한 결속 메카니즘의 예를 보인 것이다.

도 7을 참조하면, DVF는 TrE에 보유된 기능 또는 데이터의 일부에 대한 액세스를 허용하는 것과 관련하여 2가지 유형의 게이팅 절차를 수행할 수 있다. 게이팅 절차는 장치 무결성 확인 결과의 상태에 의존할 수 있다. 만일 장치 무결성 확인 결과가 성공이 아니면, DVF는 도 7에서 라인 (A: 게이팅)으로 표시된 것처럼, DAF가 TrE의 SPC_DA에 액세스하는 것을 금지할 수 있다. DVF는 SPC_DA가 AAA 서버에 대하여 성공적 인증을 수행하는데 필요한 장치 인증 크리덴셜에 액세스하는 것을 금지할 수 있다. 이러한 유형의 게이팅 기능은 장치 확인과 장치 인증 사이에서 다른 유형의 논리적 결속을 제공할 수 있다.

장치 확인은 증명서 기반 장치 인증과 같은 인증에 결속될 수 있다.

H(e)NB의 장치 확인은 증명서 기반 클라이언트에 결속될 수 있고, 인증은 위에서 설명한 것과 유사한 메카니즘을 이용하여 달성될 수 있다. 가능한 메카니즘 중의 일부는 뒤에서 설명된다. 도 8은 물리적 결속을 이용하는 예를 보인 도이고, 여기에서 공통 TrE는 장치 무결성 체크 및 확인뿐만 아니라 장치 인증에 필요한 기능들의 일부 또는 전부를 수행할 수 있다. 이 기능들은 예를 들면 장치 증명서에 기초를 둘 수 있다. 절차는 SPC_DA에 의한 장치 인증을 위해 사용되는 크리덴셜이 장치 인증을 위한 개인키(Private Key for device Authentication; Kpriv_DA)일 수 있다는 점 및 장치 인증 기능(DAF)이 Kpriv_DA에 의해 계산된 일부 다른 자료와 함께 장치 증명서(Device Certificate; DevCert)를 AAA 서버에 전송한다는 점을 제외하면 도 5에서 설명한 것과 동일하다.

도 8을 참조하면, SPC_DA와 Kpriv_DA 간의 관계에 액세스하고 그 관계를 이용하는 키는 라인 (6)과 관련하여 도시한 것처럼 될 수 있다. DAF와 DevCert 간의 관계에 액세스하고 그 관계를 이용하는 증명서는 라인 (8)과 관련하여 도시한 것처럼 될 수 있다.

H(e)NB와 TrE는, IKEv2 프로토콜과 같은 공통 보안 프로토콜의 공통 통신 세션 또는 연속 세션에서, 장치 확인의 절차 및 증명서 기반 클라이언트 인증의 절차의 지정된 부분을 동일한 패킷, 메시지로 종합적으로 수행할 수 있다. 실질적으로, 이 결속 메카니즘의 처리는 도 6에서 설명한 것과 유사할 수 있다. 도 6을 다시 참조하면, 사전 공유 비밀 기반 장치 인증이 사용되는 경우와 비교할 때의 차이점은 다음과 같다. AAA 서버로부터의 AUTH 도전 및 TrE가 보유하는 사전 공유된 비밀에 기초하여 민감성 중간 결과를 계산(및 SPC_DA를 이용하여 계산하고 계산 결과를 DAF에 회송)하는 대신에, SPC_DA는 AAA 서버 및 Kpriv_DA로부터의 AUTH-도전에 기초하여 AUTH-도전으로부터 이들을 계산할 수 있다. AAA 서버는 DAF에 대한 장치 인증 증명서(DevCert)를 요청할 수 있다. 이에 응답하여, SPC_DA와 함께 작용하는 DAF는 1) Kpriv_DA를 이용한 인증 응답(AUTH), 및/또는 2) DevCert를 계산하여 AAA 서버에 회송할 수 있다. AUTH 및 DevCert를 수신한 때, AAA 서버는 DevCert의 유효성을 먼저 검증하고, 그 다음에 그 유효성을 이용하여 AUTH를 검증할 수 있다. 만일 검증이 체크되면, 장치가 인증될 수 있다.

이러한 차이점이 있음에도 불구하고, 논리적 결속이 관계있는 한, 논리적 결속은 사전 공유 비밀 기반 인증의 경우와 유사하게 수행될 수 있다. 예를 들면, DAF는 AUTH 및 DevCert를 AAA 서버에 회송하고, 동일한 메시지에 확인 데이터를 또한 포함시킬 수 있다. 이 확인 메시지는 TrE 내측의 DVF로부터 획득될 수 있고, TrE 개인키를 이용하여 DVF에 의해 서명될 수 있다.

도 9는 예시적인 결속 메카니즘을 보인 도이다. 이 예에서는 AAA 서버로부터 장치까지 인증 도전 자체가 없다. 오히려, 서버가 장치에게 그 증명서(DevCert)를 전송하도록 요청(라인 (7-c) 참조)한 후에, 장치는, 라인 (7-d)로 표시된 것처럼, 그 DevCert뿐만 아니라 AUTH(Kpriv_DA로부터 계산된 것)를 AAA 서버에 보낼 수 있다. AAA 서버는 DevCert에 대하여 AUTH를 검증하고 인증 상태의 확인을 보낼 수 있다(7-e).

게이팅 유형의 결속은 증명서 기반 인증 예에서 구현될 수 있다. 이 예는 사전 공유 비밀 기반 인증 예와 유사하다. 도 10은 이러한 결속 메카니즘의 예를 보인 도이다. 도 10을 참조하면, DVF는 장치 무결성 확인 결과의 상태에 의존하여, TrE에 보유된 기능 또는 데이터의 일부에 대한 액세스 허용과 관련하여 2가지 유형의 게이팅 절차를 수행할 수 있다.

만일 장치 무결성 확인 결과가 성공이 아니면, DVF는 도 10에서 라인 (A:게이팅)으로 표시된 것처럼, DAF가 TrE의 SPC_DA에 액세스하는 것을 금지할 수 있다. 대안적으로, DVF는 SPC_DA가 AAA 서버에 대한 성공적 인증을 수행하는데 필요한 Kpriv-DA에 액세스하는 것을 금지할 수 있다. 이러한 유형의 게이팅 기능은 장치 확인과 장치 인증 사이에서 다른 유형의 논리적 결속을 제공할 수 있다.

다른 본질적 장치 기능에 대한 장치 무결성 확인의 일반화 결속이 제공될 수 있다.

위에서 설명한 것처럼, 장치 무결성 확인과 장치 인증 간의 결속의 개념은 일반적으로 장치 무결성 확인의 프로세스, 사용된 입력 및/또는 중간 데이터, 및/또는 결과가 인증의 절차 또는 프로세스를 "게이트"할 수 있음을 의미한다.

결속의 개념은 결속이 구현되는 장치의 유형과 관련해서, 및 장치 무결성 확인의 처리에 결속되는 장치의 기능과 관련해서 일반화될 수 있다. 가장 일반적인 관점에서, 결속은 만일 자신의 장치 무결성을 체크, 보고 및/또는 검증하는 능력을 가진 장치(D)가 있으면, 그것만으로, 또는 장치의 본질적 기능으로서 고려될 수 있는 적어도 하나의 기능(X)을 수행하기 위한 외부 엔티티 및/또는 능력으로 대화식 처리를 수행함으로써 구현되도록 일반적으로 고려될 수 있다. 본질적인 기능은, 의도된 대로 수행하지 않고, 장치(X)가 통상의 유용한 감각으로 동작한다고 생각되지 않는 기능이다. 이동 전화기와 같은 장치의 본질적인 기능의 예는 재난(distress) 경보를 보내는 능력, 가입자 인증(네트워크에 대해), 장치 인증, 코어 애플리케이션, 통신 스택 실행, 사용자 인증(장치에 대해), 장치 관리 기능, 무선 신호의 송신 또는 수신, 장치 전원 공급 및 관리 기능 중의 하나 이상을 포함할 수 있다.

결속은 장치 무결성 확인 처리의 데이터(D_V), 절차(P_V), 또는 결과(R_V)가 본질적 기능(X)의 성공적 수행을 위해 상기 D_V, P_V 및/또는 R_V 간의 유일하고 위조 또는 복제가 어렵거나 불가능한(hard-or-impossible-to-fake-or-clone) 관계를 표시할 수 있는 절차로서 규정 및 구현될 수 있다. 앞의 섹션에서 설명한 3가지 유형의 결속 메카니즘, 즉 크립토그래픽 수단의 공유 존재 및 사용에 기인하는 결속, 동일하거나 연속적인 통신 프로토콜 패킷, 메시지, 세션 또는 세션들에 기인하는 결속, 및/또는 장치(D)의 성공적 확인시에 조절될 수 있는 본질적 기능(X)의 성공적 수행을 위해 중요한 데이터(D_V) 또는 절차(P_V)에 대한 게이팅 또는 조건적 액세스에 기인한 결속이 다시 적용될 수 있다.

도 11은 제2 유형의 결속, 즉 게이팅 유형의 결속이 장치(X)에서의 기능과 확인 처리(DVF) 사이에서 사용될 수 있는 경우의 예를 보인 것이다. TrE는 기능 X의 보안 절차 능력(Secure Procedure Capability for Function X; SPC_X)과 기능 X에 필요한 민감성 데이터(Sensitive Data required for function X; SD_X)를 그 내부에 가질 수 있다. DVF는 장치(X) 자체에서의 기능뿐만 아니라, 기능에 의해 필요로 하는 장치의 비 TrE 부분에서의 임의의 데이터(D_X), 장치(D)에 매립된 또는 장치(D)에 접속된 컴포넌트/모듈에서의 기능(X_EC), 및 사용가능한 네트워크 기반 기능(X_N) 및 데이터(D_X_N)를 또한 게이트할 수 있다.

도 11은 복수 유형의 게이팅(A~G)을 보인 것이고, 여기에서 DVF는, 장치 무결성 확인의 결과에 따라서, A) 보안 처리 능력 SPC_X, 및/또는 B) 기능 SPC_X를 위해 필요한 TRE 내측의 민감성 데이터 SD_X, 및/또는 C) TRE 내측 또는 외측에 있을 수 있는 장치(X)에서의 임의 기능, 및/또는 D) TRE 내측 또는 외측에 있을 수 있고 임의 기능 X에 의해 소용될 수 있는 장치에서의 데이터, 및/또는 E) 장치에서의 임베디드 컴포넌트(예를 들면, SoC) 또는 장치(예를 들면, UICC)에 접속된 별도 모듈에서의 임의의 기능 X_EC, 및/또는 F) 외부 엔티티(즉 네트워크로부터)에 의해 수행되는 임의의 기능 X_N, 및/또는 G) 이러한 임의의 외부 기능 X_N에 의해 소용되는 임의의 데이터 D_X_N에 대한 액세스를 게이트할 수 있다.

절차 X의 예는 예를 들면, 라디오 및 기저대역 송신 및 수신, 장치 전력 관리(온/오프를 포함함), 사용자 인터페이스, 미디어 프로세서 기능, GPS 및 다른 위치확인 기능, 타이머 및 타이밍 동기화 기능과 같은 통신 기능; 및 WLAN, 블루투스, 셀룰러 통신, 웹 기능과 같은 고급 애플리케이션, 싱글 사인온 및 식별 연합 및 관리 기능, 코덱 기능과 같은 음성 및 기타 미디어 기능, 게임 기능과 같은 통신 기능; 및 가입자 인증, 장치 인증, 애플리케이션에 대한 인가, 암호화/복호를 포함한 크립토그래픽 동작 및 서명 및 서명 검증과 같은 각 기능에 대한 보안 절차; 및 장치에 대한 임의의 다른 기능 등의 기능을 포함할 수 있다는 점에 주목한다.

SPC_X는, 비제한적인 예를 들자면, 크립토그래픽 암호화/복호화, 서명 생성 또는 검증, 난수 생성 또는 사용, 타이밍 동기화 및 타임 스탬핑, 메시지 인증 코드 생성 및 검증, 암호키 생성, 유도, 또는 관리(기원(deprecation) 또는 고립(quarantining)을 포함함), 증명서 검증, 및 TRE, 장치의 사용자, 장치 자체, 또는 장치의 가입자 및/또는 소유자의 인증 또는 인가를 위해 필요한 비밀 자료의 계산을 포함할 수 있다.

기능 X_EC의 예로는, 비제한적인 예를 들자면, 데이터 저장 및 취급 기능, 인증 기능, 키 생성 및 사용, 암호화/복호화, 서명 생성 및 검증, 구성 관리 등을 포함할 수 있다.

기능 X_N의 예로는, 비제한적인 예를 들자면, 데이터 저장 및 취급 기능, 장치 관리 및 공급과 같은 작업을 위한 네트워크 제공 애플리케이션, 고급 애플리케이션(예를 들면, 웹 접속 등), DRM, 음성 및 멀티미디어 서비스 및 게임 기능, 장치 관리 서비스, 통신 서비스, 싱글 사인온 및 식별 연합 및 관리 등을 포함할 수 있다.

게이팅 절차는 캐스케이드로서 수행될 수 있다. 즉, DVF는 하나의 애플리케이션에 대한 액세스를 게이트할 수 있고, 그 애플리케이션은 다른 애플리케이션 또는 데이터 등에 대한 액세스를 게이트할 수 있다. DVF는 복수의 절차 또는 데이터를 게이트할 수 있고, 그중 일부 또는 전부는 원인 또는 대응 관계를 가질 수 있다.

비록 특징 및 요소들을 특수한 조합으로 위에서 설명하였지만, 각 특징 또는 요소는 다른 특징 및 요소 없이 단독으로 또는 다른 특징 및 요소와 함께 또는 다른 특징 및 요소 없이 각종 조합으로 사용될 수 있다. 여기에서 제공되는 방법 또는 흐름도는 범용 컴퓨터 또는 프로세서에 의해 실행되는 컴퓨터 판독가능 기억 매체에 통합된 컴퓨터 프로그램, 소프트웨어 또는 펌웨어로 구현될 수 있다. 컴퓨터 판독가능 기억 매체의 예로는 읽기 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 레지스터, 캐시 메모리, 반도체 메모리 소자, 내부 하드 디스크 및 착탈식 디스크와 같은 자기 매체, 자기 광학 매체, 및 CD-ROM 디스크 및 디지털 다기능 디스크(DVD)와 같은 광학 매체가 있다.

적당한 프로세서는, 예를 들자면, 범용 프로세서, 특수 용도 프로세서, 전통적 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서, DSP 코어와 연합하는 하나 이상의 마이크로프로세서, 컨트롤러, 마이크로컨트롤러, 용도 지정 집적회로(ASIC), 현장 프로그램가능 게이트 어레이(FPGA) 회로, 임의의 다른 유형의 집적회로(IC), 및/또는 상태 기계 등을 포함한다.

프로세서는 소프트웨어와 연합해서 무선 송수신 유닛(wireless transmit receive unit; WTRU), 사용자 장비(user equiipment; UE), 단말기, 기지국, 무선 네트워크 제어기(radio network controller; RNC), 또는 임의의 호스트 컴퓨터에서 사용되는 라디오 주파수 송수신기를 구현하도록 사용될 수 있다. WTRU는 카메라, 비디오 카메라 모듈, 비디오폰, 스피커폰, 진동 장치, 스피커, 마이크로폰, 텔레비전 송수신기, 핸즈프리 헤드셋, 키보드, 블루투스® 모듈, 주파수 변조(FM) 라디오 유닛, 액정 디스플레이(LCD) 표시장치, 유기 발광 다이오드(OLED) 표시장치, 디지털 뮤직 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 및/또는 임의의 무선 근거리 통신망(WLAN) 또는 초광대역(UWB) 모듈과 같은, 하드웨어 및/또는 소프트웨어로 구현되는 모듈과 함께 사용될 수 있다.

네트워크 장치의 무결성 확인을 수행하기 위한 시스템, 방법 및 설비가 개시된다. 네트워크 장치는 보안 메모리를 포함할 수 있다. 예를 들면, 보안 메모리는 보안 하드웨어 모듈을 포함할 수 있다. 보안 메모리는 루트 키를 수신할 수 있다. 예를 들면, 루트 키는 제조시에 또는 공급시에 보안 메모리에 의해 수신될 수 있다. 루트 키는 보안 메모리에 저장될 수 있고, 보안 하드웨어 모듈 외부의 소프트웨어 또는 하드웨어에게 보이지 않을 수 있다.

보안 하드웨어 모듈은 제1 코드 측정치(제1 코드의 측정치)를 수신할 수 있다. 예를 들면, 보안 하드웨어 모듈을 포함한 네트워크 장치와 연관된 프로세서 등의 프로세서는 측정할 코드의 제1 부분을 선택할 수 있다. 코드의 제1 부분은 네트워크 장치와 연관된 메모리, 예를 들면, ROM 메모리, RAM 메모리 등에 저장될 수 있다. 프로세서는 코드의 선택된 제1 부분을 측정하여 제1 코드 측정치를 발생할 수 있다. 프로세서는 측정치를 보안 하드웨어 모듈에 제공할 수 있다.

보안 하드웨어 모듈은 루트 키 및 제1 코드 측정치에 기초하여 제1 키를 발생할 수 있다. 예를 들면, 보안 하드웨어 모듈은 제1 키를 유도 또는 해제할 수 있다. 발생된 제1 키는 제1 코드 측정치가 유효일 때 유효이고, 제1 코드 측정치가 무효일 때 무효이다. 예를 들면, 보안 하드웨어 모듈은 부분적으로 제1 코드 측정치에 기초하여 제1 키를 유도할 수 있다. 만일 제1 코드 측정치가 무효이면, 유도된 제1 키도 역시 무효이다. 발생된 제1 키는 자원에 대한 액세스를 제공하기 위해 보안 하드웨어 모듈에 의해 발생될 수 있다. 자원에 대한 액세스는 코드가 보안 메모리에 저장되어 있으면 코드 측정치 없이 제공될 수 있다.

제1 키는 제1 기능과 연관된 제1 신뢰 단계에 관한 것 있을 수 있다(예를 들면, 하나 이상의 자원이 제1 기능과 연관될 수 있다). 또한, 제1 이해관계자는 유효한 제1 키를 이용하여 제1 기능에 액세스할 수 있다. 만일 제1 키가 유효가 아니면, 제1 이해관계자는 제1 기능에 액세스할 수 없다. 즉, 보안 하드웨어 모듈은 제1 코드 측정치가 무효일 때 제1 기능에 대한 액세스를 금지할 수 있다.

보안 하드웨어 모듈은 제2 코드 측정치(제2 코드의 측정치)를 수신할 수 있다. 보안 하드웨어 모듈은 제1 키와 제2 코드 측정치에 기초하여 제2 키를 발생할 수 있다. 제2 키는 제2 기능과 연관된 제2 신뢰 단계에 관한 것 있을 수 있다(예를 들면, 하나 이상의 자원이 제2 기능과 연관될 수 있다). 또한, 제2 이해관계자는 유효한 제2 키를 이용하여 제2 기능에 액세스할 수 있다. 키 해제는 최종의 공지된 양호한 부팅 단계(예를 들면, 성공적 인증이 있었던 최종의 공지된 부팅 단계)로 제한될 수 있다.

하드웨어, 코드 및/또는 데이터의 무결성 측정치에 기초한 키 및 기능 등의 자원의 발생 및/또는 해제는 각 단계에서의 인증을 제공할 수 있다. 예를 들면, 장치는 수 개의 층을 포함하고 각 층은 그 자신의 인증 비밀을 가질 수 있다. 각 인증 비밀은 제조자 펌웨어, 신뢰성 실행 코드, 운영체제, 및 제3자 애플리케이션과 같은 장치 능력의 계층에 있는 특수 이해관계자에 대응할 수 있다. 다른 예로서, 유효한 제1 키는 제1 부팅 단계에 대한 유효 인증과 연관될 수 있다. 유효한 제1 키는 네트워크 장치의 펌웨어에 액세스하여 펌웨어에서의 교정을 수행하기 위해 장치 제조자(예를 들면, 제1 이해관계자)에 의해 사용될 수 있다. 유효한 제2 키는 나중의 부팅 단계(예를 들면 중간 부팅 단계) 중에 하나 이상의 소프트웨어 컴포넌트의 유효 인증과 연관될 수 있다. 유효한 제2 키는 소프트웨어 컴포넌트에 액세스하여 예를 들면 소프트웨어의 교정을 수행하기 위해 장치 관리자(예를 들면, 제2 이해관계자)에 의해 사용될 수 있다. 성공적으로 인증된 단계에 대하여 유효 키를 제공함으로써 실패 인증이 아닌 최종 단계에 상응한 액세스가 수여될 수 있다.

개시되는 다단계 인증에서의 단계의 수는 다르게 할 수 있고 제한되지 않는다. 또한, 복수의 인증 경로가 제공될 수 있다. 즉, 인증은 소정의 무결성 체크 단계에서 여러 가지 방법으로 나누어질 수 있다. 예를 들면, 각 이해관계자는 하나 이상의 인증 단계에 관한 하나 이상의 정책을 제공할 수 있다. 각 단계에서, 인증은 이해관계자 정책에 기초하여 여러 가지 방법으로 나누어질 수 있다. 이해관계자는 그 정책을 외부적으로 관리할 수 있다.

도 12는 장치(1200)의 예시적인 부팅 처리에 관한 복수의 단계에서의 인증을 보인 것이다. 장치(1200)는 계층화 부팅 단계 능력으로 구성될 수 있다(예를 들면, 하나 이상의 단계 인증과 연관된 하나 이상의 유효키를 해제하기 위해서). 장치(1200)가 제1 부팅 단계에 대하여 인증할 때, 장치(1200)는 1201에서 제조자 등의 제1 이해관계자에게 유효한 제1 키를 제공할 수 있다. 제1 부팅 단계는 낮은 수준의 인증이고, 제1 부팅 단계와 연관된 키는 제조자와 연관된 펌웨어로 제한되는 액세스를 제공할 수 있다. 장치(1200)가 제2 부팅 단계에 대하여 인증할 때, 장치(1200)는 1202에서 장치 관리자 등의 제2 이해관계자에게 유효한 제2 키를 제공할 수 있다. 제2 부팅 단계는 제1 부팅 단계보다 더 늦은 부팅 단계이고, 제2 부팅 단계와 연관된 키는 인증된 소프트웨어로 제한되는 액세스를 제공할 수 있다. 장치(1200)가 최종 부팅 단계에 대하여 인증할 때, 장치(1200)는 1203에서 코어 네트워크, 보안 게이트웨이 등에 대한 액세스를 제공할 수 있는 제3 이해관계자에게 유효 제3키를 제공할 수 있다.

예로서 부팅 처리를 이용하면, 부팅 실행시 제한된 온칩 자원에 대한 액세스 및 최종의 공지된 양호한 부팅 단계를 위한 인증 비밀이 해제될 수 있다. 이러한 단계화 해제는 장치에 대한 신뢰성있는 원격 장치 관리 갱신 절차를 위해 더 낮은 층을 이용하여 더 높은 코드 층에 대한 신뢰성있는 장치 소프트웨어/펌웨어 교정을 가능하게 한다. 이것은 보안 불변 온칩 신뢰의 근원(root of trust)으로부터 나오는 신뢰 사슬(chain of trust)에 의존할 수 있다. 예로서, 리세트시에, 제1 키를 해제하기 위해 특수한 칩 구성이 예상될 수 있다. 이 구성은 프로세서가 적당한 내부 실행 코드로 점프하는 것을 확실히 할 수 있고, 내부 실행 코드는 그 다음에 신뢰 사슬 실행의 다음 단계 전에 측정을 위해 코드 수집을 시작할 수 있다. 만일 예컨대 내부 ROM 코드에 대한 것이 아닌 점프 벡터와 같이 초기 칩 구성이 정확하지 않으면, 초기 및 후속 무결성 측정치는 예상된 것과 다를 수 있고, 장치는 다음 유효 단계로 진행하지 못할 수 있다.

제어의 형태는 온칩 자원의 하드웨어 앵커 게이팅, 컴포넌트의 측정된 무결성의 비교, 및/또는 시스템의 실제 측정된 무결성에 기초한 키의 유도를 포함할 수 있다. 예를 들면 후자의 경우에, 개시된 시스템 및 방법은 결과적인 키가 정상 동작을 위해 필요로 하는 것과 다를 수 있기 때문에, 다른 용도의 복수의 신뢰성있는 제어 실행 경로를 생성하기 위해 사용될 수 있다. 그래서, 예로서, 외부 엔티티가 장치의 핀에 대하여 직접 제어를 행할 수 있고, 이것은 다른 부팅 순서 및 그에 따라서 신뢰의 근원에 또한 기초한 다른 키를 발생할 수 있다.

인증은 종래의 파라미터 외에, 예를 들면 부팅 레벨마다 2개의 추가의 인증 계수를 부여함으로써 제공될 수 있다. 외부 엔티티에 대한 인증은 1) 부팅 단계 특유의 암호화 서명 비밀 또는 사이퍼 키(ciphering key)에 대한 지식을 요구할 수 있고, 이것은 2) 부팅 단계 특유의 코드가 정확한지(무결성 체크를 통과하는지)를 나타낼 수 있다.

결과적인 애플리케이션은 외부 엔티티가 그 엔티티에 의해 요구되는 기능에 따라서 장치의 무결성을 원격으로 확인하는 것일 수 있다. 게다가, 독립 이해관계자(예를 들면, 장치 또는 장치 제조자의 하드웨어 또는 각종 펌웨어 및 소프트웨어 계층의 것)는 다른 엔티티가 장치 기능을 정지시키지 않고 독립 이해관계자의 대응하는 펌웨어 또는 소프트웨어를 수정할 수 없게 하는 것이 보장될 수 있다.

예시적인 단계화 부팅 시퀀스는 부팅 처리의 다음 단계를 위하여 사이퍼 키, 서명키 및 무결성 측정치와 같은 온칩 자원 및 공급된 비밀을 잠금해제(unlock)하도록 크립토그래픽 키를 강화하기 위해 신뢰성 하드웨어 메카니즘을 검출 및 활용함으로써 시작할 수 있다. 각 단계가 성공적으로 체크되기 때문에, 온칩 자원과 새로운 비밀 및 측정치는 사용할 수 있게 된다.

일부 경우에, 정보는 핵심 신뢰성 영역에 있을 수 있고, 소프트웨어/펌웨어에 의한 보기(viewing) 또는 소유(possession)용이 아닌 하드웨어에 의한 사용에 충당될 수 있으며, 코드 베이스의 각 단계가 신뢰성 있는 것으로 체크 및 검증되기 때문에(예를 들면, 코드 체크, 데이터 체크, 하드웨어 체크 등에 기초하여 신뢰성 있는 것으로 검증됨) 온칩 자원 및 기타 정보가 실행 환경에 해제될 수 있다.

각각의 부팅 단계는 보안 부팅 처리의 그 장소에 대응하는 특권 및 제어에 대한 필요성을 가질 수 있다. 소정 단계에 대하여 배타적으로 생성된 크리덴셜을 가짐으로써 예를 들면 외부 엔티티에 대한 인증을 위해 제어가 플랫폼의 내부를 넘어서 연장할 수 있다.

예로서, 장치 관리 및 장치 인증의 경우에, 제조자는 펌웨어를 갱신할 특권을 가질 필요가 있는 반면, 네트워크 사업자는 펌웨어가 아닌 소프트웨어 및/또는 구성 데이터를 교정 또는 갱신할 필요가 있다. 만일 장치가 펌웨어의 무결성 체크를 통과하지만 소프트웨어에 대하여 실패하면, 이용가능한 키는 네트워크 사업자가 소프트웨어를 갱신하기 위해 장치를 인증할 수 있게 하는 것일 수 있다. 그러나, 만일 장치가 펌웨어 체크도 역시 실패하면, 관리 시스템에 대하여 장치를 인증하기 위한 키는 해제될 수 있지만, 네트워크를 인증하는데 필요한 키는 해제하지 않을 수 있다. 이것은 장치가 비보안 방식으로, 즉 신뢰의 근원 처리 밖에서 부팅될 수 없도록 원시 처리(primitive process)가 펌웨어를 원격으로 및 보안적으로 교정/인스톨하도록 제자리에 있을 수 있음을 의미한다. 펌웨어 실패는 교정을 돕는 대안적인 기능의 해제를 트리거할 수 있다(예를 들면, 인증은 실패에 기인하여 다른 분기를 취할 수 있다). 신뢰의 근원 증명을 제공하는 장점은 이것이 장치의 펌웨어 신뢰 코드 베이스의 원격 관리를 가능하게 한다는 것이다.

운용자 및 애플리케이션 제공자 등의 다른 이해관계자는 부팅 시퀀스 중에 측정의 결과에 의해 특징화되는 것처럼 시스템의 '신뢰성' 레벨에 기초하여 다른 키를 사용하도록 허용될 수 있다. 이것은 장치의 일부 운용자 또는 소유자가 아마도 복수의 단계에서 일부는 신뢰된 상태로, 그러나 일부는 신뢰되지 않은 상태로 시스템을 여전히 부팅할 수 있음을 의미한다. 그러한 상태에서도, 장치는 특정의 크립토그래픽 키를 생성하여 사용할 필요가 있다(예를 들면, 장치의 상태에 대하여 외부 사용자에게 표시할 목적으로, 또는 이러한 장치의 부분적 신뢰 상태하에서도 여전히 허용될 수 있는 애플리케이션의 보안성을 제공하기 위해). 한가지 옵션은 더 높은 레벨의 신뢰가 부팅 시퀀스에서 확립되는 경우에 더 높은 강도의 키를 생성 및 사용하는 것, 및 만일 상대적으로 더 낮은 레벨의 신뢰가 부팅 시퀀스 결과에 따라 확립되면 상대적으로 더 낮은 강도의 키의 사용으로 제한하는 것이다. 정책이 미리 공급될 수 있고, 신뢰의 근원이 확립될 수 있는 신뢰의 레벨에 대응하는 적당한 키 강도를 강화할 수 있다. 다른 신뢰성 레벨에 특유한 이러한 복수의 키의 생성 및 사용은 차선적으로 신뢰 검증 시스템이 부팅된 시스템의 신뢰성 레벨에 불일치할 수 있는 키에 대한 과도한 강도 레벨을 요구하지 않고 특정의 정보를 외부 관계자에게 전송하기 위해 암호 자원(cryptographic resource)을 사용할 필요가 있는 때에 유용할 수 있다.

서로 다른 키의 유도는 하나 이상의 유효 단계 집합이 있도록 다른 부팅 시퀀스 및 다른 코드에 기초하여 허용될 수 있다. 상이한 부팅 시퀀스로부터 야기되는 가능한 장치 유일의 비밀키들은 동일한 신뢰의 근원(이것은 동일한 루트 키를 사용할 수 있다)으로부터 나오고 그에 따라서 신뢰성이 있지만, 명백히 상이하고 상호 배타적일 수 있으며, 이것은 임무(예를 들면, 신뢰성 테스트 모드 대 신뢰성 통상 동작)의 분리를 허용할 수 있다.

키 유도 및 서명 메카니즘의 알고리즘 선택이 제공될 수 있다. 다음 단계의 키 유도 및/또는 현재 단계 서명 또는 인증을 위한 특수 알고리즘의 강화가 제공될 수 있다. 이러한 제어는 복호시에 필드 값이 부팅 단계 인증 모듈의 대응하는 레지스터에 삽입되어 강화 제어를 설정할 수 있도록 암호화 크리덴셜 패키지의 전용 제어 레지스터 필드에 있을 수 있다. 부팅 단계 인증 모듈은 TrE일 수 있다.

도 13a, 13b 및 13c는 본 발명의 시스템, 방법 및 설비의 실시형태가 구현될 수 있는 예시적인 칩을 보인 것이다.

보안 다단계 부팅 인증은 예를 들면 부팅 단계 인증 모듈(1300)과 같은 보안 하드웨어 모듈에서 구현될 수 있다. 부팅 단계 인증 모듈(1300)은 4개의 컴포넌트, 즉 루트(root) 장치 유일성(unique) 비밀키(루트 키), 제어 신호 및 단계 특유의 키 유도 함수(key derivation function; KDF), 사이퍼 엔진 및 서명 메카니즘을 포함할 수 있다. 모듈에 대한 인터페이스는 구성 및 데이터 버스 인터페이스를 포함할 수 있다. 구성 레지스터는 MMU 또는 부트 실행 벡터의 제어, 칩 I/O 등과 같은 명령어 및 데이터 흐름을 강화할 수 있다. 키 경로는 부팅 단계 인증 모듈(1300)에 대하여 내부에 둠으로써 소프트웨어/펌웨어에 의해 보여지는 것으로부터 보호될 수 있다. 부팅 단계 구성 인터페이스는 칩이 적당한 구성으로 보안 부팅 처리를 개시하도록 보장할 수 있다.

만일 보안 부팅 처리가 적절히 시작되지 않으면, 예컨대 구성이 다른 부팅 시퀀스용이면, 온칩 자원 및 장치 유일성 비밀키에 대한 결과적인 단계 액세스(stage access)은 성립될 수 없고, 이것은 그 다음에 다음 부팅 단계로의 진행 및 그 특수 단계를 위한 서명키의 복호를 금지할 수 있으며, 따라서 외부 엔티티가 장치의 신뢰 상태를 증명하지 못할 수 있다.

키형(keyed) 크립토그래픽 해싱 알고리즘, 장치 유일성 비밀키, 피드백 키 경로, 및 서명 메카니즘 중의 하나 이상이 결합될 수 있다. 인증 비밀의 계층들은 특수한 장치, 및 실행 코드, 부팅 구성 제어와 같은 측정된 정보의 무결성에 암호적으로 결속될 수 있다. 만일 측정된 정보가 무결성이 없으면, 후속의 종속하는 실행 계층은 인증 비밀에 액세스하거나 복호할 수 없다. 예를 들어서, 만일 장치가 적절히 설정된 프로세서 점프 벡터를 갖고 있지 않거나, 내부적으로 부팅되지 않거나 또는 디버그 모드에 있으면, 비트 패턴에서의 차가 검출될 수 있고, 이것은 후속적으로 외부의 관심있는 관계자에 대하여 인증하지 않는 부정확한 키를 발생할 수 있다.

장치는 유일성 비밀키를 구비할 수 있다. 장치의 유일성 비밀키는 이전의 부팅 단계 키로부터 및 측정된 코드로부터 유도될 수 있다. 장치 유일성 키가 장치에 존재하지 않고 코드 자체로부터 생성될 수 있기 때문에, 만일 코드가 변경되었으면, 장치 유일성 비밀키가 올바르지 않을 수 있다. 루트 장치 유일성 비밀키(루트 키)는 초기 공급시에 또는 제조시에 장치에 비밀스럽게 매립될 수 있고, 장치에 유일한 것일 수 있다. 루트 장치 유일성 비밀키는 특수한 장치 부팅 구성을 활용하지 않으면 이용할 수 없다. 이 루트 키는 소프트웨어/펌웨어에게 보이지 않고 후속 부팅 단계 장치 유일성 키에 대한 종자(seed)를 제공할 수 있다. 후속 부팅 단계 장치 유일성 키도 또한 소프트웨어/펌웨어에게 보이지 않지만, 키 존재 및 그에 따라서 부팅 시퀀스의 그 단계에 대한 장치의 무결성을 검증할 수 있는 인증 또는 서명 메카니즘에서 활용될 수 있다.

루트 장치 유일성 비밀키는 제조 공정 중에, 예를 들면 1회 프로그램가능 퓨즈로서 구성된 적당한 강도(예를 들면, 오늘날에는 약 256 비트일 수 있다)의 키일 수 있고, 또는 비밀키가 소프트웨어/펌웨어, 칩 신호의 도청, 프로빙, 단순 및 차분 전력 분석 등에 대하여 비밀로 되고 숨겨지도록 메모리에 저장된 키일 수 있다. 비밀키는 누구에게도 알려지지 않은 장치에 대하여 유일한 것이고, 초기의 리세트시에 키 유도 함수를 제공할 수 있다.

도 14는 예시적인 키 유도 함수를 보인 것이다.

키 유도 함수는 2가지 기능으로 사용될 수 있다. 키 유도 함수는 후속 단계 키를 생성할 수 있고 후속 부팅 코드를 측정할 수 있다. 키 유도 함수는 HMAC-SHA-256과 같은 키형 크립토그래픽 해시 함수일 수 있고, 이 해시 함수는 그 일방향 특성 때문에 나중 단계 키의 획득이 이전 키에 대한 어떠한 정보도 드러내지 않고 측정 데이터의 임의의 비트 에러가 올바른 키에 대한 상관성이 없는 크게 다른 키를 발생시키는 것을 보장할 수 있다. 암호화 단계 특유의 서명 비밀은 무결성 정보와 함께 제공될 수 있다. 무결성 정보는 컴포넌트 또는 함수의 측정된 무결성 체크 값을 확인하기 위하여 및 그에 따라서 기능의 다음 단계를 해제하기 위하여 사용될 수 있다.

도 15는 서명 메카니즘을 포함한 예시적인 키 유도 세부(detail)를 보인 것이다.

강력한 장치 인증을 위하여, 키 유도 함수는 온칩 소프트웨어/펌웨어 및 외부 엔티티에게 직접 판독될 수 없는 부팅 단계 장치 유일성 비밀키를 발생할 수 있다. 그러므로, 장치 유일성 키는 인증 또는 서명 메카니즘에 직접 경로를 통해 보내질 수 있다. 외부 엔티티 및 소프트웨어는 그 다음에 오프칩 인터페이스를 통해 장치의 부팅 상태(boot state)의 새로움(freshness)을 확인하기 위해 인증 또는 서명 메카니즘에 도전 메시지를 제공할 수 있다.

도 16은 예시적인 다단계 키 유도 세부를 보인 것이다.

부팅 흐름이 초기 부팅 및 프로그램 로더 시퀀스로부터 운영체제 및 애플리케이션 로딩까지 진행하기 때문에, 코드의 각 부팅 단계의 무결성이 코드가 실행되기 전에 측정될 수 있다. 코드는 각 단계에서 키 유도 함수에 공급될 수 있고, 장치 유일성 비밀키는 각 단계에서 생성될 수 있다. 예를 들면, 초기에 루트 장치 유일성 비밀키(루트 키) 및 제1 코드 측정치가 키 유도 함수에 공급되고, 제1 키(초기 단계 키)가 생성될 수 있다. 이것은 최종의 양호한 크리덴셜이 결정될 때까지 복수의 단계에서 반복될 수 있다.

도 17은 예시적인 부팅 시퀀스를 보인 것이다. 도 16의 예시적인 설명은 키가 복수의 단계에서 어떻게 유도되고 최종의 양호한 크리덴셜이 어떻게 결정될 수 있는지를 보여준다. 초기 단계 키는 하드웨어가 신뢰의 근원 실행을 위해 구성된 것, 예를 들면 내부 ROM, 하드웨어 무결성 테스트 결과에 대한 프로세서 벡터가 올바르다는 것, 및 보안 민감성 I/O 핀이 예를 들면 테스트 모드가 아닐 때 적절히 설정되는 것을 검증할 수 있다.

만일 부팅 단계가 적절한 부팅 구성 및 코드에 따라서 실행되면, 최종 결과는 장치가 신뢰성있는 방식으로 부팅되었는지 검증하기 위해 네트워크 엔티티에 의해 외부적으로 사용될 수 있는 사이퍼키 또는 서명키일 수 있다. 그렇지 않고, 만일 단계 부팅 코드가 실패이면, 최종 서명키는 부정확하고 외부적/원격적 인증의 실패를 유도할 수 있다.

실행의 사슬은 서명키의 사슬을 추적하는데 필요하지 않을 수 있다. 부팅 시퀀스는 장치의 신뢰성 동작을 위해 필요한 코드 측정치를 로드할 수 있는 체크 시퀀스(예를 들면, 하드웨어 기반)로 실행 제어를 통과시킬 수 있다. 만일 측정치가 정확하면, 결과는 장치의 신뢰성 동작을 외부적으로 확인하기 위해 사용될 수 있는 최종키일 수 있다.

유효 부팅 단계로부터 유도된 키 및 제어는 런타임 동작에서 지속하는 잔류 사이퍼키 및 서명키를 잠금해제(unlock)할 수 있다. 장치 관리 서버는 이 잔류 서명키를 이용하여 서버가 애플리케이션 코드를 안전하게 다운로드할 수 있는지 결정하기 위해 장치가 신뢰성있는 상태로 안전하게 부팅되었는지 검증할 수 있다. 반면에, 각 부팅 단계에서 키에 대한 액세스를 제거하면, 예를 들어서 인증된 장치 개인화, 공급, 디버깅, 테스팅 등을 위하여 특수 부팅 단계 코드의 특수 판매자에게 액세스할 수 있는 칩의 하드웨어 보호 영역을 통한 특권화 제어를 유지하는데 도움이 될 수 있다.

실행 부팅 코드는 무결성 실패가 다음 단계 측정에서 발생하였는지 검출하기 위해 필요할 수 있다. 예를 들면, 다음 부팅 단계를 위한 암호화 비밀 패킷에는 암호화 비밀 패킷의 특정 필드에 위치되어 있는 공지된 "무결성 표시 메시지"와 같은 무결성 실패의 표시가 매립될 수 있다. 다음 부팅 단계 측정에서의 에러는 패킷의 필드에서 부정한(garbled) 무결성 표시 메시지를 발생할 수 있고, 이러한 부정한 무결성 표시 메시지는 예상된 값과 일치하지 않고 실행 부팅 코드에게 무결성 실패가 발생하였음을 표시할 수 있다.

부팅 단계 인증 모듈(예를 들면 도 13a~c 참조)의 하드웨어 비교기는 (HW 보호형이고 소프트웨어 또는 펌웨어에 보이지 않는) 예상된 무결성 값과 결과적인 무결성 값의 일치성을 검출하여, 예를 들면 무결성 의존 하드웨어 구성, 칩 비밀, 퓨즈, I/O 및 테스트 핀, LED 등에 대한 액세스를 제어하는 하드웨어 제어 신호를 발생할 수 있다.

제어 부팅 시퀀스는 그 다음에, 실패가 발생하였음을 외부 세계에 표시하는 경보를 칩 외부로 발행하도록 선택할 수 있다. 또는, 제어 부팅 코드는 아이들 상태로 유지되고 외부 엔티티에 대한 인증을 시도하기 위해 칩 인터페이스(네트워크 또는 핀)로부터의 입력을 기다릴 수 있다.

하나의 동작에서, 부팅 단계 인증 모듈은 암호화 단계 서명 비밀(패킷)을 복호할 수 있다. 그러나, 단계 서명 비밀을 암호화 및 인스톨하는 방법이 필요할 수 있다. 모듈은 "공급 모드" 입력 신호, "인가된 액세스를 허용하지 않는" 입력 신호, 및 "인가된 단계" 입력 신호를 가질 수 있고, "인가된 단계" 입력 신호는 1) 제조 단계만의 공급 방법을 위한 1회 프로그램가능 퓨즈에 의해 잠금될 수 있고, 및/또는 2) 칩에서 하드웨어를 인가함으로써 액세스가능하게 될 수 있다.

칩은 입력이 제조 공정에서 퓨즈에 의해 잠금되지 않으면 입력을 보호하기 위한 다른 메카니즘을 제공할 필요가 있다. 만일 입력이 퓨즈에 의해 잠금되지 않으면, 부팅 단계 인증 모듈은 장치가 여기에서 설명하는 것처럼 자신의 검출 메카니즘에 의해 보안적으로 부팅된 경우에 공급 모드를 허용할 수 있다. 이것은 비보안 부팅 코드가 공급 모드에 진입하는 것을 금지할 수 있다. 그러나, 이것은 공급 모드 입력에 대한 인가되지 않은 액세스에 대항해 보호하기 위해 칩에서의 보안 부팅 코드, 하드웨어 구성 및 기타의 "인가" 하드웨어까지일 수 있다. 다시 말해서, 부팅 단계 인증 모듈은 공급 모드에 대한 액세스를 보호하는 인가 하드웨어를 관리하는 부팅 코드 인가 시퀀스를 보호하기 위해 보안 부팅 코드가 실행되는 것을 보장할 수 있다. 일 실시형태에 있어서, 보안 부팅 처리는 바운드(bound) 키(예를 들면, 공개키, 개인키 등) 및 도전 응답 프로토콜을 활용하여 요구자(claimant)가 공급 처리 및 공급 모드 입력에 액세스하도록 인증 및 인가할 수 있다.

공급 모드 입력은 서명 비밀 패킷의 후속 단계가 복호되고, 소프트웨어에 대해 이용불능이고 공급자에게 보이지 않는 보호된 레지스터의 부팅 단계 인증 모듈의 내부에 저장될 수 있다. 그 다음에, 공급 모드 상태가 암호화 모드로 스위칭될 수 있다. 새로운 부팅 단계 코드는 키 유도 함수에 로드될 수 있다. 코드가 로드될 때, 새로운 장치 유일성 비밀키는 자동으로 생성될 수 있다(그러나 사용자 또는 소프트웨어에는 보이지 않는다). 그 다음에, 새로운 부팅 코드에 대응하는 새로운 서명 비밀이 사이퍼 엔진에 삽입되고 새로운 장치 유일성 비밀키로 암호화될 수 있다. 그 결과는 이전 버전을 교체하기 위한 장소에 저장될 수 있다.

새로운 후속 장치 유일성 비밀키를 유도하는 후속 부팅 단계 코드가 로드될 수 있고, 상기 비밀키는 내부적으로 저장된 후속 단계 서명 키 비밀을 암호화하기 위해 사용될 수 있다. 이 처리는 완료될 때까지 계속될 수 있다. 장치는 새로운 부팅 단계 코드 및 그 대응하는 서명키로 재부팅될 수 있다. 후속 부팅 단계 코드 및 키는 동일하게 비공지로 유지되고 단계(stage) 장치 유일성 비밀키의 새로운 사슬에 결속될 수 있다. 수정 단계 전의 부팅 단계는 수정되지 않고 유지될 수 있다.

도 18은 강도(또는 크립토 알고리즘 자체 또는 알고리즘의 모드 등과 같은 다른 보안 강도 특성)가 부팅 시퀀스 중에 수행되는 무결성 체크 절차에 의해 입증되는 시스템의 신뢰성 레벨의 결과에 의존하는 키를 생성 및 사용하는 장치의 예시적인 부팅 시퀀스 흐름을 보인 것이다.

본 발명의 시스템 및 방법은 다양한 정도의 기능하에서 장치를 안전하게 관리하기 위한 융통성을 단일 이해관계자에게 제공하는 단일 이해관계자(예를 들면, 원격 사용자) 실시형태에서 사용될 수 있다. 예를 들면, 원격 사용자는 보안 임계 및 복소 함수에 대하여 장치를 이용하기 전에 장치가 그 전체 레벨의 장치 무결성 및/또는 기능을 정확히 획득하였는지 확인하기 원할 수 있다.

달성되는 장치 무결성 및/또는 기능의 레벨을 결정하기 위해, 사용자는 장치에 넌스(nonce)를 제출하고 후속적으로 서명된 응답을 검색함으로써 장치에게 도전(challenge)할 수 있다(예를 들면, 넌스는 결과의 새로움을 보증할 수 있다). 사용자는 그 다음에 응답을 체크하여 장치가 어떤 단계의 무결성 및 건강 체크 실행을 통과하였는지를 결정할 수 있다. 그 결과에 기초해서, 사용자는 무결성이 검증된 함수에 대하여 장치와 안전하게 상호작용할 수 있다고 보증될 수 있다.

예로서, 만일 응답이 보안 부팅 처리가 발생하지 않았음(예를 들면, 무결성 체크가 없음)을 표시하면, 사용자는 장치가 비보안 방식으로 구성되고 민감성 데이터의 취급에 의존하지 않는다는 것을 인식할 수 있다. 또한, 일부 장치 무결성 결속 키를 이용할 수 없기 때문에, 보안 부팅 처리에 결속된 암호화 데이터가 또한 이용될 수 없다.

만일 제1 단계의 처리가 달성되면, 장치는 그 자신의 실패한 함수의 일부를 증명하는 능력과 같은 일부 보안 능력을 가질 수 있고 리플레이 보호된 및/또는 서명된 재난 신호를 송출할 수 있다. 원격 사용자는 수신된 재난 신호가 오류가 아니거나 및/또는 일부 다른 장치에 의해 속여진(spoofed) 것인지를 상기 신호로부터 결정할 수 있고, 장치가 재난 신호를 보낸 것을 알고 있는 장치를 교정하는 동작을 취할 수 있다.

이 예를 계속해서, 만일 제2 단계가 달성되면, 더 큰 레벨의 능력/장치 무결성을 나타내는 인증키의 새로운 집합이 장치에서 이용되어 사용자가 장치에서 실패 코드를 원격에서 보안적으로 수정할 수 있게 한다. 이것의 변형예는 이러한 제2 단계의 무결성을 달성하는 장치가 원격 사용자의 OAM 또는 장치 관리(DM) 서버(또는 그러한 서버 애플리케이션)를 인증할 수 있게 하는 국소 액세스(local access)을 취하는 경우일 수 있다. 이 예의 이 단계에서, 장치는 원격 사용자(또는 그의 OAM 또는 DM 서버 또는 그러한 서버 애플리케이션)를 인증할 능력을 가질 수 있고, 그래서 장치에서의 일부 데이터 및 코드는 달성되는 무결성 단계에 관한 이용가능한 키를 이용하여 로드 및 서명될 수 있다. 다른 레벨의 능력과 관련된 다른 단계가 또한 달성될 수 있다.

최종의 성공적 단계는 장치가 원격 사용자가 안전하게 액세스 및 사용하는데 필요한 기능을 완전하게 수행할 수 있음을 표시할 수 있다.

본 발명은 수 개의 기능 단계를 포함할 필요가 없고 하나 또는 복수의 이해관계자로 제한되지 않는다. 일부 형태에 있어서, 장치는 원격 사용자의 전망(perspective)으로부터 자율적 확인을 위한 단일 인증 키를 발생시키는 단일의 대표적 결과와 함께 단일의 체크 단계를 수행할 수 있다. 이것은 예를 들면 네트워크에 대한 부착을 시도하는 장치를 확인하기 위해 사용될 수 있다. 본 발명의 시스템 및 방법은 장치의 신뢰성 상태의 표시에서의 융통성을 가능하게 하는 것, 장치, 서비스 및/또는 애플리케이션 레벨에서 재난 표시, 장치 모니터링, 장치 관리 기능(진단 및 교정) 및 인증 절차를 가능하게 하는 것까지 또한 확장될 수 있다.

양호한 네트워크에 대한 장치의 액세스를 위해 필요한 1차 키가 아닌 다른 목적으로 필요한 인증키와 같은 다른 인증 정보는 무결성 체크 처리에 결속될 수 있다. 그러한 '다른 인증'의 예는 OAM의 인증, 애플리케이션 레벨 서비스의 인증, 또는 액세스층 이외의 층들에서 보안 프로토콜(IPsec 또는 TLS 등)의 인증이 있다. 다른 예들은 장치 및/또는 그 프로필(예를 들면, 그룹 멤버쉽 등), 가입자/사용자, 서비스, 또는 애플리케이션의 인증을 포함할 수 있다. 예를 들어서 도 13c를 참조하면, 서비스 가입 키가 KDF에 보내질 수 있다. 결과적인 키는 서비스 제공자에 대한 인증을 위해 사용될 수 있는 장치 유일성 비밀키일 수 있다. 장치에 대한 도전은 가입자 및 장치 무결성 둘 다를 인증할 수 있다. 그 경우에, 서비스 가입 키는 적당한 단계에서 추가될 수 있다. 일 실시형태에 있어서, 무결성 지지형 가입 키는 이전 단계에서 제공되고, 무결성 지지형 애플리케이션 키는 나중 단계에서 제공된다. 다른 정보는 KDF 입력에서 결합되어 필요한 정보에의 결속을 보증할 수 있다. 다른 인증 정보를 무결성 체크 처리에 결속시킴으로써, 하나 이상의 독립 인증 소스가 제공될 수 있다.

본 발명의 시스템, 방법 및 설비는 장치의 보안 및 원격 구성이 가능하도록 신뢰의 동적 확장을 허용할 수 있다. 예를 들면, 공장 외부에서, 장치는 공지의 미구성 상태로 안전하게 부팅할 수 있다. 그러한 장치는 판매자 증명서(vendor certificate)에 포함된 크리덴셜을 먼저 이용할 수 있다. 이 단계에서 이용가능한 인증 키는 외부 관리 엔티티(OAM 또는 DM 서버 등)가 장치의 구성 데이터 구조에 원격으로 액세스할 수 있게 하고, 인증된 외부 관리 엔티티가 새로운 크리덴셜(예를 들면, 새로운 서명키 등을 포함하는 새로운 서명키 또는 사업자 증명서)을 삽입할 수 있게 한다. 이러한 새로운 크리덴셜은 여기에서 설명하는 방법을 이용하여 보호될 수 있다. 새로운 구성 데이터는 새로운 키를 이용하여 서명될 수 있고 성공적인 단계키(stage key)에 의해 역시 서명된 새로운 실행 단계가 삽입될 수 있다. 인증키가 추가될 수 있고, 이 인증키는 이 최종 구성 체크의 성공적인 완료에 의해 보호될 수 있다. 예를 들어서 만일 장치가 리세트되면, 장치는 새로운 구성 데이터를 체크할 수 있는 새로운 단계로 자동으로 재부팅될 수 있다. 만일 새로운 구성 데이터가 일치하면, 결과적인 인증키는 이용가능이다. 그 다음에 외부 엔티티가 장치를 인증할 수 있다. 만일 인증이 통과하면, 외부 엔티티는 장치가 적절히 구성되는 것이 보증될 수 있다.

도 19는 다단계 인증에 관한 예시적인 네트워크 통신을 보인 것이다.

3GPP 릴레이 노드(RN)는 도너 eNB(DeNB)에 대한 UE뿐만 아니라 DeNB에 접속하는 UE에 대한 eNB(즉, 릴레이-eNB)로서 작용할 수 있다. 릴레이 노드는 비상 대응 또는 임시 커버리지 갭 채움 임무(filling mission)와 같은 사용중인 시나리오의 사이트에서 전개될 수 있으므로, 릴레이 노드는 전개시에 충분히 구성되지 못할 수 있고 완전하게 동작하기 위한 모든 기능을 갖지 못할 수 있다. 그러나, RN은 네트워크 장치이기 때문에, 장치 보안 필요조건을 포함한 보안 필요조건이 높게 될 필요가 있고, 이것은 단계화 동작 단계의 달성을 가능하게 하는 무결성 체크의 필요성을 야기할 수 있다. 그러한 단계화 동작 상태는 전개 후 구성 및 크리덴셜 등록(enrollment)을 위해 필요할 수 있다.

도 20은 예시적인 3GPP 릴레이 노드를 이용한 다단계 인증 및 크리덴셜 구성을 역시 포함한 예시적인 시동(start-up) 및 시동 후(post-start-up) 구성 절차를 보인 것이다.

이 예에서, RN은, 만일 소정 단계의 무결성을 통과하면, 공지의 사업자(Operator; OP) 관리 상자(예를 들면, OAM 또는 DM 서버 상자 등)뿐만 아니라 판매자의 OAM/DM 서버에 액세스할 수 있다. 그러나, 만일 RN이 추가의 단계에서 실패하면, RN은 OP 이동도 관리 엔티티(MME)에 대한 완전한 액세스를 위해 필요한 크리덴셜(RN에 이미 존재하거나 존재하지 않는 것)에의 액세스가 허용되지 않을 수 있다. 그러므로, RN은 OP MME에 대한 완전 액세스 인증 시도에 실패할 수 있다. 그러나, 이러한 실패가 수 회 계속되면, RN은 공지의 OP OAM/DM에 대한 인증이 제한될 수 있고, 미리 공급된 판매자 크리덴셜을 이용하여 판매자 OAM/DM에 의해 재구성되도록 지시를 받을 수 있다. 만일 RN이 재구성되고 그 다음에 추가의 무결성 체크 단계를 통과하면, RN은 이제 OP MME에 액세스하는데 필요한 크리덴셜에 액세스할 수 있다.

본 발명의 시스템 및 방법은 무단 변경(tampering) 및 런타임 실패에 민감하게 될 수 있다. 별도의 무단 변경 감시 처리는 장치의 무결성이 확립되기 전에 또는 확립된 때 확립될 수 있다(예를 들면, 감시 처리는 신뢰의 근원에 연결된다). 이러한 감시는 코드, 포트, 또는 침입이나 무단변경 이벤트를 표시하는 모든 것을 체크할 수 있다. 그러한 이벤트가 있을 때, 기확립된 장치 유일성 비밀키의 값이 자동으로 제거되어 인증키를 이용불능으로 만든다. 도 21을 참조하면, 본 발명의 시스템 및 방법의 각종 실시형태가 구현될 수 있는 예시적인 칩이 도시되어 있다. 무결성 기반 인증키를 이용하여 장치와 보안 접속을 재확립하기 위한 시도는 실패할 수 있다. 이것은 장치의 보안성에 의존하는 외부 엔티티에 대한 연속적인 보호를 제공할 수 있다.

도 22는 무결성 체크 처리가 어떻게 UE 통신에까지 연장될 수 있는지를 보인 것이다. 네트워크는 무결성 결속 인증키를 이용하여 UE 키를 릴레이 노드에 통과시킬 수 있다. 만일 릴레이 노드가 무결성 또는 무단변경 이벤트 때문에 더 이상 보안되지 않으면, 릴레이 노드는 암호화 키의 복호를 할 수 없고 UE로부터의 통신의 보안성이 유지된다.

본 발명의 시스템 및 방법은 하기의 것 중 하나 이상을 제공할 수 있다: 장치의 신뢰성의 부분적 또는 단계화 원격 결정을 허용하는 장치 서명키를 단계화하는 메카니즘; 장치의 현재 부팅 단계을 위한 코드의 성공적인 측정치, 구성 정보 및 보안 부팅 처리의 상태가 제어 신호를 직접 유도하기 위해 사용될 수 있고, 이것이 온칩 자원에 대한 추가 액세스 및 인증을 위한 비밀의 해제를 가능하게 하는 경우에 온칩 자원 및 인증 비밀의 단계화 해제를 위한 방법; 부분적으로 실패가 있는 장치와 외부 엔티티 간의 신뢰성 보고, 관리 및 교정의 가능성; 부팅 처리 중에 명시적인 무결성 체크 절차의 필요성 제거 및 부팅 코드 기준 값을 저장 및 보호할 필요성의 제거; 또는 칩 경계 또는 공개 인터넷과 같은 공개 인터페이스를 통한 각종 이해관계자에 대한 인증된 액세스.

플랫폼 무결성 정책 엔진(Platform Integrity Policy Engine; PIPE)은 전체 플랫폼 신뢰 시스템 아키텍쳐의 일부일 수 있다. PIPE는 다단계 인증 및 키 해제 처리를 제어할 수 있다. PIPE는 보안 부팅 처리의 흐름, 소프트웨어 및/또는 데이터 컴포넌트에서 무결성 체크 측정치의 처리, 정책에 따른 후속 강화 동작, 및/또는 후속 소프트웨어 부하 제어의 흐름을 포함한 각종 기능을 제어할 수 있다. 정책은 제조자 및/또는 사업자와 같은 하나 이상의 외부 이해관계자에 의해 규정될 수 있고 장치에 공급될 수 있으며 원격 갱신 절차를 통해 현장에서 갱신될 수 있다.

PIPE는 더 많은 기능 능력을 점차적으로 인스톨하고 런타임 중에 컴포넌트의 동적 로딩을 유지함으로써 제어된 소프트웨어 및 데이터 체크 및 로딩 동작을 통하여 로드되는 것으로부터 절충된 소프트웨어 기능의 리스크를 제어할 수 있다. 도시된 예에서처럼, 로딩 동작에서의 진행 단계에 의존해서, PIPE는 인증 실패에 응답하여 플랫폼의 전력 강하; 절충된 컴포넌트의 로딩 금지 또는 컴포넌트의 검역; 낮은 레벨의 실패 또는 절충된 기능을 통지하기 위해 네트워크에서 보안 게이트웨이 또는 교정 관리자와 같은 외부 엔티티에 대한 경보 트리거; 인증 키 등과 같은 플랫폼에서의 기능 또는 보안 정보에의 액세스 금지; 또는 인증 알고리즘 등과 같은 플랫폼에서의 보안 기능에의 액세스 금지 중의 하나 이상을 구현할 수 있다.

일부 경우에, 실패는 핵심 TrE 기능이 절충되었기 때문에 플랫폼에서 신뢰성 환경 조차도 신뢰를 보증할 수 없을 정도로 심각할 수 있다. 낮은 레벨에서의 실패는 무결성 및 리플레이 보호 및 신뢰성 보호를 포함하는 디폴트 신뢰의 근원으로 서명된 경보 메시지를 발생시키는 것과 같은 기본 동작을 트리거할 수 있다. 즉, 낮은 레벨의 보안 실패가 발생한 때, 재난 메시지가 이용가능한 하나 이상의 통신 채널에 의해 네트워크에 대해 해제될 수 있다.

로드된 기능이 구축되고 더욱 더 복잡하게 됨에 따라서, 장치는 네트워크 엔티티 대신에 보안 및 신뢰성 프록시로서 작용하는 것과 같은, 절충된 소프트웨어 및/또는 구성 데이터의 진단, 보고 및/또는 교체를 위한 질의 절차를 촉진하는 더 복잡한 동작을 수행할 수 있고; 컴포넌트에서 오류가 있는 장소를 격리하기 위해 무단변경의 가능성이 있는 컴포넌트를 더 미세한 과립상 세부(detail)에 의한 무결성 체크를 비롯해서 벌크 코드 또는 데이터 재로드/갱신 절차 또는 조사를 더 구체적으로 수행할 수 있다.

플랫폼에서 자원에 대한 다양한 액세스는 성공적으로 검증된 기능의 레벨에 따라서 (예를 들면 PIPE에 의해) 제공될 수 있다. 만일 컴포넌트 무결성 체크가 실패하면, 그 컴포넌트는 신뢰될 수 없다. 이 검출된 실패는 안전하게 표시될 수 있고 네트워크에게 (명시적으로 또는 암시적으로) 표시될 수 있으며, 부팅 흐름은 이 실패 조건에 기인하여 분기할 수 있다. 이러한 유형의 무결성 체크 실패는 실행 흐름 실패라고 부르고, 체크된 컴포넌트는 신뢰성이 없고 이 컴포넌트의 시작은 악성의, 절충된, 오류있는 또는 잘못 구성된 코드의 실행을 야기할 수 있으며, 이것은 장치가 불특정의 예상치못한 방식으로 기능을 수행하게 할 수 있다. 따라서, 새로운 컴포넌트 및 이용가능한 기능의 로딩은 이전에 로드된 컴포넌트의 무결성에 의해 영향을 받을 수 있다.

그 결과, 실행 환경은 각 부팅 단계 및 각 런타임 처리에서 제어 실행 처리 및 액세스 특권에 따라 변할 수 있다. 예를 들면, 부팅 처리의 각 단계에서, 그 때에 이루어진 무결성 측정에 기초하여 결정을 행할 필요가 있다. 후속 단계 및 정책은 그 자신의 동작을 결정하기 위해 실행 단계(상태, 변수, 파라미터, 레지스터, 파일 등)를 초월하는 정보 전달의 임의의 이용가능한 보안 수단 또는 스토리지를 통하여 이전 단계로부터 통과된 정보를 이용할 수 있다. 예를 들면, 상위 계층 애플리케이션 인증 기능은 미리 로드된 컴포넌트의 무결성에 대한 정보를 이용하여 외부 엔티티에 의한 성공적인 인증을 위해 필요한 키 해제의 게이팅을 포함한 그 자신의 동작을 결정할 수 있다.

예시적인 PIPE 기능적 흐름은 하기의 것 중 하나 이상을 포함할 수 있다. RoT가 체크되고 그 무결성이 검증될 수 있다. 베이스라인 TrE가 RoT에 의해 체크되고 그 무결성이 검증될 수 있다. 만일 TrE 체크에 실패가 있으면, 네트워크에의 부착을 위해 필요한 키의 해제 금지; 네트워크에 대한 경보 트리거(경보가 네트워크에 보내질 수 있게 하는 폴백 코드가 로드되고 및/또는 경보가 원격 대량 갱신 절차를 트리거하여 TrE를 교체할 수 있다); 또는 장치의 전력 강하 중의 하나 이상이 구현될 수 있다. 베이스라인 운영체제 모듈의 체크 및 로드; 베이스라인 관리 클라이언트의 체크 및 로드; 또는 통신 모듈의 체크 및 로드 중 하나 이상을 포함한 기본 통신 접속 코드가 로드될 수 있다. 만일 실패가 발생하면, 네트워크에의 부착을 위해 필요한 키의 해제 금지; 컴포넌트의 교체를 위한 원격 대량 갱신 절차의 경보를 통한 트리거(경보가 네트워크에 보내질 수 있게 하는 폴백 코드가 로드되거나 및/또는 경보가 원격 대량 갱신 절차를 트리거하여 기본 코드를 교체할 수 있다); 경보 및 원격 컴포넌트 갱신 절차 개시; 또는 장치의 전력 강하 중의 하나 이상이 구현될 수 있다. 나머지 운영체제 및 관리 클라이언트 컴포넌트를 체크 및 로드한다. 동적의 재배치가능한 및/또는 재로드가능한 기능 모듈을 체크 및 로드하고, 만일 실패가 있으면, 네트워크에의 부착을 위해 필요한 키의 해제 금지; 프로토콜에서의 실패 보고를 네트워크에 전송(실패 보고는 네트워크에 의해 원격으로 갱신될 수 있는 실패 컴포넌트를 표시할 수 있다); 경보 전송 및 원격 컴포넌트 갱신 절차의 요청; 또는 장치의 전력 강하 중의 하나 이상이 구현될 수 있다.

PIPE의 행동은 성공적으로 검증된 부팅 사슬에 따라 변할 수 있다. 부팅 처리의 각 단계에서, 그 때에(또는 그 때까지) 무결성 체크된 하부 플랫폼의 일부 또는 전체의 평가된 무결성 및 적용되어야 할 정책에 기초하여 결정이 이루어질 수 있다. 이 정책들은 달성된 신뢰 레벨에 따라서 적응되거나 새로운 정책으로 교체될 수 있다. 실행 환경은 각 부팅 단계에서 제어 정책에 따라서 변할 수 있다. 후속 단계 및 정책은 실행 단계(상태, 변수, 파라미터, 레지스터, 파일 등)를 초월하는 정보 전달의 이용가능한 보안 수단 또는 스토리지를 통하여 이전 단계로부터 통과된 정보를 이용할 수 있다. PIPE 정책은 하나 이상의 이해관계자에 의해 공급될 수 있다. 예로서, 하나의 이해관계자는 각각의 정책에 액세스할 수 있고, 각 이해관계자는 일부 정책에 액세스할 수 있다(예를 들면, 우선순위 레벨 또는 특수 기능과의 연합에 따라서). 다른 예로서, 제조자는 낮은 레벨의 코드 정책을 제어할 수 있고, 사업자는 소프트웨어 및 구성 정책을 제어할 수 있으며, 애플리케이션 서비스 공급자는 더 높은 레벨의 기능 모듈을 제어할 수 있다.

지금까지 특징 및 요소들을 특수한 조합으로 설명하였지만, 이 기술에 통상의 지식을 가진 사람이라면 각 특징 또는 요소는 단독으로 또는 다른 특징 및 요소와 함께 임의의 조합으로 사용될 수 있다는 것을 이해할 것이다. 또한, 여기에서 설명한 방법들은 컴퓨터 또는 프로세서에 의해 실행되는 컴퓨터 판독가능 매체에 통합된 컴퓨터 프로그램, 소프트웨어 또는 펌웨어로 구현될 수 있다. 컴퓨터 판독가능 매체의 예로는 전자 신호(유선 또는 무선 접속을 통해 전송된 것) 및 컴퓨터 판독가능 기억 매체가 있다. 컴퓨터 판독가능 기억 매체의 비제한적인 예로는 읽기 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 레지스터, 캐시 메모리, 반도체 메모리 소자, 내부 하드 디스크 및 착탈식 디스크와 같은 자기 매체, 자기 광학 매체, 및 CD-ROM 디스크 및 디지털 다기능 디스크(DVD)와 같은 광학 매체가 있다. 프로세서는 소프트웨어와 연합해서 WTRU, UE, 단말기, 기지국, RNC, 또는 임의의 호스트 컴퓨터에서 사용되는 라디오 주파수 송수신기를 구현하도록 사용될 수 있다.

214: 송수신기
215: 메모리
216: 프로세서
217: 프로세서
219: 송수신기
220: 배터리
222: 메모리
233: 프로세서
234: 메모리

Claims

네트워크 장치의 무결성 확인(integrity validation)을 수행하는 방법에 있어서,
네트워크 장치의 메모리에 저장된 제1 코드의 무결성 측정치(measurement)를 수신하는 단계; 및
상기 네트워크 장치의 보안 메모리에 저장된 루트 키 및 상기 제1 코드 무결성 측정치에 기초하여 제1 키를 발생시키는 단계로서, 상기 제1 키는 상기 제1 코드 무결성 측정치가 유효일 때 유효이고, 상기 제1 키는 상기 네트워크 장치의 제1 기능과 연관된 제1 신뢰 단계(stage)에 관한 것이며, 유효한 제1 키는 상기 제1 기능에 액세스하기 위해 제1 원격 이해관계자(stakeholder)에 의해 사용될 수 있는 것인, 상기 제1 키를 발생시키는 단계;
상기 네트워크 장치의 메모리에 저장된 제2 코드의 제2 코드 무결성 측정치를 수신하는 단계; 및
(1) 상기 제1 키 및 (2) 상기 제2 코드 무결성 측정치에 기초하여 제2 키를 발생시키는 단계로서, 상기 제2 키는 상기 제1 코드 무결성 측정치가 유효이고 상기 제2 코드 무결성 측정치가 유효일 때 유효인 것인, 상기 제2 키를 발생시키는 단계를 포함하고,
상기 제2 키는 제2 기능과 연관된 제2 신뢰 단계에 관한 것이고, 유효한 제2 키는 상기 제2 기능에 액세스하기 위해 제2 원격 이해관계자에 의해 사용될 수 있는 것인, 무결성 확인 수행 방법.
제1항에 있어서, 상기 제1 코드 무결성 측정치가 무효일 때 상기 제1 기능에 대한 액세스를 금지하는 단계를 더 포함하는, 무결성 확인 수행 방법.
삭제
제1항에 있어서, 상기 제2 코드 무결성 측정치가 무효일 때 상기 제2 기능에 대한 액세스를 금지하는 단계를 더 포함하는, 무결성 확인 수행 방법.
삭제
제1항에 있어서,
넌스(nonce)를 수신하는 단계; 및
상기 넌스에 응답하여 서명된 메시지를 전송하는 단계를 더 포함하고, 상기 서명된 메시지는 비신뢰성(untrustworthy) 상태, 부분 신뢰성(partial trustworthy) 상태, 또는 신뢰성 상태를 표시하는 것인, 무결성 확인 수행 방법.
제6항에 있어서, 부분 신뢰성 상태가 표시된 때 최종의 유효 크리덴셜(credential)을 제공하는 단계를 더 포함하고, 상기 최종의 유효 크리덴셜은 최종의 유효 코드 무결성 측정치와 연관된 최종 유효키를 포함한 것인, 무결성 확인 수행 방법.
제6항에 있어서, 상기 서명된 메시지는 부팅 상태(boot state)의 새로움(freshness)을 또한 표시하고, 상기 넌스는 시퀀스 카운터 또는 일자 및 시간 스탬프 기능 중의 적어도 하나를 통해 국부적으로 유도되는 것인, 무결성 확인 수행 방법.
제1항에 있어서, 상기 루트 키는 제조시에 또는 공급시에 상기 보안 메모리에 저장되는 것인, 무결성 확인 수행 방법.
제1항에 있어서, 상기 보안 메모리는 보안 하드웨어 모듈의 일부이고, 상기 루트 키는 상기 보안 하드웨어 모듈 외부의 소프트웨어에 보이지 않는 것(not visible)인, 무결성 확인 수행 방법.
네트워크 장치의 무결성 확인(integrity validation)을 수행하는 보안 하드웨어 모듈에 있어서, 상기 보안 하드웨어 모듈은 적어도 부분적으로,
상기 네트워크 장치의 메모리에 저장된 제1 코드의 무결성 측정치(measurement)를 수신하고;
상기 네트워크 장치의 보안 메모리에 저장된 루트 키 및 상기 제1 코드 무결성 측정치에 기초하여 제1 키를 발생시키고;
상기 네트워크 장치의 메모리에 저장된 제2 코드의 제2 코드 무결성 측정치를 수신하며;
(1) 상기 제1 키 및 (2) 상기 제2 코드 무결성 측정치에 기초하여 제2 키를 발생시키도록 구성되고,
상기 제1 키는 상기 제1 코드 무결성 측정치가 유효일 때 유효이고, 상기 제 1키는 상기 네트워크 장치의 제1 기능과 연관된 제1 신뢰 단계(stage)에 관한 것이며, 유효한 제1 키는 상기 제1 기능에 액세스하기 위해 제1 원격 이해관계자(stakeholder)에 의해 사용될 수 있고,
상기 제2 키는 상기 제1 코드 무결성 측정치가 유효이고 상기 제2 코드 무결성 측정치가 유효일 때 유효이고, 상기 제2 키는 제2 기능과 연관된 제2 신뢰 단계에 관한 것이고, 유효한 제2 키는 상기 제2 기능에 액세스하기 위해 제2 원격 이해관계자에 의해 사용될 수 있는 것인, 보안 하드웨어 모듈.
제11항에 있어서, 상기 보안 하드웨어 모듈은 또한, 상기 제1 코드 무결성 측정치가 무효일 때 상기 제1 기능에 대한 액세스를 금지하도록 구성되는 것인, 보안 하드웨어 모듈.
삭제
제11항에 있어서, 상기 보안 하드웨어 모듈은 또한, 상기 제2 코드 무결성 측정치가 무효일 때 상기 제2 기능에 대한 액세스를 금지하도록 구성되는 것인, 보안 하드웨어 모듈.
삭제
제11항에 있어서, 상기 보안 하드웨어 모듈은 또한,
넌스(nonce)를 수신하고;
상기 넌스에 응답하여 서명된 메시지를 전송하도록 구성되고, 상기 서명된 메시지는 비신뢰성(untrustworthy) 상태, 부분 신뢰성(partial trustworthy) 상태, 또는 신뢰성 상태를 표시하는 것인, 보안 하드웨어 모듈.
제16항에 있어서, 상기 보안 하드웨어 모듈은 또한, 부분 신뢰성 상태가 표시된 때 최종의 유효 크리덴셜(credential)을 제공하도록 구성되고, 상기 최종의 유효 크리덴셜은 최종의 유효 코드 무결성 측정치와 연관된 최종 유효키를 포함한 것인, 보안 하드웨어 모듈.
제16항에 있어서, 상기 서명된 메시지는 부팅 상태(boot state)의 새로움(freshness)을 또한 표시하고, 상기 넌스는 시퀀스 카운터 또는 일자 및 시간 스탬프 기능 중의 적어도 하나를 통해 국부적으로 유도되는 것인, 보안 하드웨어 모듈.
제11항에 있어서, 상기 루트 키는 제조시에 또는 공급시에 상기 보안 메모리에 저장되는 것인, 보안 하드웨어 모듈.
제11항에 있어서, 상기 보안 메모리는 보안 하드웨어 모듈의 일부이고, 상기 루트 키는 상기 보안 하드웨어 모듈 외부의 소프트웨어에 보이지 않는 것(not visible)인, 보안 하드웨어 모듈.