JP2017139512A

JP2017139512A - ユーザ許可の確認システム

Info

Publication number: JP2017139512A
Application number: JP2016016836A
Authority: JP
Inventors: 恒太井手口; Kota Ideguchi; 英里子安藤; Eriko Ando
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2016-02-01
Filing date: 2016-02-01
Publication date: 2017-08-10
Anticipated expiration: 2036-02-01
Also published as: US20170222810A1; EP3200388A1; EP3200388B1; JP6527090B2; US10177918B2

Abstract

【課題】ＣＰＵ処理量の少ない、否認不可の担保されたユーザの許可の確認システムを提供する。
【解決手段】以上の課題を解決するため、本発明では、まずCPUに高い処理能力を必要としないMAC関数を利用する。その上で、否認防止の証明となるメッセージの正当性を担保するために、メッセージを複数の秘密鍵で暗号化し、その複数の鍵を複数のサーバに分散させて持たせる。そして各サーバが自らの範囲内でメッセージの正当性を証明し、それら個別の結果を集約することで、メッセージの正当性を担保し、否認防止を実現する。
【選択図】図２

Description

本発明は、ユーザの許可の確認とその否認防止に関する技術に関する。

クライアント機器とサーバからなる情報システム、または、自動車の車載機器とそれと通信するサーバとからなる自動車システムなど、において処理を実行するために、ユーザの許可の確認を取る必要がある場合がある。この場合、情報システムまたは自動車システムはユーザに許可を求めるメッセージを送り、ユーザが許可する旨のメッセージを返信することで確認が取れる。この際、情報システムまたは自動車システムは許可を得たことを事後に説明するために、このメッセージのやり取りのログを取る事ができる。しかし、ログの正当性が疑われた場合、情報システムまたは自動車システムはログの正当性を証明する必要が出てくる。正当性を証明するためには、ログに残されたユーザの許可する旨のメッセージは確かに当該ユーザが作成したものであり、改ざんされていないことが示されればよい。このようなメッセージの作成元とその内容を事後に否認することが出来ない性質を否認防止と呼ぶ。否認防止を可能にする技術として、特許文献１の公開鍵暗号技術の電子署名技術が知られている。特許文献１の技術では、ユーザのメッセージに対して、ユーザが自身の署名鍵を用いて署名を付けることで、事後にメッセージが確かにユーザが生成したものであることを証明することができる。

米国特許第5231668号明細書

特許文献１に記載の方法では、署名を生成する際と署名を検証する際に公開鍵暗号技術のアルゴリズムを処理する必要がある。しかし、公開鍵暗号技術のアルゴリズムの処理は、共通鍵暗号技術のアルゴリズムの処理に比べて、処理量が多く、より多くのＣＰＵ時間を消費する。特に、車載機器等の組み込み機器が持つ低スペックなＣＰＵの場合、その時間は長くなる。また、ＣＰＵが占有される時間が長いと、他の処理ができないため、特に車載機器のように時々刻々と制御をしているような場合、数msecのオーダーでも影響が出るので安全性上の問題から公開鍵暗号方式は利用できない場合がある。

そこで、本発明は、より少ないＣＰＵの処理量で動作し、かつ、否認防止の性質を持つユーザ許可の確認システムを提供することを目的とする。

以上の課題を解決するため、本発明では、まずCPUに高い処理能力を必要としないMAC関数を利用する。その上で、否認防止の証明となるメッセージの正当性を担保するために、メッセージを複数の秘密鍵で暗号化し、その複数の鍵を複数のサーバに分散させて持たせる。そして各サーバが自らの範囲内でメッセージの正当性を証明し、それら個別の結果を集約することで、メッセージの正当性を担保し、否認防止を実現する。

以上のように、本発明によれば、ＣＰＵ処理量の少ない、否認不可の担保されたユーザの許可の確認システムを提供することが可能となる。

本発明に係る第一の実施形態のシステム例を示す図。ユーザ端末を示す概略図。第一のサーバを示す概略図。第二のサーバを示す概略図。メッセージ電文のフォーマットを示す概略図。ユーザの許可の確認手順を示すフローチャート図。ユーザの許可の事後の否認を否定する手順を示すフローチャート図。本発明に係る第一の実施形態のシステム例を示す図。ユーザ端末を示す概略図。メッセージ電文のフォーマットを示す概略図。ユーザの許可の確認手順を示すフローチャート図。ユーザの許可の事後の否認を否定する手順を示すフローチャート図。

ユーザがユーザ端末での操作を許可したにもかかわらず、事後に許可したことを否認した場合に、この否認を否定できるシステムについて、実施の形態を説明する。

図１は、第一の実施形態のシステムの全体構成図である。第一の実施形態では、ユーザ端末２００と第一のサーバ３００とは、第一のネットワーク１００を介して接続されている。また、第一のサーバと、第二のサーバ４００と、は第二のネットワーク１１０を介して接続されている。なお、第一のネットワーク１００と第二のネットワーク１１０は別のネットワークとは限らず、同一のネットワークでもよい。

図２は、本実施形態におけるユーザ端末２００の概略図である。図示するように、ユーザ端末２００は、制御部２１０と、データ送受信部２２０と、記憶部２３０と、表示装置２４０と、入力装置２５０と、ＭＡＣ生成部２６０と、を備える。

ユーザ端末２００は、制御部２１０によって制御され、データ送受信部２２０を通して、第一のネットワーク１００に繋がっている。

記憶部２３０は、データを格納することができ、第一の共通鍵２３１と、第二の共通鍵２３２と、を格納する。

ＭＡＣ生成部２６０は、ＭＡＣ生成関数機能２６１を備える。

ＭＡＣ生成関数機能２６１は、メッセージと共通鍵とを与えられ、対応するメッセージ認証子（ＭＡＣ）をＭＡＣ生成関数Genmacを計算することで生成する。数式にすると、ＭＡＣ生成関数Genmacは、数１で表される。

ただし、ここでkは前記共通鍵、mは前記メッセージ、macは前記対応するＭＡＣである。

前記ＭＡＣ生成関数Genmacは、暗号学的なＭＡＣ関数を利用することができる。一例として、ブロック暗号ＡＥＳのＣＭＡＣ利用モードで構成されるＭＡＣ関数、ハッシュ関数ＳＨＡ−２５６を利用したＨＭＡＣで構成されるＭＡＣ関数、専用ＭＡＣ関数Ｃｈａｓｋｅｙ、などが挙げられる。

ＭＡＣ生成部２６０は、制御部２１０から、ＭＡＣ付加対象のメッセージとヘッダと、第一の共通鍵と、第二の共通鍵と、を受け取り、処理することで、ＭＡＣが付加されたメッセージ電文５００を生成する。

図５は、メッセージ電文のフォーマット５００を示した図である。前記、ＭＡＣ生成部の説明で記載したとおり、メッセージ電文は、ヘッダ５１０と、メッセージ５２０と、第一のＭＡＣ５３０と、第二のＭＡＣ５４０と、からなる。ヘッダ５１０には、メッセージ電文の属性情報、例えば、メッセージ電文のサイズや、第一のＭＡＣおよび第二のＭＡＣを生成する際に使われる共通鍵のＩＤ、などの情報が記載される。

ＭＡＣ生成部２６０での、メッセージ電文５００の生成手順は次のとおりである。なお、以降では前記ヘッダをh、前記メッセージをm、前記第一の共通鍵をk_1、前記第二の共通鍵をk_2、前記メッセージ電文をm_out、第一のＭＡＣをmac_1、第二のＭＡＣをmac_2と記載する。

まず、ＭＡＣ生成部２６０は前記ヘッダと前記メッセージとを連結したデータと、第一の共通鍵と、をＭＡＣ生成関数機能に渡し、第一のＭＡＣを得る。数式では数２のように表される。

次に、ＭＡＣ生成部２６０は前記ヘッダと前記メッセージとを連結したデータと、第二の共通鍵と、をＭＡＣ生成関数機能に渡し、第二のＭＡＣを得る。数式では数３のように表される。

そして、ＭＡＣ生成部２６０は、前記ヘッダと、前記メッセージと、前記第一のＭＡＣと、前記第二のＭＡＣと、を連結し、メッセージ電文（数４）を生成する。

なお、このフォーマット５００は、端末２００のみならず、第一のサーバ３００、第二のサーバ４００で共有して持っておき、検証の際に利用する。

なお、MAC生成部や、制御部は、具体的には、メモリに読み込んだプログラムをCPU等の処理装置で演算することで実現される。これらは、1つのCPUで実現してもよいし、夫々別のCPUを用いて実現してもよい。

図３は、本実施形態における第一のサーバ３００の概略図である。第一のサーバ３００は、制御部３１０と、データ送受信部３２０と、記憶部３３０と、ＭＡＣ検証機能３４０と、を備える。
第一のサーバ３００は、制御部３１０によって制御され、データ送受信部３２０を通して、第一のネットワーク１００および第二のネットワーク１１０に繋がっている。

記憶部３３０は、データを格納することができ、第一の共通鍵２３１と、メッセージ電文ログ３３１と、を格納する。

ＭＡＣ検証部３４０は、ＭＡＣ検証関数機能３４１を備える。

ＭＡＣ検証関数機能３４１は、検証対象メッセージと、共通鍵と、検証対象ＭＡＣと、を与えられ、当該検証対象メッセージと当該検証対象ＭＡＣの組が、正当な組であるかどうかを検証する機能である。ＭＡＣ検証関数機能３４１は次の動作を行う。まず、ＭＡＣ検証関数機能３４１は入力された検証対象メッセージと入力された共通鍵とから、正しいＭＡＣをGenmac関数で計算する。ここで、Genmac関数はＭＡＣ関数機能２６１で用いられるものと同じ関数である。次に、計算された正しいＭＡＣと、入力された検証対象ＭＡＣと、を比較し、一致した場合は検証成功と判断し関数の値として1を出力し、一致しない場合は検証失敗と判断し関数の値として0を出力する。ＭＡＣ検証関数を擬似コードで記載すると以下のとおりである。なお、ここではＭＡＣ検証関数をVermac、入力される検証対象メッセージをm、入力される共通鍵をk、入力される検証対象ＭＡＣをmac、とする。

ＭＡＣ検証部３４０の動きを説明する。ＭＡＣ検証部３４０は、制御部３１０からメッセージ電文と第一の共通鍵とを受け取り、メッセージ電文の正当性を検証する。まず、ＭＡＣ検証部３４０は、メッセージ電文から、メッセージ電文のフォーマット５００に従い、ヘッダとメッセージと第一のＭＡＣとを抜き出す。次に、ＭＡＣ検証部は、ヘッダとメッセージとを連結したデータを検証対象メッセージとして、第一の共通鍵を共通鍵として、第一のＭＡＣを検証対象ＭＡＣとして、ＭＡＣ検証関数機能３４１に渡し、検証結果を得る。そして、ＭＡＣ検証部は、得られた検証結果を制御部３１０に返す。

なお、MAC検証部や、制御部は、具体的には、メモリに読み込んだプログラムをCPU等の処理装置で演算することで実現される。これらは、1つのCPUで実現してもよいし、夫々別のCPUを用いて実現してもよい。

ここで、メッセージ電文５００のうち、どの部分が第一のサーバに関係するMACであるかは、事前に決められており、それに従い、ＭＡＣ検証部は第一のＭＡＣを抜き出すことができる。

図４は、本実施形態における第二のサーバ４００の概略図である。第二のサーバ４００は、制御部４１０と、データ送受信部４２０と、記憶部４３０と、ＭＡＣ検証機能４４０と、を備える。

記憶部４３０は、データを格納することができ、第二の共通鍵２３２を格納する。

ＭＡＣ検証部４４０は、ＭＡＣ検証関数機能４４１を備える。

ＭＡＣ検証関数機能４４１は、前記ＭＡＣ検証関数機能３４１と同一の機能をもつ。

ＭＡＣ検証部４４０の動きを説明する。ＭＡＣ検証部４４０は、制御部４１０からメッセージ電文と第二の共通鍵とを受け取り、メッセージ電文の正当性を検証する。まず、ＭＡＣ検証部４４０は、メッセージ電文から、メッセージ電文のフォーマット５００に従い、ヘッダとメッセージと第二のＭＡＣとを抜き出す。次に、ＭＡＣ検証部は、ヘッダとメッセージとを連結したデータを検証対象メッセージとして、第二の共通鍵を共通鍵として、第二のＭＡＣを検証対象ＭＡＣとして、ＭＡＣ検証関数機能４４１に渡し、検証結果を得る。そして、ＭＡＣ検証部は、得られた検証結果を制御部４１０に返す。

なお、図３でも説明したとおり、MAC検証部や、制御部は、具体的には、メモリに読み込んだプログラムをCPU等の処理装置で演算することで実現される。これらは、1つのCPUで実現してもよいし、夫々別のCPUを用いて実現してもよい。

また、メッセージ電文５００のうち、どの部分が第一のサーバに関係するMACであるかは、事前に決められており、それに従い、ＭＡＣ検証部は第一のＭＡＣを抜き出すことができる。

図６は、本実施形態におけるユーザの許可の確認の手順を表したフローチャートである。
まず、第一のサーバ３００からユーザ端末２００に処理実行の許可を要求するメッセージを送信する（ステップ６０１）。ユーザ端末２００の制御部２１０はデータ送受信部２２０を通して許可要求電文を受信し、許可要求メッセージを描画した画面を表示装置２４０に出力する（ステップ６０２）。ユーザはユーザ端末２００の入力装置２５０を用いて、許可要求に対して許可もしくは拒否を入力する（ステップ６０３）。
ステップ６０３で許可が入力された場合、ユーザ端末２００の制御部２１０は、記憶部２３０から第一の共通鍵２３１と第二の共通鍵２３２を取得し、許可する旨のメッセージとヘッダと当該第一の共通鍵と、をＭＡＣ生成部２６０に渡し、当該ＭＡＣ生成部は当該許可する旨のメッセージと、当該ヘッダと、当該第一の共通鍵と、当該第二の共通鍵と、からメッセージ電文５００を生成し、制御部に当該メッセージ電文を返す（ステップ６０４）。制御部２１０はデータ送受信部２２０を通して、前期メッセージ電文を第一のサーバ３００に送信する（ステップ６０５）。
第一のサーバの制御部３１０は、データ送受信部３２０を通して前記メッセージ電文を受信し、記憶部３３０から第一の共通鍵２３１を取得し、当該メッセージ電文と当該第一の共通鍵と、をＭＡＣ検証部３４０に渡し、当該ＭＡＣ検証部は当該メッセージ電文の正当性を検証し、検証結果を制御部に返す（ステップ６０６）。
ステップ６０６で検証が成功した場合、制御部３１０は、データ送受信部３２０を通して、メッセージ電文を第二のサーバ４００に送信する（ステップ６０７）。第二のサーバの制御部４１０は、データ送受信部４２０を通して前記メッセージ電文を受信し、記憶部４３０から第二の共通鍵２３２を取得し、当該メッセージ電文と当該第二の共通鍵と、をＭＡＣ検証部４４０に渡し、当該ＭＡＣ検証部は当該メッセージ電文の正当性を検証し、検証結果を制御部４１０に返す（ステップ６０８）。
ステップ６０８で検証が成功した場合、制御部４２０は、データ送受信部４２０を通して、検証成功した旨のメッセージを第一のサーバ３００に送信する（ステップ６０９）。第一のサーバ３００の制御部３１０は、データ送受信部３２０を通して前期検証成功した旨のメッセージを受け取り、前記メッセージ電文をメッセージ電文ログ３３１に追加し、ステップ６０１でユーザに許可を要求していた処理を実行するサーバ、あるいは、ユーザ端末に処理実行可能のメッセージを送付する（ステップ６１０）。
処理実行可能のメッセージを受け取ったサーバ、あるいは、ユーザ端末は処理を実行する（ステップ６１１）。

ステップ６０３でユーザが拒否を入力した場合、ユーザ端末２００は拒否する旨のメッセージを第一のサーバに送信し（ステップ６２０）、ステップ６４０に進む。

ステップ６０６で、正当性の検証が失敗した場合、ステップ６４０に進む。

ステップ６０８で、正当性の検証が失敗した場合、第二のサーバ４００は検証失敗の旨のメッセージを第一のサーバに送信し（ステップ６３０）、ステップ６４０に進む。

ステップ６４０では、第一のサーバ３００は、ステップ６０１でユーザに許可を要求していた処理を実行する予定だったサーバ、あるいは、ユーザ端末に処理実行不可のメッセージを送付する（ステップ６４０）。処理実行不可のメッセージを受け取ったサーバ、あるいは、ユーザ端末は処理を実行せずに、中止する（ステップ６４１）。

なお、ステップ６０１にて前記第一のサーバ３００がユーザの許可を要求するシステムの動作の一例として、第一のサーバ３００がユーザ端末２００の更新プログラムをユーザ端末２００に送付し、ユーザ端末２００が当該更新プログラムを実行してプログラムを更新する、ことが挙げられる。また前記システムの動作の他の例として、ユーザ端末２００が事前に第一のサーバから受信した更新プログラムを実行してプログラムを更新する、ことが挙げられる。

なお、ユーザが、過去に許可したシステムの動作に関して、許可したことを否認した場合に、第一のサーバ、もしくは、第二のサーバ、第三者は、じっしれいユーザによる否認を否定することができる。図７は、否認を否定する手順を表すフローチャートである。

まず、ユーザによる許可の否認を否定したいサーバもしくは第三者が第一のサーバ３００にユーザ許可の確認を要求する（ステップ８０１）。第一のサーバの制御部３１０は、格納部３３０のメッセージ電文ログ３３１から対応するユーザ許可のメッセージ電文を取得する（ステップ８０２）。第一のサーバの制御部は、前記メッセージ電文と、格納部から取得する第一の共通鍵３３１と、をＭＡＣ検証部３４０に渡し、ＭＡＣ検証部は、前記メッセージ電文と、前記第一の共通鍵と、からメッセージ電文の正当性を検証する（ステップ８０３）。

ステップ８０３で、検証が成功した場合、制御部はメッセージ電文を第二のサーバに送信する（ステップ８０４）。第二のサーバの制御部は、前記メッセージ電文と、格納部から取得する第二の共通鍵と、をＭＡＣ検証部に渡し、ＭＡＣ検証部は、前記メッセージ電文と、第二の共通鍵と、からメッセージ電文の正当性を検証する（ステップ８０５）。

ステップ８０５で、検証が成功した場合、第二のサーバは検証が成功した旨のメッセージを第一のサーバに送信する（ステップ８０６）。第一のサーバは、ユーザの許可の確認がとれた旨のメッセージと、前記メッセージ電文と、をステップ８０１のサーバもしくは第三者に送信する（ステップ８０７）。

ステップ８０３で、検証が失敗した場合、ステップ８３０に進む。

ステップ８０５で、検証が失敗した場合、第二のサーバは検証失敗の旨のメッセージを第一のサーバに送信し（ステップ８２０）、ステップ８３０に進む。

ステップ８３０では、第一のサーバは、ユーザ許可の否認が否定できない旨のメッセージをステップ８０１のサーバもしくは第三者に送付する（ステップ８３０）。

なお、第一のサーバ３００のメッセージ電文ログ３３１と、第一のサーバ３００のＭＡＣ検証部３４０と、第二のサーバのＭＡＣ検証部４４０と、に第三者がアクセスできる場合、図８のフローチャートの各ステップにおいて第一のサーバと第二のサーバが実行している全ての処理を第三者が実行することができる。

なお、ユーザ端末が生成するメッセージ電文の第一のＭＡＣおよび第二のＭＡＣは式２と式３に記載のものに限らず、第一の共通鍵によるＭＡＣ生成と第二の共通鍵によるＭＡＣ生成を入れ子にして、生成したＭＡＣであってもよい。ここで、入れ子とは、第二の共通鍵で生成したＭＡＣを、第一の共通鍵によるＭＡＣ生成の入力の一部とすること、または、第一の共通鍵で生成したＭＡＣを、第二の共通鍵によるＭＡＣ生成の入力の一部とすること、を意味する。例えば、次の数６と数７で表されるmac_12とmac_21をそれぞれ第一のＭＡＣと第二のＭＡＣとしてもよい。

mac_12およびmac_21をそれぞれ第一のＭＡＣおよび第二のＭＡＣとする場合、ユーザ端末のＭＡＣ生成部およびサーバのＭＡＣ検証部は、それぞれ数６および数７に従ってＭＡＣの生成および検証を行う。

第二の実施形態は、第一の実施形態を拡張した実施形態であり、第一の実施形態で２つであったサーバを第一のサーバから第ＮのサーバまでのＮ個のサーバに拡張した実施形態である。

図８は、第二の実施形態のシステムの全体構成図である。ユーザ端末１２００と第一のサーバ１３００は第一のネットワーク１１００を通して繋がっており、第一のサーバから第ＮのサーバのＮ個のサーバは第二のネットワーク１１１０を通して繋がっている。

図９はユーザ端末１２００の概要図である。ユーザ端末は、第一の実施例と同様の構成をとり、制御部、データ送受信部、記憶部、ＭＡＣ生成部、表示装置、入力装置からなる。記憶部１２３０には第一の共通鍵から第Ｎの共通鍵までＮ個の共通鍵が格納される。

ＭＡＣ生成部は、第一の実施例と同じＭＡＣ生成関数機能１２６１を備える。

ＭＡＣ生成部は、制御部から、ＭＡＣ付加対象のメッセージと、ヘッダと、第一の共通鍵から第Ｎの共通鍵のＮ個の共通鍵と、を受け取り、処理することで、ＭＡＣが付加されたメッセージ電文１５００を生成する。

なお、図２の説明と共通する構成についての説明は省略する。

図１０は、メッセージ電文１５００のフォーマットを示す図である。

ＭＡＣ生成部１２６０における、メッセージ電文１５００の生成手順は次のとおりである。なお、以降では前記ヘッダをh、前記メッセージをm、第iの共通鍵をk_i、前記メッセージ電文をm_out、第iのＭＡＣをmac_iと記載する。

まず、ＭＡＣ生成部はＮ個のＭＡＣを生成する。例えば、第iのＭＡＣについては、ＭＡＣ生成部は前記ヘッダと前記メッセージを連結したデータと、第iの共通鍵と、をＭＡＣ生成関数機能に渡し、第iのＭＡＣを得る。数式では次のように表される。

そして、ＭＡＣ生成部は、前記ヘッダと、前記メッセージと、第一のＭＡＣから第ＮのＭＡＣまでのＮ個のＭＡＣと、を連結し、メッセージ電文を生成する。

第一のサーバは、第一の実施例の第一のサーバ３００と同様の構成をとり、制御部、データ送受信部、記憶部、ＭＡＣ検証部とからなる。記憶部に第一の共通鍵が格納される。

第二のサーバから第Ｎのサーバの各サーバは、第一の実施例の第二のサーバ４００と同様の構成をとり、制御部、データ送受信部、記憶部、ＭＡＣ検証部とからなる。記憶部に格納される共通鍵は各サーバで異なり第ｋのサーバには第ｋの共通鍵が格納される。

第一のサーバから第Ｎのサーバの各サーバのＭＡＣ検証部は、第一の実施例と同等のＭＡＣ検証関数機能３４１を備える。

第iのサーバのＭＡＣ検証部は、制御部からメッセージ電文と第iの共通鍵を受け取り、メッセージ電文の正当性を検証する。まず、ＭＡＣ検証部は、メッセージ電文から、メッセージ電文のフォーマット１５００に従い、ヘッダとメッセージと第iのＭＡＣを抜き出す。次に、ＭＡＣ検証部は、ヘッダとメッセージを連結したデータを検証対象メッセージとして、第iの共通鍵を共通鍵として、第iのＭＡＣを検証対象ＭＡＣとして、ＭＡＣ検証関数機能に渡し、検証結果を得る。そして、ＭＡＣ検証部は、得られた検証結果を制御部に返す。
図１１は、第二の実施形態における処理実行確認の手順を表したフローチャートである。なお、ステップにおけるｍは、Ｎ／２より大きく、かつ、Ｎ以下の整数とする。
まず、第一のサーバ１３００からユーザ端末１２００に処理実行の許可を要求するメッセージを送信する（ステップ１００１）。ユーザ端末１２００のデータ送受信部１２２０が許可要求電文を受信し、許可要求メッセージを描画した画面を表示装置１２４０に出力する（ステップ１００２）。ユーザはユーザ端末１２００の入力装置１２５０を用いて、許可要求に対して許可もしくは拒否を入力する（ステップ１００３）。
ステップ１００３で許可が入力された場合、ユーザ端末１２００の制御部１２１０は、記憶部１２３０から第一の共通鍵から第Ｎの共通鍵のＮ個の共通鍵を取得し、許可する旨のメッセージとヘッダと当該Ｎ個の共通鍵と、をＭＡＣ生成部１２６０に渡し、ＭＡＣ生成部は、メッセージ電文１５００を生成し、制御部に当該メッセージ電文を返す（ステップ１００４）。制御部１２１０はデータ送受信部１２２０を通して、前期メッセージ電文を第一のサーバ１３００に送信する（ステップ１００５）。
第一のサーバのデータ送受信部は前記メッセージ電文を受信し、当該データ送受信部を通して、当該メッセージ電文を第二のサーバから第ＮのサーバのＮ−１個のサーバに送信する（ステップ１００６）。
メッセージ電文を得た各第iのサーバにおいて、サーバの制御部は、記憶部から第iの共通鍵を取得し、当該メッセージ電文と当該第iの共通鍵と、をサーバのＭＡＣ検証部に渡し、当該ＭＡＣ検証部は当該メッセージ電文の正当性を検証し、検証結果を制御部に返す（ステップ１００７）。各第iのサーバの制御部は、前記検証結果を第一のサーバに送信する（ステップ１００８）。第一のサーバは、集まったＮ個の検証結果のうち、検証に成功したものの数をカウントし、成功数がｍ個以上かどうかを確認する（ステップ１００９）。
ステップ１００９で、検証成功数がｍ個以上の場合、第一のサーバ１３００の制御部は、前記メッセージ電文を格納部のメッセージ電文ログに追加し、データ送受信部を通して、ステップ１００１でユーザに許可を要求していた処理を実行するサーバ、あるいは、ユーザ端末に処理実行可能のメッセージを送付する（ステップ１０１０）。処理実行のメッセージを受け取ったサーバ、あるいは、ユーザ端末は処理を実行する（ステップ１０１１）。

ステップ１００３で、拒否の場合、ユーザ端末１２００は拒否する旨のメッセージを第一のサーバに送信し（ステップ１０２０）、ステップ１０３０に進む。

ステップ１００８で、検証成功数がｍ個未満の場合、ステップ１０３０に進む。

ステップ１０３０では、第一のサーバ１３００は、ステップ１００１でユーザに許可を要求していた処理をする予定だったサーバ、あるいは、ユーザ端末に処理実行不可のメッセージを送付する（ステップ１０３０）。処理実行不可のメッセージを受け取ったサーバ、あるいは、ユーザ端末は処理を実行せずに、中止する（ステップ１０３１）。

なお、ユーザが過去に許可したシステム動作に関して、許可したことを否認した場合に、サーバもしくは第三者は、否認を否定することができる。図１２は、否認を否定する手順を表すフローチャートである。

まず、ユーザによる許可の否認を否定したいサーバもしくは第三者が第一のサーバにユーザ許可の確認を要求する（ステップ１４０１）。第一のサーバの制御部は、格納部のメッセージ電文ログから対応するユーザ許可のメッセージ電文を取得する（ステップ１４０２）。第一のサーバの制御部は、前記メッセージ電文を、第２のサーバから第ＮのサーバのＮ−１個のサーバに送信する（ステップ１４０３）。各サーバの制御部は、前記メッセージ電文と、格納部から取得する自身の持つ共通鍵と、をＭＡＣ検証部に渡し、ＭＡＣ検証部は、前記メッセージ電文と、共通鍵と、からメッセージ電文の正当性を検証する（ステップ１４０４）。各サーバは、第一のサーバに検証結果を送信する（ステップ１４０５）。第一のサーバは、集まったＮ個の検証結果のうち、検証成功したものの数をカウントし、成功数がｍ個以上かどうかを確認する（ステップ１４０６）。
ステップ１４０６で、ｍ個以上の場合、第一のサーバ１３００は、ユーザ許可の確認がとれた旨のメッセージと前記メッセージ電文をステップ１４０１のサーバ、あるいは、第三者に送付する（ステップ１４０７）。
ステップ１４０６で、ｍ個未満の場合、第一のサーバは、ユーザ許可の否認が否定できない旨のメッセージを１４０１のサーバ、あるいは、第三者に送付する（ステップ１４２０）。

なお、第一のサーバ１３００のメッセージ電文ログと、第一のサーバから第Ｎのサーバの全てのＭＡＣ検証部と、に第三者がアクセスできる場合、図１２のフローチャートの各ステップにおいて第一のサーバから第Ｎのサーバが実行している全ての処理を第三者が実行することができる。

なお、第二の実施例において、ユーザ端末１２００のＭＡＣ生成部１２６０が生成するメッセージ電文の第iのＭＡＣは式６に記載のものに限らない。例えば、第iのＭＡＣは、以下の式で表されるmac_i’であってもよい。

ここで、othermac_iは、k_i以外のＮ−１個の共通鍵とヘッダhとメッセージmとGenmac関数とを利用して計算できる任意の値である。

１００第一のネットワーク、１１０第二のネットワーク、
２００ユーザ端末、２１０制御部、２２０データ送受信部、２３０記憶部、
２３１第一の共通鍵、２３２第二の共通鍵、２４０表示装置、
２５０入力装置、２６０ＭＡＣ生成部、２６１ＭＡＣ生成関数機能、
３００第一のサーバ、３１０制御部、３２０データ送受信部
３３０記憶部、３３１メッセージ電文ログ、３４０ＭＡＣ検証部
３４１ＭＡＣ検証関数機能、４００第二のサーバ、４１０制御部
４２０データ送受信部、４３０記憶部、４４０ＭＡＣ検証部
４４１ＭＡＣ検証関数機能、５００メッセージ電文、５１０ヘッダ
５２０メッセージ、５３０第一のＭＡＣ、５４０第二のＭＡＣ
１１００第一のネットワーク、１１１０第二のネットワーク
１２００ユーザ端末、１２１０制御部、１２２０データ送受信部
１２３０記憶部、１２４０表示装置、１２５０入力装置
１２６０ＭＡＣ生成部、１２６１ＭＡＣ生成関数機能、
１３００第一のサーバ、１５００メッセージ電文

Claims

ユーザによる端末の処理を、複数のサーバを用いて確認する確認システムであって、
前記複数のサーバは、第一のサーバと第二のサーバであり、
前記端末と前記第一のサーバは第一のネットワークを介して接続されており、前記第一のサーバと前記第二のサーバは第二のネットワークを介して接続されており、
前記端末は、
第一の共通鍵と第二の共通鍵を備える記憶部と、
前記ユーザによる端末の処理に関するメッセージを前記第一及び第二の共通鍵で暗号化するＭＡＣ生成部と、
前記ＭＡＣ生成部により生成されたファイルを第一のサーバに送信するデータ送受信部と、を備え、
前記第一のサーバは、
受信したファイルを第一の共通鍵で復号化し、ファイルの正当性を検証するＭＡＣ検証部と、
前記ＭＡＣ検証部による検証で正当性が検証されたファイルを前記第二のサーバに送信し、前記第二のサーバの検証結果を受信するデータ送受信部と、
前記第二のサーバの検証結果を格納する記憶部と、を備え、
前記第二のサーバは、
前記第一のサーバから受信したファイルを前記第二の共通鍵で復号化し、ファイルの正当性を検証するＭＡＣ検証部と、
前記ＭＡＣ検証部による検証で正当性が検証されたファイルを前記第一のサーバに送信するデータ送受信部と、
を備えることを特徴とする確認システム。
請求項１に記載の確認システムにおいて、
前記第一のサーバは、前記端末が前記第一の共通鍵で生成した第一のＭＡＣと当該第一のサーバが有する第一の共通鍵で生成した第三のＭＡＣとが一致するかを検証し、
前記第二のサーバは、前記端末が前記第二の共通鍵で生成した第二のＭＡＣと当該第二のサーバが有する第二の共通鍵で生成した第四のＭＡＣとが一致するかを検証することを特徴とする確認システム。
請求項２に記載の確認システムにおいて、
前記端末のＭＡＣ生成部は、前記第一のＭＡＣおよび前記第二のＭＡＣを、前記第一の共通鍵によるＭＡＣ生成と前記第二の共通鍵によるＭＡＣ生成とを入れ子にして生成することを特徴とする確認システム。
請求項３に記載の確認システムであって、
前記第一のＭＡＣと前記第三のＭＡＣが一致し、かつ、前記第二のＭＡＣと前記第四のＭＡＣが一致した場合にのみ、ユーザの実行を許可することを特徴とする確認システム。
請求項４に記載の確認システムにおいて、
前記ユーザの実行は、アップデートデータによる端末のアップデートであることを特徴とする確認システム。
請求項２乃至５のいずれか一項に記載の確認システムにおいて、
前記サーバはＮ個あり、
前記端末のＭＡＣ生成部は、第一の共通鍵から第Ｎの共通鍵までのＮ個の共通鍵を用いて第一のＭＡＣから第ＮのＭＡＣまでのＮ個のＭＡＣを生成し、
２からＮ−１の値をとる各ｋに対して一つ存在する第ｋのサーバのＭＡＣ検証部は、第ｋの共通鍵を用いて第Ｎ＋ｋのＭＡＣを生成し、前記第Ｎ＋ｋのＭＡＣと前記ファイルの第ｋのＭＡＣとが一致するかを検証する確認システム。
請求項６に記載の確認システムであって、
１からＮのｋに対して、ｍ個より多くのｋにおいて、前記第ｋのＭＡＣと前記第Ｎ＋ｋのＭＡＣが一致した場合にユーザの実行を許可することを特徴とする確認システム。
ユーザによる端末の処理を、複数のサーバを用いて確認する確認方法であって、
前記複数のサーバは、第一のサーバと第二のサーバであり、
前記端末と前記第一のサーバは第一のネットワークを介して接続されており、前記第一のサーバと前記第二のサーバは第二のネットワークを介して接続されており、
前記端末は、
第一の共通鍵と第二の共通鍵を予め備えておき、
前記ユーザによる端末の処理に関するメッセージを前記第一及び第二の共通鍵で暗号化するＭＡＣ生成ステップと、
前記ＭＡＣ生成ステップにより生成されたファイルを第一のサーバに送信するデータ送信ステップと、
前記第一のサーバが、受信したファイルを第一の共通鍵で復号化し、ファイルの正当性を検証するＭＡＣ検証するステップと、
前記第一のサーバによるＭＡＣ検証ステップによる検証で正当性が検証されたファイルを前記第二のサーバに送信するステップと、
前記第二のサーバが、前記第一のサーバから受信したファイルを前記第二の共通鍵で復号化し、ファイルの正当性を検証する第二のサーバによるＭＡＣ検証ステップと、
前記第二のサーバによるＭＡＣ検証ステップによる検証で正当性が検証されたファイルを前記第一のサーバに送信するデータ送信ステップと、
前記第二のサーバの検証結果を第一のサーバが受信して記憶部に格納する記憶ステップと、
を備えることを特徴とする確認方法。