KR101482564B1

KR101482564B1 - 신뢰성있는 인증 및 로그온을 위한 방법 및 장치

Info

Publication number: KR101482564B1
Application number: KR1020127009291A
Authority: KR
Inventors: 안드레아스 레이처; 안드레아스 유 슈미트
Original assignee: 인터디지탈 패튼 홀딩스, 인크
Priority date: 2009-09-14
Filing date: 2009-09-14
Publication date: 2015-01-14
Also published as: CN102577301A; KR101563828B1; JP2013504832A; KR20120055728A; WO2011031272A1; JP5688087B2; EP3382991A1; KR20140037263A; EP2478682A1

Abstract

신뢰성있는 인증 및 로그온을 위한 방법 및 장치가 개시된다. 신뢰성있는 플랫폼 모듈(TPM) 기반 로그온 방법은 인증 및 액세스를 위해 제시된다. 사용자는 사용자의 특정 플랫폼, 예를 들어, TPM에 단단하게 속박된 아이덴티티 제공자에 아이덴티티를 등록한다. 사용자가 이 아이덴티티를 이용하여 예를 들어 서비스 제공자에 로그인하기로 결정하면, 아이덴티티 제공자는 사용자에게 정확한 증명서를 제공할 것을 요구한다. 증명서는 TPM 생성 티켓, 즉, 증명서 체인으로 구성된다. 이것은 사용자가 아이덴티티 제공자에서 비밀번호에 대한 필요성없이 로그인할 수 있도록 한다.

Description

신뢰성있는 인증 및 로그온을 위한 방법 및 장치{METHOD AND APPARATUS FOR TRUSTED AUTHENTICATION AND LOGON}

본 출원은 인증 및 액세스에 관한 것이다.

아이덴티티 관리 및 사용자 인증 및 액세스는 웹 사용, 모바일 서비스, 무선 통신 및 다른 서비스를 위해 중요한 문제이다. 다수의 인증 및 액세스 프로토콜이 존재한다. 예를 들어, OpenID는 사용자 인증 및 액세스 제어를 위한 오픈 분산 프레임워크 및 방법이다. 단일 디지털 아이덴티티는, 사용자가 한번 로그온(logon)하여 다수의 서비스에 액세스하도록 한다. 디지털 아이덴티티는 일반적으로 아이덴티티 제공자에 의해 호스팅되는 고유 URL(universal resource locator)의 형태이다. 아이덴티티 제공자는 사용자가 디지털 아이덴티티로 서비스 제공자에 액세스하기를 원할 때 사용자를 인증한다. OpenID 프레임워크는 사용자를 인증하는 상이한 인증 방법을 허용한다. 아이덴티티 제공자에서의 아이덴티티를 요청하기 위하여, 몇가지 방법이 사용될 수 있고, 가장 공통적인 것은 사용자가 비밀번호를 제공하는 로그온 형태의 사용이다. 그러나, 신뢰성있는 시스템을 사용하지 않으면, 신뢰성있는 당사자가 인증 증명서를 제출하는 통신 파트너에게 신뢰성있는 관계를 확립하기 위한 충분한 증거를 얻지 못한다. 사용자 증명서(예를 들어, 사용자 이름/비밀 번호 조합의 형태)는 플랫폼에 구속되지 않고 따라서 도난당할 수 있다. 공격자는 훔친 증명서를 사용하여 정당한 사용자의 이름으로 서비스를 액세스할 수 있다. OpenID 프로토콜에 대한 인증 증명서를 플랫폼 및 신뢰할만한 상태로 구속함으로써, OpenID 프로토콜의 보안 및 안전이 향상될 수 있다.

티켓 기반 인증 및 허가 프로토콜에서, 소프트웨어 토큰(즉, 티켓)은 단일 엔티티/사용자의 아이덴티티를 증명하는데 사용된다. 이들 토큰에 기초하여, 소정의 시스템으로의 액세스는 적절한 토큰을 생성하는 엔티티/사용자로 제한된다. 또한, 토큰에서 구현되는 데이터는 단순한 인증 외에 토큰 기반 액세스 제어 방식이 가능한 인증 제어를 구현하는데 사용될 수 있다.

또 다른 인증 및 허가 프로토콜은 티켓 시스템 내의 증명서를 확인함에 따라 신뢰성있는 컴퓨팅 환경에서 신뢰성있는 플랫폼 모듈(trusted platform module; TPM)에 의해 생성된 입증 아이덴티티 키(attestation identity key; AIK)를 이용한다. AIK는 TPM에 의해 생성된 증명 키 및 신뢰성있는 측정(measurement)을 서명하는데 사용된다.

이러한 신뢰성있는 티켓 기반 시스템의 현재 구현은 티켓의 암호화를 위한 공공 키 인프라스트럭쳐(public key infrastructure; PKI) 또는 공유 키 데이터베이스를 유지하기 위하여 중앙 데이터베이스의 사용을 필요로 하고, 모든 서비스 제공자는 수신된 티켓을 평가하고 수락하도록 변경될 필요가 있다.

신뢰성있는 인증 및 로그온을 위한 방법 및 장치가 개시된다. 신뢰성있는 플랫폼 모듈(TPM) 기반 로그온 방법은 인증 및 액세스를 위해 제시된다. 사용자는 사용자의 특정 플랫폼, 예를 들어, TPM에 단단히 속박된 아이덴티티 제공자에 아이덴티티를 등록한다. 사용자가 이 아이덴티티를 이용하여 예를 들어 서비스 제공자에 로그인하기로 결정하면, 아이덴티티 제공자는 사용자에게 정확한 증명서를 제공할 것을 요구한다. 이 방법에서, 증명서는 TPM 생성 티켓으로 구성되고, 암호 증명서 체인을 포함한다. 이것은 사용자가 아이덴티티 제공자에서 비밀번호에 대한 필요성없이 로그인할 수 있도록 한다. 사용자의 특정 플랫폼에서의 로컬 비밀번호는 여전히 로컬 공격으로부터 아이덴티티를 보호하는데 사용될 수 있다.

로그온은 특정한 플랫폼의 무결성 검증(integrity verification)과 결합된다. 시스템 구성을 안전하게 저장하는 TPM의 플랫폼 구성 레지스터(platform configuration register; PCR) 상의 TPM 서명 스테이트먼트를 이용하여, 아이덴티티 제공자는 보고된 시스템 상태를 이전에 생성된 기준값과 비교하고 신뢰할만한 플랫폼을 이용하는 정당한 사용자만이 아이덴티티를 로그인하고 요구하도록 할 수 있다. 이 결합된 인증 및 입증은, 인증 데이터를 특정 플랫폼에 구속하고 신뢰할만한 것으로 간주되는 미리 정의된 시스템 상태로 구속함으로써 부드러운 액세스 제어를 허용한다. 이것은, 시스템의 향상된 보안 및 안전을 요구하고 신뢰하지 못할 시스템을 야기하는 임의의 변형을 허용하지 않는 인증 및 액세스 방법을 위한 새로운 사용 케이스를 가능하게 한다.

본 발명에 따르면, 신뢰성있는 인증 및 로그온을 위한 방법 및 장치를 제공하는 것이 가능하다.

더 상세한 이해는 첨부된 도면과 결합하여 단지 예로서 제공되는 다음의 설명으로부터 가능하다.
도 1은 인증 및 액세스 시스템에 대한 예시적인 하이 레벨 아키텍쳐를 나타내는 도면이다.
도 2는 인증 및 액세스 방법에 대한 예시적인 하이 레벨 신호 흐름을 나타내는 도면이다.
도 3(a) 및 3(b)는 인증 및 액세스 방법을 위한 예시적인 신호 흐름을 나타내는 도면이다.
도 4는 LTE(long term evolution)의 무선 통신 시스템/액세스 네트워크의 실시예를 나타내는 도면이다.
도 5는 LTE 무선 통신 시스템의 기지국 및 무선 송수신 유닛의 예시적인 블록도이다.

이하에서 참조될 때, 용어 "무선 송수신 유닛(WTRU)은, 제한되지 않지만, 사용자 장치(UE), 이동국, 고정 또는 이동 가입자 유닛, 페이저, 셀룰러 폰, 개인 휴대 단말기(PDA), 컴퓨터, 또는 무선 환경에서 동작가능한 임의의 다른 타입의 사용자 장치를 포함한다. 이하에서 참조될 때, 용어 "기지국"은, 제한되지 않지만, Node-B, eNode-B(evolved Node-B), 사이트 컨트롤러, 액세스 포인트(AP) 또는 무선 환경에서 동작가능한 임의의 다른 타입의 인터페이싱 장치를 포함한다.

본 개시물은 인증 및 액세스 시스템으로서 OpenID 프로토콜을 이용하고 다른 인증 및 액세스 시스템에 적용가능하다. 기본적인 엔티티 및 그들의 하이 레벨 흐름이 먼저 기재되고 그 후 방법이 상세한 설명이 기재된다.

도 1은, 제한되지 않지만, 클라이언트/사용자 플랫폼(110), 아이덴티티 제공자(120), 사설 증명 기관(privacy certification authority; PCA)(130) 및 서비스 제공자(140)를 포함하는 예시적인 인증 및 액세스 시스템(100)을 도시한다. 클라이언트/사용자 플랫폼(110), 아이덴티티 제공자(120) 및 서비스 제공자(140)는 무선 및 유선 통신 시스템의 임의의 조합을 통해 서로 통신한다. 클라이언트/사용자 플랫폼(110)은 예를 들어, 증명을 저장하는 저장 매체(160)와 통신하는 PCA(130)와 통신한다.

클라이언트/사용자 플랫폼(110)은 WTRU, 기지국, 컴퓨팅 플랫폼, 또는 인증이 필요할 수 있는 임의의 장치일 수 있다. 클라이언트/사용자 플랫폼(110)은, 제한되지 않지만, 클라이언트/사용자 플랫폼(110)에게 데이터에 대한 원격 입증 및 실링 및 결합 능력(sealing and binding capabilities)을 제공하는 신뢰성있는 플랫폼 모듈(trusted platform module; TPM)(115)을 포함한다. TPM(115)은, 키, 비밀번호, 디지털 증명서를 저장하고 암호 키를 생성할 수 있는 마이크로컨트롤러이다. TPM은 마더보드에 부착되거나 시스템의 칩셋에 통합되고 이들 기능을 필요로하는 임의의 컴퓨팅 장치에 사용될 수 있다. TPM(115)은 저장된 정보가 외부 소프트웨어 공격, 물리적 부당변경(tampering) 및 도청으로부터 더 안전하게 되도록 한다. 부트 시퀀스(boot sequence)시 컴포넌트에 대하여 취해진 측정 값이 기준 측정에 대비하여 예측된 것이 아니면 TPM(115) 또는 클라이언트/사용자 플랫폼(110) 내의 데이터 및 비밀로의 액세스가 거부될 수 있다. 따라서, 안전한 이메일, 안전한 웹 액세스 및 데이터의 로컬 보호 등의 중요한 애플리케이션 및 능력이 더 안전해질 수 있다. 신뢰성있는 플랫폼 모듈이 여기에 기재되지만, 예를 들어 신뢰성있는 모바일 모듈 등의 다른 대안의 신뢰성있는 센터가 사용될 수 있다.

TPM(115)은, 제조시 칩 상에 랜덤하게 생성되어 변경될 수 없는 2048비트 RSA 공공 및 개인 키 쌍인 보증 키(endorsement key; EK)를 사용한다. 개인 키는 칩을 절대 떠날 수 없지만, 공공 키는 칩으로 전송된 민감한 데이터의 암호화 및 입증을 위해 사용된다. EK의 공공 부분은 일반적으로 입증을 목적으로 EK 증명서를 통해 PCA(130)에 의해 알려져 있다. 일반적으로, TPM(115)이 예를 들어 아이덴티티 등의 검증자(verifier)에게 자신을 인증할 필요가 있을 때마다, 입증 아이덴티티 키(attestation identity key; AIK)라 불리우는 제2 RSA 키 쌍을 생성하고, AIK 공공 키를 PCA(130)에게 전송하고, 해당 EK에 대하여 이 공공 키를 인증한다. PCA(130)이 그 리스트 내에서 이 EK를 찾으면, TPM(115)의 AIK에 대한 증명서를 발행한다. TPM(155)은 이 증명서를 아이덴티티 제공자(120)에게 제공하여 자신을 인증할 수 있다.

여기에 기재된 바와 같이, AIK(적어도 AIK에서 구현되는 아이덴티티)는 여기에 기재된 티켓의 적어도 일부를 나타낸다. 그러나, 티켓으로서의 AIK의 사용은 TPM(115)에 의해 제한된다. 따라서, 증명키(CertifyKey) 동작이라 불리우는 간접 어프로치가 사용되며, 여기에서, 서명키가 TPM(115)에 의해 생성되고 그를 AIK로 서명함으로써 증명된다. 이 키는 증명 서명 키(certified signing key; CSK)라 한다. CSK 및 AIK는 AIK의 유효성을 입증하는 PCA와 함께 여기에 기재된 티켓의 일부를 구성한다.

클라이언트/사용자 플랫폼(110)은 또한 서비스 액세스를 위해 증명서 또는 티켓을 생성하는 티켓 서버(150)를 포함한다. 티켓 서버(150)는 사용자를 승인한다. 티켓 서버(150)는 플랫폼 입증의 신뢰성있는 컴퓨팅 방법을 이용하여 아이덴티티 제공자(120)에 대하여 클라이언트/서버 플랫폼(110) 및 자신을 인증한다. 티켓 서버(150)는 해당 역할이 간단히 로컬 증명 저장장치에 의해 수행되는 현재의 신뢰성없는 OpenID 아키텍쳐에 존재하지 않는다. 더 많은 보안이 중요한 정보 및 동작이 티켓 서버(150)에 집중되기 때문에, AIK 증명서 및 CSK를 적절하게 처리해야 하고 그들을 다른 플랫폼으로 확산하지 않아야 하고; 티켓 및 증명서를 보호하고; 사용자 인증에 의해 모든 증명서 상의 임의의 보안이 중요한 동작을 보호하고; 공통 웹 브라우저에 직접 통합되고 그들에 의해 액세스될 안전한 옵션을 제공하고, 플랫폼 승인 데이터를 수집, 처리 전송해야 한다. 이것은 여기에서 더 상세히 개시된다.

사용자는 TPM(115) 내에 형성된 AIK를 증명하기 위하여 PCA(130)를 선택해야 한다. PCA(130)는 모든 아이덴티티 관련 정보를 유지할 수 있고 계약 기준이 이 아이덴티티 정보의 비개시(non-disclosure)를 보장하기 위하여 취해져야 한다. PCA(130)에서 AIK를 증명한 후에, 사용자는 아이덴티티 제공자(120)를 선택하여 요구된 아이덴티티를 호스팅할 수 있다. 요구된 아이덴티티는 사용자에 의해 선택된 유니버설 자원 식별자(URI; universal resource identifier)로 표시된다. 이러한 요구된 아이덴티티를 등록하기 위하여, 사용자는 아이덴티티 제공자(120)에 유효한 AIK 증명서를 제공해야 한다. 이것은 여기에서 더 상세히 개시된다.

아이덴티티 제공자(120)에는 최소량의 아이덴티티 관련 정보만이 제시될 수 있다. 사용자는 어떤 정보가 PCA(130)에 호스팅되었는지를 결정할 수 있고 이는 아이덴티티 제공자(120)에게 폭로될 것이다. 계약 기준은 당사자 간의 조정을 확보하기 위하여 취해져야 하고, 그렇지 않다면, 범죄자 PCA가 상이한 사용자에 속하는 아이덴티티를 증명할 수 있다. PCA(130)가 사용자의 실제 아이덴티티를 아이덴티티 제공자(120)에 폭로하지 않음에 따라, 아이덴티티 제공자(120)는 단일 아이덴티티에 상이한 요청을 링크할 수 없다.

PCA(130)는 단지 요구된 아이덴티티를 실제 아이덴티티로 분석할 수 있는 인스턴스이다. 이것은 (고유) EK 증명서를 AIK에 맵핑하는 안전한 데이터베이스를 유지함으로써 이루어질 수 있다. AIK 증명시 사용되는 EK는 TPM(115) 및 클라이언트/사용자 플랫폼(110)의 확실한 식별을 허용한다 (단 하나의 사용자가 플랫폼(110)에 물리적으로 액세스한 것으로 가정하면, 이것은 사용자로 분석된다).

서비스 제공자(140)는 단지 사이트에 대한 아이덴티티 제공자 로그인이 가능해야 한다. 예를 들어, 서비스 제공자(140)는 프론트 페이지 상의 OpenID 로그인 로고를 가질 수 있다. 사용자/클라이언트에 의해 사용되는 아이덴티티 제공자(120)는 서비스 제공자(140)의 알려지고 수락된 아이덴티티 제공자의 리스트 내에 있어야 한다.

이제, 도 2를 참조하면, 도 1에 개시된 시스템(100)에 대한 예시적인 하이 레벨 신호 흐름(200)이 도시된다. 여기에 기재된 바와 같이, 클라이언트/사용자 또는 사용자 플랫폼(210), 서비스 제공자(215) 및 아이덴티티 제공자(220)(예시적인 OpenID 제공자로서 도시됨)는 서로간의 통신을 위해 구성된다.

클라이언트/사용자 플랫폼(210)은 그 웹 브라우저(225)를 사용하여 액세스 웹페이지 메시지(227)를 통해 (index.jsp(235)로서 식별된) 서비스 제공자 웹페이지를 액세스한다. 클라이언트/사용자(210)가 예를 들어 자신의 OpenID URI를 이용하여 로그인하기를 원하면, 서비스 제공자(215)에서의 index.jsp 페이지(235)는 OpenID 로그온 형태 메시지(229)를 통해 URI를 요청하고 OpenID 아이덴티티 메시지(231)를 통해 요구된 아이덴티티를 호스팅하는 OpenID 제공자(220)의 어드레스를 검색한다.

서비스 제공자(215)는 OpenID 제공자(220)와의 연관성을 형성하려고 시도한다. OpenID 프로토콜에 따르면, 서비스 제공자(215)는 연관 메시지(241)를 통해 OpenID 제공자(220)와 연관된다. 이것은 연관 메시지(243)를 통한 요청, 요구된 아이덴티티 및 복귀 URL의 안전한 교환을 포함하고, 인증이 성공적이면 OpenID 제공자(220)의한 리디렉트 메시지(247)가 클라이언트/사용자 플랫폼(210)로 전송된다. 이것은 서버 제공자(215)에서의 consumer_redirect.jsp(240) 및 OpenID 제공자(220)에서의 provider.jsp(245)에 의해 수행된다. 연관 후에, 클라이언트/사용자 플랫폼(210)은 OpenID 제공자 메시지(249)로의 리디렉트(redirect)를 통해 OpenID 제공자(220)의 provider.jsp 웹페이지(245)로 리디렉트된다.

OpenID 제공자(220)는 provider.jsp 웹페이지(245)로부터 provider_authorization.jsp 웹페이지(255)로 전환하여 클라이언트/사용자 플랫폼(210)을 인증한다. 사용자는 provider_authorization.jsp 웹페이지(255) 상의 링크를 클릭함으로써 요청을 개시한다. 이것은 도전 메시지(252)를 통해 티켓 서버(250)에 도전하는 새로운 배경 스레드(thread) TT검증자(TTverifier)(258)를 개시한다. provider_authorization.jsp 웹페이지(255)는 클라이언트/사용자 플랫폼(210)을 TT검증자(258)를 기다리는 provider.jsp 웹페이지(245)로 리디렉트하여 도전 응답 메시지(254)에 제공되는 도전 결과를 종료하고 평가한다. 여기에 기재된 바와 같이, 티켓 서버(250)는 TPM 기능을 이용하여 티켓을 포함하는 적절한 응답을 생성하고 일반적으로 TPM(250), PCA(275) 및 예를 들어 증명서를 유지하는 저장 매체(280)와 상호 작용한다.

성공적인 인증을 가정하면, provider.jsp 웹페이지(245)는 리디렉션 메시지(262)를 클라이언트/사용자 플랫폼(210)으로 전송한다. 리디렉션 메시지(262)는 서비스 메시지(264)로의 리디렉트를 통해 클라이언트/사용자 플랫폼(210)을 서비스 제공자(215)에서의 consumer_returnurl.jsp 페이지(265)로 리디렉트한다. consumer_returnurl.jsp 페이지(265)는 리디렉트가 연관된 OpenID 제공자(220)으로부터 오는 것을 확인하고 서비스 메시지(267)를 통해 클라이언트/사용자 플랫폼(210)로의 액세스를 허락한다.

이제, 도 3(a) 및 3(b)를 참조하면, 티켓 서버(305) 및 티켓 도전자(310) 사이의 신호 흐름이 도시된다. 티켓 서버(305) 및 PCA(315), 증명서 저장 매체(320) 및 TPM(325) 사이의 신호 흐름이 또한 도시된다.

티켓 서버(305)는 클라이언트 상의 서비스 애플리케이션으로서 실행된다. 티켓 서버는 미리 정의된 포트로 듣고 도전을 기다린다. (사용자가 OpenID 에서 사용되기를 원하는 아이덴티티 및 서비스 제공자에서 발행한 서비스 요청을 포함하는) 도전 메시지(327)의 수신시, 사용자는 확인응답(ACK) 메시지(329)를 이용하여 도전을 명시적으로 허용하도록 요구된다. 사용자는 도전을 거부할 옵션을 갖는다. 거부되면, OpenID 인증은 실패한다.

도전이 수락되면, 사용자가, 주어진 아이덴티티에 대응하는 AIK에 대한 비밀번호를 입력하고 티켓 서버(305)에서 SRK(storage root key) 비밀번호를 입력함으로써 TPM(325) 사용을 인증하도록 프롬프트된다. SRK는 TPM 보증 키를 액세스할 수 있는 TPM 명령 내에 포함된다. 티켓 서버(305)는 여기에 기재된 바와 같이 시스템 상태 정보 검색(345) 및 TC 티켓 생성(350)을 위해 필요한 증명서 저장 매체(320)로부터의 이 아이덴티티에 대한 이전의 획득된 AIK 증명서(일괄하여 335로 도시)를 검색하려고 시도한다. 증명서는 PCA(315) 등의 PCA를 갖는 이전의 AIK 증명서로부터 오고, 따라서 증명서 저장 매체(320) 등의 시스템 상의 로컬 증명서 저장 장치로부터 검색될 수 있거나, 증명서가 로컬 저장장치에서 이용가능하지 않으면(또는 로컬 저장장치 내의 AIK에 대한 증명서가 만료했거나 어떤 이유로 무효로 되면), AIK로 표시된 아이덴티티에 대한 새로운 증명서가 PCA(315)로부터 요청될 수 있다. 특히, 증명서 저장 매체(320) 내에서 증명서가 발견되지 않으면, 사용자는 AIK 증명 프로세스를 수행하여 AIK에 대한 증명서를 얻기 위하여 접속될 PCA(315)를 선택한다. 그러므로, 사용자는 TPM(325)의 정확한 소유자 비밀번호를 제공해야 한다. 이것은 TPM(325)의 소유자 이외의 사람에 의해 범죄자 아이덴티티의 생성을 방지한다. 이하에 도시된 바와 같이, 사용자 입력은 티켓 서버(305)에 의해 비밀번호가 평가되는 TPM(325)으로 전달된다.

도전 수락에 응답하여, 티켓 도전자(310)는 랜덤 넌스(nonce)(337)를 생성한다. 티켓 서버(305)는 넌스 메시지(339)를 통해 티켓 도전자(310)로부터 랜덤 넌스(337)를 수신한다. 넌스를 포함하는 시스템 구성을 기재하는 PCR 값의 AIK 서명 인용문(quote)(Q)은 TPM(325)으로부터 검색되어 345로서 일괄적으로 도시된 시스템의 상태에 대한 스테이트먼트(statement)를 생성한다.

티켓 서버(305)는 일괄적으로 350으로 도시된 TC 티켓을 생성한다. TC 티켓 생성(350)은 요청 및 아이덴티티를 서명하는데 사용될 수 있는 TPM(RSA 키 쌍)에 의한 새로운 키의 생성을 포함한다. 여기에 기재된 바와 같이, 이 새로운 키는 증명키 동작을 이용하여 AIK로 증명된다. 즉, TPM은 이 새롭게 생성된 키 쌍에 대한 기능 증명키를 이용하여 증명 스테이트먼트 및 바인딩(binding)을 생성한다. 여기서, 바인딩은 AIK에 대한 신뢰의 체인을 형성하고 PCA로부터 AIK 증명하는 것을 지칭한다. 새롭게 생성된 키가 성공적으로 증명되면, 이는 증명 서명키(CSK)라 한다. TPM 내에 다수의 CSK 및 다수의 AIK가 존재할 수 있다(또는 TPM에 의해 보호되는 안전한 저장장치 내에서 TPM에 의해 보장됨).

TC티켓(350)을 검증하기 위하여 필요한 정보는 TC티켓(350)에 포함되어 (도 3(a) 및 3(b)에서 티켓 도전자(310)로 표시된) 수신자는 쉽게 TC티켓(350)을 검증할 수 있다. 평문 측정 로그(ML) 및 인용문(Q)과 함께, TC티켓(350)을 포함하는 응답은 TCT, Q, ML 메시지(352)를 통해 티켓 도전자(310)로 전송된다. CH_RESPONSE 및 ACK 메시지(통합하여 351)는 수신자, 즉, 티켓 도전자(310)에게 다음 메시지가 TC티켓(350), 인용문 및 ML을 포함한다는 것을 알리는 프로토콜 시그널링 메시지이다. 프로세스 내의 이 단계에서, 도 3(a) 및 3(b)는 도 2의 TT검증자 스레드(TTVerifier Thread)(258)의 내부 동작을 나타낸다. OpenID 제공자가 동시에 다수의 요청을 처리할 수 있기 때문에, 모든 요청 클라이언트가 새롭고, 신선하고 고유한 도전을 획득하여 재전송 공격을 방지하도록 보장해야 한다.

메시지(355)를 통한 TC티켓(350)의 ACK시, 티켓 도전자(310)는 다음의 데이터를 가지고 있다: 재실행 방지 프로토콜로서 넌스(337)를 포함하는 TPM(325)으로부터의 AIK 서명 인용문; 평문 측정 파일; 서명 아이덴티티 스트링, 서명 요청 스트링, CSK의 공공 키 부분, CSK의 공공 키 부분 상의 AIK 서명 및 PCA(315)에 의해 발행된 AIK 증명서를 포함하는 TC티켓(350)을 갖는다. 클라이언트를 인증하기 위하여, 티켓 도전자(310)는 통합적으로 360로 도시된 다음의 정보: AIK 증명서의 승인(타임스탬프); AIK 증명서 상의 PCA 서명 검증; TC티켓(350) 내의 CSK 공공 키 해쉬(hash) 상의 AIK 서명 검증; TC티켓(350) 내의 서비스 요청 및 아이덴티티 상의 서명 검증; 측정 리스트 내의 엔트리의 승인; 및 실제(인용된) 플랫폼 구성 레지스터(PCR) 값이 측정 리스트(ML)에 대응한다는 것의 검증을 체크한다.

이 검증 프로세스 내의 임의의 항목이 실패하면, 클라이언트는 인증되지 않는다. 특정한 증명서 체인이 티켓 서버(305) 및 PCA(315), 즉, AIK 증명서 - 증명 CSK - 서명 요청에 의해 형성된다. 검증 상태 메시지(365)가 사용자에게 전송된다. 이것은 또한 예를 들어 도 2의 리디렉션 메시지(262)에 의해 도시된다. 이 경우, 메시지(262)는 사용자의 브라우저를 서비스 제공자 return_url로 리디렉트하거나 사용자는 서비스 제공자에서 인증된다. 상기 검증 중의 임의의 것이 실패하면(증명서 실패 또는 시스템 무결성 실패), 리디렉트는 사용자를 OpenID 제공자의 "인증 실패" 페이지로 사용자를 보낸다. 대안으로, 실패한 인증의 경우 실패 원인을 나타내면서 OpenID 제공자의 주문 제작 결과 페이지를 생성할 수 있다. 이것은 어떤 모듈 또는 소프트웨어가 무결성 체크를 실패했는지를 사용자에게 보여주고 사용자가 자신의 시스템을 신뢰할만한 상태로 되돌리도록 다음 단계를 제안하는 시스템에 영향력을 행사할 수 있다.

본 개시물의 관점에서, 예를 들어, PCA(275) 등의 PCA의 역할은 신뢰성있는 컴퓨팅을 채용하는 현재의 티켓 시스템에서 실행되는 것과 다르다. 예를 들어, PCA(275)는 특정한 서비스 제공자(215)에 의해 사용될 모든 부분 아이덴티티에 대하여 단 한번 인보크(invoke)될 필요가 있을 수 있다. 초기 등록에서, 클라이언트/사용자 플랫폼(210)은 그 플랫폼 아이덴티티를 필명의 부분 아이덴티티와 연관지을 수 있다. PCA(275)는 필명의 아이덴티티에 대한 증명서를 제공하고 플랫폼 아이덴티티에 대한 필명의 연관성을 저장한다. 이 데이터는 민감한 프라이버시이고 따라서 보호되어야 한다. 다른 예에서, PCA(275)의 위치 지정은 현재 티켓 시스템과 비교하여 추가적인 옵션을 허용한다. 여기에 기재된 신뢰성있는 모델 및 방법은 사용자의 선택 및 아이덴티티 제공자(220) 이외의 장소에서의 PCA(275)의 배치를 허용한다.

개시된 방법 및 아키텍쳐에서, 사용자는 AIK 증명서가 아이덴티티 제공자에 의해 수락된 임의의 외부 PCA를 선택하거나 아이덴티티 제공자에 의해 직접 또는 간접 제공된 PCA 기능을 사용할 수 있다. 후자의 예에서, PCA 또는 PCA 기능은 아이덴티티 제공자 내에 배치되어 복잡성을 감소시키고 웹 형태를 통해 아이덴티티 제공자와의 등록의 심리스 교체(seamless replacement)를 제공한다.

특정한 보안 아키텍쳐 때문에, 본 개시물은 아이덴티티 관련 정보의 암호화에 의존하는 신뢰성있는 컴퓨팅을 채용하는 아이덴티티 관리 시스템에 대한 특정한 처리를 완화시킨다. 신뢰성있는 OpenID에서, 예를 들어, AIK 증명서는 클라이언트에게 기지이며 보일 수 있고, 따라서, AIK 증명서는 프라이버시를 위협하는 숨은 정보는 포함할 수 없다.

다른 예에서, OpenID 구현은 사용자에게 OpenID 제공자 로그인 형태를 제공한다. 사용자는 자신의 증명서를 입력하고 OpenID 제공자는 클라이언트에게 쿠키를 발행한다. 이 쿠키는 모든 후속 OpenID 가능 서비스 액세스에 사용된다. 이것은 OpenID 프로토콜에 대한 몇가지 공격: (1) 클라이언트의 OpenID 제공자로의 로그인에 사용되는 사용자 증명서에 대한 직접적인 공격(아이덴티티 절도를 허용하면서 위조 OpenID 제공자 페이지를 갖는 피싱(phishing)이 많은 양의 사용자 증명서를 노출한다), 및 (2) 아이덴티티 절도를 유발하면서, 인증 후에 클라이언트의 컴퓨터로부터 쿠키의 재사용, 복사 및 절도를 포함하는 공격을 유발할 수 있다.

이들 공격은 본 개시물에 의해 완화된다. 모든 사용자 비밀 번호는 로컬이며 신뢰성있는 로컬 티켓 서버에만 제공되고, 증명서 피싱의 문제가 제거된다. 또한, 필명의 아이덴티티가 플랫폼, 예를 들어, TPM으로 구속되고, 따라서, 다른 장치로 복사될 수 없다.

또한, 쿠키는 클라이언트의 플랫폼 상에 저장되지 않는다. 이것은 로컬 재사용의 위협을 방지한다. 예를 들어, 다수의 사용자에 의해 공유되는 컴퓨터를 고려한다. 사람(A)가 자신의 OpenID 계정으로 로그인하고 서명하고 나가는 것을 잊으면, 사람(B)는 저장된 쿠키를 이용하여 A를 가장할 수 있다. 하나의 옵션은 현재 개시된 인증 방법을 심리스하게 웹 브라우저로 통합하는 것이다. 사용자가 개시된 방법을 이용하여 서비스를 액세스하기를 원할 때마다, 아이덴티티 제공자는 티켓 서버에 대한 새로운 도전을 생성한다. 사용자는 클라이언트에게 도전에 응답할 필요가 있는 로컬 AIK 비밀번호를 요청하는 신뢰성있는 티켓 서버 애플리케이션으로부터의 프롬프트만을 본다. 티켓 서버는 이 AIK 인증 비밀을 저장하지 않는다. 동일한 플랫폼에서 다른 사용자(B)가 서비스를 액세스하기를 원하면, 티켓 서버는 다시 아이덴티티 제공자에 의해 도전되고 B는 (모르는) A의 로컬 AIK 비밀번호를 제공해야 한다. 목표는 클라이언트의 플랫폼 상에 영구적으로 저장되지 않는 1회용 쿠키를 갖는 것이다. 대안으로, 장치에 대한 사용자 인증의 바인딩은 생체인식을 통해 가능할 수 있다. 통합된 장치에서, 생체 인식은 투명하고 동적으로 자주 행해져 항상 장치가 선량한 사용자에 의해 사용되도록 보증한다.

본 개시물은 발행된 쿠키에 대한 암화화를 사용하여 (아이덴티티 제공자의 관점으로부터 볼때 사용자 플랫폼인) 타겟 플랫폼 및 사용자가 암호화된 발행 쿠키를 해독하고 그 해독된 쿠키를 인증 토큰으로 사용하도록 한다. 아이덴티티 제공자는 비밀 키를 사용하여 쿠키를 암호화하고 암호화된 쿠키를 클라이언트 측 상의 티켓 서버로 전송하여 공공 CSK에 의해 보호된다. CSK는 임의의 양의 데이터의 벌크 암호화를 의미하지 않지만, 쿠키를 암호화하는데 사용되는 비밀 키를 암호화하는데 사용될 수 있다. 비밀 키는 대칭 또는 비대칭 키일 수 있다.

TPM을 사용하여, 쿠키는 필요할 때 해독될 수 있다. 해독은 사용자가 (로컬) CSK 비밀로 CSK 사용에 대해 인증하는 것을 필요로 한다. 티켓 서버는 필요하면 쿠키가 저장되고, 암호화되고, 해독되는 것을 보장한다.

또 다른 애플리케이션에서, 개시된 인증 및 액세스 방법은 결합된 인증 및 액세스 및 인가 방법에 사용될 수 있다. 주요 검색 엔진 회사는 최근 예시적인 API 인가 방법으로서 OAuth에 대한 지원을 발표하여 웹 서비스에 액세스할 때 심리스한 사용자 경험을 제공한다. 사용자는 서비스 제공자 제공 액세스 링크를 사용하여 웹 서비스에 액세스하고 동시에 예를 들어 OAuth를 통해 서비스 제공자 호스팅 서비스로의 웹 애플리케이션 액세스를 수락한다. OpenID는 중앙 저장 아이덴티티로 사용자를 인증하는데 사용될 수 있다. OAuth는 웹 서비스를 인가하여 달력, 문서 등의 사용자 데이터를 액세스하는데 사용된다. 단일 단계에서의 양 프로토콜의 결합은 사용자의 경험상 단일 서명을 개선하고 매쉬업(mash-up), 대쉬보드 등의 상이한 사용자 데이터로의 액세스를 필요로 하는 새로운 웹 서비스를 허용한다.

사용자의 TPM이 예를 들어, OpenID 도전으로서, 아이덴티티 제공자를 서명하도록 하는 대신에, TPM은 예를 들어 웹 애플리케이션의 요청을 통해 아이덴티티 제공자에 의해 제시된 바와 같이 결합된 OpenID/OAuth 도전을 서명한다. 사용자 식별 및 인증 뿐만 아니라 데이터로의 액세스의 수락은 TPM에 의해 안전하게 서명된다. 여기에 개시된 바와 같이, 사용자에 대한 보안은 (1) 하드웨어 TPM으로 로그인 및 인가를 바인딩하고 (2) OpenID/OAuth 제공자에 의한 플랫폼 무결성 검증을 제공하여 클라이인트 상에서 실행되는 악의적인 소프트웨어에 의한 민감한 데이터의 절도를 방지함으로써 개선된다. 무결성 검증은 또한 웹 애플리케이션에 대한 안전 레벨을 증가시킨다. 증명된 무결성 검증 상태의 클라이언트만이 웹 서비스로 액세스할 수 있다. 이것은 보안 및 프라이버시 중요 애플리케이션에 대한 새로운 웹 서비스의 확립을 허용한다. 인가 제공자, 예를 들어, OAuth, 토큰 액세스가 고유하게 식별될 수 있는 TPM에 의해 서명되므로, 기재된 방법은 비거절(non-repudiation)을 제공한다. 이것은 웹 애플리케이션의 서비스 제공자에 의해 구현될 수 있는 과금 프로세스를 가능하게 한다. 서명은 사용자가 웹 서비스를 요청하고 액세스했다는 것을 웹 애플리케이션 제공자가 증명하도록 한다.

TPM 기반 사용자 인증은 플랫폼 아이덴티티 및 아이덴티티 제공자 간의 링크를 허용한다. 아이덴티티 제공자는 주어진 플랫폼에 대한 등록 아이덴티티의 데이터베이스를 유지하도록 요구된다. 등록 아이덴티티 중의 하나를 이용하여 다른 플랫폼으로부터의 로그인 시도가 검출될 때마다, 아이덴티티 제공자는 (1) 거부 인증을 할 수 있거나/해야 하거나 (2) 정당한 소유자에게 아이덴티티를 통지할 수 있다. 아이덴티티 제공자는 주어진 플랫폼 증명서로 정당한 사용자를 공격자로부터 쉽게 구별할 수 있다.

또 다른 예에서, 방법은 입증 메카니즘을 포함할 수 있다. 아이덴티티 제공자는 사용자에게 사용자 플랫폼의 시스템 상태에 대한 정보를 제공할 것을 요구할 수 있다. 시스템이 신뢰할만한 상태에 있으면, 액세스가 가능하다. 이것은 "신뢰할만한" 시스템만이 웹 서비스를 액세스할 수 있기 때문에 웹 애플리케이션에 대한 보안에 영향력을 미친다.

또 다른 예에서, 입력 아이덴티티 인증 요청에 대하여 사용자 측 상의 서비스 애플리케이션이 귀를 기울여서 그를 TPM로 전송하는 대신, 심리스한 브라우저 통합이 사용될 수 있다. 이것은 적용가능한 기능을 구현하는 브라우저 익스텐션(browser extension)을 이용하여 달성될 수 있다. 아이덴티티 제공자는 서명 페이지의 HTML 코드 내의 도전을 발행한다. 브라우저 익스텐션은 이 정보를 읽고 필요한 데이터를 TPM으로 전달할 수 있다. TPM은 서명된 티켓을 생성하고 그 생성된 티켓을 브라우저 익스텐션으로 돌려보낸다. 익스텐션은 서명된 티켓을 포함하는 아이덴티티 제공자에 대한 정확한 HTTPS 응답을 발행할 수 있다. 이 예에서, 도 3(a) 및 3(b)의 흐름은 별개의 익스텐션 대신에 심리스한 통합 브라우저 익스텐션에 의해 처리될 수 있다. 이 솔루션은 더 큰 휴대성 및 더 나은 사용자 경험을 허용한다.

일반적으로, 사용자 플랫폼으로부터의 신뢰성있는 인증 및 액세스 방법은 소정의 아이덴티티를 이용하여 서비스 제공자에 로그인하는 것을 포함하고, 사용자 플랫폼은 서비스 제공자에 의해 서비스 제공자에 의해 소정의 아이덴티티에 의해 지시되는 아이덴티티 제공자로 리디렉트된다. 방법은 또한 아이덴티티 제공자로부터 인증 도전을 수신하는 단계 및 인증 도전에 응답하여 사용자 플랫폼이 인증 도전을 수락한 조건에서 신뢰성있는 플랫폼 모듈(TPM)에 기초하여 티켓을 송신하는 단계를 더 포함한다. 방법은 아이덴티티 제공자로부터 성공적인 티켓 검증을 수신하면 서비스 제공자를 액세스하는 단계를 더 포함한다. 소정의 아이덴티티는 유니버설 리소스 식별자로 표시된다. 방법은 사용자 플랫폼 및 티켓을 승인하는 티켓을 생성하는 단계를 포함한다. 인증 도전은 적어도 소정의 아이덴티티 및 서비스 요청의 타입을 포함한다. 방법은 소정의 아이덴티티 및 서비스 요청을 서명하는 증명 서명 키를 생성하는 단계를 포함한다.

방법은 소정의 아이덴티티에 대응하는 입증 아이덴티티 키(AIK)에 대한 비밀번호 및 TPM 사용을 인증하기 위한 스토리지 루트 키 비밀번호를 제공하는 단계를 포함한다. 또한 방법은 입증 아이덴티티 키(AIK)에 대응하는 증명서를 획득하는 단계를 포함한다. 방법은 이전에 획득된 증명서가 이용가능하지 않다는 조건에서 증명서를 생성하는 단계를 더 포함한다. 방법은 긍정적인 도전 확인 응답(ACK)에 응답하여 넌스를 수신하는 단계 및 TPM으로부터 입증 아이덴티티 키(AIK) 서명 인용문을 생성하는 단계를 더 포함하고, 여기서 AIK 서명 인용문은 넌스를 포함한다. 티켓은 증명 서명 키(CSK) 서명 소정 아이덴티티, CSK 서명 요청, CSK 공공 키 및 사설 증명 기관(PCA) 발행 입증 아이덴티티 키(AIK) 증명서를 더 포함한다.

방법은 인증 도전에 응답하여 사용자 플랫폼이 인증 도전을 수락했다는 조건에서 TPM으로부터의 플랫폼 구성 레지스터(PCR)의 입증 아이덴티티 키(AIK) 서명 인용문 및 측정 로그를 전송하는 단계를 더 포함한다. 성공적인 티켓 검증은 AIK 증명서의 타임스탬프의 승인, AIK 증명서 상의 PCA 서명의 검증, CSK 공공 키 상의 AIK 서명의 검증, CSK 서명 소정 아이덴티티의 검증, CSK 서명 요청의 검증, 측정 로그의 승인, 인용문의 검증을 포함한다.

방법은 후속 서비스 제공자 액세스에 대한 증명 서명 키에 의해 보호되는 암호화된 쿠키를 수신하는 단계를 더 포함한다. 인증 도전은 인가 도전(authorization challenge)을 포함한다. 방법은 또한 입증 도전을 더 포함한다.

신뢰성있는 인증 및 액세스를 지원하는 장치는 소정의 아이덴티티를 사용하여 서비스 제공자에 액세스하도록 구성되는 인터페이스 모듈을 포함하고, 장치는 서비스 제공자에 의해 소정의 아이덴티티에 의해 지시되는 아이덴티티 제공자로 리디렉트된다. 장치는 또한 인증 도전이 수락된다는 조건에서 신뢰성있는 플랫폼 모듈(TPM)에 기초하여 티켓을 송신함으로써 인증 도전에 응답하도록 구성된 티켓 서버를 포함한다. 인터페이스 모듈은 또한 아이덴티티 제공자로부터 성공적인 티켓 검증을 수신하고 서비스 제공자 상의 서비스를 액세스하도록 구성된다. 티켓 서버는 또한 증명 서명 키(CSK) 서명 소정 아이덴티티, CSK 서명 요청, CSK 공공 키 및 사설 증명 기관(PCA) 발행 입증 아이덴티티 키(AIK) 증명서를 포함하는 티켓을 생성하도록 구성된다. 티켓 서버는 또한 TPM으로부터 입증 아이덴티티 키(AIK) 서명 인용문 및 및 측정 로그를 얻도록 구성된다. 티켓 서버는, 또한 넌스를 수신하고 TPM으로부터 입증 아이덴티티 키(AIK) 서명 인용문을 생성하도록 구성되고, AIK 서명 인용문은 넌스를 포함한다.

여기에 개시된 바와 같이, 사용자 클라이언트/플랫폼은 예를 들어 무선 통신 시스템에서 사용될 수 있는 WTRU 또는 기지국일 수 있다. 일 예에서, 다른 무선 통신 시스템에 적용가능하지만, 도 4는 E-UTRAN(Evolved-Universal Terrestrial Radio Access Network)(405)를포함하는 LTE(Long Term Evolution) 무선 통신 시스템/액세스 네트워크(400)를 나타낸다. E-UTRAN(405)는 WTRU(410) 및 몇개의 eNB(420)를 포함한다. WTRU(410)는 eNB(420)와 통신한다. eNB(420)는 X2 인터페이스를 통해 서로 인터페이스한다. eNB(420)의 각각은 S1 인터페이스를 통해 MME(Mobility Management Entity)/S-GW(Serving GateWay)(430)와 인터페이스한다. 하나의 WTRU(410) 및 3개의 eNB(420)가 도 4에 도시되지만, 무선 및 유선 장치의 임의의 조합이 무선 통신 시스템 액세스 네트워크(400)에 포함될 수 있음은 자명하다.

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

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

일반적인 eNB 내의 컴포넌트에 더하여, eNB(420)는 선택적 링크 메모리(515)를 갖는 프로세서(517), 트랜시버(519) 및 안테나(521)를 포함한다. 프로세서(517)는 여기에 개시된 방법을 수행하도록 구성된다. 트랜시버(519)는 프로세서(517) 및 안테나(521)와 통신하여 무선 통신 송수신이 가능하다. eNB(420)는 선택적 링크 메모리(534)를 갖는 프로세서(533)를 포함하는 MME/S-GW(430)에 접속된다.

실시예

1. 사용자 플랫폼으로부터의 신뢰성있는 인증 및 액세스 방법으로서, 소정의 아이덴티티를 이용하여 서비스 제공자로 로그인하는 단계를 포함하고, 상기 사용자 플랫폼은 상기 서비스 제공자에 의해 상기 소정의 아이덴티티에 의해 지시된 아이덴티티 제공자로 리디렉트(redirect)되는 방법.

2. 실시예 1에 있어서, 상기 아이덴티티 제공자로부터 인증 도전(authentication challenge)을 수신하는 단계를 포함하는 방법.

3. 선행하는 실시예 중 어느 하나에 있어서, 상기 인증 도전에 응답하여, 상기 사용자 플랫폼이 상기 인증 도전을 수락하였다는 조건에서 신뢰성있는 플랫폼 모듈(trusted platform module; TPM)에 기초하여 티켓을 송신하는 단계를 포함하는 방법.

4. 선행하는 실시예 중 어느 하나에 있어서, 상기 아이덴티티 제공자로부터 성공적인 티켓 검증을 수신하면 상기 서비스 제공자를 액세스하는 단계를 포함하는 방법.

5. 선행하는 실시예 중 어느 하나에 있어서, 상기 소정의 아이덴티티는 유니버설 자원 식별자로 표시되는 방법.

6. 선행하는 실시예 중 어느 하나에 있어서, 상기 사용자 플랫폼 및 상기 티켓을 승인하는 티켓을 생성하는 단계를 포함하는 방법.

7. 선행하는 실시예 중 어느 하나에 있어서, 상기 인증 도전은 적어도 상기 소정의 아이덴티티 및 서비스 요청의 타입을 포함하는 방법.

8. 선행하는 실시예 중 어느 하나에 있어서, 상기 소정의 아이덴티티 및 상기 서비스 요청을 서명하는 증명 서명 키를 생성하는 단계를 포함하는 방법.

9. 선행하는 실시예 중 어느 하나에 있어서, 상기 소정의 아이덴티티에 대응하는 입증 아이덴티티 키(attestation identify key; AIK)에 대한 비밀번호 및 TPM 사용을 인증하는 스토리지 루트 키 비밀번호를 제공하는 단계를 포함하는 방법.

10. 선행하는 실시예 중 어느 하나에 있어서, 입증 아이덴티티 키(AIK)에 대응하는 증명서를 얻는 단계를 포함하는 방법.

11. 선행하는 실시예 중 어느 하나에 있어서, 이전에 획득된 증명서가 이용가능하지 않다는 조건에서 증명서를 생성하는 단계를 포함하는 방법.

12. 선행하는 실시예 중 어느 하나에 있어서, 긍정적인 도전 확인 응답(ACK)에 응답하여 넌스(nonce)를 수신하는 단계를 포함하는 방법.

13. 선행하는 실시예 중 어느 하나에 있어서, 상기 TPM으로부터 입증 아이덴티티 키(AIK) 서명 인용문(quote)을 생성하는 단계를 포함하고, 상기 AIK 서명 인용문은 상기 넌스를 포함하는 방법.

14. 선행하는 실시예 중 어느 하나에 있어서, 상기 티켓은 증명 서명 키(CSK) 서명 소정 아이덴티티, CSK 서명 요청, CSK 공공 키, 및 사설 증명 기관(PCA) 발행 입증 아이덴티티 키(AIK) 증명서를 더 포함하는 방법.

15. 선행하는 실시예 중 어느 하나에 있어서, 상기 인증 도전에 응답하여, 상기 사용자 플랫폼이 상기 인증 도전을 수락했다는 조건에서 상기 TPM으로부터의 플랫폼 구성 레지스터(PCR)의 입증 아이덴티티 키(AIK) 서명 인용문 및 측정 로그를 송신하는 단계를 포함하는 방법.

16. 선행하는 실시예 중 어느 하나에 있어서, 상기 성공적인 티켓 검증은 상기 AIK 증명서의 타임스탬프의 승인, 상기 AIK 증명서 상의 PCA 서명의 검증, 상기 CSK 공공 키 상의 AIK 서명의 검증, 상기 CSK 서명 소정 아이덴티티의 검증, CSK 서명 요청의 검증, 측정 로그의 승인 및 상기 인용문의 검증을 포함하는 방법.

17. 선행하는 실시예 중 어느 하나에 있어서, 후속의 서비스 제공자 액세스를 위한 증명 서명 키에 의해 보호되는 암호화된 쿠키를 수신하는 단계를 포함하는 방법.

18. 선행하는 실시예 중 어느 하나에 있어서, 상기 인증 도전은 인가 도전(authorization challenge)을 포함하는 방법.

19. 선행하는 실시예 중 어느 하나에 있어서, 입증 도전을 포함하는 방법.

20. 신뢰성있는 인증 및 액세스를 지원하는 장치로서, 소정의 아이덴티티를 이용하여 서비스 제공자를 액세스하도록 구성되는 인터페이스 모듈을 포함하고, 상기 장치는 상기 서비스 제공자에 의해, 상기 소정의 아이덴티티에 의해 지시되는 아이덴티티 제공자로 리디렉트되는 장치.

21. 실시예 20에 있어서, 인증 도전이 수락된 조건에서 신뢰성있는 플랫폼 모듈(TPM)에 기초하여 티켓을 송신함으로써 인증 도전에 응답하도록 구성되는 티켓 서버를 포함하는 장치.

22. 실시예 20 또는 21 중 어느 하나에 있어서, 상기 아이덴티티 제공자로부터의 성공적인 티켓 검증을 수신하고 상기 서비스 제공자 상의 서비스를 액세스하도록 구성되는 상기 인터페이스 모듈을 포함하는 장치.

23. 실시예 20 내지 22 중 어느 하나에 있어서, 상기 티켓 서버는 또한 증명 서명 키(CSK) 서명 소정 아이덴티티, CSK 서명 요청, CSK 공공 키, 및 사설 증명 기관(PCA) 발행 입증 아이덴티티 키(AIK) 증명서를 포함하는 티켓을 생성하도록 구성되는 장치.

24. 실시예 20 내지 23 중 어느 하나에 있어서, 상기 티켓 서버는 또한 상기 TPM으로부터의 입증 아이덴티티 키(AIK) 서명 인용문 및 측정 로그를 얻도록 구성되는 장치.

25. 실시예 20 내지 24 중 어느 하나에 있어서, 상기 티켓 서버는 또한 넌스(nonce)를 수신하고 상기 TPM으로부터 입증 아이덴티티 키(AIK) 서명 인용문(quote)를 생성하도록 구성되고, 상기 AIK 서명 인용문은 상기 넌스를 포함하는 장치.

특징 및 소자는 특정한 조합으로 위에서 기재하였지만, 각 특징 또는 소자는 다른 특징없이 단독으로 또는 다른 특징 또는 소자를 가지고 또는 없이 다양한 조합으로 사용될 수 있다. 여기에 제공된 방법 및 흐름은 범용 컴퓨터 또는 프로세서에 의해 실행될 컴퓨터 판독가능 저장 매체에 포함된 컴퓨터 프로그램, 소프트웨어 또는 펌웨어로 구현될 수 있다. 컴퓨터 판독가능 저장 매체의 예는 리드 온리 메모리(ROM), 랜덤 액세스 메모리(RAM), 레지스터(register), 캐시 메모리, 반도체 메모리 장치, 내부 하드 디스크 및 제거가능 드라이브 등의 자기 매체, 광자기 매체, 및 CD-ROM 디스크 및 DVD 등의 광 매체를 포함한다.

적절한 프로세서는, 예로서, 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서, DSP 코어와 연관된 하나 이상의 마이크로프로세서, 컨트롤러, 마이크로컨트롤러, ASIC(Application Specific Integrated Circuit), 필드 프로그래머블 게이트 어레이(FPGA) 회로, 임의의 다른 타입의 집적 회로(IC) 및/또는 상태 머신을 포함한다.

사용자 플랫폼은 WTRU를 포함하는 다수의 플랫폼 중의 임의의 것일 수 있다. 소프트웨어와 연관된 프로세서는 무선 송수신 유닛(WTRU), 사용자 장치(UE), 단말, 기지국, 라디오 네트워크 컨트롤러(RNC) 또는 임의의 호스트 컴퓨터에서 사용되는 무선 주파수 트랜시버를 구현하는데 사용될 수 있다. WTRU는 카메라, 비디오 카메라 모듈, 비디오폰, 스피커폰, 진동 장치, 스피커, 마이크로폰, 텔레비전 트랜시버, 핸즈프리 헤드셋, 키보드, 블루투스 모듈, 주파수 변조(FM) 라디오 유닛, 액정 디스플레이(LCD) 디스플레이 유닛, 유기 발광 다이오드(OLED) 디스플레이 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저, 및/또는 임의의 무선 로컬 에어리어 네트워크(WLAN) 또는 UWB(Ultra Wide Band) 모듈 등의 하드웨어 및/또는 소프트웨어에서 구현되는 모듈과 결합하여 사용될 수 있다.

110: 클라이언트/사용자 플랫폼
115: TPM
120: 아이덴티티 제공자
130: PCA
140: 서비스 제공자
150: 티켓 서버
160: 증명서

Claims

사용자 플랫폼으로부터의 신뢰성있는 인증(authentication) 및 액세스 방법에 있어서,
상기 사용자 플랫폼이 상기 사용자 플랫폼의 입증 아이덴티티 키(attestation identity key; AIK)와 관련된 소정의(predetermined) 아이덴티티를 이용하여 서비스 제공자로 로그인하는 단계로서, 상기 사용자 플랫폼은 상기 서비스 제공자에 의해, 상기 소정의 아이덴티티에 의해 표시된 아이덴티티 제공자로 리디렉트(redirect)되는 것인, 상기 사용자 플랫폼의 로그인 단계;
상기 사용자 플랫폼이 상기 아이덴티티 제공자로부터 인증 도전(authentication challenge)을 수신하는 단계;
상기 사용자 플랫폼이 증명 기관(certification authority)에 의한 상기 AIK 의 증명을 나타내는 증명서를, 상기 사용자 플랫폼 상에 존재하는 신뢰성있는 모듈을 통해, 획득하는 단계;
상기 사용자 플랫폼이 상기 아이덴티티 제공자에서의 사용자 플랫폼의 인증을 위한 티켓 - 상기 티켓은 상기 증명 기관에 의한 상기 AIK의 증명을 나타내는 증명서를 포함함 - 을 상기 신뢰성있는 모듈에서 생성하는 단계;
상기 신뢰성있는 모듈로부터 상기 사용자 플랫폼의 구성을 나타내는 하나 이상의 플랫폼 구성 레지스터(platfrom configuration register; PCR) 값의 서명 인용문(signed quote) - 상기 서명 인용문은 상기 AIK에 의해 서명됨 - 을 검색(retrieving)하는 단계;
상기 인증 도전에 응답하여, 상기 사용자 플랫폼이 상기 티켓 및 상기 서명 인용문을 상기 사용자 플랫폼의 인증을 위해 상기 아이덴티티 제공자에게 송신하는 단계; 및
상기 사용자 플랫폼이 상기 티켓 및 상기 서명 인용문의 성공적인 검증(verification)을 수신시에 상기 서비스 제공자를 액세스하는 단계로서, 상기 사용자 플랫폼의 사용자는 정당하고 상기 사용자 플랫폼은 신뢰할 수 있는 것임을 보장하는, 상기 액세스 단계
를 포함하는 신뢰성있는 인증 및 액세스 방법.
제1항에 있어서, 상기 소정의 아이덴티티는 유니버설 자원 식별자(identifier)로 표시되는 것인, 신뢰성있는 인증 및 액세스 방법.
제1항에 있어서, 상기 티켓은 상기 사용자 플랫폼 및 상기 티켓의 정확성(authenticity)를 승인하는 데이터를 더 포함하는 것인, 신뢰성있는 인증 및 액세스 방법.
제1항에 있어서, 상기 인증 도전은 적어도 상기 소정의 아이덴티티 및 서비스 요청의 타입을 포함하는 것인, 신뢰성있는 인증 및 액세스 방법.
제4항에 있어서, 상기 사용자 플랫폼이 상기 소정의 아이덴티티 및 상기 서비스 요청을 서명하기 위한 증명된 서명 키를 생성하는 단계를 더 포함하는 신뢰성있는 인증 및 액세스 방법.
제1항에 있어서, 상기 사용자 플랫폼이 상기 소정의 아이덴티티에 대응하는 상기 AIK에 대한 비밀번호 및 상기 신뢰성있는 모듈의 사용을 인증하는 스토리지 루트 키 비밀번호를 수신하는 단계를 더 포함하는 신뢰성있는 인증 및 액세스 방법.
제1항에 있어서, 상기 증명서는 상기 AIK에 대응하는 것인, 신뢰성있는 인증 및 액세스 방법.
제7항에 있어서, 상기 사용자 플랫폼은 이전에 획득된 증명서가 이용가능하지 않다는 조건에서 상기 증명서를 획득하는 것인, 신뢰성있는 인증 및 액세스 방법.
제1항에 있어서,
상기 사용자 플랫폼이 상기 아이덴티티 제공자로부터 수신된 인증 도전에 응답하여 긍정적인 도전 확인 응답을 보내는 단계;
상기 사용자 플랫폼으로부터 상기 아이덴티티 제공자로 보내진 상기 긍정적인 도전 확인 응답에 응답하여 상기 사용자 플랫폼이 넌스(nonce)를 수신하는 단계; 및
상기 사용자 플랫폼이 상기 서명 인용문- 상기 서명 인용문은 상기 AIK에 의해 서명되고 상기 넌스를 포함함 - 을 생성하는 단계를 더 포함하는 신뢰성있는 인증 및 액세스 방법.
제1항에 있어서, 상기 티켓은 증명된 서명 키(certified signing key; CSK) 서명된 소정 아이덴티티, CSK 서명된 요청, CSK 공공 키, 및 사설 증명 기관(privacy certification authority; PCA) 발행 AIK 증명서를 포함하는 증명서를 더 포함하는 것인, 신뢰성있는 인증 및 액세스 방법.
제10항에 있어서, 상기 인증 도전에 응답하여, 상기 사용자 플랫폼이 상기 인증 도전을 수락했다는 조건에서, 상기 사용자 플랫폼이 상기 신뢰성있는 모듈로부터의 상기 PCR 값의 상기 서명 인용문 및 측정 로그를 송신하는 단계를 더 포함하는 신뢰성있는 인증 및 액세스 방법.
제11항에 있어서, 상기 성공적인 티켓 검증은, 상기 아이덴티티 제공자가 상기 증명서의 타임스탬프를 승인(validate)하였고, 상기 증명서 상의 증명 기관의 서명을 검증(verify)하였고, 상기 CSK 공공 키 상의 AIK 서명을 검증하였고, 상기 CSK 서명된 소정 아이덴티티를 검증하였고, 상기 CSK 서명된 요청을 검증하였고, 상기 측정 로그를 승인하였으며, 상기 인용문을 검증하였음을 나타내는 것인, 신뢰성있는 인증 및 액세스 방법.
제1항에 있어서, 상기 사용자 플랫폼이, 후속의 서비스 제공자 액세스를 위한 증명된 서명 키에 의해 보호되는, 암호화된 쿠키를 수신하는 단계를 더 포함하는 신뢰성있는 인증 및 액세스 방법.
제1항에 있어서, 상기 인증 도전은 인가 도전(authorization challenge)을 포함하는 것인, 신뢰성있는 인증 및 액세스 방법.
제1항에 있어서, 상기 사용자 플랫폼이 입증 도전(attestation challenge)을 수신하는 단계를 더 포함하는 신뢰성있는 인증 및 액세스 방법.
제1항에 있어서, 상기 사용자 플랫폼이 상기 AIK를 이용하여 상기 증명서를 획득하는 단계를 더 포함하는 신뢰성있는 인증 및 액세스 방법.
제1항에 있어서, 상기 티켓은 상기 사용자 플랫폼 상에 존재하는 상기 신뢰성있는 모듈에 의해 서명되는 것인, 신뢰성있는 인증 및 액세스 방법.
신뢰성있는 인증 및 액세스를 지원하는 사용자 플랫폼에 있어서,
상기 사용자 플랫폼의 입증 아이덴티티 키(attestation identity key; AIK)와 관련된 소정의 아이덴티티를 이용하여 서비스 제공자를 액세스하도록 구성된 인터페이스 모듈로서, 상기 사용자 플랫폼은 상기 서비스 제공자에 의해, 상기 소정의 아이덴티티에 의해 표시된 아이덴티티 제공자로 리디렉트되는 것인, 상기 인터페이스 모듈;
증명 기관에 의한 상기 AIK의 증명을 나타내는 증명서를 획득하도록 구성된 신뢰성있는 모듈로서, 상기 사용자 플랫폼은 상기 증명서를 포함하는 티켓을 생성하도록 구성되는 것인, 상기 신뢰성있는 모듈;
상기 신뢰성있는 모듈로부터 상기 사용자 플랫폼의 구성을 나타내는 하나 이상의 플랫폼 구성 레지스터(platfrom configuration register; PCR) 값의 서명 인용문(signed quote) - 상기 서명 인용문은 상기 AIK에 의해 서명됨 - 을 검색(retrieving)하고 상기 티켓 및 상기 서명 인용문을 송신함으로써, 상기 아이덴티티 제공자로부터 수신된 인증 도전에 응답하도록 구성된 티켓 서버
를 포함하고,
상기 인터페이스 모듈은 또한, 상기 서비스 제공자 상의 서비스를 액세스하기 위해 상기 티켓 및 상기 서명 인용문의 성공적인 검증을 수신하도록 구성되어, 상기 사용자 플랫폼의 사용자는 정당하고 상기 사용자 플랫폼은 신뢰할 수 있는 것임을 보장하는, 사용자 플랫폼.
제18항에 있어서, 상기 티켓은 증명된 서명 키(CSK) 서명된 소정 아이덴티티, CSK 서명된 요청, CSK 공공 키, 및 사설 증명 기관(PCA) 발행 AIK 증명서를 포함하는 증명서를 포함하는 것인, 사용자 플랫폼.
제19항에 있어서, 상기 티켓 서버는 또한, 상기 신뢰성있는 모듈로부터 상기 서명 인용문 및 측정 로그를 획득하도록 구성되는 것인, 사용자 플랫폼.
제18항에 있어서, 상기 티켓 서버는 또한, 넌스(nonce)를 수신하고 상기 신뢰성있는 모듈로부터 상기 서명 인용문을 생성하도록 구성되고, 상기 서명 인용문은 상기 넌스를 포함하는 것인, 사용자 플랫폼.