JP6625211B2 - 部分的に信頼できる第三者機関を通しての鍵交換 - Google Patents

Description

関連出願の相互参照
本出願は、２０１５年１２月１１日出願の「ＫＥＹ ＥＸＣＨＡＮＧＥ ＴＨＲＯＵＧＨ ＰＡＲＴＩＡＬＬＹ ＴＲＵＳＴＥＤ ＴＨＩＲＤ ＰＡＲＴＹ（部分的に信頼できる第三者機関を通しての鍵交換）」と題された米国特許出願第１４／９６７，２１４号（代理人整理番号００９７７４９−６２９ＵＳ０）の全開示の優先権を主張し、それをあらゆる目的のために参照により組み込むものであり、２０１５年１２月１１日出願の「ＳＩＧＮＥＤ ＥＮＶＥＬＯＰＥ ＥＮＣＲＹＰＴＩＯＮ（署名されたエンベロープ暗号化）」と題された米国特許出願第１４／９６７，１４２号（代理人整理番号００９７７４９−６２８ＵＳ０）の全開示をあらゆる目的のために参照により組み込むものである。

コンピューティングリソース及び関連データのセキュリティは、多くの状況で非常に重要である。一例として、コンピューティングデバイスのネットワークは、それらのユーザに強固なサービスのセットを提供するのに利用され得る。ネットワーク内で、第１のコンピュータ、システムまたはユーザは、第２のコンピュータ、システムまたはユーザを信頼し得る−すなわち、コンピュータ、システムまたはユーザには、第１のコンピュータ、システムまたはユーザのデータを生成、読出、更新及び／または削除する能力といった一定のアクセス権が付与され得る。第２のコンピュータ、システムまたはユーザもまた、第１のコンピュータ、システムまたはユーザに関連付けられたデータを格納するものとして信頼され得る。一例として、第１のコンピュータ、システムまたはユーザは、公開鍵を格納し公開鍵の所有権を証明するデジタル証明書に署名する認証局を信頼し得る。反対に、信頼できるコンピュータ、システムまたはユーザのアクセス権または権利を有していない、信頼できない他のコンピュータ、システムまたはユーザが存在し得る。さらに、信頼できるコンピュータ、システムまたはユーザに関連付けられたいくつかのアクセス権または権利を有する部分的に信頼できるコンピュータ、システムまたはユーザが存在し得る。コンピューティングリソースのそうした構成において、リソース及びデータへのアクセスが正しく管理されることを確保するのは、特にそうした構成のサイズ及び複雑性が増すにつれて、試練となり得る。

最新の暗号アルゴリズムは、高レベルのデータセキュリティを提供する。例えば現在の暗号方式は、データへの不正アクセスには実現不可能な時間及び／またはリソースが要されるように、データを保護することができる。しかしながら、そうした高レベルの保護には代償が伴う。一般的に述べると、保護のレベルが高くなると、計算リソースのより高い保全レベルとその支出の増加が必要になる。さらに、保護のレベルが高くなると、例えば、暗号化サービスまたは認証局における１つまたは複数のサブ構成要素の信頼のレベルも高くする必要があり得る。２つ以上の機関の間に暗号保護された通信を確保することは、計算リソースの使用を低減させることまたはネットワークの様々なサブ構成要素に付与される信頼量を制限することが有利となり得るシステムにおいては特に、困難なこととなり得る。

多様な技術を、図面を参照して説明する。

暗号保護された通信セッションが部分的に信頼できる暗号化サービスを用いて確立される環境の図である。 部分的に信頼できる暗号化サービスを用いて楕円曲線ディフィーヘルマン鍵ペアを交換する環境の図である。 部分的に信頼できる暗号化サービスを用いて楕円曲線ディフィーヘルマン鍵ペアを交換する環境の図である。 ２つのクライアントが暗号保護された通信セッションを確立する環境の図である。 一実施形態による、第１のクライアントと第２のクライアントと暗号化サービスの間の通信を例示する図である。 一実施形態による、第１のクライアントと第２のクライアントと暗号化サービスの間の通信を例示する図である。 一実施形態による、暗号保護された通信セッションを確立する実例的なプロセスの図である。 部分的に信頼できるクライアントを用いて暗号保護された通信を容易にする環境の図である。 暗号保護された通信が送信され得る環境の図である。 暗号保護された通信が受信され検証され得る環境の図である。 暗号保護された通信の送信を例示する図である。 暗号保護された通信の受信及び検証を例示する図である。 暗号保護された通信を送信する実例的なプロセスの図である。 暗号保護された通信を受信し検証する実例的なプロセスの図である。 多様な実施形態を実行することができる環境の図である。

本文書に記載された技術は、暗号保護された通信を容易にするために、部分的に信頼できるコンピュータシステムを用いることを含む。いくつかの例では、第１のコンピュータシステムは、部分的に信頼できる暗号化サービスを用いて第２のコンピュータシステムと通信する。部分的に信頼できるシステム（例えば暗号化サービス）は、いくつかの点では信頼できるが他の点では信頼できないコンピュータシステムであってもよい。例えば、部分的に信頼できる暗号化サービスは、デジタル署名を生成しデジタル署名の信頼性を検証するのに信頼できるものであってもよいが、第１のコンピュータシステムと第２のコンピュータシステムの間の暗号保護された通信にアクセスするのに用いることができるデジタル鍵へのアクセスにおいては信頼できないものであってもよい。そうしたシステムでは、部分的に信頼できる暗号化サービスは、第１のコンピュータシステムと第２のコンピュータシステムの間に暗号保護された通信セッションを確立するハンドシェイクプロセスの間、少なくとも部分的に用いられる場合があり、確立された暗号保護された通信セッションにアクセスできない場合がある。例えば、部分的にセキュアな暗号化サービスを少なくとも部分的に用いて、クライアントコンピュータとサーバの間に暗号化サービスによって復号化することができないトランスポート層セキュリティ（ＴＬＳ）セッションを確立してもよい。

別の例では、第１のコンピュータシステムは、暗号化データ鍵で暗号化された暗号保護された通信を第２のコンピュータシステムに送信する。該データ鍵は、第２のコンピュータシステムによってアクセス可能なものである。暗号保護された通信に含まれるデータは保護され得、第２のコンピュータシステムはデータを読み出し得るが、データを、第三者機関が検証不可能となるように修正することはできないようにする。すなわち、暗号保護された通信によるデータの任意の修正は、第三者機関が検出することができる。そうしたシステムでは、第１のコンピュータシステムは、暗号保護された通信を、信頼できない「中間者」コンピュータシステムを介して第２のコンピュータシステムに提供し得、第２のコンピュータシステムは、メッセージが「中間者」コンピュータシステムによって修正されたかどうかを検証し得る。

一例として、２つのコンピュータシステムは暗号保護された通信セッションを確立し、ここでは、部分的に信頼できる第三者機関を利用して２つのコンピュータシステム間に信頼できる関係が確立されるが、部分的に信頼できる第三者機関は暗号保護された通信の一機関としては信頼できないものである。例えば、暗号化サービスは、クライアントとサーバの間にＴＬＳセッションを確立するのに利用される部分的に信頼できる第三者機関として機能し得るが、暗号化サービスは、クライアントとサーバの間の暗号化された通信の内容を読み出すことは可能ではない。本例を続けると、暗号化サービスは、デジタル署名を生成するのにかつ真正なものであると称するデジタル署名が実際に真正なものであるかどうかを検証するのに信頼され得る。しかしながら、暗号化サービスは、クライアントとサーバの間の暗号保護された通信（例えばＴＬＳセッション）で用いられる暗号化秘密鍵を格納しそれにアクセスするのに信頼できない場合がある。暗号化サービスがいくつかの点（例えばデジタル署名を生成し検証する）で信頼できる場合があり、他の点（例えば秘密鍵を格納する）で信頼できない場合がある理由には様々なものが存在し得る−クライアントとサーバの間の通信が特に機密性（例えば重要なビジネス、政府かつ／または軍事のデータ）のあるものであり得る、暗号化サービスが、あらゆる暗号化サービスをサポート可能ではないハードウェア構成を有する場合がある（例えば暗号化サービスは、セッションに十分な長さの暗号化鍵をサポートしない場合がある）、等といったことである。

一例では、２つのクライアントは、部分的に信頼できる暗号化サービスを用いて、鍵交換を行い得る。第１のクライアントは、第１の楕円曲線ディフィーヘルマン（ＥＣＤＨ）鍵ペア、ｄ_Ａ及びＱ_Ａを生成し得、第１のクライアントの識別及び公開鍵Ｑ_Ａを含むメッセージを生成し得る。第１のクライアントの識別は、例えばユーザＩＤ、ＧＵＩＤ、マシンＩＤ、メディアアクセス制御アドレス（ＭＡＣアドレス）などとして符号化され得る。さらに、第１のクライアントを識別するために動的ＩＰアドレスなどの動的識別子が用いられ得る。第１のクライアントは、第１のクライアントの識別及び公開鍵を含むメッセージを、デジタル署名を要求して暗号化サービスに提供し得る。次いで、暗号化サービスは、第１のクライアントに関連付けられた暗号化鍵を用いてメッセージにデジタル署名し得、デジタル署名されたメッセージを第１のクライアントに戻して提供し得る。暗号化サービスは、暗号化サービスの各クライアントに固有の暗号化鍵が割り当てた暗号化鍵の格納部を有してもよい。暗号化サービスは、デジタル署名されたメッセージをコピーしてもよい。デジタル署名されたメッセージを受信すると、第１のクライアントは、デジタル署名されたメッセージを第２のクライアントに提供し得る。このことは、ハンドシェイクプロトコルの一部として起こり得る。第２のクライアントは、デジタル署名されたメッセージを受信すると、それを暗号化サービスに認証要求とともに提供することによって、デジタル署名されたメッセージの信頼性を検証し得る。場合によっては、デジタル署名は真正なものではない−すなわち、メッセージ及び／または署名は修正されたと判定され得る。これは、メッセージに対する意図的ではないまたは意図的な修正の結果であり得る。意図的ではない修正は、無線信号損失、パケット損失、データ破損、メモリ破損などから生じ得る。意図的な修正は、メッセージを取得（例えば送信中にルータで）しメッセージを修正する悪意のある機関から生じ得る。メッセージが真正なものではないと判定された場合、第２のクライアントは第１のメッセージを拒絶し得、ハンドシェイクは失敗し得る。

しかしながら、先行段落におけるメッセージが真正なものであると判定された場合、第２のクライアントは、第１のクライアントの識別を抽出し、公開鍵Ｑ_Ａを第１のクライアントに関連付け得る。次いで、第２のクライアントは、第２のＥＣＤＨ鍵ペアｄ_Ｂ及びＱ_Ｂを生成し得、第２のクライアントの識別及び公開鍵Ｑ_Ｂを含む第２のメッセージを生成し得る。この第２のメッセージは、第１のメッセージと同様にデジタル署名され、送信され、検証され得る。第２のメッセージを受信しその信頼性を検証すると、第１のクライアントは、公開鍵Ｑ_Ｂを第２のクライアントに関連付け得る。公開鍵を交換した後で、第１のクライアント及び第２のクライアントは共有秘密鍵を計算することができる−第１のクライアントはｄ_ＡＱ_Ｂの楕円曲線点乗算を計算し、第２のクライアントはｄ_ＢＱ_Ａの楕円曲線点乗算を計算する。楕円曲線ディフィーヘルマン鍵交換では、２つの値は等しく、鍵として、すなわち、ＴＬＳセッションなどの暗号保護された通信セッションを確立するのに用いられ得る秘密鍵を生成するために用いられ得る。確立されると、第１のクライアントと第２のクライアントは、暗号化サービスは共有秘密鍵を知らず、したがってＴＬＳセッションで用いられる秘密鍵を知らないという保証のもと、暗号保護された通信セッションを介して通信し得る。このことにより、暗号化サービスは暗号保護された通信セッションに関与することができないので、セキュリティ保証は高められる。クライアントには、暗号化サービスは共有秘密鍵を計算して傍受することができない、すなわち上述のように生成された暗号保護された通信セッションに「中間者」攻撃を行うことができないことが保証される。

いくつかの実施形態では、第１のコンピュータシステムはデータを第２のコンピュータシステムにエンベロープ暗号化を用いて送り得る。そうしたシステムでは、第１のコンピュータシステム及び第２のコンピュータシステムはどちらも暗号化データ鍵にアクセスできてもよい。第１のコンピュータシステムはデータ鍵を用いてメッセージを暗号化し得、該メッセージはその後第２のコンピュータシステムによってデータ鍵を用いて復号化され得る。しかしながら、いくつかの実施形態では、第２のコンピュータシステムがメッセージを修正したかどうかを検出することが望ましい場合があり、さらに、検出なしで第２のコンピュータシステムがメッセージを修正することを防ぐことが望ましい場合がある。この例では、暗号化サービスは、上記の例における動作とは異なる動作を行うことにおいて信頼され得る−この例では、暗号化サービスは、暗号化データ鍵を生成し、マスター鍵を格納し、マスター鍵を用いて暗号化動作及び復号化動作を行うのに信頼され得ることに留意されるべきである。

前段の例を続けると、第１のクライアントは、暗号化データ鍵にアクセスできる第２のコンピュータシステムがデータを、修正を検出可能にしないで修正することができないように、暗号化データ鍵を用いて暗号化されるデータまたはメッセージを有してもよい。クライアントはまず、暗号化サービスに暗号化データ鍵を生成することを要求し得る。次いで、クライアントは、暗号化データ鍵を用いてメッセージを暗号化し得る。次いで、クライアントは、ＥＣＤＨ鍵ペアｄ_Ａ及びＱ_Ａを生成し得る。暗号化されたメッセージのデジタル証明書は、ｄ_Ａを用いて生成され得、Ｑ_Ａを用いて暗号学的に検証可能である。次いで、クライアントは、暗号化サービスに、以下の入力：暗号化される平文としての暗号化データ鍵、及びＥＣＤＨ公開鍵Ｑ_Ａを含む追加認証データ（ＡＡＤ）、とともにマスター鍵を用いて認証付き暗号化を行うよう要求し得る。暗号化サービスは、認証付き暗号化を行う要求に応えて、マスター鍵のもとで暗号化アルゴリズムを用いてデータ鍵の暗号文及び暗号学的ハッシュ関数を用いてメッセージ認証（ＭＡＣ）タグを生成する。次いで、デジタル署名され暗号化されたメッセージ、データ鍵の暗号文及びＭＡＣタグは１つまたは複数の受信者に送信される。

受信者がデジタル署名され暗号化されたメッセージ、データ鍵の暗号文及びＭＡＣタグを受信すると、受信者は、メッセージが第１のクライアント以外の機関によって修正されたかどうかを検証することができる。受信者は、まず、ＭＡＣタグからＡＡＤを抽出し、暗号化サービスに上記の認証付き暗号化に対応する復号化を行うことを要求し得る。復号化は、入力として、暗号文及びＡＡＤを受け取り得る。暗号化サービスは、ＡＡＤが与えられた暗号文入力と一致しない場合、エラーを戻し得る。復号化動作に成功した場合、平文出力、及び暗号文入力を復号化するのに用いられる暗号化鍵に対応する鍵識別子が提供され得る。鍵識別子が、暗号化動作に用いられるマスター鍵に対応しない場合、エラー、またはメッセージが修正されているという他の表示が戻され得る。しかしながら、鍵識別子がマスター鍵と一致する場合、暗号化されたデータ鍵のデジタル署名は、公開鍵Ｑ_Ａを用いて検証され得る。デジタル署名の検証後、データ鍵を含む平文出力を用いて、暗号文メッセージを復号化し得る。復号化されたメッセージは、署名の検証に用いられる公開鍵の結びつきにより、第１のクライアントによって送られたことが保証される。

前述のかつ以下の説明では多様な技術が説明される。説明の目的のために、具体的な構成及び詳細が、技術の可能な実装方法の完全な理解を提供するために記載される。しかしながら、以下で説明される技術が具体的な詳細なしに様々な構成で実施され得ることも明らかとなるだろう。さらに、周知の特徴は、説明されている技術を不明瞭にしないために省略または簡略化され得る。

図１は、本開示の様々な技術が利用され得る状況を例示する略図１００を示す。この特定の例では、略図１００は、暗号保護された通信セッション１１４を介して通信する第１のクライアント「クライアントＡ」１０２及び第２のクライアント「クライアントＢ」１０４を示す。暗号化サービス１０６は、クライアント１０４及び１０６によって、様々な暗号化動作を行うためにかつ暗号化鍵を格納しそれにアクセスするために利用され得る。メッセージ１０８は認証動作を行うために暗号化サービスに提供（例えばネットワークを介して送信）され得、デジタル署名１１０は検証動作を行うために暗号化サービス１０６に提供され得る。暗号化サービス１０６は、暗号保護された通信セッション１１４にアクセス１１２する十分な情報を有さなくてもよい。

いくつかの例では、第１のクライアント１０２及び／または第２のクライアント１０４は、様々な種類のコンピューティングエンティティであり得る。いくつかの実施形態では、クライアント１０２及び１０４は、ネットワーク（例えばローカルエリアネットワーク）上の各コンピュータシステムであり得るが、インターネットを介して接続された異なるネットワーク上にも存在し得る。クライアント１０２及び１０４の一方または両方は、コンピュータサーバ、仮想マシンのインスタンス及び／または他のコンピューティングエンティティでもあり得る。

暗号化サービス１０６は、複数の鍵格納部のうちの暗号化鍵へのアクセス（例えば、暗号化鍵を生成し提供することによって、または暗号化鍵を生成し提供するように動作可能である他のシステムを参照することによって）及びどのように暗号化鍵が鍵を要求するクライアントによって用いられるべきであるかのセキュリティ設定を提供し得る。いくつかの実施形態では、鍵格納部は、暗号化鍵を格納可能であるハードウェアセキュリティモジュール（ＨＳＭ）によって実装され得る。鍵格納部は、暗号化サービス内に含まれる構成要素であってもよく、クライアント内に含まれる構成要素であってもよく、遠隔位置にあり暗号化サービスによって提供されるインタフェースを介してアクセス可能である構成要素であってもよく、それらの任意の組み合わせであってもよい。

いくつかの実施形態では、暗号化サービスは、ＡＰＩを介して、ジョブを介して、論理タスクとして、及び他の種類のルーティンとしてデータを暗号化するのに用いられ得る。一例として、暗号化（）ＡＰＩをサポートする暗号化サービスは、入力パラメータとして、暗号化するデータ、データの暗号化に用いられ得る暗号化鍵を固有識別する鍵識別子、暗号化されるデータを記述しているラベリングされたメタデータの暗号化コンテキスト、及び追加認証データ（ＡＡＤ）のための任意選択的なパラメータを受信することができる。暗号化サービスは、ＡＰＩ要求を受信し、鍵識別子から暗号化鍵を取得し、セキュリティポリシー、暗号化コンテキスト及びクライアントの暗号化能力に適合する複数の暗号化構成からある暗号化構成（例えば暗号化アルゴリズム及びブロックサイズ）を選択し得る。提供されたデータは、クライアントの暗号化能力にしたがって、鍵識別子の使用に少なくとも部分的によって取得された暗号化鍵を用いて、選択された暗号化構成にしたがって暗号化され得る。暗号化されたデータは、暗号化されたデータが暗号化構成及びデータを暗号化するのに用いられる暗号化鍵で復号化可能となるように利用可能とされ得る。この鍵は、クライアントのマスター鍵と称され得る。

いくつかの実施形態では、暗号化サービスは、暗号化サービスによって暗号化されるデータが特定の形式に準拠することをチェックするように構成され得る。例えば、暗号化サービスは、暗号化される任意のデータが８キロバイト（ＫＢ）より小さいサイズでなくてはならいことをチェックするようにプログラミングされ得、それによりクライアントに、８ＫＢよりも大きいデータは自ら暗号化させる。この制限は、例えば、マルチクライアント環境において複数のクライアントに対する暗号化サービスの拡張性及び性能を向上させることの検討に少なくとも部分的に基づくものであり得る。いくつかの実施形態では、暗号化サービスは、所要の限度を超えているデータを暗号化する要求を受信すると失敗を戻し得る。

暗号化されるデータが、暗号化サービスによって課されるサイズの限度より大きい実施形態では、または他の状況では、クライアントは、データ鍵に対するアプリケーションプログラミングインタフェース要求を暗号化サービスに送信し得る。要求は、暗号化サービスによって管理される暗号化鍵（管理鍵）の鍵識別子を指定し得る。暗号化サービスは、データ鍵を生成し、またはそれ以外の方法で取得し、データ鍵を、管理鍵を用いて暗号化し得る。暗号化は、上述したような暗号化構成にしたがうものであってもよく、一般には、管理鍵に関連付けられたポリシーにしたがうものであってもよい。暗号化サービスは、データ鍵及び暗号化されたデータ鍵を含む、要求に対する応答を提供し得る。次いで、クライアントはデータ鍵を用いてデータを暗号化し、データ鍵の任意のメモリ内コピーを削除し、暗号化されたデータ鍵を暗号化されたデータに関連させて（例えば、暗号化されたデータと一緒に、または、暗号化されたデータ鍵を暗号化されたデータに関連付けるデータベースに）格納し得る。データは、暗号化されたデータ鍵を復号化する要求を暗号化サービスに送信（鍵識別子を指定）することによって暗号化され得る。暗号化サービスは、要求に応答して、管理鍵を選択し、暗号化されたデータ鍵を復号化し、復号化されたデータ鍵を提供することによって、クライアントがデータ鍵を用いてデータを復号化することを可能にし得る。

いくつかの実施形態では、暗号化サービスは、追加の機能性を提供し得る。例えば、暗号化サービスは、例えばＡＰＩを介して、ジョブを介して、論理タスクとして、他の種類のルーティンとしてメッセージまたはデータを認証するように構成され得る。第１のクライアント１０２などのクライアントは、暗号化サービスに、認証されるメッセージ１０８を提供し得る。それに応じて、暗号化サービスは、入力メッセージまたはデータ（例えば図１に示すメッセージ１０８）及び暗号化鍵を入力として受け取る暗号学的ハッシュ関数を用いてメッセージ認証コード（ＭＡＣ）タグを生成し得る。いくつかの実施形態では、暗号学的ハッシュ関数で用いられる暗号化鍵は、呼び出しクライアントの識別に結びつけられ得（すなわち、暗号化鍵は、呼び出しクライアントの識別に基づいて選択される）、他の実施形態では、暗号化鍵に対する鍵識別子はクライアントによって提供され得る。暗号学的ハッシュ関数は、出力としてＭＡＣタグを生成し得、暗号化サービスは、メッセージまたはデータを認証する要求に応えてＭＡＣタグを提供し得る。整合性及び信頼性の保証を提供する他の方法が用いられ得ることに留意すべきである。整合性とは、メッセージまたはデータが悪意を持ってでも誤ってでも修正されないことの保証を指し得、信頼性とは、メッセージまたはデータの書き手の保証を指し得る。例えば、暗号化サービスは、デジタル署名を生成することによって、メッセージまたはデータを認証し得る。

いくつかの実施形態では、暗号化サービスは、例えばＡＰＩを介して、ジョブを介して、論理タスクとして、他の種類のルーティンとして追加の機能性を提供し得る。例えば、暗号化サービスは、ＭＡＣタグ、デジタル署名などを検証するように構成され得る。第２のクライアント１０４などのクライアントは、暗号化サービスに、検証されるＭＡＣタグ１１０を提供し得る。それに応じて、暗号化サービスは、計算されたＭＡＣタグを、暗号化サービスがメッセージ及び暗号化鍵から生成するＭＡＣタグと比較することによって、ＭＡＣタグの信頼性を検証し得る。計算されたＭＡＣタグと提供されたＭＡＣタグが一致する場合、検証はメッセージが真正なものであることを示すだろう。

様々な実施形態では、暗号保護された通信１１４は、２つ以上の機関の間で、他の機関によるデータのアクセス、読み出しまたは修正を防ぐようにデータを送信する目的のために用いられる。暗号保護された通信はまた、ソース由来であると称する通信が実際に称されたソースからのものであることを保証し得、いくつかの実施形態では、受信者によって暗号学的に検証可能であり得る。暗号保護された通信とは、例えば、２つ以上のエンティティ間でネットワークを横断するデータの整合性を確保しかつ／またはデータがネットワークを横断するときのデータの機密性を確保するために用いられることを指し得る。

例えば、図１に示された暗号保護された通信１１４は、第１のクライアント１０２及び第２のクライアント１０４が共有秘密鍵を利用して暗号化されたセッション全体に通信の機密性を確保する暗号化されたセッションであってもよい。暗号化されたセッションの一例は、ＲＦＣ５２４６に記載されるようなトランスポートセキュリティ層（ＴＬＳ）セッションであり、これは本明細書によって参照により組み込まれる。しかしながら、暗号保護された通信は、暗号化される必要はない−例えば、いくつかの実施形態では、暗号保護された通信１１４は、整合性の保証は提供するが機密性の保証は提供しなくてもよく、第三者機関が暗号保護された通信の内容を読み出すことは可能とするが、暗号保護された通信を通信の有効性を損なうことなく修正することは不可能とする。いくつかの実施形態では、暗号保護された通信を確立するために、ＭＡＣタグ、デジタル署名などが利用され得る。

様々な実施形態では、暗号保護された通信セッションは、リソースにアクセスする目的のために用いられる。暗号保護された通信セッションは、例えば、クライアントからサーバにまたはクライアントからサーバにというように１つのエンティティから別のエンティティにデータを転送するために用いられ得る。暗号保護された通信セッションは、エンティティ間でネットワークを横断するデータの整合性を確保するために、かつ／または、データがネットワークを横断するときのデータの機密性を確保するために用いられ得る。

いくつかの実施形態では、暗号化サービスは、暗号保護された通信にアクセス１１２できなくてもよい。暗号保護された通信へのアクセスとは、例えばセッションでメッセージを送受信することによって通信セッションに関与する能力を有する暗号化サービスを指し得る。いくつかの実施形態では、暗号化サービスは、暗号保護された通信で指定されたプロトコルを介して暗号化されたデータを復号化不可能であってもよい（例えば、暗号化サービスは、クライアント間のＴＬＳセッションで送られるデータを復号化不可能である）。暗号化サービスは、コンピューティング環境でいくつかの暗号化鍵にアクセスでき得るが（例えばクライアントマスター鍵）、暗号保護された通信にアクセスするのに必要な他の情報にアクセスできない場合がある（例えば、第１のクライアント１０２と第２のクライアント１０４の間の共有秘密鍵は暗号化サービスに秘匿され得る）。いくつかの実施形態では、アクセス１１２とは、通信を修正するという暗号化サービスの能力を指し得る。例えば通信は、暗号化サービスがアクセスできない秘密鍵を用いて生成されたデジタル署名を含むので、例えば、暗号化サービスは、クライアント１０２とクライアント１０４の間の通信を読み出す能力を有し得るが、通信を修正することは不可能であり得る。

図２は、部分的に信頼できる暗号化サービス２０６を用いてＥＣＤＨ鍵ペアを交換する例示的な環境２００を示す。第１のクライアント２０２は、秘密鍵ｄ_Ａ及び公開鍵Ｑ_Ａを含むＥＣＤＨ鍵ペア２０８を有し得る。ＥＣＤＨ鍵ペアは図２に例示された実施形態に示されるが、この開示にしたがって他の種類の非対称鍵ペアも利用され得ることに留意されるべきである。いくつかの実施形態では、クライアント２０２は、鍵交換プロセス中にＥＣＤＨ鍵ペアを生成し得るが、他の実施形態では、鍵ペアは、予め生成され得、または、例えば図２に示さないハードウェアセキュリティモジュール（ＨＳＭ）などの信頼できるソースによってクライアント２０２に提供され得る。図２に示すクライアント２０２及び２０４は、例えば、図１に関連して上述したクライアントと同種であってもよい。

いくつかの実施形態では、暗号化サービス２０６は、認証動作及び検証動作を行うのに信頼され得るが、クライアント２０２と２０４の間の暗号保護された通信セッションにアクセスするなどの他の動作を行うのに十分に信頼されなくてもよい。いくつかの実施形態では、暗号保護された通信セッションへのアクセスを暗号化サービスに提供することは構造的に問題があり得る。いくつかの実施形態では、暗号化サービスは、クライアント２０２及び２０４以外の機関によって潜在的にアクセス可能であり得る。いくつかの実施形態では、暗号化サービスに共有秘密鍵を提供しないことには利点が存在し得る−例えば、暗号化サービスは、そうした状況下では、多数のクライアントが共有秘密鍵を有する暗号化サービスを信頼した場合、悪意ある攻撃の識別可能な標的となり得る。

いくつかの実施形態では、暗号化サービス２０６は、暗号化鍵のセットを、例えば図２に示さないハードウェアセキュリティモジュール（ＨＳＭ）に格納し得る。暗号化サービスは、各クライアントマスター鍵が特定のクライアントに関連付けられ所有されるクライアントマスター鍵のセットを有し得る。クライアントマスター鍵は、暗号化サービスが、例えば、なりすまし攻撃を防ぐために登録者にパスワードの入力、セキュリティトークンの提供または登録者の識別の他の証明の提供を要することによって、登録者との間に信頼関係を確立する登録プロセスの一部としてそれらのそれぞれのクライアントに関連付けられ得る。

暗号化サービス２０６によって、呼び出し元はいくつかの暗号化動作を行うことが可能になり得る。特定のクライアントは、暗号化サービスを呼び出して各種暗号化動作を行い得、いくつかの実施形態では、他のクライアントがその暗号化鍵を用いて、暗号化サービスによってサポートされる暗号化動作の全てまたは一部を行うことを可能にし得る。例えば、特定のクライアントは、そのクライアントマスター鍵を用いて、特定のメッセージがそのクライアントサービスからもたらされたものであることを証明するデジタル署名を生成し得る。前の例に関して、他のクライアントは、暗号化サービスにデジタル証明書が有効かどうかを検証することを要求し得る。いくつかの実施形態では、暗号化サービスはまた、クライアントによって、データを暗号化して暗号文出力を生成すること及びデータを復号化して平文出力（例えば複数層の暗号化がデータに適用されるとき、まだ難読化されている場合がある）を生成することにも使用可能であってもよい。これらの動作は、暗号化サービスによって安全に格納されているクライアントマスター鍵を用いて行われ得る。

暗号化サービスはまた、認証付き暗号化動作も提供し得る。いくつかの実施形態では、暗号化サービスは、暗号化（鍵ＩＤ、データ、ＡＡＤ）要求、ＡＰＩまたはコマンドをサポートし得る。鍵ＩＤは、特定のクライアントに関連付けられ得、暗号化サービスによって特定のクライアントマスター鍵に内部的に関連付けられ得る。いくつかの実施形態では、鍵ＩＤは任意選択的な入力であってもよく、または、暗黙的であってもよい（例えば呼び出し元の識別を用いて鍵ＩＤを判定し得る）。追加認証データ（ＡＡＤ）は、様々な目的のために使用されてもよく、必ずしも暗号化されていないが例えば電子署名、メッセージ認証コード、または、一般にＡＡＤとともに含まれる鍵付きハッシュ値によって認証されているデータであってもよい。いくつかの実施形態では、暗号文は、ＡＡＤの少なくとも一部を含んで生成される。いくつかの他の実施形態では、ＡＡＤは、復号化の際、別に提供される。いくつかの他の実施形態では、ＡＡＤは、要求、及び／またはメタデータが通過するときにのみ復号化が成功するような他のメタデータに少なくとも部分的に基づいて、復号化時に生成される。いくつかの実施形態では、ポリシーは、暗号化動作を特定のＡＡＤに対して行うことができるかどうかを制限し得る。暗号化（鍵ＩＤ、データ、ＡＡＤ）要求の処理は、暗号化サービスによって実行されるプログラミング論理及び／またはポリシーによって、ＡＡＤが特定の値を含むこと及びＡＡＤが真正なものであること（例えば元の送信から修正されていない）の両方を必要とし得る。同様に、復号化（鍵ＩＤ、暗号文、ＡＡＤ、タグ）要求は、暗号化サービスに、鍵ＩＤによって識別される鍵を用いて、指定された暗号文を復号化させるのに用いられ得る。上述のような復号化（鍵ＩＤ、暗号文、ＡＡＤ、タグ）要求のＡＡＤは、入力タグと比較される認証タグを生成するのに用いられ得る。例えば、復号化（鍵ＩＤ、暗号文、ＡＡＤ、タグ）の処理は、暗号化サービスによって実行されるプログラミング論理及び／またはポリシーによって、ＡＡＤが特定の値を含むこと及びＡＡＤが真正なものであること（例えば元の送信から修正されていない）の両方を必要とし得る。いくつかの実施形態では、復号化（）要求は、生成された認証タグが入力タグと一致しない場合失敗となるだろう。

いくつかの実施形態では、暗号化（）ＡＰＩは、暗号文に関連するメタデータを生成する。例えば、暗号化（）ＡＰＩは暗号文を生成し、それを、暗号化動作に用いられる鍵ＩＤを含むメタデータに追加し得る。そうした実施形態では、復号化（）ＡＰＩは、入力として鍵ＩＤを必要としなくてもよい（すなわち、復号化（暗号文、ＡＡＤ、タグ）要求が、復号化（鍵ＩＤ、暗号文、ＡＡＤ、タグ）要求に置換し得るまたは代替となり得る）。いくつかの実施形態では、暗号化サービスは、暗号化動作中に暗号文及びメタデータ全体に認証タグを生成し、正しい暗号化鍵が復号化に用いられることを確保するために復号化中に認証タグを検証し得る。

いくつかの実施形態では、ＥＣＤＨ鍵ペア２０８は、クライアント２０２によって生成される。ＥＣＤＨ鍵ペアは、秘密鍵ｄ_Ａ及び公開鍵Ｑ_Ａを含み得る。しかしながら、他の種類の非対称鍵ペアが代わりに生成され得、秘密鍵は他の機関に秘匿され得る。ＥＣＤＨ鍵ペアは、例えばハンドシェイクプロトコルの一部として生成され得、または、予め生成され得る（例えば、１つまたは複数のＥＣＤＨ鍵ペアはある時点で生成され、その後暗号保護された通信セッションが形成されるときに使用するために、配布される）。いくつかの実施形態では、ＥＣＤＨ鍵ペアは、一度のセッションのみで使用可能でありその後は無効となる一時的な暗号化鍵であってもよい。いくつかの実施形態では、ＥＣＤＨ鍵ペアは、単一のメッセージにのみ使用可能であってもよく、その後は無効となる（第２のメッセージに対して第２のＥＣＤＨ鍵ペアを必要とする）。

メッセージ２１０は、第１のクライアント２０２によって生成され得、少なくとも送信者の識別及び公開鍵を含む。メッセージを用いて、公開鍵が送信者に関連付けられていること及び送信者が対応する秘密鍵の所有権を有していることを証明することによって、送信者の識別子を公開鍵に結びつかせ得る。この状況の結びつきとは、暗号化公開鍵とクライアントまたは対応する暗号化秘密鍵にアクセスできるエンティティの関連付けを指し得る。結びつきは暗黙的であってもよく（例えば、プロトコルは、公開鍵及びクライアントＩＤを含むメッセージまたはメッセージフォーマットが鍵をクライアントに結びつけることを定義する）、または、メッセージ内で明示的に記述されてもよい。いくつかの実施形態では、暗号化公開鍵を送信者情報に結びつけるメッセージはデジタル署名され得、または、ＭＡＣタグがその結びつき全体に生成され得る。

第１のクライアントの識別は、例えばユーザＩＤ、ＧＵＩＤ、マシンＩＤ、メディアアクセス制御アドレス（ＭＡＣアドレス）などとして符号化され得る。さらに、第１のクライアントを識別するために動的ＩＰアドレスなどの動的識別子が用いられ得る。メッセージ２１０は暗号保護された通信セッションを確立するハンドシェイクプロトコルの一部として暗号化サービスに提供され得る。メッセージ２１０は、メッセージを認証する要求とともに暗号化サービスに提供され得る。認証は、暗号化サービスによって、第１のクライアント２０２に関連付けられたクライアントマスター鍵を用いて行われ得る。クライアントは、鍵識別子を要求の一部として暗号化サービスに提供し得る。いくつかの実施形態では、暗号化サービスは、セキュリティチェック及びパラメータチェックを行って、例えばクライアントがデータを認証するまたはより具体的にはデータを具体的な鍵識別子のもとで認証する十分な権利を有することが要求においてチェックされていることを確保し得る。いくつかの実施形態では、メッセージはまた、認証動作で用いられる鍵に対応する鍵識別子、対応する検証動作で用いられ得る鍵に対応する鍵識別子、またはその両方も含み得る。

いくつかの実施形態では、認証要求は、暗号化サービスによって、暗号学的ハッシュ関数を用いてメッセージの内容全体にＭＡＣタグを生成することによって処理される。ＭＡＣタグ２１２は、暗号化サービスによって第１のクライアント２０２に例えば応答の一部として提供され得る。ＭＡＣタグ２１２は、同期的にまたは非同期的に提供され得る。いくつかの実施形態では、ＭＡＣタグではなくデジタル署名が、第１のクライアント２０２に関連付けられた暗号化秘密鍵を用いて生成され得る。そうした実施形態では、対応する暗号化公開鍵を用いて、デジタル署名の信頼性を検証し得る。公開鍵は、いくつかの実施形態では、やはり暗号化サービスに格納され得るが、他の実施形態では、例えば認証局（図２に示さず）といった別のエンティティを用いて格納され得る。ＭＡＣタグならびに送信クライアント情報及び公開鍵Ｑ_Ａを含むメッセージは、第２のクライアント２０４に提供され得る。いくつかの実施形態では、第１のクライアント２０２は、前述のデータを、例えばネットワーク接続を介して直接第２のクライアント２０４に送信し得る。他の実施形態では、第１のクライアント２０２は、前述のデータを、例えば第２のクライアント２０４がそこから取得し得る所定の場所に前述の情報を格納することによって、第２のクライアント２０４に間接的に送信し得る。

いくつかの実施形態では、第２のクライアントは、送信者識別情報及び公開鍵Ｑ_Ａを含むメッセージならびにメッセージの信頼性を証明するＭＡＣタグを受信し得る。第２のクライアントは、メッセージ及びＭＡＣタグを、メッセージの信頼性を検証する要求とともに暗号化サービス２０６に提供し得る。いくつかの実施形態では、第２のクライアント２０４は、検証動作で用いられる暗号化鍵に対応する鍵識別子も提供し得る。暗号化サービス２０６は、いくつかの実施形態では、ＭＡＣタグ付きのメッセージが真正なものであることを判定し、情報が有効であるという表示２１４を提供し得る。いくつかの実施形態では、検証動作が失敗するとすなわちメッセージは真正なものではないと判定すると、失敗の表示が、成功の表示に加えて、または、その代わりに提供され得る。メッセージが有効であると判定すると（例えば情報が有効であるという表示２１４を受信すると）、第２のクライアント２０４は、メッセージに含まれる公開鍵Ｑ_Ａを取得し得る。公開鍵は短期記憶に保持、アーカイブ、キャッシュまたは格納され得る。

代替の実施形態では、環境２００に示される鍵交換は、暗号化及び復号化を用いて行われ得る。例えば、第１のクライアント２０２は、送信者識別情報及び公開鍵Ｑ_Ａを有するメッセージ２１０を、暗号化サービスに、メッセージ２１０を暗号化する要求とともに提供し得る。暗号化サービスは、クライアントマスター鍵を用いてメッセージを暗号化し、暗号化されたメッセージを第１のクライアント２０２に戻し、第１のクライアント２０２は次いで、暗号化されたメッセージを第２のクライアント２０４に提供し得る。第２のクライアントは、暗号化されたメッセージを、復号化要求の一部として暗号化サービスに提供し得、暗号化サービスは、メッセージを復号化し得、要求を満たす一部として、第２のクライアント２０４に応えてメッセージを復号化するのに用いられるクライアントマスター鍵に対応する鍵識別子を提供し得る。応答を受信すると、第２のクライアント２０４は、メッセージを復号化するのに用いられる鍵識別子が第１のクライアント２０２に対応することを確認し得る。第１のクライアント２０２がそのカスタマーマスター鍵を用いて暗号化のために他の機関へのアクセスを許可しない限り、第２のクライアント２０４には、暗号化されたメッセージに含まれる公開鍵が第１のクライアントからのものであり第１のクライアントとの間の暗号保護された通信に使用可能であることが保証され得る。そうした実施形態では、第２のクライアント２０４は、認証されていない公開鍵を扱う必要はなくてもよく、一方、図２にしたがったいくつかの実施形態のもとでは、第２のクライアント２０４は、情報が有効であるという表示２１４を受信する前に、公開鍵がまだ認証されていないという理由で使用可能ではないメッセージから平文の公開鍵Ｑ_Ａにアクセスできてもよい。

いくつかの実施形態では、暗号化されたメッセージは、公開鍵Ｑ_Ａを含むことに加えて、第１のクライアント２０２が第２のクライアント２０４に暗号保護された通信セッションを確立する前にその承認を求めるノンスも含み得る。例えば、ハンドシェイクプロトコルの一部として、第１のクライアント２０２は、第２のクライアント２０４からの公開鍵Ｑ_Ｂ（例えば図３に関連して）の受け入れを、それがノンスを伴わない場合に拒絶し得る。応答がノンスを含むことを求めることは、いくつかの実施形態では、リプレイ攻撃を防ぐことによって追加のセキュリティまたは第１のクライアント２０２が第２のクライアント２０４から受信するメッセージの鮮度保証を提供し得る。いくつかの実施形態では、ノンスとしてタイムスタンプが挙げられ得る。

図３は、部分的に信頼できる暗号化サービス３０６を用いてＥＣＤＨ鍵ペアを交換する例示的な環境３００を示す。第１のクライアント３０２、第２のクライアント３０４及び暗号化サービス３０６は、図１及び２にしたがって上述されたものと同種であってもよい。ＥＣＤＨ鍵ペア３０８は、秘密鍵ｄ_Ａ及び公開鍵Ｑ_Ａを含み得、秘密鍵ｄ_Ａは環境において他の構成要素に秘匿されている。ＥＣＤＨ鍵ペア３０８は、第１のクライアント３０２によってハンドシェイクプロトコルの一部として生成され得る。第２のクライアント３０４は、公開鍵Ｑ_Ａ３１０を有し得る。さらに、第２のクライアント３０４は、秘密鍵ｄ_Ｂ及び公開鍵Ｑ_Ｂを含む第２のＥＣＤＨ鍵ペア３１２を有し得る。第２のクライアントの公開鍵Ｑ_Ｂ３２０は、第１のクライアント３０２に、図２に記載された鍵交換と同様にして提供され得る。第２のクライアントの識別情報及び公開鍵Ｑ_Ｂを有するメッセージ３１４は暗号化サービス３０６に認証要求の一部として提供され得、ＭＡＣタグ３１６は、第２のクライアント３０４に関連付けられたカスタマーマスター鍵を用いて生成され、第２のクライアント３０４に提供され、第１のクライアント３０２に転送され得る。第１のクライアントは、メッセージ及びＭＡＣタグを、メッセージの信頼性を判定する検証要求の一部として提供して、メッセージが実際にクライアントＢ３０４によって書かれたものであるかどうかを判定し得る。メッセージが真正なものであるという表示３１８が行われると、クライアントＡ３０２は、公開鍵Ｑ_Ｂを、クライアントＢ３０４との間に共有秘密鍵を確立するのに用いるために格納し得る。共有秘密鍵は、例えば、クライアント間に暗号保護された通信セッションを確立するために用いられ得る。公開鍵Ｑ_Ｂも、図２に関連する上記と同一にまたは同様にして認証動作及び検証動作の代わりに暗号化動作及び復号化動作を用いて交換され得る。

図４は、２つのクライアントが暗号保護された通信セッションを確立する例示的な環境４００を示す。第１のクライアント４０２、第２のクライアント４０４及び暗号化サービス４０６は、図１〜３にしたがって上述されたものと同種であってもよい。いくつかの実施形態では、第１のクライアント４０２は、秘密鍵ｄ_Ａ及び公開鍵Ｑ_Ａを含むＥＣＤＨ鍵ペアを生成していてもよく、公開鍵Ｑ_Ａは、場合によっては図２に上述された実施形態にしたがって、第２のクライアント４０４に配布されている。同様に、第２のクライアント４０４は、秘密鍵ｄ_Ｂ及び公開鍵Ｑ_Ｂを含む第２のＥＣＤＨ鍵ペアを生成していてもよく、公開鍵Ｑ_Ｂは、場合によっては図２〜３に記載された実施形態にしたがって、第１のクライアント４０２に配布されている。

いくつかの実施形態では、第１のクライアント４０２は、少なくともｄ_Ａ及びＱ_Ｂを用いて生成され得る共有秘密鍵４０６を有し、第２のクライアント４０４は、少なくともｄ_Ｂ及びＱ_Ａを用いて生成され得る共有秘密鍵４０８を有する。楕円曲線ディフィーヘルマン鍵交換プロトコルを用いた実施形態では、ｄ_ＡＱ_Ｂ＝ｄ_ＢＱ_Ａなので共有秘密鍵は両方の機関によって計算され得る。暗号保護された通信セッション４１０は、共有秘密鍵を用いて確立され得る。いくつかの実施形態では、暗号化サービス４０６は、秘密鍵ｄ_Ａ及びｄ_Ｂの両方にアクセスできなくてもよく、暗号保護された通信セッションにアクセス４１２可能とならないであろう。いくつかの実施形態では、暗号保護された通信セッション４１０へのアクセス４１２とは、例えばセッションでメッセージを送受信することによって通信セッションに関与する能力を有する暗号化サービスを指し得る。いくつかの実施形態では、暗号化サービスは、暗号保護された通信で指定されたプロトコルを介して暗号化されるデータを復号化できなくてもよい（例えば、暗号化サービスは、クライアント間でＴＬＳセッションを介して送信されるデータを復号化できない）。暗号化サービスはコンピューティング環境においていくつかの暗号化鍵にアクセスできてもよいが（例えばクライアントマスター鍵）、暗号保護された通信にアクセスするのに必要な他の情報にアクセスできなくてもよい（例えば、共有秘密鍵４０６及び４０８、ならびに／または秘密鍵ｄ_Ａ及びｄ_Ｂ）。いくつかの実施形態では、アクセス４１２とは、通信を修正するという暗号化サービスの能力を指し得る。例えば、暗号化サービスは、クライアント４０２とクライアント４０４の間の通信を読み出す能力を有してもよいが、例えば通信は暗号化サービスがアクセスできない秘密鍵を用いて生成されたデジタル署名を含むという理由で、通信を修正不可能であってもよい。

図５は、ある実施形態による第１のクライアント５０２と第２のクライアント５０４と暗号化サービス５０６の間のハンドシェイクプロトコルを例示する図を示す。ハンドシェイクプロトコルの一部として、第１のクライアントは、秘密鍵ｄ_Ａ及び公開鍵Ｑ_Ａを含むＥＣＤＨ鍵ペアを生成５０８し得る。いくつかの実施形態では、ＥＣＤＨ鍵ペアは、ハンドシェイクが始まる前に予め生成され得る。

ＥＣＤＨ鍵ペアが生成された後で、クライアントＡは、送信者及び公開鍵Ｑ_Ａを識別するメッセージを生成５１０し得る。メッセージは、図１〜３に関連して上述されたものにしたがうものであってもよい。次いで、クライアントＡは、メッセージを暗号化サービスに認証を受けるために提供５１２し得る。いくつかの実施形態では、メッセージは、暗号化サービスにウェブＡＰＩを通じて提供され得る。暗号化サービス５０６は、暗号化鍵を用いてメッセージ全体にデジタル署名またはＭＡＣタグを生成し得る。クライアントＡは、暗号化サービスに、認証要求の一部として、メッセージを認証するために暗号化サービスによって用いられる暗号化鍵に対応する固有識別子を提供し得る。いくつかの実施形態では、鍵識別子はメッセージで提供され得るが、他の実施形態では、鍵識別子は、ウェブＡＰＩ要求で別のパラメータとして提供され得、さらに別の実施形態では、鍵識別子は、呼び出し元の識別に基づいて暗黙的であり得る。暗号化サービスは、クライアントＡに、メッセージ及びＭＡＣタグを含む認証されたメッセージを戻し得る。いくつかの実施形態では、クライアントＡは、元のメッセージのコピーを保持し得、暗号化サービスはＭＡＣタグを戻す。

いくつかの実施形態では、クライアントＡは、認証されたメッセージを含む暗号保護された通信セッションの要求をクライアントＢに提供５１４し得る。要求は、例えば、図１〜３に関連して上述されたものなどの要求であってもよい。要求は、クライアントＡの識別情報及び公開鍵Ｑ_Ａを含むメッセージングならびに対応するＭＡＣタグを含み得る。

いくつかの実施形態では、クライアントＢは、認証されたメッセージを含む暗号保護された通信セッションを確立する要求を受信５１６し得る。いくつかの実施形態では、クライアントＢは、要求をクライアントＡから間接的に受信する−例えば、クライアントＡは、要求を、クライアントＢに要求を転送する中間クライアントＸ（示さず）を通して送信し得る。いくつかの実施形態では、中間は別のコンピュータシステムであってもよいが、ルータまたはスイッチといったメッセージを修正可能な他の種類のコンピューティングエンティティでもよいことに留意されたい。したがって、要求を受信すると、クライアントＢは、要求が真正なものであるかどうか、及び、クライアントＡによって送られたときから内容が修正されていないことを検証する必要があり得る。場合によっては、クライアントＡのメッセージを傍受する悪意ある機関は、例えば暗号保護された通信セッションを構成する公開鍵Ｑ_Ａを修正しようと試みることがある。

いくつかの実施形態では、クライアントＢは、認証されたメッセージを暗号化サービス５０６に提供５１８し、暗号化サービスに、認証されたメッセージを検証するように要求し得る。暗号化サービス５０６は、クライアントＢから、認証されたメッセージをその信頼性を検証する命令とともに受信し得る。認証されたメッセージを検証する要求の一部として鍵識別子も提供され得る。いくつかの実施形態では、暗号化鍵が取得され、ＭＡＣタグがメッセージ全体に生成され、生成されたＭＡＣタグは、受信されたＭＡＣタグと比較されて、メッセージが真正なものであるかどうかを判定する。いくつかの実施形態では、暗号化サービスは、ＭＡＣタグの代わりに受信されるデジタル署名を受信し、デジタル署名を生成し、生成されたデジタル署名を受信されたデジタル署名と比較し得る。メッセージが真正なものであることを検証した後で、クライアントＢ５０４は、公開鍵Ｑ_Ａを抽出し、ＥＣＤＨ鍵ペアｄ_Ｂ及びＱ_Ｂを生成５２０し、ｄ_Ｂ及びＱ_Ａを用いて共有秘密鍵を計算５２２し得る。

ＥＣＤＨ公開鍵Ｑ_Ａを受信した後で、クライアントＢ６０４は、例えば図６に記載されたように、ＥＣＤＨ公開鍵Ｑ_ＢをクライアントＡ６０２と交換し得る。環境６００は、図５に関連して上述された環境５００と同一のまたは同様の環境であってもよい。公開鍵Ｑ_Ｂの交換は、ハンドシェイクプロトコルの一部であってもよく、暗号保護された通信セッションを確立する図５に示す流れの後に生じてもよい。鍵は、図５（具体的には、ステップ５２０を参照）に関連して上述された流れの際に等、別のところで生成され得ることに留意するべきである。クライアントＢは、クライアントＢとしての送信者識別及び公開鍵Ｑ_Ｂを識別するメッセージを生成６１０し、メッセージを暗号化サービス６０６に認証を受けるために提供し得、暗号化サービス６０６は、メッセージを、例えばメッセージ全体にＭＡＣタグまたはデジタル署名を生成することによって、認証６１２し、認証されたメッセージをクライアントＢ６０４に提供し得る。これらのステップは、図５に関連して上述した対応するステップにしたがって行われ得る。クライアントＢは、暗号保護された通信セッションを確立する要求に応答６１４し得、応答の一部として、認証されたメッセージを含み得る。クライアントＡは、応答を受信６１６し、暗号化サービスを用いることによって検証を行って、応答における認証されたメッセージが有効かどうかを判定し得る。要求が有効であると判定された場合、公開鍵Ｑ_Ｂを用いて、例えば楕円曲線ディフィーヘルマン鍵交換のｄ_Ａ及びＱ_Ｂを用いた共有秘密鍵を計算６２０することができる。

両方の機関が共有秘密鍵６２０及び６２２を計算すると、暗号保護された通信セッションは、共有秘密鍵を用いて確立され得る。確立されると、クライアントＡとクライアントＢは、暗号化サービスは共有秘密鍵を知らずしたがって暗号保護された通信セッションで用いられる秘密鍵を知らないという保証のもと、暗号保護された通信を介して通信し得る。このことにより、暗号化サービスも、公開鍵Ｑ_Ａ及びＱ_Ｂを含む認証されたメッセージを傍受し得る任意の他の機関も、暗号保護された通信セッションに関与することができないので、セキュリティ保証は高められる。

図７は、ある実施形態によるハンドシェイクを行うプロセス７００の具体例を示す。プロセス７００は、図１〜６に上述したクライアントにしたがって記載されたコンピュータシステムなどの任意の適切なシステムによって行われ得る。しかしながら、プロセス７００は、ハンドシェイクプロセスに関与する任意のコンピュータシステムによって行われ得ることに留意されたい。また、ハンドシェイクプロセスは、ハンドシェイクプロトコル及びレコードプロトコルを含む暗号保護された通信セッションのためのプロトコルといった、暗号保護された通信セッションの確立のための任意のハンドシェイクであってもよいことにも留意されたい。ある実施形態では、プロセス７００を行うシステムは、第１の秘密鍵及び第１の公開鍵を含む第１の非対称鍵ペアを生成７０２し得る。いくつかの実施形態では、非対称鍵ペアは楕円曲線鍵ペアであってもよい。システムはまた、送信者識別情報及び第１の公開鍵を含む第１のメッセージも生成７０４し得る。第１のメッセージは、段階７０２で非対称鍵ペアを生成するより前に部分的に生成され得ることに留意されたい。例えば、いくつかの実施形態では、メッセージは、第１の非対称鍵ペアを生成するより前に部分的に生成され得る。送信者識別情報は、例えばユーザＩＤ、ＧＵＩＤ、マシンＩＤ、メディアアクセス制御アドレス（ＭＡＣアドレス）などとして符号化され得る。さらに、動的ＩＰアドレスなどの動的識別子を用いて送信者の識別を識別し得る。

いくつかの実施形態では、システムは次いで、暗号化サービスに、少なくとも送信者識別情報及び第１の公開鍵を含む第１のメッセージを提供７０６し得る。いくつかの実施形態では、システムは、代わりに、送信者識別情報及び第１の公開鍵を暗号化サービスに別々に送信し得、暗号化サービスは、少なくとも送信者識別情報及び第１の公開鍵を受信した後で、送信者識別情報及び第１の公開鍵の両方全体にＭＡＣタグまたはデジタル署名を生成し得る。

システムは、第１のメッセージを暗号化サービスに提供後、暗号化サービスから、第１のメッセージに対応する第１の認証されたメッセージを受信７０８し得、該第１の認証されたメッセージは第２のクライアントによって検証することができるものである。認証されたメッセージは、元のメッセージまたは送信者識別情報及び公開鍵を含む別のメッセージ、ならびに対応するＭＡＣタグを含み得る。認証されたメッセージは、暗号保護された通信セッションがそれとともに確立されるクライアントによって暗号学的に検証可能でなければならない。いくつかの実施形態では、ＭＡＣタグを検証することは、暗号化サービスによって保護され得る暗号化鍵へのアクセスを必要とし得る。そうした実施形態では、ＭＡＣタグを検証しようとする呼び出し元のサブセットは、暗号化サービスから、呼び出し元は検証要求を完了するのに必要なリソースにアクセスできないことを示すエラーを受信し得る。他の実施形態では、失敗の表示が、検証動作を行うのに必要な暗号化鍵がアクセス可能でなかったことをさらに示さないように、一般的なエラーが提供される。いくつかの実施形態では、真正なものであるメッセージは、送信者識別情報及び／または公開鍵が暗号化サービスによってアクセス可能な暗号化鍵を用いて暗号化されるように、暗号化され得、暗号保護された通信セッションをそれとともにシステムが確立しようとしているクライアントによって復号化され得る。

次いで、システムは、暗号保護された通信セッションをそれとともに確立するクライアントを識別し、第１の認証されたメッセージをそのクライアントに提供７１０し得る。認証されたメッセージは、直接的に（例えばメッセージはハンドシェイクプロトコルまたは要求の一部として含まれる）または間接的に（例えば、認証されたメッセージを配置し取得するのに用いられ得るユニフォームリソース識別子（ＵＲＩ）が提供される）提供され得る。いくつかの実施形態では、要求は、１つもしくは複数のコンピュータシステム、または、認証されたメッセージの内容を検査かつ／もしくは修正する能力を有し得るルータもしくはスイッチといったコンピューティングエンティティを通過してもよいことに留意されたい。しかしながら、ＭＡＣタグの正しく対応する修正なしでのメッセージ内容の修正は、検出可能であろう。

いくつかの実施形態では、システムは、暗号保護された通信セッションをそれとともに確立するクライアントから、第２の認証されたメッセージを受信７１２し得る。いくつかの実施形態では、第２の認証されたメッセージは、識別情報及び第２の公開鍵を含むメッセージならびにメッセージが真正なものであることを検証するのに用いられ得るＭＡＣタグを備える。いくつかの実施形態では、真正なものであるメッセージは、第２の公開鍵の暗号文及び／または第２のクライアントの識別情報を備える。システムは、暗号化サービスを用いて、第２の認証されたメッセージの信頼性を検証７１４し得る。いくつかの実施形態では、ＭＡＣタグはメッセージ全体に生成され、生成されたＭＡＣタグは提供されたＭＡＣタグと比較され、いくつかの実施形態では、デジタル署名が検証され得る。いくつかの実施形態では、認証されたメッセージは、復号化されかつ用いられた暗号化鍵は他の機関がメッセージを暗号化し得ないように第２のクライアントに関連付けられていることを検証することによって検証される暗号化されたメッセージであってもよい。検証がメッセージが真正なものであることの判定に成功した場合、システムは、少なくとも第２の公開鍵及び第１の秘密鍵を用いて共有秘密鍵を生成７１６または計算し得る。いくつかの実施形態では、第２の公開鍵は、楕円曲線公開鍵Ｑ_２であってもよく、第１の秘密鍵は、楕円曲線秘密鍵ｄ_１であってもよく、共有秘密鍵は、ｄ_１Ｑ_２であってもよい。

システムは、ハンドシェイクを完了し、少なくとも共有秘密鍵を用いて、暗号保護された通信セッションまたは暗号保護された通信セッションを確立７１８し得る。いくつかの実施形態では、暗号保護された通信セッションは、機密性の保証、例えばＴＬＳセッションを提供する。他の実施形態では、セッションは、機密性の保証を提供しなくてもよいが、セッションでのメッセージの整合性及び真正性などの他の保証を提供してもよい。

本明細書中で用いる用語「エンベロープ暗号化」とは、計算リソースが制限されている環境でデータの暗号化及び復号化の性能を向上させる技術を指す。計算リソースとして、ＣＰＵリソース、メモリ、リソース、帯域幅などが挙げられ得る。エンベロープ暗号化スキームでは、クライアント及び上述した暗号化（）及び復号化（）などの暗号化動作を行うのに用いられ得る暗号化サービスが存在し得る。さらに、暗号化サービスは、クライアントが暗号化動作を行うのに用い得るカスタマーマスター鍵を格納し得る。いくつかの実施形態では、あらゆる暗号化動作及び復号化動作を行うのに暗号化サービスを用いることには短所となり得る。例えば、ブロードバンドインターネット接続（例えば約１００Ｍｂ／ｓのスループットを有する）を介して暗号化サービスに接続するクライアントの場合、大量のデータ（例えばテラバイトのデータ）の暗号化は、データを暗号化のために暗号化サービスにブロードバンド接続を介して転送することに関わるオーバーヘッドのため、望ましくない性能不良を有し得る。一例として、８ＴＢのファイルを１００Ｍｂｐｓのブロードバンド接続を介して転送することは、完了に１７７時間（＞１週間）以上かかるであろう。したがって、いくつかのシステムでは、データブロック全体を暗号化のためにネットワークを介して転送しないようにすることは利点であり得る。

エンベロープ暗号化スキームは、暗号化動作の性能を向上させるために用いられ得る。大きなデータセットを暗号化するのに、暗号化サービスは、対称データ鍵を生成し、データ鍵をクライアントマスター鍵のもとで暗号化し得る。暗号化されたデータ鍵は、暗号化されたデータ鍵がどのように復号化され得るかを示す追加の情報（場合によっては平文で）を含み得る（例えばメタデータフィールドは、暗号化されたデータ鍵を復号化するのに使用可能な鍵ＩＤを含み得る）。平文データ鍵及び暗号化されたデータ鍵は、クライアントに送信され得、クライアントは、データ鍵を用いてデータを暗号化し得る。暗号化されたデータ（データ鍵のもとで暗号化された）及び暗号化されたデータ鍵（クライアントマスター鍵のもとで暗号化された）は、一緒に格納され得、または、一緒に関連付けられ得る（例えば、データベースレコードで）。

暗号化されたデータを復号化するのに、クライアント（場合によっては、データを暗号化したクライアントとは異なるクライアント）は、暗号化されたデータ鍵を取得し、暗号化サービスに暗号化されたデータ鍵を復号化することを要求し得る。暗号化サービスは、鍵ＩＤが復号化要求の一部として提供されることを要し得る。要求者が十分なアクセス権を有し（例えば、データを暗号化したクライアントによるアクセス権付与を通じて）、暗号化されたデータ鍵を復号化するのに正しい暗号化鍵が用いられる場合、平文のデータ鍵は戻され、その後、暗号化されたデータを復号化するのに用いられ得る。

図８は、本開示の様々な技術が利用され得る状況を例示する略図８００を示す。この特定の例では、略図８００は、第１のクライアント「クライアントＡ」８０２、第２のクライアント「クライアントＢ」８０４及び第３のクライアント「クライアントＣ」８０６を示す。略図８００は、さらに、メッセージ８０８、拡張エンベローブ暗号化スキームのもとで保護されたメッセージ８１０（以下「保護されたメッセージ」）及び不正メッセージ８１４を例示する。クライアント８０２、８０４及び８０６は、本開示の別のところで記載されるものなどのクライアントであってもよい。いくつかの実施形態では、クライアントはコンピュータシステムであってもよいが、ルータまたはスイッチといったメッセージ８０２を修正可能な他の種類のコンピューティングエンティティであってもよい。

いくつかの実施形態では、クライアントＡ８０２は、メッセージ８０８、より一般的にはデータを生成し、データを拡張エンベロープ暗号化スキームのもとで保護する。いくつかの実施形態では、拡張エンベロープ暗号化スキームのもとで保護されたメッセージ８１０は、エンベロープ暗号化を行うのに用いられるデータ鍵にアクセスできる他のクライアントによって読み出すことができるが、それらのクライアントによって修正されることはできない。いくつかの実施形態では、暗号化サービスを用いて、保護されたメッセージが不適切に修正されたかどうかを検証し得る。いくつかの実施形態では、クライアントＡは、保護されたメッセージを修正し得、保護されたメッセージを修正する能力を他の機関、例えば、エンベロープ暗号化を行うのに用いられるデータ鍵にアクセスできるクライアントのサブセットに委譲し得る。したがって、いくつかの実施形態では、保護されたメッセージ８１０を読み出し修正することが可能な機関は、保護されたメッセージ８１０を読み出すことが可能な機関とは異なり得る−図８にしたがった一実施形態では、クライアントＡ８０２は、保護されたメッセージを読み出し修正することが可能であり、一方、クライアントＡ、Ｂ及びＣ８０２〜８０６は、保護されたメッセージを読み出すことが可能である。

いくつかの実施形態では、保護されたメッセージ８１０の送信者（例えばＴＣＰパケットのソースアドレス）はクライアントＡ８０２であり、メッセ―ジの受信者（例えばＴＣＰパケットの宛先アドレス）はクライアントＢ８０４である。いくつかの実施形態では、保護されたメッセージ８１０の送信者はクライアントＡ８０２であり、受信者はクライアントＣ８０６であり、クライアントＢは、クライアントＡとクライアントＣの間の通信を容易にするもう１つのコンピュータシステムであってもよい。いくつかの実施形態では、保護されたメッセージ８１０の送信者はクライアントＡ８０２であり、受信者はクライアントＢ８０４であり、クライアントＡとクライアントＢの間にある取り決めが存在する（例えば、ネットワークプロトコル仕様に記載された取り決めなどの技術的取り決めまたは契約上の義務もしくはサービス品質保証（ＳＬＡ）などの非技術的な取り決め）。

いくつかの実施形態では、クライアントＢ８０４は、保護されたメッセージの不正修正８１６を行おうと試み得る。クライアントＢ８０４は、データ鍵を取得し、保護されたメッセージ８１０を復号化し、メッセージを修正（例えば、メッセージを「１２３・・・」から「７８９・・・」に変更すること）し、次いで、データ鍵を用いて、修正されたメッセージ８１２を暗号化し、不正メッセージ８１４をもたらし得る。クライアントＢ８０４は次いで、不正メッセージ８１４をクライアントＣ８０６に提供し得る。しかしながら、本明細書で開示された技術を用いて、クライアントＣ８０６は、暗号化サービスを用いて、それが受信したメッセージ（すなわち不正メッセージ８１４）は不適切に修正されたかどうかを検証し得る。

図９は、本開示の様々な技術が利用され得る状況を例示する略図９００を示す。この特定の例では、略図９００は、保護されたメッセージがどのように生成され送信され得るかを示す。第１のクライアント９０２及び第２のクライアント９０４が示される。第１のクライアント９０２は、図８に関連して上述された第１のクライアント８０２と同一または同様のものであってもよい。第２のクライアント８０２は、図８に関連して上述された第２のクライアント８０４と同一または同様のものであってもよいが、いくつかの例では、図８に関連して上述された第３のクライアント８０６と同一または同様のものであってもよい。同様に、クライアントは、本開示の別のところに記載されたコンピュータシステムまたはコンピューティングエンティティであってもよい。

暗号化サービス９０６は、本開示の別のところに記載された暗号化サービスであってもよい。いくつかの実施形態では、暗号化サービスは、少なくとも２つの動作−（１）データ鍵を生成すること及び（２）データの認証付き暗号化を行うことをサポートし得る。いくつかの実施形態では、クライアントは、暗号化サービス９０６に、エンベロープ暗号化に用いることができるデータ鍵を生成することを要求し得る（例えば、ウェブＡＰＩ要求を介して）。暗号化サービス９０６は、データ鍵を生成し、呼び出し元−クライアントに関連付けられたクライアントマスター鍵を用いてデータ鍵を暗号化し、データ鍵及び暗号化されたデータ鍵の両方を呼び出し元−クライアントに戻し得る（例えば、ウェブＡＰＩ応答を介して）。いくつかの実施形態では、呼び出し元−クライアントは、暗号化サービスを用いて、暗号化されたデータ鍵を復号化し得、呼び出し元−クライアントはまた、例えば呼び出し元−クライアントに関連付けられたカスタマーマスター鍵を用いてデータを復号化する能力を特定の他の機関（例えばクライアントＢ９０４）に付与するクライアントマスター鍵へのセキュリティポリシーを用いて、他の機関が、暗号化されたデータ鍵を復号化することも可能にし得る。例えば、図９〜１０による実施形態では、クライアントＡ９０２は、クライアントＢ９０４に、クライアントＡに関連付けられたカスタマーマスター鍵のもとで暗号化されたデータ鍵を復号化する能力を付与している。いくつかの実施形態では、クライアントは、暗号化サービス９０６に、上述した暗号化（）ＡＰＩと同一または同様なものであるＡＰＩを用いてデータを暗号化することを要求し得る（例えば、ウェブＡＰＩ要求を介して）。

いくつかの実施形態では、第１のクライアント９０２は、メッセージ９０６、データ鍵９０８、任意選択的な追加認証データ（ＡＡＤ）９１０ならびに秘密鍵ｄ_Ａ及び公開鍵Ｑ_Ａを含むＥＣＤＨ鍵ペア９１２を生成、取得かつ／または格納し得る。メッセージ９０６は、平文のメッセージであってもよく、または、予め暗号化された暗号文のメッセージであってもよい。データ鍵９０８は、暗号化サービス９０６によって生成された暗号化鍵であってもよい。いくつかの実施形態では、第１のクライアント９０６は、暗号化サービスから、平文のデータ鍵９０８及び第１のクライアントに関連付けられたクライアントマスター鍵のもとで暗号化されたデータ鍵の両方を取得していてもよい。いくつかの実施形態では、第１のクライアントは、任意選択的なＡＡＤ９１０を有さなくてもよい（例えば、任意選択的なＡＡＤは用いられなくてもよく、存在しなくてもよく、またはＮＵＬＬ値で表されてもよい）。いくつかの実施形態では、クライアント９０２は、秘密鍵ｄ_Ａ及び公開鍵Ｑ_Ａを含むＥＣＤＨ鍵ペア９１２を生成する。いくつかの実施形態では、秘密鍵ｄ_Ａは他の機関に秘匿される。いくつかの実施形態では、他の種類の非対称鍵ペアが楕円曲線鍵ペアの代わりに用いられ得る。

メッセージ９０６は、任意の形式のデータであってもよく、いくつかの実施形態では、クライアント９０２によって書かれてもよい（すなわちクライアント９０２によって生成されてもよい）が、別のソースから取得されたデータであってもよい。データ鍵９０８は、例えば、本開示で先に記載されたようにエンベロープ暗号化スキームで用いられ得る暗号化鍵であってもよい。データ鍵は、対称鍵であってもよくまたは非対称鍵であってもよい。追加認証データ９１０は、認証付き暗号化の一部として用いられ得る。いくつかの実施形態では、認証付き暗号化は、平文のデータ入力（例えば平文それ自体または平文の暗号文バージョン）及びＡＡＤに基づく認証タグ（例えばＭＡＣタグ）を生成する。ＡＡＤ９１０は、対応する認証付き復号化の復号化成功のために提示を要され得る。いくつかの実施形態では、ＡＡＤ９１０は、認証付き暗号化中に暗号化されず、難読化されていない形式（すなわち非暗号化）で送信され得る。

保護されたメッセージ９２４は、図９に示すものなどのいくつかの構成要素を含み得る。いくつかの実施形態では、保護されたメッセージ９２４は、少なくとも暗号化されたメッセージ９１６を含むデジタル署名されたペイロード９１４を含む。暗号化されたメッセージ９１６は、データ鍵９０８のもとで暗号化され得る。デジタル署名されたペイロード９１４は、ＥＣＤＨの秘密鍵ｄ_Ａを用いて暗号化されたメッセージ９１６全体に生成されかつＥＣＤＨの公開鍵Ｑ_Ａを用いて検証可能なデジタル署名であってもよい。

いくつかの実施形態では、保護されたメッセージは、さらに、ＥＣＤＨの公開鍵Ｑ_Ａを含む。しかしながら、他の実施形態では、ＥＣＤＨの公開鍵は、保護されたメッセージの別の構成要素の一部として含まれ得る（例えば、ＡＡＤが公開鍵Ｑ_Ａを含み得る）。

いくつかの実施形態では、保護されたメッセージは、さらに、（１）クライアントマスター鍵のもとで暗号化されたデータ鍵の暗号文９２２と（２）（直接的にまたは間接的に）データ鍵ならびに任意選択的なＡＡＤ９１０及びＥＣＤＨの公開鍵Ｑ_Ａを含む拡張ＡＡＤ全体に生成される認証タグ（例えばＭＡＣタグ）とを含む認証されたペイロード９２０を含む。いくつかの実施形態では、認証されたペイロードは、ＲＦＣ５０８４に記載されたものなどの認証付き暗号化動作を用いて生成され得、これは本明細書によって参照により組み込まれる。一例として、認証されたペイロード９２０は、以下の入力パラメータを用いてＡＥＳ−ＣＣＭ暗号化を行う暗号化サービス９０６によって生成され得る。
ＡＥＳ鍵：クライアントマスター鍵（図９に示さず）
ノンス：（任意の固有値）
平文：データ鍵９０８、及び
任意選択的な追加認証データ：ＡＡＤ９１０及び公開鍵Ｑ_Ａ
ＡＥＳ−ＣＣＭ暗号化は、（１）データ鍵の暗号文９２２及び（２）データ鍵ならびにＡＡＤ９１０及びＥＣＤＨの公開鍵Ｑ_Ａを含む拡張ＡＡＤ全体へのＭＡＣタグ９２０を生成する。いくつかの実施形態では、拡張ＡＡＤは、ＥＣＤＨの公開鍵のみから構成され得る（例えばＡＡＤ９１０は空である）。ＡＥＳ−ＧＣＭ暗号化は、上述と同一にまたは同様にして行われ得る。

いくつかの実施形態では、認証されたペイロード９２０の構造は、図９に示す具体例と異なってもよい。一例として、認証されたペイロードは、データ鍵９０８及びＥＣＤＨの公開鍵Ｑ_Ａの両方を含む暗号文ならびに任意選択的なＡＡＤ（空であってもよい）を含み得る。この例では、認証タグは、クライアントＡのカスタマーマスター鍵を用いて暗号文及びＡＡＤ全体に生成され得る。

いくつかの実施形態では、認証されたペイロード９２０の構造は、図９に示す具体例と異なってもよい。一例として、認証されたペイロードは、データ鍵９０８を含む暗号文及び任意選択的なＡＡＤ（空であってもよい）を含み得る。この例では、認証タグは、クライアントＡのカスタマーマスター鍵を用いて暗号文及びＡＡＤ全体に生成され得、第２の認証タグは、同一の鍵を用いてＥＣＤＨの公開鍵Ｑ_Ａ全体に生成され得る。

いくつかの実施形態では、第１のクライアント９０２は、保護されたメッセージを、第２のクライアント９０４などの他のコンピューティングエンティティにとって利用可能なものとし得る。システムは、直接的に（例えば、メッセージはハンドシェイクプロトコルまたは要求の一部として含まれる）または間接的に（例えば、保護されたメッセージを配置し取得するのに用いられ得るユニフォームリソース識別子（ＵＲＩ）が提供される）、保護されたメッセージを利用可能にし得る。いくつかの実施形態では、メッセージは、利用可能にされると、１つもしくは複数のコンピュータシステムまたはメッセージの内容を検査かつ／もしくは修正する能力を有してもよいルータもしくはスイッチなどのコンピューティングエンティティを通過し得ることに留意されたい。しかしながら、メッセージの内容の修正（例えば、デジタル署名を修正せずに暗号文のメッセージを修正すること及び／または認証タグを修正せずに暗号文のデータ鍵を修正すること）は検出可能であろう。

図１０は、本開示の様々な技術が利用され得る状況を例示する略図１０００を示す。この特定の例では、略図１０００は、保護されたメッセージがどのように受信され検証され得るかを示す。第１のクライアント１００２及び第２のクライアント１００４が示される。第１のクライアント１００２は、保護されたメッセージ１０１８を第２のクライアント１００４に送信することが示される。送信側クライアントと受信側クライアントと保護されたメッセージの様々な関係は本開示の範囲内で完結することに留意するべきである−送信側クライアントは、保護されたメッセージを生成していてもよく（例えば図８のクライアントＡ）、または、不正メッセージを生成しその不正メッセージを受信側クライアント（図８のクライアントＢ）に提供するエンティティであってもよい。いずれの場合も、保護されたメッセージを受信するクライアント（すなわちクライアントＣ１００４）は、保護されたメッセージが不適切に修正されたかどうかを検証し得る。図１０に関連して記載されたクライアントは、本開示の別のところに記載されたコンピュータシステムまたはコンピューティングエンティティであってもよい（例えばルータまたはスイッチ）。

暗号化サービス１００６は、本開示の別のところに記載された暗号化サービスであってもよい。いくつかの実施形態では、暗号化サービスは、少なくとも２つの動作−（１）クライアント鍵ＩＤを取得すること及び（２）データを復号化することをサポートし得る。いくつかの実施形態では、クライアントは、暗号化サービス１００６に、クライアント鍵ＩＤを取得し鍵ＩＤを呼び出し元−クライアントに戻すことを要求し得る（例えばウェブＡＰＩ要求を介して）。いくつかの実施形態では、呼び出し元−クライアントは、ユーザＩＤ、ＧＵＩＤ、マシンＩＤ、メディアアクセス制御アドレス（ＭＡＣアドレス）等といった識別情報を提供する。暗号化サービスは、例えば、識別情報とクライアント鍵ＩＤの関連性を、１つまたは複数のデータベーステーブルのデータベースレコードに、配列として（例えば２次元配列）、ハッシュマップで（例えば、鍵が送信者情報であり値が鍵ＩＤであるハッシュマップ）または他の適切なデータ構造で格納することによって、識別情報をクライアント鍵ＩＤにマッピングし得る。クライアント鍵ＩＤは、ユーザネーム、整数、文字数字の列、文字配列、ＧＵＩＤまたは他のそうしたデータ型として表され得る。識別情報の鍵ＩＤに対するマッピングは、単射（すなわち１対１）であってもよくかつ／または全単射（すなわち１対１かつ上への）であってもよい。いくつかの実施形態では、クライアントは、暗号化サービス９０６に、上記で説明した復号化（）ＡＰＩと同一または同様のＡＰＩを用いてデータを暗号化することを要求し得る（例えば、ウェブＡＰＩ要求を介して）。

いくつかの実施形態では、第１のクライアント１００２は、保護されたメッセージ１０１８を第２のクライアント１００４に送信する。保護されたメッセージ１０１８は、図９〜１０に関連して記載された保護されたメッセージと同一または同様なものであってもよい。いくつかの実施形態では、保護されたメッセージは、暗号文１０１０を含む暗号化されたペイロード１００８及びＥＣＤＨの公開鍵によって検証可能である暗号文１００８全体へのデジタル署名を含む。いくつかの実施形態では、保護されたメッセージは、さらに、ＥＣＤＨの公開鍵１０１２を含む。いくつかの実施形態では、保護されたメッセージは、さらに、暗号文１０１６と、暗号文１０１６ならびにＡＡＤ及びＥＣＤＨの公開鍵を含む拡張ＡＡＤ全体への認証タグとを含む認証されたペイロード１０１４を含む。クライアントＣによって受信される保護されたメッセージ１０１８の内容は不適切に修正され得たことに留意するべきである。ここで記載された技術により、保護されたメッセージを受信するクライアントは、保護されたメッセージが不適切に修正されたかどうかを判定することが可能になる。

いくつかの実施形態では、保護されたメッセージを受信するクライアント（図１０のクライアントＣ１００４）は、暗号化サービスを用いて、認証されたペイロード１０１４を復号化する。クライアントは、暗号化サービスに、ウェブＡＰＩ要求の一部として、暗号文、ＡＡＤ１０２４及びＥＣＤＨの公開鍵Ｑ_Ａ１０２６を両方含む拡張ＡＡＤならびに暗号文及び拡張ＡＡＤ全体に生成された認証タグを提供し得る。同様に、認証タグがＡＡＤ全体に生成される（公開鍵Ｑ_Ａには生成されない）実施形態では、ＡＡＤが拡張ＡＡＤの代わりに提供され得る。いくつかの実施形態では、クライアントは、復号化のために、ＡＰＩ要求の一部として鍵ＩＤも暗号化サービスに提供し得る。クライアントは、様々な情報に基づいて鍵ＩＤを判定し得る。例えば、保護されたメッセージ１０１８は、クライアントＣと識別が既知である別のクライアントの間で通信セッションの一部として送信され得る。そうした例では、鍵ＩＤは、クライアントＣが通信セッションにそれとともに関与する機関に関連付けられ得る。第２の例として、保護されたメッセージにおける情報（例えば図１０に示さないメタデータ）を用いて、鍵ＩＤを判定し得る。第３の例として、メッセージは１つまたは複数のＴＣＰパケットの一部として受信され得、鍵ＩＤは送信者の識別（例えばＴＣＰヘッダのソースアドレス）に基づいて判定され得る。

いくつかの実施形態では、暗号化サービスは、認証されたメッセージに含まれる暗号文１０１６を復号化する。いくつかの実施形態では、暗号文は、復号化のために用いる鍵ＩＤを含むメタデータ（例えば暗号文に追加されている）を含み得る。暗号化サービスは、暗号文を、鍵ＩＤを用いて復号化し、復号化された平文を用いて、平文及び提供されたＡＡＤを用いた認証タグを生成し得る。生成されたタグと復号化要求で提供されたタグが一致しない場合、復号化は失敗し得る。復号化が成功した際、暗号化サービス１００６は、クライアントに、復号化された平文及び、いくつかの実施形態では、復号化を行うのに用いられるクライアントマスター鍵の鍵ＩＤを戻し得る。いくつかの実施形態では、平文は、暗号化されたメッセージ１０１０を復号化するのに使用可能なデータ鍵１０２２である。

いくつかの実施形態では、クライアント１００４は、復号化された平文１０２０及び鍵ＩＤを、暗号化サービスから復号化要求への応答として受信し得る。クライアントは、さらに、受信した鍵ＩＤを予測される鍵ＩＤと比較し得る。予測される鍵ＩＤは、予測される送信者に関連付けられた鍵ＩＤであってもよい。クライアントは、プロトコルまたは他の情報に基づいて、予測される送信者を判定し得る。受信した鍵ＩＤと予測される鍵ＩＤが一致しない場合、エラーが発生し得、保護されたメッセージは無効として破棄され得る。しかしながら、受信した鍵ＩＤと予測される鍵ＩＤが一致する場合、クライアントはメモリ内に、復号化されたデータ鍵１０２２を格納かつ／またはキャッシュし得る。

いくつかの実施形態では、クライアントは、デジタル署名されたペイロード１００８を受信し得る。いくつかの実施形態では、ＥＣＤＨの公開鍵Ｑ_Ａを用いて、デジタル署名されたペイロード１００８全体のデジタル署名を検証し得る。一実施形態では、公開鍵Ｑ_Ａは、復号化動作の一部として認証される拡張ＡＡＤの一部として含まれる。認証すると、公開鍵Ｑ_Ａを用いてデジタル署名を検証し得る。デジタル署名が無効の場合、保護されたメッセージは無効として破棄され得る。しかしながら、デジタル署名が有効である場合、暗号化されたメッセージ１０１０は、認証されたペイロード１０１８の復号化から取得されるデータ鍵１０２２を用いて復号化され得る。復号化が完了すると、クライアント１００４は、不適切に修正されていない平文のメッセージ１０２０を取得する。

図１１は、保護されたメッセージを生成する第１のクライアント１１０２を例示する略図１１００を示す。まず、クライアントＡ１１０２は、秘密鍵ｄ_Ａ及び公開鍵Ｑ_Ａを含むＥＣＤＨ鍵ペアを生成１１０８し得る。鍵は、本開示の別のところに記載された様々なやり方で生成され得る。さらに、楕円曲線鍵ペアの代わりに他の種類の非対称鍵ペアが用いられ得る。クライアントＡはまた、データ鍵の生成を要求１１００し得る。データ鍵は、エンベロープ暗号化を行うのに使用可能であり得る。要求は、本開示の別のところに記載された機能性をサポートする暗号化サービス１１０６へウェブＡＰＩ要求として行われ得る。暗号化サービス１１０６は、要求を受信し、データ鍵を生成１１１２し、要求に応えてクライアントにデータ鍵を提供し得る。いくつかの実施形態では、データ鍵は、ＥＣＤＨ鍵ペアよりも前に生成され得る。

クライアントＡは、データ鍵を暗号化サービスから（例えばウェブＡＰＩ要求に応えて）受信し、メッセージをデータ鍵で暗号化１１１４し得る。メッセージを暗号化した後、ＥＣＤＨの秘密鍵ｄ_Ａを用いて、メッセージの暗号文全体にデジタル署名を生成１１１６し得る。生成されたデジタル署名の有効性は、対応するＥＣＤＨの公開鍵Ｑ_Ａを用いて検証可能であってもよい。デジタル署名及び暗号文メッセージを含むデジタル署名されたペイロードは、保護されたメッセージの一部として含まれ得る。

データ鍵の受信後、クライアントＡは、要求を暗号化サービス１１０６に発行して、認証付き暗号化を行い得る。要求はウェブＡＰＩ要求であってもよく、クライアントＡは、ウェブ要求の一部として、データ鍵、追加認証データ（ＡＡＤ）及びＥＣＤＨの公開鍵Ｑ_Ａを提供し得る。いくつかの実施形態では、ＡＡＤは任意選択的であり、省略されてもよい。暗号化サービスは、データ鍵を、クライアントＡに関連付けられたクライアントマスター鍵を用いて暗号化１１１８し、データ鍵（平文を用いて直接的に、または、データ鍵の暗号文を用いて間接的に）、ＡＡＤ（省略されない場合）及びＥＣＤＨの公開鍵Ｑ_Ａ全体に認証タグを生成し得る。生成された暗号文及び認証タグを含む認証されたペイロードは、保護されたメッセージの一部として含まれ得る。

いくつかの実施形態では、暗号化サービスは、データ鍵の生成後、データ鍵のコピーを格納、キャッシュまたはアーカイブし得る。そうした実施形態では、暗号化サービスは、クライアントＡのカスタマーマスター鍵を用いて暗号化されたデータ鍵も格納、キャッシュまたはアーカイブし得る。暗号化されたデータ鍵は、データ鍵が生成された後で任意の時に生成され得る（例えば、データ鍵が生成された後かつ認証付き暗号化の要求１１１８の前）。クライアントＡは、そうした実施形態では、データ鍵を暗号化要求で提供することを省略し得、暗号化サービスは、格納部、キャッシュまたはアーカイブからデータ鍵を暗号化し得る。

クライアントＡがデジタル署名されたペイロード及び認証されたペイロードの両方を取得した後で、クライアントＡは、デジタル署名されたペイロード及び認証されたペイロードの両方をクライアントＢ１１０４に提供１１２０し得る。いくつかの実施形態では、クライアントＡは、デジタル署名されたペイロード及び認証されたペイロードの両方を含む保護されたメッセージを生成し、保護されたメッセージを送信する。クライアントＢは、デジタル署名されたペイロード及び認証されたペイロード、または、いくつかの実施形態では、少なくともデジタル署名されたペイロード及び認証されたペイロードから構成された保護されたメッセージを受信１１２２し得る。

図１２は、第１のクライアント１２０２が保護されていると称するメッセージを第２のクライアント１２０４に送信し、第２のクライアントはメッセージが不適切に修正されたかどうかを検証し得ることを例示する略図１２００を示す。いくつかの実施形態では、クライアントＣ１２０４は、不適切に修正されていない保護されたメッセージであると称するメッセージを受信する。いくつかの実施形態では、メッセージは、メッセージの最初の書き手（例えばメッセージを生成した機関）によって提供１２０８され得、場合によっては、それは無関係な第三者機関（例えば、ネットワーク内のコンピュータシステムまたはルータもしくはスイッチ）であってもよい。クライアントＣは、保護されていると称するメッセージを取得１２１０し、メッセージからデジタル署名されたペイロード及び認証されたペイロードを取得し得る。保護されていると称するメッセージは、保護されたメッセージと同一の形式のものであってもよい（例えば、図１１に関連して記載されるような）−しかしながら、いくつかの実施形態では、クライアントＣは、デジタル署名及び／または認証タグが有効であることを検証していなくてもよい。

いくつかの実施形態では、保護されていると称するメッセージは、暗号文、ＡＡＤ及びＥＣＤＨの公開鍵Ｑ_Ａを含む認証されたペイロードを含む。クライアントＣは、暗号化サービス１２０６に、復号化動作を行う要求（例えばウェブＡＰＩ要求）を行い得る。クライアントＣは、要求の一部として、認証されたペイロードの暗号文、ＡＡＤ及び認証タグを提供１２１２し得る。暗号化サービスは、暗号文の復号化に用いるための暗号化鍵を選択１２１４し得る。鍵は、例えば、暗号文を復号化するのに用いられ得るクライアントマスター鍵に対応する鍵ＩＤを含む、暗号文とともに含まれるメタデータに基づいて選択され得る。暗号化鍵と鍵ＩＤは、１つまたは複数のデータベーステーブルのデータベースレコードを用いて、配列として（例えば２次元配列）、ハッシュマップで（例えば、鍵が送信者情報であり値が鍵ＩＤであるハッシュマップ）または他の適切なデータ構造で関連付けられ得る。

いくつかの実施形態では、暗号化サービスは、暗号文を復号化１２１６する。いくつかの実施形態では、暗号文は、復号化のために用いる鍵ＩＤを含むメタデータ（例えば暗号文に追加されている）を含み得る。暗号化サービスは、暗号文を、鍵ＩＤを用いて復号化し、復号化された平文を用いて、平文及び提供されたＡＡＤを用いた認証タグを生成し得る。生成されたタグと復号化要求で提供されたタグが一致しない場合、復号化は失敗し得る。復号化が成功した場合、暗号化サービスはクライアントに、復号化された平文及び、いくつかの実施形態では、復号化を行うのに用いられるクライアントマスター鍵の鍵ＩＤを戻し得る。いくつかの実施形態では、平文は、暗号化されたメッセージを復号化するのに使用可能なデータ鍵である。いくつかの実施形態では、ＡＡＤは、公開鍵Ｑ_Ａを含んで拡張され得る（例えば、鍵をＡＡＤに追加することによって）。

いくつかの実施形態では、クライアントＣ１２０４は、復号化された平文及び鍵ＩＤを暗号化サービスから復号化要求への応答として受信し得る。クライアントは、さらに、受信した鍵ＩＤを予測される鍵ＩＤに対して検証１２１８し得る。予測される鍵ＩＤは、予測される送信者に関連付けられた鍵ＩＤであってもよい。クライアントは、プロトコルまたは他の情報に基づいて、予測される送信者を判定し得る。受信した鍵ＩＤと予測される鍵ＩＤが一致しない場合、エラーが発生し得、保護されていると称するメッセージは、無効として破棄され得る。しかしながら、受信した鍵ＩＤと予測される鍵ＩＤが一致する場合、クライアントはメモリ内に、復号化されたデータ鍵を格納かつ／またはキャッシュし得る。

いくつかの実施形態では、クライアントＣは、デジタル署名されたペイロードを（例えば、保護されていると称するメッセージの一部として）受信し得る。いくつかの実施形態では、ＥＣＤＨの公開鍵Ｑ_Ａを用いて、デジタル署名されたペイロード１００８全体のデジタル署名を検証し得る。一実施形態では、公開鍵Ｑ_Ａは、復号化動作の一部として認証される拡張ＡＡＤの一部として含まれる。認証すると、公開鍵Ｑ_Ａを用いて、デジタル署名を検証１２２０し得る。デジタル署名が無効の場合、保護されていると称するメッセージは無効として破棄され得る。しかしながら、デジタル署名が有効である場合、デジタル署名されたペイロードに含まれる暗号化されたメッセージは、認証されたペイロードの復号化から取得されたデータ鍵を用いて復号化１２２２され得る。復号化が完了すると、クライアントＣは、不適切に修正されていない平文のメッセージを取得する。

図１３は、一実施形態による拡張エンベロープ暗号化スキームのもとで保護されたメッセージを生成するプロセス１３００の具体例を示す。プロセス１３００は、図８〜１２に上述したクライアントにしたがって記載されたコンピュータシステムなどの任意の適切なシステムによって行われ得る。一実施形態では、プロセス１３００を行うシステムは、秘密鍵及び公開鍵を含む非対称鍵ペアを生成１３０２し得る。いくつかの実施形態では、非対称鍵ペアは楕円曲線鍵ペアであってもよい。システムは、暗号化サービスから、エンベロープ暗号化に用いることができる暗号化データ鍵も取得１３０４し得る。データ鍵は、対称鍵であってもよい。いくつかの実施形態では、データ鍵は、非対称鍵ペアが生成されるより前に取得され得る。

いくつかの実施形態では、データ鍵を用いてメッセージを暗号化１３０６し得る。メッセージを暗号化した後で、デジタル署名は、秘密鍵を用いて、少なくとも暗号化されたメッセージ全体に生成１３０８され得る。いくつかの実施形態では、公開鍵を用いて、デジタル署名が真正なものであることを検証し得る。暗号化及びデジタル署名の生成は、例えば、図９〜１０に関連して上述した実施形態にしたがって行われ得る。いくつかの実施形態では、デジタル署名されたペイロードは、秘密鍵の暗号文（いくつかの実施形態では、暗号化を行うのに用いられるクライアントマスター鍵に関連付けられたメタデータを含む）、及び非対称秘密鍵によって生成されたデジタル署名を含み得る。

いくつかの実施形態では、追加認証データ（ＡＡＤ）が取得され得、ＡＡＤは非対称公開鍵で拡張１３１０され得る。ＡＡＤは、例えば、非対称公開鍵をＡＡＤにプリペンドまたは追加することによって、拡張され得る。いくつかの実施形態では、ＡＡＤはデータ構造であってもよく、非対称公開鍵はデータ構造内のデータ要素に挿入またはコピーされてもよい。いくつかの実施形態では、ＡＡＤは任意選択であってもよく、かつ／または、空であってもよい。

いくつかの実施形態では、データ鍵及び拡張されたＡＡＤは、認証付き暗号化を行う要求の一部として暗号化サービスに提供１３１２され得る。いくつかの実施形態では、ＡＡＤは任意選択的であってもよく、その場合には、データ鍵及び非対称公開鍵（またはデータ鍵だけ）が、認証付き暗号化を行う要求の一部として暗号化サービスに提供され得る。認証付き暗号化は、図９〜１０に関連して上述した実施形態にしたがって暗号化サービスによって行われ得る。

いくつかの実施形態では（すなわち、暗号化サービスがデータ鍵の認証付き暗号化に成功した場合）、図１３のシステムは、暗号化サービスから、データ鍵の暗号文及び拡張ＡＡＤを用いて検証することができる認証タグを受信１３１４し得る。いくつかの実施形態では、ＡＡＤは任意選択的であってもよく、その場合には、非対称公開鍵を用いて、認証タグを検証し得る。いくつかの実施形態では、図１３のシステムは、暗号文メッセージ、デジタル署名、暗号文データ鍵、拡張ＡＡＤ及び認証タグを含む保護されたメッセージを、例えば別のコンピュータシステムに送信または提供１３１６し得る。システムは、例えば、デジタル署名されたペイロード及び認証されたペイロードを含む保護されたメッセージを１つまたは複数のＴＣＰパケットで別のクライアントに送信することによって、保護されたメッセージを利用可能にし得る。

図１３に記載されたプロセス１３００の変形例も可能である。いくつかの実施形態では、システムは、ＡＡＤを公開鍵で拡張し、拡張ＡＡＤを暗号化サービスに提供し、暗号化サービスから暗号文データ鍵及び拡張ＡＡＤを用いて検証することができる認証タグを受信し得る。そうした実施形態では、暗号文データ鍵を受信する前に、またはそれと同時に、またはそれより後に、平文データ鍵も暗号化サービスから受信され得る。いくつかの実施形態では、システムは、暗号文データ鍵を受信し、暗号文データ鍵、認証タグ、ＡＡＤ及び非対称公開鍵を含む認証されたペイロードを生成し得る。いくつかの実施形態では、認証されたペイロードを生成した後で、システムは、暗号化データ鍵を取得し、データ鍵を用いて第１のメッセージの暗号文を生成し、非対称秘密鍵を用いて第１のメッセージの暗号文にデジタル署名し得る。システムは、認証されたペイロード及び第１のメッセージの暗号文に基づく第１のデジタルペイロードを含む第１の保護されたメッセージを、上述された実施形態にしたがって利用可能にし得る。システムは、第２のメッセージの暗号文もデータ鍵を用いて生成し、第２のメッセージの暗号文に非対称鍵を用いてデジタル署名し得る。次いで、システムは、第１のメッセージと同一の認証されたペイロード及び第２のメッセージの暗号文に基づく第２のデジタルペイロードを含む第２の保護されたメッセージを、上述した実施形態にしたがって利用可能にし得る。結果的に、様々な実施形態において、システムは、同一の認証されたペイロードを用いて複数の保護されたメッセージを生成し得る。

図１４は、一実施形態において、保護されたメッセージが不適切に修正されていないことを検証するプロセス１４００の具体例を示す。プロセス１４００は、図８〜１２に上述したクライアントにしたがって記載されたコンピュータシステムなどの任意の適切なシステムによって行われ得る。一実施形態では、プロセス１４００を行うシステムは、第１の暗号文、第１の暗号文全体へのデジタル署名、第２の暗号文、拡張ＡＡＤならびに第２の暗号文及び拡張ＡＡＤ全体への認証タグを含む保護されたメッセージを含む保護されたメッセージを受信１４０２し得る。保護されたメッセージは、別のコンピュータシステムによってまたは保護されたメッセージの送信に関わるルータもしくはスイッチなどの別のコンピューティングエンティティによって不適切に修正されている場合がある。

いくつかの実施形態では、システムは、暗号化サービスに、第２の暗号文、拡張ＡＡＤ及び認証タグを、第２の暗号文を復号化する要求（例えばウェブＡＰＩ要求）の一部として提供１４０４し得る。復号化は、例えば図９〜１０に関連して上述した実施形態にしたがって暗号化サービスによって行われ得る。

要求に対する応答の一部として、システムは、暗号化サービスから、第２の暗号文、拡張ＡＡＤ及び認証タグに少なくとも基づいて信頼性の表示を受信１４０６し得る。暗号文、ＡＡＤ及び／または認証タグが送信中に修正された場合のいくつかの実施形態では、失敗または無効性の表示が代わりに受信され得る。システムは、要求に対する応答の一部として、第２の暗号文の平文及び鍵ＩＤも受信１４０８し得る。平文は暗号化データ鍵を含み得る。鍵ＩＤは、暗号化サービスによって第２の暗号文を復号化するのに用いられるクライアントマスター鍵に対応し得る。いくつかの実施形態では、信頼性の表示は、平文及び鍵ＩＤが受信された後にまたはそれと同時に受信され得る。平文は、まだ難読化形式（例えば暗号化の複数の層がデータ鍵に適用される場合）であり得ることに留意されたい。

いくつかの実施形態では、システムは、受信した鍵ＩＤが予測される鍵識別子に一致することを検証１４１０し得る。予測される鍵ＩＤは、予測される送信者に関連付けられた鍵ＩＤであってもよい。クライアントは、プロトコルまたは他の情報に基づいて、予測される送信者を判定し得る。受信した鍵ＩＤと予測される鍵ＩＤが一致しない場合、エラーが発生し得、保護されたメッセージは無効として破棄され得る。システムは、この検証を、例えば、図９〜１０に関連して上述した実施形態にしたがって行い得る。いくつかの実施形態では、システムは、データ鍵を用いて第１の平文を復号化し、不適切に修正されていない平文のメッセージを取得し得る。

いくつかの実施形態では、非対称公開鍵を用いて、第１の暗号文全体のデジタル署名を検証１４１２し得る。いくつかの実施形態では、デジタル署名は、信頼性の表示が受信１４０６される前にかつ／または復号されたデータ鍵を受信する前に、検証され得る。第２の暗号文が復号化されてデータ鍵が取得された後で、システムは、第１の暗号文をデータ鍵を用いて復号化し、平文のメッセージを取得し得る。いくつかの実施形態では、暗号文は、信頼性の表示が受信１４０６される前にかつ／またはデジタル署名を検証１４１２する前に、復号化され得る。そうした実施形態では、取得された平文のメッセージは、検証ステップ完了に成功するまで使用するのに危険であるとしてマークされ得る。

本明細書中で用いる用語「秘密鍵」及び「公開鍵」とは、それぞれ、非対称暗号化（「公開鍵暗号化」）の一部として用いられる秘密鍵及び公開鍵を指すのに用いられ得る。非対称暗号化とは、秘密鍵と公開鍵が数学的にリンクされ得る暗号化プロトコルのクラスを指す。公開鍵暗号化では、機関が共有秘密鍵を共有する必要はない。むしろ、公開鍵は公開されてもよく、一般に利用可能であってもよく（信頼できない機関にも）、一方、秘密鍵は、信頼できない機関に暴露されるべきではない。（対応する秘密鍵と公開鍵の）鍵ペアは、暗号化動作を行うのに用いられ得る。例えば、公開鍵を用いて、平文メッセージを暗号化して暗号文をもたらし得、対応する秘密鍵を用いて、暗号文を復号化して元の平文メッセージをもたらし得る。第２の例として、秘密鍵を用いて、メッセージを認証するデジタル署名を生成し得、対応する公開鍵を用いて、デジタル署名が正しくしたがってメッセージは真正なものであることを検証し得る。

図１５は、様々な実施形態による態様を実装するための例示的な環境１５００の態様を示す。理解されるように、ウェブベースの環境が説明の目的のために使用されるが、多様な実施形態を実装するために様々な環境が必要に応じて使用され得る。環境は、電子クライアントデバイス１５０２を含み、該電子クライアントデバイスは、要求、メッセージまたは情報を適切なネットワーク１５０４を介して送信及び／または受信し、いくつかの実施形態では、デバイスのユーザに情報を伝達して戻すのに動作可能である任意の適切なデバイスを含み得る。係るクライアントデバイスの例には、パーソナルコンピュータ、携帯電話、ハンドヘルドメッセージングデバイス、ラップトップコンピュータ、タブレットコンピュータ、セットトップボックス、パーソナルデータアシスタント、組込み型コンピュータシステム、電子ブックリーダー等が挙げられる。ネットワークは、イントラネット、インターネット、セルラーネットワーク、ローカルエリアネットワーク、衛星ネットワークもしくは任意の他の係るネットワーク及び／またはその組合せを含む任意の適切なネットワークを含み得る。係るシステムのために使用される構成要素は、選択されるネットワーク及び／または環境の種類に少なくとも部分的に依存することがある。係るネットワークを介して通信するための多くのプロトコル及び構成要素は周知であり、本明細書において詳細に説明されない。ネットワークを介する通信は、有線接続または無線接続及びそれらの組合せによって可能にされることがある。この例では、環境は要求を受信し、要求に応えてコンテンツを提供するためのウェブサーバ１５０６を含むので、ネットワークはインターネット及び／または他のパブリックにアドレス指定可能な通信ネットワークを含むが、他のネットワークの場合、当業者に明白であるように、同様の目的を果たす代替のデバイスが使用できるだろう。

例示的な環境には、少なくとも１つのアプリケーションサーバ１５０８及びデータストア１５１０が含まれる。適切なデータストアからデータを取得する等のタスクを実行するように、連結またはそれ以外の方法で構成され得、そのように相互作用することができる、複数のアプリケーションサーバ、層もしくは他の要素、プロセス、または構成要素が存在し得ることが理解されるべきである。本明細書中で用いるようなサーバは、ハードウェアデバイスまたは仮想コンピュータシステムなどの様々に実装され得る。状況によっては、サーバとは、コンピュータシステム上で実行されているプログラミングモジュールを指し得る。本明細書で使用される「データストア」という用語は、それ以外に記述されまたは文脈から明らかでない限り、データを記憶し、データにアクセスし、かつデータを取得することができる任意のデバイスまたはデバイスの組み合わせを指し、任意の標準、分散型、仮想またはクラスタ化環境において、任意の組み合わせ及び任意の数のデータサーバ、データベース、データ記憶デバイス及びデータ記憶媒体を含み得る。アプリケーションサーバは、必要に応じてデータストアと統合してクライアントデバイスのための１つまたは複数のアプリケーションの態様を実行し、データアクセス及びアプリケーションのためのビジネスロジックの一部または全部を処理するための任意の適切なハードウェア、ソフトウェア及びファームウェアを含むことがある。アプリケーションサーバは、データストアと協働してアクセス制御サービスを提供し得、以下に限定するものではないが、テキスト、グラフィックス、音声、ビデオ及び／またはユーザに提供されるのに使用可能である他のコンテンツを含むコンテンツを生成することができ、該コンテンツは、ハイパーテキストマークアップ言語（「ＨＴＭＬ」）、拡張マークアップ言語（「ＸＭＬ」）、ＪａｖａＳｃｒｉｐｔ（登録商標）、カスケーティングスタイルシート（「ＣＳＳ」）、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）及び／または別の適切なクライアント側構造化言語の形でウェブサーバによってユーザに提供されてよい。クライアントデバイスに転送されるコンテンツは、クライアントデバイスによって処理されて、以下に限定されるものではないが、ユーザに聴覚的に、視覚的にかつ／または他の感覚を通して知覚される形式を含む１つまたは複数の形式でコンテンツを提供し得る。全ての要求および応答の処理、ならびにクライアントデバイス１５０２とアプリケーションサーバ１５０８の間のコンテンツの送達は、ウェブサーバによって、ＰＨＰ：ハイパーテキストプリプロセッサ（「ＰＨＰ」）、Ｐｙｔｈｏｎ、Ｒｕｂｙ、Ｐｅｒｌ、Ｊａｖａ（登録商標）、ＨＴＭＬ、ＸＭＬ、ＪＳＯＮ及び／またはこの例では別の適切なサーバ側構造化言語を用いて処理することができる。さらに、単一のデバイスで行われているとして本明細書中に記載された動作は、文脈からそれ以外に明確ではない限り、分散型かつ／または仮想システムを形成し得る複数のデバイスによって集団で行われ得る。

データストア１５１０は、複数の別々のデータテーブル、データベース、データドキュメント、動的データストレージスキーム及び／または他のデータストレージ機構、及び本開示の特定の態様に関するデータを記憶するための媒体を含み得る。例えば、例示されるデータストアとしては、生産側にコンテンツを提供するために使用することができる生産データ１５１２及びユーザ情報１５１６を記憶するための機構が含まれ得る。また、データストアは、報告、分析または他の係る目的のために使用することができるログデータ１５１４を記憶するための機構を含むと示される。ページの画像情報及びアクセス権情報等、データストアに記憶する必要があり得る多数の他の態様が存在し得、これは、必要に応じて上に列挙された機構のいずれか、またはデータストア１５１０内の追加の機構に記憶することができることを理解されるべきである。データストア１５１０は、データストアと関連付けられたロジックを通して、アプリケーションサーバ１５０８から命令を受信し、命令に応えてデータを入手、更新またはそれ以外の場合処理するよう作動可能である。アプリケーションサーバ１５０８は、受信した命令に応えて、静的データ、動的データ、または静的データ及び動的データの組み合わせを提供し得る。ウェブログ（ブログ）で用いられるデータなどの動的データ、ショッピングアプリケーション、ニュースサービス及び他のそうしたアプリケーションは、本明細書中で記載されたようなサーバ側構造化言語によって生成され得、または、アプリケーションサーバ上でまたはその制御下で動作するコンテンツ管理システム（「ＣＭＳ」）によって提供され得る。一例では、ユーザは、ユーザが動作させるデバイスを通して、特定のタイプの項目に対する検索要求を送信する可能性がある。この場合、データストアは、ユーザ情報にアクセスしてユーザの識別を検証する可能性があり、そのタイプの項目についての情報を入手するためにカタログ詳細情報にアクセスすることができる。情報は、次いでユーザがユーザーデバイス１５０２でブラウザを介して見ることができるウェブページ上の結果リストで等、ユーザに戻すことができる。関心のある特定の項目の情報は、ブラウザの専用ページまたはウィンドウ内で見ることができる。しかしながら、本開示の実施形態は必ずしもウェブページの文脈に限定されるものではなく、より一般に要求が必ずしもコンテンツのための要求ではない一般的な処理要求に適用可能であってもよいことに留意されるべきである。

各サーバは、通常、そのサーバの一般的な管理及び操作のための実行可能なプログラム命令を提供するオペレーティングシステムを含み、通常、サーバのプロセッサによって実行されると（すなわち実行された結果として）、サーバがその意図される機能を実行できるようにする命令を記憶するコンピュータ可読記憶媒体（例えば、ハードディスク、ランダムアクセスメモリ、読出し専用メモリ等）を含む。

一実施形態における環境は、１つまたは複数のコンピュータネットワークもしくは直接接続を使用し、通信リンクを介して相互接続されるいくつかのコンピュータシステム及び構成要素を利用する、分散型かつ／または仮想コンピューティング環境である。しかしながら、係るシステムは、図１５に示されるよりも少ない数または多い数の構成要素を有するシステムにおいて同等に良好に動作し得ることが当業者によって理解される。したがって、図１５のシステム１５００の描写は、本質的に例示であり、本開示の範囲を限定するものではないと見なされるべきである。

さらに、本開示の実施形態は、以下の条項を鑑みて説明できる。
１．コンピュータによって実装される方法であって、
実行可能命令で構成される１つまたは複数のコンピュータシステムの制御下で、
暗号保護された通信セッションを確立するハンドシェイクプロトコルの一部として、送信者識別情報及び第１の非対称公開鍵を備える第１のメッセージを取得することであって、前記第１の非対称公開鍵及び対応する第１の非対称秘密鍵は、前記暗号保護された通信セッションを介して通信するクライアントによってサポートされる、前記取得することと、
暗号化サービスに、前記第１のメッセージ、鍵識別子及び前記第１のメッセージに対応する第１の認証されたメッセージを生成する命令を提供することであって、前記第１の認証されたメッセージは、検証するために前記第１の認証されたメッセージを前記暗号化サービスに提供する前記クライアントによって検証することができる、前記提供することと、
前記暗号化サービスから、前記第１のメッセージに対応する前記第１の認証されたメッセージを受信することと、
前記ハンドシェイクプロトコルの一部として前記クライアントに前記第１の認証されたメッセージを提供することと、
前記クライアントから第２の認証されたメッセージを受信することであって、前記認証されたメッセージは少なくとも第２の送信者識別情報及び第２の非対称公開鍵を備える、前記受信することと、
前記暗号化サービスを用いて、前記第２の認証されたメッセージの信頼性を検証することと、
前記暗号化サービスから、前記第２の認証されたメッセージが真正なものであるという表示を受信することと、
前記ハンドシェイクプロトコルの一部として、共有秘密鍵を、少なくとも前記第２の非対称公開鍵及び前記第１の非対称秘密鍵を用いて生成することと、
少なくとも部分的に前記共有秘密鍵を用いて、前記クライアントとの間に前記暗号保護された通信セッションを確立することであって、前記共有秘密鍵も前記クライアントによって判定可能である、前記確立することとを備える、前記方法。

２．前記第１の非対称公開鍵が楕円曲線公開鍵Ｑ_Ａであり、前記対応する秘密鍵が対応する楕円曲線秘密鍵ｄ_Ａであり、前記第２の非対称公開鍵が楕円曲線公開鍵Ｑ_Ｂであり、かつ、前記共有秘密鍵が、ｄ_ＡとＱ_Ｂの楕円曲線点乗算の計算に部分的に基づいて生成される、条項１に記載のコンピュータによって実装される方法。

３．前記第１のメッセージに対応する前記第１の認証されたメッセージを生成する前記命令が、前記暗号化サービスへの、前記第１のメッセージに少なくとも部分的に基づくメッセージ認証コード（ＭＡＣ）タグを生成する要求を備え、
前記第１の認証されたメッセージが、前記第１のメッセージ及び前記第１のメッセージに少なくとも部分的に基づく前記ＭＡＣタグを備える、条項１または２に記載のコンピュータによって実装される方法。

４．前記暗号保護された通信セッションがトランスポート層セキュリティ（ＴＬＳ）セッションである、条項１〜３のいずれかに記載のコンピュータによって実装される方法。

５．１つまたは複数のプロセッサと、
前記１つまたは複数のプロセッサによって実行された結果として、前記システムが、
暗号化サービスから、公開鍵と送信者識別の結びつきが真正なものであるという表示を取得し、
ハンドシェイクプロトコルの一部として、前記送信者識別に結びつけられた前記公開鍵及び前記結びつきが真正なものであるという前記表示をクライアントに提供し、
前記クライアントから、第２の公開鍵を受信し、
少なくとも秘密鍵及び前記第２の公開鍵を用いて共有秘密鍵を生成し、
前記共有秘密鍵を用いて、前記クライアントとの間に暗号保護された通信セッションを確立する実行可能命令を格納するメモリとを備える、システム。

６．前記第２の公開鍵が、第２の結びつきを通して、第２の送信者識別及び前記暗号化サービスによって暗号学的に検証可能である第２の表示に結びつけられ、
前記命令によって、さらに、前記システムが、
前記暗号化サービスを用いて、前記第２の結びつきが真正なものであることを検証し、
前記第２の結びつきが真正なものであることの検証の成功に応えて、前記共有秘密鍵を生成する、条項５に記載のシステム。

７．前記非対称鍵ペアが、楕円曲線公開鍵Ｑ_Ａ及び対応する楕円曲線秘密鍵ｄ_Ａを備える楕円曲線鍵ペアであり、前記第２の公開鍵が楕円曲線公開鍵Ｑ_Ｂであり、かつ、前記共有秘密鍵が、ｄ_ＡとＱ_Ｂの楕円曲線点乗算の計算に部分的に基づいて生成される、条項５または６に記載のシステム。

８．前記システムが、前記公開鍵及び前記送信者識別を含むメッセージを少なくとも生成することによって、前記公開鍵を前記送信者識別に結びつけ、
前記システムが、鍵識別子を取得し前記暗号化サービスに前記鍵識別子に関連付けられた暗号化鍵を用いて前記メッセージ全体にメッセージ認証コード（ＭＡＣ）タグを生成することを要求することによって、前記結びつきが真正なものであるという前記表示を取得し、
前記第２の表示が第２のＭＡＣタグを含み、
前記第２の結びつきが真正なものであることを前記検証することが、前記暗号化サービスに前記第２のＭＡＣタグ及び前記第２の結びつきを提供することを備える、条項６に記載のシステム。

９．前記システムが前記公開鍵を前記送信者識別に結びつけることが、前記公開鍵及び前記送信者識別を含むメッセージを生成することを含み、
前記システムが、前記結びつきが真正なものであるという前記表示を、鍵識別子を取得し前記暗号化サービスに前記鍵識別子に関連付けられた暗号化鍵を用いて前記メッセージを暗号化することを要求することによって取得し、
前記第２の表示が暗号文を含み、
前記システムが、さらに、前記第２の結びつきが真正なものであることを検証するために、
前記暗号化サービスに、復号化する前記暗号文を提供し、
前記暗号化サービスから、暗号文に対応する平文及び第２の鍵識別子を受信し、
前記第２の鍵識別子が前記クライアントに関連付けられていることを判定する命令を含む、条項６に記載のシステム。

１０．前記メッセージがさらにノンスを含み、
前記システムが、さらに、前記第２の結びつきが真正なものであることを検証するために、前記暗号文に対応する前記平文が前記ノンスを含むことを判定する命令を含む、条項９に記載のシステム。

１１．前記命令によって、さらに、前記システムが、前記暗号保護された通信セッションを確立した後で、データを取得し、前記秘密鍵を用いて前記データ全体にデジタル署名を生成し、前記クライアントに前記暗号保護された通信セッションを介して前記データ及び前記デジタル署名を送信する、条項５〜１０のいずれかに記載のシステム。

１２．前記暗号保護された通信セッションがトランスポート層セキュリティ（ＴＬＳ）セッションである、条項５〜１１のいずれかに記載のシステム。

１３．コンピュータシステムの１つまたは複数のプロセッサによって実行された結果として、前記コンピュータシステムが、少なくとも、
秘密鍵及び公開鍵を備える非対称鍵ペアを取得し、
ハンドシェイクの一部として、クライアントに前記公開鍵を提供し、
前記クライアントから、第２の結びつきを介して第２の送信者識別及び第２の表示に結びつけられた第２の公開鍵を受信し、前記第２の表示は暗号化サービスによって暗号学的に検証可能なものであり、
前記暗号化サービスを用いて、前記第２の結びつきが真正なものであることを検証し、
前記第２の結びつきが真正なものであると判定したことに応えて、少なくとも前記秘密鍵及び前記第２の公開鍵を用いて共有秘密鍵を生成し、
前記クライアントとの間に暗号保護された通信セッションを確立する実行可能命令が格納された非一時的なコンピュータ可読記憶媒体。

１４．前記実行可能命令によって、さらに、前記コンピュータシステムが、
前記暗号化サービスから、前記公開鍵と送信者識別の結びつきが真正なものであるという表示を取得し、
ハンドシェイクプロトコルの一部として、前記結びつきが真正なものであるという前記表示をクライアントに提供し、
前記クライアントに提供された前記公開鍵は前記送信者識別に結びつけられている、条項１３に記載の非一時的なコンピュータ可読記憶媒体。

１５．前記非対称鍵ペアが、楕円曲線公開鍵Ｑ_Ａ及び対応する楕円曲線秘密鍵ｄ_Ａを備える楕円曲線鍵ペアであり、前記第２の非対称公開鍵が楕円曲線公開鍵Ｑ_Ｂである、条項１３または１４に記載の非一時的なコンピュータ可読記憶媒体。

１６．前記システムが前記公開鍵を前記送信者識別に結びつけることが、前記公開鍵及び前記送信者識別を含むメッセージを生成することを含み、
前記システムが、鍵識別子を取得し前記暗号化サービスに前記鍵識別子に関連付けられた暗号化鍵を用いて前記メッセージ全体にメッセージ認証コード（ＭＡＣ）タグを生成することを要求する命令を介して、前記結びつきが真正なものであるという前記表示を取得し、
前記第２の表示が第２のＭＡＣタグを含み、
前記システムが、前記暗号化サービスに前記第２のＭＡＣタグ及び前記第２の結びつきを提供する命令を介して、前記第２の結びつきが真正なものであることを検証する、条項１４に記載の非一時的なコンピュータ可読記憶媒体。

１７．前記公開鍵を前記送信者識別に結びけることが、前記公開鍵及び前記送信者識別を含むメッセージを生成することを含み、
前記結びつきが真正なものであるという前記表示を取得することが、鍵識別子を取得し前記暗号化サービスに前記鍵識別子に関連付けられた暗号化鍵を用いて前記メッセージを暗号化することを要求することを備え、
前記第２の表示が暗号文を含み、
前記第２の結びつきが真正なものであることを前記検証することが、
前記暗号化サービスに、復号化する前記暗号文を提供することと、
前記暗号化サービスから、暗号文に対応する平文及び第２の鍵識別子を受信することと、
前記第２の鍵識別子が前記クライアントに関連付けられていることを判定することとを備える、条項１４に記載の非一時的なコンピュータ可読記憶媒体。

１８．前記メッセージがさらにタイムスタンプを含み、
前記第２の結びつきが真正なものであることを前記検証することが、さらに、前記暗号文に対応する前記平文が前記タイムスタンプを含むことを判定することを含む、条項１７に記載の非一時的なコンピュータ可読記憶媒体。

１９．前記暗号化要求が認証付き暗号化要求である、条項１４に記載の非一時的なコンピュータ可読記憶媒体。

２０．前記暗号保護された通信セッションがトランスポート層セキュリティ（ＴＬＳ）セッションである、条項１３〜１９のいずれかに記載の非一時的なコンピュータ可読記憶媒体。

２１．第１のコンピュータシステムであって、
第１の１つまたは複数のプロセッサ、及び
前記第１の１つまたは複数のプロセッサによって実行された結果として、前記第１のコンピュータシステムが、
暗号化データ鍵を取得し、前記データ鍵を用いて少なくともメッセージを暗号化することによって、前記メッセージに少なくとも部分的に基づく第１の暗号文を生成し、
前記第１の暗号文ならびに少なくとも前記第１の暗号文及び秘密鍵を用いて生成されたデジタル署名を含むデジタル署名されたペイロードを生成し、
前記データ鍵に少なくとも部分的に基づく第２の暗号文、前記秘密鍵に対応する公開鍵、ならびに少なくとも前記データ鍵及び前記公開鍵を含むデータを用いて検証可能な認証タグを含む認証されたペイロードを取得する実行可能命令を格納する第１のメモリを備える、前記第１のコンピュータシステムと、
第２のコンピュータシステムであって、
第２の１つまたは複数のプロセッサ、及び
前記第２の１つまたは複数のプロセッサによって実行された結果として、前記第２のコンピュータシステムが、
前記デジタル署名されたペイロード及び前記認証されたペイロードを受信し、
少なくとも前記第２の暗号文、前記公開鍵及び前記認証タグに少なくとも基づいて前記データ鍵及び鍵識別子を取得し、
前記鍵識別子が前記第１のコンピュータシステムに関連付けられた予測される鍵識別子に一致すること及び前記デジタル署名が有効であることを検証し、
前記データ鍵を用いて前記第１の暗号文を復号化することによって、前記メッセージを取得する実行可能命令を格納する第２のメモリを備える、前記第２のコンピュータシステムとを備えるシステム。

２２．前記第２の暗号文を取得することが、さらに、追加認証データに基づくものであり、
前記生成された認証されたペイロードが、さらに、前記追加認証データを含み、
前記データ鍵及び前記鍵識別子を取得することが、さらに、前記追加認証データに基づくものである、条項２１に記載のシステム。

２３．前記第１の暗号文を生成することが、少なくとも前記メッセージ及び前記公開鍵を暗号化することに基づき、
前記第２のメモリが、さらに、前記第２のコンピュータシステムに、前記公開鍵を少なくとも前記第２の暗号文及び前記認証タグに基づいて取得させる実行可能命令を格納する、条項２１または２２に記載のシステム。

２４．前記秘密鍵が楕円曲線秘密鍵であり、前記公開鍵が楕円曲線公開鍵である、条項２１〜２３のいずれかに記載のシステム。

２５．実行可能命令で構成された１つまたは複数のコンピュータシステムの制御下で、
暗号化データ鍵を取得し、前記データ鍵を用いて少なくともメッセージを暗号化することによって、前記メッセージに少なくとも部分的に基づく第１の暗号文を生成することと、
非対称秘密鍵を用いて、前記第１の暗号文に少なくとも部分的に基づいてデジタル署名を生成することと、
少なくとも前記第１の暗号文及び前記デジタル署名を含むデジタル署名されたペイロードを生成することと、
暗号化サービスに、少なくとも前記暗号化データ鍵及び前記非対称秘密鍵に対応する非対称公開鍵を提供することによって、認証付き暗号化を要求することであって、少なくとも前記暗号化データ鍵は暗号化されるとして示される、前記要求することと、
前記認証付き暗号化の要求に応えて、第２の暗号文及び認証タグを受信することと、
少なくとも前記第２の暗号文、前記非対称公開鍵及び前記認証タグを含む認証されたペイロードを生成することと、
別のコンピュータシステムに、少なくとも前記デジタル署名されたペイロード及び前記認証されたペイロードを利用可能にすることとを含む、コンピュータによって実装される方法。

２６．前記認証付き暗号化を要求することが、さらに追加認証データを提供することを含み、
前記認証されたペイロードが、さらに前記追加認証データを含む、条項２５に記載のコンピュータによって実装される方法。

２７．前記非対称秘密鍵が楕円曲線秘密鍵であり、前記非対称公開鍵が楕円曲線公開鍵である、条項２５または２６に記載のコンピュータによって実装される方法。

２８．前記認証付き暗号化を要求するのにウェブＡＰＩ要求が用いられる、条項２５〜２７のいずれかに記載のコンピュータによって実装される方法。

２９．前記暗号化サービスに前記認証付き暗号化を行うことを要求することが、さらに、前記非対称公開鍵が暗号化されることを示すことを含む、条項２５〜２８のいずれかに記載のコンピュータによって実装される方法。

３０．前記認証付き暗号化を要求することが、さらに、ノンスを提供することを含む、条項２６に記載のコンピュータによって実装される方法。

３１．前記認証付き暗号化がＡＥＳ−ＣＣＭまたはＡＥＳ−ＧＣＭ暗号化である、条項３０に記載のコンピュータによって実装される方法。

３２．１つまたは複数のＴＣＰパケットで前記デジタル署名されたペイロード及び前記認証されたペイロードを送信することによって、少なくとも前記デジタル署名されたペイロード及び前記認証されたペイロードが利用可能になされた、条項２５〜３１のいずれかに記載のコンピュータによって実装される方法。

３３．前記暗号化サービスから前記暗号化データ鍵を取得するのに、ウェブＡＰＩ要求が用いられる、条項２５〜３２のいずれかに記載のコンピュータによって実装される方法。

３４．コンピュータシステムの１つまたは複数のプロセッサによって実行された結果として、前記コンピュータシステムが、少なくとも、
第１の暗号文及び前記第１の暗号文全体へのデジタル署名をさらに備えるデジタル署名されたペイロード、及び
第２の暗号文、非対称公開鍵及び認証タグをさらに備える認証されたペイロードを備える保護されたメッセージを受信し、
暗号化サービスに、少なくとも前記第２の暗号文、前記非対称公開鍵及び前記認証タグを提供することによって、前記第２の暗号文の認証付き復号化を要求し、
前記認証付き復号化の要求に応えて、少なくとも暗号化データ鍵及び鍵識別子を受信し、
前記鍵識別子が予測されるクライアントに関連付けられた予測される鍵識別子に一致すること及び前記デジタル署名されたペイロードの前記デジタル署名が有効であることを検証し、
前記暗号化データ鍵を用いて、前記デジタル署名されたペイロードの前記第１の暗号文を復号化することによってメッセージを取得する実行可能命令を格納する非一時的なコンピュータ可読記憶媒体。

３５．前記非対称公開鍵が楕円曲線公開鍵である、条項３４に記載の非一時的なコンピュータ可読記憶媒体。

３６．前記保護されたメッセージが、さらに、前記非対称公開鍵を備える、条項３４または３５に記載の非一時的なコンピュータ可読記憶媒体。

３７．前記認証付き復号化を要求するのにウェブＡＰＩ要求が用いられる、条項３４〜３６のいずれかに記載の非一時的なコンピュータ可読記憶媒体。

３８．前記命令が、さらに、前記１つまたは複数のプロセッサによって実行された結果として、前記コンピュータシステムに、前記認証付き復号化の要求に応えて、少なくとも前記暗号化データ鍵、前記非対称公開鍵及び前記鍵識別子を受信させる命令をさらに備える、条項３４〜３７のいずれかに記載の非一時的なコンピュータ可読記憶媒体。

３９．前記暗号化データ鍵が対称暗号化鍵である、条項３４〜３８のいずれかに記載の非一時的なコンピュータ可読記憶媒体。

４０．前記デジタル署名が検証された後で、前記メッセージが取得され、
少なくとも前記暗号化データ鍵及び前記鍵識別子を受信した後で、前記デジタル署名が検証され、
前記鍵識別子が予測されるクライアントに関連付けられた前記予測される鍵識別子と一致することを検証した後で、前記デジタル署名が検証される、条項３４〜３９のいずれかに記載の非一時的なコンピュータ可読記憶媒体。

４１．前記保護されたメッセージが１つまたは複数のＴＣＰパケットの一部として受信される、条項３４〜４０のいずれかに記載の非一時的なコンピュータ可読記憶媒体。

多様な実施形態は、多種多様な動作環境でさらに実装することができ、該動作環境は場合によっては、いくつかのアプリケーションのいずれかを操作するために使用できる１つまたは複数のユーザーコンピュータ、コンピューティング装置または処理装置を含むことがある。ユーザーデバイスまたはクライアントデバイスは、標準オペレーティングシステムを実行するデスクトップ、ラップトップまたはタブレットコンピュータ等のいくつかのコンピュータのいずれか、ならびに携帯電話向けソフトウェアを実行し、かついくつかのネットワーキングプロトコル及びメッセージプロトコルをサポートできる、セルラーデバイス、無線デバイス及びハンドヘルドデバイスを含むことがある。係るシステムは、さまざまな市販のオペレーティングシステムならびに開発及びデータベース管理等の目的のための他の既知のアプリケーションのいずれかを実行するいくつかのワークステーションを含むこともある。これらのデバイスは、ダミー端子、シンクライアント、ゲーム機、及びネットワークを介して通信することができる他のデバイス等の、他の電子デバイスもまた含み得る。これらのデバイスは、仮想マシン、ハイパーバイザ及びネットワークを介する通信が可能である他の仮想デバイスなどの仮想デバイスも含み得る。

本開示の様々な実施形態は、伝送制御プロトコル／インターネットプロトコル（「ＴＣＰ／ＩＰ」）、ユーザデータグラムプロトコル（「ＵＤＰ」）、オープンシステムインターコネクション（「ＯＳＩ」）モデルの様々な層で動作するプロトコル、ファイル転送プロトコル（「ＦＴＰ」）、ユニバーサルプラグアンドプレイ（「ＵｐｎＰ」）、ネットワークファイルシステム（「ＮＦＳ」）、共通インターネットファイルシステム（「ＣＩＦＳ」）、及びＡｐｐｌｅＴａｌｋ等のさまざまな市販のプロトコルのいずれかを使用し、通信をサポートするための当業者によく知られているだろう少なくとも１つのネットワークを活用する。ネットワークは、例えば、ローカルエリアネットワーク、広域ネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、無線ネットワーク、衛星ネットワーク及びその任意の組合せであることがある。いくつかの実施形態では、コネクション型のプロトコルを用いて、ネットワークエンドポイント間で通信し得る。コネクション型のプロトコル（場合によってはコネクションベースのプロトコルと呼ばれる）は、順序付けられたストリームでデータを送信可能である。コネクション型のプロトコルは、信頼できるものであり得、または信頼できないものであり得る。例えば、ＴＣＰプロトコルは信頼できるコネクション型のプロトコルである。非同期転送モード（「ＡＴＭ」）及びフレームリレーは、信頼できないコネクション型のプロトコルである。コネクション型のプロトコルは、パケットを保証された順序付けなしで送信するＵＤＰなどのパケット型のプロトコルとは多いに異なる。

ウェブサーバを利用する実施形態では、ウェブサーバは、ハイパーテキスト転送プロトコル（「ＨＴＴＰ」）サーバ、ＦＴＰサーバ、共通ゲートウェイインタフェース（「ＣＧＩ」）サーバ、データサーバ、Ｊａｖａサーバ、Ａｐａｃｈｅサーバ及びビジネスアプリケーションサーバを含むさまざまなサーバまたは中間層アプリケーションのいずれかを実行できる。また、サーバ（複数可）はＪａｖａ（登録商標）、Ｃ、Ｃ＃、もしくはＣ＋＋等の任意のプログラミング言語、またはＲｕｂｙ、ＰＨＰ、Ｐｅｒｌ、Ｐｙｔｈｏｎ、もしくはＴＣＬ等の任意のスクリプト言語、ならびにその組合せで書かれた１つまたは複数のスクリプトまたはプログラムとして実装されてよい１つまたは複数のウェブアプリケーションを実行することによって等、ユーザーデバイスからの要求に応えてプログラムまたはスクリプトを実行可能でもあり得る。また、サーバ（複数可）は、Ｏｒａｃｌｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｓｙｂａｓｅ（登録商標）及びＩＢＭ（登録商標）から市販されているものならびにＭｙＳＱＬ、Ｐｏｓｔｇｒｅｓ、ＳＱＬｉｔｅ、ＭｏｎｇｏＤＢ及び構造化データまたは非構造化データの格納、取得かつアクセスが可能である任意の他のサーバ等のオープンソースサーバを含むがこれらに制限されないデータベースサーバを含んでもよい。データベースサーバには、テーブルベースのサーバ、ドキュメントベースのサーバ、非構造化サーバ、リレーショナルサーバ、非リレーショナルサーバ、またはこれらのかつ／または他のデータベースサーバの組み合わせが含まれ得る。

環境は、上述のさまざまなデータストアならびに他のメモリ及び記憶媒体を含むことがある。これらは、コンピュータの１つまたは複数にローカルな（かつ／またはそこに常駐する）またはネットワーク全体でのコンピュータのいずれかまたはすべてから遠く離れた記憶媒体上等のさまざまな場所に常駐することがある。実施形態の特定の一式では、情報は、当業者によく知られているストレージエリアネットワーク（「ＳＡＮ」）に常駐することがある。同様に、コンピュータ、サーバ、または他のネットワークデバイスによる機能を実行するためのあらゆる必要なファイルは、必要に応じてローカルにかつ／または遠隔に記憶されてよい。システムがコンピュータ化デバイスを含む場合、係るそれぞれのデバイスはバスを介して電気的に結びつきされてよいハードウェア要素を含むことがあり、該要素は、例えば、少なくとも１つの中央演算処理装置（「ＣＰＵ」または「プロセッサ」）、少なくとも１つの入力装置（例えば、マウス、キーボード、コントローラ、タッチスクリーンまたはキーパッド）及び少なくとも１つの出力装置（例えば、表示装置、プリンタまたはスピーカ）を含むことがある。また、係るシステムは、ディスクドライブ、光学式記憶デバイス等の１つまたは複数の記憶装置、及びランダムアクセスメモリ（「ＲＡＭ」）または読出し専用メモリ（「ＲＯＭ」）等のソリッドステート記憶装置、ならびに取り外し可能な媒体デバイス、メモリカード、フラッシュカード等を含んでもよい。

また、係るデバイスは、上述のようにコンピュータ可読記憶媒体読取り装置、通信装置（例えば、モデム、ネットワークカード（無線または有線）、赤外線通信装置等）、及び作業メモリを含むこともある。コンピュータ可読記憶媒体読取り装置は、遠隔記憶装置、ローカル記憶装置、固定記憶装置、及び／または取外し可能な記憶装置を表すコンピュータ可読記憶媒体、ならびにコンピュータ可読情報を一時的にかつ／またはより恒久的に含む、記憶する、伝送する、及び取り出すための記憶媒体と接続できる、またはそれらを受け取るように構成できる。また、システム及び多様なデバイスは、通常、クライアントアプリケーションもしくはウェブブラウザ等のオペレーティングシステム及びアプリケーションプログラムを含む、いくつかのソフトウェアアプリケーション、モジュール、サービス、または、少なくとも１つの作業用メモリデバイスの中に位置する他の要素を含む。さらに、カスタマイズされたハードウェアが使用される可能性もある、かつ／または特定の要素がハードウェア、（アプレット等のポータブルソフトウェアを含む）ソフトウェア、または両方で実装される可能性もある。さらに、ネットワーク入力／出力装置等の、他のコンピューティングデバイスへの接続が用いられてよい。

コードまたはコードの一部を含むための記憶媒体及びコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、電子的消去プログラム可能型読取専用メモリ（「ＥＥＰＲＯＭ」）、フラッシュメモリ、もしくは他のメモリ技術、コンパクトディスクリードオンリーメモリ（「ＣＤ−ＲＯＭ」）、デジタル多用途ディスク（ＤＶＤ）、もしくは他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスク記憶装置、もしくは他の磁気記憶装置、または所望の情報を記憶するために使用することができ、かつシステムデバイスによってアクセスできる任意の他の媒体を含む、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータ等の情報の記憶及び／または伝送のために任意の方法または技術で実装される揮発性及び不揮発性の媒体、取外し可能及び取外しできない媒体等であるが、これに限定されるものではない記憶媒体及び通信媒体を含む当該術において既知の、または使用される任意の適切な媒体を含むことがある。本開示及び本明細書に示される教示に基づいて、当業者は多様な実施形態を実装するための他の手法及び／または方法を理解するであろう。

したがって、明細書及び図面は、限定的な意味ではなく例示的な意味で考えられるべきである。しかしながら、特許請求の範囲で述べられる本発明のより広い精神及び範囲から逸脱することなく、それに様々な修正及び変更がなされ得るということが明らかであろう。

他の変形形態は、本開示の精神の範囲内である。したがって、開示された技術は多様な修正形態及び代替構成の影響を受けやすいが、その特定の示される実施形態は図面に示され、上記に詳細に説明されている。しかしながら、本発明を特定の形式または開示される形式に限定する意図はなく、しかし、逆に、意図は、添付の特許請求の範囲において定義される本発明の精神及び範囲内に収まる、全ての修正、代替構造、及び等価物を網羅することであるということが理解されるべきである。

開示される実施形態を説明する文脈における（特に以下の特許請求の範囲の文脈における）用語「ａ」、「ａｎ」、及び「ｔｈｅ」ならびに同様の指示語の使用は、本明細書において別段の指示がない限り、または文脈に明らかに矛盾するものでない限り、単数及び複数の双方を網羅すると解釈される。用語「ｃｏｍｐｒｉｓｉｎｇ（備える）」、「ｈａｖｉｎｇ（有する）」及び「ｃｏｎｔａｉｎｉｎｇ（含む）」は、別段の記述がない限り、オープンエンド用語（すなわち「ｉｎｃｌｕｄｉｎｇ，ｂｕｔ ｎｏｔ ｌｉｍｉｔｅｄ ｔｏ，（を含むが、これらに限定されるものではない）」を意味する）として解釈される。用語「ｃｏｎｎｅｃｔｅｄ（接続された）」は、修飾されず物理的な接続を指すとき、たとえ介在するものがあっても部分的にまたは完全に、中に含まれる、取り付けられる、または互いに結びつきされるとして解釈される。本明細書での値の範囲の列挙は、本明細書に別段の指示がない限り、単に、範囲内に入るそれぞれの別個の値に個別に言及する短縮方法としての役割を果たすことが意図され、各個別の値は、それが個別に本明細書に記載されているかのように本明細書に組み込まれる。用語「ｓｅｔ（セット）」（例えば「アイテムのセット」）または「ｓｕｂｓｅｔ（サブセット）」の使用は、それ以外に記述されるか文脈によって矛盾しない限り、１つまたは複数のメンバーを備える非空のコレクションとして解釈される。さらに、それ以外に記述されるか文脈によって矛盾しない限り、対応するセットの「ｓｕｂｓｅｔ（サブセット）」という用語は、必ずしも対応するセットの適切なサブセットを示すものではないが、サブセットと、対応するセットは等しくてもよい。

特に断りのない限りまたは文脈から明らかに矛盾しない限り、「ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ Ａ，Ｂ，ａｎｄ Ｃ（Ａ、Ｂ及びＣの少なくとも１つ）」または「ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ Ａ，Ｂ，ａｎｄ Ｃ（Ａ、Ｂ及びＣの少なくとも１つ）」という形の句といった連結的な言語は、項目、用語等がＡもしくはＢもしくはＣ、またはＡ、Ｂ及びＣのセットの任意の非空のサブセットであってよいことを示すために一般的に用いられるとして文脈の中で他の意味に理解される。例えば、３つのメンバーを有するセットの具体例では、「ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ Ａ，Ｂ，ａｎｄ Ｃ（Ａ、Ｂ及びＣの少なくとも１つ）」及び「ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ Ａ，Ｂ，ａｎｄ Ｃ（Ａ、Ｂ及びＣの少なくとも１つ）」という連結的な句は、以下のセット、｛Ａ｝，｛Ｂ｝，｛Ｃ｝，｛Ａ，Ｂ｝，｛Ａ，Ｃ｝，｛Ｂ，Ｃ｝，｛Ａ，Ｂ，Ｃ｝のいずれかを指す。したがって、そのような連結的な言語は、一般に、一定の実施形態が、Ａの少なくとも１つ、Ｂの少なくとも１つ及びＣの少なくとも１つがそれぞれ存在することを必要とすることを含意することは意図していない。

本明細書に記載されるプロセスの動作は、本明細書で別段の指示がない限り、または文脈に明らかに矛盾するものでない限り、任意の適切な順序で実行できる。本明細書中に記載されるプロセス（またはその変形形態及び／もしくは組み合わせ）は、実行可能命令で構成される１つまたは複数のコンピュータシステムの制御下で実行され得、ハードウェアまたはその組合せにより１つまたは複数のプロセッサで集合的に実行するコード（例えば、実行可能命令、１つもしくは複数のコンピュータプログラム、または１つもしくは複数のアプリケーション）として実装され得る。コードは、例えば１つまたは複数のプロセッサによって実行可能な複数の命令を含むコンピュータプログラムの形でコンピュータ可読記憶媒体に記憶されてよい。コンピュータ可読記憶媒体は非一時的であり得る。いくつかの実施形態では、コードは、コンピュータシステムの１つまたは複数のプロセッサによって実行されると（すなわち実行された結果として）、コンピュータシステムが、本明細書中で記載された動作を行う実行可能命令を格納した１つまたは複数の非一時的なコンピュータ可読記憶媒体のセットに格納されている。非一時的なコンピュータ可読記憶媒体のセットは、複数の非一時的なコンピュータ可読記憶媒体を備え得、複数の非一時的なコンピュータ可読記憶媒体の個々の非一時的な記憶媒体の１つまたは複数は、コード全てがなくてもよい一方、複数の非一時的なコンピュータ可読記憶媒体は、コード全てを集合的に格納する。さらに、いくつかの例では、実行可能命令は、異なる命令は異なるプロセッサによって実行されるように、実行される。具体例として、非一時的なコンピュータ可読記憶媒体は、命令を格納し得る。メインＣＰＵは、命令の一部を実行し得、グラフィック処理装置は、他の命令を実行し得る。一般に、コンピュータシステムの異なる構成要素は別々のプロセッサを有し得、異なるプロセッサは命令の異なるサブセットを実行し得る。

したがって、いくつかの例では、コンピュータシステムは、本明細書中で記載されたプロセスの動作を単一でまたは集合的に行う１つまたは複数のサービスを実装するように構成されている。そうしたコンピュータシステムは、例えば、動作の性能を有効にする適用可能なハードウェア及び／またはソフトウェアで構成され得る。さらに、本開示の様々な実施形態を実装するコンピュータシステムは、いくつかの例では、単一のデバイスであってもよく、他の例では、分散型コンピュータシステムが本明細書中で記載された動作を行うようにかつ単一のデバイスが動作全てを行わないように、異なるように動作する複数のデバイスを備える分散型コンピュータシステムであってもよい。

本明細書で示される任意の及びすべての例、または例示的な言語（例えば、「ｓｕｃｈ ａｓ（〜など）」）の使用は、単に本発明の実施形態をよりよく示すことを意図しており、別段の主張がない限り、本発明の範囲を限定するものではない。本明細書のいかなる言葉も、本発明の実施にとって必須として任意の請求されていない要素を示すものと解釈されるべきではない。

本発明を実施するために本発明者らに知られている最良の形態を含む本開示の実施形態を本明細書に記載する。それらの実施形態の変形形態は、前述の説明を読むと当業者に明らかになり得る。本発明者らは、当業者がこのような変形形態を必要に応じて利用することを期待し、本発明者らは本開示の実施形態が本明細書に具体的に記載されたものとは別の方法で実施されることを意図する。したがって、本開示の範囲は、適用法によって許容されるように、本明細書に添付された特許請求の範囲に記載された主題のすべての修正形態及び均等物を含む。さらに、本明細書に別段の指示がない限り、または文脈に明らかに矛盾するものでない限り、上述要素のすべての考え得る変形形態での上述要素の任意の組合せが本開示の範囲に包含される。

あたかも各参考文献が個々にかつ具体的に参照により援用されることが示され本明細書中にその全体として記載されるかのように、本明細書で引用した刊行物、特許出願及び特許を含むすべての参考文献は、同程度に参照により本明細書によって援用される。

Claims (11)

1. コンピュータによって実装される方法であって、
   実行可能命令で構成される１つまたは複数のコンピュータシステムの制御下で、
   暗号保護された通信セッションを確立するハンドシェイクプロトコルの一部として、送信者識別情報及び第１の非対称公開鍵を備える第１のメッセージを取得することと、
   暗号化サービスに、前記第１のメッセージ、鍵識別子及び前記第１のメッセージに対応する第１の認証されたメッセージを生成する命令を提供することであって、前記第１の認証されたメッセージは、検証するために前記第１の認証されたメッセージを前記暗号化サービスに提供するクライアントによって検証することができる、前記提供することと、
   前記暗号化サービスから、前記第１のメッセージに対応する前記第１の認証されたメッセージを受信することと、
   前記ハンドシェイクプロトコルの一部として前記クライアントに前記第１の認証されたメッセージを提供することと、
   前記クライアントから、第２の認証されたメッセージを受信することであって、前記第２の認証されたメッセージは、少なくとも第２の送信者識別情報及び第２の非対称公開鍵を備える、前記受信することと、
   前記暗号化サービスを用いて、前記第２の認証されたメッセージの信頼性を検証することと、
   前記暗号化サービスから、前記第２の認証されたメッセージが真正なものであるという表示を受信することと、
   前記ハンドシェイクプロトコルの一部として、少なくとも前記第２の非対称公開鍵及び前記第１の非対称公開鍵に対応する第１の非対称秘密鍵を用いて共有秘密鍵を生成することと、
   前記共有秘密鍵を用いて、前記クライアントとの間に前記暗号保護された通信セッションを確立することであって、前記共有秘密鍵も前記クライアントによって生成可能である、前記確立することとを備え、
   前記第１のメッセージに対応する前記第１の認証されたメッセージを生成する前記命令が、前記暗号化サービスへの、前記第１のメッセージに基づくメッセージ認証コード（ＭＡＣ）タグを生成する要求を備え、
   前記第１の認証されたメッセージが、前記第１のメッセージ及び前記第１のメッセージに基づく前記ＭＡＣタグを備える、前記方法。
2. 前記第１の非対称公開鍵が楕円曲線公開鍵ＱＡであり、前記対応する秘密鍵が対応する楕円曲線秘密鍵ｄＡであり、前記第２の非対称公開鍵が楕円曲線公開鍵ＱＢであり、かつ、前記共有秘密鍵が、ｄＡとＱＢの楕円曲線点乗算の計算に基づいて生成される、請求項１に記載のコンピュータによって実装される方法。
3. １つまたは複数のプロセッサと、
   前記１つまたは複数のプロセッサによって実行された結果として、システムが、
   暗号化サービスから、公開鍵と送信者識別の結びつきが真正なものであるという表示を取得し、
   ハンドシェイクプロトコルの一部として、前記送信者識別に結びつけられた前記公開鍵及び前記結びつきが真正なものであるという前記表示をクライアントに提供し、
   前記クライアントから、第２の公開鍵を受信し、
   少なくとも秘密鍵及び前記第２の公開鍵を用いて共有秘密鍵を生成し、
   前記共有秘密鍵を用いて、前記クライアントとの間に暗号保護された通信セッションを確立する実行可能命令を格納するメモリとを備え、
   前記第２の公開鍵が、第２の結びつきを通して、第２の送信者識別及び前記暗号化サービスによって暗号学的に検証可能である第２の表示に結びつけられ、
   前記実行可能命令によって、さらに、前記システムが、
   前記暗号化サービスを用いて、前記第２の結びつきが真正なものであることを検証し、
   前記第２の結びつきが真正なものであることの検証の成功に応えて、前記共有秘密鍵を生成し、
   前記システムが、前記公開鍵及び前記送信者識別を含むメッセージを少なくとも生成することによって、前記公開鍵を前記送信者識別に結びつけ、
   前記システムが、鍵識別子を取得し前記暗号化サービスに前記鍵識別子に関連付けられた暗号化鍵を用いて前記メッセージ全体にメッセージ認証コード（ＭＡＣ）タグを生成することを要求することによって、前記結びつきが真正なものであるという前記表示を取得し、
   前記第２の表示が第２のＭＡＣタグを含み、
   前記第２の結びつきが真正なものであることを前記検証することが、前記暗号化サービスに前記第２のＭＡＣタグ及び前記第２の結びつきを提供することを備える、システム。
4. １つまたは複数のプロセッサと、
   前記１つまたは複数のプロセッサによって実行された結果として、システムが、
   暗号化サービスから、公開鍵と送信者識別の結びつきが真正なものであるという表示を取得し、
   ハンドシェイクプロトコルの一部として、前記送信者識別に結びつけられた前記公開鍵及び前記結びつきが真正なものであるという前記表示をクライアントに提供し、
   前記クライアントから、第２の公開鍵を受信し、
   少なくとも秘密鍵及び前記第２の公開鍵を用いて共有秘密鍵を生成し、
   前記共有秘密鍵を用いて、前記クライアントとの間に暗号保護された通信セッションを確立する実行可能命令を格納するメモリとを備え、
   前記第２の公開鍵が、第２の結びつきを通して、第２の送信者識別及び前記暗号化サービスによって暗号学的に検証可能である第２の表示に結びつけられ、
   前記実行可能命令によって、さらに、前記システムが、
   前記暗号化サービスを用いて、前記第２の結びつきが真正なものであることを検証し、
   前記第２の結びつきが真正なものであることの検証の成功に応えて、前記共有秘密鍵を生成し、
   前記システムが前記公開鍵を前記送信者識別に結びつけることが、前記公開鍵及び前記送信者識別を含むメッセージを生成することを含み、
   前記システムが、前記結びつきが真正なものであるという前記表示を、鍵識別子を取得し前記暗号化サービスに前記鍵識別子に関連付けられた暗号化鍵を用いて前記メッセージを暗号化することを要求することによって取得し、
   前記第２の表示が暗号文を含み、
   前記システムが、さらに、前記第２の結びつきが真正なものであることを検証するために、
   前記暗号化サービスに、復号化する前記暗号文を提供し、
   前記暗号化サービスから、暗号文に対応する平文及び第２の鍵識別子を受信し、
   前記第２の鍵識別子が前記クライアントに関連付けられていることを判定する命令を含む、システム。
5. 前記メッセージがノンスをさらに含み、
   前記システムが、さらに、前記第２の結びつきが真正なものであることを検証するために、前記暗号文に対応する前記平文が前記ノンスを含むことを判定する命令を含む、請求項４に記載のシステム。
6. 前記実行可能命令により、さらに、前記システムが、前記暗号保護された通信セッションを確立した後で、データを取得し、前記秘密鍵を用いて前記データ全体にデジタル署名を生成し、前記クライアントに前記暗号保護された通信セッションを介して前記データ及び前記デジタル署名を送信する、請求項３から５のいずれか一項に記載のシステム。
7. 前記暗号保護された通信セッションがトランスポート層セキュリティ（ＴＬＳ）セッションである、請求項３から６のいずれか一項に記載のシステム。
8. コンピュータプログラムであって、コンピュータシステムに、
   秘密鍵及び公開鍵を備える非対称鍵ペアを取得する手順と、
   暗号化サービスから、前記公開鍵と送信者識別の結びつきが真正なものであるという表示を取得する手順と、
   ハンドシェイクプロトコルの一部として、前記公開鍵及び前記結びつきが真正なものであるという前記表示をクライアントに提供する手順であって、前記クライアントに提供された前記公開鍵は前記送信者識別に結びつけられている、手順と、
   前記クライアントから、第２の結びつきを介して第２の送信者識別及び第２の表示に結びつけられた第２の公開鍵を受信する手順であって、前記第２の表示は前記暗号化サービスによって暗号学的に検証可能なものである、手順と、
   前記暗号化サービスを用いて、前記第２の結びつきが真正なものであることを検証する手順と、
   前記第２の結びつきが真正なものであると判定したことに応えて、少なくとも前記秘密鍵及び前記第２の公開鍵を用いて共有秘密鍵を生成する手順と、
   前記クライアントとの間に暗号保護された通信セッションを確立する手順と
   を実行させ、
   前記コンピュータプログラムは、前記コンピュータシステムに、前記公開鍵及び前記送信者識別を含むメッセージを生成することによって前記公開鍵を前記送信者識別に結びつける手順を実行させ、
   前記コンピュータプログラムは、前記コンピュータシステムに、鍵識別子を取得し前記暗号化サービスに前記鍵識別子に関連付けられた暗号化鍵を用いて前記メッセージ全体にメッセージ認証コード（ＭＡＣ）タグを生成することを要求する命令を介して、前記結びつきが真正なものであるという前記表示を取得する手順を実行させ、
   前記第２の表示が第２のＭＡＣタグを含み、
   前記コンピュータプログラムは、前記コンピュータシステムに、前記暗号化サービスに前記第２のＭＡＣタグ及び前記第２の結びつきを提供する命令を介して前記第２の結びつきが真正なものであることを検証する手順を実行させる、
   コンピュータプログラム。
9. コンピュータプログラムであって、コンピュータシステムに、
   秘密鍵及び公開鍵を備える非対称鍵ペアを取得する手順と、
   暗号化サービスから、前記公開鍵と送信者識別の結びつきが真正なものであるという表示を取得する手順と、
   ハンドシェイクプロトコルの一部として、前記公開鍵及び前記結びつきが真正なものであるという前記表示をクライアントに提供する手順であって、前記クライアントに提供された前記公開鍵は前記送信者識別に結びつけられている、手順と、
   前記クライアントから、第２の結びつきを介して第２の送信者識別及び第２の表示に結びつけられた第２の公開鍵を受信する手順であって、前記第２の表示は前記暗号化サービスによって暗号学的に検証可能なものである、手順と、
   前記暗号化サービスを用いて、前記第２の結びつきが真正なものであることを検証する手順と、
   前記第２の結びつきが真正なものであると判定したことに応えて、少なくとも前記秘密鍵及び前記第２の公開鍵を用いて共有秘密鍵を生成する手順と、
   前記クライアントとの間に暗号保護された通信セッションを確立する手順と
   を実行させ、
   前記コンピュータプログラムは、前記コンピュータシステムに、前記公開鍵及び前記送信者識別を含むメッセージを生成することによって前記公開鍵を前記送信者識別に結びつける手順を実行させ、
   前記コンピュータプログラムは、前記コンピュータシステムに、鍵識別子を取得し前記暗号化サービスに前記鍵識別子に関連付けられた暗号化鍵を用いて前記メッセージを暗号化することを要求することによって、前記結びつきが真正なものであるという前記表示を取得する手順を実行させ、
   前記第２の表示が暗号文を含み、
   前記第２の結びつきが真正なものであることを検証する前記手順が、
   前記暗号化サービスに、復号化する前記暗号文を提供する手順と、
   前記暗号化サービスから、前記暗号文に対応する平文及び第２の鍵識別子を受信する手順と、
   前記第２の鍵識別子が前記クライアントに関連付けられていることを判定する手順と
   を含む、
   コンピュータプログラム。
10. 暗号化要求が認証付き暗号化要求である、請求項８又は９に記載のコンピュータプログラム。
11. 前記暗号保護された通信セッションがトランスポート層セキュリティ（ＴＬＳ）セッションである、請求項８から１０のいずれか一項に記載のコンピュータプログラム。