KR101681136B1 - 무선 장치들의 플랫폼 검증 및 관리 - Google Patents

Abstract

플랫폼 검증 및 관리(platform validation and management, PVM)를 구현하기 위한 방법들, 컴포넌트들 및 장치가 개시된다. PVM은, 홈 노드-B 관리 시스템 또는 컴포넌트와 같은 장치 관리 컴포넌트들 및 시스템들에 의한 장치들의 원격 관리와 함께, 플랫폼 검증 엔티티의 기능 및 동작들을 제공한다. 예시적인 PVM 동작들은, 코어 네트워크로의 접속 및 액세스를 허락하기 전에, 장치들을 보안 타겟 상태(secure target state)가 되게 한다.

Description

무선 장치들의 플랫폼 검증 및 관리{PLATFORM VALIDATION AND MANAGEMENT OF WIRELESS DEVICES}

관련 출원들에 대한 상호 참조

본 출원은 다음의 미국 가 특허 출원들, 2009년 3월 6일 출원된 61/158,242호, 2009년 4월 28일 출원된 61/173,457호, 2009년 6월 30일 출원된 61/222,067호, 및 2009년 8월 21일 출원된 61/235,793호의 우선권을 주장하며, 이들 모두는 여기에서 완전히 설명되는 것 처럼 그 전체가 본원의 참조로서 통합된다. 본 출원은, 동시에 출원되었으며 그 명칭이 "Method and Apparatus For H(e)NB Integrity Verification and Validation" 미국 특허 출원 12/718,572호와 관련되며, 이는 여기에서 완전히 설명되는 것 처럼 그 전체가 본원의 참조로서 통합된다.

기존의 또는 표준화된 이동 통신 네트워크 기술은 네트워크가 장치들의 무결성(integrity)을 인증 및 검증(validate)할 수 있는 방법을 제공하지 못하거나, 또는 이러한 장치들을 관리 또는 프로비저닝(provisioning)하는 방법들을 제공하지 못한다. 유사하게, 네트워크에 어태치(attach)하고자 하는 장치들은 자신들이 접속하고 있는 그 네트워크가 실제로 유효한지 또는 신뢰성있는 제공자 네트워크인지 인증할 수 있는 능력을 갖지 않는다.

플랫폼 검증 및 관리(platform validation and management, PVM)를 구현할 수 있는 방법들 및 장치들이 필요하다.

플랫폼 검증 및 관리(PVM)를 구현하기 위한 방법들, 컴포넌트들 및 장치가 개시된다. PVM 구현은, 홈 노드-B 관리 시스템과 같은 장치 관리 시스템들에 의한 장치들의 원격 관리와 함께, 플랫폼 검증 엔티티의 기능 및 동작들을 제공한다. 예시적인 PVM 동작들은, 코어 네트워크로의 접속 및 액세스를 허락하기 전에, 장치들을 보안 타겟 상태(secure target state)가 되게 한다.

플랫폼 검증 및 관리(PVM)를 구현할 수 있는 방법들 및 장치들이 개시된다.

본 발명은 첨부 도면들과 관련하여 예로서 제시되는 하기의 상세한 설명으로부터 보다 상세하게 이해될 것이다.
도 1은 신뢰성있는(trusted) 서브시스템들의 도메인 분리(domain separation)를 보여주는 예시적인 블록도이다.
도 2는 플랫폼들 간의 신뢰(trust)가 조직적인 그리고 기술적인 방법들에 의해 조정됨을 보여주는 예시적인 블록도이다.
도 3은 H(e)NB (home enhanced node-B)에 의한 반 자율적인 검증(semi-autonomous validation)의 예시적인 흐름도이다.
도 4는 4 스테이지의 보안 스타트업(four-stage secure start-up) 방법의 예시적인 흐름도를 보여준다.
도 5a는 플랫폼 검증 및 관리(PVM)에 대한 예시적인 엔티티들의 세트와, 이들의 관계들 및 인터페이스들의 블록도를 보여준다.
도 5b는 PVM에 대한 예시적인 엔티티들의 세트와, 이들의 관계들 및 인터페이스들의 다른 블록도를 보여준다.
도 6a, 6b 및 6c는 플랫폼 검증 엔티티를 이용하는 예시적인 검증 방법의 신호도를 보여준다.
도 7은 H(e)NB 통신 시나리오를 보여주는 예시적인 블록도를 보여준다.
도 8은 H(e)NB 내의 "씬(thin)" TrE(trusted environment)의 예시적인 블록도를 보여준다.
도 9a는 간접적인 장치 접속의 예시적인 다이어그램 및 방법을 보여준다.
도 9b는 직접적인 장치 접속의 예시적인 다이어그램 및 방법을 보여준다.
도 10은 개별적인 증명서들(certificates)을 처리하는 예시적인 흐름도를 보여준다.
도 11a는 무결성 검증 실패 이후, 폴백 코드 베이스(fallback code base)에 의해 용이해지는 장치 교정이 뒤따르는 예시적인 검증 방법을 나타낸다.
도 11b는 도 11a의 방법에 따른 예시적인 흐름도를 보여준다.
도 12 기준 무결성 메트릭 쉴딩 헤더(reference integrity metrics shielding header)에 대한 예시적인 포맷을 보여준다.
도 13은 가상의 플랫폼 구성 레지스터 값을 이용하는 검증의 예시적인 흐름도이다.
도 14는 완전한 반 자율적인 검증(full semi-autonomous validation) 동안 컴포넌트들을 로딩할 때의 모듈 계층 조직(module hierarchy)을 예시적으로 나타낸다.
도 15는 각각 PVM을 제공, 수행 및 구현하도록 구성된, 무선 송/수신 유닛 및 기지국의 예시적인 기능 블록도를 나타낸다.

이하에서 언급할 때, 용어 "무선 송/수신 유닛(WTRU)"은 사용자 장비(UE), 이동국, 고정 또는 이동 가입자 유닛, 무선 호출기, 휴대 전화, 개인 휴대 정보 단말기(PDA), 컴퓨터, 또는 무선 환경에서 동작할 수 있는 기타 임의 타입의 장치를 포함하지만, 오직 이것들로만 제한되지 않는다. 이하에서 언급할 때, 용어 "기지국"은 노드-B, 사이트 제어기(site controller), 액세스 포인트(AP), 게이트웨이, 고객 구내 장비(customer premise equipment, CPE), 또는 무선 또는 유선(wireline) 환경에서 동작할 수 있는 기타 임의 타입의 인터페이싱 장치를 포함하지만, 오직 이것들로만 제한되지 않는다. 이하에서 언급할 때, 용어 "HMS"는 홈 노드 B 관리 시스템(Home NodeB Management System, HMS), 홈 인헨스드-노드 B 관리 시스템(Home Enhanced-NodeB Management System, HeMS)(여기서, HMS 및 HeMS는 집합적으로 H(e)MS로서 지칭될 수 있다), 장치 관리 시스템(DMS), 구성 서버(CS), 자동 구성 서버(ACS), 또는 "기지국"의 구성 또는 기능을 관리하는 기타 임의 타입의 시스템을 포함하지만, 오직 이것들로만 제한되지 않는다. 용어 "WTRU" 및 "기지국"은 상호 배타적이지 않다. 예를 들어, WTRU는 H(e)NB (enhanced Home Node-B)가 될 수 있다. 이하에서 언급할 때, "정보가 이론적으로 안전하다(information-theoretically secure)"는 것은 정보가 완전히 안전하고, 무조건적으로 안전하고, 그리고 이론적으로 거의 안전하다는 것을 포함하지만, 오직 이것들로만 제한되지 않는다. 이하에서 언급될 때, 용어들 "신뢰(trust)", "신뢰성있는(trusted)" 및 "신뢰할 수 있는(trustworthy)" 뿐 아니라 그 변형들은, 어떠한 유닛이 특정 방식으로 기능할 것인 지를 평가하는 정량적(quantifiable)이고 관찰가능한 방식을 나타낸다.

플랫폼 검증 및 관리(PVM)를 구현하는 방법들 및 장치들이 개시된다. PVM은, 홈 노드-B 관리 시스템(HMS)과 같은 장치 관리 시스템들에 의한 장치들의 원격 관리와 함께, 플랫폼 검증 엔티티(PVE)의 기능 및 동작들을 제공한다. PVM 동작들은, 코어 네트워크(CN)로의 접속 및 액세스를 허락하기 전에, 장치들이 보안 타겟 상태가 되게 한다.

PVM 동작들은 독립적이고, 동시에 많은 변형들을 허용하며, 그리고 다른 기술적인 상황들에서 여러 실시예들을 가능하게 한다. 인터넷 키 교환(IKE)과 같은 프로토콜들에 대한 예시적인 맵핑들이 특별한 경우들에 대해 제공되는 바, 여기에서는 일 실시예에 대해 설명하지만, 본 개시의 전체 범위를 제한 또는 한정하는 것으로서 해석되서는 안된다. 또한, H(e)NB들이 어떠한 장소들에서 예들로서 이용되기는 하지만, PVM은 이러한 H(e)NB들로만 제한되지 않는다. PVM은, 개념의 변경없이 그리고 간단한 기술적인 적응에 의해, M2M(machine to machine) 및 기타 무선 및/또는 네트워크된 장치들로 확장된다.

본 개시의 설명은, 아키텍쳐가 처음부터, 신뢰성있는 컴퓨팅 그룹(TCG)에 의해 특정되는 기술 표준들(하지만, 이것들로만 제한되지 않는다)과 관련된 신뢰성있는 컴퓨팅 기술의 대부분의 중심 개념들의 이용가능성을 가정한다는 점에서 포괄적이다. 예를 들어, 여기에서 설명되는 실시예는 PVM의 모든 동작들 및 방법에 대한 기반(base)을 확립하기 위해 신뢰성있는 환경(Trusted Environment, TrE) 및 기준 무결성 메트릭(Reference Integrity Metric, RIM)들에 의해 실행되는 보안 스타트업(secure start-up)에 의존한다. 이는 덜 신뢰성있는 기술에 기초하는 추가의 변형 구현들을 결코 배제하지 않는다. 다른 실시예들은 PVM의 다양한 단계들에서 RIM들을 이용하는 것을 피할 수 있다.

일반적으로, PVM은 기술적인 시스템들 내에서의 신뢰의 종합적인 정의에 포함되는 신뢰의 개념을 구현하는 바, 여기에서는 시스템들 내에 신뢰를 확립하기 위한 수단에 중점을 둔다. PVM은 핵심 패러다임(core paradigm)으로서 임무(duty)들의 분산화(de-centralization) 및 분리를 이용한다. 이에 의해, 요구될 때, 통신 네트워크들 및 인터넷을 진화시키기 위한 확장가능한 신뢰(scalable trust)를 가능하게 하는 바, 여기에서 노드들은 항상 이질적이고, 접속은 짧아지게 된다.

신뢰에 대한 다음의 일관된 동작 해석이 PVM과 같은 기술적인 시스템들 간의 그리고 기술적인 시스템들과 인간 간의 관계들 및 상호작용에 적용된다: "엔티티가 의도된 목적을 위해 예측된 방식으로 예측가능하게 그리고 관찰가능하게 동작하는 경우, 이 엔티티는 신뢰될 수 있다." 이러한 동작 해석은 3개의 두드러진 특징, 즉 예측가능성(predictability), 관찰가능성(observability) 및 상황성(contextuality)을 갖는다.

예측가능성은 시스템에 대한 선험적 지식(priori knowledge)을 나타내는 바, 이러한 선험적 지식은 a) 그 시스템과 상호작용을 함에 있어서 야기되는 위험을 평가하고, b) 관찰들을 추론함으로써, 상호작용을 하는 동안 그 시스템에 대한 정보를 얻을 수 있도록 하는 데에 이용될 수 있다. 관찰가능성은 상호작용들에서 시스템에 대한 지식이 얻어질 수 있는 수단 및 정도를 특정한다. 이러한 관찰가능성은 예측가능성과 밀접하게 연결되는데, 이는 관찰들이 예측들과 함께 시스템 상태에 대한 추가의 지식 및 추가의 행동을 발생시킨다는 점에서 그러하다. 상황성은 시스템과의 상호작용의 범위를 규정하는 정보를 나타내며, 이러한 범위 내에서 예측들이 유지되고 관찰들이 이루어질 수 있다. 이들을 함께 이용하게 되면, 시스템의 신뢰성(trustworthiness)을 평가하거나, 또는 상반되게는, 그 시스템이 상호작용하는 엔티티에게 부과하는 위험을 평가할 수 있게 된다.

신뢰와 강제(enforcement) 간에는, 동작상의 신뢰를 확립하기 위한 수단의 결여에 의해 야기되는 개념적인 큰 차이가 있다. 이는, 서로 연결된 시스템들의 이질성(heterogeneity)이 클라이언트-서버 관계를 넘어 성장함으로 인해 더욱 명백해졌다. 이러한 환경들에서, 그리고 최신식의 (보안) 기술을 가정하면, 강제와 동작상의 신뢰의 관점 중 어느 것도 구현될 수 없다. 시스템들은, a) 동작상의 신뢰를 확립하기 위한 유비쿼터스 기술 수단, b) 강제를 위한 무엇보다 중요한 인프라구조들, 및 c) 신뢰성에 대한 정보, 및 적용가능한 보안 레벨들을 외부 엔티티들에게 전달하기 위한 수단이 없다. 오로지 이러한 기본적인 형성 블록들(building blocks) 만이 강제와 신뢰의 동적인 밸런싱을 가능하게 함으로써, 실세계 요건들, 즉 시스템들 내에서의 확장가능한 신뢰를 반영할 수 있다.

또한, PVM은 여기에서 설명되는 형성 블록들 상에서도 확립될 수 있다. 신뢰성있는 시스템의 형성 블록들은 자신의 신뢰 경계를 확립하며, 종종 이러한 신뢰 경계를 확장하고, 어느 정도까지 예측가능하고 관찰가능한 자신의 행동 및 동작을 행함으로써 외부 엔티티에게 신뢰를 전달할 수 있는 방법들을 제공한다. 형성 블록들은 (하드웨어) 보안 앵커들(security anchors), RoT(Roots of Trust), 신뢰성있는 (서브-) 시스템 및 소유권, 안전한 저장 및 경로들, 허가(authorization), 인증되고 안전한 부트 프로세스들, 및 증명(attestation)을 포함할 수 있다. 이에 따라, 이러한 방법들, 시스템들 및 다양한 구성요소들의 결합이 구성될 수 있는데, 이는 많은 방식으로 신뢰와 강제의 특징들을 결합함으로써, 이러한 2개의 극단(pole) 간에 기술의 스케일링을 가능하게 한다. 이하, 기본적인 기능 형성 블록들에 대해 설명한다.

하드웨어 보안 앵커는 시스템 행동의 보호에 중요하다. 이러한 하드웨어 보안 앵커는, 자신에 대한 공격들의 위험을 효과적으로 완화하는 의도된 목적을 위해 충분히 안전한 것으로서 알려져있는 하드웨어 수단에 의해 비허가 액세스(unauthorized access)에 대해 보호되는 시스템의 일부이다. 특히, 이러한 하드웨어 보안 앵커는 자신의 안전한 동작을 위해 RoT를 보유한다. 이러한 RoT는 추상적인 시스템 요소로서, a) 내부 시스템 동작을 안전하게 하고, b) 시스템의 특징들 및/또는 아이덴티티를 안전하고 인증된 방식으로 외부 엔티티들에게 (개별적으로, 또는 메이크(make) 및 모델(model)과 같은 그룹의 멤버로서) 노출시킬 수 있게 한다.

시스템은 별개의 목적들을 위해 하나 이상의 RoT들을 포함할 수 있다. RoT들의 예들로는, 비대칭 키 쌍들(asymmetric key pairs) 및 이들에 대한 신뢰성있는 제 3 당사자(party)의 디지털 증명서들(digital certificates)이 있다. 또한, 셀룰러 네트워크들에서는, 가입자 식별 모듈(SIM) 카드들의 대칭 시크릿들(secrets)이 SIM 카드에 의해 구현되는 폐쇄된 신뢰성있는 시스템에 대한 RoT들로서 여겨질 수 있다.

두번째로, 신뢰성이 있는 것으로서 고려되는, 즉 의도된 목적을 위해 잘 정의된 방식으로 작동하는 것으로 추정되는 시스템 내의 기능적인 형성 블록들은 그 시스템의 신뢰성있는 컴퓨팅 베이스(Trusted Computing Base, TCB)를 형성한다. TCB는 시스템의 컴포넌트들을 포함하는데, 이들은 시스템이 필드에서 전개될 때 및 동작하는 동안에는 자신들의 동작상의 신뢰 특성들에 대해 검사될 수 없으며, 승낙(compliance) 및 순응 테스팅 및 증명과 같은 대역외 프로세스들(out-of-band processes)에 의해서만 검사될 수 있다. 일반적으로, 이러한 종류의 증명은, 이를 테면 TCB 전체 또는 이러한 TCB의 어떠한 기술 요소의 제조업자 대신, 확립된 보안 평가 표준들에 따라, 독립적인 평가기(evaluator)에 의해 수행된다. 이러한 증명이 유용하기 위해서는, 각 TCB 및 그 요소들에는 증명된 기술 부분들(pieces)로서 이들을 식별하는 정보가 부여되어야 한다.

정의된 보안 앵커, RoT들 및 TCB를 구비한 시스템은 신뢰성있는 시스템(TS)이라 불린다. 이는, "소프트웨어 프로세스들에 대한 신뢰의 토대를 생성하기 위해 이용하는, 아마도 빌트인 하드웨어 형태의 신뢰성있는 컴포넌트를 갖는 컴퓨팅 플랫폼"인 신뢰성있는 플랫폼들의 공통 개념이 약간 개량된 것이다. 하나 이상의 신뢰성있는 시스템들이 TS 내에 상주할 때, 이들은 신뢰성있는 서브시스템들(TSS)이라 불린다. 예들로는, 호스트의 신뢰성있는 플랫폼 모듈 하드웨어(Trusted Platform Module hardware, TPM)로부터 어느 정도의 신뢰성을 물려받는 개인용 컴퓨터 플랫폼 상의 가상 실행 환경들이 있다. 다른 예는 신뢰성있는 엔진의 사양과, 그것의 TCB 이다. 하기에서, 명백하게 달리 언급하지 않는 경우, "TS"는 'TS 또는 TSS'에 대한 약칭으로서 교환가능하게 이용된다. TS는 도 1에 도시된 바와 같이 다양한 장치들에서 구현될 수 있다.

이하, 용어 신뢰성있는 자원(TR)들로 요약되는, TS의 다양한 성능들, 프로세스들 및 구조적인 요소들에 대해 설명한다. 일반적으로, 2종류의 TR들로 분류된다. 즉, 1) TCB에 속하는 TR들, 및 2) TCB 바깥의 TR들이 있다. 후자에 대한 예들로는, 운영 체제의 신뢰성있는 부분들, 및 그 성능들을 이용함으로써 TCB 상에 구축되는 신뢰성있는 애플리케이션들이 있다. TCB 내의 TR의 신뢰성에 대한 표명(assertion)이 그 TCB의 정의된 보안에 의존하는 한편, 나머지 TR들의 신뢰성은 기껏해야 그 TCB의 것으로부터 도출될 수 있다. 이러한 경우, TCB는 신뢰 경계, 즉, 소정의 환경에서 신뢰성이 있는 것으로 고려되는 TS의 총 컴포넌트들이, 이를 테면 하기 설명되는 인증된 또는 보안 부트(secure boot)와 같은, TCB 외부의 TR들로 확장될 수 있게 하는 어떠한 내부 TR들을 제공해야 한다. TCB 내의 TR들은 종종 RoT와 동일한 하드웨어 보호를 공유하는 바, 이를 테면 동일한 변형 억제 칩(tamper-resistant chip) 상에 상주한다. TCB 외부의 TR들은 소프트웨어 내의 논리 유닛들로서 구현될 수 있다. 특히 TCB 외부의 TR들을 포함하는 신뢰 경계들은 순간적임을 주목해야 한다. 이들은 어떠한 목적들을 위해 얼마의 시간 동안 존재한 다음, 이후 존재하지 않을 수 있다.

TCB의 범위를 넘어 신뢰 경계를 확장하기 위한 프로세스의 일반적인 모델은 검증이다. 이 자체는 검증 프로세스를 구현하는 TR이다. 이것은 검증 프로세스 및 해당하는 TR 검증 엔티티 또는 검증기(verifier)로서 식별됨으로써, 외부 엔티티(즉, 검증기(validator))에 의한 TS의 검증 프로세스(process of validation)와 구별된다. 프로세스로서의 검증은 신뢰 경계에 새로운 컴포넌트를 포함하는데, 이는 적어도 2개의 다른 형태들이 될 수 있다. 첫 번째로, 검증기는 자신의 초기화시에 새로운 컴포넌트를 측정한다. 즉, 컴포넌트, 그 상태 및 구성이 고유하게 식별된다. 그런 다음, 이러한 측정의 결과가 저장된다. 이것의 확장으로서, 검증기는 측정들을 기준 값들과 비교하여, 신뢰 경계를 확장할 것인 지를 결정한다. 즉, 검증기는 방침(policy)을 결정하고 시행(enforce)할 수 있다. 동작상의 관점으로부터, 검증은 TS의 예측가능성에 해당하는데, 왜냐하면 검증 프로세스가 완료된 이후, 어떠한 미리 정의된 상태에 있는 것으로 추정될 수 있기 때문이다. 한편, 검증은 이러한 특성을 관찰가능하게 하고, 이에 따라 신뢰성있게 한다. 이는 보고 엔티티(reporting entity)가 검증의 결과들을 다른 당사자에게 전달함을 의미한다. 보고 엔티티에 의해 수행되는 세 번째의 중간 단계는 증명이다. 증명은 검증의 논리적인 결과 및 검증의 논리적인 필수조건이다. 이것은 측정 정보의 정확성을 보증(vouch)하는 프로세스이며, 이러한 정보에 의존하는 의존 당사자(relying party)인 검증기는 이 정보를 이용하여 원격 TS를 신뢰할 것인 지를 결정할 수 있게 된다. 검증, 증명 및 검증은 동작상의 신뢰에 대한 핵심 개념들로서, TS의 라이프 사이클에 관련된다.

TS는, 이를 테면 RoT와 같은 신뢰 경계 내의 어떠한 TR들을 액세스할 수 있는 권한이 부여된 엔티티(사람 또는 다른 기술 시스템)에 의해 소유된다. 소유권은 TS, 즉 이를 포함하는 플랫폼의 물리적인 소유에 의해 암묵적으로 구현되거나, 이를 테면 어떠한 크리덴셜(credential)을 통한 소유자의 인증에 의해 명시적으로 구현될 수 있다. 신뢰성있는 컴퓨팅 그룹(TCB) 신뢰성있는 플랫폼 모듈(TPM) 사양들의 환경에서, 이러한 인증 데이터의 프로비저닝은 소유권을 얻는 것으로서 불린다. TS와 직접 상호작용하는 소유자는 로컬 소유자라 불리는 반면, TS와의 상호작용이 임의의 방식으로(예를 들어, 통신 네트워크를 통해) 중개되는 소유자는 원격 소유자라 불린다. TS 내에 하나 보다 많은 TSS가 포함될 때, 각 TSS는 다른 소유자를 가질 수도 있고 갖지 않을 수도 있다.

도 1은 복수의 TSS들(110, 130, 150 및 170)의 컴퓨팅 도메인들의 분리를 보여준다. 각 TSS들(110, 130, 150 및 170)은 전용 MTM(Mobile Trusted Modules)(112, 132, 152 및 172)로 각각 구성된다. MPWG(Mobile Phone Work Group) 사양들의 하드웨어 보안 앵커는 상기 언급한 RoT들, TR들(신뢰성있는 자원들(114, 134, 154 및 174)) 및 신뢰성있는 서비스들(116, 136, 156 및 176)을 포함한다. 정상 소프트웨어 서비스들 및 컴포넌트들(118, 138, 158 및 178)은 각각 신용 경계(120, 140, 160 및 180) 바깥에 있다. 이들 모두가 상주하는 소위 신뢰성있는 엔진(122, 142, 162 및 182) 각각은, 특히 서로 다른 TSS들(110, 130, 150 및 170) 각각 간의 분리 및 제어된 통신을 제공하는 RoT들에 기초하는 보안 컴퓨팅 환경이다. 도메인간(inter-domain) 검증 및 허가를 조건으로, TSS는 다른 TSS와 TR들 및 심지어 MTM들의 기능들을 공유할 수 있다. 신뢰성있는 엔진들 뿐 아니라, MTM들 중 일부는, 적어도 하나의 하드웨어 보호되는 RoT(이로부터 소프트웨어 기반의 MTM들의 RoT들이 도출된다)가 존재하는 한, 소프트웨어로 구현될 수 있다. 각 TSS는 로컬 또는 원격 책임자(stakeholder) 또는 소유자에 의해 제어될 수 있다. 이동 장치의 라이프 사이클에 있어서, 반드시 모든 책임자 TSS가 존재하는 것은 아니며, (원격의) 책임자가 새로운 TSS의 생성을 초기화하고 이것의 소유권을 얻는 프로세스들이 존재한다.

PVM은 신뢰의 확립에 부분적으로 기초한다. 신뢰와 강제 간의 주요 연결(bridging) 개념은 임무들의 분리이다. 일반적으로, 임무들의 분리는 강제에 입각한 임무들을 말하는 것으로서 이해된다. 하지만, 신뢰에 대한 자연적인 관계가 있다. 의존 당사자는, 다른 시스템이 동작적으로 신뢰성을 갖는 경우에만, 이러한 다른 시스템에게 강제를 위임(delegate)할 수 있다. TS 간의 동작상의 신뢰의 확립은 제어된 정보 교환에 의존함으로써, 관찰가능성 및 예측가능성의 선확립(pre-establishment)을 가능하게 한다. 후자, 즉 예측가능성의 선확립은 TS의 바깥에서만 이루어질 수 있다.

도 2는 TSS(200, 202)에 대한 조직적인 보증을 제공하는 외부 엔티티들의 역할을 나타내는 예시적인 모델을 보여준다. TS(200, 202)는 신뢰 경계들(270, 272) 외부의 통상 애플리케이션들(normal applications)(260, 262)을 포함한다. 신뢰 경계들(270, 272) 내에는, TCB(216, 218)이 있으며, 이러한 TCB는 RoT들(208, 210) 및 TR들(212, 214)을 포함한다. 신뢰 경계(270, 272)는 보호를 필요로 하는 신뢰성있는 운영 체제들(230, 232) 또는 그 일부분, 및 신뢰성있는 애플리케이션들(234, 236)을 더 포함할 수 있다.

TS(200, 202)의 보안 특성들은 하드웨어 신뢰 앵커들(204, 206) 및 RoT들(208, 210)에 루트(root)된다. 시스템이 전개되고 동작하는 동안, 이러한 기술적인 컴포넌트들은 검사될 수 없다. 따라서, 이들은 설계 및 개발 동안 보안 평가를 받는다. 이는 독립적인 당국(authority)에 의해 수행되는데, 이러한 당국은, 평가가 성공적으로 이루어지면, 보안이 중요한 컴포넌트들의 제조업자에게 보안 증명서를 발행한다.

RoT들(208, 210) 및 신뢰 앵커들(204, 206)과 별개로, 보안 프로세스들은 또한 TCB(216, 218) 내에 다른 TR들(212, 214)을 포함하고, 다른 증명 당국들(certification authorities)(220, 222)을 필요로 할 수 있다. 평가 프로세스들 및 다른 증명 당국들의 동종의 품질을 보장하기 위해, 이들은 또한 인가 당국(accreditation authorities)(224)에 의해 평가 및 증명되며, 이러한 인가 당국은, 이를 테면 국가의 허가를 갖는 준 국가기관의 엔티티 또는 개인 엔티티가 될 수 있다. 이러한 인가 당국(224)은 또한 증명 당국들(220, 222) 간에 브리징 정보를 제공하는 역할을 할 수 있다.

증명 당국들(220, 222) 또는 이들에 의해 통지받는 기술적인 엔티티들은 크리덴셜들(226,228)을 TS(200, 202)에 발행하며, 이러한 크리덴셜들은 TR들(212, 214)에 의해 이용된다. 이러한 크리덴셜들(226, 228)은 이들이 자신들의 무결성 및 출처에 있어서 검증가능하다는 점에서 증명서들이다. 주요 예로는, 그 제조업자에 의해 TPM의 주요 RoT(EK)에 발행되는 승인 키(Endorsement Key, EK) 증명서 뿐 아니라, 플랫폼 증명서 및 다른 컴포넌트들의 증명서들이 있다. 이러한 크리덴셜들 및 암호화 수단에 의해 이들로부터 도출되는 시크릿들 역시 외부 엔티티들(특히, 다른 TS의 엔티티들)과의 상호작용에 이용될 수 있다. 일반적으로, TS들(200, 202)의 검증(240)은 인증, 및 많은 경우들에서는 기밀성(confidentiality)을 필요로 한다. 또한, TS 크리덴셜들로부터 물려받는 신뢰를 갖는 크리덴셜들 및 시크릿들은, 운영 체제들(230, 232) 및 신뢰성을 갖는 애플리케이션들(234, 236)이 보안 연계들(242, 244), 즉 통신의 인증, 기밀성 및 무결성을 제공하는 채널들을 각각 구축하는 데에 필수적이다. 이러한 보안 연계들(242, 244) 뿐 아니라, 확장된 신뢰 경계 내의 애플리케이션들은 잘 정의된 동작상의 신뢰 특성들을 갖는 보안 통신 채널들을 구축할 수 있다.

중개 엔티티(mediation entity)(250)는 도 2에 나타낸 다양한 상호작용들 간의 신뢰 확립을 용이하게 한다. 프라이버시 증명 당국(Privacy Certification Authority, PCA)가 이러한 중개 엔티티(250)의 하나의 예이다. 중개 엔티티(250)는 TS의 신뢰성에 대한 기본적인 스테이트먼트(fundamental statement)를 다른 TS 또는 의존 당사자에게 발행한다. 이러한 중개 엔티티는 TCB(216, 218) 또는 선택된 요소들, 예를 들어 신뢰 앵커(204, 206)를 신뢰성있고 증명된 컴포넌트들로서 식별한다. 이를 위해, 중개 엔티티(250)는 증명 엔티티들에 의해 발행되는 증명서들을 알고, TS로부터 이러한 증명서들을 수신할 때 이들을 검증하며, 그리고 의존 당사자에게 보증 스테이트먼트(assurance statement)를 발행할 필요가 있다. 공개 키 인프라구조들(Public Key Infrastructures, PKI) 내의 증명 당국(Certification Authority, CA)와 유사하게, 중개 엔티티(250)는 이후의 보안 연계 및 보안 통신을 용이하게 할 수 있다.

여기에서는 PVM을 위해 요구되는 신뢰 확립을 위한 형성 블록들에 대해 설명한다.

본질적으로, 검증은 요구되는 입도(granularity)에 대한 TS의 상태 변경들의 기록 및 제어이다. 이 때문에, 검증은 초기화부터 셧다운까지, TS가 상주하는 플랫폼의 동작 사이클에 단단히 바인딩된다. 따라서, 실용적인 검증 방법들은 주로, WTRU와 같은 물리 장치의 하나 이상의 프로세서들에 의해 구현되는 플랫폼들의 동작 사이클 및 부트 프로세스들과 통합된다.

TS의 내부 검증을 위한 하나의 방법은 인증 부트(authenticated boot)로서, TCB의 성능들을 이용하여, TS가 초기화될 때(예를 들어, WTRU에 전력을 공급할 때), 로드된 또는 시작된 소프트웨어 또는 하드웨어 컴포넌트들의 신뢰성을 평가한다. 인증 부트는, TS의 나머지 부분들을 시작하기 전에, RoT 및 TCB의 일정 기능들을 시작함으로써 구현된다. 이러한 부분들은 RTM(RoT for Measurement)으로서 동작한다. 이는 이후 시작 또는 로드된 컴포넌트들이 측정됨을, 즉 시작 이후, 이들 및 이들의 상태와 구성이, 예를 들어 하드웨어 컴포넌트의 내장 코드 및 로드된 프로그램들의 (바이너리(binary)) 표현에 대해 암호화 다이제스트 값들(예를 들어, 암호화 해쉬 값들)을 형성함으로써, 고유하게 식별됨을 의미한다. 특정의 요건들에 따라, 측정 값들은 보안 저장소에 저장될 수 있다. 이러한 측정 값들로부터 시스템 상태(예를 들어, 소프트웨어 명칭들 및 버전들)를 되짚어보는 데에 필요한 데이터와 함께, 이들은 TS의 SML(Stored Measurement Log)을 형성한다. PC 플랫폼들 상에서, 인증 부트는 BIOS로부터 운영 체제(OS) 로더 및 OS 자체까지의 모든 컴포넌트들을 포함할 수 있다.

인증 부트의 일 예에서, 시스템 상태는, 측정 값들을 수신하고 해쉬 값들을 이용하여 상태의 고유의 표현을 계산하는, 중앙 당국으로서의 TPM에 의한 보고 프로세스에 의해 측정된다. 설명의 목적을 위해, TPM은 1) 애플리케이션 또는 파일의 해쉬 값, 즉 외부의 (소프트웨어) 구현에 의해 계산되는 애플리케이션의 측정 값을 수신하거나, 또는 2) TPM은 해쉬 값, 즉 내부 해쉬 알고리즘 구현을 이용하여 측정 값 자체를 계산할 수 있다. 이를 위해, TPM은 몇 개의 보호된 플랫폼 구성 레지스터(Platform Configuration Register, PCB)들을 갖는다. 전력이 공급될 때 시스템 초기화와 함께 시작되어, 각각의 로드된 또는 시작된 컴포넌트에 대해, 측정 값(예를 들어, BIOS 상에서의 해쉬 값)이 TPM에 보고되고, RTM을 이용하여 SML에 안전하게 저장된다. 동시에, 액티브 PCR이 확장 절차에 의해 업데이트되는데, 이는 측정 값이 현재 PCR 값에 부가되고, 다이제스트 값이 이러한 데이터 상에 형성되어, PCR에 저장됨을 의미한다. 이러한 방식으로, 시작되고 로드된 모든 컴포넌트들을 포함하는 신뢰의 과도적인 체인(transitive chain)이 구축된다. 단일의 PCR이 단지 하나의 값을 저장하는 경우, 이는 "풋프린트 형(footprint-like)"의 무결성 검증 데이터 만을 제공할 수 있다. 이러한 값은 검증기로 하여금, 오로지 SML과 함께, 이러한 풋프린트를 재계산함으로써 이러한 신뢰의 체인을 검증할 수 있게 한다.

보안 부트는 인증 부트의 확장이다. 이는, 어떠한 독립형 및 오프라인의 기능 요건들을 반드시 갖는 셋탑 박스들 또는 이동 핸드셋들과 같은 장치들에 대해 특히 중요하다. 보안 부트를 갖추고 있는 장치들의 공통의 특징은, 예를 들어 네트워크 액세스 이전에, 이들이 자신들의 신뢰성에 대한 표명을 외부에 전달할 수 없을 때, 이들이 신뢰성있는 상태들의 세트에서 동작할 것이 요구된다는 것이다. 보안 부트에서, TS는 부트 프로세스를 관리하는 로컬 검증기(검증 엔티티) 및 로컬 엔포서(local enforcer)를 구비함으로써, PEP(Policy Enforcement Point) 및 PDP(Policy Decision Point)의 결합을 확립하여, 보안 부트 프로세스를 제어한다. 로컬 검증기는 새롭게 로드 또는 시작되는 컴포넌트들의 측정 값들을 신뢰성있는 기준 값(TRV)들(이들은 TCB에 상주하거나, 또는 TR에 의해 TS 내에서 보호되는바, 예를 들어 이들은 보호되는 저장 공간에 위치된다)과 비교하여, 이들이 로드되고 시작되는지, 아니면 시작되지 않는 지를 결정한다. 이에 따라, 시스템은 정의된 신뢰성있는 상태로 확실하게 부트될 수 있게 된다.

신뢰성있는 기준 데이터는, 알려진 완전 값(known good value)에 대해 검증 데이터를 비교하는 데에 이용되는 데이터이다. 신뢰성있는 기준 데이터를 구성하는 값들은 신뢰성있는 기준 값(TRV)들이라 불린다. 이들의 가장 잘 알려진 예는 TCG의 MPWG 사양들에서 특정되는 기준 무결성 메트릭(RIM)이다. 이들은 순수하게는, a) 측정들이 TRV를 따르는 컴포넌트들 만이 시작될 수 있도록 보장하기 위해, 보안 스타트업시 플랫폼 그 자체에 의해 이용되거나, 또는 b) 검증시 검증 데이터를 알려진 완전 값들에 대해 비교하고, 그에 의해 플랫폼 상태를 평가하기 위해, 검증기에 의해 이용될 수 있다. 본 설명에서 용어 RIM은 신뢰성있는 기준 데이터의 비제한적인 예로서 이용될 수 있다.

이 때문에, 신뢰성있는 기준 데이터는 자신에 대한 확실한 보안 표명들을 통해 신뢰적이게 되는데, 이러한 보안 표명들은 문제의 TRV를 이용하여 에이전트 또는 검증기에 의해 검증가능하다. 이러한 검증가능한 표명들은, 이를 테면 신뢰성있는 제 3 당사자(TTP)에 의해 발행되는 디지털 증명서들(본 예에서는 소위 RIM 증명서들을 발생시킨다)에 의해 구현될 수 있다. 신뢰성있는 기준 데이터의 신뢰 표명들은 또한, (예를 들어, 공통 기준의 EAL(Common Criteria Evaluation Assurance Level)에 따라), 컴포넌트 또는 플랫폼의 부가 정보, 이를 테면 외부 평가에 대한 부가 정보를 포함할 수 있다.

TRV들의 이중 양상을 주목하는 것이 중요하다. 한편으로, TRV들은 보안 부트 프로세스에서 로컬 검증을 제공한다. 이를 위해, TRV들은, 이를 테면 업데이트된 소프트웨어에 해당하는 새로운 TRV들을 TS에 프로비저닝함으로써, 측정된 컴포넌트들의 업데이트들을 가능하게 하는 TRV 프로비저닝 인프라구조에 의해 보완된다. 보안 부트 이후 TS를 검증하는 외부 엔티티에 있어서, 이 엔티티는 수신된 검증 데이터(이를 테면, 소위 이벤트 구조)를 저장된 TRV들과 비교하고, 관련된 TRV 증명서들을 검증할 필요가 있다. 따라서, TRV들 및 그에 따른 증명서들은 검증에서 뿐 아니라, 검증에서도 중요한 역할을 한다.

증명 정보의 새로움(freshness)은 검증에 있어서 중요한 문제이다. 이것은 부트로부터 TS의 동작 시간까지 검증 프로세스를 확장시킬 것을 필요로 하는데, 이러한 검증 프로세스의 확장은 복잡한 개방 시스템들에서 기술적으로 어려운 작업이다.

또한, TS를 검증하는 프로세스에는 상기 언급한 임무들의 분리가 존재한다. 즉, 검증의 결과에 기초하여, 시스템의 신뢰성이 평가되며, 그에 따라 검증시 방침 결정들이 이루어질 수 있다. 이러한 프로세스에 있어서 TS와 검증기 간의 작업들의 분리는 검증의 3개의 카테고리를 가져온다. 여기에서는, 모든 종류의 검증에 대해 요구되는 공통의 기본 개념에 대해 먼저 설명한다.

TS의 검증 프로세스는 검증기에 제시되는 검증 아이덴티티(validation identity)에 의해 지원되어야 한다. 이러한 검증 아이덴티티는 RoT, 즉 RTR(RoT for Reporting)로부터 직접적으로 또는 간접적으로 비롯되어야 한다. 중개기(mediator)가 없으면, 검증이 가능하지 않을 수도 있다. 이러한 검증 아이덴티티 제공자는 검증 아이덴티티의 보유자가 TS임을 표명하는 작업을 한다. 검증 아이덴티티의 프로비저닝은 아이덴티티 관리(IdM) 시스템들에서의 아이덴티티 프로비저닝의 확장이다. 이러한 검증 아이덴티티 제공자는, TCB 내의 TR들의 일부 또는 전부를 포함하는 TS의 크리덴셜들에 대한 체크를 수행하여, 그 TS가 검증을 위한 신뢰할 수 있는 상태에 있는 지를 평가해야 한다. 또한, 검증 아이덴티티들의 프로비저닝은 보안 프로세스에서 수행되어야 하는 바, 예를 들어 전용 보안 채널 상에서 보안 프로토콜로 수행되어야 한다. 원격 검증의 경우, 검증 아이덴티티는 TS의 글로벌 아이덴티티(global identity)와 일치할 수 있다.

고유의 영구적인 검증 아이덴티티들을 이용하는 검증은 보안과 관련하여 중요하다. 검증은 많은 목적으로 많은 검증기들에 대해 빈번하게 그리고 무차별적으로 일어날 수 있다. 비록 이용되는 검증 아이덴티티들 각각이 사용자 아이덴티티에 대해 용이하게 관련되지 않을 수도 있지만, 이들은 일반적으로 TS의 행동의 추적을 가능하게 한다. 하나의 그룹 또는 모든 TS에 대해 동일한 검증 아이덴티티를 이용하는 것은 보안 이유들로 인해 이를 해결하기 위한 옵션이 아니다. 이러한 그룹 아이덴티티는 공격/실패의 단일 포인트가 될 수 있다. 즉, 만일 그룹의 하나의 TS가 손상된다면, 나머지 모든 것들 역시 검증을 더 이상 수행할 수 없다. 다른 옵션은, 이를 테면 결정되는 주파수를 가지며 각 부트 사이클에서 발생되거나, 또는 각 검증에 대해 RTR에 의해 발생되는 순간적인(ephemeral) 검증 아이덴티티들을 이용하는 것이다.

자율적인 검증(autonomous validation)은, TS의 검증이 전적으로 국부적으로, 즉 장치 자체의 범위 내에서, 다시 말해 외부 엔티티들에 의존하지 않는 방식으로 이루어졌음에 틀림없다는 추정에 기초하여, 외부 검증기에 의한 TS의 검증이 암묵적으로 이루어지는 절차이다. 이러한 경우, 성공적인 검증은, TS가 외부의 또는 다른 동작에 의한 추가의 통신 시도들을 허용하기 전에 일어나는 것으로 여겨진다. 따라서, 이러한 경우 검증 프로세스는 절대적으로 안전한 것으로 여겨지는데, 왜냐하면 검증의 어떠한 직접적인 증거도 외부 세계에 제공되지 않기 때문이다. 외부 세계는, TS가 특정 및 구현되는 방식으로 인해, 검증에 실패한 TS는 그것의 TCB에 의해 외부 세계에 가시적인 다른 작업들(예를 들어, 자신을 네트워크에 어태치하거나, 또는 원격 엔티티에 대한 인증된 접속을 얻는 것)을 수행하지 못하게 될 것으로 추정한다. 자율적인 검증은 TS 상에 모든 강제 임무들을 둔다.

자율적인 검증은 폐쇄된 불변(immutable) 시스템 모델을 TS에 적용하는 바, 이러한 폐쇄된 불변 시스템 모델은 본질적으로는 스마트 카드들에서 이용되는 신뢰 모델이다. TS는 TCB를 이용하여 그 자체를 검증하며, 그 결과는 "성공" 또는 "실패"의 바이너리 값이다. 이렇게 되면, 검증은 TS가 외부와의 어떠한 상호작용(이를 테면, 네트워크 어태치먼트)을 가능하게 하는 암묵적인 프로세스(implicit process)이다. 전형적인 예는 스마트 카드에 의한 인증 시크릿(예를 들어, 암호 키)의 해제이다.

장치들에만 의존하는 보안은 과거에는 깨졌으며(즉, 뚫렸으며), 그리고 깨질 가능성이 더 큰데, 그 이유는 이를 테면, 이동 장치들이 개방된 컴퓨팅 플랫폼들이 되기 때문이다. 자율적인 검증은 진보된 보안 요건들에 대한 정보를 거의 포함하지 않는다. 특히, TS가 부분적으로 손상되면, 외부에서는 그 상태에 대한 어떠한 지식도 얻을 수 없다. 따라서, 악의적인 장치들에 라벨을 붙이는 것(labeling)이 불가능한데, 이는 부당한 이용(exploit)이 통지되지 않으면서 급격히 증가되어, 다른 책임자들(이를 테면, 네트워크 오퍼레이터들)에게 상당한 손해를 야기할 것임을 의미한다. 자율적인 검증은, 실패 방침(failure policy)에 의존하여, 일정 기능들을 허용하지 않거나, 또는 장치를 다운(down)시키고 리부트(re-boot)시킴으로써, 검증이 일정 조건들에 반응하는 방식으로 구현될 수 있다. 이것은 네트워크 접속을 피하며, 유익한 것으로 보인다. 하지만, 이것은 또한 서비스 거부(denial-of-service, DoS) 공격들에 대한 벡터이다. 장치는 손상된 상태로 네트워크에 어태치해서는 안되며, 이에 따라 안전한 상태로 되돌아갈 기회를 거의 갖지 않는다. 원격 관리 역시 어렵게 되는 바, 특히 악의적인 장치들에 값들(소프트웨어, 시크릿들)을 전달할 가능성이 있기 때문에, 소프트웨어 다운로드 및 설치에 있어서 보안 손실이 있을 수 있다. 따라서, 자율적인 검증은 대역외 유지를 수반하는 경향이 있다. 이를 테면, TR의 소프트웨어의 업데이트의 실패는 네트워크 접속이 불가능한 상태를 야기할 수 있다.

자율적인 검증을 이용하게 되면, 증명 데이터의 새로움은 그 자체만으로는 보증되지 않는다. 이러한 보안 특성을 만족시키기 위해서는, 시스템 상태가 변경될 때 마다 자율적인 검증이 자동으로 일어나야 한다. 실제로 자율적인 검증은, 예를 들어 네트워크 어태치먼트 동안, 드물게 일어나기 때문에, TS의 상태는 TS가 동작하는 동안 검증기에 의해 관찰불가능한 방식으로 크게 변경될 수 있다. 따라서, 공격자는, 이를 테면 이러한 갭을 이용하여, 악의적인 소프트웨어를 도입시킬 수 있다. 자율적인 검증은 이러한 종류의 타이밍 공격을 받기가 매우 쉽다.

원격 검증에 있어서, 검증기는 자신이 수신하는 검증에 대한 증거에 기초하여 TS의 유효성(validity)을 직접적으로 평가한다. 이 경우 검증은 단지 수동적이며, 완전한 SML이 검증기에 전달되어야 한다. 이에 대한 모델이 되는 경우는 인증된 부트 및 그 이후의 검증이다. 모든 방침 결정들은 검증기에 달려 있다.

검증 기술에 대한 현재 기술의 상태는 원격 검증, 특히 TCG 원격 증명이다. 원격 증명에서, TCG 신뢰성있는 플랫폼은, 증명 아이덴티티 키(Attestation Identity Key, AIK)에 의해 서명되는 원격 증명의 검증 및 검증 데이터인 SML 및 PCR을 외부 검증기에 제시한다. 이러한 AIK들은 검증 아이덴티티 제공자의 역할을 하는 PCA에 의해 증명되는 순간적인 비대칭 키 쌍들이다. 원격 증명에서 제공되는 가명(pseudonym)은 모든 경우들에서 충분하지 않을 수도 있다. TCG는 부가적으로 정의되는 DAA(Direct Anonymous Attestation)를 갖는 바, 이러한 DAA는 제로 지식 증명(zero-knowledge proof)에 기초한다.

원격 검증 및 자율적인 검증은 모두 반 자율적인 검증에 포괄되는 옵션들의 스펙트럼의 극단들(extremes)이기 때문에, 원격 검증 역시 단점들을 갖는다. 원격 증명에 의해 표현되는 원격 검증은 확장성 및 복잡성과 관련하여 실제적인 문제들을 갖는데, 왜냐하면 이러한 원격 검증은 네트워크들 또는 서비스들에 대한 (중심) 액세스 포인트들에 검증을 위한 전체 계산 부하를 두기 때문이다. 특히, SML의 검증은, 많은 버전들 및 구성들을 갖는 많은 수의 소프트웨어 및 하드웨어 컴포넌트들로 인해, 개인용 컴퓨터들과 같은 플랫폼들에 대해 비용이 매우 많이 들 수 있다. 이는 또한, 인프라구조와 함께, RIM들과 같은 TRV들의 막대한 데이터베이스를 요구함으로써, 책임자로 하여금 TS의 원하는 타겟 구성들을 정의하게 한다. 동일한 논의가 TS의 원격 관리, 즉 원격 검증에 대해서는 비현실적인, 구성의 제어 및 검증된 변경을 행한다. 또한, 원격 검증에 대해서는 런타임 검증(run-time verification)이 바람직한데, 그렇지 않으면 부트 이후의 상태 만이 검증기에 제시되기 때문이다. SML은 검증시에 "약해질 수 있다(withered)". 따라서, 런타임 검증은, 매우 빈번한 원격 검증들을 필요로 하는 검증이 바로 뒤따르지 않는 다면, 무의미해진다. 마지막으로, PCA의 이용에도 불구하고, 복잡한 개방형 TS의 원격 검증은 프라이버시를 손상시키는데, 왜냐하면 드러난 SML은 TS에 거의 고유하기 때문이다. 유사한 경제적인 논의는 원격 증명에 의한 차별(discrimination), 즉 주요 벤더들의 소프트웨어의 최신 버전들 만이 RIM 데이터베이스들과 같은 TPV 데이터베이스에 입력됨으로써, 다른 프로그램들의 사용자들로 하여금 강제적으로 이러한 최신 버전들로 스위치하게 하거나, 또는 서비스 액세스를 루스(loose)하게 하는 위협의 가능성이다. 일부 단점들은, 구체적인 구현이 아니라 컴포넌트들의 특징들을 제시하는 것을 목표로 하고 있는, 이를 테면 의미 또는 특성 기반의 검증과 같은 다른 형태들의 원격 증명에 의해 경감될 수 있다.

반 자율적인 검증은 다른 절차인데, 여기에서는 TS의 유효성이 외부 엔티티들에 의존하지 않으면서 그 자체 내의 장치 상에서 국부적으로 검증 동안 평가되며, 방침 결정들이 검증 동안 이루어진다. 하지만, 이러한 경우, 검증 결과 및 요구되는 증거와 같은 어떠한 정보(여기에서는 "검증 메시지"라 불린다)가 검증기에 시그널링되며, 이러한 검증기는 TS로부터의 검증 메시지들의 콘텐츠에 기초하여 결정들을 할 수 있다. 요구되는 경우, 인증, 무결성 및 기밀성을 제공하기 위해, TS로부터 검증기로의 시그널링은 보호되어야 한다. 반 자율적인 검증에 대한 모델 케이스는, 보안 부트 다음에, RIM들과 같은 TRV들의 표시 및 이벤트 구조가 검증기에 시그널링되는 것이다. 반 자율적인 검증은 TS와 검증기 간에 검증 및 강제 작업들을 분배한다. 구체적으로, 보안 부트에서, TS는 컴포넌트들이 로드될 때 결정들을 할 수 있는 반면, 검증기는 제공되는 상태 증거에 기초하여, 검증시 TS에 허가되는 상호작용들에 대한 결정들을 시행할 수 있다.

반 자율적인 검증은 나머지 2개의 옵션들에 비해 장점들을 제공할 수 있다. 이러한 반 자율적인 검증은 검증에서 이용되는 RIM들의 표시자들의 형태로 보다 효율적으로 검증 정보를 전달할 수 있는 가능성이 있다. 이는 또한, 이를 테면 이러한 표시가 동일한 기능 및 신뢰성(이를 테면, 버전들)을 갖는 컴포넌트들의 그룹을 나타낼 때, 프라이버시를 보호하는 데에도 이용될 수 있다. 이것은 의미 및 특성 기반 증명과 유사하며, 반 자율적인 검증은 상기 언급한 진보된 형태들의 원격 검증과 결합될 수 있다. 검증기의 일부 상에서의 검증에 있어서의 강제의 상호작용 역시 TS의 원격 관리에 대한 옵션들을 제공한다.

기술적인 구현의 경로에서, "무결성 검증에 있어서의 실패로 인해 네트워크 액세스 허가를 얻는 데에 성공하지 못한 AR(액세스 요청기)들의 분리 및 교정(remediation)에 대한 지원"을 얻기 위해, 교정이 이용될 수 있다. 이에 의해, 이론적으로, 허가에 대한 현재의 방침에 의해 정의되는 모든 무결성 관련 정보에 있어서 AR이 최신이 될 수 있게 된다. 예들로는, OS 패치들, AV(Antivirus) 업데이트들, 펌웨어 업그레이드, 및 기타 유사한 소프트웨어 또는 펌웨어 업데이트들이 있다. 원격 관리의 구현을 위한 구체적인 개념들은, 여기에서 PVM에 대해 설명되는 바와 같이, RIM 정보와 같은 TRV 정보의 효율적인 표현 및 통신에 대한 인프라구조에 의존해야 한다.

반 자율적인 검증에서 RIM 증명서들에 의한 역할을 강조하는 것이 중요하다. RIM 증명서들은 증명 당국에 의해 제공되는 바, 이러한 증명 당국은 해당 TR을 직접 또는 위임에 의해 액세스한다. 증명 방법들 및 기관들은 다를 수 있으며, 다른 레벨들의 동작 신뢰성을 가져올 수 있다. 이는 TS에 대해 더욱 미세한 입도(fine-grained)의 정보를 얻는 반 자율적인 검증기에 대한 추가의 유연성을 가져온다. 여기에서 주목하는 바와 같이, RIM 증명서들은 컴포넌트들의 온디바이스(on-device) 검증을 지원할 수 있는 데이터에 대한 예로서 이용된다. 비록 여기에서는 RIM 증명서 기반의 SAV 방법에 대해 설명하지만, 다른 SAV 변형들도 이용될 수 있다.

또한, 반자율적인 검증은, 리소스가 제한되는 시스템들(리소스 제한으로 인해, 이러한 시스템들은 a) 자율적인 검증을 하기 위한 처리 성능이 부족하고, b) 원격 검증에 필요한 광범위한 보고를 수행하기 위한 메모리 및/또는 통신 성능들이 부족하게 된다)에 대한 유일한 실제적인 검증 옵션이다. 예를 들어, 무선 센서 네트워크들의 환경에서, 이러한 2개의 제한들은 센서 노드들에 대해 유지될 수 있다. 이러한 환경들 하에서, 하나의 시도는 메모리 프로빙 코드(memory probing code)를 센서들에 전송하는 것인데, 이러한 센서들은 정적 메모리 콘텐츠(코드 및 파라미터들)의 다이제스트 값을 계산하여, 예측가능한 결과를 이끌며, 이러한 결과는 검증을 위해 기지국에 리턴된다. 공격자는 정확한 출력을 발생시키기 위해 세이브된 최초 메모리 콘텐츠들 이용함으로써 이러한 "증명"을 교묘하게 회피하고자 분명히 시도할 수 있다. 하지만, 이러한 공격이 센서 자체에서 수행되는 한, 이는 불가피하게 지연을 야기하게 되는데, 이러한 지연은 무작위화(randomization), 자기 수정 프로빙 루틴들(self-modifying probing routines) 및 불명료화(obfuscation) 방법들에 의해 증가될 수 있다. 센서의 응답에 있어서 일정 임계치를 넘는 상당한 지연이 발생하면, 그 센서는 무효화된다.

반 자율적인 검증에 있어서, H(e)NB의 유효성은 외부 엔티티들에 의존하지 않으면서 보안 셋업 동안 내부적으로 평가되며, 이러한 평가 동안, 특히 어떤 컴포넌트들을 로드/시작할 것인지 그리고 어떤 컴포넌트들을 로드/시작하지 않을 것인 지에 대한 방침 결정들을 이러한 컴포넌트들의 측정된 무결성에 기초하여 행한다. 반 자율적인 검증에 있어서, 평가 결과 및 요구되는 증거는 플랫폼 검증 엔티티(PVE)에 시그널링되며, 이러한 PVE는 검증 메시지들의 콘텐츠에 기초하여 그 자체의 결정들을 행할 수 있다. PVE로의 시그널링은 인증, 무결성, 및 요구되는 경우, 새로움 및 기밀성을 제공하기 위해 보호되어야 한다. 반 자율적인 검증은 PVE와 같은 외부 검증 엔티티와 H(e)NB들 간에 무결성 검증 및 시행 작업들을 분배한다. 구체적으로, 보안 부트에서, H(e)NB는 컴포넌트들이 로드/시작될 때 국부적으로 결정들을 할 수 있는 반면, PVE는 제공되는 상태 증거에 기초하여, 검증시 H(e)NB에 허가되는 상호작용들에 대한 결정들을 시행할 수 있다. PVE의 결정 결과에 의존하여, 네트워크에 대한 완전한 액세스 및 서비스가 허가되거나, 또는 격리된(quarantine) 네트워크 액세스 및 강제된 구성 변경들과 같은 보다 제한된 조치들이 제공될 수 있다.

신뢰성있는 환경(TrE)이라 불리는 신뢰성있는 엔티티는 반 자율적인 검증에 있어서 중요하다. 반 자율적인 검증에 대한 절차들은 다양할 수 있다. 일 실시예에서, 도 3의 흐름도(300)에 의해 도시한 바와 같이, H(e)NB는 그 H(e)NB의 무결성의 반 자율적인 검증을 수행할 수 있다. 장치 인증 절차를 수행하기 전에, H(e)NB의 TrE는 먼저 H(e)NB의 어떠한 미리 지정된 컴포넌트들(이를 테면, 부트 코드들)의 무결성 체크를 수행한다(305). 이후, 무결성 체크의 결과가 적어도 일시적으로 기록 또는 저장된다(310). 이는, H(e)NB의 파워온 이후, (예를 들어, 안전한 백홀 링크(backhaul link)를 셋업하기 위한) 인증의 제 1 인스턴스(instance) 이전에, TrE 자체에 의해 자율적으로 개시될 수 있다. 이것은 '보안 부트'로서 고려될 수 있다. TrE는 등록된 컴포넌트들 만이 무결성 검증된 상태(integrity-proven state)로 로드/시작될 수 있도록 강제함으로써, H(e)NB의 무결성을 보장한다. 이를 테면, 이전의 성공적인 네트워크 접속 세션 이후 이루어진 H(e)NB의 구성의 변경으로 인해, 구축된 신뢰가 재평가될 것이 요구된다면, 무결성 검증된 스타트업 상태의 달성에 대한 이러한 체크는 2개의 방법으로 다시 일어날 수 있다. 제 1 경우, 이러한 체크는 TrE 자체에 의해 자율적으로 개시될 수 있다. 대안적으로, 이러한 체크는 네트워크(예를 들어, 보안 게이트웨이(Secure Gateway, SeGW) 또는 플랫폼 검증 엔티티(PVE))로부터의 요청에 의해 개시될 수도 있는 바, TrE가 이러한 요청을 수행할 것이 요구된다.

이후, TrE는 H(e)NB의 나머지의 미리 정의된 부분이 보안 스타트업 상태를 달성했는 지를 체크할 수 있다(315). 추가의 체크가, TrE 자체에 의해, 또는 TrE의 외부에 있지만 이 TrE에 의해 무결성이 보호되는 H(e)NB 내의 측정 컴포넌트들에 의해 일어날 수 있다(320). 이러한 나중 스테이지(later-stage) 체크에서, 다른 컴포넌트들의 무결성, 구성들, 또는 H(e)NB의 나머지의 파라미터들은, 이들이 측정 요소에 이용가능하게 되는 어디에서든지, 이들이 로드 및 시작될 때, 또는 다른 미리 정의된 실시간 이벤트들에서 체크된다. 보안 스타트업 체크 결과들은 적어도 일시적으로 기록 또는 저장된다(325). 보안 스타트업 체크 결과 뿐 아니라 무결성 체크 결과는, TrE에 의해 제공되는 보호되는 저장소(storage), 또는 키 해쉬 값들(keyed hash values)과 같은 다른 형태의 무결성 보호를 이용하는 방식으로 기록되는 것이 바람직하다.

추가의 변형으로서, 결과들, 즉 단일 측정들 자체는, PVE에 의해 프로토콜에 이미 제공된 새로움 이외에, 새로움을 제공하고 측정들 자체에 대한 보호를 리플레이(replay)하기 위해 보안 타임 스탬프(secure time stamp)들을 부가적으로 구비할 수 있다. 예를 들어, 이러한 새로움 정보들은, 해쉬 함수(Hash function)를 적용한 다음, 그 결과를 PCR 같은 보호 레지스터에 저장하기 전에, 값들을 연관시킴으로써 타임 스탬프의 값을 측정 내에 포함시킴으로써 달성될 수 있다.

그런 다음, TrE는 체크들의 결과들을 처리하여, 이러한 결과들로부터 PVE에 전달될 검증 메시지를 형성한다(330). PVE가 이러한 메시지를 수신하면, PVE는 이 메시지를 이용하여 H(e)NB의 신뢰 상태를 평가할 수 있다(335). 하나의 처리 실시예에서, TrE는, TrE에 의해 보호되는 서명 키(signing key)를 이용하여, 그리고 이에 따라 스테이트먼트의 무결성을 보호하면서, H(e)NB가 자율적인 검증 체크를 통과(pass)했다는 스테이트먼트에 서명한다. 이러한 스테이트먼트는 또한, H(e)NB의 미리 지정된 컴포넌트에 대해 TrE에 의해 수행되는 무결성 체크의 상태 또는 결과를 평가하기 위해 PVE에 의해 이용될 수 있는 증거를 포함할 수 있으며, 그리고 자율적인 검증 체크와 장치 인증의 후속 절차 간의 어떠한 바인딩의 증거를 또한 포함할 수 있다. 또한, TrE는 새로움을 보장하기 위해 이러한 스테이트먼트에 타임 스탬프를 넣을 수도 있다. 이러한 서명된 스테이트먼트는 TrE가 재배열된 데이터 또는 결과들로부터 만들어 PVE에 전달한 메시지가 보안 스타트업 절차 이후 H(e)NB의 TrE로부터 비롯되었다는 사실을 증명한다. 서명의 검증을 위해, 검증이 장치 인증에 바인딩되거나, 또는 그렇지 않으면 개별적인 TrE 아이덴티티가 이용되어야 한다. 이러한 서명은, H(e)NB의 스타트업 구성의 TrE의 자율적인 체크들의 결과들이 신뢰성이 있다는 사실에 의해 지원되는 어떠한 추적가능성(traceability)을 부가함으로써, 완전히 자율적인 검증 체크의 보안을 증가시킨다.

TrE는 서명된 스테이트먼트를 SeGW를 통해 PVE에 전달하며, PVE는 H(e)NB로부터의 이러한 서명된 스테이트먼트를 이용하여, H(e)NB로 하여금 인증을 진행할 수 있게 할 지를 결정한다(340). PVE는 서명된 스테이트먼트 내의 정보를 다양한 방식들로 이용할 수 있다. 일 실시예에서, PVE는 단일의 정적인 구성에 대해 TrE 자체의 무결성을 체크할 수 있으며, 실패한 경우, 액세스 접속을 거부할 수 있다. 다른 실시예에서, PVE는 액세스 제어에 대해 미세한 입도의 결정들을 행하도록 구성될 수 있다. 이는 특히, TrE 내부 또는 외부의 단일/다수의 컴포넌트들의 존재/부재 및 무결성에 기초하여 액세스가 거부될 수 있음을 의미한다. 또 다른 실시예에서는, 검증 스테이트먼트에 포함된 표시들에 기초하여, PVE는 신뢰성있는 제 3 당사자로부터 H(e)NB 컴포넌트들의 무결성과 보안 특성들에 대한 정보를 페치(fetch)하도록 구성될 수 있다. 이는 PVE가 장치 상의 컴포넌트들에 대한 기준 값들에 대한 정보, 즉 검증 데이터를 페치하도록 구성될 수 있음을 의미한다. 그런 다음, 장치로부터 수신된 데이터와 검증 데이터의 비교 프로세스에 의해, 컴포넌트들의 실제 무결성에 대한 정보가 얻어진다. PVE는 TTP들로부터 컴포넌트의 무결성에 대한 스테이트먼트를 직접 페치하는 것이 아니라, 보고되는 값들이 비교될 수 있는 TRV들 만을 페치한다. 또 다른 실시예에서, PVE는 액세스를 허가하기 전에 구성 변경들을 명령하도록 구성될 수 있다. 이러한 교정 절차들은 강제적인 소프트웨어 업데이트를 포함할 수 있다.

나타낸 바와 같이, TrE는 신뢰성 있고 정확한 타임 스탬프를 만들 수 있으며, TrE 내에서 또는 TrE에 의해 보호되는 키(들)로 이러한 타임 스탬프들에 서명할 수 있다. 일 실시예에서, 외부 검증기는 TRE에 의해 로컬의 자율적인 장치 무결성 체크가 수행되었던 '시간'을 검증할 수 있다. 이는 처음 또는 마지막 측정시에 하나의 타임 스탬프를 받았음을 의미할 수 있다. 대안적으로, 이는 PVE에 의해 프로토콜이 실행될 때 타임 스탬프가 적용됨을 의미할 수 있다. 이는 또한 매 측정마다 타임 스탬프가 포함됨을 의미할 수도 있다. 요구되는 "시간 입도(time-granularity)"가 어떤 대안이 적용가능한 지를 지시할 수 있다. 다른 실시예에서, TrE는 2개의 타임 스탬프들을 삽입하도록 구성될 수 있는 바, 하나는 TRE에 의해 로컬의 자율적인 장치 무결성 체크가 수행되기 전에 삽입되고, 나머지 하나는 이러한 무결성 체크가 수행된 후에 삽입된다. 이러한 타임 스탬프들의 쌍은 로컬의 자율적인 장치 무결성 체크가 실제로 일어나는 시간 범위를 효과적으로 '바인딩'시킨다. 그리고, TrE는 이러한 타임 스탬프들과 함께, 로컬의 자율적인 무결성 체크의 결과 또는 프로세스를 나타내는 데이터를 전송함으로써, 외부 검증기로 하여금, 장치 무결성 상태를 평가할 수 있게 할 뿐 아니라, 언제 그리고 어떻게 TrE에 의해 H(e)NB의 무결성이 국부적으로 측정 및 검증되었는 지의 시간 히스토리(temporal history)를 알 수 있게 한다. 이것은 검증기로 하여금 그 자신의 '시간 창(time windows)'을 이용하여, 자신이 장치 무결성의 상태와 관련하여 TrE로부터 받은 서명된 스테이트먼트가 어떻게 처리될 수 있는 지를 결정할 수 있게 하는데, 이는 1) 타임 스탬프된 검증 메시지를 받았을 때의 검증기 자신의 시간 표시 뿐 아니라, 이러한 스테이트먼트가 얻어졌던 시간(이것은 두번째의 나중 타임 스탬프에 의해 표시된다) 및, 2) (2개의 타임 스탬프들로부터 표시되는 2개의 시간들 사이에 바인딩되는) 로컬의 자율적인 무결성 체크가 발생하는 시간에 의존하여 이루어진다.

PVM은 여기에서 설명되는 PVM 방법들, 장치 및 아키텍쳐를 통해, 여기에서 설명되는 전략들 및 방법들을 구현하는 데에 이용될 수 있다. 일반적으로, PVM은 액티브 엔티티들 간의 임무들의 최대의 분리를 이용한다. 이러한 시도는 플랫폼 검증 및 관리 프로세스들에 연관되는 모든 엔티티들의 활동 분야들을 명확하게 정의한다. PVM 시도의 장점들은 다음과 같다: 1) 각 엔티티는 성능에 대해 개별적으로 최적화될 수 있고; 2) PVM이 인에이블된 장치들은 (제한적으로) 비동기적으로 동작할 수 있고; 3) 수반되는 네트워크 엔티티들에 대해 가능한 한, PVM 방법들은 스테이트리스(stateless)로 수행될 수 있고; 4) 엔티티들은 개별적으로 유지 및 관리될 수 있으며; 그리고 5) 리던던시(redundancy) 또는 페일오버(failover)가 보다 용이하게 구현될 수 있다. 특히, 성능 및 유효성은 장치들의 검증 및 원격 관리를 효과적으로 구현하는 데에 필수적이다. 구체적인 시나리오들에서는, 장치 컴포넌트들의 대량의 업데이트들 또는 많은 수의 장치들이 SHO(selected home operator)를 변경하는 이벤트들이 있을 수 있다. PVM 아키텍쳐는 하나의 오퍼레이터(일반적으로, SHO)에 의해 단일 장치의 검증 및 관리를 수행하도록 구성될 수 있다. 예외로서, 여기에서 설명되는 바와 같이, PVM의 특별한 변형은 로밍 액세스 및 오퍼레이터 변경에 영향을 줄 수 있다.

PVM은, 장치들이 통신 네트워크에 접속하고자 처음 시도할 때, 그리고 이후 장치 무결성을 모니터링할 때, 신뢰성있는 컴퓨팅으로부터의 보안 기술에 부분적으로 의존하여, 이러한 장치들을 검증 및 관리하기 위한 시스템적인 방법을 제공한다. PVM은, 1) 네트워크 접속전에 장비를 검증하고; 2) 전파를 통해(Over-the-Air, OtA) 장치 구성을 관리하고; 3) 컴포넌트 로드/시작시에 RIM들과 같은 TRV들을 체크함으로써 보안 스타트업을 하며; 그리고 4) 구성 변경-TRV 인제스천(ingestion)을 위해 장치 상에 새로운 TRV들(예를 들어, RIM들)을 설치한다.

여기에서 설명되는 PVM의 예시적인 실시예들에서, 다음은 검증 장치 및 이것이 검증하는 네트워크에 대한 기술적인 가정들 및 필수 조건들이다. 네트워크와 관련하여, 먼저 모든 엔티티들은 동일한 코어 네트워크(CN)의 일부로서 동일한 이동 네트워크 운영자(MNO)에 의해 동작하는 것으로 가정된다. 이에 따라, 이러한 엔티티들 간의 채널들의 설정 및 실제 통신을 위한 부가적인 보안(예를 들어, 상호 인증, 메시지의 무결성 보호, 암호화)은 요구되지 않는다. 어디에서 필요하든 간에, 부가적인 보안 피쳐들이 특별하게 이용되는 경우, 이러한 피쳐들에 대해 설명한다. 하지만, PVM의 적용가능한 범위는 이러한 예들 보다 더 넓은데, 왜냐하면 PVM 시도는 MNO의 CN 외부의, 또는 심지어 MNO 이외의 다른 당사자에 의해 호스트되는 엔티티들에 대해 이용될 수 있기 때문이다.

장치와 관련하여, 장치들은 많은 특징들을 가지며 많은 명칭들을 가질 수 있다. PVM은 M2M(machine to machine) 장치들 및 E-UTRAN(Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network) 네트워크의 H(e)NB들에 적용가능하며, 그리고 특정의 필수 조건들을 만족시키는 기타 많은 네트워크 장치들에 적용가능하다. 이러한 필수 조건들은 본질적으로 신뢰성있는 시스템(TS)의 것들이다. PVM이 적용되면, 다양한 장치들은 PVM 방법들을 실행하도록 구성됨으로써, PVM 장치들이 된다.

검증 프로세스에 대한 필수 조건으로서, 장치가 인증할 수 있는 아이덴티티가 요구된다. (검증 후에 일어나거나, 또는 검증 절차에 바인딩되는) CN에 대한 장치의 인증과 혼동되지 말하야 하는 이러한 인증은, 가짜 장치들에 의한 어떠한 공격들로부터 PVM 인프라 구조를 보호하는 데에 필요하다. 이는, 장치들이 장치 아이덴티티에 대해 인증된 경우에만, PVM에 대해 허락됨으로써, PVM 프로토콜들을 수행할 수 있는 알려지지 않은 장치들이 PVM 시스템에 대해, 예를 들어 DoS 공격들을 개시하는 것을 막을 수 있음을 의미한다.

PVM을 위하여, 장치 아이덴티티(Dev_ID)가 장치 내의 신뢰성있는 환경(TE), 범용 집적 회로 카드(UICC), 또는 스마트 카드, 또는 예를 들어 H(e)NB 자체와 같은 장치에 바인딩되는 아이엔티티인지의 여부는 문제가 되지 않는다. 장치는 Dev_ID와 관련된 인증 크리덴셜을 안전하게 관리하며, 이에 따라 이 Dev_ID를 인증할 수 있는 것으로 가정된다. Dev_ID는 FQDN(Fully Qualified Domain Name), URI(Uniform Resource Identifier), URL(Uniform Resource Locator), URN(Uniform Resoruce Name), (이를 테면, EUI(Extended Unique Identifier)-48, 즉 EUI-64와 같은) MAC(Medium Access Control) 어드레스, IPv4 또는 IPv6 어드레스, 서브넷 어드레스를 포함하는 (이를 테면, 64LSB들과 같은) IPv6 호스트 식별자, IMEI(International Mobile Equipment Identity), (GSM/UMTS와 같은) IMEISV, ESN(Electronic Serial Number), (CDMA와 같은) MEID(Mobile Equipment Identifier), IMSI(International Mobile Subscriber Identity), (가입자와 장치 간의 1:1 맵핑으로 인해 가입자에 의해 장치가 식별될 때) TMSI(Temporary Mobile Subscriber Identity), (IMPI(IP Multimedia Private Identity) 또는 IMPU(IMS User Public Identity)와 같은) IMS 가입자 ID, MSISDN(Mobile Station Integrated Services Digital Network), 또는 각 오퍼레이터에 대해, 단일 장치를 확실하고 명백하게 식별할 수 있도록 하기 위해, 글로벌의 또는 적어도 도메인 특정이 될 수 있는 고유한 임의의 문자 숫자식의 또는 기계 판독 가능 포맷의 기타 임의의 식별자가 될 수 있다.

장치는 신뢰할 수 있는 TrE를 가질 수 있다. 장치 내의 TrE는 불변의 RoT(Root of Trust)로부터 보안 스타트업 프로세스에서 구축될 수 있다. TrE는 보안 실행 환경 및 기타 필수적인 보호 성능들을 제공한다. TrE는 관리되는 컴포넌트가 될 수 있으며(예를 들어, 불변이 아닐 수 있으며), 이에 따라 RoT 만이 불변으로 유지된다.

신뢰성있는 컴퓨팅의 관점에서 볼 때, TrE는 어떠한 보안 실행 환경 및 특정의 보호 인터페이스들에 의해 확장되는 TPM 또는 MTM으로부터 구축되는 TCB로서 여겨질 수 있다. TPM 또는 MTM으로부터 구축되는 TCB로서의 TrE는 비 한정적인 예로서 이용된 것이며, 다른 신뢰 실시예들도 적용될 수 있다.

PVM을 위해, TrE는 무조건적으로 신뢰할 수 있는 TCB를 제공한다. 하지만, 전형적인 신뢰성있는 컴퓨팅과는 다르게, TrE에 의해 구성되는 TCB는 PVM에서 불변이 아니다. 이러한 이유로, PVM에서, 장치 내에서 TrE과 그 주변이 구별된다. 양쪽 부분들에 대한 특정의 다른 정보가 인프라구조에 전달되어, 다른 방침들에 따라 이들을 검증 및 관리하는 데에 이용된다. TrE는 PVM 인프라구조의 주요 통신 파트너이며, PVM과 관련된 작업들을 정확하게 수행하는 것으로 추정된다.

H(e)NB 및 TrE는, 스타트업시에 그리고 코어 네트워크 또는 H(e)NB 관리 시스템(HMS)에 접속하기 전에, 장치 무결성 체크를 수행할 수 있다. 이러한 장치 무결성 체크는 하나 이상의 신뢰성있는 기준 값들 및 TrE에 기초할 수 있다. TrE는 모든 신뢰성있는 기준 값들을 항상 안전하게 저장할 것이 요구된다. TrE는 안전하게 스타트업할 것이 요구된다. TrE는 또한, 단일 컴포넌트 또는 다중 컴포넌트의 무결성 체크를 지원할 것이 요구된다.

단일 컴포넌트 무결성 체크에서, TrE는 단일 컴포넌트로서 장치의 신뢰성있는 동작에 필요한 풀 코드(full code)를 로드시킬 것이 요구된다. 이러한 컴포넌트를 시작하기 전에, TrE는, 예를 들어 컴포넌트의 암호화 해쉬 측정을 저장된 신뢰성있는 기준 값과 비교하여 무결성 체크를 실행함으로써, 그 컴포넌트의 무결성을 결정할 것이 요구된다. 만일 단일 컴포넌트가 그 무결성 체크를 통과하면, 그 컴포넌트는 시작될 수 있다. 만일 무결성 체크에 실패하면, 그 컴포넌트는 시작되지 않는다.

다중 컴포넌트 무결성 체크에서는, 장치의 신뢰성있는 동작에 필요한 장치의 풀 코드 베이스(full code base)가 분할(segment)되고, 장치 기능에 기초하여 복수 개의 컴포넌트들로 배열될 수 있다. TrE는 각 컴포넌트를 순차적으로 로드할 것이 요구되며, 그리고 어떠한 개별적인 컴포넌트를 시작하기 전에, TrE는, 예를 들어 컴포넌트의 암호화 해쉬 측정을 저장된 신뢰성있는 기준 값과 비교하여 무결성 체크를 수행함으로써, 그 컴포넌트의 무결성을 결정할 것이 요구된다. 만일 개별적인 컴포넌트가 그 무결성 체크를 통과하면, 그 컴포넌트는 시작될 수 있으며, 그리고 TrE는 다음 컴포넌트의 무결성 체크를 계속할 수 있다. 만일 어떠한 컴포넌트가 무결성 체크에 실패하면, 그 컴포넌트는 시작될 수 없지만, TrE는 다음 컴포넌트에 대한 무결성 체크를 계속할 수 있다.

컴포넌트 무결성 체크들 각각에 대해, TrE는 TRV들에 대한 무결성 보호를 제공하는 보안 메모리(secure memory)로부터 대응하는 신뢰성있는 기준 값을 검색하고, 무결성 측정과 신뢰성있는 기준 값을 비교할 것이 요구된다. 보안 메모리는 TrE의 보호된 저장소를 포함하지만, 오직 이것으로만 제한되지 않는다. 장치의 신뢰성있는 동작에 필요한 모든 컴포넌트들이 검증되면, 그 장치의 무결성이 검증된다.

보안 스타트업과 관련하여, 보안 스타트업은 신뢰의 체인을 구축함으로써 RoT부터 다중 스테이지의 풀 기능 상태(full functional state)로 진행된다. 도 4는 4단계 보안 스타트업(Four-Stage Secure Start-Up) 방법(400)의 예시적인 흐름도를 보여준다. 스테이지 1에서, TrE(410)가 보안 스타트업에서 RoT(405)로부터 구축된다. 로드 또는 시작되는 모든 컴포넌트는 검증되며, 검증을 통과한 컴포넌트들 만이 로드 및 시작될 수 있다. 스테이지 1이 성공적인 경우에만, 보안 스타트업의 보안 스테이지 2를 실행하도록 TrE(410)에 제어가 전달된다.

스테이지 2에서, TrE(410)는 PVM을 실행하는 데에 필요한 추가의 컴포넌트들을 검증, 로드 및 시작한다. 이는, 예를 들어 통신 및 프로토콜 스택과, 그리고 무선 액세스 네트워크(RAN) 통신 모듈들을 포함한다. 로드 및 시작되는 모든 컴포넌트들은 검증되며, 검증을 통과한 컴포넌트들 만이 로드 및 시작된다.

스테이지 2가 성공적일 경우에만, 보안 스타트업의 스테이지 3이 개시된다. 스테이지 3a에서, TrE(410)는 추가의 컴포넌트들을 검증, 로드 및 시작한다. 검증을 통과한 컴포넌트들 만이 로드 및 시작된다. 스테이지 3b에서, TrE는 추가의 컴포넌트들을 측정 및 로드한다.

컴포넌트들의 검증은, (415에 나타낸 바와 같이) 이들의 측정 값들을 얻은 다음, (425에 나타낸 바와 같이) 이러한 측정 값들을 RIM 저장소(420)에 저장된 RIM들과 비교함으로써 수행되는 것으로 추정된다. 언급한 바와 같이, 도 4는 RIM 저장소를 하나의 예 또는 실시예로서 포함한다. 하지만, 여기에서 언급한 바와 같이, RIM들 및 RIM 증명서들은 구조화된 데이터의 하나의 예시적인 형태일 뿐이며, 다른 형태들의 구조화된 데이터가 이용될 수도 있다. 여기에서의 설명은 RIM들 이외의 구조화된 검증 데이터의 변형들 및 실시예들의 이용을 가능하게 한다. 모든 스테이지들에서의 로드 순서(load order)는 국부적으로 이용가능한 리스트에 의해 제어되는 것으로 추정된다. 스테이지 3a 및 3b 내의 컴포넌트들 간의 구별은 국부적으로 이용가능한 방침에 의해 제어되는 것으로 추정된다. 선택적으로, 로딩 및 검증은 한 단계로 통합될 수 있다.

도 4에서, 용어 "TrE"는 PVM에 필요한 최소한의 기능들을 포함하는 엔티티를 설명하는 것으로서 이용되며, 이는 보안 스타트업에 필요한 모든 설비(facility)들, 이를 테면 측정 획득부(measurement taking)(415), RIM 저장소(420) 및 RIM들과 실제 측정들을 비교하는 검증 엔진(425)을 포함한다. 명백한 사항으로서, TrE에 대한 이러한 설명은 단순함을 위해 이용된 것으로서, TrE는 보다 복잡할 수 있으며, 키 발생기 또는 난수 발생기(RNG)와 같은 다른 컴포넌트들을 포함할 수 있다. 나타낸 바와 같이, TrE는 보안 스타트업을 구현하는 데에 필요한 모든 설비들을 포함할 수 있다. RIM들은 TrE의 외부에 저장될 수 있지만, 무결성 및 선택적으로는 기밀성을 위해 TrE에 의해 보호될 수도 있다. 측정 및 검증을 위한 엔진들은 또한 TrE 외부의 컴포넌트들로서 구현될 수도 있다. 이렇게 되면, TrE는 이러한 컴포넌트들의 무결성을 보장하며, 그리고 이러한 컴포넌트들이 변경되지 않는 방식으로 보안 실행 환경을 제공할 수 있다.

스테이지 3에서는, 방침들에 기초하는 보다 미세한 입도가 가능하다. 예를 들어, 컴포넌트들이 검증이 실패했거나 또는 RIM들이 이용가능하지 않은 경우, 이러한 컴포넌트들은 샌드박스 환경(sandbox environment)으로 로드될 수 있다. 스테이지 3a와 스테이지 3b 간의 구별은 MPWG(Mobile Phone Work Group) 기준 아키텍쳐의 보안 스타트업에서의 신뢰성있는 서비스들과 측정된 서비스들 간의 구별과 유사하다.

스테이지 4는 "사용자 공간" 내의 검증되지 않은 컴포넌트들에 대해 부가될 수 있다.

스테이지 2 내의 단일 또는 다수의 컴포넌트들(통신 모듈들 및 기타 유사한 모듈들)의 실패가, 장치들이 통신할 수 없음을 의미하는 것은 아니다. 스테이지들은 특정의 카테고리들에 속하는 컴포넌트들의 부류들로서 이해된다. 스테이지 2의 가장 필수적인 컴포넌트들이 로드되기만 하면, 장치는 자신의 상태 및 실패한 컴포넌트들을 PVM 시스템에 전달할 수 있을 것이다. 이러한 설계는 장치로 하여금, 일부 컴포넌트들이 내부 검증에 실패하더라도 재시작없이 PVM (및 이에 따른 교정 프로세스들)을 실행할 수 있게 한다.

다른 실시예에서는, 폴백 코드 베이스(FBC)를 이용할 수 있는데, 이러한 FBC는 장치로 하여금, 보안 스타트업 동안 손상(compromise)이 검출된 경우 PVM을 수행할 수 있게 한다. 장치는 손상을 감지하자 마자 FBC를 이용하여 리부트한 다음, 미리 정의된 상태로 시작됨으로써, 장치 교정을 가능하게 한다.

보안 스타트업 동안, TrE는 다음의 정보, 즉 1) 로드된 컴포넌트들의 리스트(Clist); 2) 로드된 컴포넌트들의 파라미터들; 3) 컴포넌트들 중 일부 또는 전부와 관련된 측정 값들; 및 4) 이를 테면 플랫폼 상태와 같은 측정들의 일부 또는 정부의 출력을 고유하게 식별(예를 들어, 암호화하여 식별)하는 검증 데이터를 기록하고, 이러한 정보를 탬퍼링(tampering)으로부터 보호한다. PVM에 이용되는 검증 방법에 따라, 이러한 기록들 중 일부 또는 전부는 선택적일 수 있다. 예를 들어, 자율적인 검증(AuV)은 이들 중 어느 것도 이용하지 않는다.

PVM은 다음의 용어를 이용할 수 있다. 용어 "검증"은 보안 스타트업 동안 장치 컴포넌트의 내부 검증에 이용될 수 있는 한편, 용어 "검증"은 외부 엔티티에 의해 장치를 체크하는 전체 프로세스에서 이용된다. 따라서, "내부" 대 "외부" 검증의 소개는 피한다. 일반적 의미의 암호 체크 또는 데이터 매칭에 검증이 적용되는 경우에는, 혼동이 일어나지 않도록 이에 대해 명시적으로 언급한다.

PVM은 적어도 보안 게이트웨이(SeGW), 플랫폼 검증 엔티티(PVE) 및 장치 관리 시스템(DMS)을 이용한다. 장치 내의 TrE는 장치 내부의 검증이 중요한 작업(validation critical task)들을 수행하기 때문에, 일반적으로 TrE는 다른 엔티티들과 통신한다. 이러한 통신에 필요한 디바이스의 다른 컴포넌트들(예를 들어, 네트워크 인터페이스들)이 반드시 TrE의 통합된 부분일 필요는 없지만, TrE는 종단간(end-to-end) 보안을 보장하기 위해 이러한 컴포넌트들의 무결성을 평가할 수 있어야 한다.

임무들의 엄격한 분리는 각 엔티티가 자신의 핵심 작업들로 한정될 것을 요구한다. 예를 들어, SeGW는 (비)신뢰성있는 장치와 MNO의 CN 간에 보안 인터페이스를 구축한다. 이러한 보안 인터페이스는 MNO의 CN에 대한 장벽(barrier), 네트워크 액세스 제어 및 강제 인스턴스(network access control and enforcement instance)의 역할을 한다. 이러한 보안 인터페이스는 또한 이러한 장벽으로서 기능하는 데에 필요한 모든 보안 관련 기능들을 수행하는 바, 이러한 기능들는 인증, 장치와의 통신의 암호화/복호화, 보안 연계 및 세션 설정이 있다. SeGW는 MNO의 CN과 외부 장치와 같은 외부 세계 간의 경계를 구축하는 네트워크 엔티티의 예로서 이용될 수 있다. SeGW를 필요로 하지 않으면서 PVM 방법들을 이용하여 장치 검증을 수행할 수도 있다. 이렇게 하는 것은, 전송 계층 보안(Transport Layer Security, TLS)와 같은 보안 접속을 이용하여 DMS에 장치들을 직접 연결하는 것을 포함할 수 있다.

PVE와 관련하여, 이것은 CN 내의 검증 엔티티의 역할을 하며, 무결성 검증을 수행한다. PVE는 무결성 검증 데이터를 수신하며, 보고되는 값들이 알려진 완전한 값들인 지의 여부를 체크한다. PVE는 CN 내의 다른 엔티티들에게 장치 무결성에 대한 스테이트먼트를 발행한다.

DMS와 관련하여, 이는 소프트웨어 업데이트, 구성 변경, OTA 관리 및 실패 모드 교정을 포함하는 장치 컴포넌트들의 관리를 위한 중심 엔티티의 역할을 한다. 플랫폼 검증에 기초하여 이러한 기능을 시작함에 있어서, DMS는 HMS의 강화된 버전과 유사하다.

상기 엔티티들 이외에, PVM은 또한 RIM 매니저 (RIMman)를 포함한다. 이 RIMman은 검증시에 비교하기 위한 신뢰성있는 기준 데이터 및 TRV들의 관리 및 프로비저닝을 포함하는 다음의 작업들을 수행한다. 이는 또한 증명서들을 관리하는 바, 특히 이질적인(foreign) RIM 증명서들의 인제스천, RIM 증명서들의 검증, (오퍼레이터 특정의) RIM 증명서들의 발생, 및 예를 들어 취소, 시간 제한들 및 신뢰 관계들에 의한 증명서 유효성의 체크를 관리한다. 즉, RIM 매니저는 검증 데이터베이스(V_DB)를 관리할 수 있는 권한이 있는 유일한 엔티티이다. V_DB 및 RIMman은 보호되는 CN 컴포넌트들이다. V_DB에 대한 기록 액세스는 RIMman으로만 제한되며, 이에 따라 PVE는 V_DB에 기록을 할 수 없다. RIMman은 보안과 관련하여 특별히 중요한데, 왜냐하면 이것은 PVM에 필요한 (SHO-CN) 외부 신뢰 관계를 관리하기 때문이다. 여기에서 언급된 바와 같이, RIMman은 하나의 실시예이며, 기준값들 및 (계층적으로) 구조화된 데이터의 증명된 기준값들에 대한 매니저들의 다른 실시예들을 포괄하도록 확장될 수 있다.

PVM은 또한 장치 구성들의 관리 및 프로비저닝을 수행하는 구성 방침 매니저(Configuration Policy manager, CPman)를 포함한다. 이는 또한 방침들을 관리하는 바, 특히 예를 들어 신뢰성있는 제 3 당사자(TTP)로부터의 이질적인 구성들 및 방침들의 인제스천, 및 (오퍼레이터 특정의) 타겟 장치 구성들 및 방침들의 발생을 관리한다. 즉, CPman은 구성 방침 데이터베이스(C_DB)를 관리하는 권한이 있는 유일한 엔티티이다. CPman은 보안과 관련하여 특별히 중요한데, 왜냐하면 이것은 PVM에 필요한 (SHO-CN) 외부 신뢰 관계를 관리하기 때문이다.

도 5a와 5b는 PVM에 대한 최소 세트의 엔티티들, 이들의 관계들 및 인터페이스의 예들을 보여준다. AAA(Authentication, Authorization & Accounting) 서버 및 무선 송/수신 유닛(WTRU)과 같은 부가적인 엔티티들 및 이들의 인터페이스들이 나타나있다.

도 5a의 PVM 아키텍쳐 또는 시스템(500)는 TrE(510)를 갖는 장치(505)를 포함한다. WTRU(512)는 I-ue 인터페이스(514)를 통해 장치(505)와 통신할 수 있다. 장치(505)는 I-h 인터페이스(515)를 통해 SeGW(520)와 통신한다. 일반적으로, 장치(505)와 SeGW(520) 간의 인터페이스 I-h(515)는 보호되지 않으며, 확실성(authenticity), 무결성 및 선택적으로 기밀성을 위해 이 채널을 안전하게 하기 위해 특별한 조치들이 적용될 수 있다. I-h 인터페이스(515)는 장치(505)와 SeGW(520) 및 이에 따라 CN 과의 사이에 링크를 설정하는 데에 이용될 수 있다. 예를 들어, SeGW(520)는 인터페이스 I-aaa(575)를 통해 AAA 서버와 통신할 수 있다. 오퍼레이터는 인터페이스들의 보안을 보장하기 위해 적절한 조치들을 확립할 수 있다.

I-pve 인터페이스(522)는 검증 동안 SeGW(520)에 의해 PVE(524)와 컨택하는 데에 이용될 수 있다. PVE(524)는 I-pve 인터페이스(522)를 이용하여, SeGW(520)에 검증 결과를 시그널링할 수 있다. I-dms 인터페이스(530)는 DMS(535)와 SeGW(520) 간에 장치 구성 관련 통신에 이용될 수 있다. I-pd 인터페이스(532)는 PVE(524)에 의해 DMS(535)와 통신하는 데에 이용될 수 있으며, 반대로 DMS(535)에 의해 PVE(524)와 통신하는 데에 이용될 수도 있다. 이러한 I-pd 인터페이스(532)는 장치 관리 절차들 동안, 이를 테면 장치 소프트웨어 업데이트들 및 구성 변경들 동안 이용될 수 있다.

인터페이스들 I-v(526) 및 I-d(538)는, PVE(524)에 의해 V_DB(540)로부터 RIM들을 판독하고, DMS(535)에 의해 C_DB(550)로부터 허가된 구성들을 판독하는 데에 각각 이용될 수 있다. 인터페이스들 I-r(528) 및 I-c(534)는, 이를 테면 V_DB(540)에서 RIM들이 누락(missing)되는 경우, PVE(524)에 의해 RIMman(560)과 통신하고, DMS(535)에 의해 CPman(570)과 통신하는 데에 각각 이용될 수 있다. RIMman(560) 및 CPman(570)은 각각 인터페이스 I-rdb(562) 및 I-cdb(572)를 이용하여, 검증 데이터베이스 V_DB(540)와 구성 방침 데이터베이스 C_DB(550) 각각을 판독, 기록 및 관리할 수 있다.

도 5b는 장치(505)가 DMS(535)에 직접 연결될 수 있는 PVM(582)을 도시한다. 예를 들어, 폴백 모드의 경우, 장치(505)는 SeGW와 보안 프로토콜을 수행할 수 없다. 이 경우, DMS(535)는 인터페이스 I-dms_d(584)를 통해 장치(505)에 대한 첫 번째 컨택 포인트의 역할을 하며, 그리고 인터페이스 I-pve(586) 및 I-pd(588)를 통해 PVE(524)와 통신하여, 검증을 수행하거나, 또는 적어도 보안 스타트업 동안 어떤 컴포넌트들이 실패했는 지를 알 수 있다. DMS(535)는 이러한 정보에 입각하여 교정을 행한다.

일반적으로, TrE(510)를 포함하는 장치(505), SeGW(520), PVE(524) 및 DMS(535)와 같은 각각의 컴포넌트들은 모두 액티브 엔티티들 간에 PVM에 가장 효과적인 타입으로 임무들을 분리하는 방식을 이용하도록 구성되는 것이 바람직하다. 하기에서 보다 상세히 설명되는 바와 같이, 이것은 PVM 토큰의 이용을 통해 다양한 엔티티들 간에 특정의 정보를 전달하도록 촉진된다.

여기에서 설명되는 바와 같이, PVM는 모든 버전의 검증을 이용할 수 있다. 여기에서는, PVM과 함께 작동하는 반 자율적인 검증(SAV)의 실시예에 대해 설명한다. 일 실시예에서, 장치는 TrE 및 RoT를 포함하며, 보안 스타트업이 가능하다. 이 장치는 RIM들을 구비하는 바, 이러한 RIM들은 TrE 컴포넌트들 및 TrE 외부의 컴포넌트들의 로컬 검증을 가능하게 한다. 이러한 실시예에서, 이 장치는 H(e)NB가 될 수 있다. 여기에서 주목하는 바와 같이, RIM들은 구조화된 데이터의 하나의 형태 및 예이며, 여기에서는 비한정적인 예로서 이용된다.

본 장치는 3개의 스테이지들로 보안 스타트업을 수행함으로써, 로드될 컴포넌트의 로컬 검증이 성공적인 경우 및 성공적인 경우에만, 각 컴포넌트가 로드되도록 보장한다. 스테이지 1에서, TrE는 RoT에 의존하는 보안 스타트업을 통해 로드된다. 스테이지 2에서는, SeGW와 기본적인 통신을 수행할 것이 요구되는 TrE 외부의 모든 컴포넌트들이 로드된다. 스테이지 3에서는, 장치의 나머지 모든 컴포넌트들이 로드된다.

이후, 장치는 SeGW와 함께 네트워크 인증을 시작할 수 있다. 인증 동안, 다음의 데이터 중 하나 이상의 데이터가 전송될 수 있다. 즉, Dev_ID; 장치에 대한 보안 방침들; 보안 셋업 동안 TrE에 의해 무결성이 체크되는 장치 모듈들에 대한 정보; 하드웨어/소프트웨서 빌드 버전 넘버들; 장치의 제조업자; 모델 및 버전 넘버; 장치 및 TrE에 대한 증명 정보; 및 그리고 TrE 성능들 및 특성들 중에서 하나 이상의 데이터가 전송될 수 있다.

(SeGW를 통해) PVE에 이러한 데이터를 전송하는 데에는 다른 옵션들이 적용될 수 있다. 이러한 데이터는 IKEv2(Internet Key Exchange Version 2) 인증 프로토콜의 통지 필드(Notify field)로 전송된 다음, SeGW에 의해 PVE에 전송된다. 그러면, PVE는 수신된 정보를 체크한다. PVE는 Dev_ID가 블랙 리스트에 리스트되어 있는 지를 체크한 다음, 만일 블랙 리스트에 리스트되어 있다면, 액세스가 거부된다. PVE는 보안 방침들이 그 장치에 대해 요구되는 방침들과 미스매치되는 지를 체크한다. 만일 보안 방침들이 미스 매치된다면, 교정 단계들이 실시될 수 있다. PVE는 식별되지 않은/원치 않는 모듈들 및 컴포넌트들이 로드되었는 지를 체크한다.

상기 각각의 체크들에서, 장치의 TS의 검증이 실패했음을 나타내는 긍정적(positive)인 대답의 경우, PVE는 그 장치에 대한 네트워크 액세스를 거부하거나, 또는 그렇지 않으면 제한(예를 들어, 제한된 이용 또는 자원들로 격리)할 수 있다. PVE는 장치의 유효성 및 신뢰성 결정에 대한 메시지를 SeGW에 전송한다. SeGW는 이 메시지에 따라 작동한다.

제 1 변형에서, 데이터는 신뢰성있는 제 3 당사자(TTP)에 저장되며, 장치는 TTP에 포인터를 전송하며, PVE는 이 TTP로부터 원하는 정보를 검색할 수 있다. 이러한 포인터는 IKEv2 통지 페이로드(Notify payload) 내에서 전송될 수 있다.

제 2 변형에서, 모든 데이터가 정적(static)이기만 하면, 이는 인증 동안 (가능하게는 강화된) 장치 증명서에 포함될 수 있다. 측정들 및 이에 따라 보안 스타트업에서 이용되는 RIM들에 대한 변경을 의미하는 컴포넌트들에 대한 임의의 업데이트는 새로운 장치 증명서를 요구할 것이다.

여기에서는, PVM과 작동하는 F-SAV(full semi-autonomous validation) 또는 원격 검증의 일 실시예에 대해 설명한다. 스테이지 1에서, TrE는 보안 스타트업시 RoT로부터 구축될 수 있다. TrE의 모든 컴포넌트들은 무결성이 검증되며, 성공적으로 검증될 때에 로드된다. 스테이지 2에서, TrE는 장치의 나머지의 미리 결정된 부분의 무결성을 검증할 수 있으며, 이들을 로드할 수 있다. 무결성 체크되는 코드는, 예를 들어 기본(basic) OS, SeGW에 대한 기본 통신, 및 실행가능한 PVM 보고 메시지들(performing PVM reporting messages)의 포맷을 정하는 코드로 구성될 수 있다. 측정값들은 TrE 내의 보안 저장소에 저장될 수 있다.

만일 스테이지 1 또는 스테이지 2의 체크가 실패하면, TrE는 인증이 진행되는 것을 막을 수 있다. 만일 스테이지 1 및 스테이지 2가 성공적이면, 스테이지 3으로 진행될 수 있다. 예를 들어 무선 액세스 코드를 포함하는 코드의 나머지 장치 모듈들의 무결성이 체크될 수 있지만, 로드는 되지 않을 수 있다. 검증 데이터가 준비되어, 적절한 통신 프로토콜로 SeGW에 전송될 수 있다. 이러한 데이터는, 예를 들어 TrE 저장 키(stored key)에 의해 서명됨으로써, 데이터의 확실성 및 무결성을 제공할 수 있다. 이러한 데이터는 무결성 체크에서 실패했던 스테이지 3 모듈들의 리스트를 포함할 수 있다.

데이터는 IKEv2 AUTH_REQ 메시지의 통지 페이로드를 이용하여 전송될 수 있다. 이러한 통지 페이로드 내의 데이터는, IKE 보안 연계에 의해 제공되는 전체적인 메시지 보호에 부가하여, 이 데이터의 확실성 및 무결성을 제공하기 위해 TrE의 서명 키에 의해 서명될 수 있다. 통지 페이로드는 무결성 체크에서 실패한 스테이지 3 모듈들의 리스트를 포함할 수 있다. 검증 데이터는 적절한 IKEv2 메시지의 임의의 다른 적절한 페이로드 또는 필드, 또는 IKEv2 프로토콜 이외의 적절한 프로토콜, 이를 테면 TLS, TR069, OMA-DM, HTTP, HTTPS, 또는 다른 유사한 프로토콜들의 임의의 다른 적절한 페이로드 또는 필드를 이용하여 전송될 수 있다.

SeGW는 결정을 위해 PVE에 데이터를 전송할 수 있다. 인증 프로세스가 진행될 수 있지만, PVE가 검증 메시지를 검사하고, 검증 테스트들에 실패한 것으로서 보고된 임의의 모듈들에 대한 네트워크 기반의 방침 결정을 하거나 또는 이러한 결정을 얻을 때 까지, 네트워크 접속을 허가하는 결정은 지연될 수 있다.

제 3 변형에서는, 코드를 측정하고 실행하는 대신, 이 코드를 로드하지 않으면서, 이러한 코드의 측정 및 무결성 검증이 로드될 수 있다. SeGW는 수신된 리스트를 검증할 수 있는 검증 메시지를 PVE에 전송할 수 있다. 장치가 PVE로부터 성공적인 검증 결과를 수신하면, 나머지 스테이지 3 모듈들이 로드될 수 있다.

무결성을 측정하고, 코드가 확장될 수 있는 지를 PVE가 결정하기를 대기하는 프로세스는, 일단 코드가 측정되면 이 코드는 변경되지 않을 수 있고, 이 코드는 PVE가 그렇게 하도록 허가하는 경우 실행될 수 있다고 규정하는 것을 포함한다. 따라서, 스테이지 3에서의 모든 컴포넌트 코드에 대한 보안 저장소가 포함될 수 있다. 부가적으로, 실행 환경은 허가된 실행(authorized execution)을 지원할 수 있는 바, 이러한 허가된 실행은 코드가 먼저 로드된 다음, 이후 허가된 다음에 실행될 수 있게 한다. 많은 양의 코드가 로드될 수 있으며, 이에 따라 보안 저장소 및 실행 환경은 충분한 사이즈를 가져야 한다.

F-SAV는 CN에게 실제로 무엇이 "로컬 무결성 체크들"을 받았는 지를 인식할 수 있는 유연성을 제공할 수 있다. 장치는 스테이지 1 및 2 코드의 통과/실패의 표시 및 선택적으로, 만일 있는 경우, 실패한 모듈들의 리스트를 전송할 수 있다. F-SAV는 보다 미세한 입도 및 보다 많은 가시성(visibility)을 장치 보안 특성 및 검증 측정을 제공할 수 있고, 자율적인 검증에 필적하는 로컬 장치 자원들을 허용하고, 손상된 장치들을 보다 빠르고 쉽게 검출할 수 있게 하고, 손상된 장치들에 대해 네트워크에 의해 개시되는 교정을 지원하며, 그리고 장치 보안 관리에 있어서 오퍼레이터들에게 유연성을 제공할 수 있다.

TrE는 또한 새로움을 보장하기 위해 메시지 상에 타임 스탬프를 넣을 수 있다. 타임 스탬핑(time-stamping)에 대한 대안은, 네트워크에 대해, 네트워크 액세스를 위한 프로토콜이 시작된 후 상기 언급한 메시지와 결합하기 위해 TrE에 의해 이용될 논스(nonce)를 공급하는 것이 될 수 있다. 이것은 또한 장치 인증을 검증에 바인딩시키는 특징이 될 수 있다.

인증 실패의 교정은, 예를 들어 스테이지 1 또는 스테이지 2 무결성 체크들의 최초 실패 이후 폴백 모드를 활성화함으로써, 장치가 SeGW에 어태치하여, 그 SeGW에게 실패를 알릴 수 있는 충분한 기능을 가능하게 한다. 이에 의해, 진단(diagnosis) 시에 장치 소프트웨어가 업데이트될 수 있게 하는 OAM(operation and maintenance) 절차들이 개시될 수 있다. 폴백 코드는 TrE의 감독하에서 안전한 방식으로 코드의 완전한 재건(rebuild)을 가능하게 하는 충분한 기능을 가질 것이 요구된다.

제 1 변형에서, 측정 메시지 데이터는 (장치 증명서와 함께) IKEv2 AUTH_Request의 통지 필드 내에서 전송될 수 있다. 제 2 변형에서, 측정 메시지 데이터는 IKEv2 기반의 장치 인증을 시작하기 전에 적절한 보안 프로토콜에 의해 전송될 수 있다. 제 3 변형에서, 만일 스테이지 1 또는 2 체크들의 임의의 부분이 실패하고, 실패한 모듈들이 기본적인 장치 기능에 중요하지 않은 보조적인 기능들이라면, 장치는 이러한 모듈들을 로드하지 않으면서 진행/어태치하도록 허용될 수 있다. 한편, 일부 OAM 절차들은 장치 소프트웨어를 업데이트하도록 스케쥴될 수 있다.

여기에서는, 모든 관련 엔티티들의 기능들에 대한 하이 레벨(high-level) 개요를 제공한다. H(e)NB 장치들의 시스템 아키텍쳐가 설명되는 바, 여기에서는 검증 및 원격 관리가 중요한 역할을 할 수 있다. 설명되는 방법들은 H(e)NB 네트워크 아키텍쳐 내의 엔티티들에게 직접 적용될 수 있다. 임무들의 분리에 따른 역할의 정의와 함께, 보다 일반적인 접근을 이용함으로써, 플랫폼 검증 및 관리를 위한 제시되는 솔루션은 다른 네트워크 연결 장치들에 용이하게 적용 또는 확장될 수 있다. M2M과 같은 다른 시나리오들로의 전환은, 엔티티들이 자신들의 기능들에 따라 맵핑되는 경우, 유사한 방식으로 구현될 수 있다.

여기에서 설명되는 PVM 기능들의 실시예들에서는, SAV가 이용된다. 이 SAV는 악의적인 장치들로부터 CN이 완전히 보호될 수 있게 한다. SAV 동안, SeGW에 의해 격리된 네트워크가 효과적으로 설정될 수 있다. 장치로부터 PVE 및 DMS에게 어떠한 직접적인 위협도 가해지지 않는데, 왜냐하면 이들은 오로지 SeGW, 즉 SeGW에 의해 설정되는 안전한 접속들을 통해, 자신들의 작업들에 한정된 데이터 만을 수신하기 때문이다. PVM을 수행함에 있어서의 검증 프로세스는 장치들과 CN 내의 다른 엔티티들 간의 직접적인 통신을 요구하지 않는다. SAV를 이용하여 성공적으로 검증된 이후에만, CN과의 접속이 허용된다. 이에 의해, 검증된 보안 상태의 장치들 만이 CN 내의 엔티티들과 통신할 수 있게 된다.

도 6a, 6b 및 6c는 PVM 인프라구조를 이용하는 SAV 검증 방법의 일예의 다이어그램이다. PVM 인프라구조는, TrE(605), SeGW(607), PVE(609), DMS(611), V_DB(613) 및 C_DB(615)를 비롯하여, 여기에서 설명되는 엔티티들을 포함한다. 상호 인증(620)에 이어서, TrE(605)는 다음의 데이터 중 일부 또는 전부를 수집한다: Dev_ID, 제조업자, 장치 성능들(지원되는 데이터 속도들, 전송 전력 레벨들, 시그널링 특징들 및 기타 성능들과 같은 통신 성능들, RoT를 포함하는 TrE 성능들 및 특징들을 포함하지만, 오직 이것들로만 한정되지 않는다)과 같은 장치 정보; ID, 증명 정보, 제조업자, 빌드 버전(build version), 모델, 메이크(make) 및 일련 번호를 포함하는 TrE_정보; 플랫폼 구성 레지스터(PCR) 값들을 포함하는 검증 데이터; PCR 값들에 대한 서명과 같은 검증 바인딩; 컴포넌트들에 대한 파라미터들을 포함할 수 있는, 컴포넌트 Clist에 대한 컴포넌트 표시자들(component indicators, CInd)의 배열된 리스트; 및 (신뢰되는 또는 신뢰되지 않는) 타임 스탬프(622). TrE(605)로부터 SeGW(607)로의 검증 메시지/데이터는 상기 데이터(624)를 포함할 수 있다.

SeGW(607)는 수신한 타임 스탬프들을 현지 시간(local time)과 체크/비교하여, 변화를 검출한다(626). 만일 보고된 타임 스탬프가 현지 시간과 일치하지 않으면, SeGW는 보고된 타임 스탬프의 특성들에 따라 동작한다. 만일 장치의 타임 스탬프가 신뢰성있는 타임 스탬프이고, 변화를 나타낸다면, SeGW(607)는 TrE 및 그것의 신뢰성있는 타임 소스(time source)에 대한 재검증을 트리거해야 한다. 신뢰성이 없는 타임 스탬프의 경우, SeGW(607)는 자신의 신뢰성있는 타임 스탬프를 메시지에 부가한다. 만일 장치가 신뢰성있는 타임 스탬프를 제공할 수 없다면, SeGW(607)가 리플레이 공격(replay attack)에 대한 보호로서 신뢰성있는 타임 스탬프를 부가할 수 있다.

이러한 메시지를 받으면, SeGW(607)는 검증 바인딩이 존재하는 지를 체크할 수 있다(628). 이는 검증 데이터의 확실성을 보장한다. 그런 다음, SeGW(607)는 PVM 토큰(T_PVM)을 생성하고(630), T_PVM을 전송하기 전에 이 T_PVM에 타임 스탬프를 적용함으로써, 새로움을 보장하고 비동기적인 메시지 흐름을 막는다(632).

SeGW(607)는 이러한 T_PVM을 PVE(609)에 전송하며(634), PVE(609)는 TrE_info를 이용하여 V_DB(613)에게 질문한다(636). 만일 신뢰할 수 없는 결정이 PVE(609)에 반송되면(638), PVE는 T_PVM에 타임 스탬프를 적용한 다음(640), 이를 SeGW(607)에 전송한다(642). 그러면, SeGW(607)는 장치 인증을 중지하고, 그 장치의 네트워크 어태치먼트를 막으며, TrE(605)에게 경고한다(644).

만일 신뢰할 수 있는 결정이 PVE(609)에 반송되면(646), PVE는 Dev_ID를 이용하여 C_DB에게 질문하며(648), C_DB는 PVE(609)에 구성 방침을 반송한다(650). PVE(609)는 이러한 구성 방침을 평가한다(652).

PVE(609)가 구성이 신뢰성이 없다고 결정하면(654), PVE(609)는 T_PVM을 변경하고, 타임 스탬프를 적용한다(656). 그런 다음, PVE(609)는 이러한 T_PVM을 SeGW(607)에 전송하며(658), SeGW(607)는 장치 인증을 중지하고, 그 장치의 네트워크 어태치먼트를 막으며, TrE(605)에게 경고한다(660).

만일 PVE(609)가 구성이 신뢰성이 있다고 결정하고 그 구성을 허용한다면(662), PVE(609)는 Clist 또는 V_DB(613)로부터의 C_List 내의 모든 엔티티들에 대해 RIM들을 검색한다(664). PVE(609)는 RIM들로부터 정확한 검증 데이터를 재계산하고(666), 계산된 검증 데이터를 보고된 검증 데이터와 비교한다(668). 그런 다음, PVE(609)는 T_PVM을 변경하고 타임 스탬프를 적용한다(670). 이후, PVE(609)는 T_PVM을 SeGW(607)에 전송한다(672). SeGW(607)은 PVE 검증 결과를 위해 T_PVM을 검사한다(또는 T_PVM으로부터 이끌어낸다)(674). SeGW(607)은 TrE(605)에 장치 인증의 거부 또는 허가를 전송한다(676). 만약 PVE 검증 결과가 부정적(negative)이면, TrE(605)가 리부트를 수행하고, 재검증을 한다(690).

선택적으로, PVE(609)는 계산된 검증 데이터와 보고된 검증 데이터를 비교한 후(668), 이 PVE(609)는 실패한 컴포넌트들의 리스트를 DMS(611)에 전송할 수 있다(678). DMS(611)는 업데이트가 적용될 수 있는 지를 결정하고(680), 만일 적용할 수 있다면, OTA 업데이트를 준비한다(682). 또한, DMS(611)는 업데이트를 위한 RIM들이 확실하게 V_DB(613) 내에 존재하게 한다(684). DMS(611)는 재검증 표시와 함께 T_PVM을 SeGW(607)에 전송하고(686), 재검증 트리거를 TrE(605)에 전송한다(688). TrE(605)는 리부트를 수행하고, 재검증을 한다(690).

여기에서는, 도 6a, 6b 및 6c의 처리와 관련된 상세 사항들이 설명된다. 플랫폼 검증을 실행하기 위해, TrE는 다음의 데이터를 수집하고, 이들을 검증 메시지에 포함시킨 다음, SeGW에 전송한다: Dev_ID, 제조업자, RoT를 포함하는 TrE 성능들 및 특징들과 같은 장치 정보; ID, 증명 정보, 제조업자, 빌드 버전, 및 선택적으로 모델, 메이크 및 일련 번호를 포함하는 TrE_information; 플랫폼 구성 레지스터(PCR) 값들, 또는 단순하게는 로컬 검증에 실패한 컴포넌트들의 리스트, 또는 로컬 검증에 실패한 컴포넌트들에 의해 영향을 받는 기능들의 리스트를 포함하는 검증 데이터; PCR 값들에 대한 서명, 실패한 컴포넌트들 또는 영향을 받는 기능들의 리스트들과 같은 검증 바인딩; 컴포넌트들에 대한 파라미터들을 포함할 수 있는, 컴포넌트 Clist에 대한 컴포넌트 표시자들(CInd)의 배열된 리스트; 및 (신뢰되는 또는 신뢰되지 않는) 타임 스탬프들.

컴포넌트들에 대한 표시자들 및 이들의 파라미터들의 배열된 리스트는 다음의 데이터 필드들, 즉 인덱스, 컴포넌트_표시자(CInd), 컴포넌트_파라미터들과 같은 엔트리들을 포함한다. CInd는 컴포넌트에 대한 기준을 제공하고, URN 포맷(예를 들어 URN://vendor.path.to/component/certificate)을 가질 수 있다. 컴포넌트들의 리스트는, 예를 들어 RIM 증명서(RIMc)들을 지시함으로써, 검증을 위해 RIM들을 식별하도록 기능한다.

장치의 경우, 검증 메시지는 ID, 증명 정보, 제조업자, 모델, 버전, 메이크, 일련 번호, RoT를 포함하는 TrE 성능들 및 특성들, 스테이지(1,2,3)에서 무결성 체크된 장치들 및 모듈들의 보안 방침들, 하드웨어(HW) 빌드 버전 넘버와 같은 장치 정보를 부가적으로 포함할 수 있으며, 소프트웨어(SW) 버전 넘버 및 무결성 측정 데이터를 포함할 수 있다.

TrE 특정의 정보가 요구되는 경우, 이것은 TrE가 장치 내에서 어떻게 구현될 수 있는 지의 설명이 될 수 있다. 또한, 예를 들어 TrE가 증명된 IP 컴포넌트인 경우, TrE 정보는 장치에 대한 정보 및 신뢰 환경에 대한 개별적인 정보를 제공할 수 있다. 이에 따라, 장치에 대한 증명 허가는 유용한 정보가 될 수 있다.

비록 검증을 위해 RIM들을 이용하는 것이 SAV에 대해 바람직한 방법이기는 하지만, 실제로 이것은 선택적이다. 여기에서, 검증을 위해 RIM들을 이용하는 것은 기본적인 케이스로 이용된 것이며, 다른 옵션들이 이를 벗어나 달라질 수 있다. 이를 테면, RIM들로부터 검증 데이터를 재계산하지 않는 검증들이 있으며, 심지어는 RIM들 없이도 PVM을 완전히 수행할 수도 있다.

검증 메시지가, 예를 들어 보안 채널에 의해 인증에 바인딩된다면, 검증 바인딩은 선택적이다.

SeGW는 수신한 타임 스탬프를 현지 시간과 체크/비교하여, 변화를 검출한다. 만일 보고된 타임 스탬프가 현지 시간과 일치하지 않으면, SeGW는 보고된 타임 스탬프의 특성들에 따라 동작한다. 만일 장치의 타임 스탬프가 신뢰성있는 타임 스탬프이고, 변화를 나타낸다면, SeGW는 TrE 및 그것의 신뢰성있는 타임 소스의 재검증을 트리거해야 한다. 신뢰성이 없는 타임 스탬프의 경우, SeGW는 자신의 신뢰성있는 타임 스탬프를 메시지에 부가한다. 만일 장치가 신뢰성있는 타임 스탬프를 제공할 수 없다면, SeGW가 리플레이 공격에 대한 보호로서 신뢰성있는 타임 스탬프를 부가할 수 있다.

장치 및 TrE_info는 선택적일 수 있다. Dev_ID는 장치 및 TrE_info에 대한 기준을 제공할 수 있다. 반드시 모든 MNO들이 네트워크에 어태치될 수 있는 장치들 및 그에 따른 모든 TrE들, 및 그에 따른 모든 TrE_info 데이터를 알고 있는 것은 아니기 때문에, 이러한 맵핑은 데이터베이스에 의해 제공될 수 있으며, MNO들은 임의의 소정의 Dev_ID에 대한 TrE_info를 얻기 위해 이러한 데이터베이스에 질문할 수 있다. TrE_info는 TrE_증명서 내에 있을 수 있다. TrE_증명서는 TrE 또는 TTP의 벤더에 의해 서명되어야 한다.

제 1 변형에서, 검증 메시지 내에 어떠한 검증 데이터/바인딩도 포함되지 않는 다면, 실행가능한 PVM의 단순한 버전이 구현될 수 있다. 이는, TrE의 특성들이 검증되어야 하는 경우에만 이루어질 수 있다. 방침 결정들은 TrE_info 및 컴포넌트들의 리스트에만 의존해야 한다.

SeGW와 장치 간의 상호 인증은 이러한 변형에 대한 필수 조건이다. 그렇지 않고, 예를 들어 장치가 오퍼레이터들을 변경한다면, 신뢰 문제들이 발생할 것이다. 이를 테면, 원격 관리 절차들 동안, 위조된(faked) SeGW/MNO로부터 위조된 RIM들을 사전에 수신할 수 있다.

컴포넌트들에 대한 표시자들로서 URN들을 이용하는 것이 유익한데, 왜냐하면 RIM 또는 RIM 증명서들이 페치될 수 있는 위치 및 컴포넌트의 이러한 고유한 식별을 동시에 허용하기 때문이다.

장치 검증 동안, 장치는 SeGW에 검증 메시지를 전송한다. 이러한 메시지를 수신하면, SeGW는, 만일 있는 경우, 검증 바인딩을 체크한다. 이 단계는 검증 데이터의 확실성을 보장한다. 그런 다음, SeGW는 PVM 토큰(T-PVM)을 생성한다. 이 토큰 T_PVM은 롤링 토큰(rolling token)으로서 이용될 수 있으며, 통신 동안 엔티티들 간에 전달될 수 있다. 모든 엔티티는 토큰을 전송하기 전에 그 토큰 상에 타임 스탬프를 넣음으로써, 새로움을 보장하고, 비동기적인 메시지 흐름들을 막는다. 토큰 상의 타임 스탬프들은 토큰의 상태를 따라가는 방법을 제공하는 데에 이용된다. 이러한 토큰은 CN 내에서 엔티티들 간에 (심지어 몇 번의 라운드(round) 동안) 이동할 수 있으며, 이에 따라 엔티티들에 의해 추적될 수 있다.

선택적으로, 엔티티 ID가 타임 스탬프된 데이터의 체인에 포함되어야 한다.

T_PVM은 Dev_ID를 포함할 수 있다. 만일 최초의 타임 스탬프가 존재하지 않거나, 또는 신뢰되지 않는 다면, T_PVM은 SeGW에 의해 발행된 새로운 타임 스탬프를 또한 포함할 수 있다. 그렇지 않으면, T_PVM은 검증 메시지로부터의 최초의 타임 스탬프를 포함할 수 있다.

타임 스탬프들은 리플레이 공격들을 보호하는 데에 이용될 수 있다. 이들은 논스들 또는 단조 증가 카운터들(monotonically increaing counters)과 결합되거나, 또는 심지어 이들에 의해 대체될 수 있다. 타임 스탬프들은 또한 검증 데이터의 새로움을 평가하는 데에 이용될 수 있다. 이러한 양 목적을 결합하는 것이 유익하며, 이는 타임 스탬프들에 의해 제공될 수 있다.

SeGW, PVE 및 DMS 간의 모든 통신은 무결성, 확실성 및 기밀성과 관련하여 안전한 것으로 추정된다. 따라서, 임의의 내부 메시지에 대해 이러한 보안 특성들을 확립하기 위한 어떠한 조치들도 강제적이지 않다. 그럼에도 불구하고, 요구되는 경우, 전체 메시지 또는 그 일부분에 적절한 조치들을 적용하는 것이 가능하다. 이러한 조치들은 암호화된 통신 채널들, 상호 인증, 및 메시지들 상의 서명을 포함할 수 있다. SeGW는 모든 액티브한 T_PVM을 포함하는 토큰 데이터베이스(T_DB)를 유지한다.

제 1 변형에서, DMS에 의한 이후의 장치 관리를 위해, T_PVM은, 이를 테면 TLS 증명서와 같은, DMS와 TrE 간에 보안 채널을 구축하기 위한 통신 시크릿을 포함할 수 있다.

SeGW는 검증 메시지로부터 다음의 데이터, 즉 검증 데이터, TrE_info 및 Clist를 추출한다. 토큰 T_PVM과 함께 이러한 데이터를 전송하기 전에, SeGW는 T_PVM 상에 타임 스탬프를 넣은 다음, 이를 PVE에 전송한다. SeGW는 기형의(mal-formed) 데이터 공격들로부터의 위협을 완화하기 위해, 검증 메시지들 및 그 일부의 포맷을 체크할 수 있다. 그렇지 않으면, 공격자는 손상된 TrE의 검증 메시지 내의 데이터를 변경하고자 시도할 것이며, 이에 따라 PVE에서의 이러한 데이터의 단순 검사(pure inspection)는 시스템 에러 또는 실패를 야기할 것이다.

Dev_ID와 해당 H(e)NB의 아이덴티티인 H(e)NB_ID를 분리하는 것이 유용할 수 있다. 비록 양쪽 간의 연계가 1:1이라고 할지라도, 이러한 분리는 임무들의 분리(SeGW는 TrE들을 알고, PVE는 H(e)NB들을 안다) 및 가능하게는 어드레싱/관리의 관점에서 의미가 있을 수 있다. 이 경우, PVE가 수신된 H(e)NB_ID를 이용하여 데이터베이스 HNB_DB로부터 Dev_ID를 페치하는 중간 단계가 있을 것이다.

PVE는 장치의 유효성을 결정하는 엔티티이다. 즉, 방침 시스템들의 언어로, 이것은 방침 결정 포인트(policy decision point, PDP)이다. 엄격한 임무 분리 시도하에서, 이는 PVM 시스템 내의 유일한 PDP이다. 이것은, PEP(Policy Enforcement Point)의 역할을 하는 것 같이, 방침들을 시행하기 위해 SeGW 및 DMS에 의존한다. PVM은, 자신의 일반적인 기술에 있어서, 어떻게 방침들이 발생되는지, 그리고 어디에서 이들이 저장/관리되는지(이를 테면, PVE가 어디로부터 이러한 방침들을 얻는지)의 질문에 대해 불가지론(agnotic)으로 유지된다. 하기 설명되는 보다 상세한 변형들 및 부수적인 방법들(특히, 파라미터 검증(parametric validation) 및 최소 검증) 중 일부에서는, 방침 조건들 및 액션들의 일부 예들이 주어진다. 일반적으로, 검증 방침에 대한 결정들은, 단일 컴포넌트의 유효성 뿐 아니라, Clist에 포함된 다른 데이터에도 기초할 수 있다. 특히, 허용된 파라미터(범위) 및 로드 순서(Clist가 배열된다)가 평가될 수 있다.

PVE에 의해 실행되는 검증 프로세스에서 일어날 수 있는 실패 조건(failure condition)의 몇 개의 기본적인 부류들이 있다. 예를 들어, 실패 조건 F1은 "TrE 무효(invalid)" 시나리오를 나타낸다. 자신의 인증된 Dev_ID 및 전달된 TrE_info에 의해, PVE는 장치 및/또는 그 TRE를 신뢰성이 없는 것으로서 식별한다.

다른 예는, "검증 데이터 실패(Verification data failure)"에 대한 3개의 시나리오를 나타내는 실패 조건 F2가 있다. 시나리오 F2a는 무결성 측정/검증 데이터 미스매치를 나타낸다. 이는 장치의 보안 스타트업 프로세스의 실패 및/또는, 장치에 대한 가짜 및/또는 만료된 RIM들 및/또는 RIM 증명서의 존재를 나타내는 바, 이에 의해 무효한 컴포넌트가 시작된다. 시나리오 F2b는 RIM 누락, 즉 컴포넌트에 대한 RIM이 누락되었으며, 다른 곳에서 페치될 것이 요구됨을 나타낸다. 시나리오 F2c는 만료된 RIM 증명서를 나타낸다.

실패 조건 F3은 "Clist 방침 실패"에 대한 2개의 시나리오들을 나타낸다. 시나리오 F3a에 있어서, 단일 컴포넌트들이 유효하지만, 구성은, 이를 테면 로드 순서, 원치않는 컴포넌트들 또는 파라미터들에 대한 방침에 실패한다. 시나리오 F3b는 구성이 알려지지 않았음을 나타내며, 이에 따라 Clist에 대한 '알려진 완전 값'이 이용가능하지 않다.

실패 조건 F4는 "선검증 장치 인증 실패(Pre-Validation Device Authentication Failure)'를 나타내며, 장치 인증이 검증 보다 먼저 일어나는 방식으로, 인증이 검증에 바인딩되는 경우에 적용될 수 있다. F4 조건은 만료된 장치 증명서를 나타내는 F4a 시나리오를 포함한다.

여기에서는, 상기 설명한 실패 조건들에 대한 검출 및 처리 방법들이 설명된다. 실패 조건 F1에 있어서, PVE는 수신된 TrE_info를 이용하여 로컬 검증 데이터 베이스(V-DB)에게 질문한다. TrE_info의 구조는, TrE의 증명, 제조업자, 메이크, 일련 번호에 대한 상세한 정보를 포함한다. 검증 데이터베이스 V_DB는 어떤 TrE들이 신뢰성있는 것으로 고려될 수 있는 지에 대한 정보를 저장한다. 예를 들어, 특정의 벤더, 모델, 또는 기타 유사한 식별자를 신뢰하도록 방침들을 구현하는 것이 가능하다. TrE_info의 평가 결과에 따라, TrE를 신뢰할 수 없다면, PVE는 이러한 정보를 포함하는 메시지를 SeGW에 전송할 수 있다. 그러면, SeGW는 이 메시지에 입각하여 적절하게 행동할 수 있다. PVE는 잘못된/신뢰성없는 제조업자 등의 액세스 거부의 원인을 포함하는 스테이트먼트를 T_PVM 토큰(예를 들어, 부가적인 데이터 필드)에 부가한다. PVE는 T_PVM 상에 타임 스탬프 및 서명을 넣는다. T_PVM은 SeGW에 전송된다. 그러면, SeGW는 타임 스탬프를 검증(리플레이 보호)하고, 서명을 검증(위조된 전송자를 막는다)할 수 있다. 그런 다음, SeGW는 네트워크 액세스 및 장치 인증을 거부하고, 추가의 인증 시도들을 차단할 것이다.

네트워크 액세스 및 장치 인증을 거부하는 경우, 검증과 인증이 바인딩된다면, 이는 인증 절차를 끊을 것을 요구할 것이다.

제 1 변형에서, 제조업자, 장치 버전 및 다른 특성과 같은 특정의 특성들에 따라 장치의 블랙 리스트(blacklist)를 만드는 것이 가능하다.

PVE는 또한, Dev_ID 및 TrE_info를 이용하여, 알려지지 않은 TrE들에 대해, RIM 업데이트 프로세스와 유사한 V_DB 업데이트 프로세스를 개시할 수 있다.

실패 조건 F2에 대해, PVE는 수신된 Clist로부터의 모든 컴포넌트들에 대해 V_DB로부터 RIM들을 페치한다. 검증 데이터베이스 V_DB는 증명된 RIM들 만을 저장한다. 해당하는 RIM 증명서들은 V_DB에 안전하게 저장되어야 한다.

일 실시예에서, RIM 증명서들은 V_DB에 인제스천되기 전에 검사된 다음, 폐기될 수 있다. 대안적으로, RIM 증명서들은 보안 목적으로 저장될 수 있다. 예를 들어, MNO가 RIM들 및 신뢰성있는 제 3 당사자들로부터의 이들의 증명서들을 획득함에 있어서 성실하게 수행했다는 점에서 볼 때, MNO는 RIM 증명서들을 이용하여 감사자(auditor)에게 장치 관리에 있어서의 순응(compliance)을 증명할 수 있다.

실패 조건 F2a에 대해, PVE는 검색된 RIM들로부터 정확한 검증 데이터를 재계산하고, 이를 검증 메시지 내에서 수신된 검증 데이터에 매치시킬 수 있다.

만일 계산된 정확한 검증 데이터가 검증 메시지로부터의 검증 데이터와 매치하지 않으면, 장치에 대한 보안 스타트업 프로세스가 손상되었거나, 또는 잘못된 RIM들이 장치에 저장되고, 보안 스타트업 프로세스 동안 무효한 컴포넌트들이 로드되었을 수 있다. PVE는, 측정 값들(이 값들은 검증 메시지 내에서 전송되거나, 또는 PVE로부터의 개별적인 요청에 대한 응답으로 전송된다)과 RIM들을 비교하여, 실패한 컴포넌트들을 검출할 수 있다.

F2a 방침에 의존하여, 일부 옵션들이 적용될 수 있다. 거절의 경우, PVE는 SeGW에 검증의 결과를 시그널링할 수 있다. SeGW는 네트워크 액세스를 거부하거나, 또는 장치를 격리된 네트워크(quarantine network)에 넣는다. 업데이트의 경우, 검증 데이터 실패를 나타내는 검증 결과(T_PVM)를 수신한 후, DMS는 관리 절차에 따라, 검증에 실패한 컴포넌트들을 교체하기 위해 관리 프로세스를 시작할 수 있다. DMS는, 검증이 실패했으며 장치가 재검증할 것임을 나타내는 표시자와 함께, T_PVM을 SeGW에 전송할 수 있다. DMS는 정확한 RIM들을 장치에 전송하고, 리부트를 트리거할 수 있다. 리부트할 때, 장치는 새로운 RIM들을 이용하여 재인증 및 재검증할 수 있다. 검증 데이터가 또 다시 부정확하면, 장치는 원격 관리 절차들에 의해 복구되지 못할 수도 있다. 끝없는 재 스타트업 사이클을 막기 위해, DMS는 원격 리부트 트리거를 전송할 때, 타임 스탬프와 함께 Dev_ID를 저장할 수 있다. DMS가 다시 한번 업데이트를 수행하라는 명령을 수신하면, 그 DMS는 Dev_ID가 이미 저장되어 있는 지를 체크할 수 있다. 몇 개의 저장 엔트리들이 존재하면, 타임 스탬프들은 짧은 리부트 사이클들을 표시함으로써, 장치가 복구될 수 없음을 나타낼 수 있다. RIM들이 검증에 이용되지 않는 다면, 실패 조건 부류 F2의 처리를 위한 상기 설명된 방법들은 선택적일 수 있다.

다른 변형에 있어서, PCR 값과 같은 검증 데이터에 기초하여, PVE는 PCR 값들에 의해 신뢰성있는 구성들을 캐시하고 있는 데이터베이스 V_DB의 특별한 부분들을 이용할 수 있다. PVE는, 유효한 구성들에 대해, PCR 값들의 경우 해쉬 테이블과 같은 검증 데이터의 테이블을 찾아볼 수 있다. 매치가 발견되면, 검증은 즉시 성공적이게 된다. 유효한 구성들에 대한 미리 계산된 PCR 값들을 V_DB에 저장하는 것은, 동일한 구성(여기에서는, 해쉬 값들이 동일하다)에서 작동하는 장치들의 부류들에 대해 유익할 수 있다. RIM들에 대해 모든 컴포넌트들을 비교하는 대신, 단일의 합성 해쉬 값을 비교할 수 있게 됨으로써, 계산적인 오버헤드를 낮추고, 검증 프로세스의 속도를 높인다.

어떠한 방침 실패 조건도 충족되지 않으면, 장치는 유효하다. PVE는 SeGW에 이를 신호할 수 있으며, SeGW는 CN에 대한 접속을 허가할 수 있다.

실패 조건 F2b에 대해, RIM들은 신뢰성있는 제 3 당사자(TTP)로부터 페치될 수 있다. 하나 (또는 다수의) 컴포넌트들에 대한 RIM이 V_DB에 저장되어 있지 않으면, PVE는 누락된 RIM들의 리스트를 RIMman에 전송한다. 그러면, RIMman은 TTP들로부터 (증명된) RIM들을 페치하고자 시도한다. Clist는 (URN들과 같은) 컴포넌트 표시자 CInd를 포함하며, 이에 의해 RIMman은 컴포넌트들을 식별하고, 해당하는 RIM 증명서들을 어디에서 찾을 것인 지에 대한 정보를 얻을 수 있다. RIMman은 V_DB 내의 RIMc의 검증을 포함하여, 새로운 RIM들에 대한 RIM 인제스천을 수행한다. RIMman은 CInd, RIM 및 RIMc를 저장하고 있는 V_DB의 업데이트를 수행한다. RIMman은 PVE에 V_DB의 업데이트를 시그널링하며, PVE는 V_DB로부터 누락된 RIM들을 페치할 수 있다.

대안적으로, RIM들은 장치로부터 페치될 수 있다. 만일 장치가 검증 메시지 내에, (RIM들을 포함하는) 저장된 RIMc들을 네트워크에 제공할 수 있는 성능을 표시했다면, PVE는 그 장치에게 검증에 대해 누락된 RIM들 및 RIMc들을 요청할 수 있다. 이것은 RIM 페칭을 위한 백드롭(backdrop) 방법으로서 이용될 수 있다. 장치는 보안 스타트업에서 이들 모두를 이용했기 때문에, 이 장치에는 모든 RIM들이 존재한다. 만일 PVE가 일부 컴포넌트들에 대한 RIM들을 찾을 수 없다면, PVE는 누락된 RIM들 및 T_PVM의 리스트를 새로운 타임 스탬프를 어태치하여 SeGW에 보낸다. SeGW는 장치와 프로토콜을 수행하여 RIMc들을 검색한다. SeGW는 수신된 RIMc들을 타임 스탬프와 함께 T_PVM에 부가하고, PVE에 T_PVM 토큰을 전송한다. PVE는 검색된 RIMc들을 RIMman에 전송한다. 그러면, RIMman은, 수신된 RIMc들이 신뢰성있는 엔티티로부터 발행되었고 유효함을 검증한다. RIMman은 V_DB 내로의 RIMc들의 검증을 포함하는 새로운 RIM들에 대한 RIM 인제스천을 수행한다. RIMman은 V_DB의 업데이트를 수행한 다음, PVE에 V_DB 업데이트를 시그널링한다. 그러면, PVE는 V_DB로부터 검증된 RIM들을 페치하여, 검증을 시작할 수 있다. 만일 검색 및 인제스천 프로세스 이후에도 컴포넌트들에 대한 RIM들이 여전히 누락되어 있다면, PVE는 RIMc들을 장치에 다시 요청하는 것이 아니라, 여기에서 설명되는 바와 같이 TTP들로부터 RIM들을 페치할 것이다. TTP의 장치로부터 얻어지는 임의의 RIM들은 디지털 증명서들과 동일한 방침으로 신뢰성에 대해 검증될 수 있다.

PVM 컴포넌트들 간의 신뢰 모델은 장치로부터의 RIM 인제스천에 있어서의 액션들의 순서를 결정한다. PVE는 장치로부터의 RIM들/RIMc들을 신뢰하지 않고, V_DB로의 이들의 인제스천을 기다리는데, 이는 그 데이터의 신뢰성을 체크한 후 RIMman에 의해서만 수행된다. PVE는 또한, RIMman의 RIM 인제스천 동작과 동시에, 장치가 수신하는 RIM들에 기초하여 검증 데이터의 재계산을 시작할 수 있지만, 이들의 신뢰성에 대한 RIMman의 결정을 기다려야 한다.

RIMc들은 무결성이 보호되는 추가적인 메시지로 전송될 수 있는데, 왜냐하면 이는 CN 내에서만 전송되기 때문이다. RIMc들을 포함하는 메시지는 T_PVM에 링크가능해야 한다.

장치들에 대해, RIM 인제스천 프로세스는 외부 엔티티에 의해 수행되며, 장치 및 PVM 인프라구조에 대한 완전한 인제스천 프로세스로 확장될 수 있다. 이는 PVM 아키텍쳐 내에서 분배된 RIM 인제스천으로서 식별될 수 있다.

PVE로부터 RIMman으로의 모든 메시지들은 포맷 및 콘텐츠에 있어서 제한됨으로써, 메시지 무결성을 보장하고, 예를 들어 기형의 메시지 공격들을 완화시킨다. 본질적으로, 메시지들은 기준 메트릭들이 검색될 수 있는 위치를 지시하는 컴포넌트들에 대한 단일의 URN들을 포함할 것이다.

실패 조건 F3에 대해, PVE는 구성 방침 데이터베이스 C_DB로부터 허용된 구성들에 대한 방침을 페치한다. 이러한 구성 방침 데이터베이스 C_DB는 Dev_ID에 의해 허용된 구성들을 포함한다. C_DB는 CPman에 의해 관리된다. C_DB는 또한, 연결이 끊기고 한동안 검증하지 않았던 장치에 대해 요구되는 업데이트와 같은 방침 액션들을 포함할 수 있다. PVE는, Clist 내의 정보에 기초하여, CPman으로부터 수신된 방침들을 평가한다. 만일 평가에 의해, 실패 조건들 F3a 또는 F3b 중에서 어느 하나가 야기된다면, 다른 액션들이 적용될 수 있다.

거절의 경우, PVE는 실패한 구성 방침에 대한 메시지를 T_PVM에 부가하고, T_PVM 상에 타임 스탬프 및 서명을 넣은 다음, SeGW에 전송한다. 그러면, SeGW는 타임 스탬프를 검증(리플레이 보호)하고, 서명을 검증(위조된 전송자를 막는다)할 수 있다. 그런 다음, SeGW는 네트워크 액세스 및 장치 인증을 거부하고, (추가의 인증 시도들을 차단할 수 있다). 만일 검증과 인증이 바인딩된다면, 인증 프로세스를 중단(break)시킬 수 있다.

만일 Clist가 알려지지 않았고, 이에 따라 C_DB에서 발견되지 않았거나(실패 조건 F3b) 또는 Clist 내에 컴포넌트들에 대한 어떠한 방침도 존재하지 않으면(F3a의 특별한 경우), PVE는 CPman에게 TTP들로부터 구성 방침들을 찾을 것을 요청한다. 만일 CPman이 새로운 구성 방침들을 검색할 수 있다면, CPman은 C_DB를 업데이트하고, 업데이트된 구성 방침들에 대한 표시자와 함께, 메시지를 PVE에 전송한다.

업데이트가 새로운 컴포넌트(F3a 참조)를 포함한다면, C_DB 및 V_DB를 일관되게 유지할 수 있으며, 이러한 업데이트는 새로운 컴포넌트 식별자를 포함하여 CPman으로부터 PVE에 시그널링될 수 있다. 그러면, PVE는 컴포넌트들에 대한 업데이트된 또는 새로운 RIM들을 페치하기 위해, 새로운 컴포넌트에 대해 필요한 정보를 RIMman에 전송한다. 여기서, 우리는 컴포넌트들 Cman 및 C_DB 그리고 RIMman 및 V_DB가 독립적으로 동작할 수 있도록 하기 위해, 구성 및 RIM 관리를 위한 관리 프로세스들을 개별적으로 유지하기를 원한다. 만일 방침이 장치에 대한 업데이트를 요구한다면, PVE는 업데이트 프로세스를 트리거한다.

간단한 방침의 하나의 예로서, C_DB는 허용된 구성들의 리스트를 포함할 수 있다. PVE는 수신된 Clist를 CPman에 전송하고, CPman은 그 Clist를 저장되어 있는 허용된 구성들에 매치시킨다. 어떠한 매치도 발견되지 않으면, 실패 조건 F3b가 검출된다. 업데이트들을 체크하는 것이 요구될 수 있는데, 왜냐하면 현재의 검증 프로세스는 장치 관리 프로세스 동안 장치 업데이트 이후의 재검증이 될 수 있기 때문이다. 이러한 관리 절차 동안, 장치 구성은 변경될 수 있으며, C-DB로부터의 새로운 구성들에 대해 검증되어야 할 수도 있다.

여기에서는, 재검증 프로세스의 하나의 예에 대해 설명한다. 일단 장치가 네트워크에 의해 인증이 되면, 이 장치는 거의 리부트되지 않음으로써, 전력 손실과 같은 예정에 없는 이벤트들을 막도록 되어 있다. 장치의 재검증은 실행 환경의 일상적인 부분이 될 수 있다. 주기적인 재검증은 네트워크로 하여금, 불량 코드(rogue code)의 실행 위험을 감소시키면서, 장치가 정의된 상태에서 작동하고 있다고 확신할 수 있게 한다. 재검증은 또한, 인증 절차가 다시 개시될 수 있게 함으로써, 키 교환을 새롭게 유지하고, 보안 통신 터널을 재확립한다. 장치 재검증에는 2개의 트리거들이 있는 바, 하나는 네트워크에 의해 것이고, 다른 하나는 장치에 의한 것이다. 여기에서 설명되는 재검증 방법들은 상기 검증 방법들 중 어느 것에라도 적용될 수 있다.

여기에서는, 장치에 의해 개시되는 재검증의 하나의 예에 대해 설명한다. 장치에 의해 개시되는 재검증은 주기적으로 일어날 수 있다. 장치 이용의 빈도수에 의존하여, MNO는 장치 셋업 절차들 동안 주기적인 재검증 스케쥴을 정할 수 있다. 스케쥴된 시간에서, 장치는, 인증과 함께, 검증 프로세스가 다시 시작되도록 트리거하는 리부트 시퀀스(reboot sequence)를 개시한다. 이때, 장치에 대해 소프트웨어 업데이트가 요구된다면, 해당하는 OAM 프로세스가 또한 개시될 수 있다. 장치가 요구되는 시간 프레임 내에서 재인증/재검증을 하지 않는 다면, CN이 재검증을 트리거할 수 있다. 오퍼레이터들은 재검증이 오로지 장치에 의해서만 개시되는 재검증 프로세스는 제어할 수 없다. 많은 양의 장치들이 매월 첫째날과 같은 동일한 스케쥴을 실행한다면, CN 인프라구조 상의 부하를 증가시킬 수 있다.

여기에서는, 네트워크에 의해 개시되는 재검증의 일 예에 대해 설명한다. 네트워크에 의해 개시되는 재검증은 장치에 의해 개시되는 경우에서와 같이 주기적으로 일어날 수 있지만, 네트워크가 보안 이유로 필요하다고 간주하는 때에는 언제라도 일어날 수 있다. 또한, 재검증은 방침의 일부로서 오페레이터에 의해 셋업될 수 있으며, 이에 따라 장치 내의 모듈은 프로그램된 간격들로 재검증을 수행하도록 오퍼레이터에 의해 프로그램된다. 재검증은, 재검증 요청을 나타내는 IKEv2 메시지를 장치에 전송함으로써 트리거될 수 있다. 통지 페이로드는 장치에 대해 새롭게 정의되는 재검증 트리거 코드를 운반하는 데에 이용될 수 있다.

PVE는 SeGW에 재검증 표시자를 주기적으로 전송할 수 있다. 전송되는 모든 재검증 요청들을 계속해서 파악하기 위해, PVE는 이들을 DEV_ID 및 타임 스탬프와 함께 저장한다. 그런 다음, PVE는 임의의 장치들이 재검증 요청을 무시했는 지를 주기적으로 체크한다. SeGW는 이 요청을 IKEv2 프로토콜을 통해 장치에 전송할 수 있다. 재검증 메시지는 서비스 중단 위험을 줄이기 위해 설치시에 호스팅 당사자(hosting party)들의 요청에 기초하여 셋업될 수 있다.

장치는 재검증 요청을 나타내는 통지 필드를 갖는 IKE 메시지를 수신한다. 그러면, 장치는 네트워크에 대한 검증 및 인증이 재설정되는 리부트 시퀀스를 개시한다. 장치가 손상되어 재검증 요청을 무시한다면, PVE는 모든 액티브한 재검증 요청들을 모니터링하는 동안 이를 검출할 수 있다. PVE는 SeGW에 실패한 재검증을 시그널링하며, SeGW는, 예를 들어 장치를 격리 네트워크 상태에 넣음으로써, 적절히 동작할 수 있다.

네트워크에 의해 개시되는 재검증에 대한 다른 방법은, 장치에 리부트 신호를 전송하고, 보안 스타트업 동안 리부트 및 그에 따른 재검증을 트리거하는 것을 포함한다.

다른 방법에 있어서, 장치의 재검증은 다른 네트워크 엔티티들로부터의 요청에 의해서도 일어날 수 있다. 만일 장치 제조업자가 자신들의 장치가 크게 손상되었다고 여기는 경우, 그 제조업자는 MNO를 컨택하여 재검증을 요청할 수 있다. 이는, MNO가 재검증이 일어날 수 있는 지의 여부를 결정하는 백 오피스 프로세스(back office process)에 의해 이루어질 수 있다. PVE 또는 HMS는 재검증 및 재인증을 개시할 수 있다.

여기에서는, 플랫폼 관리의 일예에 대해 설명한다. DMS는 장치 관리를 담당하는 주요 엔티티이다. 수신되어 저장되는 장치 정보, 이를 테면 벤더, 하드웨어/소프트웨어 구성들, TrE 성능들 등에 기초하여, DMS는 소프트웨어 업데이트, 구성 변경들 및 OTA 장치 관리 절차들을 개시할 수 있다. 일반적으로, 관리 액션들은 전송되는 검증 데이터, PVE부터의 검증 결과, 및 C_DB 내의 방침들(이를 테면, 요구되는 타겟 구성들)에 의해 결정된다.

DMS는 장치의 TrE와 보안 터널을 확립할 수 있다. DMS는 T_PVM 토큰을 이용하여, Dev_ID, 가장 최근에 보고된 검증 데이터 및 장치에 대한 Clist를 검색할 수 있다. Dev_ID를 이용하여, DMS는, 장치의 상태를 '액티브'에서 '관리'로 설정하기 위한 표시자와 함께 T_PVM을 전송함으로써, 장치의 TrE에 대한 보안 채널을 확립하기 위해 SeGW에 질문한다. 따라서, SeGW는 이러한 토크을 보유하고, 예를 들어 격리를 통해, 백홀 접속을 제공하지 않고, DMS가 관리 액티비티의 끝을 확인해주기를 기다릴 수 있다.

DMS에 의한 관리 액션에 의존하여, 예를 들어 소프트웨어 업데이트 이후의 리부트에 의해, 장치는 재검증을 할 수 있다. 이후, 재검증이 일어날 수 있으며(여기에서는, 이전 검증으로부터의 T_PVM을 이용함으로써 PVM 시스템 상태가 유지된다), 새로운 것을 발생시키지 않을 수도 있다. 이 경우, DMS는 '관리'로부터 '재검증'으로 변경된 장치 상태 표시자와 함께, 업데이트된 T_PVM 토큰을 SeGW에 전송한다. SeGW는 재검증을 기다리는 장치들의 리스트를 보유하는 바, 장치들이 네트워크 액세스를 요청할 때 이들을 찾아본다. 그런 다음, SeGW는 장치가 재검증하는 것을 일정 시간 기간 동안 기다릴 수 있다. 이후, 재검증의 결과가 DMS에 시그널링됨으로써, 관리 프로세스의 성공적인 완료를 확인한다.

재검증의 필요성은 장치에 대한 시스템 모델에서 발생할 수 있다. DMS로부터 다운로드되는 새로운 컴포넌트들은 다음 보안 스타트업 프로세스 바로 다음에 장치 구성 내에 삽입된다. 따라서, 플랫폼 관리의 종결 단계로서 재검증을 트리거할 필요가 있다. 장치는 리부트해야 하기 때문에, 그리고 또한 플랫폼 검증이 플랫폼의 인증과 바인딩된다면, 재검증은 플랫폼 검증 및 관리를 위한 기존의 접속을 끊는 것을 포함할 수 있다. 이 경우, SeGW는 바로 앞의 패러그래프에서 설명한 바와 같이 재검증을 위한 상태를 유지할 수 있다.

장치의 TrE에 대한 보안 터널의 확립에 의해, DMS는 새로운 소프트웨어(SW) 컴포넌트들과 같은 SW 컴포넌트들을 설치/삭제(install/uninstall)하고, 구성들을 변경하며, 그리고 재검증을 트리거할 수 있다.

다른 변형에서, 장치는 검증 메시지 내의 플래그(flag)에 의해 재검증을 표시할 수 있다. 이에 의해, SeGW에 접근하는 각 장치에 대해 재검증 리스트를 찾아볼 필요가 없게 된다. 상기 플래그는 TrE 컴포넌트에 의해 수행되는 프로세스와 같은 보안 프로세스에서 설정될 수 있으며, 이에 따라 장치는 플래그를 설정함으로써 재검증을 피할 수 있다.

이러한 단계 및 이전 단계는 PVE가 아닌 SeGW에서 일어날 수 있는데, 그렇지 않으면 SeGW는 새로운 토큰을 자동으로 발생시킬 것이다. 특히, 이러한 단계들은 장치 관리를 위해 이용되는 프로토콜 단계들을 포함하는 바, 여기서 SeGW는 장치에게 리부트할 것을 요구하는 재검증을 계속해서 파악해야 한다. 장치 리부트 이후, 장치는 재접속되고, 그에 따라 재인증하기 때문에, SeGW는 재검증을 위해 리부트하려고 하는 장치들을 계속해서 파악해야 하는데, 그렇지 않으면, SeGW는 접속 및 인증 시도들을 최초 접속으로서 고려하고, 그에 따라 새로운 토큰을 발행할 것이다. 따라서, 재검증 리스트를 유지하는 것이 SeGW에 대해 포함된다.

많은 라운드의 재검증 동안 T_PVM을 계속해서 이용하는 것은, 되풀이하여 발생하는 업데이트 실패들 및 기타 불규칙한 행동 패턴들을 검출하는 데에 유용하다.

DMS가 장치에 새로운 컴포넌트들을 설치한다면, 소프트웨어에 대한 RIM들이 DMS로부터 TrE로의 동일한 관리 메시지 내에 포함되도록 보장할 수 있다. TrE는 RIM들의 보안 저장 및 이들의 로컬 관리를 담당할 수 있다. 필요하다면, DMS는 컴포넌트들의 설치 이후 재검증을 트리거한다. 새로운 소프트웨어에 대한 RIM이 PVE에 전송될 수 있으며, PVE는 이 RIM을 RIMman을 통해 V_DB에 저장한다. DMS는 CPman을 이용하여 구성 방침 데이터베이스 C_DB를 그에 따라 업데이트한다. 새로운 컴포넌트에 대한 RIM은, PVE가 새로운 구성을 검증하기 위해, 장치가 재검증에 관여하기 전에 V_DB 내에서 이용가능해질 수 있다. 예를 들어, 구성 변경의 경우, DMS가 소정의 컴포넌트에 대한 파라미터들을 변경한다면, C_DB는 CPman을 통해 DMS에 의해 업데이트될 수 있다.

TrE는 보안 업데이트 및 관리 기능을 위한 보안 실행 환경을 제공할 수 있다. 이 기능에 의해, 실패한 소프트웨어 또는 컴포넌트 업데이트의 경우, 손상된 장치는 적어도 구제 모드(rescue mode)로 확실하게 전송될 수 있다. 실패의 경우, 폴백 코드 베이스(FBC)가 DMS에 의해 장치 전환(device reversion)을 위해 이용될 수 있다. 이에 의해, 장치는 본래의 상태(pristine state)로 되돌아갈 수 있으며, 메인 코드는 이러한 상태로부터 DMS 관리 방법들을 통해 업데이트될 수 있다.

경쟁 상태(race condition)를 피하기 위해, 재검증은 토큰 전달 후, DMS로부터 TrE로의 메시지에 의해 트리거될 수 있다. 그렇지 않으면, SeGW가 재검증을 준비하기 위해 토큰을 받기 전에, 장치가 재검증하고자 시도할 수 있다.

다른 변형에서, SeGW는 재검증 리스트 내에 각 장치에 대한 재검증 시도들 또는 실패한 시도들의 수 'n'을 유지할 수 있으며, 이후 장치는 블랙 리스트에 올라가고, 격리되거나, 인필드 유지(in-field maintenance)가 트리거되거나, 또는 그 조합이 이루어질 수 있다.

다른 변형에서는, 보안 터널을 확립하기 위한 통신 시크릿들이 T_PVM에 포함되거나, 또는 T_PVM으로부터 추출될 수 있게 됨으로써, SeGW가 관련되는 것을 피한다.

부가적인 방법은, 장치에 대한 접속을 거부하지 않으면서, 검증될 수 없으며 그리고 PVM에서 교체 또는 업데이트될 수 없는 컴포넌트들을 디스에이블(disable)시키는 것이다. 본질적으로, DMS는 디스에이블 CInd를 전송하고 메시지를 재검증할 수 있는데, 이는 하기 설명되는 바와 같이 오퍼레이터 로크인(operator lock-in)으로부터의 위험들을 완화한다. PVM은 장치들과 오퍼레이터들 간의 "신뢰 배틀(battle of trust)"과 싸우는 데에 이용될 수 있다. "신뢰 배틀"의 발생을 디스에이블시키기 위한 다른 방법들도 이용될 수 있다. 하나의 예시적인 방법에서, 장치의 컴포넌트들은 Clist 내에 이러한 컴포넌트없이 재검증을 강제적으로 이루어지게 함으로써 디스에이블 될 수 있다. 이것은, 장치에 대한 유효한 업데이트가 이용가능하지 않은 경우에 적용될 수 있다. 다른 방법에서는, 로드 순서가 강제적으로 변경될 수 있다. 다른 방법에서는, 파라미터들을 강제적으로 변경하는데, 이는 RIM에 영향을 줄 수도 있고, 영향을 주지 않을 수도 있다. 파라미터들의 강제적인 변경은, DMS로 하여금, 오로지 PVE로부터 검증이 실패한 것들에 대한 것 만이 아니라, 모든 장치 컴포넌트들에 대한 모든 필요한 정보를 얻을 것을 요구한다.

일반적으로, PVM에서는, 장치에 RIM 증명서들을 전송할 필요가 없다. 제시되는 PVM 아키텍쳐에서, 검증 및 관리는 RIMman에 위치하는 오퍼레이터 네트워크의 작업이다. 장치는 관리 프로세스에서 수신된 RIM들 및 CInd들을 신뢰할 수 있는데, 왜냐하면 네트워크를 신뢰하기 때문이다. 한편, TCG(Trusted Computing Group) MPWG(Mobile Phone Working Group)는 신뢰성있는 장치에 의해 RIM 인제스천을 분산화된 프로세스(de-centralized process)로서 정의하는 바, 장치는 또한 MTM에 의해 보호되는, RIM들에 대해 얻어지는 증명서들을 설치하기 전에 검증한다. 양쪽의 변형들은 상호 배타적이지 않다. DMS는 다른 데이터와 RIMc들을 전송할 수 있으며, TCG MPWG를 따르는 장치가 이들을 TCG 사양들에 따라 설치할 수 있다. 이것이 TCG MPWG에 의해 정의되는 보안 스타트업에 대한 장치 관리와 PVM 간의 차이점이 될 수 있다.

여기에서는, 검증 데이터의 일 예에 대해 설명한다. 이를 테면, (단일 측정들의 집합적인 해쉬 값들인) PCR 값들의 형태의 검증 데이터를 전송하는 것 뿐 아니라, 인증에 대해 검증 데이터를 바인딩시키는 것은, TCG 사양들에 의해 제공되는 기술 표준이다. 하지만, TCG 사양들에 따른 검증 데이터의 생성 및 바인딩은, 특히 많은 측정 컴포넌트들을 갖는 장치들에 대해 계산적으로 비용이 많이 든다. 이것은 보통 여기에서 설명되는 암호화 확장 오퍼레이션(본질적으로 2개의 구(old) 값들로부터 새로운 해쉬 값들을 생성한다)에 의해 이루어진다. 이에 의해, 장치의 스타트업 프로세스를 상당히 느리게 할 수 있는 바, 이는, 이를 테면 홈 환경에서 바람직하지 않다.

또한, RIM들과 검증 데이터 사이에는 리던던시가 있는데, 왜냐하면 이들은 측정의 결과에 대한 유사한 정보를 전송하기 때문이다. 만일 보안 스타트업 프로세스가 정확하게 수행된다면, TrE는 측정들을 RIM들과 비교하여, 양쪽이 일치하는 컴포넌트들 만을 로드한다. 따라서, Clist 내의 지정된 RIM들은 검증 데이터의 모든 정보를 운반한다. 실제로, 이들은 검증 데이터 보다 더 많은 정보를 운반하는데, 왜냐하면 검증 데이터는 상기 언급한 측정들의 집합으로 여겨지기 때문이다. 검증 데이터는 실제 측정 값들에 대한 암호적으로 고유한 약기들(shorthands)이다. 일 실시예에서, PCR 값들은 검증 데이터로서 이용될 수 있다.

검증 데이터에 대한 논의의 기초가 되는 기본적인 가정은, 보안 스타트업 프로세스가 Clist 내에 표시되어 있는 RIM들과 실제 측정들을 비교함에 있어서 정확히 동작한다는 것이다. 따라서, 보안의 관점에서, 검증시 검증 데이터가 장치의 신뢰성에 부가되는 하나의 주요한 이유가 있다. 이는, 장치가 부정확한 RIM들을 가지고 있거나, 또는 위조된 RIM들과 측정들을 비교할 때의 경우이다.

보안 셋업 동안 발생된 검증 데이터를 -보안이 잘된 데이터의 측면에서- 유지함으로써, 심지어 보안 셋업 또는 AuV와 같은 단순한(monadic) 접근의 경우에도, 획득한 시스템 상태를 고유하게 식별하는 추가의 논의들이 있다. 실제로, 보안 스타트업 자체는, 이 경우 측정 값들이 없는 단지 컴포넌트 리스트가 될 수 있는 다른 검증 데이터의 무결성 보호를 위해 아무것도 하지 않는다. CId들의 리스트는 또한, (이를 테면, TTP로부터의) 컴포넌트들에 대한 신뢰 정보를 어디서 그리고 어떻게 얻는 지를 검증기에게 알린다.

공격자는 검증 데이터(Clist)를 조작하여, 신뢰도가 더 적은 컴포넌트들의 식별자들을 신뢰도가 더 높은 것들의 (캡춰된) CId들로 교체('컴포넌트 신뢰 격상')하고자 시도할 수 있다. 검증 장치(TrE)는 위조된 데이터를 시그널링하고 정확하게 검증하는데, 이는 어떠한 검증 데이터도 갖지 않는 경우 조작을 내부적으로 검출하기 위한 수단없이 이루어진다.

이러한 공격을 어느 정도 완화시키는 하나의 방법은, 보안 스타트업 엔진이 데이터를 상태(마지막 PCR 값)로 실링(sealing)함으로써, 그 데이터를 정적(staic) 상태가 되게 하는 것이다. 이후, 검증을 위해, 이는 열릴 필요가 있으며(즉, 실링을 풀어야 할 필요가 있으며), 동일한 보안 갭이 다시 열리게 된다. 또한, 시스템은 SML 실링 이후 정적으로 유지됨으로써, 이러한 접근의 유연성을 제한해야할 필요가 있다.

결론적으로, 장치 및 검증기는 모두, 심지어 보안 스타트업의 경우에도, 검증 데이터에 의해 검증 데이터를 지원하는 타당한 이유들을 가지고 있다.

여기에서, '검증 데이터'는 '원(raw) 측정 데이터로부터 추가 처리(예를 들어, 해싱)되는 데이터(이는 이후 RIM들과 매치되는지 검증된다)'와 같은 뜻으로 이용된다. 이러한 검증 데이터는, 보안 스타트업 완료 이후, 플랫폼의 상태를 고유하게 식별한다. 부정확한 RIM들을 프로비저닝하는 것은, 이를 테면 손상된 소스로부터 비롯될 수 있고, PVM 시스템에 전체적으로 큰 영향을 줄 수 있으며, 그리고 이에 따라 중대한 위험을 야기할 수 있다.

구체적인 시나리오는, 오퍼레이터 CN 외부에 있을 수 있는 RIM들의 신뢰성있는 소스가 다른 당사자에 의해 손상(예를 들어, 하이잭(hijack) 또는 위조)되는 것이다. 통상의 PVM 플랫폼 관리에서는, 이를 검출하여 정정하기 전에, RIM 소스가 손상된 컴포넌트들과 함께, 위조된 RIM들을 많은 수의 장치들에 전달할 수 있다.

이러한 경우의 일반적인 구제책(즉, 공개 키 인프라구조(PKI)에서의 일반 실행)은, 허용된(according) RIM 증명서들을 취소(revoke)하는 것이다. 신뢰성있는 기준 데이터가 장치들에 존재할 수 있기 때문에, 이러한 절차는 장치들 상에 부하를 야기할 수 있다. 공격에 의해 실제로 작은 부분 만이 영향을 받았다고 할지라도, TRV 취소는 장치 집단(pupulation) 전체에 대해 RIM, RIMc 및 컴포넌트 업데이트들을 강요할 수 있다. 이는 심한 네트워크 트래픽 및 사용자들에 대한 불편을 야기할 수 있다. 메커니즘 및 프로토콜들이 장치에 의해 지원됨으로써, 허가된 TRV 취소가 실행될 수 있다.

이러한 시나리오에서는, 검증시 검증 데이터의 발생 및 이용이 적용가능하다. PVM 시스템은, 각각의 단일 검증 장치에 대해, 방침에 기초하여 검증 데이터를 이용할 수 있다. 그런 다음, PVE는 손상된 장치들을 검출하고, 이들 만을 관리할 수 있다. 여기에서, 이것은 "최소 검증 방침(Minimal Validation Policy)"으로서 설명된다.

여기에서는, PVM의 토큰 전달-기반의 오퍼레이션의 일 예에 대해 설명한다. 여기에서 설명되는 PVM은 비동기적인 프로세스이다. 따라서, 분산 시스템들 및 이들의 실패 상태들에 대한 잘 알려진 공격들을 완화하기 위해서는, 다양한 엔티티들로 이루어지는 PVM이 스테이트풀(stateful)해야 하며, 그리고 프로세스의 현재 상태를 복구할 수 있어야 한다.

일 예에서는, 이를 행하기 위해 토큰 패싱(tocken passing)을 이용할 수 있다. SeGW는, 검증 프로세스와 고유하게 관련되는 토큰의 발생 및 관리를 담당하는 엔티티로서 구성될 수 있다. PVM 토큰은 검증 TrE의 아이덴티티 뿐 아니라, 문제의 고유의 검증 프로세스에도 바인딩될 수 있다. 이러한 토큰 패싱 시도는 리플레이/재검증 보호를 포함한다. 검증 시도들은 고유하게 이루어짐으로써, 구(old) 검증들의 리플레이를 막고, 빈번한 재검증에 의한 DoS 공격들을 검출하는 수단을 제공한다. 토큰에 의해, 검증 세션이 확립됨으로써, 고유의 검증에 대한 PVM 관련 데이터와 메시지들의 고유의 연계를 가능하게 한다. 이는 또한 새로움을 평가하기 위한 전제 조건이다.

검증 토큰들은 타임 스탬프들(이들은 처음에 SeGW에 의해 발생되어, 토큰을 패싱하는 모든 엔티티에 의해 시간 정렬 리스트(time-ordered list)에 부가된다)에 기반하여(하지만, 반드시 서명될 필요는 없다) 만들어질 수 있기 때문에, 검증 데이터의 새로움이 제어될 수 있다.

새로움을 도입하는 다른 방법은, RoT가 로드된 직후 보안 실시간 통신(secure real time communication, RTC)으로부터 시간을 읽고, 이러한 타임 스탬프를 이용하여 집합적인 해쉬 체인(aggregate hash chain)을 생성하는 것이다. 다른 대안은, 시퀀스 카운터(sequence counter)를 이용하는 것인데, 이러한 시퀀스 카운터는 매 리부트 사이클 마다 증분되고, RoT에 의해 해쉬 체인을 생성하는 데에 적용된다.

새로움을 도입하는 또 다른 방법은, 스테이지 1 및 스테이지 2 체크들을 완료하고, SeGW 및 PVE와 통신을 시작한 다음, 스테이지 3 검증 결과 데이터를 SeGW에 전달하기 전에, SeGW/PVE에 의해 공급되는 논스를 이용하여 스테이지 3 체크들의 추가 검증을 바인딩시키는 것이다. 이것은 검증 데이터의 새로움을 보장한다.

많은 라운드의 재검증 동안 T_PVM을 계속해서 이용하는 것은, 표준 PVM에서와 같이, 되풀이하여 발생하는 업데이트 실패들 및 기타 불규칙한 행동 패턴들을 검출하는 데에 유용하다. SeGW는 검증 토큰에 기초하여 다양한 조건들을 검출하고 이에 입각하여 행동할 수 있다. 예를 들어, 너무 오래 액티브 상태로 유지되는 토큰은 PVM의 일반적인 실패를 나타낼 수 있다. SeGW는 토큰에 대해 PVE 및 DMS를 폴링(polling)하여, 그 상태를 알아내고, 그에 입각하여 행동한다. 이는 검증 타임아웃으로서 식별될 수 있다. 다른 예에서는, 토큰이 액티브한 동안, 재검증이 일어날 수 있다. 이는, 예기치않은 리부트, 정전 또는 DoS 공격과 같은 다양한 상태들을 나타낼 수 있다. 다른 예에서는, 랜덤한 또는 주기적인 행동과 같은 시간 기반의 패턴들이 IDS(intrusion detection system)의 방식(vein)으로 검출될 수 있다. 장치는 격리되고, 블랙 리스트에 올라가며, 인필드 유지가 트리거될 수 있다.

토큰은 또한, PVM 시스템 내의 엔티티들 간에 그리고 PVM 시스템과 장치 간에 전달되는 데이터의 무결성을 보호하는 데에 이용될 수 있다. 이를 위해, 보호될 데이터의 해쉬 값, 이를 테면 Clist 또는 실패 조건 F2a의 처리에서의 누락된 RIM들의 리스트, 및 그 데이터에 대한 포인터를 포함시키는 것으로도 충분하다. 데이터 객체(data object)는 T_PVM 내에 전체로서 포함되지 않을 수도 있는데, 왜냐하면 이것은 오버로드(overload)가 걸리게 하고, 헤아릴 수 없이 많은 오버헤드를 야기함으로써, 실제로 어떠한 DoS 공격들을 인에이블시킬 수 있기 때문이다.

여기에서는, 오퍼레이터 RIM 쉴딩(shielding) 방법에 대한 예들에 대해 설명한다. 오퍼레이터 RIM 쉴딩은, 다양한 외부 소스들로부터 비롯되는 장치 컴포넌트들에 대한 많은 RIM 증명서들을, 장치가 백홀 링크를 확립하기를 원하는 오퍼레이터, 또는 동등하게는 "선택된 홈 오퍼레이터(SHO)"에 의해 발생되는 RIM 증명서들로 대체한다. 이용가능할 때 마다, 이러한 SHO RIM 증명서(SHORIMc)들은 V_DB 내의 동일한 컴포넌트에 대한 이질적인 RIM 증명서들에 비해 검증시 우선권을 갖는다. 장치 관리에 있어서, SHORIM들은 DMS에 의해 장치들에 설치(푸쉬 다운)됨으로써, TrE에 의한 장치의 보안 스타트업시 그 장치 상에서 국부적으로 이질적인 증명서들에 비해 우선권을 갖는다.

SHORIMc들은 검증시 RIM 증명서들을 페치하기 위한 "제 1 레벨 캐쉬"로서 기능할 수 있다. 이들은, 본질적으로 V_DB의 기술적으로 분리되는 고성능의 서브 데이터베이스를 지시하는 특별한 CInd들과 관련될 수 있다.

오퍼레이터 RIM 쉴딩은, M2ME(M2M Equipment)와 같은 임의 타입의 고도의(highly) 이동 장치에 대해 유용하다. 이동 장치가 새로운 오퍼레이터의 영역에 들어가서 검증을 수행할 때, 이 새로운 오퍼레이터에게는 다른 오퍼레이터를 지시하는 CInd들이 제시될 수 있다. 이는 이러한 CInd들을 이동 장치들의 로밍과 유사한 방식으로 받아들이거나, 또는 여기에서 설명되는 바와 같이 이들을 교체한다.

오퍼레이터 RIM 쉴딩의 변형에서, SHO가 이 SHO에 의해 발생된 SHORIMc들의 서명 키의 공개 부분을 해제(release)하지 않기로 결정하면, 다른 오퍼레이터가 그 SHO로부터 나오는 장치의 컴포넌트들을 검증하는 것이 어려워지거나, 또는 심지어 불가능해질 수도 있다. 이러한 방식은 전형적인 SIM-로크(lock) 절차가 제공하는 동일 레벨의 로크인으로 확장될 수 있다. 오퍼레이터 RIM 쉴딩은, 라이프사이클 관리 툴로서, SHO와 처음 컨택하는 장치들을 원격으로 "브랜딩(branding)"하기 위해 필드 내에서의 장치들의 최초 전개에서 이용될 수 있다.

PVM에 기초하여 오퍼레이터 쉴딩을 확립하기 위해, 다음의 부가적인 단계들이 설명되는 바, 상기 설명한 최초의 PVM 절차들을 참조한다. RIM 쉴딩을 위한 PVM 셋업시, RIMman은 PVE 및 DMS를 오퍼레이터 RIM 쉴딩을 위해 이들 각각의 기능들을 수행하도록 구성한다. 플랫폼 검증시, PVE는 컴포넌트들의 리스트(이에 대해 V_DB 내에 SHORIM이 있다)를 포함하는 메시지를 (개별적으로 또는 컴포넌트 유효성에 대한 메시지와 결합하여) 전송한다. DMS는, 장치 상에 새로운 SHORIMc들이 설치될 컴포넌트들에 대해 (컴포넌트 자체를 반드시 업데이트하지 않으면서) 증명서 업데이트 액션을 수행하도록 구성된다.

검증 동안, PVE는 V_DB 내에 어떠한 SHORIM도 없는 컴포넌트들을 식별한다. (이것은, 통상의 PVM 프로세스와 같이, 컴포넌트들에 대한 임의의 RIM 및 RIMc의 이용가능성과 직교(orthogonal)한다). PVE는 오퍼레이터 RIM 쉴딩을 위해 CInd들 및 실제 RIM들(RIMman은, 본질적으로 이러한 RIM들을 서명함으로써, 해당 SHORIMc들을 발생시키기 위해 이러한 RIM들을 필요로 한다)을 포함하는 식별되는 후보 컴포넌트들의 리스트를 RIMman에 전송한다. RIMman은, 국부적으로 이용가능한 방침에 따라, 수신된 리스트의 어떤 컴포넌트들에 대해 오퍼레이터 RIM 쉴딩을 적용할 것인 지를 결정한다.

RIMman은 각각의 RIM들을 서명함으로써 이러한 컴포넌트들에 대한 SHORIMc들을 발생시킨다. 유효 기간과 같은 증명서 파라미터들이 로컬 오퍼레이터 방침에 의해 결정된다. RIMman은 V_DB 내의 SHORIMc들을 지시하는 SHOCInd들을 발생시킨다. RIMman은 V_DB에 SHORIMc들 및 SHOCInd들을 부가한다. 일 실시예에서는, V_DB 내에 최초 CInd들 및 RIMc들과 같은 모든 '구' 데이터가 이후의 추적가능성을 위해 그리고 폴백으로서 저장된다. RIMman은 (CInd, SHOCInd) 쌍들의 리스트를 DMS에 전송하여, DMS에게 문제의 장치에 대해 RIM 표시자 업데이트를 강요할 것을 지시한다. DMS는, 통상의 장치 관리에서와 같이, 하지만 컴포넌트 업데이트없이, SHO 데이터를 갖는 RIM 표시자 업데이트 메시지를 장치 TrE에 전송한다. 이러한 메시지를 이용하여, DMS는 장치에게 앞으로 검증시에 SHOCInd들 만을 이용할 것을 요청할 수 있다.

SHOCInd들을 설치하는 것 외에, 장치 상에 설치될 수 있는 것은 SHORIMc들이 될 수 있으며, 이는 로컬 방침에 의존한다. 똑똑한 장치는 자신의 최초 제조업자 CInd들 및 가능하게는 해당 RIMc들을 유지한다. 유연성을 위해, 장치는 다양한 오퍼레이터들, 최초 컴포넌트 제조업자/증명자에 대하여, 각 컴포넌트 대한 많은 변형 CInd들을 적어도 유지하고자 시도할 수 있다.

DMS는 장치의 스테이트풀 재검증을 강요할 수 있다. 스테이트풀 재검증은, 장치 상에서 RIMc 업데이트가 실패할 때에 주기적인 행동을 피하기 위해 요구된다.

여기에서는, 오퍼레이터 컴포넌트 로크인의 예에 대해 설명한다. 오퍼레이터 RIM 쉴딩의 확장으로서, 오퍼레이터는 이질적인 네트워크들 내에서의 장치 또는 그 컴포넌트들의 동작을 제어 또는 제한할 수 있다. 이는 다음의 방식으로 오퍼레이터 컴포넌트 로크인으로 확장될 수 있다. 로크될 컴포넌트의 부분은 SHO에 의해, 예를 들어 대칭 키에 의해 암호화된다. 오퍼레이터 RIM 쉴딩은 이러한 변경된 컴포넌트에 대해 수행된다. 복호화 키(decryption key)가, SHO로부터의 허가에 의해서만 액세스될 수 있는 보호 및 제어되는 공간 내의 TrE (또는 UICC)에 전송된다. 검증시, PVE에게 이러한 컴포넌트에 대한 SHOInd가 제시되면, SHO는 TrE에 대한 허가 데이터를 해제한다. 그런 다음, 그 컴포넌트의 암호화된 부분이 TrE의 보안 실행 공간 내로 전송되어, 복호화되고, 실행된다.

이에 따라, SHO-로크된 컴포넌트는, 장치가 특정 SHO에 대해 검증을 할 때에만(이 동안, 동일한 장치는 다른 오퍼레이터에 대해 검증하지 못한다) 기능할 수 있다.

다른 변형에서, 복호화된 부분은 TrE의 외부에서의 실행을 위해 해제된다. 이는 보안 측면에서 이전의 변형 보다 더 약한데, 왜냐하면 전체 컴포넌트는 장치 메모리를 덤핑함으로써 복구될 수 있기 때문이다. 얻어진 완전한(clear) 컴포넌트에 의해, RIM들이 재발생될 수 있고, 다른 오퍼레이터에 대한 검증이 성공적이 됨으로써, 로크인을 깨뜨릴 수 있다.

컴포넌트 로크인의 다른 변형은, TrE 내에서 관리되거나, 또는 UICC와 같은 다른 보안 요소들에 의해 보호되는 암호화 시크릿들없이 구현될 수 있다. 컴포넌트들의 변경들을 이용하여, 오퍼레이터 고유의 SHORIM들, SHORIMc들 및 CInd들을 발생시킬 수 있다. 이는 코드 난독화(code obfuscation) 및 워터마킹(watermarking) 분야에 적용될 수 있다.

오퍼레이터 컴포넌트 로크인의 일 예는 로밍 오퍼레이터가 다른 오퍼레이터의 컴포넌트들 또는 전체 장치들을 하이잭하는 것을 포함할 수 있다. 이것으로부터 다른 자유로운(free) 사용자 장치들을 보호하기 위한 상기 TrE 기반의 방법들이 바람직하다. 본질적으로, 장치는 이러한 절차들의 사용자/호스팅 당사자/최초 SHO에게 경고하고, 컴포넌트들에 대해 로크인을 허용할 때와 허용하지 않을 때의 방침을 유지해야 한다.

여기에서는, 특정의 PVM 시스템 및 오퍼레이터의 특성과 관련하여 PVM을 이용한 장치 관리에 있어서 장치들을 개별화하기 위한 예시적인 방법에 대해 설명한다. PVM에 의해 관리되는 장치는, 특정의 PVM 시스템 및 관리 오퍼레이터에 대한 관계에 있어서, 신뢰성있는 상태가 될 수 있다. 로밍 장치들이 다른 PVM 시스템 및 오퍼레이터의 영역에 들어갈 때, 이러한 로밍 장치들에 대해 발생할 수 있는 문제는, 장치가 자신의 구성 및 신뢰성을 이전에 누가 관리했었는 지를 증명하는 것이다. 장치가 이를 위한 증거를 제공하는 독립적인 조치들을 가능하게 하는 하나의 예시적인 방법은, 장치에 대한 어드레싱이 서명된 데이터를 그 장치에게 제공하는 것이다. 이러한 메시지의 개별화는 전송자에 의한 의도된 서명을 증명한다. 하나의 방법은 오퍼레이터에 의해 서명되는 데이터 내에 Dev_ID를 포함시키는 것이 될 수 있다. 그러면, 이러한 서명된 데이터를 제공받는 임의의 당사자는, 해당하는 메시지 및 그 콘텐츠가 서명한 오퍼레이터에 의해 그 특정 장치에 대해 의도되었음을 추정할 수 있게 된다. 이는 의존 당사자가, 서명한 오퍼레이터가 그 장치의 확실성의 검증을 (예를 들어, Dev_ID를 통해) 정확하게 수행했다고 믿는 다는 조건하에서 유지된다. 만일 이를 유지할 수 없다면, 그 대신에, 서명하는 오퍼레이터는 Dev_ID의 완전한 인증 크리덴셜을 여전히 서명할 수 있다. 서명된 데이터는 또한 실제 RIM들을 포함시킴으로써, 어느 정도의 리던던시를 부가할 수 있는데, 왜냐하면 이것은 본질적으로, Dev_ID에 의해 확장된 다른 RIMc들을 확립하기 때문이다.

PVM에 기초하여 개별화를 확립하기 위한 2개의 효율적인 방법들에 대해 설명한다. 제 1 방법에서, RIMman은 SHORIMc 내에 Dev_ID를 포함하며(이는 RIMc들이 장치에 의해 유지되는 경우에만 적용가능하다), 그리고 이에 따라 SHORIMc는 Dev_ID를 포함하여 그 장치의 내부에 저장될 것이다. 다른 방법에서, RIMman 또는 DMS는 (Dev_ID, CInd) 쌍들에 오퍼레이터의 서명을 적용하며, 그리고 SHOCInd들이 이용된다면, 이러한 SHOCInd들에도 동일한 오퍼레이터의 서명을 적용한다.

여기에서는, 장치의 블랙 리스트를 작성하는 것의 일 예를 설명한다. 장치들의 블랙 리스트들을 확립하고, 이러한 블랙 리스트들에 기초하여 네트워크 액세스를 허가하지 않는 것이 가능하다. 블랙 리스트들은 적어도 Dev_ID를 포함하며, 그리고 선택적으로 TrE_Info(증명, 메이크, 제조업자, 모델, 일련 번호)를 포함할 수 있다. 전형적으로, 이러한 리스트는 DMS에 의해 액세스될 수 있다. 일 실시예에서, 모든 MNO는 자기 자신의 블랙 리스트를 보유하며, DMS는 이러한 리스트 또는 데이터베이스를 액세스할 수 있다. 질문들은 Dev_ID를 이용하여, 소정의 장치가 블랙 리스트에 올라있는 지를 확인한다. 이러한 장치들에 대해서는 네트워크 액세스가 거부된다. 다른 실시예에서는, 글로벌 블랙 리스트(global blacklist)를 보유할 수 있는데, 개개의 모든 MNO는 장치들을 불량한(rogue) 것으로서 리스트할 수 있고, 이러한 데이터베이스는 모든 MNO들에 의해 읽혀질 수 있다. 모든 MNO는 그 자신의 장치들 만을 블랙 리스트에 올릴 수 있는 반면, 모든 MNO들은 모든 엔트리들을 읽을 수 있음이 보장되어야 한다. 이러한 글로벌 데이터베이스는 더 많은 관리 및 유지 노력을 요구한다. 상기 실시예들은 대안적인 실시예들에 대해 결합될 수 있다.

PVE가 토큰 T_PVM을 수신하면, 이 PVE은 T_PVM에 타임 스탬프를 부가한 다음, 이를 DMS에 전송하고, DMS는 그 토큰으로부터 Dev_ID를 추출하고, 선택적으로 TrE_Info를 얻는다. Dev_ID (및, 요구되는 경우 또는 존재하는 경우, TrE_Info)를 이용하여, DMS는 블랙 리스트에 질문한다. 만일 장치가 블랙 리스트에 올라있으면, DMS는 T_PVM을 포함하는 메시지를 블랙 리스트 엔트리로서 SeGW에 전송한다. DMS는 이러한 메시지에 타임 스탬프를 제공할 수 있다. 이후, SeGW는 CN에 대한 액세스를 거부할 수 있다.

다른 변형들은 TrE_Info 필드로부터의 확장된 정보를 이용하여 구현될 수 있다. 이는 특정의 벤더들, 모델들, 일련 번호들의 범위 등을 블랙 리스트에 올릴 수 있다. 블랙 리스트 행동의 복잡성에 의존하여, 로컬의 MNO-중심 솔루션이 중심 블랙 리스트 보다 더 구현하기가 용이할 수 있다.

여기에서는, 장치의 화이트 리스트(white list)를 작성하는 것의 일 예를 설명한다. 장치들의 화이트 리스트들이 확립될 수 있으며, 이러한 화이트 리스트들에 기초하여 네트워크 액세스가 허용될 수 있다. 전형적으로, 화이트 리스트들은 적어도 Dev_ID를 포함하며, 그리고 선택적으로 메이크, 제조업자, 모델, 일련 번호와 같은 TrE_Info를 포함할 수 있다. 전형적으로, 이러한 리스트는 DMS에 의해 액세스될 수 있다.

PVE가 토큰 T_PVM을 수신하면, 이 PVE은 T_PVM에 타임 스탬프를 부가한 다음, 이를 DMS에 전송한다. DMS는 그 토큰으로부터 Dev_ID를 추출하고, 선택적으로 TrE_Info를 얻을 수 있다. Dev_ID 및 선택적으로, 요구되는 경우 또는 존재하는 경우, TrE_Info를 이용하여, DMS는 화이트 리스트에 질문한다. 만일 장치가 화이트 리스트에 올라있으면, DMS는 T_PVM을 포함하는 메시지를 화이트 리스트 엔트리로서 SeGW에 전송한다. DMS는 이러한 메시지에 타임 스탬프를 제공할 수 있다. 이후, SeGW는 CN에 대한 액세스를 허가할 수 있다.

다른 실시예들은 TrE_Info 필드로부터의 확장된 정보를 이용하여 구현될 수 있다. 특정의 벤더들, 모델들, 일련 번호들의 범위 등을 화이트 리스트에 올릴 수 있다. 화이트 리스트 행동의 복잡성에 의존하여, 로컬의 MNO-중심 솔루션이 중심 화이트 리스트 보다 더 구현하기가 용이할 수 있다. 또한, 레귤레이터들(regulators)은 MNO들에게 화이트 리스트들 대신 블랙 리스트들을 보유할 것을 요구할 수 있다.

다른 실시예에서는, 모든 MNO가 화이트 리스트 또는 데이터베이스를 보유할 수 있고, DMS가 이러한 리스트를 액세스할 수 있다. 질문들은 Dev_ID를 이용하여, 소정의 장치가 화이트 리스트에 올라있는 지를 확인할 수 있다. 그러면, 이러한 장치들에 대한 네트워크 액세스가 허가될 수 있다.

또 다른 실시예에서는, 글로벌 화이트 리스트를 보유할 수 있는데, 개개의 모든 MNO는 그 자신의 장치들을 신뢰성이 있는 것으로서 리스트할 수 있고, 이러한 데이터베이스는 모든 MNO들에 의해 읽혀질 수 있다. 모든 MNO는 그 자신의 장치들 만을 화이트 리스트에 올릴 수 있는 반면, 모든 MNO들은 모든 엔트리들을 읽을 수 있음이 보장되어야 한다. 이러한 글로벌 데이터베이스는 더 많은 관리 및 유지 노력을 요구한다. 화이트 리스트에 오른 장치들의 글로벌 데이터베이스는 MNO들로 하여금 이러한 장치들 간에 부가적인 신뢰 관계들을 확립할 것을 요구할 수 있다. MNO A에 의해 신뢰성이 있는 것으로서 고려되는 장치는 화이트 리스트에 기록될 것이며, MNO B에 대한 액세스를 가질 것이다. 이는 장치들의 신뢰 레벨들을 비교하기 위한 표준화된 및/또는 증명된 장치 검증 프로세스를 필요로 한다. 선택적으로, 상기 변형들의 결합이 구현될 수도 있다.

여기에서는, 장치들에 대한 격리 네트워크들의 일 예에 대해 설명한다. 장치들에 대한 격리 네트워크가 확립됨으로써, 오퍼레이터의 네트워크에 대한 부가적인 변경을 요구할 수 있다. 이러한 새로운 네트워크에서, SeGW는 여전히 CN에 대한 시행 장벽(enforcement barrier)의 역할을 할 수 있다. SeGW는 어떤 장치들이 격리되는 지를 결정한다.

격리되는 장치들은 CN을 직접 액세스할 수 없으며, 고객들에게 어떠한 서비스도 제공할 수 없거나, 또는 제한된 서비스 만을 제공한다. 검증 데이터가 PVE에 의해 평가되는 검증이 이루어질 수 있다. 이러한 평가의 결과에 따라, 새로운 액션들이 트리거될 수 있다. 예를 들어, 장치는 신뢰성이 있는 것으로서 고려될 수 있으며, CN에 접속될 수 있다. 다른 예에서, 장치는 손상된 것으로서 그리고 복구 불가능한 것으로서 검출될 수 있다. 이 장치는 블랙 리스트에 올라가며, 추가의 액세스 시도들이 차단된다. 추가의 예에서, SeGW는 검증 결과를 Dev_ID 및 TrE_Info와 함께 DMS에 전송한다. DMS는 그 장치를 복구하기 위해 적절한 업데이트들/소프트웨어 변경들을 제공할 수 있다. SeGW는 업데이트에 대해 통지받고, 그 장치의 재검증을 트리거할 수 있다. 만일 업데이트들이 성공적으로 적용되면, 검증이 성공하게 되고, 네트워크 액세스가 허가될 수 있다.

상기 블랙 리스트 방법은 격리 네트워크와 함께 이용될 수 있다. 이는 오퍼레이터들로 하여금, 이를 테면 가능한 경우 OTA를 통해 업데이트를 제공함으로써, 장치에 대한 접속을 이용할 수 있게 한다. 대안적으로, 블랙 리스트를 이용하여, 장치들을 완전히 차단할 수도 있다. 예를 들어, 장치들이 OTA 조치들에 의해 복구될 수 없다면, 이러한 장치들은 인필드 교체/서비스에 의해 처리되어야 한다.

다른 장치들은, 이들이 그레이 리스트(grey-list)에 올라있는 경우, 격리될 수 있다. 이러한 그레이 리스트는, 예를 들어 네트워크에 새로 들어온 장치들(다른 MNO로부터 온 것들); 연장된 시간 기간 동안 접속되지 않은 장치들; 의심스러운 행동을 하는 장치들; 및 (벤더들 및 독립적인 리서처들에 의한) 보안 경고가 존재하는 장치들을 포함한다.

여기에서는, 파라미터 검증의 예들에 대해 설명한다. PVM 동안, 검증 결과들은 로드된 컴포넌트들에 대한 구성 파라미터들에 의존할 수 있다. 이러한 파라미터들은 빈번하게 변경될 수 있고, 그렇지 않으면 동등한 장치들 사이에서 달라질 수 있기 때문에, PVM의 기본 실시예는 파라미터들이 검증 동안 보통문으로(in clear) 전송될 수 있게 한다. 하지만, 이는 장치 상에서 그리고 검증기 측에서, 완전한 파라미터 데이터베이스 및 기록들을 유지할 것을 요구할 수 있다. 이는 다음의 영향들을 갖는다: 1) 파라미터 세트들은 큰 데이터베이스 공간들을 차지하며, 이들이 평가될 때 검증의 속도를 느리게 할 수 있으며; 그리고 2) 장치 마다 저장 및 평가되는 큰(high) 수의 파라미터들은, 밖으로 누설되는 경우, 장치 구성에 대한 많은 것을 제 3 당사자에게 폭로할 수 있다.

PVM 프로세스에 파라미터들을 포함시키는 하나의 방법은, 파라미터의 해쉬 함수 결과들을 컴포넌트의 측정에 연관시킴으로써, 해쉬 값들을 확장시키는 방법에 기초한다. 파라미터 다이제스트 값이 컴포넌트의 파라미터 값들의 직렬화 및 바이너리 표현으로 얻어지며, 이렇게 되면 그 컴포넌트의 기존의 측정 값은 이러한 파라미터 다이제스트 값에 의해 확장된다. 이에 따라, 검증을 위해, 모든 측정 및 기준 값들, RIM들 및 RIMc들은 유사한 방식으로 처리됨으로써, 파라미터 검증의 다양한 구현을 이끌 수 있게 된다.

증명서들(예를 들어, X.509) 및 속성 증명서들(attribute certificates)(이를 테면, 파라미터들과 유사하게 보여지는 속성들)의 관계에 있어서의 유사한 문제(이는 기준 메트릭들 및 RIMc들 내에 파라미터들을 포함시킴으로서 해결될 수 있다)는, 여기에서 "속성 증명서들에 대한 리기드(Rigged) 해쉬 값들"로 나타낸다.

여기에서는, 진단 검증(diagnostic validation)의 예들에 대해 설명한다. PVM 개념들에 기초하는 검증에 대한 일 실시예는, 장치에 RIM들을 갖지 않으면서 컴포넌트들이 로드될 수 있게 하는 옵션을 포함한다. 비보안(non-security)의 중요 소프트웨어가 장치 상에 배치되고, 특정의 컴포넌트를 로드할 정도로 충분히 안전한 것이 가능하지만, 네트워크는 변화를 인식할 필요가 있다. 다른 실시예에서, MNO는, 특정의 컴포넌트들은 (예를 들어, 빈번한 변경으로 인해) 항상 장치에 의해 측정되지만, 검증은 네트워크에 의해 일어난다는 방침을 세울 수 있다. 또한, 이것은, 장치가 알려지지 않은 컴포넌트를 로드 및 측정하고, 네트워크에 대해 검증 작업들을 남겨두는 디폴트 액션(default action)이 될 수 있다. 네트워크는 장치를 격리되게 할 수 있는 바, 이에 의해 그 장치의 원격 OAM 복구를 가능하게 한다. 예를 들어, 장치는 본래의 상태로 되돌아가고, 컴포넌트들을 제거하거나, 다른 조치들을 취할 수 있다.

여기에서는, 실패 조건 F2a의 PVM 진단의 일 예를 설명한다. PVE가 F2a에 실패한 컴포넌트들의 리스트를 DMS에 전송하지 않는 경우, 실패한 컴포넌트들은 다음과 같이 발견될 수 있다. 예를 들어, 장치는 RIM들과의 비교를 위해 PVE에 제시될 수 있는 SML을 보유하지 않을 수도 있다. 이 경우, DMS는 실패한 장치 상의 컴포넌트들을 교체하는 것을 실제로 생략할 수 있지만(왜냐하면 이들을 알지 못할 수 있기 때문이다), 오로지 통상의 관리 절차에서 Clist 내의 모든 컴포넌트들 만을 정확한 것들로 교체한다. 재식작 및 재검증시, 장치는 또한, 내부 검증에 실패했기 때문에 로드되지 않은 컴포넌트들의 리스트를 검증 메시지 내에 포함시킬 수 있다. PVE는 이전 검증의 Clist와 RIM 업데이트 이후의 것을 비교함으로써 이러한 진단까지도 할 수 있다. 현재 누락된 컴포넌트들은, 이들이 정확한 RIM들에 대해 국부적으로 검증될 때, 보안 스타트업시에 로드되지 않는다. 따라서, 누락된 컴포넌트들은 교체를 필요로 하는 것들이다. 이후, 실제 교체를 필요로 하는 컴포넌트들은 두 번째의 관리 사이클에서 교체될 수 있다.

진단 검증을 수행하는 다른 방법은, 장치가 컴포넌트를 로드할 수 없음(예를 들어, RIM이 누락되거나 잘못됨)을 보고하고, 그 컴포넌트의 측정 값을 CN에 전송하는 경우에 가능하다. MNO의 방침에 의존하여, OAM 복구 프로세스는 그 컴포넌트를 제거 또는 복구하도록 트리거될 수 있다. 다른 변형은, TrE가 컴포넌트에 대한 RIM이 누락되었거나 잘못되었음을 검출하는 경우, 장치로 하여금 OAM 복구를 직접 요청할 수 있게 한다.

부가적인 방법은 컴포넌트들을 디스에이블시키는 것인데, 이러한 컴포넌트들은 장치에 대한 접속을 거부하지 않으면서, 검증될 수 없으며, PVM에서 교체/업데이트될 수 없다. 이 경우, DMS는 컴포넌트들에 대한 "디스에이블 CInd" 메시지를 전송하고, 그 장치의 재검증을 트리거할 수 있다. 이는 알려지지 않은 컴포넌트들이 로드되는 경우에 적용될 수 있다.

다른 방법은, DMS로 하여금 어떤 컴포넌트들이 특정 장치 상에서 허용되는 지를 특정하게 할 수 있다. 장치가 보안 스타트업 동안, (예를 들어, 보안 결함이 최근에 발견되어, 어떠한 업데이트도 아직 이용가능하지 않은 이유로) 허용되지 않은 컴포넌트들을 포함하여, 모든 컴포넌트들을 로드하고 검증한다면, DMS는 SeGW를 통해 장치에 메시지를 전송하며, 이 장치는 그 컴포넌트를 디스에이블시킬 수 있다. 이 장치는 재검증하도록 요청된다. 만일 재검증 동안 컴포넌트가 로드되지 않으면, DMS는 이를 SeGW에 시그널링하며, SeGW는 인증/검증이 완료될 수 있게 한다.

여기에서는, 최소 검증 방침에 대한 예들이 설명된다. 스타트업 시간 동안 컴포넌트들의 측정(예를 들어, PCR 값들의 확장 및 Clist가 생성되는 SML에 측정들을 기록하는 것)은 스타트업 절차에 있어서 약간의 지연을 발생시키기 때문에, 최소 검증 방식은 단지 특정의 환경들 하에서만 장치 검증을 요구한다. RIM들 및 저장된 측정 값들(예를 들어, PCR 값들)은 부분적으로 동일한 또는 리던던트 정보를 전달하기 때문에, 이러한 리던던시를 제거하게 되면 메시지 및 저장 용량을 세이브할 수 있다.

로컬 무결성 측정, 검증 및 시행 프로세스가 (예를 들어, 보안 스타트업에 의해) 장치 상에서 확립된다면, 이러한 로컬 검증 프로세스에서 이용되는 RIM들 만을 전송하는 것으로도 충분할 수 있는데, 왜냐하면 검증 데이터(예를 들어, PCR 값들)은 RIM 그 자체와 동일한 정보를 포함할 수 있기 때문이다. 따라서, 최소 검증은 검증 데이터를 전송하지 않고, 단지 로컬 검증 프로세스에서 이용되는 기준 값들 만을 전송할 수 있다. 다른 변형에서는, RIM들을 전송하는 대신, 이러한 RIM들이 고유의 식별자들을 갖는 경우 및 이러한 경우에만, RIM들에 대한 표시자들 만을 전송할 수 있다.

최소 검증에 대한 2개의 요건들은 다음을 포함한다: 1) 로컬 측정, 검증 및 시행(measurement, verification and enforcement, MVE) 프로세스는 신뢰성이 있고; 2) 장치 상에 저장된 RIM들에 대한 RIM 소스는 신뢰성이 있다. 로컬 MVE 프로세스에 대한 검증 데이터를 평가를 위해 외부 엔티티에 보고하는 것이 가능하다. 이것은 명시적인 신뢰 확립을 위한 것이다. MVE 프로세스는 이것이 손상되지 않도록 구현될 수 있다. 장치가 RIM들을 이후에 보고한다는 사실은, MVE 프로세스가 신뢰성이 있음을 의미한다. 이것은 암시적인 신뢰 확립을 위한 것이다.

보고되는 RIM들의 신뢰성을 평가하기 위해, 벤더들, 다른 MNO들, TTP들 및 다른 당사자들에 의해 서명되는 RIM 증명서들이 대신 전송될 수 있다. 만일 RIM 증명서의 서명자가 신뢰성이 있다면, RIM은 신뢰성이 있는 것으로 고려된다. 보고되는 RIM들 중 임의의 RIM이 신뢰되지 않는 다면, 장치를 격리 네트워크에 넣거나 또는 블랙 리스트에 올리는 것과 같은 조치들이 적용될 수 있다.

RIM들 및 검증 데이터의 리던던시를 조정함으로써 효율을 얻을 수 있다. 이를 테면, 장치들은 특정의 조건들 하에서만, 또는 특정의 주파수들 하에서만, 검증 데이터를 전달하도록 요구될 수 있다. 예를 들어, 손상된 RIM들이 PVM 시스템에 의해 검출되면, 새로운 장치가 이러한 오퍼레이터들의 영역 내로 로밍되거나, 또는 SHO가 잠시 동안 이 장치를 보지 못한다. 다른 예에서, 검증의 전달은 'N'번의 검증들 마다 단지 한번 요구될 수 있다.

여기에서는, PVM과 이용하기 위한 교정의 예들에 대해 설명한다. 교정 또는 소프트웨어 업데이트는 디바이스의 계속된 서비스를 위해 필요한 동작이 될 수 있다. 장치가 교정을 필요로 하는 많은 이유들이 있다. 소프트웨어 업그레이드, 버그 수정(bug fix) 및 인핸스먼트의 정기적인 유지 점검 이외에, 교정은 장치의 일반적인 보안 프로세스의 필수적인 부분이 될 수 있다. 검증 절차 동안, 장치 상의 소프트웨어가 측정되어 그 무결성에 대해 검증된다. 이러한 측정들은 TrE에 위치하는 RIM들과 비교된다. 검증이 실패하면, 코드가 탬퍼링된 것이거나, 또는 그 특정의 코드 베이스에 대한 RIM들이 부정확한 것이다. 교정 절차들은, 장치의 적절한 검증을 보장하기 위해, 코드 베이스 또는 RIM들을 업데이트하도록 개시될 수 있다.

하나 이상의 컴포넌트들에 대한 장치 무결성 체크가 실패하면, 이는 이러한 컴포넌트들이 손상되었거나, 또는 해당하는 신뢰성있는 기준 값들이 장치 상의 코드 베이스와 맞지 않음을 의미한다. 교정 절차들은, 장치가 SeGW에 대해 인증할 수 없음을 적어도 CN에게 나타내고, 그리고 가능하게는 코드 베이스 또는 설치된 코드 베이스에 해당하는 새로운 신뢰성있는 기준 값들의 네트워크 개시 업데이트를 용이하게 하도록 개시될 수 있다. 교정은 SeGW를 통해 DMS와 장치 간에 이루어질 수 있다.

임의의 교정의 개시를 위해, 어떠한 공통의 보안 요건들이 적용된다. 이들은 실패가 발생하는 보안 스타트업 프로세스의 스테이지에 의해 결정된다. 고려되는 최악의 경우는 보안 스타트업의 스테이지 2에서의 실패인데, 이는 TrE가 구축되지만, 외부 엔티티에 대한 어떠한 접속도 갖지 않음을 나타낸다. 따라서, 통상의 스타트업에 있어서, 장치는 이러한 상황에서 교정을 요청할 수 없다. FBC와 같은 부가적인 코드 베이스가 TrE 내에 안전하게 로드되어, 교정을 수행하는 데에 이용될 수 있다. 이러한 프로세스에 대한 보안은 다음에 의해 특징화된다: 1) FBC는 완전하게 로드되고, TrE 내로 변경되지 않을 수 있고; 2) TrE는 FBC를 안전하게 실행할 수 있고; 3) DMS와 같은 네트워크 엔티티와의 교정을 위한 통신이 무결성 및 비밀유지에 있어서 안전할 수 있으며; 그리고 4) 네트워크로의 교정 액세스에 대한 크리덴셜들이 프로세스 전체에 걸쳐서 보호될 수 있다. 대안적으로, FBC는 TrE 내에 로드될 필요가 없다. FBC는, 예를 들어 교정의 단일 목적을 위해 다른 (신뢰성있는) 코드 베이스로서, TrE와 공존할 수 있다. FBC에 있어서의 신뢰는, 이것이 보장 저장소에 저장되거나 또는 HW 보안 시크릿들에 의해 보호된다는 사실로부터 비롯된다. 이 때문에, TrE는 FBC를 실행시킬 필요가 없다. FBC는 자립형(self-standing)이며, TrE를 확립하지 않으면서 실행될 수 있다.

여기에서는, 장치에 의해 개시되는 교정(즉, 장치 개시 교정)의 일 예를 설명한다. 장치 검증의 범위 내에서, 교정은 에러들의 검출시 장치를 즉시 격리시키는 것에 대한 대안이 될 수 있다. 자율적인 검증의 경우, TrE는 검증되는 첫 번째 스테이지이다. 정확하게 검증되면, 이는 장치가 보안 스타트업의 미리 정의된 상태를 달성했음을 나타낸다. 이는, TrE가 신뢰성이 있고, 이 TrE에 저장된 RIM들이 신뢰성이 있음을 의미한다. 하지만, 이것은, RIM들이 장치 상에 현재 로드되어 있는 특정 버전의 코드에 대해 정확하다는 것을 나타내지는 않는다.

여기에서는, 네트워크에 의해 개시되는 교정(즉, 네트워크 개시 교정)의 일 예에 대해 설명한다. 자율적인 검증의 경우, 장치가 검증 절차들에 실패하면, FBC는 RIM들을 포함하는 주요 코드 베이스의 소프트웨어 업데이트를 트리거하도록 개시될 수 있다. 장치는, 이 장치가 폴백 모드에서 실행되고 있고, 즉각적인 교정을 필요로 하고 있음을 나타내는 통지 페이로드를 갖는 IKEv2 메시지를 전송할 수 있다.

반 자율적인 검증 방법에 있어서, 교정 절차들은 소프트웨어 또는 신뢰성있는 기준 값(TRV)들의 완전한 업데이트를 반드시 수반하지는 않는다. 장치가 스테이지 1 및 2 검증은 통과했지만, 스테이지 3을 실패하는 경우, 실패한 모듈들에 대한 정보가 통지 페이로드 또는 IKEv2 프로토콜 내의 증명서를 통해 PVE에 반환된다. 만일 PVE가 이러한 실패한 모듈들을 중요하지 않은 것으로서 고려하면, 디스에이블/언로드된 이러한 실패한 모듈들에 대해 검증 및 인증이 계속될 수 있다. 하지만, 실패한 모듈들이 중요한 것이라면, PVE는 교정이 필요함을 나타내는 정보를 DMS에 전송할 수 있다.

다른 시나리오는, TRE 내에 저장된 RIM들이 특정의 코드 베이스에 대해 부정확한 것이 될 수 있다. 실패한 측정들은 PVE에 반환될 수 있으며, 여기에서의 정보의 분석은, RIM들 내에 에러가 있고, 오로지 이러한 값들 만이 TRE 내에서 안전하게 업데이트될 필요가 있음을 나타낸다.

여기에서는, 디스트레스 신호(distress signal) 및 폴백 코드의 예들 및 실시예들에 대해 설명한다. 장치는 폴백 코드(FBC) 이미지를 갖추고 있을 수 있는데, 이러한 FBC 이미지의 목적은, 장치가 장치 무결성 검증에 실패하는 경우, 장치의 교정이 이루어지도록 촉진시키는 것이다. FBC는 판독 전용 메모리(ROM)와 같은 보안 메모리에 저장될 수 있다. FBC는, 로컬 장치 무결성 검증이 실패하는 경우 호출(invoke)될 수 있다. FBC는 영향을 받은 장치에 대한 교정을 담당하는 CN 내의 엔티티와 통신하는 데에 필요한 모든 필요 기능들, 방법들 및 크리덴셜들을 적어도 포함할 수 있다. 또한, FBC는 네트워크로부터 완전한 소프트웨어 업데이트를 수신하는 데에 필요한 기능들을 포함할 수 있다. 특별한 '교정' DMS가 고려될 수 있다.

장치 및 TrE는, 장치 무결성 체크가 실패하면, 다음의 교정 지시 절차들을 수행할 수 있다. 첫 번째로, TrE는 폴백 코드(FBC)로서 알려져있는 신뢰성있는 코드의 실행을 개시할 수 있다. FBC는 ROM과 같은 보안 메모리에 저장될 수 있다. 두 번째로, FBC는 미리 지정된 '교정' DMS에 대한 보안 접속을 설정할 수 있다. 세 번째로, FBC는 장치 ID를 포함할 수 있는 디스트레스 신호를 DMS에 전송할 수 있다. DMS는, 이러한 디스트레스 신호를 수신하면, 장치가, 예를 들어 무결성 체크에 실패했으며, 유지 관리를 필요로 한다는 것을 알 수 있다. 선택적으로, 이러한 신호를 수신하면, DMS는 완전한 펌웨어 업데이트 절차를 개시하거나, 또는 진단을 수행하여 부분적인 코드/데이터 업데이트를 수행할 수 있다.

여기에서는, RIM들이 없는 검증의 예들에 대해 설명한다. RIM들이 없는 검증은, 컴포넌트 코드를 로드시 TrE의 제어하에서 보안 메모리 카드들과 같은 보안 저장소에 안전하게 전송하는 것을 포함할 수 있다. RIM들이 없는 검증은 또한, 통상의 메모리 내에 코드와 같은 암호화된 컴포넌트들을 저장하기 위해, 다이제스트 값들을 암호화로 교체하는 것을 포함할 수 있다. 이는 또한, TrE에 의해 보호되고 DMS와 공유되는 키, 또는 비대칭적인 암호 알고리즘으로부터 도출되는 암호화 키들에 의한 암호화를 포함할 수 있으며, 여기서 DMS 및 TrE는 공개키와 개인키의 쌍들을 가질 수 있다. 암호화된 코드는 목표로 하는 변경들을 허용하지 않을 수 있다. 코드의 임의의 조작은, 보안 스타트업의 변형에서와 같이, 복호화시에 검출될 수 있는데, 왜냐하면 탬퍼되는 데이터의 복호화는 넌센스(nonsense)를 야기하기 때문이다. 이러한 변경들의 검출은 암호화된 코드 내에 다이제스트 값들을 포함시킴으로써 달성될 수 있다. 에러 정정 코드들과 같은 다른 옵션들이 적용될 수도 있다.

여기에서는, 검증 프로세스에 위치 기반 정보를 포함시키는 예들에 대해 설명한다. 일부 장치들이 응용 시나리오들에서 이용될 수 있는 바, 여기에서 위치 기반 정보는 절도 보호, 화물 추적(cargo tracking), 함대 모니터링(fleet monitoring) 또는 감시(surveillance)와 같은 중요한 역할을 한다. 전형적으로, 장치는 지리적인 위치 데이터를 제공하기 위해 위성 위치 확인 시스템(GPS) 모듈을 갖추고 있을 수 있다. 그러면, 보안 스타트업은 GPS 모듈 및 컴포넌트들을 포함함으로써, 위치 기반 정보의 신뢰성있는 발생 및 저장을 보장할 수 있다. 또한, 위치 데이터는 TrE 보안 저장소에 안전하게 저장될 수 있다. 그런 다음, 위치 정보는 검증 메시지 내에 포함될 수 있다. 이는, 예를 들어 보고되는 위치가 요구되는 위치와 매치하지 않는 경우, OAM 절차들에 의해 장치 구성을 변경하는 데에 이용될 수 있다. 장치가 새로운 위치를 보고하는 경우, 그 구성은 다른 파라미터들을 이용하여 네트워크에 접속하고, 로깅(logging), 리포팅 또는 셧다운과 같은 소프트웨어 이벤트들을 트리거하도록 변경될 수 있다. 위치 정보는 신뢰성있는 애플리케이션에 의해 안전하게 처리되는 것으로 추정될 수 있다.

여기에서는, 기존의 그리고 표준화된 네트워크 엔티티들, 프로토콜들 및 메커니즘들에 대한 일반적인 PVM 아키텍쳐의 맵핑을 제공하는 H(e)NB 및 M2M 시나리오들에 대한 PVM의 응용들 및 실시예들에 대해 설명한다. 양 응용들은 특정한 보안요건들을 제시한다. 양 응용들에서는, 공통적으로, i) 장치들은 더 이상 중요 데이터(sensitive data)의 저장 및 처리를 위한 폐쇄된 불변의 환경들로서 고려되지 않는데, 왜냐하면 전형적으로 이동 햇드셋들이 고려되기 때문이며; 그리고 ii) 이러한 특별한 장치들은 이동 네트워크 오퍼레이터(MNO)와 다른 책임자에 의해 제어되며, 일반적으로, 비보안 링크(insecure link)를 통해 코어 네트워크에 단지 간헐적으로 접속된다.

제 1 응용은 펨토셀(femtocell)들로서 더 잘 알려져있는 H(e)NB들에 관한 것이다. H(e)NB는 (이동 전화들과 같은) 단말 장치들에게 3G 네트워크들에 대한 액세스 접속을 제공하는 소형의 휴대용 액세스 포인트이다. 일반적으로, H(e)NB는 HP(Hosting Party)라 불리는 책임자의 홈 내에 또는 구내에 배치된다. HP는 지정된 작은 지리적인 영역 내에서의 이동 통신 및 서비스들을 위한 매개자(mediator)가 될 수 있다. 이는 인하우스(in-house) 또는 공장 환경들과 같이 (불량한 무선 조건들로 인해) 지금까지 액세스 불가능했던 영역들 내에 이동 서비스들을 제공하는 데에 이용될 수 있다. 이는 또한 개인적인 가족들 및 SOHO(small office home office) 섹터에 대한 옵션인데, 왜냐하면 H(e)NB는 광대역 인터넷 및 이동 네트워크들에 대한 단일화된 액세스 포인트가 될 수 있기 때문이다.

H(e)NB 이용 시나리오들에서는, 3개의 책임자들, 사용자들-HP-MNO가 서비스 레벨 및 이용 협정에 의해 관련된다. 이러한 환경에서, H(e)NB는, 예를 들어 이동 네트워크 가입으로서 구현되는 HP의 인증 데이터, CSG(Closed Subscriber Group)로서 저장되는, H(e)NB에 대한 접속이 허용되는 무선 송수신 유닛(WTRU) 또는 사용자 장비(UE)의 리스트, 및 액세스 제어 리스트(ACL)와 같은 많은 중요 데이터를 저장한다. 이러한 데이터의 일부는 HP 및/또는 사용자들에 개인적일 수 있다. 또한, H(e)NB의 위치는, 간섭으로부터 이동 네트워크를 보호하고, 서비스들의 위법적인 확장을 막도록 제어될 필요가 있다.

도 7은 H(e)NB(705), WTRU 또는 UE(710)와 오퍼레이터 코어 네트워크(730) 간의 예시적인 통신 시나리오를 도시한다. 이는 2개의 네트워크 엔티티를 도입하는 바, 그중 하나는 보안에 관련된 일을 하고, 나머지 하나는 H(e)NB의 서비스와 관련된 일을 한다. OAM(Operation, Administration and Maintenance)(735)은 H(e)NB(705)에 원격 관리 기능을 제공하는 코어 네트워크의 백홀의 기능이다. 이는 특히, 소프트웨어 다운로드 및 업데이트, 무선 및 기타 파라미터들의 설정, 및 기타 유사한 기능들을 제공한다. 보안 게이트웨이(SeGW)(740)는 오퍼레이터의 코어 네트워크(730) 내로의 H(e)NB(705)에 대한 주요 엔트리 포인트이며, 그 주요 목적은 불법 접속 시도, 및 불량한 H(e)NB들 또는 H(e)NB를 위장(impersonation)하는 공격자들로부터 비롯될 수 있는 모든 타입의 공격들로부터 네트워크(730)를 보호하는 것이다.

의도되는 제 2 응용은 M2M 통신에 관한 것이다. M2ME(M2M Equipment)에 대한 전형적인 예들은 벤딩 머신 및 티켓팅 머신이다. 보다 진보된 시나리오들은, 특히 복합 열 전력 발전소들의 원격 계량(remote metering), 머신 유지 보수 및 설비 관리를 포함한다. M2ME가 이동 네트워크를 통해 백업 시스템들에 연결되어 있다면, MNO들이 M2ME 보유자들에게 부가 가치 서비스들을 제공할 수 있게 됨으로써, OTA 관리를 시작한다. H(e)NB들과 마찬가지로, M2ME는 MNO와 다른 책임자에 의해 제어된다. 이러한 책임자는 특정의 보안 요건들을 갖는데, 이들은 MNO의 것들과 다를 수 있다. H(e)NB 및 M2ME의 보안이 문제이다. 각각의 위협들, 위험들 및 수반되는 보안 요건들은 양 경우에 대해 유사하다.

위협들은 6개의 상위 그룹으로 분류될 수 있다. 그룹 1은 크리덴셜들을 손상시키는 방법들로 이루어진다. 이는 토큰들 및 (약한) 인증 알고리즘들에 대한 브루트 포스(brute force) 공격들, 물리적인 침입, 사이드 채널 공격들, 및 인증 토큰을 복제하는 악의적인 호스팅 당사자를 포함한다. 그룹 2는 조작된 장치 내로의 유효한 인증 토큰의 삽입, 불법 소트트웨어에 의한 부팅("리프레싱(re-flashing)"), 물리적인 탬퍼링 및 환경적/사이드 채널 공격들과 같은 물리적 공격들로 이루어진다. 그룹 3은 불법 소프트웨어 업데이트/구성 변경들, HP 또는 사용자에 의한 잘못된 구성, ACL의 잘못된 구성 또는 손상과 같은 구성 공격들로 이루어진다. 그룹 4는 장치에 대한 프로토콜 공격들로 이루어진다. 이러한 공격들은 기능을 위협하며, HP 및 사용자들에게 불리하게 지시된다. 주요 예들로는, 첫 번째 네트워크 액세스시의 MITM(man-in-the-middle) 공격들, DoS(denial-of-service) 공격들, 액티브 네트워크 서비스의 약점들을 이용한 장치의 손상, 및 OAM과 그 트래픽에 대한 공격들이 있다. 그룹 5는 코어 네트워크에 대한 공격들로 구성된다. 이들이 MNO에 대한 주요 위협들이다. 이들은 장치들의 위장, 이들 간의 트래픽 터널링, 모뎀/라우터 내의 방화벽의 잘못된 구성, 및 코어 네트워크에 대한 DoS 공격들을 포함한다. H(e)NB의 경우, 이는 또한 허락되지 않는 방법들로 위치들을 변경하는 것과 관련된다. 마지막으로, 이는 불량 장치를 이용한 무선 액세스 네트워크에 대한 공격들을 포함한다. 그룹 6은 사용자 데이터 및 아이덴티티 프라이버시 공격들로 이루어지는 바, 이들은 다른 사용자의 UTRAN(Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network) 또는 E-UTRAN(Evolved UTRAN) 액세스 데이터의 도청(eavesdropping), 사용자의 네트워크 ID가 H(e)NB 소유자에게 유출된 다른 사용자들로서 가장(masquerading)하는 것, 유효한 H(e)NB로서 가장하는 것, 및 CSG에 대해 무선 액세스 서비스를 제공하는 것을 포함한다.

H(e)NB 및 M2ME 모두에 대해 새로운 중요한 기능 요건들은 주로 다른 책임자들의 인증, 및 이들 간의 기능들 및 데이터의 분리, 즉 도메인 분리와 관련된다. 특히, HP 또는 M2ME 소유자의 확실성은 네트워크에 대한 장치 인증과 독립적으로 이루어질 수 있다. 또한, HP의 비밀 데이터는 다른 당사자에 의한 액세스로부터 보호되어야 하는 바, 심지어 MNO에 의한 액세스로부터도 보호되어야 한다. 장치는 보안에 민감한(security-sensitive) 작업들을 수행하고, 액세스 네트워크 및 접속된 WTRU 모두에 대해 보안 방침들을 시행해야 한다. 이것은 적어도 반 자율적인 방식으로 가능해야 하는데, 이는 서비스의 연속성을 제공하고, 백홀 링크 상에서의 불필요한 통신을 피하기 위해서이다. 다른 중요 보안 영역은 OAM 또는 OTA 각각에 의한 원격 관리이다. 장치는 소프트웨어 업데이트, 데이터 및 애플리케이션들을 안전하게 다운로드 및 설치할 필요가 있다.

코어 네트워크에 대한 변경을 동시에 최소화하면서, 인증 역할들을 분리하고, 이에 따라 EAP-AKA(Extensible Authentication Protocol - Authentication and Key Agreement)와 같은 표준 3G 인증 프로토콜들을 재사용할 것이 요구된다. 지금까지 고려된 시도들은 HP 및/또는 M2M 소유자에 대한 개별적인 인증 베어러들을 포함한다. 이들은, HP에서 소위 HP 모듈(HPM)로 구현되거나, M2M의 경우 MID(managed identity)들로서 구현될 수 있다. 양쪽 모두 UICC(Universal Integrated Circuit Card)들, 즉 3G SIM(Subscriber Identity Module) 카드들에 대한 가명들이 될 수 있다. M2M의 경우, 착탈가능한(removable) 스마트 카드들의 이용에 대한 다양한 보안상의 우려가 제기되었다. 한편, 예를 들어 업데이트들 또는 오퍼레이터 변경에 대해, 이러한 스마트 카드들의 교환을 필요로 하는 유지 동작은 피해야하는데, 왜냐하면 이것은 지역적으로 흩어져있는 M2ME의 큰 무리에 대해 비용이 매우 많이 들기 때문이다. 최근에 조심스럽게 고려되는 다른 옵션은 장치 내의 보안 환경에 AKA 크리덴셜들을 다운로드하는 것이다. 이러한 옵션을 가능하게 하는 순수 TC 기술을 이용하는 하나의 가능한 방식은 가상(virtual) SIM이다.

어느 경우이든, 보안 요건들 및 진보된 OTA 또는 원격 관리는 M2ME 및 H(e)NB들에 대한 특정의 보안 특징들을 요구한다. TrE가 이러한 목적들을 위해 이용될 수 있다. TrE는 시스템의 다른 부분들과 안전하게 상호작용을 할 필요가 있다. 이러한 TrE 인터페이스들을 살펴보는 것이 흥미로운데, 왜냐하면 이들은 TS의 TCB가 어떻게 플랫폼의 나머지 것들과 통신하는 지에 대한 일반적인 모델이기 때문이다. 기본적으로, 모든 TrE 인터페이스들은 TrE의 보안 스타트업 프로세스에서 초기화되며, 이에 따라 정확하게 동작하는 것으로 추정된다. TrE 인터페이스들의 2개의 일반적인 카테고리가 있다. 첫 번째로, 보호되지 않는 인터페이스들이 있다. 이러한 인터페이스들은 탬퍼링 및/또는 도청에 대해 안전한 것으로 추정되지 않는 장치의 일반적인 자원들을 갖는 TrE를 허용한다. 심지어 보호되지 않는 인터페이스들도, 데이터 암호화, 또는 예를 들어 보안 부트 동안, TrE가 인터페이스를 가로질러 대응되는 자원의 코드를 체크한 이후에만 인터페이스를 이용가능하게 하는 것과 같은 다른 보안 조치들로부터 이득을 얻을 수 있다.

두 번째로, 보호되는 인터페이스들이 있다. 이러한 인터페이스들은, 보안 프로토콜들 또는 보안 하드웨어를 이용하여, 무결성 보호 및/또는 이러한 인터페이스들 간에 전달되는 데이터의 기밀성을 제공한다. 만일 보안 프로토콜들이 이용된다면, 이들은 인증, 메시지 인증 및/또는 기밀성을 또한 제공할 수 있다.

보호되지 않는 인터페이스들은, 통신 엔티티가 통신되는 데이터의 보호를 제공하지 않을 때에 선택될 수 있다. 보호되는 인터페이스들은, TrE와 TrE가 통신할 필요가 있는 다른 자원들 간에 기밀성 및/또는 데이터 무결성의 보호를 제공할 필요가 있을 때에 선택될 수 있다. 이에 따라, TrE의 성능들은 달라질 수 있다. 도 8은 H(e)NB 내의 TrE 및 이것이 어떠한 다른 자원들에 연결될 수 있는 지에 대한 일 실시예를 도시한다. 이것은 H(e)NB의 장치 인증에 필요한 파라미터들을 계산하여 SeGW에 전송하는 성능, 부트시 H(e)NB의 나머지 부분의 코드-무결성 체크를 포함하는 H(e)NB 검증을 위한 기능들, 및 최소의 암호(crypto) 성능들(TRNG)(true random number generator)을 포함하는 최소 구성이다. 인증과 관련하여, TrE가 HPM(Hosting Party Module)을 포함할 수 있는 것이 고려된다.

일반적인 PVM 디스크립션(description)의 아키텍쳐는 기존의 H(e)NB 아키텍쳐에 용이하게 맵핑될 수 있다. 데이터베이스들(V_DB 및 C_DB) 및 이들의 관리 컴포넌트들은 기존의 H(e)NB 인프라구조에 대해 새롭다. 도 9a 및 9b는 SeGW를 통한 H(e)NB 접속 및 인터페이스 I-hms_d를 통한 HMS로의 H(e)NB의 직접 접속을 나타낸다.

도 9a의 PVM 아키텍쳐 또는 시스템(900)은 TrE(910)를 갖는 H(e)NB(905)를 포함한다. WTRU(또는, 사용자 엔티티(UE))(912)는 I-ue 인터페이스(914)를 통해 H(e)NB(905)와 통신할 수 있다. H(e)NB(905)는 I-h 인터페이스(915)를 통해 H(e)NB 게이트웨이(GW)(918)와 통신하며, 이 H(e)NB 게이트웨이(918)는 SeGW(920)를 포함한다. 일반적으로, H(e)NB(905)와 SeGW(920) 간의 I-h 인터페이스(915)는 보호되지 않으며, 확실성, 무결성 및 선택적으로 기밀성에 대해 이러한 채널을 안전하게 하기 위한 특별한 조치들이 적용될 수 있다. I-h 인터페이스(915)는 H(e)NB(905)와 SeGW(920)와의 사이에, 이에 따라 CN과의 사이에 링크를 확립하는 데에 이용될 수 있다. 예를 들어, SeGW(920)는 I-aaa 인터페이스(975)를 통해 AAA 서버와 통신할 수 있다. 오퍼레이터는 인터페이스들의 보안을 보장하기 위한 적절한 조치들을 취할 수 있다.

검증 동안, SeGW(920)는 I-pve 인터페이스(922)를 이용하여 PVE(924)를 컨택할 수 있다. PVE(924)는 I-pve 인터페이스(922)를 이용하여 SeGW(920)에 검증 결과를 시그널링할 수 있다. I-dms 인터페이스(930)는 H(e)NB 관리 시스템(HMS)(935)과 SeGW(920) 간의 장치 구성 관련 통신에 이용될 수 있다. PVE(924)는 I-pd 인터페이스(932)를 이용하여 HMS(935)와 통신할 수 있으며, HMS(935) 역시 I-pd 인터페이스(932)를 이용하여 PVE(924)와 통신할 수 있다. 이러한 I-pd 인터페이스(932)는, 소프트웨어 업데이트들 및 구성 변경들과 같은 장치 관리 절차들 동안 이용될 수 있다.

인터페이스들 I-v(926) 및 I-d(938)는, PVE(924)에 의해 V_DB(940)로부터 RIM들을 판독하고, HMS(935)에 의해 C_DB(950)로부터 허가된 구성들을 판독하는 데에 각각 이용될 수 있다. 인터페이스들 I-r(928) 및 I-c(934)는, 이를 테면 V_DB(940)에서 RIM들이 누락되는 경우, PVE(924)에 의해 RIMman(960)과 통신하고, HMS(935)에 의해 CPman(970)과 통신하는 데에 각각 이용될 수 있다. RIMman(960) 및 CPman(970)는 각각 I-rdb 인터페이스(962) 및 I-cdb(970)를 이용하여, 각각 검증 데이터베이스(V_DB)(940) 및 구성 방침 데이터베이스(950)를 읽고, 기록하고, 관리할 수 있다.

도 9b는 PVM(982)를 도시하는 바, 여기에서는 H(e)NB(905)가 DMS(935)에 직접 연결된다. 예를 들어, 폴백 모드의 경우, H(e)NB(905)는 SeGW와 보안 프로토콜들을 수행할 수 없다. 이 경우, HMS(935)는 인터페이스 I-dms_d(984)를 통해 H(e)NB(905)에 대한 첫 번째 컨택 포인트의 역할을 하며, 그리고 I-pve 인터페이스(986) 및 I-pd 인터페이스(988)를 통해 PVE(924)와 통신하여, 검증을 수행하거나, 또는 적어도 보안 스타트업 동안 어떤 컴포넌트들이 실패했는 지를 알게 된다. HMS(935)는 이러한 정보에 입각하여 교정을 행할 수 있다.

PVE를 이용한 검증은 H(e)NB 시나리오에 다양한 방식들로 직접 맵핑될 수 있다. DMS의 기능들은 HMS, 또는 C_DB를 액세스할 수 있는 적절하게 확장된 엔티티인 eHMS(evolved HMS)에 의해 수행된다.

방침 기반의 업데이트들에 있어서, C_DB는 모듈들의 임계성(criticality) 및 이러한 모듈들의 다양한 릴리스 버전들의 상호 운용성(interoperability)을 특정하는 방침을 제공하는 바, 예를 들어 일부 모듈들은 동작에 대해 임계적일 수 있고, 일부 모듈들은 임계적이지 않을 수 있다. 이는 업데이트의 사이즈를 제한하는 데에 유익하며, 완전한 펌웨어 업데이트 대신 패치(patch)들을 제공한다. 이러한 방침은 H(e)NB의 동작에 임계적인 모든 모듈들을 정의하는 것 만큼 간단할 수 있으며, 이에 따라 완전한 펌웨어 업데이트가 이루어진다.

모듈이 측정에 실패하면, eHMS는 방침을 검사하여, 그 모듈의 임계성 및 모듈들의 상호 운용성에 대한 임의의 영향을 체크한다. 이에 기초하여, 적용가능한 패치들의 리스트가 생성된다. 패치들은 응용을 위한 장치에 집합적으로 또는 개별적으로 전송될 수 있다. 어느 경우이든, 각 전송 단위는 무결성 및 기밀성 보호된다. 링크는 패킷들을 순서대로 그리고 손실없이 전달해야 한다. 요구되는 경우, 종결 패키지(terminating package) 또는 플래그에 의해 eHMS에 의해 표시되는 때와 같이, 모든 패치들을 수신하면, 장치는 수신된 패치들의 리스트를 이들의 측정과 함께 eHMS에 전송하여, 업데이트 정보를 확인하거나, 또는 집합적인 그리고 개별적인 패치 측정이 eHMS에 의해 전송된다면, 패치들의 로컬 검증을 수행하고, 적용을 시작한다. 패치들의 적용 이후, 시스템은 정규 모드(normal mode)에서 부트되며, 장치 검증 프로세스를 시작한다.

이러한 절차는, 제조업자로부터 새로운 펌웨어 릴리스가 있을 때 마다 뒤따라오며, 이에 따라 eHMS는 장치에게 업데이트 통지를 전송하고, 장치는 ECB로 부트하고, eHMS에 측정들을 전송한다. eHMS는 패치들 또는 완전한 펌웨어 업데이트를 제공하며, 동일한 절차가 뒤따른다.

비 방침(non-policy) 기반의 업데이트의 경우, 어떠한 실패한 측정시에, HMS는 보안 링크 상으로 전송되는 완전한 새로운 펌웨어를 제공한다. 장치는 펌웨어를 검증하고, 이를 적용하며, 정규 모드에서 부트시킨다.

이전에 알려진 양호한 상태(good state)의 경우, H(e)NB가 시스템 상태를 저장하는 것을 지원한다면, eHMS는 이 H(e)NB에게 측정에 실패한 패치들이 롤백(roll back)되는 이전에 알려진 양호한 상태로 돌아갈 것을 요구할 수 있다. 이러한 방법은 시스템을 팩토리 상태(factory state)로 되돌리는 데에 이용될 수 있다. 이러한 이전에 알려진 양호한 상태는 PVE, eHMS 또는 S(e)GW에 의해 검증되는 상태가 될 수 있다.

H(e)NB는 이전에 알려진 양호한 상태로 돌아갈 수 있고, 시스템 상태들의 무결성 보호를 제공할 수 있고, 이전에 저장된 시스템 상태들의 복구 동작을 제공할 수 있으며, 그리고 손상된 장치의 경우 이러한 복구 동작을 보호할 수 있어야 한다.

여기에서는, 공중 인터넷(public Internet)을 통해 접속되는 장치들의 검증 예들에 대해 설명한다. 비보안의 최초 링크를 통해 SeGW 및 CN에 각각 접속되는 장치들에 있어서, 검증의 최초 단계들을 안전하게 하기 위해 특별한 요건들이 적용될 수 있다. 이러한 특별한 요건들은 H(e)NB 타입의 장치들에도 적용될 수 있는 바, 이러한 장치들은 SeGW로부터 이러한 접속을 요청하고, 이를 통해 검증한다. 비록 여기에서는 PVM의 일반적인 엔티티들 대신, HMS와 같은, 네트워크 엔티티들의 H(e)NB 대응물들에 대해 설명하지만, 동일한 방법들 및 장치들은 비(non)-H(e)NB 환경에서도 적용될 수 있음이 명백하다. 전형적으로, 검증 및 인증은 최초 접속의 처음 몇 개의 단계들에, 또는 심지어 동일한 데이터 구조 내에 바인딩될 것이 요구된다. TLS 및 IKEv2와 같은 특정의 프로토콜들에 대해 검증 및 인증을 바인딩시키는 2개의 변형들에 대해 설명한다.

IKE의 전송 프로토콜인 ISAKMP는 이용될 수 있는 다수의 증명서 프로파일들을 정의하고, 이들은 FQDN(fully qualified domain name)을 ID들로서 허용한다. 장치 증명서 및 TrE 증명서는 개별적으로 유지될 수 있다. 하지만, 장치 증명서 내에 TrE 증명서를 짜넣는 것(nest)도 가능하다. TrE가 개별적인 ID (TrE_ID)를 갖는 다면, FQDN이 이용될 수 있지만, TrE는 오퍼레이터 도메인 네임들에 의해서가 아니라, 제조업자에 의해 식별될 수 있다.

IKE_SA_INIT 페이즈 및 이에 따라 Diffie-Hellmann 키 교환이 IKE 대화의 페이즈 1에서 완료되는 경우, 하나의 방법은 SeGW로 하여금 Dev_CERT를 요청하기 위해 CERTREQ 페이로드를 포함하는 제 1 인증 교환 메시지를 전송하게 할 수 있다. 그런 다음, 장치는 다음 메시지 내의 2개의 CERT 페이로드들로 대답할 수 있는 바, 이러한 페이로드들 중 하나는 Dev_CERT를 이용하고, 다른 하나는 TrE_CERT를 이용한다. 이러한 경우, TrE_CERT가 검증되고 PVE에 의해 검증 데이터가 평가될 때 까지, SeGW는 Dev_CERT의 검증을 연기한다. 이후, 인증이 진행된다. 대답이 Dev_CERT 만을 포함하는 경우, SeGW는 AuV로 돌아간다.

실제적인 이유들로 각각의 ID들이 다른 경우, Dev_CERT와 TrE_CERT 간을 구별하는 것이 유익하다. 이를 테면, 오퍼레이터는 IPSec 터널을 직접 구축하기 위해 Dev_CERT에 의해 인증되는 장치들에게, 예를 들어 IP 어드레스와 같은 새로운 어드레스를 할당할 수 있다. 어떠한 타입의 네트워크 어드레스들은 TrE_CERT에 대해 적절하지 않을 수도 있다. 따라서, 장치 내에서는 2개의 ID들이 유용하다. 실행가능한 PVM 및 TrE_CERT에 기초하는 보조 인증을 적용함으로써, Dev_CERT를 교환하는 것이 SeGW/PVE 인프라구조의 다른 작업이 될 수 있다.

IKE 인증 메시지들은 임의 타입 및 임의 수의 페이로드들을 운반할 수 있다. 매 페이로드의 헤더에, '다음 페이로드 타입' 필드를 포함할 수 있다. 따라서, 페이로드들의 전체 체인이 하나의 ISAKMP 메시지 내에서 전송될 수 있다. 이는 증명서들을 최초의 IKE 대화의 페이즈 2의 하나 이상의 ISAKMP 메시지들의 페이로드 필드들 내에 분리하는 데에 이용될 수 있다. 도 10은 장치(1005), SeGW(1010) 및 PVE(1015) 간의 예시적인 프로세스(1000)를 나타내는 바, 이는 TrE 및 장치 인증을 위한 증명서들을 완전히 분리하는 IKE 대화를 이용한다. (TrE_Cert, VAL_DAT)를 포함하는 메시지가 장치(1005)로부터 SeGW(1010)에 전송된다(1). SeGW(1010)는 추출된 TrE 증명서인 TrE_Cert를 검증한다(2). 만일 TrE_Cert가 성공적으로 검증되면, SeGW(1010)는 검증 데이터 메시지(VAL_DAT)를 PVE(1015)에 전송한다(3). PVE(1015)는 장치(1005)를 검증하고(4), SeGW(1015)에 성공을 시그널링한다(5). SeGW(1015)는 증명 요청(CERTREQ)을 장치(1005)에 전송한다(6). 이러한 증명 요청에 응답하여, 장치(1005)는 SeGW(1010)에 적어도 장치 증명(Sig_Dev(Dev_ID), Dev_Cert)을 전송한다(7). SeGW(1010)는 Sig(Dev_ID)를 검증한다(8). 만일 검증이 성공적이면, 장치가 알려져있느냐에 따라 응답하는 AAA 인프라구조에 장치 증명(Dev_Cert)을 전송한다. 이러한 실시예에 따르면, TrE_CERT에 의해 증명된 아이덴티티와 함께, TrE에 의해 서명된 검증 데이터를 전송함으로써, 검증하도록 신뢰될 수 있는 장치들에게만 장치 인증이 허락된다. 이는 SeGW 뒤의 네트워크 컴포넌트들에 대한 확장된 보호를 제공하며, DoS 공격들을 완화시킬 수 있다.

다른 예에서는, 보충 데이터(supplemental data)를 위한 TLS 핸드셰이크(handshake) 메시지가 TLS 헬로우(hello) 핸드셰이크 메시지들에 대한 확장을 정의하는데, 이는 PVM으로부터의 검증 데이터와 같은 애플리케이션 특정의 데이터를 이러한 TLS 핸드셰이크 내에서 전송할 수 있게 한다. 상기 보충 데이터는 TLS 프로토콜에 의해 이용되는 것이 아니라, PVE 검증 엔진과 같은 애플리케이션들에 의해 이용될 수 있다. 단일의 보충 데이터 핸드셰이크 메시지가 허용될 수 있지만, 이러한 메시지를 하나 보다 많이 수신하는 것은 실패로서 처리될 수 있다. 운반되는 데이터의 타입 및 포맷은 SupplementalDataType 으로서 특정될 수 있으며, 송신기와 수신기 모두에게 알려질 수 있다.

하나의 변형에서는, 더블-핸드셰이크를 수행함으로써, SupplementalDataType 핸드셰이크 메시지 내에서 운반되는 실행가능한 PVM 데이터에 대한 보호를 제공할 수 있다. 또한, 당사자들은, 어느 하나의 당사자가 SupplementalData 정보를 제공하기 전에, 상호 인증되도록 보장되어야 한다.

새로운 SupplementalDataType이 실행가능한 PVM 검증 메시지들을 운반하도록 정의될 수 있다. 그런 다음, H(e)NB가 SeGW와의 상호 인증을 위한 제 1 TLS 핸드셰이크에 관여한다. 이후, 두 번째 핸드셰이크는 제 1 TLS 세션을 이용하여 보호될 수 있으며, 검증 데이터가 SupplementalData 필드 내에서 SeGW에 전송된다.

다른 변형에서는, 제 1 핸드셰이크 메시지 내에 보충 데이터를 전송함으로써, 2개가 아닌, 1개의 핸드셰이크 교환으로 검증 데이터를 전송할 수 있다. TLS 세션 티겟 확장을 이용한 검증 연결과 관련하여, TLS 확장이 SeGW에 의한 검증에 이용됨으로써, TLS 세션 티켓 내에 검증 결과를 저장할 수 있게 되는 바, 이러한 TLS 확장은 서버로 하여금 클라이언트에게 세션 티켓을 발행할 수 있게 하여, 세션들을 재개하고 클라이언트 마다 세션 상태를 유지할 수 있게 한다.

이러한 세션 티켓은 PVM에서 플랫폼 관리를 위해 이용될 수 있다. 실패한 컴포넌트들의 특정의 리스트에 대해 검증이 실패하면, SeGW는 PVE로부터 이러한 통지를 받으며, 세션 티겟을 발생시킨다. 이러한 티켓은 H(e)NB에게는 노출되지 않은 128-비트 AES 대칭 키를 이용하여 암호화되며, 이 티켓은 또한 HMAC(Hash-based Message Authentication Code)에 의해 무결성 보호된다. 따라서, 이것은 H(e)NB에 의해 변경될 수 없으며, H(e)NB에 의해 제시되는 다른 네트워크 엔티티들에 의해 인식될 수 있다. 이후, TrE는 이러한 티켓을 안전하게 저장하고, 예를 들어 검증 데이터를 다시 전송할 필요없이, 플랫폼 관리를 위한 새로운 TLS 세션들에서 이 티켓을 이용할 수 있다. 또한, SeGW는 세션 티켓의 수명을 결정할 수 있다.

그런 다음, AES 티켓 암호화 키가 추가의 이용을 위해 T_PVM 내에 저장되거나, 또는 다른 엔티티들에게 직접 넘겨질 수 있다. 이후, 이러한 키와, 예를 들어 티켓 타임스탬프 및 상세한 검증 결과들이 PVE로부터 HMS에 전송될 수 있다. TLS 세션 키를 이용하여, H(e)NB는 플랫폼 관리를 위한 보안 접속을 직접 설정할 수 있다. 이것은 H(e)NB가 플랫폼 관리 작업을 적시에 적절히 처리하고, 티겟이 만료하기 전에 HMS를 컨택하는 것에 의존할 수 있다.

H(e)NB가 세션 티켓에 의해 설정된 접속을 이용하여 HMS에 의한 교정을 끝내면, 그 세션 티켓은 재검증을 위해 이용될 수 있다. 제 1 단계는 구(old) 티켓을 이용하여 H(e)NB로부터 SeGW로 새로운 TLS 접속을 확립하는 것이다. 그러면, SeGW는 이러한 티켓이 HMS와의 관리 사이클을 실제로 끝마친 H(e)NB로부터 오도록 제어할 수 있다. SeGW는 티켓 데이터를 찾아보고, 이러한 티켓 데이터를 관리가 완료된 후 HMS로부터 반송되는 T_PVM과 비교할 수 있다. 정확한 T_PVM이 발견되면, TLS 티켓을 이용한 재검증 시도가 받아들여짐으로써, 예를 들어 리플레이를 위해 TLS 티켓을 이용하여 개시되는 DoS 공격들에 대해 보호할 수 있게 된다. TLS 티켓들은 재검증을 위해 받아들여질 수 있는데, 만일 그렇지 않으면 HMS에 의한 재검증 단계들이 오래 걸리기 때문에 만료된 것으로 고려될 것이다. 이는 많은 보안 손실없이 이루어질 수 있는데, 왜냐하면 SeGW는 비교에 이용가능한 타임 스탬프된 T_PVM을 갖기 때문이다.

여기에서는, 자율적인 검증(AuV)에 의한 PVM의 예에 대해 설명한다. AuV는, SeGW에 어떠한 검증 데이터도 전달하지 않으며, 이에 따라 장치들의 최초 네트워크 접속을 위해 기존의 프로토콜들의 어떠한 변경도 요구하지 않는 방법이다. 따라서, PVM 시스템은 장치의 보안 스타트업 동안 검증 결과에 대한 모든 것을 알게 된다. 전송되는 유일한 장치 특정의 정보는 Dev_ID 이다.

AuV는 플랫폼 검증의 결과들에 기초하여 장치들을 관리할 수 있는 가능성들을 제한한다. 특히, 처음에 네트워크에 대해 인증하고, 업데이트 이후 재검증을 위해 AuV를 수행하는 장치들을 구별하기 위한 어떠한 간단한 방법도 없다. 장치 관리가 AuV에 기초한다면, 이러한 장치 관리는 네트워크 내의 데이터베이스들에 장치 상태들의 이력(history)을 보유할 것을 요구한다. 여기에서는, AuV에 기초하여 적어도 기본적인 장치 관리를 수행하는 데에 효과적인 예시적인 방법들에 대해 설명한다.

여기에서는, AuV 만이 가능한 장치들(AuV-only capable devices)에 대한 H(e)NB 교정의 예에 대해 설명한다. 이러한 AuV 만이 가능한 장치들은 보안 스타트업을 실시하며, 이에 의해 장치는, 로컬 장치 무결성 검증이 성공하는 경우 및 이러한 검증이 성공하는 경우에만, 장치 인증 절차들을 수행할 수 있다. 컴포넌트들 중 임의의 컴포넌트가 자신의 무결성 체크에 실패하면, 장치는 자신의 무결성 체크에 실패한 것으로서 고려될 수 있다. 하지만, FBC 이미지의 이용에 의해, 장치는 지정된 HMS를 컨택하여 장치 교정을 용이하게 할 수 있다.

일단 교정 HMS에 대한 접속이 설정되면, H(e)NB의 정규(normal) 코드 이미지 및/또는 신뢰성있는 기준 값들이 대체될 수 있다. 교정 프로세스가 완료되면, H(e)NB는 리부트해야 하고, 무결성 체크 프로세스가 다시 시작되어야 한다.

소정의 요건들의 세트가 준비되면, PVM은 FBC를 이용할 수 있다. 하나의 예시적인 요건은, FBC가 장치 내에 안전하게 저장되는 것이 될 수 있다. 다른 요건은, 실패한 보안 스타트업의 경우, FBC가 로드되고 시작되는 것이 될 수 있다. 또 다른 요건은, 지정된 H(e)MS의 어드레스가 FBC 이미지 내에 안전하게 저장되는 것이다. 또 다른 요건은, FBC가 지정된 H(e)MS에 디스트레스 신호를 전송하는 것이 될 수 있다. 이러한 신호는 장치 ID를 포함할 수 있으며, 메시지는 FBC의 일부로서 안전하게 저장되는 키에 의해 무결성 보호될 수 있다. 추가의 예시적인 요건은, H(e)MS가 이러한 신호를 수신하면, 이 H(e)MS는 장치가 무결성 체크에 실패했고 유지 보수를 요구하고 있음을 확인할 수 있어야 한다는 것이다. 또 다른 요건은, FBC가 네트워크에 의해 개시되는 풀 코드 구축을 용이하게 하는 기능을 포함할 수 있어야 한다는 것이다. 다른 요건은, FBC가 네트워크에 의해 개시되는 TRV(들)의 교체를 용이하게 하는 기능을 포함할 수 있어야 한다는 것이다.

도 11a 및 11b는, 무결성 검증 실패 이후에, FBC에 의해 용이해지는 장치 교정이 뒤따르는 예시적인 방법을 나타낸다. RoT는 디스트레스 플래그를 체크한다(1). 플래그가 클리어(clear)되면, RoT(1100)는 TrE(1105)의 무결성을 체크한다(2). 플래그가 세트되면, RoT(1100)는 FBC를 로드한다(3). 무결성 체크가 성공적이면, RoT(1100)는 TrE(1105)를 로드한다(4). 무결성 체크가 실패하면, RoT(1100)는 디스트레스 플래그를 세트시키고, 리부트한다(5). 일단 정규 코드(normal code)가 로드되면, TrE(1105)는 이러한 정규 코드의 무결성을 체크한다(6). 무결성 체크가 성공적이면, TrE(1105)는 정규 코드 이미지를 로드한다(7). 무결성 체크가 실패하면, TrE(1105)는 디스트레스 플래그를 세트시키고, 리부트한다(8). RoT가 FBC를 로드하면, FBC는 HMS로의 교정을 위한 디스트레스 신호의 전송을 개시한다.

여기에서는, AuV에 의한 재검증 및 구성 변경을 위한 기본적인 방법의 일 예에 대해 설명한다. AuV 동안 SeGW에 전송됨과 아울러, 가능하게는 플랫폼 관리에서 이용될 수 있는 유일한 개별적인 정보는, 장치 아이덴티티이다. 따라서, 일 실시예는 다수의 아이덴티티들을 장치에 할당하여 이들을 AuV에 이용함으로써, 컴포넌트 무결성 검증 실패들과 같은 (한정된 수의) 상태들을 시그널링할 수 있다. 다른 실시예에서는, 임의의 단일 장치에 대해 특정되지 않는 그룹 ID들을 이용하여, 검증 결과들을 시그널링할 수 있다. 관리 엔티티들은 보안 스타트업 프로세스의 스테이지들에 따라 그룹화된다. 예를 들어, 스테이지 3b에서 실패를 시그널링하기 위한 DevM_ID3b, 스테이지 3a에서 실패를 시그널링하기 위한 DevM_ID3a, 및 스테이지 2에서 실패를 시그널링하기 위한 DevM_ID2가 있다. 스테이지 1 실패는 시그널링될 수 없는데, 왜냐하면 장치가 통신 용량이 없기 때문이다.

AuV를 이용하는 경우에 대한 다른 예에서, 장치는 실패 및 폴백 코드의 실행을 따르는 행동 방침으로서 HMS에 접속하고자 시도할 수 있다.

스테이지 2에서의 단일의 또는 다수의 컴포넌트들의 실패가, 장치가 통신할 수 없게 될 것임을 의미하지는 않는다. 스테이지들은 특정 카테고리들에 속하는 컴포넌트들의 부류들로서 이해된다. 스테이지 2의 가장 중요한 컴포넌트들이 로드되기만 하면, 장치는 그 상태 및 실패한 컴포넌트들을 PVM 시스템에 전달할 수 있다. 이는 기준들(이 기준들 하에서 어태치먼트가 가능하다)에 대한 프레임워크를 제공하는 장치 상의 방침 매니저(이는 HMS에 의해 유지된다)가 있는 경우가 될 수 있다.

보안을 위해, DevM_IDn 및 관련된 인증 데이터(예를 들어, 개인키들)은 잘 보호되어야 하는데, 그렇지 않으면 공격자들이 스푸핑 공격들(spoofing attacks)을 수행함으로써 관리 프로세스를 파괴시킬 수 있기 때문이다. 이것은 위험한 위협인데, 왜냐하면 커다란 그룹의 장치들에 대해 관리 ID들이 동일하기 때문이다. 하나의 솔루션은 이러한 정보 만을 이용하여 플랫폼 관리 프로세스를 모델링하는 것이다. 알려지지 않은 아이덴티티를 갖는 일부 장치의 실패를 신호하는 제 1 검증을 재검증에 바인딩시키는 것은, 고유의 장치에 대한 관리 프로세스의 성공을 시그널링해야 한다. 이를 결정론적으로 수행하는 다양한 방법들이 있다. 일 예에서, 장치가 관리 아이덴티티들 중 하나에 대해 인증된 후, SeGW는 보충 프로토콜(supplementary protocol)을 실행하는 바, 장치는 최초의 Dev_ID에 대해 인증되어야 한다. 다른 방법에서는, 특정의 시크릿들을 교환함으로써, 장치 및 PVM 시스템, 및 구체적으로 SeGW는 제 1의 검증 프로세스 및 제 2의 재검증 프로세스에 걸쳐있는 관리 세션을 확립할 수 있다.

여기에서는, 보충 인증 프로토콜(supplementary authentication protocol)의 일 예에 대해 설명한다. 장치 및 SeGW는 장치와의 제 1 인증 프로토콜을 완료하는 바, 장치는 관리 엔티티들 DevM_IDn 중 하나에 대해 인증된다. 여기에서, 이들은 암호화 및 인증된 통신 세션을 확립하는 것으로 추정된다. 이렇게 되면, 장치는 Dev_ID 및 이러한 Dev_ID를 위한 인증 데이터를 간단히 전송할 수 있다. 예를 들어, 서명된 메시지 및 공개키 증명서는 확립된 보안 채널을 통해 전송될 수 있다. 이는, 어느 누구도 관리를 호출하는 장치의 아이덴티티를 알고, 이러한 지식을 이용하여 관리 프로세스를 스푸핑하지 못하도록, 즉 재검증 이전에 장치를 무효화시키거나, 또는 장치를 위장하지 못하도록 보장한다.

SeGW는 PVE에 DevM_ID 및 Dev_ID를 전송하며, PVE는 이것을 관리를 필요로 하는 장치들의 리스트에 삽입한다. 그런 다음, PVE는 DMS에 '스테이지 2 폴백 코드 설치(install stage 2 fallback code)'와 같은 필요한 장치 관리 액션들을 시그널링한다. DMS는 SeGW에 의해 이전에 설정된 보안 채널을 통해 해당 코드를 장치에 다운로드한다. 정규 PVM 모드에서와 같이, 시스템은 이후 그 장치의 재검증을 개시한다.

관리가 성공적이면, 장치는 이후 AuV에서 자신의 최초의 Dev_ID에 대해 인증된다. 이는 SeGW에 의해 PVE에 시그널링되며, PVE는 재검증 리스트에서 Dev_ID를 인지하고, 이를 삭제한다. 그렇지 않으면, 장치는 인지될 수 있는 관리 ID에 대해 다시 검증되고, 방침에 따라 추가의 액션이 취해질 수 있다.

여기에서는, 관리 세션 설정의 일 예에 대해 설명한다. 이러한 실시예는, PVM이 단일 장치에 대해 고유한 관리를 행한다는 점에서, 다른 실시예들과 다르다. 관리 세션은 장치와 SeGW 간에 통신 프로토콜로 확립될 수 있다. 이러한 시도의 효과는, 본질적으로 가명을 정함으로써, 장치 아이덴티티가 PVM 시스템에 알려지지 않은 채로 유지될 수 있다는 것이다.

정규 프로토콜(normal protocol)로 영구적인 시크릿을 설정하는 프로토콜들의 성능들은 제한될 수 있다. 이를 테면, D-H(Diffie-Hellman)와 같은 공통 키 설정 프로토콜들은, 조인트 키 제어(joint key control)라 불리는 특성을 만족시키며, 이에 따라 설정되는 키는 양쪽 당사자들에 의존한다. 즉, 양쪽 당사자들은 프로토콜 내에 (가짜의-) 랜덤 정보를 삽입함으로써, 매 런(run) 마다 다른 키들을 야기한다. 다수의 런들에 걸쳐있는 세션들은 이러한 프로토콜들을 이용하여 확립될 수 없다.

따라서, SeGW 및 장치는, 이를 테면 챌린지-응답(challenge-response)을 이용하여, 특별한 프로토콜로 시크릿을 확립해야 한다. 챌린지는 장치 또는 SeGW에 의해 제기될 수 있으며, 응답은 제 2 런의 재검증에서의 제 2 대답이 제 1 라운드의 대답과 같도록 이루어져야 한다. 간단한 실시예에서, 장치는 단지 재검증시에 SeGW로부터 얻어지는 논스를 만을 나타내며, SeGW는 이를 테이블에서 찾는다. 따라서, 논스는 가명이다. 보다 복잡한 암호 프로토콜들이 이용될 수도 있다.

이후, 상기와 같이 재검증이 진행된다. 하지만, 이러한 변형에서는, SeGW가 실제적인 이유들로 재검증하는 장치에 대한 정보를 보유한다는 차이가 있는데, 왜냐하면 이러한 정보는 SeGW와 장치 간에, 재검증에 속하는 프로토콜 런(protocol run)에서 이용될 수 있기 때문이다.

여기에서는, H(e)NB에 대한 OMA(Open Mobile Alliance) DM(Device Management) 기반 아키텍쳐의 실시예들에 대해 설명한다. OMA DM은 OMA DM 워킹 그룹 및 DS(Data Synchronization) 워킹 그룹에 의해 공동으로 특정되는 장치 관리 프로토콜이다. OMA DM은 전화기 또는 PDA들과 같은 작은 풋프린트 이동 장비들을 위해 개발되었다. 이는 장비와 DM 서버 간의 광대역 무선 접속은 지원하지 않고, 오로지 USB 또는 RS232C와 같은 단거리 유선 접속, 또는 GSM, CDMA 또는 WLAN과 같은 무선 접속 만을 지원한다. 하지만, 이는 H(e)NB들, 특히 자신에게 접속되는 CSG 및 비(non)-CSG에 대한 기지국으로서 자신을 제시하면서, 또한 코어 네트워크에 대한 WTRU로서 자신을 제시하는 H(e)NB들에 대한 장치 프로비저닝 및 관리 프로토콜로서 유용하다.

OMA DA는 첫 번째의 장치 구성 및 피쳐들의 인에이블링 또는 디스에이블링을 포함하는 프로비저닝, 장치 구성 업데이트들, 소프트웨어 업그레이트들, 진단 보고 및 질문과 같은 유스 케이스(use case)를 지원하도록 의도된다. 비록 장치는 이러한 피쳐들의 서브셋 또는 전부를 선택적으로 구현할 수 있기는 하지만, OMA DA 서버측은 이러한 모든 기능들을 지원할 수 있다.

OMA 사양은 강제적인 접속으로 작은 풋프린트 장치들에 대해 상기 리스트된 피쳐들을 지원하도록 최적화될 수 있다. 이는 또한, 인증을 이용하여, 이를 테면 EAP-AKA와 같은 프로토콜들을 이용하여, 통합 보안을 지원한다.

OMA DA은 데이터 교환을 위해, XML, 또는 보다 정확하게는 SyncML로부터의 서브세트를 이용한다. 이는, 검증의 목적을 위해, 소프트웨어 모듈들에 대한 속성들 또는 H(e)NB에 대한 기능을 정의 및 전달하기 위한, 표준화가 가능하면서도 유연한 방법을 제공하는 데에 유용하다.

장치 관리는 DM 서버(예를 들어, 장치들에 대한 관리 엔티티)와 클라이언트(이를 테면, 관리되고 있는 장치) 간에서 일어난다. OMA DM은 WAP, HTTP 또는 OBEX 또는 유사한 전송들과 같은 전송 계층들을 지원한다. DM 통신은 통지 또는 경고 메시지를 이용하여, 이를 테면 WAP 푸쉬 또는 SMS와 같은 임의의 이용가능한 방법들을 사용하여, DM 서버에 의해 비동기적으로 개시된다. 일단 서버와 클라이언트 간에 통신이 설정되면, 주어진 DM 작업을 완료하도록 메시지들의 시퀀스가 확장될 수 있다.

OMA DM 통신은 요청-응답 프로토콜에 기초하는 바, 여기서 요청들을 통상적으로 DM 서버에 의해 이루어지고, 클라이언트는 응답 메시지로 응답할 수 있다. 서버와 클라이언트는 모두 스테이트풀한데, 이는 빌트인(built-in) 인증 절차 이후, 특정의 시퀀스로 인해 임의의 데이터의 교환이 일어날 수 있음을 의미한다.

DM 통신은 DM 서버에 의해 개시될 수 있기 때문에, DM에 대해 PVM을 실시하는 것은 검증에 대해 서버-질문 기반의 접근을 요구할 수 있다. 예를 들어, IKEv2를 이용하는 장치 인증 절차가 이용될 수 있는데, 이는 장치에 의해 개시될 수 있다. 몇 개의 다른 메시지 타입들이 검증 데이터의 컨베이어(conveyor)로서 고려될 수 있다. 예를 들어, 이는 실패한 소프트웨어 모듈들 또는 장치 기능의 리스트 내에서 전송될 수 있다. 다른 예에서는, 관리 경고 메시지(Management Alert message)가 장치로부터 서버에 전송될 수 있다. 대안적으로는, (장치 또는 서버로부터의 적어도 하나의 관리 경고 메시지의 전송 이후, 오로지 그 장치로부터 DM 서버로만 전송될 수 있는) 일반 경고 메시지(Generic Alert message)의 이용자(user)도 고려될 수 있다. 이러한 경고 메시지들을 포함하는 이들 메시지들은, 콘텐츠 및 이 콘텐츠에 대한 메타 데이터(meta data)를 특정함에 있어서 유연성을 제공하는 SyncML 포맷을 이용할 수 있다. 이는 검증 정보 전송에 유용하다. 또한, DM은 분할된 데이터 전송을 지원할 수 있는데, 이러한 분할된 데이터 전송은 업데이트의 사이즈가 큰 소프트웨어 업데이트에 유용하다.

비록 맨 처음 DM 통신은 DM 서버에 의해 개시되어야 하지만, 이후의 통신은 계속되는(continued) 세션을 이용하여 DM 클라이언트에 의해 개시될 수 있다. 인세션(in-session) 통신을 개시하는 DM 클라이언트(예를 들어, H(e)NB 또는 M2ME)의 능력은, 장치 개시 재검증 또는 장치 개시 검증 메시지 전달과 같은 장치 개시 작업들에 유용하다.

여기에서는, 인증 증명서들에 검증을 바인딩시키는 예들에 대해 설명한다. 인증 증명서들에 검증을 바인딩시키게 되면, 결합된 검증 및 인증을 가능하게 함으로써, 검증에 대해 장치의 인증 ID를 자동으로 바인딩시킨다. 이렇게 되면, 검증 메시지가 부가적인 필드 내에서 인증 증명서에 포함된다. 예를 들어, 대안적으로, IKE 프로토콜을 이용하게 되면, 이러한 검증 데이터는 통지 페이로드 필드에 끼워 넣어진다.

검증 데이터가 인증 증명서 내에 저장된다면, 장치 구성이 변경될 때 마다, 새로운 결합된 인증/검증 증명서가 발행되어야 한다. 증명서의 생성은 SeGW에 의해 제어되어야 하는데, 왜냐하면 이 SeGW가 PVM을 위해 Dev_ID를 인증하는 것을 담당하는 엔티티이기 때문이다. 이는 적어도 2개의 방법으로 이루어질 수 있다. 첫 번째로, DMS로부터 업데이트된 Clist를 수신한 후, SeGW, 또는 하위 엔티티(subordinate entity)는 새로운 증명서를 생성할 수 있다. 두 번째로, 장치가 증명서 자체를 생성하여, 이를 SeGW 및 PVE에 전송하며, PVE는 이 증명서에 서명하여, 다시 장치에 반송한다.

SeGW는, 어느 정도의 성공적인 재검증 이후, 프로세스를 끝낼 수 있다(새로운 증명서를 생성하여 전송하거나, 또는 장치에 의해 생성된 새로운 증명서를 승인한다). 이는, 장치에 의해 실제로 새로운 구성이 도달했음을 PVM 시스템에게 보증하기 위한 것이다.

새로운 증명서는 장치 구성이 변경될 때에 요구되기 때문에, 이러한 사이클은 CN 내의 3개의 모든 엔티티들 및 장치를 필요로 한다. DMS는 구성 변경(예를 들어, 소프트웨어 및/또는 파라미터들의 업데이트)을 트리거하고, 방침 데이터베이스 C_DB 내에 요구되는 새로운 상태를 세이브한다. 이러한 변경이 장치에 적용된 후, 재검증이 이루어져야 한다.

예시적인 시나리오에서, 장치는 업데이트를 적용하고, 재검증을 수행한다. 새로운 소프트웨어가 이용되지만, 새로운 증명서는, (특히 성공적인 업데이트 프로세스의) 재검증이 완료될 때 까지, 장치에 배치될 수 없다. 이때, 장치는 실제 장치 구성과 매치하지 않는 구 증명서를 이용하여 새로운 소프트웨어 구성을 실행시키게 된다. 이에 응답하여, 새로운 증명서가 장치 인증을 위해 장치에 제공되고; 업데이트가 적용된 경우 및 업데이트가 적용된 경우에만 제공되며; 그리고 업데이트가 적용되지 않으면 증명서가 이용될 수 없음이 보장된다.

여기에서는, 장치 인증 증명서 취소의 예에 대해 설명한다. 장치 인증 동안, 장치 인증을 위해 장치로부터 전송된 장치 증명서가 취소될 필요가 있다고 SeGW가 결정하면, 이 SeGW는 그 장치에게, 증명서 취소때문에 장치 인증이 실패했음을 나타낸 다음, 네트워크가 보유하고 있는 화이트 리스트로부터 이 장치를 삭제하거나, 또는 반대로, 네트워크가 보유하고 있는 블랙 리스트에 이 장치를 부가할 수 있다. 장치 인증이 실패했다는 이러한 표시를 수신하면, 장치는 자신의 증명서가 취소되었으며, 자신의 아이덴티티가 화이트 리스트로부터 삭제되었거나, 또는 반대로, 블랙 리스트에 부가되었음을 알게 된다. 그러면, 장치는 네트워크 상에서 자신을 유효한 엔티티로서 재확립하기 위한 절차들을 수행할 수 있다.

장치 ID가 무효하거나, 장치 증명서가 만료되었거나, 또는 H(e)NB 및 그 관련 증명서를 발행한 신뢰성있는 제 3 당사자 오퍼레이터의 허가받은 엔티티가 네트워크에게 증명서를 취소할 것을 요청한 경우, SeGW는 장치 증명서를 취소할 수 있다.

여기에서는, 증명서 기반 검증의 기본적인 방법들의 실시예들에 대해 설명한다. 바인딩 증명서(binding certificate)는 서명된 데이터 세트이다. 이는 발행자, SHO, 또는 그것의 SeGW 또는 이러한 증명서들의 관리를 담당하는 하위 엔티티에 의해 서명된다. 증명서 내의 서명된 데이터는 적어도 Dev_ID, 인증 및 검증에 이용되는 장치 공개 키, 및 Clist를 포함한다.

증명서는 결합된 검증 및 인증 메시지로 SeGW에 전송될 수 있다. 이러한 메시지는 인증 및 검증을 위해 그 개인 키를 이용하여 장치에 의해 (그 일부가) 서명되는 메시지이다. 이러한 메시지는 타임 스탬프 및/또는 리플레이 보호를 위한 논스와 같은 기타 데이터를 포함할 수 있다. SeGW는 증명서 및 메시지의 서명을 체크하고, 평소와 같이, 검증을 진행한다.

여기에서는, 예시적인 증명서 교환 방법들에 대해 설명한다. 일반적으로, 2개의 변형들이 적용될 수 있다. 이들은 프리(pre) 및 포스트(post) 증명서 교환으로서 식별된다. 이들은 재검증이 구 증명서를 이용하느냐, 아니면 새로운 증명서를 이용하느냐에 있어서 다르다. 양 변형들은 모두, 요구되는 모든 단계들이 원자적(atomic)으로 수행되도록, 즉 이들 모두가 완료되거나, 또는 이들 중 어느 것도 완료되지 않도록 보장한다. 시작 조건은 장치가 구 증명서를 이용하여 구 구성을 실행하는 것이고, 종료 조건은 새로운 장치 구성 및 새로운 장치 증명서이다. 장치들을 하나의 오퍼레이터에 묶어두지 않고, 많은 네트워크들 상에서의 장치들의 이용을 가능하게 하기 위해서는, 인증 증명서들 및 RIM 증명서들이 독립적인 TTP 또는 제조업자에 의해 생성, 관리 및 취급될 필요가 있다. 대안적으로, 새로운 장치 증명서들은, 예를 들어 증명서들을 포함하도록 확장될 수 있는 DM을 위한 OMA에 의해 어드레스될 수 있다.

프리-증명서 교환 방법에서, 업데이트는 새로운 증명서를 포함하며, 이에 따라 이러한 증명서는 그 업데이트를 완료하기 전에 장치에 제시된다. 업데이트를 적용한 후, 장치는 새로운 증명서를 이용하여 재검증한다. 이러한 장치는 CN 내의 적절한 저장 및 데이터 구조를 이용하여 '업데이트 진행중'으로서 마크된다. 예를 들어, 인증 데이터베이스 내에 플래그를 설정한다. 다른 방법은 검증 토큰 T_PVM을 이용하는 것이다.

여기에서는, 하나의 예시적인 프리-증명서 교환 흐름에 대해 설명한다. 표준 PVM에서와 같이, DMS는 업데이트된 및/또는 변경된 컴포넌트들을 장치에 전송한다. 이후, DMS는 새로운 Clist를 SeGW에 전송한다. DMS는 T_PVM을 SeGW에 전달한다. 이에 의해, SeGW (및 이에 따라 PVM 시스템)은 장치로부터의 새로운 구성에 의해 재검증을 기대하는 상태에 들어간다. SeGW는 필요한 정보(Clist, Dev_ID, 장치 공개 키 및 기타의 것들)를 수집하여, 새로운 장치 증명서를 생성한다. 이후, SeGW는 이러한 새로운 증명서를 장치에 전송한 다음, 그 장치와의 통신 세션을 끝낸다.

이제, SeGW는 DMS로부터 얻은 T_PVM을 보유하게 되며, 이에 따라 장치로부터의 재검증을 기대해야 함을 알게 된다. SeGW는 내부 재검증 리스트에 이러한 모든 장치들에 대한 T_PVM을 저장한다. 장치가 업데이트들 및 새로운 증명서를 정확히 설치한다고 가정하면, 다음의 프로세스가 적용된다. 장치는 재검증을 개시하여, 재검증 메시지 내에서 새로운 증명서를 전송한다. SeGW는 서명된 데이터 및 장치 증명서를 검증함으로써 장치를 인증한다. SeGW는 재검증 리스트 내에서 T_PVM을 찾는다. 재검증이 이루어지는 바, PVM 시스템 상태는 이전 검증으로부터의 T_PVM을 이용하고 (새로운 것은 발생시키지 않음으로써) 유지된다. 이것 및 이전 단계는 SeGW에서 이루어지고, PVE에서는 이루어지지 않는데, 만일 그렇지 않으면, SeGW는 새로운 토큰을 자동으로 발생시킬 것이다. 따라서, 재검증 리스트의 유지 관리가 SeGW에 대해 수행된다.

표준 PVM에서와 같이, 많은 라운드의 재검증에 대해 T_PVM을 계속해서 이용하는 것은, 되풀이하여 발생하는 업데이트 실패들 및 기타 불규칙한 행동 패턴들을 검출하는 데에 유용하다.

다른 실시예에서, TrE는 HMS에게 장치에 업데이트들을 전송할 수 있게 하는 신뢰성있는 업데이트 서비스를 갖는 바, 이러한 업데이트들은 안전하고 신뢰성있는 프로세스로 적용된다. TrE에서의 업데이트 서비스의 무결성을 보증하기 위해, 보안 스타트업이 신뢰된다. HMS가 새로운 업데이트를 전개할 때, 이 HMS는 새로운 업데이트 장치 구성을 포함하는 토큰을 SeGW에 전송할 수 있다. 그러면, SeGW는 장치에 대해 새로운 인증 증명서를 생성한 다음, 이를 HMS에 반송되는 토큰에 부가한다. HMS는 장치의 업데이트 서비스를 위한 업데이트 데이터와 함께 새로운 증명서를 포함시킨다. 이러한 패키지는 TrE에 대해 암호화되고, HMS에 의해 서명될 수 있다. 신뢰성있는 업데이트 서비스는 이러한 업데이트 패키지를 수신하고, 서명을 검증하고, 데이터를 복호화하고, 업데이트를 적용하며, 그리고 새로운 증명서를 보안 저장소에 저장한다. 이후, TrE는 HMS에 성공적인 업데이트를 시그널링한다. 신뢰성있는 업데이트 서비스는 보안 스타트업에 의해 보호되기 때문에, 업데이트 프로세스는 신뢰될 수 있으며, 이에 따라 재검증이 필요없다. 업데이트의 타입에 의존하여, 리부트가 필요할 수도 있다. 이 경우, 장치는 SeGW에서 새로운 증명서를 이용하여 인증할 수 있다. 따라서, HMS는, SeGW가 일어나게 될 재검증에 대해 확실하게 통지받을 수 있게 해야 한다.

다른 실시예에서, 장치 상에서 어떠한 신뢰성있는 업데이트 서비스도 이용가능하지 않다면, 새로운 증명서에는 새로운 소프트웨어 업데이트가 제공될 수 있으며, 이에 따라 이러한 증명서는 업데이트의 성공적인 설치에 바인딩되는 키로 암호화된다. 이러한 방법 및 그 의미들은 좀 더 고려될 필요가 있다.

포스트-증명서 교환 방법에서, 업데이트는 새로운 장치 구성을 포함하는 새로운 증명서를 포함하지 않는다. 장치는 구 증명서를 이용하여, 재검증을 수행한다. 성공적인 재검증 이후, CN은 새로운 증명서를 활성화시키며, 이 새로운 증명서를 장치에 전송한다. 장치는 보안 스타트업을 수행하기 위한 새로운 구성을 가지고 있지 않을 수 있기 때문에, 비록 이 장치가 새로운 증명서를 아직 갖고 있지 않더라도, 이 장치에 새로운 구성을 전송한다.

여기에서는, 오퍼레이터 RIM-쉴딩의 예에 대해 설명한다. 무선 영역 네트워크(WAN) 관리 프로토콜이 장치들의 원격 관리에 이용될 수 있다. 도 12는 발행자로부터 장치로의 소프트웨어 패키지들의 다운로드를 가능하게 하는 서명된 메시지 포맷(1200)의 예시도이다. 이러한 포맷은 펌웨어 업데이트들 또는 구성 패키지들과 같은 하나 이상의 파일들이 단일의 서명된 패키지 내에서 전송될 수 있게 한다. 수신 장치는 소스를 인증할 수 있으며, 콘텐츠들을 설치하기 위한 모든 명령들을 포함한다.

헤더(1205)는 포맷 버전과, 커맨드 리스트 및 페이로드 컴포넌트들의 길이를 포함할 수 있다. 커맨드 리스트(1210)는 패키지에 포함되는 파일들을 설치하기 위해 실행될 수 있는 명령들의 시퀀스를 포함한다. 서명 필드(1215)는 디지털 서명을 포함할 수 있는 바, 이것의 서명된 메시지 데이터는 헤더 및 커맨드 리스트로 이루어진다. 비록 서명된 메시지 데이터가 패키지 헤더 및 커맨드 리스트 만을 포함하기는 하지만, 이러한 서명은 전체 패키지의 무결성을 보증하는 바, 이는 페이로드 파일들(1220)에 관련된 모든 커맨드들이 파일 콘텐츠의 해쉬를 포함하기 때문이다.

오퍼레이터 RIM 쉴딩의 경우, DMS는 커맨드 리스트에 서명하고, 소프트웨어 패키지들 및 이들의 각각의 RIM들을 메시지의 페이로드에 포함시킨다. 이후, 장치의 TrE는 공개 키를 이용하여 DMS의 서명을 검증한다. 이러한 공개 키는, 제조시에 또는 배치시에, 또는 오퍼레이터에 의해 신뢰되는 CA에 의해, TrE에 이용가능해질 수 있다. 공개 키를 검증하는 데에 필요한 모든 루트(root) 증명서들은 TrE에 안전하게 저장될 수 있다. 커맨드 리스트는 장치 내로의 RIM 인제스천 및 소프트웨어의 설치를 위한 커맨드들을 포함한다. 이는 오퍼레이터가 장치 상에서의 소프트웨어 및 RIM 설치 프로세스를 완전하게 제어할 수 있게 하는 효과적인 방법을 제공한다. 이러한 실시 변형에서는, 장치로의 RIMc들의 명시적인 전송이 일어나지 않을 수도 있다.

여기에서는, 교정을 위해 제 2 코드 베이스를 이용하는 예들에 대해 설명한다. 일반적인 PVM 장치 모델에서의 스테이지 2 실패와 같은, TrE의 범위를 넘어 보안 스타트업의 실패로부터 비롯되는 문제는, 통상의 실행 공간 내에 로드되는 교정 컴포넌트들에 대한 신뢰를 확장하는 데에 있어서 TrE가 신뢰될 수 없다는 것이다. 따라서, 교정을 개시하기 위해, FBC가 호출될 수 있지만, TrE 내에서, 적어도 가장 중요한 기능들에 대해, 암호 및 교정 프로토콜 스택을 실행할 필요가 있다.

특정의 환경들에서는, 외부의 보안 소스(여기에서는, FBC 캐리어라 불린다)로부터 FBC를 얻는 것이 이치에 맞을 수 있다. 이것은 부분적으로 대역외 프로세스에 의해 이루어질 수 있으며, 그리고 H(e)NB 장치 내에 스마트 카드를 삽입하는 것과 같이 인간의 개입을 요구한다. 이러한 절차는, FBC 코드를 안전하게 저장하고 보호하는 FBC 캐리어로서 제 2 보안 요소(스마트 카드)를 이용하거나, 또는 간단한 자동 DoS 공격들을 완화하기 위해 교정 개시 절차에서 인간의 개입을 명시적으로 요구함으로써, 보안을 강화할 수 있으며, 그리고 이러한 절차는 HP로부터의 딜리전스(diligence)로서 계약적으로 요구될 수 있다. 외부의 FBC 캐리어는, 장치들을 단순하고 싸게 유지하고, 얇은 TrE를 유지하기 위한 수단이 될 수 있다. 이러한 외부의 FBC 캐리어는, 교정에 대해 요구되는 모든 시크릿들을 포함하여 FBC의 실행가능한 바이너리를 운반할 수 있으며, 그리고 부가적으로는, 요구될 때에 FBC에 대한 보안 실행 환경을 제공할 수 있다. 장치가 원격에 있거나 또는 도달하기 어려운 위치에 있는 상황들에서는, 개별적인 FBC 캐리어를 이용하는 것을 적용할 수 없다. 여기에서 설명되는 3개의 엔티티들 간의 신뢰 확립 프로세스는 이전에 설명한 다양한 "과도적인 신뢰(transitive trust)" 절차들과 유사하다.

다음의 절차가, UICC, 스마트 카드, 또는 자기 자신만의 처리 유닛을 갖는 보안 메모리 카드와 같은 외부의 FBC 캐리어에 대해 적용될 수 있다. TrE는 허가되고 인증된 FBC 코드가 로드될 것을 요구하는 의존 당사자이다. 한편, 재교정을 위한 크리덴셜들이 보호된 채로 유지되기만 하면, 비허가된 당사자에게 FBC 코드를 누설하는 것은 위험이 덜하다. FBC 캐리어에 대한 TrE의 인증은 덜 문제가 되는데, 왜냐하면 TrE 및 장치가 실제로 완전히 신뢰되지 않는 대역외 프로세스가 수행되기 때문이다. 이것이 캐리어가 HMS 액세스에 대해 이용되는 크리덴셜들을 장치에 누설하지 말아야 하는 이유이다. FCB의 누설은 피할 수 없으며, 덜 중요하다.

따라서, 다음의 허가 또는 통신 시퀀스가 적용될 수 있다. 대역외 또는 인간 개입 단계들은 특별한 유스 케이스에 대한 예시일 뿐이며, 다른 변형들에서는 자동화되거나 통합될 수 있는 바, 예를 들어 FBC 캐리어가 H(e)NB 내에 내장될 수 있다. 이러한 폴백 코드 베이스 절차에서의 통신은 매우 간단하며, 이에 따라 인증 및 허가는 단일 프로토콜 단계들에서 결합될 수 있다.

처음에, 스테이지 1 스타트업이 성공하고, 스테이지 2 스타트업은 실패한다. TrE는 "FBC 대기(waitng for FBC)" 상태로 정지(stall)되며, 그리고 LED를 번쩍거리게 하거나, 또는 다른 유사한 실패 표시자를 제공한다. 사용자/HP는 FBC 캐리어를 삽입한다. 이러한 실시예에서, FBC 캐리어, 예를 들어 HPM과 같은 스마트 카드는 특정의 물리적인 인터페이스를 이용하여 TrE에 대해 그 자신에게 권한을 부여함으로써, FBC 캐리어 존재를 시그널링하고, 및/또는 허가 시크릿, 예를 들어 OTP 또는 서명된 논스를 서미트(submit)한다. TrE와 FBC 사이에는, 암호화되고 무결성이 보호되는 통신 세션인 보안 연계(security association, SA)가 설정된다. 그러면, FBC는, TrE 또는 FBC 캐리어에 의해 제공되거나, 또는 양쪽 환경들의 성능들의 임의의 결합에 의해 제공되는 보안 환경 내로 로드된다. 이후, FBC는 요구되는 경우 무결성이 체크된 다음, 다운로드되고 시작될 수 있다.

보안 스타트 이후, FBC는 시크릿을 이용하여 자신의 성공적인 로드를 캐리어에게 나타내며, TrE (FBC)와 캐리어 사이에 새로운 SA를 생성한다. 교정을 위한 크리덴셜들은 캐리어 내에 유지되지만, FBC는 HMS 발견을 위한 데이터를 포함한다. FBC는 HMS를 컨택한다. TrE (FBC)에 대해 내내 이용불가능하게 유지되는 스마트 카드 보호 크리덴셜들을 이용하여, 스마트 카드와 HMS 간의 종단간(end-to-end) SA가 확립된다. 이제, HMS는 유효한 TrE (FBC)가 교정을 요구하고 있음을 알게 된다. 스마트 카드는 TrE (FBC)에 대한 통신 세션을 넘겨주고, TrE (FBC)는 자신의 ID를 HMS에 제시한다. HMS는 교정 절차를 개시한다. 허가 시크릿은 잘 보호되어야 하는데, 왜냐하면 이러한 종류의 접속은 많은 장치들에 적용될 수 있으며, 이에 따라 이러한 시크릿에 대한 위반(breach)은 파국적이기 때문이다. 허가를 실시하는 하나의 방법은, 소유권 획득 절차에서 생성되는 160-비트 HW 보호되는 값들과 같은 TPM-보호되는 허가 시크릿들을 이용하는 것이다. 실시에 따라, FBC는 FBC 캐리어로부터 직접 시작될 수 있는 바, 이렇게 되면 안전한 보안 실행 환경을 제공해야 한다. 이 경우, 손상된 TrE까지도 교체될 수 있을 것이다. 하나의 예는, FBC 캐리어가 보안 요소, 마이크로프로세싱 유닛 및 메모리로 이루어짐으로써, FBC를 독립적으로 실행하는 것이다. FBC 캐리어는 통신 인터페이스(예를 들어, USB, JTAG)를 통해 장치에 어태치되어, 그 장치 내의 컴포넌트들에 직접적으로 인증한 다음, 손상된 컴포넌트들 및 가능하게는 TrE의 부분들을 교체할 수 있다. 다른 변형에서, 서명된 코드-이미지들이 이용된다면, FBC 캐리어 장치는 서명을 포함하는 이미지를 대신할 수 있다.

TrE는, 일부 경우들에서는, FBC를 정확하게 로드하여 실행할 정도로 충분히 신뢰적이지 않고, 대부분의 경우들에서는, FBC 캐리어에 로드되는 FBC를 검증할 수 없기 때문에, 어느 정도의 보안 강화가 포함될 수 있으며, 이에 따라 FBC 캐리어는 원격 코드 베이스 실행에서 신뢰를 확립해야 한다. 예를 들어, FBC 캐리어는 1회 시크릿(one-time-secret)을 발생시킨 다음, 불명료화 방법들을 이용하여 FBC 내에 끼워 넣을 수 있다. 대안적으로, FBC와 함께, 또는 FBC 직후, 캐리어는 다른 허가 시크릿을 전송할 수 있는데, 이는 성공적으로 시작된 FBC에 의해서만 인식되고 이용될 수 있다. 성공적으로 시작된 FBC는 이러한 시크릿을 이용하여, TrE 내의 어떠한 보호되는 장소로부터, 바로 다음 단계의 통신을 위한 통신 시크릿을 얻는다.

여기에서는, 폴백 코드를 위해 내부의 병렬 코드 베이스들을 이용하는 예들에 대해 설명한다. 이러한 내부의 병렬 코드 베이스들은 교정을 용이하게 하기 위해 트리거 메커니즘들 및 폴백 코드 베이스를 포함할 수 있다. 예를 들어, H(e)NB는 2개의 코드 이미지들을 포함할 수 있는데, 하나는 정규 모드이고, 다른 하나는 폴백 코드 이미지(FBC)이다. 정규 모드 브링업(bring up)은 스테이지들에서 AuV 및 SAV 모두에 대해 구현될 수 있다. 스테이지 1에서, ROM 내의 RoT는 TrE를 검증한다. TrE가 유효하면, 다음 스테이지의 컴포넌트들이 체크될 수 있다. 이후, 임의의 컴포넌트가 그 무결성 체크에 실패하면, 코드는 TrE 코드의 시작으로 언로드(unload)된다. 이때, TrE는 교정과 같은, 폴백 코드의 체크를 시작할 수 있다. 폴백 코드가 무결성 체크를 통과하면, 이 폴백 코드는 로드되어 시작될 수 있다. 이러한 폴백 코드는 HMS와 통신을 확립하기 위해 어떠한 최소 세트의 장치 관리(DM) 코드를 포함할 수 있다. 일단 HMS에 대한 접속이 확립되면, 실패한 모듈들이 식별되고, 업데이트가 HNB에 전송된다. 교정 프로세스를 완료하면, H(e)NB는 리부트되며, 검증 프로세스가 다시 시작된다. 폴백 코드 사이즈는 HMS와의 통신을 용이하게 하기 위해 작게 유지될 수 있다. 코드는 TrE에 "롤백(roll back)"된 다음, 폴백 코드에 의해 로드될 수 있기 때문에, 트리거 메커니즘 또는 레지스터는 요구되지 않는다.

여기에서는, 부가적인 변형인 "하이브리드 (내부/외부) 코드 베이스"에 대해 설명한다. FBC는 상기 설명한 병렬 코드 베이스 케이스에서와 같이 장치 내에 저장될 수 있지만, FBC는 장치 상에서 암호화 및 무결성 보호된다. TrE 자체는 FBC를 복호화하는 데에 이용될 수 없는데, 만일 그렇지 않으면, 손상된 TrE는 FBC 자체의 손상을 야기할 수 있다. 하이브리드 솔루션은 스마트 카드 또는 UICC와 같은 외부의 보안 요소 상에 FBC 이미지에 대한 복호화 및 검증 키들을 저장한다. 스타트 실패의 경우, TrE는 이러한 실패를 시그널링하며, 사용자/HP는 장치 내에 인증 토큰, 즉 스마트 카드를 삽입할 것이 요구된다. 장치 특성들에 따라, 2개의 옵션들이 이용가능하다. 제 1 옵션에서, 인증 토큰은 키 머티리얼(key material) 만을 저장하고, TrE와 상호 인증을 수행하는 바, 이러한 상호 인증시에 또는 상호 인증 이후에, TrE는 필요한 키 머티리얼을 수신한다. TrE는 FBC의 무결성 체크 및 복호화를 수행한 다음, FBC를 로드하여 시작한다. 다른 옵션에서는, (예를 들어, 보안 실행 환경을 제공하기 위해 TrE의 부분들을 이용하여) 장치의 자원들 만을 이용하거나, 또는 인증 토큰 자체 내에 보안 실행 환경(여기에서 FBC가 실행될 수 있다)을 제공함으로써, 장치 상에 저장된 FBC를 자율적으로 검증 및 복호화한 다음, 실행한다는 점에서, 인증 토큰이 개선된다. 이러한 변형은, 부가적인 외부 보안 요소의 보안과 결합하여, FBC 저장을 위해 장치의 더 큰 저장 용량을 이용하는 것을 가능하게 한다.

여기에서는, 내부의 순차적인 코드 베이스들을 이용하는 실시예들에 대해 설명한다. 장치 관리 프로토콜은 원격 장치들 상에 소프트웨어 구성들을 설치 및 변경하기 위한 프로토콜들 및 커맨드들을 정의할 수 있으며, '리부트' 커맨드를 포함할 수 있다. 이는 '교정 요구(remediation-needed)' 메시지를 전송하는 장치의 의도(notion)는 포함할 수 없다. 하지만, SAV와 같은 검증 결과들과 장치 관리 프로토콜을 결합하게 되면, HMS는 이러한 장치 관리 프로토콜을 이용하여, 소프트웨어 컴포넌트들의 재설치 또는 리셋을 개시한 다음, 재검증을 위한 리부트 커맨드를 발행할 수 있다.

대안적으로, FBC는 정규 코드들의 일부를 지우거나 삭제함으로써, 정규 코드들의 나머지 만을 남기고, 리부트를 개시한 다음, 재검증을 한다. FBC에는 지워지거나 삭제될 필요가 있는 정규 코드들의 리스트가 사전에 프로비저닝될 수 있다. 대안적으로, FBC는 스마트 카드(예를 들어, HPM)와 같은 외부의 보안 요소로부터 이러한 리스트를 얻을 수 있다. 대안적으로, FBC는 H(e)MS와 같은 네트워크 기반 엔티티로부터 이러한 리스트를 얻을 수 있다.

이러한 메커니즘이 확실하게 작동하도록 하기 위해, 이는 장치 상에 신뢰성있는 애플리케이션을 가질 수 있는 바, 이러한 애플리케이션은 다음의 특징들: 무결성 보호되고; 장치 내에 안전하게 저장되고; 실패한 보안 스타트업의 경우 스타트될 수 있고; HMS에 대한 (보안) 접속을 설정하고; HMS로부터의 커맨드들 및 소프트웨어 상의 서명을 검증할 수 있고; 장치 상에 소프트웨어를 설치/삭제할 수 있으며; 그리고 장치가 교정을 요구하고 있음을 보고할 수 있는 특징들을 포함할 수 있다.

제 2의 가능한 리던던트 코드 베이스 이미지를 이용하여, 이러한 애플리케이션을 호스트할 수 있다. 상기 설명을 따르고, 상기 설명한 요건들에 충실하게 되면, 제 2 코드 베이스는 장치 내에 어떠한 부가적인 리던던트 코드를 가져온다. 이러한 코드에 의해 제공되는 모든 피쳐들은 장치 내에서 정규의 성공적인 보안 스타트업의 경우에 요구된다. 제 2 코드 베이스의 모든 피쳐들은 제 1 코드 베이스에 존재할 수 있다.

다른 변형은 병렬 설계를 순차 설계(sequential design)로 대체하는 것이다. 이는 다음의 시퀀스를 필요로 한다. 성공하면, RoT는 TrE를 검증하고 시작한다. 성공하면, TrE는 교정 코드를 검증한다. 성공하면, TrE는 나머지 소프트웨어 컴포넌트들을 검증한다. 성공하지 않으면, TrE는 실패한 모듈들을 저장하고, 장치가 교정을 요구하고 있다는 플래그를 설정한다. 이후, TrE는 장치의 리부트를 트리거한다. 리부트시, 원격 코드를 검증한 후, TrE는 교정 코드에 대한 제어를 전달하고, 실패한 모듈들의 리스트를 해제한다. 이후, 교정 코드는 이러한 리스트를 이용하여, 장치 교정 프로세스들을 위해 HMS를 컨택할 수 있다.

여기에서는, 보안 방침 속성들을 이용하는 SAV에 대한 예들을 설명한다. 어떤 모듈들이 내부 무결성 체크에 실패했는 지를 PVE에게 통지하는 것은 H(e)NB들의 모든 메이크들 및 모델들에 대한 모든 SW 모듈들의 표준화된 리스트를 생성하는 것을 포함할 수 있다. 이것은 보안 방침 속성(SPA)들의 표준화된 리스트를 생성하도록 허용될 수 있다. SPA는, 특정의 SW 모델이 자신의 무결성 체크에 실패하는 경우 어떤 액션을 취해야 하는 지를 PVE에게 알려주는 방침이 될 수 있다. PVE는 실패한 모듈에 대해 어떤 것도 알 필요가 없다.

SPA 코드들은 표준화될 수 있으며, 다음의 코드들을 포함할 수 있다. "00" 모듈 실패는 네크워크 액세스가 거부되어야 함을 나타낼 수 있다. 이러한 타입의 모든 모듈들은 스테이지 2에 있을 수 있지만, 스테이지 3 모듈들에서 이러한 코딩을 하게 되면, 유연성을 허용한다. "01" 모듈 실패는 일시적인 네트워크 액세스를 허용함을 나타낼 수 있다. 이러한 일시적인 네트워크 액세스는, 예를 들어 실패한 SW 모듈의 복구를 위해 교정 센터를 이용하여, 교정에 대한 섹션에 설명한 바와 같이, 장치에 의해 교정을 수행하는 데에 이용될 수 있으며, 교정이 성공적이지 못하면, 네트워크 액세스를 중지시킬 수 있다. "02" 모듈 실패는 네트워크 액세스를 허용함을 나타낼 수 있다. 이는 실패한 SW 모듈의 복구를 위한 교정 센터와 관련될 수 있으며, 교정이 성공적이지 않더라도, 네트워크 액세스를 계속할 수 있다. "03" 모듈 실패는 네트워크 액세스를 허용함을 나타낼 수 있다. 이것은 실패한 SW 모듈을 삭제/디스에이블/격리시킬 수 있으며, 액션이 성공적이지 못하면, 네트워크 액세스를 중지시킬 수 있다. "04" 모듈 실패는 네트워크 액세스를 허용함을 나타낼 수 있다. 이것은 실패한 SW 모듈을 삭제/디스에이블/격리시킬 수 있으며, 액션이 성공적이지 않더라도, 네트워크 액세스를 계속할 수 있다. "05" 모듈 실패는 네트워크 액세스를 허용함을 나타내며, SW 무결성 실패를 무시할 수 있다. "06"은 기타 실패들을 나타낼 수 있다.

단일 SPA는 H(e)NB의 각 스테이지 3 SW 모듈과 관련될 수 있다. 이렇게 되면, 실제 SW 모듈 식별자들은 H(e)NB의 각 메이크 및 모델의 소유가 될 수 있다. SAV에서, H(e)NB는 이미 SeGW에 H(e)NB_ID를 전송하였는데, 이는 네트워크에 의해 H(e)NB의 메이크, 모델 및 일련 번호를 식별하는 데에 이용될 수 있다. 각 스테이지 3 무결성 체크 실패에 대해, H(e)NB는 통지 페이로드 내에 소유 SW 모듈 ID 및 해당 SPA를 배치한다. 이러한 통지 페이로드는 기존의 SAV 방식에 따라 PVE에 전송된다.

PVE는 SPA들을 검사하고, 만일 임의의 SPA=00 이면, SeGW는 H(e)NB에 대한 액세스를 허가할 수 있는 권한이 부여되지 않는다. 만일 임의의 SPA들=01 또는 02 이면, 교정 프로세스가 트리거된다. PVE는 H(e)NB_ID 및 SW 모듈 ID들을 전송한다. 교정 센터는 H(e)NB_ID를 이용하여, 소유 SW 모듈 ID들을 상호 참조함으로써, H(e)NB에 정확한 업데이트를 다운로드할 수 있다.

임의의 SPA들=03 또는 04 이면, PVE는 SeGW에 적절한 명령을 전송할 수 있다. 임의의 SPA들=05 이면, H(e)MS 또는 다른 네트워크 요소가 관리 목적을 위해 데이터를 저장할 수 있다.

선택적으로, 비(non)-00 SPA들과 관련된 어떠한 리부팅/재검증 및 ACK 메시징이 있을 수 있다. 네트워크가 불량 H(e)NB에 대한 어느 정도의 정보를 갖게 됨으로써, 어떠한 관리 액션이 취해질 수 있다는 것을 제외하고, SPA=00 은 AuV와 동일한 최종 결과를 갖는다. 선택적으로, PVE는 자신들의 무결성 체크들을 통과한 모듈들에 대해 통지받지 못할 수도 있다.

FBC가 기본적인 통신들을 지원한다면, PVM은 스테이지 2 모듈들의 실패를 포함하도록 확장될 수 있다. SPA는 SW 모듈 ID를 포함하는 객체의 일부가 될 수 있다. 이들은 TrE 내에 저장되어야 한다. 이들은 SW 모듈의 일부로서 저장되지 않을 수도 있으며, 그리고 SW 모듈의 무결성 체크에 실패한 경우에는 신뢰되지 않을 수도 있다.

위험 평가 프로세스(risk-assessment process)에 기초하여, 각 SW 모듈에 할당되는 SPA들은 SW 스택에 대한 형식 승인 프로세스(type-approval process)의 일부로서 각 H(e)NB 공급자와 일치할 수 있다. 일단 공급자가 오퍼레이터와의 관계를 확립하면, 새로운 SW 모듈들에게 SPA들을 할당하는 것이 간단해질 수 있다. 정해진 공급자들은 이전의 성공적인 승인들에 기초하여 적절한 SPA들을 할당하도록 신뢰될 수 있다.

H(e)NB 구조의 SW 구조의 표준화에 대한 요구를 줄이기 위해, H(e)NB의 SW 구조는 코드들의 블록들의 측면에서 정의될 수 있는 바, 하나의 블록은 무결성 체크의 측면에서 그리고 무엇이 교정될 수 있는 지의 측면에서, 최소의 원자 럼프(atomic lump) 또는 퀀타(quanta)로서 정의된다. 개별적인 블록 기능들은 정의되지 않는다. 예를 들어, 모든 스테이지 3 SW는, 무결성 체크의 관점에서, 단일 블록이 될 수 있다. 대안적으로, 블록들은 실제 SW 애플리케이션들에 대해, 또는 심지어 애플리케이션들 내의 센서티브 객체들(sensitive objects)에 대해, 1:1로 맵핑될 수 있다. SPA들은 SW 블록들에 적용될 수 있다. 01 또는 02의 SPA때문에 교정 센터가 호출되면, 요구되는 블록들을 다운로드한다. 블록의 ID는 벤더와 관련될 수 있으며, 아키텍쳐는 표준화되지 않을 수도 있다.

장치 검증에 SPA들이 이용되면, 이러한 SPA들은 TrE에 안전하게 저장되고, SW 식별자에 바인딩될 수 있다. 예를 들어, 05-SPA는 00-SPA를 갖는 다른 컴포넌트에 대해 리플레이되지 않음이 보증될 수 있다. 따라서, PVE는 수신된 SPA가 실제로 H(e)NB 내의 로드된 컴포넌트에 속한다는 것을 검증할 수 있다.

장치의 첫 번째의 최초 네트워크 접속시에 개시되는 등록 프로세스(enrollment process)는, SPA들을 그 장치로부터 C_DB에 안전하게 전송하고, 이들을 미래의 이용을 위해 저장하는 데에 이용될 수 있다. 이후, 장치는 실패한 컴포넌트들의 SW_ID들을 보고할 수 있고, 그리고 PVE는 로컬 데이터베이스로부터 해당하는 SPA 방침 액션을 검색할 수 있다. 이는 저 대역폭 접속 장치들에 대해 유용하다.

여기에서는, SPA들을 그룹화하는 실시예들에 대해 설명한다. SPA들이 TrE 상에 국부적으로 저장된다면, 이 TrE는 실패한 모든 코드들 및 이들의 SPA들을 검사하고, 이들을 처리하며, 더욱 요약된 스테이지 무결성 체크를 전송할 수 있다. 실패한 모듈들 및 이들의 SPA들은 표 1에 나타낸 것들을 포함할 수 있다.

실패한 모듈 ID	SPA
00	01
01	01
02	03
03	03
04	03
05	04

TrE는 표 2에 나타낸 바와 같이 이러한 데이터를 처리할 수 있다.

SPA 값들	모듈들
01	00, 01
03	02, 03, 04
04	05

SPA에 의해 나타낸 다른 정도로 실패한 모듈들의 리스트가, 모든 SPA 값들 대신에, 전송될 수 있다.

따라서, 통지 메시지 내의 일부 비트 블록들이 정의되는 경우, 표 3에 나타낸 바와 같은 맵핑을 가질 수 있다.

SPA	모듈 값
00	없음(empty)
01	00, 01
02	없음
03	02, 03, 04
04	04
05	없음

데이터의 밀집도(compactness)는 기대되는 실패한 모듈들의 수에 의존할 것이다. 예를 들어, 평균하여, 1개 보다 많은 모듈이 대부분의 SPA들에 대해 실패한다면, 데이터는 보다 밀집할 것이다.

도 13은 원격 증명을 통한 검증 방법의 예를 나타낸다. 검증 엔티티(1300)는 SML 및 서명된 PCR 값을 수신한다. SML은 각각의 PCR 내로 확장된 모든 파일들의 정렬된 리스트를 포함한다. 검증 엔티티(1300)는 SML 내의 모든 엔트리에 대해 다음의 단계들을 수행한다. 검증 엔티티(1300)는, 알려진 완전한 해쉬 값들의 로컬 데이터베이스(1310) 내에 소정의 파일명(filename)이 있는 지를 질문한다(1). 이 데이터베이스(1310)는 신뢰성이 있는 것으로 고려되는 바이너리들의 모든 파일명들 및 RIM(이를 테면, 해쉬들)을 포함한다. 파일명이 데이터베이스 내에서 발견되지 않으면, 이것은 신뢰성이 없는 것으로서 고려된다(2). 검증 엔티티(1300)는 RIM을 SML로부터 보고된 측정 값과 비교한다(3). 이들이 일치하지 않는 다면, (사용자, 멀웨어(malware) 또는 다른 엔티티에 의해) 플랫폼 상의 바이너리가 변경된 것이다. 이 경우, 플랫폼은 신뢰될 수 없다(4). 검증 엔티티(1300)는 가상 PCR에 대해 확장 동작을 수행할 수 있다(5). 본질적으로, 검증 엔티티는 실행 및 측정 동안 플랫폼이 행하는 것과 동일한 단계들을 수행한다. 이러한 프로세스의 끝에서, 가상 PCR의 값은 플랫폼으로부터의 보고된 값과 비교된다(6). 이들이 일치하지 않으면, SML은 탬퍼링된 것이다(예를 들어, SML로부터의 라인이 삭제되지만, 해쉬 값이 PCR로 확장되었다면, 가상 PCR 및 보고되는 PCR은 일치하지 않을 것이다). 이렇게 되면, 플랫폼은 신뢰성이 없는 것으로서 고려된다(7).

Clist에서와 같이 로드된 컴포넌트들의 리스트를 보고하거나, 또는 F-SAV의 경우 실패한 모듈들의 리스트를 보고하거나, 또는 측정들을 보고하기 위한 변형으로서, 모듈들 간의 계층적인 관계를 이용하여, 보고되는 요소들의 수 및 레이턴시 요건들을 줄일 수 있다. 도 14는 예시적인 배열을 나타낸다. 이러한 배열은 모듈들에 대한 자연적인 정렬을 자동으로 유도한다. OS, 프로토콜 스택들, 관리 모듈들 및 기타 모듈들로 인해, 가능한 모듈들의 수가 매우 높아질 수 있기 때문에, 모듈들의 수가 많아질 수 있다.

성공적인 스타트업 이후, PVE 또는 SeGW는 성공적인 스타트업을 나타내는 증명서를 장치에게 발행해야 한다. 이러한 증명서는, TrE_ID, (소프트웨어, 하드웨어) 또는 소프트웨어의 해쉬의 버전 넘버들, 보안 타임 스탬프, 장치의 위치, 모듈들의 해쉬, 모듈들의 Clist 및 기타 관련 정보와 같은 정보 요소들을 포함할 것이다.

이러한 증명서는 실패한 스타트업에 대해 유용하다. 이 경우, PVE에 정보가 반송되며, PVE는 보고되는 버전 넘버가 정확하다는 것을 확실히 검증할 수 있게 한다. PVE가 증명서를 발행했기 때문에, 이에 따라 적절한 단계들을 행할 수 있다. 차이점은, 장치가 성공적인 스타트업 상태를 나타내는 경우에서와 같이 PVE가 신뢰에 대해 장치에 의존하지 않는 다는 것이다. 하지만, 이것은, PVE가 자신의 실패한 스타트업 경우에 관하여 장치로부터 수신한 임의의 정보를 적어도 신뢰할 수 있는 경우에만 그러하다. 따라서, 이 경우, 장치는 그 기능이 실패한 스타트업의 상태를 검출하고, 이러한 상태를 PVE(이는 여전히 손상되지 않았으며, 손상될 수 없다)에 보고할 수 있도록 설계될 수 있다.

이러한 증명서는 또한 성공적인 스타트업에 대해서도 유용하다. 이 경우, 이후의 보안 스타트업 프로세스에서, 장치는 측정들 또는 측정들의 해쉬 값, 및 PVE에 의해 발행되는 최근의 보안 스타트업 증명서 또는 이에 대한 포인터를 전송할 수 있다. 이를 행함에 있어서, PVE는 어떠한 악의적인 변경이 있는 지를 검증할 수 있다.

이러한 증명서는 또한, 하나의 지리적인 영역 또는 오퍼레이터 도메인에서 부트된 장치가 새로운 오퍼레이터 도메인으로 이동하는 경우들에서도 유용하다. 이는 지오 추적 장치들(geo tracking devices)의 경우에 발생한다. 추적 데이터를 검증하기 위해서는, 장치가 성공적으로 부트되었는지, 그리고 발생되는 데이터가 진짜인지를 알 필요가 있다. 성공적인 스타트업의 증명서에는 장치에 의해 발생되는 데이터가 제공될 수 있다. 이러한 증명서 내에는, 스타트업이 성공적으로 달성되었을 때의 장치의 위치가 포함될 수 있다. 이후, 이러한 증명서의 제 3 당사자 수령인이 증명서의 확실성을 검증하고자 할 때, 이 수령인은 (바람직하게는, 장치 내의 위치 정보에 대한 장치에 의한 처리에 의존하지 않는 방법들, 예를 들어 GPS 기반의 방법들을 이용하여) 장치의 그 당시 위치(then-current location)를 체크하고, 얻어지는 그 당시 위치가 증명서에 포함된 위치와 일치하는 지를 확인할 수 있다. 일치하지 않으면, 증명서의 수령인은 그 장치에게, 또는 그 장치의 재검증을 관리하는 네트워크 엔티티에게, 새로운 보안 스타트업 및 이후 장치의 무결성의 재검증을 요청할 수 있다. 최근의 성공적인 스타트업이 일어났던 위치에 대한 정보를 포함하는 이러한 증명서는 또한, 목적지 네트워크가 최근의 성공적인 스타트업의 (위치를 포함하는) 환경 및 구성에 대한 정보를 알 필요가 있을 때, 도중에 실패하는 경우에도 유용하다.

여기에서 설명되는 바와 같이, PVM은 임의의 형태의 검증을 이용할 수 있다. 일반적으로, 3개의 주요 방법들은 AuV, SAV 및 원격 검증(RV)이다. 각 방법은 장치 무결성 검증과 개별적으로 관련되는 측정, 보고 및 시행의 단계들을 취급한다. AuV는 장치 상에서 3개의 모든 단계들을 국부적으로 수행한다. RV는 측정들을 국부적으로 수행한 다음, 이러한 측정들을 외부 엔티티에 보고한다. 시행은 외부 엔티티에 의해 수행된다. SAV는 보안 스타트업을 국부적으로 시행하고, 메트릭을 외부 엔티티에 보고하고, 재검증을 허용한다.

특히, SAV를 이용하는 장치는 신뢰 상태 측정들의 직접적인 평가를 수행하며, 최초 네트워크 접속을 설정한다. 평가의 결과는, 관련된 기준 메트릭들과 함께, 보안 게이트웨이(SeGW)와 같은 외부 엔티티에 보고(이하, 검증 보고)될 수 있다. 선택적으로, 기준 메트릭들 및 측정들의 서브세트가 보고될 수 있다.

상기 검증 보고는, H(e)NB의 특징들(이를 테면, 그 플랫폼 아키텍쳐, 보안 아키텍쳐, 보안 방침들 및 장치 증명)에 기초하여 H(e)NB의 신뢰 상태를 평가할 수 있게 한다. 이러한 검증 보고는 H(e)NB, TrE 성능들, 측정 및 검증 실행, TrE의 보안 방침 매니저 성능들, 측정 결과들, 플랫폼 레벨 증명 정보, 최근 부트 시간, 또는 부트 카운터에 대한 정보를 포함할 수 있다.

상기 장치에 대한 정보는, 예를 들어 제조업자, 메이크, 모델 넘버, 버전 넘버, 하드웨어 빌드 또는 버전 넘버, 또는 소프트웨어 빌드 또는 버전 넘버를 포함할 수 있다. TrE 성능들은, 예를 들어 측정, 검증, 보고 및 시행 성능들을 포함할 수 있다.

상기 측정 및 내부 검증 실행 정보는, 보안 스타트업 동안 신뢰 상태 측정 및 내부 검증을 수행하는 방법들을 포함할 수 있다. 예를 들어, 로드되는 컴포넌트들의 이름, 타입들 및 시퀀스들과 같은, 커버리지의 범위가 포함될 수 있다. 검증에 있어서의 신뢰 체인의 수 및 범위와 같은, 컴포넌트들의 검증 방법들이 포함될 수 있다. 보안 해쉬 알고리즘 1(SAH 1) 확장과 같은, 측정들 및 검증에 이용되는 알고리즘들이 포함될 수 있다. 또한, 스타트업 검증에서 커버되는 플랫폼 구성 레지스터(PCR)들과 같은 일련의 레지스터들이 포함될 수 있다.

TrE의 보안 방침 매니저 성능들은 보안 방침들의 구현 및 시행에 관한 정보를 포함할 수 있다. 측정 결과들은 서명된 PCR 값들과 같은, 내부적으로 보고 및 검증되는 실제 측정 값들을 포함할 수 있다. 플랫폼 레벨 검증 정보는, 일반적으로 H(e)NB에 관한, 또는 특정하게는 TrE에 관한 정보를 포함할 수 있다. 최근 부트 시간은 최근 보안 부트가 수행되었던 보안 타임 스탬프를 포함할 수 있다.

부트 카운터는, 전력 사이클이 발생하고 보안 부트 동작이 수행될 때 마다 증분되는 카운터의 값을 포함할 수 있다. 이러한 카운터는 보호되는 카운터로서, 리셋 및 반대로 될 수 없으며, 항상 전방(forward) 카운트된다. 장치가 처음으로 초기화될 때, 카운트 값은 제로로 초기화될 수 있다.

검증 보고는, 인터넷 키 교환 프로토콜 버전 2(IKEv2)와 같은 인증 프로토콜 내에 정보를 바인딩시킴으로써, 결합된 인증 및 검증 절차를 통해 H(e)NB에 바인딩될 수 있다. 이러한 검증 보고는 증명서를 포함할 수 있다. 선택적으로, 이러한 증명서에는 약간의 정보가 포함될 수 있다.

대안적으로, 이러한 검증 보고는 신뢰 상태 정보를 제공하는 신뢰성있는 제 3 당사자(TTP)에 대한 포인터 또는 참조를 포함할 수 있다. 예를 들어, 이러한 검증 보고는 신뢰 상태 정보를 포함하는 개별적인 장치-신뢰 증명서에 대한 참조를 포함할 수 있다.

평가 동안 겪게 되는 예외들에 응답하여, 외부 엔티티는 네트워크 액세스를 거부할 수 있다. 이러한 외부 엔티티는 또한 측정들 및 기준 메트릭을 평가할 수 있으며, H(e)NB에 의해 검출 또는 보고되지 않는 에러들을 검출할 수 있다. 대안적으로, H(e)NB는 제한된 (격리된) 네트워크 액세스를 허가할 수 있다. 그렇지 않으면, H(e)NB는 네트워크 액세스를 허가할 수 있다. H(e)NB는, 외부 장치로부터의 요청에 응답하여, 신뢰 상태 측정들을 수행, 평가 및 보고할 수 있다. 이러한 요청은 오퍼레이터에 의해 개시될 수 있다. 재검증은 스타트업 동안 검증되지 않은 요소들을 검증할 수 있다. 외부 엔티티는, 넌 코어(non-core) 검증 에러가 검출되면 교정 조치를 수행하라는 요청을 H(e)NB에게 전송할 수 있다. 예를 들어, H(e)NB는, 교정 요청에 응답하여, 소정의 상태로 되돌아갈 수 있다.

SAV는, 보안 스타트업 시에 부당 이용(exploit)이 검출되지 않을지라도, 표시자들을 통해 손상의 검출을 가능하게 한다. 보안 특성들에 의존하여, 손상된 장치들에 대해 교정 단계들이 수행될 수 있다. 이것은, 네트워크에 전송되는 표시자들이 코어 보안 스타트업이 손상되지 않았으며 그리고 보안 특성들이 통신되고 있음을 나타내기만 하면 가능하다. 코어가 손상되었으면, 로컬 시행으로 인해, 장치는 네트워크에 접속될 수 없을 것이다. 손상된 장치는 리부트 또는 재검증 요청에 의해 검출된다. 따라서, 더 높은 검출 가능성이 있다. 소프트웨어 업데이트들이 OTA를 통해 제공될 수 있으며, 어떠한 서비스 기술자들도 장치들을 대체할 필요가 없다. SAV는 CN에 대한 미세 입도의 액세스 제어를 가능하게 하며, 그리고 표시자들의 이용 및 로컬 시행으로 인해, RV 보다 더 낮은 대역폭 이용을 제공한다.

SAV는 AuV와 RV의 장점들을 결합함으로써, 장치 보안 특성들 및 검증 측정들에 있어서 보다 미세한 입도 및 보다 많은 가시성을 얻을 수 있게 한다. 이는 낮은 대역폭 이용, 자율적인 검증에 필적하는 로컬 장치 자원들, 손상된 장치들의 더 빠르고 더 용이한 검출을 제공하며, 손상된 장치들에 대한 격리된 네트워크의 이용을 가능하게 한다.

도 15는 WTRU(1510), H(e)NB(1520) 및 H(e)MS(1530)를 포함하는 무선 통신 네트워크(1500)의 예시적인 블록도이다. 도 15에 나타낸 바와 같이, WTRU(1510), H(e)NB(1520) 및 H(e)MS(1530)는 플랫폼 검증 및 관리를 수행하도록 구성된다.

전형적인 WTRU에서 발견될 수 있는 컴포넌트들 이외에, WTRU(1510)는 선택적으로 연결되는 메모리(1522)를 갖는 프로세서(1516), 적어도 하나의 트랜스시버(1514), 선택적인 배터리(1520) 및 안테나(1518)를 포함한다. 프로세서(1516)는, H(e)NB(1520)와 같은 기지국을 통해 자신에게 전달되는 PVM 기능들과 관련하여 보완적인 플랫폼 검증 및 관리 기능들을 수행하도록 구성된다. 트랜스시버(1514)는 프로세서(1516) 및 안테나(1518)와 통신하여, 무선 통신의 송수신을 용이하게 한다. WTRU(1514)에서 배터리(1520)가 이용되는 경우, 이 배터리는 트랜스시버(1514) 및 프로세서(1516)에 전력을 공급한다.

전형적인 H(e)NB에서 발견될 수 있는 컴포넌트들 이외에, H(e)NB(1520)는 선택적으로 연결되는 메모리(1515)를 갖는 프로세서(1517), 트랜스시버들(1519) 및 안테나(1521)을 포함한다. 프로세서(1517)는 PVM 방법을 구현하기 위해 플랫폼 검증 및 관리 기능들을 수행하도록 구성된다. 트랜스시버들(1519)은 프로세서(1517) 및 안테나(1521)와 통신하여, 무선 통신의 송수신을 용이하게 한다. H(e)NB(1520)는 H(e)MS(1530)에 연결되며, 이 H(e)MS(1530)는 선택적으로 연결되는 메모리(1534)를 갖는 프로세서(1533)를 포함한다.

비록 도 15에는 나타내지 않았지만, 전형적인 SeGW 및 PVE에서 발견될 수 있는 컴포넌트들 이외에, SeGW 및 PVE는 선택적으로 연결되는 메모리를 갖는 프로세서, 트랜스시버(들), 안테나(들) 및 통신 포트들을 포함할 수 있다. 프로세서는 PVM 방법을 구현하기 위해 플랫폼 검증 및 관리 기능들을 수행하도록 구성된다. 요구되는 경우, 트랜스시버들 및 통신 포트들은 프로세서 및 안테나와 통신하여, 무선 통신의 송수신을 용이하게 한다.

네트워크 컴포넌트들은 다양한 예들과 관련하여 본원에서 상세히 제시된 요구되는 PVM 기능들을 수행하도록 선택적으로 구성된다. 부가적으로, WTRU들은, 이를 테면 검증, 검증 및 다른 신뢰 팩터들과 관련하여, 보완적인 PVM 기능들에 의해, PVM 가능 네트워크 및 자원들에 대한 자신들의 신뢰성있는 액세스 및 이러한 PVM 가능 네트워크 및 자원들의 이용을 촉진시키도록 구성될 수 있다.

일 예로서, 각각의 컴포넌트들은 모두 액티브 엔티티들 간에 임무들의 PVM 최대 타입 분리 방식을 이용하도록 구성된다. 본원에서 설명된 바와 같이, 이것은 다양한 엔티티들 간에 특정의 정보를 전달하는 PVM 토큰을 이용함으로써 용이해진다.

실시예들

1. 플랫폼 검증 및 관리(platform validation and management, PVM)를 위한 방법으로서, 이 방법은 장치로부터의 검증 메시지에 응답하여 PVM 토큰을 수신하는 단계를 포함하며, 상기 PVM 토큰은 적어도 상기 장치로부터의 검증 정보를 포함한다.

2. 실시예 1에서, 상기 PVM 토큰으로부터의 소정의 정보를 이용하여 검증을 수행하는 단계를 더 포함한다.

3. 실시예 1 또는 2 중 어느 하나의 실시예에서, 실패한 컴포넌트들에 응답하여, 교정 및 재검증을 개시하기 위해, 장치 관리 시스템(DMS)에 실패 보고(failure report)를 전송하는 단계를 더 포함한다.

4. 실시예 1 내지 3 중 어느 하나의 실시예에서, 검증 결과를 갖는 변경된 PVM 토큰을 전송하는 단계를 더 포함한다.

5. 실시예 1 내지 4 중 어느 하나의 실시예에서, 상기 검증을 수행하는 단계는 적어도 하나의 실패 조건(failure condition)의 적용가능성(applicability)을 결정하는 단계를 포함한다.

6. 실시예 1 내지 5 중 어느 하나의 실시예에서, 상기 검증은 원격 검증(remote validation, RV), 자율적인 검증(autonomous validation, AuV), 반 자율적인 검증(semi-autonomous validation, SAV), F(full)-SAV, 최소 검증(minimal validation) 또는 파라미터 검증(parametric validation) 중에서 적어도 하나를 이용하여 수행된다.

7. 실시예 1 내지 6 중 어느 하나의 실시예에서, 상기 검증 정보는 장치 아이덴티티, 장치 정보, 신뢰성있는 환경(TrE) 정보, 검증 데이터, 검증 바인딩(verification binding), 컴포넌트들에 대한 컴포넌트 표시자들의 정렬된 컴포넌트 리스트 중에서 적어도 하나를 포함한다.

8. 실시예 1 내지 7 중 어느 하나의 실시예에서, 상기 검증을 수행하는 단계는, TrE를 신뢰할 수 없는 것으로 결정하는 것, 무결성 측정/검증 데이터 불일치를 결정하는 것, 컴포넌트에 대해 누락된(missing) RIM(Reference Integrity Metrics)을 결정하는 것과, 로드된 컴포넌트 방침 실패 리스트를 결정하는 것과, 만료된 장치 또는 RIM 증명서를 결정하는 것 중에서 적어도 하나를 포함한다.

9. 실시예 1 내지 8 중 어느 하나의 실시예에서, 상기 PVM 토큰은 검증 TrE의 아이덴티티 및 검증 프로세스에 바인딩(binding)된다.

10. 실시예 1 내지 9 중 어느 하나의 실시예에서, 검증 새로움(validation freshness)은, 상기 PVM 토큰을 타임 스탬핑(time stamping)하고, 상기 PVM 토큰을 전달하는 모든 엔티티에 의한 시간 정렬 리스트(time-ordered list)에 부가함으로써 제어된다.

11. 실시예 1 내지 10 중 어느 하나의 실시예에서, RIM 증명서 내의 장치 아이덴티티를 이용하여 개별화(individualization)를 확립하는 단계를 더 포함한다.

12. 실시예 1 내지 11 중 어느 하나의 실시예에서, 격리(quarantine), 화이트 리스트(white list), 블랙 리스트(black list) 및 그레이 리스트(grey list) 적용가능성을 결정하기 위해, 상기 DMS에 상기 PVM 토큰을 전송하는 단계를 더 포함한다.

13. 실시예 1 내지 12 중 어느 하나의 실시예에서, 상기 그레이 리스트는 네트워크에 새로운 장치들, 연장된 시간 기간 동안 접속되지 않은 장치들, 의심스러운 행동을 하는 장치들, 및 보안 경고가 존재하는 장치들 중에서 적어도 하나를 포함한다.

14. 실시예 1 내지 13 중 어느 하나의 실시예에서, 오퍼레이터 RIM 쉴딩(shielding)은 다양한 외부 소스들로부터 비롯되는 장치 컴포넌트들에 대한 소정의 RIM 증명서들을 오퍼레이터 RIM 증명서들로 대체한다.

15. 실시예 1 내지 14 중 어느 하나의 실시예에서, 상기 PVM 토큰에서 수신된 정보를 체크하기 위해, 검증 데이터베이스에 질문(query)이 전송된다.

16. 실시예 1 내지 15 중 어느 하나의 실시예에서, 소정의 식별자에 기초하여 구성 방침(configuration policy)을 검색하기 위해, 구성 데이터베이스에 질문이 전송된다.

17. 실시예 1 내지 16 중 어느 하나의 실시예에서, 검색되는 구성 방침은 평가된다.

18. 실시예 1 내지 17 중 어느 하나의 실시예에서, 실패 조건에 응답하여, 검증 데이터베이스 매니저에게 메시지가 전송된다.

19. 플랫폼 검증 및 관리(PVM)에 결합되는 장치의 검증을 수행하는 방법으로서, 이 방법은 상기 장치의 적어도 하나의 미리 지정된 컴포넌트의 무결성 체크(integrity check)를 수행하는 단계 및 무결성 체크 결과를 저장하는 단계를 포함한다.

20. 실시예 19에 있어서, 상기 장치 상에서 보안 스타트업 체크(secure start-up check)를 수행하는 단계 및 보안 스타트업 체크 결과를 저장하는 단계를 더 포함한다.

21. 실시예들 19 또는 20 중 어느 하나의 실시예에 있어서, 상기 무결성 체크 결과 및 상기 보안 스타트업 체크 결과에 기초하여 검증 메시지를 형성하는 단계를 더 포함한다.

22. 실시예들 19 내지 21 중 어느 하나의 실시예에 있어서, 상기 검증 메시지를 상기 PVM에 전송하는 단계를 더 포함한다.

23. 실시예들 19 내지 22 중 어느 하나의 실시예에 있어서, 신뢰성있는 환경(TrE) 컴포넌트의 로컬 검증이 성공적인 경우에만 각각의 TrE 컴포넌트가 로드되도록 보장하기 위해, 스테이지들에서 보안 스타트업을 수행하는 단계를 더 포함한다.

24. 실시예들 19 내지 23 중 어느 하나의 실시예에 있어서, 제 1 스테이지에서, RoT(Root of Trust)에 의존하는 보안 스타트업을 통해 상기 TrE의 컴포넌트들을 로드하는 단계를 더 포함한다.

25. 실시예들 19 내지 24 중 어느 하나의 실시예에 있어서, 제 2 스테이지에서, 상기 PVM과의 통신을 허가하기 위해 상기 TrE 외부의 컴포넌트들을 로드하는 단계를 더 포함한다.

26. 실시예들 19 내지 25 중 어느 하나의 실시예에 있어서, 상기 장치의 나머지 컴포넌트들을 로드하는 단계를 더 포함한다.

27. 실시예들 19 내지 26 중 어느 하나의 실시예에 있어서, 상기 무결성 체크를 수행하는 단계는 적어도 하나의 신뢰성있는 기준 값 및 상기 TrE에 기초한다.

28. 실시예들 19 내지 27 중 어느 하나의 실시예에 있어서, 상기 검증 메시지는 상기 제 1, 2 스테이지들 동안 확립되는 무결성의 측정으로서 로컬 통과/실패 표시자를 포함한다.

29. 실시예들 19 내지 28 중 어느 하나의 실시예에 있어서, 폴백 코드 베이스(fallback code base)를 더 포함한다.

30. 실시예들 19 내지 29 중 어느 하나의 실시예에 있어서, 상기 폴백 코드 베이스를 개시하는 단계는 RIM들을 포함하는 주 코드 베이스의 소프트웨어 업데이트를 트리거하는 단계를 포함한다.

31. 실시예들 19 내지 30 중 어느 하나의 실시예에 있어서, 폴백 코드 베이스가 로드되면, 디스트레스 신호(distress signal)를 전송하는 단계를 더 포함한다.

32. 실시예들 19 내지 31 중 어느 하나의 실시예에 있어서, 폴백 코드(FBC) 이미지는 장치의 교정을 용이하게 하며, 보안 메모리에 저장된다.

33. 실시예들 19 내지 32 중 어느 하나의 실시예에 있어서, 상기 무결성 체크는 등록된 컴포넌트들 만이 활성화됨을 결정한다.

34. 실시예들 19 내지 33 중 어느 하나의 실시예에 있어서, 상기 등록된 컴포넌트들은 메모리 내에 로드함으로써 활성화된다.

35. 실시예들 19 내지 34 중 어느 하나의 실시예에 있어서, 상기 등록된 컴포넌트들은 무결성 증명된 상태(integrity-proven state)로 시작함으로써 활성화된다.

36. 실시예들 19 내지 35 중 어느 하나의 실시예에 있어서, 제 2 무결성 체크를 수행하는 단계를 더 포함한다.

37. 실시예들 19 내지 36 중 어느 하나의 실시예에 있어서, 상기 장치가 성공적인 네트워크 접속을 완료하는 경우에만, 제 2 무결성 체크를 수행하는 단계를 더 포함한다.

38. 실시예들 19 내지 37 중 어느 하나의 실시예에 있어서, 상기 제 2 무결성 체크는, 상기 장치 중 하나에 의해, 또는 메시지에 응답하여 개시된다.

39. 실시예들 19 내지 38 중 어느 하나의 실시예에 있어서, 상기 무결성 체크 결과를 저장하는 단계는 보호되는 저장 위치 내에서 이루어진다.

40. 실시예들 19 내지 39 중 어느 하나의 실시예에 있어서, 상기 검증 메시지는 암호적으로 서명된 스테이트먼트(cryptographically signed statement)를 포함한다.

41. 실시예들 19 내지 40 중 어느 하나의 실시예에 있어서, 상기 검증 메시지는 상기 무결성 체크와 이후의 인증 절차 간의 바인딩(binding)의 증거를 포함한다.

42. 실시예들 19 내지 41 중 어느 하나의 실시예에 있어서, 상기 검증 메시지는 상기 보안 스타트업 체크와 이후의 인증 절차 간의 바인딩의 증거를 포함한다.

43. 실시예들 19 내지 42 중 어느 하나의 실시예에 있어서, 상기 검증 메시지는 타임 스탬프를 포함한다.

44. 실시예들 19 내지 43 중 어느 하나의 실시예에 있어서, 상기 검증 메시지는 상기 무결성 체크 및 상기 스타트업 체크 이전에 취해지는 제 1 타임 스탬프 및 상기 무결성 체크 및 상기 스타트업 체크 이후에 취해지는 제 2 타임 스탬프를 포함한다.

45. 실시예들 19 내지 44 중 어느 하나의 실시예에 있어서, 상기 검증 메시지는 장치 구성의 표시를 포함한다.

46. 실시예들 19 내지 45 중 어느 하나의 실시예에 있어서, 상기 검증 메시지는 장치 컴포넌트의 보안 특성의 표시를 포함한다.

47. 실시예들 19 내지 46 중 어느 하나의 실시예에 있어서, 상기 검증 메시지에 응답하여 상기 PVM으로부터 결정 메시지를 수신하는 단계를 더 포함한다.

48. 실시예들 19 내지 47 중 어느 하나의 실시예에 있어서, 상기 결정 메시지는 상기 장치와 관련된 네트워크 특권(network privilege)의 표시를 포함한다.

49. 실시예들 19 내지 48 중 어느 하나의 실시예에 있어서, 신뢰성있는 자원(trusted resoruce, TR)이 상기 무결성 체크를 수행하는 것을 더 포함한다.

50. 실시예들 19 내지 49 중 어느 하나의 실시예에 있어서, 신뢰성있는 자원(TR)이 상기 보안 스타트업 체크를 수행하는 것을 더 포함한다.

51. 실시예들 19 내지 50 중 어느 하나의 실시예에 있어서, 신뢰성있는 자원(TR)이 상기 검증 메시지를 형성하는 것을 더 포함한다.

52. 실시예들 19 내지 51 중 어느 하나의 실시예에 있어서, 신뢰성있는 자원(TR)이 상기 PVM으로부터 상기 결정 메시지를 수신하는 것을 더 포함한다.

53. 실시예들 19 내지 52 중 어느 하나의 실시예에 있어서, 상기 FBC는 정규 코드(normal code)의 일부를 지우거나 삭제하고, 재검증을 위해 상기 장치를 리부트시킨다.

54. 플랫폼 검증 및 관리(PVM)를 용이하게 하기 위한 플랫폼 검증 엔티티(platform validation entity, PVE)로서, 상기 PVE는 장치로부터의 검증 메시지에 응답하여 PVM 토큰을 수신하도록 구성되며, 상기 PVM 토큰은 적어도 상기 장치로부터의 검증 정보를 포함한다.

55. 실시예 54에서, 상기 PVE는 또한 상기 PVM 토큰으로부터의 소정의 정보를 이용하여 검증을 수행하도록 구성된다.

56. 실시예들 54 또는 55 중 어느 하나의 실시예에 있어서, 상기 PVE는 또한 실패한 컴포넌트들에 응답하여, 교정 및 재검증을 개시하기 위해, 장치 관리 시스템(DMS)에 실패 보고를 전송하도록 구성된다.

57. 실시예들 54 내지 56 중 어느 하나의 실시예에 있어서, 상기 PVE는 또한 검증 결과를 갖는 변경된 PVM 토큰을 전송하도록 구성된다.

58. 실시예들 54 내지 57 중 어느 하나의 실시예에 있어서, 상기 검증 정보는 적어도 보안 방침 속성들(security policy attributes)을 포함한다.

59. 플랫폼 검증 및 관리(PVM)를 통해 검증을 수행하는 장치로서, 상기 장치의 적어도 하나의 미리 지정된 컴포넌트의 무결성 체크를 수행하고, 무결성 체크 결과를 메모리에 저장하도록 구성되는 프로세서를 포함한다.

60. 실시예 59에 있어서, 상기 프로세서는 또한 상기 장치에 대해 보안 스타트업 체크를 수행하고, 보안 스타트업 체크 결과를 상기 메모리에 저장하도록 구성된다.

61. 실시예들 59 또는 60 중 어느 하나의 실시예에 있어서, 상기 프로세서는 또한 상기 무결성 체크 결과 및 상기 보안 스타트업 체크 결과에 기초하여 검증 메시지를 형성하도록 구성된다.

62. 실시예들 59 내지 61 중 어느 하나의 실시예에 있어서, 상기 검증 메시지를 상기 PVM에 전송하기 위한 송신기를 더 포함한다.

63. 플랫폼 검증 및 관리(PVM)를 용이하게 하기 위한 장치 관리 시스템(DMS)으로서, 상기 DMS는 장치로부터의 검증 메시지에 응답하여, 플랫폼 검증 엔티티(PVE)로부터 실패 보고 및 PVM 토큰 중 적어도 하나를 수신하여, 실패한 컴포넌트들에 응답하여 교정 및 재검증을 개시하도록 구성되며, 상기 PVM 토큰은 적어도 상기 장치로부터의 검증 정보를 포함한다.

64. 실시예 63에 있어서, 상기 DMS는 또한 적어도 실패한 컴포넌트들에 대해 업데이트들의 이용가능성(availability)을 결정하도록 구성된다.

65. 실시예들 63 또는 64 중 어느 하나의 실시예에 있어서, 상기 DMS는 이용가능한 업데이트들에 대해 OTA(over-the-air) 업데이트들을 준비하도록 구성된다.

66. 실시예들 63 내지 65 중 어느 하나의 실시예에 있어서, 상기 DMS는 또한 검증 데이터베이스 내에서의 상기 이용가능한 업데이트들에 대한 신뢰성있는 기준 값들의 존재를 보장하도록 구성된다.

67. 실시예들 63 내지 66 중 어느 하나의 실시예에 있어서, 상기 DMS는 또한, 변경된 PVM 토큰 및 재검증 표시를 보안 게이트웨이(SeGW)에 전송하도록 구성된다.

68. 실시예들 63 내지 66 중 어느 하나의 실시예에 있어서, 상기 DMS는 또한 재검증 트리거(revalidation trigger)를 상기 장치에 전송하도록 구성된다.

69. 무선 통신에서 이용하기 위한 방법으로서, 플랫폼 검증 및 관리(PVM)를 수행하는 단계를 포함한다.

70. 실시예 69에 있어서, 상기 PVM을 수행하는 단계는 반 자율적인 검증(SAV)을 수행하는 단계를 포함한다.

71. 실시예들 69 또는 70 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 플랫폼 검증 엔티티(PVE) 내에서 실시되는 무선 장치의 검증을 포함한다.

72. 실시예들 69 내지 71 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 다음을 포함한다.

73. 실시예들 69 내지 72 중 어느 하나의 실시예에 있어서, 로드될 신뢰성있는 환경 컴포넌트의 로컬 검증이 성공적인 경우에만 각각의 신뢰성있는 환경 컴포넌트가 로드되도록 보장하기 위해, 스테이지들에서 보안 스타트업을 수행하는 단계를 더 포함한다.

74. 실시예들 69 내지 73 중 어느 하나의 실시예에 있어서, 제 1 스테이지에서, RoT(Root of Trust)에 의존하는 보안 스타트업을 통해 상기 신뢰성있는 환경의 컴포넌트들을 로드하는 단계를 더 포함한다.

75. 실시예들 69 내지 74 중 어느 하나의 실시예에 있어서, 제 2 스테이지에서, 보안 게이트웨이(SeGW)와 기본적인 통신을 수행하는 데에 요구되는 신뢰성있는 환경 외부의 컴포넌트들을 로드하는 단계를 더 포함한다.

76. 실시예들 69 내지 75 중 어느 하나의 실시예에 있어서, 상기 장치의 나머지 컴포넌트들을 로드하는 단계를 더 포함한다.

77. 실시예들 69 내지 76 중 어느 하나의 실시예에 있어서, 데이터를 수집하는 단계 및 상기 데이터를 상기 SeGW에 전달하는 단계를 더 포함하며, 상기 데이터는 장치 아이덴티티; H(e)NB(Enhanced Home Node-B)와 관련된 정보; 신뢰성있는 환경(TrE)과 관련된 정보; 검증 데이터; 검증 바인딩; 및 컴포넌트들에 대한 컴포넌트 표시자들의 정렬된 리스트 중에서 적어도 하나를 포함한다.

78. 실시예들 69 내지 77 중 어느 하나의 실시예에 있어서, 인증된 H(e)NB에 대한 접속이 끊기는 것에 응답하여, 상기 장치를 재검증하는 단계를 더 포함한다.

79. 실시예들 69 내지 78 중 어느 하나의 실시예에 있어서, 상기 PVE에 의해 수행되는 검증 동안 실패 조건들을 결정하는 단계를 더 포함하며, 상기 실패 조건들은, 전달되는 TrE 정보에 기초하여 상기 TrE를 신뢰성이 없는 것으로서 결정하는 것; 무결성 측정/검증 데이터 불일치를 결정하는 것; 컴포넌트에 대해 누락된 RIM(Reference Integrity Metrics)을 결정하는 것; 로드된 컴포넌트들의 리스트(Clist) 방침 실패를 결정하는 것; 만료된 장치 또는 RIM 증명서를 결정하는 것; 및 상기 SeGW가 네트워크 액세스 및 장치 인증을 거부하고 미래의 인증 시도들을 차단하는 것 중에서, 적어도 하나를 포함한다.

80. 실시예들 69 내지 79 중 어느 하나의 실시예에 있어서, 상기 검증 TrE의 아이덴티티 및 상기 검증 프로세스에 바인딩되는 PVM 토큰을 발생시키는 단계를 더 포함한다.

81. 실시예들 69 내지 80 중 어느 하나의 실시예에 있어서, 검증 새로움은 상기 토큰들을 타임 스탬프들에 기초하게 함으로써 제어되며, 상기 타임 스탬프들은 처음에 상기 SeGW에 의해 발생되어, 상기 토큰이 전달되는 모든 엔티티에 의한 시간 정렬 리스트에 부가된다.

82. 실시예들 69 내지 81 중 어느 하나의 실시예에 있어서, 검증 새로움은, 상기 제 1, 2 스테이지들을 완료하고, 상기 SeGW 및 PVE와의 통신을 개시하고, 상기 SeGW/PVE에 의해 공급되는 논스(nonce)를 이용하여, 제 3 스테이지 검증 데이터의 결과를 상기 SeGW에 전달하기 전에, 제 3 스테이지 체크의 추가의 검증을 바인딩함으로써 제어된다.

83. 실시예들 69 내지 82 중 어느 하나의 실시예에 있어서, 상기 장치가 백홀 링크(backhaul link)를 확립하기를 원하는 오퍼레이터에 의해 RIM 증명서들을 발생시키는 단계를 더 포함한다.

84. 실시예들 69 내지 83 중 어느 하나의 실시예에 있어서, RIM 매니저는 플랫폼 검증을 위해 상기 PVE 및 DMS를 구성하고, 상기 DMS는 상기 장치 상의 상기 RIM 증명서들이 설치될 컴포넌트들에 대해 증명서 업데이트 액션을 수행하도록 구성되며, 그리고 상기 방법은 상기 DMS로 하여금 상기 장치의 스테이트풀(stateful) 재검증을 강요하는 단계를 더 포함한다.

85. 실시예들 69 내지 84 중 어느 하나의 실시예에 있어서, 로크(lock)될 상기 컴포넌트의 일부를 대칭 키로 암호화하고; 상기 오퍼레이터로부터의 허가에 의해서만 액세스될 수 있는 보호 및 제어되는 공간 내의 TrE에 복호화 키를 전송하고; 그리고 상기 PVE에게 이러한 컴포넌트에 대한 표시자가 제시될 때, 상기 TrE에 대한 허가 데이터를 해제하는 것 중에서 적어도 하나를 수행함으로써, 상기 오퍼레이터가 상기 장치의 동작을 제어하는 단계를 더 포함한다.

86. 실시예들 69 내지 85 중 어느 하나의 실시예에 있어서, 상기 RIM 증명서들 내의 상기 장치 아이덴티티를 이용함으로써 PVM에 기초하여 개별화를 확립하는 단계를 더 포함한다.

87. 실시예들 69 내지 86 중 어느 하나의 실시예에 있어서, 장치 아이덴티티와 컴포넌트 표시자의 쌍(pair)들에 대해 오퍼레이터의 서명을 적용하는 것에 기초하여 개별화를 확립하는 단계를 더 포함한다.

88. 실시예들 69 내지 87 중 어느 하나의 실시예에 있어서, 장치들에 대한 블랙 리스트들을 확립하는 단계 및 상기 블랙 리스트들에 기초하여 네트워크 액세스를 허가하지 않는 단계를 더 포함하고, 상기 블랙 리스트들은 적어도 상기 장치 아이덴티티를 포함한다.

89. 실시예들 69 내지 88 중 어느 하나의 실시예에 있어서, 장치들에 대한 격리 네트워크(quarantine network)를 확립하는 단계를 더 포함하며, 상기 SeGW는 코어 네트워크에 대한 시행 장벽(enforcement barrier)의 역할을 한다.

90. 실시예들 69 내지 89 중 어느 하나의 실시예에 있어서, 네트워크에 새로운 장치들, 연장된 시간 기간 동안 접속되지 않은 장치들, 의심스러운 행동을 하는 장치들 및 보안 경고가 존재하는 장치들 중에서 적어도 하나를 포함하는 격리되는 장치들의 그레이 리스트를 확립하는 단계를 더 포함한다.

91. 실시예들 69 내지 90 중 어느 하나의 실시예에 있어서, 알려지지 않은 컴포넌트들을 로드하고, 알려지지 않은 컴포넌트들을 로드하는 것을 거부하고, 컴포넌트들을 디스에이블(disable)시키는 것 중에서, 적어도 하나를 포함하는 진단 검증(diagnostic validation)을 수행하는 단계를 더 포함한다.

92. 실시예들 69 내지 91 중 어느 하나의 실시예에 있어서, 로컬 검증 프로세스에서 이용되는 표시자들 또는 기준값들을 전송하는 것을 포함하는 최소 검증을 수행하는 단계를 더 포함한다.

93. 실시예들 69 내지 92 중 어느 하나의 실시예에 있어서, 인증 증명서들 내에 검증을 바인딩하는 단계를 더 포함한다.

94. 실시예들 69 내지 93 중 어느 하나의 실시예에 있어서, 상기 증명서는 발행자, 그것의 SeGW, 또는 이러한 증명서들의 관리를 담당하는 하위 엔티티에 의해 서명되는 서명된 데이터 세트이며, 그리고 상기 증명서 내의 서명된 데이터는 적어도 상기 장치 아이덴티티, 인증 및 검증에 이용되는 장치 공개 키, 및 컴포넌트 리스트를 포함한다.

95. 실시예들 69 내지 94 중 어느 하나의 실시예에 있어서, 상기 SeGW에 어떠한 검증 데이터도 전송하지 않는 자율적인 검증을 수행하는 단계 및 상기 보안 스타트업 프로세스의 스테이지들에 따라 관리 아이덴티티들을 그룹화하는 단계를 더 포함한다.

96. 실시예들 69 내지 95 중 어느 하나의 실시예에 있어서, 상기 장치 및 상기 SeGW가, 상기 장치가 상기 관리 아이덴티티들 중 하나에 대해 인증되는, 상기 장치와의 제 1 인증 프로토콜을 완료하면, 상기 장치 아이덴티티 및 인증 데이터를 확립된 보안 채널 상으로 전송하는 단계를 더 포함한다.

97. 실시예들 69 내지 96 중 어느 하나의 실시예에 있어서, 보안 메모리 카드들로의 컴포넌트 코드들의 전송을 안전하게 하는 단계를 더 포함한다.

98. 실시예들 69 내지 97 중 어느 하나의 실시예에 있어서, 다이제스트 값(digest vlaue)들을 암호화로 대체하는 단계를 더 포함한다.

99. 실시예들 69 내지 98 중 어느 하나의 실시예에 있어서, 상기 검증 메시지 내에 장치 위치 정보를 포함시키는 단계를 더 포함한다.

100. 실시예들 69 내지 99 중 어느 하나의 실시예에 있어서, 상기 장치는 장치 식별자(Dev_ID)에 의해 식별된다.

101. 실시예들 69 내지 100 중 어느 하나의 실시예에 있어서, 상기 Dev_ID는 FQDN(Fully Qualified Domain Name), URL(Uniform Resource Locator), URN(Uniform Resource Name), URI(Uniform Resource Identifier), MAC(Medium Access Control) 어드레스, 인터넷 프로토콜(IP) 어드레스, IP 호스트 식별자, 서브넷 어드레스(subnet address), IMEI(International Mobile Equipment Identity), IMEISV(International Mobile station Equipment Identity and Software Version) 넘버, ESN(Electronic Serial Number), 이동 장비 식별자(Mobile Equipment Identifier), IP 멀티미디어 코어 네트워크 서브시스템 가입자 ID, 또는 MSISDN(Mobile Station Integrated Services Data Network) ID 이다.

102. 실시예들 69 내지 101 중 어느 하나의 실시예에 있어서, 상기 Dev_ID는 장치에 대한 고유의 신뢰성있고 명백한 식별을 가능하게 하는 문자숫자식 또는 머신 판독가능한 포맷이다.

103. 실시예들 69 내지 102 중 어느 하나의 실시예에 있어서, 하나 이상의 신뢰성있는 기준 값들 및 상기 TrE에 기초하여 스타트업시 장치 무결성 체크를 수행하는 단계를 더 포함한다.

104. 실시예들 69 내지 103 중 어느 하나의 실시예에 있어서, 상기 TrE는 PVM에 대해 요구되는 최소의 기능들을 포함하는 엔티티이다.

105. 실시예들 69 내지 104 중 어느 하나의 실시예에 있어서, 상기 SeGW와 네트워크 인증을 수행하고, 상기 장치 아이덴티티를 포함하는 데이터를 전송하는 단계를 더 포함한다.

106. 실시예들 69 내지 105 중 어느 하나의 실시예에 있어서, 상기 제 1, 2 스테이지들 동안 확립되는 무결성의 측정으로서 로컬 통과/실패 표시자를 포함하는 측정 메시지를 준비하는 단계를 더 포함한다.

107. 실시예들 69 내지 106 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 기본(Basic) SAV를 포함한다.

108. 실시예들 69 내지 107 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 풀(Full) SAV를 포함한다.

109. 실시예들 69 내지 108 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 플랫폼 검증을 포함한다.

110. 실시예들 69 내지 109 중 어느 하나의 실시예에 있어서, 상기 플랫폼 검증은 코어 네트워크(CN)가 불량한 장치로부터 보호될 수 있게 한다.

111. 실시예들 69 내지 110 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 상기 장치와 상기 CN 간의 간접적인 통신을 이용하는 단계를 포함한다.

112. 실시예들 69 내지 111 중 어느 하나의 실시예에 있어서, 상기 플랫폼 검증은 증명된 보안 상태의 장치가 상기 CN 내의 엔티티들과 통신할 수 있도록 보장한다.

113. 실시예들 69 내지 112 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 검증 데이터를 보고하는 단계를 포함한다.

114. 실시예들 69 내지 113 중 어느 하나의 실시예에 있어서, 상기 검증 데이터를 보고하는 단계는 검증 데이터를 수집하는 단계 및 상기 검증 데이터를 상기 SeGW에 보고하는 단계를 포함한다.

115. 실시예들 69 내지 114 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 PVE를 이용하는 검증을 포함한다.

116. 실시예들 69 내지 115 중 어느 하나의 실시예에 있어서, 상기 PVE는 상기 장치의 유효성(validity)을 결정한다.

117. 실시예들 69 내지 116 중 어느 하나의 실시예에 있어서, 상기 PVE는 방침 결정 포인트(PDP)이다.

118. 실시예들 69 내지 117 중 어느 하나의 실시예에 있어서, 상기 PVE는 실패 조건을 보고한다.

119. 실시예들 69 내지 118 중 어느 하나의 실시예에 있어서, 상기 실패 조건은 무효한 TrE, 검증 데이터 실패, Clist 방침 실패, 또는 검증전(pre-validation) 장치 인증 실패이다.

120. 실시예들 69 내지 119 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 재검증을 포함한다.

121. 실시예들 69 내지 120 중 어느 하나의 실시예에 있어서, 상기 재검증은 주기적인 재검증을 포함한다.

122. 실시예들 69 내지 121 중 어느 하나의 실시예에 있어서, 상기 주기적인 재검증은, 불량 코드가 실행되는 위험이 감소되면서, 상기 장치가 정의된 상태에서 작동하고 있음을 검증하는 것을 포함한다.

123. 실시예들 69 내지 122 중 어느 하나의 실시예에 있어서, 상기 재검증은 인증 절차를 개시하는 것을 포함한다.

124. 실시예들 69 내지 123 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 장치에 의해 개시되는 재검증(device initiated revalidation)을 포함한다.

125. 실시예들 69 내지 124 중 어느 하나의 실시예에 있어서, 상기 장치에 의해 개시되는 재검증은 주기적으로 수행된다.

126. 실시예들 69 내지 125 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 네트워크에 의해 개시되는 재검증을 포함한다.

127. 실시예들 69 내지 126 중 어느 하나의 실시예에 있어서, 상기 네트워크에 의해 개시되는 재검증은 주기적으로 수행된다.

128. 실시예들 69 내지 127 중 어느 하나의 실시예에 있어서, 상기 네트워크에 의해 개시되는 재검증은 보안을 위해 필요할 때에 수행된다.

129. 실시예들 69 내지 128 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 플랫폼 관리(Platform Management)를 포함한다.

130. 실시예들 69 내지 129 중 어느 하나의 실시예에 있어서, 상기 플랫폼 관리는 상기 DMS가 장치 관리를 수행하는 것을 포함한다.

131. 실시예들 69 내지 130 중 어느 하나의 실시예에 있어서, 상기 플랫폼 관리는 수신되어 저장되는 장치 정보에 기초한다.

132. 실시예들 69 내지 131 중 어느 하나의 실시예에 있어서, 상기 장치는 H(e)NB이다.

133. 실시예들 69 내지 132 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 토큰 전달(token passing)을 포함한다.

134. 실시예들 69 내지 133 중 어느 하나의 실시예에 있어서, 상기 PVM은 비동기적인 프로세스이다.

135. 실시예들 69 내지 134 중 어느 하나의 실시예에 있어서, 상기 SeGW는 상기 검증 프로세스에 고유하게 관련되는 토큰의 발생 및 관리를 담당한다.

136. 실시예들 69 내지 135 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 공중 인터넷(public Internet)을 통한 검증을 포함한다.

137. 실시예들 69 내지 136 중 어느 하나의 실시예에 있어서, 상기 공중 인터넷을 통한 검증은 최초의 검증을 안전하게 하기 위한 특별한 요건들을 만족시키는 것을 포함한다.

138. 실시예들 69 내지 137 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 오퍼레이터 RIM 쉴딩을 포함한다.

139. 실시예들 69 내지 138 중 어느 하나의 실시예에 있어서, 상기 오퍼레이터 RIM 쉴딩은, 다양한 외부 소스들로부터 비롯되는 장치 컴포넌트들에 대한 다수의 RIM 증명서들을, 상기 장치가 백홀 링크를 확립하기를 원하는 오퍼레이터에 의해 발생되는 RIM 증명서들로 대체한다.

140. 실시예들 69 내지 139 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 오퍼레이터 컴포넌트 로크인(lock-in)을 포함한다.

141. 실시예들 69 내지 140 중 어느 하나의 실시예에 있어서, 상기 오퍼레이터 컴포넌트 로크인은 상기 오퍼레이터가 이질적인 네트워크(foreign network) 내의 장치 또는 그 컴포넌트들의 동작을 제어하는 것을 포함한다.

142. 실시예들 69 내지 141 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 개별화를 포함한다.

143. 실시예들 69 내지 142 중 어느 하나의 실시예에 있어서, 상기 개별화는 누가 상기 장치의 구성 및 신뢰성을 관리하는 지를 증명하는 것을 포함한다.

144. 실시예들 69 내지 143 중 어느 하나의 실시예에 있어서, 상기 개별화는 상기 장치에 대한 어드레싱이 서명된 데이터를 상기 장치에 제공하는 것을 포함한다.

145. 실시예들 69 내지 144 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 장치를 블랙 리스트화(blacklisting)하는 것을 포함한다.

146. 실시예들 69 내지 145 중 어느 하나의 실시예에 있어서, 상기 장치를 블랙 리스트화하는 것은, 장치들에 대한 블랙 리스트를 정하고, 상기 블랙 리스트에 기초하여 네트워크 액세스를 허가하지 않는 것을 포함한다.

147. 실시예들 69 내지 146 중 어느 하나의 실시예에 있어서, 상기 블랙 리스트는 장치 특정의 블랙 리스트이다.

148. 실시예들 69 내지 147 중 어느 하나의 실시예에 있어서, 상기 블랙 리스트는 네트워크 폭(wide)의 블랙 리스트이다.

149. 실시예들 69 내지 148 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 장치를 화이트 리스트화(whitelisting)하는 것을 포함한다.

150. 실시예들 69 내지 149 중 어느 하나의 실시예에 있어서, 상기 장치를 화이트 리스트화하는 것은, 장치들에 대한 화이트 리스트를 정하고, 상기 화이트 리스트에 기초하여 네트워크 액세스를 허가하는 것을 포함한다.

151. 실시예들 69 내지 150 중 어느 하나의 실시예에 있어서, 상기 화이트 리스트는 장치 특정의 화이트 리스트이다.

152. 실시예들 69 내지 151 중 어느 하나의 실시예에 있어서, 상기 화이트 리스트는 네트워크 폭의 화이트 리스트이다.

153. 실시예들 69 내지 152 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 네트워크들을 격리하는 것을 포함한다.

154. 실시예들 69 내지 153 중 어느 하나의 실시예에 있어서, 상기 SeGW는 어떤 장치들이 격리되는 지를 결정한다.

155. 실시예들 69 내지 154 중 어느 하나의 실시예에 있어서, 격리되는 장치는 상기 CN을 직접 액세스할 수 없으며, 제한된 서비스를 제공한다.

156. 실시예들 69 내지 155 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 파라미터 검증(Parametric Validation)을 포함한다.

157. 실시예들 69 내지 156 중 어느 하나의 실시예에 있어서, 상기 파라미터 검증은 검증 동안 보통문으로(in clear) 파라미터들을 전송하는 것을 포함한다.

158. 실시예들 69 내지 157 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 진단 검증(Diagnostic Validation)을 포함한다.

159. 실시예들 69 내지 158 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 알려지지 않은 컴포넌트들을 로딩하는 것을 포함한다.

160. 실시예들 69 내지 159 중 어느 하나의 실시예에 있어서, 상기 알려지지 않은 컴포넌트들을 로딩하는 것은, 상기 장치 내에서 RIM들을 갖지 않으면서 컴포넌트들이 로드될 수 있게 한다.

161. 실시예들 69 내지 160 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 실패 조건의 PVM 진단을 포함한다.

162. 실시예들 69 내지 161 중 어느 하나의 실시예에 있어서, 상기 DMS는 상기 장치 상의 실패한 컴포넌트들을 교체하는 것을 생략하도록 구성된다.

163. 실시예들 69 내지 162 중 어느 하나의 실시예에 있어서, 상기 DMS는 상기 Clist 내의 모든 컴포넌트들을 정확한 것들로 대체하도록 구성된다.

164. 실시예들 69 내지 163 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 알려지지 않은 컴포넌트들의 로딩을 거부하는 것을 포함한다.

165. 실시예들 69 내지 164 중 어느 하나의 실시예에 있어서, 상기 진단 검증은, 컴포넌트가 로드될 수 없음을 보고하고, 상기 컴포넌트의 측정 값을 상기 CN에 전송하는 것을 포함한다.

166. 실시예들 69 내지 165 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 컴포넌트들을 디스에이블시키는 것을 포함한다.

167. 실시예들 69 내지 166 중 어느 하나의 실시예에 있어서, 상기 컴포넌트들을 디스에이블시키는 것은, 상기 장치에 대한 접속을 거부하지 않으면서, 검증될 수 없으며 그리고 상기 PVM에서 교체 또는 업데이트될 수 없는 컴포넌트들에 대한 디스에이블 CInd 및 재검증 메시지를 전송하는 것을 포함한다.

168. 실시예들 69 내지 167 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 최소 검증 방침(Minimal Validation Policy)을 포함한다.

169. 실시예들 69 내지 168 중 어느 하나의 실시예에 있어서, 상기 최소 검증 방침은 특정의 환경들 하에서만 장치 검증을 수행하는 것을 포함한다.

170. 실시예들 69 내지 169 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 인증 증명서들 내에 검증을 바인딩하는 것을 포함한다.

171. 실시예들 69 내지 170 중 어느 하나의 실시예에 있어서, 상기 인증 증명서들 내에 검증을 바인딩하는 것은 상기 장치의 진짜 ID를 검증에 자동으로 바인딩하는 것을 포함한다.

172. 실시예들 69 내지 171 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 장치 인증 증명서 취소를 포함한다.

173. 실시예들 69 내지 172 중 어느 하나의 실시예에 있어서, 상기 장치 인증 증명서 취소는, 장치 인증을 위해 상기 장치로부터 전송된 상기 장치 증명서를 취소할 지의 여부를 결정하는 것을 포함한다.

174. 실시예들 69 내지 173 중 어느 하나의 실시예에 있어서, 상기 장치 인증 증명서 취소는, 증명서 취소로 인해 장치 인증이 실패했음을 상기 장치에게 나타내고, 상기 장치를 화이트 리스트로부터 삭제하거나, 또는 상기 장치를 블랙 리스트에 올리는 것을 포함한다.

175. 실시예들 69 내지 174 중 어느 하나의 실시예에 있어서, 상기 PVM은 자율적인 검증(AuV)을 수행한다.

176. 실시예들 69 내지 175 중 어느 하나의 실시예에 있어서, 상기 AuV는 상기 SeGW로의 검증 데이터의 전달을 생략하는 것을 포함한다.

177. 실시예들 69 내지 176 중 어느 하나의 실시예에 있어서, 상기 AuV는 상기 Dev_ID 만을 전송하는 것을 포함한다.

178. 실시예들 69 내지 177 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 교정을 포함한다.

179. 실시예들 69 내지 178 중 어느 하나의 실시예에 있어서, 상기 교정은 소프트웨어를 업데이트하는 것을 포함한다.

180. 실시예들 69 내지 179 중 어느 하나의 실시예에 있어서, 상기 교정은 장치의 계속된 서비스를 위해 필요한 동작이다.

181. 실시예들 69 내지 180 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 장치에 의해 개시되는 교정(Device Initiated Remediation)을 포함한다.

182. 실시예들 69 내지 181 중 어느 하나의 실시예에 있어서, 상기 장치에 의해 개시되는 교정은, 에러들의 검출시 상기 장치를 격리시키는 대신에 수행된다.

183. 실시예들 69 내지 182 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 네트워크에 의해 개시되는 교정(Network Initiated Remediation)을 포함한다.

184. 실시예들 69 내지 183 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 폴백 코드 베이스를 개시하는 것을 포함한다.

185. 실시예들 69 내지 184 중 어느 하나의 실시예에 있어서, 상기 폴백 코드 베이스를 개시하는 것은 상기 RIM들을 포함하는 주 코드 베이스의 소프트웨어 업데이트를 트리거하는 것을 포함한다.

186. 실시예들 69 내지 185 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 디스트레스 신호를 전송하는 것을 포함한다.

187. 실시예들 69 내지 186 중 어느 하나의 실시예에 있어서, 상기 폴백 코드(FBC) 이미지는 장치의 교정을 용이하게 하며, 보안 메모리에 저장된다.

188. 실시예들 69 내지 187 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 RIM들이 없는 검증을 포함한다.

189. 실시예들 69 내지 188 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 위치 기반 정보를 포함시키는 것을 포함한다.

190. 실시예들 69 내지 189 중 어느 하나의 실시예에 있어서, 상기 위치 정보는 절도 보호, 화물 추적(cargo tracking), 함대 모니터링(fleet monitoring) 또는 감시(surveillance)를 위해 이용된다.

191. 실시예들 69 내지 190 중 어느 하나의 실시예에 있어서, 상기 장치는 GPS 모듈을 포함한다.

192. 실시예들 69 내지 191 중 어느 하나의 실시예에 있어서, 상기 보안 스타트업은 상기 GPS 모듈 및 컴포넌트들을 검증하는 것을 포함한다.

193. 실시예들 69 내지 192 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 IKEv2 프로토콜을 이용한 검증 접속을 포함한다.

194. 실시예들 69 내지 193 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 전송 프로토콜을 이용하는 것을 포함한다.

195. 실시예들 69 내지 194 중 어느 하나의 실시예에 있어서, 상기 전송 프로토콜은 IKE 또는 ISAKMP 이다.

196. 실시예들 69 내지 195 중 어느 하나의 실시예에 있어서, 상기 전송 프로토콜은 이용될 수 있는 다수의 증명서 프로파일들을 정의한다.

197. 실시예들 69 내지 196 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 전송 계층 보안(TLS) 핸드셰이크(handshake)를 포함한다.

198. 실시예들 69 내지 197 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 TLS 세션 티켓 연장(extension)을 이용하는 것을 포함한다.

199. 실시예들 69 내지 198 중 어느 하나의 실시예에 있어서, 상기 TLS 세션 티켓 연장은, 서버로 하여금 클라이언트에게, 세션을 재개하고 클라이언트 마다의(per-client) 세션 상태를 유지하는 데에 이용될 수 있는 세션 티켓을 발행할 수 있게 한다.

200. 실시예들 69 내지 199 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 보충 인증 프로토콜(supplementary authentication protocol)을 포함한다.

201. 실시예들 69 내지 200 중 어느 하나의 실시예에 있어서, 상기 보충 인증 프로토콜은 상기 Dev_ID 및 Dev_ID에 대한 인증 데이터를 확립된 보안 채널을 통해 전송하는 것을 포함한다.

202. 실시예들 69 내지 201 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 관리 세션 확립을 포함한다.

203. 실시예들 69 내지 202 중 어느 하나의 실시예에 있어서, 상기 관리 세션 확립은 상기 장치와 상기 SeGW 간에 상기 통신 프로토콜을 이용하는 것을 포함한다.

204. 실시예들 69 내지 203 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 증명서 기반 검증을 포함한다.

205. 실시예들 69 내지 204 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는, 장치 관리(DM) 기반 아키텍쳐에 대해 OMA(Open Mobile Alliance)를 이용하는 것을 포함한다.

206. 실시예들 69 내지 205 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 증명서 교환 방법들을 이용하는 것을 포함한다.

207. 실시예들 69 내지 206 중 어느 하나의 실시예에 있어서, 상기 증명서 교환 방법들은, 검증 및 인증을 결합하고, 상기 장치의 인증된 ID를 상기 검증에 자동으로 바인딩시키는 것을 포함한다.

208. 실시예들 69 내지 207 중 어느 하나의 실시예에 있어서, 바인딩 증명서는 서명된 데이터 세트이다.

209. 실시예들 69 내지 208 중 어느 하나의 실시예에 있어서, 바인딩 증명서는 상기 발행자에 의해 서명된다.

210. 실시예들 69 내지 209 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 프리 증명서 교환(pre certificate exchange)을 포함한다.

211. 실시예들 69 내지 210 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 포스트 증명서 교환(post certificate exchange)을 포함한다.

212. 실시예들 69 내지 211 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 상기 발행자로부터 상기 장치로의 소프트웨어 패키지들의 다운로드를 위해 서명된 메시지 포맷을 이용하는 것을 포함한다.

213. 실시예들 69 내지 212 중 어느 하나의 실시예에 있어서, 상기 서명된 메시지 포맷은 단일의 서명된 패키지 내에서 파일이 전송될 수 있게 한다.

214. 실시예들 69 내지 213 중 어느 하나의 실시예에 있어서, 상기 서명된 메시지 포맷은 수신 장치로 하여금 소스를 인증할 수 있게 하고, 콘텐츠들을 설치하기 위한 명령들을 포함한다.

215. 실시예들 69 내지 214 중 어느 하나의 실시예에 있어서, 상기 서명된 메시지 포맷은 헤더를 포함하며, 상기 헤더는 포맷 버전과, 커맨드 리스트 및 페이로드 컴포넌트들의 길이를 포함한다.

216. 실시예들 69 내지 215 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 교정을 위해 제 2 코드 베이스를 이용하는 것을 포함한다.

217. 실시예들 69 내지 216 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 외부 FBC를 이용하는 것을 포함한다.

218. 실시예들 69 내지 217 중 어느 하나의 실시예에 있어서, 상기 외부 FBC는 교정을 개시하는 데에 이용되며, 상기 TrE 내에서 실행된다.

219. 실시예들 69 내지 218 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 내부 병렬 코드 베이스의 이용을 포함한다.

220. 실시예들 69 내지 219 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 교정을 용이하게 하는 데에 필요한 트리거 메커니즘들 및 폴백 코드 베이스의 이용을 포함한다.

221. 실시예들 69 내지 220 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 내부의 순차적인 코드 베이스의 이용을 포함한다.

222. 실시예들 69 내지 221 중 어느 하나의 실시예에 있어서, 상기 내부의 순차적인 코드 베이스는 원격 장치들 상에 소프트웨어 구성들을 설치 또는 변경하기 위해 프로토콜들 및 커맨드들을 정의한다.

223. 실시예들 69 내지 222 중 어느 하나의 실시예에 있어서, 상기 내부의 순차적인 코드 베이스의 이용은 상기 PVM을 수행한 결과와 상기 프로토콜을 결합하는 것을 포함한다.

224. 실시예들 69 내지 223 중 어느 하나의 실시예에 있어서, 상기 PVM을 수행하는 단계는 보안 방침 속성들을 이용하는 것을 포함한다.

225. 실시예들 69 내지 224 중 어느 하나의 실시예에 있어서, 상기 보안 방침 속성들을 이용하는 것은 보안 방침 속성(SPA)들의 표준화된 리스트를 생성하는 것을 포함한다.

226. 실시예들 69 내지 225 중 어느 하나의 실시예에 있어서, SPA는, 특정의 모듈이 자신의 무결성 체크에 실패하는 경우 어떤 액션이 취해져야 하는 지를 상기 PVE에게 알려주는 방침이다.

상기에서는 PVM의 특징들 및 요소들이 특정 조합으로 설명되었지만, 각각의 특징 또는 요소는 다른 특징들 및 요소들없이 단독으로 이용되거나, 또는 다른 특징들 및 요소들과 함께 또는 이러한 특징들 및 요소들없이 다양한 조합으로 이용될 수 있다. 여기에서 제공되는 방법들 또는 흐름도들은, 범용 컴퓨터 또는 프로세서에 의해 실행하기 위한 컴퓨터 판독가능한 저장 매체에 수록되는 펌웨어, 소프트웨어, 또는 컴퓨터 프로그램으로 구현될 수 있다. 컴퓨터 판독가능한 저장 매체들의 예들은 판독 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 레지스터, 캐시 메모리, 반도체 메모리 디바이스들, 자기 매체(이를 테면, 내부 하드 디스크들 및 착탈가능 디스크들), 광자기 매체, 및 광학 매체(CD-ROM 디스크들 및 디지털 다기능 디스크(DVD))를 포함한다.

적절한 프로세서들은, 예를 들어 범용 프로세서, 특수 목적 프로세서, 통상의 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서들, DSP 코어와 관련되는 1개 이상의 마이크로프로세서들, 제어기, 마이크로제어기, 주문형 반도체(ASIC), 필드 프로그래밍가능 게이트 어레이(FPGA) 회로들, 임의의 기타 타입의 집적 회로(IC), 및/또는 상태 머신을 포함한다.

소프트웨어와 관련된 프로세서는, 무선 송수신 유닛(WTRU), 사용자 장비(UE), 단말기, 기지국, 무선 네트워크 제어기(RNC) 또는 임의의 호스트 컴퓨터에서 이용하기 위한 무선 주파수 트랜스시버를 구현하는 데에 이용될 수 있다. WTRU는, 카메라, 비디오 카메라 모듈, 비디오폰, 스피커폰, 진동 장치, 스피커, 마이크로폰, 텔레비젼 트랜스시버, 핸즈프리 헤드셋, 키보드, 블루투쓰

모듈(Bluetooth

module), 주파수 변조(FM) 라디오 유닛, 액정 디스플레이(LCD) 유닛, 유기 발광 다이오드(OLED) 디스플레이 유닛, 디지털 뮤직 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저, 및/또는 임의의 무선 LAN(근거리 통신망) 또는 초광대역(UWB) 모듈과 같이, 하드웨어 및/또는 소프트웨어로 구현되는 모듈들과 함께 이용될 수 있다.

110: TSS 장치 제조업자
114, 134, 154, 174: 신뢰성있는 자원들
116: 신뢰성있는 서비스들
118, 138, 158, 178: 정규 서비스들
122, 142, 162, 182: 신뢰성있는 엔진
130: TSS 네트워크 오퍼레이터
150: TSS 서비스 제공자
170: TSS 네트워크 오퍼레이터
200, 202: 신뢰성있는 시스템
280, 282: 통상 애플리케이션들
270, 272: 신뢰 경계

Claims (19)

1. 플랫폼 검증 엔티티(platform validation entity; PVE)에 연결된 디바이스의 검증을 수행하기 위한, 상기 PVE에서 수행되고 있는 방법에 있어서,
   상기 디바이스의 하나 이상의 소프트웨어 모듈들의 무결성 체크(integrity check)에 기초하여, 상기 디바이스로부터 검증 메시지 - 상기 검증 메시지는 상기 디바이스에 관한 정보를 포함하고, 상기 무결성 체크에 실패한 임의의 소프트웨어 모듈들에 연관된 하나 이상의 보안 방침 속성(security policy attribute)들을 나타냄 - 를 수신하는 단계와,
   상기 검증 메시지에 기초하여, 상기 디바이스에 네트워크 액세스를 허용할 지 여부를 결정하는 단계를 포함하는,
   플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
2. 제1항에 있어서, 임의의 실패한 소프트웨어 모듈에 대한 상기 하나 이상의 보안 방침 속성들 중 하나는 코드들의 리스트로부터 선택된 코드인 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
3. 제2항에 있어서, 상기 코드는 네트워크 액세스가 거절(deny)될 필요가 있음을 나타내는 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
4. 제2항에 있어서, 상기 코드는 임시적인(temporary) 네트워크 액세스가 허용될 수 있음(acceptable)을 나타내는 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
5. 제2항에 있어서, 상기 코드는 상기 실패한 소프트웨어 모듈의 격리(quarantine)가 성공적인 한, 네트워크 액세스가 허용되어야 함을 나타내는 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
6. 제2항에 있어서, 상기 코드는 제한된(limited) 네트워크 액세스가 허용될 수 있음을 나타내는 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
7. 제2항에 있어서, 상기 리스트는 상기 네트워크 액세스가 허용되어야 함을 나타내는 코드를 포함하는 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
8. 제1항에 있어서, 상기 디바이스는 무선 송수신 유닛(wireless transmit/receive unit; WTRU)인 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
9. 제1항에 있어서, 상기 PVE는 상기 검증 메시지에 기초하여 상기 디바이스에서의 구성 변화(configuration changes)를 명령(mandate)할 지 여부를 결정하는 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
10. 제1항에 있어서, 상기 보안 방침 속성들은 상기 무결성 체크에 실패한 임의의 소프트웨어 모듈에 대해 상기 PVE에 의하여 어떠한 행위(action)가 취해져야 하는지를 나타내는 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
11. 플랫폼 검증 엔티티(platform validation entity; PVE)에 연결된 디바이스의 검증을 수행하기 위한, 상기 디바이스에서 행해지고 있는 방법에 있어서,
    상기 디바이스의 소프트웨어 모듈들에 대하여 무결성 체크(integrity check)를 수행하는 단계와,
    상기 무결성 체크에 실패하는 임의의 소프트웨어 모듈들에 대한 보안 방침 속성(security policy attribute)들을 획득하는 단계와,
    상기 무결성 체크에 기초하여 상기 PVE로 검증 메시지 - 상기 검증 메시지는 상기 디바이스에 관한 정보를 포함하고, 상기 무결성 체크에 실패한 임의의 소프트웨어 모듈들에 연관된 하나 이상의 보안 방침 속성들을 나타냄 - 를 송신하는 단계를 포함하는,
    플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
12. 제11항에 있어서, 임의의 실패한 소프트웨어 모듈에 대한 상기 보안 방침 구성은 코드들의 리스트로부터 선택된 코드인 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
13. 제12항에 있어서, 상기 코드는 네트워크 액세스가 거절(deny)될 필요가 있음을 나타내는 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
14. 제12항에 있어서, 상기 코드는 임시적인(temporary) 네트워크 액세스가 허용될 수 있음(acceptable)을 나타내는 것인 ,플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
15. 제12항에 있어서, 상기 코드는 네트워크 액세스가 허용되어야 함을 나타내는 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
16. 제12항에 있어서, 상기 코드는 제한된(limited) 네트워크 액세스가 허용될 수 있음을 나타내는 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
17. 제11항에 있어서, 상기 보안 방침 속성들은 상기 무결성 체크에 실패한 상기 임의의 소프트웨어 모듈들에 대해 상기 PVE에 의하여 어떠한 행위(action)가 취해져야 하는지를 나타내는 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
18. 제11항에 있어서, 상기 디바이스는 무선 송수신 유닛(wireless transmit/receive unit; WTRU)인 것인, 플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.
19. 플랫폼 검증 엔티티(platform validation entity; PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법에 있어서,
    상기 디바이스의 적어도 하나의 미리 지정된 컴포넌트의 무결성 측정값(integrity measurement)을 생성하기 위하여, 상기 디바이스의 상기 적어도 하나의 미리 지정된 컴포넌트를 측정하는 단계와,
    상기 디바이스의 상기 적어도 하나의 미리 지정된 컴포넌트에 대한 신뢰성 있는 참조 값(trusted reference value)을 검색(retrieve)하는 단계와,
    상기 디바이스 내에 위치한 신뢰성 있는 환경(trusted environment; TrE)을 이용하여, 상기 디바이스의 상기 적어도 하나의 미리 지정된 컴포넌트의 무결성 체크 - 상기 무결성 체크는 상기 TrE가 상기 적어도 하나의 미리 지정된 컴포넌트의 측정된 무결성 측정값을 상기 디바이스의 상기 적어도 하나의 미리 지정된 컴포넌트의 상기 신뢰성 있는 참조 값과 비교하는 것을 포함함 - 수행하고, 무결성 체크 결과들을 저장하는 단계와,
    상기 TrE를 이용하여, 상기 디바이스 상에서 보안 스타트업(secure start-up) 체크 - 상기 스타트업 체크는 상기 적어도 하나의 미리 지정된 컴포넌트가 보안 스타트업 상태를 달성했는지를 결정함 - 를 수행하고, 보안 스타트업 체크 결과들 - 상기 스타트업 체크 결과들은, 상기 적어도 하나의 미리 지정된 컴포넌트가 상기 스타트업 상태를 달성하는 데 실패하는지의 표시(indication)를 포함함 - 을 저장하는 단계와,
    상기 디바이스의 상기 적어도 하나의 미리 지정된 컴포넌트 중 상기 무결성 체크에 실패하는 임의의 컴포넌트에 대한 보안 방침 속성들을 획득하는 단계와,
    상기 TrE를 이용하여, 상기 무결성 체크 결과들과 상기 보안 스타트업 체크 결과들에 기초하여, 검증 메시지 - 상기 검증 메시지는 상기 측정된 무결성 측정값을 상기 신뢰성 있는 참조 값과 비교한 결과를 나타내고, 상기 디바이스의 상기 적어도 하나의 미리 지정된 컴포넌트 중 상기 무결성 체크에 실패한 임의의 컴포넌트에 연관된 하나 이상의 보안 방침 속성들을 나타냄 - 를 형성(form)하는 단계와,
    상기 TrE를 이용하여, 상기 검증 메시지를 상기 디바이스로부터 상기 디바이스의 외부에 있는 상기 PVE로 포워딩(forward)하는 단계와,
    상기 검증 메시지를 포워딩한 후, 디바이스 인증(device authentication)을 거부 또는 허용하는 메시지를 수신하는 단계를 포함하는,
    플랫폼 검증 엔티티(PVE)에 연결된 디바이스의 검증을 수행하기 위한 방법.

Images