5G時代の「見えない盾」を紐解く:NAS・ASセキュリティの鍵生成プロセスを現場目線で解説する
「通信が繋がった」という瞬間、我々のデバイスと基地局の間では、目に見えないところで凄まじい数学的儀式が行われています。APIのデバッグでAuthorizationヘッダーに悩み、インフラ構築でTLS証明書の更新に追われる皆さんなら、OSI参照モデルのさらに下、モバイルネットワークの根幹を支える「鍵生成」のプロセスに興味があるはずです。
今日は、USIMカードという小さなシリコンの塊と、広大なコアネットワーク(5GC)が、どうやって信頼を確立しているのか。NAS(Non-Access Stratum)とAS(Access Stratum)のセキュリティキー生成という、少し泥臭い、しかし極めて重要なプロセスを紐解いていきましょう。
—
1. 信頼の源泉:根幹鍵「K」の役割
モバイル通信のセキュリティは、物理的なUSIMカード内に焼き込まれた「K(根幹鍵)」から始まります。これは、世界中のどのネットワークエンジニアも直接触れることができない、まさに「聖域」です。
認証プロセスにおいて、コアネットワーク(AUSF/UDM)とUSIMは、このKをベースにして、一時的なセッション鍵を導出します。ここで重要なのは、「鍵そのものは決して無線区間を流れない」という原則です。流れるのは、鍵を使って計算された「チャレンジ」に対する「レスポンス」だけ。この設計こそが、4G/5Gが何十億台ものデバイスを安全に収容できている理由です。
—
2. NASとAS:役割分担のセキュリティ
セキュリティ層は大きく分けて2つあります。
- NAS(Non-Access Stratum)層: UE(端末)とコアネットワーク(AMF)間の通信を守る。信号の完全性と暗号化を担当します。
- AS(Access Stratum)層: UEと基地局(gNB)間の無線区間を守る。ユーザーデータやRRCシグナリングを保護します。
現場でトラブルシューティングをしていると、「NAS層の認証エラーなのか、AS層の暗号化の不一致なのか」を切り分けるのが最初の壁になります。NASは「エンドツーエンドの契約者保護」、ASは「無線区間の物理的な盗聴対策」と捉えてください。
—
3. 鍵導出のシーケンス:Kから鍵を生成する
鍵の導出にはKDF(Key Derivation Function)が使われます。以下のPython擬似コードは、このプロセスを概念的に示したものです。
# 鍵導出の概念的なプロセス
def derive_key(base_key, context_string, algorithm_type):
"""
KDF(Key Derivation Function)の簡略版
実務ではSHA-256やHMACが多用されます
"""
# 実際にはここでRAND, AUTN, SQNなどのパラメータが入力される
# 入力値を結合し、HMAC-SHA256でハッシュ化
derived_key = hmac.new(base_key, context_string.encode(), hashlib.sha256).digest()
return derived_key
# 5GにおけるNAS用鍵の導出例
nas_encryption_key = derive_key(kamf, "NAS_Encryption_Algorithm_ID", "AES-128-CTR")
# 5GにおけるAS用鍵の導出例
as_encryption_key = derive_key(knp, "AS_Encryption_Algorithm_ID", "AES-128-GCM")
実務でパケットキャプチャ(Wireshark等)を眺めると、NAS Security Mode Commandというパケットが見えるはずです。ここでネットワーク側は「どのアルゴリズムを使うか」をUEに指示し、UEは導出した鍵を使ってその後の通信を保護し始めます。
—
4. エンジニアが知るべき「現場のTips」
Web API設計におけるOAuth2.0のスコープ管理と似ているようで、モバイル通信の鍵管理はもっと「物理的」です。実務において、暗号化関連のトラブル(例えば、特定基地局で通信が切れる、あるいはハンドオーバーで切断される)が発生した際は、以下のポイントを疑ってください。
- アルゴリズムの不一致: キャリア側が
NEA2(128-bit SNOW 3G)を要求しているのに、UE側がNEA1しかサポートしていない場合、認証後に通信が即時切断されます。PCAP上でSecurity Mode Rejectが飛んでいないか確認しましょう。 - SQN(Sequence Number)の同期ズレ: USIMとネットワークの間でシーケンス番号がズレると、再同期プロセスが発生します。古いログを残したままSIMを入れ替える際などによく起こる事象です。
- 鍵の更新タイミング:
AS鍵はハンドオーバーのたびに更新される(KeNBやKgNBの更新)ため、電波状況が悪い場所では鍵更新の失敗が輻輳の一因になることがあります。
—
5. 最後に:インフラ屋としての視点
APIでJWTを扱うとき、私たちは「署名」が正しいことを期待しますよね。モバイルネットワークでは、その「署名」に相当する処理が、ハードウェアレベルで、かつミリ秒単位のシグナリングの中で行われています。
もし皆さんが今後、IoTデバイスの設計やプライベート5Gの導入に関わるのであれば、まずは「NAS/ASのセキュリティモードが正常に完了しているか」をログから読み解く力を養ってください。通信が暗号化されるその一瞬のやり取りに、エンジニアの美学が詰まっています。
ネットワークのトラブルは、多くの場合「仕様の解釈違い」か「鍵導出のパラメーターミス」に帰結します。複雑に見える規格書も、パケットという「事実」を追えば、必ずその正体が見えてくるはずです。
それでは、また現場でお会いしましょう。通信の安定を願っています。
コメント