JP2018205502A - 乱数性検証システム及び乱数性検証方法 - Google Patents

Abstract

【課題】検証サーバにより乱数性が認められた乱数を用いて通信端末が実際の運用時に通信相手の機器との間で安全にデータ通信を行うことを担保する。
【解決手段】端末１０は、予め乱数性が認められたシードｓｄを用いて生成した共通鍵Ｋｐを検証サーバ３０との間で交換する。端末１０は、ノイズ源１５からの複数の測定値を用いて検証データｖｄを生成する。端末１０は、検証データｖｄを共通鍵Ｋｐで暗号化して検証サーバ３０に送信する。検証サーバ３０は、暗号化された検証データｖｄを共通鍵Ｋｐで復号して得られた検証データｖｄの乱数性を検証する。検証サーバ３０は、検証データｖｄの乱数性があると判断した場合に、検証データｖｄの乱数性を認める旨の検証結果を端末１０に送信する。端末１０は、検証サーバ３０からの検証結果に応じて、複数の測定値を取得して新たなシードｓｄを生成してセキュアエリア１３に保存する。
【選択図】図４

Description

本開示は、乱数性検証システム及び乱数性検証方法に関する。

ＩｏＴ（Internet of Things）機器は、「モノのインターネット」とも呼ばれ、例えばセンシングデバイスを有するとともに、インターネット等の通信ネットワークに接続可能な機器である。ＩｏＴ機器は、センシングデバイスにより検知されたセンシング結果のデータを、通信ネットワークを介して、ネットワーク上のクラウドサーバとの間で通信できる。

ＩｏＴ機器は、クラウドサーバにセンシング結果のデータを送信し、クラウドサーバにより分析された結果のデータ（例えば、ＩｏＴ機器を制御するための制御データ）を受信し、必要に応じて、ＩｏＴ機器が備えるアクチュエータを駆動する。

ＩｏＴ機器はインターネットに接続される機器であり、セキュリティリスクが懸念されるが、ＰＣ（Personal Computer）と比べハードスペックが劣るため、セキュリティ対策が十分とはいえない。しかし、セキュリティ対策が不十分なＩｏＴ機器がサイバー攻撃を受けた場合、別のＩｏＴ機器やＩｏＴサービス全体など、広範囲に波及する可能性がある。例えば、自動車分野や医療分野におけるサイバー攻撃では、ユーザの生命や財産が危険にさらされる場合もある。従って、ＩｏＴ機器でもＰＣと同じ強度のセキュリティ対策が必要である。

セキュリティ対策として、例えば暗号化通信のプロトコルのＳＳＬ（Secure Sockets Layer）による安全なインターネット接続の確保が上げられる。ＳＳＬ接続には安全な鍵（乱数）が必要であり、乱数は擬似乱数生成器（ＰＲＮＧ）に乱数の種であるシード（ＳＥＥＤ）を与えて得ることもできる。

安全な乱数を得るためには、乱数又はシードは、機器内部で生成し設計者も知り得ない秘密の情報にして、それを使いまわしせず機器内部で定期的に更新することが望まれる。

しかしながら、ＩｏＴ機器は低機能及び低価格であることが多く、セキュリティ対策が施されていないものもあれば、たとえセキュリティ対策が施されたとしても、セキュリティ強度は低い。例えば、擬似乱数生成器を用いた乱数の生成において、出荷前に予め組み込んだシードを使いまわしたり、時間とＭＡＣ（Media Access Control）アドレスとを組み合わせた値をシードとして使用したりするケースもある。

ＩｏＴ機器のセキュリティ強度を高めるため、ＩｏＴ機器に特殊なハードウェアで構成される乱数生成回路を組み込んで乱数又はシードを生成する方法があるが、ローエンド仕様で製造されるＩｏＴ機器には適さない。

ここで、上述した乱数生成回路を有する先行技術として、例えば特許文献１の乱数生成装置が提案されている。特許文献１の乱数生成装置は、外部装置からの選択信号をセレクタに入力することにより、発振回路の発振周波数を設定し、発振回路からの出力値を保持し、サンプリングクロックに従ってサンプリング回路から出力される出力値を配列する。これにより、乱数生成装置は、真性度の高い乱数を生成できる。

特開２０１６−１２６５１８号公報

特許文献１では、乱数生成装置とは異なる外部装置によって、乱数生成装置により生成された乱数の真性度（再現不可能性及び予測不可能性）が評価されることは開示されている。しかし、特許文献１では、外部装置と乱数生成装置とがどのように接続されているかについての具体的な説明が無い。

ここで、特許文献１の乱数生成装置を、ネットワークを介した通信時にセキュリティの脆弱性が指定されるＩｏＴ機器に適用した場合を想定する。乱数生成装置と外部装置とがネットワークを介して通信可能に接続されていると、乱数生成装置は、外部装置に乱数の真性度の評価を行ってもらうために乱数のデータを安全に送信する必要があると推察される。ところが、特許文献１には、乱数生成装置から外部装置に乱数のデータを送信する時のセキュリティ対策は考慮されていないので、乱数のデータが外部装置に送られる際に漏えいする可能性がある。ＩｏＴ機器は、実際の運用時、自ら生成した乱数（シード）を用いて暗号化用の鍵（暗号鍵）を生成した上で、この暗号鍵によって通信用のデータを暗号化する。従って、実際の運用時において、ＩｏＴ機器と通信相手の機器との間で安全なデータ通信を行うことが困難であるという課題が生じる。

本開示は、上述した従来の事情に鑑みて案出され、端末により生成された乱数の乱数性を検証する検証サーバとの間で安全に乱数のデータを送受信し、検証サーバにより乱数性が認められた乱数を用いて端末が実際の運用時に通信相手の機器との間で安全にデータ通信を行うことを担保する乱数性検証システム及び乱数性検証方法を提供することを目的とする。

本開示は、端末と第１のサーバとが通信可能に接続された乱数性検証システムであって、前記端末は、予め乱数性が認められた第１のシードを保持するセキュアメモリ部を有し、前記第１のシードを用いて生成した共通鍵を前記第１のサーバとの間で交換し、複数の測定値を取得し、所定のタイミングに前記複数の測定値を用いて検証データとしての乱数を生成し、生成された前記検証データを前記共通鍵で暗号化して前記第１のサーバに送信し、前記第１のサーバは、前記端末により暗号化された前記検証データを前記共通鍵で復号して得られた前記検証データの乱数性を検証し、前記検証データの乱数性があると判断した場合に、前記検証データの乱数性を認める旨の検証結果を前記端末に送信し、前記端末は、前記検証結果の受信に応じて、複数の測定値を取得し、前記複数の測定値を用いて前記第１のシードを更新して前記セキュアメモリ部に保存する、乱数性検証システムを提供する。

また、本開示は、端末と第１のサーバとが通信可能に接続された乱数性検証システムを用いた乱数性検証方法であって、前記端末は、予め乱数性が認められた第１のシードを保持するセキュアメモリ部を有し、前記第１のシードを用いて生成した共通鍵を前記第１のサーバとの間で交換し、複数の測定値を取得し、所定のタイミングに前記複数の測定値を用いて検証データとしての乱数を生成し、生成された前記検証データを前記共通鍵で暗号化して前記第１のサーバに送信し、前記第１のサーバは、前記端末により暗号化された前記検証データを前記共通鍵で復号して得られた前記検証データの乱数性を検証し、前記検証データの乱数性があると判断した場合に、前記検証データの乱数性を認める旨の検証結果を前記端末に送信し、前記端末は、前記検証結果の受信に応じて、複数の測定値を取得し、前記複数の測定値を用いて前記第１のシードを更新して前記セキュアメモリ部に保存する、乱数性検証方法を提供する。

本開示によれば、端末により生成された乱数の乱数性を検証する検証サーバとの間で安全に乱数のデータを送受信でき、検証サーバにより乱数性が認められた乱数を用いて端末が実際の運用時に通信相手の機器との間で安全にデータ通信を行うことを担保することができる。

端末の出荷前の乱数性検証システムの構成例を示すブロック図 端末の運用中の乱数性検証システムの構成例を示すブロック図 出荷前のテストモード時の端末及び検証サーバの構成例を示すブロック図 運用中のテストモード時の端末及び検証サーバの構成例を示すブロック図 ＳＳＬネゴシエーションのシーケンス、及びテストモード時の検証のシーケンスの概要例を示す説明図 通常モード時の端末の構成例を示すブロック図 延命モード時の端末の構成例を示すブロック図 テストモード時に検証結果がＯＫとなる場合の動作手順の一例を示すシーケンス図 テストモード時に検証結果がＮＧとなる場合の第１の動作手順の一例を示すシーケンス図 テストモード時に検証結果がＮＧとなる場合の第２の動作手順の一例を示すシーケンス図 テストモード時に検証結果がＮＧとなる場合の第３の動作手順の一例を示すシーケンス図 テストモード時に検証結果がＮＧとなる場合の第４の動作手順の一例を示すシーケンス図 テストモードから通常モードへの移行の動作手順の一例を示すシーケンス図 図１２に続くシーケンス図 テストモードから延命モードへの移行の動作手順の一例を示すシーケンス図

以下、適宜図面を参照しながら、本開示に係る乱数性検証システム及び乱数性検証方法を具体的に開示した実施の形態（以下、「本実施の形態」という）を詳細に説明する。但し、必要以上に詳細な説明は省略する場合がある。例えば、既によく知られた事項の詳細説明や実質的に同一の構成に対する重複説明を省略する場合がある。これは、以下の説明が不必要に冗長になるのを避け、当業者の理解を容易にするためである。なお、添付図面及び以下の説明は、当業者が本開示を十分に理解するために提供されるのであって、これらにより特許請求の範囲に記載の主題を限定することは意図されていない。

図１Ａは、端末１０の出荷前の乱数性検証システム５Ａの構成例を示すブロック図である。

図１Ａに示す乱数性検証システム５Ａは、端末１０と第１のサーバの一例としての検証サーバ３０とを含む構成である。出荷の対象物としての端末１０と、検証サーバ３０とは、例えば有線Ｌ１で接続される。

端末１０は、例えばＩｏＴ（Internet of Things）機器等の通信端末である。ＩｏＴ機器は、上述したように、例えばセンシングデバイスを有するとともに、インターネット等の通信ネットワークに接続可能なローエンド仕様の電子機器である。ＩｏＴ機器は、センシングデバイスにより検知されたセンシング結果のデータを、通信ネットワークを介して、クラウドサーバとの間で通信でき、クラウドサーバから送信された制御データに従って、自身に内蔵されたアクチュエータを駆動する。ＩｏＴ機器としては、例えば、監視カメラ、決済端末、ボディカメラ、ドアホン、複合機、スマートメータ、ＰＬＣ（programmable logic controller）、ゲートウェイボックス等が挙げられる。言い換えると、端末１０は、例えば上述した監視カメラ、決済端末、ボディカメラ、ドアホン、複合機、スマートメータ、ＰＬＣ（programmable logic controller）、ゲートウェイボックスのうちいずれかである。なお、ここでは、端末１０は、高度な情報処理機能を有しないローエンド仕様の電子機器を挙げたが、高度な情報処理機能を有するＰＣ（Personal Computer）や携帯電話機、スマートフォン等のハイエンド仕様の電子機器であってもよい。

また、ＩｏＴ機器は、一般にローコスト機器であるので、そのセキュリティには、脆弱性がある。

端末１０と検証サーバ３０とを接続する有線Ｌ１には、ＬＡＮ（Local Area Network）、ＵＳＢ（Universal Serial Bus）、シリアル通信線等が用いられる。有線Ｌ１は、端末１０と検証サーバ３０との間で通信が行われるセキュアな通信路である。なお、端末１０と検証サーバ３０とは、セキュア通信路を介して互いに通信可能であればよく、有線接続に限定されない。例えば、端末１０と検証サーバ３０とは、近距離無線（ＮＦＣ：Near Field Communication）もしくは無線ＬＡＮ等で無線接続されてもよい。

図１Ｂは、端末１０の運用中の乱数性検証システム５Ｂの構成例を示すブロック図である。

図１Ｂに示す乱数性検証システム５Ｂは、端末１０Ａと、端末１０Ｂと、第１のサーバの一例としての検証サーバ３０と、アプリサーバ５０とを含む構成である。端末１０Ａと、端末１０Ｂと、検証サーバ３０と、アプリサーバ５０とは、例えばネットワークＮＷを介して接続される。ネットワークＮＷの形態は、使用目的に応じて適宜設定されて構わない。つまり、ネットワークＮＷは、有線ネットワークでもよいし、無線ネットワークでもよい。以下、アプリサーバは、アプリケーションサーバの略称として称する。

ネットワークＮＷに有線接続される端末１０を端末１０Ａと称する。ネットワークＮＷに無線接続される端末１０を端末１０Ｂと称する。特に、端末１０Ａと端末１０Ｂとを区別する必要が無い場合、端末１０Ａと端末１０Ｂとを纏めて端末１０と総称する。なお、以下の説明において、端末１０の出荷前の乱数性検証システム５Ａ（図１Ａ参照）と端末１０の運用中の乱数性検証システム５Ｂとを、纏めて乱数性検証システム５と総称する。

検証サーバ３０は、端末１０により生成されかつセキュアな方法によって端末１０から送信された検証データに乱数性が認められるか又は認められないかを検証する。乱数性とは、例えば検証データが乱数としての適格性を有することを示す。乱数としての適格性は、例えば乱数を構成する複数の測定値（後述参照）のそれぞれの一部のビット列のデータの出現頻度分布が一様であることを示す。従って、上述した測定値の一部のビット列のデータが特定の値に偏って出現する場合には、乱数としての適格性に欠け、乱数性は無いと判断される。一方、上述した測定値の一部のビット列のデータの出現頻度の分布が一様である場合には、乱数としての適格性を有し、乱数性があると判断される。検証サーバ３０の構成の詳細については後述する。

アプリサーバ５０は、通常モード時（つまり、端末１０の通常の運用時。以下同様。）において、端末１０との間でＳＳＬ（Secure Socket Layer）ネゴシエーションの処理を行って、端末１０により生成されかつＳＳＬネゴシエーションの処理時に端末１０から送信された共通鍵を取得して保持する。また、アプリサーバ５０は、上述した通常モード時には、この共通鍵を用いて、端末１０との間で送受信するデータの暗号化や復号の処理を行う。つまり、アプリサーバ５０は、通常モード時、ＳＳＬネゴシエーションの処理によって取得した共通鍵を用いて、端末１０に送信するデータを暗号化して端末１０に送信したり、端末１０により暗号化されたデータを復号したりする。

図２は、出荷前のテストモード時の端末１０及び検証サーバ３０の構成例を示すブロック図である。

端末１０が工場から出荷される前の乱数性検証システム５Ａでは、端末１０と検証サーバ３０とは、有線Ｌ１で直接に接続される。端末１０は、物理乱数生成部１１と、セキュアエリア１３と、テストクライアント部１２と、通信Ｉ／Ｆ（インターフェース）１４と、ノイズ源１５とを含む構成である。ここで、物理乱数生成部１１及びテストクライアント部１２は、例えばＣＰＵ（Central Processing Unit）２０等のプロセッサによって実行されるアプリケーションであり、ＣＰＵ２０の機能的な処理部として構成される。

検証サーバ３０は、検証部３１と、テストサーバ部３２と、通信Ｉ／Ｆ３６とを含む構成である。ここで、検証部３１及びテストサーバ部３２は、例えばＣＰＵ４０等のプロセッサによって実行されるアプリケーションであり、ＣＰＵ４０の機能的な処理部として構成される。

通信Ｉ／Ｆ１４と通信Ｉ／Ｆ３６とは、例えば有線ＬＡＮ、ＵＳＢケーブル、シリアル通信線等の有線Ｌ１で直接に接続され、それぞれの通信プロトコルに従って、互いにデータの送受信を行う。

検証サーバ３０において、検証部３１は、端末１０により生成されて端末１０から送信された検証データの乱数性の検証（つまり、検証データに乱数性が認められるかどうかの判断）を行う。検証部３１は、テストサーバ部３２から検証データを受け取って検証を実行するとともに、検証結果をテストサーバ部３２に通知する。

なお、検証部３１による乱数性の検証方法は、公知技術として既知である。例えば、特開２０１６−８１２４７号公報（特に段落０００８参照）、もしくは特開２０１５−１０２９８１号公報（特に段落００１９参照）、非特許文献「NIST Special Publication 800-90B, “Recommendation for the Entropy Sources Used for Random Bit Generation”, Elaine Barker John Kelsey, January 2016」に記載の技術（例えば、Repetition Count TestもしくはAdaptive Proportion Test）が挙げられる。

テストサーバ部３２は、通信Ｉ／Ｆ３６を介して、端末１０のテストクライアント部１２に検証データを要求する。テストサーバ部３２は、端末１０により生成されて端末１０から送信された検証データを、通信Ｉ／Ｆ３６を介して受け取る。テストサーバ部３２は、受け取った検証データを検証部３１に渡し、その検証結果を受け取る。テストサーバ部３２は、通信Ｉ／Ｆ３６を介して、検証結果をテストクライアント部１２に通知する。

端末１０において、物理乱数生成部１１は、擬似乱数の初期値として与えるためのシード、又は検証データを生成する。本実施の形態のシード及び検証データのそれぞれの役割については後述する。具体的には、物理乱数生成部１１は、テストクライアント部１２からシード又は検証データの生成が要求されると、ノイズ源１５より乱数の元となる値（言い換えると、測定値）を取り出す。物理乱数生成部１１は、取り出された測定値の一部の桁のビット列が一定の量に達するまで複数の測定値をサンプリング（収集）し、サンプリングにより得られた一定の量の桁数に対応したビット列のデータ（つまり、検証サーバ３０による検証対象となる乱数）を、サンプリングデータとしてメモリ（図示略）に記憶する。なお、このメモリは、後述するセキュアエリア１３でもよいし、端末１０が備えるメモリ（図２に図示略）でもよい。

物理乱数生成部１１は、テストクライアント部１２からシードを要求された場合、サンプリングデータをシードとしてセキュアエリア１３に保存してもよい。また、物理乱数生成部１１は、ノイズ源１５から出力される値に対して所定の後処理（例えばノイズ源１５から得られた値の統計的偏りを低減することで、その値のエントロピーを増やすための処理）を施したサンプリングデータをシードとしてセキュアエリア１３に保存してもよい。

物理乱数生成部１１は、テストクライアント部１２から検証データを要求された場合、サンプリングデータを検証データとしてテストクライアント部１２に渡してもよい。また物理乱数生成部１１は、ノイズ源１５から出力される値に対して所定の後処理（例えばノイズ源１５から得られた値の統計的偏りを低減することで、その値のエントロピーを増やすための処理）を施したサンプリングデータを検証データとしてテストクライアント部１２に渡してもよい。つまり、物理乱数生成部１１は、サンプリングデータの乱数性を高める（つまり、シード又は検証データのエントロピーを増やす）ための後処理を行った上で、シード又は検証データを生成してもよい。

また、物理乱数生成部１１は、上述した後処理に関して、複数種類の後処理を実行可能であり、テストクライアント部１２からの指示に従い、後処理のパターン（つまり、やり方）を変更して実行できる。複数の後処理の例として、上述した非特許文献「NIST Special Publication 800-90B, “Recommendation for the Entropy Sources Used for Random Bit Generation”, Elaine Barker John Kelsey, January 2016」に記載の技術が挙げられる。この非特許文献では、例えば後処理として、エントロピーソースモデルのノイズ源から得られたサンプリングデータの統計的偏りを低減することで、その出力のエントロピー率を増加させるための、複数の単純な後処理のやり方が開示されている。

また、上述した非特許文献では、後処理のやり方の他の例として、ノイズ源自身が出力（つまり、サンプリングデータ）の品質を改善するための簡単な後処理機能を含むことが開示されている。つまり、ノイズ源自体が、後処理として、例えばフォンノイマンの方法、線形フィルタリング方法、ランレングス法のうちいずれか一つを使用する。従って、物理乱数生成部１１は、物理乱数生成部１１自身、又は物理乱数生成部１１とノイズ源１５との協働によって、上述した非特許文献に開示されている複数種類の後処理のパターン（やり方）の中からいずれか一つを使用して実行可能である。

物理乱数生成部１１は、テストクライアント部１２からの指示に従い、検証データとして、シード、又はサンプリングデータ（つまり、検証サーバ３０による検証対象となる乱数）をテストクライアント部１２に渡す。物理乱数生成部１１は、テストクライアント部１２からの指示に従い、セキュアエリア１３にアクセスして、シード又はサンプリングデータをセキュアエリア１３に保存する。

テストクライアント部１２は、テストサーバ部３２から送信された検証データの要求を、通信Ｉ／Ｆ１４を介して受け取る。テストクライアント部１２は、検証サーバ３０のテストサーバ部３２により検証データが要求されると、物理乱数生成部１１に検証データを要求するとともに、物理乱数生成部１１から検証データを受け取り、通信Ｉ／Ｆ１４を介してテストサーバ部３２に送る。テストクライアント部１２は、検証サーバ３０から送信された検証結果を、通信Ｉ／Ｆ１４を介して受け取る。テストクライアント部１２は、検証結果として、検証データ（例えばノイズ源１５から取得された測定値に基づいて生成された乱数）に乱数性が認められた場合には、物理乱数生成部１１に対し、シードの生成を要求するとともに、生成されたシードをセキュアエリア１３に保存するように指示する。

セキュアメモリ部の一例としてのセキュアエリア１３は、例えばシードを保存（記憶）するメモリエリアであり、物理乱数生成部１１からのアクセスを許容し、他の各部からのアクセスが禁止されたエリアである。セキュアエリア１３には、例えば耐タンパ性を有するメモリが使用される。セキュアエリア１３にシードを記憶することで、例えばマルウェア等のウイルスに感染されたアプリケーション（言い換えると、悪意のあるアプリケーション）からのセキュアエリア１３に対するデータアクセスを防止でき、端末１０により保持される情報又はデータのセキュリティが向上し、端末１０に対するセキュリティの脆弱性が改善する。

ノイズ源１５は、端末１０内に１つに限らず、後述するノイズ源１５Ａ，１５Ｂのように、２つ以上のノイズ源を有してもよく、それぞれランダムな値（つまり、測定値）を発生する。サンプリングによって、ノイズ源（つまり、端末１０が取得する測定値を生成するソース（供給源））から収集された測定値のデータは、測定値の上位側の桁の理論ビットと測定値の下位側の桁の有効ビットとで構成され、Ｍ（Ｍ：２進数で表した場合に２のべき乗となる整数値）桁のビットを有する。理論ビットは、測定値の理論値付近の値であり、ビットの出現パターンが一定に近く、乱数の生成への適格性に欠け、乱数の生成に使用できないビット列又はビットである。有効ビットは、Ｎ（Ｎ＜Ｍとなる整数値）桁の値であり、ノイズ源のゆらぎから生じる測定値の誤差付近の値であり、ビットの出現パターンがランダムで、乱数の生成への適格性を有し、乱数の生成に使用できるビット列又はビットである。例えば、測定値が１０進数表記で「２４６」、２進数表記では「１１１１０１１０」の８桁のビット列で表される場合、上位６桁のビット列（つまり、「１１１１０１」）を理論ビット、下位２桁のビット列（つまり、「１０」）を有効ビットにそれぞれ決めることが可能である。ノイズ源１５は、一例として、低速オシレータの１クロック期間内に、高速オシレータから出力されるクロックを計数するクロックカウンタの計数値を測定値として出力する。

また、ノイズ源１５からの測定値は、端末１０の内部で生成されてもよいし、外部装置から入力されてもよい。ノイズ源１５からの測定値として、上述したクロックカウンタの計数値の他、ネットワークを介して通信機器と送受信されるパケットの到達時間（デルタ時間）や、ＵＤＰ（User Datagram Protocol）或いはＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）を用いて伝送されるパケットの遅延時間が挙げられる。また、ノイズ源からの測定値として、ＣＰＵ２０が端末１０内に設けられるフラッシュメモリやＨＤＤ等の記憶媒体（図示略）に対して行う書込みの時間や読込みの時間が挙げられる。また、端末１０のＣＰＵ２０に内蔵されるＡＤ変換器（図示略）によるＡ／Ｄ変換値の誤差や、ＣＰＵ２０に内蔵されるＤＡ変換器（図示略）によるＤ／Ａ変換値の誤差が挙げられる。

図３は、運用中のテストモード時の端末１０及び検証サーバ３０の構成例を示す図である。

端末１０が工場から出荷されて実際に使用される運用中の乱数性検証システム５Ｂでは、端末１０と検証サーバ３０とは、ネットワークＮＷを介して接続される。

端末１０は、物理乱数生成部１１と、セキュアエリア１３と、テストクライアント部１２と、通信Ｉ／Ｆ１４と、ノイズ源１５とに加え（図２参照）、暗号・復号モジュール部１６と、擬似乱数生成部１７とをさらに含む構成である。ここで、暗号・復号モジュール部１６、擬似乱数生成部１７、物理乱数生成部１１及びテストクライアント部１２は、例えばＣＰＵ２０等のプロセッサによって実行されるアプリケーションであり、ＣＰＵ２０の機能的な処理部として構成される。

検証サーバ３０は、検証部３１と、テストサーバ部３２と、通信Ｉ／Ｆ３６とに加え（図２参照）、物理乱数生成部３３と、暗号・復号モジュール部３４と、ノイズ源３５とを含む構成である。ここで、物理乱数生成部３３と、暗号・復号モジュール部３４と、検証部３１と、テストサーバ部３２とは、例えばＣＰＵ４０等のプロセッサによって実行されるアプリケーションであり、ＣＰＵ４０の機能的な処理部として構成される。

端末１０において、物理乱数生成部１１と、セキュアエリア１３と、テストクライアント部１２と、通信Ｉ／Ｆ１４と、ノイズ源１５との動作は、端末１０と検証サーバ３０との間の接続形態が異なる点を除き、図２に示す端末１０の物理乱数生成部１１と、セキュアエリア１３と、テストクライアント部１２と、通信Ｉ／Ｆ１４と、ノイズ源１５との動作と同一であるため、ここでは説明は割愛する。

暗号・復号モジュール部１６，３４は、公開鍵暗号方式を用いて、実際のＳＳＬ（Secure Sockets Layer）通信時に使用される共通鍵を交換するための処理（ＳＳＬネゴシエーション）時に必要な暗号化又は復号の処理を行う。ＳＳＬネゴシエーションについては、図４を参照して後述する。暗号・復号モジュール部１６，３４は、ＳＳＬネゴシエーションによって端末１０と検証サーバ３０とで互いに共有した共通鍵を用いて、ＳＳＬ通信時に送受信するためのデータに対し、共通鍵暗号方式による情報又はデータの暗号化又は復号の処理を行う。

テストサーバ部３２は、ＳＳＬを使用するアプリケーションである。テストモードが開始されると、テストサーバ部３２は、端末１０との間でＳＳＬネゴシエーションを開始する。ＳＳＬネゴシエーションの後、テストサーバ部３２は、端末１０の出荷前のテストモードと同様の手順（図２参照）を行う。テストサーバ部３２は、端末１０により生成されてセキュアな方法によって端末１０から送信された検証データに対する乱数性の検証結果として、端末１０側のノイズ源１５を用いて生成された検証データに乱数性がないと判定した場合、検証サーバ３０側の物理乱数生成部３３からシードを受け取る。さらに、テストサーバ部３２は、通信Ｉ／Ｆ３６を介して、この受け取ったシードを乱数性の検証結果と共に、端末１０のテストクライアント部１２に送信する。テストサーバ部３２は、通信Ｉ／Ｆ３６を介して端末１０にデータ（例えば乱数性の検証結果と共に送信するシード）を送信する場合、そのデータを暗号・復号モジュール部３４で暗号化させてから取得する。また、テストサーバ部３２は、通信Ｉ／Ｆ３６を介して、端末１０から暗号化されたデータを受信した場合、暗号・復号モジュール部３４でデータを復号させてから取得する。

テストクライアント部１２は、ＳＳＬを使用するアプリケーションである。テストモードが開始されると、テストクライアント部１２は、検証サーバ３０との間でＳＳＬネゴシエーションを開始する。ＳＳＬネゴシエーションの後、テストクライアント部１２は、端末１０の出荷前のテストモードと同様の手順（図２参照）を行う。テストクライアント部１２は、端末１０により生成されてセキュアな方法によって端末１０から送信された検証データに対する乱数性の検証結果として、ノイズ源１５を用いて生成された検証データに乱数性が無いと判定された場合には、通常アプリ部１８（図５，６参照）による各種サーバとの接続を停止させるか、或いは端末１０を延命モードに移行させる。テストクライアント部１２は、通信Ｉ／Ｆ１４を介して検証サーバ３０にデータ（例えば検証データ又は共通鍵）を送信する場合、そのデータを暗号・復号モジュール部１６で暗号化させてから取得する。また、テストクライアント部１２は、通信Ｉ／Ｆ１４を介して、検証サーバ３０から暗号化されたデータ（例えば乱数性の検証結果と共に送信するシード）を受信した場合、そのデータを暗号・復号モジュール部１６でデータを復号させてから取得する。

擬似乱数生成部１７は、物理乱数生成部１１と同様に、セキュアエリア１３に対するアクセスが許容されている。擬似乱数生成部１７は、例えばＳＳＬネゴシエーションの際に、セキュアエリア１３に保存されるシード（つまり、検証サーバ３０によって乱数性があると認められたシード）を用いて、端末１０がＳＳＬ通信する際に使用される共通鍵となる乱数を生成する。

本実施の形態において、実際のＳＳＬ通信を開始するにあたり、端末１０と検証サーバ３０とは、先ず始めにＳＳＬネゴシエーションを行い、ＳＳＬネゴシエーションの処理により、端末１０により生成された共通鍵を互いに共有する。

図４は、ＳＳＬネゴシエーションのシーケンス、及びテストモード時の検証のシーケンスの概要例を示す説明図である。

先ず、出荷前の準備として、端末１０のノイズ源１５から得られた測定値を用いて物理乱数生成部１１により生成されたシードｓｄが検証サーバ３０に送られる。検証サーバ３０により乱数性があると認められたシードｓｄは、端末１０のセキュアエリア１３に保存される。これらの処理が前提となって、ＳＳＬネゴシエーションは、端末１０と検証サーバ３０との間で、テストモード時に行われる検証のシーケンスにおいて、データの暗号化及び復号に用いられる共通鍵を共有するために行われる。

図４において、公開鍵暗号方式を用いたＳＳＬネゴシエーションのシーケンスでは、先ず、検証サーバ３０は、Ｈｅｌｌｏ Ｒｅｑｕｅｓｔの処理として、端末１０にＣｌｉｅｎｔ Ｈｅｌｌｏの処理の実行要求を含むメッセージを端末１０に送信する。端末１０は、検証サーバ３０からのメッセージに応じて、Ｃｌｉｅｎｔ Ｈｅｌｌｏの処理として、検証サーバ３０に通信の開始を通知する。検証サーバ３０は、端末１０から通信の開始を受けると、Ｓｅｒｖｅｒ Ｈｅｌｌｏの処理として、これから使用する暗号とハッシュ関数のアルゴリズムを決定し、端末１０に通知する。

端末１０は、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅの処理として、公開鍵暗号方式を用いて、検証サーバ３０の公開鍵で暗号化された共通鍵生成情報ＰＩを検証サーバ３０に送信する。

具体的には、Ｃｌｉｅｎｔ Ｋｅｙ Ｅｘｃｈａｎｇｅの処理において、テストクライアント部１２から共通鍵の生成が要求された際、暗号・復号モジュール部１６は、擬似乱数生成部１７がセキュアエリア１３から読み出したシードｓｄを共通鍵生成情報ＰＩとして受け取る。共通鍵生成情報ＰＩは、いわゆるプリマスタシークレットと呼ばれる乱数（つまり、共通鍵）を生成するために必要な情報であり、以下の説明においても同様である。暗号・復号モジュール部１６は、共通鍵生成情報ＰＩを用いて、共通鍵Ｋｐを生成して保持する。また、暗号・復号モジュール部１６は、検証サーバ３０の公開鍵Ｋｏを用いて、共通鍵生成情報ＰＩを暗号化して公開鍵共通鍵生成情報を生成し、テストクライアント部１２に渡す。テストクライアント部１２は、通信Ｉ／Ｆ１４を介して、検証サーバ３０側のテストサーバ部３２に公開鍵共通鍵生成情報を送信する。

検証サーバ３０側のテストサーバ部３２は、公開鍵共通鍵生成情報を受信すると、暗号・復号モジュール部３４に渡す。暗号・復号モジュール部３４は、公開鍵共通鍵生成情報を検証サーバ３０の秘密鍵Ｋｓを用いて復号して共通鍵生成情報ＰＩを得る。暗号・復号モジュール部３４は、復号した共通鍵生成情報ＰＩを用いて共通鍵Ｋｐを生成して保持する。この後、端末１０は、Ｆｉｎｉｓｈｅｄの処理として、共通鍵Ｋｐが共有できたことの通知を検証サーバ３０に送信する。同様に、検証サーバ３０は、端末１０からの通知に応じて、Ｆｉｎｉｓｈｅｄの処理として、共通鍵Ｋｐが共有できたことの通知を端末１０に送信する。これにより、端末１０と検証サーバ３０との間のＳＳＬネゴシエーションが終了する。

ＳＳＬネゴシエーション後の検証のシーケンスでは、ＳＳＬネゴシエーションにおいて共有されることとなった共通鍵を用いた共通鍵暗号方式により、端末１０と検証サーバ３０との間でデータ通信が行われる。端末１０は、物理乱数生成部１１により生成されたシード又は乱数である検証データｖｄを共通鍵Ｋｐで暗号化して検証サーバ３０に送信する。検証サーバ３０は、受信した検証データｖｄを共通鍵Ｋｐで復号し、検証部３１で検証を行う。検証サーバ３０は、この検証結果を端末１０に返信する。検証サーバ３０は、この検証結果を端末１０に返信する際に、検証結果を共通鍵で暗号化してから送ってもよいし、共通鍵で暗号化しなくて送ってもよい。

図５は、通常モード時の端末１０の構成例を示すブロック図である。

通常モードでは、端末１０は、通信Ｉ／Ｆ１４と、暗号・復号モジュール部１６と、擬似乱数生成部１７と、物理乱数生成部１１と、ノイズ源１５とに加え（図３参照）、通常アプリ部１８をさらに含む構成である。通常アプリ部１８は、例えばＣＰＵ２０等のプロセッサによって実行されるアプリケーションであり、ＣＰＵ２０の機能的な処理部として構成される。例えば、端末１０が監視カメラに適用された場合、通常アプリ部１８は、カメラアプリケーションとして、撮像、画像処理、画像認識処理、記録等の各処理を行う。

図６は、延命モード時の端末１０の構成例を示すブロック図である。

ここで、延命モードとは、端末１０のノイズ源１５から取得された測定値を基に生成された検証データｖｄが、検証サーバ３０による検証結果として乱数性が無い場合、端末１０を新品等に交換する時期まで応急処置的に稼動させる動作モードである。本来、乱数性が無いと評価された端末１０から送信されるデータはセキュリティ上の脆弱性があるため、悪意ある第三者による攻撃等によって、ネットワークＮＷ上に漏洩するおそれ又は盗聴されるおそれがある。従って、即座に端末１０の稼動を停止させて交換することが望ましい。しかし、例えば端末１０の設置場所が遠方で現場に行くまでの距離が長かったり、多く時間を要する場合、また、端末１０の動作をすぐに停止できない監視カメラであった場合、すぐに対応できないので、本実施の形態では、交換の準備ができるまで端末１０を延命的に稼動させておく。

延命モードでは、端末１０は、通信Ｉ／Ｆ１４と、通常アプリ部１８と、暗号・復号モジュール部１６と、擬似乱数生成部１７とに加え、セキュアエリア１３を更に含む構成である。既に、物理乱数生成部１１で生成した乱数には乱数性が無いと評価されているので、延命モードでは、物理乱数生成部１１及びノイズ源１５は使用されない。その代わりに、端末１０は、検証サーバ３０が生成したシードを受信し、セキュアエリア１３に保存しておき、このシードを用いて共通鍵を生成することで、延命モード時における端末１０と検証サーバ３０との間のデータ通信時におけるセキュリティを担保する。

次に、上述した本実施の形態の乱数性検証システム５の動作を説明する。

図７は、テストモード時に検証結果がＯＫとなる場合の動作手順の一例を示すシーケンス図である。

テストモードは、例えば端末１０と検証サーバ３０との間で行われ、具体的には、端末１０により生成される検証データ（つまり、乱数）に乱数性が認められるかどうかが検証サーバ３０によって検証される処理（テスト）が行われる動作モードである。テストモードは、所定の期間（例えば１日）毎に実行される。端末１０は、セキュアエリア１３に保存された（つまり、出荷前に予め乱数性が認められた）第１のシードの一例としてのシードｓｄ１を基に共通鍵Ｋｐを生成し（Ｔ１）、ＳＳＬネゴシエーションを行い（Ｔ２）、検証サーバ３０との間で共通鍵Ｋｐを共有する。

検証サーバ３０は、所定のタイミング（例えば周期的なタイミング、又は検証サーバ３０からの検証データの乱数性の検証リクエストがあったタイミング）において、端末１０に対し、検証データを要求する（Ｔ３）。端末１０は、この要求に応じ、ノイズ源１５で発生したランダムな測定値から検証データｖｄを生成する（Ｔ４）。端末１０は、共通鍵Ｋｐで検証データｖｄを暗号化し、検証サーバ３０に送信する（Ｔ５）。

検証サーバ３０は、検証データｖｄを受信すると、検証を行い、検証結果（判定結果）を得る（Ｔ６）。検証サーバ３０は、成功（ＯＫ）と判定された検証結果を端末１０に送信する（Ｔ７）。なお、検証結果が失敗（ＮＧ）と判定された場合も、検証サーバ３０は、同様に検証結果を端末１０に送信する。また、出荷前に検証結果がＮＧと判定された場合、端末１０の出荷は行われない。

端末１０は、この検証結果の受信に応じて、次回のテストモード時で共通鍵Ｋｐを生成するために、ノイズ源１５から取得した複数の測定値を基にシードｓｄ２を生成し、既に保存されているシードｓｄ１をシードｓｄ２に更新してセキュアエリア１３に保存する（Ｔ８）。この後、端末１０は、テストモードから通常モードに移行する。なお、端末１０は、検証サーバ３０から送信された検証結果を受信した時点で、テストモードから通常モードに移行してもよい。通常モードでは、端末１０は、テストモード時に乱数性がある（言い換えると、検証成功）と判定されたノイズ源１５から取得した複数の測定値を基にシードを生成し、このシードから生成した共通鍵Ｋｐを用いて、カメラ（図示略）もしくはアプリサーバ５０等の通信相手の機器との間の無線通信において、送信するデータを暗号化したり、受信したデータを復号したりする。

図７のシーケンスにより、検証サーバ３０において検証が行われる度に、端末１０により生成された検証データ（つまり、乱数）に乱数性が認められると、端末１０は、セキュアエリア１３内に保存しているシードを変更（つまり、更新）することができる。従って、端末１０は、ＳＳＬネゴシエーションにおいて、悪意ある第三者から類推されない安全な共通鍵Ｋｐを生成することで、検証で扱う検証データのセキュリティを向上でき、毎回安全にテストモードを実施することができる。

図８は、テストモード時に検証結果がＮＧとなる場合の第１の動作手順の一例を示すシーケンス図である。

手順Ｔ１〜Ｔ６までの動作は、図７に示す通常モード時の手順Ｔ１〜Ｔ６までの動作と同じであるため、説明は省略する。図８において、検証結果がＮＧと判定された場合、検証サーバ３０は、端末１０を延命モードで動作させるための指示を検証結果に含めて生成する。検証サーバ３０は、自装置内のノイズ源３５で発生した値を基にシードｓｄ２ａを生成する（Ｔ６Ａ）。なお、ここでは、検証サーバ３０は、検証結果がＮＧと判定された場合にシードｓｄ２ａを生成したが、予め任意のタイミングで生成して自装置内のセキュアメモリ（図示略）に保存しておき、検証結果がＮＧと判定された場合に同セキュアメモリから読み出してもよい。これにより、検証サーバ３０は、シードを速やかに端末１０に送信できる。なお、検証サーバ３０により生成されるシードは乱数性が認められるとする。検証サーバ３０は、シードｓｄ２ａを共通鍵Ｋｐで暗号化し、検証結果と共に端末１０に送信する（Ｔ７Ａ）。

端末１０は、検証サーバ３０からシードｓｄ２ａを含む検証結果の受信に応じて、既に保存されているシードｓｄ１をシードｓｄ２ａに更新してセキュアエリア１３に保存する（Ｔ８Ａ）。この後、端末１０は、検証サーバ３０からの検証結果に基づいて、テストモードから延命モードに移行する。なお、端末１０は、検証サーバ３０から送信されたシードｓｄ２ａを含む検証結果を受信した時点で、テストモードから延命モードに移行してもよい。端末１０は、検証サーバ３０での検証結果がＮＧと判定されたので、端末１０の延命措置の一例として、交換されるまでの期間（例えば２〜３日）の延命モードで、検証サーバ３０が生成したシードｓｄ２ａを基に生成した共通鍵Ｋｐを用いて、カメラ（図示略）もしくはアプリサーバ５０等の通信相手の機器との間の無線通信において、通常モード時と同様に、送信するデータを暗号化したり、受信したデータを復号したりする。

図９は、テストモード時において検証結果がＮＧとなる場合の第２の動作手順の一例を示すシーケンス図である。

手順Ｔ１Ａ〜Ｔ６までの動作は、図７に示す通常モード時の手順Ｔ１〜Ｔ６とほぼ同じであるため、同一の内容についての説明は簡略化又は省略し、異なる内容について説明する。手順Ｔ１Ａでは、端末１０は、セキュアエリア１３に保存されたシードｓｄ１を基に共通鍵Ｋｐを生成する。一方、端末１０の物理乱数生成部１１は、共通鍵Ｋｐの生成タイミングとは別のタイミング（例えば、出荷前のテストモード時、もしくは実際の運用中における前回のテストモード時）にノイズ源１５で発生したランダムな測定値を基にシードを生成し、セキュアエリア１３に蓄積している。図９では、例えばセキュアエリア１３に３つのシードｓｄ１，ｓｄ２，ｓｄ３が保存され、これらのシードｓｄ１，ｓｄ２，ｓｄ３はいずれもテストモード時に乱数性が認められたものである。ここで、シードｓｄ１，ｓｄ２，ｓｄ３は、別々のファイルとしてセキュアエリア１３に保存されてもよいし、また、シードｓｄ１，ｓｄ２，ｓｄ３が連結したデータ列を含む１ファイルとして、セキュアエリア１３に保存されてもよい。後者の場合には、１ファイルのどこからどこまでがシードｓｄ１，ｓｄ２，ｓｄ３であるかを示す管理情報も併せてセキュアエリア１３内に保存されることが好ましい。

また、端末１０がセキュアエリア１３に蓄積しているシードｓｄ１，ｓｄ２，ｓｄ３の数は３つに限定されるものではなく、あくまで一例である。そして、セキュアエリア１３に蓄積しているシードの数は、例えば延命モードで端末１０を延命したい期間、又は、端末１０がカメラ（図示略）もしくはアプリサーバ５０等の通信相手の機器へのアクセスの頻度に応じて、適宜設定されてよい。

手順Ｔ６で検証結果がＮＧである場合、検証サーバ３０は、端末１０を延命モードで動作させるための指示を含む、ＮＧと判定された検証結果を端末１０に送信する（Ｔ７Ａ）。端末１０は、検証サーバ３０からの検証結果の受信に応じて、今回の検証に用いたシードｓｄ１をセキュアエリア１３から削除する（Ｔ８Ｂ）。セキュアエリア１３には、シードｓｄ２とシードｓｄ３が保存されたままである。ここで、シードｓｄ１，ｓｄ２，ｓｄ３が別々のファイルとしてセキュアエリア１３に保存されている場合、シードｓｄ１のファイルだけが削除され、シードｓｄ２，ｓｄ３の各ファイルは残っている。また、シードｓｄ１，ｓｄ２，ｓｄ３が、連結したデータ列を含む１ファイルとして、セキュアエリア１３に保存されている場合、シードｓｄ１の部分が削除されて短くなったデータ列を含む１ファイルがセキュアエリア１３に保存されたままである。

また、端末１０は、検証サーバ３０からの検証結果に基づいて、テストモードから延命モードに移行する。なお、端末１０は、検証サーバ３０から送信された検証結果を受信した時点で、テストモードから延命モードに移行してもよい。端末１０は、検証サーバ３０での検証結果がＮＧと判定されたので、端末１０の延命措置の一例として、交換されるまでの期間（例えば２〜３日）の延命モードで、セキュアエリア１３に保存されるｓｄ１以外のシード（例えばシードｓｄ２）を基に生成した共通鍵Ｋｐを用いて、カメラ（図示略）もしくはアプリサーバ５０等の通信相手の機器との間の無線通信において、通常モード時と同様に、送信するデータを暗号化したり、受信したデータを復号したりする。

図１０は、テストモード時において検証結果がＮＧとなる場合の第３の動作手順の一例を示すシーケンス図である。

端末１０は、複数のノイズ源１５を有する。ここでは、２つのノイズ源１５Ａ，１５Ｂが存在する。手順Ｔ１から開始されるテストモードより以前の通常モード時では、端末１０は、ノイズ源１５Ａで発生した複数の測定値を用いてシードｓｄ１を生成し、更に、このシードｓｄ１を用いて共通鍵Ｋｐを生成していた。手順Ｔ１〜Ｔ７Ａは、図７、図９に示す手順Ｔ１もしくはＴ１Ａ〜Ｔ７もしくはＴ７Ａと同じであるため、同一の内容についての説明は簡略化又は省略し、異なる内容について説明する。ただし手順Ｔ４では、端末１０は、ノイズ源１５Ａで生成した値を基に検証データｖｄ１を生成する。

端末１０は、手順Ｔ７Ａで受信した検証結果がＮＧである場合、その検証結果の受信に応じて、シード又は検証データの生成に用いるノイズ源をノイズ源１５Ａからノイズ源１５Ｂに切り替え、手順Ｔ４と同様、ノイズ源１５Ｂで発生した複数の測定値を基に検証データｖｄ２を生成する（Ｔ１１）。ここでは、２つのノイズ源１５Ａ，１５Ｂを切り替える場合を示したが、３つ以上のノイズ源のうち少なくとも１つのノイズ源を用いて検証データを生成してもよい。端末１０は、生成した検証データｖｄ２を検証サーバ３０に送信する（Ｔ１２）。

検証サーバ３０は、検証データｖｄ２を受信すると、手順Ｔ６と同様、検証を行い、検証結果（判定結果）を得る（Ｔ１３）。検証サーバ３０は、ＯＫと判定された検証結果を端末１０に送信する（Ｔ１４）。なお、検証結果がＮＧと判定された場合も、検証サーバ３０は、同様に検証結果を端末１０に送信する。

端末１０は、ＯＫと判定された検証結果の受信に応じて、例えば通常モード時あるいは次回のテストモード時で共通鍵Ｋｐを生成するために、ノイズ源１５Ｂで発生した複数の測定値を基にシードｓｄ１１を生成し、既に保存されているシードｓｄ１をシードｓｄ１１に更新してセキュアエリア１３に保存する（Ｔ１５）。この後、端末１０は、テストモードから通常モードに移行する。なお、端末１０は、手順Ｔ１４において検証サーバ３０から送信された検証結果を受信した時点で、テストモードから通常モードに移行してもよい。通常モードでは、端末１０は、テストモード時に乱数性がある（言い換えると、検証成功）と判定されたノイズ源１５Ｂから取得した複数の測定値を基にシードを生成し、このシードから生成した共通鍵Ｋｐを用いて、カメラ（図示略）もしくはアプリサーバ５０等の通信相手の機器との間の無線通信において、送信するデータを暗号化したり、受信したデータを復号したりする。

なお、端末１０は、テストモード時に手順Ｔ１３でＮＧと判定された検証結果を受信した場合、３番目のノイズ源がある場合、ノイズ源を切り替えて、同様の動作を繰り返すことも可能である。また、３番目のノイズ源が無い場合、端末１０は、最終的な手段として、図８を参照して前述した延命モードで動作するために、検証サーバ３０が生成したシードｓｄ２ａを受信し、セキュアエリア１３に保存する。

図１１は、テストモード時において検証結果がＮＧとなる場合の第４の動作手順の一例を示すシーケンス図である。

端末１０の物理乱数生成部１１は、複数種類の後処理を実行可能である。手順Ｔ１から開始されるテストモードより以前の通常モード時では、端末１０は、ノイズ源１５で発生した複数の測定値に対して後処理ｐ１を施してシードｓｄ１を生成し、更に、このシードｓｄ１を用いて共通鍵Ｋｐを生成していた。手順Ｔ１〜Ｔ７Ａは、図７、図９に示す手順Ｔ１もしくはＴ１Ａ〜Ｔ７もしくはＴ７Ａと同じであるため、同一の内容についての説明は簡略化又は省略し、異なる内容について説明する。ただし、手順Ｔ４では、端末１０は、ノイズ源１５から取得した複数の測定値に対し、それぞれ乱数性を向上するための第１の後処理ｐ１を施して、検証データｖｄ２１を生成する。

端末１０は、手順Ｔ７ＡでＮＧと判定された検証結果を受信すると、ノイズ源１５から取得した複数の測定値に対し、それぞれ乱数性を向上するための第２の後処理ｐ２を施して、検証データｖｄ２２を生成する（Ｔ２１）。端末１０は、生成された検証データｖｄ２２を検証サーバ３０に送信する（Ｔ２２）。

検証サーバ３０は、検証データｖｄ２２に対し、検証を行い、検証結果を得る（Ｔ２３）。検証サーバ３０は、ＯＫと判定された検証結果を端末１０に送信する（Ｔ２４）。なお、検証結果がＮＧと判定された場合も、検証サーバ３０は、同様に検証結果を端末１０に送信する。

端末１０は、ＯＫと判定された検証結果の受信に応じて、例えば通常モード時あるいは次回のテストモード時で共通鍵Ｋｐを生成するために、ノイズ源１５で発生した複数の測定値に対して第２の後処理ｐ２を施してシードｓｄ２１を生成し、既に保存されているシードｓｄ１をシードｓｄ２１に更新してセキュアエリア１３に保存する（Ｔ２５）。この後、端末１０は、テストモードから通常モードに移行する。なお、端末１０は、手順Ｔ２４において検証サーバ３０から送信された検証結果を受信した時点で、テストモードから通常モードに移行してもよい。通常モードでは、端末１０は、テストモード時に乱数性がある（言い換えると、検証成功）と判定された検証データの生成方法としての第２の後処理ｐ２を用いて、ノイズ源１５で発生した複数の測定値に対して第２の後処理ｐ２を施して生成したシードｓｄを用いて共通鍵Ｋｐを生成し、この共通鍵Ｋｐを用いて、カメラ（図示略）もしくはアプリサーバ５０等の通信相手の機器との間の無線通信において、送信するデータを暗号化したり、受信したデータを復号したりする。

なお、端末１０は、テストモード時に手順Ｔ２３でＮＧと判定された検証結果を受信した場合、第３の後処理方法がある場合、第３の後処理方法に切り替えて、同様の動作を繰り返すことも可能である。また、第３の後処理方法が無い場合、端末１０は、最終的な手段として、図８を参照して前述した延命モードで動作するために、検証サーバ３０が生成したシードｓｄ２ａを受信し、セキュアエリア１３に保存する。

図１２及び図１３は、テストモードから通常モードへの移行の動作手順の一例を示すシーケンス図である。

手順Ｔ１〜手順Ｔ１５は、図１０に示した通り、テストモードにおいてノイズ源を切り替える場合の動作に対応する。図１０と同一の手順については、同一の符号を付すことで、その説明を省略する。このテストモードが終了すると、端末１０のセキュアエリア１３には、次回のテストモードで使用されるシードｓｄ１１が保存される。また、ノイズ源１５Ｂは検証済みとなり、テストモードが終了する。

端末１０は、テストモードが終了すると、通常モードを開始し、検証済みノイズ源１５Ｂからシードを生成して初期化し、擬似乱数生成部１７で共通鍵生成情報ＰＩとなる乱数を生成する（Ｔ５１）。端末１０は、アプリサーバ５０との間でＳＳＬネゴシエーションを行い（Ｔ５２）、共通鍵Ｋｐ１１を共有する。

この後、端末１０の通常アプリ部１８は、アプリサーバ５０とデータ送受信を行う（Ｔ５３）。通常アプリ部１８は、共通鍵Ｋｐ１１を用いて、アプリサーバ５０に送信するデータを暗号化し、また、アプリサーバ５０から受信したデータを復号する。

その後、端末１０は、所定のタイミングで再びテストモードを開始する。手順Ｔ６１〜手順Ｔ６８は、図７に示した通り、テストモードにおいて検証結果がＯＫである場合の動作を示す。図１３の手順Ｔ６１〜手順Ｔ６８は、それぞれ図７の手順Ｔ１〜Ｔ８と同じである。このテストモードが終了すると、端末１０のセキュアエリア１３には、検証サーバ３０で生成されたシードｓｄ１３が次回のテストモードで使用されるシードとして保存される。

端末１０は、通常モードを開始すると、検証済みノイズ源１５Ｂからシードを生成して初期化し、擬似乱数生成部１７で共通鍵生成情報ＰＩとなる乱数を生成する（Ｔ７１）。端末１０は、アプリサーバ５０との間でＳＳＬネゴシエーションを行い（Ｔ７２）、共通鍵Ｋｐ１４を共有する。

この後、端末１０の通常アプリ部１８は、アプリサーバ５０とデータ送受信を行う（Ｔ７３）。通常アプリ部１８は、共通鍵Ｋｐ１４を用いて、アプリサーバ５０に送信するデータを暗号化し、また、アプリサーバ５０から受信したデータを復号する。

図１４は、テストモードから延命モードへの移行の動作手順の一例を示すシーケンス図である。

手順Ｔ１〜手順Ｔ８は、図８に示した通り、テストモードにおいて検証サーバ３０がシードｓｄ２ａを生成する場合の動作に対応する。図８と同一の手順については、同一の符号を付すことで、その説明を省略する。

このテストモードが終了すると、端末１０のセキュアエリア１３には、検証サーバ３０が生成したシードｓｄ２ａが保存される。

端末１０は、延命モードを開始すると、セキュアエリア１３に保存されたシードｓｄ２ａを基に、擬似乱数生成部１７で共通鍵生成情報ＰＩとなる乱数を生成する（Ｔ８１）。端末１０は、アプリサーバ５０とＳＳＬネゴシエーションを行い（Ｔ８２）、共通鍵Ｋｐ１５を共有する。

この後、端末１０の通常アプリ部１８は、アプリサーバ５０とデータ送受信を行う（Ｔ８３）。通常アプリ部１８は、共通鍵Ｋｐ１５を用いて、アプリサーバ５０に送信するデータを暗号化し、また、アプリサーバ５０から受信したデータを復号する。

以上により、本実施の形態の乱数性検証システム５Ｂでは、端末１０と検証サーバ３０とがネットワークＮＷを介して通信可能に接続される。端末１０は、予め乱数性が認められたシードｓｄ１（第１のシードの一例）を保持するセキュアエリア１３を有し、このシードｓｄ１を用いて生成した共通鍵Ｋｐを検証サーバ３０との間で交換する（ＳＳＬネゴシエーション）。端末１０は、ＳＳＬネゴシエーション後、ノイズ源１５から複数の測定値を取得し、所定のタイミングにそれらの複数の測定値を用いて検証データｖｄとしての乱数を生成する。端末１０は、生成された検証データｖｄを共通鍵Ｋｐで暗号化して検証サーバ３０に送信する。検証サーバ３０は、端末１０により暗号化された検証データｖｄを共通鍵Ｋｐで復号して得られた検証データｖｄの乱数性を検証する。検証サーバ３０は、検証データｖｄの乱数性があると判断した場合に、検証データｖｄの乱数性を認める旨の検証結果を端末１０に送信する。端末１０は、この検証結果の受信に応じて、ノイズ源１５から複数の測定値を取得し、それらの複数の測定値を用いて新たなシードｓｄ２を生成し、セキュアエリア１３に保存されているシードｓｄ１をシードｓｄ２に更新してセキュアエリア１３に保存する。

これにより、乱数性検証システム５Ｂは、端末１０と、端末１０により生成された検証データｖｄ（乱数）の乱数性を検証する検証サーバ３０との間で安全に乱数のデータを送受信できる。また、乱数性検証システム５Ｂは、検証サーバ３０により乱数性が認められた旨の検証結果に基づいて、その検証結果が得られた時点の端末１０においてノイズ源１５から安全なシードを生成して更新することで、次回のテストモード時においても、安全なシードを送受信可能な安全なデータ通信路を端末１０と検証サーバ３０との間で確保でき、テストモード時におけるテストを毎回安全に実施できる。さらに、乱数性検証システム５Ｂは、テストモード後の通常モード時では、テストモード時に検証成功と判定された端末１０のノイズ源１５を用いて、端末１０が実際の運用時に通信相手の機器との間でデータ通信時に使用する共通鍵Ｋｐを生成できてＳＳＬネゴシエーションによってその共通鍵Ｋｐを交換できるので、通信相手の機器との間で安全にデータ通信を行うことを担保することができる。

また、検証サーバ３０は、検証データｖｄの乱数性が無いと判断した場合に、自装置のノイズ源３５から複数の測定値を取得し、それらの複数の測定値を用いてシードｓｄ２ａ（第２のシードの一例）を生成し、生成されたシードｓｄ２ａを共通鍵Ｋｐで暗号化して、検証データの乱数性を認めない旨の検証結果と共に端末１０に送信する。これにより、乱数性検証システム５Ｂでは、例えば端末１０の動作保証範囲を満たさない長期の使用によって端末１０に異常が見られる等の原因によって、たとえ端末１０が生成した検証データｖｄに乱数性が認められない場合でも、検証サーバ３０が応急処置的に乱数性のあるシードｓｄ２ａを生成できる。検証サーバ３０は、生成されたシードｓｄを端末１０に安全に送信できる。従って、端末１０は、乱数性が無いと評価されたノイズ源１５からシードを生成せずに、検証サーバ３０により生成されたシードｓｄ２ａを用いて共通鍵Ｋｐを生成して検証サーバ３０との間で共有することで、端末１０により保持される情報又はデータのセキュリティを確保できるため、新品への交換時期が来るまで端末１０を延命モードで使用できる。従って、端末１０を直ぐに交換しなくて済むように、応急的な処置が図れる。

また、検証サーバ３０は、検証データｖｄの乱数性が無いと判断した場合に、予め保持しているシードｓｄ２ａ（第２のシードの一例）を共通鍵Ｋｐで暗号化して、検証データの乱数性を認めない旨の検証結果と共に端末１０に送信する。端末１０は、セキュアエリア１３に保存されているシードｓｄ１（第１のシードの一例）を、検証サーバ３０により暗号化されたシードｓｄ２ａを共通鍵Ｋｐで復号して得られたシードｓｄ２ａに更新してセキュアエリア１３に保存する。これにより、乱数性検証システム５Ｂでは、例えば端末１０の動作保証範囲を満たさない長期の使用によって端末１０に異常が見られる等の原因によって、たとえ端末１０が生成した検証データｖｄに乱数性が認められない場合でも、検証サーバ３０が事前に生成して保持しておいたシードｓｄ２ａを端末１０に速やかにかつ安全に送信できる。従って、端末１０は、乱数性が無いと評価されたノイズ源１５からシードを生成せずに、検証サーバ３０により予め保持されているシードｓｄ２ａを用いて共通鍵Ｋｐを生成して検証サーバ３０との間で共有することで、端末１０により保持される情報又はデータのセキュリティを確保できるため、新品への交換時期が来るまで端末１０を延命モードで使用できる。従って、端末１０を直ぐに交換しなくて済むように、応急的な処置が速やかに図れる。

また、端末１０は、シードｓｄ１とシードｓｄ１とは異なる少なくとも１個のシード（例えばシードｓｄ２，ｓｄ３）とを含むシード群をセキュアエリア１３に予め保存する。端末１０は、シード群のうちいずれか１つのシード（例えばシードｓｄ１）を用いて生成した共通鍵Ｋｐを検証サーバ３０との間で交換する。端末１０は、検証データｖｄの乱数性を認めない旨の検証結果を検証サーバ３０から受信した場合、共通鍵Ｋｐの生成に用いたシードｓｄ１をセキュアエリア１３から削除する。端末１０は、乱数性が無いと評価されたノイズ源１５からの複数の測定値を用いて生成したシードｓｄ１を用いず、シード群の中からシードｓｄ１以外のいずれかのシード（例えばシードｓｄ２）を用いて新たな共通鍵Ｋｐを生成して検証サーバ３０との間で共有する。これにより、乱数性検証システム５Ｂでは、端末１０は、端末１０により保持される情報又はデータのセキュリティを確保できるため、新品への交換時期が来るまで端末１０を延命モードで使用できる。従って、端末１０を直ぐに交換しなくて済むように、応急的な処置が速やかに図れる。

また、端末１０は、複数のノイズ源１５Ａ，１５Ｂを有する。端末１０は、複数のノイズ源１５Ａ，１５Ｂのうち１つのノイズ源１５Ａ（第１のノイズ源の一例）から取得した複数の測定値を用いて検証データｖｄ１としての乱数を生成し、生成された検証データｖｄ１を共通鍵Ｋｐで暗号化して検証サーバ３０に送信する。端末１０は、検証サーバ３０から検証データｖｄ１の乱数性を認めない旨の検証結果を受信した場合、複数のノイズ源１５Ａ，１５Ｂのうちノイズ源１５Ａとは異なるノイズ源１５Ｂ（第２のノイズ源の一例）から取得した複数の測定値を用いて検証データｖｄ２としての乱数を生成する。端末１０は、生成された検証データｖｄ２を共通鍵Ｋｐで暗号化して検証サーバ３０に送信する。これにより、乱数性検証システム５Ｂは、端末１０が複数のノイズ源を有し、かついずれかのノイズ源から取得された複数の測定値に基づいて生成された検証データに乱数性が認められなかった場合、端末１０のノイズ源を他のノイズ源に切り替えさせることが可能となる。従って、端末１０は、乱数性が認められ得る検証データを生成でき、端末１０を継続して使用できる可能性を向上できる。

また、端末１０は、複数の測定値を用いて検証データｖｄの乱数性を向上するための後処理ｐ１，ｐ２を複数実行可能である。端末１０は、複数の後処理のうちの後処理ｐ１（第１の後処理の一例）を実行して生成した検証データｖｄ２１に対し、検証データｖｄ２１の乱数性を認めない旨の検証結果を受信した場合、後処理ｐ１とは異なる後処理ｐ２を実行して検証データｖｄ２２としての乱数を生成する。これにより、乱数性検証システム５Ｂは、端末１０により生成された検証データに乱数性が認められなかった場合、他の後処理に変更して実行することで、乱数性が認められ得る検証データを生成でき、端末１０を継続して使用できる可能性を向上できる。

また、端末１０が、ノイズ源１５から取得した複数の測定値を用いて検証データｖｄとしての乱数を生成するタイミング（所定のタイミング）は、例えば周期的なタイミングである。これにより、乱数性検証システム５Ｂは、定期的に端末１０で生成される検証データの乱数性の有無を検証サーバ３０において検証でき、端末１０により保持される情報又はデータのセキュリティを担保できる。特に、端末１０がＩｏＴ機器である場合、端末１０に対するセキュリティの脆弱性を改善できる。

また、端末１０が、ノイズ源１５から取得した複数の測定値を用いて検証データｖｄとしての乱数を生成するタイミング（所定のタイミング）は、例えば検証サーバ３０からのリクエストがあったタイミングである。これにより、乱数性検証システム５Ｂは、検証サーバ３０の要求に応じて、迅速に乱数性の検証（テスト）を行えるので、臨機応変に端末１０により保持される情報又はデータのセキュリティを担保できる。

また、端末１０は、セキュアエリア１３に保存された新たなシードｓｄ１１（言い換えると、更新されたシード）を用いて生成した共通鍵Ｋｐ１１（第２の共通鍵）をアプリサーバ５０（第２のサーバの一例）との間で交換する。端末１０は、共通鍵Ｋｐ１１で暗号化したデータをアプリサーバ５０との間で送受信する。これにより、端末１０とアプリサーバ５０との間で、データ通信を行う場合のセキュリティを向上でき、安全なデータ通信の担保が可能となる。

また、端末１０と検証サーバ３０とがセキュアな通信路（例えば図１Ａに示す有線Ｌ１）で接続された場合、端末１０は、ノイズ源１５から複数の測定値を取得して検証データｖｄとしての乱数を生成し、生成された検証データｖｄを検証サーバ３０に送信する。検証サーバ３０は、端末１０により生成された検証データｖｄの乱数性を検証する。検証サーバ３０は、検証データｖｄの乱数性があると判断した場合に、検証データｖｄの乱数性を認める旨の検証結果を端末１０に送信する。端末１０は、検証結果の受信に応じて、ノイズ源１５から複数の測定値を取得し、複数の測定値を用いて新たなシードｓｄを生成してセキュアエリア１３に更新して保存する。これにより、乱数性検証システム５Ａでは、例えば端末１０の工場出荷前等、端末１０と検証サーバ３０との間のデータ通信時に暗号化や復号の各処理を省くことができ、検証データである乱数の乱数性を簡単に検証できる。従って、実際の運用前、例えば工場出荷前に、セキュリティを確保できない端末を発見した場合、その出荷を停止できる。

以上、図面を参照しながら実施の形態について説明したが、本開示はかかる例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本開示の技術的範囲に属するものと了解される。また、発明の趣旨を逸脱しない範囲において、上述実施の形態における各構成要素を任意に組み合わせてもよい。

例えば、上述した本実施の形態では、検証データの検証結果かＮＧであった場合、端末１０は、ノイズ源１５を切り替えて検証データｖｄを生成するか、ノイズ源１５で発生したランダムな測定値に対し後処理を切り替えていた。端末１０は、これらの切り替えを組み合わせてもよい。つまり、端末１０は、ノイズ源１５の切り替えと、後処理の切り替えとを組み合わせて検証データを生成してもよい。これにより、端末１０は、検証データを多様な方法で生成することができ、検証結果がＮＧとなって、別の方法で検証データを生成することで、端末１０を交換しなければならない事態を軽減できる。

本開示は、端末により生成された乱数の乱数性を検証する検証サーバとの間で安全に乱数のデータを送受信し、検証サーバにより乱数性が認められた乱数を用いて端末が実際の運用時に通信相手の機器との間で安全にデータ通信を行うことを担保する乱数性検証システム及び乱数性検証方法として有用である。

５Ａ、５Ｂ…乱数性検証システム
１０…端末
１１、３３…物理乱数生成部
１２…テストクライアント部
１３…セキュアエリア
１４、３６…通信Ｉ／Ｆ
１５、３５…ノイズ源
１６、３４…暗号・復号モジュール部
１７…擬似乱数生成部
１８…通常アプリ部
２０、４０…ＣＰＵ
３０…検証サーバ
３１…検証部
３２…テストサーバ部
５０…アプリサーバ

Claims (10)

1. 端末と第１のサーバとが通信可能に接続された乱数性検証システムであって、
   前記端末は、
   予め乱数性が認められた第１のシードを保持するセキュアメモリ部を有し、前記第１のシードを用いて生成した共通鍵を前記第１のサーバとの間で交換し、
   複数の測定値を取得し、所定のタイミングに前記複数の測定値を用いて検証データとしての乱数を生成し、生成された前記検証データを前記共通鍵で暗号化して前記第１のサーバに送信し、
   前記第１のサーバは、
   前記端末により暗号化された前記検証データを前記共通鍵で復号して得られた前記検証データの乱数性を検証し、
   前記検証データの乱数性があると判断した場合に、前記検証データの乱数性を認める旨の検証結果を前記端末に送信し、
   前記端末は、
   前記検証結果の受信に応じて、複数の測定値を取得し、前記複数の測定値を用いて前記第１のシードを更新して前記セキュアメモリ部に保存する、
   乱数性検証システム。
2. 前記第１のサーバは、
   前記検証データの乱数性が無いと判断した場合に、複数の測定値を取得し、前記複数の測定値を用いて第２のシードを生成し、生成された前記第２のシードを前記共通鍵で暗号化して前記端末に送信し、
   前記端末は、
   前記第１のシードを、前記第１のサーバにより暗号化された前記第２のシードを前記共通鍵で復号して得られた前記第２のシードに更新して前記セキュアメモリ部に保存する、
   請求項１に記載の乱数性検証システム。
3. 前記第１のサーバは、
   前記検証データの乱数性が無いと判断した場合に、予め保持している第２のシードを前記共通鍵で暗号化して前記端末に送信し、
   前記端末は、
   前記第１のシードを、前記第１のサーバにより暗号化された前記第２のシードを前記共通鍵で復号して得られた前記第２のシードに更新して前記セキュアメモリ部に保存する、
   請求項１に記載の乱数性検証システム。
4. 前記端末は、
   前記第１のシードと前記第１のシードと異なる少なくとも１個のシードとを含むシード群を前記セキュアメモリ部に予め保存し、
   前記検証データの乱数性を認めない旨の検証結果を受信した場合、前記第１のシードを前記セキュアメモリ部から削除し、
   前記シード群の中から前記第１のシード以外のいずれかのシードを用いて新たな共通鍵を生成して前記第１のサーバとの間で交換する、
   請求項１に記載の乱数性検証システム。
5. 前記端末は、
   複数のノイズ源を有し、前記複数のノイズ源のうち第１のノイズ源から取得した複数の測定値を用いて前記検証データを生成し、生成された前記検証データを前記共通鍵で暗号化して前記第１のサーバに送信し、
   前記検証データの乱数性を認めない旨の検証結果を受信した場合、前記複数のノイズ源のうち前記第１のノイズ源とは異なる第２のノイズ源から取得した複数の測定値を用いて前記検証データを生成し、生成された前記検証データを前記共通鍵で暗号化して前記第１のサーバに送信する、
   請求項１に記載の乱数性検証システム。
6. 前記端末は、
   前記複数の測定値を用いて前記検証データの乱数性を向上するための後処理を複数実行可能であり、
   第１の後処理を実行して生成した前記検証データに対し、前記検証データの乱数性を認めない旨の検証結果を受信した場合、前記第１の後処理とは異なる第２の後処理を実行して前記検証データを生成する、
   請求項１に記載の乱数性検証システム。
7. 前記所定のタイミングは、周期的なタイミングである、
   請求項１〜６のうちいずれか一項に記載の乱数性検証システム。
8. 前記所定のタイミングは、前記第１のサーバからの前記検証データの乱数性の検証リクエストがあったタイミングである、
   請求項１〜６のうちいずれか一項に記載の乱数性検証システム。
9. 前記端末は、
   前記セキュアメモリ部に保存された、更新された前記第１のシードを用いて生成した第２の共通鍵を第２のサーバとの間で交換し、
   前記第２の共通鍵で暗号化したデータを、前記第２のサーバとの間で送受信する、
   請求項１〜８のうちいずれか一項に記載の乱数性検証システム。
10. 端末と第１のサーバとが通信可能に接続された乱数性検証システムを用いた乱数性検証方法であって、
    前記端末は、
    予め乱数性が認められた第１のシードを保持するセキュアメモリ部を有し、前記第１のシードを用いて生成した共通鍵を前記第１のサーバとの間で交換し、
    複数の測定値を取得し、所定のタイミングに前記複数の測定値を用いて検証データとしての乱数を生成し、生成された前記検証データを前記共通鍵で暗号化して前記第１のサーバに送信し、
    前記第１のサーバは、
    前記端末により暗号化された前記検証データを前記共通鍵で復号して得られた前記検証データの乱数性を検証し、
    前記検証データの乱数性があると判断した場合に、前記検証データの乱数性を認める旨の検証結果を前記端末に送信し、
    前記端末は、
    前記検証結果の受信に応じて、複数の測定値を取得し、前記複数の測定値を用いて前記第１のシードを更新して前記セキュアメモリ部に保存する、
    乱数性検証方法。