RSA暗号化と署名

RSAは、合成数を法とする整数上のトラップドア演算を定義します。 教科書的RSAは決定的で、改変可能性があり、構造的に安全でないため、 安全なシステムでは、標準化された暗号化方式または署名方式を通してのみ これらの演算を使用します。

鍵生成 #

RSA鍵生成器は、異なる、独立して生成された確率的素数 p と q を取得し、 次を計算します。

n      = p * q
phi(n) = (p - 1) * (q - 1)
lambda = lcm(p - 1, q - 1)

法 n が鍵サイズを決定します。生成規格は、素数のサイズ、差、素数判定、 乱数ビット生成に追加条件を課します。小さな素数による試し割りに合格した だけの二つの値を選ぶのでは不十分です。アプリケーションは素数を自力で 生成せず、承認されたライブラリの鍵生成器を呼び出すべきです。

公開指数 e は gcd(e, lambda) = 1 を満たすように選びます。慣例的には 65537 を 選びます。秘密指数は、そのモジュラ逆数です。

e * d = 1 (mod lambda)

phi(n) をカーマイケル値 lambda の代わりに使用しても、PKCS #1 の条件下で 正しい逆数を生成できます。公開鍵には (n, e) が含まれます。秘密鍵は通常、 p、q、d、および中国剰余定理（CRT）の値を保持します。

秘密鍵演算とCRT #

公開代表元 m と暗号文代表元 c は、RSAプリミティブによって次のように 関係付けられます。

c = m^e mod n
m = c^d mod n

秘密鍵演算では、p と q を法として別々に計算し、CRTで結果を再結合できます。 この最適化は大幅に高速ですが、一方の分岐での障害によって n の因数が 露出する可能性があります。したがって、暗号ライブラリはCRTの保護策と、 RSAブラインディングや結果検証などの実装上の対策を組み合わせます。

攻撃者が選択した暗号文または署名をデバイスに送信できる場合、タイミング、 キャッシュ、電力、および故障時の挙動も脅威モデルに含まれます。定数時間性と サイドチャネル耐性は実装の性質であり、RSA方程式から生じる性質ではありません。

安全性の仮定と鍵サイズ #

p と q が既知なら秘密鍵演算を容易に復元できるため、法の素因数分解は 十分な攻撃になります。しかし、すべてのRSAベース方式の解読が素因数分解と 厳密に等価であることを確立した証明はありません。安全性の議論は、 RSA問題、符号化方式、ハッシュ関数、乱数、および攻撃モデルにも依存します。

現行のNIST移行ガイダンスでは、112ビットの古典的安全性強度に対して、 少なくとも2,048ビットのRSA法を許容しています。3,072ビットの法は、 約128ビットの強度に対応します。プロトコルやコンプライアンス要件によって、 さらに大きなサイズが要求されたり、新規用途でRSAが禁止されたりする場合が あります。鍵を大きくするとCPU、帯域幅、証明書サイズの負担が増えますが、 脆弱なパディング方式や侵害された実装は修復されません。

RSA自体は前方秘匿性を提供しません。TLS 1.3はRSA鍵輸送を廃止し、一時的な (EC)DHEによってトラフィック秘密を確立します。RSA証明書は、許可された RSA-PSS署名を使用して、引き続きTLS 1.3エンドポイントを認証できます。

OAEP暗号化 #

RSAES-OAEPは、公開RSA演算を適用する前に、ハッシュ、マスク生成関数、 ラベル、およびランダムシードを用いてメッセージを符号化します。 法を k オクテット、ハッシュ出力を hLen オクテットで表す場合、 平文の上限は次のとおりです。

mLen <= k - 2*hLen - 2

したがって、OAEPは大量データではなく、ランダム生成された対称鍵などの 短い値を対象とします。ハイブリッドプロトコルはコンテンツ暗号鍵を カプセル化または転送し、実際のペイロードを認証付き暗号で保護します。 完全なハイブリッド構成はプロトコル標準に従う必要があります。 RSAES-OAEP単体ではアプリケーションデータを認証しません。

OAEPパラメーターはアルゴリズム識別子の一部です。両エンドポイントは、 ハッシュ、マスク生成用ハッシュ、およびラベルについて合意する必要があります。 あるAPIのライブラリ既定値は別のAPIの既定値と一致しない可能性があるため、 プロトコルで明示しなければなりません。

PSS署名 #

RSASSA-PSSはメッセージをハッシュし、ソルトを取り込み、マスク生成関数を 適用して、秘密RSA演算の前に結果を法の幅に符号化します。検証では公開演算を 逆向きにたどり、すべてのフィールドを検証します。ソルト長、メッセージ ハッシュ、およびマスク生成用ハッシュは明示的なパラメーターです。

RSA署名が必要な新規プロトコルではPSSを使用すべきです。PKCS #1 v1.5の 暗号化および署名の符号化は一部のレガシープロトコルで依然として必要ですが、 互換性は新規設計でそれらを選択する理由にはなりません。検証器は、 プロトコルで識別された方式を正確に実装し、不正な形式または範囲外の 代表元を拒否する必要があります。

整数、ASN.1、PEMの符号化 #

PKCS #1は、非負整数と固定長ビッグエンディアン・オクテット文字列との間で 変換する I2OSP と OS2IP を定義します。方式が正確に k オクテットを 要求する場合、先頭のゼロ・オクテットにも意味があります。ASN.1 DERの INTEGER値は符号付きであるため、最上位ビットが立っている正のRSA整数には 先頭に 00 オクテットが付きます。これらの規則を混同すると、値が切り詰め られる、負になる、または誤った幅になります。

一般的なコンテナーは、それぞれ異なる構造を持ちます。

PEMは、DER値をテキストラベルとBase64アーマーで囲みます。したがって、 PUBLIC KEY と RSA PUBLIC KEY のようなラベルは、それぞれ異なるASN.1構造を 識別します。場当たり的なBase64処理とバイトスライスで整数を取り出さず、 保守されているライブラリで期待するコンテナーを解析してください。

教科書的RSAとパディングオラクルの排除 #

教科書的RSAは、モジュラ累乗を直接適用します。平文の同一性を漏らし、 代数的な改変を許し、完全性検査もありません。「秘密鍵でハッシュを暗号化して 署名する」と説明される例を含め、暗号化にも署名にも決して使用しないでください。

復号処理では、失敗原因が暗号文の範囲、OAEP構造、ラベルハッシュ、区切り文字、 後段の平文解析のいずれであるかを明らかにしてはなりません。攻撃者から観測可能な 異なるエラー、応答時間、再試行動作、またはログは、パディングオラクルを形成する 可能性があります。オラクル耐性のある復号を実装したライブラリを使用し、 外部から観測できる失敗時の挙動を均一に保ち、外側のプロトコルを認証してください。 いかなる失敗後も、部分的に復号された平文を返してはなりません。

参考文献 #

• RFC 8017: PKCS #1 v2.2
• FIPS 186-5: デジタル署名規格
• NIST SP 800-56B Rev. 2: 整数因数分解暗号を用いるペア単位の鍵確立方式
• NIST SP 800-131A Rev. 2: 暗号アルゴリズムと鍵長の利用移行
• RFC 8446: TLS 1.3
• RFC 7468: PKIX、PKCS、およびCMS構造のテキスト符号化