(57)【特許請求の範囲】
【請求項１】
制御対象データを内部に保持する機器であって、
前記機器の現在のライフサイクル状態が何であるかを管理する状態管理手段と、
認証データを受け付けて利用者を認証し所属するグループを応答する利用者認証手段と、
前記制御対象データに対してアクセス要求があった場合に、前記状態管理手段から現在のライフサイクル状態を取得し、前記利用者認証手段で認証を行ってグループを取得し、前記制御対象データと対応付けられた状態アクセス制御ポリシーから現在のライフサイクル状態とアクセス要求を行った利用者のグループに基づいてアクセス可否情報を取得し、当該アクセス可否情報に基づいて前記制御対象データに対するアクセスの可否を判断するアクセス制御手段と
を備え、
前記状態管理手段は、
固定のライフサイクル状態と、
いずれかの固定のライフサイクル状態を親とする追加、変更または削除が可能なライフサイクル状態であって、前記固定のライフサイクル状態より強いアクセス制御の権限を持たない変動するライフサイクル状態と、
を管理し、
前記アクセス制御手段は、前記固定のライフサイクル状態について前記アクセスの可否を判断し、アクセス可と判断された場合、前記変動するライフサイクル状態について前記アクセスの可否をさらに判断する
ことを特徴とする機器。
【請求項２】
請求項１に記載の機器において、
前記利用者認証手段は、固定のグループに加え、固定のグループを親とする追加、変更または削除が可能な追加のグループを管理する
ことを特徴とする機器。
【請求項３】
請求項１または２のいずれか一項に記載の機器において、
前記状態管理手段は、ライフサイクル状態に対応付けた、状態変化をするための遷移条件、状態変化をする際に強制する処理の定義、次の状態に遷移した際に強制する処理の定義のいずれかもしくは複数を含む状態データを管理する
ことを特徴とする機器。
【請求項４】
請求項１乃至３のいずれか一項に記載の機器において、
前記状態管理手段は、人為的な操作入力または自動的な検出動作をトリガとしてライフサイクル状態の変化を行う
ことを特徴とする機器。
【請求項５】
請求項１乃至４のいずれか一項に記載の機器において、
他の機器と通信を行う場合に認証により正しい機器であることを判断する認証手段
を備えたことを特徴とする機器。
【請求項６】
制御対象データを内部に保持する機器に搭載される管理モジュールであって、
前記機器の現在のライフサイクル状態が何であるかを管理する状態管理手段と、
認証データを受け付けて利用者を認証し所属するグループを応答する利用者認証手段と、
前記制御対象データに対してアクセス要求があった場合に、前記状態管理手段から現在のライフサイクル状態を取得し、前記利用者認証手段で認証を行ってグループを取得し、前記制御対象データと対応付けられた状態アクセス制御ポリシーから現在のライフサイクル状態とアクセス要求を行った利用者のグループに基づいてアクセス可否情報を取得し、当該アクセス可否情報に基づいて前記制御対象データに対するアクセスの可否を判断するアクセス制御手段と
を備え、
前記状態管理手段は、
固定のライフサイクル状態と、
いずれかの固定のライフサイクル状態を親とする追加、変更または削除が可能なライフサイクル状態であって、前記固定のライフサイクル状態より強いアクセス制御の権限を持たない変動するライフサイクル状態と、
を管理し、
前記アクセス制御手段は、前記固定のライフサイクル状態について前記アクセスの可否を判断し、アクセス可と判断された場合、前記変動するライフサイクル状態について前記アクセスの可否をさらに判断する
ことを特徴とする管理モジュール。
【請求項７】
制御対象データを内部に保持する機器に搭載される管理モジュールを構成するコンピュータを、
前記機器の現在のライフサイクル状態が何であるかを管理する状態管理手段、
認証データを受け付けて利用者を認証し所属するグループを応答する利用者認証手段、及び
前記制御対象データに対してアクセス要求があった場合に、前記状態管理手段から現在のライフサイクル状態を取得し、前記利用者認証手段で認証を行ってグループを取得し、前記制御対象データと対応付けられた状態アクセス制御ポリシーから現在のライフサイクル状態とアクセス要求を行った利用者のグループに基づいてアクセス可否情報を取得し、当該アクセス可否情報に基づいて前記制御対象データに対するアクセスの可否を判断するアクセス制御手段
として機能させ、
前記状態管理手段は、
固定のライフサイクル状態と、
いずれかの固定のライフサイクル状態を親とする追加、変更または削除が可能なライフサイクル状態であって、前記固定のライフサイクル状態より強いアクセス制御の権限を持たない変動するライフサイクル状態と、
を管理し、
前記アクセス制御手段は、前記固定のライフサイクル状態について前記アクセスの可否を判断し、アクセス可と判断された場合、前記変動するライフサイクル状態について前記アクセスの可否をさらに判断する
プログラム。
【請求項８】
制御対象データを内部に保持する機器に搭載される管理モジュールを構成するコンピュータが実行する制御方法であって、
前記機器の現在のライフサイクル状態が何であるかを管理する状態管理工程と、
認証データを受け付けて利用者を認証し所属するグループを応答する利用者認証工程と、
前記制御対象データに対してアクセス要求があった場合に、前記状態管理工程により現在のライフサイクル状態を取得し、前記利用者認証工程により認証を行ってグループを取得し、前記制御対象データと対応付けられた状態アクセス制御ポリシーから現在のライフサイクル状態とアクセス要求を行った利用者のグループに基づいてアクセス可否情報を取得し、当該アクセス可否情報に基づいて前記制御対象データに対するアクセスの可否を判断するアクセス制御工程と
を備え、
前記状態管理工程は、
固定のライフサイクル状態と、
いずれかの固定のライフサイクル状態を親とする追加、変更または削除が可能なライフサイクル状態であって、前記固定のライフサイクル状態より強いアクセス制御の権限を持たない変動するライフサイクル状態と、
を管理し、
前記アクセス制御工程は、前記固定のライフサイクル状態について前記アクセスの可否を判断し、アクセス可と判断された場合、前記変動するライフサイクル状態について前記アクセスの可否をさらに判断する
ことを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器、管理モジュール、プログラムおよび制御方法に関する。
【背景技術】
【０００２】
組み込み機器の技術分野においては、その組み込み機器内に重要な電子情報を格納するようになり、その電子情報を守るために高度なセキュリティが必要とされつつある。ここで組み込み機器とは、特定の機能を実現するために、車両、家電製品、機械などの機器にコンピュータ機能を有するモジュールを組み込んだものである。
【０００３】
また、組み込み機器では、製造から廃棄までの各ステージ（段階）を含むライフサイクルを通して電子情報の安全性を保つこと、つまり一貫して機器内の電子情報が安全であることが求められている。例えば、ライフサイクルに応じて主たる利用者が変更される場合に電子情報の安全性を確保する必要性が高い。
【０００４】
ＩＣカードに対する不正利用を防止する目的で、ＩＣカードのライフサイクル状態の変更の際にセキュリティデータの設定等の有無を確認する機能を設け、セキュリティデータの設定等がなされているときに限り状態遷移を行う技術が知られている（例えば、特許文献１参照）。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、ライフサイクルを状態として管理して、それにより不正利用を防止しようとするのは、複数人の個人情報の共存、それらの個人情報に依存したアクセス制御、不正利用の防止といった点から、ＩＣカードのような単純な機器では可能であっても、汎用的な組み込み機器への適用は困難であるという点で問題があった。
【０００６】
まず、ＩＣカードでは単一の利用者が利用することを前提としているが、一般的なデータストレージを持つ組み込み機器に対してライフサイクルを状態として管理しようとした場合には、利用者が単一であるとは限らない。携帯電話のように利用者がほぼ単一の場合も想定されうるが、オフィスに存在する印刷機など、そもそも複数の利用者を前提としているものもある。また、車両のように一人で利用する場合、レンタルのように貸し借りする場合、カーシェアリングのように複数人がオーナーになる場合など、同じ組み込み機器に対して利用のされ方が異なるものもありうる。これらの組み込み機器に対して鍵やＰＩＮ（Personal Identification Number）の設定だけでライフサイクルを通しての安全性を確保することは非常に難しく、利用者毎の秘密情報を管理し、組み込み機器内のデータに対してライフサイクルに応じた適切なアクセス制限をかけてやることで始めてセキュリティ保証が可能となる。
【０００７】
また、ＩＣカードの例のようにアプリケーションの起動前に情報の設定の有無を調べる対策だけでは、状態遷移を実施した設定者は組み込み機器を利用者に引き渡した後でも、組み込み機器に対してアクセス可能な状態にある。つまり、状態遷移を実施した設定者が不正利用をしないことを前提とし、利用者は設定者を信頼する必要があった。具体的には、ライフサイクル状態を遷移させた場合、その状態遷移を行った設定者と、状態遷移後に組み込み機器を受け取る利用者のどちらもが組み込み機器内の情報にアクセスできる可能性があり、状態遷移後は利用者だけが情報を扱えるようになるという制御ができず、不正利用ができる余地が残されていた。
【０００８】
さらに、ライフサイクル状態のあり方についても問題がある。ＩＣカードでは利用のされ方がほぼ固定であるため、鍵やＰＩＮの設定によるライフサイクル状態遷移への制限のかけ方も固定として扱えていた。しかし、データストレージを持つ組み込み機器の中では、その運用方法によってライフサイクルのあり方が全く異なるものがある。例えば、車両で言えば、個人で利用するものとレンタルされるものではその運用は全く異なる。
【０００９】
しかし、単純にソフトウェアで後からライフサイクル状態に関わる条件を変更できるようにし、仕向け毎に安全な組み込み機器を作るという対策を講じるのは問題がある。
【００１０】
まず、組み込み機器のセキュリティを保つためには、組み込み機器に対するデータへのアクセス制御をライフサイクルに応じて変更するとともに、データの消去といった作業もライフサイクルの変更に応じて実施するなど、セキュリティとライフサイクルが密接に結びついた関係の上にセキュリティ保証が成り立っている必要がある。
【００１１】
しかし、セキュリティとライフサイクルの関係を後でソフトウェア的に変更した場合、セキュリティとライフサイクルの関係性が変更されることになる。その状態で組み込み機器がライフサイクルを通して本当に安全であるかを保証する術がない。例えば、組み込み機器のライフサイクルとして、最終的に廃棄状態にして、組み込み機器の全データを削除するライフサイクル状態を持たせることで、廃棄状態の安全性を保証する組み込み機器があった場合を想定する。もし組み込み機器に対し後からライフサイクル状態データを追加することで廃棄状態に至らない組み込み機器となった場合、廃棄時のデータ消去の保証はされなくなり、組み込み機器が廃棄時にも安全であるかが確かめられなくなるといったセキュリティ上の不備が生じる可能性がある。
【００１２】
つまり、ライフサイクルを通して組み込み機器の安全性を保証しようとする場合には、単純な鍵やＰＩＮだけでなく、個人の情報を適切に管理する必要がある。また、仕向け先ごとにライフサイクル状態を設定できることが望ましいが、そのライフサイクル状態を設定できることが、ライフサイクル管理された組み込み機器のセキュリティ上の穴になりうる可能性もあり、これらのことを考慮したセキュリティシステムを構築することが必要になる。
【００１３】
そこで、本発明は、ライフサイクル状態に基づいた状態遷移にてアクセス制御を行う組み込み機器において、組み込み機器のライフサイクルを通しての一貫したセキュリティを保つことを目的とする。
【課題を解決するための手段】
【００１４】
上記の課題を解決するため、本発明にあっては、制御対象データを内部に保持する機器であって、前記機器の現在のライフサイクル状態が何であるかを管理する状態管理手段と、認証データを受け付けて利用者を認証し所属するグループを応答する利用者認証手段と、前記制御対象データに対してアクセス要求があった場合に、前記状態管理手段から現在のライフサイクル状態を取得し、前記利用者認証手段で認証を行ってグループを取得し、前記制御対象データと対応付けられた状態アクセス制御ポリシーから現在のライフサイクル状態とアクセス要求を行った利用者のグループに基づいてアクセス可否情報を取得し、当該アクセス可否情報に基づいて前記制御対象データに対するアクセスの可否を判断するアクセス制御手段とを備え、前記状態管理手段は、固定のライフサイクル状態と、いずれかの固定のライフサイクル状態を親とする追加、変更または削除が可能なライフサイクル状態であって、前記固定のライフサイクル状態より強いアクセス制御の権限を持たない変動するライフサイクル状態と、を管理し、前記アクセス制御手段は、前記固定のライフサイクル状態について前記アクセスの可否を判断し、アクセス可と判断された場合、前記変動するライフサイクル状態について前記アクセスの可否をさらに判断する。
【発明の効果】
【００１５】
本発明にあっては、ライフサイクル状態に基づいた状態遷移にてアクセス制御を行う組み込み機器において、組み込み機器のライフサイクルを通しての一貫したセキュリティを保つことができる。
【図面の簡単な説明】
【００１６】
【図１】ライフサイクルの一例を示す図である。
【図２】組み込み機器の一実施例を示す図である。
【図３】固定ライフサイクル状態と変動ライフサイクル状態の例を示す図である。
【図４】ライフサイクル状態管理モジュールの一実施例を示す図である。
【図５】制御モジュールの一実施例を示す図である。
【図６】ライフサイクル状態管理モジュールの一実施例を示す機能ブロック図である。
【図７】保持されるデータの例を示す図である。
【図８】制御モジュールの一実施例を示す機能ブロック図である。
【図９】状態アクセス制御ポリシーの一例を示す図である。
【図１０】状態アクセス制御ポリシーに新たな状態を追加した例を示す図である。
【図１１】状態アクセス制御ポリシーに新たなグループを追加した例を示す図である。
【図１２】制御対象データへのアクセス処理を示すフローチャートである。
【図１３】ライフサイクル状態管理の元でのデータのアクセス権限の有無を調べる処理を示すフローチャートである。
【図１４】ライフサイクル状態の変更処理を示すフローチャートである。
【図１５】変動ライフサイクル状態を利用した具体例を示す図（その１）である。
【図１６】変動ライフサイクル状態を利用した具体例を示す図（その２）である。
【図１７】変動ライフサイクル状態を利用した具体例を示す図（その３）である。
【発明を実施するための形態】
【００１７】
以下、本発明の好適な実施形態につき説明する。
【００１８】
＜実施例＞
＜ライフサイクル＞
図１は、組み込み機器のライフサイクルの一例を示す。組み込み機器のライフサイクル状態には、ユーザが単にその組み込み機器を利用する過程だけでなく、工場で組み込み機器を製造する生産ステージ１、販売するためにトラックなどの輸送手段で運搬する物流ステージ２、販売店で組み込み機器を販売する販売ステージ３がある。さらに、組み込み機器のライフサイクル状態には、ユーザが利用している最中に組み込み機器が故障した場合などに修理を行うなどのサービスを提供するサービスステージ４、環境保護の観点から組み込み機器を回収し、リサイクルする回収リサイクルステージ５がある。組み込み機器によっては、回収リサイクル過程とともに、またはその代わりに組み込み機器を廃棄する廃棄ステージがあるものもある。
【００１９】
図１に示されるライフサイクルは、国や地域などの仕向けによって異なることがあるが、本実施例では、一例としてこれらの各ステージを通じて組み込み機器を運用することを総称してライフサイクルという。例えば、環境保護の観点から確実に回収を行いリサイクルすることや、廃棄後に悪用されないために、正規のルートで（正規のステージを通じて）ライフサイクルが運用されるように制御するとともに、運用されていることを証明する。
【００２０】
＜組み込み機器＞
ライフサイクル状態管理機能を搭載した機器の一例として、ライフサイクル状態管理機能を備えた車両などの組み込み機器（以下、「機器」という）について説明する。
【００２１】
図２は、ライフサイクル状態管理機能を備えた車両の制御モジュール構成の一実施例を示す。本実施例に係る車両は、車両全体のライフサイクルの各ステージ（状態）を管理するライフサイクル状態管理モジュール１００、およびライフサイクルの各ステージに応じてアクセス制御ポリシーが定義されたデータを格納する１または複数の制御モジュールによって構成される。ライフサイクル状態管理モジュール１００、および１または複数の制御モジュールのいくつかは、バス５０によって接続されることによってＣＡＮ（Controller Area Network）、ＬＩＮ（Local Interconnect Network）、イーサネット（Ethernet）（登録商標）、ＬＡＮ（Local Area Network）などのネットワークを構成する。これらのネットワークに限らず、ライフサイクル状態管理モジュール１００、および１または複数の制御モジュールをＦｌｅｘＲａｙによって接続することもできる。図２に示される例では、ライフサイクル状態管理モジュール１００、および複数の制御モジュールのいくつかは、バス５０によって接続される。図２には、複数の制御モジュールの例として、駆動制御モジュール２００、エンジン制御モジュール３００、ナビゲーションモジュール４００、および車載カメラモジュール５００が示される。
【００２２】
ライフサイクル状態管理モジュール１００は、機器全体に対して、唯一つのライフサイクルの各ステージを管理するとともに、機器利用者の認証情報を管理する。ライフサイクル状態管理モジュール１００は、機器の１または複数の制御モジュールの構成を把握し、その１または複数の制御モジュールに制御指示を与える。ライフサイクルの各ステージに応じて、機器の１または複数の制御モジュールのライフサイクルの各ステージに応じて設定されるアクセス制御ポリシー（以下、「状態アクセス制御ポリシー」という）がライフサイクル状態管理モジュール１００に格納される。ライフサイクル状態管理モジュール１００は、ライフサイクルの各ステージにおいて、制御の対象となる制御モジュールの状態アクセス制御ポリシーをベースに制御指示を行ったり、各制御の対象となる制御モジュールからの要求を受け付ける。ライフサイクル状態管理モジュール１００は、各制御モジュールからの要求に従い、バス５０を介して機器のライフサイクル状態と、機器を利用するためにアクセスした者（以下、「アクセス者」という）の属するグループを通知する。ここで、グループはアクセス者をアクセス権限の観点から分類したものであり、アクセス者がアクセスする権限があるか否かを判断する際に利用される。グループは人に対して設定することができるし、会社における部署、工場などの人以外のものにも設定できる。
【００２３】
例えば、ライフサイクルの販売ステージ３において営業がアクセス可能な制御モジュールへの制御指示およびデータと、ライフサイクルのサービスステージ４において修理が必要な場合に整備士がアクセス可能な制御モジュールへの制御指示およびデータとはその内容が異なることが想定される。ライフサイクル状態管理モジュール１００は、車両のアクセス者（営業、整備士）の認証情報を管理し、車両のアクセス者と状態アクセス制御ポリシーと関連づける。これにより、営業が修理の際に必要な情報にアクセスしてしまうことによって、整備士が修理の際にアクセスする制御モジュールの情報を壊してしまうことなどを防止できる。
【００２４】
駆動制御モジュール２００は、車両の駆動制御を行う。エンジン制御モジュール３００は、車両のエンジンを制御する。ナビゲーションモジュール４００は、車両を目的地まで導くナビゲーションを行う。車載カメラモジュール５００は、車両に搭載されたカメラを制御する。
【００２５】
駆動制御モジュール２００、エンジン制御モジュール３００、ナビゲーションモジュール４００、および車載カメラモジュール５００には、状態アクセス制御ポリシーが定義されたデータが格納される。状態アクセス制御ポリシーには、ライフサイクルの各ステージに応じて、グループに対するアクセス可能な操作が記載されている。
【００２６】
駆動制御モジュール２００、エンジン制御モジュール３００、ナビゲーションモジュール４００、および車載カメラモジュール５００は、必要に応じて、ライフサイクル状態管理モジュール１００から、その時点でのライフサイクルにおけるステージ、およびアクセス者のグループを受け取り、データへのアクセス可否の判定を行う。ライフサイクルにおけるステージに基づいて車両に搭載された全制御モジュールの各々に対して一斉にアクセス可能なグループが変更されることによって、個別に変更することによる変更忘れ、変更誤りなどを防止できる。
【００２７】
また、ライフサイクル状態管理モジュール１００にアクセス制御ポリシーが定義されたデータが格納される場合、ライフサイクル状態管理モジュール１００のライフサイクルにおけるステージ、およびアクセス者のグループを受けてデータへのアクセス可否の判定を行う場合もある。
【００２８】
ライフサイクル状態管理モジュール１００と各制御モジュールとの間の接続は、ライフサイクル状態管理モジュール１００、駆動制御モジュール２００、ナビゲーションモジュール４００、および車載カメラモジュール５００のようにバス５０を介して直接データをやり取りできるように接続することもできる。また、駆動制御モジュール２００、およびエンジン制御モジュール３００のように、ライフサイクル状態管理モジュール１００が特定の制御モジュールを介して、間接的にデータをやりとりできるように接続することもできる。また、バス５０を介して接続することに加え、ネットワークケーブルなどの有線によって接続することもできるし、無線ネットワークによって接続することもできる。いずれにしても、特定のプロトコルに従って、各制御モジュール間で通信ができるように設定することが求められる。
【００２９】
上述したように、駆動制御モジュール２００、エンジン制御モジュール３００、ナビゲーションモジュール４００、および車載カメラモジュール５００は、状態アクセス制御ポリシーを持ち、データに対するアクセス権の確認を各制御モジュールが個別に行うことができる。アクセス権の確認を各制御モジュールが個別に行う方法以外に、ライフサイクル状態管理モジュール１００に各制御モジュールの持つデータの識別子、およびそのデータに対する状態アクセス制御ポリシーを紐付けることによって対応付けたものを備えることもできる。この場合、ライフサイクル状態管理モジュール１００は、各制御モジュールの持つデータに対して紐付けられた状態アクセス制御ポリシーに基づいてアクセス権の有無を判定し、各制御モジュールに判定結果を通知する。各制御モジュールはライフサイクル状態管理モジュール１００から送信される判定結果を取得し、判定結果にしたがってデータへのアクセスを許可するなどの動作をすることができる。
【００３０】
ライフサイクル状態管理機能を搭載する対象である機器は、共通のライフサイクルにより制御される制御モジュール群全てを指す。つまり、車両を同一のライフサイクルで管理する場合は車両がライフサイクルを持つ機器になるし、ある商材に積まれたボード上の制御モジュールを同一のライフサイクルで管理する場合は、そのボードがライフサイクルを持つ機器になる。特に、機器に搭載される制御モジュールの各々に格納されるデータの寿命と、機器の寿命とが一致する場合に有効である。
【００３１】
＜固定ライフサイクル状態／変動ライフサイクル状態＞
ライフサイクル状態管理モジュール１００では２種類のライフサイクルを管理しており、それぞれを固定ライフサイクル状態、変動ライフサイクル状態と呼ぶ。各ライフサイクル状態は以下の性質を持っている。
■固定ライフサイクル状態
・全ての仕向け先に共通で適用され、変更することができない
・セキュリティを保つためのアクセス制御ルールが固定で適用される
■変動ライフサイクル状態
・仕向け先が変更可能であり、ライフサイクル状態の追加や削除も可能である
・変動ライフサイクルに定めるべきアクセス制御ルールは固定ライフサイクルより強い権限を与えることはできない
・固定ライフサイクル状態の子の状態としてのみ存在する
【００３２】
図３は、ライフサイクル状態管理モジュール１００にて管理される固定ライフサイクル状態と変動ライフサイクル状態の例を示す図である。図示の例では、「生産」「物流」「販売」「廃棄」が固定ライフサイクル状態であり、「生産」の子となる「チップ開発」「ボード組み入れ」「商材組み入れ」と、「物流」の子となる「物流業者Ａ管理状態」「物流業者Ｂ管理状態」と、「販売」の子となる「市場運用」「保守サービス」とが変動ライフサイクル状態である。なお、変動ライフサイクル状態の市場運用状態と保守サービス状態の関係のように、変動ライフサイクル状態においては元に戻るような状態遷移があってもよい。
【００３３】
ライフサイクル状態管理モジュール１００は、その時点での固定ライフサイクル状態と、その固定ライフサイクルの子として存在する変動ライフサイクル状態の２つを保持している。つまり、ある時点での機器の状態とは、固定ライフサイクル状態が何で、また変動ライフサイクル状態が何であるかというペアで表現される。ただし、図３の廃棄状態のように、固定ライフサイクル状態のみで、変動ライフサイクル状態を持たない場合が存在してもよい。
【００３４】
ライフサイクル状態管理モジュール１００の管理対象であるデータにアクセスする際には、まず固定ライフサイクル状態が持つアクセス制御ポリシーを確認し、その結果としてアクセスが可能だと判断された場合に限り、変動ライフサイクル状態のアクセス制御ポリシーの確認が実施される。これにより、ライフサイクル状態管理モジュール１００の安全性を固定ライフサイクル状態で保証し、かつ変動ライフサイクル状態にて仕向け毎の設定を可能にする。変動ライフサイクル状態のアクセス制御ポリシーの確認前に固定ライフサイクル状態のアクセス制御ポリシーを確認することで、各変動ライフサイクル状態で設定可能なアクセス制御ポリシーには制限が設けられることになる。その制約を設けることで変動ライフサイクル状態を設定することによって生じる権限昇格といったセキュリティの穴の発生を防ぐ。
【００３５】
ライフサイクルの状態遷移に関しては、変動ライフサイクル間の状態遷移と、固定ライフサイクル間の状態遷移の２種類が存在する。変動ライフサイクル間の状態遷移は、同一の固定ライフサイクル状態を親として持つ変動ライフサイクル間のみ状態遷移を行うことができる。固定ライフサイクル状態間の状態遷移を実施すると、その時点での変動ライフサイクル状態は破棄され、新しく変更された固定ライフサイクル状態を親として持つ変動ライフサイクル状態の初期値に自動的に変更する。
【００３６】
＜ライフサイクル状態管理モジュール１００のハードウェア構成＞
図４は、本実施例に係るライフサイクル状態管理モジュール１００のハードウェア構成図である。図４に示されているように、本実施例のライフサイクル状態管理モジュール１００は、バスライン１５０により互いに接続されたＣＰＵ（Central Processing Unit）１０２とメモリアクセスコントローラ１０７とバスＩ／Ｆ１０８と入出力装置１０９と認証装置１１０とを備えている。不揮発性メモリ１０３とＲＯＭ（Read Only Memory）１０４とＲＡＭ（Random Access Memory）１０６はメモリアクセスコントローラ１０７を介してバスライン１５０に接続されている。特に、異なる仕向け毎にプログラム可能な構成を実現するために、不揮発性メモリ１０３とメモリアクセスコントローラ１０７とを備えている。
【００３７】
ＣＰＵ１０２は、不揮発性メモリ１０３、ＲＯＭ１０４およびＲＡＭ１０６に展開されている、ユーザデータ、状態データ、制御対象データおよびプログラムを読み込み、実行することで、プログラムされた機能を提供する。
【００３８】
バスＩ／Ｆ１０８は、機器のバス５０（図２）に接続するインタフェースであり、ライフサイクル状態管理モジュール１００が機器に対する操作や、制御対象モジュールからのアクセスを受け付ける。
【００３９】
認証装置１１０は、機器全体（例えば車の制御対象モジュール）を制御するにあたって、機器利用者が許可されたユーザか否か判断する。許可されていないユーザであれば、ライフサイクル状態管理モジュール１００が機器全体（車）を利用することができない状態となる。許可されたユーザであれば、ユーザの所属するグループに合わせてメモリアクセスコントローラ１０７が、不揮発性メモリ１０３、ＲＯＭ１０４およびＲＡＭ１０６にアクセス可能なエリアを限定することで、そのグループにあわせたプログラムの機能を提供したり、アクセスが可能な制御対象モジュールが限定されたり、またアクセスが可能な制御対象モジュールにおいても、不揮発性メモリ１０３、ＲＯＭ１０４およびＲＡＭ１０６に展開されている状態アクセス制御ポリシーに合わせ制御対象モジュールにアクセスできる情報が制限されたりする。これは、認証結果から、認証装置１１０がメモリアクセスコントローラ１０７へ指示する。認証装置１１０が判断するデータは、入出力装置１０９から入力する。これは、ＩＣカードリーダーや、車のキーに機器利用者証明データを置き、キーを差し込むことでそのデータを入力できる装置や、無線や有線などのネットワーク装置でもよく、スマートフォンから認証するような構成でもよい。認証の手順については後述する。
【００４０】
入出力装置１０９は、ユーザ認証にのみ利用するのでなく、異なる仕向け毎に不揮発性メモリ１０３およびＲＡＭ１０６へのデータおよびプログラムの追加・修正・削除を行うためのデータ転送を行う装置である。これは、ＰＣ（Personal Computer）のＲＳ２３２Ｃで接続するような構成でもよいし、ネットワーク装置でスマートフォンからデータを送る構成でもよい。
【００４１】
なお、図４ではデータを書き換え可能な領域と、そうでない領域とを物理的に区別するために不揮発性メモリ１０３とＲＯＭ１０４とを分けて記載している。書き換えしてはならないデータ領域に対して、一度書き込んだ後に書き込み不可の権限を付与するという論理的な区別をするならば、データのストレージとしては不揮発性メモリだけでも構わない。つまり、ライフサイクル状態管理モジュール１００としては、書き込み可能な領域と書き込み不可能な領域が存在していれば構わない。
【００４２】
なお、ライフサイクル状態管理モジュール１００用のプログラムは、インストール可能な形式または実行可能な形式のファイルで、記録メディアやＣＤ−ＲＯＭ等のコンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。
【００４３】
＜他の制御モジュールのハードウェア構成＞
図５は、他の制御モジュール、すなわち、駆動制御モジュール２００、エンジン制御モジュール３００、ナビゲーションモジュール４００、車載カメラモジュール５００のハードウェア構成図である。これらの制御モジュールは、バスライン２５０により互いに接続されたＣＰＵ２０２とＲＯＭ２０４とＲＡＭ２０６とバスＩ／Ｆ２０８とを備えている。
【００４４】
＜ライフサイクル状態管理モジュール１００の機能構成＞
図６は、ライフサイクル状態管理モジュール１００の機能ブロック図である。図６には、ライフサイクル状態管理モジュール１００の機能ブロック図とともに、処理に用いるデータについても記載される。
【００４５】
ライフサイクル状態管理モジュール１００は、状態管理プログラムの実行により実現される状態管理部１６０と、利用者認証プログラムの実行により実現される利用者認証部１６２と、アクセス制御プログラムの実行により実現されるアクセス制御部１６４とを有している。これらの動作により、データへのアクセス権の確認のために全てのデータのアクセス制御ポリシーやユーザデータを確認することが可能であり、そこからデータへのアクセス制御を行っていく。
【００４６】
状態管理部１６０は、機器の固定ライフサイクル状態データＤ１と、機器の変動ライフサイクル状態データＤ２と、現時点における機器の固定状態データＤ３と機器の変動状態データＤ４とを参照可能であり、アクセス要求時点でのライフサイクル状態を通知する。また、各ライフサイクル状態のデータを取得できる。この状態管理部１６０により、アクセス制御のための情報として、その時点のライフサイクル状態を知ることができ、かつ各ライフサイクル状態を遷移させるための条件を知ることが可能になる。
【００４７】
利用者認証部１６２は、利用者の認証情報を入力として動作し、利用者認証の結果と、その利用者のグループを出力する。利用者認証部１６２は外部Ｉ／Ｆから入力されるユーザ情報と、ユーザデータＤ５を参照し、認証できるユーザがいるかを検索する。このとき、認証の手段としてはネットワークＩ／Ｆを用いた認証なら証明書、署名認証、ユーザＩ／Ｆならパスワード認証などが想定されており、認証方法については定めない。認証が成功したなら認証が成功したという結果と、認証が成功したユーザデータ内に存在するグループを出力する。
【００４８】
アクセス制御部１６４は、特定のライフサイクル状態において、ユーザがデータアクセス可能であるかを判定する機能を有し、制御対象データＤ６を参照する。それぞれの制御対象データには、状態アクセス制御ポリシーが含まれている。状態アクセス制御ポリシーは、特定のライフサイクルにおいて、どのユーザがアクセス可能か、どのグループがアクセス可能かという、アクセス可能者のリストが格納されている。アクセス制御部１６４は制御対象データＤ６を参照することで、特定のライフサイクル状態における、各データ（ファイル）にアクセス可能な利用者を特定することができる。状態アクセス制御ポリシーの詳細は後述する。
【００４９】
アクセス制御部１６４は、状態管理部１６０を呼び出すことでライフサイクル状態を取得し、利用者認証部１６２を呼び出すことで、該当する利用者のグループを取得し、また、制御対象データＤ６に対し、取得したライフサイクル状態におけるアクセス可能なグループを調べることで、利用者がアクセス可能であるかを決定する。
【００５０】
＜データ構造＞
図７はライフサイクル状態管理モジュール１００において保持されるデータの例を示す図である。データには大きく分けて２種類あり、ＲＯＭ内に存在し、書き換え不可能なデータ（以下、「書き換え不可能なデータ」とも呼ぶ。）と、不揮発性メモリ内に存在し、書き換えや追加や削除が可能なデータ（以下、「書き換え可能なデータ」とも呼ぶ。）の２種類である。図４の構成に従えば、書き換え不可能なデータはＲＯＭ１０４に、書き換え可能なデータは不揮発性メモリ１０３に保存される。
【００５１】
書き換え不可能なデータとして、固定ライフサイクル状態データＤ１、利用者認証プログラムＤ７、アクセス制御プログラムＤ８、状態管理プログラムＤ９、ユーザグループ一覧Ｄ１０が少なくとも存在する。また、書き換え可能なデータとして、ユーザデータＤ５、制御対象データＤ６、変動ライフサイクル状態データＤ２、機器の固定状態データＤ３、機器の変動状態データＤ４、追加ユーザグループ一覧Ｄ１１が少なくとも存在する。これらのデータを用いて利用者毎のアクセス制御をソフトウェアにて実現するが、ソフトウェア視点での各データの相関関係については後述する。
【００５２】
固定ライフサイクル状態データＤ１は、固定ライフサイクル状態として取り得る状態の集合が、固定状態データとして管理されている。各固定状態データは遷移条件、Ｅｎｔｒｙ動作、Ｅｘｉｔ動作を含む。遷移条件は、固定ライフサイクル同士の状態遷移が起こる際に満たすべき条件について記載されており、セキュリティを保ちつつ状態遷移をする上で必要な遷移条件を記載する。Ｅｎｔｒｙ動作は特定の固定ライフサイクルからの遷移にて、該当の状態に遷移した際に実行すべき処理について記述されており、当該状態になった際に、機器の安全性を保つ上で行うべき操作を記述し、それを状態遷移と同時に強制的に実施することでセキュリティの穴が発生することを防ぐ。Ｅｘｉｔ動作は、該当の固定ライフサイクル状態から別の固定ライフサイクル状態に変化する際に、状態遷移に対して残して置くべきでない情報の削除、書き換えられるべきでない情報の書き込み禁止権限の設定といった機能を提供する。これらは全て固定の情報であり、固定ライフサイクル状態遷移を行う際にはそれぞれのデータに従った機能提供、制限が強制的に実行され、それによりセキュリティを保証する。
【００５３】
書き換え不可能なソフトウェアのプログラムとしては、利用者認証プログラムＤ７、アクセス制御プログラムＤ８、状態管理プログラムＤ９が存在する。これらのプログラムが提供する機能の詳細は後述するが、これらはデータに対して特定の利用者がアクセスしようとした際のアクセス制御機能を提供する。よって、これらのプログラムを書き換え不可能なデータとして置くことで、全てのデータアクセスに対してアクセス制御が適用され、また、そのプログラム自体も改竄不可能になるため、セキュリティの保証につながる。また、ユーザグループ一覧Ｄ１０には、利用者に与えられる権限レベルの一覧が記載されており、ユーザデータＤ５内に存在するグループは、ユーザグループ一覧Ｄ１０に存在するグループでなくてはならない。
【００５４】
書き換え可能なデータとしては、アクセス制御のユーザ情報として利用されるユーザデータＤ５、アクセス制御の対象となる制御対象データＤ６、各変動ライフサイクル状態を表す変動ライフサイクル状態データＤ２、機器のその時点でのライフサイクル状態を表す機器の固定状態データＤ３、機器の変動状態データＤ４、追加したユーザグループを含む追加ユーザグループ一覧Ｄ１１を持つ。
【００５５】
書き換え可能なデータについては、書き換えが可能ではあるが、全てのデータに対して書き込みにはアクセス制御による権限確認が実施されるため、全てのユーザが任意に書き換えることが可能ではなく、一部のアクセス権限を持つユーザのみが、アクセス権限を持つデータに限りデータを書き換えることが可能である。
【００５６】
ユーザデータＤ５に含まれる個々のユーザデータには認証データとグループが含まれる。認証データとはユーザ認証の際に使われる情報であり、ネットワークＩ／Ｆを用いた認証なら証明書署名認証、ユーザＩ／Ｆならユーザ名パスワード認証などが想定されており、認証方法については複数が考えられるため、認証データのあり方も複数が考えられるし、複数の認証方式を１つのユーザデータで管理してもよい。また、グループとはユーザがどのような権限を持つグループに属するかを設定したもので、例えば、機器管理者、機器製造者といったものがグループになる。ユーザ情報として設定されるグループとしては機器管理者かつ機器利用者のように複数のグループが設定されていてもよい。また、追加ユーザグループ一覧Ｄ１１の追加ユーザグループでグループを定義しても構わない。ただし、追加ユーザグループは、必ず親のユーザグループをユーザグループ一覧Ｄ１０から設定しなければならない。また、追加ユーザグループに設定できる親のユーザグループは、設定者自身の親グループ、もしくはそれより権限の弱いグループでなくてはならず、設定者が機器に設定する際にアクセス制御がかけられる。
【００５７】
ユーザデータＤ５として登録されているものは人でなくとも構わない。例えば、ログ情報を定期的に外部のサーバに送信するといった場合に、自動で認証を行って外部のサーバに送るなど、人の手が介在しないようなユーザグループの設定もありうる。
【００５８】
制御対象データＤ６に含まれる個々の制御対象データは、アクセス制御できるグループを特定するためのテーブルである状態アクセス制御ポリシーを持つ。状態アクセス制御ポリシーの詳細については後述する。
【００５９】
変動ライフサイクル状態データＤ２に含まれる変動ライフサイクル状態は、遷移条件、Ｅｎｔｒｙ動作、Ｅｘｉｔ動作、親状態データを持つ。遷移条件、Ｅｎｔｒｙ動作、Ｅｘｉｔ動作に関し、データの役割は固定状態データの持つそれと同義である。ただし、遷移条件は固定ライフサイクル状態から固定ライフサイクルへの状態遷移の条件ではなく、変動ライフサイクル状態から変動ライフサイクル状態への遷移条件が記載されている。親状態データに関しては、変動ライフサイクル状態データには存在するが、固定ライフサイクル状態には存在しないデータであり、ここにはただ１つの固定ライフサイクル状態データ名が記載されている。
【００６０】
機器の固定状態データＤ３、機器の変動状態データＤ４は、機器全体のその時点でのライフサイクル状態を示すもので、機器全体でただ１つずつ管理されている。
【００６１】
＜他の制御モジュールの機能構成＞
図８は、他の制御モジュール、すなわち、駆動制御モジュール２００、エンジン制御モジュール３００、ナビゲーションモジュール４００、車載カメラモジュール５００の機能ブロック図である。
【００６２】
制御モジュールは、アクセス制御部２６２を有し、このアクセス制御部２６２は、図５に示されている各構成要素のいずれかが、ＲＯＭ２０４からＲＡＭ２０６上に展開された駆動制御モジュール用プログラムである、アクセス制御プログラムに従ったＣＰＵ２０２からの命令によって動作することで実現される機能、または機能する手段である。
【００６３】
＜状態アクセス制御ポリシー＞
図９は状態アクセス制御ポリシーの一例を示す図である。ライフサイクル状態管理モジュール１００によって管理対象となる制御対象データは、それぞれが状態アクセス制御ポリシーを持つ。状態アクセス制御ポリシーはユーザグループと、機器のライフサイクル状態からなるマトリクス表である。
【００６４】
各ユーザグループに対して、割り当てられるアクセス権限は以下の種類がある。
・Ｒｅａｄ：対象の制御対象データを読み出せる
・Ｗｒｉｔｅ：対象の制御対象データを書き出せる（生成できる）
・Ｅｘｅｃ：対象の制御対象データを利用できる
・Ｄｅｌｅｔｅ：対象の制御対象データを削除できる
・ＲｅＷｒｉｔｅ；対象の制御対象データを変更できる
【００６５】
図９ではユーザグループとして機器製造者、物流管理者、機器管理者、機器利用者がいる場合を想定し、ライフサイクル状態として生産状態、物流状態、販売状態、廃棄状態が存在する場合を想定する。また、簡単のためにこれらは全て固定ライフサイクル状態とし、変動ライフサイクル状態は定義されていないものとする。また、制御対象データとして、各ユーザグループの持つ秘密情報のアクセス制御ポリシーの設定例について記載している。
【００６６】
（１）として示す機器製造者の秘密情報については、製造状態において機器製造者が機器に設定する。この段階では機器製造者のみがＲｅａｄ、Ｗｒｉｔｅ、Ｅｘｅｃ、ＲｅＷｒｉｔｅが可能である。そして、ライフサイクル状態管理モジュール１００が、物流状態に遷移したときに、機器製造者がＷｒｉｔｅとＲｅＷｒｉｔｅをできないようにアクセス制御をする。これにより、機器製造者が機器内の秘密情報を無断で改竄することを防ぎ、否認防止性の確保につながる。物流管理者、機器管理者、機器利用者にとっては機器製造者の秘密情報はＥｘｅｃのみできる。ただし、機器製造者の署名用の秘密鍵など、機器製造者の秘密情報の中には、機器製造者自身しかＥｘｅｃ権限を持たないものがあっても構わない。廃棄状態になったら機器製造者は、機器製造者の秘密情報を廃棄できる。安全性の観点から廃棄においては機器管理者も廃棄できるように設定可能である。
【００６７】
（５）として示す機器製造者の公開情報については、製造状態において機器製造者が機器に設定する。この段階では機器製造者のみがＲｅａｄ、Ｗｒｉｔｅ、Ｅｘｅｃ、ＲｅＷｒｉｔｅが可能である。そして、ライフサイクル状態管理モジュール１００が、市場運用状態に遷移したときに、機器製造者がＷｒｉｔｅとＲｅＷｒｉｔｅをできないようにアクセス制御をする。これにより、機器製造者が機器内の公開情報を無断で改竄することを防ぎ、否認防止性の向上につながる。機器管理者と機器利用者にとっては機器製造者の公開情報はＲｅａｄ、Ｅｘｅｃのみできる。廃棄状態になったら機器製造者は、機器製造者の公開情報を廃棄できる。安全性の観点から廃棄においては機器管理者も廃棄できるように設定可能である。
【００６８】
（３）として示す機器管理者の秘密情報については、市場運用状態において機器管理者が機器に設定する。この段階では機器管理者のみがＲｅａｄ、Ｗｒｉｔｅ、Ｅｘｅｃが可能である。機器製造者と機器利用者にとっては機器製造者の秘密情報はＥｘｅｃのみできる。ただし、機器管理者の署名用の秘密鍵など、機器管理者の秘密情報の中には、機器管理者自身しかＥｘｅｃ権限を持たないものがあっても構わない。これにより、機器管理者の持つ秘密情報を機器の製造者含む他の利用者から保護し、安全にライフサイクル状態管理モジュールを利用することができる。廃棄状態になったら機器製造者は、機器製造者の秘密情報を廃棄できる。安全性の観点から廃棄においては機器管理者も廃棄できるように設定可能である。
【００６９】
他の機器管理者の公開情報、機器利用者の秘密情報、機器利用者の公開情報も同様に、他の利用者の否認防止性、他の利用者からの保護を視点にアクセス制御ポリシーを構成する。ただし機器利用者の秘密情報に関して、機器管理者がＲｅａｄやＷｒｉｔｅをできるようにするかは、ライフサイクル状態管理モジュールの運用によって決めるべきである。管理者が強い権限を持つものであるなら、機器管理者は機器利用者の秘密情報をＲｅａｄできても構わないが、そうでなく機器管理者と機器利用者の権限が近い場合、機器管理者は機器利用者の秘密情報をＲｅａｄできるべきではない。
【００７０】
図１０は状態アクセス制御ポリシーに新たな状態を追加した例を示す図である。図１０では、変動ライフサイクル状態を新たに定義し、それを状態アクセス制御ポリシーに追加する例として、機器をレンタルする場合を想定した「貸出状態」という変動ライフサイクル状態を追加した場合を考えている。なお、この貸出状態は販売状態の子の状態として存在しているとする。
【００７１】
このとき、状態アクセス制御ポリシーは、その状態アクセス制御ポリシーを追加するユーザが任意に設定できてもよい。ただし、貸出状態は販売状態の子の状態として存在するため、そのアクセス制御は販売状態の権限を越えることはできない。図１０の上段のパターン１は、正しい設定例として、必要な範囲でアクセスを可能としている。
【００７２】
図１０の下段のパターン２として示すように、仮に変動ライフサイクル状態に対する状態アクセス制御ポリシーを考えうる限り最弱に設定する悪意のあるユーザが存在したとしても、固定ライフサイクル状態でのアクセス制御が行われているため、少なくとも固定ライフサイクル状態と同じセキュリティ強度を保つことができる。
【００７３】
図１１は状態アクセス制御ポリシーに新たなグループを追加した例を示す図である。図１１では、右端に示すように、「物流管理者」の子として「物流中間業者」のグループを追加している。このように、ユーザグループを新たに定義し、それを状態アクセス制御ポリシーに追加する場合があってもよい。図１０の例と同様に、親のユーザグループが存在することにより、最弱の設定をしたとしても、少なくともユーザグループ一覧に存在するユーザグループと同程度のセキュリティ強度を保つことができる。
【００７４】
＜制御対象データへのアクセス処理＞
図１２は制御対象データへのアクセス処理を示すフローチャートである。図１２において、機器に対して利用者からデータへのアクセス要求がある場合、処理を開始する。
【００７５】
ステップＳ１１において、機器は状態管理部１６０（状態管理プログラム）を呼び出し、利用者のデータへのアクセス要求時点での固定ライフサイクル状態を調べる。
【００７６】
次いで、ステップＳ１２において、機器は、固定ライフサイクル状態に基づいた、データに対するアクセス権限の確認を行い、ステップＳ１３において、利用者はデータに対してアクセス可能な権限を持つかを調べる。この手順の詳細については後述する。
【００７７】
この際に利用者がデータに対してアクセス可能でないと判断された場合は、ステップＳ１８において、データへのアクセスは却下される。
【００７８】
利用者がデータに対してアクセス可能であると判断された場合は、ステップＳ１４において、機器は状態管理部１６０を呼び出し、利用者のデータへのアクセス要求時点での変動ライフサイクル状態を調べる。
【００７９】
次いで、ステップＳ１５において、機器は、変動ライフサイクル状態に基づいた、データに対するアクセス権限の確認を行い、ステップＳ１６において、利用者はデータに対してアクセス可能な権限を持つかを調べる。この手順の詳細については固定ライフサイクル状態でのアクセス可能な権限を持つかを調べる手順と同一の手順であり、後述する。
【００８０】
この際に利用者がデータに対してアクセス可能でないと判断された場合は、ステップＳ１８において、データへのアクセスは却下される。また、アクセス可能と判断された場合には、ステップＳ１７において、データアクセスを許可される。
【００８１】
図１２に示されるフローチャートに示される処理の順序は、この限りでなく適宜変更可能である。
【００８２】
図１３はライフサイクル状態管理の元でのデータのアクセス権限の有無を調べる処理を示すフローチャートである。機器が制御対象データへのアクセスを要求された場合、機器はアクセス制御機能を呼び出し、データアクセス認可か却下の結論を出す。これらは固定ライフサイクル状態においてのアクセス制御の確認と、変動ライフサイクル状態におけるアクセス制御の確認のために２回呼び出され、処理としては同一である。
【００８３】
図１３において、制御対象データへのアクセス要求があった場合、ステップＳ２１において、アクセス制御機能は現在のライフサイクル状態を確認するために、状態管理機能を呼び出す。状態管理機能は、呼び出しに従い、制御対象データへのアクセス要求があった時点での機器の状態データの内容を送信する。このとき、ライフサイクル状態データとして固定ライフサイクル状態データについて調査する際には機器の固定状態データについて調べ、変動ライフサイクル状態データについて調査する際には機器の変動状態データについて調べる。
【００８４】
次いで、アクセス制御機能はライフサイクル状態データを確認した後、ステップＳ２２において、アクセス対象である制御対象データの状態アクセスポリシーを確認する。
【００８５】
次いで、ステップＳ２３において、アクセス制御機能は状態アクセスポリシーからデータアクセス可能な権限が存在するかを確認する。
【００８６】
データアクセス可能な利用者が存在しない場合、ステップＳ２９において、利用者の認証を行う前にデータへのアクセスは拒否される。一例として、ファイル書き込みが許されていないファイルとして、製造者の公開鍵情報などが存在する場合、それに対する書き込みアクセス要求は却下される。
【００８７】
また、データアクセス可能な利用者が存在する場合、ステップＳ２４において、アクセス制御機能は状態アクセスポリシーからデータアクセスにユーザグループによるアクセス制御がかかっているかを確認する。
【００８８】
アクセス制御のかかっていないデータの場合は、ステップＳ２８において、データアクセス権限を持つと判断し、利用者の認証を行わずにデータにアクセスできる。一例として、状態アクセスポリシーの確認のためのファイルアクセスなどは、利用者の確認を行わずアクセス要求は許可される。
【００８９】
アクセス制御機能は状態アクセスポリシーからデータアクセスにユーザグループによるアクセス制御がかかっていて、ユーザグループの確認が必要な場合は、ステップＳ２５において、利用者認証機能を用いて、利用者認証を実施する。認証には利用者の識別子と、利用者の認証情報の入力が必要であり、バスＩ／Ｆ１０８（図４）が利用者の認証情報の入力手段として用いられる。用いられる認証情報についてはバスＩ／Ｆ１０８に接続される入力装置に依存する。一例として、ユーザＩＤとパスワードの入力による認証などが考えられる。また、利用者の認証情報の入力はステップＳ２５で行うのに代え、データアクセスシーケンス開始時に入力として与えてもよい。
【００９０】
利用者認証機能は、ステップＳ２６で認証に成功したなら、アクセス制御機能に対して、認証者のグループを送る。このグループはユーザグループ一覧で定義されたものでも、追加ユーザグループ一覧で定義されたものでも構わないが、追加ユーザグループの場合は必ず親グループのアクセス権限を確認した後、追加ユーザグループの確認が為される。
【００９１】
認証に成功しなかった場合は、認証失敗結果をアクセス制御機能に対して送る。アクセス制御機能は認証失敗結果を受け取った場合には、ステップＳ２９において、データアクセス権限を持たないと判断し、ファイルアクセスを却下する。
【００９２】
認証に成功した場合、ステップＳ２７において、アクセス制御機能は認証者のグループと、状態アクセスポリシーから、認証者がファイルにアクセス可能であるかを確認する。
【００９３】
アクセス可能であると判断された場合は、ステップＳ２８において、データアクセス権限を持つと判断する。そうでない場合は、ステップＳ２９において、データアクセス権限を持たないと判断する。
【００９４】
図１３に示されるフローチャートに示される処理の順序は、この限りでなく適宜変更可能である。
【００９５】
＜ライフサイクル状態の変更処理＞
図１４は、ライフサイクル状態の変更が行われる際の処理を示す。
【００９６】
ステップＳ３１では、ライフサイクル状態管理モジュール１００のアクセス制御部１６４は、ライフサイクル状態を変更する要求（以下、「状態変更要求」という）を受け付ける。
【００９７】
ステップＳ３２では、ライフサイクル状態管理モジュール１００のアクセス制御部１６４は、状態変更要求を行ったアクセス者は、アクセスが許可された者であるか否かを判断する。アクセス制御部１６４は、データへのアクセス制御の後に、状態変更要求にしたがって、ライフサイクル状態を変更する処理を行う。具体的には、アクセス制御部１６４は、状態変更要求を受け付けた際に、図１２に示される制御対象データへのアクセス処理を実行する。アクセス制御部１６４は、制御対象データへのアクセスが認可された場合にはライフサイクル状態を変更する処理を行い、アクセスが認可されない場合にはライフサイクル状態を変更する処理を却下する。
【００９８】
ステップＳ３３では、ステップＳ３２で状態変更要求を行ったアクセス者がアクセスを許可された者である場合、状態管理部１６０は、遷移条件を検索する。状態変更要求を受け付けたとき、アクセス制御部１６４は、状態管理部１６０を呼び出し、状態変更要求が行われた状態における遷移条件の通知を要求する。状態管理部１６０は、アクセス制御部１６４からの遷移条件の通知の要求にしたがって、遷移条件を通知する。遷移条件は、特定のデータが存在していること、あるデータが特定の形式を満たすことなどである。ここでは、一例として、遷移条件は、ＲＯＭ１０４に格納された全データのハッシュ値を取り、データの改ざんを受けていないことを確認することである場合について説明する。
【００９９】
ステップＳ３４では、アクセス制御部１６４は、状態管理部１６０から通知される遷移条件に基づいて、状態変更のための遷移条件を満たしているか否かを判断する。ここでは、ＲＯＭ１０４に格納された全データのハッシュ値を取り、データの改ざんを受けていないことを確認することが遷移条件であるため、アクセス制御部１６４は、制御対象データ１３０１−１３０ＭなどのＲＯＭ１０４に格納された全データのハッシュ値を取り、データの改ざんを受けているかいないかを判断することによって、状態変更の遷移条件を満たしているか否かを判断する。
【０１００】
ステップＳ３５では、ステップＳ３４でデータの改ざんを受けていないと判断した場合、つまり、状態変更条件を満たしている場合、アクセス制御部１６４は、状態変更前の状態からＥｘｉｔする処理を行う。状態変更条件を満たしている場合、アクセス制御部１６４は、状態管理部１６０を呼び出し、状態管理部１６０に状態遷移前の状態データのＥｘｉｔ動作を通知するように要求する。状態管理部１６０は、アクセス制御部１６４からのＥｘｉｔ動作の通知要求にしたがって、状態遷移前の状態データのＥｘｉｔ動作を通知する。アクセス制御部１６４は、状態管理部１６０から通知されるＥｘｉｔ動作にしたがってＥｘｉｔ処理を実施する。Ｅｘｉｔ処理を実施することによって、ライフサイクル状態を変更する上で、次の状態に移行する際に残しておくことがセキュリティ上の脆弱性につながるような情報の消去、もしくは、そのような情報の書き換えを実施できる。Ｅｘｉｔ処理の一例は、前回のライフサイクル状態における機器の主要な利用者の個人情報につながるログデータの削除、秘密鍵の改ざん防止のための書き込み不可設定などである。
【０１０１】
ステップＳ３６では、ステップＳ３５においてＥｘｉｔ処理が実施された後、アクセス制御部１６４は、状態変更を実施する。アクセス制御部１６４は、状態管理部１６０に状態の変更を通知する。状態管理部１６０は、アクセス制御部１６４から状態の変更が通知されると、現在の状態として記憶している内容を要求された状態に入れ替えることによって、管理対象の状態を遷移させる。
【０１０２】
ステップＳ３７では、状態変更後の状態へのＥｎｔｒｙ処理を実施する。状態変更後、アクセス制御部１６４は、状態管理部１６０を呼び出し、Ｅｎｔｒｙ動作を要求する。状態管理部１６０は、アクセス制御部１６４からのＥｎｔｒｙ動作の通知の要求にしたがって、Ｅｎｔｒｙ動作を通知する。アクセス制御部１６４は、状態管理部１６０から通知されるＥｎｔｒｙ動作にしたがって、Ｅｎｔｒｙ動作を実施する。Ｅｎｔｒｙ動作では、状態変更後のライフサイクルを安全に使うための処理として、セキュリティ情報の初期設定などを実施する。一例として、通信のための鍵の設定が必要になる場合に、機器が鍵を自動生成するなどの処理を実施する。
【０１０３】
ステップＳ３８では、ステップＳ３７によって、Ｅｎｔｒｙ処理が実施された後、状態変更を完了する。
【０１０４】
ステップＳ３９では、ステップＳ３２で状態変更要求を行ったアクセス者がアクセスを許可された者でない場合、またはステップＳ３４でデータの改ざんを受けていると判断した場合、アクセス制御部１６４は、状態変更要求を却下する。
【０１０５】
図１４に示されるフローチャートに示される処理の順序は、この限りでなく適宜変更可能である。
【０１０６】
＜変動ライフサイクル状態を利用した具体例＞
図１５は変動ライフサイクル状態を利用した具体例を示す図であり、車両をレンタカーとして運用する際のライフサイクル状態管理を用いた安全な運用に適用した例である。
【０１０７】
図１５において、車両自体は市場運用が既に為されており、販売状態にあるものとし、変動ライフサイクル状態の追加とユーザグループの追加を行うものとする。図１５では変動ライフサイクル状態として「貸出可能状態」と「貸出状態」を定義している。貸出可能状態は、レンタカーのレンタル業者（ディーラー）が車を保持している状態であり、貸出状態は特定のレンタル者に車を貸している状態とする。また、主利用者（グループ）として、レンタル業者のグループとレンタル者のグループを定義している。貸出可能状態、貸出状態はどちらも販売状態を親に持つ変動ライフサイクル状態として定義しており、また、レンタル業者とレンタル者は機器管理者を親に持つグループとして定義している。
【０１０８】
例えば、レンタル業者としては貸出可能状態であるときには車を自由に扱える必要があるため、車の操作関連の機能やデータにはアクセス可能でなくてはならない。ただし、貸出状態にあるときにはレンタル業者には公開すべきでない情報が車内で扱われる可能性がある。例えば、貸出状態のときにレンタル者がナビを利用した場合、そのナビにはレンタル者がいつどこに行こうとしていたかといった個人情報が履歴として残る可能性がある。これらの情報はレンタル業者が無断で見てよい情報ではない。つまり、車のレンタルでは貸し出す前と貸し出した後で、レンタル業者は異なるアクセス権限を持つ必要があり、一度貸し出しを行った車に対してのデータアクセス権限は弱くなる必要がある。
【０１０９】
逆に、レンタル者にしても、自分が車を借りている間はナビを機能制限なく使いたいはずで、自宅の住所を都度入力する必要があるよりは、一度入力すれば履歴から検索できる方が便利である。かといって、車をレンタル業者に返却した後にも、車両内にナビの履歴が残っているのは望ましくない。つまり、車を借りている間は履歴のログなどデータへのアクセス権限が強く、返却した際にはそれらのデータは削除されていることが望ましい。
【０１１０】
そこで、貸出可能状態から貸出状態に遷移する際（ステップＳ４１）に、まず貸出可能状態のＥｘｉｔ動作にて、レンタル業者の車へのアクセスに制限をかける（ステップＳ４２）。この制限にはナビへのアクセスを禁止するなどの、貸し出した後にレンタル者の情報を盗み出せなくするような動作を定義する。続いて、貸出状態のＥｎｔｒｙ動作として、レンタル者のユーザデータ登録を実施する（ステップＳ４３）。これを行うことで、レンタカーを貸与している間は、自分の車であるかのように車内の機能をユーザデータに紐付けてカスタマイズすることができる。例えば、ナビの特定地点のお気に入り登録、履歴機能などが使えるようになる。
【０１１１】
貸出状態から貸出可能状態に遷移する場合（ステップＳ４４）は、貸出状態のＥｘｉｔ動作として、レンタル者のユーザデータを削除する（ステップＳ４５）。また、それに結びついたナビの個人設定などのカスタマイズ項目も削除することで、車両内にレンタル者の個人データを残さない状態にする。また、同時に返却後にレンタル者が車に対してアクセスできてしまうという事態も防止することが可能になる。
【０１１２】
そして、貸出可能状態のＥｎｔｒｙ動作としてレンタル業者のアクセス制限を元に戻すことで（ステップＳ４６）、レンタル業者は貸出可能状態にあるときのみ車を自由に扱えるようになる。
【０１１３】
なお、このときにそれぞれのライフサイクル状態の遷移を誰が行うかについてだが、貸出可能状態から貸出状態への遷移はレンタル業者が行い、貸出状態から貸出可能状態への遷移はレンタル者が行う形式がふさわしい。
【０１１４】
このように、変動ライフサイクル状態の定義が可能になることで、レンタル者とレンタル業者の双方にとってセキュリティを保った状態で、通常に利用する分には不便をかけない運用が可能になる。これらの特性は既存特許では実現が難しく、状態を元に戻せるという変動ライフサイクル状態の性質と、新たにグループも追加可能で、それぞれに異なる権限を与えることが可能であるという性質が可能にしている。
【０１１５】
図１６は変動ライフサイクル状態を利用した他の具体例を示す図であり、ユーザとして人以外を設定した場合の一例として、車両が事故にあった際のライフサイクル状態管理を用いた事故の自動通報システムに適用した例である。
【０１１６】
図１６において、車両自体は市場運用が既に為されており、販売状態にあるものとする。また、この例では状態遷移を引き起こすのは特定の人ではなく、他のモジュールなどの機器同士になる。
【０１１７】
図１６では、変動ライフサイクル状態として「市場運用状態」と「緊急状態」を定義している。市場運用状態は、機器管理者が正常に機器を利用している状態であり、緊急状態は緊急の通報を必要とする状態として定義している。また、主利用者（グループ）として、機器管理者のグループとロードサービス業者のグループを定義している。市場運用状態、緊急状態はどちらも販売状態を親に持つ変動ライフサイクル状態として定義しており、また、ロードサービス業者は機器利用者を親に持つグループとして定義している。
【０１１８】
例えば、機器管理者としては市場運用状態であるときには、例えロードサービス業者の契約が為されたとしても、車の内部のログ情報といったものを無闇に公開するのは望まれない可能性がある。このようなときに、市場運用状態にて、ロードサービス業者のログへのアクセスを禁止すれば、データを覗かれる心配はなくなり、セキュリティ上の強度が増す。
【０１１９】
ただし、事故時（ステップＳ５１）にはいち早くロードサービス業者への救援依頼を行う必要があるため、緊急状態ではログ情報、事故の状態を検知するための車内の各センサー類の情報を公開設定にし、ロードサービス業者に通知する設定とする（ステップＳ５２）。これにより、事故が発生した際には即座にロードサービス業者に通知され、各種センサー情報から事故の度合いを推察することが可能になる。また、緊急状態にて自動通知を行う設定にすれば、他の状態ではロードサービス業者への通知機能はロックすることも可能なので、ロードサービス業者への誤通報やいたずらといった問題も解消可能である。更に、センサー結果を自動で通知することで、人の主観によらない客観的な事故の状況の通知が可能になる。
【０１２０】
この例での状態の移り変わりのための遷移は人の手によって行わない。例えば、市場運用状態から緊急状態への遷移は、エアバッグの作動をトリガーとするなど、他のモジュール（安全装置）の動作をトリガーとする。このような機器同士の連携によって、人の手を経由しない運用も、ライフサイクル状態遷移の管理モジュールではあり得る。
【０１２１】
図１７は変動ライフサイクル状態を利用した他の具体例を示す図であり、複数のライフサイクル管理モジュールを用いて提供できるサービスとして、車両が事故にあった際のライフサイクル状態管理を用いた事故の自動通報システムに適用した例である。
【０１２２】
図１７では、車両の事故の状態を通知するのは他のライフサイクル状態管理システムを用いている車両とする。
【０１２３】
車両Ｃ１が事故にあった際（ステップＳ６１）に、危険を事前に予測しやすいように、各車両に対して危険を通知するための事故位置、車両Ｃ１のユーザＩＤ、車両Ｃ１の証明書を用いて、データを送る（ステップＳ６２）。このときに、事故の位置や車両Ｃ１のユーザＩＤにはデジタル署名をつけることで、車両Ｃ２−Ｃ４がデータの認証を行えるようなデータとして送信する。
【０１２４】
車両Ｃ２−Ｃ４は車両Ｃ１からのデータを受け取ることで、証明書署名認証を行い、データの正当性を確認する。これにより、事故の情報をいち早く知ることができ、ナビに事故位置を表示する、迂回ルートの検索を開始するなどの対応が可能になる。
【０１２５】
このような機器の運用は、機器が認証機能を備えていることと、機器利用者でさえアクセス不可能な機器の内部情報を、機器内部に保存していることから可能になる。まず、機器の認証機能を用いることで、例え事故を偽装して交通を乱そうとする偽装者Ｄが存在していたとしても（ステップＳ６３）、正しい証明書発行機関が発行していない証明書であれば証明書に不備が存在することになり、各車両はデータを受け取っても受理しない。また、機器管理者であっても故意に事故の通知をするといったこともできないようにできる。車両Ｃ１の証明書を用いた署名を機器自身のシステムしかできないようにし、機器管理者にさえその権限を与えないという管理にすることで、自動通報以外に外部に事故情報を伝える術をなくせばよい。
【０１２６】
よって、認証機能と、アクセス制御機能を用いることで、セキュリティが守られていることを前提としたサービスの供給が可能になる。
【０１２７】
＜総括＞
以上、説明したように、本実施形態によれば、ライフサイクル状態に基づいた状態遷移にてアクセス制御を行う組み込み機器において、組み込み機器のライフサイクルを通しての一貫したセキュリティを保つことができる。
【０１２８】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【０１２９】
＜実施形態の用語と請求項の用語の対応＞
状態管理部１６０は「状態管理手段」の一例である。利用者認証部１６２は「利用者認証手段」の一例である。アクセス制御部１６４は「アクセス制御手段」の一例である。
【符号の説明】
【０１３０】
５０        バス
１００      ライフサイクル状態管理モジュール
１０２      ＣＰＵ
１０３      不揮発性メモリ
１０４      ＲＯＭ
１０６      ＲＡＭ
１０７      メモリアクセスコントローラ
１０８      バスＩ／Ｆ
１０９      入出力装置
１１０      認証装置
１５０      バスライン
１６０      状態管理部
１６２      利用者認証部
１６４      アクセス制御部
２００      駆動制御モジュール
２０２      ＣＰＵ
２０４      ＲＯＭ
２０６      ＲＡＭ
２０８      バスＩ／Ｆ
２５０      バスライン
２６２      アクセス制御部
３００      エンジン制御モジュール
４００      ナビゲーションモジュール
５００      車載カメラモジュール
【先行技術文献】
【特許文献】
【０１３１】
【特許文献１】特開２００９−７５９６８号公報
【図１】
0006387756.tif 000002
【図２】
0006387756.tif 000003
【図３】
0006387756.tif 000004
【図４】
0006387756.tif 000005
【図５】
0006387756.tif 000006
【図６】
0006387756.tif 000007
【図７】
0006387756.tif 000008
【図８】
0006387756.tif 000009
【図９】
0006387756.tif 000010
【図１０】
0006387756.tif 000011
【図１１】
0006387756.tif 000012
【図１２】
0006387756.tif 000013
【図１３】
0006387756.tif 000014
【図１４】
0006387756.tif 000015
【図１５】
0006387756.tif 000016
【図１６】
0006387756.tif 000017
【図１７】
0006387756.tif 000018