第６話： PQC 利用の OCSP レスポンダと Apache httpd の OCSP ステープリング

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

Open Quantum Safe project / OpenSSL や Demo

OQS-demos の続き

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

PQC 対応の OpenSSL や Apache httpd については、OCSP (Online Certificate Status Protocol) まわりについても特に普通に動くのかを確認してみることにしました。具体的には、以下のように Apache 側で OCSP ステープリングの設定を行いました。これにより、クライアント側（ブラウザ）が Web サーバの証明書（TLS 証明書）の有効性を認証局の OCSP レスポンダに直接問合せなくても、Web サーバ側で問い合わせてキャッシュ（ステープリング）しておいた結果が、TLS 接続のやり取りの中で webサーバからクライアントに渡されるようになります。これらを、既存暗号と PQC を使ったコンポジット証明書を使い、確認してみました。ここで、TLS 証明書だけでなく、OCSP レスポンダも、既存暗号と PQC のコンポジットを使ってみました。なお、実際には、既存暗号としては RSA 3072bit、PQC としては Picnic L1 Full を用いてみました。

PQC/既存暗号コンポジットでのOCSPステープリング

なお、上の図で、それぞれのエンティティは、以下で実現しています。

Web サーバ ：docker 上で OQS-demo / httpd を稼働させて利用
OCSP レスポンダ ： PQC 対応版 OpenSSL (OQS-OpenSSL) を利用（./openssl ocsp コマンド利用）
クライアント ： PQC 対応版 OpenSSL (OQS-OpenSSL) を利用（./openssl s_client コマンド利用）

なお、クライアント環境は、PQC 対応版の chromium を試してみたいところでしたが、コンポジット証明書に未対応のため、ここではクライアント側も PQC 対応版 openssl を使い、-status オプションを付けて確認しています。

それぞれのポイントとなる設定ですが・・
Web サーバは、httpd の設定として、httpd-ssl.conf の中で、サーバ証明書関連のコンポジットの鍵と証明書の指定と、OCSP ステープリング関連の設定が必用となります。

SSLCertificateFile    "/opt/httpd/pki/rsa3072_picnicl1full_srv.crt"
SSLCertificateKeyFile "/opt/httpd/pki/rsa3072_picnicl1full_srv.key"
　　・・・
SSLUseStapling On
SSLStaplingCache "shmcb:/tmp/ssl_stapling_cache(32768)"

また、上記で設定する Web サーバ証明書には、AIA（Authority Information Access）extension という、OCSP レスポンダの問合せ先（接続先 URL）情報を記載しておく必要があります。実際には、サーバ証明書の拡張領域の設定を指定した x509.ext ファイルを用意し、openssl x509 コマンドの引数として、-extfile x509.ext -extensions server と指定してサーバ証明書を作成することで、AIA extension を含めることができます。

[ server ]
basicConstraints = critical,CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
authorityInfoAccess = OCSP;URI:http://　（OCSP レスポンダの FQDN）　/

発行されたサーバ証明書の拡張領域は以下のように AIA extension が含まれます。

        X509v3 extensions:
　　　　　　　　・・・（略）・・・
            Authority Information Access:
                OCSP - URI:http:// 　（OCSP レスポンダの FQDN）　/

次に、OCSP レスポンダですが、OCSP レスポンダには、自身が使用する鍵・証明書を用意する必要があります。
また、その OCSP レスポンダ証明書は、その仕様上、証明書拡張領域は以下のような値がセットされているべきでしょう。

        X509v3 extensions:
　　　　　　　　・・・（略）・・・
            X509v3 Extended Key Usage:
                OCSP Signing
            OCSP No Check:

ということで、前述のサーバ証明書の作成と同様に、x509_ocsp.ext ファイルとして以下のような内容を含むものを用意し、openssl x509 コマンドの引数として、-extfile x509_ocsp.ext を指定して OCSP レスポンダ証明書を作成します。

　・・・
extendedKeyUsage = OCSPSigning
noCheck = ignored

なお、今回はコンポジットということで、鍵の生成では、openssl req の引数として、-newkey RSA3072_picnicl1full を指定して OCSP レスポンダ用の鍵ペアと CSR　を作成しています。

以上を利用してコンポジット証明書を利用した OCSP と httpd（OCSP ステープリング設定あり）とを稼働させ、クライアントとして openssl で以下のように -status（OCSP ステープリング情報も確認する）オプション付きで、Web サーバに接続を行ってみました。

$ ./openssl s_client -connect ( 接続先 FQDN):443  --tls1_3  -status

結果としては以下のように、OCSP ステープリング結果が含まれて、Web サーバへの TLS 接続が確認できました。

CONNECTED(00000003)
　　・・・
OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = JP, ST = Some-State, O = Cybertrust Japan Co Ltd TEST PQC, OU = Test Purpose Only, CN = PQC RSA3072 PicnicL1Full OCSP
    Produced At: May ・・ ・・:・・:・・ 2022 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: B58D・・・・・・・・・・・・・・・・・・・・・
      Issuer Key Hash: 2766・・・・・・・・・・・・・・・・・・・・・
      Serial Number: 62C2・・・・・・・・・・・・・・・・・・・・・
    Cert Status: unknown
    This Update: May ・・ ・・:・・:・・ 2022 GMT

    Signature Algorithm: rsa3072_picnicl1full
         00:00:01:80:b4:　・・・

ひとまず、OQS-OpenSSL による OCSP レスポンダは、OCSP のリクエストを受けて応答を返し、OQS-demos / httpd は OCSP ステープリングを行い、クライアントからの TLS 接続に際して、キャッシュした OCSP レスポンスも一緒に返しており、RSA3072_picnincl1full のコンポジット証明書でも、これらは基本的には正常に動くようです。

ただ１点、良く見ると、上記の応答中で OCSP レスポンスの status が unknown となっており、本来は good（有効）が返ってきて欲しいところです。OCSP レスポンダとしての OpenSSL は一般には index.txt か、-index という引数で指定したファイル（database）を参照して、この内容を元に証明書の有効・失効・期限切れなどを判断して、応答を返すのですが、上記設定では、この database 指定がうまく行われていなかったようです。

ただ、index.txt に証明書発行情報を含めると、どうもうまく OCSP が起動しない。ここだけは今後確認するとして、これを除くと、仕様上は PQC に関しては特段何も定まっていない OCSP についても、OQS プロジェクトの実装から想像するに、少なくとも従来仕様をシンプルに PQC（コンポジット含む）に拡張した形では動作するようになるのだろうと想像します。

おわりに

耐量子計算機暗号 (PQC) についての NIST の標準化に並行して、実装面での実証実験として Open Quantum Safe project が公開している PQC 対応版の OpenSSL や Apache、Chromium などを用いて、どの程度まで PQC を用いた暗号処理や暗号通信が実装できているのか、技術者目線で確認した結果が以上となります。商用利用を保証するものではないですし、また、仕様上もこれまで記載の通り、提案段階の複数仕様案がある状態である点は要注意ですが、PQC が実用化された状態をイメージする上では十分なものを感じました。

この「おわりに」を記載している今も、まだ NIST からは特段の発表はありません。
サイバートラスト R&D センターでは、今後も引き続き NIST の PQC 標準化動向などをウオッチしつつ、今回のように関連するちょっとした動作確認結果なども紹介 / 共有していければと思います。

この記事の著者

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

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

本文書内の組織名・内容などは、掲載日時点のものとなります。また、含まれるロゴ・商標などはそれぞれの所有者に属するものとなります。なお、本内容は可能性の一つを示したもので、サイバートラストの戦略などを示すものではなく、また未来を確約するものでもありません。