Skip to main content

IoT のための耐量子コンピュータ

PQC の脅威

将来的に量子コンピュータは、RSA や ECC など現在オンラインで使用されている一般的な非対称暗号をすべて破るようになると予想されています。一般的に「Q デー」と呼ばれるこの日がいつになるかは、いろいろと議論の的となっています。幸いなのは、AES などの対称暗号化アルゴリズムは、量子コンピューティングの脅威に対しても安全だと考えられていることです。

Q デーは何年も先のことかもしれませんが、「Harvest Now, Decrypt Later(今収穫し、後で解読)」の脅威は現在でも存在します。攻撃者は暗号化されたデータを今すでに収集しており、後で量子コンピュータなど強力な技術を利用できるようになってから復号化するつもりなのです。

この脅威で気がかりなのは、たとえデータが暗号化されていたとしても、後で復号化されたときに機密性の高い貴重なデータになってしまう可能性があるという点です。たとえば、財務レコード、医療情報、個人情報などが危険にさらされる可能性があります。このような事態から身を守るには、将来にも備えられる強力な耐量子コンピュータ暗号(PQC)を使用することが重要です。詳細をご希望の方は、「Post-Quantum Cryptography For Dummies(誰でもわかる耐量子コンピュータ暗号)」を参照してください。

業界の現在の対応

セキュリティ業界は、PQC への移行を積極的に進めています。この移行や変更の目的は、量子コンピュータによる将来の脅威から守ることです。米国商務省標準化技術研究所(NIST)は 2017 年、古い非対称アルゴリズムからの移行を開始しました。

2024 年に NIST が発表した新しい PQC 標準は次のとおりです。

  • FIPS-203 ML-KEM: セキュアな通信に用いる鍵のカプセル化。

  • FIPS-204 ML-DSA: モジュール格子ベースの電子署名アルゴリズム。

  • FIPS-205 SLH-DSA: ステートレスハッシュベースの電子署名アルゴリズム。

NIST は、古い非対称アルゴリズムの 廃止予定日を設定しました。業界が新しい PQC 標準の採用に向かうよう後押しすることが目的です。

1. 量子脆弱性のある電子署名アルゴリズム(出典:  NIST IR 8547 ipd)

電子署名アルゴリズムのファミリー

パラメータ

移行

ECDSA

[FIPS186]

112 ビットのセキュリティ強度

2030 年以降は非推奨

2035 年以降は禁止

128 ビット超のセキュリティ強度

2035 年以降は禁止

EdDSA

[FIPS186]

128 ビット超のセキュリティ強度

2035 年以降は禁止

RSA

[FIPS186]

112 ビットのセキュリティ強度

2030 年以降は非推奨

2035 年以降は禁止

128 ビット超のセキュリティ強度

2035 年以降は禁止


NIST の例に倣い、NSA は国家安全保障システム(NSS)に対する商用国家安全保障アルゴリズムスイート 2.0(CNSA 2.0)の要件を更新しました。

NSA は以下に対してガイダンスを推奨しています。

  • 国防総省(DoD)

  • 防衛産業基盤(DIB)

この更新には PQC アルゴリズムが必要です。現行の暗号アルゴリズムも段階的に廃止される予定です。2027 年 1 月 1 日までに、NSS で新規取得されるものは、特に断りのない限り、すべて CNSA 2.0 に準拠することが要求されます。2030 年 12 月 31 日までに、CNSA 2.0 をサポートできないすべての機器とサービスは段階的に廃止しなければなりません。

米国で PQC 採用の動きをさらに加速したのが、2025 年 1 月 16 日にジョー・バイデン元大統領によって署名された大統領令 14144 号です。米国政府に PQC の採用を義務付けています。注目すべきは、この大統領令がトランプ大統領の就任時にも覆されなかったことです。

IETF や CA/B フォーラムなどの標準化団体は現在、これらの新しいアルゴリズムに対するサポートを TLS 1.3 やパブリックトラストエコシステム(ブラウザ、パブリック CA など)に追加する作業に当たっています。Web ブラウザと Web サーバーのように、TLS セッションの両端とも制御するのではない場合、2 つの証明書が必要です。ひとつは ML-DSA などの純粋 PQC 証明書、もうひとつは RSA など従来の証明書です。クライアントとサーバーそれぞれに 2 つの証明書があるので、問題が複雑になります。このことから、業界団体はハイブリッドの x.509 証明書を模索しています。既存の手法と PQC を組み合わせた証明書です。たとえば、MLDSA-44、RSA 2048、SHA256 を併用する場合もあります。

TLS で使用される対称暗号は量子コンピュータの脅威に対して安全ですが、TLS セッションは共有鍵を確立するときにキーアグリーメントの手法も利用しています。現在、ほとんどの TLS トラフィックは、Diffie-Hellman スタイルのキーアグリーメントである安全鍵交換に X25519 を使っています。しかし、量子コンピュータに関するショアーのアルゴリズムなら、完全に X25519 のセキュリティを破ることができます。したがって、優先的にまずキーアグリーメントのメカニズムを ML-KEM にアップグレードする必要があります。

キーアグリーメントは安全な鍵交換を可能にしますが、関係者の ID を検証するものではありません。攻撃者は認証なしにメッセージを傍受できるということです。ブラウザとサーバーで別々のキーアグリーメントを作成し、それぞれのメッセージを再暗号化することもできます。認証 の実施に使われるのが署名です。https://digicert.com などの Web サイトでは、認証局(CA)からの証明書が表示されます。それによって、公開鍵が DigiCert の所有であることが確認されます。サーバーは次に、秘密鍵を使ってハンドシェイクと共有鍵に署名し、クライアントが正しいサーバーと通信していることを保証します。

RSA や ECDSA といった従来の署名方式は、ショアーのアルゴリズムを用いる量子攻撃に対して脆弱です。つまり、攻撃者は署名を偽造でき、中間者攻撃(MitM)を実行できるということです。耐量子署名へのアップグレードは重要ですが、それが必要になるのは量子コンピュータが脅威となる前までなので、緊急なわけではありません。とはいえ、耐量子コンピュータへの移行は複雑で、時間もかかるものです。

IoT デバイスへの影響

NIST が新しい PQC アルゴリズムに FIPS ステータスを割り当てたため、IoT デバイスやコネクテッド製品には次のような影響が考えられますが、これに限定されるとは限りません。

  • すべての米連邦政府機関(行政一般と軍)で PQC の使用が義務化される。

  • NIST の厳格な審査のため、PQC が事実上の標準になる。

  • 国際的な採用や標準が後押しされる。EU のサイバーレジリエンス法、米国のサイバートラストマーク、医療機器向けの FDA 市販前ガイダンス、CSA の Matter といった IoT のセキュリティ標準で PQC が要求され始める。

  • コンプライアンスへの影響:

    • 連邦政府機関および請負業者に対する義務化の実施

    • 証明書プログラムの刷新。FIPS 140-3 など。

    • NIST の標準を参照する HIPAA、FISMA などの規制の改定が必要になる。

    • コンプライアンス監査により PQC がチェックされる。

    • 政府機関の調達で PQC 対応システムが義務付けられる(RFP要件)。

    その結果、デバイスのハードウェア、デバイスのソフトウェア、TLS ライブラリ、バックエンドサービス、クラウド、PKI インフラストラクチャなど、お客様のコネクテッド製品ソリューションが影響を受けます。

製品への実際の影響

大まかに言えば、コネクテッド製品への影響は次のように分類されます。

  • デバイス

  • バックエンドサービス

  • PKI

  • TLS

06f28466-a846-4ee1-a8b9-5551ff7b3d69.png

確認のチェックリスト

以下のチェックリストを使用して、コネクテッド製品ソリューションの各種コンポーネントがどんな影響を受けるかを確認してください。

デバイス

  • デバイスの SDK は高度な暗号標準に適合するように更新されていますか?

    • デバイス暗号の SDK は ML-DSA と ML-KEM をサポートしていますか?

    • FIPS 140-3 認証を受けたデバイス暗号が必要ですか?

    • お使いのデバイスに TLS 1.3 スタックはインストールされていますか?

    • 上記のライブラリをデバイスの SBOM に含めていますか?

    • SDK のアップデートをデバイスフリート全体に確実にデプロイできる信頼性の高い OTA アップデートシステムがありますか?

  • TPM とセキュアエレメントは、強化された暗号機能と安全なキーストレージをサポートしていますか?

    • お使いのデバイスには TPM またはセキュアエレメントが搭載されていますか?

    • ML-DSA をサポートしていますか?

      注記

      TPM 2 を使用する場合、現在 TCG Trusted Platform Module Library Specification, Family 2.0, Level 00, Revision 01.83 - March 2024 は ML-DSA をサポートしていません。

    • TPM やセキュアエレメントのファームウェアをアップデートして、ML-DSA をサポートすることはできますか?

    • デバイスの秘密鍵の保護に PUF(Physical Unclonable Function)技術を使用していますか?

    • PUF の実装を更新して ML-DSA をサポートすることはできますか?

  • PQC に最適化された現行の OpenSSL 実装を実行していますか?

    注記

    PQC を追加するには、OQS などの OpenSSL プロバイダを活用する必要があります。

    • お使いのデバイスで OpenSSL の最新バージョンを実行していますか?

    • お使いのデバイスに OQS はインストールされていますか?

    • デバイスの SBOM に OQS は含めていますか?

  • お使いのデバイスは、新しい ML-DSA 鍵ペアを生成して、よりサイズの大きい証明書を管理できるようになっていますか?

    注記

    デバイス上で暗号 SDK を更新したら、新しい ML-DSA 鍵ペアを生成し、CSR を PKI に送信して、新しい純粋 PQC 証明書または複合 x.509 証明書を受信する必要があります。

    • お使いのデバイスはサイズの大きい証明書に対応できますか?新しい PQC x.509 証明書のサイズは大きくなりました。そのため、制約のあるデバイスでは問題になることがあります。証明書は大幅に大きくなり(およそ 10 倍)、一部のプロトコルにとって問題になります。

    • お使いのデバイスは複数の証明書を扱えますか?デバイスは、後方互換性のために既存の RSA/ECC 証明書と新しい PQC 証明書の両方を必要とする場合があります。そのため、制約のあるデバイスでは問題になることがあります。

    • デバイスのルート証明書ストアを更新できますか?新しい PQC ルート CA 証明書をデバイスルートストアに追加する必要があります。そのため、制約のあるデバイスでは問題になることがあります。

    • ルートストアのアップデートをデバイスフリート全体に確実にデプロイできる信頼性の高い OTA アップデートシステムがありますか?

バックエンドサービス

  • ネットワークとバックエンドサービスは TLS 1.3 に対応していますか?

    • ネットワークはより大きな ClientHello メッセージを処理できますか?

    • WAF、ファイアウォール、プロキシなど、デバイスとバックエンドの間にある各機能は、PQC で TLS 1.3 を処理できますか?

  • 証明書ライフサイクル管理(CLM)はアジャイルですか?

    • TLS エンドポイントがすべて CLM の管理課にあり、ゼロタッチで証明書を管理していますか?

    • TLS エンドポイントへの PQC 証明書の発行は自動化できますか?

    • PQC 証明書の更新は自動化できますか?

  • お使いの OTA(Over-the-Air)アップデートサービスは拡張可能ですか?

    • 新しい暗号ライブラリや TLS スタックのアップデートをデバイスにプッシュするための、信頼性が高いデバイス(OTA)アップデートプロセスがありますか?

    • お使いの OTA サービスは TLS 1.3 と PQC に対応していますか?

    • エアギャップまたは切断されたデバイスはどうアップデートしますか?

PKI

  • PKI は、新しい PQC 証明書タイプをサポートしていますか?

    • 純粋 PQC 証明書: ML-DSA ルート、ML-DSA 中間 CA、ML-DSA エンドエンティティ。

    • デュアル証明書: 純粋 PQC 証明書 + 既存の RSA/ECC 証明書。

    • ハイブリッド証明書: MLDSA-44 + RSA 2048 + SHA256 などの複合証明書。

  • PKI のハードウェアセキュリティモジュール(HSM)は PQC に対応していますか?

    • HSM は PQC に対応し、FIPS 認証を受けていますか?

    • HSM のファームウェアアップデートは可能ですか?

    • HSM ベンダーは FIPS 140-3 認定を取得しているところですか?

TLS

  • お使いのコネクテッド製品ソリューションは、サードパーティのサービスを含めて TLS 1.3 に対応していますか?

    注記

    PQC に対応しているのは TLS 1.3 だけです。TLS 1.2 は機能凍結中です。https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/03/ を参照してください。

    • お使いの HTTP、MQTT、クライアント、サーバーソフトウェアは TLS 1.3 をサポートしていますか?

    • TLS 1.3 がサポートされている場合、実際に有効化されて設定されていますか?たとえば、Paho、Mosquitto、その他の MQTT クライアントでは、使用する TLS バージョンを指定できます。TLS v1.2 を使用するようにハードコーディングしている場合は、そのコードを更新する必要があります。

  • デバイスから接続するエンドポイントは TLS 1.3 をサポートしていますか?

    • Azure IoT Hub は TLS 1.3 をサポートして いません

    • Azure IoT Central は TLS 1.3 をサポートして いません

    • Azure IoT DPS は TLS 1.3 をサポートして いません

    • Azure Event Grid MQTT ブローカーは TLS 1.3 をサポートしています。

    • AWS IoT Core は TLS 1.3 をサポートしています。

  • IoT ネットワークは、TLS ハンドシェイクサイズの増大に起因するネットワークトラフィックとレイテンシーの増加に対応できますか?

    • ハンドシェイクのサイズが大きくなっても対処できますか?ML-DSA では、TLS ハンドシェイクに 14.7kB が追加されます(1312 バイトの 2 つの公開鍵と 2420 バイトの 5 つの署名)。https://blog.cloudflare.com/another-look-at-pq-signatures/ を参照してください。

    • お使いのルーター、プロキシ、ファイアウォール、ゲートウェイは、新しい TLS 1.3 + ML-KEM + ML-DSA ClientHello メッセージをサポートしていますか?このメッセージはインターネットの標準 MTU より大きいため、複数のパケットにまたがる必要があります。https://dadrian.io/blog/posts/pqc-signatures-2024/ を参照してください。

どんな準備ができるか

PQC に備えるため、業界は米国土安全保障省の用語を採用しました。それが「暗号化の俊敏性」です。この設計標準によって、今後の暗号化アルゴリズムや標準への更新が可能になります。その際、周囲のインフラを変更したり置き換えたりする必要はありません ― 米国土安全保障省は

暗号化の俊敏性を備えるとは、新たな暗号の脅威に備えることを意味します。すなわち、量子コンピュータなどの新しいテクノロジーに伴う脅威です。

準備するうえでは、2030 年まで待つ必要はありません。

暗号化の俊敏性への段階的アプローチ

b83389f1-10e7-4688-a559-39d3e53582ff.png

検出

  • 上記の検出チェックリストを使って、コネクテッド製品ソリューション全体について検出を実行します。

  • ソフトウェア部品表(SBOM)、暗号部品表(CBOM)、ハードウェア部品表(HBOM)を活用して、デバイス全体で使用されている暗号および TLS ライブラリを特定し、それが PQC に対応しているかどうかを確認します。

  • 標準化団体と協力して、明確化を図ります。

    • IETF、CA/B フォーラム、NIST など。

  • ベンダーと協力して、ベンダーの PQC ロードマップを把握します。

  • PQC のセキュリティ専門知識を有するパートナーを活用します。

テスト

  • デバイスの暗号ライブラリを、デジサートの TrustCore SDK のように PQC 対応、クロスプラットフォーム、高パフォーマンス、そして FIPS-140-3 認定のソリューションに更新してください。

  • デバイスの TLS ライブラリを、デジサートの TrustCore SDK のようにクロスプラットフォーム、高パフォーマンス、そして FIPS-140-3 認定ソリューションである PQC 対応の TLS 1.3 スタックに更新してください。

  • デバイスの暗号ライブラリを、PQC 対応の TPM、セキュアエレメント、またはデジサートの TrustCore SDK のような PUF ソリューションと統合します。

  • デジサートの Device Trust Manager のようなソリューションを使って、デバイスに純粋 PQC 証明書と複合証明書を発行する準備が整っていることを確認します。

  • Thales HSM などのデジサートパートナーのソリューションを使用して、PQC 対応の TPM を更新してテストします。

デプロイ

デジサートの Device Trust Manager のような統合デバイス管理、OTA アップデートサービス、証明書ライフサイクル管理ソリューションを利用して、デバイスフリートソフトウェアのアップデートと PQC の発行を自動化します。

管理

デジサートの Device Trust Manager など、自動化されたスケーラブルな管理ツールを使用して、デバイス全体でソフトウェアアップデートと証明書ライフサイクルを自動化します。

PQC に対応している DigiCert Device Trust のソリューションはどれか

DigiCert ONE プラットフォーム上に構築された DigiCert Device Trust のソリューションはすべて PQC に対応しています。

DigiCert Device Trust Manager は PQC に対応し、以下をサポートしています。

  • EST、SCEP、ACME、CMPv2、REST API を介した純粋 PQC(ML-DSA)証明書の発行と更新。詳細については、サポートされる PKI 鍵タイプと署名アルゴリズム を参照してください。

  • EST、SCEP、ACME、CMPv2、REST API を介した複合証明書の発行と更新。詳細については、サポートされる PKI 鍵タイプと署名アルゴリズム を参照してください。

  • 純粋 PQC 証明書と複合証明書のバッチ発行のサポート。

  • クライアント側とサーバー側の鍵ペア生成。

  • ML-DSA および複合証明書の証明書ライフサイクル管理を自動化すると、PQC 証明書の有効期限切れが発生しなくなります。

DigiCert TrustEdge は、デジサートによる Linux デバイス向けの無償のセキュリティ CLI です。ML-DSA 鍵ペアを生成する、CSR を作成する、EST または SCEP 経由で PKI に CSR を送信するなどの機能をサポートし、PQC に対応しています。すべて無料でダウンロードできるシンプルな CLI を通じて利用できます。

DigiCert TrustCore SDK は、デジサートによる C-SDK 組み込みセキュリティツールキットです。ML-KEM、ML-DSA、TLS 1.3、および FIPS 140-3 認証の暗号をサポートし、PQC に対応しています。

Labs.digicert.com は、デジサートによる 無償の PQC プレイグラウンドであり、テスト目的で PQC 証明書を速やかに作成できます。

FAQ

PQC は TLS 1.2 でサポートされますか?

いいえ、サポートしているのは TLS 1.3 のみです。TLS 1.2 は機能凍結中であり、IETF は 単刀直入に言うと、TLS 1.2 用の耐量子コンピュータ暗号はサポートされない と明言しています。https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/03/ を参照してください。

パブリックトラストのエコシステムが PQC に対応するのはいつですか?

CA/B フォーラム は、NIST の新アルゴリズムを証明書に組み込むという提案について議論しているところです。適切な識別子を割り当て、公開鍵と秘密鍵の相互運用可能な形式に合意するための標準が登場しつつあります。これらが RFC になるのは、おそらく 2025 年後半か 2026 年前半になるでしょう。

PQC に FIPS 140-3 は適用されますか?

はい。2024 年 8 月、NIST は、新しい PQC アルゴリズムを FIPS 140-3 に組み込むための CMVP プログラムに対する 変更も発表しました。デジサートなどの暗号ベンダーは、FIPS 140-3 の再認証を取得する必要があります。

関連リンク