気が付けば5月(執筆中)。前回の記事を投稿してからひと月が経過していました。
気が付けば新人が入ってきて、気が付けば梅雨が始まろうかと言わんばかりの季節に。 私が気が付かないのか、世界が気づかせてくれないのか。どうもエンジニアTです。
戯言もほどほどに。
前回は「ざっくりと従来の暗号技術を把握」したので、その続きとして「最近、(TLSで)ハイブリット暗号方式が使われないらしい」ことについてざっくり紹介したいと思います。
↓↓↓前回記事↓↓↓ tech.kentem.jp
RSAが抱える脆弱性
これまで強力な公開鍵暗号方式として知られていたRSA暗号方式ですが、近年、 前方秘匿性の観点 から暗号化通信(TLS1.3)で使われなくなりました。
前方秘匿性とは
簡単にいうと「 もし開ける鍵🔑(秘密鍵)がバレちゃったとき 」に関する話のことです。
もし開ける鍵🔑が第三者にバレてしまうと、現在～未来で送受信するメッセージは攻撃者に復号される危険性があります。
しかし、前方秘匿性がある暗号化技術を使っていれば、少なくとも 過去にやり取りしたメッセージだけは防御できる という性質を持ちます。
実は、RSA暗号を使ったハイブリット暗号方式はこの性質を持っていません。
RSA暗号を使ったハイブリット暗号方式を考えてみましょう。
AさんとBさんはオンラインフリーマーケットアプリで商品を売買するやり取りをしています。 この通信に、悪意ある攻撃者Cさんが目をつけ、AさんとBさんの通信を長期間にわたって傍受し続けます。
Cさんが傍受した通信には暗号化済みの暗号鍵とメッセージが含まれていますが、この時点ではCさんに解読されません。 とりあえず片っ端からストレージに保存し続けているだけです。
それから数カ月が過ぎ、、 ある日、CさんはBさんの開ける鍵🔑を何かしらのルートで盗むことに成功しました（したとします）。
開ける鍵🔑が盗まれてしまえば、ストレージに貯めたログから暗号鍵が解読され、メッセージも芋づる式にバレバレです。
前方秘匿性を得るには
実は前方秘匿性を担保する方法はシンプルです。 開ける鍵🔑（対になる閉じる鍵🔒も）を 頻繁に作り直せばいい のです。
開ける鍵🔑・閉じる鍵🔒が短時間で変われば、過去の暗号鍵は復号できません。
しかし、RSA暗号はこれができません。
ざっくり説明すると、RSA暗号は大きな数字での素因数分解がめっちゃ難しい特性を活用しています。 大きな数字(600桁以上)を扱うため鍵の生成コストが高く、頻繁に鍵を作り直すようなことはしたくありません。
それに加え、閉じる鍵🔒はインターネットに公開している関係で「本当にBさんの閉じる鍵🔒なの？」を保証する証明書を第三者機関(認証局)から発行してもらっています。
閉じる鍵🔒を頻繁に作り変えるような真似をすれば、その度に証明書を発行させられる認証局は・・・気が狂うことでしょう。
こういった背景から、RSA暗号を使ったハイブリット暗号方式は使われなくなりました。
この世界の限界
ハイブリット暗号方式が使えないなら何を使えばいいのでしょうか。
正直、手軽に使えるRSA暗号が使えないことは痛手です。 素因数分解問題のように都合のいい数学はあるでしょうか。
実際のところ、私たちが普段扱う数字の中では、いくつかそういった問題はあります。
しかし、扱う値が大きすぎたりと、鍵を頻繁に作り直すには不向きです。 やはり、私たちが普段扱う数字の中ではピンとくるものはありません。
私たちが普段扱う数字の中では。
そういうことです。 RSA暗号から脱却するために、ここからは 異世界（楕円曲線上）の数字の力 を借ります！
・・・安心してください。 そこまで難しくならないよう努力しますので・・・
楕円曲線上の世界
楕円曲線上の世界と言われてもイメージしづらいですよね。 簡単にいうと、楕円曲線という 曲線の上に存在できる数字（点）のみの世界 です。
なので、不用意に「4」とかいうと、そんな数字（点）は存在しません(404NotFound)と怒られます。
そんな異世界であるここには、私たちの知る数字の法則と違うルールがあります。
関係のある3つだけ紹介します。
楕円曲線上のルール
- この世界の数字は点と呼ぶべし。
- 点同士の演算法則は 足し算（引き算）のみ 。点Gをk回足し合わせると「kG」と表す。（あくまで足し算であることに注意)
- 足し算（引き算）したあとは、 元に戻すのが難しい。 （楕円曲線離散対数問題）
とまぁ、こんな風に 足し算（引き算）しかないクセ強な世界なわけですね。
それに、この
足し算（引き算）したあと、元に戻すのが難しい
というルール。
ひじょーーーに匂います。最高に鍵に使えそうな匂いがします。
そんな足し算しか使わない世界なら、 簡単で強力な鍵が作れそうですねぇ。
楕円曲線上の世界で鍵を作る方法
では、実際に鍵をつくってみましょう。
- まず、楕円曲線上の（どっかから）点Gをとってきます。
- そのGにa回足し合わせた「aG」と、b回足し合わせた「bG」を用意します。
- 用意した2つに対し、「aG」にはさらにb回の足し算、「bG」にはa回の足し算をします。
- そうすると「abG」という共通の点が得られます。
さあ、どうですか？ 結果はどちらも「abG」となりました。
この「abG」を 暗号鍵として使えば 、AさんとBさんの間で鍵を渡せそうじゃないですか？
AさんとBさんにそれぞれ、aとbを生成してもらい、暗号鍵「abG」を作ってもらいましょう。
おぉ、いけそう！！ 無事、暗号鍵「 abG 」を入手できました！
ですが、 ここまで読んだ皆さんなら気になるでしょう。
「aGとbGはバレてるけど大丈夫なん？？」
はい、大丈夫なんです。
ここで効いてくるのが、 ルール3 足し算（引き算）したあと、元に戻すのが難しい なわけです。
インターネットに公開された「aG」と「bG」から暗号鍵を求めようとすると、
- それぞれ「aとG」、「bとG」に分解
- 「Gをa回足し合わせて、さらにb回足し合わせる」ことでabGを作る
必要があります。
しかし、分解する時点でこの性質に引っかかるので、aGとbGからaとbを求めることは非常に困難です。
ちなみに、この性質がどれほど難しいかを説明するには私の数学的能力は足りません。本稿での理解は諦めましょう。
とりあえず、 aGとbGからaとbはバレづらい と覚えてくれたら100点です。
前方秘匿性は？
あ、忘れてましたね。 この性質を求めてこの世界に来たのでした。
この世界の暗号鍵の作り方だと、前方秘匿性はすぐに担保できます。
結論からいうと、 aとbを使い捨てればいい わけです。
先ほどのAさんとBさんの通信に注目してください。
Aさん、Bさんのお二人とも自分でaとbを作っています。 それどころか aとbは ランダムな数字です。
よって、Bさんの持つbがバレてしまっても、通信の度にランダムな整数(図でいうとe、r、kなど)に生まれ変わるので、過去の鍵を開けることはできません。
TLS1.3でやっていること（ECDHE鍵交換）
とまぁ、強引に楕円曲線上の世界の話を持ち出しましたが、 現在の暗号化通信規格TLS1.3では、この楕円曲線上の世界の暗号鍵を使ったECDHE鍵交換（楕円曲線DHE暗号）が使われています。
ただ、現実の世界でいちいち楕円曲線上の世界を計算するのは面倒なので、簡略化のため 点Gをあらかじめ決めておき、全世界の人が共通で使おうね！。 といった工夫がなされています。
共通にして大丈夫？と思うかもしれませんが、全く問題ありません。
鍵が安全な理由は、aGをaとGに分解するのが難しい（Gが分かってもaがわかりづらい）からです。
aがバレなければ点Gはどうでもいいのです。
ECDHE鍵交換の簡略図
だいぶ簡略化していますが、実際のTLS1.3もこのような通信をおこなっています。
詳しく言うと、他の楕円曲線も使えるよっていうリストを送っていたり、中間者攻撃対策の署名などの話もありますが今回はカットです。機会があれば紹介致します。
ということで、全2回で「最近、暗号化通信がちょっと変わってたよ」という話を長々とさせていただきました。
ここまで読んでくださった方はありがとうございます。 ここだけ読んでいる人もお疲れ様です。
次があればまたよろしくお願いします。
それではまた。
引用文献
- herumi. TLS 1.3 の鍵交換と暗号方式. Zenn, 2022年5月29日.
- lemiyachi. 暗号プロトコル入門 〜 TLS 1.3 を例に〜. Qiita, 2021年8月15日.
- lighthawk. TLS1.3の暗号方式を読み解く. Zenn, 2021年3月17日.
- 情報処理推進機構 (IPA). 暗号技術に関する安全性評価のためのガイドライン 第3.1.1版, 2022年3月.
- Wikipedia. ファイル:Secp256k1.png. ウィキメディア・コモンズ, 最終更新 2023年9月2日閲覧.
おわりに
KENTEMでは、様々な拠点でエンジニアを大募集しています！ 建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。 recruit.kentem.jp career.kentem.jp
