KR101683111B1 - 메모리 카드를 대신하여 컨텐츠에 대한 권리 개체를 수신하는 방법 및 단말 - Google Patents

메모리 카드를 대신하여 컨텐츠에 대한 권리 개체를 수신하는 방법 및 단말 Download PDF

Info

Publication number
KR101683111B1
KR101683111B1 KR1020090105146A KR20090105146A KR101683111B1 KR 101683111 B1 KR101683111 B1 KR 101683111B1 KR 1020090105146 A KR1020090105146 A KR 1020090105146A KR 20090105146 A KR20090105146 A KR 20090105146A KR 101683111 B1 KR101683111 B1 KR 101683111B1
Authority
KR
South Korea
Prior art keywords
memory card
rights
srm
request message
terminal
Prior art date
Application number
KR1020090105146A
Other languages
English (en)
Other versions
KR20100088063A (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 엘지전자 주식회사
Priority to EP10735983.8A priority Critical patent/EP2382576B1/en
Priority to CN201080006116.6A priority patent/CN102301372B/zh
Priority to PCT/KR2010/000296 priority patent/WO2010087592A1/en
Priority to US12/696,039 priority patent/US8307457B2/en
Publication of KR20100088063A publication Critical patent/KR20100088063A/ko
Application granted granted Critical
Publication of KR101683111B1 publication Critical patent/KR101683111B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 명세서는 단말이 메모리 카드를 대신하여 권리 발급 서버로부터 권리 개체를 수신하는 방법을 제공한다. 상기 방법은 단말이 권리 발급 서버로부터 권리 개체 획득을 위한 트리거 메시지를 수신하는 단계와; 상기 단말이 상기 트리거 메시지 내에 포함된 트러스트 앵커 및 메모리 카드의 ID에 대한 리스트와, 상기 단말의 컨텍스트 내에 있는 트러스트 앵커 및 메모리 카드의 ID를 비교하는 단계와; 상기 비교의 결과 상기 컨텍스트 내에 있는 트러스트 앵커 및 메모리 카드의 ID가 상기 리스트 내의 것들과 일치하는 경우, 상기 서버로 권리 개체 요청 메시지를 전송하는 단계와; 상기 단말이 보호화된 권리 개체를 포함하는 권리 개체 응답 메시지를 상기 권리 발급 서버로부터 수신하는 단계를 포함할 수 있다.

Description

메모리 카드를 대신하여 컨텐츠에 대한 권리 개체를 수신하는 방법 및 단말{METHOD AND TERMINAL FOR RECEIVING RIGHTS OBJECT FOR CONTENT on behalf of MEMORY CARD}
본 발명은 디지털 저작권 관리에 관한 것으로서, 더욱 상세하게는 디지털 저작권 관리에서 메모리 카드에 사용권리를 안전하게 발급하는 방법에 관한 것이다.
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 컨텐츠를 복호화 및 사용할 수 없다.
따라서 일반적인 DRM 시스템에서 상기 사용권리 및 이와 연관된 DRM 콘텐트가 멀티미디어카드 등의 휴대용 메모리 카드(SRM(secure removable memory))에 저장된 경우, 상기 사용권리가 발급된 특정 단말 이외의 타 단말은 상기 메모리 카드(SRM)로부터 상기 DRM 컨텐츠를 읽어내어 사용할 수 없는 문제점이 있다. 즉, 사용권리는 특정한 단말에 종속되는 문제점이 있다.
또한, 일반적인 DRM 시스템에서 사용권리는 특정 단말에 발급되었으므로 메모리 카드(SRM)가 상기 사용권리 및 그의 DRM 컨텐츠를 저장한 경우, 상기 사용권리가 발급된 상기 특정 단말만이 상기 SRM으로부터 상기 DRM 컨텐츠 및 사용권리를 읽어내고 사용할 수 있기 때문에, SRM의 유용성을 저하시키는 단점이 있다.
그리고 일반적인 DRM 시스템에서 상기 사용권리 발급자(RI)(40) 상기 메모리 카드, 즉 SRM에 DRM 컨텐트에 대한 사용권리를 발급할 수 없기 때문에 상기 메모리 카드, 즉 SRM은 SRM 명의의 사용권리를 가질 수 없는 문제점이 있다.
그리고 일반적인 DRM 시스템에서 상기 사용권리 발급자(RI)(40)는 단말의 DRM 에이전트와 메모리 카드, 즉 SRM 사이에서 협상된 트러스트 앵커(Trust Anchor)를 알 수 없으며 또한 SRM의 ID를 알 수 없기 때문에 상기 메모리 카드, 즉 SRM은 SRM 명의의 사용권리를 가질 수 없는 문제점이 있다.
도 2는 종래 기술에 따른 문제점을 나타낸다.
도 2를 참조하여 알 수 있는 바와 같이, 컨텐츠 발급자(CI)(30)는 컨텐츠를 제1 단말(11) 에 발급한다. 그리고 사용권리 발급자(RI)(40)는 상기 컨텐츠에 대한 사용권리를 제1 단말(11) 에 발급한다. 상기 제1 단말(11)은 상기 사용권리를 추출하여 상기 메모리 카드, 즉, SRM(15)에 저장한다.
상기 제1 단말(11)의 사용자가 상기 메모리 카드, 즉 SRM(15)를 제2 단말(12)로 전달하더라도, 상기 사용권리는 상기 제1 단말(11)의 명의로 발급되었기 때문에, 상기 제2 단말(12)은 상기 사용권리를 이용할 수 없다.
따라서, 본 발명의 목적은 전술한 문제점들을 해결하는 데에 있다.
구체적으로, 본 발명의 목적은 사용권리를 단말을 통하여 메모리 카드, 즉 SRM으로 안전하게 발급하기 위한 세부적인 절차를 제시하는 데에 있다.
또한, 본 발명의 목적은 메모리 카드, 즉 SRM으로 발급된 사용권리를 호환성을 유지하여 다른 장치로 이동할 수 있도록 함에 있다.
또한, 본 발명의 다른 목적은 다수의 메모리 카드들 혹은 단말들이 존재할 때, 상호 인증 방안을 제공함에 있다.
또한, 본 발명의 다른 목적은 상기 인증을 제공하는 엔티티가 다수 존재하고, 상기 메모리 카드와 단말이 서로 다른 인증 엔티티를 지원할 때, 사용권리(RO)를 오류 없이 발급하는 방안을 제공함에 있다.
상기와 같은 목적을 달성하기 위하여 본 명세서는 단말이 메모리 카드를 대신하여 권리 발급 서버로부터 권리 개체를 수신하는 방법을 제공한다. 상기 방법은 단말이 권리 발급 서버로부터 권리 개체 획득을 위한 트리거 메시지를 수신하는 단계와; 상기 단말이 상기 트리거 메시지 내에 포함된 트러스트 앵커 및 메모리 카드의 ID에 대한 리스트와, 상기 단말의 컨텍스트 내에 있는 트러스트 앵커 및 메모리 카드의 ID를 비교하는 단계와; 상기 비교의 결과 상기 컨텍스트 내에 있는 트러스트 앵커 및 메모리 카드의 ID가 상기 리스트 내의 것들과 일치하는 경우, 상기 서 버로 권리 개체 요청 메시지를 전송하는 단계와; 상기 단말이 보호화된 권리 개체를 포함하는 권리 개체 응답 메시지를 상기 권리 발급 서버로부터 수신하는 단계를 포함할 수 있다.
상기 방법은 상기 비교전에 상기 트리거 메시지 내에 상기 트러스트 앵커 및 메모리 카드의 ID에 대한 리스트가 포함되어있는지 확인하는 단계를 더 포함할 수 있다. 여기서 상기 트리거 메시지 내에 상기 리스트가 포함되어 있는 경우, 상기 트리거 메시지가 상기 SRM을 위한 것으로 판단될 수 있다.
상기 방법은 상기 비교의 결과 상기 컨텍스트 내에 있는 트러스트 앵커 및 메모리 카드의 ID가 상기 리스트 내의 것들과 일치하지 않는 경우, 상기 리스트 내에 존재하고 상기 단말에 의해 지원되는 트러스트 앵커를 이용하여 상기 메모리 카드와 상호 인증 절차를 수행하는 단계를 더 포함할 수 있다.
상기 상호 인증 절차를 통해서 상기 리스트 내에 존재하고 상기 단말에 의해 지원되는 트러스트 앵커가 상기 메모리 카드에 의해서도 지원되는 것으로 확인되는 경우, 상기 권리 개체 요청 메시지를 전송하는 단계가 수행될 수 있다.
상기 상호 인증 절차는 상기 리스트 내에 존재하고 상기 단말에 의해 지원되는 트러스트 앵커에 대한 정보를 포함하는 인증 요청 메시지를 상기 메모리 카드로 전송하는 단계와; 상기 메모리 카드로부터 상기 트러스트 앵커의 지원 여부에 대한 정보를 포함하는 인증 응답 메시지를 수신하는 단계를 포함할 수 있다.
상기 보호화된 권리 개체는 상기 메모리 카드에 의해 지원되는 것으로 확인된 트러스트 앵커에 의한 상기 메모리 카드의 공개키로 암호화되어 있을 수 있다.
상기 권리 개체 요청 메시지 전송 단계는 상기 단말이 메모리 카드를 대신하여 권리 개체 요청 메시지를 생성하는 단계와; 상기 단말이 상기 권리 개체 요청 메시지를 포함하는 서명 질의 요청 메시지를 상기 메모리 카드로 전송하는 단계와; 상기 메모리 카드로부터 서명 질의 응답 메시지를 수신하는 단계와; 여기서 상기 서명 질의 응답 메시지는 상기 메모리 카드의 서명을 포함하고, 상기 메모리 카드의 서명을 포함하는 권리 개체 요청 메시지를 전송하는 단계를 포함할 수 있다.
상기 방법은 상기 보호화된 권리 개체를 파싱하는 단계를 더 포함할 수 있다. 여기서 상기 파싱 단계에서는 상기 권리 개체로부터 권리가 추출되고, 메모리 카드 저장하기 위한 포맷인 권리 정보(Rights Information)로 변환될 수 있다.
상기 방법은 상기 권리를 식별하기 위한 식별자를 생성하는 단계와; 상기 식별자, 상기 권리 정보의 크기 대한 정보를 포함하는 제공 설정 요청 메시지를 메모리 카드로 전송하는 단계와; 상기 메모리 카드로부터 상기 제공 설정의 상태를 포함하는 제공 설정 응답 메시지를 수신하는 단계와; 상기 상태가 성공이면, 상기 권리 정보를 상기 메모리 카드에 설치하기 위하여, 상기 권리 정보를 포함하는 권리 제공 요청 메시지를 상기 메모리 카드에 전송하는 단계를 더 포함할 수 있다.
한편, 상기와 같은 목적을 달성하기 위하여, 본 명세서는 메모리 카드를 대신하여 권리 개체를 수신하는 단말을 제공한다. 상기 단말은 권리 발급 서버로부터 권리 개체 획득을 위한 트리거 메시지를 수신하는 송수신부와; 상기 트리거 메시지 내에 포함된 트러스트 앵커 및 메모리 카드의 ID에 대한 리스트와, 상기 단말의 컨텍스트 내에 있는 트러스트 앵커 및 메모리 카드의 ID를 비교하고, 상기 비교의 결 과 상기 컨텍스트 내에 있는 트러스트 앵커 및 메모리 카드의 ID가 상기 리스트 내의 것들과 일치하는 경우, 상기 서버로 권리 개체 요청 메시지를 전송하고, 보호화된 권리 개체를 포함하는 권리 개체 응답 메시지를 상기 권리 발급 서버로부터 수신하도록 상기 송수신부를 제어하는 프로세서를 포함한다.
본 발명은 사용권리 발급자(RI)가 사용권리를 메모리 카드, 즉 SRM에 안전하게 발급할 수 있도록 한다. 또한, 상기 SRM에 저장된 사용권리(RO)를 사용자가 희망하는 어떠한 단말에서도 올바르게 사용될 수 있도록 한다.
또한, 본 발명은 인증을 제공하는 엔티티가 다수 존재하고 하고, 상기 메모리 카드와 단말이 서로 다른 인증 엔티티를 지원할 때, 사용권리(RO)를 오류없이 발급할 수 있도록 한다.
본 발명은 디지털 저작권 관리(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) 권리 발급자(Rights Issuer: RI): DRM 컨텐츠에 대한 권리 객체를 발급하는 엔티티이다.
5) 허가권(Permission): 권리 발급자(Rights Issuer: RI)에 의해 허용된 DRM 컨텐츠에 대한 실제 사용의 허가
6) 권리(Rights): DRM 컨텐츠에 부여된 허가권 및 제약 의미한다. 상기 권리는 관련 상태에 대한 정보 및 다른 정보와 함께 권리 객체를 이룬다.
상기 권리(Rights) = 권리정보(Rights Information) + 권리 객체 암호화 키(REK) 일 수 있다.
7) 권리 객체(Rights Object)
권리 객체는 사용 권리로도 불리며, DRM 컨텐츠에 대한 허가권(또는, 제약)들과 상기 컨텐츠에 연결된 다른 속성들을 포함한다.
상기 권리 객체는 일반적으로 단말 내에 저장되나, 본 발명의 실시예에 따르면 메모리 카드, 예컨대 SRM 에 저장될 수 있다. 이때, 상기 권리 개체는 권리 객 체 컨테이너(Rights Object Container)의 형태로 저장될 수 있다.
상기 SRM의 에이전트는 상기 권리 객체 컨테이너를 불투명한 개체(opaque object)로 다룬다. 즉, 상기 SRM 에이전트는 상기 권리 개체 컨테이너를 파싱하지 않는다.
상기 권리 객체(Rights) = 권리정보(Rights Information)의 일부 (상태 정보를 포함하고 있지 않음. 그 외 값은 모두 포함) + 권리 객체 암호화 키(REK)와 같이 구성될 수 있다..
8) 권리 정보(Rights Information)
권리 정보는 상기 권리 메타 데이터, 권리 객체 컨테이너, 상기 상태 정보를 포함한다.
권리 정보 (Rights Information) = (권리 객체(Rights Object - 권리객체 암호화 키(REK)) + 상태 정보(State Information) = 권리(Rights) ? 권리객체 암호화 키(REK)를 의미한다.
9) 권리 메타 데이터(Rights Meta Data):
권리 메타 데이터(Rights Meta Data)는 권리 객체 버전(Rights Object Version), 권리 객체의 별명(RO Alias), 사용권리 발급자의 식별자(RI Identifier), 사용권리 발급자의 주소(RI URL), 사용권리 발급자의 별명(RI Alias), 사용권리 발급자의 타임 스탬프(RI Time Stamp)를 포함한다.
10) 상태 정보(State Information)
상태 정보는 stateful 사용 권리 내에 있는 각각의 stateful 허가권의 현재 상태(예컨대, 잔여 카운트, 시작일 간격(interval start date)를 뜻한다. 상기 사용권리가 stateful 사용권리 라면, 상기 상태 정보는 권리(Rights) 내에 포함된다.
11) AssetID
Asset Identifier의 약자로서 권리 개체(RO)내에 포함되고, DRM 컨텐츠를 식별하는데에 이용된다.
12) REK
REK는 권리 객체 암호화 키(Rights Object Encryption Key)로서, 바이너리 형태를 가지며, no base64 encoding이다.
13) Handle
Handle은 DRM 에이전트에 의해서 생성되는 랜덤 넘버로서, 상기 DRM 에이전트가 메모리 카드, 예컨대 SRM 내에 저장된 사용권리(또는 권리 객체(RO))를 식별하기 위해서 사용된다. 상기 Handle은 상기 DRM 에이전트가 상기 SRM 내의 사용권리를 사용하거나 혹은 이동하기 위해서 액세스할 때, 상기 사용권리(또는 권리 객체(RO))를 식별하기 위해서 사용된다. 상기 Handle은 상기 SRM 내에 저장되며, 또한 단말의 동작 로그(Operation Log)에 저장된다.
상기 DRM 에이전트는 상기 사용권리(또는 권리 객체(RO))를 이용하거나 또는 이동하기 위한 메시지를 전송할 때, 상기 Handle을 생성하고, 상기 생성된 Handle을 상기 SRM에 전송한다.
14) Secure Authenticated Channel (SAC): 송수신되는 메시지의 무결성 및 신뢰성을 보증하기 위한 논리 채널이다.
15) 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를 참조하여 상세하게 후술하기로 한다.
16) 트러스트 앵커(Trust Anchor: TA라고도 함)
트러스트 앵커는 DRM 시스템 내에 존재하는 특정 장치 혹은 특정 정보에 대한 무결성 및 신뢰성을 보장하는 엔티티 혹은 장치이다. 서로 신뢰되는 여러 엔티티가 체인 형태로 존재할 때, 가장 상위에 존재하는 엔티티가 트러스트 앵커가 된다. 상기 트러스트 앵커의 공개키는 디지털 서명과 관련 데이터를 검증하는데에 이용된다.
상기 트러스트 앵커를 신뢰하는 자는 어떤 오브젝트에 포함된 전자 서명을 상기 트러스트 앵커에 의해 발급된 공개키를 이용하여 검증함으로써, 유효한 것인지 확인할 수 있다.
16) 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를 지시함
상기 보호화된 RO(protected RO)는 DRM 버전 2.0에 따른 형태이다. 상기 보호화된 RO는 상기 RI로부터 단말로 제공될 때 사용되는 포맷이다. 또한, 상기 보호화된 RO는 상기 단말의 DRM 에이저트로부터 상기 메모리 카드, 예컨대 SRM의 SRM 에이전트로 전달될 때 사용되는 포맷이다.
상기 보호화된 권리 개체는 아래의 표와 같이 일련의 권리 객체, 즉 <RO> 엘리먼트와 MAC 값을 포함하는 <mac> 엘리먼트를 포함한다. 상기 <mac> 엘리먼트는 상기 <ro> 엘리먼트의 무결성과, 키 확인을 위해 사용된다.
<element name="protectedRO" type="roap:ProtectedRO" form="qualified"/>
<complexType name="ProtectedRO">
<sequence>
<element name="ro" type="roap:ROPayload" form="qualified"/>
<element name="mac" type="ds:SignatureType"/>
</sequence>
</complexType>
상기 표에 나타난 바와 같이, <ro> 엘리먼트는 ROPayload 항목을 포함한다. 상기 ROPayload 항목은 보호화된 권리와 보호된 키들(wrapped keys)을 포함한다. 상기 보호된 키들은 상기 권리 내에 암호화되어 있는 부분을 복호(decrypt)하는데 이용된다. 상기 ROPayload 항목은 다음이 표와 같은 내용을 포함한다.
<!-- Rights Object Definitions -->
<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에 포함된다.
<element name="roPayloadAliases">
<complexType>
<sequence>
<element name="roAlias" type="roap:String80" minOccurs="0"/>
<element name="domainAlias" type="roap:String80" minOccurs="0"/>
<element name="riAlias" type="roap:String80"/>
<any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
한편, Nonce 항목은 ROAP 프로토콜 메시지 내의 임의 값을 포함한다. 상기 Nonce 항목은 이름 그대로 단 한번만 사용되어야 한다. 즉, ROAP 메시지가 생성될 때마다, 상기 Nonce의 임의 값이 생성된다.
<simpleType name="Nonce">
<restriction base="base64Binary">
<minLength value="14"/>
</restriction>
</simpleType>
본 명세서에서 제안되는 방안의 개념에 대한 설명
본 발명에서는 종래의 DRM v2.1에서 정의된 ROAP Trigger를 확장한 새로운 Trigger에 포함된 정보를 통해서 RI가 지원하는 Trust Model을 DRM Agent와 SRM Agent간 SAC session을 위해 협의된 Trust Model과 일치시킴으로써 RI, DRM Agent, SRM Agent간 동일한 Trust Model하에서 SRM-ID를 정확히 인식할 수 있는 방법을 제공한다. 또한 본 발명에서는 RI와 DRM Agent간 ROAP interface에서는 ROAP Trigger를 확장하게 되며, DRM Agent와 SRM 1.1간 interface에서는 Direct Provisioning of Rights to the SRM procedure를 위한 프로토콜이 새롭게 정의된다.
SRM은 여러 Trust Model을 지원할 수 있기 때문에 DRM Agent와 SRM Agent 사이에 SAC(Secure Authenticated Channel) session을 위해서 협의된 Trust Model과 RI가 지원하는 Trust Model을 일치시켜야만 RI, DRM Agent, SRM Agent가 동일한 Trust Model하에서 암. 복호화 및 entity ID의 인식이 가능해 진다.
또한 DRM Agent가 RI로부터 ROAP Trigger를 수신하고 RI와 SRM 간 Trust Model을 동일하게 설정함으로써 Device에 삽입된 SRM을 정확히 인식함으로써 Direct Provisioning of Rights to the SRM procedure가 오류 없이 진행될 수 있다.
이하에서는, 본 발명에 따른 실시 예를 첨부한 도면을 참조하여 상세히 설명하기로 한다.
도 3는 본 발명에 따라 컨텐츠 및 사용권리를 메모리 카드에 발급하는 개념을 나타낸다.
도 3를 참조하여 알 수 있는 바와 같이, 컨텐츠 발급자(CI)(300)는 컨텐츠를 제1 단말(110)을 통하여, 메모리 카드, 즉 SRM(150)에 발급한다. 그리고 사용권리 발급자(RI)(400)는 상기 컨텐츠에 대한 사용권리(RO)를 제1 단말(110)을 통하여, 메모리 카드, 즉 SRM(150)에 발급한다. 이때, 상기 사용권리(RO)는 상기 메모리 카드, 즉 SRM(150)의 명의로 발급된다. 상기 제1 및 제2 단말(110, 120)(이하, 부호 100으로 칭하기로 한다)은 DRM 에이전트를 포함한다. 그리고 상기 SRM(150)은 SRM 에이전트를 포함한다.
따라서, 상기 제1 단말(110)의 사용자가 상기 메모리 카드, 즉 SRM(150)를 제2 단말(120)로 전달할 경우, 상기 제2 단말(120)은 적법하게 상기 컨텐츠를 사용할 수 있다.
이때, 상기 제1 단말(110)의 DRM 에이전트와 상기 SRM(150)의 SRM 에이전트 간에는 본 발명에 따라 새로운 프로토콜이 정의된다. 즉, 상기 제1 단말(110)의 DRM 에이전트와 상기 SRM(150)의 SRM 에이전트 간에는 상기 SRM 에이전트 명의로 권리 객체(RO)를 발급하는 데에 필요한 서명 질의 프로토콜(Signature Query protocol)과 상기 SRM 명의로 발급되는 권리 객체(RO)를 상기 DRM 에이전트에서 상기 SRM 에이전트로 제공하기 위한 프로비저닝 설정 프로토콜(Provisioning Setup protocol)과 권리 프로비저닝 프로토콜(Rights Provisioning protocol)이 제시된다.
이하, 도 4내지 도 8을 참조하여, 본 발명의 실시 예들을 설명하기로 한다.
도 4는 본 발명의 개념을 개략적으로 나타낸 흐름도이다.
본 발명은 크게 DRM 에이전트와 SRM 에이전트 간에 상호 인식 및 인증 절차(S10)와, 트러스트 모델 협상 과정(S30 또는 S60)과, 사용권리(RO) 획득 과정(S50)과, DRM 에이전트가 사용권리 발급자(RI)(400)로부터 수신한 사용권리를 전달하기 위한 준비를 수행하는 과정(S70)과, SRM 에이전트에게 사용권리를 제공하는 과정(S80)을 포함한다.
상기 상호 인식 및 인증 절차(S10)는 SRM이 단말에 장착되면 개시될 수 있다. 상기 상호 인식 및 인증 절차(S10)를 통해서 상기 DRM 에이전트와 상기 SRM 에이전트 간에는 상호 인식 및 인증되고, 트러스트 모델(Trust Model), 엔티티 ID(entity ID), 보안 알고리즘(security algorithm) 등이 협상된다.
상기 트러스트 모델 협상 과정(S30 또는 S60)은 상기 사용권리 발급자(400)로부터 트리거 메시지를 수신하였을 때(S20), 혹은 사용권리(RO)를 획득하였을 때(S50), 상기 사용권리 발급자(RI)(400)와 트러스트 앵커를 협상하는 과정이다(S30 또는 S60). 이때, 상기 트러스트 모델 협상 과정(S30 또는 S60)에서 협상된 트러스트 앵커가 상기 HELLO 및 MAKE 절차(S10)에서 상기 DRM 에이전트와 상기 SRM 에이전트 간에 협상된 트러스트 앵커와 다르다면, 상기 HELLO 및 MAKE 절차가 다시 한번 수행될 수 있다(S10’).
상기 사용권리(RO) 획득 과정(S50)에서는 상기 사용권리 발급자(RI)(400)가 상기 SRM 명의로 사용권리를 발급할 때, 보호화된 권리 개체(protected RO)로 상기 DRM 에이전트에게 제공함으로써, 상기 권리 개체 내의 중요 정보들, 예컨대 REK, CEK와 같은 정보들이 상기 단말(100) 또는 외부에 유출되지 않도록 한다.
상기 RO 제공 준비 과정(S70)에서는 상기 DRM 에이전트는 상기 SRM에 설치되는 권리들을 구분하게 하는 Handle과 암호화된 정보들을 상기 SRM 에이전트로 제공하여 설치 준비를 한다.
상기 RO 제공 준비가 완료되면, 상기 DRM 에이전트는 상기 SRM 에이전트로 사용권리를 제공한다(S80)
도 5는 도 4에 도시된 상호 인식 및 인증 절차를 상세하게 나타낸 흐름도이다.
도 5를 참조하여 알 수 있는 바와 같이, 상기 상호 인식 및 인증 절차는 Hello 절차(S11)와 MAKE 절차(S15)를 포함한다.
먼저, 상기 Hello 절차(S11)를 설명하면 다음과 같다.
상기 DRM 에이전트는 자신이 지원하는 SRM 버전 정보, 트러스트 앵커 그리고 단말(디바이스) ID 쌍에 대한 정보가 담긴 리스트를 포함하는 SRM Hello Request 메시지를 상기 SRM 에이전트로 전송한다.
상기 SRM 에이전트는 상기 SRM Hello Request 메시지를 수신하면, 상기 메시지 내의 SRM 버전 정보를 자신의 버전과 비교하고, 적절한 버전을 선택한다. 그리고, SRM Hello Response 메시지를 상기 DRM 에이전트로 전송한다. 이때, 상기 SRM Hello Response 메시지에는 상기 SRM 에이전트가 지원하는 트러스트 앵커 및 SRM ID 쌍에 대한 정보가 담긴 리스트가 포함된다. 또한, 상기 SRM Hello Response 메시지에는 상기 SRM 에이전트가 인증서 정보의 검증이 완료된 단말 ID 리스트가 포함될 수 있다. 또한, 상기 SRM Hello Response 메시지에는 상기 SRM 에이전트가 지원하는 H(AssetID)의 최대 수, 추가적인 메시지의 지원 여부에 대한 정보가 포함될 수 있다.
상기 추가적인 메시지의 지원 여부에 대한 정보는 다음과 같은 형태로 상기 SRM Hello Response 메시지에 포함될 수 있다.
파라미터 설명
ocspSupported 만약 ‘0’이면, OCSP Nonce와 OCSP Process 메시지는 SRM 에이전트에서 지원되지 않음을 나타낸다. 만약 ‘1’이면, OCSP Nonce와 OCSP Process 메시지는 SRM 에이전트에서 지원됨을 나타낸다.
rightsInfoListSupported 만약 ‘0’이면, Rights Info List Query 메시지는 SRM 에이전트에서 지원되지 않음을 나타낸다. 만약 ‘1’이면, Rights Info List Query 메시지는 SRM 에이전트에서 지원됨을 나타낸다.
riCertificateStorageSupported 만약 ‘0’이면, RI Certificate Store 와 RI Certificate Query 메시지는 SRM 에이전트에서 지원되지 않음을 나타낸다. 만약 ‘1’이면, RI Certificate Store 와 RI Certificate Query 메시지는 SRM 에이전트에서 지원됨을 나타낸다.
riCertificateRemovalSupported 만약 ‘0’이면, RI Certificate Removal 메시지는 SRM 에이전트에서 지원되지 않음을 나타낸다. 만약 ‘1’이면, RI Certificate Removal 메시지는 SRM 에이전트에서 지원됨을 나타낸다.
dynamicCodePageSupported 만약 ‘0’이면, Dynamic Code Page Query 와 Dynamic Code Page Update 메시지는 SRM 에이전트에서 지원되지 않음을 나타낸다. 만약 ‘1’이면, Dynamic Code Page Query 와 Dynamic Code Page Update 메시지는 SRM 에이전트에서 지원됨을 나타낸다.
changeSacSupported 만약 ‘0’이면, ChangeSac 메시지는 SRM 에이전트에서 지원되지 않음을 나타낸다. 만약 ‘1’이면, ChangeSac 메시지는 SRM 에이전트에서 지원됨을 나타낸다.
2) 상기 MAKE 절차(S15)를 설명하면 다음과 같다.
먼저, 상기 DRM 에이전트는 상기 SRM 에이전트가 지원하는 트러스트 앵커의 리스트 중에서 상기 DRM 에이전트가 지원하는 트러스트 앵커를 하나 선택하여 인증 요청 메시지(Authentication Request 메시지)를 상기 SRM 에이전트로 전송한다. 상기 인증 요청 메시지는 상기 단말(100)의 인증서 체인(Certificate Chains), 인증서 정보가 검증 완료된 SRM ID(Peer Key ID)와 상기 DRM 에이전트에 의해서 지원되는 암호 알고리즘 정보(즉, hash 알고리즘, MAC 알고리즘, 서명 알고리즘, 공개키 암호 알고리즘, 대칭 암호 알고리즘, 키 유도 알고리즘)을 포함한다.
그러면, 상기 SRM 에이전트는 상기 인증 요청 메시지를 수신하면, 상기 DRM 에이전트가 선택한 트러스트 앵커를 확인한다 그리고, 상기 SRM 에이전트는 상기 인증 요청 메시지에 DRM 에이전트의 인증서가 포함되어 있을 경우, 상기 DRM 에이전트의 인증서를 저장한다. 그리고, 상기 SRM 에이전트는 상기 인증 요청 메시지 내의 지원 알고리즘 정보 중에서 자신이 지원하는 알고리즘을 선택한다. 그리고 상기 SRM 에이전트는 SAC에서 사용될 키 정보를 위해 임의 값(RNS, Random Number from SRM) 생성한다.
그리고 상기 SRM 에이전트는 인증 응답 메시지(Authentication Response 메시지)를 상기 DRM 에이전트로 전송한다. 상기 인증 응답 메시지는 상기 SRM의 인증서를 포함할 수 있다. 그러나, 상기 수신했던 인증 요청 메시지에 Peer Key ID가 포함되어 있을 경우 상기 SRM의 인증서는 상기 인증 응답 메시지에 포함되지 않을 수도 있다. 상기 인증 응답 메시지에는 상기 생성된 임의 값(RNS) 정보와, 버전, 선택된 알고리즘, 지원되는 알고리즘이 포함된다. 이와 같은 정보들은 상기 DRM 에이전트의 공개키로 암호화되어 포함될 수 있다. 또한, 상기 인증 응답 메시지는 상기 수신했던 인증 요청 메시지를 처리한 결과(Status)를 포함할 수 있다.
상기 인증 응답 메시지를 수신하면, 상기 DRM 에이전트는 상기 인증 응답 메시지 내에 포함된 정보들을 자신의 개인키로 복호화한다. 그리고, DRM 에이전트는 상기 복호된 정보들 확인한다. 그리고 상기 DRM 에이전트는 SAC에서 사용될 키 정보를 위해 임의값(RND, Random Number from Device)를 생성한다.
그리고 상기 DRM 에이전트는 키 교환 요청 메시지(Key Exchange Request 메시지)를 상기 SRM 에이전트로 전송한다. 상기 키 교환 요청 메시지는 상기 생성한 임의값(RND)와, 선택된 버전(Selected Version) 정보 등을 포함한다. 상기 정보들은 상기 SRM 에이전트의 공개키로 암호화되어 포함될 수 있다.
상기 키 교환 요청 메시지를 수신하면, 상기 SRM 에이전트는 메시지 내의 정보들을 자신의 개인키로 복호화한다. 그리고 상기 SRM 에이전트는 상기 DRM 에이전트가 생성한 임의 값 (RND)를 확인하고 SAC에서 사용될 MAC 키와 세션 키를 유도하기 위한 정보를 확인한다. 상기 MAC 키와 상기 세션 키의 유도를 위해서는 KDF(Key Derivation Function), Z = RND | RNS, otherInfo = Supported Algorithms | Selected Algorithms과 kLen (36 (bytes)) 정보가 필요하다.
또한 상기 SRM 에이전트는 자신이 생성해서 상기 DRM 에이전트로 전송했던 임의 값(RNS)과 상기 수신한 임의 값(RND)의 해쉬 값을 비교해서, 상기 임의 값의 전송이 성공적으로 이루어졌는지 그리고 상기 DRM 에이전트가 충분히 신뢰할 수 있는 엔티티인지를 확인한다.
이어서, 상기 SRM 에이전트는 키 교환 응답 메시지(Key Exchange Response 메시지)를 상기 DRM 에이전트로 전송한다. 상기 키 교환 응답 메시지는 상기 수신했던 키 교환 요청 메시지를 처리한 결과(Status)와 상기 SRM 에이전트의 임의값(RNS) 및 상기 DRM 에이전트의 임의값(RND)에 대한 해쉬값, 즉 Hash (RND | RNS)값을 포함한다.
상기 DRM 에이전트는 상기 키 교환 응답 메시지를 수신하면, 상기 키 교환 요청 메시지에 대한 상기 SRM 에이전트의 처리 결과를 확인한다. 그리고 상기 키 교환 응답 메시지 내에 포함된 상기 SRM 에이전트의 임의값(RNS) 및 상기 DRM 에이전트의 임의값(RND)에 대한 해쉬값, 즉 Hash (RND | RNS) 값을 이전에 전송했던 상기 DRM 에이전트의 임의값(RND)과 상기 이전에 수신했던 상기 SRM 에이전트의 임의값(RNS)과 비교하여, 상기 임의 값이 올바른지 확인한다.
이상과 같이 상기 MAKE 절차가 완료되면, SAC 설정을 위한 정보가 포함된SAC 컨텍스트가 상기 DRM 에이전트 및 상기 SRM 에이전트 내에 생성된다. 상기 SAC 컨텍스트는 표 1과 같은 정보들을 포함한다.
도 6는 본 발명의 제1 실시예에 따른 방법을 나타낸 흐름도이다.
도 6에 도시된 바와 같이, 제1 실시 예에 따른 방법은 사용권리 발급자(RI)400)가 상기 단말(100)을 통하여 상기 SRM(150)으로 권리 개체(RO)(또는 사용권리)를 발급하려고 할 때, 상기 사용권리 발급자(RI)(400)가 상기 SRM(150)의 서명을 확인함으로써, 상기 SRM을 인증한다. 또한, 본 발명의 제1 실시 예는 상기 사용권리 발급자(RI)(400)가 상기 SRM 명의로 사용권리를 발급할 때, 보호화된 권리 개체(protected RO)로 상기 단말(100)에게 제공함으로써, 상기 권리 개체 내의 중요 정보들, 예컨대 REK, CEK와 같은 정보들이 상기 단말(100) 또는 외부에 유출되지 않도록 한다.
구체적으로 설명하면 다음과 같다.
1) 먼저, 상기 DRM 에이전트와 상기 SRM 에이전트는 상호 인식 및 인증을 수행하기 위해, 전술한 SRM Hello 절차와 MAKE 절차를 수행한다(S110).
구체적으로, 상기 DRM 에이전트와 상기 SRM 에이전트는 전술한 바와 같이, 상기 SRM Hello Request 메시지 및 Response 메시지를 통해서 서로 지원하는 버전, 트러스트 앵커 및 ID 쌍에 대한 리스트 및 SRM의 Key ID List, Max Number Of AssetIDs, 추가 메시지 지원 여부 등에 대해서 협상을 마친다.
2) 이후, 상기 사용권리 발급자(RI)(400)는 상기 SRM 명의의 권리 개체(Rights Object)를 제공하기 위해서, 트리거 메시지, 예컨대 권리 개체 획득을 위한 트리거 메시지, 또는 ROAP(Rights Object Acquisition Message) Trigger 메시지를 상기 SRM이 장착된 상기 단말(100)로 전송한다(S120). 상기 트리거 메시지는 상기 사용권리 발급자(RI)(400)가 상기 SRM(100)의 사용자로부터 웹 브라우징과 같은 방식을 통해 특정 컨텐츠에 대한 권리 객체(RO)(또는 사용권리)의 전달을 요청할 때 전송될 수 있다. 이와 같은 상기 전달 요청 시, 상기 SRM(150)에 대한 정보 예컨대 SRM ID, IMSI와, 상기 SRM(150)이 장착되어 있는 단말(100)에 대한 정보, 예컨대 Device ID가 상기 사용권리 발급자(RI)로 전달될 수 있다.
상기 트리거 메시지는 다음과 같은 형태로 이루어질 수 있다.
<complexType name="ExtendedROAcquisitionTrigger">
<complexContent>
<extension base="roap: BasicRoapTrigger">
<sequence>
<element name="domainID" type="roap:DomainIdentifier" minOccurs="0"/>
<element name="domainAlias" type="string" minOccurs="0"/>
<sequence maxOccurs="unbounded">
<element name="roID" type="ID"/>
<element name="roAlias" type="roap:String80" minOccurs="0"/>
<element name="contentID" type="anyURI" minOccurs="0" maxOccurs="unbounded"/>
<element name="trustAnchorAndsrmIDPair" type=”roap:trustAnchorAndsrmIdentifierPairType” minOccurs="0” maxOccurs="unbounded">
</sequence>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="trustAnchorAndsrmIdentifierPairType">
<sequence>
<element name="trustAnchor" type="roap:Identifier"/>
<element name="srmID" type="roap:Identifier"/>
</sequence>
</complexType>
상기 trustAnchorAndsrmIDPair 엘리먼트는 trustAnchor 엘리먼트와 srmID 엘리먼트의 쌍을 포함한다.
상기 <trustAnchorAndsrmIDPair> 엘리먼트는 사용권리(RO)가 설치된 SRM을 식별할 수 있게 하는 정보를 포함한다.
한편, 상기 전달 요청을 수신하면 상기 사용권리 발급자(RI)(400)는 상기 특정 컨텐츠에 대한 권리 객체(RO)(또는 사용권리)를 생성할 수도 있다. 또는 상기 권리 개체(RO)의 생성은 추후 상기 단말(100)로부터 권리 개체 요청 메시지를 수신한 후에 수행될 수도 있다.
3) 상기 트리거 메시지를 수신하면, 상기 DRM 에이전트는, 상기 ROAP Trigger 메시지가 자신을 위한 것인지 상기 SRM(150)을 위한 것인지를 판단한다.
그리고 상기 DRM 에이전트는 트러스트 모델을 협상한다(S130). 그리고 상기 DRM 에이전트는 선택적으로 SRM Hello 과정과 MAKE 과정을 수행한다. 이 과정은 도 7을 참조하여 후술하기로 한다.
4) 상기 DRM 에이전트는 사용권리(RO)를 사용권리 발급자(RI)에 요청하기 전에 SRM의 서명을 획득한다(S140). 구체적으로 설명하면 다음과 같다.
상기 단말(100)의 DRM 에이전트는 SRM을 대신하여 사용권리(RO)를 사용권리 발급자(RI)에 요청하기 위해 권리 개체 요청 메시지를 생성한다(S141). 이때, 상기 DRM 에이전트는 상기 권리 개체 요청 메시지를 생성할 때, 서명 부분을 제외하여 생성한다. 상기 권리 개체 요청 메시지는 상기 단말의 ID 대신 상기 SRM의 ID가 포함된다. 또한, 상기 권리 개체 요청 메시지는 상기 사용권리 발급자의 ID, Device Nonce, 요청 시간, RO Information, Extension 파라미터를 포함한다. 상기 Extension 파라미터는 협의된 트러스트 앵커(상기 SAC 컨텍스트에 저장된 트러스트 앵커)에 대한 정보를 포함한다. Extension에 포함된 트러스트 앵커를 통해서 RI는 SRM의 트러스트 앵커와 SRM-ID를 알 수 있으며 해당 트러스트 앵커에 맞게 RSA-Encryption이 가능하며 SRM을 위한 protected RO를 생성할 수 있다.
그리고, 상기 DRM 에이전트는 상기 생성한 권리 개체 요청 메시지를 상기 SRM 에이전트로 전송하면서, 서명 요청을 한다(S142). 상기 서명 요청은 서명 질의 요청 메시지, 예컨대 Signature Query Request 메시지 또는 서명 요청 메시지, 예컨대 Signing Request 메시지의 전송을 통해서 달성된다. 상기 서명 질의 요청 메시지 또는 서명 요청 메시지는 상기 서명이 없는 권리 개체 요청 메시지를 포함할 수 있다. 상기 서명 질의 요청 메시지는 아래의 표와 같은 항목들을 포함한다.
필드 설명
RO Request 권리 개체 요청 메시지
Signature Scheme 상기 RI(400)와 상기 단말간에 협상된 서명 알고리즘
한편 상기 서명 질의 요청 메시지 또는 서명 요청 메시지 내에 포함되는 상기 권리 개체 요청 메시지는 무결성이 요구된다. 이를 위해 상기 권리 개체 요청 메시지는 HMAC 값을 포함한다. 상기 HMAC 값은 상기 권리 개체 요청 메시지가 DRM 에이전트로부터 SRM 에이전트까지 전송되는 동안 변경되지 않았음을 보증한다. 상기 HMAC 값은 상기 DRM 에이전트와 상기 SRM 에이전트 간에 협상된 HMAC 알고리즘을 사용하여, 생성된다. 상기 HMAC 알고리즘은 HMAC-SHA1-128을 사용하게 된다.
상기 서명 질의 요청 메시지 또는 서명 요청 메시지를 수신하면, 상기 SRM 에이전트는 상기 권리 개체 요청 메시지에 대한 무결성 검증을 수행한 후,상기 서명 질의 요청에 대한 서명 조회 응답 메시지, 예컨대 Signature Query Response 메시지 또는 서명 응답 메시지, 예컨대 Signing Response 메시지를 상기 DRM 에이전트로 전송한다(S144). 상기 서명 조회 응답 메시지 또는 상기 서명 응답 메시지는 상기 서명을 포함하는 권리 개체 요청 메시지를 포함한다. 즉, 상기 SRM 에이전트는 자신이 권리 객체(RO)를 상기 사용권리 발급자(400)에게 요청한다는 의미로 자신의 서명을 상기 권리 개체 요청 메시지에 포함시키고, 다시 상기 서명이 포함된 상기 권리 개체 요청 메시지를 상기 서명 조회 응답 메시지 또는 상기 서명 응답 메시지에 캡슐화해서 전송한다. 대안적으로, 상기 서명 조회 응답 메시지 또는 서명 응답 메시지는 상기 서명 값만을 포함한다.
상기 서명 질의 응답 메시지는 아래의 표와 같은 항목들을 포함한다.
필드 설명
Status 상기 Signature Query Request 메시지의 처리 결과
이 status 필드는 상기 처리 결과가 에러인 경우에 만 포함될 수도 있다.
Signature of RO Request 상기 SRM의 디지털 서명, SRM의 개인키(private key)를 사용해야 생성된 RO Request 메시지에 대한 서명 값.
상기 status 필드는 아래의 표에 나타난 같은 값들을 포함할 수 있다.
상태값 설명
Success 성공
Signature Scheme Not Supported 서명 알고리즘이 상기 SRM 에이전트에 의해서 지원되지 않음
Parameter Failed 필드의 길이 또는 구조가 부정확함
Unexpected Request 순서에 맞지 않는 메시지를 수신하였거나 허용되지 않은 메시지가 수신되었음
Unknown Error 기타의 에러
상기 서명을 포함하는 권리 개체 요청 메시지 또는 상기 디지털 서명은 무결성이 요구된다. 이를 위해 상기 권리 개체 요청 메시지 또는 상기 디지털 서명은 HMAC 값을 포함한다, 상기 HMAC 값은 상기 권리 개체 요청 메시지 또는 상기 디지털 서명이 전송되는 동안 변경되지 않았음을 보증한다. 상기 HMAC 값은 상기 DRM 에이전트와 상기 SRM 에이전트 간에 협상된 HMAC 알고리즘을 사용하여, 생성된다. 상기 HMAC 알고리즘은 HMAC-SHA1-128을 사용하게 된다.
5) 상기 SRM 에이전트로부터 상기 서명 조회 응답 메시지 또는 서명 응답 메시지를 수신하면, 상기 DRM 에이전트는 사용권리(RO) 획득 절차들을 수행한다(S150). 구체적으로 설명하면 다음과 같다.
상기 DRM 에이전트는 상기 SRM의 서명이 포함된 권리 개체 요청 메시지를 상기 사용권리 발급자(RI)(400)에 전송한다(S151).
상기 사용권리 발급자(RI)(400)는 권리 개체 응답 메시지, 예컨대 RO Response 메시지를 생성한다(S152). 상기 사용권리 발급자(RI)(400)는 상기 권리 개체 요청 메시지의 Extension 파라미터에 포함된 트러스트 앵커에 대한 정보를 통해서 상기 SRM을 위한 트러스트 앵커를 확인한다.
이어서 상기 사용권리 발급자(RI)(400)는 상기 권리 개체 응답 메시지, 예컨대 RO Response 메시지 상기 DRM 에이전트로 전송한다(S153). 이때, 상기 사용권리 발급자(RI)(400)는 이전에 생성했던 또는 현재 생성한 권리 개체(RO)를 보호화된 권리 개체(protected RO) 형태로 상기 권리 개체 응답 메시지에 포함시킨다. 이때, 상기 사용권리 발급자(RI)(400)는 상기 SRM을 위한 보호화된 권리 개체(protected RO)를 생성할 때, 상기 확인된 SRM을 위한 트러스트 앵커를 따르는 상기 SRM(150)의 공개 키(public key)로 K_MAC과 K_REK를 암호화 한다.
상기 권리 개체 응답 메시지에는 상기 사용권리 발급자(RI)(400)의 서명이 포함된다. 상기 권리 개체 요청 메시지 및 권리 개체 응답 메시지는 DRM 2.0의 프로토콜 또는 DRM 2.1의 프로토콜을 따른다.
6) 상기 권리 개체 응답 메시지를 수신하면, 상기 DRM 에이전트는 사용권리(RO) 제공 준비 절차들을 수행한다(S160). 구체적으로 설명하면 다음과 같다.
상기 DRM 에이전트는 상기 수신한 권리 개체 응답 메시지를 검증하고, 파싱한다(S161). 즉 상기 DRM 에이전트는 상기 권리 개체 응답 메시지에 포함된 서명을 검증함으로써, 상기 권리 개체 응답 메시지가 상기 사용권리 발급자(RI)(400)에 의해 생성되었으며, 전송 도중 변경되지 않았음을 함께 확인한다. 그리고, 상기 DRM 에이전트는 상기 파싱을 함으로서, 상기 보호화된 권리 개체(Protected RO)를 복호한다. 구체적으로 설명하면 다음과 같다.
먼저, 상기 DRM 에이전트는 상기 권리 개체 응답 메시지로부터 상기 SRM(150)에 설치할 권리(Rights)를 추출하고, 상기 SRM(150)에 저장하기 위한 포맷인 권리 정보(Rights Information)로 변환한다. 상기 권리 정보(Rights Information)은 아래의 표 7과 같이 권리 메타 데이터(Rights Meta Data), 권리 개체 컨테이너(RO Container), 상태 정보(State Information)를 포함한다.
Rights Meta Data
① Rights Object Version: <protectedRO> 엘리먼트::<ro> 엘리먼트::<version> 엘리먼트.
② RO Alias: <protectedRO> 엘리먼트::<ro> 엘리먼트::<roPayloadAliases>::<roAlias> 엘리먼트.
③ RI Identifier: <protectedRO> 엘리먼트::<ro> 엘리먼트::<riID> 엘리먼트.
④ RI URL: <protectedRO> 엘리먼트::<ro> 엘리먼트::<riURL> 엘리먼트.
⑤ RI Alias: <protectedRO> 엘리먼트::<ro> 엘리먼트::<roPayloadAliases> 엘리먼트::<riAlias> 엘리먼트.
⑥ RI Time Stamp: <protectedRO> 엘리먼트::<ro> 엘리먼트::<timeStamp> 엘리먼트.
Rights Object Container
① <rights> 엘리먼트: <protectedRO> 엘리먼트::<ro> 엘리먼트:::<rights> 엘리먼트.
② <signature> 엘리먼트: <protectedRO> 엘리먼트::<ro> 엘리먼트::<signature> 엘리먼트.
State Information
만약, 권리 개체(RO)가 stateful RO일 경우, 상기 DRM 에이전트는 상기 SRM 에이전트에 설치될 Rights를 위한 State Information을 생성한다. 이때 State Information은 상기 사용권리 발급자(RI)(400)가 SRM에게 발급한 RO가 하나도 사용되지 않은 상태로 State Information을 채운다.
이어서, 상기 DRM 에이전트는 상기 생성한 권리 정보(Rights Information)의 크기(size)를 측정한다.
이어서, 상기 DRM 에이전트는 상기 권리 개체 응답 메시지 내의 상기 보호화된 권리개체(protected RO)에서 상기 보호된 키(Wrapped Key material)를 추출한다. 상기 보호화된 키는 상기 SRM 에이전트의 공개 키(public key)로 암호화 되어 있는 값이며, 상기 DRM 에이전트는 상기 보호된 키(Wrapped Key material, KMAC, KREK이 포함되어 있음)을 상기 SRM 에이전트로 제공 설정(Rights Provisioning Setup) 메시지를 통해 전달하게 되며 상기 보호된 키(Wrapped Key material)를 복호화 하는 것이 불가능하다. 왜냐하면 상기 보호된 키(Wrapped Key material)는 SRM의 공개키로 암호화 되어 있기 때문이다. 상기 보호된 키(Wrapped Key material)는 <protectedRO> 엘리먼트::<ro> 엘리먼트::<encKey>::엘리먼트::<xenc:CipherData> 엘리먼트::<xenc:Ciphervalue> 엘리먼트에 포함되어 있다. 여기서 ‘::’는 sub 엘리먼트를 의미한다. 즉 <protectedRO> 에리먼트의 하위에는 <RO> 엘리먼트가 있으며 그 하위에는 <encKey> 엘리먼트가 존재한다.
이어서, 상기 DRM 에이전트는 SRM에 설치될 Rights의 구별을 위해서 random하게 Handle을 생성한다.
상기 파싱(S161)이 완료되면, 상기 DRM 에이전트는 제공 설정 요청 메시지, 예컨대 Provisioning Setup Request 메시지를 생성하고, 상기 SRM 에이전트로 전송한다(S162). 상기 제공 설정 요청 메시지는 상기 Handle, Size, 상기 보호된 키(Wrapped Key material)를 포함한다. 구체적으로, 상기 제공 설정 요청 메시지는 아래의 표와 같은 필드들을 포함한다.
필드 설명
Handle 상기 Handle은 SRM에 저장된 Rights를 구별하기 위해서 사용된다. 상기 Handle은 10 byte로써 상기 DRM 에이전트에서 random하게 생성된 값이며, 상기 Handle을 통해서 상기 SRM에 저장된 권리(Rights)들 중 특정 권리를 선택해서 컨텐츠를 이용할 수 있다. 이러한 Handle은 암호화되어 포함된다.
Size 상기 권리의 크기이며, 상기 SRM 에이전트에 저장될 권리 정보(Rights Information)의 크기를 나타낸다. 상기 권리 정보는 권리 메타 데이터, 권리 개체 컨테이너, 상태 정보를 포함한다.
Wrapped Key Material Wrappted Key Material은 MAC key, KMAC 그리고 REK, KREK. 를 포함한다. Wrapped Key Material은 RO Response 메시지에 포함되어 있는 C value와 동일한 값이다. <protectedRO> 엘리먼트::<ro> 엘리먼트::<encKey > 엘리먼트::<xenc:CipherData> 엘리먼트::<xenc:Ciphervalue>가 C value에 해당된다.
상기 SRM 에이전트는 상기 DRM 에이전트로부터 상기 제공 설정 요청 메시지 수신하고, 제공 준비 설정 절차를 수행한다(S163).
구체적으로, 상기 SRM 에이전트는 상기 보호된 키(Wrapped Key material)를 아래와 같은 과정을 통해서 AES-WRAP(KEK, KMAC | KREK)를 SRM 에이전트의 개인키(private key)로 복호화해서 KMAC | KREK 값을 도출해 낸다.
SRM 에이전트는 C를 C1 과 C2로 분리하고 C1을 OS2IP()를 사용해서 c1을 도출하여 SRM의 개인키(private key)를 사용해서 c1을 복호화하여 Z값을 구한다:
C1 | C2 = C
c1 = OS2IP(C1, mLen)
Z = RSA.DECRYPT(PrivKeySRM, c1) = c1d mod m
OS2IP()는 octet string을 nonnegative integer로 변환해 주는 함수이며 [PKCS-1]에 정의되어 있다.
KEK = KDF(I2OSP(Z, mLen), NULL, kekLen)
상기 SRM 에이전트는 아래 수학식 3의 AES-UNWRAP()에 KEK와 C2를 입력하여, KMAC | KREK룰 구한다.
KMAC | KREK = AES-UNWRAP(KEK, C2)
상기 SRM 에이전트의 개인 키로 복호(해독)해서, KMAC과 KREK 값을 확인한다.
상기 SRM 에이전트는 상기 복호화한 KMAC 과 KREK 값 중 상기 KREK(REK)를 저장한다. 상기 REK는 상기 DRM 에이전트로부터 전송될 예정인 권리 제공 요청 메시지, 예컨대 Rights Provisioning Request에 포함된 권리 개체 컨테이너(RO Container)의 <rights> 엘리먼트를 통해서 전달되는 암호화 CEK를 복호화하는데 사용된다.
위와 같은 준비 설정 절차들이 완료되면, 상기 SRM 에이전트는 상기 DRM 에이전트로부터 수신된 상기 제공 설정 요청 메시지, 예컨대 Provisioning Setup Request에 포함된 Handle이 나타내는 영역을 상기 SRM 안에 예약해 놓은 후, 제공 설정 응답 메시지, 예컨대 Provisioning Setup Response message를 상기 DRM 에이전트로 전송한다(S164). 이때, 상기 SRM 내에는 Handle, REK만 저장되며, 권리 정보(Rights Information), LAID를 위한 공간은 예약만 해 놓는 상태이고, 추후에 상기 DRM 에이전트로부터 권리 제공 요청 메시지, 예컨대 Rights Provisioning Request를 수신하게 되면, 상기 권리 제공 요청 메시지 내에 포함된 권리 정보(Rights Information)과 함께 저장하게 된다.
상기 제공 설정 응답 메시지는 아래의 표 9와 같은 필드를 포함한다.
필드 설명
Status 제공 설정 응답 메시지(Provisioning Setup Request messag)의 처리 결과
상태의 값은 아래의 표 13과 같다.
KMAC 상기 사용권리 발급자(RI)(400)가 상기 SRM으로 발급한 권리의 무결성 검증을 위한 MAC 키
이때, 만약 상기 SRM 에이전트가 상기 권리 제공 설정을 위한 준비를 성공적으로 완료할 경우, 상기 Status 필드에 ‘Success’를 의미하는 값을 포함시킨다. 또한, 상기 KMAC 필드에 값을 포함시킨다. 이와 같은 KMAC를 통해 보호화된 권리 개체(protected RO)의 무결성을 확인할 수 있다.
만약 상기 SRM 에이전트가 상기 권리 제공 설정을 위한 준비가 실패할 경우, 아래와 같이 상기 Status 필드에 해당 에러를 포함해서 전달하게 된다.
상태값 설명
Success 제공 설정 요청(Provisioning Setup Request)가 성공적으로 처리되었다.
Field Integrity Verification Failed 제공 설정 요청 메시지의 HMAC 값이 SRM 에이전트가 생성한 HMAC값과 불일치함
Duplicate Handle 상기 SRM이 이미 동일한 Handle과 관련된 권리를 갖고 있음
Not Enough Space 상기 SRM에 Size of Rights에 해당되는 만큼의 저장 여유 공간이 없음
Parameter Failed 제공 설정 요청 메시지 구조나 길이에 문제가 있다.
Unexpected Request 제공 설정 요청이 잘못된 순서에 수신되었거나 허가되지 않은 메시지였다.
Unknown Error 알려지지 않은 다른 에러가 발생했다.
7) 상기 DRM 에이전트는 상기 제공 설정 응답 메시지를 수신하면, 사용권리(RO) 제공 절차를 수행한다(S170). 구체적으로 설명하면 다음과 같다.
먼저, 상기 DRM 에이전트는 상기 권리 개체를 검증한다(S171). 구체적으로, 상기 DRM 에이전트는 상기 제공 설정 응답 메시지에 포함된 KMAC을 통해서 보호화된 권리 개체(protected RO)가 상기 사용권리 발급자(RI)(400)로부터 수신되는 도중 변경되지 않았음을 확인한다. 해당 검증 과정을 통해서 보호화된 권리 개체(protected RO) 내의 <ro> 엘리먼트에 포함된 <rights> 엘리먼트, KMAC | KREK 가 올바르게 전달되었음을 확인하게 된다. 상기 보호화된 권리 개체(Protected RO)의 검증 작업은 상기 DRM 에이전트가 상기 SRM 에이전트를 대신하여 수행하며, 상기 해당 검증 결과가 올바를 경우, DRM 에이전트는 권리 제공(Rights Provisioning) 절차를 수행하게 된다.
상기 DRM 에이전트는 상기 권리 제공 절차를 수행하기 위하여, 권리 제공 요청 메시지, 예컨대 Rights Provisioning Request 메시지를 상기 SRM 에이전트로 전송한다(S171).
상기 권리 제공 요청 메시지는 앞서 상기 제공 설정 요청 메시지를 전송하여 상기 SRM 내에 예약해 놓은 Handle을 포함한다. 상기 Handle은 암호화되어 포함될 수 있다. 또한, 상기 권리 제공 요청 메시지는 List Of Asset ID (LAID), 권리 정보(Rights Information)을 포함한다. 이때 상기 DRM 에이전트는 상기 사용권리 발급자(RI)(400)로부터 전달받은 상기 권리 개체(RO) 상기 SRM 에이전트가 인식할 수 있는 포맷으로 상기 LAID 및 상기 권리 정보(Rights Information)를 상기 메시지에 포함시킨다. 상기 SRM 에이전트가 인식할 수 있는 포맷은 SRM 1.0 포맷일 수 있다.
상기 권리 제공 요청 메시지는 아래의 표와 같은 필드를 포함할 수 있다.
필드 설명
Handle Handle은 상기 SRM에 저장되는 복수의 권리들을 구별하기 위해서 사용된다. 상기 Handle은 10 byte로써 상기 DRM 에이전트에서 랜덤하게 생성된 값이다. 상기 DRM 에이전트는 상기 복수의 권리들 중 특정한 권리를 상기 Handle을 통해서 식별하여 선택하고, 상기 권리를 통해서 컨텐츠를 이용할 수 있다. 상기 제공 설정 요청 메시지(Provisioning Setup Request message)내에 포함된 Handle과 동일한 Handle 값.
LAID 해당 권리(Rights)와 관련된 Asset ID의 해쉬(hash) 값 list. List of hash of Asset ID.
Rights Information 권리 메터 데이터(Rights Meta Data), 권리 개체 컨테이너(RO Container), 상태 정보(State Information)을 포함한다. 상기 권리 메타 데이터(Rights Meta Data)는 권리 개체 버전, RO Alias, RI Identifier, RI URL. RI Alias, RI Timestamp를 포함한다.
상기 권리 개체 컨테이너(RO Container)는 <rights> 엘리먼트와 <signature> 엘리먼트를 포함한다.
상기 권리 개체가 Stateful RO의 경우, 상태 정보(State Information)이 포함되어 있다.
상기 권리 제공 요청 메시지를 수신하면, 상기 SRM 에이전트는 상기 메시지 내에 포함된 Handle과 권리 정보(Rights Information)를 상기 SRM에 저장한다(S173). 그리고 상기 SRM 에이전트는 Handle 리스트를 갱신한다. 상기 Handle 리스트를 갱신함으로써, 상기 SRM이 다른 단말에 장착되더라도, 상기 Handle이 인식될 수 있도록 한다. 상기 SRM 에 저장된 정보는 다음의 표와 같다.
Handle Rights Information LAID REK
상기 설치가 완료되면, 상기 SRM 에이전트는 상기 DRM 에이전트로 권리 제공 응답 메시지를 전송한다(S174).
상기 권리 제공 응답 메시지는 다음의 표와 같은 필드를 포함할 수 있다.
필드 설명
Status 권리 제공 요청 메시지의 처리 결과.
Status 값은 표13에 정의되어 있다.
상태값 설명
Success 권리 제공 요청 메시지가 성공적으로 처리됨
Field Integrity Verification Failed 권리 제공 요청 메시지의 HMAC 값이 상기 SRM 에이전트가 생성한 HMAC값과 불일치함
Handle Not Found 권리 제공 요청 메시지에 포함된 Handle을 상기 SRM에서 찾을 수 없음
Handles In-Consistent 권리 제공 요청 메시지에 포함된 Handle이 권리 설정 요청 메시지 에 포함된 Handle과 다름
Not Enough Space SRM에 Size of Rights에 해당되는 만큼의 저장 여유 공간이 없음
Parameter Failed 권리 제공 요청 메시지의 구조나 길이에 문제가 있다.
Unexpected Request 권리 제공 요청 메시지가 잘못된 순서에 수신되었거나 허가되지 않은 메시지였다.
Unknown Error 알려지지 않은 다른 에러가 발생했다.
상기 권리 제공 응답 메시지를 수신하면, 상기 DRM 에이전트는 상기 설치가 성공인지를 판단하고, 성공인 경우 자신이 저장했던 권리 개체를 삭제한다(S172). 구체적으로 상기 DRM 에이전트는 상기 권리 제공 응답 메시지의 Status 필드의 값이 ‘Success’인지를 판단한다.
도 7는 도 4 및 도 6에 도시된 트러스트 모델 협상 과정을 상세하게 나타낸 흐름도이다.
도 6에 도시된 바와 같이, 상기 사용권리 발급자(400), 상기 단말(110) 내의 상기 DRM 에이전트, 상기 SRM(150) 내의 상기 SRM 에이전트는 각기 트러스트 앵커(TA) 및 SRM의 ID 간의 쌍에 대한 리스트를 가지고 있다고 가정한다.
상기 사용권리 발급자(400)의 리스트에는 예를 들어 C-C2, D-D2, E-E2를 포함한다. 상기 DRM 에이전트의 리스트에는 예를 들어 B-B2, C-C1, D-D1을 포함한다. 그리고, 상기 SRM 에이전트의 리스트에는 예를 들어, C-C2, D-D2, E-E2를 포함한다. 상기 C-C2는 트러스트 앵커는 C이고 SRM ID는 C2임을 나타낸다. 마찬가지로 D-D2는 트러스트 앵커는 D이고 SRM ID는 D2를 나타낸다.
1) 이와 같은 가정하에서 도 6을 참조하여 설명하면, 상기 DRM 에이전트는 HELLO 절차 및 MAKE 절차를 수행한다(S110). 상기 MAKE 절차를 통해서 상기 DRM 에이전트 및 상기 SRM 에이전트 간에는 SAC 세션을 위한 SAC 컨텍스가 생성된다. 상기 SAC 컨텍스트에는 상기 DRM 에이전트 및 상기 SRM 에이전트 간에 협상된 Session Key (SK), MAC Key (MK), 선택된 알고리즘에 대한 정보, 트러스트 앵커 및 엔티티 ID가 포함되어 있다. 상기 트러스트 앵커의 협상은 먼저 트러스트 모델을 협상하고, 이어서 협상된 모델들 내에서 트러스트 앵커를 정하는 방식으로 이루어진다. 도 6에서 예시적으로 도시된 SAC 컨텍스트에는 트러스트 앵커로서 C와 SRM의 ID로서 C2가 포함되어 있다. 이와 같이 SAC 컨텍스트가 생성되면, 상기 DRM 에이전트는 상기 트러스트 앵커 하에서 상기 C2를 이용하여 상기 SRM을 식별할 수 있다. 마찬가지로 상기 SRM 에이전트는 상기 단말의 ID를 SAC 컨텍스트에 저장하고, 상기 저장된 ID를 통해 상기 단말을 식별할 수 있다.
2) 한편, 상기 사용권리 발급자(RI)(400)는 트리거 메시지, 예컨대 ROAP Trigger 메시지를 전달한다(S120). 이때, 상기 트리거 메시지는 상기 SRM을 위한 트러스트 앵커 및 ID 쌍의 리스트를 포함한다.
3) 상기 트리거 메시지를 수신하면, 상기 DRM 에이전트는 트러스트 모델 협상 과정을 수행한다(S130). 구체적으로 설명하면 다음과 같다.
상기 DRM 에이전트는 상기 트리거 메시지에 포함된 리스트와 상기 SAC 컨텍스트 내의 리스트를 비교한다(S131). 다시 말해서 상기 DRM 에이전트는 상기 트리거 메시지에 포함된 리스트와 상기 SAC 컨텍스트 내의 리스트 중에서 서로 일치하는 트러스트 앵커와 SRM ID가 있는지 확인한다. (The DRM Agent compares the <trustAnchor> element and <srmID> element in the <trustAnchorAndsrmIDPair> element with the Trust Anchor and SRMID pair of the SAC Context in an SRM attached Device.)
상기 DRM 에이전트는 상기 트리거 메시지에 포함된 리스트와 상기 SAC 컨텍스트 내의 리스트 중에서 상기 서로 일치하는 트러스트 앵커와 SRM ID가 있는 경우, 서명 획득 과정(S140)으로 진행한다.
그러나, 상기 서로 일치하는 트러스트 앵커와 SRM ID가 없는 경우(If all of a <trustAnchor> element and a <srmID> element does not match any Trust Anchor and SRMID pair of the SAC Context in the DRM Agent), 상기 DRM 에이전트는 상기 트리거 메시지에 포함된 리스트 내의 트러스트 앵커 및 SRM ID가 상기 DRM 에이전트에 저장되어 있는 SRM의 트러스트 앵커 및 SRM-ID와 일치하는지 확인한다(S132). 즉, 상기 DRM 에이전트는 상기 트리거 메시지 내의 트러스트 앵커를 지원하는지 확인한다. 만일, 상기 DRM 에이전트는 상기 트리거 메시지 내의 트러스트 앵커를 지원하는지 않으면, 상기 DRM 에이전트는 트러스트 모델 협상이 실패한 것으로 간주하고, 상기 과정을 끝낸다.
상기 DRM 에이전트의 리스트와 일치하는 트러스트 앵커 및 SRM ID가 있으면(즉, 상기 DRM 에이전트가 상기 트리거 메시지 내의 트러스트 앵커를 지원하는 경우), 상기 DRM 에이전트는 상기 SRM 에이전트와 상기 트러스트 앵커를 사용해서 MAKE 절차를 다시 수행한다(S110’). 이를 위해, 상기 DRM 에이전트는 상기 SRM 에이전트로 상기 일치하는 트러스트 앵커 및 SRM ID 쌍에 대한 정보를 포함하는 인증 요청 메시지를 전송한다. 상기 인증 요청 메시지는 상기 트리거 메시지 내에 존재하고, 상기 DRM 에이전트에 의해서 지원되는 상기 트러스트 앵커에 대한 정보 또는 트러스트 앵커를 포함할 수도 있다. 만약 DRM Agent가 S110의 SRMHello 메시지를 통해 수신한 SRM의 Trust Anchor와 SRMID의 리스트를 어떠한 특별한 이유로 삭제한 경우는 MAKE를 수행하기 전에 SRM Hello 절차를 먼저 수행하여, SRM의 Trust Anchor와 SRMID의 리스트를 DRM Agent의 메모리 내에 확보한다. 상기 SRM 에이전트는 상기 인증 요청 메시지 내의 상기 트러스트 앵커를 자신이 지원할 경우, 정상적인 인증 응답 메시지를 전송한다. 그러나, 상기 인증 요청 메시지 내의 상기 트러스트 앵커를 자신이 지원하지 않을 경우, 상기 인증 응답 메시지의 상태를’Trust Anchor Not Supported’로 설정하여 전송한다.
상기 DRM 에이전트는 상기 인증 응답 메시지 내의 상태가 ‘Trust Anchor Not Supported’일 경우, 자신의 지원하는 다른 트러스트 앵커가 있는지 확인하고, 다른 트러스트 앵커가 i개 존재한다면, 상기 다른 트러스트 앵커를 기반으로 상기 MAKE 절차를 i번 반복한다. 그러나, 상기 i번 반복 후에 수신되는 모든 인증 응답 메시지의 상태가 Trust Anchor Not Supported’일 경우, 상기 DRM 에이전트는 상기 사용권리 발급자(RI), 상기 DRM 에이전트, 상기 SRM 에이전트간 일치하는 트러스트 앵커가 없는 것으로 간주하고 최종 에러를 사용자에게 알린다. 그리고, 상기 DRM 에이전트는 선택적으로 트리거 에러 보고 메시지, 예컨대 Trigger Error report 메시지를 상기 사용권리 발급자(RI)(400)로 전송한다. 이때, 상기 트리거 에러 보고 메시지는‘Trust Anchor Not Supported’를 의미하는 상태 파라미터를 포함한다.
지금까지는 트러스트 모델 협상 과정(S130)을 상세하게 설명하였다. 그러나 상기 트러스트 모델 협상 과정은 전술한 설명에 한정되는 것은 아니며, 다양하게 변형될 수 있다.
예를 들어, SAC 컨텍스트 에는 트러스트 앵커 및 SRM ID 쌍이 하나만 포함되어 있지만, 상기 HELLO 절차 및 MAKE 절차(S110)를 수행할 때, 상기 DRM 에이전트는 상기 SRM 에이전트가 지원하는 트러스트 앵커 및 SRM ID 쌍에 대한 리스트를 수신하므로, 상기 DRM 에이전트는 상기 SAC 컨텍스트와는 별도로 상기 SRM 에이전트로부터 수신된 트러스트 앵커 및 SRM ID 쌍에 대한 리스트를 저장할 수 있다. 그러므로, 상기 DRM 에이전트는 상기 S132 과정에서 상기 트리거 메시지에 포함된 리스트 내의 트러스트 앵커 및 SRM ID가 상기 DRM 에이전트의 리스트뿐만이 아니라 상기 SRM 에이전트의 리스트와도 일치하는지를 확인할 수 있다.
도 8는 본 발명의 제2 실시 예에 따른 방법을 나타낸 흐름도이다.
도 8에 도시된 바와 같이, 제2 실시 예에 따른 방법은 전술한 제1 실시 예와 달리 트리거 메시지, 사용권리 요청 메시지가 수신되지 않고, 권리 개체 응답 메시지만이 수신된다. 이를 푸쉬(push) 모델이라고 한다. 상세하게 설명하면 다음과 같다.
1) S210 과정은 도 5 및 도 6의 S110과정을 참조하면 당업자가 용이하게 알 수 있으므로, 상세하게 설명하지 않기로 한다.
2) 상기 DRM 에이전트는 상기 사용권리 발급자(RI)(400)로부터 권리 개체 응답 메시지, 예컨대 RO Response 메시지를 수신한다(S240). 상기 권리 개체 메시지는 상기 사용권리 발급자(RI)(400)와의 브라우징 세션을 통한 사용자의 요청에 의해 수신될 수 있다. 예를 들어, 상기 사용자는 상기 브라우징 세션을 통해, SRM 명의의 사용권리를 요청한다. 이와 같은 브라우징 세션을 통해 SRM에 대한 정보 (트러스트 앵커 및 SRM ID 쌍의 리스트)와 상기 단말(100)에 대한 정보(Device ID 등)가 상기 사용권리 발급자(RI)(400)로 전달될 수 있다.
상기 권리 개체 응답 메시지는 전술한 바와 같이
상기 권리 개체 응답 메시지는 전술한 바와 같이 상기 보호화된 권리 개체(protectedRO)를 포함한다. 상기 보호화된 권리 개체(protectedRO)는 <ro> 엘리먼트와 <mac> 엘리먼트를 포함한다. 상기 <ro> 엘리먼트는 <ROPayload> type이며, 표 3과 같다.
다만, 제2 실시 예에서는 상기 표 3에 나타난 정보 이외에 아래의 표8과 같은 TrustAnchorAndSRM IDPair를 더 포함한다. 상기 TrustAnchorAndSRM IDPair는 상기 사용권리 발급자(RI)(400)지원하는 트러스트 앵커들 중에서 상기 SRM에서 지원 가능한 트러스트 앵커 및 SRM ID가 리스트의 형태로 포함될 수 있다.
<sequence maxOccurs="unbounded">
<element name="encKey" type="xenc:EncryptedKeyType"/>
<element name="trustAnchorAndsrmIDPair" type="roap:trustAnchor AndsrmIdentifierPairType" minOccurs="0"/>
</sequence>
3) 상기 권리 개체 응답 메시지를 수신하면, 상기 DRM 에이전트는, 상기 메시지가 자신을 위한 것인지 상기 SRM(150)을 위한 것인지를 판단하고, 상기 메시지를 검증한다.
그리고, 상기 DRM 에이전트는 트러스트 모델을 협상한다(S130). 그리고 상기 DRM 에이전트는 선택적으로 SRM Hello 과정과 MAKE 과정을 수행한다. 이 과정은 도 9를 참조하여 후술하기로 한다.
한편, S260 과정 및 S270 과정은 도 6의 S160 과정 및 S170과정과 동일하므로, 도 6에 대한 설명 내용을 준용하기로 한다.
도 9는 도 8에 도시된 트러스트 모델 협상 과정을 상세하게 나타낸 흐름도이다.
도 9를 참조하여 알 수 있는 바와 같이, 도시된 절차들은 도 7의 절차들과 유사하다. 따라서, 이하 차별되는 절차에 대해서만 설명하고, 동일한 절차는 간단하게 설명하기로 한다.
1) 상기 DRM 에이전트는 HELLO 절차 및 MAKE 절차를 수행한다(S210). 이 과정은 도 7의 과정과 동일하다.
2) 상기 사용권리 발급자(RI)(400)는 권리 개체 응답 메시지, 예컨대 RO Response 메시지를 전달한다(S240). 이때, 상기 권리 개체 응답 메시지 는 상기 SRM을 위한 트러스트 앵커 및 ID 쌍의 리스트를 포함한다.
3) 상기 권리 개체 응답 메시지를 수신하면, 상기 DRM 에이전트는 트러스트 모델 협상 과정을 수행한다(S130).
이때, 전술한 바와 같이 i번 반복 후에 수신되는 모든 인증 응답 메시지의 상태가 Trust Anchor Not Supported’일 경우, 상기 DRM 에이전트는 선택적으로 권리 개체 확인 요청 보고 메시지, 예컨대 RO Confirm Request 메시지를 상기 사용권리 발급자(RI)(400)로 전송한다. 이때, 상기 권리 개체 확인 요청 보고 메시지 는‘Trust Anchor Not Supported’를 의미하는 상태 파라미터를 포함한다.
도 10은 본 발명의 따른 단말(100) 및 SRM(150)의 구성 블록도이다.
도 10에 도시된 바와 같이 상기 단말(100)은 저장 수단, 송수신부, 커넥터, 컨트롤러를 포함한다. 그리고 상기 메모리 카드, 즉 SRM은 저장 수단, 커넥터, 컨트롤러를 포함한다.
상기 커넥터는 상기 단말(100)과 상기 메모리 카드, 즉 SRM을 서로 접속시킨다.
상기 저장 수단들은 도 4 내지 도 8에 도시된 방법이 구현된 소프트웨어 프로그램을 저장한다. 그리고, 상기 저장 수단들은 수신한 각 메시지 내의 정보들을 저장한다.
상기 컨트롤러들 각각은 상기 저장 수단들 및 상기 송수신부들을 각기 제어한다. 구체적으로 상기 컨트롤러들은 상기 저장 수단들에 각기 저장된 상기 방법들을 각기 실행한다. 그리고 상기 컨트롤러들 각각은 상기 송수신부들을 통해 상기 전술한 신호들을 전송한다.
이상에서는 본 발명의 바람직한 실시 예를 예시적으로 설명하였으나, 본 발명의 범위는 이와 같은 특정 실시 예에만 한정되는 것은 아니므로, 본 발명은 본 발명의 사상 및 특허청구범위에 기재된 범주 내에서 다양한 형태로 수정, 변경, 또는 개선될 수 있다.
도 1은 일반적인 DRM 시스템의 구성을 보인다.
도 2는 종래 기술에 따른 문제점을 나타낸다.
도 3은 본 발명에 따라 컨텐츠 및 사용권리를 메모리 카드에 발급하는 개념을 나타낸다.
도 4는 본 발명의 개념을 개략적으로 나타낸 흐름도이다.
도 5는 도 4에 도시된 상호 인증 절차를 상세하게 나타낸 흐름도이다.
도 6은 본 발명의 제1 실시예에 따른 방법을 나타낸 흐름도이다.
도 7은 도 4 및 도 5에 도시된 트러스트 모델 협상 과정을 상세하게 나타낸 흐름도이다.
도 8은 본 발명의 제2 실시예에 따른 방법을 나타낸 흐름도이다.
도 9는 도 8에 도시된 트러스트 모델 협상 과정을 상세하게 나타낸 흐름도이다.
도 10은 본 발명의 따른 단말(100) 및 SRM(150)의 구성 블록도이다.

Claims (23)

  1. 삭제
  2. 삭제
  3. 삭제
  4. 삭제
  5. 삭제
  6. 삭제
  7. 삭제
  8. 삭제
  9. 삭제
  10. 삭제
  11. 삭제
  12. 삭제
  13. 삭제
  14. 메모리 카드를 대신하여 권리 발급 서버로부터 권리 객체(right object; RO)를 수신하기 위한 방법으로서, 상기 방법은 단말에 의해 수행되며, 상기 방법은:
    상기 권리 발급 서버로부터 RO 획득을 위한 트리거 메시지를 수신하는 단계;
    상기 메모리 카드를 위한 RO 획득을 위한 트리거 메시지가 수신되면, 상기 단말과 상기 메모리 카드 사이의 상호 절차에 의해 생성된 보안 인증 채널(Secure Authenticated Channel; SAC)에서, 상기 트리거 메시지에 포함된 트러스트 앵커(trust anchor) 및 상기 메모리 카드의 ID를 포함하는 제1 페어(pair)의 데이터 아이템들과, 트러스트 앵커 및 상기 메모리 카드의 ID를 포함하는 제2 페어의 데이터 아이템들을 비교하는 단계;
    상기 비교의 결과가 상기 제1 페어의 데이터 아이템들이 상기 제2 페어의 데이터 아이템들과 불일치한다고 지시하면,
    상기 트리거 메시지에 포함된 상기 단말에 의해 지원되는 다른 트러스트 앵커를 식별하는 단계;
    상기 메모리 카드와 상호 인증 절차를 수행하는 단계, 상기 상호 인증 절차는:
    상기 단말로부터 상기 메모리 카드로 인증 요청 메시지를 전송하는 단계, 상기 인증 요청 메시지는 상기 다른 트러스트 앵커를 포함함, 및
    상기 메모리 카드로부터 상기 다른 트러스트 앵커가 상기 메모리 카드에 의해 지원됨을 지시하는 정보를 포함하는 인증 응답 메시지를 수신하는 단계를 포함하고,
    상기 권리 발급 서버로 상기 메모리 카드의 ID를 포함하는 RO 요청 메시지를 전송하는 단계; 및
    상기 권리 발급 서버로부터 보호된(protected) RO를 포함하는 RO 응답 메시지를 수신하는 단계를 포함하는 것을 특징으로 하는, 권리 객체 수신 방법.
  15. 제14항에 있어서, 상기 수신된 트리거 메시지가 상기 제1 페어의 데이터 아이템들을 포함하면, 상기 수신된 트리거 메시지가 상기 메모리 카드를 위한 RO 획득을 위한 트리거 메시지인 것으로 판단되는 것을 특징으로 하는, 권리 객체 수신 방법.
  16. 제14항에 있어서,
    상기 비교의 결과가 상기 제1 페어의 데이터 아이템들이 상기 제2 페어의 데이터 아이템들과 일치한다고 지시하면 상기 권리 발급 서버로 RO 요청 메시지를 전송하는 단계를 더 포함하는 것을 특징으로 하는, 권리 객체 수신 방법.
  17. 제14항에 있어서, 상기 보호된 RO는 상기 메모리 카드의 공개 키(public key)를 사용하여 암호화되고, 상기 공개 키는 상기 메모리 카드에 의해 지원될 트러스트 앵커로부터 제공되는 것을 특징으로 하는, 권리 객체 수신 방법.
  18. 제14항에 있어서, 상기 RO 요청 메시지를 전송하는 단계는:
    상기 메모리 카드 대신 상기 RO 요청 메시지를 생성하는 단계;
    상기 메모리 카드로 서명(signature) 질의 요청 메시지를 전송하는 단계, 상기 서명 질의 요청 메시지는 상기 RO 요청 메시지를 포함함,
    상기 메모리 카드로부터 서명 질의 응답 메시지를 수신하는 단계, 상기 서명 질의 응답 메시지는 상기 메모리 카드의 서명을 포함함, 및
    상기 메모리 카드의 서명을 포함하는 상기 RO 요청 메시지를 전송하는 단계를 포함하는 것을 특징으로 하는, 권리 객체 수신 방법.
  19. 제14항에 있어서,
    상기 보호된 RO를 파싱(parsing)하는 단계, 상기 파싱하는 동안 권리들이 상기 RO로부터 추출되고 상기 메모리 카드에 저장될 포맷인 권리 정보로 변환됨,
    상기 메모리 카드에 저장될 상기 권리 정보를 식별하기 위한 식별자를 생성하는 단계;
    상기 메모리 카드로 프로비져닝(provisioning) 설정(setup) 요청 메시지를 전송하는 단계, 상기 프로비져닝 설정 요청 메시지는 상기 식별자와 상기 권리 정보의 크기(size)와 관련된 정보를 포함함,
    상기 메모리 카드로부터 상기 프로비져닝 설정의 상태(status)를 포함하는 프로비져닝 설정 응답 메시지를 수신하는 단계; 및
    상기 상태가 성공(success)이면 상기 권리 정보를 상기 메모리 카드로 인스톨(install)하기 위해 상기 메모리 카드로 상기 권리 정보를 포함하는 권리 프로비져닝 요청 메시지를 전송하는 단계를 포함하는 것을 특징으로 하는, 권리 객체 수신 방법.
  20. 메모리 카드 대신 권리 객체(rights object; RO)를 수신하도록 구성된 단말로서, 상기 단말은:
    권리 발급 서버로부터 RO 획득을 위한 트리거 메시지를 수신하도록 구성된 송수신부; 및
    상기 송수신부를 제어하도록 구성된 프로세서를 포함하고, 상기 프로세서는:
    상기 메모리 카드를 위한 RO 획득을 위한 트리거 메시지가 수신되면, 상기 단말과 상기 메모리 카드 사이의 상호 절차에 의해 생성된 보안 인증 채널(Secure Authenticated Channel; SAC)에서, 상기 트리거 메시지에 포함된 트러스트 앵커(trust anchor) 및 상기 메모리 카드의 ID를 포함하는 제1 페어(pair)의 데이터 아이템들과, 트러스트 앵커 및 상기 메모리 카드의 ID를 포함하는 제2 페어의 데이터 아이템들을 비교하고,
    상기 비교의 결과가 상기 제1 페어의 데이터 아이템들이 상기 제2 페어의 데이터 아이템들과 불일치한다고 지시하면,
    상기 트리거 메시지에 포함된 상기 단말에 의해 지원되는 다른 트러스트 앵커를 식별하고,
    상기 메모리 카드와 상호 인증 절차를 수행하고, 상기 상호 인증 절차는:
    상기 단말로부터 상기 메모리 카드로 인증 요청 메시지를 전송하는 단계, 상기 인증 요청 메시지는 상기 다른 트러스트 앵커를 포함함, 및
    상기 메모리 카드로부터 상기 다른 트러스트 앵커가 상기 메모리 카드에 의해 지원됨을 지시하는 정보를 포함하는 인증 응답 메시지를 수신하는 단계를 포함하고,
    상기 권리 발급 서버로 상기 메모리 카드의 ID를 포함하는 RO 요청 메시지를 전송하고; 그리고
    상기 권리 발급 서버로부터 보호된(protected) RO를 포함하는 RO 응답 메시지를 수신하도록 구성되는 것을 특징으로 하는, 단말.
  21. 제20항에 있어서, 상기 수신된 트리거 메시지가 상기 제1 페어의 데이터 아이템들을 포함하면 상기 수신된 트리거 메시지가 상기 메모리 카드를 위한 RO 획득을 위한 트리거 메시지인 것으로 판단되는 것을 특징으로 하는, 단말.
  22. 제20항에 있어서, 상기 프로세서는 상기 비교의 결과가 상기 제1 페어의 데이터 아이템들이 상기 제2 페어의 데이터 아이템들과 일치한다고 지시하면 상기 권리 발급 서버로 RO 요청 메시지를 전송하도록 구성되는 것을 특징으로 하는, 단말.
  23. 제20항에 있어서, 상기 보호된 RO는 상기 메모리 카드의 공개 키(public key)를 사용하여 암호화되고, 상기 공개 키는 상기 메모리 카드에 의해 지원될 것으로 확인된 트러스트 앵커로부터 제공되는 것을 특징으로 하는, 단말.
KR1020090105146A 2009-01-29 2009-11-02 메모리 카드를 대신하여 컨텐츠에 대한 권리 개체를 수신하는 방법 및 단말 KR101683111B1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP10735983.8A EP2382576B1 (en) 2009-01-29 2010-01-18 Method and terminal for receiving rights object for content on behalf of memory card
CN201080006116.6A CN102301372B (zh) 2009-01-29 2010-01-18 用于代表存储卡接收用于内容的权利对象的方法和终端
PCT/KR2010/000296 WO2010087592A1 (en) 2009-01-29 2010-01-18 Method and terminal for receiving rights object for content on behalf of memory card
US12/696,039 US8307457B2 (en) 2009-01-29 2010-01-28 Method and terminal for receiving rights object for content on behalf of memory card

Applications Claiming Priority (12)

Application Number Priority Date Filing Date Title
US14805309P 2009-01-29 2009-01-29
US61/148,053 2009-01-29
US17011309P 2009-04-17 2009-04-17
US61/170,113 2009-04-17
US18598809P 2009-06-10 2009-06-10
US61/185,988 2009-06-10
US18728409P 2009-06-16 2009-06-16
US61/187,284 2009-06-16
KR1020090073802A KR20100088051A (ko) 2009-01-29 2009-08-11 메모리 카드에 컨텐츠에 대한 사용권리를 설치하는 방법
KR1020090073802 2009-08-11
KR1020090101947A KR20100088061A (ko) 2009-01-29 2009-10-26 메모리 카드에 컨텐츠에 대한 사용권리를 설치하는 방법
KR1020090101947 2009-10-26

Publications (2)

Publication Number Publication Date
KR20100088063A KR20100088063A (ko) 2010-08-06
KR101683111B1 true KR101683111B1 (ko) 2016-12-06

Family

ID=42754386

Family Applications (3)

Application Number Title Priority Date Filing Date
KR1020090073802A KR20100088051A (ko) 2009-01-29 2009-08-11 메모리 카드에 컨텐츠에 대한 사용권리를 설치하는 방법
KR1020090101947A KR20100088061A (ko) 2009-01-29 2009-10-26 메모리 카드에 컨텐츠에 대한 사용권리를 설치하는 방법
KR1020090105146A KR101683111B1 (ko) 2009-01-29 2009-11-02 메모리 카드를 대신하여 컨텐츠에 대한 권리 개체를 수신하는 방법 및 단말

Family Applications Before (2)

Application Number Title Priority Date Filing Date
KR1020090073802A KR20100088051A (ko) 2009-01-29 2009-08-11 메모리 카드에 컨텐츠에 대한 사용권리를 설치하는 방법
KR1020090101947A KR20100088061A (ko) 2009-01-29 2009-10-26 메모리 카드에 컨텐츠에 대한 사용권리를 설치하는 방법

Country Status (4)

Country Link
EP (1) EP2382576B1 (ko)
KR (3) KR20100088051A (ko)
CN (1) CN102301372B (ko)
WO (1) WO2010087592A1 (ko)

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6823417B2 (en) * 2001-10-01 2004-11-23 Hewlett-Packard Development Company, L.P. Memory controller for memory card manages file allocation table
KR101100385B1 (ko) * 2004-03-22 2011-12-30 삼성전자주식회사 인증서 폐지 목록을 이용한 디지털 저작권 관리 방법 및장치
KR20050094273A (ko) * 2004-03-22 2005-09-27 삼성전자주식회사 디지털 저작권 관리 구조, 휴대용 저장 장치 및 이를이용한 컨텐츠 관리 방법
KR101254209B1 (ko) * 2004-03-22 2013-04-23 삼성전자주식회사 디바이스와 휴대용 저장장치간에 권리 객체를 이동,복사하는 방법 및 장치
KR100608605B1 (ko) * 2004-09-15 2006-08-03 삼성전자주식회사 디지털 저작권 관리 방법 및 장치
KR100755707B1 (ko) * 2005-01-13 2007-09-05 삼성전자주식회사 호스트 디바이스, 휴대용 저장장치, 및 휴대용 저장장치에저장된 권리객체의 메타 정보를 갱신하는 방법
KR20070050712A (ko) * 2005-11-11 2007-05-16 엘지전자 주식회사 Srm의 디지털 저작권 관리 방법 및 장치
KR100821083B1 (ko) * 2005-11-30 2008-04-10 에스케이 텔레콤주식회사 디지털 권한 관리를 이용한 자작 컨텐츠 유통 시스템 및 그방법
FR2898001A1 (fr) * 2006-02-28 2007-08-31 Gemplus Sa Gestion d'acces securise a un contenu numerique securise dans un objet communicant portable
RU2419235C2 (ru) * 2006-05-05 2011-05-20 Интердиджитал Текнолоджиз Корпорейшн Управление цифровыми правами с использованием методик доверительной обработки
KR101443612B1 (ko) * 2006-08-08 2014-09-23 엘지전자 주식회사 Ｒｏ 이동을 위한 ｄｒｍ 에이전트 간의 인증 방법 및 장치
KR100988374B1 (ko) * 2007-12-14 2010-10-18 엘지전자 주식회사 사용권리 이동 방법, 사용권리의 발급권한 관리 방법 및시스템
KR101517942B1 (ko) * 2008-08-21 2015-05-06 삼성전자주식회사 디지털 저작권 관리에서 에스알엠을 사용하기 위한 장치 및방법

Also Published As

Publication number Publication date
EP2382576A4 (en) 2012-05-02
KR20100088063A (ko) 2010-08-06
KR20100088061A (ko) 2010-08-06
EP2382576A1 (en) 2011-11-02
EP2382576B1 (en) 2018-10-31
WO2010087592A1 (en) 2010-08-05
KR20100088051A (ko) 2010-08-06
CN102301372A (zh) 2011-12-28
CN102301372B (zh) 2014-07-23

Similar Documents

Publication Publication Date Title
US9489498B2 (en) Digital rights management using trusted processing techniques
US7568234B2 (en) Robust and flexible digital rights management involving a tamper-resistant identity module
US8656156B2 (en) Method and terminal for authenticating between DRM agents for moving RO
US9026793B2 (en) Method for installing rights object for content in memory card
US8719956B2 (en) Method and apparatus for sharing licenses between secure removable media
US9177112B2 (en) Method and device for communicating digital content
KR101517942B1 (ko) 디지털 저작권 관리에서 에스알엠을 사용하기 위한 장치 및방법
US8307457B2 (en) Method and terminal for receiving rights object for content on behalf of memory card
CN113676332B (zh) 二维码认证方法、通信设备及存储介质
CN104868998A (zh) 一种向电子设备供应加密数据的系统、设备和方法
US9589113B2 (en) Method for using rights to contents
JP2011028522A (ja) ホスト装置、認証方法、並びに、コンテンツ処理方法及びそのシステム
US8667601B2 (en) Method and device for upgrading rights object that was stored in memory card
CN106230832A (zh) 一种设备标识校准的方法
KR101683111B1 (ko) 메모리 카드를 대신하여 컨텐츠에 대한 권리 개체를 수신하는 방법 및 단말
KR20060124215A (ko) Ｅｓｎ 불법 복제 방지를 위한 이동 통신 단말과 이를이용한 ｅｓｎ 불법 복제 방지 방법
JP2006066960A (ja) 記憶装置、記憶方法およびプログラム

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right