JP2004535704A - Ｉｐサービスへの条件アクセス方法およびシステム - Google Patents

Abstract

ＩＰタイププロトコルを用いるネットワーク（３）を介して、アクセス制御によって、情報（２０）を送信するための方法である。本発明によれば、送信時に、第１データグラム（２３）がスクランブルされ、アクセス制御手段を識別する少なくとも１つのデータを具備するヘッダー（２４）が定義され、データブロック（２６）を作成するために、前記ヘッダー（２４）が、スクランブルされた第１データグラム（２３）と連結され、データブロック（２６）が、第２データグラム（３０）内にカプセル化され、ネットワークを介して、第２データグラム（３０）が受信用に送信され、こうして受信されたデータグラムから、データブロック（２６）が抽出され、ヘッダー（２４）が抽出され、前記データへのアクセスが認可される場合に、第１データグラム（２３）がスクランブル解除され、かつ、スクランブル解除されたデータが配信される。

Description

【技術分野】
【０００１】
本発明は、ＩＰサービスのスクランブリングおよびＩＰサービスへのアクセス制御の技術分野におけるものである。
【０００２】
本発明は、より詳細には、ＩＰプロトコルを利用するネットワークを介して、アクセス制御によって、情報を送信／受信するための方法およびシステム、および、該方法の実施を可能にする装置に関するものである。
【０００３】
この方法については、ＩＰを介した視聴覚的フロー（audiovisual flow）サービスと、インターネットを介して衛星により分配されるデータ分配サービスとに対するアクセスを制御するために利用することができる。
【背景技術】
【０００４】
ＩＰデータのスクランブリングおよびＩＰデータへのアクセス制御を実現するための多数の解決法が現在では用いられている。これらの解決法の中から、機密的な様式でＩＰデータグラム内のデータをポイントツーポイント（point-to-point）で移送することを可能にするＩＰＳＥＣ規格を引用する。この規格は、
−機密性
−認証
−無欠性
というサービスを提案する。
【０００５】
ＩＰＳＥＣによる保護は、サーバーの変更も、クライアントの位置においてインストールされたアプリケーションの変更も必要としない。しかしながら、スクランブリングは、一般的には、特定のサービスに対してのみならず、クライアントとサーバーとの間のトラフィック全体に対しても加えられる。さらに、保護を必要としないデータをトラフィックが具備する限りにおいて、定義されたサービスに対して選択的なスクランブリングを行うべき場合にはＩＰＳＥＣ規格を用いることができない。
【０００６】
この規格についての他の欠点は、リターン経路（return path）の存在を課すという点である。現在、ポイントマルチポイント（point-multi-point）アプリケーションの枠組において、リターン経路は必要ではない（例えば、衛星による送信（マルチキャスト））。
【０００７】
さらに、鍵の交換は、コンテンツへのアクセスが公開鍵アルゴリズムの利用によって行われることを可能にする。この理由により、この規格は、ディジタルテレビ（例えば、ペイパービュー（pay per view）、加入、など）のために定義されかつ安全なプロセッサへ書き込まれるような権利を有することを引き換えに、情報のコンテンツへのアクセスを決定することを可能にはしない。
【０００８】
さらに、トランスポート層のレベルにおいてデータに適用される暗号化方法であるＳＳＬ（セキュアソケットレイヤー）規格を引用する。この方法は、保護されたデータと保護されていないデータとを区別するために、プロトコルインターフェースとポート番号とを利用する。例えば、プロトコル識別子が“ＨＴＴＰ”の代わりに“ＨＴＴＰＳ”を示す場合に、ネットワークを介したハイパーテキストリンクがこの方法を用いる。ＳＳＬにより保護されるデータは、概略的には、ＴＣＰサーバーのポート４４３への接続を介して、ナビゲートする。さらに、サーバーがポート４４３への接続を受信する場合に、サーバーは、ＳＳＬスクランブリングをこの接続に適用し、かつ、ＩＰデータをクライアントへ送信する。この手順は、クライアントおよびサーバーが、保護されたデータと保護されていないデータとを区別することを可能にする。
【０００９】
この方法の欠点は、用いられるＴＣＰトランスポートプロトコルに対する依存性にあり、これにより、このプロトコルのデータのフォーマットを、スクランブルすべきデータに課する。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明の目的は、ＩＰサービスを包括的にスクランブルすることを可能にし、かつ、チップカードのようなアクセス制御装置によってこれらのサービスへのアクセスを制御することを可能にするプロセスによって、前述した従来技術についてのこれらの欠点を緩和することである。
【００１１】
本発明のさらなる目的は、トランスポートプロトコルと関連した制約を除去することである。
【００１２】
本発明のさらなる目的は、特に、
−ポイントツーポイント・サービス；
−クライアント−サーバーリターン経路の存在を伴うマルチポイント・サービス；
−クライアント−サーバーリターン経路を伴わないマルチポイント・サービス；
というサービス構成設定において、前記データを用いるアプリケーションとは無関係に、ＩＰデータのスクランブリングを提供することである。
【課題を解決するための手段】
【００１３】
これらの目的は、
送信時に、
−第１データグラムをスクランブルする段階と、
−アクセス制御手段を識別する少なくとも１つのデータを具備するヘッダーを定義する段階と、
−データブロックを作成するために、前記ヘッダーを、スクランブルされた第１データグラムと連結する段階と、
−データブロックを第２データグラム内にカプセル化する段階と、
−ネットワークを介して、第２データグラムを送信する段階と
を具備し、
受信時に、
−受信されたデータグラムから、データブロックを抽出する段階と、
−ヘッダーを抽出する段階と、
−データへのアクセスが認可される場合に、第１データグラムをスクランブル解除する段階と、
−スクランブル解除されたデータを配信する段階と
を具備する方法によって達成される。
【００１４】
本発明によれば、前記データブロックは、ＵＤＰパケット内にカプセル化される。
【００１５】
本発明によれば、前記データブロックは、ＩＰデータグラム内に直接的にカプセル化される。
【００１６】
本発明によれば、前記スクランブル段階は、
−送信元ＩＰアドレスまたは宛先ＩＰアドレスと対応するラベルを用いて、スクランブルすべきサービスを定義する段階と、
−少なくとも１つのアクセス条件または少なくとも１つの秘密鍵を捕捉する段階と
を具備する。
【００１７】
本発明によれば、前記データブロックは、
−送信されたデータを端末により処理するために必要な情報を移動するヘッダー（access_control_header）と、
−スクランブルすべきデータを示すシーケンス（ペイロード）と
を具備する。
【００１８】
本発明によれば、前記データブロックは、下記の数式のようなシンタックスにしたがう。
【００１９】
【数１】

【００２０】
本発明によれば、前記シーケンス（ペイロード）は、下記の数式のようなシンタックスにしたがう。
【００２１】
【数２】

【００２２】
本発明によれば、前記ヘッダーは、エラー検出シーケンスを示すフィールド（EDC）をさらに具備する。
【００２３】
本発明の一実施例によれば、送信時のＩＰデータグラム内に挿入されるＵＤＰパケット内に前記データブロックが挿入される場合に、ＵＤＰ送信元ポートは、ＵＤＰリンクの開始位置に動的に割り当てられる。
【００２４】
この実施例において、ＵＤＰ宛先ポート番号の割り当てについては、静的（監督機関により最終的に与えられた構成設定データ）に、または、スクランブラーとデスクランブラーとの間におけるシグナリングプロトコルにより動的にさえも行うことができる。
【００２５】
本発明の実施例によれば、最終的なクライアントによるＵＤＰ／ＩＰデータグラムの受信は、
−第２データグラムを受信する段階と、
−以前に開かれたＵＤＰポート（静的ポートまたは動的ポート）を経て、ＵＤＰパケットを受信する段階と、
−データブロックを回復し、かつ、スクランブル解除する段階と、
−ヘッダーを抽出する段階と、
−スクランブル解除されたＩＰデータグラムを、疑似ドライバーへ送信する段階と、
−第１データグラムの宛先から、データを抽出する段階と、
−抽出されたパケットを、宛先アプリケーションへ送信する段階と
を具備する。
【００２６】
本発明の実施例の代替案によれば、最終的なクライアントによるＵＤＰデータグラムの受信は、
−第２データグラムを受信する段階と、
−開かれたＵＤＰポート（静的ポートまたは動的ポート）上で、ＵＤＰパケットを受信する段階と、
−データブロックを回復し、かつ、スクランブル解除する段階と、
−ヘッダーを抽出する段階と、
−ＩＰスタックのループバックアドレスを介して、第１ＩＰデータグラムを再送信する段階と、
−第１データグラムからデータを抽出して、これらを宛先アプリケーションへ送信する段階と
を具備する。
【００２７】
本発明によれば、送信されたＩＰサービスは、ＩＰを介した視聴覚的フローである。
【００２８】
本発明によれば、送信されたＩＰサービスは、ＩＰネットワークを介して衛星により送信されたデータである。
【００２９】
前記データは、アクセス制御手段と用いられるスクランブリング方法の表示とを識別する少なくとも１つのデータを具備するヘッダーを、ＩＰと関連づける手段を具備する送信器により、ＩＰネットワークを介して送信される。
【００３０】
前記送信器は、
−送信元ＩＰアドレスまたは宛先ＩＰアドレスと対応するラベルを用いて、スクランブルすべきサービスを定義する手段と、
−少なくとも１つのアクセス条件または少なくとも１つの秘密鍵を捕捉する手段と
をさらに具備する。
【００３１】
本発明によれば、前記送信器は、ＩＰデータフローサーバーと、ＩＰスクランブラーを具備するゲートウェイと、ＥＣＭ生成器と、ＥＭＭ生成器と、データベースとを具備する。
【００３２】
ネットワークを介しての、送信されたデータの受信は、スクランブルされたデータブロックのヘッダーを抽出する手段と、少なくとも１つのアクセス条件または少なくとも１つの秘密鍵をアクティブ化する手段とを具備する受信器により実現される。
【００３３】
ＩＰタイプネットワークにおけるスクランブリング／アクセス制御システムは、前述した送信器と受信器とを具備する。
【００３４】
本発明による、ＩＰサービスのためのスクランブリング／アクセス制御装置は、スクランブルすべきサービスを定義するための、かつ、アクセス条件または秘密鍵を捕捉するためのヒューマンマシンインターフェースを具備する。
【００３５】
本発明によれば、前記アクセス制御手段は、秘密鍵を送信するためのメモリカードを具備する。
【発明を実施するための最良の形態】
【００３６】
本発明の他の特徴および利点は、添付図面を参照した非制限的な例として提供される以下の説明から明らかとなるだろう。
【００３７】
図１は、インターネットネットワーク３を経て複数のクライアント４に接続されるローカルネットワーク２（ＬＡＮ：ローカルエリアネットワーク）において、幾つかのデータ処理／送信装置が相互接続されているシステムを図式的に示す。ＬＡＮ２は、ＩＰデータフローサーバー６と、ＩＰスクランブラーを具備するゲートウェイ８と、ＥＣＭ生成器１２（アクセス制御メッセージＤＶＢ、権利付与制御メッセージ（entitlement control message））と、ＥＭＭ生成器１４（アクセス管理メッセージＤＶＢ、権利付与管理メッセージ（entitlement management message））と、データベース１６とを具備する。ＬＡＮ２は、ウェブサーバー１７に接続される。サーバーアプリケーションの特徴（@IP_server，name_program，scrambling_active）を示すウェブサーバー１７は、同じＬＡＮ２上に存在するとは限らない。
【００３８】
前記フローサーバー６により配信されるＩＰデータは、権利を付与されたクライアント４により保持されるチップカード上に登録されたアクセス権の所持を要求する視聴覚的サービスであり得る。これらの視聴覚的サービスは、インターネットネットワーク３を介して送信される前に、ゲートウェイ８内に統合されたＩＰスクランブラーによりスクランブルされる。
【００３９】
各々のクライアント４は、例えばチップカードのようなアクセス制御装置を具備する機器１８を有する。
【００４０】
ゲートウェイ８には、
−スクランブルすべきサービスを定義すること；
−アクセス条件または秘密鍵を捕捉すること；
を可能にするヒューマンマシンインターフェース（human-machine interface）ＨＭＩプログラムが設けられる。
【００４１】
スクランブルすべきサービスは、送信元ＩＰアドレスまたは宛先ＩＰアドレスと対応するラベルにより識別され、該ラベルにしたがって、送信元からのデータをスクランブルすることが希望され、および／または、宛先へ行くことが希望される。
【００４２】
下記の表（表Ｉおよび表II）に示されるように、データのスクランブリングは、ＩＰデータグラムの送信元（ｓ）アドレスおよび／または宛先（ｄ）アドレスにより特徴づけられるサービス識別子（IDservice）と、スクランブリング鍵とを結びつける結果となる。この鍵を更新する周期性は、チップカードを利用しないシステム（表Ｉ）においては比較的低く、かつ、チップカードを利用するシステム（表II）においては比較的高くなり得る。後者において、制御ワードの名前が携えられる。
【００４３】
【表１】

【００４４】
【表２】

【００４５】
チップカードを利用するシステムにおいて、制御ワードを得るためには、以前にカード上に登録された権利の所持が条件となる。
【００４６】
ＩＰコンテクスト内の制御ワードを復活させるためにチップカードを利用するアクセス制御システムの実施に結びつけられたシグナリングは、優先度の順に、
−ＵＤＰ／ＩＰスタックを利用するデータ分配サービス：ＩＰＳａｔ（プッシュ、ファイル転送）；
−ＵＤＰ／ＩＰスタックを利用する、ＩＰ（ＩＰマルチポイントフロー）を介した視聴覚的分配サービス（マルチポイントの映像会議または音声会議、視聴覚的分配）；
−ＵＤＰ／ＩＰスタックを利用する、ＩＰを介した視聴覚的分配サービス（ＶＯＤ、ポイントツーポイントの映像会議、ＩＰを介した電話通信）；
−ＴＣＰ／ＩＰスタックを利用するトランザクションサービス；
というサービスをカバーする。
【００４７】
図２は、本発明による、データグラムを作成するための段階を図式的に示す。送信すべきデータ２０は、最初に、可変的な長さのものであり得るパケット２１の形に分割される。次に、各々のパケット２１は、ＩＰヘッダー２２と関連づけられて、第１データグラム２３が構成される。
【００４８】
ＩＰネットワークを介したパケット２１の送信は、以下の原理に基づくものである：
−第１データグラム２３（ＰＤＵ（プロトコルデータユニット））をスクランブルする；
−スクランブリング工程において発生する要素をデスクランブラーに提供することを可能にするアクセス制御標識として知られるヘッダー２４“access_control_header”を定義する（このヘッダー２４は、ＩＰデータグラム２３をスクランブルするために用いられるアクセス制御システムのタイプを識別するための弁別部２５と、制御データ２７とを具備する）；
−データブロック２６を形成するために、このヘッダー２４とデータグラム２３とを連結する；
−このデータブロック２６をＵＤＰデータグラム内にカプセル化する。
【００４９】
これらの工程一式は、以下の説明において、ＩＰ−ＣＡＳ（ＩＰ条件アクセスシステム）と称される。
【００５０】
ヘッダー２４の概略的な構造は、バイナリーデータブロックを示す様々なフィールドについて説明する付録１（Appendix）に例示されている。このヘッダー２４は、
−ヘッダー２４の全長を示すフィールド（header_length）；
−有用な情報をスクランブルする場合の、スクランブリングのアプリケーションのモードを示すフィールド（payload_scrambling_control）；
を具備する。
【００５１】
ヘッダー２４は、エラー検出シーケンスを示すフィールド（EDC）をさらに具備し得る。本発明によれば、（payload_scrambling_control≠００）の場合には、ヘッダー２４（access_control_header）は、ペイロードのコンテンツのスクランブル解除（descrambling）のモードを示すフィールド（payload_descrambling_way）をさらに具備する。
【００５２】
フィールド（payload_descrambling_way）＝ｘｉ（ｘｉは２進値）の場合には、ヘッダー２４は、スクランブルされたデータグラム２３のヘッダー２４における少なくとも１つの条件アクセス記述子（ECM_CA_descriptor）の存在を示すフィールド（ECM_CA_descriptor_flag）と、（値が１に等しい場合には）スクランブルされたデータグラム２３のヘッダーにおける少なくとも１つのフィールドECM()の存在を示すフィールド（ECM_flag）とをさらに具備する。
【００５３】
（ECM_CA_descriptor_flag≠１）の場合には、ヘッダー２４は、スクランブルされたデータグラム２３のヘッダー２４内に存在するブロック（ECM_CA_descriptor）の数を示すフィールド（Nb_ECM_CA_descriptor）をさらに具備する。
【００５４】
ヘッダー２４は、ヘッダーの始まりを識別することを可能にするフィールド（access_control_header_start_sequence）と、ヘッダー２４の現在のバージョンを示すフィールド（version_number）と、利用されるサービスの参照（reference）を示すフィールド（service_ID）と、送信されるデータのタイプを示すフィールド（payload_type）と、将来的な使用のために予約されるフィールド（RUF0）とをさらに具備する。
【００５５】
ヘッダー２４は、データグラムをスクランブルするために用いられるアルゴリズムのタイプを示すフィールド（scrambling_algorithm_type）と、スクランブル解除された有用なデータのためのエラー訂正フィールド（CRC_32）とをさらに具備する。
【００５６】
ブロックモードにて機能するアルゴリズムを用いて、データグラム２３がスクランブルされる場合には、ヘッダー２４（access_control_header）は、
−ペイロードの終わりに追加される充填バイト（filler byte）の数を示すフィールド（payload_padding_size）；
−（値がゼロとは異なる場合には）スクランブラーの初期化ベクトルフィールドの存在および長さを示すフィールド（IVOperator_ID_length）；
−（IVOperator_ID_length）の値がゼロとは異なる場合には、スクランブラーの初期化ベクトルの値を示すフィールド（IVOperator_ID_value）；
−将来的な使用のために予約されるフィールド（RUF1）；
をさらに具備する。
【００５７】
ヘッダー２４は、（値が１に等しい場合には）スクランブルされたデータグラム２３のヘッダー２４における少なくとも１つの条件アクセス記述子（ECM_CA_descriptor）の存在を示すフィールド（ECM_CA_descriptor_flag）と、将来的な使用のために予約されるフィールド（RUF2）とをさらに具備する。
【００５８】
ヘッダー２４は、ブロック（ECM_CA_descriptor）のバージョンを示すフィールド（ECM_CA_descriptor_version_number）をさらに具備する。
【００５９】
（EMM_CA_descriptor_flag＝１）である場合には、ヘッダー２４は、ブロック（EMM_CA_descriptor）のバージョンを示すフィールド（EMM_CA_descriptor_version_number）と、データブロック（EMM_CA_descriptor）とをさらに具備する。
【００６０】
（ECM_flag＝１）である場合には、ヘッダー２４は、スクランブルされたデータグラム２３のヘッダー２４におけるＥＣＭの数を示すフィールド（NB_ECM）をさらに具備する。
【００６１】
（payload_descrambling_way≠０１０）である場合には、ヘッダー２４は、将来的な使用のために予約される第３フィールド（RUF3）を具備する。
【００６２】
アクセス制御メッセージは、
−スクランブル解除するための特定のＥＣＭを選択するために複数のＥＣＭを区別するためのECM_indexポインター；
−ＥＣＭデータと、段階変更命令とを含むECM_tableテーブル；
を具備する。
【００６３】
例として、アクセス制御メッセージは、下記の数式のようなフォーマットを有し、この場合に、ECM_indexは、条件アクセスの記述子と関連づけられたＥＣＭを示し、かつ、ECM_table()は、ＥＣＭの構造を示す。
【００６４】
【数３】

【００６５】
ECM tableは、
−識別フィールド（table_id）；
−ＥＣＭの長さを示すフィールド（ECM-length）；
を具備する。
【００６６】
ECM_table()は、下記の数式のような構造を有し、この場合に、table_idは、
−条件アクセス記述子ＥＣＭの始まりを示すフィールド（descriptor_tag）；
−ＥＣＭ記述子の長さを示すフィールド（ECM_CA descriptor_length）；
−利用されるアクセス制御の識別子を示すフィールド（CA_system_ID）；
−ポインター（ECM_index）；
というテーブル内に含まれるデータのタイプを識別する８ビットフィールドを示す。
【００６７】
【数４】

【００６８】
例として、条件アクセス記述子（ECM_CA_descriptor）は、下記の数式のようなフォーマットを有し、かつ、アルゴリズムのタイプの識別子は、
−CI_Tag識別子；
−識別子の長さを示すCI-lengthフィールド；
−CI_Tag識別子の値を示すCI_valueフィールド；
を具備する。
【００６９】
【数５】

【００７０】
スクランブリングアルゴリズムのタイプの識別子は、下記の数式のようなフォーマットを有する。
【００７１】
【数６】

【００７２】
サービスオペレータ（service operator）は、
−チップカード内で利用されるサービスオペレータの領域について説明することを可能にするブロックのSOID_tag識別子；
−前記領域の長さを示すSOID_lengthフィールド；
−SOID_tag識別子の値を示すSOID_valueフィールド；
を具備する。
【００７３】
サービスオペレータは、下記の数式のようなシンタックスを示すフィールドにより識別され、この場合に、SOID_valueは、チップカード内で利用されるサービス領域を識別するフィールドを示す。
【００７４】
【数７】

【００７５】
−下向きの（descending）流れの系統的なスクランブリング；
−ウェブサーバー１７によりアクティブ化されるスクランブリング；
という２つのスクランブリング選択肢が提案される。
【００７６】
図４は、クライアントの主導で（段階（ａ））ウェブサーバー１７によりアクティブ化されるスクランブリング（段階（ｃ））を図式的に示す図である。この場合に、“スクランブリングをアクティブ化しなさい”というパラメータ（http://@IP:port/prog_scrambled/name_programというＵＲＬでのキーワード）を備えた、リンク上のクライアントのＨＴＴＰ要請（ａ）を受信すると、ウェブサーバー１７上のアクティブ状態のデーモン（demon）は、アクティブ化要請を、ＩＰスクランブラーへ送信する（段階（ｂ））。
【００７７】
スクランブリングのシナリオは、以下の通りである：
１）フローサーバー６は、ポイントツーポイント・モードまたはマルチポイント・モードで、ＩＰデータグラム２３を送信する。データグラム２３の宛先アドレスは、クライアントのアドレス（ポイントツーポイント）であり、または、分配アドレス（マルチポイント）ですらある。
２）ＩＰスクランブラーは、ＩＰデータグラム２３を最終的にフィルタリングする。ＩＰデータグラム２３の元のアドレスは、フローサーバー６のアドレスであり、かつ、宛先アドレスによりスクランブリングセッションを維持する。このフィルターは、図４のイーサネット（登録商標）レベルにおいて作用する。
３）次に、ＩＰスクランブラーは、ヘッダー２４（access_control_header）を、段階２においてスクランブルされるＩＰデータグラム２３に連結し、次に、このフィールドを、最初のデータグラムと同じ宛先アドレスを経て、ＵＤＰスタックを介して送信する。
４）フローサーバー６の宛先データグラムは、ＩＰスクランブラーにより傍受されない。
【００７８】
このスクランブリング手順を実現するために、スクランブリングを行う機器は、スクランブリングパラメータを識別すべきである。したがって、
−ＩＰスクランブラーについての、テーブル内の“有線（cabled）”情報；
−必要な情報を中心に集める専用ウェブサーバー１７についての、ＩＰスクランブラーによる質問；
−ウェブサーバー１７によるＩＰスクランブラーの更新；
−ユーザーにより行われる、スクランブラーの局所的な更新；
という幾つかの選択肢が考えられ得る。
【００７９】
送信時におけるＵＤＰ／ＩＰトンネルフィールドの評価は、以下の機構にしたがって行われる：
−スクランブラーは、以下の情報を備えたＩＰデータグラムを生成する：
・送信元ＩＰアドレスは、スクランブラーのＩＰアドレスである。このアドレスは、公衆ＩＰアドレスである。
・宛先ＩＰアドレスは、最初のデータグラムの宛先のアドレスである。
・ＵＤＰ送信元ポートは、ＵＤＰスタックの開始位置（opening）に動的に割り当てられる。
【００８０】
クライアントステーション上でのルーピングの問題を防ぐために、スクランブルされたＵＤＰフローポートは、元のＵＤＰフローポートと同じではない。後述のＵＤＰ ＩＰ−ＣＡＳポートにおいて呼び出される宛先ＵＤＰポート番号を割り当てるために、以下のような２つの可能性が存在する：
−スクランブラーとデスクランブラーとの間におけるシグナリングプロトコルによる動的な割り当て（このことは、クライアントとサーバーとの間におけるリターン経路の存在を前提とする）。
−以下の規則を用いて与えられる、認証機関により提供される構成設定値。
・既知のポートは、０から１０２３までのポートである。
・登録されたポートは、１０２４から４９１５１までのポートである。
・動的に割り当てられるポートは、４９１５２から６５５３５までのポートである。
【００８１】
〈受信手順：ＩＰ−ＣＡＳ仮想スタック〉
“スクランブリング解除”ソフトウェア３５は、クライアントステーション上にインストールされる（ウィンドウズ（登録商標）、Ｌｉｎｕｘ、Ｍａｃ（登録商標）ＯＳ、など）。疑似ドライバー（pseudo-driver）４０の利用、または、“未加工（raw）”モードでのループバック（loopback）の利用、という２つの使用法が予想される。
【００８２】
〈１．疑似ドライバーの利用〉
図５は、このモードでの使用法を示す。データは、インターネットネットワーク３によって、アクセスプロバイダのインターフェース４２（ＦＡＩ）上で受信され、かつ、データは、クライアントマシンのＩＰスタック４４を経て、特定のＩＰ＿ＣＡＳポート上で、ＵＤＰデータを待機するデスクランブラー３５へ移される。このデスクランブラー３５は、ＩＰスタックを経て、ＵＤＰデータグラムのデータを回復し（recoup）、ヘッダー〈discriminator-access_control_header〉を抽出し、かつ、元のＩＰデータグラムをスクランブル解除する。
【００８３】
デスクランブラー３５は、元の宛先ポートを介して、データを待機する最終的なクライアントへ、ＩＰデータグラムを提供する。
【００８４】
このＩＰデータグラムを、（マシンと同一区内に存在する）最終的なクライアントへ送信するために、疑似ドライバーネットワーク４０を、ＩＰスタックの下で展開する必要がある：
−この疑似ドライバーは、デスクランブラー３５からのデータを待機しており、かつ、これらをＩＰスタックへ提供する。
−最終的なアプリケーションは、その特定のポート上で待機しており、かつ、通常は、ＴＣＰ（またはＵＤＰ）／ＩＰスタックにより元のＩＰデータグラムがカプセル化解除（de-encapsulation）された後に、プレーンテキストでのデータを回復する。
【００８５】
この解決法については、マシンのＩＰスタックの下で第２ネットワークドライバーを追加することを可能にするオペレーティングシステム上で実施することができる。ＩＰ層レベルにおけるＦＡＩドライバー４２および疑似ドライバー４０のルーティングは、
（１）ＩＰ＿ＣＡＳポート上のＵＤＰパケットの到着
（２）スクランブルされたＩＰデータグラム２３の回復（recuperation）
（３）元のスクランブル解除されたＩＰデータグラムの、疑似ドライバーへの移行
（４）クライアント４による、宛先ポート上のデータの回復
という機構にしたがって、各々のネットワークドライバーにとって適切なＩＰアドレス上で行われる。
【００８６】
この機構は、元のデータグラム２３を無変更で回復することを可能にし、スクランブル解除機能を最終的なクライアントから完全に独立させる。データの受信時に、この機構は、ＵＤＰ／ＴＣＰモードにおけるＩＰスタックのみを利用する。
【００８７】
〈２．ループバックの“未加工（RAW）”モードの利用〉
図６に示されるように、データは、ＦＡＩインターフェース４２を経て受信され、かつ、クライアントマシンのＩＰスタック４４を経て、特定のＩＰ＿ＣＡＳポート上で、ＵＤＰデータを待機するデスクランブラー３５へ移される。デスクランブラー３５は、ＩＰスタック４４を経て、ＵＤＰデータグラムのデータを回復し、ヘッダー〈discriminator-access_control_header〉を抽出し、かつ、元のＩＰデータグラム２３をスクランブル解除する。デスクランブラー３５は、このＩＰデータグラム２３を、ＵＤＰ（またはＴＣＰ）上の元の宛先ポート上で、データを待機する最終的なクライアントへ提供する。
【００８８】
ＦＡＩ／ＩＰスタック４２内のＩＰデータグラム２３は、マシンの宛先ＩＰアドレス（１２７．０．０．０）へＩＰループバックを伝えることにより、ＩＰスタック４４を経て再送信される。この再送信は未加工モードで行われるが、その理由は、再送信されたデータが、修正すべきではない完結したＩＰフレームを構成するためである。ＩＰスタック４４のループバック機構は、データを再送信せずに、これらのデータを再トレースする。デスクランブラー３５は、その特定のポート上において保留状態（pending）であり、かつ、通常は、ＴＣＰ（またはＵＤＰ）／ＩＰスタックによりＩＰデータグラムがカプセル化解除された後に、プレーンテキストでのデータを回復する。
【００８９】
この解決法については、送信側において、ループバックにおけるＩＰスタック４４の未加工モードを利用することを可能にするオペレーティングシステム上で実施することができ、かつ、
（１）ＩＰ＿ＣＡＳポートを経ての、ＵＤＰパケットの到着
（２）スクランブルされたＩＰデータグラムの回復
（３）未加工モードおよびループバックにおける、（（１２７．０．０．０）に置き換えられた宛先ＩＰアドレスを備えた）元のスクランブル解除されたＩＰデータグラムの、疑似ドライバーへの移行
（４）クライアント４による、宛先ポート上のデータの回復
という機構にしたがって行われる。
【００９０】
クライアント側において、この機構は、最終的なアプリケーションへ再送信するためのデータの送信時と同様に、データの受信時に、これらをデスクランブラー３５へ伝えるために、ＵＤＰ／ＴＣＰモードにおけるＩＰスタック４４のみを利用する。
【００９１】
図７は、本発明による、ポイントツーポイント環境におけるデータスクランブリングシステムを図式的に示す。
【００９２】
このシステムは、ユーザー端末４と、サービスプロバイダ６と、ＥＣＭ生成器１２と、データベース１６と、提案提示サーバー６４と、アクセス条件エディター６６と、ＲＴＳＰタイプ視聴覚的コマンドゲートウェイ７２と、インターネットアクセスプロバイダ７４とを具備する。
【００９３】
以下の段階は、チップカードの使用による、ＶＯＤサービスへのユーザーのアクセスについて説明する。この原理については、他のタイプのポイントツーポイント・サービスにも拡張することができる。
【００９４】
アクセスは、加入者認証段階によって始まる。この段階は、加入者がインターネットアクセスプロバイダ７４に接続した直後に始まる。
【００９５】
このセッションの間に、遠隔的なユーザー端末４と、そのＩＰアドレスとは、アクセスプロバイダ７４により、ネットワークおよびカードのＵＡ（独自アドレス）への接続時に、動的に作動させられる。
【００９６】
〈段階１：提案の提示〉
ユーザーは、提案提示サーバー６４に対して、ＨＴＴＰ要請を行う。ユーザー端末４は、権利の取得とコンテンツとに関して提案を行うサービスを提示するページを受信する。
【００９７】
前記ページの提示は、任意的であり、かつ、運営者により直接的に管理され得る。次に、このページは、加入者による要求に応じて（例えば、権利を再ロードする時に）のみ現れる。
【００９８】
〈段階２：プログラムの選択〉
段階２は、ユーザーが特定のサービス（例えば、ＶＯＤサービス上における映画（film）の選択）を選択したことを前提とする。
【００９９】
２つの作用が並列して展開される：
−第１の作用は、ナビゲーターの宛先におけるものである（段階２）；
−第２の作用は、スクランブリングシステムの宛先におけるものである（段階２’）。
【０１００】
この第２段階において、提示サーバーは、映画のＵＲＬ全体を、ＨＴＴＰ応答（例えば、〈http://serv1.name-of-the-film.ram〉）で、端末へ再送信する。
【０１０１】
〈段階３：映画プレイヤーの実行プログラムの開始〉
ユーザーのナビゲーターは、このプログラム（本例においては、リアルプレイヤー（RealPlayer））を、映画パラメータ“name_of_the_film.ram”で伝えることにより、アクティブ化する。
【０１０２】
前記プレイヤーは、ＵＲＬ〈http://serv1.name-of-the-film.ram〉に接続される。次に、ＲＴＳＰ（開始、停止、再生、巻き戻し、早送り、など）コマンドセッションが、端末４と、ＲＴＳＰ要請を最も適切なフローサーバーへリダイレクトするコマンドゲートウェイ７２との間において開かれ、コマンドゲートウェイ７２およびフローサーバー６が、最終的に結合される。
【０１０３】
〈段階４：フローサーバーの接続〉
次に、ＲＴＳＰサーバーは、映画（ここでは、serv1...）を配信することにより、関係しているサーバーとのＴＣＰセッションを開く。
【０１０４】
〈段階５：同報通信の開始〉
次に、フローサーバー６は、送信元アドレスとしてのサーバーのアドレス、および、宛先アドレスとしての最終的なクライアントのアドレスとともに、映画を、ＵＤＰ／ＩＰデータグラムで、スクランブリングゲートウェイへ送信する。
【０１０５】
〈段階６：プログラムのスクランブリング〉
次に、データベース１６内のポイントツーポイント・サービスの検出時に自動的にアクティブ化されるポイントツーポイント・フィルターを有するスクランブリングゲートウェイは、包括的に（@originを経て）、または、個人的に（@addresseeを経て）、または、ＵＲＬにしたがって、降下してくる（downcoming）データをスクランブルすることができる。
【０１０６】
〈段階７：ポイントツーポイント・システムの閉鎖〉
ポイントツーポイント・セッションについては、タイムアウト（送信元アドレスからのパケットまたは受信人のデータをＸ秒間受信しないこと）に基づいて、スクランブリングセッションにより閉じることができる。ポイントツーポイント・タイムアウトの最大値は、機器の全般的なパラメータの構成設定時に示される。
【０１０７】
【表３】

【図面の簡単な説明】
【０１０８】
【図１】本発明による、アクセス制御を伴うデータ送信／受信システムを図式的に示す図である。
【図２】本発明による、データグラムの構造を定義するための段階を図式的に示す図である。
【図３】本発明による、スクランブリングの好ましい実施例を図式的に示す図である。
【図４】本発明による方法において実施される第１受信モードを図式的に示す図である。
【図５】本発明による方法において実施される第２受信モードを図式的に示す図である。
【図６】本発明による、ポイントツーポイント環境におけるデータスクランブリングシステムを図式的に示す図である。
【符号の説明】
【０１０９】
２ ＬＡＮ
３ インターネットネットワーク
４ クライアント
６ ＩＰデータフローサーバー
８ ゲートウェイ
１２ ＥＣＭ生成器
１４ ＥＭＭ生成器
１６ データベース
１７ ウェブサーバー
１８ アクセス制御装置
２０ 送信すべきデータ
２１ パケット
２２ ＩＰヘッダー
２３ 第１データグラム
２４ ヘッダー
２５ 弁別部
２６ データブロック
２７ 制御データ
３０ 第２データグラム
３５ デスクランブラー
４０ 疑似ドライバー
４２ ＦＡＩインターフェース
４４ スタック
６４ 提案提示サーバー
６６ アクセス条件エディター
７２ ＲＴＳＰタイプ視聴覚的コマンドゲートウェイ
７４ インターネットアクセスプロバイダ

Claims (41)

1. ＩＰタイププロトコルを用いるネットワーク（３）を介して、アクセス制御によって、情報（２０）を送信するための方法であって、
   送信時に、
   −第１データグラム（２３）をスクランブルする段階と、
   −アクセス制御手段を識別する少なくとも１つのデータを具備するヘッダー（２４）を定義する段階と、
   −データブロック（２６）を作成するために、前記ヘッダー（２４）を、スクランブルされた第１データグラム（２３）と連結する段階と、
   −データブロック（２６）を第２データグラム（３０）内にカプセル化する段階と、
   −ネットワークを介して、第２データグラム（３０）を送信する段階と
   を具備し、
   受信時に、
   −受信されたデータグラムから、データブロックを抽出する段階と、
   −ヘッダー（２４）を抽出する段階と、
   −データへのアクセスが認可される場合に、第１データグラム（２３）をスクランブル解除する段階と、
   −スクランブル解除されたデータを配信する段階と
   を具備することを特徴とする方法。
2. 前記データブロック（２６）は、ＵＤＰパケット内にカプセル化されることを特徴とする請求項１に記載の方法。
3. 前記データブロック（２６）は、ＩＰデータグラム内に直接的にカプセル化されることを特徴とする請求項１に記載の方法。
4. 前記スクランブル段階は、
   −送信元ＩＰアドレスまたは宛先ＩＰアドレスと対応するラベルを用いて、スクランブルすべきサービスを定義する段階と、
   −少なくとも１つのアクセス条件または少なくとも１つの秘密鍵を捕捉する段階と
   を具備することを特徴とする請求項１から請求項３のいずれかに記載の方法。
5. 前記データブロック（２６）は、
   −送信されたデータを端末（４）により処理するために必要な情報を移動するヘッダー（２４）（access_control_header）と、
   −スクランブルすべき有用なデータ（２０）を示すシーケンス（ペイロード）と
   を具備することを特徴とする請求項１に記載の方法。
6. 前記データブロック（２６）は、下記の数式のようなシンタックスにしたがうことを特徴とする請求項１から請求項５のいずれかに記載の方法。
   

   
7. 前記シーケンス（ペイロード）は、下記の数式のようなシンタックスにしたがうことを特徴とする請求項５に記載の方法。
   

   
8. 前記ヘッダー（２４）は、
   −ヘッダー（２４）の全長を示す第１フィールド（header_length）と、
   −情報（２０）のスクランブルリングのアプリケーションのモードを示す第２フィールド（payload_scrambling_control）と
   を具備することを特徴とする請求項５に記載の方法。
9. 前記ヘッダー（２４）は、エラー検出シーケンスを示すフィールド（EDC）をさらに具備することを特徴とする請求項８に記載の方法。
10. （payload_scrambling_control≠００）の場合には、前記ヘッダー（２４）は、情報（２０）のスクランブル解除のモードを示すフィールド（payload_descrambling_way）をさらに具備することを特徴とする請求項８に記載の方法。
11. （payload_descrambling_way＝００１）の場合には、前記ヘッダー（２４）は、該ヘッダー（２４）における少なくとも１つの条件アクセス記述子（ECM_CA_descriptor）の存在を示すフィールド（ECM_CA_descriptor_flag）と、（値が１に等しい場合には）ヘッダー（２４）におけるアクセス制御メッセージを示す少なくとも１つのフィールドECM()の存在を示すフィールド（ECM_flag）とをさらに具備することを特徴とする請求項１０に記載の方法。
12. （ECM_CA_descriptor_flag＝１）の場合には、前記ヘッダー（２４）は、該ヘッダー（２４）内に存在するブロック（ECM_CA_descriptor）の数を示すフィールド（Nb_ECM_CA_descriptor）をさらに具備することを特徴とする請求項１１に記載の方法。
13. 前記ヘッダー（２４）は、該ヘッダー（２４）の始まりを識別することを可能にするフィールド（access_control_header_start_sequence）と、ヘッダー（２４）の現在のバージョンを示すフィールド（version_number）と、利用されるサービスの参照を示すフィールド（service_ID）と、送信されるデータのタイプを示すバイナリーフィールド（payload_type）と、将来的な使用のために予約されるフィールド（RUF0）とをさらに具備することを特徴とする請求項８に記載の方法。
14. 前記ヘッダー（２４）は、データグラム（２３）をスクランブルするために用いられるアルゴリズムのタイプを示すフィールド（scrambling_algorithm_type）と、スクランブル解除された有用なデータのエラー訂正フィールド（CRC_32）とをさらに具備することを特徴とする請求項１０に記載の方法。
15. ブロックモードにて機能するアルゴリズムを用いて、データグラム（２３）がスクランブルされる場合には、前記ヘッダー（２４）は、
    −情報（２０）の終わりに追加されるパディングオクテットの数を示すフィールド（payload_padding_size）と、
    −（値がゼロとは異なる場合には）スクランブラーの初期化ベクトルフィールドの存在および長さを示すフィールド（IVOperator_ID_length）と、
    −（IVOperator_ID_length）の値がゼロとは異なる場合には、スクランブラーの初期化ベクトルの値を示すフィールド（IVOperator_ID_value）と、
    −将来的な使用のために予約されるフィールド（RUF1）と
    をさらに具備することを特徴とする請求項１４に記載の方法。
16. 前記ヘッダー（２４）は、（値が１に等しい場合には）スクランブルされたデータグラム（２３）のヘッダーにおける少なくとも１つの条件アクセス記述子（ECM_CA_descriptor）の存在を示すフィールド（ECM_CA_descriptor_flag）と、将来的な使用のために予約されるフィールド（RUF2）とをさらに具備することを特徴とする請求項１１に記載の方法。
17. 前記ヘッダー（２４）は、ブロック（ECM_CA_descriptor）にしたがうバージョンを示すフィールド（ECM_CA_descriptor_version_number）をさらに具備することを特徴とする請求項１２に記載の方法。
18. （EMM_CA_descriptor_flag＝１）である場合には、前記ヘッダー（２４）は、ブロック（EMM_CA_descriptor）の次バージョンを示すフィールド（EMM_CA_descriptor_version_number）をさらに具備することを特徴とする請求項１６に記載の方法。
19. （ECM_flag＝１）である場合には、前記ヘッダー（２４）は、スクランブルされたデータグラムのヘッダー（２４）におけるＥＣＭの数を示すフィールド（NB_ECM）をさらに具備することを特徴とする請求項１１に記載の方法。
20. （payload_descrambling_way＝０１０）である場合には、前記ヘッダー（２４）は、将来的な使用のために予約される第３フィールド（RUF3）を具備することを特徴とする請求項１０に記載の方法。
21. 前記アクセス制御メッセージは、
    −スクランブル解除するための特定のＥＣＭを選択するために複数のＥＣＭを区別するためのポインター（ECM_index）と、
    −ＥＣＭデータと、段階変更命令とを含むテーブル（ECM_table）と
    を具備することを特徴とする請求項１１に記載の方法。
22. 前記テーブル（ECM_table）は、
    −識別フィールド（table_id）と、
    −ＥＣＭの長さを示すフィールド（ECM_length）と
    を具備することを特徴とする請求項２１に記載の方法。
23. 前記条件アクセス記述子（ECM_CA_descriptor）は、
    −条件アクセス記述子ＥＣＭの始まりを示すフィールド（descriptor_tag）と、
    −長さを示すフィールド（ECM_CA_descriptor_length）と、
    −利用されるアクセス制御の識別子を示すフィールド（CA_system_ID）と、
    −ポインター（ECM_index）と
    を具備することを特徴とする請求項１７に記載の方法。
24. 前記アルゴリズムのタイプの識別子は、
    −識別子（CI_Tag）と、
    −識別子（CI_Tag）の長さを示すフィールド（CI-length）と、
    −識別子（CI_Tag）の値を示すフィールド（CI_value）と
    を具備することを特徴とする請求項１４に記載の方法。
25. サービスオペレータは、
    −チップカード内で利用されるサービスオペレータの領域について説明することを可能にするブロックの識別子（SOID_tag）と、
    −前記領域の長さを示すフィールド（SOID_length）と、
    −識別子（SOID_tag）の値を示すフィールド（SOID_value）と
    を具備するフィールドにより識別されることを特徴とする請求項１から請求項２４のいずれかに記載の方法。
26. ＵＤＰ送信元ポートは、ＵＤＰリンクの開始位置に動的に割り当てられることを特徴とする請求項２に記載の方法。
27. ＵＤＰ宛先ポート番号の割り当ては、スクランブラーとデスクランブラーとの間におけるシグナリングプロトコルを用いて動的に行われることを特徴とする請求項２に記載の方法。
28. ＵＤＰ宛先ポート番号は、認証機関により割り当てられる値であることを特徴とする請求項２に記載の方法。
29. 最終的なクライアントによるＵＤＰ／ＩＰデータグラムの受信は、
    −第２データグラム（３０）を受信する段階と、
    −以前に開かれた静的または動的なＵＤＰポートを経て、ＵＤＰパケットを受信する段階と、
    −データブロック（２６）を回復し、かつ、スクランブル解除する段階と、
    −ヘッダー（２４）を抽出する段階と、
    −スクランブル解除された第１ＩＰデータグラム（２３）を、疑似ドライバーへ送信する段階と、
    −第１データグラム（２３）から、データを抽出する段階と、
    −抽出されたパケットを、宛先アプリケーションへ送信する段階と
    を具備することを特徴とする請求項２７または請求項２８に記載の方法。
30. 最終的なクライアントによるＵＤＰデータグラムの受信は、
    −第２データグラム（３０）を受信する段階と、
    −以前に開かれた静的または動的なポート上で、ＵＤＰパケットを受信する段階と、
    −データブロック（２６）を回復し、かつ、スクランブル解除する段階と、
    −ヘッダー（２４）を抽出する段階と、
    −スタックのループバックアドレスを介して、第１ＩＰデータグラム（２６）を再送信する段階と、
    −第１データグラム（２３）からデータを抽出して、これらを宛先アプリケーションへ送信する段階と
    を具備することを特徴とする請求項２８に記載の方法。
31. 送信されたＩＰサービスは、ＩＰを介した視聴覚的フローであることを特徴とする請求項１から請求項３０のいずれかに記載の方法。
32. 送信されたＩＰサービスは、ＩＰネットワークを介して衛星により送信されたデータであることを特徴とする請求項１から請求項３０のいずれかに記載の方法。
33. 請求項１から請求項３２のいずれかに記載の方法を用いることが可能な、ＩＰタイプネットワークを介してスクランブルされたデータのための送信器。
34. 前記ＩＰデータグラム（２３）を、アクセス制御手段と用いられるスクランブリング方法の表示とを識別する少なくとも１つのデータを具備するヘッダー（２４）と関連づける手段を具備することを特徴とする請求項３３に記載の送信器。
35. −送信元ＩＰアドレスまたは宛先ＩＰアドレスと対応するラベルを用いて、スクランブルすべきサービスを定義する手段と、
    −少なくとも１つのアクセス条件または少なくとも１つの秘密鍵を捕捉する手段と
    をさらに具備することを特徴とする請求項３４に記載の送信器。
36. ＩＰデータフローサーバー（６）と、ＩＰスクランブラーを具備するゲートウェイ（８）と、ＥＣＭ生成器（１２）と、ＥＭＭ生成器（１４）と、データベース（１６）とを具備することを特徴とする請求項３５に記載の送信器。
37. 請求項１から請求項３２のいずれかに記載の方法にしたがって、スクランブルされたデータを受信することが可能な受信器。
38. スクランブルされたデータブロック（２６）のヘッダー（２４）を抽出する手段と、少なくとも１つのアクセス条件または少なくとも１つの秘密鍵をアクティブ化する手段とを具備することを特徴とする請求項３７に記載の受信器。
39. ＩＰタイプネットワークにおけるスクランブリング／アクセス制御システムであって、
    請求項３３に記載の送信器と、請求項３７に記載の受信器とを具備することを特徴とするシステム。
40. 請求項３６に記載の送信器を具備する、ＩＰサービスのためのスクランブリング／アクセス制御装置であって、
    スクランブルすべきサービスを定義するための、かつ、少なくとも１つのアクセス条件または１つの秘密鍵を捕捉するためのヒューマンマシンインターフェースをさらに具備することを特徴とする装置。
41. 前記アクセス制御手段は、秘密鍵を送信するためのメモリカードを具備することを特徴とする請求項４０に記載の装置。

Images