フリーWi-Fi向け新規格「Wi-Fi CERTIFIED Enhanced Open」、盗聴の恐れがある通信路で秘密鍵を安全に共有

「Diffie-Hellman（DH）」のアルゴリズムで鍵を共有するOWEの仕様、RFC8110で定義

　「Wi-Fi CERTIFIED Enhanced Open」の仕様書は、"Opportunistic Wireless Encryption Specification Version 1.0"としてWi-Fi Allianceから公開されているが、わずか7ページというシンプルなものであり、しかも「OWE（Opportunistic Wireless Encryption）」の説明に費やされているのは、このうち2ページだけしかない。もっとも、OWEの仕様そのものは、「RFC8110」で定義されていて、これがそのまま利用されているためでもある。そのRFC8110自体も、わずか12ページというシンプルなものである。

　RFC8110で定義されたOWEの仕様では、「Diffie-Hellman（DH）」の鍵交換アルゴリズムを利用して、鍵の共有を行う仕組みとなっている。これは1976年にスタンフォード大のWhitfield Diffie氏とMartin Hellman氏が発明した方式で、事前に鍵を共有することなく、盗聴の恐れがある通信路を利用して秘密鍵を安全に共有できるというものだ。

Whitfield Diffie氏

Martin Hellman氏

DH法の肝は、逆関数の計算が非常に困難な「一方向性関数」の利用

　DH法の肝は、関数そのものは簡単に計算できるが、逆関数の計算が非常に困難な「一方向性関数」を利用することだ。DHの場合、まず最初に非常に大きな素数pと任意の整数gを用意する。これらは公開されても構わない。通信路の両側に存在するXとYは、1以上でp-2未満の任意の数字a,bをそれぞれ勝手に定めるものとし、このa,bを秘密鍵とする。これを定めた後に、それぞれ以下を計算し、お互いに交換し合う。

• X:A=g^a mod p(gのa乗をpで割った余り)
• Y:B=g^b mod p(gのb乗をpで割った余り)

このA,Bが公開鍵となり、それを交換し終わったら、次に以下を計算する。

• X:Ka=B^a mod p(Bのa乗をpで割った余り)
• Y:Kb=A^b mod p(Aのb乗をpで割った余り)

　実はこのKaとKbは、一致することが数学的に証明されている。これにより、このKa/Kbをそのまま共通の鍵として利用できるという仕組みだ。

　これが「盗聴に対して安全」と言えるのは、一方向性関数の特徴による。例えばgを5、pを7としてみよう。aが3、bが2だとすると、以下の式のようになる。

• A=5^3 mod 7 = 6
• B=5^2 mod 7 = 4

　通信路には、この6と4のみが流されるかたちになる。問題は、これを傍受したからといって、aとbを推定するのは非常に難しいことだ。傍受した側は、以下の式を解いてmとnを定めるわけだ。

• 6=5^m mod 7
• 4=5^n mod 7

　しかし、このmやnを求めるには、1から順番に数字を当てはめて結果が一致するかを調べねばならず、方程式を解くようには計算できない。

　今回は、pが7と小さいため範囲は1～5の間で済むが、これが99999989（8桁で最大の素数）とかであれば、最も多い場合で、ほぼ1億回計算をしないと答えが求められないことになる。十分に大きな素数（DHでは8桁という縛りはないため、さらに大きな数にすることも可能）にすれば、1回の値の交換で鍵が破られる可能性は、限りなく低くなるというわけだ。

　1997年に、このDHはアルゴリズムの特許期限が切れた関係で、現在ではさまざまな用途で利用されている。また、この功績を称え、2人は「ACM（Association for Compution Machinery）」の「Paris Kanellakis Theory and Practice Award」を1996年に受賞している。

ACM（Association for Compution Machinery）の「Paris Kanellakis Theory and Practice Award」のウェブページ

DHを利用した鍵交換の4-way Handshakeをサポートするのが、OWEの必須要件

　というわけで話を戻すと、OWEでは、このDHを利用して共通の秘密鍵を共有する仕組みとなっており、このDHを利用した鍵交換の4-way Handshakeをサポートするのが、OWEにとって必須要件となる。また、暗号化方式としては「楕円曲線暗号」（ECC：Elliptic Curve Cryptography）と「有限体暗号」（FFC：Finite Field Crytography）の2種類をサポートし、その際のハッシュの種類は、それぞれの暗号化に利用される素数のサイズ（bit長）に応じて、以下のように定められている。

　プロトコルの側の変更としては、まずクライアントに対してOWEをサポートしたアクセスポイントであることを示す「OUI（Organizationally Unique Identifier）」が追加された。また、Associationの際にDHを利用するために、「Diffele-Hellman Parameter Element」が新たに追加されている。また、Associationが終わった後に共有鍵（PMK）を生成する方式は、（DHによって生成された共通する）秘密鍵をx、共有鍵をYとしたときに、以下の方法で行うことが規定されている。

• z = F(DH(x, Y))
• prk = HKDF-extract(C | A | group, z)
• PMK = HKDF-expand(prk, "OWE Key Generation", n)

　この「HKDF-extract()」や「HKDF-expantion()」は、「RFC5869」で規定されている方式をそのまま使うことが定められている。

　というわけで、OWEはDHの実装がメインであり、既存の製品に大きく手を入れなくても済むように考慮されている。DH自身も実装そのものはそれほど難しくなく、基本的には乗算と減算だけで実行できる。もっとも、べき乗の計算や、mod（剰余演算）は、単純ながら高速化が難しい処理の代表例でもある。

Wi-Fi CERTIFIED Enhanced Open対応製品の登場は、今年末から来年以降

　実際、TLS/SSLなどにおいてDHを用いると、スループットが1/6程度まで落ちる、という話もある。しかし、OWEに関して言えば、そこまで煩雑にDHを使うわけではないし、昨今ではアクセスポイントにせよ、情報家電とかIoTデバイスは例外としてクライアントにせよ、それなりに高速なので、計算負荷はそれほど大きくないとみなされたようだ。

　ただ、何しろ発表されたばかりの規格であり、しかもアクセスポイントとクライアントの両方がこれに対応して、DHを利用したOWEのプロトコル拡張をサポートしなければならない関係で、どの程度普及するかは、まだ未知数だ。

　というのも、Wi-Fi Allianceによって、OWEを搭載した製品に対して、それが正しくインプリメントされていることを認証するOWEのCertificationが行われてはいるが、アクセスポイントに対してOWEのインプリメントを強制するかたちとはなっていないようで、どの程度のアクセスポイントがOWE、つまりWi-Fi CERTIFIED Enhanced Openに準拠するかは、現時点では未知数なためだ。

　Wi-Fi AllianceのProduct FinderでWi-Fi CERTIFIED Enhanced Open対応の製品は、この原稿の執筆時点では0。早くても今年末、実際には来年以降にならないと製品が出てこないように思われる。

　そして、クライアントの対応はさらに遅れるだろう。OWE対応アクセスポイントがない状況では、クライアント側で対応する動機が非常に小さくなるのは仕方がないことである。今後は、どうやってこのWi-Fi CERTIFIED Enhanced Openを普及させていくのかに、Wi-Fi Allianceの活動の焦点は移っていくのだろう。