Over-the-Air (OTA) によるソフトウェアやファームウェアの更新は、携帯機器、産業機器、自動車分野の組み込みプラットフォームで時代とともに増加しています。 製品が実世界に出ると、バグ修正、セキュリティ修正、または機能更新に関連するファームウェアやソフトウェアの更新が、デバイスの改善や最新のソフトウェアに更新するために必要となります。 自動車の場合、ファームウェアやソフトウェアを通信機器を使って無線で更新し、車内のゲートウェイを経由して、最近の自動車で存在感を増しているECUに送ります。

自動車におけるOTAの必要性とは？ 現在、自動車は従来の機械的なコンポーネントではなく、主にソフトウェアで制御されています。 一昔前は、ソフトウェアの更新が必要な場合、車両をサービスステーションまで牽引し、車両をシステム/コンピュータに接続して更新していました。 OTAは、以前からあった更新ごとの信頼性の問題、次にサービスステーションに車両を運ぶという依存性の問題を解決し、ソフトウェア更新のコストは非常に低くなり、顧客やサービスステーションに大きな手間をかけさせません。 携帯電話と自動車のOTAアップデートはアプローチが異なり、自動車のOTAアップデートはハンドヘルド機器に比べて複雑で厳しいため、不適切なソフトウェア更新はユーザーライフにも害を及ぼす可能性があります。 現在、自動車の主要部品は電子制御ユニット（ECU）であり、ECUはすべての機械的なステアリング部品に取って代わっています。 一般に、ECUは1つまたは複数のネットワークで相互接続され、複雑な相互作用と規制を可能にする情報を共有しています。 例えば、先進運転支援システム（ADAS）では、機能的な能力の向上はシステムの複雑化を伴い、車両全体の安全・安心に影響を及ぼす可能性のあるソフトウェアバグが発生しやすくなる。 定期的なソフトウェアの更新と機能拡張を行うことで、車両の全ライフタイムに渡ってシステムの正確性、効率性、信頼性を確保することができます。 本ブログでは、自動車業界におけるOTAソフトウェアアップデートをサポートするためのエンドツーエンドのソリューションについて主に説明します。 前節では、OTAについて説明し、自動車産業におけるOTAアップデートは、無線によるソフトウェア更新の際にセキュリティの面で大きな課題を抱えていることを理解しました。

  • エンジンのトランスミッションのオン/オフ
  • 乗客やドライバーを車内に閉じ込める
  • ホーンを鳴らし続ける
  • ハンドルシステムを制御する
  • 車のブレーキシステム
  • 道路規制を超えて車の速度を上げる
  • 自動車の安全性。
  • ナビゲーション、オーディオ、またはインフォテインメントシステムを制御する
  • コックピットの誤報

では、OTAアップデートが車両内でどのように行われるかを見てみましょう。 概要を説明します。 車両のOTAリモートアップデート方式は、高速で費用対効果が高く、ECU上で動作するソフトウェアを無線で更新することができ、車のユーザーはサービスセンターや修理工場に行かなくても、どこでもソフトウェアを更新することができます。 さらに、OEMは車から無線を通じて受信したデータに基づいて車を診断できる

Figure 1: OTA updateの概要

自動車システムにおける安全なOTA。 ECUのファームウェアやソフトウェアのアップデートにおいて、セキュアなOTAアップデートは最も重要なファクターである。 セキュアなOTAアップデートを実現するためには、多くの課題がある。 セキュアなOTAアップデートを実現するために、業界全体では多くの技術が提案・実装されています。 今回はその中から、自動車業界で最も一般的に使用されている技術を紹介します。 エンドツーエンドのアーキテクチャ全体を3つの要素に分け、その目的は何かを考えてみましょう。 バックエンド サーバー

  • 更新されたイメージを作成する/異なる Tier-1 からイメージを収集する
  • デバイスにフラッシュするファームウェアおよびソフトウェア更新イメージを提供する
  • ヘッド ユニットが更新を要求する場合、クライアント/サーバー アーキテクチャをサポートする必要があるかもしれません。

通信チャネル

  • セキュアなメカニズムを提供
  • イメージやデータが改ざんされないよう、セキュアなN/Wを提供すること。

ヘッドユニット

  • ソフトウェアアップデートのトリガー（クライアント）
  • 正しい画像がインストールされているか確認
  • 画像アップデート中のダウンタイム低減
  • 障害時のロールバック

バックエンドサーバー:

  • ソフトウェアアップデートを行うには、クライアントが必要である場合があります。 バックエンドサーバーは、主に車載ユニットに展開する必要のあるファームウェアとソフトウェアイメージの作成に責任を負います。 バックエンドサーバーは、異なるTier-1サプライヤーから展開される必要があるイメージを収集し、すべてのECUのために1つのイメージにそれをパックしようとします。 このバックエンドサーバーは、Yoctoベースのシステム（オープンソース）またはサードパーティサポートアーキテクチャをベースとすることができます。 通信チャネル。 このコンポーネントで最も難しいのは、データ/画像がn/wに公開され、攻撃者が容易に操作できるようになる場合です。 ヘッドユニットへのセキュアなアップデートのための技術、オープンソースやサードパーティーのソリューションは数多くありますが、最もよく使われているのはUptaneです。 Uptaneは、OTAアップデートシステムの実装を設計レベルでガイドする、初の包括的なセキュリティフレームワークです。 ヘッドユニット（車両本体）：ヘッドユニットは、多くのECUで構成されており、高速なもの、低速なもの、またECUの種類、TCU（テレマティクス制御ユニット）、ゲートウェイなど、あらゆるコンポーネントがOTAアップデートにおいて役割を担っています。 ヘッドユニットは、ファームウェアやソフトウェアを更新するために、バックエンドに接続する準備が整っていることを確認する必要があります。 あるいは、それ自体がアップデートを要求するトリガーとなる機能を備えている必要があります。 Uptaneを使ったOTAアップデート アップデートフレームワーク（TUF）は、ソフトウェアリポジトリのユーザーをセキュリティ攻撃から保護するためのセキュリティシステムを構築するために設計されています。 バックエンドサーバーが安全でない場合や、暗号に使用する鍵が盗まれることを想定して設計されています。 そのため、特定のシステムに依存しない分散型システムを構築し、攻撃者のスレッドがあったとしても、すべてのシステムを同時に簡単にハッキングすることができないようになっているのです。 アップデートフレームワーク（TUF）では、役割を4つに分けています（Root of trust、Timestamps、Snapshot、Targets）。Uptaneはアップデートフレームワーク（TUF）をベースにしており、分散型（タイムサーバー、ディレクトリとイメージリポジトリ、マニフェスト、プライマリ/セカンダリECU、完全/部分検証)である

    図2 Uptaneバックエンドサーバーの概要。 画像（ECUに更新が必要なデータ）とメタデータ（暗号ハッシュ、ファイルサイズ）が格納される。 画像リポジトリ。 イメージリポジトリは、オフラインキーを使用して、ECUのすべての利用可能な更新のためのメタデータに署名する。 定期的（例：毎週、毎月）に利用可能な画像に関するメタデータを更新するUptaneコマンドラインツールを使用してメタデータを生成するオフライン鍵の閾値（例：Yubikey、HSMなどがよく使われる）を使用してメタデータに署名する

    図3：画像リポジトリディレクトリレポジトリ。 ディレクトリリポジトリは、車両のECUにインストールするために使用されるメタデータに署名するためにオンラインキーを使用しました。 どのイメージをどのECUにインストールする必要があるかを決定し、車両ごとに異なるメタデータを作成し、インベントリデータにアクセスして車両に関する詳細を取得します。 通常、車両が持っているものに応じて、インストールするアップデートを指示するために使用されます

    • 瞬時にアップデートをブラックリスト化するために使用可能
    • Uptane API を使用して署名付きメタデータを生成
    • ECU に関する情報（例:,

    Figure 4: Directory repository

    つまり、インストール前に、ディレクトリとイメージ リポジトリからの指示が一致するかどうかを確認する必要があるということです。 プライマリECUが各ECUSのトークンリストをタイムサーバーに送信すると、タイムサーバーはトークンリストと現在時刻を含む署名付きメッセージを返す。 ヘッドユニット（Vehicle Itself）。 6495>

  • 1次ECU（TCU）は画像をダウンロードし、それを検証した後、他の2次ECUにメタデータを配布する
  • 2次ECUも画像を更新する前に検証を行う

    • 。

  • 完全検証および部分検証を行う

図6：ECU間の通信

通信チャネル

ヘッドユニットからバックエンドサーバへの通信の完全フローです。

図7：通信チャネル

Uptaneを展開するために必要なことは何ですか？

  • OEM は、
    • Director リポジトリ
    • Image リポジトリ
    • Time サーバー（オプション）
  • Image is signed by
    • サプライヤーまたは OEM、または両方！
    • Images are added by
        Supplier or OEM, or Both?
  • ECU は、
    • Full verification, または
    • Partial verification
  • May keep using your existing TLS, etc. を行うものとする。 transport
    • Transport / Caching が侵害されても、セキュリティ リスクはほとんどない

    OTA update の課題

    • Automotive is more complex architecture with increasing of ECU, updating the different type of ECU itself become challenging
    • The security of the data over the air are high risk.となるため。
    • ファームウェアやソフトウェアのアップデートは、ネットワーク帯域幅、ストレージ、コンピューティングなどの最小限のリソースで行う方法です。
    • アプリケーションだけでなく、デバイスのコアドライバーやソフトウェアも更新できますか。
    • ソフトウェア更新のロールバック機構
    • ソフトウェアまたはファームウェアの更新中に高いダウンタイムは許容されません。
    • The size of the software blocks
    • How seamlessly OTA happens with impacting the current system.

    Conclusion

    自動車業界では、時間とともにソフトウェア更新が進み、最新であることを確認することができるようになりました。 自動車は安全に更新される必要がある。

    Further reading

    • Enabling SAE L3-L5 Autonomy with Sensor Fusion: Approaches and Challenges
    • Safety Concept for Automated Driving
    • Guide to Porting Real-time Traffic Sign Recognition Algorithm on Texas Instruments TDA2x SoC
  • Safety Concept for Automated Driving