ついに！ SM2 国家暗号アルゴリズムが Linux カーネル コミュニティに承認されました

背景

Guomi は国家商用暗号化の略称です。アルゴリズム標準は国家暗号管理局によって策定され、多数の製品およびインターフェース仕様とアプリケーション シナリオも策定されています。

近年の対外的な国際貿易紛争や技術封鎖、対内的なインターネットの急速な発展、IoT分野の台頭、金融分野の変化の激化などにより、特に、外国の技術や製品への過度な依存を脱却し、産業ネットワークのセキュリティ環境を構築し、我が国の産業情報システムのセキュリティと信頼性を高めることが必要かつ緊急です。

暗号化アルゴリズムは、情報セキュリティを確保するための中核技術であり、特に銀行業界の最も重要な中核分野では、3DES、SHA-1、RSA などの国際的に認められた暗号化アルゴリズム システムと関連標準が長年使用されてきました。

2010年末、国家暗号管理局は我が国が独自に開発した「楕円曲線公開鍵暗号アルゴリズム」（SM2アルゴリズム）を発表しました。国家暗号管理局は、重要な経済システムにおける暗号アプリケーションのセキュリティを確保するために、2011 年に「公開鍵暗号アルゴリズムのアップグレードの推進に関する通知」を発行し、「2011 年 3 月 1 日から、構築中および構築予定の公開鍵暗号インフラストラクチャの電子認証システムと鍵管理システムは、国家秘密アルゴリズムを使用する必要があります。2011 年 7 月 1 日から、運用が開始され、公開鍵暗号を使用する情報システムは、SM2 アルゴリズムを使用する必要があります」と明確に要求しました。

国家暗号管理局は2012年以降、「中華人民共和国暗号業界標準」の形でSM2/SM3/SM4などの暗号アルゴリズム標準とその応用仕様を順次発表してきました。ここで、「SM」は「商業秘密」の略で、国家機密に関わらず商業目的で使用される暗号技術を意味します。

その中でも、次の公開アルゴリズムは注目に値します。

SM2: 楕円曲線暗号 (ECC) に基づく公開鍵暗号アルゴリズム標準。デジタル署名、鍵交換、公開鍵暗号化を提供し、RSA/ECDSA/ECDH などの国際アルゴリズムの置き換えに使用されます。

SM3: メッセージ ダイジェスト アルゴリズム、ハッシュ結果は 256 ビット、MD5/SHA1/SHA256 などの国際アルゴリズムの置き換えに使用されます。

SM4: 対称暗号化アルゴリズム、キー長とパケット長はともに128ビット、主に無線LAN規格で使用され、DES/AESなどのアルゴリズムの置き換えに使用される。

国家秘密証明書: ここでの国家秘密証明書とは、国家秘密アルゴリズム (SM2-with-SM3) を使用する標準 X509 形式の証明書を指します。証明書はハッシュ アルゴリズムとして SM3 を使用し、デジタル署名アルゴリズムとして SM2 を使用します。

国家機密 SSL: 国家機密アルゴリズムを使用し、国家機密標準に準拠した安全な伝送プロトコル。SSL/TLS プロトコルの国家機密バージョンでもあります。

SM2 の先進的な Linux カーネルへの道

現在、無線 LAN 標準の普及により、Linux カーネルは SM3 および SM4 アルゴリズムを適切にサポートしています。しかし、SM2アルゴリズムと国家暗号証明書はまだサポートされておらず、国家暗号に基づいてカーネル内でフルスタックの信頼性と整合性の検証を確立することは不可能であるため、カーネル内でこのシステムをサポートすることが急務となっています。全体的な計画としては、カーネルで SM2 アルゴリズムと国家暗号化証明書をサポートし、まずは社内ビジネスに適用し、最終的にはコミュニティに推進していく予定です。

全体のプロセスで多くの非互換性があったので、それらを記録しておきます。

初めて

計画が整ったら、次のステップはそれをどのように実行するかを検討することです。暗号化アルゴリズムがある場合は、まずそれを openssl から移植できるかどうかを検討します。幸いなことに、openssl は SM2/3/4 を非常によくサポートしており、楕円曲線アルゴリズムの実装はテスト済みで非常に成熟しており、最新バージョンでは国家暗号化証明書も完全にサポートしています。

残念ながら、openssl のさまざまなモジュールは互いに密接に結合されています。SM2 および国家暗号化証明書を実装するには、BIGNUM、ECC、X509 などを含む openssl アーキテクチャとインフラストラクチャ コードを移植する必要があります。作業量は間違いなく膨大です。たとえ実装できたとしても、この方法がコミュニティに受け入れられるのは難しいでしょう。何度も検討を重ねた結果、私たちはこの「近道」を断念しました。

第2ラウンド

驚くべき事実を発見しました。カーネルにはすでに楕円アルゴリズムの基本的な実装 (crypto/ecc.c) が存在するので、このアルゴリズムに基づいて試してみませんか?そこで、SM2 仕様に従ってコーディングを始めましたが、結果は少々残念なものでした。この楕円アルゴリズムは、実際は SM2 では失敗し、最も基本的なドット積の結果さえ間違っていました。何？スクリプトはこうであってはなりません。そこで私はアルゴリズムの上級開発者にメールを送り、すぐに次のような返信を受け取りました (世の中にはまだまだ心優しい人がたくさんいるものだとため息が出ます)。

Shamir のトリック アルゴリズムはおそらく汎用的ですが、曲線に固有のものは ecc_point_double_jacobian() です。

アルゴリズムは、私 (および以前のコーダー) が使用した曲線に適合するように選択されています。これらを使用する場合は、その特性を注意深く確認する必要があります。

他の曲線に適合する可能性のある、使用されたアルゴリズムのいくつかのバリエーションは、参照論文（コメント内）に記載されています。

理由をまとめると、このアルゴリズムは、NIST および ECRDSA の楕円曲線パラメータに正確に適合する高度に最適化されたアルゴリズムですが、国内の SM2 曲線パラメータには必ずしも適していません。このパスは実現可能ではないようです...

…泣いてるから、気にしないで。

...涙を拭いて、成功か失敗かを見てください。人生は英雄的です。もう一度やり直してください...

第3章

調査を繰り返した結果、カーネル内の RSA アルゴリズムは、libgcrypt (有名なプライバシー保護ソフトウェア GnuPG の基礎となるアルゴリズム実装) から派生した mpi (高精度整数) ライブラリに基づいて実装されていることが判明しました。 RSA を実装するために導入された mpi の初期バージョンがカーネルに実装されています。

現在、libgcrypt にはすでに完全な楕円曲線基本アルゴリズムが備わっているため、libgcrypt に基づく SM2 アルゴリズム曲線を試してみるという姿勢でテストしました。ありがたいことに、この驚きはショックにはならず、実験結果は SM2 仕様と一致しています。

第4章

libgcrypt の ECC アルゴリズムは、実装の結合度が低い一般的なアルゴリズムです。そこで、私はあるアイデアを思いつきました。まず libgcrypt に SM2 を実装し、試用後にこれらすべてをカーネルに移植し、さらにコミュニティに広めるという方法です。これもコミュニティに受け入れられる方法のようです。

計画を立てた後は、ただ楽な姿勢をとり、キーボードの上に手を厳粛に置き、指で思考が自然に流れるのを待つだけでした。その後の開発とデバッグは順調に進み、すぐに暗号化、復号化、署名、署名検証という 4 つの公開鍵アルゴリズムのセットが完成しました。

私たちはこれらの実装を一度に libgcrypt コミュニティに提出しました。2 回のレビューと修正を経て、SM2 アルゴリズムは最終的に ECC のサブアルゴリズムとしてコミュニティに受け入れられました。libgcrypt のメンテナーの 1 人である NIIBE Yutaka 氏の忍耐と親切さ、そして伝統的な中国文化に対する理解に感謝したいと思います。全体的なプロセスはスムーズに進んだので、詳細には触れません。関連する提出書類を添付します:

第5章

鉄は熱いうちに打て。カーネル内の lib/mpi ライブラリは古いバージョンであり、RSA を提供するため、libgcrypt 内の mpi と比較すると去勢されたバージョンです。不足している関数と ECC アルゴリズムを移植する必要があります。これは技術的に難しい作業ではありませんが、繊細な作業でもあり、作業量は少なくありません。

実際には、SM2 の実装プロセスで不足していた部分はすべて移植され、すぐに対応する SM2 アルゴリズムと国家秘密証明書が実装されました。数回の磨き上げと十分なテストを経て、この最初のパッチセットが完成しました: https://lkml.org/lkml/2020/2/16/43

第6章

中国の古い諺に「最初は大いに努力するが、その後衰え、そして三度目には疲れ果てる」とある。物事の進歩はまたしても障害に遭遇した。 Linux カーネルは、専用の暗号化ライブラリとは比較になりません。コミュニティは、あまり知られていないアルゴリズムにあまり関心を示さず、興味を持つ人もほとんどいませんでした。最終的には、実用的なアプリケーション シナリオがないために却下されました。もちろん、このままでは終わりません。コード量の多さとメンテナーのレビュー意欲の低さを考慮して、私たちはSM2の暗号化、復号化、署名を思い切ってカットし、国家暗号化証明書のサポートに必要な署名検証機能のみを残しました。その後、いくつかの小さな修復と改善を行い、同時にIMAの上流の国家暗号化アルゴリズムを強化して、IMAシナリオでの国家暗号化機能の適用を実際のケースとして使用できるようにしました。

同時に、関係する開発者やメンテナーとの継続的なソフトおよびハードのコミュニケーションと、新しいパッチの継続的な送信により、メンテナーの通常の応答時間とパッチの組み込みパターンを最終的に把握し、SM2 のコミュニティへの参入のペースをゆっくりと進め続けました。この期間中は劇的なストーリーや血みどろの筋書きはなく、バラバラバラ...であり、while (1) {...} ループは省略されています。

第7章

中秋節が過ぎ、月も中旬になりました。半年以上経ち、SM2はもはや最も馴染みのあるものではなくなり、パッチはいつの間にかバージョンv7に更新されました。中秋節の満月の夜にはいつも何か大きな出来事が起こります。その夜、鍋の蓋を頭に乗せ、腰に昆布を巻き、足元に色とりどりの雲を背負った無比の英雄が飛来。ついにSM2は至宝を手に入れた。話を元に戻すと、このバージョンのパッチは最終的にコミュニティに受け入れられ、Linux メインライン 5.10-rc1 に統合されました。

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=Tianjia+Zhang

何も問題がなければ、カーネルバージョン 5.10 で正式にリリースされる予定です。

libgcryptは各国の暗号化アルゴリズムを完全にサポートしています

その後、偶然にも、SM4 が libgcrypt に実装されました。国家暗号化開発プロセスの副産物として、libgcrypt は現在、国家暗号化アルゴリズム SM2/3/4 を完全にサポートしています。これらの実装は、次のバージョン 1.9.0 で正式にリリースされる予定です。そのうち、SM3は2017年に関係する同僚によって開発されました。

ima-evm-utils は SM2-with-SM3 国家秘密署名をサポートします

カーネルはすでに SM2 と国家暗号証明書をサポートしています。IMA 整合性署名のユーザー モード ツールとして、ima-evm-utils は国家暗号証明書もサポートする必要があります。関連する提出物は添付されています:

https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/ceecb28d3b5267c7d32c6e9401923c94f5786cfb/log/?path=

既知の問題

SM2 にはまだ注意が必要な問題がいくつかあります。

SM2 X509 証明書には、SM2 公開鍵アルゴリズム用に定義された独立した OID はありません。現在、OID_id_ecPublicKey 識別子はデフォルトで SM2 として認識されます。

SM2 仕様では、推奨される楕円曲線パラメータの OID が定義されていないため、SM2 アルゴリズムにはデフォルトの楕円曲線パラメータが 1 つだけ存在します。

SM2 仕様でメッセージに署名する場合、メッセージ自体の SM3 も計算します。同時に、SM2楕円曲線パラメータと公開鍵はSM3の計算に参加する必要があります。SM2秘密鍵署名は、最終的なハッシュ結果に署名するためのものです。この仕様定義は少し異なり、国際一般アルゴリズムとの大きな違いです。

通常、X509 証明書の解析とアルゴリズムは独立したモジュールとして実装されます。まさにこの SM2 仕様により、実装は強く結合されています。X509 証明書を検証する場合、証明書内の tbs の SM3 ハッシュを計算する必要があります。このハッシュには楕円曲線パラメータと公開鍵データも必要であり、これらのデータは完全な SM2 署名検証プロセスにおける一時的なデータです。現在のカーネルは、このようなコールバック メカニズムを提供していません (もちろん、これは SM2 の特殊なケースです)。これにより、X509 証明書の解析と SM2 アルゴリズムが強く結合され、切り離すことはできません。

これにより、この機能の適用にもいくつかの制限が生じます。SM2 は組み込みコンパイル (Y) のみをサポートし、モジュールへのコンパイル (M) はサポートしません。X509 は、国家暗号化証明書を正常に検証するために、コンパイル中に SM2 をサポートしていることを認識する必要があります。実装の観点からは、関数ポインターを取得するために SM2 モジュールを動的にロードする方法もいくつかありますが、フレームワーク レイヤーのサポートと比較すると、あまり使いやすくはありません。

IMA署名がファイルハッシュを計算する際、カーネルが直接ファイルハッシュを計算します。SM2署名が使用されるかどうかについては特別な処理はありません（上図のZa値の増加を参照）。現在のカーネルは、IMA 国家秘密署名検証をサポートしており、ima-evm-utils の国家秘密 sm2+sm3 署名もサポートしています (最新の openssl に依存)。現在、この部分は Za 値を追加せずにファイル ハッシュを直接計算します。これは、現時点では最善の解決策でもあります。

説明する必要があることの 1 つは、国家の暗号署名および検証プロセスで Za が必要であることです。署名検証プロセスでのみ必要ですが、国家の暗号プロセスは現在の主流のアルゴリズムに反しています。これをサポートするには、カーネルと ima-evm-utils ツールの両方を大幅に変更する必要があります。カーネルにはアーキテクチャの変更が伴い、コミュニティはそれを受け入れたがりません。そのため、現在主流の方法でサポートされているのは sm2+sm3 IMA 署名です。

簡単に言うと、ポイントは2つあります。

国家暗号化証明書の検証をサポートするには、SM2 をコンパイルしないか、内部でコンパイルする必要があり、モジュールへのコンパイルはサポートされません。もちろん、非対称アルゴリズムである SM2 はハッシュに署名するか、国家暗号化 IMA 検証に基づいているだけなので、この制限はありません。 IMA 署名ツール ima-evm-utils およびカーネル計算ファイル SM3 ハッシュで使用される国家暗号化アルゴリズムには Za が追加されておらず、仕様とは若干異なります。