(57)【特許請求の範囲】
【請求項１】
セキュアな通信チャネルにおいてセキュリティを向上させるためのコンピュータシステムが実行する方法であって、
モバイルデバイスまたは前記モバイルデバイスのユーザと関連付けられる文脈情報を収集することと、
トリガ状態が満たされているか否かを前記収集された文脈情報に基づいて判定することであって、前記トリガ状態が満たされているか否かは、前記モバイルデバイスに関連する利用可能な帯域及びセキュリティリスクを判定することを含む、前記判定することと、
前記トリガ状態が満たされていると判定することに応答して、第１の種類のキーラチェット動作を現在の暗号キーに行い前記暗号キーを更新することと、
前記トリガ状態が満たされていないと判定することに応答して、第２の種類のキーラチェット動作を前記現在の暗号キーに行い前記暗号キーを更新することであって、前記第１の種類のキーラチェット動作は、前記第２の種類のキーラチェット動作より高いセキュリティレベル、かつ、より高い通信オーバーヘッドを提供する、前記更新することと、
送信されるメッセージを、前記更新された暗号キーと関連付けられる暗号化キーを使用して暗号化することと、
を備える、方法。
【請求項２】
前記第１の種類のキーラチェット動作はディフィーヘルマンキーラチェット動作に関与し、前記第２の種類のキーラチェット動作はハッシュベースのキーラチェット動作に関与する、請求項１に記載の方法。
【請求項３】
前記文脈情報は、
前記第１の種類の前のキーラチェット動作が行われてからの時間間隔、
前記通信チャネルの現在の帯域、
前記ユーザの位置、
前記ユーザの移動パターン、
ネットワークトラフィックパターン、および、
前記モバイルデバイスの電池寿命、
のうちの１つ以上を含む、請求項１に記載の方法。
【請求項４】
前記セキュアな通信チャネルは、
Ｗｉ−Ｆｉチャネル、
３Ｇまたは４Ｇセルラーネットワークにおけるチャネル、および、
ショートメッセージサービス（ＳＭＳ）チャネル、
のうちの１つ以上を含む、請求項１に記載の方法。
【請求項５】
前記暗号化キーは、ハッシュベースのキー導出関数（ＨＫＤＦ）を使用して前記更新された暗号キーから導出される、請求項１に記載の方法。
【請求項６】
メッセージ認証コード（ＭＡＣ）を暗号化された前記メッセージで計算すること、
暗号化された前記メッセージを前記ＭＡＣと一緒に前記セキュアな通信チャネルで送信することとを、さらに含む、請求項１に記載の方法。
【請求項７】
コンピュータシステムにより実行されると、前記コンピュータシステムに、セキュアな通信チャネルにおけるセキュリティを向上させるための方法を行わせる命令を保存するコンピュータ可読保存媒体であって、前記方法は、
モバイルデバイスまたは前記モバイルデバイスのユーザと関連付けられる文脈情報を収集することと、
トリガ状態が満たされているか否かを前記収集された文脈情報に基づいて判定することであって、前記トリガ状態が満たされているか否かは、前記モバイルデバイスに関連する利用可能な帯域及びセキュリティリスクを判定することを含む、前記判定することと、
前記トリガ状態が満たされていると判定することに応答して、第１の種類のキーラチェット動作を現在の暗号キーに行い前記暗号キーを更新することと、
前記トリガ状態が満たされていないと判定することに応答して、第２の種類のキーラチェット動作を前記現在の暗号キーに行い前記暗号キーを更新することであって、前記第１の種類のキーラチェット動作は、前記第２の種類のキーラチェット動作より高いセキュリティレベル、かつ、より高い通信オーバーヘッドを提供する、前記更新することと、
送信されるメッセージを、前記更新された暗号キーと関連付けられる暗号化キーを使用して暗号化することと、
を備える、コンピュータ可読保存媒体。
【請求項８】
前記第１の種類のキーラチェット動作はディフィーヘルマンキーラチェット動作に関与し、前記第２の種類のキーラチェット動作はハッシュベースのキーラチェット動作に関与する、請求項７に記載のコンピュータ可読保存媒体。
【請求項９】
コンピュータシステムであって、
モバイルデバイスまたは前記モバイルデバイスのユーザと関連付けられる文脈情報を収集する手段と、
トリガ状態が満たされているか否かを前記収集された文脈情報に基づいて判定する手段であって、前記トリガ状態が満たされているか否かは、前記モバイルデバイスに関連する利用可能な帯域及びセキュリティリスクを判定することを含む、前記判定する手段と、
前記トリガ状態が満たされていると判定することに応答して、第１の種類のキーラチェット動作を現在の暗号キーに行い前記暗号キーを更新する手段と、
前記トリガ状態が満たされていないと判定することに応答して、第２の種類のキーラチェット動作を前記現在の暗号キーに行い前記暗号キーを更新する手段であって、前記第１の種類のキーラチェット動作は、前記第２の種類のキーラチェット動作より高いセキュリティレベル、かつ、より高い通信オーバーヘッドを提供する、前記更新する手段と、
送信されるメッセージを、前記更新された暗号キーと関連付けられる暗号化キーを使用して暗号化する手段と、
を含む、コンピュータシステム。
【請求項１０】
前記第１の種類のキーラチェット動作はディフィーヘルマンキーラチェット動作に関与し、前記第２の種類のキーラチェット動作はハッシュベースのキーラチェット動作に関与する、請求項９に記載のコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般的に、対称暗号化スキームに関する。より具体的には、本開示は、暗号化キーを適応的に更新し得る暗号化キーラチェットメカニズムに関する。
【背景技術】
【０００２】
モバイルコンピューティングデバイス（スマートフォンおよびタブレットコンピュータなど）の普及、および、これらのモバイルデバイス用に開発され増加の一途をたどるアプリケーション（アプリとも呼ばれる）により、モバイルデバイスユーザは、これらのデバイス上で個人またはビジネス関連の両方を含む多くのタスクを行うことが可能となっている。例えば、ユーザは、スマートフォンを介して銀行口座または企業データサーバにアクセスし得る。結果として、スマートフォンとサーバの間で機密情報がやり取りされる。このような機密情報をセキュアに保つことが、モバイルコンピューティングにおいて、ますます重要になっている。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
モバイルデバイス上のデータセキュリティを提供する１つの直接的な手法は、モバイルデバイスとの間で送信されるメッセージを暗号化することである。様々な暗号化スキームの中で、高度暗号化標準（ＡＥＳ）により規定されるようにブロック暗号を使用する対称キーアルゴリズムは、モバイル通信で使用される最も一般的な暗号化スキームである。他の対称キーアルゴリズムと同様に、ＡＥＳにおいて使用される暗号キーは、通信相手の間の共有秘密鍵である。通信の秘密性は、キーの秘密性に依存する。悪意のある第三者によるキーの不正アクセスを防止するために、定期的にキーを更新することが望ましい。一部の手法は、キー材料を前方へ継続的にラチェットして暗号化キーを経時的に更新するキーラチェットメカニズムに依存する。原則として、これらのキーラチェットメカニズムは、強秘匿性を達成することができ、過去の秘密性を（キー消去により）提供することができ、可能であれば未来の秘密性を提供することができる。「未来の秘密性」という用語は、個々のキーが不正アクセスされた場合、システムが（新たなラチェットキーを導入することにより）システム自体を「修復」し得ることを意味することに、留意されたい。しかしながら、ラチェットキーは、特にキーがメッセージごとに更新される場合、追加的な通信オーバーヘッドを導入し得る。
【課題を解決するための手段】
【０００４】
本発明の１つの実施形態は、セキュアな通信チャネルにおいてセキュリティを向上させるためのシステムを提供する。動作中、システムは、モバイルデバイスまたはモバイルデバイスのユーザと関連付けられる文脈情報を収集し、トリガ状態が満たされているか収集された文脈情報に基づいて判定する。トリガ状態が満たされていると判定すると、システムは、第１の種類のキーラチェット動作を現在の暗号キーに行って暗号キーを更新する。トリガ状態が満たされていないと判定すると、システムは、第２の種類のキーラチェット動作を現在の暗号キーに行って暗号キーを更新する。その後、システムは、更新された暗号キーと関連付けられる暗号化キーを使用して、送信されるメッセージを暗号化する。
【０００５】
本実施形態の変形において、第１の種類のキーラチェット動作は、第２の種類のキーラチェット動作より高いレベルのセキュリティを提供する。
【０００６】
さらなる変形において、第１の種類のキーラチェット動作はディフィーヘルマンキーラチェット動作に関与し、第２の種類のキーラチェット動作はハッシュベースのキーラチェット動作に関与する。
【０００７】
本実施形態の変形において、文脈情報は以下のうちの１つ以上を含む：前回の第１の種類のキーラチェット動作が行われてからの時間間隔、通信チャネルの現在の帯域幅、ユーザの位置、ユーザの移動パターン、ネットワークトラフィックパターン、およびモバイルデバイスの電池寿命。
【０００８】
本実施形態の変形において、セキュアな通信チャネルは以下を含む：Ｗｉ−Ｆｉチャネル、３Ｇまたは４Ｇセルラーネットワークにおけるチャネル、およびショートメッセージサービス（ＳＭＳ）チャネル。
【０００９】
本実施形態の変形において、暗号化キーは、ハッシュベースのキー導出関数（ＨＫＤＦ）を使用して更新された暗号キーから導出される。
【００１０】
本実施形態の変形において、システムは、さらに、メッセージ認証コード（ＭＡＣ）を暗号化されたメッセージにおいて計算し、暗号化されたメッセージをＭＡＣと一緒にセキュアな通信チャネルで送信する。
【図面の簡単な説明】
【００１１】
【図１】図１は、既存のキーラチェットメカニズムを図示する図を提示する。
【図２】図２（Ａ）及び図２（Ｂ）は、本発明の実施形態にしたがって、例示的なキーラチェットのタイムラインを図示する図を提示し、図２（Ｃ）は、本発明の実施形態にしたがって、セキュリティのレベルを時間の関数として図示する図を提示する。
【図３Ａ】図３Ａは、本発明の実施形態にしたがって、ＤＨラチェットの例示的なプロセスを図示する図を提示する。
【図３Ｂ】図３Ｂは、本発明の実施形態にしたがって、ハッシュベースのラチェットの例示的なプロセスを図示する図を提示する。
【図４】図４は、本発明の実施形態にしたがって、適応型キーラチェットのための例示的なシステムを図示する図を提示する。
【図５】図５は、本発明の実施形態にしたがって、例示的な通信プロセスを図示する図を提示する。
【図６】図６は、本発明の実施形態にしたがって、セキュアなＳＭＳベースのモバイルアプリケーション用の例示的な通信スタックを図示する図を提示する。
【図７】図７（Ａ）及び図７（Ｂ）は、本発明の実施形態にしたがって、セキュアなＳＭＳベースのモバイルアプリケーション用の例示的なメッセージフォーマットを図示する図を提示する。
【図８】図８は、本発明の実施形態にしたがって、例示的な暗号化された通信プロトコルを図示する図を提示する。
【図９】図９は、本発明の１つの実施形態にしたがって、適応型キーラチェットのための例示的なコンピュータおよび通信システムを図示する。
【発明を実施するための形態】
【００１２】
図において、同様の参照番号は同様の図要素を指す。
【００１３】
以下の説明は、当業者が実施形態を作製および使用可能なように提示され、特定の用途および要件の文脈において提供される。開示される実施形態への様々な修正が当業者に容易に明らかとなり、本明細書において規定される一般的な原理は、本開示の精神および範囲から逸脱することなく、他の実施形態および用途に適用されてよい。したがって、本発明は示される実施形態に限定されず、本明細書に開示される原理および特性と一致する最も広い範囲と合致する。
【００１４】
概要
本発明の実施形態は、ユーザの運動、通信パターン、セキュリティ要件などを含むが、それらに限定されない、複数のパラメータに基づいて、キーラチェット速度を自動的および動的に調整し得る適応型キーラチェットシステムを提供する。一部の実施形態において、キーラチェットは、制限帯域幅を有するショートメッセージサービス（ＳＭＳ）チャネルにおいて行われる。キーラチェットの適応型手法は必要なラチェット数を削減することができ、したがって、キーラチェットに起因する通信オーバーヘッド全体を削減できる。
【００１５】
ＡＥＳ暗号化およびキーラチェット
ＡＥＳは、レインダールブロック暗号に基づく対称暗号化アルゴリズムである。暗号学において、ブロック暗号は、対称キーにより特定される不変の変換で、「ブロック」と称される固定長のビット群において動作する決定論的アルゴリズムである。ＡＥＳは１２８ビットの固定長で動作し、１２８、１９２、または２５６ビットのキー長を支持する。例えば、ＡＥＳは、１２８ビットブロックの平文を入力とし、１２８ビット、１９２ビット、または２５６ビットの暗号化キーを使用して、対応する１２８ビットブロックの暗号文を出力し得る。
【００１６】
ブロック暗号は、固定キーにおける単一ブロックの暗号化のみに適しているため、多数の動作モードは、セキュアな手法において繰り返し使用されることが可能なように設計されている。より具体的には、動作モードは、どのように暗号の単一ブロック動作を繰り返し適用して、ブロックより大きい膨大なデータをセキュアに変換するのかを示す。最も単純な暗号化モードは、電子コードブック（ＥＣＢ）モードであり、メッセージをブロックに分割して各ブロックを個別に暗号化する。暗号ブロック連鎖（ＣＢＣ）は、別の動作モードである。ＣＢＣモードにおいて、平文の各ブロックは、暗号化される前に、前の暗号文ブロックで排他的論理和をとる。このように、各暗号文ブロックは、その地点まで処理された全ての平文ブロックに依存する。一方で、カウンタ（ＣＴＲ）モードは、ブロック暗号をストリーム暗号へ変える動作モードである。そのために、「カウンタ」の連続的な値を暗号化することにより、次のキーストリームブロックを生成する。カウンタは非循環配列を生じさせ得る任意の関数であり得るが、実際には、ほとんどの暗号化スキームは、増分１のカウンタを実装する。暗号フィードバック（ＣＦＢ）、出力フィードバック（ＯＦＢ）など、他の動作モードが多くある。
【００１７】
本開示において、ＣＴＲモードのＡＥＳ（ＡＥＳ−ＣＴＲ）は、様々な実施形態を拡張する際に例として使用される。しかしながら、本発明の範囲は、暗号化スキームにより限定されない。
【００１８】
ＣＴＲモードを含む多数の動作モードは、暗号化される平文、対称暗号化キー、および、初期化ベクトル（ＩＶ）と呼ばれる独自の列を入力とする。秘密を保たなければならない平文および暗号化キーと異なり、ＩＶは秘密を保つ必要がなく、暗号文と一緒に平文において送られ得る。一般的に、ＩＶは非循環である必要があり、動作モデルに依存して、ＩＶは乱数または疑似乱数である必要がある可能性がある。暗号化スキームによるＩＶの利用は強秘匿性を提供する。この特性により、同じキーでスキームを繰り返し利用することで、攻撃者は暗号化されたメッセージのセグメント間の関係を推論できない。これは、ＩＶが異なる暗号文を確実に各時間に生じさせるからである。ＡＥＳ−ＣＴＲにおいて使用されるＩＶは、メッセージカウンタと連結される無作為に生成されたノンスを含み得る。
【００１９】
ＩＶはＡＥＳの多くの動作モードに必須のコンポーネントであるが、メッセージごとに暗号化キーを変更するキーラチェットメカニズムは、ＩＶの使用を無関係にする。例えば、ＡＥＳ−ＣＴＲにおいて、暗号化キーがあらゆるメッセージに対して変更される限り、もはやＩＶを送信する必要はない。言い換えると、過去および潜在的な未来の秘密性に加えて、そのようなキーラチェットメカニズムは強秘匿性を提供し得る。
【００２０】
図１は、既存のキーラチェットメカニズムを図示する図を提示する。図１において、アリスは暗号化されたメッセージをボブへ送る。実際のメッセージコンテンツと共に、アリスは未来に使用する新しいキーを「通知」する。アリスのメッセージを受信すると、ボブは暗号化されたメッセージをアリスへ送り返す。実際のメッセージコンテンツと共に、ボブはアリスが通知したキーを「承認」し、さらに、ボブ自身の次のキーを通知する。その後、アリスは、次にアリスがメッセージを送る際に、通知および承認されたキーを使用する。このメカニズムは未来と過去の両方の秘密性を提供し得るが、キーラチェットは、あらゆるメッセージに対して行われるため、膨大なオーバーヘッドを生成する。加えて、このスキームは、キーが更新され得る前に、２つのメッセージの交換を必要とする。
【００２１】
本発明の一部の実施形態において、セキュリティを損なわずにキーラチェットのオーバーヘッドを削減するために、システムは暗号化キーを適応的にラチェットする。より具体的には、メッセージごとに暗号化キーをラチェットする代わりに、システムは、日時、ユーザの位置、利用可能な通信チャネルの帯域、ユーザの通信パターン、および、それらの任意の組み合わせを含むが、それらに限定されない、様々な動的要因に基づいて、ラチェットに適切な時間を選択する。例えば、（特に海外旅行の事例において）ユーザのコストを削減するために、特定のモバイルアプリケーションは、モバイルデバイスがＷｉ−Ｆｉチャネルへのアクセスを有さない場合、ＳＭＳチャネルでサーバと通信するよう構成されてよい。１５００バイトまでのパケットを許可するＷｉ−Ｆｉとは異なり、ＳＭＳはパケットサイズを１４０バイトまでに制限する。ＳＭＳにより提供される制限帯域幅は、任意のキーラチェット動作が膨大なオーバーヘッドをもたらし得ることを意味する。したがって、通信オーバーヘッドを削減するために、本発明の一部の実施形態において、システムは、モバイルデバイスがＷｉ−Ｆｉへのアクセスを有することが検出された場合のみ、キーラチェット動作を行うよう構成され得る。
【００２２】
図２（Ａ）は、本発明の実施形態にしたがって、例示的なキーラチェットのタイムラインを図示する図を提示する。図２（Ａ）において、モバイルデバイスは移動していて、様々な独立した期間にＷｉ−Ｆｉチャネルへのアクセスを有し得る。例えば、モバイルデバイスのユーザは、期間２０２、２０４、および２０６中、家、職場、または、Ｗｉ−Ｆｉへのアクセスを有する特定の公共の場所（例えば、空港または喫茶店）にいてよい。他の期間（例えば、期間２０８、２１０、および２１２）中、モバイルデバイスはＷｉ−Ｆｉアクセスを有さない。結果として、セキュアなチャネルを介してサーバへ接続する必要があるアプリケーションは、ＳＭＳなど、他の帯域制限された通信チャネルに依存しなければならない。図２（Ａ）に示される例において、システムは、モバイルデバイスがＷｉ−Ｆｉに接続されている期間中にのみキーラチェットを行うよう構成される。モバイルデバイスがＷｉ−Ｆｉに接続されていない期間中、システムは、ラチェットを行わずに現在の暗号化キーを使用し続けてよい。代替的に、システムは、モバイルデバイスがＷｉ−Ｆｉに接続されていない際、断続的なキーラチェットを行ってよい。例えば、システムは、たとえモバイルデバイスがＷｉ−Ｆｉ上になくても、５分または１０分ごとにキーラチェットを行ってよい。頻度の少ないキーラチェットにより生成されるオーバーヘッドは、大幅に少なくなり得る。
【００２３】
全てのキーラチェットが同等に作成されるとは限らない。暗号化キーをラチェットする１つの単純な例は、繰り返しハッシュすることである。キーが更新される際、通信パートナー間のメッセージ交換はないので、この手法はオーバーヘッドを生成しない。しかしながら、この単純な手法は、過去の秘密性を提供し得るのみで、未来の秘密性を提供しない。キーをラチェットする別の手法は、メッセージごとにＤＨキー交換を行うディフィーヘルマン（ＤＨ）ラチェット動作である。ＤＨラチェットは、過去および未来の秘密性を提供し得るが、膨大なオーバーヘッドを生成する。セキュリティを向上させながらオーバーヘッドを削減するために、一部の実施形態において、システムは、Ｗｉ−Ｆｉ接続期間中にＤＨラチェットを行い、他の期間中に安全性が低いハッシュベースのラチェットを行い得る。
【００２４】
図２（Ｂ）は、本発明の実施形態にしたがって、例示的なキーラチェットのタイムラインを図示する図を提示する。図２（Ａ）に示されるものと同様に、図２（Ｂ）において、モバイルデバイスは期間２０２、２０４、および２０６中にＷｉ−Ｆｉと接続され、期間２０８、２１０、および２１２中にＷｉ−Ｆｉアクセスを有さない。図２（Ｂ）に示される例において、モバイルがＷｉ−Ｆｉに接続されている際にシステムはＤＨラチェットを行い、そうでない場合にシステムはハッシュベースのラチェットを行う。ＤＨラチェットはメッセージごとに行われてよく、または、システムはモバイルデバイスがＷｉ−Ｆｉに接続されている期間中に断続的に（例えば、５分ごとに）ＤＨラチェットを行ってよいことに、留意されたい。ハッシュベースのラチェットは、オーバーヘッドを作成しないので、メッセージごとに行われ得る。
【００２５】
図２（Ｃ）は、本発明の実施形態にしたがって、セキュリティのレベルを時間の関数として図示する図を提示する。より具体的には、図２（Ｃ）は、図２（Ｂ）に示されるキーラチェットのタイムラインにしたがって、システムにより提供されるセキュリティレベルを概念的に図示する。図２（Ｃ）において確認され得るように、システムは、ＤＨラチェットが行われている際に高いレベルのセキュリティを取得し得る。提供されるセキュリティのレベルは、ＤＨラチェットがもう行われない場合、時間と共に徐々に低下する。図を単純化するために、セキュリティレベルは、時間の線形関数として低下するよう示されていることに、留意されたい。実際には、セキュリティレベルの低下は様々な要因に影響を受ける可能性があり、時間の線形関数でない可能性がある。図２（Ｃ）は、さらに、ＤＨラチェットが行われるたびに、セキュリティレベルが高いレベルへ回復されることを図示する。したがって、セキュリティレベルが危険なほど低くならないように、システムは、モバイルデバイスがＷｉ−Ｆｉに接続されていない場合でも、ＤＨラチェットを行ってよい。
【００２６】
図３Ａは、本発明の実施形態にしたがって、ＤＨラチェットのための例示的なプロセスを図示する図を提示する。図３Ａにおいて、クライアント３０２およびサーバ３０４の両方は、前のセッションキー（または、第１のＤＨ動作の場合、ＤＨマスタキー）Ｋｓ０＝ｇＡ０Ｂ０の知識を有する（動作３０６および３０８）。クライアント３０２は乱数Ａ０を知っており、サーバ３０４は乱数Ｂ０を知っている。動作中、クライアント３０２は乱数Ａ１を生成し（動作３１０）、一時的なセッションキーＫｔ１＝ｇＡ１Ｂ０を作成する（動作３１２）。この一時的なセッションキーは、ラチェットメカニズムの結果である。セッションキーを使用して、クライアント３０２は、メッセージを暗号化するために使用される、メッセージキーＫｍ１＝ＨＫＤＦ（Ｋｔ１）を作成し得る（動作３１４）。関数ＨＫＤＦは、ハッシュメッセージ認証コード（ＨＭＡＣ）ベースのキー導出関数（ＫＤＦ）であることに、留意されたい。ＨＫＤＦの詳細な説明は、インターネット技術タスクフォース（ＩＥＴＦ）のＲＦＣ５８６９で確認することができ、ＩＥＴＦのウェブサイトで入手可能である。
【００２７】
その後、クライアント３０２は、メッセージキーを使用してメッセージを暗号化し、暗号化されたメッセージを乱数Ａ１およびメッセージ認証コード（ＭＡＣ）と共に送る（動作３１６）。ＭＡＣはメッセージを認証するために使用され、ＨＭＡＣなどの暗号ハッシュ関数に基づいて生成され得る。ＨＭＡＣ関数の詳細な説明は、インターネット技術タスクフォース（ＩＥＴＦ）のＲＦＣ２１０４で確認することができ、ＩＥＴＦのウェブサイトで入手可能である。図３Ａに示される例において、ＭＡＣの生成はメッセージキーに関与する。
【００２８】
暗号化されたメッセージを受信すると、サーバ３０４は、一時的なセッションキーおよびメッセージキーを計算する（動作３１８）。サーバ３０４は、受信されたメッセージを、セッションキーを使用して復号し得る（動作３２０）。続いて、サーバ３０４は乱数Ｂ１を生成し（動作３２２）、Ａ１およびＢ１を使用して新しいセッションキーＫｓ１＝ｇＡ１Ｂ１を作成する（動作３２４）。新しいセッションキーを使用して、サーバ３０４は、新しいメッセージキーＫｍ２＝ＨＫＤＦ（Ｋｓ１）を生成する（動作３２６）。新しいメッセージキーは、リプライメッセージおよびＭＡＣの暗号化のためにサーバ３０４により使用され得る。その後、サーバ３０４は、暗号化されたリプライを乱数Ｂ１およびＭＡＣと共にクライアント３０２へ送り得る（動作３２８）。その後、クライアント３０２は、新しいセッションキーおよび新しいメッセージキーを計算し（動作３３０）、リプライを復号し得る（動作３３２）。新しいセッションキーはキーラチェットの結果であり、クライアント３０２は、新しいメッセージキーを使用してサーバ３０４への次のメッセージを暗号化することに、留意されたい。
【００２９】
図３Ｂは、本発明の実施形態にしたがって、ハッシュベースのラチェットのための例示的なプロセスを図示する図を提示する。図３Ｂにおいて、新しいセッションの開始時に、クライアント３５２およびサーバ３５４の両方が、前のセッションキーＫｓ１＝ｇＡ１Ｂ１および第１のメッセージキーＫｍ１＝ＨＫＤＦ（Ｋｓ１）の知識を有していると想定する（動作３５６および３５８）。動作中、クライアント３５２は、メッセージ暗号化のために使用されるメッセージキーＫｍ２＝ＨＫＤＦ（Ｋｍ１）を生成する（動作３６０）。クライアント３５２は、新しく生成されたメッセージキーを使用してメッセージを暗号化し、暗号化されたメッセージをＭＡＣと共に送る（動作３６２）。
【００３０】
暗号化されたメッセージを受信すると、サーバ３５４はメッセージキーを計算し（動作３６４）、計算されたメッセージキーを使用してメッセージを復号する（動作３６６）。サーバ３５４は、計算されたメッセージキーをハッシュすることにより、メッセージキーＫｍ３＝ＨＫＤＦ（Ｋｍ２）を生成し得る（動作３６８）。その後、サーバ３５４は、新しく生成されたメッセージキーを使用してメッセージを暗号化し、暗号化されたメッセージをＭＡＣと共にクライアント３５２へ送る（動作３７０）。クライアント３５２はメッセージを受信し、前のメッセージキーを使用して現在のメッセージキーを計算し（動作３７２）、計算されたメッセージキーを使用してメッセージを復号する（動作３７４）。クライアント３５２またはサーバ３５４がメッセージを送信または受信するたびに、ＨＫＤＦ関数を使用してメッセージキーを更新することに、留意されたい。図３Ｂで確認し得るように、クライアント３５２とサーバ３５４との間で交換される情報は、暗号化されたメッセージおよびＭＡＣのみを含み、オーバーヘッドを招かない。
【００３１】
図２（Ａ）〜図２（Ｂ）に示される例において、キーをラチェットするかの決定は、モバイルデバイスがＷｉ−Ｆｉに接続されているかに基づいて行われる。実際には、さらに、最後のキーラチェット動作からの経過時間、ユーザの位置、ユーザが機密情報を送信／受信しているか、または、モバイルデバイスが現時点で移動しているか（チャネル品質の低下をもたらし得る）を含むが、それらに限定されない、他の要因を考慮する必要がある可能性がある。
【００３２】
図２（Ｃ）に示されるように、よりセキュアなＤＨラチェットを行うことを長期間にわたり控えることは、危険であり得る。したがって、システムは、各ラチェットの時間の経過を追跡してよい。現在の時間と最後のラチェットの時間との間の差異が閾値を超えているとシステムが判定した場合、システムはＤＨラチェットを行ってよい。システムは、さらに、接続されたＷｉ−Ｆｉアクセスポイントまたはセルラーネットワークの基地局に基づいて、ユーザの位置を追跡することができ、位置の変化を検出するたびに、ＤＨラチェットを行う。さらに、システムは、多数のセキュアな位置を規定し、ユーザがセキュアな位置にいることを検出した場合、よりセキュアで計算的に高価なＤＨラチェットを一時的に停止してよい。例えば、ユーザが会社にいて、同僚と通信するために会社のセキュアなＷｉ−Ｆｉネットワークを使用している際、システムは、そのような通信は本質的にセキュアであるとみなし、さらにセキュアなＤＨラチェットを要求しない。同様に、システムは、多数のインセキュアな位置を規定してよい。例えば、ユーザが好ましくない環境にいて、誰かがメッセージにアクセスしようと試みている可能性が高い場合、システムは、Ｗｉ−Ｆｉまたは他の高帯域チャネルが利用できない状況においても、メッセージごとにＤＨラチェットを行うよう構成されてよい。
【００３３】
代替的に、システムはユーザの通信パターンを監視してよく、ユーザが特定数のメッセージを送信／受信するたびにキーラチェット（例えば、ＤＨラチェット）を行ってよい。これにより、悪意のある第三者がハッシュラチェットされた暗号化キーの知識を十分に蓄積する状況を防ぐことができる。加えて、ユーザはセキュリティの好みを規定してよい。例えば、ユーザが友人と両者が見た映画に関して通信している場合、ユーザは、そのような通信が安全であり、キーラチェットを要求していないとみなしてよい。システムは、さらに、メッセージが機密であるかをメッセージの文脈に基づいて判定し得る。例えば、システムは一連の機密の単語を集めてよい。メッセージが機密の単語を含む場合、機密とマーク付けされ得る。結果として、メッセージが送られる前に、ＤＨラチェットが行われて新しいセッションキーがそのメッセージに対して確実に生成される。考慮すべき他の事項は、ネットワークトラフィックパターン、電池寿命、および、他のセンサの出力を含み得る。ネットワークトラフィックが重いと、システムはラチェットの遅延を招く可能性がある。同様に、電池寿命が短い場合、高リスクな状況でない限り、システムにラチェットを行わせない可能性がある。モバイルデバイスに搭載されているセンサからの出力が、システムが別の方法では利用可能でない可能性がある追加的な文脈情報を判定することを支援するようにしてもよい。例えば、ユーザの位置がネットワークアクセスポイントに基づいて判定され得ない状況において、システムは位置情報をＧＰＳ（全地球測位システム）モジュールから取得してよい。
【００３４】
図４は、本発明の実施形態にしたがって、適応型キーラチェットのための例示的なシステムを図示する図を提示する。図４において、適応型キーラチェットシステム４００は、文脈情報収集モジュール４０２、トリガ状態判定モジュール４０４、キーラチェットモジュールＩ４０６、キーラチェットモジュールＩＩ４０８、メッセージキー生成モジュール４１０、および、メッセージ暗号化モジュール４１２を含む。
【００３５】
文脈情報収集モジュール４０２は、モバイルデバイスおよびモバイルデバイスのユーザと関連付けられる文脈情報を収集する役割を果たす。一部の実施形態において、文脈情報収集モジュール４０２は、文脈情報を収集するために、モバイルデバイスに搭載される様々なセンサと連結し得る。そのような情報は、トリガ状態判定モジュール４０４へ送られ、キーラチェットトリガ状態が満たされているか判定する。トリガ状態判定モジュール４０４の出力は、キーラチェットモジュールのうちの１つを起動するよう構成され得る。キーラチェットモジュールＩ４０６は、通信オーバーヘッドの増大を犠牲にして、よりセキュアなキーラチェット動作を行うよう構成される。キーラチェットモジュールＩＩ４０８は、より低セキュアのキーラチェット動作を行うよう構成されるが、オーバーヘッドを招かない。動作中、キーラチェットモジュールは、モバイルデバイスの内部メモリにアクセスし、現段階で使用されているセッションキーを取得するよう構成され、その後、対応するラチェット動作をセッションキーにおいて行う。さらにセキュリティを提供するために、キーラチェットモジュールの出力は、メッセージキー生成モジュール４１０へ送られ、ＨＫＤＦ関数を使用してメッセージキーを生成し得る。その後、メッセージ暗号化モジュール４１２は、メッセージキーを使用してメッセージを暗号化し得る。
【００３６】
図５は、本発明の実施形態にしたがって、例示的な通信プロセスを図示する図を提示する。動作中、システムは初期化を行う（動作５０２）。クライアントサーバ間通信では、システムはクライアントおよびサーバを初期化する。ピアツーピア通信では、システムは両方のクライアントデバイスを初期化する。初期化プロセスは、典型的に、クライアントとサーバ（または、クライアントのピア）との間の長期共有秘密をやり取りすることが目的であるキー（マスタキーとも呼ばれる）の確立に関与する。モバイルデバイスは、Ｗｉ−Ｆｉまたは他の高帯域チャネル（例えば、３Ｇまたは４Ｇセルラーネットワーク）と初期化中に接続されると推測され得る。様々な手法が、マスタキーを確立するために使用され得る。一部の実施形態において、トランスポート層セキュリティ（ＴＳＬ）プロトコルにより既定されるように、標準的なキー交換手順がマスタキーを確立するために使用され得る。ＴＬＳプロトコルの詳細な説明は、インターネット技術タスクフォース（ＩＥＴＦ）のＲＦＣ５２４６において確認されることができ、ＩＥＴＦのウェブサイトで入手可能である。ＴＬＳによると、ＲＳＡ暗号化事前共有秘密の直接的な送信およびディフィーヘルマン（ＤＨ）キー交換を含む、キー確立のための２つの可能な手法がある。どちらの手法も、良好なセキュリティのために２０４８ビットスペースにおいて動作する必要がある。ＤＨキー交換は、わずかに高い通信オーバーヘッドを有する。キー交換が１４０バイト長のＳＭＳメッセージを使用して行われる場合、ＤＨキー交換は最大で８個のＳＭＳメッセージを必要とする可能性があるが、事前共有秘密に基づく手法がキー確立のために必要とするのは４個のＳＭＳメッセージだけである。
【００３７】
マスタキーが生成されると、モバイルデバイス上に安全に保存されなければならない。マスタキーの安全性を確保するために、様々な手法が使用され得る。１つの解決策は、マスタキーを使用するアプリケーションと関連付けられる内部ストレージに、マスタキーを保存することである。加えて、アプリケーションにアクセス不能なキーを使用してマスタキーを暗号化する要望がある可能性がある。
【００３８】
セキュアなチャネルの確立後、ユーザは認証される必要がある（動作５０４）。これは、パスワード認証プロトコル（ＰＡＰ）、チャレンジハンドシェイク認証プロトコル（ＣＨＡＰ）、および、拡張認証プロトコル（ＥＡＰ）など、チャレンジレスポンスプロトコルを使用して行われ得る。
【００３９】
モバイルデバイスがサーバまたはピアとの間でメッセージを送信または受信する前に、システムは、ユーザおよびモバイルデバイスと関連付けられる文脈情報を収集する（動作５０６）。既に記述したように、時間および位置情報、ユーザの移動情報、ユーザの通信パターンと関連付けられる情報、インターネットへのアクセス可能性（モバイルデバイスがＷｉ−Ｆｉまたは他の高帯域データチャネルと接続されるか）、ネットワークトラフィックに関する情報、電池寿命、およびモバイルデバイス上の様々なセンサの出力を含むが、それらに限定されない、様々な文脈情報がモバイルデバイスにより収集され得る。文脈情報の一部はユーザの行動に関連し、一方で一部はモバイルデバイスのネットワーク環境に関連してよい。
【００４０】
その後、システムは、収集された文脈情報に基づいて、トリガ状態が満たされているか判定する（動作５０８）。満たされている場合、システムは、高いレベルのセキュリティを提供し得るキーラチェット動作を行う（動作５１０）。例えば、システムは、ＤＨラチェットを行ってよく、Ｗｉ−Ｆｉが利用できない場合にＷｉ−ＦｉチャネルまたはＳＭＳチャネルでメッセージを交換することに関与し得る。ＳＭＳベースのアプリケーションでは、この手法は、既存の通信をＷｉ−ＦｉでピギーバックしてＳＭＳチャネルの利用を削減するので、低いオーバーヘッドを招くことに、留意されたい。ＳＭＳのみが利用可能な場合であっても、図３Ａに示されるように、ＤＨラチェットは余分なＳＭＳメッセージの使用を必要とせず、既存の通信に適合し得る。ＤＨラチェットに起因するオーバーヘッドは、楕円曲線の代数構造においてＤＨを平面有限領域の代わりに有限領域で使用する、楕円曲線ＤＨ（ＥＣＤＨ）を使用することにより削減され得る。ＥＣＤＨを使用して、オーバーヘッドは２つのメッセージにおいて４２バイトまで削減され得る。
【００４１】
トリガ状態が満たされていない場合、システムは比較的に低いレベルのセキュリティを提供するのみのキーラチェットを行うか、または、システムはキーをラチェットしない可能性がある（動作５１２）。例えば、システムは、オーバーヘッドを招かない、ハッシュベースのラチェットを行ってよい。ハッシュベースのラチェットに使用されるパケットは（図３Ｂに示されるように）同じままであるので、このスキームは帯域制限されたＳＭＳチャネルと良好に適合することに、留意されたい。ハッシュベースのラチェットに加えて、システムは、（ＡＥＳ−ＣＴＲモードにおいて通信パートナー間で交換される情報の一部である）ＩＶおよびキーを、同じ暗号化キーを使用して更新してよい。それを行う１つの手法は、メッセージカウンタに依存してＩＶを更新することである。メッセージカウンタが利用できない事例において、クライアントおよびサーバは、キャッシュされたメッセージカウンタを各々が維持し得る。メッセージ交換ごとに、両方がカウンタの値を増やして同期を維持する。この手法はオーバーヘッドを増やさず、小さいメモリフットプリントを有する。
【００４２】
既に述べたように、トリガ状態を規定する様々な基準がある。１つの単純な手法は、通信チャネルの時間および利用可能性に基づいてトリガ状態を規定することである。より具体的には、システムは、ラチェット間隔および最大ラチェット間隔の２つのタイミング閾値を規定し得る。トリガ状態は、モバイルデバイスがＷｉ−Ｆｉと接続されており、最後のラチェット動作からの時間間隔がラチェット間隔を超えた場合、満たされ得る。代替的に、トリガ状態は、モバイルデバイスが静止したままであり、送信され得るＳＭＳメッセージの数に制限がない場合、満たされ得る。これは、移動しているモバイルデバイスは、チャネル品質の低下を生じ、ＳＭＳメッセージの送信不具合をもたらし得るため、ＤＨキーラチェットに適した状態ではないからである。同様に、ＤＨラチェットはオーバーヘッドを生成するため、許容されたＳＭＳメッセージの数に制限がない場合に行われなければならない。最終的に、トリガ状態は、最後のラチェット動作からの時間間隔が最大ラチェット間隔を超える場合に、満たされる。この最大ラチェット間隔の判断は、全ての他の判断より優先されることに、留意されたい。言い換えると、最大ラチェット間隔が達成される際、ネットワーク接続性の状況（すなわち、モバイルデバイスが高帯域幅チャネルと接続されているかまたは帯域制限チャネルと接続されているか）に関わらず、システムはＤＨラチェットを行って新しいキーを生成する。
【００４３】
続いて、システムは、ラチェットされたキーから生じるメッセージキーを使用してメッセージを暗号化し、暗号化されたメッセージを送信する（動作５１４）。
【００４４】
図５に示される例示的なプロセスは、セキュアな通信の片方の側により行われ得る。クライアントサーバ通信の事例において、クライアントは、独自の文脈情報に基づいて、よりセキュアなラチェットを行うか判定してよい。一方で、サーバは、さらに、文脈情報をクライアントから取得することができ、そのような情報を使用してセキュアなラチェットを行うか判定する。代替的に、サーバは、さらに、独自の規則を課してよく、特定のトリガ状態が満たされている際にセキュアなラチェットを始動する。ピアツーピア通信の事例において、片側のクライアントデバイスは、独自の文脈情報に基づいてトリガ状態が満たされていると判定した場合、セキュアなラチェットを始動し得る。
【００４５】
セキュアなＳＭＳベースのモバイルアプリケーション
既に記述されているように、ＳＭＳは通信の低価格な手法を提供することができ、ＳＭＳを通信チャネルとして使用して３Ｇまたは４Ｇセルラーデータネットワークの高いローミングフィーの支払いを回避するために、様々なモバイルアプリケーションが開発され得る。例えば、モバイルデバイス上で起動するクライアントは、ＨＴＴＰ（ハイパーテキスト転送プロトコル）トラフィックを、２Ｇネットワークで送信される連続するＳＭＳメッセージへ圧縮し得る。これらのＳＭＳメッセージは、アプリケーションのサーバで読み出され、他のオンラインサービスへ転送され得るＨＴＴＰメッセージに再結合される。同様のことが、サーバからクライアントへ送り返されるメッセージに対して起こり得る。結果として、帯域制限されたＳＭＳチャネルを使用して、モバイルデバイスのユーザは様々なオンラインサービスにアクセスし得る。しかしながら、この手法の１つの重大な欠点は、ＳＭＳチャネルのセキュリティが欠けていることである。より具体的には、現在のＳＭＳ通信は暗号化されず、多くの潜在的な攻撃にさらされ得る。例えば、仲介媒体（例えば、セルラーネットワークオペレータおよびＳＭＳルータ）は、ＳＭＳコンテンツを受動的に収集し得る。さらに悪いことに、活動中の攻撃者は、ＳＭＳメッセージを注入、修正、または、中継することができ、中間者攻撃を介して通信の完全制御を取得することさえできる。
【００４６】
ＳＭＳベースのアプリのためにセキュリティを提供することは、ＳＭＳチャネルと関連付けられる固有の制約のため困難であり得る。より具体的には、ＳＭＳのパケットサイズは１４０バイトに制限され、配信、順序付け、タイミング、または、複製保護の保証がないため、ＳＭＳトランスポートは信頼性が低くなり得る。既存のＳＭＳセキュリティ手法は、十分にセキュアでないか（例えば、未来の秘密性を提供しない）、または、過多の通信オーバーヘッドを招くか、のいずれかである。
【００４７】
適応型キーラチェットシステムにより、セキュアに暗号化されたオーバーヘッドの少ないＳＭＳ通信が可能となる。図６は、本発明の実施形態にしたがって、セキュアなＳＭＳベースのモバイルアプリケーションのための例示的な通信スタックを図示する図を提示する。図６において、セキュアなＳＭＳベースのモバイルアプリケーションの通信スタックは、アプリケーション層６０２、トランスポート層６０４、セキュリティ層６０６、ＳＭＳ層６０８、および、データリンク層６１０を含む。図６の右側は、各層のデータフレームを示す。トランスポート層６０４は、アプリケーション層６０２におけるペイロード６１２を圧縮し、適切なヘッダを付けてデータフレーム６１４を取得する。セキュリティ層６０６は、圧縮されたペイロードを暗号化してＭＡＣを付け、データフレーム６１６を生じさせる。１２８ビットのブロック暗号を使用する暗号化スキームでは、暗号化されたペイロードは、典型的に、１２８の倍数のビットを含み得る。ＭＡＣは、８０ビット長であり得る。ＳＭＳ層６０８は、ペイロードを拡張し得るＢａｓｅ６４符号化を使用して、データフレーム６１６を暗号化する。その後、符号化されたデータフレームは、各々が１１２０ビットの長さを有するＳＭＳデータフレーム６１８および６２０に適合される。
【００４８】
図７（Ａ）は、本発明の実施形態にしたがって、セキュアなＳＭＳベースのモバイルアプリケーションのための例示的なメッセージフォーマットを図示する図を提示する。図７（Ａ）において、メッセージヘッダは、８ビットのプロトコル識別子（ＰＩＤ）フィールド、８ビットのメッセージＩＤ（ＭＩＤ）フィールド、および、８ビットの予備フィールドを含む。メッセージは、さらに、暗号化されたペイロードフィールドおよび８０ビットのＭＡＣフィールドを含む。ＭＡＣはヘッダおよびペイロードの両方で計算されることに、留意されたい。
【００４９】
図７（Ｂ）は、本発明の実施形態にしたがって、セキュアなＳＭＳベースのモバイルアプリケーションのための例示的なメッセージフォーマットを図示する図を提示する。図７（Ｂ）において、メッセージは、ここでは連結されたＳＭＳメッセージにおけるメッセージ列およびメッセージの総数を示す８ビットのＣＩＤ／ＴＯＴフィールドをヘッダが含むこと以外は、図７（Ａ）と類似のフォーマットを有する連結されたＳＭＳメッセージである。
【００５０】
選択平文攻撃（ＣＰＡ）セキュリティおよび選択暗号文攻撃（ＣＣＡ）セキュリティを含む、実際に達成され得る様々なレベルのセキュリティがある。ＣＰＡセキュリティは強秘匿性とも呼ばれる。これは、任意の平文を暗号化する能力による重大な利点を敵対者が得ないことを意味する。ＣＰＡは受動的な攻撃に関し、最低限の望ましいセキュリティレベルとみなされることが多い。一方で、ＣＣＡセキュリティは、暗号文を復号する能力による重大な利点を敵対者が確実に得ないようにする。言い換えると、ＣＣＡは、選択した他の暗号文の復号化へアクセスがあっても、暗号文を所与される基本的な平文に関するいかなる情報も敵対者が学習し得ないことを保証する。ＣＣＡセキュリティは、ＣＰＡセキュリティより強い保護を提供するが、実際には達成するのが難しい。例えば、ＡＥＳ−ＣＴＲはＣＰＡセキュアであるが、ＣＣＡセキュアではない。
【００５１】
本発明の実施形態において、ＡＥＳ−ＣＴＲスキームは、認証された暗号化がＣＣＡセキュアであるため、暗号化ＭＡＣプロセスを使用してＣＣＡセキュアなスキームに導入される。ほとんどのＣＣＡ攻撃は、チャレンジを修正した後に復号オラクルへ送り込む攻撃者に依存しており、復号オラクルの答えにより攻撃者は暗号化されたメッセージを知ることができる。しかしながら、認証された暗号化スキームは、不適切に構築された暗号文を認識し、復号することを拒否し得る。したがって、暗号化の上位にＭＡＣを含むことにより、攻撃者が暗号文に手を加えるのを防ぐことができ、それにより、復号オラクルが原則的に役に立たないようにする。
【００５２】
図８は、本発明の実施形態にしたがって、例示的な暗号化された通信プロトコルを図示する図を提示する。図８において、クライアント８０２は、署名キー（Ｋｓ）および暗号化キー（Ｋｅ）を、クライアント８０２とサーバ８０４との間の共有秘密であるマスタキーから導出する。ＫｓおよびＫｅを導出する１つの単純な手法は、マスタキーをＳＨＡ−２５６でハッシュして、最初の１２８ビットを暗号化キーとして使用し、最後の１２８ビットを署名キーとして使用することである。ＡＥＳ−ＣＴＲはメッセージ（ｍ）を暗号化するために使用され、平文メッセージ（ｍ）、暗号化キー（Ｋｅ）、および、暗号化キーと同じ長さのＩＶを入力として取り込む。１２８ビットのＩＶは、６４ビットのノンスを６４ビットのメッセージカウンタと連結させることにより、構築され得る。暗号文（ｃ）は、ｃ＝ＡＥＳ−ＣＴＲ（ｍ，ＩＶ，Ｋｅ）として生成され得る。メッセージが１２８ビットより長い場合、分割される必要があり、必要に応じて１２８ビットのブロックに増やされる必要がある。
【００５３】
ＩＶおよび暗号文は両方とも、ＭＡＣを構築するために使用される。一部の実施形態において、ＨＭＡＣは、タグをｔａｇ＝ＳＨＡ−２５６（Ｋｓ｜｜ＳＨＡ−２５６（Ｋｓ｜｜ＩＶ｜｜ＭＩＤ｜｜ｃ））として計算するために使用される。暗号文だけでなく、ＳＭＳチャネルを介して送られる全ての要素にＭＡＣを適用することが重要であることに、留意されたい。ここで計算されるタグは２５６ビットであるが、強固な認証を提供しながらオーバーヘッドを削減するために、８０ビットまで切り捨てられ得る。ＩＶ、暗号文、およびタグは、図８に示されるように、ＳＭＳチャネルを介して搬送される。さらに、図８に示されるように、サーバ８０４は、署名キー（Ｋｓ）および暗号化キー（Ｋｅ）を導出し、タグを検証し、暗号文を復号する。
【００５４】
追加的なセキュリティ層から生じる通信オーバーヘッドを削減するには、様々な手法がある。例えば、ＩＶは暗号文と共に送られ、キー確立フェーズでノンスを送信することにより送信される各々のＩＶの長さを削減し得る。結果として、ＩＶのメッセージカウンタ部分のみが送信される必要がある。
【００５５】
さらに、オーバーヘッドはＩＶを全く送信しないことにより削減され得る。代わりに、メッセージＩＤ（図７（Ａ）〜図７（Ｂ）に示される）が、メッセージカウンタを置換するために使用され得る。しかしながら、メッセージＩＤは８ビットの長さしかなく、したがって、２５６個のメッセージまでカウントアップするのみである。これを克服するために、２５６個のメッセージごとにマスタキーを更新し得る。他の選択肢は、２５６個のメッセージごとに値を増加させる局所的にキャッシュされたカウンタを維持し、ノンスのＳＨＡ−２５６、キャッシュされたカウンタ、および、メッセージＩＤをＩＶとして使用することである。すなわち、ＩＶ＝ＳＨＡ−２５６（ｎｏｎｃｅ｜｜ｃａｃｈｅｄ＿ｃｏｕｎｔｅｒ｜｜ＭＩＤ）である。言い換えると、クライアントおよびサーバは、もはやＩＶと通信する必要はなく、２５６個のパケットごとにキャッシュされたカウンタを更新する必要があるのみである。この手法は、実装し易さ、効率性、および、復元力の間で良好なトレードオフを提供する。より具体的には、この暗号化スキームは、通信オーバーヘッドを全く増大させない。ＩＶのオーバーヘッドを削減するための別の手法は、前のＩＶをハッシュして次のＩＶを生成することに依存する。
【００５６】
既に説明されたように、キーラチェットは、さらに、セキュリティを向上させ得る。さらに、キーラチェットが行われる際、たとえメッセージごとではなくても、図３Ａ〜図３Ｂに示されるように、もはやＩＶの必要性はない。ラチェットは追加的なオーバーヘッドを追加するが、適応型ラチェット（図４に図示されるように）はオーバーヘッド全体を削除することができ、一方で高いレベルのセキュリティを提供し続ける。
【００５７】
ＳＭＳベースのアプリケーションに対する通信オーバーヘッドの削減のための別の手法は、ＭＡＣの送信に起因するオーバーヘッドを削減することである。そのための１つの手法は、メッセージごとに単一のＭＡＣを使用する代わりに、メッセージの群ごとに１つのＭＡＣを使用することである。しかしながら、群における１つの破損メッセージは群における全てのメッセージの再送を必要とし得るため、再送の増大をもたらす可能性がある。別の手法は、ＭＡＣを全く使用しないことを含み、送信されたメッセージの既知の構造に依存して認証を提供する。しかしながら、これによりセキュリティ保護が弱まる可能性がある。
【００５８】
加えて、長期にわたるＳＭＳメッセージが交換される状況において、ハッシュ木（マークル木としても知られる）の使用を考慮することが有益である可能性がある。ＭＡＣと併せて、これらのハッシュ木は、オーバーヘッドがわずかに大きくなることを犠牲にして、より効率的なエラー検出を可能にする。
【００５９】
一般的に、本発明の実施形態は、ＳＭＳベースの通信においてセキュリティを確保するための手法を提供する。ネットワーク環境と共にユーザの行動に適応するキーラチェット動作で対称暗号化を行うことにより、ラチェットから生じる通信オーバーヘッドは、セキュリティを損なうことなく削減され得る。
【００６０】
コンピュータおよび通信システム
図９は、本発明の１つの実施形態にしたがって、適応型キーラチェットのための例示的なコンピュータおよび通信システムを図示する。１つの実施形態において、コンピュータおよび通信システム９００は、プロセッサ９０２、メモリ９０４、および、保存デバイス９０６を含む。保存デバイス９０６は、アプリケーション９１０および９１２などの他のアプリケーションと共に、適応型キーラチェットアプリケーション９０８を保存する。動作中、適応型キーラチェットアプリケーション９０８は、保存デバイス９０６からメモリ９０４内へロードされ、その後、プロセッサ９０２により実行される。プログラムを実行しながら、プロセッサ９０２は前述の機能を行う。コンピュータおよび通信システム９００は、タッチスクリーンディスプレイを含み得る選択的なディスプレイ９１４、キーボード９１６、ポインティングデバイス９１８と結合され、さらに、１つ以上のネットワークインタフェースを介してネットワーク９２０と結合され得る。
【００６１】
一部の実施形態において、アプリケーション９０８、９１０、および９１２は、部分的または全体的にハードウェアに実装され、プロセッサ９０２の一部となり得る。さらに、一部の実施形態において、システムは別個のプロセッサおよびメモリを含まなくてよい。代わりに、特有のタスクを行うことに加えて、アプリケーション９０８、９１０、および９１２は、個々または一斉に、汎用または専用の計算エンジンの一部であってよい。
【００６２】
この詳細な説明に記載されるデータ構造およびコードは、典型的に、コンピュータシステムにより使用するためのコードおよび／またはデータを保存し得る任意のデバイスまたは媒体であってよい、コンピュータ可読保存媒体に保存される。コンピュータ可読保存媒体は、揮発性メモリ、不揮発性メモリ、ディスクドライブ、磁気テープ、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタル多用途ディスクまたはデジタルビデオディスク）などの磁気および光保存デバイス、または、現段階で既知であるか、または、今後開発される、コンピュータ可読媒体を保存可能な他の媒体を含むが、それらに限定されない。
【００６３】
詳細な説明の項に記載される方法およびプロセスは、上述したようにコンピュータ可読保存媒体に保存され得る、コードおよび／またはデータとして具現化され得る。コンピュータシステムがコンピュータ可読保存媒体に保存されるコードおよび／またはデータを読み込んで実行する際、コンピュータシステムは、データ構造およびコードとして具現化されコンピュータ可読保存媒体内に保存される方法およびプロセスを行う。
【００６４】
さらに、本明細書に記載される方法およびプロセスは、ハードウェアモジュールまたは装置に含まれ得る。これらのモジュールまたは装置は、特定用途向け集積回路（ＡＳＩＣ）チップ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定のソフトウェアモジュールまたはコードを特定の時間に実行する専用または共有プロセッサ、および／または、現段階で既知であるか、または、今後に開発される、他のプログラマブル論理デバイスを含んでよいが、それらに限定されない。ハードウェアモジュールまたは装置が起動されると、それらに含まれる方法およびプロセスが実行される。
【図１】
0006764753.tif 000002
【図２】
0006764753.tif 000003
【図３Ａ】
0006764753.tif 000004
【図３Ｂ】
0006764753.tif 000005
【図４】
0006764753.tif 000006
【図５】
0006764753.tif 000007
【図６】
0006764753.tif 000008
【図７】
0006764753.tif 000009
【図８】
0006764753.tif 000010
【図９】
0006764753.tif 000011