KR101018368B1 - 트러스티드 프로세싱 기술을 사용하는 디지탈 권리 관리 - Google Patents

Abstract

본 발명은 오픈 모바일 얼라이언스 (OMA; Open Mobile Alliance) 디지탈 권리 관리 (DRM; Digital Rights Management) 에 의해 정의되는 컨텐츠 배포와 관련되는 엔티티, 메시지 및 프로세싱의 무결성을 강화하는 여러 방법을 개시한다. 상기 방법은 트러스티드 컴퓨팅 그룹 (TCG; Trusted Computing Group) 규격과 관련되는 기술을 사용한다. 제 1 실시예에서는, DRM 권리 오브젝트 획득 프로토콜 (ROAP) 와 DRM 컨텐츠 포맷 규격에 대한 변형과 함께 그리고 변형없이, TCG 기술을 사용하여 플랫폼과 DRM 소프트웨어의 무결성 또는 신뢰성을 검증한다. 제 2 실시예에서는, 기존의 ROAP 프로토콜의 변경없이, TCG 기술을 사용하여 ROAP 메시지, 구성요소 정보 및 프로세싱의 무결성을 강화한다. 제 3 실시예에서는, 기존의 ROAP 프로토콜에 대한 일부 변경과 함께, TCG 기술을 사용하여 ROAP 메시지, 정보 및 프로세싱의 무결성을 강화한다.

DRM, OMA, ROAP 프로토콜, 무결성

Description

트러스티드 프로세싱 기술을 사용하는 디지탈 권리 관리 {DIGITAL RIGHTS MANAGEMENT USING TRUSTED PROCESSING TECHNIQUES}

본 발명은 일반적으로 무선 통신 네트워크에서의 디지탈 권리 관리 (DRM; digital rights management) 방법에 관한 것이다. 보다 구체적으로, 본 발명은 OMA (open mobile alliance) DRM 규격 (specifications) 에 따라 동작하는 시스템에서의 보안, 무결성 (integrity) 및 신뢰성 (trustworthiness) 을 향상시키는 방법을 제공한다.

OMA DRM 은 이동 전화 및 디바이스 제조자와 모바일 서비스 제공자의 컨소시엄인 OMA 에 의해 명시된 DRM 시스템이다. 상기 방식은 많은 이동 전화에서 실행되고 있고, 이동 컨텐츠 제공자에 의해 사용되어 그들의 제품 및 서비스에 DRM 을 부가하도록 의도되어 있다. OMA DRM 은 2 개의 버전; OMA DRM 1.0 과 OMA DRM 2.0 이 공개되어 있다.

OMA DRM 1.0 은 컨텐츠 오브젝트 (content object) 에 대한 디지탈 권리의 기본적인 관리를 위한 방식들을 제기했다. 따라서, 그것은 컨텐츠 오브젝트나 권리 오브젝트에 대한 강력한 보호를 제공하지 않는다. OMA DRM 1.0 은 3 가지의 전달 방법을 명시한다: 포워드 락(Forward lock) (사용자가 컨텐츠를 다른 사용자 또는 디바이스로 포워드하는 것을 방지함), 결합 전달 (combined delivery)(결합된 권리 오브젝트와 미디어 오브젝트), 및 분리 전달 (separate delivery)(분리된 권리 오브젝트와 미디어 오브젝트). OMA DRM 1.0 은 전화용 월페이퍼 (wallpaper) 나 호출음과 같은 소규모 미디어 오브젝트를 취급하도록 설계되었다.

OMA DRM 2.0 은 OMA DRM 1.0 전달 메카니즘을 개선하여 확장한다. OMA DRM 2.0 을 준수하는 디바이스는 DRM 공개키 기반구조 (PKI; public key infrastructure) 에 기초하는 개별적인 인증서를 가지며, 즉, 각각의 디바이스가 공개키, 대응하는 비밀키, 및 이러한 사실을 검증하는 인증서를 갖는다. 각각의 권리 오브젝트 (RO) 는 (암호화에 의한) 기밀성 및 (전자 서명에 의한) 무결성 양자에 대해 보호된다. PKI 의 사용, 암호화 및 무결성 체킹을 통해 OMA DRM 1.0 시스템에 비해 OMA DRM 2.0 시스템의 보안이 강화된다.

OMA DRM 2.0 은 또한 권리 오브젝트 획득 프로토콜 (ROAP; Rights Object Acquisition Protocol) 로 총칭하여 불리우는 프로토콜 세트를 명시하며, 상기 ROAP 는 디바이스와 권리 발행자 (RI; rights issuer) 사이의 상호 인증 및 등록, RO 의 요구, RO 전달에 대한 응답 또는 RO 전달에 대한 거절, 및 디바이스에 의한 도메인의 가입 및 탈퇴와 관련되는 다양한 서브-프로토콜로 이루어진다.

이하는 OMA DRM 에서 정의되는 메인 엔티티 중 일부이다:

액터(actor) - 액터는 유즈 케이스 (use cases) 를 실행하는 외부 엔티티이다.

백업/원격 저장소 - RO 와 컨텐츠 오브젝트 (CO; content object) 를 원본 디바이스로 재전송할 의도로 상기 RO 와 CO 를 다른 위치로 전송한다.

결합 전달 - 보호 컨텐츠와 RO 를 전달하기 위한 OMA DRM 1.0 방법. 상기 RO 와 보호 컨텐츠는 단일 엔티티로, DRM 메시지와 함께 전달된다.

기밀성 - 인증되지 않은 개인, 엔티티, 또는 프로세스에 대해 정보가 사용가능하게 되지 않거나 또는 공개되지 않는 특성.

복합 오브젝트 (composite object) - 인클루젼 (inclusion) 을 통해 하나 이상의 미디어 오브젝트를 포함하는 CO.

접속형 디바이스 - 적절한 광역 전송/네트워크 계층 인터페이스를 통해 적절한 프로토콜을 사용하여 RI 에 직접 접속할 수 있는 디바이스.

컨텐츠 - 하나 이상의 미디어 오브젝트.

컨텐츠 발행자 (CI; content issuer) - DRM 에이전트에 대해 사용가능한 컨텐츠를 만드는 엔티티.

컨텐츠 제공자 - CI 또는 RI 인 엔티티.

디바이스 - DRM 에이전트를 구비한 사용자 기기. 이것은 접속형 디바이스 또는 비접속형 디바이스일 수 있지만, 접속형 디바이스는 RI 에 직접 접속할 수 있는 능력을 잃는 경우 비접속형 디바이스로 될 수 있기 때문에 이러한 구별은 문맥에 의존하고 사실상 가변이다.

디바이스 폐지 (device revocation) - RO 를 획득하는데 디바이스를 더 이상 신뢰할 수 없음을 나타내는 RI 의 프로세스.

디바이스 RO - 디바이스의 공개키를 통해 특정 디바이스에 전담된 RO.

도메인 - 도메인 RO 를 공유할 수 있는 디바이스 세트. 도메인 내의 디바이스들은 도메인 키를 공유한다. 도메인은 RI 에 의해 정의되고 관리된다.

도메인 식별자 - 도메인 키의 고유한 스트링 식별자.

도메인 키 - 128 비트 대칭 암호키.

DRM 에이전트 - 디바이스 상의 미디어 오브젝트에 대한 사용허가를 관리하는 디바이스 내의 엔티티.

DRM 컨텐츠 - RO 내의 사용허가 세트에 따라 소비되는 미디어 오브젝트들.

DRM 타임 - 안전한, 비-사용자 변경가능 타임 소스. DRM 타임은 UTC 타임 포맷이다.

무결성 - 데이터가 인증되지 않은 방식으로 변경되거나 또는 파괴되지 않는 특성.

도메인 가입 - 도메인에 디바이스를 포함하는 RI 의 프로세스.

도메인 탈퇴 - 도메인으로부터 비-폐지(non-revoked)된 디바이스를 배제하는 RI 의 프로세스.

미디어 오브젝트 - 디지탈 워크 또는 복합 오브젝트.

네크워크 서비스 제공자 - 모바일 디바이스를 위한 네트워크 접속을 제공하는 엔티티.

사용허가(permission) - DRM 컨텐츠에 대해 RI 에 의해 허용되는 실제 사용 또는 활동.

플레이 - 일시적인 인식가능한 리소스의 렌디션 (rendition) 을 생성하는 것.

보호 컨텐츠 - RO 내의 사용허가들의 세트에 따라 소비되는 미디어 오브젝트들.

복원 - 보호 컨텐츠 및/또는 RO 를 외부 위치로부터 그들이 백업되었던 디바이스로 재전송하는 것.

폐지 - 디바이스 또는 RI 인증서를 무효로 선언하는 프로세스.

권리 발행자 (RI; rights issuer) - RO 를 OMA DRM 순응 디바이스에게 발행하는 엔티티.

RI 컨텍스트 - RI ID, RI 인증서 체인, 버전, 알고리즘, 및 다른 정보와 같은 4-패스 등록 프로토콜 (4-pass Registration Protocol) 동안 주어진 RI 와 협상되었던 정보. RI 컨텍스트는, 디바이스가 등록 프로토콜을 제외하고, ROAP 슈트 (suite) 의 모든 프로토콜에 성공적으로 참여하기 위해 필요하다.

권리 오브젝트 (RO) - 보호 컨텐츠에 연결되어 있는 사용허가 및 다른 속성들의 모음.

권리 오브젝트 획득 프로토콜 (ROAP; Rights Object Acquisition Protocol) - 디바이스가 RI 로부터 RO 를 요구하여 획득할 수 있게 하는 프로토콜.

ROAP 트리거 - 디바이스에 의해 수신될 때, ROAP 를 개시하는 URL 을 포함하는 확장성 생성 언어 (XML; extensible markup language) 문서.

비상태형(stateless) 권리 - 디바이스가 상태 정보를 유지할 필요가 없는 RO.

상태형 (stateful) 권리 - RO 에서 표현되는 사용제약들 및 사용허가들이 올바르게 시행될 수 있도록 디바이스가 상태 정보를 명시적으로 RO 들에 대해 유지해야 한다. 다음의 사용제약들 또는 사용허가들 중 임의의 것을 포함하는 RO 가 고려된다 상태형 권리: <인터발(interval)>, <카운트(count)>, <타임-카운트(timed-count)>, <데이트타임(datetime)>, <어큐물레이티드(accumulated>, 또는 <엑스포트(export)>.

초배포(super-distribution) - (1) 사용자가 잠재적으로 불안한 채널을 통해 다른 디바이스로 보호 컨텐츠를 배포할 수 있게 하고, (2) 상기 디바이스의 사용자가 초배포된 보호 컨텐츠에 대한 RO 를 얻을 수 있게 하는 메카니즘.

비접속형 (unconnected) 디바이스 - 국부 접속 기술, 예를 들어, OBEX over IrDA (적외선 데이터 협정을 통한 오브젝트 교환; object exchange over infrared data association), 블루투스, 또는 USB 를 통해 적절한 프로토콜을 사용하여 접속형 디바이스를 통해 RI 에 접속할 수 있는 디바이스. 비접속형 디바이스는 DRM 타임을 지원할 수 있다.

사용자 - 디바이스의 인간 사용자. 사용자가 반드시 디바이스를 소유할 필요는 없다.

도 1 은 기존의 OMA DRM 2.0 기능적 아키텍처 (100) 의 개요이다. 상기 아키텍처 (100) 는 DRM 시스템 (102), 컨텐츠 제공자 (104), 및 사용자 (106) 로 이루어진다. DRM 시스템 (102) 은 CI (110), RI (112), DRM 에이전트 (114), 네트워크 저장소 (116), 및 탈착가능 미디어 (118) 를 포함한다. CI (110) 는 보호 컨텐츠 (122) 를 배포하고 RI (112) 는 RO (124) 를 배포한다. DRM 에이전트 (114) 는 보호 컨텐츠 (122) 를 재배포한다.

CI (110) 는 DRM 컨텐츠 (122) 를 전달하는 엔티티이다. OMA DRM 은 DRM 에이전트 (114) 로 전달될 DRM 컨텐츠 (122) 의 포맷, 및 상기 DRM 컨텐츠 (122) 가 상이한 전송 메카니즘을 사용하여 CI (110) 로부터 DRM 에이전트 (114) 로 전송될 수 있는 방법을 정의한다. CI (110) 는 DRM 컨텐츠 (122) 자체의 실제 패키징하거나 또는 다른 일부 소스로부터 미리-패키징된 (pre-packaged) 컨텐츠를 수신할 수 있다.

RI (112) 는 DRM 컨텐츠 (122) 에 사용허가 및 사용제약을 할당하고 RO (124) 를 생성하는 엔티티이다. RO (124) 는 DRM 컨텐츠 (122) 와 연관된 사용허가 및 사용제약을 표현하는 XML 문서이다. RO (124) 는 DRM 컨텐츠 (122) 가 사용될 수 있는 방법을 관리하고; DRM 컨텐츠 (122) 는 연관된 RO (124) 없이는 사용될 수 없고 그것과 연관된 RO(들) 에 의해 명시되는 대로 사용될 수 있을 뿐이다. DRM 컨텐츠는, 예를 들어, RO 가 시간 만료 (예를 들어, 10 일) 를 가지고 있다면, 하나보다 많은 RO 와 연관될 수 있고, 시간 만료 이후에 컨텐츠에 액세스하는데 새로운 RO 가 필요할 것이다.

DRM 에이전트 (114) 는 DRM 컨텐츠 (122) 의 소비지점 시행 (point-of-consumption enforcement) 을 관리하는 논리적인 엔티티이다. DRM 에이전트 (114) 는 디바이스의 신뢰가능한 컴포넌트를 구현하고, 디바이스 상의 DRM 컨텐츠 (122) 에 대한 사용허가 및 사용제약을 시행하고, 디바이스 (DRM 에이전트 (114) 를 통해 서만 액세스될 수 있음) 상의 DRM 컨텐츠에 대한 액세스를 제어하는 일을 담당한다.

DRM 컨텐츠 (122) 는 전달되기 전에 인가되지 않은 액세스(unauthorized access) 로부터 이를 보호하기 위해 패키징된다. CI (110) 는 DRM 컨텐츠 (122) 를 전달하고, RI (112) 는 RO (124) 를 생성한다. CI (110) 와 RI (112) 는 시스템 (102) 내에서 물리적인 엔티티보다는 논리적인 역할을 구현한다. 예를 들어, 하나의 전개예에서, 컨텐츠 소유자는 DRM 컨텐츠를 미리-패키징할 수 있고, 그 다음으로 상기 DRM 컨텐츠가 CI 와 RI 양자로 작용하는 컨텐츠 배포기에 의해 배포된다.

RO (124) 는 DRM 컨텐츠 (122) 가 사용될 수 있는 방법을 관리한다. DRM 컨텐츠 (122) 는 연관된 RO (124) 없이는 사용될 수 없고, RO (124) 에 의해 명시되는 사용허가와 사용제약에 따라서만 사용될 수 있다. OMA DRM 은 DRM 컨텐츠를 RO 로부터 논리적으로 분리한다. DRM 컨텐츠와 RO 는 개별적으로 또는 같이 요구될 수 있으며, 그들은 개별적으로 또는 동시에 전달될 수 있다. 동시에 전달되는 경우, 그들은 통상적으로 RO 및 DRM 컨텐츠 포맷 (DCF) 으로 구현된 컨텐츠와 함께, CI (110) 에 의해 제공된다.

RO (124) 는 키 세트에 의해 특정한 DRM 에이전트 (114) 에 암호기술적으로 바인딩되어 있고, 따라서 그 특정한 DRM 에이전트 (114) 만이 그것에 액세스할 수 있다. DRM 컨텐츠 (122) 는 유효한 RO (124) 에 의해서만 액세스될 수 있고, 따라서 DRM 컨텐츠 (122) 가 자유롭게 배포 또는 초배포될 수 있다.

OMA DRM 2.0 은 하나의 RO 가 DRM 에이전트의 그룹에 바인딩되는 것을 허용 한다. 이러한 그룹은 도메인으로 불리운다. 도메인에 배포된 DRM 컨텐츠와 RO 들은 그 도메인에 속하는 모든 DRM 에이전트에 의해 공유되어 오프라인 액세스될 수 있다. 예를 들어, 사용자는 전화와 PDA 양자에서의 사용을 위해 DRM 컨텐츠를 구입할 수 있다.

OMA DRM 규격은 DRM 컨텐츠 (또는 DCF) 에 대한 포맷과 보호 메카니즘, RO 에 대한 포맷 (권리 표현 언어(REL; rights expression language)) 와 보호 메카니즘, 및 암호화 키의 관리를 위한 보안 모델을 정의한다. OMA DRM 규격은 또한, 풀(pull) (HTTP 풀, OMA 다운로드), 푸쉬 (WAP 푸쉬, MMS), 및 스트리밍을 포함하는 범위의 전송 메카니즘을 사용하여 DRM 컨텐츠와 RO 들이 디바이스들로 전송될 수 있는 방법을 정의한다. 그러나, OMA DRM 규격은 네트워크 엔티티들 사이의, 예를 들어, CI (110) 와 RI (112) 사이의 어떠한 상호작용도 언급하지 않는다.

다음은 OMA DRM 2.0 규격에 의해 커버되는 유즈 케이스들의 완전하지 않은 (non-exhaustive) 리스트이다.

1. 기본 풀 (pull) 모델

사용자는 웹 사이트를 브라우징함으로써 다운로드할 컨텐츠를 선택하고, 구입 항목들을 확인한다. CI (110) 는 컨텐츠 (122) 를 식별하여 보호하며, 즉, 그것을 패키징한다. 상기 컨텐츠 (122) 는 컨텐츠 암호화 키 (CEK; content encryption key) 를 사용하여 암호화된다. 디바이스 능력은 광고된 MIME-타입 서포트 등을 사용하여 검출될 수 있다. RI (112) 는 컨텐츠 (122) 와 목표 DRM 에이전트 (114) 에 대해 RO (124) 를 생성한다. RO (124) 는 컨텐츠 거래와 CEK 를 위한 사용허가를 포함한다. 최종적으로, RO (124) 는 암호화 (RO 암호화 키, 또는 REK 를 사용) 및 전자 서명에 의해 암호기술적으로 보호되고, 목표 DRM 에이전트 (114) 에만 바인딩된다. 그 다음, DRM 컨텐츠 (122) 와 보호된 RO (124) 가 DRM 에이전트 (114) 로 전달된다.

2. DRM 컨텐츠의 푸쉬

대안적인 배포 모델은, 전술한 발견(discovery) 프로세스없이 멀티미디어 메시징 서비스 (MMS; multimedia messaging service), WAP 푸쉬, 또는 유사 방법을 사용하여 컨텐츠를 직접 푸쉬하는 것이다. 이러한 유즈 케이스에 대해 2 개의 변형예가 존재한다.

2A. 컨텐츠 푸쉬

CI (110) 및/또는 RI (112) 는 사용자와 특정한 DRM 에이전트 (114) 에 대한 특정 사전 지식을 가질 수 있고, 따라서 컨텐츠 (122) 와 RO (124) 는 전달을 위해 포맷되고 패키징될 수 있다.

2B. 푸쉬-개시된 풀

이 경우에, CI (110) 및/또는 RI (112) 는 사용자 또는 그들의 DRM 에이전트 (114) 에 대한 사전 지식을 갖지 않을 수 있지만, 여전히 컨텐츠 전달을 원할 수 으며, 예를 들어, 컨텐츠를 구입하도록 사용자를 유인하기 위해 사용자가 컨텐츠 (122) 를 미리보기 (preview) 할 수 있게 한다. DRM 컨텐츠 (122) 를 사용자에게 직접 푸쉬하는 대신, 컨텐츠에 대한 링크 또는 컨텐츠의 미리보기에 대한 링크가 전송될 수 있다. 링크를 따라감으로써 사용자는 특정한 위치에 도달할 것이고 다음 절차는 기본 풀 모델에서와 같이 계속된다.

3. DRM 컨텐츠의 스트리밍

기본 풀과 푸쉬 유즈 케이스들 양자는 컨텐츠가 전체적으로 패키징되어 전달되는 것을 가정한다. 대안으로, 상기 컨텐츠는 스트림으로서 패키징되어 전달될 수 있다. 이 경우에, 스트림 자체가 보호 (암호화) 된다. 암호화의 정확한 포맷은 OMA DRM 의 범위로부터 벗어났고 기존의 암호화 표준으로부터 선택될 수 있다. 상기 스트림들은 있을 수 있는 패킷 손실 등에 대처하기 위해, 다운로드에 대해 OMA 에 의해 명시된 것들과 상이한 암호화 방식에 의해 보호될 수 있다. 그러나, 스트림이 암호화된 후, 스트림에 대한 액세스는 개별 컨텐츠에 대해 이전에 서술된 것과 동일한 절차를 통해 제어될 수 있다. RO 가 생성되고, 스트림 암호화 키가 CEK 처럼 RO 내에 입력된 다음, RO 는 DRM 에이전트에 암호기술적으로 바인딩된다.

4. 도메인

도메인은 선택적인 특성 (feature) 으로 모든 RI 에 의해 지원되지 않을 수 있다. 도메인은 RO 와 CEK 가 특정한 DRM 에이전트 (114) 에 바인딩되어 있는 OMA DRM 2.0 의 기본 모델을 확장하고, RI (112) 가 권리와 CEK 를 단지 단일 DRM 에이전트 대신 DRM 에이전트 그룹에 바인딩할 수 있게 한다. 다음으로 사용자는 동일한 도메인에 속하는 모든 DRM 에이전트 사이에 오프라인으로 DRM 컨텐츠 (122) 를 공유할 수 있다. RI (112) 는 도메인 개념을 사용하여, 사용자들이 그들이 소유한 여러 디바이스로부터 DRM 컨텐츠 (122) 에 액세스할 수 있게 하는 것과 같은 새로운 서비스를 제공할 수 있고, 또는 사용자가 하나의 디바이스 (예를 들어, PC) 를 통 해 DRM 컨텐츠와 권리를 구입하여 다른 디바이스 (예를 들어, 휴대가능한 플레이어) 상에서 나중에 사용하도록 비접속형 디바이스들에 대한 지원을 제공할 수 있다.

5. 백업

DRM 컨텐츠 (122) 는 탈착가능한 미디어 (118), 네트워크 저장소 (116), 또는 다른 형태의 저장소에 저장될 수 있다. DRM 컨텐츠 (122) 는 암호화된 형태로 저장되고 연관된 RO (124) 를 사용하는 특정한 목표 DRM 에이전트 (114) 에 의해서만 액세스될 수 있다. RO (124) 가 비상태형(stateless) 사용허가만 포함한다면, 상기 RO (124) 는 백업 목적으로 저장될 수 있다. 보안 모델은, RO (124) 가 오프-디바이스에 저장되어 있을지라도, RO (124) 가 보호되어 의도된 DRM 에이전트 (114) 에 의해서만 액세스될 수 있음을 보장한다. 일부 사용허가는 DRM 에이전트 (114) 에 의한 상태 (state) 의 유지, 예를 들어, 제한된 플레이 횟수를 요구한다. 이러한 RO 는 상태 정보의 손실을 초래할 수 있기 때문에, 오프-디바이스에 저장될 수 없다.

6. 초-배포

DRM 컨텐츠 (122) 는 복사되어 다른 DRM 에이전트 (114) 로 전송될 수 있으며, 예를 들어, 사용자가 DRM 컨텐츠 (122) 를 친구에게 보낼 수 있다. 친구는, 상기 컨텐츠 (122) 에 액세스하기 위해, DRM 컨텐트 패키지 내의 링크를 통해 RI (112) 에 도달하여 RO (124) 를 획득한다.

7. (비-OMA DRM 시스템으로) 엑스포트(export)

DRM 컨텐츠 (122) 는, OMA DRM 을 준수하지 않는 디바이스에서의 사용을 위해, 다른 DRM 시스템으로 엑스포트될 수 있지만, 일부 다른 DRM 메카니즘은 지원하지 않는다. OMA DRM 아키텍처는 RI (112) 들이, 원한다면, DRM 에이전트 (114) 를 위한 사용허가를 표현할 수 있게 하여, 특정한 다른 DRM 시스템에 의해 명시되는 대로, 그 특정한 다른 DRM 시스템으로의 변환을 수행하게 한다. RI (112) 는 특정한 외부 DRM 시스템에 대해서만 엑스포트를 제한할 수 있다.

8. 비접속형 디바이스들의 서포트

OMA DRM 은 접속형 디바이스가 중개자로서 작용하게 하여 컨텐츠 (122) 와 RO (124) 를 구입하여 다운로드하도록 비접속형 디바이스를 보조한다. 사용자는, 예를 들어, 네트워크 접속성을 갖지 않는 OMA DRM 준수 휴대가능 디바이스 (비접속형 디바이스), 및 네트워크 접속성을 갖는 OMA DRM 준수 모바일 디바이스 (접속형 디바이스) 를 가질 수 있다. 접속형 디바이스를 사용하여 브라우즈하고 DRM 컨텐츠 (122) 를 구입하여 DRM 컨텐츠 (122) 를 접속형 디바이스로 다운로드한 이후에, 사용자는 상기 DRM 컨텐츠 (122) 를 비접속형 디바이스 상에서 플레이하기를 원할 수도 있다. 이 경우에, 접속형 디바이스 상의 DRM 에이전트 (114) 는 RI (112) 로부터 도메인 RO (124) 를 요구하여 다운로드한다.

그 다음, 접속형 디바이스 상의 DRM 에이전트 (114) 는 도메인 RO (124) 를 DCF 에 내장한다. 그 다음으로 DCF 는 국부 접속 기술, 예를 들어, 블루투스 또는 USB 를 통해 적절한 프로토콜을 사용하여 비접속형 디바이스로 전송될 수 있다. 접속형 디바이스와 비접속형 디바이스 양자는 이러한 기능을 지원하기 위해 OMA DRM 을 준수해야 한다. 또한, 비접속형 디바이스는 접속형 디바이스와 동일한 도메인에 속해야 한다.

보안 및 신뢰

다음은 OMA DRM 2.0 보안 및 신뢰 대책의 개요이다. 일반적으로, DRM 솔루션은 2 개의 보안 요건을 충족해야 한다: (1) 보호 컨텐츠는 적절하게 인증되고 인가된 DRM 에이전트에 의해서만 액세스되어야 하고; (2) 모든 DRM 에이전트는 보호 컨텐츠에 대한 사용허가를 이행해야 한다. DRM 컨텐츠와 연관된 사용허가와 사용제약의 시행은 임의의 DRM 방식의 보안 및 신뢰 대책의 주요한 관심이다. 연관된 RO 에 의해 규정되어 있는 것을 넘어 DRM 컨텐츠에 대한 인가되지 않은 액세스, 불법 복사본의 생성, 및 DRM 컨텐츠의 재배포는 임의의 DRM 시스템에 대한 주요한 위협을 구성한다.

OMA DRM 시스템은 OMA 환경에서 보호 컨텐츠의 안전한 배포와 관리를 위한 수단을 제공하고 위에 명시된 요건을 충족한다. OMA DRM 은 RO 의 사용제약 하에서 컨텐츠의 보호 사용을 보장하는 DRM 에이전트를 사용함으로써 소비지점에서 컨텐츠와 RO 의 사용과 보호를 시행한다.

DRM 컨텐츠를 배포하기 위한 기본적인 단계들은 다음과 같이 요약될 수 있다:

1. 컨텐츠 패키징. 컨텐츠가 안전한 컨텐츠 컨테이너 (DCF) 내에 패키징된다. DRM 컨텐츠는 대칭적인 컨텐츠 암호화 키 (CEK) 에 의해 암호화된다. 상기 컨텐츠는 미리-패키징될 수 있으며, 즉, 컨텐츠 패키징은 작동 중에 (on the fly) 발 생해서는 않된다. OMA DRM 에서의 요건은 아닐지라도, 동일한 CEK 가 컨텐츠 조각(a piece of content)의 모든 인스탄스 (instance) 들에 대해 사용되지 않는다.

2. DRM 에이전트 인증. 모든 DRM 에이전트는 고유의 비밀키/공개키 쌍 및 인증서를 갖는다. 인증서는 디바이스 제조자, 디바이스 타입, 소프트웨어 버전, 시리얼 번호, 등과 같은 부가적인 정보를 포함한다. 이에 따라 CI 와 RI 는 안전하게 DRM 에이전트를 인증할 수 있다.

3. RO 생성. RO 는 DRM 컨텐츠가 연관 RO 없이는 사용될 수 없음을 보장하는 CEK 를 포함한다. RO 는 사용허가 (예를 들어, 플레이, 디스플레이, 및 실행) 및 사용제약 (예를 들어, 한 달 동안의 플레이, 10번의 디스플레이) 으로 구성되어 있다. RO 는 또한 컨텐츠에 액세스될 때 특정 사용자 (예를 들어, 사용자 신원(identity)에 의해 결정됨) 가 있을 것을 요구하는 사용제약을 포함한다. 이들 사용허가와 사용제약은, RO 에 포함된 다른 정보 (예를 들어, 저작권 정보) 와 함께, 사용자에게 제공될 수 있다.

4. RO 보호. RO 를 전달하기 전에, RO 의 민감한 부분 (CEK 와 같은) 은 권리 암호화 키 (REK) 를 사용하여 암호화된 다음, RO 가 목표 DRM 에이전트에 암호기술적으로 바인딩된다. 이에 의해 목표 DRM 에이전트만이 RO, CEK, 및 DRM 컨텐츠에 액세스할 수 있음이 보장된다. 게다가, RI 는 RO 에 전자 서명한다. RO 는 또한 CEK 를 포함함으로써 DRM 컨텐츠에 대한 액세스를 관리한다. OMA DRM 권리 표현 언어 (REL) 는 DRM 컨텐츠의 사용을 관리하는 사용허가와 사용제약의 구문(syntax)(XLM) 과 문법 (semantics) 을 명시한다. RO 는 그것 자신의 MIME 컨텐 츠 타입을 갖는다.

5. 전달. RO 와 DCF 는 이제 목표 DRM 에이전트로 전달될 수 있다. 양자의 아이템들은 본질적으로 안전하므로, 그들은 임의의 전송 메카니즘 (예를 들어, HTTP/WSP, WAP 푸쉬, MMS) 를 사용하여 전달될 수 있다. RO 와 DCF 는 예를 들어, MIME 멀티파트 메시지로, 함께 전달될 수 있고 또는 개별적으로 전달될 수 있다.

RO 를 위한 OMA DRM 신뢰 모델은 공개키 인프라스트럭처 (PKI) 에 기초하고, 그럼으로써 참여자 (principal), 검증자 (verifier), 및 양자에 의해 인식되고 신뢰되는 하나 이상의 인증 기관의 그룹들이 존재한다. 단일 엔티티는 선택된 컨텍스트와 솔루션의 필요에 의존하여 참여자와 검증자로서 양자의 역할을 할 수 있다. PKI 에 의해 검증자는 참여자의 신원과 다른 속성들을 그들이 개방된 안전하지 않은 네트워크를 통해 통신할 때 인증할 수 있다. 이러한 시스템에서, 통상적으로, 검증자는 인증 목적으로 검증자가 상호작용하는 참여자들에 대한 민감한 어떠한 정보도 유지할 필요가 없다. 게다가, 인증 기관 (CA; Certification Authority) 은 참여자와 검증자 사이의 거래에 직접적으로 관여되지 않는다. DRM 에이전트의 인증서가 RI 에 의해 검증가능하고 폐지되지 않았다면 RI 는 DRM 에이전트가 올바르게 행동할 것으로 신뢰한다. 유사하게, RI 의 인증서가 DRM 에이전트에 의해 검증가능하고 폐지되지 않았으면 DRM 에이전트는 RI 가 올바르게 행동할 것으로 신뢰한다.

OMA DRM 에 인가되는 PKI 의 일차 (primary) 엔티티들은 CA, 디바이스들 및 RI 들이다. OMA DRM 의 인증 및 키 전송 프로토콜은 RI가 디바이스를 인증할 수 있도록 그리고 디바이스가 RI 를 인증할 수 있도록 요구한다. 이러한 상호 인증은 ROAP 에 의해 달성된다.

게다가, 디바이스들은 디바이스 공개키와 비밀키 및 적절한 CA 를 사용하여 서명된 연관 인증서와 함께 (제조시 또는 이후에) 준비되는 것으로 가정된다. RI 에 의해 표현되는 인증서 선호에 기초하여, 디바이스는 적절한 인증서를 제공해야 한다. 디바이스들은 무결성 및 기밀성 보호되도록 비밀키를 국부 저장소에 저장해야 한다.

RI 들에는 또한 공개키, 비밀키, 및 CA 에 의해 서명된 인증서들이 제공된다. 인증서 체인 (하나의 CA 에 의해 서명된 공개키 소유자의 인증서 및 다른 CA 에 의해 서명된 CA 들의 제로 또는 이상의 부가적인 인증서들을 포함하는 다수의 인증서들의 체인) 은 신뢰하는 인증서 체인의 확인을 위한 인증 프로토콜의 시점에서 디바이스에 제공된다.

다수의 CA 가 DRM 시스템에 존재할 수 있음에 유의해야 한다. ROAP 프로토콜은 RI 인증서에 서명하는 CA 가 프로토콜의 실행 동안의 사용을 위해 온라인 인증 상태 프로토콜 (OCSP; Online Certification Status Protocol) 응답기를 실행할 것을 요구한다. CA 들에게는 또한 발행된 인증서들의 사용을 관리하는 적절한 인증서 정책을 정의할 것이 요구된다.

다음은 OMA DRM 보안의 주요 양태를 서술한다.

1. 데이터가 인가되지 않은 상대방에 의해 액세스 가능하지 않다는 것을 보장하는 기밀성. 상술한 바와 같이, 보호 컨텐츠는 적절하게 인증되고 인가된 DRM 에이전트에 의해서만 액세스 가능해야 한다. 이러한 목적을 달성하기 위해, 보호 컨텐츠는 암호화된다. 암호화 키들은 각각의 미디어 오브젝트에 대해 고유하고, RO 들은 의도된 수령자에 의해서만 액세스 가능한 키에 포장된 암호화 키를 운반한다.

2. 일 상대방이 다른 상대방에 대해 그 자체를 식별하는 프로세스인 인증. OMA DRM 에서는, 상호적인 DRM 에이전트와 RI 인증이 4-패스 등록 프로토콜, 2-패스 RO 획득 프로토콜, 및 2-패스 도메인 가입 프로토콜에서 달성된다. 사용되는 프로토콜과 송신되는 메시지에 의존하여, 넌스들 (nonces) 또는 타임 스탬프 (time stamps) 에 대한 전자 서명을 통해 인증된다. 1-패스 RO 획득 프로토콜은 타임 스탬프에 대한 전자 서명을 통해 RI 인증한다. 그것은 RI 에 대해 DRM 에이전트를 인증하지 않지만, 보호 컨텐츠가 수령자의 공개키를 사용하여 포장되어 있기 때문에, 키 바인딩을 통해 간접적으로 인증된다. 2-패스 도메인 탈퇴 프로토콜은 타임 스탬프에 대한 전자 서명을 통해 RI 에 대해 DRM 에이전트를 인증한다. 그것은 DRM 에이전트에 대해 RI 를 인증하지 않는다. RI 들은 RO 들의 전달 동안 DRM 에이전트에 대해 자신들을 인증하도록 요구된다. 이것은 RI 의 인증성에 대한 일정 수준의 보증을 제공한다.

3. 데이터 무결성 보호 (Data Integrity Protection) 는 인가되지 않은 데이터의 변형을 검출하는 능력을 보장한다. OMA DRM 에 있어서, 데이터 무결성 보호는, 적용가능할 때, ROAP 메시지들과 RO 들 상의 전자 서명을 통해 달성된다.

4. 키 확인 (Key Confirmation) 은 메시지 송신기가 키 값을 알고 있는 보호키를 포함하는 메시지의 수령을 보장한다. DRM 컨텍스트에 있어서, 이러한 특성은 하나의 RI 로부터 다른 것에 의한 RO 들의 인가되지 않은 재-발행에 대해 보호한 다. OMA DRM 시스템에 있어서, 키 확인은 미디엄 액세스 제어 (MAC; medium access control) 를 통해 보호되는 키의 일부를 MAC 키로서 사용함으로써, 보호되는 키 및 송신측의 신원을 통해 달성된다.

DRM 에이전트는 RI 에 의해 올바른 행동 및 안전한 실행의 양면에서 신뢰되어야 한다. OMA DRM 에서, 각각의 DRM 에이전트에는 고유한 키 쌍 및 연관된 인증서가 준비되어, DRM 에이전트를 식별하고 상기 에이전트와 상기 키 쌍 사이의 바인딩을 인증한다. 이에 따라 RI 들이 표준 PKI 절차를 사용하여 DRM 에이전트를 안전하게 인증할 수 있다.

RI 는 인증서 내의 정보를 사용하여 그것의 비지니스 규칙, 그것의 컨텐츠의 값, 등에 기초하여 정책을 적용할 수 있다. 예를 들어, RI 는 어떤 제조업자를 신뢰할 수 있고, 또는 RI 에 의해 정의된 어떤 기준에 따라 신뢰할 수 있음 또는 신뢰할 수 없음으로 알려져 있는 갱신된 DRM 에이전트의 리스트를 유지할 수 있다.

DRM 컨텐츠 포맷 (DCF; DRM content format) 은 그것 소유의 MIME 컨텐츠 타입을 갖는, 암호화된 컨텐츠를 위한 안전한 컨텐츠 패키지이다. 암호화된 컨텐츠에 부가하여, 그것은 컨텐츠 설명 (원본 컨텐츠 타입, 판매인, 버전, 등), RI URI (uniform resource identifier)(RO 가 얻어질 수 있는 위치), 등과 같은 부가적인 정보를 포함한다. 이러한 부가적인 정보는 암호화되지 않고, RO 가 검색되기 이전에 사용자에게 제공될 수 있다. DCF 내부에서 DRM 컨텐츠를 잠금해제하기 위해 요구되는 CEK 는 RO 내에 포함되어 있다. 따라서, RO 없이 DRM 컨텐츠에 액세스할 수 없고, DRM 컨텐츠는 RO 에서 명시된 대로만 사용될 수 있다. OMA DRM 은, DRM 에이 전트가 DCF 의 무결성을 입증할 수 있게 하고, 인가되지 않은 엔티티에 의한 컨텐츠의 변형에 대해 보호하는 메카니즘을 포함한다.

OMA DRM 시스템은 DRM 에이전트 내의 DRM 타임의 존재를 가정한다. 사용자들은 DRM 타임을 변경할 수 없으므로, DRM 타임이 OCSP 응답기에 의해 유지되는 시간과 동기화될 수 있는 메카니즘이 정의된다. RO 를 위한 전달 프로토콜의 일부 양태 뿐만 아니라 일부 사용제약 (예를 들어, 절대 시간 사용제약) 은 안전한 시간 소스를 갖는 DRM 에이전트에 의존한다. OMA DRM 규격의 문맥에서 DRM 타임은 사용자들에 의해 변경할 수 없는 시간 값 뿐만 아니라 정확한 시간을 의미한다. OMA DRM 규격은 필요할 때, 예를 들어, 오랜 정전 (power failure) 이후에 DRM 타임이 소실되면, DRM 타임이 동기화되는 메카니즘을 제공한다. 일부 제한된-능력 비접속형 디바이스들은 실시간 클럭을 지원하지 않을 수 있고, 그에 따라 DRM 타임을 지원하지 않을 수 있다. 그러나, 접속형 디바이스들은 DRM 타임을 지원해야 한다.

OMA DRM 은 RO 재전송 보호 공격에 대항하여 보호한다. RO 재전송 공격의 일례는 DRM 에이전트로의 전달 동안 제한된 전송 횟수로 중개자가 RO 를 차단하는 것이다. 권리가 DRM 에이전트에 대해 만료되면, 차단된 RO 가 중개자로부터 다시 전달 (재전송) 될 수 있다. OMA DRM 은 이들 및 유사 공격이 발생하는 것을 방지한다.

OMA DRM 시스템은 위에 리스트된 보안 메카니즘의 사용을 통해 애플리케이션-계층 보안을 제공한다. 그러므로, 그것은 전송 계층 보안에 의존하지 않거나 또는 가정하지 않는다.

ROAP 는 RO 들에 관한 정보의 안전한 인증-기반 교환을 허용하는데 있어서 OMA DRM 2.0 에서 중요한 역할을 한다. ROAP 는 디바이스에서 RI 와 DRM 에이전트 사이의 DRM 보안 프로토콜의 슈트 (suite) 에 대한 공통 명칭이다. 상기 프로토콜 슈트는 여러 개의 서브-프로토콜을 포함한다:

1. 도 2 에 도시된 바와 같이, RI 에 디바이스를 등록하기 위한 4-패스 프로토콜.

2. 도 3 에 도시된 바와 같이, 2-패스 RO 획득 프로토콜은 RO 의 요구 및 전달을 포함한다.

3. 도 4 에 도시된 바와 같이, 1-패스 RO 획득 프로토콜은 RI 로부터 디바이스까지의 RO 의 전달 (예를 들어, 메시징/푸쉬) 과 관련되어 있다.

4. 도 5 에 도시된 바와 같이, 도메인에 가입하려는 디바이스를 위한 2-패스 도메인 가입 프로토콜.

5. 도 6 에 도시된 바와 같이, 도메인을 탈퇴하려는 디바이스를 위한 2-패스 도메인 탈퇴 프로토콜.

도 2 는 4-패스 등록 프로토콜 (200) 의 흐름도이다. 프로토콜 (200) 은 디바이스 (202), RI (204), 및 OCSP 응답기 (206) 를 활용한다. 디바이스 (202) 는 디바이스 헬로우 메시지 (Device Hello message) 를 전송함으로써 RI (204) 와의 접촉을 (가능하면 ROAP 트리거의 수신시) 개시하며 (단계 210), 상기 디바이스 헬로우 메시지는 디바이스 ID (RI (204) 가 OCSP 응답기(206)로 나중에 체크할 수 있는 디바이스의 인증서의 해쉬) 및 다른 정보를 포함한다. 표 1 은 디바이스 헬로우 메시지 내의 주요한 컴포넌트를 나타낸다. 디바이스 헬로우 메시지 내의 어떠한 정보도 무결성 보호되지 않으며, 즉, 메시지에 대한 서명이 없다.

RI (204) 는, 디바이스 헬로우 메시지 (단계 201) 에 응답하여, RI 헬로우 메시지 (RI Hello message)를 디바이스 (202) 로 보내고 (단계 212), 상기 RI 헬로우 메시지는 RI 의 인증서 크리덴셜 (RI ID 의 형태로), 일부 세션 관련된 (반대-응답-목적; anti-reply-purpose) 넌스 및 세션 넘버와 같은 정보, 및 RI (204) 가 인식하는 디바이스에 대한 신뢰 체인의 정보와 같은 선택적인 다른 정보를 포함한다. 표 2 는 RI 헬로우 메시지의 포맷을 나타낸다. RI 헬로우 메시지 내의 어떠한 정보도 무결성 보호되지 않음에 유의해야 한다.

RI 헬로우 메시지에 포함된 정보를 성공적으로 검증하면, 디바이스 (202) 는 등록 요청 메시지 (Registration Request message) 를 보내고 (단계 214), 상기 등록 요청 메시지는 요청 시간, 세션 ID 및 서명과 같은 필수적인 정보, 및 인증서 체인, 신뢰 RI 기관 앵커, 익스텐션 (extension) 등과 같은 선택적인 정보를 포함한다. 표 3 은 등록 요청 메시지의 포맷을 나타낸다. 등록 요청 메시지는 등록 요청 메시지 내의 서명 필드 (Signature field) 까지의 디바이스 (202) 와 RI (204) 사이에서 교환된 모든 메시지의 전자 서명을 그의 말단에 포함하며, 즉, 전체 디바이스 헬로우 메시지, 전체 RI 헬로우 메시지, 및 서명 필드까지 (배제하는) 의 등록 요청 메시지의 필드의 전자 서명을 포함한다. 이러한 전자 서명은 디바이스의 비밀키를 사용하여 이루어진다. 전자 서명을 포함함으로써 연관 ROAP 메시지의 무결성 보호를 제공한다.

디바이스 (202) 가, 익스텐션 내의 정보를 통해, OCSP 검증이 필요하지 않거나 또는 지원되지 않는 것을 나타내지 않으면, RI (204) 는 OCSP 요청 메시지 (OCSP Request message)를 OCSP 응답기 (206) 로 보내어 (단계 216) 디바이스 (202) 가 RI (204) 로 공급하는 정보의 검증을 요청한다. OCSP 응답기 (206) 는 요청 메시지 내의 정보를 찾아 정보의 검증을 시도하고, 요청의 결과를 포함하는 OCSP 응답 메시지를 돌려 보낸다 (단계 218).

RI (204) 는 등록 응답 메시지 (Registration Response message) 를 디바이스 (202) 로 보내는데 (단계 220), 상기 등록 응답 메시지에는 등록이 성공적이었는지 또는 성공적이지 않았는지의 표시 및 다른 정보가 포함된다. 표 4 는 등록 응답 메시지의 포맷을 나타낸다. 등록 응답 메시지는 등록 요청 메시지의 SHA-1 해쉬 및 등록 응답 메시지 (서명 필드를 제외한 상기 서명 필드까지) 를 그의 말단에 포함한다. 이러한 전자 서명은 RI 의 비밀키를 사용하여 만들어진다. 전자 서명을 포함함으로써 연관 ROAP 메시지의 일부 무결성 보호를 제공한다. 전자 서명에 대해 SHA-1 해쉬가 사용되고 있지만, 전자 서명을 적용하기 위한 임의의 적당한 알고리즘이 사용될 수 있음에 유의해야 한다.

도 3 은 2-패스 RO 획득 프로토콜 (300) 의 흐름도이다. 프로토콜 (300) 은 디바이스 (202) 와 RI (204) 를 사용하고, 4-패스 등록 프로토콜 (200) 이 완료되고 디바이스 (202) 가 RI (204) 에 대한 유효 인증서 체인을 수신한 이후에 동작한다. 프로토콜 (300) 은 RI (204) 로부터의 RO 를 요청하기 위해 디바이스 (202) 에 의해 사용된다. 디바이스 (202) 는 RO 요청 메시지 (RO Request message) 를 RI (204) 로 보내어 RO 를 요청한다 (단계 310). 표 5 는 RO 요청 메시지의 포맷을 도시한다. RO 요청 메시지는 메시지 (서명 필드를 배제) 의 전자 서명을 포함한다.

RI (204) 는, 요청 메시지에 응답하여, RO 응답 메시지 (RO Response message) 를 디바이스 (202) 로 보낸다 (단계 312). RO 응답 메시지는 RO 를 포함하거나 또는 RO 가 송신되지 않을 것을 나타내는 표시를 포함한다.

표 6 은 RO 응답 메시지의 포맷을 도시한다. RO 응답 메시지는, 성공적인 상태의 경우에, 서명 필드를 배제한, RO 요청 메시지 및 RO 응답 메시지의 SHA-1 해쉬인 전자 서명을 포함한다.

도 4 는 1-패스 RO 획득 프로토콜 (400) 의 흐름도이다. 프로토콜 (400) 은 디바이스 (202) 와 RI (204) 를 활용한다. 프로토콜 (400) 에 있어서, RI (204) 는, 디바이스 (202) 에 의한 요청없이, RO 를 포함하는 디바이스 (202) 로 RO 응답 메시지를 일방적으로 보낸다 (단계 410). 프로토콜 (400) 은 예를 들어, 푸쉬 유즈 케이스에 적용한다. 표 7 은 RO 응답 메시지의 포맷을 도시한다.

도 5 는 2-패스 도메인 가입 프로토콜 (500) 의 흐름도이다. 프로토콜 (500) 은 디바이스 (202) 와 RI (204) 를 활용한다. 디바이스 (202) 가 도메인에 가입하기 원하면, 디바이스 (202) 는 도메인 가입 요청 메시지 (Join Domain Request message) 를 RI (204) 로 보낸다 (단계 510). RI (204) 는 상기 요청을 평가하여 도메인 가입 응답 메시지 (Join Domain Response message) 를 디바이스 (202) 로 보낸다 (단계 512). 표 8 은 도메인 가입 요청 메시지의 포맷을 도시하고, 표 9 는 도메인 가입 응답 메시지의 포맷을 도시한다.

도 6 은 2-패스 도메인 탈퇴 프로토콜 (600) 의 흐름도이다. 프로토콜 (600) 은 디바이스 (202) 와 RI (204) 를 활용한다. 디바이스 (202) 가 도메인에서 탈퇴하기를 원하면, 디바이스 (202) 는 도메인 탈퇴 요청 메시지 (Leave Domain Request message) 를 RI (204) 로 보낸다 (단계 610). RI (204) 는 요청을 평가하여 도메인 탈퇴 응답 메시지 (Leave Domain Response message) 를 디바이스 (202) 로 보낸다 (단계 612). 표 10 은 도메인 탈퇴 요청 메시지의 포맷을 도시하고, 표 11 은 도메인 탈퇴 응답 메시지의 포맷을 도시한다.

1-패스 RO 획득 프로토콜을 제외하고 ROAP 슈트에 포함되는 모든 프로토콜들은 ROAP 트리거를 사용하여 개시될 수 있다. 디바이스 (202) 는 또한 사용자 상호작용의 결과로서 프로토콜들을 일방적으로 개시할 수 있다. RI (204) 는 ROAP 트리거를 생성하여 디바이스 (202) 로 보내 ROAP 프로토콜 교환을 트리거한다. 대안으로, RI (204) 는 다른 시스템에게 필요한 정보 (RO 식별자와 도메인 식별자와 같은) 를 제공함으로써 ROAP 트리거 생성을 다른 시스템에게 위임할 수 있다. ROAP 트리거 (직접 발생되거나 또는 RI (204) 에 의해 간접적으로 발생되는) 는 또한 다른 시스템 (예를 들어, CI) 에 의해 디바이스 (202) 로 전송될 수 있다.

디바이스 (202) 는 ROAP 트리거를 수신하면, 가능한 한 빨리 ROAP 프로토콜 교환을 개시한다. ROAP 트리거의 수신의 결과로서 임의의 ROAP 프로토콜을 개시하기 이전에 적절한 사용자 동의가 얻어져야 한다. ROAP 는 여러 개의 프로토콜로 이루어지므로, ROAP 트리거는 디바이스 (202) 에 의해 시작될 실제 프로토콜 (예를 들어, 등록, RO 획득, 도메인 가입, 또는 도메인 탈퇴) 의 표시를 포함한다.

ROAP 메시지들과 상기 메시지들이 프로토콜들에 의해 다루어지는 방법은 RO 들과 이들의 연관된 프로세싱 뿐만 아니라, RO 들과 OMA DRM 2.0 을 둘러싸는 보안 기능들을 제공한다. 보다 구체적으로, 다음의 보안 및 신뢰 양태는 ROAP 프로토콜에 의해 언급되어 있다.

1. RI 와 디바이스 사이의 상호 인증;

2. 다양한 메시지 내의 넌스들을 사용함으로써 재전송 공격 (replay attack) 에 대항(countering);

3. ROAP 메시지들 또는 ROAP 메시지들 중 일부의 무결성을 보호함; 및

4. ROAP 메시지들 또는 ROAP 메시지들 중 일부에서의 안전한 DRM 타임의 검증.

트러스티드 컴퓨팅 기술

최근에, 트러스티드 컴퓨팅 그룹 (TCG; Trusted Computing Group) 의 기술 범위 하에서, 트러스티드 컴퓨팅 기술이 문헌과 제품에 출현하고 있다. 상기 TCG 기술은 컴퓨팅 엔티티들이 신뢰 체인의 사용을 통해 그들 자신 및 다른 디바이스들에 대한 신뢰성을 확립할 수 있는 방법을 제공하며, 따라서 이러한 디바이스들 상에서의 프로세싱 또는 컴퓨팅은:

1. 플랫폼과 다양한 하드웨어 (HW) 와 소프트웨어 (SW) 컴포넌트들의 신뢰성을 위해 액세스될 수 있고;

2. 적절한 신뢰 레벨이 확립되어 있을 때만 검증될 수 있고 외부 요청시 그 자체와 다른 것들을 위해 검증될 수 있고; 또한

3. 외부 상대방들은 상기 목표 디바이스들의 명백한 신뢰 레벨에 기초하여 다른 디바이스들과의 정보 및 프로세싱의 교환을 평가하여 결정할 수 있다.

TCG 는 다음의 특징을 갖는 트러스티드 프로세싱 모듈 (TPM; Trusted Processing Module) 로 불리우는 핵심 프로세싱 모듈을 정의한다:

1. 모듈과 그것의 인터페이스의 물리적인 보호;

2. 보호되는 휘발성 및 비휘발성 저장 공간;

3. 암호화와 전자 서명을 수행할 수 있는 모듈 내부의 보호되는 암호기술 기능들;

4. 해쉬 확장 (hash extending) 에 의해 플랫폼의 "상태" 와 그것의 SW 컴포넌트들을 연속적으로 포획하는 플랫폼 구성 레지스터 (PCR; Platform Configuration Registers) 의 사용;

5. 디바이스의 인증의 근거로서 작용하지만 직접적인 방법은 아닌 PKI 에 기초하는, 디바이스 특정의 안전한 승인 키 (EK; Endorsement Keys) 의 존재. EK 는 결코 외부에 노출되지 않지만, 증명 확인키 (AIK; Attestation Identity Keys) 로 불리우는 그것의 별칭(aliases)들이 플랫폼의 무결성 측정값들에 서명하는데 사용된다; 또한

6. AIK 에 의해 서명된 PCR 값들과 관련하여, 메모리 "블로브(blobs)" 내의 데이터의 "날인(sealing)" 의 사용, 따라서 (TPM 으로부터의 PCR 값들과 날인된 메모리 블로브로부터의 값을 매칭함으로써 측정되어 검증되는) 플랫폼 또는 SW 무결성이 검증될 때만 데이터가 액세스되거나 또는 추출될 수 있다.

트러스티드 컴퓨팅 기술들이, 특히 모바일 폰 다바이스의 맥락에서, 상기 모바일 디바이스 상의 DRM 애플리케이션을 보호할 때 가능한 애플리케이션을 위해 검사되었다. TCG 기술의 사용에 의해 DRM 어플리케이션을 보호하기 위한 이전에 제안된 방법들은, TPM 에서 그리고 키 보호를 갖는 저장 영역에서 TCG 키들을 사용하는 ROAP 프로토콜 프로세싱 이후에 DRM 관련된 데이터를 안전하게 저장하기 위해 TPM 날인과 메모리 블로브의 절차를 사용하는 방법들을 포함하였다.

그러나, 기존의 종래 기술은 플랫폼 및/또는 DRM 소프트웨어 상에 "신뢰" 를 확립하여 사용하는 방법을 순서대로 언급하지도 않고 명확하게 언급하지도 않는다. 종래기술에서는, OMA DRM 2.0 시스템에서 무결성 프로세싱을 강화하기 위해, ROAP 메시지의 무결성을 보호하는 특정한 기술을 언급하지 않는다. 본 발명은 상기 목적을 위한 새로운 기술을 포함한다.

현재의 OMA DRM 2.0 규격은 CA, RI 및 디바이스를 포함하는 PKI 에 기초하는 강력한 보안 방법을 제공한다. 그러나, OMA DRM 2.0 규격 자체 내에서 플랫폼, SW, 에이전트 및 메시지의 보안 및 무결성과 관련되는 취약성이 존재하고, OMA DRM 2.0 에 따르는 디바이스들과 RI 들의 명시되지 않은 구현과 관련되는 취약성이 존재한다.

OMA DRM 규격은, 임의의 디바이스 또는 RI 가 OMA DRM 2.0 규격을 준수하고 있을 때에도, 디바이스 또는 RI 가 직면할 수 있는 다양한 위협 및 취약성을 알고 있다. 이들 취약성은:

1. 공격자가 DRM 시스템의 엔티티를 물리적으로 또는 다른 방식으로 손상시키려고 시도할 수 있는, 엔티티 손상(compromise). 엔티티 손상 공격의 타입들은 디바이스 상의 DRM 에이전트 및 RI 내의 DRM SW 를 손상시키는 것을 포함한다. 엔티티 손상의 결과는, 예를 들어 DRM 에이전트의 재전송 캐쉬의 무결성 보호의 손실 및/또는 DRM 에이전트에 내부적으로 저장된 권리 보호의 손실 뿐만 아니라, 비밀키, 도메인 키, RO 암호화 키, 컨텐츠 암호화 키 및 보호 컨텐츠의 노출을 포함한다. 또한, DRM 타임의 손실도 발생할 수 있다. 손상된 CA 또는 OCSP 응답기의 PKI 에 대한 영향은 IETF RFC3280 과 같은 참조문헌에 논의되어 있다.

OMA DRM 시스템은 손상된 엔티티에 의해 초래되는 손해를 최소화하기 위해 인증서 폐지에 의지한다. DRM 에이전트와 RI 는 엔티티의 인증서 상태를 체크함으로써 그들이 통신하는 엔티티가 손상되지 않았는지를 항상 검증해야 한다. 엔티티 손상 공격은 "포워드" 와 "백워드" 양쪽으로 발생할 수 있다. DRM 엔티티 (RI, DRM 에이전트, CI, CA, 또는 OCSP 응답기) 에 대해 포워드 손상 공격이 이루어져 인가되지 않은 행동을 유도한다. 역방향 손상 공격은 DRM 에이전트의 안전성, 무결성 세팅 및 구성을 중화하거나 또는 약화시킨다.

2. 메시지 제거, 공격자는 DRM 에이전트와 RI 사이에서 보내지는 메시지를 제거하여, 통상적으로 서비스 거부 (DoS; Denial of Service) 공격을 초래한다. 메시지 제거 공격은 등록 프로토콜 또는 RO 획득 프로토콜 동안의 메시지 제거, 재전송 넌스 제거, ROAP 트리거의 제거, 등을 포함한다.

3. 메시지 변형, 공격자는 DRM 에이전트와 RI 사이에서 보내지는 임의의 메시지를 변형하여, 통상적으로 서비스 거부 공격을 초래한다. 메시지 변형 공격은 등록 프로토콜 동안, 도메인 가입 프로토콜과 도메인 탈퇴 프로토콜 동안의 변형 및 다양한 ROAP 트리거에 대한 변형을 포함한다.

4. 메시지 삽입, 공격자는 RI 와 DRM 에이전트 사이의 임의의 지점에서 통신 채널 내부에 메시지를 삽입할 수 있다. 공격자는 또한 메시지들을 기록하여 나중의 시점에서 그들의 재전송을 시도할 수 있다. 메시지 삽입 공격은 등록 프로토콜, 2-패스와 1-패스 RO 획득 프로토콜 동안에 삽입되는 메시지, 및 다양한 ROAP 트리거에 삽입되는 메시지를 포함한다.

5. 일반적인 DoS 공격과 같은 다른 공격들, 트래픽 분석과 같은 수동적인 공격들, 및 프라이버시 노출.

현재의 OMA DRM 규격 및 구현의 다음의 문제점들이 규명되어 있다. OMA DRM 방식에 적용되는 "무결성" 의 확대된 개념이 정의되어 있다. 전통적인 의미에서, OMA DRM 규격은 작은 범위의 ROAP 메시지 무결성만 언급한다. 본 발명에서 정의되는 무결성의 확대된 개념에 있어서, 어떤 종류의 무결성이 다음에서 고려될 수 있는지 유의해야 한다.

1. DRM 플랫폼 무결성. 이것은 플랫폼 엔티티에서의 또는 플랫폼 엔티티내에서의, 즉, 디바이스, RI 및 컨텐츠 기능들을 구비하는 물리적인 엔티티에서의 무결성에 관한 것이다. 상이한 엔티티들은 오퍼레이팅 시스템 (OS), 부트 코드 (예를 들어, PC 경우의 BIOS), 메모리 액세스를 위한 HW/펌웨어(FW;firmware)/SW, (정책, 인증서, 등과 같은 비밀 데이터의 특권 저장 뿐만 아니라 암호화와 키 관리와 같은) 보안 관련 기능을 처리하는 다양한 HW/FW/SW 엔티티들, 및 네트워크와 국부 접속성 HW/FW/SW 을 포함한다. 플랫폼 무결성은 플랫폼이 유효한지, 진짜인지, 정당한 프로세스에 의한 것을 제외하고 변형되지 않았는지, 및 의도된 대로만 동작하는지 여부를 결정한다.

2. DRM SW 무결성. DRM SW 는 OMA DRM 규격과 그들의 절차에 특정한 기능들을 수행하는 디바이스, RI, 또는 CI 에 상주하는 소프트웨어 엔티티들과 컴포넌트들을 지칭한다. 디바이스에서, DRM 에이전트는 DRM SW 로 구성된다. RI 와 CI 에서, DRM SW 는 RO 패키징, DCF 포맷팅, 컨텐츠 암호화, 컨텐츠 또는 RO 전달, 검증, ROAP 프로세싱, 등과 같은 DRM-특정 기능들을 수행하는 SW 의 세트를 집합적으로 지칭한다. DRM SW 이 유효하고, 진짜이고, 정당한 프로세스에 의한 것을 제외하고 변형되지 않았고, 또한 의도된 대로만 동작하면 DRM SW 무결성은 유지된다.

3. ROAP 메시지와 정보의 무결성. ROAP 메시지들과 그들의 구성요소 정보의 무결성은 이러한 정보가 유효하고, 진짜이고, 정당한 프로세스에 의한 것을 제외하고 변형되지 않았으면 유지된다. OMA DRM 2.0 규격에 있어서, ROAP 메시지들과 그들의 구성요소 정보의 어떤 서브세트는 전자 서명의 사용에 의해 무결성 보호된다.

4. 미디어 오브젝트와 DRM 컨텐츠의 무결성. 미디어 오브젝트와 DRM 컨텐츠는 또한 무결성 보호되어야 하며, 즉, 그들이 디바이스, RI, 또는 CI 에 저장되어 있거나 또는 임의의 2 개의 상대 사이에서 운송 또는 전달 상태에 있건, 변형되고, 제거되고, 또는 부정으로 삽입되지 않아야 한다. DRM 컨텐츠가 본질적으로 개방된 채널을 사용하여 전달되고 있고, 모바일 디바이스로의 컨텐츠 전송에 적용할 수 있는, 컨텐츠의 오버-더-에어 (OTA; over-the-air) 전달은 특별히 흥미롭다.

5. DRM-관련 정보의 무결성. 엔티티 ID (디바이스 ID, RI ID, 등), 암호화 키 (CEK, REK) 와 서명 키, RO 자체, 컨텍스트 정보, 인증서들, 및 다른 신뢰-체인 관련 정보와 같은 DRM-관련 정보는 안전하게 보호되어야 하고, 이것은 상기 DRM-관련 정보는 기밀성 뿐만 아니라 무결성에 대해서도 보호되어야 함을 의미한다.

현재의 OMA DRM 2.0 규격과 기존의 종래 기술 어느 쪽도 엔티티 손상 또는 무결성 문제에 대한 해결책을 제안하지 않는다는 점에 유의해야 한다. 이러한 해결책의 결핍은 다음의 문제점을 제기한다: 심지어 모든 ROAP 절차가 OMA DRM 2.0 규격에 따라 올바르게 실행될지라도, 예를 들어, 디바이스는 RI 의 플랫폼이 신뢰할 수 있는지 여부를 참으로 어떻게 알 수 있을까 ? 달리 말하자면, RI 의 플랫폼이 디바이스가 ROAP 프로토콜의 일부로서 보내는 데이터를 오용하지 않을지 또는 DRM 프로세싱 자체를 오용하지 않을지 여부를 디바이스가 어떻게 알 수 있을까 ?. 예를 들어, 디바이스는 RI 가 디바이스의 사용 권리를 임의로 그리고 올바르지 않게 제한할 것인지 여부를 모르는데, 왜냐하면 RI 의 플랫폼 SW 가 손상되어 있고 그것이 디바이스의 다른 유효한 사용 권리를 제한하기 때문이다. DRM 소프트웨어의 무결성의 문제에 대해 유사한 질문이 생긴다. 보다 구체적으로는, 상술된 무결성의 확대된 개념의 관점에서 볼 때, 현재의 OMA DRM 2.0 시스템의 문제점 중 일부는 다음과 같다.

1. 플랫폼과 DRM SW 의 무결성을 체크하여 보고할 방법들의 결핍. 상술된 엔티티 손상 위협과 관련하여, OMA DRM 2.0 규격에 의해 특정된 바와 같이, 또는 TCG 1.2 유즈 케이스들의 일부로서, 디바이스와 RI 사이의 명확하고 구조화된 플랫폼 무결성 검증 및 SW 에이전트 무결성 검증에 대해 종래 기술의 방법이 없다. 이것은 특히 DRM 에이전트 보다는 오히려 플랫폼 무결성 검증에 대해 사실이다.

2. 플랫폼 (RI 에 대해, 디바이스 또는 서버와 관련되는, PC 또는 PDA 와 같은) 이 악의적으로 손상될 수 있고, 올바르고, 기밀성-보호되고, 또한 무결성-보호된 정보가 주어질지라도, 플랫폼의 악의적인 손상이 DRM 에이전트와 RI 에이전트 SW 가 올바르게 수행하는 것을 방해할 수 있다. 예를 들어, 다른 잘-보호된 DRM 에이전트 SW 는 프로세싱 이전에, 프로세싱 동안에, 또는 프로세싱 이후에 공유 메모리에 평문으로 일부 정보를 저장할 수 있다. 손상된 플랫폼은, 이러한 경우들에 있어서, 터무니없이 상기 공유 메모리에 액세스하여 정보를 제거하고, 정보를 변경하고, 또는 새로운 잘못된 정보를 삽입하며, 상기 잘못된 정보를 진짜 정보로서 인식할 수 있는 DRM 에이전트 SW 가 상기 잘못된 정보를 처리할 수 있다. 이것이 DoS 공격, 인가되지 않은 개인 정보의 노출, 또는 인가되지 않은 DRM RO 또는 DRM 컨텐츠의 전달, 배포, 또는 소비를 초래할 수 있다.

3. DRM-관련 정보를 처리하는 SW 의 조각인 DRM 에이전트 SW 와 RI SW 는 다양한 원인으로 손상될 수 있다. 상기 SW 는, 예를 들어, 바이러스 또는 다른 악성 SW 엔티티들에 의해 변경될 수 있다. 이러한 플랫폼 또는 DRM SW 의 손상은 OMA DRM 2.0 이 고려하는 메시지들과 정보, 특히 ROAP 프로토콜 메시지들의 무결성의 후속 손상을 초래한다. 모든 ROAP 메시지들이 아니고 일부만이 무결성-보호되는 부분적인 이유 때문에, 상기 ROAP 메시지들은 손상된 디바이스와 비인증(rogue) 또는 손상된 RI 사이에서 동기화된 방법으로 이론적으로 조작될 수 있다. 메시지들은 디바이스와 RI 양방에서 동기적으로 변형될 수 있고, 상기 메시지들이 동일하게 변형되었기 때문에 여전히 "무결성 검증된" 것처럼 보인다.

4. ROAP 메시지들의 불충분한 무결성 보호. 메시지 무결성과 관련하여, 다양한 메시지 필드에 의해 운반되는 ROAP 메시지들과 정보는 OMA DRM 2.0 규격에 의해 해결되지 않는 취약성을 겪는다. 예를 들어, OMA DRM 2.0 규격에서 현재 명시되는 ROAP 메시지 무결성 보호는 다음과 같은 결함을 남긴다:

4A. 모든 ROAP 메시지가 무결성 보호되는 것은 아니다. 모든 메시지에 전자 서명을 포함하지 않는 것이 어떤 경우들에서 취약성을 제기할 수 있다.

4B. ROAP 메시지들 또는 어떤 정보의 필드가 전자 서명에 의해 무결성 보호되어 있을지라도, 일단 상기 정보가 해독되고, 무결성 체크된 다음, 평문으로 "사용" 되면, 악성 엔티티들이 상기 평문 정보에 액세스하여 이전에 무결성-체크된 정보를 제거하고, 변경하고, 또는 재배포할 수 있다. 따라서, 강화된 무결성 보호가 요구된다.

5. DRM 컨텐츠와 그것의 전달의 무결성에 대한 취약성. 보다 구체적으로는, 다음의 문제점들이 존재한다:

5A. 컨텐츠 무결성 체킹 메카니즘이 불완전하다. 예를 들어, 컨텐츠가 전송 또는 전달 상태 (예를 들어, OTA 다운로드) 에 있는 동안 컨텐츠의 무결성은 명시되어 있지 않다. DCF 에 대한 서명은, 예를 들어, ROAP 절차에서의 사용을 위해서만 발생된다. ROAP 절차가 발생될 때까지 그리고 그 이전에, 예를 들어, CI 에서의 저장 상태에 있는 동안 컨텐츠 무결성을 관리하는 무결성 체킹 메카니즘이 없다.

5B. 컨텐츠 암호화는, 심지어 ROAP 프로토콜에서의 사용의 경우에도, 필수적이지만 무결성 체킹은 선택적일 뿐이다.

5C. 특히 서비스들을 스트리밍하기 위해 패킷화된 컨텐츠에 대해, PDCF 포맷은 타이밍 이슈 (timing issue) 를 갖는다. 전체 스트림의 무결성이 체크될 수 있기 전에 불법적으로 변형되었던 패킷들이 다운로드될 수 있고 심지어 소비 (즉, 미디어 플레이어 상에서 플레이) 될 수도 있다.

중심적인 문제점은 다음이다: 다양한 상대들 (디바이스, RI 및 CI) 이 어떻게 플랫폼 무결성과 DRM SW 무결성을 확신하는가 ? 따라서, 플랫폼 (예를 들어, OS, BIOS, 드라이버, 미디어 플레이어, 통신 소프트웨어, 공유 메모리, 등) 의 무결성을 강화하여 검증하는 방법이 요구되며, 상기 방법에 DRM 에이전트 SW 또는 RI SW 가 의존한다. 본 발명은 종래 기술의 결점들에 대처한다.

본 발명은 OMA DRM 규격 v2.0 에 관련된 엔티티들, 메시지들, 프로세싱의 무결성을 강화하는 여러 방법을 개시한다. 상기 방법은, 인더스트리 포럼 TCG (Trusted Computing Group) 에 의해 명시되는, 트러스티드 컴퓨팅 기술로서 공통적으로 알려진 기술들을 사용한다. 본 발명의 제 1 실시예에서는, 플랫폼과 DRM SW 무결성 또는 신뢰성을, DRM ROAP 및 DCF 규격에 대한 변형에 의해 그리고 변형없이, 검증하는 기술들을 개시한다. 제 2 실시예에서는, 기존의 ROAP 프로토콜을 변경하지 않고 OMA DRM ROAP 메시지들, 구성요소 정보 및 프로세싱의 무결성을 강화하는 기술들을 개시한다. 제 3 실시예에서는, 기존의 ROAP 프로토콜의 일부 변경에 의해 ROAP 메시지들, 정보 및 프로세싱의 무결성을 강화하는 기술들을 개시한다.

본 발명은, 예로서 주어지고 첨부되는 도면과 관련하여 이해되는 다음의 바람직한 실시예의 설명으로부터 보다 상세하게 이해될 수 있다.

도 1 은 기존의 OMA DRM 2.0 기능적 아키텍처의 블록도이다.

도 2 는 기존의 OMA DRM 2.0 ROAP 4-패스 등록 프로토콜의 흐름도이다.

도 3 은 기존의 OMA DRM 2.0 ROAP 2-패스 RO 획득 프로토콜의 흐름도이다.

도 4 는 기존의 OMA DRM 2.0 ROAP 1-패스 RO 획득 프로토콜의 흐름도이다.

도 5 는 기존의 OMA DRM 2.0 ROAP 2-패스 도메인 가입 프로토콜의 흐름도이다.

도 6 은 기존의 OMA DRM 2.0 ROAP 1-패스 도메인 탈퇴 프로토콜의 흐름도이다.

도 7 은 OMA DRM 2.0 엔티티들 사이에서 다중-상대 플랫폼 무결성 체킹의 블록도이다.

도 8 은 2 개의 엔티티 사이에서 플랫폼 무결성 검증을 수행하기 위한 방법의 흐름도로서 여기에서 상기 2 개의 엔티티는 디바이스와 RI 또는 디바이스와 CI 일 수 있다.

도 9 는 종래의 신뢰 체킹을 사용하여 디바이스와 RI 사이에서 상호 플랫폼 무결성 체킹을 수행하기 위한 4-패스 ROAP 등록 프로토콜의 흐름도이다.

도 10 은 변형된 디바이스 헬로우 메시지와 RI 헬로우 메시지들을 사용하여 디바이스와 RI 사이에서 상호 플랫폼 무결성 체킹을 수행하기 위한 4-패스 ROAP 등록 프로토콜의 흐름도이다.

도 11 은 2 개의 엔티티 사이에서 DRM 소프트웨어 무결성 체킹을 수행하기 위한 방법의 흐름도로서 여기에서 상기 2 개의 엔티티는 디바이스와 RI 또는 디바이스와 CI 일 수 있다.

도 12 는 디바이스와 RI 사이에서 상호 DRM 소프트웨어 무결성 체킹을 수행하기 위한 2-패스 ROAP RO 획득 프로토콜의 흐름도이다.

도 13 은 날인된 바인딩과 메모리 블로빙을 포함하는 TCG 기술을 사용하여 ROAP 메시지들과 프로세싱의 무결성을 개선하기 위한 방법의 흐름도이다.

이하, 용어 "무선 송/수신 유닛" (WTRU; wireless transmit/receive unit) 은, 사용자 장비, 이동국, 고정 또는 이동 가입자 유닛, 페이저, 또는 유선 또는 무선 환경에서 동작할 수 있는 임의의 다른 종류의 디바이스를 포함하지만, 이들로 한정되지 않는다. 이하 지칭될 때, 용어 "기지국" 은 노드 B, 사이트 컨트롤러, 액세스 지점, 또는 무선 환경에서의 임의의 다른 종류의 인터페이싱 디바이스를 포함하지만, 이들로 한정되지 않는다.

본 발명은 DRM 엔티티 (예를 들어, 디바이스, RI 또는 CI) 의 신뢰 상태 또는 무결성에 대한 정보가 OMA DRM 절차에 대한 선행요건으로서 임의의 2 개의 DRM 엔티티 사이에서 명시적으로 상호 요청되고 교환되는 방법들을 개시한다.

본 방법의 일반적인 아키텍처 (700) 는 도 7 에 도시되어 있다. 상기 아키텍 처는 4 개의 DRM 엔티티: 디바이스 (702), RI (704), CI (706), 및 PCA (Private Certification Authority)(708) 를 포함한다. 플랫폼 무결성 체킹은, PCA (708) 가 다른 DRM 엔티티들 (예를 들어, 디바이스 (702), RI (704) 및 CI (706)) 에 대한 트러스티드 컴퓨팅 (예를 들어, TCG) 크리덴셜 (credentials) 의 기록을 가지고 있고, TCG 크리덴셜의 인증을 위한 신뢰의 근원을 제공한다고 가정한다.

그들 사이에서 상호 플랫폼 무결성 체크를 원하는 임의의 엔티티 쌍 (예를 들어, 디바이스 (702) 와 RI (704), 디바이스 (702) 와 CI (706), 또는 RI (704) 와 CI (706)) 은 트러스티드 컴퓨팅 가능하다 (예를 들어, TCG 트러스티드 프로세싱 모듈 (TPM; Trusted Processing Modules)(710) 을 갖추고 있다). 이것은 트러스티드 컴퓨팅 가능한 DRM 엔티티가 TPM (710) (또는 등가물) 을 갖고 있을 뿐만 아니라, AIK (712), SML (714), 및 블로브 (716) 를 사용하는 보호 메모리와 같은 관련 TCG 자원도 갖는다는 것을 의미한다. 또한 OS 또는 플랫폼 소프트웨어 (718) 및 DRM 소프트웨어 (720) 도 존재한다.

상술된 요건이 충족되면, 임의의 상이한 DRM 엔티티의 쌍은 PCA (708) 와 트러스티드 컴퓨팅 능력을 사용하여 그들의 플랫폼 무결성 또는 플랫폼 신뢰 상태를 상호 체크할 수 있다. 일례로서, 디바이스 (702) 와 RI (704) 사이에서 상호 무결성 체크을 위한 절차는 다음과 같다.

디바이스 (702), RI (704) 및 CI (706) 모두는, OS 또는 다른 플랫폼 소프트웨어 컴포넌트의 셀프-체크 (단계 730), 및 DRM 소프트웨어의 셀프-체크 (단계 732) 를 수행할 수 있다. 셀프-체크는 보다 큰 검증 프로세스 (이하에서 보다 상세 하게 논의) 의 일부로서 요청되거나, 단독 (standalone) 프로세스일 수 있다. 만일 셀프-체크들 중 어느 것이 실패하면, 그것은 엔티티가 손상되었고 신뢰되지 않아야 한다는 표시일 수 있다.

디바이스 (702) 는 그것의 플랫폼 TCG 크리덴셜에 대한 정보를 RI (704) 로 보낸다 (단계 740). 플랫폼 TCG 크리덴셜의 예들은 서명된 TCG 플랫폼 인증서 또는 서명된 TPM 인증서를 포함하지만, 이들로 한정되지 않는다. 상기 크리덴셜의 일부로서, 디바이스 (702) 는 또한 RI (704) 에게 자체-증명된 (self-attested) 신뢰 상태 또는 플랫폼 무결성 체크된 플래그를 보충 정보로서 보낼 수 있다. 만일 디바이스 (702) 가 RI (704) 의 플랫폼 무결성을 검증할 것이라면, 단계 740 에서 보내진 크리덴셜 정보는 또한 RI (704) 가 디바이스의 플랫폼 무결성을 검증하는 절차를 시작하기를 디바이스가 원한다는 디바이스 (702) 에 의한 지시를 포함할 것이다. RI 의 플랫폼 무결성 상태의 검증이 선택적인 특징일 때만 디바이스 (702) 는 RI (704) 의 플랫폼 무결성을 검증할지 여부에 대한 결정을 할 수 있음에 유의해야 하며; 일 실시예에서, RI 의 플랫폼 무결성을 검증하는 것은 필수적인 특징 (feature) 이다.

디바이스 (702) 로부터 크리덴셜 정보를 수신하면, RI (704) 는 상기 크리덴셜 정보를 PCA (708) 로 중계하고 (단계 742), 또한 PCA (708) 가 디바이스 (702) 에 대한 크리덴셜, 특히 디바이스의 가장 최근의 신뢰성을 검증하도록 요청한다. 그 다음으로 PCA (708) 는 디바이스 (702) 에 대한 가장 최근의 신뢰성 정보 (예를 들어, 플랫폼 신뢰 수준, 등) 를 RI (704) 로 보낸다 (단계 744). PCA (708) 로부 터 디바이스 플랫폼 신뢰성 정보를 그리고 또한 선택적으로 디바이스 (702) 로부터 보충 정보를 수신하면, RI (704) 는 디바이스 (702) 의 신뢰 수준을 평가한다. RI (704) 는 등록 프로토콜 또는 RO 획득 프로토콜과 같은 DRM 절차를 추가로 진행하기 위해 디바이스 플랫폼의 무결성에 대한 충분한 신뢰를 전파할지 여부를 결정한다.

디바이스 (702) 는, 필수적인 절차로서 또는 선택적인 절차로서, RI (704) 의 플랫폼 무결성을 단계 740 - 단계 744 와 유사한 반대 방향으로 평가할 수 있다. 보다 구체적으로는, RI (704) 는 그것의 플랫폼 TCG 크리덴셜에 대한 정보를 디바이스 (702) 로 보낸다 (단계 750). 크리덴셜의 일부로서, RI (704) 는 또한 디바이스 (702) 에게 자체-증명된 신뢰 상태 또는 플랫폼 무결성 체크된 플래그를 보충 정보로서 보낼 수 있다.

RI (704) 로부터 TCG-관련 정보를 수신하면, 디바이스 (702) 는 상기 정보를 PCA 에게 중계하고 (단계 752) 또한 PCA (708) 가 RI (704) 에 대한 크리덴셜을, 특히 RI 의 가장 최근의 신뢰성을 검증할 것을 요청한다. 그 다음으로 PCA (708) 는 RI (704) 에 대한 가장 최근의 신뢰성 정보를 디바이스 (702) 로 보낸다 (단계 754). RI (704) 에 대하여 PCA (708) 로부터 RI 플랫폼 신뢰성 정보 및 선택적으로 RI 자체로부터 보충 정보를 수신하면, 디바이스 (702) 는 RI (704) 의 신뢰 수준을 평가한다. 디바이스 (702) 는 등록 프로토콜 또는 RO 획득 프로토콜과 같은 DRM 절차를 추가로 진행하기 위해 RI 플랫폼의 무결성에 대한 충분한 신뢰를 전파할지 여부를 결정한다.

디바이스 (702) 는, 필수적인 절차로서 또는 선택적인 절차로서, CI (706) 의 플랫폼 무결성을 평가할 수 있다. CI (706) 는 그것의 플랫폼 TCG 크리덴셜에 대한 정보를 디바이스 (702) 로 보낸다 (단계 760). 크리덴셜의 일부로서, CI (706) 는 또한 디바이스 (702) 에게 자체-증명된 신뢰 상태 또는 플랫폼 무결성 체크된 플래그를 보충 정보로서 보낼 수 있다.

CI (706) 로부터 TCG-관련 정보를 수신하면, 디바이스 (702) 는 상기 정보를 PCA 에게 중계하고 (단계 762) 또한 PCA (708) 에 CI (706) 에 대한 크리덴셜을, 특히 CI 의 가장 최근의 신뢰성을 검증하도록 요청한다. 그 다음으로 PCA (708) 는 CI (706) 에 대한 가장 최근의 신뢰성 정보를 디바이스 (702) 로 보낸다 (단계 764). CI (706) 에 대하여 PCA (708) 로부터 CI 플랫폼 신뢰성 정보, 및 선택적으로 CI 자체로부터 보충 정보를 수신하면, 디바이스 (702) 는 CI (706) 의 신뢰 수준을 평가한다. 디바이스 (702) 는 DRM 절차를 추가로 진행하기 위해 CI 플랫폼의 무결성에 대한 충분한 신뢰를 전파할지 여부를 결정한다.

디바이스 (702) 의 플랫폼 무결성은 CI (706) 에 의해 다음과 같이 검증될 수 있다. 디바이스 (702) 는 그것의 플랫폼 TCG 크리덴셜에 대한 정보를 CI (706) 로 보낸다 (단계 770). 크리덴셜의 일부로서, 디바이스 (702) 는 또한 CI (706) 에게 자체-증명된 신뢰 상태 또는 플랫폼 무결성 체크된 플래그를 보충 정보로서 보낼 수 있다. 만일 디바이스 (702) 가 CI (706) 의 플랫폼 무결성을 검증할 것이라면, 단계 770 에서 보내진 크리덴셜 정보는 또한 CI (706) 가 디바이스의 플랫폼 무결성을 검증하는 절차를 시작하기를 디바이스가 원한다는 디바이스 (702) 에 의 한 지시를 포함할 것이다. CI 의 플랫폼 무결성 상태의 검증이 선택적인 특징일 때만 디바이스 (702) 는 CI (706) 의 플랫폼 무결성을 검증할지 여부에 대한 결정을 할 수 있을 것임에 유의해야 하며; 일 실시예에서, CI 의 플랫폼 무결성을 검증하는 것은 필수적인 특징이다.

디바이스 (702) 로부터 크리덴셜 정보를 수신하면, CI (706) 는 상기 크리덴셜 정보를 PCA (708) 로 중계하고 (단계 772) 또한 PCA (708) 가 디바이스 (702) 에 대한 크리덴셜을, 특히 디바이스의 가장 최근의 신뢰성을 검증하도록 요청한다. 그 다음으로 PCA (708) 는 디바이스 (702) 에 대한 가장 최근의 신뢰성 정보를 CI (706) 로 보낸다 (단계 774). PCA (708) 로부터 디바이스 플랫폼 신뢰성 정보를 그리고 또한 선택적으로 디바이스 (702) 로부터 보충 정보를 수신하면, CI (706) 는 디바이스 (702) 의 신뢰 수준을 평가한다. CI (706) 는 DRM 절차를 추가로 진행하기 위해 디바이스 플랫폼의 무결성에 대한 충분한 신뢰를 전파할지 여부를 결정한다.

상기 실시예에서, 디바이스 (702) 가 그것의 무결성 상태를 RI (704) 에 대해 검증하는 단계 740 - 단계 744 는 본 발명의 필수적인 특징임에 유의해야 한다. 그러나, RI (704) 의 플랫폼 무결성을 디바이스 (702) 에 대해 검증하는 것 (단계 750 - 단계 754), CI (706) 의 플랫폼 무결성을 디바이스 (702) 에 대해 검증하는 것 (단계 760 - 단계 764), 및 디바이스 플랫폼 무결성을 CI (706) 에 대해 검증하는 것 (단계 770 - 단계 774) 은 DRM 시스템에서 선택적이지만 적극 추천되는 특징이다.

이들 절차는 검증될 필요가 있는 엔티티에 의한 능동 개시에 의해 시작되어야 하는 것은 아님에 유의해야 한다. 무결성 검증 절차는 다른 상대의 무결성을 검증하고 싶어하는 엔티티에 의한 요청으로 시작할 수 있다. 이러한 경우들에서, 단계 740, 750, 760, 또는 770 은 각각 다른 단계로 진행될 것이고, 그럼으로써 다른 상대의 플랫폼 무결성의 검증을 원하는 엔티티는 상기 다른 상대에게 관계있는 신뢰-관련 정보를 보낼 것을 요구 또는 요청한다.

대안 실시예에 있어서, 실제적인 OMA DRM 시스템 구현을 위해, 상술된 플랫폼 무결성 증명 절차에 대한 조건 또는 트리거 메카니즘은 다음을 포함할 수 있다.

1. 디바이스 플랫폼 무결성 증명 절차 (즉, 단계 740 - 단계 744) 는 하나 이상의 다음에 의해 수행될 수 있다.

1A. 디바이스가 새로운 4-패스 ROAP 등록 프로토콜의 시작을 원하기 이전.

1B. 특정한 RI 에 의한 제 1 등록이 발생하기 이전에, 각각의 RI 마다 한번. 이 경우에, RI 는 디바이스의 TCG 크리덴셜을 제 1 등록 이전에 한 번 수신할 것이고, 그 다음으로 RI 는 상기 크리덴셜 정보를 TPM 키를 사용하여 바인딩함으로써 그것 소유의 TPM 하에서 디바이스의 크리덴셜 정보를 보호한다. 나중에 RI 는 저장된 TCG 크리덴셜을 바인딩 해제하여, 주기적으로 또는 어떤 이벤트 시에, 그것이 수신했던 디바이스의 TCG 크리덴셜이 여전히 유효한지 여부를, 예를 들어, OCSP CA 와의 협의에 의해 검증한다.

1C. 주기적으로, 디바이스가 동일한 RI 로 최종 등록 프로토콜을 완료한 이 후로 특정한 시간, 예를 들어, T_{DEV-PLATFORM-LAST-REG} 이 경과할 때 마다.

1D. 주기적으로, 디바이스가 그것의 플랫폼 무결성 상태를 동일한 RI 에 대해 검증했던 최종 시간 이후로 특정한 시간, 예를 들어, T_{DEV-PLATFORM-LAST-REPORT} 이 경과할 때 마다.

2. RI 플랫폼 무결성 증명 절차 (즉, 단계 750 - 단계 754) 가 실행되면, 그들은 다음 중 하나 이상에 의해 수행될 수 있다.

2A. 특정한 디바이스에 의한 제 1 등록이 발생하기 이전에, 각각의 디바이스 마다 한번. 이 경우에, 디바이스는 RI 의 TCG 크리덴셜을 제 1 등록 이전에 한 번 수신할 것이고, 그 다음으로 디바이스는 상기 크리덴셜 정보를 TPM 키를 사용하여 바인딩함으로써 그것 소유의 TPM 하에서 RI 의 크리덴셜 정보를 보호한다. 나중에 디바이스는 저장된 TCG 크리덴셜을 바인딩 해제하여, 주기적으로 또는 어떤 이벤트 시에, 그것이 수신했던 RI 의 TCG 크리덴셜이 여전히 유효한지 여부를, 예를 들어, OCSP CA 와의 협의에 의해 검증한다.

2B. 디바이스는 RI 가 디바이스에 대한 그것의 무결성 상태를 검증하기를 원한다는 디바이스로부터의 지시를 단독 메시지로서 또는 변형 ROAP 프로토콜 메시지의 일부로서 RI 가 수신할 때마다.

2C. 주기적으로, RI 가 그것의 무결성 상태를 디바이스에 대해 검증했던 최종 시간 이후로 특정한 시간, 예를 들어, T_{RI-PLATFORM-LAST-REPORT} 이 경과할 때 마다.

3. 디바이스와 CI 사이의 플랫폼 무결성 검증에 대하여, 상술과 유사한 메카 니즘이 무결성 검증 프로세스의 주기적인 발생 및/또는 이벤트-구동 (event-driven) 발생에 대해 고려될 수 있다. 또한, CI 의 플랫폼 무결성의 디바이스의 검증의 경우에, 컨텐츠가 구입되거나 또는 다운로드되어야 하기 이전에 매 번 그것이 또한 수행될 수 있고, 어쩌면 반대로 (즉, 디바이스의 플랫폼 무결성이 CI 에 대해 검증되어야 한다).

종래 기술에서는 강건한 DRM 의 적용과 결합된 TCG 기술을 사용하는 "안전 부트-업(secure boot-up)" 의 사용을 고려했다. 이러한 방식에서는, 디바이스가 부팅되어 임의의 DRM 애플리케이션이 실행될 수 있기 전에 플랫폼 무결성 체크를 암시적으로 수행할 때마다, 플랫폼의 OS 와 다른 부트-업 관련 코드가 무결성 체크된다. 본 발명은, 어떤 이벤트의 발생 시 뿐만 아니라 소정의 시간 주기에 기초한 다른 시간에서의 플랫폼 무결성 체크 뿐만 아니라, 부트-타임 플랫폼 무결성 체크의 보다 체계적이고 명시적인 사용을 제공한다. 본 발명은 또한 디바이스로부터 RI 와 CI 로의 플랫폼 무결성 체킹을 일반화한다. 연속적인 플랫폼 무결성 체크는, 디바이스가 특정한 유효 CO 를 올바르게 수신하기 때문에, 그것은 RI 또는 CI 가 그 시간으로부터 미래로 무기한으로 신뢰가능한 것으로 고려되어야 한다는 것을 의미하지 않는다는 사실 때문에 유리하다. 신뢰성의 주기적인 및/또는 이벤트-구동 연속 검증은 우수한 보호 메카니즘을 제공한다.

또한, 디바이스와 CI 사이의 무결성 체킹의 필요성에 대해, 컨텐츠가 RO 보다 이전에 도착할지라도, CI 의 플랫폼 또는 CI 의 DRM SW 의 무결성이 손상되면 상기 컨텐츠는 손상될 수 있다. 예를 들어, 사용자가 파일을 다운로드했다고 가정 하자. RO 가 아직 획득되지 않았을지라도, 사용자는 부주의로 컨텐츠를 클릭할 수 있고 또는 컨텐츠에 대한 유효성 체크를 수행할 수 있다. 만일 컨텐츠가 손상되었다면 (예를 들어, 바이러스가 첨부되었다면), 상기 컨텐츠는, 심지어 RO 없이, 디바이스에 피해를 줄 수 있다. 또한, 디바이스와 CI 사이의 사전-다운로드 상호작용 (예를 들어, 발견 단계 동안) 에 있어서, 손상된 디바이스는, 예를 들어 컨텐츠에 부착된 바이러스를 CI 용으로 의도된 메시지에 부가함으로써, CI 에 피해를 줄 수 있다. 게다가, 사업 전망으로부터, CI 는 손상된 디바이스로 컨텐츠를 전송하기를 원하지 않을 것이다: 예를 들어, 손상된 디바이스는 인가되지 않은 수령자들에게 무료로 컨텐츠를 재배포할 수 있다. 따라서 디바이스와 CI 사이의 상호 플랫폼 (및 SW) 무결성 검증은 전체 시스템을 보호하는 장점을 갖는다.

상술된 아키텍처 논의에서 윤곽을 그린 중심 아이디어를 구현하는 여러 다른 방법들이 있을 수 있음에 또한 유의해야 한다. 그러한 2 개의 실시예가 아래에 논의되어 있지만, 이들은 위의 구문에서 설명된 아키텍처에 기초한 보다 넓은 개념의 단지 예시적인 실시예일 뿐임에 유의해야 한다.

플랫폼 무결성 검증

도 8 은 2 개의 엔티티 사이에서 플랫폼 무결성 검증을 수행하는 방법 (800) 의 흐름도이다. 2 개의 엔티티는 디바이스와 RI, 디바이스와 CI, 또는 RI 와 CI 일 수 있다. 상기 방법 (800) 은 요청 엔티티 (RE; requesting entity) 와 목표 엔티티 (TE) 를 활용하며, 쌍 중 어느 엔티티 (디바이스, RI, 또는 CI) 는 RE 일 수 있음에 유의해야 한다. 상기 방법 (800) 은 어느 엔티티가 RE 이고 어느 엔티티가 TE 인가에 관계없이 동일한 방식으로 동작한다.

상기 방법 (800) 은 RE 가 TE 에게 그것의 플랫폼 무결성 상태를 보고하도록 요청을 보내는 것으로 시작한다 (단계 802). 상기 요청에 응답하여, TE 는 그것의 TCG 크리덴셜을 RE 에게 보낸다 (단계 804). 상기 TCG 크리덴셜은, 예를 들어, 플랫폼 크리덴셜, TPM 크리덴셜, 또는 적합 크리덴셜 (conformance credentials) 을 포함할 수 있다. 그 다음으로, RE 는 TE 의 TCG 크리덴셜을 상기 크리덴셜의 검증을 위해 OCSP 응답기에게 보낸다 (단계 806). OCSP 응답기는 TE 의 TCG 크리덴셜을 재검토하여 검증 상태를 RE 에게 보고한다 (단계 808).

RE 는 TE 에게 그것 소유의 플랫폼 무결성 상태를 보고하도록 요청을 보낸다 (단계 810). TE 는 그것의 플랫폼 무결성 상태를 체크하여 (단계 812), 플랫폼 상태 플래그를 RE 에게 보내고 (단계 814), 상기 방법이 종료된다 (단계 816).

상기 방법 (800) 은, ROAP 프로토콜에 대한 변경없이 (도 9 와 관련되어 아래에서 논의) 또는 ROAP 프로토콜에 대한 변경과 함께 (도 10 와 관련되어 아래에서 논의) 적용될 수 있다.

ROAP 프로토콜에 대한 변경없는 무결성 검증

도 9 는 ROAP 프로토콜과 별도로 TCG 기술 (즉, OCSP 응답기/PCA (906) 이용) 를 사용하여 디바이스 (902) 와 RI (904) 사이에서 무결성 관련 정보를 교환하는 방법 (900) 의 흐름도이다. 상기 방법 (900) 에서는, 동일한 엔티티 (906) 가 TCG 프로세싱을 위한 OCSP 응답기 뿐만 아니라 DRM 프로세싱을 위한 PCA 양방으로 설명되어 있음에 유의해야 한다. 상기 방법 (900) 에 있어서, 플랫폼 무결성 검증 (점선 사각형으로 표시한 바와 같이) 은 ROAP 4-패스 등록 프로토콜 이전에 수행된다. 등록 프로토콜 이전에 플랫폼 무결성 검증을 수행하는 것이 유용한데 그 이유는 등록 프로토콜이 빈번하게 수행되지 않고 플랫폼 무결성 검증 프로세스는 완료하는데 시간이 걸리기 때문이다; 만일 플랫폼 무결성 검증이 각각의 메시지에 의해 수행되었다면, 시스템의 전반적인 동작은 불필요하게 느려질 수 있다. 당업계의 당업자라면, 플랫폼 무결성 검증이 수행된 이후에, 오직 하나의 디바이스 헬로우 메시지만이 RI 에 의해 수신된다면, 그것은 신뢰 디바이스를 나타내는 것으로 가정할 수 있다. 만일 하나보다 많은 디바이스 헬로우 메시지가 동일한 디바이스로부터 RI 에 의해 수신된다면, 그것은 DoS 공격의 징후일 수 있다. 플랫폼 무결성 검증은 또한 인증 프로토콜과 오브젝트 획득 프로토콜과 관련하여 수행될 수 있다.

디바이스 (902) 는, RI (904) 와 함께 4-패스 등록 프로토콜을 시작하기에 앞서, RI (904) 와 함께 별도의 절차들의 세트를 시작하여 플랫폼 무결성의 상호 검증을 수행한다. 디바이스 (902) 는 먼저 그것 소유의 TCG 크리덴셜 (예를 들어, 플랫폼 크리덴셜, TPM 크리덴셜, 적합 크리덴셜, 등) 또는 TCG 크리덴셜을 포함하는 또는 TCG 크리덴셜과 관계되는 다른 정보를 RI (904) 에게 보낸다 (단계 910). 선택적으로, 디바이스 (902) 는 또한 RI (904) 에게 그것 소유의 플랫폼 무결성 상태를 디바이스 (902) 에 대해 체크하여 보고하도록 요청을 보낸다: 이 요청은 디바이스 크리덴셜과 함께 포함된다.

RI (904) 는 PCA (906) 에게 디바이스의 TCG 크리덴셜을 검증하도록 요청한다 (단계 912). PCA (906) 는 RI 의 요청에 응답하여 디바이스의 TCG 크리덴셜에 대한 정보를 보낸다 (단계 914).

RI (904) 는 디바이스 (902) 에게 그것의 플랫폼 무결성 상태 플래그를 보고하도록 요청한다 (단계 916). 또한, 만일 RI (904) 가 단계 910 에서 그것의 플랫폼 무결성 상태를 검증하여 보고할 것을 디바이스 (902) 가 요청했다면 그리고 만일 RI (904) 가 상기 요청에 따르길 원하고 따를 수 있다면, RI (904) 는 그것 소유의 TCG 크리덴셜 또는 TCG 크리덴셜을 포함하는 또는 TCG 크리덴셜과 관계되는 다른 정보를 디바이스 (902) 에게 단계 916 에서 보낸다. 만일 RI (904) 가 상기 요청에 따를 수 없거나 또는 따르기를 원하지 않으면, RI 는 "따르지 않음(not obliging)" 메시지를 디바이스 (902) 에게 보낸다. RI (904) 는, 자원 제한된 RI (즉, RI 는 상기 요청에 응답할 충분한 활용가능 자원을 가지고 있지 않다) 또는 디바이스 신뢰성 체크 실패를 포함하는 많은 이유로 요청에 대해 응답하지 않을 수 있다. 디바이스는 디바이스가 RI 와 함께 갖는 신뢰 수준에 의존하여 프로토콜을 중단할 수 있다; 만일 디바이스가 RI 를 신뢰하면, 심지어 RI 가 요청에 대한 응답을 거절했을 지라도 프로토콜을 계속할 것이다. 플랫폼 상태를 체크하도록 RI (904) 로부터 요청을 수신하면, 디바이스 (902) 는 그것 소유의 플랫폼 무결성 상태를 체크한다 (단계 918).

디바이스 (902) 는 PCA (906) 에게 RI 의 TCG 크리덴셜을 검증하도록 요청한다 (단계 920). PCA (906) 는, 디바이스 (902) 로부터 요청을 수신하면, RI 의 TCG 크리덴셜에 대한 정보를 되돌린다 (단계 922). 디바이스 (902) 는 그것의 플랫폼 무결성 상태 플래그를 RI (904) 로 보낸다 (단계 924). 만일 RI (904) 가 디바이스 (902) 로부터 그것의 무결성 상태를 체크하도록 요청을 수신했다면, 그리고 만일 RI (904) 가 상기 요청에 따르기를 원하고 따를 수 있다면, RI (904) 는 그것 소유의 플랫폼 무결성을 체크한다 (단계 926). RI 는 그 다음으로 그것의 플랫폼 무결성 상태 플래그를 디바이스 (902) 에게 되돌린다 (단계 928). RI 무결성 체크에 대한 선택적인 단계들은 임의의 순서로 수행될 수 있다; 이들 단계는 도 9 에 도시된 디바이스 무결성 체크와 서로 얽힐 필요는 없다. 게다가, RI 는 그것 소유의 무결성 체크를 시작할 수 있다. 또한, RI 가 가능한 이유들 중 어떤 이유 때문에 그것 소유의 TCG 크리덴셜 정보와 함께 상기 요청에 대해 완전히 응답하는 것을 거절하면, RI 는 그러한 사실을 적절한 방법으로, 예를 들어 단계 922 에서 디바이스에게 나타낼 수 있다.

상기 방법 (900) 에 의해 디바이스 (902) 와 RI (904) 는 상호 플랫폼 무결성 검증을 달성할 수 있다. 이러한 검증을 하자마자, 디바이스는 ROAP 등록 프로토콜을 시작할 수 있다. 도 9 에 도시된 등록 프로토콜의 단계들 (단계 930 - 단계 940) 은 상술된 방법 (200) 의 단계 210 - 단계 220 과 동일하다. 이들 절차는 주기적으로 트리거되거나 또는 반복될 수 있음에도 또한 유의해야 하다.

ROAP 등록 프로토콜에 대한 변경과 함께 무결성 검증

도 10 은, 다른 실시예에 있어서, 디바이스 (1002) 와 RI (1004) 가 무결성-관련 정보를 교환하고, 또한 OCSP 응답기/PCA (1006) 의 서비스들을 활용하는 방법 (1000) 을 도시한다. 상기 방법 (1000) 에 있어서, ROAP 등록 프로토콜의 기존 디바이스 헬로우 메시지와 RI 헬로우 메시지는 플랫폼 무결성 검증을 위해 TCG 크리 덴셜과 요청 양자를 다른 상대에게 전달하도록 변형되어 있다.

디바이스 (1002) 는 변형된 디바이스 헬로우 메시지를 RI (1004) 에게 보내며 (단계 1010), 디바이스 TCG 크리덴셜과 선택적인 요청을 포함하는 메시지가 그것의 플랫폼 무결성을 보고하도록 RI (1004) 에게 보내진다. RI (1004) 는 디바이스 크리덴셜을 검증을 위해 PCA (1006) 로 포워드한다 (단계 1012). PCA (1006) 는 그 다음으로 디바이스 TCG 크리덴셜을 RI (1004) 로 되돌린다 (단계 1014). RI (1004) 는 RI 헬로우 메시지를 변형하여 디바이스 (1002) 에 응답하며 (단계 1016), 상기 메시지는 RI 의 TCG 크리덴셜을 선택적으로 포함한다.

다음으로, 디바이스 (1002) 는 RI 의 TCG 크리덴셜을 체크하도록 PCA (1006) 에게 요청을 선택적으로 보낸다 (단계 1018). PCA (1006) 는 RI 의 크리덴셜을 체크하여 그 결과를 디바이스 (1002) 에게 보고한다 (단계 1020). 디바이스 (1002) 는 그것 소유의 무결성 상태를 체크하여 (단계 1022), 상기 무결성 상태를 RI (1004) 에게 보고한다 (단계 1024).

만일 RI (1004) 가 그것의 무결성 상태를 보고할 것을 디바이스 (1002) 가 요청했다면, RI (1004) 는 플랫폼 무결성 체크를 수행하고 (단계 1026) 상기 무결성 상태, 예를 들어, 그것의 신뢰 상태 플래그를 디바이스 (1002) 에게 보고한다 (단계 1028). 단계 1030 - 단계 1036 은 ROAP 등록 프로토콜의 도 2 에 도시된 단계 214 - 단계 220 과 동일하다.

DRM 소프트웨어의 무결성 체킹

도 11 은 DRM 엔티티들의 임의의 쌍 중에서 DRM SW (예를 들어, 디바이스에 상주하는 DRM 사용자 에이전트 SW, 또는 RI 또는 CI 에 상주하는 DRM SW) 의 무결성을 체크하는 방법 (1100) 의 흐름도이다. 요청 엔티티 (RE) 는 목표 엔티티 (TE) 에게 DRM SW 무결성 체크를 수행하도록 요청을 보낸다 (단계 1102). TE 는 그것의 DRM SW 무결성을 체크하고 (단계 1104), DRM SW 무결성 상태 플래그를 RE 에게 보내고 (단계 1106), 상기 방법이 종료된다 (단계 1108). TE 가 디바이스일 때, DRM SW 와 디바이스 드라이버들 및 미디어 플레이어 SW 가 디바이스 상에 별도로 존재한다면, 상기 디바이스 드라이버들 및 미디어 플레이어 SW 의 무결성은 DRM SW 의 무결성과 별도로 체크될 수 있다는 것을 유의해야 한다.

상기 방법 (1100) 은 TE 로부터 DRM SW 무결성 체크를 획득하는 RE 에만 관계된 것이다. 상호 DRM SW 무결성 체킹을 수행하기 위해, 상기 방법 (1100) 은 일단 RE 로부터 TE 로 그리고 그 다음에 TE 로부터 RE (RE 와 TE 가 역할을 바꾼 상태로) 로 2 번 수행될 필요가 있다. 상호 DRM SW 무결성 체크 동안, 상기 요청들은 얽힐 수 있고 (도 12 에 도시된 바와 같이) 또는 도 11 에 도시된 바와 같이 분리될 수 있다. 상호 DRM SW 무결성 체크가 수행중이면 상기 방법의 동작은 변경되지 않는다.

OMA DRM 2.0 규격은, RI (또는 RI 의 DRM SW) 뿐만 아니라 DRM 사용자 에이전트 SW (또는 디바이스 DRM SW, 본 발명에서 사용되는 용어로) 는 암시적으로 신뢰될 수 있다라고 가정하며, 이러한 가정이 유효하게 구현될 수 있는 방법은 제안하지 않는다. 따라서 OMA DRM 2.0 규격에서의 인증 프로토콜만이, 이미 신뢰성있는 것으로 여겨지는 엔티티들 사이에서의 실제 인증 절차들을 명시한다. 명백한 이유 들 때문에, 실제로 이러한 암시적인 SW 신뢰 가정은, 그들을 실행하고 검증하는 실제의 단계들 없이, 자동적으로 가정될 수 없다. 본 섹션에서 기술되는 방법들은 그러한 구체적인 단계들과 관계가 있다.

도 12 는 ROAP RO 획득 프로토콜과 관계되는 DRM SW 체크를 적용하는 방법 (1200) 의 흐름도이다. 상기 방법 (1200) 은 디바이스 (1202), RI (1204), 및 OCSP 응답기/PCA (1206) 를 활용한다. 먼저, PCA (1206) 는 디바이스 (1202) 및 RI (1204) 와 통신하여 플랫폼 무결성 체킹 및 ROAP 등록 프로토콜을 수행한다 (단계 1210). 디바이스 (1202) 및 RI (1204) 는 상호 플랫폼 무결성 체크, 일방향 DRM SW 무결성 체크, 또는 상호 DRM SW 무결성 체크를 수행한다 (단계 1212).

RI (1204) 는 디바이스 (1202) 에게 디바이스의 DRM 사용자 에이전트 (UA) SW 무결성을 체크하여 보고하도록 요청을 보낸다 (단계 1214). 디바이스 (1202) 는 그것의 최신 DRM UA SW 무결성을 체크한다 (단계 1216). 디바이스 (1202) 는 선택적으로 RI (1204) 에게 RI 의 DRM SW 무결성을 체크하여 보고하도록 요청을 보낸다 (단계 1218). 요청을 받으면, RI (1204) 는 그것의 최신 DRM SW 무결성을 체크한다 (단계 1220). 디바이스 (1202) 는 디바이스 DRM SW 무결성 상태 플래그를 RI (1204) 에게 보낸다 (단계 1222). 사전에 요청되었으면, RI (1204) 는 RI DRM SW 무결성 상태 플래그를 디바이스 (1202) 에게 보낸다 (단계 1224). 선택적인 RI 무결성 체크의 단계들은 임의의 순서로 수행될 수 있고 도 12 에 도시된 디바이스 무결성 체크와 얽힐 필요가 없다는 점에 유의해야 한다.

상기 방법 (1200) 은 예시된 디바이스/RI 상호작용 대신에, 디바이스와 CI 사이에서의 상호 DRM SW 무결성 검증으로 일반화될 수 있음에 유의해야 한다. 단계 1210 - 단계 1224 을 완료하면, 디바이스 (1202) 는, 예를 들어, 단계 1226 과 단계 1228 에서 2-패스 RO 획득 프로토콜을 시작할 수 있고, 상기 단계 1226 과 단계 1228 는 도 3 과 관련하여 상술된 단계 310 과 단계 312 와 동일하다. 비록 방법 (1200) 이 RO 획득 프로토콜과 관련하여 도시되어 있을지라도, 그것은 임의의 다른 ROAP 프로토콜과 관련하여 사용될 수 있고, 방법 (1200) 과 연관된 오버헤드 (overhead) 를 최소화하기 위해 임의의 주어진 시간에 ROAP 프로토콜들의 적절하게 선택된 서브세트만으로 수행될 수 있음에 추가로 유의해야 한다. 실제적인 OMA DRM 시스템 실행을 위해, 제안된 플랫폼 및/또는 상술된 DRM SW 무결성 검증 절차를 위한 조건들 또는 트리거 메카니즘들 중 일부가 포함할 수 있다:

1. 디바이스 DRM SW 무결성 검증 절차는 하나 이상의 다음에 의해 트리거될 수 있다.

1A. 디바이스가 새로운 2-패스 ROAP 등록 프로토콜, 2-패스 도메인 가입 프로토콜, 또는 2-패스 도메인 탈퇴 프로토콜를 시작하기를 원하기 이전.

1B. 주기적으로, 디바이스가 동일한 RI 와 함께 2-패스 ROAP 등록 프로토콜, 2-패스 도메인 가입 프로토콜, 또는 2-패스 도메인 탈퇴 프로토콜을 최종 완료한 이후로 특정한 시간, 예를 들어, T_{DEV-DRM-LAST-ROAP} 이 경과할 때 마다.

1C. 주기적으로, 디바이스가 그것의 DRM SW 무결성 상태를 검증하여 동일한 RI 에게 보고했던 최종 시간 이후로 특정한 시간, 예를 들어, T_{DEV-DRM-LAST-REPORT} 가 경 과할 때 마다.

1D. 디바이스가 그것의 DRM SW 를 갱신할 때 마다.

1E. 플랫폼 SW 가 갱신되거나 또는 변경될 때 마다.

2. RI DRM 무결성 검증 절차는 다음 중 하나 이상에 의해 수행될 수 있다.

2A. RI 가 디바이스에 대한 그것의 DRM SW 무결성 상태를 검증하기를 디바이스가 원한다는 디바이스로부터의 지시를, 단독 메시지로서 또는 변형된 ROAP 프로토콜 메시지의 일부로서, RI 가 수신할 때 마다.

2B. 주기적으로, RI 가 그것의 DRM SW 무결성 상태를 검증하여 디바이스에게 보고했던 최종 시간 이후로 특정한 시간, 예를 들어, T_{RI-DRM-LAST-REPORT} 가 경과할 때 마다.

2C. RI 가 그것의 DRM SW 를 갱신할 때 마다.

2D. 사용자가 스트리밍 컨텐트와 같은 컨텐츠를 빈번하게 획득하고 있는 경우에, 디바이스가 RO 요청을 보내기 전에 매 번.

디바이스와 CI 사이의 플랫폼 무결성 검증에 관한 한, 상술과 유사한 메카니즘들이 DRM SW 무결성 검증 프로세스의 주기적인 발생 및/또는 이벤트-구동 발생에 대해 고려될 수 있다.

DRM 플랫폼 검증 및 DRM SW 검증을 위해 제안된 방법들은 서로 독립적으로 수행될 수 있지만, 이들 검증 절차는 절차들의 그룹의 일부로서 조합될 수 있음도 또한 고려되고 있다. 이러한 실시예에서, DRM 플랫폼 검증 단계들은 DRM SW 검증 단계들을 위한 선행 요건으로 고려되고 있다. 예를 들어, 디바이스와 RI 사이의 무결성 검증을 위해, 디바이스와 RI 는 먼저 상술된 바와 같이 DRM 플랫폼 검증 절차를 수행함으로써 서로의 전체적인 플랫폼에 대한 신뢰를 확립한다. 트리거 메카니즘은 일반적인 플랫폼 검증 트리거 조건들을 포함한다. 그 다음으로, DRM SW 검증 트리거를 위한 조건들이 발생할 때, DRM SW 검증 절차가 뒤따른다. 양쪽 타입의 검증 절차는 그들 각각의 트리거 조건들이 충족될 때 실행될 것이라는 점에 주목한다. 그러나, DRM SW 검증 단계들은 DRM 플랫폼 검증 단계들의 성공적인 완료에 지배될 것이며, 즉, 만일 DRM 플랫폼 검증이 디바이스와 RI 사이에서 실패하면, 실제의 DRM ROAP 프로세싱과 사용자-관련 프로세싱 뿐만 아니라 DRM SW 검증에서의 추가적인 프로세싱도 실패할 것이다.

서명 날인 (Sealed-signing) 및 바인딩 (binding)

ROAP 프로토콜의 무결성을 보호하는 OMA DRM 2.0 규격의 기존 메카니즘은 ROAP 메시지들 전부는 아니더라도 일부에, 전자 서명 (또는 메시지 무결성 체킹) 을 포함시키는 것에 제한되어 있다. ROAP 프로토콜이 안전한 DRM 프로세싱 구현에서 중심적으로 중요하다면, ROAP 프로토콜에서 사용되고 교환되는 정보의 무결성을 보호하고 연속적으로 검증하는 것이 중요하다.

그러므로, 본 발명의 대안적인 실시예에서는, ROAP 프로토콜의 무결성을 강화하는 방법들이 개시되어 있고 그럼으로써 DRM 디바이스와 RI 사이에서 신뢰할 수 있는 인증과 무결성 검증에 중심적인 정보는: (1) TCG 기술을 사용하여 안전하게 저장될 수 있고, 또한 (2) 다른 측으로 전송되기 전에 또는 정보가 저장되어 있는 측에서 프로세싱을 위해 사용되기 전에 사전-검증될 수 있다.

본 방법은 서명 날인 (즉, 목표 정보를 대칭적으로 암호화하고 그 다음으로 플랫폼 또는 특정한 SW 컨포넌트의 당시의 무결성 상태를 나타내는 PCR 값 세트에 더하여 대칭키에 비대칭적으로 서명함) 및 바인딩 (그것의 비밀 암호화 키가 TPM 과 같은 보호 모듈 내에 보관되어 있는 키를 사용하여 목표 정보를 비대칭적으로 암호화함) 의 TCG 기술을 사용하는 2 개의 기본적인 절차를 포함한다. 서명 날인은, 비대칭 암호화, 전자 서명, 및 바인딩에 의해 제공되는 최고 수준의 정보 보안을, 보호되는 PCR 값으로 표시되는 디바이스 DRM 사용자 에이전트 SW 의 신뢰 상태까지 부여한다. 바인딩은, 암호화 키가 TPM 내부에 보호되어 있는 비대칭 암호화를 사용하는 높은 수준의 보호를 부여한다.

다음의 체계적인 원리들은 서명 날인과 바인딩을 사용하여 ROAP 메시지에서 사용되고 있는 정보의 기밀성과 무결성 양쪽을 보호하고, 그럼으로써 ROAP 프로토콜 자체의 무결성의 강도를 간접적으로 향상시킨다. 다음의 논의에서, 디바이스와 RI (또는 이러한 특정 디바이스를 다루는 RI 의 일부분) 양방에는 TPM 과 서포트 풀 TPM 기능 (support full TPM functionality) 이 갖추어져 있다고 가정된다.

디바이스와 RI 각각은 2 개의 저장 키들의 세트를 보관하고 사용하여 ROAP 프로세싱과 관련된 어떤 정보를 암호기술적으로 바인딩하여 디바이스 또는 RI 가 상주하는 신뢰 플랫폼에 안전하게 저장한다. 디바이스에 대해, 이들 키는 K_DEV_BIND_A 및 K_DEV_BIND_B 이다. RI 에 대해, 이들 키는 K_RI_BIND_A 및 K_RI_BIND_B 이다. 이들은 TPM-관리 비대칭 키들이다 (즉, 암호화는 공개 키에 의 해 행해지고, 암호해독은 TPM 내부에서 보호되는 비밀 키에 의해 행해진다).

디바이스와 RI 각각은 DRM 프로세싱을 위해 단일 PCR 또는 PCR 들의 세트를 사용한다. 디바이스와 RI 는 또한 AIK (Attestation Identity Key) 를 옆에 두고 이를 사용하여 ROAP 프로세싱과 관련된 어떤 정보를 신뢰 플랫폼과 그것의 특정한 PCR 값에 서명 날인한다. TCG AIK 키들은 PCR 값들에 서명하기 위해서만 사용된다는 점에 유의해야 한다. 디바이스에 대해, 그것의 AIK 는 K_DEV_AIK 이고, RI 에 대해, 그것의 AIK 는 K_RI_AIK 이다. 또한, 서명 날인은 목표 데이터의 암호화 동작을 위해 비대칭 저장 키를 필요로 한다. 따라서 디바이스와 RI 각각은 이러한 목적으로 저장 키를 옆에 두고 사용한다. 디바이스를 위한 저장 키는 K_DEV_STO_SEAL 이고, RI 를 위한 저장 키는 K_RI_STO_SEAL 이다.

상기 방법은 그 다음으로 무결성 뿐만 아니라 기밀성을 보호하는 부가된 대책과 함께 서명 날인과 바인딩의 조합을 사용하여 ROAP 프로세싱에 포함되는 다양한 정보 요소들을 저장하는 강도를 향상시킨다. 예를 들어, 도 13 은 TPM 서명 날인과 바인딩 동작을 사용하여 4-패스 ROAP 등록 프로토콜을 구비하는 다양한 메시지에서의 정보의 기밀성 및 무결성을 보호하는 방법 (1300) 의 흐름도이다. 상기 방법 (1300) 에 있어서, 디바이스 (1302) 와 RI (1304) 각각은 선택적인 ROAP-관련 정보의 세트를 서명 날인하고 2 세트의 저장 키를 사용하여 상기 정보를 바인딩하며, 상기 2 세트의 저장 키 각각은 4-패스 등록 프로토콜의 과정 동안 (다른 측으로) 전송되거나 또는 (다른 측으로부터) 수신된다.

디바이스 (1302) 는 먼저 암호화 키 K_DEV_STO_SEAL 와 디바이스-특정 AIK K_DEV_AIK 에 의해 디바이스 ID 정보 요소 (이것은, OMA DRM 케이스에서, OMA DRM 공개 키의 SHA-1 해쉬이다) 를 서명 날인한다 (단계 1310). 이 정보는 저장 키 K_DEV_BIND_A 에 의해 디바이스 헬로우 메시지로 의도된 다른 정보에 (비대칭 암호화를 사용하여) 바인딩된다 (단계 1310). 상기 디바이스 헬로우 메시지는 그 다음으로 디바이스 (1302) 로부터 RI (1304) 로 보내진다 (단계 1312).

디바이스 ID 와 같은 정보를 서명 날인하고 디바이스 헬로우 메시지를 구비하는 다른 정보를 바인딩함으로써, 디바이스 (1302) 가 사전에 서명 날인되고 바인딩된 정보를 그들의 보호 저장소로부터 복구하고 (즉, 서명 날인 해제하고 바인딩 해제하고), 그들을 DRM SW 가 사용중 일 수 있는 상기 정보 요소들의 현재값들과 비교하여, 현재값들의 진짜임과 무결성을 검증할 때만 그리고 검증한다면 디바이스 헬로우 메시지가 전송될 것이라는 정책을 디바이스 (1302) 가 설립할 수 있다. 이러한 시나리오에서 서명 날인되고 바인딩될 정보 요소들의 선택은 단지 일례로서만 주어진다는 점에 유의해야 한다. 다른 정보 요소들은 본 발명의 동작에 영향을 주지 않고 다른 조합으로 서명 날인되고 바인딩될 수 있다. 다른 조합들은, 시스템 타임, 메시지 내의 임의의 정보 요소, 알고리즘들, 및 넌스들과 같은 항목들로부터 유도될 수 있다. 넌스들을 보호하는 한 가지 이유는 넌스들이 진정으로 랜덤 (random) 인지 여부를 결정하는 것인데, 왜냐하면 일부 난수 발생기들 특히 해롭게 손상될 수 있는 것들은 받아들이기 어려운 짧은 시간 내에 그들의 출력과 동일한 패턴을 반복하고 동일한 숫자들을 발생시킬 수 있기 때문이다.

RI (1304) 는, 디바이스 헬로우 메시지를 수신하면, 상기 디바이스 헬로우 메시지 내에 포함된 정보를 그것의 바인딩 키 K_RI_BIND_A 를 사용하여 바인딩한다 (단계 1314). 이러한 단계에 의해 RI (1304) 가 디바이스 (1302) 로부터 수신했던 키 정보를 안전하고 무결성-보호되도록 저장할 수 있다. 대안으로, RI (1304) 는 또한 디바이스 헬로우 메시지로부터 디바이스 ID (또는 임의의 다른 정보 요소) 를 추출하고 AIK K_RI_AIK 및 암호화 키 K_RI_STO_SEAL 를 사용하여 상기 정보 요소를 별도로 서명 날인할 수도 있다.

RI (1304) 는 RI ID 와 RI URL 정보 요소들에 암호화 키 K_RI_STO_SEAL 와 AIK K_RI_AIK 를 사용하여 서명 날인한다 (단계 1316). RI (1304) 는 또한 그것의 RI 헬로우 메시지 내에 포함된 다른 정보를 저장 키 K_RI_BIND_A 를 사용하여 바이딩한다 (단계 1316). RI (1304) 는 그 다음으로 RI 헬로우 메시지를 디바이스 (1302) 로 보낸다 (단계 1318).

RI (1304) 가 먼저 사전에 서명 날인되고 바인딩된 정보를 보호 저장소로부터 복구하고 (즉, 서명 날인 해제하고 바인딩 해제하고), 그들을 RI DRM SW 가 사용중 일 수 있는 이러한 정보 요소들의 현재값들과 비교하여, 상기 현재값들의 진짜임과 무결성을 검증할 때만 그리고 검증한다면 RI (1304) 는 RI 헬로우 메시지를 디바이스 (1302) 로 송신한다.

디바이스 (1302) 는, RI 헬로우 메시지를 수신하면, 상기 RI 헬로우 메시지 내에 포함된 정보를 제 2 바인딩 키, 즉, K_DEV_BIND_B 를 사용하여 바인딩한다 (단계 1320). 이러한 단계에 의해 디바이스가 RI (1304) 로부터 수신했던 키 정보를 안전하고 무결성-보호되도록 저장할 수 있다. 대안으로, 디바이스 (1302) 는 또 한 수신된 RI 헬로우 메시지로부터 선택 정보 요소들 (RI ID 및/또는 RI URL 과 같은) 을 추출하고, 그들을 AIK K_DEV_AIK 와 암호화 키 K_DEV_STO_SEAL 를 사용하여 서명 날인하고, 상기 RI 헬로우 메시지로 수신된 정보 중 나머지를 K_DEV_BIND_B 를 사용하여 단순히 바인딩할 수도 있다.

디바이스 (1302) 는 인증서 체인, DCF 해쉬, 및 요청 시간 (Request Time) 에 K_DEV_AIK 와 K_DEV_STO_SEAL 을 사용하여 서명 날인한다 (단계 1322). 디바이스 (1302) 는 그 다음으로 등록 요청 메시지를 위해 의도된 다른 정보를 K_DEV_BIND_A 를 사용하여 바인딩한다 (단계 1322). 디바이스 (1302) 는 그 다음으로 등록 요청 메시지를 RI (1304) 로 보낸다 (단계 1324). 디바이스가 사전에 서명 날인되고 바인딩된 정보를 복구하고 (즉, 서명 날인 해제하고 바인딩 해제하고), 복구된 값들을 DRM SW 메모리에서 사용되는 현재의 임시값들과 비교하여, 상기 현재값들의 진짜임과 무결성을 검증하면 디바이스 (1302) 만이 등록 요청 메시지를 보낸다. 등록 요청 메시지를 수신하면, RI (1304) 는 상기 등록 요청 메시지로부터의 정보를 바인딩 키 K_RI_BIND_B 를 사용하여 바인딩한다 (단계 1326).

RI (1304) 는 키들, 인증서 체인, 및 RO 들을 K_RI_AIK 및 K_RI_STO_SEAL 를 사용하여 서명 날인한다 (단계 1328). RI (1304) 는 그 다음으로 등록 응답 메시지에 포함되도록 이것과 다른 정보를 바인딩 키 K_RI_BIND_A 를 사용하여 바인딩한다 (단계 1328). RI (1304) 는 그 다음으로 등록 응답 메시지를 디바이스 (1302) 로 보낸다 (단계 1330). RI (1304) 가 사전에 서명 날인되고 바인딩된 정보를 복구하고 (즉, 서명 날인 해제하고 바인딩 해제하고), 복구된 값들을 DRM SW 메모리에서 사용되는 현재의 임시값들과 비교하여, 상기 현재값들의 진짜임과 무결성을 검증하면 RI (1304) 만이 등록 응답 메시지를 보낸다. 등록 응답 메시지를 수신하면, 디바이스 (1302) 는 상기 등록 응답 메시지로부터의 RI-발생 정보를 바인딩 키 K_DEV_BIND_B 를 사용하여 바인딩한다 (단계 1332).

서명 날인하고 바인딩하는 것은 임의의 다른 ROAP 프로토콜과 함께 사용될 수 있음에 유의해야 한다. 상술된 방법 (1300) 은 예시적이며, 그것의 원리들은 임의의 다른 ROAP 프로토콜에 동일하게 적용될 수 있다.

OMA DRM ROAP 메시지 교환 동안에 얻어지는 데이터는, 상기 데이터를 날인했거나 또는 서명 날인했던 엔티티가 그것의 플랫폼 OS 또는 DRM SW 를 갱신했다면, 날인 해제되고 새로운 구성 PCR 값으로 재날인될 필요가 있을 것이다. 이러한 이벤트가 발생하면, 특정한 상태 (또는, 등가로, 특정한 PCR 값 세트) 로 날인되었거나 또는 서명 날인되었던 DRM ROAP-관련 데이터가 먼저 날인 해제되고 그 다음으로 갱신된 플랫폼 OS 의 가장 최근의 상태로 재날인되어야 할 것이다. 이러한 절차상의 요건을 언급하는 종래의 기존 기술들이 존재하고 여기에 제안된 대로 날인 또는 서명 날인을 사용하여 저장되어 있는 임의의 DRM ROAP-관련 데이터의 적절한 날인-해제와 재-날인을 보장하도록 이러한 절차가 발생할 것이라고 가정되어 있다.

하나의 부가적인 향상은 기존의 ROAP 메시지 포맷에 필드를 부가하여 송신 디바이스의 TCG 능력을 나타내는 것이다. 상기 TCG 능력 필드는, 수신 엔티티가 TCG 관련 정보와 절차를 지원할 수 있는지 여부를 조기에 결정함으로써 레거시 (legacy) 디바이스들에 의해 증가하는 상호 운용성 (interoperability) 을 도울 수 있다.

디바이스 헬로우 메시지와 그것의 유도물의 변형

제 1 변형은, 디바이스의 TPM 능력의 표시자인 새로운 디바이스 TPM 능력 표시 (DTCI; Device TPM Capability Indication) 를 디바이스 헬로우 메시지의 기존의 익스텐션 파라미터 (Extension parameter) 의 새로운 요소에 부가하거나, 또는 대안적으로 그리고 바람직하게는, 상기 DTCI 를 디바이스 헬로우 메시지의 헤더에 새로운 제 1 파라미터로서 부가하는 것이다. 상기 DTCI 는 (디바이스 TPM 의 존재 또는 부재를 나타내는) 일 비트 일 수 있고, 또는 (디바이스의 TPM 능력에 대한 보다 세분화된 (more granular) 정보를 나타내는) 수 개의 비트일 수 있다. 만일 DTCI 가 새로운 파라미터로서 삽입된다면, 그것은, 디바이스 ID 파라미터 전에, 제 1 파라미터로서 삽입되어야 하는 것이 바람직하고, 따라서 RI 는 다른 파라미터들을 사전에 알 수 있고 디바이스는 특정 TPM 능력을 갖고 상기 DTCI 를 활용하여 나중의 파라미터 (예를 들어, 디바이스 ID) 로부터의 정보를 처리한다. DTCI 정보의 이점은 DTCI 정보에 의해 RI 가 ROAP 프로토콜의 나머지에서 디바이스와의 추가적인 상호작용으로 디바이스의 신뢰성을 평가할 수 있다는 것이다.

제 2 변형은 디바이스-특정 TCG EK 크리덴셜 또는 TCG AIK 크리덴셜을 사용하여 DRM 디바이스 ID 를 해쉬하고 유도하는 것이다. 이러한 변형의 이점은 EK 크리덴셜 및/또는 AIK 크리덴셜이 디바이스 내부의 TPM 에 의해 고도로 보호되고, 따라서, 이들 크리덴셜 중 어느 하나로부터 DRM 디바이스 ID 를 유도함으로써 DRM 디바이스 ID 정보의 무결성을 강화한다는 것이다.

제 3 변형은 새로운 서명 파라미터를 부가하는 것이고 여기에서 디바이스 헬로우 메시지는, 서명을 배제하여 상기 서명까지, 디바이스의 AIK 비밀 키를 사용하여 서명되고, RI 에 의해 검증되도록 의도되어 있다. 이러한 변형의 이점은 디바이스와 RI 사이의 제 1 상호작용으로부터 디바이스 TPM 능력의 무결성을 보호하는 것이다. TPM 에 의해 고도로 안전하게 보호되고 있는 디바이스의 AIK 비밀 키의 사용은 서명 동작의 무결성을 강화한다.

표 12 와 표 13 은 변형된 디바이스 헬로우 메시지에 대한 2 개의 가능한 포맷을 도시한다. 표 12 는 제 1 파라미터로서 DTCI 비트를 갖는 메시지의 포맷을 도시한다. 표 13 은 DTCI 가 기존의 익스텐션 파라미터의 새로운 요소인 디바이스 헬로우 메시지의 포맷을 도시한다.

RI 헬로우 메시지와 그것의 유도물의 변형

제 1 변형은, RI 의 TPM 능력의 표시자인 새로운 RI TPM 능력 표시 (RTCI; RI TPM Capability Indication) 를 RI 헬로우 메시지의 기존의 익스텐션 파라미터의 새로운 요소로서 부가하거나, 또는 대안적으로 그리고 바람직하게는, 상기 RTCI 를 RI 헬로우 메시지의 헤더에 새로운 제 1 파라미터로서 부가하는 것이다. 이러한 변형의 이점은 디바이스가 RTCI 정보를 사용하여 ROAP 프로토콜 절차의 나머지에서 상기 RI 와 상기 디바이스의 추가적인 상호작용으로 RI 의 신뢰성을 평가하여 상기 정보를 활용할 수 있게 한다는 것이다.

제 2 변형은 RI TPM 을 사용하여 세션 ID 용 의사-난수 (pseudo-random number) 를 제공하는 것이다. 이러한 변형의 이점은 TPM 이 고도로 안전한 하드웨어-기반 의사-난수 발생기를 제공한다는 것이다. TPM 을 사용하여 세션 ID 로서 사용되고 있는 의사-난수를 발생시킴으로써 프로토콜의 보안을 강화한다.

제 3 변형은 RI 의 TPM 에 속하는 RI TCG EK 크리덴셜 또는 TCG AIK 크리덴셜을 사용하여 RI ID 를 유도하는 것이다. 이러한 변형의 이점은, EK 크리덴셜 및/또는 AIK 크리덴셜이 디바이스 내부의 TPM 에 의해 고도로 보호되고 이들 크리덴셜 중 어느 하나로부터 DRM 디바이스 ID 를 유도함으로써 DRM 디바이스 ID 의 무결성을 강화한다는 것이다.

제 4 변형은 RI TPM 을 사용하여 RI 넌스를 제공하는 것이다. 이러한 변형의 이점은 TPM 이 고도로 안전한 하드웨어-기반 의사-난수 발생기를 제공한다는 것이다. TPM 을 사용하여 RI 넌스를 발생시킴으로써, RI 헬로우 메시지에서 사용되고 있는 넌스의 무결성을 강화한다.

제 5 변형은 디바이스 신뢰 RI 앵커에 디바이스 TCG 크리덴셜을 포함시키는 것이다. 상기 디바이스의 TCG 크리덴셜은 EK 크리덴셜, AIK 크리덴셜, 플랫폼 크리덴셜, 및 RI 가 신뢰 TCG CA 로부터 미리 획득했던 준수 크리덴셜 (compliance credential) 을 포함한다. 이러한 변형의 이점은 상기 RI 헬로우 메시지에 대해 디바이스가 가질 수 있는 신뢰를 향상시킨다는 것이다.

제 6 변형은, RI 의 AIK 비밀키를 사용하여 서명된 서명을 배제한 상기 서명까지 RI 헬로우 메시지의 서명을 부가하는 것인데, 상기 RI 의 AIK 공개키는 디바이스에게 RI 헬로우 메시지의 일부로서 미리 배포되어 있다. 이러한 변형의 이점은 RI 와 디바이스 사이의 제 1 상호작용으로부터 RTCI 의 무결성을 보호한다는 것이다. RI 의 TPM 에 의해 고도로 안전하게 보호되어 있는 RI 의 AIK 비밀키를 사용함으로써 서명 동작의 무결성을 강화한다.

표 14 와 표 15 는 변형된 RI 헬로우 메시지에 대한 가능한 2 개의 포맷을 도시한다. 표 14 는 RTCI 비트를 제 1 파라미터로서 갖는 RI 헬로우 메시지의 포맷을 도시한다. 표 15 는 RTCI 가 기존의 익스텐션 파라미터의 새로운 요소인 RI 헬로우 메시지의 포맷이다.

등록 요청 메시지 및 그것의 유도물에 대한 변형

제 1 변형은 디바이스 TPM 을 사용하여 디바이스 넌스를 제공하는 것이다. 이러한 변형의 이점은 TPM 이 넌스를 위한 사용에 적당한 안전하고 신뢰가능한 의사-난수를 제공한다는 것이다.

제 2 변형은 인증서 체인에 디바이스 TCG 크리덴셜을 포함시키는 것이다. 디바이스 TCG 크리덴셜을 포함시킴은 기존의 OMA DRM 2.0 디바이스 크리덴셜의 대체일 수 있고, 또는 상기 크리덴셜에 대한 부가일 수 있다. TCG 크리덴셜 (EK 크리덴셜, AIK 크리덴셜, 플랫폼 크리덴셜, 또는 준수 크리덴셜 등) 을 포함시키는 이점은 디바이스의 신뢰성을 증대시킨다는 것이다.

제 3 변형은 신뢰 RI 앵커 요소에 RI 에 의해 신뢰되는 TCG CA 들의 목록을 포함시키는 것이다. RI 에 의해 신뢰되는 TCG CA 를 포함시키는 것은 기존의 OMA DRM 2.0 RI 신뢰 앵커 요소 목록의 대체일 수 있고, 또는 상기 목록에 대한 부가일 수 있다. RI 에 의해 신뢰되는 TCG CA 들의 목록을 포함시킴의 이점은 디바이스의 신뢰성을 증대시킨다는 것이다.

제 4 변형은 익스텐션 파라미터의 디바이스 디테일 요소에서의 디바이스 TPM 에 대한 정보를 포함시키는 것이다. 이러한 정보를 포함시킴의 이점은 RI 에 대하여 디바이스에 대한 신뢰성을 향상시킨다는 것이다.

제 5 변형은 변형된 디바이스 헬로우 메시지에 서명하는데 사용되는 디바이스 AIK 를 사용하여 서명 (Signature) 에 서명하는 것이다. 이러한 변형의 이점은 상기 디바이스 AIK 의 고도로 보호되는 성질로 인해 디바이스 및 등록 요청 메시지의 신뢰성을 증대시킨다는 것이다.

표 16 은 변형된 등록 요청 메시지에 대한 포맷을 도시한다.

등록 응답 메시지 및 그것의 유도물의 변형

제 1 변형은 RI TPM 을 사용하여 세션 ID 를 위한 의사-난수를 제공하는 것이다. 이러한 변형의 이점은 TPM 이 고도로 안전한 하드웨어-기반 의사-난수 발생기를 제공한다는 것이다. TPM 을 사용하여 상기 세션 ID 로서 사용되는 의사-난수를 발생시킴으로써 프로토콜의 보안을 강화한다.

제 2 변형은 RI 의 TPM 에 속하는 RI TCG EK 크리덴셜 또는 TCG AIK 크리덴셜을 사용하여 RI ID 를 유도하는 것이다. 이러한 변형의 이점은, 상기 EK 크리덴셜 및/또는 상기 AIK 크리덴셜이 디바이스 내부의 TPM 에 의해 극도로 보호되고 이들 크리덴셜 중 어느 크리덴셜로부터 DRM 디바이스 ID 를 유도함으로써 DRM 디바이스 ID 정보의 무결성을 강화시킨다는 것이다.

제 3 변형은 RI TPM 을 사용하여 RI 넌스를 제공하는 것이다. 이러한 변형의 이점은 상기 RI TPM 이 넌스로서의 사용에 적당한 안전하고 신뢰가능한 의사-난수를 제공한다는 것이다.

제 4 변형은 신뢰 디바이스 앵커 요소에서 디바이스에 의해 신뢰되는 TCG CA 들의 목록을 포함시키는 것이다. 디바이스에 의해 신뢰되는 TCG CA 들을 포함시키는 것은 기존의 OMA DRM 2.0 신뢰 디바이스 앵커 요소 목록들의 대체일 수 있고, 또는 상기 목록에 대한 부가일 수 있다. 디바이스에 의해 신뢰되는 TCG CA 들의 목록을 포함시키는 이점은 RI 의 신뢰성을 증대시킨다는 것이다.

제 5 변형은 변형된 RI 헬로우 메시지에 서명하는데 사용되는 RI AIK 를 사용하여 서명에 서명하는 것이다. 이러한 변형의 이점은 RI AIK 의 고도로 보호되는 성질로 인해 RI 및 등록 응답 메시지의 신뢰성을 증대시킨다는 것이다.

표 17 은 변형된 등록 응답 메시지에 대한 포맷을 도시한다.

RO 요청 메시지 및 그것의 유도물의 변형

제 1 변형은 TPM 을 사용하여 선택 TCG 크리덴셜 (EK 크리덴셜, AIK 크리덴셜, 플랫폼 크리덴셜, 또는 준수 크리덴셜) 의 SHA-1 해쉬를 생성하여 디바이스 ID 로서 사용하는 것이다. 이러한 변형의 이점은 크리덴셜들이 상기 TPM 에 의해 고도로 보호되고, 따라서 이들 크리덴셜 중 어느 크리덴셜로부터 디바이스 ID 를 유도함으로써 디바이스 ID 정보의 무결성을 강화한다는 것이다.

제 2 변형은 디바이스 TPM 을 사용하여 디바이스 넌스를 발생시키는 것이다. 이러한 변형의 이점은 TPM 에 의해 발생되는 넌스는 안전하다는 것인데, 그 이유는 TPM 의 보호되는 의사-난수 발생 능력 때문이다.

제 3 변형은 인증서 체인에 디바이스 TCG 크리덴셜들을 포함시키는 것이다. TCG 크리덴셜들을 포함시키는 것은 기존의 OMA DRM 2.0 디바이스 크리덴셜들의 대체일 수 있고, 또는 상기 기존의 크리덴셜들에 대한 부가일 수 있다. TCG 크리덴셜들을 포함시키는 이점은 디바이스의 신뢰성을 증대시킨다는 것이다.

제 4 변형은 익스텐션 파라미터 내의 디바이스 AIK 를 사용하여 선택적인 DCF 해쉬에 서명하는 것이다. 이러한 변형의 이점은 디바이스 AIK 들이 고도로 보호되고, 그럼으로써 DCF 서명을 보다 안전하게 만든다는 것이다.

제 5 변형은 등록 요청 메시지에 대해 가장 최근에 성공적으로 응답된 것에 서명하는데 사용된 디바이스 AIK 를 사용하여 RO 요청 메시지에 서명하는 것이다. 이러한 변형의 이점은 RI AIK 의 고도로 보호되는 성질로 인해 RI 및 RO 요청 메시지의 신뢰성을 증대시킨다는 것이다.

표 18 은 변형된 RO 요청 메시지의 포맷을 도시한다.

RO 응답 메시지 및 그것의 유도물의 변형

일 변형은 가장 최근의 성공적인 등록 응답 메시지에 서명할 때 사용된 동일 RI TPM AIK 를 사용하여 RO 응답 메시지에 서명하는데 RI 의 TPM 을 사용하는 것이다. 이러한 변형의 이점은 RI AIK 의 고도로 보호되는 성질로 인해 RI 및 RO 응답 메시지의 신뢰성을 증대시킨다는 것이다.

표 19 는 변형된 RO 응답 메시지의 포맷을 도시한다.

본 발명의 특징 및 구성요소들이 바람직한 실시예들의 특정한 조합으로 설명되고 있지만, 각각의 특징 또는 구성요소는, 본 발명의 다른 특징 및 구성요소들과 함께 또는 다른 특징 및 구성요소들 없이, 단독으로 (바람직한 실시예들의 다른특징 및 구성요소들 없이) 또는 다양한 조합으로 사용될 수 있다.

실시예들

1. 요청 엔티티 (RE; requesting entity) 와 목표 엔티티 (TE; target entity) 사이에서 플랫폼 무결성 체킹을 수행하기 위한 방법으로서, 상기 RE 로부터 상기 TE 에게 요청을 보내 상기 TE 에게 그것의 트러스티드 컴퓨팅 그룹 (TCG) 크리덴셜을 보고하도록 요청하는 단계; 상기 TE 로부터 상기 RE 로 TE 의 TCG 크리덴셜을 보내는 단계; 상기 TE 의 TCG 크리덴셜을 상기 RE 로부터 온라인 인증 상태 프로토콜 (OCSP) 응답기에게 검증을 위해 포워딩하는 단계; 상기 TE 의 TCG 크리덴셜의 검증 상태를 상기 OCSP 응답기로부터 상기 RE 에게 보고하는 단계; 상기 RE 로부터 상기 TE 에게 요청을 보내 상기 TE 에게 그것 소유의 플랫폼 무결성 상태를 보고하도록 요청하는 단계; 상기 TE 의 플랫폼 무결성 상태를 체킹하는 단계; 및 상기 TE 로부터 상기 RE 로 플랫폼 무결성 상태 표시자를 보내는 단계를 포함하는 플랫폼 무결성 체킹 방법.

2. 실시예 1 에 따른 방법으로서, 상기 RE 는 권리 발행자 (RI) 이고 상기 TE 는 디바이스인 것인 플랫폼 무결성 체킹 방법.

3. 실시예 2 에 따른 방법으로서, 상기 방법은 상기 디바이스가 상기 RI 에게 상기 방법을 시작하도록 트리거를 보냄으로써 상기 디바이스가 상기 RI 와의 권리 오브젝트 획득 프로토콜 (ROAP) 등록 프로토콜을 시작하기 전에 수행되는 것인 플랫폼 무결성 체킹 방법.

4. 실시예 2 또는 3 에 따른 방법으로서, 상기 방법은 상기 디바이스가 상기 RI 에 가장 최근에 등록했던 때로부터의 경과 시간에 기초하여 주기적으로 수행되는 것인 플랫폼 무결성 체킹 방법.

5. 실시예 2 내지 4 중 하나에 따른 방법으로서, 상기 방법은 상기 디바이스가 그것의 플랫폼 무결성 상태를 상기 RI 에 대해 가장 최근에 검증했던 때로부터의 경과 시간에 기초하여 주기적으로 수행되는 것인 플랫폼 무결성 체킹 방법.

6. 실시예 1 에 따른 방법으로서, 상기 RE 는 디바이스이고 상기 TE 는 권리 발행자 (RI) 인 것인 플랫폼 무결성 체킹 방법.

7. 실시예 6 에 따른 방법으로서, 상기 방법은 상기 RI 가 그것의 플랫폼 무결성 상태를 상기 디바이스에 대해 가장 최근에 검증했던 때로부터의 경과 시간에 기초하여 주기적으로 수행되는 것인 플랫폼 무결성 체킹 방법.

8. 실시예 1 에 따른 방법으로서, 상기 RE 는 컨텐츠 발행자 (CI) 이고 상기 TE 는 디바이스인 것인 플랫폼 무결성 체킹 방법.

9. 실시예 8 에 따른 방법으로서, 상기 방법은 상기 디바이스가 그것의 플랫폼 무결성 상태를 상기 CI 에 대해 가장 최근에 검증했던 때로부터의 경과 시간에 기초하여 주기적으로 수행되는 것인 플랫폼 무결성 체킹 방법.

10. 실시예 8 또는 9 에 따른 방법으로서, 상기 방법은 상기 디바이스가 상기 CI 로부터 컨텐츠를 구입할 때 수행되는 것인 플랫폼 무결성 체킹 방법.

11. 실시예 1 에 따른 방법으로서, 상기 RE 는 디바이스이고 상기 TE 는 컨텐츠 발행자 (CI) 인 것인 플랫폼 무결성 체킹 방법.

12. 실시예 11 에 따른 방법으로서, 상기 방법은 상기 CI 가 그것의 플랫폼 무결성 상태를 상기 디바이스에 대해 가장 최근에 검증했던 때로부터의 경과 시간에 기초하여 주기적으로 수행되는 것인 플랫폼 무결성 체킹 방법.

13. 실시예 11 또는 12 에 따른 방법으로서, 상기 방법은 상기 디바이스가 상기 CI 로부터 컨텐츠를 구입할 때 수행되는 것인 플랫폼 무결성 체킹 방법.

14. 실시예 1 에 따른 방법으로서, 상기 방법은 권리 오브젝트 획득 프로토콜 (ROAP) 프로세스의 일부로서 수행되는 것인 플랫폼 무결성 체킹 방법.

15. 실시예 14 에 따른 방법으로서, 상기 방법은 상기 ROAP 프로세스 전에 수행되는 것인 플랫폼 무결성 체킹 방법.

16. 실시예 14 또는 15 에 따른 방법으로서, 상기 ROAP 프로세스는 상기 방법을 상기 ROAP 프로세스의 일부로서 포함하도록 변형되는 것인 플랫폼 무결성 체킹 방법.

17. 요청 엔티티 (RE) 와 목표 엔티티 (TE) 사이에서 디지탈 권리 관리 (DRM) 소프트웨어 무결성 체킹을 수행하기 위한 방법으로서, 상기 RE 로부터 상기 TE 에게 요청을 보내 상기 TE 가 DRM 소프트웨어 무결성 체크를 수행하도록 요청하는 단계; 상기 DRM 소프트웨어 무결성을 상기 TE 에 의해 체킹하는 단계; 및 상기 TE 로부터 상기 RE 로 DRM 소프트웨어 무결성 상태 표시자를 보내는 단계를 포함하는 DRM 소프트웨어 무결성 체킹 방법.

18. 실시예 17 에 따른 방법으로서, 상기 RE 는 권리 발행자 (RI) 이고 상기 TE 는 디바이스인 것인 DRM 소프트웨어 무결성 체킹 방법.

19. 실시예 18 에 따른 방법으로서, 상기 디바이스가 권리 오브젝트 획득 프로토콜 (ROAP) 프로세스를 시작하기 전에 상기 방법을 시작하도록 상기 디바이스가 상기 RI 에게 트리거를 보내는 것인 DRM 소프트웨어 무결성 체킹 방법.

20. 실시예 19 에 따른 방법으로서, 상기 ROAP 프로세스는 2 패스 등록, 2 패스 도메인 가입, 및 2 패스 도메인 탈퇴로 이루어지는 그룹으로부터 선택되는 것인 DRM 소프트웨어 무결성 체킹 방법.

21. 실시예 19 또는 20 에 따른 방법으로서, 상기 방법은 상기 디바이스가 상기 RI 와의 권리 오브젝트 획득 프로토콜 (ROAP) 프로세스를 완료한 후에 주기적으로 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

22. 실시예 19 내지 21 중 하나에 따른 방법으로서, 상기 ROAP 프로세스는 2 패스 등록, 2 패스 도메인 가입, 및 2 패스 도메인 탈퇴로 이루어지는 그룹으로부터 선택되는 것인 DRM 소프트웨어 무결성 체킹 방법.

23. 실시예 18 내지 22 중 하나에 따른 방법으로서, 상기 방법은 상기 디바이스가 그것의 DRM 소프트웨어 무결성 상태를 상기 RI 에 대해 검증하고 보고한 후에 주기적으로 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

24. 실시예 18 내지 23 중 하나에 따른 방법으로서, 상기 방법은 상기 디바이스가 그것의 DRM 소프트웨어를 갱신한 후에 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

25. 실시예 18 내지 24 중 하나에 따른 방법으로서, 상기 RI 는 상기 디바이스에게 상기 디바이스 상의 미디어 플레이어에 대한 DRM 소프트웨어 무결성 체크를 수행하도록 요청하는 것인 DRM 소프트웨어 무결성 체킹 방법.

26. 실시예 17 에 따른 방법으로서, 상기 RE 는 디바이스이고 상기 TE 는 권리 발행자 (RI) 인 것인 DRM 소프트웨어 무결성 체킹 방법.

27. 실시예 26 에 따른 방법으로서, 상기 방법은 상기 디바이스에 의해 시작되면 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

28. 실시예 26 또는 27 에 따른 방법으로서, 상기 방법은 단독 프로세스인 것인 DRM 소프트웨어 무결성 체킹 방법.

29. 실시예 26 내지 28 중 하나에 따른 방법으로서, 상기 방법은 변형된 권리 오브젝트 획득 프로토콜 프로세스의 일부인 것인 DRM 소프트웨어 무결성 체킹 방법.

30. 실시예 26 내지 29 중 하나에 따른 방법으로서, 상기 방법은 상기 RI 가 그것의 DRM 소프트웨어 무결성 상태를 상기 디바이스에 대해 검증하고 보고한 후에 주기적으로 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

31. 실시예 26 내지 30 중 하나에 따른 방법으로서, 상기 방법은 상기 RI 가 그것의 DRM 소프트웨어를 갱신한 후에 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

32. 실시예 26 내지 31 중 하나에 따른 방법으로서, 상기 방법은 상기 디바이스가 권리 오브젝트 요청을 상기 RI 에게 보내기 전에 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

33. 실시예 26 내지 32 중 하나에 따른 방법으로서, 상기 방법은 컨텐츠를 스트리밍하기 위한 상기 디바이스로부터 상기 RI 로의 요청 동안 주기적으로 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

34. 실시예 17 에 따른 방법으로서, 상기 RE 는 컨텐츠 발행자 (CI) 이고 상기 TE 는 디바이스인 것인 DRM 소프트웨어 무결성 체킹 방법.

35. 실시예 34 에 따른 방법으로서, 상기 디바이스가 권리 오브젝트 획득 프로토콜 (ROAP) 프로세스를 시작하기 전에 상기 방법을 시작하도록 상기 디바이스가 상기 CI 에게 트리거를 보내는 것인 DRM 소프트웨어 무결성 체킹 방법.

36. 실시예 34 또는 35 에 따른 방법으로서, 상기 방법은 상기 디바이스가 상기 CI 와의 권리 오브젝트 획득 프로토콜 (ROAP) 프로세스를 완료한 후에 주기적으로 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

37. 실시예 34 내지 36 중 하나에 따른 방법으로서, 상기 방법은 상기 디바이스가 그것의 DRM 소프트웨어 무결성 상태를 상기 CI 에 대해 검증하고 보고한 후에 주기적으로 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

38. 실시예 34 내지 37 중 하나에 따른 방법으로서, 상기 방법은 상기 디바이스가 그것의 DRM 소프트웨어를 갱신한 후에 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

39. 실시예 34 내지 38 중 하나에 따른 방법으로서, 상기 CI 는 상기 디바이스에게 상기 디바이스 상의 미디어 플레이어에 대한 DRM 소프트웨어 무결성 체크를 수행하도록 요청하는 것인 DRM 소프트웨어 무결성 체킹 방법.

40. 실시예 17 에 따른 방법으로서, 상기 RE 는 디바이스이고 상기 TE 는 컨텐츠 발행자 (CI) 인 것인 DRM 소프트웨어 무결성 체킹 방법.

41. 실시예 40 에 따른 방법으로서, 상기 방법은 상기 디바이스에 의해 시작되면 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

42. 실시예 40 또는 41 에 따른 방법으로서, 상기 방법은 단독 프로세스인 것인 DRM 소프트웨어 무결성 체킹 방법.

43. 실시예 40 내지 42 중 하나에 따른 방법으로서, 상기 방법은 변형된 권리 오브젝트 획득 프로토콜 프로세스의 일부인 것인 DRM 소프트웨어 무결성 체킹 방법.

44. 실시예 40 내지 43 중 하나에 따른 방법으로서, 상기 방법은 상기 CI 가 그것의 DRM 소프트웨어 무결성 상태를 상기 디바이스에 대해 검증하고 보고한 후에 주기적으로 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

45. 실시예 40 내지 44 중 하나에 따른 방법으로서, 상기 방법은 상기 CI 가 그것의 DRM 소프트웨어를 갱신한 후에 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

46. 실시예 40 내지 45 중 하나에 따른 방법으로서, 상기 방법은 상기 디바이스가 권리 오브젝트 요청을 상기 CI 에게 보내기 전에 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

47. 실시예 40 내지 46 중 하나에 따른 방법으로서, 상기 방법은 컨텐츠를 스트리밍하기 위한 상기 디바이스로부터 상기 CI 로의 요청 동안 주기적으로 수행되는 것인 DRM 소프트웨어 무결성 체킹 방법.

48. 2 개의 엔티티 사이에서 교환되는 권리 오브젝트 획득 프로토콜 (ROAP) 메시지들의 무결성을 강화하기 위한 방법으로서, 트러스티드 컴퓨팅 기술을 사용하여 각각의 엔티티에서 상기 ROAP 메시지에 사용될 정보를 안전하게 저장하는 단계; 및 상기 ROAP 메시지에 사용될 상기 정보를, 상기 ROAP 메시지와 관련하여 사용되기에 앞서, 사전-검증하는 단계를 포함하는 ROAP 메시지의 무결성 강화 방법.

49. 실시예 48 에 따른 방법으로서, 상기 저장 단계는, 상기 정보에 서명 날인하는 단계; 및 상기 정보를 바인딩하는 단계를 포함하는 것인 ROAP 메시지의 무결성 강화 방법.

50. 실시예 49 에 따른 방법으로서, 상기 서명 날인 단계는, 상기 정보를 대칭 암호화 키를 사용하여 대칭적으로 암호화하는 단계; 및 상기 대칭 암호화 키 및 오브젝트의 현재의 무결성 상태를 나타내는 값들의 세트에 비대칭적으로 서명하는 단계를 포함하는 것인 ROAP 메시지의 무결성 강화 방법.

51. 실시예 50 에 따른 방법으로서, 상기 서명 단계는, 상기 엔티티가 동작하고 있는 플랫폼의 무결성 상태를 사용하는 단계를 포함하는 것인 ROAP 메시지의 무결성 강화 방법.

52. 실시예 50 또는 51 에 따른 방법으로서, 상기 서명 단계는, 상기 엔티티의 소프트웨어 컴포넌트의 무결성 상태를 사용하는 단계를 포함하는 것인 ROAP 메시지의 무결성 강화 방법.

53. 실시예 49 내지 52 중 하나에 따른 방법으로서, 상기 바인딩 단계는, 그의 비밀 암호해독 키가 상기 엔티티의 보호 모듈 내에 저장되어 있는 키를 사용하여 상기 정보를 비대칭적으로 암호화하는 단계를 포함하는 것인 ROAP 메시지의 무결성 강화 방법.

54. 실시예 53 에 따른 방법으로서, 상기 보호 모듈은 트러스티드 프로세싱 모듈 (TPM) 인 것인 ROAP 메시지의 무결성 강화 방법.

55. 실시예 54 에 따른 방법으로서, 상기 TPM 은 상기 ROAP 메시지에 사용할 파라미터를 유도하는데 사용되는 것인 ROAP 메시지의 무결성 강화 방법.

56. 실시예 48 내지 55 중 하나에 따른 방법으로서, 상기 정보는, 디바이스 ID, 권리 발행자 ID, 인증서, 인증서 체인, 디지탈 권리 관리 관련된 시간값, 권리 오브젝트, 알고리즘, 및 넌스로 이루어지는 그룹으로부터 선택되는 것인 ROAP 메시지의 무결성 강화 방법.

57. 실시예 48 내지 56 중 하나에 따른 방법으로서, 상기 방법은 모든 ROAP 메시지에 적용되는 것인 ROAP 메시지의 무결성 강화 방법.

58. 실시예 48 내지 56 중 하나에 따른 방법으로서, 상기 방법은 상기 ROAP 메시지와 별도로 적용되는 것인 ROAP 메시지의 무결성 강화 방법.

59. 실시예 48 내지 56 중 하나에 따른 방법으로서, 상기 방법은 상기 ROAP 메시지의 발생 및 전송에 통합되는 것인 ROAP 메시지의 무결성 강화 방법.

60. 실시예 48 내지 56 중 하나에 따른 방법으로서, 송신 엔티티의 트러스티드 컴퓨팅 능력을 나타내도록 기존의 ROAP 메시지에 필드를 부가하는 단계를 더 포함하는 ROAP 메시지의 무결성 강화 방법.

61. 실시예 1 내지 60 중 하나에 따른 방법을 수행하도록 구성된 시스템.

62. 실시예 1 내지 60 중 하나에 따른 방법을 수행하도록 구성된 집적 회로.

Claims (60)

1. 요청 엔티티 (RE; requesting entity) 와 목표 엔티티 (TE; target entity) 사이에서 플랫폼 무결성 체킹을 수행하기 위한 방법으로서,

   목표 엔티티에 대하여, 상기 목표 엔티티의 트러스티드 컴퓨팅 그룹 (TCG; trusted computing group) 크리덴셜(credential)을 보고하라는 요청을 상기 요청 엔티티로부터 수신하고;

   상기 요청 엔티티에 상기 목표 엔티티의 TCG 크리덴셜을 보내고;

   상기 목표 엔티티에 대하여, 상기 목표 엔티티의 플랫폼 무결성 상태를 보고하라는 요청을 상기 요청 엔티티로부터 수신하고;

   상기 목표 엔티티의 플랫폼 무결성 상태를 체킹하며;

   상기 요청 엔티티에 플랫폼 무결성 상태 표시자를 보내는 것

   을 포함하는 플랫폼 무결성 체킹 방법.
2. 제 1 항에 있어서,

   상기 요청 엔티티는 권리 발행자 (RI; rights issuer) 이고 상기 목표 엔티티는 디바이스인 것인, 플랫폼 무결성 체킹 방법.
3. 제 2 항에 있어서,

   상기 방법은, 상기 디바이스가 상기 방법을 시작하도록 상기 RI 에 트리거를 보냄으로써 상기 디바이스가 상기 RI 와의 권리 오브젝트 획득 프로토콜 (ROAP; rights object acquisition protocol) 등록 프로토콜을 시작하기 전에, 수행되는 것인, 플랫폼 무결성 체킹 방법.
4. 제 2 항에 있어서,

   상기 방법은 상기 디바이스가 상기 RI 에 가장 최근에 등록했던 때로부터의 경과 시간에 기초하여 주기적으로 수행되는 것인, 플랫폼 무결성 체킹 방법.
5. 제 2 항에 있어서,

   상기 방법은 상기 디바이스가 자신의 플랫폼 무결성 상태를 상기 RI 에 대해 가장 최근에 검증(verify)했던 때로부터의 경과 시간에 기초하여 주기적으로 수행되는 것인, 플랫폼 무결성 체킹 방법.
6. 제 1 항에 있어서,

   상기 요청 엔티티는 컨텐츠 발행자 (CI; content issuer) 이고 상기 목표 엔티티는 디바이스인 것인, 플랫폼 무결성 체킹 방법.
7. 제 6 항에 있어서,

   상기 방법은 상기 디바이스가 자신의 플랫폼 무결성 상태를 상기 CI 에 대해 가장 최근에 검증했던 때로부터의 경과 시간에 기초하여 주기적으로 수행되는 것인, 플랫폼 무결성 체킹 방법.
8. 제 6 항에 있어서,

   상기 방법은 상기 디바이스가 상기 CI 로부터 컨텐츠를 구입할 때 수행되는 것인, 플랫폼 무결성 체킹 방법.
9. 요청 엔티티 (RE) 와 목표 엔티티 (TE) 사이에서 디지탈 권리 관리 (DRM) 소프트웨어 무결성 체킹을 수행하기 위한 방법으로서,

   목표 엔티티에 대하여, DRM 소프트웨어 무결성 체크를 수행하라는 요청을 요청 엔티티로부터 수신하고;

   상기 목표 엔티티에 의해 상기 DRM 소프트웨어 무결성을 체킹하며;

   상기 요청 엔티티에 DRM 소프트웨어 무결성 상태 표시자를 보내는 것

   을 포함하는 DRM 소프트웨어 무결성 체킹 방법.
10. 제 9 항에 있어서,

    상기 요청 엔티티는 권리 발행자 (RI) 이고 상기 목표 엔티티는 디바이스인 것인, DRM 소프트웨어 무결성 체킹 방법.
11. 제 10 항에 있어서,

    상기 디바이스가 권리 오브젝트 획득 프로토콜 (ROAP) 프로세스를 시작하기 전에 상기 방법을 시작하도록 상기 디바이스가 상기 RI 에 트리거를 보내는 것인, DRM 소프트웨어 무결성 체킹 방법.
12. 제 11 항에 있어서,

    상기 ROAP 프로세스는 2 패스 등록, 2 패스 도메인 가입, 및 2 패스 도메인 탈퇴 중 적어도 하나로부터 선택되는 것인, DRM 소프트웨어 무결성 체킹 방법.
13. 제 10 항에 있어서,

    상기 방법은 상기 디바이스가 상기 RI 와의 권리 오브젝트 획득 프로토콜 (ROAP) 프로세스를 완료한 후에 주기적으로 수행되는 것인, DRM 소프트웨어 무결성 체킹 방법.
14. 제 13 항에 있어서,

    상기 ROAP 프로세스는 2 패스 등록, 2 패스 도메인 가입, 및 2 패스 도메인 탈퇴 중 적어도 하나로부터 선택되는 것인, DRM 소프트웨어 무결성 체킹 방법.
15. 제 10 항에 있어서,

    상기 방법은 상기 디바이스가 자신의 DRM 소프트웨어 무결성 상태를 상기 RI 에 대해 검증하고 보고한 후에 주기적으로 수행되는 것인, DRM 소프트웨어 무결성 체킹 방법.
16. 제 10 항에 있어서,

    상기 방법은 상기 디바이스가 자신의 DRM 소프트웨어를 갱신한 후에 수행되는 것인, DRM 소프트웨어 무결성 체킹 방법.
17. 제 10 항에 있어서,

    상기 RI 는 상기 디바이스 상의 미디어 플레이어에 대한 DRM 소프트웨어 무결성 체크를 수행하도록 상기 디바이스에 요청하는 것인, DRM 소프트웨어 무결성 체킹 방법.
18. 제 9 항에 있어서,

    상기 요청 엔티티는 컨텐츠 발행자 (CI) 이고 상기 목표 엔티티는 디바이스인 것인, DRM 소프트웨어 무결성 체킹 방법.
19. 제 18 항에 있어서,

    상기 디바이스가 권리 오브젝트 획득 프로토콜 (ROAP) 프로세스를 시작하기 전에 상기 방법을 시작하도록 상기 디바이스가 상기 CI 에 트리거를 보내는 것인, DRM 소프트웨어 무결성 체킹 방법.
20. 제 18 항에 있어서,

    상기 방법은 상기 디바이스가 상기 CI 와의 권리 오브젝트 획득 프로토콜 (ROAP) 프로세스를 완료한 후에 주기적으로 수행되는 것인, DRM 소프트웨어 무결성 체킹 방법.
21. 제 18 항에 있어서,

    상기 방법은 상기 디바이스가 자신의 DRM 소프트웨어 무결성 상태를 상기 CI 에 대해 검증하고 보고한 후에 주기적으로 수행되는 것인, DRM 소프트웨어 무결성 체킹 방법.
22. 제 18 항에 있어서,

    상기 방법은 상기 디바이스가 자신의 DRM 소프트웨어를 갱신한 후에 수행되는 것인, DRM 소프트웨어 무결성 체킹 방법.
23. 제 18 항에 있어서,

    상기 CI 는 상기 디바이스 상의 미디어 플레이어에 대한 DRM 소프트웨어 무결성 체크를 수행하도록 상기 디바이스에 요청하는 것인, DRM 소프트웨어 무결성 체킹 방법.
24. 2 개의 엔티티 사이에서 교환되는 권리 오브젝트 획득 프로토콜 (ROAP) 메시지의 무결성을 강화하기 위한 방법으로서,

    트러스티드 컴퓨팅 기술을 사용하여 각각의 엔티티에서 ROAP 메시지에 사용될 정보를 안전하게 저장하며;

    상기 ROAP 메시지에 사용될 상기 정보를, 상기 ROAP 메시지와 관련하여 사용되기 전에, 사전-검증하는 것

    을 포함하는 ROAP 메시지의 무결성 강화 방법.
25. 제 24 항에 있어서,

    상기 저장은,

    상기 정보를 서명 날인(sealed-signing)하고;

    상기 정보를 바인딩(binding)하는 것

    을 포함하는 것인, ROAP 메시지의 무결성 강화 방법.
26. 제 25 항에 있어서,

    상기 서명 날인은,

    상기 정보를 대칭 암호화 키를 사용하여 대칭적으로 암호화하고;

    상기 대칭 암호화 키 및 오브젝트의 현재의 무결성 상태를 나타내는 값 세트에 비대칭적으로 서명하는 것

    을 포함하는 것인, ROAP 메시지의 무결성 강화 방법.
27. 제 25 항에 있어서,

    상기 바인딩은, 비밀 암호해독 키가 상기 엔티티의 보호 모듈 내에 저장되어 있는 키를 사용하여 상기 정보를 비대칭적으로 암호화하는 것을 포함하는 것인, ROAP 메시지의 무결성 강화 방법.
28. 제 27 항에 있어서,

    상기 보호 모듈은 상기 ROAP 메시지에 사용할 파라미터를 유도하는 트러스티드 프로세싱 모듈 (TPM; trusted processing module) 인 것인, ROAP 메시지의 무결성 강화 방법.
29. 제 24 항에 있어서,

    상기 정보는, 디바이스 ID, 권리 발행자 ID, 인증서, 인증서 체인, 디지탈 권리 관리와 관련된 시간값, 권리 오브젝트, 알고리즘, 및 넌스(nonce) 중 적어도 하나로부터 선택되는 것인, ROAP 메시지의 무결성 강화 방법.
30. 제 24 항에 있어서,

    송신 엔티티의 트러스티드 컴퓨팅 능력을 나타내는 필드를 기존의 ROAP 메시지에 부가하는 것을 더 포함하는, ROAP 메시지의 무결성 강화 방법.
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제
41. 삭제
42. 삭제
43. 삭제
44. 삭제
45. 삭제
46. 삭제
47. 삭제
48. 삭제
49. 삭제
50. 삭제
51. 삭제
52. 삭제
53. 삭제
54. 삭제
55. 삭제
56. 삭제
57. 삭제
58. 삭제
59. 삭제
60. 삭제

Images