OTAアップデートの設計

OTA(Over the Air)アップデートは、組み込み機器を遠隔で安全に更新するために欠かせない仕組みです。この記事では、ロールバックやデュアルバンク方式の概要、リソース制約やセキュリティを考慮したOTA設計のポイントを解説します。

OTAアップデートとは

OTAアップデートとは、組み込み機器のファームウェアを遠隔で更新する仕組みです。組み込みシステムは物理的にアクセスの難しい場所や、更新作業ができない場所に設置されることが一般的なため、無線通信を利用したアップデート機能は必須になります。

OTAに失敗すると、システムが破損し復旧不可能となったり、不完全な上書きでシステム全体に悪影響を及ぼしたりします。アップデート中の停電など、外的要因による処理の中断も考えられるでしょう。OTAアップデートは、失敗しても復旧できる仕組みとセットで提供する必要があります。

OTAは失敗を前提とした設計にするのが基本です。具体的には、成功判定とロールバック手段を用意します。失敗したときは旧バージョンへ戻すロールバック機構を実装する必要があります。ただし、安全復旧として前バージョンを起動させるロールバックは許容しつつ、攻撃によるダウングレードとは区別しなければなりません。署名は正しいが古い脆弱版へ戻す攻撃を防ぐために、ブートローダ側で単調増加のバージョンを検査します。

ロールバックの実現方法

デュアルバンク構成によるOTAアップデートの動作を、正常時と異常時に分けて示した図。正常時(アップデート成功)は、クラウドから配信を受け、BANK Aで実行しながら待機中のBANK Bへ書き込み、検証OKのあとBANK Bで起動して切り替わり、BANK Aが待機中になる。異常時(アップデート失敗)は、BANK Bへの書き込み後に検証NGとなり、自動ロールバックして元のBANK Aで起動を続け、BANK Bは失敗のまま使われない。

正常時は新しいBankに切替 / 異常時は元のBankに自動復帰

ファームウェアのアップデートとロールバックの方式は、いくつかあります。中でもアップデートの書き込み中にダウンタイムが発生せず、失敗時に元の面へ戻せるメリットがあるため、デュアルバンク型のOTAが選ばれやすくなっています。

デュアルバンク(A/Bスロット)方式の実装

フラッシュ領域をA/Bの2スロットとして確保し、片方が動作している間に、もう片方のアップデートを実施する方式です。スロットの確保方法は物理的に2バンクでも、単一フラッシュの2パーティションでも構いません。アップデートが終了した場合は、再起動するタイミングで自動的に新しいフラッシュバンクへ切り換わります。アップデートに失敗した場合はロールバックし、アップデート前のシステムを利用できる状態に戻します。

ブートローダとの関連

電源投入時、ブートローダはブート制御用のメタデータ領域を参照し、条件に応じて起動するファームウェアを決定します。起動して最初に参照するファームウェアには、更新ステータスフラグや起動面選択フラグなどが含まれます。更新ステータスフラグが「更新完了」かつ検証が正常な場合に限り、新しいファームウェアを起動することでOTAアップデートが完了する仕組みです。

このプロセスにCRC検証を含めることで、起動時の偶発的な事象に起因するファームウェア破損も検知できます。壊れたファームウェアをブートローダが読み込んで起動不能になる事態を避けやすくなるため、より安全な組み込み機器を設計できます。なお、CRCは伝送誤り・書き込み誤りなどの偶発エラー検出には有効ですが、攻撃者が内容とCRCを再計算して書き換える改ざんは防げません。改ざん検知には署名検証を併用します。

デュアルバンク方式のメリットとデメリット

安全性と可用性の高さがデュアルバンク方式の大きなメリットです。OTAアップデート中もシステムを稼働できるとともに、アップデートが失敗した場合でもシステムが起動しなくなるリスクを低減します。

一方で、多くのメモリ容量を要すること、管理が複雑になることはデメリットとして挙げられます。切り換え用にAスロット、Bスロットの2面が必要になるためです。スロットの2パーティション型を採用する場合でも、ある程度のメモリ容量を要します。リソースの限られる組み込みシステムでは、実装に制約が出る可能性もあります。

実装時のポイント

実装時に注意すべき点を列挙します。

リソース制約

デュアルバンクの更新をおこなえるだけのメモリ容量の確保が必須です。OTAアップデートにかかる時間も確認が必要です。書き込みに必要な時間だけでなく、データの転送や書き込み後のブートも含めた時間が所要時間です。

データの転送速度は、通信方式にも左右されます。更新時間を短くすることで、通信断によるリトライや更新処理の中断といったリスクを減らせます。リソースとして意識しているのはメモリ容量かもしれませんが、それ以外に読み込み・書き込み速度にも着目する必要があります。

セキュリティ

OTAアップデートでは、ファームウェアの安全性を担保することが必要です。改ざんされておらず、発行元が信頼できることを保証する必要があります。製造側で保持する秘密鍵と外部に公開する公開鍵をあらかじめ用意したうえで、公開鍵を使って署名の検証をおこないます。このデジタル署名方式によって、ファームウェアの真正性を担保します。さらに、通信ルートも暗号化し、途中で改ざんされるリスクから保護します。

信頼性

検証や試験でファームウェアにバグがないことを担保します。特にブートローダにバグが存在すると、二度と起動しないなどの致命的な障害を引き起こすおそれがあります。OTAアップデートの信頼性を上げるためには、正確な内容のファームウェアを配信することが必要です。

対象機器の台数が多い場合は、一部の機器から適用を開始するカナリアリリースも有効です。数台に適用したあと、安定稼働を確認してからすべての機器に対してアップデートを配信することで、大規模な障害を防げます。

組み込みソフトの世界 トップへ戻る