KR101167938B1

KR101167938B1 - 컨텐츠에 대한 권리 이용 방법

Info

Publication number: KR101167938B1
Application number: KR1020100011216A
Authority: KR
Inventors: 추연성; 이승제
Original assignee: 엘지전자 주식회사
Priority date: 2009-09-22
Filing date: 2010-02-05
Publication date: 2012-08-03
Also published as: EP2481006A4; WO2011037318A4; US20110072495A1; US8955053B2; EP2481006A2; KR20110032994A; CN102498493A; EP2481006B1; WO2011037318A2; WO2011037318A3; US9589113B2; US20150121539A1; CN102498493B

Abstract

본 명세서는 컨텐츠를 이용하는 과정 중에 상기 컨텐츠에 대한 권리를 포함하는 메모리 카드가 단말에 장착되어 있는지 여부를 확인하는 방안을 제시한다. 상기 확인은 상기 단말 내의 BCAST 클라이언트가 TEK를 DRM 에이전트에 요청하는 시기와 동기화하여 수행될 수 있다. 또한, 본 명세서는 상기 메모리 카드가 장착되어 있는지 여부 뿐만이 아니라, 상기 메모리 카드 내에 상기 컨텐츠에 대한 권리가 실제 존재하고 있는지 여부를 확인하는 방안을 제시한다.

Description

컨텐츠에 대한 권리 이용 방법{METHOD FOR USING RIGHTS TO CONTENTS}

본 발명은 디지털 저작권 관리에 관한 것으로서, 더욱 상세하게는 디지털 저작권 관리에서 메모리 카드에 사용권리를 안전하게 발급하는 방법에 관한 것이다.

DRM은 디지털 컨텐츠에 대한 권리를 안전하게 보호하고 체계적으로 관리하기 위한 시스템 기술로서, 컨텐츠의 불법복제 방지 및 DRM 컨텐츠 사용권리(RO)의 획득, DRM 컨텐츠의 생성 및 유통, 사용 과정에 대한 일련의 보호 및 관리 체계를 제공한다.

도 1은 일반적인 DRM 시스템의 구성을 보인다.

일반적인 DRM 시스템은 콘텐츠 제공자가 사용자에게 전달한 디지털 콘텐트를 사용자에게 부여한 사용권리만큼만 사용하도록 통제한다. 이때, 상기 콘텐츠 제공자는 콘텐츠 발급 서버(Content Issuer; CI)(20) 및/또는 권리 발급 서버(Rights Issuer; RI)(30)에 해당하는 엔티티(Entity)이다.

상기 컨텐츠 발급 서버(CI)(30)는 접근 권한을 갖지 않은 사용자로부터 콘텐트를 보호할 수 있도록 특정 암호화 키를 사용해 보호된 콘텐트(이하, DRM 콘텐트(혹은 디지털 컨텐츠)라 칭함)를 발급하고, 상기 권리 발급 서버(RI)(40)는 상기 DRM 콘텐트를 사용하는데 필요한 사용권리를 발급한다.

단말(10)은 DRM 에이전트를 포함하며, 상기 DRM 에이전트는 상기 콘텐츠 발급 서버(CI)(30)로부터 DRM 컨텐츠를 수신하고, 상기 사용권리 발급 서버(RI)(40)로부터 상기 컨텐츠에 대한 사용권리를 수신하고, 상기 사용권리(RO)에 포함된 허가권(Permission) 및/또는 제약(Constraint)을 해석하여 해당 단말에서의 상기 DRM 콘텐트의 사용을 통제한다.

일반적으로 사용권리는 특정 단말의 공개키(public key)에 의해 암호화 되어 있기 때문에 상기 공개키와 쌍이 되는 개인키(Private Key)를 소유한 단말 이외의 단말은 상기 사용권리에 관련된 DRM 컨텐츠를 복호화 및 사용할 수 없다.

도 2는 종래의 DRM 기술을 브로드캐스트 서비스에 적용한 예를 나타낸다.

도 2를 참조하여 알 수 있는 바와 같이, 종래의 DRM 기술을 브로드캐스트 서비스, 즉, BCAST 서비스에 적용한 예가 나타나 있다.

브로드캐스트 서버(50)는 SEK(Service Encryption Key) 혹은 PEK(Program Encryption Key)로 암호화된 TEK(Traffic Encryption Key)를 상기 권리 발행 서버(RI)(40)로 전송하고, 상기 TEK로 암호화된 브로드캐스트 컨텐츠를 제1 단말(11)로 전달한다.

상기 권리 발행 서버(RI)(40)는 상기 SEK 또는 상기 PEK와 그리고 상기 암호화된 TEK를 포함하는 권리(Rights)를 상기 제1 단말(11)에 제공한다.

상기 단말(11)은 상기 권리 발행 서버(RI)(40)로부터 수신되는 권리를 착탈가능한 메모리(15)에 저장한다. 그리고, 상기 단말(11)은 상기 메모리(15) 내의 상기 권리를 상기 단말(11) 내에 복사한 후, 상기 권리 내에 포함된 TEK를 복호한다. 그리고, 상기 단말(11)은 상기 브로드캐스트 서버(50)로부터 전달되는 컨텐츠를 상기 복호된 TEK를 이용하여 소비한다.

이상과 같이 종래 기술에서 상기 브로드캐스트 컨텐츠는 제2 단말(12)도 수신할 수 있으나, 상기 TEK를 포함하는 권리가 없으면, 상기 제2 단말(12)은 상기 브로드캐스트 컨텐츠를 소비할 수 없도록 함으로써 컨텐츠를 보호한다.

그러나, 설명한 바와 같이 종래 기술에서는 상기 메모리(15) 내의 권리를 상기 단말(11) 내에 복사한 후, 상기 권리를 이용하여 컨텐츠를 소비한다. 따라서, 상기 메모리에 있던 권리가 상기 단말(11) 내에 복사된 후에, 상기 메모리(15)를 상기 제2 단말(12)에 장착하게 되면, 상기 제2 단말(12)를 통하여 상기 브로드캐스트 컨텐츠를 사용할 수 있는 문제점이 있었다.

이와 같은 문제점은 영화, 드라마와 같이 그 재생 시간이 긴 방송 컨텐츠일 경우, 더욱 심화될 수 있다. 즉, 복수의 단말이 무분별하게 상기 메모리(15)를 공유함으로서, 상기 방송 컨텐츠를 무단으로 소비할 수 있는 문제점이 있다.

따라서, 본 발명의 목적은 전술한 문제점들을 해결하는 데에 있다.

구체적으로, 본 발명의 목적은 권리가 포함된 메모리 카드가 단말에 장착되어 있을 때에만, 상기 단말에 컨텐츠를 이용할 수 있도록 함에 있다. 또한, 본 발명의 다른 목적은 단말이 컨텐츠를 이용중일 때, 메모리 카드 내에 상기 컨텐츠에 대한 권리가 있는지를 확인할 수 있도록 함에 있다.

상기와 같은 목적을 달성하기 위하여 본 명세서는 컨텐츠를 이용하는 과정 중에 상기 컨텐츠에 대한 권리를 포함하는 메모리 카드가 단말에 장착되어 있는지 여부를 확인하는 방안을 제시한다. 상기 확인은 상기 단말 내의 BCAST 클라이언트가 TEK를 DRM 에이전트에 요청하는 시기와 동기화하여 수행될 수 있다.

또한, 본 명세서는 상기 메모리 카드가 장착되어 있는지 여부 뿐만이 아니라, 상기 메모리 카드 내에 상기 컨텐츠에 대한 권리가 실제 존재하고 있는지 여부를 확인하는 방안을 제시한다.

구체적으로, 상기와 같은 목적을 달성하기 위해서, 본 발명은 단말에서 브로드캐스트 컨텐츠에 대한 권리를 이용하는 방법을 제공한다. 상기 권리 이용 방법은 메모리 카드 내에 권리가 존재하는지 여부의 확인에 대한 제약이 브로드캐스트 컨텐츠에 대한 권리 정보 내에 존재하는지 확인하는 단계와; 상기 제약에 따라, 권리 존재 확인 요청 메시지를 상기 메모리 카드로 전송하는 단계와; 상기 메모리 카드로부터 권리 존재 확인 응답 메시지를 수신하는 단계와; 상기 권리 존재 확인 응답 메시지를 수신하면, 상기 메모리 카드 내에 상기 권리가 존재하는지를 여부를 판단하는 단계와; 상기 권리의 존재 여부에 따라 상기 브로드캐스트 컨텐츠의 이용 여부를 결정하는 단계를 포함할 수 있다.

상기 권리 존재 확인 요청 메시지는 TEK(Traffic Encryption Key)의 요청에 따라 전송될 수 있다.

상기 제약은 srmPing 엘리먼트일 수 있다. 상기 제약은 상기 권리 존재 확인을 TEK 요청과 동기화하여 수행하여야 하는지를 나타내는 synchonised 엘리먼트, TEK 요청의 수신이 일정 임계값을 넘을 때 수행하여야 하는지를 나타내는 syncThreshold 엘리먼트, 그리고 일정 주기 마다 수행하여야 하는지를 나타내는 checkInterval 엘리먼트 중 적어도 하나 이상을 포함할 수 있다.

상기 권리 존재 확인 요청 메시지의 전송 단계는 상기 단말 내의 DRM 에이전트가 상기 단말 내의 BCAST 클라이언트로부터 TEK 요청 메시지를 수신하는 단계와; 상기 TEK 요청 메시지의 수신에 응답하여 상기 권리 존재 확인 요청 메시지를 전송하는 단계를 포함할 수 있다.

상기 권리 존재 확인 요청 메시지의 전송 단계는 상기 단말 내의 DRM 에이전트가 상기 단말 내의 BCAST 클라이언트로부터 TEK 요청 메시지를 수신한 횟수가 상기 제약 내에 지정된 임계값을 넘는지 판단하는 단계와; 상기 임계 값을 넘는 경우 상기 권리 존재 확인 요청 메시지를 전송하는 단계를 포함할 수 있다.

상기 권리 존재 확인 요청 메시지의 전송 단계는 상기 제약에 지정된 일정 주기에 도달하는지를 확인하는 단계와; 상기 주기에 도달하는 경우, 상기 권리 존재 확인 요청 메시지를 전송하는 단계를 포함할 수 있다.

상기 제약에 상기 일정 주기 마다 수행하여야 하는지 여부에 대한 정보가 없는 경우, 상기 권리 존재 확인을 TEK 요청과 동기화하여 수행하여야 하는 것으로 해석될 수 있다.

상기 권리 내의 정보는 권리 객체 암호화 키(REK)일 수 있다.

상기 권리 존재 확인 요청 메시지는 상기 권리에 대한 식별 정보와 임의 값을 포함할 수 있다.

상기 권리 존재 확인 응답 메시지는 해쉬값을 포함하고, 상기 해쉬값은 상기 임의값과 상기 권리 내의 소정 정보 중 적어도 하나 이상에 대해 얻어질 수 있다.

상기 권리가 존재하는지를 여부를 판단하는 단계는 상기 임의 값과 상기 단말 내에 저장된 상기 권리 내의 정보 중 적어도 어느 하나 이상에 대한 해쉬값을 구하는 단계와; 상기 구해진 해쉬값과 상기 권리 존재 확인 응답 메시지 내의 상기 해쉬값을 비교하는 단계를 포함할 수 있다.

상기 해쉬값들이 서로 일치하는 경우 상기 메모리 카드 내에 상기 권리가 존재하는 것으로 확인되고, 상기 해쉬값들이 서로 일치하지 않거나, 상기 권리 존재 확인 응답 메시지 내에 상기 해쉬값이 존재하지 않는 경우 상기 메모리 카드 내에 상기 권리가 존재하지 않는 것으로 확인될 수 있다. 상기 식별 정보는 Handle일 수 있다.

한편, 상기와 같은 목적을 달성하기 위하여, 본 발명은 메모리 카드에서 브로드캐스트 컨텐츠를 위한 권리를 단말에 제공하는 방법을 제공한다. 상기 권리 제공 방법은 상기 메모리 카드가 상기 단말로 상기 브로드캐스트 컨텐츠에 대한 권리 정보를 제공하는 단계와; 여기서, 상기 권리 정보 내에는 상기 메모리 카드의 장착 여부의 확인에 대한 제약이 포함되어 있고, 상기 메모리 카드가 상기 권리를 비활성화하는 단계와; 상기 단말로부터 권리 존재 확인 요청 메시지를 수신하는 단계와; 상기 권리 존재 확인 요청 메시지는 상기 권리에 대한 식별 정보와 임의 값을 포함하고, 상기 메모리 카드가 상기 권리가 존재하는지 확인하는 단계와; 상기 권리가 존재하는 경우, 상기 임의 값과 상기 권리 내의 소정 정보 중 어느 하나 이상에 대한 해쉬값을 생성하는 단계와; 상기 해쉬값을 포함하는 권리 존재 확인 응답 메시지를 상기 단말로 전송하는 단계를 포함할 수 있다.

본 발명은 전술한 종래 기술의 문제점을 해결한다. 즉, 본 발명은 권리의 무분별한 복제를 방지하여, 컨텐츠가 안전하게 이용될 있도록 한다.

또한, 본 발명은 메모리 카드의 장착 여부 뿐만이 아니라, 상기 메모리 카드 내에 권리가 존재하는지 여부를 브로드캐스트 컨텐츠의 이용 중에 확인함으로써, 허가되지 않은 컨텐츠의 이용을 방지한다.

도 1은 일반적인 DRM 시스템의 구성을 보인다.
도 2는 종래의 DRM 기술을 브로드캐스트 서비스에 적용한 예를 나타낸다.
도 3는 본 발명에 따라 컨텐츠 및 사용권리를 메모리 카드에 발급하는 개념을 나타낸다.
도 4는 본 발명에 따른 개념을 나타낸 예시적인 흐름도이다.
도 5는 본 발명의 제1실시예를 나타낸 흐름도이다.
도 6는 본 발명의 제2실시예를 나타낸 흐름도이다.
도 7는 본 발명의 제3실시예를 나타낸 흐름도이다.
도 8는 본 발명의 제4실시예를 나타낸 흐름도이다.
도 9는 본 발명의 실시예들을 DRM 에이전트와 SRM 에이전트 간의 프로토콜을 중심으로 나타낸 예시도이다.
도 10는 본 발명에 따른 단말의 동작을 나타낸 흐름도이다.
도 11는 본 발명의 따른 단말(100) 및 SRM(150)의 구성 블록도이다.

본 발명은 디지털 저작권 관리(DRM) 시스템에 적용된다. 그러나 본 발명은 이에 한정되지 않고, 본 발명의 기술적 사상이 적용될 수 있는 모든 통신 시스템 및 방법, 그 외 저작권 관련 시스템 및 방법에도 적용될 수 있다.

본 명세서에서 사용되는 기술적 용어는 단지 특정한 실시 예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아님을 유의해야 한다. 또한, 본 명세서에서 사용되는 기술적 용어는 본 명세서에서 특별히 다른 의미로 정의되지 않는 한, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 의미로 해석되어야 하며, 과도하게 포괄적인 의미로 해석되거나, 과도하게 축소된 의미로 해석되지 않아야 한다. 또한, 본 명세서에서 사용되는 기술적인 용어가 본 발명의 사상을 정확하게 표현하지 못하는 잘못된 기술적 용어일 때에는, 당업자가 올바르게 이해할 수 있는 기술적 용어로 대체되어 이해되어야 할 것이다. 또한, 본 발명에서 사용되는 일반적인 용어는 사전에 정의되어 있는 바에 따라, 또는 전후 문맥상에 따라 해석되어야 하며, 과도하게 축소된 의미로 해석되지 않아야 한다.

또한, 본 명세서에서 사용되는 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "구성된다" 또는 "포함한다" 등의 용어는 명세서 상에 기재된 여러 구성 요소들, 또는 여러 단계들을 반드시 모두 포함하는 것으로 해석되지 않아야 하며, 그 중 일부 구성 요소들 또는 일부 단계들은 포함되지 않을 수도 있고, 또는 추가적인 구성 요소 또는 단계들을 더 포함할 수 있는 것으로 해석되어야 한다.

또한, 본 명세서에서 사용되는 제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성 요소들을 설명하는데 사용될 수 있지만, 상기 구성 요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성 요소로 명명될 수 있고, 유사하게 제2 구성 요소도 제1 구성 요소로 명명될 수 있다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

이하, 첨부된 도면을 참조하여 본 발명에 따른 바람직한 실시 예를 상세히 설명하되, 도면 부호에 관계없이 동일하거나 유사한 구성 요소는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 또한, 본 발명을 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 발명의 사상을 쉽게 이해할 수 있도록 하기 위한 것 일뿐, 첨부된 도면에 의해 본 발명의 사상이 제한되는 것으로 해석되어서는 아니 됨을 유의해야 한다. 본 발명의 사상은 첨부된 도면외에 모든 변경, 균등물 내지 대체물에 까지도 확장되는 것으로 해석되어야 한다.

이하, 도 3 내지 도 7에서는 장치(Device)가 도시되어 있으나, 상기 장치는 UE(User Equipment), 단말(Terminal), ME(Mobile Equipment), MS(Mobile Station)로 불릴 수 있다. 또한, 상기 장치는 휴대폰, PDA, 스마트 폰(Smart Phone), 노트북 등과 같이 통신 기능을 갖춘 휴대 가능한 기기일 수 있거나, PC, 차량 탑재 장치와 같이 휴대 불가능한 기기일 수 있다.

용어의 정의

이하 도면을 참조하여 설명하기 앞서, 본 발명의 이해를 돕고자, 본 명세서에서 사용되는 용어를 간략하게 정의하기로 한다.

1) DRM 에이전트: DRM 에이전트는 단말 내에 존재하는 엔티티로서, 미디어오브젝트에 대한 허가권(permission)을 관리한다.

2) 미디어 오브젝트(Media Object): 디지털 작업(또는 동작)(work), 예컨대 전화 벨, 화면 보호기, 자바 게임 또는 이들의 조합에 대한 동작이다.

3) DRM 컨텐츠(DRM Content): 권리 개체 내의 허가권에 따라 소비되는 미디어 오브젝트이다.

4) 브로드캐스트 권리: BCAST 권리라고도 불린다. BCAST 서비스를 위해서 이용된다.

5) 권리 발급자(Rights Issuer: RI): DRM 컨텐츠에 대한 권리 객체를 발급하는 엔티티이다.

6) 허가권(Permission): 권리 발급자(Rights Issuer: RI)에 의해 허용된 DRM 컨텐츠에 대한 실제 사용의 허가

7) 권리(Rights): DRM 컨텐츠에 부여된 허가권 및 제약 의미한다. 상기 권리는 관련 상태에 대한 정보 및 다른 정보와 함께 권리 객체를 이룬다.

상기 권리(Rights) = 권리정보(Rights Information) + 권리 객체 암호화 키(REK) 일 수 있다.

8) 권리 객체(Rights Object)

권리 객체는 사용 권리로도 불리며, DRM 컨텐츠에 대한 허가권(또는, 제약)들과 상기 컨텐츠에 연결된 다른 속성들을 포함한다.

상기 권리 객체는 일반적으로 단말 내에 저장되나, 본 발명의 실시예에 따르면 메모리 카드, 예컨대 SRM 에 저장될 수 있다. 이때, 상기 권리 개체는 권리 객체 컨테이너(Rights Object Container)의 형태로 저장될 수 있다.

상기 SRM의 에이전트는 상기 권리 객체 컨테이너를 불투명한 개체(opaque object)로 다룬다. 즉, 상기 SRM 에이전트는 상기 권리 개체 컨테이너를 파싱하지 않는다.

상기 권리 객체(Rights) = 권리정보(Rights Information)의 일부 (상태 정보를 포함하고 있지 않음. 그 외 값은 모두 포함) + 권리 객체 암호화 키(REK)와 같이 구성될 수 있다..

9) 권리 정보(Rights Information)

권리 정보는 상기 권리 메타 데이터, 권리 객체 컨테이너, 상기 상태 정보를 포함한다.

권리 정보 (Rights Information) = (권리 객체(Rights Object - 권리객체 암호화 키(REK)) + 상태 정보(State Information) = 권리(Rights) - 권리객체 암호화 키(REK)를 의미한다.

10) 권리 메타 데이터(Rights Meta Data):

권리 메타 데이터(Rights Meta Data)는 권리 객체 버전(Rights Object Version), 권리 객체의 별명(RO Alias), 사용권리 발급자의 식별자(RI Identifier), 사용권리 발급자의 주소(RI URL), 사용권리 발급자의 별명(RI Alias), 사용권리 발급자의 타임 스탬프(RI Time Stamp)를 포함한다.

11) 상태 정보(State Information)

상태 정보는 stateful 사용 권리 내에 있는 각각의 stateful 허가권의 현재 상태(예컨대, 잔여 카운트, 시작일 간격(interval start date)를 뜻한다. 상기 사용권리가 stateful 사용권리 라면, 상기 상태 정보는 권리(Rights) 내에 포함된다.

12) AssetID

Asset Identifier의 약자로서 권리 개체(RO)내에 포함되고, DRM 컨텐츠를 식별하는데에 이용된다.

13) REK

REK는 권리 객체 암호화 키(Rights Object Encryption Key)로서, 바이너리 형태를 가지며, no base64 encoding이다.

14) Handle

Handle은 DRM 에이전트에 의해서 생성되는 랜덤 넘버로서, 상기 DRM 에이전트가 메모리 카드, 예컨대 SRM 내에 저장된 사용권리(또는 권리 객체(RO))를 식별하기 위해서 사용된다. 상기 Handle은 상기 DRM 에이전트가 상기 SRM 내의 사용권리를 사용하거나 혹은 이동하기 위해서 액세스할 때, 상기 사용권리(또는 권리 객체(RO))를 식별하기 위해서 사용된다. 상기 Handle은 상기 SRM 내에 저장되며, 또한 단말의 동작 로그(Operation Log)에 저장된다.

상기 DRM 에이전트는 상기 사용권리(또는 권리 객체(RO))를 이용하거나 또는 이동하기 위한 메시지를 전송할 때, 상기 Handle을 생성하고, 상기 생성된 Handle을 상기 SRM에 전송한다.

15) Secure Authenticated Channel (SAC): 송수신되는 메시지의 무결성 및 신뢰성을 보증하기 위한 논리 채널이다.

16) MAKE: 상호 인증 및 키 교환(Mutual Authentication and Key Exchange)의 약자이다. 상기 MAK 절차를 통해 상기 SAC의 설정에 필요한 SAC Context가 생성될 수 있다.

구체적으로 상기 MAKE 절차에서는 DRM 에이전트와 SRM 에이전트 간에 트러스트 모델(Trust Model), 엔티티 ID(entity ID), 보안 알고리즘(security algorithm) 등에 대한 협상이 수행되고, 상호 인증 절차가 수행된다. 또한, 상기 MAKE 절차에서는 SAC에서 사용할 암호화 키(Session Key, MAC Key)의 정보에 대한 교환이 이루어진다. 상기 MAKE 절차는 도 5를 참조하여 상세하게 후술하기로 한다.

17) MAC 키: DRM 에이전트와 SRM 에이전트 간에 SAC 세션 에서 무결성을 보장하기 위해서 이용되는 키이다.

18) 세션 키: DRM 에이전트와 SRM 에이전트 간에 SAC 세션 에서 신뢰성을 보장하기 위해서 사용되는 암호키이다.

19) 엔티티 ID: 단말을 위해서는 SRM ID이고, SRM을 위해서는 단말의 ID이다.

17) SAC 컨텍스트(SAC Context)

SAC 컨텍스트는 상기 SAC의 설정에 필요한 정보를 아래의 표 1과 같이 포함한다. 상기 SAC 컨텍스트는 DRM 에이전트와 SRM 에이전트 간에 새로운 SAC가 생성되기 전까지 유지된다.

이름	설명
MAC Key	DRM 에이전트와 SRM 에이전트간 SAC 세션에서 무결성 보장을 위해 사용되는 키
Session Key	DRM 에이전트와 SRM 에이전트간 SAC 세션에서 기밀성(Confidentiality) 보장을 위해 사용되는 암호화 키
Selected Algorithms	MAKE 절차를 통해 협상된 알고리즘
Trust Anchor	SAC에서 설정된 트러스트 앵커
Entity ID	DRM 에이전트를 위해서는 SRM의 ID를 지시하고, SRM 에이전트를 위해서는 DRM의 ID를 지시함

18) 보호화된 권리 개체(protected RO)

상기 보호화된 RO(protected RO)는 DRM 버전 2.0에 따른 형태이다. 상기 보호화된 RO는 상기 RI로부터 단말로 제공될 때 사용되는 포맷이다. 또한, 상기 보호화된 RO는 상기 단말의 DRM 에이저트로부터 상기 메모리 카드, 예컨대 SRM의 SRM 에이전트로 전달될 때 사용되는 포맷이다.

상기 보호화된 권리 개체는 아래의 표와 같이 일련의 권리 객체, 즉 <RO> 엘리먼트와 MAC 값을 포함하는 <mac> 엘리먼트를 포함한다. 상기 <mac> 엘리먼트는 상기 <ro> 엘리먼트의 무결성과, 키 확인을 위해 사용된다.

상기 표에 나타난 바와 같이, <ro> 엘리먼트는 ROPayload 항목을 포함한다. 상기 ROPayload 항목은 보호화된 권리와 보호된 키들(wrapped keys)을 포함한다. 상기 보호된 키들은 상기 권리 내에 암호화되어 있는 부분을 복호(decrypt)하는데 이용된다. 상기 ROPayload 항목은 다음이 표와 같은 내용을 포함한다.

<complexType name="ROPayload">
<sequence>
<element name="riID" type="roap:Identifier"/>
<element name="rights" type="o-ex:rightsType"/>
<element name="signature" type="ds:SignatureType" minOccurs="0"/>
<element name="timeStamp" type="dateTime" minOccurs="0"/>
<element name="encKey" type="xenc:EncryptedKeyType"/>
<element ref="roap:roPayloadAliases" minOccurs="0"/>
<any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="version" type="roap:Version" use="required" />
<attribute name="id" type="ID" use="required" />
<attribute name="stateful" type="boolean"/>
<attribute name="domainRO" type="boolean"/>
<attribute name="riURL" type="anyURI"/>
</complexType>

상기 <riID> 엘리먼트는 사용권리 발급자를 식별할 수 있도록 식별자를 포함한다.

상기 <timestamp> 엘리먼트의 값은 UTC(Universal Coordinated Time)로 주어지며, 재전송을 통한 해킹 또는 크래킹을 방지하기 위해서 사용된다.

상기 <Signature> 엘리먼트는 상기 사용권리 발급자의 서명을 포함한다.

상기 <encKey> 엘리먼트는 보호화된 MAC key, KMAC, REK(RO encryption key), KREK를 포함한다.

한편, 아래 표에 나타난 <roPayloadAliases>엘리먼트는 상기 <encKey> 엘리먼트는 상기 ROPayload에 포함된다.

한편, Nonce 항목은 ROAP 프로토콜 메시지 내의 임의 값을 포함한다. 상기 Nonce 항목은 이름 그대로 단 한번만 사용되어야 한다. 즉, ROAP 메시지가 생성될 때마다, 상기 Nonce의 임의 값이 생성된다.

본 명세서에서 제안되는 방안의 개념에 대한 설명

본 발명에서는 컨텐츠를 이용하는 과정 중에 상기 컨텐츠에 대한 권리를 포함하는 메모리 카드, 즉 SRM(Secure Removable Media)이 단말에 장착되어 있는지 여부를 확인한다. 또한, 본 발명은 상기 컨텐츠를 이용하는 과정 중에 상기 SRM이 장착되어 있는지 여부 뿐만이 아니라, 상기 SRM 내에 상기 컨텐츠에 대한 권리가 실제 존재하고 있는지 여부를 확인한다.

상기 확인을 위해 본 발명은 권리 존재 확인 프로토콜을 제시한다. 상기 권리 존재 확인 프로토콜은 예시적으로 SRM Ping 프로토콜일 수 있다.

이하에서는, 본 발명에 따른 실시 예를 첨부한 도면을 참조하여 상세히 설명하기로 한다.

도 3는 본 발명에 따라 컨텐츠 및 사용권리를 메모리 카드에 발급하는 개념을 나타낸다.

상기 제1 및 제2 단말(110, 120)은 각기 DRM 에이전트를 포함한다. 그리고 상기 SRM(150)은 SRM 에이전트를 포함한다.

도 3를 참조하여 알 수 있는 바와 같이, 컨텐츠 발급자(CI)(300)는 컨텐츠를 제1 단말(110)에 발급한다.

그리고, 상기 브로드캐스트 서버(500)는 SEK(Service Encryption Key) 혹은 PEK(Program Encryption Key)로 암호화된 TEK(Traffic Encryption Key)를 상기 권리 발행 서버(RI)(400)로 전송하고, 상기 TEK로 암호화된 브로드캐스트 컨텐츠를 제1 단말(110)로 전달한다.

상기 권리 발행 서버(RI)(400)는 상기 SEK 또는 상기 PEK와 그리고 상기 암호화된 TEK를 포함하는 권리(Rights)를 상기 제1 단말(110)에 제공한다. 이때, 상기 권리(또는 RO)는 상기 메모리 카드, 즉 SRM(150)의 명의로 발급된다.

상기 제1 단말(110)은 상기 권리 발행 서버(RI)(400)로부터 수신되는 권리를 메모리, 즉 SRM(150)에 저장한다. 그리고, 상기 단말(110)은 상기 메모리(150) 내의 상기 권리를 상기 단말(110) 내에 복사한 후, 상기 권리 내에 포함된 TEK를 복호한다. 그리고, 상기 단말(110)은 상기 브로드캐스트 서버(500)로부터 전달되는 컨텐츠를 상기 복호된 TEK를 이용하여 소비한다.

상기 제1 단말(110)이 상기 브로드캐스트 컨텐츠를 이용하는 경우, DRM 에이전트와 상기 SRM(150)의 SRM 에이전트 간에는 상기 권리가 저장된 메모리 카드, 즉 SRM(Secure Removable Media)가 장착되어 있는지 여부가 확인된다. 또한, 본 발명은 상기 브로드캐스트 컨텐츠를 이용하는 과정 중에 상기 SRM이 장착되어 있는지 여부 뿐만이 아니라, 상기 SRM 내에 상기 컨텐츠에 대한 권리가 실제 존재하고 있는지 여부가 확인된다.

이하, 도 4내지 도 8을 참조하여, 본 발명의 실시 예들을 설명하기로 한다.

도 4는 본 발명에 따른 개념을 나타낸 예시적인 흐름도이다.

도 4를 참조하여 알 수 있는 바와 같이, 제1 단말(110)은 브로드캐스트 클라이언트(BCAST 클라이언트)와 DRM 에이전트를 포함한다. 그리고 상기 제1 단말(110)에는 메모리 카드, 즉 SRM(150)이 장착된다. 상기 SRM(150)은 SRM 에이전트를 포함한다.

상기 BCAST 클라이언트는 상기 단말(110)의 사용자의 요청에 따라 혹은 다른 애플리케이션의 요청에 따라 브로드캐스트 컨텐츠를 이용하여야 하는 경우, 상기 DRM 에이전트로 TEK를 요청한다.

그러면, 상기 DRM 에이전트는 상기 TEK를 획득하기 위하여, 상기 SRM 에이전트(150)로 권리(또는 RO)를 요청한다. 상기 SRM 에이전트는 상기 SRM 내의 권리를 상기 DRM 에이전트로 제공한다.

상기 DRM 에이전트는 상기 수신한 권리를 임시 저장하고, 상기 권리 내의 TEK를 복호한다. 그리고, 상기 TEK를 상기 BCAST 클라이언트에 전달한다.

상기 BCAST 클라이언트는 상기 TEK를 이용하여 상기 브로드캐스트 서버(500)로부터 브로드캐스트되는 컨텐츠를 소비한다.

상기 컨텐츠가 소비되는 중에 상기 DRM 에이전트와 상기 SRM(150)의 SRM 상기 브로드캐스트 컨텐츠를 소비하는 중에 상기 DRM 에이전트와 상기 SRM 에이전트 간에는 상기 권리가 저장된 메모리 카드, 즉 SRM(Secure Removable Media)가 장착되어 있는지 여부가 확인된다. 즉, 도시된 바와 같이, 권리 존재 확인 프로토콜이 수행된다.

이때, 상기 SRM 이 상기 단말에 장착되어 있는지만 확인 하면, 아래와 같이 보안 이슈를 야기시킨다. 예를 들어, 상기 SRM 에이전트가 어떠한 이유로 BCAST 서비스를 위한 Rights를 포함하지 않게 되는 경우에도, 상기 SRM은 여전히 상기 단말에 장착되어 있기 때문에, 상기 DRM 에이전트는 상기 임시 저장하였던 권리 내의 SEK 및 PEK를 사용하여 TEK를 복호하고 상기 BCAST 클라이언트에 제공할 수 있다. 따라서, 상기 BCAST 클라이언트는 방송 컨텐츠를 소비할 수 있게 되는 심각한 보안 오류를 가진다. 다른 예로, 상기 SRM 에이전트를 대신하여, 상기 단말 내에 설치되는 다른 애플리케이션이 상기 DRM 에이전트로 상기 SRM이 올바르게 장착되어 있다고 알릴 경우, 상기 DRM 에이전트는 이상이 없다고 판단하고, 상기 TEK를 복호하여 상기 BCAST 클라이언트에 제공할 수 있는 문제점이 있다. 따라서, 상기 메모리 카드, 즉 SRM을 상기 단말에 장착하지 않고도 계속적인 BCAST 서비스 시청이 가능해진다.

따라서, 본 발명에 따른 상기 권리 존재 확인 프로토콜은 상기 SRM이 상기 단말에 장착되어 있는지 여부 뿐만이 아니라, 상기 SRM 내에 상기 컨텐츠에 대한 권리가 실제 존재하고 있는지 여부가 확인할 수 있도록 한다.

상기 권리 존재 확인 프로토콜은 예시적으로 SRM Ping request 메시지 및 SRM Ping response 메시지를 포함할 수 있다.

상기 SRM Ping Request 메시지는 DRM 에이전트가 SRM 에이전트로 전송하는 메시지이다. 상기 SRM Ping Request 메시지는 상기 SRM 내에 저장된 권리에 대한 핸들(handle)을 포함한다. 상기 SRM Ping Request 메시지는 Replay Attack을 방지하기 위해, 특정 값, 예컨대 임의(Random) 값을 포함할 수 있다. 상기 Replay attack이라 함은 미리 조작된 SRM Ping Response 메시지를 DRM 에이전트로 전송함으로써, 상기 DRM 에이전트가 상기 SRM 내에 권리가 존재하는 것으로 믿도록 속이는 행위를 말한다.

상기 SRM 에이전트가 상기 SRM Ping Request 메시지를 수신하면, 상기 SRM Ping Request 메시지 내에 포함된 Handle에 대응하는 권리가 저장되어 있는지 확인한다. 그리고, 상기 권리가 존재하는 경우, 상기 SRM 에이전트는 상기 Handle에 대응하는 권리 내의 REK와 상기 임의 값에 대한 해쉬(Hash)를 생성하고, 상기 Hash를 SRM Ping Response 메시지에 포함시켜, 상기 DRM 에이전트로 전송한다. 상기 DRM 에이전트는 상기 Hash를 이용하여, 상기 SRM이 장착되어 있음은 물론, 상기 SRM 내에 권리가 존재함을 확인할 수 있다. 따라서, 비어 있는 SRM을 단말에 장착하여 컨텐츠를 부적법하게 이용하는 것이 방지될 수 있다.

한편, 본 발명에 의하면, 상기 SRM Ping Request 메시지는 BCAST 클라이언트에 의한 TEK의 요청과 동기되어 상기 SRM으로 전송될 수도 있고, 혹은 일정 주기로 전송될 수도 있다. 또한, 상기 SRM Ping Request 메시지는 일정한 임계 값을 넘을 때마다 전송될 수도 있다. 상기 일정한 임계 값은 상기 TEK 요청에 대해서 지정될 수 있다.

이와 같은 상기 존재 확인 프로토콜의 수행에 대한 정보는 상기 권리 내에 포함될 수 있다. 즉, 상기 권리 내에는 SRM Ping 프로토콜의 수행에 관련된 제약이 포함될 수 있다. 상기 SRM Ping 프로토콜에 관련된 제약은 권리 내에 포함되는 <srmPing> 엘리먼트일 수 있다. 상기 <srmPing> 엘리먼트는 권리 개체(Rights Object) 내의 <rights> 엘리먼트의 하위에 위치하는 <constraint> 엘리먼트의 하위에 위치할 수 있다.

상기 <srmPing> 엘리먼트는 아래와 같을 수 있다.

<xsd:element name="srmPing" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="xsd:constraintType">
<xsd:choice minOccurs=”0”>
<xsd:element name="synchronised" type="xsd:boolean" default=”true”/>
<xsd:element name="syncThreshold" type="xsd:count "/>
<xsd:element name="checkInterval" type="xsd:duration"/>
</xsd:choice>
<xsd:any minOccurs="0" maxOccurs="unbounded" processContents=”lax”/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>

만약 권리 내에 상기 <srmPing> 엘리먼트가 포함되어 있으면, DRM 에이전트는 SRM Ping 프로토콜을 수행해야 한다. 상기 <srmPing> 엘리먼트는 <synchonised> 서브 엘리먼트, <syncThreshold> 서브 엘리먼트, <checkInterval> 서브 엘리먼트 중 하나의 서브 엘리먼트를 포함할 수 있다. 상기 SRM Ping 프로토콜의 호출 여부가 상기 서브 엘리먼트에 의해서 결정된다. 상기 <srmPing> 엘리먼트 하위에 상기 서브 엘리먼트가 존재하지 않는 경우, DRM 에이전트는 <synchronized> 서브 엘리먼트를 포함하는 것으로 해석한다. 즉, 상기 <srmPing> 엘리먼트 내에 <checkInterval> 서브 엘리먼트가 포함된 경우에는 <checkInterval> 서브 엘리먼트에 따라 동작한다. 그러나 <checkInterval> 서브 엘리먼트가 포함되지 않은 경우에는, STKM (Short Term Key Message) 절차가 수행되기 전에 SRM Ping 프로토콜이 수행된다. 예를 들어, <checkInterval> 서브 엘리먼트가 포함되지 않은 경우에는 TEK 요청과 동기되어 수행될 수도 있다.

상기 <synchonised> 서브 엘리먼트는 SRM Ping 프로토콜이 BCAST 클라이언트와 동기화 되어있는지 여부를 나타낸다. 만약 상기 <synchonised> 서브 엘리먼트의 값이 ‘true’일 경우 동기화 되며, ‘false’일 경우 동기화 되지 않는다. 이 서브 엘리먼트의 값이 생략되는 경우 ‘true’로 해석한다.

상기 <checkInterval> 서브 엘리먼트는 SRM Ping 프로토콜의 수행 주기를 포함하고 있다. 즉, 상기 <checkInterval> 서브 엘리먼트는 후속하는 SRM Ping 프로토콜간의 시간을 지정한다. 상기 <checkInterval> 서브 엘리먼트에 지정된 주기(duration)에 도달하면 SRM Ping 프로토콜이 수행된다.

상기 <syncThreshold> 서브 엘리먼트는 상기 TEK 요청의 수신 횟수가 미리 지정된 값(예컨대 임계값)에 도달하였을 경우 SRM Ping 프로토콜이 수행됨을 나타낸다. 예를 들어, 즉 <syncThreshold>의 값이 5일 경우, 상기 DRM 에이전트는 BCAST 클라이언트로부터 TEK 요청을 5번씩 수신할 때마다, 상기 SRM 에이전트과 SRM Ping 프르토콜을 수행한다. 이때, 상기 DRM 에이전트는 내부 카운터를 가지고, 상기 TEK 요청 수신시 마다 카운터를 1씩 증가시킨다. 그리고 상기 증가된 카운터와 상기 <syncThreshold> 서브 엘리먼트에 지정된 값을 비교한다. 상기 두 값이 같거나 혹은 상기 카운터의 값이 클 경우, 상기 DRM 에이전트는 상기 SRM Ping 프로토콜을 수행하고, 상기 카운터를 0으로 초기화한다. 이와 같은 상기 <syncThreshold> 서브 엘리먼트는 상기 <synchonised> 서브 엘리먼트에 비하여 SRM Ping 프로토콜 인해서 DRM 에이전트 및 SRM 에이전트에 발생할 수 있는 부하를 줄여주면서도 SRM에 BCAST Rights가 존재하는지는 안전하게 확인할 수 있도록 한다.

이와 같은 상기 제약을 확인하는 과정은 다음과 같을 수 있다.

단말 내의 DRM 에이전트는 메모리 카드, 즉 SRM이 상기 단말에 장착되면, SRM 에이전트와 SRM Hello 및 MAKE (Mutual Authentication & Key Exchange) 절차를 통해서, 통신을 위한 기본적인 협상 및 인증을 수행하고, SAC (Secure Authenticated Channel)을 생성한다.

한편, DRM 에이전트는 OMA BCAST 방송의 수신이 요구되면, 상기 SRM 에이전트로 상기 BCAST 서비스 시청을 위한 BCAST 권리의 존재 유무를 확인하고, 상기 SRM 에이전트로부터 권리 정보(Rights Information)과 REK를 복사(즉 수신 및 저장). 이어서, 상기 DRM 에이전트는 상기 SRM으로부터 복사된 권리 내에 <srmPing> 이 포함되어 있는지 확인한다.

상기 DRM 에이전트는 상기 <srmPing>이 존재하면, 상기 <srmPing>에 따라 SRM Ping 프로토콜을 수행한다.

도 5는 본 발명의 제1실시예를 나타낸 흐름도이다.

도 5를 참조하여 알 수 있는 바와 같이, 본 발명의 제1 실시예에 따르면 권리, 즉 BCAST 권리의 존재 유무 확인을 위한, 권리 존재 확인 프로토콜, 즉 SRM Ping 프로토콜이 BCAST 클라이언트의 TEK 요청과 동기화되어 수행된다.

도 5에 도시된 제1 실시예는 TEK 요청 수신 과정(S111), 권리 미 존재시 핸들 리스트 조회 과정(S120), 권리 정보 조회 과정(S130), 권리 선택 및 확인 과정과 REK 조회 과정(S140), TEK 복호 및 전달 과정(S150), TEK 요청의 수신과 동기화하여 권리 존재 확인 과정(S170), 권리가 존재하는 것으로 확인되면 TEK 복호하고 전달하는 과정(S180), 컨텐츠의 이용 종료되면 SRM 내의 권리의 상태를 원상 복구하는 과정(S190)을 포함한다.

구체적으로 설명하면 다음과 같다.

1) 먼저 상기 TEK 요청 수신 과정(S111)을 설명하면 다음과 같다.

상기 제1 단말(110) 내의 BCAST 클라이언트는 상기 단말(110)의 사용자의 요청에 따라 혹은 다른 애플리케이션의 요청에 따라 브로드캐스트 컨텐츠를 이용하여야 하는 경우, 예컨대 도시된 TEK request 메시지를 상기 DRM 에이전트로 전송한다(S111).

상기 TEK request 메시지는 BCAST 클라이언트가 BCAST 서비스/프로그램/콘텐츠의 시청을 위해서, STKM (Short Term Key Message)에 포함된 TEK의 복호화를 상기 DRM 에이전트에게 요청하는 메시지 이다. 상기 TEK request메시지는 SEK(또는 PEK)로 암호화된 TEK, 즉 도시된 AES-Encryption(SEK)(TEK)와 CID를 포함한다. 상기 CID는 Content ID이며, SEK 또는 PEK를 구분하기 위한 고유 식별자이다. 이와 같은 상기 CID는 program_CID 또는 service_CID를 나타낼 수 있다. 또는 상기 권리가 브로드캐스트 권리(또는, RO)일 경우, program_BCI 또는 service_BCI를 나타낼 수 있다. 상기 Program_BCI 및 service_BCI는 OMA BCAST 1.0 표준 명세서를 참조하면 당업자가 이해할 수 있는바, 설명하지 않는다.

2) 다음으로, 권리 미 존재시 핸들 리스트 조회 과정(S120)을 설명하면 다음과 같다.

상기 TEK Request 메시지를 상기 DRM 에이전트가 수신하면, 상기 DRM 에이전트는 상기 CID에 대응되는 BCAST 권리가 있는지(즉, 상기 SRM 에이전트로부터 이전에 수신한 BCAST 권리의 복사본을 가지고 있는지)를 검사한다. 상기 DRM 에이전트 내부에 상기 권리가 있는 경우, 상기 DRM 에이전트는 즉시 상기 권리 내의 SEK 및 PEK 중 하나 이상을 이용하여 상기 TEK를 복호화하고, 상기 복호된 TEK를 포함하는 TEK response 메시지를 상기 BCAST 클라이언트에 전송한다.

그러나, 상기 권리가 존재하지 않는 경우, 상기 DRM 에이전트는 상기 SRM에 저장된 권리들 중에서 상기 BCAST 권리를 검색하기 위하여, 리스트 검색 요청 메시지, 예컨대 Handle List Query Request 메시지를 상기 DRM 에이전트로 전송한다(S121). 상기 리스트 검색 요청 메시지는 상기 CID에 대응하는 Asset ID의 해쉬값의 리스트와, 핸들 리스트의 길이를 포함한다.

상기 SRM 에이전트는 상기 SRM(150)에 저장되어 있는 핸들에 대한 리스트를 조회한다(S122). 즉 상기 SRM 에이전트는 상기 Asset ID에 해당하는 Handle이 존재하는지를 검색한다.

그리고 상기 SRM 에이전트는 리스트 응답 메시지, 예컨대 Handle List Query Response 메시지를 상기 DRM 에이전트로 전송한다(S123). 상기 리스트 응답 메시지는 status 필드를 포함하는데, 상기 handle이 존재할 경우 상기 status의 값은 success이다. 그러나 상기 handle이 존재하지 않는 경우 status의 값은 fail이 된다. 또한, 상기 리스트 응답 메시지는 error code를 포함한다.

3) 다음으로, 권리 정보 조회 과정(S130)을 설명하면 다음과 같다.

상기 DRM 에이전트는 상기 SRM 에이전트로부터 상기 Handle List Query Response 메시지를 수신하면, 상기 메시지 내에 포함된 Handle 값을 확인한다.

그리고, 상기 확인된 handle 값을 포함하는 권리 정보 요청 메시지, 예컨대 Rights Info Query Request 메시지를 상기 SRM 에이전트로 전송한다(S131).

상기 SRM 에이전트는 상기 Handle에 대응하는 권리, 즉 BCAST 권리가 존재하는지 검색한다(S132).

이어서, 상기 SRM 에이전트는 권리 정보 응답 메시지, 예컨대 Rights Info Query Response 메시지를 상기 SRM 에이전트로 전송한다(S133). 상기 권리 정보 응답 메시지는 상기 Handle에 대응하는 권리가 존재하는 경우, 권리 정보를 포함한한다. 여기서 상기 권리 정보는 권리 메타 데이터, 권리 개체 컨테이터, 상기 권리에 대한 상태 정보를 포함한다.

그리고, 상기 권리 정보 응답 메시지는 Status를 포함한다. 상기 Status는 상기 권리가 존재하는 경우 success 또는 success에 해당하는 값을 포함하고, 상기 권리가 존재하지 않는 경우 error 또는 error에 해당하는 값을 포함한다.

4) 다음으로, 권리 선택 및 확인 과정과 REK 조회 과정(S140) 및 REK 조회 과정(S140)을 설명하면 다음과 같다.

상기 DRM 에이전트는 상기 수신된 권리 정보 응답 메시지를 수신하면, 상기 권리 정보를 제공한 SRM의 ID를 저장한다.

상기 DRM 에이전트는 상기 수신된 권리 정보 응답 메시지 내의 권리 정보를 선택하고 확인한다(S141). 구체적으로, 상기 DRM 에이전트는 상기 권리 정보 내의 <rights> 엘리먼트를 확인한다. 그리고, 상기 DRM 에이전트는 <rights> 엘리먼트 내에 권리 존재 확인 여부에 대한 제약, 즉 <srmPing> 엘리먼트가 있는지 확인한다. 만약 <srmPing> 엘리먼트가 존재하는 경우, 상기 DRM 에이전트는 <srmPing> 엘리먼트 내의 서브 엘리먼트를 확인한다. 상기 <srmPing> 엘리먼트 내에는 <synchonised> 서브 엘리먼트, <syncThreshold> 서브 엘리먼트, 상기 <checkInterval> 서브 엘리먼트 중 하나 이상을 포함할 수 있다. 이하, 도 5에서는 상기 <srmPing> 엘리먼트 내에 <synchonised> 서브 엘리먼트가 포함되어 있는 것으로 가정하여 설명하기로 한다.

상기 DRM 에이전트는 상기 권리 정보를 획득하였으나, BCAST 권리에 대한 REK를 갖고 있지 않기 때문에, CEK(Content Encryption Key)에 접근할 수 없다. 상기 CEK에는 SEK(Service Encryption Key)나 PEK(Program Encryption Key)가 포함되어 있다.

따라서, 상기 DRM 에이전트는 상기 REK를 획득하기 위해, REK 요청 메시지, 예컨대 REK Query Request 메시지를 상기 SRM 에이전트로 전송한다(S142). 상기 REK 요청 메시지는 상기 SRM에 저장된 권리에 대한 Handle과, 상기 권리에 대해 생성한 New Handle을 포함한다. 상기 New Handle은 상기 REK 요청 메시지를 전송한 상기 DRM 에이전트만 알고 있기 때문에, 다른 DRM 에이전트는 해당 권리에 접근할 수 없게 된다. 그리고, 상기 REK 획득 요청 메시지는 상기 SRM 내에서 상기 권리를 비활성 상태 또는 디스에이블 상태(Disablement satus)로 변경할 할 것을 요청하는 정보를 포함한다.

상기 SRM 에이전트는 상기 REK 요청 메시지를 수신하면, 상기 Handle에 해당하는 권리에 대해 상기 Handle을 상기 New Handle로 변경하고, 상기 권리를 비활성 상태 또는 디스에이블 상태로 변경한다(S143). 이와 같이 상기 비활성된 또는 디스에이블 된 권리는 상기 New Handle을 아는 DRM 에이전트만이 다시 활성 상태 또는 인에이블 상태로 바꿀 수 있다.

이어서, 상기 SRM 에이전트는 상기 권리의 REK를 포함하는 REK 응답 메시지, 예컨대 REK Query Response 메시지를 상기 DRM 에이전트로 전송한다(S144). 상기 REK 응답 메시지는 상태를 포함한다. 상기 상태는 상기 비활성화 또는 디스에이블의 성공 여부, 상기 new Handle로의 변경이 성공인지의 여부를 나타낸다. 상기 REK 응답 메시지는 해쉬값을 더 포함할 수 있다. 이를 위해 상기 SRM 에이전트는 임의 값을 생성하고, 상기 REK와 상기 생성된 임의 값에 대해 상기 해쉬값을 생성한다.

5) 다음으로, TEK 복호 및 전달 과정(S150)을 설명하면 다음과 같다.

상기 DRM 에이전트는 상기 REK 응답 메시지를 수신하면, 상기 REK 응답 메시지 내의 REK를 이용하여 상기 권리 정보 내의 <rights> 엘리먼트 내의 CEK를 복호화하고, 상기 복호된 CEK(SEK또는 PEK가 포함되어 있음)를 이용하여 TEK를 복호한다(S151).

즉, AES-Encryption {REK} (CEK) ( REK를 이용해 복호 ( CEK = SEK or PEK

AES-Encryption {SEK} (TEK) 또는 AES-Encryption {PEK} (TEK) ( SEK 또는 PEK 를 이용해 복호화( TEK

여기서 AES-Encryption { x } ( y )는 암호화 키 x를 사용해서 평문 y를 AES 암호화한 값을 나타낸다. 이에 대한 복호화는 암호화 키 x를 사용해서 수행하여 복호화 결과 y를 얻는다.

상기 DRM 에이전트는 상기 S111 과정의 상기 TEK 요청에 응답하여, TEK 응답 메시지를 상기 BCAST 클라이언트로 전송한다(S152). 상기 TEK 응답 메시지는 상기 복호된 TEK를 포함한다. 이때, 상기 TEK 응답 메시지는 status를 더 포함한다. 상기 status는 상기 복호가 성공적이면 success 또는 success에 해당하는 값을 포함한다. 반대로 상기 복호가 실패이면, 상기 status는 fail 또는 fail을 나타내는 값을 포함한다. 또한, 상기 TEK 응답 메시지는 status code를 더 포함한다. 상기 status code는 상기 복호가 실패인 경우, ‘TEK Decryption Failed’로 설정된다.

상기 BCAST 클라이언트는 상기 TEK를 이용하여, 상기 브로드캐스트 서버(500)로부터 브로드캐스트되는 컨텐츠를 소비한다.

6) 다음으로, TEK 요청의 수신(S161)과 동기화하여 권리 존재 확인 과정(S170)을 설명하면 다음과 같다.

상기 BCAST 클라이언트가 상기 TEK를 이용하여 컨텐츠를 소비하는 중에, 일정 주기 혹은 미리 설정된 시기에 도달하면, 상기 DRM 클라이언트로 TEK 요청 메시지를 다시 전송한다(S171). 상기 TEK 요청 메시지는 전술한 바와 동일하므로, 위의 내용을 준용하기로 한다.

상기 DRM 에이전트는 상기 TEK 요청 메시지를 수신하면, 상기 <srmPing> 엘리먼트 내의 <synchonised> 서브 엘리먼트에 따라 상기 SRM Ping 프로토콜을 수행한다.

구체적으로, 상기 DRM 에이전트는 상기 SRM 내에 권리가 존재하는지 확인하기 위해, 권리 존재 확인 요청 메시지 또는 SRM Ping Request 메시지를 상기 SRM 에이전트로 전송한다(S172). 이때, 상기 권리 존재 확인 요청 메시지 또는 상기 SRM Ping Request 메시지는 상기 TEK 요청 메시지에 포함된 CID에 대응하는 권리에 해당하는 상기 New Handle을 포함한다. 또한, 상기 권리 존재 확인 요청 메시지 또는 상기 SRM Ping Request 메시지는 임의 값(Random Value)을 더 포함한다. 이를 위해 상기 DRM 에이전트는 상기 임의 값을 생성한다. 상기 임의 값은 예를 들어 Pseudo-Random algorithm을 사용하여 생성하도록 구현될 수 있다. 상기 임의 값은 상기 권리 존재 확인 요청 메시지 또는 상기 SRM Ping Request 메시지의 최신성을 보장하고, 아울러 replay 공격을 방지하는 데에 이점이 있다. 한편, 상기 DRM 에이전트는 권리 존재 확인 응답 메시지 또는 SRM Ping Response 메시지를 수신할 때까지 상기 임의 값의 저장을 유지하고, 추후 수신시 replay 공격 여부를 판단한다.

상기 권리 존재 확인 요청 메시지 또는 SRM Ping Request 메시지는 아래와 같은 필드를 포함할 수 있다.

필드	설명
Handle	Handle은 SRM에 저장될 Rights 중에서 BCAST Service를 받기 위해서 존재 유무에 대한 확인이 필요한BCAST Rights를 나타내는 값. Handle은 SRM에 저장되어있는 Rights의 나타내는 값.
RAND	RAND는 DRM 에이전트에 의해서 생성된 random한 값. SRM Ping Response 수신 후 DRM 에이전트에 의해서 BCAST Rights의 존재 유무 확인을 위한 Hash Data의 replay를 방지하기 위한 값.

상기 SRM 에이전트는 상기 권리 존재 확인 요청 메시지 또는 SRM Ping Request 메시지를 수신하면, 무결성을 검증한다. 그리고, 상기 Handle에 대응하는 권리를 상기 SRM 내에서 찾는다(S173).

상기 SRM 내에서 상기 Handle에 대응하는 권리를 찾으면, 상기 SRM 에이전트는 수신한 메시지 내에 포함된 임의값과 상기 Handle에 대응하는 권리의 REK에 대한 해쉬값을 생성한 후, 상기 생성된 해쉬값을 포함하는 권리 존재 확인 응답 메시지 또는 SRM Ping Response 메시지를 상기 DRM 에이전트로 전송한다(S174). 이때, 상기 Hash 값을 전달하는 이유는 상기 REK를 드러내지 않으면서도 권리를 실제로 소유하고 있음을 알리기 위함이다. 상기 해쉬 값은 SHA-1 해쉬 알고리즘을 이용하여 생성될 수 있다. 상기 권리 존재 확인 응답 메시지 또는 SRM Ping Response 메시지는 status를 더 포함한다. 상기 권리 존재 확인 요청 메시지 또는 상기 SRM Ping Request 메시지가 잘 정의되어 있고, HMAC 값이 성공적으로 검사되었으며, 상기 권리가 상기 SRM 내에 존재하는 경우, 상기 Status 필드는 success로 설정된다.

상기 권리 존재 확인 응답 메시지 또는 SRM Ping Response 메시지는 아래의 표에 나타난 필드를 포함할 수 있다.

필드	설명
Status	SRMPingRequest 메시지의 처리 결과. Status 값은 표 9에 정의되어있다. 만약 Status에 어떠한 에러가 포함되어 있을 경우, SrmPingResponse메시지는 Status 필드만 포함하게 된다.
Hash Data	H(RAND \| REK). RAND 는 SRM Ping Request 메시지를 통해서 DRM 에이전트로부터 수신한 값이며, REK는 SRM Ping Request의 Handle에 해당되는 Rights에 대한 REK를 나타낸다. BCAST 서비스를 위해 사용되는 경우, 이 값은 BCAST 권리의 REK에 해당된다. H( )는 SHA-1 Hash 알고리즘을 나타낸다. Hash Data는 RAND와 REK를 hash한 값이며 RAND와 REK는 concatenated되어 있다.

아래의 표 9는 status의 값을 나타낸다.

상태 값	설명
Success	SRM Ping Request 메시지에 대한 처리가 성공적으로 수행됨.
Field Integrity Verification Failed	SRM Ping Request 메시지에 대한 HMAC 값에 대한 검증이 실패함. 즉 SRM 에이전트가 SRM Ping Request 메시지에 대한 HMAC값을 생성한 후 SRM Ping Request에 포함된 HMAC 값을 비교한 결과 일치하지 않은 경우.
Handle Not Found	DRM 에이전트가 확인 요청한 Rights가 SRM에 존재하지 않음. 즉 SRM Ping Request에 포함된 Handle이 SRM에 존재하지 않음.
Parameter Failed	SRM Ping Request 메시지의 field가 적절하지 않은 길이와 구조를 갖고 있음.
Unknown Error	Other errors.

7) 다음으로, 권리가 존재하는 것으로 확인되면 TEK 복호하고 전달하는 과정(S180)을 설명하면 다음과 같다.

상기 DRM 에이전트가 상기 권리 존재 확인 응답 메시지 또는 SRM Ping Response 메시지를 수신하면, 상기 DRM 에이전트는 상기 메시지에 대한 HMAC 필드의 검증을 통해 무결성을 검증한다.

상기 HMAC 검증이 실패하거나, Status가 Success로 설정되어 있지 않거나, DRM 에이전트가 올바른 SRM Ping Response를 수신하지 못했을 경우, SRM Ping 프로토콜은 실패로 간주된다. 그리고 DRM 에이전트는 SRM Ping 프로토콜을 종료하고 BCAST 권리에 대한 사용을 중지한다. 그리고 상기 DRM 에이전트는 TEK 응답 메시지의 Status를 fail로 하고, ‘Rights Presence Verification Fail’ error code와 함께 BCAST 클라이언트로 전송한다.

반면, 상기 무결성 검증을 성공적으로 마치면, 상기 DRM 에이전트는 상기 수신한 메시지 내에 포함된 Hash 값을 검증한다. 상기 DRM 에이전트는 상기 검증을 통해 상기 SRM내에 상기 권리가 존재하는지를 확인할 수 있다. 상기 해쉬값의 검증을 위해서, 상기 DRM 에이전트는 상기 수신함 메시지 내의 임의값과 상기 DRM 에이전트가 상기 REK를 해쉬한 값을 생성한 후, 상기 수신한 메시지 내의 해쉬값과 비교한다.

만약, 두 값이 동일하면 상기 DRM 에이전트는 SRM에 상기 권리가 존재하는 것으로 판단한다. 그리고, 상기 권리가 존재하는 것으로 판단되면, 상기 DRM 에이전트는 TEK를 복호한다(S181). 상기 TEK 복호는 전술한 내용과 동일하므로, 준용하기로 한다.

8) 다음으로, 컨텐츠이 이용 종료되면 권리의 상태를 원상 복구하는 과정(S190)을 설명하면 다음과 같다.

상기 BCAST 클라이언트에서 상기 브로드캐스트 컨텐츠의 이용이 종료되면,상기 DRM 에이전트는 상기 SRM 에이전트로 권리 활성화 요청 메시지, 예컨대 Rights Enablement Request 메시지를 전송한다(S191). 상기 권리 활성화 요청 메시지는 상기 권리에 대한 Handle과 상기 권리에 대한 상태 정보(Stateful Rights의 경우)를 포함한다.

상기 SRM 에이전트는 상기 권리 활성화 요청 메시지를 수신하면, 상기SRM 내에서 비활성화되었던 권리를 활성화 또는 인에이블링한다(S192). 이때부터 상기 SRM 내의 상기 권리는 상기 SRM이 다른 단말에 장착되면, 상기 다른 단말 내의 DRM 에이전트에 의해 접근될 수 있다.

상기 SRM 에이전트는 상기 활성화 또는 인에이블이 성공적이였으면, success를 나타내는 Status를 포함하는 권리 활성화 응답 메시지 예컨대 Rights Enablement Response 메시지를 생성한다. 그리고, 상기 SRM 에이전트는 상기 생성한 메시지를 상기 DRM 에이전트로 전송한다(S193).

상기 DRM 에이전트는 상기 권리 활성화 응답 메시지를 수신하면, 상기 메시지 내의 status를 확인한다. 상기 status가 성공인 경우, 상기 DRM 에이전트는 임시 저장하였던 상기 권리에 대응하는 REK와 권리 정보(Rights Information)을 모두 삭제한다(S194).

도 6는 본 발명의 제2실시예를 나타낸 흐름도이다.

도 6를 참조하여 알 수 있는 바와 같이, 본 발명의 제2 실시예에 따르면 일정 주기 마다 권리 존재 확인 프로토콜, 즉 SRM Ping 프로토콜이 수행된다.

즉, 제2 실시예에 따르면, 권리 내의 <srmPing> 엘리먼트 내에 <checkInterval> 서브 엘리먼트가 포함되어 있는 경우, 상기 <checkInterval> 서브 엘리먼트 내에 지정된 주기에 대한 타이머가 만료하기 전까지는, 상기 DRM 에이전트는 S230과정과 S240 과정에서 획득한 권리 정보와 REK를 이용하여 상기 BCAST 클라이언트로부터의 TEK 요청에 응답한다. 상기 타이머가 만료되면, 상기 DRM 에이전트는 SRM Ping 프로토콜을 수행한다.

도 6에 도시된 제2 실시예는 TEK 요청 수신 과정(S211), 권리 미 존재시 핸들 리스트 조회 과정(S220), 권리 정보 조회 과정(S230), 권리 선택 및 확인 과정과 REK 조회 과정(S240), 타이머를 구동하고 타이머 만료 전까지 TEK를 복호하여 전달하는 과정(S260), 타이머의 만료시 권리 존재 확인 과정(S270), 타이머를 리셋하고 타이머 만료전까지 TEK를 복호하여 전달하는 과정(S280), 컨텐츠이 이용 종료되면 권리의 상태를 원상 복구하는 과정(S290)을 포함한다.

1~4) 상기 TEK 요청 수신 과정(S211), 권리 미 존재시 핸들 리스트 조회 과정(S220), 권리 정보 조회 과정(S230), 권리 선택 및 확인 과정과 REK 조회 과정(S240)은 도 5에 도시된 각 과정과 동일하므로, 도 5의 설명 내용을 준용하기로 한다.

5) 다음으로, 타이머를 구동하고 타이머 만료 전까지 TEK를 복호하여 전달하는 과정(S260)을 설명하면 다음과 같다.

상기 DRM 에이전트는 상기 REK 응답 메시지를 수신하면(S244), 상기 REK 응답 메시지 내의 REK를 이용하여 상기 권리 정보 내의 <rights> 엘리먼트 내의 CEK를 복호화하고, 상기 복호된 CEK(SEK또는 PEK가 포함되어 있음)를 이용하여 TEK를 복호한다(S261).

즉, AES-Encryption {REK} (CEK) ( REK를 이용해 복호 ( CEK = SEK or PEK

상기 DRM 에이전트는 상기 TEK의 복호가 완료되면, 상기 <checkInterval> 서브 엘리먼트 내에 지정된 주기에 따라 타이머, 예컨대 Ping 타이머를 구동한다(S262). 상기 DRM 에이전트는 상기 타이머가 만료되면, 즉 상기 타이머가 상기 <checkInterval> 서브 엘리먼트에 지정된 주기에 도달하게 되면, SRM Ping 프로토콜을 실행하고 상기 타이머를 다시 reset하여, 반복적으로 SRM Ping 프로토콜을 실행하도록 한다.

상기 DMR 에이전트는 상기 복호된 TEK를 포함하는 TEK 응답 메시지를 상기 BCAST 클라이언트로 전달한다(S263).

상기 타이머가 만료하기 전에, 상기 BCAST 클라이언트로부터 상기 DRM 클라이언트가 TEK 요청 메시지를 수신하면(S264), 상기 DRM 에이전트는 S230과정과 S240 과정에서 획득한 권리 정보와 REK를 이용하여 TEK를 복호하고(S265), 상기 복호된 TEK를 포함하는 TEK 응답 메시지를 상기 BCAST 클라이언트로 전송한다 (S266). 상기 TEK 응답 메시지는 status를 더 포함한다. 상기 status는 상기 타이머가 만료하지 않았을 경우, success 또는 success를 나타내는 값을 갖는다. 반대로, 상기 타이머가 만료하여, SRM Ping 프로토콜을 수행하였으나 실패한 경우, 상기 status는 Fail 또는 fail을 나타내도록 설정된다. 이때, 상기 실패가 상기 권리 존재 확인 과정에서의 에러에 기인한 것이면 Status Code는 ‘Rights Presence Verification Failed’로 설정되며, TEK 복호에서의 에러에 기인한 것이면 Status Code는 ‘TEK Decryption Failed’로 설정된다.

6) 다음으로, 타이머의 만료시 권리 존재 확인 과정(S270)을 설명하면 다음과 같다.

한편, 상기 타이머가 만료하면(S271), 상기 DRM 에이전트는 SRM Ping 프로토콜을 상기 SRM 에이전트와 수행한다(S272~S274). 이러한 과정(S272~S274)은 도 5에 도시된 과정(S172~S174)과 각각 동일하므로, 도 5의 설명 내용을 준용하기로 한다.

7) 다음으로, 타이머를 리셋하고 타이머 만료전까지 TEK를 복호하여 전달하는 과정(S280)에 대해서 설명한다.

상기 SRM Ping 프로토콜이 성공적으로 수행되어, 권리가 상기 SRM 내에 존재하는 것으로 확인되면(S281), 상기 DRM 에이전트는 상기 타이머를 리셋한다(S282).

상기 타이머가 만료하기 전에, 상기 BCAST 클라이언트로부터 TEK 요청 메시지를 수신하면, 상기 DRM 에이전트는 S230과정과 S240 과정에서 획득한 권리 정보와 REK를 이용하여 TEK를 복호하고, 상기 복호된 TEK를 포함하는 TEK 응답 메시지를 상기 BCAST 클라이언트로 전송한다

8) 한편, 상기 BCAST 클라이언트에서 상기 브로드캐스트 컨텐츠의 이용이 종료되면, 상기 DRM 에이전트는 상기 SRM 내의 권리의 상태를 원상 복구하는 과정(S290)을 수행한다. 이는 도 5에 도시된 S190 과정과 동일하므로, 도 5의 내용을 준용하기로 한다.

한편, 도 5은 권리 내의 <srmPing> 엘리먼트 내에 <schronized> 서브엘리먼트가 포함된 경우에 동작을, 그리고 도 6은 권리 내의 <srmPing> 엘리먼트 내에 <checkInterval> 서브 엘리먼트가 포함된 경우의 동작을 나타내었다. 권리 내의 <srmPing> 엘리먼트 내에 <syncThreshold> 서브 엘리먼트가 포함된 경우의 동작에 대한 설명은 도 5 및 도 6의 설명으로부터 당업자가 용이하게 이해할 수 있는 바, 그 예시를 생략하기로 한다. 그러나 권리 내의 <srmPing> 엘리먼트 내에 <syncThreshold> 서브 엘리먼트가 포함된 경우의 동작도 본 발명에 포함되는 것으로 해석되어야 한다.

도 7는 본 발명의 제3실시예를 나타낸 흐름도이다.

도 7에 도시된 제3 실시예는 도 5에 도시된 제1 실시예 및 제2 실시예와 달리, DRM 에이전트가 상기 SRM 에이전트로부터 획득한 권리 정보와 REK를 이용하여 TEK를 복호하면(S351), SRM 내의 권리의 상태를 원상 복구하는 과정(S390)을 수행한다.

이와 같이 도 7에 도시된 제3 실시예는 TEK 요청 수신 과정(S311), 권리 미 존재시 핸들 리스트 조회 과정(S320), 권리 정보 조회 과정(S330), 권리 선택 및 확인 과정과 REK 조회 과정(S340), 상기 TEK의 복호(S351)가 성공적으로 완료되면 SRM 내의 권리의 상태를 원상 복구하는 과정(S390), 권리 존재 확인 과정(S370), 권리가 존재하는 것으로 확인되면 TEK 복호하고 전달하는 과정(S380)을 포함한다. 구체적으로 설명하면 다음과 같다.

1~4) 상기 TEK 요청 수신 과정(S311), 권리 미 존재시 핸들 리스트 조회 과정(S320), 권리 정보 조회 과정(S330), 권리 선택 및 확인 과정과 REK 조회 과정(S340)은 도 5에 도시된 각 과정과 동일하므로, 도 5의 설명 내용을 준용하기로 한다.

5) 다음으로, 상기 TEK의 복호(S351)가 성공적으로 완료되면 SRM 내의 권리의 상태를 원상 복구하는 과정(S390)이 수행된다.

상기 DRM 에이전트는 상기 REK 응답 메시지를 수신하면(S244), 상기 REK 응답 메시지 내의 REK를 이용하여 상기 권리 정보 내의 <rights> 엘리먼트 내의 CEK를 복호화하고, 상기 복호된 CEK(SEK또는 PEK가 포함되어 있음)를 이용하여 TEK를 복호한다(S351).

상기 복호(S351)가 성공적으로 완료되면, 상기 DRM 에이전트는 상기 SRM 내의 권리의 상태를 원상 복구하는 과정(S390)을 수행한다. 즉 상기 DRM 에이전트는 상기 SRM 에이전트로 권리 활성화 요청 메시지, 예컨대 Rights Enablement Request 메시지를 전송하고(S391), 상기 SRM 에이전트는 상기SRM 내에서 비활성화되었던 권리를 활성화 또는 인에이블링한다(S393). 그리고, 상기 SRM 에이전트는 권리 활성화 응답 메시지 예컨대 Rights Enablement Response 메시지를 상기 DRM 에이전트로 전송한다(S393).

그리고 상기 DRM 에이전트는 상기 복호된 TEK를 포함하는 TEK 응답 메시지를 상기 BCAST 클라이언트로 전송한다(S352)

6) 다음으로 권리 존재 확인 과정(S370)이 수행된다. 상기 권리 존재 확인 과정(S370)은 도 5에 도시된 제1 실시예와 같이 TEK 요청 메시지와 동기되어 수행될 수도 있고, 혹은 도 6에 도시된 제2 실시예와 같이 타이머가 만료할 때 수행될 수도 있다. 또는 상기 권리 존재 확인 과정(S370)은 TEK 요청의 수신 횟수가 <syncThreshol> 서브 엘리먼트에 지정된 일정 임계값에 도달할 때 마다 수행될 수도 있다.

7) 다음으로, 권리가 존재하는 것으로 확인되면 TEK 복호하고 전달하는 과정(S380)이 수행된다. S380과정은 도 5에 도시된 S180과정과 동일하므로, S180과정에 대한 설명 내용을 준용하기로 한다.

8) 한편, 컨텐츠의 이용 종료되면, 상기 DRM 에이전트는 임시 저장하였던 상기 권리에 대응하는 REK와 권리 정보(Rights Information)을 모두 삭제한다.

도 8는 본 발명의 제4실시예를 나타낸 흐름도이다.

도 8에 도시된 제4 실시예는 준비 요청 과정(S411), 핸들 리스트 조회 과정(S420), 권리 정보 조회 과정(S430), 권리 선택 및 확인 과정과 REK 조회 과정(S440), 준비 완료 응답 전달 과정(S451), TEK 요청에 따른 권리 존재 확인 후 TEK 전달 과정(S460), 권리 존재 확인 과정 및 TEK 전달 과정(S470), 컨텐츠의 이용 종료되면 SRM 내의 권리의 상태를 원상 복구하는 과정(S490)을 포함한다

이와 같은 도 8에 도시된 본 발명의 제4 실시예는 BCAST 클라이언트와 DRM 에이전트 간의 프로토콜, 즉 송수신되는 메시지가 변형된 예를 나타낸다.

따라서, 이하에서는 상기 DRM 에이전트와 SRM 에이전트 간에 수행되는 핸들 리스트 조회 과정(S420), 권리 정보 조회 과정(S430), 권리 선택 및 확인 과정과 REK 조회 과정(S440), 컨텐츠의 이용 종료되면 SRM 내의 권리의 상태를 원상 복구하는 과정(S490)에 대한 설명은 상세하게 하지 않기로 한다.

그리고 이하에서는 BCAST 클라이언트와 DRM 에이전트 간에 수행되는 준비 요청 과정(S411), 준비 완료 응답 전달 과정(S451), TEK 요청에 따른 권리 존재 확인 후 TEK 전달 과정(S460)에 대해서 설명하기로 한다.

1) 먼저 상기 준비 요청 수신 과정(S111)을 설명하면 다음과 같다.

상기 제1 단말(110) 내의 BCAST 클라이언트는 상기 단말(110)의 사용자의 요청에 따라 혹은 다른 애플리케이션의 요청에 따라 브로드캐스트 컨텐츠를 이용하여야 하는 경우, 준비 요청 메시지 예컨대 도시된 SEK Preparation Request 메시지를 상기 DRM 에이전트로 전송한다(S411).

상기 준비 요청 메시지는 CID를 포함한다. 상기 CID는 Content ID이며, SEK 또는 PEK를 구분하기 위한 고유 식별자이다. 이와 같은 상기 CID는 program_CID 또는 service_CID를 나타낼 수 있다. 또는 상기 권리가 브로드캐스트 권리(또는, RO)일 경우, program_BCI 또는 service_BCI를 나타낼 수 있다.

2~4) 핸들 리스트 조회 과정(S420), 권리 정보 조회 과정(S430), 권리 선택 및 확인 과정과 REK 조회 과정(S440)은 도 5에 도시된 각 과정과 동일하므로, 도 5의 설명 내용을 준용하기로 한다.

5) 다음으로 준비 완료 응답 전달 과정(S451)이 수행된다.

상기 DRM 에이전트는 상기 REK 응답 메시지를 수신하면(S444), 상기 REK 응답 메시지 내의 REK를 이용하여 상기 권리 정보 내의 <rights> 엘리먼트 내의 CEK를 복호화하고, 상기 복호된 CEK로부터 SEK 또는 PEK를 획득한다.

이와 같이 상기 SEK 또는 상기 PEK를 획득완료 하면, 상기 DRM 에이전트는 상기 BCAST 클라이언트로 준비 완료 응답 메시지, 예컨대 SEK Preparation Response 메시지를 전송한다(S451).

6) 다음으로, TEK 요청에 따른 권리 존재 확인 후 TEK 전달 과정(S460)이 수행된다.

상기 DRM 에이전트는 상기 BCAST 클라이언트로부터 TEK 요청 메시지, 예컨대 TEK Description Request 메시지를 수신한다(S461). 상기 TEK Description Request 메시지는 전술한 바와 같이 CID를 포함한다. 또한, 상기 TEK Description Request 메시지는 SEK(또는 PEK)로 암호화된 TEK, 즉 도시된 AES-Encryption(SEK)(TEK)를 포함한다.

그러면, 상기 DRM 에이전트는 권리 존재 확인 요청 메시지 또는 SRM Ping Request 메시지를 상기 SRM 에이전트로 전송한다(S462). 이때, 상기 권리 존재 확인 요청 메시지 또는 상기 SRM Ping Request 메시지는 상기 CID에 대응하는 권리에 해당하는 상기 New Handle을 포함한다. 또한, 상기 권리 존재 확인 요청 메시지 또는 상기 SRM Ping Request 메시지는 임의 값(Random Value)을 더 포함한다

상기 SRM 에이전트는 상기 권리 존재 확인 요청 메시지 또는 SRM Ping Request 메시지를 수신하면, 무결성을 검증한다. 그리고, 상기 Handle에 대응하는 권리를 상기 SRM 내에서 찾는다(S463). 상기 SRM 내에서 상기 Handle에 대응하는 권리를 찾으면, 상기 SRM 에이전트는 수신한 메시지 내에 포함된 임의값과 상기 Handle에 대응하는 권리의 REK에 대한 해쉬값을 생성한 후, 상기 생성된 해쉬값을 포함하는 권리 존재 확인 응답 메시지 또는 SRM Ping Response 메시지를 상기 DRM 에이전트로 전송한다(S464).

상기 DRM 에이전트는 상기 권리 존재 확인 응답 메시지 또는 SRM Ping Response 메시지를 수신하면, 상기 SEK또는 PEK를 이용하여 TEK를 복호한다(S465).

그리고, 상기 DRM 에이전트는 상기 복호된 TEK를 포함하는 TEK 응답 메시지, 예컨대 TEK Description Response 메시지를 상기 BCAST 클라이언트로 전송한다(S466).

그러면, 상기 BCAST 클라이언트는 상기 TEK를 이용하여 브로드캐스트 컨텐츠를 소비한다.

7) 다음으로, 상기 브로드캐스트 컨텐츠 이용 중에 권리 존재 확인 과정 및 TEK 전달 과정(S470)이 수행된다.

상기 권리 존재 확인 과정(S470)은 도 5에 도시된 제1 실시예와 같이 TEK 요청 메시지와 동기되어 수행될 수도 있고, 혹은 도 6에 도시된 제2 실시예와 같이 타이머가 만료할 때 수행될 수도 있다. 또는 상기 권리 존재 확인 과정(S370)은 TEK 요청의 수신 횟수가 <syncThreshol> 서브 엘리먼트에 지정된 일정 임계값에 도달할 때 마다 수행될 수도 있다.

8) 다음으로, 상기 BCAST 클라이언트에서 상기 브로드캐스트 컨텐츠의 이용이 종료되면, 상기 DRM 에이전트는 상기 SRM 내의 권리의 상태를 원상 복구하는 과정(S490)을 수행한다. 이는 도 5에 도시된 S190 과정과 동일하므로, 도 5의 내용을 준용하기로 한다.

9) 한편, 상기 DRM 에이전트는 종료 요청 메시지, 예컨대 SEK 종료 요청 메시지를 상기 BCAST 클라이언트로 전송한다(S495). 상기 종료 요청 메시지는 상기 권리가 참조하고 있는 CID를 포함할 수 있다. 상기 종료 요청 메시지는 상기 SRM 내의 권리를 활성화한 결과와, 상기 단말 내에 임시 저장되었던 상기 권리의 삭제 결과에 대한 정보를 더 포함할 수 있다.

도 9는 본 발명의 실시예들을 DRM 에이전트와 SRM 에이전트 간의 프로토콜을 중심으로 나타낸 예시도이다.

도 9에 도시된 예시도는 단말이 BCAST 권리를 소비할 때, <srmPing> 제약에 따라 메모리 카드, 즉 SRM의 존재를 확인하는 것을 나타낸다. 구체적으로 설명하면 다음과 같다.

1) 먼저 SRM으로부터 권리를 검색(Retrieval)한다.

구체적으로, 브로드캐스트 컨텐츠의 권리에 대응하는 Handle을 알 수 없는 경우, 상기 대응하는 Handle을 리스트 조회 과정, 즉 Handle List Query 과정을 이용하여 획득한다.

이어서 권리 정보 조회 과정, 즉 Rights Info Query 과정을 통해서 SRM으로부터 권리 정보를 획득한다. 이때, 상기 권리 정보를 제공한 SRM의 아이디를 저장한다.

이어서, REK 조회 과정, 즉, REK Query 과정을 통해서 SRM으로부터 REK를 획득한다.

2) 다음으로, 브로드캐스트 컨텐츠를 소비하기 위해 권리를 이용하고, 권리 존재 확인 과정을 수행한다.

브로드캐스트 컨텐츠를 소비하기 위해 권리를 이용하는 동안, 상기 권리를 제공한 SRM이 장착되어 있는지를 확인하기 위해, 권리 존재확인 과정, 즉 SRM Ping 프로토콜을 수행한다.

상기 권리 내에 <srmPing> 제약이 포함되어 있는 경우, 상기 SRM Ping 프로토콜을 수행되어야 상기 권리가 이용될 수 있다. 만약 상기 SRM Ping 프로토콜이 지원되지 않는 경우, 상기 <srmPIng> 제약이 포함된 권리는 이용될 수 없다. 상기 따라서, 상기 DRM 에이전트는 상기 SRM Ping 프로토콜을 지원해야 한다.이를 위해 상기 DRM 에이전트는 DRM 시간을 지원하여야 한다. 상기 SRM 에이전트도 마찬가지로 상기 SRM Ping 프로토콜을 지원해야 한다.

상기 SRM Ping 프로토콜은 상기 DRM 에이전트와 상기 SRM 에이전트 간에 수행된다. 상기 SRM Ping 프로토콜의 수행을 위해 상기 DRM 에이전트와 상기 SRM 에이전트 간에는 SAC가 설정되어야 한다.

상기 SRM Ping 프로토콜은 상기 DRM 에이전트가 SRM Ping Request 메시지를 상기 SRM 에이전트로 전송함으로써, 개시된다. 상기 SRM 에이전트는 일부 검즐을 수행한 후에 SRM Ping Response 메시지를 상기 DRM 에이전트로 전송한다.

상기 권리 내에의 <checkInterval> 서브 엘리먼트에 지정된 2개의 연속하는 수행들 간의 시간이 지정되어 있는 경우, 상기 DRM 에이전트는 상기 SRM Ping 프로토콜을 반복적으로 수행한다. 만약, 상기 <checkInterval> 서브 엘리먼트가 존재하지 않는 경우, SRM Ping 프로토콜은 BCAST STKM의 매 호출 직전에 수행된다.

만약 상기 SRM Ping 프로토콜이 실패로 종료되거나, 성공적으로 수행되지 않는 경우, 상기 DRM 에이전트는 상기 권리의 이용을 중단한다. 그리고, 상기 DRM 에이전트는 임시 저장한 권리와 대응하는 REK를 삭제한다.

3) 한편, 상기 브로드캐스트 컨텐츠의 소비가 끝나면, 권리의 이용을 종료한다.

상기 브로드캐스트 컨텐츠의 소비가 끝남으로써, 권리의 이용이 끝나게 되면, 상기 DRM 에이전트는 상기 SRM Ping 프로토콜의 수행을 중단하고, 예컨대 Rights Enablement 프로토콜을 이용하여 상기 SRM 내의 권리를 활성화한다. 그리고, 상기 DRM 에이전트는 임시 저장한 권리와 대응하는 REK를 삭제한다.

도 10는 본 발명에 따른 단말의 동작을 나타낸 흐름도이다.

상기 DRM 에이전트는 메모리 카드 내에 권리가 존재하는지 여부의 확인에 대한 제약이 브로드캐스트 컨텐츠에 대한 권리 내에 존재하는지 확인한다(S510).

상기 제약이 존재하는 경우, 상기 DRM 에이전트는 권리 존재 확인 요청 메시지를 상기 메모리 카드로 전송한다(S520). 이때, 상기 권리 존재 확인 요청 메시지는 상기 권리에 대한 식별 정보와 임의 값을 포함할 수 있다.

상기 DRM 에이전트는 상기 메모리 카드로부터 해쉬값을 포함하는 권리 존재 확인 응답 메시지를 수신한다(S530). 이때, 상기 해쉬값은 상기 임의값과 상기 권리 내의 소정 정보 중 적어도 하나 이상에 대해 얻어진 것일 수 있다.

그러면, 상기 DRM 에이전트는 상기 권리가 상기 SRM 내에 존재하는지 확인한다(S540). 이때 상기 확인은 상기 해쉬값을 이용하여 이루어질 수 있다.

이어서, 상기 권리의 존재 여부에 따라 상기 브로드캐스트 컨텐츠의 이용 여부를 결정한다(S550).

상기 DRM 에이전트는 상기 권리가 존재하지 않는 경우, 상기 권리의 이용을 시작하지 않거나, 중단한다(S560).

그러나, 상기 DRM 에이전트는 상기 권리가 존재하는 경우, 상기 권리의 이용을 시작 또는 지속한다(S570).

여기까지 설명된 본 발명에 따른 방법은 소프트웨어, 하드웨어, 또는 이들의 조합으로 구현될 수 있다. 예를 들어, 본 발명에 따른 방법은 저장 매체(예를 들어, 내부 메모리, 플래쉬 메모리, 하드 디스크, 기타 등등)에 저장될 수 있고, 마이크로프로세서, 제어기, 마이크로 제어기, ASIC(Application Specific Integrated Circuit) 등과 같은 프로세서 에 의해서 실행될 수 있는 소프트웨어 프로그램 내에 코드들 또는 명령어들로 구현될 수 있다. 이에 대해서 도 11를 참조하여 설명하기로 한다.

도 11는 본 발명의 따른 단말(100) 및 SRM(150)의 구성 블록도이다.

도 11에 도시된 바와 같이 상기 단말(100)은 저장 수단, 송수신부, 커넥터, 컨트롤러를 포함한다. 그리고 상기 메모리 카드, 즉 SRM은 저장 수단, 커넥터, 컨트롤러를 포함한다.

상기 커넥터는 상기 단말(100)과 상기 메모리 카드, 즉 SRM을 서로 접속시킨다.

상기 저장 수단들은 도 4 내지 도 8에 도시된 방법이 구현된 소프트웨어 프로그램을 저장한다. 그리고, 상기 저장 수단들은 수신한 각 메시지 내의 정보들을 저장한다.

상기 컨트롤러들 각각은 상기 저장 수단들 및 상기 송수신부들을 각기 제어한다. 구체적으로 상기 컨트롤러들은 상기 저장 수단들에 각기 저장된 상기 방법들을 각기 실행한다. 그리고 상기 컨트롤러들 각각은 상기 송수신부들을 통해 상기 전술한 신호들을 전송한다.

이상에서는 본 발명의 바람직한 실시 예를 예시적으로 설명하였으나, 본 발명의 범위는 이와 같은 특정 실시 예에만 한정되는 것은 아니므로, 본 발명은 본 발명의 사상 및 특허청구범위에 기재된 범주 내에서 다양한 형태로 수정, 변경, 또는 개선될 수 있다.

100: 단말
110: 제1 단말
120: 제2 단말
150: SRM(Secure Removable Card)
300: 컨텐츠 발급자(Contents Issuer)
400: 권리 발급자(Rights Issuer)
500: 브로드캐스트 서버

Claims

메모리 카드가 장착된 단말에서 브로드캐스트 컨텐츠에 대한 권리를 이용하는 방법으로서,
상기 단말이 메모리 카드가 존재하는지 여부의 확인에 대한 제약이 브로드캐스트 컨텐츠에 대한 권리 내에 포함되어 있는지 여부를 확인하는 단계와, 여기서 상기 제약은 synchronised 엘리먼트, syncThreshold 엘리먼트 및 checkInterval 엘리먼트 중 적어도 하나를 포함하고; 상기 단말이, 상기 브로드캐스트 컨텐츠에 대한 권리 내에 상기 제약이 포함되어 있는 경우 상기 권리의 존재 여부를 확인하기 위한 요청 메시지를 상기 메모리 카드로 전송하는 단계와;
상기 단말이 상기 메모리 카드로부터 응답 메시지를 수신하는 단계와;
상기 단말이 상기 응답 메시지를 확인하는 단계와; 그리고
상기 단말이 상기 응답 메시지 내에 실패를 나타내는 상태 정보가 포함된 경우 상기 브로드캐스트 컨텐츠에 대한 권리의 소비를 중단하거나 또는 개시하지 않는 단계를 포함하되,
상기 synchronised 엘리먼트는 상기 권리의 존재 여부에 대한 확인이 TEK(Traffic Encryption Key) 요청과 동기화되어 수행되어야 함을 나타내고,
상기 syncThreshold 엘리먼트는 STKM(Short Term Key Messages)의 횟수를 나타내되, 상기 STKM의 횟수가 임계 값에 도달한 경우 상기 TEK 요청을 통하여 상기 권리의 존재 여부에 대한 확인이 수행될 수 있도록 하기 위한 것이고,
상기 checkInterval 엘리먼트는 상기 권리의 존재 여부에 대한 확인이 반복적으로 수행될 수 있도록 하기 위한 두 개의 연속적인 실행들 간의 시간 간격을 나타내는 것을 특징으로 하는 권리 이용 방법.
제1항에 있어서, 상기 권리 존재 확인 요청 메시지는
상기 TEK 요청에 따라 전송되는 것을 특징으로 하는 권리 이용 방법.
제1항에 있어서, 상기 제약은
srmPing (Secure Removable Media Ping) 엘리먼트 인 것을 특징으로 하는 권리 이용 방법.
삭제
제1항에 있어서, 상기 권리 존재 확인 요청 메시지의 전송 단계는
상기 단말 내의 DRM (Digital Rights Management) 에이전트가 상기 단말 내의 BCAST(Broadcast) 클라이언트로부터 TEK 요청 메시지를 수신하는 단계와;
상기 DRM 에이전트에 의하여 수신된 상기 TEK 요청 메시지에 응답하여 상기 권리 존재 확인 요청 메시지를 전송하는 단계를 포함하는 것을 특징으로 하는 권리 이용 방법.
제1항에 있어서, 상기 권리 존재 확인 요청 메시지의 전송 단계는
상기 단말 내의 DRM 에이전트가 상기 제약 내의 상기 syncThreshold 엘리먼트에 의하여 지정된 횟수를 확인하는 단계와;
상기 횟수의 확인에 따라 상기 권리 존재 확인 요청 메시지를 전송하는 단계를 포함하는 것을 특징으로 하는 권리 이용 방법.
제1항에 있어서, 상기 권리 존재 확인 요청 메시지의 전송 단계는
상기 단말 내의 DRM 에이전트가 상기 제약 내의 상기 checkInterval 엘리먼트에 의하여 지정된 상기 시간 간격을 확인하는 단계와;
상기 단말 내의 DRM 에이전트가 상기 시간 간격의 확인에 따라 상기 권리 존재 확인 요청 메시지를 전송하는 단계를 포함하는 것을 특징으로 하는 권리 이용 방법.
제1항에 있어서,
상기 제약에 상기 checkInterval 엘리먼트가 없는 경우, 상기 권리 존재 확인을 TEK 요청과 동기화하여 수행하여야 하는 것으로 해석되는 것을 특징으로 하는 권리 이용 방법.
제1항에 있어서, 상기 권리 내의 정보는
권리 객체 암호화 키(REK)인 것을 특징으로 하는 권리 이용 방법.
제1항에 있어서, 상기 권리 존재 확인 요청 메시지는
권리 식별 정보와 임의 값을 포함하는 것을 특징으로 하는 권리 이용 방법.
제10항에 있어서, 상기 권리 식별 정보는
Handle인 것을 특징으로 하는 권리 이용 방법.
제10항에 있어서, 상기 권리 존재 확인 응답 메시지는
해쉬값을 포함하고, 상기 해쉬값은 상기 임의값과 상기 권리 내의 소정 정보 중 적어도 하나 이상에 대해 얻어지는 것을 특징으로 하는 권리 이용 방법.
제12항에 있어서, 상기 응답 메시지를 확인하는 단계는
상기 단말 내의 DRM 에이전트가 상기 임의 값과 상기 단말 내에 저장된 상기 권리 내의 정보 중 적어도 어느 하나 이상에 대한 해쉬값을 구하는 단계와;
상기 단말 내의 DRM 에이전트가 상기 구해진 해쉬값과 상기 권리 존재 확인 응답 메시지 내의 상기 해쉬값을 비교하는 단계를 포함하는 것을 특징으로 하는 권리 이용 방법.
제13항에 있어서,
상기 해쉬값들이 서로 일치하는 경우 상기 메모리 카드 내에 상기 권리가 존재하는 것으로 확인되고,
상기 해쉬값들이 서로 일치하지 않거나, 상기 권리 존재 확인 응답 메시지 내에 상기 해쉬값이 존재하지 않는 경우 상기 메모리 카드 내에 상기 권리가 존재하지 않는 것으로 확인되는 것을 특징으로 하는 권리 이용 방법.
메모리 카드에서 브로드캐스트 컨텐츠를 위한 권리를 단말에 제공하는 방법으로서,
상기 메모리 카드가 상기 단말로 상기 브로드캐스트 컨텐츠에 대한 권리를 제공하는 단계와, 여기서, 상기 권리 내에는 상기 메모리 카드의 장착 여부의 확인에 대한 제약이 포함되어 있고, 상기 제약은 synchronised 엘리먼트, syncThreshold 엘리먼트 및 checkInterval 엘리먼트 중 적어도 하나를 포함하고;
상기 메모리 카드가 상기 권리를 비활성화하는 단계와;
상기 단말로부터 권리 존재 확인 요청 메시지를 수신하는 단계와, 상기 권리 존재 확인 요청 메시지는 상기 권리에 대한 식별 정보와 임의 값을 포함하고;
상기 메모리 카드가 상기 권리가 존재하는지 확인하는 단계와;
상기 권리가 존재하는 것으로 확인되는 경우, 상기 임의 값과 상기 권리 내의 소정 정보 중 어느 하나 이상에 대한 해쉬값을 생성하는 단계와;
상기 해쉬값을 포함하는 권리 존재 확인 응답 메시지를 상기 단말로 전송하는 단계를 포함하되,
상기 synchronised 엘리먼트는 상기 권리의 존재 여부에 대한 확인이 TEK(Traffic Encryption Key) 요청과 동기화되어 수행되어야 함을 나타내고,
상기 syncThreshold 엘리먼트는 STKM(Short Term Key Messages)의 횟수를 나타내되, 상기 STKM의 횟수가 임계 값에 도달한 경우 상기 TEK 요청을 통하여 상기 권리의 존재 여부에 대한 확인이 수행될 수 있도록 하기 위한 것이고,
상기 checkInterval 엘리먼트는 상기 권리의 존재 여부에 대한 확인이 반복적으로 수행될 수 있도록 하기 위한 두 개의 연속적인 실행들 간의 시간 간격을 나타내는 것을 특징으로 하는 권리 제공 방법.
제15항에 있어서, 상기 제약은 srmPing (Secure Removable Media Ping) 엘리먼트 인 것을 특징으로 하는 권리 제공 방법.
삭제