KR20120140249A

KR20120140249A - 신뢰성 있는 하드웨어 가입 모듈 간의 크리덴셜 및/또는 도메인의 마이그레이션

Info

Publication number: KR20120140249A
Application number: KR1020127025623A
Authority: KR
Inventors: 루이스 구치오네; 인혁 차; 안드레아스 슈미트; 안드레아스 라이셔
Original assignee: 인터디지탈 패튼 홀딩스, 인크
Priority date: 2010-03-02
Filing date: 2011-03-02
Publication date: 2012-12-28
Also published as: KR20140094008A; US9032473B2; EP2543207A1; KR101580353B1; JP2013522705A; CN103081432B; WO2011109518A1; JP2014116953A; JP5457563B2; US20130212637A1; EP2543207B1; CN103081432A; JP5750519B2

Abstract

사용자가 한 도메인으로부터 다른 도메인으로 크리텐셜의 마이그레이션을 개시할 수 있게 해줄 수 있는 시스템, 방법 및 수단이 개시되어 있다. 제1 도메인으로부터 제2 도메인으로의 크리텐셜의 마이그레이션을 개시하라는 요청이 사용자(1a)에 의해 개시될 수 있다. 원격 소유자는 마이그레이션이 요청되었다는 것을 나타내는 메시지를 수신할 수 있다. 원격 소유자에 의해 수신된 메시지는 소스 및 목적지 장치가 내부 검사를 수행했고 마이그레이션이 진행될 수 있는 것으로 결정했다는 표시일 수 있다. 원격 소유자는 소스 장치로부터 수신된 소스 정보 및 목적지 장치로부터 수신된 목적지 정보를 평가할 수 있다(6, 6a, 6b). 소스 정보 및 목적지 정보의 평가에 기초하여, 원격 소유자는 마이그레이션이 허용가능하다고 결정할 수 있다. 원격 소유자는 마이그레이션을 진행하라는 표시를 전송할 수 있다(7, 7a).

Description

신뢰성 있는 하드웨어 가입 모듈 간의 크리텐셜 및/또는 도메인의 마이그레이션{MIGRATION OF CREDENTIALS AND/OR DOMAINS BETWEEN TRUSTED HARDWARE SUBSCRIPTION MODULES}

기술분야

본 발명은 신뢰성 있는 하드웨어 가입 모듈 간의 크리텐셜 및/또는 도메인의 마이그레이션에 관한 것이다.

관련 출원의 상호 참조

본 출원은 2010년 3월 2일자로 출원된 미국 가특허 출원 제61/309,569호에 기초하여 우선권을 주장하며, 그 개시 내용이 참조 문헌으로서 그 전체가 본 명세서에 포함된다.

현재 이동 통신 산업에서, 사용자가 특정의 네트워크 통신사업자의 서비스에 가입하는 데 사용할 수 있는 무선 장치는 통상적으로 SIM(Subscriber Identity Module) 또는 UICC(Universal Integrated Circuit Card)를 포함하고 있다. SIM/UICC는 무선 장치가 네트워크 통신사업자를 위해 네트워크 통신사업자에 대한 장치 사용자의 가입을 인증할 수 있게 해주고 네트워크 통신사업자가 무선 장치에 대한 어떤 형태의 제어(즉, 소유권)를 가질 수 있게 해주는 인증 알고리즘을 실행하고 크리텐셜을 저장하는 보안 실행 및 저장 환경을 무선 장치에 제공한다. 안타깝게도, 이 SIM/UICC 메커니즘은 통상적으로 단일 네트워크 통신사업자에서의 사용으로 제한되어 있다.

따라서, 이동 통신 장치에 대해 전술한 상황과 같은, 현재 많은 컴퓨팅 상황에서의 문제점은 컴퓨팅 장치가 종종 전적으로 단일 엔터티에 의해 "소유"되는 것으로 제한되어 있다는 것이다. 많은 경우에, 소유권이 사용자에 의한 장치의 구입 시에 설정되어야만 하고, 이는 나중에 소유권을 설정하는 것이 바람직할 수 있는 비즈니스 모델을 방해한다. 게다가, 이러한 제한들은 장치의 다수의 상호 분리되어 있는 부분에 대한 다수의 소유권이 존재하는 것 또는 소유권이 때때로 다른 엔터티로 이전되는 것이 바람직할 수 있는 상황에서의 장치의 사용을 방해한다. 예를 들어, 이동 전화 등의 무선 이동 통신 장치의 경우, 사용자는 통상적으로 구입 시에 특정의 모바일 네트워크 통신 사업자의 서비스에 가입해야만 하고 이러한 장치는 종종 모바일 네트워크 통신 사업자가 무선 장치의 구입하고 어느 정도 지나서야 알게 될 수 있는 응용 분야에서 사용되지 못한다. 또한, 통상적으로 이러한 장치가 한번에 다수의 통신 사업자 네트워크에 액세스하는 것이 가능하지 않다. 모바일 네트워크 및 서비스 가입을 갱신하거나 변경하는 것이 어려울 수 있고, 공중을 통해 그렇게 하는 것이 보통 가능하지 않다.

또한, 특히 무선 이동 통신 장치와 관련하여, SIM/UICC 메커니즘이 일반적으로 보안성이 높은 것으로 간주되고 있지만, 이 보안이 그 메커니즘이 존재하는 장치 전체의 보안 속성에 강하게 연계되어 있지 않다. 이것은 모바일 금융 거래 등의 고급 서비스 및 응용 분야를 위해 보안 개념을 확장시키는 응용 분야를 제한한다. 상세하게는, 이들 단점은 M2M(machine-to-machine) 통신 장치 등의 자율 장치에 관련되어 있다.

그에 따라, 보다 동적인 해결 방안이 바람직하다.

사용자가 한 도메인으로부터 다른 도메인으로 크리텐셜의 마이그레이션을 개시할 수 있게 해줄 수 있는 시스템, 방법 및 수단이 개시되어 있다. 마이그레이션은 하나 이상의 개별 도메인 - 각각의 도메인이 하나 이상의 상이한 로컬 또는 원격 소유자에 의해 소유되거나 제어될 수 있음 - 을 갖는 하나 이상의 장치를 포함하는 시스템에서 일어날 수 있다. 하나 이상의 장치는 적어도 하나의 플랫폼에 의해 지원되는 하나 이상의 도메인을 포함할 수 있다. 각각의 플랫폼은 하위-레벨 컴퓨팅, 저장, 또는 통신 자원을 도메인에 제공할 수 있다. 플랫폼은 어떤 하드웨어, 운영 체제, 어떤 하위-레벨 펌웨어 또는 소프트웨어(부트 코드, BIOS, API, 드라이버, 미들웨어, 또는 가상화 소프트웨어 등), 및 어떤 상위-레벨 펌웨어 또는 소프트웨어(응용 프로그램 소프트웨어 등)와 이러한 자원에 대한 각자의 구성 데이터로 이루어져 있을 수 있다. 각각의 도메인은 적어도 하나의 플랫폼 상에서 실행 중인 컴퓨팅, 저장 또는 통신 자원의 구성을 포함할 수 있고, 각각의 도메인은 도메인으로부터 원격적으로 또는 로컬적으로 위치될 수 있는 도메인의 소유자를 위한 기능을 수행하도록 구성될 수 있다. 각각의 도메인은 상이한 소유자를 가질 수 있고, 각각의 소유자는 그의 도메인의 운영에 대한 정책은 물론, 도메인이 존재하는 플랫폼 및 다른 도메인과 관련한 그의 도메인의 운영에 대한 정책을 지정할 수 있다. 가입-기반 서비스를 제공하는 원격 소유자는 원격 소유자 도메인(remote owner domain)이라고 할 수 있는 도메인의 소유권을 취득했을 수 있다. 게다가, 사용자는 사용자 도메인(user domain)이라고 할 수 있는 도메인의 소유권을 취득했을 수 있다.

제1 도메인으로부터 제2 도메인으로의 크리텐셜의 마이그레이션을 개시하라는 요청이 개시될 수 있다. 예를 들어, 소스 및 목적지 장치의 사용자는 소스 장치 상의 원격 소유자 도메인과 연관된 크리텐셜을 목적지 장치 상의 원격 소유자 도메인으로 전송하라고 요청할 수 있다. 원격 소유자는 마이그레이션이 요청되었다는 것을 나타내는 메시지를 수신할 수 있다. 원격 소유자에 의해 수신된 메시지는 소스 및 목적지 장치가 내부 검사를 수행했고 마이그레이션이 진행될 수 있는 것으로 결정했다는 표시일 수 있다. 원격 소유자에 의해 수신된 메시지는 사용자가 마이그레이션 요청을 개시했다는 표시일 수 있다.

원격 소유자는 소스 장치로부터 수신된 소스 정보 및 목적지 장치로부터 수신된 목적지 정보를 평가할 수 있다. 예를 들어, 소스 정보는 소스 정책, 소스 구성, 소스 ID(source identification), 또는 소스 무결성 표시자(source integrity indicator) 중 적어도 하나를 포함할 수 있다. 목적지 정보는 목적지 정책, 목적지 구성, 목적지 ID(destination identification), 또는 목적지 무결성 표시자(destination integrity indicator) 중 적어도 하나를 포함할 수 있다. 소스 정보 및 목적지 정보의 평가에 기초하여, 원격 소유자는 마이그레이션이 허용가능(acceptable)하다고 결정할 수 있다. 예를 들어, 원격 소유자는 장치와 연관된 정책이 크리텐셜을 마이그레이션하는 것과 상충되지 않는 것으로 결정할 수 있다. 이러한 정책 평가는 소스 도메인 및 목적지 도메인 이외의 도메인의 정책을 포함할 수 있다. 원격 소유자는 마이그레이션을 진행하라는 표시를 전송할 수 있다.

소스 및 목적지 장치에 의해 추가의 검사가 수행될 수 있다. 예를 들어, 소스 장치가 목적지 장치의 상태를 평가할 수 있고, 목적지 장치가 소스 장치의 상태를 평가할 수 있다. 원격 소유자는 마이그레이션이 완료되었고 소스 장치가 크리텐셜을 파기했다는 것을 나타내는 소스 완료 메시지(source completion message)를 소스 장치로부터 수신할 수 있다. 원격 소유자는 마이그레이션이 완료되었고 크리텐셜이 목적지 장치의 도메인 상에 복제되었다는 것을 나타내는 목적지 완료 메시지(destination completion message)를 목적지 장치로부터 수신할 수 있다.

본 명세서에 기술된 시스템, 방법 및 수단의 다른 특징이 이하의 상세한 설명 및 첨부 도면에 제공되어 있다.

도 1은 본 명세서에 기술된 방법 및 수단이 이용될 수 있는 예시적인 시스템을 나타낸 도면.
도 2는 본 명세서에 기술된 방법 및 수단이 사용자 장비(UE)에서 구현되는 시스템의 일 실시예를 나타낸 도면.
도 3 및 도 3a는 예시적인 부트업(boot up) 및 도메인의 소유권을 취득하는 프로세스를 나타낸 도면.
도 4 및 도 4a는 도메인의 소유권을 취득하는 프로세스에 대한 예시적인 호 흐름도.
도 5 및 도 5a는 완전한 증명(full attestation)을 갖는 도메인의 소유권을 취득하는 프로세스에 대한 예시적인 호 흐름도.
도 6은 신뢰성 있는 하드웨어 가입 모듈의 일 실시예의 예시적인 상태 정의, 천이 및 제어점 정의를 나타낸 도면.
도 7은 원격 소유자 도메인이 달성할 수 있는 예시적인 상태 및 동적으로 관리되는 환경에서 천이가 일어날 수 있는 조건을 나타낸 도면.
도 8은 등록 및 크리텐셜 롤아웃(credential roll-out) 프로세스를 구현하는 예시적인 호 흐름을 나타낸 도면.
도 9a 및 도 9b는 크리텐셜 마이그레이션을 구현하는 예시적인 호 흐름을 나타낸 도면.
도 9c는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 통신 시스템의 시스템도.

도 1 내지 도 9는 개시된 시스템, 방법 및 수단이 구현될 수 있는 예시적인 실시예에 관한 것일 수 있다. 그렇지만, 본 발명이 예시적인 실시예와 관련하여 기술되어 있을 수 있지만, 본 발명이 그것으로 제한되지 않고, 본 발명을 벗어나지 않고 본 발명의 동일한 기능을 수행하기 위해, 다른 실시예가 사용될 수 있거나 기술된 실시예에 대해 수정 및 추가가 행해질 수 있다는 것을 잘 알 것이다. 게다가, 도면은 예시하기 위한 것인 호 흐름을 나타낸 것일 수 있다. 다른 실시예가 사용될 수 있다는 것을 잘 알 것이다. 게다가, 적절한 경우, 흐름의 순서가 변화될 수 있다. 그에 부가하여, 필요하지 않은 경우 흐름이 생략될 수 있고, 부가의 흐름이 추가될 수 있다.

사용자가 한 도메인으로부터 다른 도메인으로 크리텐셜을 마이그레이션할 수 있게 해줄 수 있는 시스템, 방법 및 수단이 개시되어 있다. 마이그레이션은 하나 이상의 개별 도메인 - 각각의 도메인이 하나 이상의 상이한 로컬 또는 원격 소유자에 의해 소유되거나 제어될 수 있음 - 을 갖는 하나 이상의 장치를 포함하는 시스템에서 일어날 수 있다. 하나 이상의 장치는 적어도 하나의 플랫폼에 의해 지원되는 하나 이상의 도메인을 포함할 수 있다. 각각의 플랫폼은 하위-레벨 컴퓨팅, 저장, 또는 통신 자원을 도메인에 제공할 수 있다. 플랫폼은 어떤 하드웨어, 운영 체제, 어떤 하위-레벨 펌웨어 또는 소프트웨어(부트 코드, BIOS, API, 드라이버, 미들웨어, 또는 가상화 소프트웨어 등), 및 어떤 상위-레벨 펌웨어 또는 소프트웨어(응용 프로그램 소프트웨어 등)와 이러한 자원에 대한 각자의 구성 데이터로 이루어져 있을 수 있다. 각각의 도메인은 적어도 하나의 플랫폼 상에서 실행 중인 컴퓨팅, 저장 또는 통신 자원의 구성을 포함할 수 있고, 각각의 도메인은 도메인으로부터 원격적으로 또는 로컬적으로 위치될 수 있는 도메인의 소유자를 위한 기능을 수행하도록 구성될 수 있다. 각각의 도메인은 상이한 소유자를 가질 수 있고, 각각의 소유자는 그의 도메인의 운영에 대한 정책은 물론, 도메인이 존재하는 플랫폼 및 다른 도메인과 관련한 그의 도메인의 운영에 대한 정책을 지정할 수 있다. 가입-기반 서비스를 제공하는 원격 소유자는 원격 소유자 도메인(remote owner domain)이라고 할 수 있는 도메인의 소유권을 취득했을 수 있다. 게다가, 사용자는 사용자 도메인(user domain)이라고 할 수 있는 도메인의 소유권을 취득했을 수 있다.

원격 소유자는 소스 장치로부터 수신된 소스 정보 및 목적지 장치로부터 수신된 목적지 정보를 평가할 수 있다. 예를 들어, 소스 정보는 소스 정책, 소스 구성, 소스 ID(source identification), 또는 소스 무결성 표시자(source integrity indicator) 중 적어도 하나를 포함할 수 있다. 목적지 정보는 목적지 정책, 목적지 구성, 목적지 ID(destination identification), 또는 목적지 무결성 표시자(destination integrity indicator) 중 적어도 하나를 포함할 수 있다. 소스 정보 및 목적지 정보의 평가에 기초하여, 원격 소유자는 마이그레이션이 허용가능하다고 결정할 수 있다. 예를 들어, 원격 소유자는 장치와 연관된 정책이 크리텐셜을 마이그레이션하는 것과 상충되지 않는 것으로 결정할 수 있다. 이러한 정책 평가는 소스 도메인 및 목적지 도메인 이외의 도메인의 정책을 포함할 수 있다. 시스템 레벨 정책은 소스 및 목적지 정책과 소스 및 목적지 장치에 관한 다른 도메인의 정책 간의 잠재적인 충돌을 결정할 수 있다. 원격 소유자는 마이그레이션을 진행하라는 표시를 전송할 수 있다.

I. 예시적인 다중 도메인 시스템

도 1 내지 도 7은 개시된 시스템, 방법 및 수단이 구현될 수 있는 예시적인 실시예에 관한 것일 수 있다. 그렇지만, 본 발명이 예시적인 실시예와 관련하여 기술되어 있을 수 있지만, 본 발명이 그것으로 제한되지 않고, 본 발명을 벗어나지 않고 본 발명의 동일한 기능을 수행하기 위해, 다른 실시예가 사용될 수 있거나 기술된 실시예에 대해 수정 및 추가가 행해질 수 있다는 것을 잘 알 것이다.

개시된 시스템, 방법 및 수단이 구현될 수 있는 예시적인 시스템은 하나 이상의 장치 - 각각이 적어도 하나의 플랫폼에 의해 지원되는 하나 이상의 도메인을 포함할 수 있음 - 를 포함한다. 각각의 플랫폼은 하위-레벨 컴퓨팅, 저장, 또는 통신 자원을 도메인에 제공할 수 있다. 플랫폼은 어떤 하드웨어, 운영 체제, 및 기타 하위 레벨 펌웨어 또는 소프트웨어(부트 코드, BIOS 및 드라이버 등) 그리고 이러한 자원에 대한 각자의 구성 데이터로 이루어져 있을 수 있다. 각각의 도메인은 적어도 하나의 플랫폼 상에서 실행 중인 컴퓨팅, 저장 또는 통신 자원의 구성을 포함할 수 있고, 각각의 도메인은 도메인으로부터 원격적으로 또는 로컬적으로 위치될 수 있는 도메인의 소유자를 위한 기능을 수행하도록 구성될 수 있다. 각각의 도메인은 상이한 소유자를 가질 수 있고, 각각의 소유자는 그의 도메인의 운영에 대한 정책은 물론, 도메인이 존재하는 플랫폼 및 다른 도메인과 관련한 그의 도메인의 운영에 대한 정책을 지정할 수 있다.

각각의 도메인은, 컴퓨팅, 저장, 또는 통신 자원(입력 관점에서 본 것임) 또는 도메인이 이러한 컴퓨팅, 저장 또는 통신 자원을 사용하여 제공하는 기능(출력 관점에서 본 것임)과 관련하여, 다른 도메인과 분리되어 있을 수 있다. 각각의 도메인은 공통의 기본 플랫폼의 컴퓨팅, 저장 또는 통신 자원 또는 기능에 의존할 수 있다. 어떤 도메인은 공통의 플랫폼에 의해 제공되는 이러한 기능들 중 일부를 공유할 수 있다. 플랫폼 자원 및/또는 기능의 이러한 공유는 각각의 도메인에서의 공통 자원 또는 기능의 사용이 다른 도메인에서의 이러한 사용과 분리될 수 있도록 하는 방식으로 행해질 수 있다. 예를 들어, 장치의 플랫폼이, 도메인의 자원에 대한 임의의 액세스가 플랫폼 및/또는 도메인의 소유자에 의해 허가되어 있는 도메인 외부에 있는 사용자(들), 소유자(들), 또는 다른 엔터티 또는 프로세스에게만 허용될 수 있도록, 플랫폼이 각각의 도메인에 제공하는 자원에 대한 엄격한 액세스 제어를 시행함으로써 이러한 분리가 달성될 수 있다. 도메인의 기능들 중 임의의 기능이 장치 상의 도메인들 중 임의의 도메인의 외부에 있는 장치의 자원에 의존하는 한, 플랫폼이 또한 단지 장치 상의 분리된 도메인들 중 임의의 도메인의 일부가 아닌 장치의 일부로 이루어져 있을 수 있다.

동일한 또는 상이한 플랫폼 상의 또는 동일한 또는 상이한 장치 상의 임의의 2개의 도메인 사이의 통신이 안전하게 될 수 있고, 이는 도메인이 서로를 안전한 방식으로(예컨대, 암호적 수단을 사용함으로써) 인증할 수 있고 또한 기밀성(confidentiality), 무결성(integrity) 및 신선성(freshness) 등의 보안 측면을 위해 이들 간에 교환되는 메시지를 보호할 수 있다는 것을 의미한다. 도메인이 존재하는 플랫폼(들)에 의해 제공되는 암호적 수단은 임의의 2개의 도메인 간의 이러한 보안 통신을 제공하는 데 사용될 수 있다.

시스템 전체 도메인 관리자(system-wide domain manager)는 도메인들 중 하나의 도메인에 존재할 수 있다. 시스템 전체 도메인 관리자는 자신이 존재하는 도메인의 정책을 집행할 수 있고, 시스템 전체 도메인 관리자가 존재하는 도메인과 관련하여 다른 도메인의 집행을 그 각자의 정책에 의해 조정할 수 있다. 그에 부가하여, 시스템 전체 도메인 관리자는 다른 도메인들 간의 상호작용을 그 각자의 정책에 따라 조정할 수 있다. 시스템 전체 도메인 관리자가 존재하는 도메인이 그 도메인을 가지고 있는 장치의 소유자에 의해 소유될 수 있다. 다른 대안으로서, 이러한 도메인이 그 도메인을 가지고 있는 장치의 소유자가 아닐지도 모르는 소유자에 의해 소유될 수 있다.

도 1은 이러한 시스템의 일 실시예를 나타낸 것이다. 도시된 바와 같이, 이 시스템은 하나 이상의 장치(100, 110, 120)를 포함할 수 있다. 각각의 장치는 적어도 하나의 플랫폼에 의해 지원되는 하나 이상의 도메인을 포함할 수 있다. 예를 들어, 장치(100)는 도메인(106) 및 하나 이상의 다른 도메인(101, 102)을 포함할 수 있다. 장치(100)에 대해 3개의 도메인이 예시되어 있지만, 다른 실시예에서, 도메인의 수가 더 많거나 더 적을 수 있다. 이들 도메인(101, 102, 106) 각각은 장치의 적어도 하나의 플랫폼(105) 상에서 실행 중인 컴퓨팅, 저장, 또는 통신 자원의 구성을 포함할 수 있다. 각각의 도메인은 도메인으로부터 원격적으로 또는 로컬적으로 위치될 수 있는 도메인의 소유자에 대한 기능을 수행하도록 구성될 수 있다. 예를 들어, 도메인(106)이 장치 소유자(도시 생략)의 소유일 수 있는 반면, 도메인(101, 102)은 하나 이상의 원격 소유자에 의해 소유될 수 있다. 각각의 도메인이 상이한 소유자를 가질 수 있거나, 장치의 2개 이상의 도메인이 동일한 소유자에 의해 소유될 수 있다. 각각의 소유자는 그의 도메인의 운영에 대한 정책은 물론, 그 도메인이 운영되는 플랫폼, 그 도메인이 존재하는 장치, 및 동일한 또는 상이한 장치 내의 다른 도메인과 관련하여 그의 도메인의 운영에 대한 정책도 지정할 수 있다.

전술한 바와 같이, 이 시스템은 또한 다른 도메인이 존재하는 다른 장치를 포함할 수 있다. 예를 들어, 장치(110)는 도메인(111, 112) - 각각이 동일한 원격 소유자에 의해 소유될 수 있음 - 을 포함할 수 있다. 물론, 도메인(111, 112) 각각이 그 대신에 각각 상이한 소유자에 의해 소유될 수 있다. 도메인(111, 112) 각각은 장치(110)의 플랫폼(115) 상에서 실행 중인 컴퓨팅, 저장, 또는 통신 자원의 구성을 포함할 수 있다. 이와 유사하게, 장치(120)는 도메인(121, 122)를 포함할 수 있다. 이 일례에서 도시된 바와 같이, 이들 도메인 각각은 상이한 소유자에 의해 소유될 수 있다. 다른 대안으로서, 이들 도메인이 동일한 소유자에 의해 소유될 수 있다. 다시 말하지만, 도메인(121, 122) 각각은 장치(120)의 플랫폼(125) 상에서 실행 중인 컴퓨팅, 저장, 또는 통신 자원의 구성을 포함할 수 있다.

시스템 전체 도메인 관리자(SDM)(107)는 도메인들 중 하나의 도메인에 존재할 수 있다. 이 일례에서, SDM(107)은 장치(100)의 도메인(106) 상에 존재한다. 일 실시예에서, SDM이 존재하는 도메인[예컨대, 도메인(106)]은 장치(100)의 소유자에 의해 소유된다. SDM(107)은 장치(100)에 제공된 통신 메커니즘을 통해 장치(100) 상의 원격 소유자 도메인(101)과 통신한다. 그에 부가하여, SDM(107)은 유선 또는 무선 채널일 수 있는 각자의 통신 채널(131, 132, 141, 142)을 통해 다른 장치 상의 도메인과 통신한다. 통신 채널(131, 132, 141, 142)은 안전할 수 있다. SDM(107)은 그가 존재하는 도메인(106)의 정책을 집행할 수 있고, 도메인(106)과 관련하여 그 각자의 정책에 의해 다른 도메인(101, 111, 112, 121, 122)의 집행을 조정할 수 있다. 그에 부가하여, SDM(107)은 다른 도메인들 간의 상호작용을 그 각자의 정책은 물론, SDM이 존재하는 도메인의 정책(그 특정의 도메인의 소유자의 정책일 것임)에 따라 조정할 수 있다.

일례로서, 일 실시예에서, 도메인이 서비스 공급자의 소유일 수 있다. 예를 들어, 장치(100)의 도메인(102)이 서비스 공급자 - 단지 일례로서, 모바일 네트워크 통신 사업자 등 - 의 소유일 수 있다. 도메인(102)은 장치(100)와 서비스 공급자 사이의 통신을 가능하게 해주기 위해 서비스 공급자를 위해 장치(100) 또는, 어떤 경우에 이와 동등하게 장치의 소유자 또는 사용자의 가입을 인증하기 위해 SIM(subscriber identity module) 기능을 수행할 수 있다.

전술한 SDM의 기능에 부가하여, SDM(107)은 정보에 액세스하고 상기 하나 이상의 도메인이 사용할 수 있는 자원의 목록을 제공할 수 있다. SDM(107)은 또한 원격 소유자에 의해 소유된 도메인의 로딩(loading) 및 유지(maintenance)를 관리할 수 있다. SDM(107)은 SDM이 존재하는 장치(100)의 사용자에게 로드할 수 있는 도메인의 목록을 제공할 수 있고, 사용자에게 열거된 도메인들 중 어느 것을 로드할지를 선택하라고 요청할 수 있다. SDM은 또한 하나 이상의 도메인을 로드하고 따라서 그의 운영을 지원하기에 충분한 컴퓨팅 자원이 플랫폼 또는 장치 상에 있는지를 평가할 수 있다.

또한 이상에서 언급한 바와 같이, SDM(107)은 그 자신의 정책(들) - 본 명세서에서 시스템 전체 도메인 정책(system-wide domain policy, SDP)이라고 할 수 있음 - 은 물론, 다른 도메인의 정책(들) - 즉, 도메인-관련 정책(domain-specific policy, DP) - 을 집행하는 데 참여할 수 있다. SDM(107)은 새로운 도메인을 로드할지 여부를 평가할 때 하나 이상의 기존의 도메인의 정책을 고려할 수 있다. 예를 들어, 원격 소유자에 의해 소유된 주어진 도메인의 정책이, 어떤 유형의 다른 도메인이 활성으로 될 때 그 주어진 도메인이 비활성으로 되도록 지정할 수 있다. 다른 일례에서, 원격 소유자에 의해 소유된 주어진 도메인의 정책이, 어떤 다른 원격 소유자에 의해 소유된 다른 도메인이 활성으로 될 때 그 주어진 도메인이 비활성으로 되도록 지정할 수 있다. 또 다른 일례에서, 원격 소유자에 의해 소유된 주어진 도메인의 정책이, 어떤 유형의 다른 도메인이 활성으로 될 때 그 주어진 도메인의 운영이 어떤 특정의 방식(들)으로 제한되도록 지정할 수 있다. 추가의 일례에서, 원격 소유자에 의해 소유된 주어진 도메인의 정책이, 어떤 다른 원격 소유자에 의해 소유된 다른 도메인이 활성으로 될 때 그 주어진 도메인의 운영이 어떤 특정의 방식(들)으로 제한되도록 지정할 수 있다. SDM(107)은 이들 유형의 정책 모두를 집행할 책임을 지고 있을 수 있다.

SDM(107)은 또한 원격 소유자가 나중에 소유권을 취득할지도 모르는 도메인을 설정하거나 로드할 수 있다. 예를 들어, 이러한 도메인은 본 명세서에서 어떤 소유자의 소유도 아닌 "원시(pristine)" 상태라고 하는 상태로 설정될 수 있고, SDM(107)은 원격 소유자의 도메인의 소유권의 설정을 관리할 수 있다.

그를 위해, SDM(107)은 원격 소유자가 도메인의 소유권을 설정할지 여부를 결정할 시에 고려할 수 있는 정보를 원격 소유자에게 전송할 수 있다. 이 정보는 (i) 소유권을 얻고자 하는 도메인의 무결성을 증명하는 정보; 및 (ii) 시스템의 적어도 하나의 다른 도메인의 무결성을 증명하는 정보 중 적어도 하나를 포함할 수 있다. 이 정보는 또한 (i) 소유권을 얻고자 하는 도메인이 운영하는 자원을 사용하여 플랫폼의 무결성을 증명하는 정보; 및 (ii) 시스템의 적어도 하나의 다른 도메인이 운영하는 자원을 사용하여 플랫폼의 무결성을 증명하는 정보를 포함할 수 있다. 그에 부가하여, 이 정보는 장치의 현재 환경에 관한 정보를 포함할 수 있다. 이러한 정보는 (i) 시스템 내의 도메인의 수를 나타내는 값; (ii) 시스템 내의 다른 도메인의 요약 특성을 제공하는 정보; 및 (iii) 소유권을 설정하고자 하는 도메인이 사용할 수 있는 플랫폼의 자원을 지정하는 정보 중 적어도 하나를 포함할 수 있다. 시스템의 다른 도메인에 관한 정보가 원격 소유자에게 제공되는 정도는 기밀성 및/또는 분리와 관련하여 이들 다른 도메인의 각자의 정책에 따라 조절될 수 있다.

원격 소유자가 도메인의 소유권을 취득한 후에, 원격 소유자는 도메인에 대해 어느 정도의 제어를 실시할 수 있다. 예를 들어, 원격 소유자가 도메인의 소유권을 설정한 후에, 도메인은 도메인의 기능을 향상시키기 위해 암호 키, 구성 정보, 파라미터 및 실행가능 코드 중 적어도 하나를 원격 소유자로부터 수신할 수 있다. 다른 일례에서, 원격 소유자가 도메인의 소유권을 설정한 후에, 도메인은 그의 도메인-관련 정책을 원격 소유자로부터 수신할 수 있다.

본 명세서에 개시된 시스템은 또한 하나 이상의 도메인의 분리 및 보안을 제공할 수 있다. 예를 들어, 도메인들 중 하나 이상의 도메인이 다른 도메인과 분리되어 있는 안전한 실행 및 저장 환경을 포함할 수 있다. 이러한 안전한 환경을 달성하기 위해, 하나 이상의 도메인이 설정되어 있는 장치의 플랫폼 - 도 1의 장치(100)의 플랫폼(105) 등 - 은 신뢰의 기초(root of trust)(103)를 포함할 수 있다. 신뢰의 기초(103)는 변경할 수도 없고 이동할 수도 없는 일련의 하드웨어 자원 - 그의 무결성이 사전 설정되어 있고 도메인의 원격 소유자를 비롯한 다른 사람에 의해 신뢰될 수 있음 - 을 포함할 수 있다. 도메인(101) 등의 도메인의 무결성이 신뢰의 기초(103)에 입각한 신뢰 사슬(chain of trust)에 의해 입증될 수 있다. 예를 들어, 도메인(101)의 적어도 하나의 구성요소의 측정 - 이 측정이 신뢰의 기초(103)에 의해 발생될 수 있음 - 을 기준 무결성 메트릭 - 신뢰의 기초(103)에 저장되어 있을 수 있고 도메인의 무결성을 검증하기 위해 신뢰의 기초에 의해 사용될 수 있음 - 과 비교함으로써 도메인(101)의 무결성이 입증될 수 있다. 다른 대안으로서, 기준 무결성 메트릭이 원격 소유자에 의해 저장될 수 있고, 이 측정이 기준 무결성 메트릭과의 비교를 위해 원격 소유자에게 전송될 수 있다. 이 측정이 기준 무결성 메트릭과 일치하는 경우 도메인의 무결성이 검증될 수 있다. 한 예시적인 실시예에서, 이 측정은 구성요소에 대해 계산된 해시를 포함할 수 있고, 기준 무결성 메트릭은 구성요소에 대해 이전에 계산된 해시 - 기준 무결성 메트릭의 신뢰성(authenticity)의 표시를 제공하는 디지털 인증서가 첨부되어 있음 - 를 포함할 수 있다. 기준 무결성 메트릭이, 장치의 제조 시에 또는그의 소유자에게로의 배달 시에, 장치에 사전 프로비저닝(pre-provision)될 수 있다. 기준 무결성 메트릭이 또한, 장치의 제조/그의 소유자에게로의 공급 후에, 원격 소스로부터 통신 채널(예컨대, 공중파 무선 통신 채널)을 통해 전달되고, 전달 후에 장치에 프로비저닝될 수 있다. 기준 무결성 메트릭이 인증서에 포함되어 장치로 전달될 수 있다. 이러한 인증서는, 장치로의 전달 후에, 신뢰성 있는 제3자에 의해 검증될 수 있다.

본 명세서에 개시된 시스템 및 그의 다양한 방법 및 수단이 아주 다양한 컴퓨팅 및 통신 상황에서 구현될 수 있다. 그에 따라, 시스템의 장치 - 도 1의 예시적인 장치(100, 110, 120) 등 - 가 다양한 형태를 취할 수 있다. 제한이 아닌 일례로서, 시스템의 장치는 WTRU(wireless transmit/receive unit), UE(user equipment), 이동국, 고정식 또는 이동식 가입자 장치, 페이저, 휴대 전화, PDA(personal digital assistant), 컴퓨터, M2M(machine-to-machine) 장치, SIM 카드, UICC(Universal Integrated Circuit Card), 스마트 카드, 위치 추적(geo-tracking) 장치, 센서-네트워크 노드, 계량 장치(수도, 가스 또는 전기 계량기 등), 또는 무선 또는 유선 환경에서 동작할 수 있는 임의의 다른 유형의 컴퓨팅 또는 통신 장치를 포함할 수 있다. 이하의 도면 및 설명은 WTRU(wireless transmit/receive unit)에서의 본 개시 내용의 시스템 및 방법의 다수의 부가의 예시적인 실시예를 제공한다. 그렇지만, 이들 실시예가 단지 예시적인 것이며 본 명세서에 개시된 시스템 및 방법이 이들 실시예로 결코 제한되지 않는다는 것을 잘 알 것이다. 오히려, 전술한 바와 같이, 본 명세서에 기술된 시스템 및 방법이 아주 다양한 컴퓨팅 및 통신 환경에서 이용될 수 있다.

도 2는 본 명세서에 기술된 시스템 및 방법이 구현될 수 있는 WTRU의 일 실시예를 나타낸 도면이다. 도시된 바와 같이, WTRU는 UE(200) 등의 모바일 장치를 포함할 수 있다. UE(200)는 ME(Mobile Equipment)(210) 및 THSM(Trusted Hardware Subscription Module)(220)를 포함할 수 있다. 그에 부가하여, THSM(220)은 THSM 장치 제조업체(Device Manufacturer; DM) 도메인(221), THSM 장치 소유자(Device Owner; DO) 도메인(222), THSM 장치 사용자(Device User; DU 또는 U) 도메인(223), 시스템 전체 도메인 관리자(System-Wide Domain Manager; SDM)(230), 도메인간 정책 관리자(Inter Domain Policy Manager)(240) 및 하나 이상의 원격 소유자(Remote Owner; RO) 도메인[RO의 도메인 A(224), RO의 도메인 B(225) 및 RO의 Domain C(226) 등]을 더 포함할 수 있다. 게다가, UE(200)는 다음과 같은 비예시된 구성요소인 프로세서, 수신기, 송신기 및 안테나를 포함할 수 있다. 본 명세서에 기술된 예시적인 구현예는 도 2와 관련하여 기술된 것과 같은 구성요소를 참조할 수 있다.

THSM은, 통상적으로 SIM 기능, USIM 기능, ISIM 기능, 및 액세스 네트워크 가입에 의해 수행되는 것을 비롯한, 신뢰성 있는 가입 관리 기능을 제공하는 하드웨어-기반 모듈일 수 있다. THSM은 하드웨어-보호 모듈(hardware-protected module)일 수 있다. THSM은 관련 보안 기능으로 특수 설계되어 있는 하드웨어를 포함할 수 있다. THSM은 내부적으로 다수의 분리된 도메인을 지원할 수 있다. 도메인이 원격 소유자(Remote Owner; RO)라고 하는 다른 소유자에 의해 청구되거나 소유될 수 있다. RO에 의해 청구된 도메인은 각자의 RO에 대해 프록시로서 역할할 수 있다.

도메인들 중 하나 이상의 도메인이 TSIM(Trusted Subscription Identity Management) 등의 가입 관리 기능을 수행할 수 있다. TSIM 기능을 갖는 다수의 도메인이 하나의 THSM 상에 존재할 수 있기 때문에, THSM이 다수의 RO에 대한 가입 관리를 지원할 수 있다. TSIM 지원 도메인(TSIM-capable domain)의 관리의 어떤 측면이 시스템 전체 도메인 관리자(SDM)라고 하는 하나의 관리 기능에 의해 수행될 수 있다. 다른 측면은 개개의 도메인 내에서 및 개개의 도메인 상에서 개별적으로 관리될 수 있다.

UMTS(Universal Mobile Telecommunication System) 환경과 관련하여 기술되어 있지만, 당업자라면 본 명세서에 기술된 방법 및 장치가 본 출원의 범위를 벗어나지 않고 다른 환경에 적용가능하다는 것을 잘 알 수 있다. TSIM은 "가입 응용 프로그램"의 대표적인 일례일 수 있다. 예를 들어, 3G UMTS 네트워크에서 동작하는 WTRU에서 구현되는 경우, TSIM은, 그의 기능의 일부로서, UMTS 인증 및 키 합의(authentication and key agreement; AKA) 기능을 비롯한 가입 관련 기능들 전부를 포함할 수 있다. TSIM이 UICC 등의 특정의 하드웨어에 구속되어 있지 않을 수 있다. 이것은 USIM에만 존재할 수 있는 USIM와 대조적이다. 그 대신에, 본 명세서에 기술되어 있는 바와 같이, TSIM이 THSM(Trusted Hardware Subscription Module)에 구현될 수 있다. 당업자라면 또한 본 명세서에 기술되어 있는 THSM의 기능이, 본 출원의 범위를 벗어나지 않고, UICC 또는 유사한 스마트 카드 - ETSI(European Telecommunications Standards Institute) UICC 요구사항에 부합하는 UICC 또는 글로벌 플랫폼(Global Platform) 규격에 부합하는 스마트 카드 등 - 에 포함될 수 있다는 것을 잘 알 것이다.

WTRU는 THSM 및 ME(mobile equipment)를 포함할 수 있다. ME는 모뎀, 무선기, 전원 공급 장치, 및 WTRU에서 통상적으로 발견되는 다양한 다른 특징부를 포함할 수 있다. THSM은 별도의 하드웨어-기반 모듈을 포함할 수 있다. THSM은 WTRU 상에 내장되어 있을 수 있거나, 독립적인 것일 수 있다. THSM은, WTRU 상에 내장되어 있더라도, 논리적으로 ME로부터 분리되어 있을 수 있다. THSM은 하나 이상의 도메인 - 각각이 특정의 도메인 소유자에 의해 소유되고, 안전하고 신뢰성 있는 서비스 및 응용 프로그램을 제공하기 위해 소유자의 이익을 위해 운영됨 - 을 포함할 수 있다. 따라서, 예를 들어, DM의 도메인은 TD_DM으로 표시될 수 있고, DO의 도메인은 TD_DO로 표시될 수 있다. THSM 내의 도메인은 ME에서 수행하기에 안전하지 않거나 편리하지 않을지도 모르는 보안에 민감한 기능 및 응용 프로그램을 수행할 수 있다.

어떤 도메인은 하나 이상의 서비스 공급자에 의해 소유되고 관리될 수 있다. 예를 들어, MNO(mobile network operator); 기타 통신 네트워크 운영자 - WLAN(wireless local area network) 공급자, 또는 WiMax 공급자 -; 응용 프로그램 서비스 공급자 - 모바일 결제, 모바일 티켓팅, DRM(digital rights management), 모바일 TV, 또는 위치-기반 서비스; 또는 IMS(IP Multimedia Core Network Subsystem) 서비스 공급자에 의해 소유되고 관리될 수 있다. 가입 관리가 서비스 공급자 소유의 도메인에 의해 지원될 수 있다. 간단함을 위해, THSM 도메인 상에 구현된 가입 관리 기능이 이후부터 TSIM 기능으로 언급될 수 있다. TSIM 기능에 대한 지원은 도메인별로 달라질 수 있다. 예를 들어, 지원되는 TSIM 기능이 이동 단말기의 UICC 상의 USIM 및 ISIM 응용 프로그램에 의해 제공되는 것과 유사한 기능을 포함할 수 있다. THSM은, UICC와 마찬가지로, TSIM에 의해 제공되는 것에 부가하여, 기능, 응용 프로그램 및 데이터를 포함할 수 있다.

TSIM은 소프트웨어 단위(software unit) 또는 가상 응용 프로그램일 수 있다. TSIM은 처음에 특정의 네트워크 통신사업자 또는 PLMN(Public Land Mobile Network)과 연관된 크리텐셜을 가지고 있지 않을 수 있다. TSIM은 UMTS 셀룰러 액세스 네트워크에 대한 가입 크리텐셜/응용 프로그램의 관리를 말하는 것일 수 있다. 예를 들어, TSIM은 UMTS 인증 키 등의 강력한 비밀(Ki)의 관리를 포함할 수 있다. M2M과 관련하여, TSIM은 또한 MCIM(M2M Connectivity Identity Management)을 포함할 수 있다.

THSM은 TPM(trusted platform module) 또는 MTM(mobile trusted module)을 가지는 컴퓨팅 장치에서 발견될 수 있는 RTM(root of trust of measurement)과 유사한 CRTM[Core Root of Trust (RoT) of Measurement] 유닛을 포함할 수 있다. THSM의 CRTM은, 예를 들어, THSM의 부트 시에 THSM 부트 코드의 무결성을 측정할 수 있다. 무결성 메트릭이 확장 연산(Extend operation)을 통해 - 예를 들어, THSM의 부트 코드, BIOS, 및 선택적으로 제조업체의 THSM 특성(버전 번호, 소프트웨어 구성, 또는 배포판 번호 등)에 암호 다이제스트 값 연산(cryptographic digest value operation)을 적용함으로써 - 계산될 수 있다. 예를 들어, SHA-X 등의 어떤 버전의 암호 해시 알고리즘을 사용하여 무결성 메트릭이 계산될 수 있다.

THSM은 무결성 메트릭을 보호 저장소(protected storage)에 저장하도록 구성되는, TPM 또는 MTM에서 발견되는 RTS(root of trust for storage)와 유사한 CRTS(core RoT of Storage) 유닛을 포함할 수 있다. THSM은 또한 THSM의 무결성 측정을 외부 챌린저(external challenger)에게 보고하도록 구성되는, TPM 또는 MTM에서 발견되는 RTR(root of trust for reporting)와 유사한 CRTR(core RoT of Reporting) 유닛을 포함할 수 있다.

따라서, THSM은 신뢰 측정, 저장 및 보고와 관련하여 TPM 또는 MTM의 기능과 유사한 기능을 효과적으로 제공할 수 있다. THSM은 또한 다수의 신뢰성 있는 이해관계자 엔진(stakeholder engine)을 실현하는 기능을 포함할 수 있다. 게다가, THSM은 각자의 다중-이해관계자 신뢰 서브시스템을 실현하도록 구성될 수 있다. 따라서, THSM은 TCG MPWG(Mobile Phone Working Group) 규격에 의해 정의된 신뢰성 있는 이동 전화와 유사할 수 있다.

THSM은, 예를 들어, 본 명세서에 기술되어 있는 코어 RoT 기능을 사용하여 다수의 내부 "이해관계자 도메인"을 구축하도록 구성될 수 있다. 이해관계자는 THSM DM(Device Manufacturer), THSM DO(Device Owner), 또는 THSM DU(Device User)일 수 있다. DU는 DO와 동일할 수 있거나, DO와 다를 수 있다. THSM당 2개 이상의 DU가 있을 수 있다. 이해관계자는 또한 DO가 특정하여 임대하거나 소유하고 있는 도메인의 다른 원격 소유자(RO)일 수 있다. 예를 들어, MNO, IMS 서비스 공급자, 비3GPP 액세스 네트워크 통신사업자, 또는 부가 가치 응용 프로그램 서비스 공급자 등의 3GPP(third generation partnership project) PLMN 통신 사업자가 이해관계자일 수 있다.

어떤 도메인은 필수적일 수 있고, 이경우에 이들 도메인은 THSM의 제조 시에 사전 구성될 수 있다. 예를 들어, DM의 도메인이 필수적일 수 있고, 사전-구성된 파일에 따라 부트 시에 구축되거나 로드될 수 있다. DO의 도메인이 또한 필수적일 수 있고, 사전-프로비저닝된 구성에 따라 구축될 수 있다. 다른 대안으로서, 도메인이 다운로드되는 구성 파일에 따라 구축될 수 있다.

DM의 도메인 이외의 도메인은, 도메인의 소유자에 의해 "청구" 및 "소유"될 수 있기 전에, RTO(Remote Take-Ownership) 프로세스를 거칠 수 있다. 특정의 도메인이 RTO 프로세스를 수행하기 전에, 비지정된 소유자에 대한 "원시" 도메인이 존재할 수 있다. 이 경우에, 도메인에 대해 청구된 특정의 소유권이 없다.

THSM 상의 도메인은 THSM-ME 인터페이스를 통해 ME와 통신하고 ME와 정보를 교환할 수 있다. 예를 들어, 도메인은 부트업 또는 RTO 프로세스 동안 ME와 통신할 수 있다. THSM-ME 인터페이스를 통해 교환되는 데이터의 보호가 필요할 수 있다.

THSM-ME 인터페이스를 통한 모든 통신의 무결성 보호가 필요할 수 있다. 예를 들어, 무결성 보호는 사전-프로비저닝된 임시 키 또는 인증된 키 교환 메커니즘을 사용하여 교환되는 키 등의 암호 키를 사용할 수 있다. 암호 키는 대칭(Ktemp_I 등) 또는 비대칭(무결성을 위해 THSM에 의해 사용되는 공개 또는 비밀 키에 대한 Kpub/priv_THSM_temp_I 및 무결성을 위해 ME에 의해 사용되는 공개 또는 비밀 키에 대한 Kpub/priv_ME_temp_I 등)일 수 있다. 인터페이스의 보호를 위해 임시 키가 사용될 수 있다. 예를 들어, 임시 키가 유효 기간과 연관되어 있을 수 있거나, 1회 또는 소정의 횟수 사용될 수 있다.

THSM-ME 인터페이스를 통한 통신의 기밀성이 또한 암호적 수단을 사용하여 제공될 수 있다. 사전-프로비저닝된 임시 키 또는 인증된 키 교환 메커니즘을 사용하여 교환되는 키가 사용될 수 있다. 암호 키는 대칭(암호화를 위한 Ktemp_C 등) 또는 비대칭(암호화를 위해 THSM에 의해 사용되는 공개 또는 비밀 키에 대한 Kpub/priv_THSM_temp_C, 및 암호화를 위해 ME에 의해 사용되는 공개 또는 비밀 키에 대한 Kpub/priv_ME_temp_C 등)일 수 있다. 본 명세서에 기술되어 있는 RTO 방법 및 장치는 간단함을 위해 사전-프로비저닝된 대칭 임시 키의 사용을 참조하고 있다. 그렇지만, 당업자라면, 본 출원의 범위를 벗어나지 않고, 다른 키 구현이 사용될 수 있다는 것을 잘 알 것이다.

RO에서 THSM-ME 사이에서 평문으로(in the clear) 전달되는 메시지에 대한 재전송 공격(replay attack)의 방지가 제공될 수 있다. THSM-ME 인터페이스를 통해 전송되는 각각의 메시지가 넌스(nonce)의 사용에 의해 신선성 품질(freshness quality)을 가질 수 있다. 간단함을 위해, 본 명세서에 기술되어 있는 RTO 프로토콜은 ME-THSM 인터페이스를 거쳐 교환되는 모든 메시지의 재전송 방지 보호(anti-replay protection)를 포함할 수 있지만, 당업자라면 본 출원의 범위를 벗어나지 않고 다른 인터페이스 보호 구성이 사용될 수 있다는 것을 잘 알 것이다.

서명이 해시에 적용될 수 있다. 예를 들어, 해시가 SHA-X 알고리즘에 의해 생성될 수 있다. 신뢰성 있는 제3자가, 인증서(Cert_TSIM)를 사용하여, THSM과 연관되어 있는 비밀-공개 키 쌍(K_TSIM-Priv 및 K_TSIM-Pub 등)을 인증할 수 있다. 신뢰성 있는 제3자가 또한, 인증서(Cert_RO)를 사용하여, 네트워크와 연관되어 있는 다른 키 세트(K_RO-Priv 및 K_RO-Pub 등)를 인증할 수 있다. 이들 인증서는 문제의 도메인에 할당되어 있는 보호 저장소에 저장될 수 있다.

공개 키 K_{RO_Pub}는 RO로부터의 서명을 검증하기 위해 또는 RO로 전송되는 메시지를 암호화하기 위해 THSM 플랫폼, 특히 TSIM에 의해 사용될 수 있다. 비밀 키 K_RO-Priv는 서명을 위해 그리고 대응하는 공개 키를 사용하여 TSIM에 의해 암호화된 메시지를 복호화하기 위해 네트워크에 의해 사용될 수 있다. 공개-비밀 키 쌍 K_TSIM-Pub 및 K_TSIM-Priv는, TSIM 및 RO의 역할이 바뀌어 있는 것을 제외하고는, 유사한 기능을 포함할 수 있다. 다른 대안으로서, RO 및 TSIM 둘 다에서, 암호화 및 서명을 위한 별도의 키 쌍이 있을 수 있다.

키 쌍 K_{RO_Priv} 및 K_{RO_Pub}와 K_TSIM-Priv 및 K_TSIM-Pub는 소유자, 사용자 또는 둘 다에 의해 선택된 특정의 네트워크 서비스에 의존할 수 있다. RO 등의 각각의 서비스 공급자는 그 공급자와 연관되어 있는 THSM 상의 각각의 도메인에 대한 그 자신의 인증된 공개-비밀 키 쌍을 가질 수 있다. 선택된 서비스는 어느 키 쌍 세트가 사용되는지를 결정할 수 있다. 예를 들어, 선택된 서비스 공급자 및 THSM 상의 연관된 도메인에 의해 공개-비밀 키 쌍 세트가 결정될 수 있다. 사용되는 키 쌍의 협상이 없을 수 있다. 공개 또는 비밀 키 쌍이 서비스 공급자에 의해 결정될 수 있고, THSM 서브시스템 또는 도메인와 밀접하게 연관되어 있을 수 있다.

THSM TD_DO는 "SDM"(System-wide Domain Manager)을 구성할 수 있다. SDM은 "SDP"(System-wide Domain Policy)를 포함하는 사전-구성된 파일을 보호 저장할 수 있다. SDM은 SDP에 따라 THSM에 대한 RO의 도메인을 구축하거나 로드할 수 있다. SDM은 DO의 도메인의 원시 구성에 포함될 수 있다. SDM은 어느 다른 도메인이 어느 순서로 구축되어야 하는지를 결정하기 위해 사전-구성된 SDP를 사용할 수 있다.

SDM은, RO 도메인을 위해 그리고 RO 도메인에 의해 요청될 때, TPES(THSM Platform Environment Summary) 및 TPIA(THSM Platform Integrity Attestation)을 준비하여 제공할 수 있다. TPES는 THSM의 가장 최근의 "환경"에 관한 요약 정보를 나타낼 수 있다. 이러한 정보는 요청측 도메인과 통신하고 기능 또는 자원을 공유할 수 있는 THSM 및 THSM 상의 임의의 남아 있는 자원 상의, 기밀성 및 분리에 관한 각자의 도메인 정책에 의해 조절되거나 허용되는, 도메인의 수 및 요약 속성을 포함할 수 있다. TPIA는 THSM의 도메인들 중 하나 이상의 도메인 상의 무결성 증명의 집합체를 포함할 수 있다. TPIA는 또한 상기 도메인을 지원하는 플랫폼에 대한 무결성 증명을 포함할 수 있다. TPIA는 관심의 도메인 및 그 도메인을 지원하는 플랫폼의 신뢰 상태를, THSM 상의 원시 도메인(pristine domain)에 대한 RTO 프로세스를 수행하는 데 관심이 있는 RO 등의 외부 검증자에게 증명하는 데 사용될 수 있다. RO, 또는 RO의 도메인(TD_RO)은 TPIA에 대한 SDM을 요청할 수 있다. SDM은 SDP에 따라 요청을 수락하거나 거부할 수 있다.

SDM은 또한 구축되어야만 하는 다른 도메인 및 어느 순서로 구축되어야 하는지를 상호작용적으로 식별하기 위해 THSM의 서비스 요원 등의 실제로 존재하는 장치 소유자(Physically Present Device Owner)와 상호작용할 수 있다. 게다가, SDM은 또한 구축될 도메인 및 구축 순서에 대한 입력을 제공하기 위해 사용자의 도메인에 THSM의 실제로 존재하는 사용자와 상호작용하라고 요청할 수 있다. 이 정보는 도메인 구축 프로세스에서 입력으로서 사용될 수 있다.

THSM은, RO의 도메인에 대해 RTO 프로세스를 수행할 때, 원격 소유권 취득 프로토콜의 완료 이전에 4개의 상이한 시스템 상태를 달성하도록 구성될 수 있다. THSM Pre_Boot 시스템 상태는 THSM이 "전원이 켜지지" 않았다는 것을 나타낼 수 있다. THSM_TD_DM_LOAD_COMPLETE 시스템 상태는 THSM의 전원 켜짐 이후의 첫번째 단계로서 THSM 상의 DM의 도메인이 구축되거나 로드되었다는 것을 나타낼 수 있다. THSM_TD_DO_LOAD_COMPLETE 시스템 상태는 DO의 도메인(TD_DO)이 마지막 이용가능 구성(last-configuration-available)으로 구축되거나 로드되었다는 것을 나타낼 수 있다. DO의 도메인이 자체적으로 RTO 프로세스를 결코 수행하지 않은 경우, "마지막 이용가능 구성"이 "원시" 구성일 수 있거나, 그렇지 않은 경우, "RTO후(post-RTO)" 구성일 수 있다. DM의 도메인이 DO의 도메인을 구축하거나 로드할 수 있다. DO의 도메인이 적어도 하나의 RTO 프로세스를 수행하기 전에, DO의 도메인이 "원시" 상태에 있을 수 있고, 임의의 특정의 DO에 의해 청구되거나 소유되지 않을 수 있다. "원시" 도메인은 "쉘(shell)"을 포함할 수 있다. DO의 도메인이 처음으로 구축되거나 로드될 때, "마지막 이용가능 구성"[이후부터 마지막 구성(Last-Configuration)이라고 함]이 사전-구성된 파일로부터 나온다. 다른 대안으로서, "마지막 구성"이 RO의 도메인에 대한 RTO 프로세스로 인한 것인 경우, THSM 상의 특정의 도메인이 적어도 한번 원격 소유권 취득 프로토콜을 수행했을 수 있고, 원격 소유자는 TSS_RO의 소유권을 취득했을 수 있다. 이것은 원격 소유권 취득 완료 시에 플랫폼 상에 구성된 신뢰 서브시스템을 나타낼 수 있다. 이 상태에 도달할 때 또는 이 상태에 도달하기 전에, 특정의 RO는 다른 작업을 수행하기 시작할 수 있다.

THSM_TD_RO_LOAD_COMPLETE 시스템 상태는 RO의 도메인(TD_RO)이 마지막 이용가능 구성으로 구축되거나 로드되었다는 것을 나타낼 수 있다. RO의 도메인이 자체적으로 RTO 프로세스를 결코 수행하지 않은 경우, "마지막 이용가능 구성"이 "원시" 구성일 수 있거나, 그렇지 않은 경우, "RTO후" 구성일 수 있다. DM의 도메인이 RO의 도메인을 구축하거나 로드할 수 있다. DO의 도메인이 적어도 하나의 RTO 프로세스를 수행하기 전에, DO의 도메인이 "원시" 상태에 있을 수 있고, 임의의 특정의 DO에 의해 청구되거나 소유되지 않을 수 있다. "원시" 도메인은 "쉘"을 포함할 수 있다. RO의 TD가 처음으로 구축되거나 로드될 때, 마지막 구성이 사전-구성된 파일로부터 나올 수 있다.

다른 대안으로서, 마지막 구성이 RO의 TD에 대한 RTO 프로세스로 인한 것인 경우, THSM 상의 특정의 TD가 적어도 한번 RTO 프로토콜을 수행했을 수 있고, RO는 TD_RO의 소유권을 취득했다. 이것은 RTO 완료 시에 플랫폼 상에 구성된 신뢰 서브시스템을 나타낸다. 이 상태에 도달할 때쯤, 특정의 RO는 다른 작업을 수행하기 시작할 수 있다. RO의 TD(TD_RO)가 MNO의 TD인 경우, 이 스테이지에 의해, MNO의 TD는 그 TD_RO 상에서 실현되는 궁극적인 TSIM(Trusted Subscription Identity Management) 기능을 제공할 수 있다.

다른 대안으로서, SDM(System-wide Domain Manager)은 DO의 TD보다는 DM의 TD에 구현될 수 있다. DO는, DM의 TD에 적당한 허가 데이터(authorization data)를 제공한 후에, THSM 상의 다양한 원격-소유자 TD를 생성하고 로드하며 다른 방식으로 관리하는 작업을 수행하기 위해 DL의 TD에 의해 제공된 SDM을 사용할 수 있다. 이 경우의 THSM 시스템 부트 시퀀스 및 RTO 프로세스 시퀀스의 상세가 본 명세서에 기술되어 있는 것과 상이할 수 있지만, 본 출원의 범위 내에 있다. 이것에 대한 부트업 및 RTO 프로세스는 물론 DO 또는 DO의 TD가 DM의 TD에 의해 제공된 SDM을 어떻게 사용할 수 있는지 - 예를 들어, 어떤 종류의 허가 데이터가 제공될 수 있는지(및 어떻게 제공될 수 있는지) - 에 대한 설명이 본 명세서에 기술되어 있는 것과 유사할 수 있다. 예를 들어, 스마트 카드로서 구현된 THSM은 글로벌 플랫폼(Global Platform) 등의 표준에 의해 규정된 카드 관리자(Card Manager) 기능을 지원하는 기능을 갖는 카드 관리자 - 카드 발급자를 위해 카드 상의 보안 도메인을 관리하는 책임을 지고 있음 - 를 포함할 수 있다. 카드 발급자는 DM과 유사할 수 있고, 카드 관리자는 SDM의 기능들 중 일부를 포함할 수 있다. 따라서, 카드 관리자는 DM의 도메인에 보유된 SDM과 유사할 수 있다.

제1 실시예에서, ME는 안전 부트(secure boot) 기능을 제공하도록 구성될 수 있고, THSM은 완전 MTM(full MTM) 기능을 제공하도록 구성될 수 있다. 전원이 켜질 때, ME는 안전하게 부트할 수 있다. 예를 들어, ME는 OMTP(open mobile terminal platform) 신뢰 실행 환경 TR0 규격 등에 따라 비TCG "안전" 부트를 수행할 수 있다. 부트 시에, THSM은, 예를 들어, 부트업에 의해, THSM DM의 도메인(TD_DM)을 먼저 구축할 수 있고, 이어서 "원시" THSM DO의 도메인(TD_DO)을 구축할 수 있다. DO 및 DU가 분리되어 있는 경우, THSM은 또한 THSM DU의 도메인도 구축할 수 있다.

THSM TD_DM은 THSM에 보호되어 있는 사전-구성된 파일로 먼저 구축될 수 있고 부트 시에 이용가능하게 될 수 있다. THSM TD_DO는 대체로 사전-구성된 파일로 구축될 수 있지만 RTO 프로세스를 사용해서도 구축될 수 있다. THSM TD_DO는 RTO 프로토콜을 수행할 수 있다. 이 프로토콜은 RO의 도메인(TD_RO)에 대한 RTO 프로토콜과 동일한 형태를 취할 수 있거나, 상이한 프로토콜일 수 있다. THSM TEDO가 RTO 프로토콜을 수행하지 않은 경우, 소유권을 취득하는 데 필요한 크리텐셜이 사전-구성되고 사전-프로비저닝된다. THSM TE_DO가 DO의 소유일 수 있다. DO가 실제 사람 사용자 또는 소유자, 기업 또는 그의 IT(Information Technology) 부서 등의 조직체, 또는 원격 네트워크 통신사업자(Network Operator, NO)일 수 있다.

THSM TD_U는 THSM TE_DO에 사전-프로비저닝되어 있는 사전-구성된 파일로 구축될 수 있다. THSM의 RO 도메인이 먼저 THSM DO의 SDP(system-wide domain policy)에 따라 "원시" 구성으로 구축될 수 있다. THSM의 RO 도메인이 RO에서의 RTO 프로세스를 수행할 수 있다. DO의 도메인의 SDM은 SDP에 따라 RO의 도메인에 대한 RTO 프로세스를 관리할 수 있다. THSM의 DO가 MNO이고 따라서 RO의 도메인이 MNO의 도메인인 경우, 이러한 MNO의 도메인이 또한 i) MNO의 도메인이 어떻게 MNO에 등록될 수 있는지; ii) 가입 크리텐셜[예컨대, USIM 또는 MCIM 비밀 키 Ki 및 IMSI(International Mobile Subscriber Identity) 등]이 어떻게 MNO의 모바일 네트워크로부터 THSM 상의 MNO의 도메인으로 롤오프되고 이어서 그곳에 프로비저닝될 수 있는지; 및 iii) 일단 다운로드된 가입 크리텐셜, 이러한 크리텐셜을 처리하거나 사용하는 기능, 또는 심지어 가입 관리 기능을 제공하는 도메인이 한 장치로부터 다른 장치로 마이그레이션될 수 있는지를 정의하는 프로토콜을 수행할 수 있다. 이러한 프로토콜은, 각각, i) 등록 프로토콜; ii) 크리텐셜 롤오프(credential roll-off) 프로토콜; 및 iii) 마이그레이션 프로토콜이라고 할 수 있다. THSM의 RO 도메인은, RTO가 완료된 후에, 그 자신의 구성을 증명하고 RO에 보고할 수 있다.

ME의 신뢰-구축 메커니즘이 전원 켜짐 시의 안전 부트 프로세스를 수행하는 것으로 제한될 수 있는 제1 실시예에서, ME 구성이 ME 또는 THSM에 의해 추가로 증명가능하지 않을 수 있다. 다른 대안으로서, ME는 자체-무결성 검사(self-integrity check)를 수행하고, 안전 부트를 완료할 때 무결성 값(integrity value, IV)을 생성할 수 있다. ME는 OTA(over the air) 방법을 사용하여 UMTS 보안 모드 특징 등의 보안 모드 특징에 따라 기밀성 및 무결성 보호를 위한 엔진 등의 소프트웨어를 설치할 수 있다. 선택적으로, RO의 도메인의 소유권이 RO에서의 RTO 프로세스를 통해 취득될 때, RO는, RTO 프로세스가 완료될 수 있게 해주기 위해, 그가 받을 수 있는 THSM의 조건에 관한 그 자신의 정책을 다운로드하거나 다른 방식으로 가져오기하고 이어서 확인할 수 있다. RO가 전체 THSM의 조건, THSM의 다른 도메인의 구축 구조의 조건, 또는 둘 다에 합의할 때 RO는 THSM 플랫폼 상에 그 자체에 대한 도메인을 설치하는 것을 "게이트-키핑"하도록 구성될 수 있다. 따라서, RTO 프로세스의 일부로서, RO는, DO의 조건 또는 "도메인 구축 계획"을 식별하기 위해 그리고 이러한 조건이 RO에 허용가능한 경우에만 RTO 프로세스가 완료될 수 있게 해주기 위해, DO의 도메인의 SDM과 어떤 정보를 교환할 수 있다. RO 도메인은 또한 권한을 가지고 있을 수 있고, 처음에 THSM 상에 RTO-완료된 RO의 도메인을 구축하기로 합의한 후에 THSM의 조건 또는 도메인 구축 계획의 임의의 변경으로 업데이트되거나 그 변경을 통지받을 수 있게 해주기 위해 이러한 권한을 시행하는 기능을 수행하도록 구성될 수 있다. RO의 DP(domain-specific policy)는 RO의 도메인이 통지받을 필요가 있을 수 있는 변경의 유형을 지정할 수 있다.

SDM은 의도된 RO와 연관되어 있는 RO 도메인에 대해 RTO 프로세스를 개시할 수 있다. 이것은 RO의 도메인이 "원시" "미청구" 상태에 있을 때 일어날 것이다. 예를 들어, RO의 도메인은 DO의 도메인 및 DO에 의한 "도메인 X"(TD_X)라고 명명될 수 있다. 도메인이 아직 청구되지 않은 쉘(as-yet-unclaimed shell)에 또는 "원시" 조건에서 생성될 수 있다 이러한 경우에, SDM은 RTO 프로세스를 개시할 수 있고, 그에 의해 도메인 TD_X를 대신하여 의도된 RO와 접촉한다. RO가 이 도메인에 대한 RTO 프로세스를 수행했으면, SDM은 더 이상 이 동일한 도메인에 대한 다른 RTO 프로세스를 개시할 수 없다. 그 대신에, RO 자체가 이 특정의 도메인에 대해 다른 종류의 소유권 취득 프로세스를 개시할 수 있다. 이러한 소유권 취득 프로세스는, 전자가 (어쩌면 SDM 또는 DO의 도메인의 조정 하에서) 장치의 소유자/사용자 또는 장치 자체에 의해 로컬적으로 개시되기 보다는 원격 소유자에 의해 원격적으로 개시될 수 있다는 점에서, 지금까지 언급한 RTO 프로세스와 상이할 수 있다. DO는, RO의 도메인이 RTO 프로세스를 수행하였고 따라서 적당한 RO에 의해 "청구"되거나 "소유"된 후라도, 임의의 RO의 도메인을 삭제, 파기 또는 연결 해제시키는 권한을 보유하고 있을 수 있다. 그렇지만, DO는 일반적으로 RO의 도메인 내에 저장되어 있는 비밀을 알지 못하거나 RO의 도메인 내에서 수행되는 중간 계산 또는 기능을 알지 못할 수 있다.

SDM은, 원시 RO의 도메인에 대한 RTO 프로세스를 개시하기 전에, 도메인 구축을 위해 이용가능한 자원의 목록을 탐색할 수 있다. 이 목록은 DM의 도메인에 의해 유지될 수 있다. SDM은 또한 "원하는 도메인" 목록을 탐색할 수 있다. 원하는 도메인 목록은 DO의 도메인 TD_DO에 유지될 수 있다. SDM은 또한 SDP(System Domain Policy), 및 DM의 도메인에 질의될 수 있는 플랫폼 및 THSM의 기존의 도메인의 신뢰 상태를 비롯한 현재 상태를 탐색할 수 있다. 이 정보는 특정의 RO의 도메인에 대한 원하는 RTO 프로세스가 이용가능한 자원 및 정책 하에서 가능한지, 원하는 도메인 목록 하에서 요망되는지 및 THSM의 기존의 도메인의 상태(예를 들어, 신뢰 상태) 하에서 허용되는지를 결정하는 데 사용될 수 있다.

다른 대안으로서, 원격 소유자의 도메인(TD_RO)은 그 자체에 대한 RTO 프로세스를 시작하고 관리할 수 있다. TD_RO는 RTO 프로세서 이전에 미청구되고 "원시" 조건에 있을 수 있다. "원시" RO의 도메인 TD_RO는 부트업 시에 그의 의도된 RO와 접촉할 수 있게 해주고 RTO 프로세스를 자율적으로 시작할 수 있게 해주는 사전-구성된 기능을 포함할 수 있다. 선택적으로, TD_RO를 얻는 것이 THSM의 소유자 또는 사용자에게 요청하고 이어서 THSM의 소유자 또는 사용자로부터 RTO 프로세스를 개시하라는 "승낙"을 얻은 후에 RTO 프로세스가 시작될 수 있다. 생성되어 (대상) 원격 소유자 RO_target에 의해 소유되도록 의도되어 있지만 아직 RTO 프로세스를 통해 소유되지 않았고 여전히 "원시" 상태에 있는 도메인 TD는 이후부터 TD_RO _{_} _target*라고 할지도 모른다.

다른 대안에서, TD_RO는 특정의 RO에서 적어도 하나의 RTO 프로세스를 수행했을 수 있고, 현재 RO에 의해 "청구"되거나 "소유"되어 있을지도 모른다. DO 또는 그의 프록시(도메인 TD_DO 등)가 동일한 RO의 도메인에 대해 다른 RTO 프로세스를 시작할 수 있는지는 RO의 정책 및/또는 SDM의 정책에 의존할 수 있다. SDM은 RTO의 목적을 검사할 수 있고, 그의 정책 구조 내에서 허용된 목적 또는 활동에 기초하여, 이러한 새로운 RTO가 진행될 수 있게 해줄지를 결정할 수 있다. RO는, 원격 시그널링 또는 RO의 도메인(TD_RO)을 통해, 동일한 RO를 갖는 도메인에 대한 다른 RTO 프로세스를 개시할 수 있다. 이것은 RO가 TD_RO에서의 구성 파일, 보안 정책, 또는 실행가능 코드를 업데이트할 필요가 있을 때 일어날 수 있다. RO는 업데이트를 다운로드할 수 있다. 업데이트가 비RTO, OTA(over the air) 업데이트 프로세스를 통해 행해질 수 있다. 그렇지만, 어떤 경우에, RO 또는 TD_RO는 어떤 파일 또는 코드를 업데이트하기 위해 다른 RTO 프로세스를 사용할 수 있다.

"원시" TD_RO는, 자체적으로 RTO 프로세스를 개시할 때, DM의 도메인에 의해 유지되어 있을 수 있는, 도메인 구축에 이용가능한 자원의 목록을 탐색하기 위해 SDM에 의존할 필요가 있을 수 있다. TD_RO는 또한 DO의 도메인에 유지되어 있을 수 있는 "원하는 도메인" 목록, SDP(System Domain Policy), 및 DM의 도메인에 질의될 수 있는 THSM의 기존의 도메인의 신뢰 상태를 비롯한 현재 상태를 탐색하기 위해 SDM에 의존할 수 있다. 이 정보는 특정의 RO의 도메인에 대한 원하는 RTO 프로세스가 이용가능한 자원 및 정책 하에서 가능한지, 원하는 도메인 목록 하에서 요망되는지 및 THSM의 기존의 도메인의 상태 또는 신뢰 상태 하에서 허용되는지를 결정하는 데 사용될 수 있다.

SDM 정책은 DO에 대한 TO(take-ownership) 프로세스 동안 구성될 수 있다. 이 프로세스는 부트 프로세스 동안 시행되는 기존의 구성 구조를 통해 로컬적으로 행해질 수 있다. DO의 TO는 또한 원격적으로 행해질 수 있고, 이 프로세스는, 본 명세서에 언급되어 있는 바와 같이, 비장치 소유자인 원격 소유자에 대한 RTO 프로세스의 경우와 달리 DO의 도메인에 대한 TO 프로세스의 경우에 RTO를 차단할지 허용할지에 대한 SDM의 검사가 호출되지 않을 수 있다는 점에서, 장치 소유자의 도메인이 아닌 도메인의 소유권 취득에서 사용하도록 의도되어 있는 RTO 프로세스와 유사할 수 있다. SDP가 로컬적으로(DO가 실제로 존재하고 장치와 상호작용하고 있는 상태에서) 또는 원격으로 위치된 장치 소유자와의 원격 상호작용을 수반하는 방식으로 수행될 수 있는 DO 소유권 취득 프로세스 동안 설정될 수 있다. SDP의 구성요소는 모든 비DO 도메인에 공통인 허용된 활동 또는 목적의 목록이다. 이 목록은 또한 도메인의 소유권 취득이 허용되어 있지 않은 원격 소유자를 지정하는 부가의 항목을 포함할 수 있다.

제2 실시예에서, ME는 안전 부트 기능을 가질 수 있고, 그의 부트 코드의 일부에 대한 "안전 부트" 검사의 일부를 수행하기 위해 THSM에 의존할 수 있다. ME는 OMTP TR0 안전 부트 등의 비TCG 안전 부트를 수행할 수 있다. THSM은 THSM에 제공되는 물리적 보호를 "이용"하기 위해 ME의 무결성을 검사하는 데 사용될 수 있다. 예를 들어, ME는 원시 데이터를 THSM에 전송할 수 있고, THSM은 ME의 무결성을 검사할 수 있다. WTRU는, THSM이 ME에 대한 무결성 검사를 하도록, ME와 THSM 사이의 보안 채널, 및 코드 또는 데이터를 안전한 방식으로 THSM으로 전송하고 보안 채널 등을 통해 THSM과 안전하게 통신할 것으로 적어도 신뢰될 수 있는 ME의 "어느 정도 신뢰할 만한" 부분을 제공하는 메커니즘을 구현할 수 있다. THSM은 또한 ME를 대신하여 ME의 코드의 일부를 그 안에 저장하고 있을 수 있다. 이들 코드는 부트 프로세스 동안 ME에 로드될 수 있다. THSM은 ME의 무결성 검사를 수행하거나 ME에 대한 코드의 일부를 저장하고 로드하는 역할을 할 수 있는데, 그 이유는 자신과 ME 사이에서, THSM이 그의 하드웨어-기반 보호 메커니즘으로 인해 더 신뢰할 만한 환경일 수 있기 때문이다.

제3 실시예에서, THSM은 ME의 코드에 대한 안전 부트 또는 무결성 검사의 일부를 수행할 수 있다. 이것은 RO를 증명할 수 있다. ME는 하나의 신뢰성 있는 엔터티인 MTE(Mobile Trusted Environment)를 포함할 수 있다. MTE는 ME의 나머지 부분보다 더 신뢰성 있는 ME 내의 논리적으로 분리된 환경일 수 있다. MTE는 하드웨어-기반 RoT(root of trust) 등의 어떤 하드웨어-기반 보호 메커니즘을 이용할 수 있다. ME의 기본 코드(base code)가 로드된 후에, MTE가 로드될 수 있다. MTE는, 신뢰성 있는 서명 키의 사용 등 신뢰의 증거를 외부 검증자에게 제공할 수 있다는 의미에서, 신뢰성 있는 엔터티일 수 있다. MTE가 신뢰성 있는 엔터티이지만, 실제의 TPM과 연관되어 있는 측정 프로그램 코드인 측정에 대한 코어 RoT(core root of trust)를 갖고 있지 않을지도 모른다. 전력을 공급받는 장치인 ME가 THSM이 동작할 수 있는 "플랫폼"을 제공하는 한, ME는 본 명세서에서 ME 플랫폼이라고 할 수 있다. MTE는 ME 플랫폼의 무결성의 증거를 수집하고, 적어도 MTE 내에서 보호되는 서명 키의 사용에 의해 제공되는 무결성 보호 하에서, 증거를 부트후 SDM(post-boot SDM) 등의 THSM 내의 신뢰성 있는 엔터티에게 전달하도록 구성될 수 있다. THSM이 TCG TPM 또는 MTM과 같은 무결성 측정 및 검증 기능을 구현하기 때문에, THSM은 또한 "확장" 연산을 수행하기 위해 TCG TPM 또는 MTM의 기능을 구현할 수 있고, 그에 의해 PCR(Platform Configuration Register)의 새로운 값을 계산하기 위해 현재 소프트웨어의 측정이 소프트웨어의 로딩의 과거 상태를 나타내는 PCR의 현재 값과 결합된다. THSM은 또한 다이제스트 값(소프트웨어 구성요소의 무결성의 원시 측정 값임) 또는 PCR의 값을, THSM을 위해 ME 플랫폼의 신뢰성을 증명하는 데 사용될 수 있는 다른 무결성 데이터로 변환하는 메커니즘을 구현할 수 있다. 간단함을 위해, 수집된 ME 플랫폼 무결성의 데이터가 이후부터 MPID(ME Platform Integrity Data)로 표시될 수 있다. THSM은 ME 또는 MTE에 대한 도메인을 유지하지 않을 수 있다. THSM은 사전-구성된 파일로부터 또는 DM과의 실시간 접촉에 의해, 계산된 다이제스트를 검사하는 데 대조되는 인증된 메트릭을 획득할 수 있다. 일치하는 것으로 결정되기만 하면, ME의 증명이 뒤따를 수 있다. MTE는 또한 모델 번호, 어떤 종류의 서비스를 누구를 위해 수행하기로 되어 있는지 등의 ME의 "환경"을 나타내는 데이터를 수집할 수 있다. 간단함을 위해, ME의 이러한 환경 설명은 이후부터 MPES(ME Platform Environment Survey)로 표시될 수 있다. THSM DO의 RO는 그 자신의 도메인은 물론 ME 플랫폼 둘 다의 무결성을 증명할 수 있다. 이 증명은, PCT 특허 출원 WO 2009/092115(PCT/US2009/031603)에 언급된 바와 같이, M2M과 관련한 TRE(Trusted Environment)의 M2M2 유효성 검사 기능과 유사할 수 있다. ME는 계속하여, 자체적으로 또는 THSM으로부터 요청 시에, 그의 변하는 상태를 THSM에 보고할 수 있다.

제4 실시예에서, ME 및 THSM 둘 다는 완전 MTM 기능을 수행하도록 구성될 수 있다. ME 또는 그의 도메인의 신뢰성이 ME에 의해 또는 도메인에 의해 직접 증명될 수 있다. ME의 RO 도메인은, 계속적으로 또는 요청에 따라, 그의 상태를 RO에 보고할 수 있다. THSM의 RO 도메인도 이와 유사하게 기능할 수 있다. ME의 RO 도메인 및 THSM의 RO 도메인에 의한 보고는 동기화될 수 있고, 또한 서로에 연계되어 있을 수 있다. 이 보고는 또한 프로토콜 흐름의 공통 세션을 사용하여 행해질 수 있다.

이 실시예에서, ME는 본 명세서에 기술되어 있는 바와 같이 THSM의 몇가지 기능을 수행하도록 구성될 수 있다. ME는 그 자신의 하나 이상의 도메인 - 각각이 특정의 소유자에 대한 것임 - 을 포함할 수 있다. 이들 도메인은 THSM에 따른 신뢰성 있는 엔터티의 특성을 포함할 수 있다. 이러한 도메인은 DM(device manufacturer) 도메인 및 U(user) 도메인을 포함할 수 있다. 이들 도메인은 THSM과 유사한 방식으로 사전 구성될 수 있다. ME 상의 도메인을 THSM 상의 도메인과 구별하기 위해, 문자 ME에 도메인 자체를 나타내는 것이 첨자로 붙어 있을 수 있다. 따라서, DM에 대한 도메인은 ME_DM으로 표시될 수 있다. THSM 상의 장치 소유자(DO) 도메인은, SDM 상에 존재하는 SDP(System-Wide Domain Policy)에 대한 적합성을 보증하기 위해, ME측 상의 도메인을 모니터링할 수 있다. ME 내의 각각의 도메인의 생성에 의해, SDM과의 통신은 THSM DO가 각각의 새로운 도메인 구성을 인식하게 해줄 수 있다.

ME는 THSM에서의 SDM과 유사한 방식으로 기능할 수 있는 플랫폼 도메인 관리자(platform domain manager)(ME_PDM)라고 할 수 있는 도메인 관리자를 포함할 수 있다. ME_PDM은 ME_DM에 존재할 수 있고 처음에는 DM에 의해 정의된 사전 구성을 가질 수 있다. 이러한 초기 구성은 그의 목적 및 기능이 THSH 상의 TD_DM의 초기의 사전 구성된 정의의 목적 및 기능과 유사할 수 있다. ME_DM 설정이 TD_DO가 THSM에 인스턴스화된 후에 행해지도록 타이밍 조절될 수 있다. SDM은, ME_DM에 대한 설정이 완료되었다고 통지를 받을 때, 시스템 전체 제약조건에 따라, SDP로부터 기인하는 또는 SDP를 반영하는 정책 제한을 부과할 수 있다. SDM은 다수의 원격 소유자 및 THSM 상의 그의 도메인의 목록을 유지할 수 있다. 도메인이 생성되고 목록에 있는 소유자들 중 하나의 소유자에 속하는 ME 상에 유지되는 경우, SDM은 ME 상의 이들 도메인의 생성 및 관리에 대해 어떤 제어를 할 수 있다.

이 실시예에서, ME는 완전 MTM 기능을 가질 수 있다. 따라서, ME는 CRTM(core root of trust for measurement), CRTR(core root of trust for reporting), 및 CRTS(core root of trust for storage)를 포함할 수 있다. THSM 상에서, 도메인 가입 기능은 TSIM 기능에 의해 관리될 수 있다. 2개의 도메인 - 예컨대, 하나의 도메인은 THSM 상에 있고 다른 도메인은 ME 상에 있음 - 이 동일한 RO에 대한 것인 경우, THSM 상의 도메인은 아주 높은 레벨의 보안 및/또는 신뢰를 필요로 하는 RO에 대한 기능 또는 서비스 - 그 원격 소유자에 대한 가입 기능 및 그의 관리 등 - 를 위해 사용될 수 있는 반면, ME 상의 도메인은 어떤 레벨의 보안 또는 신뢰를 여전히 필요로 할 수 있지만 THSM 상의 도메인에 기대되는 기능 및 서비스에 필요한 바로 그 레벨의 보안 또는 신뢰를 필요로 하는 것은 아닌 동일한 RO에 대한 기능 또는 서비스를 위해 사용될 수 있다. 사전-구성된 파일로부터 구축되지 않는 도메인은 RTO(remote take ownership) 프로세스를 통해 구성될 수 있다. 통상적인 RO(remote owner)에 대해, ME에 대한 RTO는 THSM에 대한 RTO와 유사할 수 있다.

ME 상의 도메인은 원격 소유자에 대한 가입 관리를 위해 사용되도록 의도되어 있지 않을 수 있다. 그 대신에, 이들은 사용자, 소유자 원격 소유자, 또는 이들의 임의의 조합을 위해 계산 및 자원을 많이 사용하는 작업을 수행하는 데 사용되도록 의도되어 있을 수 있다. 예를 들어, 이들 도메인은 THSM 상의 비교적 제한된 자원에 대해 예측가능하지 않을 수 있는 작업을 수행할 수 있다. ME 상의 도메인은 또한 , 일단 생성된 다음에 명시적으로 삭제될 때까지 ME 내에 존재하는 것이 아니라, 이들 도메인이, 가상화와 유사하게, 부트 시에 또는 심지어 런타임 세션 시에 생성되고 일시적인 세션-기반 방식으로 그 특정의 목적을 위해 사용될 수 있다는 점에서, 더욱 "순간적" 또는 "일시적"일 수 있다. ME 상의 도메인의 원격 소유자는 다른 원격 소유자에 의해 소유된 ME 상의 다른 도메인 또는 THSM 상의 이러한 다른 도메인의 자원의 할당 및 그의 목적에 대한 증명된 조사를 요청하고 획득하는 것과 관련하여 동일한 레벨의 특권을 갖지 않을 수 있다.

모바일 신뢰 플랫폼의 장치 소유자가 특정의 PLMN - MNO 원격 소유자라고도 함 - 에 의해 사전 할당되고 초기화되지 않은 "비어 있는" WTRU를 구매하여 제한 없이 모바일 네트워크 통신 사업자를 마음대로 선택할 수 있게 해주는 방법을 제공하는 것이 유리하다. 이 방법은 UMTS 장치(UE) 등의 WTRU의 소유권 취득 프로세스 - RTO 프로세스 등 - 를 수행하는 단계를 포함할 수 있고, 여기서 원격 소유자는 PLMN 통신 사업자 또는 가입 응용 프로그램이 의도되어 있는 다른 유사한 통신 사업자이고, THSM 내부에 있는 도메인이고 올바른 RO에 의해 청구될 수 있는 RO의 도메인 등의 서브시스템을 설정(setup), 커스터마이즈(customize) 및 종료(finalize)한다.

앞서 언급한 바와 같이, THSM(Trusted Hardware Subscription Module)은 PLMN 통신사업자에 대한 가입 응용 프로그램의 기능을 포함하는 위조 방지 하드웨어 구성요소 모듈로서 구축될 수 있거나 그 안에 위조 방지 하드웨어 구성요소 모듈 및 ISIM(IMS Subscription Identity Module) 등의 다른 부가 가치 서비스를 포함할 수 있다. THSM은 WTRU로부터 제거가능하거나 제거가능하지 않을 수 있다. 향상된 버전의 UICC 또는 글로벌 플랫폼 표준에 부합하는 스마트 카드가 이러한 THSM의 일 실시예일 수 있다.

소유권 취득 동작은 통신 사업자 또는 PLMN과 WTRU 사이에 기본적인 "신뢰" 관계를 구축한다. 이 절차는 범용의 "신뢰성 있는" 소프트웨어 구성을 갖는 "원시" 엔진을 포함하는 "비어 있는 신뢰성 있는" TSIM을 설치하고 인스턴스화할 수 있다. 플랫폼이 그의 "원시" 구성 및 보안 속성의 증거를 제공할 수 있는 경우, 이 서브시스템이 원격 소유자에 의해 "인증"될 수 있다. 도 3 및 도 3a는 이 프로세스의 일례를 나타낸 것이며, 이는 본 명세서에 기술된 제1 실시예와 구체적으로 관련되어 있다. 원격 소유자는 사용자에게 요청된 서비스를 제공하고, 적절한 보안 정책을 수립하며, 서비스와 부합하는 장치 구성을 시행하는 모바일 네트워크일 수 있다. 이 프로토콜에 대한 소유자는 로컬일 수 있다.

도 3 및 도 3a는 예시된 부트업 및 RTO 프로세스를 나타낸 것이다. ME는 부트전(pre-boot) 상태(304)를 가질 수 있다. 장치는 306에서 전원이 켜질 수 있다(powered on). ME는 308에서 "안전" 부트("secure" boot)(비TCG)를 수행할 수 있다. ME는 기본 코드 부트됨(base code booted) 상태(310)를 가질 수 있다. 게다가, ME는 312에서 "기본 부트 완료됨(base boot completed)" 신호를 THSM으로 전송할 수 있다. ME는 314에서 기본 구성에 따라 부가의 소프트웨어를 로드할 수 있다. ME 부트가 316에서 완료됨(응용 프로그램 로드됨) 상태일 수 있다. ME는 318에서 부트 완료됨 메시지를 THSM으로 전송될 수 있다.

THSM은 부트전 상태(330)에 있을 수 있다. THSM은 334에서 TE_DM을 로드할 수 있다. THSM은 구성 동안 사전-구성된 파일을 수신할 수 있다 - 예를 들어, 336은 사전 구성된 파일의 사용을 나타내고 있다 -. 338에서, THSM은 "TD_DM 구축" 상태(기본 구성 상태)에 도달할 수 있다. THSM은, 예를 들어, 340에 나타낸 바와 같이, RO 도메인에 대한 이용가능한 자원에 관한 DM의 규격을 수신할 수 있다.

342에서, TD_DM은 TD_DO를 구축할 수 있다(TD_DO는 SDM을 포함할 수 있다). 344에서, THSM은, 예를 들어, 도메인을 구축하기 위해 저장된 구성 파일을 사용할 수 있다(이전의 RTO로 인해 이용가능할 수 있음). 346에서, THSM은 TD_DO 구축 상태(SDM을 포함함)에 도달할 수 있고, 여기서 TD_DO는 DO에 의해 미청구되거나 청구될 수 있다. 350에서, TD_DO는 TD_U를 구축할 수 있다. 352에서, 입력이 DO로부터 수신될 수 있다. 354에서, THSM은 TD_U 구축 상태에 도달할 수 있고, 여기서 TD_U는 미청구되거나 청구될 수 있다. 356에서, THSM은 DO 또는 DU로부터 입력을 수신할 수 있다(예컨대, 파일 또는 상호작용에 의해 DO가 어느 도메인을 구축하고자 할 수 있는지를 지정함). 358에서, TD_DO는 RO 도메인 TD_RO를 구축할 수 있다.

이제 도 3a를 참조하면, 362에서, THSM은 TD_RO 구축됨 상태에 도달할 수 있고, 여기서 TD_RO는 RO에 의해 미청구되거나 청구될 수 있다. 366에서, SDM은 TD_RO에 RTO를 수행하라고 요청할 수 있거나, TD_RO는 RTO를 수행하라고 SDM에 통지(또는 요청)할 수 있다. 370에서, TD_RO는 RTO 프로세스를 시작할 수 있다. 380에서, 대표적인 원격 소유자(RO₁ ...RO_n)가 있다. 384에서, 정보가 교환될 수 있다. 예를 들어, 원격 소유자에서의 RTO 프로세스의 일부로서, 교환되는 정보는 증명, 구성, 정책, 목적, 인증서(본 명세서에서 CERT라고 함), 키 및 SP 내지 TD_RO 중 하나 이상을 포함할 수 있다.. 선택적으로, RO는 RTO 프로세스 동안 DO의 '환경' 또는 '도메인 계획'을 찾아낼 수 있고, 프로세스가 환경/계획에 동의하면 프로세스가 계속될 수 있게 해줄 수 있다.

372에서, THSM은 다양한 도메인에 대한 시스템 구성을 포착/업데이트하고, 정보를 저장하며, 정보를 THSM 내의 비휘발성 보호 메모리에 저장할 수 있다. 374에서, THSM은 RTO후 TD_RO를 갖는 상태에 도달할 수 있다.

제1 실시예를 참조하면, DO의 RTO에 의해 형성된 정책 도메인이 후속 RTO 프로세스의 도메인 구성에 영향을 미치는 규정을 포함할 수 있다. RTO 프로토콜이 비DO RO에 대해 적절할 수 있다. RTO 트랜잭션 동안 DP(domain-specific policy)가 다운로드될 수 있다. 이러한 DP(DP_DO)가 THSM에 원격적으로 소유될 수 있는 다른 도메인을 구축하고 유지하는 데 사용하도록 되어 있는 SDP(System-wide Domain Policy)를 포함할 수 있다는 점에서 DO에 대한 DP가 RO에 대한 DP와 상이할 수 있다. RTO 프로세스 이전에 또는 RTO 프로세스 동안, 도메인의 RO는, 신뢰성 있는 제3자(trusted third party, TTP)로부터, 구성에 대한 기준 무결성 메트릭(Reference Integrity Metric, RIM_RO) 및 THSM의 도메인 전부 또는 일부를 지원하는 하드웨어 또는 소프트웨어의 현재 무결성 상태를 획득할 수 있고, 다음과 같이 표현될 수 있다:

어떤 경우에, TTP는 RO가 변화시키고자 하는 도메인을 비롯한 THSM의 HW 및 SW의 일부에 대한 RIM_RO를 제공할 수 있다. RIM_RO를 제공하기 위해 2개 이상의 TTP가 필요할 수 있고, RO는 이를 수집하여 집합적 기준 메트릭(collective reference metric.)을 형성한다. RTO 프로세스를 거치는 THSM의 대상 도메인(TD_RO _{_} _target)은, THSM의 SDM의 도움을 받아, 그의 RO에 서명된 TPIA(THSM Platform Integrity Attestation)를 제공하도록 구성될 수 있다. TPIA는 THSM 상의 도메인의 개개의 무결성 증명 및/또는 TD_RO _{_} _target에서의 RTO 프로세스의 완료를 가능하게 해주기 전에 대상 도메인의 RO가 변화시키고자 하는 장치의 플랫폼의 무결정 증명의 연결일 수 있다. THSM의 대상 도메인(TD_RO _{_} _target)은, THSM의 SDM의 도움을 받아, 그의 RO에 서명된 TPES(THSM Platform Environment Summary)를 제공할 수 있다. TPES는 THSM 상의 다른 도메인의 수 및 속성과 TE_RO _{_} _target을 위해 사용될 수 있는 임의의 남아 있는 이용가능한 자원 - THSM의 플랫폼의 자원 등 - 을 비롯한 THSM의 환경의 요약을 포함할 수 있고, 다음과 같이 표현될 수 있다:

다른 대안으로서, 관심의 모든 도메인에 걸친 모든 증명을 포함할 수 있는 TPIA를 RO에 보고하는 것 대신에, SDM은 모든 이러한 도메인의 무결성을 검사했고 신뢰할 만한 것으로 생각된다는 반자율적 성명서일 수 있는 서명된 성명서를 제공할 수 있다. 이 증명은 도메인의 집합체의 무결성의 로컬 검증(local verification)을 포함할 수 있다. 로컬 검증자(local verifier)는 THSM 상의 각각의 도메인에 대한 유효한 구성 목록을 포함할 수 있다. SDM은 AIK에 의해 서명될 수 있는 TPIA를 로컬 검증자에게 제공할 수 있다. 개개의 무결성 증명의 검증은 구성 목록 내의 대응하는 로컬적으로 저장된 항목과 일치할 것을 필요로 할 수 있다. SDM은 TPIA를 구성하고 각각의 도메인의 신뢰성을 증명하는 데 필요한 무결성 측정, 로깅 및 PCR에 대한 확장을 수행할 수 있다. 요구된 도메인에 대한 증명이 행해졌다는 것을 입증하기 위해 이들 측정 및 그의 확장이 검증자에 의해 사용될 수 있다.

검증이 달성되었으면, 로컬 검증자는 관련 증명이 행해졌다는 성명서를 준비하고 인증된 키 쌍(K_sign _{_} _verify _{_} _priv, K_sign _{_} _verify _{_} _pub)으로부터의 비밀 키로 이 성명서에 서명을 한다. 서명된 TPES와 연결되는 서명된 검증 성명서(Verification Statement)를 포함하는 메시지가 다음과 같이 표현될 수 있다:

TTP(들)로부터 {RIM_RO}(들)를 수신하고 TD_RO _{_} _target으로부터 서명된 TPIA 및 서명된 TPES를 수신할 시에, RO는, TD_RO _{_} _target이 RO가 RTO 프로세스를 계속하려는 목적에 알맞은 것으로 찾아낸 THSM에서의 환경 등의 환경에 있는지를 검증할 수 있고, TD_{RO_target} 및 RO가 관심을 갖고 있는 임의의 다른 도메인을 지원하는 하드웨어 또는 소프트웨어는 RO에 알맞은 무결성을 갖는 상태에 있다.

원시 도메인에 대한 RTO 프로토콜은 전원을 켤 시에 시작될 수 있다. 선택적으로, RTO 프로토콜은 전원을 켠 후에 시작될 수 있다. THSM의 안전 부트가 완료될 때, 그 결과 얻어지는 도메인의 구축이 처음으로 전원을 켤 때(최초로 전원을 켤 때 등)의 플랫폼의 상태 또는 장치가 이전에 부트업되었다가 전원이 꺼졌을 때의 이전의 상태를 반영하는 내용을 갖는 구성 파일에 의해 결정될 수 있다. 따라서, 장치는 TD_DM 구축, "원시" TD_DO, 및 "원시" TE_U 상태를 포함하는 기본 구성으로 되어 있을 수 있다. 다른 대안으로서, WTRU는 나중의 구성[예를 들어, TD_DM, "RTO후" TD_DO, 및 "RTO후" TE_U 상태를 포함하는 이전의 부트업 및 도메인 구축 또는 RTO 프로세스에 기초한 구성]으로 되어 있을 수 있다. 다른 대안에서, WTRU는, 도 2에 도시된 것과 같은, 확장된 부가 도메인 세트를 역시 포함하는 구성으로 되어 있을 수 있다. 이러한 도메인은 이전의 전원이 있는 세션 동안 생성되었을 수 있고, 이전의 세션 동안 행해졌던 이전에 실행된 RTO 프로세스에 의해 각자의 소유자가 소유권을 취득할 수 있다.

제1 실시예를 참조하면, 플랫폼의 안전하고 신뢰성 있는 엔터티로서, THSM은 소유권 취득 프로토콜을 제어하고 ME가 초기의 신뢰할 만한 상태에 있는지 여부를 결정할 수 있다. 사전-프로비저닝된 키 K_temp가 THSM-ME간 인터페이스를 통해 전송되는 메시지의 기밀성을 보호하기 위해 사용될 수 있다. 간단함을 위해, 암호화된 메시지가 {A}로 나타내어질 수 있고, 메시지의 서명이 [A]로 나타내어질 수 있으며, 표기법 ID_ME 및 ID_THSM는, 각각, ME 및 THSM의 사전-프로비저닝된 임시 ID를 나타낸다.

RTO 개시는 TD_DO의 SDM이 RO에 의해 청구되도록 의도되어 있는 "미청구된" "원시" 도메인에 대한 RTO를 그 특정의 RO에서의 RTO 프로세스 이후에 개시하는 것을 포함할 수 있다. 사용자는 ME 플랫폼의 전원 켜기를 개시할 수 있다. 전원을 켤 시에, ME는 "활성(alive)"으로 되는 기본 코드의 "비TCG" "안전 부트"(OMTP에 의해 정의된 부트 등)를 수행할 수 있다. 비TCG 안전 부트 프로세스의 일부로서, ME의 기본 코드의 무결성이 자율적으로 검사될 수 있다.

제3 실시예를 참조하면, MTE(Mobile Trusted Environment)가 기본 코드 부트 프로세스의 완료 이후에 로드될 수 있다. 서명 키를 사용하여, MTE는 ME 플랫폼 구성의 무결성을 증명할 수 있다.

ME는, 기본 코드의 로드 후에, 최소 안전 설정(minimum secure setting)으로 부트되었다는 것을 나타내는 신호를 THSM으로 주기적으로 전송할 수 있다. 그 신호가 전송될 때 THSM의 DO의 도메인이 아직 부트되지 않았을 수 있기 때문에, ME는 THSM의 DO의 도메인으로부터 확인 응답 신호를 다시 수신할 때까지 다른 랜덤 넌스(random nonce)(nonce_1)와 함께 동일한 신호를 전송할 수 있다. 이 신호는 다음과 같이 표현될 수 있다:

제3 실시예를 참조하면, 시그널링이 다음과 같이 표현될 수 있다:

THSM은 "안전하게" 부트할 수 있고 따라서 THSM은 그의 DM의 도메인, "원시" DO의 도메인, 사용자의 도메인, 및 RO에 의해 소유되기로 되어 있지만 아직 소유되지 않을 수 있는 적어도 하나의 "원시" 도메인을 로드했을 수 있다. 또한, 이들 도메인을 로드할 시에, 각각의 도메인의 코드 상태의 무결성이 각각의 도메인의 기준 무결성 메트릭(RIM)과 대조하여 검사될 수 있다. 이 검사는 TCG MPWG 규격 등의 규격에 따라 수행될 수 있다.

장치 소유자의 도메인(TD_DO)이 "사전 구성된" 구성으로 또는, DO에 대한 RTO 프로세스를 이전에 수행한 경우, "마지막으로 저장된[이전 RTO후(post-previous-RTO)]" 구성으로 로드될 수 있다. DO의 도메인은, 로드될 때, SDM(System-wide Domain Manager)을 포함할 수 있다. SDM은 다른 원격 소유자(RO)에 속하는 도메인의 구축 또는 로드 및 유지를 관리할 수 있다. SDM은 DM의 도메인으로부터 "도메인에 이용가능한 자원의 목록"을 탐색할 수 있고, 또한 TD_DO가 보호하는 SDP(System-wide Domain Policy)를 탐색할 수 있다.

부트 시에, SDM은 또한 "구축될 수 있는 도메인의 목록"을 사용하여 THSM의 사람 사용자 또는 사람 소유자(DO)를 프롬프트하고 구축될 도메인을 선택하는 입력을 요청할 수 있다. 그 입력을 사용자 또는 소유자로부터 얻은 후에, SDM은 사람 소유자 또는 사용자로부터의 응답에 지정된 그 도메인만을 구축하기 시작할 수 있다. SDM은 이들 트랜잭션을 위한 사용자 인터페이스(UI)를 제공하는 ME와 상호작용할 수 있다.

안전 부트 후에, THSM의 TD_DO는 "THSM 부트 완료됨" 메시지를 ME로 전송할 수 있다. 이 메시지 내에, TD_DO는 또한 도메인의 현재 상태 - 로드된 RO의 도메인의 개수 및 이름 등 - 의 외부에 노출가능한 요약을 포함시킬 수 있다. TD_DO의 SDM은 도메인의 현재 상태의 요약의 외부 노출의 정도를 결정하고 시행할 수 있으며, 이러한 결정은 SDP 및/또는 THSM 및/또는 ME 상의 도메인의 DP(domain-specific policy)에 기초할 수 있다. TD_DO는 수신된 nonce_1을 SHA-X 무결성 검사 코드 입력의 일부로서 포함시킴으로써 이 메시지에서 Package_1의 수신을 확인 응답할 수 있으며, 이는 다음과 같이 표현될 수 있다:

ID_THSM 등의 THSM의 ID는 DM의 도메인 TD_DM에 유지될 수 있고 등가적으로 TD_DM의 ID일 수 있다. DO의 도메인 TD_DO는 TD_DM으로부터 이를 페치하여 식 6에서의 Package_2를 구성할 수 있다.

"THSM 부트 완료됨" 신호에 응답하여, ME는 그의 부트 프로세스를 계속하여 완료할 수 있다. 그의 부트 프로세스를 완료한 후에, ME는 다음과 같이 표현될 수 있는 메시지를 THSM의 TD_DO로 전송할 수 있다.

이하는 DO의 도메인의 SDM이 현재 "원시"인 RO의 도메인에 대한 RTO 프로세스를 개시하고 관리하는 경우에 적용된다.

TD_DO가 ME로부터 Package_2를 수신한 후에, RTO 프로세스가 개시될 수 있다. TD_DO 내의 SDM(System-wide Domain Manager)은 "원시" 대상 RO의 도메인(TD*_RO _{_} _Target)에 RTO 프로세스를 시작하라고 요청함으로써 RTO 프로세스를 개시할 수 있다. SDM은 이 프로세스를 자율적으로 또는 사람 소유자 또는 사용자에 의해 프롬프트될 때 개시할 수 있다. SDM은 대상 RO에 대한 RTO 프로세스를 시작하라는 요청을 TD*_RO로 전송할 수 있다. 이 요청은 대상 RO가 누구인지 - RO의 ID 또는 NAI(Network Access Identifier) 등 -, 및 현재 요청의 유효 기간을 포함할 수 있다. 요청의 일부로서 또는 요청과 함께 가는 별도의 패키지로서, SDM은 또한 "허용된 RO의 도메인에 대한 SDP의 조건(SDP's Conditions for Allowed RO's Domains)"(이후부터 SCARD라고 함)의 목록을 전송할 수 있다. SDM은 또한, 의도된 RTO 프로세스 후에 완료될 때, TD_RO에 대한 "대상 도메인 계획(Target Domain Plan)"을 전송할 수 있다. 이 메시징은 다음과 같이 표현될 수 있다:

TD*_RO _{_} _Target은, Package_4의 수신에 응답하여, 요청을 수락하거나 거부할 수 있다. 이 요청은 RO가 RO의 도메인의 소유권을 취득할 수 있게 해주는 "제안"으로서 해석될 수 있다. TD*_RO _{_} _Target은 사전-구성된 기준 또는 로드된 그 자신의 "원시 버전"의 RO의 도메인 정책에 기초하여 그 결정을 할 수 있다. TD*_RO _{_} _Target은 Request_to_start_RTO, SCARD, 및 Target_Domain_Plan을 검사하고, 실제의 대상 원격 소유자가 없는 경우 그리고 실제의 대상 원격 소유자를 위해, 이러한 결정을 하도록 구성될 수 있다. 이것은 다음과 같이 표현될 수 있다:

"원시" 대상 RO의 도메인(TD*_RO _{_} _Target)은 이 프로세스를 개시할 수 있다. TD*_{RO_Target}은 RTO 프로세스에 대한 그의 "최종적인 도메인 계획"을 SDM에 알려줄 수 있다. SDM은 요청을 허가하거나 거부할 수 있다. SDM이 요청을 허가하는 경우, TD*_RO는 RTO 프로세스를 시작할 수 있고, 이는 다음과 같이 표현될 수 있다:

Package_5a 또는 Package_5b의 수신에 응답하여, SDM은, TD*_RO _{_} _Target에 대한 RTO 프로세스를 위해, 사전 구성되거나 TD_DO에 대한 RTO 프로세스에 의해 획득될 수 있는 SDP(System Domain Policy), 사전 구성되거나 소유자에 의해 공급될 수 있는 "원하는 도메인"의 목록, DM의 도메인에 의해 유지되고 연속적으로 업데이트될 수 있는 "도메인에 이용가능한 자원"의 목록, 또는THSM 내의 도메인의 현재 상태를 탐색할 수 있다.

SDM은 또한 THSM 상에 다수의 도메인을 구축하거나 유지하는 데 이용가능한 충분한 자원(가상 기계 스레드에 대한 메모리 또는 컴퓨팅 자원 등)이 있는지, THSM 내의 도메인의 현재 상태가 "원하는 도메인" 목록에 지정된 것과 일치하는지, "원하는 도메인" 내의 임의의 새로운 도메인의 구축 또는 로드가 THSM 내의 도메인의 현재 상태에 의해 지원가능하고 또한 SDP 하에서 허용되는지, 또는 도메인들 중 하나 이상의 도메인이 RTO 프로세스를 수행할 필요가 있는지를 평가할 수 있다.

SDM이 TD*_RO _{_} _Target이 이용가능한 자원, THSM의 기존의 도메인의 현재 상태, 및 SDP에 따라 RTO 프로세스를 수행할 수 있는 것으로 결정하는 경우, SDM은 이 결정을 (TD*_RO _{_} _Target)에 알려주고, TD*_RO _{_} _Target 및 그의 주변의 도메인에 대한 그의 평가를 위해, RTO 프로세스 동안, RO로 전달될 다수의 무결성 증명을 준비하기 시작한다. 이것은 다음과 같이 표현될 수 있다:

SDM은, 예를 들어, WTRU 상에 디스플레이되는 메시지에 의해, 특정의 도메인에 대한 RTO 프로세스를 개시하려 한다는 것을 사람 사용자에게 알려줄 수 있다. SDM은 또한 "RTO 프로세스를 시작하기를 원하는 도메인 및 원하는 RO"의 목록을 사용하여 사람 사용자 또는 사람 소유자(DO)를 프롬프트할 수 있고, 소유자 또는 사용자가 프롬프트에 응답하여 지정하는 그 RO의 도메인에 대해서만 RTO 프로세스를 개시하기 시작한다. SDM은 이들 트랜잭션을 위한 사용자 인터페이스(UI)를 제공하는 ME와 상호작용할 수 있다.

TD*_RO _{_} _Target은 TPIA(THSM Platform Integrity Attestation) 및 TPES(THSM Platform Environment Summary)를 구성하기 위해 사용할 수 있는 자료를 준비하라고 SDM에 요청할 수 있다. 이것은 다음과 같이 표현될 수 있다:

제3 실시예를 참조하면, 요청이 다음과 같이 표현될 수 있다:

TPIA 및 TPES에 대한 요청에서, RO는 SDM으로부터 TPIA 및 TPES에 관한 어떤 종류의 정보를 탐색할지를 지정할 수 있다. 예를 들어, TPIA의 경우, RO는 무결성을 검증하고자 하는 그 자체 이외의 도메인의 이름 또는 범위를 지정할 수 있다. 이와 마찬가지로, TPES의 경우, RO는 그 자체 이외의 도메인의 소유자의 공개 ID - NAI(network allocation identifier) 등 - 를 지정할 수 있다.

제3 실시예를 참조하면, 대상 RO는 또한 ME 플랫폼의 무결성에 관한 특정의 정보(이후부터 MPID라고 함) 및 ME 환경에 관한 기타 정보를 요청할 수 있다. 다른 대안으로서, RO는 MTE가 로드되었고 MPID 및 MPES가 ME에 의해 SDM으로 전송되었다는 간단한 표시자를 요청할 수 있다. MT 플랫폼에 존재하는 신뢰성 있는 엔터티인 MTE는 SDM에 의해 값 MPID 및 MPES를 준비하라고 요청받을 때 그렇게 할 수 있다. 이 요청은 다음과 같이 표현될 수 있다:

MTE는 ME로부터 구성 데이터를 수집하고 MPID를 작성할 수 있다. MPES(ME Platform Environment Survey)를 생성하기 위해 환경 데이터가 또한 획득될 수 있다. 이들 값은 시간이 지남에 따라 변할 수 있는 현재의 ME 상태에 기초할 수 있다. ME 상태 변경 이후에 장래의 요청이 행해질 때 업데이트된 값이 SDM으로 전송될 수 있다. 일반적으로, MTE는 다음과 같이 표현될 수 있는 응답을 SDM으로 전송할 수 있다:

MTE는 그의 공개 키 K_MTE _{_} _Pub를 포함하는 인증서 - CA에 의해 서명되어 있을 수 있음 - 를 제공할 수 있다. 따라서, SDM은 CA 서명의 검증을 통해 이 공개 키의 신뢰성를 검증할 수 있고, 따라서 K_MTE _{_} _Pub를 사용하여 MTE로부터의 메시지의 무결성을 검사할 수 있다. SDM은 TPIA 및 TPES를 준비하고 나중에 TD*_RO _{_} _Target으로 전달할 수 있다.

TPIA의 준비를 위해, SDM은 "원시" TD_RO의 무결성 증명 및 그에 의한 무결성 증명, TE_DO의 무결정 증명 및 그에 의한 무결성 증명, TE_U의 무결성 증명 및 그에 의한 무결성 증명(장치 사용자가 DO와 상이한 경우), 및 RO가 관심을 가지고 있는 임의의 다른 기존의 TD_RO의 무결성 증명 및 그에 의한 무결성 증명 등의 무결성 증명을 수집할 수 있다.

다른 대안으로서, SDM은, PCR로부터 무결성 값을 수집한 후에, 코드 및 데이터 등의 측정 로그의 로컬 자율 검사 및 재계산의 프로세스에 의해, 각자의 도메인에 대한 PCR로부터의 다이제스트 값과 대조하여 도메인을 검증할 수 있다. 이것은 TTP(PCA)가 각자의 도메인을 포함해야만 하는 마지막 코드를 알고 있지 않을 때 수행될 수 있고, TTP는 WTRU 상의 TPM 또는 MTM에 대해 인증되어 있는 AIK에 링크되어 있는 서명 키를 인증할 수 있다. TTP는 RO가 SDM으로부터의 TPIA를 비교하기 위해 사용할 수 있는 다이제스트 메트릭에 대한 기준 값을 제공하도록 구성되지 않을 수 있다. SDM은, 도메인에 대한 코드의 다이제스트를 재계산하고 이를 인용된 PCR 값과 비교함으로써, 도메인에 대해 가져온 PCR 인용(PCR quote)이 최신의 것인지를 로컬적으로 검사할 수 있다. 이 로컬 검사가 통과되면, SDM은 TPIA에 서명하고, 이를 MTE 또는 ME를 통해 TD_RO _{_} _target 및 RO_target으로 전달할 수 있다.

3중 검증(3-way verification)인 다른 대안에서, SDM은, TPIA의 일부로서, 도메인의 다이제스트 및 측정 로그(실제 코드 등)를 제공할 수 있다. RO는, 다이제스트와 함께 코드를 가져올 때, TTP로부터 다이제스트에 대한 기준 메트릭을 가져올 수 있고, 측정 로그로부터 다이제스트를 재계산할 수 있으며, 이를 TD_RO _{_} _Target으로부터 수신한 인용된 PCR 다이제스트는 물론 TTP로부터 수신한 다이제스트의 기준 메트릭과 비교할 수 있다.

측정 로그를 갖거나 갖지 않는 TPIA는 또한 개개의 도메인의 다이제스트에 대한 인용을 효과적으로 타임-스탬핑하는, PCR 인용이 일어났을 때의 "로컬 시간"의 표시를 포함할 수 있다. 이것은 도메인의 PCR 다이제스트 각각이 SDM에 의해 마지막으로 획득되었을 때의 어떤 표시를 제공한다. 측정 로그가 RO로 전송되지 않은 경우, 로컬 다이제스트가 획득되고 TPIA에 포함되었을 때가 증명 검증에서 사용할 수 있을 정도로 충분히 최근인지를 결정하는 것과 관련하여 TPIA에 표시된 증명을 검증할 필요가 있을 때 PCR의 타임-스탬핑된 인용이 어떤 부가 정보를 RO에 제공할 수 있다. 이러한 타임-스탬핑에 사용되는 클록은 신뢰할 만한 클록일 수 있다.

3중 검증이 실패하는 경우에, RO는 TTP에게 업데이트된 기준 메트릭 또는 측정 로그 - 이들로부터 원하는 다이제스트를 계산할 수 있음 - 를 제공하라고 요청할 수 있다. RO는 3중 검증을 재시도할 수 있다. 검증이 성공하는 경우, RTO가 계속된다. 검증이 실패하고 RO 정책에 의해 3중 검증의 성공이 요구되는 경우, RTO가 종료될 수 있다.

DO의 도메인의 무결성 증명에 대해, SDM은 SDM의 고유 기능(native function) 등을 통해 이를 자율적으로 획득할 수 있다. DO의 도메인에 대한 무결성 증명을 제외한 무결성 증명에 대해, SDM은 각자의 다른 도메인에 그 자신의 각자의 무결성 증명을 생성하고 서명하라고 요청할 수 있다. 요청에, SDM은 수신자가 SDM이 도메인에 무결성 증명을 요청하여 획득할 수 있는 권한을 가지고 있는지를 검사하는 데 사용할 수 있는 토큰 등의 허가 데이터를 포함시킬 수 있다. 요청은 또한 대상 RO 및 대상 RO의 요청의 전달자인 SDM이 수신자 도메인의 무결성에 대해 검사할 필요가 있는 수신자 도메인의 PCR(Platform Configuration Register)의 범위를 포함할 수 있다. 이 요청은 다음과 같이 표현될 수 있다:

각각의 도메인 - domain(i), i=1,2, ...,N으로 표시되고, 여기서 N은 SDM이 PCR 값을 수집하는 도메인의 수임 - 은 먼저 Request_for_Attestation에서의 허가 데이터를 검사하고, 이어서 Request_for_Attestation에 지정되어 있는 PCR의 범위의 PCR 값을 페치한다. 이 동작은 다음과 같이 표현될 수 있다:

SDM은 모든 증명을 연결시키고 이를 그의 서명 키로 서명하기 위해 TPIA(THSM Platform Integrity Attestation)를 수행할 수 있다. 이것은 다음과 같이 표현될 수 있다:

TPES의 준비를 위해, SDM은, TD_DM, TD_DO, 및 TD_Domains _(i)로부터 수집하는 정보(DM의 도메인으로부터 획득될 수 있는 THSM HW 및 SW 구성과 버전 번호 등), BIOS 구성, 플랫폼 상의 도메인의 수, 현재 도메인을 위해 사용된 총 플랫폼 자원(메모리 등), 기존의 또는 새로운 도메인의 추가적인 구축 또는 확장을 위해 남아 있는 플랫폼 자원, 도메인의 이름, 또는 그의 소유주의 이름 또는 ID( NAI 등)(각자의 도메인 소유자에 의해 허용되어 있는 경우), 날짜/시각, 또는 단조적 카운터 값(이것이 이용가능한 경우)(그러나, 상기 환경 정보가 SDM에 의해 수집되었던 날짜/시각은 아님), 임의의 다른 관련 정보를 연결함으로써, TPES를 생성할 수 있다. 이 요청은 다음과 같이 표현될 수 있다:

SDM은 TPIA 및 TPES에 서명하고 이를 TD*_RO _{_} _Target으로 전달할 수 있다. SDM은 또한 서명된 SCARD를 포함할 수 있고, 따라서 DO는 SCARD를 검사할 수 없는 경우 어떤 원시 TD*_RO _{_} _Target에도 의존할 필요가 없을지도 모른다. SCARD는 TPIA 및 TPES와 함께 RO로 전송될 수 있고, 따라서 RO는 SCARD, TPIA 및 TPES를 검사한 후에 소유권 취득을 추진하기로 결정을 할 수 있다. 이 메시징은 다음과 같이 표현될 수 있다:

TPIA, TPES, 및 SCARD를 SDM으로부터 수신할 시에, TD*_RO _{_} _Target은 SDM의 공개 서명 키로 이들을 검사함으로써 그의 무결성을 검사할 수 있다. 이어서, TPIA, TPES, SCARD, 사용자가 원하는 서비스를 나타내는 목적 정보 요소(purpose information element)(P), 및 소유권 취득 요청 메시지(request_TO)가 ME로 전송될 수 있다. RTO 프로세스가 완전 TSIM 능력을 위해 프로비저닝되어 있어야만 하는 도메인에 대한 것인 경우, TSIM 기능에 관한 서명된 인증서(Cert_TSIM)가 또한 준비되고 상기 패키지와 함께 전송될 수 있다.

TSIM 기능을 위해 사용되는 2개 이상의 인증서가 있을 수 있다. 하나는 원시 TSIM 기능에 대한 인증서(CERT*_TSIM)에 대한 것이고 다른 것들은 완전히 인스턴스화되거나 업데이트되어 있는 인증서에 대한 것이다. 원시 TSIM 기능에 대한 인증서는 DM에 대한 인증서 구조에 모듈 방식으로 내장(modularly embedded)되어 있을 수 있다(예를 들어, DM으로부터의 기능인 원시 도메인에 플러그인되어 있을 수 있다).

TD가 적어도 하나의 RTO를 이전에 수행한 후에 RO가 RTO 프로세스를 수행할 때, RO는 더 이상 CERT*_TSIM을 전송할 필요가 없을 수 있는데, 그 이유는 이 인증서가 원시 도메인 - TD_RO가 더 이상 원시 도메인이 아닐 수 있음 - 에서만 사용하기에 적절할 것이기 때문이다. 따라서, 이 경우에, RO는 업데이트된 인증서 CERT_TSIM을 전송할 수 있다.

내용이 대상 RO의 공개 키(K_Target_RO_pub) - 예를 들어, TD*_RO _{_} _Target에 의한 사용 이전에, 원시 TD*_RO _{_} _Target이 로드될 때 대상 RO가 이미 알려져 있는 경우에, 인증서 전달에 의해 또는 사전 구성에 의해 이용가능하게 되었을 수 있음 - 로 암호화될 수 있다. TSIM은 서명 키 K__TSIM _- _Sign에 의해 사전-프로비저닝되어 있을 수 있다. 이 비밀 서명 키의 공개 키가 대상 RO에 사전 배포되어 있을 수 있다. ID_ME는 TD*_{RO_Target}이 ME ID를 안전하게 보유하고 있는 THSM DM의 도메인 TD_DM으로부터 획득하는 ME의 ID이다. 이것은 다음과 같이 표현될 수 있다:

제3 실시예를 참조하면, 값 MPIA 및 MPES가 메시지에 부가될 수 있다. MPIA는 MTE에 의해 편집되는 구성 데이터(MPID)에 기초하여 THSM에서 계산되는 다이제스트를 포함할 수 있다. 구성 파일에 이미 존재하거나 DM과의 실시간 통신을 통해 전달되는 획득된 인증된 메트릭으로 검사하는 경우에만, 이 다이제스트가 증명될 수 있다. 무결성 및 환경 정보에 대한 RO 요청에 따라, 식 20은 SDM이 MPID 및 MPES를 성공적으로 수신했다는 간단한 표시를 포함할 수 있다. 이것은 다음과 같이 표현될 수 있다:

ME는 다음과 같이 표현될 수 있는 상기 전체 메시지를 RO로 전송할 수 있다:

제3 실시예를 참조하면, 이 메시지는 MPIA 및 MPES를 포함할 것이다.

RO는 그의 비밀 키 K_Target _{_} _RO _{_} _Priv _.를 사용하여 Package_10를 복호화하고, ME의 ID를 검사하며, 메시지를 해석할 수 있다. RO는 SCARD를 해석하고, SDP로부터의 이들 조건에 "동의"할 수 있는지를 살펴볼 수 있다. RO가 SCARD에 동의하는 경우, 임의의 서비스 크리텐셜 또는 구성 제어가 대상 RO의 도메인 TD*_RO _{_} _Target에 제공되기 전에, 예를 들어, 원시 TD*_RO _{_} _Target으로부터의 값 TPIA가 전체 초기 TSIM 상태를 나타내는 것으로 해석될 수 있다.. 값 P가 사용자가 원하하는 서비스를 나타낸 것으로 해석될 수 있다. TSIM-지원 TD*_RO _{_} _Target의 경우에 MNO일 수 있는 대상 RO는 TPIA에 나타낸 바와 같이 TPIA를 TTP로부터 독립적으로 획득한 RIM(Reference Integrity Metrics) 값(RIM_RO)과 비교함으로써 관심의 도메인의 무결성을 검증할 수 있다.

MNO는 WTRU/THSM의 공급자에 의해, 예를 들어, TTP에 제공되는 인증서를 통해 TPIA의 예상된 값을 알아내는 기능을 가질 수 있다. 제3 실시예를 참조하면, MPIA 및 MPES의 예상된 값이 MTE가 신뢰성 있는 엔터티 - 그의 신뢰성은 THSM에 의해 증명되었음 - 라는 사실에 의해 가능하게 되는 인증서 프로세스를 통해 미리 알려질 수 있다.

대상 RO는 수신된 TPES를 탐색할 수 있고, TD*_RO _{_} _Target이 RO가 자체적으로 RTO 프로세스를 추가적으로 계속할 수 있는 것과 관련하여 대상 RO에 "적당한", 예를 들어, TPES로 표현되는 "주변 시스템 환경"을 갖는 THSM 시스템에 있는지를 평가할 수 있다.

TPIA, TPES, 목적 P, Request_TO, 그리고, 제3 실시예를 참조하여, MPIA 및 MPES를 검사한 후에, MNO 등의 대상 RO는 대상 RO에게 "소유권을 취득"하라고 요청하는 원시 TD*_RO _{_} _Target은 물론 일반의 TD*_RO _{_} _Target을 포함하는 THSM이 RO로 하여금 RTO 프로세스를 추가로 계속하게 하고 RO로 하여금 TD*_RO _{_} _Target에게 RO와 상호작용하여 어떤 사전 지정된 기본 서비스를 제공하게 하는 데 충분히 "신뢰"할 만한지를 결정할 수 있다.

도메인이 나중에 키, 더 상세한 구성, 파라미터 및 실행 파일을 다운로드하고 이들을 기본 "원시" 상태가 허용하는 것보다 더 많은 기능을 갖도록 또한 대상 원격 소유자(RO)에 의해 청구 또는 소유되거나 관리되도록 설치할 수 있도록 TD*_{RO_Target}의 소유권 취득을 수행하기 위해, 대상 RO는 실행 파일을 포함할 수 있는 구성 신호(CONFIG)를 전송할 수 있다. RO는 또한, TD_RO _{_} _Target이 수신된 CONFIG에 따라 구성, 파라미터, 및 실행 파일을 설치하는 경우, 설치후 상태와 일치할 수 있는 TSIM에 대한 RIM(RIM_TSIM이라고 함)을 전송한다. RIM_TSIM은 TD*_RO _{_} _Target 상의 안전한 메모리에 저장될 수 있고, 장래의 부트 시에 TSIM 기능의 무결성을 검사하는 데 사용될 수 있다. 이용될 보안 대책은 물론 다른 구성 문제를 명시하는 DP(domain policy)가 트랜잭션에 포함될 수 있다.

RO-관련 DP(domain policy)는 SDM에 의해 보유되어 있고 THSM 상의 특정의 RO에 의해 소유되는 하나 이상의 도메인을 구축하고 관리하는 계획을 나타내는 SDP(System-wide Domain Policy)와 상이할 수 있다. RO-관련 DP는 특정의 도메인에 고유하고 배타적인 도메인내 응용 프로그램 및 보안 대책을 규율하는 정책 또는 계획을 포함할 수 있다.

어떤 RO는 DP가 어떤 다른 RO가 THSM 상에서 구축되거나 관리되는 데 "적당"한지에 관한 제한을 두는 규정을 포함할 수 있는 방식으로 그의 DP를 작성할 수 있다. 예를 들어, 모바일 네트워크 통신 사업자(MNO_A)는, THSM 상의 다른 도메인들 중 일부의 상태 및 속성에 관해 DP_MNO _{_A}에 규정된 조건들 중 일부가 만족스러울 정도로 충족되지 않은 것으로 밝혀지는 경우, 그의 대상 도메인(TD_MNO _{_A})이, DP_MNO _{_A}를 다운로드하여 설치한 후에, 예를 들어, 그의 서비스 또는 활성화에 대한 일련의 제한에 의해 규율되도록 하는 방식으로 그의 DP_MNO _{_A}를 작성할 수 있다. 예를 들어, MNO는 TD_MNO _{_A}가, THSM 내의 더 큰 환경을 조사한 후에, 동일한 THSM 상에 설치되어 활성인 그 자신의 활성화된 TSIM 기능을 갖는 다른 MNO의 도메인이 있다는 것을 발견한 경우 TD_MNO _{_A}가 그의 TSIM 기능을 디스에이블시키도록 DP_MNO _{_A}를 구현할 수 있다.

TD*_RO _{_} _Target은 P에서의 요청된 서비스에 대응하는 방식으로 그 자체를 구성해야만 할지도 모른다. 예를 들어, RO는 응답을 ME로 전송할 수 있고, 이 때 메시지 기밀성이 K_TSIM _- _Pub를 사용하여 보호된다. ME는 이 메시지를 THSM 상의 TD*_Target _{_} _RO로 전송할 수 있다. Cert_RO는 Target_RO의 공개 키 K_RO-_priv를 포함할 수 있다. RO는, 이 때, TSIM에 대한 RIM(reference integrity metric)을 전송할 수 있다. RO 응답은 다음과 같이 표현될 수 있다:

TD*_RO _{_} _Target은 비밀 키 K_TSIM _- _Priv로 메시지를 복호화할 수 있고 CA에서 그 인증서를 검사한 후에 Cert_RO에서의 공개 키 K_RO _{_} _Pub를 사용하여 RO 서명을 검증할 수 있다. 이는 TSIM 응용 프로그램에 대한 수신된 기준 무결성 메트릭 RIM_TSIM을 안전하게 저장할 수 있다. 이는 ID_RO로부터 RO의 ID를 검사할 수 있고, 이어서 RO의 정책 DP_RO를 검사할 수 있으며, CONFIG의 나머지 구성 및 설치를 계속할 수 있는지를 결정할 수 있다. TD*_RO _{_} _Target은 "완료" 도메인 상태에 도달하기 위해 CONFIG를 통해 재구성을 수행할 수 있고, 이어서 그의 TSIM 기능의 측정된 메트릭이 네트워크에 의해 전달되고 RIM_TSIM에 표현되어 있는 것과 일치하는지를 결정하기 위해 자체-테스트를 실행한다. 도메인 TD_RO _{_} _Target은 이제 "완료"되었고, 더 이상 "원시"가 아니며, 따라서 표기법에 별표 *가 제거된다. 이것은 다음과 같이 표현될 수 있다:

완료된 도메인 TD_Target _RO은 "RTO 성공 및 도메인 완료됨" 상태 메시지를 ME로 전송할 수 있고, ME는 이를 대상 RO로 전달할 수 있다. 이것은 다음과 같이 표현될 수 있다:

선택적으로, ME는 전화가 현재 등록 및 크리텐셜 롤아웃할 준비가 되어 있다는 상태 메시지를 사용자에게 전송할 수 있다(예를 들어, WTRU의 화면에 디스플레이됨).

ME는 플랫폼의 재구성이 성공적으로 완료되었고 TSIM 크리텐셜을 등록할 준비가 되었다는 상태 메시지를 RO로 전달할 수 있다. TD_RO _{_} _Target은 "THSM_TD_RO_LOAD_COMPLETE" 상태에 도달하였다. 이 메시지는 다음과 같이 표현될 수 있다:

이 RTO 프로토콜은 THSM의 소유자 또는 사용자인 가입자를 가입형 서비스를 제공하는 3G UMTS 네트워크 통신사업자에 등록하는 프로토콜에 대해 또한 AKA(authentication and key agreement)에 대한 크리텐셜을 다운로드하고 프로비저닝하는 나중의 프로토콜 - 공유 비밀 K 및 가입자 ID IMSI를 다운로드하고 프로비저닝하는 것을 포함함 - 에 대해 프리커서(precursor)로서 역할할 수 있다.

공개-비밀 키 세트에 대한 인증서 Cert_TSIM 및 Cert_RO는 이들이 사용되는 메시지를 통해 전달될 수 있다. 다른 대안으로서, RO의 도메인(TD_RO) 및 RO는 신뢰성 있는 제3자로부터 그 각자의 인증서를 획득할 수 있다. 이 획득은 다음과 같이 표현될 수 있다:

다른 대안에서, RO의 인증서 Cert_RO는 네트워크로부터 ME로 전달될 수 있고, THSM의 인증서 Cert_TSIM은 ME로부터 네트워크로 전달될 수 있으며, 그 후에 이들이 사용되는 메시지가 전달된다. 따라서, 본 명세서에 기술되어 있는 암호화된 메시지 이전에 통신이 전송될 수 있고, 이들 통신은 다음과 같이 표현될 수 있다.

이들 대안의 인증서 전달 방법 각각에 대해, 엔터티 ID는 공개 암호화 키가 사용되는 메시지를 수반할 수 있다.

다른 대안에서, 메시지의 기밀성을 보호하기 위해 공개 키 대신에 대칭 키를 사용하는 것이 이용될 수 있다. 각각의 경우에, 전송자는, 예를 들어, 의사 난수 발생기(pseudo-random number generator, PRNG)를 사용하여 대칭 키 K_S를 발생할 수 있고, 공개 키가 아니라 이 키를 사용하여, 메시지의 기밀성을 보호할 수 있다. 대칭 암호화 키는 또한 암호화된 메시지와 함께 수신자에게 전송될 수 있고, 이 경우 대칭 암호화 키는 공개 키로 보호된다. 따라서, 수신자는 그의 비밀 키를 사용하여 키 K_S에 액세스할 수 있고, 이어서 이를 사용하여 메시지를 복호화할 수 있다.

제2 실시예를 참조하면, THSM 및 ME는 제1 실시예의 THSM 및 ME와 상이할 수 있다. ME가 부트될 때 ME의 코드의 일부 또는 전부의 무결성 검사를, ME 자체 또는 MTE 등의 ME 내의 신뢰성 있는 엔터티 대신에, THSM가 수행하도록 구성될 수 있다. 선택적으로, THSM은 또한 ME에 대한 부트 코드의 일부 또는 전부를 저장하고 있을 수 있다. THSM은 외부 평가자에 대해 ME의 무결성을 증명하도록 구성되지 않을 수 있다. THSM은 부트 시에 ME 코드의 무결성의 "로컬" 검사를 수행하도록 구성될 수 있다.

ME에 대한 무결성 값이 부트업 프로세스에서 사용될 수 있고, RTO 프로세스에서 사용되지 않을 수 있다. ME의 안전 부트로부터 얻어지는 ME 코드 및 구성 상태를 나타내는 ME의 무결성 측정(meas_ME로 표시됨)이 THSM의 DM의 도메인 TE_DM에 의해 획득될 수 있다. THSM의 TD_DM은 meas_ME의 유효성을 검사할 수 있지만, 이를 플랫폼 증명에 포함시키지 않을 수 있다.

제4 실시예를 참조하면, ME는, 예를 들어, TCG MPWG의 측면에서 신뢰성 있는 ME일 수 있다. ME는 MTM(mobile trusted module)을 포함할 수 있고, MTM을 저장, 보고, 측정, 검증 및 시행에 대한 신뢰의 기초(root of trust)를 제공하는 그의 신뢰 앵커(trust anchor)로서 갖는 것으로 인해 신뢰될 수 있다.

도 4 및 도 4a는 원격 소유권 취득 프로세스에 대한 예시적인 호 흐름도를 나타낸 것이다. 예를 들어, 도 4 및 도 4a는 ME(402), TD_DO(404), SDM(406), TD*_{Target_RO}(408) 및 대상 RO(410) 중 하나 이상 사이의 예시적인 호를 나타낸 것이다. 도 4 및 도 4a에서의 화살표는 호의 발신지/목적지를 나타낼 수 있다.

도 2 및 도 3에 도시된 바와 같이, SDM은 THSM에 존재하는 시스템 전체 도메인 관리자를 포함할 수 있고, DO의 기능의 일부를 제공할 수 있다. SDM은 장치 내의 모든 도메인 설정의 감독 및 조정을 하여, SDP 및 도메인 관련 정책에서의 임의의 충돌이 DO 및 다른 도메인의 RO를 대신하여 SDM에 의해 조정되도록 시도되는 한, 이러한 도메인 전부가 SDP에 따라 그리고 도메인-관련 정책에 따라 동작하고 서로 상호작용하도록 할 수 있다. TD_DO는 THSM에 필수적인 장치 소유자 도메인을 포함할 수 있다. TD_DO는 SDM을 포함할 수 있고, 따라서 시스템 레벨 도메인 정책을 유지할 수 있다. MTE는 ME측에 대한 정책 관리자 ME_PDM을 포함할 수 있다. . ME_PDM은 ME 상에서 정책 관리자 기능을 수행할 수 있지만, THSM 내의 SDM의 감독을 받지 않을 수 있다. ME*_Target _{_} _RO는 허용된 원격 소유자의 원격 소유권에 대한 원시 도메인 설정을 포함할 수 있다. 대상 RO는 ME*_Target _{_} _RO의 소유권을 요청하는 원격 소유자를 포함할 수 있다.

ME는 인식된 원격 소유자의 ME 상의 도메인에 대한 원격 소유권 취득이 지원되도록 완전 MTM 기능(full MTM functionality)을 가지고 있을 수 있다. 제1 실시예를 참조하여 기술된 RTO와 유사하게, THSM 및 ME 둘 다에 있는 동일한 원격 소유자에 의해 소유된 그 도메인에 대한 ME_PDM에 대해 SDM에 의해 실시되는 궁극적인 정책 제어에 의해 이들이 기본적으로 상이하다. 따라서, THSM 상의 도메인도 소유하는 동일한 원격 소유자에 의해 소유된 임의의 ME 도메인의 형성 및 관리가 SDM의 정책에 부합하는 방식으로 행해져야만 한다.

여전히 도 4를 참조하면, 41에서, 기본 코드 부트가 ME(402)에 의해 완료될 수 있다. 415에서, THSM이 안전 부트될 수 있다. THSM은 DO의 도메인을 로드할 수 있고, SDM이 포함될 수 있으며, 이 경우 SDM은 1) 도메인 구축에 이용가능한 자원; 및/또는 2) 허용가능한 도메인의 목록을 사용자에게 제공할 수 있다. 42에서, THSM이 그의 부트를 완료할 수 있다. 425에서, ME가 그의 부트를 완료할 수 있다. 43에서, ME는 그의 부트가 완료되었다는 것을 나타낼 수 있다. 이 프로세스 동안, DM의 도메인이 구축될 수 있고, 선택적인 사용자 도메인(ME_U)도 역시 구축될 수 있으며, 이용가능한 자원이 검사될 수 있다. DM의 도메인은 ME 장치에 대한 도메인 정책의 초기 구성 및 규격을 제공하는 ME_PDM을 포함할 수 있다. ME_DM의 사전 구성에 의해, ME 도메인과 THSM 도메인 사이에서 공통의 원격 소유자를 갖는 THSM 상의 도메인 및 ME 상의 다른 도메인 등의 그 도메인들에 대한 정책들과 관련하여 이 정책이 SDP의 정책과 일관성을 유지하게 될 수 있다.

여전히 도 4를 참조하면, 그의 사전 구성된 도메인을 갖는 ME는, 431에서, "부트 완료됨" 메시지를 전송하고 RTO를 개시할 수 있다. 이 메시지는 ME에서의 이용가능한 자원 및 DM 도메인 정책에 관한 명시적인 정보를 포함할 수 있다. 44에서, 대상 도메인 계획을 포함하는 RTO를 시작하라는 요청이 전송될 수 있다. 455에서, TD*_Target _{_} _RO(408)에 의해 RTO 시작 요청을 수락하거나 거부하기로 결정할 수 있다. 45에서, RTO가 시작되어야만 하는지를 나타내는 메시지가 전송될 수 있다. 다른 대안으로서, 456에서, RTO가 TD*_Target _{_} _RO(408)에서 시작될 수 있다. 451에서, TD*_{Target_RO}(408)는 "RTO 최종 도메인 계획을 시작하려는 의도"를 전송할 수 있다.

SDM은 THSM의 SDP(system-wide domain policy)를 평가하고 ME 도메인에 어떤 제한이 부과되거나 할당되어야 하는지를 결정함으로써 ME 부트 메시지에 응답할 수 있다. 이들 정책 제한은, 그의 연관된 원격 소유자에 따라 ME 및 THSM 상에서 어떤 도메인이 허용되는지를 포함할 수 있다. SDM은 ME가 THSM 상의 도메인을 가지는 동일한 원격 소유자에 의해 소유된 도메인(THSM 상의 도메인 중 원격 소유자가 알고 있는 도메인을 포함함)에 대해 어떤 시스템 전체 자원(system-wide resource)을 사용할 수 있는지를 결정할 수 있다. ME_PDM은 식 7에서의 메시지를 통해 이 정보를 수신할 수 있다. SDM은 또한 정책 제한을 그의 기본 정책에 포함시키고 허용가능한 자원을 그의 자원 목록에 포함시킬 수 있다. ME_PDM은, 정보를 수신한 후에, ME 상의 자원 및 도메인의 관리에 관한 결정을 하고 결정을 시행하는 것과 관련하여, 모든 이러한 결정에 대해 SDM으로부터 허가를 받을 필요 없이, 어떤 특권을 행사할 수 있다.

여전히 도 4를 참조하면, 이 프로세스가 465에서 계속될 수 있다. 465에서, 하기의 것들이 검사되고 및/또는 평가될 수 있다: SDP, 이용가능한 자원, 및/또는 허용가능한 도메인 및/또는 상태. 46에서, "시작하라고 수락" 신호가 전송될 수 있다. 47에서, TPIA, TPES, MPID, 및 MPES에 대한 요청이 전송될 수 있다. 475에서, SDM(406)은, 예를 들어, 도메인마다 일정 범위의 PCR에 걸쳐 기존의 도메인으로부터 무결성 증명을 수집/연결할 수 있고 및/또는 TPES 정보를 수집 및/또는 연결할 수 있다.

471에서, MPID 및 MPES에 대한 요청이 전송될 수 있다. 476에서, MPID 및 MPES에 대한 요청의 응답이 MTE에 의해 처리될 수 있다. 48에서, MPID 및 MPES가 신뢰의 증거와 함께, 서명 키와 함께 전송될 수 있다. 481에서, TPIA, TPES, MPID 및 MPES가 SDM(406)으로부터 TE*_Target _{_} _RO(408)로 전송될 수 있다. 485에서, THSM은 MPID(원시 데이터)로부터 다이제스트 MPIA를 계산할 수 있고 MPIA를 검사할 수 있다. 허용가능한 경우, 다이제스트 MPIA가 RO로 전송될 수 있다. 49에서,

에 대한 요청이 전송될 수 있다.

도 4a를 참조하면, RTO 프로세스를 계속하여,

메시지가 대상 RO(410)로 전송될 수 있다. 418에서, 대상 RO(410)는, 예를 들어, TPIA, TPES, MPIA, MPES 및 목적을 검사하는 것; RIMTDRO와 대조하여 원시 도메인의 신뢰성을 결정하는 것; 허용가능성에 대해 DP를 검사하는 것; 또는 전체 도메인 상태를 구축하기 위해 CONFIG를 생성하는 것 중 하나 이상을 수행할 수 있다.

상기의 것에 대한 대안은 TD*_Target _{_} _RO(408)가 MPIA 및 MPES 대신에 ME의 신뢰성의 간단한 표시를 SDM에 요청하는 것이며, 그 경우에, SDM은 TPIA, TPES, 및 ME 신뢰성 표시를 제공한다. 그렇지만, SDM은 여전히 MPIA 및 MPES를 MTE에 요청하여 수신한다.

여전히 도 4a를 참조하면, 411에서, 메시지

이 전송될 수 있다. 412에서,

메시지가 전송될 수 있다. 428에서, 도메인이 구축되고 구성될 수 있으며, RIM_TDRO와 대조하여 무결성이 검사될 수 있다. 그에 부가하여, TD*_Target _{_} _RO의 소유권이 취득될 수 있고, 따라서 이를 TD_Target _{_} _RO로 변환한다. 413에서, 도메인 완료 메시지가 전송될 수 있다. 414에서, 도메인 완료 메시지가 전송될 수 있다.

도 5 및 도 5a는 (예컨대, 제4 실시예에 관련된) 완전 증명(full attestation)을 갖는 원격 소유권 취득에 대한 예시적인 호 흐름도를 나타낸 것이다. 예를 들어, 도 5 및 도 5a는 SDM(502), TD_DO(504), ME_PDM(506), ME*_Target _{_} _RO(508) 및 대상 RO(510) 중 하나 이상 사이의 예시적인 호를 나타낸 것이다. 도 5 및 도 5a에서의 화살표는 호의 발신지/목적지를 나타낼 수 있다. 51에서, 기본 코드 부트 완료 메시지가 전송될 수 있다. 그에 응답하여, 515에서, THSM은 안전하게 부트될 수 있고, SDM을 포함하는 DO의 도메인을 로드할 수 있다. 52에서, THSM 부트 완료 메시지가 전송될 수 있다. 그에 응답하여, 525에서, ME는 안전하게 부트될 수 있고 - 이는 포함되어 있는 DM의 도메인 ME_PDM을 로드하는 것을 포함할 수 있음 -, 이용가능한 자원을 검사할 수 있다. ME_PDM은 SDP과 부합하는 도메인 정책 및 이용가능한 자원을 지정하는 초기 구성을 제공할 수 있다. 53에서, DM의 도메인(정책 정보) 및 ME 내의 이용가능한 자원을 포함하는, ME 안전 부트가 완료되었다는 메시지가 전송될 수 있다. 531에서, "ME 부트 완료됨" 메시지가 SDM(502)으로 전송될 수 있다. 535에서, SDM(502)은, 예를 들어, 시스템 전체 정책을 평가하고, ME에 대한 허용된 도메인, 자원 및 정책 제한을 결정한다. 54에서, 정책 제한 및/또는 허용된 자원에 관한 정보를 제공하는 메시지가 전송될 수 있다. 545에서, 정책 제한이 기본 정책에 첨부될 수 있고, 필요한 경우, 자원 목록이 수정될 수 있다.

도 5 및 도 5a의 요소(55 내지 511)는 도 4 및 도 4a에 도시된 요소(45 내지 414)와 유사할 수 있다. 값 MPIA 및 MPES의 평가는 식 14 내지 식 19에서의 평가와 유사할 수 있다. ME는 MEM 지원일 수 있고, 원시 데이터 MPID만이 아니라 다이제스트 MPIA를 자체적으로 계산하도록 구성될 수 있다. 어떤 금지된 도메인 또는 도메인 정책이 실현되지 않도록, SDM에 의해 전달되는 업데이트된 정책 제한이 검사될 수 있다. 정책 검사 및 평가가 ME_PDM에 의해 수행될 수 있다.

55에서, 대상 도메인 계획을 포함할 수 있는, RTO를 시작하라는 요청이 전송될 수 있다. 555에서, ME_PDM에 의한 RTO 요청을 수락할지 거부할지의 결정이 행해질 수 있다. 551에서, RTO가 시작되어야만 하는지를 나타내는 메시지가 전송될 수 있다. 대안에서, 556에서, RTO를 시작하려는 의도(intent to start RTO)가 ME 대상에서 발신될 수 있다. 56에서, RTO를 시작하려는 의도 메시지가 전송될 수 있다. 565에서, 하기의 것들이 검사되고 및/또는 평가될 수 있다: 1) 확장된 도메인 정책; 및/또는 2) 확장된 정책에 따른 이용가능한 자원, 허용가능한 자원 및 상태. 561에서, RTO를 시작하는 것이 허용가능하다는 메시지가 전송될 수 있다. 57에서, ME 도메인 세트로부터의 MPIA 및 MPES에 대한 요청이 전송될 수 있다. 575에서, 도메인마다 일정 범위의 PCR에 걸쳐 기존의 도메인으로부터의 무결성 증명(MPIA)의 수집 및 연결은 물론, MPES 정보의 수집 및 연결도 수행될 수 있다. 58에서, MPIA 및 MPES가 전송될 수 있다. 59에서,

요청이 전송될 수 있다(메시지 무결성 및 기밀성이 인증된 공개/비밀 키에 의해 보호될 수 있다). 595에서, 대상 RO(510)는, 예를 들어, MPIA, MPES 및 목적을 검사하는 것; RIM_TSIM과 대조하여 원시 도메인의 신뢰성을 결정하는 것; 허용가능성에 대해 DP를 검사하는 것; 또는 전체 도메인 상태를 구축하기 위해 CONFIG를 생성하는 것 중 하나 이상을 수행할 수 있다. 514에서, 메시지

가 전송될 수 있다. 515에서, 도메인이 구축되고 구성될 수 있으며, RIM_TDRO와 대조하여 무결성이 검사될 수 있다. 그에 부가하여, ME*_Target _{_} _RO의 소유권이 취득될 수 있고, 따라서 이를 ME_Target _{_} _RO로 변환한다. 511에서, 도메인 완료 메시지가 전송될 수 있다(서명되고, 무결성 보호됨). ME는, 도 3 및 도 3a에 도시된 것과 같은 어떤 메시지 전송도 사용되지 않을 수 있도록 그리고 메시지의 수가 감소될 수 있도록, 대상 RO와 직접 통신할 수 있다. ME와 대상 RO 사이에서의 메시징에서 공개/비밀 키 교환을 위한 요구된 인증서에 관한 상세가, 원시 엔진 신뢰성 검증을 위한 RIM 인증서에 관한 상세와 함께, 도 5에 도시되어 있지 않다.

도 6은 THSM의 예시적인 상태 정의, 천이 및 제어점 정의를 나타낸 것이다. 일례로서, PCT 특허 출원 WO 2009/092115(PCT/US2009/031603)에 정의된 정의 및 기본 기능을 갖는 MCIM(M2M Communication Identity Module)에 대한 라이프사이클이 본 명세서에 정의되어 있다. THSM은 MCIM의 상태 정의 및 천이를 비롯한 기능 및 특징을 개선시키고 일반화시킬 수 있다.

601에서, THSM은 부트전 상태에 있을 수 있다. 제1 사용자는 THSM의 전원을 켤 수 있고, THSM은 안전하게 부트될 수 있으며, THSM은 상태(602)에 있을 수 있다. 602에서, DM 및 DO가 원시 상태에 존재할 수 있다. DM 도메인이 사전-구성된 파일로부터 구축될 수 있고, THSM이 상태(606)에 있을 수 있다. 606에서, THSM이 부트후(post boot) 2 상태에 있고, 여기서 TD_DM이 로드될 수 있다. 606으로부터, DO 도메인이 사전 구성된 또는 다운로드된 파일로부터 구축될 수 있고, THSM을 상태(605)에 놔둘 수 있다. 605에서, THSM은 부트후 3 상태에 있을 수 있고, 여기서 TD_DO 도메인이 구축될 수 있지만, TD_U 또는 TD_RO는 로드되지 않을 수 있다. 상태(605)로부터, DO의 도메인(SDM)은 사용자의 도메인을 로드할 수 있고, THSM을 상태(604)에 놔둘 수 있다. 604에서, THSM은 부트후 상태 2a에 있을 수 있고, 여기서 TD_U가 로드되지만 RO 도메인은 로드되지 않을 수 있다. 상태(605)로부터, 원시 RO 도메인이 SDP에 기초하여 구축될 수 있고, THSM을 상태(607)에 놔둘 수 있다. 607에서, THSM은 부트후 상태 7에 있을 수 있고, 여기서 TD_RO 및 TD_DO는 로드되었지만 TD_U는 로드되지 않을 수 있다. 상태(607)로부터, TD_DO(SDM)은 TD_U를 로드할 수 있고, THSM을 상태(608)에 놔둘 수 있다. 608에서, THSM은 DO, DU 및 RO 도메인을 로드할 수 있다.

상태(601)로부터, 사용자는 전원을 켤 수 있고, THSM은 안전하게 부트될 수 있으며, THSM을 상태(603)에 놔둘 수 있다. 603에서, 저장된 구성이 THSM에 로드될 수 있고, 여기서 저장된 구성은 가장 최근의 전원 꺼짐 이전의 구성이다. 상태(603)로부터, 구성을 변경하는 부트후 트랜잭션이 일어날 수 있고, THSM을 상태(610)에 놔둘 수 있다. 610에서, THSM은 하나 이상의 이전에 활성이었던 상태가 비활성으로 되는 상태에 있다. 603으로부터 상태(610)에 도달하는 프로세스와 유사하게, THSM은 상태(609)에 있을 수 있고, 여기서 THSM은 하나 이상의 활성 도메인을 가진다. 상태(609)로부터, 구성 변경 이벤트의 결과로서 천이가 일어날 수 있고, THSM을 다시 상태(610)에 놔둘 수 있다.

상태(604, 605, 607, 608)에서, THSM이 새로운 정책 및/또는 실행 파일로 재구성될 수 있거나, 비활성 상태로 천이할 수 있다. 그에 부가하여, 상태(605)에서, SDP가 저장될 수 있다.

제1 도메인 관리 방법에서, 도메인 소유자로부터의 정책, 즉 SDP(system-wide domain policy)는 아주 제한적이고 "정적"일 수 있으며, 새로운 도메인 활동 또는 목적에 관한 까다로운 규칙을 가질 수 있다. 이들 정책은 모든 새로운 도메인 항목 또는 기존의 도메인 업데이트를 RO로 전달할 필요성을 완화시키는 경향이 있다.

제2 도메인 관리 방법에서, SDP는 덜 제한적일 수 있고, 활동 및 목적과 관련하여 더 많은 유연성을 가능하게 해준ㄷ나. 모든 새로운 도메인 항목 및 모든 도메인 변경이 기존의 도메인 소유자에게 보고될 수 있다. 이 결과, 플랫폼과 RO 간의 초기 및 후속 협상이 일어날 수 있는 보다 동적인 정책 시행 시스템이 얻어질 수 있다.

제1 도메인 관리 방법을 참조하면, SDP는 사전 구성된 목록에서 예외 없이 허용되는 도메인을 지정할 수 있다. 이 목록은 RO의 유형 및 (각각의 유형에 대해) 몇개가 허용되는지에 관한 정보를 포함할 수 있다. 이 목록은 또한 RO가 그의 도메인이 설정된 경우 제공할 수 있는 서비스의 종류를 포함할 수 있다. 예상된 RO는 목록이 나타내는 기준을 충족시키는 것일 수 있다. RO가, 예를 들어, 식 9에 나타낸 바와 같이, 목록 및 정책 제약조건 등의 조건에 관한 RTO 프로세스의 일부로서 통지될 수 있다. RO는, SCARD의 수신 시에, 문제의 플랫폼 또는 장치 상의 이해관계자이고자 하는지 여부를 독립적으로 결정할 수 있다. RO로 전송된 조건은 도메인 유형 및 그의 목적을 포함할 수 있지만, 다른 RO의 ID를 보호하기 위해, 임의의 다른 RO의 목록의 실제 이름을 포함하지 않을 수 있다. RO가 RTO를 완수하기로 결정하는 경우, 정책으로부터의 어떤 벗어남도 이 RO 또는 플랫폼 상의 현재 활성인 임의의 다른 RO, 또는 장래에 활성으로 될 수 있는 임의의 다른 RO에 의해 허용되지 않도록 할 수 있다. 그 결과, RO는 일어날지로 모르는 후속 RTO에 대해 통지받을 필요가 없을 수 있고 통지받지 않을 수 있다.

제2 도메인 관리 방법을 참조하면, 임의의 특정의 RO 유형을 식별하지 않고 어떤 원격 소유자가 허용되는지 등의 단지 비교적 넓은 제한, 및 RO로부터 SDM으로의 추가 정보에 대한 요청 또는 어떤 협상 등의 추가의 상호작용을 가능하게 해주는 정책이 RTO 프로세스 동안 수행될 수 있다. 또한, 도메인 구성이 변할 때, SDM과 모든 RO 사이에 진행 중인 공동 작업이 있을 수 있다. 따라서, 초기 협상, 및 심지어 후속 협상이 RO/SDM 동작의 일부로서 행해질 수 있다.

RTO 프로세스의 일부로서, RO는 TPIA, TPES 및 SCARD 등의 필요로 하는 증명 및 정책 조건 정보 - 제1 방법의 경우와 비교하여 구성 및 그의 신뢰성에 관한 보다 일반적인 정보를 포함할 수 있음 - 를 제공받을 수 있다. 기존의 도메인 구성에 기초하여, 대상 RO는 RTO를 계속할지 여부를 결정할 수 있다. 대상 RO가 소유권을 취득하지 않기로 즉각 결정하지 않는 한, SDM과의 협상 프로세스가 뒤따를 수 있다. 예를 들어, SDM은 대상 RO의 도메인이 활성인 동안 어떤 도메인 유형 및 부속 서비스가 활성인지, 또는 반대하는 도메인 유형이 활성으로 되는 경우 어떤 절차를 수행할지를 대상 RO에 요구할 수 있다. RO는, 예를 들어, 어떤 다른 도메인 유형 또는 심지어 어떤 다른 RO의 소유인 도메인이 활성으로 되거나 활성으로 될 예정일 때 그 자신의 도메인이 비활성으로 될 것을 필요로 할 수 있거나, 자신의 도메인이 활성이지만 감소된 용량 또는 능력에 있을 것을 필요로 할 수 있다. SDM은 또한 어느 것에 대해 어떤 이벤트 발생을 통지받아야 하는지를 RO에 요청할 수 있다. 이러한 이벤트는 반대하는 도메인 유형이 활성 또는 비활성으로 되는 것을 포함할 수 있다. RO는, 그 자신의 도메인이 활성일 때, 다른 도메인 유형 또는 어떤 다른 소유자가 보유하는 도메인이 모든 활동으로부터 완전히 차단될 것을 필요로 할 수 있다.

SDM은 이러한 조건을 수락하거나 거부하기로 결정할 수 있다. 광범위한 일련의 정책 요구사항에 따라 동작하지만, SDM은 RO로부터의 요구를 받아들이는 것이 여전히 "정적" SDP(System Domain Policy)의 의도 또는 자구에 부합할 수 있는지를 결정하는 허용 범위 및 의미론적 능력(semantic capability)을 가질 수 있다.

도 7은 RO 도메인이 달성할 수 있는 예시적인 상태 및 동적으로 관리되는 환경에서 천이가 일어날 수 있는 조건을 나타낸 것이다. 701에서, 널 상태가 존재할 수 있다(예컨대, RO가 구축되어 있지 않을 수 있다). 701로부터, 원시 RO 도메인이 SDP에 따라 구축될 수 있고, RO 도메인을 상태(702)에 놔둘 수 있다. 702로부터, RO가 TPIA, TPES 및 SCARD를 획득하는 것을 비롯한 RTO 프로세스가 수행될 수 있다. 게다가, RO는 RTO의 조건을 수락할 수 있고, RO 도메인을 상태(703)에 놔둘 수 있다. 703으로부터, 새로 활성인 도메인과 정책 충돌이 있는지가 결정될 수 있고, 그에 응답하여, RO 도메인의 기능을 감소시키거나 RO 도메인을 비활성으로 만들고, RO 도메인을 상태(704)에 놔둘 수 있다. 또한, 703으로부터, RO 도메인은 업데이트된 정책/구성 변경을 수신할 수 있고, 그 결과 RO 도메인은 수정된 구성 및/또는 업데이트된 정책 제한을 가질 수 있다. 706으로부터, 새로 활성인 도메인과 정책 충돌이 있는지가 결정될 수 있고, 그에 응답하여, RO 도메인의 기능을 감소시키거나 RO 도메인을 비활성으로 만들고, RO 도메인을 상태(704)에 놔둘 수 있다. 또한, 703으로부터, 새로운 소프트웨어 구성요소가 다운로드 또는 RTO를 통해 도입될 수 있고, 그 결과 RO 도메인의 수정된/확장된 상태가 얻어지고, RO 도메인을 705에 놔둘 수 있다. 705로부터, 새로 활성인 도메인과 정책 충돌이 있는지가 결정될 수 있고, 그에 응답하여, RO 도메인의 기능을 감소시키거나 RO 도메인을 비활성으로 만들고, RO 도메인을 상태(704)에 놔둘 수 있다.

711에 나타낸 바와 같이, 상태(702, 703, 704, 705 또는 706)에 있는 RO 도메인이 널(null)로 될 수 있다(예를 들어, DO, RO 등에 의해 삭제됨). 741에 나타낸 바와 같이, 비활성/감소된 기능의 RO 도메인이, 예를 들어, RO 도메인을 상태(704)로 가게 한 충돌을 해결함으로써, 상태(703, 705 또는 706)로 이동할 수 있다. 751에 예시된 바와 같이, 상태(705)에 있는 RO 도메인이 상태(703, 704 또는 706)로 이동할 수 있다. 761에 예시된 바와 같이, 상태(706)에 있는 RO 도메인이 상태(703, 705 또는 706)로 이동할 수 있다.

RO 도메인의 관리와 관련하여, 동적 도메인 곤리의 일부로서 허용될 수 있는 것은 이벤트가 나타날 때 변경할 요구사항을 협상하는 것이다. 예를 들어, RO는 이전에 못마땅했던 다른 RO에 의해 제공되는 어떤 서비스가, 더 이상 그 서비스와 경쟁할 필요가 없는 것으로 결정한 결과로서, 이제 허용되는 것으로 결정할 수 있다. 시간의 경과에 따른 비즈니스 모델에 대한 변경은 예상된 RO에 의한 전략 및 정책을 협상하는 것에 영향을 미칠 수 있다. 동적 정책 구조를 이용하는 SDP는 이러한 전략 변경에 대응하도록 되어 있을 수 있다.

스마트-대금 청구(smart-billing)와 결합된 M2M 위치 추적(이들로 제한되지 않음) 등의 서비스에서, 바람직한 로밍 파트너쉽 또는 폐쇄된 RO 그룹이 형성될 수 있다. 이러한 그룹화된 서비스는, 유사하거나 상이한 서비스를 제공하는 상이한 통신사업자가 서로 제휴하는 경우, 바람직한 폐쇄된 그룹을 가져올 수 있다. 이러한 바람직한 서비스 그룹, 통신사업자 그룹, 또는 둘 다가 번들형 서비스 또는 패키지 거래(package deal)로서 장치 사용자에게 제공될 수 있다.

제1 일례에서, 패키지가 전 세계에 걸쳐 이동될 때 추적될 수 있다. 수백만의 이러한 위치-추적 장치가 이용될 수 있다. 패키지가 대륙을 건너갈 때, 패키지는 상이한 국가에 있는 상이한 통신사업자에 의해 연결을 제공받는다. 따라서, 연결을 획득하기 위해, 사용자는 다수의 로밍 프로파일에 가입할 필요가 있을 수 있다. 다양한 원격 통신 사업자에 걸쳐 있는 이들 로밍 프로파일이 도메인간 정책으로서 관리될 것인데, 그 이유는 각각의 도메인이 원격 소유자에 의해 소유되고 관리되기 때문이다. 이들 정책은 또한, 로밍 기반 해결 방안을 지원하는 대신에, 새로운 서비스 공급자로의 완전 핸드오버를 지원하도록 시행될 수 있다.

제2 일례에서, 스마트 계량 통신사업자와 위치 추적 통신사업자 간의 파트너쉽이 기술되어 있다. 이들 도메인은 상이한 통신사업자에 의해 소유되고 운영될 수 있다. 비즈니스 파트너쉽 또는 사용자 기본 설정으로 인해, 결합 프로파일(joint profile)을 지원하기 위해 도메인이 결합될 수 있다. 노동력, 저장소, 또는 주차 등의 자원의 사용에 기초한 요금 청구의 경우, 패키지의 추적과 함께 스마트 요금 청구가 사용될 수 있다. 개별 카테고리에 속하는 공존하는 서비스의 이러한 경우는 도메인간 정책 관리자의 지원을 사용할 수 있다.

IDPM(Inter Domain Policy Manager)은 도메인의 그룹 거동을 규율하는 정책을 관리할 수 있다. IDP(Inter Domain Policy)는 RTO 프로세스 동안 각각의 RO에 의해 다운로드될 수 있다. IDP가 각각의 RO에 의해 서명되는 인증서에 의해 인증될 수 있다. 이들 인증서가 IDP와 함께 발행될 수 있다. 다른 대안으로서, 이들 정책이 외부 서비스 대리점(service dealer)에 의해 인증되고 다운로드될 수 있다. 바람직한 통신 사업자 목록을 생성하는 데 관심이 있는 장치 사용자 또는 장치 소유자가 IDP를 생성할 수 있다. IDPM은 후보 정책들의 허용가능한 교집합을 평가하거나 IDP의 우선 순위를 선택하고 이어서 얻어진 우선순위를 시행함으로써 이들 정책을 처리할 수 있다.

IDPM이 다른 대안으로서 그의 기능 중 하나로서 또는 THSM 상에 로드(구축)되거나 다운로드될 수 있는 별도의 엔터티로서 SDM에 부가될 수 있다.

증명 프로토콜의 일부로서, TD_RO는, 이들 측정을 전체적으로 전송하는 대신에, TPIA, TPES, 및 SCARD의 해시를 RO로 전송할 수 있다. RO는, 자체적으로 또는 TTP에 의해, 이러한 해시를 검증하고 그에 의해 TDRO 및 주변 시스템의 생존성(viability)을 평가하는 수단을 가질 수 있다. 이 방법은, PCT 특허 출원 WO 2009/092115(PCT/US2009/031603)에 언급된 바와 같은 SAV(Semi Autonomous Validation)와 유사할 수 있다. TPIA, TPES, 및 SCARD 측정 중 임의의 1개 또는 2개의 측정이 증명 단계 동안 송출될 수 있다.

THSM이 ME의 일부로서 일체로 내장될 수 있다. 이러한 장치에 대한 RTO 프로세스가 간단화될 수 있는데, 그 이유는 이 프로세스가 ME와 THSM 사이의 인터페이스를 제거할 것이기 때문이다.

이상에서 특징 및 요소가 특정의 조합으로 기술되어 있지만, 각각의 특징 또는 요소가 다른 특징 및 요소 없이 단독으로 또는 다른 특징 및 요소를 갖거나 갖지 않는 다양한 조합으로 사용될 수 있다. 본 명세서에 제공된 방법 또는 플로우차트는 범용 컴퓨터 또는 프로세서에서 실행하기 위해 컴퓨터 판독가능 저장 매체에 구현되어 있는 컴퓨터 프로그램, 소프트웨어, 또는 펌웨어로 구현될 수 있다. 컴퓨터 판독가능 저장 매체의 일례로는 ROM(read only memory), RAM(random access memory), 레지스터, 캐시 메모리, 반도체 메모리 장치, 내장형 하드 디스크 및 이동식 디스크 등의 자기 매체, 광자기 매체, 그리고 CD-ROM 디스크 및 DVD(digital versatile disk) 등의 광 매체가 있다.

적당한 프로세서는, 일례로서, 범용 프로세서, 전용 프로세서, 종래의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서, DSP 코어와 연관된 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, ASIC(Application Specific Integrated Circuit), FPGA(Field Programmable Gate Array) 회로, 임의의 다른 유형의 IC(integrated circuit), 및/또는 상태 기계를 포함한다.

소프트웨어와 연관된 프로세서는 WTRU(wireless transmit receive unit), UE(user equipment), 단말기, 기지국, RNC(radio network controller), 또는 임의의 호스트 컴퓨터에서 사용하기 위한 무선 주파수 송수신기를 구현하는 데 사용될 수 있다. WTRU는 하드웨어 및/또는 소프트웨어로 구현된 모듈[카메라, 비디오 카메라 모듈, 비디오폰, 스피커폰, 진동 장치, 스피커, 마이크, 텔레비전 송수신기, 핸즈프리 헤드셋(hands free headset), 키보드, Bluetooth® 모듈, FM(frequency modulated) 라디오 유닛, LCD(liquid crystal display) 디스플레이 유닛, OLED(organic light-emitting diode) 디스플레이 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저, 및/또는 임의의 WLAN(wireless local area network) 또는 UWB(Ultra Wide Band) 모듈 등]과 관련하여 사용될 수 있다.

II . 가입-기반 서비스에 액세스하기 위한 등록 및 크리텐셜 롤아웃

장치의 사용자는 가입-기반 서비스의 공급자와 가입 관계를 생성하고자 할 수 있다. 예를 들어, 도 1의 장치(100, 110, 또는 120) 또는 도 2의 UE(200) 등의 UE의 사용자는 원격 소유자에 의해 제공되는 가입-기반 서비스의 가입된 사용자로서 등록하고자 할 수 있다. 가입-기반 서비스의 제공은 제3자에 의해 용이하게 될 수 있다(예컨대, 제3자가 원격 소유자를 대신하여 가입-기반 서비스를 사용자에게 판매할 수 있다). RTO 프로세스와 관련하여 앞서 기술한 바와 같이, 원격 소유자는 원격 소유자 도메인이라고 할 수 있는 장치 상의 도메인의 소유권을 취득할 수 있다. 게다가, 사용자는 사용자 도메인(user domain)이라고 할 수 있는 장치 상의 도메인의 소유권을 취득했을 수 있다.

사용자가 가입-기반 서비스에 액세스하기 위해, 등록 및 크리텐셜 롤아웃이 행해질 필요가 있을 수 있다. 등록 및 크리텐셜 롤아웃은 사용자를 가입-기반 서비스의 가입된 사용자로서 원격 소유자에 등록하는 것 - 이 경우, 이러한 서비스는 원격 소유자 도메인을 통해 원격 소유자에 의해 렌더링될 수 있음 -, 사용자가 가입된 사용자로서 가입-기반 서비스를 사용할 수 있게 해줄 수 있는 크리텐셜을 원격 소유자로부터 획득하는 것, 및/또는 크리텐셜을 원격 소유자 도메인에 저장하는 것 중 하나 이상을 포함할 수 있다. 크리텐셜은 사용자가 장치를 통해 가입-기반 서비스를 사용할 수 있게 해줄 수 있다. 크리텐셜이라는 용어는 종래의 크리텐셜(예컨대, 키, ID, 인증서 등)을 포함할 수 있다. 크리텐셜이라는 용어는 가입 관리 기능을 위해 사용되는 다른 상황-관련 데이터 및 응용 프로그램(실행 파일 및 애플릿 등)을 포함할 수 있다.

본 명세서에 개시된 시스템 및 방법은 사용자가 하나의 장치 또는 여러 장치를 통해 다수의 가입-기반 서비스에 액세세스할 수 있는 것을 생각하고 있다. 예를 들어, 도 1 및 도 2와 관련하여 또한 RTO 프로세스와 관련하여 앞서 기술한 바와 같이, 장치가 상이한 원격 소유자에 의해 소유될 수 있는 다수의 도메인을 가질 수 있다. 사용자는 다수의 원격 소유자로부터의 다수의 가입-기반 서비스에 가입할 수 있다.

원격 소유자가 원격 소유자 도메인의 소유권을 취득하고 나서 오랜 시간 후에 등록 및 크리텐셜 롤아웃이 행해질 수 있다. 무선 전화 기능을 갖는 무선 장치가 일례로서 사용될 수 있다. 다수의 무선 통신사업자가 장치 상의 다수의 도메인의 소유권을 취득할 수 있다(예컨대, 각각의 무선 통신사업자가 원격 소유자임). 예를 들어, 무선 통신사업자 1은 원격 소유자 도메인 1의 소유권을 취득할 수 있고 무선 통신사업자 2는 원격 소유자 도메인 2의 소유권을 취득할 수 있다. 그렇지만, 사용자는 무선 통신사업자 2가 아니라 무선 통신사업자 1의 가입-기반 서비스(예컨대, 무선 전화 서비스)에 관한 등록 및 크리텐셜 롤아웃을 개시했을 수 있다. 예를 들어, 무선 통신사업자 1은 무선 통신사업자 2보다 전체 무선 전화 서비스에 관한 더 나은 거래를 사용자에게 제공했을 수 있다. 나중에(예컨대, 수일, 수개월, 수년 후에), 사용자는 무선 통신사업자 2의 가입-기반 서비스(예컨대, 무선 전화 서비스)에 관한 등록 및 크리텐셜 롤아웃을 개시할 수 있다. 예를 들어, 무선 통신사업자 2는 이제 무선 통신사업자 1보다 장거리 통화에 관한 더 나은 거래를 제공할 수 있다. 사용자는 양쪽 가입-기반 서비스를 사용할 수 있는데, 그 이유는 등록 및 크리텐셜 롤아웃이 둘 다에 대해 완료되었기 때문이다. 예를 들어, 사용자는 시내 통화를 위해서는 무선 통신사업자 1의 무선 전화 서비스를 사용할 수 있고, 장거리 통화를 위해서는 무선 통신사업자 2의 무선 전화 서비스를 사용할 수 있다. 이 일례는 어느 원격 소유자도 이러한 구성을 금지하는 설정 규칙을 가지고 있지 않은 것으로 가정하고 있다(예컨대, RTO 프로세스를 참조). 이 일례는 또한 원격 소유자가 원격 소유자 도메인의 소유권을 취득하고 나서 오랜 시간 후에 등록 및 크리텐셜 롤아웃이 행해질 수 있다는 것을 나타내고 있다.

등록 및 크리텐셜 롤아웃 프로세스에 포함된 엔터티는 사용자, 사용자 도메인, 원격 소유자, 원격 소유자 도메인, 제3자, 또는 반자율적 유효성 검사를 용이하게 해주는 구성요소(예컨대, 시스템 전체 도메인 관리자) 중 하나 이상을 포함하고 있다. 등록 및 크리텐셜 롤아웃과 관련하여, 엔터티는 다음과 같은 속성을 가질 수 있다.

사용자는 가입-기반 서비스 등의 서비스에 가입하고자 하는 장치의 사용자일 수 있다. 이러한 가입-기반 서비스의 일례는 금융 서비스, 셀룰러 통신 서비스, 인터넷 연결 서비스, 음악/비디오/멀티미디어 가입 서비스, ID 서비스, 위치-기반 서비스, 이메일/메시지/소셜-네트워킹 서비스, 전자책 서비스, 게임 서비스 등을 포함할 수 있지만, 이들로 제한되지 않는다. 사용자는 또한 장치의 소유자일 수 있다. 사용자는 등록 및 크리텐셜 롤아웃을 개시할 수 있다. 이 개시는 사용자가 개인 데이터 및/또는 종래의 로그인 정보를 전송하는 것을 포함할 수 있다. 사용자는 또한, 예컨대, 사용자가 가입되어 있는/가입하고 있는 가입-기반 서비스와 연관된 동작에 관련되어 있을 때 가입자라고도 할 수 있다.

사용자 도메인(TU_u)은 사용자 기능에 관련된 장치 상의 도메인일 수 있다. 사용자 도메인은 선택적인 도메인일 수 있다. 사용자 도메인은 본 명세서에 기술되어 있는 바와 같이(예컨대, 도 2 참조) THSM의 일부일 수 있다. 사용자 도메인이 플랫폼의 초기 부트 시퀀스 동안 생성되고 그의 기능을 제공받을 수 있다. 소유자 도메인(TD_O)은 사용자 도메인을 포함하지 않는 구성에 대해 TD_U의 기능을 수행할 수 있다. 사용자는 사용자 이름(ID_U), 비밀번호(PW_U) 및 개인 등록 데이터(REGDATA_U)를 제공함으로써 TD_U에의 등록을 개시할 수 있다. TD_U는 사용자 등록의 일부로서 프로세스 ID(PID_U)를 발생할 수 있다. 이 정보는 등록을 개시하고 크리텐셜 롤아웃을 요청하는 데 사용될 수 있다. 예를 들어, 이 정보는 특정의 요청(예컨대, 특정의 등록 및/또는 크리텐셜 롤아웃 요청)과 연관될 수 있고, 등록 및/또는 크리텐셜 롤아웃에 대한 상이한 세션 또는 프로세스를 구별하거나 표시하는 데 사용될 수 있다. 사용자 및 사용자 도메인은 ME를 통해 통신할 수 있다. 사전-프로비저닝된 키 K_{temp_C}(예컨대, 기밀성을 위한 것임) 및 K_temp _{_I}(예컨대, 무결성/인증을 위한 것임)가 ME/THSM 인터페이스를 통한 메시징을 보호하는 데 사용될 수 있다. ME/THSM 인터페이스를 통한 메시징을 보호하기 위해 비대칭 키 쌍이 사용될 수 있다. ME가 도 8과 관련하여 도시되어 있지 않을 수 있다. THSM과의 사용자 통신은 TD_U를 통해 행해질 수 있다.

원격 소유자(RO)는 장치를 통해 사용자에게 가입형 서비스를 제공할 수 있다. 원격 소유자는 사용자가 가입형 서비스를 사용하기 위해 필요할 수 있는 크리텐셜을 제공할 수 있다. 크리텐셜은 원격 소유자 도메인과 원격 소유자 사이의 강력한 비밀로서 역할할 수 있는 인증 키 K를 포함할 수 있다. 일례로서, RO는 MNO, 다른 통신 네트워크 통신사업자(예컨대, WLAN, WiMax 등), 이메일 서비스 공급자, 인터넷 서비스 공급자, 소셜-네트워킹 서비스 공급자, 디지털 콘텐츠(음악, 전자책, 비디오 등) 공급자, 게임 서비스 공급자, 금융 서비스 공급자, 응용 프로그램 서비스 공급자(예컨대, 모바일 결제, 모바일 티켓팅, DRM, 모바일 TV, 위치-기반 서비스 등에서의 서비스 공급자) 또는 IMS 서비스 공급자 등 중 하나 이상일 수 있다.

원격 소유자 도메인(TD_RO)은 원격 소유자에 의해 정의된 기능을 제공할 수 있는 장치 상의 도메인일 수 있다. 원격 소유자 도메인은 앞서 기술되어 있는 바와 같이(예컨대, 도 2 참조) THSM의 일부일 수 있다. 원격 소유자 도메인은 앞서 기술된 RTO 프로세스와 관련하여 기술된 바와 같은 TSIM 기능을 가질 수 있다. 원격 소유자 도메인은 원격 소유자에 의해 제공되는 크리텐셜을 저장할 수 있다. TD_RO는 사용자의 ID 및 프로세스 ID(ID_U, PID_U)를 사용자 도메인으로부터 수신할 수 있고, 등록 및 크리텐셜 롤아웃 동안 이 정보를 다양하게 사용할 수 있다.

POS(point of sale 또는 point of service entity)는 사용자에의 가입 기반 서비스의 판매/서비스 제공을 용이하게 해주는 제3자일 수 있다. POS는 도 8과 관련하여 기술된 바와 같이 티켓을 통한 판매를 용이하게 해줄 수 있다. 일례로서, POS는 원격 소유자의 가입-기반 서비스를 판매하는 및/또는 그의 판매전 및 판매후 고객 서비스 의무를 수행하는 소매점(온라인, 오프라인 등)일 수 있다.

SDM(system wide domain manager)(예컨대, 섹션 I에 개시된 SDM)은 등록 및 크리텐셜 롤아웃의 일부로서 하나 이상의 플랫폼에 관련된 증명 정보를 제공할 수 있다. 예를 들어, 등록 및 크리텐셜 롤아웃 동안 요청 시에, 반자율적 무결성 확인이 SDM에 의해 제공될 수 있다. SDM은 도메인의 구성요소 등의 THSM의 일부일 수 있다(예컨대, 도 2 참조).

등록 및 크리텐셜 롤아웃은 다음과 같은 것들 중 하나 이상을 포함할 수 있다:

- POS가 티켓을 사용자와 연관시킬 수 있다. 티켓은 사용자의 ID를 설정할 수 있고, 크리텐셜에 대한 요청이 행해질 때 원격 소유자에게 제시될 수 있다. 사용자에게 제공되는 티켓 등의 티켓은 (예컨대, 사전 발생된 세트로) RO에 의해 POS로 분배될 수 있다. 티켓은 등록 및 크리텐셜 롤아웃 프로세스에서 사용될 정보를 포함할 수 있다. 예를 들어, 이 정보는 "3중항(triple)" 포함할 수 있고, 이 3중항은 식별자(예컨대, IMSI), 예컨대, 크리텐셜에 대한 요청이 행해질 때, 원격 소유자에게 챌린지 숫자(challenge number)로서 역할할 수 있는 난수(RAND), 및 티켓 인증 값(AUTH)을 포함한다.

- 사용자 도메인이, 사용자를 대신하여, 등록을 요청할 수 있다.

- POS가 사용자의 ID를, 사용자의 연관된 개인 등록 데이터와 함께, 원격 소유자에게 보고할 수 있다[예컨대, 분배된 티켓이 IMSI(International Mobile Subscriber Identity) 등의 식별자를 제공할 수 있다].

- 사용자는 식별자(예컨대, IMSI)를 사용하여 크리텐셜 롤아웃을 요청할 수 있다.

- 가입 서비스에 액세스하기 위해 사용될 수 있는 크리텐셜이 장치로(예컨대, 원격 소유자 도메인으로) 전달될 수 있다. 원격 소유자 도메인은 가입 서비스를 관리하는 데 TSIM 기능을 제공할 수 있다.

등록 및 크리텐셜 롤아웃이 안전한 방식으로 행해질 수 있다. 사용자 등록 및 크리텐셜 롤아웃이 안전한 방식으로 행해지도록 이하의 전제조건 중 하나 이상이 만족되고 및/또는 가정될 수 있다.

- THSM/ME 플랫폼이 신뢰할 만한 상태에 있는 것으로 간주될 수 있고, RTO(remote take ownership) 프로토콜을 통해 이미 구성되는 도메인을 갖는 원격 소유자의 요청 시에 플랫폼 구성의 상태 또는 그의 일부분을 보고할 수 있다. 이 장치는 "완전히 신뢰성 있는" 플랫폼 구성요소인 것으로 간주되지 않을 수 있는 ME를 포함할 수 있다. ME의 신뢰성이 THSM에 의해 주기적으로 모니터링될 수 있다. ME와 THSM을 연결시키는 인터페이스는 일반적으로 안전한 것으로 간주되지 않을 수 있다. ME가 완전 MTM 기능을 갖고 그의 무결성을 증명할 수 있는 것으로 가정될 수 있다.

- 다음과 같은 방식들 중 하나 이상의 방식으로 구현될 수 있는 플랫폼의 증명:

o TPIA, TPES, 및 SCARD의 사용을 포함하는 증명 보고(예컨대, RTO 프로세스 참조),

o 현재 구성의 해시를 RO로 전송하는 것을 포함할 수 있는 원격 유효성 검사의 스케일링된 버전, 대량의 데이터의 전송을 피하려고 할 때 이 유형의 증명이 이용될 수 있다.

o 내부 무결성 검사를 수행하는 것, 및 플랫폼이 안전하다는 확인을 제공하는 것을 포함할 수 있는 반자율적 유효성 검사.

- 크리텐셜이 원격적으로 다운로드될 수 있다. POS는 사용자를 원격 소유자에 등록시키는 데 참여할 수 있다. POS와의 통신이 다음과 같은 방식들 중 하나 이상의 방식으로 행해질 수 있다.

o 사용자는 그의 ID 정보 및 등록 데이터를 전송할 때 공중을 통해(OTA) 또는 인터넷 링크를 통해 POS와 통신할 수 있다.

o 사용자가 핸드셋을 사용하여 등록 로그인 단계를 완료한 후에, 사용자 도메인은 등록 및 크리텐셜 롤아웃 프로세스와 관련하여 인터넷을 통해 POS와 통신할 수 있다.

- POS는 티켓 분배 기능을 처리하기에 충분히 신뢰할 만한 것으로 간주될 수 있다. 그에 따라, POS는 연관된 인증서 Cert_POS를 갖는 K_POS _- _Priv 및 K_POS _- _Pub로 표시되는 인증된 키 쌍 세트를 가지고 있을 수 있다. 이들은 연관된 인증서 Cert_RO 및 Cert_TSIM을 각각 갖는 원격 소유자에 대한 키 세트(K_RO _{_} _Priv, K_RO _{_} _Pub) 및 TSIM에 대한 키 세트(K_TSIM-Priv, K_TSIM-Pub)와 관련하여 등록 및 크리텐셜 롤아웃에서 사용될 수 있다.

- 사용자와 사용자 도메인 사이의 통신은 중개자로서 ME를 사용하는 것을 가정할 수 있고, 여기서 사용자가 사용하도록 의도되어 있는 메시지는 핸드셋의 화면 상에 디스플레이된다. 이들 메시지는 각각 무결성 및 기밀성 보호를 위한 임시 키 K_{temp_I} 및 K_temp _{_C}를 이용할 수 있고, ME는 사용자를 위해 해석(예컨대, 서명을 복호화 및/또는 검증)할 수 있다.

- 등록 및 크리텐셜 롤아웃은 동일한 사용자 또는 어쩌면 다수의 사용자로부터 다수의 등록 및 크리텐셜 요청을 가능하게 해줄 수 있을 정도로 유연할 수 있다. 일례로서, 각각의 사용자는 주어진 신뢰성 있는 도메인(TD_RO)에 대해 하나의(단 하나의) 등록을 설정할 수 있지만, 다수의 이러한 도메인에 걸쳐 다수의 등록을 설정할 수 있다. 그렇지만, 다수의 상이한 사용자 각각이 하나의 이러한 도메인에 대해 그 자신의 등록을 가질 수 있다. 각각의 TD_RO는 하나의 RO를 가질 수 있지만, RO는 다수의 등록(각각의 등록이 상이한 사용자에 대한 것임)을 관리할 수 있다. 주어진 RO가 2개 이상의 TD_RO를 소유하는 것도 가능할 수 있다. 어쩌면 다수의 원격 소유자에 대응하는 다수의 사용자 및 신뢰성 있는 도메인이 주어진 경우, 프로세스 ID가, 예컨대, 사용자 도메인, POS 및 원격 소유자에 의해 발생될 수 있고, 다수의 등록에 관한 모호성을 방지하는 데 사용될 수 있다. 주어진 등록 및 크리텐셜 요청에 대해, 밀접하게 연관되어 있는 3개의 프로세스 ID가 발생될 수 있다: PID_U(사용자 도메인에 의해 발생됨), PID_POS(POS에 의해 발생됨), 및 PID_RO(원격 소유자에 의해 발생됨). PID_U는, 사용자 도메인을 식별하기 위해 POS 또는 원격 소유자와 통신할 때, THSM 내의 엔터티에 의해 사용될 수 있다. 이들 ID는 주어진 등록 프로세스를 일의적으로 식별하기에 충분할 수 있다.

- 신뢰성 있는 엔터티들 간의 통신이 공개-비밀 키 쌍을 사용하여 보호될 수 있고, 여기서 공개 키는 인증 기관(certificate authority, CA)에 의해 발행된 인증서를 통해 배포될 수 있다.

- 등록 및 크리텐셜 롤아웃 동안, 재전송 공격을 방지하기 위해 넌스가 이용될 수 있다. 넌스는 연속적으로 번호가 부여되어 있을 수 있거나, 다른 방식으로 순차적으로 정렬되어 있을 수 있거나, 연속적이거나 다른 방식으로 순차적으로 정렬된 숫자를 포함할 수 있다. 어떤 내부의 도메인간 상호작용은, 설명적 넌스 지정(descriptive nonce designation)이 사용되는 경우, 연속적으로 번호가 부여되지 않을 수 있다. 2개의 엔터티 간의 왕복 통신(round trip communication)의 경우, 전송된 제1 넌스는 반환 메시지에서 새로운 넌스(평문으로 되어 있음)와 함께 그의 발신지로 다시 전송될 수 있다(평문으로 되어 있지 않음). 반환 넌스를 수신하는 엔터티는, 값이 처음에 반환 넌스에 의해 생성되었고 따라서 알려져 있을 수 있는 경우, 반환 넌스를 평문으로 전송할 필요가 없을 수 있다.

- 서명이, 예를 들어, 미지정된 버전의 SHA 알고리즘(본 명세서에서 SHA-X라고 표시될 수 있음)에 의해 계산되는 고정된 비트 길이의 암호 해시 값에 적용될 수 있다.

등록 및 크리텐셜 롤아웃을 예시하는 방법이 이제부터 도 8을 참조하여 설명될 수 있다. 도 8은 등록 및 크리텐셜 롤아웃(credential roll-out) 프로세스를 구현하는 예시적인 호 흐름을 나타낸 것이다. 호 흐름이 식으로 표현될 수 있다. 식은 각자의 흐름과 연관되어 있을 수 있는 보안 기능을 포함할 수 있다. 도 8에 예시되어 있는 호 흐름은 예시를 위한 것이다. 다른 실시예가 사용될 수 있다는 것을 잘 알 것이다. 게다가, 적절한 경우, 흐름의 순서가 변화될 수 있다. 그에 부가하여, 필요하지 않은 경우 흐름이 생략될 수 있고, 부가의 흐름이 추가될 수 있다.

1에서, POS(30)는 다양한 허가된 사용자[사용자(32) 등]에게 배포될 수 있는 사전 발생된 티켓을 원격 소유자(RO, 40)에게 요청할 수 있다.

2에서, RO(40)는 공개 키 K_POS _- _Pub(예컨대, 인증서 Cert_POS를 통해 수신됨)를 사용하여 POS 서명의 유효성을 검사하고, 사용자[사용자(32) 등]를 등록시킬 때 사용될 수 있는 인덱싱된 티켓 세트를 전송하는 것으로 응답할 수 있다.

인덱싱된 세트 내의 각각의 티켓은 3중항을 포함할 수 있다:

IMSI(international mobile identity subscriber identity)는, 예컨대, 서비스 크리텐셜을 요청할 때, 사용자/가입자의 고유 식별자로서 역할할 수 있다. RAND 값은 티켓 자체의 신선성 표시를 제공할 수 있는 난수이고, AUTH는 티켓의 무결성 및 신뢰성을 검증하는 데 사용될 수 있는 수단이다. T키 K_RO _{_} _Priv(RO의 비밀 키)를 사용하는 Package_1 해시의 서명은, 원격 소유자를 인증하는 동안, 메시지의 무결성을 보호할 수 있다.

2에서 전송된 메시지에 대해, POS(30)는 그의 비밀 키 K_POS _{_} _Priv를 사용하여 티켓 세트를 복호화할 수 있고, 공개 키 K_RO _{_} _Pub(예컨대, 인증서 Cert_RO를 통해 수신됨)를 사용하여 원격 소유자 서명을 검증할 수 있다. 식 1 및 식 2에 나타낸 바와 같이, nonce0는 (송신기로부터 수신기로 다시 송신기로) 왕복하고, 이는 보안 통신을 위해 필요할 수 있다.

3에서, 사용자(32)는, 예컨대, THSM 내의 사용자 도메인 TD_U(34)에 등록하고, ID, 비밀번호 및/또는 등록 데이터 등의 정보를 제공할 수 있다.

3에서의 프로세스는 통상적인 로그인 및 등록 절차로 볼 수 있다. 메시지의 암호화 및 서명 특징은 물론, 넌스 nonce_U의 사용은 ME의 암시적 존재를 반영할 수 있고 사용자에게 투명할 수 있다. 이 투명성은 도 8에 예시된 방법 전체에 걸쳐 사용자/소유자와 TD_U 사이의 다른 통신에 관한 것일 수 있다.

ID_U 및 Password_U(PW_U라고도 함)는, 사용자가 플랫폼 상에 설정하는 각각의 계정에 대해, 사용자가 생성하는 고유의 사용자 이름 및 비밀번호 쌍일 수 있다. ID_U는 특정의 계정과 관련하여 사용자를 식별해줄 수 있고, 연관된 비밀번호 Password_U는 비밀일 수 있으며(예컨대 허가된 사용자는 알고 있지만 다른 사람들은 모르고 있음) 사용자 허가(user authorization)를 위해 사용될 수 있다. REGDATA_U는 사용자 개인 정보를 포함할 수 있다.

4에서, TD_U(34)는 3에서 수신된 메시지에서의 정보를 판독하고 저장할 수 있으며, 프로세스 ID(PID_U)를 발생할 수 있다. K_temp _{_C} 및 K_temp _{_I}는, 각각, 사전-프로비저닝되어 있을 수 있는 기밀성 및 무결성 키를 나타낼 수 있다. 이것은 TD_U(34)가 비밀번호(Password_U)를 복호화하고 Package_2의 해싱된 서명을 검증할 수 있게 해줄 수 있다. 등록 및 티켓 요청 프로세스를 시작하기 위해 PID_U가 REGDATA_U와 함께 POS(30)로 전송될 수 있다. PID_U는 제1 프로세스 식별자일 수 있다.

5에서, POS(30)는, PID_U 및 REGDATA_U를 수신한 후에, 그 자신의 PID(PID_POS)를 발생하고 이를 PID_U 및 사용자 등록 정보와 연관시킬 수 있다. 플랫폼이 PID_U를 사용하여 POS(30)와 통신할 때, POS(30)는 메시지를 PID_POS에 의해 식별된 등록 프로세스의 일부로 볼 수 있다. 따라서, 다수의 등록 프로세스가 동시에 일어날 수 있다. PID_POS는 제2 프로세스 식별자일 수 있다. 인증서 Cert_TDU를 사용하여, POS(30)는 공개 키 K_TDU _- _Pub를 사용하는 SHA-X(Package_3)의 서명을 검증할 수 있다. POS(30)는 4에서 PID_POS를 PID_U와 함께 다시 TD_U(34)로 전송하는 것에 의해 메시지에 응답할 수 있다(예컨대, 이하의 메시지에 예시되어 있음).

TD_U(34)는 인증서 Cert_POS부터 획득된 K_POS _{_} _Pub를 사용하여 SHA-X (Package_4)의 서명을 검증할 수 있다. TD_U(34)와 POS(30) 사이의 통신은 공중을 통해 도는 인터넷 경로를 통해 일어날 수 있다.

6에서, TD_U(34)는 등록 요청을 TD_RO(38)로 전송할 수 있다. PID_U 및 PID_POS는 TD_RO(38)가 관련 프로세스 연관을 수행할 수 있게 해주기 위해 메시지의 일부로서 전송될 수 있다. 사용자 ID ID_U는 메시지에 포함될 수 있고, TD_RO(38)는 등록 시도를 하는 특정의 사용자의 서비스 프로파일에 대한 검사로서 사용자 ID를 사용한다. 이 특징은 동일한 도메인에 대한 다수의 사용자 등록에 유연성을 제공할 수 있다.

TD_RO(38)는 인증서 Cert_TDU로부터 획득된 공개 키 K_TDU _- _Pub를 사용하여 TD_U(34)의 서명을 검증할 수 있다.

7에서, TD_RO(38)는 하기의 메시지를 통해 POS(30)에 티켓 요청을 할 수 있다. POS(30)는 메시지 5에서 TD_U(34)로 전송했고 메시지 6에서 TD_RO(38)로 전달된 nonce4를 예상할 수 있다. nonce4를 갖는 Package_6은 비밀 키 K_TSIM _- _Priv를 사용하여 서명될 수 있다. POS(30)는 이 요청을 프로세스 ID PID_U를 사용하여 4에서 전송된 등록 데이터와 연관시킬 수 있다.

POS(30)는 인증서 Cert_TSIM를 통해 획득할 수 있는 공개 키 K_TSIM _- _Pub를 사용하여 이 메시지에서의 서명을 검증할 수 있다. POS(30)는 Package_6(평문으로 전송됨) 및 nonce4를 사용하여 SHA-X를 재생성할 수 있다.

8에서, 등록 요청(티켓 요청)이 POS(30)에 의해 수신된 후에, POS(30)는 RO(40)로부터 앞서 수신된 세트로부터 티켓을 페치할 수 있다. POS(30)는, 예컨대, THSM을 통해 이 티켓을 TD_RO(38)로 전송할 수 있다. 공개 키 K_TSIM _- _Pub은 ticket_k를 암호화하는 것은 물론 티켓을 수신자에 바인딩시키는 데도 사용될 수 있다.

TD_RO(38)는 그의 비밀 키 K_TSIM _- _Priv를 사용하여 ticket_k를 복호화(언바인딩)할 수 있고 메시지 6에서의 Cert_POS를 통해 획득된 K_POS _- _Pub를 사용하여 Package_7의 서명을 검증할 수 있다. 이 프로세스는 티켓의 무결성을 인증하고 검증하는 역할을 할 수 있다. TD_RO(38)는 PID_POS를 사용하여 올바른 프로세스 연관을 할 수 있다. 넌스 nonce5는 TD_RO(38)로 반환될 수 있다.

9에서, TD_RO(38)로 전송된 티켓에 부가하여, POS(30)는 또한 REGDATA_U를 포함할 수 있고 ticket_k를 갖는 사용자를 식별해줄 수 있는 등록 메시지를 RO(40)로 전송할 수 있다. 프로세스 연관에 필요할 수 있는 정보를 RO(40)에 제공하기 위해, PID_POS 및 PID_U가 전송될 수 있다. 이것은 RO(40)가 수신된 프로세스 ID를 이 등록을 위해 RO(40)가 생성하는 ID와 연관시킬 수 있게 해줄 수 있다. 이 메시지는 사용자가 요청할 수 있는 크리텐셜을 지정된 사용자에게 제공하기 위해 RO(40)에서 필요로 할 수 있는 정보를 포함할 수 있다.

티켓이 메시지 2에서의 Cert_RO에서 POS(30)에 의해 획득된 K_RO _- _Pub를 사용하여 암호화될 수 있다. RO(40)는 그의 비밀 키 K_RO _- _Priv를 사용하여 ticket_k을 복호화할 수 있고 공개 키 K_POS _- _Pub를 사용하여 Package_8의 서명을 검증할 수 있다. 공개 키 K_RO _- _Pub은 티켓을 RO(40)에 바인딩하는 효과를 가질 수 있다.

10에서, RO(40)는 티켓을 포함하는 등록 정보를 수신하는 것을 확인 응답할 수 있다. 예를 들어, RO(40)는 하기의 메시지를 TD_U(34)로 전송할 수 있다.

TD_U(34)는 9에서 메시지를 수신한 후에 RO(40)에 의해 발생되는 PID_U 및 PID_RO의 수신에 의해 프로세스 ID를 RO(40)에 유지할 수 있다. TD_U(34)는 인증서 Cert_RO에서 수신된 공개 키 K_RO _- _Pub를 사용하여 package_9 해시의 서명을 유효성 검사할 수 있다.

11에서, 식 10과 연관된 메시지를 수신한 후에, TD_U(34)는 사용자(32)에게 크리텐셜을 요청할 권한을 부여하는 화면 메시지를 사용자(32)에게 발행할 수 있다.

이 메시지는, 메시지 3에서 사용된 서명 및 검증 프로세스와 유사하게 그렇지만 반대 방향으로, ME측에서 동일한 키를 사용하여 검증되기 위해 THSM측에서 적용될 수 있는 서명 키 key K_temp _{_I}의 사용을 나타내고 있다. Nonce_U는 왕복하는 TD_U(34)에 의해 ME로 반환될 수 있다. ID_U는 사용자(32)를 식별하고, PID_U와 함께, 현재의 등록 및 크리텐셜 롤아웃과 연관시키기 위해 ME 및 TD_U(34)에 의해 사용될 수 있으며, 이는 프로세스 모호성을 방지할 수 있다.

사용자는 크리텐셜 롤아웃을 개시할 수 있다(예컨대, 사용자는 가입자-관련 크리텐셜을 획득하기 위해 원격 소유자에 신청할 수 있다). 12에서, 사용자(32)는 11에서 전달된 메시지에 크리텐셜에 대한 요청으로 응답할 수 있다. 비밀번호가 공유 암호화 키 K_temp _{_C}를 사용하여 보호될 수 있다. Nonce9는 TD_U(34)로 반환될 수 있다.

TD_U(34)는 공유 키 세트를 사용하여 비밀번호를 복호화하고 서명을 검증할 수 있다. 11에서 전달된 메시지는 PID_U와 ID_U의 조합을 사용하는 것을 예시하고 있다. 넌스 및 PID는 사용자/소유자에게 투명할 수 있고, 사람이 아닌 통신 엔터티에 의한 사용으로 제한될 수 있다.

13에서, TD_U(34)는 이제 크리텐셜에 대한 사용자 요청을 TD_RO(40)로 이월시킬 수 있고, 이는 RO(40)에 직접 요청하라고 TD_RO(40)를 트리거할 수 있다. PID_RO 및 PID_U는 통신 엔터티와의 프로세스 연관을 가능하게 해줄 수 있다. TD_RO(40)는 이제 3개의 프로세스 ID를 연관시킬 수 있다.

6에서 전달된 메시지를 통해 수신된 Cert_TDU에서 수신된 K_TDU _- _Pub를 사용하여 메시지 검증이 달성될 수 있다.

14에서, TD_RO는 SDM(36)에 반자율적 무결성 검증에 대한 요청할 수 있다. 반자율적 무결성 검증은 키 무결성 표시자(예컨대, TPIA, TPES, 및 SCARD)의 해시 값의 사용으로 제한될 수 있다.

SDM(36)이 Package_13 해시의 서명 검증을 위한 공개 키 K_TDRO _- _Pub를 획득할 수 있게 해주기 위해 인증서 Cert_TSIM이 전송될 수 있다. PID_U의 사용에 의해 프로세스 ID 연관이 유지될 수 있다. SDM(36)은 PID_U만을 필요로 할 수 있는데, 그 이유는 SDM(36)이 외부 엔터티(예컨대, THSM 외부의 엔터티)와 통신하지 않을 수 있기 때문이다.

15에서, SDM(36)은, 예컨대, RTO 프로세스 이후에 일어났을 수 있는 구성 변경에 대한 업데이트된 증명 정보를 수집할 수 있다. TPIA, TPES, 및 SCARD는 필요에 따라 업데이트될 수 있고, 무결성 데이터가 하나의 값 IV(integrity verification value, 무결성 검증 값)으로 해싱될 수 있다. PID_U 및 IV는 반환 메시지를 통해 TD_RO(34)로 전송될 수 있다. 넌스 nonce_TDRO가 반환될 수 있다.

서명이 인증서 Cert_SDM에서 획득된 공개 키 K_SDM _- _Pub를 사용하여 검증될 수 있다.

16에서, TD_RO(38)는 RO(40)에 크리텐셜 롤아웃에 대한 요청을 할 수 있다. 16에서 전송된 메시지에서, 식별자 IMSI_k는 13에서 메시지 내의 인증서 Cert_RO에서 TD_RO(40)에 의해 수신되었던 RO(40)의 공개 키 K_RO _- _Pub로 암호화되어 전송될 수 있다. 무결성 값 IV는 신뢰성 검증을 위해 전송될 수 있고, 프로세스 ID PID_U는 9에서 메시지에서의 정보와의 프로세스 연관을 가능하게 해주기 위해 전송될 수 있다.

RO(40)는 그의 비밀 키 K_RO _- _Priv를 사용하여 IMSI_k를 복호화할 수 있고 인증서 Cert_TDRO에서 RO(40)에 의해 획득된 공개 키 K_TDRO _- _Pub를 사용하여 서명을 검증할 수 있다.

17에서, 크리텐셜이 RO(40)에 의해 TD_RO(38)로 전송될 수 있다. 크리텐셜이 16에서 Cert_TDRO로부터 획득된 공개 키 K_TDRO _- _Pub를 사용하여 암호화될 수 있다. 이것은 크리텐셜을 TD_RO(38)에 바인딩시킬 수 있다. TD_RO(38)는 그의 비밀 키 K_TDRO _- _Priv를 사용하여 크리텐셜을 언바인딩할 수 있다. 넌스 nonce11는 왕복할 수 있다.

TD_RO(38)는 13에서 관련 인증서를 통해 수신된 공개 키 K_RO _- _Pub를 사용하여 서명을 검증할 수 있다. 프로세스 ID PID_RO는 올바른 프로세스 연관을 제공한다.

크리텐셜 키가 보호 메모리에 또는 SDM(36)에 제공된 보안 정책에 따라(예컨대, 17에 나타낸 바와 같이, 크리텐셜의 수신 시에) 저장될 수 있다. 이 정책은 RTO 프로세스 동안 정의되었을 수 있다. 18에서, 롤아웃이 완료되면, 확인 응답 메시지가 RO(40)로 전송될 수 있다.

넌스 nonce12가 반환될 수 있고, 프로세스 모호성이 PID_U에 의해 회피될 수 있다. RO(40)는 16에서 획득된 공개 키 K_TDRO _- _Pub를 사용하여 서명을 검증할 수 있다.

19에서, TD^RO(38)는 롤아웃 완료 확인 응답 메시지를 TD_U(34)로 전송할 수 있다. 넌스 nonce_TDU2(13 참조) 및 nonce_TDU1(16 참조)가 반환될 수 있고, 프로세스 모호성이 PID_U에 의해 회피될 수 있다.

인증서 Cert_TDRO에서 획득된 공개 키 K_TDRO _- _Pub를 사용하여 TD_U(34)에 의해 서명이 검증될 수 있다.

20에서, 사용자(32)는 크리텐셜이 수신되었고 구성되어 있다는 것을 나타내는 화면 메시지를 TD_U(34)로부터 제공받을 수 있다. 크리텐셜이 이제 사용자(32)가 허가되어 있는 안전한 서비스에 이용가능할 수 있다. 넌스 nonce10이 반환될 수 있다(12 참조).

3, 11 및 12와 관련하여 기술된 바와 같이 서명 검증이 달성될 수 있다. PID_U 및 ID_U의 조합의 사용이 11과 관련하여 기술된 바와 같이 달성될 수 있다.

21에서, ticket_k이 이제 사용 중이고 다른 곳에 배포되어서는 안된다는 것을 나타내는 메시지가 POS(30)로 전송될 수 있다.

POS(30)는 2에서 수신되는 인증서 Cert_RO에서 획득된 공개 키 K_RO _{_} _Pub를 사용하여 서명을 검증할 수 있다. PID_RO는 프로세스 연관을 가능하게 해줄 수 있다.

도 8에 예시된 호 흐름과 관련하여, 3개의 넌스가 한쪽으로만 가는 것으로 도시되어 있다. 즉, 이들이 처음으로 전달되었을 때 이후의 메시지에서 반환되지 않을 수 있다. 3개의 이러한 넌스는 10에서의 nonce8, 15에서의 nonce_SDM, 및 21에서의 nonce15이다. 호 흐름 설명에 나타내어져 있지는 않지만, 이들 넌스 각각에 대해, 넌스를 포함하는 ACK가 수신자에 의해 대응하는 전송자에게로 전송(반환)되는 것으로 가정될 수 있다. 따라서, 예를 들어, nonce8는 10에서의 메시지의 수신 이후에 TD_U(34)에 의해 ACK 메시지를 통해 RO(40)로 반환될 수 있다.

III . 크리텐셜 및/또는 도메인의 마이그레이션

크리텐셜 및/또는 도메인을 마이그레이션하는[예컨대, 도메인을 하나의 장치(소스)로부터 다른 장치(목적지)로 마이그레이션하는, 크리텐셜을 소스 장치 상의 제1 도메인으로부터 목적지 장치 상의 제2 도메인으로 마이그레이션하는, 크리텐셜을 장치 상의 제1 도메인으로부터 장치 상의 제2 도메인으로 마이그레이션하는, 기타를 하는] 시스템, 방법 및 수단이 개시되어 있다. 크리텐셜의 마이그레이션을 예시하는 일례가 제공될 수 있다. 그렇지만, 본 명세서에 개시된 마이그레이션이 이러한 실시예로 제한되지 않는다는 것을 잘 알 것이다.

마이그레이션은 크리텐셜을 제1 도메인으로부터 제2 도메인으로 마이그레이션하는 것을 포함할 수 있다. 예를 들어, 장치의 사용자는 장치 상의 원격 소유자 도메인에 액세스할 수 있다. 사용자는 크리텐셜을 원격 소유자 도메인에 저장할 수 있다(예컨대, 크리텐셜에 의해 사용자가 원격 소유자 도메인과 연관되어 있는 원격 소유자에 의해 제공되는 서비스를 사용할 수 있게 되는 경우). 게다가, 사용자는 크리텐셜을 상이한(제2) 원격 소유자 도메인으로 이동(즉, 마이그레이션)시키고자 할 수 있다. 제2 원격 소유자 도메인이 동일한 장치 상에 또는 상이한 장치 상에 있을 수 있다. 예를 들어, 사용자는 새로운 장치를 구입했을 수 있고, 이 경우 사용자는 새로운 장치 상의 원격 소유자의 서비스를 사용하고자 한다. 사용자는, 예를 들어, 현재 사용 중인 장치의 TSIM 코어 구성(코어 보안 크리텐셜; 영구적 ID 및 공유 비밀 K, 및/또는 TSIM 기능/실행 파일)을 새로 구입한 장치로 이동시키고자 할 수 있다.

TSIM 개념에서, 각각이 장치 상에 구성된 하나 이상의 원격 소유 도메인에 액세스할 수 있는 어쩌면 다수의 사용자가 이들 도메인 중 하나 이상의 도메인의 TSIM 코어를 사용자가 역시 액세스할 수 있는 다른 장치로 이동시키고자 할 수 있다. 본 명세서에 개시된 시스템, 방법 및 수단은 소스로부터 목적지로의 마이그레이션을 기술하고 있을 수 있으며, 여기서 절차는 다수의 도메인의 이동에 대한 반복(iterative)으로 볼 수 있다.

크리텐셜 및 도메인은 본 명세서에 기술되어 있는 THSM(trusted hardware security module) 프레임워크의 일부일 수 있다. 예시적인 마이그레이션이 동일한 소유자에 속하는 소스 도메인 및 대상 도메인을 참조하여 설명될 수 있다. 그렇지만, 본 명세서에 개시된 마이그레이션이 이러한 실시예로 제한되지 않는다는 것을 잘 알 것이다.

이하의 것들 중 하나 이상이 만족될 수 있고 및/또는 마이그레이션이 일어나는 것으로 가정될 수 있다.

사용자는 (예컨대, 장치 소유자의 허가를 받는 것에 의해) 등록하고 사용자 도메인을 생성할 수 있고, 이 사용자 도메인 상에서 사용자 프로필이 소스 및 목적지 장치 둘 다에 저장되고 유지된다.

마이그레이션은 원격 소유자/통신 사업자(RO) 관여의 레벨을 포함할 수 있다. 소스 및 목적지 장치 둘 다의 RO는 물론, SDM(system wide domain manager)도 마이그레이션이 진행되지 않도록 중단시킬 수 있다. RO는 마이그레이션이 진행할 수 있도록 하기 위해 장치가 충분한 레벨의 신뢰성을 가지고 있는지를 결정할 수 있다.

사용자 프로필은 그 사용자가 이용가능한 서비스를 나타내는 계정 정보 및 기타 사용자 개인 데이터 등의 사용자 등록 데이터는 물론, 식별자(예컨대, 사용자 이름) 및 사용자 인증 데이터(예컨대, 비밀번호, 실제 비밀번호의 다이제스트, 생체 식별 등)도 포함할 수 있다. 한명의 소유자를 갖는 다수의 장치 상의 서비스에 액세스할 수 있는 사용자의 등록 데이터 및 계정 정보가 그 장치 상에서 그 사용자가 액세스할 수 있는 서비스에 따라 장치마다 다를 수 있다. 마이그레이션은 마이그레이션된 크리텐셜과 연관된 서비스에 관련되어 있는 사용자 등록 데이터의 전달을 포함할 수 있다.

사용자가 장치와 통신하는 데 사용자 도메인이 필요할 수 있다. 즉, 사용자 도메인을 통해 사용자가 일반적으로 서비스 공급자에 의해 원격적으로 소유되는 그 도메인에 의해 제공되는 서비스에 액세스할 수 있다.

장치 소유자는 사용자일 수 있다. 어떤 시나리오에서, 장치 소유자는 단독 사용자일 수 있다.

장치는 한명의 소유자를 갖는 것으로 제한될 수 있지만, 2명 이상의 사용자를 가질 수 있다. 각각의 사용자는 주어진 사용자의 프로필에 의해 정의되는 고유의 구성을 갖는 상이한 사용자 도메인을 가질 수 있다.

소스 장치로부터 목적지 장치로의 개시된 예시적인 마이그레이션의 경우, 소스 장치 및 목적지 장치 둘 다가 동일한 소유자를 가질 수 있다.

사용자의 액세스는 그 서비스로 제한될 수 있고, 따라서 사용자가 등록되어 있고 사용하도록 허가되어 있는 그의 연관된 도메인으로 제한될 수 있다. Password_U(PW_U) 및 ID_U는 마이그레이션되고 있는 특정의 도메인에 고유할 수 있고, 동일한 사용자에 대해, 유사하지만 구별되는 등록 크리텐셜이 다른 도메인에 대해 존재할 수 있다. 사용자에 의해 제공되는 등록 크리텐셜에 따라, 신뢰성 있는 사용자/소유자 도메인은 그 크리텐셜을 적절한 도메인으로 보내고 안전하게 프로비저닝할 책임을 지고 있을 수 있으며, 그에 의해 의도된 서비스가 액세스될 수 있다.

마이그레이션이 일어나도록 하기 위해, 소스 도메인의 원격 소유자(RO)가 또한 RTO를 통해 목적지 도메인의 소유권을 취득할 필요가 있을 수 있다. RO는 이어서 그의 초기 정책 및 구성을 알 수 있다. 목적지 장치는 그 자신의 시스템 구성 파일을 가질 수 있고, 따라서 시작 도메인(예컨대, 장치 제조업체의 도메인은 물론, 사용자/소유자 도메인 및 장래의 소유권에 대한 최소 원시 도메인 세트) 및 어쩌면 이미 존재하는 원격 소유 도메인을 소유하고 있다. SDP(system wide domain policy)가 동일한 소유자를 가지는 다수의 장치에 걸쳐 꼭 복제될 필요는 없다. 소스 및 목적지 도메인의 원격 소유자가 마이그레이션이 수행되기 전에 양쪽 장치의 SDP를 수락한 것으로 가정될 수 있다.

마이그레이션에 관여된 엔터티는 사용자/소유자, 소스와 연관된 시스템 전체 도메인 관리자, 목적지와 연관된 시스템 전체 도메인 관리자, 소스와 연관된 원격 소유자 도메인, 목적지와 연관된 원격 소유자 도메인, 또는 원격 소유자 중 하나 이상을 포함할 수 있다. 원격 소유자 도메인은 또한 원격 소유 도메인(remotely owned domain)이라고도 할 수 있다.

사용자는 장치(예컨대, 하나 이상의 원격 소유자 도메인을 포함하는 장치)의 사용자일 수 있다. 사용자는 또한 장치의 소유자일 수 있다. 사용자는 원격 소유자 도메인의 원격 소유자에 등록되어 있을 수 있다. 사용자가 원격 소유자에 의해 제공되는 서비스에 액세스할 수 있게 해주기 위해 사용자와 연관된 크리텐셜이 원격 소유자 도메인에 로드될 수 있다. 사용자는 크리텐셜을 동일한 장치 또는 상이한 장치 상의 다른 도메인으로 마이그레이션하고자 할 수 있다. 사용자는 크리텐셜의 마이그레이션을 개시할 수 있다.

원격 소유자(RO)는 장치를 통해 사용자에게 서비스를 제공할 수 있다. 원격 소유자는 사용자가 서비스를 사용하기 위해 필요할 수 있는 크리텐셜을 제공할 수 있다. 크리텐셜은 원격 소유자 도메인과 원격 소유자 사이의 강력한 비밀로서 역할할 수 있는 인증 키 K를 포함할 수 있다. 일례로서, RO는 MNO, 다른 통신 네트워크 통신사업자(예컨대, WLAN, WiMax 등), 이메일 서비스 공급자, 인터넷 서비스 공급자, 소셜-네트워킹 서비스 공급자, 디지털 콘텐츠(음악, 전자책, 비디오 등) 공급자, 게임 서비스 공급자, 금융 서비스 공급자, 응용 프로그램 서비스 공급자(예컨대, 모바일 결제, 모바일 티켓팅, DRM, 모바일 TV, 위치-기반 서비스 등에서의 서비스 공급자) 또는 IMS 서비스 공급자 등 중 하나 이상일 수 있다.

원격 소유자 도메인(TD_RO)은 원격 소유자에 의해 정의된 기능을 제공할 수 있는 장치 상의 도메인이다. 원격 소유자 도메인은 앞서 기술되어 있는 바와 같이(예컨대, 도 2 참조) THSM의 일부일 수 있다. 원격 소유자 도메인은 앞서 기술된 RTO 프로세스와 관련하여 기술된 바와 같은 TSIM 기능을 가질 수 있다. 원격 소유자 도메인은 원격 소유자에 의해 제공되는 크리텐셜을 저장할 수 있다. TD_RO는 사용자의 ID 및 프로세스 ID(IDU, PID_U)를 사용자 도메인으로부터 수신할 수 있고, 등록 및 크리텐셜 롤아웃 동안 이 정보를 다양하게 사용할 수 있다. 소스 원격 소유자 도메인(TD_RO _,S)(이것으로부터 크리텐셜이 마이그레이션됨) 및 목적지 원격 소유자 도메인(TD_RO _,S)(이것으로 크리텐셜이 마이그레이션됨)이 있을 수 있다. 예를 들어, 사용자는 소스 장치와 연관된 원격 소유자 도메인으로부터 목적지 장치와 연관된 원격 소유자 도메인으로의 전송을 개시할 수 있다.

SDM(system-wide domain manager)(예컨대, 섹션 I에 개시된 SDM)은 마이그레이션 프로세스의 일부로서 하나 이상의 플랫폼에 관련된 증명 정보를 제공할 수 있다. 예를 들어, 반자율적 무결성 확인 등의 무결성 표시자가 SDM에 의해 제공될 수 있다. SDM은 도메인의 구성요소 등의 THSM의 일부일 수 있다(예컨대, 도 2 참조). SDM은 신뢰성 있는 사용자 도메인 및/또는 신뢰성 있는 소유자 도메인과 결합될 수 있다. 소스 원격 소유자 도메인과 연관된 소스 시스템 전체 도메인 관리자(source system- wide domain manager, SDM_S) 및 목적지 원격 소유자 도메인과 연관된 목적지 시스템 전체 도메인 관리자(destination system-wide domain manager, SDM_D)가 있을 수 있다.

이하의 처음 3개의 식 각각은 2 부분을 포함할 수 있고, 한 부분은 소스 장치에서의 통신에 대한 것이고 다른 부분은 목적지 장치에서의 유사한 통신에 대한 것이다. 이들 부분은, 예컨대, 식 1의 경우에, 1(소스 부분) 및 1a(목적지 부분)로 표시되어 있을 수 있다. 이들 식에서의 키 및 인증서는 유사하게 표시되어 있을 수 있지만, 이들이 그 각자의 부분에서 상이한 값을 나타낼 수 있다. 식 1에서, 예를 들어, 기밀성 및 무결성 키가 소스 부분(1) 및 목적지 부분(1a) 둘 다에 대해, 각각, K_temp _{_C} 및 K_temp _{_I}로 표시될 수 있지만, 이들이 상이한 키 세트를 나타낼 수 있다. 다른 일례에서, K_SDM _- _Pub 및 K_SDM _- _Priv는 그의 소스 및 목적지 사용에서의 상이한 공개-비밀 키 쌍을 나타낼 수 있다(예컨대, 3 및 3a 참조).

마이그레이션 전체에 걸쳐, 메시지 서명 및 서명 검증이 확인 응답될 수 있다. 이 보안 기능을 수행하기 위해 공개-비밀 키 쌍이 사용될 수 있고, 그에 의해 메시지가 인증되고 무결성도 보호된다. 신뢰성 있는 제3자 인증서를 통해 메시지 서명자에 의한 비밀 서명 키에 대응하는 공개 키의 배포가 포함될 수 있다. 예를 들어, Cert_TSIM(소스 및 목적지 원격 소유 도메인에 대해, 각각, Cert_TSIMS 및 Cert_TSIMD로 표시됨)로 표시된 제3자 발행 인증서가 비밀 키 K_TSIM _- _Priv(K_TSIMS _- _Priv 또는 K_TSIMD _- _Priv)에 대응하는 공개 키 K_TSIM _- _Pub(각각, 소스 또는 목적지에 따라, K_TSIMS _- _Pub 또는 K_TSIMD _- _Pub) 를 전달하는 데 사용될 수 있다. 비밀 키는 주어진 메시지의 SHA-X 해시에 서명을 하여, 고정된 길이로 만든다. 서명 검증을 위해 대응하는 공개 키가 사용된다.

플랫폼과의 사용자/소유자 통신이 도 9a/도 9b에 도시되거나 식에서 참조되지 않은 단말기를 통해 수행될 수 있다. 소스 및 목적지 장치 둘 다에 대해, 사전-프로비저닝된 상이한 대칭 키 세트 K_temp _{_C} 및 K_temp _{_I}가 단말기와 THSM 사이의 통신을 보호할 수 있다. W 사용자/소유자가 소스 또는 목적지 장치 상의 신뢰성 있는 사용자/소유자 도메인(일반적으로 SDM/TD_U/TD_O로 표시됨)과 통신할 때, 이러한 키가 포함될 수 있다.

프로세스 ID 관리가 마이그레이션에서 이용되지 않을 수 있다(왜냐하면 대역외 메시징이 이용가능하지 않을 수 있기 때문이다).

표기법 SDM/TD_U/TD_O가 SDM 및 사용자/소유자 도메인의 결합을 나타내기 위해 사용될 수 있다. 이는 개별적인 엔터티를 나타낼 수 있고, 마이그레이션의 상이한 부분에서, 참조가 SDM으로 제한될 수 있고, 다른 때에, 참조가 사용자/소유자 도메인으로 제한될 수 있으며, 이 경우 참조는 상황에 의존한다. 상황은, 예를 들어, 사용자 ID 및 어쩌면 비밀번호를 이용하는 마이그레이션 요청 메시징을 수반하는 사용자/소유자 상호작용일 수 있거나, 관여가 SDM으로 제한될 수 있는 정책에 관한 상호작용일 수 있다. 유사한 표기법을 사용하여, 사용자/소유자는 사용자/소유자 상호작용을 지정할 수 있고, SDM은 SDM 상호작용을 지정할 수 있다.

소스 및 목적지 장치의 신뢰성 레벨을 평가하기 위해 마이그레이션에서 반자율적 무결성 표시자(SA-IV) 등의 무결성 표시자가 사용될 수 있다. 반자율적 무결성 표시자는 무결성 검사를 통과하지 못한 장치 내의 모듈의 목록을 포함할 수 있다. 소스 및 목적지 반자율적 무결성 표시자를 지정하기 위해 표기법 SA-IV(src) 및 SA-IV(dest)가 이용될 수 있다.

마이그레이션 요청의 소스에 관한 모호성을 회피하기 위해 마이그레이션과 연관된 메시징 및 프로세스에 필요할 수 있는 후속 메시징 전체에 걸쳐 프로세스 식별자(Proc_ID)가 제공될 수 있다. 서명 메커니즘을 통한 메시지 무결성 보호는 이 ID의 외부 변조를 방지할 수 있다. 예컨대, 사용자가 다수의 도메인을 마이그레이션하고자 하는 경우에 모호성을 회피하기 위해, 사용자 ID 및 프로세스 ID의 사용이 도메인 식별자를 포함하도록 확장될 수 있다. 이하의 일례는 사용자가 단일 도메인을 마이그레이션하는 경우를 설명할 수 있다. 그렇지만, 이 프로세스가 그것으로 제한되지 않으며 다중 도메인 마이그레이션의 경우를 포함할 수 있다.

사용자 비밀번호(PW_U)의 초기 사용은, 마이그레이션 요청의 개시가 적법한 사용자/소유자로 제한될 수 있도록, 사용자 가장(user impersonation)으로부터 보호할 수 있다.

프로토콜 전체에 걸쳐 넌스를 사용함으로써 재전송 보호(replay protection)가 제공될 수 있다. 왕복 통신의 발신자는 의도된 수신자로 넌스를 전송할 수 있고, 수신자는, 서명된 해시의 일부로서, 그 넌스를 발신자로 반환할 수 있다. 어떤 경우에, 넌스가 프로토콜에서 나중에 반환될 수 있다(식 4에서 소스 도메인으로부터 수신한 후에 식 7a에서 RO에 의해 nonce4를 반환하는 것 등). 넌스는 일반적으로 순서에 따라 연속적으로 번호가 부여되어 있을 수 있다(예컨대, 단계 i에서 송신기에 의해 발생된 넌스가 통상적으로 값 noncei를 받을 수 있다).

이하의 식에서의 특정의 경우는 반환되는 넌스를 나타낼 수 있고, 여기서 발신자로부터의 그 넌스의 전송은 도시되어 있지 않다. 각각의 경우에서의 넌스가 도시된 통신 이전에 발신 통신에서 발신자에 의해 제공된 것으로 가정될 수 있다. 이러한 발신 통신은 요구된 넌스로 제한되었을 수 있다. 이들 생략은 이하의 경우에 일어난다:

i. SDM_S에서 발신되는 1에서의 nonce1

ii. SDM_D에서 발신되는 1에서의 nonce1a

iii. TD_RO _,D에서 발신되는 2(식 2)에서의 nonce2d

iv. TD_RO _,S에서 발신되는 2(식 2a)에서의 nonce2s

v. RO에서 발신되는 4에서의 nonce4c

vi. TD_RO _,D에서 발신되는 7에서의 nonce4a

vii. SDM_D에서 발신되는 5에서의 nonce4b

viii. TD_RO _,D에서 발신되는 8에서의 nonce8a

ix. 단말기에서 발신되는 18에서의 nonce18

x. 단말기에서 발신되는 20에서의 nonce20

도 9a 및 도 9b는 크리텐셜 마이그레이션을 구현하는 예시적인 호 흐름을 나타낸 것이다. 도 9a는 소스 및 목적지 도메인의 무결성 검증이 원격 소유자에 의해 수행될 수 있는 예시적인 마이그레이션을 나타낸 것이다. 도 9b는 소스 도메인의 무결성 검증이 SDM_D에 의해 수행될 수 있고, 목적지 도메인의 무결성 검증이 SDM_S에 의해 수행될 수 있는 예시적인 마이그레이션을 나타낸 것이다.

도 9a 및 도 9b의 것과 같은 마이그레이션 및 관련 호 흐름에 관한 상세가 제공된다. 앞서 살펴본 바와 같이, 3a까지의 식에서 일반 표기법이 사용될 수 있다.

도 9a를 참조하면, 예시적인 마이그레이션은 소유자일 수도 있는 사용자인 사용자/소유자(940), SDM_S, TD_U _,S, TD_O _,S 중 하나 이상을 참조할 수 있는 SDM_S/TD_U,S/TD_O,S(950), TD_RO _,D(970)를 비롯한 목적지 장치에 대해 유사한 참조를 갖는 소스 원격 소유자 도메인 TD_RO _,S(960), 및 SDM_D/TD_U _,D/TD_O _,D(980)를 포함할 수 있다. 마이그레이션 이전에, RO(990)(원격 소유자)는TD_RO _,D(970)의 RTO를 완료했을 수 있고 TD_RO,D(970)의 초기 정책 및 구성을 알고 있을 수 있다.

1 및 1a에서, 크리텐셜 마이그레이션 요청이 사용자/소유자(940)에 의해 행해질 수 있다.

식 1 및 식 1a는 사용자/소유자(940)에 대한 통신을 나타내고 있고, 여기서 사용자/소유자(940)는 마이그레이션을 개시하기 위해 로그인 정보 및 마이그레이션 요청을, 각각, 소스 및 목적지 사용자/소유자 도메인[SDM_S/TD_U _,S/TD_O _,S(950) 및 SDM_D/TD_U,D/TD_O,D(980)]로 전송할 수 있다. 키 K_temp _{_C}는 사용자 비밀번호를 암호화하고 K_{temp_I}는 메시지에 서명을 한다. 앞서 언급한 바와 같이, K_temp _{_C} 및 K_temp _{_I}는 단말기(도시 생략) 및 THSM의 인터페이스를 통해 통신을 보호할 수 있다. 사전-프로비저닝된 대칭 키 속성은 소스 및 목적지 도메인이 비밀번호를 복호화하고 메시지 서명을 검증할 수 있게 해줄 수 있다. 사용자는 소스 및 목적지 사용자/소유자 도메인 둘 다에 로그인 정보(소스 및 목적지 도메인에 대해 동일할 수 있고, 예컨대, 사용자가 양쪽 도메인과 관련하여 서비스에 한번 등록할 수 있음)를 제공할 수 있고, 이 경우 목적지에 대해서는, 로그인 크리텐셜이 전송되었다. TSIM 크리텐셜이 마이그레이션될 때, 사용자 등록 프로필의 전송이, 예컨대, 16에서 행해질 수 있다. 1 이전에, 사용자/소유자(940)에 의한 초기 마이그레이션 요청에서 사용하기 위해, 넌스 1 및 1a가, 각각, 소스 및 목적지 SDM에 의해 단말기로 전송되었을 수 있다. 이것은 단계 1에서의 그 넌스의 반환에 의해 재전송 방지를 제공할 수 있다.

PW_U 및 ID_U는 마이그레이션되고 있는 도메인 TSIM과 연관될 수 있다. 동일한 사용자가 상이한 비밀번호 및 로그인 크리텐셜을 사용하여 다른 원격 소유 도메인에 등록할 수 있다.

정책 프로비전이 마이그레이션을 진행되지 못하도록 방해하는지를 결정하기 위해, 시스템 전체 정책 검사(system wide policy check)가 각자의 SDM에 의해 수행될 수 있다. 어느 한 플랫폼 상에 2개 이상의 이러한 소유자가 있는 경우, 시스템 레벨 검사가 다수의 도메인 원격 소유자 간의 있을 수 있는 충돌을 고려할 수 있다. 1 및 1a에 대해, 전달된 정보는 소스 및 목적지 SDM(950, 980)에 의한 정책 검사, 그리고 소스 및 목적지의 신뢰성 있는 도메인 TD_U _,X/TD_O _,X(950, 980)(단, X = S 또는 D)에 의한 사용자 로그인 정보의 처리를 필요로 할 수 있다.

일 실시예에서, 마이그레이션 요청이 목적지가 아니라 소스로 전송될 수 있다. 예를 들어, 목적지 도메인을 갖는 장치가 아직 사용자/소유자(940)에게 판매되지 않았을 수 있고, 마이그레이션이 판매 프로세스의 일부로서 행해질 수 있다(예컨대, 판매자가 사용자 도메인을 수신할 때까지 장치를 가지고 있을 수 있고, 판매자는 결제될 때까지 "유치권(hostage)"을 취득한다. 이 경우에, 목적지 장치는 제1 사용자 로그인까지 수신된 도메인을 비활성 상태에 둘 수 있다. 이러한 제1 사용자 로그인은 수신된 사용자 도메인 TD_U로부터 사용자 인증된 메시지를 획득할 수 있는 다른 도메인(장치 제조업체 도메인 TD_DM)에 의해 처리될 필요가 있을 수 있고, 이어서, TD_DM은 목적지 장치 상에서 TD_U를 활성화시킬 수 있다.

2 및 2a에서, 사용자/소유자 도메인[SDM_S/TD_U _,S/TD_O _,S(950) 및 SDM_D/TD_U,D/TD_O,D(980)]은, 예컨대, 각각, 식 2a 및 식 2에서, 사용자에 의해 개시된 도메인 마이그레이션 요청 메시지를 RO 소스 및 목적지 도메인[TD_RO _,S(960) 및 TD_RO,D(970)]으로 전송할 수 있다. 서비스 허가 검사를 위해 사용자 ID ID_U가 필요할 수 있다. 다양한 서비스에 대한 동시적인 요청을 하는 다수의 사용자 간의 잠재적인 모호성을 제거하기 위해 프로세스 ID(Proc_ID)가 생성된다(예컨대, 4 참조). Proc_ID와 사용자 ID ID_U 사이의 연관이 명확히 나타내어져 있지 않을 수 있다. 공개 키 K_SDM _- _Pub가 인증서 Cert_SDM를 통해 소스 및 목적지 도메인[TD_RO _,S(960) 및 TD_RO,D(970)]로 전달될 수 있다. 소스 및 목적지 도메인[TD_RO _,S(960) 및 TD_RO _,D(970)]은 K_SDM-Pub를 사용하여 메시지 서명을 검증한다. 이 메시지는 소스 및 목적지 전송을 위해 K_SDM _- _Priv에 의해 서명될 수 있다. 넌스 nonce2d 및 nonce2s는, 각각, 목적지 및 소스 도메인에 의해 그 각자의 SDM으로 이전에 전달된 것으로 가정될 수 있다. 서명 및 전송 동작이 사용자/소유자 소스 및 목적지 도메인과 연관된 기능에 의해 수행될 수 있다.

2b 및 2c에서, 각자의 소스 및 목적지 도메인[TD_RO _,S(960) 및 TD_RO _,D(970)]은 도메인 레벨에서 마이그레이션에 관한 정책 충돌이 존재하는지를 결정하기 위한 검사를 수행할 수 있다. 시스템 전체 또는 도메인 레벨 정책 충돌은 마이그레이션을 중단시킬 수 있다[예컨대, 3에서, 프로토콜의 계속을 방지하는 NACK(negative acknowledgement)가 전송될 수 있다].

3 및 3a에서, 소스 및 목적지 도메인[TD_RO _,S(960) 및 TD_RO _,D(970)]은 긍정 확인 응답(ACK) 또는 부정 확인 응답(NACK)으로 마이그레이션 요청(각각, 1 및 1a)에 응답한다. 소스 및 목적지 사용자/소유자 도메인[SDM_S/TD_U _,S/TD_O _,S(950) 및 SDM_D/TD_U,D/TD_O,D(980)]이 NACK - 그 원격 소유 도메인에 대한 정책이 이 마이그레이션 요청을 금지시킨다는 것을 나타냄 - 를 수신하는 경우, 마이그레이션이 종료된다. 둘 다가 ACK를 수신하는 경우, 프로세스가 계속될 수 있다. 식 3 및 식 3a에서의 사용자/소유자 도메인은 그의 인증서 Cert_TSIM를 통해 획득될 수 있는 그 각자의 버전의 공개 키 K_TSIM _- _Pub를 사용하여 그의 메시지 서명을 검증할 수 있다.. 도시된 바와 같이, 메시지가 K_TSIM _- _Priv를 사용하여 서명될 수 있다.

3b에서, TD_RO _,S(960)는 사용자/소유자 도메인 SDM_S/TD_U _,S/TD_O _,S(950)으로부터 허가를 받은 메시지를 수신할 수 있다. (식 3b에서 시작하여, 소스 키 세트와 목적지 키 세트 간에 그리고 그의 대응하는 인증서 간에 표기법 구분이 있다.) 메시지의 서명이 TD_RO _,S(960)에 의해 인증서 Cert_SDM(Cert_SDMS)(예컨대, 식 2a에서 전달됨)로부터 획득되는 공개 키 K_SDMS _- _Pub를 사용하여 검증될 수 있다.

4에서, TD_RO _,S(960)는 마이그레이션이 요청되고 있다는 것을 RO(990)에 알려주는 메시지를 전송할 수 있다. 이 메시지는 소스 및 목적지 도메인[TD_RO _,S(960) 및 TD_RO,D(970)]의 정책, 구성 상태, 및 SA-IV를 검사하라는 것을 나타낼 수 있다[예컨대, 2 참조, ID_U 및 장치 ID를 RO(990)로 전송하는 것이 허가 검사를 위해 사용될 수 있다]. 메시지 서명이 검사되고 인증서 Cert_TSIMS에서 수신된 공개 키 K_TSIMS _- _Pub를 사용하여 검증될 수 있다. 소스 도메인이 마이그레이션에 대한 요청을 허가하지 않는 경우, 이 프로세스는 종료될 수 있다(예컨대, 식 4에서의 메시지가 전송되지 않는다). 그렇지만, 소스가 마이그레이션에 대한 허가를 해주면서 이와 동시에 목적지 도메인이 허가를 거부할 수 있고, 이는 경쟁 상태를 야기할 수 있다. 이러한 경우에, 프로세스는 종료되거나, 예컨대, 6에서 어쩌면 재협상될 수 있다. 소스는 허가를 해주지 않고 목적지가 허가를 해주는 경우, 목적지 도메인에 의해 개시된 활성 프로세스가 어떤 소정의 기간 후에 타임 아웃될 수 있다.

5 및 5a에서, RO(990)는 소스 및 목적지 SDM[각각, SDM_S/TD_U _,S/TD_O _,S(950) 및 SDM_D/TD_U,D/TD_O,D(980)]에 정책 및 구성 정보를 요청할 수 있다. 예를 들어, RO(990)는 소스 및 목적지 도메인에 구성, 장치 ID, SA-IV 정보, 및 마이그레이션 정책을 요청할 수 있다. 시스템 전체 도메인 정책을 관리하는 SDM은 그 요청을 수신하고 RO(990)에 대해 그 각자의 응답을 준비할 수 있다. 양 메시지에 대한 메시지 서명이 Cert_RO에서 획득된 공개 키 K_RO _{_} _Pub를 사용하여 검증될 수 있다.

6 및 6a에서, SDM[SDM_S/TD_U _,S/TD_O _,S(950) 및 SDM_D/TD_U _,D/TD_O _,D(980)]은 요청된 정보를 RO(990)로 전송한다. 마이그레이션이 목적지 도메인 TD_RO _,D(970)에 의해 금지되는 경우, NACK 메시지가 RO(990)로 반환되고, 이 프로세스가 종료된다. 이 경우에, RO(990)는 마이그레이션이 허용되지 않는 이유를 알기 위해 목적지 SDM[SDM_D/TD_U,D/TD_O,D(980)]에 부가 정보를 요청할 수 있다. 4에서의 요청으로부터, 소스 도메인이 이전에 허가를 해주었다는 것을 알 수 있다. 수정된 도메인 구성(예컨대, 서비스의 수정)이 허용가능한지를 결정하기 위해 RO(990)와 SDM 사이에 잠재적인 협상이 있을 수 있다. 수정의 허용가능성이, 예를 들어, 장치의 소유자에 의해(예컨대, 소유자와 상이한 사용자가 마이그레이션을 개시하고 있는 것으로 가정함) 또는 다른 원격 소유자에 의해(그의 도메인 정책이 원래의 구성을 금지시켰음) 결정될 수 있다. 협상이 실패하는 경우, 마이그레이션이 추가의 통신 없이 종료될 수 있고, 소스 도메인에 의해 활성화된 마이그레이션 프로세스가 소정의 기간 후에 타임 아웃될 수 있다. 그렇지 않은 경우, 마이그레이션이 계속될 수 있고, 목적지 도메인에 대한 수정은 그 도메인의 다른 RTO를 트리거할 수 있다.

6 및 6a를 여전히 참조하면, RO(990)는 프로세스를 2개의 장치와 연관시키기 위해 Proc_ID와 소스 및 목적지 장치 ID를 수신할 수 있다. 등록된 서비스에 대한 허가 검사가 행해질 수 있다. SA-IV(src & dest)의 수신에 의해, 양 장치의 무결성이 검증될 수 있다. 구성의 허용가능성이 또한 평가될 수 있다.

RO(990)는 인증서 Cert_SDMD 및 Cert_SDMD로부터 각각 획득된 공개 키 K_SDMD _- _Pub 및 K_SDMS-Pub를 사용하여 서명을 검증할 수 있다.

일 실시예에서, 도메인 구성 및 정책에 대한 요청이 생략될 수 있는데, 그 이유는 이러한 정보가 마이그레이션이 행해질 때까지는 행해졌을 수 있는 RTO 프로세스로부터 획득될 수 있다.

6b에서, RO(990)는 소스 및 목적지 도메인[TD_RO _,S(960) 및 TD_RO _,D(970)]의 정책, 구성 및 신뢰성의 허용가능성을 검사할 수 있다. (NACK 없음을 가정할 수 있는) 6 및 6a에서 소스 및 목적지 도메인으로부터 수신된 구성 정책 및 무결성 표시자의 평가에 기초하여, RO(990)는 마이그레이션을 계속하기로 또는 종료하기로 결정할 수 있다. 계속하여 7 및 7a에서, 계속하라는 메시지가 TD_RO _,S(960) 및 TD_RO,D(970)로 각각 전송될 수 있다. RO(990)가 현재 구성이 허용가능하지 않은 것으로 발견하는 경우(예컨대, 초기 RTO 이후로 구성이 변경되었을 수 있는 경우), RO(990)는 어떤 협상도 없이 마이그레이션을 종료할 수 있거나, 당사자에 허용가능하고 계속하도록 허용하는 새로운 구성 및 정책을 협상할 수 있다. 메시지가 Cert_RO로부터 획득된 공개 키 K_RO _{_} _Pub를 사용하여 검증될 수 있다.

5, 5a, 6, 및 6a에 관련된 예시적인 변형에서, 소스 및 목적지 도메인의 무결성 상태가 RO(990)에 의해 검사되지 않을 수 있다. 무결성 상태가 도메인 자체에 의해 검사될 수 있다. 즉, 소스 도메인의 무결성 상태가 목적지 도메인에 의해 검사될 수 있고, 그 반대도 마찬가지이다. 이것은 도메인이 다른 도메인의 무결성 상태를 검사할 수 있다는 점에서 RO(990)에 대한 프록시일 수 있는 것으로 가정할 수 있다.

8에서, TD_RO _,S(960)는, 예컨대, RO(990)에서 소스 및 목적지에 대한 구성, 신뢰성의 레벨 및 정책이 마이그레이션에 허용가능한지를 결정한 후에, 마이그레이션 서비스를 활성화시키기 위해 TD_RO _,D(970)로 메시지를 전송할 수 있다. 도메인 상태 요청이 발행될 수 있다. 수신자는 인증서 Cert_TSIMS를 통해 전달되는 공개 키 K_TSIMS-Pub를 사용하여 서명을 검증할 수 있다.

9 내지 12에서, 소스 및 목적지의 도메인 크리텐셜의 전송 준비 상태를 결정하기 위해 하나 이상의 동작이 취해질 수 있다. RO(990)가 소스 및 목적지 도메인의 신뢰성을 평가했고 이들이 프로토콜을 계속하기에 적당하다고 간주한 것으로 가정될 수 있다. 9에서, TD_RO _,D(970)는 목적지 사용자/소유자 도메인[SDM_D/TD_U _,D/TD_O _,D(980)]에 상태 정보(예컨대, 도메인의 이용가능 메모리의 상태를 나타냄)를 요청할 수 있다. 9a에서, 목적지 사용자/소유자 도메인[SDM_D/TD_U _,D/TD_O _,D(980)]은 상태 정보를 제공할 수 있다. Cert_SDMD(예컨대, 2에서 Cert_SDM으로 나타냄)에서 획득된 공개 키 K_SDMD _- _Pub를 사용하여 서명 검증이 수행될 수 있다. 식 9 및 식 9a는 목적지 도메인이 식 8에서의 그 정보에 대한 요청 이후에 그 자신의 상태를 획득하는 것을 나타낸다.

10에서, TD_RO _,D(970)는 상태 정보를 TD_RO _,S(960)에 제공할 수 있다(예컨대, 식 10에서, 목적지 도메인은 소스에 요청된 상태 정보를 제공한다). 10a에서, 소스 도메인은 목적지 상태 정보에 대해 검사를 수행할 수 있다. 예를 들어, 소스 도메인은 계속하기로, 지연시키기로 또는 종료하기로 결정할 수 있다. 목적지 상태 정보가 허용가능한 준비 상태(예컨대, 메모리 및 기능 능력에 관한 허용가능한 상태)를 나타내는 경우, 소스 도메인은 계속하기로 결정할 수 있다. 목적지 상태 정보가 허용가능하지 않은 준비 상태를 나타내는 경우, 소스 도메인은 요구된 소프트웨어의 다운로드가 완료될 때까지 마이그레이션을 지연시키기로 결정할 수 있다.

11에서, TD_RO _,S(960)는 소스 사용자/소유자 도메인[SDM_S/TD_U _,S/TD_O _,S(950)]에 상태 정보(예컨대, 요구된 소프트웨어의 버전 등의 마이그레이션 기능의 상태를 나타냄)를 요청할 수 있다. 11a에서, 소스 사용자/소유자 도메인[SDM_S/TD_U _,S/TD_O _,S(950)]은 상태 정보를 제공할 수 있다. 식 11 및 식 11a는 소스와 관련하여 식 9 및 식 9a의 유사한 프로세스를 제공한다. 이 정보는, 이하에서 기술하는 바와 같이, 소스의 준비 상태를 평가하기 위해 목적지 도메인으로 전달될 수 있다.

소스 사용자/소유자 도메인은 Cert_TSIMS에서 획득된 공개 키 K_TSIMS _- _Pub를 사용하여 메시지(식 11)의 서명을 검증할 수 있다(예컨대, 3 참조). 식 11a에서, 서명이 단계 3에서 Cert_SDMS에서 획득된 공개 키 K_SDMS _- _Pub를 사용하여 검증된다. 12로부터 계속하여, 서명 검증에 대한 명시적인 참조가 행해지지 않을 수 있다. 서명이 적절한 서명 키를 사용하여 나타내어질 수 있고, 적절한 경우, 인증서 전달이 또한 표시된다. 이들 경우 각각에서, 이상의 단계들에서 표시된 공개 키가 관련 서명을 검증하는 데 사용될 수 있다.

12에서, TD_RO _,S(960)는 상태 정보를 TD_RO _,D(970)에 제공할 수 있다(예컨대, 식 12는 소스가 그의 상태를 목적지에 제공하는 것을 나타낸다). 식 12는 또한 마이그레이션 OK 메시지를 전달할 수 있다. 마이그레이션이 계속될 수 있기 전에 상태 변경이 필요한 경우, 지연 메시지로 대체될 수 있다.

12a에서, 목적지 도메인은 소스 상태 정보에 대해 검사를 수행할 수 있다. 예를 들어, 목적지 도메인은 계속하기로, 지연시키기로 또는 종료하기로 결정할 수 있다. 소스 상태 정보가 허용가능한 준비 상태(예컨대, 허용가능한 최신 마이그레이션 소프트웨어)를 나타내는 경우, 목적지 도메인은 계속하기로 결정할 수 있다. 소스 상태 정보가 허용가능하지 않은 상태를 나타내는 경우, 목적지 도메인은 요구된 마이그레이션 소프트웨어가 다운로드될 때까지 마이그레이션을 지연시키기로 결정할 수 있다.

일 실시예에서, 9 내지 12에서 기술된 바와 같이 소스 도메인의 상태를 검사하는 대신에, 목적지 도메인은 수신된 패키지를 나중에 또는 패키지가 수신된 후에 검사할 수 있다. 전체 패키지가 이어서 먼저 목적지 SDM으로 전달될 필요가 있을 수 있고, 기지의 IV(Integrity Verification) 기준과 대조하여 검사될 수 있다. 안전 부트로부터 얻어지는 IV는 마이그레이션 구성 패키지로부터 계산된 IV와 상이할 수 있다.

13에서, TD_RO _,D(970)는 (예컨대, "크리텐셜 전송" 메시지에서) TD_RO _,S(960)가 크리텐셜을 전송하라는 요청을 전송할 수 있다. 13에서의 메시지는 10a 및 12a가 마이그레이션이 허용가능하다는 것을 나타낼 때 전송될 수 있다. 13a에서, TD_RO,S(960)는 크리텐셜을 TD_RO _,D(970)로 전송할 수 있다. 13b에서, TD_RO _,D(970)는 마이그레이션된 크리텐셜으로 구성될 수 있다. 지연 메시지가 전송된 경우, 타임 아웃이 일어날 수 있다(예컨대, 프로세스가 소스 및 목적지 타이머의 한계 내에서 재개되지 않는 경우).

14 내지 20에서, 해제 프로세스가 구현될 수 있다. 식 14 내지 식 20은 마이그레이션이 일어났고 소스 도메인 내에서의 크리텐셜 파기 프로세스(RO의 정책이 소스 도메인 상의 이전의 크리텐셜의 파기를 지시하는 경우)가 정책 검사 동안 행해져 이러한 파기가 허용되도록 해야 한다는 확인 응답이 교환될 수 있도록 해제를 실행하는 메시지를 포함한다.

14에서, TD_RO _,D(970)는 TD_RO _,S(960) 상의 크리텐셜이 파기되어야 하는지를 나타낼 수 있는 마이그레이션 확인 메시지를 TD_RO _,S(960)로 전송한다. 식 14는 마이그레이션이 행해졌고 목적지 장치가 새로 마이그레이션된 크리텐셜에 따라 재구성되었다는 목적지 도메인으로부터 소스로의 확인 응답을 나타낸다. 이전의 크리텐셜(소스 도메인에서의 크리텐셜)을 파기하라는 요청이 포함되어 있다. 이전의 RTO 프로세스 동안, 소스 장치의 SDM(소스 장치 소유자에 대한 프록시임) 및 RO가 임의의 마이그레이션후 파기 또는 크리텐셜을 소스 도메인 상에 계속 저장하는 것에 관한 상호 합의를 한 경우 협상이 있었을 수 있는 것으로 가정될 수 있다.

크리텐셜의 전송 후에, 소스 SDM에 의한 크리텐셜 파기에 관한 시스템 전체 정책 검사가 필요할 수 있다. 15에서, 크리텐셜 파기에 관한 정책 검사를 수행하기 위해, 메시지가 TD_RO _,S(960)로부터 소스 SDM[SDM_S/TD_U _,S/TD_O _,S(950)]으로 전송될 수 있다. 15a에서, 정책 검사가 수행될 수 있다. 식 15는 SDM에 이러한 검사를 수행하라는 소스 도메인의 요청을 나타내는 메시지를 나타낸 것이다.

16에서, 소스 사용자/소유자 도메인[SDM_S/TD_U _,S/TD_O _,S(950)]은 사용자 데이터를 목적지 사용자/소유자 도메인[SDM_D/TD_U _,D/TD_O _,D(980)]으로 전송할 수 있다. 식 16에서, 사용자 등록 데이터가 소스로부터 목적지 도메인으로 전송된다. REGDATA는 마이그레이션된 크리텐셜에 관련된 가입자 정보를 포함하는 사용자 프로필을 나타낸다. 사용자가 목적지 도메인에 액세스하여 프로토콜을 개시하려고 목적지 장치에 로그인할 수 있게 해주기 위해 최소 가입자 프로필이 사용될 수 있다.

17에서, 소스 사용자/소유자 도메인[SDM_S/TD_U _,S/TD_O _,S(950)]은 마이그레이션이 완료되었고 마이그레이션된 크리텐셜이 소스 상에서[예컨대, TD_RO _,S(960) 상에서] 파기되었는지 여부를 나타내는 메시지를 RO(990)로 전송할 수 있다. 식 17은, 크리텐셜 파기가 시스템 정책을 위반하지 않는 것으로 가정하여, RO에 크리텐셜 파기를 확인해준다. 크리텐셜 파기가 소스 시스템 정책에 의해 허용되지 않는 경우, 가능한 해결 메커니즘은 RO에 동일한 크리텐셜이 개별 장치 상에 공존할 수 있는지를 결정하라고 요구할 수 있다.

18에서, 소스 도메인은 마이그레이션이 완료되었고 크리텐셜 파기가 소스 장치 상에서 수행되었다는 것을 사용자/소유자에 통지할 수 있다. 소스 크리텐셜이 파기된 경우, 사용자는 소스 장치 상에서 가입한 서비스에 더 이상 액세스할 수 없다. 그 서비스의 사용은 이제 새로운 플랫폼으로 이전되었다. 사전-프로비저닝된 키 K_temp _{_I}(예컨대, 1 참조)는 메시지에 서명하는 데 사용될 수 있다(예컨대, 단말기/THSM 링크를 통한 통신이 기밀성에 대해 K_temp _{_C}를 사용하고 무결성 및 인증에 대해 K_{temp_I}를 사용할 것을 요구할 수 있다).

19에서, TD_RO _,D(970)는 크리텐셜을 수신하였고 구성이 수행되었다는 것을 나타내는 메시지를 RO(990)로 전송할 수 있다. 식 19는 목적지 도메인이 마이그레이션된 크리텐셜에 따라 재구성되었다는 것을 RO에 알려준다. 사용자는 이제 목적지 장치 상의 서비스(예컨대, 이전에 소스 장치 상에서 이용가능했던 서비스)에 액세스할 수 있다.

20에서, TD_RO _,D(970)가 크리텐셜을 수신했고 구성을 수행했다는 것을 나타내는 메시지가 TD_RO _,D(970)로부터 사용자/소유자(940)로 전송된다. 마이그레이션이 완료되었다는 확인 응답이 양 장치에 의해 제공될 수 있다. 통지를 받는 엔터티는 사용자/소유자 및 RO를 포함할 수 있다. 사용자가 크리텐셜 이전을 통지받는 식 18과 유사하게, 식 20은 목적지 장치에 대한 재구성이 완료되었다는 것을 사용자에게 알려준다. 이것은 사용자가 가입한 서비스가 이제 목적지 플랫폼 상에서 액세스될 수 있다는 사용자에 대한 경고를 나타낼 수 있다. 식 18에서, 서명 키는 K_temp _{_I}이고, 여기서 이 키는 목적지 장치와 연관되어 있다. 사전-프로비저닝된 키 세트 K_temp _{_C} 및 K_{temp_I}가 소스 장치와 목적지 장치 사이에서 분리된 별개의 것인 것으로 가정될 수 있다.

도 9b는 도 9a와 유사성이 있는 TSIM 도메인 마이그레이션에 대한 호 흐름도이다. 그렇지만, 9 내지 12에 예시된 바와 같이, 도 9b는 소스의 무결성 검증이 목적지 장치의 SDM에 의해 수행될 수 있고 목적지 도메인의 무결성 검증이 소스 장치의 SDM에 의해 수행될 수 있는 경우를 나타내고 있다.

9에서, 무결성 검증 정보를 소스에 요청하는 메시지가 TD_RO _,D(970)로부터 TD_RO,S(960)로 전송될 수 있다. 9a에서, 이 요청이 TD_RO _,S(960)로부터 소스 SDM[SDM_S/TD_U,S/TD_O,S(950)]으로 전달될 수 있다. 9b에서, 소스 SDM[SDM_S/TD_U,S/TD_O,S(950)]은 무결성 검증 정보를 획득한다. 10에서, 무결성 검증 정보가 소스 SDM[SDM_S/TD_U _,S/TD_O _,S(950)]로부터 TD_RO _,S(960)로 전송될 수 있다. 10a에서, 소스 무결성 검증 정보가 TD_RO _,S(960)로부터 TD_RO _,D(970)로 전송될 수 있다. 11에서, 소스 무결성 검증 정보가 TD_RO _,D(970)로부터 목적지 SDM[SDM_D/TD_U _,D/TD_O _,D(980)]로 전송될 수 있다. 메시지(10a 및 11a)에서, TD_RO _,S에서 발신되는 목적지 무결성 검증 정보에 대한 요청이 TD_RO _,D로 전송될 수 있고 이어서 목적지 SDM[SDM_D/TD_U _,D/TD_O _,D(980)]로 전송될 수 있다. 11a에서, 목적지 SDM[SDM_D/TD_U _,D/TD_O _,D(980)]은 소스 무결성 검증 정보를 검사하고 목적지 무결성 검증 정보를 준비한다. 11b에서, 소스 무결성 검증 정보의 검사는 물론, 목적지 무결성 검증 정보를 전달하는 것에 기초하여 마이그레이션을 계속할지 종료할지를 나타내는 메시지가 목적지 SDM[SDM_D/TD_U _,D/TD_O _,D(980)]으로부터 TD_RO _,D(970)으로 전송된다. 흐름 12-12C는 소스 및 목적지의 역할이 반대로 되어 있는 유사한 흐름을 나타낸다.

도 9c는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 통신 시스템(900)의 도면이다. 통신 시스템(900)은 음성, 데이터, 비디오, 메시징, 방송 등과 같은 콘텐츠를 다수의 무선 사용자에게 제공하는 다중 접속 시스템일 수 있다. 통신 시스템(900)은 다수의 무선 사용자가 시스템 자원(무선 대역폭을 포함함)의 공유를 통해 이러한 콘텐츠에 액세스할 수 있게 해줄 수 있다. 예를 들어, 통신 시스템(900)은 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) 등과 같은 하나 이상의 채널 액세스 방법을 이용할 수 있다.

도 9c에 도시된 바와 같이, 통신 시스템(900)은 WTRU(wireless transmit/receive unit)(902a, 902b, 902c, 902d), RAN(radio access network, 무선 액세스 네트워크)(904), 코어 네트워크(906), PSTN(public switched telephone network, 공중 교환 전화망)(908), 인터넷(910), 및 기타 네트워크(912)를 포함할 수 있지만, 개시된 실시예가 임의의 수의 WTRU, 기지국, 네트워크 및/또는 네트워크 요소(중계 노드, 게이트웨이, 펨토셀 기지국, 셋톱 박스 등을 포함할 수 있지만, 이들로 제한되지 않음)를 생각하고 있다는 것을 잘 알 것이다. WTRU(902a, 902b, 902c, 902d) 각각은 무선 환경에서 동작하고 및/또는 통신하도록 구성된 임의의 유형의 장치일 수 있다. 일례로서, WTRU(902a, 902b, 902c, 902d)는 무선 신호를 전송 및/또는 수신하도록 구성될 수 있고, UE(user equipment), 이동국, 고정형 또는 이동형 가입자 장치, 페이저, 휴대폰, PDA(personal digital assistant), 스마트폰, 랩톱, 넷북, 태블릿, 개인용 컴퓨터, 무선 센서, 가전 제품 등을 포함할 수 있다.

통신 시스템(900)은 또한 기지국(914a) 및 기지국(914b)을 포함할 수 있다. 기지국(914a, 914b) 각각은 하나 이상의 통신 네트워크 - 코어 네트워크(906), 인터넷(910) 및/또는 네트워크(912) 등 - 에의 액세스를 용이하게 해주기 위해 WTRU(902a, 902b, 902c, 902d) 중 적어도 하나와 무선으로 인터페이스하도록 구성된 임의의 유형의 장치일 수 있다. 일례로서, 기지국(914a, 914b)은 BTS(base transceiver station, 기지국 송수신기), 노드-B, eNode B, 홈 노드 B, 홈 eNode B, 사이트 제어기, AP(access point), 무선 라우터, 무선 지원 셋톱 박스, 무선 지원 홈 게이트웨이, 중계 노드 등일 수 있다. 기지국(914a, 914b) 각각이 단일 요소로서 나타내어져 있지만, 기지국(914a, 914b)이 임의의 수의 상호연결된 기지국 및/또는 네트워크 요소를 포함할 수 있다는 것을 잘 알 것이다.

기지국(914a)은 다른 기지국 및/또는 네트워크 요소 - BSC(base station controller), RNC(radio network controller, 무선 네트워크 제어기), 중계 노드, 기타 등등 - (도시 생략)도 포함할 수 있는 RAN(904)의 일부일 수 있다. 기지국(914a) 및/또는 기지국(914b)은 특정의 지리적 지역 - 셀(도시 생략)이라고 할 수 있음 - 내에서 무선 신호를 전송 및/또는 수신하도록 구성될 수 있다. 셀은 셀 섹터들로 추가로 나누어질 수 있다. 예를 들어, 기지국(914a)과 연관된 셀이 3개의 섹터로 나누어질 수 있다. 따라서, 일 실시예에서 기지국(914a)은 3개의 송수신기(즉, 셀의 각각의 섹터마다 하나씩)를 포함할 수 있다. 다른 실시예에서, 기지국(914a)은 MIMO(multiple-input multiple output) 기술을 이용할 수 있고, 따라서, 셀의 각각의 섹터에 대해 다수의 송수신기를 이용할 수 있다.

기지국(914a, 914b)은 임의의 적당한 무선 통신 링크[예컨대, RF(radio frequency, 무선 주파수), 마이크로파, IR(infrared, 적외선), UV(ultraviolet, 자외선), 가시광 등]일 수 있는 공중 인터페이스(916)를 통해 WTRU들(902a, 902b, 902c, 902d) 중 하나 이상과 통신할 수 있다. 임의의 적당한 RAT(radio access technology, 무선 액세스 기술)를 사용하여 공중 인터페이스(916)가 설정될 수 있다.

보다 구체적으로는, 앞서 살펴본 바와 같이, 통신 시스템(900)은 다중 접속 시스템일 수 있고, CDMA, TDMA, FDMA, OFDMA, SC-FDMA 등과 같은 하나 이상의 채널 액세스 방식을 이용할 수 있다. 예를 들어, RAN(904) 내의 기지국(914a) 및 WTRU(902a, 902b, 902c)는 WCDMA(wideband CDMA, 광대역 CDMA)를 사용하여 공중 인터페이스(916)를 설정할 수 있는 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, 고속 상향링크 패킷 액세스)를 포함할 수 있다.

다른 실시예에서, 기지국(914a) 및 WTRU(902a, 902b, 902c)는 LTE(Long Term Evolution) 및/또는 LTE-A(LTE-Advanced)를 사용하여 공중 인터페이스(916)를 설정할 수 있는 E-UTRA(Evolved UMTS Terrestrial Radio Access)와 같은 무선 기술을 구현할 수 있다.

다른 실시예에서, 기지국(914a) 및 WTRU(902a, 902b, 902c)는 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) 등과 같은 무선 기술을 구현할 수 있다.

도 9c의 기지국(914b)은, 예를 들어, 무선 라우터, 홈 노드 B, 홈 eNode B, 또는 액세스 포인트일 수 있고, 사업장, 가정, 차량, 캠퍼스 등과 같은 국소화된 지역에서의 무선 연결을 용이하게 해주는 임의의 적당한 RAT를 이용할 수 있다. 일 실시예에서, 기지국(914b) 및 WTRU(902c, 902d)는 WLAN(wireless local area network)을 설정하기 위해 IEEE 802.11과 같은 무선 기술을 구현할 수 있다. 다른 실시예에서, 기지국(914b) 및 WTRU(902c, 902d)는 WPAN(wireless personal area network)을 설정하기 위해 IEEE 802.15와 같은 무선 기술을 구현할 수 있다. 또 다른 실시예에서, 기지국(914b) 및 WTRU(902c, 902d)는 피코셀 또는 펨토셀을 설정하기 위해 셀룰러-기반 RAT(예컨대, WCDMA, CDMA2000, GSM, LTE, LTE-A 등)를 이용할 수 있다. 도 9c에 도시된 바와 같이, 기지국(914b)은 인터넷(910)에의 직접 연결을 가질 수 있다. 따라서, 기지국(914b)은 코어 네트워크(906)를 통해 인터넷(910)에 액세스할 필요가 없을 수 있다.

RAN(904)은 음성, 데이터, 응용 프로그램, 및 VoIP(voice over internet protocol) 서비스를 WTRU들(902a, 902b, 902c, 902d) 중 하나 이상의 WTRU에 제공하도록 구성된 임의의 유형의 네트워크일 수 있는 코어 네트워크(906)와 통신하고 있을 수 있다. 예를 들어, 코어 네트워크(906)는 호출 제어, 대금 청구 서비스, 모바일 위치-기반 서비스, 선불 전화(pre-paid calling), 인터넷 연결, 비디오 배포 등을 제공하고 및/또는 사용자 인증과 같은 고수준 보안 기능을 수행할 수 있다. 도 9c에 도시되어 있지는 않지만, RAN(904) 및/또는 코어 네트워크(906)가 RAN(904)와 동일한 RAT 또는 상이한 RAT를 이용하는 다른 RAN과 직접 또는 간접 통신을 하고 있을 수 있다는 것을 잘 알 것이다. 예를 들어, E-UTRA 무선 기술을 이용하고 있을 수 있는 RAN(904)에 연결되는 것에 부가하여, 코어 네트워크(906)는 또한 GSM 무선 기술을 이용하는 다른 RAN(도시 생략)과 통신하고 있을 수 있다.

코어 네트워크(906)는 또한 WTRU(902a, 902b, 902c, 902d)가 PSTN(908), 인터넷(910) 및/또는 다른 네트워크(912)에 액세스하기 위한 게이트웨이로서 역할할 수 있다. PSTN(908)은 POTS(plain old telephone service)를 제공하는 회선-교환 전화 네트워크를 포함할 수 있다. 인터넷(910)은 TCP/IP 인터넷 프로토콜군 내의 TCP(transmission control protocol, 전송 제어 프로토콜), UDP(user datagram protocol, 사용자 데이터그램 프로토콜) 및 IP(internet protocol, 인터넷 프로토콜)와 같은 공통의 통신 프로토콜을 사용하는 상호연결된 컴퓨터 네트워크 및 장치의 전세계 시스템을 포함할 수 있다. 네트워크(912)는 다른 서비스 공급자가 소유하고 및/또는 운영하는 유선 또는 무선 통신 네트워크를 포함할 수 있다. 예를 들어, 네트워크(912)는 RAN(904)와 동일한 RAT 또는 상이한 RAT를 이용할 수 있는 하나 이상의 RAN에 연결된 다른 코어 네트워크를 포함할 수 있다.

통신 시스템(900) 내의 WTRU들(902a, 902b, 902c, 902d) 중 일부 또는 전부는 다중-모드 기능을 포함할 수 있다 - 즉, WTRU(902a, 902b, 902c, 902d)가 상이한 무선 링크를 통해 상이한 무선 네트워크와 통신하기 위한 다수의 송수신기를 포함할 수 있다 -. 예를 들어, 도 9c에 도시된 WTRU(902c)는 셀룰러-기반 무선 기술을 이용할 수 있는 기지국(914a)과 통신하도록, 그리고 IEEE 802 무선 기술을 이용할 수 있는 기지국(914b)과 통신하도록 구성될 수 있다.

Claims

하나 이상의 장치를 포함하는 시스템에서의 방법으로서,
상기 장치 각각은 하나 이상의 도메인을 포함하고, 각각의 도메인은 상기 하나 이상의 장치 상에서 실행하는 컴퓨팅 자원의 구성을 포함하고 각각의 도메인은 상기 도메인으로부터 원격적으로 또는 로컬적으로 위치될 수 있는 상기 도메인의 소유자에 대한 기능을 수행하도록 구성되며, 각각의 도메인은 상이한 소유자를 가질 수 있고, 적어도 하나의 도메인은 상기 하나 이상의 장치의 사용자에 의해 소유되며, 적어도 하나의 다른 도메인은 원격 소유자에 의해 소유되고,
상기 방법은,
마이그레이션이 요청되었다는 것 - 제1 도메인 또는 상기 제1 도메인과 연관된 크리텐셜 중 적어도 하나가 소스 장치로부터 목적지 장치로 마이그레이션됨 - 을 나타내는 메시지를 수신하는 단계;
상기 소스 장치로부터 수신된 소스 정보 및 상기 목적지 장치로부터 수신된 목적지 정보를 평가하는 단계;
상기 평가하는 단계에 기초하여 상기 마이그레이션이 허용가능하다고 결정하는 단계; 및
상기 마이그레이션을 진행하라는 표시를 전송하는 단계를 포함하는 방법.
제1항에 있어서,
상기 소스 정보는 소스 정책, 소스 구성, 소스 ID(source identification), 또는 소스 무결성 표시자(source integrity indicator) 중 적어도 하나를 포함하고,
상기 목적지 정보는 목적지 정책, 목적지 구성, 목적지 ID(destination identification), 또는 목적지 무결성 표시자(destination integrity indicator) 중 적어도 하나를 포함하는 것인 방법.
제1항에 있어서,
원격 소유자 정책을 평가하는 단계; 및
상기 원격 소유자 정책에 기초하여 상기 마이그레이션이 허용가능하다고 결정하는 단계를 더 포함하는 방법.
제1항에 있어서,
상기 소스 정보는 소스 시스템 전체 도메인 관리자(source system-wide domain manager)가 상기 마이그레이션을 승인했다는 것을 나타내는 것인 방법.
제4항에 있어서,
상기 소스 정보는 또한 상기 마이그레이션이 상기 소스 장치의 상기 제1 도메인과 연관된 제1 정책 및 제2 도메인과 연관된 제2 정책을 위반하지 않는다는 것을 나타내고, 상기 제1 도메인은 제1 원격 소유자에 의해 소유되면, 상기 제2 도메인은 제2 원격 소유자에 의해 소유되는 것인 방법.
제1항에 있어서,
상기 마이그레이션이 완료되었다는 것과 상기 소스 장치가 상기 크리텐셜을 파기했는지 여부를 나타내는 소스 완료 메시지를 수신하는 단계; 및
상기 마이그레이션이 완료되었다는 것 - 상기 제1 도메인 또는 상기 크리텐셜 중 적어도 하나가 상기 목적지 장치의 도메인 상에 복제되었음 - 을 나타내는 목적지 완료 메시지를 수신하는 단계
를 더 포함하는 방법.
제6항에 있어서,
상기 소스 완료 메시지는 소스 시스템 전체 도메인 관리자가 상기 목적지 장치의 상태를 검증했다는 것을 나타내고,
상기 목적지 완료 메시지는 목적지 시스템 전체 도메인 관리자가 상기 소스 장치의 상태를 검증했다는 것을 나타내는 것인 방법.
제6항에 있어서,
상기 소스 완료 메시지는 소스 시스템 전체 도메인 관리자가 상기 목적지 장치의 무결성을 검증했다는 것을 나타내고,
상기 목적지 완료 메시지는 목적지 시스템 전체 도메인 관리자가 상기 소스 장치의 무결성을 검증했다는 것을 나타내는 것인 방법.
제1항에 있어서,
상기 메시지는 상기 마이그레이션이 사용자에 의해 요청되었다는 것을 나타내는 것인 방법.
하나 이상의 장치를 포함하는 시스템으로서,
상기 장치 각각은 하나 이상의 도메인을 포함하고, 각각의 도메인은 상기 하나 이상의 장치 상에서 실행하는 컴퓨팅 자원의 구성을 포함하고 각각의 도메인은 상기 도메인으로부터 원격적으로 또는 로컬적으로 위치될 수 있는 상기 도메인의 소유자에 대한 기능을 수행하도록 구성되며, 각각의 도메인은 상이한 소유자를 가질 수 있고, 적어도 하나의 도메인은 상기 하나 이상의 장치의 사용자에 의해 소유되며, 적어도 하나의 다른 도메인은 원격 소유자에 의해 소유되고,
상기 하나 이상의 장치 중 적어도 하나의 장치는,
마이그레이션이 요청되었다는 것 - 제1 도메인 또는 상기 제1 도메인과 연관된 크리텐셜 중 적어도 하나가 소스 장치로부터 목적지 장치로 마이그레이션됨 - 을 나타내는 메시지를 수신하고;
상기 소스 장치로부터 수신된 소스 정보 및 상기 목적지 장치로부터 수신된 목적지 정보를 평가하며;
상기 평가에 기초하여 상기 마이그레이션이 허용가능하다고 결정하고;
상기 마이그레이션을 진행하라는 표시를 전송하도록 구성되는 것인 시스템.
제10항에 있어서,
상기 소스 정보는 소스 정책, 소스 구성, 소스 ID, 또는 소스 무결성 표시자 중 적어도 하나를 포함하고,
상기 목적지 정보는 목적지 정책, 목적지 구성, 목적지 ID, 또는 목적지 무결성 표시자 중 적어도 하나를 포함하는 것인 시스템.
제10항에 있어서,
상기 하나 이상의 장치 중 적어도 하나의 장치는 또한,
원격 소유자 정책을 평가하고;
상기 원격 소유자 정책에 기초하여 상기 마이그레이션이 허용가능하다고 결정하도록 구성되는 것인 시스템.
제10항에 있어서,
상기 소스 정보는 소스 시스템 전체 도메인 관리자가 상기 마이그레이션을 승인했다는 것을 나타내는 것인 시스템.
제13항에 있어서,
상기 소스 정보는 또한 상기 마이그레이션이 상기 소스 장치의 상기 제1 도메인과 연관된 제1 정책 및 제2 도메인과 연관된 제2 정책을 위반하지 않는다는 것을 나타내고, 상기 제1 도메인은 제1 원격 소유자에 의해 소유되며, 상기 제2 도메인은 제2 원격 소유자에 의해 소유되는 것인 시스템.
제10항에 있어서,
상기 하나 이상의 장치 중 적어도 하나의 장치가 또한
상기 마이그레이션이 완료되었다는 것과 상기 소스 장치가 상기 크리텐셜을 파기했는지 여부를 나타내는 소스 완료 메시지를 수신하고;
상기 마이그레이션이 완료되었다는 것 - 상기 제1 도메인 또는 상기 크리텐셜 중 적어도 하나가 상기 목적지 장치의 도메인 상에 복제되었음 - 을 나타내는 목적지 완료 메시지를 수신하도록 구성되는 것인 시스템.
제15항에 있어서,
상기 소스 완료 메시지는 소스 시스템 전체 도메인 관리자가 상기 목적지 장치의 상태를 검증했다는 것을 나타내고,
상기 목적지 완료 메시지는 목적지 시스템 전체 도메인 관리자가 상기 소스 장치의 상태를 검증했다는 것을 나타내는 것인 시스템.
제15항에 있어서,
상기 소스 완료 메시지는 소스 시스템 전체 도메인 관리자가 상기 목적지 장치의 무결성을 검증했다는 것을 나타내고,
상기 목적지 완료 메시지는 목적지 시스템 전체 도메인 관리자가 상기 소스 장치의 무결성을 검증했다는 것을 나타내는 것인 시스템.
제10항에 있어서,
상기 메시지는 상기 마이그레이션이 사용자에 의해 요청되었다는 것을 나타내는 것인 시스템.