(57)【要約】      （修正有）【課題】ユーザーにとって可能なかぎり透明な形で、改善した認証プロセスのセキュリティを提供する。【解決手段】データネットワーク上で１つのサービス28のユーザアカウントにアクセスするための認証方法において、サービス28へのコンサルティングデバイス10側からの要求をサービス28が受信する、要求が第１の認証情報を含んでいるステップＥ２０と、認証のセキュリティデバイス管理機構34が送った情報をサービス28が受信する、受信する情報がユーザアカウントに連関されたセキュリティデバイス16又は18に由来する第２の認証情報に基づいているステップＥ６０と、第１の認証情報および認証のセキュリティデバイス管理機構34から受信した情報に基づいて、サービス28が認証を行なうステップと、を含む。【選択図】図２
2015099595.tif 000002
【特許請求の範囲】
【請求項１】
データネットワーク（２６）上でサービス（２８）のユーザアカウントにアクセスするための認証方法において、
−  前記サービス（２８）へのコンサルティングデバイス（１０）側からの要求をサービス（２８）が受信するステップ（Ｅ２０）であって、前記要求が第１の認証情報を含んでいるステップと、
−  認証のセキュリティデバイス管理機構（３４）が送った情報を前記サービス（２８）が受信するステップ（Ｅ６０）であって、前記サービス（２８）が受信する情報が前記ユーザアカウントに連関されたセキュリティデバイス（１６；１８）に由来する第２の認証情報に基づいているステップと、
−  前記第１の認証情報および前記認証のセキュリティデバイス管理機構（３４）から受信した情報に基づいて、前記サービス（２８）が認証を行なうステップと、
を含む方法。
【請求項２】
前記第２の認証情報は、前記管理機構（３４）が接続された時点で前記管理機構に対し前記セキュリティデバイス（１６；１８）によって自発的に送信されることを特徴とする請求項１に記載の認証方法。
【請求項３】
前記サービス（２８）が受信する前記情報が、前記セキュリティデバイス（１６；１８）により送信された前記第２の認証情報に対応することを特徴とする請求項１または２に記載の認証方法。
【請求項４】
前記管理機構（３４）は前記セキュリティデバイス（１６；１８）が受信した前記第２の認証情報を検証すること、および前記管理機構（３４）により前記サービス（２８）に送信される情報が前記検証の結果に対応することを特徴とする請求項１または２に記載の認証方法。
【請求項５】
前記第２の認証情報が前記セキュリティデバイスの位置特定情報を含むことを特徴とする請求項１〜４のいずれか一項に記載の認証方法。
【請求項６】
前記位置特定情報がローカルネットワークと前記サービス（２８）をホストするデータネットワークとの間のゲートウェイのアドレスを含み、前記ローカルネットワークが前記セキュリティデバイス（１６；１８）と前記コンサルティングデバイス（１０）とを接続していることを特徴とする請求項５に記載の認証方法。
【請求項７】
前記第２の認証情報が、前記セキュリティデバイス（１６；１８）内に記憶された秘密に基づくワンタイムコードを含むことを特徴とする請求項１〜６のいずれか一項に記載の認証方法。
【請求項８】
前記セキュリティデバイス（１６；１８）が、前記セキュリティデバイス（１６；１８）により開始される持続的接続を用いて前記管理機構（３４）に接続されていることを特徴とする請求項１〜７のいずれか一項に記載の認証方法。
【請求項９】
前記セキュリティデバイス（１６；１８）と前記ユーザアカウントの連関には、
−  前記セキュリティデバイス（１６；１８）により提示されたコードを前記コンサルティングデバイス（１０）上で入力するステップと、
−  前記入力されたコードを前記サービス（２８）に送信するステップと、
−  前記サービス（２８）が連関を起動するステップと、
が含まれることを特徴とする請求項１〜８のいずれか一項に記載の認証方法。
【請求項１０】
前記管理機構（３４）による前記第２の認証情報の受信には、前記コンサルティングデバイス（１０）のユーザの確認が必要とされることを特徴とする請求項１〜９のいずれか一項に記載の認証方法。
【請求項１１】
データネットワーク（２６）上でサービス（２８）を実施するデバイスにおいて、
−  前記サービス（２８）へのコンサルティングデバイス（１０）側からの要求を受信する手段であって、前記要求が第１の認証情報を含んでいる手段と、
−  認証のセキュリティデバイス管理機構（３４）が送った情報を受信する手段であって、前記サービス（２８）が受信する情報がユーザアカウントに連関されたセキュリティデバイス（１６；１８）に由来する第２の認証情報に基づいている手段と、
−  前記第１の認証情報および前記認証のセキュリティデバイス管理機構（３４）から受信した情報に基づいて、認証を行なう手段と、
を含むデバイス。
【請求項１２】
データネットワーク（２６）上でサービス（２８）のユーザアカウントにアクセスするための認証のセキュリティデバイス管理機構（３４）において、
−  セキュリティデバイス（１６；１８）に由来する認証情報を受信する手段と、
−  第２の認証情報に基づく情報を前記サービス（２８）に送信する手段と、
を含む管理機構。
【請求項１３】
マイクロプロセッサによりロードされ実行される場合の、請求項１〜１０のいずれか一項に記載の認証方法を実施するための命令を含むコンピュータプログラム。
【請求項１４】
請求項１〜１０のいずれか一項に記載の方法を実施するためのコンピュータプログラムの命令を含む、マイクロプロセッサ可読情報媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データネットワーク上で１つのサービスのユーザアカウントにアクセスするための認証方法、このようなサービスを実施するデバイスおよびセキュリティデバイス管理機構に関する。本発明は詳細には、このようなユーザアカウントにアクセスするためのユーザの多因子認証にも応用される。
【背景技術】
【０００２】
データネットワーク（例えばインターネットネットワーク）上にホストされかつ同様にこのデータネットワークに接続されているコンサルティングデバイスコンサルティングデバイスまたはコンサルティング端末からユーザがアクセスできるサービスは、増々多くなってきている。
【０００３】
このコンサルティングデバイスは、パソコン、多機能携帯電話（英語ではＳｍａｒｔｐｈｏｎｅ）、典型的にはキーボードの無いタッチスクリーンを含むパソコンであるタブレットあるいは、通信ネットワークに接続されユーザがサービスとインタラクトできるようにする他のあらゆるタイプの端末であり得る。
【０００４】
このようなサービスは、データネットワークに接続された１つ以上のサーバー上にホストされたソフトウェアアセンブリである。このソフトウェアアセンブリはコンサルティングデバイスに由来する要求を受信し、考慮対象のサービスを提供する形でこれに応答するようにプログラミングされている。このサービスは例えば、バンキングサービスさらにはソーシャルネットワークである。
【０００５】
このようなサービスに対するアクセスには、コンサルティングデバイスのユーザの認証が必要とされ得る。この場合、サービスは典型的に、ユーザデータベースまたはユーザアカウントと協働して機能する。
【０００６】
こうして、サービスにアクセスするためには、ユーザは、そのサービスに連関されたデータベースのユーザアカウントの１つに連関する１つ以上の認証情報を提供するよう求められる。ひとたび認証されたならば、ユーザは例えば、サービスがバンキングサービスである場合にはその銀行口座に、またはサービスがソーシャルネットワークである場合にはそのパーソナルプロフィールにアクセスすることができる。
【０００７】
認証には、ユーザが知っている秘密情報例えばユーザのユーザアカウントに連関されたパスワードなどをユーザが入力することを求められる場合がある。この場合、認証は、秘密情報が、サービスに連関されたデータベース内で問題のユーザアカウントのために記録された情報に対応する場合にのみ、有効となる。
【０００８】
しかしながら、従来の秘密情報によるユーザの認証は時としてサービスへのアクセスのセキュリティを保証するのに不充分である。
【０００９】
例えば、ユーザが、必ずしも互いに関連性のないさまざまなサービスに対する自らのアクセスを保護するために同一の情報、典型的には同一のパスワードを使用することは、極めて一般的である。こうして、この情報を発見した場合、悪意あるエンティティは、パスワードを用いてそのユーザになりすまして１つまたは複数のこれらのサービスにアクセスすることができる。
【００１０】
ユーザの認証を複雑化して前述のような１つのサービスに対するアクセスのセキュリティを改善するためには、多因子認証方法を実施することができる。
【００１１】
この方法は、大部分がユーザが知る秘密情報（例えばパスワード）とユーザ自身を特徴づける情報、典型的にはバイオメトリック情報（例えば、指紋、眼の虹彩）および／またはユーザに帰属する物体を介して得られる情報（例えばユーザの端末上に表示されるコード）の併用に基づいている。
【００１２】
単一の因子による（唯一のタイプの情報を使用する）従来の認証方法とは異なり、悪意あるエンティティが異なるタイプのこれらの情報の１つを発見した場合でも、保護されたサービスにアクセスすることはできない。
【００１３】
しかしながら、それが認証のセキュリティを改善できるにしてもこれらの情報を得るためにはサービスへのアクセスを望むユーザを介入させる場合が多く、これはユーザエクスペリエンスにとって有害であり得る。
【発明の概要】
【発明が解決しようとする課題】
【００１４】
したがって、ユーザにとって可能なかぎり透明な形で、既存の認証プロセスのセキュリティを改善する必要性が存在する。
【課題を解決するための手段】
【００１５】
したがって、本発明の目的は、これらの欠点のうちの少なくとも１つを改善することにある。
【００１６】
この状況下で、本発明の第１の態様は、データネットワーク上で１つのサービスへのユーザアカウントにアクセスするための認証方法において、
−  前記サービスのコンサルティングデバイス側からの要求をサービスが受信するステップであって、前記要求が第１の認証情報を含んでいるステップと、
−  認証のセキュリティデバイス管理機構が送った情報をサービスが受信するステップであって、サービスが受信する情報がユーザアカウントに連関されたセキュリティデバイスに由来する第２の認証情報に基づいているステップと、
−  第１の認証情報および認証のセキュリティデバイス管理機構から受信した情報に基づいて、サービスが認証を行なうステップと、
を含む方法に関する。
【００１７】
したがって、本発明に係る方法は、認証のセキュリティを改善できるようにする。
【００１８】
このことは、認証が特に、２つの異なるデバイス、すなわちコンサルティングデバイスおよびユーザアカウントに連関されたセキュリティデバイスに由来する２つの認証情報に基づいているという事実に起因している。
【００１９】
さらに、セキュリティデバイスにより送信される要求は、ユーザの多因子認証に必要な他の情報を獲得を開始させ、しかもここでユーザがこの補足的情報の送信を提案するかまたは自らその送信を考える必要はないため、ユーザエクスペリエンスは改善される。
【００２０】
こうして、見かけ上、この方法はユーザにとって従来の認証方法に似てはいるが、実際には認証はよりセキュア化されている。要求は、サービスの開設または始動に限定されない。要求は、ユーザによるコンサルティングデバイスからのこのサービスの使用をも目的とすることができる。
【００２１】
本発明の実施形態に係る方法の他の特徴は、従属クレーム中に記載されている。
【００２２】
一部の実施形態において、特にサービスが管理機構の機能性を内蔵している形態においては、認証ステップは管理機構により実施され得る。
【００２３】
本発明の特定の実施形態において、第２の情報は、セキュリティデバイスに対して管理機構が送った要求に応答して管理機構により受信される。
【００２４】
一変形形態において、第２の認証情報は、管理機構が接続された時点で管理機構に対しセキュリティデバイスによって自発的に送信される。
【００２５】
本発明の特定の実施形態において、サービスが受信する前記情報は、セキュリティデバイスにより送信された第２の認証情報に対応する。
【００２６】
したがって、サービスは、それ自体第１および第２の認証情報の検証を実施してユーザを認証する。
【００２７】
一変形実施形態において、管理機構は、セキュリティデバイスが受信した第２の認証情報を検証し、管理機構によりサービスに送信される情報はこの検証の結果に対応する。
【００２８】
したがって、管理機構は、自ら第２の認証情報を検証し、この検証の結果（情報）をサービスに伝送することができる。
【００２９】
本発明の特定の実施形態において、第２の認証情報はセキュリティデバイスの位置特定情報を含む。
【００３０】
本発明の特定の実施形態において、位置特定情報は、ローカルネットワークとサービスをホストするデータネットワークとの間のゲートウェイのアドレスを含み、前記ローカルネットワークはセキュリティデバイスとコンサルティングデバイスとを接続している。
【００３１】
これらの態様において、コンサルティングデバイスとセキュリティデバイスは同じローカルネットワークに属し、サービスをホストするデータネットワークに対して同じパブリックアドレス（すなわちゲートウェイのアドレス）によって特徴づけ可能である。これに対し、ローカルネットワークに接続されているデバイスの各々は、ローカルネットワーク内に独自のプライベートアドレスを有するが、このプライベートアドレスは、管理機構またはサービスなどのデータネットワークのデバイスによって必ずしも知られているわけではない。
【００３２】
したがって、ローカルネットワークとデータネットワークの間のゲートウェイのアドレスは、補足的な１つの認証因子を構成し、こうしてサービスへのアクセスをより一層セキュア化することができる。
【００３３】
一変形形態において、位置特定情報は、地理的座標あるいはまたランドマークの総体であり得る。これらの情報は、ＧＰＳ位置、ＧＳＭ（登録商標）三角測量（ＧＳＭ位置特定）、さらにはＷｉ−Ｆｉ位置特定により提供可能である。
【００３４】
本発明の特定の実施形態において、第２の認証情報は、セキュリティデバイス内に記憶された秘密に基づくワンタイムコードを含む。
【００３５】
本発明の特定の実施形態において、セキュリティデバイスは、セキュリティデバイスにより起動される持続的接続を用いて管理機構に接続されている。
【００３６】
したがって、これらの形態において、管理機構およびセキュリティデバイスはこのとき、ユーザが自らの認証を試みる基礎とするコンサルティングデバイスとは独立した形で直接交信できる。
【００３７】
本発明の特定の実施形態において、セキュリティデバイスとユーザアカウントの連関には、
−  セキュリティデバイスにより提示されたコードをコンサルティングデバイス上で入力するステップと、
−  入力されたコードをサービスに送信するステップと、
−  サービスが連関を起動するステップと、
が含まれる。
【００３８】
これらのステップは、セキュリティデバイスとユーザアカウントとの予備的連関を実施することを目的としている。
【００３９】
入力されたコードは、セキュリティデバイスの一意的ＩＤに基づくものであり得る。
【００４０】
したがって、コードは、例えば対応表を用いて、セキュリティデバイスを再度発見することを可能にすることができる。詳細には、入力されたコードは、セキュリティデバイスの一意的ＩＤに直接対応することができる。こうしてコードはセキュリティデバイスを直接指定する。
【００４１】
変形形態において、入力されたコードは、カラーコードまたはセキュリティデバイスとは独立した（または少なくともそのＩＤとは異なる）セキュリティデバイス上に表示された番号に基づくものであり得る。
【００４２】
したがって、セキュリティデバイス上での回収の後のコンサルティングデバイスによるサービスに対するこのコードの入力および送信によって、セキュリティデバイスがサービスのユーザアカウントに有効に結合されていることを示すことが可能である。
【００４３】
入力は、書込みまたは音声（口述）によるものであってよい。このコードは、例えばセキュリティデバイス上に表示される一時的なものであっても、あるいは一変形形態として、例えばセキュリティデバイス上に印刷または刻印される永久的なものであってもよい。
【００４４】
入力されサービスにより受信されたコードは、ユーザアカウントと連関されて、サービスに連関されたデータベース内に記録され得る。
【００４５】
セキュリティデバイスとユーザアカウントの連関は、さらに、以下のステップを含むことができる。
−  セキュリティデバイス管理機構に対して、サービスが受信したコードを送信するステップと、
−  管理機構による受信されたコードの検証ステップ。
【００４６】
こうして、デバイスとユーザアカウントの連関は、さらに一層セキュア化される。変形形態では、サービスはそれ自体、自らに連関されたデータベースと協働してコードを検証することができる。
【００４７】
管理機構により検証されたコードは、サービスのＩＤと連関された状態で、管理機構に連関されたデータベース内に記録され得る。
【００４８】
本発明の特定の実施形態において、管理機構による第２の認証情報の受信には、コンサルティングデバイスのユーザの確認が必要とされる。
【００４９】
例えば、これにより、認証中にユーザの位置特定因子を加えることができる。
【００５０】
例えば、確認は、別のデバイス上でボタンを押すこと、さらには指紋などの生体情報を提供することから成っていてよい。これにより、ユーザを認証するために補足的因子（例えば網膜その他の生体紋様の有効性）を考慮に入れることが可能になる。
【００５１】
バイオメトリック有効化は、補足的な信頼性レベルをもたらし、特にユーザが認証情報の送信の時点で存在していることの証明を可能にする。
【００５２】
例えば、これにより、認証中にユーザの位置特定因子を加えることができる。
【００５３】
本発明の第２の態様は、データネットワーク上でサービスを実施するデバイスにおいて、
−  前記サービスのコンサルティングデバイス側からの要求を受信する手段であって、前記要求が第１の認証情報を含んでいる手段と、
−  認証のセキュリティデバイス管理機構が送った情報を受信する手段であって、サービスが受信する情報がユーザアカウントに連関されたセキュリティデバイスに由来する第２の認証情報に基づいている手段と、
−  第１の認証情報および認証のセキュリティデバイス管理機構から受信した情報に基づいて、認証を行なう手段と、
を含むデバイスに関する。
【００５４】
本発明の第３の態様は、データネットワーク上でサービスのユーザアカウントにアクセスするための認証のセキュリティデバイス管理機構において、
−  セキュリティデバイスに由来する認証情報を受信する手段と、
−  第２の認証情報に基づく情報をサービスに送信する手段と、
を含む管理機構に関する。
【００５５】
このようなセキュリティデバイス管理機構は典型的には、同様にデータネットワーク上にホストされている１つ以上のサービスのユーザアカウントに連関する一群のセキュリティデバイスを管理することのできる、データネットワーク上にホストされたサーバーである。
【００５６】
セキュリティデバイスと管理機構の間および／またはサービスと管理機構の間、および／またはサービスとコンサルティングデバイスの間の交換は、ＩＳＯ７８１６規格（ＡＰＤＵスクリーン）に適合したものであり得る。
【００５７】
セキュリティデバイスは、例えば、ユーザインターフェイスが備わったセキュリティコンパニオン（例えばｌｅｄｓ）、ＥＴＳＩ  ＴＲ  １０２２１６規格にしたがったチップカードまたはＵＩＣＣ（Ｕｎｉｖｅｒｓａｌ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ  Ｃａｒｄ）、さらには、セキュア化されたアプリケーションを実行する多機能携帯電話（英語ではＳｍａｒｔｐｈｏｎｅ）であり得る。
【００５８】
セキュリティデバイスは、搭載型（ｅＳＥ）または取外し可能なセキュリティ化素子を含むことができる。
【００５９】
本発明の異なる態様に係るデバイスの詳細な利点、目的および特徴は、上述の方法のものと類似である。
【００６０】
特定の一実施形態において、上述の方法の異なるステップは、コンピュータプログラムの命令によって決定される。
【００６１】
したがって、本発明は、マイクロプロセッサにより実施され得、上述の方法のステップの実施に適応された命令を含む、情報媒体上のコンピュータプログラムをも目的としている。
【００６２】
このプログラムはあらゆるプログラム言語を使用することができ、ソースコード、オブジェクトコードまたはソースコードとオブジェクトコードの間の中間コードの形、例えば部分コンパイル型、あるいは他の所望されるあらゆる形の言語、例えばスクリプト言語を使用することができる。
【００６３】
本発明は同様に、以上の通りのコンピュータプログラムの命令を含む、マイクロプロセッサ可読情報媒体をも目的としている。
【００６４】
情報媒体は、プログラムを記憶できるあらゆるエンティティまたはデバイスであってよい。例えば、媒体は、記憶手段、例えばＲＯＭ、例えばマイクロ回路ＲＯＭ、さらには磁気記憶手段、例えばハードディスク、フラッシュメモリー、あるいは光学記録手段、例えばＣＤ、ＤＶＤさらにはブルーレイを含み得る。
【００６５】
他方では、情報媒体は、伝送可能媒体、例えば、無線または他の手段により電気または光ケーブルを介して導かれ得る電気または光信号であってよい。本発明に係るプログラムは、詳細には、インターネットタイプのネットワークの記憶プラットホーム上にダウンロード可能である。
【００６６】
代替的には、情報媒体は、プログラムが内蔵されている集積回路であってよく、回路は、問題の方法を実行するため、またはその実行において使用するように適応されている。
【００６７】
上述の情報媒体およびコンピュータプログラムは、それらが実施する方法と類似の特徴および利点を有する。
【００６８】
本発明の他の特長および利点は、全く非限定的である本発明の実施例を示す添付図により例示されている以下の説明の中でさらに明らかになる。
【図面の簡単な説明】
【００６９】
【図１】特定の実施形態に適合した本発明の異なる態様に係るデバイスが表わされている１つの状況を例示している。
【図２】本発明の特定の実施形態に係る認証方法中に介入する主要な交換を、クロノグラムの形で表わしている。
【図３】本発明の特定の実施形態にしたがったユーザアカウントとセキュリティデバイスの連関ステップを、クロノグラムの形で表わしている。
【発明を実施するための形態】
【００７０】
一般的に、本発明は、さまざまなサービスをホスト（he'berger（供給））できるデータネットワーク上でサービスのユーザアカウントにアクセスするためのユーザの多因子認証に関する。
【００７１】
認証の多因子態様は、ここでは、ローカルネットワークに関連する２つの異なるデバイスを介入させるという特長を有する。これら２つのデバイスは、典型的には、ユーザがそこからのサービスの使用を所望しているサービスコンサルティングデバイスと、ユーザの認証とより一層のセキュア化を担うセキュリティデバイスである。
【００７２】
一般的に、本発明の論点は、ユーザをサービスに接続するプロセスにおいて、そのコンサルティングデバイスから得た第１の認証情報を確認するための第２の認証情報を獲得することによって、ユーザの認証をセキュア化することにある。この第２の認証情報は、この認証のセキュア化を目的としてユーザアカウントに予め連関させられているセキュリティデバイスに由来する。
【００７３】
ユーザアカウントとセキュリティデバイスの連関または結合オペレーションは、いわゆる認証オペレーションに先立ち１回しか実施されない。この予備結合により、ユーザにとってできるかぎり透明な認証を維持することが可能になる。
【００７４】
一部の実施形態において、第２の認証情報は、サービスがセキュリティデバイスから直接獲得される。
【００７５】
このために、セキュリティデバイスは、サービスに対して持続的接続を開くことができる。この接続により、サービスが例えば、第２の認証情報を得るための要求を送信すること、そして、このように接続されたセキュリティデバイス側からのその応答を受信することが可能になる。
【００７６】
この持続的接続は、それがセキュリティデバイスの主導の下にある場合、さらに、より大域的なネットワーク（ここではデータネットワーク）に対するローカルネットワークのデバイスの（例えばファイアウォールを用いた）限定されたアクセスに連関する問題の解決をも可能にする。
【００７７】
変形形態においては、第２の認証情報は、管理機構またはサービスに対してセキュリティデバイスにより自発的に送られてよい。この第２の認証情報の自発的送信は、周期的であってよい。例えば、セキュリティデバイスは、それが起動状態にあるかぎり規則的に第２の情報を送信することができ、こうしてその接続解除は送信の中断に対応することから容易に検出可能である。
【００７８】
変形形態において、送信は特定の事象により開始され得る。
【００７９】
この特定の事象は、例えばユーザとセキュリティデバイス間の相互作用である。例えば、これはユーザによるボタンの押圧であり得る。
【００８０】
第２の情報は、あらゆるアクセス要求とは独立して、セキュリティデバイスにより送られてよい。
【００８１】
変形形態において、特定の事象は、サービスへのアクセス要求の受信に対応し得る。
【００８２】
一部の実施形態において、認証情報は、第２の認証情報を含むセキュリティデバイスの応答のソースアドレスが、コンサルティングデバイスにより発せられたサービスに対するアクセス要求のソースアドレスに対応する場合に確認される。これにより、セキュリティデバイスおよびサービスへのアクセスのために使用されるコンサルティングデバイスが同じローカルネットワーク（ＬＡＮ）に接続されていることを検証することができる。ソースアドレスの予期された類似性は、典型的に同じローカルネットワークに接続された異なるデバイスが同じゲートウェイを介してデータネットワークと交信すること、そしてこのゲートウェイが典型的にアドレス変換プロトコルＮＡＴ（英語でＮｅｔｗｏｒｋ  Ａｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ）を実装することに起因している。
【００８３】
したがって、このときローカルネットワークに接続されたデバイスに由来する全てのメッセージは、データネットワーク上のゲートウェイのアドレスに対応する同じソースアドレスを有する。ゲートウェイのアドレスは、ここでは、ゲートウェイへのアクセス提供者により割り当てられたローカルネットワークに接続されたデバイス（ここでは少なくともセキュリティデバイスとコンサルティングデバイス）のパブリックアドレスに対応する。
【００８４】
一般的に本発明は、ユーザアカウントの第２の認証情報として管理機構またはサービスが、セキュリティデバイスと同じローカルネットワークに接続されたセキュア化済みデバイスの位置特定を可能にする位置特定情報を受信する態様をも網羅している。
【００８５】
この位置特定情報は、ローカルネットワークとデータネットワーク間のゲートウェイアドレス以外のものであってよい。例えば、これはゲートウェイの地理的座標、例えばＧＰＳ座標またはＧＳＭ三角測量さらにはＷｉ−Ｆｉ位置特定により得られる座標であり得る。
【００８６】
一部の実施形態において、この第２の認証情報は、セキュリティデバイスが発するもう１つの認証情報によって置換または補完される。
【００８７】
これは例えば、セキュリティデバイスにより生成されるワンタイムパスワード、さらにはユーザに対しデバイスが要請するバイオメトリック情報、例えば指紋または虹彩読取りであり得る。
【００８８】
この場合、サービスに対するアクセスのセキュリティをさらに強化する目的でユーザが寄与する。この場合、この寄与に起因するアクセスセキュリティの増大は、もはやユーザにとって全面的に透明なものではなくなるが、極めて重要なサービス用としては正当化され得る。
【００８９】
こうして、実施形態によると、サービスまたは管理機構は、例えば、セキュリティデバイスから得た応答メッセージのソースアドレスとサービスが獲得しかつ／または伝送するアクセス要求のソースアドレスとを比較することによって第２のセキュリティ情報の検証を担っている。
【００９０】
一般的に、簡略化を期して以下で使用する「アクセス要求」という用語は、コンサルティングデバイスとサービスの間の通信セッションの開設または始動時においてコンサルティングデバイスがサービスに対して送信する要求に限定されない。この用語は同様に、ユーザによるこのサービスの利用全体にわたり（またはその間に）コンサルティングデバイスがサービスに対して送信する要求をも対象としている。
【００９１】
本発明により、セキュリティデバイスとユーザアカウントの予備連関という単純なオペレーションにより、その後、サービスの自らのユーザアカウントに対するアクセスを所望するユーザをより一層セキュア化された形で認証するための単純かつセキュア化された手順を入手することが可能になる。
【００９２】
本発明のもう１つの利点は、セキュリティデバイスとサービスの間の通信がコンサルティングデバイスから独立したものであるという点にある。
【００９３】
こうして、コンサルティングデバイスが例えば悪意あるウイルスなどに感染した場合、セキュリティデバイスにより提供された補足的認証情報（第２の認証情報）は、コンサルティングデバイスを介して移送されることが一切無いために発見または操作され得ない。
【００９４】
図１は、特定の実施形態にしたがった本発明の異なる態様に係るデバイスが表わされている状況を例示している。
【００９５】
これらのデバイスは、以下で説明するステップを含む本発明に係る認証方法を実施することができる。
【００９６】
図１では、コンサルティングデバイス（dispositif de consultation）１０は、通信リンク１４を用いてＬＡＮ（英語のＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋの略）ローカルネットワークに接続されている。
【００９７】
このコンサルティングデバイス１０は例えば、ポータブルコンピュータまたは携帯端末（例えばタッチ式タブレットまたは電話）である。したがってそのアーキテクチャは、ＰＣまたは端末の従来の基本アーキテクチャの構成要素を少なくとも含んでいる。これらの公知の要素については、さらに詳述しない。
【００９８】
一部の実施形態によると、コンサルティングデバイス１０はさらに、仮想または物理的キーボード、生体紋様センサー、音声解析／認識モジュール、人相認識モジュール、網膜解析モジュール、またはこのコンサルティングデバイス１０のユーザによる認証情報の提供（入力）を可能にする他のモジュールを含むことができる。
【００９９】
ローカルネットワーク１２は例えば、イーサネットネット（登録商標）ワークであってよく、通信リンク１４は例えばイーサネットケーブルであり得る。
【０１００】
変形形態において、ローカルネットワーク１２は、Ｗｉ−Ｆｉネットワークであってよく、このとき通信リンク１４はワイヤレス接続であり得る。
【０１０１】
ローカルネットワーク１２は、通信リンク１４と同様、別のタイプのものであり得る。ローカルネットワーク１２は、Ｂｌｕｅｔｏｏｔｈ（登録商標）ネットワーク、家庭用または個人用ネットワークであってよく、あるいはまた、例えば企業のイントラネットネットワークに対応してもよい。
【０１０２】
１６および１８と付番された他のデバイスも同様に、それぞれ２０および２２と付番された通信リンクを介してローカルネットワーク１２に接続され得る。これらのデバイスは、本発明の実施形態に係る認証セキュリティデバイスである。
【０１０３】
一般的に、セキュリティデバイスは典型的に国際規格ＩＳＯ／ＣＥＩ１５４０８（ＦＩＰＳ）にしたがったコモンクライテリアに準拠している。
【０１０４】
この例では、２つのセキュリティデバイスが表わされているが、本発明は、１つ以上のセキュリティデバイスを伴う場合も網羅している。この例では、セキュリティデバイス（dispositif de se'curisation）１６は例えばＬｅｄｓの備わったセキュリティコンパニオンである。
【０１０５】
このセキュリティコンパニオン１６は、例えば本発明の実施形態に係る認証方法のステップに対応する命令の実施に適応させられた、セキュア化された素子を含むことができる。
【０１０６】
これらの命令は、例えばアプレットＪａｖａＣａｒｄの形、またはネイティブコードの断片の形をしている。
【０１０７】
セキュリティデバイス１８は例えば、電話により実施され得るセキュリティアプリケーションをメモリー内に含む携帯電話である。
【０１０８】
例えば、電話１８は、例えば本発明の実施形態に係る認証方法のステップの実施に適応させられたセキュア化された素子を搭載することができる。
【０１０９】
このセキュア化された素子は例えば、ＳＩＭ（英語でＳｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ  Ｍｏｄｕｌｅの略）カード、ＵＳＩＭまたはマイクロＳＩＭカードである。
【０１１０】
セキュリティデバイス１６および１８は同様に、生体紋様センサー、網膜解析モジュールおよび／または人相認識モジュールを備えていてよい。
【０１１１】
簡略化を期して、以下の説明において方法は無差別にセキュリティデバイス１６およびデバイス１８に関わるものとする。
【０１１２】
以下では、方法に関してセキュリティデバイス１６について記述されていることは、セキュリティデバイス１６および１８に関して記述されているものと類似の特徴を有する、補足的認証因子を提供または追加することでユーザの認証のセキュリティデバイスの役割を果たすことのできる全ての装置にあてはまる。
【０１１３】
ローカルネットワーク１２は、このローカルネットワーク１２外に位置するネットワーク内にあるデバイスに向けた、ローカルネットワーク１２由来のデータパケット用のルーターの役割を果たすゲートウェイＧＴＷ（英語でＧａｔｅｗａｙの略）２４を含むかまたはこれに接続されていてよい。
【０１１４】
例えば、ローカルネットワーク１２は、ゲートウェイ２４を介して、データネットワーク（re'seau de donne'es）ＷＡＮ（英語でＷｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋの略）２６、例えばインターネットネットワークに接続される。
【０１１５】
変形形態では、ゲートウェイ２４は、データネットワーク２６に直接接続されるかまたはこのデータネットワーク２６の一部を成すことができる。
【０１１６】
ローカルネットワーク１２由来でデータネットワーク２６のデバイスに向けたデータパケットのルーティングを行なうために、ゲートウェイ２４は、ＮＡＴ（英語でＮｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎの略）タイプのルーティング技術を使用することができる。
【０１１７】
この技術の使用は特に、対応するソースアドレスからゲートウェイ２４のアドレスまでゲートウェイ２４により伝送されるデータパケットをスタンプする効果を有する。
【０１１８】
したがって、データネットワークの観点から見ると、ローカルネットワーク１２に接続されたデバイスが発出するデータパケットは、共通の原始アドレスを有する。
【０１１９】
本発明は、一部の実施形態において、以下でさらに詳述する通り、補足的認証因子としてこの共通の特徴を使用することを想定している。
【０１２０】
他方で、ローカルネットワーク１２は、通信リンク３０を用いて、ゲートウェイ２４およびデータネットワーク２６を介してサービス（service）２８に対するアクセスデバイスに接続されている。
【０１２１】
データネットワーク２６上では複数のサービスが利用可能であるが、簡略化を期して、サービス２８のみが表わされている。このデータネットワーク上さらには異なるデータネットワーク上で複数のサービスが利用可能である場合、このサービスに関する教示を適応させることは、当業者の技量の範囲内にある。
【０１２２】
サービス２８は、以下でさらに詳述する通り、認証情報、例えばＩＤ／パスワード対ならびに、例えば認証に介入するユーザアカウントに連関されたデバイスの識別を可能にするコードなどのさまざまな情報と連関させてユーザアカウントが記憶されているデータベース３２を含むか、またはこのデータベースにリンクされてよい。
【０１２３】
コンサルティングデバイス１０は、以下の記述において説明される通り、認証の成功を条件として、通信リンク１４および３０およびゲートウェイ２４によって、サービス２８にアクセスできる可能性がある。
【０１２４】
セキュリティデバイスの管理機構（gestionnaire）（またはフリート管理機構）３４は同様にデータネットワーク２６に接続されてよい。このとき、この管理機構は、１つ以上のサービスとリンクした状態で全ユーザのためのセキュリティデバイス全体の管理を担っている。それは典型的には、セキュリティデバイスの提供者により管理される。
【０１２５】
この管理機構は、例えば一部の認証情報の獲得ならびに場合によってはそれらの処理など、ユーザアカウントのセキュリティに関係する一部のタスクをサービスに免除することができるようにする。
【０１２６】
対応するサービスはこうして、そこにアクセスするための認証のセキュリティレベルの改善によって誘発される補足的処理にも関わらず、そのサービス品質を維持する。
【０１２７】
管理機構３４は固定ドメイン（ＤＮＳ）によって特徴づけされ、データベース３６と協働して、データネットワーク２６に接続されたセキュリティデバイス（例えば１６および１８）ならびにそれらの接続状態をリストアップできるようにする。
【０１２８】
セキュリティデバイスの管理機構３４はさらに、通信リンク３８を用いて、サービス２８に接続されている。
【０１２９】
したがって、連関されたデータベース３６はデバイスのＩＤだけでなくサービスのＩＤも記憶する。以下で本発明に係る方法のステップに関してさらに詳細に説明する通り、このデータベース３６は同様に、データネットワーク上で識別されたサービスのユーザアカウントのセキュリティデバイス間の結合コードを記憶することもできる。
【０１３０】
セキュリティデバイスの管理機構３４は同様に、ゲートウェイ２４と共にリンク４０を用いてローカルネットワーク１２にも接続される。こうして、ローカルネットワーク１２のデバイスがデータネットワークへのアクセスを所望する場合、このデバイスは、管理機構３４に対して自らのＩＤと共に接続要求を送信することができる。これに応答して、管理機構３４は、データベース３６内にこのデバイスの（一意的）ＩＤを記憶することができる。
【０１３１】
このＩＤは例えばセキュリティデバイスのＭＡＣアドレスであり、接続要求の原始アドレスがローカルネットワークに接続された全てのデバイスに共通であるという事実にも関わらず、ローカルネットワーク内でセキュリティデバイスを再度発見することを可能にする。
【０１３２】
その後、管理機構は、例えばサービス２８などのデータネットワークのサービスのユーザアカウントとこのセキュリティデバイスの間の結合を記憶することができる。ユーザアカウントとセキュリティデバイスの連関については、以下で、とりわけ図３を参照しながら詳述する。
【０１３３】
他の実施形態において、各サービス（例えばサービス２８）は、ユーザアカウントとセキュリティデバイスの連関をそれ自体管理するように設計されている。
【０１３４】
これらの形態において、ローカルネットワーク１２のデバイスがデータネットワークへのアクセスを所望する場合、サービス２８に対しそのＩＤと共に接続要求を送信することができる。そして応答して、サービス２８は、例えば、存在する場合１つまたは複数のユーザアカウントと連関して、付随するデータベース３２内にこのデバイスのＩＤ（一意的）を記憶することができる。
【０１３５】
簡略化を期して、以下の記述は非限定的に、インターネットデータネットワークの場合に集中させられている。異なるデバイスは特にそのＩＰアドレスにより表わされ、交換はインターネットプロトコルに準拠している。これに関連して、サービスはウェブサービスであり、ウェブサービスへのアクセスをユーザが所望するコンサルティングデバイス上で実行されるナビゲータを用いてアクセス可能なものである。
【０１３６】
好ましくは、セキュリティデバイス１６および１８と管理機構３４またはサービス２８との間の通信は、例えばＷｅｂ  Ｓｏｃｋｅｔプロトコル、ＴＣＰさらには宛て先に向かってメッセージを自発的に「プッシュ」できる（「ｐｕｓｈ」モード）ＸＭＰＰ  Ｃ英語でＥｘｔｅｎｓｉｂｌｅ  Ｍｅｓｓａｇｉｎｇ  ａｎｄ  Ｐｒｅｓｅｎｃｅ  Ｐｒｏｔｏｃｏｌｅの略）などの、持続的接続の維持を必要とする非同期通信プロトコルに準拠している。
【０１３７】
コンサルティングデバイス１０と管理機構３４の間（リンク１４および４０を介した）および／またはコンサルティングデバイス１０とサービス２８の間（リンク１４および３０を介した）および／またはサービス２８と管理機構３４の間（リンク３８を介した）の交換は、例えば、ＨＴＴＰ  ＧＥＴ／ＰＯＳＴタイプの要求を介して行なわれる。
【０１３８】
したがって、コンサルティングデバイス１０とサービス２８の間の交換を可能にするプロトコルは、典型的にＨＴＴＰ（英語でＨｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）プロトコルおよび、セキュア化バージョン用のＨＴＴＰＳなどの付随するプロトコルである。
【０１３９】
変形形態では、必要な場合にセキュリティデバイス１６（あるいは１８）を検出するために、仮想発見技術を使用することができる。この場合、通信チャネル２０〜４０は、セキュリティデバイス１６（あるいは１８）が、コンサルティングデバイス１０に対し（例えばＵＳＢリンクによって）連結されたローカルバス上に直接接続されている場合にのみ開設される。発見技術は同様にＷｉ−ＦｉまたはＢｌｕｅｔｏｏｔｈを使用することもできる。ただし、本発明は、このタイプの交換および通信に限定されない。これは同様に、所有権を主張できる他の通信プロトコルでもあり得る。
【０１４０】
ここで図２を参照して、本発明の特定の実施形態に係る認証方法のステップについて記述する。ここでは、前記方法を同時に実施するように適応された図１の異なるデバイスを参考にする。
【０１４１】
初期化ステップＥ１０の間、ローカルネットワーク１２のセキュリティデバイス１６（あるいは１８）は、データネットワーク２６のセキュリティデバイス管理機構３４と接触して、このネットワークに接続される。
【０１４２】
実際には、セキュリティデバイス１６（あるいは１３）のＩＤ（例えばＭＡＣアドレスまたは共有秘密）が、管理機構３４に付随するデータベース３６内に記憶され、それに対して「起動」状態が連関される。こうしてリンク２０（あるいは２２）および４０で構成された通信チャネルが、開設状態に維持される。
【０１４３】
この通信チャネルは専用チャネルであり、そのため、使用される通信プロトコルが許す場合、管理機構はこの通信チャネルによりセキュリティデバイス１６（または１８）に対して「プッシュ」通知を送信することができる。
【０１４４】
セキュリティデバイスは、管理機構に対しデータを自発的に送信するように装備されていてよい。
【０１４５】
ステップＥ２０の間に、データネットワーク２６のサービス特にウェブサービス２８のユーザアカウントを有する可能性のあるユーザが、自らのユーザアカウントへのアクセス要求を出す。
【０１４６】
サービス２８に対するアクセスは、ユーザがサービスに対して自らの認証に成功した場合にのみ可能である。
【０１４７】
実際には、ユーザはコンサルティングデバイス１０上に設置されたナビゲータ内にウェブページを開設することができ、このウェブページがウェブサービス２８との接触を可能にする。
【０１４８】
ユーザはウェブページを介して、第１の認証情報を提供し、サービス２８宛ての要求の中でこの第１の情報を送信する。
【０１４９】
ユーザ由来のこの第１の認証情報は、サービス２８による獲得がこの情報の提供におけるユーザの関与を証明する程度のものである。この情報は、目的のユーザアカウントを識別しユーザを少なくとも部分的に認証できるようにする。
【０１５０】
例えば、これは、ユーザが知っている秘密情報、典型的にはユーザがウェブページを介して提供するパスワードであってよい。
【０１５１】
認証情報は同様に、ユーザ自身を生物学的に特徴づけすることもできる。認証情報は指紋から成るか、人相認識の結果であるか、あるいはユーザの網膜の解析の結果であってよい。
【０１５２】
このタイプの情報は、サービス２８へのアクセスをユーザが試みるコンサルティングデバイス１０の適応されたセンサーおよびモジュール、例えば生体紋様センサー、人相認識モジュールまたは網膜解析モジュールによって捕捉可能である。
【０１５３】
第１の認証情報は同様に、例えば別のデバイス（セキュリティデバイス１６または１８）からその内容を認識した後にユーザが入力した情報であってもよい。
【０１５４】
この内容認識は、別のデバイス上に表示されたコード（カラーコード、図案、ワード…）の読取りによる視覚的なものであっても、あるいは別のデバイス上に書込まれたもの（例えば刻印されたもの）であってもよい。
【０１５５】
内容認識は同様に、音響によるもの、例えば別のデバイスが流す音響メッセージの聴取によるものであってもよい。
【０１５６】
こうして、ウェブページを介した第１の認証情報の入力は、コンサルティングデバイス１０上でキーボードを用いて行なうことができる。変形形態では、コンサルティングデバイス１０が音声認識に適応された手段を含むのであれば、情報は口述であってよい（音声入力）。
【０１５７】
２つの入力モードの組合せも同様に、本発明により網羅されている。
【０１５８】
アクセス要求を受信した時点で、サービス２８は第１の認証情報を抽出し、それを付随するデータベース３２を用いて処理する。
【０１５９】
このために、サービス２８は、コンサルティングデバイスの要求中に存在するＩＤに連関されたユーザアカウントとデータベース３２内の認証情報（例えばパスワード、指紋、網膜）との間の対応を検証することができる。
【０１６０】
変形形態において、サービスはこの検証を、方法の中のより遅い時点、例えば後述する認証ステップの間に実施する。
【０１６１】
サービス２８は同様に、コンサルティングデバイスの要求の原始アドレスを抽出して、場合により後でそれをユーザの補足的認証因子として使用することもできる。
【０１６２】
図１を参照しながら説明した通り、このソースアドレスは、要求が由来したローカルネットワーク１２（コンサルティングデバイス１０はリンク１４によりこのローカルネットワーク１２に接続されているため）とサービス２８がリンク３０を用いて接続されているデータネットワーク２６との間のゲートウェイ２４のアドレスに対応する。
【０１６３】
サービス２８は、次にデータベース３２から、同様にユーザアカウントに連関された結合コードに対応するコードを抽出することができる。
【０１６４】
一般的に、結合コードは、ユーザの認証のセキュア化を目的としてサービスのユーザアカウントとこのアカウントに付随するデバイスとの間の連関を表わす。
【０１６５】
結合コードは、直接的に（ＩＤ）または間接的に（例えば対応表中のＩＤに対応し得るコード）セキュリティデバイスを特定することを可能にする。
【０１６６】
ユーザアカウントは、複数の付随するデバイス、ひいてはサービスに付随するデータベース内の複数の付随する結合コードを有することができる。
【０１６７】
ステップＥ３０中、サービスは、コードに対応するセキュリティデバイスに由来する情報を回収することを目的とする情報要求を生成し送信する。この例において、情報要求は管理機構３４に送信される。
【０１６８】
管理機構に送信された情報要求は、以上で説明した通り、このアドレスを後で検証することを目的として、コンサルティングデバイスによる要求の原始アドレスを含んでいてよい。
【０１６９】
コードにより管理機構３４は、この情報を得るために対応するセキュリティデバイスを見い出すことができる。
【０１７０】
このために、情報要求を受信した時点で、管理機構３４は、自らに付随するデータベース３６中の結合コードの存在を検証し、同様にこのコードがサービス２８に正しく連関されていることも検証する。
【０１７１】
セキュリティデバイスは複数のサービスに連関され得、この理由から管理機構は別のサービスとの干渉をことごとく回避するためにコードがサービス２８に正しく連関されていることを検証するのが有利であり得る。
【０１７２】
該当する場合、管理機構３４はデータベース３６から、ここではセキュリティデバイス１６（あるいは１８）である、結合コードに連関されたデバイスのＩＤを抽出する。それができない場合、方法は停止し、ユーザは認証されず、サービスにアクセスできない。
【０１７３】
結合コードの記録、換言するとセキュリティデバイスとユーザアカウントとの連関については、図３を参照しながらさらに詳述する。
【０１７４】
その後、管理機構３４は場合によって、セキュリティデバイス１６（あるいは１８）の情報に連関された接続の状態を検証することができ、こうして、接続の状態が起動状態でない場合、方法は停止し、ユーザは認証されず、サービスにアクセスできない。
【０１７５】
この例において、ステップＥ１０で開かれた通信は維持され、セキュリティデバイス１６（あるいは１８）に連関された状態は「起動状態」である。
【０１７６】
ステップＥ４０の間に、管理機構３４は、ステップＥ１０で確立された通信チャネルを介して、認証情報（第２の認証情報）を得るためにセキュリティデバイスに対し認証要求を送信する。
【０１７７】
この第２の認証情報は、認証において「デバイス因子」を構成し、その生成は、（ステップＥ２０で送信されたアクセス要求の中に挿入される第１の認証情報とは異なり）ユーザがこの第２の認証情報の生成に介入しないことから、ユーザにとって理論上は透明である。
【０１７８】
第２の認証情報は例えば、データネットワーク２６中のセキュリティデバイス１６（あるいは１８）のアドレス、すなわちゲートウェイ２４のアドレスによって構成されている。
【０１７９】
こうして、ステップＥ４０において発出される要求は単純に、セキュリティデバイス１６（あるいは１８）が（ゲートウェイ２４を介して）データネットワークに常時接続されていることを確認するため、セキュリティデバイス１６（あるいは１８）に対して肯定応答（確認）を請求することからなる可能性がある。
【０１８０】
他の実施形態においては、管理機構とセキュリティデバイスとの間で「チャレンジ−レスポンス」機序を実施して、認証を強制する目的でセキュリティデバイスの存在をシミュレートする悪意あるデバイスによって接続が維持されていないことを確認することができる。
【０１８１】
変形形態において、セキュリティデバイスは、例えば規則的な形で、管理機構に対し認証情報を自発的に送信することができる。
【０１８２】
変形形態において、第２の認証情報は、セキュリティデバイス１６（あるいは１８）を認証できるようにするコードを含むことができる。
【０１８３】
このコードは例えば、セキュリティデバイス１６（あるいは１８）がセキュア化された素子を利用できる場合このような素子によってセキュリティデバイス１６（あるいは１８）の内部で生成される、ワンタイムおよび／または有効期限のあるコード（Ｔｅｍｐｏｒａｒｙ  Ｏｎｅ  Ｔｉｍｅ  Ｐａｓｓｗａｒｋ、略してＴＯＴＰ）であってよい。
【０１８４】
このコードは場合によっては管理機構３４と共有される秘密に基づくものであってよく、共有秘密は、例えばステップＥ１０における接続の確立の際に交換されたものである。変形形態において、この秘密はサービス２８と共有されてよい。
【０１８５】
実際には、秘密の確立は、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ（ＤＨ）の名前で公知の技術により通信セッションの開始段階の間に行なわれ得る。変形形態では、秘密は、セキュリティデバイスの提供者によってかまたは、ユーザアカウントとの連関段階中にサービスの提供者によって確立されたものであり得る。
【０１８６】
秘密は、例えばセキュリティデバイスのセキュア化された素子の中に記憶されてよい。
【０１８７】
諸形態において、第２の認証情報は、上述のローカルネットワークのアドレスとコードとを同時に含むことができる。
【０１８８】
任意のステップＥ４５の間、セキュリティデバイス１６（あるいは１８）は場合によって、管理機構３４に要求に対する応答を送信するために（例えばキーボードまたは生体紋様センサーを介して）ユーザに確認を要請することができる。
【０１８９】
この任意の確認は、ユーザがセキュリティデバイス１６（あるいは１８）の近くにいることを管理機構に保証するため、認証における補足的因子を構成する。
【０１９０】
セキュリティデバイス１６（あるいは１８）は、ステップＥ５０中に、管理機構３４によって発出された認証要求に対して応答する。
【０１９１】
その応答は、ゲートウェイ２４のアドレスを原始アドレスとする肯定応答の形および／または一時的コード（または管理機構３４に対するセキュリティデバイスの認証を可能にする他のあらゆる情報）を含むメッセージの形をとることができる。
【０１９２】
セキュリティデバイス１６（あるいは１８）の応答を受信した時点で、管理機構は、応答の原始アドレスを抽出し、ステップＥ３０において検証要求の中で受信されたアクセス要求の原始アドレスとの間の対応を検証することができる。
【０１９３】
変形形態において、管理機構は、サービス２８に対し応答の原始アドレスをそのまま移送して、サービスがアクセス要求の原始アドレスとの対応を検証できるようにしてもよい。
【０１９４】
この場合、ステップＥ５０においてサービスが要求した情報は、セキュリティデバイスによって発出される第２の認証情報に対応する。
【０１９５】
セキュリティデバイス１６（あるいは１８）が自らの認証のためのコードを送った場合、管理機構３４は、例えばコードが共有秘密に基づくものである場合にはこのような秘密を用いて、このコードを検証する。
【０１９６】
管理機構３４は次に、サービス２８に対してメッセージを送り（ステップＥ６０）、アドレスとコードが予期された値を有するか否かをサービスに知らせる。
【０１９７】
メッセージの内容に応じて、サービス２８はユーザを認証するかまたは認証しない。例えば、アドレスが対応することおよびコードが有効であることをメッセージがサービス２８に知らせた場合、サービス２８はユーザを認証し、例えばそのコンサルティングデバイス１０上に設置されたナビゲータを用いてユーザがそのユーザアカウントにアクセスできるようにするアクセス許可をステップＥ７０の間に送信する。
【０１９８】
変形形態では、管理機構は、サービス２８に対し直接コードを伝送して、サービス自体がコードの有効性を検証するようにすることができる。
【０１９９】
この場合、ステップＥ５０でサービスによって要求された情報は、セキュリティデバイスにより発出された第２の認証情報に対応する。
【０２００】
本発明は同様に、各サービスがそれ自体（管理機構３４無しで）セキュリティデバイスを管理する実施形態をも網羅している。これらの実施形態においては、サービスは、上述の例では管理機構３４が実施していたステップを自ら実施する。
【０２０１】
詳細には、これらの実施形態において、セキュリティデバイスはステップＥ１０でサービス２８に接続される。
【０２０２】
コンサルティングデバイス１０がアクセス要求を受信した（ステップＥ２０）後、サービス２８はステップＥ３０の間に、そのデータベース３２内で、セキュリティデバイスがユーザアカウントに正しく連関されていることを検証する。
【０２０３】
正しく連関されている場合には、サービスはステップＥ４０でセキュリティデバイスに直接情報要求を送って、第２の認証情報を得る。ステップＥ５０においてサービスは、応答として第２の認証情報を受信する。
【０２０４】
サービスは、例えばデータベース３２と協働してステップＥ６０においてその有効性を検証し、その後、認証情報が全て予期された値を有している場合ユーザの認証に着手する。
【０２０５】
この場合、サービス２８は、ステップＥ７０の間に、そのコンサルティングデバイス１０上に設置されて、ナビゲータを用いて、ユーザが自らのユーザアカウントにアクセスできるようにするアクセス許可を返送する。
【０２０６】
あらゆる場合において、サービス２８は、以下の因子が検証された場合にユーザを認証する。
−  ステップＥ２０で受信されたアクセス要求中に含まれた第１の認証情報の有効性、および
−  アクセス要求のソースアドレスと、管理機構３４由来の要求に対するセキュリティデバイス１６（あるいは１８）の応答との対応、および／または
−  セキュリティデバイス１６（あるいは１８）により発出されたコードがある場合には、その有効性。
【０２０７】
本発明は、以下で記述した異なる形態を組合わせた実施形態も網羅する。例えば、サービスがセキュリティデバイスとユーザアカウントの結合は行なうものの情報処理は管理機構に委託している形態、さらには、結合は管理機構によって行なわれるもののサービスが全ての認証データを処理している形態（この場合管理機構は異なるセキュリティデバイスにおいて要求された情報を回収することを担当していない）がある。
【０２０８】
図３は、本発明の実施形態に係る、ユーザアカウントとセキュリティデバイス１６（あるいは１８）の予備連関を例示している。ここでは、図１のデバイスが言及されている。
【０２０９】
この連関段階の目的は、サービスへのアクセスのためにユーザが使用するデバイス以外の１つ以上のデバイスとユーザアカウントとを結合して、補足的認証因子を構成しユーザの認証をさらに一層セキュア化することにある。この結合は、本質的にサービスによって、あるいは管理機構と協働して実施され得る。
【０２１０】
この後者の場合が、図３に表わされているが、以下では両方の場合について記述する。
【０２１１】
ステップＥ０の間、コンサルティングデバイス１０は、データネットワーク２６のサービス２８に対するアクセス要求を送信する。このステップは、図２を参照して記述されたステップＥ２０と類似している。このサービス２８に対するアクセスは、コンサルティングデバイス１０のユーザがこのサービスに対する自らの認証に成功した場合にのみ可能である。実際には、ユーザは、コンサルティングデバイス１０上に設置されたナビゲータの中にウェブページを開設することができ、このウェブページがウェブサービス２８との接触を可能にする。ユーザは、ウェブページを介して認証情報を提供し、サービス２８に宛てた要求の中でこの情報を送信する。
【０２１２】
この認証情報は、図２を参照して記述した第１の識別情報と類似したものであってよく、あるいは異なる性質のものであってもよい。あらゆる場合において、この情報によりサービス２８はユーザを識別でき、サービス２８に対するその提供には、ユーザの関与が求められる。
【０２１３】
サービス２８は、データベース３２と協働して、要求内に含まれる認証情報を抽出し検証する。
【０２１４】
このために、サービス２８は、アクセス要求内に存在するＩＤに連関されたユーザアカウントと認証情報（例えばパスワード、指紋、網膜）との間の対応を検証することができる。
【０２１５】
成功した場合、すなわち、認証情報が実際に問題のユーザアカウントに対応する場合、サービス２８はコンサルティングデバイス１０に対しアクセス許可を伝送し、こうして、ユーザは、サービス２８のそのユーザアカウントにアクセスできることになる。
【０２１６】
この段階で、多因子認証はなおもこのユーザアカウントについて起動されていない可能性がある。したがって、このさらにセキュア化された認証を起動するためにはユーザアカウントのパラメータを修正することが問題となる。
【０２１７】
変形形態においては、アカウントがすでに多因子認証でパラメータ化されている可能性があり、この場合は、サービスにアクセスするために求められるセキュリティレベルをさらに増大させることが考慮される。
【０２１８】
あらゆる場合において、問題は、サービスへのアクセスを要求するために使用されるコンサルティングデバイス１０以外のデバイス（１６または１８）に由来する補足的認証因子を付加することにある。それが可能となるためには、問題のユーザのアカウントにこの別のデバイス（セキュリティデバイス）を結合または連関させることが必要である。
【０２１９】
このために、ユーザはコンサルティングデバイス１０に、使用中のユーザアカウントとセキュリティデバイス１６（あるいは１８）との間の結合コードを入力または口述する。結合コードの入力（書込みまたは音声による）については、図２を参照して詳述された。
【０２２０】
結合コードは、その時点ですでに、データネットワークのデータベース例えば管理機構３４のデータベース３６および／またはサービス２８のデータベース３２中に存在している場合があり、こうしていわゆる連関の前に管理機構３４および／またはサービス２８により検証され得る。
【０２２１】
ステップＥ４の間に、コンサルティングデバイス１０は、サービス２８において入力または口述された結合コードを伝送する。
【０２２２】
この結合コードを受信した時点で、サービス２８は、管理機構３４宛てに結合の起動要求を生成する。この段階で、結合コードは、データベース３２中に永続的に記憶されない。結合コードは、例えばサービス２８に関連するＲＡＭの中に一時的に記憶される。
【０２２３】
この起動要求は、ステップＥ４においてコンサルティングデバイス１０から受信された結合コードを含み、セキュリティデバイス１６（あるいは１８）と使用中のユーザアカウントとの間の連関を起動化させることを目的とする。
【０２２４】
この連関により、ユーザが次にサービス２８への接続を試みた際に、ユーザアカウントの認証にセキュリティデバイス１６（あるいは１８）に由来する補足的認証情報を考慮することが可能になる。
【０２２５】
換言すると、この結合は、認証における補足的因子の考慮をひき起こし、こうしてユーザアカウントからのサービスへのアクセスはさらに一層セキュア化されることになる。
【０２２６】
ステップＥ６の間、サービス２８は、管理機構３４に対して起動要求を伝送する。
【０２２７】
ステップＥ６においてサービス２８が発出した起動要求を受信した時点で、結合コードが管理機構３４に対し並行して送信された場合、管理機構３４は、要求の中で受信されたコードが他で受信されたコードに正しく対応していることを検証することによって、補足的検査を行なうことができる。これらのコードが対応していない場合、方法は停止し、結合は起こらない。
【０２２８】
特定の実施形態において、管理機構３４は同様に、セキュリティデバイス１６が正しく接続されていることも検証する。この検証は一部の形態において、セキュリティデバイスが接続されていない場合に連関を妨げることができる。
【０２２９】
管理機構３４は、セキュリティデバイス１６（あるいは１８）のＩＤおよび起動要求を発出したサービス２８のＩＤと連関させて、付随するデータベース３６内に結合コードを記録する。
【０２３０】
管理機構３４はその後（ステップＥ８）サービス２８に対して、ユーザアカウントとセキュリティデバイス１６（あるいは１８）の間の結合が起動されたこと、換言するとセキュリティデバイスがユーザアカウントに正しく連関させられていることを証明するメッセージを返送する。
【０２３１】
ステップＥ６において送信された起動要求に対するこの応答メッセージを受信した時点で、サービス２８は、ユーザアカウントと連関させた状態で結合コードをデータベース３２内に記録する。
【０２３２】
この例の変形形態として、サービスはそれ自体、ユーザアカウントとセキュリティデバイスの連関を管理することができる。このために、サービスは自ら連関を起動させ、次に必要な情報を付随するデータベース３２の中に記録する。
【０２３３】
典型的に、この変形形態において、結合コードは、セキュリティデバイスのＩＤに直接対応する。データベース３２は変形形態として、結合コードとセキュリティデバイスのＩＤとの間の対応表を記憶することができる。
【０２３４】
その時から、ユーザアカウントのユーザを認証するために、サービス２８は、ユーザが使用するコンサルティングデバイス１０の側からのユーザの認証情報（前述のステップＥ２０を参照のこと）、ならびにユーザアカウントに結合されたセキュリティデバイス１６（あるいは１８）の側からの認証情報（前述のステップＥ５０を参照のこと）を獲得しなければならない。
【０２３５】
以上の実施例は、これに限定されない本発明の実施形態にすぎない。
【符号の説明】
【０２３６】
１０    コンサルティングデバイス
１２    ローカルネットワーク
１６    セキュリティデバイス
１８    セキュリティデバイス
２４    ゲートウェイ
２６    データネットワーク
２８    サービス
３２    データベース
３４    セキュリティデバイス管理機構
３６    データベース
【図１】
2015099595.tif 000003
【図２】
2015099595.tif 000004
【図３】
2015099595.tif 000005