ウェブページの真正性検証
証明書レジストリシステムが、複数の情報プロバイダの各プロバイダに発行される認証証明書を発行し、さらにこれらの認証証明書のすべてに対応するルート証明書を保持するように構成される。これらの認証証明書の各証明書は、その証明書のそれぞれの認証情報を、情報プロバイダの対応するプロバイダの識別情報に結び付ける。認証証明書の各証明書は、情報プロバイダの対応するプロバイダと、そのプロバイダのドメイン名情報との間のリンクを欠いている。証明書レジストリの認証証明書は、情報プロバイダが提供する情報の特定のタイプ、情報プロバイダが関連する特定の組織、情報プロバイダが携わっている特定のタイプの職業、および情報プロバイダが位置する特定の地理的区域のうち少なくとも１つに少なくとも或る程度、依存する仕方で関連する。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書で行われる開示は、一般に、コンピュータネットワークシステムにおける認証の備えに関し、より詳細には、ウェブページの真正性を検証することに関する。
【背景技術】
【０００２】
いくつもの理由で、電子メールメッセージ送信者の真正性を検証する必要性は、軽視され得ない。そのような認証は、電子メールメッセージの中で示される送信側エンティティの識別情報が、認証され得ない場合、警報をもたらす必要がある。電子メールメッセージの中で与えられる送信者識別情報の例には、送信側エンティティの名前、ロゴ、可聴音などが含まれるが、以上には限定されない。詐欺的な電子メールメッセージおよび悪意のある電子メールメッセージを送信するエンティティが何者であるかを知ることは有用であろうが、その一方で、単に、電子メールメッセージの中で与えられる送信者識別情報が、信頼される認証プロセスに合格したか、不合格であったかを簡単に知ることに極めて大きな価値がある。同様に、認証が、詐欺的な電子メールメッセージまたは悪意のある電子メールメッセージを送信している個人またはエンティティを識別しないものの、電子メールメッセージ送信者が、認証されることに成功しているか否かを知ることにも価値がある。
【０００３】
そのような電子メールメッセージ認証を提供するための有効で、実際的な手段の欠如が、例えば、「フィッシング」などの犯罪行為の急速な増加につながっている。フィッシングにおいて、犯罪者は、通常、受信者に電子メールを、その電子メールメッセージが、例えば、金融機関、オンラインサービスプロバイダなどの評判のよい、さらに／または信頼されるエンティティから送信されていることを装って送信する。その電子メールメッセージは、機密情報で返信するよう（例えば、機密情報が入力されることが可能な詐欺的なウェブサイトへのリンクを介して）受信者を誘う。獲得された場合、犯罪者は、その機密情報を使用して、電子メールメッセージ受信者の対応する１つまたは複数の口座を危うくする。機密情報の例には、銀行口座、投資口座、オンライン支払いサービス口座、オンライン競売口座などにアクセスするために使用される情報が含まれるが、以上には限定されない。この情報を使用して、犯罪者は、通常、対応する口座から資金を盗む、またはそのような口座情報を使用して、受信者のＩＤを使用した他の個人もしくはエンティティに対する金銭的詐欺を容易にする。残念ながら、フィッシングは、大きい、増大している問題であり、フィッシング手法は、週を追うごとに偽装の巧妙さを増している。
【０００４】
電子メールメッセージ送信者の認証に関して、１つの知られているソリューションは、ＳＰＦ（送信者ポリシーフレームワーク）である。ＳＰＦは、電子メールメッセージが、そのドメインから電子メールメッセージを送信することを許されていると指定されているマシンから来たことを確認しようと試みる。残念ながら、ドメインの正当性に関する検査は、存在しない。したがって、誰でも、「ｘ−ｃｏｍｐａｎｙ−ｓｐｅｃｉａｌ−ｏｎ−ＴＶ．ｃｏｍ」のようなドメインを登録して、ｘ−ｃｏｍｐａｎｙから電子メールメッセージを送信していると主張することができる。
【０００５】
デマ電子メールメッセージが、電子メールメッセージの送信者を認証することが有益である別の状況を代表する。例えば、多くのデマ電子メールは、権威あるソースからであると称するが、明らかにそうではない。しかし、電子メールメッセージの受信者が、送信者ＩＤを有効に、実際的に認証する方法は、現在、存在しない。実際の権威あるソースからの否定が、これらのデマ電子メールメッセージをどうにか抑え込むことは稀である。
【０００６】
一般に「スパム」とも呼ばれる、求められていない大量電子メール送付が、広まっている。スパムを規制しようとする試みのすべてにもかかわらず、スパムの出現率は増え続けており、現在、すべての電子メールメッセージの大半を占めると推定されている。したがって、スパムの頻度および量を減らす必要性が、明らかに存在する。さらに、これらの求められていない大量電子メール送付が、これらの電子メールメッセージが正当な、さらに／または信頼されるエンティティからであることを偽って示すヘッダ情報を通常、有することは、驚くにあたらない。ヘッダ情報の認証は、個人が受信するスパムの量を制限するための手段を、フィッシングなどの関連する詐欺的な行為の対象となる可能性を制限することに加えて、もたらす。
【０００７】
詐欺的なウェブページが、しばしば、セットアップされ、電子メールメッセージを介して開始されるフィッシング行為をサポートするのに、しばしば、使用される。これらの詐欺的なウェブサイトは、信頼される機関のウェブサイトであるように見えるが、実際には、犯罪行為を犯す特定の目的でセットアップされる。したがって、ウェブページおよび／またはウェブサイトを管理しているエンティティを検証することに大きな価値がある。
【０００８】
電子メールメッセージおよびウェブページと同様に、ＩＭ（インスタントメッセージング）システムが、犯罪行為または欺く行為が、通常、偽のＩＤの使用を介して実行されるさらに別のネットワークベースの通信アプローチである。ＩＭメッセージの送信者として示されるＩＭスクリーン名の認証が、望ましく、そのＩＭスクリーン名が、或る特定の機関からであると認証されるのが、望ましい。そのような認証なしには、機密情報は、ＩＭを使用する通信を介して、直接に、または間接的に、容易に危険にさらされ得る。
【０００９】
受信者に電子メールメッセージ、ウェブサイト／ウェブページ、および／またはＩＭ（インスタントメッセージング）メッセージを提供することを担ったと称されているエンティティを認証するための完全で、さらに／または有効なソリューションは、現在、存在しない。このため、偽装されたＩＤ情報に基づき、データ通信ネットワークを介して犯されるフィッシング、スパム、および他のタイプの犯罪行為または欺く行為は、なくならず、増え続ける。偽装されたＩＤ情報に基づく、そのような犯罪行為および欺く行為の問題を解決することと関係するが、実際には、これらの問題を完全に解決しない、またはこれらの問題に十分に対処しないソリューション、または部分的ソリューションに、いくつもの要素が存在する。
【００１０】
ウェブページが、対応するＵＲＬ（ユニフォームリソースロケータ）の実際の所有者から来ていることを確認しようと試みる、知られている１つのソリューションは、ＨＴＴＰＳ（すなわち、ＳＳＬ保護を伴うハイパーテキストトランスポートプロトコル）としても知られる、ＳＳＬ／ＴＬＳ（セキュアソケットレイヤ／トランスポートレイヤセキュリティ）プロトコルと組み合わされたＤＮＳ（ドメイン名システム）である。残念ながら、いくつかの要因が重なり合って、そのようなソリューションを不十分にしている。この知られているソリューションを効果的とは言えないものにする１つの要因は、多くの企業が、複数のドメイン名を使用し、これらのドメイン名が、一貫した規則なしに出入りすることである。例えば、ｘ−ｃｏｍｐａｎｙが、「ｘ−ｃｏｍｐａｎｙ」を、重要なすべての最上レベルドメインにおいて登録し（例えば、ｘ−ｃｏｍｐａｎｙ．ｃｏｍ、ｘ−ｃｏｍｐａｎｙ．ｎｅｔ、ｘ−ｃｏｍｐａｎｙ．ｏｒｇなど）、さらに各国ドメインにおいても登録する（例えば、ｘ−ｃｏｍｐａｎｙ．ｃａなど）ことが可能である。しかし、特別プロモーションのため、ｘ−ｃｏｍｐａｎｙは、ｘ−ｃｏｍｐａｎｙ−ＴＶ．ｃｏｍドメイン名を有するが、ｘ−ｃｏｍｐａｎｙ−ＴＶ．ｃａドメイン名は有さないことが可能である。このことは、消費者が、ドメイン名、ｘ−ｃｏｍｐａｎｙＴＶ．ｃｏｍ、ｘ−ｃｏｍｐａｎｙ−ＴＶ−ｓｐｅｃｉａｌ．ｃｏｍなどを示された場合に、容易に混乱し得ることを意味する。この知られているソリューションを効果的とは言えないものにする別の要因は、企業が、派手に宣伝されることもほとんどなく作られた子会社およびその他の法人エンティティを、しばしば、有することである。平均的な消費者が、これらすべてのドメイン名を常に把握していることは困難である。この知られているソリューションを効果的とは言えないものにするさらに別の要因は、同一の名前を正当に有する複数の企業が、しばしば、存在することである。最も頻繁な場合は、２つの企業が異なる管轄区域において営業している場合である。ＤＮＳ所有権モデルは、実質的に先着順であり、紛争解決機構が設置されている。したがって、複数のエンティティのいずれが、「最も自明な」ドメイン名を有するか、あるいは消費者が求める企業が、自明でないドメイン名を使用していることを消費者が知ることは、実質的に不可能である。この知られているソリューションを効果的とは言えないものにするさらに別の要因は、多くの数字および／またはテキスト文字が似ていることである。偽装されたＩＤ情報に関して、欺く目的で数字およびテキスト文字を使用するための１つの古典的なアプローチは、大文字の「Ｏ」に数字「０」を代用すること、または小文字の「Ｌ」に数字「１」を代用することである。最近では、キリル文字またはユニコード文字を使用するはるかに巧妙な策略が、存在する。以上のことは、犯罪者が、本物のドメイン名と視覚的に実質的に見分けのつかない偽のドメイン名を有することを可能にする。ブラックリスト、ならびにヒューリスティクスを使用して、これらの偽のドメイン名を識別しようと試みる類のソフトウェアが種々、存在する。しかし、このソフトウェアは、ネットワークオーバヘッド、ならびに不正なドメインをブラックリストに追加するのに時間がかかるという問題を抱えている。この知られているソリューションを効果的とは言えないものにするさらに別の要因は、スパム電子メールが、巨大な問題に成長していることである。ほとんどのフィルタリングの取り組みは、電子メールメッセージコンテンツを調べて、例えば、処方薬のオンライン購入などの現在、流布しているスパムトピックを識別するというアプローチをとってきた。最先端のスパムは、現在、イメージ、ならびにスペルミスを使用して、これらのフィルタを通り抜ける。
【００１１】
最近、「ＥＶ証明書」（拡張された検証証明書）と呼ばれる認証方法が、導入されている。その名前が暗示するとおり、この認証方法は、標準の（すなわち、非ＥＶの）ＳＳＬ／ＴＬＳ証明書と同一の基礎を有するが、追加の検証を伴う。標準の（すなわち、非ＥＶの）ＳＳＬ／ＴＬＳ証明書に関連して前段で説明される問題のほとんどが、やはり、当てはまる。ＥＶ証明書は、詐欺的な行為（例えば、フィッシング）の犯人を、そのような詐欺的な行為が実行された後に、見つけ出すのに役立つに過ぎず、そのような詐欺的な行為を防止するのではないものと考えられている。明らかに、犯人は、しばしば、オンライン詐欺取締り予算、または詐欺的な、もしくは悪意のあるオンライン行為を取り締まることへの関心がほとんど、またはまったくない環境における見せかけのエンティティである。したがって、ＥＶ証明書は、いくつかの仕方で役立つものの、フィッシングの問題を実際に解決するようには思われない。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
したがって、ネットワークベースの通信アプローチが、電子メールであるか、ウェブページであるか、さらに／またはインスタントメッセージングであるかにかかわらず、偽装されたＩＤ情報、またはそれ以外で不正直なＩＤ情報に基づくネットワーク対応の犯罪行為および欺く行為に対抗するための知られているアプローチに関連する欠点の少なくとも一部分を克服するソリューションは、有用であり、有利であり、さらに革新的である。
【課題を解決するための手段】
【００１３】
本発明の実施形態は、偽装されたＩＤ情報、またはそれ以外で不正直なＩＤ情報に基づくネットワークベースの犯罪行為および欺く行為に対抗するための知られているアプローチに関連する欠点を克服する。より具体的には、本発明の実施形態は、電子メールメッセージの送信者として示されるエンティティ、ウェブページの所有権を有するエンティティ、および／またはＩＭ（インスタントメッセージング）メッセージの送信者として示されるエンティティに対応するＩＤ情報の認証をもたらす。そのような認証を介して、ＩＤ情報の受信者は、受信者が、本当に、表明されたエンティティを相手にしたネットワークベースの通信セッションに携わっていることを、適度に保証されることが可能であり、その結果、詐欺的な行為または悪意のある行為に知らずに参加する可能性が抑えられる。
【００１４】
本発明は、本明細書で「ＲｅａｌＮａｍｅレジストリ」と記述的に呼ばれるレジストリ、および関連する認証証明書（すなわち、ＲｅａｌＮａｍｅ証明書）に依拠する。各ＲｅａｌＮａｍｅレジストリは、識別情報に関する証明機関として機能する。本発明による識別情報の例には、エンティティが認識される名前、エンティティに固有のイメージ、エンティティに固有のテキスト、およびエンティティに固有のサウンドが含まれるが、以上には限定されない。ＤＮＳ（ドメイン名サーバ）および他のツールから「認証」機能を切り離すことによって、ＲｅａｌＮａｍｅレジストリは、電子メールメッセージ、ＩＭメッセージ、ウェブページなどの認証を円滑にすることの複雑さに関連して、有用な機能を達するのに有利に使用されることが可能である。
【００１５】
ドメイン名は、負荷分散、組織追跡、ウェブサイト階層などを含め、多くの機能のために使用される。これらの機能は、識別機能を扱うことを困難にする様々な要件も有する。識別に関して、レジストリが、重複する（およびほぼ重複する）識別情報のすべての問題を解決することが好ましい。明らかに、このことは、世界的な規模で行われることは不可能であり、このため、本発明の実施形態は、好ましくは、管轄権の境界を尊重する仕方で構成される。幸いなことに、この機能のためのモデル、つまり、商標レジストリが存在する。各管轄区域は、独自の商標レジストリを有し、場合により、商標の所有権を解決するための様々な規則、および提案される識別情報（例えば、名前）が既存の商標を侵害するかどうかを判定するための様々な規則を備えている。ＲｅａｌＮａｍｅレジストリは、商標レジストリと同一の仕方で効率的に機能することが本明細書で開示される。実際、ＲｅａｌＮａｍｅレジストリが、商標レジストリよりさらに分散化されていることが有利である。例えば、各管轄区域が、独自のＲｅａｌＮａｍｅレジストリを運用することが可能であり、各職業が、独自のＲｅａｌＮａｍｅレジストリを運用することが可能であり、各業界団体が、独自のＲｅａｌＮａｍｅレジストリを運用することが可能であるといった具合である。情報受信者（例えば、電子メールの受信者、ＩＭメッセージの受信者、ウェブページの受信者など）は、受信者がいずれのレジストリをインポートする気があるかを選択することができる。最低でも、情報受信者は、地元の管轄区域、および情報受信者が相手にする職業に関するＲｅａｌＮａｍｅレジストリを、通常、インポートする。このＲｅａｌＮａｍｅレジストリ構成により、ＤＮＳシステムを悩ます多くの法的争い、詐欺的な（しかし、視覚的に同一の）ドメイン名、ドメイン名所有権に関する明確な規則（例えば、ｘ−ｃｏｍｐａｎｙ Ｉｎｃ．は、ｘ−ｃｏｍｐａｎｙ ｒｏｃｋｓ．ｃｏｍサイトを所有するか）などを含め、多くの問題が回避される。
【００１６】
レジストリが整えられて、電子メールメッセージ、ＩＭメッセージ、ウェブページなどの認証が、進められることが可能である。各レジストリは、「承認された名前の証明書」の発行者として機能するとともに、「承認された」識別情報（すなわち、一般に、ＲｅａｌＮａｍｅと呼ばれる）のデータベースとしても機能する。証明書（すなわち、認証証明書）は、多くの仕方で達せられることが可能であるが、最も簡単なのは、既存のＤＮＳ／ＳＳＬのために使用されるＸ．５０９認証証明書である。Ｘ．５０９は、標準化されたＰＫＩ（公開鍵インフラストラクチャ）である。Ｘ．５０９用語において、各レジストリは、「証明機関」として機能し、各認証証明書は、実質的に、ＲｅａｌＮａｍｅおよび公開鍵を埋め込むパッケージである。次に、このパッケージに、証明機関の秘密鍵によって署名が行われる。運用の際、認証証明書は、エンティティのＩＤを強調するために役立つ実質的に任意のタイプの識別情報を含むように構成される。
【００１７】
本発明の一実施形態において、ウェブページを検証するための方法が、複数の動作を含む。複数の情報プロバイダの各プロバイダに発行された認証証明書と、これらの認証証明書のすべてに対応するルート証明書とを含む証明書レジストリを作成するための動作が、提供される。これらの認証証明書の各証明書は、その証明書のそれぞれの認証情報を、情報プロバイダの対応するプロバイダの識別情報に結び付ける。認証証明書の各証明書は、情報プロバイダの対応するプロバイダと、そのプロバイダのドメイン名情報との間のリンクを欠いている。証明書レジストリの認証証明書は、情報プロバイダが提供する情報の特定のタイプ、情報プロバイダが関連する特定の組織、情報プロバイダが携わっている特定のタイプの職業、および情報プロバイダが位置する特定の地理的区域のうち少なくとも１つに少なくとも或る程度、依存する仕方で関連する。情報受信者にルート証明書を提供するための動作が、提供される。情報受信者によってアクセスされ、さらに認証証明書が関連付けられているウェブページの検証を円滑にするための動作が、提供される。この検証は、ルート証明書の中に含まれる認証情報を使用して、関連付けられた認証証明書の真正性を検証することに成功して、関連付けられた認証証明書が、証明書レジストリに属することを検証すること、および関連付けられた認証証明書の真正性を検証することに成功した後、関連付けられた認証証明書の中に含まれる認証情報を使用して、ウェブページの指定された所有者のＩＤを検証することに成功することを含む。
【００１８】
本発明の別の実施形態において、証明書レジストリが、複数の情報プロバイダの各プロバイダに発行された認証証明書と、これらの認証証明書のすべてに対応するルート証明書とを含む。これらの認証証明書の各証明書は、その証明書のそれぞれの認証情報を、情報プロバイダの対応するプロバイダの識別情報に結び付ける。認証証明書の各証明書は、情報プロバイダの対応するプロバイダと、そのプロバイダのドメイン名情報との間のリンクを欠いている。証明書レジストリの認証証明書は、情報プロバイダが提供する情報の特定のタイプ、情報プロバイダが関連する特定の組織、情報プロバイダが携わっている特定のタイプの職業、および情報プロバイダが位置する特定の地理的区域のうち少なくとも１つに少なくとも或る程度、依存する仕方で関連する。
【００１９】
本発明の別の実施形態において、証明書レジストリシステムが、複数の情報プロバイダの各プロバイダに発行される認証証明書を発行し、さらにこれらの認証証明書のすべてに対応するルート証明書を保持するように構成される。これらの認証証明書の各証明書は、その証明書のそれぞれの認証情報を、情報プロバイダの対応するプロバイダの識別情報に結び付ける。認証証明書の各証明書は、情報プロバイダの対応するプロバイダと、そのプロバイダのドメイン名情報との間のリンクを欠いている。証明書レジストリの認証証明書は、情報プロバイダが提供する情報の特定のタイプ、情報プロバイダが関連する特定の組織、情報プロバイダが携わっている特定のタイプの職業、および情報プロバイダが位置する特定の地理的区域のうち少なくとも１つに少なくとも或る程度、依存する仕方で関連する。
【００２０】
本発明のこれら、およびその他の目的、実施形態、利点、および／または特徴は、以下の詳述、関連する図面、および添付の特許請求の範囲をさらに精査することで、直ちに明白となろう。
【図面の簡単な説明】
【００２１】
【図１】本発明による情報プロバイダ登録のための登録インフラストラクチャおよび登録プロセスを示す概略図である。
【図２】本発明による識別情報認証アプリケーションを実行するユーザデバイスによって実行される情報識別認証インフラストラクチャおよび情報識別認証プロセスを示す概略図である。
【図３ａ】本発明による識別情報認証メッセージを表示する情報受信者デバイスを示す概略図である。
【図３ｂ】本発明による識別情報認証メッセージを表示する情報受信者デバイスを示す概略図である。
【図３ｃ】本発明による識別情報認証メッセージを表示する情報受信者デバイスを示す概略図である。
【図４ａ】情報受信者デバイスに発信者認証表示を伝える方法を示す概略図である。
【図４ｂ】情報受信者デバイスに発信者認証表示を伝える方法を示す概略図である。
【図４ｃ】情報受信者デバイスに発信者認証表示を伝える方法を示す概略図である。
【図４ｄ】情報受信者デバイスに発信者認証表示を伝える方法を示す概略図である。
【図５】本発明による電子メールメッセージ認証方法の実施形態を示す流れ図である。
【図６】本発明によるＨＴＴＰページ（例えば、ウェブページ）認証方法の実施形態を示す流れ図である。
【図７】本発明によるＩＭメッセージ認証方法の実施形態を示す流れ図である。
【発明を実施するための形態】
【００２２】
本発明は、関係者が、本発明に従ってプログラミングされたデータ通信機器へのアクセスを有する誰にでも認証された識別情報を提供することを許す。識別情報の例には、エンティティが認識される名前、エンティティに固有のイメージ、エンティティに固有のテキスト、およびエンティティに固有のサウンドが含まれるが、以上には限定されない。より具体的には、識別情報の例には、エンティティの保護された名前、エンティティの保護されたイメージ、エンティティの保護されたテキスト、およびエンティティの保護されたサウンドが含まれるが、以上には限定されない。「保護された」とは、本明細書では、例えば、商標、著作権、および識別情報の他の登録形態などの管理機関手段によって、さらに／またはブランド付き識別情報（例えば、商標）を作成することによって与えられる保護を含むものと定義される。データ通信機器とは、遠隔通信ネットワークおよび／またはコンピュータネットワークを介してデータを通信するように構成されたコンピュータ機器および／または電話機器を指す。そのようなデータ通信機器の例には、電子メールメッセージを介して通信するように構成されたコンピュータ、インスタントメッセージングを介して通信するように構成されたコンピュータ、インスタントメッセージングを介して通信するように構成された電話機、ウェブページにアクセスするように構成されたコンピュータ、電子メールメッセージを送信するように構成された電話機、およびウェブページにアクセスするように構成された電話機が含まれるが、以上には限定されない。
【００２３】
本発明に従ってプログラミングされたデータ通信機器は、１つまたは複数の識別情報レジストリ（すなわち、１つまたは複数のＲｅａｌＮａｍｅレジストリ）と、１つまたは複数の情報プロバイダ認証アプリケーションとを含む。各識別情報レジストリは、情報受信者に情報プロバイダの認証を提供することを所望する情報プロバイダに関連する一意識別情報（例えば、名前、テキスト、イメージ、サウンドなど）を格納するように構成される。情報プロバイダとは、情報を受信する、さらに／または情報にアクセスするのに情報受信者が通信する相手のエンティティを指す。情報プロバイダの例には、電子メールメッセージの送信者、ＩＭメッセージの送信者、ウェブページ所有者などが含まれるが、以上には限定されない。各情報プロバイダ認証アプリケーションは、関係者によって開始されたデータ通信に関連する認証証明書を受信し、この認証証明書を使用して、その関係者の識別情報の認証を円滑にする。識別情報が認証されることに成功したか否かを示す通知が、情報受信者に伝えられる。
【００２４】
図１は、本発明による識別情報の登録のための例示的な登録インフラストラクチャおよびプロセスの概略図である。この例では、登録者１１０が、以下の３つの別々のレジストリに登録する。すなわち、レジストリ１０１が、ネットワークサービスプロバイダ１００であるＲＡ（登録機関）によって運用され、レジストリ２０１が、関係グループ（業界団体などの）であるＲＡによって運用され、さらにレジストリ３０１が、地理的区域または行政的区域（場合により、政府または他の公的エンティティ）であるＲＡによって運用される。登録者１１０は、利用可能なレジストリのいずれか１つに加入する情報受信者に認証された識別情報を提供するような方法で登録する。つまり、登録者１１０は、情報受信者が、利用可能なレジストリの１つまたは複数に、この例では、レジストリ１０１、２０１、または３０１に加入している場合に限って、情報受信者に対して認証されることが可能である。
【００２５】
各レジストリは、それぞれのＲＡによって運用される。レジストリを運用することは、本明細書では、レジストリの中に含まれる情報を保持することを含むように定義される。ＲＡは、識別情報レジストリを提供することに関心がある任意の公的組織または私的組織であることが可能である。ＲＡは、運用するのにいずれの当局からの承認も要さないが、これらの当局による公認を求めることも可能である。エンドユーザ、サービス供給業者、および／または機器供給業者は、信頼できる所与のレジストリが存在するかどうかを判定して、信頼できると判定されたレジストリだけに加入することが可能である。各レジストリは、２つの主要な部分、すなわち、ＲＡ（Ｘ．５０９用語において証明機関）、および識別情報のデータベースから成る。各レジストリは、所定の加入者グループ、地域、および／または事前定義された関係グループにサービスを提供する。１つのレジストリによってサービスを提供される地域が、別のレジストリによってサービスを提供される地域と重なり合うことも可能であり、さらに２つ以上のレジストリが、同一の地域にサービスを提供することも可能である。同様に、異なる２つ以上の定義された関係グループが、重なり合うことが可能である（例えば、医者と、より狭く定義された、小児科医の関係グループ）。
【００２６】
レジストリ１０１は、任意の企業、公的組織または政府組織に、認証された情報プロバイダサービスを提供することを所望するネットワークサービスプロバイダ１００によって、またはネットワークサービスプロバイダ１００によってサービスを提供される情報受信者に、認証された識別情報を提供することを所望する他の登録者１１０によって保持される。レジストリ２０１は、例えば、Ｃａｎａｄｉａｎ Ｂａｎｋｅｒｓ Ａｓｓｏｃｉａｔｉｏｎ（Ｒ）などの関係グループ２００によって運用され、この関係グループは、レジストリ２０１を保持して、このグループの銀行メンバに、認証された識別情報および／または関連するサービスを提供する。レジストリ３０１は、例えば、ニューヨーク州、オンタリオ州、トロント市、シカゴ市とその周辺などの地理的区域または行政的区域に関連付けられ、対応する政府機関または他の公的エンティティ３００によって保持される。
【００２７】
一実施形態において、ＲＡ１００、２００、または３００が負う唯一の責任は、任意の登録者１１０のＩＤの証明を確実にするとともに、ＲＡ１００、２００、または３００が、異なる登録者１１０に関して重複する識別情報を登録しないことを確実にすることだけである。この実施形態において、レジストリ１０１（データベースおよびＲＡから成る）は、一般の人々によって自由に検査されることが可能であり、紛らわしく類似した、または誤解を招く情報プロバイダＩＤが、別の登録者１１０によって登録されないことを確実にするために、レジストリ１０１、２０１、および３０１を監視することは、少なくとも或る程度、登録者１１０、および他の関係者の責任である。登録者１１０が、登録されると、ＲＡは、認証証明書１０４を発行する。この認証証明書は、登録された情報プロバイダＩＤ（すなわち、識別情報）が、登録者の公開鍵に結合されていることを認定し、そしてこの公開鍵は、登録者の秘密鍵と暗黙に対にされている。
【００２８】
登録プロセス
レジストリによって各登録者１１０に提供される認証証明書１０４は、知られている任意の認証システムに適合することが可能であり、さらに各レジストリは、本発明の範囲を逸脱することなしに、異なる認証システムを使用することができる。登録者のＩＤ情報が、レジストリの中に記録されると、情報プロバイダ認証が実行されることを許す認証証明書が、登録者１１０に提供される。この認証証明書は、Ｘ．５０９のような任意の公開鍵インフラストラクチャスキームに基づくことが可能である。
【００２９】
Ｘ．５０９が、登録者１１０に提供される認証証明書のために使用される場合、本発明の一実施形態では、登録プロセスは、以下のとおり、進む（すなわち、例としてＲＡ１００を使用して）。
【００３０】
１）ＲＡ１００が、ＲＡ１００のルート証明書の中でＲＡ１００の公開鍵を公開する。ルート証明書は、レジストリ（すなわち、証明）機関の公開鍵を有する証明書である。この公開鍵は、認証証明書を検証するのに使用され、したがって、ルート証明書は、情報プロバイダ認証を実行する各デバイスの中にインポートされなければならない。通常、データ通信機器のベンダまたは所有者は、ウェブブラウザに、現在、ＰＫＩルート証明書が事前ロードされるのと同じように、地元地域のレジストリ、すべての一般的な業界レジストリおよび職業レジストリなどを含む、関心対象のルート証明書を事前ロードするものと想定される。オプションとして、エンドユーザが、複数の地域においてビジネスを行う、または特化されたレジストリに感心がある場合において、エンドユーザが、さらなるルート証明書をインポートすることを許す方法が、存在する。当業者には理解されるとおり、いくつのルート公開鍵が、インポートされることが可能であるか、またはそのようなインポートを許すための手段に制限は、まったく存在しない。
【００３１】
２）登録者１１０になることを所望する各関係者（すなわち、レジストリ申請者）が、その関係者独自の公開鍵／秘密鍵ペアを生成し、その公開鍵を、その関係者の識別情報および他の要求される登録情報および／または登録ドキュメンテーションと一緒に、ＲＡ１００にサブミットする。
【００３２】
３）ＲＡ１００が、関係者が、その識別情報を実際に所有している、またはそれ以外で合法的に保有していると判定した場合、ＲＡ１００は、その識別情報をデータベース１００に入力し、ＲＡ１００の秘密鍵を使用して、登録者の識別情報と、登録者の公開鍵とを含む認証証明書に署名する。したがって、ＲＡ１００は、登録者の公開鍵が、登録者の識別情報に結合された公開鍵に「他ならない」こと、およびその登録者が、その識別情報を使用する資格があることを「請け合う」。
【００３３】
４）登録者１１０は、この時点で、登録者１１０の識別情報を証明する署名された認証証明書を有し、さらに登録者１１０は、登録者１１０が、その認証証明書を検証することを許す秘密鍵も有する。認証証明書の意味は、限られていることを理解されたい。認証証明書は、秘密鍵の保持者（登録者１１０であるべき）が、登録者１１０が登録した特定の登録機関１００の管轄区域内で、この保持者の識別情報を表示させる資格があることを意味するに過ぎない。
【００３４】
情報プロバイダ認証
図２は、本発明による情報プロバイダ認証構成の実施形態を示す。情報受信者ユーザデバイス（すなわち、デバイス１２０ａ）が、情報プロバイダ認証を実行する。デバイス１２０ａの例には、電子メールメッセージを介して通信するため、インスタントメッセージングを介して通信するため、および／またはウェブページにアクセスするように構成されたパーソナルコンピュータまたはＩＰ（インターネットプロトコル）電話機などのデバイスが含まれるが、以上には限定されない。デバイス１２０ａは、本発明による非常にセキュリティの強い形態の情報プロバイダ認証を可能にする情報プロバイダ認証アプリケーション１２２を備える。このセキュリティは、情報受信者が、認証アプリケーション１２２を直接に制御／監督していること、つまり、情報受信者が、情報受信者自らのデバイスを信頼するだけでよいことに由来する。他の実施形態では、サービス（ウェブ／電子メール／ＩＭ）に依存して、プロキシにおいて認証を実行することが可能である。しかし、そのような構成は、多くの攻撃の道を開き、セキュリティを強くすることをはるかに困難にする。したがって、情報プロバイダ認証アプリケーション１２２を備えたデバイス１２０ａが、「エンドツーエンド」方式で実施されるべき識別情報認証を有利に提供することを見て取ることができる。
【００３５】
やはり図２を参照して、登録者１１０が、デバイス１２０ａによって受信されるように、提供される情報の伝送を開始すると、そのような情報伝送（１ａ）は、当技術分野でよく知られた仕方でデータ通信ネットワークを介して進められる。そのような情報伝送の例には、電子メールメッセージを伝送すること、ＩＭメッセージを伝送すること、ウェブサイトコンテンツを伝送すること、ウェブページを伝送すること、およびデータ通信ネットワークまたは遠隔通信ネットワークを介する他の情報伝送形態が含まれるが、以上には限定されない。提供される情報を伝送することと一緒に、登録者デバイス１１０に、デバイス１２０ａによって受信されるようにデバイス１１０の認証証明書を送信させるための情報プロバイダ認証対話（２ａ）が、開始される。情報がウェブページである場合において、この対話は、デバイス間のダイアログである。電子メールまたはＩＭメッセージの場合において、この対話は、情報の伝送を含むが、電子メールシステムまたはＩＭシステムにおける片方、または両方の終端デバイスが、オフラインである可能性があるので、２つのデバイス間のダイアログではない可能性がある。提供される情報、および認証証明書は、データネットワークまたは通信ネットワークを介してデータを通信するために適切に構成された、知られている通信プロトコルの同一のプロトコル、または異なるプロトコルを使用して伝送されることが可能である。認証証明書を受信することに応答して、情報プロバイダ認証アプリケーション１２２は、登録者デバイス１１０を相手に認証対話を行い、この認証対話中に獲得された認証証明書の真正性を検証する。情報プロバイダ認証は、レジストリ１０１、２０１、３０１のクエリを要求しないことを理解されたい。登録者デバイス１１０は、提供される情報の伝送を円滑にするために使用されるのと同一の機器であることも、異なる機器（例えば、同一のサーバ、または異なるサーバ）であることも可能であることが、本明細書で開示される。判定されると、次に、認証プロセスの結果は、図３ａから図３ｃ、および図４ａから図４ｄに関連して後段で説明されるとおり、デバイス１２０ａに伝送される（３ａ）。
【００３６】
本発明による認証アプリケーションは、好ましくは、ただし、必然的にではなく、ユーザデバイス上に存在する。このことは、ユーザが、遠隔デバイスではなく、ユーザのデバイスを信頼するだけでよいことを意味する。サービス（例えば、ウェブ、電子メール、ＩＭなど）に依存して、プロキシにおいて認証を実行することが可能である。しかし、このことは、多くの攻撃の道を開き、認証プロセスのセキュリティを強くすることをはるかに困難にする。したがって、本明細書で開示される認証の「エンドツーエンド」アプローチは、有利である。
【００３７】
図３ａから図３ｃは、本発明の一実施形態による、情報受信者に伝えられる情報プロバイダ認証メッセージの例を示す。これらの例において、表示される情報プロバイダ認証メッセージは、識別情報が認証されることに成功したかどうかを示す情報、識別情報（オプションとして、ロゴなど）を示す情報、および情報プロバイダが、レジストリ１０１、２０１、３０１のいずれのレジストリに登録したかを示す情報を含む。
【００３８】
図３ａは、認証されることに成功した識別情報に関する例示的な表示フォーマット１３０ａを示す。表示フォーマット１３０ａの第１の行は、この識別情報が認証されることに成功したことを示す。表示フォーマット１３０は、デバイス１２０のビジュアルディスプレイ１４０上で提供される。示されるとおり、表示フォーマット１３０ａは、ビジュアルディスプレイ１４０の相当な領域を包含する。しかし、他の実施形態（図示せず）では、表示フォーマット１３０ａは、ビジュアルディスプレイ１４０の限られた領域を包含する。表示１３０ａの第２の行は、認証された識別情報を表示する。この表示の最後の行は、この例では、カリフォルニア州に関連するレジストリである、ＲＡの名前を表示する。
【００３９】
図３ｂは、認証が失敗したために認証されることが可能でなかった情報プロバイダに関する例示的な表示フォーマット１３０ｂを示す。当業者には理解されるとおり、情報プロバイダ認証は、いくつかの理由のいずれの理由でも失敗する可能性がある。例えば、情報プロバイダは、情報プロバイダが、対応する秘密鍵を有さない盗まれた認証証明書を提示する可能性がある、認証証明書は、ユーザデバイスに知られていないレジストリからである、認証証明書は、ＣＡの公開鍵を使用して検証されることが可能でない、通信障害が、生じた可能性がある、認証対話が、中断された可能性がある、など。表示１３０ｂの第１の行は、情報プロバイダ認証が失敗したために、情報プロバイダが認証されることに成功しなかったことを示す。表示１３０ｂの第２の行は、認証証明書の中に含まれる識別情報を、利用可能な場合、表示する。表示１３０ｃの最後の行は、認証証明書の中に含まれるレジストリの名前を、利用可能な場合、表示する。認証が失敗したということをさらにハイライトするのに、メッセージは、明るい色で、例えば、赤などで表示されることが可能である。
【００４０】
図３ｃは、情報プロバイダが認証証明書を提示しないために認証されることが可能でなかった情報プロバイダに関する例示的な表示フォーマット１３０ｃを示す。表示１３０ｃの第１の行は、情報プロバイダが、認証を試みていないことを示し、残りの行は、示されるとおり、空白であることが可能であり、あるいは識別情報を表示することが可能であり、その場合、認証が試みられていないということが、認証サービスなしのメッセージをハイライトする、または点滅させることによって強調されなければならない。
【００４１】
当業者には理解されるとおり、表示フォーマット１３０ａ−１３０ｃは、必ずしも実際的、または情報受信者によって所望されるというわけではない。例えば、パーソナルコンピュータの場合において、ビジュアルディスプレイのサイズは、通常、認証結果の視覚的提示に関して制限要因ではない。しかし、セルラー電話機、パーソナルデジタルアシスタント、ハンドヘルドコンピュータなどのハンドヘルドデバイスのビジュアルディスプレイのサイズは、認証結果の視覚的表示における制限要因である可能性がある。したがって、認証プロセス結果を示す他の形態が、そのような結果を伝えるために使用され得ることが、企図される。図４ａから図４ｄは、認証プロセス結果を、そのような結果を情報受信者に伝えるために示す代替の形態を示す。図４ａから図４ｄに示される例は、或る特定のタイプのデバイス１４０（すなわち、セルラー電話機）を示すものの、認証プロセス結果を示す他のそのような形態が、ほとんどの知られているタイプのデータ通信デバイスに伝えられることが可能であることを理解されたい。
【００４２】
図４ａに示されるとおり、一実施形態では、情報プロバイダ認証または認証失敗は、メッセージ受信通知信号が、デバイス１４０ａから出力されるのと同時に、または出力された後に、出力される帯域外メッセージを使用して、情報受信者デバイスを介して伝えられることが可能である。一実施形態では、ビジュアルメッセージが、デバイス１４０ａのビジュアルディスプレイ１４２ａ上で出力される。別の実施形態では、ＳＭＳ（ショートメッセージサービス）メッセージが、認証プロセスを実行するサーバからデバイス１４０ａに送信され、そのＳＭＳメッセージは、ビジュアルディスプレイ１４２ａ上で視覚的に表示される。表示されるビジュアルメッセージは、図４ａに示される、情報プロバイダが認証されている（Ａ）、または図示されない、認証されていない（ＮＡ）という指示１５０、および情報プロバイダＩＤ（例えば、「カリフォルニア州の銀行」）を含む。
【００４３】
図４ｂに示されるとおり、別の実施形態では、情報受信者が、対応する提供される情報にアクセスすると、帯域内の可聴メッセージが、デバイス１４０ｂの可聴出力手段を介して出力されることが可能である。この可聴メッセージは、情報プロバイダが、認証されることに成功したか否かを示す。この可聴メッセージは、情報受信者が、そのようなアクセスを実行した後に、ただし、提供される情報が提示される前に出力されることが可能であり、したがって、情報プロバイダは、この可聴メッセージを偽造することができない。この実施形態では、情報受信者は、情報プロバイダが、認証されることが可能であったか、可能でなかったかを示す可聴メッセージ１５２を受け取る。
【００４４】
図４ｃに示されるとおり、別の実施形態では、特有の呼び出し音が、デバイス１４０ｃの可聴出力手段によって出力される。１つの呼び出し音１５４は、認証された情報プロバイダを示し、別の呼び出し音（図示せず）は、識別情報が認証されることが可能でなかったことを示す。
【００４５】
図４ｄに示されるとおり、さらに別の実施形態では、識別情報が認証されたかどうかを示すイメージ１５６（例えば、．ｊｐｅｇイメージ）が、デバイス１４０ｄに送信される。この実施形態では、イメージ１５６は、識別情報が認証されることが可能でなかったことを、失敗した認証に対応する詐欺的な／悪意のある行為（例えば、フィッシング）を示すイメージであることによって示す。別のイメージ（図示せず）が、識別情報が認証されることに成功した状況を示すのに使用される。
【００４６】
次に提示されるのは、様々な特定のタイプの通信媒体に適用される、本発明による認証を円滑にすることの開示である。これらの通信媒体の例には、電子メール、ＩＭメッセージ、およびウェブページが含まれるが、以上には限定されない。以下は、電子メール、ＩＭメッセージ、およびウェブページの文脈においてメッセージ認証を個々に円滑にするための特定のアプローチの実施形態である。詐欺的な行為、および悪意のある行為は、しばしば、通信媒体の組合せを介して実行されることが、当業者には認められよう。例えば、フィッシング行為は、しばしば、偽装された、または紛らわしい送信者情報を有する電子メールメッセージを介して「餌を見せ」、さらに信頼できるエンティティのウェブページであると偽って称するウェブページを介して「釣り針を仕掛ける」。釣り針を仕掛けることは、例えば、銀行口座情報などの機密性の高い情報を獲得して、口座からの資金の許可のない引き出しを可能にすることを、しばしば、含む。したがって、本発明による、様々な通信媒体の文脈における、メッセージ認証を円滑にするためのアプローチは、例えば、ＶｏＩＰを介するフィッシング、ビジネス−ビジネス間認証、スパムフィルタリング、電子メール偽造、ウェブページ偽造、ウェブページフィッシング、ＩＭセッションハッキングなどの詐欺的な行為および／または悪意のある行為に対抗する目的で、個々に、または組合せで有利に実施されることが可能であることが、本明細書で開示される。
【００４７】
電子メール認証
ＳＭＴＰ（簡易メール転送プロトコル、ＲＦＣ２８２１）が、現在、圧倒的に支配的な電子メールプロトコルである。したがって、電子メールメッセージ認証は、ＳＭＴＰに関して本明細書で説明される。しかし、電子メールメッセージ認証を円滑にするために特別に構成される本発明の実施形態は、すべてではないにしても、ほとんどの電子メールメッセージングプロトコルに準拠して構成されることが可能であることが、当業者には認められよう。
【００４８】
本発明によれば、電子メールメッセージ認証を円滑にすることは、メッセージ送信者（すなわち、情報プロバイダ）が、認証証明書を使用して電子メールに署名しなければならないことを含む。より厳密には、メッセージ送信者は、認証証明書の中に埋め込まれた公開鍵に対応する秘密鍵を使用して、電子メールメッセージに署名する。電子メールメッセージが、秘密鍵を使用して署名されていることに鑑みて、この署名された電子メールメッセージの受信者は、公開鍵を使用して、この電子メールメッセージの中に含まれる識別情報を認証することができる。
【００４９】
ＳＭＴＰは、ＳＭＴＰを使用して伝送されるメッセージ内に含まれるコンテンツの認証を、円滑にするのを困難にする多くの独特の機能上の考慮点を有する。１つのそのような考慮点は、電子メールが、蓄積交換システムであることである。電子メールメッセージの送信者と受信者の間に最低で２つのＭＴＡ（メール転送エージェント）が、存在し、各ＭＴＡは、異なるプログラムの異なるバージョンを実行している。ＭＴＡは、基本的に、ｓｅｎｄｍａｉｌアプリケーションまたはｐｏｓｔｆｉｘアプリケーションを実行しているメールサーバである。電子メールメッセージの送信者と受信者の間に６つ以上のＭＴＡがそこに存在することも珍しくない。ＳＭＴＰは、各ホップ上のＭＴＡのペア間の対話だけしか許さない。送信者と受信者は、同時にオンラインであることが決してない可能性もあり、このことは、エンドツーエンド認証の選好が存在する場合、対話を完全に不可能にする。
【００５０】
例えば、ＳＭＴＰなどの電子メールメッセージングプロトコルに準拠する各電子メールは、いくつかの「ヘッダ」行を有する。ＳＭＴＰ，ＭＩＭＥなどに関する標準の中で指定された多くのヘッダが、存在する。また、誰でも任意の理由で加えることができる拡張ヘッダも存在する。例えば、Ｘ−Ｓｃａｎｎｅｄ−Ｂｙが、悪意のあるソフトウェアスキャナによって加えられる一般的なヘッダであり、Ｘ−Ｍａｉｌｅｒが、いずれのソフトウェアが送信元ＭＵＡであったかを示す別のヘッダである。そのようなヘッダの存在は、そのようなヘッダを含む電子メールメッセージがクリーンであることは保証しないことが、当業者には認められよう。例えば、ヘッダは、悪意のある目的で或るエンティティによって、または旧バージョンのスキャナを有するエンティティによって追加されていることも可能である。我々は、追加の２つのヘッダ、Ｘ−ＲｅａｌＮａｍｅ−ＣｅｒｔｉｆｉｃａｔｅおよびＸ−ＲｅａｌＮａｍｅ−Ｃｈｅｃｋｓｕｍが、それぞれ、証明書、および署名されたチェックサムを含むことを提案している。また、これらのヘッダを組み合わせて単一のヘッダにすることも可能である。
【００５１】
各ＭＴＡは、新たなヘッダ行を挿入し、さらにいくつかのヘッダ行を書き換えることになっている。このことは、チェックサムが、最初に送信されたとおり、単純に電子メールにわたるだけではあり得ないことを意味する。さらに悪いことには、電子メールメッセージ本文が、いくつかの理由で変更される可能性がある。そのような変更の一例は、行の先頭における「Ｆｒｏｍ」を「＞Ｆｒｏｍ」に変えることである。別の例は、一部のＭＴＡ、および一部のＭＵＡ（例えば、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ（ＴＭ）のようなユーザプログラムに不可欠なメールユーザエージェント）が、行の長さ、およびその他の理由でメッセージを不適切に分割することである。
【００５２】
ＭＩＭＥ（多目的インターネットメール拡張）は、とりわけ、「並行」ビューおよび／または「代替」ビューを含むことが可能なマルチパートメッセージを定義するＳＭＴＰの拡張である。ＭＵＡは、メッセージのいずれの部分を表示するかに関する様々な規則を有する。一部のスパム電子メールメッセージは、意図的に、複数の部分、すなわち、ＡＳＣＩＩにおける１つの部分、およびＨＴＭＬにおける１つの部分を有する本文を有して送信される。その意図は、スパムフィルタが、ＡＳＣＩＩ部分に基づいてフィルタリングを行い、電子メールプログラム（すなわち、ＭＵＡ）が、ＨＴＭＬ部分を表示することである。
【００５３】
したがって、電子メールメッセージ認証を円滑にするように構成された本発明の実施形態は、例えば、反射攻撃や中間者攻撃などの偽造戦術に耐性のあるロバストな電子メールメッセージ認証を依然として実行しながら、これらの独特の機能上の考慮点に対処しなければならない。この目的で、本発明の一実施形態では、図５に示される電子メールメッセージ認証方法２００が、電子メール対応の情報プロバイダデバイスと電子メール対応の情報受信者デバイスによって共同で実施される。
【００５４】
１．図５を参照すると、チェックサム動作２０２が、マルチパート電子メールメッセージ（すなわち、元の電子メールメッセージ）の各部分に対して実行される。このチェックサム動作は、電子メールメッセージコンテンツのすべてまたは一部分に依存するチェックサム（すなわち、計算された値）をもたらす。このチェックサム動作は、好ましくは、例えば、ＳＨＡ−１（セキュアハッシュアルゴリズム１）などの暗号の強固なハッシュを適用することを含む。非テキストであるメッセージの部分は、これらの非テキスト部分に対して、符号化された形態においてチェックサム動作が実行されることを許す適切な仕方で符号化される。
【００５５】
単一パート電子メールの本文、および「テキスト」である部分（ＨＴＭＬおよびその他を含む）を含め、元の電子メールメッセージのテキスト部分のチェックサムを行うのに、好ましくは、実行されるいくらかの処理が、存在する。この処理は、本明細書で「正規化」と呼ばれる。正規化の目的は、メールプログラムによって行われるすべての変更の下で変化しないが、それでも、メッセージの中に見えるすべてのテキストを見られるとおりに保持するメッセージ本文部分を生成することである。そのようなメールプログラムは、例えば、電子メールメッセージを作成するため、送信するため、および受信するために使用されるＭｉｃｒｏｓｏｆｔ（ＴＭ）Ｏｕｔｌｏｏｋ（ＴＭ）などのアプリケーションである。正規化は、さらなる処理を必然的に伴うが、認証アプリケーションの論理を有利に単純化することができる。
【００５６】
一実施形態では、正規化は、好ましくは、空白、タブ、バックスペース、行末文字などのすべての白のスペースを除去することを含む。異なるオペレーティングシステムは、異なる行末規則を有し、したがって、我々は、すべての＜ｃｒ＞および＜ｌｉｎｅｆｅｅｄ＞を白のスペースとして扱うことに留意されたい。行の先頭に「＞」文字があれば、やはり除去される。別のアプローチは、白のスペースのそれぞれの隣接するシーケンスを圧縮して、単一の空白にし、最小限の費用で人間による可読性を向上させることである。さらに、電子メールメッセージ本文がＡＳＣＩＩになっていることは必須ではない。他の文字符号化（例えば、ＥＢＣＤＩＣ）における電子メール、または任意のバイナリファイルさえ、これらがＡＳＣＩＩになっているかのように、正規化されることが可能である。代替として、元の電子メールメッセージ（例えば、イメージ部分）の符号化された部分が、必要に応じて、適宜、正規化を受けることも可能である。
【００５７】
２．元の電子メールメッセージから指定されたヘッダ情報を抽出するためのヘッダ抽出動作２０４が、実行される。そのような抽出されるヘッダ情報の例には、「ｆｒｏｍ：」アドレスおよび「ｒｅｐｌｙ−ｔｏ：」アドレス、「ｍｅｓｓａｇｅ−ＩＤ：」が含まれるが、以上には限定されない。電子メールメッセージが、そのような抽出されたヘッダ情報のすべてのカテゴリを有さない場合において、単一の空白、または他の適切な表現が、欠落しているカテゴリを表すために使用されることが可能であることに留意されたい。「Ｄａｔｅ：」ヘッダの中で指定される日付が、抽出されるべき指定されたヘッダ情報の別の例である。この日付は、いずれの時間帯にあることも可能であるため、例えば、ＵＣＴまたは現地時間などの規定された時間帯にこの日付を標準化することが有用である。
【００５８】
３．元の電子メールメッセージの様々な部分に対して必要なチェックサム（正規化を伴っても、伴わなくても）および抽出が実行された後、すべてのチェックサムおよびヘッダ（すなわち、チェックサムコレクション）を単一の構造に組み立てるための動作２０６が、実行される。この単一の構造は、本明細書で、組み立てられたチェックサムコレクション構造と定義される。組み立てられたチェックサムコレクション構造の一実施形態は、以下のフォーマット、すなわち、「ｆｒｏｍ：＜ｔｈｅｆｒｏｍａｄｄｒｅｓｓ＞、ｒｅｐｌｙ−ｔｏ：＜ｔｈｅｒｅｐｌｙａｄｄｒｅｓｓ＞、ｄａｔｅ：＜ｄａｔｅ＞、ｂｏｄｙ：＜ｂｏｄｙｃｈｅｃｋｓｕｍ＞、ｐａｒｔ １：＜ｐａｒｔ１ｃｈｅｃｋｓｕｍ＞など」を有するコンテンツフィールド文字列である。ＭＩＭＥマルチパート処理に関して、部分の命名および順序付けは、いくつかの部分が、複数の名前（「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：」における名前、「Ｃｏｎｔｅｎｔ−Ｄｉｓｌｏｓｉｔｉｏｎ：」における名前）を有し、他の部分が、まったく名前を有さない可能性があるため、扱いが難しくなる可能性があることに留意されたい。オプションとして、メッセージｉｄは、この構造の中に含められることも可能である。このようにして、マルチパート電子メールメッセージの通常に目に見える部分のすべて、ならびに日付および送信者アドレスが、チェックサムコレクションの中に（直接に、またはチェックサムを介して間接的に）含められる。このことは、署名が、他の本文のために再使用されることが不可能であることを意味し、実際、反射攻撃を防止する。
【００５９】
４．組み立てられたチェックサムコレクション構造を作成することに応答して、組み立てられたチェックサムコレクション構造に関するチェックサムを算出して、第２のレベルのチェックサム構造（すなわち、チェックサムコレクション構造のチェックサム）を生成するための動作２０８が、実行される。
【００６０】
５．第２のレベルのチェックサム構造を算出した後、情報プロバイダの認証証明書に対応する秘密鍵を使用して第２のレベルのチェックサム構造に署名して、署名されたチェックサムを生成するための動作２１０が、実行される。この第２のレベルのチェックサム構造は、帯域幅を最小限に抑える最適化を可能にする。チェックサムコレクションは、場合により、例えば、約数百バイトである。第２のチェックサム構造は、例えば、約２０バイトである。第２のレベルのチェックサム構造を送信することにより、チェックサムコレクションが、伝送される必要はなく、帯域幅利用率が低減される。ＲＳＡ公開鍵署名は、開始するのが比較的遅く、メッセージが長いほど、この署名も遅い。チェックサムコレクションは、チェックサムを計算して、チェックサムだけに署名する方が速いほど十分に長い。
【００６１】
６．署名された第２のレベルのチェックサム構造を生成した後、元の電子メールメッセージの新たなヘッダの中に、署名された第２のレベルのチェックサム構造、および対応する認証証明書を挿入して、署名された電子メールメッセージ（すなわち、本発明による認証証明書によって署名されたメッセージ）を作成するための動作２１２が、実行される。電子メールの元の部分は、変更されず、署名されたチェックサムおよび認証証明書は、認証の目的で追加のヘッダ行として挿入される。受信者が認証したいと思わない場合、受信者デバイスは、これらの追加のヘッダを単に無視する。
【００６２】
７．情報受信者デバイスによって受信されるように情報プロバイダデバイスから、署名された電子メールメッセージを伝送するための動作２１４が、実行され、さらに、これに相応して、その署名された電子メールメッセージを受信するための動作２１６が、情報受信者デバイスによって実行される。
【００６３】
８．受信者が、署名された電子メールメッセージを受信した受信機において、認証証明書、および署名された第２のレベルのチェックサム構造にアクセスする（例えば、これらを抽出する）ための動作２１８が、実行される。
【００６４】
９．認証証明書にアクセスすることに応答して、認証証明書の有効性を検証するための動作２２０が、実行される。好ましくは、そのような有効性は、Ｘ．５０９ ＰＫＩに従って検査される。より具体的には、そのような検証することは、受信者が、レジストリのルート証明書を有することを確認すること、認証証明書が、レジストリによって適切に署名されていることを確認すること、有効期間を調べて、その証明書が失効していないことを確かめること、および取り消しリストを調べて、その証明書が取り消されていないことを確かめることを含む。
【００６５】
１０．証明書が検証された後、署名された第２のレベルのチェックサム構造が、認証証明書に対応する秘密鍵によって正しく署名されていることを検証するための動作２２１が、実行される。
【００６６】
１１．認証証明書の有効性、および第２のレベルのチェックサム構造の署名を検証することに成功することに関連して（例えば、応答して）、電子メールメッセージから、組み立てられたチェックサムコレクション構造を再現するための動作２２２が、実行される。
【００６７】
１２．組み立てられたチェックサムコレクション構造を再現した後、この再現された、組み立てられたチェックサムコレクション構造から第２のレベルのチェックサム構造を算出するための動作２２４が、実行される。このことは、動作２０２から２０８の機能と同一の機能を実行することを必然的に伴う。
【００６８】
１３．次に、ヘッダから取り出されたチェックサムを、再現された、組み立てられたチェックサムコレクション構造に関するチェックサムと比較するための動作２２６が、実行される。再現されたチェックサムコレクション構造に関するチェックサムが、取り出されたチェックサム（すなわち、署名されたチェックサム）と合致する場合、電子メールは、真正であるものと考えられる。署名は、認証証明書に照らして検証され、受信者によって検査されるため、中間者攻撃の懸念は、解消されないとしても、大幅に小さくなる。
【００６９】
１４．組み立てられたチェックサムコレクション構造の署名を検証すること（例えば、認証証明書内に含まれる識別情報を介して）に応答して、署名が検証されることに成功したか否かを示す認証通知を与えるための動作２２８が、実行される。
【００７０】
表面上、この電子メールメッセージ認証方法は、多少、複雑であるように見える可能性がある。しかし、この方法は、メールを送受信する際にＭＵＡ／ＭＴＡによって通常、行われる電子メール本文をコピーすることと並行して、複数のチェックサム動作を実行することによって、最小限の処理時間で達せられることが可能である。さらに、最新の電子メールサーバは、通常、ウイルススキャンを行い、これと比較して、この電子メールメッセージ認証方法は、比較的単純である。
【００７１】
要するに、本発明による電子メールメッセージ認証は、送信者機能、ＭＴＡ機能、および受信者機能を含む。送信者機能は、元の電子メールメッセージのコンテンツに関するチェックサムを計算すること、チェックサムコレクション構造を生成するために、チェックサムおよび電子メールメッセージコンテンツを単一の構造に組み立てること、組み立てられたチェックサムコレクション構造に関するチェックサム（すなわち、第２のレベルのチェックサム構造）を計算すること、認証証明書に対応する秘密鍵を使用して第２のレベルのチェックサムに署名すること、署名された第２のレベルのチェックサム構造をそれぞれのヘッダ（例えば、ｘ−ＲｅａｌＮａｍｅ−ｃｈｅｃｋｓｕｍ）の中に入れ、認証証明書をそれぞれのヘッダ（例えば、ｘ−ＲｅａｌＮａｍｅ−ｃｅｒｔｉｆｉｃａｔｅ）の中に入れることを含む。ＭＴＡ機能は、各ＭＴＡが、ヘッダをそのままにしておく必要があることを含み、このことは、ほとんどのＭＴＡソフトウェアに関してデフォルトの機能である。受信者機能は、それぞれのヘッダから認証証明書、および署名された第２のレベルのチェックサム構造を抽出すること、証明書が有効である（すなわち、ＣＡによって正しく署名されている、失効していない、取り消されていない）ことを確認すること、証明書の中の公開鍵を使用して、署名された第２のレベルのチェックサムが、正しく署名されていることを確認すること、チェックサムコレクション構造に関するチェックサムの自らのバージョンを計算して、チェックサムの２つのバージョンを比較することを含む。署名された第２のレベルのチェックサム構造は、平文で現れ、このことは、暗号の強固なハッシュ関数（例えば、ＳＨＡ−１）が、ハッシュされて、その所与のチェックサムコレクション構造になる別の文字列を見出す実行可能な方法が存在しないことを意味するため、許容できることに留意されたい。この認証方法は、ＭＴＡソフトウェア変更がない（すなわち、展開するのが容易である）という利点、エンドツーエンドの展開という利点を有し、セキュリティのための登録にだけ依拠し、厳密な標準に従わないＭＴＡ／ＭＵＡに対しても機能する。
【００７２】
代替の一実施形態では、チェックサムのレベルが、よりかさばるヘッダ行が伝送されるという犠牲を払って、節約される。この代替は、チェックサムコレクション構造に直接に署名する（例えば、認証証明書に対応する秘密鍵を使用して）ことを、この構造に関する第２のレベルのチェックサム構造に署名するのではなく、行うことである。そのような代替の実施形態において、情報受信者デバイスは、チェックサムコレクション構造を解読する（例えば、認証証明書の中の公開鍵を使用して）ことを、この構造のチェックサムを確認することではなく、行う。このため、符号化されたチェックサムコレクション構造の実施形態には、認証証明書に対応する秘密鍵によって署名されている、組み立てられたチェックサムコレクション構造、および暗号化されている、組み立てられたチェックサムコレクション構造が含まれるが、以上には限定されないことが本明細書で開示される。
【００７３】
別の代替の実施形態では、第２のレベルのチェックサム構造に署名することは、省略され、組み立てられたチェックサムコレクション構造に署名が行われる。
【００７４】
別の代替の実施形態において、認証証明書は、電子メールヘッダ行の中で直接には供給されず、間接的にアクセスされる。認証証明書は、かさばる可能性があり、各送信者／受信者デバイスペアは、時とともに複数の電子メールを送信する可能性が高いため、同一のかさばる証明書を多数回、送信するのを回避することとともに、必須の検証を回避することが有利である。このことは、完全な証明書の代わりに、証明書へのポインタ（例えば、ＵＲＬ）を挿入することによって行われることが可能である。次に、受信デバイスは、指定された認証証明書をフェッチし、後の使用のために、この証明書をキャッシュすることができる。このため、認証証明書と、認証証明書が、或る特定のソースからアクセスされることを可能にするポインタなどの手段とはともに、本発明による認証証明書情報の例である。また、要求される認証証明書を指定することの、この「間接的」アプローチは、本発明によるウェブページ認証に関しても有用であることも認められよう。
【００７５】
さらに別の代替の実施形態において、チェックサム構造（第２のレベルのチェックサム構造、または組み立てられたチェックサムコレクション構造）は、署名されるのではなく、暗号化される。そのような実施形態において、暗号化されたチェックサムは、ヘッダの中に挿入され、受信者は、署名を検査するのではなく、暗号化されたチェックサムを解読しなければならない。メッセージの平文が、署名の動作の後でさえ目に見えるままであるのに対して、メッセージの平文は、暗号化の動作の後、読み取り不能になる。署名すること、および暗号化することは、エンティティが、証明書に対応する秘密鍵を有することを証明し、したがって、エンティティのＩＤを証明することを目的とする符号化の例であることが、本明細書で開示される。署名の有効性を検証すること、および解読することは、そのような符号化された情報を復号することの例であり、さらに、許可された関係者によって実行された場合、符号化された情報のセキュリティで保護された通信を可能にする。したがって、署名するため、および署名を検証するために実行される本明細書における動作、および関連する機能は、それぞれ、暗号化するため、および解読するための動作、および関連する機能で置き換えられることが可能であることが、本明細書で開示される。
【００７６】
チェックサムを暗号化すること、および解読することについてさらに述べると、署名動作または暗号化動作だけが、第２のレベルのチェックサム構造に対して実行される必要がある。いずれの動作も、送信者が、そのチェックサムを含む電子メールメッセージを送信したことを証明する。基本的に、第１の動作は、情報プロバイダデバイスが、チェックサムを計算するように実行される。チェックサムは、チェックサムコレクション、または第２のレベルのチェックサム構造であることが可能である。本明細書で開示されるとおり、第２のレベルのチェックサム構造の実施は、ＣＰＵサイクルを節約するとともに、要求される帯域幅を節約する。組み立てられたチェックサムコレクション構造、または第２のレベルのチェックサム構造を符号化することにより、メッセージが識別される。しかし、そのメッセージが、指定された情報プロバイダからであることを証明するための動作が、依然として、実行されなければならない。したがって、チェックサムに署名すること、またはチェックサムを暗号化することによって、そのような証明をもたらすための第２の動作が、実行される。証明が、署名することによる場合、それぞれの署名が、情報受信者デバイスに送信される。証明が、暗号化による場合、それぞれの暗号文が、情報受信者デバイスに送信される。署名されたチェックサム、または暗号化されたチェックサムに関して、情報受信者デバイスは、チェックサムが、組み立てられたチェックサムコレクションであるか、第２のレベルのチェックサム構造であるかにかかわらず、チェックサムを再現する同一の動作を一通り行う。供給された証明が暗号文である場合、情報受信者デバイスは、そのチェックサムを解読し、解読されたチェックサムを、再現されたチェックサムと比較する。供給された証明が署名である場合、情報受信者デバイスは、その署名を検査する。各送信者は、第１の動作と第２の動作の可能な４つの組合せのいずれかを使用するように、独立に選択することができる。
【００７７】
ウェブページ認証
ウェブページ認証に関して、本発明によるメッセージ認証を有効に実施するために、ＨＴＴＰ／ＨＴＭＬ（ハイパーテキストトランスポートプロトコル／ハイパーテキストマークアップ言語）の様々な態様に対処されなければならない。対処されなければならない一態様は、ウェブページが、単に、単一のＨＴＭＬファイルではないことである。ほとんどのウェブページは、異なるＵＲＬをそれぞれが有する、多くの異なる部分、例えば、イメージ、フレーム（それぞれがＨＴＭＬファイルによって指定された）、ｊａｖａｓｃｒｉｐｔから成る。
【００７８】
対処されなければならない別の態様は、Ｘ．５０９証明書を検証することは、処理リソースの見地から相当に費用がかかる動作であることである。多くのウェブサーバは、既に、この動作を専用のハードウェアに肩代わりさせ、作業負荷を増やすことは、好ましくは、最小限に抑えられなければならない。対処されなければならない別の態様は、単一のウェブページの諸部分が、しばしば、異なるサーバに由来することである。例えば、多くのウェブサイトは、第三者ウェブサイトエンティティ（例えば、広告プロバイダ）によって提供され、管理されるコンテンツ構成要素を有する。対処されなければならない別の態様は、多くのウェブサーバが、複数のドメインを扱うことである。例えば、所与のエンティティの複数のドメイン（例えば、ｗｗｗ．ｘ−ｃｏｍｐａｎｙ．ｃｏｍ、ｗｗｗ．ｘ−ｃｏｍｐａｎｙ．ｏｒｇ、ｗｗｗ．ｘ−ｃｏｍｐａｎｙ．ｔｖなど）がすべて、単一のサーバから提供されることが普通である。理論上、サーバセットアップが、これらの複数のドメインを分離すべきである。しかし、これらのドメインのすべてを提供する単一のサーバは、しばしば、これらのドメインすべてを同一のアドレス（例えば、ｗｗｗ．ｘ−ｃｏｍｐａｎｙ．ｃｏｍ）として扱う。有効な認証機能を提供するのに対処されなければならない、このことの１つの重大な悪影響は、各ＳＳＬ証明書が、対応するドメインを指定するために、多くのウェブサイトが、誤ったＳＳＬ証明書を使用することになってしまうことである。対処されなければならない別の側面は、信頼性のために、ほとんどの主要なウェブサイトは、何らかの種類の負荷分散およびレプリケーションを必要とすることである。このことは、複数のマシン（すなわち、場合により、異なるＯＳおよびウェブサーババージョンの）が、同一のＵＲＬに応じる可能性があることを意味する。これらの極端な場合において、単一のページの異なる部分、または単一のドメインの単なる諸部分でさえ、負荷分散セットの中の異なるサーバに由来する可能性があり、このことは、認証実行を複雑にする。対処されなければならない別の態様は、多くのウェブページが、静的ではなく、動的に生成されることである。これらの動的ページは、時として、複雑なシステムによって生成され、特殊なタグなどを有するように変更されるようウェブページを強制することは、望ましくない。対処されなければならないさらに別の態様は、ＳＳＬが、ＨＴＴＰより下位で動作し、このより高いレベルのプロトコルの知識を有さないため、ＳＳＬサーバが、或る特定のＩＰ／ポート組合せに関して１つの認証証明書だけしか提示することができないことである。このことは、ほとんどの場合において、ＨＴＴＰＳを用いた名前ベースの仮想ホスティングを使用することは、現在、実行可能ではないことを意味する。
【００７９】
本発明の一実施形態では、これらの独特の機能上の考慮点は、ＳＳＬ／ＴＬＳを無視して、ＨＴＴＰレベルで動作することによって対処される。有利には、このアプローチは、ＨＴＴＰＳが、機密情報に関してＳＳＬ／ＴＬＳを使用することを可能にする。これに関して、本発明の基礎をなす機能は、既存のセキュリティの備えに悪影響を及ぼさない。ウェブページは、ブラウザによって検査され、次に、ブラウザの別個の偽造不能な領域内で表示される認証証明書を参照する。この目的で、本発明の一実施形態では、情報受信者ユーザデバイスのブラウザが、図６に示されるウェブページ認証方法３００を実行する。
【００８０】
ＵＲＬ（ユニバーサルリソースロケータ）は、一般に、ＵＲＩ（ユニバーサルリソースアイデンティファイア）の同義語として使用されることを想い起こせば、厳密な違いは、この場合、我々に関係ない。ユーザ名、パスワード、ポート番号のような多くの複雑さを無視すると、単一のＵＲＩは、「ｈｔｔｐ：／／ｗｗｗ．ｘｘｘ．ｃｏｍ／ｄｅｍｏ／ｐａｇｅ．ｈｔｍｌ」のような外見であり、以下の３つの部分から成る。すなわち、
１．プロトコル、この場合「ＨＴＴＰ」。ＦＴＰ、ｔｅｌｎｅｔ、ｇｏｐｈｅｒ、ならびに、無論、ＨＴＴＰおよびＨＴＴＰＳを含む、数ダースのプロトコルが、サポートされる。我々は、このことの扱いをブラウザに任せ、我々は、単に、ブラウザが、指定されたリソースをどのように取り出すべきかを知っているものと見込む。
２．ホスト、この場合ウェブサーバのＤＮＳ名である「ｗｗｗ．ｘｘｘ．ｃｏｍ」。
３．パス、この場合所望されるリソースを指定する「ｄｅｍｏ／ｐａｇｅ．ｈｔｍｌ」。このリソースは、ＨＴＭＬファイル、ｇｉｆグラフィックイメージ、または他の何らかであることが可能である。また、このリソースは、静的であることも、動的に生成されることも可能である。これらの、戻されるリソースをＨＴＭＬファイルなどと呼ぶことが慣習的である。
【００８１】
ＨＴＴＰ（ハイパーテキストトランスポートプロトコル）は、ウェブサーバと通信するのにブラウザによって使用される最も一般的なプロトコルであることを想い起こされたい。ブラウザは、ＵＲＬ、およびサーバと対話する「メソッド」を提示し、我々は、これらのメソッドのうち２つ、すなわち、「ＧＥＴ」および「ＰＯＳＴ」について述べる。ゲットとポストはともに、ＵＲＬに対応する「リソース」を取り出し、ゲットとポストの違いは、この場合、我々に関係ない。ゲットとポストはともに、取り出されるリソースのタイプを返し、例えば、ＨＴＭＬファイルは、「ｔｅｘｔ／ｈｔｍｌ」というタイプであり、ｇｉｆ符号化されたグラフィックイメージは、「ｉｍａｇｅ／ｇｉｆ」というタイプである。（このＨＴＴＰタイプは、ファイル名またはＵＲＬのサフィックスによって示されるファイルタイプとは独立であり、タイプの複数の指示を調整することは、我々が扱う範囲を超えている）。我々は、概ね、以下の異なる３つのタイプのリソース、すなわち、ＨＴＭＬファイル、ＲｅａｌＮａｍｅ証明書、およびチェックサムに関心がある。
【００８２】
また、ＨＴＭＬ（ハイパーテキストマークアップ言語）は、ＳＧＭＬに由来する「マークアップ言語」であることも想い起こされたい。ＨＴＭＬは、或るテキストを見出し、段落、リストなどとして表すことによって、文書の中のテキストベースの情報の構造を記述し、さらにそのテキストを対話型フォーム、埋め込まれたイメージ、およびその他のオブジェクトで補足する手段をもたらす。ＨＴＭＬは、ラベル（タグとして知られる）の形態で書かれ、より小なり記号（＜）および大なり記号（＞）によって囲まれる。例えば、「＜ｔｉｔｌｅ＞Ｉｎｔｒｏｄｕｃｔｉｏｎ＜／ｔｉｔｌｅ＞」が、「ｔｉｔｌｅ」タグの例であり、「Ｉｎｔｒｏｄｕｃｔｉｏｎ」というテキストにそのページのタイトルとしてマークを付ける。結びのタグ「＜／ｔｉｔｌｅ＞」は、開始のタグに追加のスラッシュが付いているだけであることに留意されたい。ＨＴＭＬファイルは、ページの構造を記述するネストされたタグセットに過ぎない。我々は、ウェブページを識別するのに（同一のＵＲＬが、異なるページを毎回、動的に生成することが可能であるので）使用される追加のタグ＜ＲｅａｌＮａｍｅＳｅｒｉａｌＮｕｍｂｅｒ＞を加えることを提案する。ブラウザは、ブラウザに知られていないタグを無視するので、ＨＴＭＬ標準を変更することは望ましいが、必須ではなく、このことは、ウェブブラウザが、＜ＲｅａｌＮａｍｅＳｅｒｉａｌＮｕｍｂｅｒ＞タグをＨＴＭＬファイルの中に常に含めることに害はなく、ＲｅａｌＮａｍｅ対応のブラウザは、このタグを認証し、非対応のブラウザは、このタグを無視するに過ぎないことに留意されたい。また、我々がＨＴＭＬを参照する場合、我々は、情報のさらなるタグ付けをサポートすることができるＸＨＴＭＬ様のマークアップ言語、および他のＸＭＬ／ＳＧＭＬ様のマークアップ言語を含める。
【００８３】
１．ウェブページの先頭で、ＨＴＴＰ ＧＥＴ／ＰＵＴを使用してウェブサーバからファイルをフェッチするための動作３０２が、実行される。ＵＲＬおよびファイルは、この場合、それぞれ、「Ｔｏｐ ＵＲＬ」および「Ｔｏｐファイル」と呼ばれる。我々は、トップファイルがＨＴＭＬファイルである場合に最も関心があり、我々は、「Ｔｏｐ ＨＴＭＬファイル」において、このファイルを参照する。（この場合、「トップ」とは、このＨＴＭＬファイルが、他の多くのＨＴＭＬファイルが、このページの部分としてフェッチされるようにすることによって、ウェブページの構築を制御するということを指す）。ＲｅａｌＮａｍｅをサポートするウェブサーバは、各Ｔｏｐ ＨＴＭＬファイルが、通し番号および証明書ＵＲＬ（これら２つのアイテムは、単一のタグの中にあることも、複数のタグの中にあることも可能である）を指定するタグを含むようにする。通し番号は、そのページの特定のインスタンスを識別するのに使用され、連続的にインクリメントする番号に限定されず、最も好都合な形態は、通し番号が、ＵＲＬの形態にもなっていることである。この通し番号構成は、最上レベルのＨＴＭＬに関してだけ行われる。より低いレベルのＨＴＭＬに関する認証を許すことは、ＣＰＵおよび帯域幅の点で高価であるとともに、種々のクロスサイトスクリプティング攻撃に機会を与える。
【００８４】
２．Ｔｏｐ ＨＴＭＬファイルをフェッチすることに応答して、ＨＴＴＰを使用して、またはＵＲＬの中で指定された任意の機構を使用して、指定された認証証明書をフェッチするための動作３０４が、実行される。認証証明書を取り出した後に、認証証明書をキャッシュするための動作、その結果、遠隔ソースから認証証明書を後に取り出す必要性を排除することが本明細書で開示される。
【００８５】
３．認証証明書をフェッチした後、そのレジストリの存在する（すなわち、あらかじめ格納された）ルート証明書を使用して認証証明書を検証するための動作３０６が、実行される。
【００８６】
４．認証証明書を検証することに成功することに応答して、Ｔｏｐ ＨＴＭＬファイルに関するチェックサムを取り出す動作３０８が、実行される。このことは、通し番号をウェブサーバに送信すること（好ましい形態において、通し番号は既に、チェックサムを取り出すのに使用されることが可能なＵＲＬである）、ウェブサーバから対応する秘密鍵で符号化されたチェックサム（例えば、秘密鍵署名された、秘密鍵暗号化された、その他）を受信すること、および認証証明書の中の公開鍵を使用して、このチェックサムを復号すること（例えば、公開鍵検証、公開鍵解読、その他）によって行われる。チェックサムを符号化するために使用される秘密鍵が、認証証明書の中の公開鍵と合致するという条件付きで、ウェブサーバからの秘密鍵符号化されたチェックサムは、正しく復号される。異なる秘密鍵が使用されている場合、この復号は、失敗する、または復号されたチェックサムは、誤りであり、認証に不合格となる。
【００８７】
５．ウェブサーバからのチェックサムを解読することに成功したことに応答して、Ｔｏｐ ＨＴＭＬファイルが、実際に、そのウェブサーバに由来することを、Ｔｏｐ ＨＴＭＬファイルの我々のチェックサムを計算し、我々のチェックサムを、ウェブサーバから解読されたチェックサムと比較することによって、検証するための動作３１０が、実行される。これらのチェックサムが等しい場合、そのウェブページに関する識別情報は、認証されることに成功している。等しくない場合、認証は、失敗である。
【００８８】
６．ウェブページが真正であると判定されたか否かを判定することに応答して、ウェブページ（すなわち、ウェブページの識別情報）が真正であると判明したか否かを示す通知情報を提示するための動作３１２が、実行される。一実施形態では、この通知情報は、ウェブページコンテンツとは別個のブラウザウインドウの領域内で提示される。さらに、一実施形態では、認証証明書は、その別個の領域の表示を制御するＨＴＭＬファイルを含むことが可能である。
【００８９】
このウェブページ認証方法の利点は、トップＨＴＭＬファイルだけしか変更される必要がないことである。トップＨＴＭＬファイルだけが、それぞれの認証証明書を有する必要があるだけ十分に「重要」と考えられるウェブページであると想定することにより、例えば、帯域幅、サイクルなどの貴重なネットワークリソースが節約されることもある。このように想定することは、トップＨＴＭＬファイルが、他のいずれの部分がウェブページの中に含められるかを制御するので、妥当な想定である。トップＨＴＭＬファイルを認証することによって、我々は、後続の部分が、意図されるとおりにフェッチされることを暗黙に保証され、偽造は、正当なウェブサーバを覆すことを要求する。このことは、本発明の範囲を超える異なるセキュリティ問題である。また、この方法の実施は、有利には、ＨＴＴＰバージョン１．１を要求しない。一部の実例では、Ｔｏｐ ＵＲＬは、リダイレクトまたはタイムアウトを含むＴｏｐ ＨＴＭＬを返す可能性があり、その場合、ブラウザは、両方のページを認証する必要がある。リダイレクトは、長い時間がかかる、または決して行われない可能性がある。しかし、その一方で、リダイレクトページは、いくらかの表示可能な情報、およびクリック可能なリンクを含む可能性もある。トップＨＴＭＬファイルだけを認証することの結果は、多くのページ、例えば、単一のイメージから成るページが認証可能でないことであり、このことは、ユーザがサーバに情報を返送するのにＨＴＭＬが要求されるので（このことは、フィッシングの試みがＨＴＭＬを使用しなければならないことを意味する）、深刻な問題ではないことに留意されたい。
【００９０】
通し番号、および暗号化されたチェックサムを使用する、この手続きは、面倒であると見なされる可能性がある。しかし、Ｔｏｐ ＨＴＭＬファイルが、称されるところのウェブサーバに実際に由来することをサーバに確認させることが必要である。電子メールメッセージ認証方法と同様の仕方でＴｏｐ ＨＴＭＬファイルの中にチェックサムを埋め込むことが好ましい。しかし、Ｔｏｐ ＨＴＭＬファイルの中にチェックサムを埋め込むという動作自体が、チェックサムを変化させる。埋め込まれたチェックサムが、チェックサム計算から除外されるべきことが指定されているとした場合でも、そのチェックサムの存在は、やはり、チェックサム計算問題をもたらす。このことは、動的ページに関して、ファイル全体が生成されて、送信されるまで、ウェブサーバが、チェックサムを計算することを終えることができないためである。オプションとして、チェックサムを＜／ｂｏｄｙ＞タグまたは＜／ｈｔｍｌ＞タグの一部にすることによって、Ｔｏｐ ＨＴＭＬファイルが送信された後、暗号化されたチェックサムが送信されるべきことが指定されることが可能であるが、そうすることは、＜ｈｔｍｌ＞＜／ｈｔｍｌ＞ペアの外にタグを許すようにＨＴＭＬの定義を変更すること、またはチェックサムを計算する際に、複雑な編集を実行することを要求する。
【００９１】
通し番号を介してチェックサムへのアクセスを許すことによって、本発明によるウェブページ認証は、アドオンの仕方で実施されることが可能である。例えば、そのようなアドオン機能は、＜ＲｅａｌＮａｍｅＳｅｒｉａｌＮｕｍｂｅｒ＞タグを有するＨＴＭＬファイルを探してＨＴＴＰ応答を調べる。そのようなＨＴＭＬファイルが見つかるといつでも、チェックサムが計算され、情報受信者デバイスが、後に、そのチェックサムを照会することができるように、データベースの中に入れられる。さらに、この機能を、ウェブサイト／ブラウザソフトウェアに入れられるアドオン機能に組み込むことも、比較的容易である。
【００９２】
別の実施形態では、チェックサムは、ＨＴＭＬファイルの一部ではなく、ＨＴＴＰプロトコルの一部として伝送される。実行可能ではあるが、このようにすることは、ＨＴＭＬファイルのコンテンツとプロトコルの間の結合を生じさせる。また、署名する動作が、ＨＴＴＰ要求の完了に関するネックになる。さらに、そのようなソリューションは、許容できる結果を実現するのに多くのソフトウェア拡張が行われなければならないため、展開するのが困難である可能性も高い。別の実施形態では、チェックサムは、ＨＴＭＬファイルの最後の部分として含められる。このことは、例えば、＜／ｈｔｍｌ＞という結びのタグの後に来る新たなＨＴＭＬタグ＜ＲｅａｌＮａｍｅＣｈｅｃｋｓｕｍ＞を定義し、次に、チェックサムが、＜ＲｅａｌＮａｍｅＣｈｅｃｋｓｕｍ＞を除外して計算されるべきことを指定することによって、実施されることが可能である。つまり、ＨＴＭＬファイルを取り上げ、＜ＲｅａｌＮａｍｅＣｈｅｃｋｓｕｍ＞タグを編集して除き、次に、チェックサムを計算する。このソリューションは、実行可能であるが、ＨＴＭＬファイルのコンテンツとプロトコルの間の結合に関して前述した状況を生じさせ、署名動作が、ネックとなり、さらに実際の展開は、ソフトウェア拡張に依存する。
【００９３】
代替として、本発明による別のウェブページ認証方法は、認証証明書の扱いを、ＵＲＬおよびＨＴＭＬとは無関係にすることを含む。有利には、この方法は、ウェブページ（静的または動的）の変更をまったく要求せず、単一のイメージから成るページを含め、すべてのページを認証することができる。したがって、この方法は、望ましい代替である。証明書の扱いは、事前定義された特殊なＵＲＬに対する通常の要求として行われることが可能である。詳細には、ＨＴＴＰ１．１接続が、通常に行われるとおりに（標準のＳＳＬを伴って、または伴わずに）セットアップされ、ブラウザが、標準の事前定義されたＵＲＬを使用して認証証明書をフェッチし、この証明書が、検査され、秘密鍵のプロセッションが、検査される。このことにより、ウェブサーバが、証明書の所有者のために正当に動作していることが確認される。単一の法人エンティティに関して複数のドメイン名をホストしているウェブサーバは、この方法の容易な実施を特に評価することが、当業者には理解されよう。
【００９４】
また、前述したウェブページ認証方法は、有利に組み合わされることが可能であることも本明細書で開示される。そのような実施形態において、第１の説明される方法が、適用されることが可能である。トップＨＴＭＬが、認証証明書をポイントするタグを含まない場合、第２の説明されるソリューションが、適用されることが可能である。オプションとして、これら２つのソリューションは、逆の順序で適用されることも可能である。いずれかの方法が、認証された識別情報をもたらす場合、その趣旨の指示が、提示される。いずれかの方法が、無効な証明書、または不良な秘密鍵確認をもたらす場合、偽造の試みの可能性の指示が、提示されなければならない。いずれの方法も、メッセージ認証（成功した、またはそれ以外の）をもたらさない場合、そのような認証が未確認であるという指示が、提示されなければならない。
【００９５】
この「特殊なＵＲＬ」は、認証の目的でウェブサーバがサポートする標準化されたＵＲＬである。例えば、この「特殊なＵＲＬ」は、「ｈｔｔｐ：／／ｗｗｗ．ｅｎｔｉｔｙ−ｎａｍｅ．ｃｏｍ／＄＄ＲｅａｌＮａｍｅ＄＄」であることが可能であり、したがって、最上レベルのＵＲＬが、そのドメインにある（すなわち、ＵＲＬが、「ｈｔｔｐ：／／ｗｗｗ．ｅｎｔｉｔｙ−ｎａｍｅ．ｃｏｍ」から始まる）場合、ブラウザは、「ｈｔｔｐ：／／ｗｗｗ．ｅｎｔｉｔｙ−ｎａｍｅ．ｃｏｍ／ＲｅａｌＮａｍｅ」をウェブサーバに求めて、対応するＲｅａｌＮａｍｅ（すなわち、認証）証明書を取り出す。ドル記号は、多くのウェブマスタが、このＵＲＬが「通常のデータページではなく」、注意を払って変更されるべきことを示すのに使用する慣習に過ぎない。このアプローチは、本発明に従って構成された認証証明書に合わせて構成されていないサーバが、「４０４−ページが見つかりませんでした」などのエラーメッセージを返す一方で、本発明による認証対応であるウェブサーバは、それに相応して証明書を返すという点で、本発明に従って構成された認証証明書に合わせて構成されていないサーバに対して機能することに留意されたい。
【００９６】
ＩＭメッセージ認証
インスタントメッセージング認証に関して、問題は、やはり異なる。しかし、それらの問題は、概ね、前述した電子メールメッセージ認証に関連する独特の機能上の考慮点のサブセットである。１つのそのような考慮点は、ほとんどのＩＭシステムが、クライアント間で「調停する」中央サーバを有することである。したがって、クライアントは、他のクライアントと直接に通信しない。このことは、基本的に、電子メールのマルチホップの性質と同一の状況である。別のそのような考慮点は、通常、各ベンダにつき１つの、異なる複数のＩＭプロトコルが存在し、さらに、各ＩＭプロトコルに関して、異なる多くのユーザエージェントも存在することである。さらに別のそのような考慮点は、まったくの他人が互いに電子メール送信することができる電子メールとは異なり、クライアントペアが、通常、スクリーン名交換プロトコルを介して、クライアント自らの許可された連絡先リストに互いを相互に追加しなければならないことである。
【００９７】
したがって、ＩＭメッセージ認証を円滑にするように構成された本発明の実施形態は、これらの独特の機能上の考慮点に対処しなければならず、前段で開示される電子メールメッセージ認証方法と同様の意向で構成される。この目的で、本発明の一実施形態では、図７に示される以下のＩＭメッセージ認証方法４００が、ＩＭ対応の受信者デバイスによって実施される。実施形態の詳細は、必然的に、基礎をなす特定のＩＭプロトコルに依存する可能性があることが当業者には認識されよう。
【００９８】
１．ＩＭダイアログセッションごとに、またはＩＭスクリーン名を連絡先リストに追加する時点においてだけ、ＩＭクライアント間で認証証明書を交換するための動作４０２が、実行される。ＩＭダイアログセッションごとに認証証明書を交換することは、ＩＭクライアントが、異なるチャットセッションに関して異なる、認証されたスクリーン名を使用することを許すという利点を有する。ＩＭスクリーン名を連絡先リストに追加する時点においてだけ認証証明書を交換することは、ＩＭメッセージにおける認証証明書の伝送を節約し、このことは、認証証明書が、比較的「かさばる」ので、有利であり、さらにＩＭスクリーン名が追加される時点において、ＩＭスクリーン名の認証を可能にする。
【００９９】
２．認証証明書を交換した後、ＩＭスクリーン名を検査するための動作４０４が、実行される。このことは、ＩＭスクリーン名を、それぞれの認証証明書に埋め込まれた名前と照合することによって行われることが可能である。このアプローチは、スクリーン名が、証明書を発行する時点で固定されることを意味する。代替として、スクリーン名は、証明書に埋め込まれず、検査することは、スクリーン名に署名することによって行われることが可能であり、このことは、複数のスクリーン名が使用されることが可能である（場合により、証明書は、「技術支援」部門に関し、各技術者が、個人スクリーン名を有する）という利点を有する。認証手続きが失敗した場合、対応する１つまたは複数の通知アクションが、行われることが可能である。これらの通知アクションの例には、スクリーン名を追加することが拒否されることが可能であり、スクリーン名を追加することの確認を要求するユーザダイアログウインドウが、提示されることが可能であり、スクリーン名に、認証されていないというフラグが付けられ、スクリーン名が、ＩＭ連絡先リストの中の或る特定の「認証されていない」グループにリダイレクトされることが可能であることなどが含まれるが、以上には限定されない。この特定のアクションは、ＩＭクライアントポリシー設定の特性として指定されることが可能である。
【０１００】
３．ＩＭユーザが、チャットセッションを開始すると、ＩＭメッセージの指定された部分に関するチェックサムを作成するための動作４０６が、ＩＭメッセージが送信されるデバイス（すなわち、送信者ユーザデバイス）によって実行される。一実施形態では、これらの部分には、実際のメッセージ、送信者スクリーン名、および日付／時刻情報が含まれる。
【０１０１】
４．チェックサムを作成した後、符号化されたチェックサムを生成するために、証明書に対応する秘密鍵を使用してチェックサムを符号化するための動作４０７が、実行される。この符号化されたチェックサムは、証明書の認証を可能にするために、証明書に対応する秘密鍵によって署名されている、または暗号化されているチェックサムである。
【０１０２】
５．チェックサムを符号化した後、ＩＭメッセージの中で指定された受信者スクリーン名に対応するデバイス（すなわち、受信者ユーザデバイス）によって受信されるように、符号化されたチェックサム、およびＩＭメッセージを伝送するための動作４０８が、実行される。
【０１０３】
６．符号化されたチェックサムを伝送した後、符号化されたチェックサムを受信するための動作４１０が、受信者ユーザデバイスによって実行される。
【０１０４】
７．符号化されたチェックサムを受信した後、符号化されたチェックサムを検証し、さらに情報プロバイダの認証証明書を使用してチェックサムをレプリケートして、確認するための動作４１２が、受信者ユーザデバイスによって実行される。情報プロバイダの認証証明書は、符号化されたチェックサムの有効性を検証するために使用される。符号化されたチェックサムの検証は、前段で開示される電子メール実施形態における、符号化されたチェックサムの検証と同一の仕方で（例えば、署名を検査し、または符号化されたチェックサムを解読し、情報プロバイダの認証証明書を使用してチェックサムをレプリケートし、確認して）実行される。
【０１０５】
８．チェックサムが検証されることに成功したか否かを示す通知情報を提示するための動作４１４が、実行される。チェックサムの検証が失敗した場合、送信者のスクリーン名に、認証されていないというフラグが付けられ、通知が、提示される。さもなければ、スクリーン名は、追加され、認証の成功の通知が、提示される。前述したとおり、ポリシーが、行われるべきさらなるアクションを規定することが可能である。
【０１０６】
本発明による情報プロバイダ認証アプリケーションは、様々な機能に関して、機能的、さらに／または物理的に分離されることが可能であることが、本明細書で開示される。例えば、一実施形態では、識別情報識別検証機能が、情報プロバイダ認証アプリケーションの第１の部分を介して提供され、通信媒体固有の機能が、情報プロバイダ認証アプリケーションの他の１つまたは複数の部分を介して提供される。より具体的には、一実施形態では、識別情報識別検証機能が、情報プロバイダ認証アプリケーションの第１の部分を介して提供され、電子メール認証固有の動作が、情報プロバイダ認証アプリケーションの第２の部分を介して提供され、ウェブ認証固有の動作が、情報プロバイダ認証アプリケーションの第３の部分を介して提供され、さらにＩＭメッセージ固有の動作が、情報プロバイダ認証アプリケーションの第４の部分を介して提供される。この目的で、本発明による認証アプリケーションは、モジュール型で設計され、保持されることが可能である。
【０１０７】
次に、本発明によるデータ通信デバイスによって処理可能な命令について述べると、本明細書で開示されるメッセージコンテンツ認証機能および／または識別情報機能を円滑にするために適合された方法、プロセスおよび／または動作は、そのような機能を実行するように構成された命令を有するコンピュータ可読媒体によって実体化されることが、本明細書で行われる開示から理解されよう。１つの特定の実施形態では、これらの命令は、図１から図７を参照して開示される方法の１つまたは複数を実行するために実体化される。これらの命令は、メモリ装置（例えば、ＲＡＭ、ＲＯＭ、仮想メモリ、ハードドライブメモリなど）から、データ処理システムのドライブユニットによって読み取り可能な装置（例えば、ディスケット、コンパクトディスク、テープカートリッジなど）から、またはこれらの両方から、１つまたは複数のデータ処理デバイスによってアクセス可能であり得る。したがって、本発明によるコンピュータ可読媒体の実施形態には、本発明によるメッセージコンテンツ認証機能および／または識別情報機能を実行することを円滑にするために適合された命令（例えば、コンピュータプログラム）がイメージ化されているコンパクトディスク、ハードドライブ、ＲＡＭ、または他のタイプの記憶装置が含まれる。
【０１０８】
以上の詳細な説明において、本明細書の一部を形成し、例示として、本発明が実施されることが可能な特定の実施形態が示される、添付の図面が、参照されてきた。これらの実施形態、およびこれらの実施形態のいくつかの変種が、本発明の実施形態を当業者が実施することができるようにするのに十分な詳細で説明されてきた。他の適切な実施形態が、利用されることも可能であり、さらにそのような発明の開示の趣旨または範囲を逸脱することなく、論理的、機械的、化学的、および電気的な変更が行われることが可能であるものと理解されたい。不必要な詳細を回避するのに、この説明は、当業者に知られている或る情報を省略している。したがって、以上の詳細な説明は、本明細書で示される特定の形態に限定されることは意図されず、それどころか、添付の特許請求の範囲の趣旨および範囲に合理的に含まれることが可能な、そのような代替形態、変形形態、および均等形態を範囲に含むことが意図される。
【技術分野】
【０００１】
本明細書で行われる開示は、一般に、コンピュータネットワークシステムにおける認証の備えに関し、より詳細には、ウェブページの真正性を検証することに関する。
【背景技術】
【０００２】
いくつもの理由で、電子メールメッセージ送信者の真正性を検証する必要性は、軽視され得ない。そのような認証は、電子メールメッセージの中で示される送信側エンティティの識別情報が、認証され得ない場合、警報をもたらす必要がある。電子メールメッセージの中で与えられる送信者識別情報の例には、送信側エンティティの名前、ロゴ、可聴音などが含まれるが、以上には限定されない。詐欺的な電子メールメッセージおよび悪意のある電子メールメッセージを送信するエンティティが何者であるかを知ることは有用であろうが、その一方で、単に、電子メールメッセージの中で与えられる送信者識別情報が、信頼される認証プロセスに合格したか、不合格であったかを簡単に知ることに極めて大きな価値がある。同様に、認証が、詐欺的な電子メールメッセージまたは悪意のある電子メールメッセージを送信している個人またはエンティティを識別しないものの、電子メールメッセージ送信者が、認証されることに成功しているか否かを知ることにも価値がある。
【０００３】
そのような電子メールメッセージ認証を提供するための有効で、実際的な手段の欠如が、例えば、「フィッシング」などの犯罪行為の急速な増加につながっている。フィッシングにおいて、犯罪者は、通常、受信者に電子メールを、その電子メールメッセージが、例えば、金融機関、オンラインサービスプロバイダなどの評判のよい、さらに／または信頼されるエンティティから送信されていることを装って送信する。その電子メールメッセージは、機密情報で返信するよう（例えば、機密情報が入力されることが可能な詐欺的なウェブサイトへのリンクを介して）受信者を誘う。獲得された場合、犯罪者は、その機密情報を使用して、電子メールメッセージ受信者の対応する１つまたは複数の口座を危うくする。機密情報の例には、銀行口座、投資口座、オンライン支払いサービス口座、オンライン競売口座などにアクセスするために使用される情報が含まれるが、以上には限定されない。この情報を使用して、犯罪者は、通常、対応する口座から資金を盗む、またはそのような口座情報を使用して、受信者のＩＤを使用した他の個人もしくはエンティティに対する金銭的詐欺を容易にする。残念ながら、フィッシングは、大きい、増大している問題であり、フィッシング手法は、週を追うごとに偽装の巧妙さを増している。
【０００４】
電子メールメッセージ送信者の認証に関して、１つの知られているソリューションは、ＳＰＦ（送信者ポリシーフレームワーク）である。ＳＰＦは、電子メールメッセージが、そのドメインから電子メールメッセージを送信することを許されていると指定されているマシンから来たことを確認しようと試みる。残念ながら、ドメインの正当性に関する検査は、存在しない。したがって、誰でも、「ｘ−ｃｏｍｐａｎｙ−ｓｐｅｃｉａｌ−ｏｎ−ＴＶ．ｃｏｍ」のようなドメインを登録して、ｘ−ｃｏｍｐａｎｙから電子メールメッセージを送信していると主張することができる。
【０００５】
デマ電子メールメッセージが、電子メールメッセージの送信者を認証することが有益である別の状況を代表する。例えば、多くのデマ電子メールは、権威あるソースからであると称するが、明らかにそうではない。しかし、電子メールメッセージの受信者が、送信者ＩＤを有効に、実際的に認証する方法は、現在、存在しない。実際の権威あるソースからの否定が、これらのデマ電子メールメッセージをどうにか抑え込むことは稀である。
【０００６】
一般に「スパム」とも呼ばれる、求められていない大量電子メール送付が、広まっている。スパムを規制しようとする試みのすべてにもかかわらず、スパムの出現率は増え続けており、現在、すべての電子メールメッセージの大半を占めると推定されている。したがって、スパムの頻度および量を減らす必要性が、明らかに存在する。さらに、これらの求められていない大量電子メール送付が、これらの電子メールメッセージが正当な、さらに／または信頼されるエンティティからであることを偽って示すヘッダ情報を通常、有することは、驚くにあたらない。ヘッダ情報の認証は、個人が受信するスパムの量を制限するための手段を、フィッシングなどの関連する詐欺的な行為の対象となる可能性を制限することに加えて、もたらす。
【０００７】
詐欺的なウェブページが、しばしば、セットアップされ、電子メールメッセージを介して開始されるフィッシング行為をサポートするのに、しばしば、使用される。これらの詐欺的なウェブサイトは、信頼される機関のウェブサイトであるように見えるが、実際には、犯罪行為を犯す特定の目的でセットアップされる。したがって、ウェブページおよび／またはウェブサイトを管理しているエンティティを検証することに大きな価値がある。
【０００８】
電子メールメッセージおよびウェブページと同様に、ＩＭ（インスタントメッセージング）システムが、犯罪行為または欺く行為が、通常、偽のＩＤの使用を介して実行されるさらに別のネットワークベースの通信アプローチである。ＩＭメッセージの送信者として示されるＩＭスクリーン名の認証が、望ましく、そのＩＭスクリーン名が、或る特定の機関からであると認証されるのが、望ましい。そのような認証なしには、機密情報は、ＩＭを使用する通信を介して、直接に、または間接的に、容易に危険にさらされ得る。
【０００９】
受信者に電子メールメッセージ、ウェブサイト／ウェブページ、および／またはＩＭ（インスタントメッセージング）メッセージを提供することを担ったと称されているエンティティを認証するための完全で、さらに／または有効なソリューションは、現在、存在しない。このため、偽装されたＩＤ情報に基づき、データ通信ネットワークを介して犯されるフィッシング、スパム、および他のタイプの犯罪行為または欺く行為は、なくならず、増え続ける。偽装されたＩＤ情報に基づく、そのような犯罪行為および欺く行為の問題を解決することと関係するが、実際には、これらの問題を完全に解決しない、またはこれらの問題に十分に対処しないソリューション、または部分的ソリューションに、いくつもの要素が存在する。
【００１０】
ウェブページが、対応するＵＲＬ（ユニフォームリソースロケータ）の実際の所有者から来ていることを確認しようと試みる、知られている１つのソリューションは、ＨＴＴＰＳ（すなわち、ＳＳＬ保護を伴うハイパーテキストトランスポートプロトコル）としても知られる、ＳＳＬ／ＴＬＳ（セキュアソケットレイヤ／トランスポートレイヤセキュリティ）プロトコルと組み合わされたＤＮＳ（ドメイン名システム）である。残念ながら、いくつかの要因が重なり合って、そのようなソリューションを不十分にしている。この知られているソリューションを効果的とは言えないものにする１つの要因は、多くの企業が、複数のドメイン名を使用し、これらのドメイン名が、一貫した規則なしに出入りすることである。例えば、ｘ−ｃｏｍｐａｎｙが、「ｘ−ｃｏｍｐａｎｙ」を、重要なすべての最上レベルドメインにおいて登録し（例えば、ｘ−ｃｏｍｐａｎｙ．ｃｏｍ、ｘ−ｃｏｍｐａｎｙ．ｎｅｔ、ｘ−ｃｏｍｐａｎｙ．ｏｒｇなど）、さらに各国ドメインにおいても登録する（例えば、ｘ−ｃｏｍｐａｎｙ．ｃａなど）ことが可能である。しかし、特別プロモーションのため、ｘ−ｃｏｍｐａｎｙは、ｘ−ｃｏｍｐａｎｙ−ＴＶ．ｃｏｍドメイン名を有するが、ｘ−ｃｏｍｐａｎｙ−ＴＶ．ｃａドメイン名は有さないことが可能である。このことは、消費者が、ドメイン名、ｘ−ｃｏｍｐａｎｙＴＶ．ｃｏｍ、ｘ−ｃｏｍｐａｎｙ−ＴＶ−ｓｐｅｃｉａｌ．ｃｏｍなどを示された場合に、容易に混乱し得ることを意味する。この知られているソリューションを効果的とは言えないものにする別の要因は、企業が、派手に宣伝されることもほとんどなく作られた子会社およびその他の法人エンティティを、しばしば、有することである。平均的な消費者が、これらすべてのドメイン名を常に把握していることは困難である。この知られているソリューションを効果的とは言えないものにするさらに別の要因は、同一の名前を正当に有する複数の企業が、しばしば、存在することである。最も頻繁な場合は、２つの企業が異なる管轄区域において営業している場合である。ＤＮＳ所有権モデルは、実質的に先着順であり、紛争解決機構が設置されている。したがって、複数のエンティティのいずれが、「最も自明な」ドメイン名を有するか、あるいは消費者が求める企業が、自明でないドメイン名を使用していることを消費者が知ることは、実質的に不可能である。この知られているソリューションを効果的とは言えないものにするさらに別の要因は、多くの数字および／またはテキスト文字が似ていることである。偽装されたＩＤ情報に関して、欺く目的で数字およびテキスト文字を使用するための１つの古典的なアプローチは、大文字の「Ｏ」に数字「０」を代用すること、または小文字の「Ｌ」に数字「１」を代用することである。最近では、キリル文字またはユニコード文字を使用するはるかに巧妙な策略が、存在する。以上のことは、犯罪者が、本物のドメイン名と視覚的に実質的に見分けのつかない偽のドメイン名を有することを可能にする。ブラックリスト、ならびにヒューリスティクスを使用して、これらの偽のドメイン名を識別しようと試みる類のソフトウェアが種々、存在する。しかし、このソフトウェアは、ネットワークオーバヘッド、ならびに不正なドメインをブラックリストに追加するのに時間がかかるという問題を抱えている。この知られているソリューションを効果的とは言えないものにするさらに別の要因は、スパム電子メールが、巨大な問題に成長していることである。ほとんどのフィルタリングの取り組みは、電子メールメッセージコンテンツを調べて、例えば、処方薬のオンライン購入などの現在、流布しているスパムトピックを識別するというアプローチをとってきた。最先端のスパムは、現在、イメージ、ならびにスペルミスを使用して、これらのフィルタを通り抜ける。
【００１１】
最近、「ＥＶ証明書」（拡張された検証証明書）と呼ばれる認証方法が、導入されている。その名前が暗示するとおり、この認証方法は、標準の（すなわち、非ＥＶの）ＳＳＬ／ＴＬＳ証明書と同一の基礎を有するが、追加の検証を伴う。標準の（すなわち、非ＥＶの）ＳＳＬ／ＴＬＳ証明書に関連して前段で説明される問題のほとんどが、やはり、当てはまる。ＥＶ証明書は、詐欺的な行為（例えば、フィッシング）の犯人を、そのような詐欺的な行為が実行された後に、見つけ出すのに役立つに過ぎず、そのような詐欺的な行為を防止するのではないものと考えられている。明らかに、犯人は、しばしば、オンライン詐欺取締り予算、または詐欺的な、もしくは悪意のあるオンライン行為を取り締まることへの関心がほとんど、またはまったくない環境における見せかけのエンティティである。したがって、ＥＶ証明書は、いくつかの仕方で役立つものの、フィッシングの問題を実際に解決するようには思われない。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
したがって、ネットワークベースの通信アプローチが、電子メールであるか、ウェブページであるか、さらに／またはインスタントメッセージングであるかにかかわらず、偽装されたＩＤ情報、またはそれ以外で不正直なＩＤ情報に基づくネットワーク対応の犯罪行為および欺く行為に対抗するための知られているアプローチに関連する欠点の少なくとも一部分を克服するソリューションは、有用であり、有利であり、さらに革新的である。
【課題を解決するための手段】
【００１３】
本発明の実施形態は、偽装されたＩＤ情報、またはそれ以外で不正直なＩＤ情報に基づくネットワークベースの犯罪行為および欺く行為に対抗するための知られているアプローチに関連する欠点を克服する。より具体的には、本発明の実施形態は、電子メールメッセージの送信者として示されるエンティティ、ウェブページの所有権を有するエンティティ、および／またはＩＭ（インスタントメッセージング）メッセージの送信者として示されるエンティティに対応するＩＤ情報の認証をもたらす。そのような認証を介して、ＩＤ情報の受信者は、受信者が、本当に、表明されたエンティティを相手にしたネットワークベースの通信セッションに携わっていることを、適度に保証されることが可能であり、その結果、詐欺的な行為または悪意のある行為に知らずに参加する可能性が抑えられる。
【００１４】
本発明は、本明細書で「ＲｅａｌＮａｍｅレジストリ」と記述的に呼ばれるレジストリ、および関連する認証証明書（すなわち、ＲｅａｌＮａｍｅ証明書）に依拠する。各ＲｅａｌＮａｍｅレジストリは、識別情報に関する証明機関として機能する。本発明による識別情報の例には、エンティティが認識される名前、エンティティに固有のイメージ、エンティティに固有のテキスト、およびエンティティに固有のサウンドが含まれるが、以上には限定されない。ＤＮＳ（ドメイン名サーバ）および他のツールから「認証」機能を切り離すことによって、ＲｅａｌＮａｍｅレジストリは、電子メールメッセージ、ＩＭメッセージ、ウェブページなどの認証を円滑にすることの複雑さに関連して、有用な機能を達するのに有利に使用されることが可能である。
【００１５】
ドメイン名は、負荷分散、組織追跡、ウェブサイト階層などを含め、多くの機能のために使用される。これらの機能は、識別機能を扱うことを困難にする様々な要件も有する。識別に関して、レジストリが、重複する（およびほぼ重複する）識別情報のすべての問題を解決することが好ましい。明らかに、このことは、世界的な規模で行われることは不可能であり、このため、本発明の実施形態は、好ましくは、管轄権の境界を尊重する仕方で構成される。幸いなことに、この機能のためのモデル、つまり、商標レジストリが存在する。各管轄区域は、独自の商標レジストリを有し、場合により、商標の所有権を解決するための様々な規則、および提案される識別情報（例えば、名前）が既存の商標を侵害するかどうかを判定するための様々な規則を備えている。ＲｅａｌＮａｍｅレジストリは、商標レジストリと同一の仕方で効率的に機能することが本明細書で開示される。実際、ＲｅａｌＮａｍｅレジストリが、商標レジストリよりさらに分散化されていることが有利である。例えば、各管轄区域が、独自のＲｅａｌＮａｍｅレジストリを運用することが可能であり、各職業が、独自のＲｅａｌＮａｍｅレジストリを運用することが可能であり、各業界団体が、独自のＲｅａｌＮａｍｅレジストリを運用することが可能であるといった具合である。情報受信者（例えば、電子メールの受信者、ＩＭメッセージの受信者、ウェブページの受信者など）は、受信者がいずれのレジストリをインポートする気があるかを選択することができる。最低でも、情報受信者は、地元の管轄区域、および情報受信者が相手にする職業に関するＲｅａｌＮａｍｅレジストリを、通常、インポートする。このＲｅａｌＮａｍｅレジストリ構成により、ＤＮＳシステムを悩ます多くの法的争い、詐欺的な（しかし、視覚的に同一の）ドメイン名、ドメイン名所有権に関する明確な規則（例えば、ｘ−ｃｏｍｐａｎｙ Ｉｎｃ．は、ｘ−ｃｏｍｐａｎｙ ｒｏｃｋｓ．ｃｏｍサイトを所有するか）などを含め、多くの問題が回避される。
【００１６】
レジストリが整えられて、電子メールメッセージ、ＩＭメッセージ、ウェブページなどの認証が、進められることが可能である。各レジストリは、「承認された名前の証明書」の発行者として機能するとともに、「承認された」識別情報（すなわち、一般に、ＲｅａｌＮａｍｅと呼ばれる）のデータベースとしても機能する。証明書（すなわち、認証証明書）は、多くの仕方で達せられることが可能であるが、最も簡単なのは、既存のＤＮＳ／ＳＳＬのために使用されるＸ．５０９認証証明書である。Ｘ．５０９は、標準化されたＰＫＩ（公開鍵インフラストラクチャ）である。Ｘ．５０９用語において、各レジストリは、「証明機関」として機能し、各認証証明書は、実質的に、ＲｅａｌＮａｍｅおよび公開鍵を埋め込むパッケージである。次に、このパッケージに、証明機関の秘密鍵によって署名が行われる。運用の際、認証証明書は、エンティティのＩＤを強調するために役立つ実質的に任意のタイプの識別情報を含むように構成される。
【００１７】
本発明の一実施形態において、ウェブページを検証するための方法が、複数の動作を含む。複数の情報プロバイダの各プロバイダに発行された認証証明書と、これらの認証証明書のすべてに対応するルート証明書とを含む証明書レジストリを作成するための動作が、提供される。これらの認証証明書の各証明書は、その証明書のそれぞれの認証情報を、情報プロバイダの対応するプロバイダの識別情報に結び付ける。認証証明書の各証明書は、情報プロバイダの対応するプロバイダと、そのプロバイダのドメイン名情報との間のリンクを欠いている。証明書レジストリの認証証明書は、情報プロバイダが提供する情報の特定のタイプ、情報プロバイダが関連する特定の組織、情報プロバイダが携わっている特定のタイプの職業、および情報プロバイダが位置する特定の地理的区域のうち少なくとも１つに少なくとも或る程度、依存する仕方で関連する。情報受信者にルート証明書を提供するための動作が、提供される。情報受信者によってアクセスされ、さらに認証証明書が関連付けられているウェブページの検証を円滑にするための動作が、提供される。この検証は、ルート証明書の中に含まれる認証情報を使用して、関連付けられた認証証明書の真正性を検証することに成功して、関連付けられた認証証明書が、証明書レジストリに属することを検証すること、および関連付けられた認証証明書の真正性を検証することに成功した後、関連付けられた認証証明書の中に含まれる認証情報を使用して、ウェブページの指定された所有者のＩＤを検証することに成功することを含む。
【００１８】
本発明の別の実施形態において、証明書レジストリが、複数の情報プロバイダの各プロバイダに発行された認証証明書と、これらの認証証明書のすべてに対応するルート証明書とを含む。これらの認証証明書の各証明書は、その証明書のそれぞれの認証情報を、情報プロバイダの対応するプロバイダの識別情報に結び付ける。認証証明書の各証明書は、情報プロバイダの対応するプロバイダと、そのプロバイダのドメイン名情報との間のリンクを欠いている。証明書レジストリの認証証明書は、情報プロバイダが提供する情報の特定のタイプ、情報プロバイダが関連する特定の組織、情報プロバイダが携わっている特定のタイプの職業、および情報プロバイダが位置する特定の地理的区域のうち少なくとも１つに少なくとも或る程度、依存する仕方で関連する。
【００１９】
本発明の別の実施形態において、証明書レジストリシステムが、複数の情報プロバイダの各プロバイダに発行される認証証明書を発行し、さらにこれらの認証証明書のすべてに対応するルート証明書を保持するように構成される。これらの認証証明書の各証明書は、その証明書のそれぞれの認証情報を、情報プロバイダの対応するプロバイダの識別情報に結び付ける。認証証明書の各証明書は、情報プロバイダの対応するプロバイダと、そのプロバイダのドメイン名情報との間のリンクを欠いている。証明書レジストリの認証証明書は、情報プロバイダが提供する情報の特定のタイプ、情報プロバイダが関連する特定の組織、情報プロバイダが携わっている特定のタイプの職業、および情報プロバイダが位置する特定の地理的区域のうち少なくとも１つに少なくとも或る程度、依存する仕方で関連する。
【００２０】
本発明のこれら、およびその他の目的、実施形態、利点、および／または特徴は、以下の詳述、関連する図面、および添付の特許請求の範囲をさらに精査することで、直ちに明白となろう。
【図面の簡単な説明】
【００２１】
【図１】本発明による情報プロバイダ登録のための登録インフラストラクチャおよび登録プロセスを示す概略図である。
【図２】本発明による識別情報認証アプリケーションを実行するユーザデバイスによって実行される情報識別認証インフラストラクチャおよび情報識別認証プロセスを示す概略図である。
【図３ａ】本発明による識別情報認証メッセージを表示する情報受信者デバイスを示す概略図である。
【図３ｂ】本発明による識別情報認証メッセージを表示する情報受信者デバイスを示す概略図である。
【図３ｃ】本発明による識別情報認証メッセージを表示する情報受信者デバイスを示す概略図である。
【図４ａ】情報受信者デバイスに発信者認証表示を伝える方法を示す概略図である。
【図４ｂ】情報受信者デバイスに発信者認証表示を伝える方法を示す概略図である。
【図４ｃ】情報受信者デバイスに発信者認証表示を伝える方法を示す概略図である。
【図４ｄ】情報受信者デバイスに発信者認証表示を伝える方法を示す概略図である。
【図５】本発明による電子メールメッセージ認証方法の実施形態を示す流れ図である。
【図６】本発明によるＨＴＴＰページ（例えば、ウェブページ）認証方法の実施形態を示す流れ図である。
【図７】本発明によるＩＭメッセージ認証方法の実施形態を示す流れ図である。
【発明を実施するための形態】
【００２２】
本発明は、関係者が、本発明に従ってプログラミングされたデータ通信機器へのアクセスを有する誰にでも認証された識別情報を提供することを許す。識別情報の例には、エンティティが認識される名前、エンティティに固有のイメージ、エンティティに固有のテキスト、およびエンティティに固有のサウンドが含まれるが、以上には限定されない。より具体的には、識別情報の例には、エンティティの保護された名前、エンティティの保護されたイメージ、エンティティの保護されたテキスト、およびエンティティの保護されたサウンドが含まれるが、以上には限定されない。「保護された」とは、本明細書では、例えば、商標、著作権、および識別情報の他の登録形態などの管理機関手段によって、さらに／またはブランド付き識別情報（例えば、商標）を作成することによって与えられる保護を含むものと定義される。データ通信機器とは、遠隔通信ネットワークおよび／またはコンピュータネットワークを介してデータを通信するように構成されたコンピュータ機器および／または電話機器を指す。そのようなデータ通信機器の例には、電子メールメッセージを介して通信するように構成されたコンピュータ、インスタントメッセージングを介して通信するように構成されたコンピュータ、インスタントメッセージングを介して通信するように構成された電話機、ウェブページにアクセスするように構成されたコンピュータ、電子メールメッセージを送信するように構成された電話機、およびウェブページにアクセスするように構成された電話機が含まれるが、以上には限定されない。
【００２３】
本発明に従ってプログラミングされたデータ通信機器は、１つまたは複数の識別情報レジストリ（すなわち、１つまたは複数のＲｅａｌＮａｍｅレジストリ）と、１つまたは複数の情報プロバイダ認証アプリケーションとを含む。各識別情報レジストリは、情報受信者に情報プロバイダの認証を提供することを所望する情報プロバイダに関連する一意識別情報（例えば、名前、テキスト、イメージ、サウンドなど）を格納するように構成される。情報プロバイダとは、情報を受信する、さらに／または情報にアクセスするのに情報受信者が通信する相手のエンティティを指す。情報プロバイダの例には、電子メールメッセージの送信者、ＩＭメッセージの送信者、ウェブページ所有者などが含まれるが、以上には限定されない。各情報プロバイダ認証アプリケーションは、関係者によって開始されたデータ通信に関連する認証証明書を受信し、この認証証明書を使用して、その関係者の識別情報の認証を円滑にする。識別情報が認証されることに成功したか否かを示す通知が、情報受信者に伝えられる。
【００２４】
図１は、本発明による識別情報の登録のための例示的な登録インフラストラクチャおよびプロセスの概略図である。この例では、登録者１１０が、以下の３つの別々のレジストリに登録する。すなわち、レジストリ１０１が、ネットワークサービスプロバイダ１００であるＲＡ（登録機関）によって運用され、レジストリ２０１が、関係グループ（業界団体などの）であるＲＡによって運用され、さらにレジストリ３０１が、地理的区域または行政的区域（場合により、政府または他の公的エンティティ）であるＲＡによって運用される。登録者１１０は、利用可能なレジストリのいずれか１つに加入する情報受信者に認証された識別情報を提供するような方法で登録する。つまり、登録者１１０は、情報受信者が、利用可能なレジストリの１つまたは複数に、この例では、レジストリ１０１、２０１、または３０１に加入している場合に限って、情報受信者に対して認証されることが可能である。
【００２５】
各レジストリは、それぞれのＲＡによって運用される。レジストリを運用することは、本明細書では、レジストリの中に含まれる情報を保持することを含むように定義される。ＲＡは、識別情報レジストリを提供することに関心がある任意の公的組織または私的組織であることが可能である。ＲＡは、運用するのにいずれの当局からの承認も要さないが、これらの当局による公認を求めることも可能である。エンドユーザ、サービス供給業者、および／または機器供給業者は、信頼できる所与のレジストリが存在するかどうかを判定して、信頼できると判定されたレジストリだけに加入することが可能である。各レジストリは、２つの主要な部分、すなわち、ＲＡ（Ｘ．５０９用語において証明機関）、および識別情報のデータベースから成る。各レジストリは、所定の加入者グループ、地域、および／または事前定義された関係グループにサービスを提供する。１つのレジストリによってサービスを提供される地域が、別のレジストリによってサービスを提供される地域と重なり合うことも可能であり、さらに２つ以上のレジストリが、同一の地域にサービスを提供することも可能である。同様に、異なる２つ以上の定義された関係グループが、重なり合うことが可能である（例えば、医者と、より狭く定義された、小児科医の関係グループ）。
【００２６】
レジストリ１０１は、任意の企業、公的組織または政府組織に、認証された情報プロバイダサービスを提供することを所望するネットワークサービスプロバイダ１００によって、またはネットワークサービスプロバイダ１００によってサービスを提供される情報受信者に、認証された識別情報を提供することを所望する他の登録者１１０によって保持される。レジストリ２０１は、例えば、Ｃａｎａｄｉａｎ Ｂａｎｋｅｒｓ Ａｓｓｏｃｉａｔｉｏｎ（Ｒ）などの関係グループ２００によって運用され、この関係グループは、レジストリ２０１を保持して、このグループの銀行メンバに、認証された識別情報および／または関連するサービスを提供する。レジストリ３０１は、例えば、ニューヨーク州、オンタリオ州、トロント市、シカゴ市とその周辺などの地理的区域または行政的区域に関連付けられ、対応する政府機関または他の公的エンティティ３００によって保持される。
【００２７】
一実施形態において、ＲＡ１００、２００、または３００が負う唯一の責任は、任意の登録者１１０のＩＤの証明を確実にするとともに、ＲＡ１００、２００、または３００が、異なる登録者１１０に関して重複する識別情報を登録しないことを確実にすることだけである。この実施形態において、レジストリ１０１（データベースおよびＲＡから成る）は、一般の人々によって自由に検査されることが可能であり、紛らわしく類似した、または誤解を招く情報プロバイダＩＤが、別の登録者１１０によって登録されないことを確実にするために、レジストリ１０１、２０１、および３０１を監視することは、少なくとも或る程度、登録者１１０、および他の関係者の責任である。登録者１１０が、登録されると、ＲＡは、認証証明書１０４を発行する。この認証証明書は、登録された情報プロバイダＩＤ（すなわち、識別情報）が、登録者の公開鍵に結合されていることを認定し、そしてこの公開鍵は、登録者の秘密鍵と暗黙に対にされている。
【００２８】
登録プロセス
レジストリによって各登録者１１０に提供される認証証明書１０４は、知られている任意の認証システムに適合することが可能であり、さらに各レジストリは、本発明の範囲を逸脱することなしに、異なる認証システムを使用することができる。登録者のＩＤ情報が、レジストリの中に記録されると、情報プロバイダ認証が実行されることを許す認証証明書が、登録者１１０に提供される。この認証証明書は、Ｘ．５０９のような任意の公開鍵インフラストラクチャスキームに基づくことが可能である。
【００２９】
Ｘ．５０９が、登録者１１０に提供される認証証明書のために使用される場合、本発明の一実施形態では、登録プロセスは、以下のとおり、進む（すなわち、例としてＲＡ１００を使用して）。
【００３０】
１）ＲＡ１００が、ＲＡ１００のルート証明書の中でＲＡ１００の公開鍵を公開する。ルート証明書は、レジストリ（すなわち、証明）機関の公開鍵を有する証明書である。この公開鍵は、認証証明書を検証するのに使用され、したがって、ルート証明書は、情報プロバイダ認証を実行する各デバイスの中にインポートされなければならない。通常、データ通信機器のベンダまたは所有者は、ウェブブラウザに、現在、ＰＫＩルート証明書が事前ロードされるのと同じように、地元地域のレジストリ、すべての一般的な業界レジストリおよび職業レジストリなどを含む、関心対象のルート証明書を事前ロードするものと想定される。オプションとして、エンドユーザが、複数の地域においてビジネスを行う、または特化されたレジストリに感心がある場合において、エンドユーザが、さらなるルート証明書をインポートすることを許す方法が、存在する。当業者には理解されるとおり、いくつのルート公開鍵が、インポートされることが可能であるか、またはそのようなインポートを許すための手段に制限は、まったく存在しない。
【００３１】
２）登録者１１０になることを所望する各関係者（すなわち、レジストリ申請者）が、その関係者独自の公開鍵／秘密鍵ペアを生成し、その公開鍵を、その関係者の識別情報および他の要求される登録情報および／または登録ドキュメンテーションと一緒に、ＲＡ１００にサブミットする。
【００３２】
３）ＲＡ１００が、関係者が、その識別情報を実際に所有している、またはそれ以外で合法的に保有していると判定した場合、ＲＡ１００は、その識別情報をデータベース１００に入力し、ＲＡ１００の秘密鍵を使用して、登録者の識別情報と、登録者の公開鍵とを含む認証証明書に署名する。したがって、ＲＡ１００は、登録者の公開鍵が、登録者の識別情報に結合された公開鍵に「他ならない」こと、およびその登録者が、その識別情報を使用する資格があることを「請け合う」。
【００３３】
４）登録者１１０は、この時点で、登録者１１０の識別情報を証明する署名された認証証明書を有し、さらに登録者１１０は、登録者１１０が、その認証証明書を検証することを許す秘密鍵も有する。認証証明書の意味は、限られていることを理解されたい。認証証明書は、秘密鍵の保持者（登録者１１０であるべき）が、登録者１１０が登録した特定の登録機関１００の管轄区域内で、この保持者の識別情報を表示させる資格があることを意味するに過ぎない。
【００３４】
情報プロバイダ認証
図２は、本発明による情報プロバイダ認証構成の実施形態を示す。情報受信者ユーザデバイス（すなわち、デバイス１２０ａ）が、情報プロバイダ認証を実行する。デバイス１２０ａの例には、電子メールメッセージを介して通信するため、インスタントメッセージングを介して通信するため、および／またはウェブページにアクセスするように構成されたパーソナルコンピュータまたはＩＰ（インターネットプロトコル）電話機などのデバイスが含まれるが、以上には限定されない。デバイス１２０ａは、本発明による非常にセキュリティの強い形態の情報プロバイダ認証を可能にする情報プロバイダ認証アプリケーション１２２を備える。このセキュリティは、情報受信者が、認証アプリケーション１２２を直接に制御／監督していること、つまり、情報受信者が、情報受信者自らのデバイスを信頼するだけでよいことに由来する。他の実施形態では、サービス（ウェブ／電子メール／ＩＭ）に依存して、プロキシにおいて認証を実行することが可能である。しかし、そのような構成は、多くの攻撃の道を開き、セキュリティを強くすることをはるかに困難にする。したがって、情報プロバイダ認証アプリケーション１２２を備えたデバイス１２０ａが、「エンドツーエンド」方式で実施されるべき識別情報認証を有利に提供することを見て取ることができる。
【００３５】
やはり図２を参照して、登録者１１０が、デバイス１２０ａによって受信されるように、提供される情報の伝送を開始すると、そのような情報伝送（１ａ）は、当技術分野でよく知られた仕方でデータ通信ネットワークを介して進められる。そのような情報伝送の例には、電子メールメッセージを伝送すること、ＩＭメッセージを伝送すること、ウェブサイトコンテンツを伝送すること、ウェブページを伝送すること、およびデータ通信ネットワークまたは遠隔通信ネットワークを介する他の情報伝送形態が含まれるが、以上には限定されない。提供される情報を伝送することと一緒に、登録者デバイス１１０に、デバイス１２０ａによって受信されるようにデバイス１１０の認証証明書を送信させるための情報プロバイダ認証対話（２ａ）が、開始される。情報がウェブページである場合において、この対話は、デバイス間のダイアログである。電子メールまたはＩＭメッセージの場合において、この対話は、情報の伝送を含むが、電子メールシステムまたはＩＭシステムにおける片方、または両方の終端デバイスが、オフラインである可能性があるので、２つのデバイス間のダイアログではない可能性がある。提供される情報、および認証証明書は、データネットワークまたは通信ネットワークを介してデータを通信するために適切に構成された、知られている通信プロトコルの同一のプロトコル、または異なるプロトコルを使用して伝送されることが可能である。認証証明書を受信することに応答して、情報プロバイダ認証アプリケーション１２２は、登録者デバイス１１０を相手に認証対話を行い、この認証対話中に獲得された認証証明書の真正性を検証する。情報プロバイダ認証は、レジストリ１０１、２０１、３０１のクエリを要求しないことを理解されたい。登録者デバイス１１０は、提供される情報の伝送を円滑にするために使用されるのと同一の機器であることも、異なる機器（例えば、同一のサーバ、または異なるサーバ）であることも可能であることが、本明細書で開示される。判定されると、次に、認証プロセスの結果は、図３ａから図３ｃ、および図４ａから図４ｄに関連して後段で説明されるとおり、デバイス１２０ａに伝送される（３ａ）。
【００３６】
本発明による認証アプリケーションは、好ましくは、ただし、必然的にではなく、ユーザデバイス上に存在する。このことは、ユーザが、遠隔デバイスではなく、ユーザのデバイスを信頼するだけでよいことを意味する。サービス（例えば、ウェブ、電子メール、ＩＭなど）に依存して、プロキシにおいて認証を実行することが可能である。しかし、このことは、多くの攻撃の道を開き、認証プロセスのセキュリティを強くすることをはるかに困難にする。したがって、本明細書で開示される認証の「エンドツーエンド」アプローチは、有利である。
【００３７】
図３ａから図３ｃは、本発明の一実施形態による、情報受信者に伝えられる情報プロバイダ認証メッセージの例を示す。これらの例において、表示される情報プロバイダ認証メッセージは、識別情報が認証されることに成功したかどうかを示す情報、識別情報（オプションとして、ロゴなど）を示す情報、および情報プロバイダが、レジストリ１０１、２０１、３０１のいずれのレジストリに登録したかを示す情報を含む。
【００３８】
図３ａは、認証されることに成功した識別情報に関する例示的な表示フォーマット１３０ａを示す。表示フォーマット１３０ａの第１の行は、この識別情報が認証されることに成功したことを示す。表示フォーマット１３０は、デバイス１２０のビジュアルディスプレイ１４０上で提供される。示されるとおり、表示フォーマット１３０ａは、ビジュアルディスプレイ１４０の相当な領域を包含する。しかし、他の実施形態（図示せず）では、表示フォーマット１３０ａは、ビジュアルディスプレイ１４０の限られた領域を包含する。表示１３０ａの第２の行は、認証された識別情報を表示する。この表示の最後の行は、この例では、カリフォルニア州に関連するレジストリである、ＲＡの名前を表示する。
【００３９】
図３ｂは、認証が失敗したために認証されることが可能でなかった情報プロバイダに関する例示的な表示フォーマット１３０ｂを示す。当業者には理解されるとおり、情報プロバイダ認証は、いくつかの理由のいずれの理由でも失敗する可能性がある。例えば、情報プロバイダは、情報プロバイダが、対応する秘密鍵を有さない盗まれた認証証明書を提示する可能性がある、認証証明書は、ユーザデバイスに知られていないレジストリからである、認証証明書は、ＣＡの公開鍵を使用して検証されることが可能でない、通信障害が、生じた可能性がある、認証対話が、中断された可能性がある、など。表示１３０ｂの第１の行は、情報プロバイダ認証が失敗したために、情報プロバイダが認証されることに成功しなかったことを示す。表示１３０ｂの第２の行は、認証証明書の中に含まれる識別情報を、利用可能な場合、表示する。表示１３０ｃの最後の行は、認証証明書の中に含まれるレジストリの名前を、利用可能な場合、表示する。認証が失敗したということをさらにハイライトするのに、メッセージは、明るい色で、例えば、赤などで表示されることが可能である。
【００４０】
図３ｃは、情報プロバイダが認証証明書を提示しないために認証されることが可能でなかった情報プロバイダに関する例示的な表示フォーマット１３０ｃを示す。表示１３０ｃの第１の行は、情報プロバイダが、認証を試みていないことを示し、残りの行は、示されるとおり、空白であることが可能であり、あるいは識別情報を表示することが可能であり、その場合、認証が試みられていないということが、認証サービスなしのメッセージをハイライトする、または点滅させることによって強調されなければならない。
【００４１】
当業者には理解されるとおり、表示フォーマット１３０ａ−１３０ｃは、必ずしも実際的、または情報受信者によって所望されるというわけではない。例えば、パーソナルコンピュータの場合において、ビジュアルディスプレイのサイズは、通常、認証結果の視覚的提示に関して制限要因ではない。しかし、セルラー電話機、パーソナルデジタルアシスタント、ハンドヘルドコンピュータなどのハンドヘルドデバイスのビジュアルディスプレイのサイズは、認証結果の視覚的表示における制限要因である可能性がある。したがって、認証プロセス結果を示す他の形態が、そのような結果を伝えるために使用され得ることが、企図される。図４ａから図４ｄは、認証プロセス結果を、そのような結果を情報受信者に伝えるために示す代替の形態を示す。図４ａから図４ｄに示される例は、或る特定のタイプのデバイス１４０（すなわち、セルラー電話機）を示すものの、認証プロセス結果を示す他のそのような形態が、ほとんどの知られているタイプのデータ通信デバイスに伝えられることが可能であることを理解されたい。
【００４２】
図４ａに示されるとおり、一実施形態では、情報プロバイダ認証または認証失敗は、メッセージ受信通知信号が、デバイス１４０ａから出力されるのと同時に、または出力された後に、出力される帯域外メッセージを使用して、情報受信者デバイスを介して伝えられることが可能である。一実施形態では、ビジュアルメッセージが、デバイス１４０ａのビジュアルディスプレイ１４２ａ上で出力される。別の実施形態では、ＳＭＳ（ショートメッセージサービス）メッセージが、認証プロセスを実行するサーバからデバイス１４０ａに送信され、そのＳＭＳメッセージは、ビジュアルディスプレイ１４２ａ上で視覚的に表示される。表示されるビジュアルメッセージは、図４ａに示される、情報プロバイダが認証されている（Ａ）、または図示されない、認証されていない（ＮＡ）という指示１５０、および情報プロバイダＩＤ（例えば、「カリフォルニア州の銀行」）を含む。
【００４３】
図４ｂに示されるとおり、別の実施形態では、情報受信者が、対応する提供される情報にアクセスすると、帯域内の可聴メッセージが、デバイス１４０ｂの可聴出力手段を介して出力されることが可能である。この可聴メッセージは、情報プロバイダが、認証されることに成功したか否かを示す。この可聴メッセージは、情報受信者が、そのようなアクセスを実行した後に、ただし、提供される情報が提示される前に出力されることが可能であり、したがって、情報プロバイダは、この可聴メッセージを偽造することができない。この実施形態では、情報受信者は、情報プロバイダが、認証されることが可能であったか、可能でなかったかを示す可聴メッセージ１５２を受け取る。
【００４４】
図４ｃに示されるとおり、別の実施形態では、特有の呼び出し音が、デバイス１４０ｃの可聴出力手段によって出力される。１つの呼び出し音１５４は、認証された情報プロバイダを示し、別の呼び出し音（図示せず）は、識別情報が認証されることが可能でなかったことを示す。
【００４５】
図４ｄに示されるとおり、さらに別の実施形態では、識別情報が認証されたかどうかを示すイメージ１５６（例えば、．ｊｐｅｇイメージ）が、デバイス１４０ｄに送信される。この実施形態では、イメージ１５６は、識別情報が認証されることが可能でなかったことを、失敗した認証に対応する詐欺的な／悪意のある行為（例えば、フィッシング）を示すイメージであることによって示す。別のイメージ（図示せず）が、識別情報が認証されることに成功した状況を示すのに使用される。
【００４６】
次に提示されるのは、様々な特定のタイプの通信媒体に適用される、本発明による認証を円滑にすることの開示である。これらの通信媒体の例には、電子メール、ＩＭメッセージ、およびウェブページが含まれるが、以上には限定されない。以下は、電子メール、ＩＭメッセージ、およびウェブページの文脈においてメッセージ認証を個々に円滑にするための特定のアプローチの実施形態である。詐欺的な行為、および悪意のある行為は、しばしば、通信媒体の組合せを介して実行されることが、当業者には認められよう。例えば、フィッシング行為は、しばしば、偽装された、または紛らわしい送信者情報を有する電子メールメッセージを介して「餌を見せ」、さらに信頼できるエンティティのウェブページであると偽って称するウェブページを介して「釣り針を仕掛ける」。釣り針を仕掛けることは、例えば、銀行口座情報などの機密性の高い情報を獲得して、口座からの資金の許可のない引き出しを可能にすることを、しばしば、含む。したがって、本発明による、様々な通信媒体の文脈における、メッセージ認証を円滑にするためのアプローチは、例えば、ＶｏＩＰを介するフィッシング、ビジネス−ビジネス間認証、スパムフィルタリング、電子メール偽造、ウェブページ偽造、ウェブページフィッシング、ＩＭセッションハッキングなどの詐欺的な行為および／または悪意のある行為に対抗する目的で、個々に、または組合せで有利に実施されることが可能であることが、本明細書で開示される。
【００４７】
電子メール認証
ＳＭＴＰ（簡易メール転送プロトコル、ＲＦＣ２８２１）が、現在、圧倒的に支配的な電子メールプロトコルである。したがって、電子メールメッセージ認証は、ＳＭＴＰに関して本明細書で説明される。しかし、電子メールメッセージ認証を円滑にするために特別に構成される本発明の実施形態は、すべてではないにしても、ほとんどの電子メールメッセージングプロトコルに準拠して構成されることが可能であることが、当業者には認められよう。
【００４８】
本発明によれば、電子メールメッセージ認証を円滑にすることは、メッセージ送信者（すなわち、情報プロバイダ）が、認証証明書を使用して電子メールに署名しなければならないことを含む。より厳密には、メッセージ送信者は、認証証明書の中に埋め込まれた公開鍵に対応する秘密鍵を使用して、電子メールメッセージに署名する。電子メールメッセージが、秘密鍵を使用して署名されていることに鑑みて、この署名された電子メールメッセージの受信者は、公開鍵を使用して、この電子メールメッセージの中に含まれる識別情報を認証することができる。
【００４９】
ＳＭＴＰは、ＳＭＴＰを使用して伝送されるメッセージ内に含まれるコンテンツの認証を、円滑にするのを困難にする多くの独特の機能上の考慮点を有する。１つのそのような考慮点は、電子メールが、蓄積交換システムであることである。電子メールメッセージの送信者と受信者の間に最低で２つのＭＴＡ（メール転送エージェント）が、存在し、各ＭＴＡは、異なるプログラムの異なるバージョンを実行している。ＭＴＡは、基本的に、ｓｅｎｄｍａｉｌアプリケーションまたはｐｏｓｔｆｉｘアプリケーションを実行しているメールサーバである。電子メールメッセージの送信者と受信者の間に６つ以上のＭＴＡがそこに存在することも珍しくない。ＳＭＴＰは、各ホップ上のＭＴＡのペア間の対話だけしか許さない。送信者と受信者は、同時にオンラインであることが決してない可能性もあり、このことは、エンドツーエンド認証の選好が存在する場合、対話を完全に不可能にする。
【００５０】
例えば、ＳＭＴＰなどの電子メールメッセージングプロトコルに準拠する各電子メールは、いくつかの「ヘッダ」行を有する。ＳＭＴＰ，ＭＩＭＥなどに関する標準の中で指定された多くのヘッダが、存在する。また、誰でも任意の理由で加えることができる拡張ヘッダも存在する。例えば、Ｘ−Ｓｃａｎｎｅｄ−Ｂｙが、悪意のあるソフトウェアスキャナによって加えられる一般的なヘッダであり、Ｘ−Ｍａｉｌｅｒが、いずれのソフトウェアが送信元ＭＵＡであったかを示す別のヘッダである。そのようなヘッダの存在は、そのようなヘッダを含む電子メールメッセージがクリーンであることは保証しないことが、当業者には認められよう。例えば、ヘッダは、悪意のある目的で或るエンティティによって、または旧バージョンのスキャナを有するエンティティによって追加されていることも可能である。我々は、追加の２つのヘッダ、Ｘ−ＲｅａｌＮａｍｅ−ＣｅｒｔｉｆｉｃａｔｅおよびＸ−ＲｅａｌＮａｍｅ−Ｃｈｅｃｋｓｕｍが、それぞれ、証明書、および署名されたチェックサムを含むことを提案している。また、これらのヘッダを組み合わせて単一のヘッダにすることも可能である。
【００５１】
各ＭＴＡは、新たなヘッダ行を挿入し、さらにいくつかのヘッダ行を書き換えることになっている。このことは、チェックサムが、最初に送信されたとおり、単純に電子メールにわたるだけではあり得ないことを意味する。さらに悪いことには、電子メールメッセージ本文が、いくつかの理由で変更される可能性がある。そのような変更の一例は、行の先頭における「Ｆｒｏｍ」を「＞Ｆｒｏｍ」に変えることである。別の例は、一部のＭＴＡ、および一部のＭＵＡ（例えば、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ（ＴＭ）のようなユーザプログラムに不可欠なメールユーザエージェント）が、行の長さ、およびその他の理由でメッセージを不適切に分割することである。
【００５２】
ＭＩＭＥ（多目的インターネットメール拡張）は、とりわけ、「並行」ビューおよび／または「代替」ビューを含むことが可能なマルチパートメッセージを定義するＳＭＴＰの拡張である。ＭＵＡは、メッセージのいずれの部分を表示するかに関する様々な規則を有する。一部のスパム電子メールメッセージは、意図的に、複数の部分、すなわち、ＡＳＣＩＩにおける１つの部分、およびＨＴＭＬにおける１つの部分を有する本文を有して送信される。その意図は、スパムフィルタが、ＡＳＣＩＩ部分に基づいてフィルタリングを行い、電子メールプログラム（すなわち、ＭＵＡ）が、ＨＴＭＬ部分を表示することである。
【００５３】
したがって、電子メールメッセージ認証を円滑にするように構成された本発明の実施形態は、例えば、反射攻撃や中間者攻撃などの偽造戦術に耐性のあるロバストな電子メールメッセージ認証を依然として実行しながら、これらの独特の機能上の考慮点に対処しなければならない。この目的で、本発明の一実施形態では、図５に示される電子メールメッセージ認証方法２００が、電子メール対応の情報プロバイダデバイスと電子メール対応の情報受信者デバイスによって共同で実施される。
【００５４】
１．図５を参照すると、チェックサム動作２０２が、マルチパート電子メールメッセージ（すなわち、元の電子メールメッセージ）の各部分に対して実行される。このチェックサム動作は、電子メールメッセージコンテンツのすべてまたは一部分に依存するチェックサム（すなわち、計算された値）をもたらす。このチェックサム動作は、好ましくは、例えば、ＳＨＡ−１（セキュアハッシュアルゴリズム１）などの暗号の強固なハッシュを適用することを含む。非テキストであるメッセージの部分は、これらの非テキスト部分に対して、符号化された形態においてチェックサム動作が実行されることを許す適切な仕方で符号化される。
【００５５】
単一パート電子メールの本文、および「テキスト」である部分（ＨＴＭＬおよびその他を含む）を含め、元の電子メールメッセージのテキスト部分のチェックサムを行うのに、好ましくは、実行されるいくらかの処理が、存在する。この処理は、本明細書で「正規化」と呼ばれる。正規化の目的は、メールプログラムによって行われるすべての変更の下で変化しないが、それでも、メッセージの中に見えるすべてのテキストを見られるとおりに保持するメッセージ本文部分を生成することである。そのようなメールプログラムは、例えば、電子メールメッセージを作成するため、送信するため、および受信するために使用されるＭｉｃｒｏｓｏｆｔ（ＴＭ）Ｏｕｔｌｏｏｋ（ＴＭ）などのアプリケーションである。正規化は、さらなる処理を必然的に伴うが、認証アプリケーションの論理を有利に単純化することができる。
【００５６】
一実施形態では、正規化は、好ましくは、空白、タブ、バックスペース、行末文字などのすべての白のスペースを除去することを含む。異なるオペレーティングシステムは、異なる行末規則を有し、したがって、我々は、すべての＜ｃｒ＞および＜ｌｉｎｅｆｅｅｄ＞を白のスペースとして扱うことに留意されたい。行の先頭に「＞」文字があれば、やはり除去される。別のアプローチは、白のスペースのそれぞれの隣接するシーケンスを圧縮して、単一の空白にし、最小限の費用で人間による可読性を向上させることである。さらに、電子メールメッセージ本文がＡＳＣＩＩになっていることは必須ではない。他の文字符号化（例えば、ＥＢＣＤＩＣ）における電子メール、または任意のバイナリファイルさえ、これらがＡＳＣＩＩになっているかのように、正規化されることが可能である。代替として、元の電子メールメッセージ（例えば、イメージ部分）の符号化された部分が、必要に応じて、適宜、正規化を受けることも可能である。
【００５７】
２．元の電子メールメッセージから指定されたヘッダ情報を抽出するためのヘッダ抽出動作２０４が、実行される。そのような抽出されるヘッダ情報の例には、「ｆｒｏｍ：」アドレスおよび「ｒｅｐｌｙ−ｔｏ：」アドレス、「ｍｅｓｓａｇｅ−ＩＤ：」が含まれるが、以上には限定されない。電子メールメッセージが、そのような抽出されたヘッダ情報のすべてのカテゴリを有さない場合において、単一の空白、または他の適切な表現が、欠落しているカテゴリを表すために使用されることが可能であることに留意されたい。「Ｄａｔｅ：」ヘッダの中で指定される日付が、抽出されるべき指定されたヘッダ情報の別の例である。この日付は、いずれの時間帯にあることも可能であるため、例えば、ＵＣＴまたは現地時間などの規定された時間帯にこの日付を標準化することが有用である。
【００５８】
３．元の電子メールメッセージの様々な部分に対して必要なチェックサム（正規化を伴っても、伴わなくても）および抽出が実行された後、すべてのチェックサムおよびヘッダ（すなわち、チェックサムコレクション）を単一の構造に組み立てるための動作２０６が、実行される。この単一の構造は、本明細書で、組み立てられたチェックサムコレクション構造と定義される。組み立てられたチェックサムコレクション構造の一実施形態は、以下のフォーマット、すなわち、「ｆｒｏｍ：＜ｔｈｅｆｒｏｍａｄｄｒｅｓｓ＞、ｒｅｐｌｙ−ｔｏ：＜ｔｈｅｒｅｐｌｙａｄｄｒｅｓｓ＞、ｄａｔｅ：＜ｄａｔｅ＞、ｂｏｄｙ：＜ｂｏｄｙｃｈｅｃｋｓｕｍ＞、ｐａｒｔ １：＜ｐａｒｔ１ｃｈｅｃｋｓｕｍ＞など」を有するコンテンツフィールド文字列である。ＭＩＭＥマルチパート処理に関して、部分の命名および順序付けは、いくつかの部分が、複数の名前（「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：」における名前、「Ｃｏｎｔｅｎｔ−Ｄｉｓｌｏｓｉｔｉｏｎ：」における名前）を有し、他の部分が、まったく名前を有さない可能性があるため、扱いが難しくなる可能性があることに留意されたい。オプションとして、メッセージｉｄは、この構造の中に含められることも可能である。このようにして、マルチパート電子メールメッセージの通常に目に見える部分のすべて、ならびに日付および送信者アドレスが、チェックサムコレクションの中に（直接に、またはチェックサムを介して間接的に）含められる。このことは、署名が、他の本文のために再使用されることが不可能であることを意味し、実際、反射攻撃を防止する。
【００５９】
４．組み立てられたチェックサムコレクション構造を作成することに応答して、組み立てられたチェックサムコレクション構造に関するチェックサムを算出して、第２のレベルのチェックサム構造（すなわち、チェックサムコレクション構造のチェックサム）を生成するための動作２０８が、実行される。
【００６０】
５．第２のレベルのチェックサム構造を算出した後、情報プロバイダの認証証明書に対応する秘密鍵を使用して第２のレベルのチェックサム構造に署名して、署名されたチェックサムを生成するための動作２１０が、実行される。この第２のレベルのチェックサム構造は、帯域幅を最小限に抑える最適化を可能にする。チェックサムコレクションは、場合により、例えば、約数百バイトである。第２のチェックサム構造は、例えば、約２０バイトである。第２のレベルのチェックサム構造を送信することにより、チェックサムコレクションが、伝送される必要はなく、帯域幅利用率が低減される。ＲＳＡ公開鍵署名は、開始するのが比較的遅く、メッセージが長いほど、この署名も遅い。チェックサムコレクションは、チェックサムを計算して、チェックサムだけに署名する方が速いほど十分に長い。
【００６１】
６．署名された第２のレベルのチェックサム構造を生成した後、元の電子メールメッセージの新たなヘッダの中に、署名された第２のレベルのチェックサム構造、および対応する認証証明書を挿入して、署名された電子メールメッセージ（すなわち、本発明による認証証明書によって署名されたメッセージ）を作成するための動作２１２が、実行される。電子メールの元の部分は、変更されず、署名されたチェックサムおよび認証証明書は、認証の目的で追加のヘッダ行として挿入される。受信者が認証したいと思わない場合、受信者デバイスは、これらの追加のヘッダを単に無視する。
【００６２】
７．情報受信者デバイスによって受信されるように情報プロバイダデバイスから、署名された電子メールメッセージを伝送するための動作２１４が、実行され、さらに、これに相応して、その署名された電子メールメッセージを受信するための動作２１６が、情報受信者デバイスによって実行される。
【００６３】
８．受信者が、署名された電子メールメッセージを受信した受信機において、認証証明書、および署名された第２のレベルのチェックサム構造にアクセスする（例えば、これらを抽出する）ための動作２１８が、実行される。
【００６４】
９．認証証明書にアクセスすることに応答して、認証証明書の有効性を検証するための動作２２０が、実行される。好ましくは、そのような有効性は、Ｘ．５０９ ＰＫＩに従って検査される。より具体的には、そのような検証することは、受信者が、レジストリのルート証明書を有することを確認すること、認証証明書が、レジストリによって適切に署名されていることを確認すること、有効期間を調べて、その証明書が失効していないことを確かめること、および取り消しリストを調べて、その証明書が取り消されていないことを確かめることを含む。
【００６５】
１０．証明書が検証された後、署名された第２のレベルのチェックサム構造が、認証証明書に対応する秘密鍵によって正しく署名されていることを検証するための動作２２１が、実行される。
【００６６】
１１．認証証明書の有効性、および第２のレベルのチェックサム構造の署名を検証することに成功することに関連して（例えば、応答して）、電子メールメッセージから、組み立てられたチェックサムコレクション構造を再現するための動作２２２が、実行される。
【００６７】
１２．組み立てられたチェックサムコレクション構造を再現した後、この再現された、組み立てられたチェックサムコレクション構造から第２のレベルのチェックサム構造を算出するための動作２２４が、実行される。このことは、動作２０２から２０８の機能と同一の機能を実行することを必然的に伴う。
【００６８】
１３．次に、ヘッダから取り出されたチェックサムを、再現された、組み立てられたチェックサムコレクション構造に関するチェックサムと比較するための動作２２６が、実行される。再現されたチェックサムコレクション構造に関するチェックサムが、取り出されたチェックサム（すなわち、署名されたチェックサム）と合致する場合、電子メールは、真正であるものと考えられる。署名は、認証証明書に照らして検証され、受信者によって検査されるため、中間者攻撃の懸念は、解消されないとしても、大幅に小さくなる。
【００６９】
１４．組み立てられたチェックサムコレクション構造の署名を検証すること（例えば、認証証明書内に含まれる識別情報を介して）に応答して、署名が検証されることに成功したか否かを示す認証通知を与えるための動作２２８が、実行される。
【００７０】
表面上、この電子メールメッセージ認証方法は、多少、複雑であるように見える可能性がある。しかし、この方法は、メールを送受信する際にＭＵＡ／ＭＴＡによって通常、行われる電子メール本文をコピーすることと並行して、複数のチェックサム動作を実行することによって、最小限の処理時間で達せられることが可能である。さらに、最新の電子メールサーバは、通常、ウイルススキャンを行い、これと比較して、この電子メールメッセージ認証方法は、比較的単純である。
【００７１】
要するに、本発明による電子メールメッセージ認証は、送信者機能、ＭＴＡ機能、および受信者機能を含む。送信者機能は、元の電子メールメッセージのコンテンツに関するチェックサムを計算すること、チェックサムコレクション構造を生成するために、チェックサムおよび電子メールメッセージコンテンツを単一の構造に組み立てること、組み立てられたチェックサムコレクション構造に関するチェックサム（すなわち、第２のレベルのチェックサム構造）を計算すること、認証証明書に対応する秘密鍵を使用して第２のレベルのチェックサムに署名すること、署名された第２のレベルのチェックサム構造をそれぞれのヘッダ（例えば、ｘ−ＲｅａｌＮａｍｅ−ｃｈｅｃｋｓｕｍ）の中に入れ、認証証明書をそれぞれのヘッダ（例えば、ｘ−ＲｅａｌＮａｍｅ−ｃｅｒｔｉｆｉｃａｔｅ）の中に入れることを含む。ＭＴＡ機能は、各ＭＴＡが、ヘッダをそのままにしておく必要があることを含み、このことは、ほとんどのＭＴＡソフトウェアに関してデフォルトの機能である。受信者機能は、それぞれのヘッダから認証証明書、および署名された第２のレベルのチェックサム構造を抽出すること、証明書が有効である（すなわち、ＣＡによって正しく署名されている、失効していない、取り消されていない）ことを確認すること、証明書の中の公開鍵を使用して、署名された第２のレベルのチェックサムが、正しく署名されていることを確認すること、チェックサムコレクション構造に関するチェックサムの自らのバージョンを計算して、チェックサムの２つのバージョンを比較することを含む。署名された第２のレベルのチェックサム構造は、平文で現れ、このことは、暗号の強固なハッシュ関数（例えば、ＳＨＡ−１）が、ハッシュされて、その所与のチェックサムコレクション構造になる別の文字列を見出す実行可能な方法が存在しないことを意味するため、許容できることに留意されたい。この認証方法は、ＭＴＡソフトウェア変更がない（すなわち、展開するのが容易である）という利点、エンドツーエンドの展開という利点を有し、セキュリティのための登録にだけ依拠し、厳密な標準に従わないＭＴＡ／ＭＵＡに対しても機能する。
【００７２】
代替の一実施形態では、チェックサムのレベルが、よりかさばるヘッダ行が伝送されるという犠牲を払って、節約される。この代替は、チェックサムコレクション構造に直接に署名する（例えば、認証証明書に対応する秘密鍵を使用して）ことを、この構造に関する第２のレベルのチェックサム構造に署名するのではなく、行うことである。そのような代替の実施形態において、情報受信者デバイスは、チェックサムコレクション構造を解読する（例えば、認証証明書の中の公開鍵を使用して）ことを、この構造のチェックサムを確認することではなく、行う。このため、符号化されたチェックサムコレクション構造の実施形態には、認証証明書に対応する秘密鍵によって署名されている、組み立てられたチェックサムコレクション構造、および暗号化されている、組み立てられたチェックサムコレクション構造が含まれるが、以上には限定されないことが本明細書で開示される。
【００７３】
別の代替の実施形態では、第２のレベルのチェックサム構造に署名することは、省略され、組み立てられたチェックサムコレクション構造に署名が行われる。
【００７４】
別の代替の実施形態において、認証証明書は、電子メールヘッダ行の中で直接には供給されず、間接的にアクセスされる。認証証明書は、かさばる可能性があり、各送信者／受信者デバイスペアは、時とともに複数の電子メールを送信する可能性が高いため、同一のかさばる証明書を多数回、送信するのを回避することとともに、必須の検証を回避することが有利である。このことは、完全な証明書の代わりに、証明書へのポインタ（例えば、ＵＲＬ）を挿入することによって行われることが可能である。次に、受信デバイスは、指定された認証証明書をフェッチし、後の使用のために、この証明書をキャッシュすることができる。このため、認証証明書と、認証証明書が、或る特定のソースからアクセスされることを可能にするポインタなどの手段とはともに、本発明による認証証明書情報の例である。また、要求される認証証明書を指定することの、この「間接的」アプローチは、本発明によるウェブページ認証に関しても有用であることも認められよう。
【００７５】
さらに別の代替の実施形態において、チェックサム構造（第２のレベルのチェックサム構造、または組み立てられたチェックサムコレクション構造）は、署名されるのではなく、暗号化される。そのような実施形態において、暗号化されたチェックサムは、ヘッダの中に挿入され、受信者は、署名を検査するのではなく、暗号化されたチェックサムを解読しなければならない。メッセージの平文が、署名の動作の後でさえ目に見えるままであるのに対して、メッセージの平文は、暗号化の動作の後、読み取り不能になる。署名すること、および暗号化することは、エンティティが、証明書に対応する秘密鍵を有することを証明し、したがって、エンティティのＩＤを証明することを目的とする符号化の例であることが、本明細書で開示される。署名の有効性を検証すること、および解読することは、そのような符号化された情報を復号することの例であり、さらに、許可された関係者によって実行された場合、符号化された情報のセキュリティで保護された通信を可能にする。したがって、署名するため、および署名を検証するために実行される本明細書における動作、および関連する機能は、それぞれ、暗号化するため、および解読するための動作、および関連する機能で置き換えられることが可能であることが、本明細書で開示される。
【００７６】
チェックサムを暗号化すること、および解読することについてさらに述べると、署名動作または暗号化動作だけが、第２のレベルのチェックサム構造に対して実行される必要がある。いずれの動作も、送信者が、そのチェックサムを含む電子メールメッセージを送信したことを証明する。基本的に、第１の動作は、情報プロバイダデバイスが、チェックサムを計算するように実行される。チェックサムは、チェックサムコレクション、または第２のレベルのチェックサム構造であることが可能である。本明細書で開示されるとおり、第２のレベルのチェックサム構造の実施は、ＣＰＵサイクルを節約するとともに、要求される帯域幅を節約する。組み立てられたチェックサムコレクション構造、または第２のレベルのチェックサム構造を符号化することにより、メッセージが識別される。しかし、そのメッセージが、指定された情報プロバイダからであることを証明するための動作が、依然として、実行されなければならない。したがって、チェックサムに署名すること、またはチェックサムを暗号化することによって、そのような証明をもたらすための第２の動作が、実行される。証明が、署名することによる場合、それぞれの署名が、情報受信者デバイスに送信される。証明が、暗号化による場合、それぞれの暗号文が、情報受信者デバイスに送信される。署名されたチェックサム、または暗号化されたチェックサムに関して、情報受信者デバイスは、チェックサムが、組み立てられたチェックサムコレクションであるか、第２のレベルのチェックサム構造であるかにかかわらず、チェックサムを再現する同一の動作を一通り行う。供給された証明が暗号文である場合、情報受信者デバイスは、そのチェックサムを解読し、解読されたチェックサムを、再現されたチェックサムと比較する。供給された証明が署名である場合、情報受信者デバイスは、その署名を検査する。各送信者は、第１の動作と第２の動作の可能な４つの組合せのいずれかを使用するように、独立に選択することができる。
【００７７】
ウェブページ認証
ウェブページ認証に関して、本発明によるメッセージ認証を有効に実施するために、ＨＴＴＰ／ＨＴＭＬ（ハイパーテキストトランスポートプロトコル／ハイパーテキストマークアップ言語）の様々な態様に対処されなければならない。対処されなければならない一態様は、ウェブページが、単に、単一のＨＴＭＬファイルではないことである。ほとんどのウェブページは、異なるＵＲＬをそれぞれが有する、多くの異なる部分、例えば、イメージ、フレーム（それぞれがＨＴＭＬファイルによって指定された）、ｊａｖａｓｃｒｉｐｔから成る。
【００７８】
対処されなければならない別の態様は、Ｘ．５０９証明書を検証することは、処理リソースの見地から相当に費用がかかる動作であることである。多くのウェブサーバは、既に、この動作を専用のハードウェアに肩代わりさせ、作業負荷を増やすことは、好ましくは、最小限に抑えられなければならない。対処されなければならない別の態様は、単一のウェブページの諸部分が、しばしば、異なるサーバに由来することである。例えば、多くのウェブサイトは、第三者ウェブサイトエンティティ（例えば、広告プロバイダ）によって提供され、管理されるコンテンツ構成要素を有する。対処されなければならない別の態様は、多くのウェブサーバが、複数のドメインを扱うことである。例えば、所与のエンティティの複数のドメイン（例えば、ｗｗｗ．ｘ−ｃｏｍｐａｎｙ．ｃｏｍ、ｗｗｗ．ｘ−ｃｏｍｐａｎｙ．ｏｒｇ、ｗｗｗ．ｘ−ｃｏｍｐａｎｙ．ｔｖなど）がすべて、単一のサーバから提供されることが普通である。理論上、サーバセットアップが、これらの複数のドメインを分離すべきである。しかし、これらのドメインのすべてを提供する単一のサーバは、しばしば、これらのドメインすべてを同一のアドレス（例えば、ｗｗｗ．ｘ−ｃｏｍｐａｎｙ．ｃｏｍ）として扱う。有効な認証機能を提供するのに対処されなければならない、このことの１つの重大な悪影響は、各ＳＳＬ証明書が、対応するドメインを指定するために、多くのウェブサイトが、誤ったＳＳＬ証明書を使用することになってしまうことである。対処されなければならない別の側面は、信頼性のために、ほとんどの主要なウェブサイトは、何らかの種類の負荷分散およびレプリケーションを必要とすることである。このことは、複数のマシン（すなわち、場合により、異なるＯＳおよびウェブサーババージョンの）が、同一のＵＲＬに応じる可能性があることを意味する。これらの極端な場合において、単一のページの異なる部分、または単一のドメインの単なる諸部分でさえ、負荷分散セットの中の異なるサーバに由来する可能性があり、このことは、認証実行を複雑にする。対処されなければならない別の態様は、多くのウェブページが、静的ではなく、動的に生成されることである。これらの動的ページは、時として、複雑なシステムによって生成され、特殊なタグなどを有するように変更されるようウェブページを強制することは、望ましくない。対処されなければならないさらに別の態様は、ＳＳＬが、ＨＴＴＰより下位で動作し、このより高いレベルのプロトコルの知識を有さないため、ＳＳＬサーバが、或る特定のＩＰ／ポート組合せに関して１つの認証証明書だけしか提示することができないことである。このことは、ほとんどの場合において、ＨＴＴＰＳを用いた名前ベースの仮想ホスティングを使用することは、現在、実行可能ではないことを意味する。
【００７９】
本発明の一実施形態では、これらの独特の機能上の考慮点は、ＳＳＬ／ＴＬＳを無視して、ＨＴＴＰレベルで動作することによって対処される。有利には、このアプローチは、ＨＴＴＰＳが、機密情報に関してＳＳＬ／ＴＬＳを使用することを可能にする。これに関して、本発明の基礎をなす機能は、既存のセキュリティの備えに悪影響を及ぼさない。ウェブページは、ブラウザによって検査され、次に、ブラウザの別個の偽造不能な領域内で表示される認証証明書を参照する。この目的で、本発明の一実施形態では、情報受信者ユーザデバイスのブラウザが、図６に示されるウェブページ認証方法３００を実行する。
【００８０】
ＵＲＬ（ユニバーサルリソースロケータ）は、一般に、ＵＲＩ（ユニバーサルリソースアイデンティファイア）の同義語として使用されることを想い起こせば、厳密な違いは、この場合、我々に関係ない。ユーザ名、パスワード、ポート番号のような多くの複雑さを無視すると、単一のＵＲＩは、「ｈｔｔｐ：／／ｗｗｗ．ｘｘｘ．ｃｏｍ／ｄｅｍｏ／ｐａｇｅ．ｈｔｍｌ」のような外見であり、以下の３つの部分から成る。すなわち、
１．プロトコル、この場合「ＨＴＴＰ」。ＦＴＰ、ｔｅｌｎｅｔ、ｇｏｐｈｅｒ、ならびに、無論、ＨＴＴＰおよびＨＴＴＰＳを含む、数ダースのプロトコルが、サポートされる。我々は、このことの扱いをブラウザに任せ、我々は、単に、ブラウザが、指定されたリソースをどのように取り出すべきかを知っているものと見込む。
２．ホスト、この場合ウェブサーバのＤＮＳ名である「ｗｗｗ．ｘｘｘ．ｃｏｍ」。
３．パス、この場合所望されるリソースを指定する「ｄｅｍｏ／ｐａｇｅ．ｈｔｍｌ」。このリソースは、ＨＴＭＬファイル、ｇｉｆグラフィックイメージ、または他の何らかであることが可能である。また、このリソースは、静的であることも、動的に生成されることも可能である。これらの、戻されるリソースをＨＴＭＬファイルなどと呼ぶことが慣習的である。
【００８１】
ＨＴＴＰ（ハイパーテキストトランスポートプロトコル）は、ウェブサーバと通信するのにブラウザによって使用される最も一般的なプロトコルであることを想い起こされたい。ブラウザは、ＵＲＬ、およびサーバと対話する「メソッド」を提示し、我々は、これらのメソッドのうち２つ、すなわち、「ＧＥＴ」および「ＰＯＳＴ」について述べる。ゲットとポストはともに、ＵＲＬに対応する「リソース」を取り出し、ゲットとポストの違いは、この場合、我々に関係ない。ゲットとポストはともに、取り出されるリソースのタイプを返し、例えば、ＨＴＭＬファイルは、「ｔｅｘｔ／ｈｔｍｌ」というタイプであり、ｇｉｆ符号化されたグラフィックイメージは、「ｉｍａｇｅ／ｇｉｆ」というタイプである。（このＨＴＴＰタイプは、ファイル名またはＵＲＬのサフィックスによって示されるファイルタイプとは独立であり、タイプの複数の指示を調整することは、我々が扱う範囲を超えている）。我々は、概ね、以下の異なる３つのタイプのリソース、すなわち、ＨＴＭＬファイル、ＲｅａｌＮａｍｅ証明書、およびチェックサムに関心がある。
【００８２】
また、ＨＴＭＬ（ハイパーテキストマークアップ言語）は、ＳＧＭＬに由来する「マークアップ言語」であることも想い起こされたい。ＨＴＭＬは、或るテキストを見出し、段落、リストなどとして表すことによって、文書の中のテキストベースの情報の構造を記述し、さらにそのテキストを対話型フォーム、埋め込まれたイメージ、およびその他のオブジェクトで補足する手段をもたらす。ＨＴＭＬは、ラベル（タグとして知られる）の形態で書かれ、より小なり記号（＜）および大なり記号（＞）によって囲まれる。例えば、「＜ｔｉｔｌｅ＞Ｉｎｔｒｏｄｕｃｔｉｏｎ＜／ｔｉｔｌｅ＞」が、「ｔｉｔｌｅ」タグの例であり、「Ｉｎｔｒｏｄｕｃｔｉｏｎ」というテキストにそのページのタイトルとしてマークを付ける。結びのタグ「＜／ｔｉｔｌｅ＞」は、開始のタグに追加のスラッシュが付いているだけであることに留意されたい。ＨＴＭＬファイルは、ページの構造を記述するネストされたタグセットに過ぎない。我々は、ウェブページを識別するのに（同一のＵＲＬが、異なるページを毎回、動的に生成することが可能であるので）使用される追加のタグ＜ＲｅａｌＮａｍｅＳｅｒｉａｌＮｕｍｂｅｒ＞を加えることを提案する。ブラウザは、ブラウザに知られていないタグを無視するので、ＨＴＭＬ標準を変更することは望ましいが、必須ではなく、このことは、ウェブブラウザが、＜ＲｅａｌＮａｍｅＳｅｒｉａｌＮｕｍｂｅｒ＞タグをＨＴＭＬファイルの中に常に含めることに害はなく、ＲｅａｌＮａｍｅ対応のブラウザは、このタグを認証し、非対応のブラウザは、このタグを無視するに過ぎないことに留意されたい。また、我々がＨＴＭＬを参照する場合、我々は、情報のさらなるタグ付けをサポートすることができるＸＨＴＭＬ様のマークアップ言語、および他のＸＭＬ／ＳＧＭＬ様のマークアップ言語を含める。
【００８３】
１．ウェブページの先頭で、ＨＴＴＰ ＧＥＴ／ＰＵＴを使用してウェブサーバからファイルをフェッチするための動作３０２が、実行される。ＵＲＬおよびファイルは、この場合、それぞれ、「Ｔｏｐ ＵＲＬ」および「Ｔｏｐファイル」と呼ばれる。我々は、トップファイルがＨＴＭＬファイルである場合に最も関心があり、我々は、「Ｔｏｐ ＨＴＭＬファイル」において、このファイルを参照する。（この場合、「トップ」とは、このＨＴＭＬファイルが、他の多くのＨＴＭＬファイルが、このページの部分としてフェッチされるようにすることによって、ウェブページの構築を制御するということを指す）。ＲｅａｌＮａｍｅをサポートするウェブサーバは、各Ｔｏｐ ＨＴＭＬファイルが、通し番号および証明書ＵＲＬ（これら２つのアイテムは、単一のタグの中にあることも、複数のタグの中にあることも可能である）を指定するタグを含むようにする。通し番号は、そのページの特定のインスタンスを識別するのに使用され、連続的にインクリメントする番号に限定されず、最も好都合な形態は、通し番号が、ＵＲＬの形態にもなっていることである。この通し番号構成は、最上レベルのＨＴＭＬに関してだけ行われる。より低いレベルのＨＴＭＬに関する認証を許すことは、ＣＰＵおよび帯域幅の点で高価であるとともに、種々のクロスサイトスクリプティング攻撃に機会を与える。
【００８４】
２．Ｔｏｐ ＨＴＭＬファイルをフェッチすることに応答して、ＨＴＴＰを使用して、またはＵＲＬの中で指定された任意の機構を使用して、指定された認証証明書をフェッチするための動作３０４が、実行される。認証証明書を取り出した後に、認証証明書をキャッシュするための動作、その結果、遠隔ソースから認証証明書を後に取り出す必要性を排除することが本明細書で開示される。
【００８５】
３．認証証明書をフェッチした後、そのレジストリの存在する（すなわち、あらかじめ格納された）ルート証明書を使用して認証証明書を検証するための動作３０６が、実行される。
【００８６】
４．認証証明書を検証することに成功することに応答して、Ｔｏｐ ＨＴＭＬファイルに関するチェックサムを取り出す動作３０８が、実行される。このことは、通し番号をウェブサーバに送信すること（好ましい形態において、通し番号は既に、チェックサムを取り出すのに使用されることが可能なＵＲＬである）、ウェブサーバから対応する秘密鍵で符号化されたチェックサム（例えば、秘密鍵署名された、秘密鍵暗号化された、その他）を受信すること、および認証証明書の中の公開鍵を使用して、このチェックサムを復号すること（例えば、公開鍵検証、公開鍵解読、その他）によって行われる。チェックサムを符号化するために使用される秘密鍵が、認証証明書の中の公開鍵と合致するという条件付きで、ウェブサーバからの秘密鍵符号化されたチェックサムは、正しく復号される。異なる秘密鍵が使用されている場合、この復号は、失敗する、または復号されたチェックサムは、誤りであり、認証に不合格となる。
【００８７】
５．ウェブサーバからのチェックサムを解読することに成功したことに応答して、Ｔｏｐ ＨＴＭＬファイルが、実際に、そのウェブサーバに由来することを、Ｔｏｐ ＨＴＭＬファイルの我々のチェックサムを計算し、我々のチェックサムを、ウェブサーバから解読されたチェックサムと比較することによって、検証するための動作３１０が、実行される。これらのチェックサムが等しい場合、そのウェブページに関する識別情報は、認証されることに成功している。等しくない場合、認証は、失敗である。
【００８８】
６．ウェブページが真正であると判定されたか否かを判定することに応答して、ウェブページ（すなわち、ウェブページの識別情報）が真正であると判明したか否かを示す通知情報を提示するための動作３１２が、実行される。一実施形態では、この通知情報は、ウェブページコンテンツとは別個のブラウザウインドウの領域内で提示される。さらに、一実施形態では、認証証明書は、その別個の領域の表示を制御するＨＴＭＬファイルを含むことが可能である。
【００８９】
このウェブページ認証方法の利点は、トップＨＴＭＬファイルだけしか変更される必要がないことである。トップＨＴＭＬファイルだけが、それぞれの認証証明書を有する必要があるだけ十分に「重要」と考えられるウェブページであると想定することにより、例えば、帯域幅、サイクルなどの貴重なネットワークリソースが節約されることもある。このように想定することは、トップＨＴＭＬファイルが、他のいずれの部分がウェブページの中に含められるかを制御するので、妥当な想定である。トップＨＴＭＬファイルを認証することによって、我々は、後続の部分が、意図されるとおりにフェッチされることを暗黙に保証され、偽造は、正当なウェブサーバを覆すことを要求する。このことは、本発明の範囲を超える異なるセキュリティ問題である。また、この方法の実施は、有利には、ＨＴＴＰバージョン１．１を要求しない。一部の実例では、Ｔｏｐ ＵＲＬは、リダイレクトまたはタイムアウトを含むＴｏｐ ＨＴＭＬを返す可能性があり、その場合、ブラウザは、両方のページを認証する必要がある。リダイレクトは、長い時間がかかる、または決して行われない可能性がある。しかし、その一方で、リダイレクトページは、いくらかの表示可能な情報、およびクリック可能なリンクを含む可能性もある。トップＨＴＭＬファイルだけを認証することの結果は、多くのページ、例えば、単一のイメージから成るページが認証可能でないことであり、このことは、ユーザがサーバに情報を返送するのにＨＴＭＬが要求されるので（このことは、フィッシングの試みがＨＴＭＬを使用しなければならないことを意味する）、深刻な問題ではないことに留意されたい。
【００９０】
通し番号、および暗号化されたチェックサムを使用する、この手続きは、面倒であると見なされる可能性がある。しかし、Ｔｏｐ ＨＴＭＬファイルが、称されるところのウェブサーバに実際に由来することをサーバに確認させることが必要である。電子メールメッセージ認証方法と同様の仕方でＴｏｐ ＨＴＭＬファイルの中にチェックサムを埋め込むことが好ましい。しかし、Ｔｏｐ ＨＴＭＬファイルの中にチェックサムを埋め込むという動作自体が、チェックサムを変化させる。埋め込まれたチェックサムが、チェックサム計算から除外されるべきことが指定されているとした場合でも、そのチェックサムの存在は、やはり、チェックサム計算問題をもたらす。このことは、動的ページに関して、ファイル全体が生成されて、送信されるまで、ウェブサーバが、チェックサムを計算することを終えることができないためである。オプションとして、チェックサムを＜／ｂｏｄｙ＞タグまたは＜／ｈｔｍｌ＞タグの一部にすることによって、Ｔｏｐ ＨＴＭＬファイルが送信された後、暗号化されたチェックサムが送信されるべきことが指定されることが可能であるが、そうすることは、＜ｈｔｍｌ＞＜／ｈｔｍｌ＞ペアの外にタグを許すようにＨＴＭＬの定義を変更すること、またはチェックサムを計算する際に、複雑な編集を実行することを要求する。
【００９１】
通し番号を介してチェックサムへのアクセスを許すことによって、本発明によるウェブページ認証は、アドオンの仕方で実施されることが可能である。例えば、そのようなアドオン機能は、＜ＲｅａｌＮａｍｅＳｅｒｉａｌＮｕｍｂｅｒ＞タグを有するＨＴＭＬファイルを探してＨＴＴＰ応答を調べる。そのようなＨＴＭＬファイルが見つかるといつでも、チェックサムが計算され、情報受信者デバイスが、後に、そのチェックサムを照会することができるように、データベースの中に入れられる。さらに、この機能を、ウェブサイト／ブラウザソフトウェアに入れられるアドオン機能に組み込むことも、比較的容易である。
【００９２】
別の実施形態では、チェックサムは、ＨＴＭＬファイルの一部ではなく、ＨＴＴＰプロトコルの一部として伝送される。実行可能ではあるが、このようにすることは、ＨＴＭＬファイルのコンテンツとプロトコルの間の結合を生じさせる。また、署名する動作が、ＨＴＴＰ要求の完了に関するネックになる。さらに、そのようなソリューションは、許容できる結果を実現するのに多くのソフトウェア拡張が行われなければならないため、展開するのが困難である可能性も高い。別の実施形態では、チェックサムは、ＨＴＭＬファイルの最後の部分として含められる。このことは、例えば、＜／ｈｔｍｌ＞という結びのタグの後に来る新たなＨＴＭＬタグ＜ＲｅａｌＮａｍｅＣｈｅｃｋｓｕｍ＞を定義し、次に、チェックサムが、＜ＲｅａｌＮａｍｅＣｈｅｃｋｓｕｍ＞を除外して計算されるべきことを指定することによって、実施されることが可能である。つまり、ＨＴＭＬファイルを取り上げ、＜ＲｅａｌＮａｍｅＣｈｅｃｋｓｕｍ＞タグを編集して除き、次に、チェックサムを計算する。このソリューションは、実行可能であるが、ＨＴＭＬファイルのコンテンツとプロトコルの間の結合に関して前述した状況を生じさせ、署名動作が、ネックとなり、さらに実際の展開は、ソフトウェア拡張に依存する。
【００９３】
代替として、本発明による別のウェブページ認証方法は、認証証明書の扱いを、ＵＲＬおよびＨＴＭＬとは無関係にすることを含む。有利には、この方法は、ウェブページ（静的または動的）の変更をまったく要求せず、単一のイメージから成るページを含め、すべてのページを認証することができる。したがって、この方法は、望ましい代替である。証明書の扱いは、事前定義された特殊なＵＲＬに対する通常の要求として行われることが可能である。詳細には、ＨＴＴＰ１．１接続が、通常に行われるとおりに（標準のＳＳＬを伴って、または伴わずに）セットアップされ、ブラウザが、標準の事前定義されたＵＲＬを使用して認証証明書をフェッチし、この証明書が、検査され、秘密鍵のプロセッションが、検査される。このことにより、ウェブサーバが、証明書の所有者のために正当に動作していることが確認される。単一の法人エンティティに関して複数のドメイン名をホストしているウェブサーバは、この方法の容易な実施を特に評価することが、当業者には理解されよう。
【００９４】
また、前述したウェブページ認証方法は、有利に組み合わされることが可能であることも本明細書で開示される。そのような実施形態において、第１の説明される方法が、適用されることが可能である。トップＨＴＭＬが、認証証明書をポイントするタグを含まない場合、第２の説明されるソリューションが、適用されることが可能である。オプションとして、これら２つのソリューションは、逆の順序で適用されることも可能である。いずれかの方法が、認証された識別情報をもたらす場合、その趣旨の指示が、提示される。いずれかの方法が、無効な証明書、または不良な秘密鍵確認をもたらす場合、偽造の試みの可能性の指示が、提示されなければならない。いずれの方法も、メッセージ認証（成功した、またはそれ以外の）をもたらさない場合、そのような認証が未確認であるという指示が、提示されなければならない。
【００９５】
この「特殊なＵＲＬ」は、認証の目的でウェブサーバがサポートする標準化されたＵＲＬである。例えば、この「特殊なＵＲＬ」は、「ｈｔｔｐ：／／ｗｗｗ．ｅｎｔｉｔｙ−ｎａｍｅ．ｃｏｍ／＄＄ＲｅａｌＮａｍｅ＄＄」であることが可能であり、したがって、最上レベルのＵＲＬが、そのドメインにある（すなわち、ＵＲＬが、「ｈｔｔｐ：／／ｗｗｗ．ｅｎｔｉｔｙ−ｎａｍｅ．ｃｏｍ」から始まる）場合、ブラウザは、「ｈｔｔｐ：／／ｗｗｗ．ｅｎｔｉｔｙ−ｎａｍｅ．ｃｏｍ／ＲｅａｌＮａｍｅ」をウェブサーバに求めて、対応するＲｅａｌＮａｍｅ（すなわち、認証）証明書を取り出す。ドル記号は、多くのウェブマスタが、このＵＲＬが「通常のデータページではなく」、注意を払って変更されるべきことを示すのに使用する慣習に過ぎない。このアプローチは、本発明に従って構成された認証証明書に合わせて構成されていないサーバが、「４０４−ページが見つかりませんでした」などのエラーメッセージを返す一方で、本発明による認証対応であるウェブサーバは、それに相応して証明書を返すという点で、本発明に従って構成された認証証明書に合わせて構成されていないサーバに対して機能することに留意されたい。
【００９６】
ＩＭメッセージ認証
インスタントメッセージング認証に関して、問題は、やはり異なる。しかし、それらの問題は、概ね、前述した電子メールメッセージ認証に関連する独特の機能上の考慮点のサブセットである。１つのそのような考慮点は、ほとんどのＩＭシステムが、クライアント間で「調停する」中央サーバを有することである。したがって、クライアントは、他のクライアントと直接に通信しない。このことは、基本的に、電子メールのマルチホップの性質と同一の状況である。別のそのような考慮点は、通常、各ベンダにつき１つの、異なる複数のＩＭプロトコルが存在し、さらに、各ＩＭプロトコルに関して、異なる多くのユーザエージェントも存在することである。さらに別のそのような考慮点は、まったくの他人が互いに電子メール送信することができる電子メールとは異なり、クライアントペアが、通常、スクリーン名交換プロトコルを介して、クライアント自らの許可された連絡先リストに互いを相互に追加しなければならないことである。
【００９７】
したがって、ＩＭメッセージ認証を円滑にするように構成された本発明の実施形態は、これらの独特の機能上の考慮点に対処しなければならず、前段で開示される電子メールメッセージ認証方法と同様の意向で構成される。この目的で、本発明の一実施形態では、図７に示される以下のＩＭメッセージ認証方法４００が、ＩＭ対応の受信者デバイスによって実施される。実施形態の詳細は、必然的に、基礎をなす特定のＩＭプロトコルに依存する可能性があることが当業者には認識されよう。
【００９８】
１．ＩＭダイアログセッションごとに、またはＩＭスクリーン名を連絡先リストに追加する時点においてだけ、ＩＭクライアント間で認証証明書を交換するための動作４０２が、実行される。ＩＭダイアログセッションごとに認証証明書を交換することは、ＩＭクライアントが、異なるチャットセッションに関して異なる、認証されたスクリーン名を使用することを許すという利点を有する。ＩＭスクリーン名を連絡先リストに追加する時点においてだけ認証証明書を交換することは、ＩＭメッセージにおける認証証明書の伝送を節約し、このことは、認証証明書が、比較的「かさばる」ので、有利であり、さらにＩＭスクリーン名が追加される時点において、ＩＭスクリーン名の認証を可能にする。
【００９９】
２．認証証明書を交換した後、ＩＭスクリーン名を検査するための動作４０４が、実行される。このことは、ＩＭスクリーン名を、それぞれの認証証明書に埋め込まれた名前と照合することによって行われることが可能である。このアプローチは、スクリーン名が、証明書を発行する時点で固定されることを意味する。代替として、スクリーン名は、証明書に埋め込まれず、検査することは、スクリーン名に署名することによって行われることが可能であり、このことは、複数のスクリーン名が使用されることが可能である（場合により、証明書は、「技術支援」部門に関し、各技術者が、個人スクリーン名を有する）という利点を有する。認証手続きが失敗した場合、対応する１つまたは複数の通知アクションが、行われることが可能である。これらの通知アクションの例には、スクリーン名を追加することが拒否されることが可能であり、スクリーン名を追加することの確認を要求するユーザダイアログウインドウが、提示されることが可能であり、スクリーン名に、認証されていないというフラグが付けられ、スクリーン名が、ＩＭ連絡先リストの中の或る特定の「認証されていない」グループにリダイレクトされることが可能であることなどが含まれるが、以上には限定されない。この特定のアクションは、ＩＭクライアントポリシー設定の特性として指定されることが可能である。
【０１００】
３．ＩＭユーザが、チャットセッションを開始すると、ＩＭメッセージの指定された部分に関するチェックサムを作成するための動作４０６が、ＩＭメッセージが送信されるデバイス（すなわち、送信者ユーザデバイス）によって実行される。一実施形態では、これらの部分には、実際のメッセージ、送信者スクリーン名、および日付／時刻情報が含まれる。
【０１０１】
４．チェックサムを作成した後、符号化されたチェックサムを生成するために、証明書に対応する秘密鍵を使用してチェックサムを符号化するための動作４０７が、実行される。この符号化されたチェックサムは、証明書の認証を可能にするために、証明書に対応する秘密鍵によって署名されている、または暗号化されているチェックサムである。
【０１０２】
５．チェックサムを符号化した後、ＩＭメッセージの中で指定された受信者スクリーン名に対応するデバイス（すなわち、受信者ユーザデバイス）によって受信されるように、符号化されたチェックサム、およびＩＭメッセージを伝送するための動作４０８が、実行される。
【０１０３】
６．符号化されたチェックサムを伝送した後、符号化されたチェックサムを受信するための動作４１０が、受信者ユーザデバイスによって実行される。
【０１０４】
７．符号化されたチェックサムを受信した後、符号化されたチェックサムを検証し、さらに情報プロバイダの認証証明書を使用してチェックサムをレプリケートして、確認するための動作４１２が、受信者ユーザデバイスによって実行される。情報プロバイダの認証証明書は、符号化されたチェックサムの有効性を検証するために使用される。符号化されたチェックサムの検証は、前段で開示される電子メール実施形態における、符号化されたチェックサムの検証と同一の仕方で（例えば、署名を検査し、または符号化されたチェックサムを解読し、情報プロバイダの認証証明書を使用してチェックサムをレプリケートし、確認して）実行される。
【０１０５】
８．チェックサムが検証されることに成功したか否かを示す通知情報を提示するための動作４１４が、実行される。チェックサムの検証が失敗した場合、送信者のスクリーン名に、認証されていないというフラグが付けられ、通知が、提示される。さもなければ、スクリーン名は、追加され、認証の成功の通知が、提示される。前述したとおり、ポリシーが、行われるべきさらなるアクションを規定することが可能である。
【０１０６】
本発明による情報プロバイダ認証アプリケーションは、様々な機能に関して、機能的、さらに／または物理的に分離されることが可能であることが、本明細書で開示される。例えば、一実施形態では、識別情報識別検証機能が、情報プロバイダ認証アプリケーションの第１の部分を介して提供され、通信媒体固有の機能が、情報プロバイダ認証アプリケーションの他の１つまたは複数の部分を介して提供される。より具体的には、一実施形態では、識別情報識別検証機能が、情報プロバイダ認証アプリケーションの第１の部分を介して提供され、電子メール認証固有の動作が、情報プロバイダ認証アプリケーションの第２の部分を介して提供され、ウェブ認証固有の動作が、情報プロバイダ認証アプリケーションの第３の部分を介して提供され、さらにＩＭメッセージ固有の動作が、情報プロバイダ認証アプリケーションの第４の部分を介して提供される。この目的で、本発明による認証アプリケーションは、モジュール型で設計され、保持されることが可能である。
【０１０７】
次に、本発明によるデータ通信デバイスによって処理可能な命令について述べると、本明細書で開示されるメッセージコンテンツ認証機能および／または識別情報機能を円滑にするために適合された方法、プロセスおよび／または動作は、そのような機能を実行するように構成された命令を有するコンピュータ可読媒体によって実体化されることが、本明細書で行われる開示から理解されよう。１つの特定の実施形態では、これらの命令は、図１から図７を参照して開示される方法の１つまたは複数を実行するために実体化される。これらの命令は、メモリ装置（例えば、ＲＡＭ、ＲＯＭ、仮想メモリ、ハードドライブメモリなど）から、データ処理システムのドライブユニットによって読み取り可能な装置（例えば、ディスケット、コンパクトディスク、テープカートリッジなど）から、またはこれらの両方から、１つまたは複数のデータ処理デバイスによってアクセス可能であり得る。したがって、本発明によるコンピュータ可読媒体の実施形態には、本発明によるメッセージコンテンツ認証機能および／または識別情報機能を実行することを円滑にするために適合された命令（例えば、コンピュータプログラム）がイメージ化されているコンパクトディスク、ハードドライブ、ＲＡＭ、または他のタイプの記憶装置が含まれる。
【０１０８】
以上の詳細な説明において、本明細書の一部を形成し、例示として、本発明が実施されることが可能な特定の実施形態が示される、添付の図面が、参照されてきた。これらの実施形態、およびこれらの実施形態のいくつかの変種が、本発明の実施形態を当業者が実施することができるようにするのに十分な詳細で説明されてきた。他の適切な実施形態が、利用されることも可能であり、さらにそのような発明の開示の趣旨または範囲を逸脱することなく、論理的、機械的、化学的、および電気的な変更が行われることが可能であるものと理解されたい。不必要な詳細を回避するのに、この説明は、当業者に知られている或る情報を省略している。したがって、以上の詳細な説明は、本明細書で示される特定の形態に限定されることは意図されず、それどころか、添付の特許請求の範囲の趣旨および範囲に合理的に含まれることが可能な、そのような代替形態、変形形態、および均等形態を範囲に含むことが意図される。
【特許請求の範囲】
【請求項１】
複数の情報プロバイダの各プロバイダに発行された認証証明書と、前記認証証明書のすべてに対応するルート証明書とを含む証明書レジストリを作成し、前記認証証明書の各証明書が、該証明書のそれぞれの認証情報を、前記情報プロバイダの対応するプロバイダの識別情報に結び付け、前記認証証明書の各証明書が、前記情報プロバイダの対応するプロバイダと、該プロバイダのドメイン名情報との間のリンクを欠いており、さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも１つに少なくとも或る程度、依存する仕方で関連付けられること、
情報受信者にルート証明書を提供すること、および
情報受信者によってアクセスされ、さらに認証証明書が関連付けられているウェブページの検証を円滑にし、前記検証が、ルート証明書の中に含まれる認証情報を使用して、前記関連付けられた認証証明書の真正性を検証することに成功して、前記関連付けられた認証証明書が、証明書レジストリに属することを検証すること、および前記関連付けられた認証証明書の真正性を前記検証することに成功した後、前記関連付けられた認証証明書の中に含まれる認証情報を使用して、ウェブページの指定された所有者のＩＤを検証することに成功することを含む、方法。
【請求項２】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダが認識される名前、前記情報プロバイダのそれぞれのプロバイダに固有のイメージ、前記情報プロバイダのそれぞれのプロバイダに固有のテキスト、および前記情報プロバイダのそれぞれのプロバイダに固有のサウンドの少なくとも１つを含む、請求項１に記載の方法。
【請求項３】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダの保護された名前、前記情報プロバイダのそれぞれのプロバイダの保護されたイメージ、前記情報プロバイダのそれぞれのプロバイダの保護されたテキスト、および前記情報プロバイダのそれぞれのプロバイダの保護されたサウンドの少なくとも１つを含む、請求項１に記載の方法。
【請求項４】
情報受信者にルート証明書を提供することが、情報受信者が、ルート証明書を明確に要求することに応答して実行され、さらにルート証明書が、情報の特定のタイプ、特定の組織、特定のタイプの職業、および特定の地理的区域の少なくとも１つに対応する、請求項１に記載の方法。
【請求項５】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダの保護された名前、前記情報プロバイダのそれぞれのプロバイダの保護されたイメージ、前記情報プロバイダのそれぞれのプロバイダの保護されたテキスト、および前記情報プロバイダのそれぞれのプロバイダの保護されたサウンドの少なくとも１つを含む、請求項４に記載の方法。
【請求項６】
情報受信者によってアクセスされるウェブページの検証を円滑にすることが、
前記関連付けられた認証証明書をウェブサーバから取り出すこと、
ウェブサーバが、認証証明書に対する合致する鍵を有することを検証すること、および
認証証明書が有効であり、さらにウェブサーバが、合致する鍵を有すると判定して、ウェブサーバと情報受信者との間のウェブページ通信チャネルが真正であることを検証したことに応答して、ウェブページの真正性を確認することを含む、請求項４に記載の方法。
【請求項７】
情報受信者によってアクセスされるウェブページの検証を円滑にすることが、ウェブページを表すファイルをウェブサーバから取り出すことを含み、ファイルが、ウェブページの通し番号と、前記関連付けられた認証証明書とを含み、
ファイルが、ウェブサーバから送信されたこと、およびウェブサーバが、認証証明書に対する合致する鍵を有することを検証することが、通し番号をウェブサーバに送信すること、サーバから、認証証明書の秘密鍵を使用して署名された、ファイルのチェックサムを受信すること、サーバから受信された確認チェックサムが、受信されたファイルを使用して作成されたチェックサムの確認チェックサムと合致するかどうかを判定すること、および認証証明書が、ルート証明書の秘密鍵によって署名されているかどうかを判定することを含む、請求項４に記載の方法。
【請求項８】
ファイルが、ウェブページに関連付けられた認証証明書を指定する、請求項７に記載の方法。
【請求項９】
前記関連付けられた認証証明書を取り出した後、前記関連付けられた認証証明書をキャッシュして、前記認証証明書の取り出しの繰り返しを防止することをさらに含む、請求項８に記載の方法。
【請求項１０】
複数の情報プロバイダの各プロバイダに発行された認証証明書と、
前記認証証明書のすべてに対応するルート証明書とを含む証明書レジストリであって、
前記認証証明書の各証明書が、該証明書のそれぞれの認証情報を、前記情報プロバイダの対応するプロバイダの識別情報に結び付け、
前記認証証明書の各証明書が、前記情報プロバイダの対応するプロバイダと、該プロバイダのドメイン名との間のリンクを欠いており、さらに
証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも１つに少なくとも或る程度、依存する仕方で関連付けられる、レジストリ。
【請求項１１】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダが認識される名前、前記情報プロバイダのそれぞれのプロバイダに固有のイメージ、前記情報プロバイダのそれぞれのプロバイダに固有のテキスト、および前記情報プロバイダのそれぞれのプロバイダに固有のサウンドの少なくとも１つを含む、請求項１０に記載のレジストリ。
【請求項１２】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダの保護された名前、前記情報プロバイダのそれぞれのプロバイダの保護されたイメージ、前記情報プロバイダのそれぞれのプロバイダの保護されたテキスト、および前記情報プロバイダのそれぞれのプロバイダの保護されたサウンドの少なくとも１つを含む、請求項１０に記載のレジストリ。
【請求項１３】
複数の情報プロバイダの各プロバイダに発行される認証証明書を発行し、さらに前記認証証明書のすべてに対応するルート証明書を保持するように構成された証明書レジストリシステムであって、
前記認証証明書の各証明書が、該証明書のそれぞれの認証情報を、前記情報プロバイダの対応するプロバイダの識別情報に結び付け、前記認証証明書の各証明書が、前記情報プロバイダの対応するプロバイダと、該プロバイダのドメイン名情報との間のリンクを欠いており、さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連する特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置する特定の地理的区域のうち少なくとも１つに少なくとも或る程度、依存する仕方で関連する、システム。
【請求項１４】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダが認識される名前、前記情報プロバイダのそれぞれのプロバイダに固有のイメージ、前記情報プロバイダのそれぞれのプロバイダに固有のテキスト、および前記情報プロバイダのそれぞれのプロバイダに固有のサウンドの少なくとも１つを含む、請求項１４に記載のシステム。
【請求項１５】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダの保護された名前、前記情報プロバイダのそれぞれのプロバイダの保護されたイメージ、前記情報プロバイダのそれぞれのプロバイダの保護されたテキスト、および前記情報プロバイダのそれぞれのプロバイダの保護されたサウンドの少なくとも１つを含む、請求項１４に記載のシステム。
【請求項１６】
情報受信者が、ルート証明書を明確に要求することに応答して、情報受信者にルート証明書を提供するようにさらに構成され、ルート証明書が、情報の特定のタイプ、特定の組織、特定のタイプの職業、および特定の地理的区域の少なくとも１つに対応する、請求項１４に記載のシステム。
【請求項１７】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダの保護された名前、前記情報プロバイダのそれぞれのプロバイダの保護されたイメージ、前記情報プロバイダのそれぞれのプロバイダの保護されたテキスト、および前記情報プロバイダのそれぞれのプロバイダの保護されたサウンドの少なくとも１つを含む、請求項１７に記載のシステム。
【請求項１８】
情報受信者によってアクセスされ、さらに認証証明書が関連付けられているウェブページの検証を円滑にするようにさらに構成され、前記検証が、ルート証明書の中に含まれる認証情報を使用して、前記関連付けられた認証証明書の真正性を検証することに成功して、前記関連付けられた認証証明書が、証明書レジストリに属することを検証すること、および前記関連付けられた認証証明書の真正性を前記検証することに成功した後、前記関連付けられた認証証明書の中に含まれる認証情報を使用して、ウェブページの指定された所有者のＩＤを検証することに成功することを含む、請求項１７に記載のシステム。
【請求項１９】
情報受信者によってアクセスされるウェブページの検証を円滑にすることが、
前記関連付けられた認証証明書をウェブサーバから取り出すこと、
ウェブサーバが、認証証明書に対する合致する鍵を有することを検証すること、および
認証証明書が有効であり、さらにウェブサーバが、合致する鍵を有すると判定して、ウェブサーバと情報受信者との間のウェブページ通信チャネルが真正であることを検証したことに応答して、ウェブページの真正性を確認することを含む、請求項１８に記載のシステム。
【請求項２０】
情報受信者によってアクセスされるウェブページの検証を円滑にすることが、ウェブページを表すファイルをウェブサーバから取り出すことを含み、ファイルが、ウェブページの通し番号と、前記関連付けられた認証証明書とを含み、
ファイルが、ウェブサーバから送信されたこと、およびウェブサーバが、認証証明書に対する合致する鍵を有することを検証することが、通し番号をウェブサーバに送信すること、サーバから、認証証明書の秘密鍵を使用して署名された、ファイルのチェックサムを受信すること、サーバから受信された確認チェックサムが、受信されたファイルを使用して作成されたチェックサムの確認チェックサムと合致するかどうかを判定すること、および認証証明書が、ルート証明書の秘密鍵によって署名されているかどうかを判定することを含む、請求項１８に記載のシステム。
【請求項２１】
ファイルが、ウェブページに関連付けられた認証証明書を指定する、請求項２０に記載のシステム。前記関連付けられた認証証明書を取り出した後、前記関連付けられた認証証明書をキャッシュして、前記認証証明書の取り出しの繰り返しを防止するようにさらに構成される、請求項２０に記載のシステム。
【請求項１】
複数の情報プロバイダの各プロバイダに発行された認証証明書と、前記認証証明書のすべてに対応するルート証明書とを含む証明書レジストリを作成し、前記認証証明書の各証明書が、該証明書のそれぞれの認証情報を、前記情報プロバイダの対応するプロバイダの識別情報に結び付け、前記認証証明書の各証明書が、前記情報プロバイダの対応するプロバイダと、該プロバイダのドメイン名情報との間のリンクを欠いており、さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも１つに少なくとも或る程度、依存する仕方で関連付けられること、
情報受信者にルート証明書を提供すること、および
情報受信者によってアクセスされ、さらに認証証明書が関連付けられているウェブページの検証を円滑にし、前記検証が、ルート証明書の中に含まれる認証情報を使用して、前記関連付けられた認証証明書の真正性を検証することに成功して、前記関連付けられた認証証明書が、証明書レジストリに属することを検証すること、および前記関連付けられた認証証明書の真正性を前記検証することに成功した後、前記関連付けられた認証証明書の中に含まれる認証情報を使用して、ウェブページの指定された所有者のＩＤを検証することに成功することを含む、方法。
【請求項２】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダが認識される名前、前記情報プロバイダのそれぞれのプロバイダに固有のイメージ、前記情報プロバイダのそれぞれのプロバイダに固有のテキスト、および前記情報プロバイダのそれぞれのプロバイダに固有のサウンドの少なくとも１つを含む、請求項１に記載の方法。
【請求項３】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダの保護された名前、前記情報プロバイダのそれぞれのプロバイダの保護されたイメージ、前記情報プロバイダのそれぞれのプロバイダの保護されたテキスト、および前記情報プロバイダのそれぞれのプロバイダの保護されたサウンドの少なくとも１つを含む、請求項１に記載の方法。
【請求項４】
情報受信者にルート証明書を提供することが、情報受信者が、ルート証明書を明確に要求することに応答して実行され、さらにルート証明書が、情報の特定のタイプ、特定の組織、特定のタイプの職業、および特定の地理的区域の少なくとも１つに対応する、請求項１に記載の方法。
【請求項５】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダの保護された名前、前記情報プロバイダのそれぞれのプロバイダの保護されたイメージ、前記情報プロバイダのそれぞれのプロバイダの保護されたテキスト、および前記情報プロバイダのそれぞれのプロバイダの保護されたサウンドの少なくとも１つを含む、請求項４に記載の方法。
【請求項６】
情報受信者によってアクセスされるウェブページの検証を円滑にすることが、
前記関連付けられた認証証明書をウェブサーバから取り出すこと、
ウェブサーバが、認証証明書に対する合致する鍵を有することを検証すること、および
認証証明書が有効であり、さらにウェブサーバが、合致する鍵を有すると判定して、ウェブサーバと情報受信者との間のウェブページ通信チャネルが真正であることを検証したことに応答して、ウェブページの真正性を確認することを含む、請求項４に記載の方法。
【請求項７】
情報受信者によってアクセスされるウェブページの検証を円滑にすることが、ウェブページを表すファイルをウェブサーバから取り出すことを含み、ファイルが、ウェブページの通し番号と、前記関連付けられた認証証明書とを含み、
ファイルが、ウェブサーバから送信されたこと、およびウェブサーバが、認証証明書に対する合致する鍵を有することを検証することが、通し番号をウェブサーバに送信すること、サーバから、認証証明書の秘密鍵を使用して署名された、ファイルのチェックサムを受信すること、サーバから受信された確認チェックサムが、受信されたファイルを使用して作成されたチェックサムの確認チェックサムと合致するかどうかを判定すること、および認証証明書が、ルート証明書の秘密鍵によって署名されているかどうかを判定することを含む、請求項４に記載の方法。
【請求項８】
ファイルが、ウェブページに関連付けられた認証証明書を指定する、請求項７に記載の方法。
【請求項９】
前記関連付けられた認証証明書を取り出した後、前記関連付けられた認証証明書をキャッシュして、前記認証証明書の取り出しの繰り返しを防止することをさらに含む、請求項８に記載の方法。
【請求項１０】
複数の情報プロバイダの各プロバイダに発行された認証証明書と、
前記認証証明書のすべてに対応するルート証明書とを含む証明書レジストリであって、
前記認証証明書の各証明書が、該証明書のそれぞれの認証情報を、前記情報プロバイダの対応するプロバイダの識別情報に結び付け、
前記認証証明書の各証明書が、前記情報プロバイダの対応するプロバイダと、該プロバイダのドメイン名との間のリンクを欠いており、さらに
証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連している特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置している特定の地理的区域の少なくとも１つに少なくとも或る程度、依存する仕方で関連付けられる、レジストリ。
【請求項１１】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダが認識される名前、前記情報プロバイダのそれぞれのプロバイダに固有のイメージ、前記情報プロバイダのそれぞれのプロバイダに固有のテキスト、および前記情報プロバイダのそれぞれのプロバイダに固有のサウンドの少なくとも１つを含む、請求項１０に記載のレジストリ。
【請求項１２】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダの保護された名前、前記情報プロバイダのそれぞれのプロバイダの保護されたイメージ、前記情報プロバイダのそれぞれのプロバイダの保護されたテキスト、および前記情報プロバイダのそれぞれのプロバイダの保護されたサウンドの少なくとも１つを含む、請求項１０に記載のレジストリ。
【請求項１３】
複数の情報プロバイダの各プロバイダに発行される認証証明書を発行し、さらに前記認証証明書のすべてに対応するルート証明書を保持するように構成された証明書レジストリシステムであって、
前記認証証明書の各証明書が、該証明書のそれぞれの認証情報を、前記情報プロバイダの対応するプロバイダの識別情報に結び付け、前記認証証明書の各証明書が、前記情報プロバイダの対応するプロバイダと、該プロバイダのドメイン名情報との間のリンクを欠いており、さらに証明書レジストリの前記認証証明書が、前記情報プロバイダが提供する情報の特定のタイプ、前記情報プロバイダが関連する特定の組織、前記情報プロバイダが携わっている特定のタイプの職業、および前記情報プロバイダが位置する特定の地理的区域のうち少なくとも１つに少なくとも或る程度、依存する仕方で関連する、システム。
【請求項１４】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダが認識される名前、前記情報プロバイダのそれぞれのプロバイダに固有のイメージ、前記情報プロバイダのそれぞれのプロバイダに固有のテキスト、および前記情報プロバイダのそれぞれのプロバイダに固有のサウンドの少なくとも１つを含む、請求項１４に記載のシステム。
【請求項１５】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダの保護された名前、前記情報プロバイダのそれぞれのプロバイダの保護されたイメージ、前記情報プロバイダのそれぞれのプロバイダの保護されたテキスト、および前記情報プロバイダのそれぞれのプロバイダの保護されたサウンドの少なくとも１つを含む、請求項１４に記載のシステム。
【請求項１６】
情報受信者が、ルート証明書を明確に要求することに応答して、情報受信者にルート証明書を提供するようにさらに構成され、ルート証明書が、情報の特定のタイプ、特定の組織、特定のタイプの職業、および特定の地理的区域の少なくとも１つに対応する、請求項１４に記載のシステム。
【請求項１７】
前記識別情報が、前記情報プロバイダのそれぞれのプロバイダの保護された名前、前記情報プロバイダのそれぞれのプロバイダの保護されたイメージ、前記情報プロバイダのそれぞれのプロバイダの保護されたテキスト、および前記情報プロバイダのそれぞれのプロバイダの保護されたサウンドの少なくとも１つを含む、請求項１７に記載のシステム。
【請求項１８】
情報受信者によってアクセスされ、さらに認証証明書が関連付けられているウェブページの検証を円滑にするようにさらに構成され、前記検証が、ルート証明書の中に含まれる認証情報を使用して、前記関連付けられた認証証明書の真正性を検証することに成功して、前記関連付けられた認証証明書が、証明書レジストリに属することを検証すること、および前記関連付けられた認証証明書の真正性を前記検証することに成功した後、前記関連付けられた認証証明書の中に含まれる認証情報を使用して、ウェブページの指定された所有者のＩＤを検証することに成功することを含む、請求項１７に記載のシステム。
【請求項１９】
情報受信者によってアクセスされるウェブページの検証を円滑にすることが、
前記関連付けられた認証証明書をウェブサーバから取り出すこと、
ウェブサーバが、認証証明書に対する合致する鍵を有することを検証すること、および
認証証明書が有効であり、さらにウェブサーバが、合致する鍵を有すると判定して、ウェブサーバと情報受信者との間のウェブページ通信チャネルが真正であることを検証したことに応答して、ウェブページの真正性を確認することを含む、請求項１８に記載のシステム。
【請求項２０】
情報受信者によってアクセスされるウェブページの検証を円滑にすることが、ウェブページを表すファイルをウェブサーバから取り出すことを含み、ファイルが、ウェブページの通し番号と、前記関連付けられた認証証明書とを含み、
ファイルが、ウェブサーバから送信されたこと、およびウェブサーバが、認証証明書に対する合致する鍵を有することを検証することが、通し番号をウェブサーバに送信すること、サーバから、認証証明書の秘密鍵を使用して署名された、ファイルのチェックサムを受信すること、サーバから受信された確認チェックサムが、受信されたファイルを使用して作成されたチェックサムの確認チェックサムと合致するかどうかを判定すること、および認証証明書が、ルート証明書の秘密鍵によって署名されているかどうかを判定することを含む、請求項１８に記載のシステム。
【請求項２１】
ファイルが、ウェブページに関連付けられた認証証明書を指定する、請求項２０に記載のシステム。前記関連付けられた認証証明書を取り出した後、前記関連付けられた認証証明書をキャッシュして、前記認証証明書の取り出しの繰り返しを防止するようにさらに構成される、請求項２０に記載のシステム。
【図１】
【図２】
【図３ａ】
【図３ｂ】
【図３ｃ】
【図４ａ】
【図４ｂ】
【図４ｃ】
【図４ｄ】
【図５】
【図６】
【図７】
【図２】
【図３ａ】
【図３ｂ】
【図３ｃ】
【図４ａ】
【図４ｂ】
【図４ｃ】
【図４ｄ】
【図５】
【図６】
【図７】
【公表番号】特表２０１０−５３００９７（Ｐ２０１０−５３００９７Ａ）
【公表日】平成２２年９月２日（２０１０．９．２）
【国際特許分類】
【出願番号】特願２０１０−５１０９５３（Ｐ２０１０−５１０９５３）
【出願日】平成２０年６月５日（２００８．６．５）
【国際出願番号】ＰＣＴ／ＩＢ２００８／０５３４８２
【国際公開番号】ＷＯ２００８／１４９３３１
【国際公開日】平成２０年１２月１１日（２００８．１２．１１）
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
【公表日】平成２２年９月２日（２０１０．９．２）
【国際特許分類】
【出願日】平成２０年６月５日（２００８．６．５）
【国際出願番号】ＰＣＴ／ＩＢ２００８／０５３４８２
【国際公開番号】ＷＯ２００８／１４９３３１
【国際公開日】平成２０年１２月１１日（２００８．１２．１１）
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
[ Back to top ]