KR20040037155A - 사용자 인증을 허용하는 사용자 단말의 고유 온라인프라비젼 - Google Patents

사용자 인증을 허용하는 사용자 단말의 고유 온라인프라비젼 Download PDF

Info

Publication number
KR20040037155A
KR20040037155A KR10-2004-7004467A KR20047004467A KR20040037155A KR 20040037155 A KR20040037155 A KR 20040037155A KR 20047004467 A KR20047004467 A KR 20047004467A KR 20040037155 A KR20040037155 A KR 20040037155A
Authority
KR
South Korea
Prior art keywords
key
client
ticket
spare
server
Prior art date
Application number
KR10-2004-7004467A
Other languages
English (en)
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 KR20040037155A publication Critical patent/KR20040037155A/ko

Links

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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • 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/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • 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/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0457—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply dynamic encryption, e.g. stream encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)

Abstract

본 발명은 KDC(Key Distribution Center)로의 클라이언트의 공개 키의 전송을 보안처리하는 예비 시스템이다. 이 예비 시스템은 사용자 ID(identification)를 포함하는 하나 또는 그 이상의 파라미터에 의해 고유하게 식별가능한 클라이언트; 클라이언트를 등록하기 위한 예비 서버; 및 사용자 ID와 관련된 예비 키 -이 예비 키는 예비 서버에 포워드 됨- 를 생성하기 위한 키 분배 센터를 포함하며, 상기 예비 서버는 클라이언트를 초기화하기 위한 구성 파라미터를 생성하고, 예비 키는 이 구성 파라미터에 포함되며; 초기화시 클라이언트는 키 분배 센터에 포워딩하기 위한 예비 키에 의해 인증처리된 공개 키를 제공한다.

Description

사용자 인증을 허용하는 사용자 단말의 고유 온라인 프라비젼{UNIQUE ON-LINE PROVISIONING OF USER TERMINAL ALLOWING USER AUTHENTICATION}
본 출원은 다음 정식출원, 2002년 7월 12일자로 제출된 "KEY MANAGEMENT INTERFACE TO MULTIPLE AND SIMULTANEOUS PROTOCOLS" 라는 표제의 미국출원번호 10/194,922(관리 번호 018926-008000US); 2002년 3월 4일자로 제출된 "KEY MANAGEMENT PROTOCOL AND AUTHENTICATION SYSTEM FOR SECURE INTERNET PROTOCOL RIGHTS MANAGEMENT ARCHITECTUER" 라는 표제의 미국출원번호 10/092,347(관리 번호 018926-007500US); 2002년 6월 12일자로 제출된 "ACCESS CONTROL AND KEY MANAGEMENT SYSTEM FOR STREAMING MEDIA" 라는 표제의 미국출원번호 10/170,951(관리 번호 018926-007700US); 2002년 5월 21일자로 제출된 "ASSOCIATION OF SECURITY PARAMETERS FOR A COLLECTION OF RELATED STREAMING PROTOCOLS" 라는 표제의 미국출원번호 10/153,445(관리 번호 018926-007600US)에 관련된 것으로, 이들 모두는 본 발명에서 의도적으로 전체적으로 참조함으로써 결합되어 있다.
본 발명은 일반적으로 데이터 통신 분야에 관한 것으로 특히 네트워크에서 통신되는 권리 관리 및 보안 데이터에 관한 것이다.
인터넷과 같은 통신 네트워크를 통해 전송된 콘텐츠를 보안처리하기 위한 종래의 디지털 권리 관리 시스템들은 널리 공지되고 있다. 권리 관리 시스템들은 콘텐츠 제공자에게 직면한 기본적인 문제가 디지털 콘텐츠의 인증되지 않은 이용 및 분배를 방지하는 것이기 때문에 필요하다. 인증되지 않은 인터셉트 및 억세스는 소비자들이 쉽게 콘텐츠를 검색할 수 있으며, 기술이 완벽하게 재생 콘텐츠용으로 활용가능하기 때문에 엑서스베이트(exercebate)된다.
다수의 메카니즘이 인증되지 않은 억세스 및 복사에 대한 방지를 하고 디지털 관리 관리를 제공하기 위해 개발되었다. 한가지 방법은 콘텐츠가 어떻게 사용되는지를 한세트의 루울이 결정하는 디지털 권리 관리 시스템이다. 인증되지 않은 복사를 억제하기 위한 다른 방법(소프트웨어의 경우)은 통상적으로 동작하다가 특정 지속시간후에 만료되는 소프트웨어 시험판 또는 데모를 제공하는 구조의 이용이다. 게다가, 대안적인 방법은 콘텐츠가 보여지기 전에 소비자 단말에 라이센스의 존재를 요구하는 것이다.
수많은 상술한 방법들은 디지털 콘텐츠의 "암호화/복호화"를 이용하여 통상적으로 실행된다. 암호화는 인증되지 않은 소비자에 의해 쉽게 알아낼 수 없는, 예를 들면, 암호문과 같은 이해할 수 없는 형태로의 데이터의 변환이다. 복호화는 이해할 수 있도록 오리지널 형태로 암호화된 콘텐츠를 역으로 변환하는 프로세스이다. 간단한 암호는 알파벳내의 문자들의 로테이션, 숫자로 문자의 대체, 및 측파대 주파수로 반전시킴으로써 음성 신호의 "스크램블링(scrambling)"을 포함한다. 보다 복잡한 암호는 디지털 정보 콘텐츠내의 데이터 비트를 재배열하는 복잡한 컴퓨터 알고리즘에 따라 작업한다.
암호화된 정보 콘텐츠를 쉽게 복원하기 위하여, 정확한 복호화 키가 요구된다. 이 키는 암호화 및 복호화 알고리즘 둘다에 대한 파라미터로서 요구되는 2진수 스트링이다. 일반적으로, 키가 더 커질수록 더 어렵게 되어 키에 대한 억세스없이 통신을 디코딩하게 된다. 일반적으로, 압호화/복호화 시스템에 대한 2가지 타입의 방법들이 있다, 즉 (1) 2개의 상이한 키들, 암호화하거나 사인하기 위한 것, 및 복호화하거나 검증하기 위한 것을 활용하는 비대칭 시스템들 또는 PKS(public key systems); 및 (2) 대칭 또는 비밀키로서 알려져 있는 비공개 키 시스템들, 통상적으로 암호화 및 복호화 키들이 동일한 시스템. 공개 및 비밀키 시스템 둘다를 이용하여, 키들을 분배하고 키들을 받아들이기 위한 부분들을 적절하게 인증하기 위한 키 관리가 사용되어야만 한다.
MIT에서 개발된 한가지 관련된 기술인 키 관리 시스템은 커베로스 프로토콜로서 알려져 있다. 커베로스는 KDC(key distribution center)와 티켓의 개념을 이용함으로써 네트워크상의 상이한 기계들에 특정인이 억세스할 수 있도록 한 인증 프로토콜이다. 일반적으로, 티켓은 티켓이 발행되었던 클라이언트의 식별을 서버에 안전하게 패스시키는데 사용된다. 불행하게도, 커베로스는 비교적 복잡하고 많은 상이한 옵션들을 포함하고, 특정 어플리케이션에 항상 적용되지 않는다. 게다가, 그러한 복잡한 시스템을 변경하는 것은 옵션이 없으며, 그것은 익숙치 않은 시스템에 대한 변경이 추가적인 에러를 수반할 위험이 있기 때문이다. 커베로스의 다른 단점은 키 관리 메시지가 키 변경에 대한 충분한 정보를 가지고 있지 않다는 것이다.
인터넷 프로토콜(IP) 네트워크를 통한 멀티미디어 콘텐츠의 스트리밍 분배의성장하는 관심은 키 관리 시스템에 대한 필요성이 증가하게 되었다. 그러한 스트리밍 분배 시스템은 캘리포니아, 샌디에고에 있는 에어로캐스트사(Aerocast, Inc)에 의해 개발된 Aerocast NetworkTM이다. 도 1을 참조하여 논의된 바와 같이, 현존하는 단계 1 에어로캐스트 네트워크가 콘텐츠의 전송을 활용하고 있다고 할지라도, 네트워크에 대한 보안 및 키 관리가 부족하다.
도 1은 통신 네트워크를 통한 콘텐츠의 스트리밍을 활용하기 위한 네트워크(100)(에어로캐스트에 의한)의 블럭도이다. 다른 컴포넌트중에서, 네트워크(100)는 소비자(116)용 콘텐츠를 생성하기 위한 콘텐츠 제공자(102), 콘텐츠가 스트리밍되는 인터넷(114) 및 콘텐츠 제공자(102)가 콘텐츠를 공개하는 중앙 서버(104)를 포함한다. 중앙 서버(104)는 콘텐츠 정보를 저장하기 위한 데이터베이스(108)와, 데이터베이스(108)를 검색하기 위한 검색 엔진(110)을 포함한다. 네트워크(100)는 예비 센터(106)와, 캐싱 서버들(112, 113, 115)을 더 포함한다.
구동시, 콘텐츠 제공자(102)에 의해 콘텐츠를 억세스하기를 원하는 소비자(116)는 가장 근접한 캐싱 서버, 본 경우에는 캐싱 서버(115)로부터 콘텐츠를 스트리밍한다. 캐싱 서버들이 없는 종래의 시스템에서, 그러한 콘텐츠 스트림을 원하는 소비자(116)는 콘텐츠 제공자(102)로부터 직접적으로 콘텐츠를 취득한다. 콘텐츠 품질이 빈약한 결과를 초래함은 물로느 부적절한 대역폭과 관련된 지연이 발생할 수도 있다. 캐싱 서버들을 이용함으로써, 네트워크(100)는 콘텐츠 제공자(102)로부터 디지털 콘텐츠의 직접적인 스트리밍과 관련된 단점을 방지한다.캐싱 서버(112, 113, 115)는 예를 들면, 로컬 DSL(digital subscriber line) 제공자들일 수도 있다.
네트워크(100)는 추가적인 이점을 제공한다. 콘텐츠를 검색할 때, 소비자(116)는 인터넷(114) 상의 임의의 그리고 모든 데이터베이스를 검색할 필요가 없다. 네트워크(100) 상의 모든 콘텐츠 제공자들(콘텐츠 제공자(102)를 포함)은 단일 중앙 데이터베이스(108)에 콘텐츠의 설명을 발표한다. 예를 들면, 비디오 콘텐츠의 경우, 그러한 설명들은 영화명, 배우 등을 포함할 수도 있다. 이러한 방식에서, 콘텐츠가 요구될 때, 소비자(116)는 검색 엔진(110)을 이용하여 데이터베이스(108)를 검색한다. 콘텐츠가 발견되면, 데이터베이스(108)는 이후 원하는 콘텐츠를 갖는 콘텐츠 제공자(102)로의 링크를 제공한다. 콘텐츠 제공자(102)는 소비자(116)에 의해 억세스되어 원하는 콘텐츠를 보다 상세히 억세스한다. 그러한 상세는 가격 정보 등을 포함한다.
가장 근접한 캐싱 서버들의 리스트를 콘텐츠 제공자(102)에게 제공하는 메카니즘이 제공된다. 소비자(116)의 요구에 응답하여, 콘텐츠 제공자(102)는 콘텐츠를 스트리밍하기 위해 소비자(116)에게 가장 근접한 적당한 캐싱 서버를 선택한다. 그러나, 오늘날의 에어로캐스트 네트워크 콘텐츠가 네트워크(100)에 의해 깨끗하게 스트리밍되는 것을 관측하여야만 한다. 불행하게도, 이것은 보호되지 않기 때문에, 콘텐츠는 인증되지 않은 소비자에 의해 인터셉트될 수도 있으며, 이는 콘텐츠 제공자 및 소비자들에게 실질적인 손실을 초래한다.
네트워크(100)의 단점들 중 일부는 ____자로 본 명세서와 함께 동시에 제출되었으며 공동 소유이며, 본 출원서에서 완전히 참조로서 설정된 바와 같이, ____라는 표제의 미국특허 출원번호 제____호에 의해 해소되었다. 출원번호 제____호는 스트리밍 콘텐츠에 대한 네트워크에 대한 보안을 제공하기 위한 키 관리 및 인증 시스템을 개시한다.
실시간 데이터 스트림을 수신하기 위해서는, 사용자는 통상적으로 클라이언트가 콘텐츠 제공자 서버로부터 데이터 스트림을 수신하도록 요구한다. 클라이언트가 업(up)이고 러닝(running)이고 서버와 통신될 수 있는 이후에만, 실시간 데이터 스트림을 수신한다. 클라이언트는 예를 들면, 콘텐츠 제공자들의 웹 사이트상에서 온라인으로, 또는 CD-ROM을 통해서는 오프라인으로 취득한다. 이 어느 한 경우에, 신뢰의 부족이 존재한다. 클라이언트가 취득하고 통신할 준비가 되어 있는 상태에서, 서버는 클라이언트가 인증되지 않은 사용자인지 확실하지 않다. 예를 들면, 클라이언트는 서버 이외의 소스로부터 변경되거나 취득될 수도 있다. 유사하게, 클라이언트는 의도되었던 서버와 통신중인지를 검증해야만 한다. 그러한 초기 검증 또는 인증없이, 인증되지 않은 사용자는 보안 정보에 비밀이 있을 수도 있으며 콘텐츠 소비자들에게 비교적 실질적인 손실을 초래하는 콘텐츠를 지불할 수 있다.
종래의 시스템의 추가적인 단점은 예비 서버 및 KDC(또는 일부 다른 키 관리 서버)는 단일 서버에 결합된다는 것이다. 따라서, KDC는 상이한 예비 요구사항을 가진 새로운 예비 시스템으로 변경되어야 한다.
대안적으로, 종래의 시스템은 2개의 별도 등록 스크린 -하나는 예비 서버용이고 다른 하나는 KDC용임- 을 통해 소비자가 진행해야만 하는 별개의 비통합된 예비 서버 및 KDC로 구성된다.
따라서, 네트워크(예를 들면, IP 네트워크)에서의 데이터의 통신에 관련된 상술된 문제점들을 해결할 필요가 있으며 본 발명은 이러한 필요성에 부합된다.
<발명의 요약>
본 발명의 제1 특징에 따르면, KDC(Key Distribution Center)로의 클라이언트의 공개키의 전송을 보장하는 예비 시스템이 개시된다. 등록동안, 예비 시스템은 클라이언트와 KDC간에 신뢰의 초기 설정을 허용하여 클라이언트가 콘텐츠 제공자로부터 실시간 데이터 스트림을 수신할 수 있도록 한다. KDC는 클라이언트 ID와 관련된 예비 키를 생성하고, 이후 예비 키가 예비 서버에 포워드된다. 클라이언트를 초기화하기 위한 구성 파라미터들은 예비 서버, 구성 파라미터에 포함되어 있는 예비 키에 의해 생성된다. 이들 파라미터들은 초기화를 위해 클라이언트에 의해 사용된다. 초기화시, 클라이언트는 공개 키가 KDC에 포워드되는 개인/공개 키 한쌍을 생성한다. 유리하게, 포워드될 때, 공개 키는 클라이언트에 의해 이전에 수신된 예비 키에 의해 인증된다.
본 발명의 다른 양상에 따르면, 클라이언트 공개 키의 전송을 보장하는 예비 시스템이 개시된다. 예비 시스템은 등록될 클라이언트; 클라이언트를 등록하고 고유 사용자 ID(identification)를 할당하기 위한 예비 서버; 및 사용자 ID와 관련된 예비 키를 생성하기 위한 것이며, 예비 키는 예비 서버에 포워드되는 키 분배 센터; 및 클라이언트를 초기화하기 위한 구성 파라미터를 생성하기 위한 것이며, 예비 키는 구성 파라미터내에 포함되는 예비 서버를 포함하며, 초기화시 클라이언트는 인증된 공개 키에, 키 분배 센터에 포워딩하기 위한 예비 키를 제공한다. (클라이언트가 공개/개인 키 한쌍을 취득하는 다수의 방법이 있다: 예비 단계 동안 생성할 수 있고, 스마트 카드 또는 키들과 같은 암호 표시로부터 취득할 수 있으며, 공장에서 클라이언트에게 미리 설치될 수 있다).
본 발명의 다른 양상에 따르면, 키 분배 센터는 공개 키를 저장하거나 인증서를 생성한다.
본 발명의 다른 양상에 따르면, 예비 시스템은 예비 키가 포함되어 있는 예비 티켓을 더 포함한다.
본 발명의 다른 양상에 따르면, 예비 시스템은 클라이언트에 예비 키를 포워딩하기 위한 예비 티켓을 더 포함한다.
본 발명의 다른 양상에 따르면, 본 방법은 예비 티켓이 이미 등록되어 있는 공개 키를 이용하여 인증되는 AS 요구로 취득된 티켓 허용 티켓을 더 포함하고, 이 티켓 허용 티켓은 KDC로부터 추가로 티켓을 취득하기 위한 클라이언트에 의해 사용되며, 여기서 각각의 추가 티켓은 특정 서버에 대한 억세스를 취득하기 위해 사용된다.
본 발명의 다른 양상에 따르면, 클라이언트는 클라이언트 어플리케이션이 작동하는 컴퓨터를 고유하게 식별하는 호스트 식별자를 예비 시스템에 더 제공한다.
본 발명의 다른 양상에 따르면, KDC와, 고유하게 식별가능한 사용자 ID(identification)를 갖는 클라이언트간에 신뢰를 초기에 설정하기 위한 방법이개시된다. 이 방법은 사용자 ID와 관련된 예비 키 -상기 예비 키는 예비 서버에 포워드됨- 를 KDC에 의해 생성하는 단계; 클라이언트를 등록하기 위해 예비 서버에 예비 키를 포워딩하는 단계; 예비 서버에 의해, 클라이언트를 초기화하기 위한 구성 파라미터들을 생성하는 단계; 클라이언트를 초기화하기 위해 예비 키 및 구성 파라밑들을 클라이언트에 포워딩하는 단계; 초기화시, 개인 및 공개 키 -공개 키는 키 분배 센터에 포워딩하기 위한 예비 키로 인증됨- 를 클라이언트에 의해 생성하는 단계를 포함한다.
본 발명의 다른 양상에 따르면, 본 방법은 클라이언트에 예비 키를 포워딩하기 위한 예비 티켓을 더 포함한다.
유리하게, 단일 서버에 예비 서버 및 KDC(또는 일부 다른 키 관리 서버)를 결합시키는 종래의 시스템과는 달리, 본 발명의 KDC는 별개의 것이면서도 일반적이고 서로다른 예비 요구사항에 대해 변경될 필요가 없다. 단지 예비 서버만이 필요할 때 변경될 필요가 있다. 또한, 가입자의 관점으로부터, 예비 서버를 이용하여 한번만 등록되며, 이는 차후 KDC 등록이 가입자에게 명백하기 때문이다.
도 1은 통신 네트워크를 통한 콘텐츠의 스트리밍을 활용하기 위한 네트워크의 블럭도이다.
도 2는 본 발명의 예시적인 실시예에 따라 도 1의 네트워크에 키 관리 및 보안을 적용하기 위한 ES BrokerTM프로토콜을 결합한 IPRM(Internet Protocol rightsmanagement) 시스템의 블럭도이다.
도 3은 본 발명의 예시적인 실시예에 따라 소비자(클라이언트)에 의해 키 관리가 캐싱 서버(서버)에 초기화될 때의 보안 및 키 관리 프로토콜의 하이레벨 흐름도이다.
도 4는 본 발명의 예시적인 실시예에 따라 캐싱 서버(서버)로부터 콘텐츠 제공자(클라이언트)로 키 관리가 초기화될 때의 보안 및 키 관리 프로토콜의 하이레벨 흐름도이다.
도 5는 본 발명의 예시적인 실시예에 따라 소비자에 의한 콘텐츠의 수신 및 초기 등록을 도시한 블럭도이다.
본 명세서에서 본 발명의 특징 및 이점의 추가적인 이해는 첨부된 도면 및 상세설명의 나머지 부분을 참조함으로써 구체화될 수 있다. 도면 및 청구범위를 포함하는 상세의 나머지 부분에 대한 참조는 본 발명의 다른 특징 및 이점들을 구현할 것이다. 본 발명의 추가적인 특징 및 이점들은 물론, 본 발명의 다양한 실시예의 구조 및 동작은 첨부된 도면을 참조하여 이하에 상세히 기술된다. 도면들에서, 동일한 참조 번호들은 동일하거나 기능적으로 유사한 엘리먼트를 가리킨다. 다수의 100으로 상이하게 나타난 참조 번호들은 본 발명을 수용하도록 변경된 것을 제외하고 동일하거나, 기능적으로 유사한 엘리먼트를 가리킨다.
간략하게, 본 발명의 예시적인 실시예는 KDC로의 클라이언트의 공개 키의 전송을 보장하는 예비 시스템이다. 예비 시스템은 클라이언트와 KDC(KeyDistribution Center)간의 신뢰의 초기 설정을 허용하여 클라이언트가 콘텐츠 제공자로부터 실시간 데이터 스트림을 수신할 수 있도록 한다. 물론, 콘텐츠 제공자는 또한 클라이언트 ID와 관련된 예비 키를 생성하며, 이후 예비 키는 예비 서버에 포워딩된다. 클라이언트를 초기화하기 위한 구성 파라미터들은 예비 서버에 의해 생성되고, 예비 키는 구성 파라미터내에 포함된다. 이들 파라미터들은 초기화용으로 클라이언트에 의해 사용된다. 초기화시, 클라이언트는 공개 키가 KDC에 포워드되는 개인/공개 키 한쌍을 생성한다. 공개 키는 KDC에 포워드될 때 클라이언트에 의해 이전에 수신된 예비 키와 함께 인증된다.
도 2는 본 발명의 예시적인 실시예에 따라 도 1의 네트워크(100)에 키 관리 및 보안을 적용하기 위한 ESBrokerTM프로토콜이 결합된 IPRM(Internet protocol rights management) 시스템(200)의 블럭도이다.
다른 컴포넌트들 중에서, IPRM 시스템(200)은 콘텐츠 제공자(202), 소비자(216), 인터넷(214), 예비 센터(206), 데이터베이스(208)와 검색 엔진(210) 둘다를 포함하는 중앙 서버(205), 캐싱 서버들(212, 213, 215)를 포함하며, 이들 모두는 도 1에서 대응하는 컴포넌트와 유사한 방식으로 기능한다. 또한, IPRM 시스템(200)은 소비자(216)에게 TGT(ticket granting ticket)을 발행하기 위한 AS(authentication server)를 포함하는 KDC(204), 특정 서버를 억세스하기 위한 서버 티켓을 제공하기 위한 TGS(ticket granting server)(209), 예비 서버(220) 및 빌링 센터(211)를 포함한다. KDC(204), 빌링 센터(211), 예비 센터(206) 및 중앙서버(205)는 모두 IPRM 시스템(200)내에 준비된 서비스를 활용하기 위해 중앙 유닛(218)내에 위치되어 있다.
게다가, IPRM 시스템(200)은 콘텐츠 제공자(202)에 대한 권리 관리를 관리하기 위한 IPRM 에이전트(202A), 스트리밍될 콘텐츠에 대한 인증 데이터, 및/또는 소비자 구매 결정을 정의하기 위한 세션 권리 오브젝트(202B), 캐싱 서버(212)에 대한 권리 관리를 관리하기 위한 IPRM 에이전트(212A), 캐싱 서버(213)에 대한 권리 관리를 관리하기 위한 IPRM(213A), 캐싱 서버(215)에 대한 권리 관리를 관리하기 위한 IPRM 에이전트(215A), 소비자(216)에 대한 권리 관리를 관리하기 위한 IPRM 에이전트(216A), 및 원하는 콘텐츠를 수신하기 위한 소비자(216)내의 뷰어(미도시됨)를 포함한다. 도시되지는 않았지만, 전술한 컴포넌트들은 관련 컴포넌트들내에 위치될 수도 있다. 예를 들면, IPRM 에이전트(202A)는 도시된 바와 같이, 외부보다는 콘텐츠 제공자(202)내에 위치가능하다.
알 수 있는 바와 같이, IPRM 시스템(200)은 일반적으로 캐싱 서버들(212, 213, 215)을 이용함으로써 소비자(216)에게 콘텐츠의 스트리밍을 보안 방식으로 활용하는 기능을 한다. 콘텐츠 제공자(202)는 일단 한번만 콘텐츠를 제공하고 이후 캐싱 서버들 중에서 이동될 수 있다. 캐싱 서버들에 대한 이유는 IPRM 시스템(200)의 에지에 가장 근접한 콘텐츠를 이동하기 위한 것이다. 미디어 스트리밍에 대한 고가의 하드웨어를 구매할 필요없이 스트리밍 성능을 향상시키고 더 작은 수의 콘텐츠 제공자들이 그들의 콘텐츠를 팔 수 있게 한다. 캐싱 서버들에서만 IP 멀티캐스트(네트워크 상에서 하나의 송신기와 다수의 수신기간의 통신)의 도입을 허용한다. 현재의 기술은 인터넷을 통해 IP 멀티캐스트를 갖는 것보다 로컬 억세스 네트워크에 제한된 IP 멀티캐스트를 갖는 것이 더 용이하다.
제1 실시예에 따른 본 발명은 KDC(204), IPRM 에이전트(202A, 212A, 213A, 215A, 216A)를 통해 IPRM 시스템(200)에 보안을 제공한다. KDC(204) 및 예비 센터(206)와 결합되는 IPRM 에이전트는 IPRM 시스템(200)의 모든 양상에 대한 제어 및 비공개 도구를 제공한다. 예를 들면, 소비자가 콘텐츠를 스트밍하기 위한 시스템을 활용할 수 있기 전에, 등록 처리가 필요하다. 소비자에 대한 보안 등록은 IPRM 시스템(200)에 의해 제공된다. 따라서, 동록 처리동안, 소비자(216)와 KDC(204)간에 메시지를 인터셉트함으로써 소비자(216)의 신원을 어느 누구도 복제할 수 없다. KDC(204)는 신뢰된 실체이며, 대칭 및 비대칭 알고리즘의 혼합을 이용하여 네트워크 컴포넌트에 키 분배를 제공한다.
보안이 제공된 시스템의 다른 양상은 콘텐츠가 노드들간에 통신될 때의 캐싱 서버들과 콘텐츠 제공자(202)간의 인터페이스이다. 보안이 제공되는 다른 양상은 캐싱 서버들의 설치, 콘텐츠 제공자로부터의 캐싱 서버로의 콘텐츠 전송, 캐싱 서버들간의 콘텐츠 이동, 사용 데이터의 리포트, 빌링, 소비지 프로파일 업데이트, 콘텐츠 공개 및 초기 소비자 서명이다. 표시되지는 않았지만, 본 분야의 숙련된 자라면, 본 발명의 사상 및 범위와 일치하는 다른 양상들이 보호될 수 있다는 것을 알 수 있을 것이다.
KDC(204)와 IPRM 컴포넌트는 소비자(216)에 대해 배치된 제한된 신뢰를 갖는 소프트웨어를 순수하게 보호할 수도 있고, 또는 높은 보안 레벨을 필요로 하는 저작권 소유자들로부터 고품질의 콘텐츠에 대한 권리를 취득하도록 되어 있을 수 있는 하드웨어 보안 모듈을 포함할 수 있거나, 보안이 소프트웨어 및 하드웨어 둘다의 조합을 통해 수행될 수도 있다. IPRM은 수백만의 소비자들에게 높은 확장성을 가진 인증된 키 관리 프로토콜을 이용한다. 키 관리 프로토콜은 켈리포니아 샌디에고에 있는 모토롤라사의 제품인, ESBrokerTM(Electronic Security Broker)라고 명명되며 이 상세설명 전반에 걸쳐서 참조될 것이다.
커베로스 프레임워크에 부분적으로 기초한 ESBrokerTM프로토콜은 중앙집중식 KDC(204)는 물론 개별 어플리케이션 서버와의 클라이언트 상호작용으로 구성된다. KDC 클라이언트는 KDC에 요구를 전송할 수 잇는 임의의 호스트이다. IPRM 시스템내에서, 이것은 소비자들, 캐싱 서버들 및 다른 IPRM 시스템 컴포넌트를 포함한다. 이 어플리케이션 서버는 클라이언트가 서비스 티켓(예를 들면, 캐싱 서버, 빌링 센터 등)을 요구할 수 있는 KDC에 등록된 임의의 서버이다.
본 명세서에서 사용된 바와 같이, 티켓은 KDC에 의해 클라이언트에 주어지는 인증 표시이다. 최소한, 티켓은 클라이언트의 명칭, 특정 서버의 명칭 및 세션 키(대칭 암호 키)를 포함한다. 클라이언트명 및 세션 키는 비밀로 유지될 필요가 있으며 일명 비밀 키인 다른 키로 암호화된다. 서비스 키는 티켓에 명명된 특정 서버 및 KDC에만 알려져 있는 비밀 키이다. 클라이언트가 이 서비스 키를 가지고 있지 않기 때문에, 티켓을 해독하고 그 콘텐츠를 변경할 능력을 가지고 있지 않다. 정상적으로, 클라이언트는 또한 세션 키를 알 필요가 있으며, 티켓 중에서 이를 취득할 수 없기 때문에, KDC는 클라이언트에게 동일 세션 키의 별도의 복사본을 전송한다.
티켓이 가진 메시지(예를 들면, ESBroker 키 요구 메시지)를 인증하기 위하여, 클라이언트는 세션 키로 키 설정된 체크섬(checksum)과 티켓 둘다 이 메시지내에 포함할 것이다. 티켓내에 명명된 서버가 클라이언트로부터 메시지를 수신할 때, 서비스 키를 이용하여 티켓을 해독하고, 클라이언트명을 검증하여 세션 키를 취득할 수 있다. 다음으로, 세션 키는 키잉된 체크섬을 검증하여 전체 메시지를 인증하는데 사용된다. 티켓 기반의 인증은 커베로스 IETF 표준(RFC 1510)의 일부이며 또한 ESBroker 프로토콜에 활용된다. 티켓은 유효 기판(시간 시간과 만료 시간), 다양한 플래그, 클라이언트 인증 데이터 등을 포함하는 다른 정보를 가질 수도 있다.
동일 호스트는 동시에 KDC 클라이언트 및 어플리케이션 서버 둘다 일 수 있다. IPRM 시스템(200)의 경우, 프로토콜은 일련의 메시지를 사용하여 클라이언트와 시스템의 서버 인터페이스간의 키 관리를 달성한다. 이 키 관리 프로토콜은 보안 세션을 설정하기 위한 일반적인 이용이며 IPRM 시스템에 국한되지 않는다. 이하 표 1에 나타난 메시지는 IPRM 프로토콜 메시지가 부여된 세션에 상세히 기술되어 있다.
코드 메시지 타입 설명
1 CLIENT_ENROLL_REQ client enrollment request, 클라이언트 공개 키 및 다른 속성을 포함한다.
2 CLIENT_ENROLL_REP KDC(204)로부터의 client enrollment reply는 가능한한, 공개 키에 대한 클라이언트 인증서를 포함한다.
3 AS_REQ 인증 서버로부터 티켓 허용 티켓을 요구
4 AS_REP TGT를 이용하여 인증 서버로부터 응답
5 TGS_REQ TGT 서버(209)로부터 서비스 티켓을 요구
6 TGS_REP 서비스 티켓을 이용하여 TGS 서버(209)로부터 응답
7 TKT_CHALLENGE 키 관리를 초기화하기 위해 클라이언트에게 서버 요구
8 KEY_REQ 클라이언트로부터 키 관리 요구
9 KEY_REP 어플리케이션 서버로부터 키 관리 응답
10 SEC_ESTABLISHED 보안이 설정되어 있는 어플리케이션 서버에 클라이언트로부터의 ACK
11 ESB_ERR Error reply message
12 INIT_PRINCIPAL_REQ 특정 프린서펄에 대한 예비 티켓을 생성한다. 만일 특정 프린서펄이 이미 존재하고 있지 않다면, KDC(204) 데이터베이스에서 초기화될 것이다.
13 INIT_PRINCIPAL_REP 특정 프린서펄에 대한 예비 티켓을 리턴시킨다.
14 DELETE_PRINCIPAL_REQ KDC(204) 데이터베이스로부터 특정화된 ESBrokerTM프린서펄을 삭제한다.
15 DELETE_PRINCIPAL_REP DELETE_PRINCIPAL_REQ에 대한 승인
16 SERVICE_KEY_REQ 어플리케이션 서버는 KDC(204)로부터 새로운 서비스 키를 요구한다.
17 SERVICE_KEY_REP KDC(204)는 어플리케이션 서버에 새로운 서비스 키를 리턴시킨다.
18 AUTH_DATA_REQ KDC(204)는 특정 프린서펄에 대한 인증 데이터를 요구한다. 이는 KDC(204)가 연속적으로 발행하는 티켓에 나타나게 될 인증 데이터의 일부 또는 전부일 수 있다.
19 AUTH_DATA_REP 인증 서버는 AUTH_DATA_REQ를 통해 요구된 데이터를 리턴시킨다.
동작시, 클라이언트와 서버간의 키 관리 처리는 2개의 단계로 분류된다: (1) 서버를 억세스하기 위한 서버 티켓을 취득하기 위해 KDC(204)와 클라이언트가 접촉하는 일반적인 단계; 및 (2) 클라이언트가 서버 티켓을 이용하여 서버에 KEY_REQ(key request) 메시지를 형성하는 비일반적인 단계. 이 비일반적인 단계에서, 일반적인 ESBrokerTM 키 관리 프로토콜(예를 들면, 구체적으로 IPRM 시스템용)의 특정 어플리케이션에 구체적인 정보를 포함하는 DOI(domain of interpretation)오브젝트가 취득된다. 예를 들면, 소비자(216)(클라이언트)와 캐싱 서버(215)(서버)간의 키 관리 프로세스에서, 일반적인 단계는 소비자(216)에 의해, 캐싱 서버(215)를 억세스하기 위해 KDC(204)로부터 서버 티켓을 취득하는 것을 포함한다. 비일반적인 프로세스는 캐싱 서버(215)를 억세스하기 위해 KEY_REQ 메시지를 생성하는 서버 티켓을 이용하는 것을 포함하며, KEY_REQ는 세션 권리를 포함하는 DOI 오브젝트를 포함한다. 게다가, 이 메시지는 키 관리가 시작된 서버 또는 클라이언트인지에 따라 좌우되는 프로토콜에 사용된다. 만일 시작된 서버인 경우, TKT_CHALLENGE(티켓 첼린지) 메시지는 도 1을 참조하여 보다 명확하게 나타난 바와 같이, 다른 메시지에 부가하여 사용된다.
도 3은 본 발명의 예시적인 실시예에 따라 캐싱 서버(215)(서버)에 소비자(216)(클라이언트)에 의해 키 관리가 시작될 때의 보안 및 키 관리 프로토콜의 하이레벨 흐름도이다.
도시된 바와 같이, 캐싱 서버(215)로부터 보안 방식으로 콘텐츠를 스트리밍하기를 원하는 소비자(216)는 키 관리 프로세스를 시작한다. 이것은 KDC(204)에 AS_REQ 메시지를 전송하여 캐싱 서버(215)에 대한 TGT(ticket granting ticket)를 취득함으로써 수행된다. AS_REQ 메시지는 소비자(216)의 실체, KDC(204)의 실체, 보다 구체적으로 KDC 영역 또는 관리 도메인 및 응답에 구속되어 있는 임시(nonce)를 포함한다. 소비자(216)에 의해 지원되는 대칭 암호 알고리즘을 포함할 수도 있다. 물론, 소비자(216) 및 캐싱 서버(215)는 신뢰성있는 인증자로서 작용하며 양측 모드들의 실체를 검증할 수 있는 KDC(204)에 의해 등록되어 있다고 가정된다.
나타난 바와 같이, AS_REQ 메시지에 응답하여, KDC(204)는 TGT 요구를 확인하고, 소비자(216)의 확인에 대해 예비 서버(220)으로 체크하며 이후 TGT를 포함하는 AS_REP 메시지로 응답한다. TGT의 사적 부분은 KDC(204)에만 알려진 KDC(204)의 서비스 키로 암호화됨에 유의하여야 한다. 동일한 KDC(204) 서비스 키는 또한 키잉된 해시(keyed hash)로 TGT를 인증하는데 사용된다. 소비자(216)가 KDC(204) 서비스 키를 알지 못하기 때문에, 이를 변경할 수 없으며 티켓의 사적 부분을 판독할 수 없다. 소비자(216)가 여전히 KDC(204)에 연속적인 인증에 대한 세션 키를 알 필요가 있기 때문에, 세션 키의 다른 복사본은 키 동의 알고리즘(예를 들면, Elliptic Curve Diffie-Hellman)을 이용하여 소비자(216)에게 전송된다.
TGT를 수신 및 저장한 후, 소비자(216)는 네트워크상의 스트리밍 콘텐츠를 요구하기 시작한다. TGT를 포함하는 TGS_REQ 메시지는 서버(215)를 캐싱하기 위한 티켓을 요구하는 KDC(204)(TGS 서버(209))에 전송된다. 소비자는 특정 콘텐츠 제공자에 대한 가입과 같은 추가적인 예비 동작을 수행할 수 있음에 유의하여야 한다. 또한, 소비자(216)는 바람직한 캐싱 서버의 리스트를 생성할 수도 있다.
TGS_REQ 메시지에 응답하여, 캐싱 서버 티켓을 갖는 TGS_REP 메시지는 KDC(204)로부터 소비자(216)에게 전송된다. 만일 추가적인 바람직한 캐싱 서버가 있다면, 소비자(216)는 KDC(204)에 접속하여 TGT를 이용하여 바람직한 캐싱 서버들에 대한 캐싱 서버 티켓들을 취득할 수도 있다. 이들 캐싱 서버 티켓들은 나중에 이용하기 위해 캐싱될 수도 있다. 바꾸어 말하자면, 캐싱 서버 티켓들은 적당한 캐싱 서버로부터 콘텐츠를 요구할 시 취득된다.
일부 소비자들의 경우, KDC(204)는 우선 캐싱 서버 티켓들을 발행하기 전에 가입자 인증 데이터에 대해 예비 서버(220)에 질문할 필요가 있다. 이것은 KDC(204)와 예비 서버(220)간에 AUTH_DATA_REQ/AUTH_DATA_REP 교환으로 달성된다. 사용자 인증 데이터는 티켓에 삽입가능하다. 캐싱 서버 티켓은 TGT와 같은 포맷을 가지며, -이는 캐싱 서버(215)에 인증에 사용된 세션 키를 포함한다. 티켓의 사적 부분은 KDC(204)에만 알려져 있는 캐싱 서버(215)의 서비스 키로 암호화된다. 티켓은 또한 동일한 서비스 키로 키잉된 해시(hash)로 인증된다. TGT를 갖는 경우에서와 같이, 소비자(216)는 티켓을 변경할 수 없다. 소비자(216)는 이 서버에 그체를 인증하기 위해 캐싱 서버 티켓으로부터의 세션 키를 필요로 한다. 이 세션 키의 복사본은 소비자(216)에게 전송되며, TGT 세션 키로 암호화된다.
TGS_REP 메시지에 대한 AS_REQ 메시지로 시작하는 프로세스는 상술한 일반적인 단계에 대응하며, 클라이언트는 KDC(204)와 접촉하여 서버에 억세스하기 위한 서버 티켓을 취득한다. 이것은 일반적이기 때문에, 동일한 프로세스는 콘텐츠 제공자로부터 캐싱 서버들에 콘텐츠의 전송에 대한 다른 인터페이스를 보장하고; 사용법의 리포트; 빌링(billing) 등을 수행하는데 사용된다. 게다가, 이는 불필요하거나 복잡한 옵션에 대한 필요없이 IPRM 시스템을 보다 보안처리 할 수 있다. 게다가, 복잡성의 감소로 인해, 신속한 방식으로 문제를 식별하고 정정한다.
캐싱 서버 티켓을 포함하는 TGS_REP 메시지를 수신할 시, 티켓과 함께 KEY_REQ 메시지는 캐싱 서버(215)에 전송된다. KEY_REQ 메시지는 캐싱 서버 티켓에 부가하여 메시지의 MAC(massage authentication code), DOI(domain ofinterpretation) 오브젝트 및 타임 스탬프를 포함한다. DOI 오브젝트는 이 보안 세션과 관련된 어플리케이션 특정 정보를 전송하기 위한 것이다. 본 실시예에서, DOI 오브젝트는 소비자(216)에 대한 소비자 구매 결정 정보 및 세션 권리 정보를 포함한다. DOI 오브젝트내에 세션 권리 및 구매 결정을 포함시키는 이유는 세션 권리가 특정 콘텐츠 전송 구조(캐싱 서버에 의해)에 특정되는 반면, ESBrokerTM프로토콜은 일반적인 키 관리 서비스를 제공한다. ESBrokerTM은 DOI 오브젝트에 포함된 어플리케이션 특정 정보와 함께 다른 타입의 보안 세션에 적용될 수 있다.
캐싱 서버(215)가 일반적인 KEY_REQ 메시지를 수신할 대, 비일반적인 DOI 오브젝트를 추출한다. 캐싱 서버(215)는 예를 들면, 스트리밍하기 위한 어플리케이션 특수 코드를 체크하고, DOI 오브젝트 및 인증 정보를 검증한다. 만일 세션 권리 등이 티켓내의 인증 데이터와 일치한다면, 세션 키를 포함하는 KEY_REP 메시지는 소비자(216)에게 포워드된다. 이점으로부터 양쪽 사이드들은 프로토콜 키를 가지고 스트리밍 콘텐츠와 같은 최종 메시지를 암호화하기 시작할 수 있다. 만일 인증이 실패하면, 에러 메시지가 소비자에게 포워드된다. 일부 경우에, KEY_REP 메시지는 캐싱 서버(215)가 소비자(216)에 일부 어플리케이션 특정 정보를 리턴시킬 필요가 있는 일반적인 DOI 오브젝트를 포함한다는 것에 유의하여야 한다. 예를 들면, IPRM 시스템에서, 캐싱 서버가 콘텐츠 제공자에 티켓 챌린지를 전송하여 보안 세션을 요구할 때, 세션 ID는 KEY_REP 메시지내의 DOI 오브젝트 내부에 있는 캐싱 서버에 의해 나중에 제공된다. 티켓 챌린지 메시지는 인증되지 않았기 때문에 DOI오브젝트를 포함하지 않는다.
이 단계(KEY_REQ/KEY_REP)는 클라이언트가 서버 티켓을 이용하여 서버에 키 요구를 형성하는 비일반적인 단계에 해당한다. 이 단계는 보안되는 인터페이스에 따라 DOI 오브젝트가 변화하기 때문에 비일반적인 것이다. 예를 들면, 콘텐츠 제공자로부터 캐싱 서버로의 콘텐츠의 전송에 관련된 DOI 오브젝트는 캐싱 서버로부터 가입자들로의 동일한 콘텐츠의 전송을 사용하는 것과는 상이하다.
도 4는 본 발명의 예시적인 실시예에 따라 캐싱 서버(215)(서버)로부터 콘텐츠 제공자(202)(클라이언트)로 키 관리가 시작될 때의 보안 및 키 관리 프로토콜의 하이레벨 흐름도이다.
키 관리는 콘텐츠에 대한 요구가 수신되고 캐싱 서버(215)가 요구된 콘텐츠를 가지고 있지 않을 때 캐싱 서버(215)에 의해 시작된다. 도시된 바와 같이, 키 관리는 캐싱 서버(215)로부터 콘텐츠 제공자(202)로 TKT_CHALLENGE(ticket challenge) 메시지를 전송함으로써 시작된다. TKT_CHALLENGE는 키 관리를 시작하기 위해 서버에 의해 클라이언트에 직접 향하게 함으로써 이용하기 위한 것이다.
결정 블럭(224)에서, 콘텐츠 제공자(202)가 캐싱 서버 티켓을 이전에 취득하였다면, 티켓을 포함하는 KEY_REQ 메시지를 캐싱 서버(215)로 포워드시킨다. 응답시, 캐싱 서버(215)는 이전에 상술한 바와 같이 KEY_REP 메시지를 전송한다. 한편, 결정 블럭(224)으로 되돌아 가면, 만일 콘텐츠 제공자(202)가 캐싱 서버 티켓 및 TGT 어느 것도 가지고 있지 않다면, AS_REP 메시지에 응답하는 KDC(204)에 AS_REQ를 전송한다. 만일 콘텐츠 제공자가 TGT를 갖는다면, AS_REQ/REP가 스킵된다.
이후, 콘텐츠 제공자(202)는 TGS_REQ 메시지를 KDC(204)에 전송하고 캐싱 서버 티켓을 포함하는 TGS_REP 메시지를 수신한다. 캐싱 티켓이 취득될 때, 콘텐츠 제공자(202)는 DOI 오브젝트가 없는 경우에 KEY_REQ 메시지를 전송한다. 세션 ID는 응답 또는 요구중 어느 하나 또는 둘다일 수 있으며; 세션 권리는 콘텐츠 제공자(202) 또는 캐싱 서버(215) 어느 것도 소비자가 아니기 때문에 적용되지 않는다. 일단 공유된 키가 설정되면, SEC_ESTABLISHED 메시지(미도시됨)는 콘텐츠 제공자(202)에 의해 캐싱 서버(215)에 전송된다. 서버가 키 관리를 초기화하였기 때문에, SEC_ESTABLHSHED 메시지는 보안이 설정되어 있는 서버에 알린다.
유리하게, 동일 메시지, 즉 TKT_CHALLENGE, AS_REQ/AS_REP, TGS_REQ/TGS_REP, KEY_REQ/KEY_REP, SECURITY_ESTABLISHED가 클라이언트 또는 서버가 키 관리를 시작할 것인지에 따른 다수의 프로토콜 및 시나리오에 사용된다는 것을 관측하여야 한다. 만일 서버가 키 관리를 요구하면, 모든 메시지는 TKT_CHALLENGE 메시지를 포함하여 사용된다. 바꾸어 말하자면, 만일 클라이언트가 키 관리를 시작하면, TKT_CHALLENGE 이외의 모든 메시지가 사용된다. 클라이언트가 키 관리를 시작할 때 보안이 설정된 메시지는 또한 공통적으로 스킵되는 것을 관찰하여야만 한다. 유리하게, 단일 키 관리 프로토콜이 모든 인터페이스에 대해 활용되기 때문에, 시스템이 보안될 지의 여부를 분석하기 더 용이하다. 또한, 시스템은 DOI 오브젝트 필드에만 변경하는 동일 키 관리를 갖는 빌링 데이터를 포함하는 비스트림 콘텐츠 및 스트리밍 콘텐츠 둘다를 보안처리한다.
도 5는 본 발명의 예시적인 실시예에 따라 소비자(216)에 의해 콘텐츠의 수신 및 초기 등록을 도시한 블럭도이다.
캐싱 서버(215)로부터 콘텐츠를 수신하기를 원하는 새로운 소비자(216)는 중앙 유닛(218)를 이용하여 초기에 사인할 수도 있다.
블럭(502)에서, 웹 브라우저를 이용하는 소비자(216)는 중앙 유닛(218)에 의해 제공된 웹 사이트(미도시됨)를 억세스한다. 소비자(216)는 초기 사인-업(sign-up) 및 소프트웨어 다운로드 페이지에 도착해서, 임의의 IPRM 컴포넌트를 포함하는 뷰어 어플리케애션을 다운로딩 및 설치한다. 대안적으로, 뷰어 어플리케이션 및 IPRM 컴포넌트는 CD-ROM과 같은 착탈가능한 미디어를 이용하여 소비자들에게 분배될 수 있다.
블럭(504)에서, 소비자는 예비 서버(220)를 이용하여 SSL(secured soket layer) 세션을 시작하는 뷰어를 구동함으로써 등록 처리를 시작한다. 세션이 구동되는 동안, 중앙 유닛은 그 인증서를 클라이언트에 전송하여 클라이언트가 중앙 유닛의 실체를 확인할 수 있게 한다. 이 인증서는 중앙 유닛의 공개 키를 포함하고 클라이언트(예를 들면, 베리사인(verisign))에 의해 신뢰성이 확인된 공지의 증명국(certification authority)에 의해 정상적으로 사인될 수 있다. 클라이언트는 중앙 유닛 인증서를 확인할 수 있으며, 이는 공지의 증명국의 공개 키로 미리 구성되기 때문이다. SSL 세션이 시작된 후, 소비자(216)는 사인업(signup) 형식을 채우고, 이는 사용자 ID에 대한 폼을 포함한다. 대안적으로, 사용자 ID는 중앙 유닛(218)에 의해 자동적으로 할당될 수도 있다. 다음으로, 소비자(216)는 로컬호스트 식별자를 결정하고 이를 다른 정보와 함께 예비 서버(220)에 전송한다(뷰어에 의해 명백하게 수행된다).
블럭(506)에서, 예비 서버(220)는 사용자 ID를 추출하고 이를 ESBrokerTM프린서펄 명칭으로 변환한다. 이 프린서펄 명칭은 IPRM 시스템(200)에 참가하는 고유하게 명명된 소비자이거나 서버예이다. 이 경우, 뷰어 프린서펄 명칭은 그 뷰어에 할당된 가입자 id와 동일하다. 사용자 ID가 ESBrokerTM프린서펄 명칭으로 변환된 후, 예비 서버(220)는 KDC(204)에 INIT_PRINCIPAL_REQ를 전송하여 새로운 ESBrikerTM프린서펄을 KDC(204) 데이터베이스(미도시됨)내에 생성한다. 이 메시지는 또는 소비자(216)에 대한 호스트 식별자를 포함한다.
블럭 508에서, KDC(204)는 소비자(216)용 예비(provisioning) 키(세션 키)를 포함하는 예비 티켓을 발생시킨다. 예비 키는 본 발명의 일 실시예에서 대칭 키일 수 있다. 예비 키는 KDC(204) 자체와 소비자(216) 간의 메시지 인증을 위해 KDC(204)에 의해 사용된다. 이후, 예비 티켓은 SKS(Session Key Seed)와 함께 예비 서버(220)에 복귀한다. 소비자(216)가 예비 키(KDC(204) 키로 암호화된)로의 액세스를 갖지 못하기 때문에, SKS는 예비 티켓내의 위치하는 예비 키를 재구성하기 위해 소비자(216)에 의해 사용된다.
블럭 510에서, 예비 티켓에 덧붙여, 사용자 ID, (티켓의 비암호화된 부분에 이미 포함된) 티켓 만료 시간, KDC(204)명 및/또는 어드레스 등, 및 ESBrokerTM을포함하는 (선택적인) 소프트웨어 컴포넌트를 포함하는 구성 파라미터들은 소비자(216)에 의해 다운로드된다. 소프트웨어 컴포넌트가 Aerocast 네트워크에서의 경우와 같이 등록 절차 이전에 다운로드될 수 있다.
블럭 512에서, ESBrokerTM데몬(daemon)은 다운로드된 구성 파라미터들을 이용하여 초기화된다. 이 지점에서, 소비자(216)는 특정 캐싱(caching) 서버로부터 콘텐츠를 수신하고자 한다.
블럭 514에서, 소비자(216)와 KDC(204)간의 AS_REQ 메시지를 인증하기 위한 공개/사설 키 쌍이 발생된다. 공개 키는 소비자(216)로부터 KDC(204)로 전송된다. 이는 CLIENT_ENROLL_REQ 메시지를 이용하여 수행된다. 메시지는 소비자(216)에 의해 SKS로부터 유도된 예비 키로 (대칭적으로)서명된 공개 키를 포함한다. 예비 티켓내에서 예비 키로의 액세스를 갖지 못하기 때문에, 소비자(216)는 단방향 함수를 이용하여 SKS로부터 예비 키를 유도한다.
티켓 및 예비 키를 소프트웨어 클라이언트에게 분배하는데 있어서의 문제는 소프트웨어 클라이언트가 티켓 및 키를 권한이 없는 소프트웨어 클라이언트로의 전송을 위해 복사된다는데 있다. 이런 문제를 지향하기 위해, 소비자(216)는 실제 예비 키 대신에 SKS를 수신한다. 단방향 함수를 이용하여 SKS를 고유 호스트 식별자와 결합하면 예비 키가 발생된다. 호스트 식별자는 로컬 하드웨어 구성에 기초한 소비자의 소프트웨어에 의해 자동으로 결정되는 값이어야만 한다. 호스트 식별자의 선택은 해커가 변경하는데 매우 어렵도록 되어야 한다. 예컨대, 이는 CPU 일련 번호 또는 하드웨어와 연관된 수정가능하지 않은 식별자의 다른 타입일 수 있다. SKS 및 이런 호스트 식별자로부터 유도된 결과적인 세션 키는 특정 호스트에 특정될 것이고, 그 밖의 어디에서나 사용될 수 없다. 본 실시예에서, 소비자(216)는 예비 키를 재생하기 위해 다음의 함수를 실행한다:
예비 키 = SKGen(호스트 ID, SKS):
여기서, SKGen()이 단방향 함수인 경우; SKGen-1은 상당한 시간량내에서 (예컨대, 티켓 수명 보다 적은) 계산될 수 없다.
블럭 516에서, CLIENT_ENROLL_REQ 메시지 수신시, KDC(204)는 요청을 검증하기 위하여 그 로컬 데이터베이스에서 소비자(216)를 찾는다. 요청이 유효하다면, KDC(204)는 KDC상에서 국부적으로 위치할 수 있는 클라이언트 데이터베이스 또는 보안 액세스를 갖는 몇가지 다른 원격 로케이션중 어느 하나에서 공개 키를 저장한다. 대안적으로, KDC(204)는 소비자(216)에게 전송하기 위한 공개 키를 갖는 인증서를 발생시킨다. 키가 저장되는 것을 응답확인하는 (또는 클라이언트 인증서를 선택적으로 포함하는) 메시지 CLIENT_ENROLL_REP는 소비자(216)에게 전송된다.
블럭 518에서, 소비자(216)는 지금 등록되고, 콘텐츠 제공자(202)를 포함하는 여러 제공자들로부터 콘텐츠의 리스팅을 갖는 데이터베이스(208)에 웹 사이트(도시 안됨)를 접촉시킨다. 소정의 콘텐츠가 위치될 때, 소비자(216)는 콘텐츠 제공자(202)에게 다시 향하게 된다.
블럭 520에서, 소비자(216)는 캐싱 서버의 양호한 리스트, 가입된 서비스의리스트, 콘텐츠에 지불하는 능력 등에 다시 향하며 전달하는 콘텐츠 제공자(202)와 접촉한다.
블럭 522에서, 콘텐츠 제공자(202)는 특정 소비자 및 서비스의 상황에 의존하는 구매 옵션의 최적화된 서브세트를 제공한다. 예컨대, 가격 선택 스크린은 이런 서비스에 이미 가입된 소비자에 대해서는 바이패스된다.
블럭 524에서, 콘텐츠 제공자(202)는 소비자(216)에 의해 선택된 구매 옵션, 콘텐츠 액세스 규칙의 선택적인 세트(예컨대, 정전 지역) 및 선택된 콘텐츠에 대한 기준을 캡슐화하는 세션 권리 오브젝트(session right object)를 발생시킨다. 예컨대, 세션 ID는 콘텐츠 제공자로부터 이들 세션 권리를 요청할 때 소비자(216)에 의해 발생되는 랜덤 수이다. 이들 세션 권리가 더 이상 유효하지 않는 종료 시간, 제공자 ID, 구매옵션이 소비자(216)에 의해 선택된다.
콘텐츠 액세스 규칙의 세트는 콘텐츠를 갖는 캐싱 서버(215)에 직접 전달되기 때문에 선택적이다. 더욱이, 캐싱 서버(215)는 다수의 소스들로부터 부가적인 콘텐츠 액세스 규칙을 선택적으로 모을 수 있다. 예컨대, 액세스 네트워크 제공자(예컨대, 케이블 시스템 조작자)는 그 네트워크를 통한 전달을 위한 몇몇 제약을 부가한다.
블럭 526에서, 콘텐츠 제공자(202)는 적당한 캐싱 서버에 소비자(216)를 다시 향하게 한다. 이 경우, 콘텐츠는 소비자(216)에 가장 가까운 캐싱 서버(215)로부터 스트리밍된다. 소비자(216)가 서명할 때 캐싱 서버(215)용 캐싱 서버 티켓을 이전에 캐시한다면, 그 티켓을 검색한다. 캐싱된 티켓이 없다면, 정정된 캐싱 서버 티켓을 얻기 위해 TGT를 이용하여 KDC(204)에 접촉한다.
블럭 528에서, 소비자(216)는 캐싱 서버 티켓을 이용하여 캐싱 서버(215)에 그 자신을 인증하며, 동시에(동일 KEY_REQ 메시지에서) 콘텐츠 제공자(202)로부터 얻어진 세션 권리 오브젝트를 캐싱 서버(215)로 전송한다. 소비자(216)와 캐싱 서버(215)간의 통신은 상기 KEY_REQ/KEY_REP 메시지를 이용하여 달성된다.
블럭 530에서, 캐싱 서버(215)는 티켓에 포함된 소비자(216)의 권한 및 세션 권리 오브젝트에서 사용자 선택(소비자에 의해 선택된 구매 옵션)에 대한 세션 권리 오브젝트로부터 액세스 규칙을 체크한다. 권한부여(entitlements)는 기본적으로 콘텐츠에 대한 액세스를 허용하는 소비자(216)에 특정된 권한 데이터이다.
콘텐츠 액세스 규칙은 캐싱 서버(215)에 의해 국부적으로 저장되며 세션 권리 오브젝트에 존재하지 않는다. 액세스 규칙은 권한 데이터 및 세션 권리 오브젝트에 포함된 사용자 선택(소비자에 의해 선택된 구매 옵션)에 대해서 체크된다.
블럭 532에서, 액세스가 승인된다면, 소비자(216) 및 캐싱 서버(215)는 콘텐츠의 전달을 위한 CEK(Content Encryption Key)와 협상한다.
블럭 534에서, 소비자(216)는 암호화된 RTSP 커맨드를 캐싱 서버(215)에 발부하기 시작하여 콘텐츠의 기술(RTSP URL)을 얻고 콘텐츠 재생을 요청한다.
블럭 536에서, 캐싱 서버(215)는 RTSP 커맨드를 수신하고, 이를 디코딩하며 암호화된 RTSP 응답을 복귀한다. RTSP 커맨드가 특정 URL을 재생을 요청할 때, 캐싱 서버(215)는 특정된 URL이 이런 보안 세션(세션 ID에 의해 식별되는)용 세션 권리 오브젝트에서 특정되는 것임을 입증한다.
블럭 538에서, RTSP URL 재생 요청 수신 후, 캐싱 서버(215)는 암호화된 RTP 패킷을 전송하기 시작하며, 캐싱 서버(215) 및 소비자(216) 모두는 주기적으로 암호화된 RTCP 리포트 패킷을 전송한다. 동일한 스트리밍 세션 및 특정 RTSP URL과 연관된 모든 RTP 및 RTCP 패킷은 단일 세션 ID와 연관된 동일 세트의 키를 이용하여 암호화되며, 이런 세션 ID는 캐싱 서버(215)가 소비자(216)로부터 암호화된 RTSP 메시지를 수신하기 시작할 때 기록된다.
블럭 540에서, 소비자(216)는 콘텐츠를 암호해독 및 재생한다. 동시에, 소비자(216)는 이런 스트리밍 세션에 할당된 세션 ID와 연관된 동일 세트의 키를 이용하여 계속해서 암호화된 부가적인 RTSP 커맨드를 발부한다(예컨대, 콘텐츠의 재생을 일시정지 또는 재시작). 캐싱 서버(215)는 콘텐츠를 누가 보는지, 콘텐츠를 얼마나 보는지, 어떤 메카니즘 하에서 콘텐츠가 구매되는지에 관한 정보를 끊임없이 얻는다. 이런 정보는 소비자(216) 또는 광고주로 향하는 요금청구 목적에 사용된다. 이롭게, 본 시스템은 여러 제공자들로부터 다수의 콘텐츠를 통해 한번만 기입되는 신용카드 번호와 같은 요금청구 정보로 손쉬운 변이를 가능하게 한다. 콘텐츠가 요청될 때, 소비자에 대한 정보는 콘텐츠 제공자에게 명확히 송신된다. 소비자 경험은 다수의 액세스가 다시번호매길 필요가 없기 때문에 비교적 손쉽다.
IPRM 프로토콜 메시지
다음은 표 1에 리스트된 초기 등록 프로세스에 채용된 예시적인 ESBrokerTM메시지이다. 다른 ESBrokerTM메시지는 이하 본 발명에 참고로 합체되는 미국특허출원(명칭: 키 관리 프로토콜 및 보안 인터넷 프로토콜 권리 관리 아키텍쳐용 인증서 시스템)에 개시된다.
메시지 CLIENT_ENROLL_REQ
메시지 CLIENT_ENROLL_REQ는 공개 키를 업데이트하거나 KDC(204) 데이터베이스에 아직 없으며 대응하는 디지털 인증서를 갖지 않은 새로운 공개 키를 특정하길 원하는 클라이언트에 의해 KDC(204)로 전송된다. 이 메시지는 예비 키(예비 티켓에서의 세션 키)로 키잉(keying)되는 체크섬(checksum) 및 예비 티켓으로 인증된다. (이런 키잉된 체크섬을 발생시키기 위하여, 클라이언트는 예비 티켓의 외부에서 이런 세션 키의 제2 사본을 획득해야만 한다.) 예비 서버는 INIT-PRINCIPAL_REQ 메시지를 이용하여 몇몇 ESBrokerTM대신에 예비 세션 키의 제2 사본 및 예비 티켓을 획득한다. 예비 서버는 예비 티켓 및 대응하는 예비 키의 제2 사본을, 이런 CLIENT_ENROLL_REQ을 발생시키는 소비자(216)에게 전송하는 대역외(out-of-band) 방법을 사용한다.
클라이언트는 또한 어느 타입의 KDC(204) 인증서가 수용되는 지를 특정한다. 대응하는 속성(KDC 인증서 타입)이 존재하지 않으면, 소비자(216)는 KDC(204) 인증서들중 어떤 종류를 지원하지 않는다(이경우, 클라이언트에는 인증서없이 KDC 공개 키가 제공된다).
이런 메시지 수신시, KDC(204)는 클라이언트 공개 키를 저장하며 이런 공개 키를 유효하게 하는 인증서 또는 모두를 소비자에게 발부해야만 할지를폴리시(policy)에 기초하여 결정한다. KDC(204)는 또한 어떤 타입의 인증서가 발부되는지를 결정한다. 클라이언트는 그 자신의 인증서를 자세히 조사할 필요가 없기 때문에, KDC(204)에 의해 발부된 인증서 종류에 대해 무관심하다. 소비자가 인증서를 발부받을 때, 이를 오페이크 블락(opaque blob)으로 처리한다. 클라이언트는 그 자신의 인증서를 저장하는데만 책임이 있다. 다음은 CLIENT_ENROLL_REQ 메시지의 속성이다.
속성 설명
Ctime 클라이언트의 호스트상의 현재 시간
PublicKeyInfo 이런 클라이언트로부터 AS_REQ 메시지상의 서명을 검증하기 위해 KDC(204)에 의해 사용되는 소비자의 공개 키
KDCCertificateType 클라이언트가 (AS_REP에서) 프로세스할 수 있는 KDC(204)의 인증서 타입 식별. 이런 분야는 선택적이다; 존재하지 않으면 클라이언트는 KDC(204) 인증서를 수용하지 않는다.
ServiceTicket INIT_PRINCIPAL_REP로부터 얻어진 예비 티켓.이는 클라이언트를 식별하고, Siiignature 속성에서 키잉된 체트섬을 계산하기 위한 세션 키를 제공한다.
Signature 이런 메시지상의 키잉된 체크섬. 이미 제공된 클라이언트 대층 키로 키잉된다. 이런 클라이언트가 또한 어플리케이션 서버이라면, 이런 대칭 키는 서비스 키와 동일하다.
메시지 CLIENT_ENROLL_REP
이 메시지는 CLIENT_ENROLL_REQ에 대한 응답이다. 이는 클라이언트 공개 키가 업데이트됐는지 응답확인하거나 또는 공개 키에 대한 신 클라이언트 인증서를 특정하며, 또는 이둘 모두를 행한다. 이런 메시지를 전송하기 이전에 KDC(204)에 의해 취해진 액션은 구성된 폴리시에 기초한다. 이런 메시지는 요청을 인증하는데 사용되는 동일한 예비 키를 이용하여 키잉된 체트섬으로 인증된다. 표 3은 이런 메시지에 대한 속성이다.
속성 설명
Cname 클라이언트의 주요한 식별자의 이름 부분
Crealm 클라이언트의 주요한 식별자의 영역 부분
ClientInfoUpdated 이는 불린 플래그이다:1 = 그 데이터베이스로 클라이언트 정보가 업데이트된 KDC(204)0 = 업데이트되지 않은 데이터베이스 - 클라이언트는 발부된 인증서를 항상 사용해야 한다.
EndTime 이 필드 클라이언트의 공개 키의 만료 시점을 특정한다. 이후, KDC(204)는 댜응하는 사설 서명 키를 갖는 서명을 더 이상 수용하지 않는다. 클라이언트가 인증서를 발부하는 경우, 인증서 만료 시점은 이 값과 동일해야 한다. 이런 필드의 값은 키가 만료 시점을 갖지 않는다는 것을 의미하는 0이다.
CertificateChain 이 체인은 특정된 공개 키에 대한 KDC(204)에 의해 발부된 클라이언트 인증서상에서 종료된다. 체인에서 다른 인증서(만약 있다면)는 다른 영역에서 KDC(204)로 AS_REQ를 발부할 때 클라이언트 인증을 완료할 필요가 있다.
Signature 이런 메시지를 통한 키잉된 체크섬. 예비 키 - CLIENT_ENROLL_REQ에서 예비 티켓으로부터의 세션 키 -로 키잉된다.
메시지 INIT_PRINCIPAL_REQ
메시지 INIT_PRINCIPAL_REQ는 관리 특권을 갖는 특정 클라이언트 프린서펄(principaal)에 의해 KDC(204)로 전송될 수 있으며, KDC(204) 데이터베이스에서 새로운 ESBrokerTM프린서펄 엔트리를 활용하도록 사용된다. 동일한 프린서펄 이름을 갖는 엔트리가 이미 존재한다면, 예비 티켓만이 발부된다.
이런 메시지의 주된 목적은 KDC(204) 관리를 자동화하며, 이를 외부 예비 시스템에 통합하고자 하는 것이다. KDC(204) 데이터베이스에서 프린서펄 엔트리가 암호 키와 티켓 발부와 연관된 폴리시만을 포함한다. 부가적인 가입자 정보를 유지하는 KDC(204) 외부에, 부가 데이터베이스가 있을 수 있다. 이런 메시지는 이런 다른 외부 데이터베이스용 관리 클라이언트가 외부 데이터베이스에서 새로운 가입자에 대응하는 KDC(204)에서 엔트리를 자동적으로 생성하게 한다.
또한, 기존의 프린서펄이 KDC(204) 데이터베이스에서 공개 키를 변경하고자 한다면, 새로운 예비 티켓을 발생시키기 위하여 예비 시스템이 이 요청을 전송하게 할 필요가 있다. 예비 티켓은 통상 짧은 수명을 가지며, 보통 새로운 예비 키(예비 티켓 내부의 세션 키)는 공개 키를 업데이트하기 위하여 각각의 CLIENT_ENROLL_REQ가 필요하게 된다.
이런 업데이트가 비교적 자주 일어나지 않으며 이런 이유로 메시지가 디지털 서명으로 보호된다고 가정한다. 이는 관리 인터페이스를 단순화한다 - 관리 클라이언트는 KDC(204)에 대한 티켓을 먼저 얻는데 요구되지 않는다. 또한, 디지털 서명은 특정 관리 클라이언트가 데이터베이스 업데이트 요청을 발생시킨다는 증거를 제공한다.
이런 메시지는 또한 클라이언트의 키 동의(key agreement) 파라미터(AS_REQ와 유사)를 포함한다. 키 동의 알고리즘은 연속적인 INIT_PRINCIPAL_REP 메시지의 일부를 암호화하는데 사용되는 대칭적 암호화 키를 발생시키는데 사용된다(INIT_PRINCIPAL_REP는 비밀을 요구하는 예비 SKS를 포함한다).
KDC(204)는 관리 클라이언트 보다는 랜덤수들의 양호한 소스일 수 있으며, 이에 따라 이런 INIT_PRINCIPAL_REP 메시지는 임의의 비밀 키를 포함하지 않는다. 이런 새로운 프린서펄에 대해 발생될 필요가 있는 모든 비밀 키는 KDC(204)에 의해 발생된다. 표 4는 이런 메시지의 속성 리스트이다.
속성 설명
Cname KDC(204) 데이터베이스에서 초기화되는 프린서펄의 이름.이는 메시지를 전송한 것과 동일한 프린서펄임에 유의해라. 전송자의 이름은 ESBPublicKeyClientAuthenticator 내부에 있다.
Crealm KDC(204) 데이터베이스에서 초기화되는 프린서펄의 영역 부분
HostID 초기화될 클라이언트에 대한 고유 호스트 식별자. 이는 가변 길이 필드이며, 그 포맷은 특정 클라이언트 오퍼레이팅 시스템 또는 심지어 클라이언트 하드웨어 구성에 의존한다. 이런 요청이 기존의 프린서펄에 대한 것이라면, 이런 호스트 식별자는 KDC(204) 데이터베이스에서 현재 저장된 값을 대체한다.
EncTypeSet 선호 순서로 관리 클라이언트에 의해 지원되는 암호화의 타입.
KeyAgreementInfo 키 동의 알고리즘 및 알고리즘에 요구되는 속성을 기술.
ESBPublicKeyClientAuthenticator 이 속성은 관리 클라이언트 식별 및 이런 요청 메시지를 인증하는데 사용된다. 이는 클라이언트 프린서펄명, 시간 스탬프, 디지털 서명 및 선택적인 인증서 체인을 포함한다. 또한, 응답을 표시하기 위해 KDC(204)에 의해 사용되야하는 KDC(204)의 공개 키의 식별자를 포함한다.
메시지 INIT_PRINCIPAL_REP
이 메시지는 INIT_PRINCIPAL_REQ에 대한 응답이다. 새로운 프린서펄 기록이 생성되며 대응하는 예비 클라이언트를 포함하는지를 응답확인한다. 응답은 또한 키 동의 알고리즘을 이용하여 암호화된 티켓의 사설 부분을 포함하여, 클라이언트가 이런 티켓 내에서 세션 키를 알게 한다. AS_REP 및 TGS_REP 메시지의 경우와 같이, 응답의 암호화된 부분이 실제 세션 키 대신에 SKS(Session Key Seed)를 포함함에 유의해라. 초기화될 클라이언트(이런 응답을 수신하는 관리 클라이언트가 아닌)는 SKS 및 그 호스트 식별자로부터 세션 키를 재구성하도록 기대된다.
특정된 이름을 갖는 프린서펄 기록이 이미 존재한다면, 이런 메시지는 기존의 프린서펄에 대해 생성된 새로운 예비 티켓을 특정한다. 이런 티켓이 만료되기전에, CLIENT_ENROLL_REQ를 인증하기 위해 티켓에 특정된 프린서펄에 의해 사용되야 한다. 이런 메시지는 KDC(204)의 사설 키를 이용하여 디지털 서명으로 인증된다. 표 5는 이런 메시지의 속성 리스트이다.
속성 설명
ServiceTicket CLIENT_ENROLL_REQ 메시지를 인증하는데 사용되는 예비 티켓. 이런 티켓에서 서버 프린서펄 이름은 'ESBadmin'(인용없이 취함)이다.
EncryptedData 이런 필드는 세션 키의 예외로 예비 티켓에서 PrivateTicketPart와 동일한 정보를 포함한다 - 이는 SKS로 대체된다. 암호화된 데이터는 PrivateTicketPart이며 키 동의 알고리즘으로부터 유도된 대칭 키로 암호화된다.
KeyAgreementInfo 키 동의 알고리즘의 타입 및 알고리즘의 공개 속성을 기술.
ESBPubKeyKDCAuthenticator 디지털 서명 및 선택적인 인증서 체인을 갖는 KDC(204) 인증
INIT_PRINCIPAL_REP의 생성
INIT_PRINCIPAL_REQ 프로세싱이 임의의 에러를 발생시키지 않는다면, KDC(204)는 다음의 절차를 이용하여 INIT_PRINCIPAL_REP를 발생시킨다: (1) INIT_PRINCIPAL_REQ 메시지로부터의 STID 헤더 필드는 요청에 결합되도록 INIT_PRINCIPAL_REP에서 DTID 헤더 필드로 복사된다; (2) KDC(204)는 이에 의해 지원되는 암호화 방법의 리스트를 갖는 EncTypeSet 필드에서 방법의 리스트의 교차점에 기초하여 랜덤한 예비 티켓 세션 키의 타입을 할당한다. 이런 교차점이 하나 이상의 암호화 알고리즘을 포함한다면, KDC(204)는 가장 강력한 것을 선택한다.
본 명세서에 사용되는 바와 같이, STID(Source Transaction Identifier)는키 관리 메시지의 기폭제에 의해 선택된 고유 랜덤 값이다. 이는 요청/응답 쌍을 정합시키는데 사용된다. 응답자는 STID를 취하고 헤더에서 DTID 필드에 이를 둔다. 원 요청의 전송자가 응답을 얻을 때, 응답에서 DTID가 원 STID 값에 대해 정합되는 것을 검증한다. DTID(Destination Transaction Identifier)는 응답 메시지에서 사용되는 값이며, 그래서 원 요청은 빈 DTID를 가진다. 응답자는 요청으로부터 STID를 취하고 이를 응답에서 DTID에 둔다. 보다 복잡한 4-메시지 트랜젝션의 경우, 예컨대, 메시지 #2는 채워지는 STID 및 DTID 모두를 가진다. DTID는 이전 메시지로부터의 STID이며, STID는 다음 메시지 #3에 이 메시지를 정합시키는데 사용되는 몇가지 새로운 랜덤 값이다.
단계(3)은 SKS를 랜덤하게 발생시킨다. SKS는 예비 티켓 세션 키와 동일한 크기를 가진다. (4) 이전 단계에서 발생된 특정 KDC(204) 클라이언트 및 SKS에 대한 호스트 ID를 이용하여, 세션 키 = SKGen(호스트 SKS, ID)를 계산한다. (5) KDC(204)는 예비 티켓을 발생시킨다. (6) KDC(204) 비밀 키는 암호화된 티켓 부분을 암호화하는데 사용되며, 또한 전체 티켓을 통해 키잉된 체크섬을 발생시킨다. 티켓에서 서버 프린서펄 명은 'ESBadmin'(인용없이 취함)이다. 티켓에서 클라이언트명은 INIT_PRINCIPAL_REQ에서 특정되며, 이는 INIT_PRINCIPAL_REQ 메시지를 전송하는 관리 클라이언트의 명과 동일하지 않다. 티켓의 종료 시간은 KDC(204)에 의해 결정된다.
단계(7)은, INIT_PRINCIPAL_REQ로부터의 EncTypeSet 필드는 키 동의 알고리즘으로부터 유도된 키의 타입을 선택하기 위해 KDC(204)에 의해 사용되며, 그후 응답의 EncryptedData 부를 암호화하는데 사용된다. 리스트에 하나 이상이 있다면, KDC(204)는 지원하는 EncTypeSet에서 가장강력한 암호화 타입을 선택해야만 한다. (8) 응답의 암호화 부분은 세션 키 속성이 (티켓에 있는 실제 세션 키 대신에)SKS의 값을 포함하는 것을 제외하고, 예비 티켓의 PrivateTicketPart와 동일한 정보를 포함한다.
단계(9)는, INIT_PRINCIPAL_REQ 메시지를 인증하기 위하여 ESBPubKeyKDCAuthenticator를 발생시킨다. INIT_PRINCIPAL_REQ 메시지의 발생이 본 실시예에 대해서 특히 설명된다 할지라도, 본기술 분야의 당업자에게는 본 발명의 정신 및 범위 내에서 다른 실시예에도 적용가능하다는 것을 이해할 것이다. 더욱이, INIT_PRINCIPAL 메시지의 발생은 ESBrokerTM에 특정된 적당한 변화가 이루어진다 하더라도, 다른 ESBrokerTM메시지의 발생과 유사하다.
INIT_PRINCIPAL_REP의 프로세싱
관리 클라이언트는 INIT_PRINCIPAL_REP를 프로세싱하기 위해 다음의 절차를 채용한다. 클라이언트가 에러 메시지를 서버에 다시 전송하지 않음에 유의해라. 몇몇 경우, 클라이언트는 다른 INIT_PRINCIPAL_REP로 다시시도한다: (1) 메시지 헤더는 자세히 조사된다. 헤더 세밀 조사가 실패하면, 이 응답은 수신되지 않는다고 가정한다(소정의 미결정 INIT_PRINCIPAL_REPs이 있다면, 시간 종료 및 재시도 할때까지 응답을 계속해서 대기한다). (2) 헤더에서 프로토콜 버전 수가 검증된다. 이런 프로토콜 버전이 지원되지 않으면, 메시지가 수신되지 않는다고 가정한다.(3) 클라이언트는 이런 응답에서 DTID 헤더 필드를 정합시키는 STID 값을 갖는 미결정의 INIT_PRINCIPAL_REQ 메시지를 찾는다. 정합이 없다면, 클라이언트는 메시지가 수신되지 않았다 하더라도 진행한다. (4) 메시지의 나머지가 자세히 조사된다. 메시지 포맷이 불법인 것으로 밝혀지면, 메시지가 수신되지 않았다고 가정한다.
단계(5)에서, ESBPubKeyKDCAuthenticator가 프로세싱된다. (6) 관리 클라이언트는 키 동의 알고리즘을 이용하여 응답에서 PrivateTicketPart를 암호해독한다. 관리 클라이언트가 특정 암호화 타입을 지원하지 않기 때문에 PrivateTicketPart이 암호해독될 수 없다면, 치명적인 에러가 사용자에게 리포트되며, 클라이언트는 다시시도하지 않는다. 결과적인 클리어 텍스트가 포맷팅 에러를 포함하거나 또는 요청을 정합하지 않는 클라이언트 식별자를 포함한다면, 치명적인 에러는 사용자에게 리포트되고 관리 클라이언트는 다시시도하지 않는다.
단계(7)에서, 관리 클라이언트는 예비 티켓 및 암호화된 PrivateTicketPart를, 티켓이 발부되는 클라이언트 프린서펄에 전송한다. 정보를 전송하는데 사용되는 방법은 ESBrokerTM에 대한 범위를 벗어난 보안 인터페이스를 사용한다. 예컨대, 웹 클라이언트에서, SSL을 통한 HTTP일 수 있다. INIT_PRINCIPAL_REQ 메시지의 프로세싱이 본 실시예에 대하여 특히 설명된다 할지라도, 본 기술 분야의 당업자에게는 본 발명의 범위 및 정신을 벗어남이 없이 다른 실시예게 적용가능하다는 것을 이해할 것이다. 더욱이, INIT_PRINCIPAL 메시지의 프로세싱은, ESBrokerTM메시지에 특정된 적당한 변경이 이루어진다 할지라도, 다른 ESBrokerTM메시지의 발생과 유사하다. 예컨대, 인증 서버로부터 티켓 교부를 요청하는 AS_REQ 메시지는 INIT_PRINCIPAL_REP 메시지에 대해 상술한 바와 같이 유사한(몇가지는 다른) 발생 및 프로세싱 프로세스를 채용한다. 이런 방식으로, 본 발명은 사용자 인증을 가능하게 하는 사용자 시스템의 고유 온라인 예비를 제공한다.
전술한 바는 본 발명의 예시적 특정 실시예의 완전한 설명이지만, 부가적인 실시예도 또한 가능하다. 예컨대, 유사한 예비 시퀀스가 IPRM 네트워크내에서 소비자뿐만 아니라 다른 KDC(204) 클라이언트도 등록하는데 이용될 수 있다는 것을 알 수 있다. 이러한 클라이언트의 예는 콘텐츠 제공자(102), 캐싱 서버 또는 본 발명의 범주 및 사상내에서의 다른 클라이언트등이다. 따라서, 전술한 설명은 본 발명의 범위를 제한하는 것으로 간주되어서는 안되며, 균등물의 그 전체 범위와 함께 부가된 특허청구범위에 의해서 한정되는 것이다.

Claims (9)

  1. 클라이언트 공개 키(public key)의 전달을 보장하는 예비(provisioning) 시스템에 있어서,
    등록될 클라이언트;
    상기 클라이언트를 등록하고, 상기 클라이언트에 고유 사용자 ID(identification)를 할당하는 예비 서버; 및
    상기 사용자 ID와 연관된 예비 키를 생성하는 키 분배(distribution) 센터 - 상기 예비 키는 상기 예비 서버에 전송됨 -
    를 포함하고,
    상기 예비 서버는 상기 클라이언트를 초기화하기 위한 구성(configuration) 파라미터를 생성하고, 상기 예비 키는 상기 구성 파라미터내에 포함되며,
    초기화시, 상기 클라이언트는, 전송용 예비 키로 인증된 그 공개 키를 상기 키 분배 센터에 제공하는 것을 특징으로 하는 예비 시스템.
  2. 제1항에 있어서,
    상기 키 분배 센터는 상기 공개 키를 저장하거나 인증서(certificate)를 생성하는 것을 특징으로 하는 예비 시스템.
  3. 제1항에 있어서,
    상기 예비 키가 또한 동봉(enclose)된 예비 티켓을 더 포함하는 것을 특징으로 하는 예비 시스템.
  4. 제1항에 있어서,
    상기 예비 키를 상기 클라이언트에 전송하기 위한 예비 티켓을 더 포함하는 것을 특징으로 하는 예비 시스템.
  5. 제4항에 있어서,
    상기 예비 티켓으로 미리 등록된 공개 키를 이용하여 인증된 AS 요청(Request)으로 얻어진 티켓 승인(granting) 티켓을 더 포함하고, 상기 티켓 승인 티켓은 상기 KDC로부터 여분의 티켓을 얻기 위해 상기 클라이언트에 의해 이용되고, 상기 각각의 여분의 티켓은 특정 서버에 대한 액세스를 획득하는데 이용되는 것을 특징으로 하는 예비 시스템.
  6. 제1항에 있어서,
    상기 클라이언트는, 상기 클라이언트 어플리케이션이 실행중인 컴퓨터를 고유하게 식별하는 호스트 식별자(identifier)를 상기 예비 시스템에 더 제공하는 것을 특징으로 하는 예비 시스템.
  7. KDC(키 분배 센터)와 예비 서버에 의해 할당된 고유하게 식별가능한 사용자ID(identification)를 갖는 클라이언트간에 초기에 트러스트(trust)를 구축하는 방법에 있어서,
    상기 KDC에 의해 상기 사용자 ID와 관련된 예비 키를 생성하는 단계 - 상기 예비 키는 상기 예비 서버로 전송됨 -;
    상기 예비 키를 상기 클라이언트를 등록하기 위한 예비 서버로 전송하는 단계;
    상기 예비 서버에 의해 상기 클라이언트를 초기화하기 위한 구성 파라미터를 생성하는 단계; 및
    상기 예비 키 및 상기 클라이언트를 초기화하기 위한 구성 파라미터를 상기 클라이언트로 전송하는 단계를 포함하고,
    초기화시, 상기 클라이언트는 전송용 예비 키로 인증된 그 공개 키를 상기 키 분배 센터에 제공하는 것을 특징으로 하는 방법.
  8. 제7항에 있어서,
    상기 예비 키를 상기 클라이언트에 전송하기 위한 예비 티겟을 더 포함하는 방법.
  9. 제8항에 있어서,
    상기 예비 티켓으로 미리 등록된 공개 키를 이용하여 인증된 AS 요청으로 얻어진 티켓 승인 티켓을 더 포함하고, 상기 티켓 승인 티켓은 상기 KDC로부터 여분의 티켓을 얻기 위해 상기 클라이언트에 의해 이용되고, 상기 각각의 여분의 티켓은 특정 서버에 대한 액세스를 획득하는데 이용되는 것을 특징으로 하는 방법.
KR10-2004-7004467A 2001-09-26 2002-09-20 사용자 인증을 허용하는 사용자 단말의 고유 온라인프라비젼 KR20040037155A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/966,552 2001-09-26
US09/966,552 US20030063750A1 (en) 2001-09-26 2001-09-26 Unique on-line provisioning of user terminals allowing user authentication
PCT/US2002/030128 WO2003028330A2 (en) 2001-09-26 2002-09-20 Unique on-line provisioning of user terminals allowing user authentication

Publications (1)

Publication Number Publication Date
KR20040037155A true KR20040037155A (ko) 2004-05-04

Family

ID=25511576

Family Applications (1)

Application Number Title Priority Date Filing Date
KR10-2004-7004467A KR20040037155A (ko) 2001-09-26 2002-09-20 사용자 인증을 허용하는 사용자 단말의 고유 온라인프라비젼

Country Status (7)

Country Link
US (1) US20030063750A1 (ko)
EP (1) EP1433300A2 (ko)
KR (1) KR20040037155A (ko)
AU (1) AU2002336757A1 (ko)
CA (1) CA2461538A1 (ko)
TW (1) TW578417B (ko)
WO (1) WO2003028330A2 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010056969A2 (en) * 2008-11-14 2010-05-20 Visa International Service Association Payment transaction processing using out of band authentication

Families Citing this family (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030118188A1 (en) * 2001-12-26 2003-06-26 Collier David C. Apparatus and method for accessing material using an entity locked secure registry
US20030084171A1 (en) * 2001-10-29 2003-05-01 Sun Microsystems, Inc., A Delaware Corporation User access control to distributed resources on a data communications network
US8910241B2 (en) 2002-04-25 2014-12-09 Citrix Systems, Inc. Computer security system
US7146504B2 (en) * 2002-06-13 2006-12-05 Microsoft Corporation Secure clock on computing device such as may be required in connection with a trust-based system
US7016888B2 (en) * 2002-06-18 2006-03-21 Bellsouth Intellectual Property Corporation Learning device interaction rules
US20040059913A1 (en) * 2002-09-13 2004-03-25 Sun Microsystems, Inc., A Delaware Corporation Accessing for controlled delivery of digital content in a system for digital content access control
US7512972B2 (en) 2002-09-13 2009-03-31 Sun Microsystems, Inc. Synchronizing for digital content access control
US7398557B2 (en) * 2002-09-13 2008-07-08 Sun Microsystems, Inc. Accessing in a rights locker system for digital content access control
US20040059939A1 (en) * 2002-09-13 2004-03-25 Sun Microsystems, Inc., A Delaware Corporation Controlled delivery of digital content in a system for digital content access control
US7240365B2 (en) * 2002-09-13 2007-07-03 Sun Microsystems, Inc. Repositing for digital content access control
US7380280B2 (en) * 2002-09-13 2008-05-27 Sun Microsystems, Inc. Rights locker for digital content access control
US7363651B2 (en) 2002-09-13 2008-04-22 Sun Microsystems, Inc. System for digital content access control
US7913312B2 (en) * 2002-09-13 2011-03-22 Oracle America, Inc. Embedded content requests in a rights locker system for digital content access control
US7370212B2 (en) 2003-02-25 2008-05-06 Microsoft Corporation Issuing a publisher use license off-line in a digital rights management (DRM) system
EP1646177B1 (en) * 2003-07-11 2012-04-11 Nippon Telegraph And Telephone Corporation Authentication system based on address, device thereof, and program
US8234699B2 (en) * 2003-12-31 2012-07-31 Citrix Systems, Inc. Method and system for establishing the identity of an originator of computer transactions
US20060166742A1 (en) * 2004-12-17 2006-07-27 Daniel Willis Method for advertisement service provider wholesaling
US20060148573A1 (en) * 2004-12-17 2006-07-06 Daniel Willis Method and system for cataloging advertising spots of an advertising enabled game
US8128493B2 (en) * 2004-12-20 2012-03-06 Google Inc. Method and system for automatically managing a content approval process for use in in-game advertising
US8438645B2 (en) 2005-04-27 2013-05-07 Microsoft Corporation Secure clock with grace periods
US8725646B2 (en) 2005-04-15 2014-05-13 Microsoft Corporation Output protection levels
DE102005018676B4 (de) * 2005-04-21 2008-09-25 Wincor Nixdorf International Gmbh Verfahren zur Schlüsselverwaltung für Kryptographiemodule
US20060265758A1 (en) 2005-05-20 2006-11-23 Microsoft Corporation Extensible media rights
US7861308B2 (en) * 2005-11-28 2010-12-28 Sony Corporation Digital rights management using trusted time
US7925023B2 (en) * 2006-03-03 2011-04-12 Oracle International Corporation Method and apparatus for managing cryptographic keys
US8171302B2 (en) * 2006-05-30 2012-05-01 Hewlett-Packard Development Company, L.P. Method and system for creating a pre-shared key
US20070283003A1 (en) * 2006-05-31 2007-12-06 Broyles Paul J System and method for provisioning a computer system
JP4983165B2 (ja) * 2006-09-05 2012-07-25 ソニー株式会社 通信システムおよび通信方法、情報処理装置および方法、デバイス、プログラム、並びに記録媒体
WO2008041950A2 (en) 2006-10-04 2008-04-10 Trek 2000 International Ltd. Method, apparatus and system for authentication of external storage devices
RU2339077C1 (ru) * 2007-03-13 2008-11-20 Олег Вениаминович Сахаров Способ функционирования системы условного доступа для применения в компьютерных сетях и система для его осуществления
WO2009005698A1 (en) * 2007-06-28 2009-01-08 Applied Identity Computer security system
US8243924B2 (en) * 2007-06-29 2012-08-14 Google Inc. Progressive download or streaming of digital media securely through a localized container and communication protocol proxy
US8286082B2 (en) 2007-09-12 2012-10-09 Citrix Systems, Inc. Methods and systems for providing, by a remote machine, access to a desk band associated with a resource executing on a local machine
US8516539B2 (en) * 2007-11-09 2013-08-20 Citrix Systems, Inc System and method for inferring access policies from access event records
US8990910B2 (en) * 2007-11-13 2015-03-24 Citrix Systems, Inc. System and method using globally unique identities
CN101163010B (zh) * 2007-11-14 2010-12-08 华为软件技术有限公司 对请求消息的鉴权方法和相关设备
US9240945B2 (en) * 2008-03-19 2016-01-19 Citrix Systems, Inc. Access, priority and bandwidth management based on application identity
US8943575B2 (en) 2008-04-30 2015-01-27 Citrix Systems, Inc. Method and system for policy simulation
US8990573B2 (en) * 2008-11-10 2015-03-24 Citrix Systems, Inc. System and method for using variable security tag location in network communications
US20100268649A1 (en) * 2009-04-17 2010-10-21 Johan Roos Method and Apparatus for Electronic Ticket Processing
US20100325424A1 (en) * 2009-06-19 2010-12-23 Etchegoyen Craig S System and Method for Secured Communications
US8495359B2 (en) 2009-06-22 2013-07-23 NetAuthority System and method for securing an electronic communication
US20100325703A1 (en) * 2009-06-23 2010-12-23 Craig Stephen Etchegoyen System and Method for Secured Communications by Embedded Platforms
US8903653B2 (en) * 2009-06-23 2014-12-02 Uniloc Luxembourg S.A. System and method for locating network nodes
US8736462B2 (en) * 2009-06-23 2014-05-27 Uniloc Luxembourg, S.A. System and method for traffic information delivery
US8452960B2 (en) * 2009-06-23 2013-05-28 Netauthority, Inc. System and method for content delivery
US20100321207A1 (en) * 2009-06-23 2010-12-23 Craig Stephen Etchegoyen System and Method for Communicating with Traffic Signals and Toll Stations
US9141489B2 (en) * 2009-07-09 2015-09-22 Uniloc Luxembourg S.A. Failover procedure for server system
US8509448B2 (en) * 2009-07-29 2013-08-13 Motorola Solutions, Inc. Methods and device for secure transfer of symmetric encryption keys
CN101668046B (zh) * 2009-10-13 2012-12-19 成都市华为赛门铁克科技有限公司 资源缓存方法及其装置、系统
FR2951343A1 (fr) * 2009-10-14 2011-04-15 Alcatel Lucent Gestion de dispositif de communication a travers un reseau de telecommunications
US9083534B2 (en) 2011-01-07 2015-07-14 Mastercard International Incorporated Method and system for propagating a client identity
US9032204B2 (en) * 2011-01-07 2015-05-12 Mastercard International Incorporated Methods and systems for providing a signed digital certificate in real time
US8446834B2 (en) 2011-02-16 2013-05-21 Netauthority, Inc. Traceback packet transport protocol
US8850216B1 (en) * 2011-05-19 2014-09-30 Telefonaktiebolaget Lm Ericsson (Publ) Client device and media client authentication mechanism
US9231926B2 (en) * 2011-09-08 2016-01-05 Lexmark International, Inc. System and method for secured host-slave communication
US8949954B2 (en) 2011-12-08 2015-02-03 Uniloc Luxembourg, S.A. Customer notification program alerting customer-specified network address of unauthorized access attempts to customer account
AU2012100460B4 (en) 2012-01-04 2012-11-08 Uniloc Usa, Inc. Method and system implementing zone-restricted behavior of a computing device
AU2012100462B4 (en) 2012-02-06 2012-11-08 Uniloc Usa, Inc. Near field authentication through communication of enclosed content sound waves
US8635128B2 (en) 2012-03-06 2014-01-21 Edgecast Networks, Inc. Systems and methods for billing content providers for designated content delivered over a data network
US8862516B2 (en) * 2012-03-06 2014-10-14 Edgecast Networks, Inc. Systems and methods for billing content providers for designated content delivered over a data network
DE102012208836A1 (de) * 2012-05-25 2013-11-28 Siemens Aktiengesellschaft Verfahren und Vorrichtung zur Erzeugung kryptographisch geschützter redundanter Datenpakete
US9009854B2 (en) * 2012-12-19 2015-04-14 Intel Corporation Platform-hardened digital rights management key provisioning
AU2013100355B4 (en) 2013-02-28 2013-10-31 Netauthority, Inc Device-specific content delivery
US10122591B1 (en) * 2013-03-13 2018-11-06 Google Llc Managing access to no-cost content
CN104468074A (zh) * 2013-09-18 2015-03-25 北京三星通信技术研究有限公司 应用程序之间认证的方法及设备
US11349675B2 (en) * 2013-10-18 2022-05-31 Alcatel-Lucent Usa Inc. Tamper-resistant and scalable mutual authentication for machine-to-machine devices
US9571472B2 (en) * 2014-05-06 2017-02-14 Cryptography Research, Inc. Establishing an initial root of trust for individual components of a distributed security infrastructure

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2011396C (en) * 1989-03-03 1995-01-03 Kazue Tanaka Cipher-key distribution system
US6002768A (en) * 1996-05-07 1999-12-14 International Computer Science Institute Distributed registration and key distribution system and method
US5784463A (en) * 1996-12-04 1998-07-21 V-One Corporation Token distribution, registration, and dynamic configuration of user entitlement for an application level security system and method
US6122742A (en) * 1997-06-18 2000-09-19 Young; Adam Lucas Auto-recoverable and auto-certifiable cryptosystem with unescrowed signing keys
US6189146B1 (en) * 1998-03-18 2001-02-13 Microsoft Corporation System and method for software licensing
US6807277B1 (en) * 2000-06-12 2004-10-19 Surety, Llc Secure messaging system with return receipts

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010056969A2 (en) * 2008-11-14 2010-05-20 Visa International Service Association Payment transaction processing using out of band authentication
WO2010056969A3 (en) * 2008-11-14 2010-08-12 Visa International Service Association Payment transaction processing using out of band authentication
US8245044B2 (en) 2008-11-14 2012-08-14 Visa International Service Association Payment transaction processing using out of band authentication
US8898762B2 (en) 2008-11-14 2014-11-25 Visa International Service Association Payment transaction processing using out of band authentication

Also Published As

Publication number Publication date
WO2003028330A2 (en) 2003-04-03
EP1433300A2 (en) 2004-06-30
WO2003028330A3 (en) 2003-10-09
CA2461538A1 (en) 2003-04-03
US20030063750A1 (en) 2003-04-03
TW578417B (en) 2004-03-01
AU2002336757A1 (en) 2003-04-07

Similar Documents

Publication Publication Date Title
KR20040037155A (ko) 사용자 인증을 허용하는 사용자 단말의 고유 온라인프라비젼
KR101078455B1 (ko) 보안 인터넷 프로토콜 권한 관리 아키텍쳐에 대한 키 관리프로토콜 및 인증 시스템
US7237108B2 (en) Encryption of streaming control protocols and their headers
US7818792B2 (en) Method and system for providing third party authentication of authorization
CA2486690C (en) Association of security parameters for a collection of related streaming protocols
US7231663B2 (en) System and method for providing key management protocol with client verification of authorization
US6993652B2 (en) Method and system for providing client privacy when requesting content from a public server
US20030059053A1 (en) Key management interface to multiple and simultaneous protocols

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application