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

2024年1月8日～2024年1月14日に読んだ中で気になったニュースとメモ書きです。社内勉強会TLSらじお第139回分。

[ブラウザの中間証明書の取り扱い]

こちらのツイートから。

The browsers biggest TLS mistakehttps://t.co/AkGHHJCXGK

— Frank ⚡ (@jedisct1) 2024年1月8日

リンク先はこちら。

blog.benjojo.co.uk

TLSの認証で利用するために、Certificate版ドシェイクメッセージを通じてサーバ証明書に関連するデータが、サーバからクライアントに送信される。
通常はサーバ証明書とその中間証明書の証明書チェーンがこのCertificateメッセージに入るのだが、そう設定されていないサーバも世の中には多い。そのため、ブラウザが証明書拡張のAuthority Information Accessに含まれる情報などから証明書チェーンを独自に構築する場合がある。

というところまでは知っていたのだが、FirefoxとChromeで微妙に挙動が違うという話が本記事では書かれている。きっとSafariも微妙に違う挙動をするんだろうな...。

Firefoxの挙動を模倣するGoライブラリがあるらしい。マニアックな...。これを使ってTrancoのトップ100万サイト*1でテストしたところ、約0.8%のドメインで設定が間違っているとのこと。
playstation.comなんかはサーバ証明書を2回送ってくるらしい。ほんとかよ、と思ってOpenSSLで接続してみたらほんとだった。謎い...

pkg.go.dev

[AirDrop Cracked]

こちらのツイートから。

AirDropの通信は「TLS」を使ってE2EEを実現しているけど、AirDropの相手認証部分がアレだったんじゃないかと予想

ニュース記事のタイトルが暗号解読って書いているけど、解読はしてないんじゃない？と思う#TLS #Apple
--
アップルの｢エアドロップ｣、中国が暗号解読と送信者特定に成功と発表… pic.twitter.com/G5cpMX4j1K

— 菅野 哲 / GMOイエラエ 取締役CTO (@satorukanno) 2024年1月10日

リンク先はこちら。

www.bloomberg.co.jp

中国政府がAirDropの送信者を特定する方法を確立したらしい。
送信者の電話番号のハッシュが含まれているが、ソルトがつけられないので電話番号の全データのハッシュ値の計算結果をレインボーテーブルとして用意しておくことで、送信者を特定できるとのこと。日本でもできるんだろうな...。

こちらが発表のソースだと思われます。
北京市司法局の発表で、「送信者のハッシュ値をもとにメールアドレスと電話番号を特定できるようにした」とあります。
実際の調査を行った組織:北京网神洞鉴司法鉴定所https://t.co/jSE8pKyqqI

— マイナー次郎☄️🥀🧪🥕/INTP,e/acc (@mj_IRIAM) 2024年1月10日

Airdropは暗号学的ソルトを使用しておらず、レインボーテーブルにより容易に利用者の匿名性解除が可能です

中国のような国家は既にこれを活用しています。やり方は：

1. AirdropがBluetoothアドバタイズメントをブロードキャストする
2.… https://t.co/BLogCOkpCF

— kokumօtօ (@__kokumoto) 2024年1月13日

この辺りの技術情報はAppleのサイトにも掲載されている。TLS接続が開始されるのは共有相手を選択してかららしい。iCloud識別情報の証明書を交換してお互いのユーザーを検証するとある。

support.apple.com

こちらの記事によると、やはりクライアント認証のTLSを使っているようだ。2019年にはすでに知られていた攻撃で、すでにDH鍵交換を利用したPrivateDropと呼ばれるプロトコルが対策として提案されているらしい。

Attack of the week: Airdrop tracing https://t.co/z0VGAoilxs #mobilesecurity #androidsecurity #infosec pic.twitter.com/1nqzjiq2sq

— Ptrace Security GmbH (@ptracesecurity) 2024年1月12日

blog.cryptographyengineering.com

[その他のニュース]

▼OpenSSL YouTubeチャンネル

こちらのツイートから。

OpenSSL - YouTube https://t.co/8oVC72bw5G OpenSSL がライブラリ利用方法の動画を公開しはじめてる。

— V (@voluntas) 2024年1月8日

リンク先はこちら。

www.youtube.com

どれも再生数100くらいだった。マニアック...。

▼ECC 2024

こちらのツイートから。

Happy to announce that ECC 2024, the 25th Workshop on Elliptic Curve Cryptography, will take place in Taipei, Taiwan Oct 30 - Nov 01, 2024. The workshop will be preceeded by an autumn school on isogenies. For more see https://t.co/KSszCn16M1 You can sign up up for annoucements

— Tanja Lange (@hyperelliptic) 2024年1月4日

リンク先はこちら。

troll.iis.sinica.edu.tw

2024年10月末に台北で楕円曲線暗号のワークショップが開催されるらしい。2018年には大阪で開催されていた様子。

▼X-Wing, the Hybrid KEM

こちらのツイートから。

X-Wing - The Hybrid KEM You’ve Been Looking For https://t.co/NecIReU2d5

— Frank ⚡ (@jedisct1) 2024年1月11日

🙄 pic.twitter.com/ZwFd3zlJc0

— Frank ⚡ (@jedisct1) 2024年1月11日

リンク先はこちらの論文。

耐量子暗号のML-KEM-768(Kyberの別名)と楕円曲線暗号のX25519を併用するハイブリッド鍵カプセル化アルゴリズムの提案らしい。共有鍵の先頭6バイトがStarWarsに登場する小型宇宙船X-Wingに似ている。ちょっとかっこいい(笑)。

TLS用に提案中のドラフトと著者の一部が同じだった。

datatracker.ietf.org

▼ACMのWHOISルックアップ中止

こちらのツイートから。

Amazon Trust Services is going to stop relying on WHOIS data. https://t.co/NubX93ua6Z

— Jonathan Kozolchyk (@seakoz) 2024年1月11日

リンク先はこちら。

aws.amazon.com

WHOISを利用したドメインの検証のためのメールを送信しなくなるらしい。まあ通常はメールじゃなくてDNS検証だろうからそれでいいんじゃなかろうか...（というのはきっと理解が浅いんだろうな）。

ACMの発行するTLS証明書は395日間有効、というのはこの記事で初めて知った。CA/B ForumのBaseline Requirementsでは397日まで許可されてるのに、なんで短くしているんだろう...自動更新だから短くても問題ないってことだろうか。

背景はよくわからないけどGDPRが絡んでいるらしい？

Yep, it's in the rules that it's allowed but GDPR really broke the functionality.

— Jonathan Kozolchyk (@seakoz) 2024年1月11日

▼pkijs.org

こちらのツイートから。

New website and improved documentation for https://t.co/K5u2fL6e1w is live today.

— Ryan Hurst (@rmhrisk) 2024年1月12日

リンク先はこちら。

pkijs.org

pkijsというJavaScriptのライブラリの公式サイトができたとのこと。X.509証明書を作って検証したり、パースしたり、OCSPのやりとりをしたりできるらしい。

[暗認本：38 認証付き暗号]

『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』より、Chapter 7 TLSのセクション38をまとめた。

• 秘匿性と完全性
  • 共通鍵暗号：秘匿性あり、完全性なし
  • MAC：秘匿性なし、完全性あり
  • 組み合わせるのは難しい...両立するAEAD（認証付き暗号）を必須化
• AEADのアルゴリズム
  • 暗号文c、認証タグt＝AEAD(秘密鍵s、平文m、ナンスn、関連データd)
  • n, d, c, tを送信して共有済みの秘密鍵sで復号、検証
• AES-GCM
  • GCM：Galois/Counter Mode。ガロア体(有限体、F₂₁₂₈)で認証
  • GHASH：排他的論理和と有限体の演算を組み合わせた関数。暗号文cと関連データtから、128ビットの認証タグを生成するのに利用。
  • GHASHではなくCBC-MACで認証するAES-CCMもある（無線LANのWPA2などで利用）
  • AES-GCMの方がAES-CCMより演算コスト少、並列処理可能で高速
• ChaCha20-Poly1305
  • ChaCha20はストリーム暗号。Poly1305がMAC。
  • Poly1305の名前は計算に利用される素数p=2¹³⁰-5に由来。
  • ChaCha20-Poly1305は専用CPU命令を持たない組み込み系でAES-GCMより高速に動作

[まとめ]

そろそろ技術書典16のことを考え始めないとな...。

techbookfest.org

*1:昔はAlexaのトップ100万サイトのリストが使われていたが、2022年くらいにサービスが提供終了してしまった。