KR101703925B1 - 장치 유효성 확인, 재난 표시, 및 복원 - Google Patents

장치 유효성 확인, 재난 표시, 및 복원 Download PDF

Info

Publication number
KR101703925B1
KR101703925B1 KR1020147014163A KR20147014163A KR101703925B1 KR 101703925 B1 KR101703925 B1 KR 101703925B1 KR 1020147014163 A KR1020147014163 A KR 1020147014163A KR 20147014163 A KR20147014163 A KR 20147014163A KR 101703925 B1 KR101703925 B1 KR 101703925B1
Authority
KR
South Korea
Prior art keywords
component
integrity
network
code
trv
Prior art date
Application number
KR1020147014163A
Other languages
English (en)
Other versions
KR20140079865A (ko
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 KR20140079865A publication Critical patent/KR20140079865A/ko
Application granted granted Critical
Publication of KR101703925B1 publication Critical patent/KR101703925B1/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00Testing or monitoring of control systems or parts thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079Root cause analysis, i.e. error or fault diagnosis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793Remedial or corrective actions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575Secure boot
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/24Arrangements for testing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10Integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30Security of mobile devices; Security of mobile applications
    • H04W12/35Protecting application or service provisioning, e.g. securing SIM application provisioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • H04W24/02Arrangements for optimising operational condition
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/22Processing or transfer of terminal data, e.g. status or physical capabilities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103Challenge-response
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2111Location-sensitive, e.g. geographical location, GPS

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Quality & Reliability (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Databases & Information Systems (AREA)
  • Automation & Control Theory (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

무선 통신 장치는 복원을 위해 무선 네트워크 장치 상의 실패한 컴포넌트의 일부분을 격리시키기 위해 네트워크 엔터티에 의한 무결성 검사 및 조사를 수행하도록 구성될 수 있다. 장치의 컴포넌트에 대해 무결성 실패가 결정되면, 장치는 그 컴포넌트와 연관되어 있는 기능을 식별하고 실패한 기능을 네트워크 엔터티에 알려줄 수 있다. 무선 네트워크 장치 및 네트워크 엔터티 둘 다는 컴포넌트-기능간 맵을 사용하여 실패한 기능 및/또는 실패한 컴포넌트를 식별할 수 있다. 장치에서 무결성 실패의 표시를 수신한 후에, 네트워크 엔터티는 실패한 컴포넌트 상의 무결성 검사의 범위를 좁히기 위해 장치에서 무결성 검사의 하나 이상의 부가의 반복이 수행될 수 있는 것으로 결정할 수 있다. 무결성 실패가 격리되면, 네트워크 엔터티는 무선 통신 장치 상의 실패한 컴포넌트의 일부분을 복원할 수 있다.

Description

장치 유효성 확인, 재난 표시, 및 복원{DEVICE VALIDATION, DISTRESS INDICATION, AND REMEDIATION}
관련 출원의 상호 참조
이 출원은 미국 가특허 출원 제61/410,781호(2010년 11월 5일자로 출원됨)에 기초하여 우선권을 주장하며, 이 출원의 내용은 참조 문헌으로서 그 전체가 본 명세서에 포함된다.
무선 통신 시스템은 시스템 내의 무선 통신 장치 상에서 무결성 검사 및/또는 무결성 실패의 치유를 수행하기 위해 불필요한 자원을 사용할 수 있다. 현재의 무결성 검사는 무선 통신 장치의 무결성이 손상되었는지를 결정하기 위해 대규모 모놀리딕 코드 블록에 대해 수행될 수 있다. 예를 들어, 무선 통신 장치 상에서 무결성 검사를 통해 불법 수정, 변조 및/또는 손상된 소프트웨어가 검출될 수 있다. 대규모 코드 블록에 대해 무결성 실패가 결정되면, 네트워크는 실패를 치유하기 위해 대규모 모놀리딕 블록의 형태로 무선 통신 장치로 업데이트를 다운로드할 수 있다. 이것은 불필요한 대역폭을 필요로 하고 시스템에 불필요한 계산 부담을 부가할 수 있다.
그에 부가하여, 각각이 다양한 형태의 소프트웨어 및 하드웨어를 가지는 다수의 유형 및/또는 모델의 무선 통신 장치가 네트워크와 또는 네트워크를 통해 통신하는 데 사용될 수 있다. 이들 다양한 장치는 무선 통신 장치 상의 실패한 컴포넌트(failed component)를 보고하는 것을 표준화하는 것을 어렵게 만들 수 있는데, 그 이유는 하드웨어 및 소프트웨어 개발 실무가 회사마다 상이할 수 있기 때문이다.
이 요약은 이하에서 상세한 설명에 추가로 기술되어 있는 다양한 개념들을 간략화된 형태로 소개하기 위해 제공된다.
무선 통신 장치의 하나 이상의 컴포넌트의 무결성 검사를 수행하는 시스템, 방법 및 장치 실시예가 본 명세서에 기술되어 있다. 본 명세서에 기술된 바와 같이, 무선 통신 장치와 연관된 컴포넌트에 대해 제1 무결성 검사가 수행될 수 있다. 그 컴포넌트가 제1 무결성 검사에 실패한 것으로 결정될 수 있다. 실패한 컴포넌트에 대응하는 기능의 표시가 네트워크 엔터티로 송신될 수 있다. 실패한 컴포넌트가 제1 무결성 검사에 실패하게 한 실패한 컴포넌트의 일부분을 결정하기 위해 실패한 컴포넌트에 대해 제2 무결성 검사를 수행하라는 요청이 네트워크 엔터티로부터 수신될 수 있다. 네트워크 엔터티에 의한 복원을 위해 실패한 컴포넌트의 일부분을 격리시키기 위해 제2 무결성 검사가 실패한 컴포넌트에 대해 수행될 수 있다.
예시적인 실시예에 따르면, 로더(loader)가 무선 통신 장치와 연관된 컴포넌트에 대해 제1 무결성 검사를 수행하도록 구성될 수 있다. 로더가 또한 컴포넌트가 제1 무결성 검사에 실패한 것으로 결정하고 네트워크 엔터티에 의한 복원을 위해 실패한 컴포넌트의 일부분을 격리시키기 위해 실패한 컴포넌트에 대해 제2 무결성 검사를 수행하도록 구성될 수 있다.
예시적인 실시예에 따르면, PIPE(platform integrity policy engine, 플랫폼 무결성 정책 엔진)가 로더로부터 실패한 컴포넌트의 표시를 수신하고 실패한 컴포넌트에 대응하는 네트워크 기능을 수신하도록 구성될 수 있다. PIPE는 또한 실패한 컴포넌트에 대응하는 기능의 표시를 네트워크 엔터티에 보고하고 실패한 컴포넌트의 일부분이 컴포넌트로 하여금 제1 무결성 검사에 실패하게 한 것으로 결정하기 위해 실패한 컴포넌트에 대해 제2 무결성 검사를 수행하라는 요청을 네트워크 엔터티로부터 수신하도록 구성될 수 있다.
예시적인 실시예에 따르면, 장치 복원 서버가 본 명세서에 기술되어 있을 수 있다. 장치 복원 서버는 무선 통신 네트워크에 존재할 수 있고, 무선 통신 장치 상의 무결성 검사에 실패한 컴포넌트의 일부분을 복원하도록 구성되어 있을 수 있다. 예를 들어, 장치 복원 서버는 무선 통신 장치에 대한 무결성 검사의 실패한 컴포넌트와 연관된 네트워크 기능의 표시를 무선 통신 장치로부터 수신하도록 구성되어 있을 수 있다. 실패한 컴포넌트가 네트워크 기능의 수신된 표시에 기초하여 결정될 수 있다. 장치 복원 서버는 또한 복원을 위해 실패한 컴포넌트의 일부분을 격리시키기 위해 무선 통신 장치에 대한 문의(interrogation)를 수행하도록 구성되어 있을 수 있다. 장치 복원 서버는 또한 하나 이상의 기준에 기초하여 무선 통신 장치로 송신될 실패한 컴포넌트의 일부분에 대한 수리 또는 교체를 결정하도록 구성되어 있을 수 있다. 기준에 기초하여 결정되면, 장치 복원 서버는 실패한 컴포넌트의 일부분에 대한 수리 또는 교체를 무선 통신 장치로 송신할 수 있다. 실패한 컴포넌트에 대한 수리 또는 교체를 결정하기 위해 각종의 상이한 기준이 사용될 수 있다. 예를 들어, 기준이 실패한 컴포넌트의 크기 또는 어떤 다른 인자에 기초할 수 있다. 예시적인 실시예에서, 복원 서버는 OS 소프트웨어 버전에 기초하여 특정의 컴포넌트를 교체할 수 있다. 다른 예시적인 기준은 버전 번호; 장치/컴포넌트/코드 부분별 마지막 업데이트의 날짜/시간 또는 성공적인 복원; 코드 또는 컴포넌트의 소유권; 코드 라이선스의 상태(예컨대, 디지털 저작권 관리); 실패한 컴포넌트, 비트 또는 바이트의 수; 실패한 코드 부분의 크기; 및 코드 부분 또는 컴포넌트의 할당된 또는 계산된 위험 또는 손상 영향값(damage impact value)을 포함하지만, 이들로 제한되지 않는다.
이 요약은 이하에서 상세한 설명에 추가로 기술되어 있는 일련의 개념들을 간략화된 형태로 소개하기 위해 제공된다. 이 요약은 청구된 발명 요지의 주요 특징 또는 필수적인 특징을 확인하기 위한 것도 아니고, 청구된 발명 요지의 범위를 제한하기 위해 사용되기 위한 것도 아니다. 게다가, 청구된 발명 요지는 본 개시 내용의 임의의 부분에 열거된 임의의 또는 모든 단점을 해결하는 것으로 제한되지 않는다.
일례로서 첨부 도면과 관련하여 주어진 이하의 설명으로부터 보다 상세하게 이해할 수 있다.
도 1a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 통신 시스템을 나타낸 도면.
도 1b는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 무선 송수신 유닛을 나타낸 도면.
도 1c는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 시스템 무선 액세스 네트워크를 나타낸 도면.
도 2는 무선 통신 장치에서의 부트 시퀀스(boot sequence)의 예시적인 실시예를 나타낸 도면.
도 3은 오브젝트 파일(object file)과 실행가능 이미지(executable image) 간의 링킹(linking)을 나타낸 도면.
도 4는 오브젝트 파일과 실행가능 이미지 간의 링킹을 나타낸 다른 도면.
도 5는 파일의 컴포넌트 TRV 섹션(component TRV section)의 예를 나타낸 도면.
도 6은 컴포넌트와 네트워크 기능 간의 매핑을 나타낸 도면.
도 7은 파일의 컴포넌트-기능간 매핑 섹션의 예를 나타낸 도면.
도 8은 부트 시퀀스에서 사용되는 정책 및 기능의 플랫폼 활성화(platform bring-up)를 나타낸 도면.
도 9는 무결성 검사 및/또는 보고 동안 본 명세서에 기술되어 있는 테이블 또는 맵의 사용을 나타낸 도면.
도 10은 본 명세서에 기술되어 있는 보고 및 복원 프로세스의 예시적인 개요를 나타낸 도면.
도 11은 수행될 수 있는 동작을 결정하기 위해 장치에서 정보를 수집하는 예시적인 호 흐름도.
도 12는 장치와 네트워크 엔터티 간의 조사를 위한 예시적인 호 흐름도.
도 13은 무선 통신 장치의 컴포넌트에 대해 수행되는 조사의 예를 나타낸 도면.
도 14는 무선 통신 장치의 컴포넌트에 대해 수행되는 조사의 다른 예를 나타낸 도면.
도 15는 재난 경보(distress alarm) 및 모놀리딕 코드 교체(monolithic code replacement)에 관련된 예시적인 호 흐름도.
도 16은 원격 소프트웨어 재난/복원(remote software distress/remediation)에 관련된 예시적인 호 흐름도.
도 17은 SeGW 인증 시도를 갖는, 원격 소프트웨어 재난/복원에 관련된 예시적인 호 흐름도.
도 18a는 네트워크가 SeGW를 통해 인증을 허용하지 않을 수 있는, 원격 소프트웨어 재난/복원에 관련된 예시적인 호 흐름도.
도 18b는 즉각적인 제한된 액세스(immediate limited access) 및 미세 조정된 액세스 제어(refined access control)를 갖는, 원격 소프트웨어 재난/복원에 관련된 예시적인 호 흐름도.
도 19는 SeGW 액세스를 무선 통신 장치 소프트웨어 컴포넌트 복원에 관련된 예시적인 호 흐름도.
도 20은 기능의 중계 노드 부트스트랩(relay node bootstrapping)에 관련된 예시적인 호 흐름도.
도 21은 인증된 관리 기능에 의한 중계 노드 복원(relay node remediation)에 관련된 예시적인 호 흐름도.
도 22는 기능 컴포넌트 및 코드/데이터 저장 컴포넌트의 예시적인 시스템을 나타낸 도면.
도 23은 부트 시퀀스의 스테이지들 및 각각의 스테이지에서 구현되는 다양한 엔터티들 간의 상호작용의 예시적인 실시예를 나타낸 도면.
도 24a는 TRV를 생성하기 위해 선형적으로 결합되는 측정들의 시퀀스를 나타낸 도면.
도 24b는 TRV를 생성하기 위해 Merkle 해쉬 트리를 사용한 값들의 결합을 나타낸 도면.
도 1a 내지 도 24b는 개시된 시스템, 방법 및 수단이 구현될 수 있는 예시적인 실시예에 관한 것이다. 본 명세서에 기술되어 있는 실시예는 제한하는 것이 아니라 예시적인 것으로 보아야 한다. 프로토콜 흐름이 본 명세서에 예시되고 기술되어 있지만, 흐름의 순서가 변화될 수 있고, 일부분이 생략될 수 있으며 및/또는 부가의 흐름이 추가될 수 있다.
도 1a, 도 1b 및 도 1c는 본 명세서에 기술되어 있는 실시예에서 사용될 수 있는 예시적인 통신 시스템 및 장치를 나타낸 것이다. 도 1a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 통신 시스템(100)의 도면이다. 통신 시스템(100)은 음성, 데이터, 비디오, 메시징, 방송 등과 같은 콘텐츠를 다수의 무선 사용자에게 제공하는 다중 접속 시스템일 수 있다. 통신 시스템(100)은 다수의 무선 사용자가 시스템 자원(무선 대역폭을 포함함)의 공유를 통해 이러한 콘텐츠에 액세스할 수 있게 해줄 수 있다. 예를 들어, 통신 시스템(100)은 CDMA(code division multiple access, 코드 분할 다중 접속), TDMA(time division multiple access, 시분할 다중 접속), FDMA(frequency division multiple access, 주파수 분할 다중 접속), OFDMA(orthogonal FDMA, 직교 FDMA), SC-FDMA(single-carrier FDMA, 단일 반송파 FDMA) 등과 같은 하나 이상의 채널 접속 방법을 이용할 수 있다.
도 1a에 도시된 바와 같이, 통신 시스템(100)은 WTRU(wireless transmit/receive unit, 무선 송수신 장치)(102a, 102b, 102c, 102d), RAN(radio access network, 무선 액세스 네트워크)(104), 코어 네트워크(106), PSTN(public switched telephone network, 공중 교환 전화망)(108), 인터넷(110), 및 기타 네트워크(112)를 포함할 수 있지만, 개시된 실시예가 임의의 수의 WTRU, 기지국, 네트워크 및/또는 네트워크 요소를 생각하고 있다는 것을 잘 알 것이다. WTRU(102a, 102b, 102c, 102d) 각각은 무선 환경에서 동작하고 및/또는 통신하도록 구성되어 있는 임의의 유형의 장치일 수 있다. 일례로서, WTRU(102a, 102b, 102c, 102d)는 무선 신호를 전송 및/또는 수신하도록 구성될 수 있고, UE(user equipment), 이동국, 고정형 또는 이동형 가입자 장치, 페이저, 휴대폰, PDA(personal digital assistant), 스마트폰, 랩톱, 넷북, 개인용 컴퓨터, 무선 센서, 가전 제품 등을 포함할 수 있다.
통신 시스템(100)은 또한 기지국(114a) 및 기지국(114b)을 포함할 수 있다. 기지국(114a, 114b) 각각은 하나 이상의 통신 네트워크 - 코어 네트워크(106), 인터넷(110) 및/또는 네트워크(112) 등 - 에의 액세스를 용이하게 해주기 위해 WTRU(102a, 102b, 102c, 102d) 중 적어도 하나와 무선으로 인터페이스하도록 구성되어 있는 임의의 유형의 장치일 수 있다. 일례로서, 기지국(114a, 114b)은 BTS(base transceiver station, 기지국 송수신기), 노드-B, eNode B, 홈 노드 B, 사이트 제어기, AP(access point), 무선 라우터 등일 수 있다. 기지국(114a, 114b) 각각이 단일 요소로서 나타내어져 있지만, 기지국(114a, 114b)이 임의의 수의 상호연결된 기지국 및/또는 네트워크 요소를 포함할 수 있다는 것을 잘 알 것이다.
기지국(114a)은 다른 기지국 및/또는 네트워크 요소 - BSC(base station controller, 기지국 제어기), RNC(radio network controller, 무선 네트워크 제어기), 중계 노드, 기타 등등 - (도시 생략)도 포함할 수 있는 RAN(104)의 일부일 수 있다. 기지국(114a) 및/또는 기지국(114b)은 특정의 지리적 지역 - 셀(도시 생략)이라고 할 수 있음 - 내에서 무선 신호를 전송 및/또는 수신하도록 구성될 수 있다. 셀은 여러 셀 섹터(cell sector)로 추가로 나누어질 수 있다. 예를 들어, 기지국(114a)과 연관된 셀이 3개의 섹터로 나누어질 수 있다. 따라서, 일 실시예에서 기지국(114a)은 3개의 송수신기(즉, 셀의 각각의 섹터마다 하나씩)를 포함할 수 있다. 다른 실시예에서, 기지국(114a)은 MIMO(multiple-input multiple output, 다중 입력 다중 출력) 기술을 이용할 수 있고, 따라서, 셀의 각각의 섹터에 대해 다수의 송수신기를 이용할 수 있다.
기지국(114a, 114b)은 임의의 적당한 무선 통신 링크[예컨대, RF(radio frequency, 무선 주파수), 마이크로파, IR(infrared, 적외선), UV(ultraviolet, 자외선), 가시광 등]일 수 있는 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c, 102d) 중 하나 이상과 통신할 수 있다. 임의의 적당한 RAT(radio access technology, 무선 액세스 기술)를 사용하여 공중 인터페이스(116)가 설정될 수 있다.
보다 구체적으로는, 앞서 살펴본 바와 같이, 통신 시스템(100)은 다중 접속 시스템일 수 있고, CDMA, TDMA, FDMA, OFDMA, SC-FDMA 등과 같은 하나 이상의 채널 접속 방식을 이용할 수 있다. 예를 들어, RAN(104) 내의 기지국(114a) 및 WTRU(102a, 102b, 102c)는 WCDMA(wideband CDMA, 광대역 CDMA)를 사용하여 공중 인터페이스(116)를 설정할 수 있는 UTRA[UMTS(Universal Mobile Telecommunications System) Terrestrial Radio Access]와 같은 무선 기술을 구현할 수 있다. WCDMA는 HSPA(High-Speed Packet Access, 고속 패킷 액세스) 및/또는 HSPA+(Evolved HSPA)와 같은 통신 프로토콜을 포함할 수 있다. HSPA는 HSDPA(High-Speed Downlink Packet Access, 고속 하향링크 패킷 액세스) 및/또는 HSUPA(High-Speed Uplink Packet Access, 고속 상향링크 패킷 액세스)를 포함할 수 있다.
다른 실시예에서, 기지국(114a) 및 WTRU(102a, 102b, 102c)는 LTE(Long Term Evolution) 및/또는 LTE-A(LTE-Advanced)를 사용하여 공중 인터페이스(116)를 설정할 수 있는 E-UTRA(Evolved UMTS Terrestrial Radio Access)와 같은 무선 기술을 구현할 수 있다.
다른 실시예에서, 기지국(114a) 및 WTRU(102a, 102b, 102c)는 IEEE 802.16[즉, WiMAX(Worldwide Interoperability for Microwave Access)], CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, IS-2000(Interim Standard 2000), IS-95(Interim Standard 95), IS-856(Interim Standard 856), GSM(Global System for Mobile communications), EDGE(Enhanced Data rates for GSM Evolution), GSM EDGE(GERAN) 등과 같은 무선 기술을 구현할 수 있다.
도 1a의 기지국(114b)은, 예를 들어, 무선 라우터, 홈 노드 B, 홈 eNode B, 또는 액세스 포인트(access point)일 수 있고, 사업장, 가정, 차량, 캠퍼스 등과 같은 국소화된 지역에서의 무선 연결을 용이하게 해주는 임의의 적당한 RAT를 이용할 수 있다. 일 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 WLAN(wireless local area network, 무선 근거리 통신망)을 설정하기 위해 IEEE 802.11과 같은 무선 기술을 구현할 수 있다. 다른 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 WPAN(wireless personal area network, 무선 개인 영역 네트워크)을 설정하기 위해 IEEE 802.15와 같은 무선 기술을 구현할 수 있다. 또 다른 실시예에서, 기지국(114b) 및 WTRU(102c, 102d)는 피코셀(picocell) 또는 펨토셀(femtocell)을 설정하기 위해 셀룰러-기반 RAT(예컨대, WCDMA, CDMA2000, GSM, LTE, LTE-A 등)를 이용할 수 있다. 도 1a에 도시된 바와 같이, 기지국(114b)은 인터넷(110)에의 직접 연결을 가질 수 있다. 따라서, 기지국(114b)은 코어 네트워크(106)를 통해 인터넷(110)에 액세스할 필요가 없을 수 있다.
RAN(104)은 음성, 데이터, 응용 프로그램, 및 VoIP(voice over internet protocol) 서비스를 WTRU(102a, 102b, 102c, 102d) 중 하나 이상의 WTRU에 제공하도록 구성되어 있는 임의의 유형의 네트워크일 수 있는 코어 네트워크(106)와 통신하고 있다. 예를 들어, 코어 네트워크(106)는 호출 제어, 대금 청구 서비스, 모바일 위치-기반 서비스, 선불 전화(pre-paid calling), 인터넷 연결, 비디오 배포 등을 제공하고 및/또는 사용자 인증과 같은 고수준 보안 기능을 수행할 수 있다. 도 1a에 도시되어 있지는 않지만, RAN(104) 및/또는 코어 네트워크(106)가 RAN(104)과 동일한 RAT 또는 상이한 RAT를 이용하는 다른 RAN과 직접 또는 간접 통신을 하고 있을 수 있다는 것을 잘 알 것이다. 예를 들어, E-UTRA 무선 기술을 이용하고 있을 수 있는 RAN(104)에 연결되는 것에 부가하여, 코어 네트워크(106)는 또한 GSM 무선 기술을 이용하는 다른 RAN(도시 생략)과 통신하고 있을 수 있다.
코어 네트워크(106)는 또한 WTRU(102a, 102b, 102c, 102d)가 PSTN(108), 인터넷(110) 및/또는 기타 네트워크(112)에 액세스하기 위한 게이트웨이로서 역할할 수 있다. PSTN(108)은 POTS(plain old telephone service)를 제공하는 회선-교환 전화 네트워크를 포함할 수 있다. 인터넷(110)은 TCP/IP 인터넷 프로토콜군 내의 TCP(transmission control protocol, 전송 제어 프로토콜), UDP(user datagram protocol, 사용자 데이터그램 프로토콜) 및 IP(internet protocol, 인터넷 프로토콜)와 같은 공통의 통신 프로토콜을 사용하는 상호연결된 컴퓨터 네트워크 및 장치의 전세계 시스템을 포함할 수 있다. 네트워크(112)는 다른 서비스 공급자가 소유하고 및/또는 운영하는 유선 또는 무선 통신 네트워크를 포함할 수 있다. 예를 들어, 네트워크(112)는 RAN(104)과 동일한 RAT 또는 상이한 RAT를 이용할 수 있는 하나 이상의 RAN에 연결된 다른 코어 네트워크를 포함할 수 있다.
통신 시스템(100) 내의 WTRU(102a, 102b, 102c, 102d) 중 일부 또는 전부는 다중-모드 기능을 포함할 수 있다 - 즉, WTRU(102a, 102b, 102c, 102d)가 상이한 무선 링크를 통해 상이한 무선 네트워크와 통신하기 위한 다수의 송수신기를 포함할 수 있다 -. 예를 들어, 도 1a에 도시된 WTRU(102c)는 셀룰러-기반 무선 기술을 이용할 수 있는 기지국(114a)과 통신하도록, 그리고 IEEE 802 무선 기술을 이용할 수 있는 기지국(114b)과 통신하도록 구성될 수 있다.
도 1b는 예시적인 WTRU(102)의 시스템도이다. 도 1b에 도시된 바와 같이, WTRU(102)는 프로세서(118), 송수신기(120), 송신/수신 요소(122), 스피커/마이크(124), 키패드(126), 디스플레이/터치패드(128), 비이동식 메모리(130), 이동식 메모리(132), 전원 공급 장치(134), GPS(global positioning system) 칩셋(136), 및 기타 주변 장치(138)를 포함할 수 있다. 실시예와 부합한 채로 있으면서 WTRU(102)가 상기한 요소들의 임의의 서브컴비네이션을 포함할 수 있다는 것을 잘 알 것이다.
프로세서(118)가 범용 프로세서, 전용 프로세서, 종래의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서, DSP 코어와 연관된 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, ASIC(Application Specific Integrated Circuit), FPGA(Field Programmable Gate Array) 회로, 임의의 다른 유형의 IC(integrated circuit), 상태 기계 등일 수 있다. 프로세서(118)는 WTRU(102)가 무선 환경에서 동작할 수 있게 해주는 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 임의의 다른 기능을 수행할 수 있다. 프로세서(118)는 송신/수신 요소(122)에 결합되어 있을 수 있는 송수신기(120)에 결합될 수 있다. 도 1b가 프로세서(118) 및 송수신기(120)를 개별 구성요소로서 나타내고 있지만, 프로세서(118) 및 송수신기(120)가 전자 패키지 또는 칩에 함께 통합되어 있을 수 있다는 것을 잘 알 것이다.
송신/수신 요소(122)는 공중 인터페이스(116)를 통해 기지국[예컨대, 기지국(114a)]으로 신호를 전송하거나 기지국으로부터 신호를 수신하도록 구성될 수 있다. 예를 들어, 일 실시예에서, 송신/수신 요소(122)는 RF 신호를 전송 및/또는 수신하도록 구성된 안테나일 수 있다. 다른 실시예에서, 송신/수신 요소(122)는, 예를 들어, IR, UV 또는 가시광 신호를 전송 및/또는 수신하도록 구성되어 있는 방출기/검출기일 수 있다. 또 다른 실시예에서, 송신/수신 요소(122)는 RF 신호 및 광 신호 둘 다를 전송 및 수신하도록 구성될 수 있다. 송신/수신 요소(122)가 무선 신호의 임의의 조합을 전송 및/또는 수신하도록 구성될 수 있다는 것을 잘 알 것이다.
그에 부가하여, 송신/수신 요소(122)가 도 1b에 단일 요소로서 나타내어져 있지만, WTRU(102)는 임의의 수의 송신/수신 요소(122)를 포함할 수 있다. 보다 구체적으로는, WTRU(102)는 MIMO 기술을 이용할 수 있다. 따라서, 일 실시예에서, WTRU(102)는 공중 인터페이스(116)를 통해 무선 신호를 전송 및 수신하기 위한 2개 이상의 송신/수신 요소(122)(예컨대, 다수의 안테나)를 포함할 수 있다.
송수신기(120)는 송신/수신 요소(122)에 의해 전송되어야 하는 신호를 변조하고 송신/수신 요소(122)에 의해 수신되는 신호를 복조하도록 구성될 수 있다. 앞서 살펴본 바와 같이, WTRU(102)는 다중-모드 기능을 가질 수 있다. 따라서, 송수신기(120)는 WTRU(102)가, 예를 들어, UTRA 및 IEEE 802.11과 같은 다수의 RAT를 통해 통신할 수 있게 해주는 다수의 송수신기를 포함할 수 있다.
WTRU(102)의 프로세서(118)는 스피커/마이크(124), 키패드(126), 및/또는 디스플레이/터치패드(128)[예컨대, LCD(liquid crystal display, 액정 디스플레이) 디스플레이 유닛 또는 OLED(organic light-emitting diode, 유기 발광 다이오드) 디스플레이 유닛]에 결합될 수 있고 그로부터 사용자 입력 데이터를 수신할 수 있다. 프로세서(118)는 또한 사용자 데이터를 스피커/마이크(124), 키패드(126) 및/또는 디스플레이/터치패드(128)로 출력할 수 있다. 그에 부가하여, 프로세서(118)는 비이동식 메모리(130) 및/또는 이동식 메모리(132)와 같은 임의의 유형의 적당한 메모리로부터의 정보에 액세스하고 그 메모리에 데이터를 저장할 수 있다. 비이동식 메모리(130)는 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 하드 디스크, 임의의 다른 유형의 메모리 저장 장치를 포함할 수 있다. 이동식 메모리(132)는 SIM(subscriber identity module, 가입자 식별 모듈) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예에서, 프로세서(118)는 WTRU(102) 상에 물리적으로 위치하지 않은[예컨대, 서버 또는 가정용 컴퓨터(도시 생략) 상의] 메모리로부터의 정보에 액세스하고 그 메모리에 데이터를 저장할 수 있다.
프로세서(118)는 전원 공급 장치(134)로부터 전력을 받을 수 있고, WTRU(102) 내의 다른 구성요소로 전력을 분배하고 및/또는 전력을 제어하도록 구성될 수 있다. 전원 공급 장치(134)는 WTRU(102)에 전원을 제공하는 임의의 적당한 장치일 수 있다. 예를 들어, 전원 공급 장치(134)는 하나 이상의 건전지[예컨대, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 수소화금속(NiMH), 리튬-이온(Li-ion) 등], 태양 전지, 연료 전지 등을 포함할 수 있다.
프로세서(118)는 또한 WTRU(102)의 현재 위치에 관한 위치 정보(예컨대, 경도 및 위도)를 제공하도록 구성될 수 있는 GPS 칩셋(136)에 결합될 수 있다. GPS 칩셋(136)으로부터의 정보에 부가하여 또는 그 대신에, WTRU(102)는 기지국[예컨대, 기지국(114a, 114b)] 공중 인터페이스(116)를 통해 위치 정보를 수신하고 및/또는 2개 이상의 근방의 기지국으로부터 수신되는 신호의 타이밍에 기초하여 그의 위치를 결정할 수 있다. 실시예와 부합한 채로 있으면서 WTRU(102)가 임의의 적당한 위치 결정 방법에 의해 위치 정보를 획득할 수 있다는 것을 잘 알 것이다.
프로세서(118)는 또한 부가의 특징, 기능 및/또는 유선 또는 무선 연결을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있는 다른 주변 장치(138)에 결합될 수 있다. 예를 들어, 주변 장치(138)는 가속도계, 전자 나침반, 위성 송수신기, 디지털 카메라(사진 또는 비디오용), USB(universal serial bus) 포트, 진동 장치, 텔레비전 송수신기, 핸즈프리 헤드셋, 블루투스® 모듈, FM(frequency modulated, 주파수 변조) 라디오 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.
도 1c는 일 실시예에 따른, RAN(104) 및 코어 네트워크(106)의 시스템도이다. 앞서 살펴본 바와 같이, RAN(104)은 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c)와 통신하기 위해 E-UTRA 무선 기술을 이용할 수 있다. RAN(104)은 또한 코어 네트워크(106)와 통신하고 있을 수 있다.
RAN(104)은 eNode B(140a, 140b, 140c)를 포함할 수 있지만, 실시예와 부합한 채로 있으면서 RAN(104)이 임의의 수의 eNode B를 포함할 수 있다는 것을 잘 알 것이다. eNode B(140a, 140b, 140c) 각각은 공중 인터페이스(116)를 통해 WTRU(102a, 102b, 102c)와 통신하기 위한 하나 이상의 송수신기를 포함할 수 있다. 일 실시예에서, eNode B(140a, 140b, 140c)는 MIMO 기술을 구현할 수 있다. 따라서, 예를 들어, eNode B(140a)는 WTRU(102a)로 무선 신호를 전송하고 그로부터 무선 신호를 수신하기 위해 다수의 안테나를 사용할 수 있다.
eNode B(140a, 140b, 140c) 각각은 특정의 셀(도시 생략)과 연관되어 있을 수 있고, 무선 자원 관리 결정, 핸드오버 결정, 상향링크 및/또는 하향링크에서의 사용자의 스케줄링 등을 처리하도록 구성되어 있을 수 있다. 도 1c에 도시된 바와 같이, eNode B(140a, 140b, 140c)는 X2 인터페이스를 통해 서로 통신할 수 있다.
도 1c에 도시된 코어 네트워크(106)는 MME(mobility management gateway, 이동성 관리 게이트웨이)(142), SGW(serving gateway, 서비스 제공 게이트웨이)(144), 및 PDN(packet data network, 패킷 데이터 네트워크) 게이트웨이(146)를 포함할 수 있다. 상기 요소들 각각이 코어 네트워크(106)의 일부로서 나타내어져 있지만, 이들 요소 중 임의의 것이 코어 네트워크 운영자 이외의 엔터티에 의해 소유되고 및/또는 운영될 수 있다는 것을 잘 알 것이다.
MME(142)는 S1 인터페이스를 통해 RAN(104) 내의 eNode B(142a, 142b, 142c) 각각에 연결되어 있을 수 있고, 제어 노드로서 역할할 수 있다. 예를 들어, MME(142)는 WTRU(102a, 102b, 102c)의 사용자를 인증하는 것, 베어러 활성화/비활성화, WTRU(102a, 102b, 102c)의 초기 접속(initial attach) 동안 특정의 SGW(serving gateway)를 선택하는 것 등을 책임지고 있을 수 있다. MME(142)는 또한 RAN(104)과 GSM 또는 WCDMA와 같은 다른 무선 기술을 이용하는다른 RAN(도시 생략) 간에 전환하는 제어 평면 기능(control plane function)을 제공할 수 있다.
SGW(serving gateway)(144)는 S1 인터페이스를 통해 RAN(104) 내의 eNode B(140a, 140b, 140c) 각각에 연결될 수 있다. SGW(serving gateway)(144)는 일반적으로 WTRU(102a, 102b, 102c)로/로부터 사용자 데이터 패킷을 라우팅하고 전달할 수 있다. SGW(serving gateway)(144)는 eNode B간 핸드오버 동안 사용자 평면을 앵커링(anchoring)하는 것, WTRU(102a, 102b, 102c)에 대해 하향링크 데이터가 이용가능할 때 페이징(paging)을 트리거하는 것, WTRU(102a, 102b, 102c)의 컨텍스트를 관리하고 저장하는 것 등과 같은 다른 기능도 수행할 수 있다.
SGW(serving gateway)(144)는, WTRU(102a, 102b, 102c)와 IP-기반(IP-enabled) 장치 사이의 통신을 용이하게 해주기 위해, 인터넷(110)과 같은 패킷 교환 네트워크에의 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있는 PDN 게이트웨이(146)에도 연결될 수 있다.
코어 네트워크(106)는 다른 네트워크와의 통신을 용이하게 해줄 수 있다. 예를 들어, 코어 네트워크(106)는, WTRU(102a, 102b, 102c)와 종래의 지상선(land-line) 통신 장치 사이의 통신을 용이하게 해주기 위해, PSTN(108)과 같은 회선 교환 네트워크에의 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있다. 예를 들어, 코어 네트워크(106)는 코어 네트워크(106)와 PSTN(108) 사이의 인터페이스로서 역할하는 IP 게이트웨이[예컨대, IMS(IP multimedia subsystem, IP 멀티미디어 서브시스템) 서버]를 포함할 수 있거나 그와 통신할 수 있다. 그에 부가하여, 코어 네트워크(106)는 다른 서비스 공급자에 의해 소유되고 및/또는 운영되는 다른 유선 또는 무선 네트워크를 포함할 수 있는 네트워크(112)에의 액세스를 WTRU(102a, 102b, 102c)에 제공할 수 있다.
본 명세서에 기술되어 있는 통신 시스템 및 장치는 통신 장치의 소프트웨어를 관리하는 데, 통신 장치의 구성을 관리하는 데, 및/또는 장치를 원시 상태로 복구하기 위해 소프트웨어 및/또는 구성 정보의 복원을 제공하는 데 사용될 수 있다. 또한, 소프트웨어 도구, 네트워크 프로토콜, 장치 정책 및 소프트웨어 관리, 및/또는 원격 디버깅 기법의 사용함으로써 TCB(trusted code base, 신뢰성 있는 코드 베이스)의 소프트웨어 측면의 참조의 자동 발생 및 관리를 통해 증명가능한 보고 및 복원을 위한 메커니즘 및 참조를 장치에 임베딩할 수 있는 소프트웨어 개발 및 코드 배포(code release) 도구를 사용하는 구현예가 본 명세서에 기술되어 있다. 게다가, 실패를 보고하기 위해 장치가 신뢰성 있다는 표시의 설명을 비롯하여, 장치에 의한 무결성 검사의 실패의 표시를 보장해줄 수 있는 기법들이 본 명세서에 기술되어 있다.
본 명세서에 기술된 바와 같이, 무선 통신 장치는 다중 스테이지 안전 부트 프로세스(secure boot process)의 각각의 스테이지에서 무결성 검사를 수행하도록 구성될 수 있다. 다중 스테이지 안전 부트 프로세스 동안, 각각의 스테이지는 후속 스테이지를 검증할 수 있고, 그로써 신뢰 사슬을 생성한다. 다중 스테이지 안전 부트 프로세스의 각각의 스테이지 동안, 그 스테이지와 연관된 컴포넌트가 신뢰될 수 있는지의 결정이 행해질 수 있다. 컴포넌트와 연관되어 있는 무결성 측정이 결정될 수 있다. 컴포넌트는 연관되어 있는 신뢰성 있는 참조값을 가질 수 있다. 무결성 측정을 신뢰성 있는 참조값과 비교함으로써 컴포넌트의 신뢰성이 결정(예컨대, 테스트)될 수 있다. 무결성 측정이 신뢰성 있는 참조값과 일치하는 경우, 컴포넌트는 신뢰할 수 있는 것으로 생각될 수 있다. 무결성 측정이 신뢰성 있는 참조값과 일치하지 않는 경우, 컴포넌트는 신뢰할 수 없는 것일 수 있다. 무결성 측정을 신뢰성 있는 참조값과 비교함으로써 무결성 검사가 수행될 수 있는 것으로 본 명세서에 기술되어 있지만, 컴포넌트의 신뢰성을 결정하기 위해 무결성 검사가 다른 방식으로 수행될 수 있다는 것을 잘 알 것이다.
컴포넌트가 외부 엔터티에 의해 인식되지 않을 수 있기 때문에, 예를 들어, 표준 규격을 따르기 위해 및/또는 구현 독립적인 방식으로, 다수의 네트워크 및/또는 장치에 걸쳐 기능이 정의 및/또는 표준화될 수 있다. 컴포넌트는 기능에 관련되어 있을 수 있다. 컴포넌트와 기능 간의 관계가 컴포넌트-기능간 맵으로 주어질 수 있다. 실패한 컴포넌트를 컴포넌트-기능간 맵과 비교함으로써 기능 실패가 식별될 수 있다.
장치는 기능 실패와 연관된 경보를 외부 엔터티로 송신할 수 있다. 외부 엔터티는 실패한 컴포넌트를 수리 또는 교체하기 위해 사용될 수 있는 기능과 연관된 교체 코드(replacement code)를 결정할 수 있다. 즉, 교체 코드는 교체 컴포넌트(replacement component)일 수 있다. 장치는 교체 컴포넌트를 수신하고 실패한 컴포넌트를 교체 컴포넌트로 교체할 수 있다.
안전 부트 프로세스는 유효성 확인 절차에 대한 기반을 제공할 수 있다. 불변의 하드웨어 RoT(root of trust, 신뢰의 근원)에 의해 개시되는 신뢰 사슬은 로드된 초기 코드의 유효성을 검증할 수 있다. 예를 들어, 도 2에 예시된 바와 같이, 부트 프로세스가 계속될 수 있는데, 그 이유는 각각의 스테이지가 신뢰 사슬을 통해 후속 스테이지를 검증하기 때문이다.
전원 켜기 및 하드웨어 초기화 절차 이후에, 예를 들어, 도 2에 예시된 바와 같이, 장치는 안전 부트 프로세스를 개시할 수 있다. 초기 RoT는 ROM 내의 보안 메모리(secure memory)에 존재할 수 있는 부트 로더(boot loader)(202)로 나타내어질 수 있다. ROM 부트 로더(202)는 처음에 어떤 초기화 함수를 실행할 수 있다. ROM 부트 로더(202)는 (예컨대, 외부 메모리에 존재하는) 제2 스테이지 부트 로더(204)의 무결성을 검증하기 위해 사용할 수 있는 보안 자격 증명(security credential)(예컨대, 융합된 키 정보)에 액세스할 수 있다. 제2 스테이지 로더(204)는 그의 무결성을 보장하기 위해 하드웨어 또는 소프트웨어 암호 수단(cryptographic means)에 의해 검사될 수 있다. 제2 스테이지 로더(204)의 계산된 해쉬 측정이, 보안 자격 증명에 의해 서명되어 있고 외부 메모리에 저장되어 있을 수 있는 TRV(trusted reference value, 신뢰성 있는 참조값) 측정과 비교될 수 있다. 계산된 측정이 서명된 TRV와 일치하는 경우, 제2 스테이지 로더(204)가 검증되고 내부 메모리(예컨대, RAM)에 로드될 수 있다. 부트 ROM은 제2 스테이지 로더(204)의 시작으로 점프할 수 있고, 신뢰 사슬이 계속될 수 있다. 검증 프로세스의 초기 스테이지에서의 실패는 후속 검증이 손상될 수 있다는 것을 나타낼 수 있다(예컨대, 초기 스테이지에서의 실패는 신뢰 사슬의 치명적인 파괴를 나타낼 수 있다). 검증 프로세스의 초기 스테이지에서 실패가 표시되는 경우, 장치가 종료될 수 있다.
제2 스테이지 부트 로더(204)는, 부가의 코드를 검사하고 내부 메모리로 로드할 수 있는 코드와 함께, TrE(trusted execution environment, 신뢰성 있는 실행 환경) 코드를 포함할 수 있다. TrE는 부가의 무결성 참조값이 계산되고 저장될 수 있는 신뢰성 있는 환경(trusted environment) 및 보안 저장 영역을 설정할 수 있다. TrE 무결성은 운영 체제 및 통신 코드를 검사, 로드 및/또는 시작할 수 있다. 각각의 스테이지가 검사되고 로드되기 때문에, 신뢰 사슬이 계속될 수 있다[예컨대, 도 2에 예시된 상자(202, 204, 206 및 208) 각각은 스테이지를 나타낼 수 있음]. 예를 들어, 제2 스테이지 로더(204)는 OS/통신(206) 및/또는 장치 소프트웨어(208)의 무결성을 검증할 수 있다. 다른 대안으로서, 또는 그에 부가하여, OS/통신(206)은 장치 소프트웨어(208)의 무결성을 검증할 수 있다. OS/통신(206)은 OS 로더를 포함할 수 있다. 일 실시예에 따르면, 도 2에 예시된 엔터티가 신뢰 사슬을 유지하기 위해 실행 순서로 검증될 수 있고 및/또는 서로를 검증할 수 있다.
후속 프로세스를 안전하게 검증할 수 있는 실행 프로세스에 의해 신뢰 사슬이 유지될 수 있다. 검증 프로세스는 암호 계산 및/또는 신뢰성 있는 참조값 둘 다를 사용할 수 있다. 비보안 메모리(unsecure memory)에 존재하는 코드는 공격에 취약할 수 있고, 로드 이전에 검증될 수 있다. 세밀한 유효성 확인을 사용하지 않고, 제2 스테이지 부트 로더(204)는 벌크 측정(bulk measurement)으로서 나머지 코드를 검증할 수 있다. 측정된 값이 모놀리딕 블록에 대한 TRV와 일치하지 않는 경우, 코드가 신뢰되지 않을 수 있고 코드가 로드되지 않을 수 있다고 결정될 수 있다. 장치는 통신할 수 없을지도 모르고, 결과는 수리를 위해 다시 장치의 고비용 트럭롤(truck roll) 또는 수송(shipment)을 통한 전체 코드 베이스의 복원을 포함할 수 있다.
본 명세서에 기술되어 있는 방법, 시스템 및 수단은 장치가 저장된 코드의 보다 작은 컴포넌트를 유효성 확인하는 것은 물론, 어느 컴포넌트가 실패가 있고 어느 것이 원격적으로 복원될 수 있는지 또는 복원될 수 없는지에 대한 상세한 설명을 제공할 수 있게 해줄 수 있다. 이 세밀한 정보를 복원 관리자(remediation manager)가 이용가능하게 될 수 있다.
어느 실패한 컴포넌트가 원격 복원가능한지를 결정하는 정책이 설정될 수 있다. 예를 들어, 장치가 검사되고 최소한의 통신 코드 세트와 함께 TrE를 로드한 경우, 장치는 특정의 실패한 컴포넌트의 정보를 식별하고 복원 관리자에 보고하기 위해 복원 관리자에 대한 대용물로서 역할하는 기능을 유지할 수 있다. 복원 기능이 존재하고 장치의 대용물 기능의 일부인 경우, 후속하는 원격 복원 절차가 개시될 수 있고, 이는 고비용의 현장 직원 업데이트의 사용을 감소시킬 수 있다.
일 실시예에 따르면, 세밀한 보고를 가능하게 해주기 위해 실행가능 이미지가 분할되고 유효성 확인될 수 있다. 실행가능 이미지의 발생이 다수의 스테이지에서 일어날 수 있다. 컴포넌트는 서브루틴 및/또는 파라미터/데이터로 이루어져 있는 파일을 말하는 것일 수 있다. 개발자는 컴포넌트 소스 및 헤더 파일에 포착되어 있는 프로그램을 작성할 수 있다. 이들 컴포넌트 소스 파일로부터, 컴파일러 및 어셈블러는 기계 이진 코드(machine binary code) 및 프로그램 데이터 둘 다를 포함하는 오브젝트 파일(예컨대, *.o)을 생성할 수 있다. 링커(linker)는 이들 오브젝트 파일을 입력으로서 받아서, 다른 오브젝트 파일과의 부가적인 링킹을 위해 사용될 수 있는 실행가능 이미지 또는 오브젝트 파일을 생성할 수 있다. 링커 명령 파일(linker command file)은 오브젝트 파일을 어떻게 결합시키고 대상 임베디드 시스템(target embedded system)에서 이진 코드 및 데이터를 어디에 위치시키는지에 관해 링커에 지시할 수 있다.
링커의 기능은 다수의 오브젝트 파일을 보다 큰 재배치가능 오브젝트 파일, 공유 오브젝트 파일, 또는 최종 실행가능 이미지로 결합시키는 것일 수 있다. 전역 변수(global variable) 및 비정적 함수(non-static function)는 전역 심볼(global symbol)이라고 할 수 있다. 최종 실행가능 이진 이미지에서, 심볼은 메모리에서의 주소 위치(address location)를 말하는 것일 수 있다. 이 메모리 위치의 내용은 변수에 대한 데이터 또는 함수에 대한 실행가능 코드일 수 있다.
컴파일러는 컴파일러가 생성하는 오브젝트 파일의 일부로서 주소 매핑에 대한 심볼 이름을 갖는 심볼 테이블(symbol table)을 생성할 수 있다. 재배치가능한 출력을 생성할 때, 컴파일러는, 각각의 심볼에 대해, 컴파일되고 있는 파일에 상대적인 주소를 발생할 수 있다. 링커에 의해 수행되는 링킹 프로세스는 심볼 해석(symbol resolution) 및/또는 심볼 재배치(symbol relocation)를 포함할 수 있다. 심볼 해석은 링커가 각각의 오브젝트 파일을 살펴보고, 오브젝트 파일에 대해, 외부 심볼이 어느 (다른) 오브젝트 파일 또는 파일들에 정의되어 있는지를 결정하는 프로세스일 수 있다. 심볼 재배치는 링커가 심볼 참조(symbol reference)를 그의 정의에 매핑하는 프로세스일 수 있다. 링커는 심볼에 대한 코드 참조(code reference)가 이들 심볼에 할당된 실제 주소를 반영하도록 링킹된 오브젝트 파일의 기계 코드를 수정할 수 있다.
오브젝트 파일 및 실행가능 파일은, 예를 들어, ELF(Executable and Linking Format) 및 COFF(Common Object-File Format) 등의 몇가지 형식으로 나올 수 있다. 오브젝트 파일은 영역 또는 섹션으로 나누어질 수 있다. 이들 섹션은, 예를 들어, 실행가능 코드, 데이터, 동적 링킹 정보, 디버깅 데이터, 심볼 테이블, 재배치 정보, 코멘트, 문자열 테이블 또는 메모 중 하나 이상을 보유할 수 있다. 이들 섹션은 이진 파일에 명령어를 제공하고 검사를 가능하게 해주기 위해 사용될 수 있다. 함수 섹션은 시스템 함수의 주소를 저장할 수 있는 GOT(Global Offset Table), GOT에 대한 간접 링크(indirect link)를 저장할 수 있는 PLT(Procedure Linking Table), 내부 초기화를 위해 사용될 수 있는 .init/fini, 그리고 생성자(constructor) 및 소멸자(destructor)를 위해 사용될 수 있는 .shutdown, 또는 .ctors/.dtors 중 하나 이상을 포함할 수 있다. 데이터 섹션은 판독 전용 데이터를 위한 .rodata, 초기화된 데이터를 위한 .data, 또는 초기화되지 않은 데이터를 위한 .bss 중 하나 이상을 포함할 수 있다. ELF 섹션은 기동을 위한 .init, 문자열을 위한 .text, 종료를 위한 .fini, 판독 전용 데이터를 위한 .rodata, 초기화된 데이터를 위한 .data, 초기화된 스레드 데이터(thread data)를 위한 .tdata, 초기화되지 않은 스레드 데이터를 위한 .tbss, 생성자를 위한 .ctors, 소멸자를 위한 .dtors, 전역 오프셋 테이블(global offset table)을 위한 .got, 또는 초기화되지 않은 데이터를 위한 .bss 중 하나 이상을 포함할 수 있다.
일부 섹션은 프로세스 이미지에 로드될 수 있다. 일부 섹션은 프로세스 이미지를 빌드(build)하는 데 사용될 수 있는 정보를 제공할 수 있다. 일부 섹션은 오브젝트 파일을 링킹하는 데 사용하도록 제한되어 있을 수 있다. 일부 오브젝트 파일은 다른 오브젝트 파일에 위치되어 있는 심볼에 대한 참조를 포함할 수 있다. 링커는 각각의 오브젝트 파일에 대한 텍스트 및 데이터 세그먼트에 심볼 이름 및 그의 대응하는 오프셋의 목록을 포함할 수 있는 심볼 테이블을 생성할 수 있다. 오브젝트 파일을 서로 링킹한 후에, 링커는 기입되어 있지 않을지도 모르는 해석되지 않은 심볼 주소(symbol address)를 찾기 위해 재배치 기록(relocation record)을 사용할 수 있다. 다수의 소스 파일(예컨대, C/C++ 및 어셈블리 파일)이 컴파일되고 ELF 오브젝트 파일로 어셈블된 후에, 예컨대, 도 3에 도시된 바와 같이, 링커는 이들 오브젝트 파일을 결합하고 상이한 오브젝트 파일로부터의 섹션들을 프로그램 세그먼트로 병합할 수 있다.
도 3에 예시된 바와 같이, 오브젝트 파일(302, 304 및 306)의 텍스트 섹션(각각, 308, 316 및 324)은 실행가능 이미지(338)의 텍스트 세그먼트(332)로 병합될 수 있다. 그에 부가하여, 또는 다른 대안으로서, 기동 섹션(310, 318 및 326)은 실행가능 이미지(338)의 텍스트 세그먼트(332)로 병합될 수 있다. 이와 유사하게, 오브젝트 파일(302, 304 및 306)의 데이터 섹션(각각, 312, 320 및 328)은 실행가능 이미지(338)의 데이터 세그먼트(334)로 병합될 수 있다. 마지막으로, 오브젝트 파일(302, 304 및 306)의 초기화되지 않은 데이터 섹션(각각, 314, 322 및 330)은 실행가능 이미지(338)의 초기화되지 않은 데이터 세그먼트(336)로 병합될 수 있다. 도 3이 실행가능 이미지(338) 내의 세그먼트로 병합될 수 있는 오브젝트 파일(302, 304 및 306)의 다수의 섹션을 나타내고 있지만, 임의의 수 및/또는 조합의 섹션이 실행가능 이미지의 세그먼트로 병합될 수 있다는 것을 잘 알 것이다.
도 3에 예시된 바와 같이, 세그먼트는 관련 섹션들을 그룹화하는 방법을 제공할 수 있다. 각각의 세그먼트는 동일하거나 상이한 유형의 하나 이상의 섹션(예컨대, 텍스트, 데이터 또는 동적 섹션)을 포함할 수 있다. 운영 체제는 프로그램 헤더 테이블(program header table)에 제공된 정보에 따라 파일의 세그먼트를 논리적으로 복사할 수 있다. 실행가능 및 판독 전용 데이터 섹션이 단일의 텍스트 세그먼트로 결합될 수 있다. 데이터 및 초기화되지 않은 데이터 섹션이 데이터 세그먼트로 또는 그 자신의 개별 세그먼트로 결합될 수 있다. 이들 세그먼트는 로드 세그먼트(load segment)라고 할 수 있는데, 그 이유는 이들이 프로세스 생성 시에 메모리에 로드될 수 있기 때문이다. 심볼 정보 및 디버깅 섹션 등의 다른 섹션은 다른 비로드 세그먼트(non-load segment)로 병합될 수 있다. 텍스트 섹션은, 초기화된 정적 변수와 함께, 소스 코드를 포함할 수 있다. 컴파일러에 의해 정의된 다수의 섹션이 링커에 의해 정의되는 단일의 결합된 세그먼트에 로드될 수 있다.
링커가 섹션들을 어떻게 결합시키는지 및/또는 세그먼트들을 대상 시스템 메모리 맵에 어떻게 할당하는지를 제어하기 위해 링커 명령[링커 지시자(linker directive)라고 할 수 있음]을 사용하여 최종 실행가능 이미지가 발생될 수 있다. 링커 지시자는 링커 명령 파일에 보관될 수 있다. 임베디드 개발자(embedded developer)는 실행가능 이미지를 대상 시스템에 매핑하기 위해 링커 명령 파일을 사용할 수 있다.
실패한 컴포넌트의 유효성 확인 및 세밀한 보고를 수행하는 기능은 실행가능 이미지에서 이용가능한 부가의 정보를 사용할 수 있고, 그로써 개발 및 코드 배포 도구 체인에 대한 수정이 있을 수 있다. 각각의 컴포넌트에 대한 참조 측정은 물론 측정이 어느 컴포넌트와 연관되어 있는지를 식별해주는 정보 요소가 실행가능 이미지 내에서 식별가능할 수 있다.
실패한 컴포넌트의 복원은 표준의 기능 실패를 보고하는 장치의 기능에 의존할 수 있다. 기능은 물론 실패에 기초하여 취해질 조치가 네트워크 통신사업자에 의해 정의되어 있을 수 있다. 소프트웨어 개발자는 통신사업자에 의해 정의된 기능이 어떻게 그의 시스템에 있는 소프트웨어 컴포넌트에 매핑될 수 있는지를 결정할 수 있다. 기능 매핑은 실행가능 이미지에서 보일 수 있고, 도구 체인 향상을 사용할 수 있다.
컴포넌트 섹션의 발생, TRV의 안전한 발생 및 임베딩, 컴포넌트-기능 정의의 삽입, 또는 정책 및 정책 구성 파일의 삽입 중 하나 이상에 대처하기 위해, 개발 단계 동안 사용되는 소프트웨어 도구 체인이 수정될 수 있다.
유효성 확인 및/또는 복원에 대처하기 위해 로더 기능이 수정될 수 있다. 컴포넌트가 로드될 때 컴포넌트의 무결성 검사를 수행하는 것, 실패한 컴포넌트를 격리시키거나 언로드하는 것, 정책을 관리하는 것, 또는 정책 관리자가 실패를 보고하기 위해 실패한 컴포넌트 ID를 메모리에 저장하는 것 중 하나 이상을 수행하기 위해 로더가 수정될 수 있다.
원하는 기능을 설명하기 위해 본 명세서에 기술되어 있는 소프트웨어 개발 및 코드 배포 도구 체인에 적용될 수 있는 예시적인 실시예가 본 명세서에 기술되어 있다. 그렇지만, 실시예들이 여기에 제공된 예로 제한되지 않는다.
링커의 역할은 입력 오브젝트들을 받아 다양한 섹션들을 세그먼트로 결합시키는 것일 수 있다. 오브젝트 코드가 링킹 프로세스 동안 결합될 수 있기 때문에, 오브젝트 파일 내의 함수 또는 변수를 식별할 수 있는 기능은 심볼 테이블 정보에 보유되어 있을 수 있다. 얻어지는 병합된 코드 섹션은 본 명세서에 기술되어 있는 바와 같이 유효성 확인 절차를 트리거하는 데 사용될 수 있는 유효성 확인 방식을 제공하지 않을 수 있다.
개별적인 컴포넌트의 식별을 용이하게 해주기 위해, 로더는, 컴포넌트를 정의하는 것 또는 로더에 의해 식별될 수 있는 개별 컴포넌트에 대한 TRV를 발생하는 것을 포함할 수 있는, 코드가 어디에서 나왔는지를 식별하는 방법을 가질 수 있다. 예컨대, 로더 유효성 확인 기능이 특정의 컴포넌트를 식별하고 무결성 검사를 수행하기 위해 특정의 오브젝트 파일 컴포넌트와 연관되어 있는 코드를 식별할 수 있기 위해, 실행가능 이미지를 발생하는 데 사용되는 도구 체인이 향상될 수 있다. 코드 이미지의 재정렬은 입력 객체에 대한 TRV를 변경할 수 있다(예컨대, 하나의 입력 객체를 수정하는 것에 의해 다른 입력 객체에 대한 TRV가 변경될 수 있음). TRV의 변경을 하지 못하게 하기 위해 도구 체인이 최적화 방법을 사용하지 못하도록 될 수 있다.
무결성 검사를 하도록 요망될 수 있는 컴포넌트에 대해 특정의 섹션 이름이 발생될 수 있다. 섹션 이름은, 예를 들어, 최종 ELF 실행가능 파일에 포함되어 있는 섹션 헤더 테이블에 나타날 수 있다. 사용자-정의 섹션들을 그룹화함으로써, 로더는 컴포넌트를 식별하고 무결성 검사를 수행할 수 있다. 로더는 컴포넌트의 통과 또는 실패 상태를 정책 관리자에 보고할 수 있다. 무결성 검사를 통과/실패한 특정의 기능을 격리시키는 것은 정책 관리자가 실패한 컴포넌트에 의해 영향을 받을지도 모르는 그 기능들을 세밀한 또는 상세한 레벨로 보고할 수 있게 해줄 수 있다.
도 4는 단일의 실행가능 이미지(406)를 형성하기 위해 서로 링킹될 수 있는 2개의 오브젝트 파일(402 및 404)을 나타낸 것이다. 오브젝트 파일(402)은 2개의 상이한 코드 세그먼트 - 컴포넌트 파일 섹션(408) 및 텍스트 섹션(410) - 를 가진다. 오브젝트 파일(404)은 코드 및/또는 상수 데이터를 포함할 수 있는 단일의 코드 세그먼트 - 컴포넌트 파일 섹션(416) - 를 가진다. 사용자-정의 코드 섹션 - 컴포넌트 파일 섹션(408) 및 컴포넌트 파일 섹션(416) - 은, 이들이 매핑되는 세그먼트의 유형에 대한 크기 및/또는 메모리 위치와 함께, 섹션 헤더에 나타날 수 있다. 이러한 매핑 관계의 예가 도 4에 화살표로 나타내어져 있다. 예를 들어, 오브젝트 파일(402)의 컴포넌트 파일 섹션(408), 텍스트 섹션(410), 데이터 섹션(412), 및 bss 섹션(414)은, 각각, 실행가능 이미지(406)의 컴포넌트 파일 섹션(420), 텍스트 섹션(424), 데이터 섹션(426), 및 bss 섹션(428)에 매핑될 수 있다. 이와 유사하게, 오브젝트 파일(404)의 컴포넌트 파일 섹션(408) 및 bss 섹션(418)은, 각각, 실행가능 이미지(406)의 컴포넌트 파일 섹션(420) 및 bss 섹션(428)에 매핑될 수 있다. 사용자-정의 섹션들이 순차적으로 검사될 수 있도록 실행가능 이미지(406)의 시작에서 소정의 위치에 사용자-정의 섹션을 포함하도록 실행가능 이미지(406)가 링킹될 수 있다. 유효성 확인에 의한 무결성의 검사가 코드 베이스의 서브세트로 제한될 수 있다. 보다 큰 텍스트 세그먼트로 그룹화된 나머지 코드는 무결성 검사되지 않을 수 있고 및/또는 로드될 수 있다.
예컨대, #PRAGMA를 컴포넌트 코드에 삽입함으로써, 사용자-정의 섹션들의 부가가 식별가능하게 될 수 있다. 여전히 도 4의 예를 참조하면, 명령어 #PRAGMA 섹션[예컨대, 컴포넌트 파일 섹션(408)]은 소스 파일의 상단에 삽입될 수 있다. 컴파일러는 컴파일러 플래그에 의해 사용자-정의 섹션을 포함하도록 향상될 수 있다. 컴파일러는 특정의 플래그가 세트되어 있는 경우 자동으로 PRAGMA를 삽입하도록 향상될 수 있다. 사용자-정의 섹션이 무결성 검사될 수 있는 컴포넌트 내의 그 함수로 제한되도록, 사용자-정의 섹션 개념이 확장될 수 있다. 장치의 신뢰성 있는 실행을 위해 사용될 수 있는 함수가 기동 프로세스에서 처음으로 또는 조기에 무결성 검사될 수 있는 컴포넌트로 분할되거나 격리될 수 있다.
섹션이 링커 명령 파일을 통해 메모리의 특정의 세그먼트에 매핑될 수 있다. ELF 객체를 소스 및 목적지 주소의 점에서 볼 수 있다. 섹션 헤더 테이블에서 식별된 섹션은 이동할 코드 및/또는 데이터의 시작을 어디에서 찾아야 하는지를 로더에 알려줄 수 있다. 세그먼트 헤더에서 식별된 세그먼트는 컴포넌트를 어디로 복사해야 하는지를 로더에 알려줄 수 있다. 섹션 및 프로그램 헤더의 형식이 이하에 예시되어 있다.
섹션 헤더 프로그램 헤더
typedef struct { typedef struct {
Figure 112014049660497-pat00001
Elf32_Word sh_name;
Figure 112014049660497-pat00002
Elf32_Word p_type;
Figure 112014049660497-pat00003
Elf32_Word sh_type;
Figure 112014049660497-pat00004
Elf32_Off p_offset;
Figure 112014049660497-pat00005
Elf32_Word sh_flags;
Figure 112014049660497-pat00006
Elf32_Addr p_vaddr;
Figure 112014049660497-pat00007
Elf32_Addr sh_addr;
Figure 112014049660497-pat00008
Elf32_Addr p_paddr;
Figure 112014049660497-pat00009
Elf32_Off sh_offset;
Figure 112014049660497-pat00010
Elf32_Word p_filesz;
Figure 112014049660497-pat00011
Elf32_Word sh_size;
Figure 112014049660497-pat00012
Elf32_Word p_memsz;
Figure 112014049660497-pat00013
Elf32_Word sh_link;
Figure 112014049660497-pat00014
Elf32_Word p_flags;
Figure 112014049660497-pat00015
Elf32_Word sh_info;
Figure 112014049660497-pat00016
Elf32_Word p_align;
Figure 112014049660497-pat00017
Elf32_Word sh_addralign;
} Elf32_Phdr;
섹션 헤더 프로그램 헤더
Figure 112014049660497-pat00018
Elf 32_Word sh_entsize;
} Elf32_Shdr;
sh_addr는 프로그램 섹션이 대상 메모리(target memory)에서 존재할 수 있는 주소일 수 있다. p_paddr는 프로그램 세그먼트가 대상 메모리에서 존재할 수 있는 주소일 수 있다. sh_addr 및 p_paddf 필드는 로드 주소(load address)를 말하는 것일 수 있다. 로더는 섹션 헤더로부터의 로드 주소 필드를 비휘발성 메모리로부터 RAM으로의 이미지 전송을 위한 시작 주소로서 사용할 수 있다.
컴포넌트 섹션 식별의 개념을 파일 내에 포함되어 있는 2개 이상의 특정의 컴포넌트로 확장하는 것이 가능할 수 있다. 이러한 확장은 전체 파일보다는 무결성 검사될 특정의 서브루틴의 식별을 통해 정책 관리자에 의한 액세스 제어의 추가적인 세분성을 가능하게 해줄 수 있다.
TRV는 특정의 컴포넌트 또는 오브젝트 파일의 예상된 측정(예컨대, 안전한 방식으로 계산된 컴포넌트의 해쉬)일 수 있다. 유효성 확인 프로세스는 예컨대, 실행가능 이미지에 존재하거나 무결성 검증을 위해 개별적으로 안전한 방식으로 로드되는 검사될 각각의 컴포넌트에 대한 TRV에 의존할 수 있다. 이것은 다수의 방식으로 달성될 수 있다. 예시로서, 컴포넌트 또는 오브젝트 파일의 해쉬값을 안전하게 계산하기 위해 그리고 계산된 TRV를 동일한 오브젝트 파일의 적절한 섹션에 안전하게 삽입하기 위해, 실행가능 이미지를 빌드하는 도구 체인이 수정될 수 있다. 이 계산은 링킹 프로세스의 일부로서 수행될 수 있다. TRV 해쉬가 계산되는 순서는 컴포넌트가 로드되고 측정되는 순서와 일치할 수 있고, 그렇지 않은 경우, 측정값이 정확하게 일치하지 않을 수 있다. 해쉬값이 로더가 이용가능할 수 있거나 실행파일 내에 포함되어 있을 수 있다. 신뢰 사슬을 유지하기 위해, TRV가 발생되고 및/또는 안전하게 저장될 수 있다. 예컨대, 공개 키(예를 들어, 소프트웨어/펌웨어의 제조업체의 공개 키)에 대응하는 비밀 키를 사용하여 TRV 값에 서명을 함으로써 TRV가 보호될 수 있다.
컴포넌트 오브젝트 파일은, 도 5에 예시된 바와 같이, 개별적인 사용자-정의 섹션을 그의 연관된 TRV에 대한 자리 표시자(placeholder)로서 포함할 수 있다. 예를 들어, 도 5에 예시된 바와 같이, 컴포넌트 오브젝트 파일(408)의 TRV가 계산되고 컴포넌트 TRV 섹션(502)에 저장될 수 있다. 섹션 헤더는 본 명세서에 기술되어 있는 사용자-정의 섹션을 포함할 수 있는 그 섹션들의 시작 주소 및/또는 크기를 식별해줄 수 있다. 오브젝트 파일(402)에서, 링커는 심볼 해석 단계의 끝에서 컴포넌트 오브젝트 파일(408)의 해쉬값을 계산하고 대응하는 컴포넌트 TRV 섹션(502)을 찾아낼 수 있다. 컴포넌트 TRV는 메모리에서의 지정된 위치(예컨대, 컴포넌트 TRV 섹션)에서 실행가능 이미지에 삽입될 수 있다. 섹션 헤더는 로더가 유효성 확인 프로세스 동안 특정의 섹션에 대한 TRV를 찾아낼 수 있게 해줄 수 있다.
본 명세서에 기술된 바와 같이, 장치 유효성 확인은 컴포넌트의 무결성 상태에 중점을 둘 수 있다. 실패한 컴포넌트를 보고하는 것을 표준화하는 일은 어려울 수 있는데, 그 이유는 소프트웨어 개발 실무가 회사마다 상이할 수 있기 때문이다.
컴포넌트들이 수행하는 기능과 관련하여 컴포넌트들을 그룹화하는 방식을 표준화하는 시스템, 방법, 및 수단이 본 명세서에 개시되어 있다. 기능들이 표준 규격을 따르도록 및/또는 구현 독립적인 방식으로 표준화될 수 있다. 표준화될 수 있는 장치 기능에 대해 기능들의 목록이 사전 정의될 수 있다. 무결성 검사 동안 발견된 실패와 보고를 위한 특정의 기능 간의 매핑을 가능하게 해주기 위해 기능과 컴포넌트 간의 참조가 사용될 수 있고, 그의 한 예가 도 6에 도시되어 있다.
도 6에 예시된 바와 같이, 신뢰성 있는 도메인(trusted domain)(602)은 서로 매핑되는 컴포넌트 및 기능을 포함할 수 있다. 예를 들어, 신뢰성 있는 도메인(602)은 상위 레벨 기능(604), 중간 기능(606), 및/또는 TrE(trusted environment) 핵심 기능(608)을 포함할 수 있다. 상위 레벨 기능(604)은 기능(610) 및 기능(612)을 포함할 수 있다. 중간 기능(606)은 기능(614) 및 기능(616)을 포함할 수 있다. TrE 핵심 기능(608)은, 예를 들어, RoT 등의 기능(618)을 포함할 수 있다. 기능(612)은, 예를 들어, 소프트웨어 컴포넌트일 수 있는 컴포넌트(620 및/또는 622)에 매핑될 수 있다. 기능(616)은, 예를 들어, 역시 소프트웨어 컴포넌트일 수 있는 컴포넌트(624)에 매핑될 수 있다. 기능(618)은, 예를 들어, 펌웨어 컴포넌트일 수 있는 컴포넌트(626)에 매핑될 수 있다. 신뢰성 있는 도메인(602)의 무결성 검사 동안, 컴포넌트(624)에서 실패가 결정될 수 있다. 컴포넌트(624)가 기능(616)에 매핑될 때, 네트워크 기능(616)이 또한 실패가 있다고 결정될 수 있다. 그 결과, 장치는 복원을 위해 실패한 기능(616)의 표시를 네트워크로 송신할 수 있다.
도 6에서 기능과 컴포넌트 간의 매핑이 시행 계층(enforcement layer) 매핑으로서 예시되어 있다. 도 6에 예시된 실시예에 대한 대안으로서, 또는 그에 부가하여, 컴포넌트와 기능 간의 매핑이 2개 이상의 계층을 가질 수 있다. 3개 이상의 계층(예컨대, 하나는 컴포넌트에 대한 것이고 나머지는 기능에 대한 것임)을 가지는 데이터 구조체가 사용될 수 있다. 이러한 구조체에서, 컴포넌트는 한 세트의 서브기능에 매핑될 수 있고, 서브기능은 한 세트의 훨씬 더 높은 레벨의 서브기능에 매핑될 수 있다. 중간 매핑은 최종 서브기능 계층에 있는 서브기능이 최종 계층에 있는 최종 기능에 매핑될 때까지 계속될 수 있다. 트리 또는 트리와 유사한 데이터 구조체가 이러한 다중 계층 컴포넌트-기능간 매핑 관계를 포착할 수 있는 구조체의 예일 수 있다.
개발자는 컴포넌트가 표준화된 기능에 어떻게 매핑되는지를 결정할 수 있다. 일 실시예에 따르면, 실행가능 이미지는 컴포넌트와 기능간의 매핑을 포함할 수 있다. 이것은 컴파일 시에, 예를 들어, 컴파일된 또는 소스 코드를 파싱하고 개별적인 파일 레이아웃, 파일에서의 함수들의 상호의존성 중 하나 이상을 보여주며 컴포넌트와 기능 간의 매핑을 가능하게 해주는 그래픽 도구를 통해 달성될 수 있다. 기능은 사용자에 의해 입력되고 및/또는 수동으로 컴포넌트/파일에 매핑될 수 있는 텍스트 필드 및/또는 단축된 ID 번호일 수 있다. 개발 도구는 컴포넌트를 기능 매핑 테이블에 참조시키는 섹션을 생성할 수 있다. 컴포넌트 이름, 기능 이름, 및 ID는, 교차 참조 상호 연결(cross-reference inter-connect)과 함께, 테이블의 요소로서 포함될 수 있다.
도 7은 컴포넌트와 기능 간의 매핑을 포함하는 섹션의 예를 나타낸 것이다. 도 7에 예시된 바와 같이, 기능-컴포넌트간 매핑 섹션(702)은, 예를 들어, 오브젝트 파일(402) 등의 오브젝트 파일에 섹션으로서 포함될 수 있다. 본 명세서에 기술되어 있는 바와 같이, 기능-컴포넌트간 매핑 섹션(702)은 또한 실행가능 이미지에서 대응하는 세그먼트에 링킹될 수 있다.
로더의 기능은 코드를 외부 메모리로부터 내부 메모리로 가져오는 것일 수 있다. 신뢰 사슬은 RoT 및 부트 로더로부터 시작하여 이전의 스테이지에 의해 검증되는 코드의 각각의 로드된 스테이지에 의존할 수 있다. 제2 스테이지 로더는 신뢰성 있는 환경 및 OS 로더의 핵심을 포함할 수 있는 그 다음 스테이지를 검증할 수 있다. OS가 초기화되어 실행되고 있으면, 나머지 무결성 검사가 본 명세서에 기술되어 있는 바와 같이 표준 OS 로더에 의해 수행될 수 있다. 실행가능 이미지가 캐싱 없이 RAM에 로드될 수 있다. 본 명세서에 개시되어 있는 이들 개념이 실행가능 이미지가 부가의 수정에 의해 이용가능한 RAM보다 큰(예컨대, 캐시 메모리의 사용이 있을 수 있는 그리고 코드가 ROM으로부터 직접 실행될 수 있는) 보다 제약된 구현을 포함하도록 확장될 수 있다.
외부 메모리로부터 내부 메모리로 코드를 가져오는 로더는 암호 무결성 검사를 수행할 수 있는 기능을 포함할 수 있다. 무결성 검사는 다시 신뢰성 있는 환경에 안전하게 보유되어 있을 수 있는 암호 함수를 참조할 수 있다. 정상 동작 하에서, 로더는, 링커 명령 스크립트 및 세그먼트 헤더 정보에 의해 정의된 바와 같이, 결합된 텍스트 섹션[텍스트 섹션(410) 등] 및 데이터 섹션[데이터 섹션(412) 등] 내의 코드 및 데이터를 내부 메모리로 복사할 수 있다. 텍스트 섹션(410) 및 데이터 섹션(412)을 벌크 로드하는 대신에, 로더는 코드 및/또는 데이터의 사용자-정의 섹션을 식별할 수 있다. 이러한 보충 섹션 정보의 일부가 무결성 검사를 위해 사용될 수 있다. 로더는 컴포넌트에 대한 무결성 측정을 계산하고 이어서 그의 연관된 섹션에서 컴포넌트에 대한 TRV를 찾아낼 수 있다. 섹션 헤더는 섹션의 시작 주소 및 크기를 제공할 수 있다. 측정된 값은 동일한 컴포넌트에 대한 저장된 TRV와 비교될 수 있다. 그 값들이 일치하는 경우, 코드가 내부 메모리에 로드될 수 있다. 무결성 측정이 일치하지 않는 경우, 코드가 로드되지 않을 수 있고, 그 컴포넌트에 대해 실패가 기록되고 및/또는 정책 관리자에 보고될 수 있다.
각각의 컴포넌트에 대한 로더 검증 결과가 컴포넌트가 검사되었다는 것을 나타내는 비트 필드는 물론 통과 또는 실패 비트 표시에 저장될 수 있다. 전체 코드가 내부 메모리로 이동되었을 때, 정책 관리자는 완료된 무결성 검사 결과에 기초하여 어떤 액세스를 장치에 허가해야 하는지를 결정할 수 있다. 이것을 달성하는 한가지 방법은 로더가 무결성 결과를 추적하기 위해 안전한 메모리 위치에 액세스할 수 있게 해주는 것이다. 컴포넌트의 무결성이 검사되고 검증되었는지를 추적하기 위해 PLT(procedure linkage table)가 부가의 정보 요소로 향상될 수 있고, 각각의 검사된 컴포넌트가 내부 RAM에 로드될 때 그 무결성 검사의 결과 및 정보가 갱신될 수 있다.
제한된 메모리를 갖는 임베디드 시스템에서, 코드 스와핑(code swapping)이 사용될 수 있다. 코드 스와핑은 실행을 위해 사용될 수 있는 함수를 RAM으로 로드하는 것을 수반할 수 있다. 서브컴포넌트가 사용되는 경우, 서브컴포넌트가 RAM에서 이용가능하지 않은 경우 서브컴포넌트의 주소를 찾아내기 위해 PLT 및 GOT 테이블이 사용될 수 있다. 서브컴포넌트는 연관된 TRV를 갖는 보다 큰 컴포넌트의 작은 부분일 수 있다. 서브컴포넌트가 로드될 때 서브컴포넌트를 동적으로 검사하는 시스템에서, 서브컴포넌트가 로드되어야만 할 때마다, 전체 컴포넌트의 무결성 검사가 사용될 수 있다. 이러한 요구사항은 시스템에 불필요한 계산 부담을 부가할 수 있다.
컴포넌트가 그의 서브컴포넌트로 분할될 수 있고, 각각의 서브컴포넌트에 대해 무결성을 검사하는 데 사용될 수 있는 중간 TRV가 계산될 수 있다. 게다가, 중간 해쉬를 계산하기 위해 최소 블록 크기가 구현될 수 있다. 서브컴포넌트의 TRV 해쉬를 발생하는 이 프로세스는 TRV 분해(TRV digestion)라고 할 수 있다. 예를 들어, 작은 서브컴포넌트 해쉬가 메모리 페이지 블록 크기에 기초하여 계산될 수 있다. 이와 같이 컴포넌트를 서브컴포넌트로 나누는 것은 컴포넌트가 무결성 검사될 때, 예를 들어, 기동 프로세스의 설치의 일부로서, 일어날 수 있다. 각각의 서브컴포넌트의 중간 TRV를 포함하도록 GOT가 향상될 수 있다.
PIPE(Platform Integrity Policy Engine)는 전체 플랫폼 신뢰 시스템 아키텍처의 일부일 수 있다. 예를 들어, PIPE는 네트워크가 공격받는 것, 장치가 오사용되는 것, 민감한 데이터가 불법적 방식으로 플랫폼 상에서 전달되거나 조작되는 것 중 하나 이상을 방지할 수 있다. PIPE는 안전하고 신뢰할 수 있는 플랫폼을 제어 및 생성하기 위해 부트 로더, 정책 관리자, 및 가상화 컴포넌트 등의 다양한 운영 체제 함수에 의존할 수 있다. PIPE는 안전 부트 프로세스의 흐름, 소프트웨어 컴포넌트에 대한 무결성 검사 측정의 처리, 정책에 따른 후속 시행 조치, 및/또는 후속 소프트웨어 로드 제어의 흐름을 비롯한 다양한 함수를 제어할 수 있다. 정책이 제조업체 또는 통신사업자 등의 외부 이해관계자에 의해 정의될 수 있고, 장치 상에 프로비저닝될 수 있다. 정책이 원격 업데이트 절차를 통해 현장에서 업데이트될 수 있다.
PIPE는 제어된 소프트웨어 데이터 검사 및 로드 동작, 더 많은 기능적 능력을 점진적으로 설치하는 것, 또는 런타임 동안 컴포넌트의 동적 로딩을 유지하는 것 중 중 하나 이상을 통해 손상된 소프트웨어 기능이 로드될 위험을 감소시킬 수 있다. 로딩 동작에서의 진행 스테이지에 따라, 조치들은 플랫폼의 전원을 끄는 것; 손상된 컴포넌트(들)의 로딩을 방지하거나 컴포넌트(들)를 격리시키는 것; 하위 레벨 실패 또는 손상된 기능을 통지하기 위해 네트워크 내의 보안 게이트웨이 또는 복원 관리자 등의 외부 엔터티에 대한 경보를 트리거하는 것; 인증 키 등과 같은 플랫폼 상의 보안 정보에의 액세스를 방지하는 것; 인증 알고리즘 등과 같은 플랫폼 상의 보안 기능에의 액세스를 방지하는 것; 벌크 코드 또는 데이터 재로드/업데이트 절차를 수행하는 것; 손상된 소프트웨어 컴포넌트 및/또는 구성 데이터를 교체하는 것; 또는 컴포넌트에서의 실패의 위치를 격리시키기 위해 변조가 의심되는 컴포넌트를 보다 상세히 조사하는 것(보다 세밀하게 무결성 검사하는 것을 포함함) 중 하나 이상을 포함할 수 있다.
어떤 경우에, 실패가 아주 심각하여 심지어 신뢰성 있는 환경조차도 플랫폼에의 신뢰를 보장해주지 못할 수 있는데, 그 이유는 핵심 TrE 기능이 손상되었기 때문이다. 하위 레벨에서의 실패는 무결성 및 재생 보호 및 기밀성 보호를 포함할 수 있는 기본 RoT(root-of-trust) 서명된 경보 메시지를 발생하는 것 등의 기초적인 동작을 트리거할 수 있다. 즉, 심각한 하위 레벨 보안 실패가 발생할 시에 이용가능할 수 있는 하나 이상의 통신 채널에 의해 재난 메시지가 네트워크로 방출될 수 있다.
로드된 기능이 빌드되어 더욱 더 복잡하게 될 때, 장치는 네트워크 엔터티를 대신하여 안전하고 신뢰할 수 있는 대용물로서 기능하는 것 등의 보다 복잡한 동작을 수행할 수 있으며, 이는 손상된 소프트웨어 또는 구성 데이터를 진단, 보고 및/또는 교체하는 조사 절차를 용이하게 해줄 수 있다.
성공적으로 검증된 기능의 레벨에 따라 플랫폼 상의 자원에 대한 다양한 액세스가 (예컨대, PIPE에 의해) 제공될 수 있다. 컴포넌트 무결성 검사가 실패하는 경우, 그 컴포넌트는 신뢰되지 않을 수 있다. 이 검출된 실패는 안전하게 표시되고 네트워크에 (명시적으로 또는 암시적으로) 알려질 수 있으며, 부트 흐름이 이 실패 있는 조건으로 인해 분기할 수 있다. 이러한 유형의 무결성 검사 실패(integrity check failure)는 실행 흐름 실패(execution flow failure)라고 할 수 있고, 그로써 검사된 컴포넌트는 신뢰할 수 없을 수 있고, 이 컴포넌트를 시작하는 것에 의해 악의적인, 손상된, 실패 있는, 또는 잘못 구성된 코드가 실행될 수 있고, 이는 장치로 하여금 지정되지 않은 및/또는 예상되지 않은 방식으로 네트워크 함수를 수행하게 할지도 모른다. 이와 같이, 새로운 컴포넌트 및 이용가능한 기능을 로드하는 것이 이전에 로드된 컴포넌트의 무결성에 의해 영향을 받을 수 있다.
그 결과, 각각의 부트 스테이지 및 각각의 런타임 프로세스에서 제어 실행 프로세스 및/또는 액세스 특권에 따라 실행 환경이 변할 수 있다. 예를 들어, 부트 프로세스에서의 각각의 스테이지에서, 그 때에 행해진 무결성 측정에 기초하여 결정이 행해질 수 있다. 후속 스테이지 및 정책이 그 자신의 동작을 결정하기 위해 실행 스테이지를 초월하는 임의의 이용가능한 안전한 정보 전달 또는 저장 수단(상태, 변수, 파라미터, 레지스터, 파일 등)을 통해 이전의 스테이지로부터 전달된 정보를 사용할 수 있다. 예를 들어, 상위 계층 응용 프로그램 인증 함수는, 예를 들어, 외부 엔터티에의 성공적인 인증을 위해 사용되는 키의 배포의 게이팅(gating)을 비롯한 그 자신의 동작을 결정하기 위해, 이전에 로드된 컴포넌트의 무결성에 관한 정보를 사용할 수 있다.
예시적인 PIPE 기능 흐름은 본 명세서에 기술되어 있는 바와 같이 수행될 수 있다. 예를 들어, RoT가 무결성 검사될 수 있고 및/또는 그의 무결성이 검증될 수 있다. 기준 TrE가 RoT에 의해 무결성 검사될 수 있고 및/또는 그의 무결성이 검증될 수 있다. 기준 TrE의 무결성 검사 및/또는 검증에 실패한 경우, PIPE는 네트워크에 접속하기 위해 사용되는 키의 배포를 방지하고, 네트워크로 경보를 트리거하며 및/또는 장치의 전원을 끌 수 있다. PIPE가 네트워크로 경보를 트리거하는 경우, 경보가 네트워크로 송신될 수 있게 해줄 수 있는 폴백 코드(fallback code)가 로드될 수 있다. 경보는 TrE를 교체하기 위해 원격 벌크 업데이트 절차를 트리거할 수 있다.
기준 TrE의 무결성 검사 및/또는 검증에 실패가 없는 경우, 기본 통신 연결 코드가 로드될 수 있다. 이것은 무결성 검사를 수행하고 기준 운영 체제 모듈(baseline operating system module)을 로드하는 것, 무결성 검사를 수행하고 기준 관리 클라이언트(baseline management client)를 로드하는 것, 및/또는 무결성 검사를 수행하고 통신 모듈을 로드하는 것을 포함할 수 있다. 운영 체제 모듈, 기준 관리 클라이언트 및/또는 통신 모듈의 무결성을 검사하는 동안에 실패가 식별되는 경우, PIPE는 네트워크에 접속하기 위해 사용되는 키의 배포를 방지하고, 네트워크로 경보를 트리거하며, 컴포넌트를 교체하기 위해 원격 벌크 업데이트 절차를 수행하고, 원격 컴포넌트 업데이트 절차를 수행하며, 및/또는 장치의 전원을 끌 수 있다. PIPE가 원격 벌크 업데이트 절차를 트리거하는 경우, 경보가 네트워크로 송신될 수 있게 해줄 수 있는 폴백 코드가 로드될 수 있다. 경보는 기본 코드(basic code)를 교체하기 위해 원격 벌크 업데이트 절차를 트리거할 수 있다.
기본 통신 연결 코드의 무결성 검사 및/또는 검증에 실패가 없는 경우, 나머지 운영 체제 및 관리 클라이언트 컴포넌트가 무결성 검사되고 및/또는 로드될 수 있다. 이것은 무결성 검사를 수행하는 것 및/또는 재배치가능한 및/또는 재로드가능한 함수 모듈을 로드하는 것을 포함할 수 있다. 무결성 검사 동안 실패가 식별되는 경우, PIPE는 네트워크에 접속하기 위해 사용되는 키의 배포를 방지하고, 프로토콜에서의 실패 보고를 네트워크로 송신하며, 경보를 트리거하고 및/또는 원격 컴포넌트 업데이트 절차를 요청하며, 및/또는 장치의 전원을 끌 수 있다. 예를 들어, 네트워크에 의해 원격적으로 업데이트될 수 있는 실패 보고는 실패한 컴포넌트를 나타낼 수 있다.
성공적으로 검증된 부트 체인에 따라 PIPE의 동작이 변할 수 있다. 부트 프로세스에서의 각각의 스테이지에서, 그 때에(또는 그 때까지) 무결성 검사되었던 기본 플랫폼의 일부 또는 전체의 평가된 무결성 및 적용되어야 하는 정책에 기초하여 결정이 행해질 수 있다. 이들 정책은 달성된 신뢰 레벨에 따라 적응되거나 다른 정책으로 교체될 수 있다. 각각의 부트 스테이지에서의 제어 정책에 따라 실행 환경이 변할 수 있다. 후속 스테이지 및/또는 정책이 실행 스테이지를 초월하는 이용가능한 안전한 정보 전달 또는 저장 수단(예컨대, 상태, 변수, 파라미터, 레지스터, 파일 등)을 통해 이전의 스테이지로부터 전달된 정보를 사용할 수 있다.
본 명세서에 기술된 바와 같이, 예를 들어, PIPE는 정책을 플랫폼 상에 프로비저닝할 수 있고, 이 경우 정책은, 예컨대, 도 8에 도시된 바와 같이, 플랫폼 활성화 및 신뢰 상태의 달성된 레벨에 따라 적응하거나 변할 수 있다. 도 8에 예시된 바와 같이, TrE(802)는 대응하는 정책(812)에 따라 무결성 검사되고, 로드되며, 및/또는 실행될 수 있다. TrE(802)가 신뢰성 있는 엔터티로서 설정되고 실행된 후에, 장치는 부트 시퀀스의 그 다음 스테이지로 이동할 수 있다. 예를 들어, 능력(804)은 정책(814)에 따라 무결성 검사되고, 로드되며, 및/또는 실행될 수 있다. 능력(804)의 무결성 검사, 로딩 또는 실행은 TrE(802)의 무결성 검사, 로딩 또는 실행과 연관되어 있는 정보(예컨대, 신뢰 상태)에 기초할 수 있다. 무결성 검사, 로딩 및/또는 능력(804)의 실행 동안 구현될 수 있는 정책(814)은 부트 시퀀스의 이전 스테이지에서 구현되었던 정책(812)에 의해 통보될 수 있다. 능력(804)이 신뢰성 있는 엔터티로서 설정되고 실행된 후에, 장치는 부트 시퀀스의 그 다음 스테이지로 이동할 수 있다. 부트 시퀀스는 능력(806, 808 및 810)을, 각각, 그의 대응하는 정책(816, 818 및 820)에 따라 검사, 로딩 및/또는 실행하는 것을 계속할 수 있다. 부트 시퀀스의 각각의 스테이지는, 본 명세서에 기술되어 있는 바와 같이, 부트 시퀀스의 이전 스테이지들 중 하나 이상의 스테이지에 의해 통보를 받을 수 있다.
본 명세서에 기술되어 있는 정책은 통신사업자 등의 신뢰성 있는 외부 엔터티에 의해 프로비저닝될 수 있다. 플랫폼의 달성된 신뢰 상태의 결과는, 예를 들어, 통신 사업자 또는 민감한 응용 프로그램 또는 서비스의 제공자 등의 플랫폼의 신뢰 상태에 관해 알 적법한 이익/권리를 가질 수 있는 외부 엔터티로 전달가능할 수 있다. 유의할 점은, 플랫폼의 부트업 또는 동작 사이클의 어쩌면 상이한 스테이지에서 평가되는 플랫폼의 어쩌면 상이한 상태에 관한 정보가 전달될 수 있는 2개 이상의 외부 엔터티가 있을 수 있다는 것이다.
본 명세서에 기술되어 있는 바와 같이, 다중 계층 무결성 검사 및 이러한 무결성 검사와 플랫폼의 신뢰 상태 간의 바인딩이 수행될 수 있다. 예를 들어, 이러한 무결성 검사 및 바인딩은, 정책 및 시행에 의해, 장치 상의 키가 장치의 달성된 능력(복원 작업을 수행하는 네트워크 상의 서버 등의 외부 검증자에 대한 장치 복원 기능)을 인증하도록 보장하기 위해 다중 계층 무결성 검사를 사용할 수 있다. 원하는 능력을 달성하기 위한 특정의 사전에 알고 있는 한 세트의 소프트웨어 및/또는 구성 파일이 무결성 검사를 통과하는 경우, 인증을 위해 이러한 키를 사용하는 보안에 민감한 함수가 장치에 의해 이용가능하게 될 수 있다. 이러한 소프트웨어 및/또는 구성 파일은, 예를 들어, 하위 레벨 OS 함수, 드라이버, 구성 파일, 및/또는 어떤 통신 스택 코드의 서브세트를 포함한다.
다중 계층 무결성 검사 및 무결성 검사의 바인딩은 또한, 인증 키가 허가된 함수 또는 프로세스에 의한 사용으로 제한될 수 있도록, 인증 키를 보호하기 위해 사용되는 정책을 포함하고 있을 수 있다. 키가 보호되지 않은 경우, 키에 액세스하기 위해 소프트웨어가 손상될 수 있다. 장치가 키가 한 세트의 제한된 능력, 함수들 또는 단일의 함수에 의한 사용으로 제한되도록 키를 보호하기 위해; 그 키에 작용하는 함수/프로그램을 보호하기 위해; 및/또는 누가(예컨대, 사용자, 시스템, 스크립트 등) 이들 특권 함수들 중 하나를 호출할 수 있는지를 제한하기 위해 신뢰성 있는 기능을 제공할 수 있다.
다중 계층 무결성 검사 및 바인딩을 위한 본 명세서에 기술되어 있는 실시예는 어쩌면 손상된 장치가 그의 부분 능력(예컨대, 실패를 보고하고 복원 서버 또는 이러한 서버에 대한 AAA 엔터티를 사용하여 복원 동작을 수행하는 그의 능력)을 외부 엔터티에 인증할 수 있게 해주기 위해 사용될 수 있는 한 세트의 사전에 알고 있는 소프트웨어를 포함할 수 있다. 외부 엔터티(예컨대, 복원 서버)는 논리 엔터티일 수 있고, 이는, 예를 들어, H(e)NB의 경우에 H(e)MS 등의 장치 관리 서버에 의해 호스팅될 수 있다.
특정의 플랫폼 상에서의 실제 구현에 독립적일 수 있는 정책을 지정하는 메커니즘을 제공하기 위해, 특정의 플랫폼 능력을 위해 요망될 수 있는 기능을 지정하는 것에 의해 정책이 정의될 수 있다. 따라서, 본 명세서에 개시되어 있는 컴포넌트-기능간 매핑과 유사한 방식으로, 특정의 능력에 대응하는 정책이 또한 기능에 매핑될 수 있다. 외부 이해관계자가 특정의 능력에 대한 정책을 단일의 기능 또는 몇개의 기능으로 지정할 수 있다. 능력을 특정의 정책에 및 플랫폼 활성화의 스테이지에 매핑하는 데 있어서의 정책 요구사항을 해석하는 것은 PIPE의 책임일 수 있다.
특정의 능력이 한 세트의 특정의 기능을 사용하는 경우, 그 특정의 능력에 따라 조정되는 대응하는 정책을 위해 이들 기능이 지정될 수 있다. 예를 들어, 복원을 수행하는 능력이 정책에 매핑되도록 요망되는 경우, 복원을 수행하는 데 사용되는 기능이 대응하는 정책에 매핑될 수 있다(예컨대, 복원 능력이 기능 1, 2 및 3에 의해 처리될 수 있고, 따라서 대응하는 정책이 기능 1, 2 및 3에 매핑되도록 지정된다).
일부 구현예에서, 플랫폼의 계층화된 활성화와 능력 및 기능 간에 타당한 레벨의 상관이 있을 수 있다. 능력이 기능과 연계하여 계층별로 점진적으로 활성화될 수 있다. 예를 들어, 복원 기능 및 능력이 플랫폼 활성화의 조기 스테이지에서 활성화될 수 있다.
다중 계층 무결성 검사는 상이한 기능의 검사됨(checked) 대 검사되지 않음(not-checked) 상태의 순차적 결정이 아닐 수 있다. 기능이 순차적 방식으로 검사될 수 있다. 그렇지만, 상이한 기능이 (상이한 스테이지에서 순차적으로 로드될 수 있는) 상이한 컴포넌트에 매핑될 수 있기 때문에, 무결성의 기능별 결정 프로세스가 비순차적 방식으로, 또는 컴포넌트별 무결성 검사의 원자적 프로세서의 시퀀스에 (시간 지속기간에서 또는 시간 순서에서) 반드시 동기화될 필요는 없는 순차적 방식으로 행해질 수 있다.
정책 시행을 위해 직렬화가 사용될 수 있다. 정책 시행은, 주어진 플랫폼 능력에 대해, 대응하는 기능이 무결성 검사되었는지 및/또는 적용되어야만 하는 정책을 결정할 수 있다.
다중 스코프 인증(multi-scope authentication)은 플랫폼이 플랫폼의 달성된 신뢰 레벨에 기초하여 하나 이상의 외부 엔터티에 인증될 수 있게 해줄 수 있다. 인증 메커니즘(예컨대, 인증 시도 응답 메커니즘)이 장치의 무결성의 얻어진 스코프를 외부 엔터티에 전달하는 수단으로서 사용될 수 있다. 외부 엔터티는 장치를 인증하고, 이와 동시에, 장치의 무결성의 범위/스코프의 표시를 획득할 수 있다.
장치의 TrE는, 다중 계층 무결성 검사를 거치는 동안, 상이한 목적을 위해 인증 시도 응답에 대한 상이한 파라미터 또는 파라미터 값을 발생할 수 있다. 파라미터의 이러한 발생은 성공적인 무결성 검사의 스코프에 따라 외부 인증 엔터티와 공유되는 동일한 비밀 자격 증명에 기초하거나 이를 사용할 수 있다. 공통의 시도-응답 계산 알고리즘이 사용될 수 있다. 그렇지만, 무결성 검사의 스코프 및/또는 인증의 목적에 따라, 이러한 알고리즘에의 입력이 상이하게 될 수 있다. 예를 들어, TrE가 전체 코드 베이스를 성공적으로 검사한 경우, "전체 코드 베이스가 성공적으로 검사되었음" 등의 텍스트 문자열이 인증 시도 응답 계산 알고리즘에의 입력으로서 사용될 수 있다. TrE가 재난 복원 기능을 실현하기 위해 사용되는 컴포넌트를 성공적으로 검사하지만 전체 코드 베이스를 반드시 성공적으로 검사할 필요는 없는 경우, "재난 복원을 위한 코드 베이스가 성공적으로 검사되었음" 등의 다른 문자열이 입력으로서 사용될 수 있다.
외부 인증자(external authenticator)는, 그의 인증 시도 요청을 장치로 송신했을 시에, 또한 2개의 버전의 '예상된' 시도 응답을 계산할 수 있다. 외부 인증자가 장치에서의 시도 응답의 계산에서 어느 입력이 사용될 것인지를 알지 못할 수 있기 때문에, 외부 인증자는 양 버전의 응답을 계산해야만 할지도 모른다. 장치로부터 수신된 응답을 한 세트의 예상된 응답과 비교함으로써, 외부 인증자는, 암시적으로, 장치 무결성의 '스코프'를 성공적으로 테스트할 수 있다. 이 엔터티는, 유도에 의해, 장치의 무결성의 특정의 '스코프'가 장치측에서 성공적으로 검사되었음을 인증 및/또는 검증할 수 있다. 상기 예에서, 기능, 따라서 그 능력을 실현하는 데 사용되는 컴포넌트의 무결성 검사에 따라 장치의 다른 특정의(예컨대, 부분) 능력을 인증하기 위해 동일하거나 유사한 구현이 사용될 수 있다.
한 예로서, 신뢰-검증가능 외부 표시는 코드 무결성 측정을 특정의 부트 사이클 실행 및 구성 서명에 바인딩하는 안전 부트 프로세스 동안의 서명 자격 증명의 안전한 배포일 수 있다. 보안 시간 스탬프(secure time stamp), 부트 사이클마다 증분되는 보안된 단조 카운터(secured monotonic counter), 또는 부트 사이클 비밀(boot cycle secret)(부트 사이클마다 발생되거나 도입되는 넌스 등의 은폐된 랜덤한 값)이 포함될 수 있다. 사전 조건이 만족될 때 인증 키가 이용가능하게 될 수 있고, 현재의 신뢰할 수 있는 프로세스는, 그 다음 리셋 때까지, (예컨대, 초기 측정 이후의 실패의 검출 시에) 실패한 상태로 복구하는 것으로 제한되어 있을 수 있는 보호된 부트당 1회 프로그램가능 "통과" 플래그(protected one-time per boot programmable "pass" flag)를 세트시킨다. TrE 등의 지속적인 신뢰성 있는 환경(예컨대, 단지 부트시 만이 아니라 런타임에 이르기까지)은 외부 엔터티로 배포 이전에 인증 프로토콜 넌스를 사용하여 상태 정보에 서명할 수 있다. 현재 검증된 신뢰할 수 있는 프로세스에 의해 임시 부트 키를 사용하여 보고의 섹션들이 서명될 수 있고, 따라서 나중의 프로세스는 유효성 확인을 위해 이 상태를 외부 엔터티에 제시할 수 있다.
인증 프로토콜에서 교환되는 수정된 랜덤 넌스(들)가 사용될 수 있고, 이러한 수정된 넌스(들)는 시도 응답 및 예상된 시도 응답 계산에의 입력으로서 사용될 수 있다. 즉, 장치 자체에서, 장치의 TrE는 (예컨대, 무결성 검사를 통과하는 경우) 응답 계산에의 입력에서 인증 서버로부터 수신되는 랜덤 넌스(들)를 사용하여, 그의 인증 응답을 정상적으로 계산하려고 시도할 수 있다. 전체 장치에 대한 무결성 검사가 실패하는 경우 그렇지만, 예를 들어, '재난/복원 기능'의 무결성 검사 등의 장치의 부분 기능의 무결성 검사가 성공하는 경우, TrE는 응답에 대한 다른 값을 계산할 수 있다(이 때, 수신된 넌스의 수정된 버전을 사용함). 이러한 수정이 어디서/어떻게 수행되는지는 인증 서버가 알고 있을지도 모른다. 이러한 수정의 예는 원래의 넌스의 기지의 위치에 있는 비트 또는 비트의 수를 변경하는 것을 포함할 수 있다. 이러한 방식으로, 장치 및 인증 서버 둘 다는, 원래의 '장치-인증' 응답을 계산하는 것에 부가하여, 수정된 넌스 입력을 사용하여 응답을 계산할 수 있다. 수신기(예컨대, 인증 서버)에서, 서버는 장치로부터 수신하는 응답이 '장치-인증' 응답과 일치하는지를 검사할 수 있다. 이들이 일치하지 않는 경우, 인증 실패를 즉각 발표하는 대신에, 인증 서버는 수신된 응답을 수정된 넌스를 사용하여 계산된 다른 값 응답과 비교할 수 있다. 이들이 일치하는 경우, 인증 서버는, 장치가 전체로서 인증되어 있지 않을 수 있지만, 이 예에서, '재난/복원 기능' 등의 특정의 기능이 인증될 수 있는 것으로 결정할 수 있다.
안전 부트 프로세스 동안, 장치는 각각의 소프트웨어 컴포넌트를 대응하는 TRV와 비교함으로써 컴포넌트의 무결성 실패를 알게 될 수 있고, 이는 컴포넌트의 비트-정확도 및 소스 진정성을 보장하는 데 도움을 줄 수 있다.
검출된 컴포넌트 검사 실패가 무결성 검사 상태 정보 요소에 포착될 수 있다. 이 상태 데이터의 구조체는 보안 목적을 위해 및 보고 및 진단에서의 효율을 위해 다양한 형태들 중 임의의 형태를 취할 수 있다. 이 정보는 정책 측정 절차를 지원하는 현재의 및 후속의 부트 스테이지 및 런타임 프로세스에 의해 판독될 수 있다. 장치의 네트워크 기능 및 다른 기능에 대한 컴포넌트의 의존성을 결정하기 위해 컴포넌트-기능간 맵이 사용될 수 있다. 기능은 연결 엔터티(예컨대, 네트워크 통신사업자) 또는 장치에 의해 지원되는 부가가치 응용 프로그램(예컨대, 모바일 결제)이 의존할 수 있는 그 기능일 수 있다. 통신 사업자 및/또는 응용 프로그램 서비스 공급자는 베어링 트래픽, 복원, 관리 동작 또는 부가가치 응용 프로그램 특징 등의 특정의 작업에 대한 장치의 신뢰성 있는 동작을 위해 어느 기능이 사용될 수 있는지를 정의할 수 있고, 특정의 네트워크 동작을 위해 어느 기능이 사용될 수 있는지를 나타내는 정책을 장치 상에 설정할 수 있다.
한 세트의 네트워크 기능이 네트워크 통신사업자 및/또는 응용 프로그램 서비스 공급자로부터 예상되는 한 세트의 표준 능력으로부터 나올 수 있다. 기능은 무선 기술, 프로토콜 스택에서의 계층, 네트워크 프로토콜, 관리 능력, 보안 및 신뢰 메커니즘, 부가가치 응용 프로그램 특징 등을 포함할 수 있다.
장치의 정책 관리자는 장치 컴포넌트에 따른 네트워크 기능의 의존성을 보여줄 수 있는 임베디드 컴포넌트-기능간 테이블 또는 맵(본 명세서에 기술되어 있음)을 사용할 수 있다. 무결성 검사 및/또는 보고 동안의 이러한 컴포넌트-기능간 테이블 또는 맵의 사용은 도 9에 도시되어 있다. 도 9에 예시된 바와 같이, 장치는, 910에서, 컴포넌트(902)의 무결성 측정을 그의 대응하는 TRV(904)를 사용하여 검사함으로써 무결성 검사를 수행할 수 있다. 무결성 검사가 수행된 후에, 장치 정책 관리 엔터티(908)는, 916에서, 무결성 검사된 하나 이상의 컴포넌트의 컴포넌트 식별자(예컨대, 컴포넌트 주소)를 수신하고, 918에서, 각각의 컴포넌트가 무결성 검사를 통과했는지 실패했는지의 표시를 수신할 수 있다. 정책 관리 엔터티(908)는 네트워크 엔터티로의 송신을 위한 컴포넌트와 연관되어 있는 대응하는 기능을 결정할 수 있다. 예를 들어, 복원을 필요로 하는 실패한 기능이 송신될 수 있거나, 유효성 확인된 기능의 표시가 송신될 수 있다. 예를 들어, 정책 관리 엔터티(908)는, 922에서, 주어진 컴포넌트에 대응하는 컴포넌트 식별자를 검색하기 위해, 920에서, 컴포넌트 주소를 사용할 수 있다. 도 9에 예시된 바와 같이, 컴포넌트 식별자는 컴포넌트 주소 대 컴포넌트 식별자간 매핑을 포함하고 있는 테이블(906)로부터 검색될 수 있다. 정책 관리 엔터티(908)는, 926에서, 주어진 컴포넌트에 대응하는 컴포넌트 기능을 검색하기 위해, 924에서, 컴포넌트 식별자를 사용할 수 있다. 컴포넌트 기능은 컴포넌트 식별자 대 컴포넌트 기능간 매핑을 포함하고 있는 테이블(912)로부터 검색될 수 있다. 정책 관리 엔터티(908)는, 932에서, 네트워크 엔터티와 상호작용하기 위해 (예컨대, 무결성 검사를 통과하거나 실패한) 결정된 기능을 사용할 수 있다. 예를 들어, 정책 관리 엔터티는 무결성 보고를 수행하거나, 장치 정책을 수신하거나, 결정된 기능들 중 하나 이상의 기능에 대응하는 동작 및/또는 제한을 수신할 수 있다. 각각의 기능은 하나 이상의 정책(930)과 연관되어 있을 수 있다. 하나 이상의 기능의 모음은 모두 합하여 장치 내에서 특정의 능력을 가능하게 해줄 수 있다. 이들 능력은 계층적으로 계층화되어 있을 수 있다. 예를 들어, 기본 계층 능력은 그 다음 능력 계층의 서브세트인 그 다음 능력 계층의 서브세트일 수 있고, 이하 마찬가지이다. 능력들의 계층화는 통상적인 계층 및 신뢰 사슬 기반 안전 부트 시퀀스를 반영할 수 있다. 계층은 특정의 능력을 가능하게 해주는 기능들의 임의적인 조합일 수 있거나, 계층적 계층화와 기능들의 특정의 조합의 혼성 조합일 수 있다. 정책 관리 엔터티(908)는, 930에서, 주어진 컴포넌트에 대응하는 하나 이상의 정책을 검색하기 위해, 928에서, 컴포넌트 매핑된 기능을 사용할 수 있다. 정책은 능력 대 다양한 정책간 매핑을 포함하고 있는 테이블(914)로부터 검색될 수 있다. 정책은, 932에 예시된 바와 같이, 네트워크 엔터티로부터 수신될 수 있다.
실패한 컴포넌트로 인해 하나 이상의 실패한 기능이 생길 수 있다. 소프트웨어 개발 및 빌드 도구에 의해 임베딩되는 컴포넌트-기능간 맵 정보는 정책 관리자가 기능의 무결성 검사 실패의 척도를 확인하는 것과, 따라서 장치 및 제조업체와 관련하여 구현에 독립적일 수 있는 표준화된 방식으로 실패(예컨대, 인증 함수 또는 기저대역 무선 프로토콜 스택의 실패)를 보고하는 것을 지원할 수 있다. 장치 상에서, 불변 RoT(root of trust)에 의해 보장되는 이 정보가 수정으로부터 보호될 수 있다.
정책 관리 프로세스는 부트 및 런타임 환경에서 이 정보를 이용할 수 있다. 장치 상에서의 정책 관리 프로세스는, 무결성 검사 프로세스의 결과를 사용하여, 어느 네트워크 기능이 실패가 있는지를 결정할 수 있다. 컴포넌트가 코드가 로더에 의해 검사되고 있는 부트시 동안 이용가능한 참조(예컨대, 심볼 테이블 또는 메모리 주소)에 의해 식별될 수 있다. 검사되고 있는 코드는, 무결성 및 소스 진정성이 검증된 후까지, 실행가능 메모리에서의 사용으로부터 격리될 수 있다. 이와 마찬가지로, 검사된 코드는 로드되고 검사된 때로부터 그리고 실행 동안 (예컨대, 보안된 실행 및 저장, 하드웨어 보호, 암호 보호, 가상화 등에 의해) 보호될 수 있다. 메모리 맵, 액세스 특권 등의 수정에 의해 실행이 방지될 수 있다. 도 9에서 테이블(906 및 912)에 예시되어 있는 예로서, 주소 위치 x에 있는 코드는 네트워크 기능 F1, F5 및 F14에 매핑될 수 있는 컴포넌트 A에 대응할 수 있다. 이 코드는, 예를 들어, 몇개의 통신 프로토콜이 의존하는 원시 해싱 함수(primitive hashing function)일 수 있다. 무결성 보고 및 복원이 실패한 프리미티브(primitive)에 의존할지도 모른다. 따라서, 이들 무결성 보고 및 복원 기능이 기본 지원 기능으로서 네트워크 표준화 목록에 포함될 수 있다.
기능 실패의 표준화된 목록은 장치의 능력에 관한 세밀한 정보를 네트워크에 제공할 수 있다. 원격 장치의 경우, 장치가 여전히 무엇을 달성할 수 있는지에 대한 확실한 이해가 문제점을 복원하기 위해 자원을 적용하는 데 유용할 수 있다. 재난의 경우에, 네트워크가 재난 표시 자체(예컨대, 소스, 시간 및 정확도)의 무결성을 유효성 확인할 수 있도록 실패를 안전하고 보장된 방식으로 알려줄 수 있는 것은 경보 오류 하에서 고비용의 네트워크 자원의 불필요한 사용을 방지할 수 있다.
도 10은 예시적인 시스템 컴포넌트를 포함하는 보고 및 복원 시스템의 예시적인 개요를 제공한다. 도 10에 예시된 바와 같이, 장치(1004)의 컴포넌트 상의 1002에서 실패가 검출될 수 있다. 이 실패는 네트워크에 통보될 수 있다. 예를 들어, 이 실패는 1008에서 네트워크에 보고되는 장치 보고(1006)에 포함될 수 있다. 이 실패는, 예를 들어, 실패한 컴포넌트와 연관되어 있는 실패한 네트워크 기능으로서 통보될 수 있다. 실패가 네트워크에 보고될 때, 네트워크는 액세스 제어에 관해 세밀한 결정을 할 수 있다. 예를 들어, 네트워크 플랫폼 유효성 확인 엔터티(1010)는 보고된 기능 검사 보고(1006)에 기초하여 어떤 액세스, 부분 액세스 또는 전체 액세스도 허용하지 않을 수 있다. 1016에서, 액세스 결정이 장치(1004)에 의해 수신될 수 있다. 장치 보고(1006)에서 실패가 통보되는 경우, 네트워크 플랫폼 유효성 확인 엔터티는 기능 보고를 장치 관리 서버(1012)로 전송할 수 있고, 장치 관리 서버(1012)는 기능-컴포넌트간 매핑 정보(1014)로부터 실패한 컴포넌트(들)를 결정할 수 있다. 이 정보는 장치(1004)를 복원하고 실패한 소프트웨어 컴포넌트를 장치(1004)에 재로드하는 데 사용될 수 있다. 예를 들어, 장치 관리 서버(1012)는 실패한 컴포넌트와 연관되어 있는 실패한 기능의 범위를 좁히기 위해 1018에서 장치(1004)를 조사할 수 있다. 무결성 실패가 효율적인 복원을 위해 장치(1004)의 한 섹션으로 격리된 후에, 장치 관리 서버(1012)는, 예를 들어, 코드 빌드 배포 엔터티(code build release entity)(1022) 등에 1020에서 소프트웨어 업데이트(예컨대, 교체 컴포넌트)를 요청할 수 있다. 장치 관리 서버(1012)는 실패한 컴포넌트를 복원하기 위해 1024에서 소프트웨어 업데이트를 장치(1004)에 제공할 수 있다. 제조업체의 장치 상에서의 이러한 형태의 특정의 실패한 코드의 추상화는 (통신사업자가 연결되어 있는) 장치를 긴밀하게 알아내야 하는 통신사업자에 대한 부담을 감소시키지만, 이와 동시에, 실패한 기능에 기초하여 세밀한 액세스 제어 및 복원 결정을 가능하게 해줄 수 있다.
실행 흐름 실패는 프로세스 체인에서 호출될 수 있는 컴포넌트에 대한 실패일 수 있다. 컴포넌트의 실행은 상위 레벨의 보장을 유지하면서 장치의 능력을 확장시킬 수 있다. 현재의 검증된 프로세스가 그 다음 프로세스의 코드(및 어쩌면 장치의 구성)의 무결성을 검사하고 그 코드가 실패가 있다는 것을 발견할 때 실행 흐름 실패가 검출될 수 있다. 후속 부트 코드에서의 실패는 현재의 신뢰성 있는 프로세스가 현재의 상태를 마지막으로 알려진 양호한 상태로 로크-다운하는 것; 프로세스의 제어를 대기 모드에 유지하는 것; 재난 프로세스에 제어를 넘겨 주는 것; 및/또는 제어를 신뢰할 수 없는 프로세스로 넘겨 주는 것 중 하나 이상을 수행할 수 있다는 것을 의미할 수 있다. 실패한 스테이지에 대한 인증 및 식별 키가 추가의 프로세스로부터 배제될 수 있고, 따라서 신뢰할 수 없는 프로세스는 보고(예컨대, 서명된 상태) 또는 인증 기법(예컨대, 자율적 유효성 확인)을 통해 유효한 상태를 네트워크에 통보할 수 없을지도 모른다.
효율을 위해, 장치로부터 네트워크로 송신된 실패 보고는 세밀한 게이트웨이 액세스 제어를 수행하기 위해 그리고 네트워크의 장치 관리 엔터티에 장치 실패를 통보하기 위해 통신 사업자 네트워크 유효성 확인 기능으로부터의 동작을 프롬프트하는 데 사용되는 최소량의 정보를 포함할 수 있다. 관리 엔터티는 실패의 근본 원인을 확인하기 위해 그리고 어느 코드가 복원될 수 있는지를 결정하기 위해 제조업체 관련 정보를 볼 수 있다. 관리 엔터티는, 그 엔터티가 액세스 제어 및/또는 복원에 대한 추가의 정책 결정을 할 수 있게 해주기 위해, 추가 정보를 다시 네트워크 유효성 확인 기능에 제공할 수 있다.
실패 보고에 포함될 수 있는 한 세트의 예시적인 실패한 기능이 이하의 표 1에 기술되어 있다.
실패한 기능 목록
(코드, 데이터, 파라미터)
LTE
기저대역 영역
표 1: 실패한 기능에 대한 예시적인 무결성 위반(TrE에 의해 서명되는 실패 보고)
결과(통과 또는 실패)의 기능 보고가 송신될 수 있다. 표 2는 이러한 목록의 예를 제공한다.
기능(코드, 데이터, 파라미터) 상태(실패 또는 통과)
전체적인 결과
LTE
UMTS
코어 게이트웨이 통신
관리 통신
WiFi
UlCC/스마트카드 채널
응용 프로그램 영역
기저대역 영역
표 2: 기능에 대한 예시적인 무결성 위반(TrE에 의해 서명되는 보고)
기능 보고는 인증 동안 게이트웨이 인증을 위해 사용되는 것과 같은 대안의 채널을 통해 페이로드에서 전송될 수 있고, 따라서 게이트웨이 인증이 실패하더라도, 보고가 인증 시퀀스에서 페이로드로서 송신될 수 있다. 페이로드는 장치의 신뢰성 있는 실행 환경에 의해 서명될 수 있다.
신뢰 실행 환경(TrE)는 (예컨대, 편의상 또는 중복을 위해) 그 자신의 기능 필드를 가질 수 있다. 그렇지만, 기능 또는 재난 페이로드의 목록이 TrE에 의해 서명되거나 인증 키가 TrE에 의해 보호되는 경우, 네트워크에의 접속 시에 TrE의 무결성을 알 수 있다. TrE의 서명 키(들)가 실패에 안전한 봉인 방법(fail-secure sealing method)에 의해 보호될 수 있다. 즉, TrE가 손상된 경우, 그의 키(들)가 (예컨대, 장치 또는 그의 내부 기능 및 인터페이스에서, I/O 및 테스트 포트에서 및 외부 네트워크 엔터티에서) 이용가능하지 않을지도 모른다.
실패 또는 경보의 경우에, 서비스 제공 네트워크 엔터티는 재난을 당한 장치가 실패를 신뢰성있게 보고하는 특징을 가지며 재난을 당한 장치의 메커니즘이 고장나지 않았다는 것을 검증할 수 있다. 2가지 형태의 보장은 보고 메커니즘이 신뢰할 만하다는 것을 네트워크에 알려줄 수 있다. 특정의 유형의 장치가 한 세트의 특정의 신뢰할 수 있는 보고 능력과 부합한다는 인증서 등의 정적 형태의 신뢰성 있는 제3자 보장을 받을 수 있다. 이 보장은 실패 상태의 경보 및 메시지의 처리 및 송신을 위한 장치 능력 및 강건성(또는 신뢰성) 레벨에 관한 정보를 제공할 수 있다. 네트워크 통신사업자는 실패 경보의 경우에 적절히 자동으로 반응하는 절차를 설정하기 위해 인증된 능력을 사용할 수 있다.
다른 형태의 보장은 장치와의 온라인 트랜잭션을 통해 받을 수 있다. 장치 내의 메커니즘은 실패 이벤트 시에 보고 메커니즘의 무결성의 표시를 제공할 수 있다. 이 내부 능력은, 제3자가 부합의 인증서를 제공할 수 있게 해준다는 점에서, 정적 형태의 보장에 관련되어 있을 수 있다.
H(e)NB와 관련한 장치 재난 및 복원에 대한 다양한 프로토콜 흐름이 본 명세서에 기술되어 있을 수 있다. 그렇지만, 본 명세서에 기술되어 있는 개념들이 이러한 실시예로 제한되지 않으며, 임의의 통신 장치에 적용될 수 있다. 도 16에 도시된 예시적인 실시예에 따르면, 장치 무결성 정보가 H(e)NB로부터 SeGW를 통해 관리 서버(H(e)MS)로 송신될 수 있다. 도 17에 도시된 다른 예시적인 실시예에 따르면, H(e)NB가 관리 서버(H(e)MS)에 직접 연결될 수 있다. 도 18a 및 도 18b에 도시된 다른 예시적인 실시예에 따르면, 부분 실패의 경우에 세밀한 액세스 제어를 가능하게 해주기 위해 장치 무결성 검사가 보강될 수 있다. 이들 절차는 네트워크 내의 복원 엔터티로부터 수신된 복원 데이터를 사용하여 DRF에 의해 변경될 수 있는 DRF의 제어 하에서 코드 또는 데이터 블록의 복원을 가능하게 해줄 수 있다. 시스템 아키텍처가 이러한 변경을 허용하는 경우, 그것은 소프트웨어와 또한 소프트웨어 또는 하드웨어 구성 데이터의 변경을 포함할 수 있다. 예시된 흐름은 소프트웨어 복원에 관한 것일 수 있지만, 그것으로 제한되지 않는다.
조사가 네트워크 관리자 엔터티와 장치 자체 사이에서 수행될 수 있고, 그 동안 초기에 보고된 것보다 더 미세한 세분성으로 장치의 실패한 무결성에 관한 상세한 정보가 추출된다. 이 정보는 실패의 원인을 발견하게 해주고, 컴포넌트의 어느 부분에 실패가 있는지를 나타내며, 소프트웨어 다운로드의 크기를 감소시키고 따라서 네트워크 대역폭의 요구와 코드 다운로드의 크기 간의 균형을 맞춤으로써 효율적인 장치 관리를 위한 코드 및/또는 구성의 보다 세밀한 수리를 가능하게 해줄 수 있다. 예시적인 실시예에 따르면, IP(internet protocol)를 사용하여 관리된 네트워크 장치는 장치 관리를 위해 TR-069(CPE WAN)를 이용할 수 있다. 이 프로토콜은 "ACS(auto configuration server, 자동 구성 서버)"에의 액세스를 제공할 수 있다. ACS 응용 프로그램은 표 3에 나타낸 바와 같은 프로토콜 스택에서의 몇가지 능력을 사용할 수 있다.
ACS
RPC 방법
SOAP
HTTP
SSL/TLS
TCP/IP
표 3: TR-069 프로토콜 스택
이 스택은 TR-069 연결된 관리 서버에 고보장 재난 표시를 제공할 수 있는 RoT 프로세스에 의해 액세스가능할 수 있다. 그렇지만, 각각의 계층의 특징들의 전체 목록이 재난 상황에서 사용되지 않을 수 있고, 따라서 장치를 다시 전체 관리 및 장치 기능으로 안전하게 부트스트랩하는 데 사용되는 그 절차를 수행하도록 스택이 조정될 수 있다.
도 11은 수행될 수 있는 동작을 결정하기 위해 장치에서 정보를 수집하는 예시적인 호 흐름도를 나타낸 것이다. 무결성 실패가 일어날 때, H(e)NB(1102) 등의 장치(예컨대, TR-069 장치)와 H(e)MS(1104) 등의 네트워크 엔터티 사이에서 도 11에 예시된 시퀀스가 일어날 수 있다. 1106에서, H(e)NB(1102)와 H(e)MS(1104) 사이에 연결(예컨대, TR-069 연결)이 설정될 수 있다. 예를 들어, H(e)NB(1102)는, 1106에서, 그의 TrE 또는 RoT를 사용하여 연결을 설정할 수 있다. 1108에서, H(e)NB(1102)는, 예컨대, 정보 요청 및/또는 경보를 사용하여 무결성 실패를 H(e)MS(1104)에 보고할 수 있다. H(e)MS(1104)는, 1108에서, 경보를 수신할 수 있고, 1110에서, 정보 응답 메시지(예컨대, TR-069 정보 응답)를 사용하여 H(e)NB(1102)에 응답할 수 있다.
대략적으로, 장치의 각각의 소프트웨어 컴포넌트는 대응하는 TRV를 가질 수 있다. 본 명세서에 기술된 바와 같이, 컴포넌트가 참조와 일치하지 않을 때, 컴포넌트는 무결성 실패를 가질 수 있다. 어떤 컴포넌트는 꽤 클 수 있다. 예를 들어, 운영 체제는 단일의 TRV를 갖는 단일의 모놀리딕 코드 블록으로서 전달될 수 있다.
도 12는 컴포넌트에서의 실패(들)의 위치(들)를 격리시키기 위해 조사를 위한 예시된 호 흐름도를 나타낸 것이다. 조사 프로세스 동안, 예를 들어, H(e)MS 등의 네트워크 관리자 엔터티(1204)는, 예를 들어, H(e)NB 등의 장치(1202)와 상호작용하여, 검출된 실패를 복원하기 위해 수행될 수 있는 조치를 결정하기 위해 부가의 정보를 수집할 수 있다. 한 예시적인 실시예에 따르면, 장치(1202)는 네트워크 관리자 엔터티(1204)와 상호작용하기 위해 TrE 또는 RoT를 사용할 수 있다.
네트워크 관리자 엔터티(1204)는 전체 코드 이미지의 모놀리딕 다운로드를 수행하기로 결정할 수 있다. 다운로드는 현재의 코드 이미지 또는 업데이트된 코드 이미지의 재로드로 이루어져 있을 수 있다. 전체 이미지가 네트워크 관리 엔터티(1204)로 다운로드될 수 있기 때문에, TRV(원본 또는 업데이트)가 다운로드된 이미지에 포함될 수 있다. 네트워크 관리자 엔터티(1204)는, 전체 코드 이미지의 모놀리딕 다운로드를 하기보다는, 실패한 것으로 보고된 컴포넌트를 다운로드하기로 결정할 수 있다. 업데이트의 경우에 TRV를 포함하는 전체 컴포넌트가 장치(1202)로 다운로드될 수 있기 때문에, 이미지가 현재의 컴포넌트 또는 업데이트된 컴포넌트의 재로드일 수 있다. 업데이트된 컴포넌트의 경우에, 클라리언트 관리 엔터티는 전체 이미지의 무결성 및 구조가 영향을 받지 않도록 기존의 코드 이미지를 관리할 수 있다.
도 12에 예시된 바와 같이, 1206에서, 무결성 실패가 검출될 수 있다. 예를 들어, 본 명세서에 기술되어 있는 바와 같이, 장치(1202)의 컴포넌트에서 무결성 실패가 검출될 수 있고, 무결성 검사 보고가 네트워크 관리자 엔터티(1204)로 송신될 수 있다. 1208에서, 장치(1202)와 네트워크 관리자 엔터티(1204) 사이에 연결(예컨대, TR-069 연결)이 설정될 수 있다. 1210에서, 네트워크 관리자 엔터티(1204)는 장치(1202)에서의 무결성 실패와 연관되어 있는 경보에 관련되어 있는 파라미터에 대한 요청을 장치(1202)로 송신할 수 있다. 1212에서, 장치(1202)는 경보 상세를 포함하는 파라미터 응답을 네트워크 관리자 엔터티(1204)로 송신할 수 있다. 1214에서, 네트워크 관리자 엔터티(1204)는 복원을 위해 장치 상의 컴포넌트의 무결성 실패를 좁히기로 결정할 수 있다. 무결성 실패를 좁히기 위해, 1216에서, 네트워크 관리자 엔터티(1204)는 보다 세밀한 측정을 하기 위해 파라미터 요청을 장치(1202)로 송신할 수 있다. 1218에서, 장치(1202)는 장치(1202) 상의 컴포넌트의 측정을 행할 수 있다. 1220에서, 네트워크 관리자 엔터티(1204)는 참조에 대한 측정을 행할 수 있다. 예를 들어, 네트워크 관리자 엔터티(1204)는 동작 중에 참조값을 발생할 수 있는데, 그 이유는 컴포넌트의 측정이 컴포넌트 제작자에 의해 제공되지 않을 수 있고 동적 세분성으로 장치(1202)에 의해 행해질 수 있기 때문이다. 예를 들어, 네트워크 엔터티(1204)에 의해 행해지는 참조에 대한 측정이 장치(1202)에 의해 행해지는 컴포넌트의 측정과 비교될 수 있다. 1222에서, 장치(1202)는 장치(1202)가 보다 세밀한 무결성 측정을 했거나 할 것임을 나타내는 파라미터 응답을 네트워크 관리자 엔터티(1204)로 송신할 수 있다.
1224에서, 네트워크 관리자 엔터티는 제1 노드(들)[예컨대, 컴포넌트(들)]의 무결성 측정에 대한 파라미터 요청을 송신할 수 있다. 1226에서, 장치(1202)는 제1 노드(들)의 무결성 측정을 나타내는 파라미터 응답을 네트워크 관리자 엔터티(1204)로 송신할 수 있다. 1228에서, 네트워크 관리자 엔터티(1204)는 장치(1202)로부터의 그 다음 노드(들)[예컨대, 컴포넌트(들)]의 측정에 대한 파라미터 요청을 송신할 수 있다. 예를 들어, 장치(1202)로부터 수신된 제1 노드(들)의 측정에 기초하여 그 다음 노드(들)의 측정이 요청될 수 있다. 그에 부가하여, 그 다음 노드(들)는 제1 노드(들)의 일부분 또는 서브컴포넌트일 수 있다. 1230에서, 장치(1202)는 그 다음 노드(들)의 요청된 측정을 포함하는 파라미터 응답을 네트워크 관리자 엔터티(1204)로 송신할 수 있다. 예를 들어, 1232에 나타낸 바와 같이, 효율적인 복원을 위해, 무결성 실패가 장치(1202)의 섹션(예컨대, 컴포넌트, 함수 또는 그의 일부분)으로 격리될 때까지, 네트워크 관리자 엔터티(1204)로부터의 파라미터 요청 및 장치(1202)로부터의 파라미터 응답이 반복될 수 있다. 무결성 실패가 식별되고 격리된 후에, 1234에서, 장치(1202)와 네트워크 관리자 엔터티(1204) 사이의 연결(예컨대, TR-069 연결)이 닫힐 수 있다.
네트워크 관리자 엔터티(1204)는 실패를 검출한 후에 추가로 더 조사하고 모놀리딕 블록 또는 컴포넌트의 다중 측정을 행하기로 결정할 수 있다. 장치(1202)는 무결성 측정을 수행하고 및/또는 빠른 참조를 위한 이들을 데이터 구조체(예컨대, 이진 트리)에 정렬할 수 있다. 네트워크 관리자 엔터티(1204)는 동일한 일을 할 수 있다. 이러한 구조체는 단일 블록에서의 다수의 실패를 보여줄 수 있고, 따라서 네트워크 관리자 엔터티(1204)는 모놀리딕 블록 또는 컴포넌트의 어느 부분이 무결성 검사에 실패했는지를 신속하게 결정할 수 있고, 이는 영향의 범위를 좁힐 수 있고 어쩌면 소프트웨어 다운로드 트래픽을 감소시킬 수 있다. 도 12 및 도 13에 예시된 바와 같이, 컴포넌트 또는 모놀리딕 블록에 대한 TRV보다 더 미세한 세분성으로 오염된 곳을 격리시키기 위해 수정된 블록의 상세가 검사될 수 있다.
세밀한 정보가 컴포넌트 실패에 대한 범위를 좁히는 경우, 네트워크 관리자 엔터티는 전체 블록에 대해서보다는 그 코드 세그먼트에 대한 다운로드 이미지를 생성할 수 있다. 예를 들어, 도 13에 예시된 바와 같이, 몇개의 기능을 지원하는 큰 모놀리딕 컴포넌트(1302) 내에서 실패가 일어날 수 있다. 전체 측정값(1304)이 전체 컴포넌트(1302)와 연관되어 있을 수 있는데, 그 이유는 전체 컴포넌트(1302)가 무결성 검사에 실패할 수 있기 때문이다. 1306에서, 장치와 네트워크 관리자 엔터티 간의 조사를 통해 세밀한 측정이 발생될 수 있다. 조사로 인해, 더 세밀한 무결성 측정이 큰 모놀리딕 컴포넌트(1302) 내에서 세그먼트[예를 들어, 세그먼트(1308) 등]의 실패를 찾아낼 수 있다. 조사 후에, 무결성 검사로부터 얻어지는 전체 측정값(1310)은, 예를 들어, 큰 모놀리딕 컴포넌트 전체와 연관되어 있는 측정값(1304)보다는, 세그먼트(1308)의 측정값 7을 포함할 수 있다. 세그먼트(1308)에서 실패가 식별된 후에, 수리 패치(repair patch)가 이 세그먼트로 국소화될 수 있다. 수리 패치는 무결성 검사를 통과한 큰 모놀리딕 컴포넌트(1302) 내의 다른 세그먼트를 사용하여 세그먼트(1308)에서의 실패를 수리하는 것에 대한 명령어를 포함할 수 있다.
발생된 무결성 측정의 수가 장치의 유형에 기초하여 제한될 수 있다. 다운로드된 서브컴포넌트가 현재의 컴포넌트의 재로드일 때, 재로드를 수행하기 위해 장치에 의해 어떤 부가의 정보도 사용되지 않을 수 있다. 그렇지만, 서브컴포넌트 다운로드가 기존의 컴포넌트에 대한 업데이트인 경우, 그 서브컴포넌트에 대한 업데이트된 TRV가 다운로드에 포함될 수 있다. 동일한 업데이트된 컴포넌트 이미지를 생성하기 위해 장치 클라이언트 및 네트워크 관리자 엔터티가 동기화될 수 있고, 따라서 업데이트된 TRV가 업데이트된 컴포넌트 이미지의 해쉬와 일치한다. 장치 관리 클라리언트는 전체 이미지의 무결성이 영향을 받지 않도록 기존의 코드 이미지를 관리할 수 있다.
조사 프로세스에 의해, 장치 상에서의 네트워크 액세스 제어를 수정하기 위해 네트워크 유효성 확인, 인증 및/또는 게이트웨이 엔터티로 피드백될 수 있는 보고된 실패한 기능의 목록의 네트워크 버전이 수정될 수 있다.
조사 프로세스는 반복적 측정 방식을 사용하여 컴포넌트 실패를 격리시킬 수 있고, 그로써 네트워크 관리자 엔터티 및 장치는 점진적으로 측정을 발생하여, 실패를 나타내는 그 서브섹션 상의 이미지 상의 시야를 좁힐 수 있다. 이 방법은 주어진 분해능에 대해 사용되는 측정값의 수를 감소시킬 수 있고, 그로써 메모리 제약된 장치에 대한 측정과 분해능 간의 절충을 가능하게 해준다. 이 조사 프로세스의 한 예시적인 실시예가, 예를 들어, 도 14에 예시되어 있을 수 있다. 도 14에 예시된 바와 같이, 컴포넌트(1402)에서 실패가 발견될 수 있고, 전체 측정값(1404)이 전체 컴포넌트(1402)와 연관될 수 있다. 컴포넌트(1402)에서 실패가 발견된 후에, 장치 및 네트워크는 조사를 수행할 수 있고, 조사에 기초하여, 장치는 컴포넌트(1402)에 대해 제1 측정 반복을 수행할 수 있다. 예를 들어, 제1 측정 반복에서, 장치는 컴포넌트(1402)의 서브섹션(1406) 및 서브섹션(1408)에 대해 독립적인 측정을 수행할 수 있다. 그 결과, 장치는 서브섹션(1406)이 무결성 검사를 통과한 것으로 결정할 수 있는 반면, 서브섹션(1408)은 무결성 실패의 원인을 포함한다. 이것은 서브섹션(1406)과 연관되어 있는 측정값 1 및 서브섹션(1408)과 연관되어 있는 측정값 2로 표시될 수 있다. 서브섹션(1408)이 여전히 무결성 검사에 실패하기 때문에, 전체 측정값(1404)은 여전히 컴포넌트(1402)가 무결성 실패를 포함한다는 것을 나타낼 수 있다.
무결성 실패가 서브섹션(1408)까지 좁혀지지만, 장치 및 네트워크는 복원을 위한 점진적으로 더 세밀한 측정을 발생하기 위해 부가의 조사 절차를 수행할 수 있다. 조사의 결과로서, 장치는 컴포넌트(1402)에 대해 제2 측정 반복을 수행할 수 있다. 도 14에 예시된 바와 같이, 서브섹션(1408)에 대해 제2 측정 반복이 수행될 수 있는데, 그 이유는 이것이 무결성 실패의 원인인 것으로 결정된 서브섹션이었기 때문이다. 장치는 제2 반복에서 서브섹션(1410 및 1412)에 대해 독립적인 측정을 수행할 수 있고, 이는 각각 측정값 3 및 측정값 4를 생성할 수 있다. 서브섹션(1410 및 1412)은 서브섹션(1408)의 서브섹션일 수 있다. 측정값 3은 서브섹션(1408)의 서브섹션(1410)이 무결성 검사를 통과했다는 것을 나타낼 수 있다. 그렇지만, 측정값 4는 서브섹션(1412)이 무결성 검사에 실패했다는 것을 나타낼 수 있고, 컴포넌트(1402)의 무결성 검사 실패의 원인을 포함한다.
무결성 실패가 서브섹션(1412)으로 좁혀지지만, 장치 및 네트워크는 복원을 위한 점진적으로 더 세밀한 측정을 발생하기 위해 부가의 조사 절차를 수행할 수 있다. 예를 들어, 장치는 제3 측정 반복을 수행할 수 있다. 서브섹션(1412)에 대해 제3 측정 반복이 수행될 수 있는데, 그 이유는 제2 측정 반복 후에 서브섹션(1412)이 무결성 실패의 원인인 것으로 결정된 서브섹션이었기 때문이다. 도 14에 예시된 바와 같이, 장치는 서브섹션(1414 및 1416)에 대해 독립적인 측정을 수행할 수 있다. 장치는 서브섹션(1414)이 무결성 실패의 원인을 포함하는 것으로 결정할 수 있다. 이것은, 예를 들어, 측정 값 5로 표시될 수 있다. 제3 측정 반복 후에, 서브섹션(1414)과 연관되어 있는 기능이 무결성 실패의 원인을 포함하는 컴포넌트(1402)의 세밀한 서브섹션에 대응하는 네트워크로 송신될 수 있다. 조사의 결과로서, 네트워크는 서브섹션(1414)으로 국소화될 수 있는 수리 패치(예컨대, 서브컴포넌트의 교체 또는 수리)를 결정하고 서브섹션(1414)의 교체 또는 수리를 위해 수리 패치를 장치로 송신할 수 있다. 도 14가 네트워크와 장치 사이의 조사의 결과로서 장치에서 수행되는 제3 측정 반복을 나타내고 있지만, 무결성 실패를 포함하는 컴포넌트의 일부분을 격리시키기 위해 임의의 수의 측정 반복이 수행될 수 있다. 예시적인 실시예에서, 반복의 횟수는 서비스 제공자에 기초하고 있다. 다른 예시적인 실시예에서, 장치 관리 서버는 장치 ID 및 소프트웨어 배포판 번호를 포함하는 다양한 기준에 대응하는 실패의 데이터베이스를 유지한다. 실패 정보는, 예를 들어, 장치 관리 서버가 조사 전략을 평가할 수 있게 해줄 수 있다.
트리의 완전한 발생 등의 이 점진적인 방식 대 다른 알고리즘의 값을 결정할 시에 네트워크 통신, 측정 계산 및 측정 계산을 위한 값의 로딩의 비용 간의 비교가 가중될 수 있다.
점진적인 방법에서, 실패의 범위가 좁혀짐에 따라 측정이 행해질 수 있다. 코드/데이터가 반복하여 측정될 수 있다. 재측정될지도 모르는 코드/데이터의 양을 감소시키기 위해 혼성 방식이 사용될 수 있고, 이는, 예를 들어, 초기에 이미지를 어떤 최적의 수의 서브섹션으로 분할할 수 있다. 이미지를 어떤 인자로 나누는 것에 의해, 실패한 섹션(들)이 추가로 점진적으로 분석될 수 있다. 반복마다 그리고 최소의 대역폭 및 최소의 전력 소모를 사용하여 네트워크에 걸친 실패 격리 및 결정의 비율을 최적화하기 위한 다른 시간 지연 및 성능 고려사항에 기초하여 이 인자가 결정될 수 있다. 실패 격리 프로세스를 촉진시키기 위해, 네트워크는 주어진 컴포넌트 실패에 대한 해쉬 트리 등의 데이터 구조체로 한 세트의 예상된 해쉬를 사전 발생하고 이 서브-TRV 측정의 트리를 장치로 송신할 수 있다. 이것에 의해 장치는 이 점진적인 방식에서 트리의 최고 분해능까지 비교를 할 수 있다. 네트워크는 (예컨대, 정정될 필요가 있는 장치의 수에 기초하여) 복원 절차를 최적화하기 위해 더 많은 분해능이 필요한지를 결정할 수 있다. 더 많은 분해능이 필요한 경우, 보다 정확한 위치에서 시작하는 새로운 트리가 발생되고 네트워크에 의해 송신될 수 있거나, 비교가 상호작용적으로 수행될 수 있다.
소프트웨어 또는 데이터 업데이트의 경우에, 소프트웨어 관리 서버는 업데이트를 수행하기 위해 파일에서의 간단한 이진 차이에 대해 코드/데이터 업데이트를 수행할 수 있다. 장치 관리 클라리언트는 이진 업데이트를 수신하고 그의 무결성을 보장하기 위해 전체 코드 이미지에 대해 수정을 수행할 수 있다. 소프트웨어 관리 엔터티가 소프트웨어 업데이트 동안 트래픽의 양을 감소시키기 위한 조사 기법을 포함하도록 이진 차이의 동일한 원리가 확장될 수 있다. 즉, 소프트웨어 업데이트 절차는 이진 트리 검색을 비롯한 본 명세서에 기술되어 있는 동일한 복원 기법들 중 다수를 포함할 수 있다.
도 15는 재난 경보 및 모놀리딕 코드 교체에 관련된 예시적인 호 흐름도를 나타낸 것이다. 호 흐름이 H(e)NB를 사용하여 기술되어 있지만, 다른 네트워크 장치가 사용될 수 있다. 호 흐름 시퀀스는 본 명세서에 기술되어 있는 단계들 중 하나 이상의 단계를 포함할 수 있다. 예를 들어, 도 15에 예시된 바와 같이, 1512에서, H(e)NB(1502)는 안전 부트 시퀀스를 수행할 수 있다. 무결성 검사 단계(1514) 동안, H(e)NB(1502)는 동작을 위해 사용되는 코드에서 무결성 실패를 발견할 수 있고, 따라서, H(e)NB(1502)의 TrE는 SeGW(1504) 인증을 위한 비밀 키를 이용할 수 없을지도 모른다. 그렇지만, TrE는 H(e)NB(1502)가 H(e)MS(1506) 동작을 위해 통과했다는 것을 인식할 수 있다. 예를 들어, H(e)NB(1502)는 경보를 H(e)MS(1506)로 송신할 수 있고, 및/또는 H(e)NB(1502)가 할 수 있는 절차에 대한 H(e)MS(1506) 인증을 위해 비밀 키를 이용할 수 있을지도 모른다. 1516에서, H(e)MS(1506)는 H(e)NB(1502)와 IP 연결(예컨대, SSL/TLS 개시)을 설정할 수 있다. 1518에서, H(e)NB(1502)는 H(e)MS(1506)에 무결성 실패를 경보할 수 있다. 예를 들어, H(e)MS(1506)는 H(e)NB(1502)로부터 재난 경보를 수신할 수 있고, 1520에서, (예컨대, 재로드 또는 업데이트에 대한) 코드 복원 요청을 소프트웨어 복원 엔터티(1510)로 송신할 수 있다. 1522에서, 소프트웨어 복원 엔터티(1510)는 소프트웨어 빌드를 수행할 수 있다. 1524에서, 소프트웨어 복원 엔터티(1510)는 H(e)MS(1506)에 모놀리딕 컴포넌트 교체를 제공할 수 있다. 예를 들어, 소프트웨어 복원 엔터티(1510)는 H(e)MS(1506)에 모놀리딕 복원 이미지를 제공할 수 있다. H(e)MS(1506)는 H(e)NB(1502)와 보안 연결을 설정할 수 있다. 예를 들어, 1526에서, H(e)MS(1506)는 (예컨대, SSL/TLS 개시를 통해) H(e)NB(1502)와 보안 IP 연결을 설정할 수 있다. 소프트웨어/펌웨어 다운로드가 H(e)NB(1502)를 수리할 수 있게 해주기 위해, H(e)NB(1502) 및 H(e)MS(1506)가 인증될 수 있다. 1528에서, H(e)MS(1506)는 H(e)NB(1502)의 소프트웨어/펌웨어를 업데이트할 수 있고, H(e)NB(1502)를 재부트할 수 있다. 1530에서, H(e)NB(1502)는 재부트하고 및/또는 무결성 검사를 재시작할 수 있다.
도 16은 원격 소프트웨어 재난/복원에 관련된 예시적인 호 흐름도를 나타낸 것으로서, 여기서, H(e)NB(1602)는 H(e)MS(1606)에 재난을 통지한다. 호 흐름 시퀀스는 본 명세서에 기술되어 있는 단계들 중 하나 이상의 단계를 포함할 수 있다. 그에 부가하여, 호 흐름이 H(e)NB를 사용하여 기술되어 있지만, 다른 네트워크 장치가 사용될 수 있다. 도 16에 예시된 바와 같이, 1612에서, H(e)NB(1602)는 안전 부트 시퀀스를 수행할 수 있다. 1614에서 무결성 검사 단계 동안, H(e)NB(1602)의 TrE는 정상 동작을 위한 코드에서 실패를 발견할 수 있고, 따라서, H(e)NB(1602)의 TrE는 SeGW(1604) 인증을 위한 비밀 키를 이용할 수 없을지도 모른다. 그렇지만, TrE는 H(e)NB(1602)가 H(e)MS(1606)에 안전하게 연결될 수 있다는 것을 인식할 수 있고, 따라서 TrE는 H(e)NB(1602)가 할 수 있는 절차에 대한 H(e)MS(1606) 인증을 위해 비밀 키를 이용할 수 있다. H(e)NB(1602)는 SeGW(1604)에 대해 인증되려고 시도하지 않을 수 있다(또는 어떤 실패로 시도할 수 없다). 1616에서, H(e)NB(1602)는 H(e)MS(1606)와 IP 연결(예컨대, 보안 SSL/TLS 세션)을 설정할 수 있다. 1618에서, H(e)NB(1602)는 H(e)MS(1606)에 H(e)NB(1602) 무결성 검사 상태(예컨대, 무결성 실패)를 경보할 수 있다. H(e)MS(1606)는, 예를 들어, 인증에 의해 또는 TrE-서명된 무결성 상태 페이로드 정보의 서명 검증에 의해, H(e)NB(1602) 무결성 정보의 진정성을 검증할 수 있다. 무결성 검사 상태가 H(e)NB(1602)에 무결성 실패한 것을 나타내는 경우, 1620에서, H(e)MS(1606)는 표시된 실패에 대한 소프트웨어 수리를 결정할 수 있다. 이 소프트웨어 수리는 무결성 실패의 추가적인 조사를 포함할 수 있다. 예를 들어, 1622에서, H(e)MS(1606)는 H(e)NB(1602)를 진단 및/또는 조사할 수 있다. H(e)MS(1606)는 실패의 원인(예컨대, 위치)을 상세히 결정할 수 있고 1624에서, H(e)MS(1606)는 재로드 또는 업데이트에 대한 것일 수 있는 코드 복원 요청을 소프트웨어 복원 엔터티(1610)로 송신할 수 있다. 소프트웨어 복원 엔터티(1610)는, 1626에서, 소프트웨어 빌드를 수행하고, 소프트웨어 수리 정보를 H(e)MS(1606)로 송신할 수 있다. 예를 들어, 소프트웨어 수리 정보는 복원 이미지를 포함할 수 있다. 1630에서, H(e)MS(1606)는 (예컨대, IP 연결을 통해) H(e)NB(1602)와 보안 연결을 설정할 수 있다. 소프트웨어/펌웨어 다운로드가 H(e)NB(1602)를 수리할 수 있게 해주기 위해, H(e)NB(1602) 및 H(e)MS(1606)가 인증될 수 있다. 1632에서, H(e)MS(1606)는 H(e)NB(1602)의 소프트웨어/펌웨어를 업데이트할 수 있고 및/또는 H(e)NB(1602)를 재시작할 수 있다. 1634에서, H(e)NB(1602)는 안전 부트 시퀀스를 수행할 수 있고 및/또는 무결성 검사 프로세스를 재시작할 수 있다. 1636에서 무결성 검사 단계 동안, H(e)NB(1602)의 TrE는 SeGW(1604) 동작을 위해 무결성 검사가 통과되었다는 것을 알고 SeGW(1604) 인증을 위해 사용되는 비밀 키를 이용할 수 있다. 1638에서, H(e)NB(1602) 및 SeGW(1604)는 상호 인증될 수 있고, 1640에서, SeGW(1604)는 인증이 성공적이었다는 것을 H(e)NB(1602)에 알려줄 수 있다.
도 17은 SeGW 인증 시도를 갖는, 원격 소프트웨어 재난/복원에 관련된 예시적인 호 흐름도를 나타낸 것이다. 호 흐름 시퀀스는 본 명세서에 기술되어 있는 단계들 중 하나 이상의 단계를 포함할 수 있다. 그에 부가하여, 호 흐름이 H(e)NB를 사용하여 기술되어 있지만, 다른 네트워크 장치가 사용될 수 있다. 도 17에 예시된 바와 같이, 1712에서, H(e)NB(1702)는 안전 부트 시퀀스를 수행할 수 있다. 1714에서 무결성 검사 단계 동안, H(e)NB(1702)는 SeGW(1704) 동작을 위해 사용되는 코드에서 무결성 실패를 발견할 수 있고, 따라서, H(e)NB(1702)의 TrE는 SeGW(1704) 인증을 위한 비밀 키를 이용할 수 없을지도 모른다. 그렇지만, TrE는 H(e)NB(1702)가 H(e)MS(1706)에 안전하게 연결될 수 있다는 것을 인식할 수 있고, H(e)NB(1702)가 할 수 있는 절차에 대한 H(e)MS(1706) 인증을 위해 비밀 키(들)를 이용할 수 있을지도 모른다. 1716에서, H(e)NB(1702)는, 예를 들어, IKEv2 프로토콜을 사용하는 등에 의해, SeGW(1704)에 대해 인증되려고 시도할 수 있지만, 실패할 수 있다(예컨대, 비밀 인증 키가 이용가능하지 않기 때문임). 1718에서, SeGW(1702)에의 인증이 실패했다는 표시가 H(e)NB(1702)에 제공될 수 있다. 1720에서, H(e)MS(1702)는 (예컨대, SSL/TLS 개시를 통해) H(e)NB(1706)와 보안 IP 연결을 설정할 수 있다. 예를 들어, H(e)NB(1702)와 SeGW(1704) 사이의 실패한 인증 시도에 기초하여 보안 IP 연결이 설정될 수 있다. 1722에서, H(e)NB(1702)는 H(e)MS(1706)에 H(e)NB(1702) 무결성 검사 상태(예컨대, 무결성 성공 또는 실패)를 경보할 수 있다. H(e)MS(1706)는 인증에 의해 또는 TrE-서명된 무결성 상태 페이로드 정보의 서명 검증에 의해, H(e)NB(1702) 무결성 정보의 진정성을 검증할 수 있다. 무결성 검사 상태가 H(e)NB(1702)에 컴포넌트의 무결성 실패한 것을 나타내는 경우, 1724에서, H(e)MS(1706)는 표시된 실패에 대한 소프트웨어 수리를 결정할 수 있다. 이 소프트웨어 수리는 무결성 실패의 추가적인 조사를 포함할 수 있다. 예를 들어, 1726에서, H(e)MS(1706)는 H(e)NB(1726)를 진단 및/또는 조사할 수 있다. H(e)MS(1706)는 실패의 원인을 상세히 결정할 수 있고, 1728에서, (예컨대, 재로드 또는 업데이트에 대한) 코드 복원 요청을 소프트웨어 복원 엔터티(1710)로 송신할 수 있다. 소프트웨어 복원 엔터티(1710)는, 1730에서, 소프트웨어 빌드를 수행하고, 1732에서, 소프트웨어 수리(예컨대, 복원 이미지)를 H(e)MS(1706)에 제공할 수 있다. 1734에서, H(e)MS(1706)는 (예컨대, SSL/TLS 개시를 통해) H(e)NB(1502)와 보안 IP 연결을 설정할 수 있다. 소프트웨어/펌웨어 다운로드가 H(e)NB(1702)를 수리할 수 있게 해주기 위해, H(e)NB(1702) 및 H(e)MS(1706)가 인증될 수 있다. H(e)MS(1706)는, 1736에서, H(e)NB(1736)의 소프트웨어/펌웨어를 다운로드할 수 있고 H(e)NB(1702)를 재시작할 수 있다. 1738에서, H(e)NB(1702)는 안전 부트 시퀀스를 수행하고 및/또는 무결성 검사를 재시작할 수 있다. 1740에서 무결성 검사 단계 동안, H(e)NB(1702)는 무결성 검사가 통과되었다는 것을 알고 SeGW(1704) 인증을 위한 비밀 키를 이용할 수 있다. H(e)NB(1702) 및 SeGW(1704)는, 1742에서, 상호 인증할 수 있고, 1744에서, 성공적인 인증을 알려줄 수 있다.
도 18a는 네트워크가 SeGW를 통해 인증을 허용하지 않을 수 있는, 원격 소프트웨어 재난/복원에 관련된 예시적인 호 흐름도를 나타낸 것이다. 호 흐름 시퀀스는 본 명세서에 기술되어 있는 단계들 중 하나 이상의 단계를 포함할 수 있다. 그에 부가하여, 호 흐름이 H(e)NB를 사용하여 기술되어 있지만, 다른 네트워크 장치가 사용될 수 있다. 도 18a에 예시된 바와 같이, 1812에서, H(e)NB(1802)는 안전 부트 시퀀스를 수행할 수 있다. 1814에서 무결성 검사 단계 동안, H(e)NB(1802)는 동작을 위해 사용되는 코드에서 실패를 발견할 수 있고, 따라서, H(e)NB(1802)의 TrE는 SeGW(1804) 인증을 위한 비밀 키를 이용할 수 없을지도 모른다. 그렇지만, TrE는 H(e)NB(1802)가 H(e)MS(1806)에 안전하게 연결될 수 있다는 것을 인식할 수 있고, 따라서 H(e)NB(1802)가 할 수 있는 절차에 대한 H(e)MS(1806) 인증을 위해 비밀 키(들)를 이용할 수 있을지도 모른다. 1816에서, H(e)NB(1802)는 (예컨대, IKEv2 프로토콜을 사용하여) SeGW(1804)에 대해 인증되려고 시도할 수 있지만, 실패한다(예컨대, 비밀 키가 이용가능하지 않기 때문임). H(e)NB(1802)는 인증 시도 동안 H(e)NB(1802)의 무결성에 관한 TrE-서명된 정보를 제공할 수 있다. 1818에서, SeGW(1804)는 무결성 정보(예컨대, 실패 보고)를 네트워크 유효성 확인 엔터티(1808)로 전달할 수 있다. 네트워크 유효성 확인 엔터티(1808)는, 수신하는 정보에 기초하여, SeGW(1804)를 통한 어떤 H(e)NB(1802) 트래픽을 허용하지 않기로 결정하고, 1820에서, H(e)NB(1802) 트래픽의 일부 또는 전부가 H(e)MS(1806)로 제한되지 않는다는 것을 나타내는 세밀한 액세스 결정을 송신할 수 있다. 1822a에서, SeGW(1804)는 인증 실패의 표시를 송신할 수 있다. 1824에서, 네트워크 유효성 확인 엔터티(1808)는 복원을 위해 H(e)NB(1802) 무결성 정보를 H(e)MS(1806)로 송신할 수 있다. 1826에서, H(e)MS(1806)는 (예컨대, SSL/TLS 개시를 통해) H(e)NB(1802)와 보안 IP 연결을 설정할 수 있다. 1828에서, H(e)MS(1806)는, 예를 들어, 인증 실패에 기초하여, 소프트웨어 수리를 수행하기로 결정할 수 있다. 1830에서, H(e)MS(1806)에 의한 진단 및 조사를 가능하게 해주기 위해, H(e)NB(1830) 및 H(e)MS(1806)가 인증될 수 있다. H(e)MS(1806)는 실패의 원인을 상세히 결정할 수 있고, 1832에서, (예컨대, 재로드 또는 업데이트에 대한) 코드 복원 요청을 소프트웨어 복원 엔터티(1810)로 송신할 수 있다. 소프트웨어 복원 엔터티(1810)는 H(e)NB(1802)에 대한 교체 소프트웨어 컴포넌트(예컨대, 또는 그의 일부분)를 빌드하기 위해, 1834에서, 소프트웨어 빌드를 수행할 수 있다. 1836에서, 소프트웨어 복원 엔터티(1810)는 H(e)MS(1806)에 소프트웨어 수리 정보(예컨대, 복원 이미지)를 제공할 수 있다. 1838에서, H(e)MS(1806)는 (예컨대, SSL/TLS 개시를 통해) H(e)NB(1802)와 보안 IP 연결을 설정할 수 있다. 소프트웨어/펌웨어 다운로드가 H(e)NB(1802)를 수리할 수 있게 해주기 위해, H(e)NB(1802) 및 H(e)MS(1806)가 인증될 수 있다. H(e)MS(1806)는, 1840에서, H(e)NB(1840)의 소프트웨어/펌웨어를 다운로드할 수 있다. 1842에서, H(e)NB(1802)는 재부트될 수 있고 및/또는 다운로드된 코드를 로드하고 실행할 수 있다.
도 18b는 즉각적인 제한된 액세스 및 미세 조정된 액세스 제어를 갖는, 원격 소프트웨어 재난/복원에 관련된 예시적인 호 흐름도를 나타낸 것이다. 호 흐름이 H(e)NB를 사용하여 기술되어 있지만, 다른 네트워크 장치가 사용될 수 있다. 도 18b의 호 흐름 시퀀스는 도 18a에 예시된 호 흐름과 동일하거나 유사한 많은 단계들을 포함할 수 있다. 그렇지만, 도 18b에 예시된 바와 같이, SeGW(1804)에 대한 H(e)NB(1802)의 인증이 성공할 수 있지만, SeGW(1804)는 H(e)NB(1802)에의 액세스를 제한할 수 있다. 예를 들어, 1814에서 무결성 검사 단계 동안, H(e)NB(1802)는 동작을 위해 사용되는 코드에서 실패를 발견할 수 있고, 따라서, H(e)NB(1802)의 TrE는 SeGW(1804) 인증을 위한 비밀 키를 이용할 수 없을지도 모른다. 그렇지만, TrE는 H(e)NB(1802)가 H(e)MS(1806)에 안전하게 연결될 수 있다는 것을 인식할 수 있고, 따라서 H(e)NB(1802)가 할 수 있는 절차에 대한 H(e)MS(1806) 인증을 위해 비밀 키(들)를 이용할 수 있을지도 모른다. 1816에서, H(e)NB(1802)는 (예컨대, IKEv2 프로토콜을 사용하여) SeGW(1804)에 대해 인증되려고 시도할 수 있다. H(e)NB(1802)는 인증 시도 동안 H(e)NB(1802)의 무결성에 관한 TrE-서명된 정보를 제공할 수 있다. 1818에서, SeGW(1804)는 무결성 정보를 네트워크 유효성 확인 엔터티(1808)로 전달할 수 있다. 네트워크 유효성 확인 엔터티(1808)는 수신된 정보에 기초하여 H(e)NB(1802) 액세스에 대한 인증을 위한 결정을 할 수 있고, 이것을 SeGW(1804)로 송신할 수 있다. SeGW(1804)는, 네트워크 유효성 확인 엔터티(1808)로부터의 정보에 기초하여, H(e)NB(1802)를 인증할 수 있지만, H(e)NB(1802) 액세스를 제한할 수 있다. 1822b에서, SeGW(1804)는 인증이 성공했다는 표시를 H(e)NB(1802)로 송신할 수 있지만, SeGW(1804)는 액세스를 제한하였다. 도 18b의 프로토콜 흐름에 예시된 나머지 단계들은 도 18a의 프로토콜 흐름에 예시된 단계들과 동일하거나 유사할 수 있다.
도 19는 SeGW 액세스를 갖는 H(e)NB 소프트웨어 컴포넌트 복원에 관련된 예시적인 호 흐름도를 나타낸 것이다. 호 흐름 시퀀스는 본 명세서에 기술되어 있는 단계들 중 하나 이상의 단계를 포함할 수 있다. 그에 부가하여, 호 흐름이 H(e)NB를 사용하여 기술되어 있지만, 다른 네트워크 장치가 사용될 수 있다. 도 19에 예시된 바와 같이, 1912에서, H(e)NB(1902)는 안전 부트 시퀀스를 수행할 수 있다. 1914에서 무결성 검사 단계 동안, H(e)NB(1902)는 장치 코드에서 실패를 발견하지 않을 수 있지만, 맵에서 실패, 누락 컴포넌트 또는 구성의 결여를 발견할 수 있다. H(e)NB(1902)의 TrE는 SeGW(1904) 인증을 위한 비밀 키를 이용할 수 있다. 예를 들어, 1916에서, H(e)NB(1902)는 (예컨대, IKE를 사용하여) 비밀 키를 포함하는 상태 보고를 SeGW(1904)로 송신할 수 있다. 1818에서, SeGW(1904)는 무결성 정보를 네트워크 유효성 확인 엔터티(1908)로 전달할 수 있다. 네트워크 유효성 확인 엔터티(1908)는 수신된 정보에 기초하여 H(e)NB(1902) 액세스에 대한 인증을 위한 결정을 할 수 있고, 이것을 SeGW(1904)로 송신할 수 있다. 예를 들어, 1920에서, 네트워크 유효성 확인 엔터티(1908)는 통신사업자 정책에 따른 세밀한 액세스 결정을 SeGW(1904)로 송신할 수 있다. SeGW(1904)는, 네트워크 유효성 확인 정보에 기초하여, H(e)NB(1902)를 인증할 수 있고 및/또는 통신사업자 정책에 따라 액세스 허용을 설정할 수 있다. 1922에서, SeGW(1904)는 성공적인 인증의 표시를 H(e)NB(1902)로 송신할 수 있다. 1924에서, 네트워크 유효성 확인 엔터티(1908)는 H(e)NB 무결성 정보를 H(e)MS(1906)로 송신할 수 있다. 예를 들어, 재구성을 위해 무결성 정보가 송신될 수 있다. H(e)MS(1906)는, 1926에서, 실패를 복원하기 위해 사용될 수 있는 복원 정보(예컨대, 소프트웨어/파라미터)를 결정할 수 있고, 1928에서, (예컨대, 재로드 또는 업데이트에 대한) 복원 요청을 소프트웨어 복원 엔터티(1910)로 송신할 수 있다. 소프트웨어 복원 엔터티(1910)는 H(e)NB(1902)에 대한 교체 소프트웨어 컴포넌트(예컨대, 또는 그의 일부분)를 빌드하기 위해, 1930에서, 소프트웨어 빌드를 수행할 수 있다. 1932에서, 소프트웨어 복원 엔터티(1910)는 복원 정보(예컨대, 복원 이미지 또는 소프트웨어/구성 업데이트)를 H(e)MS(1906)에 제공할 수 있다. 1934에서, H(e)MS(1906)는 복원 정보를 SeGW(1904)로 전달할 수 있다. SeGW(1904) 및 H(e)NB(1902)는 인증될 수 있고, 1936에서, (예컨대, IKEv2 또는 IPSec을 사용하여) 보안 IP 연결을 설정할 수 있다. 1938에서, SeGW(1904)는 복원 정보(예컨대, 복원 이미지 또는 소프트웨어/펌웨어 업데이트)를 H(e)NB(1902)로 다운로드할 수 있다. 예를 들어, SeGW(1904)는 실패한 중요하지 않은 소프트웨어/파라미터의 업데이트(예컨대, IKE 및/또는 IPSec 업데이트)를 송신할 수 있다.
장치는 종래의 능력 및 진보된 능력 둘 다를 가질 수 있다. 종래의 능력에 대한 네트워크 서비스가 일반적으로 이용가능할 수 있다. 진보된 능력에 대한 네트워크 서비스는 드물 수 있고 및/또는 완전히 지원되지 않을 수 있다. 배포 문제를 용이하게 해주기 위해, 통신사업자는 진보된 능력에 익숙해지기 위해 종래의 능력을 이용할 수 있다. 이러한 이용은 본 명세서에 기술되어 있는 바와 같이 사용될 수 있다. 예를 들어, 장치가 한 위치에서 종래의 장치로서 네트워크에 접속될 수 있다. 네트워크는 장치를 인증할 수 있고 그의 가입에서 장치가 진보된 능력을 가질 수 있다는 것 및/또는 진보된 능력을 안전하게 지원할 수 있다는 것을 인식할 수 있다. 그 위치에 대한 네트워크가 진보된 능력을 지원하는 경우, 네트워크 관리자 엔터티는 장치의 액세스 포인트에 업데이트 서버에의 세밀한 액세스를 제공할 수 있다. 장치는 종래의 액세스 포인트를 통해 업데이트 서버에 액세스할 수 있다. 일부 구현예에서, 장치의 가입은 액세스를 종래의 서비스가 아니라 진보된 특징으로 제한할 수 있고, 따라서 액세스 포인트는 일반적으로 종래의 네트워크가 아니라 업데이트 서버에의 장치의 액세스를 제한할 수 있다. 업데이트 서버 및 장치는 상호 인증할 수 있다. 업데이트 서버는 장치의 진보된 능력을 (예컨대, 인증을 통해 암시적으로 또는 명시적으로) 유효성 확인하고 및/또는, 장치가 새로운 유형의 장치로서 직접 재연결될 수 있게 해주기 위해, 장치에 액세스 자격 증명, 구성 정보, 액세스 포인트 주소, 및/또는 코드를 제공할 수 있다. 장치는 네트워크 액세스 인증을 위한 공유 또는 비대칭 키 쌍을 발생하는 능력을 가질 수 있다. 네트워크는 새로운 장치 자격 증명으로 장치 가입 데이터 베이스를 업데이트할 수 있다. 장치는 진보된 네트워크 위치에 대한 액세스 자격 증명을 보호된 영역에 포함시키는 능력을 가질 수 있다. 온라인 증명 발생은 진보된 네트워크에 대한 장래의 사전 유효성 확인된 연결을 가능하게 해줄 수 있다. 네트워크는 특정의 자격 증명의 장치가 진보된 네트워크에 접속될 수 있다는 것을 진보된 네트워크(진보된 능력을 지원하는 네트워크)에의 액세스 포인트에 알려줄 수 있다. 장치는 업데이트된 자격 증명을 사용하여 진보된 네트워크에 액세스할 수 있다. 진보된 네트워크 엔터티는 장치를 진보된 장치로서 인증할 수 있다.
관리 인증을 위한 절차의 적어도 2개의 스테이지가 있을 수 있다. 하나는 구성을 위한 것이고 다른 하나는 복원을 위한 것일 수 있다. 구성의 경우에, 네트워크 관리자 엔터티는 중계 노드의 능력을 통신사업자의 코어 네트워크에의 차후의 인증 절차를 위해 통신사업자 인증서를 확실히 설치하는 장치로서 인증할 수 있다. 중계는 플랫폼 인증을 사용한 플랫폼의 자율적 유효성 확인 수단을 통해 암시적인 증명을 네트워크 엔터티에 제공할 수 있다. 관리 엔터티는, 장치를 인증하는 것 및/또는 RN 제조업체 인증서를 유효성 확인하는 것에 의해, RN의 무결성이 손상되지 않았다는 것을 알 수 있다(예를 들어, 장치의 무결성의 내부 검증이 성공적일 때, 자율적 유효성 확인이 비밀 인증 키를 배포할 수 있기 때문임).
복원의 경우에, RN은 관리 엔터티에 의한 원격 수리 절차를 수행할 수 있는데, 그 이유는 어떤 어떤 심각하지 않은 실패가 전체 장치 무결성 검사를 실패하게 만들었기 때문이다. 이 경우에, RN의 관리 능력이 영향을 받지 않으면, RN은 인증을 위해 전체 장치 무결성 인증서가 아니라 관리 능력 인증서를 관리 엔터티로 송신할 수 있다. 네트워크 관리 엔터티는 장치를 인증하고 인증서를 검증할 수 있다. 성공 시에, 네트워크 관리 엔터티는 중계의 능력을 부트스트랩하기 위해 원격 절차를 수행할 수 있다.
후자의 절차는 초기의 제한된 범위의 경우에 RN의 능력을 부트스트랩하기 위해 사용될 수 있다. 이 경우에, 제1 인증서는 관리 엔터티를 사용하여 기본 동작을 수행할 수 있다는 것을 나타낼 수 있다. 제2 인증서는 관리 엔터티를 사용하여 보다 폭넓은 동작을 수행할 수 있다는 것을 나타낼 수 있다. 이 경우에, 중계는 향상된 기능의 범위에서 무결성 실패를 검출하지 않을지도 모른다. 또한 향상된 기능을 수용하기 위해 부가의 업데이트된 정책을 프로비저닝함으로써, 무결성 검사의 범위가 증가될 수 있다. 이러한 방식으로, 장치의 능력이 무결성 검사의 범위와 함께 성장할 수 있다.
이 기법은 일반적으로 보안 게이트웨이 인증에 적용될 수 있다. 장치의 제한된 범위를 나타내는 인증서는 코어 네트워크에 대한 게이트웨이 인증의 경우에 사용될 수 있고, 따라서 네트워크는 인증 동안 인증의 권한을 결정할 수 있다. 게이트웨이(예컨대, HeNB 인증에서의 SeGW 또는 RN 인증에 대한 DeNB)는 장치를 인증하고 인증서를 검증할 수 있다. 인증서 상의 정보 및 특정의 장치 ID의 성공적인 인증에 기초하여, 게이트웨이는 복원 또는 등록을 위한 네트워크 관리 엔터티에의 액세스를 제한할 수 있다. 중계가 성공적으로 구성, 업데이트 및/또는 복원되면, 인증 키가 인증 기반 향상을 위해 이용가능하게 될 수 있다.
도 20은 기능의 중계 노드 부트스트랩에 관련된 예시적인 호 흐름도를 나타낸 것이다. 호 흐름 시퀀스는 본 명세서에 기술되어 있는 단계들 중 하나 이상의 단계를 포함할 수 있다. 예를 들어, 도 20에 예시된 바와 같이, 2014에서, RN(Relay Node, 중계 노드)(2002)은 안전 부트 시퀀스를 수행할 수 있다. 2016에서, RN(2002)은 보안 환경을 설정하고 및/또는 자율적 유효성 확인을 수행할 수 있다. 자율적 유효성 확인 동안, RN(2002)은 실패를 발견하지 않을지도 모른다. 2018에서, RN(2002)은 eNB(2004)를 통해, 예를 들어, MME/HSS(2012) 등의 네트워크에 UE로서 접속될 수 있다. 2020에서, MME(2012)는 RN(2002)에 등록 서버(2008)에의 제한된 액세스를 할당할 수 있다. 도 20에 예시된 바와 같이, 제한된 액세스가 eNB(2004)를 통해 할당될 수 있다. RN(2002) 및 등록 서버(2008)는 상호 인증할 수 있다. 2022에서, RN(2002)은 등록 요청을 등록 서버(2008)로 송신할 수 있다. 2024에서, 등록 서버는 인증서를 유효성 확인, 구성 및/또는 RN(2002)에 발행할 수 있다. 등록 서버(2008)는 RN(2002) 보안 환경이 RN(2002)의 등록 서버 비밀 인증 키의 사용을 배포하는 것을 통해 암시적으로 RN(2002)을 유효성 확인할 수 있거나, 등록 서버(2008)는 RN 보고의 조사에 의해 RN(2002)을 유효성 확인할 수 있다. 등록 서버(2008)는 DeNB(2006) 접속을 위해 유효성 확인된 RN(2002)을 구성하고 인증서를 발행할 수 있다. 등록 서버(2008)는 장래의 재부트 시에 등록 단계를 우회하기 위해 그리고 자율적 유효성 확인 프로세스에서 등록 정보를 포함시키기 위해(예컨대, 등록 정보를 포함하는 TRV를 부가하기 위해) 장치 상의 RN 정책을 업데이트할 수 있다. 새로운 비밀 키가 RN(2002)에 설치되거나 이 스테이지에서 활성화될 수 있다. RN(2002)은 키 발생 능력을 가질 수 있고, 이 경우에 RN(2002)에서 키 쌍이 발생될 수 있다. RN(2002)은 그의 보안 환경에 비밀 키를 설치할 수 있고, 이 키의 배포를 등록 구성 및 하위 레벨 안전 부트 스테이지에 바인딩할 수 있다. 2026에서, 등록 서버(2008)는 등록이 완료되었다는 것을 중계 노드(2002)에 알려줄 수 있다. 2028에서, RN(2002)은 DeNB(2006)를 통해 RN으로서 네트워크에 접속될 수 있다. 2030에서, MME(2012)는 RN(2002)에 DeNB(2006)를 통한 구성 서버(2010)에의 제한된 액세스를 할당할 수 있다. 2032에서, RN(2002)은 RN 구성 요청을 구성 서버(2010)로 송신할 수 있다. 2034에서, 구성 서버(2010)는 인증서를 유효성 확인, 구성 및/또는 RN(2002)에 발행할 수 있다. 예를 들어, 구성 서버(2010)는 동작을 위해 유효성 확인된 RN(2002)을 구성하고 인증서를 발행할 수 있다. 구성 서버(2010)는 장래의 재부트 시에 구성 단계를 우회하기 위해 그리고 자율적 유효성 확인 프로세스에서 구성 정보를 포함시키기 위해(예컨대, 구성 정보를 포함하는 TRV를 부가하기 위해) 장치 상의 RN 정책을 업데이트할 수 있다. DeNB(2006) 인증을 위한 새로운 비밀 키가 이 스테이지에서 설치 또는 활성화될 수 있다. 2036에서, 구성 서버(2010)는 구성이 완료되었다는 것을 RN(2002)에 알려줄 수 있다. 2038에서, RN(2002)은 DeNB(2006)와의 S1 설정을 개시할 수 있다. 2040에서, RN(2002)은 DeNB(2006)와의 X2 설정을 개시할 수 있다. 2042에서, RN(2002)은 중계 노드로서 동작할 수 있다.
2044에서, RN(2002) 상에서 리셋이 일어날 수 있다. 이 리셋은, 예를 들어, 네트워크, 장치 또는 정전에 의해 개시될 수 있다. 2046에서, RN(2002)은 안전 부트 시퀀스를 수행할 수 있다. 2048에서의 보안 환경의 설정 및/또는 자율적 유효성 확인 동안, RN(2002)은 실패를 발견하지 않을지도 모른다. 2048에서, 등록 서버(2008) 정보 및/또는 구성 서버(2010) 정보가 자율적 유효성 확인 프로세스에서 포함될 수 있기 때문에, RN(2002)은, 서버를 개입시킬 필요없이, 2050 및 2052에서, 각각, S1 및 X2 인터페이스를 계속하여 설정할 수 있다. 2054에서, RN(2002)은 또한 RN으로서 동작할 수 있다. 등록 서버 정보 또는 구성 서버 정보에서 실패가 일어나는 경우, 정책은, 재구성이 있을 때까지, 비밀 인증 키의 배포 또는 후속 네트워크 프로세스에 대한 실행을 가능하게 해주거나 그렇지 않을 수 있다.
도 21은 인증된 관리 기능에 의한 중계 노드 복원에 관련된 예시적인 호 흐름도를 나타낸 것이다. 호 흐름 시퀀스는 본 명세서에 기술되어 있는 단계들 중 하나 이상의 단계를 포함할 수 있다. 예를 들어, 도 21에 예시된 바와 같이, 2114에서, RN(Relay Node)(2102)은 안전 부트 시퀀스를 수행할 수 있다. 2116에서, RN(2102)은 보안 환경을 설정하고 및/또는 자율적 유효성 확인을 수행할 수 있다. 2116에서의 자율적 유효성 확인 동안, RN(2102)는 장치의 중요하지 않은 컴포넌트에 대한 실패를 발견할지도 모른다. 2118에서, RN(2102)은 eNB(2104)를 통해 네트워크[예컨대, MME/HSS(2112)]에 UE로서 접속될 수 있다. 2120에서, MME(2112)는 등록 서버(2106) 및/또는 복원 서버(2110)에의 제한된 액세스를 RN(2102)에 할당할 수 있다. MME(2112)는, 예를 들어, eNB(2104)를 통해 제한된 액세스를 할당할 수 있다. RN(2102) 및 복원 서버(2110)는 상호 인증할 수 있다. 2122에서, RN(2102)은 경보(예컨대, 복원 요청)을 복원 서버(2110)로 송신할 수 있다. 2124에서, 복원 서버(2110)는 RN(2102) 보안 환경이 RN(2102)의 복원 서버 비밀 인증 키의 사용을 배포하는 것을 통해 암시적으로 RN 관리 능력을 유효성 확인할 수 있고 및/또는 복원 서버(2110)는 RN(2102) 무결성 상태 보고(들)의 조사에 의해 RN(2102)을 유효성 확인할 수 있다. 2126에서, RN(2102) 및 복원 서버(2110)는 (선택적으로) RN(2102)의 조사를 수행할 수 있다. 복원 서버(2110)는, 2128에서, RN(2102)을 복원하고, 실패를 교정하기 위해, 2130에서, 복원 정보를 RN(2102)으로 송신할 수 있다.
2132에서, 복원 서버(2110)는 안전하게 재부트하라고 RN(2102)에 원격적으로 명령할 수 있거나, RN(2102)가 이미 전원 켜기 스테이지의 제1 단계를 수행했고, 예를 들어, 단지 관리 인증이라기보다는 플랫폼 인증을 위해 장치 무결성 검사가 이제 성공했기 때문에, RN(2102)은 RN(2102) 전원 켜기 시퀀스에서의 그 다음 단계로 곧바로 진행할 수 있다. 예를 들어, 2134에서, RN(2102)은 보안 환경을 설정하고 및/또는 자율적 유효성 확인을 수행할 수 있다. 2136에서, RN(2102)은 eNB(2104)를 통해 네트워크[예컨대, MME/HSS(2112)]에 UE로서 접속될 수 있다. 2138에서, MME(2112)는 등록 서버(2106) 및/또는 복원 서버(2110)에의 제한된 액세스를 RN(2102)에 할당할 수 있다. 2140에서, RN(2102)은 등록 서버(2106)에 등록 요청을 할 수 있다. 2142에서, 등록 서버(2106)는 인증서를 유효성 확인, 구성 및/또는 RN(2102)에 발행할 수 있다. 2144에서, 등록 서버(2106)는 등록이 완료되었다는 것을 RN(2102)에 알려줄 수 있다.
본 명세서에 기술된 바와 같이, 무결성 검사, 보고 및 복원을 위한 본 명세서에 기술되어 있는 절차, 시스템 및 수단이 소프트웨어 실패, TR-069, 소프트웨어 복원, H(e)NB 등으로 제한되지 않을 수 있다. 게다가, 기술된 동작들은 예시를 위한 것이다. 다른 동작들이 사용될 수 있고, 사용되지 않는 경우 생략될 수 있으며 및/또는 동작들이 부가될 수 있다는 것을 잘 알 것이다.
일부 구현예에서, 실패가 소프트웨어에 대한 것이 아니라 구성 데이터 또는 장치 상의 어떤 다른 측정가능한 컴포넌트에 대한 것일 수 있다. 이러한 구현예에서, 관리 엔터티는 업데이트를 소프트웨어 복원 엔터티로부터 수신하지 않고, 예를 들어, 네트워크 장치 구성 데이터베이스로부터 수신할지도 모른다. 모든 실패 시나리오가 조사 절차를 사용하는 것은 아니다. 이들 경우에, 처음에 장치로부터 경보 또는 보고로서 송신된 정보가 실패의 원인을 결정하는 데 충분하거나, 어떤 동작이 수행될 수 있는 것으로 결정하는 데 적어도 충분할 수 있고, 그로써 관리 엔터티는 조사 없이 복원 절차를 개시할 수 있다. 예를 들어, 관리 엔터티는 유사한 장치의 이전의 실패로부터 실패한 컴포넌트 측정을 인식할 수 있고, 따라서 업데이트를 장치로 즉각 전달할 수 있다. 어쩌면 작은 컴포넌트로 인한, 조사와 업데이트 간의 시간 및 트래픽 부하의 절충은 전체 컴포넌트 업데이트를 트리거할 수 있다.
이하의 예에서, 장치 아키텍처 및 복원 업데이트 절차가 기술되어 있다. 이 예시적인 장치 아키텍처 및 복원 업데이트 절차가 제한된 복잡도 및 자원을 갖는 소형 장치에 대해 사용될 수 있다. 이 예와 연관되어 있는 제약 조건이 본 명세서에 기술되어 있을 수 있다. 예를 들어, 장치의 응용 프로그램 코드 베이스 및 신뢰성 있는 코드 베이스가 그의 개발 및/또는 배포 라이프사이클은 물론 그의 동작과 관련하여 분리되어 있을 수 있다. 이들 2개의 코드 베이스가 개별 당사자에 의해 개발 및/또는 배포될 수 있다. 장치의 생산성 기능을 제공할 수 있는 장치의 응용 프로그램 코드 베이스가 단일 코드 및 데이터 블록으로서 장치의 비휘발성 메모리의 일부에 배포될 수 있다. 응용 프로그램 코드 베이스가 복원에 최소한으로 관여될 수 있고 및/또는 무결성 유효성 확인에 관여되어 있지 않을 수 있다. 서비스 사이클(예컨대, 장치의 응용 프로그램에 의해 사용될 수 있는 장치의 코드 베이스의 일부의 업데이트 사이의 업타임)이 길 수 있다. 이는, 예를 들어, 복원을 위한 재부트가 언제라도 무분별하게 강제되지 않을 수 있다는 것을 의미할 수 있다. 장치의 정상 동작이 복원 또는 장치 업데이트 절차를 위해 방해되지 않을 수 있다. 장치 기동의 초기 스테이지에서 무결성 유효성 확인 및 복원을 위한 통신이 일어날 수 있고, 그 동안 장치 내부 자원 사용 및 통신 대역폭에 대한 심각한 제한이 적용될 수 있다. 컴포넌트들(예컨대, 프로그램들 및 데이터)이 로드되고 이어서 하나씩 개별적으로 시작되는 통상적인 부트 사이클의 의미에서 복잡한 시스템 기동이 없을 수 있다.
상기 제한들을 고려하여, 예시적인 시스템 모델이 시스템의 TrE 및 보통 컴포넌트들로의 일반적인 분할의 버전으로서 기술되어 있을 수 있다. 시스템 아키텍처의 기능 요소는
신뢰 사슬에서 장치 무결성 유효성 확인이 의존하고 있는 불변 요소일 수 있는 RoT(Root of Trust);
시스템의 나머지로부터 격리되어 있는, 실행가능 코드 및 데이터의 하드웨어 및/또는 소프트웨어 보호를 갖는 특수 실행 환경일 수 있는 SEE(Secure Execution Environment) 중 하나 이상을 포함할 수 있다. 가능한 실현은 프로세서의 안전 실행 모드 또는 프로세서에서의 별도의 커널일 수 있다. SEE에 대한 제한은 런타임 메모리 및 이용가능한(SEE에 전용되어 있는) NVS(non-volatile storage, 비휘발성 저장 장치);
기본 통신 능력을 SEE 및/또는 NEE에 노출시킬 수 있는 Comm IF(Communications Interface, 통신 인터페이스) 컴포넌트; 및/또는
장치에서의 응용 프로그램 코드(예컨대, TrE에 속하지 않는 코드)의 실행 환경일 수 있는 NEE(Normal Execution Environment, 보통 실행 환경)에 대한 제한을 포함할 수 있다 NEE는 이 통신 능력을 재사용하기 위해 SEE의 능력에 대한(예를 들어, Comm IF에 대한) 특정의 인터페이스를 가질 수 있다.
장치의 능력 및 컴포넌트를 포함하는 몇개의 코드 베이스에 의해 기능 요소가 사용될 수 있다. TrECB(TrE Code Base) 및 DACB(Device Application Code Base)로 분리될 수 있다. TrECB는 SEE에 할당될 수 있고 DACB는 NEE에 할당될 수 있다. DACB 컴포넌트가 TrE의 능력에 액세스하기 위한 것인 경우, 이러한 액세스가 NEE와 SEE 사이의 전술한 인터페이스를 통해 수행될 수 있다. NEE 상의 SEE로부터 런타임 시에, 예컨대, 보안 기동 후에, 실행 제어가 없을 수 있거나, 그 반대도 마찬가지이다. TrECB 및 DACB가 NVS의 개별적인 부분에 저장되어 있을 수 있다.
도 22는 기능 컴포넌트(2202)(좌측) 및 코드/데이터 저장 컴포넌트(2204)(우측)의 예시적인 시스템을 나타낸 것이다. 기능 컴포넌트(2202)는 NEE(2206) 및 SEE(2208)를 포함할 수 있다. SEE(2208)는 통신 인터페이스(2210) 및/또는 ROT(2212)를 포함할 수 있다. 코드/데이터 저장 컴포넌트(2204)는 NVS 컴포넌트를 포함할 수 있다. NVS 컴포넌트 TRV_tmp(2214)는 NEE(2206)와 연관되어 있는 TRV를 포함할 수 있다. NVS 컴포넌트 DACB(2216)는 DACB를 포함할 수 있다. NVS 컴포넌트 TRV_NVS(2218)는 SEE(2208)와 연관되어 있는 TRV를 포함할 수 있다. NVS 컴포넌트 TrECB NVS(2220)는 TrECB를 포함할 수 있다. 상이한 보안 대책이 NVS 구획(compartment)에 개별적으로 적용될 수 있다. 화살표는 도 22에 도시된 엔터티들 간의 판독/기록 액세스를 나타낼 수 있다. TrECB NVS(2220)는 IVC(integrity validation capability), DGC(device generic communication capability), FB/DC(fall back/distress capability), 및 RC(remediation capability) 등의 다양한 능력을 제공할 수 있다. 이들 능력이 도 22 및 도 23과 관련하여 본 명세서에 논의되고 있다.
도 22에 예시된 바와 같이, NEE(2206)는 SEE(2208)와 통신하고 있을 수 있다(예컨대, 그로부터 판독하고 및/또는 그에 기입함). SEE(2208)는 통신 인터페이스(2210)를 사용하여 통신할 수 있다. SEE(2208)는 코드/데이터 저장 컴포넌트에 대해 수행되는 무결성 유효성 확인을 위해 ROT(2212)를 사용할 수 있다. NEE(2206)는 NVS 컴포넌트(2214)에 기입하고 NVS 컴포넌트(2216)로부터 판독할 수 있다. SEE(2208)는 NVS 컴포넌트(2214)로부터 판독할 수 있다. SEE(2208)는 또한 NVS 컴포넌트(2216, 2218 및 2220)로부터 판독하고 그에 기록할 수 있다.
도 23은 부트 시퀀스의 스테이지들 및 각각의 스테이지에서 구현되는 다양한 엔터티들 간의 상호작용의 예시적인 실시예를 나타낸 것이다. 도 23에 예시된 바와 같이, NEE(2206) 및 SEE(2208)는 부트 시퀀스에서 구현될 수 있다. 부트 시퀀스의 제1 및 제2 스테이지에서는 SEE(2208)가 사용될 수 있다. 제1 스테이지는 ROT(2212)를 포함할 수 있다. 제2 스테이지는 IVC(integrity validation capability)(2318), DGC(device generic communication capability)(2314), FB/DC(fall back/distress capability)(2320), RC(remediation capability)(2324), 및/또는 TRV(2326)를 포함할 수 있는 TrECB NVS(2220)를 포함할 수 있다. IVC(2318)는 컴포넌트의 측정을 행하고 이들을 TRV[예를 들어, TRV(2326) 등]에 포함되어 있는 참조값과 비교하는 일을 맡고 있을 수 있다. DGC(2314)는 SEE(2208)[이는 차례로 NEE(2206)에 노출될 수 있음]에 기본 통신 기능을 제공할 수 있다. DGC(2314)는 FB/DC(2320) 및 RC(2324)에 의한 복원 및/또는 재난 표시를 위해 사용될 수 있다. DGC(2314)는 또한 인터페이스를 통해 DAC(2322)에 노출될 수 있다. 관련 기능[즉, 폴백 코드 베이스에 의한 DACB(2216)의 교체]을 수행하기 위한 특정의 조건이 만족되는 경우 FB/DC(2320)가 활성화되어, 네트워크 또는 장치 사용자에 재난 상황을 알려줄 수 있다. RC(2324)는 코드 베이스의 계획된 변경 및/또는 교정을 맡고 있는 기관일 수 있다. RC(2324)는 또한 TRV(236)의 관리자일 수 있고, RC(2324)는 TRV(2326)의 진위를 검사할 수 있다.
부트 시퀀스의 제3 스테이지에 대해 NEE(2206)가 사용될 수 있다. 제3 스테이지는 RAIF(remediation application IF)(2316) 및/또는 DAC(device application capabilities)(2322)를 포함하는 DACB(2216)를 포함할 수 있다. RAIF(2316)는 네트워크로부터 들어오는 새로운 TRV에 대한 PTI(pass-through interface, 통과 인터페이스)일 수 있다. RAIF(2316)는 들어오는 통신에서 TRV를 인식하고, 이를 TRV 임시 비휘발성 저장소에 저장할 수 있다. DAC(2322)는 장치의 응용 프로그램 관련 기능을 구현할 수 있다. DAC가 Comm IF로부터의 통신 능력을 사용하고자 하는 경우, 그에 대한 액세스가 특수 NEE-SEE IF를 통해 중재될 수 있다.
TRV(2326)는 시스템 내의 2개의 상이한 장소에 저장될 수 있다. TRV_tmp(2214)는 RAIF(2316)에 의해 수신된 새로운 TRV에 대한 임시 저장소일 수 있다[예컨대, TRV_tmp(2214)가 NEE(2206)로부터 기록가능할 수 있음]. TRV_tmp가 SEE(2208)로부터 판독가능할 수 있고, 그로부터 RC(2324)는 새로운 TRV를 판독하고, 이들이 인증되면, 이를 TRV NVS(2218)에 넣을 수 있다.
도 23에 예시된 기동 시퀀스는 간략화된 시스템 아키텍처에서의 무결성 검사를 갖는 보통의 기동(예컨대, 재난/폴백 도는 복원 동작을 필요로 할지도 모르는 실패 상황이 일어나지 않는 기동)에 관련된 것일 수 있다. 보안 기동의 제1 스테이지에서, RoT(2212)가 활성화될 수 있다. 보안 기동의 제2 스테이지에 대한 이전의 설명과 달리, RoT(2212)는 로드되어 시작된 컴포넌트에 대해 추가의 무결성 검사를 나중에 수행할 수 있는 신뢰성 있는 부트 로더를 검증 및 활성화하지 않을 수 있다. 이러한 로더/실행 제어기는 간략화된 시스템 아키텍처에서 이용가능하지 않을 수 있다. 그 대신에, RoT(2212)는 TrECB NVS(2220)에서 IVC(2318) 코드 및 데이터 블록을 검사할 수 있다. 이 구성에서, IVC(2318)는 불변일 수 있는데, 그 이유는 RoT(2212)가 TRV(2326)를 판독할 수 없을지도 모르기 때문이다. 따라서, 이는 고정된, [RoT(2212)에] 내장된 참조값과 대조하여 IVC(2318)를 검사할 수 있다.
일 실시예에서, RoT(2212)는 고정된 루트 인증서를 사용하여 IVC(2318) 코드 및 데이터 블록을 검사할 수 있다. 이 경우에, TrECB NVS(2220)의 IVC(2318) 부분은 TrECB NVS(2220)의 이 후자의 IVC(2318) 부분에 대한 서명과 함께 저장될 수 있다. RoT(2212)가 서명을 검사하는 데 사용되는 키는 전술한 고정된 루트 인증서에 있을 수 있다. IVC(2318) 코드의 변경은 새로운 IVC(2318) 코드를 동일한 고정된 키를 사용하는 새로운 코드에 대한 새로운 서명과 함께 다운로드하고 후자의 데이터를 TrECb NVS(2220)에 저장하는 것에 의해 구현될 수 있다. IVC(2318)는 SEE(2208) 내부에서 실행될 수 있다. IVC(2318)는 TRV_tmp NVS(2214)가 비어 있는지(간략화된 시스템 아키텍처에서 무결성 검사를 갖는 보통의 기동에 대해 가정되어 있을 수 있음)를 검사할 수 있다. IVC(2318)는 TRV NVS(2218)로부터 DGC(2314)의 코드에 대한 지정된 TRV를 로드할 수 있다.
IVC(2318)는 TRV 참조값 및 임의의 부가의 데이터에 대한 서명을 검증함으로써 TRVEMF(2326)의 각각의 로드된 TRV의 무결성을 검사할 수 있다. 이 서명은 TRV에 있을 수 있고, IVC(2318)가 서명을 검사하는 데 사용할 수 있는 키는 IVC(2318) 코드/데이터 블록에 있다. IVC(2318)는 이어서 TrECB NVS(2220)로부터 SEE(2208)에 로드된 DGC(2314) 코드를 측정하고 이 측정을 후자의 TRV에서의 참조값과 비교할 수 있다. 성공 시에, DGC(2314)가 활성화될 수 있다. SEE(2208) 프로세서 및 NEE(2206) 프로세서가, NEE(2206) 코드가 검사될 때마다, 이 플래그를 존중하는 것으로 가정하여, 활성화는, 예를 들어, DGC(2314)가 존재하는 SEE(2304)의 런타임 메모리 부분 상의 플래그 'executable'를 세트시킴으로써 DGC(2314)가 실행을 위해 이용가능하다는 것을 의미할 수 있다.
IVC(2318)는 TRV NVS(2218)로부터 RAIF(2316)의 코드에 대한 지정된 TRV를 로드할 수 있다. IVC(2318)는 DACB NVS(2216)로부터 NEE(2206)에 로드된 RAIF(2316) 코드를 측정하고 이 측정을 후자의 TRV에서의 참조값과 비교할 수 있다. 성공 시에, RAIF(2316)가 활성화될 수 있다.
IVC(2318)는 소정의 순서로 DACB(2216)의 일부와 연관되어 있는 각각의 TRV를 로드할 수 있다. IVC(2318)는 DACB NVS(2216)로부터 NEE(2306)에 로드된, 로드된 TRV에 의해 지정된 DAC(2322) 코드 및 데이터의 일부를 측정하고 이 측정을 후자의 TRV에서의 참조값과 비교할 수 있다.
[예컨대, DACB(2216) 코드 및 데이터에 대한 이용가능한 TRV의 시퀀스를 전부 사용함으로써] DACB(2216)에서의 검사가 수행될 때, IVC(2318)는 DAC(2322)를 활성화시키고 실행을 NEE(2206) 프로세서로 넘길 수 있다[또는 SEE(2208) 및 NEE(2206) 프로세서가 동시에 실행되는 것이 가능할 때 이를 시작함]. 기동 절차에서 특수한 상황(예컨대, 무결성 검사 실패)이 일어나지 않는 경우, FB/DC(2320) 및 RC(2324) 코드 및 데이터 블록이 검사되지도 활성화되지도 않을 수 있다.
안전 부트 등의 보다 복잡한 시스템에서의 안전 기동과의 차이점은 IVC(2318)가 TRV 데이터에 의해 구동될지도 모른다는 것을 포함할 수 있다. 즉, TRV는 다양한 코드 베이스의 어느 코드 및 데이터 단편을 검사할지에 관한 정보를 가질 수 있다. TRV(2326)이 IVC(2318)에 의해 순차적으로 판독될 수 있고, IVC(2318)는 TRV 참조 무결성 값이 적용되는 코드 및 데이터 단편을 발견하기 위해 이들을 평가할 수 있고, 이 데이터를 판독 및/또는 측정하고 대조된 측정을 참조값과 비교할 수 있다.
단일의 TRV 참조값이 코드 베이스에서의 다수의 코드 및 데이터 단편에 대응할지도 모르기 때문에, TRV는 매핑(예컨대, 코드 베이스에서의 그 단편의 위치 및 길이의 표시자), 및 단편의 측정을 합성 측정값과 어떻게 결합시킬지에 관한 방안을 포함할 수 있다. 도 24a 및 도 24b는 TRV 대 코드 베이스에서의 코드 및/또는 데이터 단편 간의 매핑의 예시적인 구현예를 나타낸 것이다.
도 24a는 TRV를 생성하기 위해 선형적으로 결합될 수 있는 부분 측정들의 시퀀스를 나타낸 도면이다. 도 24a에 예시된 바와 같이, TRV(2412)를 생성하기 위해 DACB의 코드 측정(2402, 2404, 2406, 2408 및 2410)이 선형적으로 결합될 수 있다. 예시적인 실시예에 따르면, TCG에 의해 지정된 신뢰 플랫폼 모듈(Trusted Platform Module)의 TPM-확장(TPM-Extend) 명령으로 실현되는 바와 같은 해쉬 연쇄(hash-chaining)를 적용함으로써 코드 측정(2402, 2404, 2406, 2408 및 2410)이 결합될 수 있다.
도 24b는 TRV를 생성하기 위해 Merkle 해쉬 트리를 사용한 값들의 결합을 나타낸 도면이다. 도 24b에 예시된 바와 같이, TRV(2414)를 생성하기 위해 DACB의 코드 측정(2416, 2418, 2420, 2422, 2424 및 2426)이 Merkle 해쉬 트리를 사용하여 선형적으로 결합될 수 있다.
복원 및/또는 업데이트를 수행하는 장치 엔터티와 대응하는 네트워크 엔터티[예컨대, H(e)MS] 간의 상호작용적 조사 절차는 본 명세서에 기술되어 있는 TRV 대 코드/데이터 간의 매핑을 사용할 수 있다. 이러한 절차는, 본 명세서에 기술되어 있는 바와 같이, 본 명세서에 기술되어 있는 일반적인 장치 조사 절차의 특수한 경우일 수 있다.
각각의 코드 단편이 측정될 수 있고, 이 측정이 네트워크 엔터티로 하나씩 송신될 수 있고, 여기서, 예컨대, 단편 참조값들의 순차적 목록에 있는 대응하는 단편 참조값과 비교될 수 있으며, 이 단편 참조값들의 순차 목록으로부터의 TRV 참조값은, 예를 들어, 해쉬 연쇄 등의 어떤 방법에 의해 이전에 계산되었을 수 있다.
Merkle 해쉬 트리를 통한 검출에 의해 많은 수의 단편의 경우에 효율이 향상될 수 있다. 이것은 트리의 레벨을 하강시킴으로써 상호작용적 조사 절차의 형태로 수행될 수 있다. 본 명세서에서, TRV에 포함되어 있는 참조값 및 코드/데이터의 얻어진 측정값 둘 다는 (그래프 이론상) 동일한 이진 트리의 루트를 나타낼 수 있다. 이들이 일치하지 않는 경우, 장치는 2개의 자식 노드 값을 네트워크 엔터티로 송신할 수 있고, 네트워크 엔터티는 어느 것이 실패가 있는지[예컨대, 네트워크가 (그 참조 트리의 루트일 수 있는) TRV 참조값을 빌드하는 데 사용했던 참조 트리에서의 동일한 노드와 일치하지 않는지]를 결정할 수 있다. 네트워크는 어느 분기(들)가 불일치인지를 알려줄 수 있는 메시지를 장치로 송신할 수 있다. 참조값(말단값)과 일치하지 않는 코드 단편[그의 측정값이 측정 트리의 말단(leaf)를 구성함]이 결정될 때까지 이 절차가 반복될 수 있다.
다시 도 23을 참조하면, 장치 복원을 위해 사용되는 TrECB(2220) 능력에 기초하여 기능 및 절차가 수행될 수 있다. 일 실시예에서, 동작 동안 하나 이상의 TRV(2326)를 업데이트하는 것 및 그 다음 기동 시에 실제의 코드 업데이트를 수행하는 것에 의해 계획된 코드 업데이트가 수행될 수 있다.
이하는 계획된 코드 업데이트에 관한 것일 수 있다. 장치가 본 명세서에 기술되어 있는 바와 같이 기동을 수행한 것으로 가정될 수 있다. RAIF(2316)는, 예를 들어, Comm IF(2210) 및/또는 DGC(2314)를 통해, 새로운 TRV를 외부 당사자[예컨대, H(e)MS]로부터 수신할 수 있다. RAIF(2316)는 이 새로 수신된 TRV를 TRV_tmp NVS(2214)에 저장할 수 있다. 나중에, 장치가 재시작될 수 있다. 본 명세서에 기술되어 있는 바와 같이, IVC(2318)는 SEE(2208) 내에서 무결성 검사되고 시작될 수 있다. IVC(2318)는 검사하고 TRV_tmp NVS(2214)가 비어 있지 않음을 발견할 수 있고, 본 명세서에 기술되어 있는 바와 같이 계속할 수 있다.
TRV_tmp(2214)는 단일의 새로운 TRV를 가질 수 있다. 제1 구현예에서, TRV_tmp 내의 새로운 TRV는 DACB(2216)에서의 코드 및/또는 데이터를 말할 수 있다. 제2 구현예에서, TRV_tmp에서의 새로운 TRV는 TrECB(2220)에서의 코드 및/또는 데이터[예컨대, DGC(2314), FB/DC(2320), 또는 RC(2324) 코드/데이터]를 말할 수 있다.
제1 구현예에서, 앞서 기술한 바와 같이, IVC(2318)는 TRV의 진위를 검증할 수 있다. 성공 시에, IVC(2318)는 새로운 TRV를 TRV NVS(2218)에 저장할 수 있다. IVC(2318)는 새로운 TRV에 의해 교체될 것으로 생각될 수 있는 TRV NVS(2218)에서의 하나 이상의 이전의 TRV를 삭제할 수 있다. 이들 중요도가 떨어진 TRV가 어떻게 결정되는지는 구현에 의존할 수 있다. TRV에서의 부가 데이터의 일부로서, 고유 식별자가 TRV에 할당될 수 있다. 이 단락에 기술된 프로세스는, 예를 들어, TRV의 취득(ingestion)이라고 할 수 있다.
IVC(2318)는 TrECB(2220) NVS로부터 SEE(2208)에 로드된 DGC(2314) 코드를 측정하고 이 측정을 후자의 TRV에 포함되어 있는 참조값과 비교할 수 있다. 성공 시에, DGC(2314)가 활성화될 수 있다. IVC(2318)는 TRV(2326)를 TRV NVS로부터 로드 및/또는 검증할 수 있고, 이들 각각에 대한 지정된 코드 및 데이터 단편에 대해 IV를 수행할 수 있다[예컨대, RAIF(2316)로부터 시작하여 DACB(2216)의 다른 부분으로 계속됨]. IV 시퀀스에서 새로 취득된 TRV를 만나게 될 때, DACB(2216)의 지정된 코드 및 데이터 부분에 대해 수행되는 IV가 반드시 실패할지도 모른다(예컨대, 새로운 TRV가 중요도가 떨어진 참조값(들)과 상이한 참조값을 가지는 것으로 가정함).
IVC(2318)는 TRV NVS(2218)로부터 RC의 코드에 대한 지정된 TRV를 로드할 수 있다. IVC(2318)는 이어서 TrECB(2220) NVS로부터 SEE(2208)에 로드된 DGC(2314) 코드를 측정하고 이 측정을 후자의 TRV에서의 참조값과 비교할 수 있다. 성공 시에, RC가 활성화될 수 있다.
대응하는 네트워크 엔터티[예컨대, H(e)MS]를 사용한 조사 절차에 의해, RC(2324)는 업데이트될 필요가 있을 수 있는(예컨대, 새로 취득된 TRV의 참조값을 재현하기 위해 무결성 측정의 실패에 기여하는) 그 코드 및/또는 데이터 단편을 결정할 수 있다. 예를 들어, 본 명세서에 기술되어 있는 바와 같이, 조사 절차가 수행될 수 있다.
새로운 TRV를 사용하여, 장치는 또한 코드 및/또는 데이터의 어느 부분이 교체될 필요가 있을 수 있는지의 상세를 수신했을 수 있다. 이것은 RC(2324)와 네트워크 사이의 조사 절차를 피할 수 있다. 장치의 정상 동작 동안 다운로드되는 장치 관리 및/또는 복원을 위한 데이터의 양을 최소화하기 위해 조사가 수행될 수 있다. 장치가 그 (하나의, 새로운) TRV 및/또는 그의 지정된 코드 단편의 어떤 중간 업데이트를 "상실"할 수 있는 경우를 고려하기 위해 조사가 또한 수행될 수 있다. 이러한 후속 업데이트가 누적적인 경우, 이들은 조사 절차에서 발견될지도 모르는(그렇지만 장치에 의해 상실되었을 수 있는 동일한 TRV의 일련의 업데이트 후에 마지막 TRV로 제한된 업데이트를 위해 지정된 단편들의 목록에 있는 것으로 보장되지 않을지도 모르는) 많은 수의 코드 단편에 영향을 주는 경향이 있을 수 있다.
RC(2324)는 대응하는 네트워크 엔터티로부터 결정된 코드 및/또는 데이터 단편을 다운로드할 수 있다. 한 예에 따르면, 네트워크 엔터티는 TR-069 서명된 데이터 패키지를 편집하고 및/또는 이를 장치로 송신할 수 있다. 예를 들어, 새로 취득된 TRV에서의 서명 인증서, [예컨대, IVC(2318)에 의해] TRV(2326)를 검사하는 데 사용된 루트 인증서, 또는 [예컨대, RC(2324) 코드/데이터 베이스에 있는] 복원을 위한 전용 인증서를 사용하여 패키지 서명을 검증하는 것에 의해, 수신된 데이터는 RC(2324)[다른 대안으로서, IVC(2318)]에 의해 진위 검사될 수 있다.
다운로드된 코드 및/또는 데이터 단편의 인증 후에, RC(2324)는 이들을 DACB(2216) NVS로 이전에 결정된 단편의 위치에 기록할 수 있다. DGC(2314)는 실행을 다시 IVC(2318)로 넘길 수 있고, IVC(2318)는 TRV 시퀀스에서의 동일한 TRV(예컨대, 새로 취득한 TRV)에서 IV를 재시작할 수 있다.
*전술한 절차가 순환적으로 될 수 있다. 이것은 적어도 2개의 원인 중 하나로 인해 일어날 수 있다. 첫째, 공격자가 TRV 참조값에 부합하지 않을지도 모르는 그 자신의 코드를 업데이트 프로세스에 삽입했을 수 있다. 그에 부가하여, 예를 들어, 네트워크측 코드 빌드의 오작용으로 인해, TRV 참조값 및/또는 다운로드된 코드의 부적절한 불일치가 있을 수 있다. 이들 구현예 둘 다에서, 이 상황이 검출되고 네트워크로 신호될 수 있다. 이것은 TRV 사용에 대해 반복 카운터를 사용하여 IVC(2318)에 의해 달성될 수 있다. 고도의 보안을 위해, 이들 카운터는 TRV NVS에의 판독 액세스에 의해 증분될 수 있는 단조 하드웨어 카운터일 수 있다. 단일의 TRV에 대해 너무 많은 IV의 반복(횟수는 정책에 의존할 수 있음)이 검출되는 경우, IVC(2318)는 검사하고 FB/DC(2320)를 활성화시키며 및/또는 대응하는 신호를 네트워크로 송신하기 위해 제어를 그 능력으로 넘길 수 있다.
[TrECB(2220)에서의 코드 및/또는 데이터를 참조하는 TRV_tmp(2214)에서의 새로운 TRV에 관련된] 전술한 제2 구현예와 관련하여, [DACB(2216)에서의 코드 및/또는 데이터를 참조하는 TRV_tmp(2214)에서의 새로운 TRV에 관련된] 제1 구현예가 사용되지 않을 수 있는데, 그 이유는 업데이트/복원에 관여되고 활성인 컴포넌트 자체에 대해 업데이트/복원이 요청될 수 있기 때문이다. 이러한 경우에, 이하의 절차에서의 하나 이상의 단계가 적용될 수 있다. IVC(2318)는 새로운 TRV를 취득할 수 있지만, 대응하는 이전의 TRV를 TRV NVS(2218)에 유지할 수 있다. 새로운 TRV가 그것이 새로운 것임을 나타내는 어떤 데이터 플래그(예컨대, 문자열 "NEW_DGC_TRV")로 표시될 수 있다. IVC(2318)는 이전의 TRV를 사용하여 RC(2324)를 검사하고 및/또는 활성화시킬 수 있다. RC(2324)는 제1 구현예에 기술된 것과 동일한 방식으로 사용될 수 있는 TrECB(2220) 부분의 업데이트를 수행할 수 있지만, 제2 구현예에서, 업데이트는 TrECB(2220) NVS에 기록될 수 있다. IVC(2318)는 새로운 TRV를 사용하여 TrECB(2220)의 업데이트된 부분을 검사할 수 있다. 성공 시에, 이전의 TRV가 TRV NVS(2218)로부터 삭제될 수 있고, 새로운 TRV에 부착된 표시가 제거될 수 있다. 이것은, 예를 들어, 장치의 그 다음 재시작 후까지 지연될 수 있다.
RoT(2212)가 IVC(2318) 코드를 검사할 때, 무결성 검사의 제1 실패 조건이 일어날 수 있다. 이 검사가 실패하는 경우, RoT(2212)는 시스템을 정지시킬 수 있고, 그에 부가하여, 신호(예컨대, 광학 신호)를 사용자로 송신할 수 있다.
일 실시예에 따르면, RoT(2212)는 FB/DC(2320)의 불변 부분(또는 그의 무결성이 IC 코드에 대한 유사한 변형에서 기술된 바와 같이 서명에 의해 보호될 수 있는 가변 부분)을 검사하고 및/또는, 예컨대, SEE(2208)에 로드하여 실행함으로써 이 자율적으로 검사된 코드를 통해 이용가능할 수 있는 재난/폴백 절차의 이러한 제한된 부분을 호출할 수 있다.
실패할지도 모르는 그 다음 무결성 검사는 DGC(2314) 및/또는 RAIF(2316)의 무결성 검사일 수 있다. 전자는 장치가 신뢰할 수 있는 통신 능력을 가지고 있지 않음을 의미할 수 있다. 이 경우에, IVC(2318)는 FB/DC(2320)을 검증하고 활성화하려고 시도할 수 있다. FB/DC(2320)는 신뢰할 수 있는 통신을 어느 정도까지 복구할 수 있고, 재난 신호를 네트워크로 송신할 수 있다. 그렇지 않은 경우, 이는 사용자에 신호할 수 있고 시스템을 정지시킬 수 있다. 전술한 복원 절차에서 RC(2324)의 IV가 실패하는 경우, 동일한 절차가 적용될 수 있다.
전술한 제2 구현예에서, RAIF(2316)의 IV가 실패하는 경우, 이것은 장치가 TRV 업데이트를 수신할 수 없을지도 모른다는 것을 의미한다. 장치는 이어서 먼저 전술한 바와 같이 이 상황을 교정하려고 시도할 수 있다. 이것이 성공하지 못하는 경우, IVC(2318)는 FB/DC(2320)를 검증 및/또는 활성화할 수 있고, FB/DC(2320)는 이어서 특정의 조치[예컨대, RAIF(2316)를 어떤 기본 코드로 교체]를 취할 수 있다.
NEE(2206)에서의 노출되어 있는 코드의 일부 및 보통의 코드의 일부인 RAIF(2316)이 장치 복원에서의 가장 약한 링크일 수 있다는 것을 이상의 설명으로부터 알 수 있다. 이것이 장치 무결성에 직접적인 위협을 제기하지 않을 수 있지만, RAIF(2316)가 무결성 검사에 관여되어 있지 않을 수 있기 때문에, 이는, 업데이트/복원을 디스에이블하고 따라서 장치를 중요도가 떨어진(예컨대, 실패있는) 상태에 두는 것에 의해, 간접적인 서비스 거부 공격의 침해에 노출되어 있을 수 있다. 일 실시예에 따르면, RAIF(2316)에 의해 구현되는 기능이 TrECB(2220)의 일부로서 제공되고 SEE(2208)에서 실행될 수 있다. 이것은 시스템 아키텍처에 대한 진보된 구성을 제공할 수 있는데, 그 이유는 SEE(2208)의 일부가 활성이고 새로운 TRV를 수신할 준비가 되어 있다는 것을 의미할 수 있기 때문이다. SEE의 이러한 지속적인 활동은, 예를 들어, Comm IF(2210) 및 DGC(2324)에서 실현될 수 있다.
특징 및 요소가 특정의 조합으로 앞서 기술되어 있지만, 당업자라면 각각의 특징 또는 요소가 단독으로 또는 다른 특징 및 요소와 임의의 조합으로 사용될 수 있다는 것을 잘 알 것이다 그에 부가하여, 본 명세서에 기술된 방법이 컴퓨터 또는 프로세서에서 실행하기 위해 컴퓨터 판독가능 매체에 포함되어 있는 컴퓨터 프로그램, 소프트웨어, 또는 펌웨어로 구현될 수 있다. 컴퓨터 판독가능 매체의 일례는 전자 신호(유선 또는 무선 연결을 통해 전송됨) 및 컴퓨터 판독가능 저장 매체를 포함한다. 컴퓨터 판독가능 저장 매체의 일례로는 ROM(read only memory), RAM(random access memory), 레지스터, 캐시 메모리, 반도체 메모리 장치, 내장형 하드 디스크 및 이동식 디스크 등의 자기 매체, 광자기 매체, 그리고 CD-ROM 디스크 및 DVD(digital versatile disk) 등의 광 매체가 있지만, 이들로 제한되지 않는다. 소프트웨어와 연관된 프로세서는 WTRU, UE, 단말, 기지국, RNC, 또는 임의의 호스트 컴퓨터에서 사용하기 위한 무선 주파수 송수신기를 구현하는 데 사용될 수 있다.

Claims (22)

  1. 방법에 있어서,
    무선 통신 장치에서, 상기 무선 통신 장치와 연관된 적어도 하나의 컴포넌트(component)에 대해 무결성 검사(integrity check)를 수행하는 단계;
    상기 적어도 하나의 컴포넌트가 상기 무결성 검사에 실패했는지(failed) 여부를 결정하는 단계;
    상기 적어도 하나의 컴포넌트가 상기 무결성 검사에 실패한 것으로 결정되는 경우, 상기 실패한 적어도 하나의 컴포넌트에 대응하는 기능을 결정하는 단계;
    상기 무선 통신 장치에서, 상기 실패한 적어도 하나의 컴포넌트에 대응하도록 결정된 상기 기능을 상기 무선 통신 장치의 적어도 하나의 능력(capability)에 맵핑하는 정책(policy)을 액세스(access)하는 단계; 및
    상기 결정된 적어도 하나의 능력에 기초하여 상기 무선 통신 장치에 대하여 정책을 시행하는(enforce) 단계
    를 포함하는, 방법.
  2. 제1항에 있어서,
    상기 능력은, 플랫폼 능력(platform capability)인 것인, 방법.
  3. 제1항에 있어서,
    컴포넌트의 상기 기능을 결정하기 위해 컴포넌트-기능간 맵핑(component-to-functionality map)이 사용되는, 방법.
  4. 제3항에 있어서,
    상기 컴포넌트-기능간 맵핑으로부터의 적어도 하나의 기능은 상기 적어도 하나의 능력을 결정하는데 사용되는 것인, 방법.
  5. 제4항에 있어서,
    상기 능력은, 시행하기 위한 적어도 하나의 정책에 대응하는 것인, 방법.
  6. 제1항에 있어서,
    상기 정책은, 상기 장치 상의 액세스 자원에 제한을 시행하는 것인, 방법.
  7. 제1항에 있어서,
    상기 정책은, 상기 장치의 로더(loader)에 의해 컴포넌트가 로딩될 수 있는 순서를 변경하는 것인, 방법.
  8. 제1항에 있어서,
    상기 정책은, 상기 장치의 로더에 의해 가능하게 되는 상기 적어도 하나의 능력의 실행에 대한 제어를 시행하는 것인, 방법.
  9. 무선 통신 장치에 있어서,
    컴퓨터 판독 가능 명령어들을 실행하도록 구성되는 프로세서;
    상기 프로세서에 통신가능하게 연결되고, 상기 컴퓨터 판독 가능 명령어들이 저장된 메모리
    를 포함하고,
    상기 컴퓨터 판독 가능 명령어들은, 상기 프로세서에 의한 실행시에, 상기 프로세서로 하여금,
    상기 무선 통신 장치에서, 상기 무선 통신 장치와 연관된 적어도 하나의 컴포넌트(component)에 대해 무결성 검사(integrity check)를 수행하는 동작;
    상기 적어도 하나의 컴포넌트가 상기 무결성 검사에 실패했는지(failed) 여부를 결정하는 동작;
    상기 적어도 하나의 컴포넌트가 상기 무결성 검사에 실패한 것으로 결정되면, 상기 실패한 적어도 하나의 컴포넌트에 대응하는 기능을 결정하는 동작;
    상기 무선 통신 장치에서, 상기 실패한 적어도 하나의 컴포넌트에 대응하도록 결정된 상기 기능을 상기 무선 통신 장치의 적어도 하나의 능력(capability)에 맵핑하는 정책(policy)을 액세스(access)하는 동작; 및
    상기 결정된 적어도 하나의 능력에 기초하여 상기 무선 통신 장치에 대하여 정책을 시행하는(enforce) 동작
    을 수행하게 하는 것인, 무선 통신 장치.
  10. 제9항에 있어서,
    상기 능력은, 플랫폼 능력(platform capability)인 것인, 무선 통신 장치.
  11. 제9항에 있어서,
    컴포넌트의 상기 기능을 결정하기 위해 컴포넌트-기능간 맵핑(component-to-functionality map)이 사용되는, 무선 통신 장치.
  12. 제11항에 있어서,
    상기 컴포넌트-기능간 맵핑으로부터의 적어도 하나의 기능은 상기 적어도 하나의 능력을 결정하는데 사용되는 것인, 무선 통신 장치.
  13. 제12항에 있어서,
    상기 능력은, 시행하기 위한 적어도 하나의 정책에 대응하는 것인, 무선 통신 장치.
  14. 제9항에 있어서,
    상기 정책은, 상기 장치 상의 액세스 자원에 제한을 시행하는 것인, 무선 통신 장치.
  15. 제9항에 있어서,
    상기 정책은, 상기 장치의 로더(loader)에 의해 컴포넌트가 로딩될 수 있는 순서를 변경하는 것인, 무선 통신 장치.
  16. 제9항에 있어서,
    상기 정책은, 상기 장치의 로더에 의해 가능하게 되는 상기 적어도 하나의 능력의 실행에 대한 제어를 시행하는 것인, 무선 통신 장치.
  17. 삭제
  18. 삭제
  19. 삭제
  20. 삭제
  21. 삭제
  22. 삭제
KR1020147014163A 2010-11-05 2011-11-04 장치 유효성 확인, 재난 표시, 및 복원 KR101703925B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US41078110P 2010-11-05 2010-11-05
US61/410,781 2010-11-05
PCT/US2011/059274 WO2012061678A1 (en) 2010-11-05 2011-11-04 Device validation, distress indication, and remediation

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR1020137014322A Division KR101622447B1 (ko) 2010-11-05 2011-11-04 장치 유효성 확인, 재난 표시, 및 복원

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020177002832A Division KR20170016034A (ko) 2010-11-05 2011-11-04 장치 유효성 확인, 재난 표시, 및 복원

Publications (2)

Publication Number Publication Date
KR20140079865A KR20140079865A (ko) 2014-06-27
KR101703925B1 true KR101703925B1 (ko) 2017-02-07

Family

ID=45003068

Family Applications (3)

Application Number Title Priority Date Filing Date
KR1020137014322A KR101622447B1 (ko) 2010-11-05 2011-11-04 장치 유효성 확인, 재난 표시, 및 복원
KR1020177002832A KR20170016034A (ko) 2010-11-05 2011-11-04 장치 유효성 확인, 재난 표시, 및 복원
KR1020147014163A KR101703925B1 (ko) 2010-11-05 2011-11-04 장치 유효성 확인, 재난 표시, 및 복원

Family Applications Before (2)

Application Number Title Priority Date Filing Date
KR1020137014322A KR101622447B1 (ko) 2010-11-05 2011-11-04 장치 유효성 확인, 재난 표시, 및 복원
KR1020177002832A KR20170016034A (ko) 2010-11-05 2011-11-04 장치 유효성 확인, 재난 표시, 및 복원

Country Status (8)

Country Link
US (3) US8914674B2 (ko)
EP (2) EP3002697A1 (ko)
JP (2) JP5810168B2 (ko)
KR (3) KR101622447B1 (ko)
CN (2) CN103202045B (ko)
AU (1) AU2011323225B2 (ko)
TW (3) TW201735675A (ko)
WO (1) WO2012061678A1 (ko)

Families Citing this family (84)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101611649B1 (ko) 2008-01-18 2016-04-26 인터디지탈 패튼 홀딩스, 인크 M2m 통신을 인에이블하는 방법 및 장치
SE533007C2 (sv) 2008-10-24 2010-06-08 Ilt Productions Ab Distribuerad datalagring
JP5453461B2 (ja) 2009-03-05 2014-03-26 インターデイジタル パテント ホールディングス インコーポレイテッド H(e)NB完全性検証および妥当性確認のための方法および機器
WO2010102259A2 (en) 2009-03-06 2010-09-10 Interdigital Patent Holdings, Inc. Platform validation and management of wireless devices
KR101296483B1 (ko) * 2009-04-15 2013-08-13 인터디지탈 패튼 홀딩스, 인크 네트워크와의 통신을 위한 장치의 검증 및/또는 인증
EP2387200B1 (en) 2010-04-23 2014-02-12 Compuverde AB Distributed data storage
KR101622447B1 (ko) 2010-11-05 2016-05-31 인터디지탈 패튼 홀딩스, 인크 장치 유효성 확인, 재난 표시, 및 복원
US9553728B2 (en) * 2011-02-25 2017-01-24 Nokia Technologies Oy Method and apparatus for providing end-to-end security for distributed computations
US8589996B2 (en) * 2011-03-16 2013-11-19 Azuki Systems, Inc. Method and system for federated over-the-top content delivery
US8589735B2 (en) * 2011-05-16 2013-11-19 International Business Machines Corporation Creating randomly ordered fields while maintaining the temporal ordering based on the value of the fields
US8645978B2 (en) 2011-09-02 2014-02-04 Compuverde Ab Method for data maintenance
US8769138B2 (en) 2011-09-02 2014-07-01 Compuverde Ab Method for data retrieval from a distributed data storage system
US9626378B2 (en) 2011-09-02 2017-04-18 Compuverde Ab Method for handling requests in a storage system and a storage node for a storage system
EP2756697B1 (en) * 2011-09-13 2019-04-17 Nokia Solutions and Networks Oy Authentication mechanism
KR101897605B1 (ko) * 2012-02-24 2018-09-12 삼성전자 주식회사 휴대 단말기의 무결성 보호 방법 및 장치
US8973138B2 (en) * 2012-05-02 2015-03-03 The Johns Hopkins University Secure layered iterative gateway
US9007465B1 (en) * 2012-08-31 2015-04-14 Vce Company, Llc Obtaining customer support for electronic system using first and second cameras
CN103049346B (zh) * 2012-12-11 2015-03-18 工业和信息化部电子第五研究所 基于失效物理的元器件故障树构建方法和系统
JP6063317B2 (ja) * 2013-03-26 2017-01-18 株式会社富士通エフサス 端末装置および判定方法
JP6054225B2 (ja) * 2013-03-26 2016-12-27 株式会社富士通エフサス 構成情報管理装置および構成情報管理方法
US9792436B1 (en) * 2013-04-29 2017-10-17 Symantec Corporation Techniques for remediating an infected file
KR20160009602A (ko) 2013-05-06 2016-01-26 콘비다 와이어리스, 엘엘씨 M2m 부트스트래핑
US20150019852A1 (en) * 2013-07-12 2015-01-15 International Games System Co., Ltd. Verification method for system execution environment
US9686274B2 (en) * 2013-10-11 2017-06-20 Microsoft Technology Licensing, Llc Informed implicit enrollment and identification
KR101468190B1 (ko) * 2013-10-15 2014-12-05 순천향대학교 산학협력단 Usim을 활용한 스마트워크 사용자 및 디바이스 인증 기법
US9755831B2 (en) 2014-01-22 2017-09-05 Qualcomm Incorporated Key extraction during secure boot
US9276803B2 (en) * 2014-04-02 2016-03-01 Ca, Inc. Role based translation of data
KR101742666B1 (ko) * 2014-05-29 2017-06-15 삼성에스디에스 주식회사 집적 회로 장치 및 상기 집적 회로 장치에서의 신호 처리 방법
CN105302708A (zh) * 2014-06-30 2016-02-03 联发科技(新加坡)私人有限公司 一种移动终端及其检测方法
CN104503318B (zh) * 2014-12-12 2017-03-22 清华大学 一种基于航天器无线网络的多线程控制方法
FR3030831B1 (fr) * 2014-12-23 2018-03-02 Idemia France Entite electronique securisee, appareil electronique et procede de verification de l’integrite de donnees memorisees dans une telle entite electronique securisee
US9830217B2 (en) * 2015-01-29 2017-11-28 Qualcomm Incorporated Selective block-based integrity protection techniques
DE102015001801A1 (de) * 2015-02-16 2016-08-18 IAD Gesellschaft für Informatik, Automatisierung und Datenverarbeitung mbH Autonom bootendes System mit einer Verschlüsselung des gesamten Datenspeichers und Verfahren hierfür
US20160246582A1 (en) * 2015-02-25 2016-08-25 Red Hat, Inc. Generic Semantic Configuration Service
US10496974B2 (en) * 2015-03-25 2019-12-03 Intel Corporation Secure transactions with connected peripherals
US9471285B1 (en) * 2015-07-09 2016-10-18 Synopsys, Inc. Identifying software components in a software codebase
US10165457B2 (en) * 2015-08-07 2018-12-25 Telefonaktiebolaget Lm Ericsson (Publ) System and method for root cause analysis of call failures in a communication network
US9860067B2 (en) * 2015-10-29 2018-01-02 At&T Intellectual Property I, L.P. Cryptographically signing an access point device broadcast message
EP3384629B1 (en) * 2015-12-02 2022-05-04 PCMS Holdings, Inc. System and method for tamper-resistant device usage metering
US10395200B2 (en) * 2016-03-17 2019-08-27 Ca, Inc. Method and apparatus for repairing policies
CN107526647B (zh) * 2016-06-21 2021-06-22 伊姆西Ip控股有限责任公司 一种故障处理方法、系统和计算机程序产品
DE102016009232A1 (de) * 2016-07-28 2018-02-01 Giesecke+Devrient Mobile Security Gmbh Integriertes Teilnehmeridentitätsmodul mit Core-OS und Anwendungs-OS
US10496811B2 (en) 2016-08-04 2019-12-03 Data I/O Corporation Counterfeit prevention
US10069633B2 (en) * 2016-09-30 2018-09-04 Data I/O Corporation Unified programming environment for programmable devices
US10666443B2 (en) * 2016-10-18 2020-05-26 Red Hat, Inc. Continued verification and monitoring of application code in containerized execution environment
WO2018194568A1 (en) 2017-04-18 2018-10-25 Hewlett-Packard Development Company, L.P. Executing processes in sequence
US11160006B2 (en) 2017-05-05 2021-10-26 Apple Inc. Access control mechanism
WO2018229657A1 (en) * 2017-06-16 2018-12-20 Telefonaktiebolaget Lm Ericsson (Publ) Apparatuses and methods for handling of data radio bearer integrity protection failure in new radio (nr) network
US10462161B2 (en) * 2017-06-21 2019-10-29 GM Global Technology Operations LLC Vehicle network operating protocol and method
US10938855B1 (en) * 2017-06-23 2021-03-02 Digi International Inc. Systems and methods for automatically and securely provisioning remote computer network infrastructure
US10409685B2 (en) 2017-07-24 2019-09-10 Uber Technologies, Inc. Recovery of application functions via analysis of application operational requests
US10291498B1 (en) * 2017-11-14 2019-05-14 Sprint Communications Company L.P. Mobile communication device diagnostic client and error remediation sharing
FR3074324B1 (fr) * 2017-11-28 2020-01-17 Schneider Electric Industries Sas Procede d'inscription securisee d'un appareil electrique amovible lors de son installation au sein d'un systeme electrique
US10521662B2 (en) 2018-01-12 2019-12-31 Microsoft Technology Licensing, Llc Unguided passive biometric enrollment
JP6706278B2 (ja) * 2018-03-27 2020-06-03 キヤノン株式会社 情報処理装置、及び情報処理方法
CN112041818A (zh) * 2018-05-07 2020-12-04 谷歌有限责任公司 基于平台水平基准化来调整应用性能的系统
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
JP7084826B2 (ja) * 2018-08-28 2022-06-15 キヤノン株式会社 情報処理装置、その制御方法、およびそのプログラム
EP3857415A1 (en) * 2018-09-27 2021-08-04 Landis+Gyr Innovations Inc. Validation and installation of a file system into a transient, non-persistent storage circuit
JP7250121B2 (ja) * 2018-10-09 2023-03-31 グーグル エルエルシー クラウドデグレードモードにおいてデバイス動作信頼性を継続的に確保するための方法および装置
US11056192B2 (en) * 2018-12-21 2021-07-06 Micron Technology, Inc. Monotonic counters in memories
US20200220865A1 (en) * 2019-01-04 2020-07-09 T-Mobile Usa, Inc. Holistic module authentication with a device
CN110032446B (zh) * 2019-03-27 2021-05-04 中国科学院微电子研究所 一种应用于嵌入式系统中分配内存空间的方法及装置
US11886390B2 (en) 2019-04-30 2024-01-30 JFrog Ltd. Data file partition and replication
US11106554B2 (en) 2019-04-30 2021-08-31 JFrog, Ltd. Active-active environment control
US11386233B2 (en) 2019-04-30 2022-07-12 JFrog, Ltd. Data bundle generation and deployment
US11340894B2 (en) 2019-04-30 2022-05-24 JFrog, Ltd. Data file partition and replication
US11068333B2 (en) 2019-06-24 2021-07-20 Bank Of America Corporation Defect analysis and remediation tool
US11461163B1 (en) * 2019-06-28 2022-10-04 Amazon Technologies, Inc. Remote device error correction
WO2021014326A2 (en) * 2019-07-19 2021-01-28 JFrog Ltd. Software release verification
RU2722239C1 (ru) * 2019-11-26 2020-05-28 Общество с ограниченной ответственностью «ПИРФ» (ООО «ПИРФ») Способ создания и использования формата исполняемого файла с динамическим расширяемым заголовком
US11695829B2 (en) 2020-01-09 2023-07-04 JFrog Ltd. Peer-to-peer (P2P) downloading
US11513817B2 (en) * 2020-03-04 2022-11-29 Kyndryl, Inc. Preventing disruption within information technology environments
US11593209B2 (en) 2020-04-01 2023-02-28 Microsoft Technology Licensing, Llc Targeted repair of hardware components in a computing device
US11907052B2 (en) * 2020-04-20 2024-02-20 Dell Products L.P. Systems and methods for encrypting unique failure codes to aid in preventing fraudulent exchanges of information handling system components
US11470677B2 (en) * 2020-08-27 2022-10-11 Dish Network L.L.C. Systems and methods for a computer network intermediate router
US11860680B2 (en) 2020-11-24 2024-01-02 JFrog Ltd. Software pipeline and release validation
KR102432284B1 (ko) * 2021-07-28 2022-08-12 인프라닉스 아메리카 코퍼레이션 It관리대상의 이벤트 알람이나 장애 문제를 실시간 자동으로 조치하는 시스템 및 그 운용방법
US12061889B2 (en) 2021-10-29 2024-08-13 JFrog Ltd. Software release distribution across a hierarchical network
US11765604B2 (en) 2021-12-16 2023-09-19 T-Mobile Usa, Inc. Providing configuration updates to wireless telecommunication networks
TWI823535B (zh) * 2022-08-26 2023-11-21 新唐科技股份有限公司 空中下載裝置及空中下載方法
US12124700B2 (en) * 2022-09-23 2024-10-22 Qualcomm Incorporated Loading multi-segmented software image files into memory using a nested file structure
US12124836B2 (en) 2022-11-03 2024-10-22 Bank Of America Corporation Systems and methods for evaluating, validating, and implementing system environment production deployment tools using cognitive learning input
DE102023106985A1 (de) * 2023-03-21 2024-09-26 Valeo Schalter Und Sensoren Gmbh Verfahren zum Starten eines Softwareprogramms einer Kraftfahrzeug-Recheneinheit,Kraftfahrzeug-Recheneinheit und Rechensystem für ein Kraftfahrzeug

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007515708A (ja) 2003-11-19 2007-06-14 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 携帯端末内のデータ更新方法
WO2010102222A2 (en) * 2009-03-05 2010-09-10 Interdigital Patent Holdings, Inc. METHOD AND APPARATUS FOR H(e)NB INTEGRITY VERIFICATION AND VALIDATION

Family Cites Families (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US6779120B1 (en) 2000-01-07 2004-08-17 Securify, Inc. Declarative language for specifying a security policy
US7076797B2 (en) 2001-10-05 2006-07-11 Microsoft Corporation Granular authorization for network user sessions
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
GB0211644D0 (en) 2002-05-21 2002-07-03 Wesby Philip B System and method for remote asset management
DE10223248A1 (de) 2002-05-22 2003-12-04 Siemens Ag Verfahren zum Registrieren eines Kommunikationsendgeräts
FI117586B (fi) 2002-08-02 2006-11-30 Nokia Corp Menetelmä SIM-toiminteen järjestämiseksi digitaaliseen langattomaan päätelaitteeseen sekä vastaava päätelaite ja palvelin
EP1532791B1 (en) 2002-08-22 2007-08-15 NTT DoCoMo, Inc. Reconfiguration of a group of network nodes in an ad-hoc network
AU2003297228A1 (en) 2002-12-31 2004-07-29 Motorola, Inc, A Corporation Of The State Of Delaware System and method for distributed authorization and deployment of over the air provisioning for a communications device
US7634807B2 (en) 2003-08-08 2009-12-15 Nokia Corporation System and method to establish and maintain conditional trust by stating signal of distrust
DE60306931T2 (de) 2003-09-16 2007-03-01 Research In Motion Ltd., Waterloo Aktualisierungsbereitsstellung auf Bedarfsbasis für eine mobile Kommunikationsvorrichtung
KR100554172B1 (ko) 2003-11-27 2006-02-22 한국전자통신연구원 네트워크 보안성을 강화한 무결성 관리 시스템, 이를구비한 무결성 네트워크 시스템 및 그 방법
US20050138355A1 (en) 2003-12-19 2005-06-23 Lidong Chen System, method and devices for authentication in a wireless local area network (WLAN)
US7350072B2 (en) 2004-03-30 2008-03-25 Intel Corporation Remote management and provisioning of a system across a network based connection
JP4144880B2 (ja) 2004-04-09 2008-09-03 インターナショナル・ビジネス・マシーンズ・コーポレーション プラットフォーム構成測定装置、プログラム及び方法、プラットフォーム構成認証装置、プログラム及び方法、プラットフォーム構成証明装置、プログラム及び方法、並びに、プラットフォーム構成開示装置、プログラム及び方法
ATE428278T1 (de) 2004-06-17 2009-04-15 Ericsson Telefon Ab L M Sicherheit in mobilen kommunikationssystemen
US7747862B2 (en) 2004-06-28 2010-06-29 Intel Corporation Method and apparatus to authenticate base and subscriber stations and secure sessions for broadband wireless networks
ES2368566T3 (es) * 2004-08-20 2011-11-18 Telefonaktiebolaget Lm Ericsson (Publ) Conexión rápida a red.
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
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
US7725703B2 (en) 2005-01-07 2010-05-25 Microsoft Corporation Systems and methods for securely booting a computer with a trusted processing module
JP4293155B2 (ja) 2005-03-31 2009-07-08 サクサ株式会社 コードレス電話機
US7907531B2 (en) 2005-06-13 2011-03-15 Qualcomm Incorporated Apparatus and methods for managing firmware verification on a wireless device
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
US7809777B2 (en) 2005-07-01 2010-10-05 Qnx Software Systems Gmbh & Co. Kg File system having deferred verification of data integrity
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系统中的会话接入方法
JP4708143B2 (ja) 2005-09-30 2011-06-22 シスメックス株式会社 自動顕微鏡及びこれを備える分析装置
GB0520254D0 (en) 2005-10-05 2005-11-16 Vodafone Plc Telecommunications networks
US7580701B2 (en) 2005-12-27 2009-08-25 Intel Corporation Dynamic passing of wireless configuration parameters
WO2007110094A1 (en) 2006-03-27 2007-10-04 Telecom Italia S.P.A. System for enforcing security policies on mobile communications devices
US20070239748A1 (en) 2006-03-29 2007-10-11 Smith Ned M Management of reference data for platform verification
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
CN101410847B (zh) 2006-06-30 2011-11-09 国际商业机器公司 在移动设备处的消息处理方法以及移动设备和智能卡
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
US20080101400A1 (en) * 2006-10-30 2008-05-01 Nokia Corporation Managing attachment of a wireless terminal to local area networks
US7683630B2 (en) * 2006-11-30 2010-03-23 Electro Scientific Industries, Inc. Self test, monitoring, and diagnostics in grouped circuitry modules
KR101368327B1 (ko) 2006-12-22 2014-02-26 삼성전자주식회사 프로그램 실행흐름 보고 시스템 및 방법
TWI543644B (zh) 2006-12-27 2016-07-21 無線創新信號信託公司 基地台自行配置方法及裝置
WO2008110996A1 (en) 2007-03-12 2008-09-18 Nokia Corporation Apparatus, method and computer program product providing auxillary handover command
DE602007013701D1 (de) 2007-04-17 2011-05-19 Alcatel Lucent Verfahren zur Verkoppelung eines Femto-Zellengeräts mit einem mobilen Kernnetzwerk
US8064597B2 (en) 2007-04-20 2011-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for mobile device credentialing
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
US8365018B2 (en) * 2007-06-19 2013-01-29 Sand Holdings, Llc Systems, devices, agents and methods for monitoring and automatic reboot and restoration of computers, local area networks, wireless access points, modems and other hardware
KR101392697B1 (ko) * 2007-08-10 2014-05-19 엘지전자 주식회사 이동통신 시스템에서의 보안 오류 검출방법 및 장치
US7853804B2 (en) 2007-09-10 2010-12-14 Lenovo (Singapore) Pte. Ltd. System and method for secure data disposal
US8200736B2 (en) 2007-12-24 2012-06-12 Qualcomm Incorporated Virtual SIM card for mobile handsets
KR101611649B1 (ko) 2008-01-18 2016-04-26 인터디지탈 패튼 홀딩스, 인크 M2m 통신을 인에이블하는 방법 및 장치
US8300829B2 (en) 2008-06-23 2012-10-30 Nokia Corporation Verification key handling
WO2010102259A2 (en) 2009-03-06 2010-09-10 Interdigital Patent Holdings, Inc. Platform validation and management of wireless devices
CN101651949B (zh) * 2009-08-17 2011-10-26 中兴通讯股份有限公司 一种安全模式建立的方法及无线网络控制器
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
CN101820619B (zh) * 2010-01-15 2012-10-24 北京工业大学 无线传感器网络中高效节能的链路安全方法
CN101771704B (zh) * 2010-01-22 2016-03-30 中兴通讯股份有限公司 一种安全的数据传输的方法和系统
KR20130020734A (ko) * 2010-04-12 2013-02-27 인터디지탈 패튼 홀딩스, 인크 부팅 처리에서의 단계화 제어 해제
KR101622447B1 (ko) 2010-11-05 2016-05-31 인터디지탈 패튼 홀딩스, 인크 장치 유효성 확인, 재난 표시, 및 복원

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007515708A (ja) 2003-11-19 2007-06-14 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 携帯端末内のデータ更新方法
WO2010102222A2 (en) * 2009-03-05 2010-09-10 Interdigital Patent Holdings, Inc. METHOD AND APPARATUS FOR H(e)NB INTEGRITY VERIFICATION AND VALIDATION

Also Published As

Publication number Publication date
EP2635991A1 (en) 2013-09-11
TWI596959B (zh) 2017-08-21
JP2013545193A (ja) 2013-12-19
KR20140079865A (ko) 2014-06-27
TW201620318A (zh) 2016-06-01
US8914674B2 (en) 2014-12-16
TWI527474B (zh) 2016-03-21
US20150099510A1 (en) 2015-04-09
EP2635991B1 (en) 2015-09-16
US20120290870A1 (en) 2012-11-15
CN103202045B (zh) 2016-06-01
JP2016006659A (ja) 2016-01-14
US9652320B2 (en) 2017-05-16
KR101622447B1 (ko) 2016-05-31
WO2012061678A1 (en) 2012-05-10
KR20170016034A (ko) 2017-02-10
AU2011323225B2 (en) 2015-05-28
CN106055930A (zh) 2016-10-26
CN103202045A (zh) 2013-07-10
TW201735675A (zh) 2017-10-01
KR20130084688A (ko) 2013-07-25
EP3002697A1 (en) 2016-04-06
TW201234877A (en) 2012-08-16
AU2011323225A1 (en) 2013-05-30
US20170199777A1 (en) 2017-07-13
JP5810168B2 (ja) 2015-11-11

Similar Documents

Publication Publication Date Title
KR101703925B1 (ko) 장치 유효성 확인, 재난 표시, 및 복원
US11494484B2 (en) Leveraging instrumentation capabilities to enable monitoring services
US11805107B2 (en) Extracting encryption keys to enable monitoring services
JP6231054B2 (ja) 無線装置のプラットフォームの検証と管理
US8474032B2 (en) Firewall+ storage apparatus, method and system
US20170364685A1 (en) Providing security to computing systems
US9455955B2 (en) Customizable storage controller with integrated F+ storage firewall protection
WO2021087221A1 (en) Secure and flexible boot firmware update for devices with a primary platform
Blázquez et al. Trouble over-the-air: An analysis of fota apps in the android ecosystem
Mitra A security & privacy analysis of us-based contact tracing apps
AU2015221575A1 (en) Device validation, distress indication, and remediation
Draschbacher et al. CryptoShield-Automatic On-Device Mitigation for Crypto API Misuse in Android Applications
US20220100860A1 (en) Secure collection and communication of computing device working data
Zhao Authentication and Data Protection under Strong Adversarial Model
D'Onghia Use of SGX to protect network nodes
Sood Digging inside the vxworks os and firmware the holistic security
Juhász et al. Secure remote firmware update on embedded IoT devices
Su Trust and integrity in distributed systems
Schäfer Risk analysis and software integrity protection for 4g network elements in ASMONIA
Holloway Project number: 883156 Project acronym: EXFILES Project title

Legal Events

Date Code Title Description
A107 Divisional application of patent
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
A107 Divisional application of patent
GRNT Written decision to grant