JP2020107237A - 情報処理装置 - Google Patents

Abstract

【課題】誤検知による悪影響を抑えつつ、情報処理装置を用いて制御されるシステムをサイバー攻撃から安全に守る。【解決手段】ソフトウェアを更新可能な情報処理装置２は、ソフトウェアの更新可否を制御するための制御情報である更新ステータスフラグ２８１を記憶する更新制御情報記憶部２８と、通信バス４を介して接続された他の情報処理装置１，３から送信される通信メッセージを受信する通信部２１と、通信部２１が受信した通信メッセージに基づいて更新ステータスフラグ２８１を更新する更新制御部２２と、更新ステータスフラグ２８１に基づいてソフトウェアの更新可否を判定する更新可否判定部２３と、を備える。【選択図】図１

Description

本発明は、情報処理装置に関する。

近年、自動車に搭載される車載システムは、インターネット、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ−Ｆｉ等の通信回線を介して車外のサーバや情報処理装置と繋がることにより、ユーザに様々なサービスを提供するようになりつつある。これに伴い、従来の閉じた車載システムとは異なり、外部からのセキュリティサイバー攻撃に対する備えが重要になってきている。さらに、このような車載システムでは、ＯＳＳ（Open Source Software）の活用や、セキュリティが担保されていないスマートフォン等の情報処理装置との接続も検討されている。そのため、これまで以上に脆弱性を悪用されたセキュリティサイバー攻撃が懸念されつつある。

一般的にセキュリティ対策では、脅威のリスクを減らすために設計段階で対策を検討する「事前対策」、運用段階で顕在化する脅威を検知する「侵入検知」、顕在化した脅威による被害を最小化する「事後対処」の３つの観点により、設計から運用にわたって対象システムの保護資産を守ることが有効と考えられている。特に、事後対処を適切に行うためには、サイバー攻撃者の侵入を確実に検知できることが重要である。一般的な情報システムにおける外部からの不正な侵入を検知する仕組みとしては、例えばＩＤＳ（Intrusion Detection System）やＩＰＳ（Intrusion Prevention System）が利用されている。

プラントや工場で使用される統合生産システムのセキュリティ対策に関して、例えば下記の特許文献１の技術が知られている。特許文献１には、プラントに構築された統合生産システムにおいて、前記統合生産システムに対するサイバー攻撃を検知する検知手段の検知結果に基づいて、サイバー攻撃の対象及び種別を特定し、特定したサイバー攻撃の対象及び種別に応じた対策手段を実行する制御装置が開示されている。

特開２０１７−１１１５３２号公報

特許文献１の技術では、サイバー攻撃を正しく検知できることが前提となっており、事象に応じた適切な事後対処を実行できるか否かはサイバー攻撃の検知精度に依存する。このため、サイバー攻撃を誤検知した場合、本来は事後対処が必要ない状況であっても、事後対処として全通信機能の停止やシステムシャットダウン等が実行されてしまい、システムの可用性に大きな悪影響を及ぼす恐れがある。特に、車載システムでは異常発生時に自動車をなるべく安全な状態に維持する必要があるため、異常を検知した場合の事後対処として、縮退運転や緊急停車等の緊急対処が行われることが多い。このため、特許文献１の技術を車載システムに適用すると、サイバー攻撃に対する誤検知率（ＦＰＲ：False Positive Rate）が高い場合、実際にはサイバー攻撃が発生していなくても縮退運転や緊急停車が頻繁に実行されてしまい、車両の可用性が大きく低下するという悪影響を生じるおそれがある。

本発明は、以上の問題に鑑みなされたものであり、情報処理装置を用いて制御されるシステムにおいて、誤検知による悪影響を抑えつつ、システムをサイバー攻撃から安全に守ることを目的とする。

本発明による情報処理装置は、ソフトウェアを更新可能なものであって、前記ソフトウェアの更新可否を制御するための制御情報を記憶する記憶部と、通信回線を介して接続された他の情報処理装置から送信される通信メッセージを受信する通信部と、前記通信部が受信した前記通信メッセージに基づいて前記制御情報を更新する更新制御部と、前記制御情報に基づいて前記ソフトウェアの更新可否を判定する更新可否判定部と、を備える。

本発明によれば、誤検知による悪影響を抑えつつ、情報処理装置を用いて制御されるシステムをサイバー攻撃から安全に守ることができる。

本発明の第１の実施形態に係るソフトウェア更新制御用セキュリティシステムの構成を示す図 本発明の第１の実施形態に係るソフトウェア更新制御用セキュリティシステムにおける全体処理シーケンスの一例を示す図 通信監視識別処理のフローチャート ステータス更新処理のフローチャート ソフトウェア更新制御処理のフローチャート ステータス回復処理のフローチャート 通信検証情報のデータ構造の例を示す図 更新ステータスフラグのデータ構造の例を示す図 装置ステータス情報のデータ構造の例を示す図 本発明の第２の実施形態に係るソフトウェア更新制御用セキュリティシステムの構成を示す図 本発明の第２の実施形態に係るソフトウェア更新制御用セキュリティシステムにおける全体処理シーケンスの一例を示す図

以下、本発明の実施形態について、図面を参照しながら詳細に説明する。

以下の実施形態では、車両に搭載されてソフトウェアを更新可能な情報処理装置が、他の情報処理装置から受信する特定の通信メッセージに基づいて、ソフトウェアの更新可否を示すフラグを更新し、このフラグに基づいてソフトウェアの更新可否を判定する方法の例を説明する。ただし、本発明の技術的思想は、この例に限定されるものではない。なお、各装置間及び車外との通信は、暗号技術などを用いた安全な通信路を利用することが好ましい。また、各装置で利用する暗号用の鍵及びシードは、安全に配布、管理、更新されていることが好ましく、エンジン起動時／停止時、製品開発時、メンテナンス時などの任意のタイミングで配布や更新が行なわれてもよい。

（第１の実施形態）
図１は、本発明の第１の実施形態に係るソフトウェア更新制御用セキュリティシステムの構成を示す図である。図１のソフトウェア更新制御用セキュリティシステムは、それぞれ一つまたは複数の情報処理装置１、情報処理装置２、情報処理装置３が通信バス４を介して互いに接続されることにより構成されている。なお、情報処理装置１，２および３は、例えば車両に搭載されるＥＣＵ（Electronic Control Unit）であり、車内の通信バス４を介して他の装置にも接続されている。ただし通信バス４は、物理的には複数の通信バスで構成されており、これらの通信バスの規格はすべて同一でもよいし異なっていてもよい。これら通信バスの規格は、例えばＣＡＮ（登録商標）、ＬＩＮ（登録商標）、ＦｌｅｘＲａｙ（登録商標）、イーサネット（登録商標）などである。

情報処理装置１，２および３は、不図示のＣＰＵ、不図示のＲＯＭ、および不図示のＲＡＭをそれぞれ備え、ＲＯＭに格納されたプログラムをＣＰＵがＲＡＭに展開して実行することにより、以下の機能をそれぞれ実現する。

情報処理装置１は、その機能として、通信部１１、通信検証部１２、検証結果通知部１３を備える。また、フラッシュメモリ等の記録媒体を用いて構成された通信判定情報記憶部１４を備える。

通信部１１は、通信バス４を介して他の情報処理装置から送信される通信メッセージを受信するとともに、通信バス４を介して他の情報処理装置に対して通信メッセージを送信する。前述のとおり通信バス４は物理的に複数の通信バスから構成されているため、通信部１１はこの物理的な通信バスと同数の接続ポートを有する。

通信検証部１２は、通信部１１が受信した通信メッセージの検証を行い、システム上で何らかの事後対処が必要な事象が発生した場合にはこれを検知する。例えば、通信部１１が受信した通信メッセージに基づき、不正なサイバー攻撃の予兆が発生した場合にはこれを検知する。具体的には、例えばアドレススキャン、ポートスキャン、不正メッセージ受信、不正ファイル生成、不正プロセス起動等のサイバー攻撃によって生じる事象を、サイバー攻撃の予兆として検知する。また、他の情報処理装置において禁止動作の発生が検知されたことを示す通信メッセージを通信部１１が受信した場合は、この通信メッセージに基づいて禁止動作の発生を検知する。例えば、ソフトウェアの更新が禁止されている状態でソフトウェアの更新依頼が行われた場合、これを禁止動作として検知する。

検証結果通知部１３は、通信検証部１２による通信メッセージの検証結果を他の情報処理装置に通知する。例えば、通信検証部１２によって不正なサイバー攻撃の予兆が検知された場合は、通信部１１を用いて所定の通信メッセージを他の情報処理装置に送信することにより、サイバー攻撃の予兆が発生したことを通知するとともに、ソフトウェア更新の禁止などの事後対処を指示する。また、通信検証部１２によって禁止動作の発生が検知された場合は、通信部１１を用いて所定の通信メッセージを他の情報処理装置に送信することにより、禁止動作の発生を通知するとともに、縮退運転や緊急停車などの事後対処を指示する。

通信判定情報記憶部１４には、受信した通信メッセージを通信検証部１２が検証するために用いられる通信検証情報１４１が記憶されている。通信検証部１２は、この通信検証情報１４１を参照することで、通信メッセージの検証を行う。

情報処理装置２は、その機能として、通信部２１、更新制御部２２、更新可否判定部２３、更新認証部２４、更新実行部２５、状態検証部２６、状態管理部２７を備える。また、フラッシュメモリ等の記録媒体を用いて構成された更新制御情報記憶部２８を備える。

通信部２１は、通信バス４を介して他の情報処理装置から送信される通信メッセージを受信するとともに、通信バス４を介して他の情報処理装置に対して通信メッセージを送信する。前述のとおり通信バス４は物理的に複数の通信バスから構成されているため、通信部２１はこの物理的な通信バスと同数の接続ポートを有する。

更新制御部２２は、通信部２１が受信した通信メッセージに基づいて、更新制御情報記憶部２８に記憶されている更新ステータスフラグ２８１を更新する。この更新ステータスフラグ２８１は、情報処理装置２のソフトウェアの更新可否を制御するためのフラグ情報である。

更新可否判定部２３は、更新ステータスフラグ２８１に基づいてソフトウェアの更新可否を判定する。

更新認証部２４は、通信部２１が他の情報処理装置から通信メッセージとして所定の認証依頼メッセージを受信した場合に、その情報処理装置の認証処理を実行する。例えば、正規のソフトウェア更新プロトコルに従って送信された認証依頼メッセージであるか否かを確認することで、その認証依頼メッセージが正しいものであるか否かを判定する。

更新実行部２５は、情報処理装置２のソフトウェアの更新を実行する。例えば、ＵＤＳ（Unified Diagnosis Services、ＩＳＯ１４２２９）プロトコルに基づく処理を実行することで、ソフトウェアの更新を行う。

状態検証部２６は、ある任意のタイミングで、情報処理装置２が不正なサイバー攻撃による影響を受けているかどうかを検証する。この状態検証のタイミングには、例えば車両の起動時や、通信部２１が予め決められた通信メッセージを受信した時などが設定される。また、所定の周期で状態検証を繰り返し実行してもよい。

状態管理部２７は、更新制御情報記憶部２８に記憶されている更新ステータスフラグ２８１および装置ステータス情報２８２を用いて、情報処理装置２の状態を管理する。

更新制御情報記憶部２８には、情報処理装置２におけるソフトウェアの更新可否の状態を示す更新ステータスフラグ２８１と、情報処理装置２の状態を示す装置ステータス情報２８２とが記憶されている。更新可否判定部２３は、この更新ステータスフラグ２８１を参照することで、ソフトウェアの更新可否の判定を行う。

情報処理装置３は、情報処理装置１および２と接続され、情報処理装置１および２と通信バス４を介して様々な通信メッセージを送受信する。なお、情報処理装置３は、情報処理装置１または２のいずれかと同様の機能を有してもよい。あるいは、情報処理装置１と２の両方の機能を有してもよい。

図２は、本発明の第１の実施形態に係るソフトウェア更新制御用セキュリティシステムにおける全体処理シーケンスの一例を示す図である。なお、以下に説明する各ステップの実行主体は、各情報処理装置が有する不図示のＣＰＵである。

ステップ１０１において、情報処理装置１は、通信部１１により通信バス４を介して他の情報処理装置から送信される通信メッセージを受信する。

ステップ１０２において、情報処理装置１は、通信検証部１２により、上記ステップ１０１で受信した通信メッセージの検証を行う。ここでは、受信した通信メッセージが禁止動作の発生やサイバー攻撃の予兆の発生を示しているかを検証する。図２の例では、ステップ１０１で受信した通信メッセージから、ステップ１０２でサイバー攻撃の予兆が検知され、これに対する事後対処として、ソフトウェアの更新を禁止することが決定される。

ステップ１０３において、情報処理装置１は、検証結果通知部１３により、上記ステップ１０２での検証結果を通信バス４を介して他の情報処理装置に通知する。図２の例では、ステップ１０２でサイバー攻撃の予兆への事後対処として決定されたソフトウェア更新の禁止を指示するための所定の通信メッセージを、通信部１１を用いて情報処理装置２に送信する。

ステップ２０１において、情報処理装置２は、通信部２１により、上記ステップ１０３で情報処理装置１から送信された通信メッセージ、すなわち、サイバー攻撃の予兆の発生に対する事後対処としてソフトウェア更新の禁止を指示する通信メッセージを、通信バス４を介して受信する。

ステップ２０２において、情報処理装置２は、状態管理部２７により、更新制御情報記憶部２８に記憶されている更新ステータスフラグ２８１を確認し、ソフトウェアの更新可否状況を判断する。図２の例では、更新ステータスフラグ２８１が未更新であり、ソフトウェアの更新を許可するステータスである「更新許可」を表しているものとする。

ステップ２０３において、情報処理装置２は、更新制御部２２により、上記ステップ２０１で受信した通信メッセージと、上記ステップ２０２での更新ステータスフラグ２８１の確認結果とに基づいて、情報処理装置２のステータスを更新する。図２の例では、受信した通信メッセージがサイバー攻撃の予兆の発生を示す通信メッセージであり、かつ、更新ステータスフラグ２８１が未更新であるため、これらに従って更新ステータスフラグ２８１を変更する。これにより、情報処理装置２のステータスを、ソフトウェアの更新を許可するステータスである「更新許可」から、更新を許可しないステータスである「更新不可」に更新する。

ステップ２０４において、情報処理装置２は、状態管理部２７により、更新制御情報記憶部２８に記憶されている更新ステータスフラグ２８１および装置ステータス情報２８２の内容に基づき、現在の情報処理装置２のステータスを通信バス４を介して他の情報処理装置に通知する。図２の例では、上記ステップ２０３で変更された更新ステータスフラグ２８１に従い、情報処理装置２のステータスが「更新不可」であることを通知するための所定の通信メッセージを、通信部１１を用いて情報処理装置１に送信する。

ステップ３０において、情報処理装置３は、正規のソフトウェア更新プロトコルに従って、認証依頼を通知するための所定の通信メッセージを情報処理装置２に送信することで、情報処理装置２に対してソフトウェアの更新を指示する。

ステップ２０５において、情報処理装置２は、通信部２１により、上記ステップ３０で情報処理装置３から送信された認証依頼の通信メッセージを、通信バス４を介して受信する。

ステップ２０６において、情報処理装置２は、更新可否判定部２３により、更新制御情報記憶部２８に記憶されている更新ステータスフラグ２８１に基づいて、ソフトウェアの更新可否を判定する。図２の例では、上記ステップ２０３で更新ステータスフラグ２８１が「更新不可」に変更されているため、ステップ２０５で情報処理装置３から受信した通知メッセージが示すソフトウェアの更新指示を禁止動作の発生として検知し、ソフトウェアの更新を不可と判定する。

ステップ２０７において、情報処理装置２は、状態管理部２７により、上記ステップ２０６での判定結果に基づいて、情報処理装置２のステータスを更新する。図２の例では、ステップ２０６で禁止動作の発生が検知され、これに従ってソフトウェアの更新が不可であると判定されている。こうした判定結果を装置ステータス情報２８２に反映させることで、情報処理装置２のステータスを更新する。

ステップ２０８において、情報処理装置２は、状態管理部２７により、更新制御情報記憶部２８に記憶されている更新ステータスフラグ２８１および装置ステータス情報２８２の内容に基づき、現在の情報処理装置２のステータスを通信バス４を介して他の情報処理装置に通知する。図２の例では、上記ステップ２０７で変更された装置ステータス情報２８２に従い、情報処理装置２が禁止動作の発生を検知したことを通知するための所定の通信メッセージを、通信部２１を用いて情報処理装置１に送信する。

ステップ１０４において、情報処理装置１は、通信部１１により通信バス４を介して、上記ステップ２０８で情報処理装置２から送信された通信メッセージを受信する。

ステップ１０５において、情報処理装置１は、通信検証部１２により、上記ステップ１０４で受信した通信メッセージの検証を行う。ここでは上記ステップ１０２と同様に、受信した通信メッセージが禁止動作の発生やサイバー攻撃の予兆の発生を示しているかを検証する。図２の例では、ステップ１０４で受信した通信メッセージから、ステップ１０５で禁止動作の発生が検知され、これに対する事後対処として、縮退運転や緊急停車を行うことが決定される。

ステップ１０６において、情報処理装置１は、検証結果通知部１３により、上記ステップ１０５での検証結果を通信バス４を介して他の情報処理装置に通知する。図２の例では、ステップ１０５で禁止動作への事後対処として決定された縮退運転や緊急停車を指示するための所定の通信メッセージを、通信部１１を用いて情報処理装置２に送信する。

ステップ２０９において、情報処理装置２は、上記ステップ１０６で情報処理装置１から送信された通信メッセージを通信バス４を介して受信し、この通信メッセージに基づいて、車両の縮退運転や緊急停車を実施するための所定の制御モードに移行する。

本実施形態のソフトウェア更新制御用セキュリティシステムでは、以上の各ステップにより、セキュリティに対する不正なサイバー攻撃の予兆を検知した場合に、情報処理装置２におけるソフトウェアの更新を禁止する。さらに、当該禁止期間においてソフトウェアの更新に関る動作を検知した場合に、縮退運転や緊急停車などの緊急対処を情報処理装置２に実行させ、自動車を安全な状態で維持できるようにする。

次に、図２の処理シーケンスの詳細について、図３〜図５および図７〜図９を参照して以下に説明する。

図３は、図２のステップ１０１からステップ１０５において情報処理装置１が実行する通信監視識別処理のフローチャートである。

ステップ３０１において、情報処理装置１は、図２のステップ１０１、１０４で説明したように、通信バス４を介して他の情報処理装置から送信される通信メッセージを通信部１１により受信する。

ステップ３０２において、情報処理装置１は、通信検証部１２により、図２のステップ１０２、１０５で説明したように、通信判定情報記憶部１４に記憶されている通信検証情報１４１に基づいて、ステップ３０１で受信した通信メッセージの検証を行う。すなわち、受信した通信メッセージが「禁止動作の発生」や「サイバー攻撃の予兆の発生」に該当するかどうかを検証する。

図７は、上記ステップ３０２において通信検証部１２が通信メッセージの検証に用いる通信検証情報１４１のデータ構造の例を示す図である。図７に示すように、通信検証情報１４１は、例えば検証ＩＤ１４１１と、通信種別１４１２と、該当通信ＩＤ一覧１４１３とを含んで構成される。検証ＩＤ１４１１は、通信検証情報１４１を構成する各レコードを識別するための情報であり、レコードごとに固有の値が設定されている。通信種別１４１２は、通信メッセージの種別を示す情報であり、これは検証対象の通信メッセージがどのような事象に該当するかを表している。該当通信ＩＤ一覧１４１３は、通信メッセージに含まれる通信ＩＤの一覧を示す情報である。

通信検証部１２は、通信検証情報１４１に含まれるこれらの情報を通信部１１が受信した通信メッセージと照合することで、受信した通信メッセージがどの事象に該当するかを判断することができる。例えば、上記ステップ３０１で受信した通信メッセージにおける通信ＩＤの値が「０ｘ００１」の場合、この値が該当通信ＩＤ一覧１４１３に含まれているのは、検証ＩＤ１４１１の値が「Ｖ１」のレコードである。したがって、このレコードに紐づけられた通信種別１４１２の内容から、受信した通信メッセージが「禁止動作の発生」を示しており、ソフトウェアの更新が禁止されている状態でソフトウェアの更新依頼が行われたと判断することができる。

図３の説明に戻ると、ステップ３０３において、通信検証部１２は、上記ステップ３０２で行った通信メッセージの検証結果に基づいて、禁止動作を検知したか否かを判定する。禁止動作を検知した場合はステップ３０４に進み、それ以外の場合はステップ３０５に進む。

ステップ３０４において、情報処理装置１は、検証結果通知部１３により、ステップ３０２で検知した禁止動作への事後対処として、縮退運転や緊急停車への移行を依頼する通知を行う。ここでは図２のステップ１０６で説明したように、通信部１１により通信バス４を介して、縮退運転や緊急停車を指示する所定の通信メッセージを送信することで、他の各情報処理装置に対して禁止動作への事後対処を指示する。

ステップ３０５において、通信検証部１２は、上記ステップ３０２で行った通信メッセージの検証結果に基づいて、不正なサイバー攻撃の予兆を検知したか否かを判定する。攻撃の予兆を検知した場合はステップ３０６に進み、それ以外の場合はステップ３０７に進む。

ステップ３０６において、情報処理装置１は、検証結果通知部１３により、ステップ３０２で検知したサイバー攻撃の予兆への事後対処として、所定の更新制御を依頼する通知を行う。ここでは図２のステップ１０３で説明したように、通信部１１により通信バス４を介して、ソフトウェア更新の禁止を指示する所定の通信メッセージ（更新制御依頼メッセージ）を送信することで、他の各情報処理装置に対して攻撃の予兆への事後対処を指示する。

ステップ３０７において、通信検証部１２は、通信部１１により受信される通信メッセージを継続して監視する継続監視状態に移行する。

ステップ３０４、３０６、３０７のいずれかを実行したら、情報処理装置１は図３の処理を終了する。

以上の処理により、情報処理装置１は、受信した通信メッセージを検証し、その検証結果に基づいて、事象に応じた事後対処を他の情報処理装置に通知できる。なお、情報処理装置１は、検証結果の通知先に情報処理装置１自身を含めてもよい。また、通信検証情報１４１において、攻撃の予兆と禁止動作以外の事象も通信種別１４１２に含めることで、通信検証部１２がこれらの事象についても事後対象を要する事象として検証できるようにしてもよい。

図４は、図２のステップ２０１からステップ２０４において情報処理装置２が実行するステータス更新処理のフローチャートである。

ステップ４０１において、情報処理装置２は、図２のステップ２０１で説明したように、通信バス４を介して情報処理装置１から送信される更新制御依頼メッセージ、すなわち更新ステータスフラグ２８１を更新してソフトウェア更新の禁止を依頼する通信メッセージを、通信部２１により受信する。

ステップ４０２において、情報処理装置２は、図２のステップ２０２で説明したように、状態管理部２７により、更新制御情報記憶部２８に記憶されている更新ステータスフラグ２８１を確認し、ソフトウェアの更新可否状況を判断する。

図８は、上記ステップ４０２において状態管理部２７が確認する更新ステータスフラグ２８１のデータ構造の例を示す図である。図８に示すように、更新ステータスフラグ２８１は、例えばフラグ値２８１１を含んで構成される。フラグ値２８１１は、ソフトウェアの更新が許可されているか禁止されているかを示す情報である。フラグ値２８１１が「０」の場合は、ソフトウェアの更新が許可されている、すなわち情報処理装置２のステータスが「更新許可」であることを表し、「１」の場合は、ソフトウェアの更新が禁止されている、すなわち情報処理装置２のステータスが「更新不可」であることを表す。

状態管理部２７は、更新ステータスフラグ２８１に含まれるこの情報を確認することで、情報処理装置２におけるソフトウェアの更新可否状況を判断することができる。すなわち、フラグ値２８１１が「０」の場合はソフトウェアの更新が許可されていると判断し、「１」の場合は禁止されていると判断することができる。

図４の説明に戻ると、ステップ４０３において、情報処理装置２は、上記ステップ４０２で確認した最新の更新ステータスフラグ２８１に基づいて、情報処理装置２のステータスが「更新許可」と「更新不可」のいずれであるかを判定する。すなわち、フラグ値２８１１が「０」の場合は「更新許可」と判定してステップ４０４に進み、フラグ値２８１１が「１」の場合は更新不可状態と判定してステップ４０５に進む。これにより、通信部２１が通信メッセージとして更新制御依頼メッセージを受信した場合であっても、情報処理装置２において過去に下記のステップ４０４が実行されたことにより、更新ステータスフラグ２８１のフラグ値２８１１を「０」から「１」に更新済みである場合は、ステップ４０４を実行せずに更新ステータスフラグ２８１を更新しないようにする。

ステップ４０４において、情報処理装置２は、更新制御部２２により、更新ステータスフラグ２８１を更新する。ここでは、更新ステータスフラグ２８１のフラグ値２８１１を「０」から「１」に更新することで、図２のステップ２０３で説明したように、更新ステータスフラグ２８１が表す情報処理装置２のステータスを「更新許可」から「更新不可」に変更する。

ステップ４０５において、情報処理装置２は、更新制御部２２により、装置ステータス情報２８２を更新する。ここでは、ステップ４０３の判定結果に従って、装置ステータス情報２８２にログを記録する。

図９は、上記ステップ４０５において更新制御部２２がログを記録する装置ステータス情報２８２のデータ構造の例を示す図である。図９に示すように、装置ステータス情報２８２は、例えば装置ステータスＩＤ２８２１と、ステータス種別２８２２と、発生回数２８２３とを含んで構成される。装置ステータスＩＤ２８２１は、装置ステータス情報２８２を構成する各レコードを識別するための情報であり、レコードごとに固有の値が設定されている。ステータス種別２８２２は、ステータスの種別を示す情報であり、これは情報処理装置２がどのような状態であるかを表している。発生回数２８２３は、当該ステータスの発生回数を示す情報である。なお、装置ステータス情報２８２にこれ以外の情報、例えば時刻情報や検知箇所等の補足情報を追加してもよい。

更新制御部２２は、装置ステータス情報２８２に含まれるこれらの情報のうち、ステップ４０３の判定結果に応じた情報を書き換えることで、情報処理装置１からの更新制御依頼に対する処理結果をログとして記録する。例えば、ステップ４０３で「更新許可」と判定された場合、ステップ４０４で更新ステータスフラグ２８１が更新されることにより、情報処理装置２のステータスが「更新許可」から「更新不可」に変更される。この場合は、ステータス種別２８２２が「更新ステータスフラグの更新」を示しているレコード、すなわち装置ステータスＩＤ２８２１が「Ｄ５」であるレコードを特定し、このレコードの発生回数２８２３の値に「１」を加算した値を登録する。一方、ステップ４０３で「更新不可」と判定された場合、ステップ４０４が実行されずに更新ステータスフラグ２８１が更新されない。この場合は、ステータス種別２８２２が「更新ステータスフラグアクセス拒否」を示しているレコード、すなわち装置ステータスＩＤ２８２１が「Ｄ３」であるレコードを特定し、このレコードの発生回数２８２３値に「１」を加算した値を登録する。

図４の説明に戻ると、ステップ４０６において、情報処理装置２は、図２のステップ２０４で説明したように、状態管理部２７により、上記ステップ４０４が実行された場合に更新された更新ステータスフラグ２８１と、上記ステップ４０５で更新された装置ステータス情報２８２とに基づいて、現在の情報処理装置２のステータスを示す任意の情報を通信バス４を介して情報処理装置１に送信する。例えば、任意の情報として更新ステータスフラグ２８１の値のみを送信してもよいし、装置ステータス情報２８２の一部を送信してもよい。

ステップ４０６を実行したら、情報処理装置２は図４の処理を終了する。

以上の処理により、情報処理装置２は、情報処理装置１から通知された検証結果に基づいて、ソフトウェアの更新可否を制御するための更新ステータスフラグ２８１の内容を更新することができる。また、一度でも更新ステータスフラグ２８１が更新されたら、その後は更新ステータスフラグ２８１をそのままの状態に維持することができる。

図５は、図２のステップ２０５からステップ２０８において情報処理装置２が実行するソフトウェア更新制御処理のフローチャートである。

ステップ５０１において、情報処理装置２は、図２のステップ２０５で説明したように、通信バス４を介して情報処理装置３から送信される所定の通信メッセージ（認証依頼メッセージ）を、ソフトウェアの更新を指示する通信メッセージとして、通信部２１により受信する。

ステップ５０２において、情報処理装置２は、図２のステップ２０６で説明したように、更新可否判定部２３により、更新制御情報記憶部２８に記憶されている更新ステータスフラグ２８１を参照し、これに基づいてソフトウェアの更新可否を判定する。例えば、図８の更新ステータスフラグ２８１におけるフラグ値２８１１を参照し、フラグ値２８１１が「０」であれば、ソフトウェアの更新を許可すると判定する。すなわち、上記ステップ４０４で更新制御部２２によって更新ステータスフラグ２８１のフラグ値２８１１が一度も「０」から「１」に更新されていない場合は、ソフトウェアの更新を許可すると判定する。一方、フラグ値２８１１が「１」であれば、ソフトウェアの更新を許可しないと判定する。すなわち、上記ステップ４０４で更新制御部２２によって更新ステータスフラグ２８１のフラグ値２８１１が一度でも「０」から「１」に更新された場合は、ソフトウェアの更新を許可しないと判定する。

ステップ５０３において、情報処理装置２は、更新可否判定部２３により、上記ステップ５０２の判定結果に基づいて、ソフトウェアの更新が可能か否かを判定する。ステップ５０２でソフトウェアの更新を許可すると判定された場合は、ソフトウェアの更新が可能であると判定してステップ５０４に進む。一方、ステップ５０２でソフトウェアの更新を許可しないと判定された場合は、ソフトウェアの更新が不可であると判定してステップ５０７に進む。

ステップ５０４において、情報処理装置２は、更新認証部２４により、ステップ５０１で通信部２１が受信した認証依頼メッセージによって認証を依頼してきた情報処理装置３に対する認証処理を実施する。このときの認証処理としては、任意の処理を実行できる。例えば機器認証、受信したメッセージの認証、署名検証等のうちいずれか一つまたは複数の処理を、認証処理として実施することができる。

ステップ５０５において、情報処理装置２は、更新認証部２４により、上記ステップ５０４で実施した認証処理の結果に基づいて、情報処理装置３が認証をパスしたか否かを判定する。認証処理において情報処理装置３が正規の装置であると認証された場合は、認証をパスしたと判定してステップ５０６に進み、そうでないと判断された場合は、認証をパスしなかったと判定してステップ５０７に進む。

ステップ５０６において、情報処理装置２は、更新実行部２５により、所定の手順に基づいてソフトウェアの更新処理を実行する。ステップ５０６でソフトウェアの更新を完了したら、ステップ５０８に進む。

ステップ５０７において、情報処理装置２は、状態管理部２７により、上記ステップ５０３またはステップ５０５の判定結果に基づいて、装置ステータス情報２８２を更新する。例えば、ステップ５０３でソフトウェアの更新が不可であると判定した場合は、図９の装置ステータス情報２８２において、ステータス種別２８２２が「更新不可」を示しているレコード、すなわち装置ステータスＩＤ２８２１が「Ｄ２」であるレコードを特定し、このレコードの発生回数２８２３の値に「１」を加算した値を登録する。また例えば、ステップ５０５で情報処理装置３が認証をパスしなかったと判定した場合は、図９の装置ステータス情報２８２において、ステータス種別２８２２が「認証失敗」を示しているレコード、すなわち装置ステータスＩＤ２８２１が「Ｄ１」であるレコードを特定し、このレコードの発生回数２８２３の値に「１」を加算した値を登録する。ステップ５０７で装置ステータス情報２８２を更新したら、ステップ５０８に進む。

ステップ５０８において、情報処理装置２は、図２のステップ２０７で説明したように、状態管理部２７により、更新ステータスフラグ２８１および装置ステータス情報２８２に基づいて、現在の情報処理装置２のステータスを示す任意の情報を通信バス４を介して情報処理装置１に送信する。ここでは図４のステップ４０６と同様に、例えば、任意の情報として更新ステータスフラグ２８１の値のみを送信してもよいし、装置ステータス情報２８２の一部を送信してもよい。

ステップ５０８を実行したら、情報処理装置２は図５の処理を終了する。

以上の処理により、情報処理装置２は、情報処理装置３からのソフトウェアの更新指示に対して、更新ステータスフラグ２８１に基づいて、ソフトウェアの更新可否を判定することができる。

次に、更新された更新ステータスフラグ２８１を元に戻す場合の処理について説明する。上記図４の処理では、情報処理装置２において更新ステータスフラグ２８１が一度でも更新されると、その後は更新ステータスフラグ２８１がそのままの状態に維持されることで、ソフトウェアの更新が禁止された状態のままとなる。以下では、図６に示すステータス回復処理のフローチャートを参照して、任意のタイミングで情報処理装置２がサイバー攻撃による影響を受けているかどうかを検証し、サイバー攻撃による影響を受けていない場合は、更新ステータスフラグ２８１を元に戻して、ソフトウェアの更新を再び許可する場合を説明する。

ステップ６０１において、情報処理装置２は、状態検証の要求を検知する。例えば、車両の起動時や、通信バス４を介して情報処理装置１から送信される所定の通信メッセージを通信部２１により受信したとき、一定周期など、任意のタイミングで状態検証の要求が行われたと判断し、これを検知する。

ステップ６０２において、情報処理装置２は、状態検証部２６により、ステップ６０１で検知した状態検証の要求に応じて、情報処理装置２が不正なサイバー攻撃による影響を受けているかどうかの検証を行う。ここでは、例えば所定のセキュアブート処理を実行し、情報処理装置２が改ざんされていないことを検証することで、サイバー攻撃による影響の有無を検証する。

ステップ６０３において、情報処理装置２は、上記ステップ６０２で実施した検証結果に基づいて、情報処理装置２における異常の有無を判定する。ステップ６０２の検証によって情報処理装置２が改ざんされていないことを確認できた場合は、「異常なし」と判定してステップ６０４に進み、確認できなかった場合は「異常あり」と判定してステップ６０５に進む。

ステップ６０４において、情報処理装置２は、更新制御部２２により、更新ステータスフラグ２８１を更新する。ここでは、更新ステータスフラグ２８１のフラグ値２８１１を「１」から「０」に更新することで、更新ステータスフラグ２８１が表す情報処理装置２のステータスを、図４のステップ４０４において更新済みの状態である「更新不可」から更新前の状態である「更新許可」に戻す。ただし、更新ステータスフラグ２８１のフラグ値２８１１が「０」である場合は、更新せずにそのままとする。

ステップ６０５において、情報処理装置２は、更新制御部２２により、装置ステータス情報２８２を更新する。ここでは、ステップ６０３の判定結果に従って、装置ステータス情報２８２にログを記録する。例えば、ステップ６０３で「異常なし」と判定された場合、ステップ６０４で更新ステータスフラグ２８１が更新されることにより、情報処理装置２のステータスが「更新不可」から「更新許可」に変更される。この場合は、ステータス種別２８２２が「更新ステータスフラグの更新」を示しているレコード、すなわち装置ステータスＩＤ２８２１が「Ｄ５」であるレコードを特定し、このレコードの発生回数２８２３の値に「１」を加算した値を登録する。一方、ステップ６０３で「異常あり」と判定された場合は、ステータス種別２８２２が「状態検証異常あり」を示しているレコード、すなわち装置ステータスＩＤ２８２１が「Ｄ４」であるレコードを特定し、このレコードの発生回数２８２３の値に「１」を加算した値を登録する。

ステップ６０６において、情報処理装置２は、状態管理部２７により、更新ステータスフラグ２８１および装置ステータス情報２８２に基づいて、現在の情報処理装置２のステータスを示す任意の情報を通信バス４を介して情報処理装置１に送信する。ここでは図４のステップ４０６や図５のステップ５０８と同様に、例えば、任意の情報として更新ステータスフラグ２８１の値のみを送信してもよいし、装置ステータス情報２８２の一部を送信してもよい。

ステップ６０６を実行したら、情報処理装置２は図６の処理を終了する。

以上の処理により、情報処理装置２は、任意のタイミングで、情報処理装置２がサイバー攻撃による影響を受けているかどうかを検証し、その検証結果に応じて、ソフトウェアの更新を再び許可するか否かを決定することができる。

以上説明した第１の実施形態によれば、ソフトウェア更新制御用セキュリティシステムは、例えば情報処理装置２を車両制御系のＥＣＵとした場合に、このＥＣＵを狙ったサイバー攻撃に対して有効に対処することができる。すなわち、情報処理装置２では、ソフトウェアの更新認証を行う更新認証部２４とは別に、更新制御部２２および更新可否判定部２３により、更新制御情報記憶部２８に記憶された更新ステータスフラグ２８１を用いて、サイバー攻撃の予兆が検知された段階でソフトウェアの更新を禁止する。また、ソフトウェアの更新を禁止している期間において、ソフトウェアの更新指示等の禁止動作を検知した場合は、縮退運転や緊急停車などの緊急対処に移行する。これにより、サイバー攻撃者によって正規ソフトウェア更新プロトコルが破られたとしても、不正なソフトウェアの更新を防止することができる。また、サイバー攻撃の予兆が誤検知の場合でも、一時的にソフトウェアの更新ができないだけで、走行制御に影響を与えずに自動車を安全な状態に維持することができる。

以上説明した本発明の第１の実施形態によれば、以下の作用効果を奏する。

（１）ソフトウェアを更新可能な情報処理装置２は、ソフトウェアの更新可否を制御するための制御情報である更新ステータスフラグ２８１を記憶する更新制御情報記憶部２８と、通信バス４を介して接続された他の情報処理装置１，３から送信される通信メッセージを受信する通信部２１と、通信部２１が受信した通信メッセージに基づいて更新ステータスフラグ２８１を更新する更新制御部２２と、更新ステータスフラグ２８１に基づいてソフトウェアの更新可否を判定する更新可否判定部２３と、を備える。このようにしたので、誤検知による悪影響を抑えつつ、情報処理装置２を用いて制御される自動車等のシステムをサイバー攻撃から安全に守ることができる。

（２）更新制御部２２は、通信部２１が通信メッセージとして、更新ステータスフラグ２８１の更新を依頼する所定の更新制御依頼メッセージを他の情報処理装置１から受信した場合（ステップ４０１）に、更新ステータスフラグ２８１を更新する（ステップ４０４）。このようにしたので、適切なタイミングで更新ステータスフラグ２８１を更新することができる。

（３）更新制御部２２は、通信部２１が通信メッセージとして更新制御依頼メッセージを受信した場合であっても、更新ステータスフラグ２８１を更新済みである場合（ステップ４０３：Ｎｏ）は、更新ステータスフラグ２８１を更新しない。このようにしたので、一度でも更新ステータスフラグ２８１を更新して情報処理装置２のステータスを「更新不可」に設定した後は、その状態を確実に維持することができる。

（４）更新可否判定部２３は、更新制御部２２により更新ステータスフラグ２８１が一度も更新されていない場合は、ソフトウェアの更新を許可すると判定し、更新制御部２２により更新ステータスフラグ２８１が一度でも更新された場合は、ソフトウェアの更新を許可しないと判定する（ステップ５０２）。このようにしたので、サイバー攻撃の発生の予兆がある場合に、ソフトウェアが不正に更新されてしまうことを確実に防止できる。

（５）情報処理装置２は、不正な攻撃による影響の有無を検証する状態検証部２６をさらに備える。更新制御部２２は、状態検証部２６による検証結果に基づいて、更新済みの更新ステータスフラグ２８１を更新前の状態に戻す（ステップ６０２〜６０４）。このようにしたので、サイバー攻撃の発生の予兆を検知して一度ソフトウェアの更新を禁止した後でも、サイバー攻撃による影響を受けていないことが確認できた場合は、ソフトウェアの更新を再び許可して可用性を回復することができる。

（６）更新可否判定部２３は、通信部２１が通信メッセージとして、ソフトウェアの更新を依頼する所定の認証依頼メッセージを他の情報処理装置３から受信した場合（ステップ５０１）に、更新ステータスフラグ２８１に基づいてソフトウェアの更新可否を判定する（ステップ５０２）。このようにしたので、適切なタイミングでソフトウェアの更新可否を判定することができる。

（７）情報処理装置２は、通信部２１が通信メッセージとして認証依頼メッセージを受信した場合に、他の情報処理装置３の認証処理を実行する更新認証部２４と、ソフトウェアの更新を実行する更新実行部２５と、をさらに備える。更新実行部２５は、更新可否判定部２３がソフトウェアの更新を許可すると判定し（ステップ５０３：Ｙｅｓ）、かつ、更新認証部２４が実行した認証処理において他の情報処理装置３が正規の装置であると認証された場合（ステップ５０５：Ｙｅｓ）に、ソフトウェアの更新を実行する（ステップ５０６）。このようにしたので、なりすまし等の不正な手段でソフトウェアが更新されてしまうことを確実に防止できる。

（８）情報処理装置２は、更新制御部２２により更新ステータスフラグ２８１が更新された後、通信部２１が通信メッセージとして所定の禁止メッセージを受信した場合（ステップ３０３：Ｙｅｓ）に、制御モードを所定の縮退モードに切り替える（ステップ３０４）。このようにしたので、不正なサイバー攻撃の攻撃を受けた場合でも、自動車を安全な状態に維持することができる。

（第２の実施形態）
図１０は、本発明の第２の実施形態に係るソフトウェア更新制御用セキュリティシステムの構成を示す図である。図１０のソフトウェア更新制御用セキュリティシステムは、それぞれ一つまたは複数の情報処理装置２Ａ、情報処理装置３が通信バス４を介して互いに接続されることにより構成されている。なお、第１の実施形態と同様に、情報処理装置２Ａおよび３は、例えば車両に搭載されるＥＣＵ（Electronic Control Unit）であり、車内の通信バス４を介して他の装置にも接続されている。ただし通信バス４は、物理的には複数の通信バスで構成されており、これらの通信バスの規格はすべて同一でもよいし異なっていてもよい。

情報処理装置２Ａは、第１の実施形態で説明した情報処理装置２と比べて、情報処理装置１と同様の機能をさらに有する点が異なっている。具体的には、通信検証部１２および検証結果通知部１３をさらに有する点と、更新制御情報記憶部２８に替えて情報記憶部２８Ａを有し、この情報記憶部２８Ａには更新ステータスフラグ２８１および装置ステータス情報２８２に加えて、さらに通信検証情報１４１が記憶されている点とが異なっている。なお、通信検証部１２、検証結果通知部１３および通信検証情報１４１は、第１の実施形態で説明したのとそれぞれ同様のものである。

図１１は、本発明の第２の実施形態に係るソフトウェア更新制御用セキュリティシステムにおける処理シーケンスの一例を示す図である。なお、図１１では、第１の実施形態で説明した図２と同じ内容の処理に対して、図２と共通のステップ番号を付している。また、各ステップの実行主体は、情報処理装置２Ａが有する不図示のＣＰＵである。

ステップ１０１において、情報処理装置２Ａは、通信部２１により通信バス４を介して他の情報処理装置から送信される通信メッセージを受信する。

ステップ１０２において、情報処理装置２Ａは、通信検証部１２により、上記ステップ１０１で受信した通信メッセージの検証を行う。ここでは、受信した通信メッセージが禁止動作の発生やサイバー攻撃の予兆の発生を示しているかを検証する。図１１の例では、ステップ１０１で受信した通信メッセージから、ステップ１０２でサイバー攻撃の予兆が検知され、これに対する事後対処として、ソフトウェアの更新を禁止することが決定される。

上記ステップ１０２でソフトウェアの更新を禁止することが決定されると、ステップ２０２において、情報処理装置２Ａは、状態管理部２７により、更新制御情報記憶部２８に記憶されている更新ステータスフラグ２８１を確認し、ソフトウェアの更新可否状況を判断する。図１１の例では、更新ステータスフラグ２８１が未更新であり、ソフトウェアの更新を許可するステータスである「更新許可」を表しているものとする。

ステップ２０３において、情報処理装置２Ａは、更新制御部２２により、上記ステップ１０２での検証結果と、上記ステップ２０２での更新ステータスフラグ２８１の確認結果とに基づいて、情報処理装置２Ａのステータスを更新する。図１１の例では、検証結果としてソフトウェアの更新禁止が決定され、かつ、更新ステータスフラグ２８１が未更新であるため、これらに従って更新ステータスフラグ２８１を変更する。これにより、情報処理装置２Ａのステータスを、ソフトウェアの更新を許可するステータスである「更新許可」から、更新を許可しないステータスである「更新不可」に更新する。

なお、図１１の例では上記のとおりであるが、ステップ１０２の検証結果としてソフトウェアの更新禁止が決定されなかった場合や、ステップ２０２で更新ステータスフラグ２８１が更新済みであることが確認された場合は、ステップ２０３において、更新ステータスフラグ２８１を更新せずにそのままとする。

ステップ２０５〜２０７では、図２と同様の処理をそれぞれ実施する。

ステップ１０５において、情報処理装置２Ａは、通信検証部１２により、上記ステップ２０５で受信した通信メッセージの検証を行う。ここでは上記ステップ１０２と同様に、受信した通信メッセージが禁止動作の発生やサイバー攻撃の予兆の発生を示しているかを検証する。図１１の例では、ステップ２０５で受信した認証依頼の通信メッセージにより、ステップ２０６で禁止動作の発生が検知されている。そのため、ステップ１０５では禁止動作の発生に対する事後対処として、縮退運転や緊急停車を行うことが決定される。

ステップ２０９において、情報処理装置２Ａは、上記ステップ１０５で決定された事後対処に従って、車両の縮退運転や緊急停車を実施するための所定の制御に移行する。

本実施形態のソフトウェア更新制御用セキュリティシステムでは、以上の各ステップにより、第１の実施形態と同様に、セキュリティに対する不正なサイバー攻撃の予兆を検知した場合に、情報処理装置２Ａにおけるソフトウェアの更新を禁止する。さらに、当該禁止期間においてソフトウェアの更新に関る動作を検知した場合に、縮退運転や緊急停車などの緊急対処を実行し、自動車を安全な状態で維持できるようにする。

以上説明した本発明の第２の実施形態によれば、第１の実施形態で説明した（１）、（４）〜（８）に加えて、さらに以下の作用効果を奏する。

（９）情報処理装置２Ａは、通信部２１が受信した通信メッセージに基づいて不正な攻撃の予兆を検知する通信検証部１２をさらに備える。更新制御部２２は、通信検証部１２が不正な攻撃の予兆を検知した場合に、更新ステータスフラグ２８１を更新する（ステップ２０３）。このようにしたので、サイバー攻撃の予兆が発生した場合に、ソフトウェアが不正に更新されてしまうことを防止するため、更新ステータスフラグ２８１を確実に更新することができる。

（１０）更新制御部２２は、通信検証部１２が不正な攻撃の予兆を検知した場合であっても、更新ステータスフラグ２８１を更新済みである場合は、ステップ２０３で更新ステータスフラグ２８１を更新しない。このようにしたので、第１の実施形態と同様に、一度更新ステータスフラグ２８１を更新して情報処理装置２Ａのステータスを「更新不可」に設定した後は、その状態を確実に維持することができる。

なお、以上説明した各実施形態や各種変形例はあくまで一例であり、発明の特徴が損なわれない限り、本発明はこれらの内容に限定されるものではない。また、上記では種々の実施形態や変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

１，２，２Ａ，３：情報処理装置
４：通信バス
１１：通信部
１２：通信検証部
１３：検証結果通知部
１４：通信判定情報記憶部
２１：通信部
２２：更新制御部
２３：更新可否判定部
２４：更新認証部
２５：更新実行部
２６：状態検証部
２７：状態管理部
２８：更新制御情報記憶部
２８Ａ：情報記憶部
１４１：通信検証情報
２８１：更新ステータスフラグ
２８２：装置ステータス情報

Claims (10)

1. ソフトウェアを更新可能な情報処理装置であって、
   前記ソフトウェアの更新可否を制御するための制御情報を記憶する記憶部と、
   通信回線を介して接続された他の情報処理装置から送信される通信メッセージを受信する通信部と、
   前記通信部が受信した前記通信メッセージに基づいて前記制御情報を更新する更新制御部と、
   前記制御情報に基づいて前記ソフトウェアの更新可否を判定する更新可否判定部と、を備える情報処理装置。
2. 請求項１に記載の情報処理装置において、
   前記更新制御部は、前記通信部が前記通信メッセージとして、前記制御情報の更新を依頼する所定の更新制御依頼メッセージを前記他の情報処理装置から受信した場合に、前記制御情報を更新する情報処理装置。
3. 請求項２に記載の情報処理装置において、
   前記更新制御部は、前記通信部が前記通信メッセージとして前記更新制御依頼メッセージを受信した場合であっても、前記制御情報を更新済みである場合は、前記制御情報を更新しない情報処理装置。
4. 請求項１に記載の情報処理装置において、
   前記通信部が受信した前記通信メッセージに基づいて不正な攻撃の予兆を検知する通信検証部をさらに備え、
   前記更新制御部は、前記通信検証部が前記不正な攻撃の予兆を検知した場合に、前記制御情報を更新する情報処理装置。
5. 請求項４に記載の情報処理装置において、
   前記更新制御部は、前記通信検証部が前記不正な攻撃の予兆を検知した場合であっても、前記制御情報を更新済みである場合は、前記制御情報を更新しない情報処理装置。
6. 請求項１から請求項５のいずれか一項に記載の情報処理装置において、
   前記更新可否判定部は、
   前記更新制御部により前記制御情報が一度も更新されていない場合は、前記ソフトウェアの更新を許可すると判定し、
   前記更新制御部により前記制御情報が一度でも更新された場合は、前記ソフトウェアの更新を許可しないと判定する情報処理装置。
7. 請求項６に記載の情報処理装置において、
   不正な攻撃による影響の有無を検証する状態検証部をさらに備え、
   前記更新制御部は、前記状態検証部による検証結果に基づいて、更新済みの前記制御情報を更新前の状態に戻す情報処理装置。
8. 請求項１から請求項５のいずれか一項に記載の情報処理装置において、
   前記更新可否判定部は、前記通信部が前記通信メッセージとして、前記ソフトウェアの更新を依頼する所定の認証依頼メッセージを前記他の情報処理装置から受信した場合に、前記制御情報に基づいて前記ソフトウェアの更新可否を判定する情報処理装置。
9. 請求項８に記載の情報処理装置において、
   前記通信部が前記通信メッセージとして前記認証依頼メッセージを受信した場合に、前記他の情報処理装置の認証処理を実行する更新認証部と、
   前記ソフトウェアの更新を実行する更新実行部と、をさらに備え、
   前記更新実行部は、前記更新可否判定部が前記ソフトウェアの更新を許可すると判定し、かつ、前記更新認証部が実行した前記認証処理において前記他の情報処理装置が正規の装置であると認証された場合に、前記ソフトウェアの更新を実行する情報処理装置。
10. 請求項１から請求項５のいずれか一項に記載の情報処理装置において、
    前記更新制御部により前記制御情報が更新された後、前記通信部が前記通信メッセージとして所定の禁止メッセージを受信した場合に、制御モードを所定の縮退モードに切り替える情報処理装置。

Images