2023年6月12日～2023年6月18日に読んだ中で気になったニュースとメモ書き（TLSらじお*1第110回の原稿）です。
[HiCAとacme.shのRCE脆弱性]
こちらのツイートから。
中国のCA（というかリセラー？）「HiCA」の証明書発行プロセスにおいて、自動証明書発行プロトコル(ACME) にコード実行が埋め込まれるという問題があった模様。現在業務停止中
— Yurika (@EurekaBerry) 2023年6月13日
情報を拾い中なんだけど HiCAの担当者も含めインシデント報告が行われているここが追いやすいかなhttps://t.co/ND6vQxXPrl https://t.co/tdMfmtqNrZ
リンク先はこちら。
HiCAという中国のSSL証明書のリセラーが問題を起こした。親のルート認証局はSSL.comで、Macのルートストアであるキーチェーンにもルート証明書が入っている。
HiCAは、証明書の自動更新プロトコルであるACMEに準拠するために、acme.shのリモートコード実行(RCE)の脆弱性をうまく利用して、acme.shを実行するユーザーのマシンにコードを送り、ACMEに必要な処理を実行していたらしい。GitHubのissue上で紹介されていたツイートでは、実際にHiCAから送られたスクリプトの一部が紹介されていた（実際にはcurlが呼び出されるらしく、curlにロギング処理を挟んでスクリプトの中身を取得したとのこと）。GitHubのイシューや、Hacker Newsのスレッドなどを見ていても、悪意のある処理が実装されていた訳ではなく、単にお行儀のよくない実装だっただけ、という見方が多いように見受けられる。
Yep, this is the script they serve, and it did execute in my VM. pic.twitter.com/kTbzhiSGKY
— Aleksejs Popovs (@aleksejspopovs) 2023年6月8日
ACMEのプロトコルをきちんと理解していないが、本来はサーバとクライアントの両方が計算した結果を証明書更新対象のドメインの特定のパスに配置して、CAがそれを確認する、という流れが本来のもので、上述のスクリプトはこの計算処理をスキップしているため、ACMEのプロトコルに反しておりセキュリティ上問題がある、という話らしい。
ちゃんとしたACMEのプロトコルを実装すればいいのに...と思っていたが、HiCAは2023年6月6日に全てのサーバを停止したとのこと。RCEの問題もあるが、DDoS攻撃によるコスト増に対応するため、と主張されているが真偽は謎。
リセラーについてはAndrew Ayer氏が本件を受けてブログを書いていた。リセラーの標準的な定義がそもそもないこと、1CAのリセラーをしながら自社もCAである業者もいれば、複数のCAのリセラーをしている業者もいること、別のリセラー経由で証明書を提供するリセラーもいること、などなど。
普段自分があるサービスがCAなのかリセラーなのか、ほとんど意識していないが、新しいサービスを使うときは気をつけたほうがよさそう...。
New blog post: The Difference Between Root Certificate Authorities, Intermediates, and Resellershttps://t.co/UPtzzBg0mD
— Andrew Ayer (@__agwa) 2023年6月18日
HiCAの管理者とされるXiaohui Lam氏は過去にも色々悪いことをしているとの指摘もある。GlobalSignの認証局のシステムも被害にあったとか。
Drama continues in the WebPKI https://t.co/s14OS3z7Ru pic.twitter.com/XhRdDiIK6x
— Ryan Hurst (@rmhrisk) 2023年6月16日
[Google vs EU]
こちらのツイートから。
📝EUのトラストサービスのプロバイダーの組織 European Signature Dialog が Google の提唱する90日のshort-lived Certificateに対する懸念を、EU機関にむけて発信。https://t.co/bz7f9Gedf4
— Yurika (@EurekaBerry) 2023年6月13日
リンク先はこちら。
Googleの推進する90日の有効期間は、EUのQWACs証明書の標準の398日とコンフリクトし、ACMEを利用したDV証明書の利用を促進するものであり、EUの法規制eIDASが時代遅れになるのでは、と懸念しているらしい。
加えて、ドイツの独占禁止法関連の行政機関の調査によると、Googleの動きはドイツやEUの法令に違反するとして、これ以上証明書の有効期限を短くしないように、とGoogleに要求している。
個人的にはEU側の主張にあるように、ACMEを導入しない場合に証明書関連の仕事が4倍に増える点を懸念しているので、是非ともEU側に頑張ってもらいたいとも思う一方で、ACMEの使えるDV証明書でも別にいいんじゃないか...とも思えてきた。EUのデジタル主権を犯すな、というのもわからなくはないんだけど...。
CA/B ForumのBaseline Requirements変更までは影響はないかな、と思っていたけど、Googleがポリシー変更したらCAは追随せざるを得ない、という視点は自分に抜けていた...。
同時に、Google ルートストアのポリシーとして証明書発行CAに対して、発行する証明書を90日とするようポリシー変更も予定。
— Yurika (@EurekaBerry) 2023年6月13日
事実上商用CAはルートストアポリシーに従う必要があるので、CAB Forumでの採決の結果によらず、ルートポリシーが制定されれば90日が業界デファクトに。
どうなることやら。
[その他のニュース]
▼Certificate Lifetimes on Chromium
こちらのツイートから。
確かに、ChromeでもFirefoxでも別にブロックされない… > 有効期限が長いSSL証明書
— angel (as ㌵㌤の猫) (@angel_p_57) 2023年6月11日
ひょっとして、みかけの有効期限が1年強に切り詰められるのかな? と思ったけど、今度は開始・終了を調整して証明書を作る方法が分からない。作る瞬間だけPCの時間をいじればいい話ではあるんだけど、それもちょっと… https://t.co/Kd3lLj847H
オレオレ証明書や、個別にインストールされたルート証明書の場合、CA/B Forumの要求している証明書の有効期限398日は適用されない。
ということがChromiumのサイトに書かれていた。たまたまこの間別件で調べて読んでいたので紹介しておく。
This will only apply to TLS server certificates from CAs that are trusted in a default installation of Google Chrome, commonly known as “publicly trusted CAs”, and will not apply to locally-operated CAs that have been manually configured.
▼ECDSA署名の分析
こちらのツイートから。
ECDSA is cursed.
— Diego F. Aranha 🕷️ (@dfaranha) 2023年6月14日
#ePrint Limits in the Provable Security of ECDSA Signatures: D Hartmann, E Kiltz https://t.co/FHyHurIVf1
— IACR (@IACR_News) 2023年6月14日
リンク先はこちら。
TLSの証明書などで利用されているECDSA署名については、理想的なパターンではセキュリティが担保される、という結論になっているっぽい。
量子コンピュータの発展に伴って、2048ビットのRSA署名の利用期限が迫っていることを考えると、移行先のECDSAに不安があるって言われるのは困る...。
▼マルウェアとDNS over HTTPS
こちらの記事から。
プライバシーを高めるために発展した技術であるはずが、マルウェアの隠れ蓑になってしまうというのはなかなか皮肉...。
DoHのTXTレコードとかを通してマルウェアが実行するコマンドのやり取りをしてるって話は興味深い。
▼100量子ビットでの正確な計算
こちらのツイートから。
#ニュースリリース
— 日本IBM (@IBM_JAPAN) 2023年6月15日
IBMは、100超の量子ビット規模において、#量子コンピューター が古典アプローチを超える正確な結果を導き出せることを初めて実証しました。
詳しくはこちら🔗 https://t.co/bhcNbqamro pic.twitter.com/Wf0C4i9TNg
リンク先はこちら。
検証のために同時に実施した古典コンピュータによるシミュレーションは行き詰まってしまったが、IBMの127ビット量子コンピュータは正確な結果を出し続けた、とのこと。
ロードマップで言うと、2021年のEagleが改善したということの様子。着実にRSAの終わりに向かって近づいている気がする。
▼Kyber support on Chrome canary
こちらのツイートから。
Chrome CanaryにKyber来てた
— ゆき (@flano_yuki) 2023年6月16日
> TLS 1.3 hybridized Kyber support pic.twitter.com/eDWMmCawgM
https://t.co/entHFJunWd とX25519Kyber768Draft00で繋がってそ pic.twitter.com/EV6KdxhRnA
— ゆき (@flano_yuki) 2023年6月16日
IBMが量子コンピュータをすすめてる一方で、ブラウザ側もちゃんと対応をすすめてくれている。
EUはGoogleの動きを批判しているけど、総合的に考えるとGoogleのやってることのほうが良さそうに見えてくる。
▼ストリーム暗号のTMTO攻撃
こちらのツイートから。
Hidden Stream Ciphers and TMTO Attacks on TLS 1.3, DTLS 1.3, QUIC, and Signalhttps://t.co/XASiU3gaOu
— ゆき (@flano_yuki) 2023年6月17日
国際暗号学会（IACR）のペーパー
リンク先はこちら。
詳細をきちんと理解できていないが、TLS1.3で使われているChaCha20-Poly1305のストリーム暗号は、key updateを利用する場合に計画されたセキュリティレベルに満たない挙動になっているらしい。key updateを実施しないと言うことは、鍵交換をやり直すことになるはずなので、暗号処理のコスト的にはあまり好まれない気がする。
Time Memory Trade-Off（TMTO）攻撃は、ストリーム暗号の内部状態を特定し、それ以降に利用される秘密鍵を得ることができる。同種の攻撃にBabbage-Golićと言うのがあるが、これは事前計算と誕生日攻撃で確率を高めて狙う技らしい。
とまあ細かいところで色々勉強になりそうな論文だったが、一番印象に残ったのは、導入部分で触れられていた「NISTが2024年1月1日までにTLS1.3のサポートを（政府機関について）必須としている」という部分。確かに2019年のニュースに出ている。
日本のIPAが2020年に出しているTLS暗号設定ガイドラインをよく読むとちゃんとそのことに触れられていた。勉強が足りない...。
▼光ファイバー盗聴対策
こちらのツイートから。
「光ファイバーから盗聴なんてできるわけ無いじゃん！」という方に。
— かんべ (@KanbeWorks) 2023年6月17日
いくらでもやりようはあるんだねってことで。https://t.co/TinwKzQjqG
リンク先はこちら。記事自体は2017年のもの。
海外で、国防用の回線とかに利用されているらしい。なるほど〜。
https://t.co/NLkc3L7f5z
— かんべ (@KanbeWorks) 2023年6月17日
>通常、光ファイバーケーブルを通じて光信号を盗聴することは技術的に困難だとされている。
どこで「困難だとされている」のかはわからないんだけど、別に困難ではないよね。
「海底ケーブルの光ファイバーを直接盗聴する」ことについて、現実的な実現性の話ならともかく。
こちらは最近のニュース。穏やかじゃないなあ...。
▼OpenSSL 1.1.1のEoL間近
こちらのツイートから。
OpenSSL 1.1.1 End of Life Approaching https://t.co/Aq6w55DAYG
— Hacker News Bot (@newsycombinator) 2023年6月16日
リンク先はこちら。
LTSであったOpenSSL 1.1.1が2023年9月11日でサポート終了予定とのこと。
今後は3.1系が2025年3月14日まで、LTSの3.0系が2026年9月7日までサポートされるらしい。
[暗認本：09ビットと排他的論理和]
引き続き、ニュース以外のメインコンテンツとして『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』を読んでいく。
今週はChapter 3 共通鍵暗号から、セクション09をざっとまとめた。
- 1ビットの基本変換
- 1ビット：1か0
- 1ビット入力して1ビット出力する演算
- 恒等変換(a)：0 -> 0, 1 -> 1
- 否定(¬a)：0 -> 1, 1 -> 0
- 論理積と論理和
- 排他的論理和(a(+)b)
- どちらか片方のみが1のとき、1を出力
- 同じ値の排他的論理和は常に0
- 交換法則と結合法則
- 排他的論理和の重要な性質
[まとめ]
これまでに雑にまとめてきたニュースを、もう少しいい感じにまとめようと画策中です。
