AKA認証とは？

AKAは、携帯電話のSIMカードと通信キャリア網の間で取り交わされる認証です。公開鍵は使わず、Kと呼ばれる128bitの共有秘密鍵を使って認証と鍵交換を実現します。このK値はSIMカード製造時に工場で書き込むもので、ユーザーの手では変更できません。

鍵交換に成功すると、以下の鍵が得られます。重要なのはCKとIKで、AKはオプションです。

|名称|名称の意味|用途|長さ|
|:--|:--|:--|:--|
|CK|Cipher Key|暗号化|128bit|
|IK|Integrity Key|メッセージ認証|128bit|
|AK|Anonymity Key|匿名化|48bit|

また、SIMカードとキャリア網で、SQNと呼ばれる48bitsのシーケンス番号を持っています。認証の都度、SQNの更新が双方で走り、常時同一値を維持するようになっています。

以上！

。。。と、これだけではあんまりなので、以下もう少し詳しく説明します。

#用語について

SIM、UIM、U-SIM、R-UIM、UICCなど、いろいろな呼び方があって、技術的にもちょっとずつ違いますが、外見は同じだし携帯端末の同じスロットに刺さって同じような役割を果たすものですので、本稿では全部SIMカードと呼ぶことにします。ただし、この言葉遣いは本当は不正確です。

#仕様書のありか

3Gの通信規格は、大まかな仕様をITU、細かい仕様を3GPP (W-CDMA) と3GPP2 (CDMA2000) で決める形になっています。4Gは、認証方式に関するところは3Gと同じ方式を踏襲しています。

3GPPの仕様書は、[3GPPのページ](http://www.3gpp.org/specifications)で情報公開されています。ページ構成がわかりにくく、ここから必要な仕様書にたどり着くのは結構難儀です。また、ちょっと古いですが、[Release 99の和訳版](http://www.qtc.jp/3GPP/japanese.html)がクインティリオン社から無償公開されています。

|番号|名称|英語|日本語参考|
|:--|:--|:--|:--|
|TS 33.102|Security Architecture|[Release 14](http://www.3gpp.org/ftp/Specs/archive/33_series/33.102/33102-e00.zip)|[Release 99](http://www.qtc.jp/3GPP/JPR99/33102-360j.pdf)|
|TS 33.103|Security Integration Guidelines|[Release 4](http://www.3gpp.org/ftp/Specs/archive/33_series/33.103/33103-420.zip)|[Release 99](http://www.qtc.jp/3GPP/JPR99/33103-340j.pdf)|
|TS 33.105|Cryptographic Algorithm Requirements|[Release 13](http://www.3gpp.org/ftp/Specs/archive/33_series/33.105/33105-d00.zip)|[Release 99](http://www.qtc.jp/3GPP/JPR99/33105-350j.pdf)|

#AKA認証のシーケンス

AKAは、SIMカードと通信キャリアのAuC (Authentication Centre) の間で取り交わされます。AuCは通信キャリアの設備で、3GならHLR、4GならHSSの機能の一つとして実装されます。途中にある携帯端末のベースバンドチップや基地局は、単にAKAトラフィックを中継するだけです。

認証までの手順は、下表のように進行します。

||MS（SIMカード）||SGSN||HLR (AuC)|
|--:|--:|:-:|:--|:-:|:--|
|1|||Authentication data request|→||
|2||||←|Authentication data response|
|3||←|User authentication request|
|4|User authenticaion response|→|

以下、順に説明します。

1. Authentication data request
2. Authentication data response
SGSNのリクエストに応じて、AuC側のSQNが更新され、端末へ送るデータ一式と、端末からの応答の予想値 (XRES) が算出されて、HLRからSGSNへと送られます。これはHLRに負荷を集中させないための措置です。ここから先の認証処理はSGSNが引き受けます。K値は秘密なのでSGSNへは送りません。
4Gの場合は、HLRをHSS、SGSNをMMEにそれぞれ読み替えて、同じような処理が走ります。

3. User authentication request
ここからが認証の本番です。
128bit乱数であるRANDを網から端末へと送出します。このとき同時に送出するAUTNは、RANDが中間者に改ざんされた場合にSIM側で見破るためのメッセージ認証コードです。
SIMカードにRANDが届きましたので、これをK値と組み合わせて共有秘密鍵CK, IK, AK、応答値RESを計算します。このときのアルゴリズムはAuCと同じです。

4. User authenticaion response
SIMカード側からRESを送信します。SGSNはこれを既に持っているXRESと比較し、合っていたら認証成功です。

以上！これで認証完了です。鍵交換で手に入った秘密値CK, IKはそのまま暗号通信の鍵として使うのではなく、さらに変換を施すのですが、その話は本稿では省略します。

#計算処理のアルゴリズム

K, RANDを元データとして、これにハッシュ関数を適用してCK, IK, AKを算出します。この計算アルゴリズムは以下の通りです。当然ながら、SIMカードとAuCで共通でなければいけません。

|パラメータ|関数名|
|:--|:--|
|CK|f3|
|IK|f4|
|AK|f5|

何の説明にもなっていませんが（汗）、f3～f5各関数は実装依存ということになっています。実装の「一例」として、MILENAGEアルゴリズムというのがあり、それは[3GPP TS 35.205～208](http://www.3gpp.org/specifications/60-confidentiality-algorithms)で規定されています。

何だか随分と無責任な書きっぷりの仕様書ですなあという気がしますが、まあ、要はMILENAGEを使っとけということです。

#AKAの携帯電話以外への応用

##EAP

IEEE802.1XでエンタープライズでRADIUS/Diameterな環境でAKA認証するという世界があるのです。このためにEAP-AKA ([RFC4187](https://tools.ietf.org/html/rfc4187)/[Google翻訳](https://rfcs.web.fc2.com/rfc4187.html)) や、その拡張であるEAP-AKA' ([RFC5448](https://tools.ietf.org/html/rfc5448)/[Google翻訳](https://rfcs.web.fc2.com/rfc5448.html)) が規格化されています。また、これとは微妙に違うEAP-SIM ([RFC4186](https://tools.ietf.org/html/rfc4186)/[Google翻訳](https://rfcs.web.fc2.com/rfc4186.html)) というのもあります。
昔販売されていたWi-Fi搭載型のガラケーは、この手のプロトコルを使って公衆無線LAN基地局との認証を実現していました。

#NFC

ISO/IEC 14443 Type A/Bにに対応した携帯電話を読み取り機にかざすと、SIMカードからの通信が読み取り機を経由して通信キャリアのAuCまで届き、AKA認証が走ります。そのため、Type A/Bでは、端末からSIMカードを抜き取ると、NFCが使えなくなります。もっとも、ご存知の通り日本ではさっぱり普及していません。

##HTTP Digest AKA

HTTPのDigest認証でAKAをやるというのが[RFC3310](https://tools.ietf.org/html/rfc3310)/[Google翻訳](https://rfcs.web.fc2.com/rfc3310.html)として規格化されています。もっとも、これが使われているのを見たことってあります？私はありません。

##その他

なぜか、TLSの認証と鍵交換にAKAを使う規格がありません。ありそうなのに。

#Q&A

##Q1. わかりにくい。なぜこんなに変な略語が多いのか。

ですよねー。3GPPもITUも、いつもこんな調子です。

##Q2. AKA認証はセキュアなのか。

いろいろな観点があると思います。以下思いつくままに。

###Q2.1. 鍵の長さはこれで大丈夫なのか。

今のところは大丈夫ですが、将来はわかりません。あまりにも多くのパラメータが128bits固定ですから、これを例えば256bitsにするとなると、大改造手術が必要になってしまいます。しかし、SIMカードのハードウェア仕様をいじくるのは骨ですよね。
とはいえ、今までにもGSMから3Gの大改造手術を乗り切って来た実績ある業界ですから、まあ何とかなるさ、という感じではないかと。

###Q2.2. 共有秘密鍵の秘密は守られるのか。

K値が漏洩したらAKAのセキュリティはお終いです。
K値はSIMカード内と通信キャリアのAuCにインストールされますが、Kasperskyブログの[SIMカード情報の大量漏えいという悪夢](https://blog.kaspersky.co.jp/gemalto-sim-hack/6973/)という記事によると、SIMカードの製造メーカーから漏洩してしまう場合があるらしく、やはり万全ではないようです。

###Q2.3. 乱数がサーバ側からしか供給されないが、これで大丈夫なのか。

TLSは、ClientHelloとServerHelloで256bits乱数をクライアント・サーバの両方から提示し、さらに鍵交換では別の乱数を使うという念の入れようですから、それに比べるとサーバ側からしか乱数を出さないAKAは、そのサーバがなりすましだった場合にクライアント側で見破れるのか？というのは誰しも気になるところだと思います。

プロトコルの設計としては、48bitsのSQNが一種の共有秘密の役割を果たします。攻撃者の偽AuCがリプレイ攻撃を仕掛けたくても、攻撃者はSQNの更新後の値を知る手段がありませんので、AUTNを正しく作れません。したがってSIMカードの実装が正しければ、AUTNの検証で見破れます。もちろん、SQN値の秘密が守られることが大前提です。

###Q2.4. MILENAGEアルゴリズムとかいうのはセキュアなのか。

よくわかりません（汗）。今のところ、危殆化したという話は聞きませんが。。。

そんなところです。

##Q3. AKA認証を理解すると、何のご利益があるのか。

例えば、NTTドコモがIIJなどのMVNOに、「HLR/HSS連携」を可能にする、との報道がありましたでしょ。HLR/HSSにはいろいろな機能がありますが、AKAの仕組みを理解すれば、AuCとSIMカードはセットですから、AuCが手に入ればSIMカードの発行権も手に入ることがすんなり理解できます。

というわけで、ちょっとニュースに強くなれます。

#参考文献

3GPP W-CDMA 仕様書の日本語翻訳
(株)QT
http://115.125.87.227/3GPP/japanese.html

Alf Zugenmaier, 青野 博
SAE/LTEを実現するセキュリティ技術
NTTドコモ
https://www.nttdocomo.co.jp/binary/pdf/corporate/technology/rd/technical_journal/bn/vol17_3/vol17_3_027jp.pdf