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

確認のチェックリスト

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

デバイス

  • Have your device SDKs been updated to meet advanced cryptographic standards?

    • Does your device crypto SDK support ML-DSA and ML-KEM?

    • Do you need FIPS 140-3 certified device crypto?

    • Does your device have a TLS 1.3 stack installed?

    • Have you included the above libraries in your device’s SBOM?

    • Do you have a reliable OTA update system to deploy SDK updates reliably across your fleet of devices?

  • Do your TPMs and secure elements support enhanced cryptographic functions and secure key storage?

  • Are you running a current OpenSSL implementation optimized for PQC support?

    注記

    You need to leverage OpenSSL providers such as OQS to add PQC support.

    • Are you running a current version of OpenSSL on your device?

    • Is OQS installed on your devices?

    • Have you included OQS in your device’s SBOM?

  • Is your device ready to generate new ML-DSA keypairs and manage larger certificate sizes?

    注記

    After the crypto SDK is updated on the device, new ML-DSA keypair needs to be generated, CSR sent to PKI, and a new pure PQC or composite x.509 certificate received.

    • Can your device handle the large certificate sizes? New PQC x.509 certificates are larger. This can be problematic on constrained devices. Certificates will be substantially larger (roughly 10x) which causes problems for some protocols.

    • Can your device handle multiple certificates? Devices may require both existing RSA/ECC and new PQC certificate for backwards compatibility. This can be problematic on constrained devices.

    • Can you update the device’s root certificate store? New PQC root CA certificates need to be added to device root store. This can be problematic on constrained devices.

    • Do you have a reliable OTA update system to deploy root store updates reliably across your fleet of devices?

バックエンドサービス

  • Is your network and backend services TLS 1.3-ready?

    • Can your network can the handle larger ClientHello messages?

    • Can your WAFs, firewalls, proxies and anything else in between your devices and your backend handles TLS 1.3 with PQC?

  • Is your certificate lifecycle management (CLM) agile?

    • Are all your TLS endpoints under CLM for zero-touch certificate management?

    • Can you automate the issuance of PQC certificates to your TLS endpoints?

    • Can you automate the renewal of PQC certificates?

  • Is your over-the-air (OTA) update service ready to scale?

    • Do you have a reliable device (OTA) update process to push new crypto libs and TLS stack updates to devices.

    • Does your OTA service support TLS 1.3 and PQC?

    • How will you update air-gapped or disconnected devices?

PKI

  • Does your PKI support the new PQC certificate types?

    • Pure PQC certificates: ML-DSA Root, ML-DSA Intermediate CA, ML-DSA End Entity.

    • Dual certificates: Pure PQC certificate + existing RSA/ECC certificate.

    • Hybrid certificates : Composite, such as MLDSA-44 + RSA 2048 + SHA256.

  • Does your PKI’s Hardware security module (HSM) support PQC?

    • Are you HSMs capable of PQC and are they FIPS certified?

    • Can your HSM be firmware updated?

    • Is your HSM vendor obtaining FIPS 140-3 certification?

TLS

  • Is your connected production solution enabled for TLS 1.3, including third-party services?

    注記

    Only TLS 1.3 will support PQC! TLS 1.2 is in feature freeze. See https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/03/

    • Do your HTTP, MQTT, client and server software support TLS 1.3?

    • If TLS 1.3 is supported, is it actually enabled and configured? For example, in Paho, Mosquitto and other MQTT clients, you can specify the TLS version to use; if you have hard coded them to use TLS v1.2, that code will need to be updated.

  • Do the endpoints your devices connect to support TLS 1.3?

    • Azure IoT Hub does NOT support TLS 1.3

    • Azure IoT Central does NOT support TLS 1.3

    • Azure IoT DPS does NOT support TLS 1.3

    • Azure Event Grid MQTT broker supports TLS 1.3

    • AWS IoT Core supports TLS 1.3

  • Can your IoT network handle the increased network traffic and latency due to increased TLS handshake size?

どんな準備ができるか

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 の再認証を取得する必要があります。

関連リンク

このセクションの内容: