JP2004527188A - メッセージの保護および識別のためのセキュリティ装置およびセキュリティ方法 - Google Patents
メッセージの保護および識別のためのセキュリティ装置およびセキュリティ方法 Download PDFInfo
- Publication number
- JP2004527188A JP2004527188A JP2002592550A JP2002592550A JP2004527188A JP 2004527188 A JP2004527188 A JP 2004527188A JP 2002592550 A JP2002592550 A JP 2002592550A JP 2002592550 A JP2002592550 A JP 2002592550A JP 2004527188 A JP2004527188 A JP 2004527188A
- Authority
- JP
- Japan
- Prior art keywords
- message
- key
- msg
- identification
- encryption
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/60—Digital content management, e.g. content distribution
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Storage Device Security (AREA)
- Telephonic Communication Services (AREA)
Abstract
本発明は、可変の現在の鍵（Ｋ′ｉ）により識別（２１）をコントロールする手段を有する受信装置（２）に発送されるメッセージ（ＭＳＧ）を保護するためのセキュリティデバイス（３）およびプロセスに関する。さらに本発明は、メッセージを識別するための相応のデバイス（４）および対応のプロセスにも関する。セキュリティデバイスは、可変の現在の暗号鍵（Ｋｉ）を用いてこれらのメッセージ各々の少なくとも一部分に対する暗号化をコントロールするユニット（１１）を有しており、その際、メッセージに付加される署名が生成される。さらにセキュリティデバイスは、現在の暗号鍵を変更しこの暗号鍵を使用可能な複数の暗号鍵（Ｋ１〜Ｋｎ）から成るまえもって決められたセット（１６）から選択するユニット（１２）と、上記のメッセージに鍵識別子（ＫｅｙＩＤ）を登録するユニット（１３）も有している。鍵識別子（ｋｅｙＩＤ）によって受信装置は現在の識別鍵を、この現在の識別鍵と現在の暗号鍵とが互いに一致するよう、使用可能な複数の識別鍵（Ｋ′１〜Ｋ′ｎ）から成るまえもって決められたセットから選択できるようになる。さらに上記のメッセージはサービス通知メッセージである。
Description
【技術分野】
【０００１】
本発明は、ネットワークにおけるメッセージの安全保護および識別のための方法およびこの方法に対応する装置に関する。
【０００２】
安全でないネットワークにおいて、メッセージの流れがたとえば無線ブロードキャストにより行われようとケーブルによりあるいはインターネットネットワークにより行われようと、そのようなメッセージの流れを保証するために暗号鍵を用いることが一般的に行われており、これを暗号鍵とも称する。一般にはメッセージの送信側にそのような暗号鍵が与えられ、受信側には対応する識別鍵が与えられる。これらの鍵は構想するアプリケーションに応じて秘密鍵であってもよいし、公開鍵であってもよい。たとえば送信側が一対の鍵を使用し、それらのうちメッセージの暗号化を可能とする公開暗号鍵を送信側がブロードキャストし、しかも送信側は自身のためには非公開つまり秘密の復号化鍵を保持している。
【０００３】
メッセージの暗号化は２種類の主要な用途をもっている。すなわち、
メッセージの認証：このために暗号化により得られた結果が署名というかたちでメッセージに組み込まれる。この場合、識別鍵は復号鍵であってもよいし、暗号鍵であってもよい。
メッセージの秘匿化：このために暗号化の結果が秘匿化されるメッセージの部分を置き換える。この場合、識別鍵は復号化鍵である。
【０００４】
これら両方の種類の用途において望ましいのは、第三者によりメッセージが傍受されたり不正に復号されたりするリスク、あるいは署名を不正に添えることで偽造されるリスクを最低限に抑えることである。したがって権限のない暗号化または復号の可能性を複雑にする目的で、いくつかのシステムが提案されてきた。
【０００５】
このため、対応する暗号鍵と識別鍵を定期的に変更できるようにする技術が開発された。これらの技術のいくつかは、通信ネットワークを介した新しい識別鍵の配送に頼っており、他方、殊にこれらの鍵が秘密鍵であれば（たとえば鍵の秘匿暗号化などによって）それらの鍵を認識するのが難しくされる。しかしながらこれらの技術は、予防措置をとったにもしても配送された鍵の傍受およびその使用に対しては脆弱である。さらに新しい鍵を配送するごとに、受信側によってそれを認識しインストールする必要があり、このことは場合によっては鍵の効率に対し不利には働くようになる。
【０００６】
文献EP-0,506,637には、セルラ無線通信ネットワークにおける移動局の妥当性および照合のためのシステムが記載されている。このシステムはネットワークと移動局の双方において、固定的な鍵とローリングキー（rolling key）と呼ばれる変更可能な鍵を有している。これらの鍵は入力として認証アルゴリズムに供給され、ネットワークと各移動局において生成されたレスポンスの比較によって不正を正確に指摘できるようになる。ローリングキーはネットワークと移動局において双方向の認証各々に応じて、両方に共通する履歴認証情報に依存して同時に更新される。
【０００７】
したがってネットワークを経由することなく鍵が規則的に変更されるので、交換のセキュリティを高めることができる。とはいうもののこのようなシステムの欠点は、双方向の認証各々に応じて新たなローリングキーの計算が必要とされることである。しかも技術的な誤動作が生じて同期のとれない問題も発生する可能性があり、そのために認証を利用できなくなってしまうかもしれない。このことを改善するためには特定のメカニズムを構築しなければならず、それによってシステムが複雑になり、認証の信頼性が低減するというリスクが生じることになる。
【０００８】
アメリカ合衆国特許US-6,105,133には送信局／受信局の認証と秘匿暗号化のための双方向システムが開示されている。送信局のいずれか２つの間の交換は、認証と秘匿化ならびにこれらの局間のコネクションごとに変更される暗号鍵の使用により安全に保護される。この鍵は局各々において独立して計算され、これは他方の局の識別子と、双方の局に固定的なかたちで記録されたパラメータと、一方の局から他方の局へ通信される変更値とに基づき計算される。
【０００９】
この技術によれば、暗号鍵の周期的な変更を可能にし、ネットワークを介したこの鍵の伝送を回避し、かつ送信局と受信局における鍵の更新の同期を保証することで、システムの信頼性が高められる。とはいうものの、そのためには更新ごとに送信局と受信局において新たな鍵の計算が必要とされる。この計算に必要とされる時間によって、メッセージ受信後に迅速に実行すべきオペレーションが危うくされる。特にこのような時間は、復号および／または認証すべきメッセージのあとに先行のメッセージの知識を要求する処理がなされる他のメッセージが続き、これら先行のメッセージと後続のメッセージとの間の期間がこの知識の取得には十分ではないとき、誤動作の原因となる。
【００１０】
アメリカ合衆国特許US-5,301,233には、特定の個人に向けたプログラムの送信および受信のためのプロセスが開示されている。各プログラムは複数の秘匿暗号化された要素から成り、それらの要素各々ごとに意図する受信側の識別子が含まれている。対応する要素をアクセスするために、この識別子のみに権限が付与されている。アクセスコントロールメッセージによって、受信側は自身のために意図された要素の秘匿暗号化に使用されるコントロールワードを再構成することができる。詳しくはこのメッセージには「サービスキー識別子」が含まれており、さらにオプションとして、識別されたサービスキーを用いて得られた署名が含まれている。コントロールワードに加えられるオプションとしてのこの署名によってこのワードの妥当性を保証できるようになり、応答が否定的であったならば受信したプログラムを無視することができる。このキー識別技術は、これに特定されるわけではないが、キー生成用情報のバッチに頼っており、このバッチはキー識別子の中に含まれていて、これは８ｂｙｔｅの署名に対したとえば３ｂｙｔｅにわたっている（第５欄第４２〜５２行）。
【００１１】
アメリカ合衆国特許US-5,222,137は、秘匿暗号化無線伝送のための暗号鍵のダイナミックな選択に係わるものである。オペレーション中、複数の鍵識別子と対応する鍵をもつ無線機が他の同一の無線機と通信を行う。この無線機は、秘匿化されていない鍵識別子をもつ秘匿暗号化信号を送信および受信する。伝送を行う前にそのつど送信側無線機は鍵識別子の１つを自動的に選択し、送信すべきメッセージを対応する秘匿化暗号鍵を用いて秘匿暗号化する。受信側の無線機は受信した鍵識別子を用いて使用された秘匿化暗号鍵を求め、それを用いてメッセージを復号する。この方法によれば、ディスパッチないしは発送ごとに使用される鍵を変更できることから内容のダイナミックな保護を保証することができるため、セキュリティレベルが高められる。
【００１２】
しかしながら、受信したメッセージごとに処理するためには十分なオペレーション容量ならびにメモリスペースが必要とされる。情報を迅速に利用できなければならずメッセージサイズが重要であり殊に個々の受信側に対するサービスの発行のために重要である場合、このような状況では遅延が引き起こされる可能性があるし、あるいはメモリワイピングメカニズムがトリガされて情報の損失が引き起こされてしまうおそれすらある。
【００１３】
本発明は、ネットワークを介して発送することを意図したメッセージを保護するためのセキュリティ装置に関するものであり、変更可能な暗号鍵の使用に基づいている。このサービス装置によれば、上述の暗号鍵をネットワークを介して伝達させる必要なく変更することができ、メッセージの送信側と受信側において鍵の更新を同期合わせすることができ、さらに著しく迅速に鍵の交換を実行することができる一方、遅延あるいは不都合なメモリスペース要求を回避することができる。
【００１４】
また、本発明によるデバイスを、更新鍵のための複雑化したアルゴリズムを必要とすることなく経済的にインプリメントすることができる。
【００１５】
本発明はさらに、ネットワークを介して受信したメッセージを識別するデバイスにも関し、これによって上述の利点を得ることができる。
【００１６】
本発明はさらに、本発明に従って構成された１つまたは複数の識別デバイスを有するメッセージ送信装置にも、本発明に従って構成された１つまたは複数の識別デバイスを有するメッセージ受信装置にも適用されるし、さらにコンピュータプログラム製品、メッセージおよび相応のセキュリティおよび識別プロセスにも適用される。
【００１７】
以下の記載では次のような名称を採用する：
−「認証」"authentication" 、これはネットワークを介して伝達されるメッセージの出所と完全性の保証に関連する手順であり、メッセージ送信前に鍵を用いて生成されメッセージ中に入れられるディジタル署名に基づいて行われる、
−「秘匿化」"encryption" 、平文をそのままでは役立たない理解不能な文に置き換える手順；
−「秘匿解除」"decryption" 、秘匿化文を元の形式に戻すことにより平文に置き換える手順；
−「暗号化」"enciphering" 、メッセージまたはメッセージの一部分から秘匿化文を決定する手順、この秘匿化文は平文に対する置き換え（秘匿化 encryption）または署名（認証 authentication）として使用される；
−「復号」"decipherment" 、秘匿化文から平文を少なくとも部分的に再構築する手順、これはテキストを含むメッセージの出所および完全性を証明するため（認証 authentication）、あるいは秘匿化文を平文に置き換えるため（復号 decryption）に行われる；
−「安全保護」"securing"、これは認証または秘匿化の目的でメッセージまたはその一部分を暗号化する手順；
−「識別」"identification"、メッセージの出所および完全性（認証）またはその内容（復号）により、メッセージ識別のためにメッセージにおいて受け取った秘匿化文を使用する手順である。
【００１８】
本発明は一般に、電子署名・電子認証および／または秘匿化のための暗号化・秘匿解除のための復号を使用するセキュリティプロセスに適用される。このセキュリティプロセスは伝送時には暗号鍵を使用し受信時には暗号鍵および／または復号鍵を使用することに基づいており、この場合、復号鍵は秘匿解除のためにインプリメントされ、復号鍵および／または暗号鍵は認証のためにインプリメントされる。
【００１９】
本発明の適用事例の有利な分野はディジタルテレビジョンであり、たとえばオーディオビジュアルデータのブロードキャスト、ＰＳＩ（Program Specific Information）、ＳＩ（Service Information）、インタラクティブデータ、シグナリングデータまたはプライベートデータのためのものである。殊にいくつかのディジタルブロードキャストネットワークやリターンチャネルをもついくつかのネットワークたとえば地上波およびマイクロ波周波数のネットワークは、不正行為たとえばスプーフィング spoofing に脆弱である。この場合、不正行為として挙げられるのはデータの傍受、それらの改竄および改竄したデータのブロードキャストまたはネットワークへの流し込みなどである。殊に有用な適用事例は電子商取引やホームバンキングである。
【００２０】
この目的で本発明は、可変の現在の識別鍵によりメッセージの識別をコントロールする手段を有する少なくとも１つの受信装置へネットワークを介して発送するためのメッセージを保護するセキュリティデバイスに関する。本発明によるセキュリティデバイスは以下のユニットを有している：
−可変の現在の暗号鍵を用いてメッセージ各々の少なくとも一部分に対する暗号化をコントロールするユニット；
現在の暗号鍵を変更するユニット、このユニットは使用可能な複数の暗号鍵から成るまえもって決められたセットから暗号鍵を選択するよう設計されている；
−メッセージに鍵識別子を登録するユニット、このユニットにより受信装置は、使用可能な複数の暗号鍵から成るまえもって決められたセットに対応する使用可能な複数の識別鍵から成るまえもって決められたセットから現在の識別鍵を選択できるようになり、この鍵識別子によって受信装置は、現在の識別鍵が現在の暗号鍵と一致するようこの現在の識別鍵を変更できるようになる。
【００２１】
本発明によればこのセキュリティデバイスには、メッセージの各々に対する現在の暗号鍵を用いたメッセージの一部分の暗号化の結果から成る署名の付加をコントロールする手段が設けられており、メッセージはサービス通知メッセージである。
【００２２】
ここで用語「サービス通知メッセージ」"service announcement message"とは、あるサービスの枠組みの中で上流に発送されるメッセージのことであり、これによってこのサービスにおける１つまたは複数の別のメッセージの後続の発送に関する情報および命令が与えられる。これら他のメッセージはコンテンツ（「コンテンツメッセージ」"content message"）または即時トリガ命令（「トリガ」"trigger"）のベアラである。有利な実施形態によればサービス通知メッセージは、ＳＡＰ（Session Announcement Protocol）フォーマットのヘッダとＳＤＰ（Session Description Protocol）フォーマットのペイロードを有している。
【００２３】
ＡＴＶＥＦ仕様（つまりAdvanced Television Enhancement Forum 標準に準拠した仕様）によれば、オプションとしてサービス通知メッセージに認証フィールドが設けられる。
【００２４】
上述のように用語「識別」鍵によって表されているのは、セキュリティデバイスにより使用された暗号鍵にそれぞれ対応づけられた復号鍵または秘匿解除鍵のことである。秘匿解除のためには識別鍵のセットは暗号鍵のセットであり、各暗号鍵は秘匿化に使用された対応する暗号鍵と同じ長さを有している。
【００２５】
認証のためにはこのセットは復号鍵、暗号鍵または両方のタイプの鍵の組み合わせから成り、これらはそれぞれ伝送時の対応する暗号鍵から生成される。この場合、受信側によって使用される各認証鍵および殊にほとんどの暗号鍵は有利には、署名生成のためセキュリティデバイスにより使用される対応する暗号鍵よりも著しく短い。殊に、署名を完全に秘匿解除したり再構築したりする必要がない。メッセージの認証を保証するためには部分的な一致で十分である。したがって認証オペレーションは単純化され、複数の暗号鍵から成る識別鍵について、受信側への伝送時に使用された暗号鍵全体がブロードキャストされないことから、署名が不正に生成されるリスクが低減される。
【００２６】
受信側においていわば即時的に所望の識別鍵を正確に得るために、単純な識別子の発送で十分である。この結果は、それぞれ伝送側と受信側において使用可能な複数の鍵から成る２つの対応するセットをまえもって記録し、それらの鍵をインデックス化しておくことにより達成される。しかしながら意外なことに、アメリカ合衆国特許 US-5,222,137のように伝送された情報の保護がコンテンツメッセージの秘匿化、ならびに同一の送信／受信システム（ラジオ）に同一の鍵のセットを設けることには基づいていない。本発明のセキュリティデバイスは実践において、完全に非対称であってよい送信側デバイスと受信側デバイスとの間のサービス通知メッセージに適用される認証プロセスにインプリメントされる。
【００２７】
本発明によるデバイスはことごとく予想外のものであり、それというのもインタラクティブテレビジョンの世界で使用されるフォーマットたとえばＡＴＶＥＦおよびＭＨＰ（Multimedia Home Platform）標準はサービス通知メッセージの中に、この通知メッセージの署名の計算を可能にする鍵識別子を組み込む可能性をサポートしていないからである。たとえばＡＴＶＥＦの例であれば、Session Announcement Protocol, RFC 2974に関して進行中のＲＦＣ（Request For Comment）ドキュメントの規定によれば、認証に関する情報のない通知メッセージにおいて署名を計算することによりサービス通知メッセージを署名することが可能であると規定されている。
【００２８】
ＭＨＰ標準それ自体は、どのようにしてアプリケーションおよびブロードキャストデータを認証すべきか、およびリターンチャネルに伝送されたデータをどのようにして保護すべきかを規定している。しかしこれによっても、サービス通知メッセージの機能を果たすシグナリングメッセージの認証については呈示されていない。したがって本発明のデバイスは基本的に、主体が受け取った知識に反する動作をする。
【００２９】
このような解決手段により受信側のレベルにおいて、通知されたサービスが有効ではないとき、そのサービスのメッセージについてコンテンツメッセージまたはトリガタイプを不必要に考慮しなくてもよくなる。このため受信側はいっそう扱いやすくなり、システムの信頼性や安全性について妥協することなく演算やメモリスペースの不必要な消費が切り詰められる。
【００３０】
しかもコンテンツメッセージの秘匿化によってさらに別の可能性が生じ、これはいくつかの事例では望ましいとされるかもしれないが、たいての状況では絶対に必要というわけではない。権限のないサービス（認証されていないサービス通知メッセージ）ばかりか有効なサービスにも関する処理コストやメモリスペースコストは、このような秘匿化がなければ回避される。
【００３１】
本発明によるデバイスによれば、いずれかのメッセージまたは所定のタイプのメッセージの発送に応じて鍵の変更に対する権限が付与される。鍵の識別の最初の形態によれば鍵識別子がいずれかのメッセージに付加され、これは鍵変更の主体を成すことができる。ついで受信側におけるこのインジケータに対応する鍵が、識別子に基づきシステマティックに選択されて識別に使用される。鍵の識別の第２の実施形態によれば、鍵識別子が鍵変更バイナリインジケータによって補われる。その後、受信側において、鍵変更インジケータが鍵の変更を通報するまで現在の識別鍵がメモリ内に保持される。識別鍵の第３の実施形態によれば、鍵識別子は鍵が実際に変更される場合にのみ指定される。さもなければ鍵識別子はデフォルト値（たとえば０）に置き換えられ、これによっていままで使用されていた鍵が依然として有効であることが通報される。この第３の経済的な形態が有利である事例は、メッセージを常にリスニングしておりいかなるメッセージも見落とさない複数の受信側の集合にメッセージが送信される場合である。この場合、たとえばＷｅｂを介したマルチキャストに適用できる。
【００３２】
変更の頻度と実行される鍵の選択の両方に関して、鍵識別子を様々なやり方で決めることができる。したがって変更に関する第１の実施形態によれば鍵識別子が変更されるのは、伝送側のユーザでありつまり変更の発生も選択される新たな鍵もともに決定できるユーザによって要求されたときである。変更に関する第２の実施形態によれば鍵識別子は、ユーザによって選ばれた周期に従って周期的に変更され、新たな鍵識別子がランダムに決められる。変更に関する第３の実施形態によれば鍵識別子は、ランダムに選択されるが最短期間と最長期間の間に位置する期間だけ間隔のとられた時点で、まえもって決められた一連の値に従い変更される。変更に関する第２および第３の実施形態の場合、どんなやり方でもいかなる時点でも現在の鍵を変更可能なシステムを採用しているユーザにとって望ましい。
【００３３】
伝送時および受信時の鍵は秘密鍵であってもよいし公開鍵であってもよい。有利であるのは、送信側の身元が保証されるよう伝送時の鍵を秘密鍵とし、受信側の鍵を公開鍵とすることである。なお、サービスにおける後続のコンテンツメッセージの秘匿化を利用して補足的なセキュリティを実施するのであれば、メッセージの機密性が保証されるようこの秘匿化のための受信側の鍵を秘密鍵とするのが有利である。
【００３４】
さらに有利であるのは暗号化コントロールユニットが、使用可能な暗号鍵が格納されている暗号化ライブラリを呼び出すことである。
【００３５】
有利であるのは、使用可能な複数の識別鍵から成るまえもって決められたセットを複数の復号鍵から成るセットとすることである。
【００３６】
さらに有利であるのは、暗号化すべきメッセージの一部分が署名を差し引いたメッセージ全体から成り、これには鍵識別子が含まれている。したがって認証は送信側の身元およびメッセージのペイロードに関係するだけでなく、もっと広くメッセージ内に含まれる情報すべてに関係し、これには識別鍵の選択および受信側レベルにおけるあらゆる動作パラメータも含まれる。
【００３７】
１つの有利な実施形態によれば、本発明のセキュリティデバイスはメッセージを秘匿化することができ、この機能は有利には認証済みサービス通知メッセージに続くコンテンツメッセージに適用される。この場合、暗号鍵について有利であるのは、サービス通知メッセージの認証に採用されたのと同様のモードに従い識別されるようにすることである。さらに有利にはヘッダとペイロードを有する秘匿化すべきメッセージ各々ごとに暗号化コントロールユニットは以下のことをコントロールするように設計されている：
−現在の暗号鍵により秘匿化すべきメッセージの一部分の暗号化、この部分は少なくともペイロードの一部分を有する；
−この部分のメッセージにおいて、現在の暗号鍵によるこの部分の暗号化の結果から成る秘匿化情報による置き換え。
【００３８】
この実施形態の変形によれば、サービスにおいて認証済みサービス通知メッセージに続く秘匿化すべきメッセージの２つのレベルの暗号化が以下のようにして行われる：
−使用可能な複数の鍵から成る第１のセットから選択された現在の鍵を用いた秘匿化；
−使用可能な複数の鍵から成る第２のセットから選択された現在の認証鍵を用いた署名、認証のための暗号化は署名を除いたメッセージ全体に適用するのが有利であり、これには秘匿化部分が含まれる。
【００３９】
１つの有利な適用形態によればサービス通知メッセージは少なくとも、ＡＴＶＥＦ通知メッセージおよび／またはシステム通知メッセージの中から選択される。
【００４０】
１つのサービスにおける各ＡＴＶＥＦ通知メッセージには、１つまたは複数のサービストリガによる（HyperText Transfer Protocol方式に従った）少なくとも１つのＨＴＴＰコンテンツメッセージが続く。１つのサービスにおけるシステム通知メッセージ（これは一般に非公開およびマルチキャスト）自体には、そのサービスのバイナリファイルが続く。システム通知メッセージは有利には、ＡＴＶＥＦ通知メッセージと同様の形態をもっている。サービス通知メッセージの利用に関してＡＴＶＥＦ通知メッセージとは別の詳細な説明は、出願番号00402921.1をもつ２０００年１２月２３日出願のヨーロッパ特許出願および出願番号EP/01/12333をもつそのＰＣＴ出願に示されている。
【００４１】
可変長の認証フィールドをもつサービス通知メッセージ各々ごとに有利には登録ユニットは、この認証フィールドに鍵識別子を登録するように設計されている。この実施形態はその単純さの点で有利である。それというのもこのことによって、特別なフィールドを追加することなくサービス通知メッセージにすでに設けられているフィールドを非常にフレキシブルに利用できるようになるからである。
【００４２】
ＡＴＶＥＦおよびシステム通知メッセージ以外の有利な適用形態によればサービス通知メッセージは少なくとも、ＭＨＰシグナリングメッセージの中から適用される。
【００４３】
第１の鍵認識形態によれば鍵識別子各々は、使用可能な複数の鍵のうち決められた１つの暗号鍵と、使用可能な複数の識別鍵のうちこの暗号鍵に対応する１つの識別鍵とに対応づけられる。
【００４４】
したがって受信側で使用すべき鍵は、選択された鍵識別子により１対１形式で与えられる。この実施形態によれば、メッセージの出所と完全性の保証を迅速に成功させることができる。
【００４５】
第２の鍵認識形態によれば鍵識別子各々は、使用可能な複数の暗号鍵から成るセットの中から決定された暗号鍵ブロックと、使用可能な複数の識別鍵から成るセットの中からそれぞれ暗号鍵に対応して決定された識別鍵ブロックとに対応づけられる。
【００４６】
したがって選択される鍵識別子によっても、受信側は使用すべき識別鍵を即座に知ることはできない。この場合、意図するブロックの様々な鍵を用いて適切なものが得られるまで連続的なテストを実行しなければならない。したがってこの実施形態によれば、複雑さおよび認証または復号に要する期間が増大するにしても、不正行為に対する付加的な保護が提供される。
【００４７】
有利には登録ユニットは、（場合によっては複数の鍵または鍵ブロックに対応する）８〜１２の間に位置する個数の値有利には１０と等しい個数の値の中から鍵識別子を選択するように設計されている。セキュリティを強める別の実施形態によれば、この値の個数は２５６（１バイトをもつ識別子のコーディング）であり、あるいは６５５３６（２バイトのコーディング）であってもよい。
【００４８】
これに加えて、伝送時および受信時の鍵を更新できると有利である。たとえば複数の識別鍵から成るセットは、受信側をサーバと接続し、受信側により識別し、識別鍵テーブルをネットワークを介して安全に取り出すことによって遠隔に変更されるように設計されている。
【００４９】
本発明をさらにメッセージの送信装置にも適用できる。本発明によれば送信装置は、本発明の複数の実施形態のうちの１つに従って構成された少なくとも１つのセキュリティデバイスを有しており、この送信装置は有利にはブロードキャストによりメッセージを送信するように設計されている。
【００５０】
ここで用語「ブロードキャスト」とは、それがたとえば無線ブロードキャストまたはケーブルあるいはインターネットによってなされようが、同一のデータが複数の宛先の集合へ伝送されることを表す。
【００５１】
本発明はさらにネットワークを介して受信されるメッセージを識別するデバイスに関し、この場合、メッセージ各々には変更可能な現在の暗号鍵を用いて暗号化された部分が含まれている。この識別デバイスは以下のユニットを有している：
−変更可能な現在の識別鍵により暗号化された部分の識別をコントロールするユニット；
−このメッセージから鍵識別子を抽出するユニット、これにより現在の識別鍵を、使用可能な複数の暗号鍵から成るまえもって決められたセットに対応する使用可能な複数の識別鍵から成るまえもって決められたセットから、この現在の識別鍵が現在の暗号鍵と一致するよう選択できるようになる。
【００５２】
本発明によれば識別コントロールユニットは暗号化部分の識別をコントロールするユニットであり、この暗号化部分は現在の署名であり、メッセージはサービス通知メッセージである。
【００５３】
メッセージを識別するデバイスは有利には、本発明に従って構成されたセキュリティデバイスのいずれか１つの実施形態を用いて安全に保護されたメッセージを識別することができる。
【００５４】
本発明はさらにメッセージの受信装置にも適用される。本発明によればこの受信装置は、本発明の実施形態のいずれか１つに従って構成された少なくとも１つの識別デバイスを有している。さらにこの受信装置は有利には、本発明に従って構成されたメッセージ送信装置から発せられたメッセージを受信するように設計されている。
【００５５】
本発明はさらにコンピュータプログラム製品に関する。本発明によればこの製品は、本発明の実施形態のいずれか１つに従って構成されたメッセージを保護するセキュリティデバイスまたはメッセージを識別するデバイスにおけるユニットをインプリメントする機能を有している。
【００５６】
ここで「コンピュータプログラム製品」という用語の意味するコンピュータプログラム媒体は、ディスクやカセットなどのようにプログラムを含む記憶スペースによって構成できるだけでなく、電気的な信号または光学的な信号のような信号によっても構成可能である。
【００５７】
本発明はさらに、ネットワークを介して少なくとも１つの受信側へ発送すべきメッセージにも関する。このメッセージには以下のものが含まれている：
−それぞれ少なくとも１つの変更可能な現在の暗号鍵によって暗号化された少なくとも１つの部分；
−少なくとも１つの鍵識別子、これにより現在の識別鍵を、使用可能な複数の識別鍵から成るまえもって決められたセットからそれぞれ選択できるようになり、この現在の識別鍵によってそれぞれ暗号化された部分を識別できるようになる。
【００５８】
本発明によれば暗号化部分は署名であり、メッセージはサービス通知メッセージである。
【００５９】
このメッセージは有利にはメッセージを保護するセキュリティデバイスによって得られ、有利には本発明の実施形態のいずれか１つに従って構成されたメッセージ識別デバイス向けのものである。
【００６０】
本発明の別の観点として挙げられるのはセキュリティプロセスであり、このセキュリティプロセスによれば、変更可能な現在の識別鍵による識別コントロール手段をもつ少なくとも１つの受信装置へネットワークを介して発送すべきメッセージが保護される。このセキュリティプロセスは以下のステップを有する：
−使用可能な複数の暗号鍵から成る少なくとも１つのまえもって決められたセットから現在の暗号鍵を選択するステップ、これによりメッセージ各々の少なくとも一部分を暗号化することができる；
−このメッセージに鍵識別子を登録するステップ、これにより受信側は、使用可能な複数の暗号鍵から成るまえもって決められたセットに対応する使用可能な複数の識別鍵から成るまえもって決められたセットから、現在の識別鍵を選択することができ、この鍵識別子によって受信側は現在の識別鍵を、この現在の識別鍵が現在の暗号鍵に対応するよう変更できるようになる；
−現在の暗号鍵により暗号化すべきメッセージの一部分を暗号化するステップ。
【００６１】
本発明によれば暗号化ステップはこの部分の署名を生成することから成り、この場合、メッセージはサービス通知メッセージである。
【００６２】
メッセージを保護するセキュリティプロセスは有利には、本発明の１つの実施形態に従って構成されたメッセージを保護するセキュリティデバイスによってインプリメントされる。
【００６３】
さらに本発明はネットワークを介して受信されるメッセージを識別するプロセスに関し、これらのメッセージの各々は変更可能な現在の暗号鍵を用いて暗号化された部分を有する。この識別プロセスは以下のステップを有する：
−鍵識別子をこのメッセージから抽出するステップ、これによれば現在の識別鍵は使用可能な複数の識別鍵から成るまえもって定められたセットから選択され、現在の識別鍵は現在の暗号鍵に対応する；
−現在の識別鍵を用いて暗号化された部分を識別するステップ。
【００６４】
本発明によれば暗号化部分は署名であり、メッセージはサービス通知メッセージである。
【００６５】
メッセージを識別するプロセスは有利には、本発明の実施形態のいずれか１つに従って構成されたメッセージ識別デバイスを用いてインプリメントされる。
【００６６】
次に、添付の図面を参照しながら実施形態に基づき本発明について詳しく説明する。なお、本発明はこれらの実施形態に限定されるものではない。
【００６７】
図１は、第１の鍵選択形態を実装した本発明によるメッセージの送信側および受信側を示す基本構成図である。
【００６８】
図２は、認証に利用可能な図１の送信側の第１の実施形態について詳細に示す図である。
【００６９】
図３は、図２の送信側により発送される認証フィールドを含むＡＴＶＥＦサービス通知メッセージの内容を示す図である。
【００７０】
図４は、図３の認証フィールドの内容を詳細に示す図である。
【００７１】
図５は、認証フィールドが埋められた状態で図２の送信側により生成されたメッセージの中間バージョンの内容を示す図である。
【００７２】
図６は、図２に示した送信側を伴う中央サーバによりコントロールされる無線ブロードキャストタイプのブロードキャスタセットを示す図である。
【００７３】
図７は、図２の送信側と組み合わせてＡＴＶＥＦサービスメッセージの認証に利用可能な図１の受信側の第１の実施形態について詳細に示す図であるが、この場合にはシステムサービスメッセージの認証にも復号にも利用できる。
【００７４】
図８は、暗号化と認証の組み合わせに利用可能な図１の送信側における第２の実施形態について詳細に示す図である。
【００７５】
図９は、図８の送信側によって発送される認証フィールドと暗号化フィールドを含むＡＴＶＥＦサービス通知メッセージの内容を示す図である。
【００７６】
図１０は、図１の送信側の変形実施形態として用いられる鍵のブロックを伴う第２の鍵選択形態を実装する署名ライブラリを示す図である。
【００７７】
図１１は、図１の受信側の変形実施形態として使用され図１０のライブラリに対応する鍵ブロックを伴う認証ライブラリを示す図である。
【００７８】
図１２は、図２の送信側により発送される認証フィールドを含むＡＴＶＥＦサービス通知メッセージの変形実施形態の内容を示す図である。
【００７９】
図１３は、図１２による認証フィールドの内容を詳細に示す図である。
【００８０】
これらの図面は本願開示に不可欠な部分であるとみなされるものである。
【００８１】
図中、同じ要素または類似の要素には同じ参照符号が付されている。さらに図示されている後述の各機能的エンティティが必ずしも物理的にシステムのそれぞれ異なるエンティティに対応していなくてもよく、たとえば同一コンポーネントのソフトウェアまたは回路における同一部分の機能によって構成してもよい。また、図３〜図５および図９、図１２ならびに図１３において示されている数字は、表されるメッセージ中のフィールドの配分をビットで示すものである。さらに添字ＡとＣは認証エンティティを表すために使われ、添字Ｂは暗号化エンティティのために、添字Ａ′は暗号化後の認証エンティティのために使われる。
【００８２】
送受信システム（図１）は、ネットワーク５を介して１つまたは複数の受信装置２へＭＳＧメッセージを送るための１つまたは複数の送信装置１を有している。以下で詳述する実施例の場合、ネットワーク５はブロードキャスト双方向伝送ネットワークであり、ここでは（それぞれ受信装置２を伴う）複数の顧客に送信を行う（送信装置１を伴う）ブロードキャストサーバについて考察する。簡単にするため、ここでは複数の送信装置１のうちの１つと複数の送信装置２のうちの１つについてのみ考察する。
【００８３】
概略的にいえば送信装置１は、メッセージＭ０を受け取りそのメッセージを送信すべきメッセージＭＳＧに変換し、その際にネットワーク５を介して伝送するためのおよびメッセージＭＳＧと場合によっては後続のメッセージを適切な受信装置２が読み取るための種々の情報項目を付加する。これに応じて受信装置２は受け取ったメッセージＭＳＧから、メッセージＭ０によって表される意味のある内容を抽出する。メッセージＭ０は有利にはある固有のタイプのメッセージであり、後述のように送信装置１と受信装置２はすべてのメッセージタイプを同じように処理するわけではない。
【００８４】
送信装置１はたとえば（図１に示されているように）、メッセージＭ０を上述のように変換する目的で様々な要素を有しており、たとえばそれらは以下のようなものである：
−パーミッション識別子ＰＥＲＭをメッセージＭ０に挿入するよう設計されたパーミッション登録用ユニット１４；上述のパーミッション識別子ＰＥＲＭによって、受信装置の様々な機能をアクセスするため受信装置に対して制御命令を送信できるようになる。
−メッセージを安全に保護するためのデバイス３、その目的はメッセージＭ０の少なくとも一部分の暗号化（署名または秘匿化）について判断力のあるモードを規定すること、この暗号化をトリガして受信装置２のために暗号化部分を利用するための情報をメッセージＭ０に挿入することである；選ばれた例では送信装置１において登録ユニット１４はセキュリティデバイス３の上流にあり、変形実施例としてこれらのポジションが逆にされるまたは、これら２つのサブシステムのうち少なくとも一方が送信装置１の上流におかれる；
−暗号化ライブラリ１５、たとえばダイナミックリンクライブラリまたはＤＬＬ（Dynamic Link Library）、これは暗号化モジュール１７を有しており、厳密な意味では実際には送信側により簡単にアクセス可能なプログラムとすることができるけれども、一般にこのライブラリ１５は送信装置１に配分されている。
【００８５】
さらに詳しく説明すると、暗号化ライブラリ１５には暗号鍵Ｋ１，Ｋ２〜Ｋｎのインデックス化テーブル１６が設けられており、暗号化モジュール１７はメッセージを保護するためのセキュリティデバイス３によって与えられる命令に依存して、暗号鍵Ｋｉのうちの１つに従い暗号化を実行する。さらにセキュリティデバイス３は以下のユニットを有している：
−暗号化モジュール１７をトリガ可能な暗号化コントロールユニット１１、これは必要とされる情報を暗号化モジュール１７に伝えることにより行われ、詳しくは使用すべき暗号鍵Ｋｉの選択を考慮することにより行われる；
−現在の鍵を変更するためのユニット１２、これによって使用すべき現在の鍵Ｋｉを暗号化コントロールユニット１１に相応の情報を発送することで変更できるようになる。このユニット１２はたとえば、ユーザが直接介在可能な現在の鍵Ｋｉの（実現値と選択値の双方について）ランダムな変更に基づくものである；
−メッセージＭ０に鍵識別子ＫｅｙＩＤを登録するためのユニット１３、これによって受信装置２の注意喚起のため選択された現在の鍵Ｋｉを指示できるようになる。ここで示されている実施例の場合、この登録ユニット１３は関与しているタイプのメッセージＭ０における鍵識別子ＫｅｙＩＤの登録を決まった手順で実行する。
【００８６】
同様に、受信装置２は詳細には以下のユニットを有している：
受け取ったメッセージＭＳＧ内のパーミッション識別子ＰＥＲＭを読み取るユニット２４；
（認証のための復号／暗号化または復号により）メッセージＭＳＧにおける暗号化部分の関連する識別モードを規定するため、メッセージを識別しこの識別をトリガするデバイス４；
識別ライブラリ２５、これは識別モジュール２７を有しており、一般に受信装置２に配分される。
【００８７】
さらに詳しく説明すると、識別ライブラリ２５には識別鍵Ｋ′１，Ｋ′２〜Ｋ′ｎのインデックス化テーブル２６が設けられており、これは暗号化ライブラリ１５の暗号鍵Ｋ１，Ｋ２〜Ｋｎにひとつずつ対応している。識別モジュール２７は、メッセージ識別デバイス４により与えられる命令に依存して識別鍵Ｋ′ｉのうちの１つに従い識別を実行するよう設計されている。さらにメッセージ識別デバイス４は以下のユニットを有している：
−識別モジュール２７をトリガ可能な識別コントロールユニット２１、これは必要とされる情報を識別モジュール２７に伝えることにより行われ、詳しくは使用すべき鍵Ｋ′ｉの選択を考慮することにより行われる；
−メッセージＭＳＧから鍵識別子ＫｅｙＩＤを抽出するためのユニット２３、これにより送信装置２の現在の暗号鍵Ｋｉに応じて選択された現在の識別鍵Ｋ′ｉが与えられる。
【００８８】
上述の簡単な説明は本質的に機能的であり、もっぱらメッセージを安全に保護し識別するための固有のシステムと関連した特徴の中心にある。実際には送信装置１に、場合によっては組み合わせで参照符号１５が付されているような複数のセキュリティデバイスをもたせることができる。たとえばメッセージの安全な保護が秘匿化と署名を合わせもつようにし、および／または異なるタイプのメッセージに対しそれぞれ別個のデバイスが適用される。同様に、受信装置２に複数の識別デバイスをもたせることができる。このような可能性については個々の実施形態を参照しながらあとで詳しく説明する。
【００８９】
参照符号１Ａ（図２）の付された送信装置１における第１の実施形態は認証に適用される。この実施形態によれば送信装置１Ａは、パーミッション識別子ＰＥＲＭを安全に保護し登録するためのオペレーションのためにはサービス通知メッセージ service announcement message Ｍ０だけしか必要とせず、（コンテンツメッセージやトリガなどのような）他のタイプのメッセージはここでは必要とされない。考慮されるサービス通知メッセージの例はＡＴＶＥＦ通知メッセージ ATVEF announcement message あるいはシステム通知メッセージ system announcement messageであって、これら２つのタイプのメッセージは考察中の実施例では同様の構造をもっている。生成されるメッセージＭＳＧ（参照符号ＭＳＧ−Ａ）はネットワーク５を介してブロードキャストされる。
【００９０】
前述の実施例の場合、暗号鍵Ｋｉ（署名鍵）は秘密鍵であり、識別鍵Ｋ′ｉ（認証鍵）は顧客に配布してよい公開鍵であって、これは場合によってはネットワーク５を介して行われる（このとき伝送を安全に保護すると有利である）。さらに特別な実施形態の場合、署名鍵Ｋｉは各々５９６ｂｙｔｅを有しており、識別鍵Ｋ′ｉは各々１４８ｂｙｔｅの復号鍵であり、これらの鍵はそれぞれ署名鍵Ｋｉから生成され、顧客の中に存在するよう伝送される。それぞれ署名鍵と認証鍵各々のインデックス化テーブル１６，２６は、たとえば１０個の対応する鍵を有している。
【００９１】
送信装置１Ａには基本的に以下のものが設けられている：
参照符号３１Ａの付されたサーバドライブシステム３１、これには現在の鍵を変更するためのユニット１２と、鍵識別子ＫｅｙＩＤを登録するためのユニット１３と、パーミッション識別子ＰＥＲＭを登録するためのユニット１４が含まれている。このドライブシステム３１Ａは、情報源１０からメッセージＭ０を取り出してメッセージＭ１を生成するように設計されており、このメッセージには参照符号ＫｅｙＩＤ［ＳＧＮ］で表される認証用鍵識別子ＫｅｙＩＤとパーミッション識別子ＰＥＲＭが含まれているが署名はない；
ブロードキャストサーバ３２Ａ、これにはたとえばサーバ３２Ａのすべての要素の動作をコントロールするコントロールユニット３７（見やすくするため図２には接続関係は示されていない）と、ドライブシステム３１Ａから発せられたメッセージＭ１を収集するよう設計されたデータベース３３が含まれており、このブロードキャストサーバ３２ＡはメッセージＭ１をメッセージＭＳＧ−Ａに変換するために用いられる；
認証ライブラリ１５Ａの形式をとる暗号化ライブラリ１５。
【００９２】
ブロードキャストサーバ３２Ａは、メッセージＭ１に対して連続的に動作する２つのモジュールすなわち仕上げモジュール３５とカプセル化モジュール３６を有している。認証コントロールユニット１１Ａの形態の暗号化コントロールユニット１１を含む仕上げモジュール３５の役割は、補足情報（インターネットアドレス、ポート等）をメッセージＭ１に登録してメッセージＭ２を生成すること、認証ライブラリ１５Ａを呼び出し署名ＳＧＮを生成してメッセージにＭ２に組み込み、それによってメッセージＭ３を生成することである。認証ライブラリ１５Ａにディスパッチされる認証鍵識別子ＫｅｙＩＤ［ＳＧＮ］がメッセージＭ２内に存在することで、認証ライブラリ１５Ａは即座に望ましい鍵Ｋｉを選択して署名ＳＧＮを生成できるようになる。有利には現在の暗号鍵Ｋｉはライブラリ１５Ａ内に保持される。
【００９３】
ブロードキャストサーバ３２Ａがライブラリ１５Ａに対し署名を下請けに出すこと、ならびに現在の鍵Ｋｉをサーバ３２Ａではなくライブラリ１５Ａに記録できることによって、サーバ３２Ａは一般的な特性を維持することができる。そのうえ重要であるのは、上述のことでドライブシステム３１Ａとライブラリ１５Ａがともに、鍵識別子ＫｅｙＩＤ［ＳＧＮ］とパーミッション識別子ＰＥＲＭに関するオペレーションのコントロールを保有できることである。しかも有利であるのは、一連の流れの最後に署名ＳＧＮが付加され、これがブロードキャストサーバ３２Ａによりブロードキャストされる直前に行われることである。なぜならば、このことで署名ライブラリ１５Ａと暗号鍵Ｋｉを複製する必要なく非常に多くの顧客によって署名を供給することができるからであり、かつ鍵識別子ＫｅｙＩＤ［ＳＧＮ］の変更を集中化させることができるからである。さらに圧縮および／または秘匿化が行われる場合、それらのオペレーションの後に署名が付けられる。
【００９４】
署名ＳＧＮは有利には通知メッセージＭ２全体にわたり計算される。ここでメッセージＭ２にはヘッダ（これは殊に識別子ＫｅｙＩＤ［ＳＧＮ］とＰＥＲＭを有する）とペイロードが含まれており、これによってたとえば現在の鍵ＫｅｙＩＤ［ＳＧＮ］（したがって顧客による認証用）とパーミッションに関するデータに対するどのような外部の変更も検出できる。
【００９５】
カプセル化モジュール３６は、ネットワーク５を介した伝送用の階層のカットおよび付加により通知メッセージＭ３を伝送するためのものである。ここに示されている実施例の場合、モジュール３６はＩＰ（Internet Protocol）パケットをＵＤＰ（Unidirectional Data Protocol）／ＩＰ／ＳＬＩＰ（Serial Line IP）層によって生成する。コンテンツメッセージのためにモジュール３６はあらかじめ、ＵＨＴＴＰ（Unidirectional HyperText Transfer Protocol）プロトコルとＭＩＭＥ（Multipurpose Internet Mail Extensions）フォーマットを利用する。
【００９６】
このため署名されたメッセージＭＳＧ−Ａにより顧客各々は、提供されるサービスの真正性を照合することができる。つまり顧客が署名ＳＧＮを有効であると認めれば、顧客はコンテンツメッセージおよび場合によってはそれに続くべきトリガのためのリスニングチャネル（ソケット）をオープンする。有効であると認められなければ、顧客は通知メッセージＭＳＧ−Ａを考慮に入れず拒否する。署名ＳＧＮを認証するため顧客は鍵識別子ＫｅｙＩＤ［ＳＧＮ］を使用し、これによって顧客は適切な識別鍵Ｋ′ｉを対応する識別ライブラリ２５（認証ライブラリ）から即座に選択することができる。したがって顧客はソケットをオープンすべきか否かを迅速に判定することができ、そのため順次到来するコンテンツパケットのすべてあるいはいくつかが失われてしまうのを回避できる。たとえば第１のコンテンツパケットが通知メッセージ後５００ｍｓのときにブロードキャストされたならば、署名照合ならびにソケットオープンオペレーションをこの期間中に実行完了させることが必須である。
【００９７】
以下、送信装置１Ａにおける１つの固有のインプリメンテーションについて挙げておく。この実施例の場合、ＡＴＶＥＦタイプの通知メッセージＭＳＧ−ＡはマルチキャストＩＰアドレス２２４．０．１．１１３、ポート２６７０でブロードキャストされ、システムタイプの通知メッセージはマルチキャストＩＰアドレス２３５．０．１．１１３、ポート３２６７０でブロードキャストされる。メッセージＭＳＧ−Ａ（図３）の各々は、参照符号ＳＡＰ−Ａの付されたＳＡＰフォーマットのヘッダとＳＤＰフォーマットのペイロードから成り、この場合、ヘッダＳＡＰ−Ａは以下のフィールドによって構成されている：
−ＳＡＰのバージョンＶ（３ｂｉｔ，Ｖ＝１）
−５項目から成るＡＲＴＥＣ（５ｂｉｔ）
−アドレスタイプＡ（ＩＰｖ４プロトコルは１、ＩＰｖ６プロトコルは０）；
−予約フィールドＲ（０）;
−メッセージタイプＴ（セッション通知パケット０、セッション保証パケット１）；
−暗号化フィールドＥ（「暗号化」について：ＳＤＰ非暗号化は０、ＳＤＰ暗号化は１）；
−圧縮Ｃ（非圧縮ペイロードは０、圧縮ペイロードは１）；
−認証フィールドＡＵＴＨの長さＬ−ＡＵＴＨ（８ｂｉｔの符号のない値）、認証フィールドには参照符号ＡＵＴＨ−Ａが付されＳＤＰの直前に挿入され３２ｂｉｔワードの数値として表現される；
−ハッシュ識別子（ディジタル署名のためインターネットで用いられる保護アルゴリズム）ＭＳＧ ＩＤ ＨＡＳＨ（１６ｂｉｔ）、ＳＤＰフィールドが変更されるときは常にハッシュ値も変更されなければならない。この識別子が０であれば、顧客は常にＳＤＰに構文解析（パーシング）を受けさせる必要がある；
−送信装置１Ａつまりはブロードキャストサーバ３２ＡのＩＰアドレス、参照符号ＯＲＩＧ（１ワード３２ｂｉｔ）；ハッシュ識別子の値が０でありマンダトリサーバmandatory server（プロキシ）を通過しなければ、このアドレスを０．０．０．０にセットできる；
認証フィールドＡＵＴＨ−Ａ、この長さはパラメータＬ−ＡＵＴＨにより決められる。
【００９８】
認証フィールドＡＵＴＨ−Ａ（図４）は１２８ｂｙｔｅの署名フィールドＳＧＮだけでなく、ＥＮＴ−Ａで表される固有の認証ヘッダも有しており、これは４ｂｙｔｅを占め、以下のサブフィールドを有する：
−使用されるプロトコルのバージョンＶ（３ｂｙｔｅ，Ｖ＝１）；
−パディング識別子Ｐ（１ｂｉｔ）、これはダブルワード（３２ｂｉｔワード）の倍数の全長をもつ認証フィールドで完結させるよう場合によってはパディングが存在することをシグナリングするために用いられる；この実施例の場合、認証フィールドが１３２ｂｙｔｅの全長をもっているためＰ＝０（パディングなし）である；
−使用される認証タイプＴＹＰＥ（４ｂｉｔ）；この事例ではＴＹＰＥ＝０（ＰＧＰフォーマット、Pretty Good Privacyのこと）；
−ＰＥＲＭパーミッションフラグ（８ｂｉｔ）；
−将来の使用のために予約されたフィールド（８ｂｉｔ）；
−鍵識別子ＫｅｙＩＤ［ＳＧＮ］（８ｂｉｔ）。
【００９９】
したがってヘッダＥＮＴ−Ａには、殊に顧客のために使われる２つのバイトが含まれており、すなわちフィールドＫｅｙＩＤ［ＳＧＮ］のバイトとＰＥＲＭのバイトであり、これによってそれぞれ顧客は適切な認証鍵Ｋ′ｉを即座に決定することができ、サービスにおける後続のメッセージ（コンテンツメッセージとトリガ）に関して適切なパーミッションを求めることができる。
【０１００】
この実施例では、パーミッションフラグＰＥＲＭのために利用可能なバイトは８つの値のマスクという形態で利用される。パーミッションフラグＰＥＲＭは、受信装置２におけるいわゆるクリティカルなリソースに関して以下の機能に対するアクセスに関係する（認証値はさしあたり１６進数で与えられる）：
−0x0001：受信装置２のモデムにアクセスして、送信装置１にかかわるサービスオペレータのオンラインサーバとのコネクションを開始させる；
−0x0002：受信装置２のモデムにアクセスして、何らかのサービスオペレータのオンラインサーバとのコネクションを開始させる；
−0x0004：１つのオンラインサーバとの安全なコネクションを利用する；
−0x0008：受信装置２のハードディスクにアクセスして、そこからデータを読み出すかまたはそこに永続的にデータを書き込む；
−0x00010：受信装置２のフラッシュメモリにアクセスして、そこからデータを読み出すかまたはそこに永続的にデータを書き込む；
−0x00020：受信装置２のチップカードにアクセスして、そこからデータを読み出すかまたはそこに永続的にデータを書き込む；
−0x00040：受信装置２のチューナにアクセスして現在の局を変更する。
【０１０１】
１つの変形実施形態によれば、パーミッションに利用可能なバイトは２５６エントリをもつテーブルの形態で使用され、それらのエントリ各々はただ１つのパーミッションレベルに対応している。上述の実施例では８つのパーミッションが得られ、それらを互いに組み合わせることができる。
【０１０２】
パーミッションの個数を難なく増やすことができ、これはたとえば１ｂｙｔｅの予約フィールドをパーミッションフィールドに組み入れたり（１６個のパーミッションへの切り換え）、および／または２つのダブルワードを１つのダブルワードの代わりに認証フィールドＡＵＴＨ−ＡのヘッダＥＮＴ−Ａに割り当てることによって行われる。
【０１０３】
動作中、ドライブシステム３１はＳＡＰフォーマットのヘッダをサービス通知メッセージＭ０に付加し、詳しくはその中にはこのサービスのためのパーミッションフラグＰＥＲＭならびに場合によっては鍵識別子ＫｅｙＩＤ［ＳＧＮ］が組み込まれる（鍵識別子はドライブシステム３１によってコンフィギュレーション可能であるがデフォルトではライブラリ１５Ａによって決められる）。認証フィールドＡＵＴＨ−Ａの長さＬ−ＡＵＴＨは１ダブルワード（Ｌ−ＡＵＴＨ＝１）で固定されており、その中に署名ＳＧＮに伴わずにヘッダＥＮＴ−Ａが登録されるようになる。このようにして得られたメッセージＭ１（図５）には、ＳＡＰフォーマットのヘッダ（ＳＡＰ１で表す）の認証フィールドＡＵＴＨ１（略してＥＮＴ１）内にパーミッションフラグＰＥＲＭと予約フィールドしか含まれておらず、これは０で初期化されている。このメッセージはブロードキャストサーバ３２Ａのデータベース３３で受け取られる。
【０１０４】
ついで仕上げモジュール３５はヘッダＳＡＰ１が存在するか否かを照合し（存在しなければ署名なしでそれを加える）、要求される補足情報（コンテンツメッセージとトリガのアドレスとポートによるＳＤＰのいわゆるパッチ）をＭ１に登録し、ライブラリ１５Ａを呼び出し、引数としてメッセージＭ１を含むバッファメモリとバッファサイズを与える。
【０１０５】
ライブラリ１５Ａは以下のオペレーションを実行する：
−パーミッションフラグＰＥＲＭが存在するか否かの照合；存在するのであれば通常どおりオペレーションが継続され、存在しないのであればエラーコードがブロードキャストサーバ３２Ａに戻される。改善されたバージョンではパーミッションフラグＰＥＲＭが存在していないのであれば、デフォルトマスクが割り当てられる；
−サービス通知メッセージＭ１がすでに署名されているか否かの照合；すでに署名されているならばブロードキャストサーバ３２Ａに戻される；
−まだ署名されていないならば、長さＬ−ＡＵＴＨが１３２ｂｙｔｅ（0x21ダブルワード）に更新され、認証フィールドＡＵＴＨ−ＡのヘッダＥＮＴ−Ａの付加および更新が行われ、（Ｌ−ＡＵＴＨ＝１による）計算ならびに署名ＳＧＮのバッファへの付加ならびにバッファサイズの更新が行われる；署名ＳＧＮはヘッダＳＡＰ１全体（Ｌ−ＡＵＴＨ＝１であるから署名フィールドＳＧＮは含まれない）から、およびメッセージＭ１のペイロードから決定される。これはＲＳＡ（Rivest - Shamir - Adelman）アルゴリズムを用い、さらにこれ全体にわたりハッシュＭＤ５を計算し、適切な現在の鍵Ｋｉを抽出し、その鍵ＫｉでハッシュにおけるＲＳＡ署名の計算を行うことにより得られる。１つの実施形態によれば、認証フィールドＡＵＴＨ−Ａは署名に関して完全に無視される（１つのらブルワードの代わりにＬ−ＡＵＴＨ＝０）；
−ブロードキャストサーバ３２Ａへ戻す。
【０１０６】
次に、カプセル化モジュール３６はこのようにして得られたメッセージＭ３をカプセル化し、その後、ネットワーク５を介してブロードキャストされる。
【０１０７】
この技術によれば、たとえサービスが１つのカルーセルとしてまたは１つのオカレンスとしてディスパッチされる（ワンショット）としても、サービスごとに必ず１回だけ署名が計算される（これは通知メッセージにおいて計算される）。
【０１０８】
鍵識別子ＫｅｙＩＤ［ＳＧＮ］を変更するためメッセージはたとえば、アプリケーションをプログラミングするためのインタフェースあるいはＡＰＩ（Application and Programming Interface）を介してブロードキャストサーバ３２Ａへディスパッチされ、ついでサーバ３２Ａはその識別子の新たな値をライブラリ１５Ａに通知するだけである。この場合、変更はたとえば毎月規則的に実行される。
【０１０９】
以下で例示するブロードキャストサーバ３２Ａの入力（Ｍ１）と出力（ＭＳＧ−Ａ）におけるサービス通知メッセージの例において、ヘッダＳＡＰ１は角括弧の中のボールドのキャラクタで表され、認証フィールド（ＡＵＴＨ１，ＡＵＴＨ−Ａ）のヘッダ（ＥＮＴ１，ＥＮＴ−Ａ）はアンダーラインで、さらにペイロードは通常のキャラクタで表されている（表記は１６進数）。
【０１１０】
L-AUTH＝0x01, PERM＝0x27 および0x00と等しい３つの予約バイトに関してメッセージＭ１は以下の通りである。
【０１１１】
【数１】
【０１１２】
L-AUTH＝0x21, PERM＝0x27, KeyID＝0x07に関して、ブロードキャストサーバ３２ＡによるメッセージＭ０の処理後に得られるメッセージＭＳＧ−Ａは以下の通りである。
【０１１３】
【数２】
【０１１４】
送信装置１Ａ（図６）の固有の実施形態の場合、サービスオペレータの中央ドライブシステム４０は中央サーバ４５を有しており、これは専用リンク（専用回線）４６を介してブロードキャスタ４１，４２，４３と接続されている。また、ブロードキャスタ４１〜４３の各々はあとで詳しく説明するサーバ３２Ａのタイプのブロードキャストサーバ３２と、オーディオビジュアルプログラムをブロードキャストするデバイス４７と、参照符号４８の付されたＶＢＩエンコーダとを有している。ＶＢＩエンコーダの役割は、サーバ３２からの情報とデバイス４７からの情報を符号化すること、ならびにアンテナ４９に向けてそれらの情報をブロードキャストすることである。
【０１１５】
オペレーション中、中央ドライブシステム４０は様々なソース（ブロードキャスタ、アドバタイザ、コンテンツプロバイダ等）からブロードキャストすべきサービスに関する情報を取得し、それらの情報のブロードキャスト動作をプログラムし、ついでブロードキャストされる少し前にブロードキャストサーバ３２がそれらの情報を利用できるようにする。これによって殊に、ディジタル証明書５１，５２，５３がブロードキャスタ４１〜４３へそれぞれ配送されることで公開鍵の真正性が保証される。この中央ドライブシステム４０は上述のドライブシステム３１の機能も果たし、したがってブロードキャスタ４１〜４３によりブロードキャストされるサービス通知メッセージＭＳＧに選択的にパーミッションを与えることができ、受信時の認証において不都合な遅延を引き起こすことなく可変の鍵を用いて署名することができる。
【０１１６】
受信装置２の各々はたとえば以下のものを有している（図７）：
−参照符号６１の付されたＶＢＩドライブ、これは（ブロードキャスタ４１〜４３のような）送信装置１Ａから受信しフィールドＷＳＴ（World Standard Teletext）をもつ情報からペイロードを抽出し、エラーコントロールコードＦＥＣ（Forward Error Correction）を計算し、ペイロードにおけるＳＬＩＰフレームのデコーディングをコントロールするよう設計されている；
ネットワーク５を介して伝送するためにレイヤを非カプセル化するモジュール、これは復号されたＳＬＩＰフレームをドライブ６１から受け取ることができ、復号後、サービス通知メッセージＭＳＧのためのＳＤＰフォーマットのペイロードにおいてＳＡＰフォーマットのヘッダの形式でＩＰ／ＵＤＰフレームの内容を抽出することができる；
−ブラウザ６３、これには上述のタイプの識別デバイス４とパーミッション読み取りユニット２４（それぞれ参照符号４Ｎ，２４Ｎでそれぞれ表す）が設けられている；
−ローダ６７、これには上述のタイプの識別デバイス４とオプションパーミッション読み取りユニット２４（参照符号４Ｃ，２４Ｃでそれぞれ表す）が設けられている；
−参照符号２５の付された上述のタイプの認証ライブラリ、この場合、鍵インデックス化テーブル２６が受信装置２の不揮発性メモリたとえばフラッシュメモリタイプのメモリにライブラリ２５のコードとして格納されている。
【０１１７】
ブラウザ６３は、各サービス通知メッセージＭＳＧ−Ａを受信すると以下の機能を実行するように設計されている：
−リスニングソケット６４を介してメッセージＭＳＧ−Ａのヘッダとペイロードを取り出す；
−入力としてメッセージＭＳＧ−Ａへのポインタを与えることでライブラリ２５における署名照合機能を呼び出す；
−認証が成功したならば、コンテンツメッセージおよび後続のトリガのためにそれぞれリスニングソケット６５，６６をオープンする、これはメッセージＭＳＧ−ＡのパーミッションフラグＰＥＲＭにより表されるパーミッションを適用することにより行われ、ブロードキャストアプリケーションに適用すべきブラウザ６３の機能へのアクセスを指定する。
【０１１８】
ライブラリ２５の署名照合機能により、詳細には以下のオペレーションが実行される：
−署名なしヘッダＳＡＰ−Ａとペイロード全体におけるハッシュＭＤ５の計算、インジケータＬ−ＡＵＴＨによって認証フィールドＡＵＴＨ−Ａの長さが与えられ、これは１にセットされる；署名計算のために指示されるこのフィールドに対応する１つの変形実施形態によれば、認証フィールドＡＵＴＨ−Ａは認証に関して無視され、インジケータＬ−ＡＵＴＨは０にセットされる；
−ヘッダＳＡＰ−Ａの認証フィールドＡＵＴＨ−Ａにおける鍵識別子ＫｅｙＩＤ［ＳＧＮ］を抽出し、適切な認証鍵Ｋ′ｉを選択する；
−ＲＳＡタイプによる認証フィールドＡＵＴＨ−Ａの署名ＳＧＮの照合、これは選択された鍵Ｋ′ｉを用いた署名のハッシュにおける再計算により行われ、署名が無効であれば値０が戻される；
−署名ＳＧＮが有効であれば、パーミッションフラグＰＥＲＭが戻される。
【０１１９】
したがってメッセージＭＳＧ−Ａのペイロードは、認証が成功した場合を除いて無視される。逆の事例では、通知されたサービスにおける後続のメッセージのためにリスニングソケットはオープンされず、顧客は到来したデータに対しリスニングしない状態を維持する。
【０１２０】
ローダ６７の動作は、リスニングソケット６８を介して受け取ったシステム通知メッセージに関しては同様である：ソケット６９は、ライブラリ２５の呼び出しによりメッセージが認証されたときのみ後続のコンテンツメッセージのためにオープンされる。
【０１２１】
参照符号１Ｂ（図８）で表されている送信装置１に関する第２の実施形態は、秘匿化と認証の組み合わせに用いられる。この実施形態と上述の実施形態との基本的な相違点は、送信装置１Ｂ内に署名要素を補足するかたちで暗号化による秘匿化要素が設けられていることであり、これは署名要素の上流で動作するよう設計されている。暗号化による秘匿化要素と署名の要素はそれぞれ、鍵インデックス化テーブル１６（図１）から現在の２つの暗号鍵を選択することに基づいており、上述のように一般的なやり方で暗号化ライブラリ１５のタイプの秘匿暗号化ライブラリ１５Ｂと署名ライブラリ１５Ａ′をそれぞれ呼び出す。受信装置２は、暗号鍵インデックス化テーブルに対応するインデックス化復号テーブルを有しており、これらの復号鍵は有利には非公開ないしは秘密である。インデックス化暗号テーブルおよびインデックス化復号テーブルは、たとえば各々１０個の鍵を有している。
【０１２２】
したがって参照符号３１Ｂの付されたドライブシステム３１は、現在の鍵を変更するためのユニット１２と、秘匿暗号化のためのメッセージ（それぞれ１２Ｂ，１３Ｂ）を安全に保護するためおよび秘匿暗号化後の署名（それぞれ１２Ａ′，１３Ａ′）のためのデバイス１３の双方を有している。
【０１２３】
さらに参照符号３２Ｂの付されたブロードキャストサーバ３２には、暗号コントロールユニット１１Ｂを有する仕上げおよび秘匿暗号化モジュール３４と、このモジュール３４の下流に設けられ署名コントロールユニット１１Ａ′を有する署名モジュール３８が設けられており、各コントロールユニット１１Ｂ，１１Ａ′は暗号化コントロールユニット１１のタイプである。このサーバ３２Ｂは第１の実施形態と同じようにして、参照符号ＡＵＴＨ−Ｂで表される認証フィールドＡＵＴＨをＳＡＰフォーマットのヘッダに組み入れる。
【０１２４】
仕上げおよび秘匿暗号化モジュール３４の役割は上述の第１の実施形態のように、必要とされる補足情報をメッセージＭ１に付加すること、ならびに暗号ライブラリ１５Ｂを呼び出して取得されたメッセージＭ４を秘匿暗号化することであり、これは秘匿暗号化ライブラリ１５Ｂに暗号鍵識別子ＫｅｙＩＤ［ＣＲＹＰＴ］を伝達することによって行われる。この場合、ライブラリ１５Ｂの暗号化モジュール１７（図１）によってペイロードの暗号化が実行されるけれども、ヘッダまたは認証フィールドＡＵＴＨ−Ｂの初期データの暗号化は実行されない。鍵識別子ＫｅｙＩＤ［ＣＲＹＰＴ］はたとえばランダムに生成される。
【０１２５】
署名モジュール３８は、この暗号化の結果として得られ殊に認証鍵識別子ＫｅｙＩＤ［ＳＧＮ］をもつメッセージＭ５を暗号ライブラリ１５Ｂから受け取り、さらに署名ライブラリ１５Ａ′を呼び出して、署名されたメッセージＭ６を取得するように設計されている。ライブラリ１５Ａ′の暗号化モジュール１７（図１）によってメッセージＭ５全体に係わる署名が決定されて添付され、これは前述の実施形態のように鍵識別子ＫｅｙＩＤ［ＳＧＮ］により与えられた現在の鍵を用いて行われる。
【０１２６】
カプセル化モジュール３６は前述のものと同じ役割を果たし、これにより参照符号ＭＳＧ−Ｂの付されたブロードキャストすべきメッセージＭＳＧが得られるようになる。
【０１２７】
一例として（図９参照）メッセージＭＳＧ−Ｂはそのペイロードに加えて、参照符号ＳＡＰ−Ｂの付されたＳＡＰフォーマットのヘッダを有しており、これは以下のように構成されている：
−フィールドＶ、ＡＲＴＥＣ，Ｌ−ＡＵＴＨ，ＭＳＧ ＩＤ ＨＡＳＨ，ＡＵＴＨ−Ｂ、これらは第１の実施形態と同様である；
−秘匿化暗号鍵識別子ＫｅｙＩＤ［ＣＲＹＰＴ］（１ダブルワード）；
−時間超過を表すインジケータＴＩＭＥＯＵＴ（１ダブルワード）、これが有用となるのはペイロードが秘匿暗号化されるときおよび通知メッセージの送信にプロキシが係わるときである；
−秘匿暗号化前のパディングをシグナリングするパディングインジケータＰ（１ｂｉｔ）、この場合、復号されたペイロードの最後のバイトによって付加されたパディングバイトの数が表される；
−真の乱数を含み復号後に廃棄されることを意図した乱数フィールド（３１ｂｉｔ）。
【０１２８】
暗号化フィールドのセットＣＲＹＰＴは識別子Ｐ、乱数フィールドならびにペイロードから成り、他方、識別子ＫｅｙＩＤ［ＣＲＹＰＴ］とフィールドＴＩＭＥＯＵＴは暗号化されてない暗号ヘッダＥＮＴ−ＣＲＹＰＴを成す。
【０１２９】
関連する暗号化ライブラリおよび識別ライブラリ（図１０，図１１）のペアのうちいずれか１つに適用可能な１つの変形実施形態によれば、暗号化ライブラリ７５は鍵テーブルの代わりに暗号鍵のブロックＢ１，Ｂ２〜Ｂｎのインデックス化テーブル７６を有している。ブロックＢｉそれ自体は各々複数の鍵Ｋｉ，１，Ｋｉ，２〜Ｋｉ，ｌｉを有しており、その個数は考慮されるブロックに従って可変である。同様に、識別ライブラリ８５は識別鍵のブロックＢ′１，Ｂ′２〜Ｂ′ｎのインデックス化テーブル８６を有しており、それらのブロックＢ′ｉは各々、暗号化ライブラリ７５のブロックＢｉの鍵Ｋｉ，１，Ｋｉ，２〜Ｋｉ，ｌｉにそれぞれ対応する複数の鍵Ｋ′ｉ，１，Ｋ′ｉ，２〜Ｋ′ｉ，ｌｉを有している。
【０１３０】
したがって鍵識別子ＫｅｙＩＤを知っていても、暗号化モジュール７７による暗号化のために選ばれた鍵Ｋｉ，ｊを１対１のかたちで突き止めることはできず、したがってライブラリ８５の識別モジュール８７により使用されるべき対応の識別鍵Ｋ′ｉ，ｊを突き止めることはできず、それぞれこれらの鍵が属するブロックＢｉおよびＢ′ｉだけである。このため識別ブロックＢ′ｉの鍵すべてを、復号が成功するまで連続的に試さなければならない。
【０１３１】
識別子の１つの変形実施形態によれば、認証鍵識別子ＫｅｙＩＤ［ＳＧＮ］および／またはパーミッション識別子ＰＥＲＭは、メッセージＭＳＧのヘッダにおいて認証フィールドＡＵＴＨの外側にある。したがって認証のためのメッセージは、署名計算ＳＧＮにそれらの識別子を含めることによって暗号化することができるが、他方、認証フィールドＡＵＴＨ（Ｌ−ＡＵＴＨ＝０）は除外される。
【０１３２】
別の実施形態（図１２，図１３）の場合、パーミッションフラグＰＥＲＭはペイロードフィールド内に配置される。この実施例によれば参照符号ＭＳＧ−Ｃの付された生成されたサービス通知メッセージＭＳＧには、参照符号ＳＡＰ−Ｃで表されたＳＡＰフォーマットのヘッダが含まれており、これにはパーミッションは伴わないが認証フィールドＡＵＴＨ−ＣのヘッダＥＮＴ−Ｃにおける２ｂｙｔｅの予約フィールドが設けられている。参照符号ＳＤＰ−Ｃの付されたＳＤＰフォーマットのペイロードはたとえばフィールドの最初に、２ｂｙｔｅのパーミッションフラグＰＥＲＭを有している。パーミッションフィールドは、バイナリフォーマットではなくテキストでの書き込みが要求されるためにヘッダスペースよりも多くのペイロードスペースとパーミッションフィールド識別ラベルを必要とする。
【０１３３】
次に、ＭＰＥＧ−２標準に準拠するネットワークを介したＭＨＰ標準に従ってデータをディジタルブロードキャストする適用例について詳しく説明する。この適用例は、ＭＰＥＧ−２標準（ISO/IEC 13818-1）で指定されているＰＭＴテーブル（Program Map Table）とＡＩＴテーブル（Application Information Table）の保護に関するものであり、この場合、ＰＭＴテーブルのスクランブルはＭＰＥＧ−２標準によって禁じられている。上述のメカニズムのため、ルート証明書発行局（root certification authority）が設立されており、オプションとして他の証明書発行局も設立される。
【０１３４】
ＰＭＴテーブルは、インタラクティブにまたはその他のやり方でサービスをシグナリングするための重要なエントリポイントを成している。インタラクティブＭＨＰアプリケーションの事例の場合、ＰＭＴテーブルにはＡＩＴテーブルを搬送するストリームと、コードおよびアプリケーションデータ（ＤＳＭ−ＣＣ ＤＳＩへのポインタ、"Digital Storage Media - Command and Control"および"Digital Speech Interpolation"を意味する）を搬送するストリームのポジションが含まれている。
【０１３５】
シグナリングの保護はハッシュコードと署名と証明書に基づいている。これらの暗号メッセージの符号化は、それぞれhash＿descriptor, signature＿descriptorおよびcertificate＿descriptorで表される新しい３つのデスクリプタを導入することによって行われる。
【０１３６】
最初のデスクリプタhash＿descriptorは、ＡＩＴテーブルまたはＰＭＴテーブルにおける第１のループまたは第２のループに配置することができる。ハッシュコードは特定のループ内で、ポインタが指すデスクリプタにおいて計算される。次の階層レベルのデスクリプタループは低レベルのハッシュコードを有することができる。hash＿descriptorのシンタックスはたとえば以下のパラメータを用いて定義される：
−digest＿count：ハッシュデスクリプタにおけるプリプロセッシング値（digest value）の数を識別する１６ｂｉｔの値；
−digest＿type：関連するデスクリプタのために場合によっては使用可能なプリプロセッシングアルゴリズムを識別する８ｂｉｔの値；以下の中から割り当て値が選ばれる：
−０：プリプロセッシング長０、認証なし；
−１：プリプロセッシング長１６、ドキュメントＲＦＣ１３２１において定義されているハッシュアルゴリズムＭＤ５；
−２：プリプロセッシング長２０、ドキュメントＦＩＰＳ−１８０−１において定義されているハッシュアルゴリズムＳＨＡ−１（ＳＨＡは"Secure Hash Algorithm"を意味する）；
−その他：将来の可能性のために予約；
−descriptor＿count：プリプロセッシング値に関連するデスクリプタの数を識別する１６ｂｉｔの値、この値は０よりも大きくなければならない；
−descriptor＿pointer：ハッシュ計算の一部を成すデスクリプタを識別するポインタ；
−descriptor＿tag：descriptor＿pointerパラメータが指すデスクリプタのタグ；
−digest＿length：各プリプロセッシング値のバイト数を表す整数値；これは上述のようにdigestタイプパラメータに関してプリプロセッシングのタイプに依存する；
−digest＿byte：プリプロセッシング値の１つのバイトを含む８ｂｉｔの値。
【０１３７】
したがってhash＿descriptorデスクリプタのシンタックスは以下のように記述される：
【０１３８】
【数３】
【０１３９】
第２のデスクリプタsignature＿descriptorのために（hash＿descriptorデスクリプタについてすでに定義されているパラメータに加えて）以下のパラメータが使用される：
−signature＿id：この識別子により、権限をもつ複数の局（authority）の署名を使用できるようになる；
−signature＿length：次のループの長さを表す；
署名固有のフィールドについては以下で説明する。
【０１４０】
デスクリプタループにおける第１のhash＿descriptorデスクリプタの前に配置されるデスクリプタは以下のシンタックスを有する：
【０１４１】
【数４】
【０１４２】
「署名固有データ」"signature specific data"フィールドには、ASN. 1（Abstract Syntax Notation one）DER仕様言語で以下のように表現される構造が含まれている：
ここにおける"signatureValue"フィールドは署名値（ビットストリング"BIT STRING"の形式）を表し、その値はＭＨＰ仕様の選択に依存する。また"certificateIdentifier"および"hashSignatureAlogrithm"フィールドは以下のように定義される。
【０１４３】
certificateIdentifierフィールドによって、署名の照合に使用される証明された公開鍵をもつ証明書が識別される。これはAuthorityKeyIdentifierタイプフィールドのためのITU-T（"International Telecommunication Union - Telecommunications Standardization Sector"）extension X.509 [54] に従って定義される。AuthorityKeyIdentifierタイプフィールドの構造には殊に、オプションの鍵識別フィールドKeyIdentifier（KeyIdentifierタイプ）が含まれている。さらにこれにはauthorityCertIssuer（GeneralNamesタイプ）要素とauthorityCertSerialNumber（CertificateSerialNumberタイプ）要素も含まれていて、authorityCertIssuer要素自体には使用される公開鍵をもつ証明書の値を有する"directoryName"フィールドが含まれ、authorityCertSerialNumber要素は対応するシリアル番号を表す。先験的にオプションとしてAuthorityKeyIdentifierフィールドタイプであるこれら２つの要素は埋められていなければならない。したがって以下のようにする：
hashSignatureAlgorithmフィールドは使用されるハッシュアルゴリズムを識別する。署名の計算に使用される暗号化アルゴリズムはここでは指定する必要がない。その理由は、鍵を暗号化する証明書のSubjectKeyInfoフィールドにすでに記述されているからである。設けられている２つのアルゴリズムはＭＤ５とＳＨＡ−１であり、その構造は以下の通りである：
第３のデスクリプタcertificate＿descriptorによってCertificateFileファイルの構造化が可能になり、このファイルにはルート証明までのおよびそれを含む証明ストリングにおけるすべての証明が含まれている。リーフ証明とルート証明はデスクリプタのそれぞれ最初と最後に配置されており、後者は整合性のためだけに含まれている。証明符号化プロファイルはETSI（"European Telecommunications Standard Institute"）標準TS 102 812 V1.1.1に定義されている。
【０１４４】
デスクリプタストリング内で最初のsignature＿descriptorデスクリプタの前に配置されているcertificate＿descriptorデスクリプタには、ITU-T X.509標準により定義されている単一の「証明 "certificate"」データ構造をもつ"certificate()" fieldが含まれている。デスクリプタの構造は以下のパラメータに依存して表現される：
−signature＿id：証明を特定の署名に結合する識別子；
−certificate＿here＿flag：値１であれば証明がデスクリプタ内に配置されていることを表し、そうでなければアプリケーションの証明を用いる必要があり、この場合、結合を以下のように定義すべきである；
−certificate＿count：証明デスクリプタにおける証明の数を表す１６ｂｉｔの整数；
−certificate＿length：証明におけるバイト数を指定する２４ｂｉｔの整数。
【０１４５】
したがってcertificate＿descriptorデスクリプタの構造は以下のようにして指定される：
【０１４６】
【数５】
【０１４７】
上述の方法によって、ＰＭＴテーブルとＡＩＴテーブルを不正操作や侵害行為から保護できるようになる。また、ネットワークの前処理においてストリームが再度多重化される可能性や、ＰＩＤ識別パケットまたはイベントＰＭＴテーブル内容がネットワーク要求により変更される可能性がある。上述の方法によればこのような再多重化は、デスクリプタのサブセレクションだけが認証されるか、そうでなければ変更されたデスクリプタを再多重化装置によって再認証することで可能となる。
【０１４８】
これまでの説明はＰＭＴテーブルとＡＩＴテーブルの認証をターゲットとして述べてきたものであるが、上述の方法はたとえばＰＡＴ，ＣＡＴ，ＮＩＴ，ＥＩＴ，ＳＩＴまたはＤＩＴテーブルなどのようなＭＰＥＧ／ＤＶＢに準拠して定義された他のいかなるタイプのテーブルにも適用可能である。
【図面の簡単な説明】
【０１４９】
【図１】第１の鍵選択形態を実装した本発明によるメッセージの送信側および受信側を示す基本構成図である。
【図２】認証に利用可能な図１の送信側の第１の実施形態について詳細に示す図である。
【図３】図２の送信側により発送される認証フィールドを含むＡＴＶＥＦサービス通知メッセージの内容を示す図である。
【図４】図３の認証フィールドの内容を詳細に示す図である。
【図５】認証フィールドが埋められた状態で図２の送信側により生成されたメッセージの中間バージョンの内容を示す図である。
【図６】図２に示した送信側を伴う中央サーバによりコントロールされる無線ブロードキャストタイプのブロードキャスタセットを示す図である。
【図７】図２の送信側と組み合わせてＡＴＶＥＦサービスメッセージの認証に利用可能な図１の受信側の第１の実施形態について詳細に示す図であるが、この場合にはシステムサービスメッセージの認証にも復号にも利用できる。
【図８】暗号化と認証の組み合わせに利用可能な図１の送信側における第２の実施形態について詳細に示す図である。
【図９】図８の送信側によって発送される認証フィールドと暗号化フィールドを含むＡＴＶＥＦサービス通知メッセージの内容を示す図である。
【図１０】図１の送信側の変形実施形態として用いられる鍵のブロックを伴う第２の鍵選択形態を実装する署名ライブラリを示す図である。
【図１１】図１の受信側の変形実施形態として使用され図１０のライブラリに対応する鍵ブロックを伴う認証ライブラリを示す図である。
【図１２】図２の送信側により発送される認証フィールドを含むＡＴＶＥＦサービス通知メッセージの変形実施形態の内容を示す図である。
【図１３】図１２による認証フィールドの内容を詳細に示す図である。
【０００１】
本発明は、ネットワークにおけるメッセージの安全保護および識別のための方法およびこの方法に対応する装置に関する。
【０００２】
安全でないネットワークにおいて、メッセージの流れがたとえば無線ブロードキャストにより行われようとケーブルによりあるいはインターネットネットワークにより行われようと、そのようなメッセージの流れを保証するために暗号鍵を用いることが一般的に行われており、これを暗号鍵とも称する。一般にはメッセージの送信側にそのような暗号鍵が与えられ、受信側には対応する識別鍵が与えられる。これらの鍵は構想するアプリケーションに応じて秘密鍵であってもよいし、公開鍵であってもよい。たとえば送信側が一対の鍵を使用し、それらのうちメッセージの暗号化を可能とする公開暗号鍵を送信側がブロードキャストし、しかも送信側は自身のためには非公開つまり秘密の復号化鍵を保持している。
【０００３】
メッセージの暗号化は２種類の主要な用途をもっている。すなわち、
メッセージの認証：このために暗号化により得られた結果が署名というかたちでメッセージに組み込まれる。この場合、識別鍵は復号鍵であってもよいし、暗号鍵であってもよい。
メッセージの秘匿化：このために暗号化の結果が秘匿化されるメッセージの部分を置き換える。この場合、識別鍵は復号化鍵である。
【０００４】
これら両方の種類の用途において望ましいのは、第三者によりメッセージが傍受されたり不正に復号されたりするリスク、あるいは署名を不正に添えることで偽造されるリスクを最低限に抑えることである。したがって権限のない暗号化または復号の可能性を複雑にする目的で、いくつかのシステムが提案されてきた。
【０００５】
このため、対応する暗号鍵と識別鍵を定期的に変更できるようにする技術が開発された。これらの技術のいくつかは、通信ネットワークを介した新しい識別鍵の配送に頼っており、他方、殊にこれらの鍵が秘密鍵であれば（たとえば鍵の秘匿暗号化などによって）それらの鍵を認識するのが難しくされる。しかしながらこれらの技術は、予防措置をとったにもしても配送された鍵の傍受およびその使用に対しては脆弱である。さらに新しい鍵を配送するごとに、受信側によってそれを認識しインストールする必要があり、このことは場合によっては鍵の効率に対し不利には働くようになる。
【０００６】
文献EP-0,506,637には、セルラ無線通信ネットワークにおける移動局の妥当性および照合のためのシステムが記載されている。このシステムはネットワークと移動局の双方において、固定的な鍵とローリングキー（rolling key）と呼ばれる変更可能な鍵を有している。これらの鍵は入力として認証アルゴリズムに供給され、ネットワークと各移動局において生成されたレスポンスの比較によって不正を正確に指摘できるようになる。ローリングキーはネットワークと移動局において双方向の認証各々に応じて、両方に共通する履歴認証情報に依存して同時に更新される。
【０００７】
したがってネットワークを経由することなく鍵が規則的に変更されるので、交換のセキュリティを高めることができる。とはいうもののこのようなシステムの欠点は、双方向の認証各々に応じて新たなローリングキーの計算が必要とされることである。しかも技術的な誤動作が生じて同期のとれない問題も発生する可能性があり、そのために認証を利用できなくなってしまうかもしれない。このことを改善するためには特定のメカニズムを構築しなければならず、それによってシステムが複雑になり、認証の信頼性が低減するというリスクが生じることになる。
【０００８】
アメリカ合衆国特許US-6,105,133には送信局／受信局の認証と秘匿暗号化のための双方向システムが開示されている。送信局のいずれか２つの間の交換は、認証と秘匿化ならびにこれらの局間のコネクションごとに変更される暗号鍵の使用により安全に保護される。この鍵は局各々において独立して計算され、これは他方の局の識別子と、双方の局に固定的なかたちで記録されたパラメータと、一方の局から他方の局へ通信される変更値とに基づき計算される。
【０００９】
この技術によれば、暗号鍵の周期的な変更を可能にし、ネットワークを介したこの鍵の伝送を回避し、かつ送信局と受信局における鍵の更新の同期を保証することで、システムの信頼性が高められる。とはいうものの、そのためには更新ごとに送信局と受信局において新たな鍵の計算が必要とされる。この計算に必要とされる時間によって、メッセージ受信後に迅速に実行すべきオペレーションが危うくされる。特にこのような時間は、復号および／または認証すべきメッセージのあとに先行のメッセージの知識を要求する処理がなされる他のメッセージが続き、これら先行のメッセージと後続のメッセージとの間の期間がこの知識の取得には十分ではないとき、誤動作の原因となる。
【００１０】
アメリカ合衆国特許US-5,301,233には、特定の個人に向けたプログラムの送信および受信のためのプロセスが開示されている。各プログラムは複数の秘匿暗号化された要素から成り、それらの要素各々ごとに意図する受信側の識別子が含まれている。対応する要素をアクセスするために、この識別子のみに権限が付与されている。アクセスコントロールメッセージによって、受信側は自身のために意図された要素の秘匿暗号化に使用されるコントロールワードを再構成することができる。詳しくはこのメッセージには「サービスキー識別子」が含まれており、さらにオプションとして、識別されたサービスキーを用いて得られた署名が含まれている。コントロールワードに加えられるオプションとしてのこの署名によってこのワードの妥当性を保証できるようになり、応答が否定的であったならば受信したプログラムを無視することができる。このキー識別技術は、これに特定されるわけではないが、キー生成用情報のバッチに頼っており、このバッチはキー識別子の中に含まれていて、これは８ｂｙｔｅの署名に対したとえば３ｂｙｔｅにわたっている（第５欄第４２〜５２行）。
【００１１】
アメリカ合衆国特許US-5,222,137は、秘匿暗号化無線伝送のための暗号鍵のダイナミックな選択に係わるものである。オペレーション中、複数の鍵識別子と対応する鍵をもつ無線機が他の同一の無線機と通信を行う。この無線機は、秘匿化されていない鍵識別子をもつ秘匿暗号化信号を送信および受信する。伝送を行う前にそのつど送信側無線機は鍵識別子の１つを自動的に選択し、送信すべきメッセージを対応する秘匿化暗号鍵を用いて秘匿暗号化する。受信側の無線機は受信した鍵識別子を用いて使用された秘匿化暗号鍵を求め、それを用いてメッセージを復号する。この方法によれば、ディスパッチないしは発送ごとに使用される鍵を変更できることから内容のダイナミックな保護を保証することができるため、セキュリティレベルが高められる。
【００１２】
しかしながら、受信したメッセージごとに処理するためには十分なオペレーション容量ならびにメモリスペースが必要とされる。情報を迅速に利用できなければならずメッセージサイズが重要であり殊に個々の受信側に対するサービスの発行のために重要である場合、このような状況では遅延が引き起こされる可能性があるし、あるいはメモリワイピングメカニズムがトリガされて情報の損失が引き起こされてしまうおそれすらある。
【００１３】
本発明は、ネットワークを介して発送することを意図したメッセージを保護するためのセキュリティ装置に関するものであり、変更可能な暗号鍵の使用に基づいている。このサービス装置によれば、上述の暗号鍵をネットワークを介して伝達させる必要なく変更することができ、メッセージの送信側と受信側において鍵の更新を同期合わせすることができ、さらに著しく迅速に鍵の交換を実行することができる一方、遅延あるいは不都合なメモリスペース要求を回避することができる。
【００１４】
また、本発明によるデバイスを、更新鍵のための複雑化したアルゴリズムを必要とすることなく経済的にインプリメントすることができる。
【００１５】
本発明はさらに、ネットワークを介して受信したメッセージを識別するデバイスにも関し、これによって上述の利点を得ることができる。
【００１６】
本発明はさらに、本発明に従って構成された１つまたは複数の識別デバイスを有するメッセージ送信装置にも、本発明に従って構成された１つまたは複数の識別デバイスを有するメッセージ受信装置にも適用されるし、さらにコンピュータプログラム製品、メッセージおよび相応のセキュリティおよび識別プロセスにも適用される。
【００１７】
以下の記載では次のような名称を採用する：
−「認証」"authentication" 、これはネットワークを介して伝達されるメッセージの出所と完全性の保証に関連する手順であり、メッセージ送信前に鍵を用いて生成されメッセージ中に入れられるディジタル署名に基づいて行われる、
−「秘匿化」"encryption" 、平文をそのままでは役立たない理解不能な文に置き換える手順；
−「秘匿解除」"decryption" 、秘匿化文を元の形式に戻すことにより平文に置き換える手順；
−「暗号化」"enciphering" 、メッセージまたはメッセージの一部分から秘匿化文を決定する手順、この秘匿化文は平文に対する置き換え（秘匿化 encryption）または署名（認証 authentication）として使用される；
−「復号」"decipherment" 、秘匿化文から平文を少なくとも部分的に再構築する手順、これはテキストを含むメッセージの出所および完全性を証明するため（認証 authentication）、あるいは秘匿化文を平文に置き換えるため（復号 decryption）に行われる；
−「安全保護」"securing"、これは認証または秘匿化の目的でメッセージまたはその一部分を暗号化する手順；
−「識別」"identification"、メッセージの出所および完全性（認証）またはその内容（復号）により、メッセージ識別のためにメッセージにおいて受け取った秘匿化文を使用する手順である。
【００１８】
本発明は一般に、電子署名・電子認証および／または秘匿化のための暗号化・秘匿解除のための復号を使用するセキュリティプロセスに適用される。このセキュリティプロセスは伝送時には暗号鍵を使用し受信時には暗号鍵および／または復号鍵を使用することに基づいており、この場合、復号鍵は秘匿解除のためにインプリメントされ、復号鍵および／または暗号鍵は認証のためにインプリメントされる。
【００１９】
本発明の適用事例の有利な分野はディジタルテレビジョンであり、たとえばオーディオビジュアルデータのブロードキャスト、ＰＳＩ（Program Specific Information）、ＳＩ（Service Information）、インタラクティブデータ、シグナリングデータまたはプライベートデータのためのものである。殊にいくつかのディジタルブロードキャストネットワークやリターンチャネルをもついくつかのネットワークたとえば地上波およびマイクロ波周波数のネットワークは、不正行為たとえばスプーフィング spoofing に脆弱である。この場合、不正行為として挙げられるのはデータの傍受、それらの改竄および改竄したデータのブロードキャストまたはネットワークへの流し込みなどである。殊に有用な適用事例は電子商取引やホームバンキングである。
【００２０】
この目的で本発明は、可変の現在の識別鍵によりメッセージの識別をコントロールする手段を有する少なくとも１つの受信装置へネットワークを介して発送するためのメッセージを保護するセキュリティデバイスに関する。本発明によるセキュリティデバイスは以下のユニットを有している：
−可変の現在の暗号鍵を用いてメッセージ各々の少なくとも一部分に対する暗号化をコントロールするユニット；
現在の暗号鍵を変更するユニット、このユニットは使用可能な複数の暗号鍵から成るまえもって決められたセットから暗号鍵を選択するよう設計されている；
−メッセージに鍵識別子を登録するユニット、このユニットにより受信装置は、使用可能な複数の暗号鍵から成るまえもって決められたセットに対応する使用可能な複数の識別鍵から成るまえもって決められたセットから現在の識別鍵を選択できるようになり、この鍵識別子によって受信装置は、現在の識別鍵が現在の暗号鍵と一致するようこの現在の識別鍵を変更できるようになる。
【００２１】
本発明によればこのセキュリティデバイスには、メッセージの各々に対する現在の暗号鍵を用いたメッセージの一部分の暗号化の結果から成る署名の付加をコントロールする手段が設けられており、メッセージはサービス通知メッセージである。
【００２２】
ここで用語「サービス通知メッセージ」"service announcement message"とは、あるサービスの枠組みの中で上流に発送されるメッセージのことであり、これによってこのサービスにおける１つまたは複数の別のメッセージの後続の発送に関する情報および命令が与えられる。これら他のメッセージはコンテンツ（「コンテンツメッセージ」"content message"）または即時トリガ命令（「トリガ」"trigger"）のベアラである。有利な実施形態によればサービス通知メッセージは、ＳＡＰ（Session Announcement Protocol）フォーマットのヘッダとＳＤＰ（Session Description Protocol）フォーマットのペイロードを有している。
【００２３】
ＡＴＶＥＦ仕様（つまりAdvanced Television Enhancement Forum 標準に準拠した仕様）によれば、オプションとしてサービス通知メッセージに認証フィールドが設けられる。
【００２４】
上述のように用語「識別」鍵によって表されているのは、セキュリティデバイスにより使用された暗号鍵にそれぞれ対応づけられた復号鍵または秘匿解除鍵のことである。秘匿解除のためには識別鍵のセットは暗号鍵のセットであり、各暗号鍵は秘匿化に使用された対応する暗号鍵と同じ長さを有している。
【００２５】
認証のためにはこのセットは復号鍵、暗号鍵または両方のタイプの鍵の組み合わせから成り、これらはそれぞれ伝送時の対応する暗号鍵から生成される。この場合、受信側によって使用される各認証鍵および殊にほとんどの暗号鍵は有利には、署名生成のためセキュリティデバイスにより使用される対応する暗号鍵よりも著しく短い。殊に、署名を完全に秘匿解除したり再構築したりする必要がない。メッセージの認証を保証するためには部分的な一致で十分である。したがって認証オペレーションは単純化され、複数の暗号鍵から成る識別鍵について、受信側への伝送時に使用された暗号鍵全体がブロードキャストされないことから、署名が不正に生成されるリスクが低減される。
【００２６】
受信側においていわば即時的に所望の識別鍵を正確に得るために、単純な識別子の発送で十分である。この結果は、それぞれ伝送側と受信側において使用可能な複数の鍵から成る２つの対応するセットをまえもって記録し、それらの鍵をインデックス化しておくことにより達成される。しかしながら意外なことに、アメリカ合衆国特許 US-5,222,137のように伝送された情報の保護がコンテンツメッセージの秘匿化、ならびに同一の送信／受信システム（ラジオ）に同一の鍵のセットを設けることには基づいていない。本発明のセキュリティデバイスは実践において、完全に非対称であってよい送信側デバイスと受信側デバイスとの間のサービス通知メッセージに適用される認証プロセスにインプリメントされる。
【００２７】
本発明によるデバイスはことごとく予想外のものであり、それというのもインタラクティブテレビジョンの世界で使用されるフォーマットたとえばＡＴＶＥＦおよびＭＨＰ（Multimedia Home Platform）標準はサービス通知メッセージの中に、この通知メッセージの署名の計算を可能にする鍵識別子を組み込む可能性をサポートしていないからである。たとえばＡＴＶＥＦの例であれば、Session Announcement Protocol, RFC 2974に関して進行中のＲＦＣ（Request For Comment）ドキュメントの規定によれば、認証に関する情報のない通知メッセージにおいて署名を計算することによりサービス通知メッセージを署名することが可能であると規定されている。
【００２８】
ＭＨＰ標準それ自体は、どのようにしてアプリケーションおよびブロードキャストデータを認証すべきか、およびリターンチャネルに伝送されたデータをどのようにして保護すべきかを規定している。しかしこれによっても、サービス通知メッセージの機能を果たすシグナリングメッセージの認証については呈示されていない。したがって本発明のデバイスは基本的に、主体が受け取った知識に反する動作をする。
【００２９】
このような解決手段により受信側のレベルにおいて、通知されたサービスが有効ではないとき、そのサービスのメッセージについてコンテンツメッセージまたはトリガタイプを不必要に考慮しなくてもよくなる。このため受信側はいっそう扱いやすくなり、システムの信頼性や安全性について妥協することなく演算やメモリスペースの不必要な消費が切り詰められる。
【００３０】
しかもコンテンツメッセージの秘匿化によってさらに別の可能性が生じ、これはいくつかの事例では望ましいとされるかもしれないが、たいての状況では絶対に必要というわけではない。権限のないサービス（認証されていないサービス通知メッセージ）ばかりか有効なサービスにも関する処理コストやメモリスペースコストは、このような秘匿化がなければ回避される。
【００３１】
本発明によるデバイスによれば、いずれかのメッセージまたは所定のタイプのメッセージの発送に応じて鍵の変更に対する権限が付与される。鍵の識別の最初の形態によれば鍵識別子がいずれかのメッセージに付加され、これは鍵変更の主体を成すことができる。ついで受信側におけるこのインジケータに対応する鍵が、識別子に基づきシステマティックに選択されて識別に使用される。鍵の識別の第２の実施形態によれば、鍵識別子が鍵変更バイナリインジケータによって補われる。その後、受信側において、鍵変更インジケータが鍵の変更を通報するまで現在の識別鍵がメモリ内に保持される。識別鍵の第３の実施形態によれば、鍵識別子は鍵が実際に変更される場合にのみ指定される。さもなければ鍵識別子はデフォルト値（たとえば０）に置き換えられ、これによっていままで使用されていた鍵が依然として有効であることが通報される。この第３の経済的な形態が有利である事例は、メッセージを常にリスニングしておりいかなるメッセージも見落とさない複数の受信側の集合にメッセージが送信される場合である。この場合、たとえばＷｅｂを介したマルチキャストに適用できる。
【００３２】
変更の頻度と実行される鍵の選択の両方に関して、鍵識別子を様々なやり方で決めることができる。したがって変更に関する第１の実施形態によれば鍵識別子が変更されるのは、伝送側のユーザでありつまり変更の発生も選択される新たな鍵もともに決定できるユーザによって要求されたときである。変更に関する第２の実施形態によれば鍵識別子は、ユーザによって選ばれた周期に従って周期的に変更され、新たな鍵識別子がランダムに決められる。変更に関する第３の実施形態によれば鍵識別子は、ランダムに選択されるが最短期間と最長期間の間に位置する期間だけ間隔のとられた時点で、まえもって決められた一連の値に従い変更される。変更に関する第２および第３の実施形態の場合、どんなやり方でもいかなる時点でも現在の鍵を変更可能なシステムを採用しているユーザにとって望ましい。
【００３３】
伝送時および受信時の鍵は秘密鍵であってもよいし公開鍵であってもよい。有利であるのは、送信側の身元が保証されるよう伝送時の鍵を秘密鍵とし、受信側の鍵を公開鍵とすることである。なお、サービスにおける後続のコンテンツメッセージの秘匿化を利用して補足的なセキュリティを実施するのであれば、メッセージの機密性が保証されるようこの秘匿化のための受信側の鍵を秘密鍵とするのが有利である。
【００３４】
さらに有利であるのは暗号化コントロールユニットが、使用可能な暗号鍵が格納されている暗号化ライブラリを呼び出すことである。
【００３５】
有利であるのは、使用可能な複数の識別鍵から成るまえもって決められたセットを複数の復号鍵から成るセットとすることである。
【００３６】
さらに有利であるのは、暗号化すべきメッセージの一部分が署名を差し引いたメッセージ全体から成り、これには鍵識別子が含まれている。したがって認証は送信側の身元およびメッセージのペイロードに関係するだけでなく、もっと広くメッセージ内に含まれる情報すべてに関係し、これには識別鍵の選択および受信側レベルにおけるあらゆる動作パラメータも含まれる。
【００３７】
１つの有利な実施形態によれば、本発明のセキュリティデバイスはメッセージを秘匿化することができ、この機能は有利には認証済みサービス通知メッセージに続くコンテンツメッセージに適用される。この場合、暗号鍵について有利であるのは、サービス通知メッセージの認証に採用されたのと同様のモードに従い識別されるようにすることである。さらに有利にはヘッダとペイロードを有する秘匿化すべきメッセージ各々ごとに暗号化コントロールユニットは以下のことをコントロールするように設計されている：
−現在の暗号鍵により秘匿化すべきメッセージの一部分の暗号化、この部分は少なくともペイロードの一部分を有する；
−この部分のメッセージにおいて、現在の暗号鍵によるこの部分の暗号化の結果から成る秘匿化情報による置き換え。
【００３８】
この実施形態の変形によれば、サービスにおいて認証済みサービス通知メッセージに続く秘匿化すべきメッセージの２つのレベルの暗号化が以下のようにして行われる：
−使用可能な複数の鍵から成る第１のセットから選択された現在の鍵を用いた秘匿化；
−使用可能な複数の鍵から成る第２のセットから選択された現在の認証鍵を用いた署名、認証のための暗号化は署名を除いたメッセージ全体に適用するのが有利であり、これには秘匿化部分が含まれる。
【００３９】
１つの有利な適用形態によればサービス通知メッセージは少なくとも、ＡＴＶＥＦ通知メッセージおよび／またはシステム通知メッセージの中から選択される。
【００４０】
１つのサービスにおける各ＡＴＶＥＦ通知メッセージには、１つまたは複数のサービストリガによる（HyperText Transfer Protocol方式に従った）少なくとも１つのＨＴＴＰコンテンツメッセージが続く。１つのサービスにおけるシステム通知メッセージ（これは一般に非公開およびマルチキャスト）自体には、そのサービスのバイナリファイルが続く。システム通知メッセージは有利には、ＡＴＶＥＦ通知メッセージと同様の形態をもっている。サービス通知メッセージの利用に関してＡＴＶＥＦ通知メッセージとは別の詳細な説明は、出願番号00402921.1をもつ２０００年１２月２３日出願のヨーロッパ特許出願および出願番号EP/01/12333をもつそのＰＣＴ出願に示されている。
【００４１】
可変長の認証フィールドをもつサービス通知メッセージ各々ごとに有利には登録ユニットは、この認証フィールドに鍵識別子を登録するように設計されている。この実施形態はその単純さの点で有利である。それというのもこのことによって、特別なフィールドを追加することなくサービス通知メッセージにすでに設けられているフィールドを非常にフレキシブルに利用できるようになるからである。
【００４２】
ＡＴＶＥＦおよびシステム通知メッセージ以外の有利な適用形態によればサービス通知メッセージは少なくとも、ＭＨＰシグナリングメッセージの中から適用される。
【００４３】
第１の鍵認識形態によれば鍵識別子各々は、使用可能な複数の鍵のうち決められた１つの暗号鍵と、使用可能な複数の識別鍵のうちこの暗号鍵に対応する１つの識別鍵とに対応づけられる。
【００４４】
したがって受信側で使用すべき鍵は、選択された鍵識別子により１対１形式で与えられる。この実施形態によれば、メッセージの出所と完全性の保証を迅速に成功させることができる。
【００４５】
第２の鍵認識形態によれば鍵識別子各々は、使用可能な複数の暗号鍵から成るセットの中から決定された暗号鍵ブロックと、使用可能な複数の識別鍵から成るセットの中からそれぞれ暗号鍵に対応して決定された識別鍵ブロックとに対応づけられる。
【００４６】
したがって選択される鍵識別子によっても、受信側は使用すべき識別鍵を即座に知ることはできない。この場合、意図するブロックの様々な鍵を用いて適切なものが得られるまで連続的なテストを実行しなければならない。したがってこの実施形態によれば、複雑さおよび認証または復号に要する期間が増大するにしても、不正行為に対する付加的な保護が提供される。
【００４７】
有利には登録ユニットは、（場合によっては複数の鍵または鍵ブロックに対応する）８〜１２の間に位置する個数の値有利には１０と等しい個数の値の中から鍵識別子を選択するように設計されている。セキュリティを強める別の実施形態によれば、この値の個数は２５６（１バイトをもつ識別子のコーディング）であり、あるいは６５５３６（２バイトのコーディング）であってもよい。
【００４８】
これに加えて、伝送時および受信時の鍵を更新できると有利である。たとえば複数の識別鍵から成るセットは、受信側をサーバと接続し、受信側により識別し、識別鍵テーブルをネットワークを介して安全に取り出すことによって遠隔に変更されるように設計されている。
【００４９】
本発明をさらにメッセージの送信装置にも適用できる。本発明によれば送信装置は、本発明の複数の実施形態のうちの１つに従って構成された少なくとも１つのセキュリティデバイスを有しており、この送信装置は有利にはブロードキャストによりメッセージを送信するように設計されている。
【００５０】
ここで用語「ブロードキャスト」とは、それがたとえば無線ブロードキャストまたはケーブルあるいはインターネットによってなされようが、同一のデータが複数の宛先の集合へ伝送されることを表す。
【００５１】
本発明はさらにネットワークを介して受信されるメッセージを識別するデバイスに関し、この場合、メッセージ各々には変更可能な現在の暗号鍵を用いて暗号化された部分が含まれている。この識別デバイスは以下のユニットを有している：
−変更可能な現在の識別鍵により暗号化された部分の識別をコントロールするユニット；
−このメッセージから鍵識別子を抽出するユニット、これにより現在の識別鍵を、使用可能な複数の暗号鍵から成るまえもって決められたセットに対応する使用可能な複数の識別鍵から成るまえもって決められたセットから、この現在の識別鍵が現在の暗号鍵と一致するよう選択できるようになる。
【００５２】
本発明によれば識別コントロールユニットは暗号化部分の識別をコントロールするユニットであり、この暗号化部分は現在の署名であり、メッセージはサービス通知メッセージである。
【００５３】
メッセージを識別するデバイスは有利には、本発明に従って構成されたセキュリティデバイスのいずれか１つの実施形態を用いて安全に保護されたメッセージを識別することができる。
【００５４】
本発明はさらにメッセージの受信装置にも適用される。本発明によればこの受信装置は、本発明の実施形態のいずれか１つに従って構成された少なくとも１つの識別デバイスを有している。さらにこの受信装置は有利には、本発明に従って構成されたメッセージ送信装置から発せられたメッセージを受信するように設計されている。
【００５５】
本発明はさらにコンピュータプログラム製品に関する。本発明によればこの製品は、本発明の実施形態のいずれか１つに従って構成されたメッセージを保護するセキュリティデバイスまたはメッセージを識別するデバイスにおけるユニットをインプリメントする機能を有している。
【００５６】
ここで「コンピュータプログラム製品」という用語の意味するコンピュータプログラム媒体は、ディスクやカセットなどのようにプログラムを含む記憶スペースによって構成できるだけでなく、電気的な信号または光学的な信号のような信号によっても構成可能である。
【００５７】
本発明はさらに、ネットワークを介して少なくとも１つの受信側へ発送すべきメッセージにも関する。このメッセージには以下のものが含まれている：
−それぞれ少なくとも１つの変更可能な現在の暗号鍵によって暗号化された少なくとも１つの部分；
−少なくとも１つの鍵識別子、これにより現在の識別鍵を、使用可能な複数の識別鍵から成るまえもって決められたセットからそれぞれ選択できるようになり、この現在の識別鍵によってそれぞれ暗号化された部分を識別できるようになる。
【００５８】
本発明によれば暗号化部分は署名であり、メッセージはサービス通知メッセージである。
【００５９】
このメッセージは有利にはメッセージを保護するセキュリティデバイスによって得られ、有利には本発明の実施形態のいずれか１つに従って構成されたメッセージ識別デバイス向けのものである。
【００６０】
本発明の別の観点として挙げられるのはセキュリティプロセスであり、このセキュリティプロセスによれば、変更可能な現在の識別鍵による識別コントロール手段をもつ少なくとも１つの受信装置へネットワークを介して発送すべきメッセージが保護される。このセキュリティプロセスは以下のステップを有する：
−使用可能な複数の暗号鍵から成る少なくとも１つのまえもって決められたセットから現在の暗号鍵を選択するステップ、これによりメッセージ各々の少なくとも一部分を暗号化することができる；
−このメッセージに鍵識別子を登録するステップ、これにより受信側は、使用可能な複数の暗号鍵から成るまえもって決められたセットに対応する使用可能な複数の識別鍵から成るまえもって決められたセットから、現在の識別鍵を選択することができ、この鍵識別子によって受信側は現在の識別鍵を、この現在の識別鍵が現在の暗号鍵に対応するよう変更できるようになる；
−現在の暗号鍵により暗号化すべきメッセージの一部分を暗号化するステップ。
【００６１】
本発明によれば暗号化ステップはこの部分の署名を生成することから成り、この場合、メッセージはサービス通知メッセージである。
【００６２】
メッセージを保護するセキュリティプロセスは有利には、本発明の１つの実施形態に従って構成されたメッセージを保護するセキュリティデバイスによってインプリメントされる。
【００６３】
さらに本発明はネットワークを介して受信されるメッセージを識別するプロセスに関し、これらのメッセージの各々は変更可能な現在の暗号鍵を用いて暗号化された部分を有する。この識別プロセスは以下のステップを有する：
−鍵識別子をこのメッセージから抽出するステップ、これによれば現在の識別鍵は使用可能な複数の識別鍵から成るまえもって定められたセットから選択され、現在の識別鍵は現在の暗号鍵に対応する；
−現在の識別鍵を用いて暗号化された部分を識別するステップ。
【００６４】
本発明によれば暗号化部分は署名であり、メッセージはサービス通知メッセージである。
【００６５】
メッセージを識別するプロセスは有利には、本発明の実施形態のいずれか１つに従って構成されたメッセージ識別デバイスを用いてインプリメントされる。
【００６６】
次に、添付の図面を参照しながら実施形態に基づき本発明について詳しく説明する。なお、本発明はこれらの実施形態に限定されるものではない。
【００６７】
図１は、第１の鍵選択形態を実装した本発明によるメッセージの送信側および受信側を示す基本構成図である。
【００６８】
図２は、認証に利用可能な図１の送信側の第１の実施形態について詳細に示す図である。
【００６９】
図３は、図２の送信側により発送される認証フィールドを含むＡＴＶＥＦサービス通知メッセージの内容を示す図である。
【００７０】
図４は、図３の認証フィールドの内容を詳細に示す図である。
【００７１】
図５は、認証フィールドが埋められた状態で図２の送信側により生成されたメッセージの中間バージョンの内容を示す図である。
【００７２】
図６は、図２に示した送信側を伴う中央サーバによりコントロールされる無線ブロードキャストタイプのブロードキャスタセットを示す図である。
【００７３】
図７は、図２の送信側と組み合わせてＡＴＶＥＦサービスメッセージの認証に利用可能な図１の受信側の第１の実施形態について詳細に示す図であるが、この場合にはシステムサービスメッセージの認証にも復号にも利用できる。
【００７４】
図８は、暗号化と認証の組み合わせに利用可能な図１の送信側における第２の実施形態について詳細に示す図である。
【００７５】
図９は、図８の送信側によって発送される認証フィールドと暗号化フィールドを含むＡＴＶＥＦサービス通知メッセージの内容を示す図である。
【００７６】
図１０は、図１の送信側の変形実施形態として用いられる鍵のブロックを伴う第２の鍵選択形態を実装する署名ライブラリを示す図である。
【００７７】
図１１は、図１の受信側の変形実施形態として使用され図１０のライブラリに対応する鍵ブロックを伴う認証ライブラリを示す図である。
【００７８】
図１２は、図２の送信側により発送される認証フィールドを含むＡＴＶＥＦサービス通知メッセージの変形実施形態の内容を示す図である。
【００７９】
図１３は、図１２による認証フィールドの内容を詳細に示す図である。
【００８０】
これらの図面は本願開示に不可欠な部分であるとみなされるものである。
【００８１】
図中、同じ要素または類似の要素には同じ参照符号が付されている。さらに図示されている後述の各機能的エンティティが必ずしも物理的にシステムのそれぞれ異なるエンティティに対応していなくてもよく、たとえば同一コンポーネントのソフトウェアまたは回路における同一部分の機能によって構成してもよい。また、図３〜図５および図９、図１２ならびに図１３において示されている数字は、表されるメッセージ中のフィールドの配分をビットで示すものである。さらに添字ＡとＣは認証エンティティを表すために使われ、添字Ｂは暗号化エンティティのために、添字Ａ′は暗号化後の認証エンティティのために使われる。
【００８２】
送受信システム（図１）は、ネットワーク５を介して１つまたは複数の受信装置２へＭＳＧメッセージを送るための１つまたは複数の送信装置１を有している。以下で詳述する実施例の場合、ネットワーク５はブロードキャスト双方向伝送ネットワークであり、ここでは（それぞれ受信装置２を伴う）複数の顧客に送信を行う（送信装置１を伴う）ブロードキャストサーバについて考察する。簡単にするため、ここでは複数の送信装置１のうちの１つと複数の送信装置２のうちの１つについてのみ考察する。
【００８３】
概略的にいえば送信装置１は、メッセージＭ０を受け取りそのメッセージを送信すべきメッセージＭＳＧに変換し、その際にネットワーク５を介して伝送するためのおよびメッセージＭＳＧと場合によっては後続のメッセージを適切な受信装置２が読み取るための種々の情報項目を付加する。これに応じて受信装置２は受け取ったメッセージＭＳＧから、メッセージＭ０によって表される意味のある内容を抽出する。メッセージＭ０は有利にはある固有のタイプのメッセージであり、後述のように送信装置１と受信装置２はすべてのメッセージタイプを同じように処理するわけではない。
【００８４】
送信装置１はたとえば（図１に示されているように）、メッセージＭ０を上述のように変換する目的で様々な要素を有しており、たとえばそれらは以下のようなものである：
−パーミッション識別子ＰＥＲＭをメッセージＭ０に挿入するよう設計されたパーミッション登録用ユニット１４；上述のパーミッション識別子ＰＥＲＭによって、受信装置の様々な機能をアクセスするため受信装置に対して制御命令を送信できるようになる。
−メッセージを安全に保護するためのデバイス３、その目的はメッセージＭ０の少なくとも一部分の暗号化（署名または秘匿化）について判断力のあるモードを規定すること、この暗号化をトリガして受信装置２のために暗号化部分を利用するための情報をメッセージＭ０に挿入することである；選ばれた例では送信装置１において登録ユニット１４はセキュリティデバイス３の上流にあり、変形実施例としてこれらのポジションが逆にされるまたは、これら２つのサブシステムのうち少なくとも一方が送信装置１の上流におかれる；
−暗号化ライブラリ１５、たとえばダイナミックリンクライブラリまたはＤＬＬ（Dynamic Link Library）、これは暗号化モジュール１７を有しており、厳密な意味では実際には送信側により簡単にアクセス可能なプログラムとすることができるけれども、一般にこのライブラリ１５は送信装置１に配分されている。
【００８５】
さらに詳しく説明すると、暗号化ライブラリ１５には暗号鍵Ｋ１，Ｋ２〜Ｋｎのインデックス化テーブル１６が設けられており、暗号化モジュール１７はメッセージを保護するためのセキュリティデバイス３によって与えられる命令に依存して、暗号鍵Ｋｉのうちの１つに従い暗号化を実行する。さらにセキュリティデバイス３は以下のユニットを有している：
−暗号化モジュール１７をトリガ可能な暗号化コントロールユニット１１、これは必要とされる情報を暗号化モジュール１７に伝えることにより行われ、詳しくは使用すべき暗号鍵Ｋｉの選択を考慮することにより行われる；
−現在の鍵を変更するためのユニット１２、これによって使用すべき現在の鍵Ｋｉを暗号化コントロールユニット１１に相応の情報を発送することで変更できるようになる。このユニット１２はたとえば、ユーザが直接介在可能な現在の鍵Ｋｉの（実現値と選択値の双方について）ランダムな変更に基づくものである；
−メッセージＭ０に鍵識別子ＫｅｙＩＤを登録するためのユニット１３、これによって受信装置２の注意喚起のため選択された現在の鍵Ｋｉを指示できるようになる。ここで示されている実施例の場合、この登録ユニット１３は関与しているタイプのメッセージＭ０における鍵識別子ＫｅｙＩＤの登録を決まった手順で実行する。
【００８６】
同様に、受信装置２は詳細には以下のユニットを有している：
受け取ったメッセージＭＳＧ内のパーミッション識別子ＰＥＲＭを読み取るユニット２４；
（認証のための復号／暗号化または復号により）メッセージＭＳＧにおける暗号化部分の関連する識別モードを規定するため、メッセージを識別しこの識別をトリガするデバイス４；
識別ライブラリ２５、これは識別モジュール２７を有しており、一般に受信装置２に配分される。
【００８７】
さらに詳しく説明すると、識別ライブラリ２５には識別鍵Ｋ′１，Ｋ′２〜Ｋ′ｎのインデックス化テーブル２６が設けられており、これは暗号化ライブラリ１５の暗号鍵Ｋ１，Ｋ２〜Ｋｎにひとつずつ対応している。識別モジュール２７は、メッセージ識別デバイス４により与えられる命令に依存して識別鍵Ｋ′ｉのうちの１つに従い識別を実行するよう設計されている。さらにメッセージ識別デバイス４は以下のユニットを有している：
−識別モジュール２７をトリガ可能な識別コントロールユニット２１、これは必要とされる情報を識別モジュール２７に伝えることにより行われ、詳しくは使用すべき鍵Ｋ′ｉの選択を考慮することにより行われる；
−メッセージＭＳＧから鍵識別子ＫｅｙＩＤを抽出するためのユニット２３、これにより送信装置２の現在の暗号鍵Ｋｉに応じて選択された現在の識別鍵Ｋ′ｉが与えられる。
【００８８】
上述の簡単な説明は本質的に機能的であり、もっぱらメッセージを安全に保護し識別するための固有のシステムと関連した特徴の中心にある。実際には送信装置１に、場合によっては組み合わせで参照符号１５が付されているような複数のセキュリティデバイスをもたせることができる。たとえばメッセージの安全な保護が秘匿化と署名を合わせもつようにし、および／または異なるタイプのメッセージに対しそれぞれ別個のデバイスが適用される。同様に、受信装置２に複数の識別デバイスをもたせることができる。このような可能性については個々の実施形態を参照しながらあとで詳しく説明する。
【００８９】
参照符号１Ａ（図２）の付された送信装置１における第１の実施形態は認証に適用される。この実施形態によれば送信装置１Ａは、パーミッション識別子ＰＥＲＭを安全に保護し登録するためのオペレーションのためにはサービス通知メッセージ service announcement message Ｍ０だけしか必要とせず、（コンテンツメッセージやトリガなどのような）他のタイプのメッセージはここでは必要とされない。考慮されるサービス通知メッセージの例はＡＴＶＥＦ通知メッセージ ATVEF announcement message あるいはシステム通知メッセージ system announcement messageであって、これら２つのタイプのメッセージは考察中の実施例では同様の構造をもっている。生成されるメッセージＭＳＧ（参照符号ＭＳＧ−Ａ）はネットワーク５を介してブロードキャストされる。
【００９０】
前述の実施例の場合、暗号鍵Ｋｉ（署名鍵）は秘密鍵であり、識別鍵Ｋ′ｉ（認証鍵）は顧客に配布してよい公開鍵であって、これは場合によってはネットワーク５を介して行われる（このとき伝送を安全に保護すると有利である）。さらに特別な実施形態の場合、署名鍵Ｋｉは各々５９６ｂｙｔｅを有しており、識別鍵Ｋ′ｉは各々１４８ｂｙｔｅの復号鍵であり、これらの鍵はそれぞれ署名鍵Ｋｉから生成され、顧客の中に存在するよう伝送される。それぞれ署名鍵と認証鍵各々のインデックス化テーブル１６，２６は、たとえば１０個の対応する鍵を有している。
【００９１】
送信装置１Ａには基本的に以下のものが設けられている：
参照符号３１Ａの付されたサーバドライブシステム３１、これには現在の鍵を変更するためのユニット１２と、鍵識別子ＫｅｙＩＤを登録するためのユニット１３と、パーミッション識別子ＰＥＲＭを登録するためのユニット１４が含まれている。このドライブシステム３１Ａは、情報源１０からメッセージＭ０を取り出してメッセージＭ１を生成するように設計されており、このメッセージには参照符号ＫｅｙＩＤ［ＳＧＮ］で表される認証用鍵識別子ＫｅｙＩＤとパーミッション識別子ＰＥＲＭが含まれているが署名はない；
ブロードキャストサーバ３２Ａ、これにはたとえばサーバ３２Ａのすべての要素の動作をコントロールするコントロールユニット３７（見やすくするため図２には接続関係は示されていない）と、ドライブシステム３１Ａから発せられたメッセージＭ１を収集するよう設計されたデータベース３３が含まれており、このブロードキャストサーバ３２ＡはメッセージＭ１をメッセージＭＳＧ−Ａに変換するために用いられる；
認証ライブラリ１５Ａの形式をとる暗号化ライブラリ１５。
【００９２】
ブロードキャストサーバ３２Ａは、メッセージＭ１に対して連続的に動作する２つのモジュールすなわち仕上げモジュール３５とカプセル化モジュール３６を有している。認証コントロールユニット１１Ａの形態の暗号化コントロールユニット１１を含む仕上げモジュール３５の役割は、補足情報（インターネットアドレス、ポート等）をメッセージＭ１に登録してメッセージＭ２を生成すること、認証ライブラリ１５Ａを呼び出し署名ＳＧＮを生成してメッセージにＭ２に組み込み、それによってメッセージＭ３を生成することである。認証ライブラリ１５Ａにディスパッチされる認証鍵識別子ＫｅｙＩＤ［ＳＧＮ］がメッセージＭ２内に存在することで、認証ライブラリ１５Ａは即座に望ましい鍵Ｋｉを選択して署名ＳＧＮを生成できるようになる。有利には現在の暗号鍵Ｋｉはライブラリ１５Ａ内に保持される。
【００９３】
ブロードキャストサーバ３２Ａがライブラリ１５Ａに対し署名を下請けに出すこと、ならびに現在の鍵Ｋｉをサーバ３２Ａではなくライブラリ１５Ａに記録できることによって、サーバ３２Ａは一般的な特性を維持することができる。そのうえ重要であるのは、上述のことでドライブシステム３１Ａとライブラリ１５Ａがともに、鍵識別子ＫｅｙＩＤ［ＳＧＮ］とパーミッション識別子ＰＥＲＭに関するオペレーションのコントロールを保有できることである。しかも有利であるのは、一連の流れの最後に署名ＳＧＮが付加され、これがブロードキャストサーバ３２Ａによりブロードキャストされる直前に行われることである。なぜならば、このことで署名ライブラリ１５Ａと暗号鍵Ｋｉを複製する必要なく非常に多くの顧客によって署名を供給することができるからであり、かつ鍵識別子ＫｅｙＩＤ［ＳＧＮ］の変更を集中化させることができるからである。さらに圧縮および／または秘匿化が行われる場合、それらのオペレーションの後に署名が付けられる。
【００９４】
署名ＳＧＮは有利には通知メッセージＭ２全体にわたり計算される。ここでメッセージＭ２にはヘッダ（これは殊に識別子ＫｅｙＩＤ［ＳＧＮ］とＰＥＲＭを有する）とペイロードが含まれており、これによってたとえば現在の鍵ＫｅｙＩＤ［ＳＧＮ］（したがって顧客による認証用）とパーミッションに関するデータに対するどのような外部の変更も検出できる。
【００９５】
カプセル化モジュール３６は、ネットワーク５を介した伝送用の階層のカットおよび付加により通知メッセージＭ３を伝送するためのものである。ここに示されている実施例の場合、モジュール３６はＩＰ（Internet Protocol）パケットをＵＤＰ（Unidirectional Data Protocol）／ＩＰ／ＳＬＩＰ（Serial Line IP）層によって生成する。コンテンツメッセージのためにモジュール３６はあらかじめ、ＵＨＴＴＰ（Unidirectional HyperText Transfer Protocol）プロトコルとＭＩＭＥ（Multipurpose Internet Mail Extensions）フォーマットを利用する。
【００９６】
このため署名されたメッセージＭＳＧ−Ａにより顧客各々は、提供されるサービスの真正性を照合することができる。つまり顧客が署名ＳＧＮを有効であると認めれば、顧客はコンテンツメッセージおよび場合によってはそれに続くべきトリガのためのリスニングチャネル（ソケット）をオープンする。有効であると認められなければ、顧客は通知メッセージＭＳＧ−Ａを考慮に入れず拒否する。署名ＳＧＮを認証するため顧客は鍵識別子ＫｅｙＩＤ［ＳＧＮ］を使用し、これによって顧客は適切な識別鍵Ｋ′ｉを対応する識別ライブラリ２５（認証ライブラリ）から即座に選択することができる。したがって顧客はソケットをオープンすべきか否かを迅速に判定することができ、そのため順次到来するコンテンツパケットのすべてあるいはいくつかが失われてしまうのを回避できる。たとえば第１のコンテンツパケットが通知メッセージ後５００ｍｓのときにブロードキャストされたならば、署名照合ならびにソケットオープンオペレーションをこの期間中に実行完了させることが必須である。
【００９７】
以下、送信装置１Ａにおける１つの固有のインプリメンテーションについて挙げておく。この実施例の場合、ＡＴＶＥＦタイプの通知メッセージＭＳＧ−ＡはマルチキャストＩＰアドレス２２４．０．１．１１３、ポート２６７０でブロードキャストされ、システムタイプの通知メッセージはマルチキャストＩＰアドレス２３５．０．１．１１３、ポート３２６７０でブロードキャストされる。メッセージＭＳＧ−Ａ（図３）の各々は、参照符号ＳＡＰ−Ａの付されたＳＡＰフォーマットのヘッダとＳＤＰフォーマットのペイロードから成り、この場合、ヘッダＳＡＰ−Ａは以下のフィールドによって構成されている：
−ＳＡＰのバージョンＶ（３ｂｉｔ，Ｖ＝１）
−５項目から成るＡＲＴＥＣ（５ｂｉｔ）
−アドレスタイプＡ（ＩＰｖ４プロトコルは１、ＩＰｖ６プロトコルは０）；
−予約フィールドＲ（０）;
−メッセージタイプＴ（セッション通知パケット０、セッション保証パケット１）；
−暗号化フィールドＥ（「暗号化」について：ＳＤＰ非暗号化は０、ＳＤＰ暗号化は１）；
−圧縮Ｃ（非圧縮ペイロードは０、圧縮ペイロードは１）；
−認証フィールドＡＵＴＨの長さＬ−ＡＵＴＨ（８ｂｉｔの符号のない値）、認証フィールドには参照符号ＡＵＴＨ−Ａが付されＳＤＰの直前に挿入され３２ｂｉｔワードの数値として表現される；
−ハッシュ識別子（ディジタル署名のためインターネットで用いられる保護アルゴリズム）ＭＳＧ ＩＤ ＨＡＳＨ（１６ｂｉｔ）、ＳＤＰフィールドが変更されるときは常にハッシュ値も変更されなければならない。この識別子が０であれば、顧客は常にＳＤＰに構文解析（パーシング）を受けさせる必要がある；
−送信装置１Ａつまりはブロードキャストサーバ３２ＡのＩＰアドレス、参照符号ＯＲＩＧ（１ワード３２ｂｉｔ）；ハッシュ識別子の値が０でありマンダトリサーバmandatory server（プロキシ）を通過しなければ、このアドレスを０．０．０．０にセットできる；
認証フィールドＡＵＴＨ−Ａ、この長さはパラメータＬ−ＡＵＴＨにより決められる。
【００９８】
認証フィールドＡＵＴＨ−Ａ（図４）は１２８ｂｙｔｅの署名フィールドＳＧＮだけでなく、ＥＮＴ−Ａで表される固有の認証ヘッダも有しており、これは４ｂｙｔｅを占め、以下のサブフィールドを有する：
−使用されるプロトコルのバージョンＶ（３ｂｙｔｅ，Ｖ＝１）；
−パディング識別子Ｐ（１ｂｉｔ）、これはダブルワード（３２ｂｉｔワード）の倍数の全長をもつ認証フィールドで完結させるよう場合によってはパディングが存在することをシグナリングするために用いられる；この実施例の場合、認証フィールドが１３２ｂｙｔｅの全長をもっているためＰ＝０（パディングなし）である；
−使用される認証タイプＴＹＰＥ（４ｂｉｔ）；この事例ではＴＹＰＥ＝０（ＰＧＰフォーマット、Pretty Good Privacyのこと）；
−ＰＥＲＭパーミッションフラグ（８ｂｉｔ）；
−将来の使用のために予約されたフィールド（８ｂｉｔ）；
−鍵識別子ＫｅｙＩＤ［ＳＧＮ］（８ｂｉｔ）。
【００９９】
したがってヘッダＥＮＴ−Ａには、殊に顧客のために使われる２つのバイトが含まれており、すなわちフィールドＫｅｙＩＤ［ＳＧＮ］のバイトとＰＥＲＭのバイトであり、これによってそれぞれ顧客は適切な認証鍵Ｋ′ｉを即座に決定することができ、サービスにおける後続のメッセージ（コンテンツメッセージとトリガ）に関して適切なパーミッションを求めることができる。
【０１００】
この実施例では、パーミッションフラグＰＥＲＭのために利用可能なバイトは８つの値のマスクという形態で利用される。パーミッションフラグＰＥＲＭは、受信装置２におけるいわゆるクリティカルなリソースに関して以下の機能に対するアクセスに関係する（認証値はさしあたり１６進数で与えられる）：
−0x0001：受信装置２のモデムにアクセスして、送信装置１にかかわるサービスオペレータのオンラインサーバとのコネクションを開始させる；
−0x0002：受信装置２のモデムにアクセスして、何らかのサービスオペレータのオンラインサーバとのコネクションを開始させる；
−0x0004：１つのオンラインサーバとの安全なコネクションを利用する；
−0x0008：受信装置２のハードディスクにアクセスして、そこからデータを読み出すかまたはそこに永続的にデータを書き込む；
−0x00010：受信装置２のフラッシュメモリにアクセスして、そこからデータを読み出すかまたはそこに永続的にデータを書き込む；
−0x00020：受信装置２のチップカードにアクセスして、そこからデータを読み出すかまたはそこに永続的にデータを書き込む；
−0x00040：受信装置２のチューナにアクセスして現在の局を変更する。
【０１０１】
１つの変形実施形態によれば、パーミッションに利用可能なバイトは２５６エントリをもつテーブルの形態で使用され、それらのエントリ各々はただ１つのパーミッションレベルに対応している。上述の実施例では８つのパーミッションが得られ、それらを互いに組み合わせることができる。
【０１０２】
パーミッションの個数を難なく増やすことができ、これはたとえば１ｂｙｔｅの予約フィールドをパーミッションフィールドに組み入れたり（１６個のパーミッションへの切り換え）、および／または２つのダブルワードを１つのダブルワードの代わりに認証フィールドＡＵＴＨ−ＡのヘッダＥＮＴ−Ａに割り当てることによって行われる。
【０１０３】
動作中、ドライブシステム３１はＳＡＰフォーマットのヘッダをサービス通知メッセージＭ０に付加し、詳しくはその中にはこのサービスのためのパーミッションフラグＰＥＲＭならびに場合によっては鍵識別子ＫｅｙＩＤ［ＳＧＮ］が組み込まれる（鍵識別子はドライブシステム３１によってコンフィギュレーション可能であるがデフォルトではライブラリ１５Ａによって決められる）。認証フィールドＡＵＴＨ−Ａの長さＬ−ＡＵＴＨは１ダブルワード（Ｌ−ＡＵＴＨ＝１）で固定されており、その中に署名ＳＧＮに伴わずにヘッダＥＮＴ−Ａが登録されるようになる。このようにして得られたメッセージＭ１（図５）には、ＳＡＰフォーマットのヘッダ（ＳＡＰ１で表す）の認証フィールドＡＵＴＨ１（略してＥＮＴ１）内にパーミッションフラグＰＥＲＭと予約フィールドしか含まれておらず、これは０で初期化されている。このメッセージはブロードキャストサーバ３２Ａのデータベース３３で受け取られる。
【０１０４】
ついで仕上げモジュール３５はヘッダＳＡＰ１が存在するか否かを照合し（存在しなければ署名なしでそれを加える）、要求される補足情報（コンテンツメッセージとトリガのアドレスとポートによるＳＤＰのいわゆるパッチ）をＭ１に登録し、ライブラリ１５Ａを呼び出し、引数としてメッセージＭ１を含むバッファメモリとバッファサイズを与える。
【０１０５】
ライブラリ１５Ａは以下のオペレーションを実行する：
−パーミッションフラグＰＥＲＭが存在するか否かの照合；存在するのであれば通常どおりオペレーションが継続され、存在しないのであればエラーコードがブロードキャストサーバ３２Ａに戻される。改善されたバージョンではパーミッションフラグＰＥＲＭが存在していないのであれば、デフォルトマスクが割り当てられる；
−サービス通知メッセージＭ１がすでに署名されているか否かの照合；すでに署名されているならばブロードキャストサーバ３２Ａに戻される；
−まだ署名されていないならば、長さＬ−ＡＵＴＨが１３２ｂｙｔｅ（0x21ダブルワード）に更新され、認証フィールドＡＵＴＨ−ＡのヘッダＥＮＴ−Ａの付加および更新が行われ、（Ｌ−ＡＵＴＨ＝１による）計算ならびに署名ＳＧＮのバッファへの付加ならびにバッファサイズの更新が行われる；署名ＳＧＮはヘッダＳＡＰ１全体（Ｌ−ＡＵＴＨ＝１であるから署名フィールドＳＧＮは含まれない）から、およびメッセージＭ１のペイロードから決定される。これはＲＳＡ（Rivest - Shamir - Adelman）アルゴリズムを用い、さらにこれ全体にわたりハッシュＭＤ５を計算し、適切な現在の鍵Ｋｉを抽出し、その鍵ＫｉでハッシュにおけるＲＳＡ署名の計算を行うことにより得られる。１つの実施形態によれば、認証フィールドＡＵＴＨ−Ａは署名に関して完全に無視される（１つのらブルワードの代わりにＬ−ＡＵＴＨ＝０）；
−ブロードキャストサーバ３２Ａへ戻す。
【０１０６】
次に、カプセル化モジュール３６はこのようにして得られたメッセージＭ３をカプセル化し、その後、ネットワーク５を介してブロードキャストされる。
【０１０７】
この技術によれば、たとえサービスが１つのカルーセルとしてまたは１つのオカレンスとしてディスパッチされる（ワンショット）としても、サービスごとに必ず１回だけ署名が計算される（これは通知メッセージにおいて計算される）。
【０１０８】
鍵識別子ＫｅｙＩＤ［ＳＧＮ］を変更するためメッセージはたとえば、アプリケーションをプログラミングするためのインタフェースあるいはＡＰＩ（Application and Programming Interface）を介してブロードキャストサーバ３２Ａへディスパッチされ、ついでサーバ３２Ａはその識別子の新たな値をライブラリ１５Ａに通知するだけである。この場合、変更はたとえば毎月規則的に実行される。
【０１０９】
以下で例示するブロードキャストサーバ３２Ａの入力（Ｍ１）と出力（ＭＳＧ−Ａ）におけるサービス通知メッセージの例において、ヘッダＳＡＰ１は角括弧の中のボールドのキャラクタで表され、認証フィールド（ＡＵＴＨ１，ＡＵＴＨ−Ａ）のヘッダ（ＥＮＴ１，ＥＮＴ−Ａ）はアンダーラインで、さらにペイロードは通常のキャラクタで表されている（表記は１６進数）。
【０１１０】
L-AUTH＝0x01, PERM＝0x27 および0x00と等しい３つの予約バイトに関してメッセージＭ１は以下の通りである。
【０１１１】
【数１】
L-AUTH＝0x21, PERM＝0x27, KeyID＝0x07に関して、ブロードキャストサーバ３２ＡによるメッセージＭ０の処理後に得られるメッセージＭＳＧ−Ａは以下の通りである。
【０１１３】
【数２】
送信装置１Ａ（図６）の固有の実施形態の場合、サービスオペレータの中央ドライブシステム４０は中央サーバ４５を有しており、これは専用リンク（専用回線）４６を介してブロードキャスタ４１，４２，４３と接続されている。また、ブロードキャスタ４１〜４３の各々はあとで詳しく説明するサーバ３２Ａのタイプのブロードキャストサーバ３２と、オーディオビジュアルプログラムをブロードキャストするデバイス４７と、参照符号４８の付されたＶＢＩエンコーダとを有している。ＶＢＩエンコーダの役割は、サーバ３２からの情報とデバイス４７からの情報を符号化すること、ならびにアンテナ４９に向けてそれらの情報をブロードキャストすることである。
【０１１５】
オペレーション中、中央ドライブシステム４０は様々なソース（ブロードキャスタ、アドバタイザ、コンテンツプロバイダ等）からブロードキャストすべきサービスに関する情報を取得し、それらの情報のブロードキャスト動作をプログラムし、ついでブロードキャストされる少し前にブロードキャストサーバ３２がそれらの情報を利用できるようにする。これによって殊に、ディジタル証明書５１，５２，５３がブロードキャスタ４１〜４３へそれぞれ配送されることで公開鍵の真正性が保証される。この中央ドライブシステム４０は上述のドライブシステム３１の機能も果たし、したがってブロードキャスタ４１〜４３によりブロードキャストされるサービス通知メッセージＭＳＧに選択的にパーミッションを与えることができ、受信時の認証において不都合な遅延を引き起こすことなく可変の鍵を用いて署名することができる。
【０１１６】
受信装置２の各々はたとえば以下のものを有している（図７）：
−参照符号６１の付されたＶＢＩドライブ、これは（ブロードキャスタ４１〜４３のような）送信装置１Ａから受信しフィールドＷＳＴ（World Standard Teletext）をもつ情報からペイロードを抽出し、エラーコントロールコードＦＥＣ（Forward Error Correction）を計算し、ペイロードにおけるＳＬＩＰフレームのデコーディングをコントロールするよう設計されている；
ネットワーク５を介して伝送するためにレイヤを非カプセル化するモジュール、これは復号されたＳＬＩＰフレームをドライブ６１から受け取ることができ、復号後、サービス通知メッセージＭＳＧのためのＳＤＰフォーマットのペイロードにおいてＳＡＰフォーマットのヘッダの形式でＩＰ／ＵＤＰフレームの内容を抽出することができる；
−ブラウザ６３、これには上述のタイプの識別デバイス４とパーミッション読み取りユニット２４（それぞれ参照符号４Ｎ，２４Ｎでそれぞれ表す）が設けられている；
−ローダ６７、これには上述のタイプの識別デバイス４とオプションパーミッション読み取りユニット２４（参照符号４Ｃ，２４Ｃでそれぞれ表す）が設けられている；
−参照符号２５の付された上述のタイプの認証ライブラリ、この場合、鍵インデックス化テーブル２６が受信装置２の不揮発性メモリたとえばフラッシュメモリタイプのメモリにライブラリ２５のコードとして格納されている。
【０１１７】
ブラウザ６３は、各サービス通知メッセージＭＳＧ−Ａを受信すると以下の機能を実行するように設計されている：
−リスニングソケット６４を介してメッセージＭＳＧ−Ａのヘッダとペイロードを取り出す；
−入力としてメッセージＭＳＧ−Ａへのポインタを与えることでライブラリ２５における署名照合機能を呼び出す；
−認証が成功したならば、コンテンツメッセージおよび後続のトリガのためにそれぞれリスニングソケット６５，６６をオープンする、これはメッセージＭＳＧ−ＡのパーミッションフラグＰＥＲＭにより表されるパーミッションを適用することにより行われ、ブロードキャストアプリケーションに適用すべきブラウザ６３の機能へのアクセスを指定する。
【０１１８】
ライブラリ２５の署名照合機能により、詳細には以下のオペレーションが実行される：
−署名なしヘッダＳＡＰ−Ａとペイロード全体におけるハッシュＭＤ５の計算、インジケータＬ−ＡＵＴＨによって認証フィールドＡＵＴＨ−Ａの長さが与えられ、これは１にセットされる；署名計算のために指示されるこのフィールドに対応する１つの変形実施形態によれば、認証フィールドＡＵＴＨ−Ａは認証に関して無視され、インジケータＬ−ＡＵＴＨは０にセットされる；
−ヘッダＳＡＰ−Ａの認証フィールドＡＵＴＨ−Ａにおける鍵識別子ＫｅｙＩＤ［ＳＧＮ］を抽出し、適切な認証鍵Ｋ′ｉを選択する；
−ＲＳＡタイプによる認証フィールドＡＵＴＨ−Ａの署名ＳＧＮの照合、これは選択された鍵Ｋ′ｉを用いた署名のハッシュにおける再計算により行われ、署名が無効であれば値０が戻される；
−署名ＳＧＮが有効であれば、パーミッションフラグＰＥＲＭが戻される。
【０１１９】
したがってメッセージＭＳＧ−Ａのペイロードは、認証が成功した場合を除いて無視される。逆の事例では、通知されたサービスにおける後続のメッセージのためにリスニングソケットはオープンされず、顧客は到来したデータに対しリスニングしない状態を維持する。
【０１２０】
ローダ６７の動作は、リスニングソケット６８を介して受け取ったシステム通知メッセージに関しては同様である：ソケット６９は、ライブラリ２５の呼び出しによりメッセージが認証されたときのみ後続のコンテンツメッセージのためにオープンされる。
【０１２１】
参照符号１Ｂ（図８）で表されている送信装置１に関する第２の実施形態は、秘匿化と認証の組み合わせに用いられる。この実施形態と上述の実施形態との基本的な相違点は、送信装置１Ｂ内に署名要素を補足するかたちで暗号化による秘匿化要素が設けられていることであり、これは署名要素の上流で動作するよう設計されている。暗号化による秘匿化要素と署名の要素はそれぞれ、鍵インデックス化テーブル１６（図１）から現在の２つの暗号鍵を選択することに基づいており、上述のように一般的なやり方で暗号化ライブラリ１５のタイプの秘匿暗号化ライブラリ１５Ｂと署名ライブラリ１５Ａ′をそれぞれ呼び出す。受信装置２は、暗号鍵インデックス化テーブルに対応するインデックス化復号テーブルを有しており、これらの復号鍵は有利には非公開ないしは秘密である。インデックス化暗号テーブルおよびインデックス化復号テーブルは、たとえば各々１０個の鍵を有している。
【０１２２】
したがって参照符号３１Ｂの付されたドライブシステム３１は、現在の鍵を変更するためのユニット１２と、秘匿暗号化のためのメッセージ（それぞれ１２Ｂ，１３Ｂ）を安全に保護するためおよび秘匿暗号化後の署名（それぞれ１２Ａ′，１３Ａ′）のためのデバイス１３の双方を有している。
【０１２３】
さらに参照符号３２Ｂの付されたブロードキャストサーバ３２には、暗号コントロールユニット１１Ｂを有する仕上げおよび秘匿暗号化モジュール３４と、このモジュール３４の下流に設けられ署名コントロールユニット１１Ａ′を有する署名モジュール３８が設けられており、各コントロールユニット１１Ｂ，１１Ａ′は暗号化コントロールユニット１１のタイプである。このサーバ３２Ｂは第１の実施形態と同じようにして、参照符号ＡＵＴＨ−Ｂで表される認証フィールドＡＵＴＨをＳＡＰフォーマットのヘッダに組み入れる。
【０１２４】
仕上げおよび秘匿暗号化モジュール３４の役割は上述の第１の実施形態のように、必要とされる補足情報をメッセージＭ１に付加すること、ならびに暗号ライブラリ１５Ｂを呼び出して取得されたメッセージＭ４を秘匿暗号化することであり、これは秘匿暗号化ライブラリ１５Ｂに暗号鍵識別子ＫｅｙＩＤ［ＣＲＹＰＴ］を伝達することによって行われる。この場合、ライブラリ１５Ｂの暗号化モジュール１７（図１）によってペイロードの暗号化が実行されるけれども、ヘッダまたは認証フィールドＡＵＴＨ−Ｂの初期データの暗号化は実行されない。鍵識別子ＫｅｙＩＤ［ＣＲＹＰＴ］はたとえばランダムに生成される。
【０１２５】
署名モジュール３８は、この暗号化の結果として得られ殊に認証鍵識別子ＫｅｙＩＤ［ＳＧＮ］をもつメッセージＭ５を暗号ライブラリ１５Ｂから受け取り、さらに署名ライブラリ１５Ａ′を呼び出して、署名されたメッセージＭ６を取得するように設計されている。ライブラリ１５Ａ′の暗号化モジュール１７（図１）によってメッセージＭ５全体に係わる署名が決定されて添付され、これは前述の実施形態のように鍵識別子ＫｅｙＩＤ［ＳＧＮ］により与えられた現在の鍵を用いて行われる。
【０１２６】
カプセル化モジュール３６は前述のものと同じ役割を果たし、これにより参照符号ＭＳＧ−Ｂの付されたブロードキャストすべきメッセージＭＳＧが得られるようになる。
【０１２７】
一例として（図９参照）メッセージＭＳＧ−Ｂはそのペイロードに加えて、参照符号ＳＡＰ−Ｂの付されたＳＡＰフォーマットのヘッダを有しており、これは以下のように構成されている：
−フィールドＶ、ＡＲＴＥＣ，Ｌ−ＡＵＴＨ，ＭＳＧ ＩＤ ＨＡＳＨ，ＡＵＴＨ−Ｂ、これらは第１の実施形態と同様である；
−秘匿化暗号鍵識別子ＫｅｙＩＤ［ＣＲＹＰＴ］（１ダブルワード）；
−時間超過を表すインジケータＴＩＭＥＯＵＴ（１ダブルワード）、これが有用となるのはペイロードが秘匿暗号化されるときおよび通知メッセージの送信にプロキシが係わるときである；
−秘匿暗号化前のパディングをシグナリングするパディングインジケータＰ（１ｂｉｔ）、この場合、復号されたペイロードの最後のバイトによって付加されたパディングバイトの数が表される；
−真の乱数を含み復号後に廃棄されることを意図した乱数フィールド（３１ｂｉｔ）。
【０１２８】
暗号化フィールドのセットＣＲＹＰＴは識別子Ｐ、乱数フィールドならびにペイロードから成り、他方、識別子ＫｅｙＩＤ［ＣＲＹＰＴ］とフィールドＴＩＭＥＯＵＴは暗号化されてない暗号ヘッダＥＮＴ−ＣＲＹＰＴを成す。
【０１２９】
関連する暗号化ライブラリおよび識別ライブラリ（図１０，図１１）のペアのうちいずれか１つに適用可能な１つの変形実施形態によれば、暗号化ライブラリ７５は鍵テーブルの代わりに暗号鍵のブロックＢ１，Ｂ２〜Ｂｎのインデックス化テーブル７６を有している。ブロックＢｉそれ自体は各々複数の鍵Ｋｉ，１，Ｋｉ，２〜Ｋｉ，ｌｉを有しており、その個数は考慮されるブロックに従って可変である。同様に、識別ライブラリ８５は識別鍵のブロックＢ′１，Ｂ′２〜Ｂ′ｎのインデックス化テーブル８６を有しており、それらのブロックＢ′ｉは各々、暗号化ライブラリ７５のブロックＢｉの鍵Ｋｉ，１，Ｋｉ，２〜Ｋｉ，ｌｉにそれぞれ対応する複数の鍵Ｋ′ｉ，１，Ｋ′ｉ，２〜Ｋ′ｉ，ｌｉを有している。
【０１３０】
したがって鍵識別子ＫｅｙＩＤを知っていても、暗号化モジュール７７による暗号化のために選ばれた鍵Ｋｉ，ｊを１対１のかたちで突き止めることはできず、したがってライブラリ８５の識別モジュール８７により使用されるべき対応の識別鍵Ｋ′ｉ，ｊを突き止めることはできず、それぞれこれらの鍵が属するブロックＢｉおよびＢ′ｉだけである。このため識別ブロックＢ′ｉの鍵すべてを、復号が成功するまで連続的に試さなければならない。
【０１３１】
識別子の１つの変形実施形態によれば、認証鍵識別子ＫｅｙＩＤ［ＳＧＮ］および／またはパーミッション識別子ＰＥＲＭは、メッセージＭＳＧのヘッダにおいて認証フィールドＡＵＴＨの外側にある。したがって認証のためのメッセージは、署名計算ＳＧＮにそれらの識別子を含めることによって暗号化することができるが、他方、認証フィールドＡＵＴＨ（Ｌ−ＡＵＴＨ＝０）は除外される。
【０１３２】
別の実施形態（図１２，図１３）の場合、パーミッションフラグＰＥＲＭはペイロードフィールド内に配置される。この実施例によれば参照符号ＭＳＧ−Ｃの付された生成されたサービス通知メッセージＭＳＧには、参照符号ＳＡＰ−Ｃで表されたＳＡＰフォーマットのヘッダが含まれており、これにはパーミッションは伴わないが認証フィールドＡＵＴＨ−ＣのヘッダＥＮＴ−Ｃにおける２ｂｙｔｅの予約フィールドが設けられている。参照符号ＳＤＰ−Ｃの付されたＳＤＰフォーマットのペイロードはたとえばフィールドの最初に、２ｂｙｔｅのパーミッションフラグＰＥＲＭを有している。パーミッションフィールドは、バイナリフォーマットではなくテキストでの書き込みが要求されるためにヘッダスペースよりも多くのペイロードスペースとパーミッションフィールド識別ラベルを必要とする。
【０１３３】
次に、ＭＰＥＧ−２標準に準拠するネットワークを介したＭＨＰ標準に従ってデータをディジタルブロードキャストする適用例について詳しく説明する。この適用例は、ＭＰＥＧ−２標準（ISO/IEC 13818-1）で指定されているＰＭＴテーブル（Program Map Table）とＡＩＴテーブル（Application Information Table）の保護に関するものであり、この場合、ＰＭＴテーブルのスクランブルはＭＰＥＧ−２標準によって禁じられている。上述のメカニズムのため、ルート証明書発行局（root certification authority）が設立されており、オプションとして他の証明書発行局も設立される。
【０１３４】
ＰＭＴテーブルは、インタラクティブにまたはその他のやり方でサービスをシグナリングするための重要なエントリポイントを成している。インタラクティブＭＨＰアプリケーションの事例の場合、ＰＭＴテーブルにはＡＩＴテーブルを搬送するストリームと、コードおよびアプリケーションデータ（ＤＳＭ−ＣＣ ＤＳＩへのポインタ、"Digital Storage Media - Command and Control"および"Digital Speech Interpolation"を意味する）を搬送するストリームのポジションが含まれている。
【０１３５】
シグナリングの保護はハッシュコードと署名と証明書に基づいている。これらの暗号メッセージの符号化は、それぞれhash＿descriptor, signature＿descriptorおよびcertificate＿descriptorで表される新しい３つのデスクリプタを導入することによって行われる。
【０１３６】
最初のデスクリプタhash＿descriptorは、ＡＩＴテーブルまたはＰＭＴテーブルにおける第１のループまたは第２のループに配置することができる。ハッシュコードは特定のループ内で、ポインタが指すデスクリプタにおいて計算される。次の階層レベルのデスクリプタループは低レベルのハッシュコードを有することができる。hash＿descriptorのシンタックスはたとえば以下のパラメータを用いて定義される：
−digest＿count：ハッシュデスクリプタにおけるプリプロセッシング値（digest value）の数を識別する１６ｂｉｔの値；
−digest＿type：関連するデスクリプタのために場合によっては使用可能なプリプロセッシングアルゴリズムを識別する８ｂｉｔの値；以下の中から割り当て値が選ばれる：
−０：プリプロセッシング長０、認証なし；
−１：プリプロセッシング長１６、ドキュメントＲＦＣ１３２１において定義されているハッシュアルゴリズムＭＤ５；
−２：プリプロセッシング長２０、ドキュメントＦＩＰＳ−１８０−１において定義されているハッシュアルゴリズムＳＨＡ−１（ＳＨＡは"Secure Hash Algorithm"を意味する）；
−その他：将来の可能性のために予約；
−descriptor＿count：プリプロセッシング値に関連するデスクリプタの数を識別する１６ｂｉｔの値、この値は０よりも大きくなければならない；
−descriptor＿pointer：ハッシュ計算の一部を成すデスクリプタを識別するポインタ；
−descriptor＿tag：descriptor＿pointerパラメータが指すデスクリプタのタグ；
−digest＿length：各プリプロセッシング値のバイト数を表す整数値；これは上述のようにdigestタイプパラメータに関してプリプロセッシングのタイプに依存する；
−digest＿byte：プリプロセッシング値の１つのバイトを含む８ｂｉｔの値。
【０１３７】
したがってhash＿descriptorデスクリプタのシンタックスは以下のように記述される：
【０１３８】
【数３】
第２のデスクリプタsignature＿descriptorのために（hash＿descriptorデスクリプタについてすでに定義されているパラメータに加えて）以下のパラメータが使用される：
−signature＿id：この識別子により、権限をもつ複数の局（authority）の署名を使用できるようになる；
−signature＿length：次のループの長さを表す；
署名固有のフィールドについては以下で説明する。
【０１４０】
デスクリプタループにおける第１のhash＿descriptorデスクリプタの前に配置されるデスクリプタは以下のシンタックスを有する：
【０１４１】
【数４】
「署名固有データ」"signature specific data"フィールドには、ASN. 1（Abstract Syntax Notation one）DER仕様言語で以下のように表現される構造が含まれている：
【０１４３】
certificateIdentifierフィールドによって、署名の照合に使用される証明された公開鍵をもつ証明書が識別される。これはAuthorityKeyIdentifierタイプフィールドのためのITU-T（"International Telecommunication Union - Telecommunications Standardization Sector"）extension X.509 [54] に従って定義される。AuthorityKeyIdentifierタイプフィールドの構造には殊に、オプションの鍵識別フィールドKeyIdentifier（KeyIdentifierタイプ）が含まれている。さらにこれにはauthorityCertIssuer（GeneralNamesタイプ）要素とauthorityCertSerialNumber（CertificateSerialNumberタイプ）要素も含まれていて、authorityCertIssuer要素自体には使用される公開鍵をもつ証明書の値を有する"directoryName"フィールドが含まれ、authorityCertSerialNumber要素は対応するシリアル番号を表す。先験的にオプションとしてAuthorityKeyIdentifierフィールドタイプであるこれら２つの要素は埋められていなければならない。したがって以下のようにする：
【０１４４】
デスクリプタストリング内で最初のsignature＿descriptorデスクリプタの前に配置されているcertificate＿descriptorデスクリプタには、ITU-T X.509標準により定義されている単一の「証明 "certificate"」データ構造をもつ"certificate()" fieldが含まれている。デスクリプタの構造は以下のパラメータに依存して表現される：
−signature＿id：証明を特定の署名に結合する識別子；
−certificate＿here＿flag：値１であれば証明がデスクリプタ内に配置されていることを表し、そうでなければアプリケーションの証明を用いる必要があり、この場合、結合を以下のように定義すべきである；
−certificate＿count：証明デスクリプタにおける証明の数を表す１６ｂｉｔの整数；
−certificate＿length：証明におけるバイト数を指定する２４ｂｉｔの整数。
【０１４５】
したがってcertificate＿descriptorデスクリプタの構造は以下のようにして指定される：
【０１４６】
【数５】
上述の方法によって、ＰＭＴテーブルとＡＩＴテーブルを不正操作や侵害行為から保護できるようになる。また、ネットワークの前処理においてストリームが再度多重化される可能性や、ＰＩＤ識別パケットまたはイベントＰＭＴテーブル内容がネットワーク要求により変更される可能性がある。上述の方法によればこのような再多重化は、デスクリプタのサブセレクションだけが認証されるか、そうでなければ変更されたデスクリプタを再多重化装置によって再認証することで可能となる。
【０１４８】
これまでの説明はＰＭＴテーブルとＡＩＴテーブルの認証をターゲットとして述べてきたものであるが、上述の方法はたとえばＰＡＴ，ＣＡＴ，ＮＩＴ，ＥＩＴ，ＳＩＴまたはＤＩＴテーブルなどのようなＭＰＥＧ／ＤＶＢに準拠して定義された他のいかなるタイプのテーブルにも適用可能である。
【図面の簡単な説明】
【０１４９】
【図１】第１の鍵選択形態を実装した本発明によるメッセージの送信側および受信側を示す基本構成図である。
【図２】認証に利用可能な図１の送信側の第１の実施形態について詳細に示す図である。
【図３】図２の送信側により発送される認証フィールドを含むＡＴＶＥＦサービス通知メッセージの内容を示す図である。
【図４】図３の認証フィールドの内容を詳細に示す図である。
【図５】認証フィールドが埋められた状態で図２の送信側により生成されたメッセージの中間バージョンの内容を示す図である。
【図６】図２に示した送信側を伴う中央サーバによりコントロールされる無線ブロードキャストタイプのブロードキャスタセットを示す図である。
【図７】図２の送信側と組み合わせてＡＴＶＥＦサービスメッセージの認証に利用可能な図１の受信側の第１の実施形態について詳細に示す図であるが、この場合にはシステムサービスメッセージの認証にも復号にも利用できる。
【図８】暗号化と認証の組み合わせに利用可能な図１の送信側における第２の実施形態について詳細に示す図である。
【図９】図８の送信側によって発送される認証フィールドと暗号化フィールドを含むＡＴＶＥＦサービス通知メッセージの内容を示す図である。
【図１０】図１の送信側の変形実施形態として用いられる鍵のブロックを伴う第２の鍵選択形態を実装する署名ライブラリを示す図である。
【図１１】図１の受信側の変形実施形態として使用され図１０のライブラリに対応する鍵ブロックを伴う認証ライブラリを示す図である。
【図１２】図２の送信側により発送される認証フィールドを含むＡＴＶＥＦサービス通知メッセージの変形実施形態の内容を示す図である。
【図１３】図１２による認証フィールドの内容を詳細に示す図である。
Claims (16)
- 可変の現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）によりメッセージ（ＭＳＧ）の識別をコントロールする手段（２１）を有する少なくとも１つの受信装置（２）へネットワークを介して発送するためのメッセージ（ＭＳＧ）を保護するセキュリティデバイス（３）において、
可変の現在の暗号鍵（Ｋｉ，Ｋｉ，ｊ）を用いて前記メッセージ（ＭＳＧ）各々の少なくとも一部分に対する暗号化をコントロールするユニット（１１）と、
前記現在の暗号鍵（Ｋｉ，Ｋｉ，ｊ）を変更するユニット（１２）が設けられており、該ユニット（１２）は、使用可能な複数の暗号鍵（Ｋ１〜Ｋｎ；Ｋ１，１〜Ｋｎ，ｌｎ）から成るまえもって決められたセット（１６，７６）から暗号鍵（Ｋｉ，Ｋｉ，ｊ）を選択し、
前記メッセージ（ＭＳＧ）に鍵識別子（ＫｅｙＩＤ）を登録するユニット（１３）が設けられており、該ユニット（１３）により前記受信装置（２）は、使用可能な複数の暗号鍵（Ｋ１〜Ｋｎ；Ｋ１，１〜Ｋｎ，ｌｎ）から成る前記まえもって決められたセット（１６，７６）に対応する使用可能な複数の識別鍵（Ｋ′１〜Ｋ′ｎ；Ｋ′１，１〜Ｋ′ｎ，ｌｎ）から成るまえもって決められたセット（２６，８６）から現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）を選択できるようになり、
該鍵識別子（ＫｅｙＩＤ）によって前記受信装置（２）は、現在の識別鍵（Ｋ′ｉ，Ｋ′ｉｊ) が現在の暗号鍵（Ｋｉ，Ｋｉ，ｊ）と一致するよう該現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）を変更できるようになり、
前記メッセージ（ＭＳＧ）各々に対する、現在の暗号鍵（Ｋｉ，Ｋｉ，ｊ）を用いた前記メッセージの一部分の暗号化の結果から成る署名（ＳＧＮ）の付加をコントロールする手段（１１Ａ，１１Ａ′）が設けられており、
前記メッセージ（ＭＳＧ）はサービス通知メッセージであることを特徴とする、
セキュリティデバイス。 - 使用可能な複数の識別鍵（Ｋ′１〜Ｋ′ｎ；Ｋ′１，１〜Ｋ′ｎ，ｌｎ）から成る前記まえもって決められたセット（２６，８６）は複数の復号鍵から成るセットである、請求項１記載のセキュリティデバイス。
- 前記メッセージの一部分は全体から署名を差し引いたメッセージから成り、該一部分には鍵識別子（ＫｅｙＩＤ［ＳＧＮ］）が含まれる、請求項１または２記載のセキュリティデバイス
- 前記メッセージ（ＭＳＧ）は少なくともＡＴＶＥＦ通知メッセージとシステム通知メッセージの中から選択される、請求項１から３のいずれか１項記載のセキュリティデバイス。
- 前記メッセージの各々は可変長（Ｌ−ＡＵＴＨ）の認証フィールド（ＡＵＴＨ）をもっており、前記登録ユニット（１３）は該認証フィールド（ＡＵＴＨ）に鍵識別子（ＫｅｙＩＤ）を登録する、請求項１から４のいずれか１項記載のセキュリティデバイス。
- 前記メッセージ（ＭＳＧ）は少なくともＭＨＰ通知メッセージの中から選択される、請求項１から５のいずれか１項記載のセキュリティデバイス。
- 前記鍵識別子（ＫｅｙＩＤ）の各々は、使用可能な複数の暗号鍵（Ｋ１〜Ｋｎ）のうち決定された１つの暗号鍵と、該暗号鍵に対応する使用可能な複数の識別鍵（Ｋ′１〜Ｋ′ｎ）のうち決定された１つの識別鍵とに対応づけられている、請求項１から６のいずれか１項記載のセキュリティデバイス。
- 前記鍵識別子（ＫｅｙＩＤ）の各々は、使用可能な複数の暗号鍵（Ｋ１，１〜Ｋｎ，ｌｎ）から成るセット（１６，７６）の中から決定された暗号鍵（Ｋ′ｉ，ｊ）のブロック（Ｂｉ）と、該暗号鍵（Ｋ′ｉ，ｊ）にそれぞれ対応する使用可能な複数の識別鍵（Ｋ′１，１〜Ｋ′ｎ，ｌｎ）から成るセットの中から決定された識別鍵（Ｋ′ｉ，ｊ)のブロック（Ｂ′ｉ）とに対応づけられている、請求項１から６のいずれか１項記載のセキュリティデバイス。
- 前記登録ユニット（１３）は、８〜１２の間に位置する個数有利には１０に等しい個数の値の中から鍵識別子（ＫｅｙＩＤ）を選択する、請求項１から８のいずれか１項記載のセキュリティデバイス。
- 請求項１から９のいずれか１項記載の少なくとも１つのセキュリティデバイス（３）を有しており、有利にはブロードキャストによりメッセージ（ＭＳＧ）を送信することを特徴とする送信装置（１）。
- ネットワークを介して受信したメッセージ（ＭＳＧ）を識別するデバイス（４）において、
前記メッセージ（ＭＳＧ）の各々には、可変の現在の暗号鍵（Ｋｉ，Ｋｉ，ｊ）により暗号化された部分（ＳＧＮ）が含まれており、
可変の現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）により前記暗号化部分（ＳＧＮ）の識別をコントロールするユニット（２１）と、前記メッセージ（ＭＳＧ）から鍵識別子（ＫｅｙＩＤ）を抽出するユニット（２３）が設けられており、
該ユニット（２３）により、使用可能な複数の暗号鍵（Ｋ１〜Ｋｎ；Ｋ１，１〜Ｋｎ，ｌｎ）から成るまえもって決められたセット（１６，７６）に対応する使用可能な複数の識別鍵（Ｋ′１〜Ｋ′ｎ；Ｋ′１，１〜Ｋ′ｎ，ｌｎ）から成るまえもって決められたセット（２６，８６）から現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）を、該現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）が現在の暗号鍵（Ｋｉ，Ｋｉ，ｊ）と一致するよう選択できるようになり、
前記識別コントロールユニット（２１）は暗号化部分（ＳＧＮ）の認証をコントロールするユニットであり、該暗号化部分は現在の署名であり、前記メッセージ（ＭＳＧ）はサービス通知メッセージであり、
有利には請求項１から９のいずれか１項記載のセキュリティデバイス（３）を用いて安全に保護されたメッセージ（ＭＳＧ）を識別可能であることを特徴とするデバイス。 - 請求項１１記載の少なくとも１つの識別デバイス（４）が設けられており、該受信装置は有利には、請求項１０記載のメッセージの送信装置（１）から発せられたメッセージ（ＭＳＧ）を受信することを特徴とする送信装置（２）。
- 請求項１から９のいずれか１項記載のメッセージ（ＭＳＧ）を保護するセキュリティデバイス（３）または請求項１１記載のメッセージ（ＭＳＧ）を識別するデバイス（４）における複数のユニット（１１〜１３；２１，２３）をインプリメントするためのファンクションを有することを特徴とするコンピュータプログラム製品。
- 少なくとも１つの受信装置（２）へネットワークを介して発送するためのメッセージ（ＭＳＧ）において、
それぞれ少なくとも１つの可変の現在の暗号鍵（Ｋｉ，Ｋｉ，ｊ）により暗号化される少なくとも１つの部分（ＳＧＮ）と、
使用可能な複数の識別鍵（Ｋ′１〜Ｋ′ｎ；Ｋ′１，１〜Ｋ′ｎ，ｌｎ）から成るまえもって決められたセットからそれぞれ現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）を選択可能にする少なくとも１つの鍵識別子（ＫｅｙＩＤ［ＳＧＮ］）を有しており、該現在の識別鍵により前記暗号化された部分（ＳＧＮ）を識別できるようになり、
該暗号化部分（ＳＧＮ）は署名であり、前記メッセージ（ＭＳＧ）はサービス通知メッセージであり、
該メッセージ（ＭＳＧ）は有利には請求項１から９のいずれか１項記載のメッセージを保護するためのセキュリティデバイス（３）により得られ、有利には請求項１１記載のメッセージを識別するデバイス（４）のためのものであることを特徴とするメッセージ。 - 可変の現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）により識別（２１）をコントロールする手段を有する少なくとも１つの受信装置（２）へネットワークを介して発送するためのメッセージ（ＭＳＧ）を保護するセキュリティプロセスにおいて、
使用可能な複数の暗号鍵（Ｋ１〜Ｋｎ；Ｋ１，１〜Ｋｎ，ｌｎ）から成る少なくとも１つのセット（１６，１９，７６）から現在の暗号鍵（Ｋｉ，Ｋｉ，ｊ）を選択して、前記メッセージ（ＭＳＧ）各々の少なくとも一部分を暗号化可能にするステップと、
鍵識別子（ＫｅｙＩＤ）を前記メッセージ（ＭＳＧ）に登録して、使用可能な複数の暗号鍵（Ｋ１〜Ｋｎ；Ｋ１，１〜Ｋｎ，ｌｎ）から成る前記まえもって決められたセット（１６，７６）に対応する使用可能な複数の識別鍵（Ｋ′１〜Ｋ′ｎ；Ｋ′１，１〜Ｋ′ｎ，ｌｎ）から成るまえもって決められたセット（２６，８６）から、現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）を受信装置（２）が選択できるようにするステップが設けられており、該鍵識別子（ＫｅｙＩＤ）により前記受信装置（２）は現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）を、該現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）が現在の暗号鍵（Ｋｉ，Ｋｉ，ｊ）と一致するよう変更できるようになり、
該現在の暗号鍵（Ｋｉ，Ｋｉ，ｊ）を用いて前記メッセージ（ＭＳＧ）の一部分を暗号化するステップが設けられており、
該暗号化ステップは前記一部分の署名（ＳＧＮ）を生成することから成り、前記メッセージ（ＭＳＧ）はサービス通知メッセージであり、
有利には請求項１から９のいずれか１項記載のメッセージ（ＭＳＧ）を保護するセキュリティデバイス（３）によりインプリメントされることを特徴とする、メッセージ（ＭＳＧ）を保護するセキュリティプロセス。 - ネットワークを介して受信したメッセージ（ＭＳＧ）を識別するプロセスにおいて、
前記メッセージ（ＭＳＧ）の各々には、可変の現在の暗号鍵（Ｋｉ，Ｋｉ，ｊ）を用いて暗号化された部分（ＳＧＮ）が含まれており、
前記メッセージ（ＭＳＧ）から鍵識別子（ＫｅｙＩＤ）を抽出するステップが設けられており、該ステップにより、使用可能な複数の識別鍵（Ｋ′１〜Ｋ′ｎ；Ｋ′１，１〜Ｋ′ｎ，ｌｎ）から成るまえもって決められたセット（２６，８６）から現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）が選択され、該現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）は前記暗号鍵（Ｋｉ，Ｋｉ，ｊ）と一致し、
前記現在の識別鍵（Ｋ′ｉ，Ｋ′ｉ，ｊ）により前記暗号化部分（ＳＧＮ）を識別するステップが設けられており、
前記暗号化部分（ＳＧＮ）は署名であり、前記メッセージ（ＭＳＧ）はサービス通知メッセージであり、
有利には請求項１１記載のメッセージ（ＭＳＧ）を識別するデバイス（４）によりインプリメントされることを特徴とする、
メッセージ（ＭＳＧ）を識別するプロセス。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0106769A FR2825209A1 (fr) | 2001-05-23 | 2001-05-23 | Dispositifs et procede de securisation et d'identification de messages |
| PCT/EP2002/005610 WO2002096016A2 (en) | 2001-05-23 | 2002-05-22 | Security devices and processes for protecting and identifying messages |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004527188A true JP2004527188A (ja) | 2004-09-02 |
Family
ID=8863573
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002592550A Pending JP2004527188A (ja) | 2001-05-23 | 2002-05-22 | メッセージの保護および識別のためのセキュリティ装置およびセキュリティ方法 |
Country Status (11)
| Country | Link |
|---|---|
| US (1) | US20040162980A1 (ja) |
| EP (1) | EP1402679B1 (ja) |
| JP (1) | JP2004527188A (ja) |
| KR (1) | KR100875289B1 (ja) |
| CN (1) | CN1315281C (ja) |
| AU (1) | AU2002310832A1 (ja) |
| DE (1) | DE60203509T2 (ja) |
| ES (1) | ES2240751T3 (ja) |
| FR (1) | FR2825209A1 (ja) |
| MX (1) | MXPA03010564A (ja) |
| WO (1) | WO2002096016A2 (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2017017685A (ja) * | 2015-07-02 | 2017-01-19 | ジーエヌ リザウンド エー／エスＧｎ Ｒｅｓｏｕｎｄ Ａ／Ｓ | 聴覚デバイスおよび聴覚デバイス通信の方法 |
| US11101979B2 (en) | 2019-05-30 | 2021-08-24 | Kira Inc. | Method and system for creating word-level differential privacy using feature hashing techniques |
| JP2022538465A (ja) * | 2019-07-03 | 2022-09-02 | グーグル エルエルシー | 匿名デバイス認証 |
Families Citing this family (50)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7627762B2 (en) * | 2001-05-23 | 2009-12-01 | Thomson Licensing | Signing and authentication devices and processes and corresponding products, notably for DVB/MPEG MHP digital streams |
| US20040163091A1 (en) * | 2003-02-19 | 2004-08-19 | Brill Gregory M. | Attributes bridging solution and method of using the same |
| JP4717329B2 (ja) * | 2003-03-14 | 2011-07-06 | キヤノン株式会社 | デジタル署名生成装置 |
| WO2005050898A2 (en) * | 2003-11-17 | 2005-06-02 | General Instrument Corporation | Method and apparatuses for using packet data to manage a data stream in a broadband communications system |
| JP4749680B2 (ja) * | 2004-05-10 | 2011-08-17 | 株式会社ソニー・コンピュータエンタテインメント | データ構造、データ処理装置、データ処理方法、認証装置、認証方法、コンピュータプログラム、及び記録媒体 |
| US8090940B1 (en) * | 2004-06-01 | 2012-01-03 | Cisco Technology, Inc. | Method and system for verifying identification of an electronic message |
| US7437558B2 (en) * | 2004-06-01 | 2008-10-14 | Cisco Technology, Inc. | Method and system for verifying identification of an electronic mail message |
| CA2493442C (en) | 2005-01-20 | 2014-12-16 | Certicom Corp. | Method and system of managing and filtering electronic messages using cryptographic techniques |
| US8050406B2 (en) * | 2005-06-07 | 2011-11-01 | Sony Corporation | Key table and authorization table management |
| US8165302B2 (en) * | 2005-06-07 | 2012-04-24 | Sony Corporation | Key table and authorization table management |
| JP4595691B2 (ja) * | 2005-06-14 | 2010-12-08 | トヨタ自動車株式会社 | 電子キーシステム |
| US7748031B2 (en) | 2005-07-08 | 2010-06-29 | Sandisk Corporation | Mass storage device with automated credentials loading |
| US7434253B2 (en) * | 2005-07-14 | 2008-10-07 | Microsoft Corporation | User mapping information extension for protocols |
| JP4596256B2 (ja) * | 2005-08-02 | 2010-12-08 | ソニー株式会社 | 送受信システムおよび方法、送信装置および方法、受信装置および方法、並びにプログラム |
| DE102005046462B4 (de) | 2005-09-21 | 2008-09-18 | Engel Solutions Ag | Netzwerkkomponente für ein Kommunikationsnetzwerk, Kommunikationsnetzwerk und Verfahren zur Bereitstellung einer Datenverbindung |
| CN1808975B (zh) * | 2006-01-26 | 2010-09-08 | 黄涛 | 一种网络帐号防盗系统及其方法 |
| WO2008013656A2 (en) * | 2006-07-07 | 2008-01-31 | Sandisk Corporation | Content control system and method using certificate chains |
| CN101490688A (zh) * | 2006-07-07 | 2009-07-22 | 桑迪士克股份有限公司 | 使用证书撤回列表的内容控制系统和方法 |
| US20090323968A1 (en) * | 2008-06-27 | 2009-12-31 | Shih-Ta Hsu | Descrambling apparatus and descrambling method in a tv system |
| KR101508794B1 (ko) * | 2008-07-09 | 2015-04-06 | 삼성전자주식회사 | Ｎｄｅｆ 메시지에서 선택적으로 레코드들을 보안하기 위한 방법 |
| US9104618B2 (en) | 2008-12-18 | 2015-08-11 | Sandisk Technologies Inc. | Managing access to an address range in a storage device |
| JP5458657B2 (ja) * | 2009-05-01 | 2014-04-02 | ソニー株式会社 | 情報処理装置、鍵更新方法、及びプログラム |
| EP2368541B1 (en) | 2010-03-26 | 2011-12-21 | The Procter & Gamble Company | Method of depilation and depilatory kit |
| US9083534B2 (en) * | 2011-01-07 | 2015-07-14 | Mastercard International Incorporated | Method and system for propagating a client identity |
| WO2012103720A1 (zh) * | 2011-06-29 | 2012-08-09 | 华为技术有限公司 | 维护llc层加解密参数的方法及装置 |
| EP2559420B1 (en) | 2011-08-17 | 2014-10-15 | The Procter and Gamble Company | Effective depilatory article |
| CN103988210B (zh) | 2011-12-21 | 2018-04-03 | 索尼公司 | 信息处理设备、服务器设备、信息处理方法、以及服务器处理方法 |
| US9197700B2 (en) | 2013-01-18 | 2015-11-24 | Apple Inc. | Keychain syncing |
| KR102457809B1 (ko) * | 2014-09-24 | 2022-10-24 | 삼성전자주식회사 | 데이터 통신 보안을 위한 방법, 장치 및 시스템 |
| US10158955B2 (en) | 2015-07-02 | 2018-12-18 | Gn Hearing A/S | Rights management in a hearing device |
| US9887848B2 (en) | 2015-07-02 | 2018-02-06 | Gn Hearing A/S | Client device with certificate and related method |
| US10158953B2 (en) | 2015-07-02 | 2018-12-18 | Gn Hearing A/S | Hearing device and method of updating a hearing device |
| DK201570433A1 (en) | 2015-07-02 | 2017-01-30 | Gn Hearing As | Hearing device with model control and associated methods |
| DK201570436A1 (en) * | 2015-07-02 | 2017-01-23 | Gn Hearing As | Hearing device and method of updating a hearing device |
| US10318720B2 (en) | 2015-07-02 | 2019-06-11 | Gn Hearing A/S | Hearing device with communication logging and related method |
| US9877123B2 (en) | 2015-07-02 | 2018-01-23 | Gn Hearing A/S | Method of manufacturing a hearing device and hearing device with certificate |
| DK201570434A1 (en) * | 2015-07-02 | 2017-01-30 | Gn Hearing As | Hearing device and method of hearing device communication |
| GB2558429B (en) | 2016-02-25 | 2020-04-29 | Arm Ip Ltd | Methods and resources for generating secure communications |
| US10855465B2 (en) | 2016-11-10 | 2020-12-01 | Ernest Brickell | Audited use of a cryptographic key |
| US11398906B2 (en) | 2016-11-10 | 2022-07-26 | Brickell Cryptology Llc | Confirming receipt of audit records for audited use of a cryptographic key |
| US10498712B2 (en) | 2016-11-10 | 2019-12-03 | Ernest Brickell | Balancing public and personal security needs |
| US11405201B2 (en) | 2016-11-10 | 2022-08-02 | Brickell Cryptology Llc | Secure transfer of protected application storage keys with change of trusted computing base |
| EP3334190B1 (en) * | 2016-12-08 | 2021-08-04 | GN Hearing A/S | Hearing devices, user accessory devices and method for updating a hearing device configuration |
| EP3334185B1 (en) | 2016-12-08 | 2021-06-02 | GN Hearing A/S | Hearing system, devices and method of securing communication for a user application |
| US10652245B2 (en) | 2017-05-04 | 2020-05-12 | Ernest Brickell | External accessibility for network devices |
| US10348706B2 (en) * | 2017-05-04 | 2019-07-09 | Ernest Brickell | Assuring external accessibility for devices on a network |
| EP4369210A3 (en) * | 2017-05-04 | 2024-07-24 | Brickell Cryptology LLC | Assuring external accessibility for devices on a network |
| FR3106245B1 (fr) * | 2020-01-09 | 2023-04-07 | Sigfox | Procédé d’émission et de réception d’un message comportant un identifiant chiffré du dispositif émetteur |
| CN113726830B (zh) * | 2020-05-25 | 2023-09-12 | 网联清算有限公司 | 一种报文标识生成方法及装置 |
| CN114513781B (zh) * | 2022-02-11 | 2024-08-06 | 青岛民航空管实业发展有限公司 | 一种空管智慧台站的身份认证方法及数据加解密方法 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5222137A (en) * | 1991-04-03 | 1993-06-22 | Motorola, Inc. | Dynamic encryption key selection for encrypted radio transmissions |
| FR2680589A1 (fr) * | 1991-08-19 | 1993-02-26 | France Telecom | Procede d'emission et de reception de programmes personnalises. |
| CN1178504C (zh) * | 1997-03-21 | 2004-12-01 | 卡纳尔股份有限公司 | 向mpeg接收/译码器下载数据的方法和mpeg传输系统 |
| US6370249B1 (en) * | 1997-07-25 | 2002-04-09 | Entrust Technologies, Ltd. | Method and apparatus for public key management |
| US6978017B2 (en) * | 1997-10-14 | 2005-12-20 | Entrust Limited | Method and system for providing updated encryption key pairs and digital signature key pairs in a public key system |
| US6557172B1 (en) * | 1999-05-28 | 2003-04-29 | Intel Corporation | Communicating enhancement data in layers |
| US7296091B1 (en) * | 1999-06-18 | 2007-11-13 | The Trustees Of Columbia University In The City Of New York | System and method for receiving over a network a broadcast from a broadcast source |
| EP1075108A1 (en) * | 1999-07-23 | 2001-02-07 | BRITISH TELECOMMUNICATIONS public limited company | Cryptographic data distribution |
| US6363480B1 (en) * | 1999-09-14 | 2002-03-26 | Sun Microsystems, Inc. | Ephemeral decryptability |
| FI20000624A0 (fi) * | 2000-03-17 | 2000-03-17 | Prikatti Ab Oy | Parannettu menetelmä, järjestelmä ja liiketoimintamalli sähköisen vedonlyönnin järjestämiseksi |
-
2001
- 2001-05-23 FR FR0106769A patent/FR2825209A1/fr active Pending
-
2002
- 2002-05-22 KR KR1020037014962A patent/KR100875289B1/ko active IP Right Grant
- 2002-05-22 DE DE60203509T patent/DE60203509T2/de not_active Expired - Lifetime
- 2002-05-22 WO PCT/EP2002/005610 patent/WO2002096016A2/en active IP Right Grant
- 2002-05-22 AU AU2002310832A patent/AU2002310832A1/en not_active Abandoned
- 2002-05-22 CN CNB028102487A patent/CN1315281C/zh not_active Expired - Fee Related
- 2002-05-22 MX MXPA03010564A patent/MXPA03010564A/es active IP Right Grant
- 2002-05-22 ES ES02735376T patent/ES2240751T3/es not_active Expired - Lifetime
- 2002-05-22 EP EP02735376A patent/EP1402679B1/en not_active Expired - Lifetime
- 2002-05-22 JP JP2002592550A patent/JP2004527188A/ja active Pending
- 2002-05-22 US US10/478,447 patent/US20040162980A1/en not_active Abandoned
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2017017685A (ja) * | 2015-07-02 | 2017-01-19 | ジーエヌ リザウンド エー／エスＧｎ Ｒｅｓｏｕｎｄ Ａ／Ｓ | 聴覚デバイスおよび聴覚デバイス通信の方法 |
| US11101979B2 (en) | 2019-05-30 | 2021-08-24 | Kira Inc. | Method and system for creating word-level differential privacy using feature hashing techniques |
| JP2022538465A (ja) * | 2019-07-03 | 2022-09-02 | グーグル エルエルシー | 匿名デバイス認証 |
| JP7300529B2 (ja) | 2019-07-03 | 2023-06-29 | グーグル エルエルシー | 匿名デバイス認証 |
| US12003964B2 (en) | 2019-07-03 | 2024-06-04 | Google Llc | Anonymous device authentication |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1402679A2 (en) | 2004-03-31 |
| DE60203509D1 (de) | 2005-05-04 |
| WO2002096016A3 (en) | 2003-08-28 |
| ES2240751T3 (es) | 2005-10-16 |
| WO2002096016A2 (en) | 2002-11-28 |
| DE60203509T2 (de) | 2006-02-23 |
| KR20040004628A (ko) | 2004-01-13 |
| US20040162980A1 (en) | 2004-08-19 |
| FR2825209A1 (fr) | 2002-11-29 |
| KR100875289B1 (ko) | 2008-12-23 |
| AU2002310832A1 (en) | 2002-12-03 |
| MXPA03010564A (es) | 2004-03-02 |
| CN1526217A (zh) | 2004-09-01 |
| EP1402679B1 (en) | 2005-03-30 |
| CN1315281C (zh) | 2007-05-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004527188A (ja) | メッセージの保護および識別のためのセキュリティ装置およびセキュリティ方法 | |
| KR100841986B1 (ko) | 수신기의 기능에 접근하기 위한 제어 명령의 전송 및 실행을 위한 디바이스 및 방법과, 서비스 공표 메시지 송신기 및 수신기 | |
| CN101061666B (zh) | 在广播/多播服务中管理数字权利的方法 | |
| US7356147B2 (en) | Method, system and program product for attaching a title key to encrypted content for synchronized transmission to a recipient | |
| JP3962083B2 (ja) | デジタル伝送システムで伝送されるデータの認証及び証明の方法及びその装置 | |
| US5625693A (en) | Apparatus and method for authenticating transmitting applications in an interactive TV system | |
| KR100782865B1 (ko) | 데이터 전송 제어 방법 및 데이터 전송 시스템 | |
| US20080065548A1 (en) | Method of Providing Conditional Access | |
| JP4732687B2 (ja) | データプロセシングシステムにおけるセキュリティに関する方法及び装置 | |
| US8792642B2 (en) | Apparatus, system and method for detecting a loss of key stream system synchronization in a communication system | |
| JP4094216B2 (ja) | 暗号同期情報の自動再同期 | |
| WO2001067768A2 (en) | Optional verification of interactive television content | |
| AU2001243544A1 (en) | Optional verification of interactive television content | |
| KR19990014887A (ko) | 데이터 송신 장치, 데이터 송신 방법, 데이터 수신 장치, 데이터 수신 방법, 데이터 전송 장치, 및 데이터 전송 방법 | |
| JPH0756831A (ja) | 個人用プログラムの送受信方法 | |
| KR100950422B1 (ko) | 아이피 티브이 시스템을 위한 소스 인증 방법 | |
| WO2010000786A1 (en) | Process to ensure massive data diffusion security, and devices associated | |
| KR20180007286A (ko) | 조건부 액세스 시스템의 컨트롤 워드 보호 | |
| JP2003143127A (ja) | セキュリティ保持方法及びその実施システム並びにその処理プロセス |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050406 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080111 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080612 |