セキュリティは、IoT デバイスのデプロイと管理において重要です。Cloud IoT Core には、次のセキュリティ機能が用意されています。
- JSON Web Token(JWT、RFC 7519)を使用したデバイスごとの公開鍵 / 秘密鍵の認証。
- 鍵が不正使用された場合に影響が及ぶ対象がデバイス全体ではなく 1 つのデバイスのみであるため、攻撃対象領域が限定されます。
- JWT の有効期間は限られているため、不正使用された鍵は期限切れとなります。
- RSA または楕円曲線のアルゴリズムをサポートして署名を検証し、強力な鍵サイズを適用できます。
- 同時鍵の登録を可能にすることで、デバイスごとに鍵のローテーションをサポートします。また、認証情報ごとの有効期限をサポートします。
- TLS 1.2 接続。ルート認証局を使用します(MQTT に必要)。
- Cloud IoT Core API アクセスは、Identity and Access Management(IAM)のロールと権限によって制御されます。
認証情報のプロビジョニング
次の図は、デバイス認証情報をプロビジョニングするプロセスをまとめたものです。多くの場合、デバイスを構成するユーザーである認証済みの「プロビジョナー」は、プロジェクトとレジストリを作成しており、デバイスを作成する権限があることを前提としています。プロビジョナーは、Cloud IoT Core API、gcloud コマンド、または Cloud Platform Console を使用して、クラウド内に論理デバイスを作成します。
- 公開鍵と秘密鍵のペアはプロビジョナーによって生成されます。
- プロビジョナーは、作成した公開鍵を指定して、Cloud IoT Core API、gcloud コマンド、Cloud Platform Console を使用してデバイスを作成します。これはデバイスの ID を確認するために使用されます。
- Cloud IoT Core のデバイス マネージャーがデバイス リソースと公開鍵を保存します。
- デバイス マネージャーがプロビジョナーに応答し、デバイスが作成されたことを示します。
- 秘密鍵は、後で認証に使用するためにデバイスに保存されます。このステップでは、ハードウェア トラステッド プラットフォーム モジュール(TPM)を使用できます。
ここに示すステップの順序は規範的なものではありません。たとえば、デバイスが Cloud IoT Core に登録される前にキーをデバイスに保存します。
鍵の作成方法については、鍵ペアの作成をご覧ください。
認証
次の図は、MQTT を使用した Cloud IoT Core での認証をまとめたものです。
- デバイスは、JSON Web Token の使用の説明に従って、JSON Web Token(JWT)を準備します。JWT は、認証フローの秘密鍵で署名されます。
- MQTT ブリッジに接続すると、デバイスは MQTT
CONNECT
メッセージでパスワードとして JWT を提示します。ユーザー名の内容は無視されます。ただし、一部の MQTT クライアント ライブラリは、ユーザー名を指定しない限りパスワードを送信しません。最良の結果を得るには、ユーザー名をunused
やignored
などの任意の値に設定します。 - MQTT ブリッジは、JWT をデバイスの公開鍵と照合して検証します。
- MQTT ブリッジが接続を受け入れます。
- (許可されたクロックのずれを考慮して)JWT が期限切れになると接続が閉じられます。
セキュリティ基準
Cloud IoT Core では、RSA と El 円曲線署名付きトークンの両方にデジタル署名ベースの認証を使用します。次のアルゴリズムがサポートされています。
- JWT
RS256
(SHA-256 RFC 7518 sec 3.3 を使用する RSASSA-PKCS1-v1_5) - JWT
ES256
(P-256 と SHA-256 RFC 7518 sec 3.4 を使用する ECDSA)は、OpenSSL で prime256v1 曲線として定義されています
RSA アルゴリズムは一般的に使用されており、クライアント ライブラリで広くサポートされています。ただし、生成される鍵と署名は非常に大きくなる可能性があります(通常は 1 ~ 2 キロバイト程度)。さらに、RSA は(鍵の長さと CPU の両方において)大量のリソースを使用する可能性があり、リソースが制限されているデバイスに影響する可能性があります。
楕円曲線アルゴリズムは十分にサポートされていますが、RSA ほど広くは使用されません。楕円曲線を使用するには、クライアント ライブラリに追加の依存関係をインストールしなければならない場合があります。ただし、生成される鍵と署名は、RSA で生成されたものよりもはるかに小さく、リソースが限られているデバイスに役立ちます。
主な強み
Cloud IoT Core では、NIST の推奨事項(セクション 5.6.2、55 ~ 56 ページ)に従い、112 ビット以上のセキュリティが必要です。これは、RS256 の最小 2, 048 ビットの鍵サイズに変換されます(NIST の推奨事項の 53 ページ、53 を参照)。
ES256 には、128 ビットのセキュリティ レベル(キーサイズが固定)がプリセットされています。
公開鍵の形式
デバイスの公開鍵を登録する場合、鍵は次のいずれかの形式でなければなりません。
整形 | 説明 |
---|---|
RSA_PEM | base64 でエンコードされた RSA 公開鍵。JWT トークン(RFC 7518)の RS256 署名を検証するために使用できます。 |
RSA_X509_PEM | base64 でエンコードされ、X.509v3 証明書(RFC 5280)でラップされた RSA_PEM 鍵。証明書は自己署名できます。それ以外の場合、Cloud IoT Core はデバイス証明書の署名とレジストリ レベルの証明書とを比較し、証明書の起点を確認できます。 |
ES256_PEM | base64 でエンコードされた ECDSA アルゴリズムの公開鍵(P-256 と SHA-256 を使用)。ES256 アルゴリズム(RFC 7518)で JWT トークンを検証するために使用できます。この公開鍵は証明書でラップされていません。これにより、鍵のサイズが小さく保たれます。これは ES256 の主な利点の 1 つです。 |
ES256_X509_PEM | base64 でエンコードされ、X.509v3 証明書(RFC 5280)でラップされた ES256_PEM 鍵。証明書は自己署名できます。それ以外の場合、Cloud IoT Core はデバイス証明書の署名とレジストリ レベルの証明書とを比較し、証明書のオリジンを検証できます。 |
鍵の作成の詳細については、公開鍵/秘密鍵のペアの作成をご覧ください。
鍵のローテーション
Cloud IoT Core は複数のアクティブなキー(デバイスあたり最大 3 つ)をサポートしており、ローテーションが中断されません。サービスはそれぞれのアクティブな鍵を使用して JWT を検証し、有効な鍵が一致すると接続を受け入れます。
API を使用すると、デバイス認証情報(公開鍵)ごとに expirationTime
を定義できます。有効期限が切れると、キーは無視されますが、自動的に削除されることはありません。10 分間のキュースキューの許容範囲が適用されます。キーに有効期限が指定されていない場合、キーは期限切れになりません。
デバイスのセキュリティに関する推奨事項
次のセキュリティに関する推奨事項は Cloud IoT Core によって適用されませんが、デバイスと接続を保護するのに役立ちます。
- 秘密鍵は秘密のままにします。
- ポート 8883 と 443 で
mqtt.googleapis.com
またはmqtt.2030.ltsapis.goog
と通信する場合は TLS 1.2 を使用します。TLS 接続を維持するには:- Google ルート CA 証明書を使用して、サーバー証明書が有効であることを確認します。
- 定期的なセキュリティ関連のファームウェア更新を実施して、サーバー証明書を最新の状態に保ちます。
- TLS の要件と今後の互換性については、こちらのセキュリティ ノートをご覧ください。
- 各デバイスには固有の公開鍵/秘密鍵のペアが必要です。複数のデバイスが 1 つのキーを共有し、それらのデバイスのいずれかが不正使用されている場合、攻撃者はその 1 つのキーで設定されたすべてのデバイスに成り代わることができます。
- Cloud IoT Core に登録する際に公開鍵を安全に保ちます。攻撃者が公開鍵を改ざんし、プロビジョナーが公開鍵を入れ替えて不適切な公開鍵を登録できる場合、攻撃者はその後、デバイスの代わりに認証を行うことができます。
- Cloud IoT Core に対するデバイスの認証に使用する鍵ペアは、他の目的やプロトコルに使用しないでください。
- キーを安全に保存する機能に応じて、キーのペアは定期的にローテーションする必要があります。現実的には、デバイスをリセットしたときにすべてのキーを破棄する必要があります。
- オペレーティング システムが実行されている場合は、安全に更新できる方法があることを確認します。オペレーティング システムがインストールされていないデバイスの場合、デプロイ後にセキュリティの脆弱性が見つかった場合は、デバイスのソフトウェアを安全に更新できることを確認します。
- ルート証明書を更新する方法があることを確認します。詳しくは、Google Internet Authority のサイトをご覧ください。
- デバイスのクロックが改ざんされていないことを確認します。デバイス クロックが侵害された場合、強力な攻撃者は、トークンの期限を回避して将来有効なトークンを発行するようデバイスをだますことができます。最適な結果を得るには、Google Public NTP サーバーを使用してください。