なりすまし・フィッシングメール・偽サイトにご注意ください

RSA暗号を高速で解読できたらインターネットは終わるのか? | SSLサーバー証明書ならさくらインターネット

RSA暗号を高速で解読できたらインターネットは終わるのか?

先日「RSA暗号を高速で解読できるアルゴリズムを開発した」と主張する”未査読”の論文が発表され、SNS上で「RSA暗号」がトレンド入りする珍しい事態が起きました。今回は実際にRSA暗号を高速で解読できたら何が起きるのか?本当にインターネットは終わるのか?という点について考えてみましょう。

RSA暗号を高速で解読できたらインターネットは終わるのか?

RSA暗号とは?

RSA暗号(以下、RSA)とは、公開鍵暗号アルゴリズムの一つで、インターネットの世界では電子署名のアルゴリズムとして普及しており、一番身近な利用例にSSLサーバー証明書(以下、SSL証明書)があります。

SSL証明書においてRSAは「ドメイン認証」を行うために広く利用されています。例えば、「本当にアクセス先のドメインが、ブラウザのアドレスバーに表示されているドメインと一致しているか?」を確認するために使われています。いわゆる「なりすまし防止」です。しかしながら、SSL証明書を利用した暗号化通信には他にも様々な暗号アルゴリズムが使われており、RSAだけが暗号化通信の全体を担っているわけではありません。

また、ドメイン認証は「電子署名」によって支えられています。SSL証明書は第三者機関である「認証局」が申請者に対して「本当にドメインを所有しているのか?」という確認を行い、確認できた場合にそのお墨付きを「電子署名」によって行います。ここにRSAが使われています。

ドメイン認証について詳しく知りたい方は『なぜSSL証明書の発行は失敗するのか?~ドメイン認証の落とし穴~』にて説明していますので、ぜひご覧ください。

RSAは解読できるのか?

年単位の時間をかければRSAの鍵長(2048bit)を総当たり計算して解読できる可能性はありますが、数分で解読することは現在のコンピューターでは不可能です。もし量子コンピューターが実用化された場合、RSAは脆弱になると言われていますが、この量子コンピューターでも現実的な早さで解読できるまでには至っていません。

現在の一般的なRSAの鍵長は2048bitですが、そもそも何故2048bitなのでしょうか?実は、暗号アルゴリズムの最適な鍵長は「コンピューターの性能がムーアの法則に従って進化する」という前提で決められています。

つまり、ある日突然に数十年分くらい一気に進化した高性能なコンピューターが発明されるか、現在のコンピューターでもRSAを高速で解読できるプログラムが開発されない限り、RSAを現実的な早さで解読することは不可能とされています。もしそれらが本当に実現すれば、RSAは脆弱になると言えるでしょう。今回SNS上で話題になったのは後者の「高速で解読できる理論」になります。

知っておきたい鍵長の意味

さくらのレンタルサーバでは秘密鍵を生成する際に2048bitの鍵長を選択しますが、この鍵長(暗号鍵のデータ長)とは一体どういうものなのでしょうか?簡単に説明すると、パスワードの長さと同じように長ければ長いほど暗号強度は上がりますが、パスワードと違うのはデータを復号するときも鍵長が長い(データが大きい)ほど復号に時間が掛かります。つまり、鍵長が長いほど暗号強度は上がりますが、利便性は下がってしまうのです。

様々な暗号アルゴリズムで秘密鍵、共通鍵といった鍵が使われていますが、暗号アルゴリズムごとに「適した鍵長」は異なります。これは「等価安全性(equivalent security)」と呼ばれ、暗号アルゴリズムごとに2030年までは2048bit、2050年までは3072bitと言った具合に年代別で決められています。

「鍵長が長いほど安全だが、復号時の負荷などを考えても2030年くらいまでのコンピューター技術であれば2048bitでもリスクは低いだろう」という風にコンピューター技術の進化を計算に入れて決められており、その結果RSAの鍵長は2048bitが現在の主流となっています。

稀に4096bitや3072bitの鍵長で生成したCSRでSSL証明書を購入しようとする方もいますが、認証局によっては最大鍵長が2048bitに制限されている場合もあり、さくらのSSLでも2048bitに制限しています。

RSAが解読されたらインターネットは終わるのか?

前述の通り、ドメイン認証は「電子署名」によって支えられており、そこにRSAが使われています。つまり「本当にアクセス先のドメインが、ブラウザのアドレスバーに表示されているドメインと一致しているか?」という確認に使われており、確認できればドメインが一致することを保証してくれます。裏返すと、もしRSAの信頼性が無くなれば「アクセス先のドメインが、ブラウザのアドレスバーに表示されているドメインと一致するかわからない。保証されても信用することができない」状態になります。

現在SSL証明書による暗号化通信は、金融機関やECサイトではほぼ100%利用されていると言っても過言ではない状況です。もし、これらのサイトへ正常にアクセスしていたつもりが、本当は悪意のある第三者によって偽装されたサイトにアクセスしていたとしたらどうでしょうか?きっと暗証番号やパスワードなどの情報を窃取され、悪用されてしまうに違いありません。

もし秘密鍵が危殆化した(流出、もしくは解読可能になった)場合は「24時間以内にそのSSL証明書を失効処理しなければならない」と業界団体※によって定められており、これまでも個別のサーバーに対して発行されたSSL証明書が失効処理されたことがあります。

  • ※業界団体=CA/Browser Forum(CAブラウザーフォーラム)

ただし、RSA自体が脆弱になった場合はルート証明書も再発行しなければなりません。過去にもルート認証局から秘密鍵が流出し、Windowsアップデートなどでルート証明書を削除するといった事象が起きたこともあります。もしRSAを利用する全ての通信の信頼性が無くなった場合、Windowsアップデートで取得するファイルの正当性すら保証されなくなる可能性があります。

他にもメールの送信者を認証する(送信者のなりすましを防止する)S/MIME証明書や、ソフトウェアの作成者を認証する(作成者・配布元のなりすましを防止する)コードサイニング証明書、さらには電子契約時の電子署名などでもRSAは利用されており、影響範囲を考えれば考えるほど頭が痛くなってきます。

さらに、サーバーへのログイン認証に利用するSSHにおいてもRSAの鍵がよく使われています。もしこれらが全て脆弱になってしまったら、サーバーの安全性すら脅かされてしまうでしょう。これでは本当にインターネットが終わってしまうかもしれません。

代替手段は無いのか?

RSAが使われているドメインの認証には、別のアルゴリズムであるECDSA(ECC:楕円曲線暗号)も利用可能です。RSAよりも解読に強く、相対的に短い鍵長(384bit)で利用できるためCPU負荷が低くパフォーマンスも優れています。しかしながら、利用できるSSL証明書のブランドが少ないこともあり普及が進んでいません。無料のLet's Encryptと一部認証局の有料SSL証明書でのみECDSAが利用可能※です。

  • ※ECDSAの利用にはOSやブラウザ側でも対応が必要ですが、現在では無視できるぐらいになってきました。多くのパソコンやスマートフォンは問題ありませんが、ちょっと古いゲーム機などには対応していないこともあります。

もちろん、RSAを使って発行・署名されたSSL証明書をそのままECDSAで利用することはできないため、ECDSAを利用できるSSL証明書に発行し直す必要があります。さくらのレンタルサーバでもCSR作成時はRSA 2048bitで秘密鍵を生成するため、ECDSAでの生成には対応しておりません(もし対応する場合はシステム改修が必要になります)。

SSL証明書ではRSAとECDSAのように「1つの役割に2つ以上のアルゴリズム」が使えるようになっていますが、このような有事の際に補完するための意味合いも含んでいます。「ドメイン認証」におけるRSAとECDSAの他にも、「鍵交換」におけるECDHEとDHE、「暗号化通信」におけるAESとCHACHA20などがあります。

上記の中でドメイン認証以外はSSL証明書に依存せずサーバー側の設定のみで変更することが可能ですが、ドメイン認証だけはSSL証明書に電子署名されている都合上、アルゴリズムを変更するにはSSL証明書を発行し直す必要があります。

さらに大きな問題になるのは、PCやスマートフォンにインストールされているルート証明書もRSAを利用しているため、Windowsアップデートなどでルート証明書を入れ替える必要があります。しかし、そのWindowsアップデートにもRSAが利用されており……はい、どんどん頭が痛くなりますね。

想定外の事態に備えておこう

今回の件は論文の内容が再現できたわけではないため、今のところ実効性は低いと思われます。突然RSAが使えなくなる!という事態が訪れる可能性がゼロでは無いですが、極めてレアケースであると考えて大丈夫でしょう。

しかしながら、これまでもSSL業界においてはSHA-1ハッシュアルゴリズムの脆弱性対策のためにSSL証明書の入れ替えが行われたり、脆弱性が発見されたことによって推奨プロトコルの変更勧告などが行われてきたりしました。また、セキュリティインシデントによる再発行なども近年増加しています。

こうした想定外の事態に備えて「SSL証明書は有効期間を満了する前に使えなくなる可能性がある」という前提でシステムを構成する必要があります。レンタルサーバーの運用担当者はSSL証明書の入れ替え方法をチェックしておくことをおすすめします。

特に最近では、SSL証明書の設定を外注しているため入れ替えの度にお金が掛かったり、業者の人がSSLに詳しくないので入れ替えができなかったりするケースが非常に多く発生しています。外注せずとも簡単に入れ替えられるような仕組みにしてもらうのも手段の一つですので、入れ替えに不安のある方はぜひ検討してみてください。

こちらの記事もあわせておすすめ!

暗号解読に興味のある方は、量子コンピューターによる暗号解読とその対策を取り上げた『あと数年で量子コンピューターにSSL通信が解読される?SSL/TLSの未来を担うPQCとは?』がおすすめです。SSL証明書におけるドメイン認証の仕組みを知りたい方は、PKIによる信頼の連鎖などを扱った『サーバー証明書/中間CA証明書/ルート証明書の違いとは?』がおすすめです。

データ読み込み中...