KR101393012B1

KR101393012B1 - 라이센스 관리 시스템 및 방법

Info

Publication number: KR101393012B1
Application number: KR1020070066609A
Authority: KR
Inventors: 이재원; 김희열; 윤현수; 정병천; 이윤호
Original assignee: 삼성전자주식회사
Priority date: 2007-07-03
Filing date: 2007-07-03
Publication date: 2014-05-12
Anticipated expiration: 2027-07-03
Also published as: EP2012494B1; KR20090003705A; US8006085B2; JP2009015852A; US20090013177A1; EP2012494A2; CN101340278B; CN101340278A; EP2012494A3

Abstract

라이센스 관리 시스템 및 방법을 제공한다. 대리인증서 발급 방법은 라이센스 매니저가 라이센스 발급 권한을 위임 받기 위한 요청 메시지를 라이센스 서버로 전송하는 단계와 라이센스 서버가 요청 메시지를 검증하는 단계와 요청 메시지가 유효할 경우 라이센스 서버가 라이센스 발급 권한에 대한 정보를 포함하는 대리인증서를 라이센스 매니저로 전송하는 단계 및 라이센스 매니저가 대리인증서를 검증하는 단계를 포함한다.

DRM(Digital Rights Management), 컨텐츠, 라이센스

Description

라이센스 관리 시스템 및 방법{System and method for management of license}

본 발명은 라이센스 관리 시스템 및 방법에 관한 것으로서, 더욱 상세하게는 디지털 컨텐츠(이하, 컨텐츠)의 내용에 따른 디바이스의 다양한 접근 권한 제어 및 효율적인 라이센스 관리를 위한 라이센스 관리 시스템 및 방법에 관한 것이다.

디지털 저작권 관리(DRM; Digital Rights Management)의 기본 개념은 컨텐츠를 정상적으로 구매한 사용자가 해당 컨텐츠를 사용할 수 있게 하기 위함이다. 초기 시스템들은 한 사용자를 하나의 디바이스에 바인딩 함으로써 오직 해당하는 디바이스만이 구매한 컨텐츠를 사용할 수 있는 방향으로 개발되어 왔다. 그러나, 가전 기술의 발달과 유비쿼터스 환경의 발전으로 인해 한 사용자가 동일한 컨텐츠를 여러 디바이스에서 사용할 필요성이 대두되었다.

이를 지원하기 위해 생겨난 개념이 인증된 도메인(AD; Authorized Domain) 이며, AD 개념은AD에 속한 디바이스들 간에는 제약 없이 컨텐츠를 공유할 수 있게 하고, AD에 속하지 않은 디바이스에는 컨텐츠 공유에 제약이 가해진다. 이러한 AD의 대표적인 예로써 네트워크 환경을 들 수 있다. AD 개념을 지원하는 대표적인 DRM 시스템으로는 Thomson 사의 Smart Right 시스템, Open Mobile Alliance(OMA) DRM 표준, 그리고 IBM 사의 xCP 등을 들 수 있다.

OMA DRM이나 xCP의 경우는 이하 도 1과 같이 중앙 라이센스 서버가 각각의 모든 도메인을 직접 관리한다. 즉 디바이스가 특정 도메인에 가입하고자 할 경우는 중앙 라이센스 서버와 협상을 통해서 가능하며, 특정 도메인에 가입 허가를 받은 경우에는 라이센스 서버로부터 그 도메인에 대응되는 도메인 키를 전달받게 된다. 이하 보다 구체적으로 설명하기로 한다.

도 1 및 도 2는 종래 복수개의 디바이스가 네트워크를 구성하는 예를 도시한다.

도 1은 네 개의 디바이스(D1, D2, D3, D4)가 하나의 네트워크(Home_A)(12)를 구성하는 예를 나타낸다. 네트워크(Home_A)(12)는 AD_1과 AD_2 라는 두 개의 도메인을 구성하고 있으며, AD_1의 경우는 D1, D2, D3, D4 즉, 네트워크 내의 모든 디바이스를 포함하고 도메인 키(DK_1)을 공유하고 있다. AD_2의 경우는 네트워크의 일부 디바이스인 D3와 D4만을 포함하고 도메인 키(DK_2)를 공유하고 있다. AD_1과 AD_2를 구분하는 이유는 컨텐츠의 용도에 따라 필요 시 접근 제어를 하기 위함이다.

한편, Smart Right 시스템의 경우는 OMA DRM이나 xCP와는 달리 중앙 라이센스 서버(10)의 도움 없이 디바이스들 간에 직접 자신의 인증된 도메인을 구성한다.

도 2는 디바이스(D1, D2, D3, D4)가 하나의 네트워크(Home_B)(14)를 구성하는 예를 나타낸다. 네트워크(Home_B)(14)는 디바이스 D2, D3, D4로 구성된 하나의 도메인 AD_3를 구성하고 있으며 도메인 키 DK_3을 공유하고 있다. 디바이스 D1은 외부 컨텐츠 공급자로부터 자신만이 해독할 수 있는 형태로 암호화된 컨텐츠를 수신하고 AD_3 내의 디바이스들이 재생할 수 있는 형태로 라이센스를 재 포장하여 공급하는 역할을 담당한다. 이러한 과정에서 D1은 AD_3의 도메인 키(DK_3)를 모르기 때문에 AD_3내의 디바이스의 도움을 필요로 한다.

그러나, 기존 DRM 시스템의 인증된 도메인 관리 방법에는 다음과 같은 문제점이 존재한다.

먼저 도메인 관리 관점에서 보면, OMA DRM이나 xCP와 같이 중앙 라이센스 서버에 의한 도메인 관리 방법은 중앙의 라이센스 서버가 각각의 모든 도메인을 관리해야 하므로 라이센스 서버에 관리 부담을 줄 수 있으며, 또한 사용자의 입장에서 자신의 도메인에 등록된 모든 디바이스에 관한 정보를 중앙의 라이센스 서버가 알 수 있으므로 자신의 도메인에 대한 프라이버시 침해 문제가 발생할 수 있다.

한편, 컨텐츠 관리 관점에서 보면, 기본적으로 하나의 도메인은 하나의 도메인 키로 바인딩 되어 있으므로 각 디바이스에 대해 컨텐츠에 따른 유연한 접근 권한 제어가 힘들다. OMA DRM이나　xCP의 경우는 하나의 네트워크에 여러 개의 AD를 허용하는 방식으로 부분적으로 해결하고 있으나, 정교한 접근 권한 제어는 제공하기 힘들며, 이는 중앙 라이센스 서버의 관리부담을 증대시키게 된다. 그리고, Smart Right 시스템의 경우는 개별 디바이스의 접근 권한을 제어하는 기능을 제공하지 않는다.

본 발명은 라이센스 관리 시스템 및 방법을 제공하여, 디지털 컨텐츠의 내용에 따른 디바이스의 다양한 접근 권한 제어 및 효율적인 라이센스 관리를 제공하는 데에 그 목적이 있다.

본 발명의 목적들은 이상에서 언급한 목적들로 제한되지 않으며, 언급되지 않은 또 다른 목적들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.

상기 목적을 달성하기 위하여, 본 발명의 실시예에 따른 대리인증서 발급 방법은 라이센스 매니저가 라이센스 발급 권한을 위임 받기 위한 요청 메시지를 라이센스 서버로 전송하는 단계와 라이센스 서버가 요청 메시지를 검증하는 단계와 요청 메시지가 유효할 경우 라이센스 서버가 라이센스 발급 권한에 대한 정보를 포함하는 대리인증서를 라이센스 매니저로 전송하는 단계 및 라이센스 매니저가 대리인증서를 검증하는 단계를 포함한다.

본 발명의 실시예에 따른 대리인증서 갱신 방법은 라이센스 매니저가 라이센스 발급 권한에 대한 정보를 포함하는 대리인증서에 대한 갱신 요청 메시지를 라이센스 서버로 전송하는 단계와 라이센스 서버가 갱신 요청 메시지를 검증하는 단계와 갱신 요청 메시지가 유효할 경우 라이센스 서버가 OCSP(Online Certificate Status Protocol) 서버에 대리인증서의 유효 여부를 질의하는 단계 및 라이센스 서 버가 OCSP로부터 대리인증서가 유효하다는 응답을 받은 경우 새로운 대리인증서를 라이센스 매니저로 전송하는 단계를 포함한다.

본 발명의 실시예에 따른 대리인증서 유효성 검증 방법은 디바이스가 대리인증서의 유효성 검증을 위한 요청 메시지를 라이센스 매니저로 전송하는 단계와 라이센스 매니저가 요청 메시지를 OCSP(Online Certificate Status Protocol) 서버로 전송하는 단계와 OCSP 서버가 대리인증서의 유효성 검증 결과에 대한 응답 메시지를 라이센스 매니저로 전송하는 단계 및 라이센스 매니저가 디바이스로 응답 메시지를 전송하는 단계를 포함한다.

본 발명의 실시예에 따른 라이센스 매니저는 라이센스 발급 권한에 대한 정보를 포함하는 대리인증서를 요청하기 위한 제1 요청 메시지 또는 대리인증서의 갱신을 요청하기 위한 제2 요청 메시지를 생성하는 제1 생성부 및 제1 요청 메시지에 따라 라이센스 서버로부터 수신한 대리인증서를 검증하거나 제2 요청 메시지에 따라 라이센스 서버로부터 수신한 새로운 대리인증서를 검증하는 제1 검증부를 포함한다.

본 발명의 실시예에 따른 라이센스 서버는 라이센스 매니저로부터 수신한 라이센스 발급 권한에 대한 정보를 포함하는 대리인증서에 대한 제1 요청 메시지 또는 대리인증서의 갱신을 위한 제2 요청 메시지를 검증하는 제2 검증부 및 제1 요청 메시지가 유효할 경우 대리인증서를 생성하거나 제2 요청 메시지가 유효할 경우 새로운 대리인증서를 생성하는 제2 생성부를 포함한다.

기타 실시예들의 구체적인 사항들은 상세한 설명 및 도면들에 포함되어 있 다.

본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예를 상세히 설명하기로 한다.

상기한 바와 같은 본 발명의 라이센스 관리 시스템 및 방법에 따르면 다음과 같은 효과가 하나 혹은 그 이상 있다.

첫째, 네트워크 내의 컨텐츠 공유를 위한 라이센스 관리 문제를 네트워크 내부 즉, 라이센스 매니저(LLM)에 인양함으로써 기존 DRM 시스템의 문제점으로 지적할 수 있는 네트워크 내의 디바이스들에 대한 프라이버시 보호 문제를 해결할 수 있는 장점이 있다.

둘째, 라이센스 매니저가 라이센스를 각각의 디바이스에 대해 발급할 수 있으므로 컨텐츠의 내용에 따른 디바이스의 다양한 접근 권한 제어를 수행할 수 있는 장점도 있다.

셋째, 유효기간을 짧게 설정하거나 또는 재생 횟수에 제한을 가하여 라이센스를 발급함으로써 프리뷰(preview) 형식으로 임시적으로 컨텐츠를 재생할 수 있고, 프리뷰를 통한 컨텐츠 시장의 잠재적 구매자를 확대하는 기대효과를 가져올 수 있는 장점도 있다.

넷째, 외부의 라이센스 서버로부터 위임받은 라이센스 발급 권한을 갱신 및 해지할 수 있는 방법을 제공하는 장점도 있다.

다섯째, 라이센스 매니저가 악의적인 사용자에 의해 공격 당하여 해당 라이센스의 무분별한 발급과 같은 바람직하지 않은 동작을 수행하는 상황에서도 각각의 디바이스는 라이센스 매니저를 경유하여 라이센스 매니저의 권한 위임의 유효성 여부를 검증할 수 있는 장점도 있다.

도 3은 본 발명의 일 실시 예에 따른 라이센스 서버(LS; License Server)가 라이센스 매니저(LLM; Local License Manager)에 라이센스 발급 권한을 위임하는 과정을 나타낸다. 그리고, 도 4는 본 발명의 일 실시 예에 따른 대리위임 요청 메시지의 양식의 예를 도시한다. 이하, 도 3 및 도 4를 기초로 보다 구체적으로 설명하기로 한다.

도 3에 있어서, 본 실시 예의 기반이 되는 대리권한 위임 방식은 X. 509 대리인증서 표준을 위한　RFC 3820, “Internet X. 509 PKI Proxy Certificate Profile”에 있는 인증서를 통한 위임 방식(delegation by certificate) 중 소지자 대리(bearer-proxy) 방식을 응용할 수 있다. 구체적인 위임 절차는 다음과 같다.

먼저 라이센스 매니저(310)는 대리서명 생성과 검증에 사용될 대리 개인키(SK_Proxy), 및 대리 공개키(PK_Proxy)을 생성한다.

라이센스 매니저(310)는 도 4와 같은 구조를 갖는 대리위임 요청 메시지(ProxyReq_LLM)(400)를 생성한다. 대리위임 요청 메시지(400)는 자신의 신원(subject)과 대리 공개키(PK_Proxy) 등의 정보를 포함하며, 네트워크에서 라이센스의 대리 생성에 관한 규칙(예를 들어, 권한 기간, 라이센스 개수, 발급 대상 등)을 명시할 수 있다. 또한, 대리위임 요청 메시지(400)는　대리 공개키(PK_Proxy)를 대리 개인키(SK_Proxy)로 서명하여 얻은 서명 값(SIG_Proxy)(402)을 포함할 수 있다. 여기서 서명 값(SIG_Proxy)(402)을 포함하는 이유는 대리 공개키에 대응되는 대리 개인키를 자신이 소유하고　있음을 증명하기 위해서이다.

이러한 대리위임 요청 메시지(400)의 내용들은 라이센스 매니저(310)의 개인키(SK_LLM)로 다시 서명되며, 라이센스 매니저(310)는 서명 값(SIG_LLM)(404)이 첨부된 대리위임 요청 메시지(400)를 라이센스 서버(300)에 전송한다(S301).

다음으로, 라이센스 서버(300)는 수신한 상기 대리위임 요청 메시지(400)를 검증한다(S311). 즉, 라이센스 서버(300)는 라이센스 매니저(310)의 공개키(PK_LLM)로 서명 값(SIG_LLM)(404)이 유효한지　검증한 다음, 대리위임 요청 메시지(400)에 포함되어 있는 대리 공개키(PK_Proxy)를 이용하여 서명 값(SIG_Proxy)(402)을 검증한다.

다음으로 대리위임 요청 메시지(400)가 유효하면, 라이센스 서버(300)는 라이센스 매니저(310)의 신원과 대리 공개키(PK_Proxy)를 바인딩하고, 디바이스들에 대해 라이센스를 발급할 수 있는 권한을 부여하기 위해 이하 도 5 와 같은 대리인증서(Cert_Proxy)(500)를 생성한다. 도 5는 본 발명의 일 실시 예에 따른 대리인증서(500)의 양식의 예를 도시한다. 대리인증서(500)는 권리 발급자(Issuer), 신원(subject), 일련번호(serial number), 대리 공개키, 유효 기간(validity period), 및 위임 정보(ProxyCertInfo)를 포함할 수 있다. 위임 정보는 권리 발급자가 라이센스 매니저(310)에 권한을 위임하는 구체적인 정보를 포함한다. 구체적으로 라이센스 발급 횟수, 권한 재위임 가능 여부 등의 정보가 위임 정보에 포함될 수 있으며, 해당 정보는 라이센스 매니저(310) 내 소정 모듈이 판독하게 된다.

위임된 권한의 내용과 제약 사항들은 XML 기반의 권한 기술 언어를 사용하여 기술될 수 있으며, 대리인증서(500)의 확장 필드 중 소정 필드(ProxyCertInfo)에 포함될 수 있다. 이렇게 생성된 대리인증서는 라이센스 서버(300)의 개인키(SK_LS)로 서명되어 서명 값(SIG_LS)(502)이 첨부된 후 라이센스 매니저(310)에 전송된다(S321).

다음으로, 라이센스 매니저(310)는 수신된 대리인증서(500)의 서명 값(SIG_LS)(502)을 라이센스 서버(300)의 공개키(PK_LS)로 검증한다(S331). 서명이 유효한 경우에는 대리 비밀키(SK_Proxy)를 이용하여 대리인증서(500)에 기술된 권한 내에서 디바이스에 라이센스를 발급할 수 있게 된다.

라이센스 매니저(310)가 컨텐츠를 디바이스들을 대신하여 구매하게 되면 라이센스 서버(300)는 컨텐츠 암호화 키와 해당 컨텐츠의 이용에 관한 권리, 제약 조건, 유효소비 기간 등이 명시된 라이센스를 라이센스 매니저(310)에 발급해준다. 라이센스 매니저(310)는 자신이 받은 라이센스를 바탕으로 디바이스들이 컨텐츠를 재생할 수 있도록 위임 받은 권한 즉, 대리 개인키(SK_Proxy)를 이용하여 라이센스를 재 포장한 후 발급해 준다.

대리인증서(500)는 유효기간이 만료되거나 라이센스 발급 횟수가 초과되면 효력이 중지된다. 따라서 라이센스 매니저(310)는 위임된 권한을 계속 유지하기 위해서는 대리인증서(500)의 유효기간이 만료되기 전 특정기간 안에 대리인증서를 갱신하여야 한다. 그러나 장시간 네트워크 연결이 원활하지 못했거나 또는 기타 사정으로 인하여 유효기간 만료 전에 갱신을 못한 경우라도 이후에 대리인증서는 갱신될 수 있다. 이러한 절차는 모두 자동으로 이루어질 수 있다.

도 6은 본 발명의 일 실시 예에 따른 대리인증서 갱신 과정을 도시한다. 그리고, 도 7은 본 발명의 일 실시 예에 따른 대리인증서 갱신 요청 메시지(700)의 양식의 예를 도시한다. 이하 도 6 및 도 7을 기초로 보다 구체적으로 설명하기로 한다.

라이센스 매니저(310)는 도 7과 같은 구조를 갖는 대리인증서 갱신 요청 메시지(ProxyRenewReq_LLM)(700)를 생성한다. 대리인증서 갱신 요청 메시지(700)는 자신의 신원과 대리인증서의 일련번호 등의 정보를 포함할 수 있으며, 이러한 메시지 내용들은 라이센스 매니저(310)의 개인키(SK_LLM)로 서명되어 상기 도 5의 대리인증서와 함께 라이센스 서버(300)에 전송될 수 있다(S601).

라이센스 서버(300)는 전달 받은 대리인증서 갱신 요청 메시지(700)를 검증한다(S611). 즉, 라이센스 서버(300)는 라이센스 매니저(310)의 공개키(PK_LLM)를 이용하여 서명 값(SIG_LLM)(404-1)을 검증하는 과정을 거치게 된다.

라이센스 서버(300)는 서명 값(SIG_LLM)(404-1)이 유효한 경우에 대리인증서의 일련번호를 이용하여 OCSP(Online Certificate Status Protocol) 프로토콜에 따라 OCSP 서버(320)에 대리인증서 유효 여부를 질의한다(S621).

그리고, 라이센스 서버(300)는 질의한 결과를 OCSP 서버(320)로부터 수신한다(S631). 전 단계(S621)는 라이센스 서버(300)가 관리하는 CRL(Certificate Revocation List)을 참조하는 방식으로 대체될 수 있다.

라이센스 서버(300)는 전 단계(S631)에서 받은 대리인증서 상태 결과가 유효한 경우, 단계 (S601)로부터 전달 받은 대리인증서의 유효 기간　또는 라이센스의 발급 가능한 횟수 등을 재 설정한 후 자신의 개인키(SK_LS)로 재 서명하여 새로운 대리인증서를 만든 후 라이센스 매니저(310)에 전송한다(S641).

라이센스 매니저(310)는 전송 받은 새로운 대리인증서의 서명 값(SIG_LS)을 라이센스 서버(300)의 공개키(PK_LS)로 검증한다(S651). 검증이 유효한 경우 라이센스 매니저(310)는 기존의 대리인증서는 삭제하고 새로운 대리인증서로 대체한다.

이러한 방식의 갱신 메커니즘은 대리 공개키를 변경하지 않고도 유효 기간만을 연장하는 효과를 가져오므로 시스템의 투명성을 증진시킬 수 있다. 한편, 본 실시 예의 갱신 메커니즘은 기존의 대리인증서는 폐기시키지 않으므로 일시적으로 두 개의 유효한 대리인증서가 존재할 수 있으나 기존의 대리인증서는 얼마 남지 않은 유효 기간이 지나면 무효화(폐기) 되므로 시스템의 안전성에는 문제가 되지 않는다.

대리인증서의 유효 기간 즉, 갱신 주기를 결정하는 정책은 시스템의 효율성과 시스템의 안전성이 상충관계에 있기 때문에 운용 전략에 따라 적절하게 선택해야 한다. 유효 기간을 짧게 설정하면 해킹 또는 기타 다른 이유로 인한 라이센스 매니저의 권한 오남용을 조기에 중단시킬 수 있는 반면에, 자주 대리인증서를 갱신하여야 하므로 전체 시스템의 성능 저하를 유발할 수 있다. 유효 기간을 길게 설정하면 반대의 효과가 발생한다. 따라서 시스템의 성능이 시스템의 안전성보다 우선시 된다면 유효 기간을 비교적 길게 설정하는 것이 유리하고, 시스템의 안전성이 더 중요하다면 유효 기간을 비교적 짧게 잡는 전략이 유리하다. 예를 들어, 현재 공인인증서의 유효기간이 1년인 점을 감안하면, 대리인증서의 유효기간은 1달 이내로 잡는 것이 적절할 것이다.

한편, 라이센스 매니저(310)에 부여한 권한을 해지하기 위해서나 또는 공격으로 인하여 라이센스 매니저(310)가 권한을 오남용이 이루어 지는 것이 감지 되었을 경우, 라이센스 서버(300)는 자신이 부여한 대리인증서를 OCSP 서버(320)에 폐기 등록하여야 한다. 이러한 절차는 라이센스 서버(300)에 의해 수행되며, 후술될 도 8 의 단계(S100)와 같은 OCSP 프로토콜의 폐기 인증서 등록과정을 통하여 OCSP 서버(320)에 등록된다. 폐기 인증서 등록과정은 종래의 기술 문서들을 참조하기 바란다.

도 8은 본 발명의 일 실시 예에 따른 대리인증서 유효성 검증 과정의 일 예를 나타낸다.

디바이스(D1, D2, ...)가 컨텐츠를 재생하기 위해서는 컨텐츠와 이에 대응하 는 라이센스가 필요하다. 라이센스는 라이센스 매니저(310)가 대리 권한을 이용하여 발급한 것이므로 컨텐츠를 재생하기 전에 그 대리 권한이 유효한지를 검증해야 한다. 이를 위해서는 OCSP 서버(320)에 질의를 통해 대리인증서의 유효성 유무를 검증하는 것이 바람직하다. 그러나 모든 디바이스가 외부의 OCSP 서버(320)와 직접 연결할 수 있는 능력을 갖추고 있다고 가정할 수 없으므로 이럴 경우는 OCSP와의 통신 방법을 갖고 있는 당사자인 라이센스 매니저(310)를 통하여 대리인증서의 유효성 유무를 검증 작업이 수행될 수 있다. 여기서, 전송 도중에 당사자인 라이센스 매니저(310)로부터 검사 결과 값이 조작될 수 있으며, 이에 대한 보완책이 마련되어야 한다. 이는 다음의 과정을 통해 달성될 수 있다.

디바이스(D2)는 자신의 신원과 자신의 공개키(PK_D2), 라이센스 매니저(310)의 대리인증서의 일련번호, 타임 스탬프(time stamp), 논스(nonce) 등의 정보를 포함한 대리인증서의 유효성 검증을 위한 요청 메시지를 생성한 다음 자신의 서명(SIG_D2)을 첨부하여 라이센스 매니저(310)에 전송한다(S801). 타임 스탬프(time stamp), 논스(nonce)등의 정보는 요청 메시지에 대한 리플레이(replay) 공격을 막기 위해 사용된다. 여기서, 디바이스(D2)는 상기와 같은 작업에 사용할 개인키(SK_D2)와 공개키(PK_D2) 쌍을 안전하게 저장하고 있어야 한다.

라이센스 매니저(310)는 대리인증서의 유효성 유무를 검증하기 위해 디바이스(D2)로부터 수신한 요청 메시지를 OCSP 서버(320)에 전달한다(S811).

OCSP 서버(320)는 수신한 요청 메시지에 포함된 디바이스의 서명의 유효성 여부를 디바이스(D2)의 공개키(PK_D2)로 검증하고, 서명이 유효할 경우 요청 메시 지에 포함된 대리인증서의 일련번호에 대응하는 인증서의 상태를 확인한다. 그리고, 대리인증서의 유효성 검증 결과에 대한 응답 메시지를 자신의 비밀키(SK_OCSP)로 서명하고, 디바이스(D2)의 공개키로 암호화하여 라이센스 매니저(310)에 전송한다(S821).

라이센스 매니저(310)는 수신한 응답 메시지를 디바이스(D2)에 전달한다(S831).

디바이스(D2)는 OCSP의 공개키(PK_OCSP)로 수신한 응답 메시지의 서명을 검증한 후, 서명이 유효한 경우에는 그 결과를 참조한다(S841). 그 결과가 유효할 경우 즉, 대리인증서가 유효할 경우 디바이스는 해당 라이센스로 컨텐츠를 재생하면 되고, 그렇지 않은 경우에는 대리인증서와 라이센스를 메모리에서 삭제하고 유효하지 않은 라이센스라는 것을 디스플레이에 표시하여 사용자에게 통보하고 컨텐츠는 재생하지 않는다.

상기 과정에서 전송되는 요청 메시지 및 응답 메시지는 암호화 되고 서명이 첨부되어 있으므로 중간에서 라이센스 매니저가 임의로 조작할 수 있는 가능성을 방지할 수 있다.

또한, 공격에 의해 라이센스 매니저가 상기와 같은 유효성 검증 과정을 수행하지 않는 경우 디바이스는 적절한 응답을 수신하지 못하게 됨으로써 라이센스 매니저(310)가 공격 당하여 유효하지 않음을 추론할 수 있다.

도 9은 본 발명의 일 실시 예에 따른 라이센스 관리를 위한 시스템 구성도의 예를 도시한다.

상술한 내용을 기초로 하여 본 발명의 시스템은 컨텐츠 제공자를 구성하는 라이센스 서버(300)와 컨텐츠 서버(CS; Contents Server)(303), 사용자 측의 네트워크를 구성하는 라이센스 매니저(310)와 미디어 서버(LMS; Local Media Server)(305), OCSP 서버(320)를 포함할 수 있다.

컨텐츠 서버(303)는 컨텐츠에 대한 지적 재산권을 소유하고 있는 컨텐츠 제공자가 운영하는 서버로서 컨텐츠에 대한 일차적인 배포를 수행할 수 있고, 라이센스 서버(300)는 컨텐츠 구매자에 대해 적법한 사용 권한을 명시한 라이센스를 발급하는 역할을 수행할 수 있다. 이 두개의 서버(303, 300)는 개념적으로 분리되어 있지만 실제 운영을 위하여 동일한 물리적 장치에서 동작할 수 있다. 즉, 상술된 바와 같이 라이센스 서버(300)가 컨텐츠 서버(303)의 기능을 포함할 수 있다.

컨텐츠 서버(303)는 컨텐츠를 DRM(Digital Rights Management)와 같은 방법에 의하여 암호화하는 등의　안전하게 포장한 컨텐츠를 네트워크 내의 미디어 서버(305)에 전송하는 역할을 수행할 수 있다.

라이센스 서버(300)는 상술한 바와 같이 구매한 컨텐츠에 대해 구매 조건에 맞는 접근 권한을 부여한 라이센스를 생성한다. 상기 라이센스에는 해당 컨텐츠가 디바이스에서 어떤 식으로 소비되어야 하는지 기술되어 있다.

상술된 실시 예에서 디바이스(D1, D2..)는 라이센스 서버(300)를 통해 직접 라이센스를 발급 받지 않고 네트워크 상에서 컨텐츠를 재생할 수 있으며, 해당 도메인을 관리하는 라이센스 매니저(310)를 통해 자체적으로 라이센스가 발급되어 디바이스에 제공될 수 있다.

즉, 라이센스 매니저(310)는 자신이 속한 네트워크를 대표하여 디바이스에 대해 라이센스를 발급할 수 있는 권한을 라이센스 서버(300)로부터 위임 받는다.

한편, OCSP 서버(320)는 개체인증서나 대리인증서의 유효성 여부를 질의 받아 인증서의 현 상태를 답변해주는 역할을 담당한다. 응답 메시지에는 OCSP의 서명이 첨부될 수 있다.

각 개체는 자신만의 개인키(SK), 공개키(PK) 쌍을 가지고 있으며 또한 자신의 공개키 인증을 위한 신뢰된 인증기관(CA)이 발급한 개체인증서를 포함할 수 있다. 또한, 두 개체가 통신을 원할 때는 먼저 PKI 기반의 상호 인증을 수행할 수 있다. 그 밖에 사용자 디바이스는 적법한 라이센스에 명시된 권한 내에서 컨텐츠를 재생할 수 있는 신뢰할 만한 에이전트에 의해 통제 받을 수 있다.

도 10은 본 발명의 일 실시 예에 따른 라이센스 매니저의 블록도이다.

라이센스 매니저(310)는 제1 생성부(313), 제1 검증부(315), 갱신부(317), 및 발급부(319)를 포함한다.

제1 생성부(313)는 라이센스 발급 권한에 대한 정보를 포함하는 대리인증서에 대한 요청 메시지를 생성한다. 즉, 라이센스 매니저는 대리인증서를 통해 라이센스 발급 권한을 위임 받을 수 있다. 또한, 제1 생성부(313)는 대리서명 생성과 검증에 사용될 대리 개인키(SK_Proxy), 및 대리 공개키(PK_Proxy)을 생성할 수 있다. 요청 메시지는　대리 공개키(PK_Proxy)를 대리 개인키(SK_Proxy)로 서명하여 얻은 서명 값(SIG_Proxy)을 포함할 수 있다. 또한, 제1 생성부(313)는 대리인증서에 대한 갱신 요청 메시지를 생성할 수 있다. 갱신 요청 메시지는 라이센스 매니저의 신원과 대리인증서의 일련번호 등의 정보를 포함할 수 있으며, 라이센스 매니저의 개인키(SK_LLM)로 서명되어 대리인증서와 함께 라이센스 서버에 전송될 수 있다.

제1 검증부(315)는 라이센스 서버로부터 수신한 라이센스 발급 권한에 대한 정보를 포함하는 대리인증서를 검증한다. 여기서, 제1 검증부(315)는 대리인증서의 서명 값(SIG_LS)을 라이센스 서버의 공개키(PK_LS)로 검증할 수 있다. 또한, 서명이 유효한 경우에는 대리 비밀키(SK_Proxy)를 이용하여 대리인증서에 기술된 라이센스 발급 권한 내에서 디바이스에 후술될 발급부(319)를 통해 라이센스를 발급할 수 있다. 또한, 제1 검증부(315)는 새로운 대리인증서를 수신한 경우 새로운 인증서의 서명 값(SIG_LS)을 라이센스 서버의 공개키(PK_LS)로 검증하고, 검증이 유효한 경우 후술될 갱신부(317)는 통해 기존의 대리인증서는 삭제하고 새로운 대리인증서로 대체할 수 있다.

갱신부(317)는 라이센스 서버로부터 새로운 대리인증서를 수신한 경우 기존의 대리인증서를 새로운 대리인증서로 대체한다. 여기서, 갱신부(317)는 아직 기존의 대리인증서의 유효 기간이 남아 있을 경우 자동으로 유효 기간이 만료되면 기존의 대리인증서를 폐기하고 새로운 대리인증서로 대체할 수 있다.

발급부(319)는 대리인증서에 기술된 라이센스 발급 권한 내에서 디바이스에 컨텐츠 이용을 위한 라이센스를 발급한다.

도 11은 본 발명의 일 실시 예에 따른 라이센스 서버의 블록도이다.

라이센스 서버(300)는 제2 검증부(303), 및 제2 생성부(305)를 포함한다.

제2 검증부(303)는 라이센스 매니저가 전송한 라이센스 발급 권한을 위임 받 기 위한 요청 메시지를 검증한다. 여기서, 제2 검증부(303)는 라이센스 매니저의 공개키(PK_LLM)를 이용하여 요청 메시지에 포함된 서명 값(SIG_LLM)의 유효성 여부를 검증하고, 요청 메시지에 포함되어 있는 대리 공개키(PK_Proxy)를 이용하여 서명 값(SIG_Proxy)을 검증할 수 있다. 또한, 제2 검증부(303)는 라이센스 매니저가 전송한 대리인증서에 대한 갱신 요청 메시지를 검증할 수 있다. 여기서, 제2 검증부(303)는 라이센스 매니저의 공개키(PK_LLM)를 이용하여 서명 값(SIG_LLM)을 검증할 수 있다. 그리고, 제2 검증부(303)는 갱신 요청 메시지가 유효할 경우 라이센스 서버가 OCSP 서버에 상기 대리인증서의 유효 여부를 질의할 수 있고, 그 결과에 대한 응답메시지를 수신할 수 있다.

제2 생성부(305)는 요청 메시지가 유효할 경우 라이센스 발급 권한에 대한 정보를 포함하는 대리인증서를 생성한다. 여기서, 제2 생성부(305)는 라이센스 매니저의 신원과 대리 공개키(PK_Proxy)를 바인딩한 대리인증서를 생성할 수 있다. 대리인증서는 권리 발급자, 신원, 일련번호, 대리 공개키, 유효 기간, 및 위임 정보 중 적어도 하나를 포함할 수 있다. 여기서, 대리인증서는 라이센스 서버의 개인키(SK_LS)로 서명되어 서명 값(SIG_LS)이 첨부된 후 라이센스 매니저에 전송될 수 있다. 또한, 제2 생성부(305)는 상술된 OCSP로부터 대리인증서가 유효하다는 응답을 받은 경우 새로운 대리인증서를 생성하여 라이센스 매니저로 전송할 수 있다. 새로운 대리인증서에는 대리인증서의 유효 기간　및 라이센스의 발급 가능한 횟수에 대한 정보 중 적어도 하나를 포함할 수 있으며, 라이센스 서버의 개인키(SK_LS)로 재 서명될 수 있다.

도 12은 본 발명의 일 실시 예에 따른 대리인증서 유효성 검증 장치의 블록도이다.

대리인증서 유효성 검증 장치(100)는 제3 생성부(103), 제3 검증부(105) 및 재생부(107)를 포함하며, 소정 디바이스 내에 구현될 수 있다.

제3 생성부(103)는 라이센스 매니저의 대리인증서의 일련번호, 타임 스탬프(time stamp), 논스(nonce) 등의 정보를 포함한 대리인증서의 유효성 검증을 위한 요청 메시지를 생성하고, 자신의 공개키(PK_D2)로 암호화 한 뒤 자신의 서명(SIG_D2)을 첨부한다. 타임 스탬프(time stamp), 논스(nonce)등의 정보는 요청 메시지에 대한 리플레이(replay) 공격을 막기 위해 사용될 수 있다.

제3 검증부(105)는 OCSP의 공개키(PK_OCSP)로 OCSP로부터 수신한 응답 메시지의 서명을 검증한 후, 서명이 유효한 경우에는 그 결과를 참조한다. 그 결과에 따라 대리인증서가 유효할 경우 라이센스 매니저로부터 발급 받은 라이센스로 후술될 재생부를 통해 컨텐츠를 재생한다.

재생부(107)는 상술된 바와 같이 대리인증서가 유효할 경우 컨텐츠를 재생한다. 만약 그 반대의 경우 재생부는 대리인증서와 라이센스를 메모리에서 삭제할 수 있다.

도 10, 도 11 및 도 12에서 도시된 각각의 구성요소는 일종의 '모듈'로 구성될 수 있다. 상기 '모듈'은 소프트웨어 또는 Field Programmable Gate Array(FPGA) 또는 주문형 반도체(Application Specific Integrated Circuit, ASIC)과 같은 하드웨어 구성요소를 의미하며, 모듈은 어떤 역할들을 수행한다. 그렇지만 모듈은 소프 트웨어 또는 하드웨어에 한정되는 의미는 아니다. 모듈은 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 실행시키도록 구성될 수도 있다. 따라서, 일 예로서 모듈은 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 모듈들에서 제공되는 기능은 더 작은 수의 구성요소들 및 모듈들로 결합되거나 추가적인 구성요소들과 모듈들로 더 분리될 수 있다.

이상 첨부된 도면을 참조하여 본 발명의 실시예를 설명하였지만, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다.

도 3은 본 발명의 일 실시 예에 따른 라이센스 서버가 라이센스 매니저에 라이센스 발급 권한을 위임하는 과정을 나타낸다.

도 4는 본 발명의 일 실시 예에 따른 대리위임 요청 메시지의 양식의 예를 도시한다.

도 5는 본 발명의 일 실시 예에 따른 대리인증서의 양식의 예를 도시한다.

도 6은 본 발명의 일 실시 예에 따른 대리인증서 갱신 과정을 도시한다.

도 7은 본 발명의 일 실시 예에 따른 대리인증서 갱신 요청 메시지의 양식의 예를 도시한다.

도 9는 본 발명의 일 실시 예에 따른 라이센스 관리를 위한 시스템 구성도의 예를 도시한다.

<도면의 주요 부분에 관한 부호의 설명>

300: 라이센스 서버 303: 컨텐츠 서버

305: 미디어 서버 310: 라이센스 매니저

320: OCSP 서버

Claims

라이센스 매니저가 라이센스 발급 권한을 위임 받기 위한 요청 메시지를 라이센스 서버로 전송하는 단계;

상기 라이센스 서버가 상기 요청 메시지를 검증하는 단계;

상기 요청 메시지가 유효할 경우 상기 라이센스 서버가 상기 라이센스 발급 권한에 대한 정보를 포함하는 대리인증서를 상기 라이센스 매니저로 전송하는 단계;

상기 라이센스 매니저가 상기 대리인증서를 검증하는 단계; 및

상기 라이센스 매니저가 상기 대리인증서에 기술된 권한 내에서 각 디바이스에 컨텐츠 이용을 위한 라이센스를 발급하는 단계를 포함하는, 대리인증서 발급 방법.
제 1항에 있어서,

상기 요청 메시지를 검증하는 단계는

상기 라이센스 서버가 상기 라이센스 매니저의 공개키를 이용하여 상기 요청 메시지에 포함된 서명 값의 유효성 여부를 검증하는 단계를 포함하는, 대리인증서 발급 방법.
삭제
라이센스 매니저가 라이센스 발급 권한에 대한 정보를 포함하는 대리인증서에 대한 갱신 요청 메시지를 라이센스 서버로 전송하는 단계;

상기 라이센스 서버가 상기 갱신 요청 메시지를 검증하는 단계;

상기 갱신 요청 메시지가 유효할 경우 상기 라이센스 서버가 OCSP(Online Certificate Status Protocol) 서버에 상기 대리인증서의 유효 여부를 질의하는 단계; 및

상기 라이센스 서버가 상기 OCSP로부터 상기 대리인증서가 유효하다는 응답을 받은 경우 새로운 대리인증서를 상기 라이센스 매니저로 전송하는 단계를 포함하는데,

상기 라이센스 매니저에 저장된 기존의 대리인증서는 상기 새로운 대리인증서로 대체되거나, 상기 기존의 대리인증서가 유효 기간이 만료되면 자동으로 폐기되는, 대리인증서 갱신 방법.
제 4항에 있어서,

상기 라이센스 매니저가 상기 새로운 대리인증서를 상기 라이센스 서버의 공개키를 이용하여 검증하는 단계를 더 포함하는, 대리인증서 갱신 방법.
제 4항에 있어서,

상기 새로운 대리인증서에는 대리인증서의 유효 기간　및 라이센스의 발급 가능한 횟수에 대한 정보 중 적어도 하나를 포함하는, 대리인증서 갱신 방법.
삭제
디바이스가 대리인증서의 유효성 검증을 위한 요청 메시지를 라이센스 매니저로 전송하는 단계;

상기 라이센스 매니저가 상기 요청 메시지를 OCSP(Online Certificate Status Protocol) 서버로 전송하는 단계;

상기 OCSP 서버가 상기 대리인증서의 유효성 검증 결과에 대한 응답 메시지를 상기 라이센스 매니저로 전송하는 단계; 및

상기 라이센스 매니저가 상기 디바이스로 상기 응답 메시지를 전송하는 단계를 포함하는, 대리인증서 유효성 검증 방법.
제 8항에 있어서,

상기 디바이스가 상기 요청 메시지를 자신의 공개키로 암호화하고 자신의 서명을 첨부하는 단계를 더 포함하는, 대리인증서 유효성 검증 방법.
제 8항에 있어서,

상기 OCSP 서버가 상기 디바이스의 공개키로 상기 요청 메시지에 포함된 서 명의 유효성 여부를 검증하는 단계를 더 포함하는, 대리인증서 유효성 검증 방법.
제 8항에 있어서,

상기 OCSP 서버가 상기 응답 메시지를 자신의 비밀키로 서명하고, 디바이스의 공개키로 암호화하는 단계를 더 포함하는, 대리인증서 유효성 검증 방법.
제 8항에 있어서,

상기 응답 메시지의 결과에 있어서 상기 대리인증서가 유효하지 않은 것으로 검증된 경우, 상기 디바이스가 상기 라이센스 매니저로부터 발급받은 라이센스 및 상기 대리인증서 중 적어도 하나를 삭제하는 단계를 더 포함하는, 대리인증서 유효성 검증 방법.
제 8항에 있어서,

상기 유효성 검증 질의에 대하여 제한된 시간 내에 상기 OCSP 서버로부터 상기 유효성 검증 질의에 대한 응답을 수신하지 못하는 경우 상기 대리인증서가 유효하지 않은 것으로 간주하고 상기 라이센스 매니저로부터 발급받은 라이센스 및 상기 대리인증서를 삭제하는 단계를 더 포함하는 대리인증서 유효성 검증 방법.
라이센스 발급 권한에 대한 정보를 포함하는 대리인증서를 요청하기 위한 제1 요청 메시지 또는 상기 대리인증서의 갱신을 요청하기 위한 제2 요청 메시지를 생성하는 제1 생성부;

상기 제1 요청 메시지에 따라 라이센스 서버로부터 수신한 상기 대리인증서를 검증하거나 상기 제2 요청 메시지에 따라 상기 라이센스 서버로부터 수신한 새로운 대리인증서를 검증하는 제1 검증부; 및

상기 대리인증서에 기술된 라이센스 발급 권한 내에서 각 디바이스에 컨텐츠 이용을 위한 라이센스를 발급하는 발급부를 포함하는, 라이센스 매니저.
제 14항에 있어서,

상기 제1 검증부는 상기 대리인증서 또는 상기 새로운 대리인증서의 서명 값을 상기 라이센스 서버의 공개키를 이용하여 검증하는, 라이센스 매니저.
삭제
제 14항에 있어서,

상기 대리인증서를 상기 새로운 대리인증서로 대체하는 갱신부를 포함하는, 라이센스 매니저.
라이센스 매니저로부터 수신한 라이센스 발급 권한에 대한 정보를 포함하는 대리인증서에 대한 제1 요청 메시지 또는 상기 대리인증서의 갱신을 위한 제2 요청 메시지를 검증하는 제2 검증부; 및

상기 제1 요청 메시지가 유효할 경우 상기 대리인증서를 생성하거나 상기 제2 요청 메시지가 유효할 경우 새로운 대리인증서를 생성하는 제2 생성부를 포함하는데,

상기 라이센스 매니저에 저장된 기존의 대리인증서는 상기 새로운 대리인증서로 대체되거나, 상기 기존의 대리인증서가 유효 기간이 만료되면 자동으로 폐기되는, 라이센스 서버.
제 18항에 있어서,

상기 대리인증서는 권리 발급자, 신원, 상기 대리인증서의 일련번호, 대리 공개키, 유효 기간, 및 위임 정보 중 적어도 하나를 포함하는, 라이센스 서버.
제 18항에 있어서,

상기 제2 생성부는 기존의 상기 대리인증서의 유효기간 및 라이센스의 발급 가능한 회수 중 적어도 하나를 재설정한 후 상기 새로운 인증서를 생성하는, 라이센스 서버.
제 18항에 있어서,

상기 제2 검증부는 상기 제2 요청 메시지가 유효할 경우 OCSP(Online Certificate Status Protocol) 서버에 상기 대리인증서의 유효 여부를 질의하고,

상기 제2 생성부는 상기 OCSP 서버로부터 상기 대리인증서가 유효하다는 응답을 받은 경우 상기 새로운 대리인증서를 생성하는, 라이센스 서버.