JP2019152961A - 検証端末、検証システム - Google Patents

Abstract

【課題】ランダム性の確保を自動車特有の視点から確保すると共に、自動車特有の限られたリソースでも対応可能な計算負荷で実現することができるデータ改竄防止手法を提供する。【解決手段】格納されている部分ブロックデータの承認を求める複数の承認端末を選択する承認選択部（１０１）と、格納されている部分ブロックデータに含まれるトランザクションが更新されると、更新されたトランザクション及び更新前の部分ブロックデータのハッシュ値を含めて、選択された承認端末に更新後の部分ブロックデータの承認を求める承認要求部（１０２）と、承認要求部（１０２）からの承認要求に応じて承認端末から返信される承認結果に基づいて部分ブロックデータの更新処理を実行する承認結果登録部（１０３）と、を設ける。【選択図】図６

Description

本開示は、時系列に沿って更新され追加されるブロックデータの正当性検証を行う検証端末、時系列に沿って更新され追加されるブロックデータの正当性検証を行う検証システムに関する。

サーバーに格納されているデータの保護や、データ保持者が善意の他者とデータを授受する際のデータ保護の観点から、データを暗号化することが行われている。一方、データ管理者やデータ保持者がデータを改竄することを防止するためには、データの暗号化は有効な手段とはならない。

データ管理者やデータ保持者がデータを改竄することを防止するための技術として、下記特許文献１に記載されているようにブロックチェーン技術を活用するものが提案されている。

特開２０１７−１２３６９２号公報

ブロックチェーン技術を用いたデータの改竄防止手法には、全員が巨大なデータを共有してデータの改竄を防止すること、マイナーがブロックチェーンの健全性を膨大なコンピューターリソースを活用して保証すること、その保証の報酬を受け取ることが前提となっている。

ところで、自動車に通信端末を搭載し、ネットワークを介して又は直接他の車やインフラ装置やサーバーと通信を行うコネクテッドカーが普及すると、膨大な台数の端末のセキュリティを確保する必要がある。このセキュリティ確保の一つの側面として、車載データの改竄防止が求められる。車載データとしては、車歴データやセンサー情報といったものが含まれる。悪意のあるユーザーは、例えば車歴データを改ざんして自動車を本来の価値よりも高く転売したり、センサー情報を改竄して他者の混乱を誘発したりといったことを行うことが想定されるため、車載データの改竄防止ニーズは高まるものと想定される。

しかしながら、従来のブロックチェーンの技術をそのまま適用しようとすると、車載のメモリやＣＰＵに制限があるため、膨大な計算負荷に対応することができない。また、報酬を渡すことを前提にすると、その資金源をどのようにするかといったことを含むビジネスモデルの構築に障壁がある。

そこで、従来のブロックチェーンの手法を全て流用するのではなく、ランダム性の確保を自動車特有の視点から確保すると共に、自動車特有の限られたリソースでも対応可能な計算負荷で実現することができるデータ改竄防止手法を提供することを目的とする。

本開示は、時系列に沿って更新され追加されるブロックデータの正当性検証を行う検証端末であって、時系列に沿って新しい方から一部の部分ブロックデータを格納する格納部（１０４）と、格納部に格納されている部分ブロックデータの承認を求める複数の承認端末を選択する承認選択部（１０１）と、格納部に格納されている部分ブロックデータに含まれるトランザクションが更新されると、更新されたトランザクション及び更新前の部分ブロックデータのハッシュ値を含めて、選択された承認端末に更新後の部分ブロックデータの承認を求める承認要求部（１０２）と、承認要求部からの承認要求に応じて承認端末から返信される承認結果に基づいて部分ブロックデータの更新処理を実行する承認結果登録部（１０３）と、を備える。

本開示では、格納部に時系列に沿って新しい方から一部の部分ブロックデータを格納するので、時系列に沿った全長のブロックデータを格納することに比較して格納するデータ量が少なくなり、検証端末における計算負荷が軽減される。ランダムに選択された承認端末が、部分ブロックデータの承認を実行するので、予め承認端末を予期することができず、格納されている部分ブロックデータの改竄を防止することができる。

本開示は、時系列に沿って更新され追加されるブロックデータの正当性検証を行う検証システムであって、時系列に沿った一部の部分ブロックデータが格納される検証端末と関連付けて、時系列に沿った全長のフルブロックデータを管理サーバーに格納し、検証端末から送信される部分ブロックデータの末端データを管理サーバーが受信し、受信した末端データと格納されているフルブロックデータとを照合して末端データの健全性を検証する。

検証端末の格納部に格納されている部分ブロックデータは、時系列に沿って新しい方から一部の長さしかないので、全長のブロックデータに比較して改竄に対する耐性が低い。そこで、検証端末から末端データの健全性を管理サーバーに問い合わせることで、部分ブロックデータの健全性を確保することができる。

尚、「課題を解決するための手段」及び「特許請求の範囲」に記載した括弧内の符号は、後述する「発明を実施するための形態」との対応関係を示すものであって、「課題を解決するための手段」及び「特許請求の範囲」が、後述する「発明を実施するための形態」に限定されることを示すものではない。

本開示によれば、ランダム性の確保を自動車特有の視点から確保すると共に、自動車特有の限られたリソースでも対応可能な計算負荷で実現することができるデータ改竄防止手法を提供することができる。

図１は、本実施形態の基本概念を説明するための図である。 図２は、本実施形態の基本概念を説明するための図である。 図３は、本実施形態の基本概念を説明するための図である。 図４は、本実施形態の基本概念を説明するための図である。 図５は、本実施形態の基本概念を説明するための図である。 図６は、本実施形態の検証端末としての自動運転車の機能的な構成を説明するための図である。 図７は、自動運転車の情報処理を説明するためのフローチャートである。 図８は、自動運転車の情報処理を説明するためのフローチャートである。 図９は、自動運転車の情報処理を説明するためのフローチャートである。 図１０は、自動運転車の情報処理を説明するためのフローチャートである。 図１１は、自動運転車の情報処理を説明するためのフローチャートである。 図１２は、ブロックデータの更新処理を説明するための図である。

以下、添付図面を参照しながら本実施形態について説明する。説明の理解を容易にするため、各図面において同一の構成要素に対しては可能な限り同一の符号を付して、重複する説明は省略する。

図１を参照しながら、本実施形態の基本概念を説明する。本実施形態は自動運転車に搭載される検証端末及び承認端末を例示しているが、本開示の技術的思想は全ての分散された情報端末のセキュリティ確保のために応用されうるものである。

図１に示されるように、各担当エリアにそれぞれの担当エリアを管理するためのサーバーとして、管理サーバーＦＯＧ００１，ＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５が設けられている。管理サーバーＦＯＧ００１，ＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５は、担当エリア内の自動運転車に格納されているブロックデータのマスターデータを格納している。マスターデータは、時系列に形成されるブロックデータにおいて、全長のフルブロックデータである。

各担当エリア内に存在する自動運転車は、自己の近隣の他の自動運転車に対して、自身が格納しているブロックデータの健全性の検証を求める。検証を求める他の自動運転車は、そもそも任意に入れ替わる周囲の自動運転車からランダムに選択されるので、高度にランダム性を確保することができる。

各自動運転車が格納しているブロックデータは、時系列に形成されるブロックデータにおいて、新しい方からの一部である部分ブロックデータである。部分ブロックデータのみを保持することで計算負荷は抑制される。上記したランダム性の確保により、データ改竄を防止することができるが、ブロックデータの特徴であるチェーンの長さによる改竄耐性を確保することは期待できない。特に、部分ブロックデータの末端を改竄される懸念があるので、エンジン始動時や停止時といったタイミングで、部分ブロックデータの健全性を検証することが好ましい。

近隣の他の自動運転車からの過半数の承認が得られれば、自身が格納している部分ブロックデータは健全であると判断し、そうでなければ不健全であると判断する。各自動運転車は、周囲の自動運転車との車車間通信で行われる承認プロセスで健全性が確かめられない場合に、管理サーバーに問い合わせを行うので、管理サーバーの負荷は低減されている。

図２に示されるように、概念的には、管理サーバーＦＯＧ００１，ＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５，ＦＯＧ００６，ＦＯＧ００７，ＦＯＧ００８，ＦＯＧ００９は、重複しないように担当エリアが設定されている。図２では、管理サーバーＦＯＧ００３の担当エリアに、自動運転車Ｔ０１１が存在している。管理サーバーＦＯＧ００４の担当エリアに、自動運転車Ｔ００２，Ｔ００３，Ｔ００７，Ｔ００８が存在している。管理サーバーＦＯＧ００５の担当エリアに、自動運転車Ｔ００１，Ｔ００４，Ｔ００５，Ｔ００６，Ｔ００９，Ｔ０１３が存在している。管理サーバーＦＯＧ００６の担当エリアに、自動運転車Ｔ０１２が存在している。

図２に示される状態での、各管理サーバーＦＯＧ００１，ＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５，ＦＯＧ００６，ＦＯＧ００７，ＦＯＧ００８，ＦＯＧ００９に格納されている自動運転車の情報を概念的に示したものが図３に示される対応図である。

管理サーバーＦＯＧ００１は、主たる担当エリアはＦＯＧ−００１であるが、ＦＯＧ−００１に隣接する、ＦＯＧ−００２，ＦＯＧ−００４，ＦＯＧ−００５も保存対象領域としている。従って、ＦＯＧ−００４に存在している自動運転車Ｔ００２，Ｔ００３，Ｔ００７，Ｔ００８のマスターデータと、ＦＯＧ−００５に存在している自動運転車Ｔ００１，Ｔ００４，Ｔ００５，Ｔ００６，Ｔ００９，Ｔ０１３のマスターデータと、を保存している。

管理サーバーＦＯＧ００２は、主たる担当エリアはＦＯＧ−００２であるが、ＦＯＧ−００２に隣接する、ＦＯＧ−００１，ＦＯＧ−００３，ＦＯＧ−００４，ＦＯＧ−００５，ＦＯＧ−００６も保存対象領域としている。従って、ＦＯＧ−００３に存在している自動運転車Ｔ０１１のマスターデータと、ＦＯＧ−００４に存在している自動運転車Ｔ００２，Ｔ００３，Ｔ００７，Ｔ００８のマスターデータと、ＦＯＧ−００５に存在している自動運転車Ｔ００１，Ｔ００４，Ｔ００５，Ｔ００６，Ｔ００９，Ｔ０１３のマスターデータと、ＦＯＧ−００６に存在している自動運転車Ｔ０１２のマスターデータと、を保存している。

管理サーバーＦＯＧ００３は、主たる担当エリアはＦＯＧ−００３であるが、ＦＯＧ−００３に隣接する、ＦＯＧ−００２，ＦＯＧ−００３，ＦＯＧ−００５，ＦＯＧ−００６も保存対象領域としている。従って、ＦＯＧ−００３に存在している自動運転車Ｔ０１１のマスターデータと、ＦＯＧ−００５に存在している自動運転車Ｔ００１，Ｔ００４，Ｔ００５，Ｔ００６，Ｔ００９，Ｔ０１３のマスターデータと、ＦＯＧ−００６に存在している自動運転車Ｔ０１２のマスターデータと、を保存している。

管理サーバーＦＯＧ００４は、主たる担当エリアはＦＯＧ−００４であるが、ＦＯＧ−００４に隣接する、ＦＯＧ−００１，ＦＯＧ−００２，ＦＯＧ−００５，ＦＯＧ−００７，ＦＯＧ−００８も保存対象領域としている。従って、ＦＯＧ−００４に存在している自動運転車Ｔ００２，Ｔ００３，Ｔ００７，Ｔ００８のマスターデータと、ＦＯＧ−００５に存在している自動運転車Ｔ００１，Ｔ００４，Ｔ００５，Ｔ００６，Ｔ００９，Ｔ０１３のマスターデータと、を保存している。

管理サーバーＦＯＧ００５は、主たる担当エリアはＦＯＧ−００５であるが、ＦＯＧ−００５に隣接する、ＦＯＧ−００１，ＦＯＧ−００２，ＦＯＧ−００３，ＦＯＧ−００４，ＦＯＧ−００５，ＦＯＧ−００６，ＦＯＧ−００７，ＦＯＧ−００８，ＦＯＧ−００９も保存対象領域としている。従って、ＦＯＧ−００３に存在している自動運転車Ｔ０１１のマスターデータと、ＦＯＧ−００４に存在している自動運転車Ｔ００２，Ｔ００３，Ｔ００７，Ｔ００８のマスターデータと、ＦＯＧ−００５に存在している自動運転車Ｔ００１，Ｔ００４，Ｔ００５，Ｔ００６，Ｔ００９，Ｔ０１３のマスターデータと、ＦＯＧ−００６に存在している自動運転車Ｔ０１２のマスターデータと、を保存している。

管理サーバーＦＯＧ００６は、主たる担当エリアはＦＯＧ−００６であるが、ＦＯＧ−００６に隣接する、ＦＯＧ−００２，ＦＯＧ−００３，ＦＯＧ−００５，ＦＯＧ−００６，ＦＯＧ−００８，ＦＯＧ−００９も保存対象領域としている。従って、ＦＯＧ−００３に存在している自動運転車Ｔ０１１のマスターデータと、ＦＯＧ−００５に存在している自動運転車Ｔ００１，Ｔ００４，Ｔ００５，Ｔ００６，Ｔ００９，Ｔ０１３のマスターデータと、ＦＯＧ−００６に存在している自動運転車Ｔ０１２のマスターデータと、を保存している。

管理サーバーＦＯＧ００７は、主たる担当エリアはＦＯＧ−００７であるが、ＦＯＧ−００７に隣接する、ＦＯＧ−００４，ＦＯＧ−００５，ＦＯＧ−００７，ＦＯＧ−００８も保存対象領域としている。従って、ＦＯＧ−００５に存在している自動運転車Ｔ００１，Ｔ００４，Ｔ００５，Ｔ００６，Ｔ００９，Ｔ０１３のマスターデータを保存している。

管理サーバーＦＯＧ００８は、主たる担当エリアはＦＯＧ−００８であるが、ＦＯＧ−００８に隣接する、ＦＯＧ−００４，ＦＯＧ−００５，ＦＯＧ−００６，ＦＯＧ−００７，ＦＯＧ−００８も保存対象領域としている。従って、ＦＯＧ−００４に存在している自動運転車Ｔ００２，Ｔ００３，Ｔ００７，Ｔ００８のマスターデータと、ＦＯＧ−００５に存在している自動運転車Ｔ００１，Ｔ００４，Ｔ００５，Ｔ００６，Ｔ００９，Ｔ０１３のマスターデータと、ＦＯＧ−００６に存在している自動運転車Ｔ０１２のマスターデータと、を保存している。

管理サーバーＦＯＧ００９は、主たる担当エリアはＦＯＧ−００９であるが、ＦＯＧ−００９に隣接する、ＦＯＧ−００５，ＦＯＧ−００６，ＦＯＧ−００８，ＦＯＧ−００９も保存対象領域としている。従って、ＦＯＧ−００５に存在している自動運転車Ｔ００１，Ｔ００４，Ｔ００５，Ｔ００６，Ｔ００９，Ｔ０１３のマスターデータと、ＦＯＧ−００６に存在している自動運転車Ｔ０１２のマスターデータと、を保存している。

図２に示されるように、自動運転車Ｔ０１０が領域ＦＯＧ−００５から領域ＦＯＧ−００６に移動すると、関連する管理サーバーの保持情報が更新される。領域ＦＯＧ−００５の情報を保持している管理サーバーは、管理サーバーＦＯＧ００１，ＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５，ＦＯＧ００６，ＦＯＧ００７，ＦＯＧ００８，ＦＯＧ００９である。領域ＦＯＧ−００５から自動運転車Ｔ０１０が退出するので、管理サーバーＦＯＧ００１，ＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５，ＦＯＧ００６，ＦＯＧ００７，ＦＯＧ００８，ＦＯＧ００９が保持する領域ＦＯＧ−００５に関する情報から、自動運転車Ｔ０１０に関する情報が消去される。

領域ＦＯＧ−００６の情報を保持している管理サーバーは、管理サーバーＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５，ＦＯＧ００６，ＦＯＧ００８，ＦＯＧ００９である。領域ＦＯＧ−００６に自動運転車Ｔ０１０が侵入するので、管理サーバーＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５，ＦＯＧ００６，ＦＯＧ００８，ＦＯＧ００９が保持する領域ＦＯＧ−００６に関する情報に、自動運転車Ｔ０１０に関する情報が書き込まれる。

このように更新された後の情報保持状態を図４に示す。図４に示されるように、自動運転車Ｔ０１０のマスターデータは、領域ＦＯＧ−００６に関連付けて保持されている。管理サーバーＦＯＧ００６に着目すると、自動運転車Ｔ０１０のマスターデータは、自動運転車Ｔ０１０が領域ＦＯＧ−００５から領域ＦＯＧ−００６に移動する前から後にかけて保持され続けている。このように隣接領域を担当する管理サーバーと情報を共有し、対象となる移動体が移動するにあわせてハンドオーバーしていくことで、途切れずに管理することが加納となる。

図５に、各端末として管理される自動運転車のマスターデータの一例を示す。図５に示されるように、マスターデータとしては、車歴情報、支払い履歴情報、ドライバー情報、マップ情報、開発履歴情報、承認履歴情報が含まれている。車歴情報としては、事故履歴、故障履歴、充放電履歴といった情報が含まれる。支払い履歴情報としては、高速料金、物品購入といった情報が含まれる。ドライバー情報としては、シャアカーであるか否かや、保険の加入有無に関する情報が含まれる。承認履歴情報としては、タイムスタンプ、ハッシュ値といった情報が含まれる。

続いて、図６を参照しながら、自動運転車に搭載される検証端末及び承認端末の機能的な構成について説明する。自動運転車Ｔ００１には、検証端末１０及び承認端末２０が搭載されている。自動運転車Ｔ００２にも、検証端末１０及び承認端末２０が搭載されている。検証端末１０及び承認端末２０は、管理サーバーＦＯＧ００１と相互に情報通信可能なように構成されている。検証端末１０及び承認端末２０は、管理サーバーＦＯＧ００１のみならず、他の管理サーバーとも情報通信可能なように構成されている。

検証端末１０及び承認端末２０は、ハードウェア的な構成要素として、ＣＰＵといった演算部、ＲＡＭやＲＯＭといった記憶部、データの授受を行うためのインターフェイス部を備えるコンピューターとして構成されている。検証端末１０及び承認端末２０は、他の自動運転車に搭載されている同様の検証端末及び承認端末と相互に情報送受信可能なように構成されている。続いて、検証端末１０及び承認端末２０の機能的な構成要素について説明する。

検証端末１０は、承認選択部１０１と、承認要求部１０２と、承認結果登録部１０３と、ブロックデータ格納部１０４と、を備えている。ブロックデータ格納部１０４は、本開示の格納部に相当し、時系列に沿って新しい方から一部の部分ブロックデータを格納する部分である。ブロックデータ格納部１０４に格納されている部分ブロックデータの一例を図１２に示す。

図１２に示されるように、「＃（Ｎ−１）ブロック」として記載されている部分ブロックデータは、更新前の部分ブロックデータである。「＃（Ｎ−１）ブロック」の部分ブロックデータは、
・＃Ｎ−１ブロックのハッシュ値
・＃Ｎ−１ブロックの承認時のタイムスタンプ
・＃Ｎ−２ブロックのハッシュ値（＃Ｎ−２ブロックは、＃Ｎ−１ブロックの１つ前）
・＃Ｎ−１ブロックのトランザクションのマークルルート
・＃Ｎ−１ブロックのトランザクション発生時のタイムスタンプ
・＃Ｎ−１ブロックのトランザクション
・＃Ｎ−１ブロックの承認者のハッシュ値
・＃Ｎ−１ブロックの承認者アドレスのハッシュ値
を含んでいる。

図６に戻って、検証端末１０の説明を続ける。承認選択部１０１は、ブロックデータ格納部１０４に格納されている部分ブロックデータの承認を求める複数の承認端末を選択する部分である。

承認要求部１０２は、ブロックデータ格納部１０４に格納されている部分ブロックデータに含まれるトランザクションが更新されると、更新されたトランザクション及び更新前の部分ブロックデータのハッシュ値を含めて、選択された承認端末に更新後の部分ブロックデータの承認を求める部分である。図１２に示される例に基づいて説明すると、承認要求部１０２は、次の情報を含めて他の自動運転車に搭載されている承認端末２０に承認を求める情報を送信する。
・＃Ｎ−１ブロックの部分ブロックデータ
・＃Ｎブロックのトランザクション発生時のタイムスタンプ
・＃Ｎ−１ブロックのトランザクション

図６に戻って、検証端末１０の説明を続ける。承認結果登録部１０３は、承認要求部１０２からの承認要求に応じて承認端末から返信される承認結果に基づいて部分ブロックデータの更新処理を実行する部分である。図１２に示される例に基づいて説明すると、承認結果登録部１０３は、他の自動運転車に搭載されている承認端末２０からの承認が過半数を超えると、次の情報を含む「＃Ｎブロック」の部分ブロックデータを生成し、ブロックデータ格納部１０４に格納する。
・＃Ｎブロックのハッシュ値
・＃Ｎブロックの承認時のタイムスタンプ
・＃Ｎ−１ブロックのハッシュ値（＃Ｎ−１ブロックは、＃Ｎブロックの１つ前）
・＃Ｎブロックのトランザクションのマークルルート
・＃Ｎブロックのトランザクション発生時のタイムスタンプ
・＃Ｎブロックのトランザクション
・＃Ｎブロックの承認者のハッシュ値
・＃Ｎブロックの承認者アドレスのハッシュ値

上記したように、本実施形態の検証端末１０は、時系列に沿って更新され追加されるブロックデータの正当性検証を行う検証端末であって、時系列に沿って新しい方から一部の部分ブロックデータを格納する格納部としてのブロックデータ格納部１０４と、ブロックデータ格納部１０４に格納されている部分ブロックデータの承認を求める複数の承認端末２０を選択する承認選択部１０１と、ブロックデータ格納部１０４に格納されている部分ブロックデータに含まれるトランザクションが更新されると、更新されたトランザクション及び更新前の部分ブロックデータのハッシュ値を含めて、選択された承認端末２０に更新後の部分ブロックデータの承認を求める承認要求部１０２と、承認要求部１０２からの承認要求に応じて承認端末から返信される承認結果に基づいて部分ブロックデータの更新処理を実行する承認結果登録部と、を備える。

本実施形態では、ブロックデータ格納部１０４に時系列に沿って新しい方から一部の部分ブロックデータを格納するので、時系列に沿った全長のブロックデータを格納することに比較して格納するデータ量が少なくなり、検証端末１０における計算負荷が軽減される。ランダムに選択された承認端末２０が、部分ブロックデータの承認を実行するので、予め承認端末を予期することができず、格納されている部分ブロックデータの改竄を防止することができる。

本実施形態において、承認選択部１０１は、自身の近隣に存在する複数の端末から承認端末２０を選択する。

検証端末１０が移動可能である場合、自身の近隣に存在する端末は変遷するので、変遷する端末の中から承認端末２０を選択することになり、承認端末２０のランダム性を確保することができる。

本実施形態において、承認結果登録部１０３は、過半数の承認が得られた場合に、更新されるトランザクションを含む新たな部分ブロックデータを更新追加する。

承認端末２０の過半数の承認をもって新たな部分ブロックデータを更新追加するので、検証端末１０が移動することに伴う承認端末２０のランダム性と併せて、承認プロセスの堅牢性を確保することができる。

本実施形態において、承認結果登録部１０３は、過半数の承認が得られない場合に、異常が発生したことを管理サーバーＦＯＧ００１に報知する。過半数の承認が得られない場合に管理サーバーＦＯＧ００１に報知するので、検証端末１０と管理サーバーＦＯＧ００１との間の通信頻度を低減することができる。

本実施形態において、承認結果登録部１０３は、所定のタイミングでブロックデータ格納部１０４に格納されている部分ブロックデータの末端データの健全性を管理サーバーＦＯＧ００１に問い合わせる。

検証端末１０のブロックデータ格納部１０４に格納されている部分ブロックデータは、時系列に沿って新しい方から一部の長さしかないので、全長のブロックデータに比較して改竄に対する耐性が低い。そこで、所定のタイミングで末端データの健全性を管理サーバーＦＯＧ００１に問い合わせることで、通信頻度の低減と部分ブロックデータの健全性確保とを両立させることができる。尚、所定のタイミングとしては、自動運転車Ｔ００１のエンジン始動時やエンジン停止時といったタイミングを含め、様々なタイミングが選択されうる。

本実施形態は、検証端末１０、承認端末２０、管理サーバーＦＯＧ００１を含む検証システムとして捉えることができる。この検証システムは、時系列に沿って更新され追加されるブロックデータの正当性検証を行う検証システムであって、時系列に沿った一部の部分ブロックデータが格納される検証端末１０と関連付けて、時系列に沿った全長のフルブロックデータを管理サーバーＦＯＧ００１に格納し、検証端末１０から送信される部分ブロックデータの末端データを管理サーバーＦＯＧ００１が受信し、受信した末端データと格納されているフルブロックデータとを照合して末端データの健全性を検証する。

検証端末１０のブロックデータ格納部１０４に格納されている部分ブロックデータは、時系列に沿って新しい方から一部の長さしかないので、全長のブロックデータに比較して改竄に対する耐性が低い。そこで、検証端末１０から末端データの健全性を管理サーバーＦＯＧ００１に問い合わせることで、部分ブロックデータの健全性を確保することができる。

図１から図５を参照しながら説明したように、管理サーバーＦＯＧ００１，ＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５，ＦＯＧ００６，ＦＯＧ００７，ＦＯＧ００８，ＦＯＧ００９は、担当エリアごとに設けられており、管理サーバーＦＯＧ００１，ＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５，ＦＯＧ００６，ＦＯＧ００７，ＦＯＧ００８，ＦＯＧ００９ごとに担当エリア内に存在する検証端末１０が格納する末端データの健全性を検証する。

担当エリアごとに管理サーバーＦＯＧ００１，ＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５，ＦＯＧ００６，ＦＯＧ００７，ＦＯＧ００８，ＦＯＧ００９を設けるので、個々の管理サーバーＦＯＧ００１，ＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５，ＦＯＧ００６，ＦＯＧ００７，ＦＯＧ００８，ＦＯＧ００９の計算負荷を低減することができる。

検証端末１０が異なる担当エリアに移動すると、移動した担当エリアに該当する管理サーバーＦＯＧ００１，ＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５，ＦＯＧ００６，ＦＯＧ００７，ＦＯＧ００８，ＦＯＧ００９にフルブロックデータが移管される。

検証端末１０の移動に応じて管理サーバーＦＯＧ００１，ＦＯＧ００２，ＦＯＧ００３，ＦＯＧ００４，ＦＯＧ００５，ＦＯＧ００６，ＦＯＧ００７，ＦＯＧ００８，ＦＯＧ００９が格納するフルブロックデータを移管するので、検証端末１０の移動に応じた検証を行うことができる。

本実施形態の承認端末２０は、機能的な構成要素として、承認受付部２０１と、承認実行部２０２と、承認結果登録部２０３と、承認結果格納部２０４と、を備えている。

承認受付部２０１は、他の自動運転車に搭載されている承認要求部１０２から送信される承認要求を受け付ける部分である。承認実行部２０２は、承認要求に基づいて、他の自動運転車に搭載されているブロックデータ格納部１０４に格納されている部分ブロックデータの健全性を検証する部分である。承認結果登録部２０３は、承認実行部２０２の承認結果を承認結果格納部２０４に登録するとともに、管理サーバーＦＯＧ００１に送信する部分である。

続いて、図７から図１１を参照しながら、検証端末１０、承認端末２０、管理サーバーＦＯＧ００１の動作について説明する。図７のステップＳ１０１では、プログラムのハッシュ値が確認済みか否かを確認する。プログラムの正当性を確認するためのステップである。プログラムのハッシュ値が確認済であればステップＳ１０２の処理に進み、プログラムのハッシュ値が確認済でなければステップＳ１０１の処理を繰り返す。

ステップＳ１０２では、承認選択部１０１は、承認端末選択処理を実行する。承認端末選択処理について、図８を参照しながら説明する。

図８のステップＳ１５１では、承認選択部１０１が、周囲の自動運転車や情報端末のＲＳＳＩ（Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒ）を取得する。ＲＳＳＩは、Ｗｉ−Ｆｉネットワークにおける受信信号強度を示すものである。ＲＳＳＩが大きいものを選択することで、近隣の端末を特定することができる。尚、近隣の端末を特定するという観点からは、ＧＰＳ情報を用いることもできる。

ステップＳ１５１に続くステップＳ１５２では、承認選択部１０１が、同種の端末を選択する。同種の端末としては、同種の自動運転車や同種の検証端末と一対になって搭載されている承認端末が選択される。

ステップＳ１５２に続くステップＳ１５３では、承認選択部１０１が、選択した端末のアドレスやハッシュ値を取得し、確認する。ステップＳ１５３に続くステップＳ１５４では、承認選択部１０１が、選択した端末の承認履歴を確認する。承認履歴があればステップＳ１５５の処理に進み、承認履歴がなければステップＳ１５６の処理に進む。

ステップＳ１５５では、承認選択部１０１が、過剰重複して承認端末として選択されている端末を排除する処理を実行する。何回も同じ端末を承認端末とすると、不正な改竄を許す余地が大きくなるためである。

ステップＳ１５４及びステップＳ１５５に続くステップＳ１５６では、承認選択部１０１が承認端末２０を抽出する。ステップＳ１５６の処理が終了すると、承認端末選択処理を終了し、図７のステップＳ１０３の処理に進む。

ステップＳ１０３では、承認要求部１０２が、選択された承認端末２０に承認要求を送信する。送信された承認要求は、承認端末２０の承認受付部２０１が受信する。承認要求を受信した承認端末２０においては、図１１に示される承認処理が行われる。

図１１のステップＳ３０１では、承認実行部２０２が、タイムスタンプの整合性を確認する。図１２に示す例によれば、＃Ｎ−１ブロックのトランザクション発生時のタイムスタンプと、＃Ｎブロックのトランザクション発生時のタイムスタンプとの整合性を確認する。時系列が逆転しているなどの不整合が発生していなければ、ステップＳ３０２の処理に進む。時系列が逆転しているなどの不整合が発生していれば、ステップＳ３０６の処理に進む。

ステップＳ３０２では、承認実行部２０２が、トランザクションの整合性を確認する。図１２に示す例によれば、＃Ｎ−１ブロックのトランザクションと、＃Ｎブロックのトランザクションとの整合性を確認する。トランザクションの整合性がとれていればステップＳ３０３の処理に進み、トランザクションの整合性がとれていなければステップＳ３０６の処理に進む。

ステップＳ３０３では、承認実行部２０２が、マークルルートの整合性を確認する。図１２に示す例によれば、＃Ｎ−１ブロックのトランザクションにおけるマークルルートと、＃Ｎブロックのトランザクションにおけるマークルルートとの整合性を確認する。マークルルートの整合性がとれていればステップＳ３０４の処理に進み、マークルルートの整合性がとれていなければステップＳ３０６の処理に進む。

ステップＳ３０４では、承認実行部２０２が、部分ブロックのハッシュ値を確認する。図１２に示す例によれば、＃Ｎ−１ブロックのハッシュ値が、承認結果格納部２０４に格納されている＃Ｎ−１ブロックのハッシュ値と同一であるかどうかを確認する。＃Ｎ−１ブロックのハッシュ値が格納済のハッシュ値と同一であればステップＳ３０５の処理に進み、＃Ｎ−１ブロックのハッシュ値が格納済のハッシュ値と同一なければステップＳ３０６の処理に進む。

ステップＳ３０５では、承認実行部２０２が承認要求に対して、承認許可の判断を行い、検証端末１０にその旨を送信する。ステップＳ３０６では、承認実行部２０２が承認要求に対して、承認不許可の判断を行い、検証端末１０及び管理サーバーＦＯＧ００１にその旨を送信する。

図７に戻って説明を続ける。ステップＳ１０４では、承認結果登録部１０３が承認結果を受信する。ステップＳ１０４に続くステップＳ１０５では、承認結果登録部１０３が、承認結果が正常を示すものであるか（承認要求が許可されたか）を確認する。承認結果が正常を示すものであればステップＳ１０６の処理に進み、承認結果が正常を示すものでなければステップＳ１０７の処理に進む。

ステップＳ１０６では、承認結果登録部１０３がデータ更新処理を実行する。データ更新処理については、図９を参照しながら説明する。

図９のステップＳ２０１では、承認結果登録部１０３が、承認者アドレスのハッシュ値を追加する。ステップＳ２０１に続くステップＳ２０２では、承認結果登録部１０３が、承認結果を送信した承認端末が最終承認者か否かを判断する。最終承認者か否かは、承認要求を送信した複数の承認端末から返信される承認結果が最後となっているか否かで判断する。最終承認者であればステップＳ２０３の処理に進み、最終承認者でなければステップＳ２０２の処理を続ける。

ステップＳ２０３では、承認結果登録部１０３が、＃Ｎトランザクションのマークルルートを計算する。ステップＳ２０３に続くステップＳ２０４では、承認結果登録部１０３が、最終承認者のハッシュ値を追加する。

ステップＳ２０４に続くステップＳ２０５では、承認結果登録部１０３が、＃Ｎブロックのハッシュ値を計算し、ブロックデータ格納部１０４に格納すると共に、承認を行った承認端末２０に送信する。ステップＳ２０５の処理が終了すると、図７に戻り、検証処理を終了する。

ステップＳ１０７では、承認結果登録部１０３が異常処理を実行する。異常処理については、図１０を参照しながら説明する。

図１０のステップＳ２５１では、承認結果登録部１０３が、管理サーバーＦＯＧ００１に異常を報知する。ステップＳ２５１に続くステップＳ２５２では、承認結果登録部１０３が、ブロックデータ格納部１０４に異常履歴を登録する。ステップＳ２５２の処理が終了すると、図７に戻り、検証処理を終了する。

以上、具体例を参照しつつ本実施形態について説明した。しかし、本開示はこれらの具体例に限定されるものではない。これら具体例に、当業者が適宜設計変更を加えたものも、本開示の特徴を備えている限り、本開示の範囲に包含される。前述した各具体例が備える各要素およびその配置、条件、形状などは、例示したものに限定されるわけではなく適宜変更することができる。前述した各具体例が備える各要素は、技術的な矛盾が生じない限り、適宜組み合わせを変えることができる。

１０１：承認選択部
１０２：承認要求部
１０３：承認結果登録部
１０４：ブロックデータ格納部

Claims (8)

1. 時系列に沿って更新され追加されるブロックデータの正当性検証を行う検証端末であって、
   時系列に沿って新しい方から一部の部分ブロックデータを格納する格納部（１０４）と、
   前記格納部に格納されている部分ブロックデータの承認を求める複数の承認端末を選択する承認選択部（１０１）と、
   前記格納部に格納されている部分ブロックデータに含まれるトランザクションが更新されると、更新されたトランザクション及び更新前の部分ブロックデータのハッシュ値を含めて、選択された前記承認端末に更新後の部分ブロックデータの承認を求める承認要求部（１０２）と、
   前記承認要求部からの承認要求に応じて前記承認端末から返信される承認結果に基づいて部分ブロックデータの更新処理を実行する承認結果登録部（１０３）と、を備える検証端末。
2. 請求項１に記載の検証端末であって、
   前記承認選択部は、自身の近隣に存在する複数の端末から前記承認端末を選択する、検証端末。
3. 請求項２に記載の検証端末であって、
   前記承認結果登録部は、過半数の承認が得られた場合に、更新されるトランザクションを含む新たな部分ブロックデータを更新追加する、検証端末。
4. 請求項３に記載の検証端末であって、
   前記承認結果登録部は、過半数の承認が得られない場合に、異常が発生したことを管理サーバーに報知する、検証端末。
5. 請求項１に記載の検証端末であって、
   前記承認結果登録部は、所定のタイミングで前記格納部に格納されている部分ブロックデータの末端データの健全性を管理サーバーに問い合わせる、検証端末。
6. 時系列に沿って更新され追加されるブロックデータの正当性検証を行う検証システムであって、
   時系列に沿った一部の部分ブロックデータが格納される検証端末と関連付けて、時系列に沿った全長のフルブロックデータを管理サーバーに格納し、
   前記検証端末から送信される前記部分ブロックデータの末端データを前記管理サーバーが受信し、
   受信した前記末端データと格納されている前記フルブロックデータとを照合して前記末端データの健全性を検証する、検証システム。
7. 請求項６に記載の検証システムであって、
   前記管理サーバーは、担当エリアごとに設けられており、
   前記管理サーバーごとに担当エリア内に存在する前記検証端末が格納する前記末端データの健全性を検証する、検証システム。
8. 請求項７に記載の検証システムであって、
   前記検証端末が異なる担当エリアに移動すると、移動した担当エリアに該当する前記管理サーバーに前記フルブロックデータが移管される、検証システム。

Images