IR 情報

お問い合わせ

BLOG

研究開発ブログ

第5話: OQS-demos:PQC 対応版 Apache httpd と既存暗号/PQC 混在環境

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

Open Quantum Safe project / OpenSSL や Demo

OQS-demos の続き

Apache httpd と既存暗号 /PQC 混在環境

OQS プロジェクトによる PQC 対応の Apache httpd も Docker イメージで提供されています [1]。かつ、oqs-demos/ httpd/USAGE.md [2] の "Putting it all together" の記載のように、各種の config 値、証明書などをカスタマイズして、動作確認などをすることが可能です。これを用いて、PQC 対応ブラウザと PQC 非対応ブラウザが混在する環境での、2つの証明書(RSA と PQC)の使い分けが1つの Web サーバ(Apache)で可能かを確認してみました。

PQC/既存暗号混在環境での証明書の使い分け

まずは、RSA と PQC それぞれ用の証明書を作成します。実際には、SHA256 RSA(3072bit)と Picnic L1 Full の署名アルゴリズムを用いてみました。openquantumsafe/httpd [3] の "Creating (test) CA and server certificates" の記載に従い、かつ、openquantumsafe/curl の引数として、それぞれ -newkey RSA:3072 と -newkey picnicl1full を指定して、それぞれの鍵と証明書を作成します(今回は以下)。

・RSA の鍵・証明書ファイル
/opt/httpd/pki/server-RSA3072.key
/opt/httpd/pki/server-RSA3072.crt
・PQC(Picnic L1 Full) の鍵・証明書ファイル
/opt/httpd/pki/server-picnicL1FS.key
/opt/httpd/pki/server-picnicL1FS.crt

oqs-demos/httpd/httpd-conf/ [4] からダウンロードしてきた conf ファイル "httpd-ssl.conf" の中で以下のように、2つの鍵・証明書ファイルを併記して指定します。

SSLCertificateKeyFile  "/opt/httpd/pki/server-RSA3072.key"
SSLCertificateFile     "/opt/httpd/pki/server-RSA3072.crt"
SSLCertificateKeyFile  "/opt/httpd/pki/server-picnicL1FS.key"
SSLCertificateFile     "/opt/httpd/pki/server-picnicL1FS.crt"

これらを用いて、前述の oqs-demos/httpd/USAGE.md "Putting it all together" の記載に従い、PQC 対応の apache を起動。

クライアント側としては、PQC 対応の OQS-OpenSSL を用い、かつ、TLS の extension として Signature Algorithms を指定して接続します。

・署名アルゴリズムとして RSA を指定して接続
$ ./openssl s_client -connect (ip addr):443 --tls1_3  -sigalgs RSA-PSS+SHA256
・署名アルゴリズムとして PQC (Picnic L1 Full) を指定して接続
$ ./openssl s_client -connect (ip addr):443 --tls1_3  -sigalgs picnicl1full

それぞれ、TLS 接続時の Client Hello メッセージを PQC 対応 wireshark で見ると、以下の通り、きちんと signature algorithms で指定した署名アルゴリズムを Web サーバ側に指定して接続しているのが分かります。

署名アルゴリズムとして RSA を指定

署名アルゴリズムとして RSA を指定1

署名アルゴリズムとして RSA を指定2

署名アルゴリズムとして PQC (Picnic L1 Full) を指定

署名アルゴリズムとして PQC (Picnic L1 Full) を指定1

署名アルゴリズムとして PQC (Picnic L1 Full) を指定2

※wireshark の表示上 unknown ですが、0xfe96 は picnicl1full です

これに対し、Web サーバ(apache / OQS-httpd)からは、それぞれに対応した証明書が返されていました。

署名アルゴリズムとして RSA(RSA-PSS) を指定

CONNECTED(00000003)
depth=0 CN = oqs-httpd
  ・・・
---
Certificate chain
 0 s:CN = oqs-httpd
   i:CN = oqstest CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDsDCCAhgCFG・・・
-----END CERTIFICATE-----
  ・・・
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits

署名アルゴリズムとして PQC (Picnic L1 Full) を指定

CONNECTED(00000003)
depth=0 CN = oqs-httpd
  ・・・
---
Certificate chain
 0 s:CN = oqs-httpd
   i:CN = oqstest CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIJ5EzCBqQIUZd・・・
-----END CERTIFICATE-----
・・・
Peer signature type: Picnic L1 full
Server Temp Key: X25519, 253 bits

当然、既存のブラウザ(PQC 非対応)でも接続が可能で、RSA 側の証明書が用いられます。
ブラウザが Signature Algorithms で既存の署名アルゴリズムのみを指定しているからとなります。

既存の一般のブラウザ(今回は Google chrome)で接続

Google chromeで接続1

Google chromeで接続2

Google chromeで接続3

Google chromeで接続4

逆に、QPC 対応 chrome(OQS-demos / chromium)で接続するとどうなるでしょう?
残念ながら、現行の OQS-demos / chromium は、最初の client hello メッセージで、まずは非対応 chrome と同様、既存の署名アルゴリズムを指定して接続を試み、それが拒否される(Handshake Failure)と、次の試行として、PQC を含む署名アルゴリズムを指定するという挙動となっていました。このため、Web サーバ側(OQS-httpd)が RSA の証明書を持っていると、最初の RSA で接続してしまいました。

PQC 対応 chromium(OQS-demos / chromium)で接続

最初の接続時の Signature Algorithms 指定
(既存暗号関連の署名アルゴリズムのみ)

最初の接続時の Signature Algorithms 指定

一度 Handshake Failure した後の接続時の指定
(PQC 関連の署名アルゴリズムも含まれる)

一度 Handshake Failure した後の接続時の指定

RSA 証明書を使用して接続

RSA 証明書を使用して接続

上記は、たまたま現行の OQS-demos / chromium では、そのような作り / 挙動になっているというものですが、将来、PQC が普及した際には、TLS 接続時の signature algorithms extension に最初から PQC を含む署名アルゴリズムが指定されることになると想定されます。
試しに、OQS-OpenSSL を用い、RSA と PQC の両方の署名アルゴリズムを指定してみると:

・署名アルゴリズムとして RSA と PQC (Picnic L1 Full) の両方を指定して接続
$ ./openssl s_client -connect (ip addr):443 --tls1_3 -sigalgs RSA-PSS+SHA256:picnicl1full

この場合、OQS-httpd(apache) は、PQC 側(Picninc L1 Full)の証明書を使い、TLS 接続を確立しました。
上記クライアント側から Signature Algorithms で指定する署名アルゴリズムの順番(RSA と Picnic L1 Full のどちらを先にするか)や、apache 側の https-ssl.conf の設定の順番(RSA と Picnic L1 Full のどちらを先にするか)を変更しても、特に挙動に違いは無く、PQC 側(Picninc L1 Full)の証明書を使い、TLS 接続が確立されました。現行の OQS-httpd はそういった内部の作りになっているのかもしれません。

OQS-OpenSSL を用い、RSA と PQC の両方の署名アルゴリズムを指して接続

TLS 接続の Client Hello メッセージ中では、署名アルゴリズムとして RSA と Picnic L1 Full の2つが指定される(wireshark の表記上 Unknwon(0xfe96) となっていますが、これは Picnic L1 Full を示します)

TLS 接続の Client Hello メッセージ

Picninc L1 Full 側証明書が使用され接続

$ ./openssl s_client -connect (ip addr):443 --tls1_3 -sigalgs RSA-PSS+SHA256:picnicl1full
CONNECTED(00000003)
depth=0 CN = oqs-httpd
   ・・・
---
Certificate chain
 0 s:CN = oqs-httpd
   i:CN = oqstest CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIJ5EzCBqQIUZd・・・
-----END CERTIFICATE-----
   ・・・
Peer signature type: Picnic L1 full
Server Temp Key: X25519, 253 bits

上記は、接続に際して、既存暗号 (RSA など)と PQC の両方を使用する、いわゆる「ハイブリッド」ではありませんが、PQC 対応版の Web サーバやブラウザなどが混在する環境で、1つの利用形態にはなり得るものと想像します。

今回はここまで。

次回 : PQC 利用の OCSP レスポンダと Apache httpd の OCSP ステープリング

次回は、「PQC 利用の OCSP レスポンダ と Apache httpd の OCSP ステープリング」について解説します。

この記事の著者
 サイバートラスト R&D センター
サイバートラスト R&D センター

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

出典
[1]
"open-quantum-safe / oqs-demos"
[2]
"oqs-demos/httpd/USAGE.md", GitHub
[3]
"openquantumsafe/httpd", Open Quantum Safe
[4]
"oqs-demos/httpd/httpd-conf/", GitHub
本文書内の組織名・内容などは、掲載日時点のものとなります。また、含まれるロゴ・商標などはそれぞれの所有者に属するものとなります。なお、本内容は可能性の一つを示したもので、サイバートラストの戦略などを示すものではなく、また未来を確約するものでもありません。
デジタルトランスフォーメーションのための電子認証基盤 iTrust
SSL/TLS サーバー証明書 SureServer Prime
組込み Linux にプラスして 長期間の製品ライフサイクルをサポート EM+PLS