特許 6961553 情報処理装置、システム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6961553

(24)【登録日】2021年10月15日

(45)【発行日】2021年11月5日

(54)【発明の名称】情報処理装置、システム及び方法

(51)【国際特許分類】

   G06F 21/14 20130101AFI20211025BHJP

   H04L 9/32 20060101ALI20211025BHJP

   G09C 1/00 20060101ALI20211025BHJP

   G06F 21/44 20130101ALI20211025BHJP

【ＦＩ】

   G06F21/14

   H04L9/00 675A

   G09C1/00 640D

   G06F21/44

【請求項の数】17

【全頁数】28

(21)【出願番号】特願2018-161586(P2018-161586)

(22)【出願日】2018年8月30日

(65)【公開番号】特開2020-35202(P2020-35202A)

(43)【公開日】2020年3月5日

【審査請求日】2020年8月31日

(73)【特許権者】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(73)【特許権者】

【識別番号】317011920

【氏名又は名称】東芝デバイス＆ストレージ株式会社

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100103034

【弁理士】

【氏名又は名称】野河 信久

(74)【代理人】

【識別番号】100075672

【弁理士】

【氏名又は名称】峰 隆司

(74)【代理人】

【識別番号】100153051

【弁理士】

【氏名又は名称】河野 直樹

(74)【代理人】

【識別番号】100189913

【弁理士】

【氏名又は名称】鵜飼 健

(72)【発明者】

【氏名】小池 竜一

(72)【発明者】

【氏名】橋本 幹生

(72)【発明者】

【氏名】新保 淳

【審査官】 小林 秀和

(56)【参考文献】

【文献】 米国特許出願公開第２０１５／０２４２６０６（ＵＳ，Ａ１）

【文献】 特開２００７−２２６２７６（ＪＰ，Ａ）

【文献】 特開２０１５−１４１５０５（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ２１／１４

Ｈ０４Ｌ ９／３２

Ｇ０９Ｃ １／００

Ｇ０６Ｆ ２１／４４

(57)【特許請求の範囲】

【請求項1】

組込み機器に適用する情報処理装置であって、
コントローラと、
前記コントローラによって直接実行可能な第１ソフトウェアを記憶しかつ書換え可能である第１メモリ領域と、前記コントローラによって直接実行可能な第２ソフトウェアを記憶しかつ書換え不可である第２メモリ領域と、を含む不揮発性メモリと、
を備え、
前記コントローラは、
前記第１ソフトウェア及び前記第２ソフトウェアを使用して、外部からのアクセスに応じてデバッグの可否の判定を、前記情報処理装置とは異なるサーバに要求するように構成された、
情報処理装置。

【請求項2】

前記コントローラは、
前記第２ソフトウェアを使用して、前記デバッグの可否を示す前記サーバの判定結果に基づいて、前記デバッグの可否を制御するように構成された、
請求項１に記載の情報処理装置。

【請求項3】

前記コントローラは、
前記第２ソフトウェアを使用して、前記デバッグの可否の判定を前記サーバに要求するためのメッセージを生成するように構成された、
請求項１に記載の情報処理装置。

【請求項4】

前記コントローラは、
前記第１ソフトウェアを使用して、前記メッセージを前記サーバに送信するように構成された、
請求項３に記載の情報処理装置。

【請求項5】

前記メッセージは、デバッグの対象である前記第１メモリ領域内に記憶されたソフトウェアを特定する第１情報を含む、
請求項４に記載の情報処理装置。

【請求項6】

前記コントローラは、
前記第１ソフトウェアを使用して、前記サーバから送信された前記判定結果を受信し、
前記第２ソフトウェアを使用して前記判定結果の正当性を検証するように構成された、
請求項２に記載の情報処理装置。

【請求項7】

前記コントローラは、
前記判定結果が正当性を有する場合に、前記判定結果によりデバッグが許可であれば、前記第２ソフトウェアを使用して、前記デバッグを有効化するように構成された、
請求項６に記載の情報処理装置。

【請求項8】

前記コントローラは、前記第１ソフトウェアを使用して、前記第１情報を収集するように構成された、
請求項５に記載の情報処理装置。

【請求項9】

前記コントローラは、前記第１ソフトウェア及び前記第２ソフトウェアのいずれが実行されているかを判定するように構成された、
請求項１に記載の情報処理装置。

【請求項10】

前記不揮発性メモリは、前記第１ソフトウェアが実行される場合には書換え不可であり、前記第２ソフトウェアが実行される場合には書換え可能である第３メモリ領域を含む、
請求項９に記載の情報処理装置。

【請求項11】

前記コントローラが再起動された後に一度だけ書換え可能となるレジスタを更に備えた、
請求項９に記載の情報処理装置。

【請求項12】

請求項１に記載の情報処理装置と、
当該情報処理装置と前記サーバとの間で通信して情報交換を可能とするネットワークとを有するシステム。

【請求項13】

前記情報処理装置のコントローラは、
前記第２ソフトウェアを使用して、前記デバッグの可否の判定を前記サーバに要求するためのメッセージを生成し、
前記第１ソフトウェアを使用して、前記サーバに前記メッセージを送信するように構成され、
前記サーバは、
前記メッセージの正当性を検証し、
前記メッセージに基づいて前記デバッグの可否を判定し、
前記デバッグの可否の判定結果を前記コントローラに送信するように構成された、
請求項１２に記載のシステム。

【請求項14】

組込み機器内のコントローラが実行しかつ不揮発性メモリに記憶される第１ソフトウェア及び第２ソフトウェアによってデバッグを制御する方法であって、
外部からのアクセスを受信することと、
前記外部からのアクセスに応じて、前記第１ソフトウェア及び前記第２ソフトウェアを使用して、前記デバッグの可否の判定を前記コントローラとは異なるサーバに要求することと、
を備え、
前記第１ソフトウェアは、前記不揮発性メモリに含まれかつ書換え可能である第１メモリ領域に記憶され、前記コントローラによって直接実行可能であり、
前記第２ソフトウェアは、前記不揮発性メモリに含まれかつ書換え不可である第２メモリ領域に記憶され、前記コントローラによって直接実行可能である、
方法。

【請求項15】

前記サーバに要求することは、
前記第２ソフトウェアを使用して、前記デバッグの可否の判定を前記サーバに要求するためのメッセージを生成することと、
前記第１ソフトウェアを使用して、前記メッセージを前記サーバに送信することと、
を含む、
請求項１４に記載の方法。

【請求項16】

前記第１ソフトウェアを使用して、前記サーバから送信された前記判定の結果を受信することと、
前記第２ソフトウェアを使用して、前記判定の結果の正当性を検証することと、
を更に備えた、
請求項１５に記載の方法。

【請求項17】

前記判定の結果が正当性を有する場合に、前記判定の結果によりデバッグが許可であれば、前記第２ソフトウェアを使用して、前記デバッグを有効化することを更に備えた、
請求項１６に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、組込み機器に適用する情報処理装置、システム及び方法に関する。

【背景技術】

【0002】

近年では、例えば車両などの各種の製品のほとんどには、コンピュータ制御を行う組込み機器（組込みシステム）が搭載されている。このため、組込み機器に対して、外部者からの不正なアクセスに対するセキュリティ対策が重要になっている。

【0003】

不正なアクセスとは、具体的には、組込み機器のマイコン（マイクロコントローラ又マイクロコンピュータ）にデバッガを接続し、マイコンのソフトウェアをデバッグモードで動作させることである。外部者は、デバッガを通じて、ソフトウェアのメモリ内容を読み出し、又は書込みすることが可能となるため、結果としてソフトウェア動作を解析することが可能になる。また、外部者は、ソフトウェア動作の解析だけでなく、機密情報を不正に取得し、あるいはソフトウェアを改ざんして不正な動作をさせることも可能である。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１３−０６９０５３号公報

【特許文献2】特開２０１６−１４４０４０号公報

【特許文献3】特開２０１７−０３３１４９号公報

【特許文献4】特開２０１７−１５６９４５号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

組込み機器のセキュリティ対策としては、不正なデバッグに対する有効なアクセス制限機能の実現が望まれる。しかし、低コストの組込み機器は、コスト面から、不正なデバッグに対する有効なアクセス制限を確実に実行できる機能を組み込むことは困難である。

【0006】

そこで、目的は、低コストの組込み機器のセキュリティ対策として、不正なデバッグに対する有効なアクセス制限を確実に実行できる情報処理装置を提供することにある。

【課題を解決するための手段】

【0007】

本実施形態の情報処理装置は、組込み機器に適用する情報処理装置であって、コントローラと、上記コントローラによって直接実行可能な第１ソフトウェアを記憶しかつ書換え可能である第１メモリ領域と、上記コントローラによって直接実行可能な第２ソフトウェアを記憶しかつ書換え不可である第２メモリ領域と、を含む不揮発性メモリと、を備える。上記コントローラは、上記第１ソフトウェア及び上記第２ソフトウェアを使用して、外部からのアクセスに応じてデバッグ又はソフトウェア変更の可否の判定を、上記情報処理装置とは異なるサーバに要求するように構成される。

【図面の簡単な説明】

【0008】

【図1】実施形態に関するシステムの構成を説明するためのブロック図。

【図2】実施形態に関する制御装置の構成を説明するためのブロック図。

【図3】実施形態に関するマイコンの内部構成を説明するためのブロック図。

【図4】実施形態に関する不揮発性メモリの内部構成を示す図。

【図5】実施形態に関するＲＯＭモニタ専用記憶領域部の内部構成を示す図。

【図6】実施形態に関する共用記憶領域部の内部構成を示す図。

【図7】実施形態に関する制御装置と管理サーバとの関係を示す図。

【図8】実施形態に関するＲＯＭモニタとシステムソフトの機能を説明するためのブロック図。

【図9】実施形態に関するマイコンの基本的処理を説明するためのフローチャート。

【図10】実施形態に関するＲＯＭモニタの処理を説明するためのフローチャート。

【図11】実施形態に関するデバッグ許可要請メッセージの構成を示す図。

【図12】実施形態に関するシステムソフトの処理を説明するためのフローチャート。

【図13】実施形態に関するデバッグ可否の処理を説明するためのフローチャート。

【図14】実施形態に関する通常処理の連携を説明するためのシーケンス図。

【図15】実施形態に関するデバッグ許可要求処理の連携を説明するためのシーケンス図。

【図16】実施形態に関するデバッグ許可要求メッセージの作成処理の連携を説明するためのシーケンス図。

【図17】実施形態に関する管理サーバとの通信処理の連携を説明するためのシーケンス図。

【図18】実施形態に関するデバッグ許可証の検証処理の連携を説明するためのシーケンス図。

【図19】実施形態に関する車両の車内ネットワークを示す図。

【図20】実施形態の変形例に関するブロック図。

【発明を実施するための形態】

【0009】

以下図面を参照して、実施形態を説明する。
［システムの構成］
図１は、本実施形態に関するシステムの構成を示すブロック図である。図１に示すように、本実施形態のシステムは、管理サーバ１００、組込み機器として制御装置（後述する）を搭載した車両２００、及び広域のネットワーク３００を有する構成である。

【0010】

ネットワーク３００には、無線アクセスポイント３１０、及び整備工場３３０に設置されている通信装置３２０のそれぞれが有線接続されている。整備工場３３０は、例えば車両２００の整備を行う施設であり、通信装置３２０を経由して車両２００の制御装置とネットワーク３００との接続が可能になっている。また、車両２００の制御装置は、無線アクセスポイント３１０との無線通信により、ネットワーク３００との接続が可能になっている。

【0011】

車両２００の制御装置は、公道上などで車両２００が走行中している場合には、無線アクセスポイント３１０及びネットワーク３００を経由して、管理サーバ１００との間で通信する通信機能を含む。また、車両２００の制御装置は、整備工場３３０において車両２００が停止している場合には、通信装置３２０及びネットワーク３００を経由して、管理サーバ１００との間で通信する通信機能を含む。

【0012】

管理サーバ１００は、例えば車両２００の完成車メーカが管理しているサーバとし、各車両２００を管理し、本実施形態に関する車両２００に搭載されている制御装置のマイコンに対するデバッグ可否を判定する機能（後述する）を有する。

【0013】

図１９は、車両２００の車内ネットワークを示す図である。図１９に示すように、車内ネットワークには複数の制御装置１０が接続されており、それぞれが車両の装備を制御している。例えば、制御装置１０は、車両内無線ネットワークを介してタイヤ空気圧センサ２１０と接続している。さらに、例えば、制御装置１０は、車両内有線ネットワークを介して、エンジン２１１やアクチュエータ２１２、あるいはエアコンなどの機器を制御している。また、各制御装置１０はそれぞれ、ゲートウェイ（ＧＷ）２１３を経由して有線通信装置２１４及び無線通信装置２１５に接続されている。これにより、各制御装置１０はそれぞれ、必要に応じて車両外の機器と通信を行うことができる。
［制御装置の構成］
図２は、車両２００の内部に搭載された組込み機器として、例えばアクチュエータ２１２を制御する制御装置１０の構成を示すブロック図である。

【0014】

図２に示すように、制御装置１０は、主要部であるマイコン（マイクロコントローラ又マイクロコンピュータ）１１と、デバッグポート１２と、有線／無線通信部１３とを含む。マイコン１１は、入出力インターフェイス１５を介してアクチュエータ駆動回路２１に接続し、このアクチュエータ駆動回路２１を制御することによりアクチュエータ２１２を駆動制御する。また、マイコン１１は、エンジンの回転数やブレーキの操作等を制御する。

【0015】

マイコン１１は、デバッグポート１２を介して、外部のデバッガ２０と接続可能になっている。本実施形態は、後述するように、デバッグポート１２を介して、マイコン１１のソフトウェアに対する不正なデバッグを制限するデバッグアクセス制限機能に関する。

【0016】

ここで、本実施形態のデバッグアクセス制限機能が無い場合には、デバッガ２０は、デバッグポート１２を通じて、無条件にマイコン１１をデバッグモードに切り替えることが可能である。デバッグモードになったマイコン１１は、動作中のソフトウェアを解析することに適した環境をデバッガ２０に提供できる。例えば、マイコン１１のレジスタ値やメモリなどの各種情報の読み込みが可能になり、ソフトウェアの実行を一時的に停止することが可能となり、またプログラムを書き替えることも可能となる。

【0017】

マイコン１１は、有線／無線通信部１３及び通信インターフェイス１６を介して、無線によりネットワーク３００に接続可能である。これにより、マイコン１１は、後述するように、ネットワーク３００を介して管理サーバ１００との間で各種の情報交換を行うことが可能である。
［マイコンの構成］
図３は、マイコン１１の内部構成を示すブロック図である。図３に示すように、マイコン１１は、命令実行ユニット３０と、動作ソフト判定ユニット３１と、デバッグユニット３２と、制御レジスタ３３と、通信ユニット３５とを含む。

【0018】

命令実行ユニット３０は、後述する不揮発性メモリ３６に格納されている各種のソフトウェアに含まれる命令群を実行するユニットである。命令実行ユニット３０は、動作ソフト判定ユニット３１及び制御レジスタ３３を経由して、内蔵ハードウェアの各種制御を実行する。例えば、命令実行ユニット３０は、制御レジスタ３３を通じて、リセット信号の出力を管理するレジスタに書き込みを行うことで、マイコン１１全体をリセットすることが可能である。

【0019】

また、命令実行ユニット３０は、制御レジスタ３３を通じて、通信ユニット３５、不揮発性メモリ３６、揮発性メモリ（ＲＡＭ）３７、暗号化ユニット３８、および乱数生成ユニット３９の制御を実行する。なお、不揮発性メモリ３６と揮発性メモリ３７とは内部バスに接続されている、いわゆるオンチップメモリ構成である。

【0020】

動作ソフト判定ユニット３１は、実行中のソフトウェアの種類を判別することで、命令実行ユニット３０による不揮発性メモリ３６と揮発性メモリ３７との一部領域に対する読み書きを制限すると共に、デバッグモードレジスタ３４Ｂへの書き込みを禁止する。この時、動作ソフト判定ユニット３１は、動作ソフトの種類を、制御レジスタ３３内の動作ソフトレジスタ３４Ａにより判別する。動作ソフト判定ユニット３１は、動作ソフトレジスタ３４Ａの値が０の場合には、制限を実行せず、０以外の場合には制限を実行する。

【0021】

制御レジスタ３３は、書き換え制限のある動作ソフトレジスタ３４Ａ及びデバッグモードレジスタ３４Ｂを含む。

【0022】

動作ソフトレジスタ３４Ａは、端末の電源投入あるいはリセット時に必ず０クリアされて、その後一度だけ値を書き込める。値が書き込まれると、もう一度、端末のリセットを行うまでは値を変更することはできない。この性質により、リセット直後に動作するＲＯＭモニタ（後述）が動作している期間は、不揮発性メモリ３６、揮発性メモリ３７、デバッグモードレジスタ３４Ｂに対して制限なく読み書きが可能である。一方、ＲＯＭモニタがレジスタ値を０以外に変更すると、不揮発性メモリ３６、揮発性メモリ３７の一部領域への読み書きが制限され、デバッグモードレジスタ３４Ｂへの書き込みが行えなくなる。動作ソフトレジスタ３４Ａは、ＲＯＭモニタが他のソフトウェアに制御を移す直前に書き込みが行われる。

【0023】

デバッグユニット３２は、命令実行ユニット３０およびマイコン１１の外部のデバッグポート１２に接続されている。デバッグユニット３２は、デバッグモード（デバッグ機能）が有効であれば、外部のデバッガ２０（図２を参照）の指示に従って、命令実行ユニット３０を操作する。デバッグモードの有効又は無効の切り替えは、制御レジスタ３３内のデバッグモードレジスタ３４Ｂにより行われる。

【0024】

暗号化ユニット３８は、ソフトウェア処理では時間を要するブロック暗号化処理を効率的に実行する専用ユニットである。暗号化方式は、例えば３ＤＥＳ（Data Encryption Standard）やＡＥＳ（Advanced Encryption Standard）などである。また、乱数生成ユニット３９は、ソフトウェアでは実装が困難な乱数の生成を実行する専用ユニットである。

【0025】

通信ユニット３５は、マイコン１１外部の有線／無線通信部１３に接続されており、ＵＡＲＴ（Universal Asynchronous Receiver-Transmitter）やＣＡＮ（Controller Area Network）などの車載用ネットワークで多用されるプロトコルで情報通信を実行する。
[不揮発性メモリの内部構成]
図４は、不揮発性メモリ３６の内部構成（メモリマップ）を示す図である。図４に示すように、不揮発性メモリ３６は、ソフトウェアであるＲＯＭモニタを格納している記憶領域であるＲＯＭモニタ部４０、およびシステムソフトウェア（システムソフトと表記する場合がある）を格納している記憶領域であるシステムソフト部４２を含む。

【0026】

ＲＯＭモニタは、後述するように、本実施形態のデバッグのアクセス制限に関するセキュリティ上の重要な処理のみを実行するソフトウェアである。システムソフトは、マイコン１１の利用目的に沿った一般的な処理を実行するソフトウェアである。

【0027】

ＲＯＭモニタ部４０は、原則として書き換えが想定されていない領域であり、不揮発性メモリ３６の書き替え禁止領域に配置される。システムソフト部４２は、書き替え可能な領域に配置されており、原則としてはシステムソフトのアップデート時にのみ書き替えられる。

【0028】

さらに、不揮発性メモリ３６は、各ソフトウェアが利用する情報を保存するためのＲＯＭモニタ専用記憶領域部４１および共用記憶領域部４３を含む。

【0029】

図５は、ＲＯＭモニタ専用記憶領域部４１の内部構成を示す図である。ＲＯＭモニタ専用記憶領域部４１は、ＲＯＭモニタのみが読み書きできる領域である。よって、ＲＯＭモニタ専用記憶領域部４１は、システムソフトは読み書きできない領域である。

【0030】

図５に示すように、ＲＯＭモニタ専用記憶領域部４１は、デバッグモードフラグが保存されるデバッグモードフラグ部５０、乱数が保存される乱数部５１、共通鍵が保存される共通鍵部５２、およびデバッグ可能回数が保存されるデバッグ可能回数部５３を含む。

【0031】

デバッグモードフラグは、デバッグモード（デバッグ機能）の有効又は無効を示すフラグである。乱数部５１の乱数は、リプレイアタック対策向けに管理サーバ１００との通信時に使われる乱数である。共通鍵部５２の共通鍵は、マイコン１１と管理サーバ１００とが互いに保持している共通の共通鍵である。なお、共通鍵は、個々のマイコン毎に異なる鍵が割り当てられており、出荷前に管理サーバ１００との間で対応付けが完了しているものとする。デバッグ可能回数は、マイコン１１に対してデバッグを実行できる残り回数である。

【0032】

図６は、共用記憶領域部４３の内部構成を示す図である。共用記憶領域部４３は、ＲＯＭモニタおよびシステムソフトの双方が読み書き可能な領域である。各ソフトウェアは共用記憶領域部４３に対して、それぞれが利用する情報を保存すると共に、マイコン１１のリセットを跨いで、もう一方のソフトウェアに伝達する際の命令や情報なども保存する。

【0033】

図６に示すように、共用記憶領域部４３は、ＲＯＭモニタ向け命令部６０、システムソフト情報部６１、システムソフト機密情報部６２、システムソフト向け命令部６３、およびデバッグメッセージバッファ部（メッセージバッファ部と表記する場合がある）６４の各記憶領域を含む。

【0034】

ＲＯＭモニタ向け命令部６０は、システムソフトからＲＯＭモニタへの命令を書き込む領域である。本実施形態では、具体的な命令としては、システムソフトを通常ブートさせる命令（sys-boot）と、デバッグ許可要求メッセージを作成させる命令（make-req）の２種類が定義されている。なお、これらの命令は、命令実行ユニット３０が直接解釈する機械語命令ではなく、ＲＯＭモニタおよびシステムソフトに対する命令である。

【0035】

システムソフト情報部６１は、システムソフトが収集した任意の情報が保存される領域である。システムソフト機密情報部６２は、システムソフトが利用している機密情報が保存される領域である。システムソフト向け命令部６３は、ＲＯＭモニタからシステムソフトへの命令を書き込む領域である。本実施形態では、具体的な命令としては、システムソフトに通常処理のみを行わせる命令（normal）と、管理サーバ１００にデバッグ許可要求メッセージを送信させる命令（send-req）の２種類が定義されている。メッセージバッファ部６４は、管理サーバ１００との間で送受信される各種メッセージが保存される領域である。
[ＲＯＭモニタとデバッグモードレジスタの構成]
ここで、図３に戻って、本実施形態のＲＯＭモニタとデバッグモードレジスタ３４Ｂの構成について説明する。

【0036】

前述したように、不揮発性メモリ３６のＲＯＭモニタ専用記憶領域部４１は、ＲＯＭモニタの実行中に、ＲＯＭモニタのみが読み書きできる領域である。一方、制御レジスタ３３に含まれるデバッグモードレジスタ３４Ｂに対する書き込みも、ＲＯＭモニタの実行中に限定される。

【0037】

これらの実行手段としては、動作ソフト判定ユニット３１が関与する。動作ソフト判定ユニット３１は、命令実行ユニット３０が命令を実行する際に、命令実行によるアクセス先（オペランド）がＲＯＭモニタであるか、ＲＯＭモニタ専用記憶領域部４１およびデバッグモードレジスタ３４Ｂであるか、それ以外の領域であるかを監視している。動作ソフト判定ユニット３１は、実行中ソフトウェアの種類も判定しているため、ＲＯＭモニタの命令の場合にのみ、オペランドの制限なしで命令が実行されることになる。言い換えると、ＲＯＭモニタ実行中の時にだけ、ＲＯＭモニタ専用記憶領域部４１やデバッグモードレジスタ３４Ｂの書き換えが可能となる。なお、本実施形態では、ＲＯＭモニタ専用記憶領域部４１は不揮発性メモリ３６に設定されているが、揮発性メモリ３７の一部をＲＯＭモニタ専用記憶領域部４１としてもよい。

【0038】

ＲＯＭモニタは、リセットおよびマスク不能割り込み（NMI: Non-Maskable Interrupt）の２つのエントリポイントのみを有する。ＲＯＭモニタは、これら２つのエントリポイント以外のアドレスからの実行はできない。即ち、ＲＯＭモニタは、リセット時またはＮＭＩ時のみ実行される。
[車両の制御装置と管理サーバとの関係]
図７は、デバッグに関する車両２００の制御装置１０と管理サーバ１００との関係を示す図である。前述したように、本実施形態では、車両２００の制御装置１０と、管理サーバ１００とは、ネットワーク３００を経由して接続し、情報交換を行うことが可能である。

【0039】

図７に示すように、車両２００の制御装置１０に含まれるマイコン１１内のソフトウェアをデバッグしたい場合には、外部からデバッガ２０がデバッグポート１２に接続される。本実施形態では、マイコン１１は、デバッガ２０からのデバッグアクセスに対して、デバッグモードに入って良いか否かの判断を管理サーバ１００に問い合わせる。

【0040】

管理サーバ１００は、車両２００の制御装置１０から受け取った情報に基づいて、デバッグの可否を判断し、その判断結果を送り返す。マイコン１１は、管理サーバ１００からの判断結果に基づいて、デバッグモードに切り替えを実行する。あるいは、マイコン１１は、デバッグモードへの切り替えを拒否して、デバッガ２０に対してデバッグアクセスを切り離す処理を実行する。

【0041】

図７に示すように、実装的な観点からは、車両２００の制御装置１０は、ネットワーク３００を経由してデバッグ許可要求メッセージ７０を管理サーバ１００に送信する。管理サーバ１００は、当該デバッグ許可要求メッセージ７０に応じて、デバッグ可であればデバッグ許可証７１を制御装置１０に送り返す。マイコン１１は、当該デバッグ許可証７１により、デバッグ許可が与えられたと判定する。

【0042】

即ち、本実施形態は、デバッガ２０からのデバッグアクセスに対して、マイコン１１側ではなく、管理サーバ１００においてデバッグの可否を判断するように、管理サーバ１００側へのデバッグ許可権限を分離する構成である。これにより、管理サーバ１００を運営する、例えば車両２００の完成車メーカ側が各車両２００のデバッグ状況を把握できるようになる。

【0043】

ただし、本実施形態の仕組みは、当然ながら、車両２００のマイコン１１が管理サーバ１００側の判断を遵守する必要がある。具体例として、例えば、悪意ある攻撃により、マイコン１１のシステムソフトが異常な状態に陥っていれば、システムソフトは管理サーバ１００側の判断を無視する可能性がある。すると、管理サーバ１００側がいくら正しく判断しても、マイコン１１側ではそれを無視して悪意あるデバッグを許可してしまう事態が生じる。

【0044】

このような事態を回避するためには、管理サーバ１００側の判断を遵守する機構をマイコン１１側に用意する必要がある。換言すれば、悪意ある攻撃の影響を受けずに、マイコン１１側は正しい情報を管理サーバ１００側に伝達すること、管理サーバ１００側の判断結果に基づいて必ず実行することの２点を満たす機構を用意する必要がある。
[ＲＯＭモニタとシステムソフトの機能]
図８は、ＲＯＭモニタとシステムソフトの機能を説明するためのブロック図である。図８に示すように、マイコン１１は、主要な機能を提供するソフトウェアとして、ＲＯＭモニタ８０およびシステムソフト９１を有する。

【0045】

ＲＯＭモニタ８０およびシステムソフト９１はそれぞれ、前述したように、不揮発性メモリ３６のＲＯＭモニタ部４０およびシステムソフト部４２に格納されている。不揮発性メモリ３６は、各ソフトウェアが関係する記憶領域部として、ＲＯＭモニタ専用記憶領域部４１および共用記憶領域部４３を含む。ＲＯＭモニタ専用記憶領域部４１は、ＲＯＭモニタ８０のみが読み書きできる領域である。共用記憶領域部４３は、ＲＯＭモニタ８０およびシステムソフト９１の双方が読み書き可能な領域である。

【0046】

ＲＯＭモニタ８０は、後述するように、ＲＯＭモニタ向け命令判定部８１、システムソフト起動部８２、システムソフト検証部８３、システムソフト向け命令変更部８４、デバッグ許可証有効性判定部８５、デバッグポート設定変更部８６、およびデバッグ許可要求メッセージ準備部８７の各ソフトウェア機能部を含む。デバッグ許可要求メッセージ準備部８７は、乱数生成部８８、デバッグ許可要求メッセージ保存部８９および署名部９０の各ソフトウェア機能部を含む。なお、ＲＯＭモニタ８０は通信機能部を含まない。

【0047】

システムソフト９１は、後述するように、システムソフト向け命令判定部９２、ＲＯＭモニタ向け命令変更部９３、システムソフト情報収集部９４、再起動部９５、および通信部９６の各ソフトウェア機能部を含む。通信部９６は、デバッグ許可要求メッセージ送信部９７およびデバッグ許可証受信部９８の各ソフトウェア機能部を含む。

【0048】

さらに、マイコン１１は、ハードウェア主体で実現される機能としては、動作ソフト判定部８００およびデバッグポートアクセス制限部８１０を含む。これらのハードウェア機能部は、総称してＨＷと表記する場合がある。

【0049】

動作ソフト判定部８００は、実行中のソフトウェアがＲＯＭモニタ８０又はシステムソフト９１のいずれであるかを検出して判定する。動作ソフト判定部８００は、動作ソフト判定ユニット３１を含む構成要素であり、ハードウェア実装である。このため、ソフトウェアが悪意ある状態に陥っていても影響は受けない。これにより、ＲＯＭモニタ８０以外のソフトウェアが、ＲＯＭモニタ専用記憶領域部４１およびデバッグモードレジスタ３４Ｂを書き替えるような事態を防止できる。

【0050】

デバッグポートアクセス制限部８１０は、外部のデバッガ２０がデバッグポート１２に接続された場合に、そのアクセス（デバッグアクセス）制限を実際に実行する。デバッグポートアクセス制限部８１０は、デバッグモードが有効であるとき、即ち、制御レジスタ３３のデバッグモードレジスタ３４に有効フラグがセットされている時にのみ、接続されたデバッガ２０との通信（デバッグアクセス）を許可する。デバッグポートアクセス制限部８１０は、デバッグモードが無効である場合には、デバッガ２０との通信を遮断し、デバッグアクセスを拒否する。

【0051】

ここで、管理サーバ１００は、前述したように、マイコン１１とは別のコンピュータであり、デバッグ許可判定部１１０であるソフトウェア機能部を含む。デバッグ許可判定部１１０は、マイコン１１から送信されるデバッグ許可要求メッセージの内容を精査し、問題が無ければデバッグ許可証をマイコン１１に送り返す。
［本実施形態の動作］
以下、図９から図１８を参照して、本実施形態の動作を説明する。図９は、マイコンの基本的処理を説明するフローチャートである。図１０は、ＲＯＭモニタの処理を説明するためのフローチャートである。図１１は、デバッグ許可要請メッセージの構成を示す図である。図１２は、システムソフトの処理を説明するためのフローチャートである。図１３は、デバッグ可否の処理を説明するためのフローチャートである。図１４から図１８は、ＨＷ、ＲＯＭモニタ８０、システムソフト９１、および管理サーバ１００の連携を説明するシーケンス図である。
[マイコンの基本的処理]
図９に示すように、制御装置１０からマイコン１１に電源が入ると、ＲＯＭモニタ８０が起動する（Ｓ１）。ここで、ＲＯＭモニタ８０は、本実施形態のデバッグアクセス制限機能を実現するセキュリティ関連処理を実行する。デバッグアクセス制限機能とは、例えばデバッガ２０による不正なデバッグアクセスに対する有効なアクセス制限を実行できる機能である。なお、ＲＯＭモニタ８０は、ソフトウェアバグ（software bug）およびソフトウェア的な脆弱性もないとする。

【0052】

ＲＯＭモニタ８０は、動作ソフトレジスタ３４Ａの値を０以外に書き替えた上で、システムソフト９１を起動する（Ｓ２）。システムソフト９１は、前述したように、マイコン１１の使用目的に対応する通常処理を実行する（Ｓ３）。通常処理とは、例えば、車両２００のエンジンやエアコンの制御処理である。システムソフト９１は、電源がオフされるまで通常処理を継続する（Ｓ４のＮＯ、Ｓ５のＮＯ）。

【0053】

ここで、制御レジスタ３３を通じてソフトウェア的にリセットがかけられた場合、システムソフト９１からＲＯＭモニタ８０への処理遷移が発生する（Ｓ４のＹＥＳ）。リセットは、例えば、ＲＯＭモニタ８０の実行中、あるいはシステムソフト９１の通常処理が開始される前など、各種のタイミングで発生する。なお、当該処理遷移は、リセット以外に、マイコン１１に対する電源の入れ直しがある場合も発生する。
[ＲＯＭモニタの処理]
図１０に示すように、ＲＯＭモニタ８０は起動後に、システムソフト９１の起動処理以外に、大別して２つのセキュリティ関連処理（デバッグアクセス制限機能）を実行する。第１のセキュリティ関連処理は、デバッグ許可要求メッセージの作成処理（Ｓ１４）である。第２のセキュリティ関連処理は、デバッグ機能の有効化（Ｓ２０）である。以下、具体的に各処理を説明する。

【0054】

ＲＯＭモニタ８０は起動後（Ｓ１０）に、ＲＯＭモニタ向け命令判定部８１により、共用記憶領域部４３に含まれるＲＯＭモニタ向け命令部６０において、システムソフト９１から命令（make-req）が書き込まれていると判定した場合に、デバッグ許可要求メッセージの作成処理を開始する（Ｓ１１のＹＥＳ）。具体的には、ＲＯＭモニタ８０は、システムソフト９１の状態を完全性の観点からチェックする（Ｓ１２）。完全性のチェックとは、不揮発性メモリ３６上のシステムソフト全体が改竄されていないことを確認する処理のことである。確認方法としては、このタイミングでハッシュ値と公開鍵とによる検証を行っても良いし、以前に行われた検証処理に基づいて命令を発効したシステムソフトの完全性は正しいと信じてもよい（例えば、特開2017-156945公報を参照）。ＲＯＭモニタ８０は、システムソフト９１の状態に問題が無ければ（Ｓ１３のＮＯ）、デバッグ許可要求メッセージを作成し（Ｓ１４）、そのデバッグ許可要求メッセージを共用記憶領域部４３のメッセージバッファ部６４に保存する。

【0055】

その後、システムソフト９１のＲＯＭモニタ向け命令変更部９３により、ＲＯＭモニタ向け命令部６０が命令（sys-boot）に書き替えられると、マイコン１１は、制御レジスタ３３を通じてソフトウェア的にリセットする。命令（sys-boot）は、システムソフト９１を通常ブートさせる命令である。従って、ＲＯＭモニタ８０は、次回に起動した際に、デバッグ許可要求メッセージの作成処理がスキップし、システムソフト９１を起動するための処理を実行する（Ｓ１１のＮＯ）。

【0056】

図１１は、デバッグ許可要求メッセージの構成を示す図である。ＲＯＭモニタ８０は、デバッグ許可要求メッセージ準備部８７により、デバッグ許可要求メッセージをデバッグ許可要求メッセージ保存部８９に保存する。

【0057】

図１１に示すように、ＲＯＭモニタ８０は、管理サーバ１００へのデバッグ許可要求を意味する命令（req-debug）を書き込む。次に、ＲＯＭモニタ８０は、乱数生成部８８により生成した乱数を書き込む。乱数は、ＲＯＭモニタ専用記憶領域部４１の乱数部５１に保存される。

【0058】

さらに、ＲＯＭモニタ８０は、共用記憶領域部４３のシステムソフト情報部６１から、システムソフト９１が事前に用意したシステムソフト情報をコピーする。システムソフト情報には、システムソフト名、システムソフト９１のバージョンおよび拡張情報が含まれている。拡張情報は、システムソフト名やバージョン以外の複雑な情報を管理サーバ１００側に伝えるために用意された情報である。ＲＯＭモニタ８０は単純な構成を維持するために、機能追加を目的に更新されることは想定されていない。その一方で、システムソフト９１や管理サーバ１００は、状況に応じて更新がなされる。一般的には、運用の状況に応じて、デバッグの可否判断に対して追加の情報が必要になることが考えられる。その様な情報を、拡張情報としてシステムソフト９１が収集することになる。これにより、将来に渡って、システム拡張を行うことが可能となる。

【0059】

最後に、ＲＯＭモニタ８０は、署名部９０により、管理サーバ１００と共有している共通鍵（共通の共通鍵）を用いて、デバッグ許可要求メッセージ全体に対する電子署名を実行する。共通鍵は、ＲＯＭモニタ専用記憶領域部４１の共通鍵部５２に保存されている。

【0060】

図１０に戻って、ＲＯＭモニタ８０は、ＲＯＭモニタ向け命令部６０に命令（make-req）が書き込まれていない場合（Ｓ１１のＮＯ）、あるいはシステムソフト９１の状態が不正な場合には（Ｓ１３のＹＥＳ）、デバッグ許可要求メッセージの作成処理を実行しない。

【0061】

システムソフトの状態が不正とは、システムソフト部４２が改竄されて、完全性が維持されていない場合である。改竄されたシステムソフト９１は、不正な動作をしている可能性が高く、デバッグ許可要求そのものが信頼できない。このため、ＲＯＭモニタ８０は、デバッグ許可要求を無視することになる。一方、システムソフト９１が正常であれば、同ソフトが収集する情報も信頼できることになる。即ち、デバッグ許可要求メッセージに含まれるシステムソフト名、バージョン、拡張情報の各情報にも、悪意を持った偽情報が混入することはないと推定できる。

【0062】

ＲＯＭモニタ８０は、ＲＯＭモニタ向け命令部６０に命令（make-req）が書き込まれていない場合（Ｓ１１のＮＯ）、第２のセキュリティ関連処理であるデバッグ機能の有効化の処理を実行する。ここで、デバッグ機能の有効化とは、マイコン１１をデバッグモードにして、デバッグポート１２に接続されたデバッガ２０からシステムソフト９１を操作可能にすることである。

【0063】

具体的には、ＲＯＭモニタ８０は、共用記憶領域部４３に含まれるメッセージバッファ部６４に管理サーバ１００から受信したデバッグ許可証が保存されているかを確認し、保存されている場合には、当該デバッグ許可証を読み込む（Ｓ１５）。ＲＯＭモニタ８０は、デバッグ許可証有効性判定部８５により、改竄などが行われているか否かの正当性を検証する（Ｓ１６）。

【0064】

ＲＯＭモニタ８０は、正当性の検証が成功した場合には（Ｓ１６のＹＥＳ）、ＲＯＭモニタ専用記憶領域部４１のデバッグモードフラグ部５０にデバッグモードフラグをセットする（Ｓ１７）。ここで、セットされたデバッグモードフラグは、デバッグモード（デバッグ機能）の有効を示す有効フラグ（１）とする。なお、ＲＯＭモニタ８０は、検証済みのデバッグ許可証をメッセージバッファ部６４から削除する。

【0065】

次に、ＲＯＭモニタ８０は、デバッグモードフラグ部５０のデバッグモードフラグを確認する（Ｓ１８）。ＲＯＭモニタ８０は、有効フラグがセットされていれば（Ｓ１９のＹＥＳ）、デバッグ機能を有効化する（Ｓ２０）。具体的には、マイコン１１は、制御レジスタ３３のデバッグモードレジスタ３４を操作することで、デバッグモードを有効にする。このとき、ＲＯＭモニタ８０が動作中であるため、デバッグモードレジスタ３４に対する書き替えが可能になっている。この後、ＲＯＭモニタ８０は、システムソフト９１を起動することになる（Ｓ２１）。

【0066】

なお、ＲＯＭモニタ８０は、デバッグモードフラグを参照せずに、毎回デバッグ許可証の検証を行う処理も可能である。但し、マイコン１１は起動時間の制約が厳しいため、検証時間を確保できない場合もある。このため、一度、デバッグ許可証が検証された後は、書き込み制限のあるデバッグモードフラグに基づいて制御を行うことが望ましい。

【0067】

ここで、デバッグ許可証の検証では、デバッグ許可証が、(1)改竄されていないこと、(2)想定した正しい管理サーバから発行されていること、(3)再利用されていないことの３項目が確認される。項目(3)は、「リプレイアタック」としてよく知られた攻撃への対策である。リプレイアタックは、以前に送受信されたデータをそのまま再利用することで、なんらかの悪影響を与える攻撃である。リプレイアタック対策が無い場合は、以前に発行されたデバッグ許可証を流用されて、マイコン１１側で本来は拒否されるべきデバッグ（デバッグアクセス）が許可されてしまう可能性がある。デバッグ可否は、直近のマイコン１１の状態を考慮して判断されるべきであり、以前に発行されたデバッグ許可証の流用は回避する必要がある。
[システムソフトの処理]
図１２に示すように、システムソフト９１は起動後に、通常処理以外ではデバッグ許可要求処理を実行する。デバッグ許可要求メッセージとは、管理サーバ１００からデバッグ許可証を取得するためのメッセージである（図１１を参照）。以下、具体的に説明する。

【0068】

システムソフト９１は起動後（Ｓ３０）、システムソフト向け命令判定部９２により、共用記憶領域部４３のシステムソフト向け命令部６３に命令（send-req）が格納されていることを確認すると（Ｓ３１のＹＥＳ）、通常処理以外のデバッグ許可要求処理を実行する。

【0069】

具体的には、システムソフト９１は、共用記憶領域部４３のメッセージバッファ部６４に保存されているデバッグ許可要求メッセージを読み込む（Ｓ３２）。システムソフト９１は、通信部９６のデバッグ許可要求メッセージ送信部９７により、当該デバッグ許可要求メッセージを管理サーバ１００に送信する（Ｓ３３）。

【0070】

後述するように、管理サーバ１００は、デバッグ許可判定部１１０により、デバッグ許可要求メッセージの正当性や内容を確認して、デバッグを許可する場合にはデバッグ許可証をシステムソフト９１に返信する。

【0071】

システムソフト９１は、管理サーバ１００からデバッグ許可証を返信された場合には、通信部９６のデバッグ許可証受信部９８により受信して（Ｓ３４のＹＥＳ）、当該デバッグ許可証を共用記憶領域部４３のメッセージバッファ部６４に保存する（Ｓ３５）。

【0072】

システムソフト９１は、共用記憶領域部４３のシステムソフト向け命令部６３に対して、命令（normal）に書き替えてリセットを実行する。これにより、システムソフト９１は、リセット後に起動した場合に、システムソフト向け命令部６３の命令（normal）に応じて（Ｓ３１のＮＯ）、前述したような通常処理を実行する（Ｓ３６）。システムソフト９１は、リセットされるまで、当該通常処理を継続する（Ｓ３７のＮＯ）。

【0073】

以上のように本実施形態は、システムソフト９１は、通信部９６により、ＲＯＭモニタ８０が作成したデバッグ許可要求メッセージを、いわば代理して管理サーバ１００に送信する構成である。これにより、ＲＯＭモニタ８０は通信機能を付加することなく、相対的に小さく単純なソフトウェア構造を維持できる。一般的に、通信用のコードは可変長のフィールドを扱うため複雑化する。このため、ソフトウェアの脆弱性の原因になることが多い。本実施形態では、ＲＯＭモニタ８０は、デバッグ許可要求メッセージを作成する処理と、デバッグ許可書を検証する処理に集約できることにより、脆弱性の排除が可能になっている。

【0074】

一方、システムソフト９１は、通信処理を行うため、脆弱性を含む確率が高くなる。しかし、システムソフト９１が仮に脆弱であっても、デバッグ制限機能には大きな影響を与えることはない。その理由は、システムソフト９１は、ＲＯＭモニタ８０と管理サーバ１００との間で情報交換の仲介をしているだけで、デバッグ（デバッグアクセス）制限に関する重要な判断処理には関与していないためである。前述したように、デバッグモードへの切り替えは、ＲＯＭモニタ８０が判断している。ＲＯＭモニタ８０は、管理サーバ１００が発行したデバッグ許可証に基づいて判断する。また、不正に改竄されたシステムソフト９１により、悪意をもってデバッグ許可要求メッセージの内容を書き替えられても、管理サーバ１００又はＲＯＭモニタ８０により当該改竄を検出できる。
[デバッグ可否の処理]
図１３は図７に関連し、マイコン１１のデバッグアクセス制限の処理を示すフローチャートである。図１３に示すように、マイコン１１は、外部からデバッガ２０がデバッグポート１２に接続されると（Ｓ４０）、デバッガ２０からのデバッグアクセスに対して、デバッグモードに入って良いか否かの判断を管理サーバ１００に問い合わせる（Ｓ４１）。即ち、マイコン１１は、デバッグ許可要求メッセージを送信して、デバッグ（デバッグアクセス）の可否判断を管理サーバ１００に依頼する。

【0075】

マイコン１１は、管理サーバ１００から送信された判断結果を受信する（Ｓ４２）。マイコン１１は、当該判断結果としてデバッグ許可証を受信すると（Ｓ４３のＹＥＳ）、デバッグ機能（デバッグモード）を有効化する（Ｓ４４）。これにより、マイコン１１は、デバッガ２０からのデバッグアクセスに応じて、システムソフト９１に対するデバッグの実行を許可する（Ｓ４５）。

【0076】

一方、マイコン１１は、当該判断結果としてデバッグ不可を受信すると（Ｓ４３のＮＯ）、デバッグ機能（デバッグモード）を無効化する（Ｓ４６）。これにより、マイコン１１は、デバッガ２０からのデバッグアクセスを切り離し、システムソフト９１に対するデバッグの実行を拒否する（Ｓ４７）。
［システムの連携］
以下、図１４から図１８に示すシーケンス図を参照して、本実施形態の動作を、ＨＷ（ハードウェア機能）、ＲＯＭモニタ８０、システムソフト９１、および管理サーバ１００の連携の観点から説明する。

【0077】

なお、ＨＷは、前述したように、マイコン１１のハードウェア主体で実現される機能を意味し、動作ソフト判定部８００およびデバッグポートアクセス制限部８１０などのソフトウェア機能も含む。さらに、ＨＷは、制御レジスタ３３の初期化や、不揮発性メモリ３６内のプログラムへの制御遷移、電源制御等の機能も含む。

【0078】

図１４から図１８の共通事項として、ＲＯＭモニタ８０とシステムソフト９１との連携により処理では、ＲＯＭモニタ専用記憶領域部４１や共用記憶領域部４３に対する情報又は命令の読み書き動作（readまたはwrite）が実行される。これらの動作については、「read 情報又は命令」、「write 書き込まれる値 to 領域名」の形式で明記している。

【0079】

具体例として、ＲＯＭモニタ８０が共用記憶領域部４３からＲＯＭモニタ向け命令を読み込む際には、矢印を共用記憶領域部４３まで伸ばして、read「ＲＯＭモニタ向け命令」と表記している。同様に、システムソフト９１が共用記憶領域部４３のＲＯＭモニタ向け命令部６０に書き込みを行う際は、矢印を共用記憶領域部４３まで伸ばし、write make-req to「ＲＯＭモニタ向け命令部」と表記している。
[通常処理]
図１４は、ＲＯＭモニタ８０とシステムソフト９１との通常処理における連携を説明するためのシーケンス図である。通常処理では、デバッグアクセス制限に関するセキュリティ関連処理は含まれない。

【0080】

図１４に示すように、初期状態では、共用記憶領域部４３のＲＯＭモニタ向け命令部６０には、システムソフト９１の起動を示す命令（sys-boot）が書き込まれている。また、システムソフト向け命令部６３には、通常処理の実行を示す命令（normal）が書き込まれている。共用記憶領域部４３のメッセージバッファ部６４には、有意な情報は書き込まれていないとする（０クリア又は有意でないことを示す値が書き込まれている状態）。また、ＲＯＭモニタ専用記憶領域部４１のデバッグモードフラグ部５０には、有効フラグがセットされていないＯＦＦ状態とする（単にＯＦＦと表記する）。また、有効フラグがセットされている場合は、単にＯＮと表記する。

【0081】

マイコン１１に電源が投入されると、ＨＷは、制御レジスタ３３を初期化し、デバッグモードレジスタ３４のフラグをＯＦＦ（無効）に設定する。ここで、デバッグモードレジスタ３４のフラグをＯＦＦの場合には、デバッグポートアクセス制限部８１０は接続されるデバッガ２０との通信を拒否し、デバッグアクセスを無効にする。即ち、初期状態では、マイコン１１は、デバッガ２０によるデバッグを実行できない状態である。

【0082】

次に、ＨＷは、ＲＯＭモニタ８０を起動（boot）させて制御を移行する。ＲＯＭモニタ８０は、ＲＯＭモニタ向け命令判定部８１により、共用記憶領域部４３のＲＯＭモニタ向け命令部６０からＲＯＭモニタ向け命令（sys-boot）を読み込む。この命令（sys-boot）は、システムソフト９１を起動させる命令である。

【0083】

次に、ＲＯＭモニタ８０は、デバッグポート設定変更部８６により、ＲＯＭモニタ専用記憶領域部４１のデバッグモードフラグ部５０からフラグを読み込み、デバッグモードフラグのＯＮ又はＯＦＦを確認する。ここでは、デバッグモードフラグはＯＦＦであるため、デバッグモードレジスタ３４を操作しない。

【0084】

ＲＯＭモニタ８０は、命令（sys-boot）に従って、システムソフト起動部８２によりシステムソフト９１を起動させて、システムソフト向け命令を共用記憶領域部４３のシステムソフト向け命令部６３に書き込む。システムソフト９１は、システムソフト向け命令判定部９２により、共用記憶領域部４３のシステムソフト向け命令部６３から読み出した命令（normal）を確認する。

【0085】

システムソフト９１は、命令（normal）に従って、セキュリティ関連処理を実行せずに、マイコン１１の通常処理を実行する。この時、デバッグモードフラグはＯＦＦであるため、マイコン１１は、デバッガ２０によるデバッグを実行できない状態である。
[デバッグ許可要求処理]
図１５は、デバッグ許可要求処理における連携を説明するためのシーケンス図である。本実施形態では、システムソフト９１は、所定のインターフェイスを有し、デバッガ２０が接続された状態で、当該インターフェイスに対する操作をトリガーとして、デバッグの許可を管理サーバ１００に要求する（依頼する）。具体例としては、制御装置１０の基板上のスイッチが操作される、ＵＡＲＴから特定の信号が送信される、WebインターフェイスからPOSTされる等のトリガーである。この場合、車両２００の修理を行うディーラー技術者や、事故原因を究明したいメーカ技術者などが、当該インターフェイスを操作して、マイコン１１をデバッグモードに切り替えることになる。

【0086】

図１５に示すように、システムソフト９１は、管理サーバ１００へのデバッグ許可要求の準備として、ＲＯＭモニタ向け命令変更部９３により、共用記憶領域部４３のＲＯＭモニタ向け命令部６０を命令（make-req）に書き替える。これにより、システムソフト９１は、デバッグ許可要求処理をＲＯＭモニタ８０に移行する。

【0087】

次に、システムソフト９１は、システムソフト情報収集部９４により、図１１に示すようなシステムソフト名、バージョン、および拡張情報を収集して、共用記憶領域部４３のシステムソフト情報部６１に書き込みを実行する。

【0088】

最後に、システムソフト９１は、再起動部９５によりリセットを実行し、デバッグ許可要求の準備処理を終了する。リセット後は、ＲＯＭモニタ８０は、命令（make-req）に従ってデバッグ許可要求メッセージの作成処理を開始する（図１６を参照）。

【0089】

ここで、本実施形態では、シングルＣＰＵのマイコン１１であり、ＲＯＭモニタ８０とシステムソフト９１とを順番に動作させている。システムソフト９１が起動すると、ＲＯＭモニタ８０に遷移する機能は、リセットにより実現されている。一般的に、マイコンでは、リセットが行われると、揮発性メモリ３７やハードウェア設定等がクリアされ、これまでのソフトウェア動作の影響を完全に排除した状態となる。このため、その後に動くソフトウェアは、バグの影響を除けば開発者が想定した通りに動くことが期待できる。

【0090】

本実施形態では、リセット後に動作するソフトウェアは、ＲＯＭモニタ８０である。このため、ＲＯＭモニタ８０が、デバッグに関するセキュリティ関連の処理を実行することで、安全性を確保できる。但し、ＲＯＭモニタ８０は、通信機能を付加することなく、記憶領域の読み書きも可変長になるようなものは排除し、相対的に小さく単純なソフトウェア構造を維持し、脆弱性が排除されていることが望ましい。

【0091】

なお、本実施形態では、リセットが必須の構成であるため、マルチタスクシステムで多用される揮発性メモリ（DRAM、SRAM等）を利用した情報の伝達は不可である。一般的なマルチタスクシステムでは、プロセスやタスク間で情報を伝達する場合には、共有メモリに類する仕組みを使うことが多い。しかし、本実施形態では、システムソフト９１からＲＯＭモニタ８０に処理が移行される場合には、リセットが生じる。このため、揮発性メモリを介して情報をやり取りすることはできない。そこで、ごく単純な命令・情報であっても不揮発性メモリ３６に保存する仕組みとなる。このため、起動した直後のＲＯＭモニタ８０およびシステムソフト９１は、不揮発性メモリ３６を参照して処理すべき案件を判断する。
[デバッグ許可要求メッセージの作成処理]
図１６は、デバッグ許可要求メッセージの作成処理の連携を説明するためのシーケンス図である。

【0092】

前述したシステムソフト９１によるリセットにより、ＨＷは、デバッグモードレジスタ３４のＯＦＦを維持した状態で、ＲＯＭモニタ８０を起動する（boot）。ＲＯＭモニタ８０は、ＲＯＭモニタ向け命令判定部８１により、共用記憶領域部４３のＲＯＭモニタ向け命令部６０から、ＲＯＭモニタ向け命令（make-req）を読み込む。これにより、ＲＯＭモニタ８０は、命令（make-req）に従って、デバッグ許可要求メーセージの作成処理を開始する。

【0093】

なお、ＲＯＭモニタ８０は、ＲＯＭモニタ専用記憶領域部４１のデバッグモードフラグ部５０からフラグを読み込み、デバッグモードフラグがＯＦＦであることを確認する。ここのため、デバッグモードへの切り替えは実行されない。ＲＯＭモニタ８０は、外部の影響を一切受けることなく、以降の処理を進めることになる。

【0094】

次に、ＲＯＭモニタ８０は、システムソフト検証部８３により、システムソフト９１の完全性を検証する。まず、ＲＯＭモニタ８０は、ＲＯＭモニタ専用記憶領域部４１の共通鍵部５２から共通鍵を読み込む。共通鍵（ABCD）は、マイコン１１と管理サーバ１００とが互いに保持している共通の共通鍵である。

【0095】

次に、ＲＯＭモニタ８０は、共用記憶領域部４３のシステムソフト機密情報部６２からハッシュ値を読み込む。ＲＯＭモニタ８０は、システムソフト９１に付随している暗号化済みの想定ハッシュ値を、共通鍵で復号した上で比較する。ＲＯＭモニタ８０は、各ハッシュ値が等しい場合には、システムソフト９１の完全性が検証されたことになり、命令（make-req）を書いたシステムソフト９１の状態は正しいと判定する。

【0096】

これにより、ＲＯＭモニタ８０は、悪意あるデバッグ許可要求ではないと判断して処理を続行する。この場合、システムソフト９１の完全性が検証されたため、システムソフト９１が共用記憶領域部４３のシステムソフト情報部６１に書き込んだ内容も同様に正しいと判定する。なお、ＲＯＭモニタ８０は、各ハッシュ値が不一致の場合には、システムソフト９１が不正に改竄あるいは改造された可能性があるため、デバッグ許可要求メッセージの作成処理を中止する。

【0097】

次に、ＲＯＭモニタ８０は、デバッグ許可要求メッセージ準備部８７の各機能部が連携して当該メッセージの作成準備を開始する。まずは、乱数生成部８８が乱数を生成する。デバッグ許可要求メッセージ準備部８７は、ＲＯＭモニタ専用記憶領域部４１の乱数部５１に保存する（書き込む）。乱数（1234）は、後述するように、デバッグ許可証に対するリプレイ攻撃対策に用いられる。署名部９０は、共通鍵を用いてデバッグ許可要求メッセージ全体に対する電子署名を実行する。デバッグ許可要求メッセージ保存部８９は、図１１に示すようなデバッグ許可要求メッセージを作成し、共用記憶領域部４３のメッセージバッファ部６４に保存する。

【0098】

次に、ＲＯＭモニタ８０は、デバッグ許可要求メッセージの作成処理が完了したことを認識すると、共用記憶領域部４３のＲＯＭモニタ向け命令部６０を命令（sys-boot）に書き替える。これにより、ＲＯＭモニタ８０が再起動した際には、命令（sys-boot）に従って、システムソフト９１を通常通りに起動させる。即ち、再びデバッグ許可要求メッセージを作成する処理を再開することはない。

【0099】

最後に、ＲＯＭモニタ８０は、システムソフト向け命令変更部８４により、共用記憶領域部４３のシステムソフト向け命令部６３を、命令（send-req）に書き替えて、リセットする。この命令（send-req）は、後述するように、デバッグ許可要求メッセージを、ＲＯＭMＲＯＭモニタ８０の代理としてシステムソフト９１に送信させるための命令である。リセット後に起動したシステムソフト９１は、この命令（send-req）により、当該メッセージの送信の依頼があったことを認識する（図１７を参照）。

【0100】

ここで、ＲＯＭモニタ８０は、ＲＯＭモニタ専用記憶領域部４１の乱数部５１に乱数を書き込む。この書き込み処理は、ＨＷの動作ソフト判定部８００の機能により実現される。即ち、動作ソフト判定部８００は、ＲＯＭモニタ８０が動作中であるため、不揮発性メモリ３６のメモリコントローラあるいは制御レジスタ３３に信号を出力して、ＲＯＭモニタ専用記憶領域部４１に対する書き込みが一時的に実行できる状態にしている。この場合、ＲＯＭモニタ８０は、不正な値を書き込むことはない。

【0101】

ここで、ＲＯＭモニタ８０が用意するデバッグ許可要求メッセージ（Msg Debug Req）を式の形式で表現した一例「MsgDebugReq = Body||Sign_m」を示す。但し、「Body = com_debugReq || SN || Ver | Rnd || EInfo，Sign_m = E_K[H[Body]]」である。

【0102】

式の各要素の定義は以下の通りである。即ち、com_debugReqは、デバッグ許可を管理サーバに求めるコマンドである。Kは、管理サーバ１００とマイコン１１とで共有している共通鍵である。SNはシステムソフトの名前(System soft Name)である。Verは、マイコン１１が現在使用しているシステムソフトのバージョン番号である。Rndは乱数である。EInfoは拡張情報である。E_K[A]は、共通鍵KによるデータAの共通鍵ブロック暗号化を意味する。H[X]はデータXに対するハッシュ計算を意味する。||は要素の連結を意味する。例えば、データAとデータBとの連結は、A||Bと表現する。
[管理サーバとの通信処理]
図１７は、管理サーバ１００との通信処理の連携を説明し、管理サーバ１００からデバッグ許可証を取得するまでの処理を示すシーケンス図である。

【0103】

図１７に示すように、前述したＲＯＭモニタ８０によるリセットにより、ＨＷは、デバッグモードレジスタ３４のＯＦＦを維持した状態で、ＲＯＭモニタ８０を起動する（boot）。ＲＯＭモニタ８０は、ＲＯＭモニタ向け命令判定部８１により、共用記憶領域部４３のＲＯＭモニタ向け命令部６０から、ＲＯＭモニタ向け命令（sys-boot）を読み込む。

【0104】

また、ＲＯＭモニタ８０は、デバッグポート設定変更部８６により、ＲＯＭモニタ専用記憶領域部４１のデバッグモードフラグ部５０からフラグを読み込み、デバッグモードフラグがＯＦＦであることを認識する。これにより、ＲＯＭモニタ８０は、システムソフト起動部８２により、デバッグモードが無効である状態のまま、システムソフト９１を起動させる。

【0105】

起動したシステムソフト９１は、システムソフト向け命令判定部９２により、共用記憶領域部４３のシステムソフト向け命令部６３からシステムソフト向け命令（send-req）を読み込み、認識する。システムソフト９１は、命令（send-req）に従って、通信部９６により、共用記憶領域部４３のメッセージバッファ部６４からデバッグ許可要求メッセージを読み込む。

【0106】

次に、システムソフト９１は、デバッグ許可要求メッセージ送信部９７により、当該デバッグ許可要求メッセージを管理サーバ１００に送信する。この場合、システムソフト９１は、接続されている適切な通信経路を使用して、管理サーバ１００との通信処理を実行する。具体例としては、通信サーバが物理的に直結されている場合にはUARTでも良いし、いわゆる有線LANに接続されていればEthernet（登録商標）とTCP/IPを利用いても良い。本実施形態では、前述したように、管理サーバ１００との通信処理は、システムソフト９１側で対応する。一方、ＲＯＭモニタ８０は、通信処理を実行せずに、デバッグ許可要求メッセージの作成処理、および後述するデバッグ許可証の検証処理を実行する。

【0107】

管理サーバ１００は、デバッグ許可判定部１１０により、デバッグ許可要求メッセージの正当性（署名）や内容を確認して、問題が無いかを判定する。管理サーバ１００は、問題が無ければ同様の通信経路でデバッグ許可証を返信し、問題がある場合にはその旨を返信する。

【0108】

ここで、デバッグ許可判定部１１０は、一例として、以下の手順により判定処理を実行する。まず、デバッグ許可判定部１１０は、前述の式の形式で示すデバッグ許可要求メッセージ（Msg Debug Req）から本体部分であるBodyを取り出し、ハッシュ値H[Body]を計算する。次に、署名（Sign_m）を共通鍵Kで復号して、想定ハッシュ値であるD_K[Sign_m]を算出する。ここで、D_K[Y]は、共通鍵KによるYの共通鍵ブロック復号を意味する。

【0109】

デバッグ許可判定部１１０は、両者のハッシュ値を比較して値が等しければ、ＲＯＭモニタ８０が生成した当該メッセージ（Msg Debug Req）を、マイコン１１内及び通信経路上で改竄されていないことを保証することになる。次に、デバッグ許可判定部１１０は、システムソフト９１の名前（SN）の値を調査し、それが想定する名前であり、問題が無ければ処理を進める。

【0110】

デバッグ許可判定部１１０は、複数種類のシステムソフト（マイコン）を管理しており、システムソフト名（SN）で要求元の機種等を判断する。これは出荷時であっても、デバッグ可能マイコンの種類を増減できることを示している。即ち、出荷時にはデバッグを行えないマイコンであっても、状況に応じて管理サーバ１００側の情報を更新すればデバッグ可能にできる余地がある。

【0111】

また、デバッグ許可判定部１１０は、当該メッセージ（Msg Debug Req）のバージョン（Ver）の値も調査する。これも、管理サーバ１００側で想定される値が設定されており、問題がなければ処理を進める。どのバージョンをデバッグ許可対象にするのかは、運用によって様々なものが考えられる。例えば、常に最新ソフトしか利用を認めないという運用方針であれば、古いソフトからデバッグ要求が来ること自体を不正とすることになる。よって、最新のバージョンの値のみが想定値になる。一方、最新版のシステムソフトでは問題がないが、特定バージョンにだけ動作不良が見つかり、調査を行う場合もある。この場合には、特定バージョンの値だけが一時的に想定値として設定されることになる。

【0112】

最後に、デバッグ許可判定部１１０は、当該メッセージ（Msg Debug Req）の拡張情報（EInfo）を調査する。これは、システムソフト名（SN）とバージョン（Ver）では表現できない情報を含む。これも、管理サーバ１００側で想定値を設定することになり、必要に応じて判断材料に用いられる。

【0113】

デバッグ許可判定部１１０は、システムソフト名（SN）、バージョン（Ver）、拡張情報（EInfo）の３情報に問題がなければ、デバッグ許可証（License Debug）を作成して、マイコン１１側に返信する。

【0114】

デバッグ許可証（License Debug）の構成は、式「LicenseDebug = Res || Sign_l」の形式で表現できる。但し、「Res = resp_debug_ok || Rnd， Sign_l = E_K[H[Res]]」である。

【0115】

ここで、乱数（Rnd）は管理サーバ１００が新たに生成したものではなく、デバッグ許可要求メッセージ（Msg Debug Req）に含まれていたものをそのままコピーしたものである。また、resp_debug_okは、デバッグを許可したことを示す返答（デバッグ許可証）を意味する。一方、resp_degun_ngは、デバッグを許可しないことを示す返答を意味することになる。即ち、デバッグ許可判定部１１０は、デバッグ許可要求メッセージ（Msg Debug Req）に問題があり、デバッグ許可証が発行できない場合には、返答（resp_degun_ng）を返信することになる。

【0116】

システムソフト９１は、管理サーバ１００からデバッグ許可証（License Debug）を返信された場合には、通信部９６のデバッグ許可証受信部９８により受信して、共用記憶領域部４３のメッセージバッファ部６４に保存する（書き込む）。システムソフト９１は、管理サーバ１００との通信処理が完了したことを認識すると、共用記憶領域部４３のシステムソフト向け命令部６３を命令（normal）に書き替えてリセットを実行する。これにより、システムソフト９１は、次回の起動時に通常処理を開始し、管理サーバ１００との通信処理を実行しない。
［デバッグ許可証の検証処理］
図１８は、デバッグ許可証の検証処理の連携を説明し、デバッグモードの有効化してデバッグを許可するまでの処理を示すシーケンス図である。

【0117】

図１８に示すように、前述したシステムソフト９１によるリセットにより、ＨＷは、デバッグモードレジスタ３４のＯＦＦを維持した状態で、ＲＯＭモニタ８０を起動する（boot）。ＲＯＭモニタ８０は、ＲＯＭモニタ向け命令判定部８１により、共用記憶領域部４３のＲＯＭモニタ向け命令部６０から、ＲＯＭモニタ向け命令（sys-boot）を読み込み、認識する。これにより、ＲＯＭモニタ８０は、デバッグ許可要求メッセージの作成処理ではなく、デバッグ許可証の検証処理を開始し、最終的にはシステムソフト９１を起動させる処理を進める。

【0118】

ＲＯＭモニタ８０は、共用記憶領域部４３のメッセージバッファ部６４から、デバッグ許可証を読み出す。ＲＯＭモニタ８０は、デバッグ許可証有効性判定部８５により、デバッグ許可証の有効性を検証する処理を開始する。具体的には、以下の手順で有効性を検証する。

【0119】

ＲＯＭモニタ８０は、ＲＯＭモニタ専用記憶領域部４１の共通鍵部５２から共通鍵（K）を読み出す。次に、ＲＯＭモニタ８０は、前述の式の形式であるデバッグ許可証（License Debug）から、レスポンス本体（Res）を取り出して、ハッシュ値H[Res]を計算する。次に、署名（Sign_l）を共通鍵（K）で復号して、想定ハッシュ値（D_K[Sign_l]）を算出する。この両者を比較して値が等しければ、ＲＯＭモニタ８０は、デバッグ許可証が改竄されていないこと、および想定する送信者である管理サーバ１００が返答したものであることを検証する。

【0120】

但し、この検証により確認できた内容は、「過去に管理サーバ１００がデバッグを許可したことがある」という事実までである。この事実だけで、デバッグ許可を与えてしまうと、過去に発行したデバッグ許可証を何度も再利用するというリプレイアタックを許してしまうことになる。即ち、一度でもデバッグが許可されたシステムソフトが永遠にデバッグ可能となる恐れがある。デバッグの可否判断は、直近の状況に応じて、その都度行われるべきであり、対策が必要となる。

【0121】

本実施形態では、ＲＯＭモニタ８０は、デバッグ許可証有効性判定部８５により、リプレイアタック対策として、以下の手順で検証処理を実行する。

【0122】

まず、ＲＯＭモニタ８０は、ＲＯＭモニタ専用記憶領域部４１の乱数部５１から乱数（1234）を読み込む。ＲＯＭモニタ８０は、当該乱数と、デバッグ許可証（License Debug）の本体（Res）に含まれる乱数（Rnd）との比較を行う。ＲＯＭモニタ８０は、両者が一致した場合には、リプレイアタックされていないと判断する。一方、両者が一致しない場合には、リプレイアタックされているとして、デバッグ許可証そのものを不正なものと判断する。

【0123】

以下、判断の根拠を説明する。ＲＯＭモニタ専用記憶領域部４１の乱数部５１に保存されている乱数（1234）は、デバッグ許可要求メッセージを作成する際に、ＲＯＭモニタ８０が保存しておいた値である。このため、ＲＯＭモニタ８０が直近で作成した当該メッセージには、必ず同じ乱数の値が使われていることになる。一方、管理サーバ１００は、この乱数を取り出して、そのままデバッグ許可証にコピーする（埋め込む）処理を行っている。このため、管理サーバ１００から返信されたデバッグ許可証に、その乱数が含まれているならば、時間的に近いタイミングで作成されたものであると推測することができる。

【0124】

ＲＯＭモニタ８０は、デバッグ許可証の検証処理が完了し、かつ、デバッグ許可を示す命令（resp_debug_ok）が含まれていれば、正当性の検証が成功したものと判断する。ＲＯＭモニタ８０は、デバッグポート設定変更部８６により、ＲＯＭモニタ専用記憶領域部４１のデバッグモードフラグ部５０にデバッグモードフラグをＯＮ（有効）にセットする。

【0125】

次に、ＲＯＭモニタ８０は、検証済みのデバッグ許可証をメッセージバッファ部６４から削除する。さらに、ＲＯＭモニタ８０は、制御レジスタ３３のデバッグモードレジスタ３４のデバッグモードを有効（ＯＮ）にしてデバッグ機能を有効化する。これにより、デバッグポートアクセス制限部８１０は、接続されたデバッガ２０との通信（デバッグアクセス）を許可する。この後、ＲＯＭモニタ８０は、システムソフト９１を起動する。従って、外部のデバッガ２０により、マイコン１１のシステムソフト９１をデバッグできる状態となる。

【0126】

ここで、次回以降、ＲＯＭモニタ８０は、起動する毎にＲＯＭモニタ専用記憶領域部４１のデバッグモードフラグ部５０をアクセスして、デバッグモードフラグの内容を確認することになる。この場合、デバッグ許可証の判定なしに、デバッグモードが有効（ＯＮ）になっている。デバッグモードフラグの有効な状態が永続化するのは問題であるため、前述したように、ＲＯＭモニタ専用記憶領域部４１にはデバッグ可能回数部５３が設けられている。デバッグ可能回数は、デバッグモードフラグを有効にした際に値がセットされる。その後は、マイコン１１がデバッグモードで起動する度に値を減らしていく。デバッグ可能回数が「０」になった時点で、ＲＯＭモニタ８０は、デバッグモードフラグを無効にして、デバッグ許可証の再取得を再開する。

【0127】

デバッグ可能回数として設定する値は、マイコン１１の用途に依存して設定する。例えば、ネットワーク環境の悪い場所で運用されるマイコン１１を想定するのであれば、デバッグ可能回数を多めにしないと、必要なタイミングでデバッグできない可能性がある。一方、デバッグを厳しく制限したいマイコン１１の場合には、デバッグ可能回数の値を「１」に設定して、デバッグ要求がある度に、デバッグ許可証の発行が必要となるようにしてもよい。

【0128】

以上のように本実施形態によれば、低コストのシングルＣＰＵコアを主要素とするマイコンにおいて、外部からの不正なデバッグに対して、有効なデバッグアクセス制限を確実に行うことができるデバッグアクセス制限機能を実現できる。これにより、悪意のある外部からマイコンのソフトウェアを不正に動作・解析し、または改竄されるような事態を未然に防止することができる。

【0129】

さらに、本実施形態は、セキュリティ性の高いＲＯＭモニタにより、外部からのデバッグ要求に応じて、マイコンとは異なるコンピュータである管理サーバに対してデバッグの可否判断を依頼する。ＲＯＭモニタは、管理サーバからのデバッグ許可証に基づいて、マイコンのデバッグ機能の有効化または無効化の処理を実行する。

【0130】

即ち、管理サーバ側へのデバッグ可否判断の権限を分離する構成を実現することにより、低コストのマイコンの場合でも、外部に対するセキュリティ面を確保すると共に、確実なデバッグアクセス制限機能を実現できる。また、デバッグ可否判断を管理サーバ側が行うため、当該管理サーバの運用側が、マイコンが組み込まれた製品の出荷後でも、マイコンのデバッグ状況を一元管理できる。

【0131】

なお、本実施形態は、車両に搭載されるマイコンに適用する場合について説明したが、これに限ることなく、例えば家庭用電気機器や医療機器などに組み込まれるマイコンにも適用できる。
[変形例]
図２０は、本実施形態の変形例に関するブロック図である。本変形例は、図８に示す本実施形態のマイコン１１の機能において、ＨＷに含まれる周辺回路としてＡ／Ｄコンバータ制御部８２０およびＲＯＭモニタ８０に含まれる機密情報消去部８３０を付加した構成である。なお、他の構成については、本実施形態と同様であるため、説明を省略する。

【0132】

本変形例のＡ／Ｄコンバータ制御部８２０および機密情報消去部８３０はいずれも、マイコン１１内の機密情報の流出を防止することを目的とした構成要素である。ここで、本変形例では、マイコン１１内の機密情報としては、ＲＯＭモニタ専用記憶領域部４１の共通鍵、および共用記憶領域部４３のシステムソフト機密情報部６２に格納されているシステムソフト機密情報の２種類の情報とする。

【0133】

共通鍵は、本実施形態の各処理を実行する際のセキュリティ上の観点から、安全性の担保を確保するために重要である。本実施形態では、安全性の高いＲＯＭモニタ８０だけが共通鍵の読み込み権限を持つと共に、共通鍵がそのままの形式で外部に保存される処理を含まないため、共通鍵が流出する可能性は極めて低い。一方で、共通鍵はマイコン出荷前に書き込まれて、基本的には更新は想定されていないため、流出した際の影響が大きい。
また、システムソフト機密情報は、システムソフト９１の通常処理中に保存される情報の中で、流出の影響が大きいものである。例えば、ユーザが利用しているＩＤやパスワード、動作ログ（音声データ、顔の画像等）が代表例である。これらの中には、デバッグ時であっても、オペレータに見せるべきではない情報が含まれる可能性がある。よって、システムソフト９１の設計者は、事前にシステムソフト機密情報を意識した設計を行うことになる。

【0134】

以下、マイコン１１内の機密情報の流出を防止するための手順を説明する。

【0135】

まず、機密情報として共通鍵が使用されている場合に、共通鍵が流出する経路としては電力解析時のマイコン１１からの出力である。電力解析とは、本来ソフトウェア的には取得が困難な情報を、電気的な特徴を解析することで推測する処理である。具体的には、マイコン１１内おいて、共通鍵による署名検証処理が行われている際に、マイコン１１の電力消費量やノイズを測定することで、その測定値の出力時に共通鍵の値が漏出する可能性がある。よって、マイコン１１が共通鍵を使用して計算処理中には、外部に電力解析に伴う測定をさせない工夫が望ましい。

【0136】

そこで、本変形例では、Ａ／Ｄコンバータ制御部８２０は、ＲＯＭモニタ８０による共通鍵の操作が行われている間（例えば、暗号化ユニット３８の動作中）、マイコン１１からの出力により電力解析を行うための回路の動作を停止させる。電力解析を行うための代表例となる回路としては、Ａ／Ｄコンバータが外部インターフェイスとして接続されていることがある。即ち、Ａ／Ｄコンバータを経由して、例えばマイコン１１の演算処理の内容が不正に取得される可能性がある。

【0137】

そこで、本変形例では、Ａ／Ｄコンバータ制御部８２０は、外部インターフェイスに対する電源を遮断して、Ａ／Ｄコンバータの動作を停止させる。但し、Ａ／Ｄコンバータに限らず、外部インターフェイスとして接続されている他の回路の場合でも、マイコン１１が共通鍵を使用して計算処理中には、動作を停止させる制御部が必要である。

【0138】

さらに、マイコン１１において、システムソフト９１が運用されている場合は、通常処理に伴いシステムソフト機密情報を共用記憶領域部４３のシステムソフト機密情報部６２に保存することがある。この保存後に、要請に従って、例えば、ＲＯＭモニタ８０がデバッグモードフラグを有効にする処理を実行する場合には、ＲＯＭモニタ８０の機密情報消去部８３０は、システムソフト機密情報部６２の内容を直ちに消去する。これにより、デバッグを行うオペレータに対しても、システムソフト機密情報部６２からの機密情報が漏出するような事態を防止できる。

【0139】

なお、ＲＯＭモニタ８０の単純性を維持するために、システムソフト機密情報部６２は固定長である。よって、システムソフトが保存するシステムソフト機密情報の容量によっては、システムソフト機密情報部６２の容量が不足する可能性がある。この場合には、システムソフト９１は独自にシステムソフト機密情報を暗号化し、その際に使う鍵のみをシステムソフト機密情報部６２に保存する運用を実行してもよい。これにより、デバッグ時には、その鍵が確実に削除されて、暗号化しておいたシステムソフト機密情報を復元することができなくなる。システムソフトの通常処理向けに用意されている不揮発性メモリ３６の容量は、システムソフト機密情報部６２と比較して大きいため、当該運用により機密情報の容量には実用上の制限がなくなる。

【0140】

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【符号の説明】

【0141】

１０…制御装置、１１…マイコン、１２…デバッグポート、
１３…無線通信部、１４…有線通信部、１５…入出力インターフェイス、
１６，１７…通信インターフェイス、２０…デバッガ、
２１…アクチュエータ駆動回路、３０…命令実行ユニット、
３１…動作ソフト判定ユニット、３２…デバッグユニット、３３…制御レジスタ、
３４Ａ…動作ソフトレジスタ、３４Ｂ…デバッグモードレジスタ、
３５…通信ユニット、３６…不揮発性メモリ、３７…揮発性メモリ（ＲＡＭ）、
３８…暗号化ユニット、３９…乱数生成ユニット、
８０…ＲＯＭモニタ、９１…システムソフト、１００…管理サーバ、
２００…車両、３００…ネットワーク。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】