JP7147947B2 - 電子制御装置及びプログラム - Google Patents
電子制御装置及びプログラム Download PDFInfo
- Publication number
- JP7147947B2 JP7147947B2 JP2021165793A JP2021165793A JP7147947B2 JP 7147947 B2 JP7147947 B2 JP 7147947B2 JP 2021165793 A JP2021165793 A JP 2021165793A JP 2021165793 A JP2021165793 A JP 2021165793A JP 7147947 B2 JP7147947 B2 JP 7147947B2
- Authority
- JP
- Japan
- Prior art keywords
- function
- return
- importance
- program
- processing instruction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/54—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/002—Countermeasures against attacks on cryptographic mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/84—Vehicles
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
Description
本発明は、バッファオーバーフロー攻撃に対して耐性を有するプログラムの生成方法および当該プログラムを搭載する電子制御装置に関し、主として自動車の車載システムに搭載されるプログラムおよび電子制御装置に関するものである。
バッファオーバーフロー攻撃は、実行中のプログラムのメモリ内に攻撃者の作成したプログラムが送り込まれることにより実行され、この結果コンピュータの制御が奪われてしまう。具体的には、攻撃者が送り込んだプログラムによって、例えばスタックに置かれたリターンアドレスが変更され、当該プログラムに制御が移ることによりコンピュータの制御が奪われてしまうものである。
バッファオーバーフロー攻撃に対しては様々な解決策が提案されている、その一つに攻撃者がリターンアドレスを修正することを許容するが、損害が生じる前にこの変更を検出する制御フローインテグリティ(CFI)技術がある。このCFI技術では、プログラムコードにおいて関数から別の関数へとコール又はリターンする際に、コール先又はリターン先の関数のIDをチェックし、コール先又はリターン先の関数のIDが許可されている場合にコール/リターン処理を実行するものである。しかし、CFIにおいては、プログラム実行に際してチェック処理に時間を要するという課題を有している。
かかる課題を解決するため、例えば特許文献1には、プログラム命令を特定領域のメモリに格納し、ジャンプ/リターン時に目的アドレスをマスクすることで、攻撃者が単純にジャンプ/リターンアドレスを修正しても有用な操作を行うことを制限することでチェック処理によるオーバーヘッドが生じるという課題を解決することが記載されている。
また、特許文献2には、時間的オーバーヘッド、および空間的オーバーヘッドを抑制しつつ、ドメイン間の実行制限を考慮して、非信頼ドメインからの関数コール時と関数リターン時のアドレスチェックを効率よく行うことが記載されている。
さらに、非特許文献1には、保護された領域であるシャドウコールスタック(Shadow call stack)領域に関数のリターンアドレスを格納し、当該リターンアドレスへとリターン処理を実行することにより、関数がリターンする際にリターン先のIDをチェックしなくとも、コール元である正しいリターン先へとリターンできることが記載されている。
Martin Abadi, Mihai Budiu, Ulfar Erlingsson, and Jay Ligatti著、「Control-flow integrity」、ACM Conference on Computer and Communications Security,(米国)2005年11月、p.340-353
しかし、特許文献1は、従来のCFI技術とは異なるアプローチであり、CFI技術に対して直接適用できるものではない。
また、特許文献2では、非信頼ドメイン内の関数コール/リターンはチェック対象外となってしまい、非信頼ドメイン内では不適切な関数コール/リターンによって、設計者の意図しない命令列を実行してしまう恐れがある。
さらに、非特許文献1に記載のアプローチによると、全てのリターンアドレスをシャドウコールスタック領域に格納することにより、オーバーヘッドが著しく増加してしまう恐れがある。
本発明の目的は、CFI技術を用いつつ、かつドメインに依存せず、プログラム実行時のオーバーヘッドを抑制することにある。
上記課題を解決するために、本発明の電子制御装置(20)は、プログラムコード内の関数のコール/リターン関係である制御フローを正しく実行するための処理命令であり、かつ前記関数の重要度に基づいて実行するか否かが選択可能な前記処理命令が前記プログラムコード内に挿入されているプログラムを実行する演算部(101)と、前記関数の重要度に基づいて、前記プログラムコード内に挿入された前記処理命令のうち実行する処理命令を選択する処理命令選択部(201)と、を有する。
本発明の電子制御装置及びプログラムによれば、CFI技術を用いつつ、かつドメインに依存せず、プログラム実行時のオーバーヘッドを抑制することができる。
以下、本発明のプログラム生成方法、および当該プログラムを搭載した電子制御装置の構成及び機能について、図面を参照して説明する。なお、本発明とは、特許請求の範囲又は課題を解決するための手段の項に記載された発明を意味するものであり、以下の実施形態に限定されるものではない。また、鉤括弧内の語は、特許請求の範囲又は課題を解決するための手段の項に記載された語を意味し、同じく以下の実施形態に限定されるものではない。
また、特許請求の範囲の従属項に記載の構成及び方法、従属項に記載の構成及び方法に対応する実施形態の構成及び方法、および特許請求の範囲に記載がなく実施形態等のみに記載の構成及び方法は、本発明においては任意の構成及び方法である。
なお、各実施形態に開示の構成は、各実施形態のみで閉じるものではなく、実施形態をまたいで組み合わせることが可能である。
発明が解決しようとする課題に記載した課題は公知の課題ではなく、本発明者が独自に知見したものであり、本発明の手段と共に発明の進歩性を肯定する事実である。
また、特許請求の範囲の従属項に記載の構成及び方法、従属項に記載の構成及び方法に対応する実施形態の構成及び方法、および特許請求の範囲に記載がなく実施形態等のみに記載の構成及び方法は、本発明においては任意の構成及び方法である。
なお、各実施形態に開示の構成は、各実施形態のみで閉じるものではなく、実施形態をまたいで組み合わせることが可能である。
発明が解決しようとする課題に記載した課題は公知の課題ではなく、本発明者が独自に知見したものであり、本発明の手段と共に発明の進歩性を肯定する事実である。
なお、以下の実施形態は、主として自動車の車載用電子制御装置および当該電子制御装置に書き込まれるプログラムを例として説明するが、本発明は、特許請求の範囲で限定がない限り、車載用途以外の電子制御装置やプログラムも含むものである。
(各実施形態に共通の構成)
図1は、本発明の実施形態に共通の各種装置の配置を示すものである。自動車の車載ネットワーク10には、N個の電子制御装置(ECU)20、プログラム生成装置30、車両制御装置40、表示装置50、データコミュニケーションモジュール(DCM)60、車両動作状態取得装置70、等が接続されている。なお、プログラム生成装置30は、常時車載ネットワーク10に接続されていてもよいし、必要なときのみコネクタとケーブル等を用いて接続されてもよい。また、プログラム生成装置30に代えて、データコミュニケーションモジュール60を介して無線通信を用いて、常時又は必要なときのみプログラム生成装置80が接続されてもよい。
図1は、本発明の実施形態に共通の各種装置の配置を示すものである。自動車の車載ネットワーク10には、N個の電子制御装置(ECU)20、プログラム生成装置30、車両制御装置40、表示装置50、データコミュニケーションモジュール(DCM)60、車両動作状態取得装置70、等が接続されている。なお、プログラム生成装置30は、常時車載ネットワーク10に接続されていてもよいし、必要なときのみコネクタとケーブル等を用いて接続されてもよい。また、プログラム生成装置30に代えて、データコミュニケーションモジュール60を介して無線通信を用いて、常時又は必要なときのみプログラム生成装置80が接続されてもよい。
(実施形態1)
1.プログラム生成方法および生成された本件プログラム
図2は、本実施形態のプログラム生成方法のフローを示すフローチャートである。フローチャートの各ステップにつき、図3から図6を参照しながら説明する。なお、このプログラムの生成方法は、図1に記載の、演算装置(CPU)およびメモリを有する専用又は汎用のプログラム生成装置30またはプログラム生成装置80を用いて実行されるが、これに代えて、プログラムが書き込まれる対象である電子制御装置(ECU)20等の内部で実行されてもよい。
1.プログラム生成方法および生成された本件プログラム
図2は、本実施形態のプログラム生成方法のフローを示すフローチャートである。フローチャートの各ステップにつき、図3から図6を参照しながら説明する。なお、このプログラムの生成方法は、図1に記載の、演算装置(CPU)およびメモリを有する専用又は汎用のプログラム生成装置30またはプログラム生成装置80を用いて実行されるが、これに代えて、プログラムが書き込まれる対象である電子制御装置(ECU)20等の内部で実行されてもよい。
まず、電子制御装置20に書き込まれるプログラムの「プログラムコード」内の「関数」、および関数のコール/リターン関係である制御フローを抽出する(S101)。プログラムの例として、自動車のシフト状態を検出し、シフトがPレンジ(駐車位置)にある場合は、シフトがPレンジにあることを表示するとともに、ドアが開くことを可能とする制御(ドアロックを解除可能とする制御)を行うものを用いて説明する。
ここで、本発明の「プログラムコード」とは、機械語やアセンブリ言語で記述されたものの他、高級言語で記述されたものも含む。
また、本発明の「関数」とは、狭義の関数の他、メソッドと呼ばれるものも含む。
ここで、本発明の「プログラムコード」とは、機械語やアセンブリ言語で記述されたものの他、高級言語で記述されたものも含む。
また、本発明の「関数」とは、狭義の関数の他、メソッドと呼ばれるものも含む。
図3は、プログラムコードから抽出した関数及び制御フローを、制御フローグラフ(CFG)として示したものである。図3の例では、プログラムコードから関数Aないし関数Dが抽出されるとともに、各関数のコール/リターン関係である制御フローが抽出されている。また、関数Bと、関数C及びDとは、自動車のシフトレバーがP(パーキング)の位置にある場合のコール/リターン関係にあることが示されている。
次に、プログラムコード内で用いられている関数について、関数ごとに「重要度」を規定したリスクランクテーブルを取得する(S102)。
本発明の「重要度」とは、所定の評価基準に基づき分類される指標であり、分類の数は複数以上であればよい。
本発明の「重要度」とは、所定の評価基準に基づき分類される指標であり、分類の数は複数以上であればよい。
具体的には、重要度とは、例えば使用機会の多少から見た重要度であり、関数の「使用頻度」に「応じて」定められたものである。
本発明の「使用頻度」とは、当該関数を実行する回数の他、当該関数を実行した合計時間など、当該関数の使用率を示すものであれば足りる。
また、本発明の「応じて」とは、直接または間接の対応関係が認められれば足りる。以下の、発明として記載された語も同様である。
本発明の「使用頻度」とは、当該関数を実行する回数の他、当該関数を実行した合計時間など、当該関数の使用率を示すものであれば足りる。
また、本発明の「応じて」とは、直接または間接の対応関係が認められれば足りる。以下の、発明として記載された語も同様である。
あるいは、重要度とは、例えば機能から見た重要度であり、具体的には、車両に搭載される電子制御装置に書き込まれたプログラムコードにおいて、プログラムコード内の関数が車両を使用するユーザの安全性に関係する場合、車両を使用するユーザの安全性に「応じて」定められたものが挙げられる。例えば、誤作動があった場合にユーザが危険にさらされるような機能、誤作動があった場合にユーザが違和感を覚える程度の機能、誤作動があった場合にも正常動作のように見えユーザが気づかないような機能、などの指標が挙げられる。本実施形態では、後述の図4の通り、これら例示した指標を、順に重要度高、重要度中、重要度低の3つに分類している。
その他、重要度とは、例えば扱うデータの重要度であり、具体的には、関数がデータを扱う場合において、扱う個人情報やデータ自体の属性の観点での指標で分類したものが挙げられる。例えば、個人情報、車両情報、走行情報、その他情報、などの指標で分類し、順に重要度1,2,3,4とすることが考えられる。
図4は、本実施形態のリスクランクテーブルの例である。図3で抽出した関数のうち、Aはメイン関数、BはシフトP状態検出に関する関数、Cはドア開制御に関する関数、DはLED『P』点灯指示に関する関数である。攻撃等により正常フロー以外でコールされることによるユーザの安全性に対する影響度という観点で各関数の重要度を評価すると以下のようになる。Aは、必ず実行する処理であるため、この評価軸での重要度について規定がない。Bは、シフトP状態のチェックが他の箇所でコールされたとしても、ユーザがシフトPに入れていなければ内部で判定結果=NG(Pでない)が返るだけでありユーザは気づかないので重要度は低と規定されている。Cは、シフトP以外の状態にも関わらず、ドア開制御が実行されると走行中にドアが開き、ユーザが危険にさらされる恐れがあるので重要度は高と規定されている。Dは、シフトP以外の状態にも関わらず、シフトPのLED点灯があるとユーザは違和感を覚えるので重要度は中と規定されている。
なお、このリスクランクテーブルは、プログラム生成方法を処理する装置内にデータベースとして持っていてもよいし、装置外に持っていてもよい。また、装置外に持っている場合は、リスクランクテーブル全てを取得してもよいし、S101で抽出した関数についてのみリスクランクテーブルを取得してもよい。
そして、S101で抽出した関数、およびS102で取得したリスクランクテーブルから、S101で抽出した関数の「重要度」を決定する(S103)。具体的には、関数Bは重要度低、関数Cは重要度高、関数Dは重要度中、と決定する。なお、本発明ではリスクランクテーブルの取得、及び重要度の決定にリスクランクテーブルを用いることは任意である。
続いて、決定した重要度に「基づいて」、制御フローが正しく実行するための処理命令をプログラムコード内に挿入する。この処理命令は、関数のコール/リターン時にコール/リターン先の関数のIDをチェックするチェック処理命令、及び、リターンアドレスをセキュア領域に格納するとともに、セキュア領域に格納されたリターンアドレスに基づいてリターン処理を実行するリターン処理命令の少なくとも一方を含む。なお、本実施形態1、及び、以下に示す実施形態2、3では、処理命令として、コール/リターン先の関数のIDをチェックするチェック処理命令を挿入している。本実施形態では、まずプログラムコード全体において、重要度が所定以上の関数を特定するとともに、重要度が所定以上の関数を対象とする制御フローを特定する(S104)。
ここで、本発明の「基づいて」とは、関数の重要度を反映したチェック処理命令の挿入がされていれば足り、重要度を直接指標として用いる場合の他、重要度に加えて重要度以外の要素も考慮する場合、および重要度に所定の演算を施したものを用いる場合も含む。以下同様。
ここで、本発明の「基づいて」とは、関数の重要度を反映したチェック処理命令の挿入がされていれば足り、重要度を直接指標として用いる場合の他、重要度に加えて重要度以外の要素も考慮する場合、および重要度に所定の演算を施したものを用いる場合も含む。以下同様。
図5は、本実施形態のCFGにおいて、所定の重要度以上の関数、および当該関数を対象とする制御フローを特定した状態を示している。図中、太線で囲まれた四角形が所定の重要度以上の関数であり、太線で示された矢印が所定の重要度以上の関数を対象とする制御フローである。本実施形態では重要度が大以上の関数、および重要度が大以上の関数を対象とする制御フローを特定している。つまり、重要度が大以上の関数は関数Cのみであるから、関数Cが呼び出し元、あるいは呼び出し先に含まれる制御フローを特定している。
次に、本実施形態では、S104で特定した制御フローを対象として、制御フローが正しく実行されるかをチェックするチェック処理命令をプログラムコード内に挿入する(S105)。
図6は、チェック処理命令を挿入したプログラムを模式的にCFGとして示すものである。本実施形態では、重要度高である関数Cを対象とする制御フローをチェックするため、関数Bから関数Cへの遷移時(関数Cのコール)、および関数Cから他の関数への遷移時のフローチェック処理を行なうチェック処理命令がそれぞれ挿入される。
つまり、本実施形態のプログラム生成方法で生成されたプログラム(以下、本件プログラムという)は、関数AないしD(本発明の「関数」に相当)、及び関数のコール/リターン関係である制御フロー(本発明の「制御フロー」に相当)をプログラムコード内に含むプログラムであり、制御フローが正しく実行されるかをチェックするチェック処理命令が関数の重要度に「基づいて」プログラムコード内に挿入されている、「コンピュータ」にて実行可能なプログラムである。
ここで、本発明の「コンピュータ」とは、マイコンやモジュール、電子制御装置などの部品レベルとして把握されるもののほか、カーナビゲーションシステムや携帯電話、スマートフォン等、完成品レベルとして把握されるものも含まれる。
ここで、本発明の「コンピュータ」とは、マイコンやモジュール、電子制御装置などの部品レベルとして把握されるもののほか、カーナビゲーションシステムや携帯電話、スマートフォン等、完成品レベルとして把握されるものも含まれる。
なお、本実施形態では、重要度として、車両を使用するユーザの安全性の指標を用いたが、これに加えて他の重要度の指標を含めてもよい。また、重要度以外の要素を考慮してもよい。
例えば、メイン関数(関数A)に関係する制御フローをチェック処理対象として加えてもよい。メイン関数はプログラム実行時に必ず実行する関数であることから、車両を使用するユーザの安全性という指標とは異なる他の重要度の指標、すなわち関数の使用頻度という重要度を含めることになる。あるいは、車両を使用するユーザの安全性という重要度以外の要素を考慮していることになる。
例えば、メイン関数(関数A)に関係する制御フローをチェック処理対象として加えてもよい。メイン関数はプログラム実行時に必ず実行する関数であることから、車両を使用するユーザの安全性という指標とは異なる他の重要度の指標、すなわち関数の使用頻度という重要度を含めることになる。あるいは、車両を使用するユーザの安全性という重要度以外の要素を考慮していることになる。
チェック処理命令の例として、あらかじめ把握している正しいコール/リターン先と、実行予定のプログラムにおけるコール/リターン先を比較して、一致すればプログラムを実行し、一致しなければプログラムの実行を停止するという命令が挙げられるが、これに限るものではない。
最後に、このようなチェック処理命令を挿入されたプログラムコードを有する本件プログラムが実装対象の電子制御装置20に書き込まれる(S106)。
なお、上述のように、当該電子制御装置20内で本実施形態のプログラム生成方法が実行される場合は、このステップは省略される。
なお、上述のように、当該電子制御装置20内で本実施形態のプログラム生成方法が実行される場合は、このステップは省略される。
以上のプログラム生成方法によれば、重要度に基づいてチェック対象の制御フローを限定することになるので、プログラム実行時の時間的(例えば、処理時間。以下同じ。)、空間的(例えば、保存領域の大きさ。以下同じ。)オーバーヘッドを抑制できるプログラムを生成することができる。
2.本件プログラムを搭載した電子制御装置
生成した本件プログラムは、車載ネットワーク10、又はDCM60を介して、本件プログラムが実行される電子制御装置(ECU)に書き込まれる。なお、本件プログラムが書き込まれ、かつ実行される電子制御装置(ECU)には、狭義の電子制御装置20の他、車両制御部40、表示装置50、DCM60、その他車載ネットワーク10に接続された情報処理装置すべてが含まれる。以下、電子制御装置20を例にして説明する。
生成した本件プログラムは、車載ネットワーク10、又はDCM60を介して、本件プログラムが実行される電子制御装置(ECU)に書き込まれる。なお、本件プログラムが書き込まれ、かつ実行される電子制御装置(ECU)には、狭義の電子制御装置20の他、車両制御部40、表示装置50、DCM60、その他車載ネットワーク10に接続された情報処理装置すべてが含まれる。以下、電子制御装置20を例にして説明する。
本件プログラムを搭載した電子制御装置20の構成を、図7を用いて説明する。電子制御装置20は、中央演算処理装置(CPU)100、及びメモリ110を有する。メモリ110には、本件プログラムが格納されている。そして、中央演算処理装置100の演算部101(本発明の「演算部」に相当)は、メモリ110に保存した本件プログラムを読み出して実行する。本件プログラムの構成は、0033段落に記載した通りである。
中央演算処理装置100の検知部102(本発明の「検知部」に相当)は、本件プログラムを実行した際に実行されるチェック処理命令の出力を監視し、制御フローの異常を検知する。具体的には、あらかじめ把握している正しいコール/リターン先と、実行予定の本件プログラムにおけるコール/リターン先を比較し、これらが一致するか否かで異常を検知する。
中央演算処理装置100の処理部103(本発明の「処理部」に相当)は、検知部102の検知結果に基づき、「所定の処理」を行なう。例えば、検知結果が異常を示した場合、本件プログラムの実行を停止する。あるいは、表示装置50を通じてユーザに通知したり、本件プログラムの実行ログを保存してもよい。本件プログラムを途中で停止することが安全上困難である場合は、例えば安全確保に関する処理(例えば車両の停止等)を行った上で停止又はリセットするなどしてもよい。
ここで、本発明の「所定の処理」とは、予め定められた一定の処理の他、条件等に応じて処理内容が変わる処理も含まれる。
ここで、本発明の「所定の処理」とは、予め定められた一定の処理の他、条件等に応じて処理内容が変わる処理も含まれる。
次に、電子制御装置20の動作を、図8を用いて説明する。
中央演算処理装置100の演算部101は、メモリ110に保存した本件プログラムを読み出して実行する(S201)。
中央演算処理装置100の演算部101は、メモリ110に保存した本件プログラムを読み出して実行する(S201)。
中央演算処理装置100の検知部102は、本件プログラムを実行した際に実行されるチェック処理命令の出力を監視し、制御フローの異常を検知する(S202)。
異常を検知した場合は、中央演算処理装置100の処理部103は、本件プログラムの停止等の「所定の処理」を行なう(S203)。異常を発見しない場合は、所定の処理を行なわず引き続きプログラムの実行を継続する。
以上の電子制御装置においては、搭載されている本件プログラムが、重要度に基づいてチェック対象となる制御フローを限定しているので、プログラム実行時の時間的、空間的オーバーヘッドを抑制することができる。
また、車載用電子制御装置において、車両を使用するユーザの安全性に応じて定められた重要度に基づいてチェック処理命令を挿入することにより、車両やユーザの安全性を損なわずに効率的にオーバーヘッドを抑制することができる。
(実施形態2)
実施形態1では、特定した関数を対象とする制御フローをチェックするチェック処理命令を挿入した。そして、チェック処理命令自体は必ずチェック処理を実行するものであった。これに対して、本実施形態は、チェック処理命令は必ずチェック処理命令を実行するものではなく、本件プログラムの実行時にチェック処理命令が実行されるかどうかが選択可能な構成を有するものである。
実施形態1では、特定した関数を対象とする制御フローをチェックするチェック処理命令を挿入した。そして、チェック処理命令自体は必ずチェック処理を実行するものであった。これに対して、本実施形態は、チェック処理命令は必ずチェック処理命令を実行するものではなく、本件プログラムの実行時にチェック処理命令が実行されるかどうかが選択可能な構成を有するものである。
1.プログラム生成方法および生成された本件プログラム
本実施形態のプログラム生成方法は、図2を用いて説明した実施形態1と基本的には同じである。ただし、本実施形態では、S104で特定される所定の重要度を、実施形態1よりも低く設定している。例えば、重要度が低以上の関数を特定し、重要度が低以上の関数が対象となる制御フローを特定する。そして、重要度が低以上の関数のコール/リターンが正しく実行されるかをチェックするチェック処理命令をプログラムコード内に挿入する(S105)。例えば、図4のリスクランクテーブルに基づき、重要度が低以上の関数を抽出し、関数B、関数C、関数Dを抽出する。
本実施形態のプログラム生成方法は、図2を用いて説明した実施形態1と基本的には同じである。ただし、本実施形態では、S104で特定される所定の重要度を、実施形態1よりも低く設定している。例えば、重要度が低以上の関数を特定し、重要度が低以上の関数が対象となる制御フローを特定する。そして、重要度が低以上の関数のコール/リターンが正しく実行されるかをチェックするチェック処理命令をプログラムコード内に挿入する(S105)。例えば、図4のリスクランクテーブルに基づき、重要度が低以上の関数を抽出し、関数B、関数C、関数Dを抽出する。
そして、図9に示す通り、関数B、関数C、関数Dがコール/リターン先となる制御フローに対し、チェック処理命令を挿入する。なお、図9において、白丸は挿入されたチェック処理命令である。ただし、実施形態1と異なり、挿入されるチェック処理命令は、重要度に応じて、チェック処理命令を実行するか否かが選択可能となっている。詳細は次項で説明する。
なお、本実施形態では、重要度低以上の関数の制御フローに対してチェック処理命令をプログラムコード内に挿入したが、全ての関数の制御フローを対象として挿入してもよい。
この場合を含む本件プログラムは、関数AないしD(本発明の「関数」に相当)、及び関数のコール/リターン関係である制御フロー(本発明の「制御フロー」に相当)をプログラムコード内に含むプログラムであり、制御フローが正しく実行されるかをチェックするチェック処理命令が挿入されており、チェック処理命令は、関数の重要度に基づいて実行するか否かが選択可能である、コンピュータにて実行可能なプログラムである。
この場合を含む本件プログラムは、関数AないしD(本発明の「関数」に相当)、及び関数のコール/リターン関係である制御フロー(本発明の「制御フロー」に相当)をプログラムコード内に含むプログラムであり、制御フローが正しく実行されるかをチェックするチェック処理命令が挿入されており、チェック処理命令は、関数の重要度に基づいて実行するか否かが選択可能である、コンピュータにて実行可能なプログラムである。
2.本件プログラムを搭載した電子制御装置
本実施形態の電子制御装置の構成を、図10を用いて説明する。本実施形態の電子制御装置は、図7で説明した実施形態1の構成に加え、チェック処理命令選択部201を有している。チェック処理命令選択部201は、外部から入力された情報を用いて重要度を決定する。外部から入力された情報として、ユーザ等から重要度自体が入力されることのほか、車両の動作状態、例えば車速やギア等に応じて重要度を決定することが挙げられる。動作状態の詳細は、実施形態3で説明する。
本実施形態の電子制御装置の構成を、図10を用いて説明する。本実施形態の電子制御装置は、図7で説明した実施形態1の構成に加え、チェック処理命令選択部201を有している。チェック処理命令選択部201は、外部から入力された情報を用いて重要度を決定する。外部から入力された情報として、ユーザ等から重要度自体が入力されることのほか、車両の動作状態、例えば車速やギア等に応じて重要度を決定することが挙げられる。動作状態の詳細は、実施形態3で説明する。
そして、チェック処理命令選択部201は、決定した重要度をふまえ、関数の「重要度」に「基づいて」、本件プログラムに挿入されたチェック処理命令のうちどのチェック処理命令を実行するかを選択する。例えば、図11(A)の通り、重要度高と決定した場合、関数Cのみが重要度高となっているので、関数Bから関数Cをコールする制御フロー、および関数Cが他の関数をコールする制御フローのみを対象とするチェック処理命令が選択される。また、図11(B)の通り、重要度中以上と決定した場合、関数Dが重要度中となっているので、図11(A)の場合に加えて、関数Bから関数Dをコールする制御フロー、および関数Dが他の関数をコールする制御フローを対象とするチェック処理命令が選択される。さらに、図11(C)の通り、重要度低以上と決定した場合、関数Bが重要度低となっているので、図11(B)の場合に加えて、関数Aから関数Bをコールする制御フローを対象とするチェック処理命令が選択される。なお、図11において、黒丸は実行対象として選択されたチェック処理命令、白丸は実行対象外として選択されなかったチェック処理命令である。
そして、演算部101は、選択されたチェック処理命令を含め、本件プログラムを実行する。例えば、チェック処理命令選択部201で決定した重要度が高であれば図11(A)、重要度が中であれば図11(B)、重要度が低であれば図11(C)で説明した通りのチェック処理命令を実行対象として実行する。
次に、電子制御装置20の動作を、図12を用いて説明する。
チェック処理命令選択部201は、外部から入力された情報を用いて重要度を決定するとともに、決定された重要度を踏まえ、関数の重要度に基づいてチェック対象命令を選択する(S301)。
チェック処理命令選択部201は、外部から入力された情報を用いて重要度を決定するとともに、決定された重要度を踏まえ、関数の重要度に基づいてチェック対象命令を選択する(S301)。
そして、その後決定された重要度の設定を変更する必要がある情報が外部から入力されているかどうかを確認し(S302)、入力されていればS301に戻り、チェック処理命令選択部201で新たに重要度を決定し、関数の重要度に基づいてチェック処理命令を新たに選択する。入力されていなければ、演算部101は、選択されたチェック処理命令を含めて本件プログラムを実行する(S303)。それ以降は、図8のS202,S203と同様である。
以上、本実施形態によれば、本件プログラムの実行時に、重要度に応じて実行させるチェック処理命令を変更することができ、プログラム実行時の時間的、空間的オーバーヘッドを抑制するとともに、状況に応じたプログラムのチェックを行うことができる。例えば、走行状態や走行場所によってチェック対象の制御フローを変更する例が考えられる。攻撃がユーザに及ぼす影響に鑑み、低速走行中(一般道路)では重要度高をチェック処理対象にするとともに、高速走行中(高速道路など)では重要度低以上をチェック処理対象にすることにより、特に速度域が高い状態での車両制御プログラムの実行の安全性を高めることが可能となる。
(実施形態3)
実施形態2では、プログラムコード内の関数自体の重要度は固定されており、外部から入力された情報を用いて重要度を決定し、関数の重要度に基づいて実行するチェック処理命令を選択した。これに対して、本実施形態では、プログラムコード内の関数自体の重要度を状況に応じて変化させるものである。
実施形態2では、プログラムコード内の関数自体の重要度は固定されており、外部から入力された情報を用いて重要度を決定し、関数の重要度に基づいて実行するチェック処理命令を選択した。これに対して、本実施形態では、プログラムコード内の関数自体の重要度を状況に応じて変化させるものである。
1.プログラム生成方法および生成された本件プログラム
本実施形態のプログラム生成方法は、図2を用いて説明した実施形態1、および実施形態2と基本的には同じである。ただし、S102で取得するリスクランクテーブル、およびS105のチェック処理命令を挿入する基準が異なる。
本実施形態のプログラム生成方法は、図2を用いて説明した実施形態1、および実施形態2と基本的には同じである。ただし、S102で取得するリスクランクテーブル、およびS105のチェック処理命令を挿入する基準が異なる。
図13は、本実施形態におけるリスクランクテーブルを示したものである。
本実施形態のリスクランクテーブルは、本件プログラムが実行される車両の「動作状態」に応じて、プログラムコード内の関数の重要度が変化することを示している。例えば、図13の場合、車両の駐車時、停止時、そして走行時に分けて重要度が規定されている。
ここで、本発明の「動作状態」とは、車速、ギア、ドアロック等、車両自体の状態を表す場合の他、ブレーキやハンドル、アクセル操作等、車両の操作状態、あるいは、走行する道路、天候、周辺車両の位置等、車両の周辺状況も含む。
本実施形態のリスクランクテーブルは、本件プログラムが実行される車両の「動作状態」に応じて、プログラムコード内の関数の重要度が変化することを示している。例えば、図13の場合、車両の駐車時、停止時、そして走行時に分けて重要度が規定されている。
ここで、本発明の「動作状態」とは、車速、ギア、ドアロック等、車両自体の状態を表す場合の他、ブレーキやハンドル、アクセル操作等、車両の操作状態、あるいは、走行する道路、天候、周辺車両の位置等、車両の周辺状況も含む。
そして、重要度に基づいてチェック処理命令をプログラムコード内に挿入する(S105)。ただし、本実施形態では動作状態に応じて重要度が異なるため、例えば、各関数につき所定の重要度以上が何れかの動作状態で有する関数を対象に、チェック処理命令を挿入する。一例として、重要度高が何れかの動作状態で付与されている関数を対象に、チェック処理命令を挿入する。例えば図13のリスクランクテーブルを用いる場合、関数C、関数Dは、重要度高が含まれている。そこで、図14のように、関数C、および関数Dを対象とする制御フローをチェックするチェック処理命令を挿入する。
なお、実施形態2と同様、本実施形態においても、全ての関数の制御フローを対象として挿入してもよい。その場合を含む本件プログラムは、0050段落に記載の通りである。
なお、実施形態2と同様、本実施形態においても、全ての関数の制御フローを対象として挿入してもよい。その場合を含む本件プログラムは、0050段落に記載の通りである。
2.本件プログラムを搭載した電子制御装置
本実施形態の電子制御装置の構成を、図15を用いて説明する。本実施形態の電子制御装置は、図10で説明した実施形態2の構成に加え、動作状態検出部301、および重要度変更部302を有している。なお、本実施形態の別の態様として、図7で説明した実施形態1の構成に加え、動作状態検出部301、および重要度変更部302を有するようにしてもよい。
本実施形態の電子制御装置の構成を、図15を用いて説明する。本実施形態の電子制御装置は、図10で説明した実施形態2の構成に加え、動作状態検出部301、および重要度変更部302を有している。なお、本実施形態の別の態様として、図7で説明した実施形態1の構成に加え、動作状態検出部301、および重要度変更部302を有するようにしてもよい。
動作状態検出部301は、車載ネットワーク10に接続された車両動作状況取得装置80で検出された車両の動作状態を受信し、重要度変更部302に対して出力する。
重要度変更部302は、リスクランクテーブルを参照し、車両の動作状態に応じた各関数の重要度を変更する。そして、チェック処理命令選択部201は、決定した重要度をふまえ、関数の重要度に基づいて、本件プログラムに挿入されたチェック処理命令のうちどのチェック処理命令を実行するかを選択する。本実施形態では、以下に述べる通り、重要度が高である関数を対象とする制御フローをチェックするチェック処理命令を選択しているが、実施形態2のように重要度を決定して実行するチェック処理命令を適宜選択するようにしてもよい。リスクランクテーブルは、メモリ110に保存しているが、車載ネットワーク10に接続された他の装置から読み出すようにしてもよい。
図16は、図13のリスクランクテーブルに基づいて実行される本件プログラムを模式的に示したものである。動作状態検出部301が、動作状態が駐車時であることを受信した場合、関数Cのみが重要度高となっている。そこで、チェック処理命令選択部201は、図16(A)の通り、関数Bから関数Cをコールする制御フロー、および関数Cが他の関数をコールする制御フローのみを対象とするチェック処理命令を選択する。動作状態検出部301が、動作状態が停止時であることを受信した場合、関数Cのみが重要度高となっている。そこで、チェック処理命令選択部201は、図16(B)の通り、数Bから関数Cをコールする制御フロー、および関数Cが他の関数をコールする制御フローのみを対象とするチェック処理命令を選択する。動作状態検出部301が、動作状態が走行時であることを受信した場合、関数C、関数Dが重要度高となっている。そこで、チェック処理命令選択部201は、図16(C)の通り、関数C、関数Dを対象とする制御フローを対象とするチェック処理命令を選択する。
次に、電子制御装置20の動作を、図17を用いて説明する。
動作状態検出部301は、車載ネットワーク10に接続された車両動作状況取得装置80で検出された車両の動作状態を受信し、重要度変更部302に対して出力する(S401)。
動作状態検出部301は、車載ネットワーク10に接続された車両動作状況取得装置80で検出された車両の動作状態を受信し、重要度変更部302に対して出力する(S401)。
重要度変更部302は、車両の動作状態に応じた各関数の重要度を変更する。そして、チェック処理命令選択部201は、決定した重要度をふまえ、関数の重要度に基づいてチェック処理命令を選択する(S402)。
そして、その後動作状態が変更されているかどうかを確認し(S403)、変更されていればS401に戻る。変更されていなければ、演算部101は、選択されたチェック処理命令を含めて本件プログラムを実行する(S404)。それ以降は、図8のS202,S203と同様である。
以上、本実施形態によれば、車両の動作状態に応じて実行するチェック処理命令を変更することができ、プログラム実行時の時間的、空間的オーバーヘッドを抑制するとともに、車両の動作状態に応じた最適なチェックを行うことができる。
(実施形態4)
実施形態1乃至3はいずれも、制御フローを正しく実行するための処理命令として、関数のコール/リターン時にコール/リターン先の関数のIDをチェックするチェック処理命令をプログラムコード内に挿入する構成を示した。これに対し、本実施形態4では、処理命令として、リターンアドレスをセキュア領域に格納するとともに、セキュア領域に格納されたリターンアドレスに基づいてリターン処理を実行するリターン処理命令をプログラムコード内に挿入する実施形態を、実施形態1乃至3との相違点を中心に説明する。
実施形態1乃至3はいずれも、制御フローを正しく実行するための処理命令として、関数のコール/リターン時にコール/リターン先の関数のIDをチェックするチェック処理命令をプログラムコード内に挿入する構成を示した。これに対し、本実施形態4では、処理命令として、リターンアドレスをセキュア領域に格納するとともに、セキュア領域に格納されたリターンアドレスに基づいてリターン処理を実行するリターン処理命令をプログラムコード内に挿入する実施形態を、実施形態1乃至3との相違点を中心に説明する。
1.プログラム生成方法および生成された本件プログラム
本実施形態のプログラム生成方法は、図2を用いて説明した実施形態1と基本的には同じである。ただし、本実施形態では、処理命令として、チェック処理命令に代わりリターン処理命令をプログラムコード内に挿入している。
本実施形態のプログラム生成方法は、図2を用いて説明した実施形態1と基本的には同じである。ただし、本実施形態では、処理命令として、チェック処理命令に代わりリターン処理命令をプログラムコード内に挿入している。
図18は、プログラムコードから抽出した関数及び制御フローを、制御フローグラフ(CFG)として示したものである。図18の例では、プログラムコードから、ハザードライト点灯制御に関する関数Aないし関数Cが抽出されるとともに、各関数のコール/リターン関係である制御フローが抽出されており、プログラムコードが関数のリターン関係を含むという点で、図3の制御フローとは異なっている。この例では、関数Aと関数C、関数Bと関数Cはそれぞれコール/リターン関係にあり、関数A又は関数B(本発明の「第1の関数」に相当)から関数C(本発明の「第2の関数」に相当)がコールされるとともに、関数Cからコール元である関数A又は関数Bにリターンする。
図19は、本実施形態のリスクランクテーブルの例である。図18で抽出した関数のうち、Aは緊急ブレーキ作動に関する関数、Bはハザードスイッチ状態の検出に関する関数、Cはハザードライトの点灯に関する関数である。外部からの攻撃等により正常フロー以外でコール又はリターンされることによるユーザの安全性に対する影響度という観点で各関数の重要度を評価すると以下のようになる。Aは、自車両が他車両などの障害物に急接近するなどの条件下で実行される関数であり、緊急ブレーキが作動しないと、自車両が障害物に衝突してユーザが危険にさらされる恐れがあるので、重要度は高と規定されている。Bは、ハザードスイッチ状態の検出が他の箇所でコールされたとしても、ユーザがハザードスイッチをオンにしなければ、内部で判定結果=False(trueではない)が返るだけでありユーザは気づかないので重要度は低と規定されている。Cは、ユーザがハザードライトを手動で点灯させていないにも関わらず、ハザードが点灯しているとユーザは違和感を覚えるので、重要度は中と規定されている。
図20は、本実施形態のCFGにおいて、所定の重要度以上の関数、および当該関数を対象とする制御フローを特定した状態を示している。図中、太線で囲まれた四角形が所定の重要度以上の関数であり、太線で示された矢印が所定の重要度以上の関数にリターンする制御フローである。本実施形態では重要度が高以上の関数、および重要度が高以上の関数にリターンする制御フローを特定している。つまり、重要度が高以上の関数は関数Aのみであるから、関数Cから関数Aにリターンする制御フローを特定している。
次いで、実施形態1と同様、重要度が所定以上であると特定した制御フローに対して、リターン処理命令をプログラムコード内に挿入する。図21は、リターン処理命令を挿入したプログラムを模式的にCFGとして示すものである。本実施形態では、重要度高である関数Aにリターンする制御フローを正しく実行するためのリターン処理命令がプログラムコード内に挿入されている。
そして、実施形態1と同様、リターン処理命令を挿入されたプログラムコードを有する本件プログラムが実装対象の電子制御装置20に書き込まれる。
そして、実施形態1と同様、リターン処理命令を挿入されたプログラムコードを有する本件プログラムが実装対象の電子制御装置20に書き込まれる。
リターン処理命令は、関数Aから関数Cをコールする際、関数Cから関数Aへのリターンアドレスを「セキュア領域」に格納する。そして、セキュア領域に格納されたリターンアドレスに「基づいて」、関数Cから関数Aへのリターン処理を実行する。具体的には、セキュア領域に格納されたリターンアドレスへとリターン処理を実行する。なお、本実施形態では、関数Aから関数Cをコールする時にリターンアドレスをセキュア領域に格納する例を説明している。
ここで、「セキュア領域」とは、格納されるデータに対するセキュリティが確保されるメモリ領域であればよく、狭義のセキュア領域、すなわち、格納されるファイルやデータに対して、その読み書きに関してアクセス制限が施されたメモリ領域はもちろん、後述のシャドウスタック領域も含む。また、「セキュア領域」は、ROM、RAMのいずれでもよい。「シャドウスタック領域」とは、通常のプログラム実行時にアクセスするメモリ領域から分離されたメモリ領域であればよく、例えば、明示的に指定してアクセスする拡張セグメントのデータ領域などを含む。また、「基づいて」とは、リターン処理を実行するリターンアドレスの決定において、セキュア領域に格納されたリターンアドレスを使用していれば足り、セキュア領域に格納されたリターンアドレスをリターン先として直接用いる場合の他、その他の要素を考慮する場合も含む。
ここで、「セキュア領域」とは、格納されるデータに対するセキュリティが確保されるメモリ領域であればよく、狭義のセキュア領域、すなわち、格納されるファイルやデータに対して、その読み書きに関してアクセス制限が施されたメモリ領域はもちろん、後述のシャドウスタック領域も含む。また、「セキュア領域」は、ROM、RAMのいずれでもよい。「シャドウスタック領域」とは、通常のプログラム実行時にアクセスするメモリ領域から分離されたメモリ領域であればよく、例えば、明示的に指定してアクセスする拡張セグメントのデータ領域などを含む。また、「基づいて」とは、リターン処理を実行するリターンアドレスの決定において、セキュア領域に格納されたリターンアドレスを使用していれば足り、セキュア領域に格納されたリターンアドレスをリターン先として直接用いる場合の他、その他の要素を考慮する場合も含む。
通常、関数Aから別の関数Cへとコールされる場合、関数Aにリターンするためのリターンアドレスはスタック領域に格納され、このスタック領域に格納されたリターンアドレスへとリターン処理が行われる。しかしながら、バッファオーバーフロー攻撃を受けた場合、スタック領域に書き込まれたリターンアドレスが悪意のあるコードを格納しているメモリアドレスに上書きされてしまう。特に、関数Cからのリターンアドレスが関数Bに上書きされても、チェック処理命令だけでは、そのリターン先が誤った制御フローに改ざんされたことを検知することができない。そこで、リターン処理命令が挿入された制御フローでは、外部から保護されたセキュア領域にリターンアドレスを格納することで、コール元のリターンアドレスへのリターンを可能とする。
セキュア領域に格納されるデータは、外部からのアクセスに対して高いセキュリティが確保されている。例えば、セキュア領域であるシャドウスタック領域にアクセスするためには、明示的にレジスタを指定する必要があり、シャドウスタック領域は通常のプログラム実行時に読み書きされることがなく、バッファオーバーフロー攻撃に対して有効に保護された領域であるといえる。つまり、セキュア領域に格納されたリターンアドレスは、確実に正しい値であると保証される。一方、リターンアドレスを格納するためにセキュア領域を使用すると、オーバーヘッドが増加してしまう。
しかしながら、以上のプログラム生成方法によれば、重要度に基づいて、セキュア領域へのリターンアドレスの格納とその取得の使用回数を限定するため、オーバーヘッドの増加を抑制しながら、リターン処理の安全性を高めることができる。
2.本件プログラムを搭載した電子制御装置
生成した本件プログラムは、実施形態1と同様、図7に示すような電子制御装置20に搭載される。しかしながら、後述するように、本件プログラムを搭載する電子制御装置20においては、検知部102及び処理部103は有さなくともよい。なお、セキュア領域及びスタック領域はメモリ110に設けられる。
生成した本件プログラムは、実施形態1と同様、図7に示すような電子制御装置20に搭載される。しかしながら、後述するように、本件プログラムを搭載する電子制御装置20においては、検知部102及び処理部103は有さなくともよい。なお、セキュア領域及びスタック領域はメモリ110に設けられる。
次に、電子制御装置20のプログラム実行時の動作を、図22を用いて説明する。
中央演算処理装置の演算部101は、メモリ110に保存した本件プログラムを読み出し、プログラムを開始する。
まず、プログラムコード内の関数(図21の関数A又は関数B)を実行し、次いで、別の関数(関数C)をコールする(S501)。ここで、リターン処理命令が挿入されている場合、リターンアドレスをセキュア領域に格納する(S502、S503)。一方、リターン処理命令が挿入されていない場合には、従来通り、リターンアドレスをスタック領域に格納する(S502、S504)。なお、本実施形態4の応用例として、リターン処理命令を実行しない場合には、S504の後に、図22の点線で示すようにチェック処理命令を実行してもよい。
中央演算処理装置の演算部101は、メモリ110に保存した本件プログラムを読み出し、プログラムを開始する。
まず、プログラムコード内の関数(図21の関数A又は関数B)を実行し、次いで、別の関数(関数C)をコールする(S501)。ここで、リターン処理命令が挿入されている場合、リターンアドレスをセキュア領域に格納する(S502、S503)。一方、リターン処理命令が挿入されていない場合には、従来通り、リターンアドレスをスタック領域に格納する(S502、S504)。なお、本実施形態4の応用例として、リターン処理命令を実行しない場合には、S504の後に、図22の点線で示すようにチェック処理命令を実行してもよい。
次に、コール先の関数(関数C)を実行し、コール元の関数(関数A又は関数C)にリターンする(S505)。ここで、リターン処理命令が挿入されている場合には、セキュア領域に格納されたリターンアドレスへとリターン処理を実行する(S506、S507)。一方、リターン処理命令が挿入されていない場合には、スタック領域に格納されたリターンアドレスへとリターン処理を実行する(S506、S508)。ここでも、本実施形態4の応用例として、リターン処理命令を実行しない場合には、S508の後に、図22の点線で示すようなチェック処理命令を実行してもよい。
なお、本実施形態4では、セキュア領域にリターンアドレスを格納しており、正しいリターンアドレスへとリターン処理を実行することができるため、実施形態1乃至3とは異なり、制御フローの異常を検知する検知部102、及び検知結果が異常を示した場合に所定の処理を行う処理部103を必要としない。
なお、上記実施形態によるリターン処理命令は、セキュア領域に格納されたリターンアドレスを読み出し、当該リターンアドレスへとリターン処理を実行するものである。しかしながら、リターン処理命令は、セキュア領域に格納されたリターンアドレスに「基づいて」リターン処理を実行すればよく、例えば、セキュア領域に格納されたリターンアドレスに対して更なるチェックを加えてもよい。
0076段落にて述べたとおり、通常、ある関数から別の関数へとコールされる場合、リターンアドレスはスタック領域に格納される。そこで、リターン処理命令は、関数からコール元の関数へとリターンする際に、セキュア領域に格納されたリターンアドレス(本発明の「第1のリターンアドレス」に相当)と、スタック領域に格納されたリターンアドレス(本発明の「第2のリターンアドレス」に相当)とを比較し、これらのリターンアドレスが一致した場合に、一致したアドレスへとリターン処理を実行してもよい。
このように、リターン処理命令が、セキュア領域に格納されたリターンアドレスと、スタック領域に格納されたリターンアドレスとを比較する構成の場合、正しいリターンアドレスへとリターン処理を実行すると同時に、第2のリターンアドレスが改ざんされたという異常を検知することが可能となる。
3.実施形態4の変形例
(変形例1)
上記実施形態によるリターン処理命令は、実施形態1に記載のチェック処理命令と同様、リターン処理命令が挿入されている場合には必ず、セキュア領域にリターンアドレスを格納するとともに、セキュア領域に格納されたリターンアドレスへとリターン処理を実行するものであった。
しかしながら、リターン処理命令は必ずリターン処理命令を実行するものではなくともよく、実施形態2に記載のチェック処理命令と同様、本件プログラムの実行時に、関数の重要度に基づいてリターン処理命令が実行されるかどうかを選択可能な構成としてもよい。この場合、本件プログラムを生成する際は、重要度が低以上の関数を特定し、重要度が低以上の関数が対象となる制御フローを特定するとともに、重要度が低以上の関数のリターンを正しく実行させるためにリターン処理命令をプログラムコード内に挿入する。また、本変形例1の電子制御装置の構成は、図10と基本的に同じであるが、チェック処理命令選択部201に代えて、リターン処理命令選択部を有する。
(変形例1)
上記実施形態によるリターン処理命令は、実施形態1に記載のチェック処理命令と同様、リターン処理命令が挿入されている場合には必ず、セキュア領域にリターンアドレスを格納するとともに、セキュア領域に格納されたリターンアドレスへとリターン処理を実行するものであった。
しかしながら、リターン処理命令は必ずリターン処理命令を実行するものではなくともよく、実施形態2に記載のチェック処理命令と同様、本件プログラムの実行時に、関数の重要度に基づいてリターン処理命令が実行されるかどうかを選択可能な構成としてもよい。この場合、本件プログラムを生成する際は、重要度が低以上の関数を特定し、重要度が低以上の関数が対象となる制御フローを特定するとともに、重要度が低以上の関数のリターンを正しく実行させるためにリターン処理命令をプログラムコード内に挿入する。また、本変形例1の電子制御装置の構成は、図10と基本的に同じであるが、チェック処理命令選択部201に代えて、リターン処理命令選択部を有する。
例えば、通常走行中では、リターン処理命令選択部は、図23(A)の通り、重要度高以上の関数Aのリターンアドレスをセキュア領域に格納するリターン処理命令、及びセキュア領域に格納されたリターンアドレスに基づいてリターンを実行するリターン処理命令を選択する。一方、高速走行中では、図23(B)の通り、リターン処理命令選択部は、重要度低以上の関数に関するリターン処理命令を実行対象とする。
本変形例1では、重要度に応じて実行させるリターン処理命令を変更することができ、関数のリターンの安全性を状況に応じて高めることができるとともに、セキュア領域を使用することによって生じるオーバーヘッドの増加を抑制することができる。
さらに、リターン処理命令を実行しない場合はリターンアドレスを格納するセキュア領域を無効化することにより、さらに、オーバーヘッドの増加を効率的に抑制してもよい。
さらに、リターン処理命令を実行しない場合はリターンアドレスを格納するセキュア領域を無効化することにより、さらに、オーバーヘッドの増加を効率的に抑制してもよい。
(変形例2)
実施形態4のリターン処理命令について、実施形態3に記載のチェック処理命令と同様、プログラムコード内の関数自体の重要度を状況に応じて変化させることにより、処理命令の実行対象を動的に変化させてもよい。この場合の電子制御装置の構成は、図15と基本的に同じであるが、チェック処理命令選択部201に代えて、リターン処理命令選択部を有する。
実施形態4のリターン処理命令について、実施形態3に記載のチェック処理命令と同様、プログラムコード内の関数自体の重要度を状況に応じて変化させることにより、処理命令の実行対象を動的に変化させてもよい。この場合の電子制御装置の構成は、図15と基本的に同じであるが、チェック処理命令選択部201に代えて、リターン処理命令選択部を有する。
図24は、状況に応じて重要度が変化する場合の本実施形態におけるリスクランクテーブルの例を示したものである。例えば、動作状態検出部301が、車両の動作状態が高速走行中であることを受信した場合、重要度変更部302は、関数A及び関数Cを重要度高に、関数Bを重要度中にそれぞれ変更する。そして、リターン処理命令選択部は、重要度が高以上である関数Aのリターンアドレスをセキュア領域に格納するリターン処理命令、及びセキュア領域に格納されたリターンアドレスに基づいてリターンを実行するリターン処理命令を実行対象として選択する。一方、動作状態検出部301が、車両の動作状態が低速走行中であることを受信した場合、重要度変更部302は、関数A及び関数Cを重要度中に、関数Bを重要度低にそれぞれ変更する。そこで、リターン処理命令選択部は、関数A乃至Cのいずれについても、リターン処理命令を実行対象として選択しない。
変形例2では、重要度を状況に応じて変化させることにより、車両の動作状態に応じて最適にリターン処理の安全性を高めることができるとともに、セキュア領域を使用することによって生じるオーバーヘッドの増加を効率的に抑制することができる。
また、変形例1と同様、リターン処理命令を実行しない場合はリターンアドレスを格納するセキュア領域を無効化して、オーバーヘッドの増加を抑制してもよい。
また、変形例1と同様、リターン処理命令を実行しない場合はリターンアドレスを格納するセキュア領域を無効化して、オーバーヘッドの増加を抑制してもよい。
(その他の実施形態)
実施形態1から4では、電子制御装置20に書き込まれた本件プログラム自体は変更されないが、プログラム自体を書き換えるようにしてもよい。例えば、処理命令の挿入位置を、使用状況や車両の動作状態に応じて変更するようにしてもよい。あるいは、実行される関数の使用頻度に応じて、処理命令の挿入位置を変更するようにしてもよい。
実施形態1から4では、電子制御装置20に書き込まれた本件プログラム自体は変更されないが、プログラム自体を書き換えるようにしてもよい。例えば、処理命令の挿入位置を、使用状況や車両の動作状態に応じて変更するようにしてもよい。あるいは、実行される関数の使用頻度に応じて、処理命令の挿入位置を変更するようにしてもよい。
(総括)
以上、本発明の各実施形態におけるプログラム生成方法、電子制御装置、およびプログラム生成方法で生成した本件プログラムの特徴について説明した。
以上、本発明の各実施形態におけるプログラム生成方法、電子制御装置、およびプログラム生成方法で生成した本件プログラムの特徴について説明した。
なお、各実施形態の特徴を2以上含むようにしてもよい。つまり、各実施形態は、実施形態同士組み合わせることが可能である。例えば、実施形態2と実施形態3とを組み合わせ、実行するチェック処理命令を選択できるようにするとともに、関数自体の重要度を変化させてもよい。
また、実施形態1から3では、処理命令としてチェック処理命令をプログラムコード内に挿入する場合を、実施形態4では、処理命令としてリターン処理命令をプログラムコード内に挿入する場合を説明した。しかしながら、処理命令はチェック処理命令とリターン処理命令の少なくとも一方を含むものであればよく、チェック処理命令とリターン処理命令の双方を含むものであってもよい。例えば、重要度高の関数については、チェック処理命令とリターン処理命令の両方を実行してもよい。あるいは、チェック処理命令とリターン処理命令の双方が挿入されている場合には、リターン処理命令を優先的に実行し、リターン処理命令が挿入されていない関数に対してのみチェック処理命令を実行してもよい。
また、各実施形態に開示の構成、方法は、その要素を本発明に適宜組み合わせることができる。つまり、各実施形態に開示の要素同士が必須の組み合わせという訳ではなく、各要素を適宜発明として組み込むことが可能である。
本発明は、主として自動車の電子制御装置に用いられるものであるが、自動車以外の車両、例えば、二輪車、電動アシスト自転車の他、船舶、航空機などにも用いることができる。さらに、本発明はこれらの車載用途に限られるものではない。
20 電子制御装置(ECU)、100 中央演算処理装置(CPU)、101 演算部、102 検知部、103 処理部、110 メモリ
Claims (12)
- プログラムコード内の関数のコール/リターン関係である制御フローを正しく実行するための処理命令であり、かつ前記関数の重要度に基づいて実行するか否かが選択可能な前記処理命令が前記プログラムコード内に挿入されているプログラムを実行する演算部(101)と、
前記関数の重要度に基づいて、前記プログラムコード内に挿入された前記処理命令のうち実行する処理命令を選択する処理命令選択部(201)と、
を有する、
電子制御装置(20)。 - 前記処理命令は、前記制御フローが正しく実行されるかをチェックするとともに、前記関数の重要度に基づいて実行可能か否かが選択可能なチェック処理命令を含み、
当該電子制御装置はさらに、
前記チェック処理命令の出力を監視し、前記制御フローの異常を検知する検知部(102)と、
前記検知部の検知結果に基づき、所定の処理を行なう処理部(103)と、
を有する、請求項1記載の電子制御装置。 - 前記プログラムコードは、第1の関数と、前記第1の関数からコールされるとともに、前記第1の関数にリターンする第2の関数とを含み、
前記処理命令は、前記第2の関数から前記第1の関数へのリターンアドレスをセキュア領域に格納するとともに、前記リターンアドレスに基づいて前記第2の関数から前記第1の関数へのリターン処理を実行するリターン処理命令を含む、
請求項1記載の電子制御装置。 - 前記リターン処理命令は、前記セキュア領域に格納された前記リターンアドレスへとリターン処理を実行する、
請求項3記載の電子制御装置。 - 前記リターン処理命令は、前記セキュア領域に格納されるリターンアドレスである第1のリターンアドレスと、前記第1の関数から前記第2の関数をコールする際にスタック領域に格納される前記第1の関数へのリターンアドレスである第2のリターンアドレスとを比較するとともに、前記第1及び第2のリターンアドレスが一致した場合には一致した前記第1及び第2のリターンアドレスへとリターン処理を実行する、
請求項3記載の電子制御装置。 - 前記プログラムコードは、車両に搭載される電子制御装置に書き込まれたものであり、
当該電子制御装置は、さらに
前記車両の動作状態を受信する動作状態検出部(301)と、
検出した前記動作状態に応じて前記関数の前記重要度を変更する重要度変更部(302)と、を有する
請求項1記載の電子制御装置。 - 前記プログラムコードは、車両に搭載される電子制御装置に書き込まれたものであり、
前記処理命令選択部は、前記車両を使用するユーザの安全性に応じて定められる前記重要度に基づいて、実行する前記処理命令を選択する、
請求項1記載の電子制御装置。 - 関数及び前記関数のコール/リターン関係である制御フローをプログラムコード内に含むプログラムであり、
前記制御フローを正しく実行するための処理命令が前記プログラムコード内に挿入されており、
前記関数の重要度に基づいて、前記プログラムコード内に挿入された前記処理命令のうち実行される処理命令が選択される、
コンピュータにて実行可能なプログラム。 - 前記処理命令は、前記制御フローが正しく実行されるかをチェックするチェック処理命令を含む、
請求項8記載のプログラム。 - 前記プログラムコードは、第1の関数と、前記第1の関数からコールされるとともに、前記第1の関数にリターンする第2の関数とを含み、
前記処理命令は、前記第2の関数から前記第1の関数へのリターンアドレスをセキュア領域に格納するとともに、前記リターンアドレスに基づいて前記第2の関数から前記第1の関数へのリターン処理を実行するリターン処理命令を含む、
請求項8記載のプログラム。 - 前記リターン処理命令は、前記セキュア領域に格納された前記リターンアドレスへとリターン処理を実行する、
請求項10記載のプログラム。 - 前記リターン処理命令は、前記セキュア領域に格納されるリターンアドレスである第1のリターンアドレスと、前記第1の関数から前記第2の関数をコールする際にスタック領域に格納される前記第1の関数へのリターンアドレスである第2のリターンアドレスとを比較するとともに、前記第1及び第2のリターンアドレスが一致した場合には一致した前記第1及び第2のリターンアドレスへとリターン処理を実行する、
請求項10記載のプログラム。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017130197 | 2017-07-03 | ||
JP2017130197 | 2017-07-03 | ||
JP2017199805A JP6996215B2 (ja) | 2017-07-03 | 2017-10-13 | プログラム生成方法および電子制御装置 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017199805A Division JP6996215B2 (ja) | 2017-07-03 | 2017-10-13 | プログラム生成方法および電子制御装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2022003582A JP2022003582A (ja) | 2022-01-11 |
JP7147947B2 true JP7147947B2 (ja) | 2022-10-05 |
Family
ID=64739114
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2021165793A Active JP7147947B2 (ja) | 2017-07-03 | 2021-10-07 | 電子制御装置及びプログラム |
Country Status (2)
Country | Link |
---|---|
US (1) | US11496506B2 (ja) |
JP (1) | JP7147947B2 (ja) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3908947A1 (en) * | 2019-03-25 | 2021-11-17 | Aurora Labs Ltd | Generating and signing a line-of-code behavior and relation model |
US11868467B2 (en) * | 2019-06-25 | 2024-01-09 | Nec Corporation | Semiconductor device, control flow inspection method, non-transitory computer readable medium, and electronic device |
US11204746B2 (en) * | 2020-01-28 | 2021-12-21 | Oracle International Corporation | Encoding dependencies in call graphs |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001216161A (ja) | 2000-02-04 | 2001-08-10 | Internatl Business Mach Corp <Ibm> | メモリ装置、スタック保護システム、コンピュータシステム、コンパイラ、スタック保護方法、記憶媒体及びプログラム伝送装置 |
JP2011008778A (ja) | 2009-05-27 | 2011-01-13 | Ntt Docomo Inc | プログラム実行フローの修正を防止する方法及び装置 |
Family Cites Families (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2000020291A (ja) * | 1998-07-06 | 2000-01-21 | Toyota Motor Corp | 車両用プログラム開発支援方法および装置 |
US6871341B1 (en) * | 2000-03-24 | 2005-03-22 | Intel Corporation | Adaptive scheduling of function cells in dynamic reconfigurable logic |
JP2006106939A (ja) | 2004-10-01 | 2006-04-20 | Hitachi Ltd | 侵入検知方法及び侵入検知装置並びにプログラム |
US7577992B2 (en) | 2005-01-14 | 2009-08-18 | Microsoft Corporation | Software security based on control flow integrity |
JP4849606B2 (ja) | 2006-04-28 | 2012-01-11 | 株式会社日立製作所 | 制御フロー誤り検出方法、データ処理装置、及びコンパイラ |
US9058483B2 (en) * | 2008-05-08 | 2015-06-16 | Google Inc. | Method for validating an untrusted native code module |
US8347272B2 (en) * | 2008-07-23 | 2013-01-01 | International Business Machines Corporation | Call graph dependency extraction by static source code analysis |
JP2011081501A (ja) | 2009-10-05 | 2011-04-21 | Hitachi Ltd | オペレーティングシステムプログラム、及びこれが搭載されているコンピュータ |
US8482431B2 (en) * | 2009-10-23 | 2013-07-09 | Fuji Jukogyo Kabushiki Kaisha | Driving support apparatus |
JP5374348B2 (ja) | 2009-12-10 | 2013-12-25 | 株式会社豊田中央研究所 | ソフトウェア検査装置及びプログラム |
WO2011072970A1 (en) * | 2009-12-18 | 2011-06-23 | Syddansk Universitet | Method, computer program product, and system for non-blocking dynamic update of statically typed class-based object-oriented software |
US8418160B2 (en) * | 2010-10-13 | 2013-04-09 | International Business Machines Corporation | Apparatus and method to selectively remove memoizing functions from program code |
US11003464B2 (en) * | 2012-04-19 | 2021-05-11 | Microsoft Technology Licensing, Llc | Control flow integrity enforcement at scale |
US8959495B2 (en) * | 2012-09-14 | 2015-02-17 | Oracle International Corporation | Unifying static and dynamic compiler optimizations in source-code bases |
US8935679B2 (en) * | 2012-10-10 | 2015-01-13 | Freescale Semiconductor, Inc. | Compiler optimized safety mechanism |
US9223979B2 (en) * | 2012-10-31 | 2015-12-29 | Intel Corporation | Detection of return oriented programming attacks |
JP6018022B2 (ja) * | 2013-06-14 | 2016-11-02 | 株式会社デンソー | 並列化コンパイル方法、並列化コンパイラ、並列化コンパイル装置、及び、車載装置 |
KR101600460B1 (ko) * | 2013-06-17 | 2016-03-08 | 한국산업기술대학교산학협력단 | 보안기능을 갖는 ecu 업그레이드시스템 및 그 방법 |
US9529584B2 (en) * | 2013-11-06 | 2016-12-27 | General Motors Llc | System and method for preparing vehicle for remote reflash event |
US9361102B2 (en) | 2014-06-09 | 2016-06-07 | Lehigh University | Methods for enforcing control flow of a computer program |
US20170249460A1 (en) * | 2014-09-23 | 2017-08-31 | The Regents Of The University Of California | Provably secure virus detection |
US9753731B1 (en) * | 2015-01-16 | 2017-09-05 | The Mathworks, Inc. | Methods and systems for analyzing and improving performance of computer codes |
US11354128B2 (en) * | 2015-03-04 | 2022-06-07 | Intel Corporation | Optimized mode transitions through predicting target state |
WO2017042702A1 (en) * | 2015-09-07 | 2017-03-16 | Karamba Security | Context-based secure controller operation and malware prevention |
US10114634B2 (en) * | 2016-01-22 | 2018-10-30 | 2236008 Ontario Inc. | Updating a controller unit in a vehicle |
JP6477551B2 (ja) * | 2016-03-11 | 2019-03-06 | トヨタ自動車株式会社 | 情報提供装置及び情報提供プログラム |
US9870665B2 (en) * | 2016-06-03 | 2018-01-16 | Volkswagen Aktiengesellschaft | Apparatus, system and method for vehicle access and function control utilizing a portable device |
JP6773477B2 (ja) * | 2016-08-02 | 2020-10-21 | トヨタ自動車株式会社 | 駐車支援装置 |
JP6270965B1 (ja) * | 2016-11-16 | 2018-01-31 | 三菱電機株式会社 | プログラムの更新制御システムおよびプログラムの更新制御方法 |
US20200151972A1 (en) * | 2017-05-09 | 2020-05-14 | Mitsubishi Electric Corporation | In-vehicle authentication system, vehicle communication apparatus, authentication management apparatus, in-vehicle authentication method, and computer readable medium |
US10360374B2 (en) * | 2017-05-25 | 2019-07-23 | Intel Corporation | Techniques for control flow protection |
-
2018
- 2018-06-25 US US16/016,736 patent/US11496506B2/en active Active
-
2021
- 2021-10-07 JP JP2021165793A patent/JP7147947B2/ja active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001216161A (ja) | 2000-02-04 | 2001-08-10 | Internatl Business Mach Corp <Ibm> | メモリ装置、スタック保護システム、コンピュータシステム、コンパイラ、スタック保護方法、記憶媒体及びプログラム伝送装置 |
JP2011008778A (ja) | 2009-05-27 | 2011-01-13 | Ntt Docomo Inc | プログラム実行フローの修正を防止する方法及び装置 |
Non-Patent Citations (2)
Title |
---|
冨永 悠生 et. al.,コールスタックの制御データ検査によるスタック偽装攻撃検知,情報処理学会論文誌 Vol.53 No.9 [CD-ROM],日本,一般社団法人情報処理学会,2012年09月15日,P.2075~P.2085 |
柴田 有 et. al.,難読化コンパイラのユーザによる保護強度調整機構,電子情報通信学会技術研究報告 Vol.109 No.168,日本,社団法人電子情報通信学会,2009年07月28日,P.43~P.48 |
Also Published As
Publication number | Publication date |
---|---|
JP2022003582A (ja) | 2022-01-11 |
US20190007446A1 (en) | 2019-01-03 |
US11496506B2 (en) | 2022-11-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7147947B2 (ja) | 電子制御装置及びプログラム | |
JP6898420B2 (ja) | セキュアロックダウンを実装するように構成された関連装置を有する特別にプログラムされたコンピューティングシステムおよびその使用方法 | |
CN104866762B (zh) | 安全管理程序功能 | |
JP2014519120A (ja) | サンドボックスにリファレンスを保存するシステム及び方法 | |
US9710290B2 (en) | Device for the reliable integration of a software component into a motor vehicle | |
CN107949847B (zh) | 车辆的电子控制单元 | |
CN109344609B (zh) | 一种tcu模块、tcu系统及保护方法 | |
US8839237B2 (en) | Method and apparatus for tamper resistant communication in a virtualization enabled platform | |
TWI678615B (zh) | 在資料處理裝置中進行除錯 | |
CN113868636A (zh) | 内核和任务隔离的方法和装置 | |
KR101089157B1 (ko) | 클라이언트 가상화를 이용한 서버의 논리적 망분리 시스템 및 방법 | |
Iqbal et al. | Towards a security architecture for protecting connected vehicles from malware | |
JP6885226B2 (ja) | 電子制御装置 | |
JP2015531521A (ja) | リンクされた複数のプログラムブロックの別々の実行を制御するための方法および制御装置 | |
JP2015067107A (ja) | 車両用制御装置 | |
CN108090376B (zh) | 基于TrustZone的CAN总线数据防护方法及系统 | |
CN111213144B (zh) | 单芯片系统,用于运行单芯片系统的方法及机动车 | |
JP6996215B2 (ja) | プログラム生成方法および電子制御装置 | |
Jia et al. | Towards secure and safe appified automated vehicles | |
JP2019049928A (ja) | 電子制御装置及び電子制御装置の制御方法 | |
US10503666B2 (en) | Method for operating a microcontroller | |
CN103886251B (zh) | 系统加固的方法及装置 | |
US10019576B1 (en) | Security control system for protection of multi-core processors | |
US20220080989A1 (en) | Information processing apparatus, information processing method, and recording medium | |
WO2023020069A1 (zh) | 虚拟机管理方法及相关系统、存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20211013 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20220823 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20220905 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 7147947 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |