이하, 본 발명의 바람직한 실시 예들의 상세한 설명이 첨부된 도면을 참조하여 상세히 설명한다. 도면들 중 동일한 구성들은 가능한 한 어느 곳에서든지 동일한 부호들을 나타내고 있음을 유의하여야 한다. 또한, 하기 설명에서는 구체적인 특정 사항들이 나타나고 있는데, 이는 본 발명의 보다 전반적인 이해를 돕기 위해서 제공된 것일 뿐 이러한 특정 사항들 없이도 본 발명이 실시될 수 있음은 이 기술 분야에서 통상의 지식을 가진 자에게는 자명하다 할 것이다. 그리고 본 발명을 설명함에 있어, 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 상세한 설명을 생략한다.

본 발명은 서비스 액세스 시나리오들을 변경 없이 유지하고, SEK와 PEK를 액세스 값 쌍(AVP: Access Value Pair)들로 대체한다. AVP는 BSM에서 임의로 발생되는 키 씨드 쌍(KSP: Key Seed Pair)으로 불리는 임의 값들의 쌍을 이용하여 계산된다. AVP는 다수 개의 TEK들을 파생하는데 사용된다. 이를 통해 본 발명에서는 키 계층구조가 업데이트 되고, TEK를 식별하는 방법이 변경되며, STKM들이 제거된다. 따라서 더 이상 TEK들을 전송할 필요가 없다. 또한 LTKM 포맷은 TEK 식별자(ID)와, 액세스 기준과, 기타 이전에 STKM을 통해 운반된 콘텐츠에 링크된 속성들 및 AVP를 포함하도록 수정된다. 또한 본 발명에 따르면 스마트카드에 의해 LTKM를 처리하거나 단말이 스마트카드로 새로운 TEK 요청 메시지를 전송한다.

도 5는 본 발명의 실시예에 따른 키 계층구조를 나타낸 것이다.

SMK(420)는 종래와 동일하게 등록 키들(410)로부터 파생되어 사용되지만, SEK와 PEK는 AVP들(440)로 대체된다. SEK를 대체하는 AVP(440)는 서비스 AVP(SAVP)라 하고, PEK를 대체하는 AVP(440)는 프로그램 AVP(PAVP)라 한다.

또한 KSP(430)는 {KS ₁ , KS ₂ }으로 이루어진 쌍이며, KS ₁ 과 KS ₂ 는 BSM에서 임의로 발생된다고 가정할 때, KSP(430)로부터 발생될 수 있는 TEK들(450)의 총 개수가 n이라 하면, AVP(440)는 다음과 같이 2가지 방식으로 계산될 수 있다.

1. 사용자가 n개의 TEK들을 발생하도록 허가받은 경우:

AVP = KSP = {KS ₁ , KS ₂ }

2. 사용자가 m개의 TEK들을 발생하도록 허가받은 경우(m < n):

1) 해시(hash) 함수를 KS ₁ 에 n번 적용하고, 해시 값 {S _i }의 시퀀스를 저장한다.

S ₁ = hash (KS ₁ ), S ₂ = hash (S ₁ ),…, S _n-1 = hash (S _n-2 ), S _n = hash (S _n-1 )

상기와 같은 해시 시퀀스를 정방향 해시 시퀀스(forward hash sequence)라고 한다.

2) 해시 함수를 KS ₂ 에 n번 적용하고, 마지막 해시 값에서부터 시작하는 해시 값 {M _i }의 시퀀스를 저장한다.

M ₁ = hash (M ₂ ), M ₂ = hash (M ₃ ),…,M _n-1 = hash (M _n ), M _n = hash (KS ₂ )

즉, M ₁ 은 KS ₂ 의 n번째 해시 값이고, M ₂ 는 KS ₂ 의 (n-1)번째 해시 값이다. 이러한 해시 시퀀스를 역방향 해시 시퀀스(backward hash sequence)라고 한다.

3) AVP = {S _i , M _j }

여기서, i는 n개의 TEK들의 시퀀스 중에서 사용자가 사용 가능한 첫 번째 TEK의 인덱스(시퀀스 번호)를 나타내며, j는 n개의 TEK들의 시퀀스 중에서 사용자가 사용할 수 있는 마지막 TEK의 인덱스(시퀀스 번호)를 나타낸다.

한편, 키 재료들(materials)을 맵핑할 때, SEK는 단일 SAVP = KSP로 맵핑되거나(즉, KSP LT = SEK LT; n개의 TEK들은 KSP로부터 파생됨), 다수 개의 SAVP들(SAVP ₁ = KSP ₁ , SAVP ₂ = KSP ₂ ,…)로 맵핑될 수 있다. 또한 PEK는 관련 SAVP로부터 파생된 단일 PAVP로 맵핑되거나, 각각 관련 SAVP(들)로부터 파생된 다수 개의 PAVP들로 맵핑될 수 있다.

또한 BSM에서, n개의 TEK들을 다음과 같이 정방향 및 역방향 해시 시퀀스들로부터 발생시킬 수 있다.

TEKi = S _i XOR M _j

여기서, XOR은 비트단위(bitwise)의 배타적 OR 연산이다.

또한, 단말에서 m개의 TEK들은, 모든 x에 대해서 m개의 S _i+x 값들을 계산하고, 구간 [1,m]로부터 얻어진 값들 또는 모든 x에 대해서 m개의 M _j-x 값들을 계산하고, 구간 [1,m]로부터 얻어진 값들 또는 모든 x에 대해서 TEK _x = S _x XOR M _x 를 계산하고, 구간 [i,i+m]로부터 얻어진 값들로 이루어진 AVP = {S _i , M _j }로부터 얻어진다.

한편, 일반적으로 다양한 보안 프로토콜에 대한 요구를 만족시키기 위해서는, TEK 파생을 위해 서로 다른 유형의 해시 함수들이 사용될 수 있으며, 해시 함수의 출력은 절삭(truncated)될 수도 있다.

도 6과 도 7은 본 발명의 실시예에 따른 키 분배의 예를 도시한 것이다. 도 6과 도 7에서의 조건은 도 3 및 도 4와 동일하다.

도 6은 본 발명의 실시예에 따른 가입 기반 액세스 상황에서의 SAVP 제공 흐름을 도시한 것이다.

본 발명의 실시예에 따른 가입 기반 액세스 상황에서 SAVP의 수명은 TEK의 수명의 n배로 계산된다. 즉, n개의 TEK들이 SAVP로부터 발생될 수 있다. 서비스가 제공되기 시작할 때, BSM는 새로운 SAVP ₁ 을 발생시키고, 이를 LTKM를 통해 가입 사용자에게 전송한다(510). SAVP ₁ 은 사용자와 BSM간에만 공유되는 SMK ₁ 에 따라 암호화된다. 또한 BSM은 SAVP ₁ 이 만료되기 전에 새로운 SAVP ₂ 를 발생시키고, 이를 LTKM을 통하여 사용자에게 전송한다(520). SAVP ₂ 도 사용자와 BSM간에만 공유되는 SMK ₁ 에 따라 암호화된다.

도 7은 본 발명의 실시예에 따른 PPV 기반 액세스 상황에서의 PAVP 제공 흐름을 도시한 것이다.

본 발명의 실시예에 따른 PPV 기반 액세스 상황에서, PAVP의 수명(PAVP LT)은 TEK의 수명의 m배로 계산되며, m ≤ n이다. 도 6에서는 SAVP ₁ 로부터 파생된 2개의 PAVP들(PAVP ₁ , PAVP ₂ )을 예로 들었으나 더 많은 PAVP들이 있을 수도 있다. 사용자는 이들 각각에 대해서 별도의 구매 요청을 발행해야 한다. 사용자가 콘텐츠에 대한 액세스를 시작하기 전에, 그리고 첫 번째 구매를 수행하는 경우에, BSM는 LTKM를 통하여 사용자에게 PAVP ₁ 을 전송한다(610). 또한 PAVP ₁ 이 만료되기 전에, 사용자는 두 번째 구매 요청을 발행하며, 구매가 성공적으로 이루어지면 BSM는 LTKM을 통하여 사용자에게 PAVP ₂ 를 전송한다(620). PAVP ₂ 가 만료되기 전에 사용자에 의해 더 이상의 구매 요청이 발행되지 않으면, BSM도 사용자에게 PAVP를 전송하지 않으므로 사용자는 더 이상 콘텐츠에 액세스 할 수 없다.

다음, 본 발명의 실시예에 따른 키 식별 방법에 대하여 설명한다.

[표 1]은 본 발명의 실시예에 따른 키 식별자와 스마트카드 프로파일의 키 식별자의 맵핑 관계를 나타낸 것이다.

표 1

다음, 본 발명의 실시예에 따른 LTKM 포맷에 대하여 설명한다.

본 발명의 실시예에서는 SAVP와 PAVP가 각각 SEK와 PEK를 대체하므로, 이들은 LTKM을 통해 운반되어야 한다. 한편, TEK들을 전송하는 STKM들은 STKM의 관리 데이터를 제외하고는 더 이상 필요하지 않다. STKM의 관리 데이터는 액세스 기준 정보와 기타 암호화된 콘텐츠에 링크된 속성들을 포함한다. STKM의 관리 데이터가 LTKM에 복사되면 STKM들은 제거될 수 있다.

도 8은 본 발명의 실시예에 따른 상위 레벨의 LTKM 포맷을 도시한 것이다.

본 발명의 실시예에 따른 LTKM은 MIKEY(Multimedia Internet KEYing) 프로토콜(RFC 3830)을 통해 전송되고 MIKEY 규칙에 따라 형성된다. 메시지의 구조는 스마트카드 프로파일과 비교할 때 변경되지 않지만, 일부 필드들의 콘텐츠가 수정된다. 본 발명의 실시예에서는 관리 데이터({EXT BCAST})를 포함하는 LTKM들만이 고려되며, 관리 데이터를 포함하지 않는 LTKM들은 현재 스마트카드 프로파일에 기술된 대로 구성되어(formatted) 처리된다.

스마트카드 프로파일과 비교할 때 수정되지 않는 필드들은 다음과 같다.

- 공통 헤더(710): MIKEY 메시지 헤더

- TS(740): 리플레이 어택(replay attack)을 검출하기 위해 사용되는 카운터

- MIKEY RAND(750): 리플레이 보호, 키 부호화 및 키 생성에 사용되는 임의 값

- IDi(760): 단말과 BSM 간의 보안 관계에 대한 식별자

- IDr(770): BSM 식별자

- {SP}(780): SRTP(Secure Realtime Transmission Protocol) 부호화 프로토콜 특정 파라미터들

또한 변경이 요구되는 파라미터들은 다음과 같다.

- EXT MBMS(720): 키 도메인 ID와 키 타입 ID를 포함하며, 키 도메인 ID 서브 페이로드는 기존과 동일하고, 키 타입 ID 서브 페이로드에서 SEK/PEK ID는 KSP ID로 교체된다.

- {EXT BCAST}(730): LTKM 관리 데이터로서, 변경된 포맷은 하기 [표 2]를 따른다.

- KEMAC(790): 키잉(keying) 및 메시지 인증 재료로, SEK/PEK는 하나 또는 그 이상의 AVP로 대체된다(예를 들어, 솔트 값(salt value)이 보안 프로토콜에 의해 요구되는 경우). SEK/PEK 유효성의 TS _LOW 및 TS _HIGH 은 AVP로부터 파생될 수 있는 TEK들의 개수에서 측정된 AVP 유효성의 TEK ID _LOW 및 TEK ID _HIGH 로 대체되며, TEK ID _LOW 와 TEK ID _HIGH 는 AVP 유효성 데이터(VL)라 한다.

다음, 본 발명의 실시예에 따른 LTKM 관리 데이터에 대하여 설명한다.

하기 [표 2]는 본 발명의 실시예에 따른 스마트카드 프로파일 LTKM 관리 데이터 포맷을 나타낸 것이다.

표 2

상기 [표 2]에서 protocol_version, security_policy_ext_flag, consumption_reporting_flag, access_criteria_flag, terminal_binding_flag는 레거시(legacy) LTKM 포맷으로부터 상속되며(inherited), 이들 플래그들은 스마트카드 프로파일에 기술된 바와 같이 변경 없이 사용된다. 이 중 security_policy_ext_flag 필드는 보안 정책 확장자(security policy extension)가 존재하는지를 나타내며, 일반적으로 보안 정책 확장자는 어떻게 콘텐츠 소비에 대한 요금이 사용자에게 청구되는지를 정의한다. 또한 상기 플래그들 중 어느 하나가 LTK_FLAG_TRUE로 설정된 경우에는, LTKM에 속한 기타 필드들은 스마트카드 프로파일과 동일하게 사용된다.

원래의 LTKM은 액세스 기준 디스크립터(access criteria descriptor)로 불리는 콘텐츠 액세스 규칙들을 이미 포함한다. 그러나 특정 액세스 기준들이 하나 또는 그 이상의 관련 TEK들로 암호화된 하나의 콘텐츠에 대해 정의된 경우, 이들은 STKM에 기술된 바와 같이 개별적으로 상술(specified) 되어야 한다. 이를 위해, 다음의 새로운 필드들이 메시지에 포함된다.

- traffic_key_descriptor_flag: 트래픽 키 사용 디스크립터들이 LTKM에 속하는지를 나타낸다.

- number_of_traffic_key_descriptors: 트래픽 키 사용 디스크립터들의 수를 나타낸다.

- traffic_key_descriptor_loop( ) - 액세스 기준들 및 기타 하나 또는 그 이상의 TEK들과 연관된 파라미터들을 포함하는 트래픽 키 디스크립터를 정의한다.

- traffic_key_identifier_low: 트래픽 키 디스크립터가 적용되는 TEK 시퀀스 중 첫 번째 TEK를 나타내는 TEK 시퀀스 번호. 이때, TEK들은 순차적으로 하나씩 그들의 시퀀스 번호에 따라 사용되는 것으로 가정한다.

- traffic_key_identifier_high: 트래픽 키 디스크립터가 적용되는 TEK 시퀀스 중 마지막 TEK를 나타내는 TEK 시퀀스 번호

다음 필드들은 단기 키 메시지(STKM)에서 변경 없이 그대로 수용된다.

- protection_after_reception

- access_criteria_flag

- traffic_protection_protocol

- traffic_key_lifetime

- traffic_authentication_tag

- reserved_for_future_use

- number_of_access_criteria_descriptors

- access_criteria_descriptor

다음, 사용자 측에서의 LTKM 처리 과정에 대하여 설명한다.

LTKM들은 스마트카드 또는 단말에 위치한 보안 함수(secure function)에 의해 처리된다.

도 9는 본 발명의 실시예에 따른 단말에서의 LTKM 처리 절차를 나타낸 것이다.

단말은 801 단계에서 LTKM을 수신하면, 802 단계에서 SMK를 사용하여 메시지 검증(validation)을 수행한 후 803 단계에서 상기 메시지가 유효한지를 확인한다.

메시지가 유효하면, 단말은 804 단계에서 LTKM 리플레이 검출 절차를 수행한 후에 805 단계에서 검출된 리플레이가 유효한지를 판단한다.

리플레이가 유효하면 단말은 LTKM을 보안 함수로 보내며, 보안 함수는 806 단계에서 AVP 데이터가 유효한지, 즉 TEK ID _LOW 가 TEK ID _HIGH 보다 작은지를 확인한다. 만약 AVP 데이터가 유효하지 않으면 단말은 815 단계로 진행하여 주어진 KSP ID, 즉 SAVP/PAVP, TEK들, 저장된 정책 확장자들 등과 연관된 전체 컨텍스트를 제거하고 LTKM 처리를 종료한다.

AVP 데이터가 유효하면, 보안 함수는 808 단계에서 security_policy_ext_flag=LTK_FLAG_TRUE일 경우의 security_policy_extension의 값에 기반하여 LTKM을 처리한다. SEK/PEK 유효성의 "TS 하이(high)" 및 STKM에서 사용되는 TS에 의존하는 보안 정책 확장자들은 TEK ID _HIGH 와 현재 사용되는 TEK의 TEK ID를 사용한다. 일반적으로, LTKM은 타임스탬프들 대신에 TEK ID들에 기반하여 처리된다.

다음, access_criteria_flag= LTK_FLAG_TRUE이면, 보안 함수는 809 단계에서 액세스 제어 디스크립터들을 처리한다. 또한 관련 플래그가 LTK_FLAG_TRUE로 설정되면 보안 함수는 810 단계에서 소비 보고를 수행하고, traffic_key_descriptor_flag= LTK_FLAG_TRUE이면 811 단계에서 트래픽 키 디스크립터들을 처리한다.

즉, 각각의 트래픽 키 디스크립터에 대해, 보안 함수는 traffic_key_identifier_low와 traffic_key_identifier_high를 확인함으로써 현재 트래픽 키 디스크립터가 적용되는 TEK 시퀀스를 식별하고, 액세스 기준들과 기타 콘텐츠 속성들을 처리하며 이들을 관련 TEK ID들과 함께 저장한다.

다음, 보안 함수는 812 단계에서 SAVP/PAVP를 해독하고, 813 단계에서 TEK들을 파생시키며, 814 단계에서 상기 파생된 TEK들을 이전 단계들에서 처리된 기타 속성들과 함께 저장한다. 또한 보안 함수는 단말의 요구에 따라 필요한 TEK를 파생시킬 수도 있다.

다음, 단말에 의한 TEK 요청 절차에 대하여 설명한다.

단말은, 콘텐츠 해독을 위해 새로운 TEK가 필요할 때마다 보안 함수로 TEK를 요청해야 한다. 스마트카드 프로파일에 정의된 바와 같이, 일반적으로 보안 함수는 단말의 STKM에 응답하여 단말에게 TEK를 제공한다. 그런데 본 발명의 실시예에서는 STKM들이 더 이상 사용되지 않으므로, TEK를 요청하기 위한 새로운 메시지가 정의되어야 한다. 본 발명에서는 이러한 메시지를 "TEK 요청" 메시지라고 한다.

TEK 요청 메시지에는 키 도메인 ID와, KSP ID 및 TEK ID가 포함된다. 또한 요청에 따라 기타 피라미터들도 포함될 수 있다. 예를 들어, TEK 요청 메시지가 단말에 바인딩된 경우, 단말 바인딩 키(TBK: Terminal Binding Key) 식별자 및 메시지 인증 코드가 포함될 수 있다.

도 10은 본 발명의 실시예에 따라 보안 함수가 단말로부터 TEK 요청을 수신한 경우의 흐름을 도시한 것이다.

901 단계에서 보안함수가 단말로부터 TEK 요청을 수신하면, 902 단계에서 보안 함수는 키 도메인 ID, KSP ID 및 TEK ID에 기반하여 관련 TEK를 검색(또는 발생)한다. 만약 903 단계에서 TEK 검색에 성공하였으면 보안함수는 904 단계로 진행하여 스마트카드 프로파일에서 액세스 기준 처리에 대해 정의된 바와 동일하게 TEK와 연관된 액세스 기준들을 처리한다. 예를 들어, SAVP/PAVP 연관 액세스 기준 및 TEK 특정 액세스 기준들이 제공되면 이들을 비교하고, PIN 검증이 요구되면 이를 수행한다. 또한 TEK 검색에 실패하였으면, 보안함수는 909 단계에서 단말에게 실패 지시자(failure indication)를 보내고 TEK를 제공하지 않는다.

액세스 기준들을 처리한 후 905 단계에서는 액세스 기준 처리 성공 여부를 확인하며, 성공하였으면 906 단계에서 보안함수는 관련 SAVP/PAVP와 연관된 보안 정책 확장자들에 기반하여 요청을 처리한다(스마트카드 프로파일의 STKM 처리 참조). 또한 액세스 기준 처리에 실패하였으면 909 단계에서 단말에게 실패 지시자를 보내고 TEK를 제공하지 않는다.

정책 확장자들을 처리한 후 907 단계에서는 정책 확장자 처리 성공 여부를 확인하며, 성공하였으면 908 단계에서 단말에게 TEK를 전송하며 실패하였으면 909 단계에서 단말에게 실패 지시자를 보내고 TEK를 제공하지 않다.