暗号化チップを使用してIoTデバイスの設計にセキュアブートを追加

最善の努力にもかかわらず、モノのインターネット（IoT）の設計がまさにセキュリティの維持を期待されるコードによって攻撃に曝されることがあります。ハッカーは、ファームウェアを侵害されたコードで置き換えることによって、一見安全な設計であっても攻撃することがよくあります。セキュアブートの方法はこのような攻撃を緩和できますが、適切に実装することが困難な場合があります。

開発者には、IoTデバイスのセキュリティ確保のための総合的な戦略の一環として、セキュアブートの簡単な実装方法が必要です。

この記事では、IoTデバイスの設計における一般的な攻撃対象領域と、セキュアキーストレージ、暗号化、認証などの基本的なセキュリティ方法の役割の概要を説明します。その後、IoTデバイスのセキュリティを確保するための総合的な戦略において必要なさまざま機能の中でも、開発者がセキュアブートを追加できるセキュリティチップを紹介します。

IoTデバイスの脆弱性

IoTデバイスには、デバイス自体、ネットワーク、最終的にはアプリケーションの侵害にハッカーが利用する多数のエントリポイントが存在する可能性があります。開発者はさまざまな手法を使用してネットワークとアプリケーションのセキュリティを強化できますが、デバイスで使用できるメモリと処理リソースが限られるため、IoTデバイスのセキュリティには課題が残っています。

開発者は暗号化方法を使用してデータを保護していますが、多くのデバイスは、ハッカーが承認サーバ、ゲートウェイ、他のIoTデバイスのふりをして通信をインターセプトするのを防ぐために必要な、安全な認証機能を備えずに設計されています。場合によっては、有効ではあっても弱い認証方法を使用するデバイスが、有効なセキュリティキーをインターセプトして一見するとプライベートな通信セッションで再利用する高度な悪用に対して脆弱なままになることがあります。

IoTデバイスの更新

さらに基本的なセキュリティの弱点は、急速に増加するIoTデバイスに組み込まれている無線（OTA）更新機能の使用に関係します。OTA更新では、急速に変化するIoT市場において重要な機能が提供されます。開発者は、新機能（またはバグ修正）に対する顧客の変化する需要に、展開されているデバイスのファームウェアをアップグレードすることによって対応できます。標準的なOTA更新プロセスでは、IoTデバイスは定期的に更新を検索し、使用可能になったら新しいコードをダウンロードし、一連のシステム呼び出しを実行して更新プロセスを完了します。

たとえば、Microchip TechnologyのSAM D21 MCUベースのIoTデバイスの場合、デバイスのファームウェアには、いくつかの事前設定されたエンドポイントからイメージをダウンロードし、成功したことをチェックして、新しいファームウェアセットに切り替える、OTA更新コードが含まれます（リスト1）。MicrochipのAdvanced Software Frameworkパッケージからのこのリストでは、OTAファームウェアの初期化（m2m_ota_init()）の後、コールバックルーチンOtaUpdateCb()はOTAファームウェアが新しいコードイメージをダウンロードした後で新しいファームウェアセット（m2m_ota_switch_firmware()）に切り替え、システムのリセットによってMCUは更新されたファームウェアで再起動します。

コピーする

static void OtaUpdateCb(uint8 u8OtaUpdateStatusType ,uint8 u8OtaUpdateStatus)

{

if(u8OtaUpdateStatusType == DL_STATUS) {

if(u8OtaUpdateStatus == OTA_STATUS_SUCSESS) {

// アップグレードされたファームウェアに切り替える

m2m_ota_switch_firmware();

}

}

else if(u8OtaUpdateStatusType == SW_STATUS) {

if(u8OtaUpdateStatus == OTA_STATUS_SUCSESS) {

M2M_INFO("Now OTA successfully done");

// ホストSWのアップグレードを開始した後、システムのリセットが必要である（ドライバの再初期化）

}

}

}

 

void wifi_event_cb(uint8 u8WiFiEvent, void * pvMsg)

{

case M2M_WIFI_REQ_DHCP_CONF:

{

// 正常に接続した後、無線アップグレードを開始する

m2m_ota_start_update(OTA_URL);

}

break;

default:

break;

}

 

int main (void)

{

tstrWifiInitParam param;

tstr1xAuthCredentials gstrCred1x    = AUTH_CREDENTIALS;

nm_bsp_init();

   

m2m_memset((uint8*)&param, 0, sizeof(param));

param.pfAppWifiCb = wifi_event_cb;

   

// WINCドライバを初期化する

ret = m2m_wifi_init(&param);

if (M2M_SUCCESS != ret)

{

M2M_ERR("Driver Init Failed <%d>\n",ret);

while(1);

}

// OTAモジュールを初期化する

m2m_ota_init(OtaUpdateCb,NULL);

// OTAサーバーへの接続を提供するAPに接続する

m2m_wifi_default_connect();

 

while(1)

{

       

// アプリの状態マシンとWINCイベントハンドラを処理する

while(m2m_wifi_handle_events(NULL) != M2M_SUCCESS) {

           

}

       

}

}

リスト1：MicrochipのAdvanced Software Frameworkパッケージからのこの無線（OTA）コードサンプルでは、Wi-Fiイベントハンドラコールバックwifi_event_cb()は指定されたURLを使用してOTA更新m2m_ota_start_update(OTA_URL)を開始し、OtaUpdateCb()が正常に完了したら新しいファームウェアm2m_ota_switch_firmware()に切り替えます。（コード提供元：Microchip Technology）

ダウンロードされたコードが有効であることを確認するため、開発者は長い間、認定された認証局によって発行されたコード署名証明書に頼ってきました。そうではあっても、セキュアデータストレージ、検証手法の実装、証明書の保護における弱点があるため、ハッカーは複数の方法でIoTデバイスを乗っ取ることができます。

従来のセキュリティ手法であっても、デバイスの独自のファームウェア更新プロセスが、騙されて有効なコードを侵害されたコードに置き換える可能性があります。再起動時には、デバイスは、ハッカーがIoTネットワーク、IoTアプリケーション、さらには企業の内部リソースにまで深く侵入するために使用できるツールになります。

このシナリオでは、IoTデバイスを安全に起動する機能が、重要な防御ラインになります。ただし、開発者にとっては、セキュアブートを実装する場合は、安全なストレージ、暗号化、認証、コード検証のメカニズムに関して複数の要件があります。

セキュアブートをソフトウェアに実装すると、デバイスのストレージからセキュアキーを取得し、暗号化されたデータをインターセプトし、認証メカニズムになりすまして、コード検証アルゴリズムを侵害することに着目した攻撃方法に、更新プロセスが曝されます。実際、IoTの設計には、通常、あらゆるイベントにおけるソフトウェアソリューションに必要な余分なメモリと処理能力が欠けています。だからといって、ハードウェアによる実装が常にセキュリティを保証できるということではありません。

最近まで、IoTデバイスのハードウェアにセキュアブートを実装するには、設計の複雑さとコストが大幅に上昇する多数の特別なデバイスが必要でした。このような独立したデバイスを統合したとしても、断固とした決心のハッカーなら、ターゲットのIoTデバイスのサンプルを簡単に手に入れて、バスや信号の相互接続を介して個別のセキュリティデバイスを攻撃できます。一方、Microchip TechnologyのATECC608Aは単一チップのソリューションであり、開発者は基になっている秘密やセキュリティメカニズムを脅威に曝すことなくセキュアブートを追加できます。

セキュリティIC

ATECC608Aは8ピンのセキュリティデバイスであり、シンプルなシリアルインターフェースによって高度な補完セキュリティ機能を備えたホストMCUをサポートするように設計されています。（図1）。

図1：ATECC608Aは、安全なハードウェアベースのキーストレージを備えた8ピンの暗号化コプロセッサです。（画像提供：Microchip Technology）

このデバイスは、統合された暗号アクセラレータとオンチップの安全なストレージを組み合わせて、SHA-256やAES-128などのさまざまな暗号化アルゴリズムと、楕円曲線デジタル署名（ECDSA）、楕円曲線Diffie-Hellman（ECDH）、NIST曲線P-256などの堅牢な楕円曲線アルゴリズムをサポートする、完全なハードウェアベースのセキュリティソリューションを提供します。これらの暗号メカニズムに加えて、このデバイスはさらに高いレベルのトランスポートレイヤセキュリティ（TLS）プロトコル（TLS 1.3など）をサポートします。初期のデバイスとは異なり、ATECC608Aはセッションキーを生成して安全に格納できるので、TLS認証の使用に関して見つかった脅威の一般的な発生元を軽減するのに役立ちます。

これらの機能はIoTデバイスの通常動作の保護において基本的な役割を果たしますが、ATECC608Aによるセキュアブートのサポートはセキュリティの範囲を基盤のファームウェア更新プロセスにまで拡張します。その場合、ATECC608Aは新しいコードセットを検証し、成功または失敗を示すメッセージをMCUに返します。その時点で、既存のセキュリティポリシーに応じて、MCUは、更新の再試行、セキュリティ監視エンドポイントへの警告メッセージの送信、停止、または更新を無視して元のコードでの再起動を行うことができます。

ハードウェアの統合

開発者にとっては、ATECC608Aでセキュアブートと他のセキュリティ機能をMCUベースの設計に追加するために新たに加わる要件は比較的少数です。ハードウェア側では、設計者は最大で4つの接続（V_CC、GND、シリアルクロック入力（SCL）、シリアルデータ（SDA））を処理する必要があります。残りの4つのピンは接続されていません。V_CCを2.0Vから5.5Vの電源に接続することを除けば、残っている決定事項はMCUへのシリアル接続だけです。

設計者は、従来のI²C接続のために、デバイスのSCLおよびSDAピンをMCUに接続できます。あるいは、設計者はMicrochipの1線インターフェースのデバイスのサポートを利用することもできます。その場合、開発者はデバイスのSDAポートをMCU GPIOピンに接続し、Microchipの1線タイミングプロトコルを使用して論理0と1の値を伝送します（図2）。

図2：Microchipの1線シリアルプロトコルでは、指定された期間の波形遷移のシーケンスが論理0または論理1を通知します。（画像提供：Microchip Technology）

このプロトコルでは、ATECC608AとMCUの間の論理値の伝送は、指定された期間の開始パルス（t_START）で開始します。開始パルスの後、プロトコルでは、論理0は、ゼロ伝送高パルス（t_ZHI）とそれに続くゼロ伝送低パルス（t_ZLO）に指定された期間のサイクルと定義されます。同様に、高レベルが維持されると論理1の伝送を示します。

いずれの場合も、プロトコルは指定されたビット時間（t_BIT）内にシグナルは低になるものと予想します。一連のビット伝送の後、指定されたIOタイムアウト期間の後にシリアル回線が非アクティブになった場合は自動的にスリープモードになるように、デバイスをプログラミングできます。ただし、ATECC608Aを使用する場合、開発者自身がこのプロトコルのタイミングの詳細について考慮する必要はほとんどありません。Microchipによって、230.4Kbaudで作動する標準のUARTに適合するように重要なタイミングパラメータは定義されています。

デバイス構成

ATECC608Aでは、デバイスレベルで必要な構成の設定は最小限です。I²Cまたは1線シリアルインターフェースを使用すると、開発者はI²Cアドレスなどの設定をロードしたり、ウェークアップまたは電源投入時の自己テストなどの機能を設定したりできます。デバイスでは、超低電力IoT設計に特に関連する構成設定が提供されています。

これらの設計のATECC608Aでは、おそらく標準的なIoT設計において最も一般的であるアイドルまたはスリープモードにおける全体的なパワーバジェットの増加は比較的小さいものです。アイドルモードでは、デバイスは約800マイクロアンペア（μA）を消費し、スリープモードでの消費電力は構成に応じて150ナノアンペア（nA）以下です。MCUがデバイスを起動して何らかのセキュリティ処理を実行しても、デバイスの消費電力はアクティブな動作の間にわずか14ミリアンペア（mA）に達するだけです。それでも、非常に厳しいパワーバジェットではさらに低いアクティブ電力レベルが必要な場合があります。

そのような設計をサポートするため、このデバイスの構成オプションでは、開発者は電力消費量を少なくする代わりに実行速度が遅くなる3つの異なる動作モードを選択できます。したがって、開発者は、最大実行速度での14mAから、実行速度の低下に応じて6mAまたは3mAにアクティブな電力消費を下げることができます。

さまざまな低レベル構成項目とは別に、ATECC608Aなどのセキュリティデバイスでは、開発前に安全な情報がすでに適切に配置されていると、いっそう効率的になります。開発中に実行されるセキュアキーや証明書に誤りや侵害があると、セキュリティのための最善の努力も無駄になる可能性があります。このような脅威の可能性に対処するため、Microchipの信頼できるプロビジョニングサービスでは、製造プロセスの一部としてキーや証明書を含むセキュアデータがロードされます。

工場での安全な環境下でロードされた安全な情報は、その後、デバイスがサプライチェーンの通常の処理プロセスを経る間も、不注意または意図的な検出から保護された状態を保ちます。ATECC608Aには特別な輸送ロック機能が含まれ、最終的なホストMCUから送信された既知のキーを使用して暗号的に有効にされるまで、デバイスを使用することはできません。

ホストMCUによって有効にされたATECC608Aは、MCUと共有されるIO保護キーと呼ばれるシークレットキーをランダムに生成します。それ以降に行われるATECC608AとMCUの間の通信は、このIO保護キーを使用して暗号化されます。これは、セキュアブートおよび他のセキュアプロセスの間に追加認証を提供するメカニズムです。

ハッカーがATECC608Aへの接続を断って独自の「成功」信号をMCUにフィードすることによって検証プロセスになりすまそうとした場合、このIO保護キーメカニズムによって偽の信号は無視されます。ハッカーが何とかしてATECC608Aデバイスを侵害して異なるシステムで使用しようとしても、IO保護キーメカニズムによってそのような使用は効果的に防止されます。

ソフトウェアの統合

このような高度な機能と保護メカニズムを備えていても、ATECC608AをMCUベースの設計に適用するのは簡単なままです。これまでに説明した簡単なハードウェアインターフェースと構成設定の実装とは別に、開発者はセキュリティ動作の細部を抽象化するアプリケーションプログラミングインターフェース（API）を使用します。MicrochipのCryptoAuthLib暗号認証ライブラリでは、ATECC608Aの機能を活用するために必要な定義、構造体、API呼び出しを含む包括的なソフトウェアパッケージが提供されます。このライブラリはハードウェアに依存しないレイヤとして機能し、ハードウェア抽象化レイヤ（HAL）APIおよび特定のハードウェアターゲット用のドライバによって動作します（図3）。

図3：MicrochipのCryptoAuthLibライブラリは、アプリケーションと、ハードウェア固有のドライバ上のハードウェア抽象化レイヤを通してアクセスされる基盤ハードウェアの間に、暗号サービスレイヤを提供し、異なるハードウェアセット間の移植性を実現します。（画像提供：Microchip Technology）

開発者は、io_protection_set_key()などのCryptoAuthLib APIルーチンを使用してIO保護キーを作成し、atcab_secureboot()を使用して、呼び出しパラメータに含まれるコードダイジェストまたは署名に対してATECC608Aのセキュアブート検証メカニズムを実行します。

APIコマンドは簡単ですが、セキュリティを実装するために必要な具体的なセットアップ、管理、運用の手順は難しい場合があります。開発者が実装しようとしているセキュリティメカニズムであっても、重要な手順が漏れたり不適切な順序で実行されたりすると、遅延の原因になる可能性があります。

MicrochipのSAM D21 MCUベースのATSAMD21-XPRO開発キットおよびそのATECC608Aを備えたATCRYPTOAUTH-XPRO-Bアドオンボードを使用すると、開発者は、これらの一般的なメカニズムやATECC608Aの特定の機能に関する作業を短時間で経験できます。Microchipでは、ATSAMD21-XPROおよびATCRYPTOAUTH-XPRO-B上で実行するように設計された広範なセキュアブートソフトウェアパッケージが提供されており、MicrochipのATOLED1-XPROを使用してサンプルアプリケーション用の基本的なディスプレイインターフェースが提供されます（図4）。

図4：開発者は、MicrochipのソフトウェアおよびSAM D21 MCUベースのATSAMD21-XPRO開発キットを、ATECC608A装備のATCRYPTOAUTH-XPRO-BアドオンおよびATOLED1-XPROディスプレイアドオンと組み合わせて使用し、セキュアブートプロセスをすばやく評価できます。（画像提供：Microchip Technology）

SAM D21デモパッケージに含まれる完全なセキュアブートルーチンでは、セキュアブート動作のセットアップ、実行、および状態チェックに使用される重要なソフトウェア設計パターンが示されています（リスト2）。このハードウェアプラットフォームとデモソフトウェアパッケージを使用して、開発者は、リモートブートに対するATECC608Aの使用をすばやく評価し、必要に応じてサンプルソフトウェアを変更して独自の要件を満たすことができます。

コピーする

/** \brief 初期化、実行、初期化解除によって、セキュアブートの

*         機能を処理する。

*  \return 成功の場合はATCA_SUCCESS、それ以外の場合はエラーコード。

*/

ATCA_STATUS secure_boot_process(void)

{

ATCA_STATUS status;

secure_boot_parameters secure_boot_params;

uint8_t secure_boot_mode;

bool secure_boot_app_valid = false;

 

/* セキュアブートを初期化する */

if ((status = secure_boot_init(&secure_boot_params)) != ATCA_SUCCESS)

{

return status;

}

 

do

{

.

.

.

#if SECURE_BOOT_DIGEST_ENCRYPT_ENABLED

.

.

.

/* IO保護キーを取得する */

if ((status = io_protection_get_key(secure_boot_params.io_protection_key)) != ATCA_SUCCESS)

{

return status;

}

 

        if ((status = atcab_secureboot_mac(secure_boot_mode,

                                           (const uint8_t*)&secure_boot_params.app_digest,

                                           (const uint8_t*)&secure_boot_params.memory_params.signature,

                                           (const uint8_t*)secure_boot_params.randomnum,

                                           (const uint8_t*)secure_boot_params.io_protection_key,

                                           &secure_boot_app_valid)) != ATCA_SUCCESS)

        {

            break;

        }

        #else

        if ((status = atcab_secureboot(secure_boot_mode,

                                       0,

                                       (const uint8_t*)&secure_boot_params.app_digest,

                                       (const uint8_t*)&secure_boot_params.memory_params.signature,

                                       NULL)) != ATCA_SUCCESS)

        {

            break;

        }

        secure_boot_app_valid = true;

        #endif

 

        /* セキュアブートコマンドが正しいリターンMACで正常に実行されたかどうかをチェックする  */

        if (!secure_boot_app_valid)

        {

            break;

        }

        .

        .

        .

   }

    while (0);

 

    /* メモリインターフェースを初期化解除し、リソースを解放する */

    secure_boot_deinit_memory(&secure_boot_params.memory_params);

 

    return status;

}

リスト2：MicrochipのSAM D21デモパッケージからのこのスニペットでは、IO保護キーのチェック（io_protection_get_key()）や、ダイジェスト、署名、他のパラメータを使用したファームウェアの検証（選択されている構成に応じてatcab_secureboot_mac()またはatcab_secureboot()）など、セキュアブートの重要な設計パターンが示されています。（コード提供元：Microchip Technology）

まとめ

IoTデバイスには、侵害されたデバイスをIoTのネットワーク、アプリケーション、エンタープライズリソースへのエントリとして使用しようとするハッカーに対する複数の脅威対象領域があります。緩和手法の中で、セキュアブートは広範なセキュリティ戦略における不可欠な要素として発展しています。しかし、セキュアブートの実装には、適切に処理されないとシステムを脅威に曝す可能性がある独自の要件セットがあります。

Microchip TechnologyのATECC608AセキュリティICでは、単一のパッケージで包括的なソリューションが提供され、開発者は任意のMCUベース設計に簡単に追加できます。ATECC608Aを使用すると、開発者はセキュリティを劇的に強化し、IoT設計にセキュアブートを組み込むことができます。