従来、自動車のセキュリティといえば、自動車の盗難などの物理的なセキュリティを指すことが一般的でした。しかし、昨今、自動車の電子制御化が進み、安全運転支援機能などで見られるように、アクセル、ブレーキなどの速度制御、ハンドルの舵角制御など、「走る、曲がる、止まる」の車両制御までが車載コンピュータによる電子制御になってきています。自動車の電子制御化は、利便性、快適性、安全性の向上を享受する半面、車載コンピュータへのサイバー攻撃が搭乗者の命に関わる可能性もあるため、自動車制御を守るサイバーセキュリティ対策は喫緊の課題となっています。
本ページでは、自動車のサイバーセキュリティの脅威やそれに対する国際的な取り組み紹介などをまとめた後、車載ECU開発にあたっての開発プロセスにおけるセキュリティ観点や導入されようとしている車載セキュリティ技術を紹介します。
車載セキュリティ概要
自動車のサイバーセキュリティリスク
2015年に公開されたアメリカのセキュリティ専門家による自動車制御ハッキングの実証実験は世界中に大きな衝撃を与えました。自動車に搭載されたインフォテイメントシステムにつながる無線WiFi回線の脆弱性を利用して車内ネットワークに侵入できることを公表し、結果的に自動車メーカはリコール対応に追い込まれました。
この中では以下のセキュリティ脅威が実証されています。
- WiFiを侵入路としたパスワードのブルーフォースアタック(総当たり攻撃)によるインフォテイメントシステムへの侵入
- インフォテイメントシステムと接続されたマイコンのプログラム書き換え(CANデータ送信を可能に改変)
- 車内ネットワークへの不正制御データの送信(自動車制御の乗っ取り)
自動車の電子制御を担う車内ネットワーク通信には、主にCAN通信やLIN通信が使われていますが、そのデータは平文(暗号化されていないデータ)で送受信されています。そのため、通信データを解析することにより、データの成りすましが行えたり、不正データを送信することで自動車制御に影響を与える危険性があります。
また、ECUソフトウェアのリプログラミング機能では、書き損じ判定や書き換え許可判定は実装されていますが、書き換えデータが不正なものでないかを照合する仕組みがありません。そのため、自動車の電子制御を守るための取り組みが各国で検討されています。
国際的な自動車サイバーセキュリティ標準化の取り組み
◆欧州の取り組み
自動車セキュリティの標準化活動は欧州が先行して取り組みを始めました。代表的なものとして、HIS(Hersteller Initiative Software)やEVITA(E-safety Vehicle Intrusion Protected Applications)プロジェクトで、ECUに必要となるセキュリティ機能をハードウェア規格としてSHE(Secure Hardware Extension)やHSM(Hardware Security Module)で策定しています。これは、ECU内のマイコンの制御CPUとは別にセキュアゾーンを設け、セキュリティ機能に使うAES暗号化処理、乱数生成、鍵管理、セキュアブート機能などのセキュリティ処理を制御CPUから独立することで、外部アタックから守る仕組みです。
車載ソフトウェア標準化団体のAUTOSARでは、車載通信のセキュリティ仕様として、外部からの通信データ改ざんや成りすましを検知・防止するメッセージ認証機能をAUTOSAR R4.2.1仕様から規定しています。
◆北米の取り組み
北米での自動車セキュリティ標準化活動は、SAE(Society of Automotive Engineers)が、J3061(Cybersecurity Guidebook for Cyber-Physical Vehicle Systems)により、自動車のサイバー攻撃に対するガイドラインやセキュリティ機能開発プロセスを規定しています。また、北米では自動車メーカが提供した実車両をハッキングするチャレンジコンテストが開催されており、SAEが主催者に加わるなど活発な活動をされています。ハッキングコンテストによってホワイトハッカーが露呈した侵入経路やハッキング技術を自動車メーカが取り込むことで実践的なセキュリティ対策が進んでいます。
◆日本の取り組み
日本では、自動車技術会から「JASO TP-15002:自動車の情報セキュリティ分析ガイド」が発行されており、自動車システムの脅威分析、リスクアセスメントなどセキュリティ分析の手法を定義されています。また、自動車メーカ、サプライヤ等が加盟する標準化団体のJASPAR(Japan Automotive SoftwarePlatform and Architecture)では、メッセージ認証要求仕様を策定するなど自動車セキュリティの議論が行われています。その他、経済産業省が各団体と自動車のサイバーセキュリティに関する検討を行うなど、国をあげて対策の検討を行っています。
自動車サイバーセキュリティレイヤー
自動車のサイバーセキュリティは各分野で議論されています。全体像を把握するためには、開発ECUに対してレイヤー構造で捉えると整理しやすいでしょう。
- アプリケーションレイヤー層
車車間通信、V2X通信におけるセキュアな認証のためのデジタル署名技術や規定 - ミドルウェア、ドライバ層
車内ネットワークの制御通信を守るメッセージ認証や、セキュアブート、セキュアなリプログラミング技術や規定 - ハードウェア層
認証用の鍵を守る技術やソフトウェアで実施するには負荷の高い暗号化処理や認証処理をハードウェア化することで、ソフトウェア負荷を抑えながらも外部から隠蔽化する技術や規定
セキュリティ対策は技術を導入するだけでは足りず、開発プロセスからもサイバーセキュリティへの対策が必要との議論が進んでいます。更には、自動車サイバーセキュリティの包括的な国際基準作りが始まっています。
自動車のライフサイクルにおけるサイバーセキュリティ
◆WP.29
2018年11月、国連の下部組織である自動車基準調和世界フォーラム(WP.29)から2つのサイバーセキュリティ関連ガイドラインが示されました。
- Proposal for a Recommendation on Cyber Security
- Draft Recommendation on Software Updates of the Task Force on Cyber Security and Over-the-air issues
自動車のサイバーセキュリティは自動車メーカだけが対応すれば良いものではありません。
Proposal for a Recommendation on Cyber Security(以下、PRCS)では、車両のライフサイクル全体にわたるサイバーセキュリティ対策を原則としており、車両メーカだけでなく、下請け業者、サプライヤー、潜在的な第三者を含むすべての組織でシステムのセキュリティを強化するために協力する必要があるとしています。
また、PRCSでは、サイバーセキュリティの原則を10項目あげています。ECU開発に関わるものを抜粋すると以下の通りです。
- ソフトウエアのセキュリティは、その存続期間を通じて管理する必要がある
- データの保存と送信は安全かつ管理できる必要がある
- 自動車メーカは、テスト手順でセキュリティ機能を評価する必要がある
- 車両はサイバー攻撃に対して回復力があるように設計する必要がある
- 車両はサイバー攻撃を検出し、適切に対応する機能を備えて設計する必要がある
PRCSでは、自動車のサイバーセキュリティの原則、脅威、緩和策などの指針や観点を示すのみで、具体的な手法や具体策は明示されていません。但し、これらのサイバーセキュリティの原則からは、今後の車載セキュリティではECUや車内ネットワーク通信を守るため、メッセージ認証のような通信セキュリティ技術や、ECUソフトウェアをアップデートするためのリプログラミング機能などが必須になっていくものと思われます。
WP.29では、サイバーセキュリティに関するタスクフォースを組織し、2020年6月24日に、自動車のサイバーセキュリティとソフトウェアアップデートに関する国際基準(UN規則)を採択しました。車両の型式認可を受ける際に、国際基準を満たす体制であることを示す必要であったり、サプライチェーンや製造後の自動車の使用期間の全体像を見た対応が求められており、自動車メーカーだけでなく、サプライヤーの対応も必要になってきています。
◆ISO/SAE 21434
ISO/SAEでは、自動車サイバーセキュリティに関する規格 ISO/SAE 21434として2021年8月にIS版が公開されました。
本規格では、リスク管理手法、開発プロセス、生産・運用・廃棄、サイバーセキュリティ管理などの車両開発から廃止までのライフサイクル全般にわたるサイバーセキュリティ要件を定めたものとなります。そのため対象は、自動車のシステム、コンポーネント、ソフトウェア、外部デバイスやネットワークとの通信を含めた包括的な内容になっています。
ISO/SAE 21434は、今後の自動車サイバーセキュリティの中心的な規格になります。
◆ISO 26262
機能安全規格のISO 26262は、第2版(2nd edition)が2018年に発行されました。ISO 26262 2nd editionでは車載セキュリティについても議論されており、安全分析にセキュリティを組込むために、機能安全担当組織、サイバーセキュリティ担当組織の間で「有効なコミュニケーションチャネル」を構築することを求めています。ただし、具体的なことは明示されていません。
車載開発のセキュリティ要素
車載開発におけるセキュリティは大きく分けて4つに分類することができます。セキュリティの管理体制、開発プロセス、組込み技術、インシデント対応は全て組織として対応する必要があります。セキュリティの開発プロセスでは、まず「何を守るのか?」を決めてから、脅威とリスク評価を実施し、セキュリティアーキテクチャのデザインを実施します。
一般的に情報セキュリティでは、以下の3点に対して均等に対策をすることでセキュアな情報システムが構築できると考えられています。
1.Cofidentiality(機密性)
情報を読むことを定められたポリシー通りに制御すること
→ 情報が漏れないこと
2.Integrity(完全性)
情報や機能を設定する、あるいは消去することを定められたポリシー通りに制御すること
→ 情報が保存した時点のまま維持されること
3.Availability(可用性)
システムやサービスの利用が定められたポリシー通りにできるように制御すること
→ 情報が利用したい時に利用できること
上記の要求に対して、自動車では将来に渡る稼働期間が長く、開発期間の中でセキュリティ対策を全て予測することは困難です。そのため、以下の車載セキュリティの取り組みが始められています。
■Integrity(完全性):設計者の意図した制御プログラムが維持されること
→ セキュアブート(確かなプログラムが起動すること)
→ メッセージ認証(確かな通信データを受信すること)
車載ECUのセキュリティ開発プロセス
車載ECUの開発プロセスにおいて、セキュリティ対策は開発プロセス全般で実施する必要があります。脆弱性の発見は遅れるほど、対策が難しくなってきます。そのため、システム要求分析や設計の段階で、いかに脆弱性を排除するかが重要になり、システムとしてのセキュリティ資産の定義や脅威分析、リスク評価が重要になってきます。
セキュリティ資産の定義は、「何を守るか」の観点で定義付けします。セキュリティ資産は、鍵であったり、意図したプログラムを保持する(改ざんされない)ことなどを対象とします。それに対して脅威は、鍵が盗まれる、ソフトが改ざんされるなどを定義し、開発対象製品の分析が必要になります。
HSM機能検証と設計では、鍵管理やソフト改ざん対策のため、HSMを用いる事で何が出来て、何が守れるのかをきちんと把握しておく必要があります。HSMの処理速度と現在システムとの整合・検証をしておくことで、最適なアーキテクチャ設計が出来ます。
また、ソフトウェアコーディングにおける意図しないコーディングミスが脆弱性の混入要因ともなります。実装における欠陥はセキュリティ問題の原因の50%にも達するとも言われています。欠陥の例としては、バッファオーバーフロー、インデックス/整数オーバーフロー、不適切なエラー処理などが挙げられます。そのためセキュアコーディングは非常に重要です。
車載組込みソフトウェア開発ではC言語が主流ですが、C言語を使ってセキュアコーディングを行うためのルールとしてCERT-Cコーディングルールが使われるようになってきました。CERT-Cコーディングルールでは、脆弱性につながる恐れのある危険なコーディングや未定義の動作を削減することで、品質が高く保守性の良いシステム開発を目的としています。
評価工程においては、脆弱性評価のためのファジングテストやぺネストレーションテストなどを実施することが検討されています。但し、開発ECUに対してどのような評価をどこまで実施すればよいか、まだノウハウが確立されていないのが実態です。セキュリティ評価の網羅性を決めることは難しく、過去事例などでのノウハウが重要になってきます。
車載ECUへ導入されるセキュリティ機能
自動車制御を守るセキュリティ
冒頭で紹介した自動車制御のハッキング実証検証では、外部からインフォテイメントシステムに侵入された後、ECUソフトウェアを不正に書き換え、自動車制御を司るCAN通信ネットワークへデータ送信できるように改変されました。これにより、車内ネットワークへ不正データが送り付けられ、自動車制御が乱された事例になります。
この事例によるハッキングへの対策は以下の通りとなります。
- 不正な侵入を防ぐ
- マイコンのプログラムを改ざんさせない
- 不正なメッセージを送信/受信できないようにする
自動車制御を守るためには、不正なメッセージの送受信を防げば有効な対策となることが分かります。その対策として、以下のセキュリティ技術が車載ECUに導入されようとしています。
- ハードウェアセキュリティモジュール:マイコンやSoC等のデバイスに内蔵されるセキュリティ機能の専用モジュール
- メッセージ認証:車内ネットワーク通信の不正データや成りすましデータを検出・防止する仕組み
これらのセキュリティ技術により、車載ECUに認証機能を持たせ、プログラムや受信データが不正なものでないかを検証することが可能になります。
ハードウェアセキュリティモジュール
既存ECUに認証機能を持たせるためには、認証のための鍵の管理をいかにセキュアに保つかが重要になってきます。ハードウェアセキュリティモジュールは、鍵管理や認証子のための暗号生成や乱数発生などの重要機能をハードウェア的に独立したセキュアゾーンで実施することで、外部からの不正操作(読み出し、書込み)を防止します。
車載ECUのハードウェアセキュリティモジュールは、欧州のHIS(Hersteller Initiative Software)によるSHE(Secure Hardware Extension)や、EVITA(E-safety Vehicle Intrusion Protected Applications)プロジェクトによるHSM(Hardware Security Module)で規格化されています。
ハードウェアによる鍵管理や暗号化処理は、セキュア環境を保つとともに、ソフトウェアの処理負荷を減らし、車載ECUの限られた処理リソースやコストを考慮したものとなっています。
特にEVITAでは、各ECUが必要とするセキュリティレベルに応じて、EVITA Full / EVITA Medium / EVITA Lightの3段階のHSMを規定しています。
- EVITA Full:楕円曲線暗号アクセラレータ(ECC:Elliptic Curve Cryptography) やHash、AESアクセラレータを搭載。車車間や路車間をつなぐV2X通信をするECUに適応を想定。
- EVITA Medium:EVITA Fullに比べECCアクセラレータやHashはないが、セキュリティ用CPUを搭載しているのでクリティカルでない用途にはソフトウェア処理が可能。 エンジンECUやパワトレ系ECU、セントラルG/Wなど鍵管理をするECUへの適応を想定。
- EVITA Light:AESアクセラレータを搭載しているので、端末のOn board communicationをするセンサーやアクチュエータのECUへの適応を想定。主にメッセージ認証やCMAC生成・検証を行う。
HSMは、欧州自動車メーカが主導して活動してきた経緯もあり、北米、日本でもSHE,EVITAの考え方をベースにシステム検討がなされています。各マイコンベンダーからはHSMに対応した車載マイコンがリリースされています。
HSMを利用することで、ECUに認証機能を持たせることができるため、ECU起動時にプログラムが正しいかを検証するセキュアブート機能や、受信データの確からしさを検証することが可能になります。
但し、HSMの導入は、対応マイコンを使えば良いだけではありません。HSMを使ったデバッグや評価は、HSMの取り扱い上、決められた手順でしかできないなど制約があります。また、アクセラレータのコアや乱数がどう動いているかなど、ハードの中でやっていることは見れないため、デバッグで参照できる内容は限られてきます。そのため、HSMへのインプットとアウトプットを照らし合わせてデバッグするなど、HSMの組み方やデバッグ方法が従来と変わってきます。
メッセージ認証
自動車を制御する車内通信ネットワークはCAN通信が主流ですが、CANデータは平文であるため、外部からのデータ解析や不正データの注入が容易であることは、数々の自動車ハッキング検証からも明らかになっています。
不正なメッセージの種類は以下の通りとなります。
- なりすまし:本来あるECUに取って代わって、不正なデータを送信する
- 改ざん:本来送られるべきデータを改造して、不正なデータを送信する
- 再送攻撃:ネットワーク上に流れているデータをモニタリングして、同じものを再送する
車内ネットワークの通信セキュリティ対策として、外部からの通信データ改ざんや成りすましを検出するメッセージ認証の導入が進められています。メッセージ認証とは、通信データにメッセージ認証情報を付与することで通信データの認証を可能とし、データの完全性を保護する仕組みです。送信側、受信側でそれぞれ共通鍵を使ってメッセージ認証子(MAC : Message Authentication Code)を作成し、通信データのMACの値を比較します。
(1)送信側は共通鍵を使って作成したMACをメッセージに付与
(2)受信側でも、同じ鍵を使ってメッセージのMACを生成し、送信されたメッセージに付与されているMACと比較
(3)MACが一致した時のみ受信データを処理
◆AUTOSAR SecOCの特徴
AUTOSAR仕様では、メッセージ認証機能をSecOC(Secure Onboard Communication)で定義しており、メッセージ認証子の付与方法を仕様化しています。
AUTOSAR SecOCでは、通信データに共有鍵を使って作成したメッセージ認証子(MAC : Message Authentication Code)と、カウント値などから作成したFV (Freshness Value)を付与して送信。受信側でも共通鍵で作成したMAC値、FV値を受信データと比較することで、通信データの確からしさを検証します。
メッセージ認証では、データは秘匿して送受信するのではなく、データが信頼に足るデータかを検出する機構になります。そのため、データは平文で送受信されます。AUTOSARではSecOCの機能により、通信データの認証および完全性保護を謳っています。
AUTOSAR SecOCでは、共通鍵を用いてAES128で暗号化した値からMACを生成します。しかし、単純な暗号化だけでは、通信ネットワークに流れるデータをコピーして再送することで認証をパスする可能性があります。これを再送攻撃と呼びます。そのため、MAC生成アルゴリズムにカウンタなどの変動値であるFVを追加することで、MAC値はデータ送信する毎に変動し、再送攻撃を防ぐ仕組みを実現しています。
AUTOSAR SecOCでは、暗号アルゴリズムに「CMAC/AES-128」をサポートしており、SecOC Profile 1 ~ SecOC Profile 3の全てのプロファイルで「CMAC/AES-128」を使用しています。そのため、AUTOSAR BSWベンダーが提供するSecOC実装には、HSM対応マイコンとの組み合わせで使用することが多くなってきています。
MAC生成では、セキュリティプロファイルとして、以下の3つのプロファイルを規定しています。
SecOC Profile1 | SecOC Profile2 | SecOC Profile3 | |
アルゴリズム | CMAC/AES-128 | CMAC/AES-128 | CMAC/AES-128 |
FV長 | 定義なし | 0 (定義なし) | 64bits |
メッセージ上のFV長 | 8bits | 0bit (定義なし) | 4bits |
MAC長 | 24bits | 24bits | 28bits |
AUTOSAR SecOCを使った車載セキュリティ通信が主流になると、通信評価ツールもメッセージ認証対応が必要になってきます。通信データは平文のため、従来の通信アナライザツールでも通信モニタはできますが、ターゲットECUの通信評価に必要なノードシミュレーション機能は、AUTOSAR SecOCに対応したFV,MAC生成やメッセージ送信機能が必要です。
サニー技研では、MicroPeckerX CAN-FD Analyzerのオプション機能として、MicroPeckerXメッセージ認証機能プラグインをご用意しています。通信データのメッセージ認証検証機能やデータ送信機能など、通信評価に対応した機能を搭載しています。
サニー技研の車載セキュリティソリューション
サニー技研では、ユーザの車載ECUへの組込みセキュリティ導入にあたって、立上げ支援や開発プロセスに合わせてサポートします。HSM導入サポートや組込から、AUTOSAR SecOCまで、車載ECUに求められる組込ソフトウェアのセキュリティを中心にサポートが可能です。
各フェーズ | ユーザの作業 | 問題、トラブル | サニー技研サポート |
初期段階 | ■HSMシステム検証 ・CMAC生成時間計測 ・Secure Boot処理時間 ■セキュリティシステム検討 ・要求要件の実現性検討 |
・HSMがうまく立ち上がらない ・評価環境として何が必要なのかもわからない ・どのマイコン,SoCを使ったら機能が実現できるかわからない |
・HSMのレクチャー ・HSMシステムのインテグレーション方法 |
設計段階 | ■HSM機能設計 | ・マルチコア,Flashの排他制御をどうしたらいのかわからない ・鍵の冗長化をどうしたらいいのかわからない ・新しい暗号機能をどう組み込んでいいのかわからない |
・HSMの構造理解 ・HSMのKey Storage手法 |
コーディング段階 | ■HSMアプリケーションソフト開発 | ・デバッグしているが、何が悪いのかわからない | ・HSMの過去の問題点、データベース ・セキュアコーディング手法 |
評価段階 | ■HSMアプリケーションソフトの評価 ・メモリのオーバーフローチェック ・異常メッセージの評価 ・セキュリティ処理性能評価 ■脆弱性評価 ■脅威分析 |
・脆弱性、なりすまし等をどのように評価をしたらいいのかわからない ・脆弱性テストで工数がかかりすぎている ・脅威分析をどのようにしたらいいのかわからない |
・なりすましの評価方法 ・セキュリティ機能評価手法 |
量産段階 | ■不良解析 ■セキュリティモジュールの認証作業 |
・バックエンドでの鍵の管理が手間 ・デバッグPORTがOFFされているので、不具合の解析ができない ・セキュリティモジュール自体を認証したいが、どうしたらいいのかわからない |
・HSMのモジュールとしての認証方法 |
サニー技研では、これまで培ってきた車載ネットワーク技術、ノウハウを活かし、車載セキュリティ技術を組み合わせることで、通信からセキュリティの実現までをご提供します。特に当社では、CANや車載Ethernetに精通しており、マイコンのハードウェア周辺を熟知しているため、実際にお客様の開発の現場で有益なソリューションを提供しております。
車載マイコン用セキュリティサポートパンフレット
サニー技研で実施していますセキュリティ教育やセキュリティソリューションについて詳細にまとめたパンフレットがございます。
以下のリンクボタンよりダウンロードいただけます。
組込みマイコンのセキュリティ立上げ支援ソリューション
セキュリティソリューション | 日程/期間 | 内容 | マイコン展開品種 |
マイコンセキュリティレクチャ(座学) | 半日~ | HSMの概要を説明し、セキュリティの開発環境の準備からHSMの使い方などをレクチャします。 | ルネサスエレクトロニクス社製マイコンの他、Infineon、NXPなど |
マイコンセキュリティ実習 | 半日~ | セキュリティの開発環境の準備からHSMを搭載したマイコンを使って、乱数生成、鍵の登録、CMAC生成/検証を基板を用いて実習します。 | ルネサスエレクトロニクス社製マイコンの他、Infineon、NXPなど |
マイコンセキュリティ技術支援 | ~3ヶ月 | セキュリティのアーキテクチャ設定レビュー、セキュリティQA対応を実施します。 | ルネサスエレクトロニクス社製マイコンの他、Infineon、NXPなど |
HSM導入では、経験豊富なHSMの専門家やHSM組込実績を持つメンバがサポート可能です。また、車載通信セキュリティ導入では、AUTOSAR SecOCの開発実績や組込評価に長けたスペシャリストが多数在籍しています。
以下のサポート実績がございます。
- HSMのインテグレーション、立ち上げ支援/レクチャ/評価
- AUTOSAR SecOCなど通信+認証のアプリケーション開発/評価/検証
お困り事があればお気軽にご相談、お問い合わせください。
サニー技研の車載セキュリティへの取組み
サニー技研の車載セキュリティ開発の取り組み、開発実績は以下のリンクからご覧ください。
車載セキュリティ用語集
日本語/略語 | 英語 | 定義/意味 |
AES | Advanced Encryption Standard | 米国商務省標準技術局(NIST)によって制定された、米国政府の次世代標準暗号化方式 |
C&R | Challenge & Response | 通信回線やネットワークを介して利用者の認証を行う際に、パスワードなどの秘密の情報を直接やり取りすることなく確認する方式の一つ |
C2C-CC | Car-to-Car Communication Consortium | 2002年にドイツ自動車メーカが 欧州のITSにおける路車・車車間通信に関しての標準化を目的に設立した事業連合体 |
CAVP | Cryptographic Algorithm Validation Program | 暗号アルゴリズムの第3者検証 |
CBC | Cipher Block Chaining | 前の平文ブロックを暗号化した結果を次の平文にXOR演算によって重ね合わせ、その結果に対して暗号化処理を行うブロック暗号方式 |
CMAC | Cipher-based Message Authentication Code | ブロック暗号に基づくメッセージ認証符号アルゴリズム。認証及びデータの機密の保証に用いられる |
CRY | Cryptographic Library | AUTOSARの暗号ライブラリのこと |
CRYPTREC | Cryptography Research and Evaluation Committees | 電子政府において、推奨暗号の安全性を評価・監視し、暗号技術の適切な実装法・運用法を調査・検討するプロジェクト |
CSM | Crypto Service Manager | AUTOSARの暗号機能サービスマネージャ |
CTR | Counter Mode | ブロック暗号を同期型のストリーム暗号として扱う方式 |
CVSS | Common Vulnerability Scoring System | 共通脆弱性評価システムのことで、情報システムの脆弱性に対するオープンで包括的、汎用的な評価手法のこと |
CWE | Common Weakness Enumeration | ソフトウェアにおけるセキュリティ上の脆弱性の種類を識別するための共通基準の一覧 |
DCM | Data Communication Module | テレマティクスサービス専用に開発された車載タイプのインテリジェント通信モジュールのこと |
ECB | Electronic Code Book | メッセージをブロックに分割して、それぞれのブロックを独立して暗号化する方式 |
ECC | Elliptic Curve Cryptography | 楕円曲線と呼ばれる数式によって定義される特殊な加算法に基づいて暗号化・復号を行う方式のこと |
ECDH | Elliptic Curve Diffie-Hellman | 楕円曲線を使用して実行される鍵共有プロトコル |
EdDSA | Edwards-curve Digital Signature Algorithm | 公開鍵暗号において、エドワーズ曲線に基づいたデジタル署名の一つ |
EVITA | E-safety Vehicle Intrusion protected Applications | 2008年から2011年にドイツにおいて自動車をサイバー攻撃から保護する目的で、車載LANのセキュリティを保護する通信手順と実行処理基盤を研究開発するプロジェクト |
FIPS | Federal Information Processing Standards | アメリカ国立標準技術研究所が発行している標準規格で、軍事以外の用途で購買・利用する情報・通信機器の技術規格 |
GCM | Galois/Counter Mode | ブロック暗号の一つで、認証付きであることから、データ保護と認証(完全性確認)の両方の機能を有している |
HIS | Hersteller initiative Software | 欧州自動車メーカが中心となった業界団体 |
HMAC | Hash Message Authentication Code | ハッシュ関数を使ってメッセージ認証コードを実現する手法 |
HSM | Hardware Security Module | マイコンやSoC等のデバイスに内蔵されるセキュリティ機能の専用モジュール |
ICT | Information and Communication Technology | ネットワークへの不正侵入を検知するシステム |
IPA | Information-technology Promotion Agency, Japan | 独立行政法人情報処理推進機構 |
IVN | In Vehicle Network | 車載ネットワーク |
JAMA | Japan Automotive Manufactures Association | 日本自動車工業会 |
JASPAR | Japan Automotive Software Platform and Architecture | 2004年 9月に車載電子制御システムのソフトウエアやネットワークの標準化及び共通利用による、開発の効率化と高信頼性確保を目指し設立された一般社団法人 |
JSAE | Society of Automotive Engineers in Japan | 公益社団法人 自動車技術会 |
MAC | Message Authentication Code | メッセージ認証コード |
NIST | National Institute of Standards and Technology | 米国商務省標準技術局 |
OBD | On-Board Diagnostics | ECUにプログラミングされている自己診断機能 |
OSS | Open Source Software | 利用者の目的を問わずソースコードを使用、調査、再利用、修正、拡張、再配布が可能なソフトウェアの総称 |
OTA | Over The Air | 無線通信を用いてデータを送受信することを指し、ソフトウェアの更新などを行う際に用いられる技術 |
PFU | Physically Unclonable Function | 複製困難な物理的特徴を利用してデバイスに固有の値を出力する関数のこと |
PRESERVE | Preparing Secure Vehicle-to-X Communication Systems | EVITAプロジェクトの後を受けて、2011年に欧州でV2Xにおけるセキュリティを検討したプロジェクト |
PRNG | Pseudo Random Number Generator | 擬似乱数器 |
RSA | Rivest Shamir Adleman | 公開鍵暗号アルゴリズム。RSAは開発者の名前に由来する |
SAE | Society of Automotive Engineers | 米国自動車技術者協会 |
SHE | Secure Hardware Extension | HISによって策定されたECUのセキュリティ拡張機能 |
SSL | Secure Sockets Layer | インターネット上で通信を暗号化し、第三者による通信内容の盗み見や改ざんを防ぐ技術 |
TCG | Trusted Computing Group | 2003年4月に設立されたコンピュータの信頼性と安全性を向上させるための標準技術を策定する米国の業界団体 |
TPM | Trusted Platform Module | コンピュータのマザーボードなどに装着される、セキュリティ関連の処理機能を実装したデバイス |
TRNG | True Random Number Generator | 真性乱数生成器 |
XTS | XEX encryption mode with tweak and ciphertext stealing | ストリーム暗号の一種で、ディスクの暗号化等に使用され、IEEEで標準化されたが、その後パラメータの制約を加えた上でNISTで XTS-AESとして標準化された |
エンティティ | entity | 実態、人,グループ,デバイス又はプロセス |
ファジングテスト | Fuzzing test | ファジングの基本的な手順は,対象のソフトウェアに対して問題が起こりそうなデータを大量に入力し,それに対する挙動を確認するというもの |
ペネトレーションテスト/侵入試験 | Penetration test | ネットワークに接続されているコンピュータシステムに対し、実際に既知の技術を用いて侵入を試みることで、システムに脆弱性がないかどうかテストする手法のこと。侵入実験または侵入テストとも言われる |