キャリアWi-Fiでおなじみ(?)のSIM認証ですが、そのプライバシ保護についての話です。最近のスマートフォンでは、MACアドレスランダム化が実装されていて、第三者による端末追跡を困難とすることによって、プライバシ保護が実現されています。ところが、MACアドレスランダム化だけでは不十分でした。
この一年ほどの間に、Wi-Fi業界では(Google主導で) "IMSI Privacy Protection" と呼ばれる仕組みが議論されていて、これから端末などに実装されようとしています。その概略を紹介します。
[2021/6/18] 今後この方式が標準になるかどうかは未確認で進行形。
※ IMSI: International Mobile Subscriber Identity; 国際的な加入者識別番号で、携帯電話の契約時に割り当てられ、SIMに書き込まれる。英語ではイムズィのように読む。
詳しい概略(?)はWireless Broadband Allianceのウェブサイトからダウンロードできます(要登録)。多少長い英文でもざくざく読んでいける人は、ここで当エントリはやめて、ソースを参照した方が確実でしょう。英文ソースの翻訳を記事にするつもりはなく、あくまで「こんなのもあるよ」程度の安い記事なので。
とりあえず日本語でざっくり掴みたい人は、この先へどうぞ。
どのようなプライバシ問題か
無線LANのプライバシ問題やその対策について、以前にいくつか記事を書きました。
今回はどのようなプライバシ問題かというと、フリーWi-Fiでおなじみの、「端末(利用者)追跡」です。前の記事に書いたように、すべての追跡が悪いわけではないのですが、利用者の承諾もなしに追跡できてしまうことがプライバシ上の懸念となります。
何が問題だったのか
前の記事では、認証方式としてEAP-TTLSやPEAPが使われている場合について書きました。SIM認証では方式が違い、EAP-SIM, EAP-AKA, EAP-AKA'が使われています。このうち、最近ではEAP-AKAまたはAKA'を使うのが一般的です。
これらのSIM認証方式では、EAPトンネルやouter identityといったものはなく、利用者の識別情報が平文で空中を飛ぶことになります。具体的には、識別情報として使われるIMSIが、暗号化されない形で利用されていました。
基地局(AP)の中にあるオーセンティケータと端末の間では、次のようなやり取りがあります。まず、オーセンティケータから端末に対して、EAP-Request/Identityというメッセージが送られます。これに対して、端末はEAP-Response/Identityを返しますが、このとき <prefix><IMSI>@<NAI realm> の形式で識別情報が渡されます(*1)。NAI realmは、 wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org の形式で、MNCがMobile Network Code、MCCがMobile Country Code (両方を合わせてPLMN-IDと呼ばれる)を表します。
IMSIが平文のままだと、どのようなプライバシ上の問題が生じるでしょうか？
悪意ある攻撃者が、キャリアWi-Fiの利用者の無線通信を傍受していたり、キャリアWi-Fiを装った偽基地局を設置していたりすると、利用者が気付かないうちに、IMSIが攻撃者に知られることになります。攻撃者と書きましたが、実は、こっそりと無線LANの利用者を追跡しようとしている、追跡ビジネスかもしれません。
IMSIは利用者に振られた永続的なIDなので、それが書き込まれたSIMを使い続ける限り、地球の裏側まで追跡されうるということです。
[2021/6/18追記] *1: 一部の端末は、どのSSIDに対しても1X認証で接続を試みるようです。そのため、WPA2 Enterpriseの無線LANシステムを運用していると、通りすがりの人のものと思しき端末から接続が試行され、RADIUS proxyのログに 3gppnetwork.org のレルムでLogin incorrectの記録が残ります (キャリアのIdPに接続されていないためOKは出ない)。このログでは、prefix+IMSIが丸見えのものが多数ですが、以下のようにユーザ名部分が匿名になっているものもあります。手元の2019年のログには既に匿名のものが見えます。(詳細は調べ切れていません)
- aka_anonymous@wlan.mnc010.mcc440.3gppnetwork.org (ドコモ)
- sim-encr_softbank@wlan.mnc020.mcc440.3gppnetwork.org (ソフトバンク)
- anonymous@wlan.mnc260.mcc310.3gppnetwork.org (T-Mobile US)
EAP-AKAの場合
端末は、EAP-Request/Identityを蹴ることができるようです。
Ω ΩΩ＜な、なんだってー!!!
ところが、この蹴り方がきちんと定義されていなくて(ぇ?)、下手に応答しないように実装すると、接続できない問題が生じるようです。
EAP-AKAの場合、続いてオーセンティケータからEAP-Request/AKA-Identity (AT_PERMANENT_ID_REQ) が送出され、端末がEAP-Response/AKA-Identityを返します。これには AT_IDENTITY が含まれており、形式はこれまた <prefix><IMSI>@<NAI realm> です。(ダメじゃん)
一応、AT_IDENTITY に仮名ID (pseudonym)を返す方法も規定されていますが、認証成功のためには後に素のIMSIを送ることになって、全然保護になっていません。(この辺はざっくり省略)
IMSI暗号化によるプライバシ保護
そこで、どうするかというと、認証に必要なIMSIを含むPermanent Identityを RSAES-OAEP（Optimal Asymmetric Encryption Padding, Sect. 7.1 of RFC8017) を使って暗号化します。ここで、暗号文にランダム性が入るのがキモです。
Permanent Identity = <IMSI>@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org
Encrypted Permanent Identity = Base64(RSA-OAEP-SHA-256(Permanent Identity))
端末は、こうして得られたEncrypted Permanent Identityを AT_IDENTITY に詰めて、オーセンティケータに送り返します。このときの AT_IDENTITY の形式は、`\0`<Encrypted Permanent Identity><,<attribute>=<value>>となります。IMSIがランダム性を含む暗号に変換されているため、盗聴されても追跡が困難になります。
RSAの鍵を扱うために、公開鍵暗号基盤 (PKI) を使います。
# おうふ、また鬼門のPKIか_('､3｣∠)_
終
