5GS的双连接安全和互操作安全学习笔记

5GS的双连接安全

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

DC（DualConnectivity）是UE在RRC连接态的一种工作模式（OperationMode），UE同时配置MCG（MasterCellGroup）和SCG（SecondaryCellGroup），以提升用户的体验速率。UE同时和两个基站“连接”，一个称为MN（MasterNode），另一个称为SN（SecondaryNode）。UE和CN（EPC或5GC）只和MN建立控制面连接（RRC连接和S1AP/NGAP连接），SN和MN通过Xx（X2或Xn）接口连接，为UE提供（Uu）用户面资源（如果忽略SRB3和SplitSRB）。DC是3GPP在R12引入的技术，最初MN和SN都是eNB。为了尽早利用NR优势，3GPP在R15引入MR-DC，即Multi-RATDualConnectivity。MR-DC可视为DC的“泛化”（generalization），MN和SN可以是不同基站类型（eNB、ng-eNB或gNB）。后来，3GPP把MR-DC重新定义为Multi-RadioDualConnectivity，将NR-NRDC（MN和SN都是gNB）也纳入MR-DC的范畴。

5GS的双连接，这里限定为MR-DCwith5GC（不包括EN-DC），MN和SN均为NG-RAN，即gNB或ng-eNB。根据NG-RAN的不同组合，MR-DCwith5GC包括三种类型：1、NGEN-DC（NG-RANE-UTRA-NRDualConnectivity），MN为ng-eNB，SN为gNB；2、NE-DC（NR-E-UTRADualConnectivity），MN为gNB，SN为ng-eNB；3、NR-DC（NR-NRDualConnectivity），MN为gNB，SN为gNB。MR-DC就不展开了，详见3GPPTS37.340，或参考《MR-DC是什么鬼？》系列。在5GS中，接入的数据保护包括加密保护和完全性保护（包含重放保护）。NAS保护在NAS层实现，RRC保护和UP保护在PDCP实现。UE和网络（AMF或NG-RAN）的NAS实体或PDCP实体使用相同的输入密钥（NAS密钥或AS密钥），相同的输入参数（BEARER、COUNT、DIRECTION、LENGTH、MESSAGE）和相同的保护算法（加密算法或完整性算法），获得相同的输出（KEYSTREAM或MAC），实现加密保护或完整性保护，详见3GPPTS33.501的6.4、6.5、6.6章节，或参考《5GS的数据保护》。

DC有什么影响呢？

对NAS保护来说，没什么影响。无论UE是否处于DC模式，NAS实体只在AMF和UE上，按照原有方式保护即可。对AS保护来说，如果SRB和DRB的PDCP实体还在MN上，也没什么影响。如果SNRRC消息通过Xn接口传递给MN，封装在MNRRC消息（CombinedMN/SNRRCMessage）中发送给UE，也是由MN的PDCP实体实现保护（SN不提供保护）。同样道理，SplitSRB（SRB1或SRB2）尽管占用SCG资源，但PDCP实体还在MN上，保护方式也保持不变。我们要重点分析的，是PDCP实体在SN上的DRB和SRB。

在UE进入DC模式之前，SRB（SRB1和SRB2）和DRB的PDCP实体都在（准）MN上，在UE进入DC模式之后，部分DRB的PDCP实体可能“迁移”（offload）到SN（SNTerminatedBearer）。同时，SN还可能建立SRB3（PDCP实体在SN，且SN类型为gNB），部分SNRRC消息（SCG的测量任务和测量报告）可能通过SN的Uu接口传送。那么，这些数据如何保护呢？

SN需要创建“自己”的AS安全上下文，包含“自己”的AS密钥（KRRCint、KRRCenc、KUPint和KUPenc），以保护在上述DRB和SRB（SRB3）传送的数据（UP数据和SNRRC消息）。和MN相同，SN的AS安全上下文也有一个根密钥，即KSN。显然，KSN来自于MN——在控制面上，MN是SN的唯一出路……

SN只能抱MN大腿了啊！

MN由KMN衍生KSN，通过Xn接口传递给SN。KMN和KSN是什么类型，取决于DC类型。更具体的：在NGEN-DC中，KMN为KeNB，KSN为S-KgNB；在NE-DC中，KMN为KgNB，KSN为S-KeNB；在NR-DC中，KMN为KgNB，KSN为S-KgNB。SN获得KSN后，由KSN衍生SN的AS密钥（KRRCint、KRRCenc、KUPint和KUPenc）。因而，SN安全上下文和MN安全上下文存在关联，MN总是由当前KMN衍生KSN，这为避免KSN重复提供了条件。如果MN变更，KMN也会变更（详见3GPPTS33.501的6.9.2章节，或参考《5GS的前向安全》），KSN随之变更。如果MN不变，SN变更，为了由相同的KMN衍生不同的KSN，MN将KMN和一个计数器关联，其数值作为衍生KSN的输入参数。这个计数器称为SNCounter。

在衍生KSN的KDF（KeyDerivationFunction）中，FC为0x79，P0为SNCounter（KDF在5GS中的应用，详见3GPPTS33.501的6.2.2章节，或参考《5GS的密钥衍生》）。SNCounter长度为16Bit，初始值为0。如果MN第一次添加SN，MN由当前KMN和SNCounter=0衍生KSN，SNCounter加1。后续MN每次衍生KSN，SNCounter都加1——由于SNCounter总是“新鲜”的，KSN也总是“新鲜”的。如果KMN不变，无论MN添加（和释放）多少次SN，SN相同还是不同，SNCounter都不会重置为0，总是单调增加。

SNCounter不传递给SN，KSN是MN衍生的，SNCounter对SN没有用。事实上，SN连KSN都不太想保留——SN由KSN衍生AS密钥后，可以就将KSN删除。这和SEAF的行为相似，SEAF由KSEAF衍生KAMF后，就将KSEAF删除。SN和SEAF这么“忘本”，是为了降低上游密钥（KMN或KAUSF）暴露的风险。

MN将SNCounter（SK-counter）传递给UE，UE才可以获得（和MN/SN）相同的KSN。这里还有一个小问题，MN和SN知道PDCP实体在哪一侧，但UE是无法区分的，特别是在MR-DCwith5GC中，所有PDCP实体都用NRPDCP（3GPPTS38.323）。因而，在RRC重配中，网络还要通过keyToUse告知UE，各个DRB用KMN（MasterKey）保护，还是用KSN（SecondaryKey）保护。SRB没有这个困惑，SRB1和SRB2总是用KMN保护（无论是否SplitSRB，PDCP实体总是在MN侧），SRB3总是用KSN保护（PDCP实体总是在SN侧）。

在SNADDITION中，MN由KMN和SNCounter（第一次添加SN时取值为0）衍生KSN，通过SNADDITIONREQUEST（Xn-C消息中KSN称为S-NG-RANnodeSecurityKey）传递给SN。SN返回SNADDITIONREQUESTACKNOWLEDGE后，MN将SNCounter通过RRCConnectionReconfiguration（MNRRC消息有完整性保护和重放保护，攻击者无法修改或重放SNCounter）传递给UE，并告知UE哪些DRB使用KSN。UE由（本地的）KMN和（接收的）SNCounter衍生KSN——理论上，应该和SN获得的KSN相同。SN的密钥来自MN，但在算法上，SN还有一点自主权。MN将UE安全能力通过SNADDITIONREQUEST传递给SN，SN选择本地配置优先级最高，且UE支持的AS算法（可以不同于MN选择的AS算法），通过SNADDITIONREQUESTACKNOWLEDGE返回，MN通过RRCConnectionReconfiguration传递给UE。对于使用KSN保护的DRB和SRB，UE使用SN选择的AS算法衍生（SN侧的）AS密钥——理论上，应该和SN衍生的AS密钥相同。另外，MN将从SMF获得的UP安全策略（UPsecuritypolicy）传递给SN，SN指示UE是否对DRB开启加密保护和（或）完整性保护。对于SplitPDUSession——部分DRB终结于MN，部分DRB终结于SN的PDUSession，MN应保证所有DRB同时开启（激活），或同时关闭（去激活）保护——为了实现这个目标，对于某个PDUSession，如果MN将部分DRB的PDCP实体“迁移”到SN，应将MN对UP保护的决定（开启或关闭）传递给SN，SN参照执行。

UP完整性保护相对复杂一些。原因是ng-eNB不支持UP完整性保护。如果UP安全策略指示为“required”：在NGEN-DC中，MN（ng-eNB）应拒绝PDUSession建立；在NE-DC中，如果MN（gNB）决定开启UP完整性保护，不能将同一PDUSession的DRB“迁移”到SN（ng-eNB）；在NR-DC中，MN决定MN终结的PDUSession是否开启UP完整性保护，SN决定SN终结的PDUSession是否开启UP完整性保护。

如果UP安全策略指示为“preferred”：在NGEN-DC中，MN（ng-eNB）和SN总是关闭UP完整性保护，在NE-DC中，如果MN（gNB）对PDUSession的任一DRB开启完整性保护，MN不能将同一PDUSession的DRB“迁移”到SN（ng-eNB），反之，如果MN关闭则可以“迁移”，但SN不可以开启UP完整性保护。如果UP安全策略指示为“notneeded”，那就简单了，MN和SN都消停吧。

在5GS中，如果UP完整性保护没有开启，NG-RAN可以通过CounterCheck流程（参考3GPPTS33.401或3GPPTS33.501）监测是否存在“man-in-the-middle”攻击。NG-RAN向UE发送CounterCheck，包含各个DRB的PDCPCOUNT（包括上行和下行）的高位（MSB），UE接收后和本地进行比对，向NG-RAN返回CounterCheckResponse。如果CounterCheckResponse没有包含PDCPCOUNT，表示一切正常。如果CounterCheckResponse包含某些DRB的PDCPCount，表示存在异常，NG-RAN可以释放对应的DRB，并向AMF或网管报告。在5GS的双连接中，如果DRB的PDCP实体“迁移”到SN，SN也可以通过MN触发CounterCheck流程——SN向MN发送S-NG-RANnodeCounterCheck，包括DRBID和期望的PDCPCOUNT，MN再向UE发送CounterCheck。不过，SN发送完就没啥事了，也不期望MN返回什么。对于MN终结的DRB，MN也可能会发送RRCCheck，MN收到的CounterCheckResponse，可能包含MN终结和SN终结的DRB，最好是啥都没有了。

没消息就是好消息啊。

如果MN释放SN，或SN变更（SNRelease或SNChange），（Old）SN和UE之间的DRB和SRB（SRB3）会释放，用于保护DRB和SRB的（SN）AS密钥也会删除。相似的，在N2Handover或XnHandover中，OldSN的AS密钥会删除——留着也没用，targetMN总会从sourceAMF（N2Handover）或sourceng-RAN（XnHandover）获得新的KMN（参考《5GS的前向安全》），衍生新的KSN，SN（无论是否变更）由新的KSN衍生新的（SN）AS密钥。

即使MN没有变更（N2Handover或XnHandover）或SN没有变更（SNChange），MN和SN也可能触发KSN更新，避免SN的NEA（加密保护）或NIA（完整性保护）生成重复的KEYSTREAM或MAC。NEA和NIA输入包括KEY、BEARER、COUNT、DIRECTION和LENGTH（适用于NEA），只要输入不重复，输出就不会重复。

首先，避免KEY重复。SN由KSN和AS算法（AlgorithmIdentity和AlgorithmTypeDistinguisher）衍生AS密钥，因而，KSN也不能重复（KDF输入没有新鲜因子）。再往前推，MN由KMN和SNCounter衍生KSN，如果KMN保持不变，SNCounter是KDF的新鲜因子，因而，如果SNCounter翻转（WrapAround），MN就不能衍生新的KSN了——MN通过Intra-CellHandover更新KMN，相应的，SNCounter重置为0。

如果MN为同一SN增加新的DRB，但从上次KSN更新后，DRBID已经分配完毕（空间耗尽），如果分配重复的DRBID，就会出现输入BEARER（DRBID）重复。此时，MN将SNCounter加1，衍生新的KSN，通过SNModification（MNInitiated）更新KSN。相似的，如果SN发现SCG的DRB（或SRB）的（uplink或downlink）PDCPCOUNT（HFN||PDCPSN）即将翻转（COUNT重复），通过SN触发SNModification（SNInitiatedwithMNinvolvement）更新KSN。通过MN触发的SNModification更新KSN，过程和SNAddition相似（参考前面的示图）。通过SN触发的SNModification更新KSN，SN向MN发送SNMODIFICATIONREQUIRED，并携带KeyChangeIndication（Xn-C消息中为S-NG-RANnodekeyupdaterequired，包含在PDCPChangeIndication中），表示请求更新KSN，MN将SNCounter加1，衍生新的KSN，通过SNModification更新KSN，后面部分和MN触发的SNModification相同。在安全方面，MR-DCwith5GC和EN-DC差不太多，区别主要是，MR-DCwith5GC的MN和SN都是NG-RAN，需要考虑SplitPDUSession和UP安全策略（包括UP完整性保护）的影响。5GS的互操作安全5GS还很遥远，但3GPP文档也很长，别说通读一遍，打开都要些勇气。我决定“分而治之”，拆成小块来学。这里和大家分享的，就是其中一小块——3GPPTS33.501（Securityarchitectureandproceduresfor5Gsystem）的8章节，5GS的SecurityofInterworking，即5GS的互操作安全。

所谓5GS的“互操作”，就是UE从EPS进入5GS，或从5GS进入EPS。5GS的“互操作”只涉及EPS（4G），和更早的UMTS（3G）等没有什么关系

5GS连EPS都有些瞧不上，其它系统更别提了，那些“过时的”玩意儿，就别来套近乎了。根据UE的状态，5GS的“互操作”分为IdleModeMobility（空闲态）和Handover（连接态），结合UE的移动方向，共有四种组合场景：<1>从EPS到5GS的IdleModeMobility（Registration）；<2>从5GS到EPS的IdleModeMobility（TAU）；<3>从5GS到EPS的Handover；<4>从EPS到5GS的Handover。EPS和5GS就像两个世界，UE从EPS进入5GS，或从5GS进入EPS，都得使用目标系统的安全上下文，所谓“入乡随俗”嘛。安全上下文从哪儿来，就和很多因素相关了，比如说，UE的“注册模式”——UE可能工作在“单注册”模式（SingleRegistrationMode）也可能工作在“双注册”模式（DualRegistrationMode）。

如果UE工作在“双注册”模式，UE维护两个独立的安全上下文，分别用于EPS和5GS——大家井水不犯河水哈。如果目标系统是EPS，UE和网络使用EPS安全上下文，遵循EPS的安全机制（3GPPTS33.401）；如果目标系统是5GS，UE和网络使用5GS安全上下文，遵循5GS的安全机制（3GPPTS33.501）。

如果UE工作在“单注册”模式，要看AMF和MME之间是否存在N26接口。如果网络支持没有N26接口的互操作：如果UE从5GS进入EPS，并且存在“current”的EPSNAS安全上下文，则使用这个EPS安全上下文；如果UE从EPS进入5GS，并且存在“current”的5GNAS安全上下文，则使用这个5G安全上下文。如果UE没有“current”的NAS安全上下文——协议没有说明，大概只能执行AKA（EPSAKA或5GAKA/EAP-AKA'）重新生成吧。

协议描述的重点，是UE工作在“单注册”模式，且存在N26接口的场景。AMF和MME在N26接口传递UE信息，特别是EPS安全上下文——对比鲜明的，无论在哪种场景中，N26接口都不会传递5G安全上下文。个人理解，这有两个原因：第一，AMF永远不会向5GS以外的实体传送5G安全参数，MME自然也不例外（MME：NND，主要就是针对我吧）；第二，MME作为Legacy（老古董）网元，AMF不能指望MME实现安全上下文的映射（相似的，EPS和UMTS之间的互操作，MME也不能指望SGSN）。AMF和MME在N26接口传递EPS安全上下文，是因为，UE在目标系统使用的安全上下文，大多数时候是映射安全上下文（mappedsecuritycontext）。也就是说，UE从EPS进入5GS，使用的5G安全上下文是从EPS安全上下文“映射”来的；而UE从5GS进入EPS，使用的EPS安全上下文是从5GS安全上下文“映射”来的。不过，无论UE如何移动，负责实现“映射”（Mapping）的永远是AMF（而不是MME）——引用“隔壁老李”的话，就是：WithGreatPowerComesGreatResponsibility…

能力越大，责任越大啊。

“映射”的关键，是NAS安全上下文的根密钥，即KAMF和KASME。如果从EPS安全上下文映射为5G安全上下文，AMF由KASME衍生KAMF'，作为映射5G安全上下文的KAMF；如果从5G安全上下文映射为EPS安全上下文，AMF由KAMF衍生KASME'，作为映射EPS安全上下文的KASME。映射安全上下文的KSI取值保持不变（newngKSI=oldeKSI，neweKSI=oldngKSI），类型置为“mapped”。因为映射根密钥是新启用的，映射安全上下文的NASCOUNT置为0。KDF（KeyDerivationFunction）在5GS的应用可参考《5GS的密钥衍生》。

更具体的…

如果AMF从EPS安全上下文映射为5G安全上下文：<1>在IdleModeMobility（Registration）中，AMF由KASME和EPSNASUPLINKCOUNT衍生KAMF'（KDF的FC为0x75）；在Handover中，AMF由KASME和（EPS）NH衍生KAMF'（KDF的FC为0x76），详见3GPPTS33.501的附录A.15。<2>KAMF'作为映射安全上下文的KAMF，ngKSI取值和KASME对应的eKSI相同，类型置为“mapped”。<3>映射5G安全上下文的5GNASCOUNT置为0。NH（NextHop）的定义可参考《5GS的前向安全》。如果AMF从5G安全上下文映射为EPS安全上下文：<1>在IdleModeMobility（TAU）中，AMF由KAMF和5GNASUPLINKCOUNT衍生KASME'（KDF的FC为0x73）；在Handover中，AMF由KAMF和5GNASDOWNLINKCOUNT衍生KASME'（KDF的FC为0x74），详见3GPPTS33.501的附录A.14。<2>KASME'作为映射安全上下文的KASME，eKSI取值和KAMF对应的ngKSI相同，类型置为“mapped”。<3>映射EPS安全上下文的EPSNASCOUNT置为0。

UE在目标系统使用的AS安全上下文，也有根密钥，即5GS的KNG-RAN（KgNB或Kng-eNB）或EPS的KeNB。从EPS到5GS的IdleModeMobility中，AMF由KAMF'和5GNASUPLINKCOUNT（=0）衍生KgNB，从5GS到EPS的IdleModeMobility中，MME由KASME'和EPSNASUPLINKCOUNT（=0）衍生KeNB。（以上是映射场景，先忽略原生场景）

系统间的Handover相对复杂，和系统内的N2Handover（5GS）或S1Handover（EPS）相似，又略有不同。从5GS到EPS的Handover中，sourceAMF由KASME'和UPLINKNASCOUNT（=2^32-1）衍生NH0（初始KeNB），再由NH0衍生NH1和NH2。sourceAMF将{NH2,NCC=2}传递给targetMME，再传递给targeteNB。targeteNB由NH（NH2）水平衍生KeNB*，作为KeNB使用。从EPS到5GS的Handover中，sourceMME由KASME衍生新的（EPS）NH。SourceMME将新的{NH,NCC}传递给targetAMF，但targetAMF没有传递给targetng-RAN（gNB或ng-eNB），由KASME和（EPS）NH衍生KAMF'。TargetAMF由KAMF'和UPLINKNASCOUNT（=2^32-1）衍生（5GS）NH0（初始KeNB），将{NH0,NCC=0}传递给targetNG-RAN。targetNG-RAN由（5GS）NH（NH0）水平衍生KNG-RAN*，作为KNG-RAN（KgNB或Kng-eNB）使用。简单的说，targetAMF将EPS的NH拦截了，用于衍生KAMF'，另外生成了5GS的NH给targetNG-RAN使用。

在安全算法方面，通常由目标系统选择。比如说，UE从EPS进入5GS，在IdleModeMobility中，AMF通过NASSMC向UE指示选择的5GNAS算法，详见3GPPTS33.501的8.2章节；在Handover中，AMF通过NAS容器向UE指示选择的5GNAS算法，详见3GPPTS33.501的8.4章节。（可参考《5GS的安全模式》）

UE从5GS进入EPS，又不太一样。在（此前的）5GS鉴权流程之后，AMF通过5GS的NASSMC指示UE，网络选择的EPSNAS算法——也就是说，在互操作之前，AMF和UE已经保存“未来”使用的EPSNAS算法，UE从5GS进入EPS，网络不用再指示UE选择的EPSNAS算法——如果MME非要变更（咽不下这口气），IdleModeMobility可以通过EPS的NASSMC实现（Handover就忍了，可以切换后再变更）。相对来说，AS算法自主性强一些，大概是基站更具有多样性吧（什么货色都有啊…）。

NAS安全上下文的根密钥（KAMF'或KASME'）和NAS算法确定，AMF或MME就可以衍生NAS密钥（KNASint和KNASenc）。AS安全上下文的根密钥（KNG-RAN*或KeNB*）和AS算法确定，NG-RAN或eNB就可以衍生AS密钥（KRRCint、KRRCenc、KUPint和KUPenc）。UE按照相同方式衍生NAS密钥和AS密钥。EPS的密钥详见3GPPTS33.401的附录A.7；5GS的密钥详见3GPPTS33.501的附录A.8，或参考《5GS的密钥体系》和《5GS的密钥衍生》。网络和UE有了算法和密钥，就可以对NAS消息、RRC消息和UP数据进行保护，可参考《5GS的数据保护》。一切都齐活儿了，再来看四个场景的信令流程。

场景1：从EPS到5GS的Registration

1、UE处于空闲态，从EPS进入5GS，向AMF发送RegistrationRequest。UE需要先解决一个小问题——UE只有oldMME分配的（EPS）GUTI，格式和5GGUTI不同，如果直接发给AMF，AMF不认识啊。因而，UE先将GUTI映射为5GGUTI，指示为“映射”类型。GUTI映射关系如下图所示：可见，映射5GGUTI只是样子变了，但依然包含oldMME的信息，AMF将5GGUTI还原为GUTI，就可以用GUMMEI查询DNS，获得oldMME的N26接口地址，向oldMME请求UE的EPS上下文，包括KASME。

UE需要解决的另一个问题，是证实自己的身份（队长，别开枪！），否则AMF只能触发AKA流程（可参考《5GS的鉴权流程》）。如果UE有原生（native）5G安全上下文，对RegistrationRequest进行（5GS）完整性保护，AMF可通过完整性校验确认UE身份——如果UE没有5G安全上下文，RegistrationRequest无法保护，但UE有EPS安全上下文，可对RegistrationRequest包含的TAURequest进行（EPS）完整性保护，AMF将TAURequest传递给oldMME，oldMME可通过完整性校验确认UE身份，就像UE直接向oldMME发送TAURequest一样。以下假定UE没有原生5G安全上下文。2、AMF由映射5GGUTI还原为（EPS）GUTI，使用GUMMEI构造FQDN查询DNS，获得oldMME的N26接口地址。3、AMF向oldMME发送ContextRequest，携带RegistrationRequest包含的TAURequest。4、oldMME对TAURequest进行完整性校验。5、如果校验通过，oldMME向AMF发送ContextResponse，携带UE上下文，包括KASME。

6、AMF由KASME和EPSNASUPLINKCOUNT衍生KAMF'（KDF的FC为0x75）。KAMF'作为映射安全上下文的KAMF，ngKSI取值和KASME对应的eKSI相同，类型置为“mapped”。映射5G安全上下文的5GNASCOUNT置为0。7、AMF激活映射5GNAS安全上下文，选择NAS算法，由KAMF'衍生NAS密钥，向UE发送NASSMC，携带ngKSI和NAS算法标识，并进行完整性保护。

8、UE发现ngKSI类型为“映射”，按照和AMF相同的方式，由eKSI（ngKSI）对应的KASME和EPSNASUPLINKCOUNT衍生KAMF'，和收到的ngKSI关联，映射5G安全上下文的5GNASCOUNT置为0。9、UE由KAMF'衍生NAS密钥，对NASSMC进行完整性校验——如果通过，UE向AMF发送NASSMP。10、AMF向UE发送RegistrationAccept，并使用新的NAS安全上下文保护。

如果UE有原生5GNAS安全上下文——RegistrationRequest携带（此前UE访问5GS时AMF分配的）5GGUTI和ngKSI，并进行（5GS）完整性保护。如果AMF有5GGUTI和ngKSI指示的5GNAS安全上下文，对RegistrationRequest进行（5GS）完整性校验——如果通过，AMF丢弃从oldMME获得的EPS安全参数——5GS安全性高于EPS，AMF更倾向于自己校验。毕竟，你（MME）办事……

我（AMF）不放心呀！

不过，如果AMF没有找到5G安全上下文，或完整性校验失败，就只能退而求其次了。AMF将RegistrationRequest视为unprotected，触发AKA（EAP-AKA'或5GAKA）流程，生成新的原生5G安全上下文，或者像前面描述那样，从EPS安全上下文映射为5G安全上下文（AMF：还是觉得你最好……MME：滚！）。

如果UE使用原生5G安全上下文保护RegistrationRequest，并且AMF沿用这个5G安全上下文，AMF可跳过NASSMC，直接向UE发送RegistrationAccept。可见，AMF激活的5G安全上下文有三种可能：1、已有的原生5G安全上下文（跳过NASSMC）；2、AKA新建的原生5G安全上下文（通过NASSMC激活）；3、从EPS安全上下文映射的5G安全上下文（通过NASSMC激活）。AMF使用激活的5G安全上下文保护RegistrationAccept。

如果AMF不使用已有的原生5G安全上下文（或没有），由新的（原生或映射）KAMF（或KAMF'）衍生KgNB（3GPPTS33.501的附录A.9）——KDF的FC为0x6E，P0为最近的NASSMP的5GUPLINKNASCOUNT（=0），P1（accesstype）取值为0x01（即3GPPaccess）。如果UE收到ASSMC，按照和AMF相同的方式由新的KAMF衍生KgNB。

场景2：从5GS到EPS的TAU

1、UE处于空闲态，从5GS进入EPS，向MME发送TAURequest，包含映射（EPS）GUTI和UE的EPS安全能力。（EPS）GUTI由5GGUTI映射获得，包含oldAMF的信息。尽管TAURequest是发送给MME的，UE依然“傲娇”的使用5G安全上下文（NAS密钥、NAS算法和5GNASUPLINKCOUNT）对TAURequest进行保护，生成NASMAC，就像在3GPP接入发送5GNAS消息一样。2、MME使用映射（EPS）GUTI的GUMMEI，构造FQDN查询DNS，获得oldAMF的N26接口地址。3、MME向oldAMF发送ContextRequest，携带TAURequest，包含eKSI（=ngKSI）、NASMAC和映射（EPS）GUTI。4、oldAMF对TAURequest进行（5G）完整性校验——如果通过，oldAMF由KAMF和5GNASUPLINKCOUNT衍生KASME'（KDF的FC为0x73）。KASME'作为映射安全上下文的KASME，eKSI取值和KAMF对应的ngKSI相同，类型置为“mapped”。映射EPS安全上下文的EPSNASCOUNT置为0。

5、oldAMF向MME发送ContextResponse，携带映射EPS安全上下文，并将EPSNAS算法设置为（此前）5GNASSMC指示UE的EPS算法。6、与此“同时”，UE按照和oldAMF相同的方式，从5G安全上下文映射为EPS安全上下文。7、MME对比收到的UE安全能力和本地配置的优先级列表，决定是否选择其他NAS算法。如果MME决定保持，跳过第8步~第10步。

8、如果MME选择其他NAS算法，MME向UE发送NASSMC，指示MME选择的NAS算法。MME由KASME'衍生NAS密钥，对NASSMC进行完整性保护。9、UE使用NASSMC指示的NAS算法衍生NAS密钥，对NASSMC进行完整性校验。10、如果校验通过，UE向MME发送NASSMP，使用新的NAS安全上下文进行保护。11、MME向UE发送TAUAccept。

场景3：从5GS到EPS的HO

假定UE在5GC注册并处于连接态，UE和AMF共享5G安全上下文——这个安全上下文可能是（此前）5GS的AKA产生的原生5G安全上下文，或是UE从EPS进入5GS产生的映射5G安全上下文，anyway，就是UE和AMF当前使用的5G安全上下文。

1、sourceNG-RAN向sourceAMF发送HANDOVERREQUIRED，包含UE的ID和UE安全能力。sourceAMF确认UE的接入权限和安全能力，2、sourceAMF构造包含映射EPS安全上下文的UE上下文，以提供给targetMME使用。SourceAMF由KAMF和5GNASDOWNLINKCOUNT衍生KASME'（KDF的FC为0x74），然后将5GNASDOWNLINKCOUNT加1。KASME'作为映射安全上下文的KASME，eKSI取值和KAMF对应的ngKSI相同，类型置为“mapped”。映射EPS安全上下文的EPSNASCOUNT置为0。

TargetMME将sourceAMF视为另一个MME，期待通过N26接口收到选择的EPSNAS算法。SourceAMF将此前通过5GNASSMC指示UE的EPSNAS算法传递给targetMME，用于UE从5GS到EPS的Handover过程。如果targetMME希望选择其他EPSNAS算法，只能在随后的TAU流程中通过EPSNASSMC实现。

SourceAMF由KASME'和UPLINKNASCOUNT（=2^32-1）衍生初始KeNB（或临时KeNB），即NH0。SourceAMF再由KASME'和NH0衍生NH1和NH2。由此，sourceAMF构造了targeteNB衍生KeNB*的{NH2,NCC=2}，将作为UE上下文的一部分传递给targetMME。NCC（NHChainCounter）的定义可参考《5GS的前向安全》。

3、sourceAMF向targetMME发送ForwardRelocationRequest，携带UE安全上下文，包括eKSI（ngKSI）、KASME'、EPSNASCOUNT、UE的EPS安全能力、sourceAMF指示的EPSNAS算法标识，也可能包含UE的NR安全能力。4、targetMME收到ForwardRelocationRequest后，根据sourceAMF指示的EPSNAS算法，由KASME'衍生NAS密钥，向targeteNB发送HANDOVERREQUEST，携带从sourceAMF收到的UE的EPS安全能力和{NH2,NCC=2}。

5、targeteNB收到HANDOVERREQUEST后，由NH（NH2）水平衍生KeNB*，作为KeNB使用，选择本地配置优先级最高，且UE支持的AS算法，构造targettosourcetransparentcontainer，包含收到的NCC（=2）和选择的AS算法标识。TargeteNB向targetMME发送HANDOVERREQUESTACK，携带targettosourcetransparentcontainer。6、targetMME向sourceAMF发送ForwardRelocationResponse，携带targettosourcetransparentcontainer。

7、sourceAMF向sourceNG-RAN发送HANDOVERCOMMAND，携带targettosourcetransparentcontainer，以及sourceAMF用于衍生KASME'的5GDOWNLINKNASCOUNT的8LSB（LeastSignificantBit）。8、sourceNG-RAN向UE发送HANDOVERCOMMAND，携带targettosourcetransparentcontainer和5GDOWNLINKNASCOUNT的8LSB。

UE收到HANDOVERCOMMAND后，根据收到的5GDOWNLINKNASCOUNT的8LSB和本地的5GDOWNLINKNASCOUNT估算完整的5GDOWNLINKNASCOUNT——当然，应该大于本地保存的数值。UE按照和sourceAMF相同的方式，由KAMF和（估算的）5GNASDOWNLINKCOUNT衍生KASME'（KDF的FC为0x74），将本地5GNASDOWNLINKCOUNT置为接收的（估算的）5GDOWNLINKNASCOUNT（和sourceAMF保持同步）。

9、UE按照和targetMME相同的方式，根据sourceAMF指示的EPSNAS算法，由KASME'衍生NAS密钥——在HANDOVERCOMMAND中，网络不需要再向UE指示EPSNAS算法，UE使用（此前的）5GNASSMC指示的EPSNAS算法即可。

UE按照和sourceAMF相同的方式，由KASME'和UPLINKNASCOUNT（=2^32-1）衍生初始KeNB，即NH0，再由KASME'和NH0衍生NH1和NH2。接着，UE按照和targeteNB相同的方式，由NH（NH2）水平衍生KeNB*，作为KeNB使用。最后，根据targeteNB选择的AS算法，UE由KeNB*衍生AS密钥。

10、UE向targeteNB发送HANDOVERCOMPLETE，使用新的AS安全上下文进行保护。11、targeteNB向targetMME发送HANDOVERNOTIFY。

场景4：从EPS到5GS的HO

假定UE在EPC注册并处于连接态，UE和MME共享EPS安全上下文——这个安全上下文可能是（此前）EPS的AKA产生的原生EPS安全上下文，或是UE从5GS进入EPS产生的映射EPS安全上下文，anyway，就是UE和MME当前使用的EPS安全上下文。

1、sourceeNB向sourceMME发送HANDOVERREQUIRED，包含UE的ID和UE安全能力。sourceMME确认UE的接入权限和安全能力。2、sourceMME由KASME衍生新的NH，选择targetAMF，向targetAMF发送ForwardRelocationRequest，携带UE安全上下文，包括eKSI、KASME'、EPSNASCOUNT、UE的EPS安全能力、选择的EPSNAS算法标识，新的{NH,NCC}，也可能包含UE的NR安全能力。3、targetAMF收到ForwardRelocationRequest后，从EPS安全上下文映射为5G安全上下文。Target

AMF由KASME和收到的NH衍生KAMF'（KDF的FC为0x76）。KAMF'作为映射安全上下文的KAMF，ngKSI取值和KASME对应的eKSI相同，类型置为“mapped”。映射5G安全上下文的EPSNASCOUNT置为0。

TargetAMF选择本地配置优先级最高，且UE支持的NAS算法——如果targetAMF没有从sourceMME获得UE的NR安全能力，假设UE支持默认能力集：NEA0、128-NEA1和128-NEA2（加密）；128-NIA1和128-NIA2（完整性）。根据选择的NAS算法，TargetAMF由KAMF'衍生NAS密钥，同时，targetAMF将从sourceMME收到的EPSNAS算法保存到映射5G安全上下文。

和场景3不同，sourceMME生成的（EPS）NH已经用于衍生KAMF'，targetAMF需要另外生成（5GS）NH——TargetAMF由KAMF'和UPLINKNASCOUNT（=2^32-1）衍生临时KeNB，即NH0。TargetAMF构造NASC（NASContai