(58)【調査した分野】(Int.Cl.,DB名)
装置証明書がローカルに格納されていないことを確認した後に、又は前記サーバによって返された検証失敗応答を受信した後に、前記要求送信ユニットが前記証明書申請要求を送信するように更に構成される、請求項8に記載の機器。
命令のセットを格納する非一時的コンピュータ可読媒体であって、前記命令のセットは、対象装置を検証する方法を行うために装置検証機器の少なくとも一つのプロセッサによって実行可能であり、前記方法が、
対象サービスの実行を要求する対象装置を検証するための装置検証方法であって、
前記対象装置によって送信された装置検証要求を受信することであって、前記装置検証要求が前記対象装置の装置証明書及び第1の装置属性情報を含み、前記装置証明書が第2の装置属性情報に従って生成された装置指紋を含むことと、
前記装置指紋が前記第1の装置属性情報と一致するかどうかを判定することと、
前記装置指紋が前記第1の装置属性情報と一致するとの判定に応じて、前記対象装置が前記対象サービスを実行できるようにすることと、
を含み、
前記対象装置によって送信された装置検証要求の前記受信の前に、前記方法が、
前記対象装置によって送信された証明書申請要求を受信することであって、前記証明書申請要求が、前記対象装置によって収集された前記第2の装置属性情報を含むことと、
前記第2の装置属性情報に従って前記装置指紋を生成することと、
前記装置証明書を前記対象装置に送信することであって、前記装置証明書が前記装置指紋を含むことと、
を更に含み、
前記第2の装置属性情報が、前記対象装置によって収集された第1の数の属性値を含み、各属性値が前記対象装置の装置属性に対応し、
前記第2の装置属性情報に従って前記装置指紋を生成することが、前記第1の数の属性値から第2の数の属性値を選択すること、及び前記装置指紋を生成するために前記第2の数の属性値を組み合わせることを更に含む、
非一時的コンピュータ可読媒体。
命令のセットを格納する非一時的コンピュータ可読媒体であって、前記命令のセットは、対象装置を検証する方法を行うために装置検証機器の少なくとも一つのプロセッサによって実行可能であり、前記方法が、
第1の装置属性情報を収集することと、
装置検証要求をサーバに送信することであって、前記装置検証要求が装置証明書及び前記第1の装置属性情報を含み、前記装置証明書が第2の装置属性情報に従って生成された装置指紋を含むことと、
前記装置指紋が前記第1の装置属性情報と一致すると前記サーバが判定した場合に、当該判定に基づいて、対象サービスが実行されるようにすることと、
を含み、
第1の装置属性情報の前記収集の前に、前記方法が、
前記第2の装置属性情報を収集することと、
証明書申請要求を前記サーバに送信することであって、前記証明書申請要求が、前記装置指紋の生成に使用される前記第2の装置属性情報を含むことと、
前記サーバによって返された前記装置証明書を受信することと、
を更に含み、
前記第2の装置属性情報が第1の数の属性値を含み、各属性値が前記対象装置の装置属性に対応し、
前記装置指紋が、前記第1の数の属性値から前記サーバによって選択された第2の数の属性値の組み合わせに基づいて生成されている、
非一時的コンピュータ可読媒体。
【発明を実施するための形態】
【0011】
詳細な説明
図1は、本発明の実施形態による装置検証方法の適用シナリオを概略的に示す。
図1に示されているように、例として、ウェブサイト上で決済サービスを実行するユーザを取り上げると、決済サービスは、例えば、ユーザが、自分自身の口座を用いることによってサービスの支払いをするなどのサービス業務である。ユーザは、一般に、決済サービスを実行するために、自分のコンピュータ11を用いる。サービスが、より高いセキュリティを要求するので、サーバ12は、ユーザの口座とユーザによって通常用いられるコンピュータ11との間の対応関係を記録してもよく、ユーザの口座が、コンピュータ11上で用いられる場合に、サーバ12は、サービスが安全に行われると見なしてもよい。決済サービスの実行を要求する場合に、口座が、ユーザによって通常用いられるコンピュータではなく、コンピュータ13を用いることをサーバ12が知った場合に、サーバ12は、ユーザの口座が、ハッカーによって不正に入手されたかどうか、及びハッカーが、コンピュータ13を用いることによって不正に動いているかどうかを疑ってもよく、その結果、サーバ12は、サービスの履行を拒否してもよい。
【0012】
上記の例は、装置検証の適用シナリオである。即ち、ウェブサイトサーバは、サービスが安全に行われるかどうかを検証するために、サービスのセキュリティを保証するように装置(例えばコンピュータ)を識別する。続いて説明される本発明の実施形態による装置検証方法は、検証結果がより正確でより信頼できることを保証するために、サーバがどのように装置を検証するかを説明する。明らかに、装置検証の例は、
図1に示されているシナリオに限定されず、他の同様のシナリオがまた、本発明の実施形態による装置検証方法を採用してもよい。
【0013】
図2は、本発明の実施形態による装置検証方法の概略シグナリング図である。
図2に示されているように、方法は、装置とサーバとの間で実行される装置検証フローを概略的に示す。例えば、ユーザは、決済サービスを行う装置を用いている。サーバ側は、サービスのセキュリティを保証するために、検証を行うように装置に指示してもよく、サーバは、検証が成功した後にだけ装置がサービスを再開できるようにしてもよい。
【0014】
以下のプロセスは、装置が検証されることを要求するサーバの指示を、装置が受信した後で実行される処理を説明する。検証される装置は、対象装置と呼ばれてもよく、装置によって実行されるサービスは、対象サービスと呼ばれる。
【0015】
201.対象装置は、第1の装置属性情報を収集する。
【0016】
検証される対象装置が、サーバによって送信された、装置の検証を要求する指示を受信した後で、対象装置は、対象装置自体に対応する第1の装置属性情報を収集する(「第1の」は、続く実施形態に現れる他の属性情報から区別されるためにのみ用いられ、他の限定的な意味を有しない)。具体的には、第1の装置属性情報は、対象装置のハードウェア固有属性である。
【0017】
例えば、例として、コンピュータである対象装置を取り上げると、コンピュータは、ネットワークカード、表示カード、CPU及びメモリチップなどの様々なハードウェアを有しており、そのようなハードウェアの属性情報が、収集される必要がある。例えば、表示カードに関し、表示カードの属性は、例えば型、名称、配送ID、解像度などを含んでもよい。これらは、全て、ハードウェア、この場合には表示カードの属性情報と呼ばれてもよい。どの属性(単複)が特に収集されるか、例えば型又は配送IDが収集されるかどうかは、この実施形態において限定されていない。しかしながら、取得されるハードウェア属性用の要件が存在する。属性は、ハードウェアの固有属性、即ちハードウェア用の不変の属性である。例えば、例としてやはり表示カードを用いると、配送ID又は型は、収集されてもよい。これらの属性は、固定され不変である。一方で解像度は、表示カードの属性であるが、変化する可能性がある。例えば、コンピュータ構成が調整された後で、解像度は、増加又は低減される可能性があり、かかる可変属性情報は、第1の装置属性情報として収集することができない。
【0018】
更に、通常、このステップで収集される複数の第1の装置属性情報が存在してもよい。例えば、3つの属性情報又は5つの属性情報が収集されてもよい。複数の属性情報が、1つのハードウェアに対応する複属性であってよく、且つ複数個のハードウェアにそれぞれ対応する複属性であってもよいことに留意されたい。
【0019】
例えば、3つの属性情報、即ち属性A、属性B、及び属性Cが収集されることを仮定する。その場合に、3つの属性は、表示カードなどの同じハードウェアピースに対応し、それぞれ表示カードの型、配送ID及び名称である。又は3つの属性は、相異なるハードウェアピースにそれぞれ対応し、例えば、属性Aは、ネットワークカードの型であり、属性Bは、表示カードの配送IDであり、属性Cは、CPUなどの型である等である。明らかに他の例が存在するが、それらは、ここで詳細には説明されない。
【0020】
202.対象装置は、装置検証要求をサーバに送信する。要求は、対象装置の装置証明書及び第1の装置属性情報を含み、装置証明書は、第2の装置属性情報に従って生成された装置指紋を含む。
【0021】
第1の装置属性情報を収集した後で、対象装置は、対象装置に対して装置検証を実行するようにサーバに要求するために、装置検証要求をサーバに送信する。検証要求は、201において収集された第1の装置属性情報を含むだけでなく、装置証明書も含む。
【0022】
一般に、対象装置が、正当なユーザ機器であると仮定すると、装置証明書は、この装置検証プロセスの前に、サーバによって対象装置へと発行され、対象装置は、サーバによって送信された装置証明書を格納する。対象装置は、このステップにおいて検証要求で装置証明書を伝達するように要求されるだけである。この時点で、第2の装置属性情報に従って生成される、且つ装置証明書に保持される装置指紋は、その属性、例えば201で挙げられた属性に従って、対象装置によって生成される指紋である。
【0023】
検証される対象装置が、ハッカーによって使用される不正な装置であると仮定すると、装置証明書は、ハッカーによって盗まれた正当なユーザの装置証明書であり得、装置証明書に保持される装置指紋は、やはり、対象装置の属性に従って対象装置によって生成された指紋である。ハッカーは、装置証明書に含まれる装置指紋を修正することができない。何故なら、装置証明書の内容に対してなされるどんな修正も、証明書を無効にするからである。
【0024】
任意選択的に、装置証明書は、対象装置のトラステッド・プラットフォーム・モジュールTPMに格納されてもよく、TPMハードウェアは、より信頼できるセキュリティ保証を証明書の格納用に提供することができる。
【0025】
203.サーバは、第1の装置属性情報が、装置証明書における装置指紋と一致するかどうかを判定する。
【0026】
このステップにおいて、第1の装置属性情報が、装置証明書における装置指紋と一致するかどうかをサーバが判定する前に、サーバは、装置指紋に従って、装置証明書が有効かどうかを更に判定する。例えば、証明書が有効であることを判定した場合に、サーバは、装置指紋が破損されたかどうかをチェックしてもよい。例えば、サーバは、装置指紋が破損されているかどうかを判定するために、証明書における装置指紋を、前にサーバに格納された指紋と比較してもよい。サーバはまた、証明書の内容が完全かどうかを判定する完全性試験を実行するために、装置指紋を用いてもよい等である。
【0027】
証明書が有効であると判定された後で、サーバは、202において対象装置によって提示された第1の装置属性情報を証明書における装置指紋と比較して、2つが互いに一致するかどうかを判定する。
【0028】
任意選択的に、第1の装置属性情報が、証明書における装置指紋と一致する2つの方法が存在し得る。例えば、第1の装置属性情報は、第2の装置属性情報と一致する。例えば、対象装置によって収集された第1の装置属性情報は、属性A、属性B及び属性Cを含み、証明書における装置指紋を生成するための第2の装置属性情報もまた、属性A、属性B及び属性Cを含む。即ち、装置指紋もまた、3つの属性によって生成される。その場合には、第1の装置属性情報は、第2の装置属性情報と一致する。換言すれば、第1の装置属性情報は、証明書における装置指紋と一致する。別の例では、別の装置指紋がまた、対象装置によって収集された第1の装置属性情報に従って生成されてもよく、その別の装置指紋が、装置証明書における装置指紋と同じである場合に、それは、第1の装置属性情報が、証明書における装置指紋と一致することを示す。
【0029】
更に、第1の装置属性情報が、第2の装置属性情報と一致する場合に、属性情報間の一致は、例えば、第1の装置属性情報及び第2の装置属性情報における対応する属性値が同じであること、又は属性値の総数に対する同一属性値の数の比率が、予め設定された比率閾値に達することを指す。
【0030】
例えば、4つの属性、即ち属性A、属性B、属性C及び属性Dが存在すると仮定すると、サーバは、対象装置によって収集された4つの属性が、装置証明書における4つの対応する属性と同一かどうかを比較してもよい。例としてネットワークカードを取り上げると、装置証明書における属性Aは、ネットワークカードの配送IDであり、対象装置によって収集された第1の装置属性情報もまた、対象装置のネットワークカードの配送IDを有し、サーバは、2つの配送IDが同じかどうか、即ち同じハードウェアの対応するタイプの属性が同じかどうかを比較してもよい。上記の比較は、証明書における各属性に対して必要とされる。
【0031】
比較中に、3つの場合が存在し得る。例えば、1つの場合において、属性値(属性値は、例えばネットワークカードの配送IDである)は同じである。例えば配送IDが同一である。別の場合において、属性値は異なる。例えば、配達IDが異なるか又は表示カードの型が異なる。更に別の場合において、収集された属性値はヌルである。例えば、装置証明書における1つの属性は、ネットワークカードの型であるが、しかし対象装置によって収集された第1の装置属性情報において、ネットワークカード型はヌルである。即ち、ネットワークカード型は収集されない。これは、収集中に収集環境又は他の要因によって影響を受けた可能性があり、その場合、属性は取得されない。
【0032】
上記の3つの比較の場合に基づいて、属性情報間の一致は、次のように定義されてもよい。
【0033】
例えば、第1の装置属性情報、及び第2の装置属性情報における対応する属性値は、完全に同じである必要がある。即ち、対象装置は、証明書における全ての属性値を収集する必要があり、属性値は、同じである必要がある。その場合に、サーバは、第1の装置属性情報が第2の装置属性情報と一致することを判定することができる。
【0034】
別の例では、第1の装置属性情報、及び第2の装置属性情報における対応する属性値は、完全に同じである必要があり、その場合に、幾つかの収集された対応する属性値がヌルであることは許され得るが、しかし全ての収集された属性値がヌルであることは許されない。証明書における属性値が、対象装置によって収集されず、それらが全てヌルである場合に、サーバは、第1の装置属性情報が、第2の装置属性情報と一致しないことを判定する。4つの属性A、B、C及びDに関し、属性Bだけが対象装置によって収集されず、他の属性値が同じである場合に、属性Aは無視されてもよく、第1の装置属性情報が、第2の装置属性情報と一致することが判定される。
【0035】
別の例では、第1の装置属性情報、及び第2の装置属性情報における対応する属性値間で、属性値の総数に対する同一属性値の数の比率は、予め設定された比率閾値に達する。例えば、上記の4つの属性において、1つの対応する属性だけが比較において異なり、他の3つが同じである場合に、属性値の総数に対する同一属性値の数の比率は3/4であり、予め設定された比率閾値1/2より大きく、そのとき、それらが互いに一致することが判定される。3つの属性の属性値が異なる場合に、属性値の総数に対する同一属性値の数の比率は、1/4であり、予め設定された比率閾値1/2未満であり、そのとき、それらが互いに一致しないことが判定される。
【0036】
前述において説明された一致条件の例が、単に例であり、網羅的ではなく、特定の実装形態において、一致条件が、装置検証によって要求されるセキュリティ制御の厳格さの程度に従って柔軟に設定されてもよいことに留意されたい。
【0037】
このステップにおける属性比較は、
図1に示されている適用シナリオの例と組み合わせて示されており、装置が安全かどうか、及び装置が安全な装置か又は不正な装置かをサーバがどのように判定するかが説明される。
【0038】
図1において、ユーザが、正当なユーザであり、サーバ12にアクセスするために自分のコンピュータ11を用いると仮定すると、コンピュータ11が、装置検証要求を送信する場合に、そこに保持された装置証明書は、コンピュータ11へとサーバ12によって発行された証明書であり、証明書における第2の装置属性情報は、コンピュータ11に対応する属性、例えば、コンピュータ11の表示カード属性及びネットワークカード属性である。装置検証要求が送信される場合に、コンピュータ11の表示カード及びネットワークカード属性もまた、コンピュータ11によって収集された第1の属性情報に存在し、2つの属性情報は、サーバ側によって判定される場合に、一般に一貫している。
【0039】
対して、
図1において、ユーザが、不正なユーザ、即ち正当なユーザのコンピュータ11に対応する装置証明書を盗み、コンピュータ13を介してサーバ12にアクセスする不正なユーザであると仮定し、且つコンピュータ13が、装置検証要求を送信する場合に、そこに保持される装置証明書が、サーバ12によってコンピュータ11に発行された証明書であると仮定すると、証明書における装置指紋は、コンピュータ11の属性によって生成され、一方でコンピュータ13によって収集された第1の装置属性情報は、コンピュータ13に対応するハードウェア情報であり、従って、サーバ側が判定する場合に、装置指紋及び第1の装置属性情報が互いに一致しないことが判定されることになる。
【0040】
このステップにおいて、装置証明書が装置指紋に従って有効であると判定され、且つ判定結果によれば、装置証明書における装置指紋が第1の装置属性情報と一致する場合に、それは、装置証明書が対象装置の証明書であることを示し、204が実行される。そうでなければ、205が実行される。
【0041】
204.サーバは、対象装置が対象サービスを実行できるようにする。
【0042】
このステップにおいて、サーバは、検証成功応答を対象装置に返すか、又は成功応答を返さずに、対象装置が後続のサービス動作を直接実行できるようにしてもよい。
【0043】
205.サーバは、対象装置が対象サービスを実行できないようにする。
【0044】
例えば、サーバは、検証失敗応答を対象装置に返す。例えば、不正なユーザが、上記で説明したように、サーバにアクセスするためにコンピュータ13を用いた場合に、ユーザは、サーバによって、サービスを実行できないようにされることになる。
【0045】
この実施形態の装置検証方法において、装置属性情報に従って生成された装置指紋は、装置用に発行された装置証明書に保持され、装置の検証中に、装置は、装置属性が証明書における装置指紋と一致する場合にのみサービスを実行できるようにされ、それによって、装置検証のセキュリティ及び信頼性を改善する。
【0046】
上記の例において、装置検証方法を実行するプロセスは、対象装置が装置証明書を格納したことに基づいて実行され、対象装置は、装置検証要求を送信する場合に、装置証明書を伝達する必要があるだけである。実際には、装置証明書は、サーバによって対象装置に発行され、装置検証のプロセスを実行する前に、サーバに申請することを通して、対象装置によって取得される。証明書の申請は、以下で詳細に説明される。
【0047】
図3は、本発明の実施形態による別の機器検証方法の概略シグナリング図であり、その図は、装置が証明書をサーバに申請する場合のプロセス及びサーバが証明書を生成する方法を説明するために用いられ、以下のステップを含む。
【0048】
301.対象装置は、第2の装置属性情報を収集し、且つ公開鍵−秘密鍵ペアを生成する。
【0049】
装置証明書が、サーバによって作成される場合に、装置のハードウェア属性もまた、証明書に設定され、従って、対象装置が、証明書を申請する場合に、第2の装置属性情報と呼ばれてもよい装置のハードウェア属性の収集が、実行される必要があり、その結果、それらは、サーバに提出され、それに応じてサーバが証明書を生成できるようにすることができる。
【0050】
このステップにおいて、対象装置によって収集された第2の装置属性情報が、装置証明書における属性情報と必ずしも完全に同一でなくてもよいことに留意されたい。例えば、3つの属性A、B及びCが、装置証明書に存在すると仮定すると、このステップにおける第2の装置属性情報は、対象装置が、対象装置自体の全てのハードウェア固有属性を収集するか又は5つの属性を収集する等であってよく、それは、要するに、装置証明書に含まれる属性より多くてもよく、装置証明書における属性は、複属性から選択された幾つかの属性である。詳しくは、後続の303の説明を参照されたい。明らかに、第2の装置属性情報はまた、証明書における属性と同一であってもよい。例えば、3つのA、B及びCが収集され、3つの属性はまた、証明書が作成される場合に証明書に設定される。
【0051】
更に、このステップにおいて第2の装置属性情報を収集することに加えて、対象装置は、公開鍵及び秘密鍵を含む公開鍵−秘密鍵ペアを更に生成する。公開鍵は、304において証明書を生成するために用いられ、秘密鍵は、証明書が申請される場合にはサーバに送信されない。例えば、秘密鍵は、検証が成功した後で、情報伝送中に情報を暗号化するために用いられてもよい。例えば、対象装置によってサーバ送信される情報は、秘密鍵によって暗号化され、サーバは、公開鍵を用いることによって情報を解読する。
【0052】
302.対象装置は、証明書申請要求をサーバに送信し、証明書申請要求は、第2の装置属性情報、及び公開鍵−秘密鍵ペアにおける公開鍵を含む。
【0053】
対象装置が、証明書申請要求をサーバに送信する場合に、301において収集された第2の装置属性情報、及び生成された公開鍵−秘密鍵ペアにおける公開鍵が伝達される。
【0054】
任意選択的に、対象装置は、装置証明書をサーバに申請し、申請は、次のように列挙される2つの場合において、サーバに対して開始されてもよい。
【0055】
1つの場合において、対象装置は、それが装置証明書を格納していないことを知る。証明書がサーバによって装置に送信されるので、証明書は装置に格納され、装置が装置検証を実行するようにサーバに要求した場合に、証明書は装置検証要求において伝達される。装置証明書がローカルに格納されていないことを対象装置が確認した場合に、装置検証は、続いて実行することはできない。従って、対象装置は、証明書申請を開始することになる。
【0056】
もう1つの場合に、対象装置が、サーバによって返された検証失敗応答を受信した場合に、換言すれば、今回の対象装置による証明書の申請の前に、対象装置は、恐らくサーバに検証を要求するために別の装置の証明書を用いた可能性があり、その結果、サーバは、属性情報が一致しないことを判定し、装置証明書が、その装置の証明書ではないことを示す検証失敗を返す。従って、対象装置は、再びそれ自体の装置証明書を申請する必要がある。
【0057】
303.サーバは、第2の装置属性情報に従って装置指紋を生成する。
【0058】
このステップにおいて、対象装置によって収集された第2の装置属性情報における属性数が、装置指紋が生成される場合に基づく必要のある属性情報の数より多い場合に、属性は、第2の装置属性情報から選択されてもよく、対象装置によって収集された第2の装置属性情報における属性数が、装置指紋が生成される場合に基づく必要のある属性数と同じである場合に、指紋は、それらの全てに基づいて生成されてもよい。
【0059】
前述において、装置指紋が生成される際に基づく第2の装置属性情報の取得は、属性数の点から説明され、収集される第2の装置属性情報が、属性A(例えばCPU型)、属性B(例えばネットワークカード型)、属性C(例えば表示カードの配送ID)、及び属性D(例えばメモリの名称)を含むと仮定すると、それに応じて指紋が生成される際に基づく属性を取得する場合に、指紋は、例えば、次に示す方法で、更に処理される必要がある。
【0061】
上記の表1に示されているように、表1は、対象装置が、伝送のセキュリティを保証するために、収集された4つの属性情報の属性値用のハッシュ値を取ることを示す。実際には、収集された属性値のハッシュ値は、サーバに送信される。サーバ側において、これらの属性のハッシュ値は、対象装置を識別するための装置指紋を形成するために組み合わされる必要がある。
【0062】
例えば、例として、第2の装置属性情報から幾つかの属性を選択する。第2の装置属性情報は複属性値を含み、各属性値、例えば上記の表1における4つの属性値は、対象装置の装置固有属性に対応する。サーバは、4つの属性から、予め設定された数の属性値を選択する。例えば、この実施形態において、3つの属性値A、B及びCが選択され、これらの属性値は、装置の指紋情報を生成するために組み合わされる。組み合わせは、次の方法に従って実行されてもよい。即ち、上記の表1における属性A、属性Aのハッシュ値、属性B、属性Bのハッシュ値、属性C、及び属性Cのハッシュ値は、全て、装置指紋情報として働くために、ハッシュを取るように統合される。明らかに、3つの属性の関連情報が含まれる限り、他の組み合わせ方法が存在してもよいが、それらは、詳細には説明されない。
【0063】
前述のように、第2の装置属性情報から幾つかの属性を選択することによって装置指紋を生成する方法が、装置検証の方法をより信頼でき且つより安全にできることに留意されたい。その理由は、対象装置が、その全てのハードウェア固有属性を収集すると仮定すると、対象装置は、それらの全ての属性からどの属性が、それに応じて装置指紋を生成するために、サーバによって選択されるかを知ることができず、ハッカーなどの不正なユーザは、どの属性が装置証明書に含まれるかが分からず、その結果、ハッカーは、自分自身で属性を捏造しようとさえ目論むが(例えばハッカーは、装置検証要求を報告する場合に、正当な装置のハードウェア属性を改竄し、それらをハッカー自身のハードウェアと取り替える)、ハッカーは、どの属性が捏造される必要があるかが分からず、それは、ハッカーの不正行為の困難さを増加させ、その結果、検証方法は、より高い信頼性を有する。
【0064】
更に、対象装置は、証明書を申請する場合に、対象装置によって収集されるハードウェア固有属性を記録してもよい。このようにして、同じ装置属性はまた、続いて装置検証が要求される場合に、収集されることができる。このようにしてのみ、収集された属性情報が、装置証明書における対応する属性を含むことが保証され得、サーバは、属性を照合し、比較することができる。
【0065】
304.サーバは、装置指紋及び公開鍵を含む装置証明書を生成する。
【0066】
以下の表2は、単純化された方法で、このステップにおいて生成される装置証明書の構造を示す。
【0068】
上記の表2に示されているように、装置証明書は、証明書の拡張情報に含まれる装置指紋を有するデジタル証明書であり、デジタル証明書は、例えばX.509V3フォーマットにおける証明書である。装置指紋の生成の説明は、303の説明に見い出し得る。装置証明書はCA署名付き公開鍵を更に含み、公開鍵は、対象装置によって生成された公開鍵−秘密鍵ペアにおける公開鍵である。情報の破損は、証明書を無効にする。
【0069】
更に、装置証明書が生成される場合に、証明書通し番号もまた、証明書の固有属性として生成される。サーバ側は、生成された装置証明書と装置指紋との間の対応関係を記録してもよい。具体的には、次の表3に示されているように、サーバ側は、例えば、証明書の証明書通し番号と装置指紋との間の対応関係、及び同様に装置固有属性(属性は、指紋が生成される際に基づく属性を指す)を記録してもよい。
【0071】
表3の対応関係が記録された後で、サーバが、続いて対象装置によって送信された装置検証要求で伝達された装置証明書、即ち証明書通し番号の証明書属性を含む装置証明書を受信した場合に、サーバは、装置証明書に対応する装置指紋に対応する属性A、属性B、及び属性Cを取得するために、証明書通し番号に従って表3を調べ、且つ対象装置によって収集された第1の装置属性情報と属性を比較し、それらが互いに一致するかどうかを判定してもよい。
【0072】
証明書通し番号がまた、装置検証をより信頼できるものにすることができることに留意されたい。例えば、2つの装置の属性が同じである、例えば、ネットワークカードの型及び表示カードの配送IDが全て同じであると仮定すると、2つの装置が、装置証明書を申請する場合に、サーバは、2つの装置用の装置証明書を発行する可能性があり、装置証明書に保持される装置指紋は、同じである可能性がある。しかしながら、各証明書は、一意の証明書通し番号に対応し、2つの装置証明書の証明書通し番号は、相異なり、サーバは、やはり2つの装置を区別することができる。
【0073】
換言すれば、対象装置の装置検証要求を受信した場合に、サーバは、上記の例で説明された装置属性情報を照合し比較する必要があるだけでなく、また証明書の通し番号が、同じかどうか、証明書が、有効期限内かどうか、証明書情報が、完全か又は破損されているかどうか等を確かめるために、例えばある基本的な証明書検証を実行する必要がある。
【0074】
305.サーバは、装置証明書を対象装置に送信する。
【0075】
本発明のこの実施形態における装置検証方法は、デジタル証明書及び装置指紋を組み合わせる機構を用い、その結果、証明書における装置指紋は、デジタル証明書が偽造不可能であるように偽造不可能である。一方で、デジタル証明書の一意性もまた利用され、それによって装置検証の信頼性を大いに改善する。
【0076】
装置検証機器が、上記で説明された装置検証方法を機器を通して実行するために、以下のように更に提供される。
【0077】
図4は、本発明の実施形態による装置検証機器の概略構造図であり、機器は、サーバに適用されてもよく、例えば、ソフトウェアは、サーバ端末に設定される。
図4に示されているように、機器は、要求受信ユニット41及び装置検証ユニット42を含んでもよい。
要求受信ユニット41は、検証される対象装置によって送信された装置検証要求を受信するように構成され、装置検証要求は対象装置の装置証明書及び第1の装置属性情報を含み、装置証明書は第2の装置属性情報に従って生成された装置指紋を含む。
装置検証ユニット42は、装置証明書が有効であることが装置指紋に従って確認され、且つ装置指紋が第1の装置属性情報と一致する場合に、装置証明書が対象装置の証明書であることを判定し、且つ対象装置が対象サービスを実行可能にするように構成される。
【0078】
図5は、本発明の実施形態による別の装置検証機器の概略構造図である。
図4に示されている構造に基づいて、機器は、証明書生成ユニット43及び証明書送信ユニット44を更に含む。
要求受信ユニット41は、対象装置によって送信された証明書申請要求を受信するように更に構成され、証明書申請要求は、対象装置によって収集された第2の装置属性情報を含む。
証明書生成ユニット43は、第2の装置属性情報に従って装置指紋を生成するように、且つ生成された装置証明書に装置指紋を設定するように構成される。
証明書送信ユニット44は、装置証明書を対象装置に送信するように構成される。
【0079】
更に、証明書生成ユニット43は、第2の装置属性情報に従って装置指紋を生成する場合に、第2の装置属性情報に含まれる複属性値から予め設定された数の属性値を選択するように、且つ対象装置を識別するための装置指紋を生成するために予め設定された数の属性値を組み合わせるように更に構成される。各属性値は、対象装置の装置固有属性に対応する。
【0080】
図6は、本発明の実施形態による更に別の装置検証機器の概略構造図である。機器は、対象装置に適用されてもよい。例えば、クライアント端末ソフトウェアは、対象装置側に設定される。
図6に示されているように、機器は、情報取得ユニット61及び要求送信ユニット62を含んでもよい。
情報取得ユニット61は、第1の装置属性情報を収集するように構成される。
要求送信ユニット62は、装置検証要求をサーバに送信するように構成され、装置検証要求は装置証明書及び第1の装置属性情報を含み、装置証明書は第2の装置属性情報に従って生成された装置指紋を含み、その結果、対象サービスは、装置指紋が第1の装置属性情報と一致することをサーバが判定した場合に実行される。
【0081】
図7は、本発明の実施形態による更に別の装置検証機器の概略構造図である。
図6に示されている構造に基づいて、機器は、証明書受信ユニット63を更に含む。
情報取得ユニット61は、第2の装置属性情報を収集するように更に構成される。
要求送信ユニット62は、証明書申請要求をサーバに送信するように更に構成され、証明書申請要求は第2の装置属性情報を含み、その結果、サーバは、第2の装置属性情報に従って装置指紋を生成し、且つ装置証明書に装置指紋を設定する。
証明書受信ユニット63は、サーバによって返された装置証明書を受信するように構成される。
【0082】
更に、要求送信ユニット62は、装置証明書がローカルに格納されていないことが確認された場合に、又はサーバによって返された検証失敗応答が受信された場合に、証明書申請要求を送信するように更に構成される。
【0083】
上記は、単に本発明の好ましい実施形態であり、本発明を限定するようには意図されていない。本発明の趣旨及び原理内で行われる任意の修正、等価な交換、改良等は、全て、本発明の保護範囲内に入るものとする。