特許 7463928 認証管理装置および認証管理方法

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

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

(11)【特許番号】

(24)【登録日】2024-04-01

(45)【発行日】2024-04-09

(54)【発明の名称】認証管理装置および認証管理方法

(51)【国際特許分類】

   G06F 21/31 20130101AFI20240402BHJP

【ＦＩ】

G06F21/31

【請求項の数】 6

(21)【出願番号】P 2020165361

(22)【出願日】2020-09-30

(65)【公開番号】P2022057222

(43)【公開日】2022-04-11

【審査請求日】2023-02-15

(73)【特許権者】

【識別番号】000004260

【氏名又は名称】株式会社デンソー

(74)【代理人】

【識別番号】110000567

【氏名又は名称】弁理士法人サトー

(72)【発明者】

【氏名】野村 肇

(72)【発明者】

【氏名】田中 雄介

(72)【発明者】

【氏名】伊東 由佳

(72)【発明者】

【氏名】牧田 貴成

【審査官】宮司 卓佳

(56)【参考文献】

【文献】特開２０２０－０８３１８１（ＪＰ，Ａ）

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

【文献】特開２００８－１９１８５７（ＪＰ，Ａ）

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

Ｇ０６Ｆ ２１／３１

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

【請求項1】

車両（２）のユーザ（３）から前記車両に関する所定の操作を要求する操作要求が与えられると、前記ユーザの認証に関する認証情報および前記操作の認可に関する認可情報に基づいて前記ユーザの認証状態および前記操作の認可状態を確認し、前記ユーザが認証済みであり且つ前記操作が認可済みであることが確認されると前記所定の操作を実現する機能部に対して前記操作要求を伝達する認証部（４）と、
前記認証部による前記ユーザの認証状態および前記ユーザによる前記操作の認可状態を管理する管理部（５）と、
前記操作要求の正当性を検証する検証部（６）と、
を備え、
前記検証部は、前記操作要求が不当であることを検出すると前記管理部に対して不当要求受信を通知し、
前記機能部は、前記検証部によって前記操作要求が不当であることが検出されると前記不当要求受信時の処置であるフェールセーフ処理を実施し、
前記管理部は、前記不当要求受信が通知されると、前記検証部により不当であることが検出された前記操作要求を与えた前記ユーザである不当要求元ユーザの前記認証状態を認証がなされていない状態である未認証状態とするように前記認証情報を変更し、その状態を前記不当要求元ユーザから再度認証が要求されるまで継続し、
前記管理部は、同一の前記不当要求元ユーザの前記認証状態を前記未認証状態とするように前記認証情報を変更した回数が所定回数に達すると、前記不当要求元ユーザの前記認証状態を認証に関する異常が生じている状態である異常状態とするように前記認証情報を変更し、その状態を通常の認証の要求に関する処置とは異なる異常解除のための処置が実施されるまで継続する認証管理装置。

【請求項2】

車両（２）のユーザ（３）から前記車両に関する所定の操作を要求する操作要求が与えられると、前記ユーザの認証に関する認証情報および前記操作の認可に関する認可情報に基づいて前記ユーザの認証状態および前記操作の認可状態を確認し、前記ユーザが認証済みであり且つ前記操作が認可済みであることが確認されると前記所定の操作を実現する機能部に対して前記操作要求を伝達する認証部（４）と、
前記認証部による前記ユーザの認証状態および前記ユーザによる前記操作の認可状態を管理する管理部（５）と、
前記操作要求の正当性を検証する検証部（６）と、
を備え、
前記検証部は、前記操作要求が不当であることを検出すると前記管理部に対して不当要求受信を通知し、
前記機能部は、前記検証部によって前記操作要求が不当であることが検出されると前記不当要求受信時の処置であるフェールセーフ処理を実施し、
前記管理部は、前記不当要求受信が通知されると、前記検証部により不当であることが検出された前記操作要求を与えた前記ユーザである不当要求元ユーザによる少なくとも１つの前記操作についてその実行を認めない不認可状態とするように前記認可情報を変更する認証管理装置。

【請求項3】

前記管理部は、同一の前記不当要求元ユーザに対応する前記不当要求受信が通知されるたびに、前記不認可状態とする前記操作が漸増するように前記認可情報を変更する請求項２に記載の認証管理装置。

【請求項4】

前記認証部は、前記管理部により前記認証情報および前記認可情報のうち少なくとも一方が変更された後に前記不当要求元ユーザから前記操作要求が与えられると、変更後の前記認証情報および前記認可情報に基づいて全ての前記機能部に対して前記操作要求を伝達するか否かを判断する請求項１から３のいずれか一項に記載の認証管理装置。

【請求項5】

車両のユーザから前記車両に関する所定の操作を要求する操作要求が与えられると、前記ユーザの認証に関する認証情報および前記操作の認可に関する認可情報に基づいて前記ユーザの認証状態および前記操作の認可状態を確認し、前記ユーザが認証済みであり且つ前記操作が認可済みであることが確認されると前記所定の操作を実現する機能部に対して前記操作要求を伝達する認証手順と、
前記認証手順による前記ユーザの認証状態および前記ユーザによる前記操作の認可状態を管理する管理手順と、
前記操作要求の正当性を検証する検証手順と、
を含み、
前記検証手順では、前記操作要求が不当であることが検出されると不当要求受信を通知し、
前記機能部は、前記検証手順によって前記操作要求が不当であることが検出されると前記不当要求受信時の処置であるフェールセーフ処理を実施し、
前記管理手順では、前記不当要求受信が通知されると、前記検証手順により不当であることが検出された前記操作要求を与えた前記ユーザである不当要求元ユーザの前記認証状態を認証がなされていない状態である未認証状態とするように前記認証情報を変更し、その状態を前記不当要求元ユーザから再度認証が要求されるまで継続し、
前記管理手順では、同一の前記不当要求元ユーザの前記認証状態を前記未認証状態とするように前記認証情報を変更した回数が所定回数に達すると、前記不当要求元ユーザの前記認証状態を認証に関する異常が生じている状態である異常状態とするように前記認証情報を変更し、その状態を通常の認証の要求に関する処置とは異なる異常解除のための処置が実施されるまで継続する認証管理方法。

【請求項6】

車両のユーザから前記車両に関する所定の操作を要求する操作要求が与えられると、前記ユーザの認証に関する認証情報および前記操作の認可に関する認可情報に基づいて前記ユーザの認証状態および前記操作の認可状態を確認し、前記ユーザが認証済みであり且つ前記操作が認可済みであることが確認されると前記所定の操作を実現する機能部に対して前記操作要求を伝達する認証手順と、
前記認証手順による前記ユーザの認証状態および前記ユーザによる前記操作の認可状態を管理する管理手順と、
前記操作要求の正当性を検証する検証手順と、
を含み、
前記検証手順では、前記操作要求が不当であることが検出されると不当要求受信を通知し、
前記機能部は、前記検証手順によって前記操作要求が不当であることが検出されると前記不当要求受信時の処置であるフェールセーフ処理を実施し、
前記管理手順では、前記不当要求受信が通知されると、前記検証手順により不当であることが検出された前記操作要求を与えた前記ユーザである不当要求元ユーザによる少なくとも１つの前記操作についてその実行を認めない不認可状態とするように前記認可情報を変更する認証管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、車両のユーザの認証状態を管理する認証管理装置および認証管理方法に関する。

【背景技術】

【0002】

車両には、各種の機器が搭載されており、それぞれの機器がネットワークで接続されている。このような車両のユーザについては、１つの認証方法または複数の異なる認証方法に基づいて認証が行われ、認証されると各種の機器の操作を行うことが可能となる。また、特許文献１、２および３に開示されているように、複数のユーザに対して各種の機器の操作権限を与えつつ、ユーザの認証段階でユーザを識別することによって操作権限を抑制するといった技術が提案されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１７－００１６１５号公報

【文献】特開２０１９－０３４６３８号公報

【文献】特開２００６－０７７４３１号公報

【発明の概要】

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

【0004】

このような車両において、特に開いたネットワークに接続された機器については、外部からの様々な攻撃に対して、機器の動作および機器内の情報を保護するための対策が必要となる。外部からの攻撃としては、例えば認証済みの正規のユーザに成りすました悪意のある第三者がネットワークに侵入して機器を操作するといったタイプの攻撃が挙げられる。認証方法が物理的な鍵またはＦＯＢキーだけである場合、対象の鍵をロックする対処になるが、生体認証、スマホ認証などが用いられることによりユーザの認証方法が多様化した場合には、認証方法自体をロックするだけでは対策が不十分になるおそれがある。

【0005】

本発明は上記事情に鑑みてなされたものであり、その目的は、正規のユーザに成りすました悪意のある第三者による攻撃への対応を行うことができる認証管理装置および認証管理方法を提供することにある。

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

【0006】

請求項１に記載の認証管理装置は、認証部（４）と、管理部（５）と、検証部（６）と、を備える。認証部は、車両（２）のユーザ（３）から前記車両に関する所定の操作を要求する操作要求が与えられると、前記ユーザの認証に関する認証情報および前記操作の認可に関する認可情報に基づいて前記ユーザの認証状態および前記操作の認可状態を確認し、前記ユーザが認証済みであり且つ前記操作が認可済みであることが確認されると前記所定の操作を実現する機能部に対して前記操作要求を伝達する。管理部は、前記認証部による前記ユーザの認証状態および前記ユーザによる前記操作の認可状態を管理する。検証部は、前記操作要求の正当性を検証する。前記検証部は、前記操作要求が不当であることを検出すると前記管理部に対して不当要求受信を通知する。前記機能部は、前記検証部によって前記操作要求が不当であることが検出されると前記不当要求受信時の処置であるフェールセーフ処理を実施する。前記管理部は、前記不当要求受信が通知されると、前記検証部により不当であることが検出された前記操作要求を与えた前記ユーザである不当要求元ユーザの前記認証状態を認証がなされていない状態である未認証状態とするように前記認証情報を変更し、その状態を前記不当要求元ユーザから再度認証が要求されるまで継続する。前記管理部は、同一の前記不当要求元ユーザの前記認証状態を前記未認証状態とするように前記認証情報を変更した回数が所定回数に達すると、前記不当要求元ユーザの前記認証状態を認証に関する異常が生じている状態である異常状態とするように前記認証情報を変更し、その状態を通常の認証の要求に関する処置とは異なる異常解除のための処置が実施されるまで継続する。

【0007】

このような構成によれば、悪意のある第三者が正規のユーザに成りすまして所定の操作を要求をしたとしても、検証部によって、その悪意のある第三者から与えられた操作要求が不当であることを検出できるようになる。操作要求が不当であることが検出されると、検証部から管理部に対して不当要求受信が通知されることにより、管理部は、悪意のある第三者である不当要求元ユーザに対応する認証情報および認可情報のうち少なくとも一方を変更する。このようにすれば、悪意のある第三者について、所定の操作を制限したり、所定の操作を禁止したり、といった対応を迅速に行うことが可能となる。したがって、上記構成によれば、正規のユーザに成りすました悪意のある第三者による攻撃への対応を行うことができるという優れた効果が得られる。

【図面の簡単な説明】

【0008】

【図1】一実施形態に係る認証管理装置の構成を模式的に示す図

【図2】一実施形態に係る機能部により実行される処理の具体的な内容の一例を示す図

【図3】一実施形態に係る第１変更手法が採用された場合の管理部により実行される処理の具体的な内容の一例を示す図

【図4】一実施形態に係る第２変更手法が採用された場合の管理部により実行される処理の具体的な内容の一例を示す図

【図5】一実施形態に係る第３変更手法が採用された場合の管理部により実行される処理の具体的な内容の一例を示す図

【図6】一実施形態に係る第４変更手法が採用された場合の管理部により実行される処理の具体的な内容の一例を示す図

【図7】一実施形態に係る認証管理方法を説明するための図であり、第１具体的事例における各部の処理の流れを示す図

【図8】一実施形態に係る認証管理方法を説明するための図であり、第２具体的事例における各部の処理の流れを示す図

【図9】一実施形態に係る認証管理方法を説明するための図であり、第３具体的事例における各部の処理の流れを示す図

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

【0009】

以下、認証管理装置および認証管理方法の実施形態について図面を参照して説明する。
図１に示すように、認証管理装置１は、自動車などの車両２に設けられるものであり、後述する各種の手順を含む認証管理方法によって車両２のユーザ３の認証状態などを管理する。認証管理装置１は、認証部４、管理部５、検証部６などを備えている。認証部４は、車両２のユーザ３から車両２に関する所定の操作を要求する操作要求が与えられると、ユーザ３の認証に関する認証情報および操作の認可に関する認可情報に基づいてユーザ３の認証状態および操作の認可状態を確認する。

【0010】

認証部４は、物理的な鍵またはＦＯＢキーだけではなく、生体認証、スマホ認証などの複数の異なる認証方法のうち少なくともいずれか１つに基づいて認証を行うようになっている。認証部４は、ＮＦＣなどの読み取り装置および読み取り結果を照合してユーザ３を認証する装置などから構成されている。車両２に関する所定の操作としては、例えば、ドアロックの施錠、開錠、ドアの開閉、エンジンの始動、停止、エアコンの操作、ナビゲーション装置の操作、オーディオ機器の操作、自動運転に関する各種の操作などが挙げられる。

【0011】

この場合、ユーザ３としては、車両２の所有者に加え、所有者の家族なども想定されており、それぞれのユーザ毎に、各種の操作に対する操作権限、つまり操作の許可または禁止が設定されている。操作の認可情報には、ユーザ毎の操作権限を表す情報が含まれている。認証部４は、ユーザ３が認証済みであり且つそのユーザ３が要求する操作が認可済みであることが確認されると、車両２に設けられた複数の機能部７、８、９および１０のうち該当する操作を実現する機能部に対してユーザ３から与えられた操作要求を伝達する。認証部４により実行される各処理は、認証手順に相当する。

【0012】

図１には、４つの機能部７～１０が示されているが、機能部の数は３つ以下でもよいし、５つ以上でもよい。機能部７～１０には、車両２に搭載される電子制御装置などの各種の機器により実行されて所定の操作を実現する操作プログラム、つまりアプリケーションが含まれる。本明細書では、電子制御装置のことをＥＣＵと称することがあるとともに、アプリケーションのことをアプリと称することがある。また、機能部７～１０には、車両２に搭載されて所定の操作を実現するＥＣＵなどの車載装置が含まれる。この場合、認証部４、管理部５および機能部７～１０は、車両２に搭載されたネットワークにより接続されており、それぞれの間においてデータの送受信が可能に構成されている。

【0013】

管理部５は、認証部４によるユーザ３の認証状態およびユーザ３による操作の認可状態を管理する。この場合、管理部５は、車両２に搭載されるＥＣＵに含まれる。管理部５は、ＥＣＵが備えるＣＰＵが非遷移的実体的記憶媒体に格納されているコンピュータプログラムを実行してコンピュータプログラムに対応する処理を実行することにより実現されている、つまりソフトウェアにより実現されている。なお、管理部５のうち少なくとも一部をハードウェアにより実現する構成としてもよい。管理部５により実行される各処理は、管理手順に相当する。

【0014】

機能部７～１０は、いずれも認証部４から伝達される操作要求の正当性を検証する検証部６を備えている。検証部６は、機能部７～１０がアプリである場合、そのアプリに含まれる形で設けられている。また、検証部６は、機能部７～１０が車載装置である場合、その車載装置が備えるＣＰＵが非遷移的実体的記憶媒体に格納されているコンピュータプログラムを実行してコンピュータプログラムに対応する処理を実行することにより実現されている、つまりソフトウェアにより実現されている。なお、検証部６のうち少なくとも一部をハードウェアにより実現する構成としてもよい。検証部６により実行される各処理は、検証手順に相当する。

【0015】

検証部６は、操作要求が不当であることを検出すると管理部５に対して、ユーザ３から与えられた操作要求が不当であったことを表す不当要求受信を通知する。検証部６は、次の３つのうち少なくとも１つの検証手法に基づいて操作要求の正当性を検証する。
［１］第１検証手法
第１検証手法では、検証部６は、現在の車両２の状態と照らし合わせて、要求された操作が実現可能なものである場合には操作要求が正当であると判断するとともに、要求された操作が実現不可能なものである場合に操作要求が不当であると判断する。例えば、検証部６は、運転席に運転者が不在であるにもかかわらず自動運転の解除を要求するような操作要求が与えられた場合、その操作要求が不当であると判断する。

【0016】

［２］第２検証手法
第２検証手法では、検証部６は、現在の車両２の状態と照らし合わせて、要求された操作が実現すべきものである場合には操作要求が正当であると判断するとともに、要求された操作が実現すべきではないものである場合には操作要求が不当であると判断する。例えば、検証部６は、車両２が走行中であるにもかかわらずドアを開放するような操作要求が与えられた場合、その操作要求が不当であると判断する。

【0017】

［３］第３検証手法
第３検証手法では、検証部６は、ユーザ３の通常の操作パターンと照らし合わせて、要求された操作が通常の操作パターンに沿った操作である場合には操作要求が正当であると判断するとともに、要求された操作が通常の操作パターンに沿っていない操作である場合には操作要求が不当であると判断する。例えば、検証部６は、車両２が、ユーザ３が普段行くことがないような場所に向かうような操作が要求された場合、その操作要求が不当であると判断する。また、例えば、検証部６は、ナビゲーション装置などの目的地としてユーザ３が普段行くことがないような場所を設定するような操作要求が与えられた場合、その操作要求が不当であると判断する。

【0018】

検証部６によって操作要求が不当であることが検出されると、機能部７～１０は、不当要求受信時の処置であるフェールセーフ処理を実施する。フェールセーフ処理の具体例としては、「自動運転を停止するとともに車両２を路肩に停止させる」という処理、「所定の制御を停止する要求があった際、その制御を停止させると安全面で問題が生じる場合には、その制御を停止させない」という処理、「所定の制御を実行する要求があった際、その制御を実行させると安全面で問題が生じる場合には、その制御を実行させない」という処理などが挙げられる。

【0019】

検証部６を含む機能部７～１０により実行される処理の具体的な内容は、例えば図２に示すようなものとなる。まず、ステップＳ１０１では、認証部４から操作要求が伝達されたか否かが判断される。操作要求が伝達されていない場合、ステップＳ１０１で「ＮＯ」となり、本処理が終了となる。一方、操作要求が伝達された場合、ステップＳ１０１で「ＹＥＳ」となり、ステップＳ１０２に進む。

【0020】

ステップＳ１０２では、伝達された操作要求の正当性が検証部６によって検証される、つまり伝達された操作要求が正当であるか否かが判断される。伝達された操作要求が正当である場合、ステップＳ１０２で「ＹＥＳ」となり、ステップＳ１０３に進む。ステップＳ１０３では、伝達された操作要求に対応した所定の操作が実行される。ステップＳ１０３の実行後、本処理が終了となる。一方、伝達された操作要求が不当である場合、ステップＳ１０２で「ＮＯ」となり、ステップＳ１０４に進む。ステップＳ１０４では、フェールセーフ処理が実行される。ステップＳ１０４の実行後はステップＳ１０５に進む。ステップＳ１０５では、管理部５に対して不当要求受信が通知される。ステップＳ１０５の実行後、本処理が終了となる。

【0021】

管理部５は、検証部６から不当要求受信が通知されると、検証部６により不当であることが検出された操作要求を与えたユーザ３である不当要求元ユーザに対応する認証情報および認可情報のうち少なくとも一方を所定のポリシーに則って変更する。管理部５による認証情報および認可情報の変更については、次の４つの変更手法のうちいずれかを採用することができる。

【0022】

［１］第１変更手法
第１変更手法では、管理部５は、不当要求受信が通知されると、不当要求元ユーザの認証状態を認証がなされていない状態である未認証状態とするように認証情報を変更する。管理部５は、認証状態を未認証状態に変更した状態を、不当要求元ユーザから再度認証が要求されるまで継続する。

【0023】

［２］第２変更手法
第２変更手法では、管理部５は、不当要求受信が通知されると、不当要求元ユーザの認証状態を認証に関する異常が生じている状態である異常状態とするように認証情報を変更する。管理部５は、認証状態を異常状態に変更した状態を、通常の認証の要求に関する処置とは異なる異常解除のための処置が実施されるまで継続する。

【0024】

［３］第３変更手法
第３変更手法では、管理部５は、不当要求受信が通知されると、不当要求元ユーザによる少なくとも１つの操作について、その実行を認めない不認可状態とするように認可情報を変更する。この場合、管理部５は、同一の不当要求元ユーザに対応する不当要求受信が通知されるたびに、不認可状態とする操作が漸増するように認可情報を変更することができる。この場合、管理部５は、安全への影響が大きい操作から順番に不認可状態とするように、認可情報を変更するとよい。

【0025】

［４］第４変更手法
第４変更手法では、第１変更手法と同様、管理部５は、不当要求受信が通知されると、不当要求元ユーザの認証状態を認証がなされていない状態である未認証状態とするように認証情報を変更し、その状態を不当要求元ユーザから再度認証が要求されるまで継続する。管理部５は、同一の不当要求元ユーザの認証状態を未認証状態とするように認証情報を変更した回数が所定回数に達すると、不当要求元ユーザの認証状態を異常状態とするように認証情報を変更し、その状態を異常解除のための処置が実施されるまで継続する。

【0026】

管理部５により実行される処理の具体的な内容は、例えば図３～図６に示すようなものとなる。図３は、第１変更手法が採用された場合の処理内容を表している。図３に示す処理において、ステップＳ２０１では、機能部７～１０から不当要求受信が通知されたか否かが判断される。不当要求受信が通知されていない場合、ステップＳ２０１で「ＮＯ」となり、本処理が終了となる。一方、不当要求受信が通知された場合、ステップＳ２０１で「ＹＥＳ」となり、ステップＳ２０２に進む。ステップＳ２０２では、不当要求元ユーザの認証状態を未認証状態とするように認証情報が更新される。ステップＳ２０２の実行後、本処理が終了となる。

【0027】

図４は、第２変更手法が採用された場合の処理内容を表している。図４に示す処理は、図３に示した処理に対し、ステップＳ２０２に代えてステップＳ２０３が設けられている点が異なる。ステップＳ２０３では、不当要求元ユーザの認証状態を異常状態とするように認証情報が更新される。図５は、第３変更手法が採用された場合の処理内容を表している。図５に示す処理は、図３に示した処理に対し、ステップＳ２０２に代えてステップＳ２０４が設けられている点が異なる。ステップＳ２０４では、不当要求元ユーザによる少なくとも１つの操作について不認可状態とするように認可情報が更新される。

【0028】

図６は、第４変更手法が採用された場合の処理内容を表している。図６に示す処理は、図３に示した処理に対しステップＳ２０５およびＳ２０６が追加されている点が異なる。この場合、ステップＳ２０１で「ＹＥＳ」になるとステップＳ２０５に進む。ステップＳ２０５では、同一の不当要求元ユーザの認証状態を未認証状態とするように認証情報を変更した回数である変更回数Ｎが所定の閾値回数Ｔｈに達したか否かが判断される。変更回数Ｎが閾値回数Ｔｈに達していない場合、ステップＳ２０５で「ＮＯ」となり、本処理が終了となる。

【0029】

一方、変更回数Ｎが閾値回数Ｔｈに達した場合、ステップＳ２０５で「ＹＥＳ」となり、ステップＳ２０６に進む。ステップＳ２０６では、不当要求元ユーザの認証状態を異常状態とするように認証情報が更新される。ステップＳ２０６の実行後、本処理が終了となる。認証部４は、上述したように管理部５により認証情報および認可情報のうち少なくとも一方が変更された後に不当要求元ユーザから操作要求が与えられると、変更後の認証情報および認可情報に基づいて機能部７～１０に対して操作要求を伝達するか否かを判断する。

【0030】

次に、上記構成の作用について図７～図９を参照して説明する。
本実施形態の認証管理装置１により実現される認証管理方法について、３つの具体的事例に沿って説明する。
［１］第１具体的事例
第１具体的事例は、車両２の所有者である正規のユーザ３が認可された操作を要求した場合の事例であり、この場合の各部の処理の流れは、例えば図７に示すようなものとなる。なお、この場合、正規のユーザ３のことをユーザ３Ａと称することとする。まず、ステップＳ３０１では、ユーザ３Ａから認証部４に対して車両２に関する所定の操作を要求する操作要求が与えられる。ステップＳ３０２では、認証部４から管理部５に対してユーザ３Ａに関する認証情報および認可情報の問い合わせが行われる。

【0031】

ステップＳ３０３では、管理部５から認証部４に対してユーザ３Ａに関する認証情報および認可情報が与えられる。ステップＳ３０４では、認証部４によりユーザ３Ａの認証状態およびユーザ３Ａが要求した操作の認可状態が確認される。この場合、ユーザ３Ａが正規のユーザであるため、ステップＳ３０４では、ユーザ３Ａが認証済みであり且つユーザ３Ａが要求した操作が認可済みであることが確認される。

【0032】

そのため、ステップＳ３０５では、認証部４からユーザ３Ａが要求した操作を実現する機能部７～１０に対してユーザ３Ａから与えられた操作要求が伝達される。ステップＳ３０６では、機能部７～１０の検証部６により伝達された操作要求の正当性が検証される。この場合、正規のユーザであるユーザ３Ａが認可された操作を要求したものであるため、検証部６により操作要求が正当であることが検出される。そのため、ステップＳ３０７では、機能部７～１０により伝達された操作要求に対応した所定の操作が実行される。

【0033】

［２］第２具体的事例
第２具体的事例は、正規のユーザに成りすました悪意のある第三者であるユーザ３が操作を要求した場合の事例であり、この場合の各部の処理の流れは、例えば図８に示すようなものとなる。なお、この場合、悪意のある第三者であるユーザ３のことをユーザ３Ｂと称することとする。まず、ステップＳ４０１では、ユーザ３Ｂから認証部４に対して車両２に関する所定の操作を要求する操作要求が与えられる。

【0034】

ステップＳ４０２では、認証部４から管理部５に対してユーザ３Ｂに関する認証情報および認可情報の問い合わせが行われる。ステップＳ４０３では、管理部５から認証部４に対してユーザ３Ｂに関する認証情報および認可情報が与えられる。ステップＳ４０４では、認証部４によりユーザ３Ｂの認証状態およびユーザ３Ｂが要求した操作の認可状態が確認される。

【0035】

この場合、ユーザ３Ｂは、悪意のある第三者であるものの、正規のユーザに成りすましているため、ステップＳ４０４では、ユーザ３Ｂが認証済みであり且つユーザ３Ｂが要求した操作が認可済みであることが確認されてしまう。そのため、ステップＳ４０５では、認証部４からユーザ３Ｂが要求した操作を実現する機能部７～１０に対してユーザ３Ｂから与えられた操作要求が伝達される。ステップＳ４０６では、機能部７～１０の検証部６により伝達された操作要求の正当性が検証される。

【0036】

この場合、正規のユーザではないユーザ３Ｂが認可された操作を要求したものであるため、検証部６により操作要求が不当であることが検出される。そのため、ステップＳ４０７では、機能部７～１０から管理部５に対して不当要求受信が通知される。また、このとき、機能部７～１０では、フェールセーフ処理が実行される。ステップＳ４０８では、管理部５によりユーザ３Ｂに対応する認証情報および認可情報のうち少なくとも一方が更新される。

【0037】

［３］第３具体的事例
第３具体的事例は、車両の所有者である正規のユーザの例えば子供などの家族であるユーザ３が認可されていない操作を要求した場合の事例であり、この場合の各部の処理の流れは、例えば図９に示すようなものとなる。なお、この場合、正規のユーザの家族であるユーザ３のことをユーザ３Ｃと称することとする。まず、ステップＳ５０１では、ユーザ３Ｃから認証部４に対して車両２に関する所定の操作を要求する操作要求が与えられる。

【0038】

ステップＳ５０２では、認証部４から管理部５に対してユーザ３Ｃに関する認証情報および認可情報の問い合わせが行われる。ステップＳ５０３では、管理部５から認証部４に対してユーザ３Ｃに関する認証情報および認可情報が与えられる。ステップＳ５０４では、認証部４によりユーザ３Ｃの認証状態およびユーザ３Ｃが要求した操作の認可状態が確認される。

【0039】

この場合、ユーザ３Ｃは、正規のユーザの家族であるものの、認可されていない操作を要求しているため、ステップＳ５０４では、ユーザ３Ｃが認証済みであることが確認されるとともにユーザ３Ｂが要求した操作が認可済みでないことが確認される。そのため、ステップＳ５０５では、認証部４からユーザ３Ｃに対して要求した操作が禁止された操作である旨を表すエラーが通知される。なお、このようなエラー通知は、車両２に搭載されたディスプレイ、スピーカーなどを用いて実施することができる。

【0040】

以上説明した本実施形態によれば、悪意のある第三者が正規のユーザ３に成りすまして所定の操作を要求をしたとしても、検証部６によって、その悪意のある第三者から与えられた操作要求が不当であることを検出できるようになる。操作要求が不当であることが検出されると、検証部６から管理部５に対して不当要求受信が通知されることにより、管理部５は、悪意のある第三者である不当要求元ユーザに対応する認証情報および認可情報のうち少なくとも一方を変更する。このようにすれば、悪意のある第三者について、所定の操作を制限したり、所定の操作を禁止したり、といった対応を迅速に行うことが可能となる。したがって、本実施形態によれば、正規のユーザ３に成りすました悪意のある第三者による攻撃への対応を行うことができるという優れた効果が得られる。

【0041】

管理部５は、不当要求受信が通知されると、不当要求元ユーザの認証状態を未認証状態とするように認証情報を変更し、その状態を不当要求元ユーザから再度認証が要求されるまで継続することができる。このようにすれば、認証に関する特別な処理を別途追加することなく、正規のユーザ３に成りすました悪意のある第三者による攻撃への対応が可能となる。また、管理部５は、不当要求受信が通知されると、不当要求元ユーザの認証状態を異常状態とするように認証情報を変更し、その状態を異常解除のための処置が実施されるまで継続することができる。このようにすれば、悪意のある第三者である不当要求元ユーザは、認証情報が一旦異常状態に変更されると通常の認証の要求に関する処置とは異なる特別な処置を行わない限り再び攻撃を行うことができなくなるため、安全性が向上する。

【0042】

また、管理部５は、不当要求受信が通知されると、不当要求元ユーザによる少なくとも１つの操作について不認可状態とするように認可情報を変更する。このようにすれば、悪意のある第三者である不当要求元ユーザは、一旦所定の操作について不認可状態にされると、その後はその操作を行うことができなくなるため、安全性が向上する。さらに、管理部５は、同一の不当要求元ユーザに対応する不当要求受信が通知されるたびに、不認可状態とする操作が漸増するように認可情報を変更することができる。この場合、管理部５は、安全への影響が大きい操作から順番に不認可状態とするように、認可情報を変更するとよい。このようにすれば、悪意のある第三者である不当要求元ユーザから攻撃を受けるたびに安全への影響を大きい操作から順番に不認可状態にされてゆくことになり、安全性が一層向上する。

【0043】

検証部６は、正規のユーザ３により要求された操作が不当であると誤判断してしまう可能性がある。ただし、上記した誤判断が連続して発生する可能性は非常に低いものとなる。そこで、管理部５は、同一の不当要求元ユーザの認証状態を未認証状態とするように認証情報を変更した回数が所定回数に達すると、不当要求元ユーザの認証状態を異常状態とするように認証情報を変更し、その状態を異常解除のための処置が実施されるまで継続することができる。

【0044】

このようにすれば、仮に検証部６において上記誤判断が発生した場合、正規のユーザ３は、その認証状態が一旦未認証状態とされるものの、次回以降の操作を要求する際に再度認証されることで通常通り操作を行うことが可能となる。これに対し、正規のユーザ３に成りすました悪意のある第三者により要求された操作については検証部６によって連続して不当であると判断される可能性が高い。そのため、上記した変更手法によれば、悪意のある第三者は、何度か操作の要求を行うことにより、その認証情報が異常状態に変更されてしまい、その後は通常の認証の要求に関する処置とは異なる特別な処置を行わない限り再び攻撃を行うことができなくなる。

【0045】

認証部４は、管理部５により認証情報および認可情報のうち少なくとも一方が変更された後に不当要求元ユーザから操作要求が与えられると、変更後の認証情報および認可情報に基づいて全ての機能部７～１０に対して操作要求を伝達するか否かを判断するようになっている。このようにすれば、機能部７～１０のうち少なくとも１つの機能部に含まれる検証部６によりその機能部に対する操作要求が不当であると判断されると、その操作要求を与えた不当要求元ユーザは、他の機能部に対する操作についても制限または禁止されることになるため、悪意のある第三者による攻撃への対応を一層確実に行うことができる。

【0046】

（その他の実施形態）
なお、本発明は上記し且つ図面に記載した実施形態に限定されるものではなく、その要旨を逸脱しない範囲で任意に変形、組み合わせ、あるいは拡張することができる。
上記実施形態で示した数値などは例示であり、それに限定されるものではない。

【0047】

検証部６は、全ての機能部７～１０の全てに対応して設けられていたが、機能部７～１０のうち少なくとも１つに対応して設けられていればよい。また、検証部６は、機能部７～１０に含まれる形で設けられていたが、機能部７～１０とは独立した形で設けられてもよい。
管理部５は、不当要求受信が通知された際、上記実施形態で示した第１～第４変更手法に限らず、所定のポリシーに則って不当要求元ユーザに対応する認証情報および認可情報のうち少なくとも一方を変更すればよい。

【0048】

本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。

【0049】

本開示に記載の制御部およびその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサおよびメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部およびその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部およびその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサおよびメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。

【符号の説明】

【0050】

１…認証管理装置、２…車両、３…ユーザ、４…認証部、５…管理部、６…検証部、７～１０…機能部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】