KR20060054419A

KR20060054419A - 디지털 방송 시스템에서의 복제-방지 애플리케이션들

Info

Publication number: KR20060054419A
Application number: KR1020067002314A
Authority: KR
Inventors: 조나단 지. 포스터; 임모 벤제스
Original assignee: 코닌클리케 필립스 일렉트로닉스 엔.브이.
Priority date: 2003-08-02
Filing date: 2004-07-28
Publication date: 2006-05-22
Also published as: CN1833224A; JP2007501556A; US20060191015A1; EP1654638A1; GB0318197D0; WO2005013126A1

Abstract

DVB-MHP와 같은 디지털 방송 시스템은 애플리케이션(320)을 암호화한 형태로 단말기들(60)에 전송한다. 암호화 방법, 비용 및 지불 상세 사항들과 같은, 애플리케이션에 관한 상세 사항들이 단말기들에 전송된다. 단말기들은 인증 엔티티(55)로부터 애플리케이션(320)에 액세스하기 위한 인증을 얻기 위해서 대화형 채널(85)을 사용한다. 인증된 단말기들은 암호화된 애플리케이션(320)을 복호화하는데 사용될 수 있는 키(215)를 수신한다. 단말기들을 인증하기 위한 기능은 단말기(60)에 상주할 수 있고 아니면 단말기에 의해 수신되는 런처 애플리케이션(310, 도 5)의 일부를 이룰 수 있다.

디지털 방송 시스템, 런처 애플리케이션, 인증 엔티티, 대화형 채널, 애플리케이션 로더

Description

디지털 방송 시스템에서의 복제-방지 애플리케이션들{Copy-protecting applications in a digital broadcasting system}

본 발명은 디지털 방송 시스템들에 관한 것으로 이러한 시스템들에서 단말기들에 애플리케이션들의 전달에 관한 것이다. 본 발명은 특히 디지털 비디오 방송 멀티미디어 홈 플랫폼(DVB-MHP) 및 유사 시스템들에 적용할 수 있다.

디지털 비디오 방송(DVB) 시스템들은 원래 오디오 및 비디오물을 전달하기 위해 개발되었다. 최근에 다운로드되어 단말기들에 의해 실행될 수 있는 애플리케이션들을 전달하는데 관심이 증대되고 있다. 디지털 비디오 방송 멀티미디어 홈 플랫폼(DVB-MHP)은 멀티미디어 셋 탑 박스들에 대한 표준들을 일치시키려는 노력들의 결과이다. 이것은 대화형 디지털 텔레비전에 대해 공개 및 반포된 표준이다. DVB-MHP, 또는 간단히 MHP는 대화형 디지털 애플리케이션들과 이들 애플리케이션들을 실행하는 단말기들간의 일반적인 인터페이스를 정의한다. MHP 표준들, 이를테면 ETSI TS 101 812 V1. 3.1은 www.etsi.org에서 볼 수 있다. MHP 표준의 버전 1.0.3은 'Xlets"라고 하는 무료로 다운로딩될 수 있는 애플리케이션들을 지원한다. ETSI TS 102 819에 기재된, 디지털 비디오 방송 전역 실행가능의 MHP(DVB-GEM)도, 또한 다운로딩가능한 애플리케이션들을 지원한다.

일부 방송국들은 이들의 서비스들에 가입을 한 자들에게만, 방송 채널들 또는 애플리케이션들과 같은 콘텐트로의 액세스를 제한하도록 조건부 액세스(CA) 시스템을 사용하여 전체 방송 스트림을 암호화하는 것을 선택한다. 이것이 콘텐트의 저작권 침해에 대한 고도의 보호를 제공하는 것으로 알려졌지만, 이것은 사용자의 셋-탑 박스에 전용의 디스크램블링 하드웨어를 요구한다. 뷰어들은 CA 시스템을 포함하는 특별한 셋-탑 박스, 또는 DVB 공통 인터페이스(DVB-CI) 및 CA 시스템을 내장한 CI-모듈에 따르는 슬롯을 갖춘 셋-탑 박스 중 하나를 필요로 한다. 뷰어들은 또한, 이들을 식별하는 스마트카드를 필요로 하며, 방송국은 인증된 스마트카드들의 중앙 데이터베이스를 유지할 필요가 있다. 다수의 방송국들은 CA 시스템에 대하여 그들 자신의 전용의 암호화 알고리즘들을 사용한다. 현실적으로, 월 가입비를 부과하는 방송국들만이 CA 시스템을 위해 요구되는 기반구조를 셋업할 여유가 있다. 이러한 것을 고려하여, 대부분의 방송국들은 이러한 방식으로 전체 전송 스트림을 암호화하지 않기로 선택되었다.

게임들과 같은 유료 사용(pay-per-use) 애플리케이션들을 사용자 단말기들에 전달하는 것이 방송국에게 추가의 수익을 발생시킬 수 있기 때문에 이에 관심이 있다. 그러나, 현재의 MHP 표준들은 암호화된 애플리케이션들에 대한 지원을 포함하지 않는다. 애플리케이션들을 암호화하는 능력이 없고, 그리고 CA 시스템이 없으면, 사용자 단말기들에 전달된 어떠한 애플리케이션들이든 저작권 침해에 취약하다. 실제로, 어떤 애플리케이션들용의 코드를 포함하여, 방송 스트림의 일부로서 방송되는 파일 시스템의 전체 콘텐트들을 '그랩'하여, 이를 하드디스크에 저장할 수 있는 장비를 얻는 것이 이미 가능하다.

많은 MHP 애플리케이션들은 이들을 모방하기가 더욱 어렵게 하여 까다롭게 된다. 이것은 기술적인 라벨들이 제거하거나 보다 덜 기술적인 라벨들로 새로운 이름을 붙여지도록 코드를 처리하는 것을 의미한다. 이것은 해커가 애플리케이션의 동작을 변형하는 것을 더욱 어렵게 하지만, 애플리케이션들이 불법으로 저장 또는 실행되는 것을 막진 못한다.

본 발명은 암호화된 애플리케이션들을 단말기들에 전달하는 방법을 제공하고자 하는 것이다.

따라서, 본 발명의 제 1 양태는 디지털 방송 시스템에서 암호화된 애플리케이션을 상기 단말기(60)로 수신하는 방법에 있어서, 단말기는 외부 상대측에 시그널링을 전달할 수 있는 대화형 채널에 액세스하고, 상기 방법은,

암호화된 애플리케이션(320)에 관한 상세 사항들을 수신하는 단계;

대화형 채널을 통해 인증 요청을 인증 엔티티로 보냄으로써 단말기(60)가 애플리케이션(320)에 액세스하는 것을 인증하는 단계;

인증된 것에 응답하여 상기 대화형 채널을 통해 키를 수신하는 단계;

암호화된 애플리케이션을 수신하는 단계; 및

암호화된 애플리케이션을 수신된 키를 사용하여 복호화하는 단계를 포함하는 상기 수신 방법을 제공한다.

이로부터 발생하는 이점들 중 일부는 사용자들이 서비스에 가입할 필요가 없다는 것으로, 단말기에서 가입 카드들, 조건부 액세스(CA) 시스템 또는 CA 모듈이 필요성이 없다. 사용자들은 가입을 진행함이 없이 이들이 원하는 어떤 애플리케이션이든 이에 간단히 지불할 수 있고, 복수의 애플리케이션 제공자들은 사용자가 이들의 단말기에 복수의 전용 CA 모듈들을 필요로 하는 문제가 없이 상기 방식으로 애플리케이션을 제공할 수 있다. 트랜잭션들을 취급하는 단일 인증 엔티티가 있을 필요는 없고, 따라서 어떠한 사용자 데이터도 애플리케이션 제공자들간에 공유되지 않아야 한다. 다양한 암호화/복호화 알고리즘들, 키 길이들 및 지불 시스템들이 쉽게 수용될 수 있다.

단말기를 인증하도록 구성하는 단계 및/또는 애플리케이션을 복호화하는 단계는 단말기에 의해 수신되는 런처 애플리케이션(launcher application)에 의해 수행될 수 있다. 바람직하게는, 런처 애플리케이션은 비암호화된 형태로 방송된다. 런처 애플리케이션이 사용되는 경우, 암호화된 주 애플리케이션은 런처 애플리케이션에 동일하거나 다른 전달 채널을 통해 전달될 수 있다.

런처 애플리케이션을 사용하는 바람직한 대안은 런처 애플리케이션의 기능을 단말기 자체에 탑재시키는 것이다. 기능은 소프트웨어, 하드웨어 또는 이들의 조합으로 구현될 수 있다. 따라서, 본 발명의 다른 양태들은 디지털 방송 시스템에서 단말기용 제어장치, 단말기의 동작을 제어하는 소프트웨어 및 제어장치 또는 소프트웨어를 탑재한 단말기를 제공한다. 소프트웨어는 제조시에 단말기에 설치될 수 있거나, 후에 업그레이드로서 현존 단말기에 설치될 수 있다. 소프트웨어는 전자 메모리 디바이스, 하드디스크, 광학 디스크 또는 그 외 머신-판독가능 저장매체에 저장될 수 있다. 소프트웨어는 머신-판독가능 캐리어로 전달될 수 있거나 네트워크를 통해 단말기에 직접 다운로딩될 수 있다.

본 발명의 또 다른 양태는 디지털 방송 시스템에서 애플리케이션을 단말기(60)로 전송하는 방법에 있어서, 단말기(60)는 외부 상대측(55)에 시그널링을 전달할 수 있는 대화형 채널(85)에 액세스하고, 상기 방법은,

암호화된 애플리케이션에 관한 상세 사항들을 전송하는 단계로서, 인증 요청(314)을 대화형 채널(85)을 통해 인증 엔티티(55)로 보냄으로써 암호화된 애플리케이션(320)에 액세스하기 위해 단말기(60)를 인증하고; 인증된 것에 응답하여 대화형 채널(85)을 통해 키(215)를 수신하고; 키(215)를 사용하여 상기 애플리케이션을 복호화하도록 구성되는 런처 애플리케이션(310)을 포함하는, 상기 전송 단계; 및

상기 암호화된 애플리케이션(320)을 전송하는 단계를 포함하는, 전송 방법을 제공한다.

본 발명의 또 다른 양태는 조건부 액세스(CA) 시스템이 사용되지 않는 디지털 방송 시스템에서 암호화된 애플리케이션을 단말기에 전송하는 방법에 있어서,

상기 암호화된 애플리케이션에 관한 비암호화된 상세 사항들은 애플리케이션을 암호화하는데 사용되는 암호화 방법; 애플리케이션의 비용; 지불 상세 사항들 중 하나 이상을 포함하는, 상기 비암호화된 상세 사항들을 전송하는 단계; 및

암호화된 애플리케이션을 전송하는 단계를 포함하는, 전송 방법을 제공한다.

본 발명은 비록 디지털 비디오 방송 시스템들에 널리 적용될 수 있을지라도 멀티미디어 홈 플랫폼(MHP)의 현 버전들로의 확장으로서 특히 적용가능하다. 이들은 다음을 포함한다.

. DVB-GEM (ETSI TS 102 819) = 전역 실행가능 MHP - 이것은 DVB-SI에 의존하지 않는 MHP의 서브세트이다.

. OCAP = 오픈케이블 애플리케이션 플랫폼(OpenCable Application Platform), GEM에 기초한 새로운 US 케이블 표준;

. ATSC-DASE = ATSC(Advanced Television Systems Committee) 디지털 TV 애플리케이션 소프트웨어 환경(DASE), US 지상 표준, GEB에 기초하여 현재 재구성되고 있음:

. ARIB-AE = ARIB(일본 TV 표준 단체) 표준B-23 " 디지털 방송용 애플리케이션 실행 엔진 플랫폼(Application Execution Engine Platform for Digital Broadcasting; ARIB-AE)", GEM에 기초함.

도 1은 본 발명을 구현하는 디지털 비디오 방송(DVB) 시스템을 도시하는 도면.

도 2는 도 1의 시스템에서 가입자 단말기 내에 기능 블록들을 도시하는 도면.

도 3은 암호화된 애플리케이션을 수신함에 있어 단계들의 흐름도.

도 4는 단말기의 부분들 및 도 1의 인증 엔티티를 보다 상세히 도시하는 도면.

도 5는 런처 애플리케이션이 암호화된 주 애플리케이션 이전에 다운로딩되는 본 발명의 대안적인 실시예를 도시하는 도면.

본 발명의 실시예들을 첨부한 도면을 참조하여 단지 예로서 기술한다.

본 발명의 실시예들은 첨부하는 도면들을 참조하여 단지 예로서 여기에 기술될 것이다.

도 1은 단말기에 애플리케이션들을 전달하기 위한 디지털 비디오 방송 시스템들을 도시한다. 콘텐트는 방송국(30)에 의해 생성되고 방송 채널(35)을 통해 사용자측(100)에 전송을 위한 적합한 포맷으로 변환된다. 하나의 이러한 사용자측(100)이 도시되었다. 일반적으로, 방송 채널(35)은 비록 지상 전송 네트워크, 케이블 전달 네트워크, 또는 인터넷과 같은 데이터 네트워크에 의해 전달될 수 있을 지라도 위성을 통해 전달되고, 전달 방법은 본 발명에 중요하지 않다. 사용자측에 있는 단말기(STB)(60)는 이 실시예에는 안테나(18)를 통해 오는 방송 스트림을 수신한다. 방송 채널(35)을 통해 전달되는 방송 스트림은 각종의 서비스들 및 애플리케이션들을 지원하는 데이터뿐만 아니라 오디오 및 비디오 콘텐트를 포함한다. DVB-MHP 명세에서, 애플리케이션들용 데이터는 디지털 저장 미디어-명령 및 제어(DSM-CC) 오브젝트 캐로셀의 일부로서 방송된다. 이것은 여러 가지 애플리케이션들용 데이터 파일들을 포함하는 반복적으로 방송하는 파일 시스템이다. DSM-CC을 포함하는 DVB-MHP 시스템용 방송 채널의 포맷은 ISO/IEC 13818-6에 상술되어 있고, 당업자는 다른 정보를 위해 이를 참조할 수 있다.

애플리케이션들은 방송국(30)에 의해서, 또는 DSM-CC에 삽입을 위해 방송국 (30)에 요청된 파일들을 공급하는 독립 애플리케이션 제공자들(50)에 의해 생성될 수 있다. 애플리케이션들의 예들은 전자 프로그램 가이드(electronic programme guide; EPG), 게임들, 퀴즈들, 명령 가이드, 및 홈 뱅킹과 같은 전자상거래 애플리케이션들을 포함한다.

셋 탑 박스(60)는 데이터를 외부 상대측들에 보내고 데이터를 이들로부터 수신할 수 있게 하기 위해서 대화형 채널(85)을 지원하는 모뎀을 또한 구비한다. 대화형 채널(85)은 통상적으로 POTS와 같은 통상의 전화 네트워크(telephony network)를 사용한다. 대화형 채널(85)은 POTS를 통해 직접 애플리케이션 제공자(50)로의 다이얼-업 접속, 데이터 네트워크를 통해 접속이 게이트웨이와 애플리케이션 제공자(50)간에 이루어지는, 인터넷과 같은 데이터 네트워크의 게이트웨이로의 접속, 케이블 백-채널과 데이터 네트워크(인터넷)를 통한 애플리케이션 제공자로의 접속과의 조합, ADSL 또는 그외 광대역 인터넷 접속, 위성 업링크 또는 ISDN 회선의 형태를 취할 수 있다.

셋 탑 박스(60)는 또한 사용자 입력들을 수신하는 원격 제어(20) 또는 키보드를 구비한 사용자 인터페이스, 및 텔레비전 디스플레이(12)에 공급되는 비디오 신호(10)에 중첩될 수 있는 메시지들을 디스플레이하는 그래픽 출력을 포함한다.

MHP단말기는 자바 가상 머신(Java^TM Virtual Machine; JVM)으로 구축되고, 애플리케이션들은 자바로 작성된다. 자바의 사용은 애플리케이션들이 공통의 포맷으로 작성될 수 있어, 각 유형의 단말기 내 가상 머신은 이 단말기에 있는 특정한 하드웨어 및 소프트웨어에 호환되는 형태로 자바 바이트코드(java bytecode)를 변환할 수 있는 이점을 갖는다.

도 2는 일반적인 MHP 단말기(60) 내의 기능 블록들을 도시한다. 알려진 방식으로, 단말기(60)는 수신된 방송 신호(35)를 처리하기 위한 프론트 엔드(front end)를 포함한다. 이는 요청된 채널을 선택하여 복조하기 위한 튜너 및 복조기(61) 및 신호를 디스크램블링하기 위한 선택적 조건부 액세스 유닛(62)을 포함한다. 그 결과로 디지털 데이터 스트림은 오디오 및 비디오 데이터(통상적으로 MPEG-2 포맷)를 나타내는 데이터 스트림들, 및 반복적으로 방송되는 DSM-CC 오브젝트 캐로셀(64) 형태의 애플리케이션들을 위한 데이터로 역다중화된다. 오디오 및 비디오 데이터는 사용자로의 표현을 위한 적합한 출력 신호들(10, 14)을 도출하기 위해서 후속 처리될 수 있다(65). 방송 스트림으로부터 일단 다운로딩되면, 애플리케이션(또는 몇 개의 애플리케이션들)은 단말기 내 메모리(69)에 상주하여 마이크로프로세서(68)에 의해 실행될 것이다. 애플리케이션은 사용자 입력들(22)을 수신하고, 오디오 및 비디오 출력들을 생성하고, 애플리케이션 프로그래밍 인터페이스(Application Programming Interface; API)를 통해 대화형 채널(85)에 액세스할 수 있다. 단말기를 작동하는 제어 소프트웨어는 또한 메모리 디바이스 상에 상주한다. 도 2는 방송 전달 채널을 통해 신호들을 수신하도록 된 단말기를 도시한다. 비-방송 전달 채널들과 인터페이스하도록 한 단말기의 다른 실시예들에서, 튜너/복조기(61)는 전달 채널에 적합한 네트워크 인터페이스로 대체된다. 이는 인터넷 프로토콜(IP)-기반 전달 채널일 수 있다.

본 발명에 따라서, 애플리케이션들은 암호화된 형태로 전송된다. 단말기(60)가 암호화된 애플리케이션들을 처리하게 수정될 수 있는 근본적으로 2가지 방법들이 있다.

제 1 방법은 주 애플리케이션보다 앞서 방송 스트림(35)으로부터 다운로딩되는 암호화되지 않은 런처 애플리케이션을 이용한다. 런처 애플리케이션들은 예를 들면, 애플리케이션에 대한 지불을 처리하고, 복호화 키를 얻고 암호화된 애플리케이션을 기동시킴으로써, 단말기를 인증하는 기능들을 단말기가 구현하게 하는 코드를 포함한다. 런처 애플리케이션의 사용은 API를 통해 기능을 노출시키는 문제를 갖는다.

제 2 방법은 런처 애플리케이션의 기능을 단말기에 탑재시키고, 애플리케이션의 비용, 사용이 된 암호화 알고리즘, 및 복호화 키를 얻기 위한 접촉 상세 사항들과 같은, 애플리케이션에 관한 정보를 포함하도록 방송 시그널링이 수정된다.

도 3 및 도 4는 암호화된 애플리케이션을 방송 스트림으로부터 다운로딩하는 프로세스의 제 1 실시예를 도시한다. 이 실시예에서, 암호화된 애플리케이션들을 처리하기 위한 기능은 단말기 내 내장되어 있으며, 즉, 어떠한 런처 애플리케이션도 요구되지 않는다. 도 3은 프로세스의 단계들의 흐름도이고 도 4는 단말기(60) 및 애플리케이션 제공자(50) 내 기능 블록들의 일부와 암호화 키들의 전송을 도시한다.

먼저, 단계 500에서, 단말기(STB)는 다운로딩하는데 이용할 수 있는 애플리케이션들의 상세 사항들을 수신한다. 이 정보는 애플리케이션 정보 테이블 (Application Information Table; AIT)로 전달된다. 테이블은 MPEG 섹션들을 통해(이진 형태(binary form)로) 전송된다. 테이블의 모든 필드들은 MHP 명세에 명시되었다. AIT는 다음과 같은 상세 사항들을 포함하도록 변형되는 것이 바람직하다.

. (키 길이를 포함하는) 애플리케이션들을 암호화하는데 사용이 된 암호화 방법.

. 사용될 수 있는 지불 방법들, 및 전화번호 또는 애플리케이션 제공자의 서버 어드레스와 같이, 인증을 위해 애플리케이션 제공자에 접촉하는 방법의 상세 사항들.

. 애플리케이션의 가격과 같은, 사용자에게 디스플레이하는 정보.

다음은 AIT가 수정될 수 있는 방법의 예이다.

암호화된 애플리케이션들 및 애플리케이션들을 암호화하는데 필요한 정보를 보내기 위한 상이한 방법들이 있다.

먼저, application_type 필드는 이 AIT 내 모든 애플리케이션들은 암호화된 애플리케이션들이라는 정보를 내포할 것임을 정의하는 것이 가능하다. 현재, 이 필드는 0x0001(DVB-J 애플리케이션) 또는 0x0002(DVB-HTML)의 값들을 가질 수 있다. 이것은 15비트 필드이기 때문에, 최대값은 Ox7FFF일 수 있다. 한 가능성은 암호화된 애플리케이션들(AIT 내 모든 애플리케이션들은 암호화되어 있음)을 확인하기 위해 0x4000의 마스크를 사용하는 것이다. 암호화된 DVB-J 애플리케이션(정규 MHP 애플리케이션)은 application_type 0x4001(Ox0001｜Ox4000)을 가질 것이다.

또 다른 가능성은 암호화된 애플리케이션을 확인하기 위해서 애플리케이션 루프 내 한 비트의 예약된 4 비트(필드 2)를 사용한 것이다. 다시, 암호화 정보를 알리는 두 가지 방법들이 있다. 이를 위한 디스크립터를 'Descriptor A"로서 위에 표시된 위치에서 정의함으로써 AIT에 부가될 수 있다. 이것은 AIT가 매우 작아야 하기 때문에(1K 미만) 바람직하지 않다. 이것은 각각의 AIT가 그 자신의 PID를 갖지 않고, 하나 이상의 AIT가 전송될 필요가 있음을 의미한다. 디스크립터는 다음과 같을 수 있다.

다이얼 업 접속에 있어서, 텍스트로 된 로케이터는 모뎀이 다이얼할 전화 번호일 것이며, IP 접속에 있어서 텍스트 로케이터는 URL일 것이다.

제 2의 바람직한 방법은 다음과 같다. AIT에 명시된(트랜스포트 프로토콜 디스크립터를 통해) DSM-CC 오브젝트 캐로셀에는 각각의 암호화된 애플리케이션에 대한 XML 파일이 있거나(예를 들면 "organisation_id", "application_id"-encryption,xml 명칭의), 그 오브젝트 캐로셀에 모든 암호화된 애플리케이션들에 관한 정보를 포함하는 하나의 XML 파일이 있다. 이러한 XML 파일은 다음과 같을 수 있을 것이다.

단말기 ClassLoader는 두 개의 서로 다른 애플리케이션 classpath들, 즉 클래스들을 탐색하는 경로를 가질 것이다. 이것은 정규 classpath(암호화되지 않은 클래스들을 변경하는) 및 암호화된-classpath(암호화된 클래스들을 발견하는)을 가질 것이다. 따라서, AIT를 파싱하였을 때, 단말기는 애플리케이션이 암호화되어있는지를 체크해야 하다. 암호화되어있다면, 디스크립터들 중 하나에 특정된 classpath는 encrypted_classpath에 부가되고, 그렇지 않다면 정규 classpath에 부가된다.

AIT는 애플리케이션이 단말기에 의해 저장 또는 복제될 수 있는지를 나타내는 플래그를 또한 포함할 수 있다. 이들 확장들은 임의의 단말기이 이들 상세들을 올바르게 해석할 수 있게 표준화된 것이 바람직하다.

다음에, 단계 502에서, 사용자는 가용 애플리케이션들 중 하나를 선택하고 다운로드 프로세스를 개시한다. 이어서, 단말기는 애플리케이션에 액세스하기 위해 단말기를 인증하는 프로세스를 시작한다. 단말기에 의해 취해지는 동작은 AIT 또는 XML 파일에 있는 확장들에 의해 결정된다. 단계 506에서 단말기(60)는 애플리케이션의 비용를 나타내며(AIT에 있음) 이들이 애플리케이션에 대해 지불할 것을 동의하는지를 사용자에게 묻는 메시지를 표시한다. 사용자가 지불하기를 원하지 않는다면, 오류 메시지가 표시될 수 있고 아무 것도 일어나지 않는다. 사용자가 애플리케이션에 지불을 동의한다면, 단말기는 단계 510으로 진행하여 대화형 채널(85)을 사용해서 애플리케이션 제공자(50)의 인증/지불 실체(55)에 전화를 걸어 인증 요청(314)을 보낸다. 이 예에서, 애플리케이션에 지불하는 메커니즘은 할증 전화번호로 전화를 거는 단말기에 의한다.

도 4는 단말기(60)와 애플리케이션 제공자(50)간에 발생하는 암호화 키들의 교환을 도시한 것이다. 단말기는 한 쌍의 암호화 키들로서 공개 키(210) 및 비밀 키(220)를 갖는다. 이 한 쌍의 키들(210, 220)은 단말기에 고유한 것으로 단말기의 제조업자에 의해 서명되고, 이어서 신용 인증기관에 의해 서명된다. 인증서는 단말기이 MHP 표준에 따르는 것으로 인증되었을 때 주어질 수 있다. 비밀 키(220)는 단말기를 결코 이탈하지 않으며 애플리케이션들에 직접 노출되지 않는다. 비밀 키(220)는 TCPA(Trusted Computing Platform Alliance)/Palladium과 같은 변조방지 하드웨어(222)에 저장될 수도 있다.

단말기(60)가 먼저 애플리케이션 제공자(50)에 접촉할 때, 공개 키(210)를 보낸다. 공개 키(210)를 수신하였을 때, 인증 엔티티(55)의 인증유닛(56)은 이 키가 유효한지를 체크한다. 공개 키(210)는 단말기(60)를 식별하는데 사용될 수 있다. 위에서 설명한 서명 및 인증서 체인은 키(210)가 승인된 MHP 단말기에서 비롯 된 것임을 확실히 하기 위해서 사용된다. 무효한 키들(57)의 '블랙 리스트'가 참조될 수도 있다. 단말기들은 이를테면 단말기이 해킹된 것으로 알려졌을 때 또는 이 키를 가진 단말기이 이전 경우에 무효한 지불상태를 제공하였을 때와 같은, 각종의 이유들로 블랙 리스트에 올라 있을 수 있다. 이들 중 어느 것이, 키를 보낸 단말기이 인증되지 않았음을 또는 관계된 것임을 나타낸다면, 오류 메시지가 단계 514에서 리턴될 수 있다.

키가 유효하다면, 애플리케이션 제공자(50)는 할증전화번호에의 호의 기간이 요청된 애플리케이션의 가격과 같게 될 때까지(즉, 사용자가 기불하였을 때) 기다리고 애플리케이션 키(215)를 생성할 것을 키 생성기(58)에 명령한다. 이 키(215)는 단말기이 요청한 애플리케이션을 복호화할 것이다. 애플리케이션 키(215)는 암호화된 애플리케이션 키(216)를 도출하기 위해서 STB 공개 키(210)를 사용하여 암호화되는 것이 바람직하다. 암호화된 애플리케이션 키(216)는 대화형 채널(85)을 통해 단말기(60)에 리턴된다.

단계 518에서, 단말기는 암호화된 애플리케이션 키(216)를 수신한다. 단말기는 애플리케이션 키(215)을 한번 더 도출하기 위해서 자신의 비밀 키(220)를 사용하여 키를 복호한다(225). 이어서 단말기는 DSM-CC로부터 암호화된 애플리케이션(320)을 다운로드하기 시작한다. 단계 520에서, 애플리케이션은 키(215)를 사용하여 복호화되고 복호화된 애플리케이션(330)은 통상의 방식으로 실행될 수 있다.

DES(Data Encryption Standard), 3DES(Triple Data Encryption Standard), AES(Advanced Encryption Standard) 및 BlowFish과 같은 임의의 표준 복호화 알고 리즘이든 사용될 수 있다. 단말기는 복수의 암호화 표준들을 또는 단지 하나만을 지원할 수도 있다.

애플리케이션 키(215)는 미래의 사용을 위해 단말기(60)에 저장될 수도 있고 또는 애플리케이션의 유형에 따라, 애플리케이션이 클로즈될 때 폐기될 수도 있다. 지불형 사용 애플리케이션들은 매 경우마다 새로운 키를 요할 것이지만, 1회 지불형 애플리케이션들은 매 경우마다 동일 키를 사용할 수도 있다. 단말기는 복호화된 애플리케이션 전체를 저장할 수 있는 충분한 영구적 저장소를 구비하지 않을 수도 있다. 암호화된 애플리케이션이 계속적으로 방송되고 있다면 단말기는 단순히 키만을 저장할 수 있다. 사용자가 애플리케이션을 실행시키기를 원하는 다음 번에 애플리케이션은 다시 다운로드되고 다시 복호화된다. 애플리케이션을 복호화하는데 필요한 키가 이미 단말기에 저장되어 있기 때문에, 사용자는 다시 지불할 필요가 없다. 또한, 애플리케이션이 장치 내 저장 디바이스에 캐시/저장될지라도, 애플리케이션은 장치 내 저장 디바이스로부터 애플리케이션을 해커들이 추출하지 못하게 암호화되어야 한다. 이 경우, 해커가 애플리케이션을 복사해 두었더라도, 여전히 암호화되어 있다. 애플리케이션 키가 암호화된 형태로 저장된다면(예를 들면, 애플리케이션 대화형 채널을 통해 전송된 바와 동일한 방식으로 단말기의 공개 키에 의해 암호화됨) 애플리케이션이 해커들에 의해 복호화될 수 있는 용이한 방법은 없을 것이다.

이 예에서, 인증은 할증 전화번화로 전화를 걸어 달성된다. 그러나, 인증이 달성될 수 있는 다양한 다른 방법들이 있다. 인증을 획득하는 몇가지 가능한 방법 들은 다음과 같다.

. 단말기는 사용자에게 신용카드 상세 사항들을 재촉한다. 신용카드 상세 사항들을 수신하였을 때, 단말기는 애플리케이션 제공자(50)의 지불 인증 엔티티(55)에 접촉하여 신용카드 상세 및 공개 키(210)를 건네준다. 인증유닛(56)은 신용카드 상세가 유효함을 체크하기 위해 외부기관에 접촉할 필요가 있을 수 있다. 지불이 수락되었다면, 암호화된 애플리케이션 키(216)가 전처럼 대화형 채널(85)을 통해 애플리케이션 제공자(50)로부터 단말기(60)에 리턴된다. 애플리케이션 제공자(50)가 단말기의 소유자임을 알고 있는 경우, 신용카드 상세는 애플리케이션 제공자가 보유한 상세와 비교될 수 있다.

. 단말기는 가입 또는 클럽 멤버쉽 번호를 아마도 암호 또는 PIN과 더불어서 사용자를 재촉한다. 그러면 단말기는 애플리케이션 제공자(50)에 콘택하여 이 정보와 공개 키(210)를 제공한다. 사용자가 인증되면, 암호화된 애플리케이션 키(216)가 애플리케이션 제공자(50)로부터 단말기(60)에 보내진다.

. 단말기는 단말기(60) 상의 카드 리더에 삽입된 스마트카드(예를 들면 German GeldKarte)로부터 지불을 받아 공개 키(210)를 애플리케이션 제공자(50)에 지불을 표시하는 메시지와 함께 보낸다. 암호화된 애플리케이션 키(216)가 애플리케이션 제공자(50)로부터 단말기(60)에 보내진다.

바람직하게는 어떤 방식으로 애플리케이션 제공자(50)에 지불한 후에, 키(216)를 얻기 위해 애플리케이션 제공자(50)에 단말기이 콘택하는 어떤 다른 수단이 사용될 수 있음을 알 것이다. 애플리케이션 키(215)는 제 3자들이 키를 가로채 어 이를 분배시킬 기회를 줄이기 위해서 클리어한 형태가 아닌 암호화된 형태로 보내지는 것이 바람직하다. STB 공개 키를 사용하여 애플리케이션 키(215)를 암호화하는 것은, 단말기이 애플리케이션 제공자(50)에 제시되는 인증서를 소유하고 있음을 보증한다. 애플리케이션 키(215)를 보안적으로 보내는 또 다른 방법은 SSL(Secure Socket Layer) 프로토콜과 같은 인증된 프로토콜을 사용하는 것이다. 단말기의 인증서는 클라이언트 인증서로서 사용될 수 있다.

도 5는 암호화된 주 애플리케이션(320)보다 먼저 런처 애플리케이션(310)이 전송되는 본 발명의 다른 실시예를 도시한 것이다. 이 실시예에서, 암호화된 애플리케이션에 관한 정보는 AIT 또는 XML 파일이 아닌 런처 애플리케이션에 들어 있어 런처 애플리케이션은 암호화된 애플리케이션을 알리는 커스텀 UI(사용자 인터페이스)를 생성할 수 있다.

런처 애플리케이션이 사용된다면 API는 복호화을 지원해야 한다. 런처 애플리케이션이 암호화된 MHP 애플리케이션을 단순히 시작한다면, 특별한 클래스로, 이를테면 정적 함수, 예를 들면,

public boolean startEncryptedApp (int org_id, int app_id, byte [] key);

과 같은 함수를 사용할 수 있다.

단말기는 ATI로부터 애플리케이션 정보를 수신하나, 런처 애플리케이션은 바이트 어레이를 통해 전달되는 애플리케이션 키를 얻어야 한다.

런처 애플리케이션이 주 애플리케이션이고 단순히 암호화된 모듈들을 로딩하기를 원한다면(자바 반영 API를 통해서) 또 다른, 공장에서 정의한 방법이 요구된 다.

public static ClassLoader createDecryptionCIassLoader(Encryptioninfo info, String [] classpath, byte [] key)

여기서, 클래스 'Encryptioninfo'은 사용되는 암호화 시스템에 관한 정보를 갖고 있고, 'classpath'은 classpath 어레이고 'key'는 키이다.

또 다른 대안적인 방법은 다음과 같다.

public static ClassLoader createDecryptionCIassLoader(DecryptionEngine decryptor, String [] classpath)

이것은 또한 새로운 ClassLoader를 생성하나, 이번에는 실제 복호화을 행하는 Class는 인수(augument)로서 전달된다. DecryptionEngine은 인터페이스일 것이다. 새로운 ClassLoader가 읽는 모든 것은 먼저 DecryptionEngine에 건네질 것이며 이후 ClassLoader에 의해 다시 읽혀질 것이다(복호화됨). 그러므로, 애플리케이션은 자신의 복호화 구현(예를 들면, 박스 내 복호화 알고리즘이 크랙된 것으로 알려졌을 때)을 전송할 수 있다. 키는 결코 애플리케이션을 이탈하지 않는다(암호화된 키의 사용(위를 참조)이 가능하지 않을 수도 있을지라도).

복호화 루틴들은 박스에 상존하나, 이들은 다운로드될 수도 있을 것임이 가능하다. 런처 애플리케이션은 새로운 ClassLoader를 생성할 것을 단말기(60)에 명령한다.

위의 실시예에서, 인증 엔티티(55)는 애플리케이션 제공자(50)의 일부인 것으로서 보여졌다. 이것은 그럴 필요는 없다. 인증 엔티티(55)는 물리적으로 애플 리케이션 제공자와는 떨어져 있을 수 있고 애플리케이션 제공자(50) 대신 인증기능을 수행할 수 있다.

애플리케이션(및 런처 애플리케이션, 있다면)은 이들이 리버스 엔지니어하기가 더욱 어렵게 되게 난처하게 하는 것이 바람직하다. 이것은 서술 라벨들을 제거하거나 덜 서술적인 라벨들로 개명되게 코드를 처리함을 의미한다. 따라서, 해커가 애플리케이션을 성공적으로 복호화하였더라도, 이들은 애플리케이션의 동작을 수정하는 것이 더욱 어렵다는 것을 알 것이다. 보다 짧고 비서술적인 라벨들의 사용은 코드의 크기를 감소시키는 데에도 도움을 준다.

본 발명은 여기 기술된 실시예들로 한정되는 것은 아니며 본 발명의 범위 내에서 수정 및 변형될 수 있다.

Claims

디지털 방송 시스템에서 암호화된 애플리케이션을 단말기(60)에 수신하는 방법에 있어서,

상기 단말기(60)는 외부 상대측(55)에 시그널링을 전달할 수 있는 대화형 채널(85)에 액세스하고, 상기 암호화된 애플리케이션 수신 방법은:

암호화된 애플리케이션(320)에 관한 상세 사항들을 수신하는 단계;

상기 대화형 채널(85)을 통해 인증 요청(314)을 인증 엔티티(55)로 보냄으로써 상기 단말기(60)가 상기 애플리케이션(320)에 액세스하는 것을 인증하는 단계;

인증된 것에 응답하여 상기 대화형 채널(85)을 통해 키(215)를 수신하는 단계;

상기 암호화된 애플리케이션(320)을 수신하는 단계;

상기 암호화된 애플리케이션(320)을 상기 수신된 키(215)를 사용하여 복호화하는 단계를 포함하는, 암호화된 애플리케이션 수신 방법.
제 1 항에 있어서,

상기 애플리케이션에 관한 상세 사항들을 수신하는 상기 단계는 상기 단말기를 인증하기 위해 구성된 런처 애플리케이션(310)을 수신하는 단계를 포함하는, 암호화된 애플리케이션 수신 방법.
제 1 항 또는 제 2 항에 있어서,

상기 애플리케이션에 관한 상세 사항들을 수신하는 상기 단계는 상기 애플리케이션(320)을 복호화하기 위해 구성된 런처 애플리케이션(310)을 수신하는 단계를 포함하는, 암호화된 애플리케이션 수신 방법.
제 2 항 또는 제 3 항에 있어서,

상기 런처 애플리케이션(310)은 상기 암호화된 애플리케이션(320)에 다른 전달 채널을 통해 수신되는, 암호화된 애플리케이션 수신 방법.
제 1 항 내지 제 4 항 중 어느 한 항에 있어서,

상기 애플리케이션을 복호화하는 상기 단계는 애플리케이션 로더(316)에 의해 수행되는, 암호화된 애플리케이션 수신 방법.
제 5 항에 있어서,

상기 애플리케이션 로더(316)는 Java ClassLoader인, 암호화된 애플리케이션 수신 방법.
제 1 항 내지 제 6 항 중 어느 한 항에 있어서,

상기 수신된 상세 사항들은 상기 애플리케이션을 암호화하는데 사용되는 암호화 방법; 상기 애플리케이션의 비용; 지불 상세 사항들 중 하나 이상을 포함하 는, 암호화된 애플리케이션 수신 방법.
제 1 항 내지 제 7 항 중 어느 한 항에 있어서,

상기 단말기의 사용자로부터 지불 상세 사항들을 수집하는 단계를 더 포함하는, 암호화된 애플리케이션 수신 방법.
제 1 항 내지 제 8 항 중 어느 한 항에 있어서,

상기 단말기의 사용자로부터 지불을 수집하는 단계를 더 포함하는, 암호화된 애플리케이션 수신 방법.
제 1 항 내지 제 9 항 중 어느 한 항에 있어서,

상기 단말기는 공개/비밀 키 쌍(210, 220)을 가지고, 외부 상대측(55)에 접촉하는 상기 단계는 상기 공개 키(210)를 상기 외부 상대측(55)에 보내는 단계를 포함하는, 암호화된 애플리케이션 수신 방법.
제 10 항에 있어서,

상기 공개 키(210)를 사용하여 암호화된 상기 외부 상대측으로부터의 복호화 키(216)를 수신하는 단계를 더 포함하는, 암호화된 애플리케이션 수신 방법.
제 10 항 또는 제 11 항에 있어서,

상기 공개/비밀 키 쌍은 상기 단말기를 고유하게 식별하는, 암호화된 애플리케이션 수신 방법.
제 10 항 내지 제 12 항 중 어느 한 항에 있어서,

상기 공개 키는 상기 단말기의 제조업자에 의해 서명되는, 암호화된 애플리케이션 수신 방법.
제 1 항 내지 제 13 항 중 어느 한 항에 있어서,

상기 디지털 방송 시스템은 조건부 액세스(CA) 시스템을 사용하지 않는, 암호화된 애플리케이션 수신 방법.
제 1 항 내지 제 14 항 중 어느 한 항에 있어서,

상기 디지털 방송 시스템은 멀티미디어 홈 플랫폼(MHP)인, 암호화된 애플리케이션 수신 방법.
제 1 항 내지 제 15 항 중 어느 한 항에 따른 방법을 수행하도록 구성되는 디지털 방송 시스템에서의 단말기용 제어장치.
제 1 항 내지 제 15 항 중 어느 한 항의 방법에 따른 방식으로 단말기의 동작을 제어하는 소프트웨어.
제 16 항에 따른 상기 제어장치 또는 제 17 항에 따른 소프트웨어를 탑재한 단말기.
디지털 방송 시스템에서 애플리케이션을 단말기(60)로 전송하는 방법에 있어서,

상기 단말기는 외부 상대측(55)에 시그널링을 전달할 수 있는 대화형 채널(85)에 액세스할 수 있는, 상기 전송 방법은:

암호화된 애플리케이션에 관한 상세 사항들을 전송하는 단계로서, 인증 요청(314)을 대화형 채널(85)을 통해 인증 엔티티(55)로 보냄으로써 상기 암호화된 애플리케이션(320)에 액세스하도록 상기 단말기(60)를 인증하고; 인증된 것에 응답하여 상기 대화형 채널(85)을 통해 키(215)를 수신하고; 상기 키(215)를 사용하여 상기 애플리케이션을 복호화하도록 구성되는 런처 애플리케이션(310)을 포함하는, 상기 전송 단계; 및

상기 암호화된 애플리케이션(320)을 전송하는 단계를 포함하는, 전송 방법.
디지털 방송 시스템에서 단말기로의 전송을 위한 애플리케이션용 소프트웨어로서,

상기 단말기는 외부 상대측(55)에 시그널링을 전달할 수 있는 대화형 채널(85)에 액세스하고,

상기 애플리케이션은, 상기 단말기(60) 내의 처리기에 의해 실행될 때, 상기 처리로 하여금:

인증 요청(314)을 대화형 채널(85)을 통해 인증 엔티티(55)에 보냄으로써 암호화된 애플리케이션(320)에 액세스하고, 인증된 것에 응답하여 상기 대화형 채널(85)을 통해 키(215)를 수신하도록 상기 단말기(60)를 인증하는 단계; 및

상기 수신된 키(215)를 사용하여 상기 암호화된 애플리케이션을 복호화하는 단계를 수행하게 하는 코드를 포함하는 런처 애플리케이션(310)을 포함하는, 전송을 위한 애플리케이션용 소프트웨어.
디지털 방송 시스템에서 전송을 위한 신호에 있어서,

상기 신호는 제 20 항에 따른 소프트웨어를 구현하는, 신호.
조건부 액세스(CA) 시스템이 사용되지 않는 디지털 방송 시스템에서 암호화된 애플리케이션을 단말기에 전송하는 방법에 있어서:

상기 암호화된 애플리케이션에 관한, 상기 애플리케이션을 암호화하는데 사용되는 암호화 방법; 상기 애플리케이션의 비용; 지불 상세 사항들 중 하나 이상을 포함하는 비암호화된 상세 사항들을 전송하는 단계; 및

상기 암호화된 애플리케이션을 전송하는 단계를 포함하는, 전송 방법.
암호화된 애플리케이션을 수신하는 방법, 제어장치, 소프트웨어, 단말기, 실 질적으로 첨부한 도면을 참조하여 여기에 기술되고 이들에 도시된 애플리케이션 또는 신호를 전송하는 방법.