JP2009530906A - コールサインを用いたエンドポイント検証 - Google Patents

Abstract

ウェブサイトへの接続を検証するように、コンピュータシステムが構成される。本コンピュータシステムは、ウェブサイトに関連付けたユニフォームリソースロケータおよびコールサインを受信するようにプログラムされたユーザインタフェースを備える。本コンピュータシステムは、ユニフォームリソースロケータ、ウェブサイトに関連付けた公開鍵、およびソルトに基づいてハッシュ値を計算するようプログラムされた検証モジュールであって、ハッシュ値とコールサインを比較し、ウェブサイトへの接続を検証するようにプログラムされるた検証モジュールも備える。

Description

ビジネスおよび娯楽を目的としたオンラインサービスの使用が増えている。例えば、多くの人はインターネット上のウェブサイトを利用して、以前は対面で、または電話で行われたビジネスを遂行する。ユーザは、ウェブサイトのＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）をユーザのコンピュータ上で実行されているブラウザにタイプすることで、インターネット上のウェブサイトに到達することができる。幾つかの状況では、ユーザは、自分が所望のウェブサイトに実際に到達したことを検証したい場合がある。ユーザが所望のウェブサイトに到達したことの検証は、様々な理由で重要でありうる。例えば、ユーザが所望のウェブサイトに到達したことの検証により、フィッシングおよびファーミングのような、個人情報の盗難および金銭的な損失の結果となりうる詐欺活動の影響が最小化される。加えて、検証によりユーザの自信を深め、ユーザのそのウェブサイトとの取引願望を高めることができる。

ユーザが所望のウェブサイトに到達したことを検証する１つの方法は、信頼されたサ−ドパーティが発行するウェブサイトのデジタル証明書をダウンロードすることである。信頼されたサードパーティはデジタル証明書の内容を保証し、そのデジタル証明書はウェブサイトに対する公開鍵を含む。その公開鍵を使用して、ウェブサイトに送信するメッセージを暗号化することができる。秘密鍵を有するウェブサイトのみがそのメッセージを復号することができる。このように、ユーザは自分が所望のウェブサイトと通信しているという自信を持つことができる。

上記の方法を使用してユーザが所望のウェブサイトに到達したことを検証することができる一方、本方法は、サードパーティを使用してデジタル証明書を発行および維持しなければならないので、コストが高い恐れがある。他の状況では、サードパーティを導入して信頼を確立することが適当でない場合がある。例えば、親密なビジネスパートナである２つのパーティが、サードパーティではなく、全ての信頼性の側面を制御する電子的関係を生成したい場合がある。他の例では、サードパーティの導入により不要なプライバシー問題を引き起こす恐れがある。

ユーザは、従って、効率的な検証システムおよび方法を望む場合であろう。また、ユーザは、ユーザが自分のニーズに基づいて、ウェブサイトの検証の相対強度を決定できる検証システムおよび方法を望むであろう。

米国特許出願公開第１０／８８２，０７９号明細書

本要約は選択した概念を簡潔な形で導入するために与える。その概念を「発明を実施するための最良の形態」でさらに後述する。本要約は特許請求主題の主要な特徴または本質的な特徴を特定するようには意図しておらず、特許請求主題の範囲の決定を支援するものとしても意図していない。

１つの態様は、ウェブサイトへの接続を検証するよう構成したコンピュータシステムに関する。このコンピュータシステムは、ウェブサイトに関連付けたユニフォームリソースロケータとコールサインとを受信するようプログラムしたユーザインタフェースを含む。このコンピュータシステムは、ユニフォームリソースロケータ、ウェブサイトに関連付けた公開鍵、およびソルト（ｓａｌｔ）に基づいてハッシュ値を計算するようプログラムしたバリデータモジュールを含み、そのバリデータモジュールはそのハッシュ値をコールサインと比較してウェブサイトへの接続を検証する。

別の態様は、ウェブサービスへの接続を検証する方法に関する。その方法は、コールサインを受信すること、ウェブサービスに関連付けた公開鍵とソルトとを受信すること、ウェブサービスに関連付けたユニフォームリソースロケータと、公開鍵と、ソルトとを用いてハッシュ値を計算すること、ハッシュ値をコールサインと比較すること、およびハッシュ値がコールサインとマッチするかどうかを示すことを含む。

さらに別の態様は、ウェブサービスへの接続を検証する方法に関する。その方法は、ウェブサービスに関連付けたユニフォームリソースロケータをユーザから受信すること、ウェブサービスに関連付けた公開鍵とソルトとを受信すること、ユニフォームリソースインジケータ、公開鍵、およびソルトを用いてハッシュ値を計算すること、ユーザからコールサインの文字（ｃｈａｒａｃｔｅｒ）を受信すること、ハッシュ値がコールサインにマッチするかどうかを示すこと、およびユーザから受信したコールサインの文字に基づいて暗号強度を示すことを含む。

添付図面は必ずしも正しい縮尺で描いていないが、次に、それら添付図面を参照する。

以降、添付図面を参照して、実施形態の例をより完全に説明する。本開示が徹底的且つ完全となるようこれらの実施形態を提供する。同じ番号は全体を通して同じ要素を指す。

本明細書で開示した実施形態の例は、一般に、クライアントが所望のウェブサービスに到達したことの検証に関する。実施形態の例では、ウェブサービスへの接続時にコールサインを使用して、所望のウェブサービスに到達したことの確証レベルを実現する。幾つかの実施形態では、所与のコールサインの長さは、クライアントが望む確証レベルに依存して変化してもよい。実施形態の例では、コールサインはクライアントのユーザにとって理解可能である。

図１を参照する。コンピューティング環境の例１００はコンピュータシステム１１０、インターネット１３０のようなネットワーク、およびウェブサイト１５０のようなウェブサービスから成る実施形態を含む。コンピュータシステムの例１１０をユーザにより制御して、インターネット１３０を通してウェブサイト１５０と通信することができる。

コンピュータシステムの例１１０は、少なくとも１つのプロセッサおよびメモリを含むパーソナルコンピュータとして構成できる。コンピュータシステム１１０は、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータのような情報を記憶するための任意の方法、または技術で実装した１つまたは複数の揮発性および不揮発性コンピュータ記憶媒体、並びに取り外し可能および取り外し不可能媒体を含む。コンピュータシステム１１０は、本件特許出願人のＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムのようなオペレーティングシステム、およびコンピュータ可読媒体に記憶した１つまたは複数のプログラムを含む。

コンピュータシステム１１０は、１つまたは複数の入出力通信装置も含む。その装置によりユーザは、コンピュータシステム１１０と通信することができ、コンピュータシステム１１０はインターネット１３０およびウェブサイト１５０のような他の装置と通信することができる。図１に示す出力装置の１つの例はディスプレイ１１２である。コンピュータシステム１１０、インターネット１３０、およびウェブサイト１５０間の通信を、有線および／または無線技術を用いて実装することができる。

実施形態の例では、本件特許出願人が部分的に推奨するＷＳ−Ａｄｄｒｅｓｓｉｎｇ（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ａｄｄｒｅｓｓｉｎｇ）仕様で定義される転送メカニズムを用いてシステム１１０およびウェブサイト１５０が通信する。一般に、ＷＳ−Ａｄｄｒｅｓｓｉｎｇは、システム１１０およびウェブサイト１５０のようなサービスが互いに通信できるトランスポートニュートラルなメカニズムを定義している。

コンピュータシステム１１０のユーザは、ブラウザ１１４のようなコンピュータシステム１１０上のプログラムを用いてウェブサイト１５０にアクセスできる。ブラウザの１つの例は、Ｍｉｃｒｏｓｏｆｔ社提供のＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒブラウザである。一実施形態では、コンピュータシステム１１０上で実行されているブラウザ１１４はＨＴＴＰＳ（ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ ｓｅｃｕｒｅ）プロトコルを用いてウェブサイト１５０と通信するが、他のプロトコルを使用してもよい。

図１〜図４を参照する。ユーザがウェブサイト１５０と通信したい場合、ユーザはウェブサイト１５０に関連付けたＵＲＬ４１０（例えば、ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ）をブラウザ１１４のアドレスウィンドウ３２０に入力する。ユーザはウェブサイト１５０に関連付けたコールサイン４２０も入力する。コールサイン４２０を「＃」文字によりＵＲＬ４１０から分離するが、他の文字および／または方法も使用できる。以下でさらに説明するように、コールサイン４２０を使用して、ユーザが所望のウェブサイトに到達したことを検証することができる。

一般に、コールサイン４２０はユーザが理解可能である数字および／または英字を含む文字列である。例えば、幾つかの実施形態では、ユーザからコールサイン４２０を覚えて容易にコールサイン４２０をウィンドウ３２０に入力することができるよう、コールサイン４２０はその長さを十分に短くしている。例えば、コールサイン４２０は社会保障番号（９文字）または電話番号（１０文字）の長さ以下である。他の実施形態では、コールサインは１５文字以下の文字、７文字以下の文字、または５文字以下の文字を含む。一般に、コールサイン４２０を、友達、同僚、ビジネス、ウェブサイト、等のようなユーザが信頼するパーティによりユーザに与える。

コールサイン４２０の１つの例は「９５１６−１５７８」である。実施形態の例では、コールサイン４２０は多数の文字を含み、暗号プロセスを用いて生成する。１つの実施形態では、コールサイン４２０の夫々の文字は５つのバイナリ数を表す。例えば、長いバイナリ数を５つのビットセグメントに分割して、コールサイン４１０の文字列をエンコードする。コールサイン４２０の最初の文字は、コールサイン４１０のデコードに使用する零の数をエンコードする。コールサイン４２０の残りの文字は、残りのバイナリ数を表す。

示した例では、コールサイン４２０を、ウェブサイト１５０に関連付けた公開鍵「Ｋ」、ウェブサイト１５０のＵＲＬを含む接頭語「Ｐ」、およびランダムな数字であるソルト値「Ｓ」を取ることで生成する。これらの３つの値を、暗号１方向関数を使用してハッシュ化し、１つまたは複数のハッシュ値（「Ｈ」）を生成する。ハッシュ化は数学的アルゴリズムを任意の量のデータに適用することで、固定サイズの結果を生成する暗号プロセスである。本実施形態で使用するハッシュ関数の例には、ＭＤ２、ＭＤ４、ＭＤ５、およびＳＨＡ−１が含まれる。他の関数を同様に使用することができる。

ハッシュ値を以下のように生成することができる。

ソルト「Ｓ」は、結果が所望の数の零で開始する１つまたは複数のハッシュ値となるまで、所与の時間だけ変化する。コールサイン４２０を、次いで、数字および／または英字を用いてハッシュ値をエンコードすることで計算する。示した例では、コールサイン４２０をエンコード中に５ビットのセグメントに分割する。

コールサインに関するさらなる詳細は、「特許文献１」に見出すことができ、その全体は引用により本明細書に取り入れられる。

再度図１〜図４を参照する。ユーザがＵＲＬ４１０およびコールサイン４２０を入力した後、システム１１０をプログラムしてウェブサイト１５０のＵＲＬ４１０宛てのメッセージ１１５を送信する。メッセージ１１５を、以下でさらに説明するＷＳ−Ａｄｄｒｅｓｓｉｎｇおよびウェブサービス記述言語標準に従ってフォーマットすることができる。メッセージ１１５はウェブサイト１５０に関連付けた公開鍵およびソルトに対する要求を含む。

メッセージ１１５に応じて、ウェブサイト１５０は、ウェブサイト１５０に関連付けた公開鍵およびソルトを含む応答メッセージ２２０をシステム１１０送信する。１つの例では、メッセージ２２０はウェブサイト１１５からのデジタル証明書である。他のフォーマットを使用してもよい。

コンピュータシステム１１０がメッセージ２２０を受信する場合、コンピュータシステム１１０の検証モジュール１１６をプログラムして、ウェブサイト１５０に関連付けた、ＵＲＬ４１０のハッシュ、公開鍵、およびソルトを計算する。検証モジュール１１６をさらにプログラムして、結果のハッシュ値をコールサイン４２０のそれと比較して、ハッシュ値がコールサイン４２０にマッチすることを検証する。このように、検証モジュール１１６は公開鍵がウェブサイト１５０に関連付けられることを検証し、ユーザが所望のウェブサイトに到達したという確証レベルをユーザに提供する。

検証モジュール１１６により計算されたハッシュ値がコールサイン４２０にマッチする場合、コンピュータシステム１１０をプログラムしてそのマッチをユーザに通知する。例えば、ウィンドウ３１０を第１の色（例えば、緑）で色づけしてマッチを示すことができ、第２の色（例えば、赤）で色づけしてハッシュ値がコールサイン４２０にマッチしないことを示す。代替的実施形態では、テキストまたは音声インジケータのような他形態の通知を使用することができる。

図５〜図８を参照する。幾つかの実施形態では、強度メータ５１０をブラウザ１１４に含める。一般に、強度メータ５１０はアドレスウィンドウ３２０内で使用するコールサイン５２０の相対的な「強度」を示すものを提供する。コールサイン５２０の強度を、コールサイン５２０を「分割（break）」するための難易度、または同一のコールサイン５２０となる別の公開鍵を識別するのに必要な時間およびリソース量を推定することで測定する。

実施形態の例では、特定のコールサインの強度を、コールサインを分割するのに必要な時間およびリソースの量を考慮することで計算する。鍵を生成するのに或る一定の時間量（例えば、５秒）を要し、所与の数の零「Ｚ」（例えば、２４ビット）でハッシュ値「Ｈ」を生成するのに或る特定の時間量を要すると仮定すると、夫々の鍵を計算するのに以下の時間量「Ｔ」を要する。

攻撃者が計算を実施するのに平均的な価格のコンピュータ（例えば、５００ドル）を有し、計算を行うのに１年間（例えば、３１５３６０００秒）あると仮定すると、特定長「Ｌ」のコールサインを分割するコストを以下のように推定することができる。

変数「Ｑ」は潜在的な攻撃者が「Ｑ」人の予想される犠牲者のうち任意の者に対してコールサインの分割を図る確率を考慮した因子を表す。一実施形態の例では、先行する零「Ｚ」の数は２５ビットでコールサインの長さ「Ｌ」が９文字である場合、コールサインを分割する推定コストはほぼ１５０億ドルである。

コンピュータシステム１１０の検証モジュール１１６をプログラムして、ブラウザ１１４の強度メータ５１０を利用し、ユーザにコールサイン５２０の相対強度を視覚的に示す。示した例では、強度メータ５１０は、長さを増加させてより強いコールサインを示し、長さを減少させてより弱いコールサインを示す。別の実施形態では、他種のインジケータを使用することができる。

幾つかの状況では、使用する暗号化の強度を変更できることが望ましいかもしれない。例えば、ユーザがウェブサイト１５０に接続して、その夜のテレビ番組をレビューしている場合、自分が所望のウェブサイトに到達したかどうかを、そのユーザが検証することはあまり重要でない可能性がある。しかしながら、ユーザがウェブサイト１５０に接続して金銭取引を行っているときは、ユーザはより強い検証を望むかもしれない。

幾つかの実施形態では、コンピュータシステム１１０をプログラムすることで、ユーザはコールサイン５２０の一部のみを入力することができる。例えば、コールサイン５２０の全体が「９５１６−１５７８」であると仮定すると、図５および図６に示すようにユーザがコールサイン５２０の最初の４文字（すなわち、「９５１６」）のみを入力する場合、検証モジュール１１６をプログラムしてその部分的なコールサインを、計算したハッシュ値と比較してマッチを検証し、強度メータ５１０で入力文字の相対強度を示す。

幾つかの実施形態では、ユーザがさらなる強度を望む場合、図７および図８に示すようにユーザはコールサイン５２０の文字（すなわち、「９５１６−１５７８」）入力を続けることができる。検証モジュール１１６は計算したハッシュ値とコールサイン５２０のマッチを検証し、メータ５１０内の強度表示を増加させる。このように、ユーザは、状況と所望の検証レベルとに合わせ、ユーザがコールサイン５２０に対して入力したい文字数を決定することができる。

例えば、４つの文字グループに分割される５ビットの文字をコールサインが含むと仮定すると、コードグループ毎に２０ビットがあり、零「Ｚ」の数は２５ビットであり、夫々の文字グループを入力するとコールサインを分割するためのコストは以下のように増加すると推定できる。
・１つの文字グループ ‐ 分割に２８ドルのコスト
・２つの文字グループ ‐ 分割に３千万ドルのコスト、および
・３つの文字グループ ‐ 分割に３０兆ドルのコスト
この金額、またはこの金額を反映するスケールを、ユーザがコールサインの文字を入力する際にユーザに表示することができる。

代替的実施形態では、異なる視覚的（例えば、赤／黄／緑またはスライド式スケール）または音声インジケータを使用することができる。さらに、代替的実施形態では、コールサイン５２０の強度表示を、ブラウザ１１４とは別のユーザインタフェース内に提供できる。

代替的実施形態では、ユーザはコールサインをブラウザ１１４以外のユーザインタフェースに入力することができる。例えば、一代替的実施形態では、ユーザは別のユーザインタフェースの提供を受けコールサインを入力する。他の実施形態では、ユーザはコールサインを入力する必要は全くない。その代わり、以下でさらに説明するように、ＷＳ−Ａｄｄｒｅｓｓｉｎｇプロトコルを用いて、コールサインを別の信頼されたコンピュータシステム１１０によりコンピュータシステム１１０に転送することができる。

図９を参照する。別のコンピューティング環境の例６００を示してある。環境６００はリッチクライアント６１０、インターネット６３０、およびウェブサービス６５０を含む。実施形態の例では、リッチクライアント６１０はインターネット６３０上でウェブサービス６５０と通信するアプリケーションである。例えば、一実施形態では、リッチクライアント６１０は、証券会社のウェブサービス６５０との通信を通してユーザが株式を取引し、ポートフォリオを管理できるアプリケーションである。

実施形態の例では、ＵＲＬおよびコールサインを、リッチクライアント６１０が信頼するパーティによりリッチクライアント６１０に提供する。例えば、示した実施形態では、リッチクライアント６１０が信頼する別のリッチクライアント６２０が、ＵＲＬおよびコールサインをリッチクライアント６１０に転送する。

リッチクライアント６１０をプログラムしてウェブサービス６５０と通信し、ウェブサービス６５０に関連付けた公開鍵およびソルトを取得する。例えば、示した実施形態では、リッチクライアント６１０をプログラムして、ウェブサービス６５０に関連付けたＭｅｔａｄａｔａエンドポイントに接続し、ＷＳ−ＡｄｄｒｅｓｓｉｎｇおよびＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）１．１プロトコルに従って提供されるサービス記述をクエリする。

リッチクライアント６１０からのクエリに応じて、ウェブサービス６５０は、少なくともウェブサービス６５０に関連付けた公開鍵およびソルトを含むサービス記述を返却する。例えば、ウェブサービス６５０は、以下に示すようにＷＳ−Ａｄｄｒｅｓｓｉｎｇで定義したプロトコルを用いて公開鍵およびソルトをリッチクライアント６１０に送信する。
＜ＥｎｄＰｏｉｎｔＲｅｆｅｒｅｎｃｅ＞
<Address>http://www.microsoft.com/</Address>
<Identity>
<CallSignData>
<CallSign>AAA-B01-BYZ</CallSign>
<DistinguishedSalt>+PYbznDaB/dlhjIfqCQ458E72wA=</DistinguishedSalt>
<KeyValue>
<RSAKeyValue>
<Modulus>+rrbznDaB/dlhjIfqCQ458E72wA=</Modulus>
<Exponent>+PYbzppP=</Exponent>
</RSAKeyValue>
</KeyValue>
</CallSignData>
</Identity>
</EndPointReference>
以下で説明するように、上で与えた例では、ウェブサービス６５０は、リッチアプリケーション６１０に対する返却メッセージ内にコールサインの別のコピーを検証の目的で含む。

リッチクライアント６１０が公開鍵、ソルト、およびコールサインをウェブサービス６５０から受信すると、リッチクライアント６１０は、最初に、ウェブサービス６５０からのコールサインが、信頼されたサードパーティ（例えば、リッチアプリケーション６２０）からのコールサインにマッチすることを検証する。次に、リッチクライアント６１０はウェブサービス６５０に関連付けた公開鍵、ソルト、およびＵＲＬのハッシュ値を計算し、その結果をコールサインと比較して、公開鍵が所望のウェブサービス６５０のものであることを検証する。

図１０を参照する。コンピュータシステムがコールサインを使用して、所望のウェブサイトに到達したことを検証する方法の例７００を示してある。動作７１０で、コンピュータシステムは所望のウェブサイトのＵＲＬおよびコールサインを受信する。例えば、ユーザは信頼されたパーティからコールサインを取得した後に、ＵＲＬ、コールサインをコンピュータシステムに入力することができる。次に、動作７２０で、そのコンピュータシステムはウェブサイトからの公開鍵を要求する。制御は、次いで動作７３０に渡され、そこでコンピュータシステムはウェブサイトから公開鍵およびソルトを受信する。次に、動作７４０で、コンピュータシステムは、ＵＲＬ、公開鍵、およびソルトを用いてハッシュ値を計算する。

制御は、次いで動作７５０に渡され、そこでハッシュ値とコールサインがマッチするかどうかに関する決定を行う。ハッシュ値とコールサインがマッチする場合、制御は動作７６０に渡され、ユーザにそのマッチを通知する。または、ハッシュ値とコールサインが動作７５０でマッチしない場合、制御は動作７７０に渡され、ユーザにミスマッチを通知する。

図１１を参照する。コンピュータシステムがコールサインを使用して、所望のウェブサイトに到達したことを検証する別の方法８００を示してある。動作８１０で、コンピュータシステムは所望のウェブサイトのＵＲＬをユーザから受信する。次に、動作８２０で、コンピュータシステムはウェブサイトから公開鍵を要求する。制御は、次いで動作８３０に渡され、そこでコンピュータシステムはウェブサイトから公開鍵とソルトを受信する。次に、動作８４０で、コンピュータシステムは、ＵＲＬ、公開鍵、およびソルトを用いてハッシュ値を計算する。

制御は、次いで、動作８５０に渡され、そこでコンピュータシステムは少なくともコールサインの文字の一部をユーザから受信する。次に、動作８６０で、ハッシュ値と入力したコールサインとがマッチするかどうかの決定を行う。ハッシュ値とコールサインがマッチしない場合、制御は動作８７０に渡され、ユーザにミスマッチを通知する。

または、ハッシュ値と部分的なコールサインが動作８６０でマッチする場合、制御は動作８８０に渡され、コンピュータシステムはそのマッチを示し、入力されたコールサインの強度に基づいて強度メータを更新する。次いで、動作８９０で、コールサインの文字がまだ存在するかどうかに関して決定を行う。文字がまだ存在する場合、制御は動作８５０に戻り、コンピュータシステムは、コールサインの次の文字をユーザから受信するために待機する。ユーザが選択すれば、ユーザはコールサインの追加の文字を入力することができ、さらなる文字を入力すると、それに応じて強度メータを更新する。

上述した様々な実施形態は例として与えたに過ぎず、限定的と解釈すべきではない。当業界の技術者は、本開示または添付請求項の真の精神および範囲から逸脱せずに、上述の実施形態に対して可能な様々な修正および変更を容易に理解するであろう。

コンピュータシステムの実施形態をプログラムして所望のウェブサイトに到達したことを検証するコンピューティング環境の例を示す図である。 図１のコンピュータシステムおよびウェブサイトの例を示す図である。 図１のコンピュータシステムのグラフィカルユーザインタフェースの例を示す図である。 図３のグラフィカルユーザインタフェースの一部を示す図である。 図１のコンピュータシステムのグラフィカルユーザインタフェースの別の例を示す図である。 図５のグラフィカルユーザインタフェースの一部を示す図である。 図５のグラフィカルユーザインタフェースの別の図である。 図７のグラフィカルユーザインタフェースの一部を示す図である。 リッチクライアントの実施形態をプログラムして所望のウェブサービスに到達したことを検証する別のコンピューティング環境の例を示す図である。 コールサインを使用して所望のウェブサイトに到達したことを検証する方法の例を示す図である。 コールサインを使用して所望のウェブサイトに到達したことを検証する方法の別の例を示す図である。

Claims (20)

1. ウェブサイトへの接続を検証するよう構成したコンピュータシステムであって、
   前記ウェブサイトに関連付けたユニフォームリソースロケータおよびコールサインを受信するようプログラムしたユーザインタフェースと、
   前記ユニフォームリソースロケータ、前記ウェブサイトに関連付けた公開鍵、およびソルトに基づいて、ハッシュ値を計算するようプログラムした検証モジュールであって、前記ハッシュ値を前記コールサインと比較して前記ウェブサイトへの接続を検証するようプログラムした検証モジュールと
   を備えることを特徴とするコンピュータシステム。
2. 前記コールサインは文字列であることを特徴とする請求項１に記載のコンピュータシステム。
3. 前記文字列は前記コンピュータシステムのユーザに理解可能であることを特徴とする請求項２に記載のコンピュータシステム。
4. 前記コールサインを多ビットのバイナリ数からエンコードしたことを特徴とする請求項２に記載のコンピュータシステム。
5. 前記バイナリ数は複数の末尾の零を含み、前記コールサインの最初の文字は前記末尾の零の数をエンコードすることを特徴とする請求項４に記載のコンピュータシステム。
6. ユーザが前記ユーザインタフェースで入力した前記コールサインの強度インジケータを与えるように、前記検証モジュールをさらにプログラムしたことを特徴とする請求項１に記載のコンピュータシステム。
7. 前記コールサインの前記強度インジケータは、前記コールサインを分割（break）するためのコストの推定値を表すことを特徴とする請求項６に記載のコンピュータシステム。
8. ウェブサービスへの接続を検証する方法であって、
   コールサインを受信するステップと、
   前記ウェブサービスに関連付けた公開鍵およびソルトを受信するステップと、
   前記ウェブサービスに関連付けたユニフォームリソースロケータ、前記公開鍵、および前記ソルトを用いてハッシュ値を計算するステップと、
   前記ハッシュ値を前記コールサインと比較するステップと、
   前記ハッシュ値が前記コールサインにマッチするかどうかを示すステップと
   を含むことを特徴とする方法。
9. 前記コールサインを信頼されたパーティから受信することを特徴とする請求項８に記載の方法。
10. 前記公開鍵および前記ソルトを前記ウェブサービスから受信することを特徴とする請求項８に記載の方法。
11. 前記コールサインは文字列であることを特徴とする請求項８に記載の方法。
12. 前記文字列は前記コンピュータシステムのユーザに理解可能であることを特徴とする請求項１１に記載の方法。
13. 前記文字列は、長さが１０文字未満であることを特徴とする請求項１２に記載の方法。
14. 前記コールサインの強度を示すステップをさらに含むことを特徴とする請求項８に記載の方法。
15. 請求項８に記載のステップを実施するコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
16. ウェブサービスへの接続を検証する方法であって、
    前記ウェブサービスに関連付けたユニフォームリソースロケータを前記ユーザから受信するステップと、
    前記ウェブサービスに関連付けた公開鍵およびソルトを受信するステップと、
    前記ユニフォームリソースインジケータ、前記公開鍵、および前記ソルトを用いてハッシュ値を計算するステップと、
    コールサインの文字をユーザから受信するステップと、
    前記ハッシュ値が前記コールサインにマッチするかどうかを示すステップと、
    前記ユーザから受信した前記コールサインの文字に基づいて、暗号強度を示すステップと
    を含むことを特徴とする方法。
17. 前記コールサインの追加の文字を前記ユーザから受信するステップと、
    前記ハッシュ値を、入力された前記コールサインの前記文字と比較するステップと、
    前記ハッシュ値が前記コールサインとマッチするかどうかを示すステップと、
    入力された前記コールサインの前記文字に基づいて、前記暗号強度表示を更新するステップと
    をさらに含むことを特徴とする請求項１６に記載の方法。
18. 前記コールサインの前記暗号強度表示は、前記コールサインの分割（break）するためのコストの推定値を表すことを特徴とする請求項１６に記載の方法。
19. 前記暗号強度表示は、前記コールサインの前記暗号強度を示すためのメータを生成するステップを含むことを特徴とする請求項１６に記載の方法。
20. 請求項１６に記載のステップを実施するコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。

Images