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

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

[iMessageの耐量子暗号プロトコルPQ3]

こちらのツイートから。

AppleのiMessageが対量子暗号プロトコルPQ3の採用を発表。iOS 17.4, iPadOS 17.4, macOS 14.4, watchOS 10.4けらの対応。 https://t.co/1VgLYsc3Nl

— kokumօtօ (@__kokumoto) 2024年2月21日

リンク先はこちら。

www.silicon.co.uk

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

www.itmedia.co.jp

メッセージアプリSignalの採用したPQXDHというハイブリッド暗号よりも、周期的な鍵の生成メカニズムが組み込まれている点で高機能とのこと。TLS1.3の鍵スケジュール的なやつだろうか。TLS1.3の場合、スケジュールの周期はRFCでは書かれておらずクライアントに委ねられているけれど、PQ3では約50メッセージごとまたは少なくとも7日に1回と明示されていた。
Kyber(ML-KEM)と楕円曲線DHをハイブリッドにする部分は同じっぽい。

MLSとかも分かってないとダメかなあ...。

datatracker.ietf.org

ハードウェア命令とかも分かってないとこの辺りの理解が難しい...。

PQ3はKyberでECDHとのhybrid...だけどKyberの重さを減らすためにややこしいことをやっているようだ。ECDHは25519ではなくてNIST P256。ハードウェアが使えるからとかそんな理由だろうか。

— Tomoyuki Sahara (@tomosann) 2024年2月22日

[その他のニュース]

▼KeyTrap検証

こちらのツイートから。

「これまでに発見されたDNSに対する最悪の攻撃」というキャッチーな謳い文句が先行しないようにKeyTrapについて書いておいたhttps://t.co/XewIhW49JR

— 中東いくべぇ (@knqyf263) 2024年2月19日

リンク先はこちら。

knqyf263.hatenablog.com

ChatGPTを活用して検証環境をサクッと作っていてすごい。

▼PKCS #1 RSA実装ガイダンス(ドラフト)

こちらのツイートから。

みんな大好き、PKCS#1に関するI-Dがあるんですが、IRTF CFRGで 3週間のAdaption Call が開始されたよっ！

実装時に注意すべき点なども書かれているけど、非推奨アルゴリズムについての節があるので見ておくとよいかと〜✨

Implementation Guidance for the PKCS #1 RSA Cryptography Specification,… pic.twitter.com/9j96G81m70

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

リンク先はこちら。

datatracker.ietf.org

RFC 8017で出ているPKCS #1 v2.2の実装ガイドのドラフト。元々TLS1.2で使われていたPFSのない暗号方式であるRSAES-PKCS-v1_5を非推奨化する話も上がっている。

▼AWS IoT CoreのOCSP Staplingサポート

こちらの記事から。

aws.amazon.com

CloudFrontは随分前に対応してるみたい。

aws.amazon.com

一方、ALBではできないという記事がある...軽く探してもできるようになったという記事は見つからなかった。はて。

hayashier.com

▼HTTPSレコード解説

こちらのツイートから。 

2023年11月、HTTPSレコードがRFC9460として標準化されました。
HTTP/3を支える技術のひとつで、WebサーバのDNSへの登録方法も変わります。
CNAME + MX + α の機能も備えています。
DNS / Web / ファイアウォール運用者はぜひご覧ください。https://t.co/7OGPUya9Uw#HTTPSレコード #DNS #RFC

— IIJ_ITS (@IIJ_ITS) 2024年2月22日

リンク先はこちら。

eng-blog.iij.ad.jp

未知のDNSレコードは怪しいということで、ファイアウォールでHTTPSレコードがドロップされることもあるらしい。なるほど。

おまけのところで権威サーバの新機能を安全に伝達する仕組みとしてDELEGレコードという新しいレコードのドラフトも紹介されていた。DoTで使うっぽいけど、どうやるんだろう...。

datatracker.ietf.org

▼DKIMのRSA1024ビット鍵

こちらのツイートから。

メール配信サービスの会社さん、RSAの1024bit鍵は非推奨ですから、せめて2048bitに変えましょう。
DKIM突破されまくってますよ。

— Yoichiro Takehora (竹洞 陽一郎) | 株式会社Spelldata (@takehora) 2024年2月22日

1024bit RSA DKIM が突破されまくりって、ソース知りたいなぁ。

10～20年前に 768bit RSAが破られた記憶あるけど、とはいえ 768bit → 1024bit、つまり2^256倍のマシン性能って、クラウド集めても厳しくないかしらん…？
（あとDKIM破る程度だと、電気代/マシン代がとても見合わない気が） https://t.co/T9vg9eNgYz

— Shirouzu Hiroaki（白水啓章） (@shirouzu) 2024年2月22日

Okuさんから示唆頂き、もう少し調べてみる。
2010年にRSA 768bit解読、数百台のマシンで半年～2年の計算量と。https://t.co/AHnLvDUYFI

数体ふるい法での強度評価では768=約70bit、1024=80bit、計算量の差は2^10＝約1000倍。
（2^256はオーダー感全然違っていた…）https://t.co/StTiMzzV9X

— Shirouzu Hiroaki（白水啓章） (@shirouzu) 2024年2月23日

RSA 1024bitだと、15年前に比べて 100倍のマシンパワー（まだ無さそ？）を持つ数千～数万台のマシンを半年以上使えば、解けるかレベルかな？

（そんな膨大リソース使って、わずか1ドメインのDKIM署名を偽造するとか、元が取れるとは思えず…（笑））

— Shirouzu Hiroaki（白水啓章） (@shirouzu) 2024年2月23日

1024bit RSAを解くと1500万円の賞金がもらえます https://t.co/ohhpWVwR9P https://t.co/PSgbLoHX33

— Kazuho Oku (@kazuho) 2024年2月22日

流石にこれはなさそうかなあ...。とはいえ2048ビットのRSAは2030年で終わりにしろって言われてるし、強めのものを選択しておくのがよさそう。

▼Mozilla Root Programのオーナー変更

こちらのツイートから。

Kathleen Wilson, who has been at the helm of the Mozilla Root Program for the last 16 years, has announced her retirement. #WebPKI https://t.co/dgycuj5Lcr

— Ryan Hurst (@rmhrisk) 2024年2月22日

For more on her journey in the Root Program see https://t.co/ul8avcaJ2y

— Ryan Hurst (@rmhrisk) 2024年2月22日

リンク先はこちら。

groups.google.com

groups.google.com

16年運営されたKathleenさんが引退されるとのこと。当初は数年でルートストアが時代遅れになると思っていたらしい。

CCADBはMozillaを離れてLinux Foundationに移管される予定とも書かれている。

▼GREASE in the DNS

こちらのツイートから。

Greasing Protocol Extension Points in the DNShttps://t.co/C87rReymsm
DNSもGreasingのdraft出た。
（将来の拡張性を維持するために、未知のタイプが正しく無視されることを確認するやつ）
DNSはocificationすごそう#yuki_id

— ゆき (@flano_yuki) 2024年2月23日

『DNSプロトコルの拡張性を担保するGreasingの提案』https://t.co/AJwpS2S7NH
ブログ書いた#asnokaze

— ゆき (@flano_yuki) 2024年2月24日

リンク先はこちら。

www.ietf.org

asnokaze.hatenablog.com

HTTPSレコードとかDELEGレコードとか、どんどん新しいの出てるので、硬直化を防ぐ意味でこういうのが必要なのかもしれない。

▼wolfSSLの0.5-RTTサポート

こちらのツイートから。

ブログポストしました: 0.5-RTTデータを(D)TLS1.3でサポート: 少し前のブログ（DTLSでの0-RTTデータのサポート）でクライアントが送信するアーリーデータについてご紹介し…続きを読む

The post 0.5-RTTデータを(D)TLS1.3でサポート… https://t.co/c3ks8Ok3oX #組み込み #C言語 #プログラミング

— wolfSSL Japan (@wolfSSL_Japan) 2024年2月13日

リンク先はこちら。

wolfssl.jp

何か特別なやつ？と思ったけど、普通にRFC 8446(TLS1.3)で図示されているやつっぽい。オプショナルなものだとは書かれていたけど、意外とサポートされていない機能なのかも？他のライブラリがどうなっているか気になる。

[暗認本：44 無線LAN]

『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』より、Chapter 8 ネットワークセキュリティのセクション44をまとめた。

• 無線LANの概要
  • 1997年のIEEE 802.11以降、速度や暗号の改善があり、2019年のIEEE 802.11ax(Wi-Fi 6)が最新
    • 2021年よりWi-Fi 7(IEEE 802.11be)が仕様検討中
  • 無線LANアクセスポイント：イーサネットフレームとIEEE 802.11フレームを相互変換
  • SSID(Service Set IDentifier)またはESSID(Extended SSID)で識別
• スプーフィングと認証解除攻撃
  • 不正なARPを送りルータになりすまして盗聴するARPスプーフィング
  • 同じSSIDで本物より強い電波を出すEvil Twin攻撃
  • IEEE 802.11の認証解除フレーム(接続切断仕様)を偽装して強制切断攻撃が可能（認証解除攻撃）
    • 無線LANの管理フレームの1種であり、これを保護する802.11wという規格PMW(Protected Management Frames)がある
• WEP: Wired Equivalent Privacy
  • 最初の暗号化方式。ストリーム暗号RC4を利用。
  • 24ビットの初期化ベクトル(IV)を利用するため、同じIVになりやすく2001年から攻撃につながった
  • 2006-7年の関連鍵攻撃ではARPパケットから秘密鍵を高確率で復元、以後も改良が進んでいる
• WPA2: Wi-Fi Protected Access 2
  • 2003年WPA-TKIP(Temporal Key Integrity Protocol)はIVを48bitに拡張
  • 2004年WPA2(IEEE 802.11i)はAES暗号を利用、秘密鍵最大256bit
    • Couter mode with CBC-MAC Protorolという認証付き暗号を利用
  • 4-wayハンドシェイクでユニキャスト用のPTK(Pairwise Transient Key)とブロードキャスト用のGTK(Group Temporal Key)を共有
    • パスワード、MACアドレス、Nonceから鍵を生成
• KRACK: Key Reinstallation AttaCKs
  • 2017年にVanhoefらにより発見されたWPA2ハンドシェイクの脆弱性
  • 中間者攻撃によりなんすの再利用を誘発する
  • 当時はAndroidなど一部実装で一時キーが0になる問題も。
• WPA3
  • 2018年にWPA3が登場、パスワード最大値が128文字まで拡大(WPA2-PSKでは63文字)
  • KRACKを受けてWPA3-personalではSAE(Simultaneous Authentication of Equals)という楕円曲線の鍵共有プロトコルを4-wayハンドシェイクの前に導入
  • 2019年VanhoefらによりSAE実装のサイドチャネル脆弱性Dragonbloodが発見。他にダウングレード攻撃なども。
  • 2020年無線LAN全般への攻撃としてFragAttacksを発表

[まとめ]

古いOS、ブラウザだとTLSのエラーが出てTwitter見れないらしい。それはそう。

Windows XPでTwitter表示できんかった・・・ pic.twitter.com/L0LfcIAZH2

— きしだൠ(K1S) (@kis) 2024年2月24日