KR101731132B1 - 일회 왕복 키 인증 - Google Patents

일회 왕복 키 인증 Download PDF

Info

Publication number
KR101731132B1
KR101731132B1 KR1020127010781A KR20127010781A KR101731132B1 KR 101731132 B1 KR101731132 B1 KR 101731132B1 KR 1020127010781 A KR1020127010781 A KR 1020127010781A KR 20127010781 A KR20127010781 A KR 20127010781A KR 101731132 B1 KR101731132 B1 KR 101731132B1
Authority
KR
South Korea
Prior art keywords
key
tpm
certificate
signature
client
Prior art date
Application number
KR1020127010781A
Other languages
English (en)
Other versions
KR20120101363A (ko
Inventor
스테판 톰
스코트 디 앤더슨
에릭 엘 홀트
Original Assignee
마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 filed Critical 마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Publication of KR20120101363A publication Critical patent/KR20120101363A/ko
Application granted granted Critical
Publication of KR101731132B1 publication Critical patent/KR101731132B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
    • H04L2209/127—Trusted platform modules [TPM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

신뢰 플랫폼 모듈(TPM)이 이동불가라고 증명했던 키의 인증이 인증 기관(CA)과 인증을 요청한 클라이언트 사이에서 한 번의 왕복으로 수행될 수 있다. 클라이언트는 인증 요청을 생성하며, 그런 다음 인증 요청을 하기로 된 증명 아이덴티티 키(AIK)를 TPM이 생성하게 한다. 그러면, 클라이언트는 TPM에 이동불가의 증명으로서 새 키를 서명하도록 요청한다. 클라이언트는 그런 다음 이동불가의 증명과 함께 CA로 인증 요청을 보낸다. CA는 인증 요청 및 이동 불가의 증명을 검사한다. 그러나, CA는 증명이 신뢰 TPM에 의해 이뤄졌는지 여부를 알지 못하므로, 키를 인증하지만 인증서 안에 신뢰 TPM의 배서를 이용해서만 해독될 수 있는 암호화된 서명을 포함한다.

Description

일회 왕복 키 인증{KEY CERTIFICATION IN ONE ROUND TRIP}
암호 키의 사용은 신뢰를 수반한다. A가 B의 키로 데이터를 암호화할 때, A는 B만이 데이터를 해독할 수 있을 것이라고 기대한다. 또한 A가 B의 키로 생성된 서명을 검증할 때, A는 유효 서명의 존재가 B가 서명이 산출되었던 데이터에 실제로 서명했다는 것을 의미하는 것으로 기대한다. 따라서, A가 B의 키를 사용할 때, 어떻게 A가 B의 키가 정말 B에 속하는지를 확신할 수 있으며 어떻게 A가 B의 키가 손상되지 않았다는 것을 확신할 수 있는지를 A가 알고 싶어하는 것은 타당하다.
키에 대한 신뢰는 일반적으로 인증을 통해 확립된다. 개체가 키를 생성할 때, 그 개체는 인증할 기관에 키를 제출한다. 그 기관은 키와 그 소유자가 기관의 인증 규격을 충족하는지 여부를 판단한다. 충족할 경우, 기관은 기관이 서명한 키를 포함하는 키의 인증서를 발급한다. 기관은 그들이 봉사하는 커뮤니티에 알려지고, 그 커뮤니티가 다른 개체들의 키들을 인증하는데 있어 신뢰하는 개체들이다. 인지된 기관이 어떤 키를 인증하면, 그 기관을 신뢰하는 커뮤니티는 인증된 키를 신뢰할 것이다. 예를 들어 브라우저들은 업데이트된 기관들의 리스트들을 주기적으로 수신하므로, 브라우저들은 그 리스트 상의 기관들에 의해 발급된 인증서들을 신뢰할 것이다. 어떤 조직(가령, 회사)은 그 조직 내 장치들에 의해 인지되고 신뢰되는 인증 기관을 가질 수 있다.
신뢰 플랫폼 모듈(TPM(trusted platform module))은 다양한 형식의 장치 보안을 제공하는데 사용될 수 있는 하드웨어의 일부이다. TPM이 할 수 있는 한 가지 일은 키를 둘러싼 하드웨어 보안을 유지하며, 그에 따라 그 키가 오용되지 않을 높은 정도의 확신을 제공할 수 있다는 것이다. 어떤 경우, 인증 기관은 특정 TPM에 구속된 키만을 인증하려고 할 것인데, 이는 이러한 구속(결합)이 그 키가 이 특정 TPM을 포함하는 장치 상에서만 사용될 것이라는 것을 보장하기 때문이다. 따라서, 그러한 키를 인증하기 위해 인증 기관은 키가 실제로 특정 장치 상의 TPM에만 구속되어 있으며 다른 장치들로 이동될 수 없다는 것을 검증해야 한다. 보통, 그러한 키를 인증하는 프로세스는 인증 기관 및 키가 인증되게 요청하는 클라이언트 사이에 수 차례의 왕복 교류들을 수반한다. 클라이언트가 클라이언트의 TMP에 의해 보장된 새로운 이동불가(non-migratable) 키를 인증하고 싶어할 때, 클라이언트는 TPM이 그 새 키에 대해 증명 아이덴티티 키(AIK(Attestation Identity Key))라 불리는 키를 생성하라고 요청한다. 그런 다음 클라이언트는 인증 기관에 AIK를 인증하도록 요청하며, 인증 기관은 AIK가 실제로 클라이언트 장치 상의 TPM에 의해 생성되었다는 것을 검증한 뒤에 인증을 행한다. 그리고 나서 클라이언트는 TPM에 AIK를 가지고 새 키를 서명하도록 요청하며, TPM은 키가 이동불가인 경우에만 그렇게 서명할 것이다. 그런 다음 클라이언트는 새 키 및 AIK 생성 서명을 인증 기관으로 제출한다. 인증 기관은 TPM을 신뢰하며 AIK가 TPM에 속하는 것이라고 인증하였다. 따라서, 인증 기관은 새 키가 TPM이 AIK를 가지고 그것을 서명했다는 데 기반하여 이동불가한 것이라고 신뢰할 것이며, 그에 따라 인증 기관은 새 키에 대한 인증서를 발급할 것이다.
그러나 이 프로세스의 문제는 그것이 클라이언트 및 인증 기관 사이의 여러 번의 왕복(라운드 트립)을 수반했다는 것이다: 한 번의 트립은 AIK를 인증하기 위한 것이고, 다른 하나는 클라이언트가 인증하고자 하는 새 키를 인증하기 위한 것이다.
이동 불가 키는 인증 기관 및 키를 요청하는 클라이언트 사이에 한 번의 왕복으로 인증될 수 있다. TPM을 가진 장치 상에서, 클라이언트는 TPM에게 새 이동 불가 키(가령, RSA 키 쌍)를 생성하도록 요청한다. 그러면 TPM이 그 키를 생성하고 새 키의 공개 부분을 클라이언트에게 제공한다. 그런 다음 클라이언트는 새 키에 대한 인증 요청을 생성하고, TPM에게 인증 요청의 요약에 결합된 증명 아이덴티티 키(AIK(Attestation Identity Key))를 생성하도록 요청한다. TPM은 AIK를 생성하고, AIK의 공개 부분을 포함하는 아이덴티티 결합(identity binding), AIK의 공개 부분과 그 요약 모두에 대해 수행된 서명을 반환한다. 그런 다음 클라이언트는 TPM에 새 키가 이동 불가라는 표시로서 새 키의 공개 부분을 서명하도록 요청한다. TPM은 새 키의 공개 부분을 서명하며, 새 키를 포함하는 키 인증 구조, 새 키가 이동 불가라는 TPM의 진술, 및 AIK의 비밀 부분을 가지고 생성된 서명을 반환한다. 그런 다음 클라이언트는 인증 기관에 인증 요청; 아이덴티티 결합; 키 인증 구조; 및 TPM의 배서 키의 공개 키 인증서를 보낸다. (배서 키는 각각의 TPM이 가지는 특정 TPM을 식별하는 키이다.)
인증 기관이 클라이언트로부터 그러한 항목들을 수신할 때, 그것은 TPM의 배서 키의 공개 키 인증서를 검사하여 그 배서 키와 관련된 TPM이 인증 기관이 알고 신뢰하는 TPM이라는 것을 검증한다. 그러면 인증 기관은 인증서를 검증하여 클라이언트가 인증하도록 요청하고 있는 새 키를 복구하도록 한다. 그런 다음 인증 기관은 아이덴티티 결합에 대한 서명을 검증하고, 인증 요청의 요약을 산출하며, 산출된 요약과 아이덴티티 결합에 포함된 요약을 비교하여 두 요약들이 매치하는지를 확인한다. 요약들이 매치하고 아이덴티티 결합에 대한 서명이 유효하면, 이러한 사실들은 아이덴티티 결합에 언급된 AIK가 특히 인증 기관이 수신했던 인증 요청을 위해 생성되었음을 증명한다. 요약이 매치하고 아이덴티티 결합에 대한 서명이 바르게 검증된다고 추정할 때, 인증 기관은 키 인증 구조를 검사하고 그 구조 상의 서명을 검증한다. 키 인증 구조는 AIK의 비밀 부분을 소유한 당사자에 의해 행해진, 상기 구조 안에 포함된 새 키가 이동 불가라는 진술을 나타낸다. 따라서, 키 인증 구조가 인증 요청 안에 있는 동일한 키를 언급하고 서명이 검증되면, 인증 기관은 AIK의 비밀 부분을 보유한 당사자가 그 키가 이동 불가라고 진술했음을 알게 된다.
이 시점에서 인증 기관은 새 키에 대한 인증서를 생성하고, 그 인증서에 서명한다. 그러나, 인증서에 명확한 서명을 포함하는 대신, 인증 기관은 대칭 키를 생성하고 그 대칭 키를 사용해 서명을 암호화한다. 그런 다음, 인증 기관은 인증 요청과 함께 수신했던 공개 배서 키를 이용하여 대칭 키를 암호화하며, TPM의 공개 배서 키에 의해 암호화된 대칭 키와 함께 인증서(대칭 키에 의해 암호화된 서명을 포함함)를 클라이언트에게 보낸다. 인증 기관이 TPM의 배서 키에 대한 공개 키 인증서를 수신했을 때, 인증 기관은 그 배서 키와 연관된 특정 TPM을 신뢰한다고 판단한다. 그 TPM이 클라이언트가 실행되는 장치에 존재하는 한(다른 배서 키를 가진 어떤 다른 TPM과 반대로), 클라이언트는 먼저 TPM에 대칭 키를 해독하는 데 그것의 배서 키를 사용하라고 요청하며, 그런 다음 서명을 해독하는 데 그 대칭 키를 사용함으로써 인증서 안의 서명을 해독할 수 있을 것이다. 클라이언트가 암호화된 서명을 명확한 서명으로 바꿀 때, 그 인증서가 사용될 수 있을 것이다. 클라이언트에 다른 TPM(가령, 인증 기관에 의해 신뢰되지 않은 TPM)이 존재하면, 그 TPM은 대칭 키를 해독할 수 없을 수 있는데, 이는 그것이 대칭 키가 암호화되게 했던 배서 키를 가지지 않을 것이기 때문이다. 그 경우 클라이언트는 서명을 해독할 수 없을 것이고, 인증서는 사용되지 못할 것이다.
이 요약내용은 이하의 상세한 설명에 자세히 기술되는 엄선된 개념들을 간략한 형식으로 소개하기 위해 주어진다. 이 요약내용은 청구된 주제의 주요 특징이나 필수적 특징을 확인하도록 의도되거나 청구된 주제의 범위를 한정하는 데 사용되도록 의도된 것이 아니다.
도 1은 클라이언트가 인증 기관에 키를 인증하도록 요청할 때 사용될 수 있는 여러 구성요소들의 블록도이다.
도 2-5는 총괄하여 키를 인증하라는 요청이 만들어지고 작용될 수 있는 전형적 프로세스의 흐름도이다.
도 6은 전형적인 아이덴티티 결합의 블록도이다.
도 7은 전형적인 키 인증 구조의 블록도이다.
도 8은 암호화된 서명을 가진 전형적인 인증서의 블록도이다.
도 9는 여기 기술된 주제의 구현과 관련하여 사용될 수 있는 전형적 구성요소들의 블록도이다.
암호 키들은 암호화 및 디지털 서명과 같은 컴퓨터 보안의 다양한 응용에 사용된다. 암호화는 해독 키(암호 키와 동일할 수도 동일하지 않을 수도 있음)를 보유한 당사자만이 메시지를 해독할 수 있도록 암호 키를 가지고 메시지를 암호화하는 프로세스이다. 디지털 서명은 개체(서명자)가 데이터의 한 부분에 대해 주장하게 하는 프로세스이며, 여기서 서명은 그 주장이 실제로 키를 보유한 개체에 의해 이뤄졌다는 암호화 강도(cryptographic-strength) 보증을 제공한다.
암호화 및 디지털 서명 프로세스들은 모두 이 프로세스들에 참여하는 당사자들 사이의 묵시적 신뢰 관계를 수반한다. 예를 들어 A가 B의 키로 데이터를 암호화할 때, A는 묵시적으로 다음과 같은 것을 신뢰한다: (a) A가 믿는 키가 B의 것이라는 것이 정말 B의 키이며, (b) B의 키로 데이터를 암호화하고 암호화된 데이터를 비보안 채널을 통해 전송하는 것이 암호화 데이터가 A에게 있어 허용될 수 없는 어떤 방식으로 이용되게 하지 않을 것이다. 예를 들어, (a)와 관련하여, A는 신뢰할 수 없는 소스로부터 B의 키를 수신했을 수 있으므로, A가 B에 속한다고 믿는 키는 실제로 침입자(interloper)의 키일 수 있다. 혹은, (b)와 관련하여, 키는 실제로 B의 키일 수 있지만, B는 키의 보안이 손상될 정도로 느슨한 보안을 사용할 수도 있고, 그에 따라 침입자들이 B의 키를 가지고 암호화되었던 메시지를 해독하게 할 수 있다. 마찬가지로, A가 B에 의해 서명되었다고 알려진 메시지를 수신할 때(가령, "사실 F는 참이고 B에 의해 서명되었다"는 메시지), A가 그 메시지에 의존하는 경우, A는 메시지가 정말 B에 의해 서명되었다(즉, A는 어떤 키가 B의 것인지 정말로 알고, B의 키가 손상되지 않았다)고 묵시적으로 믿는다. 또한 B가 어떤 확신 수준까지 사실 F가 정말 참이라고 검증하지 않았다면, A는 B가 "사실 F가 참이다"라는 메시지를 서명하지 않았을 것이라고도 믿는다.
키들이 사용될 때, 키에 대한 신뢰는 일반적으로 키의 신뢰성에 대한 기관 확인을 가짐으로써 일반적으로 확립된다. 이러한 확인은 기관이 키가 신뢰성이 있다는 것을 알았다는 표시로서 기관이 키에 서명한 인증서의 형식으로 표현된다. 물론, 기관의 서명에 대한 신뢰는 위에 기술된 동일한 형식의 신뢰를 수반하지만, 인증 기관들은 일반적으로 신뢰가 확립되어야 하는 관련 커뮤니티에 잘 알려져 있거나 잘 알려진 기관들에 대해 다시 짧은 신뢰 체인들을 수반한다. 따라서, 어떤 개체가 서명이나 암호화를 우한 키를 사용하고 싶어할 때, 그 개체는 통상적으로 그 키를 적절한 인증 기관으로 제공하고 기관이 그 키를 서명할 것을 요청한다. 기관은 키가 충분히 신뢰성이 있다고 결정하는 데 적절하다고 판단하는 모든 수단을 강구한다. 예를 들어, 기관은 요청하는 개체가 키를 보호하기 위해 사용하는 것이 어떤 종류의 보안 수단들인지(예를 들어, 개체가 하드웨어 보호를 이용하는지 소프트웨어 보호를 이용하는지 여부)를 판단할 수 있다. 기관은 키를 이용해 무엇이 서명될 수 있는지를 판단하기 위해 요청하는 개체가 사용할 것이 어떤 정책들인지를 문의할 수 있다. 혹은, 기관이 소정 유형의 개체들에 대한 키들만을 인증하려고 할 수도 있다(가령, 기관은 회사나 다른 기업을 위한 인증 기관일 수 있고, 그 기업 내 장치들에 의해 사용되는 키들만을 인증하려고 할 수도 있다). 기관이 키를 인증할 수 있다고 판단하면, 기관은 키 및 기관의 서명을 포함하는 인증서를 발급한다. X.509 인증서가 그러한 인증서의 예이다.
장치가 자신의 키들에 대한 신뢰성을 확실히하도록 도울 수 있는 하나의 방법은 그 장치에 결합되어 있는 신뢰 플랫폼 모듈(TPM(Trusted Platform Module))을 이용하는 것이다. TPM은 자신의 호스트 장치에 대해 소정 암호 기능들을 수행하는 칩이다. 호스트 장치는 풍부한 보안 서비스들의 열을 제공하기 위해 이러한 암호 기능들을 이용할 수 있다. 예를 들어 TPM은 데이터를 특정한 장치 실행 상태로 봉인(seal)할 수 있어, 장치가 인지된 안전한 상태에 있을 때에만 데이터가 장치에 제공되도록 한다. 이러한 기법은 보통 호스트 상에서 암호 키들을 보호하기 위해 사용된다. 그러한 기법을 가지고 호스트는 TPM을 이용하여 키를 봉인하며, 봉인된 키만이 장치의 디스크 드라이브 상에 저장된다. 호스트가 키를 사용하고자 할 때, 호스트는 TPM에 키를 봉인해제하도록 요청하며, TPM은 장치가 키가 봉인되어 있던 실행 상태에 있을 때에만 봉인을 해제할 것이다. 이러한 실행 상태(통상적으로 플랫폼 설정 레지스터( Platform Configuration Register)들 또는 "PCR"들의 특정 값들로 나타냄)는 앞서, 키의 오용에 대비한 충분한 보장을 제공하는 안전한 것이라고 검증되어 있다. TPM이 키에 대한 보안을 제공할 수 있는 또 다른 방법은 키 쌍을 생성하고, 키 쌍의 공개 부분만을 호스트에게 제공함으로써, 그러한 키 쌍과 연루된 모든 비밀 키 동작들은 TPM 안에서 수행된다. TPM은 그러한 키에 대한 다양한 보장을 제공할 수 있다. 예를 들어 TPM은 TMP을 떠나지 않은 키는 이동 불가(non-migratabel) 키(즉, 키를 봉인했던 특정 TPM을 이용하는 것이 아닌 어떠한 플랫폼 상에서도 사용될 수 없는 키)라고 보장할 수 있다.
이동 불가 키가 TPM에 의해 보안되기 때문에, 키가 침입자들에 의해 잘못 사용될 가능성이 거의 없고 호스트 플랫폼 상의 악성코드에 의해 오용될 가능성이 거의 없다는 점에서 키는 매우 신뢰성이 크다. 관련 커뮤니터의 멤버들에게 이러한 신뢰성을 입증하기 위해, 호스트 플랫폼은 이동 불가 키를 어느 기관에 제공할 수 있고 기관이 신뢰성의 표시로서 그 키를 인증하도록 요청할 수 있다. 그러나, 이러한 인증을 획득함에 있어 문제가 발생한다. 구체적으로, 그러한 키의 인증서를 발급하기 전에, 인증 기관은 서명하기 위해 제공된 키가 실제로 TPM에 의해 보안되었음을 확인해야 한다. 예를 들어, 호스트 기관은 이동 불가 키를 가질 것을 요구할 수도 있다. 그러나, 키가 이동 불가라고 인증하기 전에, 인증 기관은 단지 호스트가 키가 이동 불가라고 말하는 것이 아니라 TPM이 그 키가 이동 불가라고 진술할 것을 요구할 것이다.
"이 키는 이동 불가하다"와 같은 진술은 일반적으로 신뢰된 개체의 서명된 진술에 의해 확립된다. TPM은 "배서 키"("EK"로 칭하며, 그 공개 및 비밀 부분들은 각기 "EK-public" 및 "EK-private"이라 칭해질 수 있음)라 불리는 키 쌍을 가진다. 주어진 TMP의 배서 키는 그 TMP을 다른 TPM들과 구분한다. TPM의 공개 EK는그 특정 TPM을 신뢰하는 인증 기관들에 알려진다. 예를 들어, 어떤 기업이 서버를 인증 기관으로서 작용하도록 운영할 수 있으며, 그 서버는 그 기업에 의해 소유된 모든 랩탑의 EK를 알고 있을 것이다. 따라서, 호스트 플랫폼이 TPM에 의해 봉인되는 키를 생성하면, 이론적으로 TPM은 EK를 사용하여 TPM이 그 키를 안전하다고 생각한다는 표시로서 그 키에 서명하도록 할 수 있다. 인증 기관은 자신이 알고 신뢰하는 그러한 TPM들의 공개 EK들을 알기 때문에, 인증 기관은 신뢰 TPM이 키가 이동 불가하다는 것을 확인했다고 검증하기 위해 서명을 사용할 수 있으며, 인증 기관은 그것을 기반으로 키의 인증서를 발급할 수 있을 것이다. 그러나, 실제로 TPM은 EK를 가지고 임의 데이터에 서명하는 것을 방지하는 정책들을 가진다. 따라서, TPM은 통상적으로 EK를 사용하여 다른 키들을 생성하며, TPM은 이러한 다른 키들을 이용하여 데이터에 서명한다. 그러한 "다른 키"의 예가 증명 아이덴티티 키(AIK(Attestation Identity Key))이며, 그것은 TPM이 다른 키들에 서명하기 위해 사용하는 것들이다.
통상적으로 AIK는 다음과 같은 방식으로 키의 인증을 획득하는데 사용된다. 호스트 플랫폼 상의 소프트웨어는 TPM에 새로운 키 쌍을 생성하도록 요청하며, 그를 위해 소프트웨어는 공개 부분을 수신한다. 그러면 소프트웨어는 TPM에 새 키의 공개 부분에 결합되는 AIK를 생성하도록 요청하며, 그런 다음 인증 기관("CA")이 AIK의 공개 부분(즉, "AIK-public")에 서명하도록 요청한다. 이 프로세스 중에, CA는 그 요청이 실제로 자신이 신뢰하는 TPM으로부터 나온다는 것을 검증한다. 예를 들어, CA는 논스(nonce)를 사용함으로써 자신과 TPM 사이의 통신 채널 보안을 검증할 것이다. CA가 AIK에 서명하라는 요청이 CA가 신뢰하는 TPM으로부터 나왔다는 것을 확신하면, CA는 AIK-public에 서명하고 그 인증서를 호스트 플랫폼에 반환한다. 그러면 호스트 플랫폼은 새 키를 생성하며, 새 키에 서명하기 위해 TPM이 AIK의 비밀 부분("AIK-private")을 사용하도록 요청한다. 새 키에 서명하기 위한 AIK의 사용은 TPM이 새 키에 대해 행한 어떤 진술을 나타낼 것이다-가령, AIK를 이용해 새 키에 서명하는 것은 TPM이 새 키가 이동 불가하다는 것을 단언한다는 것을 나타낼 수 있을 것이다. 그러면 호스트는 CA에 새 키; 서명; 및 AIK의 CA 인증서; 및 CA가 새 키에 서명하라는 요청을 제공한다. CA는 새 키에 대한 서명을 검증하기 위해 AIK-public을 사용하며, AIK에 대한 신뢰가 앞서 확립되었음을 검증하기 위해 AIK-public의 인증서를 사용한다. 그런 다음 CA는 새 인증서를 발급하고 그것을 호스트에게 반환한다.
상술한 과정에서 일어나는 문제는 CA에 대해 여러 번의 왕복(라운드 트립)을 사용한다는 것이다: 한 방향은 AIK를 인증하고, 또 다른 방향은 TPM이 AIK를 가지고 서명했던 키를 인증하기 위한 것이다.
여기 기술된 주제는 TPM의 호스트 플랫폼이 CA가 한 번의 왕복으로 TPM 보호 키를 인증할 것을 요청하게 한다. 여기 기술된 기법은 AIK를 인증하기 위해 별도의 왕복 사용을 피하게 한다. 대신, 호스트 플랫폼 상의 클라이언트는 TPM에 요청해 새로운 이동 불가 키를 생성하도록 하고, CA에 요청하여 CA가 먼저 AIK를 신뢰한다고 확립하지 않은 채 새 키를 인증하도록 한다. CA는 키를 인증하는 것으로 응답하지만, 호스트가 CA가 신뢰하는 TPM을 가진다는 조건으로 인증서를 후속 사용하는 방식에 따른다. 이러한 과정을 수행하기 위해, 클라이언트는 TPM에 요청하여 클라이언트가 인증하였기를 원하는 새 키를 생성한다. 그런 다음 클라이언트는 인증 요청-즉 CA가 새 키를 서명하게 하는 요청을 생성한다. 실제로 그 요청을 CA에게 보내기 전에, 클라이언트는 TPM에 요청하여 인증 요청에 결합된 AIK를 생성하도록 한다. TPM은 AIK의 공개 부분, 인증 요청의 요약, 및 서명을 포함하는 아이덴티티 결합을 생성함으로써 응답한다. 그러면 클라이언트는 TPM에 새 키에 서명하도록 요청한다. TPM은 인증될 키, 키에 대한 진술(가령, "이 키는 이동 불가이다"는 진술), 및 AIK-private을 사용해 생성된 서명을 포함하는 키 인증 구조를 생성함으로써 응답한다. 그러면 클라이언트는 인증 요청, 아이덴티티 결합, 키 인증 구조 및 TPM의 EK-public의 인증서를 CA로 전달한다.
CA는 그러면 EK-public의 인증서를 검증하여 그것이 CA가 신뢰하는 TPM에 속하는지를 확인하도록 한다. 이제 CA는 인증 요청을 요약하고, 그 요약을 식별 바인당에 포함된 요약과 비교하고 아이덴티티 결합에 대한 서명을 검증한다. 요약들이 매치하고 서명이 검증된다고 추정할 때, 이러한 요인들은 AIK가 CA가 수신했던 인증 요청에 대해 생성되었음을 증명한다. 다음으로, CA는 인증 요청으로부터 인증될 키를 복구하고, 그것을 키 인증 구조에서 식별된 키와 비교하여, 키 인증 구조가 인증 요청시 특정된 키와 관계가 있다는 것을 확실히 한다. 그런 다음 CA는 키에 대한 진술이 CA의 인증서 발급 정책과 일치하도록 확실히 하기 위해 키 인증 구조 안에서 만들어진 진술을 검사한다(가령, CA의 정책이 이동 불기 키들만을 인증하도록 요청하면, CA는 그 진술이 키의 이동 불가성을 증명한다는 것을 검증한다). CA는 다음으로 키 인증 구조 상의 서명을 검증하여 그 구조 안에 포함된 진술이 AIK-private 보유자에 의해 작성되었음을 확인한다. 상술한 검증들 모두가 적절하다고 추정될 때, CA는 이 시점에서, AIK의 보유자가 새 키가 이동 불가하다는 것을 단언하고 있고 그 키에 대한 인증서를 요청하고 있다는 것을 안다.
CA가 알지 못하는 것은 AIK가 EK-public과 연관된 신뢰 TPM과 관련되는지 여부이다. 따라서, CA는 클라이언트에게 조건부 인증서를 발급한다. EK-private을 보유한 (CA가 신뢰하는) TPM이 AIK가 그 TPM에 의해 발급되었는지를 증명할 경우에만 그 인증서가 사용될 수 있다는 점에서 그 인증서는 조건부이다. 인증서를 조건부로 만들기 위해, 인증서를 명확하게 서명하는 것 대신, CA는 대칭 키를 생성하고 대칭 키를 가지고 인증서의 서명을 암호화 한다. 그래서 CA는 클라이언트에게 암호화된 서명을 포함하는 인증서를 제공하고, 또한 EK-public에 의해 암호화된 대칭 키를 제공한다. 인증 요청에 사용되었던 AIK가 EK를 보유한 신뢰 TPM에 의해 실제로 생성되었다면, 그 클라이언트는 TPM에 EK-private을 사용해 나중에 인증서에 대한 서명을 해독하는데 사용될 수 있는 대칭 키를 해독하도록 요청할 수 있을 것이다. 그렇지 않고, 만일 CA가 EK-public에 의해 식별된 신뢰 TPM을 가지지 못한 장치 상의 클라이언트에게 인증서를 제공하는 경우, 클라이언트는 서명을 해독할 수 없을 것이고 인증서를 사용할 수 없을 것이다. 이러한 방식으로 CA는 신뢰 TPM에 특정 AIK의 신뢰성을 검증하는 일을 위임하며, 그로써 AIK가 인증되게 하는 데 있어 인증 기관 및 클라이언트 사이에 별도의 라운드(round)를 피할 수 있게 된다.
이제 도면을 참조하면, 도 1은 클라이언트가 인증 기관이 새 키를 인증할 것을 요청할 때 사용될 수 있는 다양한 구성요소들 및 그 구성요소들 사이의 상호동작들의 예를 보인다. 도면 및 이어지는 설명에서, 클라이언트가 인증하고자 요청하는 키를 "새(새로운) 키"라 칭한다. 일례로, 이 키는 클라이언트가 데이터에 서명하는 프로세스의 일부로서 사용할 RSA(Rivest-Shamir-Adelman)의 공개 부분이다. 따라서, 통상의 시나리오 상에서, 클라이언트는 새 RSA 서명 키를 생성하고 서명 키가 다른 개체들에 의해 신뢰될 수 있도록 CA에 의해 그 키가 인증되게 하도록 모색한다. 그러나, 여기 기술되는 기법들은 서명 키들, 혹은 RSA 키들의 인증에 국한되지 않는다. 일반적으로, 여기서의 기법들은 클라이언트가 키를 생성하고 그 키를 CA에 의해 인증받도록 모색할 때마다 적용된다. 따라서, 클라이언트가 인증받도록 모색하는 키를 "새(새로운) 키"라고 칭할 것이다. 여기에 기술된 기법들은 다양한 키들의 사용을 포함하며, 그 키들은 적절한 표시 및/또는 변형자들에 의해 내용 및 도면 안에서 구분될 것이다.
장치(102)는 퍼스널 컴퓨터, 핸드헬드 컴퓨터, 세톱 박스 등과 같은 어떤 컴퓨팅 기능을 제공하는 장치이다. 장치(102)는 TPM(104)을 갖춘다. TPM(104)은 TPM(104)이 위치되는 장치(102)에 대한 다양한 보안 서비스를 제공하는 구성요소이다. TPM(104)은 각기 공개(public) 및 비밀(private) 부분들(108 및 110)(여기서 "EK-Public" 및 "EK-Private"이라 불림)을 가지는 비대칭 키 쌍에 해당하는 배서(endorsement) 키(EK)(106)이다. 각각의 TPM(104)은 다른 TPM들에 의해 공유되지 않는 자체 EK를 가진다. EK(106)의 한 가지 양태는 EK-private이 TPM(104)의 밖으로 노출되지 않는다는 것이다. TPM(104)은 TPM(104)이 EK-Private을 가지고 데이터의 한 부분을 해독하도록 장치(102)가 요청하는데 사용할 수 있는 인터페이스를 드러내고, 그에 따라 TPM(104)은 EK-Private의 실제 값을 노출하지 않은 채 장치(102)의 데이터를 해독할 수 있다. TPM(104)은 또한 다른 다양한 보안 기능을 제공한다. 예를 들어 TPM(104)은 장치의 현재 실행 상태에 대한 평가치를 기록하는 레지스터들(플랫폼 설정 레지스터(Platform Configuration Register)들 또는 PCR들)의 집합을 보유하며, TPM(104)은 장치(102)가 데이터의 부분들을 특정 장치 상태로 봉인할 수 있게 한다. 이런 식으로 장치(102)는 TPM(104)만이 봉인해제할 수 있는 봉인된 데이터의 한 부분을 보유할 수 있으며, TPM(104)은 장치(102)가 현재 알려진 "안전" 상태에 있지 않으면 데이터를 봉인해제하는 것을 거부함으로써 그 데이터를 보호할 수 있다. TPM(104)에 의해 제공되는 또 다른 특징은 TPM(104)의 안쪽에 키들을 저장하는데 사용될 수 있는 작은 크기의 메모리이다. 따라서, TPM(104)은 키 쌍들을 생성할 수 있고, 비밀 부분이 장치(102)의 비보안 부분들에 도출되지 않도록 자체 메모리 안에 키의 비밀 부분을 보유할 수 있다. 이런 의미에서, 비밀 키가 TPM(104) 안에 보유되는 키 쌍은 이동 불가(non-migratable) 키이다: 그것은 특정 장치의 TPM 밖에 노출되지 않기 때문에 다른 장치들로 이동하게 될 수 없다.
클라이언트(112)는 어떤 목적(가령, 서명이나 암호화)을 위해 새 키를 생성하고 싶어하는 소프트웨어 구성요소이다. 클라이언트(112)는 애플리케이션, 운영체계의 구성 요소, 또는 장치(102) 상에 실행되는 어떤 다른 유형의 소프트웨어 구성요소일 수 있을 것이다. 클라이언트(112)가 새 키를 생성하고자 결정할 때, 클라이언트(112)는 TPM(104)이 새 키를 생성하라는 요청(114)을 발령한다. TPM(104)은 요청된 키를 생성하고 키가 식별될 수 있게 하는 키 핸들(116)로 반환한다. 통상적으로, 요청(114)은 RSA 키 쌍과 같은 비대칭 키 쌍을 생성하도록 하는 요청이며, 이 경우 키 핸들(116)은 새 키의 공개 부분을 포함한다(비밀 부분은 TPM(104) 안에서만 보유된다). 이 예에서, RSA 키 쌍의 공개 부분은 클라이언트가 인증 받도록 모색하는 "새 키"이다. (기술적으로, 그것은 데이터에 서명하는데 사용되는 비밀 키이며, 공개 키는 서명을 검증하기 위해 다른 당사자들에 의해 사용된다. 데이터는 누군가가 나중에 서명을 검증할 것이라는 예상과 함께 서명되므로, 이 명세서에서의 목적상, 공개 키는 데이터에 서명하는 "프로세스의 일부"로 간주될 수 있다.)
새 키가 검증되게 하기 위해, 클라이언트(112)는 인증 기관이 키를 인증하도록 요청하는 공식 데이터 구조에 해당하는 인증 요청(118)을 생성한다. 클라이언트(112)는 이 시점에 인증 요청(118)을 인증 기관으로 보내지 않는다. 그렇게 하기 전에, 클라이언트(112)는 인증 요청과 함께 보내기 위해 데이터의 여러 부분들이 TPM에 의해 생성되게 정한다. 이들 여러 개의 데이터가 이하에 기술된다.
먼저, 클라이언트(112)는 TPM(104)으로 증명 아이덴티티 키(AIK)에 대한 요청(119)을 발령한다. TPM(104)은 데이터의 임의 부분에 결합된 AIK를 생성하는 기능을 보인다. 예를 들어 TPM(104)은 "블롭(blob)"(여기서 "블롭"은 데이터의 임의 부분이다)에 암호적으로 구속되는 방식으로 AIK를 반환하는 "CreateAIK (blob)"과 같은 함수를 보일 수 있을 것이다. 구체적으로, 클라이언트(112)가 "CreateAIK (blob)" 요청을 발령하면, TPM(104)은 다음과 같은 형식으로 데이터의 부분을 반환한다:
AIK-Public | blob | sig-AIK-Private (AIK-Public | blob)
(표시법의 문제로서, 수직 바 심볼 "|"는 연결(concatenation)을 나타낸다. 또한, 이 내용 전체를 통해 표기법 "sig-<key-pair>-Private (<data>)"는 <키 쌍>의 비밀 부분을 이용하여 <데이터> 위에 생성되는 서명을 나타낼 것이다.) 클라이언트(112)가 TPM(104)에게 AIK를 요청할 때, AIK가 결합되어 있도록 클라이언트가 요청하는 "블롭"은 인증 요청(118)의 요약(digest)이다. AIK 생성 함수에 의해 반환되는 데이터를 아이덴티티 결합(identity binding)(120)이라 부르며, 아이덴티티 결합(120)의 예가 도 6에 보여진다. 구체적으로, 아이덴티티 결합(120)은 AIK-Public(602), 인증 요청의 요약(604), 및 AIK-Public(602) 및 요약(604) 위에 행해지는 서명(606)을 포함하며, 서명(606)은 AIK-Private을 사용하여 생성된다. 따라서, 클라이언트(112)가 TPM(104)으로부터 수신하는 아이덴티티 결합(120)은 다음과 같다:
AIK-Public | digest | sig-AIK-Private (AIK-Public | digest)
아이덴티티 결합이 하는 일은 AIK를 특정 인증 요청에 (그 요청의 요약을 이용하여) 구속시키는 것이다. 사실상, 서명은 AIK-Private의 보유자(TPM(104)에 해당)가 "요약"이 AIK가 생성되었던 데이터라고 주장한다는 것을 의미한다. 아이덴티티 결합(120)을 가지는 어떤 당사자이든 그 서명을 검증하기 위해 AIK-Public을 사용할 수 있다.
도 1로 돌아가면, 클라이언트(112)는 다음에 TPM(104)으로 새 키가 AIK를 사용해 서명되도록 하는 요청(122)을 발생시킨다. TPM(104)이 AIK를 가지고 키를 서명할 때, TPM(104)은 키에 적용하는 보안 특성들을 나타내는 구조를 반환한다. 예를 들어, 상술한 바와 같이, 클라이언트(112)가 CA에 의해 인증을 모색하는 새 키가 TPM에 의해 생성되었다. 새 키가 키 쌍인 경우의 예에서, TPM(104)은 TPM(104)의 내부에 비밀 부분을 보유하며 TPM(104) 밖에서 비밀 부분을 누설하지 않는다. 이러한 의미에서 새 키는 이동 불가한데, 이는 그것의 비밀 부분이 TPM(104)을 포함하지 않는 특정 장치(즉, 장치(102)가 아닌 어떤 장치 상에서 사용될 수 없기 때문이다. 따라서, TPM(104)이 AIK를 가지고 키를 서명할 때, TPM(104)은 사실상 다음과 같은 정보를 포함하는 구조를 반환한다:
statement │ new key │ sig-AIK-Private (statement │ new key) "statement(진술)"은 새 키에 대한 진술이다. 예를 들어, 진술은 사실상 "서명되는 키가 이동 불가 키이다"라고 말할 수 있다. (영어 문장의 형식으로 작성된 진술의 예는 다만 예시를 위한 것이다. 통상적으로 진술은 코드를 사용하여 만들어질 수 있다. 혹은, TPM이 키가 특정 보안 규격을 만족하지 않으면 키 서명을 거부하는 어떤 알려진 정책을 가질 때, 진술은 TPM이 키에 서명했다는 사실에 내포될 수도 있다. 또한, "이동 불가성"이 키의 전형적 특징이라는 것을 알아야 하며, 이 예는 여기서의 설명 전체에 걸쳐 사용된다. 따라서, 설명이 종종 키를 이동 불가한 특징을 가졌다고 나타내거나, AIK가 사용되어 키가 이동 불가하다는 진술을 서명하거나, CA가 그 키가 이동 불가성의 정책을 만족하는 것을 체크한다. 그러나, 이동 불가성은 단지 그러한 특징의 한 예일 뿐이다. 일반적으로 키는 어떤 특징을 가질 수 있고, 키 인증 구조에 포함된 진술은 그러한 어떤 특징을 증명할 수 있으며, CA는 키가 0 개 이상의 특성들의 어떤 집합을 가질 것을 요구하는 정책을 부과할 수 있다. 따라서, 여기서의 설명은 이동 불가 키들을 나타내지만, 키의 어떤 특징이 무엇이든 관계 없이 키 인증 구조는 그 키의 특징만을 증명한다는 것을 알 수 있을 것이고, 이하에 논의되는 것과 같이 CA는 그 키 인증 구조를 사용하여 CA의 정책이 요구하는 어떠한 특징이든 증명하는 데 AIK-Private이 사용되었는지 여부를 판단할 수 있다.)
따라서, TPM(104)이 키를 서명할 때, 그것은 키 인증 구조(124)를 도출하며, 그 예가 도 7에 도시된다. 전형적인 키 인증 구조(124)는 진술(702)(도시된 것처럼 명시적으로 표현되거나 묵시적으로 표현될 수 있음)을 포함한다. 키 인증 구조(124)는 또한 인증될 새 키(704), 및 AIK-Private을 사용하여 생성되고 진술 및 새 키에 대해 산출되는 서명(706)을 포함한다. 키 인증 구조(124)는 AIK-Private을 제어하는 어떤 개체든 새 키(704)가 이동 불가 키(또는 AIK-Private의 보유자가 증명하는 것이 어떠한 특징을 가진다)라고 주장하는 것을 입증한다. AIK-Public을 보유한 어떤 개체(즉, 상술한 아이덴티티 결합을 가진 어떤 개체)는 상기 서명을 사용하여 새 키(704) 및 진술(702)이 AIK-Private을 보유한 개체에 의해 서명되었다는 것을 입증할 수 있다.
도 1로 돌아가면, 인증 기관(CA)(126)은 클라이언트(112)가 새 키를 인증하도록 요청하고 싶어하는 개체이다. 클라이언트(112)은 이제 CA(126)에게 인증서를 요청할 준비가 된다. CA(126)가 새 키를 인증하도록 요청하기 위해, 클라이언트(112)는 CA(126)에게 인증 요청(118); 아이덴티티 결합(120); 키 인증 구조(124), 및 EK(106)의 인증서(128)(즉, EK-Public을 포함하는 TPM(104)의 배서 키에 대한 공개 키 인증서)를 보낸다. 이 항목들은 CA(126)에 의해 수신된다.
일례에서, CA(126)는 인증서들을 발급하라는 요청들에 대해 작용하는 서버이다. 예를 들어, CA(126)는 기업 내 새 장치들을 그 키들을 인증함으로써 등록하는 회사(또는 기업) 내 서버일 수 있다. CA(126)는 어떤 키들을 인증할지에 대해 결정을 내리는 발급 구성요소(130)를 포함한다. CA(126)는 신뢰 TPM들의 리스트(132)(가령, CA(126)가 신뢰하는 TPM들의 EK-Public들의 리스트)를 포함할 수 있다. CA(126)는 또한 인증 요청들이 허가되게 하거나 거부되게 하는 규칙들을 포함하는 정책(134)을 가질 수 있다. 예를 들어, CA(126)는 이동 불가 키들을 인증하기만 하는 정책을 가질 수도 있고, 아니면 어떤 다른 정책을 가질 수도 있다. 또한, CA(126)는 수신하는 데이터의 여러 부분들에 대한 암호화된 서명을 검증하도록 허락한 서명 검증기(136)를 가질 수 있다. 이 구성요소들은 발급 구성요소(130)에 의해 사용될 수 있다. 예를 들어 발급 구성요소는 서명 검증기(136)를 사용하여 아이덴티티 결합 및 키 인증 구조 상의 서명들을 검증할 수 있다. 발급 구성요소(130)는 또한 그것이 기꺼이 키들을 검증하려고 하는 것이 어떤 TPM들을 위한 것인지를 판단하기 위해 신뢰 TPM들의 리스트(132)를 사용할 수 있다. 또한, 발급 구성요소(130)는 인증 요청이 어느 한 신뢰 TPM으로부터 나오더라도, 그것이 특정 키를 인증할 것인지 여부를 판단하기 위한 정책(134)을 사용할 수 있다. (가령, 발급 구성요소는 TPM(104)을 신뢰할 수도 있지만, TPM(104)이 키가 이동 불가하다고 주장하지 않을 거라면 TPM(104)에 대한 키를 인증하기를 꺼릴 수도 있을 것이다.)
CA(126)가 상술한 항목들을 클라이언트(112)로부터 수신할 때, 그것은 다음과 같은 일을 한다. 먼저, CA(126)는 인증서(128)(TPM(104)의 배서 키를 포함함)를 검사하여 CA(126)가 클라이언트(112)가 실행되고 있는 장치 상의 TPM을 알고 신뢰하는지 여부를 판단한다. 예를 들어, TPM(104)이 CA(126)에게 알려져 있지 않으면(이것은 인증서(128)를 리스트(132)와 비교함으로써 판단될 수 있음), CA(126)는 TPM(104)이 인스톨되어 있는 장치 상의 키를 인증하는 것을 꺼릴 수 있을 것이다. 따라서, 인증서(128)가 인증이 모색되고 있는 키가 모르는 TPM에 결합되어 있다는 것을 나타내면, CA(126)는 인증 요청을 거부할 수 있다.
CA(126)가 공공 배서 키가 인증서(128) 안에 나타나는 TPM을 알고 신뢰한다고 추정할 때, CA(126)는 클라이언트(112)가 인증하려고 요청하고 있는 새 키를 복구하기 위해 인증 요청(118)을 검사한다(이는 그 키가 인증 요청에 포함되어 있기 때문이다).
다음에, CA(126)는 인증 요청의 요약을 발견하기 위해 아이덴티티 결합(120)을 검사한다. 그런 다음 CA(126)는 (아이덴티티 결합(120) 안에 요약을 생성하는데 사용되었던 것과 동일한 요약 알고리즘을 이용하여) 인증 요청의 요약을 산출하고, 아이덴티티 결합에 포함된 요약이 CA(126)가 산출했던 요약과 매치하는 것을 검증한다. 요약들이 매치하면, CA(126)는 아이덴티티 결합(120)으로부터 AIK-Public을 읽어 내고, AIK-Public을 사용하여 아이덴티티 결합(120)에 대한 서명을 검증한다. 이것은 데이터의 특정 부분의 생성 시점에 AIK가 그 데이터의 특정 부분에 구속된다는 것이 상기될 것이다. 서명에 대한 검증은 이러한 특정 AIK가 생성되었던 데이터의 부분이 인증 요청(118)의 요약임을 입증한다. 요약 프로세스가 안전하다는 점에서, AIK가 그 요약에 대해 생성되었다는 사실이 그 AIK가 인증 요청(118)에 대해 생성되었다는 것을 입증한다. 검증 프로세스가 실패했다면(즉, AIK가 현재 이뤄지고 있는 것이 아닌 어떤 인증 요청을 위해 생성되었다면), 이 사실은 인증 요청이 어떤 종류의 재전송 공격(replay attack)의 일환으로서 이뤄졌다는 것을 암시할 수 있으므로, CA(126)는 그 요청을 거부할 수 있을 것이라는 것을 알아야 한다.
다음으로 CA(126)는 보안 요청에 포함된 새 키에 대해 AIK-Private의 보유자가 하고 있는 것이 어떤 진술인지를 판단하기 위해 키 인증 구조를 검사한다. CA(126)는 AIK-Public을 사용하여 키 인증 구조 상의 서명을 검증한다. 서명이 검증되지 않으면, CA(126)는 AIK-Private의 보유자가 CA(126)에 대한 어떤 특정한 진술을 행하였다고 추단할 수 없고, 그래서 CA(126)는 인증 요청을 거부한다. 서명이 검증된다고 추정할 때, CA(126)는 새 키의 특성들이 CA(126)의 정책(134)에 부합하는지 여부를 판단한다. 예를 들어 CA(126)가 오직 이동 불가 키들만을 인증하는 정책을 가진 경우, 그것은 키가 이동 불가하다고 AIK-Private의 보유자가 단언함을 키 인증 구조가 보인다고 주장할 수 있다.
이 시점까지 프로세스의 내용은 어떤 개체가 그 키를 실제로 보유하는지를 식별하지 않고 "AIK-Private의 보유자"를 나타냈다. AIK-Private은 사실상 TPM(104)에 의해 보유되는데, 이는 그것이 AIK를 생성했던 TPM(104)이기 때문이다. 그러나, 그 사실은 CA(126)에게 알려지지 않는다. CA(126)는 TPM(104)의 배서 키의 공개 부분을 알고 있지만, CA(126)가 단지 그 배서 키로만 특정 TPM과 특정 AIK 사이의 관계를 추론할 수는 없다. 다시 말하면, 프로세스의 이 시점까지 CA(126)는 CA(126)가 수신했던 특정 인증 요청에 대해 어떤 개체가 AIK를 생성했다는 것과, 그 개체가 누구이든 인증될 키에 대해 CA(126)의 발급 정책을 만족하는 진술을 하였다는 것을 안다. 그러나 CA(126)는 그 개체가 누구인지는 알지 못한다. 상술한 바와 같이, CA(126)는 TPM(104)의 공개 배서 키를 검사하였고 TPM(104)이 신뢰할 수 있다고 판단하였으므로, CA(126)는 AIK-Private을 제어하는 개체가 TPM(104)일 때 그 인증 요청을 기꺼이 수락하게 될 것이다. 그러나 CA(126)는 AIK-Private이 TPM(104)에 의해 제어되는지 어떤 다른 개체에 의해 제어되는지 여부를 알지 못한다. 이하에 기술되는 바와 같이, CA(126)는 AIK-Private을 제어하는 개체가 실제로 TPM(104)인 경우에만 사용될 수 있는 형식으로 조건부 인증서를 발급할 수 있다. 구체적으로, 인증서의 형식은 인증서가 사용될 수 있기 전에 TPM(104)이 어떤 조치를 수행해야 하게 할 수 있는 것이다. 특히, 인증서에 대한 서명은 TPM에 의해 수행되는 프로세스의 결과로서만 해독할 수 있는 방식(가령, TPM에 의한 서명의 해독이나, 서명을 해독하기 위해 나중에 사용되는 키의 TPM에 의한 해독)으로 암호화될 수 있다.
특정 TPM의 존재에 대해 조건부인 인증서를 발급하기 위해, CA(126)는 요청된 것과 같이 새 키의 인증서(가령, X.509 인증서)를 생성한다. 인증서는 인증될 키 및 키를 인증하는 인증 기관의 서명을 포함한다. 정상적으로 서명은 명확하게(즉, 암호화되지 않고) 인증서 안에 들어있을 것이다. 그러나, CA(126)가 인증서를 생성할 때, 그것은 대칭 키를 생성하고, 서명을 암호화하기 위해 대칭 키를 사용한다. 암호화된 서명이 명확한(clear) 서명 대신 인증서 안에 위치된다. 그런 다음 CA(126)는 TPM(104)의 공개 배서 키(즉, CA(126)가 인증서(128) 안에서 수신했던 EK-Public)를 가지고 대칭 키를 암호화한다. EK-Private의 보유자(즉, TPM(104))만이 EK-Public을 가지고 암호화되는 정보를 해독할 수 있으므로, TPM(104) 만이 그 대칭 키를 복구할 수 있을 것이다. 따라서, CA(126)는 클라이언트(112)에게 다음과 같은 것을 보낸다: (a) 암호화된 서명이 포함된 인증서(138), 및 (b) 암호화된 대칭 키(140)(EK-Public에 의해 암호화됨). 클라이언트(112)가 암호화된 대칭 키를 수신할 때, 클라이언트는 TPM(104)에 요청하여 EK-public을 사용하여 그것을 해독하게 할 수 있고, 그에 따라 클라이언트(112)가 대칭 키를 가지고 서명을 해독하게 할 수 있다. 클라이언트(112)는 다음으로 인증서(138) 내 암호화된 서명을 명백한 서명으로 대체할 수 있다. 인증서(138)가 도 8에 도시된다. 인증서(138)는 암호화된 서명(802)과 함께 대칭 키에 의해 암호화된 sig-CA-Private (새 키)인 새 키(704)를 포함한다. ("CA-Private"은 CA(126)의 비밀 키이다.)
CA(126)가 인증하고 있는 키가 TPM(104)이 AIK를 생성했던 실제 개체인 경우에만 CA(126)가 참이라고 인지하는 CA(126)에 의해 부과된 적용 가능한 규격(가령, 이동 불가성)을 만족시킨다는 것을 TPM(104)이 증명했을 때에만, CA(126)는 사용 가능한 인증서를 발급하고 싶어한다는 것을 알아야 한다. 이론적으로 AIK는 TPM(104)이 아닌 어떤 개체에 의해 생성되었을 수 있다. 그 경우 CA(126)는 TPM(104)이 해독할 수 있는 암호화된 서명을 포함하는 인증서(138)를 여전히 발급할 것이다(왜냐면 그 서명은 TPM(104)의 비밀 배서 키를 가지고 복구될 수 있는 대칭 키로 암호화되기 때문이다). 그러나, CA(126)가 암호화된 서명을 포함한 인증서를 TPM(104)으로 보낼 때, 인증서(138)에 의해 인증된 새 키가 실제로 TPM(104)이 AIK를 가지고 서명했던 것이 아니라면 명확한 서명을 가진 인증서를 생성하지 않기 위해 CA(126)는 TPM(104)에 의존한다. 사실상 CA(126)는 이러한 결정을 TPM(104)에 위임하는데, 이것은 CA(126)가 TPM(104)이 CA(126)가 신뢰하는 TPM임을 이미 확정하였기 때문에 그럴 수 있다. 따라서, TPM(104)이 인증된 서명을 포함한 인증서(138)를 수신한 후, TPM(104)은 인증서(138)에 의해 인증된 새 키가 TPM(104)이 AIK를 사용해 서명했던 키인지 여부를 판단한다. 그런 경우에 해당하면, TPM(104)은 서명을 해독하며, 그 암호화된 서명을 명확한 서명으로 바꾼다. 그렇지 않은 경우이면, TPM(104)은 서명을 해독하지 않으며, 그에 따라 인증서는 사용불가한 상태에 놓여질 것이다. 어느 당사자도 당사자 자신이 신뢰하는 적절한 기관에 의해 인증서가 서명되었다고 검증할 수 없다면 키 인증서를 신뢰하지 않을 것이다. 인증서 안의 서명이 해독될 수 없다면, 인증서는 사실상 사용 불가 상태로 남는데, 이는 그것이 어떤 당사자에게도 신뢰를 확립하도록 사용되지 못할 것이기 때문이다.
도 2-5는 흐름도의 형식으로 키를 인증하라는 요청이 만들어지고 작용될 수 있는 전형적 프로세스를 보인다. 도 2-5의 내용을 참조하기 전에, 이 도면들에 포함된 흐름도가 도 1에 도시된 구성요소들을 참조하여 예로서 기술되지만, 이 프로세스는 어떠한 시스템에서라도 실행될 수 있으며 도 1에 도시된 시나리오에 국한되지 않는다는 것을 알아야 한다. 또한, 도 2-5의 각 흐름도는 블록들을 연결하는 선들로 나타낸 것과 같이 프로세스의 단계들이 특정 순서로 수행되는 예를 보이지만, 이 도면에 도시된 여러 단계들은 어떤 순서, 또는 어떤 조합 또는 부조합으로도 수행될 수 있다.
202에서, 클라이언트는 TPM이 새 키를 생성하라고 요청한다. 위에서 언급한 것과 같이, 새 키는 예컨대, 암호화나 서명과 같은 어떤 암호 기능에 사용될 수 있는 RSA 키 쌍일 수 있다. RSA 키 쌍이 생성되는 경우의 예에서, 이 흐름도에 나타낸 "새 키"(즉, 인증될 키)는 키 쌍의 공개 부분이다.
204에서, 새 키에 대한 인증 요청이 생성된다. 그 요청의 요약이 생성되고(206), 그런 다음 클라이언트가 TPM이 그 요약에 결합되는 AIK를 생성하도록 요청한다(208). 그러면 TPM은 AIK를 생성하고(210), 아이덴티티 결합을 반환한다. 위에서 언급한 바와 같이, 아이덴티티 결합은 AIK-Public, 그 요약, 및 AIK-Public과 요약에 대해 수행되는 서명(서명은 AIK-Private으로 생성됨)을 포함한다.
212에서, 클라이언트는 TPM이 AIK를 사용해 새 키에 서명하도록 요청한다. 그런 다음 TPM은 새 키에 대한 (명시적이거나 묵시적인) 진술(가령, "이 키는 이동 불가이다"), 새 키 자체, 및 진술 및 새 키에 대해 수행되는 서명(서명은 AIK-Private으로 생성됨)을 포함하는 키 인증 구조를 반환한다(214). 216에서, 클라이언트는 CA에 다음을 보낸다: (a) 인증 요청; (b) 아이덴티티 결합; (c) 키 인증 구조; 및 (d) TPM의 배서 키(EK-Public)의 공개 키 인증서. 218에서, 이 항목들은 CA에 의해 수신된다.
220에서, CA는 알려진 TPM들의 리스트에 대해 EK-Public을 체크한다. EK-Public에 기반하여, CA가 신뢰성이 없는 TPM(222에서 판단됨)으로부터 EK-Public과 관련된 TPM이 CA에 알려지지 않은 것이거나 알려진 것이라고 판단하면, CA는 프로세스를 중단하고(224) 인증서를 발급하지 않는다. EK-Public이 알려진 신뢰 TPM으로부터 나온 것이면, 프로세스는 226으로 진행하며, 거기에서 CA는 인증이 요청되고 있는 새 키를 얻고자 하는 인증 요청을 읽는다.
CA는 아이덴티티 결합에 대한 서명을 검증하고, 결합으로부터 요약을 복구하고, 또한 인증 요청으로부터 요약 자체를 산출한다. 아이덴티티 결합이 인증 요청과 매치하지 않으면(즉, 228에서 판단되는 것과 같이, 인증 요청에 포함된 요약이 인증서 인증 요청으로부터 CA가 산출했던 요약과 동일하지 않으면), 프로세스는 중단되고, CA는 인증서를 발급하지 않는다(230). 그렇지 않으면, 프로세스는 232로 진행한다.
232에서, 키 인증 구조가 새 키가 적용 가능한 정책(가령, 이동 불가라는 정책)을 만족한다는 것을 증명하는지 여부를 CA가 판단한다. CA는 가령, 키 인증 구조 상의 서명을 검증하고, 그런 다음 그 구조가 키에 대해 행한 진술을 검사함으로써, 그러한 판단을 내릴 수 있다. 서명이 검증에 실패하거나, 진술이 키가 키를 인증할 CA의 정책을 만족하지 못한다는 것을 나타내는 경우, 프로세스가 중단되고 CA는 인증서를 발급하지 않는다(234). 그렇지 않다면, 프로세스는 236으로 진행하고, 거기서 CA는 인증서 발급을 진행한다.
236에서 CA는 인증서 상의 서명을 암호화하기 위해 사용될 대칭 키를 생성한다. 238에서 CA는 새 키에 대한 인증서를 생성한다. 240에서 CA는 인증서에 대한 서명을 생성한다. 242에서 CA는 대칭 키를 사용해 서명을 암호화하고, 인증서 안에 (명확한 서명 대신) 암호화된 서명을 포함시킨다. 244에서, CA는 EK-Public(인증서가 발급될 장치 상에 있는 TPM의 배서 키의 공개 부분)을 가지고 대칭 키를 암호화한다. 246에서 CA는 인증서를 요청했던 클라이언트에게 키의 인증서(암호화된 서명을 포함함), 및 EK-Public에 의해 암호화된 대칭 키를 보낸다. 248에서, 이 항목들은 클라이언트에 의해 수신된다.
250에서 클라이언트는 TPM에게 EK-Private으로 대칭 키를 해독하도록 요청한다. 인증서에 포함된 키가 인증 요청을 위해 사용되었던 AIK를 가지고 TPM이 서명했던 것과 동일하다고 추정할 때, TPM은 대칭 키를 해독하고(252) 그것을 클라이언트에게 반환한다. 그러면 클라이언트는 대칭 키를 사용하여 서명을 해독하고, 인증서 안의 암호화된 서명을 명확한 서명으로 교체한다(256). 이제 클라이언트는 새 키에 대해 사용 가능한 인증서를 보유한다(258).
도 9는 여기에 기술된 주제의 양태들이 알맞게 사용될 수 있는 전형적인 환경을 보인다.
컴퓨터(900)는 한 개 이상의 프로세서들(902) 및 한 개 이상의 데이터 기억 구성요소들(904)을 포함한다. 프로세서(들)(902)은 통상적으로, 퍼스널 데스크탑이나 랩탑 컴퓨터, 서버, 핸드헬드 컴퓨터, 또는 다른 종류의 컴퓨팅 장치에서 보여지는 것들 같은 마이크로프로세서들이다. 데이터 기억 구성요소(들)(904)은 짧거나 긴 기간 동안 데이터를 저장할 수 있는 구성요소들이다. 데이터 기억 구성요소(들)(904)의 예들은 하드 디스크, 탈착가능 디스크(광 및 자기 디스크 포함), 휘발성 및 비휘발성 RAM(random-access memory), ROM(read-only memory), 플래시 메모리, 자기 테이프 등을 포함한다. 데이터 기억 구성요소(들)은 컴퓨터 판독 가능 저장 매체의 예들이다. 컴퓨터(900)는 CRT(cathode ray tube) 모니터, LCD(liquid crystal display) 모니터, 또는 어떤 다른 유형의 모니터일 수 있는 디스플레이(912)를 포함하거나 그와 관련될 수 있다.
소프트웨어는 데이터 기억 구성요소(들)(904) 안에 저장될 수 있고 한 개 이상의 프로세서(들)(902) 상에서 실행될 수 있다. 그러한 소프트웨어의 예는 도 1-8과 관련해 상술한 기능의 일부나 전부를 구현할 수 있는 키 인증 소프트웨어(906)이지만, 어떤 유형의 소프트웨어라도 사용될 수 있을 것이다. 소프트웨어(906)는 예컨대, 분산 시스템 안의 구성요소들일 수 있는 한 개 이상의 구성요소들, 개별 파일들, 개별 함수들, 개별 오브젝트들, 개별 코드 라인들 등을 통해 구현될 수 있다. 프로그램이 하드 디스크에 저장되고 RAM에 로드되며 컴퓨터 프로세서(들) 상에서 실행되는 퍼스널 컴퓨터가 도 9에 도시된 시나리오의 특징을 나타내지만, 여기에 기술된 주제가 이 예에 국한되는 것은 아니다.
여기 개시된 주제는 데이터 기억 구성요소(들)(904) 중 한 개 이상에 저장되고 프로세서(들)(902) 중 한 개 이상에서 실행되는 소프트웨어로서 구현될 수 있다. 또 다른 예로서, 이 주제는 한 개 이상의 컴퓨터 판독 가능 저장 매체 상에 저장되는 명령어들로서 구현될 수 있다. (광 디스크나 자기 디스크 같은 유형의 매체가 저장 매체의 예이다.) 그러한 명령어들은 컴퓨터나 다른 장치에 의해 실행될 때, 컴퓨터나 장치가 방법의 한 개 이상의 동작들을 수행하게 할 수 있다. 그러한 동작들을 수행하는 명령들은 한 개의 매체 상에 저장될 수도 있고, 아니면 복수의 매체에 걸쳐 분산되어 명령어들 전체가 동일한 매체 상에 있게 되는지 여부와 상관 없이 한 개 이상의 컴퓨터 판독 가능 저장 매체 상에서 총괄적으로 나타날 수 있다.
또한, 여기 개시된 어떠한 동작들이든(도면에 도시된 것이든 도시되지 않은 것이든) 프로세서(가령, 프로세서들(902) 중 한 개 이상)에 의해 방법의 일부로서 수행될 수 있다. 따라서, 동작들 A, B 및 C가 여기에 기술되면 그 A, B, 및 C의 동작들을 포함하는 방법이 수행될 것이다. 또한, A, B, 및 C의 동작들이 여기에 개시되면, A, B, 및 C의 동작들을 수행하기 위해 프로세서를 사용하여 A, B, 및 C의 동작들을 포함하는 방법이 수행될 것이다.
전형적인 한 환경 하에서, 컴퓨터(900)는 네트워크(908)를 통해 한 개 이상의 다른 장치들과 통신 가능하게 연결될 수 있다. 구조에 있어 컴퓨터(900)와 유사할 수 있는 컴퓨터(910)가 컴퓨터(900)에 연결될 수 있는 장치의 예지만, 다른 유형의 장치들 역시 그렇게 연결될 수 있다.
발명의 대상이 구조적 특징들 및/또는 방법론적 행위들에 특정한 언어를 통해 위에서 기술되었지만, 첨부된 청구범위에 규정된 발명의 대상이 위에서 기술된 특정한 특징들이나 행위들에 반드시 국한되는 것은 아니라는 것을 이해해야 한다. 오히려, 상술한 특정한 특징들과 행위들은 청구범위를 구현하는 예시적 형태들로서 개시된다.

Claims (20)

  1. 제1 키의 인증서를 요청하기 위한 실행가능 명령어를 저장하는 하나 이상의 컴퓨터 판독가능 저장 장치로서,
    상기 실행가능 명령어는 컴퓨터에 의해 실행되는 경우 상기 컴퓨터로 하여금 동작들을 수행하게 하고, 상기 동작들은
    상기 제1 키가 인증되게 하는 인증 요청을 생성하는 동작과,
    상기 인증 요청에 결합된 증명 아이덴티티 키(attestation identity key)를 신뢰 플랫폼 모듈(trusted platform module)에게 요청하는 동작과,
    상기 신뢰 플랫폼 모듈로부터, 상기 증명 아이덴티티 키를 상기 인증 요청에 결합하는 아이덴티티 결합(identity binding)을 수신하는 동작과,
    상기 신뢰 플랫폼 모듈이 상기 증명 아이덴티티 키를 사용하여 상기 제1 키에 서명하도록 요청하는 동작과,
    상기 신뢰 플랫폼 모듈로부터, 상기 제1 키를 포함하며 상기 증명 아이덴티티 키에 의해 서명된 키 인증 구조를 수신하는 동작과,
    인증 기관이 상기 증명 아이덴티티 키를 신뢰한다는 것을 먼저 확정하지 않고 상기 인증 요청, 상기 아이덴티티 결합, 상기 키 인증 구조, 및 상기 신뢰 플랫폼 모듈의 공개 배서 키의 제1 인증서를 포함하는 정보를 상기 인증 기관에 전송하는 동작과,
    상기 인증 기관으로부터, 상기 제1 키의 제2 인증서를 수신하는 동작- 상기 제2 인증서는 상기 인증 기관이 상기 증명 아이덴티티 키를 신뢰한다는 것을 상기 신뢰 플랫폼 모듈에 의해 상기 인증 기관에 대해 입증하는 조치가 취해진 후에만 사용될 수 있는 형식으로 되어 있음 -
    을 포함하는, 컴퓨터 판독가능 저장 장치.
  2. 제1항에 있어서,
    상기 동작들은 상기 인증 요청의 요약(digest)을 산출하는 동작을 더 포함하고,
    상기 증명 아이덴티티 키를 상기 요약에 결합함으로써 상기 증명 아이덴티티 키는 상기 인증 요청에 결합되는
    컴퓨터 판독가능 저장 장치.
  3. 제1항에 있어서,
    상기 제1 인증서는 상기 인증 기관의 서명을 포함하고, 상기 서명은 상기 신뢰 플랫폼 모듈의 비밀 배서 키를 사용하는 프로세스에 의해서만 해독될 수 있으며, 상기 조치는 상기 신뢰 플랫폼 모듈의 비밀 배서 키의 사용을 포함하는
    컴퓨터 판독가능 저장 장치.
  4. 제3항에 있어서,
    상기 동작들은 상기 인증 기관으로부터, 상기 신뢰 플랫폼 모듈의 공개 배서 키에 의해 암호화된 대칭 키를 수신하는 동작을 더 포함하며,
    상기 제2 인증서는 상기 대칭 키에 의해 암호화된 형식의 상기 서명을 포함하며,
    상기 신뢰 플랫폼 모듈의 비밀 배서 키를 사용하는 상기 프로세스는
    상기 대칭 키를 해독하기 위해 상기 신뢰 플랫폼 모듈의 비밀 배서 키를 사용하는 단계, 및
    상기 서명을 해독하기 위해 상기 대칭 키를 사용하는 단계를 포함하는
    컴퓨터 판독가능 저장 장치.
  5. 제1항에 있어서,
    상기 제2 인증서는 암호화된 형태로 수신된 서명을 포함하며,
    상기 동작들은
    상기 암호화된 형식의 상기 서명을 복호화된 형식의 서명(a signature in a clear form)으로 대체하는 동작을 더 포함하는
    컴퓨터 판독가능 저장 장치.
  6. 제1항에 있어서,
    상기 제1 키는 RSA(Rivest-Shamir-Adelman) 키 쌍의 공개 부분을 포함하는
    컴퓨터 판독가능 저장 장치.
  7. 제1항에 있어서,
    상기 제1 키는 이동 불가하며(non-migratable), 상기 키 인증 구조는 상기 제1 키가 이동 불가하다는 진술(statement)을 포함하는
    컴퓨터 판독가능 저장 장치.
  8. 제1항에 있어서,
    상기 제1 키는 상기 신뢰 플랫폼 모듈이 위치하는 머신 상에서 데이터에 서명하는 프로세스의 일부로서 사용되는
    컴퓨터 판독가능 저장 장치.
  9. 제1 키를 인증하라는 요청에 대해 수행되는 방법으로서,
    프로세서를 사용하여 동작들을 수행하는 단계를 포함하고,
    상기 동작들은
    클라이언트로부터 정보를 수신하는 동작- 상기 정보는
    제1 키를 인증하라는 인증 요청,
    상기 클라이언트가 실행되는 머신 상의 신뢰 플랫폼 모듈에 의해 생성되는 증명 아이덴티티 키의 아이덴티티 결합,
    상기 제1 키의 특징(feature)을 증명하기 위해 상기 증명 아이덴티티 키를 사용하는 키 인증 구조, 및
    상기 신뢰 플랫폼 모듈의 공개 배서 키의 제1 인증서를 포함함 -과,
    상기 공개 배서 키에 기초하여, 상기 신뢰 플랫폼 모듈이 상기 동작들을 수행하는 인증 기관에 의해 신뢰됨을 입증하는 동작과,
    상기 아이덴티티 결합이 상기 증명 아이덴티티 키를 상기 인증 요청에 결합함을 입증하는 동작과,
    상기 제1 키가 상기 특징을 가진다는 진술을 상기 키 인증 구조가 나타냄을 상기 증명 아이덴티티 키의 비밀 부분의 보유자에 의해 입증하는 동작과,
    상기 클라이언트로 상기 제1 키의 제2 인증서를 전송하는 동작- 상기 제2 인증서의 사용은 상기 증명 아이덴티티 키가 신뢰할만하다는 것을 입증하는 임무를 상기 신뢰 플랫폼 모듈에 위임하기 위해 상기 증명 아이덴티티 키의 신뢰성을 먼저 확정하지 않고, 상기 신뢰 플랫폼 모듈의 존재에 의존함 -
    을 포함하는
    방법.
  10. 제9항에 있어서,
    상기 신뢰 플랫폼 모듈의 비밀 배서 키의 사용 이후에만 상기 인증서를 사용가능하게 함으로써 상기 제2 인증서의 사용이 상기 신뢰 플랫폼 모듈의 존재에 의존하게 하는
    방법.
  11. 제9항에 있어서,
    상기 제2 인증서는 상기 인증 기관의 서명을 포함하며, 상기 서명은 상기 신뢰 플랫폼 모듈의 비밀 배서 키의 사용을 통해서만 해독되는 형식으로 되어있는
    방법.
  12. 제9항에 있어서,
    상기 제2 인증서는 상기 인증 기관의 서명을 포함하고, 상기 서명은 대칭 키를 사용하여 암호화되며, 상기 동작들은
    상기 신뢰 플랫폼 모듈의 공개 배서 키에 의해 암호화된 상기 대칭 키를 상기 클라이언트로 전송하는 동작을 더 포함하는
    방법.
  13. 제9항에 있어서,
    상기 특징은 상기 제1 키가 이동 불가하다는 것을 포함하고, 상기 키 인증 구조는 상기 제1 키가 이동 불가하다는 명시적이거나 묵시적인 진술을 포함하는
    방법.
  14. 제9항에 있어서,
    상기 제1 키는 RSA(Rivest-Shamir-Adelman) 키 쌍의 공개 부분을 포함하는
    방법.
  15. 제9항에 있어서,
    상기 제1 키는 상기 신뢰 플랫폼 모듈에 의해 데이터를 암호화 또는 서명하는 프로세스의 일부로서 사용되는
    방법.
  16. 제9항에 있어서,
    상기 아이덴티티 결합은 상기 인증 요청의 제1 요약을 포함함으로써 상기 증명 아이덴티티 키를 상기 인증 요청에 결합하며,
    상기 동작들은
    상기 인증 요청의 제2 요약을 산출하는 동작, 및
    상기 제2 요약이 상기 제1 요약과 매칭됨을 입증하는 동작을 더 포함하는
    방법.
  17. 제1 키의 인증서를 획득하기 시스템으로서,
    메모리와,
    프로세서와,
    배서 키 쌍과 연관된 신뢰 플랫폼 모듈(trusted platform module: TPM)- 상기 배서 키 쌍은 상기 TPM을 다른 TPM과 구별시킴 -과,
    상기 메모리에 저장되고 상기 프로세서 상에서 실행되는 클라이언트
    를 포함하되,
    상기 클라이언트는
    상기 TPM이 제1 키를 생성하도록 요청하고,
    상기 제1 키가 인증 기관에 의해 인증되게 하는 인증 요청을 생성하고,
    상기 TPM이 증명 아이덴티티 키(attestation identity key)를 상기 인증 요청에 결합하는 아이덴티티 결합(identity binding)을 생성하도록 요청하고,
    상기 TPM이 상기 증명 아이덴티티 키를 사용하여 상기 제1 키에 서명하는 키 인증 구조를 생성하도록 요청하고,
    상기 인증 기관이 상기 증명 아이덴티티 키를 신뢰한다는 것을 먼저 확정하지 않고 상기 인증 요청, 상기 아이덴티티 결합, 상기 키 인증 구조, 및 상기 TPM의 공개 배서 키의 제1 인증서를 상기 인증 기관에 보내고,
    상기 인증 기관으로부터, 상기 제1 키의 제2 인증서를 수신하되,
    상기 제2 인증서는 상기 인증 기관이 상기 증명 아이덴티티 키를 신뢰한다는 것을 상기 TPM에 의해 상기 인증 기관에 대해 입증하는 조치가 취해진 후에만 사용될 수 있는 형식으로 되어 있는
    시스템.
  18. 제17항에 있어서,
    상기 TPM에 의한 조치는 상기 TPM이 상기 TPM의 비밀 배서 키를 사용하는 것을 포함하는
    시스템.
  19. 제17항에 있어서,
    상기 제2 인증서는 대칭 키에 의해 암호화되는 형식의 상기 인증 기관의 서명을 포함하고,
    상기 클라이언트는 상기 TPM의 공개 배서 키에 의해 암호화된 상기 대칭 키를 상기 인증 기관으로부터 수신하고,
    상기 클라이언트는 상기 TPM이 상기 TPM의 비밀 배서 키를 사용하여 상기 대칭 키를 해독하도록 요청하고,
    상기 클라이언트는 상기 대칭 키를 사용하여 상기 서명을 해독하고 상기 암호화된 서명을 상기 제2 인증서의 복호화된 서명(a clear signature)으로 대체하는
    시스템.
  20. 제17항에 있어서,
    상기 제1 키는 상기 TPM이 위치하는 머신으로부터 이동가능하지 않고, 상기 TPM은 상기 제1 키가 이동가능하지 않다는 표시로서 상기 제1 키를 상기 증명 아이덴티티 키로 서명하는
    시스템.
KR1020127010781A 2009-10-28 2010-09-24 일회 왕복 키 인증 KR101731132B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/607,937 2009-10-28
US12/607,937 US8700893B2 (en) 2009-10-28 2009-10-28 Key certification in one round trip
PCT/US2010/050285 WO2011056321A2 (en) 2009-10-28 2010-09-24 Key certification in one round trip

Publications (2)

Publication Number Publication Date
KR20120101363A KR20120101363A (ko) 2012-09-13
KR101731132B1 true KR101731132B1 (ko) 2017-04-27

Family

ID=43899369

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020127010781A KR101731132B1 (ko) 2009-10-28 2010-09-24 일회 왕복 키 인증

Country Status (7)

Country Link
US (1) US8700893B2 (ko)
EP (1) EP2494733A4 (ko)
JP (1) JP5693595B2 (ko)
KR (1) KR101731132B1 (ko)
CN (1) CN102577229B (ko)
TW (1) TWI507006B (ko)
WO (1) WO2011056321A2 (ko)

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012023050A2 (en) 2010-08-20 2012-02-23 Overtis Group Limited Secure cloud computing system and method
WO2012122994A1 (en) * 2011-03-11 2012-09-20 Kreft Heinz Off-line transfer of electronic tokens between peer-devices
CN102355351B (zh) * 2011-07-21 2014-11-05 华为技术有限公司 一种基于可信计算的密钥生成、备份和迁移方法及系统
US8375221B1 (en) 2011-07-29 2013-02-12 Microsoft Corporation Firmware-based trusted platform module for arm processor architectures and trustzone security extensions
WO2013061792A1 (ja) * 2011-10-25 2013-05-02 株式会社アイエスアイ 電子マネー送金方法およびそのシステム
US8953790B2 (en) * 2011-11-21 2015-02-10 Broadcom Corporation Secure generation of a device root key in the field
US8850187B2 (en) * 2012-05-17 2014-09-30 Cable Television Laboratories, Inc. Subscriber certificate provisioning
US9756036B2 (en) * 2012-06-15 2017-09-05 Nokia Technologies Oy Mechanisms for certificate revocation status verification on constrained devices
WO2014079009A1 (zh) * 2012-11-22 2014-05-30 华为技术有限公司 虚拟机的管理控制方法及装置、系统
US10270748B2 (en) 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
US9521000B1 (en) * 2013-07-17 2016-12-13 Amazon Technologies, Inc. Complete forward access sessions
US9940446B2 (en) * 2013-07-25 2018-04-10 Siemens Healthcare Diagnostics Inc. Anti-piracy protection for software
US9652631B2 (en) 2014-05-05 2017-05-16 Microsoft Technology Licensing, Llc Secure transport of encrypted virtual machines with continuous owner access
US10326597B1 (en) 2014-06-27 2019-06-18 Amazon Technologies, Inc. Dynamic response signing capability in a distributed system
US9391777B2 (en) * 2014-08-15 2016-07-12 Palo Alto Research Center Incorporated System and method for performing key resolution over a content centric network
US9519787B2 (en) * 2014-11-14 2016-12-13 Microsoft Technology Licensing, Llc Secure creation of encrypted virtual machines from encrypted templates
US9742762B2 (en) 2014-12-01 2017-08-22 Microsoft Technology Licensing, Llc Utilizing a trusted platform module (TPM) of a host device
US10205598B2 (en) * 2015-05-03 2019-02-12 Ronald Francis Sulpizio, JR. Temporal key generation and PKI gateway
CN105141420B (zh) * 2015-07-29 2018-09-25 飞天诚信科技股份有限公司 一种安全导入、签发证书的方法、设备及服务器
DE102015214696A1 (de) * 2015-07-31 2017-02-02 Siemens Aktiengesellschaft Vorrichtung und Verfahren zum Verwenden eines Kunden-Geräte-Zertifikats auf einem Gerät
US9768966B2 (en) * 2015-08-07 2017-09-19 Google Inc. Peer to peer attestation
US10146916B2 (en) * 2015-11-17 2018-12-04 Microsoft Technology Licensing, Llc Tamper proof device capability store
CN107086907B (zh) 2016-02-15 2020-07-07 阿里巴巴集团控股有限公司 用于量子密钥分发过程的密钥同步、封装传递方法及装置
CN107086908B (zh) 2016-02-15 2021-07-06 阿里巴巴集团控股有限公司 一种量子密钥分发方法及装置
US10277407B2 (en) * 2016-04-19 2019-04-30 Microsoft Technology Licensing, Llc Key-attestation-contingent certificate issuance
CN107347058B (zh) 2016-05-06 2021-07-23 阿里巴巴集团控股有限公司 数据加密方法、数据解密方法、装置及系统
CN107370546B (zh) 2016-05-11 2020-06-26 阿里巴巴集团控股有限公司 窃听检测方法、数据发送方法、装置及系统
CN107404461B (zh) 2016-05-19 2021-01-26 阿里巴巴集团控股有限公司 数据安全传输方法、客户端及服务端方法、装置及系统
US10396991B2 (en) * 2016-06-30 2019-08-27 Microsoft Technology Licensing, Llc Controlling verification of key-value stores
EP3510722B1 (en) 2016-09-08 2021-07-21 Nec Corporation Network function virtualization system and verifying method
US10320571B2 (en) * 2016-09-23 2019-06-11 Microsoft Technology Licensing, Llc Techniques for authenticating devices using a trusted platform module device
CN107959656B (zh) 2016-10-14 2021-08-31 阿里巴巴集团控股有限公司 数据安全保障系统及方法、装置
CN107959567B (zh) 2016-10-14 2021-07-27 阿里巴巴集团控股有限公司 数据存储方法、数据获取方法、装置及系统
US10164778B2 (en) * 2016-12-15 2018-12-25 Alibaba Group Holding Limited Method and system for distributing attestation key and certificate in trusted computing
CN110383751B (zh) * 2017-01-06 2023-05-09 皇家飞利浦有限公司 关于证实的数据的pinocchio/trinocchio
US11438155B2 (en) * 2017-01-24 2022-09-06 Microsoft Technology Licensing, Llc Key vault enclave
CN108667608B (zh) 2017-03-28 2021-07-27 阿里巴巴集团控股有限公司 数据密钥的保护方法、装置和系统
CN108667773B (zh) 2017-03-30 2021-03-12 阿里巴巴集团控股有限公司 网络防护系统、方法、装置及服务器
CN108736981A (zh) 2017-04-19 2018-11-02 阿里巴巴集团控股有限公司 一种无线投屏方法、装置及系统
US10819696B2 (en) * 2017-07-13 2020-10-27 Microsoft Technology Licensing, Llc Key attestation statement generation providing device anonymity
US11868995B2 (en) 2017-11-27 2024-01-09 Nok Nok Labs, Inc. Extending a secure key storage for transaction confirmation and cryptocurrency
US11831409B2 (en) 2018-01-12 2023-11-28 Nok Nok Labs, Inc. System and method for binding verifiable claims
US11475107B2 (en) * 2018-03-12 2022-10-18 Hewlett-Packard Development Company, L.P. Hardware security
CN110324138B (zh) * 2018-03-29 2022-05-24 阿里巴巴集团控股有限公司 数据加密、解密方法及装置
CN109450620B (zh) 2018-10-12 2020-11-10 创新先进技术有限公司 一种移动终端中共享安全应用的方法及移动终端
CN111371726B (zh) * 2018-12-25 2022-06-14 阿里巴巴集团控股有限公司 安全代码空间的认证方法、装置、存储介质及处理器
US20200280550A1 (en) * 2019-02-28 2020-09-03 Nok Nok Labs, Inc. System and method for endorsing a new authenticator
US11792024B2 (en) 2019-03-29 2023-10-17 Nok Nok Labs, Inc. System and method for efficient challenge-response authentication
CN110046515B (zh) * 2019-04-18 2021-03-23 杭州尚尚签网络科技有限公司 一种基于短效数字证书的安全的电子签名方法
US11429519B2 (en) 2019-12-23 2022-08-30 Alibaba Group Holding Limited System and method for facilitating reduction of latency and mitigation of write amplification in a multi-tenancy storage drive
EP3855328A1 (en) * 2020-01-24 2021-07-28 Thales Dis France Sa A method for securely diversifying a generic application stored in a secure processor of a terminal
KR102559101B1 (ko) * 2020-02-24 2023-07-25 한국전자통신연구원 전력 계량 장치, 전력 계량 서버 및 블록 체인 기반의 전력 계량 방법

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050223007A1 (en) * 2004-03-30 2005-10-06 Intel Corporation Remote management and provisioning of a system across a network based connection
US20070016801A1 (en) * 2005-07-12 2007-01-18 Bade Steven A Method, apparatus, and product for establishing virtual endorsement credentials for dynamically generated endorsement keys in a trusted computing platform
WO2008026086A2 (en) * 2006-08-31 2008-03-06 International Business Machines Corporation Attestation of computing platforms
WO2008031148A1 (en) 2006-09-11 2008-03-20 Commonwealth Scientific And Industrial Research Organisation A portable device for use in establishing trust

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2003213056A1 (en) 2002-02-22 2003-09-09 Emc Corporation Authenticating hardware devices incorporating digital certificates
US7461251B2 (en) 2002-05-09 2008-12-02 Canon Kabushiki Kaisha Public key certification issuing apparatus
JP4724655B2 (ja) * 2004-04-30 2011-07-13 富士通セミコンダクター株式会社 セキュリティチップおよび情報管理方法
US20050289343A1 (en) * 2004-06-23 2005-12-29 Sun Microsystems, Inc. Systems and methods for binding a hardware component and a platform
US7747862B2 (en) * 2004-06-28 2010-06-29 Intel Corporation Method and apparatus to authenticate base and subscriber stations and secure sessions for broadband wireless networks
US8924728B2 (en) * 2004-11-30 2014-12-30 Intel Corporation Apparatus and method for establishing a secure session with a device without exposing privacy-sensitive information
CN101102180B (zh) * 2006-07-03 2010-08-25 联想(北京)有限公司 基于硬件安全单元的系统间绑定及平台完整性验证方法
CA2681507C (en) 2007-03-19 2013-01-29 Telcordia Technologies, Inc. Vehicle segment certificate management using short-lived, unlinked certificate schemes
US8837722B2 (en) * 2007-10-16 2014-09-16 Microsoft Corporation Secure content distribution with distributed hardware
US8259948B2 (en) * 2007-12-29 2012-09-04 Intel Corporation Virtual TPM key migration using hardware keys

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050223007A1 (en) * 2004-03-30 2005-10-06 Intel Corporation Remote management and provisioning of a system across a network based connection
US20070016801A1 (en) * 2005-07-12 2007-01-18 Bade Steven A Method, apparatus, and product for establishing virtual endorsement credentials for dynamically generated endorsement keys in a trusted computing platform
WO2008026086A2 (en) * 2006-08-31 2008-03-06 International Business Machines Corporation Attestation of computing platforms
WO2008031148A1 (en) 2006-09-11 2008-03-20 Commonwealth Scientific And Industrial Research Organisation A portable device for use in establishing trust

Also Published As

Publication number Publication date
TWI507006B (zh) 2015-11-01
CN102577229B (zh) 2014-05-07
TW201121281A (en) 2011-06-16
WO2011056321A2 (en) 2011-05-12
JP2013509805A (ja) 2013-03-14
JP5693595B2 (ja) 2015-04-01
EP2494733A2 (en) 2012-09-05
US8700893B2 (en) 2014-04-15
US20110099367A1 (en) 2011-04-28
EP2494733A4 (en) 2017-06-28
WO2011056321A3 (en) 2011-08-18
KR20120101363A (ko) 2012-09-13
CN102577229A (zh) 2012-07-11

Similar Documents

Publication Publication Date Title
KR101731132B1 (ko) 일회 왕복 키 인증
US9871655B2 (en) Method for deriving a verification token from a credential
US8555072B2 (en) Attestation of computing platforms
US7526649B2 (en) Session key exchange
US9064129B2 (en) Managing data
WO2020119258A1 (zh) 一种数据处理方法和装置
US20080301436A1 (en) Method and apparatus for performing authentication between clients using session key shared with server
US20120294445A1 (en) Credential storage structure with encrypted password
US20160335453A1 (en) Managing Data
US20220300962A1 (en) Authenticator App for Consent Architecture
US9608993B1 (en) Credential abuse prevention and efficient revocation with oblivious third party
US8914874B2 (en) Communication channel claim dependent security precautions
US11804957B2 (en) Exporting remote cryptographic keys
Jang-Jaccard et al. Portable key management service for cloud storage
US11368316B2 (en) Applying PKI (public key infrastructure) to power of attorney documents
US20240012933A1 (en) Integration of identity access management infrastructure with zero-knowledge services
Sherwood Practical Implications of Public Key Infrastructure for Identity Professionals (v2)
Kounga et al. Enforcing sticky policies with TPM and virtualization
Nepal et al. Portable Key Management Service for Cloud Storage

Legal Events

Date Code Title Description
N231 Notification of change of applicant
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant