組み込み機器向けに量子乱数を送る「Post‑Quantum Entropy as a Service」をESP32で実証
この論文は、量子乱数発生器(QRNG: 量子乱数発生器)由来の良質な乱数(エントロピー)を、ポスト量子暗号(PQC: 量子耐性を持つ暗号)で保護した経路を使って小型機器に届ける仕組みを示します。研究チームはサーバー側でQRNG(Quantis PCIe‑240M)から乱数を取り出
この論文は、量子乱数発生器(QRNG: 量子乱数発生器)由来の良質な乱数(エントロピー)を、ポスト量子暗号(PQC: 量子耐性を持つ暗号)で保護した経路を使って小型機器に届ける仕組みを示します。研究チームはサーバー側でQRNG(Quantis PCIe‑240M)から乱数を取り出し、ESP32クラスのクライアントにCoAP(制約環境向けアプリケーションプロトコル)経由で配信する実装を作りました。主要なベンチマークでは、ポスト量子の鍵共有と署名の組合せが、同じ条件下の従来方式よりも高速であることが示されました。
作ったシステム(QEaaS: Quantum Entropy as a Service)は二つのサーバー側経路を提供します。一つはカスタムのOpenSSLプロバイダ経由でQRNGの生データへ直接アクセスする経路、もう一つはrng‑toolsでQRNGをLinuxのエントロピープールに混ぜてから供給する経路です。利用したQuantis PCIe‑240Mは光子検出に基づく装置で、後処理を経て58 Mbpsの乱数を出力し、NISTの基準(SP800‑90A/B/C と SP800‑22)に準拠します。実装にはCoAP→HTTPを仲介するプロキシも含まれ、HTTP側はNginxとカスタムプロバイダを使って動作します。チェックインされた実装では、APIが/dev/urandom(混合されたLinuxエントロピープール)を読んで応答する設定になっている点も注記されています。
クライアント側はESP32マイコン(デュアルコア Xtensa LX6、240 MHz、520 kB SRAM、4 MBフラッシュ)で、RTOSはZephyrを使います。libcoapのZephyrサポート拡張と、wolfSSLを使ったDTLS(Datagram Transport Layer Security)1.3の統合を行い、CoAPスタック上でポスト量子のML‑KEM(鍵取り出し、論文はFIPS203相当)とML‑DSA‑44(電子署名、FIPS204相当)を動かせるようにしました。また、ローカルで使うエントロピープールとしてBLAKE2sベースの実装を追加し、既存のZephyrの取り出しインタフェースを保ったまま、サーバー由来の乱数を注入するAPIも提供します。プールは512バイトを保持し、128バイトでリフィルする設計です。
評価は同一LAN内のWi‑Fi環境で行い、各構成で100回の反復を測定しました。代表的な結果は次の通りです。ポスト量子の鍵共有アルゴリズムML‑KEM‑512単体では、証明書検証なしのDTLS 1.3ハンドシェイクが平均313 msで完了し、従来のECDHE P‑256より約35%高速でした。さらにML‑KEM‑512とポスト量子署名のML‑DSA‑44を組み合わせると平均225 msまで短縮されます。証明書検証を行うと、ECDSAでは約194 msの上乗せが必要でしたが、ML‑DSA‑44では約17 msの追加にとどまり、完全にポスト量子の構成は完全検証下でも従来のECDHE P‑256+ECDSAより約63%高速でした。ローカルのBLAKE2sプール操作は合計で0.1 ms未満に収まっています。実装面では静的DRAM使用量が約187 kB(ESP32の192 kBのほぼ全域)に達し、フラッシュは構成により約855–888 kBでした。
この仕事が重要な理由は、組み込み機器の暗号が乱数の品質に強く依存する点にあります。小型機器は信頼できる乱数源が限られるため、外部のQRNGを安全に利用できれば鍵生成などの安全性を高められます。また、配信路をポスト量子暗号で保護することで、将来の量子攻撃にも備えられます。一方で重要な注意点もあります。本稿の評価は特定のハードウェア(Quantis PCIe‑240M と ESP32)と同一LAN内の条件で行われており、インターネット越しや別のマイコン環境では遅延やメモリ制約の影響が変わる可能性があります。加えて、チェックインされたHTTP APIは現状/dev/urandomを読んでおり、直接/dev/qrandom0をそのまま公開しているわけではない実装差がある点も留意が必要です。