kdnakt blog

hello there.

今週気になったTLS関連のニュース

2023年11月6日~2023年11月12日に読んだ中で気になったニュースとメモ書き(TLSらじお*1第131回の原稿)です。
全文を公開している投銭スタイルです。

[IETF 118]

こちらのツイートから。

リンク先はこちら。

https://datatracker.ietf.org/meeting/118/materials/agenda-118-tls-03

IETF 118が2023/11/06に開催されたとのこと。Encrypted Client HelloCompact TLSのほか、KyberベースでのTLSでの認証TLS Trust ExpressionsTurboTLSといった、本ブログでも過去に取り上げたドラフトの話が盛りだくさん。

クライアント証明書を利用したTLS1.3への移行の障害になっているレガシーな署名アルゴリズムRSASSA-PKCS1-v1_5を復活させるドラフトが。そんな問題があったのか...。

TLS Flagってなんだっけ...と思ったら調べてた。そのフラグの、mTLS(相互認証)専用のフラグのドラフトが出ている。mTLSといえば...と思いながら著者を見るとやはりCloudflareの所属だった。

datatracker.ietf.org

TLS Key Share Predictionなんてドラフトもある。耐量子暗号アルゴリズムの追加も見越して、TLS1.3での鍵共有がうまく動作するように曖昧さをなくすためのものらしい。DNSで鍵共有に関する情報を伝達する方法も定義しているとか。

他にもこんなドラフトが取り上げられていた様子。

datatracker.ietf.org

[eIDAS 2.0と消極的なCAの歴史]

こちらのツイートから。

以前軽く取り上げたが、EUが提案しているeIDAS 2.0という規制で、ブラウザの有能なルートプログラムに取って代わろうとしており、Webで利用される証明書のオープンさに影響するのでは、という話。

加えて、そうしたオープンさを支えてきたのは認証局ではなく、ブラウザの方だった、と。長文なのでポイントと思われる部分を書き出しておく。

  • CAはベストプラクティスの推進に反対するケースもある
    • SHA-1の廃止が遅れた
    • CAAレコードの浸透
  • 証明書発行時のドメイン検証方法の統一

個人的に気になったのは「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についてはMozillaGoogleも懸念を示している。

security.googleblog.com

securityriskahead.eu

日本語の記事も出ていた。

gigazine.net

[その他のニュース]

▼[広告] TLS季報 vol.1発刊

こちらのツイートから。

なんとか滑り込みました。よろしくお願いします(無料です)。

techbookfest.org

▼AreionとWebRTC

こちらのツイートから。

Secure Real-Time Protocolというのがあるらしい。自分はDTLS側を全然追いかけてないだけあって、

知らない用語ばかり...。

datatracker.ietf.org

▼TLS1.3の隠しストリーム暗号とTMTO攻撃

こちらのツイートから。

リンク先はこちらの論文

ストリーム暗号には元々TMTO攻撃(Time Memory Trade-Off)というのがある。名前がなんか凄そうだけど要は効率的に暗号鍵を探すことができる、と。

で、TLS1.3にはハンドシェイク後にKeyUpdateメッセージを利用して、暗号鍵を更新する仕組みがある。これが同期的なストリーム暗号の一種とモデル化することができるので、TMTO攻撃が成立する余地がある、と。

やっぱり新しいハンドシェイクで新品の鍵を手に入れるのが一番安全なのかな...。

▼Quantum Safe Journey

こちらのツイートから。

リンク先はこちら。

www.microsoft.com

そういえば考えたことがなかったのだけど、量子コンピュータで破られる可能性のあるRSA楕円曲線暗号のような公開鍵暗号と違い、AESとかSHAといった対称鍵暗号は(現実的な時間では)破られないらしい。それでNISTが出してる候補がKEMとデジタル署名なのか。

関連してこんなツイートも。Kyber512はAES-128よりも攻撃にコストがかかる(≒安全)ということらしい。

finiterealities.net

▼AzureのTLS1.3サポート

こちらのツイートから。

リンク先はこちら。

techcommunity.microsoft.com

2023年10月からTLS1.3が使えるようになってきているらしい。AWSがALBでのTLS1.3サポートしたのも最近だったからそんなもんなのかもしれない。

aws.amazon.com

ところで、こういう時にTLS1.3が使えるという場合、どこまでを指すんだろう...TLS1.3のRFC 8446に含まれないEncrypted Client Helloとかは使えたりするんだろうか?

RFC 9460 SVBC and HTTPS RR

こちらのツイートから。

リンク先はこちら。

datatracker.ietf.org

詳細は以前ゆきさんがブログにまとめてくれている。

asnokaze.hatenablog.com

Chrome 2023 Q3 Security Update

こちらのツイートから。

リンク先はこちら。

www.chromium.org

ECHはfully launchedと言われているが、手元のWindows環境でChrome 119からCloudflareのテスト用サイトに繋いだ時もSNI情報の暗号化結果はfalseになっていた気がするのだが...バージョンが古いのだろうか?

HTTPSアップグレードは先週触れたやつ。

 

[暗認本:30 サイドチャネル攻撃]

引き続き、ニュース以外のメインコンテンツとして『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』を読んでいく。
今週はChapter 5 認証から、セクション30をざっとまとめた。

  • 電力解析攻撃
    • ICカードやセキュリティトークンは耐タンパー性が必要
    • FIPS PUB 140-2ではデバイスの安全性要件を定義
      • 実装の正しさ以外にも、攻撃の検知、温度や電圧が規定外でもデータを確実に消去すること、などが必要
    • 秘密鍵を利用した計算時に、電力消費やノイズ発生パターンから秘密鍵を推測できる場合がある(電力解析攻撃
    • 2021年Googleが販売していたキーTitanが破られた
      • 深層学習を活用する、直ちに現実的な方法ではない
  • コールド・ブート攻撃
    • メモリは電源を切っても数秒は内容を保持している
    • メモリを一気に冷却すると上記の保持期間を延ばせる
    • これを利用して強制再起動時に秘密情報(BitLockerのパスワードなど)を抜き出せる
    • 2018年当時の多くのノートパソコンが脆弱
    • 再起動時にPINを求める設定にするなどで対策可能

[まとめ]

技術書典で疲れたから今週のニュースは少なくしようと思ったのに、結局6000字弱になってしまった...。

※以降に文章はありません。投銭スタイルです。

*1:TLSらじおは社内勉強会です。このブログを読み上げつつ弊社サービスの実情を語ったりします。

この続きはcodocで購入