JP2007274688A

JP2007274688A - 強いアルゴリズム用として弱い対称キーを確認可能に作成すること

Info

Publication number: JP2007274688A
Application number: JP2007086223A
Authority: JP
Inventors: Robert R Gilman; アール．ジルマンロバート
Original assignee: Avaya Technology LLC
Current assignee: Avaya Technology LLC
Priority date: 2006-03-31
Filing date: 2007-03-29
Publication date: 2007-10-18
Also published as: CN101047499A; US20080037775A1; KR20070098754A; EP1841121A1; CA2573436A1

Abstract

【課題】暗号化キーを作成するための方法、システム、およびデバイスを提供すること。
【解決手段】より具体的には、暗号化キーは、実効キー・サイズと、その実効キー・サイズとは異なる見た目のキー・サイズとを有するように作成することができる。一般に、実効キー・サイズは、輸出規制によって制限されず、見た目のキー・サイズは、輸出規制によって制限される可能性がある。
【選択図】図１

Description

本発明は、一般には暗号化に関し、詳細には、弱いキー・スペースを占める見た目は強いキーを作成することに関する。

典型的な保護されたインターネット通信セッションは、ＩＰハードフォン、ソフトフォン、ＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）、ラップトップ、テレフォニー・サーバ、およびＰＤＡ（ＰｅｒｓｏｎａｌＤｉｇｉｔａｌＡｓｓｉｓｔａｎｔ）などの第１および第２の通信デバイスを、（インターネットなどの）信頼できないまたは安全ではないネットワークを介して接続する。これらの通信デバイスは、保護されたセッションを確立しようとし、キーの交換を行わなければならない。理解できることであろうが、２つのエンドポイントを接続するＰＢＸサーバに通常は配置されている乱数発生器を使用してキーが作成され、それらのキーが、保護されたセッション中にそれぞれの通信デバイスによって採用されることになる。それらのキーを第１および第２の通信デバイスのそれぞれが使用して、平文および暗号文を暗号化および復号ならびに認証する。対称的な暗号化においては、セッション・ノードのそれぞれにおいて同じ暗号化アルゴリズムへ同一のキーを入力することによって、暗号化および復号が行われる。

米国などの多くの国々は、国家安全保障上の理由から暗号化テクノロジーおよび暗号化製品に対して厳格な輸出統制を行っている。米国においては、商用の暗号化製品に対する輸出統制は、ＥＡＲ（ＥｘｐｏｒｔＡｄｍｉｎｉｓｔｒａｔｉｏｎＲｅｇｕｌａｔｉｏｎｓ）によって許可されるように米国商務省のＢｕｒｅａｕｏｆＩｎｄｕｓｔｒｙａｎｄＳｅｃｕｒｉｔｙによって管理されており、またＩＴＡＲ（ＩｎｆｏｒｍａｔｉｏｎＴｅｃｈｎｏｌｏｇｙＡｄｍｉｎｉｓｔｒａｔｉｏｎＲｅｇｕｌａｔｉｏｎｓ）によって許可されるように国務省のＤＴＣ（ＯｆｆｉｃｅｏｆＤｅｆｅｎｓｅＴｒａｄｅＣｏｎｔｒｏｌｓ）によって管理されている。これまで、一定のレベルよりも強い暗号化製品に対して輸出承認を付与することに関しては、厳格な統制が行われてきた。その他の国々も、同様の規制を有している。

暗号化に対応した製品を国際的に販売している企業にとって常に存在する難題は、暗号化製品の強度を効果的にコントロールすることである。米国において販売されているそのような製品に関しては、その他の国々、とりわけイラン、キューバ、および北朝鮮など、特定の厳格に輸出を統制している国々において販売されているそのような製品よりも、暗号化の強度がさらにいっそうゆるくコントロールされている。

暗号化の強度をコントロールすることに対する１つのアプローチは、製品の目指す市場に基づいて暗号化アルゴリズムを変更することである。これは、ライセンス・ファイルを使用して行われる。実例として、ライセンス・ファイル・ユーティリティーは、別々の強度の第１または第２の暗号化アルゴリズムをデバイスがサポートするかどうかをコントロールする。より弱い暗号化アルゴリズムの例としては、ＤＥＳ（ＤａｔａＥｎｃｒｙｐｔｉｏｎＳｔａｎｄａｒｄ−５６）が含まれ、より強い暗号化アルゴリズムの例としては、ＴｒｉｐｌｅＤＥＳ（ＴｈｒｅｅＤＥＳ）およびＡＥＳ（ＡｄｖａｎｃｅｄＥｎｃｒｙｐｔｉｏｎＳｔａｎｄａｒｄ）が含まれる。理解できることであろうが、ＤＥＳは、ＴｒｉｐｌｅＤＥＳよりもはるかに弱い。より強い暗号化アルゴリズムをデバイスがサポートしない場合には、ライセンス・ファイル内でフラグがセットされるか、または外される。ライセンスのチェックおよび／またはセッションの交渉中に、ライセンス・ユーティリティーは、より強い暗号化アルゴリズムをデバイスがサポートしないことをフラグが示している場合には、より強い暗号化アルゴリズムを無効にして、より弱い暗号化アルゴリズムを有効にし、より強い暗号化アルゴリズムをデバイスがサポートすることをフラグが示している場合には、より強い暗号化アルゴリズムを有効にし、したがって、より弱い暗号化アルゴリズムを無効にする。

ウェブ・ブラウザおよびサーバのベンダ（たとえば、Ｎｅｔｓｃａｐｅ（商標）、Ｍｉｃｒｏｓｏｆｔ（商標）など）によって実施されている別のアプローチでは、ウェブ・サーバ、ウェブ・ブラウザ、およびウェブ・ブラウザの証明書が、強い暗号スイートおよびキー・サイズを使用できるバージョン、タイプ、および強度のものでない限り、アプリケーションは、キーの長さが長い強いキーおよび関連付けられている暗号スイート（暗号化アルゴリズム）を交渉することはできない。そうでない場合には、キーの長さが短い弱いキーおよび関連付けられている暗号スイートが使用される。

これらのアプローチに伴う問題としては、精通した人が見れば、より弱い暗号化アルゴリズムを有効にしていることが透けて見えてしまうという点が含まれる。この知識に基づいて、精通したユーザは、ライセンス・ファイルを変更して、より強い暗号化アルゴリズムを有効にしようと試みることができる。ユーザが、プロトコルの交換を自由に見ることができ、暗号化が制限されるようなソフトウェアのバージョンかどうかを判断することができる場合には、この透けて見えてしまうという点が、特に問題となる。

別の問題は、弱いキーが作成されて通信デバイスに直接分配される場合に、潜在的な攻撃者が、キー・サイズをより容易に割り出すことができる可能性があるという点である。ある種の暗号化アルゴリズムを破るためには、多大なコンピューティング・リソースが必要とされる可能性があるため、攻撃者たちは通常、暗号化されているすべてのメッセージを復号しようとはしない。むしろ彼らは、より小さなキーを用いて暗号化されていると分かるメッセージを選択する。このために、所与のより小さなキーを用いて送信されるメッセージは、傍受および無許可の復号の影響をより受けやすくなる。その一方で、攻撃者たちは、より大きな１２８ビット・キーを用いて暗号化されていると思われるメッセージを復号しようとはしない可能性がある。というのは、不可能かもしれないと考えられるそのようなタスクにコンピューティング・リソースを投じたくはないためである。現在、特定のメッセージを暗号化するために使用されているキーのサイズを割り出すことは、攻撃者たちにとって比較的容易である。

これらおよびその他のニーズには、本発明のさまざまな実施形態および構成によって対処する。本発明は一般に、とりわけ輸出される製品用として強いキーの形状を有する確認可能な弱いキーを作成するためにキー・サイズの見た目を変えることを対象とする。本発明の少なくともいくつかの実施形態は通常、第三者が他の参加者（すなわちプリンシパル）のためのキーを作成する暗号化プロトコルにおいて適用することができる。これらのプロトコルを採用できるデバイスの例としては、Ｈ．３２３ゲートキーパやケルベロス・サーバが含まれるが、それらには限定されない。場合によっては（たとえば、ＳＲＴＰの場合には）、送信機は、キーを作成して、そのキーを受信機へ送信することができる。もちろん、この最後のステップは一般に、安全な通信チャネルを必要とする。

本発明の一実施形態によれば、暗号化キーを作成する方法が提供される。この方法は、
（ａ）第１の見た目のサイズと第１の実効サイズとを有する第１のキーを作成するステップと、
（ｂ）固定されたキーを決定するステップと、
（ｃ）固定された暗号化アルゴリズムを選択するステップと、
（ｄ）固定されたキーおよび選択されたアルゴリズムを使用して、第１のキーを第２のキー・スペースへと突出させて、第２のキーを作成するステップであって、第２のキーが、第２の見た目のサイズと、実質的に第１の実効サイズとを有し、第２の見た目のサイズが、第１の見た目のサイズとは異なるステップと、
（ｅ）突出した第２のキーを少なくとも１人の受け手に分配するステップとを含む。

別の実施形態においては、ステップｂおよびｄは、キー付きハッシュ関数などの一方向の暗号化関数へと結合され、これらは双方とも、第１のキーを同じプロセスで拡張してスクランブルをかけて、第２のキーを形成する。

実際には、第１のキーを閉ざされたキー・スペース内で作成し、次いでジェネレータにしか分からない固定されたキーを使用して、キー付き暗号化関数を第１のキーに適用することによって、より大きなキー・スペースの何らかのサブスペースへと第１のキーを「突出」させて、第２のキーを形成する。突出させるために使用された固定されたキーが、攻撃者には分からない場合、その攻撃者は、結果として生じるサブスペースを特定することができず、したがって、自分が第２のキーを探す範囲を小さなサブスペースへと絞り込むことができない。しかし、固定されたキーを内々に知っている第三者は、可能性のあるそれぞれの第１のキーを作成して、突出を適用することによって、第２のキーのサブスペースを容易に探すことができる。

第１のキーの実効サイズは通常、そのキーを作成するために使用されているビットの数によって定義される。たとえば、第１のキーが６４ビット・キーになるように作成された場合には、第１のキーの実効サイズは６４ビットとなり、第１のキーの対応する「キー強度」は２^６４となる。通常、第１の見た目のサイズは、第１の実効サイズと一致する。

第２のキーを作成するために、第１のキーを拡張してスクランブルをかけると、結果として、第１のキーと実質的に同じ実効サイズを有するが、見た目のサイズは異なる第２のキーが得られる。すなわち、上記の例を続けると、第２のキーは、やはり実質的に６４ビットの実効サイズを有し、対応する実質的な「キー強度」は２^６４となる。第２のキーのキー強度は、元のキー強度と実質的に等しくなる。しかし、当業者なら理解できることだが、第２のキーのキー強度は、第１のキーのキー強度と実質的に等しくなる。同様に、第２のキーの「実効キー・サイズ」は、第１のキーの「実効キー・サイズ」と実質的に等しくなる。

第１のキーの拡張によって、第２のキーは、より大きな見た目のサイズを有する。第２の見た目のサイズは、６５ビットから、数百ビット、数千ビット、あるいは数百万ビットまで、任意のサイズとすることができる。第１のキーを拡張して、一般的な暗号化アルゴリズムにおいて使用されるより大きなキーに似た第２のキーを作成することは、一般に有利である。たとえば、第２のキーの第２の見た目のサイズは、１２８ビットとすることができる。これは、２^１２８の実効キー強度を有する１２８ビット・キーに見えるかもしれないが、６４ビットの実効キー・サイズおよび２^６４の実効キー強度を有するにすぎない。しかし第２のキーの見た目は、固定されたキーを知らない第三者に、第２のキーがあまりにも大きな解読作業になると思わせることができ、潜在的な攻撃者は、そのキーや、そのキーを用いて暗号化されているあらゆるメッセージを改ざんするのを思いとどまるかもしれない。

拡張されたキーの「スクランブルをかける」作業は、固定されたキーを利用する対称暗号化アルゴリズムを採用することによって達成することができる。あるいは、スクランブルおよび拡張は、共有されているセッション・マスター・キーからセッション・キーを導き出すためにいくつかのプロトコル（たとえば、ＭＩＫＥＹ、ＳＲＴＰ）において使用されているような公開キー暗号化システム、一方向の暗号化キー付きハッシュまたは疑似ランダム関数を使用することによって行うことができる。対称アルゴリズムが使用されている場合には、固定されたキーを知っている許可済みの第三者は、その固定されたキーを用いて突出したキーの突出を容易に無効にして、作成されたキーのサイズを確認することができ、作成されたいかなるキーによって占められているキー・スペースも割り出すことができる。あるいは、非対称アルゴリズムまたは一方向のハッシュベースの関数が採用されている場合には、固定されたキーを知っている許可済みの第三者は、その固定されたキーを使用して、いかなる作成されたキーによって占められているキー・スペースも割り出すことができる。その後、許可済みの第三者は、第２のキーが占めているように見えるより大きなキー・スペースを探す必要はなく、作成されたキーによって占められている実際のキー・スペースを探すことができる。このスクランブル／暗号化プロセスは、元のキーのセキュリティーを守るために使用され、通常は、保護対象のキーよりも強力にすべきである。したがって攻撃者は、この拡張／スクランブル・スキームを知っていて、それによって作成されたキーを入手していても、固定されたキーを知らなければ、その固定されたキーを容易に割り出すことはできないであろう。さらに、固定されたキーを知らないそのような攻撃者は、ジェネレータによって作成された第２の（突出した）キーによって占められている実際のキー・スペースを容易に割り出すことはできない。

米国の輸出法規に準拠するためには、何度もサンプル・キーを作成して、ＮＳＡ（ＮａｔｉｏｎａｌＳｅｃｕｒｉｔｙＡｇｅｎｃｙ）や商務省のような許可済みの第三者へ送信する必要が生じるであろう。そこで、作成されたキーが分析されて、そのキーが、キー作成の規制に準拠して作成されたかどうかが判断される。第２のキーは、第２の見た目のサイズを有しており、この第２の見た目のサイズは、規制が許容するよりも潜在的に大きい可能性があるため、許可済みの第三者は、（安全な送信のために使用されているあらゆる暗号化を取り除いた後で）突出したキーの構成を無効にするか、またはテストする必要が生じる可能性がある。固定されたキーが、許可済みの第三者と共有されているならば、その第三者は、第２のキーが第２の見た目のサイズを有しており、その第２の見た目のサイズは、許容されるキー作成サイズよりも大きいかもしれないが、第２のキーの実効サイズは、許容される限度内であるということを容易に認識することができるかもしれない。したがって、許可済みの第三者（たとえばＮＳＡ）は、第１のキーが輸出規制の許容限度内で作成されたということを迅速に確認することができる。

これらおよびその他の利点は、本明細書に含まれる（１つまたは複数の）本発明の開示から明らかになるであろう。上述の実施形態および構成は、完全なものではなく、また網羅的なものでもない。理解できることであろうが、上述した特徴あるいは以降で詳述する特徴のうちの１つまたは複数を単独でまたは組み合わせて利用する本発明のその他の実施形態も可能である。

本明細書において使用される際、「少なくとも１つ」、「１つまたは複数」、ならびに「および／または」は、制限のない表現であり、接続語および離接語の双方として機能する。たとえば、「Ａ、Ｂ、およびＣのうちの少なくとも１つ」、「Ａ、Ｂ、またはＣのうちの少なくとも１つ」、「Ａ、Ｂ、およびＣのうちの１つまたは複数」、「Ａ、Ｂ、またはＣのうちの１つまたは複数」、ならびに「Ａ、Ｂ、および／またはＣ」という表現のそれぞれは、Ａだけ、Ｂだけ、Ｃだけ、ＡおよびＢ、ＡおよびＣ、ＢおよびＣ、あるいはＡ、Ｂ、およびＣを意味する。

はじめに図１を参照して、本発明の少なくともいくつかの実施形態に従って、例示的な通信システム１００について説明する。通信システム１００は、ネットワーク１０４を含み、このネットワーク１０４は、第１の通信デバイス１０８と、第２の通信デバイス１１２と、スイッチ／サーバ１１６と、許可済みの第三者１２０と、無許可の第三者１２４とを接続する。通信デバイス１０８および１１２は、複数のパケット交換デバイスのうちの任意のものとすることができ、それらのパケット交換デバイスとしては、ＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）、ラップトップ、ＰＤＡ（ＰｅｒｓｏｎａｌＤｉｇｉｔａｌＡｓｓｉｓｔａｎｔ）、ＩＰハードフォン、ＩＰソフトフォン、無線電話、携帯電話、インスタント・メッセージ用ソフトウェア、およびネットワーク機器が含まれるが、これらには限定されない。

ネットワーク１０４は、第１のエンドポイントから第２のエンドポイントへデータを送信するように機能する任意のタイプの適切な通信ネットワークとすることができ、典型的なエンドポイントとしては、通信デバイス１０８および１１２、スイッチ／サーバ１１６、許可済みの第三者１２０、ならびに無許可の第三者１２４が含まれる。適切なタイプのネットワーク１０４の例としては、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）、インターネットのようなＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）、および当技術分野で知られているその他の任意のタイプのパケット交換ネットワークが含まれるが、これらには限定されない。

サーバ１１６は、企業またはサービス・プロバイダのネットワークの一部とすることができる。「サーバ」という用語は、本明細書で使用される際には、ＰＢＸ、ＡＣＤ、エンタープライズ・サーバ、ＩＶＲサーバ、またはその他のタイプの通信システム・サーバ、ならびにメディア・サーバ、コンピュータ、付属物など、その他のタイプのプロセッサベースの通信コントロール・デバイスを含むものと理解されたい。

許可済みの第三者１２０は通常、サーバ１１６によって作成されたキーを分析して、作成されたキーの強度を確認することに関心を持つ第三者である。作成されたキーを分析するために許可済みの第三者１２０によって使用されるデバイスは、サーバ、スーパー・コンピュータ、プロセッサのネットワーク、エンドポイントをエミュレートするデバイス、またはその他のタイプの処理メカニズムの形態とすることができる。許可済みの第三者１２０は通常、作成されたキーの強度を分析することを自分たちに許可する情報を与えられる。通常、許可済みの第三者１２０と共有される情報は、分配に先立って、作成されたキーに対して拡張を施すために、および／またはスクランブルをかけるために使用されたキーを含むことができる。

その一方で、無許可の第三者１２４は通常、攻撃者、ハッカー、または保護された通信セッションに関連する情報を有することを意図されていないその他の任意の信頼できない相手を指す。ほとんどのタイプの無許可の第三者１２４は通常、さまざまな理由で悪用するために、暗号化されたメッセージ、キー、およびその他の機密データを傍受しようと試みる。

次いで図２を参照して、本発明の少なくともいくつかの実施形態に従って、例示的なサーバ１１６について説明する。サーバ１１６は通常、キー・ジェネレータ２０４、キー拡張メンバー２０８、キー・エンクリプター／スクランブラー２１２、およびネットワーク１０４との間でデータを送信／受信するためのインターフェース２１６を含む。通常、暗号化キーは、保護された通信セッションが２つのエンドポイントの間で開始されるときに、通信デバイス１０８および１１２によって必要とされる。暗号化キーを求める要求があると、サーバ１１６は、保護されたセッション中に第１の通信デバイス１０８と第２の通信デバイス１１２との間で使用するためのキーをキー・ジェネレータ２０４が作成できるようにする。キー・ジェネレータ２０４は、乱数発生器か、またはさまざまな強度のキーを作成するために採用できるその他の任意のタイプのメカニズムとすることができる。

理解できることであろうが、「キー強度」すなわち「実効キー・サイズ」とは、複数の可能な組合せまたはキーを指す。キー強度は、一般にキーの長さの関数である。たとえば、無作為の１６ビット・キーに関するキー強度は２^１６であり、３２ビット・キーに関しては２^３２であり、６４ビット・キーに関しては２^６４であり、１２８ビット・キーに関しては２^１２８である。より弱いキー強度を有する第１のキーを使用することによって、第１のキーを使用した暗号化の実効暗号化強度は、より高い実効キー強度を有する第２のキーを使用した場合よりも低くなる。より強いキーは、たとえば輸出制限のない製品において使用することができ、より弱いキーは、輸出制限のある製品において使用することができる。

本発明の少なくとも１つの実施形態によれば、キー・ジェネレータ２０４は、輸出規制に従った実効キー強度を有する第１のキー（Ｋ_Ｇ）を作成する。すなわち、米国の輸出規制に準拠するためには、Ｋ_Ｇは、６４ビットのキーの長さを有するように作成することができる。したがってＫ_Ｇの実効キー・サイズは、６４となるであろう。もちろんキー・ジェネレータ２０４は、適切な規制および／またはその他の所望の機能パラメータに応じて、より大きなキーまたはより小さなキーを作成することができる。たとえば、５６ビット・キーまたは７２ビット・キーを作成して、所望の暗号化アルゴリズムに応じて任意のサイズへ拡張することができる。

そして、第１の実効キー強度を有する作成されたキーが、キー拡張メンバー２０８へ送信される。キー拡張メンバー２０８は、実効キー強度を変更することなく、Ｋ_Ｇの見た目のサイズを変更する。キー拡張メンバー２０８は、Ｋ_Ｇの見た目のサイズを複数の異なる方法で拡張することができる。たとえば、Ｋ_Ｇの拡張である第２のキー（Ｋ_Ｅ）を、６４ビットの０、１、またはその他の何らかの固定された予測可能なバイナリー・パターン（たとえば、１および０の規定された順序付け）とＫ_Ｇとを連結したものとして形成することができる。６４ビットの０とＫ_Ｇとの連結は実質的に、１２８ビットの見た目のキー・サイズを有する一方で元の６４ビットの実効キー・サイズを有する新しいキーを生み出す。当業者なら理解できることだが、０は、Ｋ_Ｇの先頭に付加することもでき、あるいはＫ_Ｇ内の別々のポイントに配置することもできる。しかし、Ｋ_Ｅの実効キー・サイズの確認をより容易にするためには、０をＫ_Ｇの末尾または先頭のいずれかにまとめておく方が有利かもしれない。その上、当業者ならさらに理解できることだが、１をそれだけでまたは他の０と組み合わせて使用して、追加の０の機能を実行することができる。見た目のキー・サイズは、通信デバイス１０８および１１２によって使用されることになる暗号化アルゴリズムのタイプに応じて、いかなるサイズにも拡張することができる。通常は、米国の輸出規制のために、キー・ジェネレータ２０４において６４ビット・キーが作成されてから、１２８ビットの見た目のキー・サイズへと拡張される。これは、ＡＥＳ−１２８のような公知の暗号化アルゴリズムおよびその他の１２８ビットの暗号化アルゴリズムが、幅広く使用されているためである。６４ビット・キー、または１２８ビット・キーでさえ、やはり所望の暗号化アルゴリズムのタイプに応じて、２５６ビットまたはさらに大きな見た目のキー・サイズを有するように拡張することができる。

そして拡張されたキーＫ_Ｅが、キー・エンクリプター２１２へ送信され、キー・エンクリプター２１２では、拡張されたキーＫ_Ｅが、強いキーの見た目を有するように、システム全体に及ぶ固定されたキーを使用して暗号化アルゴリズムによって暗号化されるか、またはその他の形でスクランブルをかけられる。キー・エンクリプター２１２は、固定されたキー（Ｆ）を用いて任意の種類の適切な暗号化アルゴリズムを使用することができる。この固定されたキーは、たとえばＡＥＳ−１２８暗号化アルゴリズムによって使用される強いキーとすることができる。典型的な一応用例においては、暗号化アルゴリズムは、固定されたキーＦを用いて、拡張されたキーＫ_Ｅを暗号化して、突出したキーＫ_Ｓを形成し、それを使用する当事者に分配する。このキーＫ_Ｓは、いかなる第三者にも開示しないように安全に分配されるべきである。

対称キーを使用するか非対称キーを使用するかを問わず、いかなる暗号化アルゴリズムも、またはいかなる暗号化ハッシュ関数も、使用することができる。適切な対称暗号化アルゴリズムの例としては、ＡＥＳ（ＦｅｄｅｒａｌＩｎｆｏｒｍａｔｉｏｎＰｒｏｃｅｓｓｉｎｇＳｔａｎｄａｒｄ１９７）、ｔｒｉｐｌｅＤＥＳ、ＲＣ４、Ｌｕｃｉｆｅｒ、Ｍａｄｒｙｇａ、ＮｅｗＤＥＳ、ＦＥＡＬ、ＲＥＤＯＣ、ＬＯＫＩ、ＫｈｕｆｕａｎｄＫｈａｆｒｅ、ＲＣ２、ＩＤＥＡ、ＭＭＢ、ＣＡ−１．１、Ｓｋｉｐｊａｃｋ、ＧＯＳＴ、ＣＡＳＴ、Ｂｌｏｗｆｉｓｈ、ＳＡＦＥＲ、３−Ｗａｙ、Ｃｒａｂ、ＳＸＡＬ８／ＭＢＡＬ、ＲＣ５、ナップサック・アルゴリズム、Ｐｏｈｌｉｇ−Ｈｅｌｌｍａｎ、Ｒａｂｉｎ、ＭｃＥｌｉｅｃｅ、ＥｌｌｉｐｔｉｃＣｕｒｖｅＣｒｙｐｔｏｓｙｓｔｅｍｓ、ＬＵＣ、フィニット・オートメーション・パブリックキー・クリプトシステムズ、Ｏｎｇ−Ｓｃｈｎｏｒｒ−Ｓｈａｍｉｒ、ＥＳＩＧＮ、セルラー・オートマトンなどが含まれるが、これらには限定されない。適切な非対称暗号化アルゴリズムの例としては、ＲＳＡ（ＲｉｖｅｓｔＳｈａｍｉｒａｎｄＡｄｅｌｍａｎ）、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ、ＥｌＧａｍａｌ、ＤＳＳなどが含まれるが、これらには限定されない。ＨＭＡＣ−ＳＨＡ１などのキー付きメッセージ認証関数、あるいはハッシュ関数（たとえば、ＭＩＫＥＹＰＲＦ）または暗号化アルゴリズム（たとえば、ＳＲＴＰＰＲＦ）に基づくキー付き疑似ランダム関数を、固定されたキーＦと共に使用して、弱い第１のキーの拡張およびスクランブルの双方を行うことができる。最終当事者がＫ_Ｓ自体を類似のＰＲＦのマスター・キーとして使用して、たとえばデータ・プライバシー（暗号化）およびインテグリティー（メッセージの認証）のためのセッション・キーを作成することができるという点に留意されたい。

分配されたキーＫ_Ｓは一般に、比較的強いキー（たとえば、１２８ビット・キー）を表す見た目のキー・サイズを有するが、実際には、より小さな作成されたキーＫ_Ｇの実効キー・サイズ（たとえば、６４ビット・キー）を有する。突出したキーＫ_Ｓは、強いキーの見た目を有するため、固定された暗号化キーＦがジェネレータによって秘密にされている限り、実効キー・サイズが実際には小さくなるということを推定するのは、第三者の目にとって容易ではない。

第２のキーＫ_Ｓは、キー拡張メンバー２０８およびキー・エンクリプター２１２によって作成されると、安全な方法でエンドポイントへ分配するためにインターフェース２１６へ送信される。理解できることだが、Ｋ_Ｓ用の分配プロトコルは、上述の暗号化アルゴリズムやその他のタイプの適切なアルゴリズムのうちの任意のものを採用して、保護されていないネットワークを介した送信に際してキーを保護することができる。提供されるセキュリティーは、強い暗号化キーを利用する暗号化アルゴリズムと同等のものになるはずである。

一実施形態においては、キー・ジェネレータ２０４、キー拡張メンバー２０８、およびキー・エンクリプター／スクランブラー２１２は、サーバ１１６内のプロセッサまたはコントローラ上のソフトウェアとして、ハードウェア（たとえば、ＡＳＩＣ（ＡｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）などの論理回路）として、またはそれらの組合せとして具体化される。

一実施形態においては、キー・ジェネレータ２０４、キー拡張メンバー２０８、およびキー・エンクリプター／スクランブラー２１２は、所定の固定された秘密キーＦを共有する通信デバイス１０８および／または１１２のうちの１つまたは複数の中で具体化される。通信デバイスは、保護された通信セッション内で使用するための第１のキーを作成し、次いでそのキーを公知のプロトコルに従って安全な方法で別の通信デバイスと共有することができる。そして、その実効サイズよりも大きな見た目のサイズを有する突出したキーＫ_Ｓを使用して、通信デバイス同士の間における保護された通信セッションを実行することができる。

次いで図３を参照して、本発明の少なくともいくつかの実施形態に従って、突出したキーを利用する２つの通信デバイス１０８と１１２の間における例示的な通信セッションについて説明する。突出したキーは通常、キー３０４として通信セッション内で使用するために通信デバイス１０８および１１２の双方へ安全な方法で送信される。第１の通信デバイス１０８は、何らかのタイプのメッセージを平文で作成し、次いでそのメッセージは、暗号化アルゴリズム３１２によって暗号化される。暗号化アルゴリズム３１２は、暗号化キー３０４を利用し、この暗号化キー３０４は、キー３０４の実効キー・サイズすなわちキー強度よりも実際には大きなキー・サイズを有するように見える。いくつかのプロトコルにおいては、キー３０４は、「セッション・マスター・キー」として使用することができ、このセッション・マスター・キーから、暗号化および認証のためのセッション・キーを得ることができるという点を認識されたい。次いでメッセージ３１６の暗号文が作成されて、ネットワーク１０４を介して送信され、このネットワーク１０４は通常、インターネットのような信頼できないネットワークである。第２の通信デバイス１１２は、受信端３２４においてそのメッセージの暗号文を受信し、受信端３２４では、そのテキストを暗号化するために第１の通信デバイス１０８によって使用された同じキー３０４を利用して、暗号化アルゴリズム３２８によってそのメッセージの暗号文が復号される。そして第２の通信デバイス１１２のユーザは、平文メッセージ３３２を受け取って読むことができる。上述のように、キー３０４の実効キー・サイズは強くないかもしれないが、キー３０４の見た目によって、第三者１２０および１２４にとっては、強い暗号化キーのように見える。

固定されたキーＦは、おそらくは弱い暗号化を使用しなければならないと指定する規制の一環として、ライセンス・ファイルを介して、取引先（たとえば、第１の通信デバイス１０８および／または第２の通信デバイス１１２の所有者）へ分配することができる。これを利用して、保護された通信セッションを行う際に別々の取引先が同じキー・サブスペースを使用しないようにすることができる。したがって２つの別々の取引先は、他方が弱いキーに制限されていることをそれぞれ知っているが、他方のキーを容易に割り出すことはできない。というのは、それらの他方のキーを作成するために他方のシステムによって使用された固定されたキーを知らないためである。

次いで図４を参照して、本発明の少なくともいくつかの実施形態に従って、例示的な許可済み第三者確認デバイス１２０について説明する。許可済み第三者デバイス１２０は、ネットワーク１０４と通信するためのインターフェース４０４と、キー・デクリプター４０８と、キー還元メンバー４１２と、確認エージェント４１６とを含む。一般に、（ＮＳＡや商務省のような）許可済みの第三者は、米国外で販売されているシステムによって作成されたキーの実際のキー・サイズを確認する必要がある。許可済みの第三者は通常、拡張されたＫ_Ｅを突出したキーＫ_Ｓへと暗号化するために使用された固定されたキーＦを与えられる。そして許可済みの第三者は、分配されたキーを要求し、分配されたキーＫ_Ｓをインターフェース４０４において受け取る。分配されたキーＫ_Ｓは、キー・デクリプター４０８へ送信され、キー・デクリプター４０８では、固定されたキーＦを使用して、分配されたキーＫ_Ｓが復号され、したがって結果として、拡張されたキーＫ_Ｅがもたらされる。許可済みの第三者１２０は、使用された暗号化アルゴリズムが対称暗号化アルゴリズムである場合には、分配されたキーＫ_Ｓを暗号化するためにサーバによって使用された同じ暗号化アルゴリズムを利用することができる。あるいは、ハッシュ暗号化関数または何らかの非対称暗号化関数が使用されている場合には、許可済みの第三者１２０は、固定されたキーＦを利用して、作成されたキーＫ_Ｇによって占められている実際のキー・スペースを割り出すことができ、したがって、作成されたキーのキー・スペースを探ることが、より容易になる。したがって許可済みの第三者１２０は、分配されたキーＫ_Ｓを正しく復号するためには、固定された暗号化キーＦを必要とするだけでなく、どんな暗号化アルゴリズムが使用されたかも知る必要がある。

この時点で、許可済みの第三者は通常、拡張されたキーＫ_Ｅが、より小さな作成されたキー、たとえばＫ_Ｇに、複数の０、１、または１および０の固定された予測可能なパターンが連結されたものにすぎないと判断できるであろう。しかし、拡張されたキーＫ_Ｅを単に見ただけでは、もっと小さなキーが作成されたものとは見えないように、作成されたキーＫ_Ｇ内に０が挿入されている場合には、キー還元メンバー４１２が、Ｋ_Ｅの見た目のキー・サイズを還元し、その結果、キー・ジェネレータ２０４によって最初に作成された元のＫ_Ｇがもたらされる。そして、このキーを確認エージェント４１６へ送信することができ、確認エージェント４１６は、作成されたキーＫ_Ｇの実効キー・サイズが、分配されたキーＫ_Ｓの見た目のキー・サイズよりも小さいということ、したがって当該規制に準拠して作成されたものであるということを確認または否定することができる。

固定されたキーＦを公開することは、許可済みの第三者１２０が、分配された見た目は大きなキーＫ_Ｓを基本となる作成されたキーＫ_Ｇへ還元する上で非常に役に立つが、その他のセッション用のキーを見つける上では、それ以上の役には立たない。これは、作成された潜在的に弱いキーの周辺に別の層のセキュリティーを構築する上で役に立つ。

次いで図５を参照して、本発明の少なくともいくつかの実施形態に従って、キーを作成してそのキーを分配する方法について説明する。はじめに、第１の実効キー・サイズおよび対応する見た目のキー・サイズを有する第１のキーＫ_Ｇが作成される（ステップ５０４）。その後、第１のキーを拡張／突出させて、第１の実効キー・サイズおよび対応する見た目のキー・サイズを有する第２のキーＫ_Ｅが作成される（ステップ５０８）。拡張されたキーＫ_Ｅは、任意の数の方法で作成することができる。たとえば、作成されたキーＫ_ＧがＮビットの長さであり、Ｘ_１，Ｘ_２，Ｘ_３．．．Ｘ_Ｎという項目を有し、通常ではＮは１以上であると仮定する。すると、一実施形態においては、Ｋ_Ｇの末尾に最大でＭビットの０（および／または１）を付加することによって、Ｋ_Ｅを得ることができる。そしてＫ_Ｅは、Ｋ_Ｇ｜｜０_Ｎ＋１，０_Ｎ＋２，０_Ｎ＋３．．．０_Ｎ＋Ｍに等しくなり、この場合、通常では、Ｍは１以上であり、Ｋ_Ｅの見た目のキー・サイズはＮ＋Ｍであり、Ｋ_Ｅの実効キー・サイズは、やはりＮである。

ある代替実施形態においては、Ｋ_Ｇの前に最大でＭビットの０を付加することによって、Ｋ_Ｅを得ることができる。結果として得られるＫ_Ｅは、０_１−Ｍ，０_２−Ｍ，０_３−Ｍ．．．０_Ｎ−Ｍ｜｜Ｋ_Ｇとなり、Ｋ_Ｅの見た目のサイズは、やはりＮ＋Ｍに等しくなり、その一方でＫ_Ｅの実効キー・サイズはＮである。上述のように、Ｍビットの０の代わりに、Ｍビットの１を使用することができる。Ｍビットの０をＫ_Ｇの前または後ろのいずれかに配置してＫ_Ｅを形成することによって、作成されたキーＫ_Ｇのサイズを確認したいと望む許可済みの第三者にとって、作成されたキーＫ_Ｇの実効キー・サイズの確認が比較的容易になる。

さらに別の代替実施形態においては、Ｋ_Ｇのビット同士の間にＭビットの０（または１）を散りばめることによって、Ｋ_Ｅを得ることができる。結果として得られるＫ_Ｅは、Ｘ_１，０_１，Ｘ_２，０_２，Ｘ_３．．．Ｘ_Ｎとなる。これは、許可済みの第三者がＫ_Ｇの実効キー・サイズを割り出すことをより困難にする可能性があるが、サーバ１１６によって作成され分配されるキーを利用するシステムに別の層のセキュリティーを付け加える上で役に立つことができる。

ステップ５１２では、ステップ５１６において決定されるキー付き暗号化アルゴリズムを使用して、拡張されたキーＫ_Ｅを暗号化するか、またはその他の形で見た目のキー・スペースへと突出させる。決定された暗号化アルゴリズムには、決定された固定されたキーＦの使用が含まれる。固定されたキーＦは、キー・ジェネレータ２０４によって作成されるすべての拡張されたキーＫ_Ｅに対して、そのキーが作成されるセッションまたは時間を問わずにスクランブルをかけるために使用される。このようにすれば、固定されたキーＦを知っている許可済みの第三者は、キー・ジェネレータ２０４によって作成されるいかなるキーによって占められるキー・スペースも確認することができる。この暗号化アルゴリズムは、比較的強い暗号化キーＦを利用する、より強い暗号化アルゴリズムとすることができる。拡張されたキーＫ_Ｅを突出させた結果が、突出したキーＫ_Ｓであり、この突出したキーＫ_Ｓは、米国の輸出法規に準拠しつつ分配することができる。

ステップ５２０においては、突出したキーＫ_Ｓの受け手が決定される。受け手が決定されると、突出したキーＫ_Ｓは、決定された受け手に安全に分配される（ステップ５２４）。そして受け手は、分配されたＫ_Ｓを使用して、自分自身と別の通信デバイスとの間で情報の保護された送信を行うことができる。

次いで図６を参照して、本発明の少なくともいくつかの実施形態に従って、分配されたキーＫ_Ｓの実際のサイズを確認する方法について説明する。はじめに、分配されたキーＫ_Ｓが、許可済みの第三者１２０において受信される（ステップ６０４）。一般にキーＫ_Ｓは、作成されると、その他の任意のキーが（たとえば、メディアの暗号化を伴うコール・セットアップ要求に応答して）その他の任意の取引先に分配されるのと同様に、許可済みの第三者１２０へ安全に送信される。このようにすると、許可済みの第三者は、その許可済みの第三者用に特別に作成されたキーのキー強度を割り出すのではなく、通常のオペレーション内で送信された分配されたキーのキー強度を割り出すことができる。

許可済みの第三者１２０は通常、突出したキーＫ_Ｓを作成するために使用された固定されたキーＦを与えられている。ステップ６０８では、ステップ６１２において許可済みの第三者１２０に提供された突出暗号化アルゴリズムおよび固定されたキーＦを使用して、分配されたキーＫ_Ｓを復号する／スクランブルを外す。その後、許可済みの第三者１２０は、分配されたキーＫ_Ｓの実効キー・サイズを割り出すことができる（ステップ６１６）。上述のように、分配されたキーＫ_Ｓに対称暗号化アルゴリズムを用いてスクランブルがかけられている場合には、許可済みの第三者１２０は、固定されたキーＦを使用してキーのスクランブルを外し、作成されたキーと、そのキーを拡張するために使用された追加のビットとを含む拡張されたキーを見ることができる。分配されたキーＫ_Ｓに非対称暗号化アルゴリズムを用いてスクランブルがかけられている場合には、許可済みの第三者１２０は、固定されたキーＦを使用して、作成されたキーＫ_Ｓによって占められているキー・スペースを見つけ出すことができる。そして許可済みの第三者１２０は、分配されたキーＫ_Ｓのより大きな見た目のキー・スペースを探るのではなく、実際のキー・スペースを探ることができる。許可済みの第三者１２０は、その他の通信セッション内で作成されたキーに関連する何らかのさらなる情報を必ずしも与えられないかもしれないが、分配されたキーＫ_Ｓの実効サイズを割り出すことができる。

本発明は、さまざまな実施形態において、本明細書に記載され説明されているものと実質的に同様の構成要素、方法、プロセス、システム、および／または装置を含み、それらのさまざまな実施形態、副次的な組合せ、およびサブセットを含む。当業者が本開示を理解すれば、どのようにして本発明を作成して使用するかを理解できるであろう。本発明は、たとえば性能を高めるために、簡単さを実現するために、および／または実装のコストを削減するために、さまざまな実施形態において、本明細書に記載および／または説明されていないアイテムを伴わずにデバイスおよびプロセスを提供することを含み、あるいは本明細書に記載のさまざまな実施形態において、従来のデバイスまたはプロセスで使用されている可能性のあるアイテムを伴わずにデバイスおよびプロセスを提供することを含む。

本発明に関する前述の考察は、例示および説明の目的で提示されたものである。前述の内容は、本明細書に開示されている１つまたは複数の形態に本発明を限定することを意図するものではない。たとえば前述の「発明を実施するための最良の形態」においては、本発明のさまざまな特徴は、本開示を簡潔にする目的で１つまたは複数の実施形態内にグループとしてまとめられている。開示されているこの方法は、特許請求される本発明が、それぞれの請求項において明確に列挙されている以上の特徴を必要とするという意図を反映しているものと解釈すべきではない。それどころか、添付の請求項が示しているように、発明性を有する側面は、前述の開示された実施形態のうちの１つの実施形態のすべての特徴よりも小さな範囲内に存在する。したがって添付の請求項は、この「発明を実施するための最良の形態」の中に組み込まれつつも、それぞれの請求項は、本発明の別々の好ましい実施形態として独立している。

さらに、本発明の説明には、１つまたは複数の実施形態ならびに特定の変形形態および修正形態の説明が含まれているが、たとえば本開示を理解すれば当業者の技能および知識の範囲内に収まることができるようなその他の変形形態および修正形態も、本発明の範囲内である。特許請求されているものに対して代替の、交換可能な、および／または同等の構造、機能、範囲、またはステップを、そのような代替の、交換可能な、および／または同等の構造、機能、範囲、またはステップが本明細書に開示されているか否かを問わずに含む代替実施形態を、許される範囲内で含む権利を得ることを意図しており、いかなる特許性のある対象も公に限定する意図はない。

本発明の少なくともいくつかの実施形態による通信ネットワークを示すブロック図である。本発明の少なくともいくつかの実施形態による、スイッチやサーバのような中央のキー・ディストリビュータを示すブロック図である。本発明の少なくともいくつかの実施形態による、暗号化キーを利用する通信デバイスを示すブロック図である。本発明の少なくともいくつかの実施形態による、許可済みの第三者によって利用されるエンドポイントを示すブロック図である。本発明の少なくともいくつかの実施形態による、キーを作成する方法を示すフローチャートである。本発明の少なくともいくつかの実施形態による、キー強度を確認する方法を示すフローチャートである。

Claims

暗号化キーを作成する方法であって、
第１の見た目のサイズと第１の実効サイズとを有する第１のキーを作成するステップと、
固定されたキーを決定するステップと、
固定された暗号化アルゴリズムを選択するステップと、
前記固定されたキーおよび前記選択されたアルゴリズムを使用して、前記第１のキーを第２のキー・スペースへと突出させて、第２のキーを作成するステップであって、前記第２のキーが、第２の見た目のサイズと、実質的に前記第１の実効サイズとを有し、前記第２の見た目のサイズが、前記第１の見た目のサイズとは異なるステップと、
前記第２のキーを少なくとも１人の受け手に分配するステップとを含む方法。
前記第２の見た目のサイズが、前記第１の見た目のサイズよりも大きく、前記第１のキーの前記突出が、非対称暗号化アルゴリズムと、前記固定されたキーを利用する暗号化ハッシュ・アルゴリズムとのうちの少なくとも１つを採用するステップを含み、前記少なくとも１人の受け手が、許可済みの第三者を含む方法であって、
前記固定されたキーを前記許可済みの第三者に分配するステップと、
前記許可済みの第三者が前記第２のキーの前記第１の実効サイズを確認することができるように、前記第２のキーを前記許可済みの第三者へ送信するステップとをさらに含む請求項１に記載の方法。
前記第２の見た目のサイズが、前記第１の見た目のサイズよりも大きく、前記第１のキーの前記突出が、前記固定されたキーを利用する対称暗号化アルゴリズムを採用するステップを含み、前記少なくとも１人の受け手が、許可済みの第三者を含む方法であって、
前記固定されたキーを前記許可済みの第三者に分配するステップと、
前記許可済みの第三者が前記第２のキーの前記第１の実効サイズを確認することができるように、前記第２のキーを前記許可済みの第三者へ送信するステップとをさらに含む請求項１に記載の方法。
前記突出させるステップが、前記第１のキーをＭビットの０および／または１と結合するステップを含み、Ｍが１以上であり、前記Ｍビットの０および／または１が、前記第１のキーの前に配置されるか、前記第１のキーの後ろに配置されるか、前記第１のキー内に散りばめられるかの少なくとも１つである方法であって、
作成されたキーの最大実効サイズを割り出すステップと、
前記第２のキーを受け取るステップと、
前記第２のキーを分析して、前記第２のキーの前記実効サイズと、前記第２のキーの前記見た目のサイズとを割り出すステップと、
前記第２のキーの前記実効サイズが、作成されたキーの前記割り出された最大実効サイズ以下であることを判断するステップとをさらに含む請求項１に記載の方法。
前記第１の実効サイズが、輸出規制による許容されるキー作成サイズ以下であり、前記第２の見た目のサイズが、輸出規制による前記許容されるキー作成サイズよりも大きく、前記第１の実効サイズが６４ビットであり、前記第１の見た目のサイズが６４ビットであり、前記第２の見た目のサイズが６４ビットよりも大きい請求項１に記載の方法。
前記第１のキーが第１のキー強度を有する方法であって、
第３のキー強度と第３の見た目のサイズとを有する第３のキーを拡張して、前記第１のキーを作成するステップをさらに含み、前記第１のキーが、第３のキー強度と第３の見た目のサイズとを有し、前記第１のキー強度が、少なくとも前記第３のキー強度であるが、前記第１の見た目のサイズに基づくキー強度未満であり、前記使用するステップにおいて、前記固定されたキーを使用して前記第１のキーにスクランブルをかけて、前記第２のキーが作成される請求項１に記載の方法。
請求項１に記載の方法を実行するように機能する実行可能な命令を含むコンピュータ可読メディア。
暗号化キーを作成するためのデバイスであって、
第１の見た目のサイズと第１の実効サイズとを有する少なくとも１つの第１のキーを作成するためのキー作成手段と、
第２のキーを形成するために前記第１のキーを拡張するためのキー拡張手段であって、前記第２のキーが、第２の見た目のサイズと、実質的に前記第１の実効サイズとを有し、前記第２の見た目のサイズが、前記第１の見た目のサイズとは異なるキー拡張手段と、
固定されたキーと暗号化アルゴリズムとを利用して前記第２のキーにスクランブルをかけるためのキー・エンクリプター手段とを含むデバイス。
前記第２の見た目のサイズが、前記第１の見た目のサイズよりも大きく、前記暗号化アルゴリズムが、非対称暗号化アルゴリズムおよびハッシュ暗号化アルゴリズムのうちの少なくとも１つを含むデバイスであって、前記第２のキーを少なくとも１人の受け手へ送信するように機能するインターフェースをさらに含み、前記少なくとも１人の受け手が、許可済みの第三者を含み、前記固定されたキーが、前記許可済みの第三者に提供され、前記突出した第２のキーが、前記インターフェースを介して前記許可済みの第三者へ送信され、それによって前記許可済みの第三者が、前記第２のキーの前記第１の実効サイズを確認することができる請求項８に記載のデバイス。
前記第２の見た目のサイズが、前記第１の見た目のサイズよりも大きく、前記暗号化アルゴリズムが、対称暗号化アルゴリズムを含むデバイスであって、前記第２のキーを少なくとも１人の受け手へ送信するように機能するインターフェースをさらに含み、前記少なくとも１人の受け手が、許可済みの第三者を含み、前記固定されたキーが、前記許可済みの第三者に提供され、前記突出した第２のキーが、前記インターフェースを介して前記許可済みの第三者へ送信され、それによって前記許可済みの第三者が、前記第２のキーの前記第１の実効サイズを決定することができる請求項８に記載のデバイス。
前記キー拡張手段が、前記第２のキーを形成するために前記第１のキーをＭビットの０および／または１と連結し、Ｍが１以上であり、前記Ｍビットの０および／または１が、前記第１のキーの前に配置されるか、前記第１のキーの後ろに配置されるか、前記第１のキー内に散りばめられるかの少なくとも１つであり、前記第１の実効サイズが６４ビットであり、前記第１の見た目のサイズが６４ビットであり、前記第２の見た目のサイズが６４ビットよりも大きい請求項８に記載のデバイス。
前記第１の実効サイズが、輸出規制による許容されるキー作成サイズ以下であり、前記第２の見た目のサイズが、輸出規制による前記許容されるキー作成サイズよりも大きい請求項８に記載のデバイス。