KR101132148B1 - 키 관리 프로토콜에 권한부여의 클라이언트 승인을 제공하기 위한 시스템 및 방법 - Google Patents

키 관리 프로토콜에 권한부여의 클라이언트 승인을 제공하기 위한 시스템 및 방법 Download PDF

Info

Publication number
KR101132148B1
KR101132148B1 KR1020047012068A KR20047012068A KR101132148B1 KR 101132148 B1 KR101132148 B1 KR 101132148B1 KR 1020047012068 A KR1020047012068 A KR 1020047012068A KR 20047012068 A KR20047012068 A KR 20047012068A KR 101132148 B1 KR101132148 B1 KR 101132148B1
Authority
KR
South Korea
Prior art keywords
client
ticket
copy
authorization data
content
Prior art date
Application number
KR1020047012068A
Other languages
English (en)
Other versions
KR20040101219A (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 KR20040101219A publication Critical patent/KR20040101219A/ko
Application granted granted Critical
Publication of KR101132148B1 publication Critical patent/KR101132148B1/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/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
    • 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
    • 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
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

클라이언트(102)에 액세스될 수 있으며 클라이언트에 의해 사용될 수 있는 권한부여 데이터의 카피를 제공하는 방법 및 시스템이다. 방법은 티켓들의 개념을 사용하는 키 관리 프로토콜들에 적절하다. 권한부여 데이터의 두개의 카피들, 클라이언트 카피 및 서버 카피가 클라이언트가 특정 애플리케이션 서버(106)에 대한 티켓을 요청하는 클라이언트 내에 포함되고 그로 전달된다. 클라이언트는 권한부여 데이터의 클라이언트 카피로 액세스할 수 있으며 따라서 클라이언트는 요청들을 검증할 수 있고, 요청된 콘텐트 및/또는 서비스들에 대한 사용의 권한부여를 결정할 수 있다.
키 관리 프로토콜, 애플리케이션 서버, 클라이언트 프라이버시, 클라이언트 인증, 서비스 티켓

Description

키 관리 프로토콜에 권한부여의 클라이언트 승인을 제공하기 위한 시스템 및 방법{System and method for providing key management protocol with client verification of authorization}
본 발명은 일반적으로 네트워크 보안에 관한 것으로, 더욱 구체적으로는 애플리케이션 서버로부터 콘텐트를 요청할 때 클라이언트 프라이버시를 제공하기 위한 방법 및 시스템에 관한 것이다.
인터넷은 불안정한 네트워크이다. 인터넷 상에서 사용된 많은 프로토콜들은 어떠한 보안도 제공하지 않는다. 암호화나 어떠한 다른 타입의 보안 스킴을 사용하지 않고 인터넷을 통해 전송되는 데이터는 "보통문으로(in the clear)" 전송된다고 한다. 인터넷을 통해 보통문으로 전송되는 패스워드들, 신용 카드 번호들, 클라이언트 아이덴티티 및 이름들 등과 같은 데이터를 해커들이 "탐지하는" 것을 허용하는 툴들은 쉽게 사용할 수 있다. 그러므로, 인터넷을 통해 암호화되지 않은 데이터를 보내는 애플리케이션은 매우 위험이 크다.
커르베로스(Kerberos)는 보안 키 암호화를 사용하여 클라이언트/서버 애플리케이션들에 대한 인증(authentication)을 제공하도록 설계된 알려진 네트워크 인증 프로토콜의 예이다. 메사추세스 공과 대학으로부터 사용가능한 커르베로스 프로토콜은 암호화를 사용하여 클라이언트가 불안한 네트워크 연결을 가로질러 서버로 그의 아이덴티티를 의도적으로 입증할 수 있다(그 반대도 가능하다). 클라이언트 및 서버가 그들의 아이덴티티를 입증하도록 커르베로스를 사용한 후에, 그들은 또한 그들이 그들의 비지니스를 수행하도록 프라이버시와 데이터 보전을 의도적으로 보증하도록 모든 그들의 통신들을 암호화할 수 있다.
이러한 및 다른 배경 정보 팩터들은 본 발명이 전개되는 네트워크 보안의 분야와 관련된다.
본 발명은 클라이언트에 의해 액세스될 수 있고 사용될 수 있는 권한부여(authorization) 데이터의 카피를 클라이언트에 제공하는 방법을 제공하는 것이다. 방법은: 클라이언트로부터 인증 서버 요청(AS_REQ) 메세지를 수신하는 단계와, 인증 서버 응답(AS_REP) 메세지를 생성하는 단계와; AS_REP를 클라이언트로 전송하는 단계와; 클라언트로부터 티켓 승인 서버 요청(TGS_TEQ)을 수신하는 단계와; 권한부여 데이터의 두개의 카피들을 갖는 티켓 승인 서버 응답(TGS_REP)를 생성하는 단계와; 권한부여 데이터의 두개의 카피들을 갖는 TGS_REP를 클라이언트로 전송하는 단계를 포함한다.
다른 실시예에서, 본 발명은 권한부여 데이터의 제 1 카피를 포함하는 서비스 티켓을 생성하는 단계와; 서비스 티켓을 포함하는 티켓 승인 서버 응답을 생성하는 단계와; 티켓 승인 서버 응답 및 권한부여 데이터의 제 2 카피를 클라이언트로 전송하는 단계를 포함한다. 한 실시예에서, 권한부여 데이터의 제 2 카피를 전송하는 단계는 클라이언트 세션 키를 사용하여 권한부여 데이터의 적어도 제 2 카피를 암호화하는 단계를 포함하여 클라이언트가 권한부여 데이터의 제 2 카피를 해독하고 사용할 수 있으며, 서비스 티켓을 생성하는 단계는 서버 키를 사용하여 적어도 제 1 권한부여 데이터를 암호화하는 단계를 포함한다.
다른 실시예에서, 본 발명은 애플리케이션 서버로부터 콘텐트가 요청될 때 클라이언트 프라이버시를 제공하기 위한 시스템을 특징으로 한다. 시스템은 권한부여 데이터의 적어도 두개의 카피들을 포함하는 티켓 승인 서버 응답을 생성하도록 구성되는 키 분배 센터를 포함하고, 키 분배 센터는 티켓 승인 서버 응답을 수신하고 검증을 승인하도록 권한부여 데이터의 하나의 카피를 사용하도록 구성된 클라이언트와 결합되며, 클라이언트는 클라이언트로 콘텐트를 공급하도록 구성된 애플리케이션 서버로 결합되고, 클라이언트는 권한부여 데이터의 하나의 카피를 사용하여 콘텐트의 권한부여된 사용을 검증하도록 또한 구성된다.
다른 실시예에서, 본 발명은 클라이언트에 콘텐트 및/또는 서비스들로의 액세스를 제공하기 위한 시스템을 특징으로 할 수 있다. 시스템은 권한부여 데이터의 제 1 카피를 포함하는 서비스 티켓을 생성하기 위한 수단과; 서비스 티켓과 권한부여 데이터의 제 2 카피를 포함하는 티켓 승인 서버 응답을 생성하기 위한 수단과; 티켓 승인 서버 응답을 클라이언트로 보내기 위한 수단을 포함한다. 티켓 승인 서버 응답을 생성하기 위한 수단은 클라이언트 세션 키를 사용하여 적어도 권한부여 데이터의 제 2 카피를 암호화하기 위한 수단을 포함하고, 적어도 제 2 권한부여 데이터를 암호화하기 위한 수단은 클라이언트가 권한부여 데이터의 제 2 카피를 복호화하고 사용할 수 있도록 권한부여 데이터의 적어도 제 2 카피를 암호화하기 위한 수단을 포함한다. 서비스 티켓을 생성하기 위한 수단은 서버 키를 사용하여 권한부여 데이터의 적어도 제 1 카피를 암호화하기 위한 수단을 포함한다. 권한부여 데이터의 제 2 카피는 클라이언트가 애플리케이션 서버로부터 서비스들의 요청을 검증하는 것을 허용하도록 구성될 수 있다. 권한부여 데이터의 제 2 카피는 클라이언트가 수신된 콘텐트의 권한부여된 사용을 결정하는 것을 허용하도록 또한 구성될 수 있다.
본 발명의 특성들 및 장점들의 보다 나은 이해가 본 발명의 다음 상세한 설명과 본 발명의 원리들이 사용되는 도시적인 실시예를 설명하는 첨부 도면들을 참조로 얻어질 것이다.
본 발명의 상기 및 다른 양상들, 특성들 및 장점들이 다음 도면들과 연관하여 제공된, 보다 상세한 다음 설명으로부터 보다 명백하게 될 것이다.
도 1은 본 발명의 실시예에 따라 생성된 시스템의 간략화된 블럭도.
도 2는 본 발명의 한 실시예의 하나의 구현을 따른 시스템의 간략화된 블럭도.
도 3은 클라이언트에 의해 사용되기 위해 권한부여 데이터의 제 2 카피가 클라이언트에 제공되는 방법의 흐름도.
도 4는 도 3에 도시된 프로세스와 유사한, 프로세스의 하나의 구현의 간략화된 흐름도.
도 5는 애플리케이션 서버로부터 콘텐트 및/또는 서비스들을 요청하고 수신하는 클라이언트에 대한 프로세스의 하나의 구현의 간략화된 흐름도.
도면들의 몇몇 뷰들을 통해 대응 참조 기호들은 대응 구성요소들을 나타낸다.
커르베로스는 클라이언트 또는 서버와 같은, 네트워크의 엔티티가 애플리케이션 서버에 의해 공급된 서비스들 및/또는 콘텐트를 액세스하기 위해 애플리케이션 서버로 제공되는 권한부여 데이터를 검증할 수 없는 단점을 가진다. 일부, 권한부여 데이터는 클라이언트로 공급되는 서비스들 및/또는 콘텐트의 제한들을 한정한다. 권한부여 데이터는 종종 애플리케이션 서버(106) 및 애플리케이션 서버(106)에 의해 제공된 콘텐트 및/또는 서비스들로 특정된다. 클라이언트가 권한부여를 검증할 수 없기 때문에, 클라이언트는 그들이 권한부여되지 않았다고 선택된 옵션들이 없다는 것을 확실히 하기 위한 콘텐트에 대한 요청들을 체크할 수 없다. 또한, 클라이언트는 권한부여 데이터를 검증할 수 없기 때문에, 클라이언트가 클라이언트로 배달된 카피 콘텐트로 권한부여되는지를 결정하기 위한 부가적인 통신 및 정보를 요청한다. 이는 에러들과, 과도한 네트워크 트래픽과, 네트워크 자원 및 처리의 필요치 않은 사용을 가져온다. 또한, 클라이언트는 권한부여 데이터를 검증할 수 없기 때문에, 클라이언트는 부가적인 통신 및 정보를 수신하지 않고는, 예를 들어, 클라이언트가 한번 이상 큰텐트를 재생할 수 있도록 권한부여되는지를 결정할 수 없다.
본 발명은 클라이언트가 네트워크 효율을 개선시키고, 네트워크 트래픽, 및 유선형 콘텐트 및/또는 서비스 액세스 및 사용을 감소시키기 위해 액세스하고 사용할 수 있는 클라이언트로 권한부여 데이터의 카피를 배달하는 것에 의해 이러한 및 다른 단점들을 극복하는 방법 및 시스템을 제공한다. 클라이언트에 권한부여 데이터의 클라이언트 카피를 제공하는 것에 의해, 클라이언트는 콘텐트에 대한 응답들에서 불법적인 옵션들의 포함을 회피하는 것에 의해 요청들을 검증할 수 있고, 예를 들면, 배달된 콘텐트의 카피가 저장될 수 있는지, 및 콘텐트가 1회 이상 많이 다시 재생될 수 있는지 등 배달된 콘텐트 및/또는 서비스들의 클라이언트들의 권한부여된 사용을 결정할 수 있다.
본 발명은 티켓들의 개념을 사용하는 키 관리 프로토콜들에 잘 어울리며, 이는 클라이언트가 특정 서버로 인증을 허용하는 대칭 키로 암호화된 인증이다. 본 발명의 한 실시예에 따라, 키 분배 센터(key distribution center:KDC)는 KDC가 서비스 티켓을 클라이언트, 서버 또는 네트워크의 다른 엔티티로 전달 할 때, 서비스 티켓 내의 권한부여 데이터의 두개의 카피들을 포함한다. 권한부여 카피들 중 하나인, 클라이언트 카피(client copy)는 클라이언트(서버 또는 다른 엔티티)가 클라이언트에 의해 사용하기 위한 권한부여 데이터에 액세스할 수 있도록 구성되며, 권한부여 데이터의 카피들 중 하나인, 서버 카피(server copy)는 클라이언트로부터 콘텐트 선택 및/또는 키 요청으로 애플리케이션 서버에 공급된다. 본 발명은 애플리케이션 서버에 의해 제공된 콘텐트 및/또는 서비스들로의 액세스를 얻기 위해 클라이언트 또는 서버 적용에 의해 액세스되고 사용될 수 있는 권한부여 데이터의 카피를 공급하는 것에 의해 표준 커르베로스 및 다른 이전의 프로토콜들의 단점들을 극복한다.
도 1을 참조하면, 본 발명의 실시예에 따라 생성된 보안 통신을 제공하기 위한 시스템(100)의 간략화된 블럭도가 도시된다. 예를 들어, 본 발명의 하나의 구현 가능한 예를 포함하는 시스템(100)은 수백만의 사용자들을 스케일할 수 있는 인터넷, 인트라넷 또는 다른 네트워크와 같은 네트워크 상에서 보안 및 프라이버시를 제공하는 인증 키 관리 프로토콜을 사용한다. 일반적으로, 시스템(100)은 대칭 키 알고리즘들을 사용하는 애플리케이션 서버(106)(및 제 3 자 서버(140); 도 2 참조)와 같은 개별적인 애플리케이션 서버들 뿐만 아니라 공용 키와 대칭 키 알고리즘들 모두를 사용하여 하나 이상의 집중된 키 분배 센터들(KDC)(104)과 상호작용하는 적어도 하나의 클라이언트(102)를 포함한다. 프로토콜은 일반적인 것이며 분포된 환경에서 인증을 요구하는 다른 애플리케이션들로도 쉽게 적응될 수 있다. 또한, 집중적으로 관리된 사용자 데이터베이스와도 인터페이스될 수 있다.
클라이언트(102)는 사용자를 위하여 네트워크 서비스를 사용하도록 하는 프로세스, 애플리케이션 또는 디바이스를 포함한다. 예를 들어, 클라이언트(102)는 임의 타입의 컴퓨터를 포함할 수 있으며, 또는 클라이언트(102)는 무선 전화, 페이저, 개인 디지털 비서(PDA), 낮은 단부의 마이크로프로세서를 갖는 홈 애플리케이션, 또는 실질적으로 낮거나 제한된 프로세싱 커패시티들을 갖는 임의의 다른 디바이스와 같은 "씬 클라이언트(thin client)"를 포함할 수 있다. 일부 경우들에서 서버는 자체적으로 일부 다른 서버의 클라이언트가 될 수 있다는 것에 주의한다(예를 들면, 프린트 서버는 파일 서버의 클라이언트일 수 있다).
애플리케이션 서버(106)는 리소스를 네트워크 클라이언트들로 제공한다. 도시된 실시예에서, KDC(104)는 제 1 단(108)과 제 2 단(110)을 포함한다. 한 실시예에서, 제 1 단은 인증 서버(AS 서버;108)이고, 제 2 단은 티켓 승인 서버(TGS 서버; 110)이다. AS 서버(108)는 티켓 승인 티켓(TGT 티켓)을 그의 자격을 검증한 후 클라이언트(102)로 발행한다. TGS 서버(110)는 애플리케이션 서버 서비스 티켓(ST 티켓)을 클라이언트(102)로 제공한다. ST 티켓은 클라이언트(102)가 서비스를 요청할 때 클라이언트(102)가 애플리케이션 서버(106)로 제공하는 마지막 서비스 티켓이다. 애플리케이션 서버(106)는 클라이언트(102)가 ST 티켓들을 사용하여 그 자신을 인증할 때 다양한 서비스들을 클라이언트(102)로 제공한다.
시스템(100)에 의해 사용된 기본적인 메세지 타입들은 다음과 같다:
(A)인증 서버 요청 메세지(AS_REQ):AS 서버(108)로부터 TGT 티켓을 요청하기 위한 클라이언트(102)로부터의 메세지;
(B)인증 서버 응답 메세지(AS_REP):TGT 티켓을 갖고 있는 AS 서버(108)로부터 클라이언트(102)로 메세지를 응답;
(C)티켓 승인 서버 요청 메세지(TGS_REQ): TGS 서버(110)로부터 ST 티켓을 요청하기 위한 클라이언트(102)로부터의 메세지;
(D)티켓 승인 서버 응답 메세지(TGS_REP): TGS 서버(110)로부터 ST 티켓을 갖고 있는 클라이언트(102)로 메세지를 응답;
(E)키 요청 메세지(KEY_REQ): 보안(키 관리) 파라메터들을 요청하기 위하여 메세지를 클라이언트(102)로부터 애플리케이션 서버(106)로 보냄;
(F)키 응답 메세지(KEY_REP): 애플리케이션 서버(106)로부터 서브 키 및 애플리케이션 특정 데이터를 갖는 클라이언트(102)로 메세지를 응답;
(H)콘텐트 및/또는 서비스들에 대한 요청 메세지(CON_REQ): 원하는 콘텐트 및/또는 서비스들을 요청하기 위하여 클라이언트(102)로부터 애플리케이션 서버(106)로 메세지를 보냄.
(I)콘텐트(CON_REP): 애플리케이션 서버(106)로부터 원하는 콘텐트 및/또는 서비스들을 클라이언트로 공급하는 클라이언트(102)로 메세지를 보냄. 콘텐트는 전형적으로 클라이언트로 보내지기 전에 암호화된다.
메세지들의 각각은 일반적으로 메세지의 몸체에 따라오는 헤더를 포함하며, 헤더는 메세지들에 공통이다. 예를 들어, 헤더는 메세지 타입 필드, 프로토콜 버전 넘버 필드 및 체크섬을 포함할 수 있다. 메세지 타입 필드는 AS_REQ, AS_REP와 같은 메세지 타입을 나타낸다. 다음 메세지 헤더는 바람직하게 타입-길이-값(TLV) 포맷의 특성들의 리스트를 갖는 메세지의 몸체이다.
클라이언트(102)는 클라이언트가 또한 KDC(104)의 일부인 TGS 서버(110)에 대한 티켓인 TGT 티켓을 얻고자 원할 때, 클라이언트(102)와 AS 서버(108)(KDC(104)의 일부) 사이에서 변화하는 인증 서비스 변화를 개시하기 위한 AS_REQ 메세지를 생성한다. 다시 말해, AS_REQ 메세지는 애플리케이션 서버(106)와 같은, 특정 애플리케이션 서버들에 대한 ST 티켓들을 요청하기 위해 클라이언트에 의해 사용되는 TGT 티켓을 얻기 위해 클라이언트(102)에 의해 AS 서버(108)로 보내진다. 예를 들어, AS_REQ 메세지는 클라이언트의 아이덴티티(예를 들면, 이름), TGS 서버(110)의 아이덴티티를 포함할 수 있으며, 우선 이를 응답으로 묶는다. 이는 또한 클라이언트(102)에 의해 지지되는 대칭 암호화 알고리즘들의 리스트를 포함할 수 있다. 응답들을 다시 체크하기 위하여, 이러한 메세지는 또한 메세지 통합을 위한 시그너처 뿐만 아니라 타임스탬프를 포함할 수 있다. 시그너처는 암호화된 체크섬이거나 또는 디지털 시그너처일 수 있다.
시그너처를 검증하기 위한 공용 키는 바람직하게 사용자 데이터베이스에서 유지된다. 디지털 증명서들은 AS_REQ 메세지에 선택적으로 포함될 수 있으며, 디지털 시그너처들을 검증하기 위해 저장된 공용 키들 대신 사용될 수 있다. 암호화된 체크섬을 검증하기 위한 클라이언트(102)의 영구 대칭 키는 바람직하게 동일한 사용자 데이터베이스에서 유지된다. AS_REQ 메세지는 또한 키 동의를 위해 필요한 공용 키 정보(예를 들면, 엘립틱 커브 디파이-헬맨 파라메터들(Elliptic Curve Diffie-Hellman parameters))를 포함할 수 있다. 예를 들어, 엘립틱 커브는 그의 프로세싱 속도 때문에 공용 키 암호화를 위해 사용될 수 있다. 엘립틱 커브의 사용은 전형적으로 RSA와 같은 다른 암호화들보다 1차 또는 2차 정도의 고속이다. 128-비트 키 길이의 리즌데일(Rijndael) 암호화 표준이 사용될 수 있다.
AS 서버(108)는 그를 검증하기 위해 AS_REQ 메세지를 처리한다. AS_REQ 프로세싱이 에러들을 생성하지 않으면, AS 서버(108)는 AS_REQ 메세지에 응답하여 AS_REP 메세지를 생성한다. 전형적으로, AS 서버(108)는 데이터베이스의 TGS 서버(110) 및 클라이언트(102)의 키들을 검색하고, KDC(104)로의 다음 인증에 대한 랜덤 클라이언트 세션 키를 생성한다. AS 서버(108)는 TGT 티켓을 생성한다. TGT 티켓은 전형적으로 클리어한 부분 및 암호화된 부분 모두를 포함한다. TGS 서버(110)의 아이덴티티 및 티켓 유효 기간은 발행된 TGT 티켓의 클리어한 면에 제공된다. 티켓의 암호화된 부분은 개인 부분에 저장되는 클라이언트(102)의 이름, 클라이언 트 세션 키 및 임의의 다른 데이터와 같은 정보를 포함할 수 있다. TGT 티켓은 또한 KDC(104)에 의해 공급된 암호화 타입들 및 체크섬 타입들의 리스트를 제공할 수 있다. 티켓의 암호화된 부분은 KDC(104)의 보안 키를 사용하여 암호화될 수 있다.
한 실시예에서, AS_REP 메세지는 AS_REQ 메세지에 대한 시그너처를 생성하기 위해 클라이언트(102)에 의해 사용된 것과 동일한 알고리즘을 사용하여 KDC(104)에 의해 사인된다. 이러한 시그너처는 디지털 시그너처 또는 클라이언트(102)의 보안 키를 사용하는 암호화된 체크섬일 수 있다. 공용 키 정보는 키 동의 파라메터들의 KDC(104)의 공용 부분이며 클라이언트(102)에 의해 선택된 것과 같은 동일한 키 동의 알고리즘을 나타내야 한다. AS_REP 메세지는 또한 바람직하게 재생들을 보호하기 위하여 AS_REQ 메세지의 클라이언트에 의해 생성된 임시의 카피인 임시를 포함한다.
한 실시예에서, AS_REP 메세지의 암호화된 부분은 그 자신의 권한부여 데이터로 액세스하는 클라이언트(102)를 제공한다. 클라이언트(102)가 그 자신의 권한부여 데이터를 알고 있기 때문에 권한부여 데이터의 클라이언트 카피를 갖는 클라이언트를 제공하는 것은 클라이언트(및 사용자)에게로의 편의를 제공하며, 애플리케이션 서버가 티켓 내부로 암호화되는 클라이언트 정보의 카피만을 신뢰하기 때문에 애플리케이션 서버에 의해 후에 간단하게 거절되도록 동작들을 시도하지 않을 것이다. 또한, 해킹 및 그 자신의 권한부여 데이터가 바뀌는 것으로부터 사용자를 보호하기 위한 하드웨어 보안을 갖는 클라이언트들에 대해, 판독가능한 권한부여 데이터가 또한 로컬 디스크 상에 콘텐트(예를 들면, 영화들)를 저장하고 재생하기 위한 권리와 같은, 일부 로컬 동작들에 대한 클라이언트를 권한부여하기 때문에 이러한 특성은 보안적인 장점이 될 수 있다. AS_REP 메세지에서 수신된 권한부여 데이터의 클라이언트 카피는 정형적으로 일반적인 클라이언트 권한부여를 정의하며, 이는 서버들에 대해 특정적이지 않다. 권한부여 데이터의 클라이언트 카피의 사용이 이하에서 또한 설명된다. AS_REP 메세지의 암호화된 부분이 또한 상기 재생이 해당 특정 클라이언트(102)에 대한 KDC(104)에 의해 원래 구성된것인지를 검증하기 위해 클라이언트(102)의 아이덴티티를 포함할 수 있다. 데이터는 바람직하게 키 동의 알고리즘으로부터 파생된 대칭 키로 암호화될 수 있다.
클라이언트(102)는 그의 인증을 검증하기 위해 또한 TGT 티켓을 얻기 위해 메세지의 개인적인 티켓 부분을 해독하기 위해 AS_REP 메세지를 처리한다. AS_REP 메세지의 인증은 검증될 수 없기 때문에, 클라이언트(102)는 바람직하게 에러 메세지를 AS 서버(108)로 다시 보내지 않는다. 일부 경우들에서, 클라이언트는 다른 AS_REQ 메세지로 재시도할 것이다.
본 발명은 클라이언트(102)와 KDC(104)가 디지털 승인들과 서로 인증하는 것을 허용하도록 선택적으로 AS_REQ 와 AS_REP 메세지들의 디지털 승인들의 통과를 허용한다. 인증들 없이, 클라이언트(102)는 KDC 공용 키로 미리 준비되며 KDC(104)는 그의 데이터베이스에 클라이언트(102)의 공용 키를 미리 갖는다는 것이 예상된다. AS_REQ의 디지털 시그너처는 그의 데이터베이스에서 검색되는 클라이언트 공용 키를 갖는 KDC(104)에 의해 검증된다. 클라이언트(102)는 미리 준비된 KDC 공용 키를 갖는 AS_REQ 상의 디지털 시그너처를 검증한다.
클라이언트(102)가 AS 서버(108) 변화를 통해 TGT 티켓을 얻은 후, 클라이언트(102)는 클라이언트(102)가 애플리케이션 서버(106)와 같은, 주어진 또는 특정 애플리케이션 서버에 대한 인증 승인들을 얻도록 원할 때 KDC(104)의 클라이언트(102)와 TGS 서버(110) 사이의 TGS_REQ 메세지 변화를 시작한다. TGS_REQ 메세지는 KEY_REQ 메세지에서 사용되는 애플리케이션 서버 서비스 티켓(ST 티켓)을 얻기 위하여 클라이언트(102)에 의해 TGS 서버(110)로 생성되고 보내진다(이하에서 상세히 설명됨). 클라이언트(102)는 TGS_REQ 메세지의 부분으로서 AS_REP 메세지로부터 얻어진 TGT 티켓을 제공한다. TGS_REQ 메세지는 전형적으로 TGT 티켓 내부에 있는 클라이언트(102)의 아이덴티티 뿐만 아니라 애플리케이션 서버(106)의 아이덴티티를 규정하고, 클라이언트는 전형적으로 우선을 포함한다. 한 실시예에서, 이는 TGT 티켓의 암호화된 부분에 있고 메세지의 클리어한 부분에 포함되지 않으므로, 클라이언트(102)의 아이덴티티는 보호된다. TGT 티켓으로부터 클라이언트 세션 키는 TGS_REQ 변화의 암호화 및 해독을 위해 사용될 수 있다. 그러므로, 스너퍼는 클라이언트(예를 들면, 사용자)가 요청하는 서비스들을 검출할 수 없다.
클라이언트(102)는 바람직하게 KDC(104)로부터 매칭 TGS_REP 메세지를 후에 유효하게 하기 위한 우선 값을 저장한다. 클라이언트(102)는 바람직하게 구성가능한 시간 종료 값이 종료할 때까지 우선 값을 유지한다. 시간 종료 후에, 클라이언트(102)는 더이상 대응 TGS_REP를 처리할 수 없으며, 재시도해야 한다.
TGS 서버(110)는 TGS_REQ 메세지를 검증하고 TGT 티켓을 처리한다. TGT 서버(110)는 이후 TGS_REQ 메세지에 응답하여 TGS_REP 메세지를 생성한다. TGS_REP 메세지는 KDC(104)에 의해 발행된 ST 티켓(마지막 서비스 티켓이다)을 포함하며, 클라이언트(102)는 클라이언트가 콘텐트 및/또는 서비스들을 요청하도록 시도할 때 애플리케이션 서버(106)로 제공한다. 애플리케이션 서버(106)의 아이덴티티 및 티켓 유효 주기는 발행된 ST 티켓 내부의 클리어한 부분에 제공된다. ST 티켓의 암호화된 부분은 클라이언트(102)의 이름 및 애플리케이션 서버(106)와 KDC(104)에 의해 공유된 서버 키로 암호화된 서버 세션 키를 포함한다. ST 티켓의 암호화된 부분은 또한 일부 클라이언트로 제공될 서비스들 및/또는 콘텐트의 제한들을 한정하는 권한부여 데이터의 제 1 카피(예를 들어, 서버 카피)를 포함한다. 권한부여 데이터는 애플리케이션 서버(106) 및 애플리케이션 서버(106)에 의해 제공된 콘텐트 및/또는 서비스들로 한정된다. 한 실시예에서, 권한부여 데이터는 서비스 및/또는 콘텐트 특정 개체들, 및 이러한 개체들로의 권리들을 포함한다. 보호되어야 할 필요가 있는 임의의 부가적인 클라이언트 데이터는 또한 ST 티켓의 암호화된 부분의 일부로서 포함될 수 있다.
한 실시예에서, TGS_REP는 부가적으로 AS_REP 메세지의 AS 서버(108)에 의해 생성된 TGT 티켓으로부터 클라이언트 세션 키를 사용하여 암호화되는 권한부여 데이터의 제 2 카피(예를 들어, 클라이언트 카피)를 포함한다. 위에서 설명된 바와 같이, 세션 키는 TGS 서버(110) 및 클라이언트(102)에 의해 공지된다. 권한부여 데이터의 제 2 카피(클라이언트 카피)가 TGT 티켓으로부터의 세션 키를 사용하여 암호화되므로, 클라이언트(102)는 이하에서 더욱 상세히 설명될 바와 같이, 인증 목적들 및 다른 목적들을 위한 것과 같은, 권한부여 데이터를 해독하고 권한부여 데이터를 사용할 수 있다. TGS_REP 메세지에서 수신된 권한부여 데이터의 제 2 카피는 AS_REP 메세지에서 수신된 권한부여 데이터의 제 2 카피보다 많은 서버 특정 권한부여를 포함하는, 보다 특정한 권한부여를 제공할 수 있다. AS_REP 메세지에서 수신된 권한부여 데이터는 보다 일반적이며, 비서버 특정 클라이언트 권한부여들, 예를 들어 클라이언트가 콘텐트를 저장하기 위해 권한부여되는지를 정의한다.
TGS_REP 메세지는 TGT 티켓 세션 키를 사용하여 암호화된 체크섬을 갖는 KDC(104)에 의해 사인된다. TGS_REP 메세지는 부가적으로 재생들을 보장하기 위하여 TGS_REQ 메세지로부터 카피된 논스(nonce)를 포함한다.
예로써, TGS 서버(110)는 다음 절차를 사용하여 TGS_REP 메세지를 생성할 수 있다. 먼저, TGS_REQ 메세지로부터의 논스가 요청으로 묶기 위하여 TGS_REP 메세지로 포함된다. 다음, KDC(104)는 랜덤 ST 티켓 세션 키의 타입을 할당한다. 하나 이상의 암호화 알고리즘이 사용될 수 있으면, KDC(104)는 바람직하게 제일 강한 하나를 선택한다. KDC(104)는 이후 권한부여 데이터의 제 1 카피, 서버 카피를 포함하는 ST 티켓을 생성한다. 애플리케이션 서버(106)의 보안 키는 ST 티켓의 암호화된 부분을 암호화하기 위해 사용되며, 또한 전체적인 ST 티켓을 통해 암호화된 체크섬을 생성한다. ST 티켓의 마지막 시간은 바람직하게 KDC(104)에 의해 결정된다. 클라이언트(102)는 그가 원한다면 보다 짧은 라이프타임을 규정할 수 있다. ST 티켓의 암호화된 부분은 클라이언트(102)의 아이덴티티, 권한부여 데이터의 제 1 카피, 세션 키 및 다른 개인 데이터를 포함한다. TGS_REP 메세지는 또한 암호화된 데이터 부분을 포함하며, TGT 티켓 세션 키는 암호화된 데이터 부분을 생성하도록 사용된다. 암호화된 데이터 부분은 권한부여 데이터의 제 2 카피를 포함하며, TGT 세션 키를 사용하여 생성된 암호화된 체크섬은 TGS_REP 메세지를 통해 부가될 수 있다. 또한, 이는 TGS 서버(110)가 권한부여 데이터의 두개의 카피들을 포함하는 TGS_REP 메세지를 생성하도록 사용될 수 있는 절차의 단지 하나의 예이다.
TGS_REP 메세지가 권한부여 데이터의 ST 티켓의 암호화된 부분에 포함된 것과 TGT 티켓으로부터 세션 키로 암호화된 것의 두개의 카피들을 포함하기 때문에, 클라이언트(102) 뿐만 아니라 애플리케이션 서버(106)가 액세스되며 권한부여 데이터를 사용할 수 있다. 이러한 방법으로 클라이언트는 부가적인 통신들 및 부가적인 데이터들 없이도 체크들 및 검증들을 수행할 수 있다. 본 발명은 커르베로스와 상이하며, 커르베로스에서 특정 애플리케이션 서버에 대해 클라이언트로부터 티켓 요청으로의 KDC 응답은 단지 ST 티켓의 해독 시 애플리케이션 서러보의 액세스만이 가능한 권한부여 데이터의 단일 카피만을 포함한다. 클라이언트는 권한부여 데이터로의 액세스를 갖지 않으며, 데이터를 사용할 수 없다. 대안적으로, 본 발명의 KDC는 클라이언트(102)가 권한부여 데이터의 제 2 카피를 해독하고 권한부여 데이터를 사용하는 것을 허용하는 권한부여 데이터의 두개의 카피들, ST 티켓 내에서 암호화된 것과 클라이언트 TGT 티켓 세션을 사용하여 암호화된 것을 포함하는 것에 의해 특정 애플리케이션 서버에 대한 클라이언트로부터의 티켓 요청으로의 응답을 생성한다.
한 실시예에서, 클라이언트(102)는 권한부여 모듈(122)을 포함한다. 권한부여 모듈은 권한부여 데이터의 제 2 카피를 포함하며, 애플리케이션 서버(106)에 의해 제공된 콘텐트 및/또는 서비스들을 사용하기 위해 어떠한 및 어떻게 클라이언트가 권한부여되는지를 결정하기 위해 권한부여 데이터를 분석하도록 구성된다. 권한부여 모듈(122)은 하드웨어, 소프트웨어 또는 하드웨어와 소프트웨어의 조합을 통해 구현될 수 있다. 한 실시예에서, 권한부여 모듈(122)은 권한부여 데이터로부터 추출된 권한부여를 디코딩하고, 콘텐트 및/또는 서비스들에 대해 권한부여를 클라이언트(102)가 검증하며, 클라이언트가 권한부여를 초과하지 않을 때만 요청된 콘텐트를 해독하거나 및/또는 서비스들을 제공하도록 진행하는 하드웨어 모듈이다. 하드웨어 모듈 외부의 소프트웨어 해킹 침입들을 방지하기 위하여, 권한부여 데이터에 대한 암호화된 체크섬을 검증하기 위해 사용된 보안 키는 하드웨어 모듈의 외측의 클라이언트에서 노출되지 않는다. 한 실시예에서, 전체적인 키 관리 프로토콜이 동일한 하드웨어 모듈(122) 내에서 수행되도록 하기 위하여, 보안 또는 개인 키들이 하드웨어 모듈의 외부의 클라이언트 내에서 클리어하게 노출되지 않는다.
예를 들어, 클라이언트(102)는 TGS_REP 메세지를 처리하기 위한 다음 절차를 사용할 수 있다. 이러한 예에서, "클라이언트"는 클라이언트(102) 자체 또는 권한부여 모듈(122)(클라이언트 내부에 있을 때)을 나타낸다. 당업자는 권한부여 모듈(122)을 갖는 클라이언트가 전형적으로 권한부여 모듈의 외부에 발생하도록 암호 프로세싱을 허용하지 않는다는 것을 인식할 것이다. 먼저, 클라이언트(102)는 TGS_REP 메세지 헤더를 분석한다. 헤더가 실패들을 분석하며, 이후 클라이언트(102)는 TGS_REP가 수신되지 않은 것처럼 행동한다. 클라이언트(102)는 바람직하게 에러 메세지를 TGS 서버(110)로 다시 보내지 않는다. 일부 경우들에서, 클라이언트(102)는 다른 TGS_REQ 메세지를 검색한다. 외부의 TGS_REQ 메세지들이 존재하면, 클라이언트(102)는 시간 오버 및 이후 재시도할 때까지 응답에 대해 지속적으로 대기할 수 있다. 다음, 클라이언트(102)는 헤더의 프로토콜 버전 넘버를 검증한다. 이러한 프로토콜 버전이 제공되지 않으면, 클라이언트(102)는 TGS_REP 메세지가 수신되지 않은 것처럼 행동한다. 즉, 클라이언트(102)는 이후 메세지의 나머지를 분석한다. 메세지 포맷이 불법적인 것으로 발견되면, 클라이언트(102)는 TGS_REP 메세지가 수신되지 않은 것처럼 행동한다.
다음, 클라이언트(102)는 동일한 논스를 갖는 외부의 TGS_REQ 메세지에 대해 검사한다. 매치가 없으면, 클라이언트는 메세지가 수신되지 않은 것처럼 진행한다. 매치가 있으면, 클라이언트(102)는 TGT 티켓 세션 키를 사용하여 체크섬을 검증한다. 체크섬이 검증되지 않으면, 이러한 메세지는 드롭되고 클라이언트(102)는 메세지가 수신되지 않은 것처럼 진행한다.
클라이언트는 이후 TGS_REP 메세지의 개인 티켓 부분을 TGT 티켓 세션 키를 사용하여 해독한다. TGT 티켓 세션 키 타입 및 암호화된 데이터의 타입이 매칭하지 않아 개인 티켓 부분이 해독될 수 없으면, 치명적인 에러가 사용자에게 보고되고 클라이언트(102)는 재시도하지 않는다. 결과적으로 클리어한 텍스트가 포매팅 에러들을 포함하고, 이러한 클라이언트(102)에 의해 지지되지 않는 타입의 세션 키를 포함하며, 또는 요청과 매칭하지 않는 클라이언트 아이덴티티를 포함하여, 치명적인 에러가 다시 사용자에게 보고되고 클라이언트(102)는 재시도하지 않는다. 세션 키 타입이 공급되지 않고 클라이언트가 TGS_REP 메세지의 개인 티켓 부분을 해독할 수 있으면, 클라이언트는 권한부여 데이터의 제 2 카피를 추출하고, 나중 사용을 위해 이를 검증하고 보관한다.
클라이언트(102)는 이후 ST 티켓을 처리한다. ST 티켓에 에러가 있으면, 이는 치명적인 에러로서 사용자에게 보고되고 클라이언트(102)는 다른 TGS_REQ 메세지로 재시도하지 않는다. TGS_REP 메세지에 에러들이 없는 것으로 검출되면, 클라이언트(102)는 권한부여 데이터의 제 2 카피를 포함하여, 그의 티켓 개시의 새로운 엔트리에 전체적인 ST 티켓과 클리어한 텍스트의 개인 티켓 부분을 보존한다. 권한부여 모듈(122)이 클라이언트(102)의 내부에 존재하는 실시예에서, 클라이언트는 티켓의 변환된 버전에 대한 체크섬을 생성하도록 서버 키를 소유하고 잇지 않으므로 ST 티켓은 클라이언트(102) 내부의 권한부여 모듈(122)의 외부에 저장될 수 있다. 권한부여 데이터는 권한부여 모듈(122)의 내부에 저장되거나 암호화된 체크섬 또는 디지털 시그너처로 인증될 수 있으며, 이후 클라이언트(102) 내의 모듈의 외부에 저장될 수 있다. (모듈의 저장 필요량들을 최소화하기 위하여) 권한부여 데이터가 권한부여 모듈(122)의 외부에 저장되면, 권한부여 데이터를 변화시키기 위한 해커들에 의한 시도들이 권한부여 모듈(122)에 의해 검출될 것이다. 이는 권한부여 데이터를 위해 암호화된 체크섬 또는 디지털 시그너처를 생성하는데 사용된 키가 권한부여 모듈(122)의 외부에서는 판독불가능하기 때문이다.
KEY_REQ 및 KEY_REP 메세지들은 클라이언트(102)와 애플리케이션 서버(106) 사이의 키 관리 및 인증을 위해 사용된다. KEY_REQ 메모리는 보안 파라메터들의 새로운 세트를 수립하기 위해 클라이언트(102)에 의해 애플리케이션 서버(106)로 보내진다. KEY_REQ 메모리는 또한 클라이언트(102)에 의해 애플리케이션 서버(106)를 갖는 새로운 키들을 주기적으로 수립하기 위해 보내질 수 있다. 클라이언트(102)는 TGS_REP 메세지에서 이전에 얻어진 유효 ST 티켓을 시작한다. 애플리케이션 서버(106)는 티켓들을 해독하고 유효화하는데 사용할 수 있는 그의 서비스 키로 시작한다. 클라이언트는 클라이언트(102)를 인증하는데 필요한 ST 티켓 및 암호화된 체크섬을 포함하는 KEY_REQ 메세지를 생성한다. KEY_REQ 메세지는 REY_REP 메세지에 응답하여 재생 시도들을 막기 위한 클라이언트 타임 스탬프로 논스를 묶도록 바람직하게 포함될 수 있다.
클라이언트(102)가 KEY_REQ 메세지를 생성할 때, 한 실시예에서 권한부여 데이터의 제 1 카피 및 클라이언트(102)의 아이덴티티는 ST 티켓의 암호화된 부분에 존재한다. 클라이언트(102)가 KEY_REQ 메세지를 보내면, 그는 애플리케이션 서버(106)로부터 매칭 KEY_REP 메세지를 나중에 유효화하기 위해 클라이언트 논스 값을 저장한다. 클라이언트(102)는 구성 시간 종료 값이 종료할 때까지 클라이언트 논스 값을 유지한다. 시간 종료 후에, 클라이언트(102)는 대응 KEY_REP 메세지를 더이상 처리할 수 없다. 클라이언트(102)는 이러한 시간 종료 후에 재시도할 수 있다.
KEY_REP 메세지는 애플리케이션 서버(106)에 의해 KEY_REQ 메세지에 응답하여 보내진다. 예를 들어, KEY_REP 메세지는 하나 이상의 램덤하게 생성된 서브키들, 클라이언트(102)와 애플리케이션 서버(106) 사이에서 공유된 세션 키로 암호화된 키들을 포함할 수 있다. KEY_REP 메모리는 또한 보안 파라메터들을 수립하는데 필요한 부가적인 정보를 포함할 수 있다.
클라이언트(102)는 KEY_REP 메세지를 수신하고 KEY_REP 메세지를 처리한다. 클라이언트는 메세지 헤더를 분석하고, 프로토콜 버전 넘버를 검증하며, 메세지의 나머지를 분석하고, 존재하는 클라이언트 KEY_REQ 순간을 갖는 KEY_REP의 순간을 매칭하고 클라이언트(102)와 애플리케이션 서버(106) 사이에서 공유된 세션 키를 사용하여 체크섬을 검증한다. 클라이언트는 또한 공유된 세션 키를 사용하여 KEY_REP의 서브키를 해독하고, 선택된 암호가 수용가능한 것인지를 검색하며, 암호화된 DOI 개체(권한부여)을 분석하고, 서브키로부터 콘텐트 해독 및 인증 키들을 생성하며 후에 사용하기 위해 이들을 저장한다.
한 실시예에서, CON_REQ 메세지가 클라이언트(102)에 의해 애플리케이션 서버(106)로 보내지고 클라이언트는 KEY_REP을 수신하고 검증한다. CON_REQ 메세지의 생성에서, 클라이언트는 권한부여 데이터의 해독된 제 2 카피를 액세스하고, 클라이언트는 ST 티켓을 갖는 AS_REP 메세지 및/또는 TGS_REP 메세지로부터 수신되고 해독되며, CON_REQ 메세지가 불법적으로 남아있거나 권한부여되지 않은 옵션임을 확실하게 하도록 권한부여 데이터를 확정한다. 그러므로, 클라이언트의 사용자 인터페이스가 개선되고 사용자는 서버로 CON_REQ 메세지를 제출할 필요없고 응답을 위해 기다릴 필요없이 초기로부터 권한부여되지 않은 옵션들을 선택하는 것으로부터 보호될 수 있다. 한 실시예에서, 클라이언트(102)가 다소 여전히 권한부여되지 않은 CON_REQ 메세지를 생성하였으면, 권한부여 모듈(122)은 CON_REQ 메세지에 대해 암호화된 체크섬을 생성하는데 필요한 대칭 키를 보유하고 권한부여 데이터의 제 2 카피에 의해 정의된 바와 같은 클라이언트의 권한부여를 위배하거나 초과하는 이러한 CON_REQ 메세지를 위해 암호화된 체크섬을 생성하도록 거절한다. 따라서, 애플리케이션 서버(106)는 전형적으로 그들이 클라이언트 측에서 거절된 것과 같은 권한부여되지 않은 CON_REQ 메세지들을 보지 않으나, 이러한 권한부여되지 않은 메세지가 오게 되면 CON_REQ는 정확한 암호화된 체크섬을 가지지 않고 클라이언트 권한부여를 체크하도록 서버(106)로의 요청없이 거절된다.
권한부여 데이터의 확정은 또한 애플리케이션 서버(106)에서 권한부여되지 않은 메세지들의 처리를 회피하는 것에 의해 시스템을 최적화하며, 클라이언트와 사용자와의 상호작용을 개선하고, 사용자가 지역적으로 애플리케이션 서버(106) 응답에 대한 대기없이 권한부여를 평가하는 것을 허용한다. 한 실시예에서, CON_REQ 메세지는 클라이언트(102)와 애플리케이션 서버(106) 사이에서 공유된 세션 키를 사용하여 암호화된다.
CON_REQ 메세지의 수신시, 애플리케이션 서버(106)는 CON_REQ 메세지를 처리하고 암호화된 ST 티켓의 부분으로서 수신된 권한부여 데이터의 제 1 카피로 요청을 유효화한다. 에러들이 없고 콘텐트에 대한 요청이 권한부여 데이터의 권한부여를 위반하지 않으면, 애플리케이션 서버(106)는 CON_REP 메세지를 생성하고 클라이언트에 의해 요청된 콘텐트 및/또는 서비스들의 배달을 시작한다. 전형적으로, 배달된 콘텐트는 클라이언트(102)와 서버(106) 사이에서 공유된 세션 키를 사용하여 애플리케이션 서버(106)에 의해 암호화된다.
클라이언트(102)는 콘텐트를 수신하고, 콘텐트를 해독하며 프로세스를 시작하고 콘텐트를 사용한다. 한 실시예에서, 클라이언트(102)가 권한부여 데이터의 카피를 가지므로, 클라이언트는 수신된 콘텐트 및/또는 서비스들의 권한부여된 수신을 결정할 수 있다. 예를 들어, 클라이언트(102)는 권한부여 데이터를 체크하는 것에 의해 클라이언트가 콘텐트의 카피를 저장하기 위해 권한부여되는지를 결정할 수 있다. 권한부여 모듈(122)은 권한부여 데이터를 체크하고 클라이언트의 권한부여를 결정한다. 클라이언트가 권한부여되면, 클라이언트는 수신되고 해독된 콘텐트를 저장할 수 있다. 부가적으로, 클라이언트가 권한부여 데이터의 카피를 갖기 때문에, 한 실시예에서 권한부여 모듈(122)인 클라이언트(102)는 또한 클라이언트가 한번 보다 많이 콘텐트를 재생하거나 해석할 수 있는지의 권한부여를 체크하는 것에 의해 결정할 수 있다. 권한부여 모듈(122)은 전형적으로 저장된 콘텐트 해독 키들을 포함하고, 적절한 권한부여 없이 콘텐트를 해독하기 위해 거부된다. 클라이언트의 권한부여를 결정하기 위한 능력은 권한부여 데이터의 제 2 카피를 사용하는 것에 의해 이루어지며, 클라이언트(102)는 TGS_REP 메세지에서 수신되고 로컬 사용에 대해 저장된다. 이는 클라이언트 동작을 개선시키고 네트워크를 가로지르는 통신을 제한한다.
한 실시예에서, 시스템(100)은 권한부여 데이터의 ST 티켓과 클라이언트 카피를 얻도록 클라이언트에 대해 순서대로 일어나도록 TGS_REQ 및 TGS_REP 변화를 요구하지 않는다. 클라이언트(102)는 서비스 티켓에 대한 AS_REQ를 특정 서버, 예를 들면 애플리케이션 서버(106)로 제공한다. KDC(104)는 AS_REQ를 처리하고 제 1 애플리케이션 서버에 대한 ST 티켓을 되돌리며, 권한부여 데이터의 제 1 카피를 포함한다. KDC는 또한 권한부여 데이터의 제 2 카피를 클라이언트(102)에 의해 액세스되고 사용될 포맷인 클라이언트로 보낸다. 전형적으로, KDC(104)는 권한부여 데이터의 제 1 카피와 권한부여 데이터의 클라이언트 카피를 갖는 ST 티켓을 포함하는 AS_REP를 되돌린다. 따라서, 클라이언트는 TGS_REQ를 제출할 필요 없이 ST 티켓을 갖는 권한부여 데이터의 클라이언트 카피를 여전히 얻을 수 있다.
도 2는 본 발명의 한 실시예의 한 구현을 따른 시스템(101)의 간략화된 블록도를 도시한다. 한 실시예에서, 클라이언트(102)는 원하는 콘텐트 및/또는 서비스들을 선택하기 위하여 제 3 자 서버(140)에 액세스하며, 선택된 콘텐트 및/또는 서비스들을 실질적으로 수신하기 위하여 애플리케이션 서버(106)로 액세스한다. 콘텐트 및/또는 서비스들의 선택에서, 클라이언트(102)는 권한부여 데이터의 클라이언트 카피를 사용한다. 콘텐트 및/또는 서비스들에 대한 선택을 제 3 자 서버(140)로 제출하기 전에, 클라이언트는 원하는 콘텐트 및/또는 서비스들을 결정하고, 클라이언트의 권한부여를 초과하는 선택을 형성하는 것을 회피하기 위해 권한부여 데이터의 클라이언트 카피를 체크한다. 클라이언트(102)는 이후 콘텐트 및/또는 서비스들의 선택을 제 3 자 서버(140)로 보낸다. 제 3 자 서버(140)는 이후 콘텐트 및/또는 서비스들의 선택을 검증하고 콘텐트 및/또는 서비스들의 선택 응답 메세지를 클라이언트를 권한부여하고 클라이언트가 선택된 콘텐트 및/또는 서비스들로의 액세스를 얻는 것을 허용하는 애플리케이션 서버(106)에 의해 사용되는 정보를 포함하는 클라이언트(102)로 보낸다. 따라서, 클라이언트(102)는 제 3 자 서버 정보에 기초하여 클라이언트의 권한부여를 결정하기 위해 애플리케이션 서버가 시도할 때 애플리케이션 서버(106)에 의해 단지 후에 거부될 제 3 자 서버(140)로부터의 콘텐트 및/또는 서비스들에 대한 권한부여 데이터를 참조하고 권한부여 요청을 회피한다.
한 실시예에서, 제 3 자 애플리케이션 서버(140)는 부가적으로 제 3 자 정보의 정보를 포함한다. 이러한 인증은 부가적으로 클라이언트(102)에 의해 애플리케이션 서버(106)로 전형적으로는 KEY_REQ 메세지에서 전달된다. 애플리케이션 서버(106)는 클라이언트를 권한부여하기 위해 사용된 정보가 실질적으로 제 3 자 서버(140)로부터 클라이언트로 공급되었고 다른 네트워크 엔티티로는 공급되지 않으며, 또는 클라이언트에 의해 생성된 일부 반대편 정보인, 클라이언트(102)에 의해 애플리케이션 서버로 공급된 제 3 자 서버 정보를 인증하기 위해 이러한 인증을 사용한다.
KEY_REQ 메세지를 애플리케이션 서버(106)로 제공하는 단계에서, 클라이언트(102)는 제 3 자 서버 정보와, 클라이언트로 제공되었는지의 인증을 포함한다. 애플리케이션 서버(106)는 KEY_REQ 메세지를 처리하며, 제 3 자 서버 정보를 인증하고, 클라이언트 권한부여를 검증하기 위해 정보를 사용한다. 한번 인증되고 검증되면, 애플리케이션 서버(106)는 위에서 설명된 바와 같이 KEY_REP를 생성한다.
도 3을 참조하면, 애플리케이션 서버로부터 콘텐트 및/또는 서비스들을 요청하고 사용할 때 클라이언트에 의해 사용하기 위해 클라이언트에 권한부여 데이터의 제 2 카피를 제공하기 위한 방법(200)의 흐름도가 도시된다. 예로써, 방법(200)은 위에서 설명된 시스템(100)과 적절한 메세지 타입들에 의해 구현될 수 있다. 단계(202)에서 TGT 티켓에 대한 요청이 클라이언트(102)와 같은 클라이언트로부터 수신된다. 단계(204)에서 TGT 티켓이 생성된다. 단계(204)에서 예를 들면, AS 서버(108)에 의해 수행될 수 있다. 단계(206)에서 TGT 티켓은 클라이언트로 보내진다. 이러한 단계는 또한 AS 서버(108)에 의해 수행될 수 있다. 한 실시예에서, 클라이언트는 권한부여 데이터의 클라이언트 카피가 AS_REP에 포함되면 권한부여 데이터의 클라이언트 카피를 추출한다. 단계(208)에서 특정 애플리케이션 서버에 대한 ST 티켓을 위한 요청이 클라이언트로부터 수신된다. ST 티켓에 대한 요청은 TGT 티켓을 포함하고 전형적으로 클리어한 부분의 클라이언트의 아이덴티티를 제공하지 않는다. 단계(210)에서 TGS_REP 메세지는 ST 티켓 내에서 암호화된 권한부여 데이터의 제 1 카피와, TGT 티켓으로부터의 세션 키를 사용하여 암호화된 권한부여 데이터의 제 2 카피로 ST 티켓을 포함하여 생성된다. 한 실시예에서, TGS_REP의 생성은 TGS 서버(110)에 의해 수행된다. 단계(212)에서, TGS_REP 메세지는 권한부여 데이터의 두 카피들 모두로 클라이언트로 보내지고, 이는 또한 TGS 서버(110)에 의해 수행될 수 있다. 단계(214)에서, 클라이언트는 TGS_REP를 수신한다. 단계(216)에서, 클라이언트는 적어도 권한부여 데이터의 제 2 카피를 TGS_REP로부터 추출한다. 단계(220)에서, 클라이언트는 또한 권한부여 데이터의 제 1 카피를 포함하는 ST 티켓을 포함하는 KEY_REQ 메세지를 생성하고 보낸다. 단계(222)에서, 애플리케이션 서버는 KEY_REQ를 수신하고 처리한다. 애플리케이션 서버는 ST 티켓을 추출하고, ST 티켓을 해독하며 권한부여 데이터의 제 1 카피를 유효화시킨다. 단계(224)에서, 애플리케이션 서버는 KEY_REP 메세지를 생성하고 KEY_REP 메세지를 클라이언트로 보낸다. 단계(226)에서 클라이언트는 KEY_REP 메세지를 검증하고 그를 KEY_REQ 메세지와 매칭한다.
도 4는 도 3에 도시된 프로세스(200)와 유사한, 프로세스(240)의 하나의 구현의 간략화된 흐름도를 도시한다. 단계(242)에서, 클라이언트는 TGT 티켓 요청을 보낸다. 단계(244)에서, KDC(104)는 TGT 티켓을 생성한다. 단계(446)에서, KDC(104)는 클라이언트 권한부여 데이터의 클라이언트 카피를 갖는 TGT 티켓을 보낸다. 단계(248)에서, 클라이언트는 TGT 티켓을 수신하고 권한부여 데이터의 일반적인 클라이언트 카피를 추출한다. 단계(250)에서 클라이언트(102)는 ST 티켓을 요청하는 TGS_REQ를 보낸다. 단계(252)에서, KDC는 TGS_REP를 되돌린다. 단계(254)에서, 클라이언트는 TGS_REP를 수신하고 ST 티켓 및 권한부여 데이터의 서버 특정 제 2 카피를 추출한다. 단계(256)에서, 클라이언트는 권한부여를 초과하는 콘텐트 및/또는 서비스들의 요청을 회피하기 위해 원하는 콘텐트 및/또는 서비스들을 결정하고, 이후 권한부여 데이터의 클라이언트 카피를 액세스하며 원하는 콘텐트 및/또는 서비스들을 검증한다. 단계(256)에서, 클라이언트(102)는 콘텐트 및/또는 서비스들의 선택을 제 3 자 서버(140)로 제공한다. 단계(260)에서, 제 3 자 서버는 클라이언트를 권한부여하기 위해 사용된 제 3 자 정보를 포함하는 콘텐트 및/또는 서비스 선택 응답과, 이러한 정보의 인증(예를 들어, 암호화된 체크섬)을 보낸다. 제 3 자 정보는 클라이언트의 권한부여를 검증하기 위해 사용될 수 있는 정보; 예를 들면, 클라이언트에 의해 선택된 콘텐트의 신원, "신용 카드로의 변화", "클라이언트가 이러한 콘텐트를 저장하도록 허용하기"와 같은 콘텐트와 연관된 다양한 구매 옵션들, 및 다른 이러한 정보를 포함한다. 제 3 자 정보는 또한 정전 지역들의 리스트(예를 들면, 나라들, 주들, 또는 우편번호들에 기초한 정전 지역들)와 같은 콘텐트와 연관된 제한들 및 다른 이러한 제한들을 포함할 수 있다. 단계(262)에서, 클라이언트(102)는 KEY_REQ 메세지를 권한부여 데이터를 초과하지 않는 애플리케이션 서버(106)로 보낸다. KEY_REQ 메세지는 그의 인증과 ST 티켓을 따라 제 3 자 정보를 포함하며, 또한 권한부여 데이터의 제 1 카피를 포함한다. 단계(264)에서, 애플리케이션 서버(106)는 정보를 인증하고, 제 3 자 정보와 권한부여 데이터의 제 1 카피를 사용하여 콘텐트 및/또는 서비스들에 대한 클라이언트 권한부여를 검증한다. 단계(266)에서, 애플리케이션 서버(106)는 KEY_REP를 클라이언트(102)로 보낸다.
도 5는 애플리케이션 서버로부터 콘텐트 및/또는 서비스들을 요청하고 수신하는 클라이언트에 대한 프로세스(310)의 하나의 구현의 간략화된 흐름도를 도시한다. 한 실시예에서, 권한부여 데이터의 제 2 카피를 갖는 클라이언트를 공급하는 것에 대하여, 도 3에 도시된 바와 같이 프로세스(310)는 프로세스(200)의 단계(226) 뒤에 온다. 단계(312)에서, 클라이언트(102)와 같은 클라이언트는 어떤 콘텐트 및/또는 서비스들이 바람직한지를 결정한다. 예를 들어, 클라이언트는 사용자 또는 다른 네트워크 엔티티로부터 콘텐트에 대한 요청을 수신한다. 단계(314)에서, 클라이언트는 콘텐트에 대한 요청을 앞서 얻어지고 저장된 권한부여 데이터의 제 2 카피로 체크하고 비교하는 것에 의해 요청이 권한부여되는지 및 권한부여된 사용을 초과하지 않는지를 확실히 하기 위해 콘텐트 및/또는 서비스들에 대한 요청을 검증한다. 클라이언트가 한번 요청되면, 클라이언트는 CON_REQ 메세지를 생성한다. 단계(316)에서, 클라이언트는 암호화된 체크섬을 암호화하고 인증하며, CON_REQ 메세지를 애플리케이션 서버(106)(또는 제 3 자 서버(140))와 같은 애플리케이션 서버로 보낸다. 단계(320)에서, 애플리케이션 서버는 CON_REQ 메세지를 해독하고 ST 티켓에서 발견된 권한부여 데이터의 제 1 카피에서 정의된 바와 같이 클라이언트의 권한부여된 액세스 뿐만 아니라 암호화된 체크섬에 기초하여 요청을 유효화한다. 단계(322)에서, 애플리케이션 서버는 ST 티켓 및 권한부여 데이터가 검증되면 요청된 콘텐트 및/또는 서비스를 암호화하고 보낸다. 한 실시예에서, 애플리케이션 서버는 복수의 상이한 패킷들로 요청된 콘텐트를 보내서, 전체적으로 원하는 콘텐트는 하나의 패킷에 포함되지 않으나 몇몇의 패킷들에 포함된다. 단계(324)에서, 클라이언트는 요청된 콘텐트를 수신하고 데이터를 처리한다. 단계(330)에서, 클라이언트는 권한부여 데이터의 제 2 카피를 액세스하고 이는 클라이언트가 콘텐트 및/또는 서비스들의 카피를 저장할 수 있다는 것이 결정되면 저장한다. 단계(332)에서, 클라이언트는 클라이언트가 권한부여되면 콘텐트 및/또는 서비스들을 저장한다. 그렇지 않으면, 클라이언트는 그가 제 1 시간에서 수신될 때 콘텐츠로의 액세스가 허용되고, 프로세스는 부가적인 콘텐트를 검색하도록 단계(340)로 진행한다. 즉, 단계(334)는 클라이언트가 하나 보다 많은 콘텐트로 재생될 수 있다는 것을 결정하도록 입력된다. 그렇다면, 단계(336)는 클라이언트가 한번 이상 콘텐트를 액세스하고 재생할 수 있도록 입력된다. 단계(340)에서, 프로세스는 수신될 부가적인 콘텐트 및/또는 서비스들이 있는지를 결정한다. 그렇다면, 프로세스(310)는 부가적인 콘텐트 및/또는 서비스들을 수신하도록 단계(324)로 되돌아간다. 단계(336)에서, 프로세스(310)가 종결한 더이상의 데이터 및/또는 콘텐트가 없다는 것이 결정된다.
본 발명은 클라이언트가 권한부여 데이터의 그 자신의 카피를 저장하고 액세스하는 것을 허용하는 방법, 시스템, 장치, 프로그램 및 컴퓨터 프로그램 제품을 제공한다. 이는 개선된 사용자 인터페이스, 감소된 에러들, 개선된 효율 및 콘텐트 및/또는 서비스 배달의 최적화를 제공한다. 또한, 클라이언트가 권한부여 데이터의 그 자신의 카피를 액세스하는 것을 허용하는 것은 클라이언트가 배달된 콘텐트 및/또는 서비스들의 처리와 사용에 대한 결정들을 만드는 것을 허용한다. 또한, 대량의 통신 필요성이 감소하며 전체적인 네트워크 트래픽도 감소한다. 한 실시예에서, 본 발명은 모토로라에 의해 개발된 IP 권리들의 관리 시스템의 일부로서, 모토로라에 의해 개발된 전자 보안 브로커(ESBroker) 프로토콜에서 구현된다.
본 발명은 특정 실시예들 및 그의 애플리케이션들에 의해 설명되었으나, 다양한 변경들 및 변화들이 청구항들에서 설명된 본 발명의 범주로부터 벗어남이 없이 당업자에 의해 생성될 수 있다.

Claims (24)

  1. 애플리케이션 서버로부터 콘텐트 및/또는 서비스들의 요청시 클라이언트 권한부여(authorization)를 검증하는 방법에 있어서,
    클라이언트로부터 서비스 티켓 요청을 수신하는 단계로서, 상기 서비스 티켓 요청은 이전에 상기 클라이언트에 제공된 티켓 승인 티켓(ticket granting ticket)을 포함하는, 상기 수신 단계와;
    권한부여 데이터의 제 1 카피를 포함하는 서비스 티켓을 생성하는 단계와;
    상기 권한부여 데이터의 제 2 카피를 클라이언트로 전송하는 단계로서, 상기 권한부여 데이터의 제 2 카피는 상기 클라이언트로 전송될 때 암호화되고 티켓에 포함되지 않는, 상기 제 2 카피 전송 단계와;
    상기 서비스 티켓을 상기 클라이언트로 전송하는 단계로서, 상기 서비스 티켓은 상기 권한부여 데이터의 제 1 카피를 포함하는, 상기 서비스 티켓 전송 단계를 포함하는, 방법.
  2. 제 1 항에 있어서,
    상기 서비스 티켓과 상기 권한부여 데이터의 상기 제 2 카피를 포함하는 인증 서버 응답 메시지(authentication server reply message)을 생성하는 단계와;
    상기 인증 서버 응답 메시지를 상기 클라이언트로 전송하는 단계를 더 포함하는, 방법.
  3. 제 1 항에 있어서,
    상기 서비스 티켓을 포함하는 티켓 승인 서버 응답 메시지(ticket granting server reply message)을 생성하는 단계와;
    상기 티켓 승인 서버 응답을 상기 클라이언트로 전송하는 단계를 더 포함하는, 방법.
  4. 삭제
  5. 제 3 항에 있어서,
    상기 권한부여 데이터의 상기 제 2 카피를 포함하는 인증 서버 응답 메세지를 생성하는 단계와;
    상기 권한부여 데이터의 상기 제 2 카피를 상기 클라이언트로 전송하는 단계를 포함하는 상기 인증 서버 응답 메시지를 상기 클라이언트로 전송하는 단계를 더 포함하는, 방법.
  6. 삭제
  7. 삭제
  8. 삭제
  9. 삭제
  10. 삭제
  11. 삭제
  12. 삭제
  13. 삭제
  14. 삭제
  15. 시스템을 통해 보안 통신을 제공하기 위한 시스템에 있어서,
    티켓 승인 티켓을 클라이언트에게 발행하도록 구성된 키 분배 센터(key distribution center) 제 1 단과;
    상기 클라이언트로부터 수신된 티켓 승인 티켓에 응답하여 권한부여 데이터의 적어도 두 개의 카피들을 포함하는 티켓 승인 서버 응답을 생성하도록 구성되는 키 분배 센터 제 2 단으로서, 권한부여 데이터의 적어도 하나의 카피는 상기 클라이언트에 전송될 때 암호화되고 티켓에 포함되지 않는, 상기 키 분배 센터 제 2 단을 포함하는, 시스템.
  16. 제 15 항에 있어서,
    상기 클라이언트는 상기 티켓 승인 서버 응답을 수신하고, 권한부여를 검증하도록 상기 권한부여 데이터의 하나의 카피를 사용하도록 구성되는, 시스템.
  17. 제 16 항에 있어서,
    상기 클라이언트는 애플리케이션 서버와 결합되고, 상기 애플리케이션 서버는 콘텐트를 상기 클라이언트로 공급하도록 구성되고, 또한 상기 클라이언트는 상기 콘텐트의 권한부여된 사용을 검증하도록 상기 권한부여 데이터의 하나의 카피를 사용하도록 구성된, 시스템.
  18. 제 3 항에 있어서,
    클라이언트 세션 키를 사용하여 권한부여 데이터의 제 2 카피를 암호화하는 단계를 더 포함하는, 방법.
  19. 제 18 항에 있어서,
    서버 서비스 키를 사용하여 서비스 티켓을 암호화하는 단계를 더 포함하는, 방법.
  20. 제 18 항에 있어서,
    상기 클라이언트 세션 키를 사용하여 암호화하는 단계는 인증 서버 응답 메시지에서 티켓 승인 티켓으로부터 세션 키를 사용하는 단계를 포함하는, 방법.
  21. 삭제
  22. 제 3 항에 있어서,
    상기 클라이언트가 원하는 콘텐트를 결정하는 단계와,
    상기 클라이언트가 상기 원하는 콘텐트를 상기 권한부여 데이터의 상기 제 2 카피로 검증하는 단계와,
    상기 클라이언트가 콘텐트에 대한 요청을 생성하는 단계와,
    상기 클라이언트가 상기 콘텐트에 대한 요청을 제 3 자 서버로 전송하는 단계와,
    상기 제 3 자 서버가 제 3 자 정보를 어플리케이션 서버에 의해 요청된 콘텐트에 대한 클라이언트 권한부여를 결정하는데 나중에 사용되는 상기 클라이언트로 전송하는 단계를 더 포함하는, 방법.
  23. 제 3 항에 있어서,
    상기 클라이언트로부터 키 요청 메시지를 수신하는 단계와,
    키 응답 메시지를 생성하는 단계와,
    상기 키 응답 메시지를 상기 클라이언트로 전달하는 단계와,
    상기 클라이언트가 콘텐트에 대한 요청을 생성하는 단계와,
    상기 클라이언트가 상기 권한부여 데이터의 제 2 카피로 콘텐트에 대한 요청을 검증하는 단계와,
    상기 클라이언트가 콘텐트에 대한 상기 요청에 에러들이 없다는 것을 검증하면, 상기 클라이언트가 콘텐트에 대한 상기 요청을 어플리케이션 서버로 전송하는 단계를 더 포함하는, 방법.
  24. 삭제
KR1020047012068A 2002-02-04 2003-01-02 키 관리 프로토콜에 권한부여의 클라이언트 승인을 제공하기 위한 시스템 및 방법 KR101132148B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10/067,446 US7231663B2 (en) 2002-02-04 2002-02-04 System and method for providing key management protocol with client verification of authorization
US10/067,446 2002-02-04
PCT/US2003/000084 WO2003067801A2 (en) 2002-02-04 2003-01-02 Key management with client verification of authorization

Publications (2)

Publication Number Publication Date
KR20040101219A KR20040101219A (ko) 2004-12-02
KR101132148B1 true KR101132148B1 (ko) 2012-04-03

Family

ID=27658851

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020047012068A KR101132148B1 (ko) 2002-02-04 2003-01-02 키 관리 프로토콜에 권한부여의 클라이언트 승인을 제공하기 위한 시스템 및 방법

Country Status (10)

Country Link
US (1) US7231663B2 (ko)
EP (1) EP1486025B1 (ko)
JP (1) JP4674044B2 (ko)
KR (1) KR101132148B1 (ko)
CN (1) CN1640092A (ko)
AT (1) ATE530973T1 (ko)
AU (1) AU2003207444A1 (ko)
CA (1) CA2475150C (ko)
MX (1) MXPA04007547A (ko)
WO (1) WO2003067801A2 (ko)

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7805606B2 (en) * 2002-07-29 2010-09-28 Bea Systems, Inc. Computer system for authenticating a computing device
US7900247B2 (en) * 2005-03-14 2011-03-01 Microsoft Corporation Trusted third party authentication for web services
US7937753B2 (en) * 2005-03-25 2011-05-03 Microsoft Corporation Method and apparatus for distributed information management
EP1833222A1 (en) * 2006-03-10 2007-09-12 Abb Research Ltd. Access control protocol for embedded devices
US8185576B2 (en) * 2006-03-14 2012-05-22 Altnet, Inc. Filter for a distributed network
CN101051898B (zh) * 2006-04-05 2010-04-21 华为技术有限公司 无线网络端到端通信认证方法及其装置
US8161164B2 (en) * 2006-04-28 2012-04-17 Microsoft Corporation Authorizing service requests in multi-tiered applications
JP5464794B2 (ja) * 2006-07-24 2014-04-09 コニカミノルタ株式会社 ネットワーク管理方法およびネットワーク管理システム
JP4983165B2 (ja) * 2006-09-05 2012-07-25 ソニー株式会社 通信システムおよび通信方法、情報処理装置および方法、デバイス、プログラム、並びに記録媒体
US20080098120A1 (en) * 2006-10-23 2008-04-24 Microsoft Corporation Authentication server auditing of clients using cache provisioning
EP1965558B1 (en) * 2007-03-01 2011-10-19 Mitsubishi Electric Corporation Method, apparatuses and computer program product for robust digest authentication using two types of nonce values
JP4448167B2 (ja) * 2007-12-28 2010-04-07 フェリカネットワークス株式会社 通信デバイス、リモートサーバおよび端末装置
CN101436930A (zh) * 2007-11-16 2009-05-20 华为技术有限公司 一种密钥分发的方法、系统和设备
JP4470071B2 (ja) * 2008-03-03 2010-06-02 フェリカネットワークス株式会社 カード発行システム、カード発行サーバ、カード発行方法およびプログラム
US8621598B2 (en) * 2008-03-12 2013-12-31 Intuit Inc. Method and apparatus for securely invoking a rest API
US8462954B2 (en) * 2008-05-30 2013-06-11 Motorola Mobility Llc Content encryption using at least one content pre-key
US8862872B2 (en) * 2008-09-12 2014-10-14 Qualcomm Incorporated Ticket-based spectrum authorization and access control
US8548467B2 (en) * 2008-09-12 2013-10-01 Qualcomm Incorporated Ticket-based configuration parameters validation
US9148335B2 (en) * 2008-09-30 2015-09-29 Qualcomm Incorporated Third party validation of internet protocol addresses
US9436763B1 (en) * 2010-04-06 2016-09-06 Facebook, Inc. Infrastructure enabling intelligent execution and crawling of a web application
US9432373B2 (en) * 2010-04-23 2016-08-30 Apple Inc. One step security system in a network storage system
WO2012126085A1 (en) * 2011-03-18 2012-09-27 Certicom Corp. Keyed pv signatures
EP2697783B1 (en) 2011-03-29 2014-06-11 Inventio AG Distribution of premises access information
US10333711B2 (en) * 2011-06-17 2019-06-25 Microsoft Technology Licensing, Llc Controlling access to protected objects
US9026784B2 (en) 2012-01-26 2015-05-05 Mcafee, Inc. System and method for innovative management of transport layer security session tickets in a network environment
US9003507B2 (en) * 2012-03-23 2015-04-07 Cloudpath Networks, Inc. System and method for providing a certificate to a third party request
CN104468074A (zh) * 2013-09-18 2015-03-25 北京三星通信技术研究有限公司 应用程序之间认证的方法及设备
US9729538B2 (en) * 2014-09-01 2017-08-08 Microsoft Israel Research And Development (2002) Ltd System, method and process for detecting advanced and targeted attacks with the recoupling of kerberos authentication and authorization
CN104836802B (zh) * 2015-04-24 2018-04-06 深圳墨麟科技股份有限公司 基于登陆服务器的登陆链接方法及系统
US10044726B2 (en) * 2015-05-07 2018-08-07 Cyberark Software Ltd. Systems and methods for detecting and reacting to malicious activity in computer networks
US10171447B2 (en) 2015-06-15 2019-01-01 Airwatch Llc Single sign-on for unmanaged mobile devices
US10812464B2 (en) 2015-06-15 2020-10-20 Airwatch Llc Single sign-on for managed mobile devices
US11057364B2 (en) * 2015-06-15 2021-07-06 Airwatch Llc Single sign-on for managed mobile devices
US10944738B2 (en) 2015-06-15 2021-03-09 Airwatch, Llc. Single sign-on for managed mobile devices using kerberos
ES2828948T3 (es) * 2015-07-02 2021-05-28 Telefonica Cibersecurity & Cloud Tech S L U Método, sistema y productos de programa informático para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas
US9450944B1 (en) 2015-10-14 2016-09-20 FullArmor Corporation System and method for pass-through authentication
US9762563B2 (en) 2015-10-14 2017-09-12 FullArmor Corporation Resource access system and method
US9509684B1 (en) * 2015-10-14 2016-11-29 FullArmor Corporation System and method for resource access with identity impersonation
US11063753B2 (en) * 2019-03-20 2021-07-13 Arris Enterprises Llc Secure distribution of device key sets over a network
JP7395938B2 (ja) * 2019-10-09 2023-12-12 富士フイルムビジネスイノベーション株式会社 情報処理装置、情報処理システム及びプログラム
CN113037477A (zh) * 2021-03-08 2021-06-25 北京工业大学 一种基于Intel SGX的Kerberos安全增强方法
GB2607289A (en) * 2021-05-28 2022-12-07 Mastercard International Inc Data management and encryption in a distributed computing system
CN113922952B (zh) * 2021-09-30 2024-03-01 恒众创美(深圳)发展合伙企业(有限合伙) 访问请求响应方法、装置、计算机设备和存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5757920A (en) * 1994-07-18 1998-05-26 Microsoft Corporation Logon certification

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2519390B2 (ja) * 1992-09-11 1996-07-31 インターナショナル・ビジネス・マシーンズ・コーポレイション デ―タ通信方法及び装置
US5590199A (en) * 1993-10-12 1996-12-31 The Mitre Corporation Electronic information network user authentication and authorization system
US5455953A (en) * 1993-11-03 1995-10-03 Wang Laboratories, Inc. Authorization system for obtaining in single step both identification and access rights of client to server directly from encrypted authorization ticket
US6301661B1 (en) 1997-02-12 2001-10-09 Verizon Labortories Inc. Enhanced security for applications employing downloadable executable content
JP2000010930A (ja) * 1998-06-24 2000-01-14 Hitachi Ltd ネットワークシステムでのアクセス制御方法
US7340600B1 (en) * 2000-01-14 2008-03-04 Hewlett-Packard Development Company, L.P. Authorization infrastructure based on public key cryptography
US6993652B2 (en) * 2001-10-05 2006-01-31 General Instrument Corporation Method and system for providing client privacy when requesting content from a public server

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5757920A (en) * 1994-07-18 1998-05-26 Microsoft Corporation Logon certification

Also Published As

Publication number Publication date
US7231663B2 (en) 2007-06-12
WO2003067801A3 (en) 2004-10-14
EP1486025B1 (en) 2011-10-26
CA2475150C (en) 2013-03-26
JP4674044B2 (ja) 2011-04-20
CN1640092A (zh) 2005-07-13
EP1486025A4 (en) 2005-08-03
US20030149871A1 (en) 2003-08-07
JP2005517347A (ja) 2005-06-09
AU2003207444A8 (en) 2003-09-02
AU2003207444A1 (en) 2003-09-02
MXPA04007547A (es) 2004-11-10
EP1486025A2 (en) 2004-12-15
WO2003067801A2 (en) 2003-08-14
KR20040101219A (ko) 2004-12-02
ATE530973T1 (de) 2011-11-15
CA2475150A1 (en) 2003-08-14

Similar Documents

Publication Publication Date Title
KR101132148B1 (ko) 키 관리 프로토콜에 권한부여의 클라이언트 승인을 제공하기 위한 시스템 및 방법
US6993652B2 (en) Method and system for providing client privacy when requesting content from a public server
CA2475216C (en) Method and system for providing third party authentification of authorization
US10554393B2 (en) Universal secure messaging for cryptographic modules
US7610617B2 (en) Authentication system for networked computer applications
US20030188156A1 (en) Using authentication certificates for authorization
EP1249983A2 (en) Methods and arrangements for protecting information in forwarded authentication messages
US20030208681A1 (en) Enforcing file authorization access
JP2005510184A (ja) 機密保護インターネット・プロトコル権利管理アーキテクチャ用の鍵管理プロトコルおよび認証システム
JPH05298174A (ja) 遠隔ファイルアクセスシステム
WO2005055516A1 (en) Method and apparatus for data certification by a plurality of users using a single key pair

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20150309

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20160310

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20170317

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20180309

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20190314

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20200313

Year of fee payment: 9