5GS的用户隐私和前向安全学习笔记

5GS的用户隐私5GS还很遥远，但3GPP文档也很长，别说通读一遍，打开都要些勇气。我决定“分而治之”，拆成小块来学。这里和大家分享的，就是其中一小块——3GPPTS33.501（Securityarchitectureandproceduresfor5Gsystem）的6.12章节，5GS的SubscriptionIdentifierPrivacy，即5GS的用户（标识）隐私。

先回顾一下。

在EPS中，一个USIM对应一个用户，USIM的IMSI（InternationalMobileSubscriberIdentificationNumber）就是用户的永久标识。UE初始接入时，必须上报IMSI，否则网络不知道用户身份。IMSI在空中接口明文传送，捕捉到携带IMSI的请求，就可以获知UE（USIM）的地理位置，或更进一步的，UE的移动轨迹——至于如何利用这些信息，大家可以自行发挥想象力。

这不是EPS的新问题，在CS和PS中，UE同样必须上报IMSI。3GPP意识到这个风险，为了减少IMSI传送次数，用户认证成功后，在空中接口使用TID（TemporaryIdentity）替代IMSI。在CS中，TID就是TMSI（TemporaryMobileSubscriberIdentity），在PS中，TID就是P-TMSI（PacketTemporaryMobileSubscriberIdentity），在EPS中，TID就是GUTI（GloballyUniqueTemporaryIdentity）——在华府里，唐伯虎的TID就是9527了。UE还是需要上报一次IMSI，但IMSI泄露的几率大幅下降了。所谓：道高一尺，魔高一丈。你减少传送次数，那我就增加呗。携带TID的请求，如果发送到分配TID的CN节点（MSC、SGSN、MME），根据TID和IMSI的对应关系，CN知道请求者是谁（IMSI）。然而，请求也可能发送到其他CN节点，如果无法从OldCN节点获得UE上下文（比如，DNS查询失败，或OldMME不可达，或ContextREQ/ContextRSP响应丢失），NewCN节点会发送IdentityRequest，要求UE上报IMSI。攻击者利用这个流程，借助某些特殊设备（比如，伪基站），依然可以获得IMSI。

5GS有什么不同？

在5GS中，用户可以多种方式接入5GC，用户的永久标识也由IMSI变为SUPI（SubscriptionPermanentIdentifier）。SUPI只在3GPP系统中使用，并在UDM/UDR配置。为了适用于不同协议，SUPI格式可以不同，对应不同的SUPIType：0对应IMSI，1对应NAI（NetworkAccessIdentifier），2~7留作备用。如果涉及EPC（只认识IMSI）互操作，SUPI应基于IMSI构造（IMSIbased）。为了实现漫游，SUPI应包含归属网络信息，比如MCC（MobileCountryCode）和MNC（MobileNetworkCode）——如果SUPI基于IMSI构造。

在5GS中，即使UE第一次接入网络，也不在空中接口上报SUPI，而是用SUCI（SubscriptionConcealedIdentifier）替代。UE由SUPI生成SUCI，且只有归属网络的SIDF（SubscriptionIdentifierDe-concealingFunction）可由SUCI恢复SUPI，这样SUPI就得到了保护。更进一步的，同一个SUPI，每次生成的SUCI长的都不一样——在安全领域，“重复”可是大忌。

SUCI隐藏了SUPI，但也不能什么都藏起来，否则网络会无所适从——如果拜访网络（VisitingNetwork）不知道从哪儿获得SUPI，和UE就没啥好聊的了。UE（USIM）不能只说“猜猜我是谁”，还要透露一些信息，比如说，SUCI（SUPI）的归属网络（HomeNetwork）。SUCI的构成包括6个部分：SUPIType、HomeNetworkIdentifier、RoutingIndicator、ProtectionSchemeId、HomeNetworkPublicKeyId、SchemeOutput——实际上，只有最后一部分是密文。

SUCI的前半部分用于寻址，帮助网络找到正确的UDM/SIDF。如果SUPIType为0，HomeNetworkIdentifier由IMSI的MCC和MNC构成，如果SUPIType为1，HomeNetworkIdentifier由NAI的“domainname”构成（clause2.2ofIETFRFC7542）。如果UDM存在多个实例（Instance），RoutingIndicator可用于指向正确的实例——如果USIM没有配置RoutingIndicator，则取值为0。SUCI的后半部分用于保护，对用户具体身份进行隐藏。算法输入（保护对象）即SchemeInput，如果SUPIType为0，SchemeInput为IMSI的MSIN；如果SUPIType为1，SchemeInput为NAI的“username”。算法输出即SchemeOutput，格式取决于ProtectionScheme。ProtectionSchemeId和HomeNetworkPublicKeyId指出使用的算法和公钥。ProtectionSchemeId和HomeNetworkPublicKey应保存在USIM。

ProtectionSchemeId取值范围为0x0~0xF——0x0表示null-scheme，0x1表示Profile，0x2表示Profile，0x3~0xB保留给3GPP使用，0xC~0xF保留给运营商使用（历史经验告诉我们，这是多余的…）。也就是说，3GPP提供两个现成方案，如果运营商不喜欢，也可以自己定义。同时，3GPP也给“某些”需求留了口子（null-scheme）——并且很可能会成为最终的选择。

所谓null-scheme，就是不进行处理，SchemeOutput和SchemeInput完全一样。通俗的说，吃的是草，拉的……还是草。如果SUPIType为0，SchemeOutput就是IMSI的MSIN，如果SUPIType为1，SchemeOutput就是NAI的“username”。显然，null-scheme的SUCI也没啥好更新的。null-scheme失去“隐藏”的内核，但SUCI的形式还在，UE发送的依然是SUCI，而不是SUPI（好歹也要摆摆样子）。如果归属网络没有配置HomeNetworkPublicKey，或没有配置ProtectionScheme优先级列表，UE（ME）也应使用null-scheme（巧妇难为无米之炊啊）。

Null-scheme我们兴趣不大，自定义Scheme也无从说起，还是重点看一下现成的吧。Profile和Profile，都基于ECIES（EllipticCurveIntegratedEncryptionScheme），只是参数不同。两者最大的差异，是Profile使用ellipticcurveDiffie-Hellmanprimitive，而Profile使用ellipticcurvecofactorDiffie-Hellmanprimitive。Profile参数的作用，可参考SECGSEC1（RecommendedEllipticCurveCryptography,Version2.0），以及SECGSEC2（RecommendedEllipticCurveDomainParameters,Version2.0）。部分参数的作用很好猜，从名字就能看出来。比如，ENC表示加密算法（AES-128inCTRmode），MAC表示校验算法（HMAC-SHA-256）。enckeylen表示加密密钥的长度，icblen表示ICB（AES-128inCTRmode的InitialCounterBlock）的长度，mackeylen表示校验密钥的长度，maclen表示MAC（MessageAuthenticationCode）的长度。

相对应的，SUCI的SchemeOutput，构成包括三部分：Eph.PublicKey、ciphertext和MAC-tag。Ciphertext对应加密算法的输出结果，MAC-tag对应校验算法的输出结果。Profile中Eph.PublicKey长度为256bits（64hex.digits）；Profile中Eph.Publickey长度为264bits（66hex.digits）。Ciphertext和SchemeInput长度相同。Eph.publickey和MAC-tag长度之和上限是3000octets。长度超出上限的SUCI，UE不应该发送，否则，网络也多半会拒接。根据运营商策略，USIM指示SUCI由USIM还是ME计算。如果USIM没有指示，SUCI由ME计算。如果由USIM计算SUCI，USIM不应向ME传递相关参数，包括HomeNetworkPublicKeyIdentifier、HomeNetworkPublicKey和ProtectionSchemeIdentifier。ME也应删除缓存的相关参数，包括SUPIType、RoutingIndicator、HomeNetworkPublicKeyIdentifier、HomeNetworkPublicKey和ProtectionSchemeIdentifier。

如果由ME计算SUCI，运营商选取一个，或多个ProtectionScheme（3GPPTS33.501附录C）组成ProtectionScheme优先级列表，配置在USIM。ME从USIM获得SUPIType、RoutingIndicator、HomeNetworkPublicKeyIdentifier、HomeNetworkPublicKey和ProtectionScheme优先级列表，从中选择优先级最高，且ME支持的ProtectionScheme计算SUCI。如果后续引入新ProtectionScheme，旧版本的ME依然可用——但ME选择的ProtectionScheme可能不是USIM配置优先级最高的。

ECIES大概是这么回事。

T=（p,a,b,G,n,h）是有效的ECC（EllipticCurveCryptography）曲线。（du,Qu）和（dv,Qv）是关联T的密钥对（KeyPair）。du和dv是私钥（PrivateKey），Qu和Qv是公钥（PublicKey），即Qu=duG，Qv=dvG。由于duQv=dudvG=dvduG=dvQu，使用du和Qv生成的“secret”，可以使用dv和Qu恢复出来——在5GS中，这个“secret”就是UE和SIDF的共享密钥（Eph.SharedKey）。在5GS中，（du,Qu）是UE生成的密钥对，du即Eph.Privatekey，Qu即Eph.Publickey，（dv,Qv）是归属网络生成的密钥对，dv即HomeNetworkPrivateKey，Qv即HomeNetworkPublicKey。HomeNetworkPublicKey保存在USIM，而HomeNetworkPrivateKey保存在SIDF。

HomeNetworkPublicKey是SUCI安全性的关键之一。HomeNetworkPublicKey可以公开，但配置和更新依然应该在运营商的控制之下。3GPP没有明确如何实现这些过程，运营商需要自行解决，比如说，通过OTA（OvertheAir）机制——OTA具体是什么，我也不知道。

UE使用Eph.Privatekey（du）和HomeNetworkPublicKey（Qv）生成Eph.SharedKey，将Eph.PublicKey（包含在SchemeOutput）和HomeNetworkPublicKey（以及HomeNetworkPublicKeyIdentifier）传递给SIDF。SIDF使用Eph.PublicKey（Qu）和HomeNetworkPrivateKey（dv）就可以生成相同的Eph.SharedKey。

UE和SIDF获得共享密钥（Eph.SharedKey），就可以通过KDF获得相同的加密密钥（Eph.Enc.Key）、ICB和校验密钥（Eph.MacKey），并在ENC和MAC使用对称密钥算法。如果UE生成的密钥对（Eph.PrivateKey,Eph.PublicKey）是“新鲜”的，共享密钥（Eph.SharedKey）就是“新鲜”的，加密密钥（Eph.Enc.Key）、ICB、校验密钥（Eph.MacKey）也是“新鲜”的——SchemeOutput是“新鲜”的，SUCI也是“新鲜”的。

先来看UE的处理。

总的来说，UE参照SECGSEC1处理，Section3.8和Section5.1.3的步骤5和6参照3GPPTS33.501附录C3.2变更。首先，UE生成“新鲜”的ECC密钥对，即Eph.PublicKey和Eph.PrivateKey，这是生成“新鲜”SUCI的关键。然后，UE通过Eph.PrivateKey和HomeNetworkPublicKey获得共享密钥，即Eph.SharedKey。接着，Eph.SharedKey通过KDF（KeyDerivedFunction）衍生“KeyingData”——K（不是用户密钥K）。K包含三部分：1、长度为enckeylen的加密密钥Eph.Enc.Key；2、长度为icblen的ICB；3、长度为mackeylen的校验密钥Eph.MacKey。

Eph.Enc.Key和ICB参与加密运算，输入为SchemeInput，输出为Ciphertext，Eph.MacKey参与校验运算（输入为Ciphertext），输出为MAC-tag。将Eph.PublicKey、Ciphertext和MAC-tag串接起来，就是SchemeOutput——如果需要，后面还可以串接其他参数，比如说，是否使用pointcompression的指示。

再来看SIDF的处理。

总的来说，SIDF参照SECGSEC1处理，Section3.8和Section5.1.4的步骤6和7，参照3GPPTS33.501附录C3.3变更。对于SIDF来说，SUCI的SchemeOutput是输入。和UE不同，SIDF不用另外生成密钥对，通过Eph.PublicKey和HomeNetworkPrivatekey获得共享密钥，即Eph.SharedKey。SIDF知道这么多用户秘密（HomeNetworkPrivateKey），当然不能对外开放了，只有归属网络的节点（比如UDM）可以访问。Eph.SharedKey通过KDF衍生K，包含Eph.Enc.Key、ICB和Eph.MacKey。Eph.MacKey参与校验运算，输入为SchemeOutput包含的Ciphertext，输出和SchemeOutput包含的MAC-tag比对。Eph.Enc.Key和ICB参与加密运算，输入为SchemeOutput包含的Ciphertext，输出为Plaintextblock，即SchemeInput（MSIN或“username”的编码）。将SUCI的HomeNetworkIdentifier和SchemeInput串接起来，就是SUPI。

SIDF由SUCI获得SUPI后，将SUPI传递给UDM。UDM/ARPF选择AKA类型（EAP-AKA'或5GAKA），生成对应AV（AuthenticationVector），再将AV和SUPI传递给AUSF。AKA执行成功后，AUSF才把SUPI和KSEAF传递给SEAF。如果AKA执行失败，AMF/SEAF甚至不知道请求用户的SUPI。可见，5GS为了保护SUPI，除了不在空中接口传递，还有很多其他考虑。UE使用SUCI替代SUPI，一定程度上保护了SUPI。不过，UE也没必要一直发送SUCI（显摆）。SUCI是由SUPI计算获得的，即使每次生成的SUCI不一样，也会增加SUPI泄露的风险。SUCI就像SUPI的“伪装”，别人“看”的越多，“认”出来的可能性越大。因而，还是用TID替代更保险。在5GS中，（NAS的）TID是5GGUTI，由AMF分配，作用就类似于EPS的GUTI。

5G-GUTI由GUAMI和5G-TMSI（32bits）构成，GUAMI由MCC、MNC和AMFI（24bits）构成，AMFI由AMFRegionID（8bits）、AMFSetID（10bits）和AMFPointer（6bits）构成。GUAMI在全球范围内唯一标识某个AMF，5G-TMSI在AMF范围内标识某个用户。和GUTI的M-TMSI相似，5G-GUTI的5G-TMSI最好随机生成，攻击者无法预测5G-GUTI，就无法跟踪特定的用户。5GC和EPC之间互操作时，UE和AMF需要进行GUTI到5G-GUTI，或5G-GUTI到GUTI的映射（Mapping），重点是MMEI和AMFI之间的映射。MMECI由两部分构成，AMFI由三部分构成，且位数不完全对齐。因而，AMFI的中间部分，即AMFSetID拆分为两部分，高8位对应MMEGI的低8位，低2位对应MMEC的高2位。

相比于GUTI，5G-GUTI更新相当频繁。AMF收到类型为“initialregistration”、“mobilityregistrationupdate”、“periodicregistrationupdate”的RegistrationRequest，或网络触发（paging）的ServiceRequest，应向UE发送“新”5G-GUTI——对于后一种场景，“新”5GGUTI应在NAS连接释放前发送。根据运营商策略，5G-GUTI更新还可以更频繁，比如说，在非网络触发的ServiceRequest场景中也进行更新。注意，NAS安全性激活后，UE才会获得“新”5GGUTI。和EPS相似，AMF收到5G-GUTI后，在某些场景（比如说，认证失败）会向UE发送IdentityRequest，要求UE上报用户标识。不过，现在UE学乖了（小样，老子不上当了），不返回SUPI，而是返回“新”SUCI。AMF/SEAF收到SUCI后触发AKA流程，将SUCI传递给AUSF，并期待获得SUPI。另外，为了防范攻击者（比如说，伪基站）进行试探，对于给定的5G-GUTI，UE应限制返回“新”SUCI的次数（问那么多遍，老子不答了）。5GS的前向安全5GS还很遥远，但3GPP文档也很长，别说通读一遍，打开都要些勇气。我决定“分而治之”，拆成小块来学。这里和大家分享的，就是其中一小块——3GPPTS33.501（Securityarchitectureandproceduresfor5Gsystem）的6.9.2章节，5GS的Keyhandlinginhandover，即5GS切换的密钥处理，这里重点关注前向安全（ForwardSecurity）。

所谓“前向安全”，指的是A知道A和B之间使用的密钥Km，但不能预先知道B和第三方，比如C，之间将会使用的密钥Km+n（n>0）。在5GS切换中，前向安全指的是和UE（B）共享KgNB的gNB（A），不能预知UE和其他gNB（第三方）共享的KgNB。这有些过于理想，我们稍微放松点要求，如果gNB不能预先知道UE在n次切换后，及后续使用的KgNB，就实现了“n跳前向安全”（nHopForwardSecurity）。

UE和gNB通过共享KgNB衍生AS密钥（3GPPTS33.501附录A.8），包括KRRCenc、KRRCint、KUPenc和KUPint。无法预先知道KgNB，就无法预先知道AS密钥，即使攻击者侵入某个gNB，也无法破解UE和其他gNB之间传送的RRC消息和用户面数据，这就是前向安全的意义所在。那么……

KgNB从哪儿来？

在初始接入中，AMF由KAMF衍生KgNB，并传递给gNB。根据3GPPTS33.501附录A.9，衍生KgNB（或KN3IWF）的KDF（KeyDerivationFunction）中，FC=0x6E，P0=UplinkNASCOUNT，P1=AccessTypeDistinguisher（3GPP接入P1取值0x01，非3GPP接入P1取值0x02）。KDF在5GS的应用可参考《5GS的密钥体系》和《5GS的密钥衍生》。在切换中，衍生KgNB的“锅”甩给了gNB——从无线角度看，切换并不需要AMF参与（比如在XnHandover中，切换完成后target才向AMF发送NGAPPATHSWITCHREQUEST）。在不同切换场景中，接“锅”的可能是sourcegNB（或ng-eNB），也可能是targetgNB（或ng-eNB）。

gNB（或ng-eNB）衍生KNG-RAN*（示图右侧）。如果target是gNB，KNG-RAN*作为KgNB使用，FC=0x70，P0=PCI（TargetPhysicalCellID），P1=ARFCN-DL（TargetPhysicalCellDownlinkFrequency）；如果target是ng-eNB（也是一种NG-RAN），KNG-RAN*作为KeNB使用，FC=0x71，P0=PCI，P1=EARFCN-DL。

KNG-RAN*由KgNB或NH衍生：如果由KgNB衍生，称为HorizontalDerivation，水平衍生；如果由NH衍生，称为VerticalDerivation，垂直衍生。NH即NextHop——顾名思义，NH用于下一次切换（包括intragNBHandover，如果CU和DU分离，则是intra-gNB-CUHandover）。NH由AMF（而不是gNB）衍生，这是5GS切换实现前向安全的关键。

衍生NH的KDF（3GPPTS33.501附录A.10），输入密钥KEY=KAMF，FC=0x6F，P0=SYNC-input——KgNB或NHn-1。每个KAMF对应一个NH链（NHChain）。在HN链上，每一个NH（NHn）依赖于前一个NH（NHn-1），NH序号称为NCC（NHChainingCounter）——KgNB可视为初始NH（NH0），对应NCC=0。AMF由KAMF和KgNB衍生的NH1，对应NCC=1。严格来说，NH1不是“真正意义”的NH。NH1不会传递给gNB，也不会用于衍生KNG-RAN*，只是作为NH链的一个“衔接”节点——由图可见，NH1水平方向没有其他内容。在UE侧，初始接入时可以不计算NH1，等第一次（垂直衍生KNG-RAN*的）切换发生时再计算NH1（和NH2，NH1不会用于衍生KNG-RAN*）。

在初始接入中，UE和AMF共享KAMF和KgNB，因而，也共享整个NH链（对应某个KAMF）。对于给定的NCC，UE和AMF从NH链上找到的NH是相同的——尽管NH不用提前计算出来。如果gNB从某个NH（包括初始的KgNB）衍生KNG-RAN*，将对应的NCC告知UE，UE就可以从相同的NH衍生（相同的）KNG-RAN*。如果UE收到的NCC“大于”（不等于）保存的NCC，UE先进行“NCC同步”（赶上AMF的“NCC进度”），再由NH衍生KNG-RAN*（垂直衍生）；如果UE收到的NCC等于保存的NCC，UE由currentKgNB（不一定是初始的KgNB，也可能是KNG-RAN*转化的KgNB）衍生KNG-RAN*（水平衍生）。衍生NH的KDF中，P0（KgNB或NHn-1）称为“SYNC-input”（同步输入）大概就是这个原因吧。

NCC的取值范围为0~7，但并不是说NH链的长度最大为8，总不能限制UE连续切换的次数吧。因而，NCC到了最大值（7）后会翻转为0，NCC=0不一定对应NH0，也可能对应NH8、NH16…...AMF的NCC进度总是等于或“略”超前于UE，UE收到的NCC不等于保存的NCC，就会先进行NCC同步，这就是“大于”加了双引号的原因（由于存在翻转，UE收到的NCC数值可能小于保存的NCC）——个人理解。

NH啥时候用？

首先gNB得有NH，并且是未使用的NH——使用相同的NH衍生KNG-RAN*会降低安全强度。如果gNB有未使用的{NH,NCC}（AMF将NCC也发送给gNB，否则gNB无法识别是哪个NH，也无法告知UE），gNB由NH（垂直）衍生KNG-RAN*，否则，由KgNB（水平）衍生KNG-RAN*。下面，我们来具体分析各种切换场景，看看target的KgNB（即KNG-RAN*）的衍生机制，以及前向安全的实现程度。

先来看Intra-gNBHandover。

Intra-gNBHandover不涉及第三方（其他NG-RAN），前向安全也无从谈起。如果运营商乐意，gNB甚至可以选择保留currentKgNB（Intra-ng-eNBHandover不可以）。gNB应在HOCommand中告知UE，是否保留currentKgNB。如果gNB选择保留，UE和gNB在切换后继续使用currentKgNB。

如果gNB选择变更KgNB，gNB由NH或currentKgNB衍生KNG-RAN*，UE和gNB在切换后将KNG-RAN*作为KgNB使用。如果gNB有未使用的{NH,NCC}，垂直衍生KNG-RAN*，否则，水平衍生KNG-RAN*。由于NH是AMF衍生的，使用NH衍生KNG-RAN*可以摆脱前一个gNB（如果存在的话，比如在XnHandover之后的intra-gNBHandover）的影响，尽管NH对intra-gNBHandover自身安全没什么帮助，但可以利用intra-gNBHandover来增加整体安全性。

再来看XnHandover。

在初始接入中，AMF由KAMF衍生KgNB，再由KAMF和KgNB衍生NH1。AMF将KgNB传递给gNB，将NH1保留用于后续计算。此时，gNB没有{NH,NCC}，无法由NH（垂直）衍生KNG-RAN*，只能由KgNB（水平）衍生KNG-RAN*。如果在初始接入后，UE立即进行XnHandover，sourcegNB只能水平衍生KNG-RAN*。至少完成一次XnHandover后，（target）gNB才（可能）有未使用的{NH,NCC}。

在XnHandover中，sourcegNB直接向targetgNB发送切换请求。刚开始时，AMF没有参与交互，targetgNB也没有UE上下文，sourcegNB只好背起衍生KNG-RAN*的“锅”。sourcegNB由NH或currentKgNB衍生KNG-RAN*，通过XnAPHANDOVERREQUEST将{KNG-RAN*,NCC}传递给targetgNB。TargetgNB在PreparedHOCommand携带收到的NCC，封装在透明容器中，通过XnAPHANDOVERREQUESTACKNOWLEDGE发送给sourcegNB（绕了一圈），再转发给UE。如果UE收到的NCC“大于”（不等于）保存的NCC，UE先进行“NCC同步”，再由NH衍生KNG-RAN*（垂直衍生）；如果UE收到的NCC等于保存的NCC，UE由currentKgNB衍生KNG-RAN*（水平衍生）。

UE完成（无线）切换后，targetgNB向AMF发送NGAPPATHSWITCHREQUEST。AMF对本地保存的NCC加1（NCC=NCC+1），计算对应的NH，通过NGAPPATHSWITCHREQUESTACKNOWLEDGE将“新鲜”的{NH,NCC}发送给targetgNB。TargetgNB保存收到的{NH,NCC}给后续切换使用，删除此前保存的{NH,NCC}（如果存在的话）。

在初始接入后，如果UE连续进行XnHandover——第一次切换中，sourcegNB只能由currentKgNB水平衍生KNG-RAN*；后续切换中，sourcegNB（前一次切换的targetgNB）可以由NH垂直衍生KNG-RAN*（如果NH未被使用），因为sourcegNB（在上一次切换后）从AMF获得“新鲜”的{NH,NCC}。

在XnHandover中，sourcegNB（A）总是预先知道targetgNB（C）的KgNB（sourcegNB：就是老子算出来的），没有实现严格意义的前向安全。不过，sourcegNB（A）无法预先知道“再”下一跳（D）的KgNB（如果C由NH衍生KNG-RAN*，效果更佳）。因而，XnHandover至少实现了“n跳前向安全”（n=2）。如果希望进一步提高安全强度，targetgNB从NGAPPATHSWITCHREQUESTACKNOWLEDGE获得“新鲜”的{NH,NCC}后，可以立即执行intra-gNBHandover，由刚收到的NH衍生KgNB并进行更新。

最后看N2Handover。

和XnHandover不同，在N2Handover中，sourcegNB不直接向targetgNB发送切换请求，而向AMF发送NGAPHANDOVERREQUIRED，这给了AMF“介入”的机会。另一方面，在N2Handover中，AMF也可能会变更（XnHandover不允许AMF变更）。以下只讨论AMF变更场景，将AMF不变视为特例——AMF同时承担source和target两个角色，AMF之间的交互转变为AMF内部的交互。

sourcegNB向sourceAMF发送NGAPHANDOVERREQUIRED。SourceAMF对本地保存的NCC加1，计算对应的NH，通过Namf_Communication_CreateUEContextRequest将“新鲜”的{NH,NCC}发送给targetAMF。此外，SourceAMF会将计算NH的KAMF，以及对应的ngKSI、uplinkNASCOUNT和downlinkNASCOUNT发送给targetAMF。TargetAMF保存收到的KAMF和{NH,NCC}，通过NGAPHANDOVERREQUEST将“新鲜”的{NH,NCC}发送给targetgNB。TargetgNB删除此前保存的{NH,NCC}（如果存在的话），并由收到的NH衍生KNG-RAN*。TargetgNB在PreparedHOCommand携带收到的NCC，封装在透明容器中，通过targetAMF和sourceAMF发送给sourcegNB（这圈更大），再转发给UE。UE行为和XnHandover相同——N2Handover和XnHandover的差异在网络侧，对UE来说是一样的。

在N2Handover中，targetgNB总是（经targetAMF）从sourceAMF获得“新鲜”的{NH,NCC}，就算sourcegNB知道NHn-1（还不一定），由于没有KAMF，也无法计算NHn，更无法预先知道targetgNB由NHn衍生的KgNB。可以说，N2Handover实现了严格意义的前向安全。如果可以的话，TargetgNB会在PrepareHOCommand中对UE大声唱到：

妹妹你大胆地往前走啊~

在5GS中，UE从空闲态返回连接态，此前（连接的）gNB也无法预先知道当前的KgNB，这也可视为“前向安全”。在初始接入中，AMF和UE由KAMF和uplinkNASCOUNT衍生KgNB。只要AMF没有重新执行AKA，UE每发送一个受（NAS安全上下文）保护的NAS消息，uplinkNASCOUNT加1。UE携带的uplinkNASCOUNT总是“新鲜”的，因而KgNB也是“新鲜”的。UE每次初始接入，AMF和UE都会生成新的KgNB（NH0），对应新的NH链，此后targetgNB使用sourcegNB或targetgNB衍生的newKgNB（KNG-RAN*），NCC沿着NH链变更，水平衍生时NCC不变，垂直衍生时NCC=NCC+1。示图中，圈内数字表示NCC。UE每次初始接入，NCC重置为0，如果第一次切换为N2Handover、XnHandover或intra-gNBHandover，下一跳KgNB对应的NCC分别为2（垂直衍生）、0（水平衍生）、0（水平衍生）。下图是另一种呈现形式，竖向为NH链，UE共进行了3次初始接入，对应3个NH链，当gNB和UE由NH（NH0除外）衍生newKgNB（KNG-RAN*）时，为垂直衍生，KgNB对应NCC加1，当gNB和UE由currentKgNB衍生newKgNB（KNG-RAN*）时，为水平衍生，KgNB对应NCC不变。5GS这些玩法，和EPS没啥区别。在EPS中，MME和eNB按照相似方式衍生KeNB、NH和KeNB*（KDF的输入密钥KEY为KASME，FC分别为0x11、0x12、0x13）。在intra-eNBHandover或X2Handover中，如果sourceeNB有未使用的{NH,NCC}，由NH垂直衍生newKeNB（KeNB*），如果没有，由currentKeNB水平衍生newKeNB（KeNB*）。在S1Handover中，targeteNB总是（经targetMME）从sourceMME获得“新鲜”的{NH,NCC}，并由NH衍生newKeNB（KeNB*）。因而，X2Handover实现了“n跳前向安全”（n=2），S1Handover实现了严格意义的“前向安全”。那么……

5GS有什么不同？

5GS说：给你玩些高级的。换NH算什么，我把KAMF也换了。打个比方，KAMF是“爷爷”，NH是“爸爸”，KgNB是“孙子”。某个NH垂直衍生的KgNB，包括KgNB横向衍生的KgNB，都是同一NH“繁殖”的，“基因”也最相似。不同NH“繁殖”的KgNB就没那么相似，但还有同一KAMF的“基因”。如果KAMF也不同，顶多算是“五百年前是一家”（同一用户密钥K），实际上谁也不认识谁——这对前向安全是“坠吼的”啊！

和EPS不同，在5GS中，切换过程中可以进行NAS安全上下文和AS安全上下文的同步。如果sourceAMF激活新的（5G）NAS安全上下文（和生成当前AS安全上下文的NAS安全上下文不是同一个），且未完成UE上下文修改，此时发生切换（sourceAMF收到NGAPPATHSWITCHREQUEST，或NGAPHANDOVERREQUIRED），可以在切换的时完成NAS安全上下文和AS安全上下文的同步。

KAMF是NAS安全上下文的根密钥，KgNB是AS安全上下文的根密钥，而KgNB由KAMF衍生，变更KAMF，相当于把原有密钥“一锅端”，sourcegNB更别想知道targetgNB的KgNB，前向安全自然就实现了。当然，sourceAMF得向UE和gNB打个招呼，否则UE和gNB的安全上下文（NAS和AS）就不同步了。下面，我们来具体分析各种切换场景，看看KAMF是怎么变更的。

先来看XnHandover。

在XnHandover中，AMF收到NGAPPATHSWITCHREQUEST时，（无线）切换已经完成了。如果KAMF没有变更，AMF由currentKAMF生成“新鲜”的{NH,NCC}，通过NGAPPATHSWITCHREQUESTACKNOWLEDGE发送给targetgNB，用于下一次切换。如果KAMF变更，AMF、targetgNB和UE的行为就不一样了。协议没有描述NAS安全上下文的同步（大概是我没找到……），下面介绍AS安全上下文的同步。

首先，AMF需要由newKAMF衍生newKgNB（临时KgNB，作为NH0使用），KDF输入的uplinkNASCOUNT从最近的NASSecurityModeComplete获取；AMF将{newKgNB,0}作为“新鲜”的{NH,NCC}，通过NGAPPATHSWITCHREQUESTACKNOWLEDGE发送给UE，同时增加NSCI（NewSecurityContextIndicator）指示。targetgNB看到NSCI，立即执行intra-gNBHandover，使用刚收到的{newKgNB,0}衍生KNG-RAN*，并在HOCommand中增加keySetChangeIndicator，指示UE进行ASre-keying；最后，UE看到keySetChangeIndicator，按照和AMF、targetgNB相同的方式衍生newKgNB（作为NH0）和KNG-RAN*（作为KgNB）。

再来看N2Handover。

先说NAS安全上下文的同步。SourceAMF激活的NAS安全上下文，是和UE共享的，对UE来说，只要知道对应的ngKSI即可。sourceAMF将ngKSI、newKAMF、uplinkNASCOUNT和downlinkNASCOUNT发送给targetAMF，targetAMF就（临时）接管了UE的NAS连接。同时，sourceAMF在请求中增加keyAMFChangeInd，指示targetAMF这是newKAMF（NAS安全上下文）。

targetAMF将收到ngKSI放入NASC（NASContainer）的TSC（typeofsecuritycontext）和KSI（keysetidentifierin5G），封装在NGAPHANDOVERREQUEST中发送给targetgNB，targetgNB再将NASC封装在HOCommand中发送给UE。NASC作用基本等同于NASSMC，UE从NASC看到ngKSI，和当前ngKSI对比，就知道AMF是否激活新的NAS安全上下文。如果targetAMF和sourceAMF支持的NAS算法不同，或配置的NAS算法优先级不同，即使KAMF没有变更，targetAMF也可以在切换过程中变更NAS算法。TargetAMF将选择的NAS算法（NAS加密算法和NAS完整性算法）放入NASC，UE即可从NASC知道是否进行NAS算法变更，以及衍生新的NAS密钥——当然，KAMF变更和NAS算法变更可以同时进行。

再说AS安全上下文的同步。SourceAMF由newKAMF衍生newKgNB（作为NH0使用），KDF输入的uplinkNASCOUNT从最近的NASSecurityModeComplete获取；sourceAMF将{newKgNB,0}作为“新鲜”的{NH,NCC}，通过Namf_Communication_CreateUEContextRequest发送给targetAMF。sourceAMF在请求中增加keyAMFChangeInd，指示targetAMF这是newKAMF——targetAMF应指示gNB和UE进行ASre-keying。

TargetAMF将{newKgNB,0}作为“新鲜”的{NH,NCC}，通过NGAPHANDOVERREQUEST发送给UE，并增加NSCI（NewSecurityContextIndicator）指示。targetgNB看到NSCI，使用{newKgNB,0}衍生KNG-RAN*，并在HOCommand中增加keySetChangeIndicator，指示UE进行ASre-keying；最后，UE看到keySetChangeIndicator，按照和sourceAMF、targetgNB相同的方式衍生newKgNB（作为NH0）和KNG-RAN*（作为KgNB）。

还有一种KAMF变更。

SourceAMF倒是想换KAMF，可是从哪儿来未激活的共享NAS安全上下文呢（个人猜测，一种可能场景是，UE从EPS切换到5GS，使用从EPSNAS安全上下文映射的5GSNAS安全上下文，此时AMF可以激活原生的5GSNAS安全上下文）？不过，即使没有，SourceAMF也可以变更KAMF，这就是KAMF的水平衍生（KAMFHorizontalDerivation）。

和KgNB的水平衍生相似，KAMF的水平衍生就是由KAMF衍生KAMF'，作为KAMF使用——就像KAMF的“有丝分裂”。KAMF'沿用KAMF的ngKSI，但毕竟不同于KAMF（和UE的KAMF不同步），sourceAMF依然告知UE，KAMF变更了，并且是由KAMF水平衍生的。sourceAMF不仅会向targetAMF发送keyAMFChangeInd（和前面相同），还会发送keyAMFHDerivationInd。

接着，TargetAMF将收到ngKSI放入NASC中，封装在NGAPHANDOVERREQUEST中发送给targetgNB，targetgNB再封装在HOCommand中发送给UE。由于targetAMF收到keyAMFHDerivationInd，NASC中的K_AMF_change_flag（KACF）置为1，这样UE就会进行KAMF的水平衍生。K_AMF_change_flag这个名字取的不太好，容易误解为KAMF是否变更。实际上，K_AMF_change_flag表示newKAMF是否由currentKAMF“计算”获得（ifnewKAMFhasbeencalculated），即newKAMF是否由currentKAMF水平衍生。如果sourceAMF通过激活其他NAS安全上下文变更KAMF，UE比对ngKSI就知道了，此时K_AMF_change_flag置为0（newKAMF不是由currentKAMF计算获得）。

那么，如何计算KAMF'呢？根据3GPPTS33.501附录A.13，KDF的输入密钥KEY=currentKAMF，FC=0x72，P0=DIRECTION，P1=COUNT。在N2handover中，P0为0x01（idlemode