翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS IoT over-the-air (OTA) 更新ライブラリの移植
FreeRTOS over-the-air (OTA) の更新では、次のことを実行できます。
-
新しいファームウェアイメージを単一のデバイス、デバイスのグループ、またはフリート全体に展開します。
-
グループに追加、リセット、または再プロビジョニングされると、デバイスにファームウェアを展開します。
-
新しいファームウェアがデバイスに導入された後、そのファームウェアの信頼性と完全性を検証します。
-
デプロイの進行状況をモニタリングします。
-
失敗したデプロイをデバッグします。
-
のコード署名を使用してファームウェアにデジタル署名します AWS IoT。
詳細については、FreeRTOS ユーザーガイドの「FreeRTOS 無線通信経由の更新」およびAWS IoT 「O ver-the-air 更新ドキュメント
OTA 更新ライブラリを使用して、OTA の機能を FreeRTOS アプリケーションに統合できます。詳細については、FreeRTOS ユーザーガイドの FreeRTOS OTA 更新ライブラリを参照してください。
FreeRTOS デバイスは、受信した OTA ファームウェアイメージに対して暗号化コード署名検証を実行する必要があります。以下のアルゴリズムを推奨します。
-
楕円曲線デジタル署名アルゴリズム (ECDSA)
-
NIST P256 曲線
-
SHA-256 ハッシュ
前提条件
-
移植のためのワークスペースとプロジェクトの設定 の手順を完了させます。
-
ネットワークトランスポートインターフェイスポートを作成します。
詳細については、「ネットワークトランスポートインターフェイスの移植」を参照してください。
-
coreMQTT ライブラリを統合します。詳細については、「FreeRTOS ユーザーガイド」の「coreMQTT ライブラリ」を参照してください。
-
OTA 更新をサポートするブートローダーを作成します。
プラットフォームの移植
OTA ライブラリを新しいデバイスに移植するには、OTA ポータブル抽象化レイヤー (PAL) を実装する必要があります。PAL API は、実装固有の詳細を指定する必要がある ota_platform_interface.h
関数名 |
説明 |
|---|---|
|
OTA 更新を停止させます。 |
|
受信したデータチャンクを保存するファイルを作成します。 |
|
指定されたファイルを閉じます。暗号保護を実装するストレージを使用している場合、これによってファイルが認証される可能性があります。 |
|
指定されたファイルに、指定されたオフセットでデータブロックを書き込みます。成功すると、関数によって書き込まれたバイト数が返されます。その他の場合は、関数によって負のエラーコードが返されます。ブロックのサイズは常に 2 の累乗でアラインされます。詳細については、OTA ライブラリの「Configurations」 |
|
新しいファームウェアイメージをアクティブ化または起動します。一部のポートでは、デバイスがプログラム的に同期的にリセットされると、この関数は戻りません。 |
|
最新の OTA ファームウェアイメージ (またはバンドル) を受け入れるか拒否するためにプラットフォームで必要なものを行います。この関数を実装するには、ボード (プラットフォーム) の詳細とアーキテクチャについてのドキュメントを参照してください。 |
|
OTA 更新イメージの状態を取得します。 |
デバイスがそれらをサポートしている場合は、この表の関数を実装してください。
関数名 |
説明 |
|---|---|
|
指定したファイルの署名を確認します。 |
|
指定された署名者証明書をファイルシステムから読み込み、発信者に返します。 |
|
デバイスをリセットします。 |
注記
OTA 更新をサポートできるブートローダーがあることを確認してください。 AWS IoT デバイスブートローダーの作成方法については、「IoT デバイスブートローダー」を参照してください。
E2E テストと PAL テスト
OTA PAL テストと E2E テストを実行します。
E2E テスト
OTA エンドツーエンド (E2E) テストは、デバイスの OTA 機能を検証し、実際のシナリオをシミュレートするために使用されます。このテストにはエラー処理が含まれます。
前提条件
このテストを移植するには、以下のことが必要です。
AWS OTA ライブラリが統合されたプロジェクト。追加情報については、OTA ライブラリの「移植ガイド」
を参照してください。 OTA ライブラリを使用してデモアプリケーションを移植し、 AWS IoT Core とやり取りして OTA 更新を行います。OTA デモアプリケーションの移植 を参照してください。
IDT ツールをセットアップします。これにより、OTA E2E ホストアプリケーションが実行され、さまざまな構成でデバイスをビルド、フラッシュ、監視し、OTA ライブラリの統合が検証されます。
OTA デモアプリケーションの移植
OTA E2E テストには、OTA ライブラリの統合を検証するための OTA デモアプリケーションが必要です。デモアプリケーションには、OTA ファームウェアの更新を実行できる能力が必要です。FreeRTOS OTA デモアプリケーションは、FreeRTOS GitHub
移植手順
OTA エージェントを初期化します。
OTA アプリケーションコールバック関数を実装します。
OTA エージェントイベント処理タスクを作成します。
OTA エージェントを開始します。
OTA エージェントの統計を監視します。
OTA エージェントをシャットダウンします。
詳細な手順については、「FreeRTOS OTA over MQTT - Entry point of the demo
構成
を操作するには、次の設定が必要です AWS IoT Core。
AWS IoT Core クライアント認証情報
Amazon 信頼サービスエンドポイントを使用して、
Ota_Over_Mqtt_Demo/demo_config.hの democonfigROOT_CA_PEM をセットアップします。詳細については、AWS サーバー認証を参照してください。AWS IoT クライアント認証情報
Ota_Over_Mqtt_Demo/demo_config.hを使用して、 で democonfigCLIENT _CERTIFICATE_PEM と democonfigCLIENT _PRIVATE_KEY_PEM を設定します。クライアント証明書とプライベートキーについては、AWS クライアント認証の詳細を参照してください。
アプリケーションバージョン
OTA コントロールプロトコル
OTA データプロトコル
コード署名の認証情報
その他の OTA ライブラリ設定
前述の情報は、FreeRTOS OTA デモアプリケーションの demo_config.h および ota_config.h にあります。詳細については、「FreeRTOS OTA over MQTT - Setting up the device
ビルド検証
デモアプリケーションを実行して OTA ジョブを実行します。テストが正常に完了したら、引き続き OTA E2E テストを実行できます。
FreeRTOS OTA デモ
IDT ツールによるテストの実行
OTA E2E テストを実行するには、 AWS IoT Device Tester (IDT) を使用して実行を自動化する必要があります。詳細については、「FreeRTOS ユーザーガイド」の「AWS IoT Device Tester for FreeRTOS」を参照してください。
E2E テストケース
テストケース |
説明 |
|---|---|
|
定期的な OTA 更新のハッピーパステスト。これにより、新しいバージョンで更新が作成され、デバイスが正常に更新されます。 |
|
このテストでは、3 回連続で OTA 更新を作成します。デバイスは 3 回連続して更新される見込みです。 |
|
このテストでは、デバイスが新しいファームウェアでネットワークに接続できない場合に、以前のファームウェアにロールバックすることを確認します。 |
|
このテストでは、バージョンが変わらない場合に、受信したファームウェアをデバイスが拒否することを確認します。 |
|
このテストでは、イメージが署名されていない場合に、デバイスが更新を拒否することを確認します。 |
|
このテストでは、ファームウェアが信頼できない証明書で署名されている場合に、デバイスが更新を拒否することを確認します。 |
|
このテストでは、デバイスが古い更新のバージョンを拒否することを確認します。 |
|
デバイスによって、サポートされる署名アルゴリズムとハッシュアルゴリズムは異なります。このテストでは、サポートされていないアルゴリズムで作成されている場合に、デバイスが OTA 更新に失敗することを確認します。 |
|
これは一時停止/再開機能のハッピーパステストです。このテストでは、OTA 更新を作成して、更新を開始します。次に、同じクライアント ID (モノの名前) と認証情報 AWS IoT Core を使用して に接続します。 AWS IoT Core これにより、デバイスは切断されます。デバイスは、 から切断されていることを検出し AWS IoT Core、一定期間後にそれ自体を停止状態に移行して、ダウンロードへの再接続 AWS IoT Core と再開を試みることが期待されます。 |
|
このテストでは、一時停止状態のときに OTA ジョブがキャンセルされた場合に、デバイスが自動的に復旧できるかどうかを確認します。 |
|
OTA 更新が作成されたら、S3 の署名付き URL の有効期間を設定できます。このテストでは、URL の有効期限が切れてダウンロードを完了できなくても、デバイスが OTA を実行できることを確認します。デバイスは、新しいジョブドキュメントを要求することが期待されます。このドキュメントには、ダウンロードを再開するための新しい URL が含まれています。 |
|
このテストでは、2 回続けて OTA 更新を作成します。デバイスが最初の更新をダウンロードしていると報告すると、テストは最初の更新を強制的にキャンセルします。デバイスは、現在の更新を中止して 2 回目の更新を取得し、更新を完了することが期待されます。 |
|
このテストでは、2 回続けて OTA 更新を作成します。デバイスが最初の更新をダウンロードしていると報告すると、テストは最初の更新を強制的にキャンセルします。デバイスは、現在の更新を中止して 2 回目の更新を取得し、更新を完了することが期待されます。 |
|
このテストでは、イメージがクラッシュしたときに、デバイスが更新を拒否できることを確認します。 |
PAL テスト
前提条件
ネットワークトランスポートインターフェイスのテストを移植するには、次のものが必要です。
有効な FreeRTOS カーネルポートを使用して FreeRTOS をビルドできるプロジェクト。
OTA PAL の実用的な実装。
移植
FreeRTOS-Libraries-Integration-Tests
をサブモジュールとしてプロジェクトに追加します。プロジェクト内のサブモジュールの場所は、そのサブモジュールをビルドできる場所でなければなりません。 config_template/test_execution_config_template.hとconfig_template/test_param_config_template.hをビルドパス内の場所にコピーし、名前をtest_execution_config.hとtest_param_config.hに変更します。関連ファイルをビルドシステムに含めます。
CMakeを使用している場合は、qualification_test.cmakeとsrc/ota_pal_tests.cmakeを使用して関連ファイルを含めることができます。次の関数を実装して、テストを設定します。
SetupOtaPalTestParam():src/ota/ota_pal_test.hで定義されています。実装には、ota_pal_test.hで定義されているものと同じ名前と署名が必要です。現在のところ、この機能を設定する必要はありません。
テスト出力ログがデバイスログとインターリーブしないように、UNITY_OUTPUT_CHAR を実装します。
アプリケーションから
RunQualificationTest()を呼び出します。呼び出す前に、デバイスのハードウェアが正しく初期化され、ネットワークが接続されている必要があります。
テスト
このセクションでは、OTA PAL 認定テストのローカルテストについて説明します。
テストの有効化
test_execution_config.h を開いて、OTA_PAL_TEST_ENABLED を 1 に定義します。
test_param_config.h で、以下のオプションを更新します。
OTA_PAL_TEST_CERT_TYPE: 使用する証明書タイプを選択します。
OTA_PAL_CERTIFICATE_FILE: デバイス証明書へのパス (該当する場合)。
OTA_PAL_FIRMWARE_FILE: ファームウェアファイルの名前 (該当する場合)。
OTA_PAL_USE_FILE_SYSTEM: OTA PAL がファイルシステム抽象化を使用している場合は、1 に設定します。
任意のツールチェーンを使用して、アプリケーションのビルドとフラッシュを行います。RunQualificationTest() が呼び出されると、OTA PAL テストが実行されます。テスト結果はシリアルポートに出力されます。
OTA タスクの統合
現在の MQTT デモに OTA エージェントを追加します。
を使用して OTA エンドツーエンド (E2E) テストを実行します AWS IoT。これにより、統合が期待どおりに機能しているかどうかが検証されます。
注記
FreeRTOS のデバイスを正式に認定するには、デバイスの移植されたソースコードを で OTA PAL および OTA E2E テストグループと照合する必要があります AWS IoT Device Tester。FreeRTOS ユーザーガイドの「Using AWS IoT Device Tester for FreeRTOS」の指示に従って、ポート検証 AWS IoT Device Tester 用に を設定します。 FreeRTOS 特定のライブラリのポートをテストするには、 フォルダの device.json ファイル AWS IoT Device Tester configsで正しいテストグループを有効にする必要があります。
IoT デバイスブートローダー
独自のセキュアなブートローダーアプリケーションを提供する必要があります。設計と実装がセキュリティの脅威を適切に緩和するようにしてください。参考までに、脅威モデリングを以下に示します。
IoT デバイスブートローダーの脅威モデリング
背景
作業定義として、この脅威モデルによって参照される組み込み AWS IoT デバイスは、クラウドサービスとやり取りするマイクロコントローラーベースの製品です。コンシューマー、商用、または産業用にデプロイできます。IoT デバイスは、ユーザー、患者、マシン、環境に関するデータを収集し、電球やドアロックから工場の機械に至るまで、あらゆるものを制御できます。
脅威モデリングは、仮定の敵対者の観点からのセキュリティへのアプローチです。敵対者の目標と方法を検討することで、脅威のリストが作成されます。脅威とは、敵によって実行されるリソースまたはアセットに対する攻撃です。リストは優先順位付けされ、緩和策を識別および作成するために使用されます。緩和策を選択する場合、実装と保守のコストは、それらが提供する実際のセキュリティ価値とのバランスを取る必要があります。複数の 脅威モデルの方法論
FreeRTOS は、 AWS IoT デバイスに OTA (over-the-air) ソフトウェア更新を提供します。更新機能は、クラウドサービスとオンデバイスソフトウェアライブラリとパートナー提供のブートローダーを組み合わせます。この脅威モデルは、特にブートローダーに対する脅威に焦点を当てています。
ブートローダーのユースケース
-
展開する前に、ファームウェアにデジタル署名し、暗号化します。
-
新しいファームウェアイメージを単一のデバイス、デバイスのグループ、またはフリート全体にデプロイします。
-
新しいファームウェアがデバイスに導入された後、そのファームウェアの信頼性と完全性を検証します。
-
デバイスは、信頼できるソースから変更されていないソフトウェアのみを実行します。
-
デバイスは、OTA を介して受け取ったソフトウェアに障害耐性があります。
データフロー図
脅威
一部の攻撃には複数の緩和モデルがあります。例えば、悪意のあるファームウェアイメージを配信する man-in-the-middle ことを目的としたネットワークは、TLS サーバーが提供する証明書と新しいファームウェアイメージのコード署名者証明書の両方に対する信頼を検証することで緩和されます。ブートローダーのセキュリティを最大化するために、ブートローダー以外の緩和策は信頼できないと見なされます。ブートローダーには、攻撃ごとに組み込み緩和策が必要です。レイヤード緩和ソリューションがあることは、 と呼ばれます defense-in-depth。
脅威:
-
攻撃者は、悪意のあるファームウェアイメージを配信するために、デバイスからサーバーへの接続をハイジャックします。
緩和の例
-
ブートローダーは、起動時に、既知の証明書を使用してイメージの暗号化署名を検証します。検証に失敗した場合、ブートローダーは前のイメージにロールバックします。
-
-
攻撃者は、バッファオーバーフローを悪用して、フラッシュに保存されている既存のファームウェアイメージに悪意のある動作を導入します。
緩和の例
-
ブート時に、前に説明したように、ブートローダーが検証します。以前のイメージが使用できない状態で検証に失敗すると、ブートローダーは停止します。
-
ブート時に、前に説明したように、ブートローダーが検証します。以前のイメージが使用できない状態で検証に失敗すると、ブートローダーはフェイルセーフ OTA 専用モードに入ります。
-
-
攻撃者は、以前に保存されたイメージからデバイスを起動します。このイメージは悪用可能です。
緩和の例
-
最後のイメージを保存する Flash セクターは、新しいイメージのインストールとテストに成功すると消去されます。
-
ヒューズはアップグレードが成功するたびに焼き付けられ、正しい数のヒューズが焼き付けられていない限り、各イメージの実行は拒否されます。
-
-
OTA 更新は、デバイスをブロックする障害のあるイメージや悪意のあるイメージを配信します。
緩和の例
-
ブートローダーは、前のイメージへのロールバックをトリガーするハードウェアウォッチドッグタイマーを開始します。
-
-
攻撃者はブートローダーにパッチを適用してイメージの検証をバイパスし、デバイスが署名されていないイメージを受け入れるようにします。
緩和の例
-
ブートローダーは ROM (読み取り専用メモリ) にあり、変更することはできません。
-
ブートローダーは OTP (one-time-programmable メモリ) にあり、変更できません。
-
ブートローダーは ARM のセキュアゾーンにあり TrustZone、変更できません。
-
-
デバイスが悪意のあるイメージを受け入れるように、攻撃者は検証証明書を置き換えます。
緩和の例
-
証明書は暗号コプロセッサにあり、変更することはできません。
-
証明書は ROM (または OTP、またはセキュアゾーン) にあり、変更することはできません。
-
脅威のさらなるモデル化
この脅威モデルでは、ブートローダーのみを考慮します。さらに脅威モデリングを行うことで、全体的なセキュリティを向上させることができます。推奨される方法は、敵対者の目標、それらの目標の対象となるアセット、およびアセットへの参入ポイントをリストすることです。脅威のリストは、エントリポイントに対する攻撃を考慮してアセットをコントロールすることで作成できます。以下は、IoT デバイスの目標、アセット、エントリポイントの例です。これらのリストはすべてを網羅したものではなく、さらなる検討を促進することを目的としています。
敵対者の目標
-
資金の強要
-
評判を落とす
-
データの改ざん
-
リソースの転送
-
ターゲットをリモートでスパイ
-
サイトへの物理的なアクセスを獲得する
-
大惨事
-
恐怖を与える
主要なアセット
-
プライベートキー
-
クライアント証明書
-
CA ルート証明書
-
セキュリティ認証情報とトークン
-
お客様の個人識別情報
-
企業シークレットの実装
-
センサーデータ
-
クラウド分析データストア
-
クラウドインフラストラクチャ
エントリポイント
-
DHCP レスポンス
-
DNS レスポンス
-
MQTT over TLS
-
HTTPS レスポンス
-
OTA ソフトウェアイメージ
-
その他 (アプリケーションによって指示される USB など)
-
バスへの物理的なアクセス
-
デキャップされた IC
