JP2020520617A - フレームのプロパティを活用する設定可能なサービスパケットエンジン - Google Patents

Abstract

本発明は、所定の暗号プロトコルによって１つ以上のパケット（Ｐ１，Ｐ２）を暗号化するための暗号化ユニット（３２００）に関する。前記所定の暗号プロトコルは、サービスチャネル情報の交換を必要とし、前記サービスチャネル情報は第１のビット長を有する。前記暗号化ユニットは、前記パケット（Ｐ１，Ｐ２）が不使用ビットを有するか否かを識別するように構成されているパケットアナライザ（３２１０）と、前記不使用ビットの数が前記第１のビット長以上の場合に前記パケット（Ｐ１，Ｐ２）にサービスチャネル情報を挿入するように構成されているパケットビルダー（３２２０）と、前記所定の暗号プロトコルによって前記パケット（Ｐ１，Ｐ２）を暗号化するように構成されている暗号化エンジン（３２３０）とを備える。

Description

本発明は、一般に暗号化技術の分野に関する。より詳細には、本発明は、暗号化されたチャネルを通じてサービスチャネル情報を送信する方法および装置に関する。さらに詳細には、本発明は、データフローのレイテンシを変化させることなくサービスチャネル情報を送信することを可能にする。

ネットワークを通じたデータの送信のために暗号を使用することは、ますます重要になっている。ネットワークチャネルを実装するために使用されている現在の技術は、概して傍受からの保護が不可能であるので、データを保護するための１つの方法は、データを送信部において暗号化し、受信部において復号することである。

図１には、暗号化されたチャネル１３００を通じて送信部１１００から受信部１５００に対しデータが送信されるネットワーク１０００を概略的に示す。特に、暗号化されたチャネル１３００を作成するために、暗号化ユニット１２００は、チャネル１３００にデータを転送する前に該データを暗号化する。対応する復号ユニット１４００は、受信部１５００に渡す前に該データを復号する。

一般的に、暗号化ユニット１２００および復号ユニット１４００は、送信部１１００に対し、また受信部１５００に対し透過性であるように構成されることが好ましい。すなわち、送信部１１００および受信部１５００は、暗号化ユニット１２００および復号ユニット１４００の存在を知ることなく動作する。このアプローチは、既存のネットワーク１０００に暗号化ユニット１２００および復号ユニット１４００を組み込むことを可能にするため、好ましい。また、本技術は、送信部１１００および受信部１５００に対する変更なく暗号化ユニット１２００および復号ユニット１４００が更新されることを可能にする。最後に、送信部１１００および受信部１５００を暗号化ユニット１２００および復号ユニット１４００から独立したまま動作させることによって、複雑な相互依存性が生じないので、より容易に２つのシステムを管理することが可能である。

暗号化ユニット１２００および復号ユニット１４００は、一般に、サービスチャネル情報と呼ばれるデータを交換する必要がある。このデータは、例えば、セキュリティ増加させるように定期的に変更される暗号鍵であることが可能である。一般に、このデータは、暗号化動作させるために必要な任意の情報であることが可能である。例えば、１つの物理的な暗号化されたチャネル１３００は、複数の論理的な暗号化されたチャネルを含んでもよく、それら暗号化されたチャネルの数および特性は経時的に変化することが可能である。これらの情報は、暗号化ユニット１２００と復号ユニット１４００との間で共有される必要がある。したがって、暗号化ユニット１２００および復号ユニット１４００がサービスチャネル情報を交換する必要性が存在する。

サービスチャネル情報を交換するための１つの可能なアプローチは、暗号化ユニット１２００が送信部１１００からのデータ・ストリームにサービスチャネル情報を挿入することを、変更されたデータ・ストリームをチャネル１３００に転送する前に、可能にすることである。

これによって、しかしながら、不利が与えられる。特に、これによって、サービスチャネル情報パケットが挿入されたか否かに応じて、送信部と受信部との間のレイテンシが変化する。このことは、図２Ａおよび図２Ｂを参照することによって、より明確に理解されるであろう。

図２Ａには、サービスチャネル情報の挿入なしに送信部１１００から受信部１５００に２つのパケットＰ１，Ｐ２を送信するためのタイムフローを概略的に示す。パケットＰ１，Ｐ２は、送信部１１００から受信部１５００に送信される、データパケット、制御パケット、またはより一般的には任意のパケットであることが可能である。時間Ｔ０ａにおいて、パケットＰ１は送信部１１００を出る。時間Ｔ１ａにおいて、パケットＰ２は送信部１１００を離れる。送信部１１００から受信部１５００までの遅延は、値ＤＴを有する。時間Ｔ２ａ（Ｔ０ａ＋ＤＴに等しい）において、パケットＰ１は受信部１５００に到達する。時間Ｔ３ａ（Ｔ１ａ＋ＤＴに等しい）において、パケットＰ２は受信部１５００に到達する。Ｔ３ａとＴ２ａとの間の時間における差は、Ｔ１ａとＴ０ａとの間と同じであり、これは、続いているパケットＰ１とＰ２との間のレイテンシが、受信部１５００においても送信部１１００において有していたのと同じ値を保持していることを意味する。

図２Ｂには、サービスチャネル情報を含む１つのパケットＰＳＣの挿入を伴って、送信部１１００から受信部１５００に２つのパケットＰ１，Ｐ２を送信するためのタイムフローを概略的に示す。時間Ｔ０ｂにおいて、パケットＰ１は送信部１１００を出る。時間Ｔ１ｂにおいて、パケットＰ２は送信部１１００を出る。パケットＰ１，Ｐ２間のレイテンシは、図２Ａの場合と同じである。

しかしながら、暗号化ユニット１２００がサービスチャネル情報を復号ユニット１４００に送信する必要のため、時間Ｔ２ｂ、暗号化されたパケットＰ１を暗号化されたチャネル１３００へ送信した後、暗号化ユニット１２００は、サービスチャネル情報を含む１つのパケットＰＳＣを挿入する。ＰＳＣパケットを送信した後、次いで、暗号化されたパケットＰ２が、暗号化されたチャネル１３００へ送信される。時間Ｔ３ｂにおいて、サービスチャネル情報を含むパケットＰＳＣが復号ユニット１４００において受信される。復号ユニット１４００において、パケットＰＳＣは、意図された目的のために使用されることが可能であり、受信部１５００に対し転送される復号されたパケット・ストリームから除去される。パケットＰ２は、次いで、時間Ｔ４ｂにおいて受信部にて最終的に受信される。

図２ｂにおいて視認可能であるように、パケットＰ１とＰ２との間のレイテンシは、送信部１１００と受信部１５００との間において変化している（特に、増加している）。送信部１１００および受信部１５００は暗号化ユニット１２００の、また復号ユニット１４００の存在を知ることなく動作しているので、受信部１５００は、パケットＰ１とＰ２との間のレイテンシが送信部１１００におけるそれらのパケット間のレイテンシを正確に表していると仮定する。これは、しかしながら、不正確である。

レイテンシの変化によって、受信されるデータの解釈に誤りが引き起こされ得る。いくつかの場合においては、それによってネットワーク１０００が正常に機能しないことや、全く動作しなくなることがある。例えば、ネットワーク１０００がコンピュータネットワークであり、パケットＰ１，Ｐ２が高精度時間プロトコル（Ｐｒｅｃｉｓｉｏｎ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ、以下ではＰＴＰ）に属する場合、ＰＴＰは機能しなくなるか、受信部１５００を不正確に動作させる。ネットワーク１０００の多くの動作では、その正確な機能はＰＣＰＴを通じて達成されるクロック同期に基づくので、ネットワーク１０００の異なる複数の動作が正常に機能しない場合や、全く動作しなくなる場合がある。

したがって、パケット間のレイテンシを変化させることなく、ネットワーク１０００において暗号化されたチャネル１３００を通じてサービスチャネル情報を送信するための方法および装置を提供する必要性が存在する。

本発明の全般的なアプローチは、送信部から受信部に対し送られるパケットの全てにおいて、そのペイロードが完全に満たされているわけではないと認識することである。特に、いくつかのパケットは、それぞれのプロトコルによって指定されているように、最小の長さ（または固定の長さ）しか有しないので、このことによって、全てのビットが使用されているわけではないという場合が導かれる。それらのパケットを暗号化ユニットにて認識することによって、それらのパケットにサービスチャネル情報を追加し、それによってパケット・ストリームに追加のパケットを挿入することを避けることが可能になる。

本発明の一実施形態は、所定の暗号プロトコルによって１つ以上のパケットを暗号化するための暗号化ユニットに関することが可能である。前記所定の暗号プロトコルは、サービスチャネル情報を交換することを必要とし、前記サービスチャネル情報は第１のビット長を有する。暗号化ユニットは、１つ以上のパケットが不使用ビットを有するか否かを認識するように構成されているパケットアナライザと、前記不使用ビットの数が前記第１のビット長以上である場合、前記パケットにサービスチャネル情報を挿入するように構成されているパケットビルダーと、前記所定の暗号プロトコルによって前記パケットを暗号化するように構成されている暗号化エンジンと、を備える。

これは、既存のパケットを用いて追加でサービスチャネル情報を送信し、それによってデータ・ストリームにおける様々なパケットの間の送信レイテンシに影響を与えないことを可能とするので、特に有利である。

いくつかの実施形態においては、前記パケットアナライザは、前記パケットが不使用ビットを有するか否かを、前記パケット内に所定の値を認識することと、前記パケットの１つ以上のフィールドについて特定の値を認識することと、のうちの１つ以上によって認識するように構成されることが可能である。

これは、サービスチャネル情報を送信するために使用されることが可能であるパケットを、そのパケットの全内容を解析する（それは多すぎるコンピュータ・リソースを必要とする）ことなく、効率的に認識することを可能にするので、特に有利である。

いくつかの実施形態においては、前記パケットは、ＳＣＣパケット、ＥＳＭＣパケット、またはＢＦＤパケットであることが可能である。
これは、それらのパケットが、少なくともそれらのパケットのいくつかの可能な実装においてはサービスチャネル情報の送信との互換性を有する不使用の部分を含むので、特に有利である。さらにまた、それらのパケットは、統計的に有利には送信されるサービスチャネル情報との互換性を有する周波数およびペイロードを有する。

いくつかの実施形態においては、前記サービスチャネル情報は、データ、該データに対するアドレス、またはその両方を含むことが可能である。
これは、ネットワーク内の異なったポイントにおよび／または論理的に暗号化された異なるチャネルに関連してサービスチャネル情報を送信することを可能にするので、特に有利である。

本発明のさらなる一実施形態は、所定の暗号プロトコルによって１つ以上のパケットを復号するための復号ユニットに関することが可能である。前記所定の暗号プロトコルは、サービスチャネル情報を交換することを必要とし、前記サービスチャネル情報は第１のビット長を有する。復号ユニットは、前記パケットを復号するように構成されている復号エンジンと、前記パケットのうちの１つ以上が前記サービスチャネル情報を含むか否かを判定するように構成されているパケットアナライザと、前記パケットから前記サービスチャネル情報を除去するように構成されているパケットリーダーと、を備える。

これは、いずれのパケットがサービスチャネル情報を組み込んでいるか認識し、データを抽出し、場合によっては、そのパケットを以前の状態に戻すことを可能にするので、特に有利である。この方式では、サービスチャネル情報の送信はネットワークの残りの部分に対し透過性である。

いくつかの実施形態においては、前記パケットアナライザは、前記パケットが前記サービスチャネル情報を含むか否かを、前記パケット内に所定の値を認識することと、前記パケットの１つ以上のフィールドについて特定の値を認識することと、のうちの１つ以上によって認識するように構成されることが可能である。

これは、データ・ストリームに追加のパケットを挿入することなく、既に使用されているパケットを利用するだけなので、いずれのパケットがサービスチャネル情報を含むかを効率的に認識することを可能にするので、特に有利である。さらにまた、各到来パケットの全内容を解析する必要がない（その一部のみ解析する）ことによって、いずれのパケットがサービスチャネル情報を運ぶかを認識するために必要なコンピュータ・リソースを減少させることが可能である。

さらに、本発明の一実施形態は、所定の暗号プロトコルによって、１つ以上のパケットを復号するおよび／または復号するための暗号ユニットにさらに関することが可能である。前記所定の暗号プロトコルはサービスチャネル情報の交換を必要とし、前記サービスチャネル情報は第１のビット長を有する。暗号ユニットは、前記パケットのうちの１つ以上がサービスチャネル情報を含むか否かを判定し、前記パケットからサービスチャネル情報を除去するように構成されているパケット受信部と、前記パケットの暗号化、復号、またはその両方を行うように構成されている暗号化／復号エンジンと、前記パケットのうちの１つ以上が不使用ビットを有するか否かを認識し、前記不使用ビットの数が前記第１のビット長以上である場合、前記パケットにサービスチャネル情報を挿入するように構成されているパケット発信部と、を備える。

これは、暗号ユニットが上述した暗号化ユニットおよび復号ユニットの両方の機能を実行することを可能にするので、特に有利である。これは、暗号ユニットがネットワークに沿って数回（例えば、連続して）使用されることが可能であって、各暗号ユニットはそのネットワークにおける任意の他の暗号ユニットとサービスチャネル情報を交換することが可能である。

暗号化されたチャネルを通じて送信部から受信部にデータが送信されるネットワークの概略図。 サービスチャネル情報の挿入なしに送信部から受信部に２つのパケットを送信するためのタイムフローの概略図。 サービスチャネル情報を含む１つのパケットの挿入を伴って送信部から受信部に２つのパケットを送信するためのタイムフローの概略図。 本発明の実施形態による暗号化ユニットと復号ユニットとを備えるネットワークの概略図。 本発明の一実施形態による暗号化ユニットの概略図。 本発明の一実施形態による復号ユニットの概略図。 本発明の一実施形態による暗号ユニットの概略図。 マルチプロトコル・ラベル・スイッチング・プロトコルの空のＳＣＣパケットの構造の概略図。 本発明の一実施形態による変更されたＳＣＣパケットの構造の概略図。 マルチプロトコル・ラベル・スイッチング・プロトコルのＥＳＭＣパケットの構造の概略図。 ＢＦＤパケットの構造の概略図。

図３には、暗号化されたチャネル１３００を通じて送信部１１００から受信部１５００に対しデータが送信されるネットワーク３０００を概略的に示す。特に、ネットワーク３０００では、暗号化および復号は、本発明の実施形態による暗号化ユニット３２００および復号ユニット３４００によって実行される。

図３Ａには、暗号化ユニット３２００を概略的に示す。暗号化ユニット３２００は、所定の暗号プロトコルによって１つ以上のパケットＰ１，Ｐ２を暗号化するように構成されており、その所定の暗号プロトコルは、サービスチャネル情報を交換することを必要とし、サービスチャネル情報は第１のビット長を有する。

特に、暗号化ユニット３２００は、パケット（Ｐ１，Ｐ２）が不使用ビットを有するか否かを認識するように構成されているパケットアナライザ３２１０と、不使用ビットの数が第１のビット長以上である場合にサービスチャネル情報をパケットＰ１，Ｐ２に挿入するように構成されているパケットビルダー３２２０と、所定の暗号プロトコルによってパケットＰ１，Ｐ２を暗号化するように構成されている暗号化エンジン３２３０とを備える。

パケットアナライザ３２１０は、到来パケットを解析し、パケットＰ１，Ｐ２が不使用ビットを有するか否かを認識する。
いくつかの実施形態においては、これは、パケットアナライザ３２１０が、複数のパケットの特性を記憶し、到来パケットＰ１，Ｐ２のいずれが不使用ビットを有するかを認識するように、記憶した特性に関して到来パケットＰ１，Ｐ２を解析することによって、達成可能である。例えば、パケットが複数のフィールドを有することは一般的であるが、それらのフィールドの全てが常に使用されているわけではない。それらフィールドのうちのいくつかが使用されていないとき、それらのフィールドの中身は一般に所定の値に設定される。そのパケット内の、またはそれらのフィールドのうちの１つ以上のフィールド内の所定の値を認識することによって、それぞれのビットが使用されていないことが認識されることが可能である。これに代えて、または加えて、それらのフィールドはヘッダーを有することが可能である。ヘッダーは、フィールドがペイロードを有するか否かを特定し、および／またはペイロードのサイズを特定し、それ自身がフィールドである。１つ以上のヘッダーに対する特定の値を認識することによって、不使用ビットの数を決定することが可能である。ペイロードのために使用されていないビットは、不使用ビットと見なされることが可能である。いくつかの実施形態においては、これはパケットアナライザ３２１０が、ペイロードが少なくとも部分的に空の状態で常に送信される複数のパケットの特性を記憶することによって、記憶した特性に関して到来パケットを解析し、格納した特性に対応するパケットを認識することによっても達成される。

パケットアナライザ３２１０がどのように不使用ビットを識別可能であるかに関する詳細な例について、ＳＣＣ，ＥＳＭＣおよびＢＦＤパケットを参照する例について、本明細書においてさらに提供する。それらのパケットは、発明者によってランダムに選択されるのではなく、有利にはサービスチャネル情報の送信との互換性のある周波数およびペイロードを統計的に有するものとして認識される。

パケットビルダー３２２０は、パケットを受信するように、また、到来パケットが不使用ビットを有するか否かと不使用ビットの数とについての情報を受信するように、パケットアナライザ３２１０に対し接続されている。この接続は、パケットビルダー３２２０からパケットアナライザ３２１０に対してパケットを転送するために使用されるものと同じであることが可能であるか、または、図面に示されていない、別個の接続であることが可能である。不使用ビットの数がサービスチャネル情報の第１のビット長以上である場合、パケットアナライザ３２１０は、不使用ビットをサービスチャネル情報のビットに置換することによって、パケット内にサービスチャネル情報を挿入する。

暗号化エンジン３２３０は、所定の暗号プロトコルによって到来パケットを暗号化可能な任意の種類の暗号化エンジンであることが可能である。所定の暗号プロトコル（ＡＥＳ ＣＴＲ，ＡＥＳ ＧＣＭ ２５６ビット，ＡＥＳ ＧＣＭなど）は、送信部と受信部との間におけるサービスチャネル情報の交換を要する。パケットアナライザ３２１０および／またはパケットビルダー３２２０および／または暗号化エンジン３２３０が特定の暗号プロトコルに応じて構成され得ることは、明らかである。例えば、所与の暗号プロトコルがＸビットの長さを有するサービスチャネル情報を送信する必要がある場合、パケットアナライザ３２１０は、不使用ビットを有するそれらのパケットＰ１，Ｐ２を認識するように構成されるであろう。好ましくは、パケットアナライザ３２１０は、Ｘ以上の不使用ビットの数を有するそれらのパケットＰ２，Ｐ３を認識するように構成されるであろう。いくつかの実施形態においては、サービスチャネル情報を運ぶために使用されるパケットの特性は（例えば、パケットの標準的な定義を参照することによって）知られていることがあり、サービスチャネル情報のサイズは、考慮されているパケットにおける所定の利用可能なスペース以下の所定の値にされることが可能である。

到来パケットの全てが暗号化されている必要がないことも、また明らかであろう。例えば、いくつかの実施形態においては、パケットアナライザ３２１０によって認識され得るパケットのタイプに応じて、そのパケットを迂回させたり、そのパケットを認証したり、パケットを認証し暗号化したりなどすることが可能である。

特定の暗号プロトコルは、サービスチャネル情報の特性（構造、周波数、ビット長など）を定義する。例えば、送信されるサービスチャネル情報の特性のいくつかは、セッション鍵、肯定応答パケット、キープアライブ・パケットなどに関係してもよい。

例示的な一実施形態においては、セッション鍵配布のためのサービスチャネル情報は、信号ＩＤフィールド（好ましくは３２ビット）と、トンネルＩＤフィールド（好ましくは６４ビット）と、鍵バンク・フィールド（好ましくは３２ビット）と、初期化ベクトル・フィールド（好ましくは６４ビット）と、セッション鍵フィールド（好ましくは２５６ビット）と、いくつかの追加の実施形態においては合計４８０ビットとするための不使用の３２ビットとを含むことが可能である。サービスＩＤフィールドは、サービスチャネルを通じて送られる信号またはメッセージタイプの一意なＩＤであることが可能である。トンネルＩＤフィールドは、ＵＮＥＭワイドのトンネルＩＤであることが可能である。その鍵バンク・フィールドは、ＦＰＧＡが使用する必要がある鍵バンクのインデックスであることが可能である。このインデックスは、ＥＳＷによって管理されることが可能である。初期化ベクトル・フィールドは、セッション鍵の暗号化／復号によって使用されることが可能である。これはＡＥＳ ＣＴＲアルゴリズムによって使用されることが可能である。

追加の一実施形態においては、キー・アームドＯＫ（ＫｅｙＡｒｍｅｄＯＫ）メッセージのためのサービスチャネル情報は、信号ＩＤフィールド（好ましくは３２ビット）と、トンネルＩＤフィールド（好ましくは６４ビット）と、鍵バンク・フィールド（好ましくは３２ビット）と、初期化ベクトル・フィールド（好ましくは６４ビット）と、キー・アームドＯＫフィールド（好ましくは１２８ビット）と、いくつかの追加の実施形態においては合計４８０ビットとするための不使用の１６０ビットとを含むことが可能である。

パケットビルダー３２２０のおかげで、十分な数の不使用ビットを有するとパケットアナライザ３２１０によって認識されるパケットＰ１，Ｐ２の中へ、有利には送信部１１００と受信部１５００との間においてパケットのレイテンシを維持するように（合計ビット数は変化しないので）、サービスチャネル情報が挿入されることが可能である。

本実施形態においては、パケットアナライザ３２１０、パケットビルダー３２２０、および暗号化エンジン３２３０が、この順序によりパケット経路上に配置されているが、しかしながら、本発明はこれに限定されない。一般に、唯一の要件は、パケットビルダー３２２０が、パケットアナライザ３２１０によって提供される入力に基づいて動作する必要があるため、パケットアナライザ３２１０に続くことである。しかしながら、暗号化エンジン３２３０の位置は、それら他の２つの要素に対して自由に設定されることが可能である。特に、暗号化エンジン３２３０をパケットビルダー３２２０より後に配置する必要はない場合がある。実際、いくつかの場合においては、サービスチャネル情報は暗号化されていない状態において、暗号化されたパケットＰ１，Ｐ２に対し追加されてもよい。いくつかの他の場合においては、サービスチャネル情報が追加されるパケットＰ１，Ｐ２は、暗号化エンジン３２３０によって全く暗号化されなくてもよい。

図３Ｂには、本発明の一実施形態による復号ユニット３４００を概略的に示す。特に、いくつかの実施形態においては、復号ユニット３４００は、有利には暗号化ユニット３２００と協働することが可能である。

復号ユニット３４００は、所定の暗号プロトコルによって１つ以上のパケットＰ１，Ｐ２を復号するように構成されており、この所定の暗号プロトコルは、サービスチャネル情報を交換することを要し、サービスチャネル情報は第１のビット長を有する。

より詳細には、復号ユニット３４００は、パケットＰ１，Ｐ２を復号するように構成されている復号エンジン３４１０と、パケットＰ１，Ｐ２のうちの１つ以上がサービスチャネル情報を備えるか否かを決定するように構成されているパケットアナライザ３４２０と、パケットＰ１，Ｐ２からサービスチャネル情報を除去するように構成されているパケットリーダー３４３０とを備える。

復号エンジン３４１０は、ＡＥＳ ＣＴＲ，ＡＥＳ ＧＣＭ ２５６ビット、ＡＥＳ ＧＣＭなどの任意の所定の暗号プロトコルによって動作することが可能である。より一般的には、復号エンジン３４１０は、暗号化エンジン３２３０と同じ暗号プロトコルを用いて動作することが可能である。

パケットアナライザ３４２０は、パケットＰ１，Ｐ２内のサービスチャネル情報の存在を判定するように構成されることが可能である。
いくつかの実施形態においては、これは、パケットアナライザ３４２０が、複数のパケットの特性を記憶し、到来パケットＰ１，Ｐ２のいずれがサービスチャネル情報を含むかを認識するように到来パケットＰ１，Ｐ２を記憶されている特性に対して解析することによって達成される。例えば、所定の種類のパケットに対しサービスチャネル情報を常に追加することが可能であってもよい。そのような所定の種類のパケットを認識することによって、パケットアナライザ３４２０は、復号エンジン３４１０に所定の種類のパケットの到着を通知することが可能である。これに代えて、または加えて、到来パケットＰ１，Ｐ２のフィールドは、そのフィールドがサービスチャネル情報を記憶するために使用されているか否かを特定するヘッダーを有することが可能である。このヘッダーを、またはより一般的に言うとフィールドを解析することによって、到来パケットＰ１，Ｐ２にサービスチャネル情報が記憶されているか否かを判定することが可能である。

パケットリーダー３４３０は、パケットアナライザ３４２０によって、到来パケットＰ１，Ｐ２内のサービスチャネル情報の存在を通知されることが可能である。到来パケットがサービスチャネル情報を含む場合、パケットリーダー３４３０は、到来パケットＰ１，Ｐ２からサービスチャネル情報を読み取る。いくつかの実施形態においては、パケットリーダー３４３０は、続いて到来パケットＰ１，Ｐ２からサービスチャネル情報を消去するか、到来パケットＰ１，Ｐ２を所定の値に置き換えることが可能である。パケットのヘッダーおよび／またはそのパケットの何らかのフィールドがパケットビルダー３２２０によって到来パケットＰ１，Ｐ２におけるサービスチャネル情報の存在を示すように変更されている場合において、パケットリーダー３４３０は、そのヘッダーまたはフィールドの値を元の所定の値に変更してもよい。

暗号化ユニット３２００に関しては、復号エンジン３４１０とパケットアナライザ３４２０とパケットリーダー３４３０との相対的な配置は、図３Ｂに示されているものである必要はない。代替的な実施形態においては、それら３つの要素は、サービスチャネル情報を含むそれらのパケットＰ１，Ｐ２を識別する情報を受け取るようにパケットリーダー３４３０がパケットアナライザ３４２０に接続されている限り、異なって接続されてもよい。さらに、いくつかの実施形態においては、暗号化ユニット３２００について上述したように、暗号化エンジン３４１０は、パケットアナライザ３４２０より後および／またはパケットリーダー３４３０より後に位置してもよい。これは、暗号化されている到来パケットＰ１，Ｐ２に対し、暗号化されていない状態においてサービスチャネル情報を追加すること、または、サービスチャネル情報を運ぶ到来パケットＰ１，Ｐ２が全く暗号化されていないことも可能であり得るからである。

一般的に、ＳＣＣパケットは、サービスチャネル情報を転送するためのパケットＰ１，Ｐ２として使用されることが可能である。ＳＣＣパケットは異なる形式により構成されることが可能であり、以下では、特定のＳＣＣパケットがサービスチャネル情報を含むようにどのように変更可能であるかについての１つの特定例が提供される。しかしながら、ＳＣＣパケットが不使用ビットの形式における利用可能なペイロードを有する限り、他の変更が可能であることが、当業者には明らかであろう。

図４には、マルチプロトコル・ラベル・スイッチング・プロトコル（非限定的な特定の一実施形態では、サービスチャネル情報を送信するために使用されるパケットのタイプであることが可能である）のＳＣＣパケット４０００の構造を概略的に示す。

ＳＣＣパケットの構造の詳細な定義は、ＩＴＵ−Ｔ Ｇ．８１ １３．２／Ｙ．１３７２．２およびＩＴＵ−Ｔ Ｇ．７７１２／Ｙ．１７０３など、それぞれのパケットのＩＴＵ−Ｔ文書に見出されることが可能である。それらの内容を引用によってここに援用する。一般的に、ＳＣＣは、ノード間において信号通信を交換するための専用の基本パケットであるＭＰＬＳにおける、信号通信チャネル（Ｓｉｇｎａｌｉｎｇ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｈａｎｎｅｌ）を表している。図４に示されているＳＣＣパケット４０００は、ＳＣＣパケット１つの可能な実装である。他の実装も可能である。一般的には、ＳＣＣ構造は同じであるまま、送信される信号メッセージのタイプに応じて、「チャネルタイプ」およびＰＩＤなど、いくつかの値が変化してもよい。

いくつかの場合において、ＳＣＣパケット４０００は、ネットワーク３０００において、部分的にまたは完全に空の状態にて送信されることが可能である。これは、例えば、ＳＣＣパケット４０００の７−２２行目に存在する、使用されない場合があるペイロード（全６４バイトからなる）に該当し得る。この特定の実施形態においては、パケットアナライザ３２１０は、到来パケットを解析し、部分的にまたは完全に空のＳＣＣパケットを認識する。例示的な一識別方法として、識別はＳＣＣパケットのフィールドおよび／またはヘッダーに対するいくつかの所定の値を認識することによって可能である。例えば、以下の組み合わせは、７−２２行目のペイロードの６４バイト全体が使用されることがない、特定のＳＣＣパケット４０００を示す。
−イーサタイプ「８８４７」 ４行目の０−１５ビット
−アウターラベル「．．１３」 ５行目の０−４ビット
−チャネルタイプ「０ｘ０００２」 ６行目の０−１５ビット
−ＰＩＤ「１５」 ６行目の１６−３１ビット
それらのフィールドを解析するとともに、その所定の値を認識することによって、パケットアナライザ３２１０は、現在解析されているＳＣＣパケット４０００が６４バイトまでのペイロードを運ぶ可能性を有すると認識することが可能である。この情報はパケットビルダー３２２０と共有され、パケットビルダー３２２０は、サービスチャネル情報が送信される場合、この時点において、ＳＣＣパケット４０００内に６４バイトまでのサービスチャネル情報を挿入可能であることを通知される。

図５には、本発明の一実施形態による、サービスチャネル情報を挿入するためにパケットビルダー３２２０によって担われた変更後における、１つの可能な変更されたＳＣＣパケット５０００の構造を概略的に示す。

この詳細の例においては、６０バイトまでのサービスチャネル情報が８−２２行目に挿入されている。残りの４バイトは、サービスチャネル情報に関係しない情報を運ぶために、５行目において使用されている。特に、この４バイトは、以下に説明するように、１つのアドレスを各々与えられている複数の異なる受信部（したがって、変更されたＳＣＣパケット５０００が自身に向けられているか否かを所与の受信部が認識可能である）に対し、変更されたＳＣＣパケット５０００が送られる場合に使用され得るアドレスを、変更されたパケット５０００が運ぶことを可能とする。しかしながら、単一の受信部の場合においては、アドレスが必要でなく、したがって実装されなくてもよい場合があることも明らかであろう。また、この特定の例において示した４バイトの変更がアドレスを実装する１つの可能な方法に過ぎないこともまた明らかであり、当業者は異なるアドレス実装が可能であることを認識するであろう。

特に、ＳＣＣパケット４０００と変更されたＳＣＣパケット５０００とを比較する場合、以下のフィールドは変更されていない：
−宛先ＭＡＣ：これは受信部ＭＡＣアドレスを定義する宛先ＭＡＣアドレスであり、ＳＣＣパケット５０００の正しいルーティングを可能にするように、それ自体は変化しないままである。
−送信元ＭＡＣ：これはエミッタＭＡＣアドレスを定義するエミッタＭＡＣアドレスであり、ＳＣＣパケット５０００の正しいルーティングを可能にするように、それ自体は変化しないままである。
−イーサタイプ：これはイーサネット（登録商標）のプロトコル・パケットのタイプを記述しており、一例として、８８４７はＭＰＬＳを表している。
−「０ｘ０００２」はチャネルタイプであり、ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ５７１８において定義されている通り、ＳＣＣパケットに対する「２」に常に設定されている。
−「１５」はＰＩＤフィールド、すなわち、パケット識別子タイプである。これは、ＳＣＣメッセージと関連する通信プロトコルのタイプを識別する。

以下のフィールドは、ＳＣＣパケットの５行目および６行目を６行目および７行目に移動させることによって、５行目に追加される。これは１つの可能な実装に過ぎず、以下のフィールドは、ＳＣＣパケット４０００の任意の部分に追加されることが可能である。追加されるフィールドは次の通りである。
−アウターＬＳＰ。ここでは、４行目の１６−３１ビットの元のアウターＬＳＰは、５行目の１６−３１ビットに移動されており、上述のようにサービスチャネル情報のための宛先アドレスの部分として使用される。
−インナーＬＳＰ。これは、上述のようにサービスチャネル情報のための宛先アドレス送信部分として使用される。
−ＴＣ、すなわち、トラフィック・クラス（Ｔｒａｆｆｉｃ Ｃｌａｓｓ）：これは、優先パケットレベルを定義する。使用の一例としては、装置がパケットの優先順位を決定する必要がある場合、優先順位決定プロセスは、ＴＣ識別に基づく。
−「０」：これは、Ｓ−ビットであり、次のフィールドがラベルから構成されるか否かに関する情報を提供する。提供されている例において、Ｓ−ビット値が「０」であることは、次のフィールドがインナーラベルから構成されていることを意味する。
−ＴＴＬ：「生存時間（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）」は、パケットが、その寿命が終わりドロップされるより前にまだ有する時間を表す。ＩＰパケットが送信される場合、そのＴＴＬは通常では２５５であり、次いで各ホップにおいて１ずつデクリメントされる。

それらのフィールドは、上述のようなサービスチャネル情報のための宛先アドレスとして使用可能であるＭＰＬＳタグを、一緒に形成する。この場合において、サービスチャネル情報は、８行目から２２行目におけるデータと、４行目の１６−３１ビットおよび５行目の０−１５ビットにおける、そのデータのアドレスとを含む。述べた通り、当業者には、代替的なアドレスのコード化が使用されてもよいことは明らかであろう。また、いくつかの場合においては、サービスチャネル情報のための単一の受信部が存在するときには、アドレス決定が不要であることは明らかであろう。

これに代えてまたは加えて：
−８行目から２２行目では、サービスチャネル情報がパケットビルダー３２２０によって６０バイトまで必要に応じて追加されることが可能である。アドレス決定が用いられない場合、４行目および５行目のフィールドは変更されず、サービスチャネル情報がパケットビルダー３２２０によって６４バイトまで必要に応じて追加されることが可能である。

理解されるように、ＳＣＣ変更パケット５０００の全体の大きさは、ＳＣＣパケット４０００のそれと同じである。これは、有利には、パケットのレイテンシを変化させることなくサービスチャネル情報を送信することを可能にする。これに代えてまたは加えて、いくつかの実施形態においては、ＳＣＣ変更パケット５０００のサイズをＳＣＣパケット４０００のサイズに比べて増加させることも可能であってよい。特に、フレーム間のギャップが１６バイトよりも大きい場合、そのことが暗号化ユニット３２００によって認識されるとともに、認識されたフレーム間のギャップの値と最小値である１６バイトとの間の差以下の数のビットがＳＣＣ変更パケット５０００のサイズを増加させるために使用されてもよい。

変更されたＳＣＣパケット５０００は、復号ユニット３４００において受信されると、様々な方式により認識されることが可能である。いくつかの実施形態の場合には、復号ユニット３４００はパケットアナライザ３４２０において全てのＳＣＣパケットを認識するとともに、所定の規約によって変更されているフィールド（上記の例示的な場合には、８−２２行目ならびに４行目の１６−３１ビットおよび５行目の０−１５ビット）を解析する。いくつかの他の実施形態の場合には、パケットアナライザ３４２０は初めに４行目の１６−３１ビットおよび５行目の０−１５ビットにおけるアドレスを解析し、読み取られるアドレスと自身のアドレスとが対応すると判定したとき、８−２２行目のデータのみを読み取る。上述した例を参照すると、パケットのアドレス（４行目の１６−３１ビットにおけるアウターＬＳＰであることが可能である）が復号ユニット３４００のアドレスに対応するとき、復号ユニットは、到来パケットが評価される必要があり、そのパケットに記憶されているサービスチャネル情報が復号ユニット３４００にて使用されると結論づけることが可能である。さらに、それら両方の場合において、異なる種類のＳＣＣパケットを受信する可能性があるので、それらのパケットすべての内容を解析する必要を避けるために、パケットアナライザ３４２０は、ＳＣＣパケットのタイプが暗号化ユニット３２００によって使用されてよいＳＣＣパケットのタイプに対応するか否かを判定するために、初めにＳＣＣパケットのタイプを解析することも可能である。上の例において、暗号化ユニット３２００は、送信されるサービスチャネル情報が存在する場合には、以下の組み合わせによるＳＣＣパケットを使用することが可能である：
−イーサタイプ「８８４７」 ４行目の０−１５ビット
−アウターラベル「．．１３」 ５行目の０−４ビット
−チャネルタイプ「０ｘ０００２」 ６行目の０−１５ビット
−ＰＩＤ「１５」 ６行目の１６−３１ビット。

初めにそれらの値を確認することによって、パケットアナライザ３４２０は、次いで、それらのＳＣＣパケットの内容がそれらの基準に適合することだけを確認することが可能である。

この特定の種類のＳＣＣパケットが使用され得るＳＣＣパケットの１つの可能なＳＣＣパケットに過ぎず、代替的なＳＣＣパケットも本発明を実装するために使用されてもよいことは、明らかであろう。それらの代替的な場合において、パケットが使用可能であるか否かを判定するためにパケットアナライザ３２１０によって確認される所定のフィールドは、到来パケットの内容が評価される必要があるか否かを判定するためにパケットアナライザ３４２０によって確認される所定のフィールドと同じであろう。

さらなる代替的な実施形態においては、有利には、復号ユニット３４２０が変更されたＳＣＣパケット５０００を変更されていないＳＣＣパケット４０００から迅速に認識することを可能にするために、暗号化ユニット３２００によって、ＰＩＤおよび／またはイーサタイプの（より一般的には任意のフィールドの）値が所定の値に（ＳＣＣ規格によって想定されていない２つ以上のフィールドが変更される場合には所定の値の組み合わせに）設定されることが可能である。この方式では、復号ユニット３４００は、変更されたＳＣＣパケットを迅速にかつ効率的に認識することが可能である。それらの実施形態において、復号ユニット３４００によってサービスチャネル情報が自身に向けられたものであることが検出された場合、復号ユニット３４００が値（または値の組み合わせ）を規格によって想定されている値にリストアするように進行することも可能である。一例として、ＰＩＤ値は、暗号化ユニット３２００によって１５から１４に変更され、復号ユニット３４００によって１５に戻されてもよい。

図６には、非限定的な特定の一実施形態における、サービスチャネル情報を送信するために使用されるパケットのタイプであることが可能であるＥＳＭＣ（イーサネット（登録商標）同期メッセージング・チャネル（ＥＴＨＥＲＮＥＴ（登録商標） Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｍｅｓｓａｇｉｎｇ Ｃｈａｎｎｅｌ））パケット６０００の構造を概略的に示す。本発明の他の実施形態において用いられ得るＥＳＭＣのパケットのより詳細な仕様は、それぞれのＵＩＴ−Ｔ Ｒｅｃ． Ｇ．８２６４規格内において見出されることが可能である。

ＥＳＭＣパケット６０００の実装は、既述のＳＣＣパケット４０００による例示的な実装と同様であることが可能である。特に、この場合には、ＥＳＭＣパケット６０００のいくつかのフィールドは、データを（また最終的にはアドレス情報を）それ自身が含むサービスチャネル情報を含むように変更可能であることも、明らかであろう。また、いくつかのフィールドは、ＥＳＭＣパケット６０００が変更されていることを信号により伝えるように、規格では予見されていない値または値の組み合わせを有するように変更されてよいことも、明らかであろう。さらに、様々なタイプのＥＳＭＣパケット６０００が本発明の実装のために使用可能であることも明らかであろう。

図６に示した例示的な実施形態においては、適切なＥＳＭＣパケットを認識するように所定の値を認識するためにパケットアナライザによって評価されるフィールドは以下であることが可能である：
−スロープロトコル（ｓｌｏｗ ｐｒｏｔｏｃｏｌ）・イーサタイプ。所定値である０ｘ８８−０９に等しい
−スロープロトコル・サブタイプ。所定値である０ｘ０ａに等しい
−ＩＴＵ−ＯＵＩ。所定値である００−１９−ａ７に等しい。

ＳＣＣに関して以前に述べたように、この場合においてもまた、この特定の組み合わせは１つの可能な実装に過ぎず、本発明はこれに限定されない。
そのような特定の組み合わせの１つの利点は、この組み合わせによって識別されるＥＳＭＣパケット６０００が現在使用されていない「将来の強化ＴＶ（ｆｕｔｕｒｅ ｅｎｈａｎｃｅｍｅｎｔ ＴＶ）」のための利用可能なスペースを第３２バイト−第１４８６バイトに備えることにある。このスペースは、サービスチャネル情報を送信するために使用されることが可能である。どれくらいのスペースが利用可能であるかを既に知っていることによって、本発明は、有利には、サービスチャネル情報のサイズを利用可能な全スペースまでにすることが可能である。

図７には、特定の非限定的な一実施形態における、サービスチャネル情報を送信するために使用されるパケットのタイプであることが可能である、ＢＦＤパケット７０００の構造を概略的に示す。本発明の他の実施形態で使用され得るＢＦＤパケットのより詳細な仕様は、ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ５８８０において利用可能な、それぞれのＲＦＣ５８８０規格において見出されることが可能である。

この場合においてもまた、実装は、既述のＳＣＣパケット４０００および／またはＥＳＭＣパケット６０００の例示的な実装と同様であることが可能である。特に、この場合においても、ＢＦＤパケット７０００のいくつかのフィールドは、データを（また最終的にはアドレス情報を）それ自身が含むサービスチャネル情報を含むように変更可能であることも明らかであろう。また、いくつかのフィールドは、ＢＦＤパケット７０００が変更されているということを信号によって伝えるように、規格では予見されていない値または値の組み合わせを有するように変更されてよいことも明らかであろう。さらに、様々なタイプのＢＦＤパケット７０００が本発明の実装のために使用可能であることも明らかであろう。

図７に示した例示的な実施形態においては、適切なＥＳＭＣパケットを認識するように所定の値を認識するためにパケットアナライザによって評価されるフィールドは以下であることが可能である：
−イーサタイプ。０ｘ８８４７に等しい
−チャネルタイプ。０ｘ０００７に等しい
−ＰＩＤ。０ｘ２１に等しい。

図３Ｃには、本発明の一実施形態による暗号ユニット３５００を概略的に示す。
特に、暗号ユニット３５００は、所定の暗号プロトコルによって１つ以上のパケットＰ１，Ｐ２を復号するおよび／または復号するように構成されており、該所定の暗号プロトコルはサービスチャネル情報の交換を必要とし、サービスチャネル情報は第１のビット長を有する。

暗号ユニット３５００はパケット受信部３５１０を備える。パケット受信部３５１０は、パケットＰ１，Ｐ２のうちの１つ以上がサービスチャネル情報を含むか否かを判定するとともに、パケットＰ１，Ｐ２からサービスチャネル情報を除去するように構成されている。すなわち、パケット受信部３５１０は、先述したパケットアナライザ３４２０とパケットリーダー３４３０との組み合わせとして動作する。

暗号ユニット３５００は、さらに、先述した暗号化エンジン３２３０および復号エンジン３４１０と同様の方式により、パケットＰ１，Ｐ２を暗号化および／または復号するように構成されている、暗号化／復号エンジン３５２０を備える。

暗号ユニット３５００は、パケット発信部３５３０をさらに備える。パケット発信部３５３０は、パケットＰ１，Ｐ２のうちの１つ以上が不使用ビットを有するか否かを認識するとともに、不使用ビットの数が第１のビット長以上である場合にパケットＰ１，Ｐ２にサービスチャネル情報を挿入するように構成されている。すなわち、パケット発信部３５３０は、先述したパケットアナライザ３２１０とパケットビルダー３２２０との組み合わせとして動作する。

いくつかの有利な実施形態においては、パケット発信部３５３０に関するパケットアナライザ３２１０の機能は、パケット受信部３５１０のパケットアナライザ３４２０によって実行されることが可能である。特に、パケット受信部３５１０のパケットアナライザ３４２０は、パケットＰ１，Ｐ２がサービスチャネル情報を含むか否かを判定することが可能であるので、それによってパケット発信部３５３０に通知を行うことが可能である（この情報がパケットリーダー３４３０によって抽出され、それによって、続いてパケット発信部３５３０に対し転送されるパケットＰ１，Ｐ２にスペースが残るので）。

暗号ユニット３５００は、したがって、有利には、パケットＰ１，Ｐ２のレイテンシを変化させることなく、サービスチャネル情報を受信および／または送信することを可能にする。これは、特に、パケットの送信および受信の両方が行われるネットワークポイントにおいて使用される場合に有利である。

さらに別の実施形態においては、暗号化されたチャネル１３００は、複数の論理的に暗号化されたチャネルを含む単一の物理的なチャネルであることが可能である。論理的に暗号化されたチャネルの各々は、所与の暗号化ユニット３２００と所与の復号ユニット３４００との間において、または、任意の２つの暗号ユニット３５００の間において確立されることが可能である。この場合において、サービスチャネル情報は、論理的に暗号化されたチャネルおよび／またはサービスチャネル情報の宛先である復号ユニット３４００（または暗号ユニット３５００）を識別するための情報を含む。この情報は部分的なものであることが可能であり、例えば、上述したサービスチャネル情報のアドレス構成要素の一部であることが可能である。

一例として、複数の暗号ユニット３５００が連続して接続され（暗号ユニットＡ，Ｂ，Ｃなど）、暗号ユニットの各対の間に、複数の論理的に暗号化されたチャネル（ＡＢ間のチャネルＣ１，Ｃ２、ＢＣ間のチャネルＣ３，Ｃ４など）を含む１つの物理的なチャネル１３００を形成することが可能である。この例示的な構成において、サービスチャネル情報は、暗号ユニット３５００Ａ，Ｂ，Ｃ間において、任意の論理的に暗号化されたチャネルＣ１−Ｃ４に関連して交換されてよい。任意の所与の暗号ユニット３５００において、暗号ユニット３５００は、到来パケットが変更されているパケットであるか否かを認識するとともに、変更されているパケットが自身に向けられているか否かを評価するべく、到来パケットを検査することが可能である。変更されているパケットが自身に向けられている場合、暗号ユニット３５００は、サービスチャネル情報の内容を抽出し、サービスチャネル情報の挿入時に実行された変更を除去することによって、そのパケットを元の構成に戻し、受信したサービスチャネル情報をその情報が関連する特定の論理的に暗号化されたチャネルに適用するように進行することが可能である。これに代えてまたは加えて、サービスチャネル情報が複数の暗号ユニット３５００に対して向けられている場合、または他の暗号ユニット３５００に対して向けられている場合、暗号ユニット３５００は、パケットを変更することなく、そのパケットを転送することが可能である。

本発明について、本発明の様々な可能な実装をより明らかにする目的のため、個別の実施形態に関して述べている。しかしながら、本発明が特許請求の範囲によって定義されること、また、任意の詳細に示した実施形態に限定されないことは明らかであろう。さらにまた、異なる複数の実施形態の異なる特徴を組み合わせることによって、当業者には明らかであろうように、本発明のさらなる追加の実施形態が得られる。

１０００：ネットワーク
１１００：送信部
１２００：暗号化ユニット
１３００：暗号化されたチャネル
１４００：復号ユニット
１５００：受信部
３０００：ネットワーク
３２００：暗号化ユニット
３２１０：パケットアナライザ
３２２０：パケットビルダー
３２３０：暗号化エンジン
３４００：復号ユニット
３４１０：復号エンジン
３４２０：パケットアナライザ
３４３０：パケットリーダー
３５００：暗号ユニット
３５１０：パケット受信部
３５２０：暗号化／復号エンジン
３５３０：パケット発信部
４０００：ＳＣＣパケット
５０００：ＳＣＣ変更パケット
６０００：ＥＳＭＣパケット
７０００：ＢＦＤパケット

Claims (7)

1. 所定の暗号プロトコルによって１つ以上のパケット（Ｐ１，Ｐ２）を暗号化するための暗号化ユニット（３２００）であって、前記所定の暗号プロトコルは、サービスチャネル情報を交換することを必要とし、前記サービスチャネル情報は第１のビット長を有し、
   １つ以上のパケット（Ｐ１，Ｐ２）が不使用ビットを有するか否かを認識するように構成されているパケットアナライザ（３２１０）と、
   前記不使用ビットの数が前記第１のビット長以上である場合、前記パケット（Ｐ１，Ｐ２）にサービスチャネル情報を挿入するように構成されているパケットビルダー（３２２０）と、
   前記所定の暗号プロトコルによって前記パケット（Ｐ１，Ｐ２）を暗号化するように構成されている暗号化エンジン（３２３０）と、を備える暗号化ユニット。
2. 前記パケットアナライザ（３２１０）は、前記パケット（Ｐ１，Ｐ２）が不使用ビットを有するか否かを、
   −前記パケット内に所定の値を認識することと、
   −前記パケットの１つ以上のフィールドについて特定の値を認識することと、
   のうちの１つ以上によって認識するように構成されている、請求項１に記載の暗号化ユニット。
3. 前記パケット（Ｐ１，Ｐ２）は、ＳＣＣパケット（５０００）、ＥＳＭＣパケット（６０００）、またはＢＦＤパケット（７０００）である、請求項１に記載の暗号化ユニット。
4. 前記サービスチャネル情報は、データ、該データに対するアドレス、またはその両方を含む、請求項１に記載の暗号化ユニット。
5. 所定の暗号プロトコルによって１つ以上のパケット（Ｐ１，Ｐ２）を復号するための復号ユニット（３４００）であって、前記所定の暗号プロトコルは、サービスチャネル情報を交換することを必要とし、前記サービスチャネル情報は第１のビット長を有し、
   前記パケット（Ｐ１，Ｐ２）を復号するように構成されている復号エンジン（３４１０）と、
   前記パケット（Ｐ１，Ｐ２）のうちの１つ以上が前記サービスチャネル情報を含むか否かを判定するように構成されているパケットアナライザ（３４２０）と、
   前記パケット（Ｐ１，Ｐ２）から前記サービスチャネル情報を除去するように構成されているパケットリーダー（３４３０）と、を備える復号ユニット。
6. 前記パケットアナライザ（３４２０）は、前記パケット（Ｐ１，Ｐ２）が前記サービスチャネル情報を含むか否かを、
   −前記パケット内に所定の値を認識することと、
   −前記パケットの１つ以上のフィールドについて特定の値を認識することと、
   のうちの１つ以上によって認識するように構成されている、請求項５に記載の復号ユニット。
7. 所定の暗号プロトコルによって、１つ以上のパケット（Ｐ１，Ｐ２）を復号するおよび／または復号するための暗号ユニット（３５００）であって、前記所定の暗号プロトコルはサービスチャネル情報の交換を必要とし、前記サービスチャネル情報は第１のビット長を有し、
   前記パケット（Ｐ１，Ｐ２）のうちの１つ以上がサービスチャネル情報を含むか否かを判定し、前記パケット（Ｐ１，Ｐ２）からサービスチャネル情報を除去するように構成されているパケット受信部（３５１０）と、
   前記パケット（Ｐ１，Ｐ２）の暗号化、復号、またはその両方を行うように構成されている暗号化／復号エンジン（３５２０）と、
   前記パケット（Ｐ１，Ｐ２）のうちの１つ以上が不使用ビットを有するか否かを認識し、前記不使用ビットの数が前記第１のビット長以上である場合、前記パケット（Ｐ１，Ｐ２）にサービスチャネル情報を挿入するように構成されているパケット発信部（３５３０）と、を備える暗号ユニット。