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

先週に続き、2022年8月8日~8月14日に読んだ中で気になったニュースとメモ書き(TLSらじお第68回の前半用原稿)です。

 

 

[CTタイミング攻撃]

こちらの記事から。

swarm.ptsecurity.com

 

悪意のあるサイトも最近ではTLSを使うのが当たり前になってきている。そういうサイトは頻繁にドメインを変更するため、どれが問題のあるドメインなのか分かりにくい。

しかし、それらのドメインは同じサーバ上のサイトを指していることが多く、同じタイミングでTLS証明書を取得することになる。これをCT(Certificate Transparency, 証明書の透明性)ログ上で探し出すことで、悪意のあるドメインを見つけることができるのではないか、という話らしい。

 

先週取り上げたCertstreamとかお馴染みのcrt.shとかを眺めていると、悪いドメインを見つけられるかもしれない。

 

[CiscoRSA秘密鍵]

いくつかRSA秘密鍵に関する話題が。

1つ目はこちら。

www.bleepingcomputer.com

CISCOのソフトウェアに脆弱性があり、秘密鍵が取得され、デバイストラフィックを解読されたり、デバイスになりすまされたりする恐れがあるらしい。

CVEの説明によると、署名計算のエラーを発生させることで署名から秘密鍵を復元できるLenstraサイドチャネル攻撃*1によって秘密鍵が漏洩したらしい。実装の問題と言われればそれまでだが、エラー情報を気軽に公開しないように気をつけたいところ。

Lenstraサイドチャネル攻撃については、過去にも他の製品で同様の脆弱性が見つかっているようだ。

[HyundaiのRSA秘密鍵]

RSA秘密鍵に関する話題、2つ目はこちら。

話題になっている記事は以下。

programmingwithstyle.com

韓国の車メーカーHyundai*2の車のシステムアップデートに利用されるRSA鍵が、実はネット上のサンプルそのままだった、と。

記事の作者は最終的にオリジナルのソフトウェアを自分の車で動かすことに成功したらしい。

programmingwithstyle.com

 

ライブラリの使い方を説明したサンプルコードでさえ、エラーハンドリングなどが適切ではないのでそのまま使い回すことは避けたい今日この頃ですが、まさか秘密鍵を使い回す開発者がいるとは...ちょっと想定外ですね。

 

[その他のニュース]

HTTPSレコードのインターネットドラフト

こちらのツイートから。

リンク先の記事はこちら。

blog.apnic.net

Asia Pacific Network Information CentreことAPNIC、アジア太平洋地域のIPアドレスを管理する団体のブログ記事。

 

HTTPSレコード、実はつい最近(2022年5月)Proposed Standardとして承認され、RFCになる直前の段階らしい*3。ちょくちょく話題になってるから、とっくにRFCになってるものだと思ってた...。

datatracker.ietf.org

 

HTTPSレコードがあることで、クライアントはhttp://ではなくhttps://でドメインに接続できる。HTTP Strict Transport Security (HSTS)とある意味で似ているが、HSTSはクライアントが一度Webサイトを訪問している場合にのみ有効となる点が異なる。

 

HTTPSレコードとセットでSVCBレコードが定義されているが、これはService Bindingの略で、HTTPSレコードの上位概念らしい。HTTPSレコードなどのフォーマットを定めているのがSVCBレコードで、それをHTTP用に実装したのがHTTPSレコードということになる。

 

▼続々・Key Recovery Attack on SIDH

続報です。こちらのツイートから。

話題になっているのは以下のブログ記事。

blog.cr.yp.to

ブログ自体は、NISTに対して耐量子暗号の選定プロセスの透明性を高めよ、と主張しているだけっぽい。

 

ただ、耐量子暗号アルゴリズムのSIDH(の実装のSIKE)に脆弱性が見つかったことと合わせて、これは実はNISTによるバックドアだったのではないか?という説が囁かれているらしい。言われてみればそんな気もしなくもないが、公募でやってるわけだし流石にそれはなかろうとも思う。知らんけど。

 

[まとめ]

RSA秘密鍵は大切に扱いましょう...。

*1:Redhatの記事が詳しい。

*2:昔はヒュンダイと読んでいた気がするが最近は韓国語の発音に準じてヒョンデというらしい。

*3:標準化の過程としては2016年以降、Proposed Standard->Internet Standardの2段階あるようだ。

www.nic.ad.jp