(57)【要約】  装置及びサーバを相互認証するために、セキュアな信用証明を交換する目的で装置側及び装置管理サーバ側において信用証明を設定するためのシステム及び方法について説明する。装置のハードウェア識別情報、サーバ識別情報、及び共有秘密鍵を含む複数のシードを使用して、一方は装置が使用し、他方は装置管理サーバが使用する２組の信用証明を生成する信用証明生成アルゴリズムについて説明する。あらゆるセッション中に装置とサーバとの間で信用証明を交換することにより相互認証が保証される。【選択図】図１
2011521497.tif 000002
【特許請求の範囲】
【請求項１】
第１及び第２のエンティティを相互認証する方法であって、
第１及び第２の信用証明を生成するステップと、
第３及び第４の信用証明を生成するステップと、
前記第１の信用証明を前記第１のエンティティから前記第２のエンティティに提供するステップと、
前記第４の信用証明を前記第２のエンティティから前記第１のエンティティに提供するステップと、
前記第１の信用証明が前記第３の信用証明にマッチする場合、前記第１のエンティティを認証するステップと、
前記第４の信用証明が前記第２の信用証明にマッチする場合、前記第２のエンティティを認証するステップと、
を含むことを特徴とする方法。
【請求項２】
前記信用証明が同じ関数を使用して生成される、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記信用証明が、前記第１のエンティティに一意のものである、
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記信用証明が、前記第２のエンティティに一意のものである、
ことを特徴とする請求項１に記載の方法。
【請求項５】
前記信用証明が、サービスプロバイダに一意のものである、
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記関数が、前記第１のエンティティの一意の識別子を使用する、
ことを特徴とする請求項２に記載の方法。
【請求項７】
前記第１エンティティが通信装置であり、前記一意の識別子が、前記通信装置の電子シリアルナンバー（ＥＳＮ）、移動体装置識別子（ＭＥＩＤ）、国際移動体装置識別情報（ＩＭＥＩ）、及び媒体アクセス制御（ＭＡＣ）アドレスのうちの少なくとも１つを含む、
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記関数が、少なくとも２つのパラメータを使用する一方向ハッシュ関数を含み、前記第１及び第３の信用証明が、第１の順序で配列された前記少なくとも２つのパラメータにより生成され、前記第２及び第４の信用証明が、第２の順序で配列された前記少なくとも２つのパラメータにより生成される、
ことを特徴とする請求項２に記載の方法。
【請求項９】
前記第１及びの第２信用証明が、前記第１のエンティティにより生成される、
ことを特徴とする請求項１に記載の方法。
【請求項１０】
前記第１及び第２の信用証明が、前記第１のエンティティに提供される、
ことを特徴とする請求項１に記載の方法。
【請求項１１】
前記第３及び第４の信用証明が、前記第２のエンティティにより生成される、
ことを特徴とする請求項１に記載の方法。
【請求項１２】
前記第３及び第４の信用証明が、前記第２のエンティティに提供される、
ことを特徴とする請求項１に記載の方法。
【請求項１３】
前記第２エンティティが装置管理サーバである、
ことを特徴とする請求項１に記載の方法。
【請求項１４】
前記装置管理サーバが、オープンモバイルアライアンス装置管理標準、ＴＲ−６９標準、及びＤＯＣＳＩＳ標準を含む少なくとも１つの標準に基づいて動作する、
ことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記一方向ハッシュ関数が、秘密鍵を含む少なくとも３つのパラメータを使用する、
ことを特徴とする請求項８に記載の方法。
【請求項１６】
前記秘密鍵が、サービスプロバイダに一意のものである、
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記第１のエンティティが通信装置であり、前記第２のエンティティが装置管理サーバであり、前記方法が、前記通信装置及び装置管理サーバが相互認証された後に遠隔管理セッションを行うステップを含む、
ことを特徴とする請求項１に記載の方法。
【請求項１８】
前記信用証明の少なくとも１つがパスワードを含む、
ことを特徴とする請求項１に記載の方法。
【請求項１９】
前記信用証明の少なくとも１つが、複数のパラメータのダイジェストを含む、
ことを特徴とする請求項１に記載の方法。
【請求項２０】
前記複数のパラメータが、ユーザ名、パスワード、及びノンスを含む、
ことを特徴とする請求項１９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置のための、具体的には装置管理セッションなどのやりとりを目的として装置及びサーバを相互認証するためのセキュリティシステム及び方法に関する。
【背景技術】
【０００２】
多くの通信装置（無線及び有線の両方）は、装置管理サーバにより遠隔管理されるという機能を有する。典型的な装置管理サーバは、装置の設定、更新の送信、及び診断の実行を遠隔で行うことができる。ネットワークを介した遠隔管理を使用しなければ、多くの管理動作を行うために装置をサービスセンターなどに持ち込む必要がある。これは時間の無駄であり、不便であり、コストがかかる。従って、ネットワーク環境内で遠隔装置管理の機能をサポートする装置が望まれている。この目的を達成するために、通常、個々の通信サービスプロバイダは、自社のネットワーク上で動作する装置を管理することができる独自の装置管理サーバを運営している。
【０００３】
装置を遠隔で管理するためには、管理セッションにおいて管理サーバとセキュアにやりとりを行う必要がある。通常、このようなやりとりを開始するためには、装置が管理サーバに、サーバが装置を認証するために検証できるパスワード（「装置パスワード」）を提示し、管理サーバが装置に、装置がサーバを認証するために検証できるパスワード（「サーバパスワード」）を提示する。これにより、管理セッションを開始する前の相互認証が確実になる。
【０００４】
通常、サービスプロバイダは、自社のネットワークで使用される装置を相手先ブランドメーカーすなわちＯＥＭから取得する。その後、これらの装置がサービスプロバイダの顧客に販売される。通常、装置の遠隔管理に必要なパスワードは、（メールなどの）帯域外手段によって顧客に伝えられ、その後、顧客が自身のそれぞれの装置にパスワードを入力する。個々の装置に装置パスワードをプログラミングすることに加え、やりとりに使用される管理サーバのサーバパスワードを個々の装置にプログラムする必要もある。
【０００５】
しかしながら、このプロセスは間違いを起こしやすく、セキュリティを危うくし、ユーザが装置の使用前にデータを入力することに依存する。さらに、このプロセスは、装置管理サーバに装置パスワードを提供するという問題には対応しない。また、サーバパスワードを変更すると、装置に新たなサーバパスワードを再プログラミングする必要が生じる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従って、管理セッションを行うのに必要な関連する信用証明を通信装置及び装置管理サーバに提供する改善されたシステム及び方法が必要とされている。
【課題を解決するための手段】
【０００７】
本発明は、とりわけユーザにパスワードを帯域外通信する必要性、並びにユーザが装置にパスワードを入力する必要性を無くすことにより、公知のアプローチの上述の不都合を克服するシステム及び方法を提供する。
【０００８】
本発明のある態様では、装置及びサーバが装置管理セッションなどでやりとりする際に、遠隔管理装置及び装置管理サーバを相互認証するためのシステム及び方法を開示する。
【０００９】
例示的な実施形態では、装置の識別情報に基づいて装置パスワードが生成される。装置パスワードは、装置をサーバに対して認証するために装置によりサーバに提示される。装置の識別情報に基づくことに加え、装置パスワードはまた、管理サーバ及び装置をネットワーク内に配置するサービスプロバイダの識別情報などの追加パラメータに基づくこともできる。これにより、個々の装置に一意の１つのパスワードが存在し、個々の装置をサーバ側で単独で認証できることが確実になる。同様の方法をサーバ側で単独で使用して、同じパラメータから同じ装置パスワードを生成することにより、装置がサーバとやりとりする際に、装置により提供されたパスワードをサーバが検証できるようになる。
【００１０】
同様に、例示的な実施形態では、サーバの識別情報に基づいてサーバパスワードが生成される。サーバパスワードは、サーバを装置に対して認証するためにサーバにより装置に提示される。サーバの識別情報に基づくことに加え、サーバパスワードはまた、装置及び装置をネットワークに配置するサービスプロバイダの識別情報などの追加パラメータに基づくこともできる。同様の方法を装置側で単独で使用して、同じパラメータから同じサーバパスワードを生成することにより、サーバが装置とやりとりする際に、サーバにより提供されるパスワードを装置が検証できるようになる。
【００１１】
例示的な実施形態では、本発明は、実際の信用証明を事前に通信することなく、装置固有のパスワード及びサーバ固有のパスワードのペアを装置側及びサーバ側で単独で生成し、両者間でいずれかのセッションが開始される際に、装置及びサーバが相互検証を行えるようにするための方法及び装置を提供する。個々のパスワードのペアは、（装置をサーバに対して認証するために装置がサーバに提示するための）装置パスワード及び（サーバを装置に対して認証するためにサーバが装置に提示するための）サーバパスワードを含む。例えば、装置の一意の識別子、サーバの一意の識別子及び共有鍵を含む同じ関数及び同じパラメータを使用して、装置パスワード及びサーバパスワードを生成することができる。例示的な実施形態では、パラメータを異なる順序で連結して２つの異なる各ペアのパスワードを生成する。従って、装置及びサーバの各ペアに一意の装置パスワード及びサーバパスワードのペアを同じ方法により生成し、これを使用して装置及び管理サーバを相互に認証することができる。
【００１２】
本発明の例示的な実施形態では、装置内にパスワード生成関数がプログラムされ、上述したようなパラメータを使用して装置パスワード及びサーバパスワードのペアが装置側で生成される。別の例示的な実施形態では、パスワードのペアが装置内にプログラムされる。工場において、又は装置が顧客に提供される前のある時点においてこのようなプログラミングを行うことができる。
【００１３】
本発明により生成されるパスワードのペアは、サービスプロバイダ固有のものであることが好ましい。本発明の例示的な実施形態では、パスワード生成関数をサービスプロバイダ識別情報でさらにパラメータ化して、個々の装置及びサービスプロバイダのための一意のパスワードを生成できるようにする方法が提供される。従って、装置の特定のサービスプロバイダネットワークに有効なパスワードで装置の組を設定することができる。別のサービスプロバイダネットワーク内で動作するためには、装置は、新規サービスプロバイダの識別情報に基づいて生成された新たなパスワードを必要とする。
【００１４】
本発明のさらに例示的な実施形態では、装置及び装置管理サーバに同じパスワード生成関数を使用するメカニズムが提供される。パスワード生成関数は同じパラメータセットを使用するが、サーバ側で順序を変更して、装置及びサーバに対して異なるパスワードが生成されるようにする。サーバ及び装置により２つのパスワードが交換され、互いに検証される。
【００１５】
さらなる例示的な実施形態では、同じプロセスを使用して、ユーザ名およびノンス、一時的な連番などのリプレイアタックを防ぐその他の信用証明を生成することができる。
【００１６】
以下の図面及び詳細な説明から本発明の上記の及びその他の態様及び特徴が明らかになるであろう。
【図面の簡単な説明】
【００１７】
【図１】本発明の例示的な実施形態による、装置と装置管理サーバとの間の装置パスワード及びサーバパスワードの交換を示す図である。
【図２】同じパスワード生成関数を使用して装置パスワード及びサーバパスワードの両方を生成するための例示的なプロセスを示す図である。
【図３】管理セッションを開始できる個々の装置の装置パスワード及びサーバパスワードを記憶するための装置管理サーバに保持される例示的なテーブルを示す図である。
【図４】本発明の例示的な実施形態による、装置と装置管理サーバとの間の信用証明の交換を示す図である。
【図５】同じ信用証明生成関数を使用して装置及びサーバ信用証明を生成するための例示的なプロセスを示す図である。
【発明を実施するための形態】
【００１８】
図１は、本発明と共に使用する例示的な無線ネットワーク１００を示している。ネットワーク１００は、１又はそれ以上の無線装置１２０と通信できる１又はそれ以上の基地局又は無線アクセスポイント１１０を備えた従来の無線アクセスネットワークを含む。図１に示すように、基地局１１０は基幹回線に接続される。また、装置管理サーバ１４０などの１又はそれ以上のサーバもネットワーク１３０に接続され、これらは基地局１１０及びネットワーク１３０を介して装置１２０とやりとりすることができる。
【００１９】
ネットワーク１００が利用する無線技術は、装置と無線で通信するために利用可能なスキームのいずれであってもよく、例えば、とりわけ符号分割多元接続（ＣＤＭＡ）、汎用パケット無線サービス（ＧＰＲＳ）、ＷｉＦｉ、ＷｉＭａｘ、ユニバーサル移動体通信システム（ＵＭＴＳ）、及びロングタームエボリューション（ＬＴＥ）が挙げられる。本発明は、装置管理サーバにより遠隔管理される無線装置などの、２つのやりとりするエンティティの相互認証を要求するあらゆる構成に適用することができる。
【００２０】
装置１２０を遠隔管理する際には、管理サーバ１４０が、装置１２０のクライアントへメッセージが送信されるようにする特定の動作を開始する。装置１２０上で実行されるクライアントソフトウェアにより、サーバ１４０から送信される管理コマンドに基づいて装置への変更がなされ得る。管理コマンドとしては、例えばとりわけ、設定、ソフトウェア管理、診断、及びセキュリティコマンドを挙げることができる。クライアント／サーバのやりとりは、オープンモバイルアライアンス装置管理、ＤＳＬフォーラムのＴＲ−６９、又はＣａｂｌｅｌａｂｓのＤＯＣＳＩＳなどの様々な公知の標準のいずれか、又は専用プロトコルに従うことができる。
【００２１】
装置及び管理サーバがセキュアにやりとりするためには、装置をサーバに対して認証する必要がある。同様に、装置が管理サーバの真正性を検証して、不正なサーバからのコマンドを受信しないことを確実にできる必要がある。このような相互認証を容易にするために、装置１２０が管理サーバ１４０に接続する場合、図１に示すように、装置は、パスワード（ＤＥＶＩＣＥＰＡＳＳＷＯＲＤ）の形の信用証明を何らかの適当な装置識別子（ＤＥＶＩＤ）と共に提示することができる。サーバ１４０は、これをサーバ１４０が装置に対して予想するパスワードと比較することにより、装置１２０から受け取ったパスワードを検証することができる。サーバ１４０は、例えば装置識別子のデータベース、及びサーバ１４０が管理する複数の装置の対応する装置パスワードを保持することができ、或いは以下で説明するように、サーバ１４０は、他の考えられる構成の中でも、装置識別子及びその他の情報を使用して対応する装置パスワードを生成することができる。
【００２２】
同様に、装置１２０と管理サーバ１４０との間の相互認証の一部として、管理サーバは、このサーバのパスワード（ＳＥＲＶＥＲＰＡＳＳＷＯＲＤ）を何らかの適当なサーバ識別子（ＳＥＲＶＥＲＩＤ）と共に装置へ送信することができる。装置は、装置がサーバから受け取ったパスワードを装置がサーバに関して有しているパスワードと比較することにより、サーバの真正性を検証することができる。装置１２０がやりとりする予定の１又はそれ以上のサーバの識別子及びこれらの対応するパスワードを、例えば装置内に再プログラムすることができ、或いは以下で説明するように、他の考えられる構成の中でも、装置がサーバ識別子及びその他の情報を使用して対応するサーバパスワードを生成することができる。
【００２３】
例示的な実施形態では、本発明は、互いに相互認証すべき装置側及びサーバ側などにおいて前述の装置及びサーバパスワードを単独で生成するための方法を提供する。本発明の例示的な実施形態では、この目的に暗号化ハッシュ関数が使用される。ハッシュ関数は、入力として３つのパラメータを取る。使用されるパラメータの１つは装置のハードウェア識別情報であり、これには、例えば装置の電子シリアルナンバー（ＥＳＮ）、移動体装置識別子（ＭＥＩＤ）、国際移動体装置識別情報（ＩＭＥＩ）、媒体アクセス制御（ＭＡＣ）アドレス、又は他のいずれかの有効なハードウェア識別情報が含まれる。例示的なパスワード生成関数により使用される第２のパラメータはサーバ識別子であり、これはＵＲＬ、又はサーバを一意に識別するいずれの識別情報であってもよい。第３のパラメータは、サービスプロバイダに関連する秘密鍵である。これらの３つのパラメータを使用することにより、ハッシュ関数は、装置固有かつサーバ固有の装置パスワードを生成できるようになる。これにより、所与の装置を特定のサーバに対して認証できることが確実となる。同様に、同じ関数及びパラメータを使用して装置固有かつサーバ固有のサーバパスワードを生成することにより、所与のサーバを特定の装置に対して認証できるようになる。さらに、装置パスワード及びサーバパスワードの生成に上述の秘密鍵をパラメータとして使用することにより、これらがサービスプロバイダ固有のものになる。
【００２４】
図２は、本発明による、装置パスワード及びサーバパスワードを生成する例示的な方法の図形表示である。同じ３つのパラメータを使用し、同じ暗号化関数ｆ（Ｘ）を使用して、サーバ及び装置の相互認証に使用する装置パスワード及びサーバパスワードの両方を生成する。図２に示すように、３つのパラメータ、ＤＥＶＩＤ、ＳＥＲＶＥＲＩＤ、及びＫＥＹの連結（concatenation）に関数ｆ（Ｘ）を適用することにより、ＤＥＶＩＣＥＰＡＳＳＷＯＲＤが生成される。同じ関数ｆ（Ｘ）を、同じ３つのパラメータではあるが、ＳＥＲＶＥＲＩＤ、ＤＥＶＩＤ、及びＫＥＹの順序の連結に適用することにより、ＳＥＲＶＥＲＰＡＳＳＷＯＲＤが生成される。装置側及びサーバ側で順序に一貫性がある限り、他のパラメータ順序も使用できる点に留意されたい。
【００２５】
例示的な実施形態では、暗号化関数ｆ（Ｘ）が、ＭＤ５（メッセージダイジェスト）などの周知の一方向ハッシュ関数のいずれかであってもよい。
【００２６】
例示的な実施形態では、装置にパスワード生成関数をプログラムし、装置がやりとり及び相互認証を行う個々のサーバごとにサーバ及び装置パスワードのペアを生成する。このような実施形態では、装置に、パスワード生成関数ｆ（Ｘ）、ＳＥＲＶＥＲＩＤ（又は、装置が複数の装置管理サーバとやりとりする場合は複数のＳＥＲＶＥＲＩＤ）、及びサービスプロバイダに関連するＫＥＹが提供される。当然ながら、装置は自身のＤＥＶＩＤを前もって知っている。例えば、装置の起動時に、管理セッションに備えて、装置管理コマンドに応答して、或いは、例えば工場で装置のソフトウェアを読み込んだり、又はパスワード満了などのその他のイベントの発生時にパスワードのペアを生成又は更新することができる。
【００２７】
他の実施形態では、図２に示す方法に基づいて生成されたパスワードのペアが個々の装置に提供される。パスワードの提供は様々な方法で行うことができ、例えば、パスワードを装置内にハードコード化したり、又はこれらを装置の不揮発性メモリ内にプログラミングしたりなどを含む。例えば、装置メーカー又はサービスプロバイダがこれを行うことができる。
【００２８】
パスワードのペアはサービスプロバイダ固有のものであるため、装置に関連するサービスプロバイダが変更された場合、装置に提供されたパスワードは無効になる。新規サービスプロバイダの（単複の）装置管理サーバとやりとりするためには、新たなパスワードのペア（又は複数のペア）を装置に提供する必要がある。装置自体がパスワードを生成する場合、装置に新規サービスプロバイダの秘密鍵を提供する必要がある。さらに、新規サービスプロバイダが異なるパスワード生成関数を使用する可能性があり、この場合にはこの関数も装置に提供する必要がある。
【００２９】
パスワード及び／又はパスワード生成関数の提供に関する同様の検討がサーバにも適用される。さらに通常、サーバは、装置がサーバとやりとりするよりも多くの装置とやりとりする。
【００３０】
図３は、サーバによって管理される装置に関するパスワードのペアを管理サーバ側で記憶するための例示的な構成を示している。個々の装置ごとに、上述したように生成されたＤＥＶＩＣＥＰＡＳＳＷＯＲＤ及びＳＥＲＶＥＲＰＡＳＳＷＯＲＤがテーブルに含まれる。個々のパスワードのペアは、対応する装置の装置識別子（ＤＥＶＩＤ）によりインデックスされる。例えば上述したように、サービスプロバイダ又は装置メーカーがパスワード情報を生成して管理サーバに提供することができ、或いは管理サーバが同じ暗号化関数ｆ（Ｘ）及びパラメータを使用して単独でパスワード情報を生成することができる。例えば、装置がサービスを受けていたり、又はサーバに割り当てられているときには必ず装置のためのパスワードのペアを生成することができる。或いは、サーバが、例えば装置とセッションを開始しようと試みる場合などの必要に応じて、装置のためのパスワードのペアを生成することができる。この場合、サーバは、図３のようなパスワードのテーブルを保持する必要はない。
【００３１】
動作時に、装置がサーバに接続する場合、装置は、（Ｄ１などの）自身の装置識別子及び（ＤＰＸ１などの）自身のＤＥＶＩＣＥＰＡＳＳＷＯＲＤを提示する。サーバは、装置から受け取ったパスワードを、装置の対応するテーブル入力に照らしてチェックする。（或いは、サーバがパスワード生成関数を使用して、装置に対して予想されるＤＥＶＩＣＥＰＡＳＳＷＯＲＤを生成することもできる。）マッチした場合、装置は認証され、管理セッションの進行が許可される。次に、サーバは、装置（Ｄ１）に対応するＳＥＲＶＥＲＰＡＳＳＷＯＲＤ（このケースではＳＰＸ１）を取り出し、これを装置に提供する。（或いは、サーバがパスワード生成関数を使用して、装置に対して予想されるＳＥＲＶＥＲＰＡＳＳＷＯＲＤを生成することもできる。）ＳＰＸ１が、装置が予想するＳＥＲＶＥＲＰＡＳＳＷＯＲＤ、すなわち上述したように生成されたＳＥＲＶＥＲＰＡＳＳＷＯＲＤと一致する場合、サーバはこの装置に対して認証され、装置は正当なサーバとやりとりしていることを認識してセッションを進行させることができる。
【００３２】
図４は、本発明によるさらなる相互認証スキームを示している。装置１２０が管理サーバ１４０に接続する場合、図４に示すように、装置は、装置パラメータのダイジェストの形の信用証明を自身の装置識別子（ＤＥＶＩＤ）と共に提示することができる。サーバ１４０は、これをサーバ１４０が装置に対して予想する信用証明と比較することにより、装置１２０から受け取った信用証明を検証することができる。例えば、サーバ１４０は、装置識別子のデータベース、及びサーバ１４０が管理する複数の装置の対応する信用証明を保持することができ、或いは以下で説明するように、他の考えられる構成の中でも、サーバ１４０が装置識別子及びその他の情報を使用して対応する装置信用証明を生成することができる。
【００３３】
図４の例示的な実施形態では、装置が、装置ユーザ名（ＤＵ）、装置パスワード（ＤＰ）、及び装置ノンス（ＤＮ）のダイジェストを送信する。例えば、装置ユーザが装置ユーザ名及びパスワードを選択してもよく、或いは、サービスプロバイダがこれらを割り当ててもよい。装置ノンスは、タイムスタンプなどの一時的な連番であってもよく、リプレイアタックを防ぐ役に立つ。例示的な実施形態では、ＤＵ、ＤＰ、及びＤＮのダイジェストが、ＭＤ５に基づいて生成されたハッシュである。
【００３４】
同様に、装置１２０と管理サーバ１４０との間の相互認証の一部として、管理サーバが、サーバパラメータのダイジェストの形の信用証明を自身のサーバ識別子（ＳＥＲＶＥＲＩＤ）と共に装置に提示することができる。装置は、サーバから受け取った信用証明を装置がサーバに対して有している信用証明と比較することにより、サーバの真正性を検証することができる。装置１２０がやりとりする１又はそれ以上のサーバの識別子及びこれらの対応する信用証明を、例えば装置内に再プログラムすることができ、或いは以下で説明するように、他の考えられる構成の中でも、装置がサーバ識別子及びその他の情報を使用して対応するサーバ信用証明を生成することができる。
【００３５】
図４の例示的な実施形態では、サーバが、サーバユーザ名（ＳＵ）、サーバパスワード（ＳＰ）、及びサーバノンス（ＳＮ）のダイジェストを送信する。サーバノンスは、タイムスタンプなどの一時的な連番であってもよく、リプレイアタックを防ぐ役に立つ。例示的な実施形態では、ＳＵ、ＳＰ、及びＳＮのダイジェストが、ＭＤ５に基づいて生成されたハッシュである。
【００３６】
図５は、本発明による装置及びサーバ信用証明を生成する例示的な方法の図形表示である。同じ３つのパラメータを使用し、同じ暗号化関数ｆ（Ｘ）を使用して、サーバ及び装置の相互認証に使用する装置信用証明及びサーバ信用証明の両方が生成される。関数ｆ（Ｘ）は、入力パラメータの順序及び値に基づいて値のベクトルを返す。このベクトルの第１の構成要素はユーザ名であり、第２の構成要素はパスワードであり、第３の構成要素はノンスである。図５に示すように、ＤＥＶＩＤ、ＳＥＲＶＥＲＩＤ、及びＫＥＹの３つのパラメータの連結に関数ｆ（Ｘ）を適用することにより、ＤＥＶＩＣＥＵＳＥＲＮＡＭＥ、ＤＥＶＩＣＥＰＡＳＳＷＯＲＤ及びＤＥＶＩＣＥＮＯＮＣＥという装置の値が生成される。同じ３つのパラメータではあるが、ＳＥＲＶＥＲＩＤ、ＤＥＶＩＤ、及びＫＥＹの順序の連結に同じ関数ｆ（Ｘ）を適用することにより、ＳＥＲＶＥＲＮＡＭＥ、ＳＥＲＶＥＲＰＡＳＳＷＯＲＤ及びＳＥＲＶＥＲＮＯＮＣＥというサーバの値が生成される。装置側及びサーバ側で順序に一貫性がある限り、他のパラメータ順序も使用できる点に留意されたい。
【００３７】
上述したように生成されたＤＥＶＩＣＥＮＯＮＣＥ及びＳＥＲＶＥＲＮＯＮＣＥの値が、所与の装置／サーバセッションの初期値となる点に留意されたい。セッションが進行するにつれて、ＮｅｘｔＮｏｎｃｅメッセージなどを使用することによりノンス値を変更することができる。
【００３８】
上述の実施形態は、本発明の用途を表すことができる考えられる特定の実施形態を２、３示したものにすぎないことを理解されたい。当業者であれば、本発明の思想及び範囲から逸脱することなく他の数多くの及び様々な構成を行うことができる。
【符号の説明】
【００３９】
１００  無線ネットワーク
１１０  基地局
１２０  無線装置
１３０  ネットワーク
１４０  装置管理サーバ
【図１】
2011521497.tif 000003
【図２】
2011521497.tif 000004
【図３】
2011521497.tif 000005
【図４】
2011521497.tif 000006
【図５】
2011521497.tif 000007
【手続補正書】
【提出日】平成22年9月29日(2010.9.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１及び第２のエンティティを相互認証する方法であって、
第１のパラメータを前記第１のエンティティから前記第２のエンティティに提供するステップと、
第２のパラメータを前記第２のエンティティから前記第１のエンティティに提供するステップと、
前記第１及び第２のパラメータに応じて、前記第１のエンティティによって生成される第１及び第２の信用証明を生成するステップと、
前記第１及び第２のパラメータに応じて、前記第２のエンティティによって生成される第３及び第４の信用証明を生成するステップと、
前記第１の信用証明を前記第１のエンティティから前記第２のエンティティに提供するステップと、
前記第４の信用証明を前記第２のエンティティから前記第１のエンティティに提供するステップと、
前記第１の信用証明が前記第３の信用証明にマッチする場合、前記第１のエンティティを認証するステップと、
前記第４の信用証明が前記第２の信用証明にマッチする場合、前記第２のエンティティを認証するステップと、
を含み、
前記信用証明は、前記第１及び第２のエンティティにおいて、同じ関数を用いて生成されることを特徴とする方法。
【請求項２】
前記信用証明が、前記第１のエンティティに一意のものである、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記信用証明が、前記第２のエンティティに一意のものである、
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記信用証明が、サービスプロバイダに一意のものである、
ことを特徴とする請求項１に記載の方法。
【請求項５】
前記第１のパラメータは前記第１のエンティティの一意の識別子であり、前記第２のパラメータは前記第２のエンティティの一意の識別子である、
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記第１エンティティが通信装置であり、前記一意の識別子が、前記通信装置の電子シリアルナンバー（ＥＳＮ）、移動体装置識別子（ＭＥＩＤ）、国際移動体装置識別情報（ＩＭＥＩ）、及び媒体アクセス制御（ＭＡＣ）アドレスのうちの少なくとも１つを含む、
ことを特徴とする請求項５に記載の方法。
【請求項７】
前記関数が、少なくとも２つのパラメータを使用する一方向ハッシュ関数を含み、前記第１及び第３の信用証明が、第１の順序で配列された前記少なくとも２つのパラメータにより生成され、前記第２及び第４の信用証明が、第２の順序で配列された前記少なくとも２つのパラメータにより生成される、
ことを特徴とする請求項１に記載の方法。
【請求項８】
前記第２エンティティが装置管理サーバである、
ことを特徴とする請求項１に記載の方法。
【請求項９】
前記装置管理サーバが、オープンモバイルアライアンス装置管理標準、ＴＲ−６９標準、及びＤＯＣＳＩＳ標準を含む少なくとも１つの標準に基づいて動作する、
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記一方向ハッシュ関数が、秘密鍵を含む少なくとも３つのパラメータを使用する、
ことを特徴とする請求項７に記載の方法。
【請求項１１】
前記秘密鍵が、サービスプロバイダに一意のものである、
ことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記第１のエンティティが通信装置であり、前記第２のエンティティが装置管理サーバであり、前記方法が、前記通信装置及び装置管理サーバが相互認証された後に遠隔管理セッションを行うステップを含む、
ことを特徴とする請求項１に記載の方法。
【請求項１３】
前記信用証明の少なくとも１つがパスワードを含む、
ことを特徴とする請求項１に記載の方法。
【請求項１４】
前記信用証明の少なくとも１つが、複数のパラメータのダイジェストを含む、
ことを特徴とする請求項１に記載の方法。
【請求項１５】
前記複数のパラメータが、ユーザ名、パスワード、及びノンスを含む、
ことを特徴とする請求項１４に記載の方法。
【国際調査報告】
2011521497.tif 000008
2011521497.tif 000009