kdnakt blog

hello there.

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

TLSらじお SSL/TLS

2023年4月10日～2023年4月16日に読んだ中で気になったニュースとメモ書き（TLSらじお第101回の原稿）です。

[耐量子暗号+TLS1.3の電力消費]

こちらのツイートから。

リンク先はこちら。

eprint.iacr.org

バッテリー駆動デバイスなどリソースに制限のあるデバイス上での耐量子暗号とTLS1.3の組み合わせをWolfSSLというライブラリを用いて検証した論文。ちなみにハンドシェイクはこんな感じになるらしい。

いくつかの場合では通常のTLS1.3より耐量子暗号を使ったTLS1.3の方が電力消費が抑えられるケースがあったとか。論文中のTable 2: Time, Power and Energy consumption of Traditional and PQ TLS 1.3 Handshake.に結果がまとまっているが、これは主に鍵サイズのでかいRSA証明書が悪いような...。
PQCと対比してTraditionalと呼ばれているアルゴリズムでも、ECDHE+ECDSAならDil2+Kyb1とかDil3+Kyb5といい勝負をしているように見える。

[ChromiumのKyber移行]

こちらのツイートから。

リンク先はこちら。

chromium.googlesource.com

そもそもCECPQ2って何だっけ？と思ったらChromiumのサイトにまとまっていた。Chrome 91（2021年）から使えた機能っぽい。Combined Elliptic-Curve and Post-Quantum 2らしい（Wikipedia情報）。

www.chromium.org

ECDHE(X25519曲線)とNTRU-HRSS-KEMという耐量子鍵合意アルゴリズムを組み合わせてTLS1.3の鍵交換でPQCを実現しようという試みらしい。ざっと検索した感じNTRU-HRSS-KEMは2017年ごろに論文が出ているようで、やや古め。その後のNISTによる耐量子暗号標準化でKyberが選定されつつあるのを受けて今回の移行があったものと思われる。

関係ないけど、コミットを見るとちゃんと非推奨になった機能に関するテストコードを削除していて良さげ。非推奨とはいえ利用可能な機能なら、テストコードも残しておきたくなってしまいがちなので...。

[Nginx 1.24]

こちらのツイートから。

リンク先はこちら。

www.phoronix.com

TLS1.3がデフォルト、というのはこういうことらしい。そして正確にはバージョン1.23.4からデフォルトになった、と。

Default:	
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

ただ、この辺の変更点も気になる...。

リンク先はこちら。

github.com

以下のようにプロトコル混じりでlistenできなくなるということらしい。うちはそこまで見通し悪くないので大丈夫、なはず。そもそも禁止というわけではなく、警告を追加するだけっぽいし。

server { listen 443 ssl backlog=1024; server_name foo; ... }
server { listen 443 http2; server_name bar; ... }
server { listen 443 proxy_protocol; server_name bazz; ... }

[その他のニュース]

▼acmezのARI対応

こちらのツイートから。

リンク先はこちら。

github.com

acmezというGo製のACMEクライアントが、ARI（ACME Renewal Information）拡張に対応したらしい。
ARIの仕様はまだインターネットドラフトの段階だけど、先々週取り上げたAnvilに続いてちらほらと対応クライアントが増えている模様。やはりLet's Encryptが本番環境で同機能を提供し始めたのが大きいのだろうか。

▼自治体のドメイン偽装

こちらのツイートから。

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

www.tokyo-np.co.jp

「https://city.machida.kanagawa.jp/」はともかく、「https://mikurashima.tokyo.jp/」はドメインだけ見たら本物かと思っちゃいそう...「みくらじま」が正しいらしい。
記事中にもあるように自治体限定のlg.jpドメインを使ってもらえればいい気はする。
他の対策について考えてみたけど、ツイートにもあるように証明書を確認する人類はほぼいないと思うし、EV証明書のUIはあまり効果がないということで廃止されてしまったし、どういうのがいいんだろう...。

▼サーバ証明書の有効期間が90日に?

こちらのツイートから。

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

college.globalsign.com

2023/03/06の本ニュースでも取り上げた内容についてGlobalSignの記事が公開された。3月末までフィードバックを集めていたらしいので、そろそろGoogleから具体的な日付等が発表されたりするのだろうか?
ACME対応しないと、イーロンのStarlinkみたいに障害起こしちゃいそう。

▼BouncyCastle Java 1.73

こちらのツイートから。

リンク先はこちら。

www.bouncycastle.org

EdDSAやPQCのパフォーマンス改善とか、軽量暗号Ascon対応とか。

▼Wireshark Foundation

こちらのツイートから。

リンク先はこちら。

www.wireshark.org

いつもお世話になっております...🦈

▼RFCの読み方

こちらのツイートから。

リンク先はこちら。

heartbeats.jp

MUSTとかSHALL NOTとかあの辺の用語適当に読んでたので、まとめてくれてて助かる...。SHALLって要求事項でMUSTと同類だったのね。そういえば昔英語の授業でなんか習ったような...。

[暗認本：01情報セキュリティ]

『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』を読んでいきます。今週は01情報セキュリティをざっとまとめた。

  • 情報セキュリティの三要素CIA
    • 機密性Confidentiality：データの秘匿
    • 完全性Integrity：データの正確さ
    • 可用性Availability：データのアクセスしやすさ
  • それぞれ以下の暗号技術を利用する
    • 機密性：暗号化、認証
    • 完全性：メッセージ認証符号、署名
    • 可用性：秘密分散
  • 利便性とコスト：いつでも使えて高いor安いけど停止あり
  • 三要素に加えて、以下を考慮する
    • 真正性Authenticity：データが本物か
    • 責任追跡性Accountability：ロギング
    • 否認防止Non-repudiation：後で否定させない
    • 信頼性Reliability：不具合がないこと

情報セキュリティの可用性を維持するための秘密分散の技術について、パッとイメージが湧かなかったので、本書9章にある秘密分散の節を合わせて流し読みした。

  • 秘密分散：秘密鍵等を複数のデータに分散させ、単独で復元できない形にする
    • シンプルな2-of-2秘密分散
      • 秘密鍵をsとする
      • sと同じ長さの乱数rを用意し、s1=r, s2=s(+)rとする
      • 復元時はs1(+)s2からsを得る
    • k-of-n秘密分散：n個のうちk個集めると復元可能
      • ISO 19592-2:2017として標準化
      • シャミアによる秘密分散が有名

シャミアの話はこの辺がわかりやすかった。

kimh.github.io

[まとめ]

今週からTLSらじお本編もZennではなくこちらに記載する形式を試す。30分で話せるか...?

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