IoTデバイスをクラウドに安全に接続するための、より簡単なソリューション

著者 Stephen Evanczuk

Digi-Keyの北米担当編集者 の提供

セキュリティの必要性に対する意識が高まっています。にもかかわらず、IoTデバイスをクラウドに接続するのに、開発者はあまりにもしばしば、セキュリティの近道をしてしまいます。多くの場合、目的に叶うセキュリティメカニズムの複雑さ、小さなバッテリ駆動のIoTデバイスでは利用できるメモリや処理リソースが限られていること、そして製品の出荷を迫られること、これらの問題の葛藤を克服できないように思われます。

Microchip TechnologyとGoogleは、このような問題に対処し、IoTデバイスでのセキュリティ機能の実装を簡素化するために、Microchipのハードウェア的なセキュア機能と、JWT(JSON Web Token)と呼ばれる単純なデータ構造を組み合わせるアプローチを生み出しました。これによって、IoTデバイスとGoogle Cloud IoT Coreサービス間の相互認証を保証するための簡単な方法が得られます。

この記事では、IoTデバイスのセキュリティ上の脅威について説明し、その脅威に対抗するために現在使用されているデバイスを紹介します。それによってセキュリティの隙間が特定され、開発者および組み込みシステム設計者が、その隙間を埋めるためにJWTをどのように使用できるかがわかるでしょう。

IoTデバイスのセキュリティの脆弱性

IoTデバイスへの攻撃はさまざまな形をとる可能性があり、大規模なIoT配置に限定されるわけではありません。非常に小さなIoTネットワークであっても、分散サービス妨害(DDoS)攻撃などを目的としたボットネット(操り人形化したコンピュータ群)に、多数の個々のデバイスリソースを取り込もうとしているハッカーにとっては格好のターゲットになります。結果として、あらゆるクラスのIoTデバイス設計者は、攻撃を阻止できる堅牢なハードウェアベースのセキュリティメカニズムで、システムを保護する必要に迫られるのは避けられません。

たとえば、暗号化と認証に使用する秘密鍵を保存するためにシステムメモリやフラッシュメモリを使用すると、IoTデバイスが脆弱になります。さらに悪いことに、ハッカーが秘密鍵を盗み取れば、それを使ってIoTネットワークや付随する企業リソースにアクセスすることができます。

セキュリティIC

Microchip TechnologyのCryptoMemory ICやCryptoAuthentication ICなどの特殊なセキュリティデバイスは、秘密鍵やその他の秘密データを保護するためのハードウェアベースのメカニズムを備えています。これらのデバイスに統合されたEEPROMアレイは、デバイスのSPIまたはI2Cシリアルインターフェース経由でアクセスされる、暗号の機密性が確保されたメカニズムを介してのみ到達可能なセキュアなストレージを提供します(図1)。結果としてこれらのデバイスは、セキュアなストレージやその他のセキュリティ機能をあらゆるIoTデバイス設計に追加するための簡単な方法を提供してくれます。

Microchip TechnologyのAT88SC0204C CryptoMemory ICの図

図1:AT88SC0204C CryptoMemory ICなどのMicrochip Technologyのハードウェアセキュリティデバイスは、内蔵の暗号化メカニズムを使用してオンチップEEPROMへのアクセスを保護し、データの機密性が確保されたストレージを提供します。(画像提供:Microchip Technology)

ATECC608AなどのMicrochipのCryptoAuthenticationファミリの製品は、安全な設計に広く使用される暗号化アルゴリズムをサポートすることで、セキュアストレージの基盤を強化します。このデバイスは、ハードウェア機能の中でも、以下を含む複数のアルゴリズムのハードウェアアクセラレーションを特長としています。

  • 非対称暗号化アルゴリズム
    • FIPS186-3 楕円曲線デジタル署名アルゴリズム(ECDSA)
    • FIPS SP800-56A 楕円曲線ディフィー・ヘルマン鍵共有(ECDH)
    • NIST規格P256 楕円曲線暗号(ECC)
  • 対称暗号化アルゴリズム
    • SHA-256ハッシュ暗号
    • ハッシュベースのメッセージ認証符号(HMAC)暗号化
    • AES-128暗号化
    • AES-GCM(ガロア体乗算)暗号化
  • 鍵導出関数(KDF)
    • 擬似ランダム関数(PRF)KDF
    • HMACベースの抽出/展開KDF(HKDF)

暗号化機能のこのセットは、暗号専門家にとり、認証と安全なデータ交換のための、高レベルのセキュリティプロトコルをサポートするのに必要なメカニズムがすべて含まれています。たとえば、KDF機能は、データ交換セッションの開始前に参加者認証のため、TLS(トランスポート層セキュリティ)プロトコルに必要な基本メカニズムを提供します。

このプロトコルでは、TLSセッションは、セキュアセッションの開始要求をクライアント側からサーバに送信することから始まります。サーバはデジタル証明書で応答し、クライアントはこの証明書を使用してサーバの身元を確認します。このようにしてクライアントがサーバを認証した後、セッションセットアップは、サーバの公開鍵を使用してクライアントがセッション秘密鍵を生成するようにし、PRF KDFまたはより堅牢なHDKFを使用して作成されたランダム値を暗号化します。

TLS認証プロトコルは、インターネットセキュリティの基本です。認証局(CA)と呼ばれる証明書プロバイダ業界全体が、セキュア通信のこの非常に重要な要素をサポートするために進化しました。企業はCAから信頼できる証明書を取得し、上記の標準的なTLSサーバ認証プロトコルをサポートするために、これを自社サーバにインストールします。

IoTアプリケーションの場合、ネットワークが企業のリソースと広くかつ深く接続しており、この種の一方向認証では十分な保護は保証されません。たとえば、不正な証明書を持つハッカーたちは、より大がかりな攻撃の一環として、自分自身をIoTデバイスにとって正当なサーバであると装う可能性があります。

TLSを使用してクライアント認証を実装するために必要な証明書、キー、およびソフトウェアは、多くのIoTデバイスの能力を超える可能性があるので、リスクを冒しつつ、IoT開発者はTLS相互認証プロトコルの実装に苦労しています。Microchip TechnologyとGoogleでは共同で、ATECC608Aの機能とJSON Web Token(JWT)と呼ばれる単純なデータ構造を組み合わせた代替アプローチを開発しました。これによって、IoTデバイスとGoogle Cloud IoT Coreサービス間の相互認証を保証するための簡単な方法が得られます。

JWTベースの認証

RFC 7519で規定されているJWTは、JWTを準備および送信するエンティティに関する「クレーム」と呼ばれる業界標準の情報コンテナです。JWT構造自体は、3つのセクションから構成されます。

  • JSON名を含むヘッダ。トークンの署名に使用される暗号化アルゴリズムの名前("alg")と、トークンのタイプ("typ")の値のペア(たとえば、NIST P-256曲線を使用するECDSAのアルゴリズム名は"EC256"、トークンのタイプはここでは"JWT")
  • JSON名を含むペイロード。これは、各クレームの値のペア
  • 署名。ヘッダで指定されたアルゴリズムを使用して、暗号化前にそれぞれ別々にbase64 URLエンコード表現に変換されたヘッダとクレームのセットとともに秘密鍵をエンコードします

RFC 7519は、ペイロードや他のセクションでクレームを指定するための、非常に高い柔軟性を提供します。この規格では、署名や暗号化なしで作成された安全対策を持たないJWTも許可されています。その場合、ヘッダにはアルゴリズム名と値のペアが、{"alg":"none"}と記述されます。Google Cloud IoT Coreサービスで使用されるJWTの場合、Googleは署名セクションと、次の3つの必須クレームを含むペイロードを要求します。

  • "iat" - 発行日時(issued at)のことで、トークンがISO 8601 UTCタイムスタンプ形式で作成された時刻(1970-01-01T00:00:00Zからの秒数)を指します(たとえば、2019年6月30日12:00:00 PM GMTの場合は1561896000)
  • "exp" – 異なるクライアントとサーバ間のシステムクロックのずれを考慮して、"iat"値から最大24時間の経過とそれに10分の猶予期間を足したトークンの有効期限を指定するUTCタイムスタンプ(たとえば、2019年7月1日12:00:00 PM GMTの場合は1561982400)
  • "aud" - 開発者のGoogle CloudプロジェクトIDを含む文字列

GoogleのIoTデバイス認証スキームは、TLSに基づいた通常のサーバ認証と、これらの比較的単純なクレームで作成されたJWTを使用したIoTデバイス認証を組み合わせたものです。新しいセッションを開始するために、IoTデバイスはサーバへのセキュアソケットを開き、前述と同じTLSプロトコルを使用してサーバを認証します。

このプロセスの次のステップは、IoTネットワークのトランザクション用のGoogle IoTクラウドの負荷の軽いMQTT(メッセージキューイングテレメトリトランスポート)プロトコルの使用に依存しています。認証されたサーバへのセキュアソケットを使用して、IoTデバイスはその固有のJWTをログインパスワードとして使用し、そのサーバのMQTTホストサービスに「ログイン」します(リスト1)。

コピー
/* Populate the buffer with the username */
int config_get_client_username(char* buf, size_t buflen)
{
    if(buf && buflen)
    {
        int rv = snprintf(buf, buflen, "unused");
 
        if(0 < rv && rv < buflen)
        {
            buf[rv] = 0;
            return 0;
        }
    }
    return -1;
}
 
/* Populate the buffer with the user's password */
int config_get_client_password(char* buf, size_t buflen)
{
    int rv = -1;
 
    if(buf && buflen)
    {
        atca_jwt_t jwt;
        
        uint32_t ts = time_utils_get_utc();
 
        rv = atcab_init(&cfg_ateccx08a_i2c_default);
        if(ATCA_SUCCESS != rv)
        {
            return rv;
        }
 
        /* Build the JWT */
        rv = atca_jwt_init(&jwt, buf, buflen);
        if(ATCA_SUCCESS != rv)
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "iat", ts)))
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "exp", ts + 86400)))
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_string(&jwt, "aud", config_gcp_project_id)))
        {
            return rv;
        }
 
        rv = atca_jwt_finalize(&jwt, 0);
 
        atcab_release();
    }
    return rv;
}

リスト1:Google Cloud PlatformのIoT Core用のMicrochip Technologyのソフトウェアのサンプルリポジトリに格納されているモジュールは、MQTTホストでのクライアント認証用のパスワードとして使用する、ダミーのユーザー名とJWTオブジェクトを生成するためのルーチンを提供します。(コード提供:Microchip Technology)

IoTデバイスはこのログインシーケンスの一部としてユーザー名を送信しますが、ユーザー名は認証には使用されません。その結果、ダミーのユーザー名が送信されます(リスト2)。代わりに、IoTデバイスの認証は、ログインパスワードとして送信されたJWTに基づいて行われます。JWT署名は、ヘッダ、ペイロード、デバイスの秘密鍵の組み合わせなので、Google Cloud IoT Coreサービス側は、JWTが承認されたデバイスで本当に作成されたものであることを確認できます。この検証のために、Google Cloud IoTサービスは、以下に説明するキー管理プロセスを使用して、IoTデバイス開発者がGoogleクラウドに前もって保存しておいたデバイスの公開鍵を使用します。TLSを単独で使用する場合とは対照的に、このアプローチは、IoTデバイスのリソース要件を削減しながら、プロセスを高速化するハイブリッドアプローチによって相互認証を提供します。

コピー
/* Connect the MQTT Client to the host */
static int client_connect(void* pCtx)
{
    MQTTPacket_connectData mqtt_options = MQTTPacket_connectData_initializer;
    struct _g_client_context* ctx = (struct _g_client_context*)pCtx;
    size_t buf_bytes_remaining = CLIENT_MQTT_RX_BUF_SIZE;
 
    mqtt_options.keepAliveInterval = MQTT_KEEP_ALIVE_INTERVAL_S;
    mqtt_options.cleansession = 1;
 
    /* Client ID String */
    mqtt_options.clientID.cstring = (char*)&ctx->mqtt_rx_buf[0];
    if(config_get_client_id(mqtt_options.clientID.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    /* Username String */
    mqtt_options.username.cstring = mqtt_options.clientID.cstring + strlen(mqtt_options.clientID.cstring) + 1;
    buf_bytes_remaining -= (mqtt_options.username.cstring - mqtt_options.clientID.cstring);
    if(config_get_client_username(mqtt_options.username.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    /* Password String */
    mqtt_options.password.cstring = mqtt_options.username.cstring + strlen(mqtt_options.username.cstring) + 1;
    buf_bytes_remaining -= (mqtt_options.password.cstring - mqtt_options.username.cstring);
    if(config_get_client_password(mqtt_options.password.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    return MQTTConnect(&ctx->mqtt_client, &mqtt_options);
}

リスト2:Microchip社のソフトウェアサンプルリポジトリで提供されるこの機能は、初期接続フェーズ時に、IoTデバイスをMQTTサーバに対して認証するためのパスワードとしてのJWTオブジェクトの使用方法を示しています。(コード提供:Microchip Technology)

非常に重要な成功要因

ATECC608Aとそのサプライチェーンの機能は、このアプローチにとって非常に重要な成功要因です。どのMCUでも、JWTヘッダとペイロードから暗号符号化された署名を最終的に生成できますが、ソフトウェアのみで実行されるアプローチは、ハードウェアベースのセキュアキー付きストレージなしでは依然として脆弱です。さらに、「ソフトウェアのみ」で実施される場合のプロセッサの負荷と実行遅延は、シビアな応答時間要件を持ち、リソース制限のある多くのIoTデバイスやアプリケーションにとっては、非常に厳しいものになる可能性があります。最後に、セキュリティアルゴリズムや高レベルのプロトコルに関して豊富な経験のない開発者には、必要なソフトウェア機能の実装は難しい仕事になるかもしれません。Microchipは、これらの問題にCryptoAuthLibライブラリで対処しています(図2)。

CryptoAuthLibハードウェア抽象化レイヤ(HAL)の図

図2:CryptoAuthLibは、ハードウェア抽象化レイヤ(HAL)を使用して、API機能とコアプリミティブを下層ハードウェアから分離しているため、開発者はさまざまなサポートデバイスのソフトウェアを対象として扱うことができます。(画像提供:Microchip Technology)

MicrochipのCryptoAuthLibは、Google JWT認証プロトコルなどのセキュアなIoT機能の実装を簡素化し、複雑なセキュリティ操作を、CryptoAuthLib API(アプリケーションプログラミングインターフェース)を介して提供される一連の関数呼び出しに軽減します。おそらくIoT開発者にとって最も重要なことは、MicrochipのCryptoAuthLibコア機能がATECC608AなどのMicrochipの暗号ICを最大限に活用して、設計内のセキュリティ機能の実行を高速化することでしょう。たとえば、リスト1のatca_jwt_finalize()の呼び出しは、リスト2のパスワードとして使用されるJWTを作成するために、ATECC608Aなどの暗号装置を使用します。この場合、ATECC608AはJWT署名の暗号化を高速化し、統合されたセキュアストレージから設計の秘密鍵を読み取り、前述の署名作成プロセスを完了します。

しかしながら、使用するソフトウェアやセキュリティデバイスがいくら洗練されていても、IoTデバイスは、キーと証明書を管理するために従来の方法を使用しているので脆弱なままです。これまでは、製造、配布、さらに配備の際には、秘密鍵を外部で生成してセキュアなストレージにロードする必要がありました。ハードウェアセキュリティモジュールとセキュア施設を使用しても、これらの秘密を「知る必要がある」唯一のデバイスの外部に、その秘密が一時的にでも存在することは、セキュリティ上の弱点を意味し、偶発または故意によって危険にさらされる可能性があります。ATECC608Aの機能を活用することで、MicrochipとGoogleは、この従来的なセキュリティの弱点をほぼ解消しました。

この新しいアプローチでは、MicrochipはATECC608Aの機能を使用して、秘密鍵がデバイスから出ることなく鍵のペアを生成します(図3)。その後で、Microchipでは、同社のセキュアな施設のセキュアサーバに保存されている、顧客から提供された中間証明書を使用して、デバイスが生成した公開鍵に署名します。そして最後に、Microchipは、Google Cloud IoT Device Managerに登録された顧客のアカウントに安全に公開鍵を送信します。このデバイスマネージャには、各デバイスごとに最大3つの公開鍵を保存することができ、それで鍵のローテーションポリシーをサポートすることができます。これが配備されると、IoTデバイスはATECC608Aのセキュリティ機能を使用して、前述の相互認証プロセスで使用されるJWTを作成できるようになります。

Microchip TechnologyとGoogle Cloud IoTサービス相関図(クリックして拡大)

図3:Microchip TechnologyとGoogle CloudのIoTサービスを組み合わせることで、秘密鍵と証明書のプロビジョニングが簡単になり、IoTアプリケーションのセキュリティを強化するように設計された保護メカニズムが提供されます。(画像提供:Google)

MicrochipとGoogleのこのコラボレーションにより、開発者にとっては、この非常に重要なキー管理プロセスの負担が大きく軽減されます。それでもカスタム要件の場合、開発者はCryptoAuthLib API関数atcab_genkey()を使用して、独自のキー管理プロセスを実装することができます。これを使用すると、ATECC608Aは鍵のペアを生成し、秘密鍵をセキュアなストレージに格納し、これに関連付けられた公開鍵を返します。

キー生成やその他のATECC608Aセキュリティ機能を詳しく調べるには、MicrochipのSAM D21 Xplained Pro評価キットを中心に構築された包括的な開発環境をセットアップするのが、開発者にとって手っ取り早い方法です。MicrochipのATSAMD21J18A 32ビットArm® Cortex®-M0 + MCUをベースにしたSAM D21 Xplained Proキットは、MicrochipのAdvanced Software Framework(ASF)ドライバおよびコードモジュールでサポートされている完全なハードウェアプラットフォームを提供します。

ATECC608Aを含むCryptoAuthenticationデバイスを評価するには、開発者は、Xplained Proボードの2つの拡張ヘッダの1つにCryptoAuth XPRO-Bのアドオンボードを接続すればよいだけです。Microchipでは、ATECC608Aを使用して、CryptoAuthLibのセキュリティ機能を評価するためのサンプルソフトウェアを提供しています。さらに進めると、MicrochipのATWINC1500-XPRO Wi-Fiアドオンボードをもう一方のヘッダに接続すると、TLSサーバ認証とJWTデバイス認証の両方を含め、この記事で説明した相互認証フローを実証するMicrochipのサンプルソフトウェアを実行できます。

結論

IoTアプリケーションのセキュリティには複数の要件がありますが、IoTデバイスとクラウドリソースの相互認証を実装することが非常に重要な課題となります。リソースが限られたIoTシステムでは、従来のプロトコルは利用可能なメモリと処理リソースを超える場合があります。Microchip TechnologyのCryptoAuthLibライブラリとATECC608A CryptoAuthentication ICを使用すると、開発者は、IoTデバイスをGoogle Cloud IoTサービスに安全に接続するための、JSON Web Tokenに基づいたより効率的なアプローチを実装できます。

免責条項:このウェブサイト上で、さまざまな著者および/またはフォーラム参加者によって表明された意見、信念や視点は、Digi-Key Electronicsの意見、信念および視点またはDigi-Key Electronicsの公式な方針を必ずしも反映するものではありません。

著者について

Stephen Evanczuk

Stephen Evanczuk氏は、IoTを含むハードウェア、ソフトウェア、システム、アプリケーションなど幅広いトピックについて、20年以上にわたってエレクトロニクス業界および電子業界に関する記事を書いたり経験を積んできました。彼はニューロンネットワークで神経科学のPh.Dを受け、大規模に分散された安全システムとアルゴリズム加速法に関して航空宇宙産業に従事しました。現在、彼は技術や工学に関する記事を書いていないときに、認知と推薦システムへの深い学びの応用に取り組んでいます。

出版者について

Digi-Keyの北米担当編集者