5Gの「信頼」をハックする:5G-AKAと鍵導出階層の深淵を覗く
現場で「なぜこの端末がネットワークに繋がらないのか」と頭を抱えたとき、たいていのトラブルは物理層や電波強度ではなく、論理的な認証プロセスのどこかでパケットが迷子になっているものです。
今日は、5Gネットワークの根幹を支える「5G-AKA(Authentication and Key Agreement)」と、その鍵導出のメカニズムについて、仕様書の堅苦しい記述を剥ぎ取って、エンジニアの視点で紐解いていきましょう。
—
1. そもそもなぜ「5G-AKA」なのか?
4G(LTE)のEPS-AKAから5G-AKAへと進化する過程で、最も重要な変更点は「ホームネットワークによる厳格な認証」です。
5Gでは、UE(端末)が認証要求を出す際、ホームネットワーク(HSS/UDM)が確実に「この端末は本物か?」を検証します。このプロセスで使われるのが 5G-AKA です。ここで鍵となるのが EAP-AKA'(RFC 5448)であり、単なるパスワード認証とは異なり、USIMの中にある秘密鍵 K をベースにした厳密な暗号学的チャレンジ・レスポンス方式を採用しています。
—
2. 鍵導出階層のリアル:K から K_seaf へ
認証が成功すると、ネットワークと端末の間で共通の「マスター鍵」が生成されます。しかし、現代のネットワークにおいて、ルートとなる秘密鍵をそのまま使い続けるのは自殺行為です。そこで「鍵の階層化」という手法が取られます。
これを理解するための鍵の導出順序は、トラブルシューティングの際、どの階層でセッションが切れているかを特定する地図になります。
1. K: USIMとUDM(Unified Data Management)にのみ存在するマスター鍵。
2. CK, IK: 認証の過程で生成される鍵。
3. K_ausf: 認証サーバ(AUSF)レベルの鍵。
4. K_seaf: セキュリティアンカー機能(SEAF)の鍵。ここが、アクセスネットワーク(AMF)とホームネットワークの境界線です。
5. K_amf: アクセスモビリティ管理機能(AMF)で使われる鍵。
実務の勘所:
もし接続に失敗している場合、K_seaf が正しく導出されているかを確認するのが先決です。これらは KDF(Key Derivation Function)というアルゴリズムで、SHA-256をベースに構築されています。
—
3. 実務で役立つデバッグ:PythonによるKDFのシミュレーション
インフラエンジニアとしては、認証失敗のログを解析する際、「本当にこの鍵が導出されるのか?」を再現したくなるはずです。Pythonの hmac モジュールを使って、簡易的に鍵の導出プロセスをシミュレートしてみましょう。
import hmac
import hashlib
# 簡易的なKDF(HMAC-SHA256)のデモンストレーション
def derive_key(key, data):
"""
KDF(鍵導出関数)の概念コード
実際には3GPP TS 33.501に従い、定数やパディングが含まれます
"""
# 鍵(K)と入力データから新しい鍵を生成
# 実際にはK_seaf = HMAC-SHA256(K_ausf, P0) のような計算を行う
mac = hmac.new(key, data, hashlib.sha256)
return mac.digest()
# 使用例
master_key = b'super_secret_k_value_from_usim'
context = b'network_identity_and_nonce'
k_seaf = derive_key(master_key, context)
print(f"導出されたK_seaf: {k_seaf.hex()}")
—
4. ネットワークエンジニアのためのデバッグTips
実務で5GコアのAPIやパケットを眺める際、特に注目すべきは HTTP/2 のヘッダーや、SBI(Service Based Interface)の通信です。5Gコア(5GC)はRESTfulな設計になっており、UDM や AUSF とのやり取りは JSON で行われます。
curl を使った5Gコアの認証APIのシミュレート例
もし皆さんがプライベート5G環境などで、認証ステータスをAPIで叩く場合、以下のような構成が基本となります。
# 認証ステータスを確認する例
# 実際にはOAuth2等のトークン認証が必須です
curl -X GET "https://udm-service.5gc.local:8080/nudm-ueau/v1/{ueId}/auth-events" \
-H "Authorization: Bearer <JWT_TOKEN>" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
# 失敗時はここを確認:401 Unauthorizedなら秘密鍵の不一致
# 403 Forbiddenなら権限設定の問題
—
5. 最後に:泥臭い現場の教訓
私がこれまで数多くのキャリアやプライベート5Gの構築に携わってきて痛感するのは、「仕様書通りに組んでも、USIMのプロファイルとネットワーク設定の『微細なズレ』が命取りになる」ということです。
- SQN(Sequence Number)の同期不一致:
USIM側とコアネットワーク側で SQN がずれると、認証は即座に拒否されます。ログに MAC failure や Sync failure が出たら、まずはこのカウンターを確認してください。
- 暗号アルゴリズムの不一致:
UEが 5G-AKA をサポートしていても、コアネットワーク側で許可されているアルゴリズム(NEAやNIA)とのネゴシエーションが失敗することがよくあります。
ネットワークは生き物です。パケットが AMF を叩き、UDM で鍵を照合し、K_seaf が生成されるその瞬間の「息吹」を感じられるようになれば、どんなトラブルも解決できるはずです。
次回は、これらの通信フローを Wireshark でキャプチャする際、どのパケットをフィルタリングすべきか、より実践的なキャプチャ技術についてお話ししましょう。現場からは以上です。
コメント