IoTデバイスをクラウドに接続する安全なソリューション

　　人々がセキュリティの必要性をますます認識している一方で、開発者はしばしばIoTデバイスをクラウドに接続する近道を取っています。 多くの場合、適切な安全機構の複雑さ、マイクロバッテリー駆動のIoTデバイスに限られたメモリや処理資源、そして製品の輸送需要との葛藤は克服しがたいものに思えます。

　　これらの問題に対処し、IoTデバイスにおけるセキュリティ機能の実装を簡素化するために、Microchip TechnologyとGoogleは協力し、Microchipの安全なハードウェア機能とJSON Web Token(JWT)と呼ばれるシンプルなデータ構造を組み合わせた手法を開発しました。 その結果、IoTデバイスとGoogle Cloud IoTコアサービス間の相互認証を簡素化する方法が実現しました。

　　この記事では、IoTデバイスに対するセキュリティ上の脅威を紹介し、現在これらの脅威に対処するために使われているデバイスを紹介します。 セキュリティの脆弱性を特定し、開発者や組み込みシステム設計者がJWTを使ってそれらを停止する方法を明らかにします。

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

　　IoTデバイスへの攻撃は多様な形態をとることができ、大規模なIoT導入に限られるものではありません。 分散型サービス拒否(DDoS)攻撃に使われるボットネットで多数の個別デバイスのリソースを悪用しようとするハッカーにとっては、最小規模なIoTでも魅力的な標的となります。 したがって、あらゆる種類のIoTデバイスの設計者は、攻撃を防ぐために堅牢なハードウェアベースのセキュリティメカニズムでシステムを保護する必要があります。

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

　　安全IC

　　Microchip TechnologyのCryptoMemoryやCryptoAuthentication ICのような専用セキュリティデバイスは、秘密鍵やその他の秘密データを保護するメカニズムに基づくハードウェア機能を備えています。 EEPROMアレイはこれらのデバイスに統合されており、デバイスのSPIまたはI2Cシリアルインターフェースを通じてのみアクセス可能な安全なストレージおよび暗号化セキュリティ機構を提供します(図1参照)。 したがって、これらのデバイスは、あらゆるIoTデバイス設計に安全なストレージやその他のセキュリティ機能を簡単に追加できる手段を提供します。

　　図1:Microchip Technologyのハードウェアセキュリティデバイス(AT88SC0204C CryptoMemory ICなど)は、オンチップEEPROMへのアクセスを保護するために統合された暗号化機構を用い、安全なストレージを提供しています。 (画像:マイクロチップ・テクノロジー)

　　Microchip CryptoAuthenticationシリーズのメンバー(ATECC608Aなど)は、安全な保存の基盤を強化し、セキュリティ設計で一般的に用いられる暗号化アルゴリズムをサポートしています。 ハードウェアの特徴としては、以下を含む様々なアルゴリズムのハードウェアアクセラレーション機能が搭載されています。

　　非対称暗号化アルゴリズム:

　　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デバイスの正当なサーバーを装うことがあります。

　　リスクがあるにもかかわらず、IoT開発者はTLS相互認証プロトコルの実装に苦労することが多いです。なぜなら、TLSを用いたクライアント認証に必要な証明書、鍵、ソフトウェアが多くのIoTデバイスの能力を超える可能性があるからです。 マイクロチップ・テクノロジーとGoogleは協力し、ATECC608A機能とJSON Web Token(JWT)と呼ばれるシンプルなデータ構造を組み合わせた代替手法を開発しました。 その結果、IoTデバイスとGoogle Cloud IoTコアサービス間の相互認証を簡素化する方法が実現しました。

　　JWTに基づく認証

　　RFC 7519は、JWTがJWTを準備・送信する主体に関する情報(クレーム)に関する業界標準のコンテナであると明記しています。 JWTの構造自体は3つの部分で構成されています。

　　タイトル、JSON名を含む:暗号アルゴリズム(「alg」)の名前(例:ECDSAの「EC256」はNIST P-256曲線を使用しています)とトークンタイプ(「タイプ」)(これらのトークンの「JWT」)の名前です。

　　ペイロード、各クレームのJSON名を含む値ペア

　　署名:ヘッダーで指定されたアルゴリズムを用いて鍵、ヘッダー、宣言セットを符号化し、それぞれを暗号化前にbase64のURLエンコーディングに変換します

　　RFC 7519は、ペイロードやその他の部品に関する請求の指定において非常に柔軟性があります。 この標準では、署名や暗号化なしで作成された安全でないJWTも許可されており、その場合、ヘッダーにはアルゴリズム名「value pair {{alg":"none"}が含まれます。 Google Cloud IoTコアサービスで使用されるJWTには、署名セクションと3つの必須宣言を含むペイロードが必要です。

　　「iat」 - ISO 8601 UTCタイムスタンプ形式でトークンを作成する際の「発行時間」、1970-01-01T00:00:00Zからの秒数(例:2019年6月30日1561896000 12:00 GMT)

　　「exp」 - トークンの有効期限を指定するUTCタイムスタンプで、「IAT」値より最大24時間に10分の猶予期間を加え、クライアントとサーバー間の異なるシステムクロックバイアスに対応するためのものです(例:2019年7月1日1561982400 GMT 00:00 00:00)

　　「aud」 - 開発者のGoogle CloudプロジェクトIDを含む文字列

　　< p> GoogleのIoTデバイス認証ソリューションは、従来のTLSベースのサーバー認証と、これらの比較的シンプルなIoTデバイス認証宣言で作成されたJWTを組み合わせています。 新しいセッションを開始する際、IoTデバイスはサーバーへのセキュアソケットを開き、前述のTLSプロトコルでサーバーを認証します。

　　このプロセスの次のステップは、IoTネットワーク取引のためにGoogle IoT Cloudの軽量メッセージキューテレメトリー伝送(MQTT)プロトコルに依存しています。 認証済みサーバーへの安全なソケットを使い、IoTデバイスは独自のJWTをログインパスワードとして使い、そのサーバー上のMQTTホストサービス(Inventory 1)に「ログイン」します。

　　IoTデバイスはこのログインシーケンスの一部としてユーザー名を送信しますが、認証にはユーザー名は使用されません。 そのため、仮想ユーザー名(リスティング2)が移管されました。 代わりに、IoTデバイスの認証はログインパスワードとして送信されるJWTに基づいています。 JWT署名はヘッダー、ペイロード、デバイス秘密鍵の組み合わせであるため、Google Cloud IoTコアサービスはJWTが本当に認可デバイスから来ているかを検証できます。 この検証のために、Google Cloud IoT Servicesは、以下に説明する鍵管理プロセスを通じて、IoTデバイス開発者が以前Google Cloudに保存していたデバイスの公開鍵を使用します。 TLS単独と比べて、この方法はハイブリッド方式による相互認証を提供し、IoTデバイスのリソース要件を削減しつつプロセスを高速化します。

　　主要な推進要因

　　ATECC608Aとそのサプライチェーンの機能性がこのアプローチの主要な推進力です。 どのMCUも最終的にはJWTヘッダーやペイロードから暗号化された暗号署名を生成することができますが、ソフトウェアのみの方法はハードウェアベースのセキュリティキーストレージがなければ攻撃に対して脆弱です。 さらに、多くのリソース制約のあるIoTデバイスや、応答時間が厳しいアプリケーションでは、「ソフトウェアのみ」の実装に必要なプロセッサ負荷や実行遅延が禁止されることがあります。 最後に、広範なセキュリティアルゴリズムとより高度なプロトコルの経験がなければ、開発者が必要なソフトウェア機能を実装するのは困難です。 MicrochipはCryptoAuthLibライブラリ(図2)を通じてこれらの問題に対応しています。

　　図2:CryptoAuthLibはハードウェア抽象層(HAL)を使ってAPI関数やコアプリミティブを基盤ハードウェアから分離するため、開発者はさまざまなサポートデバイス向けにソフトウェアを配置できます。 (画像:マイクロチップ・テクノロジー)

　　Microchip CryptoAuthLibは、Google JWT認証プロトコルのような安全なIoT機能の実装を簡素化し、複雑なセキュリティ操作をCryptoAuthLibアプリケーションプログラミングインターフェース(API)を通じて提供される一連の関数呼び出しに還元します。 IoT開発者にとって最も重要なのは、Microchip CryptoAuthLibのコア機能で、ATECC608AなどのMicrochip暗号化ICを完全に活用し、設計上のセキュリティ機能の実行を加速します。 例えば、リスティング1では、atca_jwt_finalize()への呼び出しが利用可能な暗号化デバイス(ATECC608Aなど)を用いてリスティング2のパスワードのJWTを作成します。 この場合、JWT署名の暗号化を加速ATECC608A、設計を統合されたセキュアストレージキーから読み取り、前述の署名作成プロセスを完了させます。

　　しかし、複雑なソフトウェアやセキュリティ機器があっても、IoTデバイスは従来の鍵や証明書の管理方法のため攻撃に対して脆弱なままです。 かつては、秘密鍵は外部から生成され、製造、配布、さらには展開時に安全なストレージデバイスに読み込まれる必要がありました。 ハードウェアセキュリティモジュールやセキュリティ施設を使用していても、唯一のデバイス「知る必要がある」以外に短時間存在する秘密は、偶発的または意図的に露出する可能性のあるセキュリティ脆弱性を表します。 ATECC608Aの機能を活用することで、マイクロチップとグーグルは従来のセキュリティ脆弱性をほぼ排除しました。

　　この新しいアプローチでは、マイクロチップはATECC608Aの能力を利用して、デバイスに秘密鍵を残さずに鍵ペアを生成することができます(図3)。 マイクロチップは、顧客が提供し、マイクロチップのセキュリティ施設内の安全なサーバーに保存されるデバイスが生成した公開鍵に、中間証明書を用いて署名します。 最後に、Microchipは公開鍵をGoogle Cloud IoT Device Managerの顧客アカウントに安全に送信し、各デバイスに最大3つの公開鍵を保存して鍵の回転ポリシーをサポートします。 展開後、IoTデバイスはATECC608Aセキュリティ機能を使って、前述の相互認証プロセスで使用されるJWTを作成できます。

　　図3:Microchip TechnologyとGoogle Cloud IoTサービスの組み合わせにより、鍵および証明書の設定が簡素化され、IoTアプリケーションのセキュリティ強化を目的とした保護された仕組みを提供します。 (画像:Google)

　　MicrochipとGoogleのこの協力により、開発者はこの重要な鍵管理プロセスを完全に卸任できます。 カスタム要件として、開発者はCryptoAuthLib API関数atcab_genkey()を使って独自の鍵管理プロセスを実装できます。これにより、鍵ペアの生成、秘密鍵の安全なストレージへの保存、関連する公開鍵の返還ATECC608Aが可能になります。 /p>

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

　　CryptoAuthenticationデバイス(ATECC608Aを含む)を評価するには、開発者はCryptoAuth XPRO-BアドオンボードをXplained Proボードの2つの拡張ヘッドのいずれかに挿入するだけで済みます。 MicrochipはCryptoAuthLibおよびATECC608Aのセキュリティ機能を評価するためのサンプルソフトウェアを提供しています。 さらに、開発者はMicrochip ATWINC1500-XPRO Wi-Fiアドオンボードを別のヘッダーに挿入してMicrochipサンプルソフトウェアを実行でき、この記事で説明した相互認証プロセス(TLSサーバー認証やJWTデバイス認証を含む)を実演できます。

　　結論

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