2024年3月18日～2024年3月24日に読んだ中で気になったニュースとメモ書きです。社内勉強会TLSらじお第149回分。
[PQCと証明書 [IETF119]]
こちらのツイートから。
UTA WGでの発表でPQCの話題が出てきておりますっ
— 菅野 哲 / GMOイエラエ 取締役CTO (@satorukanno) 2024年3月22日
ScopeがTLSの範囲だから揉めない内容だと信じている
--
PQC Recommendations for Internet Applications,https://t.co/LMe4jNXgQq#IETF119 #PQC #TLS pic.twitter.com/hSGbEFXmVQ
リンク先はこちら。
ML-DSA（Dilithium）の証明書のドラフトとかも出てるみたい。
証明書ディスカバリのメカニズムも提案されているらしい。プライマリ証明書を一般的なアルゴリズム、セカンダリ証明書を新しいアルゴリズムで、みたいな使い方を想定している様子。
知らない間に証明書関連が結構進んでた。実際に発行されるのはもう少し先っぽいけど、仕様はもう話し合われてるのね（そりゃそうか）。
[Windowsの2048ビット未満RSA鍵廃止]
こちらのツイートから。
マイクロソフトがWindowsにおける2048ビット未満のビットRSA鍵の廃止を発表。企業内やテスト用の証明書はスコープ外正確な廃止時期は未発表。2012年に1024ビット未満のRSA鍵が廃止された際には猶予期間があり、古い鍵の使用試行をログに残して判別することができた。 https://t.co/j6jF44Suy7
— kokumoto (DM) (@__kokmt) 2024年3月18日
リンク先はこちら。
1024ビットのRSAキーを利用しているソフトウェアやデバイス(プリンタなど)に影響があるとのこと。2012年に1024ビット未満の鍵を非推奨にした際にも猶予期間があったので、今回も猶予期間があるだろう、とのこと。
やはり2030年より前に動き出したか...。
[その他のニュース]
▼TLS with Verifiable Credential [IETF119]
こちらのツイートから。
VCを使ってTLSの認証すっぞっていう提案
— 菅野 哲 / GMOイエラエ 取締役CTO (@satorukanno) 2024年3月17日
---
Transport Layer Security (TLS) Authentication with Verifiable Credential (VC),https://t.co/dkSPAnQaFT#IETF119 #VC
リンク先はこちら。
新しいインターネットドラフトが出てるみたい。
これまで、X509の証明書やRawPublicKeyのみが定義されていた証明書種別のところにVerifiable Credentialというものを使おうという提案。Verifiable Credentialは非中央集権的モデルで、X509のような証明書と違って証明書の発行元に問い合わせることなく改ざんがないことなどの検証ができるのが特徴。どの発行元を信頼するのか、という問題は結局あるようだけど...。
大規模なIoT環境でのX.509証明書の管理が大変なので、VCがいいんじゃないか、という話らしい。
▼TLS, byte by byte
こちらのツイートから。
このWebページにアクセスした際に発生する通信内容をバイト列レベルで解説してくれる。pure javascriptなTLS1.3実装のデモも兼ねてる。わいわい / “TLS, byte by byte” https://t.co/0Ng5eZMOwN
— matsuu (@matsuu) 2024年3月17日
リンク先はこちら。
1バイトずつ解説があるので便利。またいつかTLS実装する時にお世話になろう。
似たようなサイトだとxargs.orgがあるが、こちらはサンプルのみの解説なので、byte by byteの方がライブ感があって良さげ。
▼AES-GCM-SST [IETF119]
こちらのツイートから。
AEAD PropertiesのI-Dが完了するまでは新しい暗号利用モードの標準化を進めるのは厳しいと予想！
— 菅野 哲 / GMOイエラエ 取締役CTO (@satorukanno) 2024年3月18日
Galois Counter Mode with Secure Short Tags (GCM-SST)https://t.co/d1hPgikl9A
リンク先はこちら。
AESのGalois Counterモードは現在広く使われているが、短いタグを使うと偽造ができてしまう可能性がある。しかし音声パケットやファームウェアのアップデートなどで必要なことから、GCM with Secure Short Tags（AES-GCM-SST）というGCMの微修正バージョンが今回のドラフトに。
▼ルートCA分析
こちらのツイートから。
To complement the script I assembled yesterday, which aims to clarify which CAs are actively participating in the WebPKI, I thought it would be helpful to contextualize this within the total list of CAs.
— Ryan Hurst (@rmhrisk) 2024年3月18日
With this in mind, I created another script to answer this question. What… pic.twitter.com/YP0YKFCqeL
リンク先はこちら。
webpki-ca-countries.py · GitHub
ルートプログラムを国別に分析するとアメリカがトップになるらしい。リンク先はで、Apple、Google Chrome、Microsoft、Mozillaの各ルートストアのCAの一覧も比較されている。Microsoftが一番寛容というのはちょっと意外かも。
CAの証明書発行割合はこちらに。
This weekend I played a bit with the new view on https://t.co/6iVW1ZazNT that groups CAs by Root Owner. I combined the CA Owner view to create a cleaned-up market share review. The Python to generate this is here: https://t.co/N9eUMnulsp #WebPKI pic.twitter.com/s3qHsTBLTd
— Ryan Hurst (@rmhrisk) 2024年3月18日
▼Let's Encryptの新中間証明書
こちらのブログから。
1つだけじゃなくて、15個の新しい中間証明書が2024/03/13に発行されたとのこと。
内訳としては2048ビットのRSA証明書が5つ、P-384 ECDSAのキーペアが5つ。ECDSAのキーペアは、ISRG Root X1とISRG Root X2という2つのルート証明書で発行されるので、証明書としては10個になるとのこと。
また、現在のR3などの中間証明書は5年間の期限があり2025年まで有効だが、今回発行したものは3年間で2027年まで有効とのこと。アジリティ大事。
▼NSSのRSA復号タイミング攻撃（CVE-2023-5388）
こちらのツイートから。
Bleichenbacher attacks — once again. https://t.co/T1TzXMyBPO
— Matthew Green (@matthew_d_green) 2024年3月19日
リンク先はこちら。
FirefoxやThunderbirdで利用されている暗号モジュールNSSにRSA復号時のタイミング攻撃が可能な脆弱性があったらしい。処理時間が一定でないとか、よく気づくなあ...。
▼MD5テキスト衝突攻撃
こちらのツイートから。
Here is a 72-byte alphanum MD5 collision with 1-byte difference for fun:
— Marc Stevens (@realhashbreaker) 2024年3月19日
md5("TEXTCOLLBYfGiJUETHQ4hAcKSMd5zYpgqf1YRDhkmxHkhPWptrkoyz28wnI9V0aHeAuaKnak")
=
md5("TEXTCOLLBYfGiJUETHQ4hEcKSMd5zYpgqf1YRDhkmxHkhPWptrkoyz28wnI9V0aHeAuaKnak")
This is the first md5 collision with only printable ascii that I know of.
— Marc Stevens (@realhashbreaker) 2024年3月19日
I have been asked before if this was possible, but I used to respond its not practically doable.
72バイトの、アルファベットと数字のみからなる文字列のMD5ハッシュ値が一致したとのこと。元の文字列は1バイトしか差異がない。
ツイートしたのは、2008年にMD5の選択的プレフィクス衝突攻撃を利用して偽造CA証明書を取得したMarc Stevens氏。
$ md5 -s TEXTCOLLBYfGiJUETHQ4hAcKSMd5zYpgqf1YRDhkmxHkhPWptrkoyz28wnI9V0aHeAuaKnak
— kjur (@kjur) 2024年3月20日
faad49866e9498fc1719f5289e7a0269
$ md5 -s TEXTCOLLBYfGiJUETHQ4hEcKSMd5zYpgqf1YRDhkmxHkhPWptrkoyz28wnI9V0aHeAuaKnak
faad49866e9498fc1719f5289e7a0269
あらほんまや。AckとEckが1文字ちがうのか。
▼フリーWiFiでMITM
こちらのツイートから。
まあ、そりゃ立てるだけなら誰でもできるけど…フリーWiFiでMITMしてTLS盗聴できるよって言ってる人、そのCA証明書を誰が信頼するのかって話をすっ飛ばしてるんだよね。
— 嶋田大貴 (@shimariso) 2024年3月20日
それはそう。
ただ、一昔前の研究では、ブラウザ利用者の一定数が証明書の警告を無視すると言われている。最近はどうなんだろう...?
https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/41927.pdf
▼耐量子暗号は巨大
こちらのツイートから。
With Real World Cryptography coming up next week, I wanted to take an opportunity to point out that our current post-quantum cryptographic primitives are not suitable for the web https://t.co/AEpsJC0ssJ
— David Adrian (@davidcadrian) 2024年3月23日
リンク先はこちら。
TLSハンドシェイクでやりとりされる署名や公開鍵のサイズが詳しくまとめられている。通常のRSA証明書などであれば、SCTやハンドシェイクのECDSA署名を含めても1度のハンドシェイクで1248バイトだが、ML-DSAは公開鍵だけで1312バイト、署名は2420バイトになるという。
中間証明書の省略や、Merkle Tree証明書によるSCTと証明書のマージなどによって、どの程度改善できるだろうか。
先週のCloudflareの記事と似たような内容だった。
[暗認本：48 量子コンピュータ]
『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』より、Chapter 9 高機能な暗号技術のセクション48をまとめた。
- 量子ビットと観測
- 量子：波のように複数の状態が重なって存在
- |ψ〉= a|0〉+ b|1〉
- 0と1の状態の重なり
- a,bは|a|^2+|b|^2=1となる複素数
- 確率|a|^2で|0〉になる
- 実数に制限：|0〉を(1, 0)、|1〉を(0, 1)とする
- |ψ〉は半径1の円周のどこかを指す
- 量子ゲート
- 量子ビットに対して変換処理をする部分
- ※従来のコンピュータでビットの変換処理をする部分をゲートと呼ぶ
- ゲートX（反転）：a|0〉+ b|1〉→a|1〉+ b|0〉
- ゲートZ（符号変換）：a|0〉+ b|1〉→a|0〉- b|1〉
- ゲートH（回転、Hadamard）
- 量子ビットに対して変換処理をする部分
- CNOTゲートと量子もつれ
- ここでは2量子ビット入力、2量子ビット出力のゲートを考える
- x= a|0〉+ b|1〉、y= c|0〉+ d|1〉とする
- 積：x (x) y = ac|00〉+ ad|01〉+ bc|10〉+ bd|11〉
- CNOTゲート：|10〉と|11〉を交換
- ac|00〉+ ad|01〉+ bd|10〉+ bc|11〉となる
- (x, y)を(x, x (+) y)に変換するとも書く
- 従来の排他的論理和に相当
- CNOTを通すとxとyの観測結果が独立でなくなる：量子もつれentanglement
- 従来andとxorで任意の回路を構成できたのと同様、1量子ビットの量子ゲートとCNOTゲートを組み合わせると任意の量子ゲートを構成できる
- 量子コンピュータにおける計算
- 量子超越性
- 暗号技術に対する影響
- 量子ゲート方式と量子アニーリング方式
- 量子鍵配送
- 耐量子計算機暗号
[まとめ]
ちなみにこの広さwww pic.twitter.com/9fmKNwjRqE
— 菅野 哲 / GMOイエラエ 取締役CTO (@satorukanno) 2024年3月19日
