English version is here (英語版)

こんにちは， @nya384 です． LINE CTF 2024で [crypto]haki-tako-gameと[misc]rum-runners-ruseの作問を行いました．

チャレンジに挑戦いただきありがとうございました．シェアいただいたWriteupsは楽しく読ませていただきました． 各ソリューションについては参加者のWriteupsに詳しく書かれていますので，そちらに譲ります．

その代わりに今回はチャレンジのレッスンと作文背景について述べたいと思います．

[crypto] haki-tako-game

チャレンジの紹介

Playerにはサーバーへの接続先URL, ポートとサーバーのソースコードが与えられます． サーバーはCBCモードへの復号オラクル，CFB-128モードへの復号オラクルを提供しています．

サーバー接続時にAES-GCMで暗号化されたPINコードが与えられ，これを復号することを目指します． しかし，CFB-128モードの復号オラクルは復号結果の結果の一部を\0x00に置き換える実装になっています(truncated-CFB)．

Playerが工夫したクエリでPINコードを復号し，サーバーに送信するとFLAGを入手できます．

レッスン

  • 異なるmode of operationであっても鍵を分離してください．
  • MAC, AEADによる完全性のチェックは機密性の侵害の防止に役立つことがあります．

作問背景

私は今回の作問の方針を以下のように定めました．

  • 1.チャレンジの基本的なアイデアが現実世界のアプリケーションまたはプロトコルから来ていること．
  • 2.チャレンジが教育的な示唆に富んでいること．
  • 3.チャレンジはプレイヤーが暗号ロジックの解析に注力できるように設計されていること．

1については，現実世界のアプリケーション設計から来た論文を紹介したかったという個人的な考えから来ています． 2については，チャレンジの元ネタはレッスンを問題設計に反映し易い文献を選択しました． 3については具体的にはPlayerへFlag以外のソースコードの開示を行うこと．ゴールが明確であることを要件として設計しました.

3の参考文献 cf.

作問アイデア

作問アイデアは以下の2つの攻撃手法です．

  • Related Mode Attack [Phan and Siddiqi 05] [Dayin, Lin and Wu 07]
  • AEAD-to-CBC Downgrade Attacks on CMS[Roth and Strenzke 23]

Related Mode Attackは，あるMode of operationを使用して別のMode of operationの一部もしくは全てを構成可能であるアイデアに基づいた攻撃です．また，Related Mode AttackはRelated Cipher Attack [Wu02]を一般化したものとして知られています．

また，AEAD-to-CBC Downgrade Attacksは文献[Roth and Strenzke 23]では明言されていませんが，Related Mode Attackとよく似た考え方の攻撃です． これはGCMのキーストリーム(もしくは平文)の一部が不明であるときに，CBCモードの復号オラクルを使用して完全な平文を復元する攻撃です． これはブロック暗号プリミティブの暗号化/復号関数が全単射であること，GCMの暗号化パートは実質的にCTRモードであり，暗号化関数への入力であるnonce||counterが既知であること利用しています． この条件のおかげで，攻撃者はキーストリームの不明な一部分を全探索する際に正しい平文を識別可能になります．

  • 正しくないキーストリームの場合 nonce||counter_{i} != CBC_{Dec}(keystream_{i}, k)
  • 正しいキーストリームの場合 nonce||counter_{i} == CBC_{Dec}(keystream_{i}, k)

詳しくは文献[Roth and Strenzke 23]を参照してください． 個人的にこの攻撃は現実世界のアプリケーションの解析から来ていて興味深い内容だと感じています．

なお，[Phan and Siddiqi 05]は有料ですが，[Dayin, Lin and Wu 07]と[Roth and Strenzke 23]はURLから無料でPDFへアクセス可能です．ぜひチェックしてみてください．

cf. 無料:

有料:

[misc]rum-runners-ruse

レッスン

  • 信頼できない入力を元に署名検証の範囲を変更しないでください．

作問背景

論文が面白かったため，このアイデアで作問をしたいと考えていました． StrenzkeはPKCS#7の署名検証およびCMS(cryptographic message syntax) において，与えられるデータのあるフィールドの有無によって署名の検証範囲や署名検証対象のデータの前処理方法が分岐することを指摘しています． cf. [Strenzke 23] https://eprint.iacr.org/2023/1801

Note:
似たような，信頼できない入力によって署名の検証範囲が変わるものにはPDFの署名に対する攻撃があります． こちらも作問時のアイデアとして検討していました． ただ，PDFは仕様が複雑です．また，バイナリがunreadableなのでPlayer視点では泥沼化しそうだと感じ，作問候補から外しました． cf. https://web-in-security.blogspot.com/2019/02/how-to-spoof-pdf-signatures.html

作問アイデア

このチャレンジはPlayerに正当な署名を持つがinvalidなtimestampを持つ.der fileが与えられます． どのように署名を維持しつつ，timestampのvalidationをbypassするかが問題の焦点でした． 私は当初はこれを[crypto]カテゴリのwarmupにする予定でしたが， cryptoだけでなくrevの要素があったためmiscとして出題しました．

Intended solution

この論文が元ネタです．これが全てです． cf. [Strenzke 23] https://eprint.iacr.org/2023/1801

Unintended solution

正当なタイムスタンプが .der ファイルに残っていて，invalid timestampと正当なタイムスタンプの位置を入れ替えることによってtimestampのvalidationをバイパス可能であったようです． これらの回答を行ったチームについて，以下の理由で順位に影響を与えない決定をしました．

  • 私の作問ミスによるものであること．
  • 他のPlayerを妨害するクエリではないこと

さいごに

楽しんでいただけたでしょうか？ 次に機会があればより多くのcrypto問を作成したいと思っています．もし十分な時間とリソースがあれば…ですが..