JP2011524676A - 移動体ブロードキャストシステムにおける暗号化キー分配方法、暗号化キーの分配を受ける方法及びこのためのシステム - Google Patents

Abstract

【課題】
移動体ブロードキャストシステムにおけるサービス保護及びコンテンツ保護のための暗号化キー分配方法、暗号化キーの分配を受ける方法及びこのためのシステムを提供する。
【解決手段】
本発明によると、前記ブロードキャストサービスが端末に提供され始める際、ネットワークが第１の暗号化キーを発生させ、前記発生した第１の暗号化キーを含む長期キーメッセージを前記端末に送信し、前記第１の暗号化キーの寿命が満了する前に、前記ネットワークが第２の暗号化キーを発生させ、前記発生した第２の暗号化キーを含む長期キーメッセージを前記端末に送信する。
【選択図】図５

Description

本発明は、移動体ブロードキャストシステムに関し、より詳細には、オープンモバイルアライアンス（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ：以下、“ＯＭＡ”と称する。）ブロードキャスト（ＢＣＡＳＴ）サービスシステムにおけるサービス保護及びコンテンツ保護アーキテクチャ（スマートカードプロフィール）に適用する移動体ブロードキャストサービスのためのトラフィック暗号化キー分配方法、暗号化キーの分配を受ける方法及びこのためのシステムに関する。

移動通信市場は、既存の技術の再結合又は統合により新たなサービスの生産を求められている。今日、通信及びブロードキャスト技術の発達に伴い、従来のブロードキャストシステム又は移動通信システムは、携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ
Ａｓｓｉｓｔａｎｔｓ）などのような携帯端末機（以下、“端末”と称する。）を介してブロードキャストサービスを提供することができるステップに達した。このような潜在的で実際的な市場需要、マルチメディアサービスに対して急増するユーザの要請、既存の音声サービスに加えてブロードキャストサービスのような新たなサービスを提供するためのサービスプロバイダーの目標戦略、及び需要者の要求によって移動通信事業を強化しているＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）企業の利権という要因を背景として、移動通信サービスとインターネットプロトコル（ＩＰ）技術との融合は、今日、次世代移動通信技術の開発の大きな流れとして位置付けられている。

一方、ＯＭＡは、個々のモバイルソリューション間の相互作用のための標準を研究する団体であって、主として、移動通信用ゲーム、インターネットサービスなどに対する様々なアプリケーション標準を定める役目を担う。特に、ＯＭＡのワーキンググループの内の１つであるＯＭＡ ＢＣＡＳＴワーキンググループ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ Ｂｒｏｗｓｅｒ ａｎｄ Ｃｏｎｔｅｎｔ Ｍｏｂｉｌｅ Ｂｒｏａｄｃａｓｔ Ｓｕｂ−Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ）では、端末を用いてブロードキャストサービスを提供する技術を研究している。

以下、ＯＭＡ ＢＣＡＳＴワーキンググループで論議しているブロードキャストシステム（以下、“移動体ブロードキャストシステム”と称する。）について簡略に説明する。

図１は、従来の移動体ブロードキャストシステムにおけるネットワークの構成を示すブロック図である。

図１を参照すると、コンテンツ供給者（Ｃｏｎｔｅｎｔ Ｃｒｅａｔｉｏｎ：ＣＣ）１０は、ブロードキャストサービス（以下、“ＢＣＡＳＴサービス”と称する。）の供給者であり、ＢＣＡＳＴサービスは、従来の音声／映像ブロードキャストサービス、ファイル（音楽ファイル又はデータファイル）ダウンロードサービスなどになることができる。ＢＣＡＳＴサービスアプリケーション部（Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ：以下、“ＢＳＡ”と称する。）２０は、コンテンツ供給者（ＣＣ）１０からＢＣＡＳＴサービスデータの供給を受け、図１のＢＣＡＳＴネットワークに適した形態に加工し、ＢＣＡＳＴサービスデータを生成し、また、移動体ブロードキャストサービスの案内に必要とされる標準化されたメタデータを生成する。

図１において、ＢＣＡＳＴサービス配布／適応部（Ｓｅｒｖｉｃｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ／Ａｄａｐｔａｔｉｏｎ：以下、“ＢＳＤＡ”と称する。）３０は、ＢＣＡＳＴサービスアプリケーション部（ＢＳＡ）（２０）から供給を受けたＢＣＡＳＴサービスデータを送信するベアラを設定し、ＢＣＡＳＴサービスの送信スケジュールを決定し、移動体ブロードキャスト案内を生成する。ＢＣＡＳＴ加入管理部（ＢＣＡＳＴ Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ：以下、“ＢＳＭ”と称する。）４０は、ＢＣＡＳＴサービスの受信のための加入者の加入情報、ＢＣＡＳＴサービス提供情報、及びＢＣＡＳＴサービスを受信する端末に関する装置情報を管理する。

端末５０は、ＢＣＡＳＴサービスを受信することができる端末機であり、その性能に従って、セルラーネットワークと接続することができる機能を果たし、ここでは、セルラーネットワークと接続されることができる端末機と仮定する。ブロードキャストネットワーク６０は、ＢＣＡＳＴサービスを送信するネットワークであって、例えば、デジタルビデオ放送−ハンドヘルド（ＤＶＢ−Ｈ）、３ＧＰＰのマルチメディアブロードキャストとマルチキャストサービス（ＭＢＭＳ）、及び３ＧＰＰ２のブロードキャストとマルチキャストサービス（ＢＣＭＣＳ）などのためのものになりうる。双方向ネットワーク（Ｉｎｔｅｒａｃｔｉｏｎ Ｎｅｔｗｏｒｋ）７０は、ポイント・ツー・ポイント（ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ）基盤でＢＣＡＳＴサービスを送信するか、又はＢＣＡＳＴサービスの受信に関連した制御情報及び付加情報を双方向に交換するネットワークであって、例えば、既存のセルラーネットワークとなりうる。

一般的に、ＢＣＡＳＴサービスにおいて、複数の端末は、ブロードキャストサービスを管理するサーバが送信した暗号化されたサービスデータを受信する。この際、複数の端末は、各端末内に予め格納されている所定の暗号化キー（ｃｒｙｐｔｏｇｒａｐｈｉｃ ｋｅｙ）を用いてこのサーバから提供される暗号化されたサービスデータを復号化（ｄｅｃｉｐｈｅｒ）することにより、対応するサービスを使用することができる。これと関連してブロードキャストコンテンツ及びサービスを暗号化する方法は、サービス保護（Ｓｅｒｖｉｃｅ Ｐｒｏｔｅｃｔｉｏｎ）及びコンテンツ保護（Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）の２つに大別される。

一方、ＯＭＡ ＢＣＡＳＴ ＳＰＣＰ（Ｓｏｕｒｃｅ Ｐｒｏｄｕｃｔｉｏｎ Ｃｏｎｔｒｏｌ Ｐａｒａｍｅｔｅｒ）スマートカードプロフィールは、移動体ブロードキャストサービスのためのキー管理方式を実現する。アクセスプロビジョニング（ａｃｃｅｓｓ ｐｒｏｖｉｓｉｏｎｉｎｇ）のために２種類のキー、すなわち、長期キー（Ｌｏｎｇ Ｔｅｒｍ Ｋｅｙｓ：以下、“ＬＴＫ”と称する。）及び短期キー（Ｓｈｏｒｔ Ｔｅｒｍ Ｋｅｙｓ：以下、“ＳＴＫ”と称する。）が定義される。ＬＴＫは、ユーザのサービス加入（ｓｕｂｓｃｒｉｐｔｉｏｎ）計画に基づいてＳＴＫをＬＴＫに従って暗号化することによりＳＴＫに対するアクセス条件を設定（ｃｏｎｄｉｔｉｏｎｉｎｇ）するために使用される。ＳＴＫは、トラフィックを実際に暗号化するために使用される。ＬＴＫ及びＳＴＫは、周期的に更新されなければならないが、ＬＴＫの寿命は、ＳＴＫの寿命よりはるかに長い。ＬＴＫは、ＢＳＭ４０によりユーザに提供され、ＳＴＫは、ＢＣＡＳＴサービス配布／適応部（ＢＳＤ／Ａ）３０によりユーザに送信される。このようなキー管理方式は、ＳＴＫが頻繁にアップデートされることに伴って高帯域幅の消費が増加するという問題点がある。

以下では、スマートカードプロフィール内でのキー管理について詳細に説明する。

図２は、従来のスマートカードプロフィール内で定義されたキー階層（ｋｅｙ ｈｉｅｒａｒｃｈｙ）構造を示す図である。

加入者管理キー（Ｓｕｂｓｃｒｉｂｅｒ Ｍａｎａｇｅｍｅｎｔ Ｋｅｙ：以下、“ＳＭＫ”と称する。）１２０は、登録キー１１０を受信するに従うユーザ認証の結果から派生し、長期キーメッセージ（Ｌｏｎｇ Ｔｅｒｍ Ｋｅｙ Ｍｅｓｓａｇｅ：以下、“ＬＴＫＭ”と称する。）を通して伝達されるＬＴＫを保護する。スマートカードプロフィールのＬＴＫは、サービス暗号化キー（Ｓｅｒｖｉｃｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ：以下、“ＳＥＫ”と称する。）１３０とプログラム暗号化キー（Ｐｒｏｇｒａｍ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙｓ：以下、“ＰＥＫ”と称する。）１４０とを含む。このような２つのキーは、相互に異なるサービスアクセスシナリオをサポートするためにそれぞれ異なる寿命を有する。

ＳＥＫ１３０は、サービスに加入したユーザに提供される。すなわち、認証に成功することにより別途の要請がなくてもコンテンツ及び定期的にアップデートされるＳＥＫが持続的にユーザに提供される。このシナリオは、“加入基盤アクセス（ｓｕｂｓｃｒｉｐｔｉｏｎ−ｂａｓｅｄ ａｃｃｅｓｓ）”とも呼ぶ。

ＰＥＫ１４０は、あるサービスに対するアクセスが特定の時間間隔又はサービス単位であるプログラムで限定されたユーザに提供される。次のプログラム又は後続時間間隔（ｃｏｎｓｅｑｕｅｎｔ ｔｉｍｅ ｉｎｔｅｒｖａｌ）に対するアクセス資格を得るために、ユーザは、付加の購入要請を行わなければならない。プログラム又は時間間隔は、１つ又はそれ以上のＰＥＫと関連することがある。このようなシナリオは、“ペイ・パー・ビュー基盤アクセス（Ｐａｙ−Ｐｅｒ−Ｖｉｅｗ（ＰＰＶ）−ｂａｓｅｄ ａｃｃｅｓｓ）”とも呼ぶ。

ＳＴＫであるトラフィック暗号化キー（Ｔｒａｆｆｉｃ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ：以下、“ＴＥＫ”と称する。）１５０は、短期キーメッセージ（Ｓｈｏｒｔ Ｔｅｒｍ Ｋｅｙ Ｍｅｓｓａｇｅ：以下、“ＳＴＫＭ”と称する。）を通して運搬され、ＳＥＫ１３０により暗号化されるか、又はＳＴＫＭを通して運搬され、ＰＥＫ１４０により暗号化される。ＳＴＫＭは、ＳＴＫＭを通して運搬されるＰＥＫ１４０を使用して認証され、ＳＥＫ１３０により暗号化される。ＴＥＫ１５０は、セキュリティ保持のためにかなり頻繁にアップデートされる。

図３は、従来の加入基盤アクセス状況でのＳＥＫ及びＴＥＫの供給フローを示す図である。

加入基盤アクセス状況において、ＳＥＫの寿命（ＳＥＫ ＬＴ）は、ＴＥＫの寿命のｎ倍に計算される。ＳＥＫ（ＳＥＫ_ｙ−１）が満了する前に、ＢＳＭは、新たなＳＥＫ_ｙを発生させることによりこれをＬＴＫＭ内の加入ユーザ（ｓｕｂｓｃｒｉｂｅｄ ｕｓｅｒ）に送信する（２１０）。ＳＥＫ_ｙは、ユーザとＢＳＭとの間だけで共有されるＳＭＫ_１により暗号化される。ＳＥＫ_ｙ−１が満了した後に、ＳＴＫＭを介してＴＥＫ_ｘ＋１、ＴＥＫ_ｘ＋２、…、ＴＥＫ_ｘ＋ｎとともに運搬されるＰＥＫは、ＳＥＫ_ｙで暗号化される。また、ＳＥＫ_ｙが満了する前に、ＢＳＭは、新たなＳＥＫ_ｙ＋１を発生させることによりこれを加入ユーザに送信する（２２０）。

図４は、従来のＰＰＶ基盤アクセス状況でのＳＥＫ及びＴＥＫの供給フローを示す図である。

ＰＰＶ基盤アクセス状況において、ＰＥＫの寿命（ＰＥＫ ＬＴ）は、ＴＥＫの寿命のｍ倍に計算され、ｍ≦ｎである。また、本例において、ＰＥＫ ＬＴ＝０．５＊＝ＳＥＫ
ＬＴである。したがって、ＰＥＫは、ＳＥＫより２倍だけ頻繁にアップデートされなければならない。

ユーザがＰＥＫ_ｚ及びＰＥＫ_ｚ＋１と関連した２つの後続時間間隔に対して２つの購入要請を発行すると、ＢＳＭは、ＴＥＫ_ｘ＋１（ＰＥＫ_ｚと関連した１番目のＴＥＫ）が使用される前に、ＰＥＫ_ｚを含むＬＴＫＭをユーザに送信する（３１０）。ＰＥＫ_ｚは、ユーザとＢＳＭとの間だけで共有されるＳＭＫ_２により暗号化される。また、ＢＳＭは、ＴＥＫ_{ｘ＋ｎ＋１}（ＰＥＫ_ｚ＋１と関連した１番目のＴＥＫ）が使用される前に、ＰＥＫ_ｚ＋１を含むＬＴＫＭをユーザに送信する（３２０）。しかしながら、ＴＥＫ_{ｘ＋ｎ＋１}が使用される前にユーザによりこれ以上購入要請が発行されないと、ＢＳＭがＴＥＫ_{ｘ＋ｎ＋１}のためのＰＥＫをユーザに送信しないため、ユーザは、ＴＥＫ_{ｘ＋ｎ＋１}から開始されるＴＥＫを解読することができないという問題点があった。

そこで、本発明は上記従来の問題点に鑑みてなされたものであって、本発明の目的は、移動体ブロードキャストシステムにおける暗号化キーの分配方法、暗号化キーの分配を受ける方法及びこのためのシステムを提供することにある。

上記のような目的を達成するために、本発明の一態様によれば、移動体ブロードキャストシステムにおける端末にブロードキャストされるブロードキャストサービスの保護のための暗号化キー分配方法が提供される。前記方法は、前記ブロードキャストサービスが前記端末に提供され始める際、ネットワークが第１の暗号化キーを発生させ、前記発生した第１の暗号化キーを含む長期キーメッセージを前記端末に送信するステップと、前記第１の暗号化キーの寿命が満了する前に、前記ネットワークが第２の暗号化キーを発生させ、前記発生した第２の暗号化キーを含む長期キーメッセージを前記端末に送信するステップとを有する。

本発明の他の態様によれば、移動体ブロードキャストシステムにおける端末がブロードキャストサービスの保護のための暗号化キーの分配を受ける方法が提供される。前記方法は、長期キーメッセージをネットワークから受信する場合、加入者管理キーを用いて前記長期キーメッセージを検証するステップと、前記長期キーメッセージが有効である場合、リプレー検出を実行するステップと、前記リプレー検出に成功した場合、セキュリティ関数を用いて前記長期キーメッセージに含まれた暗号化キーの有効性を確認するステップと、前記暗号化キーが有効である場合、前記暗号化キーを解読し、前記暗号化キーからトラフィック暗号化キーを発生させ、これを格納するステップとを有する。

本発明のさらに他の態様によれば、ブロードキャストサービスを保護する移動体ブロードキャストシステムが提供される。前記システムは、前記ブロードキャストサービスを提供する際、第１の暗号化キーを発生させ、前記発生した第１の暗号化キーを含む長期キーメッセージを送信し、前記第１の暗号化キーの寿命が満了する前に第２の暗号化キーを発生させ、前記発生した第２の暗号化キーを含む長期キーメッセージを送信するネットワークと、前記ネットワークから受信した長期キーメッセージを検証し、セキュリティ関数を用いて前記長期キーメッセージに含まれた暗号化キーを解読し、前記暗号化キーからトラフィック暗号化キーを発生させ、これを格納する端末とを有する。

本明細書中に開示されている発明のうち代表的なものにより得られる効果を簡略に説明すると、下記の通りである。

本発明は、ＴＥＫ（トラフィック暗号化キー）を含むＳＴＫＭ（短期キーメッセージ）をユーザに送信せず、ＢＳＭ（ブロードキャストサービス管理部）がＡＶＰ（アクセス値対）を含むＬＴＫＭ（長期キーメッセージ）を送信することによりユーザがＴＥＫ（トラフィック暗号化キー）を取得することができるようにする効果を有する。

従来の移動体ブロードキャストシステムにおけるネットワークの構成を示すブロック図である。 従来のスマートカードプロフィールのキー階層構造を示すブロック図である。 従来の加入ユーザへのＰＥＫ／ＴＥＫ（プログラム暗号化キー／トラフィック暗号化キー）の提供を示すフローチャートである。 従来のＰＰＶ（ペイ・パー・ビュー）ユーザへのＰＥＫ／ＴＥＫ（プログラム暗号化キー／トラフィック暗号化キー）の提供を示すフローチャートである。 本発明の実施形態によるキー階層構造を示すブロック図である。 本発明の実施形態による加入ユーザへのＡＶＰ（アクセス値対）の提供を示すフローチャートである。 本発明の実施形態によるＰＰＶユーザへのＡＶＰ（アクセス値対）の提供を示すフローチャートである。 本発明の実施形態による上位レベルＬＴＫＭ（長期キーメッセージ）の構成を示すブロック図である。 本発明の実施形態による端末におけるＬＴＫＭ（長期キーメッセージ）処理を示すブロック図である。 本発明の実施形態によるセキュリティ機能によるＴＥＫ（トラフィック暗号化キー）要請処理を示すフローチャートである。

以下、本発明の好ましい実施形態を、添付の図面を参照しつつ詳細に説明する。図面中、同一の構成要素には、可能な限り同一の符号及び番号を共通使用するものとする。また、下記の説明における具体的な特定事項は、本発明のより全般的な理解を助けるために提供しただけであって、このような特定事項なしでも本発明が実施できることは、当該技術分野における通常の知識を有する者には自明である。なお、本発明の下記の説明において、明瞭性及び簡潔性の観点から、本発明に関連した公知の機能や構成に関する具体的な説明が本発明の要旨を不明瞭にすると判断される場合には、その詳細な説明を省略する。

本発明は、サービスアクセスシナリオを変更なしに保持し、ＳＥＫ及びＰＥＫをアクセス値対（Ａｃｃｅｓｓ Ｖａｌｕｅ Ｐａｉｒ：以下、“ＡＶＰ”と称する。）に置き換える。ＡＶＰは、ＢＳＭで任意に発生するキーシード対（Ｋｅｙ Ｓｅｅｄ Ｐａｉｒ：以下、“ＫＳＰ”と称する。）と呼ばれる任意の値の対を用いて計算される。ＡＶＰは、複数のＴＥＫを派生させるのに使用される。これを通して、本発明においては、キー階層構造がアップデートされ、ＴＥＫを識別する方法が変更され、ＳＴＫＭが除去される。したがって、これ以上ＴＥＫを送信する必要がない。また、ＬＴＫＭフォーマットは、ＴＥＫ識別子（ＩＤ）、アクセス基準、及び前にＳＴＫＭを介して運搬されたコンテンツにリンクされた属性及びＡＶＰを含むように修正される。また、本発明によると、端末がスマートカードによりＬＴＫＭを処理するか、又はスマートカードで新たなＴＥＫ要請メッセージを送信する。

図５は、本発明の実施形態によるキー階層構造を示す図である。

ＳＭＫ４２０は、従来と同様に、複数の登録キー４１０から派生して使用されるが、ＳＥＫ及びＰＥＫは、ＡＶＰ４４０に置き換えられる。ＳＥＫに代えるＡＶＰ４４０は、サービスＡＶＰ（ＳＡＶＰ）とし、ＰＥＫに代えるＡＶＰ４４０は、プログラムＡＶＰ（ＰＡＶＰ）と呼ぶ。

また、ＫＳＰ４３０は、｛ＫＳ_１，ＫＳ_２｝でなされる対であり、ＫＳ_１及びＫＳ_２は、ＢＳＭで任意に発生すると仮定する時、ＫＳＰ４３０から発生可能な複数のＴＥＫ４５０の総数をｎとする場合、ＡＶＰ４４０は、次のように２通りの方式で計算することができる。

１． ユーザがｎ個のＴＥＫを発生するように許可を受ける場合：
ＡＶＰ＝ＫＳＰ＝｛ＫＳ_１，ＫＳ_２｝
２． ユーザがｍ個のＴＥＫを発生するように許可を受ける場合（ｍ＜ｎ）：
１） ハッシュ（ｈａｓｈ）関数をＫＳ_１にｎ回適用し、ハッシュ値｛Ｓ_ｉ｝のシーケンスを記憶する。
Ｓ_１＝ｈａｓｈ（ＫＳ_１）、Ｓ_２＝ｈａｓｈ（Ｓ_１），．．．，Ｓ_ｎ−１＝ｈａｓｈ（Ｓ_ｎ−２），Ｓ_ｎ＝ｈａｓｈ（Ｓ_ｎ−１）
上記のようなハッシュシーケンスをフォワードハッシュシーケンス（ｆｏｒｗａｒｄ ｈａｓｈ ｓｅｑｕｅｎｃｅ）と呼ぶ。
２） ハッシュ関数をＫＳ_２にｎ回適用し、最後のハッシュ値から開始するハッシュ値｛Ｍ_ｉ｝のシーケンスを記憶する。
Ｍ_１＝ｈａｓｈ（Ｍ_２），Ｍ_２＝ｈａｓｈ（Ｍ_３），．．．，Ｍ_ｎ−１＝ｈａｓｈ（Ｍ_ｎ），Ｍ_ｎ＝ｈａｓｈ（ ＫＳ_２）
すなわち、Ｍ_１は、ＫＳ_２のｎ回目のハッシュ値であり、Ｍ_２は、ＫＳ_２の（ｎ−１）回目のハッシュ値である。このようなハッシュシーケンスをバックワードハッシュシーケンス（ｂａｃｋｗａｒｄ ｈａｓｈ ｓｅｑｕｅｎｃｅ）と呼ぶ。
３） ＡＶＰ＝｛Ｓ_ｉ，Ｍ_ｊ｝

ここで、ｉは、ｎ個のＴＥＫのシーケンスの中でユーザが使用可能な１番目のＴＥＫのインデックス（シーケンス番号）を示し、ｊは、ｎ個のＴＥＫのシーケンスの中で、ユーザが使用可能な最後のＴＥＫのインデックス（シーケンス番号）を示す。

一方、キー材料（ｍａｔｅｒｉａｌｓ）をマッピングする際、ＳＥＫは、単一のＳＡＶＰ＝ＫＳＰにマッピングされるか（すなわち、ＫＳＰ ＬＴ＝ＳＥＫ ＬＴ；ｎ個のＴＥＫは、ＫＳＰから得られる）、又は複数のＳＡＶＰ（ＳＡＶＰ_１＝ＫＳＰ_１、ＳＡＶＰ_２＝ＫＳＰ_２、．．．）にマッピングされる。また、ＰＥＫは、関連するＳＡＶＰから派生した単一のＰＡＶＰにマッピングされるか、又はそれぞれ関連するＳＡＶＰから派生した複数のＰＡＶＰにマッピングされる。

また、ＢＳＭにおいて、ｎ個のＴＥＫを次のようにフォワード及びバックワードハッシュシーケンスから発生させることができる。
ＴＥＫ_ｉ＝Ｓ_ｉ ＸＯＲ Ｍ_ｊ

ここで、ＸＯＲは、ビット単位（ｂｉｔｗｉｓｅ）の排他的ＯＲ演算である。

また、端末において、ｍ個のＴＥＫは、すべてのｘに対してｍ個のＳ_ｉ＋ｘ値を計算し、期間［１，ｍ］から得られた値又はすべてのｘに対してｍ個のＭ_ｊ−ｘ値を計算し、期間［１，ｍ］から得られた値又はすべてのｘに対してＴＥＫ_ｘ＝Ｓ_ｘ ＸＯＲ Ｍ_ｘを計算し、期間［ｉ，ｉ＋ｍ］から得られた値でなされたＡＶＰ＝｛Ｓ_ｉ，Ｍ_ｊ｝から得られる。

一方、一般的に、様々なセキュリティプロトコルに対する要請を満足させるためには、ＴＥＫ派生のために相互に異なる類型のハッシュ関数を使用することができ、ハッシュ関数の出力値は、切り捨てられる（ｔｒｕｎｃａｔｅｄ）こともある。

図６及び図７は、本発明の実施形態によるキー分配の例を示す図である。図６及び図７における条件は、図３及び図４と同様である。

図６は、本発明の実施形態による加入基盤アクセス状況でのＳＡＶＰ提供フローを示す図である。

本発明の実施形態による加入基盤アクセス状況において、ＳＡＶＰの寿命は、ＴＥＫの寿命のｎ倍に計算される。すなわち、ｎ個のＴＥＫがＳＡＶＰから発生することができる。サービスの提供が開始される際、ＢＳＭは、新たなＳＡＶＰ_１を発生させ、これをＬＴＫＭを介して加入ユーザに送信する（５１０）。ＳＡＶＰ_１は、ユーザとＢＳＭとの間だけで共有されるＳＭＫ_１により暗号化される。また。ＢＳＭは、ＳＡＶＰ_１が満了する前に新たなＳＡＶＰ_２を発生させ、これをＬＴＫＭを介してユーザに送信する（５２０）。ＳＡＶＰ_２もユーザとＢＳＭとの間だけで共有されるＳＭＫ_１により暗号化される。

図７は、本発明の実施形態によるＰＰＶ基盤アクセス状況でのＰＡＶＰ提供フローを示す図である。

本発明の実施形態によるＰＰＶ基盤アクセス状況において、ＰＡＶＰの寿命（ＰＡＶＰ ＬＴ）は、ＴＥＫの寿命のｍ倍に計算され、ｍ≦ｎである。図６では、ＳＡＶＰ_１から派生した２個のＰＡＶＰ（ＰＡＶＰ_１、ＰＡＶＰ_２）を例を挙げたが、さらに多くのＰＡＶＰがあり得る。ユーザは、これらの各々に対して個別の購入要請を発行しなければならない。ユーザがコンテンツに対するアクセスを開始する前に１番目の購入を行う場合に、ＢＳＭは、ＬＴＫＭを介してＰＡＶＰ_１をユーザに送信する（６１０）。また、ＰＡＶＰ_１が満了する前に、ユーザは、２番目の購入要請を発行し、購入に成功すると、ＢＳＭは、ＬＴＫＭを介してＰＡＶＰ_２をユーザに送信する（６２０）。ＰＡＶＰ_２が満了する前に、ユーザがこれ以上の購入要請を発行しない場合、ＢＳＭもＰＡＶＰをユーザに送信しないため、ユーザは、これ以上のコンテンツにアクセスすることができない。

次いで、本発明の実施形態によるキー識別方法について説明する。

表１は、本発明の実施形態によるキー識別子及びスマートカードプロフィールのキー識別子のマッピング関係を示す。

以下では、本発明の実施形態によるＬＴＫＭフォーマットについて説明する。

本発明の実施形態において、ＳＡＶＰ及びＰＡＶＰがそれぞれＳＥＫ及びＰＥＫに置き換えられるので、これらは、ＬＴＫＭを介して運搬されなければならない。他方、ＴＥＫを送信するＳＴＫＭは、ＳＴＫＭの管理データを除いてはこれ以上必要としない。ＳＴＫＭの管理データは、アクセス基準情報及び暗号化されたコンテンツにリンクされた属性を含む。ＳＴＫＭの管理データがＬＴＫＭにコピーされる場合、ＳＴＫＭを除去することがきる。

図８は、本発明の実施形態による上位レベルのＬＴＫＭフォーマットを示す図である。

本発明の実施形態によるＬＴＫＭは、マルチメディアインターネットキーイング（Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｎｅｔ ＫＥＹｉｎｇ：以下、“ＭＩＫＥＹ”と称する。）プロトコル（ＲＦＣ３８３０）を通して送信され、ＭＩＫＥＹ規則により形成される。メッセージの構成は、スマートカードプロフィールのメッセージの構成と比較する際に同一であるが、一部のフィールドのコンテンツが修正される。本発明の実施形態においては、管理データ（｛ＥＸＴ ＢＣＡＳＴ｝）を含むＬＴＫＭだけが考慮され、管理データを含まないＬＴＫＭは、現在のスマートカードプロフィールに記述されている通りに構成されることにより処理される。

スマートカードプロフィールと比較する際に修正されないフィールドは、次の通りである。

共通ヘッダー７１０：ＭＩＫＥＹメッセージヘッダー
− ＴＳ７４０：リプレーアタック（ｒｅｐｌａｙ ａｔｔａｃｋ）を検出するために使用されるカウンタ
− ＭＩＫＥＹ ＲＡＮＤ７５０：リプレー保護、キー符号化、及びキー生成のために使用される任意の値
− ＩＤｉ７６０：端末とＢＳＭとの間のセキュリティ関係の識別子
− ＩＤｒ７７０：ＢＳＭ識別子
− ｛ＳＰ｝７８０：ＳＲＴＰ（Ｓｅｃｕｒｅ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ）符号化プロトコル特定パラメータ

また、変更が要求されるパラメータは、次の通りである。
− ＥＸＴ ＭＢＭＳ７２０：キードメインＩＤとキータイプＩＤとを含み、キードメインＩＤサブペイロードは、従来と同様であり、キータイプＩＤサブペイロードにおいて、ＳＥＫ／ＰＥＫ ＩＤは、ＫＳＰ ＩＤに置き換えられる。
− ｛ＥＸＴ ＢＣＡＳＴ｝７３０：ＬＴＫＭ管理データであって、変更されたフォーマットは、以下の表２に従う。
− ＫＥＭＡＣ７９０：キーイング及びメッセージ認証材料であって、ＳＥＫ／ＰＥＫは、１つ又はそれ以上のＡＶＰに置き換えられる（例えば、ソルト値（ｓａｌｔ ｖａｌｕｅ）がセキュリティプロトコルにより要請される場合）。ＳＥＫ／ＰＥＫ有効性のＴＳ_ＬＯＷ及びＴＳ_ＨＩＧＨは、ＡＶＰから派生することができるＴＥＫの個数で測定されたＡＶＰ有効性のＴＥＫ ＩＤ_ＬＯＷ及びＴＥＫ ＩＤ_ＨＩＧＨに置き換えられ、ＴＥＫ ＩＤ_ＬＯＷ及びＴＥＫ ＩＤ_ＨＩＧＨは、ＡＶＰ有効性データ（ＶＬ）と呼ぶ。

次いで、本発明の実施形態によるＬＴＫＭ管理データについて説明する。

以下の表２は、本発明の実施形態によるスマートカードプロフィールＬＴＫＭ管理データフォーマットを示す。

上記の表２において、ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎ、ｓｅｃｕｒｉｔｙ＿ｐｏｌｉｃｙ＿ｅｘｔ＿ｆｌａｇ、ｃｏｎｓｕｍｐｔｉｏｎ＿ｒｅｐｏｒｔｉｎｇ＿ｆｌａｇ、ａｃｃｅｓｓ＿ｃｒｉｔｅｒｉａ＿ｆｌａｇ、ｔｅｒｍｉｎａｌ＿ｂｉｎｄｉｎｇ＿ｆｌａｇは、レガシーＬＴＫＭフォーマットから相続し（ｉｎｈｅｒｉｔｅｄ）、これらのフラグは、スマートカードプロフィールに記述されたように変更なしに使用される。この中で、ｓｅｃｕｒｉｔｙ＿ｐｏｌｉｃｙ＿ｅｘｔ＿ｆｌａｇフィールドは、セキュリティポリシー拡張子（ｓｅｃｕｒｉｔｙ ｐｏｌｉｃｙ ｅｘｔｅｎｓｉｏｎ）が存在するか否かを示し、一般的に、セキュリティポリシー拡張子は、コンテンツ消費に対する料金がユーザにどのように請求されるかを定義する。また、このフラグの中のいずれか１つがＬＴＫ＿ＦＬＡＧ＿ＴＲＵＥに設定される場合には、ＬＴＫＭに属するフィールドは、スマートカードプロフィールと同様に使用する。

元来のＬＴＫＭは、アクセス基準ディスクリプタ（ａｃｃｅｓｓ ｃｒｉｔｅｒｉａ ｄｅｓｃｒｉｐｔｏｒ）と呼ばれるコンテンツアクセス規則を含む。しかし、特定のアクセス基準が１つ又はそれ以上の関連ＴＥＫで暗号化された１つのコンテンツに対して定義された場合、これらは、ＳＴＫＭに記述したように個別に詳述（ｓｐｅｃｉｆｉｅｄ）しなければならない。このために、次の新たなフィールドがメッセージに含まれる。
− ｔｒａｆｆｉｃ＿ｋｅｙ＿ｄｅｓｃｒｉｐｔｏｒ＿ｆｌａｇ：トラフィックキー使用ディスクリプタがＬＴＫＭに属するか否かを示す。
− ｎｕｍｂｅｒ＿ｏｆ＿ｔｒａｆｆｉｃ＿ｋｅｙ＿ｄｅｓｃｒｉｐｔｏｒｓ：トラフィックキー使用ディスクリプタの数を示す。
− ｔｒａｆｆｉｃ＿ｋｅｙ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐ（ ）：アクセス基準及び１つ又はそれ以上のＴＥＫと関連したパラメータを含むトラフィックキーディスクリプタを定義する。
− ｔｒａｆｆｉｃ＿ｋｅｙ＿ｉｄｅｎｔｉｆｉｅｒ＿ｌｏｗ：トラフィックキーディスクリプタが適用されるＴＥＫシーケンスの中で１番目のＴＥＫを示すＴＥＫシーケンス番号を意味する。この際、ＴＥＫは、これらのシーケンス番号に従って順次に１つずつ使用されると仮定する。
− ｔｒａｆｆｉｃ＿ｋｅｙ＿ｉｄｅｎｔｉｆｉｅｒ＿ｈｉｇｈ：トラフィックキーディスクリプタが適用されるＴＥＫシーケンスの中で最後のＴＥＫを示すＴＥＫシーケンス番号を意味する。

次のフィールドは、変更なしに短期キーメッセージ（ＳＴＫＭ）に含まれる。
− ｐｒｏｔｅｃｔｉｏｎ＿ａｆｔｅｒ＿ｒｅｃｅｐｔｉｏｎ
− ａｃｃｅｓｓ＿ｃｒｉｔｅｒｉａ＿ｆｌａｇ
− ｔｒａｆｆｉｃ＿ｐｒｏｔｅｃｔｉｏｎ＿ｐｒｏｔｏｃｏｌ
− ｔｒａｆｆｉｃ＿ｋｅｙ＿ｌｉｆｅｔｉｍｅ
− ｔｒａｆｆｉｃ＿ａｕｔｈｅｎｔｉｃａｔｉｏｎ＿ｔａｇ
− ｒｅｓｅｒｖｅｄ＿ｆｏｒ＿ｆｕｔｕｒｅ＿ｕｓｅ
− ｎｕｍｂｅｒ＿ｏｆ＿ａｃｃｅｓｓ＿ｃｒｉｔｅｒｉａ＿ｄｅｓｃｒｉｐｔｏｒｓ
− ａｃｃｅｓｓ＿ｃｒｉｔｅｒｉａ＿ｄｅｓｃｒｉｐｔｏｒ

次いで、ユーザ側でのＬＴＫＭ処理工程について説明する。

ＬＴＫＭは、スマートカード又は端末に位置したセキュリティ関数（ｓｅｃｕｒｉｔｙ ｆｕｎｃｔｉｏｎ）により処理される。

図９は、本発明の実施形態による端末におけるＬＴＫＭ処理手順を示す図である。

端末は、ステップ８０１で、ＬＴＫＭを受信すると、ステップ８０２で、ＳＭＫを使用してメッセージ検証（ｖａｌｉｄａｔｉｏｎ）を実行した後に、ステップ８０３で、このメッセージが有効であるか否かを確認する。

このメッセージが有効である場合、端末は、ステップ８０４で、ＬＴＫＭリプレー検出手順を実行した後に、ステップ８０５で検出したリプレーが有効であるか否かを判定する。

このリプレーが有効である場合、端末は、ＬＴＫＭをセキュリティ関数で送信し、このセキュリティ関数は、ステップ８０６でＡＶＰデータが有効であるか否か、すなわち、ＴＥＫ ＩＤ_ＬＯＷがＴＥＫ ＩＤ_ＨＩＧＨより小さいか否かを確認する。ＡＶＰデータが有効でない場合、端末は、ステップ８１５で、ＫＳＰ ＩＤ、すなわち、ＳＡＶＰ／ＰＡＶＰ、ＴＥＫ、及び記憶されたポリシー拡張子などに関連した全コンテキストを除去し、ＬＴＫＭ処理を終了する。

他方、ＡＶＰデータが有効である場合、セキュリティ関数は、ステップ８０８で、ｓｅｃｕｒｉｔｙ＿ｐｏｌｉｃｙ＿ｅｘｔ＿ｆｌａｇ＝ＬＴＫ＿ＦＬＡＧ＿ＴＲＵＥである場合のｓｅｃｕｒｉｔｙ＿ｐｏｌｉｃｙ＿ｅｘｔｅｎｓｉｏｎの値に基づいてＬＴＫＭを処理する。ＳＥＫ／ＰＥＫ有効性の“ＴＳハイ（ｈｉｇｈ）”及びＳＴＫＭで使用するＴＳによるセキュリティポリシー拡張子は、ＴＥＫ ＩＤ_ＨＩＧＨと現在使用されているＴＥＫのＴＥＫ ＩＤを使用する。一般的に、ＬＴＫＭは、タイムスタンプの代りにＴＥＫ ＩＤに基づいて処理される。

ａｃｃｅｓｓ＿ｃｒｉｔｅｒｉａ＿ｆｌａｇ＝ＬＴＫ＿ＦＬＡＧ＿ＴＲＵＥである場合、セキュリティ関数は、ステップ８０９で、アクセス制御ディスクリプタを処理する。また、関連フラグがＬＴＫ＿ＦＬＡＧ＿ＴＲＵＥに設定される場合、このセキュリティ関数は、ステップ８１０で消費報告を実行し、ｔｒａｆｆｉｃ＿ｋｅｙ＿ｄｅｓｃｒｉｐｔｏｒ＿ｆｌａｇ＝ＬＴＫ＿ＦＬＡＧ＿ＴＲＵＥである場合、ステップ８１１で、トラフィックキーディスクリプタを処理する。

すなわち、各トラフィックキーディスクリプタについて、セキュリティ関数は、ｔｒａｆｆｉｃ＿ｋｅｙ＿ｉｄｅｎｔｉｆｉｅｒ＿ｌｏｗ及びｔｒａｆｆｉｃ＿ｋｅｙ＿ｉｄｅｎｔｉｆｉｅｒ＿ｈｉｇｈを確認することにより、現在のトラフィックキーディスクリプタが適用されるＴＥＫシーケンスを識別し、アクセス基準及びコンテンツ属性を処理し、これらを関連するＴＥＫ ＩＤとともに記憶する。

このセキュリティ関数は、ステップ８１２で、ＳＡＶＰ／ＰＡＶＰを解読し、ステップ８１３でＴＥＫを派生させ、ステップ８１４で、該派生したＴＥＫを前のステップで処理した属性とともに記憶する。また、セキュリティ関数は、端末の要請に応じて必要なＴＥＫを派生させる場合もある。

次いで、端末によるＴＥＫ要請手順について説明する。

端末は、コンテンツ解読のために新たなＴＥＫが必要である度にセキュリティ関数でＴＥＫを要請しなければならない。スマートカードプロフィールに定義されているように、一般的に、セキュリティ関数は、端末のＳＴＫＭに応じてＴＥＫを端末に提供する。しかしながら、本発明の実施形態では、ＳＴＫＭがこれ以上使用されないので、ＴＥＫを要請するための新たなメッセージが定義されなければならない。本発明では、このようなメッセージを“ＴＥＫ要請”メッセージと呼ぶ。

ＴＥＫ要請メッセージは、キードメインＩＤ、ＫＳＰ ＩＤ及びＴＥＫ ＩＤを含む。また、要請に応じてパラメータが含まれることもある。例えば、ＴＥＫ要請メッセージが端末にバインディングされる場合、端末バインディングキー（Ｔｅｒｍｉｎａｌ Ｂｉｎｄｉｎｇ Ｋｅｙ：以下、“ＴＢＫ”と称する。）識別子及びメッセージ認証コードが含まれることもある。

図１０は、本発明の実施形態によるセキュリティ関数がＴＥＫ要請を端末から受信した場合のフローを示す図である。

ステップ９０１で、セキュリティ関数がＴＥＫ要請を端末から受信する場合、ステップ９０２で、セキュリティ関数は、キードメインＩＤ、ＫＳＰ ＩＤ、及びＴＥＫ ＩＤに基づいて関連するＴＥＫを検索（又は発生）する。ステップ９０３で、ＴＥＫ検索に成功した場合に、セキュリティ関数は、ステップ９０４に進み、スマートカードプロフィールでアクセス基準処理について定義されたものと同様にＴＥＫに関連したアクセス基準を処理する。例えば、ＳＡＶＰ／ＰＡＶＰ関連アクセス基準及びＴＥＫ特定アクセス基準が提供される場合、これらを比較し、ＰＩＮ検証が要請されると、これを実行する。また、ＴＥＫ検索に失敗すると、セキュリティ関数は、ステップ９０９で、失敗指示子（ｆａｉｌｕｒｅ ｉｎｄｉｃａｔｉｏｎ）を端末に送信し、ＴＥＫを提供しない。

アクセス基準を処理した後に、ステップ９０５で、アクセス基準処理に成功したか否かを確認し、アクセス基準処理に成功した場合、ステップ９０６で、セキュリティ関数は、対応するＳＡＶＰ／ＰＡＶＰと関連したセキュリティポリシー拡張子に基づいて要請を処理する（スマートカードプロフィールのＳＴＫＭ処理を参照）。他方、アクセス基準処理に失敗した場合、ステップ９０９で、失敗指示子を端末に送信し、ＴＥＫを提供しない。

このセキュリティポリシー拡張子を処理した後に、ステップ９０７で、セキュリティポリシー拡張子の処理に成功したか否かを確認し、セキュリティポリシー拡張子の処理に成功した場合には、ステップ９０８で、ＴＥＫを端末に送信し、他方、セキュリティポリシー拡張子の処理に失敗した場合には、ステップ９０９で、失敗指示子を端末に送信し、ＴＥＫを提供しない。

１０ コンテンツ供給者（ＣＣ）
２０ ＢＣＡＳＴサービスアプリケーション部（ＢＳＡ）
３０ ＢＣＡＳＴサービス配布／適応部（ＢＳＤＡ）
４０ ＢＣＡＳＴ加入管理部（ＢＳＭ）
５０ 端末
６０ ブロードキャストネットワーク
７０ 双方向ネットワーク
１１０ 登録キー
１２０ 加入者管理キー（ＳＭＫ）
１３０ サービス暗号化キー（ＳＥＫ）
１４０ プログラム暗号化キー（ＰＥＫ）
１５０ トラフィック暗号化キー（ＴＥＫ）
４１０ 複数の登録キー
４２０ 加入者管理キー（ＳＭＫ）
４３０ キーシード対（ＫＳＰ）
４４０ アクセス値対（ＡＶＰ）
４５０ トラフィック暗号化キー（ＴＥＫ）

Claims (17)

1. 移動体ブロードキャストシステムにおける端末にブロードキャストされるブロードキャストサービスの保護のための暗号化キー分配方法であって、
   前記ブロードキャストサービスが前記端末に提供され始める際、ネットワークが第１の暗号化キーを発生させ、前記発生した第１の暗号化キーを含む長期キーメッセージを前記端末に送信するステップと、
   前記第１の暗号化キーの寿命が満了する前に、前記ネットワークが第２の暗号化キーを発生させ、前記発生した第２の暗号化キーを含む長期キーメッセージを前記端末に送信するステップと
   を有することをことを特徴とする暗号化キー分配方法。
2. 前記第１の暗号化キーの寿命及び前記第２の暗号化キーの寿命は、前記第１の暗号化キー及び前記第２の暗号化キーから派生するトラフィック暗号化キーの寿命の整数倍であることを特徴とする請求項１に記載の暗号化キー分配方法。
3. 前記第１の暗号化キー及び前記第２の暗号化キーは、前記端末と前記ネットワークとの間だけで共有される加入者管理キーにより暗号化されたキーであることを特徴とする請求項１に記載の暗号化キー分配方法。
4. 前記第１の暗号化キー及び前記第２の暗号化キーは、サービス暗号化キーから派生したプログラム暗号化キーであり、
   前記ネットワークは、前記端末の前記第１の暗号化キー及び前記第２の暗号化キーに対する購入要請に応じて、前記第１の暗号化キー及び前記第２の暗号化キーを含む長期キーメッセージを前記端末に送信することを特徴とする請求項１に記載の暗号化キー分配方法。
5. 前記端末は、前記第１の暗号化キーの寿命が満了する前に前記第２の暗号化キーに対する購入を前記ネットワークに要請することを特徴とする請求項４に記載の暗号化キー分配方法。
6. 前記第１の暗号化キー及び前記第２の暗号化キーは、前記ネットワークで任意に発生するキーシード対から派生し、キードメイン識別子（ＩＤ）、キーシード対識別子、及びトラフィック暗号化キーを含むことを特徴とする請求項１に記載の暗号化キー分配方法。
7. 移動体ブロードキャストシステムにおける端末がブロードキャストサービスの保護のための暗号化キーの分配を受ける方法であって、
   長期キーメッセージをネットワークから受信する場合、加入者管理キーを用いて前記長期キーメッセージを検証するステップと、
   前記長期キーメッセージが有効である場合、リプレー検出を実行するステップと、
   前記リプレー検出に成功した場合、セキュリティ関数を用いて前記長期キーメッセージに含まれた暗号化キーの有効性を確認するステップと、
   前記暗号化キーが有効である場合、前記暗号化キーを解読し、前記暗号化キーからトラフィック暗号化キーを発生させ、これを格納するステップと
   を有することを特徴とする暗号化キーの分配を受ける方法。
8. 前記端末が前記セキュリティ関数で新たなトラフィック暗号化キーを要請するための要請メッセージを送信するステップと、
   前記セキュリティ関数が前記要請メッセージに応答して新たなトラフィック暗号化キーを前記端末に送信するステップと、をさらに含むことを特徴とする請求項７に記載の暗号化キーの分配を受ける方法。
9. 前記要請メッセージは、キードメイン識別子（ＩＤ）及びトラフィック暗号化キー識別子を含むことを特徴とする請求項８に記載の暗号化キーの分配を受ける方法。
10. ブロードキャストサービスを保護する移動体ブロードキャストシステムであって、
    前記ブロードキャストサービスを提供する際、第１の暗号化キーを発生させ、前記発生した第１の暗号化キーを含む長期キーメッセージを送信し、前記第１の暗号化キーの寿命が満了する前に第２の暗号化キーを発生させ、前記発生した第２の暗号化キーを含む長期キーメッセージを送信するネットワークと、
    前記ネットワークから受信した長期キーメッセージを検証し、セキュリティ関数を用いて前記長期キーメッセージに含まれた暗号化キーを解読し、前記暗号化キーからトラフィック暗号化キーを発生させ、これを格納する端末と
    を有することを特徴とする移動体ブロードキャストシステム。
11. 前記第１の暗号化キーの寿命及び前記第２の暗号化キーの寿命は、前記第１の暗号化キー及び前記第２の暗号化キーから派生するトラフィック暗号化キーの寿命の整数倍であることを特徴とする請求項１０に記載の移動体ブロードキャストシステム。
12. 前記第１の暗号化キー及び前記第２の暗号化キーは、前記端末と前記ネットワークとの間だけで共有される加入者管理キーにより暗号化されたキーであることを特徴とする請求項１０に記載の移動体ブロードキャストシステム。
13. 前記第１の暗号化キー及び前記第２の暗号化キーは、サービス暗号化キーから派生したプログラム暗号化キーであり、
    前記ネットワークは、前記端末の前記第１の暗号化キー及び前記第２の暗号化キーに対する購入要請に応じて前記第１の暗号化キー及び前記第２の暗号化キーを含む長期キーメッセージを前記端末に送信することを特徴とする請求項１０に記載の移動体ブロードキャストシステム。
14. 前記端末は、前記第１の暗号化キーの寿命が満了する前に前記第２の暗号化キーに対する購入を前記ネットワークに要請することを特徴とする請求項１３に記載の移動体ブロードキャストシステム。
15. 前記第１の暗号化キー及び前記第２の暗号化キーは、前記ネットワークで任意に発生するキーシード対から派生し、キードメイン識別子（ＩＤ）、キーシード対識別子、及びトラフィック暗号化キーを含むことを特徴とする請求項１０に記載の移動体ブロードキャストシステム。
16. 前記端末は、前記セキュリティ関数で新たなトラフィック暗号化キーを要請するための要請メッセージを送信し、前記セキュリティ関数が前記要請メッセージに応答して新たなトラフィック暗号化キーを前記端末に送信することを特徴とする請求項１０に記載の移動体ブロードキャストシステム。
17. 前記要請メッセージは、キードメイン識別子（ＩＤ）及びトラフィック暗号化キー識別子を含むことを特徴とする請求項１６に記載の移動体ブロードキャストシステム。

Images