先週に続き、2022年5月9日~5月15日に読んだ中で気になったニュースとメモ書き(TLSらじお第56回の前半用原稿)です。
[耐量子暗号とNSA]
こちらのツイートから。
IBMが4000量子ビット超え量子コンピュータを2025年に! by Yuichiro Minato | blueqat https://t.co/cFJufqT1K8
— blueqat (blueqat.eth) (@blueqat_os) 2022年5月10日
元記事はこちら。
Quantum Serverlessなんてのも計画されているのか...。
量子コンピュータ関連で言うと、NISTの耐量子暗号の評価ラウンドが進んでいる。何も考えていなかったが、最近読んだ『プロフェッショナルSSL/TLS』第7章の終わりには、NSAによるバックドア事件が説明されていたことを考えると、耐量子暗号にもバックドアがある可能性を捨てきれないように思う。
最近のニュースではNSA自身は否定しているが、Redditでは「ダウト」、「Bullrunで信頼できなくなった」、「バックドアじゃないならフロントドアだろ」といったコメントが並んでいる。同感。www.msn.com
Nature誌には耐量子暗号への移行に関する論文が掲載された。暗号化されたデータを現在時点で保管しておいて、量子コンピュータが一般化した時点で復号するというタイプの攻撃を考えると、やはり早期に移行計画を立てる必要がありそう。
Great paper on transitioning to post-quantum cryptography by @marcmanzano and many others! https://t.co/h56agE3zfL
— sofía celi (@claucece) 2022年5月11日
[SSL Pulse更新再開]
こちらのツイートから。
気づかなかったよ。SSL Pulseが1月から4ヶ月ぶりに更新されとった。https://t.co/FMYDMrf93x
— kjur セキュリティ IT 開発の私的情報収集用+少しつぶやき (@kjur) 2022年5月12日
2022/05/07版が公開されている。
合わせてSSL Pulse Trendsも更新された。
SSL Pulse Trends 2022年5月分のアップデートを反映しました。https://t.co/xk2sjKutB8#sslpulse
— kjur セキュリティ IT 開発の私的情報収集用+少しつぶやき (@kjur) 2022年5月12日
本家が1月から4ヶ月の空白を経て帰ってきました。よかった、よかった。
[Certainly始動]
こちらのツイートから。
The Certainly R1 and E1 Root Certificates have been approved for addition to the NSS Root Store: https://t.co/dGHZcGdPlb
— Scott Helme (@Scott_Helme) 2022年5月12日
The GoDaddy cross-signing of the Certainly Intermediate Certificates has also been approved: https://t.co/bNjoGg53nz
— Scott Helme (@Scott_Helme) 2022年5月12日
2022年3月14日のニュースで取り上げた、Fastlyの新ルート認証局Certainlyに関する続報。MozillaのNSSルートストアにCertainly Root R1とCertainly Root E1の2つのルート証明書が追加されたらしい。ルート証明書とはいえ新参者なので、GoDaddyが中間証明書にクロス署名をしている。
EとRって何だろう?と思ってリポジトリから証明書をダウンロードしてみたら、Elliptic CurveとRSAの略であることがわかった。秘密鍵がどちらか、ということらしい。ルート証明書は2046年、中間証明書は2031年まで有効とのこと。
crt.sh | certainlyを見るに、2022年5月16日現在ではまだサーバー証明書などはCTログに残る形では発行されていないようだ。
[その他のニュース]
▼RFC5280とRFC6816
こちらのツイートから。
RFC 5280はRFC 6818でアップデートされてたの気が付かなかったよ。でも6818には大したこと書いてなかった。証明書ポリシのexplicitTextとか自己署名証明書の扱いとかセキュリティ考察とかSANの国際化ドメイン名とかhttps://t.co/r8shzEMkW8
— kjur セキュリティ IT 開発の私的情報収集用+少しつぶやき (@kjur) 2022年5月11日
それぞれのRFCは以下。どちらもX.509証明書とCRL(証明書失効リスト)に関するもの。
去年(2021年)、『プロフェッショナルSSL/TLS』を読みながら関連する新しいRFCは調べていたつもりだったけど自分も見逃していた。
大したこと書いてないと言われても、元をあまり理解していないので難しい...旧版との差分の箇所がテキスト左端の「|」記号で明示されているのが救いか。
▼図解RSA公開鍵
こちらのツイートから。
RSA公開鍵暗号って何?を図解してみました。
— アイデアマンズ@フロントエンドWeb高速化 (@ideamans) 2022年5月10日
最初は「公開鍵ってなんだよ、鍵を公開しちゃ意味ないじゃん」と困惑したものでした。鍵じゃなくて錠だと教えてくれたらわかりやすかったのに、という思いを込めました。いかがでしょうか。https://t.co/aRa6QBhmb5 pic.twitter.com/Sr8cYphupS
わかりやすい気もするけど、こちらの返信にもあるように、ちょっと違うといえば違うか。
「錠」と表現するのは「鍵」という単語の理解を阻むだけで、言ってみれば問題の先送りです。止めたほうが良いと思います。
— angel (as ㌵㌤の猫) (@angel_p_57) 2022年5月11日
※公開鍵という用語はデジタル署名でも使うのですが、それはどうするんでしょう、と。
公開鍵秘密鍵それぞれ用に2つ鍵穴のある錠前、みたいなのを考えるのはアリかも。
▼CVE-2022-23649
こちらのツイートから。
Cosignそのものの脆弱性。ctに存在しないはずの署名と偽ることができた。ちょっと古め #転記 https://t.co/LPHl7pzaBm
— ken\d|\x (@ken5scal) 2022年5月11日
Cosignというのはコンテナの署名や検証を行うOSSらしい。署名イメージに特殊なアノテーションを付与することで署名検証の一部をパスできる脆弱性があったらしい。
親プロジェクトのsigstoreもちょっと気になるかも。
▼CVE-2021-28165
こちらのツイートから。脆弱性自体は2021年4月のもの。
🚨 NEW: CVE-2021-28165 🚨 In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and 11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a large invalid TLS frame. Severity: HIGH https://t.co/DE2pwEXo3Y
— Threat Intel Center (@threatintelctr) 2022年5月12日
JavaのWebサーバJettyで17408バイト以上のTLSフレームを受信した場合に、CPUが100%に張り付いてしまう問題があったらしい。
CPU 100% receiving an invalid large TLS frame · Advisory · eclipse/jetty.project · GitHub
17408バイトというのは、TLSレコードプロトコルのプレーンテキストのサイズ2^14(=16384)よりも1024バイト多い計算になるが、どういうバグだったんだろうか...。
▼AES-1024
こちらのツイートから。
Practical bruteforce of AES-1024 military grade encryption https://t.co/xxWI0Yh2Y9
— Nicolas Krassas (@Dinosn) 2022年5月12日
本来、AESは128ビット、192ビット、256ビットの鍵サイズしかないが、1024ビット版もあるのか?と思いきや、どうやらそういう話ではないらしい。勝手に暗号アルゴリズムを作るのはよくないよ、ということか。
[まとめ]