KR101434769B1

KR101434769B1 - 신뢰적인 연합 아이덴티티 관리 및 데이터 액세스 인가를 위한 방법 및 장치

Info

Publication number: KR101434769B1
Application number: KR1020127022007A
Authority: KR
Inventors: 인혁 차; 안드레아스 슈미트; 안드레아스 라이허; 요겐드라 씨 샤
Original assignee: 인터디지탈 패튼 홀딩스, 인크
Priority date: 2010-01-22
Filing date: 2011-01-21
Publication date: 2014-08-27
Also published as: US20150067813A1; CN102763111A; TWI510108B; CN102763111B; US20120023568A1; EP2526504A1; KR20120120346A; US8881257B2; JP2015165702A; WO2011091313A1; CN105072088A; JP5744915B2; JP2013518326A; TW201204067A

Abstract

OpenID와 신뢰적인 OpenID(TOpenID)의 통합을 제공할 수 있는 시스템, 방법, 및 수단이 개시된다. UE상의 신뢰적인 티켓 서버와 네트워크 애플리케이션 기능부간의 통신을 통해 부분적으로 인증이 달성될 수 있다. UE는 (예컨대, UE상의 신뢰적인 플랫폼 모듈로부터) 플랫폼 입증 데이터를 검색할 수 있다. UE는 플랫폼 입증 데이터에 응답하여 플랫폼 검증을 수신할 수 있다. 플랫폼 검증은 네트워크 애플리케이션 기능부가 플랫폼 입증 데이터 및 사용자를 검증하였다는 것을 나타낼 수 있다. 플랫폼 검증은 플랫폼 입증 데이터가 이전에 생성된 참조값과 매칭한다는 것을 나타낼 수 있다.

Description

신뢰적인 연합 아이덴티티 관리 및 데이터 액세스 인가를 위한 방법 및 장치{METHOD AND APPARATUS FOR TRUSTED FEDERATED IDENTITY MANAGEMENT AND DATA ACCESS AUTHORIZATION}

본 출원은 2010년 1월 22일에 출원된 미국 가특허 출원 제61/297,446호에 기초하고, 이 출원의 우선권을 청구하며, 이 가특허 출원의 내용은 그 전체가 참조로서 본 명세서내에 병합된다.

인증을 위한 신뢰적인 컴퓨팅(Trusted Computing; TC)의 기초적인 이용은 예컨대 하드웨어 신뢰적 플랫폼 모듈(trusted platform module; TPM)에 의해 보호된 신뢰적인 시스템(Trusted System; TS)에 인증용 크레덴셜(credential)들을 제공하는 것일 수 있다. 주요 보안 특징으로서, 이것은 크레덴셜들을 특정 TS에 바인딩시킬 수 있다. 무선 네트워크들에서의 이러한 인증의 애플리케이션은 확장가능한 인가 프로시저 전송층 보안(extensible authorization procedure-transport layer security; EAP-TLS)을 통해 행해질 수 있다. TS와의 단일 서명(single sign-on; SSO)의 이용은 잠재적인 보안 문제들을 제시할 수 있다.

OpenID와, 여기서 개시된 바와 같은 신뢰적인 OpenID(trusted OpenID; TOpenID)의 통합을 제공할 수 있는 시스템, 방법, 및 수단이 개시된다.

예컨대, 사용자 장비(user equipment; UE)와 같은, 무선 디바이스의 사용자는 예컨대, 네트워크 애플리케이션 기능부로부터의 인증 요청에 응답하여 인증될 수 있다. UE상의 신뢰적인 티켓 서버(trusted ticket server; TTS)는 (예컨대, UE상의 신뢰적인 플랫폼 모듈로부터) 플랫폼 입증 데이터를 검색할 수 있다. 플랫폼 입증 데이터는 무선 디바이스의 신뢰성의 표시(measure)를 포함할 수 있다. TTS는 플랫폼 입증 데이터를 네트워크 애플리케이션 기능부에 보낼 수 있다. UE는 네트워크 애플리케이션 기능부가 플랫폼 입증 데이터 및 사용자를 검증하였다는 것을 나타내는 플랫폼 검증을 수신할 수 있다. 네트워크 애플리케이션 기능부로부터 수신된 플랫폼 검증은 플랫폼 입증 데이터에 의해 나타난 시스템 상태가 이전에 생성된 참조값과 매칭한다는 것을 나타낼 수 있다.

UE는 플랫폼 검증을 포함한 티켓을 수신할 수 있다. 티켓은 무선 디바이스의 재입증없이 후속하는 인가를 수행하기 위해 재사용되는 것이 가능할 수 있다. 티켓은 타임스탬프, 수명 한도 등을 포함할 수 있다.

UE는 네트워크 엔티티로부터 티켓 참조를 수신할 수 있다. 티켓 참조는 네트워크 애플리케이션 기능부로부터 티겟을 획득하기 위해 이용되는 것이 가능할 수 있다. 티켓에 포함된 플랫폼 검증은 무선 디바이스의 재입증없이 후속하는 인가를 수행하기 위해 재사용되는 것이 가능할 수 있다.

보다 자세한 이해는 첨부된 도면들을 참조하면서 예시를 통해 주어진 아래의 상세한 설명으로부터 얻어질 수 있다.
도 1은 예시적인 인증 및 액세스 시스템을 도시한다.
도 1a는 신뢰적인 커버러스(Kerberos)와 관련된 예시적인 콜 흐름을 도시한다.
도 2는 신뢰적인 OpenID와 관련된 예시적인 콜 흐름을 도시한다.
도 3a와 도 3b는 신뢰적인 티켓 서버 챌런지 응답과 관련된 예시적인 콜 흐름을 도시한다.
도 4는 신뢰적인 OpenID와 관련된 예시적인 방법을 도시한다.
도 5는 UICC와 WTRU를 바인딩시키는 것과 관련된 예시적인 콜 흐름도를 도시한다.
도 6은 컴포넌트들간의 예시적인 관계를 도시한다.
도 7은 신뢰 평가자로서의 PVE의 예시를 도시한다.
도 8은 예시적인 TVT 로그 온을 도시한다.
도 9는 또 다른 예시적인 TVT 로그 온을 도시한다.
도 10은 또 다른 예시적인 TVT 로그 온을 도시한다.
도 11은 TVT 로그 온과 관련된 예시적인 시각적 표시들을 제공한다.
도 12는 신뢰적인 컴퓨팅 개념들에 기초한 플랫폼상에서의 TVT의 예시적인 구현을 제공한다.
도 13은 TOpenID와의 BONDI의 예시적인 이용을 도시한다.
도 14는 TOpenID와의 BONDI의 이용을 위한 예시적인 콜 흐름도를 도시한다.
도 15는 예시적인 OpenID 프로토콜의 도면이다.
도 16은 예시적인 OAuth 프로토콜의 도면이다.
도 17은 예시적인 결합된 OpenID/OAuth 프로토콜의 도면이다.
도 18은 구글 OpenID를 갖는 예시적인 OpenID 프로토콜의 도면이다.
도 19는 구글 API를 이용한 예시적인 OAuth 프로토콜의 도면이다.
도 20은 예시적인 롱 텀 에볼루션(Long Term Evolution; LTE) 무선 통신 시스템/액세스 네트워크를 도시한다.
도 21은 예시적인 LTE 무선 통신 시스템을 도시한다.

도 1 내지 도 21은 개시된 시스템, 방법 및 수단이 구현될 수 있는 예시적인 실시예들과 관련된 것일 수 있다. 하지만, 본 발명은 예시적인 실시예들과 관련하여 기술될 수 있지만, 이것으로 제한되지는 않으며, 본 내용으로부터 일탈하지 않고서 본 발명의 동일한 기능을 수행하기 위해 다른 실시예들이 이용될 수 있거나 또는 수정과 추가가 설명된 실시예들에 대해 행해질 수 있다는 것을 이해해야 한다. 더 나아가, 도면들은 콜 흐름들을 나타낼 수 있으며, 이것은 예시적이라는 것을 의미한다. 다른 실시예들이 이용될 수 있다는 것을 이해해야 한다. 더 나아가, 흐름들의 순서는 적절하게 변할 수 있다. 게다가, 흐름들은 필요하지 않는다면 생략될 수 있고 추가적인 흐름들이 추가될 수 있다.

이하에서 언급시, 용어 "무선 송수신 유닛(WTRU)"은 사용자 장비(UE), 이동국, 고정 가입자 유닛 또는 이동 가입자 유닛, 호출기, 셀룰러 전화기, 개인 보조 단말기(PDA), 컴퓨터, 또는 무선 환경에서 동작할 수 있는 임의의 다른 유형의 사용자 장치를 포함하나, 이러한 예시들에 한정되는 것은 아니다. 이하에서 언급시, 용어 "기지국"은 노드 B, 싸이트 제어기, 액세스 포인트(AP), 또는 무선 환경에서 동작할 수 있는 임의의 다른 유형의 인터페이싱 장치를 포함하나, 이러한 예시들로 한정되는 것은 아니다.

여기서의 개시내용은 예시적인 인증 및 액세스 시스템으로서 OpenID 프로토콜을 이용할 수 있으며 다른 인증 및 액세스 시스템에 적용가능하다. 설명을 위해, 다양한 실시예들은 제3세대 파트너쉽(Third Generation Partnership; 3 GPP) 환경에서 설명되지만, 다양한 실시예들이 임의의 무선 통신 기술로 구현될 수 있다. 몇몇의 예시적인 유형들의 무선 통신 기술들은, 비제한적인 예시로서 WiMAX(Worldwide Interoperability for Microwave Access) 802.xx, GSM(Global System for Mobile communication), CDMA2000(Code Division Multiple Access), UMTS(Universal Mobile Telecommunications System), LTE(Long Term Evolution), 또는 임의의 미래의 기술을 포함할 수 있다.

도 1은 비제한적인 예시로서, 클라이언트/사용자 플랫폼(110), 아이덴티티 제공자(120), 프라이버시 인증 기관(privacy certification authority; PCA)(130) 및 서비스 제공자(140)를 포함한 예시적인 인증 및 액세스 시스템(100)을 나타낸다. 클라이언트/사용자 플랫폼(110), 아이덴티티 제공자(120), 및 서비스 제공자(140)는 무선 및 유선 통신 시스템들의 임의의 조합을 통해 서로 통신할 수 있다. 클라이언트/사용자 플랫폼(110)은 PCA(130)와 통신할 수 있으며, PCA(130)는 예컨대 인증서들을 저장할 수 있는 저장 매체(160)와 통신할 수 있다.

클라이언트/사용자 플랫폼(110)은 WTRU, 기지국, 컴퓨팅 플랫폼, 또는 인증을 필요로 할 수 있는 임의의 디바이스일 수 있다. 클라이언트/사용자 플랫폼(110)은, 비제한적인 예시로서, 클라이언트/사용자 플랫폼(110)을 위한 데이터에 대한 원격 증명 및 실링 및 바인딩 능력들을 제공하는 신뢰적인 플랫폼 모듈(TPM)(115)을 포함할 수 있다. TPM(115)은 키들, 패스워드들, 디지털 인증서들을 저장하며 암호키들을 생성시킬 수 있는 마이크로제어기일 수 있다. TPM(115)은 마더보드에 부착되거나, 시스템의 칩셋내로 통합될 수 있고, 이러한 기능들을 필요로 할 수 있는 임의의 컴퓨팅 디바이스에서 이용될 수 있다. TPM(115)은 예컨대 외부 소프트웨어 공격, 물리적 부당 변경, 도청 등으로부터 자신의 정보를 보호할 수 있다. 부트 시퀀스 동안의 컴포넌트들에 대해 취해진 측정값이 보안 이메일, 보안 웹 액세스, 및 데이터 안전 보안의 국지적 보호와 같은 능력들 및 애플리케이션들을 행할 수 있는 참조 측정에 비해 예상된 것이 아니라면 TPM(115) 또는 클라이언트/사용자 플랫폼(110)에서의 시크릿 및 데이터에 대한 액세스는 거부될 수 있다. 여기서는 신뢰적 플랫폼 모듈이 논의되지만, 예컨대 모바일 신뢰적 모듈과 같은 다른 신뢰 센터들이 이용될 수 있다.

TPM(115)은 제조시에 칩상에서 무작의적으로 생성되고 변경될 수 없는 서명키(endorsement key; EK), 예컨대 2048 비트 리베스트 샤미르 아델만(Rivest-Shamir-Adelman; RSA) 공개 및 개인키 쌍을 이용할 수 있다. 개인키는 칩으로 제한될 수 있는 반면에, 공개키는 칩으로 보내진 민감한 데이터의 암호화 및 증명을 위해 이용된다. EK의 공개 부분들은 일반적으로 증명을 위한 EK 인증서를 통해 PCA(130)에 의해 알려질 수 있다. TPM(115)이 예컨대 아이덴티티 제공자와 같은 검증자에 대해 자신을 인증할 필요가 있을 때, TPM(115)은 증명 아이덴티티 키(attestation identity key; AIK)라고 불리우는 제2 RSA 키 쌍을 생성하고, AIK 공개키를 PCA(130)에 보내고, 이 공개키를 대응하는 EK에 대해 인증할 수 있다. PCA(130)가 이 EK를 자신의 리스트에서 발견한 경우, TPM(115)의 AIK에 대한 인증서를 발행할 수 있다. 그런 후 TPM(115)은 이 인증서를 아이덴티티 제공자(120)에게 제공하고 자신을 인증할 수 있다.

AIK들(적어도 AIK에서 구현된 아이덴티티)은 여기서 설명된 티켓의 적어도 일 부분을 표현할 수 있다. 티켓에서의 AIK들의 활용은 TPM(115)에 의해 제한될 수 있다. 서명키(signing key)가 TPM(115)에 의해 생성되어 AIK로 서명하여 인증되는 CertifyKey 동작이라고 칭해지는 간접적 접근법이 이용될 수 있다. 이 키는 인증된 서명키(certified signing key; CSK)라고 칭해질 수 있다. AIK의 유효성에 대해 입증하는 PCA와 함께, CSK 및 AIK는 여기서 설명된 티켓의 부분을 구성할 수 있다.

클라이언트/사용자 플랫폼(110)은 서비스 액세스를 위한 크레덴셜들, 또는 티켓들을 생성하는 신뢰적인 티켓 서버(trusted ticket server; TTS)(150)를 포함할 수 있다. 여기서 신뢰적인 OpenID와 관련하여 티켓서버를 언급할 때, 이러한 언급은 신뢰적인 티켓 서버에 대한 것일 수 있다. TTS(150)는 사용자를 인증할 수 있다. TTS(150)는 예컨대 플랫폼 증명의 신뢰적인 컴퓨팅 방법을 이용하여 클라이언트/사용자 플랫폼(110) 및 그 자신을 아이덴티티 제공자(120)에 대해 입증시킬 수 있다. 보안 정보 및 동작들은 TTS(150)에서 집중될 수 있기 때문에, TTS(150)는 AIK 인증서들 및 CSK들을 적절하게 처리하고 이것들을 다른 플랫폼들에게 확산시키지 않고; 티켓들 및 크레덴셜들을 보호하고; 사용자 인가에 의해 크레덴셜들에 대한 보안 동작들을 보호하고; 공통 웹 브라우저들내로 병합되고 이들에 의해 액세스될 보안 옵션들을 제공하며; 플랫폼 입증 데이터를 수집하고, 프로세싱하고 보내도록 하기 위해 신뢰적일 필요가 있을 수 있다.

사용자는 TPM(115)에서 생성된 AIK들을 인증하기 위해 PCA(130)을 선택할 필요가 있을 수 있다. PCA(130)는 아이덴티티 관련 정보를 보유할 수 있고, 이 아이덴티티 관련 정보의 비공개를 보장하기 위해 계약적 조치들이 취해질 필요가 있을 수 있다. PCA(130)에서 AIK를 인증한 후, 사용자는 청구된 아이덴티티를 호스팅하기 위해 아이덴티티 제공자(120)를 선택할 수 있다. 청구된 아이덴티티는 사용자에 의해 선택된 유니버셜 자원 식별자(universal resource identifier; URI)에 의해 표현될 수 있다. 이러한 청구된 아이덴티티를 등록하기 위해, 사용자는 유효한 AIK 인증서를 아이덴티티 제공자(120)에 제공할 것을 필요로 할 수 있다.

아이덴티티 제공자(120)는 최소량의 아이덴티티 관련 정보를 제공받을 수 있다. 사용자는 PCA(130)에서 호스팅된 어느 정보를 아이덴티티 제공자(120)에게 공개할지를 결정할 수 있다. 당사자들간의 조정을 보장하도록 계약적 조치들이 취해질 필요가 있을 수 있고, 그렇지 않은 경우, 부정한 PCA가 상이한 사용자에 속한 아이덴티티들을 인증하는 것이 가능할 수 있다. PCA(130)는 사용자의 실제 아이덴티티를 아이덴티티 제공자(120)에게 공개하지 않을 수 있기 때문에, 아이덴티티 제공자(120)는 상이한 요청들을 단일 아이덴티티에 링크시키지 못할 수 있다.

청구된 아이덴티티를 실제 아이덴티티로 풀어내는 능력은 PCA(130)로 제한될 수 있다. 이것은 (고유한) EK 인증서들을 AIK들에 맵핑한 보안화된 데이터베이스를 유지함으로써 행해질 수 있다. AIK 인증 동안에 이용된 EK 인증서들은 TPM(115)의 식별 및 이에 따라 클라이언트/사용자 플랫폼(110)의 식별을 허용할 수 있다(예컨대, 하나의 사용자는 플랫폼(110)에 대한 물리적 액세스를 갖는 것으로 가정하면, 이것은 사용자에 대해 해결된다).

서비스 제공자(140)는 싸이트에 대한 아이덴티티 제공자 로그인을 인에이블시킬 수 있다. 예를 들어, 서비스 제공자(140)는 맨앞 페이지상에서 OpenID 로그인 로고를 가질 수 있다. 사용자/클라이언트에 의해 이용된 아이덴티티 제공자(120)는 서비스 제공자(140)의 알려지고 수락된 아이덴티티 제공자들의 리스트에 있을 것을 요구받을 수 있다.

연합 아이덴티티 또는 단일 서명(SSO) 기법들은 사용자가 단일 크레덴셜을 이용하여 여러 개의 보안 싸이트들상에 로그온할 수 있게 하는 사용자 친화적인 방법들을 제공할 수 있다. 여러 형태들의 연합 아이덴티티 기법들의 구현이 가능할 수 있지만, 여기서의 개시내용은 예로서 OpenID를 이용하는 신뢰적인 개념들의 개략내용을 제공한다. 다른 방법들, 예컨대, 사용자, 디바이스 및 네트워크간의 신뢰적인 컴퓨팅 기술들 및 바인딩 인증을 이용한 애플리케이션들 및 인터넷 기반 서비스들에 대한 단일 서명(SSO) 액세스가 적용될 수 있다.

OpenID는 사용자를 인증하는 상이한 인증 방법들을 허용할 수 있다. OpenID 제공자에서 아이덴티티를 청구하기 위해, 여러 방법들이 이용될 수 있다. 하나의 방법은 로그온 형태들의 이용일 수 있고, 여기서 사용자는 패스워드를 제공한다.

이 로그온은 TPM 기반 로그온 프로세스로 대체될 수 있다. 사용자는 자신의 특정 플랫폼, 예컨대 TPM에 강하게 바인딩된 아이덴티티를 등록할 수 있다. 사용자가 이 아이덴티티를 이용하여 로그인할 것을 결정한 경우, OpenID 제공자는 사용자에게 정확한 크레덴셜들을 제공할 것을 챌런징할 수 있다. 이 경우, 크레덴셜들은 TPM 생성된 티켓, 예컨대 크레덴셜 체인을 포함할 수 있다. 이것은 사용자가 OpenID 제공자에서의 패스워드에 대한 필요성 없이 로그인할 수 있도록 해줄 수 있다. 사용자의 컴퓨터에서의 로컬 패스워드는 로컬 공격들로부터 아이덴티티를 보호하기 위해 이용될 수 있다.

로그온은 특정 플랫폼의 무결성 검증과 결합될 수 있다. 시스템 구성 값들에 대한 TPM 서명된 스테이트먼트(statement)를 이용함으로써, OpenID 제공자는 보고된 시스템 상태를 이전에 생성된 참조값들과 비교할 수 있다. 이 프로시저는 신뢰할 수 있는 클라이언트들이 로그인하고 아이덴티티를 청구할 수 있도록 해줄 수 있다. 이 결합된 인증 및 증명은 인증 데이터를 특정 플랫폼에 바인딩시키고 미리정의된 시스템 상태에 바인딩시킴으로써(이것은 신뢰할 수 있는 것으로 간주될 수 있음), 미세하게 그레이닝된(fine grained) 액세스 제어를 가능하게 해줄 수 있다. 이것은 시스템의 강화된 보안 및 안전을 필요로 할 수 있고, 이에 따라 비신뢰적인 시스템을 야기시키는 수정을 허용하지 않을 수 있는 OpenID에 대한 새로운 이용 경우들의 인에이블을 가능하게 해줄 수 있다. 논의한 실시예들은 TPM에 기초하지만, 예컨대 모바일 투 모바일(mobile to mobile; MTM) 또는 신뢰적인 환경과 같은, 다른 신뢰적인 시스템 파생들이 또한 가능할 수 있다.

신뢰적인 커버러스(trusted Kerberos; TKerberos) 개념은 예컨대 인증 서버(Authentication Server; AS) 및/또는 티켓 승인 서버(Ticket Granting Server; TGS)와 같은 두 개의 서버들에 의존할 수 있다. 이러한 서버들 각각은 티켓들을 발행할 수 있다. 각각의 티켓은 두 개의 부분들을 포함할 수 있다. 예를 들어, 하나의 부분은 다음 타켓 서버를 위해 암호화될 수 있고 이에 따라 클라이언트에 의해 암호해독되지 않을 수 있다. 이 부분은 다음 통신 단계에 의해 이용될 수 있는 세션키를 포함할 수 있다. 세션키는 티켓의 제2 부분에서 클라이언트에 대해 암호화될 수 있다. 만약 클라이언트가 제2 부분을 암호해독할 수 있다면, 클라이언트는 다음 티켓을 요청하기 위해 세션키를 획득할 수 있다.

TKerberos는 예컨대 이어지는 단계들에서 수행될 수 있다. 예를 들어, 티켓 승인 티켓(ticket granting ticket; TGT)이 AS로부터 요청되고 및/또는 수신될 수 있고 미래의 이용을 위해 저장될 수 있다. 서비스 티켓(service ticket; ST) 요청에 대한 인증 데이터를 암호화하기 위해 세션키는 암호해독될 수 있다. TGT는 암호화된 인증부호(authenticator)와 함께 TGS로 보내질 수 있다. ST는 TGS로부터 수신될 수 있다. 서비스 요청에 대한 인증 데이터를 암호화하기 위해 세션키는 암호해독될 수 있다. ST는 암호화된 인증부호와 함께 서비스 제공자에게 보내질 수 있다.

TKerberos 프로토콜은 TC를 이용할 수 있다. 설계는 예컨대, TPM을 통해 티켓들을 사용자의 티켓 서버(Ticket Server; TS)에 밀접하게 바인딩시키고, 및/또는 서비스에 액세스하는 사용자의 프라이버시를 보고하기 위한 수단을 제공함으로써 보안성을 강화시키기 위함과 같은 목표들을 가질 수 있다.

AS는 PCA의 역할을 수행할 수 있고 및/또는 TGT는 AIK 인증서로서 역할을 할 수 있다. 티켓 취득 프로세스는 플랫폼이 티켓들을 미리 캐싱하고 이 티켓들을 서비스 액세스를 위해 개별화할 수 있도록 TKerberos에서 두 개의 부분들을 포함할 수 있다.

서버측상에서의 보안성 내에 포함된 경우, 사용자의 시스템의 증명이 존재할 수 있다. 사용자가 ST를 획득하여 서비스에 액세스하기를 원할 때, 사용자는 시스템 적합성을 원격적으로 증명할 것을 TGS에 의해 챌런징받을 수 있다. 그 결과로서, 인증된 시스템 상태에 있는 클라이언트들은 서비스에 액세스할 수 있다. 도 1a는 신뢰적인 커버러스(Kerberos)와 관련된 예시적인 콜 흐름을 도시한다. TGT는 TGT의 청구된 아이덴티티와 서비스 요청을 가지며, TPM에 의해 서명될 수 있는 TCTicket에 의해 증대될 수 있다.

도 1a에서 도시된 바와 같이, 클라이언트(30), AS(40), TGS(50), 및 서비스 제공자(60)는 서로간에 통신을 하도록 구성된다. 클라이언트(30)는 도면부호 10에서 TGT를 검색할 수 있다. 예를 들어, 클라이언트(30)는 로컬 캐시로부터 로딩하고 및/또는 AS(40)로부터 TGT를 얻을 수 있다. 클라이언트(30)는 도면부호 13에서 AS(40)에 대한 TGT 요청을 행할 수 있다. 클라이언트의 실제 아이덴티티 정보는 AS(40) 공개키를 이용하여 암호화될 수 있으므로 보호될 수 있다. AS(40)는 도면부호 15에서 TGT 응답을 클라이언트(30)에 반환할 수 있다. AS로부터의 TGT 응답은 TPM의 공개 EK를 이용하여 암호화될 수 있다.

클라이언트(30)는 도면부호 17에서 ST를 검색할 수 있다. 도면부호 17에서, 클라이언트(30)는 사용자로부터 아이덴티티(AIK) 패스워드를 얻고, TPM을 이용하여 TCTicket을 생성하고, 및/또는 시스템 상태를 쿼팅(quote)할 수 있다. 클라이언트(30)는 도면부호 18에서 ST를 검색하기 위해 ST 요청을 이용할 수 있다. 클라이언트(30)가 TGT를 이용하여 TGS(50)로부터 ST를 요청할 때, 통신은 TGT로부터 세션키에 의해 암호화될 수 있다. TGS(50)는 도면부호 19에서 TGT를 체크하고, 도면부호 20에서 시스템 상태 무결성을 체크하고, 도면부호 21에서 TCT를 체크하며, 및/또는 도면부호 22에서 클라이언트 TPM을 위한 ST를 암호화할 수 있다. 세션키를 공개하고 및/또는 TGS가 클라이언트에 의해 제공된 데이터를 암호해독할 수 있도록 TGT는 TGS(50)에 의해 암호해독될 수 있다. TCTicket으로부터 인증된 서명 키(Certified Signing Key; CSK)에 바인딩되고 TPM에 의해 보안화된 1회용 키로 세션키를 암호화됨으로써 응답은 TPM에 암호화되어 바인딩될 수 있다.

TPM에서의 키 활용을 위한 크레덴셜들 및 TPM을 소유하고 있는 사용자는 ST를 암호해독할 수 있고, 이에 따라 이것을 이용하여 서비스에 액세스한다. 예를 들어, 도 1a에서 도시된 바와 같이, 클라이언트(30)는 도면부호 25에서 서비스를 요청할 수 있다. 클라이언트(30)는 ST를 암호해독할 수 있고, 만약 암호화된 경우, 도면부호 26에서 ST를 서비스 제공자(60)에 제공할 수 있다. 도면부호 27에서 서비스 제공자(60)는 ST를 체크할 수 있고, 만약 ST가 유효한 경우, 도면부호 28에서 요청된 서비스를 제공할 수 있다.

신뢰적인 티켓 개념은 티켓 취득 프로세스에서의 클라이언트의 증명을 포함할 수 있다. TGS에 대한 증명은 보안성에 대한 추가로서 기술될 수 있다. 이것은 특정 애플리케이션들의 형태 변경들을 제공할 수 있다. 이러한 변경들은 신뢰적인 OpenId 개념에 적용될 수 있다. 예를 들어, 이러한 한가지 변경은 증명 및/또는 잠재적으로 교정을 통해 TGS에 의해 발행된 ST 및/또는 클라이언트의 상태를 개별화하는 것일 수 있다. 즉, TGS는 특정 서비스들에 액세스하기 위해 클라이언트들이 특정 상태에 있도록 해줄 수 있는 정책들을 시행하도록 인에이블될 수 있다. 이러한 또 다른 예시는 예컨대 서버에게 자신의 상태의 증명을 챌런징하는 것을 통해서와 같이, 클라이언트가 서비스에 액세스하기 전에, TGS가 서비스 자체를 입증할 수 있게 하는 것일 수 있다. 따라서, 예컨대 신뢰적인 OpenID의 경우에서의 OpenID 제공자 또는 TGS는 상호적으로 허락받고 및/또는 신뢰할 수 있는 상태들에 있는 클라이언트들과 서버들이 통신 관계에 진입하는 것을 보장하는 중재자로서 역할을 할 수 있다. 많은 클라이언트들이 존재하는 경우, 이것은 서비스들에 대한 너무 많은 부하에 기여할 수 있고, 이것은 몇몇의 경우들에서 적용될 수 있다. 부하는 예컨대 서비스들을 드물게 입증하는 것을 통해서 완화될 수 있다. 3GPP에서의 머신 대 머신(machine-to-machine; M2M) 통신에는 병행적인 문제들이 존재할 수 있다. 예를 들어, 기존의 네트워크 인프라구조를 변경시키지 않고서 M2ME를 반자율적으로 입증하는 것은 문제점들을 제공할 수 있다. 제공된 신뢰적 아이덴티티 관리(identity management; IdM)의 개념들은 이러한 목적을 위한 오퍼레이터의 통상적인 인증 인가 계정(authentication authorization accounting; AAA) 인프라구조를 인에이블시키는 빌딩 블록들일 수 있다. RADIUS(remote authentification dial-in user service) 등의 신뢰적 버전들이 적용될 수 있다.

신뢰적인 openID(TOpenId)를 위한 시스템 및 방법이 제공될 수 있다. 신뢰적인 OpenId 엔티티들은, 1) 예컨대 서비스에 액세스하는 사용자; 2) OpenId 제공자; 3) 사용자의 TPM으로부터 AIK들을 인증하기 위한 PCA; 및/또는 4) OpenId 인증을 이용하는 서비스 제공자를 포함할 수 있다.

도 2는 신뢰적인 OpenID와 관련된 예시적인 콜 흐름(200)을 도시한다. 콜 흐름(200)은 예컨대 신뢰적인 OpenID를 이용하여 서비스에 액세스할 때 수행될 수 있는 프로토콜일 수 있다. 여기서 논의한 바와 같이, 클라이언트/사용자 또는 사용자 플랫폼(210), 서비스 제공자(215), 및 아이덴티티 제공자(220)(예시적인 OpenID 제공자로서 도시됨)는 서로간에 통신을 행하도록 구성된다. 신뢰적인 OpenID를 이용할 때, 클라이언트/사용자 플랫폼(210)은 서비스 제공자(215)와의 초기 접속을 행할 수 있다. 클라이언트/사용자 플랫폼(210)은 자신의 웹 브라우저(225)를 이용하여 액세스 웹페이지 메시지(227)를 통해 서비스 제공자 웹페이지(index.jsp(235)로서 식별됨)에 액세스할 수 있다. 클라이언트/사용자(210)가 예컨대 사용자의 OpenID URI를 이용하여 로그인하기를 원하는 경우, 서비스 제공자(215)는 주어진 URI에 접속하여 청구된 아이덴티티를 호스팅하는 OpenID 제공자(220)의 어드레스를 검색할 수 있다. 서비스 제공자(215)에서의 index.jsp 페이지(235)는 OpenID 로그온 폼 메시지(229)를 통해 URI를 요청하고 OpenID 아이덴티티 메시지(231)를 통해 청구된 아이덴티티를 호스팅하는 OpenID 제공자(220)의 어드레스를 검색할 수 있다.

그런 후 서비스 제공자(215)는 OpenID 제공자(220)와의 연관을 형성할 것을 시도할 수 있다. OpenID 프로토콜에 따르면, 서비스 제공자(215)는 연관 메시지(241)를 통해 OpenID 제공자(220)와 연관될 수 있다. 이것은 연관 메시지(243)를 통한 요청, 청구된 아이덴티티, 및/또는 복귀 URL의 안전한 교환을 포함할 수 있으며, 서비스 제공자(215) 및/또는 만약 인증이 성공적인 경우 OpenID 제공자(220)에 의해 클라이언트/사용자 플랫폼(210)에 리다이렉트 메시지(247)가 보내질 수 있다. 이것은 서비스 제공자(215)에서 consumer_redirect.jsp(240)에 의해 수행되거나, 및/또는 OpenID 제공자(220)에서 provider.jsp(245)에 의해 수행된다. 연관 후, 클라이언트/사용자 플랫폼(210)은 OpenID 제공자 메시지(249)로의 리다이렉팅을 통해서와 같이, OpenID 제공자(220)의 provider.jsp 웹페이지(245)에 리다이렉팅될 수 있다. 리다이렉션 어드레스는 사용자 제공된 식별자로부터 검색될 수 있는데, 이것은 OP 페이지에 리다이렉트되는 클라이언트/사용자 플랫폼(210)이 식별자를 제공한 동일한 엔티티이라는 것을 보장할 수 있다. 리다이렉트는 HTTP 리다이렉트를 통해 수행될 수 있으며, HTTP 리다이렉트는 브라우저를 OP 로그인 페이지에 직접적으로 리다이렉트할 수 있다.

그 후 클라이언트/사용자 플랫폼(210)은 인증될 수 있다. OpenID 제공자(220)는 클라이언트/사용자 플랫폼(210)을 인증하기 위해 provider.jsp 웹페이지(245)로부터 provider_authorization.jsp 웹페이지(255)로 스위칭할 수 있다. 클라이언트/사용자 플랫폼(210)에는 인증을 요청하는 provider_authorization.jsp 웹페이지(255)가 제공될 수 있다. 사용자는 provider_authorization.jsp 웹페이지(255)상의 링크를 클릭함으로써 요청을 개시할 수 있다. 이것은 챌런지 메시지(252)를 통해 티켓 서버(250)를 챌런징하는 TTverifier(258)와 같은 새로운 백그라운드 쓰레드를 작동시킨다. provider_authorization.jsp 웹페이지(255)는 클라이언트/사용자 플랫폼(210)을 provider.jsp 웹페이지(245)에 다시 리다이렉트한다. provider.jsp 웹페이지(245)는 TTverifier(258)를 기다려서 종료하고 챌런지 답변 메시지(254)에서 제공된 챌런지의 결과를 평가한다. 여기서 설명된 바와 같이, 티겟 서버(250)와 같은 신뢰적인 티켓 서버(TTS)는 TPM 기능성을 이용하여 티켓을 포함한 적절한 답변을 생성할 수 있고 및/또는 예컨대 인증서들을 보유할 수 있는 저장 매체(280), PCA(275) 및/또는 TPM(270)과 상호작용할 수 있다. 프로토콜의 다른 부분들은 OpenID 프로토콜을 이용할 수 있다. 인증 토큰은 수정될 수 있으므로 OpenID 제공자(220) 및/또는 클라이언트/사용자 플랫폼(210)은 TPM 생성된 TCTicket들을 이용할 수 있다.

성공적인 인증을 가정하면, 클라이언트/사용자 플랫폼(210)은 서비스 제공자에게 리다이렉팅될 수 있다. provider.jsp 웹페이지(245)는 리다이렉션 메시지(262)를 클라이언트/사용자 플랫폼(210)에 보낼 수 있다. 리다이렉션 메시지(262)는 서비스 메시지(264)로의 리다이렉트를 통해서 클라이언트/사용자 플랫폼(210)을 서비스 제공자(215)에서의 consumer_returnurl.jsp 페이지(265)에 리다이렉팅할 수 있다. consumer_returnurl.jsp 페이지(265)는 리다이렉트가 연관된 OpenID 제공자(220)로부터 온 것이며 서비스 메시지(267)를 통해 클라이언트/사용자 플랫폼(210)에 대한 액세스를 승인한다는 것을 체크할 수 있다.

도 3a와 도 3b는 티켓 서버(305)와 티켓 챌런저(310)간의 신뢰적인 티켓 서버 챌런지 응답과 관련된 예시적인 콜 흐름(300)을 도시한다. 저장 매체(320)와 TPM(325)이 이용될 수 있다. 티켓 서버(305)는 클라이언트상에서 서비스 애플리케이션으로서 구동될 수 있다. 티켓 서버(305)는 미리정의된 포트를 통해 경청하고 챌런지들을 기다릴 수 있다. 챌런지 메시지(사용자가 이용하고자 하는 아이덴티티를 포함함, 예컨대 서비스 제공자에서 발행되었던 서비스 요청 및 OpenID)(327)의 수신시, 사용자는 확인응답 메시지(329)를 이용하여 챌런지를 허용할 것을 필요로 할 수 있다. 사용자는 챌런지를 거부하는 옵션을 가질 수 있다. 만약 거부되면, OpenID 인증은 실패할 수 있다.

챌런지가 수락되면, 사용자는 주어진 아이덴티티에 대응하는 AIK를 위한 패스워드를 입력하고 티켓 서버(305)에서 저장소 루트 키(storage root key; SRK) 패스워드를 입력함으로써 TPM(325) 활용을 인증하도록 프롬프트될 수 있다. 그런 후 SRK는 TPM 보안화된 키들에 액세스할 수 있는 TPM 명령내에 포함될 수 있다. 그런 후 티켓 서버(305)는 이 아이덴티티에 대하여 이전에 획득한 인증서, 예컨대 AIK 인증서를 인증서 저장 매체(320)로부터 검색할 것을 시도할 수 있으며(이것은 도면부호 335로서 총괄적으로 도시된다), 이 AIK 인증서는 여기서 논의된 시스템 상태 정보 검색(345) 및/또는 TCTicket 생성(350)을 위해 이용될 수 있다. 인증서는 PCA(315)와 같은 PCA에 대한 이전의 AIK 인증으로부터 나올 수 있고, 인증서 저장 매체(320)와 같은, 시스템상의 로컬 인증서 저장소로부터 검색될 수 있다. 인증서가 로컬 저장소에서 이용가능하지 않는 경우(또는 로컬 저장소에 있는 AIK용 인증서가 만료되었거나 무효로 된 경우), AIK에 의해 표현된 아이덴티티를 위한 또 다른 인증서가 PCA(315)로부터 요청받을 수 있다. 인증서가 인증서 저장 매체(320)에서 발견될 수 없는 경우, 사용자는 AIK 인증서 프로세스를 겪고 및/또는 AIK용 인증서를 획득하기 위해 접속할 PCA(315)를 선택할 수 있다. 사용자는 TPM(325)의 옳바른 소유자 패스워드를 공급할 수 있다. 이것은 TPM(325)의 소유자 이외의 다른 사람들에 의한 부정한 아이덴티티들의 생성을 방지할 수 있다. 사용자 입력은 티켓 서버(305)에 의해 패스워드를 평가하는 TPM(325)에 포워딩될 수 있다.

챌런지를 수락한 것에 응답하여, 티켓 챌런저(310)는 랜덤 논스(random nonce)를 생성할 수 있다(337). 티켓 서버(305)는 논스 메시지(339)를 통해 티켓 챌런저(310)로부터 랜덤 논스(337)를 수신할 수 있다. 논스를 비롯하여, 시스템 구성을 기술하는 플랫폼 구성 레지스터(platform configuration register; PCR) 값들의 AIK 서명된 쿼트(quote; Q)는 TPM(325)으로부터 검색되어 시스템의 상태에 관한 스테이트먼트를 생성할 수 있다(이것은 도면부호 345로서 총괄적으로 도시된다).

그런 후 티켓 서버(305)는 도면부호 350로서 총괄적으로 도시된 TCTicket을 생성할 수 있다. TCTicket 생성(350)은 요청 및/또는 아이덴티티를 서명하는데 이용될 수 있는 (예컨대 RSA 키 쌍과 같은) TPM에 의한 키의 생성을 수반할 수 있다. 여기서 설명된 바와 같이, 이 키는 CertifyKey 동작을 이용하여 AIK로 인증될 수 있다. 즉, TPM은 이 생성된 키 쌍을 위한 함수 CertifyKey를 이용하여 인증 스테이트먼트 및 바인딩을 생성할 수 있으며, 여기서 바인딩은 PCA로부터의 AIK 인증서 및/또는 AIK에 대한 신뢰 체인 구축을 말한다. 생성된 키가 성공적으로 인증된 경우, 이 키를 인증된 서명 키(CSK)라고 칭할 수 있다. TPM에는 (또는 TPM에 의해 보호된 보안 저장소 내에서 TPM에 의해 보안화될 수 있는) 다수의 CSK들, 및/또는 다수의 AIK들이 존재할 수 있다.

TCTicket(350)을 입증하기 위해 필요한 정보는 TCTicket(350) 내에 포함될 수 있으며, 이로써 (예컨대 도 3a와 도 3b에서의 티켓 챌런저(310)와 같은) 수신 당사자는 손쉽게 TCTicket(350)을 입증할 수 있다. 평문 측정 로그(measurement log; ML) 및/또는 쿼트(Q)와 함께, TCTicket(350)을 포함한 응답은 TCT, Q, ML 메시지(352)를 통해서와 같이, 티켓 챌런저(310)에 되보내질 수 있다. CH-RESPONSE 및 ACK 메시지들(도면부호 351에서 총괄하여 나타남)은 (예컨대 티켓 챌런저(310)와 같은) 수신 당사자에게 다음번의 메시지가 TCTicket(350), 쿼트, 및/또는 ML을 포함할 수 있다는 것을 통지하기 위한 프로토콜 시그널링 메시지들일 수 있다.

도 3a와 도 3b는 도 2에서의 TTVerifier 쓰레드(258)의 내부 동작들을 표현할 수 있다. OpenID 제공자는 다수의 요청들을 동시에 처리할 수 있기 때문에, 요청하는 각각의 클라이언트들은 리플레이 공격들을 방지하기 위해 새롭고, 신선하고, 및/또는 고유한 챌런지를 얻을 수 있다.

메시지들(355)을 통한 TCTicket(350)의 확인응답시, 티켓 챌런저(310)는 이하의 데이터를 가질 수 있다: 리플레이방지 보호로서 넌스(337)를 포함한, TPM(325)으로부터의 AIK 서명된 쿼트; 평문 측정 파일; 서명된 아이덴티티 스트링, 서명된 요청 스트링, CSK의 공개 키 부분, CSK의 공개 키 부분에 대한 AIK 시그너처, 및/또는 PCA(315)에 의해 발행된 AIK 인증서를 포함한 TCTicket(350). 클라이언트를 인증하기 위해, 티켓 챌런저(310)는 특정한 순서없이 도면부호 360으로서 총괄하여 나타난 아래의 것을 수행할 수 있다: 1) AIK 인증서의 입증(타임스탬프)(입증 정보는 또한 예컨대 이용 카운터의 값으로서 캡쳐될 수 있다); 2) AIK 인증서에 대한 PCA 시그너처를 검증함; 3) TCTicket(350)에서의 CSK 공개 키 해쉬에 대한 AIK 시그너처를 검증함; 4) TCTicket(350)에서의 서비스 요청 및 아이덴티티에 대한 시그너처를 검증함; 5) 측정 리스트에 있는 엔트리들을 입증함; 및/또는 6) 실제 (쿼팅된) (PCR) 값들이 측정 리스트 ML에 대응하다는 것을 검증함. AIK 인증서의 입증에서, 검증될 수 있는 것은 로컬 클라이언트의 자신의 보호된 카운터 값이 AIK 인증서에서 표시될 수 있는 "최대" 숫자에 아직 도달되지 않았는지의 여부이다. 로컬 클라이언트의 보호된 카운터 값은 예컨대 OpenID 클라이언트의 소프트웨어 및/또는 인증서들의 설치 횟수를 표시할 수 있다.

이 검증 프로세스에서의 아이템이 실패된 경우, 클라이언트는 인증되지 않을 수 있다. 예컨대 AIK 인증서 - 인증된 CSK - 서명된 요청과 같은, 특정 크레덴셜 체인이 티켓 서버(305)와 PCA(315)에 의해 구축될 수 있다. 검증 상태 메시지(365)는 사용자에게 보내질 수 있다. 이것은 또한 예컨대 도 2에서 리다이렉션 메시지(262)에 의해 도시된다. 이 경우에서, 메시지(262)는 사용자의 브라우저를 서비스 제공자의 returnurl에 리다이렉트할 수 있거나 또는 사용자는 서비스 제공자에서 인증될 수 있다. 위 검증이 실패한 경우(인증서 실패 및/또는 시스템 무결성 실패), 리다이렉트는 사용자를 OpenID 제공자에서의 인증 실패 페이지로 보낼 수 있다. 실패된 인증의 경우 OpenID 제공자에서 맞춤화된 결과 페이지들이 생성될 수 있다. 맞춤화된 결과 페이지들은 실패의 원인을 보여줄 수 있다. 이것은 사용자에게 어느 모듈들 또는 소프트웨어가 무결성 체크를 실패하였는지를 보여주고 및/또는 사용자 자신의 시스템을 신뢰할 수 있는 상태로 되돌리기 위해 사용자에게 다음 단계들로 제안하는 시스템으로 레버리징될 수 있는 것을 보여주는 것을 포함할 수 있다.

여기서의 개시내용에 의하면, PCA(275)는 특정 서비스 제공자(215)와 이용될 부분적 아이덴티티 마다 한번 인보크될 수 있다. 초기 등록에서, 클라이언트/사용자 플랫폼(210)은 자신의 플랫폼 아이덴티티를 필명의 부분적 아이덴티티와 연관시킬 수 있다. PCA(275)는 이러한 필명의 아이덴티티에 대한 인증서를 제공할 수 있고 및/또는 플랫폼 아이덴티티에 대한 필명의 연관을 저장할 수 있다. 이 데이터는 프라이버시 민감적일 수 있고 따라서 보호되어야 한다. PCA(275)의 포지셔닝은 현재의 티켓 시스템들과 비교하여 추가적인 옵션들을 가능하게 해줄 수 있다. 여기서 개시된 신뢰 모델 및 방법은 아이덴티티 제공자(220) 및 사용자의 선택에서와 다른 장소들에서의 PCA(275)의 배치를 가능하게 해줄 수 있다. 이것은 덜 프라이버시 친화적일 수 있는데, 그 이유는 사용자는 아이덴티티 제공자(IdP)에 의해 선택된 PCA를 신뢰해야만 할 수 있기 때문이다.

평문 측정 파일은 로컬 클라이언트 디바이스에 의해 수행된 측정들에 관한 정보, 예컨대 기밀성 보호를 위해 (예컨대 플랫폼에 바인딩된 키를 이용하는 것을 통해서와 같이) 암호화된 측정값들, 및/또는 개별적인 측정 파일들을 요약하는 값들을 가질 수 있는 다른 유형들의 파일들로 대체될 수 있다. 그러한 예시는 예컨대 개별적인 컴포넌트들보다는 컴포넌트들의 그룹의 무결성을 표시하는 복수의 개별적인 측정 파일들일 수 있다. 이러한 컴포넌트들은 예컨대 특정 기능성 및/또는 로컬 클라이언트 플랫폼의 속성을 총체적으로 구체화할 수 있는 그룹에 속할 수 있다.

티켓 서버(305)와 티켓 챌런저(310)간의 이용된 인증 프로토콜(예컨대 OpenID IdP 프로토콜)에 의존하여, 프로토콜을 챌런지 응답 프로토콜로 감소시키는 것이 가능할 수 있다. 챌런지 응답 프로토콜은 1) 티켓 챌런저(310)가 챌런지(id,req) 및/또는 논스를 티켓 서버(305)에 보낼 수 있고, 및/또는 2) 티켓 서버(305)가 TCT, 쿼트 Q 및/또는 측정 리스트 ML로 응답할 수 있는 것을 포함할 수 있다. 이러한 프로토콜은 다른 프로토콜들에서 통신하는 클라이언트/사용자 머신에서와 같은 티켓 서버(305), 및 OP에서와 같은 티켓 챌런저(310)의 손쉬운 통합을 가능하게 해줄 수 있다. 예를 들어, 이러한 통합은 예컨대 단순한 챌런지/응답 방식을 이용할 수 있는 HTTP 프로토콜을 이용하여 수행될 수 있다.

사용자 인증은 도 3a와 도 3b에서 도시된 챌런지 응답에서의 OpenID를 이용하여 일어날 수 있다. 사용자는 사용자 패스워드를 입력할 수 있다. 사용자 패스워드는 OpenID에 대해 이전에 등록된 것일 수 있으며, 이로써 동일한 패스워드는, 챌런지 응답에서 포함된 경우라면, 사용자가 첫번째 인스턴스에서 등록되었던 동일한 개인이라는 것을 표시할 것이다. 사용자 패스워드는 예컨대 사전공유된 시크릿 중에서 유도된 데이터와 같은, 몇몇 종류의 다른 증거를 표시할 수 있다.

TOpenID에서, 사용자 인증과 디바이스 신뢰성 증명 모두가 여기서 설명된 바와 같이 달성될 수 있다. 사용자는 예컨대 OpenID 제공자, 사용자 디바이스에 단단히 바인딩된 TPM 및/또는 사용자 디바이스용 CSK 및/또는 AIK용 인증서들에 대해 이미 미리등록되었을 수 있기 때문에 사용자 인증이 달성될 수 있다. 챌런지 응답의 단계에서, 사용자는 사용자들의 AIK들 및/또는 CSK의 개인키로 서명될 수 있는 데이터를 보낼 수 있다. 그러므로, 이러한 키들의 공개 부분의 검증시, 및/또는 사용자가 미리등록되었던 동일한 AIK 및/또는 동일한 CSK를 이용중에 있다라는 검증시, OpenID 제공자는 챌런지 응답을 보내기 위해 디바이스를 이용했던 사용자가 미리등록되었던 동일한 사용자라는 것을 알 수 있다. 예를 들어, 사용자 디바이스는 동일한, 단단히 바인딩된 TPM을 가질 수 있다.

디바이스 신뢰성 증명이 달성될 수 있다. 예를 들어, OpenID 제공자는 PCR들의 TPM_Quote들, 측정 로그들, 및/또는 (예컨대 사용자 ID 또는 요청과 같은) 티켓의 부분이 지금 검증된 AIK CSK를 이용하여 서명되는지를 검증할 수 있기 때문에, 디바이스 신뢰성 증명은 달성될 수 있다. OpenID 제공자는 PCR들의 TPM_Quote들, 측정 로그들, 및/또는 티켓의 부분이 실제로 예상했던 비교 결과들을 생성하는지 여부를 검증할 수 있기 때문에, 디바이스 신뢰성 증명은 또한 달성될 수 있다. 양쪽이 모두 매칭되는 경우, OpenID 제공자는 OpenID 요청을 보내기 위해 사용자가 이용했던 디바이스가 실제로 신뢰할 수 있다라고 검증할 수 있다. 일 예에 따르면, 사용자 및 요청의 검증이 달성되었으나, PCR 값들 및 측정 로그들의 비교가 실패되었다면, 이전에 미리 등록되었던 동일한 디바이스로부터 보내진 신뢰성 관련된 데이터는 디바이스가 손상될 수 있고 예상했던 것과는 다른 구성 상태에 있다는 것을 표시한다는 것을 OpenID 제공자는 알 수 있다.

TOpenID는 OpenID 사양들을 위반하지 않을 수 있고 및/또는 TOpenID는 OpenID 사양들에 대한 변경없이 OpenID내에서 통합될 수 있다. OpenID 아이덴티티들에 대한 여러 개의 인증 옵션들이 가능하고 구현될 수 있다. 프로토콜 흐름은 표준화된 흐름으로 분리될 수 있다. 프로토콜 흐름은 신뢰적인 당사자(relying party; RP)들 및 IdP의 상호작용을 기술할 수 있으며, 이것은 간접적 통신을 통해 일어날 수 있다. 예를 들어, RP들과 IdP의 상호작용은 사용자의 브라우저를 상이한 웹페이지들에 리다이렉팅하고 및/또는 메시지들의 HTTP 필드들에서 필요한 데이터를 전송함으로써 일어날 수 있다.

도 4는 신뢰적인 OpenID와 관련된 예시적인 방법을 도시한다. 도면부호 401, 403, 405, 407, 410, 411, 413, 414, 415, 및 416에서, 클라이언트의 브라우저, OpenID IdP, 및/또는 RP의 상호연동의 예시가 도시될 수 있다. 도면부호 409에서, 사용자 인증이 발생하지만, 의도적으로 불특정될 수 있다. OpenID는 본 방법을 명시하지 않을 수 있고 아이덴티티 서버는 사용자가 자신의 URL을 소유한다는 것을 검증하기 위해 이용될 수 있다. 몇몇의 경우들에서, 이러한 검증은 쿠키들을 통해 수행될 수 있다. 사용자가 사용자의 아이덴티티를 소비자에 대해 검증하기를 원하는지를 서버는 사용자에게 프롬프트할 수 있다.

도 4에서 도시된 바와 같이, 프로토콜 흐름은, 도면부호 401에서 사용자가 자신의 아이덴티티 URL을 입력하는 것을 포함할 수 있다. 소비자는 아이덴티티 URL을 가져올 수 있다. 도면부호 403에서, 소비자는 opened.server 및 opened.delegate 링크 관계들에 대한 문서를 프로세싱할 수 있다. 위임된 경우, 위임된 문서를 가져와서 이것을 opened.server에 대해 파싱한다. 도면부호 405에서, 소비자는 사용자의 아이덴티티 서버와의 공유된 시크릿을 생성하고 이것을 캐싱할 수 있다. 도면부호 407에서, 소비자는 체크를 위한 URL을 구축하고 이것에 사용자의 브라우저를 리다이렉팅할 수 있다. 도면부호 409에서, 사용자가 URL을 소유한다라고 서버가 단언할 수 있는지 여부를 결정할 수 있다. 만약 사용자가 URL을 소유한다라고 서버가 단언할 수 없다면, 도면부호 410에서, 소비자가 checked_immediate를 요청한 경우에 checked_setup 모드를 위한 URL을 반환한다. 도면부호 410에서, 소비자가 checkid_setup을 요청한 경우, 서버는 취소를 반환할 수 있다. 도면부호 409에서, 만약 사용자가 URL을 소유한다라고 서버가 단언할 수 있다면, 도면부호 411에서, 서명된 파라미터들을 갖는 소비자의 요청에서 명시된 URL로 복귀하도록 서버는 사용자의 브라우저를 리다이렉트할 수 있다. 도면부호 413에서, 소비자가 서버를 위해 캐시된 공유된 시크릿을 갖는지 여부를 결정할 수 있다. 소비자가 캐시된 공유된 시크릿을 갖는 경우, 도면부호 414에서, 서명된 파라미터들은 시크릿을 이용하여 검증될 수 있다. 도면부호 413에서 소비자가 캐시된 공유된 시크릿을 갖지 않는 경우, 도면부호 415에서 소비자는 서버에 의해 반환된 시그너처와 association_handle을 갖는 check_authentication 요청을 생성할 수 있다. 도면부호 416에서, 시그너처가 유효한 경우 서버는 복귀할 수 있다.

TOpenID는 인증 단계에서 IdP에 의한 플랫폼 입증 데이터 및/또는 무결성 체킹을 포함할 수 있다. OpenID 식별자는 TPMbound AIK를 이용하여 등록될 수 있기 때문에 TOpenID에서의 인증은 특정 TPM(또는 예컨대 단일 플랫폼)에 바인딩될 수 있다. TPM 및/또는 AIK 인증 프로세스의 보안 특성들은 식별자가 또 다른 플랫폼상에서 이용될 수 없는 것을 보장할 수 있다. IdP에 의한 무결성 입증은 옳바른 플랫폼(또는 신뢰적인 티켓 서버를 비롯하여, 명시된 신뢰적인 서브시스템인 경우)은 옳바른 구성에서 구동중에 있다는 것을 보장할 수 있다.

위 방법은 도 2에서 도시된 바와 같은 TOpenID 프로토콜 흐름들에 적용될 수 있다. OpenID 아이덴티티 제공자(IdP) 및/또는 사용자의 시스템은 TPM 및 자신의 무결성 입증 프로토콜들을 이용하여 인증 단계들을 수행하는 능력들을 포함할 수 있다. 이러한 능력들은 클라이언트 및/또는 서버상에서의 소프트웨어 모듈들 및/또는 라이브러리들로서 구현될 수 있다. 예를 들어, 이러한 능력들은 TTverifier(258), 챌런지 메시지(252), 챌런지 답변 메시지(259), TPM(270), PCA(275), 및/또는 저장 매체(280)와 같은, OpenID 제공자(220) 및/또는 클라이언트/사용자 플랫폼(210)에서 구현될 수 있다. OpenID의 개방된 개념은 매우 다양한 상이한 OpenID IdP 구현들을 야기시킬 수 있다. 따라서, OpenID IdP들은 자신들을 구별시키기 위한 개념들을 개발할 수 있다. OpenID IdP들이 자신들을 구별시키기 위해 이용할 수 있는 하나의 기능은 예컨대 강화된 보안 특징들의 어써션일 수 있다. 이러한 어써션들은 예컨대 HW 바운딩된 것과 같이, 사용자의 (OpenID) 아이덴티티가 보호된다라고 사용자들에게 보장할 수 있다. 사용자들은 RP들이 IdP들로부터 수신된 정보에 의존하는 것을 이러한 IdP들이 가능하게 해준다는 것을 보장받을 수 있다. 예를 들어, 은행들 또는 보안을 요구하는 다른 애플리케이션들이 보안 인식 및 인증된 OpenID IdP들의 화이트리스트와 함께 OpenID를 이용할 수 있도록 해준다.

TOpenID를 구현하는 하나의 방법은 플랫폼 입증을 수행하기 위해 제2의 비HTTP 기반 프로토콜을 이용할 수 있다. 예를 들어, 제2 프로토콜을 이용하여 챌런지 메시지는 OpenID 제공자(220)로부터 클라이언트/사용자 플랫폼(210)으로 보내질 수 있고 응답은 OpenID 제공자(220)에 되보내질 수 있다. 이것은 OpenID 제공자(220)의 주요 인증 프로세스에 대한 제어를 반환할 수 있는 백그라운드 프로세스를 통해 수행될 수 있다. 주요 인증 프로세스는 도 2에서 도시된 바와 같이 클라이언트/사용자 플랫폼(210)으로부터 OpenID 제공자(220)로의 리다이렉트로 시작될 수 있을 수 있다. 그런 후 HTTP 리다이렉트는 도 2에서 도시된 바와 같이 OpenID 제공자(220)로부터 클라이언트/사용자 플랫폼(210)으로 수행될 수 있다.

서버 및/또는 사용자의 디바이스의 능력들에 의존하여, 데이터를 전송하기 위해 상이한 프로토콜들이 이용될 수 있다.

서비스 액세스에 대한 크레덴셜들, 또는 티켓들을 생산하는 엔티티는 클라이언트내에 병합될 수 있다. 이것은 예컨대 도 2에서 도시된 티켓 서버(250)와 같은, 클라이언트 내의 신뢰적인 기능 엔티티에 의한 TKerberos의 보안성을 손상시키지 않고서 수행될 수 있다. 티겟 서버는 OpenID 제공자에 대해 클라이언트와 자신을 입증할 수 있다. 보안 정보 및 동작들은 티켓 서버 컴포넌트에서 집중될 수 있기 때문에, AIK 인증서들 및/또는 CSK들을 적절하게 처리하는 것은 신뢰적일 수 있다. 티켓 서버는 AIK 인증서들 및/또는 CSK들을 다른 플랫폼들에 확산시키지 않고, 티켓들과 크레덴셜들을 보호하고, 사용자 인가에 의한 보안 동작 크레덴셜들을 보호하고, 공통 웹브라우저들내로 통합되고 이 웹브라우저들에 의해 액세스될 보안 옵션들을 제공하고, 플랫폼 입증 데이터를 수집하고 프로세싱하고 보내며, 및/또는 리플레이 공격들을 식별하기 위해 논스의 유효성에 기초하여 액세스 제어를 제공하도록 신뢰될 수 있다.

여기서 설명된 특정 크레덴셜 체인은 티켓 서버와 PCA에 의해 구축될 수 있다. TOpenID에서의 크레덴셜 체인은 AIK 인증서 - 인증된 CSK - 서명된 요청일 수 있다.

PCA를 TKerberos 시스템에 배치하는 구현들은 다음을 포함할 수 있다. OpenID 제공자에서 PCA를 포함시키는 것은 복잡성을 감소시킬 수 있다. 이것은 웹 폼을 통해 OpenID 제공자와의 등록의 끊김없는 대체일 수 있다. TOpenID에서, 사용자는 1) TOpenID 제공자에 의해 AIK 인증서들이 수락될 수 있는 임의적인 외부 PCA를 선택하고, 및/또는 2) TOpenID 제공자에 의해 직접적으로 또는 간접적으로 제공된 PCA 기능성을 이용할 수 있다.

TOpenID의 보안 아키텍처로 인해, TOpenID는 OpenID 기반 시스템들에 대한 특정 위험성들을 완화시킬 수 있다. TKerberos에서, AIK 인증서는 클라이언트에 대해 보여지지 않을 수 있지만 TGT로 암호화되어, TGS에 의해 암호해독가능할 수 있다. AIK 인증서는 클라이언트에 알려질 수 있으며 예컨대 프라이버시를 위협할 수 있는 정보를 숨기지 못할 수 있다. OpenID 구현들은 사용자에게 OpenID 제공자 로그인 폼을 제공할 수 있다. 사용자는 자신의 크레덴셜들을 입력할 수 있고 OpenID 제공자는 클라이언트에게 쿠키를 발행할 수 있다. 그런 후 이 쿠키는 각각의 후속적인 OpenID 인에이블드 서비스 액세스를 위해 이용될 수 있다. 이것은 OpenID 프로토콜에 대한 여러 공격들의 가능성들, 예컨대: 1) 각자의 OpenID 제공자에 로그인하기 위해 이용된 사용자 크레덴셜들에 대한 직접적 공격들(가짜 OpenID 제공자 페이지를 통한 피싱이 방대한 수의 사용자 크레덴셜들을 노출시킬 수 있고, 이로써 아이덴티티 절도를 야기시킨다), 또는 2) 인증 후의 클라이언트의 컴퓨터로부터의 쿠키의 절도, 복사, 및/또는 재사용을 수반한 공격들(이것들은 아이덴티티 절도를 야기시킬 수 있음)의 가능성들을 야기시킬 수 있다. 공격들은 신뢰적인 OpenID의 이용에 의해 완화될 수 있다. 사용자 패스워드가 로컬화될 수 있고 및/또는 로컬 신뢰적 티켓서버에 제공될 수 있으므로, 크레덴셜 피싱은 무산될 수 있다. 필명 아이덴티티들이 플랫폼에 바인딩될 수 있다. 즉, 이것들은 또 다른 디바이스에 복사되지 않을 수 있다.

클라이언트의 플랫폼상에는 어떠한 쿠키들도 저장되지 않을 수 있다. 이것은 예컨대 컴퓨터가 다수의 사람들에 의해 공유될 때와 같은, 로컬 재사용의 위협을 방지할 수 있다. 일례에서, 사용자 A가 자신의 OpenID 계정으로 로그인하고, 서명하는 것을 잊은 경우, 사용자 B는 저장된 쿠키를 이용하여 사용자 A를 가장하려고 시도할 수 있다. 이러한 재사용은 신뢰적인 OpenID 인증을 끊임없이 웹브라우저에 병합시킴으로써 방지될 수 있다. 사용자가 신뢰적인 OpenID를 이용하여 서비스에 액세스하기를 원하는 경우, OpenID 제공자는 티켓서버에 대한 새로운 챌런지를 생성시킬 수 있다. 사용자는 예컨대 사용자에게 로컬 AIK 패스워드를 요청하는 프롬프트와 같은, 자신의 신뢰적인 티켓서버 애플리케이션으로부터의 프롬프트를 살펴볼 수 있는데, 이것은 챌런지에 답변할 필요가 있을 수 있다. 티켓서버는 이 AIK 인증 시크릿을 저장하지 않을 수 있다. 동일한 플랫폼에 있는 또 다른 사용자 B가 해당 서비스에 액세스하기를 원하는 경우, 티켓 서버는 OpenID 제공자에 의해 다시 챌런징될 수 있고 및/또는 사용자 B는 사용자 A의 로컬 AIK 패스워드(이것은 사용자 B에게 알려지지 않음)를 제공해야만 할 수 있다. 이것은 클라이언트의 플랫폼상에 저장되지 않을 수 있는, 1회성 쿠키의 이용을 필요로 할 수 있다.

발행된 쿠키는 타켓 플랫폼 및/또는 사용자가 이 쿠키를 암호해독할 수 있고 이것을 인증 토큰으로서 이용할 수 있도록 하는 방식으로 암호화될 수 있다. OpenID 제공자는 공개 CSK를 이용하여 이 쿠키를 암호화할 수 있고 및/또는 이것을 클라이언트측의 티켓서버에 보낼 수 있다. TPM을 이용하여, 쿠키는 필요할 때 암호해독될 수 있다. 암호해독은 예컨대 (로컬) CSK 시크릿을 통해서와 같이, CSK 활용을 위해 사용자가 인증할 것을 요구할 수 있다. 티켓 서버는 쿠키가 암호화되어 저장되고, 필요하다면 암호해독되는 것을 보장할 수 있다. 암호화된 쿠키의 저장 및/또는 이용을 위한 또 다른 구현은 실링(sealing) 동작이 일어날 때 플랫폼의 무결성에 쿠키를 바인딩하는 방식으로 쿠키를 저장하기 위해 커맨드 TPM-Seal를 이용하는 것일 수 있다. 다음에 이전에 실링된 쿠키값이 검색되면, 플랫폼의 무결성은 실링 동작이 일어날 때의 값과 동일한 것으로 검증될 수 있다. 이 예시에서, 플랫폼의 무결성이 자신의 이전의 값과 매칭하는 경우, 실링된 쿠키값이 검색될 수 있다.

신뢰적인 OpenID는 신뢰적인 구글 API로 확장될 수 있다. OpenID와 OAuth를 결합하는 것은 OpenID 인증 프로세스에 의존할 수 있으며 이로써 예컨대 OpenID 제공자에서의 전통적인 '로그인' 이외에는 추가적인 사용자 상호작용이 필요로 하지 않을 수 있다.

사용자의 TPM이 OpenID 챌런지를 서명하게 하는 것 대신에, TPM은 웹 애플리케이션의 요청을 통해 OpenID 제공자에 의해 제공된 결합된 OpenID/OAuth 챌런지를 서명할 수 있다. 사용자 식별 및 인가 뿐만이 아니라 데이터에 대한 액세스의 수락은 TPM에 의해 안전하게 서명될 수 있다. 신뢰적인 OpenID 환경에 있을 때, 사용자에 대한 보안은, 클라이언트상에서 구동중인 악성 소프트웨어에 의한 민감한 데이터의 도용을 방지하기 위해 1) 로그인 및 인가를 하드웨어 TPM에 바인딩하는 것, 및/또는 2) OpenID/OAuth 제공자에 의한 택일적인 플랫폼 무결성 검증을 포함하는 것에 의해 향상될 수 있다. 무결성 검증은 웹 애플리케이션에 대한 보안 레벨을 증가시킬 수 있다. 서비스에 대한 액세스는 증명된 무결성 검증 상태에 있는 클라이언트들로 제한될 수 있다. 이것은 보안 및 프라이버시 애플리케이션들을 위한 새로운 웹 서비스들의 구축을 허용할 수 있다. 프로세스는 부인봉쇄(non-repudiation)를 제공할 수 있는데, 예컨대 OAuth 액세스 토큰은 TPM에 의해 서명될 수 있고, 이것은 고유적으로 식별될 수 있다. 이것은 웹 애플리케이션의 제공자에 의해 구현될 수 있는 요금청구 프로세스들을 촉진시킬 수 있다. 시그너처는 사용자가 서비스를 요청했고 이에 액세스했다는 것을 웹 애플리케이션 제공자가 증명할 수 있도록 해줄 수 있다.

TPM 기반 사용자 인증은 플랫폼 아이덴티티가 OpenID 아이덴티티에 링크되도록 해줄 수 있다. OpenID 제공자가 주어진 플랫폼에 대한 등록된 아이덴티티들의 데이터베이스를 유지할 것이 필요할 수 있다. OpenID 제공자는 주어진 플랫폼 크레덴셜들에 의해 공격자로부터 정당한 사용자를 가려낼 수 있다. 또 다른 플랫폼으로부터 로그인 시도가 탐지된 경우, OpenID 제공자는, 1) 인증을 거부할 수 있고, 및/또는 2) 아이덴티티의 정당한 소유자에게 소유자 본인이 다음에 로그인할 때를 통지해줄 수 있다.

TOpenID와 OpenID/GBA 인증 방식의 잠재적인 통합은 플랫폼 무결성 값들을 검증하기 위한 TOpenID IdP의 능력들을 NAF/IdP에 구비시키는 것일 수 있다. NAF/IdP로부터의 GBA 인가 헤더는 TOpenID 프로토콜로부터의 직렬화된 폼의 챌런지(예컨대, id, req, 넌스)를 포함할 수 있다. 이 챌런지가 수신되면, ME/UE는 이 챌런지를 직렬해제시키고, 인가 다이제스트를 계산하는데 이용될 수 있는 GBA Key 유도 기능부 및 신뢰적인 티켓 서버로 이 챌런지를 멀티플렉싱할 수 있다. 예컨대 신뢰적인 티켓 서버로부터의 서명된 쿼트와 ML, 및 GBA 프로세스로부터의 다이제스트 값 모두의 반환값들은 HTTP 응답 메시지에서 NAF/IdP로 반환될 수 있다.

인증 및 신뢰 평가는 결합될 수 있다. 이러한 결합은 특정 UICC(예컨대, GBA 클라이언트로서)의 이용을 단일 플랫폼에 바인딩시킬 수 있다. 플랫폼이 무결성 증명된 상태에 있고, 플랫폼이 (예컨대 AIK에 의해) 인증될 수 있고, 사용자가 (예컨대, UICC/GBA의 소유에 의해) 인증될 수 있다면, NAF는 OpenID 식별자를 인가할 수 있다. 이러한 프로토콜은 사용자가 자신의 OpenID 식별자를 단일 UICC를 갖는 단일 구성으로 단일 플랫폼과 함께 이용하도록 잠금설정하게 할 수 있다.

도 5와 도 6은 OpenID 활용을 위해 WTRU와 (예컨대, 사용자와 연관된) UICC를 바인딩하기 위한 예시적인 다이어그램들이다. 도 5는 예시적인 콜 흐름도를 나타낸다. 도 6은 컴포넌트들간의 예시적인 관계를 도시한다. 구현들은 비신뢰적인 WTRU 엘리먼트들, 예컨대 브라우저와의 보안 통신을 보장할 수 있다. 도 5를 참조하면, 예시적인 프로토콜 단계들은 다음 중 하나 이상을 포함할 수 있다: 1) 사용자는 RP로의 접속을 구축할 수 있다; 2) RP는 OP/NAF와의 연관을 개시할 수 있다; 3) RP는 WTRU의 브라우저를 OP/NAF로 리다이렉팅할 수 있다; 4) WTRU와 OP/NAF간의 통신은 인증을 담당할 수 있는 TTS를 통해 행해질 수 있다(예컨대, TTS는 GBA 챌런지와 함께 TOpenID 챌런지를 수신할 수 있다). 5) TTS는 UICC로의 보안 채널을 구축할 수 있다; 6) TTS는 GBA 챌런지를 UICC에 포워딩할 수 있다; 7) UICC는 OpenID/GBA 프로토콜에서와 같은 다이제스트를 계산한다; 7a) UICC는 TSS에게 (예컨대, OpenID/GBA 다이제스트와 함께) GBA 응답을 보낼 수 있다; 8) TTS는 TOpenID 프로토콜을 위한 플랫폼 입증 데이터/증명 데이터를 검색할 수 있으며, 플랫폼 입증 데이터/증명 데이터는 WTRU의 신뢰성 표시(즉, AIK로 서명된 SML 및 PCR 쿼트)를 포함할 수 있다; 9) TTS는 UICC GBA 응답 및 플랫폼 입증 데이터/증명 데이터를 포함한 결합된 응답으로 OP/NAF에 응답할 수 있다; 10) OP/NAF는 플랫폼 입증 데이터/증명 데이터로 GBA 응답을 검증하고 무결성을 검증할 수 있다(예컨대, SML PCR 쿼트가 이전에 생성된 참조값과 매칭한다라고 검증하며, 이것은 WTRU의 현재 시스템 상태가 이전 상태와 매칭한다는 것을 표시할 수 있다); 11) OP/NAF는 (예컨대, RP로의 ME의 브라우저의 리다이렉트 동작의 일부로서) WTRU의 브라우저를 통해 RP로 포지티브 어써션을 발행할 수 있다. 즉, NAF는 플랫폼 입증 데이터 및/또는 사용자를 검증하였다는 것을 나타내는 플랫폼 검증을 보낼 수 있다. 플랫폼 검증은 간접적으로 또는 직접적으로 전달될 수 있다(예컨대, 플랫폼 검증은 WTRU/사용자가 신뢰적인 당사자(RP)에 대한 액세스를 승인받는 것을 포함할 수 있다).

TTS는 반드시 UICC와의 보안 채널을 구축할 필요가 있는 것은 아닐 수 있다. 두 개의 독립적인 세션들, 즉 UICC와 OP/NAF간의 하나의 GBA 세션 및 TTS와 OP/NAF간의 증명 세션을 수행하는 것이 가능할 수 있다. 양쪽 프로토콜들이 잇따라 일어나는 경우에는 OP/NAF는 포지티브 어써션을 발행할 수 있다. 이와 같은 병행적인 세션 시나리오에서는, 증명 결과를 GBA 프로토콜의 인증 결과에 바인딩하기 위해 OP가 적어도 내부적으로 양쪽 세션들을 링크할 것이 필요할 수 있다.

입증 태스크들은 수행할 네트워크와 디바이스에 대한 방대한 양의 자원들을 필요로 할 수 있다. 입증된 디바이스는 예컨대 새로운 입증 프로시저를 겪는 것 없이 후속적인 인증 프로시저들에 대해 또는 네트워크 컴포넌트들과의 상호작용들에 대해서 입증 정보를 재사용할 수 있다. 예를 들어, 네트워크와의 이전의 입증 세션으로부터 생성되었을 수 있는 입증 정보가 재사용될 수 있다. 신뢰적인 티켓 서버는 이어서 입증 티켓(또는 인증서)를 제공할 수 있다. 네트워크에 대한 디바이스의 성공적인 입증에 이어서, MNO의 네트워크 내부의 OP/NAF 엔티티는 티켓을 발행할 수 있고, 이 티켓은 요구시 다른 네트워크 엔티티들로의 재전달을 위해 디바이스에 전달될 수 있거나 또는 엔티티들이 OP/NAF 엔티티로부터 티켓을 간접적으로 획득할 수 있도록 참조되어질 수 있다. OP/NAF 엔티티는 티켓을 갖는 정보를 포함할 수 있으며, 티켓은 티켓/디바이스 신뢰성의 표시를 포함한다. 예를 들어, OP/NAF 엔티티는 타임스탬프, 개시 타임스탬프, 티켓에 대한 수명 한도, 티켓의 종료 일자, 사용량 파라미터 한도 등을 제공할 수 있다. 시간 정보는 네트워크 컴포넌트들이 디바이스의 신뢰할 수 있는 상태를 확인하고 언제 평가가 수행되었는지를 확인할 수 있도록 해줄 수 있다. 티켓을 수신하는 엔티티들은 이 정보를 디바이스와의 안전한 거래를 수행하는데 만족스러운 것으로 간주할 수 있거나 또는 디바이스에서의 신뢰에 대한 특정 애플리케이션의 요구에 따라 재입증을 강제시킬 수 있다.

이러한 티켓은 플랫폼 입증 및 관리를 위해 이용될 수 있다. 티켓이 OP/NAF 엔티티와 디바이스에 바인딩되고, 해당 데이터가 바인딩된 OP/NAF 또는 디바이스 이외의 다른 엔티티들에 의해 변경되지 않을 수 있도록 티켓은 무결성 보호되고 및/또는 기밀성 보호될 수 있다. 디바이스에서의 신뢰적인 환경(trusted environment; TrE)은 티켓을 안전하게 저장할 수 있고, 재입증을 수행하는 것 없이 네트워크와의 후속적인 상호작용들에서 이것을 사용할 수 있다. 티켓은 다른 네트워크 컴포넌트들에게 입증 상태 데이터를 제공하기 위해 디바이스에 의해 분배될 수 있다. 디바이스는 입증 정보를 획득하기 위해 다른 네트워크 엔티티들이 OP/NAF 엔티티를 컨설팅할 수 있는 티켓에 대한 참조를 순환시킬 수 있다.

결합된 TOpenID/GBA 경우, 신뢰 평가자, 예컨대 TTS로부터 측정치들을 수신하며 이 측정치들을 참조 메트릭스들과 비교하여 이 평가에 기초하여 플랫폼의 신뢰성 또는 입증에 대한 스테이트먼트를 유도할 수 있는 엔티티의 위치는 달라질 수 있다.

도 7은 TOpenID/GBA 경우에서 신뢰 평가자로서의 플랫폼 입증 엔티티(platform validation entity; PVE)의 예시를 도시한다. 도 7은 플랫폼 입증 엔티티(PVE; 705), BSF(710), UE(720), OP/NAF(730), 및 RP(740)을 포함한다. MNO의 네트워크 내부에 있는 OP/NAF 엔티티에서 신뢰 입증 프로세스를 병합시키는 것 대신에, 신뢰 평가에 대한 참조 무결성 메트릭들을 이미 소유할 수 있는 기존의 네트워크 엔티티들을 재사용하는 것이 가능할 수 있다. 이러한 예시를 PVE(705)와 같은, 플랫폼 입증 엔티티라고 칭할 수 있다. PVE(705)에는 참조 메트릭스들이 구비될 수 있으며 PVE(705)는 수신한 입증 데이터를 참조 메트릭스들과 비교할 수 있고 디바이스의 신뢰성에 대한 스테이트먼트를 발행할 수 있다. 이러한 시나리오에서, OP/NAF(730)는 내부 네트워크내에서 입증 데이터를 PVE(705)에 포워딩할 수 있으며, 이어서 PVE(705)는 신뢰성 입증을 수행할 수 있다.

신뢰성 평가는 신뢰적인 제3 당사자(trusted third party; TTP)에 의해 이행될 수 있다. MNO 내부 엔티티가 수신한 입증 데이터의 입증을 수행하는 것이 불가능한 경우, NAF/OP는 보안 채널을 통해 외부의 신뢰적인 제3 당사자에게 입증 데이터를 포워딩할 수 있다. 그런 후 TTP는 검증 및 입증을 수행할 수 있고 플랫폼의 신뢰성에 대한 스테이트먼트를 NAF/OP에게 되발행해줄 수 있다.

사용자의 플랫폼의 성공적인 인증 및 검증 이후, 서비스 제공자(service provider; SP)는 WTRU의 신뢰적인 환경(TrE)에서 설치될 수 있는 서명된 자바 애플릿을 WTRU에 보낼 수 있다. 신뢰적인 환경에서 자바 애플릿을 설치하기 전에 TrE는 예컨대 IdP 또는 신뢰적인 제3 당사자(TTP)에 의해 제공된 RIM 인증서 또는 SP로부터의 인증서 및/또는 시그너처를 통해 애플릿 무결성을 검증할 수 있고 보안 UI에 대한 SP 챌런지를 답변할 수 있다. TrE는 현재 애플리케이션이 보안 환경에서 구동할 수 있다는 것을 사용자에게 표시하는 보안 UI를 이용하여 애플릿을 로딩할 수 있다. 이러한 방식은 가짜 SP들로부터 보호될 수 있는데, 예컨대 SP는 IdP에 대해 인증하고 무결성을 증명할 것이 필요할 수 있다. 이러한 방식은 또한 예컨대 TrE 무결성 및 기능성을 검증하고 체크가 성공적인 경우 티켓을 발행하는 IdP에 의해 가짜 TrE들로부터 보호될 수 있다.

격리되고/샌드박싱된 웹 브라우저들이 구현될 수 있다. 전형적인 브라우저 솔루션들과는 대조적으로, 이것은 예컨대 온라인 뱅킹, 웹메일, 비디오 스트림 등과 같은 웹 애플리케이션들의 퍼블리셔들을 목표로 할 수 있고, 각자의 웹 애플리케이션에 대한 특정 매니페스트(manifest)를 정의할 수 있다. 이렇게 디지털방식으로 서명된 매니페스트는 웹 애플리케이션이 구동되어야만 하는 브라우저 및 웹 애플리케이션이 접속하기 위한 허용된 웹 싸이트들의 리스트를 포함할 수 있다. vm 이미지에 대한 URL과 같은 이 브라우저의 가상화 엔티티가 매니페스트에서 정의될 수 있고, 다른 웹 애플리케이션들 및/또는 호스트 동작 시스템(Os)으로부터 웹 애플리케이션을 격리시키도록 구현될 수 있다.각각의 샌드박싱된 웹 애플리케이션들은 예컨대 신뢰 상태들을 제공하기 위해 그래픽 보더들을 활용함으로써 랜더링될 수 있다. 이 개념은 XEN 가상화를 이용하여 이행될 수 있다.WTRU는 디바이스상에서 TTS를 이용하여 플랫폼 증명을 수행하고, 이어서 TrE(신뢰적인 작은 샌드박싱된 자바 애플릿들을 구동하는 환경)를 이용하여 애플리케이션 증명을 수행할 수 있다. TTS와 TrE는 모두 WTRU 디바이스에서의 몇몇의 공통적인 신뢰적 하드웨어 컴포넌트의 최상부상에서 구축될 수 있고, 이 컴포넌트의 기능들을 이용할 수 있다.

보안성을 증가시키기 위해 보안 사용자 인터페이스(보안 UI)는 TOpenID 및 OpenID를 필요로 할 수 있다. 기본적인 TOpenID 프로토콜은 디바이스 무결성 정보를 수집할 수 있는 신뢰적인 티켓 서버로부터 증가된 보안성을 유도할 수 있다. 디바이스 무결성 정보는 OpenID IdP에 의해 평가될 수 있다. 디바이스상에서 구동중인 소프트웨어가 잘 알려지고 신뢰적인 상태에 있는 경우, 인증은 성공적일 수 있다.인증은 TPM 저장되고 PCA 인증된 AIK에 바인딩될 수 있다. AIK는 증명을 위해 이용된 PCR 쿼트에 서명하기 위해 이용될 수 있다. 인증은 주어진 상태에 있는 주어진 플랫폼을 갖는 구현(예컨대, TPM을 갖는 디바이스)으로 제한될 수 있다.

증명 및 무결성 체킹은 일정한 컴포넌트들, 예컨대 TOpenID의 보안 동작에 필요한 컴포넌트들로 제한될 수 있다. 이러한 접근법에서, 디바이스는 신뢰적인/보안 부분과 비신뢰적인 부분으로 분리될 수 있다. 신뢰적인 티켓 서버는 신뢰적인 세계 내부의 신뢰적이고 무결성 체크된 애플리케이션으로서 구동될 수 있다. 드라이버들을 비롯한 하드웨어에 대한 액세스는 신뢰적인 세계에서의 서비스 인스턴스에 의해 보호될 수 있다. 디바이스의 능력들에 대한 액세스는 비신뢰적인 세계에게 필요한 API들을 제공할 수 있는 이러한 서비스 인스턴스를 통해 제한될 수 있다. 이러한 API들은 디바이스 능력들에 대한 액세스를 제공할 수 있고 액세스 제한이 시행되도록 해줄 수 있는 보안 정책 프레임워크를 구비할 수 있다.

IdP에 의한 무결성 체킹 및 입증이 디바이스의 부분들로 제한되는 경우, 사용자는 신뢰적인 티켓 서버와의 OpenID ID의 이용을 확인할 것을 필요로 할 수 있고, 이러한 입력은 중간자 공격 또는 맨 인더 디바이스/맨 인더 브라우저 공격의 방식으로 차단되거나 리플레이되지 않을 수 있다는 것을 확인할 필요가 있을 수 있다.신뢰적인 부분은 입력을 보호하고 사용자 자신이 보안 모드에서 디바이스를 이용중에 있을 수 있다는 것을 표시할 수 있는 신뢰적인 사용자 인터페이스(User Interface; UI)를 제공할 수 있다. 예시적인 표시자는, 디바이스(프로세서)가 신뢰 모드에서 구동중에 있을 때에 발광할 수 있는 발광 다이오드(LED)일 수 있다. LED는 신뢰적인 엘리먼트 또는 보안 엘리먼트에 의해 제어될 수 있다. 사용자가 OpenID 티켓의 이용에 대한 크레텐셜들을 입력하려고 할 때 마다, 보안 UI는 디바이스가 보안 모드에서 동작중에 있다는 것을 표시할 수 있다.LED와 같은 디바이스는, 외부 프로세서 인터페이스에 접속되고 보안 하드웨어 인터페이스를 통해 보호된 맵핑가능한 어드레스 공간에 있을 수 있으며, 여기서의 액세스는 보안 환경 및 신뢰적인 환경으로 제한될 수 있다.

그래픽스 디바이스의 보호된 프레임 버퍼의 부분들이 이용될 수 있다. 다른 드라이버들은 디바이스 메모리의 이러한 부분으로부터 기록 또는 판독하는 것이 허용되지 않을 수 있다. 그런 후 보안/신뢰적인 드라이버는 악성 소프트웨어에 의한 "보안 아이콘"의 디스플레이를 방지하기 위해 디스플레이 프레임 버퍼에 직접 기록함으로써 디바이스의 디스플레이상에서 그래픽 정보를 디스플레이하는 것에 의해 이 프레임 버퍼 메모리를 이용하여 보안 UI의 이용을 표시할 수 있다.

OpenID 인증에 대한 UI로서 작용할 수 있는 브라우저는 무결성 체크될 수 있고 신뢰적인 세계내로 통합될 수 있다. 브라우저가 신뢰적인 부분내에 포함되지 않은 경우, 사용자 OpenID 로그인이 이용될 때 마다 보안 UI를 통해 사용자는 승인을 제공할 것이 필요할 수 있다. 사용자가 OpenID 식별자를 이용하여 싸이트에 로그인하기를 원하는 경우, 브라우저는 신뢰적인 티켓 서버에 챌런지를 포워딩할 수 있다. 신뢰적인 티켓 서버는 UI를 보안 UI로 스위칭하고, 인증을 완료하기 위해 사용자가 보안 UI와 상호작용할 것을 필요로 할 수 있는 승인 인터페이스를 사용자에게 제공할 수 있다. 신뢰적인 티켓 서버는 응답을 생성하여 이것을 잠재적으로 손상된 브라우저를 건너뛰고 OpenID IdP에게 포워딩할 수 있다. 신뢰적인 OpenID 프로세스에서, WTRU의 브라우저 및 사용자 인터페이스는 보안화될 수 있다.

신뢰적인 시각적 토큰(Trusted Visual Token; TVT)이 이용될 수 있다. 신뢰적인 시각적 토큰은 다음의 기술 특징들 중의 하나 이상의 조합을 포함할 수 있다.

시각적 증명은 사용자의 플랫폼(사용자가 상호작용하고 있는 디바이스)이 신뢰할 수 있는 상태에 있다는 것을 증명하는 몇몇의 시각적 정보의 사용자에 대한 디스플레이를 포함할 수 있다. 이러한 시각적 정보는 예컨대 사용자에게는 알려져 있지만 다른 사람들에게는 알려지지 않으며 암호화된 형태로 플랫폼상에서 제공되는 시크릿 이미지를 포함할 수 있으며, 플랫폼이 미리정의된 상태에 있는 경우에 암호해독이 허용될 수 있다. 이것을 실링(sealing)이라고 부를 수 있다.

시각적 증명은 추가적인 시각화 방법들에 의해 증강될 수 있다. 예컨대, 발생중인 특정 거래의 데이터(예컨대, 사용자 인증, 결제 데이타 등)가 시각화에서 포함될 수 있다. 이것은 캡쳐 및 리플레이 공격을 하는 것을 어렵게 만들 수 있다.

허가된 표시자(Privileged Indicator; PI)는 플랫폼을 위한 보안 입력 경로(예컨대, 키)일 수 있으며, 플랫폼 내부의 엔드포인트는 신뢰적인 환경 또는 보안 엘리먼트이며, 예컨대 희망하는 거래를 위해 신뢰적일 수 있는 몇몇의 실행 공간이다.

사용자는 자신의 권한하에 있는 챌런지 응답 메커니즘에 의해 플랫폼의 시각적 증명을 제어할 수 있다. 사용자는 거래(예컨대, 인증, 온라인 결제 등) 프로세스 동안에 일정한 포인트에서, 플랫폼이 시각적 증명으로 응답할 수 있는 자신의 플랫폼에 대한 챌런지를 제기할 수 있다. 이것은 허가된 표시자를 이용하여 이행될 수 있다.

허가된 표시자 챌런지는 거래 동안에 절차적으로 이용될 수 있고 우회되지 않을 수 있도록 거래와 결합될 수 있다.

위 특징들은 신뢰적인 시각적 토큰(TVT)으로서 온라인 거래에서 이용하기 위해 플랫폼에서 결합될 수 있다. TVT는 예컨대 소프트웨어 신뢰적인 환경 또는 (스마트 카드와 같은) 하드웨어 보안 실행 환경에서 실현되고, 미리정의된 방식으로 PI를 통해 제기된 사용자 챌런지에 대해 시각적 증명으로 응답할 수 있는, 사용자의 플랫폼상에서의 신뢰적인 엔티티일 수 있다. TVT는 다음의 특징들 중 하나 이상을 가질 수 있다.

TVT의 신뢰할 수 있는 상태를 사용자에게 증명해주는 TVT 시각적 증명은 플랫폼의 메인 또는 또 다른, 전용 디스플레이상에서 사용자에게 디스플레이될 수 있다.

TVT는 시각적 증명을 위한 하드웨어 보안화된(예컨대, 스마트 카드, TPM 실링 등) 시크릿들을 이용할 수 있다.

TVT는 생체 측정 입력과 같은 사용자를 인증해주기 위한 방법에 대한 액세스를 가질 수 있다.

TVT의 신뢰할 수 있는 상태는 예컨대 원격 증명을 이용하여 원격 당사자에 의해 입증될 수 있다.

TVT는 플랫폼의 다른 컴포넌트들, 예컨대 브라우저 또는 온라인 뱅킹 애플리케이션을 입증할 수 있고, 시각적 증명에서 이러한 컴포넌트들의 신뢰성에 관한 정보를 병합시킬 수 있다.

TVT는 특별한 거래에 특유적인 데이터에 대한 액세스를 가질 수 있고, 이러한 데이터를 의미있고 고유한 방식으로 시각적 증명에 병합시킬 수 있다.

시각적 증명에서 TVT에 의해 디스플레이되는 것의 기본적인 양식들은 아래 중 하나 이상의 것들을 포함할 수 있으며, 이것들은 특정한 사용 경우에서 필요로 할 때에 결합될 수 있다.

TVT는 사용자와 연관된 정보, 예컨대 사용자 등록된 시크릿, 개인 정보 등을 디스플레이할 수 있다. TVT는 시간 의존적일 수 있는 TVT 특유적 시크릿을 디스플레이할 수 있다. TVT는 거래 특유적 데이터, 예컨대 거래 횟수, 거래량, 통화 유형 등을 디스플레이할 수 있다. TVT는 사용자 통지들을 디스플레이할 수 있는데, 예컨대 사용자는 예컨대 허가된 표시자를 계속 누르면서 지문 판독기를 이용하여 거래에 권한을 부여하도록 프롬프팅될 수 있다.

거래에서의 TVT의 기본적인 활용은 국지적으로 또는 원격 당사자에 대한 사용자 인증의 활용일 수 있다. '로그온'이라고 칭해질 수 있는 이 프로세스는 다음 특징들 중 하나 이상을 포함할 수 있다.

사용자가 플랫폼 또는 원격 서비스에 로그온할 것을 희망하는 경우, 사용자는 웹상에서의 서비스의 로그온 페이지에 대한 로그온 애플리케이션 또는 브라우저를 오픈할 수 있다. 사용자는 PI를 눌러서 로그온에 관한 시각적 증명을 획득할 수 있다. 도 8은 이러한 예를 제공한다.

이러한 형태의 시각화는 TVT의 상태를 증명하는 시크릿 이미지를 포함시킴으로써 증강될 수 있다. 도 9는 이러한 예를 제공한다.

TVT 시각적 증명의 추가적인 보안 강화는 추가적인 정보, 예컨대 랜덤하게 나타나고, 삭제하기 어렵고, 신선하고, 머신 의존적인 인간 판독가능한 정보를 포함시킴으로써 달성될 수 있다. 도 10은 이러한 예를 제공한다.

사용자 로그온을 위한 TVT의 활동은 원격 당사자, 예컨대 사용자 인증을 요청하는 웹 서비스에 의해 트리거될 수 있다. TVT가 일반적인 로그온 통지를 디스플레이할 때, 원격 서비스는 (예컨대 상호적으로 인증된 채널을 통해) 사용자 인증을 필요로 한다는 것을 플랫폼상의 TVT에 시그널링할 수 있다. 예를 들어, 사용자는 PI를 누를 수 있고 TVT는 자신의 시각적 증명을 수행할 수 있다. 사용자는 여기서 설명된 직접적 로그온 변형으로서, 예컨대 생체 측정 입력을 이용하여, 국지적으로 인증할 수 있다. 도 11은 예시적인 시각적 표시를 제공한다.

도 12 및 이하의 설명은 신뢰적인 컴퓨팅 개념들에 기초한 플랫폼상에서의 TVT의 예시적인 구현을 제공한다. 이하 내용은 예시로서 마이크로소프트 윈도우즈 네트워크 도메인을 포함할 수 있지만, 이러한 구현예들로 제한되는 것은 아니다.

아래의 약자들이 도 12 및 아래의 설명에서 이용될 수 있다.

TCB: Trusted Computing Base (신뢰적인 컴퓨팅 베이스)

BIO: Biometric authentication function (생체 측정 인증 기능)

RoT: Root of Trust (신뢰 루트)

MOD LSASS: Modified Local Security Authority Subsystem (수정된 로컬 보안성 권한 서브시스템) - 로컬 및 네트워크 사용자 로그온을 담당하는 마이크로소프트 윈도우즈 컴포넌트

REQ: 'Request' (요청)

DEC: Decryption keys for ENC (ENC용 암호해독 키들)

ENC: keys to encrypt TVT secret data (TVT 시크릿 데이터를 암호화하기 위한 키들)

시스템 시동시의 보안적이거나 또는 인증된 부트 프로세스에서, 플랫폼의 RoT들은 예컨대 플랫폼의 PCR(Platform Configuration Register)들(도면부호 1b)에서, TVT 애플리케이션의 상태를 측정하고 및/또는 저장할 수 있다(도면부호 1a). TVT 애플리케이션은 런타임시 TVT의 보호를 포함하는 신뢰적인 환경내에 포함될 수 있다. 측정 설비뿐만이 아니라 RoT들은 플랫폼의 TCB, 예컨대 시스템 동작 동안에 무조건적으로 보안화될 것으로 간주되는 컴포넌트들의 세트에 포함된다.

사용자가 이러한 플랫폼을 이용하여 네트워크 도메인에 로그온할 것을 원하는 경우, 도메인 제어자는 플랫폼으로부터 사용자 크레덴셜들을 요청할 수 있다(도면부호 2). 이 점에서 TVT 활동이 발생할 수 있고 여기서 설명된 바와 같이 원격적으로 요청된 TVT 사용자 로그온이 개시될 수 있다. 사용자는 PI를 이용할 것을 통지받을 수 있는데, 예컨대 도면부호 3에서의 이용을 살펴봐라. PI 신호가 TCB내에 포함된 몇몇의 PI 기능부에 전달될 수 있다.

PI 기능부는 TVT 마스터 암호해독 키들 Dec을 실링해제하고(도면부호 4), TVT의 상태를 언급하면서, Dec에 대한 실링해제 요청을 플랫폼 RoT들에 대해 발행할 수 있다. 예컨대, 상태가 옳바른 경우(실링해제), RoT들은 상태를 체크하고 Dec를 암호해독할 수 있다(도면부호 5).

Dec 키들은 TCB 내부에서 이용하는 것으로 제한될 수 있는 키 계층의 부분, 예컨대 TPM 키 계층의 키들을 가리킬 수 있다. Dec는 대응하는 암호 키들 Enc로 암호화되는 TVT 시각적 증명 씨드들을 암호해독하는데 이용될 수 있다.

PI 기능부는 사용자에 대해 시각적으로 증명할 것을 TVT 애플리케이션에게 명령내릴 수 있다(도면부호 6). TVT 애플리케이션은 TVT 씨드들의 암호해독을 요청할 수 있고(도면부호 7), 이것은 Dec를 이용하여 수행될 수 있으며(도면부호 8), TVT는 TVT 애플리케이션에 제공될 수 있다(도면부호 9). 이것들을 이용하여, TVT 애플리케이션은 예컨대 생체 측정 입력 BIO를 이용한 로컬 사용자 인증에 대한 요청을 비롯하여, 시각적 증명을 수행할 수 있다(도면부호 10).

사용자는 BIO에 대해 인증할 수 있고(도면부호 11), BIO 설비는 인증 성공을 TVT에 시그널링할 수 있다(도면부호 12).

TVT는 자신의 사용자 계정 데이터 저장소로부터 사용자 크레덴셜들, 예컨대 네트워크 로그온을 위해 이용될 사용자명 및 패스워드를 요청할 수 있다(도면부호 13). 이러한 데이터는 암호해독되어 TVT로 보내질 수 있고, 이어서 TVT는 이것을 로그온 애플리케이션 LSASS(도면부호 14)에 제공할 수 있으며, 이어서 로그온 애플리케이션 LSASS는 이것을 네트워크 도메인 제어자에게 포워딩할 수 있다.

TVT에 의해 이용된 시크릿들은 두 개의 등급들을 포함한다.

TVT 씨드들은 TVT가 사용자에 대해 시각화하는데 이용하고 원격 엔티티들과 보안적으로 통신하는데 이용하는 시크릿들을 포함할 수 있으며, 이러한 씨드들은 다음 중에서 하나 이상을 포함할 수 있다: 시각화를 위한 씨드들; TVT 개별 시크릿들(예컨대, 플랫폼에 특유적인 것); 다른 엔티티들과의 보안 통신을 위한 TVT 크레덴셜들; 사용자 정의된 파라미터들; 애플리케이션별 시크릿들; 사용자 등록된 시크릿들 등. 사용자 계정 데이터는 패스워드 벌트(vault)와 유사할 수 있는 TVT의 기능들을 표현할 수 있다. 이러한 기능들은 다음 중에서 하나 이상을 포함하지만, 이것으로 제한되는 것은 아니다: 생체 측정 사용자 참조 데이터; 도메인, 원격 서비스 및 사용자명 리스트 및 연관들; 사용자 크레덴셜들, 예컨대 패스워드들 또는 패스워드들의 해쉬 값들; 원격 서비스 또는 도메인 제어자의 인증을 위한 크레덴셜들 등.

RP와 TTS간에 상호적 인증이 일어날 수 있다. RP - 사용자 인터페이스가 보안화될 수 있는 방법과 사용자가 악성 RP들로부터 보호될 수 있는 방법을 포함하도록 OpenID 프로토콜이 정의될 수 있다. 사용자가 RP에서 자신의 아이덴티티(예컨대 OpenID 식별자)를 로그인 필드에 입력할 때 악성 RP는 OpenID 프로토콜에 대한 위협을 부과할 수 있다. 사용자는 어떤 기저 프로세스들이 발생중에 있는지를 이해하지 않을 수 있지만, 사용자는 자신이 OpenID를 이용하여 방문하는 싸이트들에 대해 자신의 아이덴티티가 관리될 수 있는 IdP 페이지로 리다이렉팅될 수 있다. IdP에서 사용자는 자신의 크레덴셜들(예컨대, 패스워드)을 입력할 수 있고 리다이렉팅될 수 있다. 하지만, 또한 OpenID 인에이블드된 또 다른 페이지를 사용자가 방문할 때, IdP는 패스워드를 다시 요청하지 않을 수 있고 이 대신에 저장된 쿠키를 이용할 수 있다. 악성 싸이트 RP는 사용자들의 크레덴셜(패스워드)을 훔치려는 목적을 갖는 가짜 싸이트일 수 있는 확실해 보이는 IdP로 사용자를 리다이렉팅하는 것이 가능할 수 있다. 그런 후 가짜 IdP는 사용자가 진짜 IdP를 갖고 OpenID에 로깅하게 할 수 있으며 사용자는 이상한 것을 경험하지 않을 수 있다. 사용자가 OpenID를 이용하여 로그인한 싸이드들에 대한 SSO 포인트로서 IdP가 역할을 할 수 있고, 이에 따라 공격자는 사용자로부터 많은 계정들을 훔칠 수 있다는 사실에 의해 공격 충격은 증가될 수 있다. 사용자를 속여서 패스워드를 수집하는 가짜 IdP 페이지에 방문하게 하는데에는 단일의 악성 RP 웹싸이트가 이용될 수 있다.

RP 인증은 TTS를 이용하여 일어날 수 있다. 패스워드 피싱 공격은 다음 중 하나 이상을 이용함으로써 완화될 수 있다.

마이크로소프트 정보 카드가 크레덴셜로서 이용될 수 있으며, 이로써 사용자들은 도용될 수 있는 패스워드를 입력할 필요가 없을 수 있다. 정보 카드는 스크린상으로부터 선택될 여러 개의 '카드들'을 사용자에게 보여줄 수 있는 마이크로소프트 기술이다. 사용자는 서비스에 대한 인증을 위한 카드를 선택할 수 있다. 정보 카드는 아이덴티티에 대한 소유 증명을 제공하기 위해 암호 증명을 이용할 수 있다. 이러한 증명들은 재사용이 불가능할 수 있고 리플레이되지 않을 수 있기 때문에, 패스워드 채취 싸이트에 의한 캡쳐링은 OpenID 아이덴티티에 대한 액세스를 초래시키지 않을 수 있다.

각각의 RP는 사용자측에서 인증될 수 있다. 이러한 인증은 사용자가 OpenID로부터 기대하는 SSO 경험을 방해하지 않는 보안적인 방식으로 수행될 수 있다. TOpenID에서, TTS는 RP로부터 주어진 크레덴셜들을 검증하는 엔티티일 수 있다. RP로의 HTTPS 접속을 이용할 때, TTS는 브라우저에 대한 프록시로서 역할을 할 수 있고 브라우저로부터 OpenID 인에이블드 싸이드로의 콜을 차단할 수 있다. 이러한 차단 메커니즘은 HTTP GET 요청 이후에 RP로부터 브라우저로 보내진 페이지에서 로그인 폼을 인식할 수 있다. 그런 후 TTS는 도메인 인증서를 요청할 수 있고 그 유효성을 체크할 수 있다. 만약 인증서가 유효하면, 사용자는 적어도 자신이 방문한 싸이트가 암호화된 접속을 이용하고 있다는 것을 보장받을 수 있다. 어써팅된 아이덴티티들과 같은, 보안 소켓 레이어(secure socket layer; SSL) 인증서들의 추가적인 특징들이 TTS에 의해 구축되고 체크될 수 있다. 어써팅된 아이덴티티는 TTP가 알려진 피싱, 멀웨어 등의 싸이트들의 블랙리스트 또는 잘 알려진 페이지들의 데이터베이스를 유지하고 TTS에게 이러한 싸이트들에 의해 이용될 것으로 알려진 모든 인증서들의 철회 리스트를 제공하는 것일 수 있다.

TTS는 모듈라 접근법에서 확장될 능력을 가질 수 있다. 예를 들어, 구글 페이지랭크, WTO(Web Of Trust) 스코어를 평가하는 모듈, 평판 시스템 등을 고려하는 또 다른 모듈이 존재할 수 있다. 이러한 모듈들은 TTS에 대한 스코어를 제공할 수 있고, 이로써 예컨대 사용자 정의된 가중화 정책들의 이용에 의해, 모듈 입력들의 요약된 스코어를 계산하고 사용자에게 싸이트의 평가를 제공하는 것이 가능할 수 있게 해준다. 이러한 특징은 예컨대 화이어폭스 또는 인터넷 익스플로러에서 기존 문의들을 뛰어 넘을 수 있으며, 여기서는 발행한 CA에 대한 신뢰적 관계의 미스매칭 또는 누락의 경우에 사용자들이 인증서를 체크하도록 요청받는다. 이러한 모듈들은 또한 SSL 인증서들이 이용가능하지 않을 수 있는 RP에 대한 비HTTPS 접속을 위해 이용될 수 있다. 일반적으로 모듈들은 보안 환경, 예컨대 TTS에 의해 이용된 것과 동일한 보안 환경에서 구동할 수 있으며, 이 모듈들은 TTS와 안전하게 통신할 수 있다.

기존의 페이지들의 해쉬 값들의 작은 참조 데이터베이스를 유지하는 것이 가능할 수 있다. 새로운 페이지들에 대해 등록 프로세스가 정의되어야만 할 수 있지만, 참조 메트릭스들의 세트가 웹 페이지들/서버들에 대해 존재한다는 것을 가정하면, TTS는 이러한 것들을 이용하여 방문한 RP의 무결성 및 진정성을 검증할 수 있다. 원격 증명 프로토콜에 따라, TTS 및 OpenID IdP 프로토콜들과 마찬가지로, RP는 TTS에 대해 자신의 무결성을 증명할 수 있고, 이어서 성공적인 증명의 경우 TTS는 더 진행하도록 허용할 수 있다.

TTS와 RP간의 예시적인 상호 인증은 다음 중 하나 이상을 포함할 수 있다. 상호 인증은 RP 웹싸이트 및 서버의 아이덴티티 및 신뢰성의 체크를 넘어설 수 있다. 프로세스는 RP에 의해 디바이스상에서 구동중인 TTS의 무결성 및 진정성의 체크를 수반할 수 있다. 이것은 TOpenID의 기업 또는 관공서 등록의 경우에 유용할 수 있으며, 여기서는 사용자가 인증 메커니즘으로서 TOpenID를 실제로 이용중에 있다라는 것을 RP들이 보장받을 수 있다. RP는 어떠한 유형의 인증 메커니즘, 예컨대 TOpenID가 IdP와 사용자 TTS 사이에서 이용된다는 것을 보장받기를 원할 수 있다. 하지만, RP는 IdP가 실제로 TTS를 이용한다는 것을 신뢰해야만 할 수 있다. 그렇지 않으면, 사용자는 또 다른 메커니즘을 이용하여 자신의 OpenID IdP에 대해 인증하면서 TOpenID를 이용할 것을 청구할 수 있다.

이러한 인증은 프로토콜에 대한 여러 수정들을 수반할 수 있다. RP는 (예컨대, 사용자의 디바이스상에서의 TTS의 진정성 및 잠재적으로 무결성을 검증한 후) 일종의 넌스(nonce)를 TTS에 보낼 수 있다. 이 넌스는 고유할 수 있고 이 특정한 클라이언트 TTS로부터 이 요청에 대한 식별자로서 역할을 할 수 있다. TTS는 로그인 요청과 연관된 보호된 저장소에 이 넌스를 보안화하여 저장할 수 있다. RP가 사용자를 IdP에 리다이렉팅시킨 후, IdP는 TOpenID에서와 같은 인증 프로토콜을 수행할 수 있다. TTS는 이전에 인증된 OP에 대해 넌스를 릴리즈할 수 있다(예컨대, 릴리즈는 TOpenID 프로토콜에서 이용하는 것으로 제한될 수 있다). IdP로부터 RP로의 어써션은 TOpenID가 인증을 위해 실제로 이용되었다라는 것을 RP에게 보장할 수 있는 넌스를 포함할 것을 필요로 할 수 있다.

이 시나리오에서 이용된 넌스라는 용어는 TOpenID 인증이 IdP에 대해 이용될 수 있다는 것을 검증하기 위해 RP에 의해 TTS에 전달된 토큰을 기술하기위해 이용될 수 있다.

넌스의 보안 특성들을 정의하기 위해, 상이한 공격 유형들을 고려할 수 있다. 사용자는 비TOpenID 인증을 수행한 후 통신에 넌스를 주입하려고 시도할 수 있다. 이것은 사용자가 어렵지만 불가능하지는 않은 것으로 추정될 수 있는 IdP와 RP간의 통신을 차단할 것을 요구할 수 있다. 사용자는 또한 TTS로부터 또는 RP와의 TTS로부터의 초기 통신으로부터 넌스를 추출할 수 있다. 만약 넌스가 보안화된 저장소에 저장되고, TTS가 손상되지 않은 경우, 이것은 어려울 수 있다. RP는 제일먼저 TTS 무결성을 검증하고 그러고 나서 넌스를 보낼 수 있기 때문에, 손상된 TTS는 이러한 넌스를 RP로부터 수신하지 않을 수 있다라고 가정될 수 있다. 이러한 보안 인지한 RP는 사용자의 디바이스들상에서 구동중인 TTS 인스턴스들의 무결성 메트릭스들을 구비할 수 있다. RP들로부터 넌스들을 수신하고 있는 TTS 인스턴스들이 보안화되면, 이러한 TTS들은 악성 사용자들로부터 넌스를 안전하게 보호하는 것으로 가정될 수 있다.

또 다른 공격 모델은 인증 메커니즘을 속여서 TTS로부터 넌스를 검색하려고 시도할 수 있는 악성 IdP를 수반할 수 있다. 이러한 시나리오에서 TTS는 넌스를 효율적으로 보안화하는 것으로 가정될 수 있다. 보다 복잡한 공격 모델은 IdP와 사용자를 유착시키는 것을 수반할 수 있다. 사용자가 넌스를 획득할 수 있는 경우 사용자는 TOpenID 인증을 수행하지 않고서 이 넌스를 IdP에 포워딩할 수 있다. 그런 후 IdP는 TOpenID를 이용하여 사용자가 인증했다는 것을 청구하는 RP에 대한 메세지에서 이 넌스를 이용할 수 있다.

고려했던 공격 모델들에서는, TTS가 RP에 의해 무결성 체크된 경우 TTS가 넌스를 수신할 수 있다라는 사실과 이러한 TTS는 넌스를 충분히 보호할 수 있고 TOpenID 인증 프로토콜에서 이 넌스를 릴리즈하도록 제한될 수 있다라는 사실에 보안성이 의존될 수 있다는 것을 살펴볼 수 있다. 넌스는 각각의 서비스 액세스에 대해 고유할 수 있기 때문에, 악성 IdP는 RP에 대해 넌스를 리플레이하지 않을 수 있다.

프로토콜은 증명 메커니즘을 포함할 수 있다. OpenID 제공자는 시스템 상태에 관한 정보를 제공할 것을 사용자에게 챌런징할 수 있다. 만약 시스템이 신뢰할 수 있는 상태에 있는 경우, 액세스는 승인될 수 있다. 서비스에 대한 액세스는 '신뢰할 수 있는' 시스템들로 제한될 수 있으므로, 이것은 웹 애플리케이션들에 대한 보안성을 레버리징시킬 수 있다.

유입하는 OpenID 인증 요청들을 경청하고 이 요청들을 TPM에 포워딩하는 사용자측상의 서비스 애플리케이션을 갖는 것 대신에, 끊김없는 브라우저 통합이 제공될 수 있다. 이것은 이러한 기능을 취하는 브라우저 확장을 이용함으로써 달성될 수 있다. OpenID 제공자는 서명 페이지의 HTML 코드 내부에서 챌런지를 발행할 수 있다. 브라우저 확장은 이 정보를 판독하고 필요한 데이터를 TPM에 포워딩할 수 있다. 이어서 TPM은 서명된 티켓을 생성하고 이것을 브라우저 확장에 반환할 수 있다. 그 후 이러한 확장은 서명된 티켓을 포함하는 옳바른 HTTPS 응답을 OpenID 제공자에게 발행할 수 있다.

만약 디바이스가 UICC를 갖는 경우, 브라우저는 디바이스내 UICC상에서 구현될 수 있다. UICC상에서 브라우저를 구현하는 것은 브라우저가 동작하도록 해주는 내재적인 보안 환경을 디바이스에게 가져다 줄 수 있다. UICC내의 브라우저와 (TPM을 포함한) 나머지 디바이스간의 인터페이스는 또한 GBA 기반 보안 채널을 이용하여 보안화될 수 있다.

OMTP BONDI 프레임워크는 위젯들 또는 웹 애플리케이션들이 HTML 페이지들에서의 자바스크립트를 통해 디바이스 능력들에 액세스하도록 해줄 수 있는 한 묶음의 API들이다. BONDI는 추가적인 디바이스 능력들에 액세스할 수 있도록 하기 위해 추가적인 API들에 의해 확장가능할 수 있다. BONDI 보안성 프레임워크는 디바이스 능력 액세스 제어 메커니즘을 제공하는 것으로 제한될 수 있고 이로써 BONDI 보안성 프레임워크는 이러한 능력들에 액세스하려고 시도하는 자바스크립트 API들에 독립적으로 특정한 기저 디바이스 능력들에 대한 액세스를 시행할 수 있다. BONDI는 디바이스 능력들을 차폐시키지 않을 수 있다. BONDI는 디바이스 자원들 및 능력들에 대한 배타적인 액세스 제공자가 아닐 수 있다. BONDI에 더하여 다른 프레임워크들 또는 기능들이 존재하는 경우, 이러한 비BONDI 독점적인 자바스크립트 API들 또는 BONDI 프레임워크 외부의 플러그인들은 제어되지 않거나 관리되지 않을 수 있으며 이것들은 BONDI 보안성 프레임워크를 약화시킬 수 있다.

도 13은 TOpenID와의 BONDI의 예시적인 이용에 관한 도면이다. 도면부호 1에서, 사용자는 RP를 방문하고 ID에 대한 XRI를 보낼 수 있다. 도면부호 2에서, RP와 OP간에 연관이 생성될 수 있다. 도면부호 3에서, OP는 HTTP(S) 인증 페이지를 제공할 수 있다. 도면부호 3b에서, 신뢰적인 티켓 서버는 증명을 위한 서명된 SML PCR을 제공할 수 있다. 도면부호 4에서, OP는 SML PCR을 입증할 수 있다. 도면부호 5에서, OP는 사용자가 로그인했던 RP의 URL로 리다이렉트될 수 있다.

예컨대 정책 관리 및 강화가 보안화되어 저장될 수 있고, 디바이스 능력들에 대한 액세스 제공자가 BONDI 프레임워크로 제한되도록, BONDI가 신뢰적인 실행 환경의 최상단상에서 실행되면, 디바이스 능력들에 안전하게 액세스하는 웹 애플리케이션들을 구축하는 것이 가능할 수 있다. 이러한 기능들은 웹페이지로부터 디바이스에서의 보안화된 기능들로의 직접적 액세스를 포함할 수 있다. 웹페이지들이 디바이스상에서 구동중인 신뢰적인 티겟 서버 서비스에 액세스하도록 해주는 특정한 API를 추가하고 신뢰적인 BONDI를 실행하는 것은 브라우저내로의 TOpenID의 끊김없는 통합을 위한 새로운 방식을 열 수 있다.

도 14는 TOpenID와의 BONDI의 이용을 위한 예시적인 콜 흐름도를 도시한다. OpenID OP는 TOpenID 인에이블드 계정들을 위한 인증 페이지에서 BONDI 자바스크립트 명령을 포함할 수 있다. 이 페이지 내의 이러한 자바스크립트는 클라이언트의 브라우저에 의해 실행될 수 있고 제일먼저 BONDI 라이브러리들과 API들을 로딩할 수 있다. 자바스크립트는 HTML 페이지로부터 신뢰적인 티겟 서버에 질의할 수 있다. 이러한 질의는 OpenID OP로부터의 넌스, ID 및 REQ를 포함할 수 있다. BONDI API들을 통해 이러한 질의는 디바이스상의 티켓 서버로 포워딩될 수 있다. BONDI 보안 정책은 신뢰적인 티겟 서버, 예컨대 단일 OpenID OP로 액세스를 제한시키는데에 이용될 수 있다. 신뢰적인 티겟 서버에 대한 각각의 액세스 시도에 대한 사용자 동의를 요구하거나 또는 사용자 허락에 대한 요청이 행해질 수 있다. 신뢰적인 티켓 서버는 서명된 PCR 쿼트 Q 및 측정 로그 ML를 검색할 수 있고 HTTP POST 메시지를 이용하여 이 값들을 OpenID OP에 전달할 수 있다. 그런 후 OP는 수신한 데이터를 평가하고 기본적인 TOpenID 경우에서와 같은 프로토콜과 함께 진행할 수 있다. 이러한 통합의 이점은 보다 적은 사용자 상호작용이 필요로 할 수 있고 OP는 티켓, 예컨대 쿼트 및 ML의 전송을 위한 제2 통신 채널을 개시할 필요 없이 HTTP 프로토콜을 통해 신뢰적인 티켓 서버와 직접적으로 통신할 수 있다라는 점일 수 있다.

도 15는 예시적인 OpenID 프로토콜의 도면이다.

도 16은 예시적인 OAuth 프로토콜의 도면이다.

도 17은 예시적인 결합된 OpenID/OAuth 프로토콜의 도면이다.

도 18은 구글 OpenID를 갖는 예시적인 OpenID 프로토콜의 도면이다.

도 19는 구글 API를 이용한 예시적인 OAuth 프로토콜의 도면이다.

여기서 개신된 바와 같이, 사용자 클라이언트/플랫폼은 예컨대 무선 통신 시스템에서 이용될 수 있는 WTRU 또는 기지국일 수 있다. 일 예에서, 도 20은 진화된 유니버셜 지상 무선 액세스 네트워크(Evolved-Universal Terrestrial Radio Access Network; E-UTRAN)(405)를 포함하는 롱 텀 에볼루션(Long Term Evolution; LTE) 무선 통신 시스템/액세스 네트워크(400)를 도시하지만, 다른 무선 통신 시스템들에서도 적용가능하다. E-UTRAN(405)은 여러 개의 진화된 노드 B(evolved Node-B; eNB)(420)들을 포함한다. WTRU(410)는 eNB(420)와 통신한다. eNB(420)들은 X2 인터페이스를 이용하여 서로 인터페이싱한다. eNB(420)들 각각은 S1 인터페이스를 통해 이동성 관리 엔티티(Mobility Management Entity; MME)/서빙 게이트웨이(Serving Gate Way; S-GW)(430)와 인터페이싱한다. 비록 도 20에서는 단일의 WTRU(410)와 세 개의 eNB(420)들이 도시되지만, 임의의 조합의 유무선 디바이스들이 무선 통신 시스템 액세스 네트워크(400)내에 포함될 수 있다는 것을 분명히 하여야 한다.

도 21은 WTRU(410), eNB(420), 및 MME/S-GW(430)를 포함하는 LTE 무선 통신 시스템(500)의 예시적인 블럭도이다. 도 21에서 도시된 바와 같이, WTRU(410), eNB(420), 및 MME/S-GW(430)는 링키지를 이용한 복잡성 감축을 블라인드 디코딩(blind decoding; BD)하는 방법을 수행하도록 구성된다.

전형적인 WTRU에서 발견될 수 있는 컴포넌트들에 더하여, WTRU(410)는 택일적으로 링크된 메모리(522)를 갖는 프로세서(516), 적어도 하나의 트랜스시버(514), 택일적인 배터리(520), 및 안테나(518)를 포함한다. 프로세서(516)는 여기서 개시된 방법을 수행하도록 구성될 수 있다. 무선 통신의 송수신을 원활하게 해주기 위해, 트랜스시버(514)는 프로세서(516) 및 안테나(518)와 통신한다. WTRU(410) 내에서 배터리(520)가 이용되는 경우, 배터리(520)는 트랜스시버(514)와 프로세서(516)에게 전력을 공급해준다.

전형적인 eNB에서 발견될 수 있는 컴포넌트들에 더하여, eNB(420)는 택일적으로 링크된 메모리(515)를 갖는 프로세서(517), 트랜스시버(519), 및 안테나(521)를 포함한다. 프로세서(517)는 여기서 개시된 방법을 수행하도록 구성될 수 있다. 무선 통신의 송수신을 원활하게 해주기 위해, 트랜스시버(519)는 프로세서(517) 및 안테나(521)와 통신한다. eNB(420)는 택일적으로 링크된 메모리(534)를 갖는 프로세서(533)를 포함한 이동성 관리 엔티티/서빙 게이트웨이(MME/S-GW)(430)에 접속된다.

본 발명의 특징부 및 구성요소들이 특정한 조합형태로 상술되었지만, 본 발명분야의 당업자라면 각 특징부 또는 구성요소들은 단독으로 사용될 수 있거나 또는 다른 특징부 및 구성요소들과 함께 임의의 조합으로 사용될 수 있다는 것을 알 것이다. 또한, 본 명세서에서 설명된 방법은 컴퓨터 또는 프로세서에 의해 실행하기 위한 컴퓨터 판독가능한 매체에 병합된 컴퓨터 프로그램, 소프트웨어, 또는 펌웨어로 구현될 수 있다. 컴퓨터 판독가능한 매체의 예시들에는 (유선 또는 무선 접속들을 통해 송신되는) 전자적 신호들과 컴퓨터 판독가능한 저장 매체를 포함한다. 컴퓨터 판독가능한 저장매체의 예시들에는 ROM(read only memory), RAM(random access memory), 레지스터, 캐시 메모리, 반도체 메모리 장치, 내부 하드 디스크와 탈착가능 디스크와 같은 자기 매체, 광자기 매체, 및 CD-ROM 디스크, DVD(digital versatile disk)와 같은 광학 매체가 포함되나, 이들로 제한되는 것은 아니다. WTRU, UE, 단말기, 기지국, RNC, 또는 임의의 호스트 컴퓨터에서 이용하기 위한 무선 주파수 트랜스시버를 구현하기 위해 소프트웨어와 연계된 프로세서가 이용될 수 있다.

적절한 프로세서에는, 예를 들어, 범용 프로세서, 특수 목적 프로세서, 통상의 프로세서, 디지털 신호 프로세서(DSP), 복수개의 마이크로프로세서, DSP 코어와 연계된 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, 응용 특정 집적 회로(ASIC), 필드 프로그램가능 게이트 어레이(FPGA) 회로, 임의의 유형의 기타 집적 회로(IC), 및/또는 상태 머신이 포함된다.

소프트웨어와 연계되는 프로세서가 무선 송수신 유닛(WTRU), 사용자 장비(UE), 단말기, 기지국, 무선 네트워크 제어기(RNC), 또는 임의의 호스트 컴퓨터에서 사용하기 위한 무선 주파수 트랜스시버를 구현하는데에 사용될 수 있다. WTRU는 카메라, 비디오 카메라 모듈, 비디오폰, 스피커폰, 진동 장치, 스피커, 마이크로폰, 텔레비젼 트랜스시버, 핸드프리 헤드셋, 키보드, 블루투스R 모듈, 주파수 변조(FM) 무선 유닛, 액정 디스플레이(LCD) 디스플레이 유닛, 유기 발광 다이오드(OLED) 디스플레이 유닛, 디지털 뮤직 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저, 및/또는 임의의 무선 근거리 네트워크(WLAN) 모듈 또는 광대역(UWB) 모듈과 같은, 하드웨어 및/또는 소프트웨어로 구현된 모듈들과 함께 사용될 수 있다.

Claims

사용자를 갖는 무선 디바이스에서 수행되는 방법에 있어서,
상기 무선 디바이스에 의해, 네트워크 애플리케이션 기능부로부터 인증(authentication) 요청 - 상기 인증 요청은 상기 사용자에 대응하는 OpenID 아이덴티티를 포함함 - 을 수신하는 단계;
상기 인증 요청이 수락되는 경우, 상기 무선 디바이스 상에 존재하는 신뢰성 있는(trusted) 티켓 서버에 의해, 플랫폼 입증(validation) 데이터 - 상기 플랫폼 입증 데이터는 상기 무선 디바이스의 신뢰성의 표시(measure)와 상기 신뢰성 있는 티켓 서버의 신뢰성의 표시를 포함함 - 를 검색(retrieving)하는 단계;
상기 사용자에 대응하는 OpenID 아이덴티티와 연관된 인증 데이터 및 상기 플랫폼 입증 데이터를 상기 네트워크 애플리케이션 기능부에 보내는 단계; 및
상기 네트워크 애플리케이션 기능부가 상기 플랫폼 입증 데이터 및 상기 사용자에 대응하는 OpenID 아이덴티티를 검증하였다는 것을 나타내는 검증(verification) 데이터를 수신하는 단계
를 포함하는, 무선 디바이스에서 수행되는 방법.
제1항에 있어서, 상기 검증 데이터는 상기 플랫폼 입증 데이터에 의해 나타난 시스템 상태가 이전에 생성된 참조값과 매칭한다는 것을 나타내는 것인, 무선 디바이스에서 수행되는 방법.
제1항에 있어서, 상기 플랫폼 입증 데이터는 상기 무선 디바이스에 의해 서명된 것인, 무선 디바이스에서 수행되는 방법.
제1항에 있어서, 상기 플랫폼 입증 데이터는 사용자 식별 파라미터를 포함한 것인, 무선 디바이스에서 수행되는 방법.
제1항에 있어서, 상기 플랫폼 입증 데이터는 증명(attestation) 데이터를 포함한 것인, 무선 디바이스에서 수행되는 방법.
제5항에 있어서, 상기 증명 데이터는 AIK(attestation identity key)로 서명된 SML 및 PCR(platform configuration register) 쿼트(quote)를 포함한 것인, 무선 디바이스에서 수행되는 방법.
제1항에 있어서, 상기 검증 데이터를 수신하는 단계는 상기 검증 데이터를 포함한 티켓을 수신하는 단계를 포함하며, 상기 티켓은 상기 무선 디바이스의 재입증(revalidation)없이 후속하는 인가(authorization)를 수행하기 위해 재사용가능한 것인, 무선 디바이스에서 수행되는 방법.
제7항에 있어서, 상기 티켓은 타임스탬프를 포함한 것인, 무선 디바이스에서 수행되는 방법.
삭제
제7항에 있어서, 상기 티켓은 수명 한도를 포함한 것인, 무선 디바이스에서 수행되는 방법.
제7항에 있어서, 상기 티켓은 종료 일자를 포함한 것인, 무선 디바이스에서 수행되는 방법.
삭제
제7항에 있어서, 상기 티켓을 수신한 후에 네트워크 엔티티로부터 티켓 참조를 수신하는 단계를 더 포함한, 무선 디바이스에서 수행되는 방법.
제13항에 있어서, 상기 티켓 참조는 상기 네트워크 애플리케이션 기능부로부터 상기 티켓을 획득하기 위해 이용될 수 있으며, 상기 검증 데이터는 상기 무선 디바이스의 재입증없이 후속하는 인가를 수행하기 위해 재사용가능한 것인, 무선 디바이스에서 수행되는 방법.
제1항에 있어서, 상기 인증 요청을 수신하는 단계 전에:
신뢰성 있는 당사자(relying party)에 대한 접속을 구축하는 단계;
상기 네트워크 애플리케이션 기능부를 향한 브라우저 리다이렉션(redirection)을 수신하는 단계; 및
상기 네트워크 애플리케이션 기능부에 상기 사용자 및 상기 무선 디바이스의 인증을 위한 인증 요청을 보내는 단계를 더 포함한, 무선 디바이스에서 수행되는 방법.
제1항에 있어서, 상기 검증 데이터는 신뢰성 있는 당사자에 대해 승인된(granted) 액세스를 나타내는 것인, 무선 디바이스에서 수행되는 방법.