2023年11月6日~2023年11月12日に読んだ中で気になったニュースとメモ書き(TLSらじお*1第131回の原稿)です。
全文を公開している投銭スタイルです。
[IETF 118]
こちらのツイートから。
IETF 118 はじまったよー!TLS WGのミーティングから!https://t.co/NQFs1AmA5A
— ゆき (@flano_yuki) 2023年11月6日
リンク先はこちら。
https://datatracker.ietf.org/meeting/118/materials/agenda-118-tls-03
IETF 118が2023/11/06に開催されたとのこと。Encrypted Client HelloにCompact TLSのほか、KyberベースでのTLSでの認証、TLS Trust Expressions、TurboTLSといった、本ブログでも過去に取り上げたドラフトの話が盛りだくさん。
クライアント証明書を利用したTLS1.3への移行の障害になっているレガシーな署名アルゴリズムRSASSA-PKCS1-v1_5を復活させるドラフトが。そんな問題があったのか...。
TLS Flagってなんだっけ...と思ったら昔調べてた。そのフラグの、mTLS(相互認証)専用のフラグのドラフトが出ている。mTLSといえば...と思いながら著者を見るとやはりCloudflareの所属だった。
TLS Key Share Predictionなんてドラフトもある。耐量子暗号アルゴリズムの追加も見越して、TLS1.3での鍵共有がうまく動作するように曖昧さをなくすためのものらしい。DNSで鍵共有に関する情報を伝達する方法も定義しているとか。
他にもこんなドラフトが取り上げられていた様子。
[eIDAS 2.0と消極的なCAの歴史]
こちらのツイートから。
Many misunderstandings surround WebPKI. A significant misconception is that the CA/Browser Forum (CABF) decides which Certificate Authorities (CAs) are trusted; in reality, each browser has its own trust criteria, usually including an audit to ensure CAs meet the CABF's…
— Ryan Hurst (@rmhrisk) 2023年11月6日
For the European CAs poised to argue that the EU's Accredited Conformity Assessment Bodies (CABs) prevent abuse in the post-DigiNotar world. I would ask you for cases where they have caught and expelled misbehaving CAs and more generally I would ask you to consider the…
— Ryan Hurst (@rmhrisk) 2023年11月6日
以前軽く取り上げたが、EUが提案しているeIDAS 2.0という規制で、ブラウザの有能なルートプログラムに取って代わろうとしており、Webで利用される証明書のオープンさに影響するのでは、という話。
加えて、そうしたオープンさを支えてきたのは認証局ではなく、ブラウザの方だった、と。長文なのでポイントと思われる部分を書き出しておく。
個人的に気になったのは「Then there is the topic of Certificate Transparency -- is it required by the CABF guidelines? No, it is not」という部分。そういえばChromeがそのシェアを背景にCTを進めていった歴史はなんとなく知っているものの、CA/B Forumのなんらかの文書にはCTが定義されているものと思っていた...。
やはりどこかでBaseline Requirementsとかじっくり読みたいところ。
eIDAS 2.0についてはMozillaやGoogleも懸念を示している。
お!
— Yurika (@EurekaBerry) 2023年11月6日
Mozillaが"security risk ahead" と銘打ち、ブラウザのセキュリティリスク低下の懸念表明していた eIDAS article 45 適格証明書 (Qualified Web Authentication Certificates (QWACs)
Google も懸念のレターを発表
Qualified certificates with qualified riskshttps://t.co/gGQE3M5Xbb
何が懸念なのかというと、
— Yurika (@EurekaBerry) 2023年11月6日
・ブラウザがどのCAを信頼するかは、長年のwebPKIで起きた事件などを踏まえ、独自の厳格な審査や維持ルールがある
・しかし、eIDAS article 45 により、適格証明書QWACs の発行CAを、ブラウザで信頼されるCAとして登録しなければならなくなる
・そうすると、これまでよりもセキュリティ基準の低いCAを、信頼するCAとして受け入れることになる。
— Yurika (@EurekaBerry) 2023年11月6日
・ブラウザでどの証明書/CAが信頼できるのか、はブラウザの信頼CAのリストにかかっており、結果として、ユーザーが 信頼の低いCAよってもたらされるリスクを受け入れることにもなる
ブラウザベンダ側が懸念するリスクについては、Mozillaのキャンペーンサイトにまとまっています
— Yurika (@EurekaBerry) 2023年11月6日
Security Risk Aheadhttps://t.co/pKHiBPT3SI
日本語の記事も出ていた。
国民の暗号化された通信内容を政府が傍受可能にする条文がEUの新たな標準規則「eIDAS 2.0」に盛り込まれようとしているhttps://t.co/dvTF3rKSm7
— GIGAZINE(ギガジン) (@gigazine) 2023年11月9日
[その他のニュース]
▼[広告] TLS季報 vol.1発刊
こちらのツイートから。
#技術書典 審査通ってた!
— KIDANI Akito (@kdnakt) 2023年11月10日
いろいろ間に合ってないですが、ご笑覧ください🙇
TLS季報 vol.1:kdnakt https://t.co/J5CzGhYM7T
なんとか滑り込みました。よろしくお願いします(無料です)。
▼AreionとWebRTC
こちらのツイートから。
SRTP と DTLS で利用できるようになったら、かなり大きいと思う。リアルタイム通信のボトルネックは暗号処理なので ... 。 https://t.co/i0Awe1PFgC
— V (@voluntas) 2023年11月6日
Secure Real-Time Protocolというのがあるらしい。自分はDTLS側を全然追いかけてないだけあって、
知らない用語ばかり...。
▼TLS1.3の隠しストリーム暗号とTMTO攻撃
こちらのツイートから。
Hidden Stream Ciphers and TMTO Attacks on TLS 1.3, DTLS 1.3, QUIC, and Signal https://t.co/D7KVoTNE6v
— Frank ⚡ (@jedisct1) 2023年11月6日
リンク先はこちらの論文。
ストリーム暗号には元々TMTO攻撃(Time Memory Trade-Off)というのがある。名前がなんか凄そうだけど要は効率的に暗号鍵を探すことができる、と。
で、TLS1.3にはハンドシェイク後にKeyUpdateメッセージを利用して、暗号鍵を更新する仕組みがある。これが同期的なストリーム暗号の一種とモデル化することができるので、TMTO攻撃が成立する余地がある、と。
やっぱり新しいハンドシェイクで新品の鍵を手に入れるのが一番安全なのかな...。
▼Quantum Safe Journey
こちらのツイートから。
量子コンピューターが広く実用化された時代に備えて、耐量子暗号を利用するなど、"Quantum Safe" なシステムへ移行準備していきましょう!
— Yurika (@EurekaBerry) 2023年11月6日
ということで、影響の評価からまずは始めませんか
Starting your journey to become quantum-safehttps://t.co/kKJJLaMkQn
リンク先はこちら。
そういえば考えたことがなかったのだけど、量子コンピュータで破られる可能性のあるRSAや楕円曲線暗号のような公開鍵暗号と違い、AESとかSHAといった対称鍵暗号は(現実的な時間では)破られないらしい。それでNISTが出してる候補がKEMとデジタル署名なのか。
関連してこんなツイートも。Kyber512はAES-128よりも攻撃にコストがかかる(≒安全)ということらしい。
new blog and a post on the security of Kyber512: https://t.co/4qZN2kebmm
— John Schanck (@susurrusus) 2023年11月10日
▼AzureのTLS1.3サポート
こちらのツイートから。
📝 Web Apps, Functions, Logic Apps もTLS1.3サポートが始まるよ
— Yurika (@EurekaBerry) 2023年11月6日
Upcoming TLS 1.3 on Azure App Service for Web Apps, Functions, and Logic Apps Updatehttps://t.co/hjFHwbGNLR
リンク先はこちら。
2023年10月からTLS1.3が使えるようになってきているらしい。AWSがALBでのTLS1.3サポートしたのも最近だったからそんなもんなのかもしれない。
ところで、こういう時にTLS1.3が使えるという場合、どこまでを指すんだろう...TLS1.3のRFC 8446に含まれないEncrypted Client Helloとかは使えたりするんだろうか?
▼RFC 9460 SVBC and HTTPS RR
こちらのツイートから。
DNSのHTTPSレコードの仕様がRFCになった!めでたい https://t.co/rENM0M6WxE
— ゆき (@flano_yuki) 2023年11月7日
リンク先はこちら。
詳細は以前ゆきさんがブログにまとめてくれている。
▼Chrome 2023 Q3 Security Update
こちらのツイートから。
Chromeの2023 Q3セキュリティトピックまとめ
— ゆき (@flano_yuki) 2023年11月8日
- TLS post-quantum
- HTTPSアップグレード
- COOP restrict-properties
などhttps://t.co/dGhso1jNkR
リンク先はこちら。
ECHはfully launchedと言われているが、手元のWindows環境でChrome 119からCloudflareのテスト用サイトに繋いだ時もSNI情報の暗号化結果はfalseになっていた気がするのだが...バージョンが古いのだろうか?
[暗認本:30 サイドチャネル攻撃]
引き続き、ニュース以外のメインコンテンツとして『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』を読んでいく。
今週はChapter 5 認証から、セクション30をざっとまとめた。
- 電力解析攻撃
- コールド・ブート攻撃
- メモリは電源を切っても数秒は内容を保持している
- メモリを一気に冷却すると上記の保持期間を延ばせる
- これを利用して強制再起動時に秘密情報(BitLockerのパスワードなど)を抜き出せる
- 2018年当時の多くのノートパソコンが脆弱
- 再起動時にPINを求める設定にするなどで対策可能
[まとめ]
技術書典で疲れたから今週のニュースは少なくしようと思ったのに、結局6000字弱になってしまった...。
※以降に文章はありません。投銭スタイルです。