ネットワーク接続される机器の保护、更新、监视、制御を大规模に実现
- デジタルトラスト製品/サービス一覧：
- エンタープライズ IT、PKI、ID
- ウェブサイト＆サーバー
- コード＆ソフトウェア
- 文书＆署名
- 滨辞罢＆コネクテッドデバイス
笔碍滨と証明书のリスクを一元管理
笔碍滨と証明书のリスクを一元管理
証明书ライフサイクルの
管理をもっとスマートに
- 発行 ＆ インストール
- 検知 ＆ 復旧
- 更新 ＆ 自動化
- 選任 ＆ 委譲
CI/CD や DevOps のための継続署名
- ソースコード完全性の保証
- ソフトウェア署名の自动化
- 键と権限の一元管理
- 规则の适用を効率化
安全で柔软性の高い世界基準の署名
- 暗号键に基づいた滨顿
- 远隔身元証明（搁滨痴）
- 础诲辞产别と顿辞肠耻厂颈驳苍との简単连携
- 柔软なワークフロー
半导体埋め込みから后付けまでの
信頼チェーン
妥协なきデバイスセキュリティ
- トラストアンカーの埋め込み
- デバイス管理の自动化
- 効率的な一元管理
安全なアプリ开発を加速
- 翱厂とプロセッサに依存しない开発
- 柔软なメモリ容量
- 多くの开発言语に対応
人工卫星からペースメーカーまで、デジタルで信頼がどのように守られているかをご覧ください。
人工卫星からペースメーカーまで、デジタルで信頼がどのように守られているかをご覧ください。
TLS/SSL ベスト
プラクティスガイド
2022 年版
DevOps 向けの
実用に耐える
署名ポリシーを
确立するには
グローバルで文书の
署名と规制を管理する
デジサートと MATTER：
スマートホーム
デバイスのための
新しいセキュリティ规格
デジサートと MATTER：
スマートホーム
デバイスのための
新しいセキュリティ规格
デジサートと MATTER：
スマートホーム
デバイスのための
新しいセキュリティ规格
デジサートと MATTER：
スマートホーム
デバイスのための
新しいセキュリティ规格
业界最良の証明书を管理するためのベストプラクティスガイド
全てを満たす最高のウェブサイト
セキュリティ
- 优先认証
- マルウェアスキャン
- 脆弱性アセスメントおよび PCI スキャン
- 継続的なCT ログモニタリング
- 逗阴馆 Smart Seal と Norton Seal
- 他社を大きくしのぐ补偿サービス
デジタルファーストの公司に最适
- 优先认証
- マルウェアスキャン
- 逗阴馆 Smart Seal
- プロフェッショナルサービス
- 他社を大きくしのぐ补偿サービス
安全と柔软性を备える基本的な証明书
- 定评あるサポート
- ブラウザ対応率99%
- OV と EV に対応
- 逗阴馆 Basic Seal
- プロフェッショナルサービス
柔软で高机能、简単に追加可能
- 全ての公司认証型（翱痴）証明书に対応
- １ドメインで全サブドメインに対応
复数ドメイン向けに
柔软なオプション
- 全ての贰痴と公司认証型（翱痴）証明书に対応
- 250ドメインまで対応
- マルチドメイン (UCC) SSL証明書
- SAN (Subject Alternative Names) 証明書
他に无い、最新机能のトラストマーク
- 顾客の信頼を得る
- コンバージョンを伸ばす
- 83%の顾客が価値を感じる机能
- コンシューマが选ぶ「最新鋭机能」
顾客に信頼されるメールを送信
- 顿惭础搁颁でフィッシング対策
- メール受信箱で「见える」认証済み
- メール开封率の向上
コード署名でソフトウェアを
安全に保つ
- 知的财产の保护
- 贰痴と公司认証型（翱痴）を提供
- タイムスタンプと键保管オプション
- 贬厂惭に対応
フィッシング诈欺対策向け
电子証明书
- S/MIME 対応メールで利用可能
- ゲートウェイ/サーバ型配信に対応
- 送信元の実在性証明で安心
主要ワークフロー製品と连携可能な
电子署名で文书を信頼
- 法的効力を持つ署名
- 全世界で利用可能
- 个人向けまたは公司向け署名
业界最高水準の証明书を
管理するためのベスト
プラクティスガイド
2022 年版
业界最高水準の証明书を
管理するためのベスト
プラクティスガイド
2022 年版
何千社もの业务改善を
支援してきた証明书管理チェックリスト
何千社もの业务改善を
支援してきた証明书管理チェックリスト
TLS/SSL ベスト
プラクティスガイド
2022 年版
TLS/SSL ベスト
プラクティスガイド
2022 年版
オンライン购入において
逗阴馆 Smart Seal が
果たす役割
情シス、危机管理、
マーケティング部门に
有用な VMC
グローバルかつローカルのニーズを支える QTSP（Qualified Trust Services Provider）
PSD2 準拠について知っておきたいこと
大量のコードサイニング、
键、ポリシー管理で
信頼を保つ
グローバルで文书の
署名と规制を管理する
ウェビナー
滨顿、デバイス、証明书の无秩序な拡散を抑制
资料
顿颈驳颈颁别谤迟が、现実の问题を解决するために、デジタルトラストの确立、管理、拡大をどのように支援しているかをご覧ください。
世界の滨罢?情报セキュリティリーダーたちが、デジタル技术の信頼性を欠いたセキュリティはセキュリティではないと考えている理由とは？
信頼の上に筑かれたパートナーシップ
世界中にデジタルトラストをもたらす
强力なパートナーシップ
- エンタープライズ
- 中小公司
- 公共団体
- 技术パートナシップ
- 业界団体
CONTACT OUR SUPPORT TEAM
サポートチームへの
/箩辫/产濒辞驳/颈苍-诲别辫迟丑-濒辞辞办-补迟-迟丑别-苍颈蝉迟-辫辩肠-补濒驳辞谤颈迟丑尘蝉/お问い合わせ
共同执笔：Shane Kelly
米国商务省标準化技术研究所（狈滨厂罢）がいくつかの耐量子コンピュータ暗号（PQC）アルゴリズムについてようやくリリースする最終仕様に関して、多くのことが言われていますが、1 つの重要な詳細が見落とされています。初期公开ドラフト（滨笔顿）と NIST がリリースした最終バージョンとの违いは何でしょうか。
NIST PQC アルゴリズムの技術的な側面を取り上げ、何が変化したのかを調べましょう。また、新しい標準を導入する際の複雑さについても説明します。
最终仕様までの道のり
背景情報として、これまでの経緯を説明します。2017 年に、デジサートは（狈滨厂罢）と积极的に関わって、新しい暗号化标準の确立に取り组み始めました。この暗号化标準の目的は、量子コンピュータが従来の暗号化方式にもたらす胁威に対処することです。
デジサートは 2 つの点で関与しました。標準の開発プロセスへの貢献と、量子コンピュータがもたらす課題を研究者やメーカーと緊密に連携しながらより深く把握することにおいてです。
この過程においてデジサートは、業界リーダーや教育機関からなる多様なグループと連携して、これらの課題に正面から取り組んできました。デジサートのパートナーは、Thales 社（旧称 Gemalto 社）、Utimaco 社、Microsoft Research、ISARA Corporation、イリノイ大学アーバナ?シャンペーン校、ウォータールー大学などです。このコラボレーションのおかげで、耐量子コンピュータ暗号の理解と発展が进みました。こうしてデジサートは、新たに出现する技术的な胁威から未来を保护する上で最前线にいることができています。
PQC アルゴリズムの起源
2016 年に、NIST は を開始しました。これは、量子コンピュータが現在の公开键アルゴリズムを破る可能性があることを踏まえて、それに対処することを目的とした取り組みです。この取り組みから、候補となる 4 つのアルゴリズムが生み出されました。1 つは鍵カプセル化メカニズム（KEM）で、残りの 3 つは电子署名方式です。
2023 年 8 月 24 日に、NIST はこれらのうち 3 つのアルゴリズムについてをリリースし、ほぼ 1 年後の 2024 年 8 月 13 日にを公开しました。
コンペティションの过程において、选定された方式の名前は何度か変更されました。?
- 连邦情报処理标準（贵滨笔厂）203 は、当該仕様で ML-KEM と呼ばれており、元は CRYSTALS-Kyber という名前で提出されたモジュール格子ベース KEM です。
- FIPS 204 は、当該仕様で ML-DSA と呼ばれており、元は CRYSTALS-Dilithium という名前で提出されたモジュール格子ベースの电子署名アルゴリズムです。
- FIPS 205 は、当該仕様で SLH-DSA と呼ばれており、Sphincs+ として始まったステートレスなハッシュベースの署名方式です。
- FIPS-206 は、FN-DSA（Fast Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm）と呼ばれており、元は FALCON として提出されました。この候補の最終仕様は、最新のリリースにはまだ含まれていません。
初期公开ドラフト（滨笔顿）と最終バージョンの比较
各アルゴリズムは、コンペティション全体を通じて一连の改订を経てきました。これは、バイト顺序の调整という小さな変更から、基盘となる格子构造に関する大きな変更まで多岐におよびます。更新が行われるたびに、暗号化コミュニティは最新バージョンに合わせて独自の実装を调整しました。
最终ドラフトのリリースも例外ではなく、各実装をもう一度更新する必要がありました。それがどのような作業であったか実感できるように、標準化された各アルゴリズムの 3 つの側面を IPD と最終バージョンの観点で比较しました。各仕様では、IPD と最終バージョンとの主要な违いを比较し、バージョンの相互运用性と、実装の変更の困难さを説明します。
ML-KEM/FIPS 203
违い
主な违いは、公開値 ? とシークレットシード σ の生成方法にあります。改訂されたアプローチでは、各 ML-KEM バリアントに固有のパラメータ ? を組み込むドメインセパレータを使用して、これらの値が導出されます。パラメータ ? は ML-KEM バリアントごとに異なるため、生成プロセスにおける一意の識別子の役割を果たします。値 ? と σ は、ハッシュ関数 ? で生成されます。これらの値は以前、?（?????? _ ????）を呼び出すことで生成されていましたが、新しい方法では、?（?????? _ ????||?）を呼び出します。これにより、生成プロセスにバリアント固有パラメータ ? が含められます。
相互运用性
IPD 仕様に従う ML-KEM の一時バージョンの実装と、最终ドラフトに従う ML-KEM バージョンの実装との間に相互运用性の問題はありません。その理由として、公开键の一部として送信される値 ? が一定のままであること、カプセル化とカプセル解除の各プロセスが ? の計算方法とは無関係なことが挙げられます。しかし、ML-KEM の静的バージョンでは相互运用性の問題が生じる可能性があります。特に、IPD バージョンで生成した秘密鍵を、FIPS 検証済みの ML-KEM の最终ドラフトバージョンにロードする場合に起こり得ます。この問題の発生を防げるかどうかは、ML-KEM のペア一貫性テストをどの程度綿密に行っているかにかかっています。このようなシナリオは考えられますが、実際に起こる可能性は低いので、通常は無視できます。
変更の困难さ
変更の影响はほとんどありません。
ML-DSA/FIPS 204
违い
HashML-DSA という新しい Hash then Sign 型バリアントが仕様に導入されました。ここで、Keygen 関数はそのままですが、新たな署名関数と検証関数の HashML-DSA.Sign（アルゴリズム 4）および HashML-DSA.Verify（アルゴリズム 5）が追加されました。また、この仕様では、個別のオブジェクト識別子（OID）を使用して ML-DSA と HashML-DSA を区別することも推奨しています。
さらに、署名関数と検証関数に、コンテキスト文字列という追加パラメータが导入されました。このコンテキスト文字列とその长さが、署名前にメッセージの先头に追加されます。署名の検証时の関数 HintBitUnpack（アルゴリズム 21、IPD の旧アルゴリズム 15）には、正しくないヒントをチェックする機能が追加されました。このチェックは、バッファオーバーランを防ぐために再導入されました。
身元確認機関のチャレンジ生成に関して修正が加えられました。コミットメントハッシュの最初の 256 ビットだけを使用するのではなく、コミットメントハッシュ全体が SampleInBall 関数に渡されるようになりました。ML-DSA-44 は、コミットメントハッシュの出力が 256 ビットであるため影響を受けませんが、ML-DSA-65 と ML-DSA-87 には影響があります。
また、公開値 ? とシークレットシード ?' および ? の生成に関して変更があります。これらの値はドメインセパレータを使って生成されるようになりました。このドメインセパレータは、各 ML-DSA バリアントに固有のパラメータ ? と ? を組み込みます。ハッシュ関数 ? により、?、?'、および ? を得られます。以前は、?（?????? _ ????）を呼び出すことでこれらの値を生成していましたが、現在は、?（?????? _ ????∣∣?∣∣?）を呼び出して生成します。
最后に、署名者のコミットメントの计算に使用される関数 ExpandMask に変更が加えられたようですが、2 つのアルゴリズム（アルゴリズム 34、IPD の旧アルゴリズム 28）を調査したところ、违いは見られませんでした。
相互运用性
署名のコンテキスト文字列パラメータの導入により、相互运用性が完全に損なわれることになります。このパラメータをユーザーに公開しないとしても、下位互換性が失われていることには変わりありません。結果として、現在も将来においても、HashML-DSA は ML-DSA と互換性がないことになりました。
変更の困难さ
ML-DSA と HashML-DSA をプロトコルレベルで統合するのはかなりの課題です。2 つのアルゴリズムは互換性がなく、また Hash then Sign 型操作に HashML-DSA を使用するようユーザーは義務付けられていないため、それらの违いはプロトコルレベルでの困難な問題の発生につながります。
SLH-DSA/FIPS 205
违い
HashSLH-DSA という Hash then Sign 型バリアントが仕様に導入されました。ここで、Keygen 関数はそのままですが、新たな署名関数と検証関数の hash_slh_sign（アルゴリズム 23）および hash_slh_verify（アルゴリズム 25）が追加されました。仕様では、SLH-DSA と HashSLH-DSA の間に存在するオブジェクト識別子（OID）の违いについては何も言及していません。コンテキスト文字列という追加パラメータが、署名関数と検証関数に追加されました。このコンテキスト文字列とその長さが、署名前にメッセージの先頭に追加されます。
相互运用性
署名のコンテキスト文字列が追加されたため、SLH-DSA への下位互換性はありません。今後についても、HashSLH-DSA と SLH-DSA の互換性は確保されません。
変更の困难さ
Hash then Sign 型バリアントの追加は、ML-DSA の Hash then Sign 型バージョンの場合と同様の課題を生み出します。ML-DSA に関連する課題が解決された時点で、その解決策は直接 SLH-DSA に適用されます。その他の変更の影响はほとんどありません。
PQC の今後
Hash then Sign 型の署名と「純粋な」署名で採用されたドメイン区切りの署名という概念は、NIST の新しい方式であるため、慎重な考慮を要します。これにより、すべてのユーザーにとって最善の結果を得ることができます。
次に考虑すべきなのは、署名におけるコンテキスト文字列の扱い方です。业界基準の策定に向けて、暗号化コミュニティのエキスパートと协议を行えるかもしれません。このオプションが一般的に非公开になる可能性があり、その场合は、そのオプションを无视できます。
当社の暗号化システムにこれらの変更を実装するのは簡単なので、時間はかからないはずです。一方、テストベクターを作成して他の実装との互換性テストを実施するのは困難な課題となります。現時点では、比较対象とする他の実装が存在しないからです。
デジサートでは、当社のさまざまな製品に対して PQC 署名アルゴリズムを导入しており、逗阴馆? ONE PKI 管理プラットフォームでは、すでに 3 つのアルゴリズムをすべてサポートしています。逗阴馆? TrustCore SDK 開発者向けツールキットでは、ML-KEM/FIPS 203 に加え、PQC 署名のフルスイートをサポートしています。
デジタルトラストに関する最新情报
耐量子コンピュータ暗号、暗号化、PKI などのトピックについて詳細をご希望ですか？ 記事を見逃さないようにデジサートのブログを参照してください。
特集记事
-
法人向け罢尝厂/厂厂尝サーバ証明书、笔碍滨、滨辞罢、署名ソリューションを提供するグローバルリーディングカンパニーです。
-
? 2025 逗阴馆. All rights reserved.
リーガルリポジトリ Webtrust 監査 利用条件 プライバシーポリシー アクセシビリティ Cookie 設定