LoginSignup
528
355

More than 1 year has passed since last update.

RSAの終わりの始まり - 暗号移行再び

Last updated at Posted at 2023-01-18

前振り

 全国の暗号を使うエンジニアの皆さんこんにちは。今日は暗号移行とRSA暗号の話をしたいと思います。まず暗号を利用している皆さんであればCRYPTRECの「電子政府推奨暗号リスト」のことはご存じですよね!(言い切るw)

 CRYPTRECから2022年7月(昨年夏)に暗号強度要件(アルゴリズム及び鍵長選択)に関する設定基準(PDF直リンク)が公開されました。この中では暗号のセキュリティ強度で各種暗号と鍵長が整理されています。セキュリティ強度はビットセキュリティと呼ばれるビットサイズ(共通鍵暗号の場合のビット長)で区分されます。暗号アルゴリズムが違ってもセキュリティ強度で比較ができるということですね。例えば現在一般的に良く使われているセキュリティ強度は112ビットセキュリティが多く、これにはデジタル署名であればRSA暗号の2048ビットやECDSAのP-224等が含まれます。今日は公開鍵暗号について語ります。

 暗号アルゴリズムは年々それを破る為の技術や環境が上がっていきます。例えば力業で暗号を破る場合には高速なコンピューターが必要ですがご存じの通りコンピューターは年々速く安く(入手が容易)なっています。また暗号を破るための方法を日夜考えている良い人や悪い人たちがいるので新しい解読手法が見つかってしまうかもしれません。とは言え昨日解読できなかった暗号が急に今日解読できる…と言うことはほとんどありません。暗号の専門家によりどの程度の期間で破られる恐れがあるかを推定しており、当面は簡単には破られる恐れのない推奨暗号があります。推奨暗号を電子政府向けに策定しているのが先のCRYPTREC電子政府推奨暗号リストです。政府向けですがもちろん民間でもその公開されている知見を利用すべきです。

 実は2022年7月に公開された電子政府推奨暗号リストではセキュリティ強度を現在の112ビットセキュリティからより強度が高い128ビットセキュリティに更新するスケジュールが記載されています。公開鍵暗号の暗号移行に関して言えば現在の112ビットセキュリティの例えばRSA 2048ビットは暗号/署名の利用が2030年末まで複合化/検証の利用が2035年末までとなっています(解釈違いはあり得ます)。「え?2030年末ってまだまだ先でしょ?」と思うかもしれませんが実は全然時間が無いのです。と言う話をしていきます。

過去の暗号移行(80ビット→112ビットセキュリティ)

 まず過去の暗号移行の例を見てみましょう。政府認証基盤(GPKI)について、80ビットセキュリティ(RSA 1024ビット/SHA-1)から112ビットセキュリティ(RSA 2048ビット/SHA-2)への移行が2008年に移行指針として公開されています。その時の資料(PDF直リンク)から移行スケジュール部を抜粋したのが以下となります。
image.png
 移行はフェーズ1~3までの3段階となっています。フェーズ3で移行完了となります。実はフェーズ3は実際には2019年8月でした。2008年に移行指針が示されたので実に11年もの時間がかかったことになります。

 この時の移行は暗号アルゴリズム自体はほぼ同じでした。RSA公開鍵暗号の1024ビットから2048ビットとハッシュアルゴリズムのSHA-1からSHA-2への移行です。

今回の暗号移行(112ビット→128ビットセキュリティ)

 CRYPTRECの暗号強度要件(アルゴリズム及び鍵長選択)に関する設定基準から抜粋すると以下となります。112ビットセキュリティの暗号方式に関しては既に「移行完遂期間」に入っていることが分かります。そして推奨に従うなら2030年末までに移行を終わらせる必要があります。
image.png
 これだけだとまだ7年もあるよね。と言う気になると思いますがデジタル署名だけではなくPKI(公開鍵基盤)まで考えると話が変わって来ます。デジタル署名では署名鍵(秘密鍵)と紐づいたX.509電子証明書を使います。素直に考えると112ビットセキュリティの公開鍵暗号(RSA 2048ビット)と紐づいたX.509電子証明書の有効期限は2030年末までと読めます。つまり新規発行するX.509電子証明書を考えると以下の式となります。

 2031年 - X.509電子証明書有効期間 = 新規発行期限

 例えば有効期間が5年のX.509電子証明書だと 2031-5=2026 となり2025年末までしか5年間有効のX.509電子証明書は発行できないことになります。今年が2023年なのでなんとあと2年と言うことになります。大変だ!

RSAかECDSAか

 移行先となる暗号方式が実は今回は2種類あります。前回の暗号移行同様にRSA公開鍵暗号の鍵長を単純に3072ビットに増やす道と新しいECDSA(楕円曲線)公開鍵暗号のP-256に移行する道です。
image.png
 PKIプログラマならお分かり頂けると思いますがソフトウェア的な観点ではRSA暗号の3072ビットに移行する方が簡単で楽です。

 ところがハードウェア的な観点になると話が違ってきます。皆さんがお使いのICカードのチップの中には公開鍵暗号を操作するチップが入っています。例えばマイナンバーカードには2種類のX.509電子証明書と紐づいた署名鍵が入っていますがこれは112ビットセキュリティのRSA 2048ビットのものです。PC等のコンピュータの性能は向上しているのですがICカードのチップの処理能力はそれほど向上していないのです。RSA公開鍵暗号は署名時の処理が重いアルゴリズムで鍵長が長くなると対応できなくなってしまうのです。前回の暗号移行時にもこの問題がありましたが何とかRSA 2048ビットには対応できました。ところが今回は正直厳しくなって来ているのが実情だと思います。

 ではECDSA(楕円曲線)暗号はどうでしょうか?ECDSAは鍵長自体が短く計算もRSA暗号よりは軽いと言う利点があります。もし今回の暗号移行でRSA 3072ビットを選択したとしてもその次の192ビットセキュリティだとRSA 7680ビットとなり利用は非現実的となると予想されます。つまりRSA公開鍵暗号の終わりが今回の暗号移行で始まってしまうと言うことになります。

 そう考えるとRSA 3072ビットはICカード等を使わないサーバー上のHSM等では良いかもしれませんが一種の保険と考えておき本来はECDSA P-256に移行すべきとも思えます。ただこれは各事業者が考えるべきことであって何か指針が出なければどちらを選んでも良いとは言えます。

耐量子計算機暗号(PQC)と言う選択肢

 一部の暗号エンジニアは「まてまて量子コンピュータが出てきているから耐量子暗号を選択すべきだろう!」とおっしゃると思います。もっともです。NIST(米国標準技術研究所)では過去のDES→AESやSHA-1→SHA-2→SHA-3のように米国の暗号標準を決めてきましたが耐量子暗号についても選定を進めており昨年候補として4つの暗号アルゴリズムを選定しました。

 ただ耐量子計算機暗号にはNISTでの選定が完了していない以外にも問題があります。現在候補となっている耐量子計算機暗号の多くは鍵サイズや署名値サイズが桁違いに大きいものが多いのです。つまりICカード化して一般利用されるまでにはまだ時間がかかりそうです。残念ながら間に合わない可能性が高いのです。

 また問題となる量子コンピューターが112ビットセキュリティのRSA 3072ビット/ECDSA P-256を解くにはまだまだ時間がかかると予想されていると言うこともあると思います。ちなみに2019年なので少し古いですが量子アルゴリズムでRSA暗号をどう解くのかを勉強してその結果を古典プログラマ向け量子プログラミング入門として公開していますのでご興味があればご覧ください。色々な見方があると思いますが私もこの資料中で説明していますが量子コンピュータが脅威になるにはどんなに早くても2040年以降になるのではと考えています。その頃には次の暗号移行のタイミングとなるのでそこで検討すればよいのかなと。

 一方でRSA公開鍵暗号やECDSA公開鍵暗号はスマホにも機能が搭載されているものもある等と既に利用が可能です。結論としては耐量子計算機暗号ではなくRSA公開鍵暗号やECDSA公開鍵暗号に移行すべきと考える方が自然ではないでしょうか。

今やらねばならぬこと

 まずはつらつらと現状を書いて来ましたが特にX.509電子証明書を発行するPKIの認証局と公開鍵暗号を使う暗号ハードや暗号ソフトを出しているベンダーはもう128ビットセキュリティへの移行は待った無しの状況です。もしまだ自分のかかわるサービスで移行計画が無いようでしたらまず検討を始めましょう。政府からも移行指針が出てくると予想されますがそれを待たずに検討を開始すべきです。CRYPTRECからは情報が出ているのですから。私も電子署名ライブラリを開発しているので自社製品の計画を立てています。まず自社製品の試験認証局については128ビットセキュリティ対応をしました。次はライブラリ本体のECDSA対応ですね!

暗号移行を前提とした設計をしましょう

 暗号を利用するシステムを設計する時には暗号アルゴリズムの移行が可能になるようにすべきでしょう。PKIのX.509電子証明書の有効性を確認するOCSPと言うプロトコルがありますが実はOCSPリクエストに埋め込むCertID(証明書ID)にはいまだにSHA-1が使われ続けています。これはCertIDにハッシュアルゴリズムのOIDを指定する仕様がないのでアルゴリズムの変更が指定できない仕様になっている為です。あとブロックチェー(銃声)

 例えば長期署名と言う仕様は暗号アルゴリズムの危殆化を前提とした仕様になっています。ご興味があれば記事 Re:ゼロから始める長期署名 を読んでみてください。

 暗号を利用するシステム運用をしているなら暗号移行時の手順は作成しておいた方が良いです。新しい解読法が見つかる危殆化は正直いつ生じるかわかりません。その時に慌てなくて良いようにしておきましょう。

終わりに

 電子署名の場合には署名者と検証者は別となります。ですので暗号移行は1社だけの問題ではなく業界全体として取り組まなければならない課題でしょう。私もその業界の片隅に生息しているプログラマですので協力して一緒に明るい明日を目指しましょう!

 最後になりますがこの記事はまず暗号移行についてのアラートを上げる為に書きました。書いている内容に間違いやミスがあればご指摘をお願いしますm(_ _)m

528
355
3

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
528
355