JP2017011491A - 認証システム - Google Patents

Abstract

【課題】コンピュータの保守を行う保守装置の不正な利用を防止する。
【解決手段】管理サーバが、第一のコンピュータから送信された構成証明データに基づいて、第一のコンピュータのエンティティ認証を行い、第二のコンピュータに対応する更新ソフトウェアを含む第一のデータと、更新ソフトウェアに対応するダイジェストを含むデータに自己の電子署名を付加した第二のデータと、を第一のコンピュータに送信する。第一のコンピュータは、管理サーバから第一および第二のデータを取得し、第二のコンピュータに転送する。第二のコンピュータは、管理サーバに対応する公開鍵を用いて、第二のデータに含まれる電子署名を検証し、また、第二のデータに含まれるダイジェストを用いて、更新ソフトウェアを検証し、正当性が全て確認できた場合にソフトウェア更新を行う。
【選択図】図１

Description

本発明は、保守装置の不正な利用を防止する認証システムに関する。

近年、ソフトウェアの高度化にともない、携帯電話や車載コンピュータなどの組込み機器に、デバッグ機能や更新機能などの保守のための機能を搭載することが一般的になっている。デバッグ機能は、開発時に機器の動作を検証する目的や、故障した機器の解析を行うために使用される。また、更新機能は、不具合の修正や機能向上などのため、ソフトウェアやファームウェアを更新する際に使用される。

これらの保守機能は、一般の利用者は使用しない機能であるため、利用者がアクセスできないように制限がかけられている場合が多い。特に、車載コンピュータ（Engine Control Unit、以下ＥＣＵ）は、自動車の制御を受け持つという性質上、パラメータの安易な
変更が故障や事故につながる可能性がある。そのため、保守機能にアクセスするためには専用の機器（以下、保守装置と称する）を必要とし、一般の利用者が容易に触れることができない構造をとっている。

しかし、保守装置を悪意のある利用者が入手した場合、保守機能が不正に利用されるおそれがある。例えば、保守装置が、パーソナルコンピュータ上で動作するソフトウェアとして実装されている場合、不正にコピーしたソフトウェアを用いて、ＥＣＵにアクセスされてしまうおそれがある。
これを防ぐための技術として、例えば特許文献１に記載の発明がある。特許文献１に記載のシステムでは、保守装置が、管理サーバに対して自己が正当な装置であることを示し、管理サーバから証明を取得する。そして、当該証明をＥＣＵに送信し、ＥＣＵが更新の可否を判断する。このようにすることで、不正な保守装置の利用を防止することができる。

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

特許文献１に記載の発明によると、保守装置が正当なものであることを管理サーバが確認しない限り、保守機能が有効にならない。
しかし、保守装置が正当なものであっても、悪意のあるユーザが、改造を施した不正なソフトウェアを用いてＥＣＵの更新を行おうとした場合に、これを防止することができない。

すなわち、このような利用を防止するためには、保守装置に対する正当性の確認（エンティティ認証）と、ＥＣＵに送信するデータに対する正当性の確認（データ認証）の双方を実行するような認証システムを構築する必要がある。

本発明は上記の問題点を考慮してなされたものであり、コンピュータの保守を行う保守
装置の不正な利用を防止することを目的とする。

本発明の第一の形態に係る認証システムは、接続されたコンピュータのソフトウェア更新を制御する第一のコンピュータと、ソフトウェアを更新する対象である第二のコンピュータと、前記第二のコンピュータに適用される更新ソフトウェアを提供する管理サーバと、を含み、前記第二のコンピュータが、前記更新ソフトウェアの正当性を認証するシステムである。

第一のコンピュータは、第二のコンピュータの保守を行うための装置であり、例えば、パーソナルコンピュータと保守ソフトウェアの組み合わせであるが、専用のハードウェア等であってもよい。また、第二のコンピュータは、ソフトウェアの更新を行う対象となる装置であり、例えば、組込み機器や、車載コンピュータ（ＥＣＵ）などである。

本発明の第一の形態に係る認証システムは、より具体的には、前記管理サーバが、前記第一のコンピュータから送信された構成証明データに基づいて、前記第一のコンピュータのエンティティ認証を行い、前記第一のコンピュータが正当なものである場合に、前記第二のコンピュータに対応する更新ソフトウェアを含む第一のデータと、前記更新ソフトウェアに対応するダイジェストを含むデータに自己の電子署名を付加したデータである第二のデータと、を前記第一のコンピュータに送信する提供手段と、を有する。
また、前記第一のコンピュータが、自己の正当性を示すデータである構成証明データを取得し、前記管理サーバに送信する自己証明手段と、前記管理サーバから前記第一および第二のデータを取得し、前記第二のコンピュータに転送する転送手段と、を有する。
また、前記第二のコンピュータが、前記管理サーバに対応する公開鍵を用いて、前記第二のデータに含まれる電子署名を検証し、また、前記第二のデータに含まれるダイジェストを用いて、前記更新ソフトウェアを検証し、前記二種類の検証によって正当性が全て確認できた場合にソフトウェア更新を行う更新手段と、を有する。

本発明における第一のコンピュータは、管理サーバに対して、第二のコンピュータを更新するためのソフトウェアを要求する。この際、第一のコンピュータは、自己が正当なものであることを示すデータ（構成証明データ）を管理サーバに送信し、管理サーバがエンティティ認証を行う。エンティティ認証は、第一のコンピュータの正当性を確認できれば、どのような方法で行われてもよい。例えば、公開鍵暗号を利用して、第一のコンピュータが有するハードウェアやソフトウェアのハッシュを送信してもよい。
管理サーバは、第一のコンピュータが正当なものあると判断した場合に、第二のコンピュータを更新するためのソフトウェア（更新ソフトウェア）が含まれる第一のデータと、第一のデータを検証するための第二のデータを生成し、当該第一のデータと、第二のデータの二つを第一のコンピュータに送信する。
第二のデータとは、更新ソフトウェアに対応するダイジェストを含むデータに、管理サーバの電子署名を付加したデータである。ダイジェストとは、更新ソフトウェアの正当性を確認するための情報であり、例えば、更新ソフトウェアのハッシュ値などであるが、一方向であればこれに限られない。

第一のコンピュータに送信された二つのデータは、例えば、第一のコンピュータと第二のコンピュータを接続したタイミングで、第二のコンピュータへ転送される。

また、データを受信した第二のコンピュータは、まず、（１）管理サーバに対応する公開鍵を用いて、第二のデータに含まれる電子署名を検証し、（２）第二のデータに含まれるダイジェストを用いて、前記更新ソフトウェアを検証する。この二種類の検証により、第二のコンピュータは、更新ソフトウェアが管理サーバによって作成された正当なもので
あることを確認することができる。

かかる構成によると、第二のコンピュータが、更新ソフトウェアの正当性を確認することができる。また、更新ソフトウェアは、第一のコンピュータが正当なものでない限り生成されないため、エンティティおよびデータの正当性を共に担保することができる。

また、前記第一のコンピュータが有する自己証明手段は、自装置のプラットフォーム構成に対応するダイジェストを生成し、自己の電子署名を加えたデータを、構成証明データとして前記管理サーバに送信し、前記管理サーバは、前記電子署名およびダイジェストを検証することで、前記第一のコンピュータのエンティティ認証を行うことを特徴としてもよい。

構成証明データとは、第一のコンピュータが有するプラットフォームが正当なものであることを示すためのデータであり、例えば、ソフトウェアやハードウェアのハッシュ値などであるが、これに限られない。対象のソフトウェアは、例えば、保守を行うソフトウェアのみであってもよいし、オペレーティングシステムのライブラリやカーネル、ミドルウェア等を含んだものであってもよい。また、ディスク装置に記憶されたソフトウェア全てであってもよい。

このように構成すると、仮に攻撃者が正規の通信ソフトウェアのプロトコルを解析し、攻撃用の保守ソフトウェアを作成した場合であっても、管理サーバから保守用のデータを受け取ることができなくなる。また、構成証明データの生成対象を、通信ソフトウェアだけでなく、オペレーティングシステムのカーネルやライブラリまで含むようにすれば、正規の通信ソフトウェアを不正にコピーするケースにも対応することができる。すなわち、攻撃に用いるコンピュータのカーネルやライブラリなどが、正当なコンピュータと少しでも異なれば認証を得ることが出来ないため、不正を防止することができる。

また、前記第一のコンピュータが有する自己証明手段は、耐タンパ性デバイスによって実現されることを特徴としてもよい。

耐タンパ性デバイスとは、情報の外部への取り出しや、情報の改変に対する防御力を持ったデバイスである。耐タンパデバイスには、例えばＴＰＭ（Trusted Platform Module
）を用いることができる。ＴＰＭとは、ＴＣＧ(Trusted Computing Group)にて標準化さ
れた、耐タンパ性を持つセキュリティチップであり、秘密鍵の記憶、ハッシュの生成、電子署名の生成などを単体で行うことができる。ＴＰＭの内部で行われるハッシュや電子署名の生成には、外部から関与することができないため、データの改ざんや、不正な電子署名の生成を行うことができない。また、データや秘密鍵を物理的に取り出そうとすると自己破壊が起こるため、ハードウェアと切り離すこともできない。すなわち、第一のコンピュータが正当なものでない限り、正しい構成証明データを得ることができないため、管理サーバから更新プログラムを取得することもできなくなる。

また、前記第一のコンピュータは、前記第二のコンピュータに対してソフトウェアの更新を指示する更新制御手段をさらに有し、前記第二のデータは、前記ダイジェストと、前記第一のコンピュータに対応する公開鍵である第一の公開鍵と、に、前記管理サーバの電子署名を付加したデータであり、前記更新手段は、前記二種類の検証が共に成功した場合に、前記第二のデータに含まれる第一の公開鍵を用いて、前記第一のコンピュータとの秘匿通信に用いるセッション鍵を暗号化して前記第一のコンピュータに送信し、前記更新制御手段は、暗号化されたセッション鍵を自己の秘密鍵で復号することで、秘匿通信に用いるセッション鍵を取得し、前記第二のコンピュータとの秘匿通信を行うことを特徴としてもよい。

第一の公開鍵は、管理サーバによって認証された第一のコンピュータに対応するものである。すなわち、接続されている第一のコンピュータが不正なものである場合、第一のコンピュータはセッション鍵を取り出すことができず、以降の通信が不可能になる。
このように構成することで、第一のコンピュータと第二のコンピュータを接続したタイミングにおいても、第一のコンピュータのエンティティ認証を行うことができる。

また、前記セッション鍵は擬似乱数であることを特徴としてもよい。
擬似乱数は毎回変化するため、攻撃者が通信内容を傍受してもリプレイ攻撃を行うことができないという効果が得られる。

また、本発明の第二の形態にかかる認証システムは、接続されたコンピュータのソフトウェア更新を制御する第一のコンピュータと、ソフトウェアを更新する対象である第二のコンピュータと、を含み、前記第二のコンピュータが、前記第一のコンピュータおよび更新ソフトウェアを認証するシステムである。

具体的には、前記第一のコンピュータが、前記第二のコンピュータに対応する更新ソフトウェアを含む第一のデータと、前記更新ソフトウェアに対応する第一のダイジェストと、前記第一のコンピュータのプラットフォームに対応する第二のダイジェストと、を含むデータに、更新ソフトウェアの提供元の電子署名である第一の電子署名を付加したデータである第二のデータと、を取得し、前記第二のコンピュータに転送する転送手段と、自己の正当性を示すデータである構成証明データを取得し、前記第二のコンピュータに送信する自己証明手段と、前記第二のコンピュータが、前記更新ソフトウェアの提供元に対応する公開鍵を用いて、前記第二のデータに含まれる第一の電子署名を検証し、また、前記第二のデータに含まれる第一のダイジェストを用いて、前記更新ソフトウェアを検証し、また、前記第二のデータに含まれる第二のダイジェストを用いて前記構成証明データを検証し、前記三種類の検証によって正当性が全て確認できた場合にソフトウェア更新を行う更新手段を有することを特徴とする。

本発明の第二の形態に係る認証システムでは、更新ソフトウェアの提供を受ける際に、第一のコンピュータに対する認証を行わない。例えば、管理サーバによって事前に生成されたデータをオフラインで第一のコンピュータに投入するような形態である。
このような形態の場合、第二のコンピュータが、第一のコンピュータの真正性を確認する必要がある。そこで、本形態では、更新ソフトウェアの提供元が第二のデータを生成する際に、第一のコンピュータのプラットフォームに対応する第二のダイジェストを含ませる。また、第一のコンピュータが、構成証明データを第二のコンピュータに送信し、第二のコンピュータが、これらを突き合わせて第一のコンピュータの認証を行う。
かかる構成によると、更新ソフトウェアの提供元が想定している第一のコンピュータでしかソフトウェアの更新を行うことができなくなるため、第一の形態と同様に、セキュリティ性を確保することができる。

なお、本発明は、上記手段の少なくとも一部を含む認証システムとして特定することができる。また、前記認証システムが行う認証方法として特定することもできる。上記処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

本発明によれば、コンピュータの保守を行う保守装置の不正な利用を防止することができる。

第一の実施形態におけるシステム概要図である。 第一の実施形態に係る車両のシステム構成図である。 第一の実施形態に係る保守装置のシステム構成図である。 第一の実施形態に係る管理サーバのシステム構成図である。 管理サーバにて生成される更新パッケージの例である。 第一の実施形態における保守装置の処理フローチャートである。 第一の実施形態における管理サーバの処理フローチャートである。 第一の実施形態における車両の処理フローチャートである。 第二の実施形態における更新パッケージの例である。 第二の実施形態における保守装置の処理フローチャートである。 第二の実施形態における車両の処理フローチャートである。 第三の実施形態における、構成証明の対象範囲を説明する図である。

（第一の実施形態）
第一の実施形態における認証システムの概要について、図１を参照しながら説明する。第一の実施形態は、車両１０と、車両１０に搭載されたコンピュータ（ＥＣＵ）に対する保守を行うための保守装置２０と、管理サーバ３０からなる認証システムである。保守装置２０が本発明における第一のコンピュータであり、車両１０に搭載されたＥＣＵが本発明における第二のコンピュータである。

保守装置２０は、車両に搭載されたＥＣＵに対してデータ解析やプログラムの更新を行うためのソフトウェアが動作するパーソナルコンピュータである。当該ソフトウェアを、本実施形態では通信ソフトウェアと称する。
第一の実施形態における保守装置２０は、管理サーバ３０に対して、車両１０が有するＥＣＵを更新するためのソフトウェアを要求する。
この際、保守装置２０は、構成証明データを生成して、電子署名とともに管理サーバに送信する。構成証明データとは、コンピュータが有するソフトウェアの正当性を示すデータであり、本実施形態では、コンピュータが記憶しているソフトウェアに対応するハッシュ値である。管理サーバは、電子署名を検証することで、送信されたデータが正当なものであること（すなわち正当なコンピュータから送信され、かつ偽造されたものでないこと）を確認し、ハッシュ値が正しいかを検証することで、コンピュータに記憶されたソフトウェアが偽造または改ざんされたものでないことを確認する。

コンピュータ、およびコンピュータに記憶されたソフトウェアが正当なものであった場合、管理サーバは、更新パッケージを生成する。更新パッケージとは、車両１０が有するＥＣＵを更新するために必要なデータの集合である。更新パッケージは、保守装置２０を介して車両１０に転送され、これを受信したＥＣＵが、更新パッケージが正当なものであるか否かを判定し、正当性が確認できた場合にのみ、保守装置に対して許可通知を行い、保守作業を開始する。
このように構成することで、更新ソフトウェアと保守装置の双方が正当なものであることを担保することができる。具体的なデータの内容および処理方法については後述する。

<システム構成>
以上に説明した機能を実現するための実施形態の詳細について説明する。
第一の実施形態に係る認証システムの構成を、図２〜４を参照しながら説明する。図２は車両１０のシステム構成図、図３はコンピュータ２０のシステム構成図、図４は管理サーバ３０のシステム構成図である。

まず、車両１０について説明する。車両１０は、車両制御用のＥＣＵを複数搭載した自動車である。車両１０には、エンジン、パワートレイン、ブレーキ、車両制御など機能別に複数のＥＣＵが備わっている。各ＥＣＵは、車内ネットワークを通して保守装置２０と接続することによって、プログラムの更新やデータの解析などを行うことができるようになっている。なお、図２には、更新パッケージを取得し、その正当性を確認するための手段のみを図示し、ＥＣＵは図示していない。

通信部１１は、保守装置２０と通信を行う手段である。具体的には、保守装置２０から、更新パッケージを受信し、また、ソフトウェアの更新を行うためのコマンド（以下、保守コマンド）を受信する。自動車には、ＯＢＤ２と呼ばれる規格の通信ポートが装備されており、通信部１２は当該ポートを利用して保守装置２０との有線接続を行う。

センタ公開鍵記憶部１２は、管理サーバ３０に対応する公開鍵であるセンタ公開鍵を記憶する手段である。本システムを利用する全ての車両が、対応するセンタ公開鍵を記憶している。

パッケージ検証部１３は、保守装置２０によって転送された更新パッケージの正当性を検証する手段である。具体的には、更新パッケージに含まれる情報（電子署名やハッシュ）を検証することで、当該更新パッケージが、管理サーバ３０によって生成された真正なものであることを確認する。詳細な検証方法については後述する。
コマンド実行部１４は、保守装置２０から送信された保守コマンドを実行し、対象のＥＣＵに対して保守作業（例えばデータの解析やプログラムの更新など）を実行する手段である。
以上の手段は、演算処理装置（ＣＰＵ）と記憶装置（ＲＯＭ）を有する組込みコンピュータによって実現されてもよいし、専用に設計された電子回路によって実現されてもよい。

保守装置２０は、車両１０に搭載されたＥＣＵと通信を行うための通信ソフトウェアが動作する、汎用のパーソナルコンピュータである。
通信部２１は、前述したＯＢＤ２規格のコネクタを有する通信手段である。例えば、パーソナルコンピュータの拡張バスに装着されるインタフェースカードなどによって実現される。
通信部２２は、管理サーバ３０との通信を行う手段であり、移動体通信網やマルチチャネルアクセス無線を利用する通信モジュールなどによって実現される。管理サーバ３０との通信は、無線通信であっても有線通信であってもよいが、セキュアな通信路を用いることが好ましい。
制御部２３は、保守装置２０の制御を司る手段であり、例えば、車両１０に搭載されたＥＣＵに対する保守コマンドを生成および送信する機能や、管理サーバ３０から取得した更新パッケージを車両１０に転送する機能を実行する。
保守コマンドは、データ解析やソフトウェア更新を行うための命令であり、タッチパネルやキーボードといった入出力手段（不図示）を通して、利用者から受け付けた操作に基づいて生成される。

符号２００は、ＴＰＭによって保護された領域を表す。ＴＰＭとは、前述したように、コンピュータに内蔵され、暗号演算に関する各種の機能を有するワンチップモジュールである。当該モジュールは、コンピュータのメインボードに直接装着されている。

ＴＰＭ制御部２０１は、ＴＰＭが有する機能を制御するための手段である。本実施形態では、ソフトウェアの構成証明データの生成、および公開鍵暗号を用いた電子署名の生成を行う動作を制御する。また、ＴＰＭ制御部２０１は、保守装置２０に固有な秘密鍵（本
発明における第一の秘密鍵）を記憶している。第一の秘密鍵は、ソフトウェアおよびハードウェア的に保護された不揮発性メモリに記憶されており、電子署名の生成等に使用することはできるが、外部からのアクセス、物理的なメモリの取り出し等を行うことはできない。
構成証明生成部２０２は、構成証明データを生成する手段である。具体的には、保守装置２０にインストールされたソフトウェアのハッシュ値を、ＳＨＡ−１、ＳＨＡ−２５６などのアルゴリズムによって計算する手段である。当該計算したハッシュ値が、本発明における構成証明データである。構成証明データを生成する具体的な例については後述する。

保守装置２０では、以上の手段が、演算処理装置（ＣＰＵ）、記憶装置（ＲＯＭ）、ＴＰＭ、およびその他のハードウェアによって実現される。

管理サーバ３０は、保守装置２０と通信を行うサーバ装置である。
通信部３１は、通信部２２と同様のプロトコルを用いてデータを送受信する手段である。本実施形態では、保守装置２０から構成証明データを受信し、生成した更新パッケージを保守装置２０に送信する。
保守装置公開鍵記憶部３２は、保守装置２０に対応する公開鍵（以下、保守装置公開鍵。本発明における第一の公開鍵）を記憶する手段である。本実施形態では、保守装置公開鍵は、保守装置の個体ごとに異なり、管理サーバ３０は、保守装置ごとに公開鍵を全て記憶している。なお、保守装置公開鍵は、複数の保守装置の間で共通であってもよい。

構成証明検証部３３は、保守装置２０から送信された構成証明データの正当性を確認する手段である。具体的には、保守装置公開鍵を用いて、構成証明データに添付された電子署名を検証することで、その発信元を確認し、構成証明データを検証することで、保守装置２０に記憶されているソフトウェアが正当なものであることを確認する。
このため、構成証明検証部３３には、正当な保守装置が有するソフトウェアに対応するハッシュ値（以下、理想状態）が記憶されている。

パッケージ生成部３４は、車両に送信する更新パッケージを生成する手段である。
ここで、更新パッケージの構造について図５を参照しながら説明する。第一の実施形態では、更新パッケージは、第一のデータおよび第二のデータからなる。
第一のデータは、対象ＥＣＵのソフトウェアを更新するために用いられるバイナリファイル（本発明における更新ソフトウェア。以下、更新バイナリ）である。また、第二のデータは、更新パッケージを要求した保守装置２０に対応する保守装置公開鍵と、更新バイナリのハッシュ値に、管理サーバの電子署名を付加したデータである。更新バイナリのハッシュ値は、ＳＨＡ−１、ＳＨＡ−２５６などのアルゴリズムによって計算されたものを使用する。また、パッケージ生成部３４は、センタ秘密鍵記憶部３５に記憶された自己の秘密鍵を用いて電子署名を生成し、追加する。
なお、本実施形態では、Ｘ．５０９ｖ３による電子証明書を第二のデータとして使用する。当該規格は拡張領域を有し、更新バイナリのハッシュ値を格納することができるため、本実施形態に好適である。

センタ秘密鍵記憶部３５は、管理サーバ３０に固有な秘密鍵であるセンタ秘密鍵を記憶する手段である。
以上の構成は、演算処理装置（ＣＰＵ）と記憶装置（ＲＯＭ）を有するコンピュータによって構成されることが望ましいが、専用に設計されたハードウェアによって実現されてもよい。

<処理フロー>
次に、保守装置２０が管理サーバ３０に対して更新パッケージを要求する処理について説明する。図６は保守装置２０が行う処理のフローチャートであり、図７は管理サーバ３０が行う処理のフローチャートである。

保守装置２０が、対象のＥＣＵを更新する旨の指示をユーザから取得すると、図６に示した処理が開始される。
まず、ステップＳ１１で、ＴＰＭ制御部２０１が、構成証明生成部２０２を通して、自装置に対応する構成証明データを生成する。

本ステップで生成する構成証明データについて詳しく説明する。
ＴＰＭは、プラットフォーム構成の計測に用いるＰＣＲ（プラットフォーム構成レジスタ：Platform Configuration Register）と呼ばれるレジスタを有している。ＰＣＲには
、現在のプラットフォームに対するハッシュ値が、プラットフォームを起動するごとに書き込まれる。ＰＣＲはハードウェアによって保護されており、利用者が任意の値に書き換えることはできない。すなわち、ＰＣＲに記録されたハッシュ値と、正当なプラットフォーム構成に対応するハッシュ値とを比較することで、プラットフォームの改ざんを検知することができる。この、ＰＣＲに記録されたハッシュ値が本発明における構成証明データである。構成証明データには、ＴＰＭに記憶されている秘密鍵（第一の秘密鍵）を用いて電子署名が付加される。この動作は構成証明（Attestation）と呼ばれ、ＴＰＭが標準で
有している機能である。ＴＰＭによって生成され、電子署名が付加された構成証明データは、外部から手を加えることができないため、第三者がこれを検証することで、プラットフォームの正当性を確認することができる。
第一の実施形態では、検証を行う対象のプラットフォームとは、保守装置２０に記憶されている全てのソフトウェアを指す。すなわち、通信ソフトウェア、その他のアプリケーション、システムライブラリ、オペレーティングシステムのカーネル等を含む。

ステップＳ１１の処理によって、構成証明データおよび電子署名が生成されると、制御部２３は、当該データを、通信部２２を介して管理サーバ３０へ送信する（Ｓ１２）。この際、更新対象のＥＣＵを識別するための情報を同時に送信してもよい。

ここで、図７を参照して、管理サーバ３０が行う処理について説明する。管理サーバ３０は、通信部３１を通して構成証明データおよび電子署名を受信すると、保守装置２０に対応する公開鍵を、保守装置公開鍵記憶部３２から取得する（ステップＳ２１）。前述したように、保守装置公開鍵記憶部３２には、保守装置ごとに対応する公開鍵が記憶されており、受信した電子署名に対応する公開鍵を取得することができる。

そして、構成証明検証部３３が、構成証明データに添付された電子署名を検証する（ステップＳ２２）。具体的には、受信データに含まれる電子署名を、取得した公開鍵を用いて復号し、受信データから得られるハッシュ値と一致するかを確認する。電子署名の検証が成功すれば、受信した構成証明データが、対応する保守装置２０から送信されたものであり、改ざんされていないことが確認できる。電子署名の検証に失敗した場合、動作を終了する（Ｓ２２−Ｎｏ）。

続いて、構成証明データに含まれるハッシュ値（保守装置が有するソフトウェアのハッシュ値）が、正当な保守装置が有するソフトウェアに対応するハッシュ値（すなわち理想状態）と一致しているかを確認する（ステップＳ２３）。これらが一致すれば、保守装置２０に記憶されているソフトウェアが正当なものであることが確認できる（Ｓ２３−Ｙｅｓ）。ハッシュ値が一致しない場合、動作を終了する（Ｓ２３−Ｎｏ）。
すなわち、ステップＳ２２およびＳ２３の結果がともにＹｅｓであれば、保守装置２０が正当なものであることが確認できる。

コンピュータの正当性が確認されると、パッケージ生成部３４が、ＥＣＵを更新するための更新パッケージを生成する（ステップＳ２４）。
ステップＳ２４では、まず、保守装置へ送信する更新バイナリを選択し、第一のデータとする。次いで、当該更新バイナリに対応するハッシュ値を求める。次に、対象の保守装置２０に対応する保守装置公開鍵を取得し、ハッシュ値と公開鍵からなるデータを生成したうえで、自己の秘密鍵を用いて電子署名を生成して付加する。生成されるデータの構造は図５のようになる。第一の実施形態では、このようにして生成されたデータ全体が更新パッケージとなる。
生成された更新パッケージは、通信部３１を介して保守装置２０へ送信される（ステップＳ２５）。

保守装置２０が行う処理の説明（図６）に戻り、ステップＳ１３から説明を続ける。保守装置２０は、構成証明データを管理サーバ３０へ送信した後、更新パッケージの受信を試みる（ステップＳ１３）。このとき、一定時間以内に更新パッケージを受信した場合、当該更新パッケージを、通信部２１を通して車両１０へ転送する（ステップＳ１４）。管理サーバからの応答がタイムアウトした場合（Ｓ１３−Ｎｏ）、処理を終了させる。
ステップＳ１４が完了すると、車両による更新パッケージの検証が行われ、その間、保守装置２０は待ち状態となる。

ここで、図８を参照して、車両１０が行う処理について説明する。
車両１０が更新パッケージを受信すると、パッケージ検証部１３が、更新パッケージに含まれる電子署名を、センタ公開鍵記憶部１２に記憶されているセンタ公開鍵を用いて復号し、電子署名の検証を行う（ステップＳ３１）。検証が失敗した場合（Ｓ３２−Ｎｏ）、処理を終了させる。電子署名の検証が成功（Ｓ３２−Ｙｅｓ）した場合、更新パッケージに含まれる第二のデータが、管理サーバ３０から送信されたものであり、改ざんされていないことが確認できる。
次に、ステップＳ３３で更新バイナリのハッシュ値を取得し、第二のデータに含まれるハッシュ値と一致することを確認する。ここで、ハッシュ値が一致しない場合、更新バイナリのみが書き換えられている可能性が疑われるため、処理を終了させる（Ｓ３３−Ｎｏ）。ハッシュ値が一致した場合（Ｓ３３−Ｙｅｓ）、受信した「更新バイナリ」「保守装置公開鍵」が共に正当なものであることがわかる。

ステップＳ３４では、パッケージ検証部１３が、保守装置２０との通信に用いるセッション鍵を生成する。セッション鍵には、任意の数値や文字列を使用してもよいが、リプレイ攻撃を防ぐため、セッションごとに生成した擬似乱数を用いることが好ましい。
次にステップＳ３５で、生成したセッション鍵を、取得した保守装置公開鍵で暗号化し、保守装置２０に送信する。このようにすると、更新パッケージに含まれる保守装置公開鍵に対応する保守装置でしかメッセージが復号できなくなる。すなわち、管理サーバが認識している保守装置と、車両に接続されている保守装置が同一のものでない限り、通信を行うことができなくなるため、不正な保守装置を用いた保守作業を防止することができる。

保守装置２０が行う処理の説明（図６）に戻り、ステップＳ１５から説明を続ける。
ステップＳ１５では、車両１０から、暗号化されたセッション鍵を取得し、自己の秘密鍵でこれを復号することでセッション鍵を取得する。そして、ステップＳ１６で、保守作業を実行するためのコマンド（保守コマンド）を生成し、車両との通信を開始する。当該通信は、取得したセッション鍵を用いた秘匿通信である。
また、車両１０は、保守装置２０との接続が解除されるまで、当該保守装置から送信された保守コマンドを受け入れる状態となる。

<第一の実施形態の効果>
以上に示したように、本実施形態では、第一に、保守装置が構成証明データを管理サーバに送信し、管理サーバが保守装置を認証するという構成をとる。構成証明データの生成にはＴＰＭを利用するため、攻撃者は管理サーバに対して偽りの情報を送信することができない。すなわち、保守装置のエンティティ認証を行うことができる。
また、第二に、管理サーバから送信された更新パッケージを車両が検証し、正当性を確認する。これにより、更新パッケージの差し替えによる不正利用を防ぐことができる。
また、第三に、更新パッケージに保守装置公開鍵を含ませ、当該公開鍵を用いてセッション鍵を伝送するという構成を取る。このため、管理サーバが認証した保守装置でない限り、車両との通信が行えなくなるため、接続時にもエンティティ認証を行うことができる。
このように、第一の実施形態では、データ認証とエンティティ認証を重ねて行うことで、不正な保守作業を防止することができる。

（第二の実施形態）
第一の実施形態では、保守装置２０と管理サーバ３０との間がオンラインで接続されており、管理サーバが保守装置を認証したうえで更新パッケージを生成した。
これに対して第二の実施形態は、管理サーバにて予め生成しておいた更新パッケージをオフラインで取り込む実施形態である。

第二の実施形態では、管理サーバが、ソフトウェアの更新に用いる保守装置２０を特定したうえで、事前に更新パッケージを生成する。図９は、第二の実施形態において生成される更新パッケージの構造を表した図である。第二の実施形態では、第二のデータに、第一の実施形態における「理想状態」、すなわち、真正な保守装置の構成証明によって得られるハッシュ値が追加される。

図１０は、第二の実施形態における保守装置２０の処理フローチャートである。なお、第一の実施形態と同様の処理を行うステップについては点線で図示し、説明を省略する。

ステップＳ１１で構成証明データを生成した後、ステップＳ４１で、管理サーバ３０で生成された更新パッケージを、例えば外部記憶装置を介して保守装置２０に取り込む。
そして、ステップＳ４２で、更新パッケージと、ステップＳ１１で生成した構成証明データを車両に送信する。

図１１は、第二の実施形態における車両１０の処理フローチャートである。第二の実施形態では、車両１０が、ステップＳ３４を実行する前に、構成証明データが真正であることを確認する（ステップＳ５１）。具体的には、第二のデータに含まれる保守装置公開鍵を用いて、取得した構成証明データの発信元を検証したうえで、更新パッケージに含まれる「理想状態」と、取得した構成証明データとを対比させ、一致しているか否かを確認する。
ここで両者が一致していない場合、保守装置２０のソフトウェアが真正なものではない可能性があるため、処理を終了させる。
ステップＳ３４およびステップＳ１５以降の処理は、第一の実施形態と同様である。

以上説明したように、第二の実施形態では、更新パッケージに「理想状態」を含ませ、保守装置２０の正当性を車両が確認する。仮に、理想状態を改ざんした場合、ステップＳ５１にて行う検証が失敗し、また、構成証明データは、ＴＰＭモジュール内で生成されるため、改ざんすることができない。すなわち、第一の実施形態と同様に、保守装置が正当なものであることを確認することができる。

（第三の実施形態）
第一および第二の実施形態では、保守装置２０に記憶されている全てのソフトウェアを構成証明の対象とした。しかし、ＴＰＭが有しているプロセッサは、コンピュータに用いられている演算処理装置と比較すると低速であり、構成証明の対象が多くなると処理に時間がかかるという欠点がある。第三の実施形態は、構成証明の対象を絞ることで、ステップＳ１１の処理時間を短縮する実施形態である。

図１２は、構成証明の対象となるソフトウェアの範囲を示す図である。点線で示した範囲が、それぞれの形態における構成証明の対象範囲である。第一の実施形態では、構成証明の対象は、コンピュータに記憶されている全てのソフトウェアであるため、その範囲は図１２（ａ）のようになる。
これに対し、通信ソフトウェアのみが正当であることを確認できればよい場合、構成証明の対象を図１２（ｂ）のように設定することができる。また、通信ソフトウェアに加えて、システムライブラリ、およびカーネルの正当性まで確認したい場合、構成証明の対象を図１２（ｃ）のように設定すればよい。

また、ソフトウェアの改ざんを検出するソフトウェアを利用してもよい。記憶されたソフトウェアの変更を監視するソフトウェアを、オブザーバと称する。
図１２（ｄ）に示したオブザーバとは、ユーザアプリケーションの変更を検出するアプリケーションである。オブザーバは、実行を許可するアプリケーションのリストを保持し、アプリケーションが変更もしくは改ざんされた場合、即時検出することができる。アプリケーションの実行ファイルが変更されたことを検知する技術は公知であり、例えばホワイトリスト方式のアンチウイルスソフトに用いられている。そして、構成証明の対象を、オブザーバ、システムライブラリ、およびカーネルとすることで、保守装置２０に記憶されている全てのソフトウェアについて変更を検知することができる。すなわち、図１２（ａ）の範囲に対して構成証明を実施するのと同じ効果が得られる。もちろん、構成証明の対象をオブザーバのみとしてもよい。

第一および第二の実施形態では、構成証明データの生成に時間がかかるという欠点があったが、第三の実施形態によると、短時間で構成証明データの生成を完了させることができる。

（変形例）
上記の実施形態はあくまでも一例であって、本発明はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、各実施形態では、ＴＰＭを用いて構成証明を実施しているが、第一の秘密鍵を記憶し、ソフトウェアのハッシュ値を生成することができれば、必ずしもＴＰＭを用いる必要は無い。例えば、任意のセキュアデバイスを用いてもよい。この他にも、ソフトウェアの正当性は、ハッシュ値以外によって確認してもよい。

また、各実施形態では、管理サーバが保守装置公開鍵を、車両がセンタ公開鍵を保持し、電子署名による認証を行っているが、通信相手が正当であることを確認することができれば、他の方法を用いてもよい。例えば公開鍵証明書などを用い、その都度公開鍵を伝送してもよい。

また、第二の実施形態では、オフラインで更新パッケージを取得する例を挙げたが、更新パッケージの伝送はオンラインで行ってもよい。
また、各実施形態では、更新パッケージに保守装置公開鍵を含め、当該公開鍵を用いて
セッション鍵を伝送したが、保守装置公開鍵は必ずしも更新パッケージに含めなくても
よく、また、セッション鍵の利用も必須ではない。
また、ステップＳ３４〜Ｓ３５の処理を省略し、車両１０が認証を完了した段階で、単独でソフトウェアの更新を行うようにしてもよい。

１０ 車両
１１，２１，２２，３１ 通信部
１２ センタ公開鍵記憶部
１３ パッケージ検証部
１４ コマンド実行部
２０ 保守装置
２３ 制御部
２００ ＴＰＭモジュール
２０１ ＴＰＭ制御部
２０２ 構成証明生成部
３０ 管理サーバ
３２ 保守装置公開鍵記憶部
３３ 構成証明検証部
３４ パッケージ生成部
３５ センタ秘密鍵記憶部

Claims (10)

1. 接続されたコンピュータのソフトウェア更新を制御する第一のコンピュータと、ソフトウェアを更新する対象である第二のコンピュータと、前記第二のコンピュータに適用される更新ソフトウェアを提供する管理サーバと、を含み、前記第二のコンピュータが、前記更新ソフトウェアの正当性を認証する認証システムであって、
   前記管理サーバが、
   前記第一のコンピュータから送信された構成証明データに基づいて、前記第一のコンピュータのエンティティ認証を行い、前記第一のコンピュータが正当なものである場合に、前記第二のコンピュータに対応する更新ソフトウェアを含む第一のデータと、前記更新ソフトウェアに対応するダイジェストを含むデータに自己の電子署名を付加したデータである第二のデータと、を前記第一のコンピュータに送信する提供手段と、を有し、
   前記第一のコンピュータが、
   自己の正当性を示すデータである構成証明データを取得し、前記管理サーバに送信する自己証明手段と、
   前記管理サーバから前記第一および第二のデータを取得し、前記第二のコンピュータに転送する転送手段と、
   前記第二のコンピュータが、
   前記管理サーバに対応する公開鍵を用いて、前記第二のデータに含まれる電子署名を検証し、また、前記第二のデータに含まれるダイジェストを用いて、前記更新ソフトウェアを検証し、前記二種類の検証によって正当性が全て確認できた場合にソフトウェア更新を行う更新手段と、を有する、
   認証システム。
2. 前記第一のコンピュータが有する自己証明手段は、自装置のプラットフォーム構成に対応するダイジェストを生成し、自己の電子署名を加えたデータを、構成証明データとして前記管理サーバに送信し、
   前記管理サーバは、前記電子署名およびダイジェストを検証することで、前記第一のコンピュータのエンティティ認証を行う、
   請求項１に記載の認証システム。
3. 前記第一のコンピュータが有する自己証明手段は、耐タンパ性デバイスによって実現される、
   請求項２に記載の認証システム。
4. 前記第一のコンピュータは、前記第二のコンピュータに対してソフトウェアの更新を指示する更新制御手段をさらに有し、
   前記第二のデータは、前記ダイジェストと、前記第一のコンピュータに対応する公開鍵である第一の公開鍵と、に、前記管理サーバの電子署名を付加したデータであり、
   前記更新手段は、前記二種類の検証が共に成功した場合に、前記第二のデータに含まれる第一の公開鍵を用いて、前記第一のコンピュータとの秘匿通信に用いるセッション鍵を暗号化して前記第一のコンピュータに送信し、
   前記更新制御手段は、暗号化されたセッション鍵を自己の秘密鍵で復号することで、秘匿通信に用いるセッション鍵を取得し、前記第二のコンピュータとの秘匿通信を行う、
   請求項１から３のいずれかに記載の認証システム。
5. 前記セッション鍵は擬似乱数である、
   請求項４に記載の認証システム。
6. 接続されたコンピュータのソフトウェア更新を制御する第一のコンピュータと、ソフト
   ウェアを更新する対象である第二のコンピュータと、を含み、前記第二のコンピュータが、前記第一のコンピュータおよび更新ソフトウェアを認証する認証システムであって、
   前記第一のコンピュータが、
   前記第二のコンピュータに対応する更新ソフトウェアを含む第一のデータと、前記更新ソフトウェアに対応する第一のダイジェストと、前記第一のコンピュータのプラットフォームに対応する第二のダイジェストと、を含むデータに、更新ソフトウェアの提供元の電子署名である第一の電子署名を付加したデータである第二のデータと、を取得し、前記第二のコンピュータに転送する転送手段と、
   自己の正当性を示すデータである構成証明データを取得し、前記第二のコンピュータに送信する自己証明手段と、
   前記第二のコンピュータが、
   前記更新ソフトウェアの提供元に対応する公開鍵を用いて、前記第二のデータに含まれる第一の電子署名を検証し、また、前記第二のデータに含まれる第一のダイジェストを用いて、前記更新ソフトウェアを検証し、また、前記第二のデータに含まれる第二のダイジェストを用いて前記構成証明データを検証し、前記三種類の検証によって正当性が全て確認できた場合にソフトウェア更新を行う更新手段を有する、
   認証システム。
7. 前記第二のデータは、前記第一のダイジェストと、前記第二のダイジェストと、に、ソフトウェアの提供元の電子署名を付加したデータであり、
   前記第一のコンピュータが有する自己証明手段は、自装置のプラットフォーム構成に対応する第三のダイジェストを生成し、自己の電子署名である第二の電子署名を加えたデータを、構成証明データとして前記第二のコンピュータに送信し、
   前記更新手段は、前記第二の電子署名の検証と、前記第二のダイジェストおよび第三のダイジェストの同一性の確認と、を行うことで前記第一のコンピュータのエンティティ認証を行う、
   請求項６に記載の認証システム。
8. 前記第一のコンピュータが有する自己証明手段は、耐タンパ性デバイスによって実現される、
   請求項７に記載の認証システム。
9. 前記第一のコンピュータは、前記第二のコンピュータに対してソフトウェアの更新を指示する更新制御手段をさらに有し、
   前記第二のデータは、前記第一および第二のダイジェストと、前記第一のコンピュータに対応する公開鍵である第一の公開鍵と、に、前記更新ソフトウェアの提供元の電子署名を付加したデータであり、
   前記更新手段は、前記三種類の検証が全て成功した場合に、前記第二のデータに含まれる第一の公開鍵を用いて、前記第一のコンピュータとの秘匿通信に用いるセッション鍵を暗号化して前記第一のコンピュータに送信し、
   前記更新制御手段は、暗号化されたセッション鍵を自己の秘密鍵で復号することで、秘匿通信に用いるセッション鍵を取得し、前記第二のコンピュータとの秘匿通信を行う、
   請求項６から８のいずれかに記載の認証システム。
10. 前記セッション鍵は擬似乱数である、
    請求項９に記載の認証システム。

Images