kdnakt blog

hello there.

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

TLSらじお SSL/TLS

2023年6月19日～2023年6月25日に読んだ中で気になったニュースとメモ書き（TLSらじお*1第111回の原稿）です。

[Let's Encryptのシリアル番号重複]

こちらのツイートから。

リンク先はこちら。

www.agwa.name

そもそもLet's Encryptの障害があったのを知らないorz
障害の内容は、約1時間のダウンタイムと、その直前の無効な証明書の発行という2点。

証明書のポリシーの設定変更を反映したところ、CT（Certificate Transparency）のログに記録されている事前証明書の内容と、事前証明書の登録後に返却されるSCT（Signed Certificate Timestamp）を含めて生成された本物の証明書の内容に差異が出てしまい、結果として署名検証に失敗する証明書が発行されてしまった、ということらしい。問題の解消のため、約1時間のダウンタイムが発生したとのこと。

ブログを書いたAndrew Ayer氏は、Cert SpotterというCTモニタリングサービスを提供しており、このサービスがアラートを発報したため、問題発生から20分以内にLet's Encryptにメールで連絡したとのこと。すごい...。

事前証明書は証明書そのものとして扱われるため、Let's Encryptは同じシリアル番号で異なる内容の証明書を発行し、CA/B ForumのBaseline Requirementsに違反したことになるらしい。CAの運用は大変そうだな...。

影響を受けた証明書についてはすでに失効済とのこと。Let's EncryptからのインシデントレポートはBugzillaに上がっており、Andrew氏の通報で問題に気付いたと書かれている。

bugzilla.mozilla.org

Andrew氏のブログによれば、この手のCAのコンプライアンス違反を発見するのは50件目とのこと。有能〜。

[CRYSTALS Kyber + TLSへの提案]

こちらのツイートから。

リンク先の論文はこちら。
論文では、Kyber KEM (Key Encryption Mechanism)アルゴリズムによって生成された秘密情報の強度に貢献するのが、TLSサーバだけである点が問題であり、Kyber KEX (Key Exchange)アルゴリズムを使うことでクライアントも貢献できるようになる、とまとめられている。

議論のベースになっているのは現在IETFで提出されている以下のドラフト。

datatracker.ietf.org

KyberをTLSで利用する場合以下のような手順になるらしい。

  • Kyberを利用して、公開鍵と秘密鍵をクライアントが生成
  • 公開鍵はサーバに送信される
  • サーバが共有シークレット(shared secret)を生成し、Kyberで暗号化して返信
  • クライアントはKyberで復号して共有シークレットを取得
  • それぞれ共有シークレットを鍵導出処理に利用

上記の手順において、公開鍵が暗号化されずにクライアントからサーバへ送信されるため、Kyberによる暗号化のエントロピーとしては不適切であり、複数のKyber KEM操作をクライアントとサーバ双方で実施するKyber KEXを利用すべし、というのが論文の主張。
ベーシックなKyber KEXのハンドシェイクを実施するには、2RTTが必要となりそうに読める。RTTが増えるようなハンドシェイクが採用されるとはあまり思えないけど、今後どうなるんだろう...。

CRYSTALS Kyberが、すでにGoogle ChromeのCanary版で利用可能になっている点については先週触れた通り。

kdnakt.hatenablog.com

[その他のニュース]

▼RFC 6125bis Last Call

こちらのツイートから。

リンク先はこちら。

www.ietf.org

TLSでX.509証明書を利用してクライアントとサーバが通信する際の、サービスのアイデンティティ検証手順を定めたRFC6125（2011年）の更新ドラフトがいよいよ大詰め。
上記ドラフトの付録 Aに、RFC 6125からの変更点がまとめられている。
証明書のドメイン名のワイルドカードの利用方法が厳格化されたりとか、RFC 9110でHTTPについてのみ触れられていたcommonName検証の禁止がX.509証明書全般に適用されたりとか、色々ある。

っていうか元のRFC 6125ではbaz*.example.comの証明書をとって、baz1.example.comドメインで利用するとかがOKだったの知らなかった...。

▼Node.js Security Releases(2023/06/20)

こちらのツイートから。

リンク先はこちら。

nodejs.org

OpenSSLのセキュリティアドバイザリ（2023/03/28、2023/04/20、2023/05/30）に対応したらしい。また、CVE-2023-30588で、無効な公開鍵をcrypto.X509Certificate()のAPIに渡すとプロセスが終了してしまう問題が修正されたとのこと。

色々問題があるんだな...。

▼中国の176量子ビットコンピュータ

こちらのツイートから。

リンク先はこちら

aait.co.jp

RSA鍵交換、早くやめないとな...。

[暗認本：10 乱数]

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

  • 真の乱数
    • 次にどんな値になるか予測できない数字
    • 予測できないようにするのは困難
    • 再現不可能性がある＝真の乱数
  • コンピュータで扱う乱数
    • コンピュータはアルゴリズムに従って同じ値を返す
    • 乱数生成にはメモリやディスク、キーボードの状態を利用
    • コンピュータ起動直後のエントロピー(乱雑さ)は小さい
      • 増大には時間がかかる、乱数生成が遅い
    • CPUには専用ハードウェア内蔵
      • 中身がベンダに制御されていたりバグがある危険性
      • 例）AMDの固定値バグ、IntelのCrosstalkバグ
    • /dev/randomは比較的安全：/dev/urandomと比べると遅い
  • 疑似乱数
    • 擬似乱数生成器(PRNG)：シードから真の乱数に見える値の列を出力する
    • 同じシードには同じ乱数を返す：再現不可能性はない
    • 例）/dev/urandomはストリーム暗号を利用したPRNG、高速
  • 疑似ランダム関数(PRF)
    • シードと任意の値に対して疑似乱数を生成
    • PRNGを使ってPRFを構成できる
      • TLSではHMACを繰り返し適用して実装

[まとめ]

だいぶ回復してきたけど、腰をやってしまってニュース収集時間があまり取れず、今週は少なめでお送りしました。

ランキング参加中
プログラミング

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