第４話： OQS-demos：PQC対応版 Chromium や Wireshark

サイバートラスト研究開発ブログシリーズ耐量子計算機暗号 (PQC) の現状～ Open Quantum Safe project の PQC 実装はどこまで動くのか？～

Open Quantum Safe project / OpenSSL や Demo

OQS-demos

OQS プロジェクトでは、OQS-OpenSSL の他に、OQS-Demos として、PQC ライブラリである liboqs を組み込んだ Apache や nginx, Chromium, Wireshark など、数々の有用なソフトウエアが公開されています ^[1]。

oqs-demosサイト画面

出典： open-quantum-safe/oqs-demos^[1], サイト画面

しかも、多くは docker イメージも用意されており、簡単に試行することが可能です。
以下にいくつかピックアップしてみます。

Chromium

Chromium は、Google Chrome や Opera などのベースとなっている OSS のウエッブブラウザですが、これの PQC 対応版となります。OQS-demos リポジトリで公開されている Chromium は、docker イメージではなく、直接、実行形式のバイナリが公開されています。

Ubuntu 18.04 環境にダウンロードして実行しようとしたのですが、ブラウザを画面表示する GUI 環境（X 環境）が ubuntu 側にはなかったので、PC 側に Sigwin をインストールし、Cygwin-X を使って、PC 側で画面表示しました。リモートの Linux のアプリケーション（Chromium）を Windows から利用するイメージです。
当然、実行しても、普通の Chromium ですが、ひとまず実行したイメージが以下。

Chromium実行画面

しかし残念ながら、ハイブリッド（コンポジット）署名アルゴリズムには対応していないということで ^[2]、前回例に挙げたような rsa3072_picnicl1full などの組み合わせによる（コンポジット）証明書を使用しているサイトへの接続は試せないようです。

Wireshark

Wireshark は、ネットワーク上のデータ（パケット）を取得（キャプチャ）して中身を見たり解析したりができるパケットキャプチャ / ネットワークアナライザアプリです。Docker イメージで提供されているので、docker 上で動作させた上で、かつ、こちらも Chromium 同様 GUI が必用なので、上と同様にして、PC 側で画面表示してみました。

Wiresharkの画面

試しに、上記の chrome で、PQC interop テスト用 web サイト ^[3] の中で、PQC のアルゴリズムとして Picnic L1 full を用いている以下のサイト（https://test.openquantumsafe.org:6850/※注：一般のブラウザで接続すると Picnic L1 full を解釈できずエラーになります）

picnicl1full    *	6850	  picnicl1full/*

に接続し、かつ wireshark でパケットをキャプチャしてみると、以下のようになります。
証明書（署名アルゴリズム）として PQC(Picnic L1 Full) が利用されているサイトに PQC 対応の chrome ブラウザで接続でき、かつパケットも取得、分析できています。ちなみに、wireshark の画面から、接続プロトコルは TLS 1.3 であることも分かります。

PQC対応のchromeブラウザで接続

wiresharkでパケットをキャプチャした画面

ここで、上の wireshark の画面では、TLS プロトコル中の Client Hello メッセージを分解して表示していますが、カーソルを合わせている行に "signature algorithms" extension があるのが見えます。
この signature algorithms extension は、TLS1.2（RFC5246）^[4] から定義されたもので、これを使うことで、TLS の接続確立（ハンドシェイク）時にクライアントのサポートしている署名アルゴリズムをサーバに伝えることができるようになっています。

今回、PQC 対応の chrome ブラウザからから送られた signature algorithms extension の内容を見ると、wireshark の表示上は unknown となっていますが（ここまでは PQC 向け修正が追いついていないのでしょう）、OQS が "Code points/OIDs of SIG algorithms" ^[5] として定義した値と比較すると、右列の四角枠内に追記したように、今回接続に使用された Picnic L1 Full が含まれ（オレンジ色部分）、接続時に利用可能とされていることが分かります。

signature algorithms extension の内容

ここから想像するに、例えば Apache を利用した web サーバでは、RSA の鍵用の証明書と、ECC（楕円）の鍵用の証明書の２つをセットしておいて、このクライアントからの signature algorithm 要求に応じて提供し分けることができますが、同様にして、PQC 対応ブラウザと PQC 非対応ブラウザが混在する環境で、ブラウザが処理できる側の証明書を送り分けるようにできるかもしれません。この後、試してみたいと思います。

次回 : OQS-demos：PQC 対応版 Apache httpd と既存暗号 /PQC 混在環境

次回は、その「Apache httpd と既存暗号 /PQC 混在環境」について解説します。

この記事の著者

サイバートラスト R&D センター

「R&D センター」は、2022 年 4 月 1 日に立ち上げられた研究開発部門です。
サイバートラストは、お客様のサービスの信頼性を支えるプラットフォーマーとして、先々のプラットフォームや社会制度、他がどのように変化するのかを考えています。
さまざまな IoT 機器が普及し、OSS や AI やブロックチェーンが活用され、量子コンピュータが発達する一方で、それらによる新たなセキュリティリスクも生じると想像される未来においても、引き続き、安心・安全な社会を実現するため、サイバートラストが果たす役割を含め、研究開発を進めていきます。