# 5G-AKA主认证与密钥推演全流程拆解 ## 1 引言：为什么5G需要重新设计认证机制 4G EPS-AKA存在三个根本性安全缺陷：IMSI以明文在空口传输（可被伪基站捕获）、CK/IK暴露给服务网络（MME可直接获取）、服务网络绑定弱（缺乏对SN的身份验证）。3GPP TS 33.501从架构层面重新设计了5G Primary Authentication，引入SUCI/SUPI隐私保护、SEAF/AUSF/ARPF分层密钥锚定、SNN（Serving Network Name）绑定的密钥推演机制。 本文聚焦 **TS 33.501 V18.x Section 6.1.3** 定义的5G-AKA完整认证流程，逐步拆解每个信令消息中的关键IE（Information Element），绘制完整的密钥推演层级，并分析与4G EPS-AKA的核心差异。 --- ## 2 涉及的安全功能实体 5G-AKA认证涉及五个核心安全功能实体，每个实体承担明确的密码学职责： | 功能实体 | 位置 | 核心职责 | 对标4G网元 | |---------|------|---------|-----------| | **UE/USIM** | 终端侧 | 存储长期密钥K，执行f1-f5算法，计算RES*和KAUSF | USIM | | **SEAF**（Security Anchor Function） | 共址于AMF | 安全锚点，接收KSEAF，推演KAMF | MME（部分） | | **AUSF**（Authentication Server Function） | 核心网新实体 | 验证RES*=XRES*，推演KSEAF，持有KAUSF | MME（部分） | | **UDM/ARPF** | 核心网 | 生成5G AV，存储长期密钥K | HSS/AuC | | **SIDF**（Subscription Identifier De-concealing Function） | 共址于UDM | 将SUCI解密还原为SUPI | 无（4G无此功能） | **设计意图**：4G中MME同时承担认证验证和密钥锚定的双重角色，存在权限过度集中的风险。5G将认证验证（AUSF）、密钥锚定（SEAF）、认证向量生成（ARPF）三者解耦，实现职责分离（Separation of Duties）。 --- ## 3 SUCI隐私保护：认证前的身份隐藏 在进入5G-AKA主流程之前，UE必须先完成身份保护。5G引入SUCI（Subscription Concealed Identifier）替代4G中的明文IMSI传输。 ### 3.1 SUCI结构 ``` SUCI = | | | | | | | ``` | 字段 | 长度 | 说明 | |-----|------|------| | SUPI Type | 4 bits | 0=IMSI, 1=NAI等 | | MCC/MNC | 可变 | 归属网络标识，明文传输用于路由 | | Routing Indicator | 1-4 digits | 用于路由到正确的UDM/ARPF | | Protection Scheme ID | 4 bits | 0=Null, 1=Profile A, 2=Profile B | | HN Public Key ID | 可变 | 标识使用哪把HN公钥 | | Ephemeral Public Key | 可变 | UE临时公钥（32字节，Curve25519） | | Ciphertext | 可变 | 加密后的MSIN | | MAC Tag | 可变 | 完整性保护标签 | ### 3.2 ECIES加密方案 TS 33.501 Section 6.2定义了两种ECIES Profile： ```mermaid flowchart TD subgraph UE侧["UE/USIM"] A["长期公钥 HN_PK
（USIM预置）"] --> B["生成临时密钥对
eph_SK / eph_PK"] B --> C["ECDH共享密钥
SharedSecret = eph_SK × HN_PK"] C --> D["KDF推演
Enc_Key + MAC_Key"] D --> E["加密MSIN → Ciphertext"] D --> F["计算MAC Tag"] end subgraph HN侧["SIDF/UDM"] G["长期私钥 HN_SK"] --> H["ECDH共享密钥
SharedSecret = HN_SK × eph_PK"] H --> I["KDF推演
Enc_Key + MAC_Key"] I --> J["验证MAC Tag"] J --> K["解密Ciphertext → MSIN"] end E -. "SUCI空口传输" .-> J F -. "SUCI空口传输" .-> J ``` | 参数 | Profile A | Profile B | |------|-----------|-----------| | 椭圆曲线 | secp256r1 (P-256) | Curve25519 | | 密钥交换 | ECDH标准 | X25519 | | 加密算法 | AES-128-CTR | AES-128-CTR | | MAC算法 | HMAC-SHA-256（截断128bit） | HMAC-SHA-256（截断128bit） | | KDF | SHA-256 | SHA-256 | | 临时公钥长度 | 64字节（未压缩） | 32字节 | **实战要点**：Profile B（Curve25519）因临时公钥更短（32 vs 64字节）、运算更快，在实际部署中更受青睐。抓包时可在SUCI的Protection Scheme ID字段识别使用的Profile——值为`0x01`为Profile A，`0x02`为Profile B。 --- ## 4 5G-AKA完整信令流程 以下为TS 33.501 Section 6.1.3.2定义的5G-AKA完整信令时序图： ```mermaid sequenceDiagram participant UE as UE/USIM participant SEAF as SEAF(AMF) participant AUSF as AUSF participant UDM as UDM/ARPF Note over UE,SEAF: Step 1: Registration Request UE->>SEAF: Registration Request
(SUCI or 5G-GUTI, SNN) Note over SEAF,UDM: Step 2-3: 认证向量请求 SEAF->>AUSF: Nausf_UEAuthentication
Authenticate Request
(SUCI/SUPI, SNN) AUSF->>UDM: Nudm_UEAuthentication
Get Request
(SUPI, SNN) Note over UDM: Step 4: ARPF生成5G AV Note over UDM: RAND ← 随机数
SQN ← 序列号递增
MAC = f1(K, RAND, SQN, AMF)
XRES = f2(K, RAND)
CK = f3(K, RAND)
IK = f4(K, RAND)
AK = f5(K, RAND)
AUTN = SQN⊕AK ‖ AMF ‖ MAC
XRES* = KDF(CK‖IK, "5G-AKA", RAND, XRES)
KAUSF = KDF(CK‖IK, SQN⊕AK, SNN) UDM-->>AUSF: Nudm_UEAuthentication
Get Response
(RAND, AUTN, XRES*, KAUSF) Note over AUSF: 保存KAUSF和XRES* AUSF-->>SEAF: Nausf_UEAuthentication
Authenticate Response
(RAND, AUTN, HXRES*) Note over SEAF,UE: Step 7: 网络挑战UE SEAF->>UE: NAS Authentication Request
(RAND, AUTN, ngKSI) Note over UE: Step 7a: UE验证网络 Note over UE: AK = f5(K, RAND)
恢复SQN = AUTN中SQN⊕AK ⊕ AK
XMAC = f1(K, RAND, SQN, AMF)
验证: XMAC == AUTN中的MAC
验证: SQN在有效范围 Note over UE,SEAF: Step 8: UE应答 UE->>SEAF: NAS Authentication Response
(RES*) Note over UE: RES = f2(K, RAND)
CK' = f3(K, RAND), IK' = f4(K, RAND)
RES* = KDF(CK'‖IK', "5G-AKA", RAND, RES)
KAUSF = KDF(CK'‖IK', SQN⊕AK, SNN) Note over SEAF: Step 9: SEAF初步验证 Note over SEAF: HRES* = KDF(RES*)
比较: HRES* == HXRES*? SEAF->>AUSF: Nausf_UEAuthentication
Authenticate Confirm
(RES*) Note over AUSF: Step 10: AUSF最终验证 Note over AUSF: 比较: RES* == XRES*?
KSEAF = KDF(KAUSF, SNN) AUSF-->>SEAF: Nausf_UEAuthentication
Authenticate Confirm Response
(KSEAF, AuthResult=SUCCESS) Note over SEAF: Step 11: 推演KAMF Note over SEAF: KAMF = KDF(KSEAF, SUPI, accessType) ``` --- ## 5 关键信令消息IE详解 ### 5.1 NAS Authentication Request（SEAF → UE） | IE名称 | 长度 | 说明 | 来源 | |--------|------|------|------| | **RAND** | 16字节 | 网络生成的随机挑战值 | ARPF | | **AUTN** | 16字节 | 认证令牌 = SQN⊕AK(6B) + AMF(2B) + MAC(8B) | ARPF | | **ngKSI** | 3 bits | 密钥集标识符，标识本次安全上下文 | SEAF分配 | | **ABBA** | 可变 | 防止BSS攻击的参数（TS 33.501 6.1.3.3） | SEAF | **AUTN内部结构**： ``` AUTN (16 bytes): ┌────────────────┬──────────────┬────────────────┐ │ SQN ⊕ AK │ AMF │ MAC │ │ (48 bits) │ (16 bits) │ (64 bits) │ │ 匿名化序列号 │ 认证管理字段 │ 消息认证码 │ └────────────────┴──────────────┴────────────────┘ ``` - **SQN ⊕ AK**：序列号与匿名密钥异或，防止攻击者追踪SQN变化 - **AMF**：认证管理字段，bit 0=0表示后续可建立安全上下文 - **MAC**：f1(K, RAND, SQN, AMF)计算，UE通过验证MAC实现**对网络的认证** ### 5.2 NAS Authentication Response（UE → SEAF） | IE名称 | 长度 | 说明 | |--------|------|------| | **RES*** | 可变（≥16字节） | UE计算的认证应答，扩展后的RES | RES*的推演公式（TS 33.501 Annex A.5）： ``` RES* = KDF(CK || IK, P0 = "5G-AKA", L0 = 7, P1 = RAND, L1 = 16, P2 = RES, L2 = len(RES)) ``` **设计意图**：4G中直接传输RES（通常8字节），长度固定。5G将RES扩展为RES*（通过KDF包裹），增加了密钥材料长度，有效抵抗**虚假基站攻击**——攻击者无法从短RES推演出完整的密钥层级。 ### 5.3 HXRES* — SEAF的本地预验证 AUSF在返回认证响应时不仅发送RAND和AUTN，还发送HXRES*： ``` HXRES* = SHA-256(RAND || XRES*) ``` SEAF收到UE的RES*后，先本地计算： ``` HRES* = SHA-256(RAND || RES*) ``` 比较HRES*与HXRES*，若匹配则初步验证通过，再转发RES*给AUSF做最终验证。 **设计意图**：SEAF预验证机制使得AMF可以在不依赖AUSF的情况下快速过滤明显的认证失败，减少不必要的网络信令开销。 --- ## 6 密钥推演层级详解 TS 33.501 Section 6.2定义了5G完整的密钥推演层级。所有KDF均基于HMAC-SHA-256（TS 33.501 Annex A.2）： ``` KDF(Key, S) = HMAC-SHA-256(Key, S) 其中 S = FC || P0 || L0 || P1 || L1 || ... FC = 功能码（1字节），Pn = 参数n，Ln = 参数n长度（2字节大端序） ``` ### 6.1 密钥推演层级图 ```mermaid flowchart TD K["长期密钥 K
（USIM + ARPF各持有一份）"] K -->|"f2(K, RAND)"| RES["RES / XRES"] K -->|"f3(K, RAND)"| CK["CK"] K -->|"f4(K, RAND)"| IK["IK"] K -->|"f5(K, RAND)"| AK["AK（匿名密钥）"] K -->|"f1(K, RAND, SQN, AMF)"| MAC["MAC"] CK --> CKIK["CK ‖ IK"] IK --> CKIK CKIK -->|"FC=0x6A
P0=5G-AKA
P1=RAND
P2=XRES"| XRESstar["XRES* / RES*
（扩展认证应答）"] CKIK -->|"FC=0x6A
P0=SQN⊕AK
P1=SNN"| KAUSF["KAUSF
（AUSF密钥）"] KAUSF -->|"FC=0x6C
P0=SNN"| KSEAF["KSEAF
（SEAF锚点密钥）"] KSEAF -->|"FC=0x6D
P0=SUPI
P1=AccessType"| KAMF["KAMF
（AMF根密钥）"] KAMF -->|"FC=0x69
P0=算法类型标识"| KNASint["KNASint
NAS完整性密钥"] KAMF -->|"FC=0x69
P0=算法类型标识"| KNASenc["KNASenc
NAS加密密钥"] KAMF -->|"FC=0x6F
P0=access type"| KgNB["KgNB
gNB根密钥"] KgNB -->|"FC=0x69"| KRRCint["KRRCint
RRC完整性密钥"] KgNB -->|"FC=0x69"| KRRCenc["KRRCenc
RRC加密密钥"] KgNB -->|"FC=0x69"| KUPint["KUPint
UP完整性密钥"] KgNB -->|"FC=0x69"| KUPenc["KUPenc
UP加密密钥"] style K fill:#e74c3c,color:#fff style KAUSF fill:#e67e22,color:#fff style KSEAF fill:#f39c12,color:#fff style KAMF fill:#27ae60,color:#fff style KgNB fill:#3498db,color:#fff ``` ### 6.2 各层级KDF参数详解 | 密钥 | KDF输入 | FC | P0 | P1 | 持有者 | |------|--------|-----|-----|-----|--------| | **KAUSF** | CK‖IK | 0x6A | SQN⊕AK | SNN | AUSF | | **KSEAF** | KAUSF | 0x6C | SNN | — | SEAF | | **KAMF** | KSEAF | 0x6D | SUPI | Access Type | AMF | | **KNASint** | KAMF | 0x69 | 算法类型ID | — | UE+AMF | | **KNASenc** | KAMF | 0x69 | 算法类型ID | — | UE+AMF | | **KgNB** | KAMF | 0x6F | Access Type | — | gNB | | **KRRCint** | KgNB | 0x69 | 算法类型ID | — | UE+gNB | | **KRRCenc** | KgNB | 0x69 | 算法类型ID | — | UE+gNB | ### 6.3 与4G EPS-AKA密钥层级对比 | 对比维度 | 4G EPS-AKA | 5G-AKA | |---------|-----------|--------| | **根密钥** | K → CK/IK → KASME | K → CK/IK → KAUSF → KSEAF → KAMF | | **中间密钥传输** | CK/IK发送给MME | CK/IK**永不离开**ARPF/USIM | | **SN绑定** | 通过OPc隐式绑定 | 通过SNN显式绑定（KDF参数） | | **密钥层级深度** | 3层（K→KASME→KeNB） | 4层（K→KAUSF→KSEAF→KAMF→KgNB） | | **加密算法协商** | NAS SMC中 | NAS SMC中（增加UP完整性） | | **认证应答** | RES（短，固定长度） | RES*（KDF扩展，变长，抗虚假基站） | --- ## 7 5G-AKA vs EAP-AKA'对比 TS 33.501 Section 6.1定义了两种主认证方法。下表从多个维度进行对比： | 对比维度 | 5G-AKA（Section 6.1.3） | EAP-AKA'（Section 6.1.2） | |---------|------------------------|--------------------------| | **适用接入** | 3GPP接入（NR/LTE） | Non-3GPP接入（Wi-Fi via N3IWF/TNGF） | | **协议框架** | NAS原生协议 | EAP框架（RFC 9048） | | **安全锚点** | SEAF（共址AMF） | N3IWF/TNGF | | **密钥层级** | KAUSF → KSEAF → KAMF | CK'\|\|IK' → MK → MSK/EMSK | | **SN绑定参数** | SNN（Serving Network Name） | Access Network Identity | | **XRES长度** | XRES*（扩展） | 标准XRES | | **身份隐私** | SUCI（ECIES加密） | 可选（非强制） | | **重认证** | 使用5G-GUTI和KAMF派生 | EAP快速重认证 | | **SQN同步失败** | NAS Authentication Failure（#3GPP同步失败） | EAP-Response/AKA'-Synchronization-Failure | | **消息数** | 4条NAS消息 | 多轮EAP交换（≥4条） | **设计意图**：5G-AKA针对3GPP接入做了专门优化，信令效率更高（4条NAS消息完成），密钥绑定更强（SNN）。EAP-AKA'则利用成熟的EAP框架适配Non-3GPP接入，保证了跨接入类型的统一认证架构。 --- ## 8 异常处理：SQN同步失败 当UE检测到SQN不在有效范围时（通常是因为USIM长期未使用或测试环境中USIM反复初始化），触发重同步流程： ```mermaid sequenceDiagram participant UE as UE/USIM participant SEAF as SEAF(AMF) participant AUSF as AUSF participant UDM as UDM/ARPF Note over UE: 验证AUTN时发现
SQN不在有效范围 UE->>SEAF: NAS Authentication Failure
(Cause: Synch failure, AUTS) Note over UE: AUTS = SQN_MS ⊕ AK ‖ MAC_S
MAC_S = f1*(K, RAND, SQN_MS) SEAF->>AUSF: Nausf_UEAuthentication
Authenticate Request
(AUTS, RAND) AUSF->>UDM: Nudm_UEAuthentication
Get Request
(AUTS, RAND) Note over UDM: ARPF使用AUTS和旧RAND
恢复UE端的SQN_MS
验证MAC_S
以UE的SQN_MS为基准重新生成AV UDM-->>AUSF: 新的5G AV
(RAND_new, AUTN_new, XRES*_new, KAUSF_new) AUSF-->>SEAF: 新的认证向量 SEAF->>UE: NAS Authentication Request
(RAND_new, AUTN_new) ``` **AUTS结构**（12字节）： ``` AUTS (12 bytes): ┌─────────────────────┬──────────────────────┐ │ SQN_MS ⊕ AK │ MAC_S │ │ (48 bits) │ (64 bits) │ │ UE端当前SQN │ f1*(K, RAND, SQN_MS) │ └─────────────────────┴──────────────────────┘ ``` **排错要点**： - 在测试环境（free5GC/Open5GS + UERANSIM）中，SQN同步失败是最常见的认证问题 - 根因通常是USIM中SQN值与UDM/ARPF中的SQN不一致 - 解决方案：重置USIM的SQN（通过pySIM等工具），或在UDM中调整SQN初始值 --- ## 9 NAS安全模式命令（Security Mode Command） 认证成功后，AMF/SEAF发起NAS Security Mode Command（SMC）建立NAS安全上下文： ### 9.1 NAS SMC流程 ```mermaid sequenceDiagram participant UE as UE participant AMF as AMF/SEAF Note over AMF: 从KAMF推演:
KNASenc = KDF(KAMF, alg-id-NEA)
KNASint = KDF(KAMF, alg-id-NIA) AMF->>UE: NAS Security Mode Command
(Selected Security Algorithms,
ngKSI, ReplayComplete) Note over AMF: 该消息使用KNASint做完整性保护
但不加密（安全上下文尚未在UE侧建立） Note over UE: UE验证完整性
推演KNASenc, KNASint
启用NAS安全和加密 UE->>AMF: NAS Security Mode Complete
(加密 + 完整性保护) Note over UE: IMEI/SUCI等敏感信息
在加密后的此消息中传输 ``` ### 9.2 Security Mode Command中的关键IE | IE | 说明 | |----|------| | **Selected NAS Security Algorithms** | 包含加密算法（NEA0/NEA1/NEA2/NEA3）和完整性算法（NIA0/NIA1/NIA2/NIA3） | | **ngKSI** | 密钥集标识，用于标识当前安全上下文 | | **ReplayComplete** | 指示UE重放之前未受保护的NAS消息 | | **Additional_5G_Security_Parameters** | 包含ABBA参数，防止BSS攻击 | **算法映射**： | 算法ID | 加密算法 | 说明 | |--------|---------|------| | 0 | NEA0 | 空加密（仅用于紧急呼叫） | | 1 | 128-NEA1 | SNOW 3G | | 2 | 128-NEA2 | AES-CTR | | 3 | 128-NEA3 | ZUC | | 算法ID | 完整性算法 | 说明 | |--------|-----------|------| | 0 | NIA0 | 空完整性（TS 33.501限制使用） | | 1 | 128-NIA1 | SNOW 3G | | 2 | 128-NIA2 | AES-CMAC | | 3 | 128-NIA3 | ZUC | --- ## 10 抓包识别与排错实战 ### 10.1 Wireshark抓包识别 5G-AKA认证信令在NAS协议层，Wireshark过滤器： ``` # 过滤NAS Authentication Request/Response nas-5gs.message_type == 0x56 || nas-5gs.message_type == 0x57 # 过滤NAS Authentication Failure nas-5gs.message_type == 0x5c # 过滤NAS Security Mode Command/Complete nas-5gs.message_type == 0x5d || nas-5gs.message_type == 0x5e ``` ### 10.2 关键字段解码 在Wireshark中展开NAS Authentication Request消息： - `Extended protocol discriminator` = 0x7E（5GS Mobility Management） - `Security header type` = 0x00（Plain NAS，因为安全上下文尚未建立） - `Message type` = 0x56（Authentication Request） - `ngKSI` = 密钥集标识（通常为0-6，7表示无密钥可用） - `RAND` = 16字节随机数（可追踪到ARPF生成的认证向量） - `AUTN` = 16字节认证令牌（包含SQN⊕AK、AMF、MAC） ### 10.3 常见故障排查 | 故障现象 | 可能原因 | 排查方法 | |---------|---------|---------| | Authentication Failure (MAC failure, #20) | USIM与UDM中密钥K不一致 | 检查USIM Ki/OPc配置是否与UDM匹配 | | Authentication Failure (Synch failure, #21) | SQN不同步 | 使用pySIM重置USIM的SQN | | Security Mode Reject | 算法协商失败 | 检查UE和AMF支持的算法列表是否有交集 | | Registration Reject (#3, Illegal UE) | 认证验证失败 | 检查AUSF日志中RES*==XRES*比较结果 | | Registration Reject (#22, Congestion) | AMF过载 | 检查AMF负载和过载控制策略 | ## 11 5G-AKA安全增强总结 ```mermaid flowchart LR subgraph 安全增强["5G-AKA vs 4G EPS-AKA 安全增强"] A["SUPI隐私保护
SUCI加密传输"] B["密钥不外传
CK/IK永不离ARPF"] C["SN绑定增强
SNN参与KDF"] D["锚点分离
SEAF+AUSF双锚"] E["抗虚假基站
XRES*扩展长度"] F["UP完整性
新增用户面完整性保护"] end A --> G["消除IMSI catcher攻击"] B --> H["减少密钥暴露面"] C --> I["防止跨SN密钥复用"] D --> J["职责分离防权限集中"] E --> K["抵抗虚假基站重放"] F --> L["端到端数据完整性"] ``` ## 12 常见问题 **Q1: 5G-AKA中CK/IK为什么不能离开ARPF？** A: 4G EPS-AKA中CK/IK从HSS发送给MME，服务网络可直接获取中间密钥。如果MME被攻破，攻击者可推演出整个密钥层级。5G规定CK/IK仅在ARPF和USIM内部使用，网络侧只能获得通过KDF推演的KAUSF/KSEAF，从根本上缩小了密钥暴露面。 **Q2: XRES*与4G的XRES有什么本质区别？** A: 4G的XRES由f2(K,RAND)直接生成，长度固定（通常4-8字节）。5G的XRES*通过KDF(CK||IK, "5G-AKA", RAND, XRES)生成，长度可变且显著更长。这一设计使得攻击者即使能截获RES*，也无法通过暴力搜索匹配原始的短XRES，有效抵抗虚假基站攻击（False Base Station Attack）。 **Q3: 为什么需要SEAF和AUSF两个锚点？** A: 职责分离原则。AUSF负责认证验证（比较RES*=XRES*）并持有KAUSF，SEAF负责密钥锚定（持有KSEAF并推演KAMF）。这样即使AMF/SEAF被攻破，攻击者也无法伪造认证结果（需要AUSF的KAUSF）；反之亦然。4G中MME同时承担这两个角色，存在单点风险。 **Q4: Null-Scheme（Protection Scheme ID=0）什么场景使用？** A: Null-Scheme不提供隐私保护（SUPI明文传输），仅在以下场景使用：(1) 紧急呼叫（UE无USIM或未配置HN公钥时）；(2) 测试环境调试。3GPP强烈建议商用网络禁止使用Null-Scheme。 **Q5: 5G-AKA与EAP-AKA'能否在同一个UE上同时使用？** A: 可以。一个UE可以同时在3GPP接入上使用5G-AKA、在Non-3GPP接入（如Wi-Fi）上使用EAP-AKA'。两种认证方法共享同一个UDM/ARPF（共享长期密钥K），但生成独立的密钥层级。TS 33.501 Section 6.1.2/6.1.3分别定义了两种方法，互不干扰。 --- ## 参考来源 1. [3GPP TS 33.501 V18.x — Security architecture and procedures for 5G system](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3169) — Section 6.1.3 (5G-AKA), Section 6.2 (Key hierarchy), Annex A (KDF) 2. [Introduction to 5G AKA - free5GC](https://free5gc.org/blog/20251029/20251029/) — 5G-AKA完整流程图解与开源实现分析 3. [5G Authentication and Key Management - Devopedia](https://devopedia.org/5g-authentication) — 5G认证机制概述与4G对比 4. [A Formal Analysis of 5G Authentication - ETH Zurich](https://people.inf.ethz.ch/rsasse/pub/5G-CCS18.pdf) — 对5G-AKA协议的形式化安全分析，揭示潜在协议层攻击 5. [TS 33.501 Section 6.1 — iTecSpec](https://itecspec.com/3gpp/33.501/s/6.1) — Primary authentication章节结构化解析 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。