KR20110126160A - Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치 - Google Patents

Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치 Download PDF

Info

Publication number
KR20110126160A
KR20110126160A KR1020117023302A KR20117023302A KR20110126160A KR 20110126160 A KR20110126160 A KR 20110126160A KR 1020117023302 A KR1020117023302 A KR 1020117023302A KR 20117023302 A KR20117023302 A KR 20117023302A KR 20110126160 A KR20110126160 A KR 20110126160A
Authority
KR
South Korea
Prior art keywords
integrity
list
component
module
pve
Prior art date
Application number
KR1020117023302A
Other languages
English (en)
Inventor
수드히르 비. 파타
인혁 차
안드레아스 유. 슈미트
안드레아스 라이쳐
요겐드라 씨. 샤
돌로레스 에프. 호우리
데이비드 쥐. 그레이너
로렌스 엘. 케이스
마이클 브이. 마이어쉬타인
루이스 제이. 구치오네
Original Assignee
인터디지탈 패튼 홀딩스, 인크
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 인터디지탈 패튼 홀딩스, 인크 filed Critical 인터디지탈 패튼 홀딩스, 인크
Publication of KR20110126160A publication Critical patent/KR20110126160A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0681—Configuration of triggering conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H04L41/0869—Validating the configuration within one network element
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • H04W84/045—Public Land Mobile systems, e.g. cellular systems using private Base Stations, e.g. femto Base Stations, home Node B
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/68—Special signature format, e.g. XML format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Abstract

자율적 확인 및 반자율적 확인을 이용하여 옥내 진화형 노드-B(H(e)NB) 무결성 검증 및 확인을 제공하는 장치 및 방법이 여기에서 개시된다.

Description

Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치{METHOD AND APPARATUS FOR H(e)NB INTEGRITY VERIFICATION AND VALIDATION}
관련 출원에 대한 교차 참조
이 출원은 2009년 3월 5일자 출원한 미국 예비 출원 제61/157,833호; 2009년 6월 30일자 출원한 미국 가출원 제61/222,067호; 2009년 8월 21일자 출원한 미국 가출원 제61/235,793호; 및 2009년 9월 3일자 출원한 미국 가출원 제61,239,698호를 우선권 주장하며, 상기 출원들은 모두 인용에 의해 마치 여기에서 전부를 설명한 것처럼 이 명세서에 통합된다. 이 출원은 "무선 장치의 플랫폼 확인 및 관리(Platform Validation and Management of Wireless Devices)"라는 명칭으로 동시에 출원된 미국 특허 출원 제12/718,480호와 관련이 있으며, 이 출원은 인용에 의해 마치 여기에서 전부를 설명한 것처럼 이 명세서에 통합된다.
발명의 분야
이 출원은 통신과 관련이 있다.
펨토셀(femtocell)이라고도 알려져 있는 옥내 진화형 노드 B(home evolved node B; H(e)NB)는 일반적으로 구내에 또는 호스팅 파티(HP)라고 부르는 이해관계자(stakeholder)의 가정 내에 배치되는 3G 네트워크에 대한 소형의 휴대용 접근점(access point)이다. H(e)NB는 이동 통신의 매개자(mediator)이고 소규모의 지정된 지리적 영역내에서 서비스한다. H(e)NB는 옥내 또는 공장 환경과 같이 (열악한 무선 조건 때문에) 지금까지 액세스가 불가능하였던 지역에서 모바일 서비스를 제공하기 위해 사용될 수 있다. H(e)NB는 광대역 인터넷 및 모바일 네트워크에 대한 통합 접근점이 될 수 있기 때문에 개인 가정 및 소호(SOHO; small office home office) 섹터에서 옵션으로도 될 수 있다.
이 응용은 특수한 보안 필요조건을 제기할 수 있다. 예를 들면, 이 장치들은 i) 모바일 핸드셋이 관습적으로 보여왔던 것처럼 민감한 데이터(sensitive data)의 저장 및 취급을 위한 폐쇄된 불변 환경으로서 더 이상 간주되지 않고, ii) 이러한 특수한 장치들은 전형적으로 H(e)NB의 주요 이해관계자로서 이동 통신 단말기의 사용자에게 서비스를 제공하도록 H(e)NB를 운용하는 모바일 네트워크 운용자(MNO)의 직접적인 물리적 제어하에 있지 않으며, iii) 이러한 장치들은 일반적으로 비보안 링크를 통해서, 및 연속적이라기 보다는 간헐적인 방법으로 코어 네트워크에 접속된다.
이동 통신망의 기존 기술 즉 표준화 기술은 H(e)NB가 관습적 인증 단계를 통과한 경우에도 네트워크가 운용하는 H(e)NB가 신뢰할만한 것이라고 네트워크가 전적으로 생각할 방법을 제공하지 못한다. 그래서, 필요한 것은 MNO가 장치의 신뢰성, 즉 무결성(ingegrity)을 인증할 뿐만 아니라 확인하고 그러한 장치를 관리 및 공급하는데 도움을 주는 방법이다.
여기에서는 자율적 확인(autonomous validation) 및 반자율적 확인을 이용하여 옥내 진화형 노드-B(H(e)NB) 무결성 확인을 제공하는 장치 및 방법이 개시된다.
본 발명은 모바일 네트워크 운용자가 장치의 신뢰성을 인증할 뿐만 아니라 확인하는데 도움을 주는 효과를 제공한다.
본 발명의 더 자세한 내용은 첨부 도면과 함께 예로서 주어지는 이하의 설명으로부터 이해할 수 있을 것이다.
도 1은 모듈, 기능성 및 컴포넌트의 예시적인 조직을 보인 도이다.
도 2는 컴포넌트와 기능성의 예시적인 조직을 보인 도이다.
도 3은 소프트웨어 다운로드 공급을 위한 예시적인 TR069 아키텍쳐를 보인 도이다.
도 4는 기본적인 무결성 측정 및 보고의 예를 보인 도이다.
도 5는 무결성 보고 및 참고 자료의 예를 보인 도이다.
도 6은 확인 리포트를 참고 적하목록(reference manifest)과 비교한 예를 보인 도이다.
도 7은 참고 적하목록에서 컴포넌트 정보의 예를 보인 도이다.
도 8은 인증서 관리 구조의 예를 보인 도이다.
도 9는 옥내 진화형 노드-B(H(e)NB)의 재구성(H(e)MS)의 예를 보인 도이다.
도 10은 자율적 확인(AuV) 교정의 예를 보인 도이다.
도 11은 파일 패키지 포맷의 예를 보인 도이다.
도 12는 반자율적 확인(SAV)의 예시적인 네트워크 구조를 보인 도이다.
도 13A 및 13B는 SAV 절차의 예시적인 흐름도를 보인 도이다.
도 14는 SAV 교정의 예시적인 흐름도를 보인 도이다.
도 15는 무결성 체크의 예시적인 결과를 나타낸 도이다.
도 16은 실패한 기능성의 예시적인 리스트를 보인 도이다.
도 17A는 예시적인 엔티티 집합 및 그들의 관계와, 플랫폼 확인 및 관리(PVM)를 위한 인터페이스를 보인 블록도이다.
도 17B는 다른 예시적인 엔티티 집합 및 그들의 관계와, PVM을 위한 인터페이스를 보인 블록도이다.
도 18A, 18B 및 18C는 플랫폼 확인 엔티티를 이용하는 예시적인 확인 방법의 신호도이다.
도 19는 롱텀 에볼루션(LTE) 무선 통신 시스템/액세스 네트워크를 보인 도이다.
도 20은 LTE 무선 통신 시스템의 예시적인 블록도이다.
이하에서 인용되는 용어 "무선 송수신 유닛(WTRU: wireless transmit/receive unit)"은, 비제한적인 예를 들자면, 사용자 설비(UE), 이동국, 고정식 또는 이동식 가입자 유닛, 페이저, 셀룰러 전화기, 개인 정보 단말기(PDA), 컴퓨터, 또는 무선 환경에서 동작할 수 있는 임의의 다른 유형의 장치를 포함한다. 이하에서 인용되는 용어 "기지국"은, 비제한적인 예를 들자면, 노드-B, 사이트 제어기, 접근점(AP), 게이트웨이, 고객 구내 설비(CPE), 또는 무선 또는 유선 환경에서 동작할 수 있는 임의의 다른 유형의 인터페이스 장치를 포함한다. 이하에서 인용되는 용어 "HMS"는, 비제한적인 예를 들자면, 홈 노드-B 관리 시스템(HMS), 홈 엔헌스드 노드-B 관리 시스템(HeMS)(상기 HMS와 HeMS는 집합적으로 H(e)MS라고 부르기도 한다), 장치 관리 시스템(DMS), 구성 서버(CS), 자동 구성 서버(ACS), 또는 "기지국"의 구성 또는 기능성을 관리하는 임의의 다른 유형의 시스템을 포함한다. 용어 "WTRU"와 "기지국"은 상호 배타적인 것이 아니다. 예를 들면, WTRU는 엔헌스드 홈 노드-B(H(e)NB)가 될 수 있다. 이하에서 인용되는 용어 "정보-이론상 보안"은 비제한적인 예를 들자면 완전한 보안, 비조건적 보안 및 대략적인 정보-이론상 보안을 포함한다. 이하에서 인용되는 용어 "신뢰", "신뢰된" 및 "신뢰할만한"과 그 변형체(variation)는 유닛이 특정 방식으로 기능할 것인지에 대한 정량화 및 관측가능한 평가 방법을 표시한다.
여기에서는 자율적 확인(autonomous validation; AuV) 및 반자율적 확인(semi-autonomous validation; SAV)를 이용하여 옥내 진화형 노드-B(H(e)NB) 무결성 검증 및 확인을 제공하는 장치 및 방법이 개시된다. 여기에서는 또한 AuV 및 SAV에 공통인 세부(details), 및 그 다음에 AuV와 SAV에 관한 구현 세부가 개시된다.
확인 방법에서 사용되는 신뢰 참고치(trusted reference value; TRV)를 결정하는 방법이 여기에서 개시된다. 장치 무결성 체킹은 확인 방법(validation method)에 공통인 절차이다. 장치 무결성 체킹을 위해, TRV 집합이 필요하고, 그래서 컴포넌트들로 이루어진 측정치(measurements)들이 그들의 무결성을 위해 체크될 수 있다. 이러한 컴포넌트 무결성 체크는 컴포넌트가 로드되기 전에 수행되어야 한다. 또한, TRV는 이들이 사용되기 전에 자신에 의해 무결성이 인증되고 보장되는 것이 바람직하다.
무결성 체크를 수행하고 TRV를 제공 및 발생하기 위해, 다른 무결성 체크 방법을 사용할 수 있다. 예를 들면, 코드에 대응하는 TRV를 발생하는 방법은 디지털 서명 메서드(digital signature method)를 포함할 수 있고, 해쉬(hash) 기반 메시지 인증 코드 또는 암호화 기반 메시지 인증 코드를 생각할 수 있다.
여기에서는 디지털 서명 메서드가 개시된다. 디지털 서명 메서드는 공개키 암호화(public key cryptography)를 사용할 수 있다. H(e)NB는 자신의 개인키를 이용하여 체크워드를 암호화함으로써 모듈의 해쉬(또는 일반적으로 체크워드)를 디지털식으로 서명할 수 있다. 암호화 체크워드는 그 다음에 플랫폼 확인 엔티티(PVE)에 보내지고, 여기에서 H(e)NB의 공개키에 의해 복호되어 TRV와 비교될 수 있다. 국소 무결성 체크를 위하여, 참고 무결성 체크가 제조자에 의해 서명되고 H(e)NB 내에서 국부적으로 검증될 수 있다. 비제한적인 예로서, 표 1은 일부 디지털 서명 메서드를 나타낸다.
명칭 종류 특성 최소 키 사이즈
디지털 서명 표준 FIPS 186-2 디지털 서명 SHA-1 해쉬에 기반을 둔 디지털 서명. 특허 없음. 라이센스 없음. 미국 연방 정부 수출 통제가 적용됨 1024 비트
RSA 디지털 서명 RSA 디지털 서명
(FIPS 승인됨)		 예전에 특허됨(2000년에 만료됨) 1024 비트
타원 곡선 디지털 서명 타원 곡선 디지털 서명 타원 곡선 키 기술에 기반을 둔 기술 160 비트
여기에서는 해쉬 알고리즘 및 해쉬 기반 메시지 인증 코드가 개시된다. 해슁은 그 입력의 유일하고(또는 거의 유일하고) 비가역성인(또는 거의 비가역성인) 개요(summary)를 생성하는 일방향 또는 거의 일방향 함수이다. 많은 경우의 디지털 서명은 암호화한 해쉬에 지나지 않는다. 비록 디지털 서명 메서드가 공개키/개인키 쌍을 사용할 수 있지만, 메시지 인증 코드(MAC)는 공유(shared) 비밀키를 사용할 수 있다. 체크워드는 내장(embedded) 비밀키(연쇄 모듈 및 키)를 이용하여 모듈을 통해 생성될 수 있다. 비제한적인 예로서, 표 2는 일부 해쉬 알고리즘 및 해쉬 기반 메시지 인증 코드 메서드를 나타낸다.
명칭 종류 특성 최소 키 사이즈
SHA-1, SHA-256,
SHA-512		 해쉬 알고리즘 FIPS 승인됨 160, 256, 512 비트
범용 메시지 인증 코드 해쉬 기반 MAC 가장 빠른 해쉬 기반 알고리즘 32, 64, 96 비트
RACE 무결성
초기(primitives)
평가 메시지 다이제스트-160		 해쉬 알고리즘 유럽에서 EC의 R&D 160 비트
TIGER(2) 해쉬 알고리즘 64 비트 플랫폼에서의 효과적인 동작을 위해 설계됨 192 비트
HMAC-SHA1-96 해쉬 기반 MAC 해쉬에 대해 SHA-1을 사용함 96 비트
WHIRLPOOL 해쉬 기반 MAC 특허되지 않음 512 비트
여기에서는 암호화 기반 메시지 인증 코드가 개시된다. 체크워드는 해쉬 알고리즘에 의해 생성된 후 비밀키를 이용하여 암호화된다. 비제한적인 예로서, 표 3은 일부 암호화 기반 메시지 인증 코드 메서드를 나타낸다.
명칭 종류 특성 최소 키 사이즈
DES-CBC-MAC 암호화 MAC DES 기반 64 비트
CMAC 암호화 MAC 대칭 키 블록 암호 알고리즘을 이용한 암호화 기반 MAC 64, 128, 192, 256
CCM 암호화 MAC 카운터 모드 암호화와 연결된 암호 블록을 사용함 128, 192, 256
무결성 메트릭은 소프트웨어 컴포넌트에서 무결성 메서드를 실행함으로써 발생된 다이제스트(예를 들면, 암호화 해쉬값)이다. 컴포넌트는 여기에서 무결성 체크의 가능한 최소량으로서 고려된다. 개별 바이너리 실행 파일 또는 전처리(pre-executable) 파일은 컴포넌트의 예이다. 반면에, 모듈은 여기에서 최소량으로서 고려되고, 이것에 의해 소프트웨어 패키지의 제조자가 공인 및 배송한다. 이 설명의 나머지에 대하여, 일반적으로, 도 1에 도시한 바와 같이, 1) 컴포넌트는 항상 1개 이상의 모듈로 구성된다는 것과, 2) 임의의 하나의 모듈은 컴포넌트에서 단지 1회 나타난다(즉, 하나의 모듈은 2개의 컴포넌트에서 나타날 수 없다)는 것을 고려한다. AuV 및 SAV에서 장치 무결성 체크 및 확인을 지원하기 위해, 소프트웨어 모듈의 리스트 및 그들의 관련 속성, 예를 들면, 모듈에 대응하는 참고 무결성 메트릭(reference integrity metrics; RIM), 가혹성(severity) 및 기타 정보가 제공되어야 한다. 참고 무결성 메트릭(RIM)은 개별 모듈의 무결성에 대한 참고치로서 사용된다. AuV의 경우에, 리스트는 제조자에 의해 발생되어 장치에 안전하게 저장되고, SAV의 경우에, 리스트는 제조자에 의해 발생되어 플랫폼 확인 엔티티(PVE)(모든 모듈)에 제공되고 H(e)NB에도 또한 공급된다(스테이지 1 및 스테이지 2에 대하여 다중 스테이지 내의 모듈들이 구현을 시작한다). 소프트웨어 모듈들이 어떻게 조직되고 구성되고 또는 저장되는지, 및 어떤 종류의 모듈이 장치에 존재하는지는 H(e)NB 구현에 의존하므로, 모듈 및 그들의 속성을 특정하기 위해 공통 명세 언어(common specification language)를 사용할 수 있다.
예를 들면, 확장형 마크업 언어(XML) 및 추상 구문 표시 1(Abstract Syntax Notation One; ASN.1) 기반 메서드는 공통 명세 언어를 구현하기 위해 사용될 수 있다. 장치 구성 데이터 시트는 소프트웨어 모듈의 리스트 및 모듈과 관련된 각종 속성을 내포한다. 이것은 또한 모듈의 분류를 컴포넌트 및 기능성으로 특정할 수 있다.
여기에서는 H(e)NB의 컴포넌트 및/또는 모듈과 관련 속성을 특정하기 위한 공통의 포터블 언어를 제공할 수 있는 소프트웨어 모듈 속성의 XML 기반 명세가 개시된다. 정보를 포터블 방식으로 및 H(e)NB 아키텍쳐-불가지론(agnostic) 방식으로 제공하기 위해, 모듈을 특정하는 언어는 진화하여야 한다. 언어는 XML 스키마(schema) 및 XML 문서를 내포하는 XML 언어와 유사할 수 있다. 모듈의 포맷 및 각종 속성은 표준화될 수 있고 각 제조자는 규정된 포맷으로 소프트웨어 모듈을 묘사하는 장치 구성 데이터 시트를 제공한다. 포맷은 XML 스키마와 유사하고 장치 구성 데이터 시트는 XML 문서와 유사할 수 있다. XML 서명은 무결성, 메시지 인증 및/또는 서명자 인증을 제공하기 위해 디지털 서명을 추가하는 지원(support)을 제공한다. 바이너리 XML은 더 간결한 표시이고 분석 비용(parsing cost) 뿐만 아니라 하나의 엔티티로부터 다른 엔티티로 구성 데이터를 통신하기 위한 필요 대역폭을 감소시키기 위한 기초로서 또한 사용될 수 있다. XML 스키마의 일 예는 표 4에 나타나 있고 제조자가 그들의 모듈을 특정하는 표준 포맷일 수 있다.
XML-스키마
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="Manufacturer Identification">
<xs:complexType>
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="URL" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element="Module Name">
<xs:complexType>
<xs:sequence>
<xs:element name="Version" Type="xs:string"/>
<xs:element name="Stage" Type="xs:string"/>
<xs:element name="Severity" Type="xs:string"/>
<xs:element name="Author" Type="xs:string"/>
<xs:element name="Dependency" Type="xs:string"/>
<xs:element name="Integrity Algorithm" Type="xs:string"/>
<xs:element name="Reference Integrity Metric" Type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>+

<Signature ID?>
<SignedInfo>
<CanonicalizationMethod/>
<SignatureMethod/>
(<Reference URI?>
(<Transforms>)?
<DigestMethod>
<DigestValue>
</Reference>)+
</SignedInfo>
<SignatureValue>
(<KeyInfo>)?
(<Object ID?>)*
</Signature>

</xs:schema>
여기에서 "?"는 제로 또는 1의 발생을 나타내고; "+"는 1 이상의 발생을 나타내며; "*"는 제로 이상의 발생을 나타낸다
제조자는 장치 구성 데이터 시트를 제공하고 장치 구성 데이터 시트를 디지털 서명으로 서명할 수 있다. 이 장치 구성 데이터 시트는 AuV을 위하여 H(e)NB에서 유지될 수 있다. 실패된 체크의 경우, 장치 구성 시트 자체의 디지털 서명이 검증되면 이것은 임의의 실패된 모듈의 영향에 대한 정보를 포함하는 소프트웨어의 속성이 소프트웨어 모듈 자체(즉, 바이너리 이미지)가 변화되고 무결성 체크가 실패한다 하더라도 본래대로 있기 때문에 적당한 동작이 취해질 수 있다. SAV의 경우에, 장치 구성 시트는 장치 및 PVE에서 유지될 수 있다. 여기에서 설명한 것처럼 SAV를 지원하기 위한 추가의 동작이 추가될 수 있다.
여기에서는 H(e)NB의 컴포넌트 및 관련 속성을 특정하는 공통의 포터블 언어를 제공할 수 있는 소프트웨어 모듈 속성의 ASN.1 기반 명세서가 개시된다. 전기 통신 및 컴퓨터 네트워킹에 있어서, ASN.1은 데이터를 표시하고 인코딩하고 전송하고 디코딩하기 위한 데이터 구조를 묘사하는 표준형의 융통성있는 표시이다. ASN.1은 장치 지정 인코딩 기술에 무관하고 불명확성을 제거하는 정밀한 공식 표시인 오브젝트의 구조를 묘사하기 위한 공식 규칙들의 집합을 제공할 수 있다. 통신 프로토콜을 위한 메시지를 규정하기 위해 공통적으로 사용되기 때문에, ASN.1은 그 관련 인코딩 규칙들과 함께 바이너리 인코딩을 야기한다. 인터넷 프로토콜 HTTP 및 SMTP와 같은 다른 통신 프로토콜은 가끔 증대된 배커스-나우어 형식(Augmented Backus-Naur form; ABNF) 표시에 기반을 둔 텍스트 태그 및 값을 이용하여 메시지를 규정한다. 정의는 또한 텍스트 내에 있는 인코딩을 규정한다.
ASN.1 접근방식은 더 효율적인 것으로 믿어지고, 패킹된 인코딩 규칙과 함께 더욱 간결한 인코딩을 확실히 제공한다. 본문 접근방식(textual approach)은 사용자가 인코드된 메시지를 간단히 판독할 수 있기 때문에 (텍스트 문자열의 생성 및 분석을 통해) 구현하기가 더 쉽고 디버깅이 더 쉽도록 요구된다. 메가코(Megaco) 프로토콜의 경우에, 2개의 인코딩이 ASN.1 및 ABNF에 기초하여 규정된다.
ASN.1 XML 인코딩 규칙(XER)은 ASN.1 표시를 이용하여 규정된 데이터 구조의 본문 인코딩을 제공한다. 일반 문자열 인코딩 규칙이 또한 사용자에게 또는 사용자로부터 제시 및 입력할 목적으로만 규정되었다. 통신 장치 무결성 메트릭을 위한 ASN.1의 예는 표 5에 나타내었다.
ASN.1
DeviceIntegrityMeasurementsType DEFINITIONS::=BEGIN
ManufacturerIdentification ::={
Name IA5String,
RUL IA5String
}
Modules ::=SEQUENCE{
Version INTEGER,
Stage INTEGER,
Severity INTEGER,
Author IA5String,
Dependency IA5String,
IntegrityAlgo IA5String,
RIM IA5String
}
DigitalSignature ::= {
SignedInfo SignedInfoType,
KeyInfo KeyInfoType,
SignatureValue IA5String,
}
END
유형 SignedInfoType 및 KeyInfoType는 장치 무결성 측정 유형(DeviceIntegrityMeasurementsType)과 유사한 방식으로 규정될 수 있다.
장치의 각 소프트웨어 모듈에 대하여, 그 관련 모듈 속성이 네트워크에 알려져 있으면, SAV 절차 중에 H(e)NB는 국소 무결성 체크 절차 중에 무결성 체크가 실패한 모든 모듈의 신원(ID) 리스트를 PVE에 보낼 수 있다. 네트워크는, PVE에 의해, 특수 소프트웨어 모듈의 관련 속성 및 그 실패의 영향을 알게 될 것이다. 이 정보는 네트워크가 여기에서 설명하는 것처럼 취하는 다음 단계의 사정(assessment)을 하기 위해 사용될 수 있다.
여기에서는 H(e)NB에 전송되는 것으로 고려될 수 있고 H(e)NB 관리 시스템(H(e)MS)과 같은 신뢰된 제3자(trusted third party; TTP)로부터 디지털 인증서 또는 서명된 메시지로서 공급될 수 있는 소프트웨어 모듈 속성이 개시된다. 예를 들면, 코드 이미지에 대한 모든 정보 요소는, 비제한적인 예를 들자면, H(e)NB의 제조자 및 모듈 코드 이미지의 다이제스트 또는 RIM을 발생하기 위해 사용할 수 있는 무결성 메서드를 포함할 수 있다.
여기에서는 컴포넌트 특정 정보를 묘사하는 방법이 개시된다. 하나 이상의 컴포넌트는 소프트웨어 모듈을 구성한다. 컴포넌트는 무결성 체킹의 기본량(basic quanta)이다. 각 컴포넌트와 관련된 하나의 신뢰된 참고치(TRV)가 있다. 컴포넌트 특정 정보 요소는 컴포넌트 설명에 대응하는 유일하게 식별가능한 ID인 컴포넌트 ID를 포함할 수 있다. 이것은 하나의 TRV로 체크되는 코드의 양(quanta)의 ID이다. 컴포넌트 특정 정보 요소는 컴포넌트의 측정치들을 비교하여 컴포넌트의 무결성을 검증하기 위해 H(e)NB의 무결성 체크 메카니즘을 사용하는 TRV를 또한 포함할 수 있다.
모듈 특정 정보 요소는, 비제한적인 예를 들자면, H(e)NB 내에서 특정 모듈 기능을 묘사하는 모듈 설명 및 제조자의 모듈을 유일하게 식별하는 모듈 ID를 포함할 수 있다. 모듈 특정 정보 요소는 모듈이 맵되는 H(e)NB의 특정 기능을 식별하는 기능 설명 및 판매자들 간에 표준화되어 있고 기능 설명에 대응하는 범용적으로 식별가능한 ID인 기능 ID를 또한 포함할 수 있다. 모듈 특정 정보 요소는 모듈이 맵되는 컴포넌트를 식별하는 컴포넌트 ID 및 모듈의 버전 번호를 표시하는 해제 버전(release version)을 또한 포함할 수 있다. 컴포넌트와 모듈 간에 1:1 맵핑이 있는 경우에, 모듈 특정 정보는 사실상 컴포넌트 특정 정보와 동일하게 될 수 있다.
모듈 특정 정보 요소는 시스템의 기능성에 있어서 현재 소프트웨어의 무결성 체크의 실패 영향을 특정하는 가혹성(severity) 분류를 또한 포함할 수 있다. 예를 들면, 다중 레벨 가혹성 분류 시스템이 있을 수 있다. 예를 들면, 가혹성 1은 H(e)NB 기능성에 높은 영향을 야기하는 모듈/기능의 실패일 수 있고 시스템의 중지 동작을 보장할 수 있다. 모듈/기능의 실패는 폴백(fallback) 코드 이미지(FBC)에 기반을 둔 시스템을 따라 림프(limp)를 야기할 수 있다. 이 경우에, 네트워크 기반 장치 관리 시스템(이 시스템은 장치가 H(e)NB인 경우 H(e)MS일 수 있다)과의 통신은 가능할 수 있다. FBC는 재난(distress) 신호를 지정된 H(e)MS에 보낼 수 있다. 또한, FBC는 네트워크 개시 펌웨어/소프트웨어 업데이트를 지원할 수 있다. 예를 들면, H(e)NB의 신뢰된 환경에 대한 임의의 모듈 또는 컴포넌트는 가혹성 1을 가질 수 있다. 가혹성 2는 제한된 H(e)NB 기능성을 야기하는 모듈/기능의 실패일 수 있고, 이것은 전체 H(e)NB 기능성의 부분집합을 부분적으로 기능시키거나 지원할 수 있다. 이 경우에, 보안 게이트웨이(SeGW)와의 통신이 가능하다. 가혹성 3은 시스템의 핵심 기능성에 영향을 주지 않지만 실패의 경우에 조기 교정을 필요로 할 정도로 충분히 중요하게 고려되는 모듈/기능의 실패일 수 있다. 실패한 모듈/기능은 즉시 펌웨어/소프트웨어 업데이트 절차에 의해 교체되고 후속 리부트(reboot)를 통해 확인될 수 있다. 가혹성 4는 시스템의 핵심 기능성에 영향을 주지 않는 모듈의 실패일 수 있다. 실패한 모듈은 정상 펌웨어/소프트웨어 업데이트 스케줄에 의해 교체될 수 있다.
여기에서는 확인 메서드의 보고 절차 또는 방법이 개시된다. AuV에 대하여, 장치 무결성 체크의 모든 절차는 국소적으로 수행된다. 만일 무결성 체크가 실패하면, 재난 신호가 H(e)MS에 보내져서 실패를 표시할 수 있다. 후속 동작은 인원(personnel)을 보내는 것으로부터 이슈를 고정하거나 장치를 격리(quarantine)시키는 것까지의 범위일 수 있다. 교정은 실패한 모듈의 리스트가 교정 서버/H(e)MS에 보고되는 경우에 수행될 수 있다. SAV의 경우에, 무결성 체크를 실패한 기능성의 리스트가 PVE에 보고될 수 있다.
모듈은 제조자 구현에 의존한다. 컴파일된 소프트웨어 모듈의 집합은 오브젝트 이미지를 형성할 수 있다. 무결성 체크는 오브젝트 이미지 조각(chunk)에서 수행될 수 있다. 그러므로, 무결성 체크가 이루어진 모듈의 집합을 결합하는 컴포넌트가 도입되었다. 하나의 모듈은 컴포넌트에서 1회 나타나고 하나의 컴포넌트에서만 나타난다(즉, 하나의 모듈은 2개의 컴포넌트에서 나타날 수 없다). 이러한 방법으로, 무결성 체크가 수행될 때, 모듈이 단지 1회 체크된다. H(e)NB의 제조자(임의의 개별 소프트웨어 모듈의 제조자와 동일할 수도 다를 수도 있다)는 아키텍쳐에 기반한 장치 무결성 체크를 위해 모듈들을 어떻게 컴포넌트로 분할할 것인지를 결정한다.
기능성은 H(e)NB의 필요조건 및 기능적 구조에 기반을 두고 표준화 식별자일 수 있다. 예를 들면, Iu 인터페이스 및 이동성 관리는 기능이다. 모듈은 2개의 기능 간에 공유될 수 있다. 그러므로, 컴포넌트(이것은 무결성 체크량이다)가 무결성 체크를 실패하면, 영향을 받은 모듈이 공지된다. 각 모듈은 그 모듈과 관련된 기능성을 갖기 때문에, 실패한 기능성의 리스트가 유도될 수 있다. 이 실패한 기능성의 리스트는 SAV의 PVE에 보내진다.
여기에서는 기능성 ID가 개시된다. 아키텍쳐의 구현은 소프트웨어 모듈의 수 및 유형을 관리한다. 복수의 제조자 및 이해관계인(모바일 네트워크 운용자 등)을 통해 보고 구조 및 방법을 조화시키기 위해, 보고는 실제 모듈 대신에 기능성에 기초하여 이루어질 수 있다. 소프트웨어 모듈은 그들의 기능성에 따라서 그룹화될 수 있다. 기능성 ID는 기능성 설명에 기초하여 모듈들을 분류하기 위한 수단을 제공한다. 표 6은 현재 공지된 것에 기초하여 유도된 기능성의 일부를 리스트한 것이다. 이 리스트는 확장 및 표준화될 수 있다. 표 6에서, 최하위 디지트에 대한 1~9의 수는 미래의 사용 또는 확장성을 위해 비축된다.
기능성 ID 기능성 설명
10 H(e)MS 서브시스템 보안 부트 로더
20 Uu 인터페이스 TrE
30 Iuh 인터페이스 무결성 확인 엔진
40 HGm 인터페이스 폴백 코드
50 HUt 인터페이스 운영체제
60 S1-MME 인터페이스 H(e)MS 서브시스템
70 S1-UUu 인터페이스
80 I2(SIP)Iuh 인터페이스
90 Iu-CS 인터페이스 HGm 인터페이스
100 Iu-PS 인터페이스 HUt 인터페이스
110 E, Nc, NbS1-MME 인터페이스
120 RUA 서비스 S1-U 인터페이스
130 HNBAP 서비스 I2(SIP) 인터페이스
140 HNB GW 디스커버리 Iu-CS 인터페이스
150 HNB 등록 Iu-PS 인터페이스
160 HNBE, Nc, Nb 인터페이스의 WTRU 등록
170 액세스 제어 관리 RUA 서비스
180 시간관리 HNBAP 서비스
190 CSG 관리 HNB GW 디스커버리
200 이동성 관리 HNB 등록
210 HNB에 대한 NAS 노드 선택 기능 UE 등록
220 페이징 최적화 액세스 제어 관리
230 운송 어드레스 맵핑 시간 관리
240 챠징 CSG 관리
250 긴급 서비스 이동성 관리
260 QoS 관리 NAS 노드 선택 기능
270 로컬 IP 액세스 페이징 최적화
280 관리된 원격 액세스 운송 어드레스 맵핑
290 레가시 CN 챠징을 위한 HNB 지원
300 인바운드 핸드오버 지원 긴급 서비스
310 로밍 QoS 관리
320 MSC SGSN 로컬 IP 액세스에 공통인 SCCP 무접속
330 OAM 서브시스템 관리 원격 액세스
340 레가시 CN에 대한 디스플레이 서브시스템 HNB 지원
350 USIM 서브시스템 인바운드 핸드오버 지원
360 HPM 서브시스템 로밍
370 MSC SGSN에 공통인 IMS 인터워킹 SCCP 무접속
380 IP-PABX 인터페이스 OAM 서브시스템
390 보안 기능 디스플레이 서브시스템
400 RAB 관리 USIM 서브시스템
410 라디오 리소스 관리 HPM 서브시스템
420 Iu 링크 관리 IMS 인터워킹
430 Iu U-평면(RNL) 관리 IP-PABX 인터페이스
440 Iu-조정 보안 기능
450 공급 기능 RAB 관리
460 하드웨어 실패 라디오 리소스 관리
470 Iu 링크 관리
480 Iu U-평면(RNL) 관리
490 Iu-조정 기능
500 공급 기능
510 하드웨어 실패
여기에서는 컴포넌트 ID가 개시된다. 장치 무결성 체크를 조화시키기 위해, 모듈들은 발생된 이미지에 기초하여 분류될 수 있다. 목적 파일(object file)의 집합은 이미지 파일에 함께 저장된다. 이러한 모듈 그룹은 동일한 컴포넌트 ID를 포함하고 무결성에 대하여 집합적으로 체크되며, 따라서 하나의 컴포넌트에 대하여 하나의 신뢰된 참고치(TRV)를 갖는다. 각 소프트웨어 모듈이 그 자신의 참고 무결성 메트릭(RIM)을 동반하기 때문에, 컴포넌트의 신뢰 참고치(TRV)는 연쇄상의 하나 이상의 소프트웨어 모듈의 다이제스트(예를 들면 해쉬)로서 얻어질 수 있다. 소프트웨어 모듈은 자신과 연관된 RIM을 각각 가질 수 있다. 하나의 컴포넌트 ID에서 나타나는 모듈은 다른 컴포넌트 ID에서 나타나는 동일 모듈과는 다른 기능성 ID로 맵된다는 점에 주목한다. 이 절차는 예를 들면 아키텍쳐 및 컴파일러에 기초하여 제조자에게 융통성을 제공하여 오브젝트 이미지에 기초한 또는 SAV 무결성 체크의 스테이지에 기초한 모듈의 그룹화를 가능하게 한다.
모듈 ID는 소프트웨어의 각종 모듈을 추적하기 위해 사용되고, 표준화가 불가능하지 않다 하더라도 표준화되지 않을 수 있다. 만일 모듈 ID가 표준화되지 않으면, 제조자는 어떤 모듈이 얼마나 많이 존재하는지를 결정해야 한다. 모듈 ID는 펌웨어/소프트웨어 업데이트 패키지를 제공하고 추적하며 구성하기 위해 사용될 수 있다.
여기에서는 모듈, 컴포넌트 및 기능성과 같은 각종 식별자들 간의 관계를 조직하고 설명하기 위한 방법 및 구조가 개시된다. 도 1은 하나의 예시적인 방법 및 구조를 도시한 것이다. 소프트웨어 아키텍쳐는 모듈의 수 및 유형을 규정한다. 이 모듈들은 그들의 기능성 및 무결성 체크량에 따라서 분류된다. 복수의 모듈로 구성된 컴포넌트는 그 자신의 TRV를 갖는다. 자신의 TRV를 이용한 임의의 컴포넌트의 무결성 체크가 실패하면, 컴포넌트 자신이 변경되거나 자신의 다이제스트가 더 이상 TRV의 값과 동일하지 않거나 컴포넌트에 대응하는 TRV가 변경된다. 어느 경우이든, 무결성 체크가 실패하면 무결성 체크가 실패한 컴포넌트와 모듈들 간의 맵핑뿐만 아니라 모듈과 기능성 간의 맵핑이 실패한(또는 적어도 "영향을 받은") 기능성의 리스트를 결정하는데 사용될 수 있다. 영향을 받은 기능성의 식별자 리스트는 H(e)MS 또는 PVE에 전달될 수 있다.
도 2는 컴포넌트의 구조 및 기능성의 예를 보인 것이다. 도시된 바와 같이, 컴포넌트가 무결성 체크가 수행되는 양일 때, 컴포넌트는 제조자에 의해 결정될 수 있다. 각 컴포넌트에 대하여, 기능성의 리스트가 관련될 수 있다. 컴포넌트는 기능성에 기반을 둔다. 그러므로, 컴포넌트가 무결성 체크를 실패한 때, 실패한 기능성의 리스트가 구축될 수 있다. 컴포넌트들은 그들의 로딩 순서에 따라서, 또는 대안적으로 실행 순서의 순으로 조직될 수 있다. 그러므로, 만일 컴포넌트 1이 체크를 실패하면 로딩 또는 실행을 위해 컴포넌트 1로부터의 기능을 사용하는 컴포넌트 2의 기능성이 또한 실패할 수 있다.
실패한 무결성 체크에 기초하여 실패한 기능성의 리스트를 추출하는 다른 대안적인 구현예가 이미지 목적 파일의 조각에서 무결성 체크를 수행하게 할 수 있다. 만일 오브젝트 이미지의 시작 어드레스와 끝 어드레스에 의해 지정된 특정의 이미지 블록이 무결성 체크를 통과하지 못하면, 실패한 세그멘트에 대응하는 소프트웨어 기능의 명칭이 추출된다. 구현된 기능에 기초해서, 실패한 H(e)NB 기능성의 리스트가 유도될 수 있다. 이것은 소프트웨어 기능이 특정 H(e)NB 기능성을 구현하는 모듈에 속하기 때문에 행하여진다. 예를 들면, UNIX 환경에서 'nm'은 목적 파일에서 기능의 명칭을 추출하는 기능성을 제공한다. 이 정보는 오브젝트의 기호표(symbol table)로부터 추출된다.
여기에서는 확인 방법을 위한 소프트웨어 및 TRV의 다운로드 및 공급이 개시된다. 사용되는 3개의 프로토콜은 TR069 기반 아키텍쳐, 개방 모바일 동맹(Open Mobile Alliance; OMA) 장치 관리(DM) 기반 아키텍쳐 및 신뢰된 컴퓨팅 그룹(TCG) 하부구조 작업그룹(IWG) 기반 아키텍쳐이다. 게다가 상기 프로토콜들은 공급 지원을 이용함으로써 H(e)NB를 구성하기 위해 또한 사용될 수 있다. 상기 3개의 프로토콜 외의 다른 프로토콜을 또한 고려할 수 있다.
도 3의 TR069 기반 아키텍쳐는 고객 구내 설비(CPE: customer premises equipment)와 자동 구성 서버(ACS: auto-configuration server) 간의 통신용으로 의도된 CPE 광역 통신망(WAN: wide area network) 관리 프로토콜을 묘사한다. CPE는 H(e)NB에 맵되고 ACS는 H(e)MS/교정 서버/운용, 경영 및 관리(operation, administration, management; OAM)에 맵된다. CPE WAN 관리 프로토콜은 CPE 소프트웨어/펌웨어 이미지 파일의 다운로드를 관리하기 위한 도구(tool)를 제공할 수 있다. 이 프로토콜은 버전 식별, 파일 다운로드 개시(ACS 개시 다운로드 및 선택적인 CPE 개시 다운로드), 및 파일 다운로드의 성공 또는 실패의 ACS에 대한 통지를 위한 메카니즘을 제공할 수 있다.
CPE WAN 관리 프로토콜은 수행할 CPE의 명시적 설치 명령어와 함께 개개의 파일 또는 파일 패키지를 다운로드하기 위해 선택적으로 사용할 수 있는 디지털식으로 서명된 파일 포맷을 또한 규정할 수 있다. 상기 서명된 패키지 포맷은 다운로드한 파일 및 관련 설치 명령어의 무결성을 보장하여 ACS 운용자 외의 제3자일 수 있는 파일 소스의 인증을 가능하게 한다. 다운로드한 파일의 무결성 체크는 다운로드 파일에 내포된 개개의 모듈로부터 계산된 무결성 다이제스트(예를 들면 해쉬)를 그 대응하는 RIM 값과 비교하는 것에 기초를 둘 수 있다.
CPE WAN 관리 프로토콜은 장치 무결성 체크를 위해 필요한 TRV를 H(e)NB에 다운로드하는데 유용할 수 있다. 이러한 콘텐트는 네트워크 운용자 서명키에 의해 디지털식으로 서명될 수 있다. 서명된 패킷을 수신하면, H(e)NB는 서명을 복호하여 수신된 TRV의 진정성 및 무결성을 검증할 수 있다. 컴포넌트가 수 개의 순서가 정해진(ordered) 연쇄적인 모듈로서 구축된 경우에, TRV는 그 모듈들에 대응하는 순서가 정해진 연쇄적인 RIM으로서 구축될 수 있다.
TRV는 디지털 서명되기 전에 기밀성을 위해 암호화될 수 있다. TRV는 동일한 디지털 서명된 패킷 내에서 TRV가 생성한 소프트웨어 모듈 바이너리 이미지의 전부에 또는 일부(최초 또는 최종)에 또한 첨부될 수 있다.
여기에서는 H(e)NB 장치를 취급하기 위한 추가적인 절차가 개시된다. 이 추가적인 필요조건 및 절차는 이하의 설명에서 H(e)NB-H(e)MS 인터페이스로서 식별된 인터페이스를 사용한다. H(e)NB의 확인은 추가적인 프로토콜 컴포넌트 필요조건을 필요로 할 수 있다. H(e)NB-H(e)MS는 보안 소켓층/운송층 보안(SSL/TLS)을 지원하고 H(e)NB와 H(e)MS 간의 인증서 기반 인증을 사용하여야 한다. 이 인증서는 SeGW에 대한 인증을 위해 사용된 것과 동일한 인증서일 수 있다. 만일 TR069 기반 아키텍쳐가 H(e)NB-H(e)MS 인터페이스용으로 사용되면, CPE 인증을 위한 기본 또는 다이제스트 인증이 인증서 기반 인증을 지원하도록 적응될 필요가 있다.
여기에서는 TR069 아키텍쳐에 기반을 둔 H(e)MS 디스커버리를 위해 필요할 수 있는 절차 또는 구조가 개시된다. H(e)NB는 관리서버.URL 파라미터내의 디폴트 H(e)MS 균일 리소스 로케이터(URL)에 의해 구성되어야 한다. 이러한 초기 구성은 H(e)NB를 배분하는 동안 운용자에 의해 또는 제조자에 의해 행하여질 수 있다. H(e)NB는 허가된 관리자에 의한 근거리 통신망(LAN)-사이드 관리서버.URL 구성을 지원할 수 있다. H(e)MS URL은 하이퍼텍스트 트랜스퍼 프로토콜 시큐어(HTTPS) URL일 수 있다. 호스팅 파티 동적 호스트 구성 프로토콜(DHCP) 기반 H(e)MS URL 업데이트 절차는 지원되지 않을 수 있다. 만일 값이 국소적으로 업데이트되면, H(e)NB는 새로운 H(e)MS와 접촉하여 구성 파일을 부트스트랩하고 친화성(affinity)을 확립할 수 있다. URL이 명칭이거나 인터넷 프로토콜(IP) 어드레스이면, 도메인명 시스템(DNS) 분해능(resolution)이 필요할 수 있다. 명칭의 DNS 분해능은 복수의 IP 어드레스를 돌려보낼 수 있고, 그 경우에 복수의 IP가 반환되지 않거나 또는 복수의 IP가 반환되면 H(e)NB가 하나를 무작위로 골라내는 것이 보장된다.
여기에서는 TR069 아키텍쳐에 기반한 SeGW 디스커버리가 개시된다. H(e)S URL과 유사하게, SeGW URL은 파라미터(SecureGateway.URL)로서 추가될 수 있다. 이 URL은 H(e)NB의 위치에 기초하여 운용자에 의해 구성될 수 있다. DHCP에 의한 상기 파라미터의 업데이트는 지원되지 않을 수 있다. 허가된 관리자에 의한 국소 업데이트는 수행될 수 있다.
AuV 및 SAV의 목적으로 TR069, OMA DM 또는 TCG IWG와 같은 장치 관리 프로토콜을 적응시키기 위한 추가적인 메카니즘이 이하에서 개시된다.
여기에서는 확인 메서드의 소프트웨어 및 TRV를 다운로드 및 공급하기 위한 OMA DM 기반 아키텍쳐가 개시된다. OMA DM은 OMA DM 워킹그룹 및 데이터 동기화(DS) 워킹 그룹에 의해 함께 특정된 장치 관리 프로토콜이다. 비록 OMD DM이 전화기, PDA와 같은 작은 풋프린트(foot-print)를 갖는 모바일 설비 및 기타 유사한 장치용으로 개발되었지만, 이 OMD DM은 설비와 DM 서버 간의 광대역 유선 접속을 지원하기에는 부족하고 단거리 유선 접속(예를 들면, 범용 직렬 버스(USB) 또는 RS232C) 또는 무선 접속(범용 이동 통신 시스템(GSM), 코드분할 다중 접속(CDMA), 무선 근거리 통신망(WLAN), 및 기타의 무선 통신 시스템)만을 지원하고, H(e)NB에 대한 장치 공급 및 관리 프로토콜로서 유용할 수 있다. 이것은 자신을 공통 직렬 게이트웨이(CSG) 및 이것에 접속된 비CSG(non-CSG) WTRU에 대한 기지국으로서 제공하면서 자신을 코어 네트워크에 대한 무선 송신 유닛(WTRU)으로서 제공할 수 있는 H(e)NB에 대하여 유용할 수 있다.
OMA DM은 공급(최초 장치 구성 및 인에이블/디스에이블 특징을 포함함), 장치 구성 업데이트, 소프트웨어 업그레이드, 및 진단 보고와 질의 등의 사용 경우(use case)를 지원할 수 있다. OMA DM 서버측은 비록 장치가 상기 특징들의 전부 또는 부분집합을 선택적으로 구현할 수 있다 하더라도 상기 기능들을 모두 지원할 수 있다.
OMA 명세는 접속이 제한된 소형 풋프린트 장치의 상기 리스트된 특징들을 지원하도록 최적화될 수 있다. OMA 명세는 또한 명세의 일부로서 이루어진 인증(상기 프로토콜을 확장형 인증 프로토콜-인증 및 키 협약(EAP-AKA)으로서 이용함으로써) 프로토콜을 이용하여 통합 보안을 지원할 수 있다.
OMA DM은 데이터 교환을 위해 XML(또는 더 정확하게는 SyncML의 부분집합)을 이용할 수 있다. 이것은 확인 목적으로 H(e)NB에 대한 소프트웨어 모듈 또는 기능성의 속성들을 정의 및 전달하기 위한 표준화 가능한 융통성 방법을 제공하는데 유용할 수 있다.
장치 관리는 DM 서버(장치의 관리 엔티티)와 클라이언트(관리되는 장치) 사이에서 발생한다. OMA DM은 무선 애플리케이션 프로토콜(WAP), HTTP 또는 오브젝트 교환(OBEX) 또는 유사한 운송 등의 운송층(transport layer)을 지원한다.
DM 통신은 통지 또는 경고 메시지를 이용하여 WAP, 푸시 또는 단문 서비스(SMS)와 같은 임의의 이용가능한 방법을 이용하여 DM 서버에 의해 비동기적으로 개시된다. 서버와 클라이언트 간에 일단 통신이 설정되면, 주어진 DM 작업(task)을 완료하기 위해 메시지의 시퀀스가 교환될 수 있다.
OMA DM 통신은 요구-응답 프로토콜에 기초할 수 있고, 요구는 DM 서버에 의해서만 이루어지고 클라이언트는 응답 메시지로 응답한다. 서버와 클라이언트는 둘 다 스테이트풀(stateful)이고, 이것은 특정 순서에 기인하는 임의의 데이터 교환이 빌트인(built-in) 인증 절차 후에만 발생한다는 것을 의미한다.
DM 통신이 DM 서버에 의해서만 개시되기 때문에, DM을 통한 SAV의 구현은 아마도 인터넷 키 교환 (IKE)v2(이것은 장치에 의해 개시된다)를 이용한 장치 인증 절차 직후에 서버-질의-기반 확인 방법을 요구할 수 있다. 몇 개의 다른 메시지 유형은 확인 데이터(예를 들면, 실패한 소프트웨어 모듈 또는 장치 기능성의 리스트)의 운반자(conveyor)로서 고려될 수 있다. 예를 들면, 관리 경보 메시지는 장치로부터 서버로 전송될 수 있다. 대안적으로 장치 또는 서버로부터 적어도 하나의 관리 경보 메시지의 전송이 있은 후에 장치로부터 DM 서버로 보내지는 일반 경보 메시지의 사용자가 또한 고려될 수 있다. 이러한 경보 메시지를 포함한 모든 메시지는 콘텐츠를 특정하는 융통성 및 콘텐츠에 대한 메타데이터를 제공하는 동기화 마크업 언어(SyncML)를 사용하기 때문에, 확인 정보 전송에 유용할 수 있다. DM은 세그멘트화 데이터 전송을 지원하고, 이것은 업데이트의 크기가 대형일 때 소프트웨어 업데이트에 유용하다. 세그멘트화 데이터 전송은 정보의 크기가 복수의 메시지로 분할을 요구할 정도로 충분히 큰 경우에 H(e)NB로부터 PVE로 H(e)NB의 실패 기능성의 리스트를 전송하기 위해 또한 사용될 수 있다.
여기에서는 확인 방법의 소프트웨어 및 TRV를 다운로드 및 공급하기 위한 TCG IWG 기반 아키텍쳐가 개시된다. 신뢰된 연산 그룹(TCG), 하부구조 작업 그룹(IWG)은 플랫폼 무결성 관리를 위한 세부적인 포맷 및 프로토콜을 특정한다. 무결성 측정 및 보고를 위한 기본 모델에 있어서, 네트워크 및 서비스 액세스는 플랫폼의 검증된 상태로 조절될 수 있다.
TCG IWG 표준은 H(e)NB SAV 또는 AuV에 대하여 필요한 구조의 상위집합(superset)이다. IWG 명세 중 어느 것도 기성품(off-the-shelf)으로 사용될 수 없다. 또한 장치 확인의 특정 쓰임새에 대한 IWG 명세의 프로파일링은 XML 스키마 수정(예를 들면, 필요한 요소의 생략)을 요구할 수 있고, 이것은 IWG 표준으로부터의 벗어남을 의미한다.
요구 플랫폼과 네트워크측 검증자 간의 기본적인 상호작용은 도 4에 도시하였다. 검증자는 요청자 플랫폼의 각 컴포넌트에 관한 허가된 정보(authoritative information)를 찾을 필요가 있다(제5 단계에서). 즉, 메트릭 공급자에 의해 사용가능으로 되는 플랫폼 확인을 위한 참고 측정치를 필요로 한다. 메트릭 공급자의 예로는 하드웨어 제조자, 소프트웨어 판매자 또는 제조자 및 판매자를 대신하는 신뢰된 공급자가 있다. 검증자가 요청자 플랫폼의 각 컴포넌트를 식별하고 보고된 측정치를 기대된(베이스라인) 참고 측정치(상기 컴포넌트에 대한 것)와 비교할 수 있으면, 검증자는 요청자 플랫폼의 신뢰성 레벨을 측정할 수 있다. 이 단계에서, 검증자는 신뢰하는 아티(relying arty)에서 리소스/서비스를 액세스하는 요청자의 희망에 관한 결정을 할 수 있다. 이것은 제6 단계에서 나타나 있다.
IWG 무결성 검증 아키텍쳐는 검증 플랫폼에서 하드웨어 신뢰 플랫폼 모듈(TPM)의 존재에 대부분 독립적임을 알 수 있다. 특히 표준으로 특정된 데이터 포맷은 일반 컴포넌트 및 플랫폼 보안 관련 속성을 표현할 수 있다.
주어진 컴포넌트에서 기술적 신뢰를 지원하기 위해, 컴포넌트 제조자는 그 제품을 컴포넌트의 출처에 관한 정보로 지원할 수 있다. 즉, 제조자 또는 신뢰된 제3자는 그 컴포넌트에 대한 어떤 정적 참고값을 제공하여야 한다. 컴포넌트에 대한 이러한 정적 참고/메트릭 값은 참고 측정치라고 부르고 TCG 참고 적하목록(RM) 구조의 형식으로 표시된다. 컴포넌트에 대한 적하목록은 그 신원(identity), 제조자, 모델 번호, 버전 번호 및 기타의 정보를 포함한다. 이 출원의 목적상, H(e)NB의 컴포넌트의 신뢰된 참고값(TRV)은 TCG IWG 참고 적하목록(RM) 구조에 의해 특정될 수 있다.
플랫폼이 확인될 필요가 있을 때, 플랫폼은 도 5에 도시된 바와 같이 플랫폼 컴포넌트를 커버하는 일련의 스냅샷으로부터 컴파일된 무결성 리포트를 밸리데이터(validator)(플랫폼 검증 엔티티(PVE) 등)에게 제공하여야 한다. 스냅샷은 플랫폼의 각각의 관련 컴포넌트(및 아마도 컴포넌트의 서브-컴포넌트)에 대한 측정치 및 주장(assertion)을 둘 다 표시한다. 레퍼런스(ID Refs)는 도 6에 도시된 바와 같이 무결성 리포트에서 보고된 컴포넌트에 속한 정보를 지적하기 위해 사용된다.
RM에 기초한 확인의 핵심 요소는 TCG 표준으로 묘사된다. 융통성을 위해, XML 네임스페이스가 IWG 포맷의 플랫폼 특정 프로파일, 예를 들면 모바일 또는 PC-클라이언트에 대해 사용될 수 있다.
상호작용이 가능한 무결성 로그(log) 구조는 플랫폼 특정 암호화를 표시하기 위한 "하드웨어 아키텍쳐" 유형 값을 규정함으로써 일부 플랫폼 특정 제약을 취급할 수 있다. 유형 값(type value)은 XML 네임스페이스 및 XRI 등의 상호작용이 가능한 네임스페이스 메카니즘을 이용하여 TCG 네임스페이스 항목으로 규정될 수 있다.
핵심 스키마로부터의 연장에 의해 계승하는 RM 스키마는 레퍼런스를 유지하도록 구조를 규정한다. RM 스키마는 도 7에 도시된 바와 같이 2개의 정보 집합으로 구성되는 것으로 대략적으로 이해할 수 있다. 제1 집합은 개별 컴포넌트에 대한 정보에 속하고 컴포넌트 모델, 명칭, 버전, 일련 번호 등과 같은 속성을 커버한다. 이 정보는 컴포넌트 ID 유형(ComponentIDtype) 구조에서 포착된다. 이 컴포넌트 특정 정보 주변은 컴포넌트 정보의 포착(수확)에 속하는 메타데이터에 의해 둘러싸인다. 이것은 스키마의 무결성 적하목록 유형(IntegrityManifestType) 구조에 의해 표시된다. 포착된 메타데이터는 사용된 수집자(수확자) 메서드, RM 서명(및 관련 서명자/발행자 정보), (소프트웨어의) 컴포넌트에 대한 다이제스트 값, 신뢰 수준, 형성된 주장 등을 포함한다.
여기에서는 AuV에 특정된 아이템이 개시된다. AuV에 있어서, 무결성 체크는 국소적으로 수행될 수 있다. 그러므로, 여기에서 설명하는 임의의 디지털 서명 또는 메시지 인증 코드가 사용될 수 있다. 이들은 제조자의 개인키/공유 비밀키를 이용하여 제조자에 의해 서명될 수 있고 제조자의 공유 비밀키 또는 공개키를 이용하여 그들의 진정성에 대해 국소적으로 검증될 수 있으며 코드의 무결성을 국소적으로 검증하기 위해 사용될 수 있다.
그러나, AuV에 있어서, 장치 확인은 장치 내에서 국소적으로 수행될 수 있고, 정보는 어떤 네트워크 엔티티에도 전송되지 않는다. 그러므로, 장치 확인은 확인을 위해 사용하는 정확한 방법을 결정하기 위해 제조자에게 남겨질 수 있다. 그러나, '무결성 알고리즘은 SHA-1과 등가이거나 더 나은 보안을 제공하여야 한다'와 같이 최소의 보안 필요조건이 표준화될 수 있다.
여기에서는 AuV가 TRV 인증서 관리를 어떻게 구현하는지가 개시된다. 시스템의 컴포넌트들은 실제 구현에 의존하기 때문에, 장치 무결성을 위해 사용되는 메카니즘들을 조화시킬 필요가 있다. 이것은 TRV라고 알려져 있는 신뢰된 참고 무결성 메트릭을 발생하기 위해 사용되는 방법을 위한 최소 필요조건을 표준화함으로써 달성될 수 있다. 이 TRV는 값들을 디지털식으로 서명하는 제조자 또는 TTP에 의해 발생될 수 있다. 그러므로, 정보를 조직하고 TRV를 발생하고 이들을 배분하고 이들을 사용하는 메카니즘이 검토(review)된다.
여기에서는 최초 TRV 인증서 초기화가 개시된다. H(e)NB가 완전하게 개발된 후에, 제조자는 국소 무결성 데이터 초기화를 수행한다. 이 처리에서, 소프트웨어 모듈 명칭들이 모두 장치 구성 데이터 시트에 수집된다. 만일 구성 파일과 관련된 임의의 팩토리 설정(factory setting)이 주어지면, 이 팩토리 설정은 장치 구성 데이터 시트에 또한 포함된다. 모듈들은 실행가능하고 소스 코드가 아니다. 구성 데이터의 초기 공급이 또한 수행된다. 장치 구성 데이터 시트 스키마는 표준 스키마를 따른다. 여기에서 제시되는 XML 또는 ASN.1 스키마는 베이스라인으로서 사용될 수 있다. 가혹성, 호환성, 스테이지 등에 관한 모든 속성들은 장치의 아키텍쳐에 따라서 상주(populate)된다.
도 8은 인증서 관리 아키텍쳐(800)를 보인 것이다. 제조자의 인증 서버(805)에서, 모든 모듈 엔트리(810)는 참고 무결성 메트릭과 함께 상주된다. 무결성 메서드 속성 및 TRV 속성이 상주된다. 그 다음에, 장치 구성 데이터 시트가 개인키(820)를 이용하여 제조자에 의해 서명된다. TTP에 의해 제조자에게 발행된 최상위 인증서(root certificate)에 관하여 또한 인증될 수 있다. 따라서, 참고 무결성 메트릭(RIM)이 TRV(830)로 된다.
다른 아키텍쳐에 있어서, TRV는 TTP에 의해 발생될 수 있다. 제조자는 제조자 사이트에서 채워질 수 있는 모든 모듈 및 일부 상주된 속성들을 리스트하는 실행가능한 부분적으로 완성된 장치 구성 시트를 제공한다. 다이제스트 메트릭인 TRV는 TTP에 의해 상주된다. 그 다음에, TTP는 장치 구성 인증서를 디지털식으로 서명한다.
장치 구성 데이터 시트는 AuV가 장치 내에서 국소적으로 수행되기 때문에 장치 내에 유지될 수 있다. 장치 구성 데이터 시트는 인증된 당사자에 의해서만 액세스되는 보안 메모리 내에 유지되어야 한다. 대안적으로, 장치 구성 데이터 시트는 암호화되어야 하고 이 데이터 시트를 판독하여 사용할 때 H(e)NB에서 복호될 수 있다. 어느 경우이든, H(e)NB의 신뢰된 환경(TrE)만이 애플리케이션에 의한 판독 액세스를 위해 장치 구성 데이터 시트를 해제(release)하고 수정하도록 권한을 가져야 한다.
안전한 시동(start-up) 처리중에, 장치가 컴포넌트의 국부 측정을 수행할 때, 발생된 다이제스트는 장치 구성 데이터 시트에서 특정된 값과 비교된다. 만일 불일치가 발생하면, 장치 무결성 확인의 실패로서 해석된다. 장치 구성 데이터 시트의 무결성은 이것이 액세스되기 전에 검증되어야 한다. 장치 구성 데이터 시트의 무결성은 데이터 시트 내에서 특정된 임의의 하나 이상의 컴포넌트의 하나 이상의 무결성 체크 실패 후에도 또한 검증될 수 있다.
여기에서는 후속하는 TRV 인증서 업데이트 절차가 개시된다. 전개된(deployed) H(e)NB 시스템에 있어서, 만일 제조자에 의해 새로운 소프트웨어 버전이 발행되면, 제조자는 소프트웨어 모듈과 함께 장치 구성 데이터 시트를 H(e)MS/OAM 서버/교정 서버에 제공할 수 있다. 이것은 제조자에 의해 '푸시' 동작을 수행함으로써 비동기적으로 수행될 수 있다. 이러한 푸시는 운용자와 제조자 간에 서명된 서비스 협약에 따라서 운용자와 제조자 간에 합의된 계획된 업데이트/업그레이드에 기초하여 계획될 수 있다.
이러한 푸시 다음에, 펌웨어 또는 소프트웨어 모듈을 업데이트하기 위한 OAM 절차 또는 TR069 절차가 호출(invoke)되어 H(e)MS/OAM/교정 서버로부터의 소프트웨어/펌웨어에 대한 '풀' 동작을 수행하도록 장치가 계획된 시간에 리부트하도록 지시할 수 있다. 암호화, 서명 및 넌스(nonce)는 기밀성, 무결정 및 재전송 공격 방지(replay protection)와 같은 보안 양상들을 각각 제공할 수 있다.
대안적으로, 장치 구성 데이터 시트가 소프트웨어 해제 계획에 따른 계획된 만기에 기인하여 만료된 때, H(e)NB는 펌웨어/소프트웨어 업데이트 처리를 시작하고 OAM/교정 서버로부터의 소프트웨어/펌웨어에 대한 풀(PULL)을 시작할 수 있다. 대안적으로 H(e)MS는 소프트웨어 해제의 공지된 계획(제조자로부터 얻어진 것)에 따라서 소프트웨어 업데이트의 계획된 푸시를 수행할 수 있다.
여기에서는 장치에 대한 소프트웨어/펌웨어 다운로드를 지원하는 TR069 또는 OMA DM 아키텍쳐에 기초한 절차가 개시된다. AuV의 경우에, TR069 프로토콜은 고객 구내 설비의 원격 관리를 위한 지원을 제공할 수 있다. TR069 프로토콜은 또한 장치 소프트웨어/펌웨어 업데이트의 지원을 제공할 수 있다. TR069는 펌웨어/소프트웨어 업데이트를 H(e)NB 장치에 제공하기 위해 사용될 수 있다.
여기에서는 도 9에 도시한 바와 같이 허가된 관리자에 의해 또는 URL 업데이트 절차를 이용하여 H(e)NB(905)에서 수행될 수 있는 후속 업데이트를 위한 H(e)NB(905))와 H(e)MS(910) 간의 예시적인 AuV 절차가 개시된다. H(e)NB(905)는 초기에 H(e)MS 디스커버리와 관련하여 위에서 설명한 관리서버.URL 파라미터(0) 내의 디폴트 H(e)MS 균일 리소스 로케이터(URL)로 구성된다. 이것은 제조자에 의해 공급될 수 있다. H(e)MS(910)는 전송 제어 프로토콜(TCP) 접속을 개방한다(1). 보안 소켓 층(SSL) 접속은 H(e)NB(905)와 H(e)MS(910) 사이에 확립되어 보안 통신을 가능하게 한다(2). H(e)MS(910)는 원격 제어 호출(RPC) 메서드 설정 파라미터 값(SetParameterValues)을 개시하고 측정서버.URL을 업데이트한다(3). 설정 파라미터 값을 성공적으로 업데이트한 후, 응답이 성공 또는 실패를 표시하는 상태 필드와 함께 H(e)NB(905)에 의해 전송된다(4). H(e)NB(905)는 H(e)MS URL을 업데이트한다(5).
여기에서는 H(e)NB-H(e)MS 인터페이스에 대하여 TR069를 이용한 파일 전송을 지원하는 AuV 절차가 개시된다. TR069는 유니캐스트 및 멀티캐스트 운송 프로토콜에 의한 파일 전송을 지원한다. 유니캐스트 프로토콜은 HTTP/HTTPS, 파일 전송 프로토콜(FTP), 보안 파일 전송 프로토콜(SFTP) 및 통속 파일 전송 프로토콜(TFTP)을 포함한다. 멀티캐스트 프로토콜은 단방향성 운송을 통한 파일 전달(FLUTE) 및 디지털 기억 매체 명령 및 제어(DSM-CC)를 포함한다. HTTP/HTTPS에 대한 지원은 강제적이다. HTTP/HTTPS에 추가하여, H(e)NB-H(e)MS 인터페이스에서 펌웨어/소프트웨어 다운로드에 대한 TR069를 적응시키기 위해, FTP 보안(FTPS)이 또한 사용될 수 있고, TR069에 추가될 필요가 있다. FTPS(FTP 보안 및 FTP-SSL이라고도 알려져 있음)는 운송 층 보안(TLS) 및 SSL 암호화 프로토콜에 대한 지원을 추가한 FTP의 확장판이다. H(e)NB-H(e)MS 인터페이스는 TLS-SSL 인터페이스를 사용하기 때문에, FTPS는 파일의 전송을 위해 구현될 수 있다.
TR069는 파일의 다운로드를 위한 동일한 TLS 접속의 재사용, 병렬로 존재하는 파일의 다운로드를 위한 새로운 접속의 생성 또는 제1 세션의 해제를 위한 지원을 또한 제공한다. 다운로드를 완료한 후, 시그널링을 위한 TLS 접속이 확립된다. 만일 HTTP/HTTPS가 파일을 다운로드하기 위해 사용되면, 표준 TR069 절차를 활용할 수 있다.
여기에서는 교정 지원을 위한 예시적인 AuV 절차가 개시된다. 만일 장치 무결정 체크가 AuV에서 실패하면, 국소 재난 플래그가 세트되고 시스템이 폴백 코드(FBC)로 리부트된다. FBC는 장치에 안전하게 저장될 수 있고, 보안 시동 절차(또는 장치의 기본 무결성을 보장하기 위한 "본질적"인 것으로서 간주되는 장치의 임의의 다른 처리)가 실패한 경우 로드되어 실행될 수 있다. FBC는 코어 네트워크와 기본적인 통신을 행하는 능력이 있고, 재난 신호를 미리 지정된 H(e)MS에 전송하는 능력이 있다. H(e)MS는 H(e)MS 디스커버리 절차에 의해 업데이트될 수 있다. 재난 신호의 내용은 장치의 FBC에 안전하게 저장될 수 있고, 또는 MNO에 의해 공급되어 장치 구성 데이터 시트의 일부로서 안전하게 저장될 수 있다. 재난 신호는 장치 무결정 체크 실패의 세부를 표시하는 에러 코드 정보 요소를 포함할 수 있다. 재난 신호를 수신한 때, 네트워크는 신뢰된 참고값을 내포하는 장치 구성 파일 및 완전한 이미지를 업데이트하도록 결정할 수 있다. FTP 서버는 완전한 이미지, 장치 구성 파일 및 설치 명령어를 내포한 패키지 파일을 저장한다. FTP 서버는 H(e)MS와 합체될 수 있다.
이 절차는 TR069 프로토콜을 지원하는 FBC에 의해 달성될 수 있고, H(e)NB(1005), H(e)MS(1010) 및 FTP 서버(1015) 간의 예시적인 흐름도(1000)가 도 10에 도시되어 있다. 장치 무결성 체크가 실패하고 신뢰의 근원(Root of Trust; RoT)이 H(e)NB(1005)에서 FBC를 부트업하면(0), H(e)NB(1005)는 미리 지정된 H(e)MS 서버(1010)에 대한 TCP 접속을 설정한다(1). SSL 개시가 수행되고 및/또는 운송 층 보안(TLS)이 설정된다(2). 그 다음에 H(e)NB(1005)가 RPC 메서드 정보, 예를 들면 재난 신호를 H(e)MS(1010)에 불러들인다. 재난 신호는 장치 ID, 이벤트, 최대 엔벨로프(MaxEnvelopes) 및 현재 시간(CurrentTime)과 같은 정보 요소의 임의 조합을 포함할 수 있다.
장치 ID는 제조자명; 장치 제조자의 조직적으로 유일한 식별자(OUI); 일련 번호가 부여되는 제품의 등급(class)을 표시하거나 일련 번호 속성을 이용하여 TrE ID 또는 H(e)NB ID를 표시하도록 장치의 일련 번호를 표시하기 위해 사용될 수 있는 제품 등급(ProductClass); 및 특수 장치의 일련 번호를 전송하거나 TrE ID 또는 H(e)NB ID를 전송하기 위해 사용되는 일련 번호를 포함하는 구조이다.
이벤트 필드는 실행되는 RPC 메서드 통보(Inform)를 야기한 이벤트 코드를 포함할 수 있다. 새로운 이벤트 코드(X-HeNB_FBC 호출)는 장치 무결성 체크가 실패했다는 것 및 FBC가 이 재난 신호를 전송하도록 호출되었다는 것을 표시하기 위해 규정될 필요가 있다. 단일 HTTP 응답에 포함될 수 있는 파라미터 호출 "SOAP 엔벨로프"의 최대 발생 수를 ACS(예를 들면, H(e)MS)에 표시하는 최대 엔벨로프 값은 1로 설정될 수 있다. 최대 엔벨로프 파라미터의 값은 1 이상일 수 있다. 재난 표시는 단지 1회 전송되도록 의도되기 때문에, 이 값을 1로 설정하는 것은 적당하다. 현재 시간 필드는 H(e)NB(1005)에 알려진 현재 날짜 및 시간의 값이다. 따라서, 통보 RPC 메서드는 장치가 무결성 체크를 실패하였고 펌웨어/소프트웨어 업데이트를 개시하기 위해 접속되어 있음을 H(e)MS(1010)에 표시한다.
절차(1000)의 나머지는 선택적이다. H(e)MS(1010)은 RPC 메서드 다운로드를 호출하고 펌웨어 또는 소프트웨어의 위치의 URL 및 장치 구성 데이터 시트를 제공한다(4). 다음의 파라미터 값이 설정된다. 명령키(CommandKey) 파라미터는 특수 다운로드를 인용하기 위해 H(e)NB(1005)에 의해 사용될 수 있는 문자열이다. 이것은 다운로드와 응답을 상관시키기 위해 사용되는 임의의 문자열일 수 있다. 파일 유형(FileType) 파리미터는 펌웨어/소프트웨어 이미지에 대하여 "1 펌웨어 업그레이드 이미지"로 및 장치 구성 데이터 시트에 대하여 "X_<OUI>_데이터_시트"로 설정될 수 있다. URL 파라미터는 다운로드 파일의 URL이다. HTTP 및 HTTPS는 지원되어야 한다. FTPS의 지원이 다운로드를 위해 또한 권장된다. 사용자명(Username) 파라미터는 파일 서버에 대한 인증을 위해 H(e)NB(1005)에 의해 사용될 수 있다. 패스워드 파라미터는 파일 서버에 대한 인증을 위해 H(e)NB(1005)에 의해 사용될 수 있다. 파일 크기(FileSize) 파라미터는 다운로드되는 파일의 크기이다. 다른 파라미터들이 또한 설정될 수 있다.
H(e)NB(1005)는 FTP 서버(1015)에 접속되고 펌웨어 이미지(또는 소프트웨어 이미지) 및 장치 구성 데이터 시트를 다운로드한다(5). FTP 서버(1015)에서의 정보는 교정 정보로서 표시될 수 있다. 다운로드가 성공적으로 완료된 때, 제로의 값(성공을 표시함)을 가진 상태 아규멘트(status argument)을 가진 다운로드 응답, 또는 다운로드 요청에 대한 실패 응답(실패를 표시함)이 보내진다(6). 다운로드의 성공 또는 실패를 표시하기 위해 다른 절차들이 또한 이어질 수 있다. 성공적인 다운로드 응답 후에, H(e)MS(1010)는 H(e)NB(1005)에서 리부트 절차를 호출할 수 있다(7). H(e)NB(1005)의 RPC 핸들러는 국소 재난 플래그를 리세트하고 국소 무결성 체크 절차를 수행하도록 정상적으로 부팅된다(8). 서명된 패키지 포맷은 리부트 명령을 포함할 수 있고, 리부트 명령은 펌웨어 또는 소프트웨어가 업데이트된 후 리부트하도록 H(e)NB(1005)에게 지시하기 위해 사용된다. 전송 완료 RPC 메서드는 펌웨어/소프트웨어 업데이트가 성공적으로 완료되었음을 H(e)MS(1010)에 표시하기 위해 H(e)NB(1005)로부터 호출될 수 있다(9). 대안적으로, SeGW는 장치가 성공적으로 부팅되었음을 표시하고 H(e)MS(1010)에서 성공적인 펌웨어/소프트웨어 업데이트 완료 메시지로서 해석될 수 있는 메시지를 H(e)MS(1010)에 전송할 수 있다.
여기에서는 H(e)NB 펌웨어/소프트웨어 업데이트를 위해 사용되고 도 11에 도시된 예시적인 파일 포맷(1100)이 개시된다. 헤더(1105)는 서문(preamble), 포맷 버전, 및 커맨드 리스트와 페이로드 컴포넌트의 길이를 포함하는 고정 길이 구조일 수 있다. 커맨드 리스트(1110)는 패키지에 내포된 파일들의 추출 및 설치를 위해 실행될 수 있는 명령어의 시퀀스를 포함한다. 각 커맨드는 유형-길이-값(TLV)의 형식을 가질 수 있다. 서명 필드(1115)는 제로 또는 그 이상의 디지털 서명을 포함하는 공개키 암호화 표준(PKCS) #7 디지털 서명 블록을 포함할 수 있다. 페이로드 파일(1120)은 커맨드 리스트(1110)의 명령어에 따라서 설치되는 하나 이상의 파일을 포함할 수 있다. 펌웨어/소프트웨어 업데이트 파일 외에, 장치 구성 데이터 시트가 또한 서명된 패키지 포맷으로 패키지될 수 있다.
스토리지 분류자(storage classifier)의 필요조건을 지원하기 위해, 하기의 새로운 H(e)NB 특정 커맨드가 추가될 수 있다: 1) 안전한 비휘발성 메모리에 저장(TRV 또는 구성 데이터 시트와 같은 데이터에 대해서); 및 2) 비휘발성 스토리지에 저장; 또는 3) 휘발성 스토리지에 저장될 수 있는가.
도 12는 SAV에 대한 예시적인 네트워크 아키텍쳐(1200)를 도시한 것이다. H(e)NB(1205)는 통신 링크(1215)를 통해 코어 네트워크(1220)와 통신하기 위해 사용자 설비(1210)에 대한 게이트웨이로서 작용한다. H(e)NB(1205)는 비보안 통신 링크(1215)를 통해 SeGW(1225)와 상호작용한다. SeGW(1225)는 인증된 H(e)NB들이 코어 네트워크(1220)에 액세스하게 한다. H(e)MS(1230)는 H(e)NB 관리 서버로서 작용하고 교정을 위한 지원을 제공한다. H(e)MS(1230)는 H(e)NB(1205)를 관리하기 위한 표준 프로토콜을 지원할 수 있다. 플랫폼 확인 엔티티(PVE)(1235)는 H(e)NB(1205)에서 특정의 기능성 집합이 실패한 때 취해질 동작을 규정하는 폴리시(policy)를 저장한다. 상기 실패된 기능성들은 SAV 처리중에 H(e)NB(1205)에 의해 보고된다. OAM(1240)은 운용, 통제 및 관리 서버이다. 비록 H(e)MS(1230) 및 PVE(1235)가 별도의 엔티티로 도시되어 있지만, 이들은 단일 네트워크 엔티티로서 함께 합체될 수 있다. 합체된 엔티티는 네트워크 운용자당 단일 노드일 수도 있고, 운용자당 복수의 노드일 수도 있다.
여기에서는 SAV에 관한 절차가 개시된다. 요약하자면, 장치 인증 절차를 수행하기 전에, H(e)NB의 TrE는 비제한적인 예를 들어서 부트 코드, 폴백 코드(FBC), SeGW에 대한 기본 통신 코드, 및 H(e)MS에 액세스하기 위해 H(e)NB를 인에이블시키는 절차를 수행하는 코드와 같은 특정의 미리 지정된 컴포넌트의 무결성 체크를 먼저 수행한다. 이 단계에서, 컴포넌트의 무결성 검증은 무결성 측정으로부터의 다이제스트 출력을 장치 구성 데이터 시트의 특정 값과 비교함으로써 국부적으로 수행될 수 있다. 만일 컴포넌트가 무결성 검증을 통과하면, 컴포넌트들은 로드되어 실행된다.
추가의 체크가 TrE 자체에 의해 또는 TrE 외부에 있지만 TrE에 의해 무결성이 보호되는 H(e)NB 내의 측정 컴포넌트에 의해 발생할 수 있다. 이러한 후반 단계 체크에 있어서, 다른 컴포넌트의 무결성, 구성, 또는 H(e)NB의 나머지의 파라미터는 이들이 로드되거나 시작되는 때에, 또는 측정 컴포넌트에 이용가능할 때마다 다른 미리 규정된 런타임 시간 이벤트에서 체크될 수 있다. 이 단계에서, 무결성 체크의 검증은 국부적으로 수행될 수 있다.
H(e)NB는 그 다음에 SeGW와 인터넷 키 교환(IKEv2) 보안 관계를 확립하려고 시도할 수 있다. 그 처리에서, H(e)NB는 SeGW에 자신을 인증하고 SeGW의 진정성을 검증한다. 이것은 인증서 교환 및 인증서 인증에 의해 수행될 수 있다. 인증이 성공하면, TrE는 컴포넌트의 실패에 의해 영향을 받은 실패 기능성 리스트를 컴파일함으로써 국소 무결성 검증의 결과를 PVE에 전달한다. TrE는 그 다음에 무결성 측정 및 검증뿐만 아니라 실패한 기능성 리스트의 (PVE에 대한) 보고를 수행한 H(e)NB의 핵심 부분이 (예를 들면, 신뢰의 근원(RoT)에 의해) 그것에서 수행된 무결성 체크를 통과하였고, 그에 따라서 서명 키를 이용하여 서명 동작을 수행할 수 있으며, 또는 그렇지 않은 경우 비밀 서명 키를 사용함으로써 고유적으로 신뢰된다는 것을 주장하는 메시지를 (TrE에 의해 보호되고 그에 따라서 메시지의 무결성을 보호하는 서명 키를 이용하여) 서명할 수 있다.
도 13A 및 도 13B는 H(e)NB(1305), SeGW(1310) 및 PVE(1315)에 의해 수행되는 예시적인 SAV 절차(1300)를 나타낸 것이다. 컴포넌트 1 및 컴포넌트 2 모듈의 국소 무결성 확인 후에, 모듈들은 로드되어 실행된다. 컴포넌트 3 모듈의 장치 무결성 체크의 결과 및 검증 결과는 H(e)NB(1305)에 의해 SeGW(1310)에 보내지고 다시 PVE(1315)에 전송된다(0).
H(e)NB(1305)는 암호화 알고리즘, 버전 번호, IKEv2 플래그, 디피-헬만 값(Diffie-Hellman value) 및 개시자 넌스의 보안 파라미터 인덱스를 포함한 IKEv2 보안 연합의 확립을 개시하기 위한 IKE_INIT 메시지를 전송할 수 있다(1). SeGW(1310)는 IKE_INIT 요청 메시지에 대한 IKE_INIT 응답을 전송할 수 있다(2). SeGW(1310)는 H(e)NB(1305)로부터 암호화 슈트를 선택하여 디피-헬만 교환을 완성할 수 있다. H(e)NB(1305)는 상호 인증을 위해 IKE_AUTH_REQ 내의 자신의 인증서를 전송할 수 있다(3). H(e)NB(1305)는 무결성 검증의 결과를 실패 기능성 리스트의 형식으로 또한 포함할 수 있다. 만일 국소 무결성 검증이 성공적이면, 실패 기능성 리스트가 포함되지 않는다. 이 경우에는 빈 리스트가 전송된다. 컴포넌트, 모듈 및 기능성 간의 관계는 여기에서 설명되었다.
SeGW(1310)는 H(e)NB(1305)의 인증 증명서를 평가하고 만일 존재하면 PVE(1315)에 전송될 기능성 ID의 리스트를 추출한다(4). 만일 인증 평가가 성공적이면, SeGW(1310)는 이것을 H(e)NB(1305)에 표시한다(5s). SeGW(1310)는 그 자신의 인증서를 응답으로 H(e)NB에 또한 전송할 수 있다. 만일 인증이 실패하면, 이것은 H(e)NB(1305)에 통신된다(5f).
만일 인증이 성공이고 실패 기능성의 리스트가 IKE_AUTH 메시지에 포함되었으면, SeGW(1310)는 실패 기능성의 리스트를 H(e)NB ID와 함께 PVE(1315)에 회송한다(6). 만일 리스트가 없으면 빈 리스트가 PVE(1315)에 보내진다. 실패 기능성의 리스트에 따라서, PVE(1315)는 장치의 격리, 풀 액세스 제공, 부분 액세스 제공, 또는 장치 교정을 위해 H(e)MS 개입을 선택적으로 요청하는 것과 같은 취해질 동작에 대한 결정을 할 수 있다(7). 만일 영향을 받은 기능성이 중요하지 않고 따라서 H(e)NB(1305)가 기능할 수 있다고 PVE(1315)가 결정하면, 이 결정을 SeGW(1310)에 표시하여 장치가 네트워크에 액세스할 수 있게 한다(8s). SeGW(1310)는 PVE(1315)에 의해 수행된 장치 무결성 평가의 결과를 표시한다. 만일 실패한 모듈이 중요하지 않으면, PVE(1315)는 H(e)NB(1305)가 네트워크에 완전하게 액세스(full access)하는 것을 허용할 수 있다(9s). 만일 PVE(1315)가 실패한 기능성에 대한 수신된 빈 리스트에 전적으로 또는 부분적으로 기초하여 H(e)NB가 인증을 위해 충분히 신뢰되었다고 결정하면, H(e)NB의 '확인'의 상태가 얻어진다. 이 점에서, 확인은 H(e)NB(1305)가 네트워크 관점으로부터 PVE(1315)와 추가의 상호작용을 위해 충분히 신뢰성이 있다고 표시하는 PVE(1315)에 의해 행하여진 결정으로서 해석된다.
만일 교정이 지원되면, PVE(1315)는 메시지 내의 H(e)NB ID에 의해 식별된 장치의 교정을 시작하게 하는 표시를 H(e)MS(1320)에 보낸다(8f_1). PVE(1315)는 실패 모듈의 리스트를 또한 포함할 수 있다. 실패 기능성 리스트 및 장치 특정 구성 데이터 시트에 기초해서, H(e)MS(1320)는 필요한 펌웨어 또는 소프트웨어 업데이트를 결정한다. 만일 교정이 지원되면, PVE(1315)는 H(e)MS(1320)에 의해 개시되는 교정을 준비하게 하는 표시를 H(e)NB(1305)에 보낸다. PVE(1315)로부터의 응답에 기초해서, SeGW(1310)는 액세스를 제한하고 그 결과를 H(e)NB(1305)에 통지한다(9f). 시스템은 장치에 의해 개시되는 교정을 시작하도록 FBC 모드에서 리부트한다(10). 이 단계는 리부트가 교정용의 TR069 프로토콜을 이용하여 H(e)MS(1320)에 의해 취급될 수 있기 때문에 선택적으로 행할 수 있다.
여기에서는 SAV의 H(e)MS 및 PVE 디스커버리 절차가 개시된다. H(e)NB는 PVE, H(e)MS 및 OAM의 IP 어드레스를 내포한 팩토리 디폴트 설정으로 구성될 수 있다. 이들은 도 9에서 설명한 바와 같이 TR069 프로토콜에 의해 지원되는 설정파라미터(SetParameter) 및 취득파라미터(GetParameter) RPC 메서드를 이용함으로써 TR069 프로토콜을 이용하여 H(e)MS에 의해 또한 구성될 수 있다. 이 절차는 PVE의 어드레스를 변경하기 위해 또한 사용될 수 있다는 점에 주목한다. 관리서버.URL 파라미터(플랫폼확인서버.URL)와 유사한 추가의 파라미터가 H(e)NB에서 PVE URL을 유지하도록 규정될 수 있다. 유사하게, 플랫폼확인서버.URL의 팩토리 설정이 제조시에 미리 구성될 수 있고 이어서 TR069에 의해 업데이트될 수 있다.
여기에서는 SAV의 무결성 메서드 및 절차가 개시된다. SAV에 있어서, 장치 무결성 체크는 국소적으로 수행될 수 있다. 무결성 체크의 결과는 실패 기능성 리스트의 형식으로 PVE로 통과될 수 있다. 그러므로 여기에서 설명하는 임의의 무결정 체크 메서드는 위의 단락 번호 [0038]~[0040]에서 예로서 도시한 바와 같이 사용될 수 있다. 무결성 체크는 네트워크 엔티티에 의해 수행되지 않는다. 그러므로, 무결정 체크는 확인에 사용하는 정확한 무결성 메서드를 결정하도록 제조자에게 남겨질 수 있다. 그러나, '무결성 메서드는 SHA-1과 등가이거나 더 나은 보안을 제공하여야 한다'와 같이 최소의 보안 필요조건이 표준화될 수 있다.
여기에서는 SAV에서 TRV 인증서 관리를 위해 사용될 수 있는 메카니즘이 개시된다. SAV를 지원하는 인터페이스 및 메시지가 먼저 설명된다. PVE-SeGW 인터페이스는 사용중인 포인트-투-포인트 프로토콜(PPP)을 사용할 수 있다. PPP는 인증, 암호화 및 압축에 대한 지원을 제공할 수 있다. 대안적으로, 운송 층 보안/보안 소켓 층(TLS/SSL)이 또한 사용될 수 있다.
복수의 메시지가 PVE-SeGW 인터페이스를 통해 전송될 수 있다. 예를 들면, H(e)NB_무결성_정보 메시지는 IKEv2 통지(NOTIGY) 메시지로 H(e)NB에 의해 SeGW에 보내지고 SeGW에 의해 추출된 실패 기능성 리스트를 포함할 수 있다. 이 메시지의 콘텐츠의 예는 표 7에 나타내었다.
정보 요소 설명
H(e)NB ID H(e)NB 또는 TrE ID의 유일한 식별자를 포함한다.
(선택사항) 무결성 체크된 모든 기능성의 리스트 (선택사항) 이 리스트는 TLV 포맷이고 체크된 모든 기능성의 리스트를 포함하며, 이것에 의해 장치에서 수행된 무결성 체크의 정도/범위를 표시한다. 이 리스트는 무결성 체크의 정도/범위가 먼저 검증자(예를 들면, PVE)에게 알려져있지 않은 경우에만 전송된다.

(대안예) 대안적으로 및 선택사항으로, 무결성 체크가 이루어지지 않은 기능성의 리스트는 체크가 이루어진 기능성의 리스트 대신에 또한 보내질 수 있다. 이러한 대안 리스트는 만일 체크되지 않은 기능성의 리스트가 체크된 기능성의 리스트보다 더 짧으면 크기가 더 작을 수 있다. 이 메서드는 체크될 수 있는 모든 기능성의 완전한 리스트가 이미 검증자에게 알려져 있는 경우에만 작용한다.
실패한 기능성의 리스트 이 리스트는 TLV 포맷이고 실패한 기능성의 리스트를 포함한다. 리스트는 만일 H(e)NB가 기능성의 실패가 없음을 보고하는 경우 비워질 수 있다. 리포트는 신뢰된 무결성 검증 코드에 의해 발생되고, 안전한 시동 처리에 의해 믿을 수 있는 것임에 주목한다.
넌스(nonce)/메시지 시퀀스 번호 넌스 또는 메시지 시퀀스 번호는 요구 및 응답을 관련시키기 위한 것이다.
H(e)NB_무결성_정보 메시지에 대한 응답은 표 8에 나타낸 H(e)NB_확인_결과이다.
정보 요소 설명
H(e)NB ID H(e)NB 또는 TrE ID의 유일한 식별자를 포함한다.
넌스/메시지 시퀀스 번호 넌스는 요구와 응답을 관련시키기 위해 H(e)NB_무결성_정보로 제공된다.
SeGW 동작 SeGW의 동작은 하기의 것을 수행할 수 있다:
1. 완전한 액세스 허용
2. H(e)MS에 대해서만 액세스 허용
3. 격리
4. 액세스 불허용
H(e)NB 동작 이 동작은 IKEv2 통지 메시지로 H(e)NB에 전송된다. H(e)NB 동작은 하기의 것일 수 있다:
1. 풀 액세스 허용(필요한 업데이트 없음, 발생된 에러 없음)
2. 풀 액세스 허용(업데이트 계획됨, 가혹성 4 에러 발생)
3. 부분 액세스 허용(업데이트 계획됨, 가혹성 2 에러 발생)
4. H(e)MS에만 액세스(즉시 교정을 위해 준비, 가혹성 3 에러 발생)
5. 폐쇄(국소 에러 코드 디스플레이 폐쇄, 관리자는 개인적으로 시스템을 가혹성 1 에러로 고정한다)
PVE-H(e)MS 인터페이스는 이들이 둘 다 네트워크 엔티티이기 때문에 PPP에 기초할 수 있다. 대안적으로, TLS/SSL이 또한 사용될 수 있다. 일 예로서, PVE와 H(e)MS는 하나의 엔티티일 수 있다. 이 인터페이스를 통한 예시적인 메시지는 표 9에 나타내었다.
정보 요소 설명
H(e)NB ID H(e)NB 또는 TrE ID의 유일한 식별자를 포함한다.
(선택사항) 무결성 체크된 모든 기능성의 리스트 (선택사항) 이 리스트는 TLV 포맷이고 체크된 모든 기능성의 리스트를 포함하며, 이것에 의해 장치에서 수행된 무결성 체크의 정도/범위를 표시한다. 이 리스트는 무결성 체크의 정도/범위가 먼저 검증자(예를 들면, PVE)에게 알려져있지 않은 경우에만 전송된다.

(대안예) 대안적으로 및 선택사항으로, 무결성 체크가 이루어지지 않은 기능성의 리스트는 체크가 이루어진 기능성의 리스트 대신에 또한 보내질 수 있다. 이러한 대안 리스트는 만일 체크되지 않은 기능성의 리스트가 체크된 기능성의 리스트보다 더 짧으면 크기가 더 작을 수 있다. 이 메서드는 체크될 수 있는 모든 기능성의 전체 리스트가 이미 검증자에게 알려져 있는 경우에만 작용한다.
실패한 기능성의 리스트 이 리스트는 TLV 포맷이고 실패한 기능성의 리스트를 포함한다. 기능성 ID가 여기에서 설명된다. 만일 리스트가 널(NULL)이면 이것은 H(e)NB가 모든 무결성 체크를 통과하였음을 표시할 수 있다.
H(e)MS 동작 표시 이것은 장치 무결성 확인이 수행되었고 그 결과 H(e)MS가 일부 동작을 수행할 수 있음을 H(e)MS에 표시한다. 하기의 동작이 수행될 수 있다.
1. 즉시 교정
2. 계획 교정
3. 관리자 개입이 필요함
대안적으로, PVE는 실패한 기능성의 리스트(또는 선택사항으로 무결성 체크된 모든 기능성의 리스트 또는 무결성이 체크되지 않은 모든 기능성의 리스트도 함께)를 보낼 수 있고 H(e)MS는 동작 자체에서 결정한다. 이것은 표 10에 나타내었다. 하기의 동작이 H(e)MS에 의해 수행될 수 있다: 즉시 교정, 계획 교정, 및 관리자 개입이 필요함.
정보 요소 설명
H(e)NB ID H(e)NB 또는 TrE ID의 유일한 식별자를 또한 포함한다.
(선택사항) 무결성 체크된 모든 기능성의 리스트 (선택사항) 이 리스트는 TLV 포맷이고 체크된 모든 기능성의 리스트를 포함하며, 이것에 의해 장치에서 수행된 무결성 체크의 정도/범위를 표시한다. 이 리스트는 무결성 체크의 정도/범위가 먼저 검증자(예를 들면, PVE)에게 알려져있지 않은 경우에만 전송된다.

(대안예) 대안적으로 및 선택사항으로, 무결성 체크가 이루어지지 않은 기능성의 리스트는 체크가 이루어진 기능성의 리스트 대신에 또한 보내질 수 있다. 이러한 대안 리스트는 만일 체크되지 않은 기능성의 리스트가 체크된 기능성의 리스트보다 더 짧으면 크기가 더 작을 수 있다. 이 메서드는 체크될 수 있는 모든 기능성의 전체 리스트가 이미 검증자에게 알려져 있는 경우에만 작용한다.
실패한 기능성의 리스트 이 리스트는 TLV 포맷이고 실패한 기능성의 리스트를 포함한다. 기능성 ID가 위의 섹션에서 설명된다. 만일 리스트가 널(NULL)이면 이것은 H(e)NB가 모든 무결성 체크를 통과하였음을 표시할 수 있다.
여기에서는 H(e)NB 아키텍쳐 및 SAV에 관한 기능성이 개시된다. H(e)NB 아키텍쳐는 외부 TrE 무결성 체커를 포함할 수 있다. H(e)NB의 TrE는 무결성 검증 작업이 TrE의 책임이었던 컴포넌트의 무결성 검증 작업을 하드웨어 및/또는 소프트웨어로 구현될 수 있는 외부 엔티티에 위임할 수 있다. 이러한 케이스는 TrE가 충분히 빠르지 않은 경우 또는 TrE가 장치 무결성 체크를 수행하기 위한 충분한 리소스를 갖지 않은 경우에 사용될 수 있다. 그 경우에, TrE는 장치 무결성 확인의 작업을 떠맡은 하드웨어 및/또는 소프트웨어 엔티티의 무결성 및 진정성을 검증한다. 성공적인 검증 후에, TrE는 외부 무결성 체커가 작업을 수행하게 하고 그 결과 및 측정 데이터를 TrE에 보고하게 한다.
H(e)NB 엔티티는 각종 이벤트, 리포트 및 네트워크와의 통신에 대한 타임스탬프를 제공하기 위한 로컬 타임 서버를 가질 수 있다. 이러한 타임 서버는 시간을 동기화하기 위해 네트워크 타임 프로토콜(NTP)을 사용할 수 있다. 타임 서버 코드 및 NTP 코드는 이들이 TrE 또는 외부 TrE 무결성 체커에 의해 실행되기 전에 무결성이 또한 검증될 수 있다.
H(e)NB 아키텍쳐는 확인 및 인증의 결합(binding)을 또한 제공할 수 있다. 확인과 인증 간의 결합은 AuV의 경우에 확인과 인증의 결합을 위해 사용된 메카니즘 외에 IKEv2 세션에 의해 제공될 수 있다. 즉, 감응 키 및 인증 기능성은 무결성 체크를 통과한 때에만 해제된다. 인증서 및 SAV에서 국소 확인의 결과는 IKEv2 IKE_AUTH_REQ 메시지로 보내질 수 있다. SeGW는 실패한 모듈의 리스트를 걸러내고 이것을 PVE에 전송한다. 그러한 리스트가 메시지에 포함되어 있지 않으면 리스트는 이 정보를 PVE에 중계한다. PVE는 추가의 동작을 결정하고 그 결과를 SeGW에 및 일부 경우에는 H(e)MS에 표시한다.
대안적인 결합 방법에 있어서, H(e)NB는 키 쌍이 미리 설비되고, 그 중에서 개인 부분(private part)은 H(e)NB의 TrE의 내측에 안전하게 저장되고 공개 부분(public part)은 H(e)NB에 이용가능하게 된다. H(e)NB의 제조자는 이러한 키 쌍을 발생하고 그에 따라서 개인키와 공개키를 공급할 수 있다. 암호화 수단에 의해 확인과 인증의 결합을 생성하기 위해, H(e)NB는 AAA 서버(AAA 서버는 비밀 기반으로 연산된 인증 자료를 연산하여 AAA 서버에 되돌려 보내도록 H(e)NB에 요청한다)로부터 수신한 메시지(예를 들면, IKE_AUTH 응답 메시지)를 인증서로부터의 공개키로 암호화하고, 암호화 데이터를 TrE에 전송한다. 그 다음에, TrE는 데이터를 복호하고 H(e)NB 신원의 인증을 AAA에 입증하기 위해 필요한 비밀 기반 인증 자료(예를 들면, 대칭 인증이 사용되는 경우 EAP-AKA RES 파라미터, 또는 인증서 기반 인증이 사용되는 경우 개인키의 사용에 기반한 AUTH 파라미터 등)를 연산한다.
대안적인 결합 방법에 있어서, H(e)NB의 IKEv2 기반 장치 인증 애플리케이션에 의해 사용되는 TrE의 키 및 다른 감응성 연산 능력은 성공적인 국소 무결성 체크 결과가 H(e)NB의 TrE에 알려지지 않는 한 상기 애플리케이션에 액세스할 수 없다.
여기에서는 H(e)NB 및 PVE에 저장된 폴리시(policy) 명세서가 개시된다. H(e)NB 장치 구성 파일은 여기에서 상세하게 설명한 기능성 ID, 컴포넌트 ID 및 모듈 ID와 같은 속성들을 묘사하는 H(e)NB에 저장된 폴리시를 설명한다. 장치 구성 시트는 제조시에 초기화된다. 이 정보의 초기화 절차 및 AuV의 후속 업데이트는 여기에서 설명되었고 SAV의 경우에 적용할 수 있다.
PVE 폴리시 구성 파일은 실패한 기능성과 SeGW 동작 간의 맵핑, H(e)NB 동작 및 H(e)MS 동작을 포함할 수 있다. 실패한 기능성 리스트에 기초하여, PVE는 H(e)NB, SeGW 및 H(e)MS에 의해 취해지는 동작들을 결정할 수 있다. 표 11은 그 동작들을 규정한 것이다.
실패 기능성 설명 H(e)NB 동작 SeGW 동작 H(e)MS 동작
보안 부트 로더 폐쇄(shut down) 격리(quarantine) 관리자 개입
TrE 폐쇄 격리 관리자 개입
무결성 확인 엔진 폐쇄 격리 관리자 개입
폴백 코드 폐쇄 격리 관리자 개입
운영체제 폐쇄 격리 관리자 개입
H(e)MS 서브시스템 부분 액세스 허용 완전한 액세스 허용 계획 교정
Uu 인터페이스 부분 액세스 허용 완전한 액세스 허용 계획 교정
Iuh 인터페이스 부분 액세스 허용 완전한 액세스 허용 계획 교정
HGm 인터페이스 부분 액세스 허용 완전한 액세스 허용 계획 교정
HUt 인터페이스 부분 액세스 허용 완전한 액세스 허용 계획 교정
S1-MME 인터페이스 부분 액세스 허용 완전한 액세스 허용 계획 교정
S1-U 인터페이스 부분 액세스 허용 완전한 액세스 허용 계획 교정
I2(SIP) 인터페이스 부분 액세스 허용 완전한 액세스 허용 계획 교정
Iu-CS 인터페이스 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
Iu-PS 인터페이스 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
E, Nc, Nb 인터페이스 부분 액세스 허용 완전한 액세스 허용 계획 교정
RUA 서비스 부분 액세스 허용 완전한 액세스 허용 계획 교정
HNBAP 서비스 부분 액세스 허용 완전한 액세스 허용 계획 교정
HNB GW 디스커버리 부분 액세스 허용 완전한 액세스 허용 계획 교정
HNB 등록 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
HNB의 WTRU 등록 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
액세스 제어 관리 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
시간 관리 풀 액세스 허용 완전한 액세스 허용 계획 교정
CSG 관리 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
이동성 관리 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
NAS 노드 선택 기능 부분 액세스 허용 완전한 액세스 허용 계획 교정
페이징 최적화 풀 액세스 허용 완전한 액세스 허용 계획 교정
운송 어드레스 맵핑 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
챠징 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
긴급 서비스 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
QoS 관리 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
로컬 IP 액세스 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
관리된 원격 액세스 풀 액세스 허용 완전한 액세스 허용 계획 교정
레가시 CN의 HNB 지원 풀 액세스 허용 완전한 액세스 허용 계획 교정
인바운드 핸드오버 지원 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
로밍 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
MSC SGSN에 공통인 SCCP 무접속 부분 액세스 허용 완전한 액세스 허용 계획 교정
OAM 서브시스템 부분 액세스 허용 완전한 액세스 허용 계획 교정
디스플레이 서브시스템 풀 액세스 허용 완전한 액세스 허용 계획 교정
USIM 서브시스템 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
HPM 서브시스템 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
IMS 인터워킹 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
IP-PABX 인터페이스
보안 기능 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
RAB 관리 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
라디오 리소스 관리 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
Iu 링크 관리 H(e)MS에만 액세스 H(e)MS에만 액세스 즉시 교정
Iu U-평면(RNL) 관리 부분 액세스 허용 완전한 액세스 허용 계획 교정
Iu-조정 기능 부분 액세스 허용 완전한 액세스 허용 계획 교정
공급 기능 풀 액세스 허영 완전한 액세스 허용 계획 교정
하드웨어 실패 폐쇄 격리 관리자 개입
여기에서는 SAV에서 교정을 지원하는 방법이 개시된다. 교정을 지원하기 위해, H(e)NB는 H(e)MS와 상호작용한다. 이 접속은 SeGW를 통할 수도 있고 TLS/SSL을 이용하여 인터넷을 통해 직접 이루어질 수도 있다. 만일 보안 시동 처리중에, 제조자에 의해 미리 지정되고 TrE용의 코드와 함께 인증 및 SeGW와의 통신을 위해 필요한 코드를 포함하는 스테이지 1 또는 스테이지 2 코드에 대하여 장치 무결성 체크가 실패하면, FBC가 실행되고 교정이 시도된다.
도 14는 H(e)NB(1405), H(e)MS(1410) 및 FTP 서버(1415)를 수반하는 SAV 교정을 위한 예시적인 흐름도(1400)를 도시한 것이다. 만일 장치 무결성 체크가 실패하면, RoT가 FBC를 이용하여 부팅된 후에(0), H(e)NB(1405)는 미리 지정된 H(e)MS 서버(1410)에 대한 접속을 형성한다(예를 들면, TCP 접속을 이용해서)(1). 그 다음에 SSL 개시가 수행되고 및/또는 TLS가 형성된다(2). 그 다음에, H(e)NB(1405)는 H(e)MS(1410)와 함께 RPC 메서드 통보(예를 들면, 재난 신호)를 호출한다. 재난 신호는 장치 ID, 이벤트, 최대 엔벨로프 및 현재 시간을 포함할 수 있다.
장치 ID는 제조자명; 장치 제조자의 조직적으로 유일한 식별자(OUI); 일련 번호가 적용되는 제품의 등급을 표시하기 위해 사용되고 또는 일련 번호 속성을 이용하여 TrE ID 또는 H(e)NB ID를 표시하기 위해 장치의 일련 번호를 표시하도록 사용될 수 있는 제품 등급(ProductClass); 및 특수 장치의 일련 번호를 보내기 위해 사용될 수 있고 또는 TrE ID 또는 H(e)NB ID를 보내기 위해 사용될 수 있는 일련 번호 필드를 포함한 구조이다.
이벤트 필드는 RPC 메서드 통보가 실행되게 하는 이벤트 코드를 포함할 수 있다. TR069를 SAV 교정에 적응시키기 위해, 새로운 이벤트 코드(X_HeNB_FBC 호출)는 장치 무결성 체크가 실패하였고 FBC가 재난 신호를 보내도록 호출되었다는 것을 표시하도록 규정될 필요가 있다. 최대 엔벨로프 값은 1로 설정된다. 이 값은 무시될 수 있지만 1로 설정된다. 현재 시간 필드는 H(e)NB(1405)에 알려진 현재 날짜 및 시간의 값으로 설정된다.
통보 RPC 메서드는 장치가 무결성 체크를 실패하였고 펌웨어 업데이트를 개시하기 위해 접속되었음을 H(e)MS에 표시한다. H(e)MS는 그 다음에 실패한 기능성의 리스트 및 에러 코드의 제조자 특정 리스트를 업로드하도록 H(e)NB에 표시하기 위해 RPC 메서드 업로드를 호출한다(4). 이 에러 코드는 무결성 체크를 실패한 컴포넌트에 대응하는 소프트웨어 모듈을 인용할 수 있고 또는 디버그 특정 에러 코드를 포함할 수 있다. 파일이 업로드되어야 하는 FTP 서버(1415)의 URL이 제공된다. FTP 서버(1415)는 제조자에 의해 유지될 수 있다는 점에 주목한다. FTP 서버(1415)는 제조자에 의해 제공된 교정 서버일 수 있다.
H(e)MS(1410)는 업로드 준비(Prepare_For_Upload) 메시지를 전송함으로써 실패 기능성 리스트의 업로드를 준비하도록 FTP 서버(1415)에 표시한다. 그 다음에 H(e)NB(1405)는 실패 기능성 리스트를 포함하는 파일을 업로드하기 위해 HTTP/HTTPS/FTPS 절차를 호출한다(6). 파일을 수신한 후, FTP 서버(1415) 또는 H(e)MS(1410)는 H(e)MS가 업로드된 파일을 수집한 때 문제를 고정하기 위한 필요한 패치 또는 펌웨어/소프트웨어 업데이트를 평가한다(6a). 만일 실패 기능성 리스트를 포함한 파일이 FTP 서버(1415)에 업로드되면, 필요한 패치의 평가 후에, FTP 서버(1415)는 다운로드_패키지_준비 메시지를 H(e)MS에 보낸다(7). 만일 H(e)MS가 업로드된 파일을 수집하였으면, 이 메시지는 필요없다. 대안적으로, 이 메시지는 H(e)MS(1410) 및 FTP 서버(1415)의 기능성이 합체된 경우에도 또한 필요없다.
대안적으로, 정보는 PVE로부터 직접 수신될 수 있고 단계 1 내지 단계 5는 필요없을 수 있다.
H(e)MS(1415)는 그 다음에 RPC 메서드 다운로드를 호출하고 펌웨어 또는 소프트웨어의 위치의 URL 및 장치 구성 데이터 시트를 제공한다(8). 하기의 파라미터 값들이 설정될 수 있다. 커맨드키 파라미터는 특수한 다운로드를 인용하기 위해 H(e)NB(1405)에 의해 사용될 수 있는 문자열 및 임의의 문자열일 수 있다. 이 파라미터는 다운로드와 응답을 상관시키기 위해 사용될 수 있다. 파일유형(FileType) 파라미터는 펌웨어 이미지에 대하여 "1 펌웨어 업그레이드 이미지"로 및 장치 구성 데이터 시트에 대하여 "X_<OUI>_데이터_시트"로 설정될 수 있다. URL 파라미터는 다운로드 파일의 URL이다. HTTP 및 HTTPS는 지원되어야 한다. FTPS의 지원은 다운로드를 위해 또한 권장된다. 사용자명 파라미터는 FTP 서버(1415)에 인증하기 위해 H(e)NB(1405)에 의해 사용될 수 있다. 패스워드 파라미터는 FTP 서버(1415)에 인증하기 위해 H(e)NB(1405)에 의해 사용될 수 있다. 파일크기 파라미터는 다운로드되는 파일의 크기이다. 기타의 파라미터들은 TR069 프로토콜 필요조건에 따라서 설정될 수 있다.
H(e)NB(1405)는 FTP 서버(1415)에 접속되고 펌웨어 또는 소프트웨어 이미지 및 장치 구성 데이터 시트를 다운로드한다(9). 다운로드를 성공적으로 완료한 때, 제로 값을 가진 상태 아규멘트에 의한 다운로드 응답(성공을 표시함) 또는 다운로드 요청에 대한 오류 응답(실패를 표시함)이 보내질 수 있다(10). 여기에서 설명하는 대안적인 절차가 다운로드의 성공 또는 실패를 표시하기 위해 또한 이어질 수 있다.
성공적 다운로드 응답 후에, H(e)MS(1415)는 H(e)NB(1405)에서 리부트 절차를 호출한다(11). H(e)NB(1405)에서의 RPC 핸들러는 국소 재난 플래그를 리세트하고 위에서 표시한 것처럼 국소 무결성 체크 절차를 수행하도록 정상적으로 부팅된다(11a). 서명된 패키지 포맷은 펌웨어 또는 소프트웨어가 업데이트된 후 H(e)NB(1405)의 리부트를 지시하기 위해 사용되는 리부트 명령을 포함할 수 있다.
선택적으로, 전송 종료 RPC 메서드는 펌웨어/소프트웨어 업데이트의 절차가 성공적으로 완료되었음을 H(e)MS에 표시하기 위해 H(e)NB로부터 호출될 수 있다(12). 대안적으로, SeGW는 장치가 성공적으로 부팅되었음을 표시하기 위한 메시지를 H(e)MS에 보낼 수 있고, 이것은 H(e)MS에 의해 성공적인 펌웨어 또는 소프트웨어 업데이트 완료 메시지로서 해석될 수 있다는 점에 주목한다.
도 15는 PVE에 의한 SAV 교정의 실시예의 흐름도(1500)를 보인 것이다. 이 절차는 H(e)NB(1505), SeGW(1510), PVE(1515), H(e)MS(1520) 및 FTP 서버(1525)를 수반한다. 보안 시동 처리중에, 만일 스테이지 1 코드 및 스테이지 2 코드가 무결성 체크를 통과하고 로드 및 실행되며 인증이 성공적으로 수행되면, H(e)NB(1505)는 SeGW(1510)와 통신하여 국소 무결성 체크의 결과를 IKEv2 메시지로 전송한다(1). H(e)NB(1505)는 실패 기능성의 리스트 및 제조자 지정 에러 코드의 리스트를 도 16에 도시한 IKEv2 통지 메시지(1600)로 SeGW(1510)에 전송한다.
그 다음에, SeGW(1510)는 국소 무결성 체크의 결과를 실패 기능성 리스트 및/또는 에러 코드의 제조자 지정 리스트를 포함하는 H(e)NB_무결성_정보 메시지로 전송할 수 있다(2). 수신된 정보에 기초해서, PVE(1515)는 SeGW 동작 및 H(e)NB 동작을 포함하는 H(e)NB_확인_결과 메시지로 SeGW(1510)에 응답할 수 있다(3). SeGW(1510)는 H(e)NB 동작을 H(e)NB(1505)에 회송할 수 있다(5). H(e)NB는 그에 따라서 준비하고 국부적으로 교정을 준비하거나 아무런 동작도 취하지 않을 수 있다.
수신된 정보에 기초해서, PVE는 실패 기능성의 리스트, 에러 코드의 제조자 지정 리스트, H(e)MS 동작 및 H(e)NB ID를 포함하는 H(e)NB_확인_결과 메시지를 H(e)MS(1520)에 또한 전송할 수 있다(4). PVE(1515)에 의해 H(e)MS(1520)에 전송된 동작에 기초해서, H(e)MS(1520)는 교정 업데이트 또는 즉시 업데이트를 계획할 수 있다. 상기 2개의 경우에, H(e)MS(1520)는 리스트를 제조자 지정 교정 FTP 서버에 전송한다.
H(e)MS(1520)는 실패 기능성의 리스트, H(e)NB ID 및 에러 코드의 제조자 지정 리스트를 포함하는 H(e)NB_확인_결과 메시지를 FTP 서버(1525)에 전송할 수 있다(4a). FTP 서버(1525)는 펌웨어/소프트웨어 다운로드 파일을 평가하고 다운로드 패키지를 준비한다(4b). FTP 서버(1525)는 다운로드_패키지_준비 메시지를 H(e)MS(1520)에 보낸다. 만일 H(e)MS(1520)가 업로드 파일을 수집하면 이 메시지는 필요없을 수 있다. 대안적으로, 메시지는 H(e)MS(1520) 및 FTP 서버(1525)가 합체된 경우에 전송되지 않을 수 있다.
그 다음에 H(e)MS(1520)는 RPC 메서드 다운로드를 호출하고 펌웨어/소프트웨어의 위치의 URL 및 장치 구성 데이터 시트를 제공한다(7). 하기의 파라미터 값들이 설정될 수 있다. 커맨드키 파라미터는 특수한 다운로드를 인용하기 위해 H(e)NB(1505)에 의해 사용될 수 있는 문자열이고 다운로드와 응답을 상관시키기 위해 사용될 수 있는 임의의 문자열일 수 있다. 파일 유형 파라미터는 펌웨어/소프트웨어 이미지에 대하여 "1 펌웨어 업그레이드 이미지"로, 및 장치 구성 데이터 시트에 대하여 "X_<OUI>_데이터_시트"로 설정될 수 있다. URL은 다운로드 파일의 URL이다. HTTP 및 HTTPS는 지원되어야 한다. FTPS의 지원은 다운로드를 위해 또한 권장된다. 사용자명 파라미터는 파일 서버에 인증하기 위해 H(e)NB(1505)에 의해 사용될 수 있다. 패스워드 파라미터는 파일 서버에 인증하기 위해 H(e)NB(1505)에 의해 사용될 수 있다. 파일크기 파라미터는 다운로드되는 파일의 크기이다. 기타의 파라미터들은 TR069 프로토콜 필요조건에 따라서 설정될 수 있다.
H(e)NB(1505)는 FTP 서버(1515)에 접속되고 펌웨어/소프트웨어 이미지 및 장치 구성 데이터 시트를 다운로드한다(8). 다운로드를 성공적으로 완료한 때, 제로 값을 가진 상태 아규멘트에 의한 다운로드 응답(성공을 표시함) 또는 다운로드 요청에 대한 오류 응답(실패를 표시함)이 H(e)MS(1520)에 보내진다(9). TR069에서 설명된 대안적인 절차가 다운로드의 성공 또는 실패를 표시하기 위해 또한 이어질 수 있다.
성공적 다운로드 응답 후에, H(e)MS(1515)는 H(e)NB(1505)에서 리부트 절차를 호출한다(10). H(e)NB(1505)에서의 RPC 핸들러는 국소 재난 플래그를 리세트하고 위에서 표시한 것처럼 국소 무결성 체크 절차를 수행하도록 정상적으로 부팅된다(10a). 대안적으로, 서명된 패키지 포맷은 펌웨어/소프트웨어가 업데이트된 후 H(e)NB(1505)의 리부트를 지시하기 위해 사용되는 리부트 명령을 포함한다. 전송 종료는 펌웨어/소프트웨어 업데이트가 성공적으로 완료된 후 SeGW(1510)에 보내질 수 있다(11). 대안적으로, 전송 종료 RPC 메서드는 펌웨어/소프트웨어 업데이트의 절차가 성공적으로 완료되었음을 H(e)MS(1520)에 표시하기 위해 H(e)NB(1505)로부터 호출될 수 있다. 다른 예로서, SeGW(1510)는 장치가 성공적으로 부팅되었음을 표시하기 위한 메시지를 H(e)MS(1520)에 보낼 수 있고, 이것은 H(e)MS(1520)에 의해 성공적인 펌웨어/소프트웨어 업데이트 종료 메시지로서 해석될 수 있다.
여기에서는 플랫폼 확인 및 관리(PVM) 아키텍쳐에서 SAV를 이용하는 구조 및 방법이 개시된다. PVM은 확인 및 관리 장치가 신뢰된 연산으로부터의 보안 기술에 부분적으로 의존해서 통신 네트워크에 대한 부착을 최초로 시도하고 장치 무결성을 후속적으로 모니터링할 때 확인 및 관리 장치에 체계적인 메서드를 제공한다. PVM은 1) 네트워크 접속이 허용되기 전에 장치의 확인; 2) 장치 구성 오버-더-에어(over-the-air; OtA) 관리; 3) 컴포넌트 로드/시작시에 RIM 체크에 의한 보안 시동; 및 4) 구성 변화-RIM 흡수(ingestion)를 위해 장치에의 새로운 RIM의 설치를 제공한다.
PVM은 하기의 용어를 사용할 수 있다. 용어 "검증"은 보안 시동 중에 장치 컴포넌트의 내부 검증에 대해 사용될 수 있고, 용어 "확인"은 외부 엔티티에 의한 장치의 전반적인 체크 처리에 대해 사용될 수 있다. 따라서, "내부" 대 "외부" 확인의 소개는 회피된다. 검증이 일반적인 감각의 암호화 체크 또는 데이터의 매칭에 적용될 때, 이것은 명시적으로 표시되므로 혼란이 발생되지 않는다.
PVM은 적어도 SeGW, PVE 및 DMS를 이용한다. 장치의 TrE는 장치 내에서 확인 임계 작업을 수행하므로, 일반적으로 TrE는 다른 엔티티와 통신한다. 장치의 다른 컴포넌트, 예를 들면 이 통신을 위해 필요로 하는 네트워크 인터페이스가 반드시 TrE의 통합 부품일 필요는 없지만, TrE가 종단 대 종단 보안(end-to-end security)을 보장하기 위해 상기 컴포넌트의 무결성에 액세스할 수 있어야 한다.
임무(duty)의 엄격한 분리는 각 엔티티가 그 핵심 작업으로 제한되는 것을 필요로 한다. 예를 들면, SeGW는 (비)신뢰된 장치와 MNO의 CN 간에 보안 인터페이스를 구축한다. 보안 인터페이스는 장벽으로서 작용하고, 네트워크 액세스 제어 및 강화는 MNO CN의 실례이다. 보안 인터페이스는 또한 인증, 장치와의 통신의 암호화/복호, 보안 연합 및 세션 확립을 비롯해서 장벽으로서 작용하는데 필요한 모든 보안 관련 기능을 수행한다. SeGW는 외부 장치와 같은 외부 세계와 MNO CN 간에 경계를 구축하는 네트워크 엔티티의 예로서 사용될 수 있다. SeGW의 필요없이 PVM 메서드를 이용하여 장치 확인을 수행할 수 있다. 이렇게 하는 것은 운송 층 보안(TLS)과 같은 보안 접속을 이용하여 장치를 DMS에 직접 접속하는 것을 포함할 수 있다.
PVE와 관련하여, PVE는 CN에서 확인 엔티티로서 작용하고 무결성 확인을 수행한다. PVE는 무결성 검증 데이터를 수신하고 보고된 값들이 공지되어 있고 양호한 것인지를 체크한다. PVE는 장치 무결성에 대한 설명문(statement)을 CN의 다른 엔티티에 발행한다.
DMS와 관련하여, 이것은 소프트웨어 업데이트, 구성 변경, OTA 관리 및 실패 모드 교정을 포함한 장치 컴포넌트의 관리를 위한 중심 엔티티로서 작용한다. DMS는 플랫폼 확인에 기초하여 이 기능을 취함에 있어서 H(e)MS의 향상된 버전과 유사하다.
상기 엔티티 외에, PVM은 RIM 관리자(RIMman)를 또한 포함한다. RIM 관리자는 확인에 있어서 비교를 위한 참고 값의 관리 및 공급을 포함한 하기의 작업을 수행한다. RIM 관리자는 인증서 관리, 특히 대외(foreign) RIM 인증서의 흡수, RIM 인증서의 검증, (운용자 특정) RIM 인증서의 생성, 및 예를 들면 철회(revocation), 시간 제한 및 신뢰 관계에 의한 인증서 유효성 체크 등의 인증서 관리를 또한 수행한다. 즉, RIM 관리자는 확인 데이터베이스(V_DB)를 관리하도록 허가되는 유일한 엔티티이다. V_DB 및 RIMman은 보호된 CN 컴포넌트이다. V_DB에 대한 기록 액세스는 RIMman으로만 제한되므로 PVE는 V_DB에 기록할 수 없다. RIMman은 PVM에 필요한 (SHO-CN) 외부 신뢰 관계를 관리하기 때문에 보안성과 관련하여 특수한 중요성을 갖는다.
PVM은 장치 구성의 관리 및 공급을 수행하는 구성 폴리시 관리자(CPman)를 또한 포함한다. PVM은 폴리시 관리, 특히 예를 들면 신뢰된 제3자(TTP)로부터의 대외적 구성 및 폴리시의 흡수, 및 (운용자 특정) 목표 장치 구성 및 폴리시의 생성 등의 관리를 또한 수행한다. 즉, CPman은 구성 폴리시 데이터베이스(C_DB)를 관리하도록 허가되는 유일한 엔티티이다. CPman은 PVM에 필요한 (SHO-CN) 외부 신뢰 관계를 관리하기 때문에 보안성과 관련하여 특수한 중요성을 갖는다.
도 17A 및 17B는 엔티티의 최소 집합, 그들의 PVM에 대한 관계 및 인터페이스의 예를 보인 것이다. 추가적인 엔티티, 예를 들면 인증, 권한부여 및 어카운팅(AAA) 서버와 무선 송수신 유닛(WTRU) 및 그들의 인터페이스가 도시되어 있다.
도 17A의 PVM 아키텍쳐 또는 시스템(1700)은 TrE(1710)를 구비한 장치(1705)를 포함한다. WTRU(1712)(또는 사용자 엔티티(UE))는 I-ue 인터페이스(1714)를 통해 장치(1705)와 통신할 수 있다. 장치(1705)는 I-h 인터페이스(1715)를 통해 SeGW(1720)와 통신한다. 일반적으로, 장치(1705)와 SeGW(1720) 사이의 인터페이스 I-h(1715)는 보호되지 않고 진정성, 무결성 및 선택적으로 신뢰성에 대해 이 채널을 보호하기 위해 특수한 방책이 적용될 수 있다. I-h(1715)는 장치(1705)와 SeGW(1720) 및 그에 따라서 CN 사이에 링크를 확립하기 위해 사용될 수 있다. 예를 들면, SeGW(1720)는 인터페이스 I-aaa(1775)를 통해 AAA 서버와 통신할 수 있다. 운용자는 인터페이스의 보안성을 보장하는 적당한 방책을 확립할 수 있다.
I-pve 인터페이스(1722)는 확인중에 PVE(1724)와 접촉하기 위해 SeGW(1720)에 의해 사용될 수 있다. PVE(1724)는 I-pve 인터페이스(1722)를 이용하여 확인의 결과물을 SeGW(1720)에 신호할 수 있다. I-dms 인터페이스(1730)는 DMS(1735)와 SeGW(1720) 사이에 장치 구성 관련 통신을 위해 사용될 수 있다. I-pd 인터페이스(1732)는 DMS(1735)와 통신하기 위해 PVE(1724)에 의해서 및 PVE(1724)와 통신하기 위해 DMS(1735)에 의해서 사용될 수 있다. 이 인터페이스, 즉 I-pd(1732)는 장치 소프트웨어 업데이트 및 구성 변경과 같은 장치 관리 절차 중에 사용될 수 있다.
인터페이스 I-v(1726)와 I-d(1738)는 PVE(1720)가 V_DB(1740)로부터 RIM을 판독하기 위해서 및 DMS(1735)가 C_DB(1750)로부터 허가 구성을 판독하기 위해서 각각 사용할 수 있다. 인터페이스 I-r(1728)과 I-c(1734)는 PVE(1720)가 V_DB(1740)에 RIM이 없는 경우에 RIMman(1760)과 통신하기 위해서 및 DMS(1735)가 CPman(1770)과 통신하기 위해서 사용할 수 있다. RIMman(1760)과 CPman(1770)은 각각 인터페이스 I-rdb(1762) 및 I-cdb(1772)를 이용하여 데이터베이스 V_DB(1740) 및 구성 폴리시 데이터베이스 C_DB(1750)의 확인을 판독, 기록 및 관리할 수 있다.
도 17B는 장치(1705)가 DMS(1735)에 직접 접속하는 경우의 PVM(1782)을 도시한 것이다. 장치가 H(e)NB인 경우, DMS(1735)는 위에서 설명한 것처럼 H(e)MS일 것이다. 예를 들면, 폴백 모드의 경우, 장치(1705)는 SeGW와 함께 보안 프로토콜을 수행할 수 없다. 이 경우, DMS(1735)는 장치(1705)에 대하여 인터페이스 I-dms_d(1784)를 통한 최초 접촉점으로서 작용하고, 인터페이스 I-pve(1786) 및 I-pd(1788)를 통해 PVE(1724)와 통신하여 확인을 수행하거나 또는 적어도 어떤 컴포넌트가 보안 시동 중에 실패하였는지를 알아낼 것이다. DMS(1735)는 이 교정 정보에 대하여 작용할 수 있다.
여기에서 설명한 것처럼, PVM은 임의의 확인 버전을 사용할 수 있다. 여기에서는 PVM과 함께 동작하는 반자율적 확인(SAV)의 실시예가 개시된다. SAV에 대한 이러한 솔루션의 장점은 CN이 부정 장치(rogue device)로부터 완전하게 보호된다는 것이다. SAV 중에, SeGW에 의해 격리가 효과적으로 확립된다. PVE와 DMS는 그들의 타스크로 제한된 데이터만을 SeGW와의 보안 접속을 통해서, 또는 SeGW에 의해 확립된 접속을 통해서만 수신하기 때문에 장치로부터 PVE 및 DMS에 직접적인 위협이 주어지지는 않는다. SAV에서의 확인 처리는 CN 내의 임의의 엔티티와 장치들 간의 직접 통신을 요구하지 않는다. SAV를 이용한 성공적인 확인 후에만 CN에 대한 접속이 허용된다. 이것은 보안 상태가 검증된 장치만이 CN 내의 엔티티와 통신할 수 있도록 보장한다.
도 18A, 18B 및 18C는 PVM 하부구조에 의한 SAV 확인 방법의 예를 보인 도이다. PVM 하부구조는 TrE(1805), SeGW(1807), PVE(1809), DMS(1811), V_DB(1813) 및 C_DB(1815)를 비롯하여 여기에서 설명한 엔티티를 포함한다. 상호 인증(1820) 다음에, TrE(1805)는 하기의 데이터, 즉 Dev_ID, 제조자, 비제한적인 예를 들자면 지원되는 데이터 전송률과 송신 전력 레벨과 시그널링 특징과 같은 통신 능력 및 기타 능력, TrE 능력 및 RoT를 포함한 속성과 같은 장치 정보; ID, 인증 정보, 제조자, 구축 버전(build version), 및 선택적으로 모델, 제조, 일련 번호를 포함한 TrE_정보; 1) 장치의 실패 기능성의 리스트 및/또는 2) 플랫폼 구성 레지스터(PCR) 값을 포함한 검증 데이터; PCR 값을 통한 서명 또는 실패한 장치 기능성의 리스트와 같은 검증 결합; 컴포넌트 C_리스트에 대한 컴포넌트 표시자(CInd)의 주문된 리스트의 일부 또는 전부를 수집할 수 있고 컴포넌트에 대한 파라미터 및 타임스탬프(신뢰된 것 또는 신뢰되지 않은 것)를 포함할 수 있다(1822). TrE(1805)로부터 SeGW(1807)로의 확인 메시지/데이터는 상기 데이터를 포함할 수 있다(1824).
SeGW(1807)는 수신한 타임스탬프를 로컬 타임과 체크/비교하여 확인을 검출할 것이다(1826). 만일 보고된 타임스탬프가 로컬 타임과 일치하지 않으면, SeGW는 보고된 타임스탬프의 속성에 따라서 작용한다. 만일 장치의 타임스탬프가 신뢰된 타임스탬프이고 확인을 나타내면, SeGW(1807)는 TrE의 재확인 및 그 신뢰된 타임 소스를 트리거할 것이다. 신뢰된 타임스탬프가 아닌 경우, SeGW(1807)는 그 자신의 신뢰된 타임스탬프를 메시지에 추가한다. 만일 장치가 신뢰된 타임스탬프를 제공할 수 없으면, SeGW(1807)는 재전송 공격에 대한 보호로서 신뢰된 타임스탬프를 추가할 수 있다.
이 메시지를 수신한 때, SeGW(1807)는 TrE로부터의 서명 형태로 검증 결합(verification binding)이 존재하는지를 체크한다(1828). 이것은 검증 데이터의 진정성을 보증한다. 그 다음에, SeGW(1807)는 PVM 토큰(T_PVM)을 생성하고(1830), 타임스탬프를 전송하기 전에 신선함(freshness)을 확인하고 비동기 메시지 흐름을 방지하기 위해 타임스탬프를 T_PVM에 적용한다.
SeGW(1807)는 T_PVM을 PVE(1809)에 회송하고(1834) PVE(1809)는 그 다음에 TrE_info를 이용하여 V_DB(1813)에 질의한다(1836). 만일 신뢰할 수 없음 결정이 PVE(1809)에 되돌아오면(1838), PVE는 타임스탬프를 T_PVM에 적용하고(1840) 타임스탬프를 SeGW(1807)에 회송한다(1842). SeGW(1807)는 장치 인증의 거부를 TrE(1805)에 전송한다(1844).
만일 신뢰할 수 있음 결정이 PVE(1809)에 되돌아오면(1846), PVE는 Dev_ID를 이용하여 C_DB에 질의하고(1848), C_DB는 그 다음에 구성 폴리시를 PVE(1809)에 되돌려 보낸다(1850). PVE(1809)는 폴리시 구성을 평가한다(1852).
만일 구성이 신뢰할 수 없는 것이라고 PVE(1809)가 결정하면(1854), PVE(1809)는 T_PVM을 수정하고 타임스탬프를 적용한다(1856). 그 다음에, PVE(1809)는 T_PVM을 SeGW(1807)에 회송하고(1858), SeGW(1807)는 장치 인증의 거부를 TrE(1805)에 전송한다(1860).
만일 구성이 신뢰할 수 있다고 PVE(1809)가 결정하고 구성을 허용하면(1862), PVE(1809)는 V_DB(1813)로부터의 C리스트(Clist) 또는 C_리스트 내에 있는 모든 엔트리에 대한 RIM을 검색한다(1864). PVE(1809)는 RIM으로부터의 정확한 검증 데이터를 재계산하고(1866), 계산된 검증 데이터를 보고된 검증 데이터와 비교한다(1868). SAV의 경우에, RIM으로부터 계산된 검증 데이터는 실패한 기능성의 '빈 리스트' 형태일 수 있다. 그 다음에 PVE(1809)는 T_PVM을 수정하고 타임스탬프를 적용한다(1870). 그 다음에, PVE(1809)는 T_PVM을 SeGW(1807)에 회송한다(1872), SeGW(1807)는 PVE 확인 결과에 대하여 T_PVM을 조사(또는 T_PVM으로부터 추출)한다(1874). SeGW(1807)는 장치 인증의 거부 또는 허용을 TrE(1805)에 전송한다(1876). 만일 PVE 확인 결과가 부정이면, TrE(1805)는 리부트를 수행하고 재확인(revalidation)을 행한다(1890).
선택적으로, PVE(1809)는 계산된 검증 데이터를 보고된 검증 데이터와 비교(1868)한 후에, PVE(1809)는 실패한 컴포넌트의 리스트를 DMS(1811)에 보낼 수 있다(1878). 만일 실패한 컴포넌트의 리스트가 비어있지 않으면, DMS(1811)는 소프트웨어 또는 펌웨어의 업데이트가 적용될 수 있는지를 결정하고(1880), 만일 적용될 수 있으면 OTA 업데이트를 준비한다(1882). DMS(1811)는 또한 업데이트를 위한 RIM이 V_DB(1813)에 있음을 보증한다(1884). DMS(1811)는 T_PVM을 재확인의 표시와 함께 SeGW(1807)에 보내고(1886) 재확인 트리거를 TrE(1805)에 보낸다(1888). TrE(1805)는 리부트를 수행하고 재확인을 행한다(1890).
도 18A, 18B 및 18C에서의 처리에 관한 세부가 여기에서 개시된다. 플랫폼 확인을 수행하기 위해, TrE는 하기의 데이터, 즉 Dev_ID, 제조자, TrE 능력 및 RoT를 포함한 속성과 같은 장치 정보; ID, 인증 정보, 제조자, 구축 버전, 및 선택적으로 모델, 제조, 일련 번호를 포함한 TrE_정보; 무결성 검증 데이터(IVD)(IVD의 예는 서명된 플랫폼 구성 레지스터(PCR) 값일 수 있고, 다른 예는 단순히 장치-국소 무결성 체크 처리에 의해 무결성이 체크된 컴포넌트 또는 기능성의 리스트일 수 있으며, 상기 장치-국소 무결성 체크를 실패한 것으로 평가된다); PCR 값을 통한 서명 등의 검증 결합; 컴포넌트 C_리스트에 대한 컴포넌트 표시자(CInd)의 주문된 리스트이고 컴포넌트에 대한 파라미터를 포함할 수 있는 C리스트 등의 데이터를 수집하고 상기 데이터를 SeGW에 통신한다. 컴포넌트의 리스트는 예를 들면 RIM 인증서(RIMcs)를 지적함으로써 확인에 대한 RIM을 식별하기 위해 사용된다. 컴포넌트 및 그들의 파라미터에 대한 표시자의 주문된 리스트는 하기의 데이터 필드, 즉 인덱스, 컴포넌트_표시자(CInd), 컴포넌트_파라미터와 같은 엔트리를 포함한다. CInd는 컴포넌트에 레퍼런스를 제공하고 URN 포맷(예를 들면, URN://vendor.path.to/component/certificate)을 가질 수 있다. 선택사항: 타임스탬프(이것은 신뢰된 타임스탬프이거나, 또는 일반적으로 반드시 신뢰될 필요가 없는 통상의 타임스탬프일 수 있다).
장치의 경우에, 확인 메시지는 장치 정보, 예를 들면, ID, 인증 정보, 제조자, 모델, 버전, 제조, 일련 번호, TrE 능력 및 RoT를 포함한 속성, 장치의 보안 폴리시, 무결성 체크 및 체크후 컴포넌트 로딩의 다중 단계 처리 중 다른 스테이지에서 무결성 체크된 모듈, HW 구축 버전 번호, 및 선택적으로 SW 구축 버전 번호 및 무결성 측정 데이터를 추가적으로 포함할 수 있다.
확인을 위해 RIM을 사용하는 것은 바람직하지만 SAV에 대해서는 선택적인 방법이다. 이것은 다른 옵션들이 벗어나고 편향되는 기본 경우로서 여기에서 사용된다. 예를 들면, RIM으로부터 검증 데이터를 재계산하지 않은 확인이 있고, RIM 없이 PVM을 완전하게 수행하는 가능성까지도 있다.
검증 결합은 만일 확인 메시지가 예를 들면 보안 채널의 존재 및 사용에 의해 장치의 무결성을 수반하는 것이 아닌 다른 수단에 의해 인증에 결합된 것이면 선택적일 수 있다.
SeGW는 수신된 타임스탬프를 로컬 타임과 체크/비교하여 변형을 검출할 수 있다. 만일 보고된 타임스탬프가 로컬 타임과 일치하지 않으면, SeGW는 보고된 타임스탬프의 속성에 따라서 작용한다. 만일 장치의 타임스탬프가 신뢰된 타임스탬프이고 변형을 보이면, SeGW는 TrE 및 그 신뢰된 타임 소스의 재확인을 트리거할 수 있다. 신뢰되지 않은 타임스탬프의 경우에, SeGW는 그 자신의 타임스탬프를 메시지에 추가한다.
TrE_info는 선택적일 수 있다. Dev_ID는 TrE_info에 레퍼런스를 제공한다. 모든 MNO가 모든 TrE, 및 그에 따라서 모든 TrE_info 데이터를 알지 못하기 때문에, 이러한 맵핑은 임의의 주어진 Dev_ID에 대한 TrE_info를 얻기 위해 MNO에 의해 질의될 수 있는 데이터베이스에 의해 제공될 수 있다. TrE_info는 TrE_인증서 내에 있을 수 있다. TrE_인증서는 TrE 또는 TTP의 판매자, 예를 들면 져먼(german) BSI에 의해 서명되어야 한다.
컴포넌트에 대한 표시자(CInd)로서 URN을 사용하는 것은 이것이 컴포넌트의 상기 유일한 식별 및 RIM 또는 RIM 인증서가 인출되는 위치를 동시에 가능하게 하기 때문에 유리하다.
SeGW는 롤링 토큰으로서 사용될 수 있는 PVM 토큰(T_PVM)을 생성하고, 통신 중에 엔티티로부터 엔티티로 전달한다. 각 엔티티는 신선함을 보장하고 비동기 메시지 흐름을 방지하기 위해 타임스탬프를 전송하기 전에 타임스탬프를 토큰에 배치한다. 토큰의 타임스탬프는 토큰의 상태를 따르는 방법을 제공하기 위해 사용될 수 있다. 토큰은 CN에서 엔티티로부터 엔티티로 수 회 이동할 수 있고, 따라서 엔티티에 의해 추적될 수 있다. 선택적으로, 엔티티 ID는 타임스탬프 데이터의 사슬에 통합될 수 있다.
T_PVM은 Dev_ID를 포함할 수 있다. 만일 최초의 타임스탬프가 존재하지 않거나 신뢰되지 않으면, T_PVM은 SeGW에 의해 발행된 새로운 타임스탬프를 또한 포함할 수 있다. 그렇지 않으면 T_PVM은 확인 메시지로부터의 최초 타임스탬프를 포함할 것이다.
타임스탬프는 재전송(replay) 공격에 대한 보호를 위해 사용될 수 있다. 타임스탬프는 넌스 또는 단조롭게 증가하는 카운터와 결합하거나 이들에 의해 교체될 수 있다. 타임스탬프는 확인 데이터의 신선함을 평가하기 위해 또한 사용할 수 있다. 2가지 목적의 결합이 유리하고 타임스탬프에 의해 제공될 수 있다.
첫번째 변형예로서, DMS에 의한 나중의 장치 관리를 위하여, T_PVM은 DMS와 TrE 간의 보안 터널을 구축하기 위한 통신 비밀, 예를 들면 TLS 인증서를 포함할 수 있다.
SeGW는 모든 활성 T_PVM을 포함하는 토큰 데이터베이스(T_DB)를 유지한다.
SeGW는 확인 메시지로부터 확인 데이터, TrE_info, 및 C리스트를 추출한다. 토큰 T_PVM과 함께 이 데이터를 전송하기 전에, SeGW는 타임스탬프를 T_PVM에 배치하고 이것을 PVE에 회송한다. SeGW는 잘못 형성된 데이터 공격으로부터의 위협을 완화하기 위해 확인 메시지의 포맷 및 그 일부를 체크할 수 있다. 그렇지 않으면, 공격자는 절충된 TrE의 확인 메시지 내의 데이터를 수정하여 PVE에서 이 데이터의 순수한 검사가 시스템 에러 또는 장애를 일으키게 할 수 있다.
PVE는 장치의 유효성을 결정하는 엔티티이다. 즉 폴리시 시스템의 언어에서, PVE는 폴리시 결정 포인트(PDP)이다. 임무 접근법의 엄격한 분리하에서, PVE는 PVM 시스템에서 유일한 PDP이다. PVE는 폴리시 강화 포인트(PEP)로서 작용하는 것처럼 폴리시를 강화하기 위해 SeGW 및 DMS에 의존한다. PVM은 그 일반적인 묘사에 있어서 PVE가 어디에서 폴리시를 취득하는가와 같이 폴리시가 어떻게 발생되고 폴리시가 어디에 저장되고 관리되는가의 질문에 대해 불가지론적으로 유지된다. 더욱 구체적인 변형체의 일부 및 이하에서 설명하는 종속 방법에 있어서(특히 파라메트릭 확인 및 최소 확인에서), 폴리시 조건 및 동작의 일부 예가 주어진다. 일반적으로, 확인 폴리시에서의 결정은 단일 컴포넌트의 유효성뿐만 아니라 C리스트에 포함된 다른 데이터에 기초할 수 있다. 특히, 허용된 파라미터(범위) 및 로드의 주문(C리스트는 주문된다)이 평가될 수 있다.
PVE에 의해 실행되는 확인 처리에서 발생할 수 있는 실패 조건의 몇 가지 기본적인 부류가 있다. 예를 들면, 실패 조건 F1은 "TrE 무효" 시나리오를 표시한다. 그 인증된 Dev_ID 및 전송된 TrE_info에 의해, PVE는 장치 및/또는 그 TrE를 신뢰할 수 없는 것으로서 식별한다. 주: TrE가 무효인지 여부를 결정하기 위해 사용될 수 있는 정보는 SAV 확인 메시지 자체로 운반될 수 없고, 또는 다른 메시지 또는 다른 수단으로부터 추론될 수 있다. 그 기본적인 형태에 있어서, SAV 확인 메시지의 존재는 TrE 자체가 유효이어야 한다는 것을 암시적으로 표시한다. F1이 어떻게 검출되는가에 관한 상세한 내용은 "무선 장치의 플랫폼 확인 및 관리"라는 명칭으로 동시에 출원된 미국 특허 출원 제12/718,480호에 설명되어 있으며, 이 출원은 그 전부를 여기에서 설명한 것처럼 인용에 의해 여기에 통합된다.
다른 하나의 예는 "IVD 검증 실패"에 대한 3가지 시나리오를 나타내는 실패 조건 F2이다. 시나리오 F2a는 무결성 측정/검증 데이터 불일치(mis-match)를 나타낸다. 이것은 장치의 보안 시동 처리의 실패, 및/또는 장치에 잘못된 및/또는 만료된 RIM 및/또는 RIM 인증서의 존재를 나타내고, 무효 컴포넌트를 시작한다. 시나리오 F2b는 RIM 누락, 즉 컴포넌트의 RIM이 누락되었고 다른 어디에서 인출될 필요가 있음을 나타낸다. 시나리오 F2c는 만료된 RIM 인증서를 나타낸다.
실패 조건 F3는 "C리스트 폴리시 실패"에 대한 2가지 시나리오를 나타낸다. 시나리오 F3a에 있어서, 단일 컴포넌트가 유효하지만 구성은 예를 들면 로드 주문, 또는 바람직하지 않은 컴포넌트, 또는 파라미터에서 폴리시를 실패한다. 시나리오 F3b는 구성이 알려져 있지 않음을 나타내고, 그래서 C리스트에 대한 '공지의 양호한 값'을 이용할 수 없다.
여기에서는 실패 조건 등급 F2의 검출 및 취급 방법이 개시된다. 실패 조건 F2에 있어서, PVE는 수신된 C리스트로부터의 모든 컴포넌트에 대하여 V_DB로부터 RIM을 인출한다. 확인 데이터베이스(V_DB)는 인증된 RIM을 저장할 뿐이다. 대응하는 RIM 인증서는 V_DB에 안전하게 저장되어야 한다.
만일 IVD가 여기에서 설명한 좁게 한정된 SAV 절차에 대하여 설명한 것처럼 "국소 무결성 체크를 실패한 장치의 컴포넌트에 대응하는 장치의 컴포넌트"의 단순한 리스트의 형태이면, IVD_ref는 단순히 널 리스트(null list)의 형태일 것이다. 즉, 이 경우에 IVD_ref는 실패한 기능성의 예상된 리스트에 지나지 않고, 이것은 각 컴포넌트가 장치-국소 무결성 체크를 통과할 것으로 기대되면 널 테이블(null table)이어야 한다.
만일 IVD_ref가 수신된 IVD와 일치하지 않으면, 장치에서의 보안 시동 처리가 절충되거나 잘못된 RIM이 장치에 저장되고, 따라서 무효 컴포넌트가 보안 시동 처리에서 로드된다.
F2a 폴리시에 따라서, F2a 실패의 검출시에 몇 가지 옵션이 적용될 수 있다. 하나의 옵션은 거절이다. PVE는 확인의 결과물을 SeGW에 신호한다. SeGW는 그 다음에 네트워크 액세스를 거부하거나 장치를 격리 네트워크에 둔다. 두번째 옵션은 업데이트이다. 검증 데이터 실패를 나타내는 확인 결과(T_PVM)를 수신한 후, DMS는 확인을 실패한 컴포넌트를 교체하기 위해 관리 처리를 시작한다. 이러한 교정 처리의 상세한 내용은 "무선 장치의 플랫폼 확인 및 관리"라는 명칭으로 동시에 출원된 미국 특허 출원 제12/718,480호에 설명되어 있으며, 이 출원은 그 전부를 여기에서 설명한 것처럼 인용에 의해 여기에 통합된다.
폴리시 실패 조건이 부합되지 않으면, 장치는 유효이다. PVE는 이것을 SeGW에 신호하고, SeGW는 그 다음에 CN에 대한 접속을 허용한다.
RIM이 누락되는 실패 조건 F2b에 있어서, 이 조건은 RIM이 V_DB에서 누락되거나 장치에서 누락될 수 있기 때문에 발생한다(그래서 이 경우에 장치는 장치-국소 무결성 체크 절차를 수행할 수 없을 것이다). F2가 어떻게 검출되고 취급되는지에 관한 상세한 내용은 "무선 장치의 플랫폼 확인 및 관리"라는 명칭으로 동시에 출원된 미국 특허 출원 제12/718,480호에 설명되어 있으며, 이 출원은 그 전부를 여기에서 설명한 것처럼 인용에 의해 여기에 통합된다.
여기에서는 실패 조건 등급 F3의 검출 및 취급을 위한 방법이 개시된다. F3 실패 조건은 단일 컴포넌트가 유효이지만 컴포넌트의 구성이 폴리시를 실패한 경우(예를 들면 로딩 주문 불일치), 또는 구성이 알려져 있지 않은 경우, 즉 C리스트에 대한 "공지의 양호한 값"을 이용할 수 없는 경우에 발생한다. 이러한 실패 조건이 어떻게 발생할 수 있고 이러한 실패 조건이 어떻게 취급될 수 있는가에 관한 상세한 내용은 "무선 장치의 플랫폼 확인 및 관리"라는 명칭으로 동시에 출원된 미국 특허 출원 제12/718,480호에 설명되어 있으며, 이 출원은 그 전부를 여기에서 설명한 것처럼 인용에 의해 여기에 통합된다.
도 19는 H(e)NB와 함께 사용될 수 있는 진화형 범용 지상 라디오 액세스 네트워크(E-UTRAN)(1905)를 포함한 롱텀 에볼루션(LTE) 무선 통신 시스템/액세스 네트워크(1900)를 보인 것이다. E-UTRAN(1905)은 WTRU(1910))와 수 개의 진화형 노드-B(eNB)(1920)를 포함한다. WTRU(1910)는 eNB(1920)와 통신한다. eNB(1920)는 X2 인터페이스를 이용하여 서로 인터페이스 접속한다. 각 eNB(1920)는 S1 인터페이스를 통해 이동성 관리 엔티티(MME)/서빙 게이트웨이(S-GW)와 인터페이스 접속한다. 비록 도 19에는 하나의 WTRU(1910)와 3개의 eNB(1920)가 도시되어 있지만, 임의 조합의 무선 및 유선 장치가 무선 통신 시스템 액세스 네트워크(100)에 포함될 수 있다는 것을 이해하여야 한다.
도 20은 WTRU(1910), eNB(1920) 및 MME/S-GW(1930)를 포함한 LTE 무선 통신 시스템(2000)의 예시적인 블록도이다. 도 20에 도시한 바와 같이, WTRU(1910), eNB(1920) 및 MME/S-GW(1930)는 자율적 및 반자율적 확인을 이용하여 H(e)NB 무결성 검증 및 확인의 방법을 수행하도록 구성된다.
전형적인 WTRU에서 나타나는 컴포넌트 외에, WTRU(1910)는 선택적 결합 메모리(2022)를 구비한 프로세서(2016), 적어도 하나의 송수신기(2014), 선택사항인 배터리(2020) 및 안테나(2018)를 포함한다. 프로세서(2016)는 자율적 및 반자율적 확인을 이용하여 H(e)NB 무결성 검증 및 확인의 방법을 수행하도록 구성된다. 송수신기(2014)는 프로세서(2016) 및 안테나(2018)와 통신하여 무선 통신의 송신 및 수신을 행한다. WTRU(1910)에서 배터리(2020)를 사용하는 경우에, 배터리는 송수신기(2014) 및 프로세서(2016)에 전원을 공급한다.
전형적인 eNB(H(e)NB)를 포함함)에서 나타나는 컴포넌트 외에, eNB(1920)는 선택적 결합 메모리(2015)를 구비한 프로세서(2017), 송수신기(2019) 및 안테나(2021)를 포함한다. 프로세서(2017)는 자율적 및 반자율적 확인을 이용하여 H(e)NB 무결성 검증 및 확인의 방법을 수행하도록 구성된다. 송수신기(2019)는 프로세서(2017) 및 안테나(2021)와 통신하여 무선 통신의 송신 및 수신을 행한다. eNB(1920)는 선택적 결합 메모리(2034)를 구비한 프로세서(2033)를 포함하는 이동성 관리 엔티티/서빙 게이트웨이(MME/S-GW)에 접속된다.
비록 도 19 및 도 20에는 도시하지 않았지만, 전형적인 SeGW 및 PVE에서 나타나는 컴포넌트 외에, SeGW 및 PVE는 선택적 결합 메모리를 구비한 프로세서, 송수신기, 안테나 및 통신 포트를 포함할 수 있다. 프로세서는 PVM 방법을 구현하기 위해 플랫폼 확인 및 관리 기능을 수행하도록 구성된다. 송수신기 및 통신 포트는 필요에 따라서 프로세서 및 안테나와 통신하여 통신의 송신 및 수신을 수행한다.
실시예:
1. 옥내 진화형 노드 B(H(e)NB)의 무결성 검증을 수행하는 방법에 있어서, 컴포넌트 로딩 전에 컴포넌트의 무결성 메트릭을 측정하는 단계를 포함한 방법.
2. 실시예 1에 있어서, 신뢰된 참고 값(TRV)을 인증하는 단계를 더 포함한 방법.
3. 선행 실시예 중 어느 하나에 있어서, 측정된 무결성 메트릭을 TRV와 비교하는 단계를 더 포함한 방법.
4. 선행 실시예 중 어느 하나에 있어서, 무결성 검증 결과에 따라서 정상 코드와 폴백 코드 중 하나로 H(e)NB를 시작하는 단계를 더 포함한 방법.
5. 선행 실시예 중 어느 하나에 있어서, 적어도 하나의 참고 무결성 메트릭을 포함한 소프트웨어 모듈 및 관련 속성의 리스트와, H(e)NB와 플랫폼 확인 엔티티(PVE) 중 적어도 하나에 대한 가혹성을 제공하는 단계를 더 포함한 방법.
6. 선행 실시예 중 어느 하나에 있어서, 장치 구성 데이터 시트는 소프트웨어 모듈 및 관련 속성을 포함하고 H(e)NB와 플랫폼 확인 엔티티(PVE) 중 적어도 하나에 제공되는 것인 방법.
7. 선행 실시예 중 어느 하나에 있어서, 관련 속성은 컴포넌트 및 기능성에 관한 소프트웨어 모듈의 맵핑을 제공하는 것인 방법.
8. 선행 실시예 중 어느 하나에 있어서, 장치 구성 데이터 시트와 소프트웨어 모듈 및 관련 속성의 리스트 중 적어도 하나는 H(e)NB와 플랫폼 확인 엔티티(PVE) 중 적어도 하나에 저장되는 것인 방법.
9. 선행 실시예 중 어느 하나에 있어서, PVE가 동작을 결정하는 기초가 되는 모듈 식별자를 적어도 내포한 무결성 체크 실패 메시지를 전송하는 단계를 더 포함한 방법.
10. 선행 실시예 중 어느 하나에 있어서, 무결성 검증 실패의 가혹성 분류에 기초하여 미리 정해진 동작을 수행하는 단계를 더 포함한 방법.
11. 선행 실시예 중 어느 하나에 있어서, 미리 정해진 동작은 재난 메시지를 전송하는 단계와 코드 업데이트를 개시하는 단계와 교정을 개시하는 단계와 실패한 기능성의 리스트를 보고하는 단계 중 적어도 하나를 포함한 것인 방법.
12. 선행 실시예 중 어느 하나에 있어서, 소프트웨어 모듈 및 관련 속성의 리스트는 컴포넌트 특정 정보 요소, 모듈 특정 정보 요소 및 기능 요소 중 적어도 하나를 포함한 것인 방법.
13. 선행 실시예 중 어느 하나에 있어서, 컴포넌트 특정 정보 요소는 컴포넌트 설명, 컴포넌트 신원(ID) 및 신뢰된 참고 값(TRV) 중 적어도 하나를 포함한 것인 방법.
14. 선행 실시예 중 어느 하나에 있어서, 모듈 특정 정보 요소는 모듈 설명, 모듈 신원(ID), 기능 설명, 기능 ID, 컴포넌트 ID, 해제 버전 및 가혹성 중 적어도 하나를 포함한 것인 방법.
15. 선행 실시예 중 어느 하나에 있어서, 모듈은 무결성 검증 중에 적어도 1회 체크되는 것인 방법.
16. 선행 실시예 중 어느 하나에 있어서, 모듈은 단지 하나의 컴포넌트에서 나타나는 것인 방법.
17. 선행 실시예 중 어느 하나에 있어서, 모듈은 2개의 기능 사이에서 공유되는 것인 방법.
18. 선행 실시예 중 어느 하나에 있어서, 각 모듈은 관련 기능성을 갖는 것인 방법.
19. 선행 실시예 중 어느 하나에 있어서, 모듈들의 그룹은 동일한 컴포넌트와 관련되고 동일한 컴포넌트 식별자(ID)를 공유하며 동일한 컴포넌트로 무결성에 대해 집합적으로 검증되는 것인 방법.
20. 선행 실시예 중 어느 하나에 있어서, 하나의 컴포넌트 식별자(ID)를 가진 모듈은 다른 기능성 식별자(ID)로 분류되는 것인 방법.
21. 선행 실시예 중 어느 하나에 있어서, 모듈은 기능성 및 무결성 체크량에 따라 분류되는 것인 방법.
22. 선행 실시예 중 어느 하나에 있어서, 동일한 컴포넌트 식별자를 가진 모듈은 하나의 신뢰된 참고 값(TRV)을 갖고, 신뢰된 참고 값이 실패한 조건에서 실패한 컴포넌트 식별자의 모든 모듈은 실패한 기능성의 리스트를 결정하기 위해 사용되는 것인 방법.
23. 옥내 진화형 노드 B(H(e)NB)의 확인을 수행하는 방법에 있어서, 장치 무결성 체크 실패의 결과로서 폴백 코드로 H(e)NB를 시작하는 단계를 포함한 방법.
24. 실시예 23에 있어서, 재난 메시지를 전송하는 단계를 더 포함한 방법.
25. 실시예 23~24 중 어느 하나에 있어서, 교정 정보를 검색하기 위한 다운링크 메시지를 수신하는 단계를 더 포함한 방법.
26. 실시예 23~25 중 어느 하나에 있어서, 다운링크 메시지에 응답하여 교정 정보를 다운로드하는 단계를 더 포함한 방법.
27. 실시예 23~26 중 어느 하나에 있어서, 설치된 교정 정보에 따라서 H(e)NB를 재시작하는 단계를 더 포함한 방법.
28. 실시예 23~27 중 어느 하나에 있어서, 교정 정보의 준비를 허용하도록 실패 정보를 업로드하는 단계를 더 포함한 방법.
29. 실시예 23~28 중 어느 하나에 있어서, 재난 메시지는 제조자 신원, 신뢰된 환경 신원, H(e)NB 신원 및 실패 코드 중 적어도 하나를 포함한 것인 방법.
30. 실시예 23~29 중 어느 하나에 있어서, 가혹성 측정은 장치 무결성 체크 실패의 영향을 특정하는 것인 방법.
31. 실시예 23~30 중 어느 하나에 있어서, 장치 무결성 체크는 국소적으로 수행되는 것인 방법.
32. 실시예 23~31 중 어느 하나에 있어서, 실패 정보는 H(e)NB 관리 시스템(H(e)MS) 또는 플랫폼 확인 엔티티(PVE) 중 하나에 보내지는 것인 방법.
33. 실시예 23~32 중 어느 하나에 있어서, H(e)NB는 보안 소켓층/운송층 보안(SSL/TLS)을 이용하여 재난 메시지를 전송하는 것인 방법.
34. 실시예 23~33 중 어느 하나에 있어서, H(e)NB는 디폴트 H(e)MS 균일 리소스 로케이터(URL)로 구성된 것인 방법.
35. 실시예 23~34 중 어느 하나에 있어서, 장치 구성 데이터 시트는 장치의 보안 메모리 내에 유지되고 인증된 당사자에 의해 액세스되는 것인 방법.
36. 실시예 23~35 중 어느 하나에 있어서, H(e)NB는 장치 구성 데이터 시트가 만료된 때 교정 서버로부터 데이터를 끌어내기 위한 업데이트 처리를 개시하는 것인 방법.
37. 실시예 23~36 중 어느 하나에 있어서, H(e)NB는 미리 지정된 컴포넌트의 장치 무결성 체크를 수행하는 것인 방법.
38. 실시예 23~37 중 어느 하나에 있어서, PVE로부터 H(e)NB 동작을 수신하는 단계를 더 포함한 방법.
39. 옥내 진화형 노드 B(H(e)NB)의 확인을 수행하는 방법에 있어서, 인터넷 키 교환(IKE) 보안 연합을 확립하는 단계를 포함한 방법.
40. 실시예 39에 있어서, 상호 인증을 위한 IKE_AUTH 요구의 인증서 및 장치 무결성 체크 결과의 표시를 전송하는 단계를 더 포함한 방법.
41. 실시예 39~40 중 어느 하나에 있어서, 인증의 결과 및 장치 무결성 확인의 표시를 수신하는 단계를 더 포함한 방법.
42. 실시예 39~41 중 어느 하나에 있어서, 장치 무결성 체크 결과의 사정(assessment)에 기초하여 동작을 수신하는 단계를 더 포함한 방법.
43. 실시예 39~42 중 어느 하나에 있어서, 장치 무결성 체크 결과는 실패한 기능성의 리스트를 포함한 것인 방법.
44. 실시예 39~43 중 어느 하나에 있어서, 수신된 동작은 교정을 호출하는 것인 방법.
45. 실시예 39~44 중 어느 하나에 있어서, 장치 무결성 체크는 H(e)NB의 격리, 풀 액세스 수행, 부분 액세스 수행, 또는 교정을 위한 인원 개입 수행을 야기하는 것인 방법.
46. 실시예 39~45 중 어느 하나에 있어서, 교정을 표시하는 동작에 응답하여 재난 메시지를 전송하는 단계를 더 포함한 방법.
47. 실시예 39~46 중 어느 하나에 있어서, 교정 정보를 검색하기 위한 다운링크 메시지를 수신하는 단계를 더 포함한 방법.
48. 실시예 39~47 중 어느 하나에 있어서, 다운링크 메시지에 응답하여 교정 정보를 다운로드하는 단계를 더 포함한 방법.
49. 실시예 39~48 중 어느 하나에 있어서, 설치된 교정 정보에 따라서 H(e)NB를 재시작하는 단계를 더 포함한 방법.
50. 실시예 39~49 중 어느 하나에 있어서, 교정 정보의 준비를 허용하도록 실패 정보를 업로드하는 단계를 더 포함한 방법.
51. 실시예 39~50 중 어느 하나에 있어서, 실패 정보는 실패한 기능성의 리스트를 포함한 것인 방법.
52. 실시예 39~51 중 어느 하나에 있어서, 실패 정보는 H(e)NB 관리 시스템(H(e)MS) 또는 플랫폼 확인 엔티티(PVE) 중 하나에 전송되는 것인 방법.
53. 실시예 39~52 중 어느 하나에 있어서, 실패 정보는 체크된 기능성의 리스트를 포함한 것인 방법.
54. 실시예 39~53 중 어느 하나에 있어서, 실패 정보는 체크되지 않은 기능성의 리스트를 포함한 것인 방법.
55. 실시예 39~54 중 어느 하나에 있어서, 확인 및 인증의 결합은 IKE 세션에 의해 제공되는 것인 방법.
56. 실시예 39~55 중 어느 하나에 있어서, 확인 및 인증의 결합은 성공적인 장치 무결성 체크의 조건에서 진행하는 인증 절차에 의해 제공되는 것인 방법.
57. 장치 확인을 결합하는 방법에 있어서, 신뢰된 환경(TrE)을 인증 절차에 결합하는 단계를 포함한 방법.
58. 실시예 57에 있어서, 인증 절차는 UMTS 인증 및 키 협정을 위한 확장형 인증 프로토콜 메서드(EAP-AKA) 절차인 방법.
59. 실시예 57~58 중 어느 하나에 있어서, 상기 절차는 AKA 증명서를 확인하는 것인 방법.
60. 실시예 57~59 중 어느 하나에 있어서, AKA 증명서는 TrE에 포함된 것인 방법.
61. 실시예 57~60 중 어느 하나에 있어서, 확인 장치 및 EAP-AKA 기반 인증을 결합하는 단계를 더 포함한 방법.
62. 실시예 57~61 중 어느 하나에 있어서, EAP-AKA 인증은 AKA 증명서를 유지하는 TrE를 EAP-AKA 기반 인증의 절차에 결합하는 단계를 포함한 것인 방법.
63. 실시예 57~62 중 어느 하나에 있어서, 향상된 홈 노드 B(HeNB)에 대하여 AKA 증명서를 유지하는 TrE의 논리적 결합을 수행하는 단계를 더 포함한 방법.
64. 실시예 57~63 중 어느 하나에 있어서, 장치 플랫폼의 무결성이 확인되는 방법.
65. 실시예 57~64 중 어느 하나에 있어서, HeNB에 대하여 AKA 증명서를 유지하는 TrE의 물리적 결합을 수행하는 단계를 더 포함한 방법.
66. 실시예 57~65 중 어느 하나에 있어서, 하드웨어 및 소프트웨어에 대한 실제 무결성 확인은 HeNB에 안전하게 내장된 하드웨어 보안 컴포넌트에 의해 수행되는 것인 방법.
67. 실시예 57~66 중 어느 하나에 있어서, EAP-AKA 인증에 적당한 증명서 및 물리적으로 결합된 TrE에 저장된 관련 애플리케이션은 호스팅 장치에 대한 분리형 하드웨어 컴포넌트의 결합을 확인하도록 구성된 것인 방법.
68. 실시예 57~67 중 어느 하나에 있어서, AKA 증명서를 유지하는 TrE와 HeNB가 또한 결합된 것인 방법.
69. 실시예 57~68 중 어느 하나에 있어서, TrE만이 데이터를 복호할 수 있도록 장치 인증을 위해 사용되는 AKA 증명서를 연산하는데 필요한 HeNB 암호화 데이터를 더 포함하는 방법.
70. 실시예 57~69 중 어느 하나에 있어서, HeNB 암호화 데이터를 복호하는데 필요한 키를 안전하게 저장하는 TrE를 더 포함한 방법.
71. 실시예 57~70 중 어느 하나에 있어서, 추가의 결합을 얻기 위해 공통 보안 프로토콜의 동일 세션에서 장치 확인 및 장치 인증에 대한 결합 정보를 더 포함한 방법.
72. 실시예 57~71 중 어느 하나에 있어서, 공통 보안 프로토콜은 인터넷 키 교환 버전 2(IKEv2)인 방법.
73. 실시예 57~72 중 어느 하나에 있어서, 장치 확인은 HeNB와 네트워크 엔티티 간의 상호작용 및 메시지 교환을 포함한 것인 방법.
74. 실시예 57~73 중 어느 하나에 있어서, HeNB는 TrE를 포함한 것인 방법.
75. 실시예 57~74 중 어느 하나에 있어서, HeNB의 확인을 수행하는 네트워크 엔티티를 더 포함한 방법.
76. 실시예 57~75 중 어느 하나에 있어서, 확인을 수행하는 네트워크 엔티티와 HeNB 간의 시그널링을 운반하는 보안 게이트웨이를 더 포함한 방법.
77. 실시예 57~76 중 어느 하나에 있어서, 장치 확인을 인증서 기반 인증에 결합하는 단계를 더 포함한 방법.
78. 실시예 57~77 중 어느 하나에 있어서, 결합하는 단계는 HeNB의 TrE를 인증서 기반 장치 인증의 절차에 물리적으로 결합하는 단계를 포함한 것인 방법.
79. 실시예 57~78 중 어느 하나에 있어서, 결합하는 단계는 HeNB의 TrE를 인증서 기반 장치 인증의 절차에 논리적으로 결합하는 단계를 포함한 것인 방법.
80. 실시예 57~79 중 어느 하나에 있어서, 인증 증명서를 유지하는 TrE와 HeNB가 또한 결합되는 방법.
81. 실시예 57~80 중 어느 하나에 있어서, 암호화 키를 이용하여 장치 인증을 위해 사용되는 인증 증명서를 연산하는데 필요한 데이터를 암호화하는 HeNB와, TrE가 안전하게 유지하고 있는 키를 이용하여 TrE 내측의 암호화 데이터를 복호하는 TrE를 더 포함한 방법.
82. 실시예 57~81 중 어느 하나에 있어서, 2개의 절차에서 공통 프로토콜 세션의 동일하거나 연속적인 세션을 이용함으로써 HeNB 확인의 절차에 인증서 기반 인증 세션을 결합하는 단계를 더 포함한 방법.
83. 실시예 57~82 중 어느 하나에 있어서, 장치 확인은 네트워크가 HeNB의 장치 무결성의 확인을 수행하게 하는 네트워크 엔티티와 HeNB 사이에서의 공통 프로토콜 세션에 의한 상호작용을 포함한 것인 방법.
84. 실시예 57~83 중 어느 하나에 있어서, HeNB의 장치 확인을 EAP-AKA 기반 클라이언트 인증에 결합하는 단계를 더 포함한 방법.
85. 실시예 57~84 중 어느 하나에 있어서, TrE와 HeNB의 나머지 간의 메시지 교환을 위해 암호화 키와 증명서를 이용하여 TrE를 HeNB에 결합하는 단계를 더 포함한 방법.
86. 실시예 57~85 중 어느 하나에 있어서, TrE와 HeNB의 나머지 간의 메시지 교환은 장치 인증에 관한 메시지 교환을 포함한 것인 방법.
87. 실시예 57~86 중 어느 하나에 있어서, 키와 증명서는 TrE 내측에 보호되는 것인 방법.
88. 실시예 57~87 중 어느 하나에 있어서, 공통 보안 프로토콜의 동일하거나 연속적인 세션 중에 장치 확인 및 EAP-AKA 기반 클라이언트 인증의 지정된 부분을 수행하는 HeNB 및 TrE를 더 포함한 방법.
89. 실시예 57~88 중 어느 하나에 있어서, HeNB의 장치 확인을 인증서 기반 클라이언트 인증에 결합하는 단계를 더 포함한 방법.
90. 실시예 57~89 중 어느 하나에 있어서, TrE는 키 쌍을 포함한 것인 방법.
91. 실시예 57~90 중 어느 하나에 있어서, 키 쌍은 개인 부분과 공개 부분을 포함한 것인 방법.
92. 실시예 57~91 중 어느 하나에 있어서, 개인 부분은 TrE 내측에 안전하게 저장된 것인 방법.
93. 실시예 57~92 중 어느 하나에 있어서, 공개 부분은 HeNB에 이용가능한 것인 방법.
94. 실시예 57~93 중 어느 하나에 있어서, 키 쌍을 발생하는 HeNB의 제조자, 및 공개키를 HeNB에서 이용할 수 있게 하는 데에 필요한 인증서를 제공하는 단계를 더 포함한 방법.
95. 실시예 57~94 중 어느 하나에 있어서, EAP-AKA 기반 인증에서 암호화 수단에 의해 확인 및 인증의 결합을 생성하는 단계를 더 포함한 방법.
96. 실시예 57~95 중 어느 하나에 있어서, 인증서로부터 공개키로 응답을 암호화하는 HeNB, 및 암호화 데이터를 TrE에 회송하는 단계를 더 포함한 방법.
97. 실시예 57~96 중 어느 하나에 있어서, 응답은 IKE_AUTH 응답인 방법.
98. 실시예 57~97 중 어느 하나에 있어서, 데이터를 복호하는 TrE, 및 인증, 권한부여 및 어카운팅(AAA) 서버에 대해 HeNB를 인증하는데 필요한 EAP-AKA 응답(RES) 파라미터를 연산하는 단계를 더 포함한 방법.
99. 실시예 57~98 중 어느 하나에 있어서, TrE에서 공개키를 이용하여 AUTH 파라미터를 연산하는 데 필요한 데이터를 암호화하는 HeNB를 더 포함한 방법.
100. 실시예 57~99 중 어느 하나에 있어서, 데이터를 복호하는 TrE, 및 SeGW에 HeNB를 인증하는데 필요한 AUTH 파라미터를 연산하는 단계를 더 포함한 방법.
101. 실시예 57~100 중 어느 하나에 있어서, 장치 무결성과 장치 ID를 암호화로 결합하는 단계를 더 포함한 방법.
102. 실시예 57~101 중 어느 하나에 있어서, 장치 무결성과 장치 ID를 암호화로 결합하는 단계는 TrE 및 HeNB에 의해 수행되는 것인 방법.
103. 실시예 57~102 중 어느 하나에 있어서, TrE 및 HeNB는 각각의 공개키 쌍을 구비한 것인 방법.
104. 실시예 57~103 중 어느 하나에 있어서, TrE 및 HeNB는 각각의 대칭 공유키를 구비한 것인 방법.
105. 실시예 57~104 중 어느 하나에 있어서, TrE 및 HeNB는 키를 이용하여 통신을 보호하고 상호 인증을 행하는 것인 방법.
106. 실시예 57~105 중 어느 하나에 있어서, 장치 인증을 위한 IKEv2 프로토콜은 TrE를 HeNB에 결합하기 위해 사용되는 것인 방법.
107. 실시예 57~106 중 어느 하나에 있어서, 장치 무결성은 장치 무결성 확인 및 장치 인증의 절차를 결합함으로써 장치 ID에 결합되는 것인 방법.
108. 실시예 57~107 중 어느 하나에 있어서, 장치 무결성 확인 및 장치 인증은 보호된 TrE 내에서 수행되는 것인 방법.
109. 실시예 57~108 중 어느 하나에 있어서, TrE는 보호되고 신뢰된 엔티티인 방법.
110. 실시예 57~109 중 어느 하나에 있어서, TrE는 장치 무결성 확인 및 장치 인증의 절차를 실행하는 것인 방법.
111. 실시예 57~110 중 어느 하나에 있어서, IKEv2 프로토콜의 세션 또는 바로 후속되는 세션은 장치 무결성 확인 및 장치 인증 둘 다를 위해 사용되는 것인 방법.
112. 실시예 57~111 중 어느 하나에 있어서, 장치 확인 절차를 새로운 메시지 교환에 결합하는 단계를 더 포함한 방법.
113. 실시예 57~112 중 어느 하나에 있어서, 새로운 요구 및 응답 교환은 장치 인증을 위해 수행되는 다른 유사한 교환을 선행하는 것인 방법.
114. 실시예 57~113 중 어느 하나에 있어서, 장치 인증에 의해 사용되는 요구 및 응답 교환은 장치 확인 절차에 사용되는 것인 방법.
115. 실시예 57~114 중 어느 하나에 있어서, 장치 무결성 확인에 필요한 추가의 데이터는 선택된 메시지 필드에 내장되는 것인 방법.
116. 실시예 57~115 중 어느 하나에 있어서, 장치 무결성에 필요한 데이터는 국소 자율적 무결성 체크 또는 반자율적 확인의 결과물에 대한 서명된 설명서를 포함한 것인 방법.
117. 실시예 57~116 중 어느 하나에 있어서, 메시지 필드는 보호된 통지 필드를 포함한 것인 방법.
118. 실시예 57~117 중 어느 하나에 있어서, 장치 확인 절차를 기존 메시지 교환에 결합하는 단계를 더 포함한 방법.
119. 실시예 57~118 중 어느 하나에 있어서, 장치 확인 절차를 새로운 요구 및 응답 교환에 결합하는 단계를 더 포함한 방법.
120. 선행 실시예 중 어느 하나에 있어서, 무결성 체크를 수행하고 무결성 체크에서 생성된 정보를 이용하여 네트워크 결정에 영향을 주는 단계를 더 포함한 방법.
121. 선행 실시예 중 어느 하나에 있어서, 정보 요소는 제조자 및 무결성 알고리즘을 포함한 것인 방법.
122. 선행 실시예 중 어느 하나에 있어서, 컴포넌트 특정 정보 요소는 컴포넌트 설명, 컴포넌트 신원(ID) 및 신뢰된 참고 값(TRV)을 포함한 것인 방법.
123. 선행 실시예 중 어느 하나에 있어서, 모듈 특정 정보 요소는 모듈 설명, 모듈 신원(ID), 기능 설명, 기능 ID, 컴포넌트 ID, 해제 버전 및 가혹성을 포함한 것인 방법.
124. 선행 실시예 중 어느 하나에 있어서, 가혹성은 무결성 체크의 실패의 영향을 특정하는 것인 방법.
125. 선행 실시예 중 어느 하나에 있어서, 가혹성은 1~4의 규모로 분류되는 방법.
126. 선행 실시예 중 어느 하나에 있어서, 가혹성 1은 H(e)NB 기능성에서 높은 영향을 나타내고 동작 중지의 근거가 될 수 있으며, 폴백 코드 이미지(FBC)는 재난 신호를 지정된 H(e)NB에 보낼 수 있는 것인 방법.
127. 선행 실시예 중 어느 하나에 있어서, 가혹성 2는 제한된 H(e)NB 기능성을 나타내는 것인 방법.
128. 선행 실시예 중 어느 하나에 있어서, 가혹성 3은 핵심 기능성에 영향을 주지 않고 모듈/기능의 실패가 펌웨어 업데이트 절차에 의해 교체되며 리부트를 통하여 확인되는 것인 방법.
129. 선행 실시예 중 어느 하나에 있어서, 가혹성 4는 핵심 기능성에 영향을 주지 않고, 실패한 모듈이 정상 펌웨어 업데이트를 통해 교체될 수 있는 것인 방법.
130. 선행 실시예 중 어느 하나에 있어서, 자율적 확인 중에 장치 무결성 체크가 국소적으로 수행되는 방법.
131. 선행 실시예 중 어느 하나에 있어서, 무결성 체크가 실패한 조건에서, 재난 신호가 옥내 이동국(H(e)MS)에 전송되는 방법.
132. 선행 실시예 중 어느 하나에 있어서, 반자율적 확인 중에, 무결성 체크를 실패한 기능성의 리스트가 개인용 비디오 인코더(PVE)에 보고되는 방법.
133. 선행 실시예 중 어느 하나에 있어서, 무결성 체크 중에 모듈이 단지 1회 체크되는 방법.
134. 선행 실시예 중 어느 하나에 있어서, 모듈은 단지 하나의 컴포넌트에서만 나타나는 것인 방법.
135. 선행 실시예 중 어느 하나에 있어서, 모듈은 2개의 기능 사이에 공유될 수 있는 것인 방법.
136. 선행 실시예 중 어느 하나에 있어서, 각 모듈은 관련 기능성을 가지며, 실패한 기능성의 리스트는 유도되어 반자율적 확인(SAV)의 개인용 비디오 인코더(PVE)에 전송되는 것인 방법.
137. 선행 실시예 중 어느 하나에 있어서, 기능성 식별자(ID)는 모듈의 분류를 제공하는 것인 방법.
138. 선행 실시예 중 어느 하나에 있어서, 모듈은 발생된 이미지에 따라서 분류되는 것인 방법.
139. 선행 실시예 중 어느 하나에 있어서, 모듈들의 그룹은 동일한 컴포넌트 식별자(ID)를 포함하며 무결성에 대해 집합적으로 체크되는 것인 방법.
140. 선행 실시예 중 어느 하나에 있어서, 하나의 컴포넌트 식별자(ID)를 가진 모듈은 다른 기능성 식별자(ID)로 분류되는 것인 방법.
141. 선행 실시예 중 어느 하나에 있어서, 모듈 식별자(ID)는 소프트웨어의 각종 모듈을 추적하기 위해 사용되고 표준화되지 않은 것인 방법.
142. 선행 실시예 중 어느 하나에 있어서, 모듈은 기능성 및 무결성 체크량에 따라서 분류되는 것인 방법.
143. 선행 실시예 중 어느 하나에 있어서, 동일한 컴포넌트 식별자(ID)를 가진 모든 모듈은 하나의 신뢰된 참고 값을 갖고, 신뢰된 참고 값이 실패한 조건에서, 실패한 컴포넌트의 모든 모듈들은 실패한 기능성의 리스트를 결정하기 위해 사용되며 옥내 이동국(H(e)MS) 또는 개인용 비디오 인코더(PVE)에 통신되는 것인 방법.
144. 선행 실시예 중 어느 하나에 있어서, 기능성의 리스트는 컴포넌트와 관련된 것인 방법.
145. 선행 실시예 중 어느 하나에 있어서, 컴포넌트는 그들이 로드되는 순서대로 조직되는 것인 방법.
146. 선행 실시예 중 어느 하나에 있어서, 무결성 체크는 이미지 목적 파일의 일부에서 수행되고, 이미지 목적 파일이 무결성 체크를 통과하지 못한 조건에서 실패한 세그멘트명이 추출되는 방법.
147. 선행 실시예 중 어느 하나에 있어서, 고객 구내 설비(CPE)가 신뢰된 레퍼런스를 H(e)NB에 다운로드하기 위해 사용되고, 신뢰된 레퍼런스는 네트워크 운용자 서명키에 의해 디지털식으로 서명된 것인 방법.
148. 선행 실시예 중 어느 하나에 있어서, 신뢰된 참고 값을 포함한 서명된 패킷의 수신시에, H(e)NB는 서명을 복호하고 수신한 신뢰된 참고 값의 무결성 및 인증을 검증하는 것인 방법.
149. 선행 실시예 중 어느 하나에 있어서, 신뢰된 참고 값은 디지털식으로 서명되기 전에 기밀성을 위해 암호화되는 것인 방법.
150. 선행 실시예 중 어느 하나에 있어서, 신뢰된 참고 값은 소프트웨어 모듈 바이너리 이미지의 일부에 첨부되는 것인 방법.
151. 선행 실시예 중 어느 하나에 있어서, H(e)NB 및 옥내 이동국(H(e)MS)은 보안 소켓층/운송층 보안(SSL/TLS)을 지원하고 인증서 기반 인증을 사용하는 것인 방법.
152. 선행 실시예 중 어느 하나에 있어서, TR069 기반 아키텍쳐는 인증서 기반 인증을 지원하는 것인 방법.
153. 선행 실시예 중 어느 하나에 있어서, H(e)NB는 관리서버.URL 파라미터의 디폴트 옥내 이동국(H(e)MS) 균일 리소스 로케이터(URL)로 구성된 것인 방법.
154. 선행 실시예 중 어느 하나에 있어서, H(e)NB는 근거리 통신망(LAN) 측 관리서버.URL 구성을 지원하는 것인 방법.
155. 선행 실시예 중 어느 하나에 있어서, 보안 게이트웨이(SeGW) 균일 리소스 로케이터(URL)는 파라미터인 방법.
156. 선행 실시예 중 어느 하나에 있어서, 자율적 확인 중에, 디지털 서명 또는 메시지가 개인키를 이용하여 서명되는 방법.
157. 선행 실시예 중 어느 하나에 있어서, 자율적 확인 중에, 정보가 네트워크 엔티티에 전송되지 않는 방법.
158. 선행 실시예 중 어느 하나에 있어서, 신뢰된 참고 무결성 메트릭 또는 신뢰된 참고 값을 발생하기 위해 사용된 알고리즘을 위하여 최소 필요조건이 표준화되는 방법.
159. 선행 실시예 중 어느 하나에 있어서, 신뢰된 참고 값은 신뢰된 제3자에 의해 발생되고 디지털식으로 서명되는 것인 방법.
160. 선행 실시예 중 어느 하나에 있어서, 국소 무결성 데이터 초기화가 수행되어진 방법.
161. 선행 실시예 중 어느 하나에 있어서, 구성 데이터의 초기 공급이 수행되어진 방법.
162. 선행 실시예 중 어느 하나에 있어서, 참고 무결성 메트릭이 신뢰된 참고 값으로 된 방법.
163. 선행 실시예 중 어느 하나에 있어서, 장치 구성 데이터 시트가 장치의 보안 메모리 내에 유지되고 허가된 당사자에 의해서 액세스되는 방법.
164. 선행 실시예 중 어느 하나에 있어서, 장치 구성 데이터는 암호화되고 H(e)NB에 의해 복호되는 것인 방법.
165. 선행 실시예 중 어느 하나에 있어서, 보안 부팅 처리 중에, 발생된 다이제스트가 장치 구성 데이터 시트에서 특정한 값과 비교되는 방법.
166. 선행 실시예 중 어느 하나에 있어서, 장치 구성 데이터 시트가 만료된 조건에서, H(e)NB는 데이터를 교정 서버로부터 끌어내기 위한 펌웨어 업데이트 처리를 시작하는 것인 방법.
167. 선행 실시예 중 어느 하나에 있어서, 옥내 이동국(H(e)MS)은 원격 절차 호출(RPC)을 개시하고 관리서버.URL을 업데이트하는 것인 방법.
168. 선행 실시예 중 어느 하나에 있어서, 파일 전송 프로토콜 보안(FTPS)은 파일을 전송하기 위해 구현되는 것인 방법.
169. 선행 실시예 중 어느 하나에 있어서, 장치 무결성 체크가 자율적 확인에서 실패하고 국소 재난(distress) 플래그가 세트되며 폴백 코드(FBC)가 장치에 저장되는 방법.
170. 선행 실시예 중 어느 하나에 있어서, 재난 신호는 장치 무결성 체크 실패의 세부를 포함한 것인 방법.
171. 선행 실시예 중 어느 하나에 있어서, 파일 전송 프로토콜(FTP) 서버는 옥내 이동국(H(e)MS)과 합체되는 것인 방법.
172. 선행 실시예 중 어느 하나에 있어서, 반자율적 확인(SAV) 중에, H(e)NB는 비보안 링크를 통해 보안 게이트웨이(SeGW)와 상호작용하는 것인 방법.
173. 선행 실시예 중 어느 하나에 있어서, 보안 게이트웨이(SeGW)는 인증된 H(e)NB만이 네트워크에 액세스하도록 허용하는 것인 방법.
선행 실시예 중 어느 하나에 있어서, 옥내 이동국(H(e)MS)은 H(e)NB 관리 서버로서 작용하고 교정에 대한 지원을 제공하는 것인 방법.
174. 선행 실시예 중 어느 하나에 있어서, SAV에서, H(e)NB는 미리 지정된 컴포넌트의 무결성 체크를 수행하는 것인 방법.
175. 선행 실시예 중 어느 하나에 있어서, SAV에서, 컴포넌트의 확인은 무결성 알고리즘으로부터의 다이제스트(digest) 출력을 장치 구성 시트의 특정 값과 비교함으로써 국소적으로 수행되는 것인 방법.
176. 선행 실시예 중 어느 하나에 있어서, H(e)NB의 운송 요소(TrE)는 미리 규정된 컴포넌트의 무결성 체크를 수행하는 것인 방법.
177. 선행 실시예 중 어느 하나에 있어서, H(e)NB는 인증서 교환에 의해 보안 게이트웨이(SeGW)와 인터넷 키 교환(IKE) 보안 연합을 확립하는 것인 방법.
178. 선행 실시예 중 어느 하나에 있어서, 컴포넌트의 국소 무결성 확인 후에, 컴포넌트가 로드되고 장치에 의해 실행되는 방법.
179. 선행 실시예 중 어느 하나에 있어서, 인터넷 키 교환 요소(IKE)는 암호화 알고리즘에 대한 보안 파라미터 인덱스를 포함하는 보안 연합을 확립하기 위해 전송되는 것인 방법.
180. 선행 실시예 중 어느 하나에 있어서, 보안 게이트웨이(SeGW)는 인터넷 키 교환(IKE)을 위한 응답을 전송하는 것인 방법.
181. 선행 실시예 중 어느 하나에 있어서, H(e)NB는 상호 인증을 위한 IKE_AUTH_REQ의 인증서를 전송하는 것인 방법.
182. 선행 실시예 중 어느 하나에 있어서, 보안 게이트웨이(SeGW)는 H(e)NB의 인증 증명서를 평가하고 기능성 식별자의 리스트를 추출하는 것인 방법.
183. 선행 실시예 중 어느 하나에 있어서, 보안 게이트웨이(SeGW)는 인증 확인이 성공인 경우 그 표시를 H(e)NB에 전송하는 것인 방법.
184. 선행 실시예 중 어느 하나에 있어서, 보안 게이트웨이(SeGW)는 인증 확인이 실패인 경우 그 표시를 H(e)NB에 전송하는 것인 방법.
185. 선행 실시예 중 어느 하나에 있어서, SeGW는 실패한 기능성의 리스트를 개인용 비디오 인코더(PVE)에 전송하는 것인 방법.
186. 선행 실시예 중 어느 하나에 있어서, PVE는 장치의 격리를 포함한 동작을 결정하거나, 풀 액세스를 제공하거나, 부분 액세스를 제공하거나 또는 교정을 위한 옥내 이동국(H(e)MS) 개입을 요구하는 것인 방법.
187. 선행 실시예 중 어느 하나에 있어서, PVE는 결정을 SeGW에 통지하는 것인 방법.
188. 선행 실시예 중 어느 하나에 있어서, 개인용 비디오 인코더(PVE)는 교정 및 실패한 모듈의 리스트를 시작하도록 통지를 옥내 이동국(H(e)MS)에 전송하는 것인 방법.
189. 선행 실시예 중 어느 하나에 있어서, 개인용 비디오 인코더(PVE)는 교정에 관한 통지를 H(e)NB에 전송하는 것인 방법.
190. 선행 실시예 중 어느 하나에 있어서, 보안 게이트웨이(SeGW)는 장치 무결성 평가의 결과를 H(e)NB에게 표시하는 것인 방법.
191. 선행 실시예 중 어느 하나에 있어서, 운송 요소(TrE)는 무결성 검증을 외부 엔티티에 위임하는 것인 방법.
192. 선행 실시예 중 어느 하나에 있어서, H(e)NB는 네트워크 타임 프로토콜(NTP)을 이용하여 시간을 동기화하는 로컬 타임 서버를 포함한 것인 방법.
193. 선행 실시예 중 어느 하나에 있어서, 인증 인증서 및 SAV에서의 국소 확인의 결과는 IKE_AUTH_REQ 메시지로 전송되는 것인 방법.
194. 선행 실시예 중 어느 하나에 있어서, 보안 게이트웨이(SeGW)는 리스트를 개인용 비디오 인코더(PVE)에 통과시키기 전에 실패한 모듈의 리스트를 걸러내는 것인 방법.
195. 선행 실시예 중 어느 하나에 있어서, H(e)NB는 옥내 이동국(H(e)MS)과 상호작용하여 보안 게이트웨이를 통하여 또는 인터넷을 통하여 접속함으로써 교정을 지원하는 것인 방법.
196. 선행 실시예 중 어느 하나에 있어서, 옥내 이동국(H(e)MS)은 원격 절차 호출(RPC)을 호출하여 H(e)NB가 실패한 기능성의 리스트 및 에러 코드의 리스트를 업로드하는 것을 표시하는 것인 방법.
197. 선행 실시예 중 어느 하나에 있어서, 옥내 이동국(H(e)MS)은 실패한 기능성 리스트의 업로드를 준비하도록 파일서버에 표시하는 것인 방법.
198. 선행 실시예 중 어느 하나에 있어서, H(e)NB는 실패한 기능성의 리스트를 포함하는 파일을 업로드하는 절차를 호출하는 것인 방법.
199. 선행 실시예 중 어느 하나에 있어서, 파일서버는 업로드된 파일의 평가 후에 옥내 이동국(H(e)MS)에 다운로드_패키지_준비 메시지를 전송하는 것인 방법.
200. 선행 실시예 중 어느 하나에 있어서, 옥내 이동국(H(e)MS)은 원격 절차 호출(RPC)을 호출하고 장치 구성 시트의 균일 리소스 로케이터(URL)를 제공하는 것인 방법.
201. 선행 실시예 중 어느 하나에 있어서, H(e)NB는 파일 전송 프로토콜(FTP) 파일 서버에 접속하여 펌웨어 이미지 및 장치 구성 시트를 다운로드하는 것인 방법.
202. 선행 실시예 중 어느 하나에 있어서, 옥내 이동국(H(e)MS)은 성공적인 다운로드 응답을 수신한 때 리부트 절차를 호출하는 것인 방법.
203. 선행 실시예 중 어느 하나에 있어서, H(e)NB는 성공적인 다운로드 응답을 수신한 때 국소 재난 플래그를 리세트하는 것인 방법.
204. 선행 실시예 중 어느 하나에 있어서, 옥내 이동국(H(e)MS)은 장치가 성공적으로 부팅되었음을 표시하는 메시지를 보안 게이트웨이(SeGW)로부터 수신하는 것인 방법.
205. 선행 실시예 중 어느 하나에 있어서, 보안 부팅 처리 중에 무결성 체크가 로드되고 실행되어 인증이 성공적으로 수행된 조건에서, H(e)NB는 보안 게이트웨이와 통신하는 것인 방법.
206. 선행 실시예 중 어느 하나에 있어서, 국소 무결성 체크의 결과를 송신하는 단계를 더 포함한 방법.
207. 선행 실시예 중 어느 하나에 있어서, 국소 무결성 체크의 결과를 개인용 비디오 인코더(PVE)에 회송하는 단계를 더 포함한 방법.
208. 선행 실시예 중 어느 하나에 있어서, H(e)NB는 실패한 기능성 리스트 및 제조자 특정 에러 코드의 리스트를 IKEv2 NOTIFY 메시지로 SeGW에 전송하는 것인 방법.
209. 선행 실시예 중 어느 하나에 있어서, SeGW는 실패한 기능성의 리스트를 개인용 비디오 인코더(PVE)에 회송하는 것인 방법.
210. 선행 실시예 중 어느 하나에 있어서, PVE는 SeGW 동작, H(e)NB 동작을 결정하고, 동작들의 리스트를 SeGW에 회송하는 것인 방법.
적당한 프로세서로는, 예를 들면, 범용 프로세서, 특수 용도 프로세서, 종래의 프로세서(conventional processor), 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서, DSP 코어와 연합하는 하나 이상의 마이크로프로세서, 제어기, 마이크로컨트롤러, 용도 지정 집적회로(ASIC), 용도 지정 표준 제품(ASSP), 현장 프로그램가능 게이트 어레이(FPGA) 회로, 임의의 다른 유형의 집적회로(IC) 및/또는 상태 머신이 있다.
소프트웨어와 연합하는 프로세서는 무선 송수신 유닛(WTRU), 사용자 설비(UE), 단말기, 기지국, 이동성 관리 엔티티(MME) 또는 진화형 패킷 코어(EPC) 또는 임의의 호스트 컴퓨터에서 사용하기 위한 무선 주파수 송수신기를 구현하기 위해 사용될 수 있다. WTRU는 하드웨어 및/또는 소프트웨어 규정 라디오(SDR)를 포함한 소프트웨어로 구현되는 모듈, 및 카메라, 비디오 카메라 모듈, 비디오폰, 스피커폰, 진동 장치, 스피커, 마이크로폰, 텔레비전 송수신기, 핸즈프리 헤드셋, 키보드, 블루투스® 모듈, 주파수 변조(FM) 라디오 유닛, 근거리 통신(NFC) 모듈, 액정 디스플레이(LCD) 표시장치, 유기 발광 다이오드(OLED) 표시장치, 디지털 음악 재생기, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저, 및/또는 임의의 무선 근거리 통신망(WLAN) 또는 초광대역(UWB) 모듈과 같은 기타 컴포넌트와 함께 사용될 수 있다.
지금까지 특징 및 요소들을 특수한 조합으로 설명하였지만, 각 특징 또는 요소는 다른 특징 및 요소 없이 단독으로 또는 다른 특징 및 요소와 함께 또는 다른 특징 및 요소 없는 각종 조합으로 사용될 수 있다. 여기에서 제공한 방법 또는 흐름도는 범용 컴퓨터 또는 프로세서에 의해 실행되는 컴퓨터 판독가능 기억 매체에 통합된 컴퓨터 프로그램, 소프트웨어 또는 펌웨어로 구현될 수 있다. 컴퓨터 판독가능 기억 매체의 예로는 읽기 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 레지스터, 캐시 메모리, 반도체 메모리 장치, 내부 하드 디스크 및 착탈식 디스크와 같은 자기 매체, 자기 광학 매체, 및 CD-ROM 디스크 및 디지털 다기능 디스크(DVD)와 같은 광학 매체가 있다.
1205: H(e)NB 1210: 사용자 설비
1215: 비보안 통신 링크 1220: 코어 네트워크
1225: SeGW 1230: H(e)MS
1235: PVE 1240: OAM
1905: E-UTRAN 1910: WTRU
1920: eNB 1930: MME/S-GW
2014: 송수신기 2015: 메모리
2016: 프로세서 2017: 프로세서
2018: 안테나 2019: 송수신기
2020: 배터리 2021: 안테나
2022: 메모리 2033: 프로세서
2034: 메모리

Claims (44)

  1. 옥내 진화형 노드 B(H(e)NB: home evolved Node B)의 무결성 검증을 수행하는 방법에 있어서,
    컴포넌트 로딩 전에 컴포넌트의 무결성 메트릭(metrics)을 측정하는 단계와;
    신뢰된 참고 값(TRV: trusted reference value)을 인증하는 단계와;
    측정된 무결성 메트릭을 TRV와 비교하는 단계와;
    무결성 검증 결과에 따라서 정상 코드와 폴백 코드 중 하나로 H(e)NB를 시작하는 단계를 포함한 방법.
  2. 제1항에 있어서, 적어도 하나의 참고 무결성 메트릭을 포함한 소프트웨어 모듈 및 관련 속성의 리스트와, H(e)NB와 플랫폼 확인 엔티티(PVE: platform validation entity) 중 적어도 하나에 대한 가혹성(severity)을 제공하는 단계를 더 포함한 방법.
  3. 제2항에 있어서, 장치 구성 데이터 시트는 소프트웨어 모듈 및 관련 속성리스트를 포함하고 H(e)NB와 플랫폼 확인 엔티티(PVE) 중 적어도 하나에 제공되는 것인 방법.
  4. 제3항에 있어서, 관련 속성은 컴포넌트 및 기능성에 관한 소프트웨어 모듈의 맵핑을 제공하는 것인 방법.
  5. 제3항에 있어서, 장치 구성 데이터 시트와 소프트웨어 모듈 및 관련 속성의 리스트 중 적어도 하나는 H(e)NB와 플랫폼 확인 엔티티(PVE) 중 적어도 하나에 저장되는 것인 방법.
  6. 제2항에 있어서, PVE가 동작을 결정하는 기초가 되는 모듈 식별자를 적어도 내포한 무결성 체크 실패 메시지를 전송하는 단계를 더 포함한 방법.
  7. 제1항에 있어서, 무결성 검증 실패의 가혹성 분류에 기초하여 미리 정해진 동작을 수행하는 단계를 더 포함한 방법.
  8. 제7항에 있어서, 미리 정해진 동작은 재난 메시지를 전송하는 단계와 코드 업데이트를 개시하는 단계와 교정을 개시하는 단계와 실패한 기능성의 리스트를 보고하는 단계 중 적어도 하나를 포함한 것인 방법.
  9. 제2항에 있어서, 소프트웨어 모듈 및 관련 속성의 리스트는 컴포넌트 특정 정보 요소, 모듈 특정 정보 요소 및 기능 요소 중 적어도 하나를 포함한 것인 방법.
  10. 제9항에 있어서, 컴포넌트 특정 정보 요소는 컴포넌트 설명, 컴포넌트 신원(ID: identification) 및 신뢰된 참고 값(TRV) 중 적어도 하나를 포함한 것인 방법.
  11. 제9항에 있어서, 모듈 특정 정보 요소는 모듈 설명, 모듈 신원(ID), 기능 설명, 기능 ID, 컴포넌트 ID, 해제 버전 및 가혹성 중 적어도 하나를 포함한 것인 방법.
  12. 제4항에 있어서, 모듈은 무결성 검증 중에 적어도 1회 체크되는 것인 방법.
  13. 제12항에 있어서, 모듈은 단지 하나의 컴포넌트에서 나타나는 것인 방법.
  14. 제4항에 있어서, 모듈은 2개의 기능 사이에서 공유되는 것인 방법.
  15. 제4항에 있어서, 각 모듈은 관련 기능성을 갖는 것인 방법.
  16. 제1항에 있어서, 모듈들의 그룹은 동일한 컴포넌트와 관련되고 동일한 컴포넌트 식별자(ID)를 공유하며 동일한 컴포넌트로 무결성에 대해 집합적으로 검증되는 것인 방법.
  17. 제1항에 있어서, 하나의 컴포넌트 식별자(ID)를 가진 모듈은 다른 기능성 식별자(ID)로 분류되는 것인 방법.
  18. 제1항에 있어서, 모듈은 기능성 및 무결성 체크량에 따라 분류되는 것인 방법.
  19. 제1항에 있어서, 동일한 컴포넌트 식별자를 가진 모듈은 하나의 신뢰된 참고 값(TRV)을 갖고, 신뢰된 참고 값이 실패한 조건에서 실패한 컴포넌트 식별자의 모든 모듈은 실패한 기능성의 리스트를 결정하기 위해 사용되는 것인 방법.
  20. 옥내 진화형 노드 B(H(e)NB)의 확인을 수행하는 방법에 있어서,
    장치 무결성 체크 실패의 결과로서 폴백 코드로 H(e)NB를 시작하는 단계와;
    재난 메시지를 전송하는 단계와;
    교정 정보를 검색하기 위한 다운링크 메시지를 수신하는 단계와;
    다운링크 메시지에 응답하여 교정 정보를 다운로드하는 단계와;
    설치된 교정 정보에 따라서 H(e)NB를 재시작하는 단계를 포함한 방법.
  21. 제20항에 있어서, 교정 정보의 준비를 허용하도록 실패 정보를 업로드하는 단계를 더 포함한 방법.
  22. 제20항에 있어서, 재난 메시지는 제조자 신원, 신뢰된 환경 증명, H(e)NB 증명 및 실패 코드 중 적어도 하나를 포함한 것인 방법.
  23. 제20항에 있어서, 가혹성 측정은 장치 무결성 체크 실패의 영향을 특정하는 것인 방법.
  24. 제20항에 있어서, 장치 무결성 체크는 국소적으로 수행되는 것인 방법.
  25. 제21항에 있어서, 실패 정보는 H(e)NB 관리 시스템(H(e)MS: home evolved management system) 또는 플랫폼 확인 엔티티(PVE) 중 하나에 보내지는 것인 방법.
  26. 제20항에 있어서, H(e)NB는 보안 소켓층/운송층 보안(SSL/TLS: secure sockets layer/transport layer security)을 이용하여 재난 메시지를 전송하는 것인 방법.
  27. 제20항에 있어서, H(e)NB는 디폴트 H(e)MS 균일 리소스 로케이터(URL: uniform resource locator)로 구성된 것인 방법.
  28. 제20항에 있어서, 장치 구성 데이터 시트는 장치의 보안 메모리 내에 유지되고 허가된 당사자에 의해 액세스되는 것인 방법.
  29. 제20항에 있어서, H(e)NB는 장치 구성 데이터 시트가 만료된 때 교정 서버로부터 데이터를 끌어내기 위한 업데이트 처리를 개시하는 것인 방법.
  30. 제21항에 있어서, H(e)NB는 미리 지정된 컴포넌트의 장치 무결성 체크를 수행하는 것인 방법.
  31. 제20항에 있어서, PVE로부터 H(e)NB 동작을 수신하는 단계를 더 포함한 방법.
  32. 옥내 진화형 노드 B(H(e)NB)의 확인을 수행하는 방법에 있어서,
    인터넷 키 교환(IKE: internet key exchange) 보안 연합을 확립하는 단계와;
    상호 인증을 위한 IKE_AUTH 요구의 인증서 및 장치 무결성 체크 결과의 표시를 전송하는 단계와;
    인증의 결과 및 장치 무결성 확인의 표시를 수신하는 단계와;
    장치 무결성 체크 결과의 사정(assessment)에 기초하여 동작을 수신하는 단계를 포함한 방법.
  33. 제32항에 있어서, 장치 무결성 체크 결과는 실패한 기능성의 리스트를 포함한 것인 방법.
  34. 제33항에 있어서, 수신된 동작은 교정을 호출하는 것인 방법.
  35. 제33항에 있어서, 장치 무결성 체크는 H(e)NB의 격리, 풀 액세스 수행, 부분 액세스 수행, 또는 교정을 위한 인원 개입 수행을 야기하는 것인 방법.
  36. 제33항에 있어서, 교정을 표시하는 동작에 응답하여 재난 메시지를 전송하는 단계를 더 포함한 방법.
  37. 제36항에 있어서, 교정 정보를 검색하기 위한 다운링크 메시지를 수신하는 단계와;
    다운링크 메시지에 응답하여 교정 정보를 다운로드하는 단계와;
    설치된 교정 정보에 따라서 H(e)NB를 재시작하는 단계를 더 포함한 방법.
  38. 제37항에 있어서, 교정 정보의 준비를 허용하도록 실패 정보를 업로드하는 단계를 더 포함한 방법.
  39. 제38항에 있어서, 실패 정보는 실패한 기능성의 리스트를 포함한 것인 방법.
  40. 제38항에 있어서, 실패 정보는 H(e)NB 관리 시스템(H(e)MS) 또는 플랫폼 확인 엔티티(PVE) 중 하나에 전송되는 것인 방법.
  41. 제38항에 있어서, 실패 정보는 체크된 기능성의 리스트를 포함한 것인 방법.
  42. 제38항에 있어서, 실패 정보는 체크되지 않은 기능성의 리스트를 포함한 것인 방법.
  43. 제32항에 있어서, 확인 및 인증의 결합은 IKE 세션에 의해 제공되는 것인 방법.
  44. 제32항에 있어서, 확인 및 인증의 결합은 성공적인 장치 무결성 체크의 조건에서 진행하는 인증 절차에 의해 제공되는 것인 방법.
KR1020117023302A 2009-03-05 2010-03-05 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치 KR20110126160A (ko)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US15783309P 2009-03-05 2009-03-05
US61/157,833 2009-03-05
US22206709P 2009-06-30 2009-06-30
US61/222,067 2009-06-30
US23579309P 2009-08-21 2009-08-21
US61/235,793 2009-08-21
US23969809P 2009-09-03 2009-09-03
US61/239,698 2009-09-03

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020127001861A Division KR101607363B1 (ko) 2009-03-05 2010-03-05 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치

Publications (1)

Publication Number Publication Date
KR20110126160A true KR20110126160A (ko) 2011-11-22

Family

ID=42236918

Family Applications (6)

Application Number Title Priority Date Filing Date
KR1020167021804A KR101691603B1 (ko) 2009-03-05 2010-03-05 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치
KR1020167007406A KR101649465B1 (ko) 2009-03-05 2010-03-05 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치
KR1020127001861A KR101607363B1 (ko) 2009-03-05 2010-03-05 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치
KR1020177019856A KR20170086140A (ko) 2009-03-05 2010-03-05 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치
KR1020117023302A KR20110126160A (ko) 2009-03-05 2010-03-05 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치
KR1020167036285A KR101760451B1 (ko) 2009-03-05 2010-03-05 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치

Family Applications Before (4)

Application Number Title Priority Date Filing Date
KR1020167021804A KR101691603B1 (ko) 2009-03-05 2010-03-05 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치
KR1020167007406A KR101649465B1 (ko) 2009-03-05 2010-03-05 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치
KR1020127001861A KR101607363B1 (ko) 2009-03-05 2010-03-05 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치
KR1020177019856A KR20170086140A (ko) 2009-03-05 2010-03-05 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020167036285A KR101760451B1 (ko) 2009-03-05 2010-03-05 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치

Country Status (10)

Country Link
US (3) US9253643B2 (ko)
EP (2) EP2966888A1 (ko)
JP (4) JP5453461B2 (ko)
KR (6) KR101691603B1 (ko)
CN (2) CN102342141A (ko)
AR (1) AR076087A1 (ko)
BR (1) BRPI1006524A2 (ko)
RU (1) RU2011140357A (ko)
TW (3) TWI531254B (ko)
WO (1) WO2010102222A2 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11121866B2 (en) * 2018-04-27 2021-09-14 Airbus Ds Slc Method for configuring access to fallback communication services and associated system

Families Citing this family (78)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004046874A1 (de) * 2004-09-28 2006-04-13 Robert Bosch Gmbh Verfahren zum Betreiben eines Verwaltungssystems von Funktionsmodulen
KR101731200B1 (ko) 2008-01-18 2017-05-11 인터디지탈 패튼 홀딩스, 인크 Ｍ2ｍ 통신을 인에이블하는 방법 및 장치
US8571550B2 (en) * 2009-02-09 2013-10-29 Qualcomm Incorporated Managing access control to closed subscriber groups
KR101691603B1 (ko) 2009-03-05 2016-12-30 인터디지탈 패튼 홀딩스, 인크 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치
JP2012520027A (ja) 2009-03-06 2012-08-30 インターデイジタル パテント ホールディングス インコーポレイテッド 無線装置のプラットフォームの検証と管理
US20110237250A1 (en) * 2009-06-25 2011-09-29 Qualcomm Incorporated Management of allowed csg list and vplmn-autonomous csg roaming
US8443431B2 (en) * 2009-10-30 2013-05-14 Alcatel Lucent Authenticator relocation method for WiMAX system
WO2011069169A1 (en) * 2009-12-04 2011-06-09 Financialos, Inc. Methods for platform-agnostic definitions and implementations of applications
US8756488B2 (en) 2010-06-18 2014-06-17 Sweetlabs, Inc. Systems and methods for integration of an application runtime environment into a user computing environment
WO2012023050A2 (en) 2010-08-20 2012-02-23 Overtis Group Limited Secure cloud computing system and method
US8516062B2 (en) 2010-10-01 2013-08-20 @Pay Ip Holdings Llc Storage, communication, and display of task-related data
US8918467B2 (en) * 2010-10-01 2014-12-23 Clover Leaf Environmental Solutions, Inc. Generation and retrieval of report information
US8914674B2 (en) * 2010-11-05 2014-12-16 Interdigital Patent Holdings, Inc. Device validation, distress indication, and remediation
JP5864598B2 (ja) * 2010-11-11 2016-02-17 エヌイーシー ヨーロッパ リミテッドＮｅｃ Ｅｕｒｏｐｅ Ｌｔｄ． ユーザにサービスアクセスを提供する方法およびシステム
US8812828B2 (en) * 2010-11-16 2014-08-19 Intel Corporation Methods and apparatuses for recovering usage of trusted platform module
WO2012134217A2 (en) * 2011-03-30 2012-10-04 Samsung Electronics Co., Ltd. Method and system to differentiate and assigning ip addresses to wireless femto cells h(e)nb (home (evolved) nodeb) and lgw (local gateway) by using ikev2 (internet key exchange version 2 protocol) procedure
KR101430242B1 (ko) 2011-08-01 2014-08-18 주식회사 케이티 펨토 기지국간 ｘ２ 인터페이스 설정 방법 및 펨토 기지국 관리 시스템
KR101862353B1 (ko) * 2011-09-30 2018-07-05 삼성전자주식회사 업그레이드 방식이 적응적으로 변경될 수 있는 업그레이드 시스템 및 업그레이드 방법
TWI428031B (zh) * 2011-10-06 2014-02-21 Ind Tech Res Inst 區域網協存取網路元件與終端設備的認證方法與裝置
CN103096311B (zh) * 2011-10-31 2018-11-09 中兴通讯股份有限公司 家庭基站安全接入的方法及系统
WO2013109417A2 (en) * 2012-01-18 2013-07-25 Zte Corporation Notarized ike-client identity and info via ike configuration payload support
US10433161B2 (en) * 2012-01-30 2019-10-01 Telefonaktiebolaget Lm Ericsson (Publ) Call handover between cellular communication system nodes that support different security contexts
CN104081376B (zh) * 2012-02-21 2018-02-02 慧与发展有限责任合伙企业 使用分布式文件系统协议远程维持系统固件映像
CN102711106B (zh) * 2012-05-21 2018-08-10 中兴通讯股份有限公司 建立IPSec隧道的方法及系统
US8775925B2 (en) 2012-08-28 2014-07-08 Sweetlabs, Inc. Systems and methods for hosted applications
CA2886058A1 (en) * 2012-09-28 2014-04-03 Level 3 Communications, Llc Identifying and mitigating malicious network threats
US9681261B2 (en) 2012-11-01 2017-06-13 Lg Electronics Inc. Method and apparatus of providing integrity protection for proximity-based service discovery with extended discovery range
US10574560B2 (en) * 2013-02-13 2020-02-25 Microsoft Technology Licensing, Llc Specifying link layer information in a URL
EP3011445A4 (en) * 2013-06-18 2017-02-15 Thomson Licensing Dual-bank telecommunication apparatus and method of upgrading firmware in dual-bank telecommunication apparatus
CN108923918B (zh) * 2013-06-28 2022-07-15 日本电气株式会社 用户设备和通信方法
US9350550B2 (en) 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
US9100175B2 (en) 2013-11-19 2015-08-04 M2M And Iot Technologies, Llc Embedded universal integrated circuit card supporting two-factor authentication
US10498530B2 (en) 2013-09-27 2019-12-03 Network-1 Technologies, Inc. Secure PKI communications for “machine-to-machine” modules, including key derivation by modules and authenticating public keys
WO2015072788A1 (en) * 2013-11-14 2015-05-21 Samsung Electronics Co., Ltd. Method and apparatus for managing security key in a near fieldd2d communication system
US10700856B2 (en) 2013-11-19 2020-06-30 Network-1 Technologies, Inc. Key derivation for a module using an embedded universal integrated circuit card
US9749440B2 (en) 2013-12-31 2017-08-29 Sweetlabs, Inc. Systems and methods for hosted application marketplaces
US20150310390A1 (en) * 2014-04-23 2015-10-29 Bank Of America Corporation Aggregation and workflow engines for managing project information
US10089098B2 (en) 2014-05-15 2018-10-02 Sweetlabs, Inc. Systems and methods for application installation platforms
US10019247B2 (en) 2014-05-15 2018-07-10 Sweetlabs, Inc. Systems and methods for application installation platforms
US20160036812A1 (en) * 2014-07-31 2016-02-04 International Business Machines Corporation Database Queries Integrity and External Security Mechanisms in Database Forensic Examinations
US9705849B2 (en) * 2014-09-30 2017-07-11 Intel Corporation Technologies for distributed detection of security anomalies
DE102014119065B4 (de) * 2014-12-18 2020-10-29 Phoenix Contact Gmbh & Co. Kg Funktionsanschlusseinheit mit einem Servicemodul
US9853977B1 (en) 2015-01-26 2017-12-26 Winklevoss Ip, Llc System, method, and program product for processing secure transactions within a cloud computing system
CN105991285B (zh) * 2015-02-16 2019-06-11 阿里巴巴集团控股有限公司 用于量子密钥分发过程的身份认证方法、装置及系统
WO2016178123A1 (en) 2015-05-04 2016-11-10 Pfizer Inc. Group b streptococcus polysaccharide-protein conjugates, methods for producing conjugates, immunogenic compositions comprising conjugates, and uses thereof
US11570209B2 (en) 2015-10-28 2023-01-31 Qomplx, Inc. Detecting and mitigating attacks using forged authentication objects within a domain
US11552968B2 (en) 2015-10-28 2023-01-10 Qomplx, Inc. System and methods for detecting and mitigating golden SAML attacks against federated services
US11570204B2 (en) 2015-10-28 2023-01-31 Qomplx, Inc. Detecting and mitigating golden ticket attacks within a domain
US11005824B2 (en) * 2015-10-28 2021-05-11 Qomplx, Inc. Detecting and mitigating forged authentication object attacks using an advanced cyber decision platform
WO2017121854A1 (en) * 2016-01-14 2017-07-20 Nokia Solutions And Networks Oy Flexible selection of security features in mobile networks
US20190073479A1 (en) * 2016-03-10 2019-03-07 Nokia Solutions And Networks Oy Trust failure alert in communications
KR102522778B1 (ko) * 2016-04-27 2023-04-19 한국전자통신연구원 분산 대리자 기반 무결성 검증을 수행하는 개별 기기, 그를 포함하는 개별 기기 무결성 검증 시스템 및 그 방법
US10708128B2 (en) * 2016-04-29 2020-07-07 Dcb Solutions Limited Data driven orchestrated network with installation control using a light weight distributed controller
US10868720B2 (en) * 2016-04-29 2020-12-15 Dcb Solutions Limited Data driven orchestrated network using a voice activated light weight distributed SDN controller
US20170357494A1 (en) * 2016-06-08 2017-12-14 International Business Machines Corporation Code-level module verification
US10157009B2 (en) * 2016-07-06 2018-12-18 Arris Enterprises Llc Custom command file for efficient memory update
US10305750B1 (en) 2016-07-29 2019-05-28 Juniper Networks, Inc. Methods and apparatus for centralized configuration management of heterogenous network devices through software-based node unification
CN107666383B (zh) * 2016-07-29 2021-06-18 阿里巴巴集团控股有限公司 基于https协议的报文处理方法以及装置
EP3555785A1 (en) * 2016-12-15 2019-10-23 Irdeto B.V. Software integrity verification
KR101870913B1 (ko) * 2016-12-19 2018-06-25 주식회사 케이티 분산 접속 제어 방법 및 이를 수행하는 초소형 이동통신 기지국
US10587421B2 (en) * 2017-01-12 2020-03-10 Honeywell International Inc. Techniques for genuine device assurance by establishing identity and trust using certificates
DE102017201857A1 (de) * 2017-02-07 2018-08-09 Siemens Aktiengesellschaft Netzwerksystem und Verfahren zur Überprüfung der Funktionsfähigkeit einer Cloud-basierten Steuerungsfunktion
US11229023B2 (en) 2017-04-21 2022-01-18 Netgear, Inc. Secure communication in network access points
CN109803260B (zh) * 2017-11-17 2022-01-11 中兴通讯股份有限公司 拒绝接入方法、装置及系统
US10853090B2 (en) * 2018-01-22 2020-12-01 Hewlett Packard Enterprise Development Lp Integrity verification of an entity
WO2019212844A1 (en) * 2018-04-30 2019-11-07 Merck Sharp & Dohme Corp. Methods for providing a homogenous solution of lyophilized mutant diptheria toxin in dimethylsulfoxide
WO2020010515A1 (en) * 2018-07-10 2020-01-16 Apple Inc. Identity-based message integrity protection and verification for wireless communication
EP3599567A1 (de) * 2018-07-25 2020-01-29 Siemens Aktiengesellschaft Vorrichtung und verfahren für eine integritätsüberprüfung einer oder mehrerer gerätekomponenten
GB2581861B (en) * 2018-09-14 2022-10-05 Sino Ic Tech Co Ltd IC Test Information Management System Based on Industrial Internet
EP3895464A4 (en) 2019-01-29 2022-08-03 Schneider Electric USA, Inc. SECURITY CONTEXT DISTRIBUTION SERVICE
EP3696698A1 (en) * 2019-02-18 2020-08-19 Verimatrix Method of protecting a software program against tampering
TWI737106B (zh) * 2019-12-31 2021-08-21 啟碁科技股份有限公司 韌體更新方法和韌體更新系統
US11477033B2 (en) * 2020-02-05 2022-10-18 Nxp B.V. Authentication without pre-known credentials
US11272007B2 (en) * 2020-07-21 2022-03-08 Servicenow, Inc. Unified agent framework including push-based discovery and real-time diagnostics features
CN114125846B (zh) * 2020-08-11 2023-09-12 维沃移动通信有限公司 完好性保护方法和系统
US20230289478A1 (en) * 2020-08-28 2023-09-14 Hewlett-Packard Development Company, L.P. Generating signed measurements
CN112153078B (zh) * 2020-10-26 2021-07-27 广州欧赛斯信息科技有限公司 一种基于时间释放的加密方法及系统
US11838428B2 (en) * 2021-12-20 2023-12-05 Nokia Technologies Oy Certificate-based local UE authentication

Family Cites Families (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2974311B1 (ja) * 1998-07-17 1999-11-10 日本電気移動通信株式会社 無線基地局装置
US8347086B2 (en) 2000-12-18 2013-01-01 Citibank, N.A. System and method for automatically detecting and then self-repairing corrupt, modified of non-existent files via a communication medium
US6731932B1 (en) 1999-08-24 2004-05-04 Telefonaktiebolaget Lm Ericsson (Publ) Methods and systems for handling subscriber data
JP2002152821A (ja) * 2000-11-08 2002-05-24 Nec Saitama Ltd 携帯端末装置のプログラム更新方法および携帯端末装置
FI114276B (fi) 2002-01-11 2004-09-15 Nokia Corp Verkkovierailun järjestäminen
US6993760B2 (en) 2001-12-05 2006-01-31 Microsoft Corporation Installing software on a mobile computing device using the rollback and security features of a configuration manager
US7240830B2 (en) 2002-02-15 2007-07-10 Telefonaktiebolaget Lm Ericsson (Publ) Layered SIM card and security function
DE10223248A1 (de) 2002-05-22 2003-12-04 Siemens Ag Verfahren zum Registrieren eines Kommunikationsendgeräts
JP4041492B2 (ja) 2002-08-22 2008-01-30 株式会社エヌ・ティ・ティ・ドコモ アドホックネットワークにおけるネットワークノード群の再設定
US7360099B2 (en) * 2002-09-19 2008-04-15 Tripwire, Inc. Computing environment and apparatuses with integrity based fail over
US7634807B2 (en) 2003-08-08 2009-12-15 Nokia Corporation System and method to establish and maintain conditional trust by stating signal of distrust
EP1533695B1 (en) 2003-11-19 2013-08-07 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Updating data in a mobile terminal
US20050138355A1 (en) 2003-12-19 2005-06-23 Lidong Chen System, method and devices for authentication in a wireless local area network (WLAN)
JP4144880B2 (ja) * 2004-04-09 2008-09-03 インターナショナル・ビジネス・マシーンズ・コーポレーション プラットフォーム構成測定装置、プログラム及び方法、プラットフォーム構成認証装置、プログラム及び方法、プラットフォーム構成証明装置、プログラム及び方法、並びに、プラットフォーム構成開示装置、プログラム及び方法
JP2005341226A (ja) * 2004-05-27 2005-12-08 Matsushita Electric Ind Co Ltd サービス提供システム及び通信端末装置
ATE428278T1 (de) 2004-06-17 2009-04-15 Ericsson Telefon Ab L M Sicherheit in mobilen kommunikationssystemen
US20060074600A1 (en) 2004-09-15 2006-04-06 Sastry Manoj R Method for providing integrity measurements with their respective time stamps
US7653819B2 (en) * 2004-10-01 2010-01-26 Lenovo Singapore Pte Ltd. Scalable paging of platform configuration registers
JP4544956B2 (ja) * 2004-10-06 2010-09-15 株式会社エヌ・ティ・ティ・データ アクセス制御システム、クライアント端末装置、及びプログラム
US8266676B2 (en) 2004-11-29 2012-09-11 Harris Corporation Method to verify the integrity of components on a trusted platform using integrity database services
US7818585B2 (en) 2004-12-22 2010-10-19 Sap Aktiengesellschaft Secure license management
US8024488B2 (en) * 2005-03-02 2011-09-20 Cisco Technology, Inc. Methods and apparatus to validate configuration of computerized devices
US7809366B2 (en) * 2005-03-21 2010-10-05 Hewlett-Packard Development Company, L.P. Mobile device client
JP4293155B2 (ja) 2005-03-31 2009-07-08 サクサ株式会社 コードレス電話機
US7908483B2 (en) * 2005-06-30 2011-03-15 Intel Corporation Method and apparatus for binding TPM keys to execution entities
US7707480B2 (en) 2005-07-01 2010-04-27 Qnx Software Systems Gmbh & Co. Kg System employing data verification operations of differing computational costs
US20070050678A1 (en) 2005-08-25 2007-03-01 Motorola, Inc. Apparatus for self-diagnosis and treatment of critical software flaws
JP4093494B2 (ja) * 2005-09-08 2008-06-04 インターナショナル・ビジネス・マシーンズ・コーポレーション 秘密情報へのアクセスを制御するシステムおよびその方法
CN1933651B (zh) 2005-09-12 2010-05-12 北京三星通信技术研究有限公司 Lte系统中的会话接入方法
CN1933657B (zh) * 2005-09-15 2010-10-06 华为技术有限公司 一种在rsa认证过程中抵抗冒充合法移动台实施攻击的方法
JP4708143B2 (ja) 2005-09-30 2011-06-22 シスメックス株式会社 自動顕微鏡及びこれを備える分析装置
KR100711722B1 (ko) * 2005-10-04 2007-04-25 엘지전자 주식회사 이동통신 단말기의 소프트웨어 인증 장치 및 그 방법
GB0520254D0 (en) 2005-10-05 2005-11-16 Vodafone Plc Telecommunications networks
JP2009518762A (ja) * 2005-12-09 2009-05-07 シグナサート， インコーポレイテッド インテグリティデータベースサービスを用いた、トラステッドプラットフォーム上のコンポーンテントのインテグリティの検証方法
US20110179477A1 (en) * 2005-12-09 2011-07-21 Harris Corporation System including property-based weighted trust score application tokens for access control and related methods
US8413209B2 (en) 2006-03-27 2013-04-02 Telecom Italia S.P.A. System for enforcing security policies on mobile communications devices
US7930733B1 (en) * 2006-04-10 2011-04-19 At&T Intellectual Property Ii, L.P. Method and system for execution monitor-based trusted computing
US8108668B2 (en) * 2006-06-26 2012-01-31 Intel Corporation Associating a multi-context trusted platform module with distributed platforms
EP2044548A2 (en) 2006-06-30 2009-04-08 International Business Machines Corporation Message handling at a mobile device
US7827397B2 (en) * 2006-07-13 2010-11-02 Aristocrat Technologies Australia Pty, Ltd. Gaming machine having a secure boot chain and method of use
US20080076425A1 (en) 2006-09-22 2008-03-27 Amit Khetawat Method and apparatus for resource management
US7617423B2 (en) 2006-08-14 2009-11-10 Kyocera Corporation System and method for detecting, reporting, and repairing of software defects for a wireless device
US7711960B2 (en) * 2006-08-29 2010-05-04 Intel Corporation Mechanisms to control access to cryptographic keys and to attest to the approved configurations of computer platforms
US20080076419A1 (en) 2006-09-22 2008-03-27 Amit Khetawat Method and apparatus for discovery
TWI599259B (zh) 2006-12-27 2017-09-11 無線創新信號信託公司 基地台自行配置方法及裝置
US8526953B2 (en) 2007-03-12 2013-09-03 Nokia Corporation Apparatus, method and computer program product providing auxiliary handover command
EP1983771B1 (en) 2007-04-17 2011-04-06 Alcatel Lucent A method for interfacing a Femto-Cell equipment with a mobile core network
CN100583768C (zh) 2007-04-27 2010-01-20 中国科学院软件研究所 基于安全需求的远程证明方法及其系统
US8528058B2 (en) 2007-05-31 2013-09-03 Microsoft Corporation Native use of web service protocols and claims in server authentication
WO2008156782A2 (en) 2007-06-19 2008-12-24 Sand Holdings, Llc Devices and methods for automatic reset of monitored network network equipment
WO2009001433A1 (ja) * 2007-06-25 2008-12-31 Panasonic Corporation 無線通信ユニット及び携帯端末装置、並びに無線認証制御方法
US7853804B2 (en) * 2007-09-10 2010-12-14 Lenovo (Singapore) Pte. Ltd. System and method for secure data disposal
US20090149200A1 (en) * 2007-12-10 2009-06-11 Symbol Technologies, Inc. System and method for device or system location optimization
KR101731200B1 (ko) 2008-01-18 2017-05-11 인터디지탈 패튼 홀딩스, 인크 Ｍ2ｍ 통신을 인에이블하는 방법 및 장치
US8832454B2 (en) * 2008-12-30 2014-09-09 Intel Corporation Apparatus and method for runtime integrity verification
KR101691603B1 (ko) 2009-03-05 2016-12-30 인터디지탈 패튼 홀딩스, 인크 Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치
JP2012520027A (ja) 2009-03-06 2012-08-30 インターデイジタル パテント ホールディングス インコーポレイテッド 無線装置のプラットフォームの検証と管理
EP2288195B1 (en) 2009-08-20 2019-10-23 Samsung Electronics Co., Ltd. Method and apparatus for operating a base station in a wireless communication system
US8914674B2 (en) 2010-11-05 2014-12-16 Interdigital Patent Holdings, Inc. Device validation, distress indication, and remediation

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11121866B2 (en) * 2018-04-27 2021-09-14 Airbus Ds Slc Method for configuring access to fallback communication services and associated system

Also Published As

Publication number Publication date
WO2010102222A2 (en) 2010-09-10
TW201616881A (zh) 2016-05-01
KR20160037243A (ko) 2016-04-05
JP2017153101A (ja) 2017-08-31
KR20170001737A (ko) 2017-01-04
JP2014096830A (ja) 2014-05-22
KR101649465B1 (ko) 2016-08-19
BRPI1006524A2 (pt) 2016-02-10
CN104918252A (zh) 2015-09-16
JP5785277B2 (ja) 2015-09-24
KR20120036350A (ko) 2012-04-17
TW201728196A (zh) 2017-08-01
CN102342141A (zh) 2012-02-01
KR20170086140A (ko) 2017-07-25
KR101607363B1 (ko) 2016-03-29
KR101760451B1 (ko) 2017-07-24
TWI531254B (zh) 2016-04-21
US20180159738A1 (en) 2018-06-07
JP2012520024A (ja) 2012-08-30
JP2015213373A (ja) 2015-11-26
TW201130331A (en) 2011-09-01
US9253643B2 (en) 2016-02-02
US20110041003A1 (en) 2011-02-17
US20160226710A1 (en) 2016-08-04
EP2404460A2 (en) 2012-01-11
AR076087A1 (es) 2011-05-18
RU2011140357A (ru) 2013-04-10
TWI580285B (zh) 2017-04-21
KR20160100410A (ko) 2016-08-23
KR101691603B1 (ko) 2016-12-30
EP2966888A1 (en) 2016-01-13
WO2010102222A3 (en) 2010-10-28
JP5453461B2 (ja) 2014-03-26

Similar Documents

Publication Publication Date Title
KR101691603B1 (ko) Ｈ(ｅ)ＮＢ 무결성 검증 및 확인을 위한 방법 및 장치
US11824643B2 (en) Security lifecycle management of devices in a communications network
US9924366B2 (en) Platform validation and management of wireless devices
El Jaouhari et al. Secure firmware Over-The-Air updates for IoT: Survey, challenges, and discussions

Legal Events

Date Code Title Description
A201 Request for examination
A107 Divisional application of patent
E902 Notification of reason for refusal
E601 Decision to refuse application