IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ アマゾン・テクノロジーズ、インコーポレイテッドの特許一覧

特許7215684部分的に信頼できる第三者機関を通しての鍵交換
<>
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図1
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図2
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図3
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図4
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図5
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図6
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図7
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図8
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図9
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図10
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図11
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図12
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図13
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図14
  • 特許-部分的に信頼できる第三者機関を通しての鍵交換 図15
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-01-23
(45)【発行日】2023-01-31
(54)【発明の名称】部分的に信頼できる第三者機関を通しての鍵交換
(51)【国際特許分類】
   H04L 9/32 20060101AFI20230124BHJP
   H04L 9/08 20060101ALI20230124BHJP
【FI】
H04L9/32 200A
H04L9/08 C
H04L9/32 200D
【請求項の数】 26
【外国語出願】
(21)【出願番号】P 2019213517
(22)【出願日】2019-11-26
(62)【分割の表示】P 2018521427の分割
【原出願日】2016-12-06
(65)【公開番号】P2020058042
(43)【公開日】2020-04-09
【審査請求日】2019-12-16
(31)【優先権主張番号】14/967,214
(32)【優先日】2015-12-11
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】506223509
【氏名又は名称】アマゾン・テクノロジーズ、インコーポレイテッド
(74)【代理人】
【識別番号】110000877
【氏名又は名称】弁理士法人RYUKA国際特許事務所
(72)【発明者】
【氏名】カンパーニャ、マシュー ジョン
【審査官】中里 裕正
(56)【参考文献】
【文献】米国特許出願公開第2005/0278534(US,A1)
【文献】特表2005-537711(JP,A)
【文献】特開平08-008895(JP,A)
【文献】特表2005-521279(JP,A)
【文献】特開2011-015110(JP,A)
【文献】特表2011-501585(JP,A)
【文献】米国特許出願公開第2013/0111209(US,A1)
【文献】野沢哲生,「e-Japan」社会を支える電子証明書 セキュリティ確保に“1枚4役” 有効/無効を即座にチェック,日経コミュニケーション,日経BP社,2001年03月05日,第335号,pp.106-113
【文献】BLAKE- WILSON, S. and MENEZES, A.,Authenticated Diffie-Hellman Key Agreement Protocols,Lecture Notes in Computer Science,Vol. 1556,1999年,p.339-361
【文献】宇根正志,金融分野におけるPKI:技術的課題と研究・標準化動向,日本銀行金融研究所ディスカッション・ペーパー・シリーズ,[online],2002年03月,pp.1-64,<URL:https://www.boj.or.jp/research/imes/dps/dps02.htm/>
【文献】EUCHNER, M.,HMAC-Authenticated Diffie-Hellman for Multimedia Internet Keying (MIKEY),Request for Comments,4650,[online],2006年09月,p.1-27,https://tools.ietf.org/rfc4650,[2019年6月26日検索]
(58)【調査した分野】(Int.Cl.,DB名)
H04L 9/32
H04L 9/08
(57)【特許請求の範囲】
【請求項1】
コンピュータによって実装される方法であって、
コンピュータシステム上で動作する暗号化サービスから第1のエンティティへ、前記第1のエンティティと第1の公開鍵との間の第1の関連付けを示す第1のデータを送信することであって、前記第1のデータは前記第1のエンティティから取得したメッセージから暗号化鍵を用いて生成されたデジタル署名を備えることと、
前記暗号化サービスにおいて、第2のエンティティから、前記第2のエンティティからの前記第1の関連付けを検証する要求に応えて前記第1のデータを取得することと、
前記デジタル署名が前記暗号化鍵を用いて検証された場合に、前記第1のデータが有効であるという表示を、前記暗号化サービスから前記第2のエンティティへ送信することと、
前記第2のエンティティと第2の公開鍵との間の第2の関連付けの有効性を示すために用いられる第2のデータを、前記暗号化サービスから前記第2のエンティティへ送信することと
を備え、
前記第1の公開鍵及び前記第2の公開鍵は共に、前記第1のエンティティと前記第2のエンティティとの間の暗号保護された通信セッションを確立することの一部として用いられる
方法。
【請求項2】
前記暗号化サービスにおいて、前記第2の関連付けを検証する第2の要求に応じて前記第2のデータを取得することと、
前記暗号化サービスから前記第1のエンティティへ、前記第2のデータが有効であるという第2の表示を送信することと
をさらに備える請求項1に記載の法。
【請求項3】
前記第1のデータは、第1の識別子及び前記第1の公開鍵が前記第1のエンティティに関連付けられていることを暗号的に検証するために使用可能なデジタル署名を備え、
前記方法は、
前記第1の関連付けを検証する前記要求に応えて前記デジタル署名の信頼性を暗号学的に検証すること
をさらに備える請求項1又は2に記載の法。
【請求項4】
前記第1のデータが有効であるという前記表示は、前記第2のエンティティによって暗号学的に検証可能である
請求項1から3のいずれか一項に記載の法。
【請求項5】
コンピュータによって実装される方法であって、
コンピュータシステム上で動作する暗号化サービスから第1のエンティティへ、前記第1のエンティティと第1の公開鍵との間の第1の関連付けを示す第1のデータを送信することと、
前記暗号化サービスにおいて、前記第1の関連付けを検証する要求に応えて前記第1のデータを取得することと、
前記第1のデータが有効であるという表示を、前記暗号化サービスから第2のエンティティへ送信することと、
前記第2のエンティティと第2の公開鍵との間の第2の関連付けの有効性を示すために用いられる第2のデータを、前記暗号化サービスから前記第2のエンティティへ送信することと
を備え、
前記第1の公開鍵及び前記第2の公開鍵は共に、前記第1のエンティティと前記第2のエンティティとの間の暗号保護された通信セッションを確立することの一部として用いられ、
前記第1のエンティティと前記第1の公開鍵との間の前記第1の関連付けを示す前記第1のデータは、暗号文を含み、
前記方法は、
前記暗号化サービスにおいて、前記第1のエンティティに関連付けられた識別子及び前記第1の公開鍵を備える平文を暗号化することであって、前記平文の暗号化によって前記暗号文が生成されることと、
前記暗号化サービスにおいて、前記第1の関連付けを検証する前記要求に応じて前記暗号文を復号化することと
をさらに備える方法。
【請求項6】
コンピュータによって実装される方法であって、
コンピュータシステム上で動作する暗号化サービスから第1のエンティティへ、前記第1のエンティティと第1の公開鍵との間の第1の関連付けを示す第1のデータを送信することと、
前記暗号化サービスにおいて、前記第1の関連付けを検証する要求に応えて前記第1のデータを取得することと、
前記第1のデータが有効であるという表示を、前記暗号化サービスから第2のエンティティへ送信することと、
前記第2のエンティティと第2の公開鍵との間の第2の関連付けの有効性を示すために用いられる第2のデータを、前記暗号化サービスから前記第2のエンティティへ送信することと
を備え、
前記第1の公開鍵及び前記第2の公開鍵は共に、前記第1のエンティティと前記第2のエンティティとの間の暗号保護された通信セッションを確立することの一部として用いられ、
前記方法は、
前記暗号化サービスにおいて、暗号学的ハッシュ関数を用いて、前記第1のエンティティに関連付けられた識別子及び前記第1の公開鍵を備えるメッセージ認証タグ(MACタグ)を生成すること
をさらに備え、
前記第1のデータは前記MACタグを備える
方法。
【請求項7】
コンピュータによって実装される方法であって、
コンピュータシステム上で動作する暗号化サービスから第1のエンティティへ、前記第1のエンティティと第1の公開鍵との間の第1の関連付けを示す第1のデータを送信することと、
前記暗号化サービスにおいて、前記第1の関連付けを検証する第1の要求に応えて前記第1のデータを取得することと、
前記第1のデータが有効であるという表示を、前記暗号化サービスから第2のエンティティへ送信することと、
前記第2のエンティティと第2の公開鍵との間の第2の関連付けの有効性を示すために用いられる第2のデータを、前記暗号化サービスから前記第2のエンティティへ送信することと、
前記暗号化サービスにおいて、前記第2の関連付けを検証する第2の要求に応じて前記第2のデータを取得することと、
前記暗号化サービスから前記第1のエンティティへ、前記第2のデータが有効であるという第2の表示を送信することと
を備え、
前記第1の公開鍵及び前記第2の公開鍵は共に、前記第1のエンティティと前記第2のエンティティとの間の暗号保護された通信セッションを確立することの一部として用いられ、
前記方法は、
前記暗号化サービスにおいて、マスター鍵を用いて、前記第1の関連付けを示す前記第1のデータを生成することと、
前記暗号化サービスにおいて、同一の前記マスター鍵を用いて、前記第2の関連付けを示す前記第2のデータを生成することと、
前記暗号化サービスにおいて、前記第1の要求に応じて、前記マスター鍵を用いて前記第1の関連付けを検証することと、
前記暗号化サービスにおいて、前記第2の要求に応じて、前記マスター鍵を用いて前記第2の関連付けを検証することと
をさらに備える方法。
【請求項8】
システムであって、
1つ又は複数のハードウェアプロセッサと、
前記1つ又は複数のプロセッサによって実行された結果として、前記システムに、
前記システムから第1のエンティティへ、前記第1のエンティティと第1の公開鍵との間の第1の関連付けを示す第1のデータであり、前記第1のエンティティから取得したメッセージから暗号化鍵を用いて生成されたデジタル署名を備える第1のデータ送信させ、
前記システムにおいて、第2のエンティティから、前記第2のエンティティからの前記第1の関連付けを検証する要求に応えて前記第1のデータを取得させ、
前記暗号化鍵を用いて前記デジタル署名が検証された場合に、前記第1のデータが有効であるという第1の表示を、前記システムから前記第2のエンティティへ送信させ、
前記第2のエンティティと第2の公開鍵との間の第2の関連付けの有効性を示すために用いられる第2のデータを、前記システムから前記第2のエンティティへ送信させる、実行可能な命令を格納するメモリと
を備え、
前記第1の公開鍵及び前記第2の公開鍵は共に、前記第1のエンティティと前記第2のエンティティとの間の暗号保護された通信セッションを確立することの一部として用いられる
システム。
【請求項9】
前記命令は、前記1つ又は複数のプロセッサによって実行された結果として、前記システムにさらに、少なくとも
前記システムにおいて、前記第2の関連付けを検証する第2の要求に応じて前記第2のデータを取得させ、
前記システムから前記第1のエンティティへ、前記第2のデータが有効であるという第2の表示を送信させる
請求項8に記載のシステム。
【請求項10】
前記暗号保護された通信セッションは、前記第2のエンティティによって取得された前記第1の表示及び前記第1のエンティティによって取得された前記第2の表示に少なくとも基づいて確立される
請求項9に記載のシステム。
【請求項11】
前記第1の公開鍵と前記第2の公開鍵に対応する第2の秘密鍵とから、共有秘密鍵を計算可能であり、
前記共有秘密鍵は、前記第2の公開鍵と前記第1の公開鍵に対応する第1の秘密鍵とからも計算可能であり、
前記共有秘密鍵は、前記システムには利用不可能であり、前記第1のエンティティ及び前記第2のエンティティによって、前記暗号保護された通信セッションを介して通信するために使用される
請求項9又は10に記載のシステム。
【請求項12】
前記第1の公開鍵は、楕円曲線ディフィーヘルマン(ECDH)公開鍵である
請求項8から11のいずれか一項に記載のシステム。
【請求項13】
前記システムは、前記暗号保護された通信セッションのプロトコルに従って暗号化された1つ又は複数のメッセージを復号化するための十分な暗号学的なデータを有さない
請求項12に記載のシステム。
【請求項14】
システムであって、
1つ又は複数のハードウェアプロセッサと、
前記1つ又は複数のプロセッサによって実行された結果として、前記システムに、
前記システムから第1のエンティティへ、前記第1のエンティティと第1の公開鍵との間の第1の関連付けを示す第1のデータを送信させ、
前記システムにおいて、前記第1の関連付けを検証する要求に応えて前記第1のデータを取得させ、
前記第1のデータが有効であるという第1の表示を、前記システムから第2のエンティティへ送信させ、
前記第2のエンティティと第2の公開鍵との間の第2の関連付けの有効性を示すために用いられる第2のデータを、前記システムから前記第2のエンティティへ送信させる、実行可能な命令を格納するメモリと
を備え、
前記第1の公開鍵及び前記第2の公開鍵は共に、前記第1のエンティティと前記第2のエンティティとの間の暗号保護された通信セッションを確立することの一部として用いられ、
前記第1のエンティティと前記第1の公開鍵との間の前記第1の関連付けを示す前記第1のデータは、暗号文を含み、
前記命令は、前記1つ又は複数のプロセッサによって実行された結果として、前記システムにさらに、少なくとも
前記第1のエンティティに関連付けられた識別子及び前記第1の公開鍵を備える平文を暗号化させ、前記平文の暗号化によって前記暗号文が生成され、
前記第1の関連付けを検証する前記要求に応じて前記暗号文を復号化させる
システム。
【請求項15】
システムであって、
1つ又は複数のハードウェアプロセッサと、
前記1つ又は複数のプロセッサによって実行された結果として、前記システムに、
前記システムから第1のエンティティへ、前記第1のエンティティと第1の公開鍵との間の第1の関連付けを示す第1のデータを送信させ、
前記システムにおいて、前記第1の関連付けを検証する要求に応えて前記第1のデータを取得させ、
前記第1のデータが有効であるという第1の表示を、前記システムから第2のエンティティへ送信させ、
前記第2のエンティティと第2の公開鍵との間の第2の関連付けの有効性を示すために用いられる第2のデータを、前記システムから前記第2のエンティティへ送信させる、実行可能な命令を格納するメモリと
を備え、
前記第1の公開鍵及び前記第2の公開鍵は共に、前記第1のエンティティと前記第2のエンティティとの間の暗号保護された通信セッションを確立することの一部として用いられ、
前記命令は、前記1つ又は複数のプロセッサによって実行された場合に、前記システムにさらに、少なくとも、
暗号学的ハッシュ関数を用いて、前記第1のエンティティに関連付けられた識別子及び前記第1の公開鍵を備えるメッセージ認証タグ(MACタグ)を生成させ、
前記第1のデータは前記MACタグを備える
システム。
【請求項16】
システムであって、
1つ又は複数のハードウェアプロセッサと、
前記1つ又は複数のプロセッサによって実行された結果として、前記システムに、
前記システムから第1のエンティティへ、前記第1のエンティティと第1の公開鍵との間の第1の関連付けを示す第1のデータを送信させ、
前記システムにおいて、前記第1の関連付けを検証する第1の要求に応えて前記第1のデータを取得させ、
前記第1のデータが有効であるという第1の表示を、前記システムから第2のエンティティへ送信させ、
前記第2のエンティティと第2の公開鍵との間の第2の関連付けの有効性を示すために用いられる第2のデータを、前記システムから前記第2のエンティティへ送信させ、
前記システムにおいて、前記第2の関連付けを検証する第2の要求に応じて前記第2のデータを取得させ、
前記システムから前記第1のエンティティへ、前記第2のデータが有効であるという第2の表示を送信させる、実行可能な命令を格納するメモリと
を備え、
前記第1の公開鍵及び前記第2の公開鍵は共に、前記第1のエンティティと前記第2のエンティティとの間の暗号保護された通信セッションを確立することの一部として用いられ、
前記命令は、前記1つ又は複数のプロセッサによって実行された場合に、前記システムにさらに、少なくとも、
マスター鍵を用いて、前記第1の関連付けを示す前記第1のデータを生成させ、
同一の前記マスター鍵を用いて、前記第2の関連付けを示す前記第2のデータを生成させ、
前記第1の要求に応じて、前記マスター鍵を用いて前記第1の関連付けを検証させ、
前記第2の要求に応じて、前記マスター鍵を用いて前記第2の関連付けを検証させる
システム。
【請求項17】
コンピュータシステムに、少なくとも、
前記コンピュータシステムから第1のエンティティへ、前記第1のエンティティと第1の公開鍵との間の第1の関連付けを示す第1のデータであり、前記第1のエンティティから取得したメッセージから暗号化鍵を用いて生成されたデジタル署名を備える第1のデータ送信させ、
前記コンピュータシステムにおいて、第2のエンティティから、前記第2のエンティティからの前記第1の関連付けを検証する第1の要求に応えて前記第1のデータを取得させ、
前記暗号化鍵を用いて前記デジタル署名が検証された場合に、前記第1のデータが有効であるという第1の表示を、前記コンピュータシステムから前記第2のエンティティへ送信させ、
前記第2のエンティティと第2の公開鍵との間の第2の関連付けの有効性を示すために用いられる第2のデータを、前記コンピュータシステムから前記第2のエンティティへ送信させ、
前記第1の公開鍵及び前記第2の公開鍵は共に、前記第1のエンティティと前記第2のエンティティとの間の暗号保護された通信セッションを確立することの一部として用いられる
コンピュータプログラム。
【請求項18】
前記コンピュータシステムにさらに、少なくとも、暗号保護された通信のためのプロトコルのハンドシェイクの一部として前記第1の表示を送信させる
請求項17に記載のコンピュータプログラム。
【請求項19】
前記ハンドシェイクは、トランスポート層セキュリティ(TLS)プロトコルに従う
請求項18に記載のコンピュータプログラム。
【請求項20】
前記コンピュータシステムにさらに、少なくとも
前記コンピュータシステムにおいて、前記第2の関連付けを検証する第2の要求に応じて前記第2のデータを取得させ、
前記コンピュータシステムから前記第1のエンティティへ、前記第2のデータが有効であるという第2の表示を送信させる
請求項17から19のいずれか一項に記載のコンピュータプログラム。
【請求項21】
前記第1の公開鍵と前記第2の公開鍵に対応する第2の秘密鍵とから、共有秘密鍵を計算可能であり、
前記共有秘密鍵は、前記第2の公開鍵と前記第1の公開鍵に対応する第1の秘密鍵とからも計算可能であり、
前記共有秘密鍵は、前記コンピュータシステムには利用不可能であり、前記第1のエンティティ及び前記第2のエンティティによって、前記暗号保護された通信セッションを介して通信するために使用される
請求項17から20のいずれか一項に記載のコンピュータプログラム。
【請求項22】
コンピュータプログラムであって、コンピュータシステムに、少なくとも、
前記コンピュータシステムから第1のエンティティへ、前記第1のエンティティと第1の公開鍵との間の第1の関連付けを示す第1のデータを送信させ、
前記コンピュータシステムにおいて、前記第1の関連付けを検証する第1の要求に応えて前記第1のデータを取得させ、
前記第1のデータが有効であるという第1の表示を、前記コンピュータシステムから第2のエンティティへ送信させ、
前記第2のエンティティと第2の公開鍵との間の第2の関連付けの有効性を示すために用いられる第2のデータを、前記コンピュータシステムから前記第2のエンティティへ送信させ、
前記コンピュータシステムにおいて、前記第2の関連付けを検証する第2の要求に応じて前記第2のデータを取得させ、
前記コンピュータシステムから前記第1のエンティティへ、前記第2のデータが有効であるという第2の表示を送信させ、
前記第1の公開鍵及び前記第2の公開鍵は共に、前記第1のエンティティと前記第2のエンティティとの間の暗号保護された通信セッションを確立することの一部として用いられ、
前記コンピュータプログラムは、前記コンピュータシステムにさらに、少なくとも
マスター鍵を用いて、前記第1の関連付けを示す前記第1のデータを生成させ、
同一の前記マスター鍵を用いて、前記第2の関連付けを示す前記第2のデータを生成させ、
前記第1の要求に応じて、前記マスター鍵を用いて前記第1の関連付けを検証させ、
前記第2の要求に応じて、前記マスター鍵を用いて前記第2の関連付けを検証させる
コンピュータプログラム。
【請求項23】
コンピュータプログラムであって、コンピュータシステムに、少なくとも、
前記コンピュータシステムから第1のエンティティへ、前記第1のエンティティと第1の公開鍵との間の第1の関連付けを示す第1のデータを送信させ、
前記コンピュータシステムにおいて、前記第1の関連付けを検証する第1の要求に応えて前記第1のデータを取得させ、
前記第1のデータが有効であるという第1の表示を、前記コンピュータシステムから第2のエンティティへ送信させ、
前記第2のエンティティと第2の公開鍵との間の第2の関連付けの有効性を示すために用いられる第2のデータを、前記コンピュータシステムから前記第2のエンティティへ送信させ、
前記第1の公開鍵及び前記第2の公開鍵は共に、前記第1のエンティティと前記第2のエンティティとの間の暗号保護された通信セッションを確立することの一部として用いられ、
前記第1のエンティティと前記第1の公開鍵との間の前記第1の関連付けを示す前記第1のデータは、暗号文を含み、
前記コンピュータプログラムは、前記コンピュータシステムにさらに、少なくとも
前記第1のエンティティに関連付けられた識別子及び前記第1の公開鍵を備える平文を暗号化させ、前記平文の暗号化によって前記暗号文が生成され、
前記第1の関連付けを検証する前記第1の要求に応じて前記暗号文を復号化させる
コンピュータプログラム。
【請求項24】
コンピュータプログラムであって、コンピュータシステムに、少なくとも、
前記コンピュータシステムから第1のエンティティへ、前記第1のエンティティと第1の公開鍵との間の第1の関連付けを示す第1のデータを送信させ、
前記コンピュータシステムにおいて、前記第1の関連付けを検証する第1の要求に応えて前記第1のデータを取得させ、
前記第1のデータが有効であるという第1の表示を、前記コンピュータシステムから第2のエンティティへ送信させ、
前記第2のエンティティと第2の公開鍵との間の第2の関連付けの有効性を示すために用いられる第2のデータを、前記コンピュータシステムから前記第2のエンティティへ送信させ、
前記第1の公開鍵及び前記第2の公開鍵は共に、前記第1のエンティティと前記第2のエンティティとの間の暗号保護された通信セッションを確立することの一部として用いられ、
前記コンピュータプログラムは、前記コンピュータシステムにさらに、少なくとも
暗号学的ハッシュ関数を用いて、前記第1のエンティティに関連付けられた識別子及び前記第1の公開鍵を備えるメッセージ認証タグ(MACタグ)を生成させ、
前記第1のデータは前記MACタグを備える
コンピュータプログラム。
【請求項25】
前記第1のエンティティと前記第1の公開鍵との間の前記第1の関連付けを示す前記第1のデータは、ノンスを含む
請求項17から24のいずれか一項に記載のコンピュータプログラム。
【請求項26】
前記ノンスは前記第1のエンティティによって提供される
請求項25に記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、2015年12月11日出願の「KEY EXCHANGE THROUGH PARTIALLY TRUSTED THIRD PARTY(部分的に信頼できる第三者機関を通しての鍵交換)」と題された米国特許出願第14/967,214号(代理人整理番号0097749-629US0)の全開示の優先権を主張し、それをあらゆる目的のために参照により組み込むものであり、2015年12月11日出願の「SIGNED ENVELOPE ENCRYPTION(署名されたエンベロープ暗号化)」と題された米国特許出願第14/967,142号(代理人整理番号0097749-628US0)の全開示をあらゆる目的のために参照により組み込むものである。
【背景技術】
【0002】
コンピューティングリソース及び関連データのセキュリティは、多くの状況で非常に重要である。一例として、コンピューティングデバイスのネットワークは、それらのユーザに強固なサービスのセットを提供するのに利用され得る。ネットワーク内で、第1のコンピュータ、システムまたはユーザは、第2のコンピュータ、システムまたはユーザを信頼し得る-すなわち、コンピュータ、システムまたはユーザには、第1のコンピュータ、システムまたはユーザのデータを生成、読出、更新及び/または削除する能力といった一定のアクセス権が付与され得る。第2のコンピュータ、システムまたはユーザもまた、第1のコンピュータ、システムまたはユーザに関連付けられたデータを格納するものとして信頼され得る。一例として、第1のコンピュータ、システムまたはユーザは、公開鍵を格納し公開鍵の所有権を証明するデジタル証明書に署名する認証局を信頼し得る。反対に、信頼できるコンピュータ、システムまたはユーザのアクセス権または権利を有していない、信頼できない他のコンピュータ、システムまたはユーザが存在し得る。さらに、信頼できるコンピュータ、システムまたはユーザに関連付けられたいくつかのアクセス権または権利を有する部分的に信頼できるコンピュータ、システムまたはユーザが存在し得る。コンピューティングリソースのそうした構成において、リソース及びデータへのアクセスが正しく管理されることを確保するのは、特にそうした構成のサイズ及び複雑性が増すにつれて、試練となり得る。
【0003】
最新の暗号アルゴリズムは、高レベルのデータセキュリティを提供する。例えば現在の暗号方式は、データへの不正アクセスには実現不可能な時間及び/またはリソースが要されるように、データを保護することができる。しかしながら、そうした高レベルの保護には代償が伴う。一般的に述べると、保護のレベルが高くなると、計算リソースのより高い保全レベルとその支出の増加が必要になる。さらに、保護のレベルが高くなると、例えば、暗号化サービスまたは認証局における1つまたは複数のサブ構成要素の信頼のレベルも高くする必要があり得る。2つ以上の機関の間に暗号保護された通信を確保することは、計算リソースの使用を低減させることまたはネットワークの様々なサブ構成要素に付与される信頼量を制限することが有利となり得るシステムにおいては特に、困難なこととなり得る。
【0004】
多様な技術を、図面を参照して説明する。
【図面の簡単な説明】
【0005】
図1】暗号保護された通信セッションが部分的に信頼できる暗号化サービスを用いて確立される環境の図である。
図2】部分的に信頼できる暗号化サービスを用いて楕円曲線ディフィーヘルマン鍵ペアを交換する環境の図である。
図3】部分的に信頼できる暗号化サービスを用いて楕円曲線ディフィーヘルマン鍵ペアを交換する環境の図である。
図4】2つのクライアントが暗号保護された通信セッションを確立する環境の図である。
図5】一実施形態による、第1のクライアントと第2のクライアントと暗号化サービスの間の通信を例示する図である。
図6】一実施形態による、第1のクライアントと第2のクライアントと暗号化サービスの間の通信を例示する図である。
図7】一実施形態による、暗号保護された通信セッションを確立する実例的なプロセスの図である。
図8】部分的に信頼できるクライアントを用いて暗号保護された通信を容易にする環境の図である。
図9】暗号保護された通信が送信され得る環境の図である。
図10】暗号保護された通信が受信され検証され得る環境の図である。
図11】暗号保護された通信の送信を例示する図である。
図12】暗号保護された通信の受信及び検証を例示する図である。
図13】暗号保護された通信を送信する実例的なプロセスの図である。
図14】暗号保護された通信を受信し検証する実例的なプロセスの図である。
図15】多様な実施形態を実行することができる環境の図である。
【発明を実施するための形態】
【0006】
本文書に記載された技術は、暗号保護された通信を容易にするために、部分的に信頼できるコンピュータシステムを用いることを含む。いくつかの例では、第1のコンピュータシステムは、部分的に信頼できる暗号化サービスを用いて第2のコンピュータシステムと通信する。部分的に信頼できるシステム(例えば暗号化サービス)は、いくつかの点では信頼できるが他の点では信頼できないコンピュータシステムであってもよい。例えば、部分的に信頼できる暗号化サービスは、デジタル署名を生成しデジタル署名の信頼性を検証するのに信頼できるものであってもよいが、第1のコンピュータシステムと第2のコンピュータシステムの間の暗号保護された通信にアクセスするのに用いることができるデジタル鍵へのアクセスにおいては信頼できないものであってもよい。そうしたシステムでは、部分的に信頼できる暗号化サービスは、第1のコンピュータシステムと第2のコンピュータシステムの間に暗号保護された通信セッションを確立するハンドシェイクプロセスの間、少なくとも部分的に用いられる場合があり、確立された暗号保護された通信セッションにアクセスできない場合がある。例えば、部分的にセキュアな暗号化サービスを少なくとも部分的に用いて、クライアントコンピュータとサーバの間に暗号化サービスによって復号化することができないトランスポート層セキュリティ(TLS)セッションを確立してもよい。
【0007】
別の例では、第1のコンピュータシステムは、暗号化データ鍵で暗号化された暗号保護された通信を第2のコンピュータシステムに送信する。該データ鍵は、第2のコンピュータシステムによってアクセス可能なものである。暗号保護された通信に含まれるデータは保護され得、第2のコンピュータシステムはデータを読み出し得るが、データを、第三者機関が検証不可能となるように修正することはできないようにする。すなわち、暗号保護された通信によるデータの任意の修正は、第三者機関が検出することができる。そうしたシステムでは、第1のコンピュータシステムは、暗号保護された通信を、信頼できない「中間者」コンピュータシステムを介して第2のコンピュータシステムに提供し得、第2のコンピュータシステムは、メッセージが「中間者」コンピュータシステムによって修正されたかどうかを検証し得る。
【0008】
一例として、2つのコンピュータシステムは暗号保護された通信セッションを確立し、ここでは、部分的に信頼できる第三者機関を利用して2つのコンピュータシステム間に信頼できる関係が確立されるが、部分的に信頼できる第三者機関は暗号保護された通信の一機関としては信頼できないものである。例えば、暗号化サービスは、クライアントとサーバの間にTLSセッションを確立するのに利用される部分的に信頼できる第三者機関として機能し得るが、暗号化サービスは、クライアントとサーバの間の暗号化された通信の内容を読み出すことは可能ではない。本例を続けると、暗号化サービスは、デジタル署名を生成するのにかつ真正なものであると称するデジタル署名が実際に真正なものであるかどうかを検証するのに信頼され得る。しかしながら、暗号化サービスは、クライアントとサーバの間の暗号保護された通信(例えばTLSセッション)で用いられる暗号化秘密鍵を格納しそれにアクセスするのに信頼できない場合がある。暗号化サービスがいくつかの点(例えばデジタル署名を生成し検証する)で信頼できる場合があり、他の点(例えば秘密鍵を格納する)で信頼できない場合がある理由には様々なものが存在し得る-クライアントとサーバの間の通信が特に機密性(例えば重要なビジネス、政府かつ/または軍事のデータ)のあるものであり得る、暗号化サービスが、あらゆる暗号化サービスをサポート可能ではないハードウェア構成を有する場合がある(例えば暗号化サービスは、セッションに十分な長さの暗号化鍵をサポートしない場合がある)、等といったことである。
【0009】
一例では、2つのクライアントは、部分的に信頼できる暗号化サービスを用いて、鍵交換を行い得る。第1のクライアントは、第1の楕円曲線ディフィーヘルマン(ECDH)鍵ペア、d及びQを生成し得、第1のクライアントの識別及び公開鍵Qを含むメッセージを生成し得る。第1のクライアントの識別は、例えばユーザID、GUID、マシンID、メディアアクセス制御アドレス(MACアドレス)などとして符号化され得る。さらに、第1のクライアントを識別するために動的IPアドレスなどの動的識別子が用いられ得る。第1のクライアントは、第1のクライアントの識別及び公開鍵を含むメッセージを、デジタル署名を要求して暗号化サービスに提供し得る。次いで、暗号化サービスは、第1のクライアントに関連付けられた暗号化鍵を用いてメッセージにデジタル署名し得、デジタル署名されたメッセージを第1のクライアントに戻して提供し得る。暗号化サービスは、暗号化サービスの各クライアントに固有の暗号化鍵が割り当てた暗号化鍵の格納部を有してもよい。暗号化サービスは、デジタル署名されたメッセージをコピーしてもよい。デジタル署名されたメッセージを受信すると、第1のクライアントは、デジタル署名されたメッセージを第2のクライアントに提供し得る。このことは、ハンドシェイクプロトコルの一部として起こり得る。第2のクライアントは、デジタル署名されたメッセージを受信すると、それを暗号化サービスに認証要求とともに提供することによって、デジタル署名されたメッセージの信頼性を検証し得る。場合によっては、デジタル署名は真正なものではない-すなわち、メッセージ及び/または署名は修正されたと判定され得る。これは、メッセージに対する意図的ではないまたは意図的な修正の結果であり得る。意図的ではない修正は、無線信号損失、パケット損失、データ破損、メモリ破損などから生じ得る。意図的な修正は、メッセージを取得(例えば送信中にルータで)しメッセージを修正する悪意のある機関から生じ得る。メッセージが真正なものではないと判定された場合、第2のクライアントは第1のメッセージを拒絶し得、ハンドシェイクは失敗し得る。
【0010】
しかしながら、先行段落におけるメッセージが真正なものであると判定された場合、第2のクライアントは、第1のクライアントの識別を抽出し、公開鍵Qを第1のクライアントに関連付け得る。次いで、第2のクライアントは、第2のECDH鍵ペアd及びQを生成し得、第2のクライアントの識別及び公開鍵Qを含む第2のメッセージを生成し得る。この第2のメッセージは、第1のメッセージと同様にデジタル署名され、送信され、検証され得る。第2のメッセージを受信しその信頼性を検証すると、第1のクライアントは、公開鍵Qを第2のクライアントに関連付け得る。公開鍵を交換した後で、第1のクライアント及び第2のクライアントは共有秘密鍵を計算することができる-第1のクライアントはdの楕円曲線点乗算を計算し、第2のクライアントはdの楕円曲線点乗算を計算する。楕円曲線ディフィーヘルマン鍵交換では、2つの値は等しく、鍵として、すなわち、TLSセッションなどの暗号保護された通信セッションを確立するのに用いられ得る秘密鍵を生成するために用いられ得る。確立されると、第1のクライアントと第2のクライアントは、暗号化サービスは共有秘密鍵を知らず、したがってTLSセッションで用いられる秘密鍵を知らないという保証のもと、暗号保護された通信セッションを介して通信し得る。このことにより、暗号化サービスは暗号保護された通信セッションに関与することができないので、セキュリティ保証は高められる。クライアントには、暗号化サービスは共有秘密鍵を計算して傍受することができない、すなわち上述のように生成された暗号保護された通信セッションに「中間者」攻撃を行うことができないことが保証される。
【0011】
いくつかの実施形態では、第1のコンピュータシステムはデータを第2のコンピュータシステムにエンベロープ暗号化を用いて送り得る。そうしたシステムでは、第1のコンピュータシステム及び第2のコンピュータシステムはどちらも暗号化データ鍵にアクセスできてもよい。第1のコンピュータシステムはデータ鍵を用いてメッセージを暗号化し得、該メッセージはその後第2のコンピュータシステムによってデータ鍵を用いて復号化され得る。しかしながら、いくつかの実施形態では、第2のコンピュータシステムがメッセージを修正したかどうかを検出することが望ましい場合があり、さらに、検出なしで第2のコンピュータシステムがメッセージを修正することを防ぐことが望ましい場合がある。この例では、暗号化サービスは、上記の例における動作とは異なる動作を行うことにおいて信頼され得る-この例では、暗号化サービスは、暗号化データ鍵を生成し、マスター鍵を格納し、マスター鍵を用いて暗号化動作及び復号化動作を行うのに信頼され得ることに留意されるべきである。
【0012】
前段の例を続けると、第1のクライアントは、暗号化データ鍵にアクセスできる第2のコンピュータシステムがデータを、修正を検出可能にしないで修正することができないように、暗号化データ鍵を用いて暗号化されるデータまたはメッセージを有してもよい。クライアントはまず、暗号化サービスに暗号化データ鍵を生成することを要求し得る。次いで、クライアントは、暗号化データ鍵を用いてメッセージを暗号化し得る。次いで、クライアントは、ECDH鍵ペアd及びQを生成し得る。暗号化されたメッセージのデジタル証明書は、dを用いて生成され得、Qを用いて暗号学的に検証可能である。次いで、クライアントは、暗号化サービスに、以下の入力:暗号化される平文としての暗号化データ鍵、及びECDH公開鍵Qを含む追加認証データ(AAD)、とともにマスター鍵を用いて認証付き暗号化を行うよう要求し得る。暗号化サービスは、認証付き暗号化を行う要求に応えて、マスター鍵のもとで暗号化アルゴリズムを用いてデータ鍵の暗号文及び暗号学的ハッシュ関数を用いてメッセージ認証(MAC)タグを生成する。次いで、デジタル署名され暗号化されたメッセージ、データ鍵の暗号文及びMACタグは1つまたは複数の受信者に送信される。
【0013】
受信者がデジタル署名され暗号化されたメッセージ、データ鍵の暗号文及びMACタグを受信すると、受信者は、メッセージが第1のクライアント以外の機関によって修正されたかどうかを検証することができる。受信者は、まず、MACタグからAADを抽出し、暗号化サービスに上記の認証付き暗号化に対応する復号化を行うことを要求し得る。復号化は、入力として、暗号文及びAADを受け取り得る。暗号化サービスは、AADが与えられた暗号文入力と一致しない場合、エラーを戻し得る。復号化動作に成功した場合、平文出力、及び暗号文入力を復号化するのに用いられる暗号化鍵に対応する鍵識別子が提供され得る。鍵識別子が、暗号化動作に用いられるマスター鍵に対応しない場合、エラー、またはメッセージが修正されているという他の表示が戻され得る。しかしながら、鍵識別子がマスター鍵と一致する場合、暗号化されたデータ鍵のデジタル署名は、公開鍵Qを用いて検証され得る。デジタル署名の検証後、データ鍵を含む平文出力を用いて、暗号文メッセージを復号化し得る。復号化されたメッセージは、署名の検証に用いられる公開鍵の結びつきにより、第1のクライアントによって送られたことが保証される。
【0014】
前述のかつ以下の説明では多様な技術が説明される。説明の目的のために、具体的な構成及び詳細が、技術の可能な実装方法の完全な理解を提供するために記載される。しかしながら、以下で説明される技術が具体的な詳細なしに様々な構成で実施され得ることも明らかとなるだろう。さらに、周知の特徴は、説明されている技術を不明瞭にしないために省略または簡略化され得る。
【0015】
図1は、本開示の様々な技術が利用され得る状況を例示する略図100を示す。この特定の例では、略図100は、暗号保護された通信セッション114を介して通信する第1のクライアント「クライアントA」102及び第2のクライアント「クライアントB」104を示す。暗号化サービス106は、クライアント104及び106によって、様々な暗号化動作を行うためにかつ暗号化鍵を格納しそれにアクセスするために利用され得る。メッセージ108は認証動作を行うために暗号化サービスに提供(例えばネットワークを介して送信)され得、デジタル署名110は検証動作を行うために暗号化サービス106に提供され得る。暗号化サービス106は、暗号保護された通信セッション114にアクセス112する十分な情報を有さなくてもよい。
【0016】
いくつかの例では、第1のクライアント102及び/または第2のクライアント104は、様々な種類のコンピューティングエンティティであり得る。いくつかの実施形態では、クライアント102及び104は、ネットワーク(例えばローカルエリアネットワーク)上の各コンピュータシステムであり得るが、インターネットを介して接続された異なるネットワーク上にも存在し得る。クライアント102及び104の一方または両方は、コンピュータサーバ、仮想マシンのインスタンス及び/または他のコンピューティングエンティティでもあり得る。
【0017】
暗号化サービス106は、複数の鍵格納部のうちの暗号化鍵へのアクセス(例えば、暗号化鍵を生成し提供することによって、または暗号化鍵を生成し提供するように動作可能である他のシステムを参照することによって)及びどのように暗号化鍵が鍵を要求するクライアントによって用いられるべきであるかのセキュリティ設定を提供し得る。いくつかの実施形態では、鍵格納部は、暗号化鍵を格納可能であるハードウェアセキュリティモジュール(HSM)によって実装され得る。鍵格納部は、暗号化サービス内に含まれる構成要素であってもよく、クライアント内に含まれる構成要素であってもよく、遠隔位置にあり暗号化サービスによって提供されるインタフェースを介してアクセス可能である構成要素であってもよく、それらの任意の組み合わせであってもよい。
【0018】
いくつかの実施形態では、暗号化サービスは、APIを介して、ジョブを介して、論理タスクとして、及び他の種類のルーティンとしてデータを暗号化するのに用いられ得る。一例として、暗号化()APIをサポートする暗号化サービスは、入力パラメータとして、暗号化するデータ、データの暗号化に用いられ得る暗号化鍵を固有識別する鍵識別子、暗号化されるデータを記述しているラベリングされたメタデータの暗号化コンテキスト、及び追加認証データ(AAD)のための任意選択的なパラメータを受信することができる。暗号化サービスは、API要求を受信し、鍵識別子から暗号化鍵を取得し、セキュリティポリシー、暗号化コンテキスト及びクライアントの暗号化能力に適合する複数の暗号化構成からある暗号化構成(例えば暗号化アルゴリズム及びブロックサイズ)を選択し得る。提供されたデータは、クライアントの暗号化能力にしたがって、鍵識別子の使用に少なくとも部分的によって取得された暗号化鍵を用いて、選択された暗号化構成にしたがって暗号化され得る。暗号化されたデータは、暗号化されたデータが暗号化構成及びデータを暗号化するのに用いられる暗号化鍵で復号化可能となるように利用可能とされ得る。この鍵は、クライアントのマスター鍵と称され得る。
【0019】
いくつかの実施形態では、暗号化サービスは、暗号化サービスによって暗号化されるデータが特定の形式に準拠することをチェックするように構成され得る。例えば、暗号化サービスは、暗号化される任意のデータが8キロバイト(KB)より小さいサイズでなくてはならいことをチェックするようにプログラミングされ得、それによりクライアントに、8KBよりも大きいデータは自ら暗号化させる。この制限は、例えば、マルチクライアント環境において複数のクライアントに対する暗号化サービスの拡張性及び性能を向上させることの検討に少なくとも部分的に基づくものであり得る。いくつかの実施形態では、暗号化サービスは、所要の限度を超えているデータを暗号化する要求を受信すると失敗を戻し得る。
【0020】
暗号化されるデータが、暗号化サービスによって課されるサイズの限度より大きい実施形態では、または他の状況では、クライアントは、データ鍵に対するアプリケーションプログラミングインタフェース要求を暗号化サービスに送信し得る。要求は、暗号化サービスによって管理される暗号化鍵(管理鍵)の鍵識別子を指定し得る。暗号化サービスは、データ鍵を生成し、またはそれ以外の方法で取得し、データ鍵を、管理鍵を用いて暗号化し得る。暗号化は、上述したような暗号化構成にしたがうものであってもよく、一般には、管理鍵に関連付けられたポリシーにしたがうものであってもよい。暗号化サービスは、データ鍵及び暗号化されたデータ鍵を含む、要求に対する応答を提供し得る。次いで、クライアントはデータ鍵を用いてデータを暗号化し、データ鍵の任意のメモリ内コピーを削除し、暗号化されたデータ鍵を暗号化されたデータに関連させて(例えば、暗号化されたデータと一緒に、または、暗号化されたデータ鍵を暗号化されたデータに関連付けるデータベースに)格納し得る。データは、暗号化されたデータ鍵を復号化する要求を暗号化サービスに送信(鍵識別子を指定)することによって暗号化され得る。暗号化サービスは、要求に応答して、管理鍵を選択し、暗号化されたデータ鍵を復号化し、復号化されたデータ鍵を提供することによって、クライアントがデータ鍵を用いてデータを復号化することを可能にし得る。
【0021】
いくつかの実施形態では、暗号化サービスは、追加の機能性を提供し得る。例えば、暗号化サービスは、例えばAPIを介して、ジョブを介して、論理タスクとして、他の種類のルーティンとしてメッセージまたはデータを認証するように構成され得る。第1のクライアント102などのクライアントは、暗号化サービスに、認証されるメッセージ108を提供し得る。それに応じて、暗号化サービスは、入力メッセージまたはデータ(例えば図1に示すメッセージ108)及び暗号化鍵を入力として受け取る暗号学的ハッシュ関数を用いてメッセージ認証コード(MAC)タグを生成し得る。いくつかの実施形態では、暗号学的ハッシュ関数で用いられる暗号化鍵は、呼び出しクライアントの識別に結びつけられ得(すなわち、暗号化鍵は、呼び出しクライアントの識別に基づいて選択される)、他の実施形態では、暗号化鍵に対する鍵識別子はクライアントによって提供され得る。暗号学的ハッシュ関数は、出力としてMACタグを生成し得、暗号化サービスは、メッセージまたはデータを認証する要求に応えてMACタグを提供し得る。整合性及び信頼性の保証を提供する他の方法が用いられ得ることに留意すべきである。整合性とは、メッセージまたはデータが悪意を持ってでも誤ってでも修正されないことの保証を指し得、信頼性とは、メッセージまたはデータの書き手の保証を指し得る。例えば、暗号化サービスは、デジタル署名を生成することによって、メッセージまたはデータを認証し得る。
【0022】
いくつかの実施形態では、暗号化サービスは、例えばAPIを介して、ジョブを介して、論理タスクとして、他の種類のルーティンとして追加の機能性を提供し得る。例えば、暗号化サービスは、MACタグ、デジタル署名などを検証するように構成され得る。第2のクライアント104などのクライアントは、暗号化サービスに、検証されるMACタグ110を提供し得る。それに応じて、暗号化サービスは、計算されたMACタグを、暗号化サービスがメッセージ及び暗号化鍵から生成するMACタグと比較することによって、MACタグの信頼性を検証し得る。計算されたMACタグと提供されたMACタグが一致する場合、検証はメッセージが真正なものであることを示すだろう。
【0023】
様々な実施形態では、暗号保護された通信114は、2つ以上の機関の間で、他の機関によるデータのアクセス、読み出しまたは修正を防ぐようにデータを送信する目的のために用いられる。暗号保護された通信はまた、ソース由来であると称する通信が実際に称されたソースからのものであることを保証し得、いくつかの実施形態では、受信者によって暗号学的に検証可能であり得る。暗号保護された通信とは、例えば、2つ以上のエンティティ間でネットワークを横断するデータの整合性を確保しかつ/またはデータがネットワークを横断するときのデータの機密性を確保するために用いられることを指し得る。
【0024】
例えば、図1に示された暗号保護された通信114は、第1のクライアント102及び第2のクライアント104が共有秘密鍵を利用して暗号化されたセッション全体に通信の機密性を確保する暗号化されたセッションであってもよい。暗号化されたセッションの一例は、RFC5246に記載されるようなトランスポートセキュリティ層(TLS)セッションであり、これは本明細書によって参照により組み込まれる。しかしながら、暗号保護された通信は、暗号化される必要はない-例えば、いくつかの実施形態では、暗号保護された通信114は、整合性の保証は提供するが機密性の保証は提供しなくてもよく、第三者機関が暗号保護された通信の内容を読み出すことは可能とするが、暗号保護された通信を通信の有効性を損なうことなく修正することは不可能とする。いくつかの実施形態では、暗号保護された通信を確立するために、MACタグ、デジタル署名などが利用され得る。
【0025】
様々な実施形態では、暗号保護された通信セッションは、リソースにアクセスする目的のために用いられる。暗号保護された通信セッションは、例えば、クライアントからサーバにまたはクライアントからサーバにというように1つのエンティティから別のエンティティにデータを転送するために用いられ得る。暗号保護された通信セッションは、エンティティ間でネットワークを横断するデータの整合性を確保するために、かつ/または、データがネットワークを横断するときのデータの機密性を確保するために用いられ得る。
【0026】
いくつかの実施形態では、暗号化サービスは、暗号保護された通信にアクセス112できなくてもよい。暗号保護された通信へのアクセスとは、例えばセッションでメッセージを送受信することによって通信セッションに関与する能力を有する暗号化サービスを指し得る。いくつかの実施形態では、暗号化サービスは、暗号保護された通信で指定されたプロトコルを介して暗号化されたデータを復号化不可能であってもよい(例えば、暗号化サービスは、クライアント間のTLSセッションで送られるデータを復号化不可能である)。暗号化サービスは、コンピューティング環境でいくつかの暗号化鍵にアクセスでき得るが(例えばクライアントマスター鍵)、暗号保護された通信にアクセスするのに必要な他の情報にアクセスできない場合がある(例えば、第1のクライアント102と第2のクライアント104の間の共有秘密鍵は暗号化サービスに秘匿され得る)。いくつかの実施形態では、アクセス112とは、通信を修正するという暗号化サービスの能力を指し得る。例えば通信は、暗号化サービスがアクセスできない秘密鍵を用いて生成されたデジタル署名を含むので、例えば、暗号化サービスは、クライアント102とクライアント104の間の通信を読み出す能力を有し得るが、通信を修正することは不可能であり得る。
【0027】
図2は、部分的に信頼できる暗号化サービス206を用いてECDH鍵ペアを交換する例示的な環境200を示す。第1のクライアント202は、秘密鍵d及び公開鍵Qを含むECDH鍵ペア208を有し得る。ECDH鍵ペアは図2に例示された実施形態に示されるが、この開示にしたがって他の種類の非対称鍵ペアも利用され得ることに留意されるべきである。いくつかの実施形態では、クライアント202は、鍵交換プロセス中にECDH鍵ペアを生成し得るが、他の実施形態では、鍵ペアは、予め生成され得、または、例えば図2に示さないハードウェアセキュリティモジュール(HSM)などの信頼できるソースによってクライアント202に提供され得る。図2に示すクライアント202及び204は、例えば、図1に関連して上述したクライアントと同種であってもよい。
【0028】
いくつかの実施形態では、暗号化サービス206は、認証動作及び検証動作を行うのに信頼され得るが、クライアント202と204の間の暗号保護された通信セッションにアクセスするなどの他の動作を行うのに十分に信頼されなくてもよい。いくつかの実施形態では、暗号保護された通信セッションへのアクセスを暗号化サービスに提供することは構造的に問題があり得る。いくつかの実施形態では、暗号化サービスは、クライアント202及び204以外の機関によって潜在的にアクセス可能であり得る。いくつかの実施形態では、暗号化サービスに共有秘密鍵を提供しないことには利点が存在し得る-例えば、暗号化サービスは、そうした状況下では、多数のクライアントが共有秘密鍵を有する暗号化サービスを信頼した場合、悪意ある攻撃の識別可能な標的となり得る。
【0029】
いくつかの実施形態では、暗号化サービス206は、暗号化鍵のセットを、例えば図2に示さないハードウェアセキュリティモジュール(HSM)に格納し得る。暗号化サービスは、各クライアントマスター鍵が特定のクライアントに関連付けられ所有されるクライアントマスター鍵のセットを有し得る。クライアントマスター鍵は、暗号化サービスが、例えば、なりすまし攻撃を防ぐために登録者にパスワードの入力、セキュリティトークンの提供または登録者の識別の他の証明の提供を要することによって、登録者との間に信頼関係を確立する登録プロセスの一部としてそれらのそれぞれのクライアントに関連付けられ得る。
【0030】
暗号化サービス206によって、呼び出し元はいくつかの暗号化動作を行うことが可能になり得る。特定のクライアントは、暗号化サービスを呼び出して各種暗号化動作を行い得、いくつかの実施形態では、他のクライアントがその暗号化鍵を用いて、暗号化サービスによってサポートされる暗号化動作の全てまたは一部を行うことを可能にし得る。例えば、特定のクライアントは、そのクライアントマスター鍵を用いて、特定のメッセージがそのクライアントサービスからもたらされたものであることを証明するデジタル署名を生成し得る。前の例に関して、他のクライアントは、暗号化サービスにデジタル証明書が有効かどうかを検証することを要求し得る。いくつかの実施形態では、暗号化サービスはまた、クライアントによって、データを暗号化して暗号文出力を生成すること及びデータを復号化して平文出力(例えば複数層の暗号化がデータに適用されるとき、まだ難読化されている場合がある)を生成することにも使用可能であってもよい。これらの動作は、暗号化サービスによって安全に格納されているクライアントマスター鍵を用いて行われ得る。
【0031】
暗号化サービスはまた、認証付き暗号化動作も提供し得る。いくつかの実施形態では、暗号化サービスは、暗号化(鍵ID、データ、AAD)要求、APIまたはコマンドをサポートし得る。鍵IDは、特定のクライアントに関連付けられ得、暗号化サービスによって特定のクライアントマスター鍵に内部的に関連付けられ得る。いくつかの実施形態では、鍵IDは任意選択的な入力であってもよく、または、暗黙的であってもよい(例えば呼び出し元の識別を用いて鍵IDを判定し得る)。追加認証データ(AAD)は、様々な目的のために使用されてもよく、必ずしも暗号化されていないが例えば電子署名、メッセージ認証コード、または、一般にAADとともに含まれる鍵付きハッシュ値によって認証されているデータであってもよい。いくつかの実施形態では、暗号文は、AADの少なくとも一部を含んで生成される。いくつかの他の実施形態では、AADは、復号化の際、別に提供される。いくつかの他の実施形態では、AADは、要求、及び/またはメタデータが通過するときにのみ復号化が成功するような他のメタデータに少なくとも部分的に基づいて、復号化時に生成される。いくつかの実施形態では、ポリシーは、暗号化動作を特定のAADに対して行うことができるかどうかを制限し得る。暗号化(鍵ID、データ、AAD)要求の処理は、暗号化サービスによって実行されるプログラミング論理及び/またはポリシーによって、AADが特定の値を含むこと及びAADが真正なものであること(例えば元の送信から修正されていない)の両方を必要とし得る。同様に、復号化(鍵ID、暗号文、AAD、タグ)要求は、暗号化サービスに、鍵IDによって識別される鍵を用いて、指定された暗号文を復号化させるのに用いられ得る。上述のような復号化(鍵ID、暗号文、AAD、タグ)要求のAADは、入力タグと比較される認証タグを生成するのに用いられ得る。例えば、復号化(鍵ID、暗号文、AAD、タグ)の処理は、暗号化サービスによって実行されるプログラミング論理及び/またはポリシーによって、AADが特定の値を含むこと及びAADが真正なものであること(例えば元の送信から修正されていない)の両方を必要とし得る。いくつかの実施形態では、復号化()要求は、生成された認証タグが入力タグと一致しない場合失敗となるだろう。
【0032】
いくつかの実施形態では、暗号化()APIは、暗号文に関連するメタデータを生成する。例えば、暗号化()APIは暗号文を生成し、それを、暗号化動作に用いられる鍵IDを含むメタデータに追加し得る。そうした実施形態では、復号化()APIは、入力として鍵IDを必要としなくてもよい(すなわち、復号化(暗号文、AAD、タグ)要求が、復号化(鍵ID、暗号文、AAD、タグ)要求に置換し得るまたは代替となり得る)。いくつかの実施形態では、暗号化サービスは、暗号化動作中に暗号文及びメタデータ全体に認証タグを生成し、正しい暗号化鍵が復号化に用いられることを確保するために復号化中に認証タグを検証し得る。
【0033】
いくつかの実施形態では、ECDH鍵ペア208は、クライアント202によって生成される。ECDH鍵ペアは、秘密鍵d及び公開鍵Qを含み得る。しかしながら、他の種類の非対称鍵ペアが代わりに生成され得、秘密鍵は他の機関に秘匿され得る。ECDH鍵ペアは、例えばハンドシェイクプロトコルの一部として生成され得、または、予め生成され得る(例えば、1つまたは複数のECDH鍵ペアはある時点で生成され、その後暗号保護された通信セッションが形成されるときに使用するために、配布される)。いくつかの実施形態では、ECDH鍵ペアは、一度のセッションのみで使用可能でありその後は無効となる一時的な暗号化鍵であってもよい。いくつかの実施形態では、ECDH鍵ペアは、単一のメッセージにのみ使用可能であってもよく、その後は無効となる(第2のメッセージに対して第2のECDH鍵ペアを必要とする)。
【0034】
メッセージ210は、第1のクライアント202によって生成され得、少なくとも送信者の識別及び公開鍵を含む。メッセージを用いて、公開鍵が送信者に関連付けられていること及び送信者が対応する秘密鍵の所有権を有していることを証明することによって、送信者の識別子を公開鍵に結びつかせ得る。この状況の結びつきとは、暗号化公開鍵とクライアントまたは対応する暗号化秘密鍵にアクセスできるエンティティの関連付けを指し得る。結びつきは暗黙的であってもよく(例えば、プロトコルは、公開鍵及びクライアントIDを含むメッセージまたはメッセージフォーマットが鍵をクライアントに結びつけることを定義する)、または、メッセージ内で明示的に記述されてもよい。いくつかの実施形態では、暗号化公開鍵を送信者情報に結びつけるメッセージはデジタル署名され得、または、MACタグがその結びつき全体に生成され得る。
【0035】
第1のクライアントの識別は、例えばユーザID、GUID、マシンID、メディアアクセス制御アドレス(MACアドレス)などとして符号化され得る。さらに、第1のクライアントを識別するために動的IPアドレスなどの動的識別子が用いられ得る。メッセージ210は暗号保護された通信セッションを確立するハンドシェイクプロトコルの一部として暗号化サービスに提供され得る。メッセージ210は、メッセージを認証する要求とともに暗号化サービスに提供され得る。認証は、暗号化サービスによって、第1のクライアント202に関連付けられたクライアントマスター鍵を用いて行われ得る。クライアントは、鍵識別子を要求の一部として暗号化サービスに提供し得る。いくつかの実施形態では、暗号化サービスは、セキュリティチェック及びパラメータチェックを行って、例えばクライアントがデータを認証するまたはより具体的にはデータを具体的な鍵識別子のもとで認証する十分な権利を有することが要求においてチェックされていることを確保し得る。いくつかの実施形態では、メッセージはまた、認証動作で用いられる鍵に対応する鍵識別子、対応する検証動作で用いられ得る鍵に対応する鍵識別子、またはその両方も含み得る。
【0036】
いくつかの実施形態では、認証要求は、暗号化サービスによって、暗号学的ハッシュ関数を用いてメッセージの内容全体にMACタグを生成することによって処理される。MACタグ212は、暗号化サービスによって第1のクライアント202に例えば応答の一部として提供され得る。MACタグ212は、同期的にまたは非同期的に提供され得る。いくつかの実施形態では、MACタグではなくデジタル署名が、第1のクライアント202に関連付けられた暗号化秘密鍵を用いて生成され得る。そうした実施形態では、対応する暗号化公開鍵を用いて、デジタル署名の信頼性を検証し得る。公開鍵は、いくつかの実施形態では、やはり暗号化サービスに格納され得るが、他の実施形態では、例えば認証局(図2に示さず)といった別のエンティティを用いて格納され得る。MACタグならびに送信クライアント情報及び公開鍵Qを含むメッセージは、第2のクライアント204に提供され得る。いくつかの実施形態では、第1のクライアント202は、前述のデータを、例えばネットワーク接続を介して直接第2のクライアント204に送信し得る。他の実施形態では、第1のクライアント202は、前述のデータを、例えば第2のクライアント204がそこから取得し得る所定の場所に前述の情報を格納することによって、第2のクライアント204に間接的に送信し得る。
【0037】
いくつかの実施形態では、第2のクライアントは、送信者識別情報及び公開鍵Qを含むメッセージならびにメッセージの信頼性を証明するMACタグを受信し得る。第2のクライアントは、メッセージ及びMACタグを、メッセージの信頼性を検証する要求とともに暗号化サービス206に提供し得る。いくつかの実施形態では、第2のクライアント204は、検証動作で用いられる暗号化鍵に対応する鍵識別子も提供し得る。暗号化サービス206は、いくつかの実施形態では、MACタグ付きのメッセージが真正なものであることを判定し、情報が有効であるという表示214を提供し得る。いくつかの実施形態では、検証動作が失敗するとすなわちメッセージは真正なものではないと判定すると、失敗の表示が、成功の表示に加えて、または、その代わりに提供され得る。メッセージが有効であると判定すると(例えば情報が有効であるという表示214を受信すると)、第2のクライアント204は、メッセージに含まれる公開鍵Qを取得し得る。公開鍵は短期記憶に保持、アーカイブ、キャッシュまたは格納され得る。
【0038】
代替の実施形態では、環境200に示される鍵交換は、暗号化及び復号化を用いて行われ得る。例えば、第1のクライアント202は、送信者識別情報及び公開鍵Qを有するメッセージ210を、暗号化サービスに、メッセージ210を暗号化する要求とともに提供し得る。暗号化サービスは、クライアントマスター鍵を用いてメッセージを暗号化し、暗号化されたメッセージを第1のクライアント202に戻し、第1のクライアント202は次いで、暗号化されたメッセージを第2のクライアント204に提供し得る。第2のクライアントは、暗号化されたメッセージを、復号化要求の一部として暗号化サービスに提供し得、暗号化サービスは、メッセージを復号化し得、要求を満たす一部として、第2のクライアント204に応えてメッセージを復号化するのに用いられるクライアントマスター鍵に対応する鍵識別子を提供し得る。応答を受信すると、第2のクライアント204は、メッセージを復号化するのに用いられる鍵識別子が第1のクライアント202に対応することを確認し得る。第1のクライアント202がそのカスタマーマスター鍵を用いて暗号化のために他の機関へのアクセスを許可しない限り、第2のクライアント204には、暗号化されたメッセージに含まれる公開鍵が第1のクライアントからのものであり第1のクライアントとの間の暗号保護された通信に使用可能であることが保証され得る。そうした実施形態では、第2のクライアント204は、認証されていない公開鍵を扱う必要はなくてもよく、一方、図2にしたがったいくつかの実施形態のもとでは、第2のクライアント204は、情報が有効であるという表示214を受信する前に、公開鍵がまだ認証されていないという理由で使用可能ではないメッセージから平文の公開鍵Qにアクセスできてもよい。
【0039】
いくつかの実施形態では、暗号化されたメッセージは、公開鍵Qを含むことに加えて、第1のクライアント202が第2のクライアント204に暗号保護された通信セッションを確立する前にその承認を求めるノンスも含み得る。例えば、ハンドシェイクプロトコルの一部として、第1のクライアント202は、第2のクライアント204からの公開鍵Q(例えば図3に関連して)の受け入れを、それがノンスを伴わない場合に拒絶し得る。応答がノンスを含むことを求めることは、いくつかの実施形態では、リプレイ攻撃を防ぐことによって追加のセキュリティまたは第1のクライアント202が第2のクライアント204から受信するメッセージの鮮度保証を提供し得る。いくつかの実施形態では、ノンスとしてタイムスタンプが挙げられ得る。
【0040】
図3は、部分的に信頼できる暗号化サービス306を用いてECDH鍵ペアを交換する例示的な環境300を示す。第1のクライアント302、第2のクライアント304及び暗号化サービス306は、図1及び2にしたがって上述されたものと同種であってもよい。ECDH鍵ペア308は、秘密鍵d及び公開鍵Qを含み得、秘密鍵dは環境において他の構成要素に秘匿されている。ECDH鍵ペア308は、第1のクライアント302によってハンドシェイクプロトコルの一部として生成され得る。第2のクライアント304は、公開鍵Q310を有し得る。さらに、第2のクライアント304は、秘密鍵d及び公開鍵Qを含む第2のECDH鍵ペア312を有し得る。第2のクライアントの公開鍵Q320は、第1のクライアント302に、図2に記載された鍵交換と同様にして提供され得る。第2のクライアントの識別情報及び公開鍵Qを有するメッセージ314は暗号化サービス306に認証要求の一部として提供され得、MACタグ316は、第2のクライアント304に関連付けられたカスタマーマスター鍵を用いて生成され、第2のクライアント304に提供され、第1のクライアント302に転送され得る。第1のクライアントは、メッセージ及びMACタグを、メッセージの信頼性を判定する検証要求の一部として提供して、メッセージが実際にクライアントB304によって書かれたものであるかどうかを判定し得る。メッセージが真正なものであるという表示318が行われると、クライアントA302は、公開鍵Qを、クライアントB304との間に共有秘密鍵を確立するのに用いるために格納し得る。共有秘密鍵は、例えば、クライアント間に暗号保護された通信セッションを確立するために用いられ得る。公開鍵Qも、図2に関連する上記と同一にまたは同様にして認証動作及び検証動作の代わりに暗号化動作及び復号化動作を用いて交換され得る。
【0041】
図4は、2つのクライアントが暗号保護された通信セッションを確立する例示的な環境400を示す。第1のクライアント402、第2のクライアント404及び暗号化サービス406は、図1~3にしたがって上述されたものと同種であってもよい。いくつかの実施形態では、第1のクライアント402は、秘密鍵d及び公開鍵Qを含むECDH鍵ペアを生成していてもよく、公開鍵Qは、場合によっては図2に上述された実施形態にしたがって、第2のクライアント404に配布されている。同様に、第2のクライアント404は、秘密鍵d及び公開鍵Qを含む第2のECDH鍵ペアを生成していてもよく、公開鍵Qは、場合によっては図2~3に記載された実施形態にしたがって、第1のクライアント402に配布されている。
【0042】
いくつかの実施形態では、第1のクライアント402は、少なくともd及びQを用いて生成され得る共有秘密鍵406を有し、第2のクライアント404は、少なくともd及びQを用いて生成され得る共有秘密鍵408を有する。楕円曲線ディフィーヘルマン鍵交換プロトコルを用いた実施形態では、d=dなので共有秘密鍵は両方の機関によって計算され得る。暗号保護された通信セッション410は、共有秘密鍵を用いて確立され得る。いくつかの実施形態では、暗号化サービス406は、秘密鍵d及びdの両方にアクセスできなくてもよく、暗号保護された通信セッションにアクセス412可能とならないであろう。いくつかの実施形態では、暗号保護された通信セッション410へのアクセス412とは、例えばセッションでメッセージを送受信することによって通信セッションに関与する能力を有する暗号化サービスを指し得る。いくつかの実施形態では、暗号化サービスは、暗号保護された通信で指定されたプロトコルを介して暗号化されるデータを復号化できなくてもよい(例えば、暗号化サービスは、クライアント間でTLSセッションを介して送信されるデータを復号化できない)。暗号化サービスはコンピューティング環境においていくつかの暗号化鍵にアクセスできてもよいが(例えばクライアントマスター鍵)、暗号保護された通信にアクセスするのに必要な他の情報にアクセスできなくてもよい(例えば、共有秘密鍵406及び408、ならびに/または秘密鍵d及びd)。いくつかの実施形態では、アクセス412とは、通信を修正するという暗号化サービスの能力を指し得る。例えば、暗号化サービスは、クライアント402とクライアント404の間の通信を読み出す能力を有してもよいが、例えば通信は暗号化サービスがアクセスできない秘密鍵を用いて生成されたデジタル署名を含むという理由で、通信を修正不可能であってもよい。
【0043】
図5は、ある実施形態による第1のクライアント502と第2のクライアント504と暗号化サービス506の間のハンドシェイクプロトコルを例示する図を示す。ハンドシェイクプロトコルの一部として、第1のクライアントは、秘密鍵d及び公開鍵Qを含むECDH鍵ペアを生成508し得る。いくつかの実施形態では、ECDH鍵ペアは、ハンドシェイクが始まる前に予め生成され得る。
【0044】
ECDH鍵ペアが生成された後で、クライアントAは、送信者及び公開鍵Qを識別するメッセージを生成510し得る。メッセージは、図1~3に関連して上述されたものにしたがうものであってもよい。次いで、クライアントAは、メッセージを暗号化サービスに認証を受けるために提供512し得る。いくつかの実施形態では、メッセージは、暗号化サービスにウェブAPIを通じて提供され得る。暗号化サービス506は、暗号化鍵を用いてメッセージ全体にデジタル署名またはMACタグを生成し得る。クライアントAは、暗号化サービスに、認証要求の一部として、メッセージを認証するために暗号化サービスによって用いられる暗号化鍵に対応する固有識別子を提供し得る。いくつかの実施形態では、鍵識別子はメッセージで提供され得るが、他の実施形態では、鍵識別子は、ウェブAPI要求で別のパラメータとして提供され得、さらに別の実施形態では、鍵識別子は、呼び出し元の識別に基づいて暗黙的であり得る。暗号化サービスは、クライアントAに、メッセージ及びMACタグを含む認証されたメッセージを戻し得る。いくつかの実施形態では、クライアントAは、元のメッセージのコピーを保持し得、暗号化サービスはMACタグを戻す。
【0045】
いくつかの実施形態では、クライアントAは、認証されたメッセージを含む暗号保護された通信セッションの要求をクライアントBに提供514し得る。要求は、例えば、図1~3に関連して上述されたものなどの要求であってもよい。要求は、クライアントAの識別情報及び公開鍵Qを含むメッセージングならびに対応するMACタグを含み得る。
【0046】
いくつかの実施形態では、クライアントBは、認証されたメッセージを含む暗号保護された通信セッションを確立する要求を受信516し得る。いくつかの実施形態では、クライアントBは、要求をクライアントAから間接的に受信する-例えば、クライアントAは、要求を、クライアントBに要求を転送する中間クライアントX(示さず)を通して送信し得る。いくつかの実施形態では、中間は別のコンピュータシステムであってもよいが、ルータまたはスイッチといったメッセージを修正可能な他の種類のコンピューティングエンティティでもよいことに留意されたい。したがって、要求を受信すると、クライアントBは、要求が真正なものであるかどうか、及び、クライアントAによって送られたときから内容が修正されていないことを検証する必要があり得る。場合によっては、クライアントAのメッセージを傍受する悪意ある機関は、例えば暗号保護された通信セッションを構成する公開鍵Qを修正しようと試みることがある。
【0047】
いくつかの実施形態では、クライアントBは、認証されたメッセージを暗号化サービス506に提供518し、暗号化サービスに、認証されたメッセージを検証するように要求し得る。暗号化サービス506は、クライアントBから、認証されたメッセージをその信頼性を検証する命令とともに受信し得る。認証されたメッセージを検証する要求の一部として鍵識別子も提供され得る。いくつかの実施形態では、暗号化鍵が取得され、MACタグがメッセージ全体に生成され、生成されたMACタグは、受信されたMACタグと比較されて、メッセージが真正なものであるかどうかを判定する。いくつかの実施形態では、暗号化サービスは、MACタグの代わりに受信されるデジタル署名を受信し、デジタル署名を生成し、生成されたデジタル署名を受信されたデジタル署名と比較し得る。メッセージが真正なものであることを検証した後で、クライアントB504は、公開鍵Qを抽出し、ECDH鍵ペアd及びQを生成520し、d及びQを用いて共有秘密鍵を計算522し得る。
【0048】
ECDH公開鍵Qを受信した後で、クライアントB604は、例えば図6に記載されたように、ECDH公開鍵QをクライアントA602と交換し得る。環境600は、図5に関連して上述された環境500と同一のまたは同様の環境であってもよい。公開鍵Qの交換は、ハンドシェイクプロトコルの一部であってもよく、暗号保護された通信セッションを確立する図5に示す流れの後に生じてもよい。鍵は、図5(具体的には、ステップ520を参照)に関連して上述された流れの際に等、別のところで生成され得ることに留意するべきである。クライアントBは、クライアントBとしての送信者識別及び公開鍵Qを識別するメッセージを生成610し、メッセージを暗号化サービス606に認証を受けるために提供し得、暗号化サービス606は、メッセージを、例えばメッセージ全体にMACタグまたはデジタル署名を生成することによって、認証612し、認証されたメッセージをクライアントB604に提供し得る。これらのステップは、図5に関連して上述した対応するステップにしたがって行われ得る。クライアントBは、暗号保護された通信セッションを確立する要求に応答614し得、応答の一部として、認証されたメッセージを含み得る。クライアントAは、応答を受信616し、暗号化サービスを用いることによって検証を行って、応答における認証されたメッセージが有効かどうかを判定し得る。要求が有効であると判定された場合、公開鍵Qを用いて、例えば楕円曲線ディフィーヘルマン鍵交換のd及びQを用いた共有秘密鍵を計算620することができる。
【0049】
両方の機関が共有秘密鍵620及び622を計算すると、暗号保護された通信セッションは、共有秘密鍵を用いて確立され得る。確立されると、クライアントAとクライアントBは、暗号化サービスは共有秘密鍵を知らずしたがって暗号保護された通信セッションで用いられる秘密鍵を知らないという保証のもと、暗号保護された通信を介して通信し得る。このことにより、暗号化サービスも、公開鍵Q及びQを含む認証されたメッセージを傍受し得る任意の他の機関も、暗号保護された通信セッションに関与することができないので、セキュリティ保証は高められる。
【0050】
図7は、ある実施形態によるハンドシェイクを行うプロセス700の具体例を示す。プロセス700は、図1~6に上述したクライアントにしたがって記載されたコンピュータシステムなどの任意の適切なシステムによって行われ得る。しかしながら、プロセス700は、ハンドシェイクプロセスに関与する任意のコンピュータシステムによって行われ得ることに留意されたい。また、ハンドシェイクプロセスは、ハンドシェイクプロトコル及びレコードプロトコルを含む暗号保護された通信セッションのためのプロトコルといった、暗号保護された通信セッションの確立のための任意のハンドシェイクであってもよいことにも留意されたい。ある実施形態では、プロセス700を行うシステムは、第1の秘密鍵及び第1の公開鍵を含む第1の非対称鍵ペアを生成702し得る。いくつかの実施形態では、非対称鍵ペアは楕円曲線鍵ペアであってもよい。システムはまた、送信者識別情報及び第1の公開鍵を含む第1のメッセージも生成704し得る。第1のメッセージは、段階702で非対称鍵ペアを生成するより前に部分的に生成され得ることに留意されたい。例えば、いくつかの実施形態では、メッセージは、第1の非対称鍵ペアを生成するより前に部分的に生成され得る。送信者識別情報は、例えばユーザID、GUID、マシンID、メディアアクセス制御アドレス(MACアドレス)などとして符号化され得る。さらに、動的IPアドレスなどの動的識別子を用いて送信者の識別を識別し得る。
【0051】
いくつかの実施形態では、システムは次いで、暗号化サービスに、少なくとも送信者識別情報及び第1の公開鍵を含む第1のメッセージを提供706し得る。いくつかの実施形態では、システムは、代わりに、送信者識別情報及び第1の公開鍵を暗号化サービスに別々に送信し得、暗号化サービスは、少なくとも送信者識別情報及び第1の公開鍵を受信した後で、送信者識別情報及び第1の公開鍵の両方全体にMACタグまたはデジタル署名を生成し得る。
【0052】
システムは、第1のメッセージを暗号化サービスに提供後、暗号化サービスから、第1のメッセージに対応する第1の認証されたメッセージを受信708し得、該第1の認証されたメッセージは第2のクライアントによって検証することができるものである。認証されたメッセージは、元のメッセージまたは送信者識別情報及び公開鍵を含む別のメッセージ、ならびに対応するMACタグを含み得る。認証されたメッセージは、暗号保護された通信セッションがそれとともに確立されるクライアントによって暗号学的に検証可能でなければならない。いくつかの実施形態では、MACタグを検証することは、暗号化サービスによって保護され得る暗号化鍵へのアクセスを必要とし得る。そうした実施形態では、MACタグを検証しようとする呼び出し元のサブセットは、暗号化サービスから、呼び出し元は検証要求を完了するのに必要なリソースにアクセスできないことを示すエラーを受信し得る。他の実施形態では、失敗の表示が、検証動作を行うのに必要な暗号化鍵がアクセス可能でなかったことをさらに示さないように、一般的なエラーが提供される。いくつかの実施形態では、真正なものであるメッセージは、送信者識別情報及び/または公開鍵が暗号化サービスによってアクセス可能な暗号化鍵を用いて暗号化されるように、暗号化され得、暗号保護された通信セッションをそれとともにシステムが確立しようとしているクライアントによって復号化され得る。
【0053】
次いで、システムは、暗号保護された通信セッションをそれとともに確立するクライアントを識別し、第1の認証されたメッセージをそのクライアントに提供710し得る。認証されたメッセージは、直接的に(例えばメッセージはハンドシェイクプロトコルまたは要求の一部として含まれる)または間接的に(例えば、認証されたメッセージを配置し取得するのに用いられ得るユニフォームリソース識別子(URI)が提供される)提供され得る。いくつかの実施形態では、要求は、1つもしくは複数のコンピュータシステム、または、認証されたメッセージの内容を検査かつ/もしくは修正する能力を有し得るルータもしくはスイッチといったコンピューティングエンティティを通過してもよいことに留意されたい。しかしながら、MACタグの正しく対応する修正なしでのメッセージ内容の修正は、検出可能であろう。
【0054】
いくつかの実施形態では、システムは、暗号保護された通信セッションをそれとともに確立するクライアントから、第2の認証されたメッセージを受信712し得る。いくつかの実施形態では、第2の認証されたメッセージは、識別情報及び第2の公開鍵を含むメッセージならびにメッセージが真正なものであることを検証するのに用いられ得るMACタグを備える。いくつかの実施形態では、真正なものであるメッセージは、第2の公開鍵の暗号文及び/または第2のクライアントの識別情報を備える。システムは、暗号化サービスを用いて、第2の認証されたメッセージの信頼性を検証714し得る。いくつかの実施形態では、MACタグはメッセージ全体に生成され、生成されたMACタグは提供されたMACタグと比較され、いくつかの実施形態では、デジタル署名が検証され得る。いくつかの実施形態では、認証されたメッセージは、復号化されかつ用いられた暗号化鍵は他の機関がメッセージを暗号化し得ないように第2のクライアントに関連付けられていることを検証することによって検証される暗号化されたメッセージであってもよい。検証がメッセージが真正なものであることの判定に成功した場合、システムは、少なくとも第2の公開鍵及び第1の秘密鍵を用いて共有秘密鍵を生成716または計算し得る。いくつかの実施形態では、第2の公開鍵は、楕円曲線公開鍵Qであってもよく、第1の秘密鍵は、楕円曲線秘密鍵dであってもよく、共有秘密鍵は、dであってもよい。
【0055】
システムは、ハンドシェイクを完了し、少なくとも共有秘密鍵を用いて、暗号保護された通信セッションまたは暗号保護された通信セッションを確立718し得る。いくつかの実施形態では、暗号保護された通信セッションは、機密性の保証、例えばTLSセッションを提供する。他の実施形態では、セッションは、機密性の保証を提供しなくてもよいが、セッションでのメッセージの整合性及び真正性などの他の保証を提供してもよい。
【0056】
本明細書中で用いる用語「エンベロープ暗号化」とは、計算リソースが制限されている環境でデータの暗号化及び復号化の性能を向上させる技術を指す。計算リソースとして、CPUリソース、メモリ、リソース、帯域幅などが挙げられ得る。エンベロープ暗号化スキームでは、クライアント及び上述した暗号化()及び復号化()などの暗号化動作を行うのに用いられ得る暗号化サービスが存在し得る。さらに、暗号化サービスは、クライアントが暗号化動作を行うのに用い得るカスタマーマスター鍵を格納し得る。いくつかの実施形態では、あらゆる暗号化動作及び復号化動作を行うのに暗号化サービスを用いることには短所となり得る。例えば、ブロードバンドインターネット接続(例えば約100Mb/sのスループットを有する)を介して暗号化サービスに接続するクライアントの場合、大量のデータ(例えばテラバイトのデータ)の暗号化は、データを暗号化のために暗号化サービスにブロードバンド接続を介して転送することに関わるオーバーヘッドのため、望ましくない性能不良を有し得る。一例として、8TBのファイルを100Mbpsのブロードバンド接続を介して転送することは、完了に177時間(>1週間)以上かかるであろう。したがって、いくつかのシステムでは、データブロック全体を暗号化のためにネットワークを介して転送しないようにすることは利点であり得る。
【0057】
エンベロープ暗号化スキームは、暗号化動作の性能を向上させるために用いられ得る。大きなデータセットを暗号化するのに、暗号化サービスは、対称データ鍵を生成し、データ鍵をクライアントマスター鍵のもとで暗号化し得る。暗号化されたデータ鍵は、暗号化されたデータ鍵がどのように復号化され得るかを示す追加の情報(場合によっては平文で)を含み得る(例えばメタデータフィールドは、暗号化されたデータ鍵を復号化するのに使用可能な鍵IDを含み得る)。平文データ鍵及び暗号化されたデータ鍵は、クライアントに送信され得、クライアントは、データ鍵を用いてデータを暗号化し得る。暗号化されたデータ(データ鍵のもとで暗号化された)及び暗号化されたデータ鍵(クライアントマスター鍵のもとで暗号化された)は、一緒に格納され得、または、一緒に関連付けられ得る(例えば、データベースレコードで)。
【0058】
暗号化されたデータを復号化するのに、クライアント(場合によっては、データを暗号化したクライアントとは異なるクライアント)は、暗号化されたデータ鍵を取得し、暗号化サービスに暗号化されたデータ鍵を復号化することを要求し得る。暗号化サービスは、鍵IDが復号化要求の一部として提供されることを要し得る。要求者が十分なアクセス権を有し(例えば、データを暗号化したクライアントによるアクセス権付与を通じて)、暗号化されたデータ鍵を復号化するのに正しい暗号化鍵が用いられる場合、平文のデータ鍵は戻され、その後、暗号化されたデータを復号化するのに用いられ得る。
【0059】
図8は、本開示の様々な技術が利用され得る状況を例示する略図800を示す。この特定の例では、略図800は、第1のクライアント「クライアントA」802、第2のクライアント「クライアントB」804及び第3のクライアント「クライアントC」806を示す。略図800は、さらに、メッセージ808、拡張エンベローブ暗号化スキームのもとで保護されたメッセージ810(以下「保護されたメッセージ」)及び不正メッセージ814を例示する。クライアント802、804及び806は、本開示の別のところで記載されるものなどのクライアントであってもよい。いくつかの実施形態では、クライアントはコンピュータシステムであってもよいが、ルータまたはスイッチといったメッセージ802を修正可能な他の種類のコンピューティングエンティティであってもよい。
【0060】
いくつかの実施形態では、クライアントA802は、メッセージ808、より一般的にはデータを生成し、データを拡張エンベロープ暗号化スキームのもとで保護する。いくつかの実施形態では、拡張エンベロープ暗号化スキームのもとで保護されたメッセージ810は、エンベロープ暗号化を行うのに用いられるデータ鍵にアクセスできる他のクライアントによって読み出すことができるが、それらのクライアントによって修正されることはできない。いくつかの実施形態では、暗号化サービスを用いて、保護されたメッセージが不適切に修正されたかどうかを検証し得る。いくつかの実施形態では、クライアントAは、保護されたメッセージを修正し得、保護されたメッセージを修正する能力を他の機関、例えば、エンベロープ暗号化を行うのに用いられるデータ鍵にアクセスできるクライアントのサブセットに委譲し得る。したがって、いくつかの実施形態では、保護されたメッセージ810を読み出し修正することが可能な機関は、保護されたメッセージ810を読み出すことが可能な機関とは異なり得る-図8にしたがった一実施形態では、クライアントA802は、保護されたメッセージを読み出し修正することが可能であり、一方、クライアントA、B及びC802~806は、保護されたメッセージを読み出すことが可能である。
【0061】
いくつかの実施形態では、保護されたメッセージ810の送信者(例えばTCPパケットのソースアドレス)はクライアントA802であり、メッセ―ジの受信者(例えばTCPパケットの宛先アドレス)はクライアントB804である。いくつかの実施形態では、保護されたメッセージ810の送信者はクライアントA802であり、受信者はクライアントC806であり、クライアントBは、クライアントAとクライアントCの間の通信を容易にするもう1つのコンピュータシステムであってもよい。いくつかの実施形態では、保護されたメッセージ810の送信者はクライアントA802であり、受信者はクライアントB804であり、クライアントAとクライアントBの間にある取り決めが存在する(例えば、ネットワークプロトコル仕様に記載された取り決めなどの技術的取り決めまたは契約上の義務もしくはサービス品質保証(SLA)などの非技術的な取り決め)。
【0062】
いくつかの実施形態では、クライアントB804は、保護されたメッセージの不正修正816を行おうと試み得る。クライアントB804は、データ鍵を取得し、保護されたメッセージ810を復号化し、メッセージを修正(例えば、メッセージを「123・・・」から「789・・・」に変更すること)し、次いで、データ鍵を用いて、修正されたメッセージ812を暗号化し、不正メッセージ814をもたらし得る。クライアントB804は次いで、不正メッセージ814をクライアントC806に提供し得る。しかしながら、本明細書で開示された技術を用いて、クライアントC806は、暗号化サービスを用いて、それが受信したメッセージ(すなわち不正メッセージ814)は不適切に修正されたかどうかを検証し得る。
【0063】
図9は、本開示の様々な技術が利用され得る状況を例示する略図900を示す。この特定の例では、略図900は、保護されたメッセージがどのように生成され送信され得るかを示す。第1のクライアント902及び第2のクライアント904が示される。第1のクライアント902は、図8に関連して上述された第1のクライアント802と同一または同様のものであってもよい。第2のクライアント802は、図8に関連して上述された第2のクライアント804と同一または同様のものであってもよいが、いくつかの例では、図8に関連して上述された第3のクライアント806と同一または同様のものであってもよい。同様に、クライアントは、本開示の別のところに記載されたコンピュータシステムまたはコンピューティングエンティティであってもよい。
【0064】
暗号化サービス906は、本開示の別のところに記載された暗号化サービスであってもよい。いくつかの実施形態では、暗号化サービスは、少なくとも2つの動作-(1)データ鍵を生成すること及び(2)データの認証付き暗号化を行うことをサポートし得る。いくつかの実施形態では、クライアントは、暗号化サービス906に、エンベロープ暗号化に用いることができるデータ鍵を生成することを要求し得る(例えば、ウェブAPI要求を介して)。暗号化サービス906は、データ鍵を生成し、呼び出し元-クライアントに関連付けられたクライアントマスター鍵を用いてデータ鍵を暗号化し、データ鍵及び暗号化されたデータ鍵の両方を呼び出し元-クライアントに戻し得る(例えば、ウェブAPI応答を介して)。いくつかの実施形態では、呼び出し元-クライアントは、暗号化サービスを用いて、暗号化されたデータ鍵を復号化し得、呼び出し元-クライアントはまた、例えば呼び出し元-クライアントに関連付けられたカスタマーマスター鍵を用いてデータを復号化する能力を特定の他の機関(例えばクライアントB904)に付与するクライアントマスター鍵へのセキュリティポリシーを用いて、他の機関が、暗号化されたデータ鍵を復号化することも可能にし得る。例えば、図9~10による実施形態では、クライアントA902は、クライアントB904に、クライアントAに関連付けられたカスタマーマスター鍵のもとで暗号化されたデータ鍵を復号化する能力を付与している。いくつかの実施形態では、クライアントは、暗号化サービス906に、上述した暗号化()APIと同一または同様なものであるAPIを用いてデータを暗号化することを要求し得る(例えば、ウェブAPI要求を介して)。
【0065】
いくつかの実施形態では、第1のクライアント902は、メッセージ906、データ鍵908、任意選択的な追加認証データ(AAD)910ならびに秘密鍵d及び公開鍵Qを含むECDH鍵ペア912を生成、取得かつ/または格納し得る。メッセージ906は、平文のメッセージであってもよく、または、予め暗号化された暗号文のメッセージであってもよい。データ鍵908は、暗号化サービス906によって生成された暗号化鍵であってもよい。いくつかの実施形態では、第1のクライアント906は、暗号化サービスから、平文のデータ鍵908及び第1のクライアントに関連付けられたクライアントマスター鍵のもとで暗号化されたデータ鍵の両方を取得していてもよい。いくつかの実施形態では、第1のクライアントは、任意選択的なAAD910を有さなくてもよい(例えば、任意選択的なAADは用いられなくてもよく、存在しなくてもよく、またはNULL値で表されてもよい)。いくつかの実施形態では、クライアント902は、秘密鍵d及び公開鍵Qを含むECDH鍵ペア912を生成する。いくつかの実施形態では、秘密鍵dは他の機関に秘匿される。いくつかの実施形態では、他の種類の非対称鍵ペアが楕円曲線鍵ペアの代わりに用いられ得る。
【0066】
メッセージ906は、任意の形式のデータであってもよく、いくつかの実施形態では、クライアント902によって書かれてもよい(すなわちクライアント902によって生成されてもよい)が、別のソースから取得されたデータであってもよい。データ鍵908は、例えば、本開示で先に記載されたようにエンベロープ暗号化スキームで用いられ得る暗号化鍵であってもよい。データ鍵は、対称鍵であってもよくまたは非対称鍵であってもよい。追加認証データ910は、認証付き暗号化の一部として用いられ得る。いくつかの実施形態では、認証付き暗号化は、平文のデータ入力(例えば平文それ自体または平文の暗号文バージョン)及びAADに基づく認証タグ(例えばMACタグ)を生成する。AAD910は、対応する認証付き復号化の復号化成功のために提示を要され得る。いくつかの実施形態では、AAD910は、認証付き暗号化中に暗号化されず、難読化されていない形式(すなわち非暗号化)で送信され得る。
【0067】
保護されたメッセージ924は、図9に示すものなどのいくつかの構成要素を含み得る。いくつかの実施形態では、保護されたメッセージ924は、少なくとも暗号化されたメッセージ916を含むデジタル署名されたペイロード914を含む。暗号化されたメッセージ916は、データ鍵908のもとで暗号化され得る。デジタル署名されたペイロード914は、ECDHの秘密鍵dを用いて暗号化されたメッセージ916全体に生成されかつECDHの公開鍵Qを用いて検証可能なデジタル署名であってもよい。
【0068】
いくつかの実施形態では、保護されたメッセージは、さらに、ECDHの公開鍵Qを含む。しかしながら、他の実施形態では、ECDHの公開鍵は、保護されたメッセージの別の構成要素の一部として含まれ得る(例えば、AADが公開鍵Qを含み得る)。
【0069】
いくつかの実施形態では、保護されたメッセージは、さらに、(1)クライアントマスター鍵のもとで暗号化されたデータ鍵の暗号文922と(2)(直接的にまたは間接的に)データ鍵ならびに任意選択的なAAD910及びECDHの公開鍵Qを含む拡張AAD全体に生成される認証タグ(例えばMACタグ)とを含む認証されたペイロード920を含む。いくつかの実施形態では、認証されたペイロードは、RFC5084に記載されたものなどの認証付き暗号化動作を用いて生成され得、これは本明細書によって参照により組み込まれる。一例として、認証されたペイロード920は、以下の入力パラメータを用いてAES-CCM暗号化を行う暗号化サービス906によって生成され得る。
AES鍵:クライアントマスター鍵(図9に示さず)
ノンス:(任意の固有値)
平文:データ鍵908、及び
任意選択的な追加認証データ:AAD910及び公開鍵Q
AES-CCM暗号化は、(1)データ鍵の暗号文922及び(2)データ鍵ならびにAAD910及びECDHの公開鍵Qを含む拡張AAD全体へのMACタグ920を生成する。いくつかの実施形態では、拡張AADは、ECDHの公開鍵のみから構成され得る(例えばAAD910は空である)。AES-GCM暗号化は、上述と同一にまたは同様にして行われ得る。
【0070】
いくつかの実施形態では、認証されたペイロード920の構造は、図9に示す具体例と異なってもよい。一例として、認証されたペイロードは、データ鍵908及びECDHの公開鍵Qの両方を含む暗号文ならびに任意選択的なAAD(空であってもよい)を含み得る。この例では、認証タグは、クライアントAのカスタマーマスター鍵を用いて暗号文及びAAD全体に生成され得る。
【0071】
いくつかの実施形態では、認証されたペイロード920の構造は、図9に示す具体例と異なってもよい。一例として、認証されたペイロードは、データ鍵908を含む暗号文及び任意選択的なAAD(空であってもよい)を含み得る。この例では、認証タグは、クライアントAのカスタマーマスター鍵を用いて暗号文及びAAD全体に生成され得、第2の認証タグは、同一の鍵を用いてECDHの公開鍵Q全体に生成され得る。
【0072】
いくつかの実施形態では、第1のクライアント902は、保護されたメッセージを、第2のクライアント904などの他のコンピューティングエンティティにとって利用可能なものとし得る。システムは、直接的に(例えば、メッセージはハンドシェイクプロトコルまたは要求の一部として含まれる)または間接的に(例えば、保護されたメッセージを配置し取得するのに用いられ得るユニフォームリソース識別子(URI)が提供される)、保護されたメッセージを利用可能にし得る。いくつかの実施形態では、メッセージは、利用可能にされると、1つもしくは複数のコンピュータシステムまたはメッセージの内容を検査かつ/もしくは修正する能力を有してもよいルータもしくはスイッチなどのコンピューティングエンティティを通過し得ることに留意されたい。しかしながら、メッセージの内容の修正(例えば、デジタル署名を修正せずに暗号文のメッセージを修正すること及び/または認証タグを修正せずに暗号文のデータ鍵を修正すること)は検出可能であろう。
【0073】
図10は、本開示の様々な技術が利用され得る状況を例示する略図1000を示す。この特定の例では、略図1000は、保護されたメッセージがどのように受信され検証され得るかを示す。第1のクライアント1002及び第2のクライアント1004が示される。第1のクライアント1002は、保護されたメッセージ1018を第2のクライアント1004に送信することが示される。送信側クライアントと受信側クライアントと保護されたメッセージの様々な関係は本開示の範囲内で完結することに留意するべきである-送信側クライアントは、保護されたメッセージを生成していてもよく(例えば図8のクライアントA)、または、不正メッセージを生成しその不正メッセージを受信側クライアント(図8のクライアントB)に提供するエンティティであってもよい。いずれの場合も、保護されたメッセージを受信するクライアント(すなわちクライアントC1004)は、保護されたメッセージが不適切に修正されたかどうかを検証し得る。図10に関連して記載されたクライアントは、本開示の別のところに記載されたコンピュータシステムまたはコンピューティングエンティティであってもよい(例えばルータまたはスイッチ)。
【0074】
暗号化サービス1006は、本開示の別のところに記載された暗号化サービスであってもよい。いくつかの実施形態では、暗号化サービスは、少なくとも2つの動作-(1)クライアント鍵IDを取得すること及び(2)データを復号化することをサポートし得る。いくつかの実施形態では、クライアントは、暗号化サービス1006に、クライアント鍵IDを取得し鍵IDを呼び出し元-クライアントに戻すことを要求し得る(例えばウェブAPI要求を介して)。いくつかの実施形態では、呼び出し元-クライアントは、ユーザID、GUID、マシンID、メディアアクセス制御アドレス(MACアドレス)等といった識別情報を提供する。暗号化サービスは、例えば、識別情報とクライアント鍵IDの関連性を、1つまたは複数のデータベーステーブルのデータベースレコードに、配列として(例えば2次元配列)、ハッシュマップで(例えば、鍵が送信者情報であり値が鍵IDであるハッシュマップ)または他の適切なデータ構造で格納することによって、識別情報をクライアント鍵IDにマッピングし得る。クライアント鍵IDは、ユーザネーム、整数、文字数字の列、文字配列、GUIDまたは他のそうしたデータ型として表され得る。識別情報の鍵IDに対するマッピングは、単射(すなわち1対1)であってもよくかつ/または全単射(すなわち1対1かつ上への)であってもよい。いくつかの実施形態では、クライアントは、暗号化サービス906に、上記で説明した復号化()APIと同一または同様のAPIを用いてデータを暗号化することを要求し得る(例えば、ウェブAPI要求を介して)。
【0075】
いくつかの実施形態では、第1のクライアント1002は、保護されたメッセージ1018を第2のクライアント1004に送信する。保護されたメッセージ1018は、図9~10に関連して記載された保護されたメッセージと同一または同様なものであってもよい。いくつかの実施形態では、保護されたメッセージは、暗号文1010を含む暗号化されたペイロード1008及びECDHの公開鍵によって検証可能である暗号文1008全体へのデジタル署名を含む。いくつかの実施形態では、保護されたメッセージは、さらに、ECDHの公開鍵1012を含む。いくつかの実施形態では、保護されたメッセージは、さらに、暗号文1016と、暗号文1016ならびにAAD及びECDHの公開鍵を含む拡張AAD全体への認証タグとを含む認証されたペイロード1014を含む。クライアントCによって受信される保護されたメッセージ1018の内容は不適切に修正され得たことに留意するべきである。ここで記載された技術により、保護されたメッセージを受信するクライアントは、保護されたメッセージが不適切に修正されたかどうかを判定することが可能になる。
【0076】
いくつかの実施形態では、保護されたメッセージを受信するクライアント(図10のクライアントC1004)は、暗号化サービスを用いて、認証されたペイロード1014を復号化する。クライアントは、暗号化サービスに、ウェブAPI要求の一部として、暗号文、AAD1024及びECDHの公開鍵Q1026を両方含む拡張AADならびに暗号文及び拡張AAD全体に生成された認証タグを提供し得る。同様に、認証タグがAAD全体に生成される(公開鍵Qには生成されない)実施形態では、AADが拡張AADの代わりに提供され得る。いくつかの実施形態では、クライアントは、復号化のために、API要求の一部として鍵IDも暗号化サービスに提供し得る。クライアントは、様々な情報に基づいて鍵IDを判定し得る。例えば、保護されたメッセージ1018は、クライアントCと識別が既知である別のクライアントの間で通信セッションの一部として送信され得る。そうした例では、鍵IDは、クライアントCが通信セッションにそれとともに関与する機関に関連付けられ得る。第2の例として、保護されたメッセージにおける情報(例えば図10に示さないメタデータ)を用いて、鍵IDを判定し得る。第3の例として、メッセージは1つまたは複数のTCPパケットの一部として受信され得、鍵IDは送信者の識別(例えばTCPヘッダのソースアドレス)に基づいて判定され得る。
【0077】
いくつかの実施形態では、暗号化サービスは、認証されたメッセージに含まれる暗号文1016を復号化する。いくつかの実施形態では、暗号文は、復号化のために用いる鍵IDを含むメタデータ(例えば暗号文に追加されている)を含み得る。暗号化サービスは、暗号文を、鍵IDを用いて復号化し、復号化された平文を用いて、平文及び提供されたAADを用いた認証タグを生成し得る。生成されたタグと復号化要求で提供されたタグが一致しない場合、復号化は失敗し得る。復号化が成功した際、暗号化サービス1006は、クライアントに、復号化された平文及び、いくつかの実施形態では、復号化を行うのに用いられるクライアントマスター鍵の鍵IDを戻し得る。いくつかの実施形態では、平文は、暗号化されたメッセージ1010を復号化するのに使用可能なデータ鍵1022である。
【0078】
いくつかの実施形態では、クライアント1004は、復号化された平文1020及び鍵IDを、暗号化サービスから復号化要求への応答として受信し得る。クライアントは、さらに、受信した鍵IDを予測される鍵IDと比較し得る。予測される鍵IDは、予測される送信者に関連付けられた鍵IDであってもよい。クライアントは、プロトコルまたは他の情報に基づいて、予測される送信者を判定し得る。受信した鍵IDと予測される鍵IDが一致しない場合、エラーが発生し得、保護されたメッセージは無効として破棄され得る。しかしながら、受信した鍵IDと予測される鍵IDが一致する場合、クライアントはメモリ内に、復号化されたデータ鍵1022を格納かつ/またはキャッシュし得る。
【0079】
いくつかの実施形態では、クライアントは、デジタル署名されたペイロード1008を受信し得る。いくつかの実施形態では、ECDHの公開鍵Qを用いて、デジタル署名されたペイロード1008全体のデジタル署名を検証し得る。一実施形態では、公開鍵Qは、復号化動作の一部として認証される拡張AADの一部として含まれる。認証すると、公開鍵Qを用いてデジタル署名を検証し得る。デジタル署名が無効の場合、保護されたメッセージは無効として破棄され得る。しかしながら、デジタル署名が有効である場合、暗号化されたメッセージ1010は、認証されたペイロード1018の復号化から取得されるデータ鍵1022を用いて復号化され得る。復号化が完了すると、クライアント1004は、不適切に修正されていない平文のメッセージ1020を取得する。
【0080】
図11は、保護されたメッセージを生成する第1のクライアント1102を例示する略図1100を示す。まず、クライアントA1102は、秘密鍵d及び公開鍵Qを含むECDH鍵ペアを生成1108し得る。鍵は、本開示の別のところに記載された様々なやり方で生成され得る。さらに、楕円曲線鍵ペアの代わりに他の種類の非対称鍵ペアが用いられ得る。クライアントAはまた、データ鍵の生成を要求1100し得る。データ鍵は、エンベロープ暗号化を行うのに使用可能であり得る。要求は、本開示の別のところに記載された機能性をサポートする暗号化サービス1106へウェブAPI要求として行われ得る。暗号化サービス1106は、要求を受信し、データ鍵を生成1112し、要求に応えてクライアントにデータ鍵を提供し得る。いくつかの実施形態では、データ鍵は、ECDH鍵ペアよりも前に生成され得る。
【0081】
クライアントAは、データ鍵を暗号化サービスから(例えばウェブAPI要求に応えて)受信し、メッセージをデータ鍵で暗号化1114し得る。メッセージを暗号化した後、ECDHの秘密鍵dを用いて、メッセージの暗号文全体にデジタル署名を生成1116し得る。生成されたデジタル署名の有効性は、対応するECDHの公開鍵Qを用いて検証可能であってもよい。デジタル署名及び暗号文メッセージを含むデジタル署名されたペイロードは、保護されたメッセージの一部として含まれ得る。
【0082】
データ鍵の受信後、クライアントAは、要求を暗号化サービス1106に発行して、認証付き暗号化を行い得る。要求はウェブAPI要求であってもよく、クライアントAは、ウェブ要求の一部として、データ鍵、追加認証データ(AAD)及びECDHの公開鍵Qを提供し得る。いくつかの実施形態では、AADは任意選択的であり、省略されてもよい。暗号化サービスは、データ鍵を、クライアントAに関連付けられたクライアントマスター鍵を用いて暗号化1118し、データ鍵(平文を用いて直接的に、または、データ鍵の暗号文を用いて間接的に)、AAD(省略されない場合)及びECDHの公開鍵Q全体に認証タグを生成し得る。生成された暗号文及び認証タグを含む認証されたペイロードは、保護されたメッセージの一部として含まれ得る。
【0083】
いくつかの実施形態では、暗号化サービスは、データ鍵の生成後、データ鍵のコピーを格納、キャッシュまたはアーカイブし得る。そうした実施形態では、暗号化サービスは、クライアントAのカスタマーマスター鍵を用いて暗号化されたデータ鍵も格納、キャッシュまたはアーカイブし得る。暗号化されたデータ鍵は、データ鍵が生成された後で任意の時に生成され得る(例えば、データ鍵が生成された後かつ認証付き暗号化の要求1118の前)。クライアントAは、そうした実施形態では、データ鍵を暗号化要求で提供することを省略し得、暗号化サービスは、格納部、キャッシュまたはアーカイブからデータ鍵を暗号化し得る。
【0084】
クライアントAがデジタル署名されたペイロード及び認証されたペイロードの両方を取得した後で、クライアントAは、デジタル署名されたペイロード及び認証されたペイロードの両方をクライアントB1104に提供1120し得る。いくつかの実施形態では、クライアントAは、デジタル署名されたペイロード及び認証されたペイロードの両方を含む保護されたメッセージを生成し、保護されたメッセージを送信する。クライアントBは、デジタル署名されたペイロード及び認証されたペイロード、または、いくつかの実施形態では、少なくともデジタル署名されたペイロード及び認証されたペイロードから構成された保護されたメッセージを受信1122し得る。
【0085】
図12は、第1のクライアント1202が保護されていると称するメッセージを第2のクライアント1204に送信し、第2のクライアントはメッセージが不適切に修正されたかどうかを検証し得ることを例示する略図1200を示す。いくつかの実施形態では、クライアントC1204は、不適切に修正されていない保護されたメッセージであると称するメッセージを受信する。いくつかの実施形態では、メッセージは、メッセージの最初の書き手(例えばメッセージを生成した機関)によって提供1208され得、場合によっては、それは無関係な第三者機関(例えば、ネットワーク内のコンピュータシステムまたはルータもしくはスイッチ)であってもよい。クライアントCは、保護されていると称するメッセージを取得1210し、メッセージからデジタル署名されたペイロード及び認証されたペイロードを取得し得る。保護されていると称するメッセージは、保護されたメッセージと同一の形式のものであってもよい(例えば、図11に関連して記載されるような)-しかしながら、いくつかの実施形態では、クライアントCは、デジタル署名及び/または認証タグが有効であることを検証していなくてもよい。
【0086】
いくつかの実施形態では、保護されていると称するメッセージは、暗号文、AAD及びECDHの公開鍵Qを含む認証されたペイロードを含む。クライアントCは、暗号化サービス1206に、復号化動作を行う要求(例えばウェブAPI要求)を行い得る。クライアントCは、要求の一部として、認証されたペイロードの暗号文、AAD及び認証タグを提供1212し得る。暗号化サービスは、暗号文の復号化に用いるための暗号化鍵を選択1214し得る。鍵は、例えば、暗号文を復号化するのに用いられ得るクライアントマスター鍵に対応する鍵IDを含む、暗号文とともに含まれるメタデータに基づいて選択され得る。暗号化鍵と鍵IDは、1つまたは複数のデータベーステーブルのデータベースレコードを用いて、配列として(例えば2次元配列)、ハッシュマップで(例えば、鍵が送信者情報であり値が鍵IDであるハッシュマップ)または他の適切なデータ構造で関連付けられ得る。
【0087】
いくつかの実施形態では、暗号化サービスは、暗号文を復号化1216する。いくつかの実施形態では、暗号文は、復号化のために用いる鍵IDを含むメタデータ(例えば暗号文に追加されている)を含み得る。暗号化サービスは、暗号文を、鍵IDを用いて復号化し、復号化された平文を用いて、平文及び提供されたAADを用いた認証タグを生成し得る。生成されたタグと復号化要求で提供されたタグが一致しない場合、復号化は失敗し得る。復号化が成功した場合、暗号化サービスはクライアントに、復号化された平文及び、いくつかの実施形態では、復号化を行うのに用いられるクライアントマスター鍵の鍵IDを戻し得る。いくつかの実施形態では、平文は、暗号化されたメッセージを復号化するのに使用可能なデータ鍵である。いくつかの実施形態では、AADは、公開鍵Qを含んで拡張され得る(例えば、鍵をAADに追加することによって)。
【0088】
いくつかの実施形態では、クライアントC1204は、復号化された平文及び鍵IDを暗号化サービスから復号化要求への応答として受信し得る。クライアントは、さらに、受信した鍵IDを予測される鍵IDに対して検証1218し得る。予測される鍵IDは、予測される送信者に関連付けられた鍵IDであってもよい。クライアントは、プロトコルまたは他の情報に基づいて、予測される送信者を判定し得る。受信した鍵IDと予測される鍵IDが一致しない場合、エラーが発生し得、保護されていると称するメッセージは、無効として破棄され得る。しかしながら、受信した鍵IDと予測される鍵IDが一致する場合、クライアントはメモリ内に、復号化されたデータ鍵を格納かつ/またはキャッシュし得る。
【0089】
いくつかの実施形態では、クライアントCは、デジタル署名されたペイロードを(例えば、保護されていると称するメッセージの一部として)受信し得る。いくつかの実施形態では、ECDHの公開鍵Qを用いて、デジタル署名されたペイロード1008全体のデジタル署名を検証し得る。一実施形態では、公開鍵Qは、復号化動作の一部として認証される拡張AADの一部として含まれる。認証すると、公開鍵Qを用いて、デジタル署名を検証1220し得る。デジタル署名が無効の場合、保護されていると称するメッセージは無効として破棄され得る。しかしながら、デジタル署名が有効である場合、デジタル署名されたペイロードに含まれる暗号化されたメッセージは、認証されたペイロードの復号化から取得されたデータ鍵を用いて復号化1222され得る。復号化が完了すると、クライアントCは、不適切に修正されていない平文のメッセージを取得する。
【0090】
図13は、一実施形態による拡張エンベロープ暗号化スキームのもとで保護されたメッセージを生成するプロセス1300の具体例を示す。プロセス1300は、図8~12に上述したクライアントにしたがって記載されたコンピュータシステムなどの任意の適切なシステムによって行われ得る。一実施形態では、プロセス1300を行うシステムは、秘密鍵及び公開鍵を含む非対称鍵ペアを生成1302し得る。いくつかの実施形態では、非対称鍵ペアは楕円曲線鍵ペアであってもよい。システムは、暗号化サービスから、エンベロープ暗号化に用いることができる暗号化データ鍵も取得1304し得る。データ鍵は、対称鍵であってもよい。いくつかの実施形態では、データ鍵は、非対称鍵ペアが生成されるより前に取得され得る。
【0091】
いくつかの実施形態では、データ鍵を用いてメッセージを暗号化1306し得る。メッセージを暗号化した後で、デジタル署名は、秘密鍵を用いて、少なくとも暗号化されたメッセージ全体に生成1308され得る。いくつかの実施形態では、公開鍵を用いて、デジタル署名が真正なものであることを検証し得る。暗号化及びデジタル署名の生成は、例えば、図9~10に関連して上述した実施形態にしたがって行われ得る。いくつかの実施形態では、デジタル署名されたペイロードは、秘密鍵の暗号文(いくつかの実施形態では、暗号化を行うのに用いられるクライアントマスター鍵に関連付けられたメタデータを含む)、及び非対称秘密鍵によって生成されたデジタル署名を含み得る。
【0092】
いくつかの実施形態では、追加認証データ(AAD)が取得され得、AADは非対称公開鍵で拡張1310され得る。AADは、例えば、非対称公開鍵をAADにプリペンドまたは追加することによって、拡張され得る。いくつかの実施形態では、AADはデータ構造であってもよく、非対称公開鍵はデータ構造内のデータ要素に挿入またはコピーされてもよい。いくつかの実施形態では、AADは任意選択であってもよく、かつ/または、空であってもよい。
【0093】
いくつかの実施形態では、データ鍵及び拡張されたAADは、認証付き暗号化を行う要求の一部として暗号化サービスに提供1312され得る。いくつかの実施形態では、AADは任意選択的であってもよく、その場合には、データ鍵及び非対称公開鍵(またはデータ鍵だけ)が、認証付き暗号化を行う要求の一部として暗号化サービスに提供され得る。認証付き暗号化は、図9~10に関連して上述した実施形態にしたがって暗号化サービスによって行われ得る。
【0094】
いくつかの実施形態では(すなわち、暗号化サービスがデータ鍵の認証付き暗号化に成功した場合)、図13のシステムは、暗号化サービスから、データ鍵の暗号文及び拡張AADを用いて検証することができる認証タグを受信1314し得る。いくつかの実施形態では、AADは任意選択的であってもよく、その場合には、非対称公開鍵を用いて、認証タグを検証し得る。いくつかの実施形態では、図13のシステムは、暗号文メッセージ、デジタル署名、暗号文データ鍵、拡張AAD及び認証タグを含む保護されたメッセージを、例えば別のコンピュータシステムに送信または提供1316し得る。システムは、例えば、デジタル署名されたペイロード及び認証されたペイロードを含む保護されたメッセージを1つまたは複数のTCPパケットで別のクライアントに送信することによって、保護されたメッセージを利用可能にし得る。
【0095】
図13に記載されたプロセス1300の変形例も可能である。いくつかの実施形態では、システムは、AADを公開鍵で拡張し、拡張AADを暗号化サービスに提供し、暗号化サービスから暗号文データ鍵及び拡張AADを用いて検証することができる認証タグを受信し得る。そうした実施形態では、暗号文データ鍵を受信する前に、またはそれと同時に、またはそれより後に、平文データ鍵も暗号化サービスから受信され得る。いくつかの実施形態では、システムは、暗号文データ鍵を受信し、暗号文データ鍵、認証タグ、AAD及び非対称公開鍵を含む認証されたペイロードを生成し得る。いくつかの実施形態では、認証されたペイロードを生成した後で、システムは、暗号化データ鍵を取得し、データ鍵を用いて第1のメッセージの暗号文を生成し、非対称秘密鍵を用いて第1のメッセージの暗号文にデジタル署名し得る。システムは、認証されたペイロード及び第1のメッセージの暗号文に基づく第1のデジタルペイロードを含む第1の保護されたメッセージを、上述された実施形態にしたがって利用可能にし得る。システムは、第2のメッセージの暗号文もデータ鍵を用いて生成し、第2のメッセージの暗号文に非対称鍵を用いてデジタル署名し得る。次いで、システムは、第1のメッセージと同一の認証されたペイロード及び第2のメッセージの暗号文に基づく第2のデジタルペイロードを含む第2の保護されたメッセージを、上述した実施形態にしたがって利用可能にし得る。結果的に、様々な実施形態において、システムは、同一の認証されたペイロードを用いて複数の保護されたメッセージを生成し得る。
【0096】
図14は、一実施形態において、保護されたメッセージが不適切に修正されていないことを検証するプロセス1400の具体例を示す。プロセス1400は、図8~12に上述したクライアントにしたがって記載されたコンピュータシステムなどの任意の適切なシステムによって行われ得る。一実施形態では、プロセス1400を行うシステムは、第1の暗号文、第1の暗号文全体へのデジタル署名、第2の暗号文、拡張AADならびに第2の暗号文及び拡張AAD全体への認証タグを含む保護されたメッセージを含む保護されたメッセージを受信1402し得る。保護されたメッセージは、別のコンピュータシステムによってまたは保護されたメッセージの送信に関わるルータもしくはスイッチなどの別のコンピューティングエンティティによって不適切に修正されている場合がある。
【0097】
いくつかの実施形態では、システムは、暗号化サービスに、第2の暗号文、拡張AAD及び認証タグを、第2の暗号文を復号化する要求(例えばウェブAPI要求)の一部として提供1404し得る。復号化は、例えば図9~10に関連して上述した実施形態にしたがって暗号化サービスによって行われ得る。
【0098】
要求に対する応答の一部として、システムは、暗号化サービスから、第2の暗号文、拡張AAD及び認証タグに少なくとも基づいて信頼性の表示を受信1406し得る。暗号文、AAD及び/または認証タグが送信中に修正された場合のいくつかの実施形態では、失敗または無効性の表示が代わりに受信され得る。システムは、要求に対する応答の一部として、第2の暗号文の平文及び鍵IDも受信1408し得る。平文は暗号化データ鍵を含み得る。鍵IDは、暗号化サービスによって第2の暗号文を復号化するのに用いられるクライアントマスター鍵に対応し得る。いくつかの実施形態では、信頼性の表示は、平文及び鍵IDが受信された後にまたはそれと同時に受信され得る。平文は、まだ難読化形式(例えば暗号化の複数の層がデータ鍵に適用される場合)であり得ることに留意されたい。
【0099】
いくつかの実施形態では、システムは、受信した鍵IDが予測される鍵識別子に一致することを検証1410し得る。予測される鍵IDは、予測される送信者に関連付けられた鍵IDであってもよい。クライアントは、プロトコルまたは他の情報に基づいて、予測される送信者を判定し得る。受信した鍵IDと予測される鍵IDが一致しない場合、エラーが発生し得、保護されたメッセージは無効として破棄され得る。システムは、この検証を、例えば、図9~10に関連して上述した実施形態にしたがって行い得る。いくつかの実施形態では、システムは、データ鍵を用いて第1の平文を復号化し、不適切に修正されていない平文のメッセージを取得し得る。
【0100】
いくつかの実施形態では、非対称公開鍵を用いて、第1の暗号文全体のデジタル署名を検証1412し得る。いくつかの実施形態では、デジタル署名は、信頼性の表示が受信1406される前にかつ/または復号されたデータ鍵を受信する前に、検証され得る。第2の暗号文が復号化されてデータ鍵が取得された後で、システムは、第1の暗号文をデータ鍵を用いて復号化し、平文のメッセージを取得し得る。いくつかの実施形態では、暗号文は、信頼性の表示が受信1406される前にかつ/またはデジタル署名を検証1412する前に、復号化され得る。そうした実施形態では、取得された平文のメッセージは、検証ステップ完了に成功するまで使用するのに危険であるとしてマークされ得る。
【0101】
本明細書中で用いる用語「秘密鍵」及び「公開鍵」とは、それぞれ、非対称暗号化(「公開鍵暗号化」)の一部として用いられる秘密鍵及び公開鍵を指すのに用いられ得る。非対称暗号化とは、秘密鍵と公開鍵が数学的にリンクされ得る暗号化プロトコルのクラスを指す。公開鍵暗号化では、機関が共有秘密鍵を共有する必要はない。むしろ、公開鍵は公開されてもよく、一般に利用可能であってもよく(信頼できない機関にも)、一方、秘密鍵は、信頼できない機関に暴露されるべきではない。(対応する秘密鍵と公開鍵の)鍵ペアは、暗号化動作を行うのに用いられ得る。例えば、公開鍵を用いて、平文メッセージを暗号化して暗号文をもたらし得、対応する秘密鍵を用いて、暗号文を復号化して元の平文メッセージをもたらし得る。第2の例として、秘密鍵を用いて、メッセージを認証するデジタル署名を生成し得、対応する公開鍵を用いて、デジタル署名が正しくしたがってメッセージは真正なものであることを検証し得る。
【0102】
図15は、様々な実施形態による態様を実装するための例示的な環境1500の態様を示す。理解されるように、ウェブベースの環境が説明の目的のために使用されるが、多様な実施形態を実装するために様々な環境が必要に応じて使用され得る。環境は、電子クライアントデバイス1502を含み、該電子クライアントデバイスは、要求、メッセージまたは情報を適切なネットワーク1504を介して送信及び/または受信し、いくつかの実施形態では、デバイスのユーザに情報を伝達して戻すのに動作可能である任意の適切なデバイスを含み得る。係るクライアントデバイスの例には、パーソナルコンピュータ、携帯電話、ハンドヘルドメッセージングデバイス、ラップトップコンピュータ、タブレットコンピュータ、セットトップボックス、パーソナルデータアシスタント、組込み型コンピュータシステム、電子ブックリーダー等が挙げられる。ネットワークは、イントラネット、インターネット、セルラーネットワーク、ローカルエリアネットワーク、衛星ネットワークもしくは任意の他の係るネットワーク及び/またはその組合せを含む任意の適切なネットワークを含み得る。係るシステムのために使用される構成要素は、選択されるネットワーク及び/または環境の種類に少なくとも部分的に依存することがある。係るネットワークを介して通信するための多くのプロトコル及び構成要素は周知であり、本明細書において詳細に説明されない。ネットワークを介する通信は、有線接続または無線接続及びそれらの組合せによって可能にされることがある。この例では、環境は要求を受信し、要求に応えてコンテンツを提供するためのウェブサーバ1506を含むので、ネットワークはインターネット及び/または他のパブリックにアドレス指定可能な通信ネットワークを含むが、他のネットワークの場合、当業者に明白であるように、同様の目的を果たす代替のデバイスが使用できるだろう。
【0103】
例示的な環境には、少なくとも1つのアプリケーションサーバ1508及びデータストア1510が含まれる。適切なデータストアからデータを取得する等のタスクを実行するように、連結またはそれ以外の方法で構成され得、そのように相互作用することができる、複数のアプリケーションサーバ、層もしくは他の要素、プロセス、または構成要素が存在し得ることが理解されるべきである。本明細書中で用いるようなサーバは、ハードウェアデバイスまたは仮想コンピュータシステムなどの様々に実装され得る。状況によっては、サーバとは、コンピュータシステム上で実行されているプログラミングモジュールを指し得る。本明細書で使用される「データストア」という用語は、それ以外に記述されまたは文脈から明らかでない限り、データを記憶し、データにアクセスし、かつデータを取得することができる任意のデバイスまたはデバイスの組み合わせを指し、任意の標準、分散型、仮想またはクラスタ化環境において、任意の組み合わせ及び任意の数のデータサーバ、データベース、データ記憶デバイス及びデータ記憶媒体を含み得る。アプリケーションサーバは、必要に応じてデータストアと統合してクライアントデバイスのための1つまたは複数のアプリケーションの態様を実行し、データアクセス及びアプリケーションのためのビジネスロジックの一部または全部を処理するための任意の適切なハードウェア、ソフトウェア及びファームウェアを含むことがある。アプリケーションサーバは、データストアと協働してアクセス制御サービスを提供し得、以下に限定するものではないが、テキスト、グラフィックス、音声、ビデオ及び/またはユーザに提供されるのに使用可能である他のコンテンツを含むコンテンツを生成することができ、該コンテンツは、ハイパーテキストマークアップ言語(「HTML」)、拡張マークアップ言語(「XML」)、JavaScript(登録商標)、カスケーティングスタイルシート(「CSS」)、JavaScript Object Notation(JSON)及び/または別の適切なクライアント側構造化言語の形でウェブサーバによってユーザに提供されてよい。クライアントデバイスに転送されるコンテンツは、クライアントデバイスによって処理されて、以下に限定されるものではないが、ユーザに聴覚的に、視覚的にかつ/または他の感覚を通して知覚される形式を含む1つまたは複数の形式でコンテンツを提供し得る。全ての要求および応答の処理、ならびにクライアントデバイス1502とアプリケーションサーバ1508の間のコンテンツの送達は、ウェブサーバによって、PHP:ハイパーテキストプリプロセッサ(「PHP」)、Python、Ruby、Perl、Java(登録商標)、HTML、XML、JSON及び/またはこの例では別の適切なサーバ側構造化言語を用いて処理することができる。さらに、単一のデバイスで行われているとして本明細書中に記載された動作は、文脈からそれ以外に明確ではない限り、分散型かつ/または仮想システムを形成し得る複数のデバイスによって集団で行われ得る。
【0104】
データストア1510は、複数の別々のデータテーブル、データベース、データドキュメント、動的データストレージスキーム及び/または他のデータストレージ機構、及び本開示の特定の態様に関するデータを記憶するための媒体を含み得る。例えば、例示されるデータストアとしては、生産側にコンテンツを提供するために使用することができる生産データ1512及びユーザ情報1516を記憶するための機構が含まれ得る。また、データストアは、報告、分析または他の係る目的のために使用することができるログデータ1514を記憶するための機構を含むと示される。ページの画像情報及びアクセス権情報等、データストアに記憶する必要があり得る多数の他の態様が存在し得、これは、必要に応じて上に列挙された機構のいずれか、またはデータストア1510内の追加の機構に記憶することができることを理解されるべきである。データストア1510は、データストアと関連付けられたロジックを通して、アプリケーションサーバ1508から命令を受信し、命令に応えてデータを入手、更新またはそれ以外の場合処理するよう作動可能である。アプリケーションサーバ1508は、受信した命令に応えて、静的データ、動的データ、または静的データ及び動的データの組み合わせを提供し得る。ウェブログ(ブログ)で用いられるデータなどの動的データ、ショッピングアプリケーション、ニュースサービス及び他のそうしたアプリケーションは、本明細書中で記載されたようなサーバ側構造化言語によって生成され得、または、アプリケーションサーバ上でまたはその制御下で動作するコンテンツ管理システム(「CMS」)によって提供され得る。一例では、ユーザは、ユーザが動作させるデバイスを通して、特定のタイプの項目に対する検索要求を送信する可能性がある。この場合、データストアは、ユーザ情報にアクセスしてユーザの識別を検証する可能性があり、そのタイプの項目についての情報を入手するためにカタログ詳細情報にアクセスすることができる。情報は、次いでユーザがユーザーデバイス1502でブラウザを介して見ることができるウェブページ上の結果リストで等、ユーザに戻すことができる。関心のある特定の項目の情報は、ブラウザの専用ページまたはウィンドウ内で見ることができる。しかしながら、本開示の実施形態は必ずしもウェブページの文脈に限定されるものではなく、より一般に要求が必ずしもコンテンツのための要求ではない一般的な処理要求に適用可能であってもよいことに留意されるべきである。
【0105】
各サーバは、通常、そのサーバの一般的な管理及び操作のための実行可能なプログラム命令を提供するオペレーティングシステムを含み、通常、サーバのプロセッサによって実行されると(すなわち実行された結果として)、サーバがその意図される機能を実行できるようにする命令を記憶するコンピュータ可読記憶媒体(例えば、ハードディスク、ランダムアクセスメモリ、読出し専用メモリ等)を含む。
【0106】
一実施形態における環境は、1つまたは複数のコンピュータネットワークもしくは直接接続を使用し、通信リンクを介して相互接続されるいくつかのコンピュータシステム及び構成要素を利用する、分散型かつ/または仮想コンピューティング環境である。しかしながら、係るシステムは、図15に示されるよりも少ない数または多い数の構成要素を有するシステムにおいて同等に良好に動作し得ることが当業者によって理解される。したがって、図15のシステム1500の描写は、本質的に例示であり、本開示の範囲を限定するものではないと見なされるべきである。
【0107】
さらに、本開示の実施形態は、以下の条項を鑑みて説明できる。
1.コンピュータによって実装される方法であって、
実行可能命令で構成される1つまたは複数のコンピュータシステムの制御下で、
暗号保護された通信セッションを確立するハンドシェイクプロトコルの一部として、送信者識別情報及び第1の非対称公開鍵を備える第1のメッセージを取得することであって、前記第1の非対称公開鍵及び対応する第1の非対称秘密鍵は、前記暗号保護された通信セッションを介して通信するクライアントによってサポートされる、前記取得することと、
暗号化サービスに、前記第1のメッセージ、鍵識別子及び前記第1のメッセージに対応する第1の認証されたメッセージを生成する命令を提供することであって、前記第1の認証されたメッセージは、検証するために前記第1の認証されたメッセージを前記暗号化サービスに提供する前記クライアントによって検証することができる、前記提供することと、
前記暗号化サービスから、前記第1のメッセージに対応する前記第1の認証されたメッセージを受信することと、
前記ハンドシェイクプロトコルの一部として前記クライアントに前記第1の認証されたメッセージを提供することと、
前記クライアントから第2の認証されたメッセージを受信することであって、前記認証されたメッセージは少なくとも第2の送信者識別情報及び第2の非対称公開鍵を備える、前記受信することと、
前記暗号化サービスを用いて、前記第2の認証されたメッセージの信頼性を検証することと、
前記暗号化サービスから、前記第2の認証されたメッセージが真正なものであるという表示を受信することと、
前記ハンドシェイクプロトコルの一部として、共有秘密鍵を、少なくとも前記第2の非対称公開鍵及び前記第1の非対称秘密鍵を用いて生成することと、
少なくとも部分的に前記共有秘密鍵を用いて、前記クライアントとの間に前記暗号保護された通信セッションを確立することであって、前記共有秘密鍵も前記クライアントによって判定可能である、前記確立することとを備える、前記方法。
【0108】
2.前記第1の非対称公開鍵が楕円曲線公開鍵Qであり、前記対応する秘密鍵が対応する楕円曲線秘密鍵dであり、前記第2の非対称公開鍵が楕円曲線公開鍵Qであり、かつ、前記共有秘密鍵が、dとQの楕円曲線点乗算の計算に部分的に基づいて生成される、条項1に記載のコンピュータによって実装される方法。
【0109】
3.前記第1のメッセージに対応する前記第1の認証されたメッセージを生成する前記命令が、前記暗号化サービスへの、前記第1のメッセージに少なくとも部分的に基づくメッセージ認証コード(MAC)タグを生成する要求を備え、
前記第1の認証されたメッセージが、前記第1のメッセージ及び前記第1のメッセージに少なくとも部分的に基づく前記MACタグを備える、条項1または2に記載のコンピュータによって実装される方法。
【0110】
4.前記暗号保護された通信セッションがトランスポート層セキュリティ(TLS)セッションである、条項1~3のいずれかに記載のコンピュータによって実装される方法。
【0111】
5.1つまたは複数のプロセッサと、
前記1つまたは複数のプロセッサによって実行された結果として、前記システムが、
暗号化サービスから、公開鍵と送信者識別の結びつきが真正なものであるという表示を取得し、
ハンドシェイクプロトコルの一部として、前記送信者識別に結びつけられた前記公開鍵及び前記結びつきが真正なものであるという前記表示をクライアントに提供し、
前記クライアントから、第2の公開鍵を受信し、
少なくとも秘密鍵及び前記第2の公開鍵を用いて共有秘密鍵を生成し、
前記共有秘密鍵を用いて、前記クライアントとの間に暗号保護された通信セッションを確立する実行可能命令を格納するメモリとを備える、システム。
【0112】
6.前記第2の公開鍵が、第2の結びつきを通して、第2の送信者識別及び前記暗号化サービスによって暗号学的に検証可能である第2の表示に結びつけられ、
前記命令によって、さらに、前記システムが、
前記暗号化サービスを用いて、前記第2の結びつきが真正なものであることを検証し、
前記第2の結びつきが真正なものであることの検証の成功に応えて、前記共有秘密鍵を生成する、条項5に記載のシステム。
【0113】
7.前記非対称鍵ペアが、楕円曲線公開鍵Q及び対応する楕円曲線秘密鍵dを備える楕円曲線鍵ペアであり、前記第2の公開鍵が楕円曲線公開鍵Qであり、かつ、前記共有秘密鍵が、dとQの楕円曲線点乗算の計算に部分的に基づいて生成される、条項5または6に記載のシステム。
【0114】
8.前記システムが、前記公開鍵及び前記送信者識別を含むメッセージを少なくとも生成することによって、前記公開鍵を前記送信者識別に結びつけ、
前記システムが、鍵識別子を取得し前記暗号化サービスに前記鍵識別子に関連付けられた暗号化鍵を用いて前記メッセージ全体にメッセージ認証コード(MAC)タグを生成することを要求することによって、前記結びつきが真正なものであるという前記表示を取得し、
前記第2の表示が第2のMACタグを含み、
前記第2の結びつきが真正なものであることを前記検証することが、前記暗号化サービスに前記第2のMACタグ及び前記第2の結びつきを提供することを備える、条項6に記載のシステム。
【0115】
9.前記システムが前記公開鍵を前記送信者識別に結びつけることが、前記公開鍵及び前記送信者識別を含むメッセージを生成することを含み、
前記システムが、前記結びつきが真正なものであるという前記表示を、鍵識別子を取得し前記暗号化サービスに前記鍵識別子に関連付けられた暗号化鍵を用いて前記メッセージを暗号化することを要求することによって取得し、
前記第2の表示が暗号文を含み、
前記システムが、さらに、前記第2の結びつきが真正なものであることを検証するために、
前記暗号化サービスに、復号化する前記暗号文を提供し、
前記暗号化サービスから、暗号文に対応する平文及び第2の鍵識別子を受信し、
前記第2の鍵識別子が前記クライアントに関連付けられていることを判定する命令を含む、条項6に記載のシステム。
【0116】
10.前記メッセージがさらにノンスを含み、
前記システムが、さらに、前記第2の結びつきが真正なものであることを検証するために、前記暗号文に対応する前記平文が前記ノンスを含むことを判定する命令を含む、条項9に記載のシステム。
【0117】
11.前記命令によって、さらに、前記システムが、前記暗号保護された通信セッションを確立した後で、データを取得し、前記秘密鍵を用いて前記データ全体にデジタル署名を生成し、前記クライアントに前記暗号保護された通信セッションを介して前記データ及び前記デジタル署名を送信する、条項5~10のいずれかに記載のシステム。
【0118】
12.前記暗号保護された通信セッションがトランスポート層セキュリティ(TLS)セッションである、条項5~11のいずれかに記載のシステム。
【0119】
13.コンピュータシステムの1つまたは複数のプロセッサによって実行された結果として、前記コンピュータシステムが、少なくとも、
秘密鍵及び公開鍵を備える非対称鍵ペアを取得し、
ハンドシェイクの一部として、クライアントに前記公開鍵を提供し、
前記クライアントから、第2の結びつきを介して第2の送信者識別及び第2の表示に結びつけられた第2の公開鍵を受信し、前記第2の表示は暗号化サービスによって暗号学的に検証可能なものであり、
前記暗号化サービスを用いて、前記第2の結びつきが真正なものであることを検証し、
前記第2の結びつきが真正なものであると判定したことに応えて、少なくとも前記秘密鍵及び前記第2の公開鍵を用いて共有秘密鍵を生成し、
前記クライアントとの間に暗号保護された通信セッションを確立する実行可能命令が格納された非一時的なコンピュータ可読記憶媒体。
【0120】
14.前記実行可能命令によって、さらに、前記コンピュータシステムが、
前記暗号化サービスから、前記公開鍵と送信者識別の結びつきが真正なものであるという表示を取得し、
ハンドシェイクプロトコルの一部として、前記結びつきが真正なものであるという前記表示をクライアントに提供し、
前記クライアントに提供された前記公開鍵は前記送信者識別に結びつけられている、条項13に記載の非一時的なコンピュータ可読記憶媒体。
【0121】
15.前記非対称鍵ペアが、楕円曲線公開鍵Q及び対応する楕円曲線秘密鍵dを備える楕円曲線鍵ペアであり、前記第2の非対称公開鍵が楕円曲線公開鍵Qである、条項13または14に記載の非一時的なコンピュータ可読記憶媒体。
【0122】
16.前記システムが前記公開鍵を前記送信者識別に結びつけることが、前記公開鍵及び前記送信者識別を含むメッセージを生成することを含み、
前記システムが、鍵識別子を取得し前記暗号化サービスに前記鍵識別子に関連付けられた暗号化鍵を用いて前記メッセージ全体にメッセージ認証コード(MAC)タグを生成することを要求する命令を介して、前記結びつきが真正なものであるという前記表示を取得し、
前記第2の表示が第2のMACタグを含み、
前記システムが、前記暗号化サービスに前記第2のMACタグ及び前記第2の結びつきを提供する命令を介して、前記第2の結びつきが真正なものであることを検証する、条項14に記載の非一時的なコンピュータ可読記憶媒体。
【0123】
17.前記公開鍵を前記送信者識別に結びけることが、前記公開鍵及び前記送信者識別を含むメッセージを生成することを含み、
前記結びつきが真正なものであるという前記表示を取得することが、鍵識別子を取得し前記暗号化サービスに前記鍵識別子に関連付けられた暗号化鍵を用いて前記メッセージを暗号化することを要求することを備え、
前記第2の表示が暗号文を含み、
前記第2の結びつきが真正なものであることを前記検証することが、
前記暗号化サービスに、復号化する前記暗号文を提供することと、
前記暗号化サービスから、暗号文に対応する平文及び第2の鍵識別子を受信することと、
前記第2の鍵識別子が前記クライアントに関連付けられていることを判定することとを備える、条項14に記載の非一時的なコンピュータ可読記憶媒体。
【0124】
18.前記メッセージがさらにタイムスタンプを含み、
前記第2の結びつきが真正なものであることを前記検証することが、さらに、前記暗号文に対応する前記平文が前記タイムスタンプを含むことを判定することを含む、条項17に記載の非一時的なコンピュータ可読記憶媒体。
【0125】
19.前記暗号化要求が認証付き暗号化要求である、条項14に記載の非一時的なコンピュータ可読記憶媒体。
【0126】
20.前記暗号保護された通信セッションがトランスポート層セキュリティ(TLS)セッションである、条項13~19のいずれかに記載の非一時的なコンピュータ可読記憶媒体。
【0127】
21.第1のコンピュータシステムであって、
第1の1つまたは複数のプロセッサ、及び
前記第1の1つまたは複数のプロセッサによって実行された結果として、前記第1のコンピュータシステムが、
暗号化データ鍵を取得し、前記データ鍵を用いて少なくともメッセージを暗号化することによって、前記メッセージに少なくとも部分的に基づく第1の暗号文を生成し、
前記第1の暗号文ならびに少なくとも前記第1の暗号文及び秘密鍵を用いて生成されたデジタル署名を含むデジタル署名されたペイロードを生成し、
前記データ鍵に少なくとも部分的に基づく第2の暗号文、前記秘密鍵に対応する公開鍵、ならびに少なくとも前記データ鍵及び前記公開鍵を含むデータを用いて検証可能な認証タグを含む認証されたペイロードを取得する実行可能命令を格納する第1のメモリを備える、前記第1のコンピュータシステムと、
第2のコンピュータシステムであって、
第2の1つまたは複数のプロセッサ、及び
前記第2の1つまたは複数のプロセッサによって実行された結果として、前記第2のコンピュータシステムが、
前記デジタル署名されたペイロード及び前記認証されたペイロードを受信し、
少なくとも前記第2の暗号文、前記公開鍵及び前記認証タグに少なくとも基づいて前記データ鍵及び鍵識別子を取得し、
前記鍵識別子が前記第1のコンピュータシステムに関連付けられた予測される鍵識別子に一致すること及び前記デジタル署名が有効であることを検証し、
前記データ鍵を用いて前記第1の暗号文を復号化することによって、前記メッセージを取得する実行可能命令を格納する第2のメモリを備える、前記第2のコンピュータシステムとを備えるシステム。
【0128】
22.前記第2の暗号文を取得することが、さらに、追加認証データに基づくものであり、
前記生成された認証されたペイロードが、さらに、前記追加認証データを含み、
前記データ鍵及び前記鍵識別子を取得することが、さらに、前記追加認証データに基づくものである、条項21に記載のシステム。
【0129】
23.前記第1の暗号文を生成することが、少なくとも前記メッセージ及び前記公開鍵を暗号化することに基づき、
前記第2のメモリが、さらに、前記第2のコンピュータシステムに、前記公開鍵を少なくとも前記第2の暗号文及び前記認証タグに基づいて取得させる実行可能命令を格納する、条項21または22に記載のシステム。
【0130】
24.前記秘密鍵が楕円曲線秘密鍵であり、前記公開鍵が楕円曲線公開鍵である、条項21~23のいずれかに記載のシステム。
【0131】
25.実行可能命令で構成された1つまたは複数のコンピュータシステムの制御下で、
暗号化データ鍵を取得し、前記データ鍵を用いて少なくともメッセージを暗号化することによって、前記メッセージに少なくとも部分的に基づく第1の暗号文を生成することと、
非対称秘密鍵を用いて、前記第1の暗号文に少なくとも部分的に基づいてデジタル署名を生成することと、
少なくとも前記第1の暗号文及び前記デジタル署名を含むデジタル署名されたペイロードを生成することと、
暗号化サービスに、少なくとも前記暗号化データ鍵及び前記非対称秘密鍵に対応する非対称公開鍵を提供することによって、認証付き暗号化を要求することであって、少なくとも前記暗号化データ鍵は暗号化されるとして示される、前記要求することと、
前記認証付き暗号化の要求に応えて、第2の暗号文及び認証タグを受信することと、
少なくとも前記第2の暗号文、前記非対称公開鍵及び前記認証タグを含む認証されたペイロードを生成することと、
別のコンピュータシステムに、少なくとも前記デジタル署名されたペイロード及び前記認証されたペイロードを利用可能にすることとを含む、コンピュータによって実装される方法。
【0132】
26.前記認証付き暗号化を要求することが、さらに追加認証データを提供することを含み、
前記認証されたペイロードが、さらに前記追加認証データを含む、条項25に記載のコンピュータによって実装される方法。
【0133】
27.前記非対称秘密鍵が楕円曲線秘密鍵であり、前記非対称公開鍵が楕円曲線公開鍵である、条項25または26に記載のコンピュータによって実装される方法。
【0134】
28.前記認証付き暗号化を要求するのにウェブAPI要求が用いられる、条項25~27のいずれかに記載のコンピュータによって実装される方法。
【0135】
29.前記暗号化サービスに前記認証付き暗号化を行うことを要求することが、さらに、前記非対称公開鍵が暗号化されることを示すことを含む、条項25~28のいずれかに記載のコンピュータによって実装される方法。
【0136】
30.前記認証付き暗号化を要求することが、さらに、ノンスを提供することを含む、条項26に記載のコンピュータによって実装される方法。
【0137】
31.前記認証付き暗号化がAES-CCMまたはAES-GCM暗号化である、条項30に記載のコンピュータによって実装される方法。
【0138】
32.1つまたは複数のTCPパケットで前記デジタル署名されたペイロード及び前記認証されたペイロードを送信することによって、少なくとも前記デジタル署名されたペイロード及び前記認証されたペイロードが利用可能になされた、条項25~31のいずれかに記載のコンピュータによって実装される方法。
【0139】
33.前記暗号化サービスから前記暗号化データ鍵を取得するのに、ウェブAPI要求が用いられる、条項25~32のいずれかに記載のコンピュータによって実装される方法。
【0140】
34.コンピュータシステムの1つまたは複数のプロセッサによって実行された結果として、前記コンピュータシステムが、少なくとも、
第1の暗号文及び前記第1の暗号文全体へのデジタル署名をさらに備えるデジタル署名されたペイロード、及び
第2の暗号文、非対称公開鍵及び認証タグをさらに備える認証されたペイロードを備える保護されたメッセージを受信し、
暗号化サービスに、少なくとも前記第2の暗号文、前記非対称公開鍵及び前記認証タグを提供することによって、前記第2の暗号文の認証付き復号化を要求し、
前記認証付き復号化の要求に応えて、少なくとも暗号化データ鍵及び鍵識別子を受信し、
前記鍵識別子が予測されるクライアントに関連付けられた予測される鍵識別子に一致すること及び前記デジタル署名されたペイロードの前記デジタル署名が有効であることを検証し、
前記暗号化データ鍵を用いて、前記デジタル署名されたペイロードの前記第1の暗号文を復号化することによってメッセージを取得する実行可能命令を格納する非一時的なコンピュータ可読記憶媒体。
【0141】
35.前記非対称公開鍵が楕円曲線公開鍵である、条項34に記載の非一時的なコンピュータ可読記憶媒体。
【0142】
36.前記保護されたメッセージが、さらに、前記非対称公開鍵を備える、条項34または35に記載の非一時的なコンピュータ可読記憶媒体。
【0143】
37.前記認証付き復号化を要求するのにウェブAPI要求が用いられる、条項34~36のいずれかに記載の非一時的なコンピュータ可読記憶媒体。
【0144】
38.前記命令が、さらに、前記1つまたは複数のプロセッサによって実行された結果として、前記コンピュータシステムに、前記認証付き復号化の要求に応えて、少なくとも前記暗号化データ鍵、前記非対称公開鍵及び前記鍵識別子を受信させる命令をさらに備える、条項34~37のいずれかに記載の非一時的なコンピュータ可読記憶媒体。
【0145】
39.前記暗号化データ鍵が対称暗号化鍵である、条項34~38のいずれかに記載の非一時的なコンピュータ可読記憶媒体。
【0146】
40.前記デジタル署名が検証された後で、前記メッセージが取得され、
少なくとも前記暗号化データ鍵及び前記鍵識別子を受信した後で、前記デジタル署名が検証され、
前記鍵識別子が予測されるクライアントに関連付けられた前記予測される鍵識別子と一致することを検証した後で、前記デジタル署名が検証される、条項34~39のいずれかに記載の非一時的なコンピュータ可読記憶媒体。
【0147】
41.前記保護されたメッセージが1つまたは複数のTCPパケットの一部として受信される、条項34~40のいずれかに記載の非一時的なコンピュータ可読記憶媒体。
【0148】
多様な実施形態は、多種多様な動作環境でさらに実装することができ、該動作環境は場合によっては、いくつかのアプリケーションのいずれかを操作するために使用できる1つまたは複数のユーザーコンピュータ、コンピューティング装置または処理装置を含むことがある。ユーザーデバイスまたはクライアントデバイスは、標準オペレーティングシステムを実行するデスクトップ、ラップトップまたはタブレットコンピュータ等のいくつかのコンピュータのいずれか、ならびに携帯電話向けソフトウェアを実行し、かついくつかのネットワーキングプロトコル及びメッセージプロトコルをサポートできる、セルラーデバイス、無線デバイス及びハンドヘルドデバイスを含むことがある。係るシステムは、さまざまな市販のオペレーティングシステムならびに開発及びデータベース管理等の目的のための他の既知のアプリケーションのいずれかを実行するいくつかのワークステーションを含むこともある。これらのデバイスは、ダミー端子、シンクライアント、ゲーム機、及びネットワークを介して通信することができる他のデバイス等の、他の電子デバイスもまた含み得る。これらのデバイスは、仮想マシン、ハイパーバイザ及びネットワークを介する通信が可能である他の仮想デバイスなどの仮想デバイスも含み得る。
【0149】
本開示の様々な実施形態は、伝送制御プロトコル/インターネットプロトコル(「TCP/IP」)、ユーザデータグラムプロトコル(「UDP」)、オープンシステムインターコネクション(「OSI」)モデルの様々な層で動作するプロトコル、ファイル転送プロトコル(「FTP」)、ユニバーサルプラグアンドプレイ(「UpnP」)、ネットワークファイルシステム(「NFS」)、共通インターネットファイルシステム(「CIFS」)、及びAppleTalk等のさまざまな市販のプロトコルのいずれかを使用し、通信をサポートするための当業者によく知られているだろう少なくとも1つのネットワークを活用する。ネットワークは、例えば、ローカルエリアネットワーク、広域ネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、無線ネットワーク、衛星ネットワーク及びその任意の組合せであることがある。いくつかの実施形態では、コネクション型のプロトコルを用いて、ネットワークエンドポイント間で通信し得る。コネクション型のプロトコル(場合によってはコネクションベースのプロトコルと呼ばれる)は、順序付けられたストリームでデータを送信可能である。コネクション型のプロトコルは、信頼できるものであり得、または信頼できないものであり得る。例えば、TCPプロトコルは信頼できるコネクション型のプロトコルである。非同期転送モード(「ATM」)及びフレームリレーは、信頼できないコネクション型のプロトコルである。コネクション型のプロトコルは、パケットを保証された順序付けなしで送信するUDPなどのパケット型のプロトコルとは多いに異なる。
【0150】
ウェブサーバを利用する実施形態では、ウェブサーバは、ハイパーテキスト転送プロトコル(「HTTP」)サーバ、FTPサーバ、共通ゲートウェイインタフェース(「CGI」)サーバ、データサーバ、Javaサーバ、Apacheサーバ及びビジネスアプリケーションサーバを含むさまざまなサーバまたは中間層アプリケーションのいずれかを実行できる。また、サーバ(複数可)はJava(登録商標)、C、C#、もしくはC++等の任意のプログラミング言語、またはRuby、PHP、Perl、Python、もしくはTCL等の任意のスクリプト言語、ならびにその組合せで書かれた1つまたは複数のスクリプトまたはプログラムとして実装されてよい1つまたは複数のウェブアプリケーションを実行することによって等、ユーザーデバイスからの要求に応えてプログラムまたはスクリプトを実行可能でもあり得る。また、サーバ(複数可)は、Oracle(登録商標)、Microsoft(登録商標)、Sybase(登録商標)及びIBM(登録商標)から市販されているものならびにMySQL、Postgres、SQLite、MongoDB及び構造化データまたは非構造化データの格納、取得かつアクセスが可能である任意の他のサーバ等のオープンソースサーバを含むがこれらに制限されないデータベースサーバを含んでもよい。データベースサーバには、テーブルベースのサーバ、ドキュメントベースのサーバ、非構造化サーバ、リレーショナルサーバ、非リレーショナルサーバ、またはこれらのかつ/または他のデータベースサーバの組み合わせが含まれ得る。
【0151】
環境は、上述のさまざまなデータストアならびに他のメモリ及び記憶媒体を含むことがある。これらは、コンピュータの1つまたは複数にローカルな(かつ/またはそこに常駐する)またはネットワーク全体でのコンピュータのいずれかまたはすべてから遠く離れた記憶媒体上等のさまざまな場所に常駐することがある。実施形態の特定の一式では、情報は、当業者によく知られているストレージエリアネットワーク(「SAN」)に常駐することがある。同様に、コンピュータ、サーバ、または他のネットワークデバイスによる機能を実行するためのあらゆる必要なファイルは、必要に応じてローカルにかつ/または遠隔に記憶されてよい。システムがコンピュータ化デバイスを含む場合、係るそれぞれのデバイスはバスを介して電気的に結びつきされてよいハードウェア要素を含むことがあり、該要素は、例えば、少なくとも1つの中央演算処理装置(「CPU」または「プロセッサ」)、少なくとも1つの入力装置(例えば、マウス、キーボード、コントローラ、タッチスクリーンまたはキーパッド)及び少なくとも1つの出力装置(例えば、表示装置、プリンタまたはスピーカ)を含むことがある。また、係るシステムは、ディスクドライブ、光学式記憶デバイス等の1つまたは複数の記憶装置、及びランダムアクセスメモリ(「RAM」)または読出し専用メモリ(「ROM」)等のソリッドステート記憶装置、ならびに取り外し可能な媒体デバイス、メモリカード、フラッシュカード等を含んでもよい。
【0152】
また、係るデバイスは、上述のようにコンピュータ可読記憶媒体読取り装置、通信装置(例えば、モデム、ネットワークカード(無線または有線)、赤外線通信装置等)、及び作業メモリを含むこともある。コンピュータ可読記憶媒体読取り装置は、遠隔記憶装置、ローカル記憶装置、固定記憶装置、及び/または取外し可能な記憶装置を表すコンピュータ可読記憶媒体、ならびにコンピュータ可読情報を一時的にかつ/またはより恒久的に含む、記憶する、伝送する、及び取り出すための記憶媒体と接続できる、またはそれらを受け取るように構成できる。また、システム及び多様なデバイスは、通常、クライアントアプリケーションもしくはウェブブラウザ等のオペレーティングシステム及びアプリケーションプログラムを含む、いくつかのソフトウェアアプリケーション、モジュール、サービス、または、少なくとも1つの作業用メモリデバイスの中に位置する他の要素を含む。さらに、カスタマイズされたハードウェアが使用される可能性もある、かつ/または特定の要素がハードウェア、(アプレット等のポータブルソフトウェアを含む)ソフトウェア、または両方で実装される可能性もある。さらに、ネットワーク入力/出力装置等の、他のコンピューティングデバイスへの接続が用いられてよい。
【0153】
コードまたはコードの一部を含むための記憶媒体及びコンピュータ可読媒体は、RAM、ROM、電子的消去プログラム可能型読取専用メモリ(「EEPROM」)、フラッシュメモリ、もしくは他のメモリ技術、コンパクトディスクリードオンリーメモリ(「CD-ROM」)、デジタル多用途ディスク(DVD)、もしくは他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスク記憶装置、もしくは他の磁気記憶装置、または所望の情報を記憶するために使用することができ、かつシステムデバイスによってアクセスできる任意の他の媒体を含む、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータ等の情報の記憶及び/または伝送のために任意の方法または技術で実装される揮発性及び不揮発性の媒体、取外し可能及び取外しできない媒体等であるが、これに限定されるものではない記憶媒体及び通信媒体を含む当該術において既知の、または使用される任意の適切な媒体を含むことがある。本開示及び本明細書に示される教示に基づいて、当業者は多様な実施形態を実装するための他の手法及び/または方法を理解するであろう。
【0154】
したがって、明細書及び図面は、限定的な意味ではなく例示的な意味で考えられるべきである。しかしながら、特許請求の範囲で述べられる本発明のより広い精神及び範囲から逸脱することなく、それに様々な修正及び変更がなされ得るということが明らかであろう。
【0155】
他の変形形態は、本開示の精神の範囲内である。したがって、開示された技術は多様な修正形態及び代替構成の影響を受けやすいが、その特定の示される実施形態は図面に示され、上記に詳細に説明されている。しかしながら、本発明を特定の形式または開示される形式に限定する意図はなく、しかし、逆に、意図は、添付の特許請求の範囲において定義される本発明の精神及び範囲内に収まる、全ての修正、代替構造、及び等価物を網羅することであるということが理解されるべきである。
【0156】
開示される実施形態を説明する文脈における(特に以下の特許請求の範囲の文脈における)用語「a」、「an」、及び「the」ならびに同様の指示語の使用は、本明細書において別段の指示がない限り、または文脈に明らかに矛盾するものでない限り、単数及び複数の双方を網羅すると解釈される。用語「comprising(備える)」、「having(有する)」及び「containing(含む)」は、別段の記述がない限り、オープンエンド用語(すなわち「including,but not limited to,(を含むが、これらに限定されるものではない)」を意味する)として解釈される。用語「connected(接続された)」は、修飾されず物理的な接続を指すとき、たとえ介在するものがあっても部分的にまたは完全に、中に含まれる、取り付けられる、または互いに結びつきされるとして解釈される。本明細書での値の範囲の列挙は、本明細書に別段の指示がない限り、単に、範囲内に入るそれぞれの別個の値に個別に言及する短縮方法としての役割を果たすことが意図され、各個別の値は、それが個別に本明細書に記載されているかのように本明細書に組み込まれる。用語「set(セット)」(例えば「アイテムのセット」)または「subset(サブセット)」の使用は、それ以外に記述されるか文脈によって矛盾しない限り、1つまたは複数のメンバーを備える非空のコレクションとして解釈される。さらに、それ以外に記述されるか文脈によって矛盾しない限り、対応するセットの「subset(サブセット)」という用語は、必ずしも対応するセットの適切なサブセットを示すものではないが、サブセットと、対応するセットは等しくてもよい。
【0157】
特に断りのない限りまたは文脈から明らかに矛盾しない限り、「at least one of A,B,and C(A、B及びCの少なくとも1つ)」または「at least one of A,B,and C(A、B及びCの少なくとも1つ)」という形の句といった連結的な言語は、項目、用語等がAもしくはBもしくはC、またはA、B及びCのセットの任意の非空のサブセットであってよいことを示すために一般的に用いられるとして文脈の中で他の意味に理解される。例えば、3つのメンバーを有するセットの具体例では、「at least one of A,B,and C(A、B及びCの少なくとも1つ)」及び「at least one of A,B,and C(A、B及びCの少なくとも1つ)」という連結的な句は、以下のセット、{A},{B},{C},{A,B},{A,C},{B,C},{A,B,C}のいずれかを指す。したがって、そのような連結的な言語は、一般に、一定の実施形態が、Aの少なくとも1つ、Bの少なくとも1つ及びCの少なくとも1つがそれぞれ存在することを必要とすることを含意することは意図していない。
【0158】
本明細書に記載されるプロセスの動作は、本明細書で別段の指示がない限り、または文脈に明らかに矛盾するものでない限り、任意の適切な順序で実行できる。本明細書中に記載されるプロセス(またはその変形形態及び/もしくは組み合わせ)は、実行可能命令で構成される1つまたは複数のコンピュータシステムの制御下で実行され得、ハードウェアまたはその組合せにより1つまたは複数のプロセッサで集合的に実行するコード(例えば、実行可能命令、1つもしくは複数のコンピュータプログラム、または1つもしくは複数のアプリケーション)として実装され得る。コードは、例えば1つまたは複数のプロセッサによって実行可能な複数の命令を含むコンピュータプログラムの形でコンピュータ可読記憶媒体に記憶されてよい。コンピュータ可読記憶媒体は非一時的であり得る。いくつかの実施形態では、コードは、コンピュータシステムの1つまたは複数のプロセッサによって実行されると(すなわち実行された結果として)、コンピュータシステムが、本明細書中で記載された動作を行う実行可能命令を格納した1つまたは複数の非一時的なコンピュータ可読記憶媒体のセットに格納されている。非一時的なコンピュータ可読記憶媒体のセットは、複数の非一時的なコンピュータ可読記憶媒体を備え得、複数の非一時的なコンピュータ可読記憶媒体の個々の非一時的な記憶媒体の1つまたは複数は、コード全てがなくてもよい一方、複数の非一時的なコンピュータ可読記憶媒体は、コード全てを集合的に格納する。さらに、いくつかの例では、実行可能命令は、異なる命令は異なるプロセッサによって実行されるように、実行される。具体例として、非一時的なコンピュータ可読記憶媒体は、命令を格納し得る。メインCPUは、命令の一部を実行し得、グラフィック処理装置は、他の命令を実行し得る。一般に、コンピュータシステムの異なる構成要素は別々のプロセッサを有し得、異なるプロセッサは命令の異なるサブセットを実行し得る。
【0159】
したがって、いくつかの例では、コンピュータシステムは、本明細書中で記載されたプロセスの動作を単一でまたは集合的に行う1つまたは複数のサービスを実装するように構成されている。そうしたコンピュータシステムは、例えば、動作の性能を有効にする適用可能なハードウェア及び/またはソフトウェアで構成され得る。さらに、本開示の様々な実施形態を実装するコンピュータシステムは、いくつかの例では、単一のデバイスであってもよく、他の例では、分散型コンピュータシステムが本明細書中で記載された動作を行うようにかつ単一のデバイスが動作全てを行わないように、異なるように動作する複数のデバイスを備える分散型コンピュータシステムであってもよい。
【0160】
本明細書で示される任意の及びすべての例、または例示的な言語(例えば、「such as(~など)」)の使用は、単に本発明の実施形態をよりよく示すことを意図しており、別段の主張がない限り、本発明の範囲を限定するものではない。本明細書のいかなる言葉も、本発明の実施にとって必須として任意の請求されていない要素を示すものと解釈されるべきではない。
【0161】
本発明を実施するために本発明者らに知られている最良の形態を含む本開示の実施形態を本明細書に記載する。それらの実施形態の変形形態は、前述の説明を読むと当業者に明らかになり得る。本発明者らは、当業者がこのような変形形態を必要に応じて利用することを期待し、本発明者らは本開示の実施形態が本明細書に具体的に記載されたものとは別の方法で実施されることを意図する。したがって、本開示の範囲は、適用法によって許容されるように、本明細書に添付された特許請求の範囲に記載された主題のすべての修正形態及び均等物を含む。さらに、本明細書に別段の指示がない限り、または文脈に明らかに矛盾するものでない限り、上述要素のすべての考え得る変形形態での上述要素の任意の組合せが本開示の範囲に包含される。
【0162】
あたかも各参考文献が個々にかつ具体的に参照により援用されることが示され本明細書中にその全体として記載されるかのように、本明細書で引用した刊行物、特許出願及び特許を含むすべての参考文献は、同程度に参照により本明細書によって援用される。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15