地上デジタルテレビジョン放送運用仕様...Marlin IPTV-ES Specific Compliance Rules”, Version 1.1 [RTDBCR]に対する詳細規定項目と、[MIPTV]に対する追加規定項目を規定する。

1 2 3 4 5 6 7 8 9

10 11 12

13

14

15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

地上デジタルテレビジョン放送 IP 再送信 Marlin IPTV-ES 運用仕様 Document Version: 1.1 Final Date: 18 November, 2008 Copyright © 2008 ALL RIGHTS RESERVED ソニー株式会社

パナソニック株式会社本仕様の内容は予告無しに変更されることがあります。

地上デジタルテレビジョン放送 IP 再送信 Marlin IPTV-ES 運用仕様 Page 2 18-November-2008

49

50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99

100 101 102

Contents 1. はじめに............................................................................................................................ 5

1.1. 本書の規定範囲 ........................................................................................................ 5 1.2. 引用文書 ................................................................................................................... 6 1.3. 用語の定義 ............................................................................................................... 6 1.4. 略語 .......................................................................................................................... 7 1.5. バイトオーダー ........................................................................................................ 7 1.6. ビットオーダー ........................................................................................................ 7

2. SACに関する規定 ............................................................................................................. 8 2.1. メッセージパラメータ ............................................................................................. 8 2.2. SACタイムアウト .................................................................................................... 8 2.3. 1 つのTCP Connectionを利用可能なSACセッション.............................................. 8 2.4. Response & Commit message................................................................................. 8

3. Service ProtocolおよびECMに関する規定 ....................................................................... 9 3.1. Get Permission Protocol .......................................................................................... 9

3.1.1. メッセージパラメータの設定 .............................................................................. 9 3.1.1.1. Get Permission Request parameters .......................................................... 9 3.1.1.2. Get Permission Reply parameters ............................................................ 10

3.1.2. メッセージパラメータの検証 ............................................................................ 10 3.1.2.1. Get Permission Request parameters ........................................................ 10 3.1.2.2. Get Permission Reply parameters ............................................................ 11

3.1.3. UsageRuleReferenceの設定.............................................................................. 12 3.1.4. 受信機における「WorkKey・SubscriptionTierBits・ExtractInfo」の

取得に関する処理 .............................................................................................. 13 3.1.5. DRMサーバにおける「WorkKey・SubscriptionTierBits・ExtractInfo」の

送信に関する処理 .............................................................................................. 14 3.2. Get Trusted Time Protocol ..................................................................................... 14 3.3. Packed Message Protocol ..................................................................................... 15

3.3.1. メッセージパラメータの設定 ............................................................................ 15 3.3.1.1. Packed Message Request parameters..................................................... 15 3.3.1.2. Packed Message Reply parameters ......................................................... 16

3.3.2. メッセージパラメータの検証 ............................................................................ 17 3.3.2.1. Packed Message Request parameters..................................................... 17 3.3.2.2. Packed Message Reply parameters ......................................................... 17

3.4. ECMに関する規定.................................................................................................. 17 3.4.1. CA_descriptorおよびECMの送出 ...................................................................... 17

3.4.1.1. CA_descriptorの送出................................................................................. 17 3.4.1.2. ECMの送出................................................................................................ 17

4. ネットワーク通信プロトコル（HTTP）に関する規定 .................................................. 18 4.1. HTTPによるSACのメッセージの伝送 ................................................................... 18 4.2. HTTPヘッダ ........................................................................................................... 18

4.2.1. サイズ ................................................................................................................ 18 4.2.2. メソッド ............................................................................................................ 18 4.2.3. リクエストヘッダ .............................................................................................. 19 4.2.4. レスポンスヘッダ .............................................................................................. 19

4.3. メッセージ処理中の受信機からHTTPのリクエストを受信した時の DRMサーバの処理.................................................................................................. 20

A. Appendix（Informative） ................................................................................................ 21 A.1 SAC処理の例 .............................................................................................................. 21

A.1.1 状態遷移 .................................................................................................... 21 A.1.2 メッセージ処理 ......................................................................................... 23

(1). Challenge message送信時の受信機処理 .................................................. 24 (2). Challenge message受信時のDRMサーバ処理.......................................... 25


103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157

(3). Response & Challenge message送信時のDRMサーバ処理 ..................... 25 (4). Response & Challenge message受信時の受信機処理 ............................ 25 (5). Response & Request message送信時の受信機処理 ............................... 25 (6). Response & Request message受信時のDRMサーバ処理 ....................... 26 (7). Reply message送信時のDRMサーバ処理 ................................................ 26 (8). Reply message受信時の受信機処理 ........................................................ 26 (9). Request message送信時の受信機処理 .................................................... 26 (10). Request message受信時のDRMサーバ処理............................................ 27 (11). Encrypted command message送信時の受信機処理 ................................ 27 (12). Encrypted command message受信時のDRMサーバ処理 ........................ 27 (13). Command が「ACK」のEncrypted command message送信時の

DRMサーバ処理 ........................................................................................ 28 (14). Encrypted command message受信時の受信機処理 ................................ 28 (15). Plain command message受信時の受信機処理 ........................................ 28 (16). Plain command message送信時のDRMサーバ処理 ................................ 28 (17). Command が「ERROR」のEncrypted command message送信時の DRMサーバ処理 ........................................................................................ 28

A.2 SACとService Protocolを用いたシーケンス .............................................................. 29 A.3 コンテンツの利用シーケンス ................................................................................ 30

A.3.1 「WorkKey・SubscriptionTierBits・ExtractInfo」の取得処理 .......................... 31 A.3.1.1 ティアビット............................................................................................. 31 A.3.1.2 WorkKeyManagementID ........................................................................... 31 A.3.1.3 WorkKey（odd/even）.............................................................................. 31 A.3.1.4 受信機における「WorkKey・SubscriptionTierBits・ExtractInfo」の管理 32 A.3.1.5 RenderingObligationによるEXTRACT・RECORD・EXPORT................ 32 A.3.1.6 Packed Message Protocolによる

「WorkKey・SubscriptionTierBits・ExtractInfo」の取得 ......................... 32 A.3.2 コンテンツ受信時のECM処理 ........................................................................... 33 A.3.3 「WorkKey・SubscriptionTierBits・ExtractInfo」の更新処理 .......................... 33

A.3.3.1 更新の有無と更新開始日時オフセット ......................................................... 33 A.3.3.2 「WorkKey・SubscriptionTierBits・ExtractInfo」の更新 ............................. 33

A.4 WorkKeyIDおよびUsageRuleReferenceの運用例...................................................... 34 A.4.1 ティアビット・WorkKeyID・UsageRuleReferenceの関係 .............................. 34

A.4.1.1 WorkKeyIDとティアビットとの関係 ........................................................ 34 A.4.1.2 UsageRuleReferenceとWorkKeyIDとの関係 ........................................... 35 A.4.1.3 ティアビットとWorkKeyID・UsageRuleReferenceの値との関係の例.... 35

A.4.2 WorkKeyを更新する運用におけるWorkKeyIDとUsageRuleReferenceとの関係の例............................................................................................................. 35

A.5 「WorkKey・SubscriptionTierBits・ExtractInfo」の更新運用の例............................ 36 A.6 メッセージの例 ...................................................................................................... 47

A.6.1 HTTPのメッセージの例..................................................................................... 47 A.6.2 SACのメッセージの例....................................................................................... 48

A.6.2.1 Challenge message .................................................................................. 48 A.6.2.2 Response & Challenge message.............................................................. 48 A.6.2.3 Response & Request message................................................................. 49 A.6.2.4 Request message ..................................................................................... 49 A.6.2.5 Reply message.......................................................................................... 50 A.6.2.6 Plain command message.......................................................................... 50 A.6.2.7 Encrypted command message.................................................................. 51

A.6.3 Service Protocolのメッセージ例 ....................................................................... 51 A.6.3.1 Get Permission Protocol ........................................................................... 51

A.6.3.1.1. DeviceInformation ............................................................................... 51 A.6.3.1.2. Get Permission Request message ..................................................... 52 A.6.3.1.3. Get Permission Reply message.......................................................... 53

A.6.3.2 Get Trusted Time Protocol ........................................................................ 53


158 159 160 161 162

A.6.3.2.1 Get TrustedTime Request.................................................................... 53 A.6.3.2.2 Get TrustedTime Reply........................................................................ 54

A.6.3.3 Packed Message Protocol ........................................................................ 54 A.6.3.3.1 Packed Message Request message ................................................... 54 A.6.3.3.2 Packed Message Reply message ....................................................... 54


163

164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209

1. はじめに

1.1. 本書の規定範囲本書では、地上デジタルテレビジョン放送IP再送信において、コンテンツの暗号を

復号するための鍵を、以下で取得するコンテンツ（以下、本書では“コンテンツ”

と記す）の利用に関し、[MIPTV]および“地上デジタルテレビジョン放送IP再送信

Marlin IPTV-ES Specific Compliance Rules”, Version 1.1 [RTDBCR]に対する詳細規

定項目と、[MIPTV]に対する追加規定項目を規定する。

“Marlin Trust Management Document for IPTV-ES Version 1.2 Supplement 1: RTDB/J Support”[MTMDSUP] 2 章で規定するRTDB Client Key及びRTDB Service Keyを用いた“Marlin IPTV End-point Service Specification”, Version 1.0.1 [MIPTV], 4.1 項で規定されるSACにおいて、[MIPTV], 4.2.1.2 項で規定され

るActionIDが「EXTRACT with Indirect Key Delivery（02h）」のGet Permission Request

[MIPTV], 6.1.2 項で規定されるECM 本書は、Marlin IPTV-ES Device、Marlin IPTV-ES Server（以下、本書ではそれぞれ

“受信機”、“DRM サーバ”と記す）、および、ECM を送出するサービス事業者

に適用する。本書の規定に準拠する受信機およびDRMサーバが、[MIPTV]と本書以外の任意の運

用仕様と組み合わせにも準拠する場合、本書での規定と相反する規定項目がある場

合には、本書の規定を優先するものとする。以下に、本書の規定項目を示す。

[MIPTV]および[RTDBCR]に対する詳細規定項目 SACに関する規定（[MIPTV], 4.1 節 Secure Authenticated Channel (SAC)

Protocol）メッセージパラメータ SAC タイムアウト 1 つの TCP Connection を利用可能な SAC セッション Response & Commit message

Service Protocolに関する規定（[MIPTV], 4.2 節 Marlin IPTV-ES Service

Protocol over SACに関する規定）の設定メッセージパラメータ

メッセージパラメータの検証 UsageRuleReference の設定受信機における WorkKey・WorkKeyID・PrivateData・

SubscriptionTierBits・ExtractInfo の取得に関する処理 DRM サーバにおける WorkKey・WorkKeyID・PrivateData・

SubscriptionTierBits・ExtractInfo の送信に関する処理

ECMに関する規定（[MIPTV], 6.1.2 項 ECM format） CA_descriptor および ECM の送出

[MIPTV]に対する追加規定項目


210 211 212 213

214

ネットワーク通信プロトコル（HTTP）に関する規定 HTTP による SAC のメッセージの伝送 HTTP ヘッダ

1.2. 引用文書 [RTDBCR] “地上デジタルテレビジョン放送 IP 再送信 Marlin IPTV-ES

Specific Compliance Rules”, Version 1.1 [MIPTV] “Marlin IPTV End-point Service Specification”, Version 1.0.1 [MP2S] ISO/IEC 13818-1 “Information technology – Generic coding of

moving pictures and associated audio information: Systems” Second edition 2000-12-01

[MTMDSUP] “Marlin Trust Management Document for IPTV-ES Version 1.2 Supplement 1: RTDB/J Support”

[RFC2109] HTTP State Management Mechanism [RFC2616] Hypertext Transfer Protocol – HTTP/1.1

215

216 217 218

1.3. 用語の定義本書で用いる用語を以下に定義する。用語定義 CA_descriptor [MP2S], 2.6.16 項で規定されるCA_descriptor。 SAC 確立受信機と DRM サーバとの間で相互認証とセッショ

ン鍵の共有を行うこと。 SAC 終了 SAC で用いたメッセージパラメータとセッション

鍵を利用できないようにし、SAC で用いた TCP Connection を切断すること。

更新開始日時オフセット WorkKey・WorkKeyID・PrivateData・SubscriptionTierBits・ExtractInfoを更新する運用に

おける、更新の開始日時（更新開始日時）の

NotAfterからのオフセット時間（単位は分）。更新

開始日時オフセットは、PrivateData（[MIPTV], 4.2.1.5 項で規定されるStatusExtensionのPrivateData）で指定する。

コンテンツ地上デジタルテレビジョン放送IP再送信において、

暗号を復号するための鍵を[MIPTV], 4.2.1.2 項で規

定されるActionIDが「EXTRACT with Indirect Key Delivery（02h）」のGet Permission Requestと[MIPTV], 6.1.2 項で規定されるECMで取得するコン

テンツ。 219 220 221

本書で用いる用語と[MIPTV]の用語との対応を以下に示す。本書 [MIPTV]受信機 Marlin IPTV-ES Device DRM サーバ Marlin IPTV-ES Server チャネル Channel


[MIPTV]本書ティアビット Tier Bits

222

223 224 225

1.4. 略語本書で用いる略語を以下に示す。略語正式名称 LSB Least Significant Bit MSB Most Significant Bit

226

227 228 229 230

231 232 233

1.5. バイトオーダー本書で規定するプロトコルの多バイト数値のバイトオーダーは、“Big Endian”で

ある。

1.6. ビットオーダー本書で規定するプロトコルのビットオーダーは、“MSB First”である。


234

235 236

237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260

261 262 263 264 265

266 267 268 269

270 271 272

2. SAC に関する規定本章では IPTV-ES SAC の運用を規定する。

2.1. メッセージパラメータ [MIPTV], 4.1.3 項で規定されるプロトコルのメッセージパラメータの運用を以下に

示す。

SenderID DRM SenderID 受信機は、サーバのとしていかなる値を受信しても、

「NULL value（00h）」を受信したものとして処理する。 SequenceNumber

Request message SequenceNumber 2 24 3受信機は送信時にが（＾－）

以上になる場合には、[MIPTV], 4.1.4.10.1 項に従い、SACを終了する。 TransactionFlag

、Encrypted command message DRMサーバと受信機はの

TransactionFlag を検証しない。 Status

DRM Plain command messageサーバは、のStatusとして「Certificate issuer mismatch（8005h）」を運用しない。

SinkCertificate 受信機が送信するSinkCertificateはcertificate chainを含むPKIPathとす

る。 SourceCertificate

DRMサーバが送信するSourceCertificateはcertificate chainを含む

PKIPathとする。

2.2. SAC タイムアウト DRM 、メッセージ送信後に 10サーバは秒間はタイムアウトせずにメッセージ受信

待ちを行う。

DRMサーバはタイムアウト後に[MIPTV], 4.1.4.10.2 項に従いSACを終了する。

2.3. 1 つの TCP Connection を利用可能な SAC セッション 1 つのTCP Connectionを利用可能なSACセッションは 1 つとする。従って、受信機

とDRMサーバは、SACを終了した時、速やかにTCP Connectionを切断する。

2.4. Response & Commit message Response & Commit messageは運用しない。


273

274 275 276 277

278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304

305 306 307 308

309 310 311 312 313 314 315 316

3. Service Protocol および ECM に関する規定本章では、Marlin IPTV-ES Service Protocol および ECM の運用を規定する。なお、メッセージパラメータに設定する UsageRuleReference、メッセージ送信先

の DRM サーバの URI を受信機が取得する方法については、本書では規定しない。

3.1. Get Permission Protocol [MIPTV], 4.2 項で規定されるGet Permission Protocolは、WorkKey・WorkKeyID・

PrivateData・SubscriptionTierBits・ExtractInfoの取得に用いる。以降、Get Permission Protocolで取得する一組のWorkKey・WorkKeyID・PrivateData・SubscriptionTierBits・ExtractInfoを示す場合、かぎかっこを付与して「WorkKey・SubscriptionTierBits・ExtractInfo」などと表記する。本節では、以下の項目を規定する。

メッセージパラメータの設定メッセージパラメータの検証 UsageRuleReference の設定受信機における「WorkKey・SubscriptionTierBits・ExtractInfo」の取得に関する

処理 DRM サーバにおける「WorkKey・SubscriptionTierBits・ExtractInfo」の送信に

関する処理なお、DRM サーバは、同時期に一対となる 2 つの WorkKey（odd）と WorkKey（even）とを常に発行する運用をおこなうこととする。よって、受信機は、

「WorkKey・SubscriptionTierBits・ExtractInfo」を取得する場合、一対となる 2 つ

の WorkKey（odd）と WorkKey（even）とを取得することとする。以降、2 つの Get Permission Reply で同時期に取得する同一 ServiceProviderID・同

一 WorkKeyManagementID の WorkKey（odd）と WorkKey（even）の組、または、

Packed Message Reply で同時に取得する同一 ServiceProviderID・同一

WorkKeyManagementID の WorkKey（odd）と WorkKey（even）の組を示す場合、

“一対の”という表記を加え、“一対の WorkKey”、“一対の WorkKey（odd）と

WorkKey（even）”などと表記する。

3.1.1. メッセージパラメータの設定受信機および DRM サーバは、以下の規定に従い、メッセージパラメータを設定す

る。

3.1.1.1. Get Permission Request parameters 受信機は、[MIPTV], 4.2.1.2 項および以下の規定に従い、Get Permission Requestのメッセージパラメータを設定する。

UsageRuleReference 事前に取得するUsageRuleReferenceを設定する。UsageRuleReferenceの

規定については、3.1.3項を参照のこと。


317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353

354 355 356 357

358 359 360 361 362 363

3.1.1.2. Get Permission Reply parameters DRMサーバは、[MIPTV], 4.2.1.3 項、4.2.1.4 項および以下の規定に従い、Get Permission Replyのメッセージパラメータを設定する。

Status 3.1.2.1項を参照のこと。

WorkKeyID 同一ServiceProviderIDかつ同一WorkKeyManagementIDのWorkKeyに関し、

同時期に発行する一対のWorkKey（odd）とWorkKey（even）の

WorkKeyVersionには連続した値を設定する。WorkKeyVersionが 255（FFh）と 0（00h）とである場合は、連続した値とみなすなお、WorkKeyIDの運用例については、A.4節を参照のこと。

PrivateData 同一ServiceProviderIDかつ同一WorkKeyManagementIDのWorkKeyに関し、

同時期に発行する一対のWorkKey（odd）とWorkKey（even）の

PrivateDataには、送信する「WorkKey・SubscriptionTierBits・ExtractInfo」の次回の更新有無および次回の更新におけるNotAfterから更新開始日時まで

のオフセット時間（更新開始日時オフセット、単位は分）として、同一の

値を設定する。なお、更新開始日時の詳細については、3.1.4項の式(3.1)を参照のこと。

次回の更新をおこなう場合、更新開始日時オフセットの値に 0001h（1分）～FFFFh（65535 分）を設定する。ただし、NotAfter の値が

0000FFFFh（更新開始日時オフセットの最大値）～FFFFFFFEh である

場合のみ設定可である。次回の更新をおこなわない場合、更新開始日時オフセットの値に 0000h

を設定する。NotAfter の値が FFFFFFFFh である場合は、更新開始日時

オフセットの値に 0000h を設定する。同一 ServiceProviderID かつ同一 WorkKeyManagementID の WorkKey に関

し、同時期に発行する一対の WorkKey（odd）と WorkKey（even）の

SubscriptionTierBits には同一の値を設定する。 NotBefore/NotAfter

同一 ServiceProviderID かつ同一 WorkKeyManagementID の WorkKey に関

し、同時期に発行する一対の WorkKey（odd）と WorkKey（even）の

NotBefore には、同一の値を設定する。同様に、同時期に発行する一対の

WorkKey（odd）と WorkKey（even）の NotAfter には、同一の値を設定す

る。

3.1.2. メッセージパラメータの検証 DRM サーバおよび受信機は、以下の規定に従い、メッセージ受信時にメッセージパ

ラメータを検証する。

3.1.2.1. Get Permission Request parameters DRMサーバは、[MIPTV], 4.2.4.1 項および以下の規定に従い、Get Permission Requestのメッセージパラメータを検証する。

ActionID ActionID が、以下に示す値の場合には検証失敗としない。


364 365

366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411

EXTRACT with Indirect Key Delivery（02h）

3.1.2.2. Get Permission Reply parameters 受信機は、[MIPTV], 4.2.4.2 項、4.2.4.4 項および以下の規定に従い、Get Permission Replyのメッセージパラメータを検証する。受信機は、以下の検証の成功後に、一対の「WorkKey・SubscriptionTierBits・ExtractInfo」を使用することとし、なお、受信機は検証に失敗した場合は、一対の

WorkKey として取得した 2 つの「WorkKey・SubscriptionTierBits・ExtractInfo」の

両方を使用しない。また、受信機は保持する一対の「WorkKey・SubscriptionTierBits・ExtractInfo」と同

一ServiceProviderID・同一WorkKeyManagementIDの一対の「WorkKey・SubscriptionTierBits・ExtractInfo」を取得した場合、以下の検証の成功後に、

[MIPTV], 6.1.3 項の規定にしたがい一対の「WorkKey・SubscriptionTierBits・ExtractInfo」を更新する。

WorkKeyID 一対の WorkKey（odd）・WorkKey（even）として取得した 2 つの

WorkKey が、同一 ServiceProviderID かつ同一 WorkKeyManagementID の

一対の WorkKey（odd）と WorkKey（even）であることを検証する。したがって、取得した 2 つの WorkKeyID の値が以下の条件のいずれかに該

当する場合、検証失敗とする。 ServiceProviderID・ReservedByte（WorkKeyID の上位 3 バイト目）・

WorkKeyManagementID のいずれかの値が異なる場合 WorkKeyVersion の値が連続した値でない場合。ただし、2 つの

WorkKeyVersion の値が 255（FFh）と 0（00h）である場合は、連続し

た値とみなすこと。 PrivateData（更新開始日時オフセット）の値が 0001h～FFFFh（更新され

る）である「WorkKey・SubscriptionTierBits・ExtractInfo」を更新する場合

において、更新前後の WorkKey（odd）・WorkKey（even）が、同一

ServiceProviderID かつ同一 WorkKeyManagementID の WorkKey であるこ

とを検証する。したがって、更新前後の WorkKey（odd）または WorkKey（even）の

WorkKeyID の値が以下の条件に該当する場合、検証失敗とする。 ServiceProviderID・ReservedByte・WorkKeyManagementID のいずれ

かの値が異なる場合 PrivateData

一対の WorkKey（odd）・WorkKey（even）として取得した 2 つの

WorkKey の PrivateData（更新開始日時オフセット）の値が異なる場合、検

証失敗とする。 SubscriptionTierBits


WorkKey の SubscriptionTierBits の値が異なる場合、検証失敗とする。 NotBefore/NotAfter


WorkKey の NotBefore の値が異なる場合、検証失敗とする。同様に、2 つの WorkKey の NotAfter の値が異なる場合、検証失敗とする。

PrivateData（更新開始日時オフセット）の値が 0001h～FFFFh（更新され

る）である WorkKey に関して、NotAfter（単位は分）の値が 0000FFFFh


412 413 414 415

416 417 418 419 420 421 422 423 424 425 426 427 428 429 430

（更新開始日時オフセットの最大値）よりも小さい場合、または、

FFFFFFFFh（期限なし）である場合、検証失敗とする。更新開始日時オフセットの詳細については、3.1.4項の式(3.1)を参照のこと。

3.1.3. UsageRuleReference の設定表3-1に示す通りとする。 UsageRuleReferenceの設定は、

UsageRuleReference は、上位 6 バイトの値のみを規定し、下位 10 バイトの値は規

定しない。すなわち、UsageRuleReference の下位 10 バイトの値は、サービス事業

者の運用により任意の値を設定して良い。 UsageRuleReferenceの上位 6 バイトは、“ServiceProviderID”、

“ReservedByte”、“WorkKeyManagementID”、および“odd/evenID”から構成

される。UsageRuleReferenceの運用例については、A.4節を参照のこと。表3-1なお、のバイトインデックスの値は、UsageRuleReferenceの最上位バイトか

らの相対値である。また、以降では、「WorkKey（odd）・SubscriptionTierBits・ExtractInfo」に対応す

る UsageRuleReference を“UsageRuleReference（odd）”、「WorkKey（even）・SubscriptionTierBits・ExtractInfo」に対応する UsageRuleReference を

“UsageRuleReference（even）”と表記する。


表3-1 UsageRuleReferenceの設定

バイト

インデ

ックスパラメータパラメータの説明パラメータ値の規定

0-1 ServiceProviderID

・[MIPTV], 4.2.1.5.1 項

で規定される

ServiceProviderIDであ

る。

・UsageRuleReference に対

応する WorkKey の

ServiceProviderID と同一の値

を設定する。 2 ReservedByte ・[MIPTV], 4.2.1.5.1 項

で規定される

ReservedByteである。



ReservedByte と同一の値

（00h）を設定する。 3-4 WorkKeyManag

ementID ・[MIPTV], 4.2.1.5.1 項

で規定されるWorkKeyManagement IDである。



WorkKeyManagementID と同

一の値を設定する。 5 odd/evenID ・[MIPTV], 4.2.1.5.1 項

で規定される

WorkKeyVersionのLSBの値である。

・LSB に

UsageRuleReference に対応

する WorkKey の

WorkKeyVersion の LSB と同

一の値を設定する。・上位 1 ビット目から上位 7ビット目までは 0b を設定す

る。 431

432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452

3.1.4. 受信機における「WorkKey・SubscriptionTierBits・ExtractInfo」の取得に関する処理

受信機は、「WorkKey・SubscriptionTierBits・ExtractInfo」の取得に関して、

[MIPTV], 4.2.4.4 項および以下の規定に従い処理をおこなう。

受信機は、「WorkKey・SubscriptionTierBits・ExtractInfo」の取得時には、事前

に取得する UsageRuleReference（odd）・UsageRuleReference（even）を用

いて、同一 ServiceProviderID かつ同一 WorkKeyManagementID の一対の

「WorkKey（odd）・SubscriptionTierBits・ExtractInfo」と「WorkKey（even）・SubscriptionTierBits・ExtractInfo」とを取得する。

受信機は、取得した一対の WorkKey（odd）・WorkKey（even）の更新開始日

時オフセット（StatusExtension の PrivateData）の値が 0001h～FFFFh（更新

される）である「WorkKey・SubscriptionTierBits・ExtractInfo」の更新の制御を

おこなう場合は、以下に従う。受信機は、WorkKey（odd）または WorkKey（even）の NotAfter および更

新開始日時オフセットの値を用いて、式(3.1)に従い更新開始日時（単位は

分）を算出する。更新開始日時オフセットの値は、NotAfter（単位は分）か

ら更新開始日時までのオフセット時間（単位は分）を示す。

（更新開始日時）＝（NotAfter）－（更新開始日時オフセット）･･･ (3.1)


453 454 455 456 457 458 459 460

461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486

487 488 489 490 491 492 493 494 495 496

受信機は、式(3.1)により算出した更新開始日時以降、DRM サーバから一対

の更新された「WorkKey・SubscriptionTierBits・ExtractInfo」を取得するこ

とができる。更新開始日時以降、受信機は速やかに更新することが望まし

い。受信機は、取得した一対の WorkKey（odd）・WorkKey（even）の更新開始日

時オフセットの値が 0000h（更新されない）である場合は、当該「WorkKey・SubscriptionTierBits・ExtractInfo」の更新の制御はおこなわない。

3.1.5. DRM サーバにおける「WorkKey・SubscriptionTierBits・ExtractInfo」の送信に関する処理

DRM サーバは、「WorkKey・SubscriptionTierBits・ExtractInfo」の送信に関して、

以下の規定に従い処理をおこなう。

DRM サーバは、同一 ServiceProviderID かつ同一 WorkKeyManagementID の

WorkKey に関し、同時期に一対の WorkKey を発行する運用をおこなうこと。す

なわち、DRM サーバは、同一 ServiceProviderID かつ同一

WorkKeyManagementID の WorkKey に関して、受信機から「WorkKey（odd）・SubscriptionTierBits・ExtractInfo」または「WorkKey（even）・

SubscriptionTierBits・ExtractInfo」の要求を受信した場合、対応する

「WorkKey・SubscriptionTierBits・ExtractInfo」を送信する。このとき DRM サーバは、WorkKey（odd）または WorkKey（even）のい

ずれか一方は、WorkKey の送信時点で ECM を暗号化する WorkKey を送信

する。サービス事業者が、ServiceProviderID および WorkKeyManagementID で特定さ

れる「WorkKey・SubscriptionTierBits・ExtractInfo」を更新する運用をおこなう

場合、DRM サーバは、当該「WorkKey・SubscriptionTierBits・ExtractInfo」の

受信機ごとの更新開始日時以降に当該受信機からの要求を受信した場合、少な

くとも NotAfter の値を更新した「WorkKey・SubscriptionTierBits・ExtractInfo」を送信する。

DRMサーバは、3.1.4項の式(3.1)に従い、受信機ごとの更新開始日時を算出

する。式(3.1)のNotAfterは、当該「WorkKey・SubscriptionTierBits・ExtractInfo」に関して、当該受信機に対して最後に送信したWorkKeyのNotAfterの値を用いる。

3.2. Get Trusted Time Protocol [MIPTV], 4.2.2 項で規定されるGet Trusted Time Protocolは、Datetimeの取得に用い

る。受信機は、[MIPTV], 4.2.2.2 項の規定に従い、Get Trusted Time Requestのメッセー

ジパラメータを設定する。また、受信機は、[MIPTV], 4.2.4.10 項の規定に従い、Get Trusted Time Replyのメッセージパラメータを検証する。 DRMサーバは、[MIPTV], 4.2.4.9 項の規定に従い、Get Trusted Time Requestのメッ

セージパラメータを検証する。また、DRMサーバは、[MIPTV], 4.2.2.3 項の規定に従

い、Get Trusted Time Replyのメッセージパラメータを設定する。


497 498 499 500 501 502 503 504 505 506 507 508 509 510 511

512 513 514 515

516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539

3.3. Packed Message Protocol [MIPTV], 4.2.3 項で規定されるPacked Message Protocolは、以下のパラメータを同

時に取得する場合に用いる。

1 または複数の“一対の「WorkKey（odd）・SubscriptionTierBits・ExtractInfo」と「WorkKey（even）・SubscriptionTierBits・ExtractInfo」”

1 または複数の“一対の「WorkKey（odd）・SubscriptionTierBits・ExtractInfo」と「WorkKey（even）・SubscriptionTierBits・ExtractInfo」” および Datetime

本節では、以下の項目を規定する。

メッセージパラメータの設定メッセージパラメータの検証

3.3.1. メッセージパラメータの設定受信機およびDRMサーバは、以下の規定に従い、メッセージパラメータを設定する。

3.3.1.1. Packed Message Request parameters 受信機は、[MIPTV], 4.2.3.2 項および以下の規定に従い、Packed Message Requestのメッセージパラメータを設定する。

RequestMessageBoxList RequestMessageBoxListには、表 3-2に示す順番でRequestMessageを格納

する。 RequestMessage の個数は（2×N）個または（2×N＋1）個とする。

ここで、N は 16 以下の自然数である。（2×M－1）番目と（2×M）番目の RequestMessage には、同一

ServiceProviderID・同一 WorkKeyManagementID の「WorkKey・SubscriptionTierBits・ExtractInfo」を取得するための Get Permission Request（UsageRuleReference の ServiceProviderID・

WorkKeyManagementID が同一の値）を格納する。ここで、M は N 以

下の自然数である。なお、以降、N または M を用いた RequestMessage の個数および順番

の表記については「×」を省略し、（2×N）を（2N）などと記す。（2M－1）番目の RequestMessage には「WorkKey（odd）・

SubscriptionTierBits・ExtractInfo」を、（2M）番目の

RequestMessage には「WorkKey（even）・SubscriptionTierBits・ExtractInfo」を取得するための Get Permission Request を格納する。

RequestMessage の個数が（2N＋1）個の場合、（2N＋1）番目の

RequestMessage には Get Trusted Time Request を格納する。

表3-2 RequestMessageBoxListに格納可能な RequestMessageの組み合わせ

RequestMessage

1 番目の Request

2 番目の Request

… （2M－1）番

目 *5 の

（2M）番目 *5 の Request

… （2N＋1）番

目 *5 の


の個数 Message Message Request Message *6

Message *6 Request Message

2N

*5

Get Permission Request *1

ActionID：EXTRACT with Indirect Key Delivery（02h）

UsageRuleReference：UsageRuleReference（odd）*3



UsageRuleReference： UsageRuleReference（even）*4

… Get Permission Request *1






…

2N+1

*5



UsageRuleReference： UsageRuleReference（odd）*3




… Get Permission Request *1






… Get Trusted Time Request *2

540 541 542 543 544 545 546 547 548 549 550 551 552

553 554 555 556

*1：メッセージパラメータの設定については、3.1.1項を参照のこと。 *2：メッセージパラメータの設定については、3.2項を参照のこと。 *3：「WorkKey（odd）・SubscriptionTierBits・ExtractInfo」に対応する

UsageRuleReference（odd/evenIDの値が 01h）を示す。詳細は3.1.3項を参

照のこと。 *4：「WorkKey（even）・SubscriptionTierBits・ExtractInfo」に対応する

UsageRuleReference（odd/evenIDの値が 00h）を示す。詳細は3.1.3項を参

照のこと。 *5： N≦16、M≦N（N、M はともに自然数）とする。 *6：（2M－1）番目と（2M）番目の RequestMessage の UsageRuleReference は、

同一 ServiceProviderID・同一 WorkKeyManagementID とする。

3.3.1.2. Packed Message Reply parameters DRMサーバは、[MIPTV], 4.2.3.3 項の規定に従い、Packed Message Replyのメッセ

ージパラメータを設定する。


557 558 559 560

561 562 563 564 565 566 567 568 569 570 571

572 573 574 575 576 577 578 579 580 581

582 583 584 585 586

587

588 589 590 591

592 593 594 595 596 597 598

3.3.2. メッセージパラメータの検証 DRM サーバおよび受信機は、以下の規定に従い、メッセージ受信時にメッセージパ

ラメータを検証する。

3.3.2.1. Packed Message Request parameters DRMサーバは、[MIPTV], 4.2.4.11 項および以下の規定に従い、Packed Message Requestのメッセージパラメータを検証する。

RequestMessageBoxList RequestMessageBoxListにActionIDが「EXTRACT with Indirect Key

Delivery（02h）」のGet Permission RequestのRequestMessageが 1 以上格

納されている場合、かつ、RequestMessageの組み合わせが表 3-2の組合せ

以外の場合には検証失敗とし、Packed Message Reply parameterのStatusを「Message format error（8009h）」とする。

3.3.2.2. Packed Message Reply parameters 受信機は、[MIPTV], 4.2.4.12 項および以下の規定に従い、Packed Message Replyのメッセージパラメータを検証する。

ReplyMessageBoxList Statusが「Success（0000h）」の場合には、3.1.2.2項にしたがい、

ReplyMessageBoxListに格納されたReplyMessageを検証する。

ReplyMessageBoxListに格納されたいずれかのReplyMessageの検証に失敗

した場合には、Packed Message Reply全体を検証失敗とする。

3.4. ECM に関する規定本節では、[MIPTV], 6.1.2 項で規定されるECM formatに関する運用を規定する。

CA_descriptor および ECM の送出

3.4.1. CA_descriptor および ECM の送出

3.4.1.1. CA_descriptor の送出 CA_descriptor の descriptor_tag の値は、09h とする。 CA_descriptor の CA_system_ID の値は 0x000Dh とする。

3.4.1.2. ECM の送出 ECM の更新

ECM の更新間隔は、6 秒以上とする。 ECM の再送

ECM の再送間隔は、最小 100ms・最大 1000ms とする。推奨値は 100msとする。


599

600

601 602 603 604 605 606 607

608 609 610

611 612 613 614

615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634

635 636 637

4. ネットワーク通信プロトコル（HTTP）に関する規

定 SAC本章では、のメッセージの伝送に用いるネットワーク通信プロトコル

（HTTP）の運用を規定する。

[RFC2616] HTTP/1.1ネットワーク通信プロトコルは、で規定されるおよび

[RFC2109] Cookie Cookie SACで規定されるに準拠し、以下に示す運用とする。はの

セッションを識別するために用いる。なお、CookieとSet-Cookieにおけるattributeのうち設定および解釈を必須とするのはNAMEのみとする。、

4.1. HTTP による SAC のメッセージの伝送 HTTP SAC 1メッセージにはのメッセージを個のみ格納して送信する。

4.2. HTTP ヘッダ本節では、必須となる HTTP ヘッダについて規定する。

HTTP以下に示すヘッダ以外は実装依存であり、受信しても解釈しなくてよい。

4.2.1. サイズ受信機と DRM サーバは、以下に示す規定に従う。なお、本項におけるヘッダとは、HTTPヘッダを含むHTTPメッセージにおけるstart-lineから空行までを示す。

1 ヘッダ行のサイズ

受信機とDRMサーバは、 1 CR＋LFヘッダ行（を含む）のサイズの上限は

256byte とし、それを超える場合は、複数行に分割する。

256byte 受信機とDRMサーバは、1行がを超えるヘッダを含むメッセージは

受信できなくてもよい。ヘッダ全体のサイズ

受信機とDRMサーバは、 4096byteヘッダ全体のサイズがを超えるメッセー

ジ 1Kbyteを受信できなくてもよい。但し、プロキシにより程度のヘッダが

付加されても受信できるように、5Kbyte程度のヘッダは受信できるよう受

信機の実装は考慮されるべきである。

DRMサーバは、送信するレスポンス 4096byteヘッダ全体のサイズがを超え

ないようにすべきであリクエストヘッダに表 4-1る。但し、受信したに記載

されている以外のヘッダ項目が設定されている場合は、送信するレスポン

スヘッダ全体のサイズが4096byte を超えてもよい。

4.2.2. メソッド

としてPOSTメソッドのみ運用する。受信機は、


638 639 640

4.2.3. リクエストヘッダ

表4-1DRMサーバは、リクエストヘッダとしてに記載されたもののみ解釈を必須と

する。表4-1の運用に従う。受信機は、

表4-1 解釈を必須とするHTTP リクエストヘッダ

ヘッダ運用 Cookie 受信機は、SAC Cookieをを終了する場合に

削除する。受信機は、Challenge message以外を送信す

る場合はSet-Cookieで指定されたCookieをつ

けて、Challenge message送信時にはCookieをつけない。

Request

Host

General

Connection Close のみ運用し、受信機のリクエストヘッ

ダの設定処理において、HTTP のリクエスト

を送信する際に HTTP のレスポンス受信後に

TCP connection を切断することが確定して

いる場合には必ず用いる。 Content-Length Entity Content-Type Application/octet-streamのみ運用する。

641

642 643 644 645 646 647 648

4.2.4. レスポンスヘッダ

表4-2受信機は、レスポンスヘッダとしてに記載されたもののみ解釈を必須とする。

DRMサーバは表4-2の運用に従う。なお、DRMサーバはHTTPのリクエストが正常である場合はステータスコードとし

て 200 OK 200 OK「」のみを送信する。受信機は、ステータスコードとして「」以

外はエラーとなお、HTTPがエラーの場合でも、SACは終了しなくてよい。する。

表4-2 解釈を必須とするHTTP レスポンスヘッダ

ヘッダ運用

Response

Set-Cookie Set-Cookieの値 SACのセッションはを識別

可能な情報を格納する。

Cookie 1の最大数は個とする。

Set-Cookie は複数行に分割しない。 Cache-Control No-cacheのみ運用する。

General Connection Close のみ運用し、TCP connection 切断時

には必ず用いる。 Content-Length Entity Content-Type Application/octet-streamのみ運用する。

649


650 651 652 653 654 655

4.3. メッセージ処理中の受信機から HTTP のリクエストを受信した時の DRM サーバの処理

受信したメッセージ処理中に、メッセージを送信した受信機からHTTPのリクエスト

を受信した場合、DRMサーバは [MIPTV], 4.1 節に規定するSACの処理は行わずに、

ステータスコードが「200 OK」以外のHTTPレスポンスを送信する。


656

657

658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704

A. Appendix（Informative）

A.1 SAC 処理の例

A.1.1 状態遷移処理に関わる受信機の状態遷移を表A-1 DRMサーバの状態遷移を表A-2SAC に、に

示す。

SAC を行う 1 対の受信機と DRM サーバは、状態遷移表に従って状態を遷移する。本書の規定外となる状態とイベントの組み合わせは、表中“－”で示す。なお、本

書に規定されていないが、表A-1 受信機のSACタイムアウトを記述した。に


表A-1 受信機の状態遷移表受信機の状態

③Response & Request message送信後のメッセージ受

信待ち

④Request message送信後のメ

ッセージ受信待ち

①SAC開始前

②Challenge message 送信

後のメッセー

ジ受信待ち送信する

Request があ

る

送信する

Request がな

い

送信する

Request があ

る

送信する

Request がな

い

⑤Encrypted command message送信後のメッ

セージ受信

待ち

SAC A.1.2項(1)

開始指示

の処

理を実

行し

て、②

に移る

－－－－－－

Response & Challenge message受信

A.1.2 (4) ①に移る ①に移る ①に移る ①に移る ①に移る

－

項の

処理を実行す

る

• メッセー

ジ検証に

成功した

場合は③

に移る • メッセー

ジ検証に

失敗した

場合は①

に移る

メッセージ受信イベント

Reply message受信

A.1.2 (8) A.1.2 (8) A.1.2 (8) A.1.2 (8) ①に移る項の

処理を実行

項の

処理を実行

項の

処理を実行

項の

処理を実行す

るす

るす

るす

る

• メッセー

ジ検証に

成功した

場合は④

に移る

• メッセー

ジ検証に

成功した

場合は⑤

に移る

• メッセー

ジ検証に

成功した

場合は④

に移る

• メッセー

ジ検証に

成功した

場合は⑤

に移る－

• メッセー

ジ検証に

失敗した

場合は①

に移る

• メッセー

ジ検証に

失敗した

場合は①

に移る

• メッセー

ジ検証に

失敗した

場合は①

に移る

• メッセー

ジ検証に

失敗した

場合は①

に移る Encrypted command message受信

①に移る A.1.2 (14) A.1.2 (14) A.1.2 (14)項の

処理を実行

項の

処理を実行

項

し

て

し

て

の処理を実

行－

①に移る ①に移る、、して、①

に移る Plain command message受信

A.1.2 (15) A.1.2 (15) A.1.2 (15) ①に移る ①に移る ①に移る項の

処理を

項の

処理を

項の

処理を実行し

て

実行し

て

実行し

て－

①に移る ①に移る ①に移る、、、

[MIPTV], 4.1.4.1 項

のMessage header検証に失敗

（PayloadTypeが上

記のメッ

セージの

①に移る ①に移る ①に移る ①に移る ①に移る ①に移る

－


受信機の状態

③Response & Request message送信後のメッセージ受

信待ち

④Request message送信後のメ

ッセージ受信待ち

①SAC開始前

②Challenge message 送信

後のメッセー

ジ受信待ち送信する

Request があ

る

送信する

Request がな

い

送信する

Request があ

る

⑤Encrypted command message送信後のメッ送信するセージ受信Request がな待ちい

場合を除

く） SAC タイムア

ウト ①に移る ①に移る ①に移る ①に移る ①に移る ①に移る

－

705

表A-2 DRMサーバの状態遷移表 DRMサーバの状態㋐SAC 開始前のメッセージ受信待 Response & Challenge messageち

㋑

送信後のメッセージ受信待ち

Reply message㋒送信後のメッセー

ジ受信待ち

Challenge message受信

A.1.2 (2) する新たなSACとして0 (2) 新たなSACとして0 (2)項の処理を実行

• メッセージ検証に成功

した場合は㋑に移る • メッセージ検証に失敗

した場合は㋐に移る

項の処理を実

行する。Response & Challenge messageを送信したSACは終了す

る。

• メッセージ検証に成功し

た場合は㋑に移る • メッセージ検証に失敗し

た場合は㋐に移る

項の処理を実

行する。Reply messageを送信した

SACは終了する。


た場合は㋑に移る • メッセージ検証に失敗し


メッセージ受信イベント

Response & Request message受信

A.1.2 (6) するに移る項の処理を実行㋐㋐


た場合は㋒に移る • メッセージ検証に失敗し


に移る

Request message受信

A.1.2 (10) するに移る㋐に移る項の処理を実行㋐


た場合は㋒に移る • メッセージ検証に失敗し

た場合は㋐に移る Encrypted command message受信

A.1.2 (12)に移る㋐に移る項の処理を実行して、㋐に

移る㋐

[MIPTV], 4.1.4.1 項

のMessage header検証に失敗

（PayloadTypeが上

記のメッ

セージの

場合を除

く）

に移る㋐に移る㋐㋐に移る

SAC タイムア

ウト㋐に移る㋐

－に移る

706

707 708

A.1.2 メッセージ処理

本項では、メッセージ送受信時に行うメッセージ処理を示す。


709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729

730 731 732 733 734 735 736 737 738 739 740 741 742

743

744 745 746

の基本シーケンスについて、図A-1と図A-2以降で説明するメッセージ処理に示す。

図中の()つきの番号は、各メッセージの送受信処理の種類を示す。以下、各処理につ

いて説明する。 DRM サーバ受信機

(1)

図A-1 基本シーケンス（複数のRequestを連続送信する場合）

図A-2 基本シーケンス（一つのRequestのみ送信する場合）

(1). Challenge message 送信時の受信機処理 Challenge messageを作成する。 DRMサーバにChallenge messageを送信する。

Challenge message (2)

Response & Challenge message (3) (4)

Response & Request message (5) (6)

Reply message (7) (8)

※Request message、Reply messageの繰り返し

Encrypted command message（Commit）

Encrypted command message（ACK）

Request message (9) (10)


(11) (12)

(13) (14)

DRM サーバ受信機

Challenge message (1) (2)

Response & Challenge message (3) (4)

Response & Request message (5) (6)


(11) Encrypted command message Commit（）(12) Encrypted command message ACK（）(13)

(14)


747 748

749 750 751 752 753 754 755

756 757 758 759 760 761 762 763 764

765 766 767 768 769 770 771

772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792

Challenge message送信後のメッセージ受信待ちの状態に移る。

(2). Challenge message 受信時の DRM サーバ処理 [MIPTV], 4.1.4.2 項の規定に従い、Challenge messageの検証を行う。

検証が成功した場合、(3)Response & Challenge message送信時の

DRMサーバ処理を実行する。検証が失敗した場合、(16)Plain command message送信時のDRMサー

バ処理を実行する。

(3). Response & Challenge message 送信時の DRM サーバ処理 Response & Challenge message を作成する。Response & Challenge

message のメッセージパラメータに関する処理を以下に示す。 Signature：SinkRandomNumber SourceEC-DHPhase1Valueに対してと

する。生成

Response & Challenge message 受信機にを送信する。

Response & Challenge message送信後のメッセージ受信待ちの状態に移る。

(4). Response & Challenge message受信時の受信機処理 [MIPTV], 4.1.4.3項の規定に従い、Response & Challenge messageの検証を

行う。

検証が成功した場合 (5)、 Response & Request message送信時の受信

機処理を実行する。

SAC して、SAC開始前の状態に移。検証が失敗した場合、を終了る

(5). Response & Request message送信時の受信機処理セッション鍵を生成する。 Response & Request messageを作成する。SequenceNumber、

TransactionFlag、Request、MessageDigestは生成したセッション鍵で暗号

化する。Response & Request messageのメッセージパラメータに関する処

理を以下に示す。 Signature SourceRandomNumber SinkEC-DHPhase1Value：とに対し

て生成する。 SequenceNumber 1 Response & Request message：をに設定し、保持

する。 TransactionFlag 「even 00h Response & Request message：（）」を

に設定し、保持する。

Service Protocolのメッセージを Request：設定する。

MessageDigest MessageDigest ：暗号化前のを除くResponse & Request message のパラメータから生成する。

Response & Request message 作成後に保持している SequenceNumber を1 増加する。

Response & Request message DRMサーバをに送信する。

Response & Request message送信後のメッセージ受信待ちの状態に移る。


793 794 795 796 797 798 799 800 801 802 803 804 805

806 807 808 809 810 811 812 813 814 815 816 817 818 819

820 821 822 823 824 825 826 827 828 829 830 831 832

833 834 835 836 837 838

(6). Response & Request message受信時のDRMサーバ処理 [MIPTV], 4.1.4.4 項の規定 Response & Request message に従い、の検証を

行い、セッション鍵を生成する。

検証が成功した場合、以下の (7)処理を行い、 Reply message送信時の

DRMサーバ処理を実行する。 SequenceNumber [MIPTV], 4.1.4.4 SequenceNumberとして、項で

1 2 の確認に用いた値よりも大きい値であるを保持する。

Response & Request message TransactionFlag のを保持する。

Service Protocol Response & Request messageからのメッセージを

抽出する。検証が失敗した場合、(16)Plain command message送信時のDRMサー

バ処理を実行する。

(7). Reply message送信時のDRMサーバ処理 SequenceNumber Reply messageを作成する。、

TransactionFlagRecordFlag Reply MessageDigest、、はセッション鍵で暗

号化する。Reply messageのメッセージパラメータに関する処理を以下に

示す。 SequenceNumber SequenceNumber：保持しているを用いる。

TransactionFlagRecordFlag 00h ：を設定する。

Reply Service Protocolのメッセージを：設定する。

MessageDigest MessageDigest Reply message：暗号化前のを除くのパ

ラメータから生成する。 Reply message 作成後に保持している SequenceNumber を 1 増加する。 Reply message を受信機に送信する。

Reply message 送信後のメッセージ受信待ちの状態に移る。

(8). Reply message受信時の受信機処理 [MIPTV], 4.1.4.6 項の規定に従い、Reply message 検証を行う。の

検証が成功した場合、以下の処理を行い、送信するRequestがある場合

は(9)のRequest message送信時の受信機処理を実行し、送信する

Requestがない場合は(11)Encrypted command message送信時の受信機

処理を実行する。 SequenceNumber 1 保持しているを増加する。

TransactionFlag の反転と保持を行う。現在、保持している

TransactionFlag even 00h odd 01h oddが（）の場合は「（）」を、

01h even 00h （）の場合は「（）」を保持する。

Service Protocol Reply messageからのメッセージを抽出する。

SAC して、SAC開始前の状態に移。検証が失敗した場合、を終了る

(9). Request message送信時の受信機処理 Request messageを作成する。SequenceNumber、TransactionFlag、

Request、MessageDigestはセッション鍵で暗号化する。Request messageのメッセージパラメータに関する処理を以下に示す。

SequenceNumber：保持している SequenceNumber を用いる。 TransactionFlag： TransactionFlagを用いる。保持している


839 840 841 842 843 844 845

846 847 848 849 850 851 852 853 854 855 856 857 858

859 860 861 862 863 864 865 866 867 868 869 870 871 872 873

874 875 876 877 878 879 880 881 882 883 884

Request：Service Protocolのメッセージを。設定する

MessageDigest： MessageDigest を除くRequest message暗号化前の

から生成する。のパラメータ

Request message作成後に SequenceNumber 1 保持しているを増加する。

Request message DRM をサーバに送信する。

Request message 送信後のメッセージ受信待ちの状態に移る。

(10). Request message受信時のDRMサーバ処理 [MIPTV], 4.1.4.5項の規定に従い、Request message 検証を行う。の

検証が成功した場合、以下の (7)Reply message処理を行い、送信時の

DRM を実行するサーバ処理

SequenceNumber 1 保持しているを増加する。

TransactionFlag Request message保持しているを受信したの

TransactionFlag に変更して保持する。

Request message Service Protocol からのメッセージを抽出する。

検証が失敗した場合、以下の処理を行い、(17)Command が「ERROR」のEncrypted command message送信時のDRMサーバ処理

を実行する。 SequenceNumber 1 保持しているを増加する。

(11). Encrypted command message送信時の受信機処理 Encrypted command messageを作成する。SequenceNumber、

TransactionFlag、Command、Status、MessageDigestはセッション鍵で暗

号化する。Encrypted command messageのメッセージパラメータに関する

処理を以下に示す。 SequenceNumber：保持しているSequenceNumber を用いる。

Command Commit ：「」を設定する。

Success（0000h） Status：「」を設定する。

MessageDigest MessageDigest ：暗号化前のを除くEncrypted command message する。のパラメータから生成

Encrypted command message 作成後に保持している SequenceNumber を1 増加する。

Encrypted command message DRMサーバをに送信する。

Encrypted command message 送信後のメッセージ受信待ちの状態に移る。

(12). Encrypted command message受信時のDRMサーバ処理 [MIPTV], 4.1.4.8 項の規定に従い、Encrypted command messageの検証を

行う。検証が成功した場合、以下の処理を行い、(13)Command が「ACK」

のEncrypted command message DRM を実行する。送信時のサーバ処理

SequenceNumber 1 保持しているを増加する

検証が失敗した場合、以下の処理を行い、(17)Command が「ERROR」のEncrypted command message送信時のDRMサーバ処理

を実行する。 SequenceNumber 1 保持しているを増加する


885 886 887 888 889 890 891 892 893 894 895 896 897

898 899 900 901 902

903 904 905 906

907 908 909 910 911 912 913 914

915 916 917 918 919 920 921 922 923 924 925 926 927

(13). Command が「ACK」のEncrypted command message送信時のDRMサーバ処理 Encrypted command messageを作成する。SequenceNumber、



処理を以下に示す。 SequenceNumber SequenceNumber ：保持しているを用いる。

Command ACK ：「」を設定する。

Status： Success（0000h）「」を設定する。

MessageDigest：暗号化前のMessageDigestを除くEncrypted command message のパラメータから生成する。

Encrypted command messageを受信機に送信する。

SAC して、SAC開始前を終了の状態に移る。

(14). Encrypted command message受信時の受信機処理 [MIPTV], 4.1.4.8項の規定に従い、Encrypted command message の検証を行

う。 SAC して、SAC開始前の状態に移。を終了る

(15). Plain command message受信時の受信機処理 [MIPTV], 4.1.4.7 項の規定に従い、Plain command message う。の検証を行

して、SAC開始前の状態に移。 SACを終了る

(16). Plain command message送信時のDRMサーバ処理 Plain command message を作成する。Plain command message のメッセー

ジパラメータに関する処理を以下に示す。 Command ERROR ：「」を設定する。

Status Status：メッセージの検証で確定したを設定する。

Plain command message を受信機に送信する。

SACを終了して、SAC開始前のメッセージ受信待ちの状態に移る。

(17). Command が「ERROR」のEncrypted command message送信時のDRMサーバ処理 Encrypted command messageを作成する。SequenceNumber、



処理を以下に示す。 SequenceNumber SequenceNumber ：保持しているを用いる。

ERROR Command：「」を設定する。

Status：メッセージの検証で確定したStatus を設定する。

MessageDigest：暗号化前のMessageDigestを除くEncrypted command message のパラメータから生成する。

Encrypted command message を受信機に送信する。

SACを終了して、SAC開始前のメッセージ受信待ちの状態に移る。


928 929 930 931 932 933 934

935

936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959

A.2 SAC と Service Protocol を用いたシーケンス本節では、SAC と Service Protocol を用いたシーケンスとして、「WorkKey・SubscriptionTierBits・ExtractInfo」取得を解説する。図A-3にDRMサーバ・受信機間の「WorkKey・SubscriptionTierBits・ExtractInfo」取

得シーケンスを示す。

ＤRMサーバ

Response & Challenge message

Reply message

Encrypted command message

受信機

Challenge message

SAC確

「WorkKey・SubscriptionTierBits・ExtractInfo」取

得

Response & Request message

Encrypted command message

SAC終

図A-3 「WorkKey・SubscriptionTierBits・ExtractInfo」取得シーケンス

「WorkKey・SubscriptionTierBits・ExtractInfo」取得シーケンスに先立ち、受信機は

UsageRuleReference と DRM サーバの URI を取得・保持する。なお、

UsageRuleReference や DRM サーバの URI の取得に関する仕様は本書では規定し

ない。 1. SAC確立：[MIPTV], 4.1 節 Secure Authenticated Channel (SAC) Protocolで規

定されるプロトコルにより、受信機はDRMサーバとの間で相互認証を行い、

SACを確立する。 2. 「WorkKey・SubscriptionTierBits・ExtractInfo」取得： [MIPTV], 4.2.1 項 Get

Permission Protocolで規定されるプロトコルにより、受信機は「WorkKey・SubscriptionTierBits・ExtractInfo」取得要求を行い、DRMサーバから

「WorkKey・SubscriptionTierBits・ExtractInfo」を取得する。なお、

「WorkKey・SubscriptionTierBits・ExtractInfo」取得とDatetimeを同時に取得す

る場合、[MIPTV], 4.2.3 項 Packed Message Protocolで規定されるプロトコルを

用いる。 3. SAC終了：「WorkKey・SubscriptionTierBits・ExtractInfo」取得後、[MIPTV],

4.1 節 Secure Authenticated Channel (SAC) Protocolで規定されるプロトコルに

より、DRMサーバはCommandがACKのEncrypted command message を送信

した後に、受信機はCommandがACKのEncrypted command message を受信し

た後に、SACを終了する。以上の「WorkKey・SubscriptionTierBits・ExtractInfo」取得シーケンスにより、受信

機は「WorkKey・SubscriptionTierBits・ExtractInfo」を取得する。


960 961 962 963 964 965 966

967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999

1000 1001 1002

1003

その後、受信機は、コンテンツサーバから地上デジタルテレビジョン放送 IP 再送信

コンテンツをストリーミングで受ける。コンテンツに多重化された ECM は

WorkKey で復号され、ECM に含まれるスクランブル鍵を用いてコンテンツは復号

されて再生される。この際、ECM に含まれる RenderingObligation に従った処理を

行う必要がある。また、WorkKeyの扱いに関しては、[RTDBCR], 4 章の規定を参照のこと。

A.3 コンテンツの利用シーケンス本節では、コンテンツの利用に関して、受信機と DRM サーバとの間、および受信

機とコンテンツを配信するコンテンツサーバとの間のシーケンスの概要について説

明する。コンテンツの利用シーケンスは、以下に示す 3 つの処理により構成される。 ① 「WorkKey・SubscriptionTierBits・ExtractInfo」の処理取得

受信時のECM処理 ② コンテンツ

③ 「WorkKey・SubscriptionTierBits・ExtractInfo」の処理更新なお、以下の処理の事前に契約処理が行われ、受信機が「WorkKey・SubscriptionTierBits・ExtractInfo」の取得のための UsageRuleReference・DRM サ

ーバの URI を取得済みであることを前提とする。 DRMサーバ

受信機

コンテンツサーバ

①「WorkKey・SubscriptionTierBits・ExtractInfo」の取

得処理

Get Permission Request Message

Get Permission Reply Message 「WorkKey (odd)・SubscriptionTierBits・ExtractInfo」


Get Permission Reply Message 「WorkKey (even)・SubscriptionTierBits・ExtractInfo」



Get Permission Reply Message 「WorkKey (odd)・SubscriptionTierBits・ExtractInfo」

Get Permission Reply Message 「WorkKey (even)・SubscriptionTierBits・ExtractInfo」

「WorkKey・SubscriptionTierBits・ExtractInfo」の更

新処理

②IP マルチキャスト

コンテンツ受信時の

ECM 処理

図A-4 コンテンツの利用シーケンス


1004 1005 1006 1007 1008 1009 1010 1011

1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025

1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038

1039 1040 1041 1042 1043 1044 1045 1046 1047 1048

A.3.1 「WorkKey・SubscriptionTierBits・ExtractInfo」の取得処理受信機は、[MIPTV], 4.1 節で規定されるSecure Authenticated Channel (SAC) ProtocolによりSACを確立した上で、[MIPTV], 4.2.1 項で規定されるGet Permission Protocolにより、DRMサーバから「WorkKey・SubscriptionTierBits・ExtractInfo」を

取得する。なお、Get Permission Protocolによるメッセージシーケンスは、A.2節の

「WorkKey・SubscriptionTierBits・ExtractInfo」取得シーケンスと同様である。

A.3.1.1 ティアビット「WorkKey・SubscriptionTierBits・ExtractInfo」に関して、DRM サーバと受信機と

の間の通信回数・受信機での保持数の削減のため、サービス事業者の 1 以上のチャ

ネルに対して同一の WorkKey を適用する運用が想定される。そこで、受信機が有す

る契約に応じたチャネルの視聴制御のため、ティアビットとよばれる 64 ビットのビ

ット列を用いる。ティアビットの各ビットには、各チャネルに対する契約が対応づ

けられる。この対応づけは、サービス事業者の運用依存である。 DRMサーバは、WorkKeyとともに、ティアビットのうち受信機が有する契約に対応

するビットを示す“SubscriptionTierBits”を受信機に送信する。一方、ECMには、

ティアビットのうち当該チャネルに対する契約を示す“ChannelTierBits”が設定さ

れる。受信機は、SubscriptionTierBitsとChannelTierBitsとの照合により、受信機が

契約を有するチャネルのみを視聴可とするよう制御する。受信機でのティアビット

による視聴制御についてはA.3.2項を参照のこと。

A.3.1.2 WorkKeyManagementID A.3.1.1項で説明したティアビットを用いる運用を実現するため、サービス事業者は、

複数チャネルに適用するWorkKeyと、当該複数チャネルに対する契約を対応づけた

ティアビットとの対応を管理する。このWorkKeyおよびティアビットの管理単位を

特定する識別子を“WorkKeyManagementID”とよぶ。WorkKeyManagementIDは、

サービス事業者ごと（“ServiceProviderID”で識別される）に割り当てる識別子で

ある。受信機は、ServiceProviderIDおよびWorkKeyManagementIDの単位で、DRMサーバ

から「WorkKey・SubscriptionTierBits・ExtractInfo」を取得する。したがって、受信

機が取得時に指定するUsageRuleReferenceには、ServiceProviderIDと

WorkKeyManagementIDとが含まれる。なお、WorkKeyManagementIDおよび

UsageRuleReferenceの運用例については、A.4節を参照のこと。

A.3.1.3 WorkKey（odd/even）コンテンツに対して、一定期間などで ECM を暗号化する WorkKey を更新する運用

が想定される。このような運用において、WorkKeyの更新時でも受信機がECMを連続して復号し、

継続視聴が可能となるように、DRMサーバは同時期に一対となる 2 つのWorkKeyを発行する。この一対となる 2 つのWorkKeyを、“WorkKey（odd）”および

“WorkKey（even）”とよぶ。WorkKey（odd）とWorkKey（even）は、

WorkKeyIDに含まれるWorkKeyVersionのLSBの値（odd/evenID）により識別できる。

WorkKeyVersionの詳細については[MIPTV], 4.2.1.5.1 項を、運用例についてはA.4節を参照のこと。


1049 1050 1051 1052 1053 1054 1055 1056 1057

1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078

1079 1080 1081 1082 1083 1084 1085 1086

1087 1088 1089 1090 1091 1092

また、DRM サーバは、一対の WorkKey（odd）・WorkKey（even）として、

WorkKey の送出時点で ECM を暗号化する WorkKey と、ECM を暗号化する

WorkKey の次回更新後の WorkKey とを送信する。受信機は、2 つの Get Permission Protocol を用いて、DRM サーバから odd/even の

「WorkKey・SubscriptionTierBits・ExtractInfo」を個別に取得する。したがって、

DRM サーバが、odd/even のどちらの WorkKey を発行すればよいかを特定できるよ

うに、UsageRuleReference には要求する WorkKey の odd/evenID の値が設定され

る。

A.3.1.4 受信機における「WorkKey・SubscriptionTierBits・ExtractInfo」の管理受信機は、ServiceProviderID・WorkKeyManagementID の単位で、取得した一対の

「WorkKey・SubscriptionTierBits・ExtractInfo」を管理する。受信機は

「WorkKey・SubscriptionTierBits・ExtractInfo」として、少なくとも WorkKey、WorkKeyID、更新開始日時オフセット（PrivateData）、SubscriptionTierBits、NotBefore/NotAfter を管理する。 [MIPTV], 4.2.4.4 項で規定される通り、受信機は、保持するWorkKeyと“ServiceProviderID”、“ReservedByte”、“WorkKeyManagementID”、および

“ odd/evenID（WorkKeyVersionのLSB）”の 4 つの値が一致するWorkKeyを新た

に取得した場合、取得した「WorkKey・SubscriptionTierBits・ExtractInfo」で、保持

する「WorkKey・SubscriptionTierBits・ExtractInfo」を更新する。このとき、受信機

は、ServiceProviderID・WorkKeyManagementIDの単位での「WorkKey・SubscriptionTierBits・ExtractInfo」の管理にあわせて、一対の「WorkKey・SubscriptionTierBits・ExtractInfo」の単位で更新する。ただし、更新前後で値が同一

であるパラメータについては更新しなくても良い。なお、取得した「WorkKey・SubscriptionTierBits・ExtractInfo」を不揮発性記憶領域

に記録するか否かについては、受信機の実装依存である。ただし、受信機は、揮発

性記憶領域に保持する「WorkKey・SubscriptionTierBits・ExtractInfo」の電源断など

による消失を防止し、DRM サーバからの再取得を不要とするため、不揮発性記憶領

域に記録することが望ましい。

A.3.1.5 RenderingObligation による EXTRACT・RECORD・EXPORT 受信機は、[MIPTV], 6.1.2 項で規定されるECMのRenderingObligationに基づき、コ

ンテンツのEXTRACT、RECORD、およびEXPORTをおこなう。受信機は、[MIPTV], 4.2.1 項で規定されるRecordInfoおよびExportInfoは取得しない。 RenderingObligationの送出に関する遵守規則、および、RenderingObligationに基づ

く受信機におけるEXTRACT・RECORD・EXPORTに関する遵守規則については、

[RTDBCR], 2 章を参照のこと。

A.3.1.6 Packed Message Protocol による「WorkKey・SubscriptionTierBits・ExtractInfo」の取得受信機は、[MIPTV], 4.2.3 項で規定されるPacked Message Protocolを用いて、1 ま

たは複数の“一対の「WorkKey（odd）・SubscriptionTierBits・ExtractInfo」と

「WorkKey（even）・SubscriptionTierBits・ExtractInfo」”とを同時に取得するこ

とができる。


1093 1094 1095 1096

1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111

1112 1113 1114 1115

1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127

1128 1129 1130 1131 1132 1133 1134 1135

また、受信機は、1 または複数の“一対の「WorkKey（odd）・

SubscriptionTierBits・ExtractInfo」と「WorkKey（even）・SubscriptionTierBits・ExtractInfo」”とともに、Datetime を同時に取得することもできる。

A.3.2 コンテンツ受信時の ECM 処理受信機は、コンテンツサーバからコンテンツを受信し、ECMを抽出する。受信機は、

ECM毎にECMのWorkKeyIDで指定されるWorkKeyのNotBefore/NotAfterと[RTDBCR], 3.2 節の受信機内で保持する時刻（以下、本項では“受信機内で保持する時刻”と記

す）とを比較し、（NotBefore）≦（受信機内で保持する時刻）≦（NotAfter）を満

たす場合、受信機は当該WorkKeyを用いてECMを復号する。但し、NotBeforeの値

がFFFFFFFFhの場合は、NotBeforeと受信機内で保持する時刻との比較は不要であ

る。同様にNotAfterの値がFFFFFFFFhの場合は、NotAfterと受信機内で保持する時

刻との比較は不要である。復号したECMの検証後、[MIPTV], 6.1.3 項の規定の通り、受信機はECMの

ChannelTierBitsとWorkKeyのSubscriptionTierBitsとを照合し、同一位置のビットが

共に 1bとなるビットが存在する場合に視聴可と判定する。受信機は、視聴可と判定した場合、ECM から抽出した ScrambleKey によりコンテ

ンツを復号し、ECM に設定された RenderingObligation に従った利用をおこなう。

A.3.3 「WorkKey・SubscriptionTierBits・ExtractInfo」の更新処理受信機は、「WorkKey・SubscriptionTierBits・ExtractInfo」が更新される運用の場合

に、保持する「WorkKey・SubscriptionTierBits・ExtractInfo」の更新を制御する。

A.3.3.1 更新の有無と更新開始日時オフセット DRM サーバは、送信する「WorkKey・SubscriptionTierBits・ExtractInfo」の

StatusExtension の PrivateData（上位 23 バイト目から上位 24 バイト目）の値によ

り、次回の更新の有無、および、NotAfter から次回の更新が可能となる日時（更新

開始日時）までのオフセット時間を受信機に通知する。この 2 バイトの値を“更新

開始日時オフセット”とよぶ。 DRM サーバは、次回の更新をおこなう場合には、送信する「WorkKey・SubscriptionTierBits・ExtractInfo」の更新開始日時オフセットの値に 0001h～FFFFh（単位は“分”）を設定する。一方、DRM サーバは、契約の解約時など、次回の更新をおこなわない場合には、更

新開始日時オフセットの値に 0000h を設定する。

A.3.3.2 「WorkKey・SubscriptionTierBits・ExtractInfo」の更新「WorkKey・SubscriptionTierBits・ExtractInfo」が更新される運用（更新開始日時オ

フセットの値が 0001h～FFFFh）の場合、受信機は更新開始日時以降に更新するこ

とができる。更新のための「WorkKey・SubscriptionTierBits・ExtractInfo」の取得は、

A.3.1項と同等である。一方、DRM サーバは、更新開始日時以降に受信機から「WorkKey・SubscriptionTierBits・ExtractInfo」の取得要求を受信した場合、少なくとも NotAfterの値を更新した「WorkKey・SubscriptionTierBits・ExtractInfo」を送信する。


1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153

1154 1155 1156

1157 1158 1159 1160

1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180

「WorkKey・SubscriptionTierBits・ExtractInfo」の更新に関して、DRM サーバ・受

信機の実装は以下の事項が考慮されることが望ましい。 • DRM サーバ

受信機が短期間に繰り返し更新しないように、DRM サーバが更新後の

NotAfter に設定する値は、（「WorkKey・SubscriptionTierBits・ExtractInfo」の送信日時）＋（更新開始日時オフセット）よりも大きな値と

することが望ましい。 • 受信機

NotAfter と更新開始日時オフセットとに基づいて更新するか否かについては、

受信機の実装依存であるが、更新された場合に継続して視聴できるように

するため、受信機は更新開始日時以降、速やかに更新することが望ましい。 DRM サーバと受信機とで保持する時刻に誤差が生じている場合などは、

DRM サーバが NotAfter を更新する前に、受信機が更新のために

「WorkKey・SubscriptionTierBits・ExtractInfo」を取得してしまう場合が考

えられる。このような場合、受信機は短期間に繰り返し更新しないように、

間隔をあけて再度更新するなどの制御をおこなうことが望ましい。

A.4 WorkKeyID および UsageRuleReference の運用例本節では、WorkKeyID および UsageRuleReference の運用例を示す。

A.4.1 ティアビット・WorkKeyID・UsageRuleReference の関係サービス事業者が運用するティアビット、WorkKeyID、および

UsageRuleReference の関係について説明する。

A.4.1.1 WorkKeyID とティアビットとの関係 WorkKeyID は、“ServiceProviderID”、“ReservedByte”、

“WorkKeyManagementID”、および“WorkKeyVersion”から構成される。

WorkKeyID のうち、DRM サーバおよび受信機における WorkKey の管理単位となる

ID が、ServiceProviderID および WorkKeyManagementID である。サービス事業者

は、64 ビットからなるティアビットを管理し、当該ティアビットに対して

WorkKeyManagementID を対応づける。したがって、サービス事業者は、64 ビット

からなるティアビットを運用する個数分だけ、WorkKeyManagementID を管理する。たとえば、サービス事業者が 64 ビットからなるティアビットを 1 個用いる運用をお

こなう場合、当該サービス事業者は 1 つの WorkKeyManagementID を管理する。ま

た、64 ビットからなるティアビットを 2 個用いて、64 を超える契約を当該 2 個の

ティアビットに対応づける運用をおこなう場合、サービス事業者は 2 つの

WorkKeyManagementID を管理する。また、DRM サーバは、同一 ServiceProviderID・同一 WorkKeyManagementID の

WorkKey について、WorkKey 自体を更新する場合に限り、WorkKeyVersion を更新

する。すなわち、SubscriptionTierBits または ExtractInfo の値を更新する場合であっ

ても、WorkKey 自体を更新しない限り、WorkKeyVersion は更新しない。 WorkKeyIDの概要についてはA.3.1.2項およびA.3.1.3項を、詳細については[MIPTV], 4.2.1.5.1 項を参照のこと。


1181 1182 1183 1184 1185 1186 1187 1188

1189 1190 1191 1192 1193 1194 1195 1196

A.4.1.2 UsageRuleReference と WorkKeyID との関係 UsageRuleReference は、“ServiceProviderID”、“ReservedByte”、

“WorkKeyManagementID”、および“odd/evenID”から構成される。 ServiceProviderID・WorkKeyManagementID には、UsageRuleReference に対応す

る WorkKey の ServiceProviderID・WorkKeyManagementID と同一の値が設定され

る。また、odd/evenID には、UsageRuleReference に対応する WorkKey の

WorkKeyVersion の LSB と同一の値が設定される。

A.4.1.3 ティアビットと WorkKeyID・UsageRuleReference の値との関係の例サービス事業者が運用するティアビットと、WorkKeyID・UsageRuleReferenceの値

との関係の例を、表A-3に示す。ただし、WorkKeyIDおよびUsageRuleReferenceのReservedByteは固定値であるの

で、表A-3では記載を省略する。また、3.1.3項で規定する通り、UsageRuleReferenceの下位 10 バイトの値はサービ

ス事業者の運用依存であるため、表A-3では上位 6 バイトの値のみを記載する。

表A-3 サービス事業者が運用するティアビットと WorkKeyID・UsageRuleReferenceの値との関係の例

WorkKeyID の値：16 進表記 UsageRuleReference の値：16 進表記

サービスサービス事業者が

運用するティアビ

ット

事業者 ServiceProviderID

WorkKeyManagementID

WorkKeyVersion ServiceProviderID

WorkK odd/eveneyMan ID agementID

01, 03, …(odd) 01(odd) 0001 0001 0001 0001 1 個(*1)

サービス

事業者 1 一つ目のテ

ィアビット 02, 04, …(even) 00(even)01, 03, …(odd) 01(odd) 一つ目のテ

ィアビット 0001

02, 04, …(even)0001

00(even)0002 0002 2 個

01, 03, …(odd) 01(odd)

サービス

事業者 2 (*2) 0002 0002 二つ目のテ

ィアビット 02, 04, …(even) 00(even)1197 1198 1199 1200 1201

1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212

*1：64 ビットからなるティアビットを 1 個用いる運用をおこなうサービス事業者の

例である。 *2：64 ビットからなるティアビットを 2 個用いて、64 を超える契約を当該 2 個の

ティアビットに対応づける運用をおこなうサービス事業者の例である。

A.4.2 WorkKey を更新する運用における WorkKeyID と

UsageRuleReference との関係の例 DRM サーバは、ServiceProviderID・WorkKeyManagementID ごとに WorkKey のバ

ージョン（WorkKeyVersion）を管理する。DRM サーバは、受信機から WorkKey を

要求された場合、一対の WorkKey（odd）・WorkKey（even）として、WorkKey の

送信時点で ECM を暗号化する WorkKey と、ECM を暗号化する WorkKey の次回更

新後の WorkKey とを送信する。よって、DRM サーバは、ServiceProviderID・

WorkKeyManagementID ごとに少なくとも一対の WorkKeyVersion を管理する。 WorkKeyを更新する運用において、ECMを暗号化するWorkKeyのWorkKeyIDの値、

Get Permission ProtocolでDRMサーバから送信するWorkKeyのWorkKeyIDの値、


1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224

Get Permission ProtocolでWorkKeyを要求する際のUsageRuleReferenceの値の関係

の例を、表A-4に示す。表A-4において、Get Permission Protocolで送信するWorkKeyのWorkKeyVersionは、

ECMを暗号化するWorkKeyの更新以降に送信する値を示すものである。DRMサーバ

は、ECMを暗号化するWorkKeyの更新後、Get Permission Protocolで送信する一対

のWorkKey（odd）・WorkKey（even）も速やかに更新する。なお、A.4.1.3 表A-3 表A-4項のと同様に、においてWorkKeyIDおよび

UsageRuleReferenceのReservedByteは記載を省略する。また、

UsageRuleReferenceの下位 10 バイトの値についても、同様に記載を省略する。

表A-4 WorkKeyを更新する運用における WorkKeyIDとUsageRuleReferenceとの値の関係の例

ECM を暗号化する WorkKeyの WorkKeyID の値：16 進表

記

Get Permission Protocol で送

信する WorkKey の

WorkKeyID の値：16 進表記

UsageRuleReferenceの値：16進表記

ECMを暗号

化するWorkKey の

更新(*1)

ServiceProviderID

WorkKeyManagementID

WorkKeyVersion

ServiceProviderID

WorkKeyManagementID

WorkKeyVersion

ServiceProviderID

WorkK odd/eveneyMan ID agementID

01(odd) 01(odd) 0001 0001 0001 0001 0001 0001 01(odd) 運用開始 02(even) 00(even)

03(odd) 01(odd) 02(even) 1 回目

の更新

後 02(even) 00(even)

03(odd) 01(odd) 03(odd) 2 回目

の更新

後 04(even) 00(even)

････････････ FF(odd) 01(odd) FF(odd) 254 回

目の更

新後 00(even) 00(even)

01(odd) 01(odd) 00(even) 255 回

目の更

新後 00(even) 00(even)

1225 1226 1227 1228

1229 1230 1231 1232 1233 1234 1235 1236

*1：256 回目以降の更新では、表A-4における“運用開始～255 回目の更新後”の繰

り返しとなる。

A.5 「WorkKey・SubscriptionTierBits・ExtractInfo」の更新運用の例

図A-5 WorkKey SubscriptionTierBits ExtractInfo本節では、を用いて「・・」の更新

運用の例を示す。

図A-5以下、のイベントの囲い数字、および、DRMサーバ・事業者サーバの括弧書

きの数字に対応して、新規契約から解約までのDRMサーバ・事業者サーバ・受信機

の処理の概要について説明する。なお、事業者サーバは、契約・解約などをおこな

うサービス事業者のポータルサーバなどである。


1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262

本節では、以下を前提とした更新運用の例を示す。 • 特定の ServiceProviderID・WorkKeyManagementID の「WorkKey・

SubscriptionTierBits・ExtractInfo」に関して、特定の受信機についての例を示す。 • WorkKey の期限（NotBefore/NotAfter）を定期的に更新する、期限延長の運用を

基本とする。したがって、更新の度に「WorkKey・SubscriptionTierBits・ExtractInfo」の全てが更新されるとは限らないことに留意されたい。

• 期限の更新周期は 1 年とする。DRMサーバは、受信機ごとの契約月の 1 年後に

更新をおこなうため、NotAfterを契約月の 1 年後の月末日に設定する。なお、

NotBeforeには期限なし（FFFFFFFFh）を設定する。図A-5に示すNotAfterの年月日の表記は、受信機が取得するWorkKeyのNotAfterの値を示し、点線の矢印は、受信機が当該NotAfterの値を保持する期間を示す。

• 期限延長における更新開始日時はNotAfterの 14 日前とし、更新開始日時オフセ

ットに 14 日（20160 分）を設定する場合の例を示す。なお、以下では、更新開

始日時からNotAfterまでを“更新期間”と記す。図A-5に示す更新期間の年月日の表記は、受信機がNotAfterの値と更新開始日時

オフセットとから算出する更新期間（更新開始日時～NotAfter）を示し、点線の

矢印は、受信機が当該更新期間の値を保持する期間を示す。 • ECMを暗号化するWorkKeyのWorkKeyVersionの初期値は 1 とする。DRMサー

バは、図A-5に示す“⑦ ECMを暗号化するWorkKeyの更新”において、

WorkKeyVersionを 1 から 2 に更新する。 • 事業者サーバは、契約時や解約時などに「WorkKey・SubscriptionTierBits・

ExtractInfo」の取得のための UsageRuleReference・DRM サーバの URI（DRMサーバ URI）を含むファイルを提供する。以下、当該ファイルを“メタファイ

ル”と記す。

更新期間

NotAfter

イベント

受信機

DRMサーバ

事業者サーバ

121110987654321121110987654321月

20092008年

①新規契約

更新期間

NotAfter

イベント

受信機

DRMサーバ

事業者サーバ

121110987654321121110987654321月

20112010年

(1)

②期限延長 ③契約追加

④期限延長 ⑤契約一部解約申し込み ⑨全解約

(2) (3)

2009/4/16～2009/4/30

2011/4/30 2011/4/302010/9/3 2012/4/30

2009/4/302010/4/30

2010/4/16～2010/4/30

②の更新期間

2011/4/16～2011/4/30

④の更新期間

2011/10/31

2010/9/1～2010/9/3 2012/4/16～2012/4/30

⑥の更新期間 ⑧の更新期間

⑧期限延長⑥契約一部解約

⑦ECMを暗号化するWorkKeyの更新

(4)

(5)

(6)

(7)

(8) (9) (10)

(11)

(12)

2011/4/16～2011/4/301263 1264

1265 1266 1267 1268 1269

図A-5 「WorkKey・SubscriptionTierBits・ExtractInfo」の更新運用の例 ① 新規契約受信機は、2008/4 に事業者サーバに新規に契約を申し込む。受信機は、事業者サー

バから取得したメタファイルを用いて、DRM サーバから一対の「WorkKey・SubscriptionTierBits・ExtractInfo」を取得する。


1270 1271

(1) 事業者サーバからのメタファイルの取得

••1272 受信機は、事業者サーバに新規契約の要求を送信する。 ••1273

1274 事業者サーバは、受信機からの契約申し込みを受け付け、DRM サーバ

に契約内容を送信するなど、新規契約の受け付け処理を完了する。 ••1275

1276 1277

受信機は、事業者サーバからメタファイルを取得し、不揮発性記憶領域

に記録する。 (2) DRM サーバからの「WorkKey・SubscriptionTierBits・ExtractInfo」の取得

••1278 1279 1280

受信機は、メタファイルで指定される UsageRuleReference（odd）を

設定した Get Permission Request message を作成して、メタファイル

の DRM サーバ URI で指定される DRM サーバに送信する。 ••1281

1282 1283 1284 1285 1286 1287 1288 1289 1290

DRM サーバは、UsageRuleReference（odd）に対応する「WorkKey（odd）・SubscriptionTierBits・ExtractInfo」を設定した Get Permission Reply message を作成して、受信機に送信する。

NotAfter には、加入月の 1 年後の月末の日時（2009/4/30）を設定

する。送信する「WorkKey・SubscriptionTierBits・ExtractInfo」を次回に

更新することを通知するため、更新開始日時オフセットの値には

14 日（20160 分）を設定する。 WorkKey（odd）には、WorkKey の送信時点で ECM を暗号化する

WorkKey（WorkKeyVersion が 1）を設定する。 ••1291

1292 受信機は、DRM サーバから受信した Get Permission Reply message か

ら「WorkKey（odd）・SubscriptionTierBits・ExtractInfo」を取得する。 ••1293

1294 1295

受信機は、メタファイルで指定される UsageRuleReference（even）を



1297 1298 1299 1300 1301 1302 1303 1304

DRM サーバは、UsageRuleReference（even）に対応する「WorkKey（even）・SubscriptionTierBits・ExtractInfo」を設定した Get Permission Reply message を作成して、受信機に送信する。

SubscriptionTierBits・ExtractInfo には、WorkKey（odd）の

SubscriptionTierBits・ExtractInfo と同一の値を設定する。また、更

新開始日時オフセットには、WorkKey（odd）の更新開始日時オフ

セットと同一の値を設定する。 WorkKey（even）には、ECM を暗号化する WorkKey の次回更新

後の WorkKey（WorkKeyVersion が 2）を設定する。 ••1305


ら「WorkKey（even）・SubscriptionTierBits・ExtractInfo」を取得する。 ••1307

1308 受信機は、取得した一対の「WorkKey・SubscriptionTierBits・

ExtractInfo」を不揮発性記憶領域に記録する。 ••1309

1310 1311 1312 1313 1314 1315 1316 1317

受信機は、更新開始日時オフセットの値が 14 日（更新される）である

ことから、NotAfter と更新開始日時オフセットとを用いて次回の更新期

間（②の更新期間：2009/4/16～2009/4/30）を算出し、次回更新の制御

をおこなう。 [備考] • DRM サーバ


1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349

DRM サーバは、WorkKey（odd）または WorkKey（even）のいずれかとし

て、WorkKey の送信時点で ECM を暗号化する WorkKey を送信する。他方

は、ECM を暗号化する WorkKey の次回更新後の WorkKey を送信する。 DRM サーバは、受信機が有する契約の終了日時を経過するまでは、受信機

に「WorkKey・SubscriptionTierBits・ExtractInfo」を送信する。送信回数は

制限しない。 DRM サーバは、更新開始日時オフセットまたは NotAfter の値を受信機ごと

などに異なる値とすることで、更新時の受信機からのアクセスを分散させ

ることができる。 • 受信機

メタファイルから取得した UsageRuleReference・DRM サーバ URI は、以

降の「WorkKey・SubscriptionTierBits・ExtractInfo」の更新時に必要となる

ため、受信機は不揮発性記憶領域に記録しておくことが望ましい。また、

この場合、受信機は新たにメタファイルを取得した場合、当該メタファイ

ルに含まれる DRM サーバ URI の値で、不揮発性記憶領域に記録した DRMサーバ URI の値を更新することが望ましい。

受信機は、同一ServiceProviderID・同一WorkKeyManagementIDの

odd/evenの「WorkKey・SubscriptionTierBits・ExtractInfo」を一対の組とし

て取得する。メタファイルでは、一対の「WorkKey・SubscriptionTierBits・ExtractInfo」に 2対応するつのUsageRuleReference（odd）・

UsageRuleReference（even） 1を組として、組以上の

UsageRuleReference 1 サービスが指定される（事業者が64 ビットからな

る 2ティアビットを複数個用いる運用をおこなう場合などに、組以上の

UsageRuleReference が指定される場合がある）。

受信機は、更新開始日時オフセットの値が 0000h（更新されない）である場合は、

更新をおこなわない。 ② 期限延長受信機は、②の更新期間（2009/4/16～2009/4/30）に、期限延長された一対の

「WorkKey・SubscriptionTierBits・ExtractInfo」を取得する。

(3) DRM サーバからの「WorkKey・SubscriptionTierBits・ExtractInfo」の取得 ••1350

1351 1352 1353

受信機は、不揮発性記憶領域に記録したメタファイルで指定される

UsageRuleReference（odd）を設定した Get Permission Request message を作成して、メタファイルの DRM サーバ URI で指定される

DRM サーバに送信する。 ••1354

1355 1356 1357 1358 1359 1360 1361


NotAfter には、1 年後の月末の日時（2010/4/30）を設定する。引き続き次回に更新をおこなうことを通知するため、更新開始日時

オフセットの値には 14 日（20160 分）を設定する。 WorkKey（odd）には、WorkKey の送信時点で ECM を暗号化する




1365 1366



の DRM サーバ URI で指定される DRM サーバに送信する。


••1367 1368 1369 1370 1371 1372 1373 1374 1375









1379 1380 1381

受信機は、取得した一対の「WorkKey・SubscriptionTierBits・ExtractInfo」で、不揮発性記憶領域に記録した同一

ServiceProviderID・同一 WorkKeyManagementID の一対の

「WorkKey・SubscriptionTierBits・ExtractInfo」を更新する。 ••1382

1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403



間（④の更新期間：2010/4/16～2010/4/30）を算出し、次回更新の制御


DRM サーバは、更新開始日時（上記では 2009/4/16）以降に受信機から

「WorkKey・SubscriptionTierBits・ExtractInfo」の要求を受信した場合、

NotAfter を更新（上記では 2010/4/30）した「WorkKey・SubscriptionTierBits・ExtractInfo」を送信する。

• 受信機メタファイルの DRM サーバ URI が変更される場合を考慮し、受信機は、

期限延長時などにメタファイルを取得し、取得したメタファイルに設定さ

れた DRM サーバ URI の値で、不揮発性記憶領域に記録した DRM サーバ

URI の値を更新することが望ましい。 ③ 契約追加受信機は、2009/9 に事業者サーバに契約の一部追加を申し込む。受信機は一部の契

約が追加された一対の「WorkKey・SubscriptionTierBits・ExtractInfo」を取得する。

(4) 事業者サーバからのメタファイルの取得 ••1404 受信機は、事業者サーバに対して契約の一部追加の要求を送信する。 ••1405

1406 事業者サーバは、受信機からの契約追加の申し込みを受け付け、DRM

サーバに契約内容を送信するなど、契約追加の受け付け処理を完了する。 ••1407

1408 1409

受信機は、事業者サーバからメタファイルを取得し、受信したメタファ

イルで不揮発性記憶領域に記録したメタファイルを更新する。 (5) DRM サーバからの「WorkKey・SubscriptionTierBits・ExtractInfo」の取得

••1410 1411 1412




1414 1415



1416 1417 1418 1419 1420 1421 1422 1423 1424

SubscriptionTierBits には、②で設定した SubscriptionTierBits のう

ち、追加した契約に対応するビットを 1b に変更したビット列を設

定する。 NotAfter には、引き続き②で設定した NotAfter（2010/4/30）と同

一の値を設定する。また、更新開始日時オフセットにも、引き続き

②で設定した更新開始日時オフセット（14 日）と同一の値を設定

する。 WorkKey（odd）には、WorkKey の送信時点で ECM を暗号化する




1428 1429




1431 1432 1433 1434 1435 1436 1437 1438









1442 1443 1444




1446 1447 1448 1449 1450 1451 1452 1453 1454



間（④の更新期間：2010/4/16～2010/4/30）を算出し、次回更新の制御

をおこなう。 ④ 期限延長受信機は、④の更新期間（2010/4/16～2010/4/30）に、期限延長された一対の



1456 1457 1458




1460 1461 1462 1463 1464


NotAfter には、1 年後の月末の日時（2011/4/30）を設定する。引き続き次回に更新をおこなうことを通知するため、更新開始日時

オフセットの値には 14 日（20160 分）を設定する。


1465 1466

WorkKey（odd）には、WorkKey の送信時点で ECM を暗号化する




1470 1471




1473 1474 1475 1476 1477 1478 1479 1480









1484 1485 1486




1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501



間（⑧の更新期間：2011/4/16～2011/4/30）を算出し、次回更新の制御

をおこなう。 ⑤ 契約一部解約申し込み受信機は、2010/8 初旬に事業者サーバに一部の契約の解約を申し込む。DRM サー

バは、解約するチャネルが当月末まで視聴可能となるように、SubscriptionTierBitsは解約前と同一で、期限が来月初めに設定された一対の「WorkKey・SubscriptionTierBits・ExtractInfo」を受信機に送信する。受信機は、当該「WorkKey・SubscriptionTierBits・ExtractInfo」を取得し、NotAfterに基づき、一部の契約が解約された一対の「WorkKey・SubscriptionTierBits・ExtractInfo」を、来月初めに取得するための制御をおこなう。

(7) 事業者サーバからのメタファイルの取得 ••1502 受信機は、事業者サーバに対して契約の一部解約の要求を送信する。 ••1503

1504 1505

事業者サーバは、受信機からの契約一部解約の申し込みを受け付け、

DRM サーバに解約内容を送信するなど、契約一部解約の受付処理を完

了する。 ••1506

1507 1508 1509 1510 1511


イルで不揮発性記憶領域に記録したメタファイルを更新する。

(8) DRM サーバからの「WorkKey・SubscriptionTierBits・ExtractInfo」の取得


••1512 1513 1514




1516 1517 1518 1519 1520 1521 1522 1523 1524


SubscriptionTierBits には、引き続き、③および④で設定した契約

の一部解約前の SubscriptionTierBits を設定する。 2010/9/1 からの一部解約のための更新を指定し、かつ、更新期間

を 3 日間とするため、NotAfter には 2010/9/3、更新開始日時オフセ

ットには 3 日（4320 分）を設定する。 WorkKey（odd）には、WorkKey の送信時点で ECM を暗号化する




1528 1529




1531 1532 1533 1534 1535 1536 1537 1538









1542 1543 1544




1546 1547 1548 1549 1550 1551 1552 1553 1554



間（⑥の更新期間：2010/9/1～2010/9/3）を算出し、次回更新の制御を

おこなう。 ⑥ 契約一部解約受信機は、⑥の更新期間（2010/9/1～2010/9/3）に、一部の契約が解約された一対

の「WorkKey・SubscriptionTierBits・ExtractInfo」を取得する。


1556 1557 1558



DRM サーバに送信する。


••1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570


SubscriptionTierBits には、⑤で設定した SubscriptionTierBits のう

ち、解約した契約に対応するビットを 0b に変更したビット列を設

定する。 NotAfter には、⑧の更新期間での期限延長を継続するため、④の期

限延長で設定した NotAfter（2011/4/30）と同一の値を設定する。

また、更新開始日時オフセットにも、引き続き④で設定した更新開

始日時オフセット（14 日）と同一の値を設定する。 WorkKey（odd）には、WorkKey の送信時点で ECM を暗号化する




1574 1575




1577 1578 1579 1580 1581 1582 1583 1584









1588 1589 1590

受信機は、取得した一対の「WorkKey・SubscriptionTierBits・ExtractInfo」で、不揮発性記憶領域に記録している同一



1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607



間（⑧の更新期間：2011/4/16～2011/4/30）を算出し、次回更新の制御


DRM サーバは、「WorkKey・SubscriptionTierBits・ExtractInfo」の送信に

対して、受信機から以下の SAC 層のメッセージを受信することにより、受

信機での「WorkKey・SubscriptionTierBits・ExtractInfo」の更新を確認でき

る。 Command に「Commit」が設定された Encrypted command message Request message

したがって、DRM サーバは、odd/even の一対の「WorkKey・SubscriptionTierBits・ExtractInfo」の送信に対して、上記メッセージを受信

することにより契約の一部解約処理を完了できる。なお、上記は Get Permission Protocol と Packed Message Protocol とで共通である。


1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631

⑦ ECM を暗号化する WorkKey の更新 DRM サーバは、現在送出中の ECM を暗号化する WorkKey が更新された場合、Get Permission Protocol で受信機に送信する WorkKey を更新する。 DRM サーバは、ECM を暗号化する WorkKey を、WorkKeyVersion が 1 の WorkKey（odd）から WorkKeyVersion が 2 の WorkKey（even）に更新する。以降、DRM サ

ーバは、WorkKeyVersion が 2 の WorkKey（even）と、WorkKeyVersion が 3 の

WorkKey（odd）とを受信機に送信する。 [備考] • DRM サーバは、ECM を暗号化する WorkKey の更新後、Get Permission

Protocol で送信する一対の WorkKey（odd）・WorkKey（even）も速やかに更

新する。 • DRM サーバが WorkKey を更新するタイミングは、サービス事業者の運用依存

とする。 • DRM サーバは、WorkKey 自体を定期的に更新する運用をおこなう場合、ECM

を暗号化する WorkKey の更新前に、全ての受信機が更新後に ECM の暗号化に

用いる WorkKey を取得できるように各受信機の更新期間を設定する。 ⑧ 期限延長受信機は、⑧の更新期間（2011/4/16～2011/4/30）に、期限延長された一対の


(10) DRM サーバからの「WorkKey・SubscriptionTierBits・ExtractInfo」の取得

••1632 1633 1634 1635




1637 1638 1639 1640 1641 1642 1643


NotAfter には、1 年後の月末の日時（2012/4/30）を設定する。引き続き次回に更新することを通知するため、更新開始日時オフセ

ットの値には 14 日（20160 分）を設定する。 WorkKey（odd）には、ECM を暗号化する WorkKey の次回更新後

の WorkKey（WorkKeyVersion が 3）を設定する。 ••1644



1647 1648




1650 1651 1652 1653 1654 1655





セットと同一の値を設定する。


1656 1657

WorkKey（even）には、WorkKey の送信時点で ECM を暗号化す

る WorkKey（WorkKeyVersion が 2）を設定する。 ••1658



1661 1662 1663




1665 1666 1667 1668 1669 1670 1671 1672 1673 1674


ことから、NotAfterと更新開始日時オフセットとを用いて次回の更新期

間（2012/4/16～2012/4/30、図A-5に図示せず）を算出し、次回更新の

制御をおこなう。 ⑨ 全解約受信機は、2011/10 初旬に事業者サーバに当該 WorkKey に関する全契約の解約を申

し込む。受信機は、解約日を期限とした一対の「WorkKey・SubscriptionTierBits・ExtractInfo」を取得する。

(11) 事業者サーバからのメタファイルの取得 ••1675 受信機は、事業者サーバに対して全契約の解約の要求を送信する。 ••1676

1677 事業者サーバは、受信機からの全解約申し込みを受け付け、DRM サー

バに解約内容を送信するなど、全解約の受付処理を完了する。 ••1678

1679 1680 1681


イルで不揮発性記憶領域に記録したメタファイルを更新する。 (12) DRM サーバからの「WorkKey・SubscriptionTierBits・ExtractInfo」の取得

••1682 1683 1684




1686 1687 1688 1689 1690 1691 1692


NotAfter には、解約月の月末の日時（2011/10/31）を設定する。当該受信機の以降の更新を停止するため、更新開始日時オフセット

の値には 0000h を設定する。 WorkKey（odd）には、ECM を暗号化する WorkKey の次回更新後

の WorkKey（WorkKeyVersion が 3）を設定する。 ••1693



1696 1697




1699 1700 1701 1702 1703 1704





セットと同一の値を設定する。


1705 1706

WorkKey（even）には、WorkKey の送信時点で ECM を暗号化す

る WorkKey（WorkKeyVersion が 2）を設定する。 ••1707



1710 1711 1712




1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733

1734

1735 1736 1737

受信機は、更新開始日時オフセットの値が 0000h（更新されない）であ

ることから、次回以降の更新はおこなわない。 [備考] • DRM サーバ

DRM サーバは、「WorkKey・SubscriptionTierBits・ExtractInfo」の送信に

対して、受信機から以下の SAC 層のメッセージを受信することにより、受

信機の「WorkKey・SubscriptionTierBits・ExtractInfo」の更新を確認できる。 Command に「Commit」が設定された Encrypted command message Request message

したがって、DRM サーバは、odd/even の一対の「WorkKey・SubscriptionTierBits・ExtractInfo」の送信に対して、上記メッセージを受信

することにより解約処理を完了できる。なお、上記は Get Permission Protocol と Packed Message Protocol とで共通である。

• 受信機

「WorkKey・SubscriptionTierBits・ExtractInfo」の削除は、受信機の実装依

存とする。ただし、更新開始日時オフセットの値が 0000h（更新されな

い）である場合、NotAfterを経過した「WorkKey・SubscriptionTierBits・ExtractInfo」を削除することが望ましい。このとき、不揮発性記憶領域に

記録した、対応するメタファイルも削除することが望ましい。

A.6 メッセージの例

A.6.1 HTTP のメッセージの例 DRM HTTP SAC本項では受信機とサーバとの通信のヘッダの例をの処理毎に示す。

本項で示す例では、以下を想定している。

1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751

www.iptv.jp DRMサーバのホスト名は Cookie 0000000000000001 は

なお、Cookie を用いない場合は、以降に示す例の Set-Cookie および Cookie は不要

である。受信機から Challenge message を送信する場合

POST / HTTP/1.1 Host: www.iptv.jp Content-type: application/octet-stream Content- Length: 1039

DRM サーバから Response & Challenge message を送信する場合

HTTP/1.1 200 OK Set-Cookie: JSESSIONID=0000000000000001

http://www.iptv.jp/

http://www.iptv./


1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768

1769 1770 1771 1772 1773 1774 1775

1776 1777 1778

Cache-Control: no-cache Content-type: application/octet-stream Content- Length: 1321

受信機から Challenge message 以外のメッセージを送信する場合

POST / HTTP/1.1 Host: www.iptv.jp Cookie: JSESSIONID=0000000000000001 Content-type: application/octet-stream Content- Length: 236

DRM サーバから Response & Challenge message 以外のメッセージを送信する場合

HTTP/1.1 200 OK Cache-Control: no-cache Content-type: application/octet-stream Content- Length: 124

A.6.2 SAC のメッセージの例本項ではSACのメッセージの例を示す。

なお、サイズの大きいパラメータ（SinkCertificate、SourceCertificate など）と演算

により生成するパラメータ（SourceEC-DHPhase1Value、Signature など）は、値

の記述を省略した。また、以下の表中のハッチング部に記載されている値は暗号化

前の値を示す。

A.6.2.1 Challenge message 1001byteのSinkCertificateを格納したChallenge messageの例を表A-5に示す。

表A-5 Challenge message の例

Byte index パラメータ名値：16 進表記 0-3 ProtocolID 49505456（固定値） 4-5 ProtocolVersion 0100（固定値） 6-13 SenderID. 1001000000000000 14-15 PayloadType 0001（固定値） 16-19 PayloadSize 0000034C 20-35 SinkRandomNumber （省略） 36-37 SinkCertificateSize 03E9 38-1038 SinkCertificate （省略）

1779

1780 1781 1782 1783 1784 1785 1786 1787

A.6.2.2 Response & Challenge message 1171byteのSourceCertificateを格納したResponse & Challenge messageの例を表

A-6に示す。

http://www.iptv./


表A-6 Response & Challenge message の例

Byte index パラメータ名値：16 進表記 0-3 ProtocolID 49505456（固定値） 4-5 ProtocolVersion 0100（固定値） 6-13 SenderID 0000000000000000（固定

値） 14-15 PayloadType 0002（固定値） 16-19 PayloadSize 000003BC 20-35 SourceRandomNumber （省略） 36-91 SourceEC-DHPhase1Value （省略） 92-147 Signature （省略） 148-149 SourceCertificateSize 0493 150-1320 SourceCertificate （省略）

1788

1789 1790 1791 1792

A.6.2.3 Response & Request message 表A-7GetPermission Requestを格納したResponse & Request messageの例をに示

す。

表A-7 Response & Request message の例

Byte index パラメータ名値：16 進表記 0-3 ProtocolID 49505456（固定値） 4-5 ProtocolVersion 0100（固定値） 6-13 SenderID 1001000000000000 14-15 PayloadType 0003（固定値） 16-19 PayloadSize 000000D8 20-75 SinkEC-DHPhase1Value （省略） 76-131 Signature （省略） 132-135 EncryptedDataSize 00000064 136-138 SequenceNumber 000001（固定値） 139 TransactionFlag 00（固定値） 140-203 Request A.6.3.1.2項を参照のこと 204-235 MessageDigest （省略）

1793

1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804

A.6.2.4 Request message 複数のRequestを連続送信する場合のGetPermission Requestを格納した最初の

Request messageの例を表A-8に示す。


表A-8 Request message の例

Byte index パラメータ名値：16 進表記 0-3 ProtocolID 49505456（固定値） 4-5 ProtocolVersion 0100（固定値） 6-13 SenderID 1001000000000000 14-15 PayloadType 0004（固定値） 16-19 PayloadSize 00000068 20-23 EncryptedDataSize 00000064 24-26 SequenceNumber 000003 27 TransactionFlag 01 28-91 Request A.6.3.1.2項を参照のこと 92-123 MessageDigest （省略）

1805

1806 1807 1808

A.6.2.5 Reply message 表A-9に示す。 Get Permission Replyを格納したReply messageの例を

表A-9 Reply message の例

Byte index パラメータ名値：16 進表記 0-3 ProtocolID 49505456（固定値） 4-5 ProtocolVersion 0100（固定値） 6-13 SenderID 0000000000000000（固定

値） 14-15 PayloadType 0005（固定値） 16-19 PayloadSize 0000004A 20-23 EncryptedDataSize 00000046 24-26 SequenceNumber 000002 27 TransactionFlagRecordFlag 00 28-61 Reply A.6.3.1.3項を参照のこと 62-93 MessageDigest （省略）

1809

1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824

A.6.2.6 Plain command message StatusとしてError other than the belowを格納したPlain command messageの例を表

A-10に示す。


表A-10 Plain command message の例

Byte index パラメータ名値：16 進表記 0-3 ProtocolID 49505456（固定値） 4-5 ProtocolVersion 0100（固定値） 6-13 SenderID. 0000000000000000（固定

値） 14-15 PayloadType 0006（固定値） 16-19 PayloadSize 00000004（固定値） 20-21 Command 0002（固定値） 22-23 Status 8001

1825

1826 1827 1828 1829 1830

A.6.2.7 Encrypted command message StatusとしてError other than the belowを格納した複数のRequestを連続送信する場

合の最初のRequest messageに対するEncrypted command messageの例を表A-11に示す。

表A-11 Encrypted command message の例

Byte index パラメータ名値：16 進表記 0-3 ProtocolID 49505456（固定値） 4-5 ProtocolVersion 0100（固定値）

6-13 SenderID. 0000000000000000（固定

値） 14-15 PayloadType 0007（固定値） 16-19 PayloadSize 0000002C（固定値） 20-23 EncryptedDataSize 00000028（固定値） 24-26 SequenceNumber 000004 27 TransactionFlag 00 28-29 Command 0002 30-31 Status 8001 32-63 MessageDigest （省略）

1831

1832 1833 1834

1835 1836 1837

1838 1839 1840 1841

A.6.3 Service Protocol のメッセージ例本項では[MIPTV], 4.2 節で規定されるService Protocolのメッセージの例を示す。

A.6.3.1 Get Permission Protocol 本項では、[MIPTV], 4.2.1 項で規定されるGet Permission Protocolのメッセージ例を

示す。

A.6.3.1.1. DeviceInformation [MIPTV], 3.2.2 項で規定されるDeviceInformationの例を表A-12に示す。この情報は

Get Permission Requestメッセージに格納される。


表A-12 DeviceInformation の例

Byte index パラメータ名値：16 進表記 0 Marlin IPTV-ES

SpecificationVersionMajor 01（固定値）

1 Marlin IPTV-ES SpecificationVersionMinor

00（固定値）

2 Capabilities 00 （固定値） 3-4 Manufacturer 1001 5-6 ManufacturerModel 0000（固定値） 7 ManufacturerModelVersion

Major 00（固定値）

8 ManufacturerModelVersionMinor

00（固定値）

9-11 Reserved 000000（固定値） 1842

1843 1844 1845

A.6.3.1.2. Get Permission Request message [MIPTV], 4.2.1.2 項で規定されるGet Permission Request messageの例を、表A-13に示す。


表A-13 Get Permission Request messageの例

バイトパラメータ名値：16 進表記

インデックス 0-1 ProtocolVersion 0100（固定値） 2-3 MessageID 0001（固定値） 4-15 DeviceInformation A.6.3.1.1項参照 16-31 UsageRuleReference 0001000001010000000000

0000000000 32 ActionID 02（固定値） 33 ActionParameter FF（固定値） 34-35 SpecificCRID 0001（固定値） 36 PrivateDataTag 00（固定値） 37-63 PrivateData 全て 00（固定値）

1846

1847 1848 1849 1850

A.6.3.1.3. Get Permission Reply message [MIPTV], 4.2.1.3 項で規定されるGet Permission Reply messageの例を、表A-14に示

す。

表A-14 Get Permission Reply messageの例


インデックス 0-1 ProtocolVersion 0100（固定値） 2-3 MessageID 0002（固定値） 4-5 Status 0000 6-21 WorkKey 00112233445566778899A

ABBCCDDEEFF 22-27 WorkKeyID 000100000101 28-29 PrivateData 4EC0 30-37 SubscriptionTierBits 8000000000000000 38-39 ExtractInfoSize 0A（固定値） 40-43 NotBefore FFFFFFFF 44-47 NotAfter 4B3CCAAF 48-49 RenderingObligation 0000（固定値）

1851

1852 1853 1854 1855

1856 1857 1858 1859 1860

A.6.3.2 Get Trusted Time Protocol 本項では、[MIPTV], 4.2.2 項で規定されるGet Trusted Time Protocolのメッセージ例

を示す。

A.6.3.2.1 Get TrustedTime Request [MIPTV], 4.2.2.2 項で規定されるGet Trusted Time Requestメッセージの例を表A-15に示す。


表A-15 Get Trusted Time Request メッセージの例

Byte index パラメータ名値：16 進表記 0-1 ProtocolVersion 0100（固定値） 2-3 MessageID 0003（固定値）

1861

1862 1863 1864 1865

A.6.3.2.2 Get TrustedTime Reply [MIPTV], 4.2.2.3 で規定されるGet Trusted Time Replyメッセージの例を表A-16に示

す。

表A-16 Get Trusted Time Reply メッセージの例

Byte index パラメータ名値：16 進表記 0-1 ProtocolVersion 0100（固定値） 2-3 MessageID 0004（固定値） 4-5 Status 0000 6-9 Datetime 4B3CCABD

1866

1867 1868 1869 1870

1871 1872 1873 1874

A.6.3.3 Packed Message Protocol 本項では、[MIPTV], 4.2.3 項で規定されるPacked Message Protocolのメッセージ例

を示す。

A.6.3.3.1 Packed Message Request message [MIPTV], 4.2.3.2 項で規定されるPacked Message Requestに格納するリクエストメ

ッセージがA.6.3.1.2 表A-17に示す。項の場合の例を、

表A-17 Packed Message Request messageの例


インデックス 0-1 ProtocolVersion 0100（固定値） 2-3 MessageID 0101（固定値） 4-5 NumberOfRequest

MessageBoxes 0002

6-7 RequestMessageSize 0040 8-71 RequestMessage A.6.3.1.2項参照 72-73 RequestMessageSize 0040 74-137 RequestMessage A.6.3.1.2項参照

1875

1876 1877 1878 1879 1880 1881

A.6.3.3.2 Packed Message Reply message [MIPTV], 4.2.3.3 項で規定されるPacked Message Reply messageで、A.6.3.3.1項に

対して応答する場合の例を、表A-18に示す。


表A-18 Packed Message Reply messageの例


インデックス 0-1 ProtocolVersion 0100（固定値） 2-3 MessageID 0102（固定値） 4-5 Status 0000 6-7 NumberOfReplyMessage

Boxes 0002

8-9 ReplyMessageSize 0032 10-59 ReplyMessage A.6.3.1.3項参照 34-35 ReplyMessageSize 0032 36-85 ReplyMessage A.6.3.1.3項参照

1882

Documents

地上デジタルテレビジョン放送 運用仕様...Marlin IPTV-ES Specific Compliance Rules”, Version 1.1 [RTDBCR]に対する詳細規 定項目と、[MIPTV]に対する追加規定項目を規定する。

地上デジタルテレビジョン放送運用仕様...Marlin IPTV-ES Specific Compliance Rules”, Version 1.1 [RTDBCR]に対する詳細規定項目と、[MIPTV]に対する追加規定項目を規定する。