AN-7648: MAXQ1065 を使って安全なAWS IoT Core 接続を確立する方法

はじめに

過去数年の間にスマート・デバイスの数は指数的に増加しました。その設計と機能が複雑に連携し、私たちの生活を容易にする数多くの特性が実現されました。インターネットへの容易なアクセスや技術と通信の進歩は、いつでも、そしてどこからでも遠隔地にあるデバイスを管理することを可能にし、そのデバイスがある場所まで実際に出向く必要はなくなりました。しかし、相互接続されるデバイスの数が増加すればするほど、データ改ざん、不正アクセス、セキュリティの侵害などのリスクが懸念されるようになっています。致命的な事象を回避するには安全な環境が必要です。本稿では、MAXQ1065とAWS IoT Coreを使ってこの安全な環境を確立する方法を示すと共に、必要な証明書と鍵を作成する方法とその使用法を説明して、基本的なセキュリティ接続とセットアップの実例を挙げます。このアプリケーション・ノートでは、MAXQ1065 SDK を使って鍵と証明書を作成し、デバイスのプロビジョニングとテストを行います。このSDKは、ご要望に応じて提供されます。 

MAXQ1065 の機能

• エンベデッド・デバイスのセキュリティを確保する固定機能IC
• セキュリティ機能 
  • (D)TLS 1.2、汎用的なSP800-56r3 ECC DH 鍵交換
  • 認証、機密性、アテステーション用固有ID、セキュア・ブート／セキュア・アップデートのための汎用的な暗号化ツールボックス 
  • タイミング設定が可能な外部ウォッチドック機能
  • リセット出力（イベントを選択可能）
  • 改ざん入力ピン（IN）を通じたパワー・オン改ざん検出
  • フィールドでのアップグレードが可能
• セキュア・ストレージ 
  • ChipDNA 保護 + ダイ・シールド、改ざん検出機能
  • セキュリティ属性をカスタマイズできる8KB ダイナミック・ファイル・システム（10K サイクル）
  • 安全な鍵管理とライフサイクル、x.509 に対応
• ハードウェア暗号化エンジン
  • SHA-2-256
  • ECC (NIST P-256)*：ECDSA、ECDH
  • AES-128/256（GCM、CBC、ECB、CCM）
  • NIST SP800-90A/B/C 対応のTRNG
• セキュア・チャンネルを備えた10MHz SPI ペリフェラル
• −40ºC/+105ºC、1.8V/3.3V 動作、100nA シャットダウン・モード（**）
• 12 ピンTDFN、3mm × 3mm、ピッチ0.5mm

AWS IoT Core について

AWS IoT Core は、IoT デバイスの管理と認証、およびそれらのデバイスとの通信を行うためのプラットフォームです。IoT デバイスは、AWS IoT Core サーバーに直接接続するか、ゲートウェイを通じて接続します。通常、サーバーの認証にはTLS 接続が使われますが、デバイス自体の認証はJSON Web Token（JWT）プロトコルを使って行われます。

基本

IoT デバイスが直接、あるいはゲートウェイを介してAWS IoT Core サーバーとの接続を確立する前に、各デバイスは、AWS IoT Core サーバーとのトランスポート層セキュア（TLS）セッションを開始する必要があります。このTLS セッションは共有対称鍵を作成して、通信の認証、完全性確保、および暗号化を行います。また、IoT デバイスが正しいサーバーと接続しているという保証をデバイスに提供します。

TLS セッションが確立されると、サーバーはJSON Web Token（JWT）プロトコルを使い、安全な方法でIoT デバイスを確認します。この相互認証の完了後は、確立されたTLS セッションを通じて、通常のHTTP トラフィックやMQTT トラフィックを安全に開始することができます。

JWT 認証はユーザーが定義するルート証明書と鍵ペアに依存しており、これらはそれぞれJWT_CA 証明書、JWT 鍵ペアと呼ばれます。サーバーから見ると、IoT デバイスは「レジストリ」と呼ばれるグループにまとめられており、各レジストリはそのJWT_CA 証明書によって定義されます。レジストリ内のすべてのデバイスは、そのレジストリに対応するJWT_CA のプライベート鍵によって発行されたJWT 証明書の所有権を示すことで、そのID が正当なものであることを実証する必要があります。各デバイスには固有のJWT 鍵ペアと、それに対応するJWT 証明書があります。この証明書は、そのレジストリのJWT 認証局（JWT_CA）によって発行されます。

注：すべての証明書は、PEM（Privacy Enhanced Mail）フォーマットで符号化されたx.509 v3 フォーマットでなければなりません。これはbase64 に符号化されたDER フォーマットであり、「BEGIN CERTIFICATE-----」デリミタと「-----END CERTIFICATE」デリミタの間に挟まれている必要があります。JWT_CA プライベート鍵は、128 ビット以上のセキュリティで暗号化されたPEM フォーマットでなくてはなりません。プライベート鍵の暗号化手法を定めたPKCS#8 などの標準を参照してください。JWT_CA プライベート鍵を使用すれば、「有効な」デバイスを生成することができます。したがって、その秘密を保つと共に、使用を厳密に管理することが不可欠です。

準備

説明を進める前に、AWS IoT Core のドキュメントを参照して、チュートリアル「レジストリを使用したモノの管理」の内容に従ってください。「モノからプリンシパルをデタッチする」までのステップを完了させます。

認証のセットアップ

レジストリにアタッチするJWT_CA ルート証明書（とプライベート鍵）を作成します。MAXQ1065 SDK には、このシーケンスに必要な自己署名証明書と鍵を作成する「make_ca_cert」スクリプトが含まれています。

必要なステップ

1. 「make_ca_cert」スクリプトを実行します。
   1. このスクリプトはJWT_CA プライベート鍵を作成し、それを「cert privkey_server_ECDSA_secp256r1_secp256r1.pem」というファイルに保存します。これは、MAXQ1065 のメモリに保存されているデバイス固有の証明書を発行するために、後で使用します。
   2. また、このスクリプトは、作成されたJWT_CA プライベート鍵を使いx509 JWT_CA 自己署名証明書を作成し、「cert_CA.pem」ファイルに保存します。
2. 作成したJWT_CA 証明書をAWS IoT Core レジストリにアップロードします。
   1. 作成した証明書ファイル「cert_CA.pem」を開いて、その内容をコピーします。

      

      

   2. AWS コンソールへ移動してIoT Core パネルを開きます。

      

   3. ［Security］を選択して、［Certificates］ボタンをクリックします。
   4. ［Add Certificate］ボタンをクリックして、［Register certificates］をクリックします。

      

   5. ［Register certificates］ウィンドウで［CA is not registered with AWS IoT］をクリックします。次に［Upload］ボタンをクリックして「cert_CA.pem」をアップロードし、更に［Register］をクリックします。

      

   6. ［Certificates］ページで証明書の隣にあるチェックボックスをクリックし、登録された証明書を選択します。［Actions］ドロップダウンをクリックしてから［Activate］をクリックし、その証明書を有効にします。

      

   7. 以上でレジストリに証明書が追加され、有効になります。これで、証明書を使い、MAXQ1065 の機能を活用してIoT ノード・デバイスを認証することができます。次に、デバイス（MAXQ1065）のプロビジョニングのセクションに示すように、デバイス固有の証明書を使ってMAXQ1065 のプロビジョニングを行う必要があります。

デバイス（MAXQ1065）のプロビジョニング

デバイスのプロビジョニングは、そのデバイス固有の鍵ペアを作成し、JWT_CA プライベート鍵を使ってその証明書を発行するプロセスです。

このプロセスを実現するために、MAXQ1065 SDK には「init_tls_iot」スクリプトが含まれています。このスクリプトは、以下の手順に示す例のような各ステップを提供します。「init_tls_iot」スクリプトは、個々のデバイスごとに以下のステップを実行します。

1. MAXQ1065 内部でデバイスの鍵ペア（JWT プライベート鍵とJWT パブリック鍵（公開鍵））を作成します。
2. 作成されたデバイスのパブリック鍵を読み出します。

   

3. 作成されたJWT パブリック鍵を、JWT_CA プライベート鍵を使って証明します。
4. デバイスのJWT 証明書（csr_cert.pem）をデバイス（より具体的にはMAXQ1065 のメモリ）に改めてロードします。

   

以上で、IoT デバイスは固有のJWT 認証鍵と、それに対応する証明書を得たことになります。したがって、このデバイスはAWS IoT Coreサーバーによる認証が可能です。より具体的に言うと、デバイス証明書の発行に使われるルートJWT_CA 証明書によって決定されるレジストリに所属します。

以下に示す追加ステップは、AWS IoT ルート証明書をクライアント・デバイスにロードするためのもので、これにより、そのデバイスがTLS ハンドシェイク時にAWS IoT Core サーバーを認証し、未知のサーバーではなく信頼できるAWS IoT サーバーに接続していることを確認できるようにします。これらのステップは、同じ「init_tls_iot」スクリプトでも実行されます。

1. 下記のURL からAmazon Root CA 3 をダウンロードします。https://www.amazontrust.com/repository/AmazonRootCA3.pem
2. Amazon Root CA 3 をMAXQ1065 のメモリにロードします。

   

AWS IoT Core へのデバイス登録

クライアント・デバイスがAWS IoT Core サーバーに接続するごとに、サーバーはそのデバイスのID を安全に検証しなければなりません。個々のデバイスをAWS IoT レジストリに予め登録しておくことによって、その後の認証がより迅速かつ簡単になります。実際、各デバイスの証明書がAWS IoT サーバーのレジストリにロードされるのは登録時に一度だけです。レジストリのJWT_CA証明書を使用して行うデバイス証明書の検証は、その段階で実行されます。AWS IoT Core サーバーは、レジストリの証明書JWT_CA を使って、クライアント・デバイスから送られてきたJWT 証明書（証明書はMAXQ1065 内に保存されます）が、JWT_CA プライベート鍵により発行されたものであることを確認します。その後でデバイスがIoT サーバーに接続したときに、それ以上証明書の送信と検証が求められることは一切ありません。サーバーは単純にそのデバイスのID を照合してレジストリに属していることを確認し、JWT 認証を要求してそのID の裏付けを行います。

個々のデバイスは、このプロセスに従い、すべてAWS IoT Core サーバーに登録する必要があります。

1. 図6 に示すように、「csr_cert.pem」をAWS IoT Core > Security > Certificates > Register certificates にアップロードします。
2. AWS CloudShell を使い、「EXAMPLE_DEVICE」という名前のデバイスをレジストリに追加します。
   1. aws iot create-thing --thing-name EXAMPLE_DEVICE
   2. aws iot attach-thing-principal --thing-name EXAMPLE_DEVICE --principal arn:aws:iot:{Certificate ARN}

      

ここで、上記のコマンド・ラインに入力されたJWT デバイス証明書（csr_cert.pem という名前のファイル）は、前にアップロードしたJWT_CA 証明書を使ってAWS IoT Core により検証されます。

デバイスの実行

デバイスとAWS IoT Core サーバーの接続は、以下のプロセスに従います。

1. デバイスは、ローカルのアマゾン・ルート証明書を使ってAWS IoT Core サーバーの証明書を検証します。

   

   1. サーバーは、その証明書をクライアント（デバイスとも言います）に送ります。
   2. クライアントは、プロビジョニング段階で事前にMAXQ1065 にロードされた、アマゾン・ルート証明書を使ってサーバー証明書を検証します。この証明書の検証はMAXQ1065 の内部で行われます。
   3. この検証に成功すると、MAXQ1065 はサーバーのパブリック鍵を取り出して、後で使用できるように保存します。

      

2. デバイスがAWS IoT Core サーバーに対して自分自身の認証を行います。

   

   1. サーバーが新しいECDHE 鍵ペアを作成します。
   2. サーバーが、サーバーのプライベート鍵を使ってECDHE パブリック鍵とMAXQ1065 から送られてきた乱数に署名し、署名したECDHE パブリック鍵をデバイスに返信します。
   3. デバイスのMAXQ1065 は、サーバー証明書からデコードしたサーバー・パブリック鍵を使って、サーバーから送られてきたデータの署名を検証します。サーバーのパブリック鍵の検証とデコードは、この前のステップで行われてMAXQ1065 に保存されます。
   4. 署名の検証が終わると、この署名によってサーバーのID が証明され、次のステップのためにECDHE パブリック鍵が内部に保持されます。

      

3. ECDHE 鍵交換を行います。セッション鍵を取得してください。

   

   1. MAXQ1065 が新しいECDHE ランダム鍵ペアを作成します。
   2. ECDHE プライベート鍵は、認証済みサーバーのECDHE パブリック鍵に関連付けられます。
   3. この組み合わせにより、両側（デバイスとサーバー）で秘密が共有されます。この共有秘密は、更にAES セッション鍵にも引き継がれます。

      

4. アプリケーション層セキュリティを実行します。セッション鍵を使って暗号化／復号を行ってください。
   

   図20 に、セッション確立後のTLS 通信を示します。サーバーがクライアントにメッセージ（例えば要求に対する応答）を送る場合、サーバーは、AES セッション鍵を使ってそのメッセージの暗号化と署名を行います。

   

   クライアント・デバイスがサーバーからのTLS パケットを受信すると、デバイスのメイン・マイクロコントローラがそのTLS パケットをMAXQ1065 に入力します。MAXQ1065 は、前に確立されたセッション鍵を使ってこのTLS パケットを復号して検証し、復号された状態のままメイン・マイクロコントローラへ戻します。逆方向の通信でも同じプロセスが適用されます。

   

5. クライアントの認証を行います。

   

   TLS セッションが確立されるとクライアント・デバイスがサーバーを認証しますが、まだこの時点ではデバイスはサーバーを認証していません。この追加的なステップは相互認証を完了させるために行われます。

   クライアント・デバイスはJWT を作成し、そのデバイスのJWT プライベート鍵を使ってこれに署名します。サーバーは、クライアントのJWT 証明書を使って、この署名されたトークンを検証します。以下に詳細なプロセスを示します。

   1. サーバーがクライアントにチャレンジ（乱数）を送信します。
   2. クライアントはMAXQ1065 を使ってこのチャレンジに署名します。署名にはJWT プライベート鍵が使われます。
   3. クライアントは、この署名とクライアントのJWT 証明書を返信します。
   4. サーバーがJWT_CA 証明書を使ってクライアントのJWT 証明書を検証し、その証明書からクライアントのパブリック鍵を取得します。
   5. サーバーが、クライアントの証明書から得た信頼できるパブリック鍵を使って、チャレンジの署名を検証します。
   6. 署名の検証が無事に終了すると、クライアントが証明書付属のパブリック鍵と一致するプライベート鍵を本当に所有していることが証明されます。

   JWT の詳細についてはhttps://jwt.io/を参照してください。

   

   プロビジョニング・オプション

   展開を容易にするために、アナログ・デバイセズは、工場でのセキュリティが確保された、そのまますぐに使えるプログラミング・サービスを提供しています。詳細および最小要件については、アナログ・デバイセズの販売代理店にお問い合わせください。

   このサービスの一般的なフローを図24 に示します。

   

   まとめ

   IoT デバイスは無人で使われたり安全な施設内に展開されていなかったりすることが多いので、もともと攻撃にさらされやすい傾向にあります。したがって攻撃者にとっては、これらのデバイスから暗号鍵を手に入れるという意図の下に侵入型攻撃をしかけやすい存在になっています。鍵を手に入れてしまえば、攻撃者がそのデバイスになりすましたりファームウェアを入れ替えてボットネットを作成したりすることが可能になり、これはネットワークに対する大規模な攻撃の基礎的要素となり得ます。

   MAXQ1065 セキュア暗号化コプロセッサは、安全に実装された暗号化機能と安全な鍵保管機能をエンベデッド・システムやIoT アプリケーションを実行するあらゆるマイクロコントローラに追加することによって、ネットワークに接続されたエンベデッド・システムのセキュリティを強化します。特に、MAXQ1065 のChipDNA PUF 技術は、ハッカーが認証情報を盗み出すために集積回路に対して行う侵入型攻撃やリバース・エンジニアリング攻撃からの保護機能を指数的に強化します。ChipDNA 動作のプロービングや観測を行おうとするあらゆる試みは基本的な回路特性を変えてしまうので、IoT クラウド・インフラストラクチャに接続するための認証情報を保護する固有の秘密が見つかってしまうのを防ぐことができます。MAXQ1065 は、接続用の認証情報を使用できるようにする前に欠かすことのできない、デバイス・ファームウェアの検証を可能にする機能も備えています。これは、IoT クラウド・サーバーへの接続前に、デバイスが正当なファームウェアを実行していることを保証します。同様に、データ暗号鍵はデバイスが実際にフィールドに展開されるまでデバイス内に安全に保管できるので、製造や輸送の段階でも取り扱いに注意すべきデータを保護することができます。

   更に、鍵や証明書を予めMAXQ1065 内にプログラムすることで、IoT デバイスを即座に、しかもより安全にクラウド・インフラストラクチャに登録することができます。IoT デバイスは環境セキュリティ要求なしで製造できますが、予めプロビジョニングされているMAXQ1065 IC は既にセキュリティが確保されていて、その内部には接続認証情報が安全に保管されています。

   MAXQ1065 は攻撃者に対するハードルを上げ、エンベデッド・デバイスにおける証明可能なセキュリティの実現を妥当なコストで可能にします。