一种物联网设备的认证凭证更新的方法及设备与流程

本发明涉及通信技术领域，尤其涉及一种物联网设备的认证凭证(Credenti al)更新的方法及设备。

背景技术：

随着物联网和移动互联网的发展，更多的物联网业务(远程抄表、智能家居等)被引入人们的生活，从而使得更多的物联网设备类型(如电表、水表、可穿戴设备等)不断出现，并被作为终端接入到运营商网络中，接受运营商网络的控制。物联网设备接入运营商的网络时，跟普通终端(如手机)一样需要物联网设备和运营商网络的HSS(归属签约用户服务器)之间提前共享认证凭证(或者称为信任状)，并基于该认证凭证执行物联网设备和网络之间的相互认证以及会话密钥的生成。与普通终端不同的是，在某些场景下，物联网设备中的认证凭证是需要更新的，该认证凭证至少包括：根密钥K和签约用户标识(也就是经常说的IMSI)。在同一运营商网络中申请更新认证凭证的时候，可以选择只更新认证凭证中的根密钥K，也可以选择更新整个认证凭证。

对于普通终端(如手机)，认证凭证都是由与运营商有合同关系的卡商提前写入UICC(通用集成电路卡)中，用户从运营商或者分销商处购买携带认证凭证的UICC插入到终端上，实现终端接入运营商网络。如果一个普通终端需要更新认证凭证(可以是更新为同一个运营商的认证凭证，也可以是更新为另一个运营商的认证凭证)，只需要重新购买写有运营商认证凭证的UICC即可。对于物联网设备，有可能用户无法亲自跑到现场去更换可插拔的UICC，比如：1)租赁公司的汽车已经被开到外地了，租赁公司不可能跑到外地去更换卡；2)物联网设备在森林广泛部署，挨个手动更换卡的工作量巨大；3)物联网设备有可能工作在震动的环境，普通的UICC不能满足震动环境，需要使用eUICC(嵌入式UICC)来存储认证凭证，此场景下eUICC焊接在物联网设备的主板上不可插拔，现有的通过更换可插拔的UICC来更换认证凭证的方式不适用。

为了解决上述可插拔卡或eUICC上的认证凭证更新的问题，3GPP给出了解决方案：参见图1，选择使用MNO_A网络的M2M(Machine-to-Machine/Man的简称)用户想放弃使用MNO_A的网络，更改成使用MNO_B网络。此时，该用户需要向MNO_A申请更换运营商；得到MNO_A允许后，MNO_B向MNO_A发送IMSI(国际移动用户识别码)列表，然后MNO_A使用标准的OTA(Over－the－Air Technology，空中下载技术)过程将M2M设备中的USIM(全球用户识别卡)上的IMSI改成收到的MNO_B的IMSI，并且将包含M2M设备的新IMSI，认证凭证根密钥K，关联的OTA密钥的列表发送给包含M2M设备的新IMSI，认证凭证中的根密钥K，关联的OTA密钥的列表。此过程结束后，M2M设备和MNO_B网络之间实现了共享认证凭证中的根密钥K以及与之对应的MNO_B分配的IMSI。另外，GSMA在讨论eUICC的方案时，又提出对于使用eUICC的物联网设备，为了实现更改运营商认证凭证，可以让运营商将包含认证凭证、算法等的签约关系打包后放入卡管理中心，用户需要使用哪个运营商的认证凭证，就可以从卡管理中心去下载。

然而，在上述方案中，需要MNO_B将自己的IMSI发给MNO_A，需要MNO_A将之前与M2M设备之间共享的认证凭证中的根密钥K发送给MNO_B。从商业模式上，运营商不会希望自己的认证凭证中的根密钥K以及控制的IMSI被别的运营商知道。在GSMA讨论的方案中，需要构建专门的卡管理中心，并且，需要所有的运营商都信任该卡管理中心。谁来构建和运营所有运营商都信任的卡管理中心是一个难题。

因此，亟需一种在不需要设置专门的卡管理中心的情况下，就能够有效的对物联网设备上的可插拔卡或不可插拔卡上的认证凭证进行更新的技术方案。

技术实现要素：

鉴于上述技术问题，本发明实施例提供一种物联网设备的认证凭证更新的方法及设备，在不需要设置专门的卡管理中心的情况下，能够保证物联网设备在认证凭证可能泄露或攻击后能够快速更新认证凭证，从而保证了物联网设备以及网络的安全。

上述技术方案中的一个技术方案具有如下优点或有益效果：实现物联网设备自动更新认证凭证，保证物联网设备在认证凭证可能泄露或攻击后能够快速更新认证凭证，从而保证了物联网UE(物联网设备)以及网络的安全。并且当用户因业务需求导致需要将另一个运营商网络作为归属网络时，能快速、方便的将该物联网设备上的可插拔卡(例如UICC)或不可插拔卡(例如eUICC)上的认证凭证更换为该运营商网络的认证凭证，可以是同一个运营商内的认证凭证更新，也可以是不同运营商(即跨运营商)的认证凭证更新。

附图说明

图1为现有技术中的更改运营商认证凭证流程图；

图2为本发明实施例一中物联网设备的认证凭证更新的方法的流程图；

图3为本发明实施例二中物联网设备的认证凭证更新的方法的流程图；

图4为本发明实施例三中同一运营商内网络侧主动更新认证凭证的流程示意图；

图5为本发明实施例四中同一运营商内终端侧主动更新认证凭证的流程示意图；

图6为本发明实施例五中跨运营商网络侧主动更新认证凭证的流程示意图；

图7为本发明实施例六中跨运营商终端侧主动更新认证凭证的流程示意图；

图8为本发明实施例七中物联网设备的结构框图；

图9为本发明实施例八中网络设备的结构框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本领域技术人员知道，本发明的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本发明的实施例可以具体实现为以下形式：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

实施例一

参见图2，图中示出了物联网设备的认证凭证更新的方法的流程，该方法的执行主体可以是物联网设备(或者称为物联网UE)，所述物联网设备包括：存储有认证凭证的可插拔卡(例如UICC)或者不可插拔卡(例如eUICC)，具体步骤如下：

步骤201、向网络侧发送认证凭证更新请求，所述认证凭证更新请求至少包括：可插拔卡或者不可插拔卡产生的公钥；

可选地，在本实施例中物联网设备可以通过以下方式向网络侧发送认证凭证更新请求。

方式一、物联网设备接收网络侧发送的认证凭证更新命令；然后物联网设备根据认证凭证更新命令向网络侧发送认证凭证更新请求。

方式二、当认证凭证的使用时间到达使用期限时，物联网设备向网络侧发送认证凭证更新请求。

网络侧主动认证凭证更新方式(方式一)和终端侧主动认证凭证更新方式(方式二)相比，由网络触发更新可以避免物联网设备遭受攻击后不停地向网络发送更新认证凭证请求，占用网络资源的风险。

步骤202、接收网络发送的认证凭证更新响应，所述认证凭证更新响应至少包括：经过所述公钥加密的新的认证凭证和所述新的认证凭证的标识，其中，所述新的认证凭证和新的认证凭证的标识是网络侧根据所述认证凭证更新请求为所述物联网设备分配的；

步骤203、通过所述可插拔卡或者不可插拔卡产生的私钥至少解密出新的认证凭证和新的认证凭证的标识；

如果用户申请了同时更新根密钥和签约用户标识，所述认证凭证更新响应中经过所述公钥加密的认证凭证至少包括：更新的根密钥和更新的签约用户标识(例如更新的IMSI)，上述更新的根密钥和更新的签约用户标识是由网络侧为物联网设备分配的，并存储在物联网设备上的可插拔卡或者不可插拔卡上的；在步骤203中，通过所述可插拔卡或者不可插拔卡产生的私钥解密出新的认证凭证中的更新的根密钥和更新的签约用户标识，以及新的认证凭证的标识。

步骤204、通过所述新的认证凭证更新之前存储的认证凭证。

物联网设备和网络之间完成附着流程后，物联网设备可以用更新的认证凭证接入运营商网络。

在步骤204之后，若所述认证凭证更新响应中经过所述公钥加密的认证凭证至少包括：更新的根密钥，还可以进一步地，将所述新的认证凭证中的更新的根密钥和新的认证凭证的标识绑定存储。或者

如果用户申请了同时更新根密钥和签约用户标识，所述认证凭证更新响应中经过所述公钥加密的认证凭证至少包括：更新的根密钥和更新的签约用户标识，还可以进一步地，将所述新的认证凭证中的更新的根密钥、新的认证凭证的标识和网络侧分配给用户的签约用户标识绑定存储。

与现有技术相比，本发明的实施例不仅适用于可插拔的UICC，还适用于不可插拔的eUICC，而且不需要有专门的卡管理平台。本发明的实施例可避免运营商的认证凭证和签约用户标识(例如IMSI)被第三方托管，不需要运营商之间传递明文的认证凭证(即根密钥)、签约用户标识以及OTA密钥，避免运营商的这些信息被其他运营商知道。本发明的实施例可以最大化的利用现有的信令消息来传递更新认证凭证相关的信息。即使现有的认证凭证已经被攻击者获知，现有的信令消息的完整性、机密性失效，由于新的认证凭证使用了UICC或eUICC的公钥进行加密保护，所以攻击者还是不能够获取新的认证凭证。而当UICC或eUICC使用新的认证凭证进行网络附着时，攻击者即使还有原来泄密的认证凭证，也不能获取使用新认证凭证进行保护的网络信息。

实施例二

参见图3，图中示出了一种物联网设备的认证凭证更新的方法，物联网设备包括：存储有认证凭证的可插拔卡或者不可插拔卡，在同一运营商内网络侧主动更新认证凭证的场景和同一运营商内终端侧主动更新认证凭证的场景中，该方法的执行主体为HSS/HLR；在跨运营商的网络侧主动更新认证凭证的场景和跨运营商的终端侧主动更新认证凭证的场景中，该方法的执行主体为拜访地HSS/HLR。

参见图3，具体步骤如下：

步骤301、接收所述物联网设备发送的认证凭证更新请求，所述认证凭证更新请求至少包括：可插拔卡或者不可插拔卡产生的公钥；

在跨运营商的网络侧主动更新认证凭证的场景和跨运营商的终端侧主动更新认证凭证的场景中，在步骤301中拜访地HSS/HLR接收归属HSS/HLR转发的所述物联网设备发送的认证凭证更新请求，所述认证凭证更新请求包括：可插拔卡或者不可插拔卡产生的公钥和当前归属运营商网络的标识。

步骤302、根据所述认证凭证更新请求为所述物联网设备至少分配新的认证凭证和新的认证凭证的标识，并通过所述公钥对所述新的认证凭证和所述新的认证凭证的标识进行加密；

在跨运营商的网络侧主动更新认证凭证的场景和跨运营商的终端侧主动更新认证凭证的场景中，在步骤302中，拜访地HSS/HLR根据所述认证凭证更新请求为所述物联网设备分配包含由拜访运营商分配的属于拜访运营商的根密钥和签约用户标识的新的认证凭证和新的认证凭证的标识，并通过所述公钥对拜访运营商分配的新的认证凭证和所述新的认证凭证的标识进行加密；

步骤303、向物联网设备发送认证凭证更新响应，所述认证凭证更新响应至少包括：经过所述公钥加密的新的认证凭证和所述新的认证凭证的标识。

在跨运营商的网络侧主动更新认证凭证的场景和跨运营商的终端侧主动更新认证凭证的场景中，在步骤303中，拜访地HSS/HLR通过归属HSS/HLR向物联网设备发送认证凭证更新响应，所述认证凭证更新响应包括：经过所述公钥加密的新的认证凭证和所述新的认证凭证的标识。

可选地，在同一运营商内网络侧主动更新认证凭证的场景和同一运营商内终端侧主动更新认证凭证的场景中，在步骤301之后，所述方法还包括：

检查所述物联网设备是否有权限进行认证凭证更新以及更新认证凭证时是只更新根密钥还是同时更新签约用户标识(例如IMSI)；

若有权限只更新认证凭证且不同时更新签约用户标识，则根据所述认证凭证更新请求为所述物联网设备分配只包含更新的根密钥的新的认证凭证和新的认证凭证的标识，并通过所述公钥对所述新的认证凭证和所述新的认证凭证的标识进行加密；

若有权限更新认证凭证且同时更新签约用户标识，根据所述认证凭证更新请求为所述物联网设备分配包含更新的根密钥和更新的签约用户标识的新的认证凭证和新的认证凭证的标识，并通过所述公钥对所述新的认证凭证中的更新的根密钥和更新的签约用户标识和所述新的认证凭证的标识进行加密；

向物联网设备发送经过所述公钥加密的包含更新的根密钥和更新的签约用户标识的新的认证凭证和所述新的认证凭证的标识。

与现有技术相比，本发明的实施例不仅适用于可插拔的UICC，还适用于不可插拔的eUICC，而且不需要有专门的卡管理平台。本发明的实施例可避免运营商的认证凭证和签约用户标识(IMSI)被第三方托管，不需要运营商之间传递明文的认证凭证、签约用户标识以及OTA密钥，避免运营商的这些信息被其他运营商知道。本发明的实施例可以最大化的利用现有的信令消息来传递更新认证凭证相关的信息。即使现有的认证凭证已经被攻击者获知，现有的信令消息的完整性、机密性失效，由于新的认证凭证使用了UICC或eUICC的公钥进行加密保护，所以攻击者还是不能够获取新的认证凭证。而当UICC或eUICC使用新的认证凭证进行网络附着时，攻击者即使还有原来泄密的认证凭证，也不能获取使用新认证凭证进行保护的网络信息。

实施例三

本实施例适用的场景是：同一运营商内网络侧主动更新认证凭证的场景。

在本实施例中，由网络侧触发物联网UE上的认证凭证更新。网络侧向物联网UE发送认证凭证更新命令，HSS(归属签约用户服务器)/HLR(归属位置寄存器)使用物联网UE上的UICC或eUICC(或者称为UICC卡或eUICC卡)的公钥加密新的认证凭证并通过物联网UE和网络之间已经建立的受完整性保护的信令链路将加密的新的认证凭证发送给物联网UE。具体如图4所示：

如图4所示，当用户需更新他的物联网UE上的认证凭证时，可以首先执行步骤400，即用户向运营商申请更新他的物联网UE上的认证凭证，比如通过打电话给运营商客服申请，或者通过运营商网站进行在线申请。用户申请更新他的物联网UE上的认证凭证时，需要向运营商提供需要更新的物联网UE上的IMSI(国际移动用户识别码)以及当前认证凭证的标识KID。由于初始的认证凭证(即根密钥K和IMSI)按照现有流程是没有KID的，所以对于第一次请求更新认证凭证的物联网UE可以不包含KID。另外该用户还可以向运营商说明在更新认证凭证时是只更新根密钥K，还是根密钥K和IMSI均更新。运营商同意用户更新认证凭证的申请后，会将该申请作为该用户的签约关系的一部分存放到签约数据库中。网络主动发起认证凭证更新的流程为：

步骤401、运营商收到并允许用户更新认证凭证请求后，运营商网络侧(如HSS或者专门管理认证凭证更新的网元)通过MME(移动性管理实体)/SGSN(服务GPRS支持节点)/MSC(移动交换中心)向用户的物联网UE发送认证凭证更新命令，例如CredentialUpdateCommand。

上述认证凭证更新命令可以是新增的单独的一条信令，也可以通过MME/SGSN/MSC向UE发paging消息(寻呼消息)，将该认证凭证更新命令包含在该paging消息中。比如，在paging消息中增加一个IE(Information Element，信息元素)来标识认证凭证更新命令。

步骤402、物联网UE收到认证凭证更新命令后，向MME/SGSN/MSC发送认证凭证更新请求，在该认证凭证更新请求中携带该物联网UE的IMSI以及UICC或eUICC产生的公钥。

可选地，上述认证凭证更新请求可以是在该UE跟网络进行AKA认证，并通过安全模式开启信令的完整性和机密性保护之后的独立的一条信令，也可以包含在TAU(跟踪区更新)/RAU(路由区更新)/LAU(位置区更新)消息中，比如，在TAU/RAU/LAU消息中增加一个IE(Information Element)来标识认证凭证更新命令。

步骤403、MME/SGSN/MSC向HSS/HLR转发认证凭证更新请求。

步骤404、HSS/HLR收到认证凭证更新请求后，检查该UE的签约关系中是否有权限进行认证凭证更新以及更新认证凭证时是否同时更新IMSI。

如果有权限更新认证凭证而且不同时更新IMSI，HSS/HLR选择一个未使用的认证凭证的根密钥K作为该UE更新的认证凭证，为该认证凭证分配一个认证凭证的标识KID，并使用UE的公钥加密该认证凭证的根密钥K和认证凭证的标识KID；

如果该用户有权限更新认证凭证而且同时更新IMSI，HSS/HLR选择一个未使用的认证凭证作为该UE更新的认证凭证，为该认证凭证分配一个认证凭证的标识KID，该认证凭证包含未使用的根密钥K和新IMSI，最后使用UE的公钥加密该认证凭证和标识KID。

步骤405、HSS/HLR向MME/SGSN/MSC发送认证凭证更新响应消息，在该响应消息中包含加密的认证凭证的标识KID和新的认证凭证。

步骤406、MME/SGSN/MSC通过eNB(基站)/RNC(无线网络控制器)/BSS(基站子系统)向UE转发认证凭证更新响应消息，该认证凭证更新响应消息可以是单独的一条信令承载(如NAS消息)，也可以是包含在TAU/RAU/LAU response消息中，例如在TAU/RAU/LAU response消息中增加一个IE(Information Element)来标识认证凭证更新命令。

步骤407、物联网UE收到认证凭证更新消息后，物联网设备通过机卡接口将加密的新的认证凭证、认证凭证的标识KID发送给UICC或eUICC。该UICC或eUICC上的公私钥处理模块使用私钥解密出新认证凭证中的根密钥K、新IMSI(可选)和认证凭证的标识KID，USIM应用使用该新认证凭证更新之前存储的认证凭证，并将认证凭证的标识KID和新的认证凭证绑定存储。

需要说明的是，如果用户没有申请IMSI更新，那么更新的认证凭证中的根密钥K与该UE原来的IMSI，以及新分配的认证凭证的标识KID绑定存储；如果用户申请了IMSI更新，那么更新的认证凭证中的根密钥K、新分配的认证凭证的标识KID与新IMSI绑定存储。

步骤408、物联网UE发起detach(去附着)请求，和网络之间进行去附着的流程。

可选地，在去附着的原因中指明是更新认证凭证。此步骤也可以是HSS/HLR主动触发物联网UE发起去附着流程。

步骤409、物联网UE向网络发起附着流程，在attach request中需要携带认证凭证的标识KID，以便HSS/HLR能够识别该物联网UE使用是哪个的认证凭证。物联网UE和网络之间完成附着流程后，物联网UE就是用更新的认证凭证接入了运营商的网络。

实施例四

本实施例适用的场景是：同一运营商内终端侧主动更新认证凭证。

在本实施例中，由物联网UE来触发物联网UE上的认证凭证更新。物联网UE向网络发送认证凭证更新请求，HSS/HLR使用物联网UE上的UICC卡的公钥加密新的认证凭证并通过物联网UE和网络之间已经建立的受完整性保护的信令链路将加密的新的认证凭证发送给物联网设备。具体如图5所示。

如图5所示，当用户需更新他的物联网UE上的认证凭证时，可以首先执行步骤500，即用户向运营商申请更新他的物联网UE上的认证凭证，比如通过打电话给运营商客服申请，或者通过运营商网站进行在线申请。该申请主要可以是向运营商签约该用户所拥有的物联网UE具备认证凭证更新的服务，还可以限定该物联网UE在认证凭证使用期限到期时并且该认证凭证更新服务可以由物联网UE主动发起更新。用户申请更新他的物联网UE上的认证凭证时，需要向运营商提供该需要更新的物联网UE上的IMSI以及当前认证凭证的标识KID。由于初始的认证凭证按照现有流程是没有KID的，所以对于第一次请求更新认证凭证的物联网UE可以不包含KID。另外该用户还需要向运营商说明在更新认证凭证时是只更新根密钥K还是根密钥Ki和IMSI均更新。运营商同意用户更新认证凭证的申请后，会将该申请作为该用户的签约关系的一部分存放到签约数据库中。

终端侧主动发起认证凭证更新的流程为：

步骤501、用户使用物联网UE向MME/SGSN/MSC发送认证凭证更新请求。在该请求中携带该物联网UE的IMSI以及UICC或eUICC产生的公钥。该认证凭证更新请求可以是独立的一条信令，也可以包含在TAU/RAU/LAU消息中。

需要说明的是，步骤501中用户实现物联网UE向MME/SGSN/MSC发送认证凭证更新请求，可以有以下两种方式：

方式一、物联网设备上支持定时器，计算每个认证凭证的使用时间，当认证凭证的使用时间到达使用期限时，定时器触发物联网设备发起认证凭证更新流程。此过程需要HSS/HLR也针对每个认证凭证的使用时间进行监控，并在收到认证凭证更新请求时检查是否已经满足需要更新的时间区间。此方法不需要用户参与操控设备。

方式二、用户申请后，直接在物联网设备上手动操作启动更新认证凭证的功能，使得物联网UE发起认证凭证更新请求。此方法不需要物联网设备和HSS/HLR来监控认证凭证的使用时间，但是需要用户手动操控物联网设备。此方法不适用于用户不能到达现场操控设备的场景。

步骤502、MME/SGSN/MSC向HSS/HLR转发认证凭证更新请求。

步骤503、HSS/HLR收到认证凭证更新请求后，检查该UE是否有权限进行认证凭证更新以及更新认证凭证时是否同时更新IMSI，比如是否签约了认证凭证更新的服务，认证凭证的使用期限是否已满等。

如果有权限更新认证凭证而且不同时更新IMSI，HSS/HLR选择一个未使用的认证凭证中的根密钥K作为该UE更新的认证凭证中的根密钥K，为该认证凭证分配一个认证凭证的标识KID，并使用UICC或eUICC的公钥加密该新的认证凭证中的根密钥K和认证凭证的标识KID；

如果该用户有权限更新认证凭证中的根密钥K而且同时更新IMSI，HSS/HLR选择一个未使用的认证凭证作为该UE更新的认证凭证，为该认证凭证分配一个认证凭证的标识KID，该新的认证凭证包含根密钥K和一个未使用的新IMSI，最后使用UE的公钥加密该新的认证凭证和认证凭证的标识KID。

步骤504、HSS/HLR向MME/SGSN/MSC发送认证凭证更新响应消息。在该响应消息中包含加密的认证凭证的标识KID、新的认证凭证。

步骤505、MME/SGSN/MSC通过eNB/RNC/BSS向UE转发认证凭证更新响应消息。该响应消息可以是单独的一条信令承载(如NAS消息)，也可以是包含在TAU/RAU/LAU response消息中。

步骤506、物联网UE收到认证凭证更新消息后，物联网设备通过机卡接口将加密的认证凭证和认证凭证的标识KID、新IMSI(可选)发送给UICC或eUICC。该UICC或eUICC上的公私钥处理模块使用私钥解密出新的认证凭证和认证凭证的标识KID，USIM应用使用该认证凭证更新之前存储的认证凭证，并将认证凭证的标识KID和新的认证凭证绑定存储。

需要说明的是，如果用户没有申请IMSI更新，那么更新的认证凭证中的根密钥K、认证凭证的标识KID与该UE原来的IMSI绑定存储；如果用户申请了IMSI更新，那么更新的认证凭证中的根密钥K、新IMIS与认证凭证的标识KID绑定存储。

步骤507、物联网UE发起detach(去附着)请求，和网络之间进行去附着的流程。

可选地，在去附着的原因中指明是更新认证凭证。此步骤也可以是HSS/HLR主动触发物联网UE发起去附着流程。

步骤508、物联网UE向网络发起附着流程，在attach request中需要携带认证凭证的标识KID，以便HSS/HLR能够识别该物联网UE使用是哪个认证凭证。物联网UE和网络之间完成附着流程后，物联网UE就使用更新的认证凭证接入了运营商的网络。

实施例三和实施例四解决了同一运营商内部的认证凭证更新，适用于物联网设备需要在同一运营商内部更新认证凭证的场景，比如用户为了安全，减少根密钥K泄露的后果要求更新根密钥。

实施例五

本实施例适用的场景是：跨运营商的网络侧主动更新认证凭证的场景，具体如图6所示。

与同一运营商网络的网络侧主动方式更新认证凭证的区别是：

步骤600，用户需向当前所在网络的运营商(如图6中的归属运营商)申请更新认证凭证，并且是更新为另一个运营商(如图6中的拜访运营商)网络的认证凭证。比如，用户可以打电话申请或者上运营商网站去申请。申请时需要说明更换到哪个运营商。获得归属运营商同意后，该更换运营商认证凭证申请将作为用户签约信息的一部分存储在签约数据库中；另外，用户还需要向拜访运营商去申请更新认证凭证，指明要将当前归属运营商的认证凭证更新为拜访运营商的认证凭证。比如，用户可以去拜访运营商的web门户上申请，填写上该用户物联网UE使用的UICC或eUICC的公钥，当前归属运营商的网络标识。

步骤604、归属运营商的HSS/HLR在接收到物联网UE的认证凭证更新请求后，需检查该用户的物联网UE是否有权限进行跨运营商的认证凭证更新。如果有权限，执行步骤605。

步骤605、归属运营商的HSS/HLR向拜访运营商的HSS/HLR发送认证凭证更新请求，该认证凭证更新请求中包含物联网UE中UICC或eUICC的公钥及当前归属运营商网络的设备标识。

步骤606、拜访运营商的HSS/HLR收到更新认证凭证请求后，检查该更新认证凭证请求是否合法(即用户是否已经对该公钥对应的物联网UE做了更新认证凭证申请)。如果合法，使用收到的公钥加密更新的认证凭证以及给该认证凭证分配一个密钥标识KID。将加密的认证凭证(包含根密钥K和IMSI)以及KID包含在认证凭证更新响应中发送给HSS。

步骤607、归属运营商的HSS/HLR收到认证凭证更新响应后，通过MME/SGSN/MSC转发给物联网UE。该认证凭证更新响应的承载方式同实施例三中的步骤406。

步骤609与实施例三中步骤407中不同的是，UICC或eUICC使用私钥解密后，需将收到的新认证凭证以及新认证凭证的标识KID绑定存储。

步骤610、物联网UE发起detach流程后离开归属运营商的网络。后续该UE可以使用更新的认证凭证接入到该认证凭证对应的运营商网络。

实施例六

本实施例适用的场景是：跨运营商的终端侧主动更新认证凭证。具体如图7所示。

本实施例与实施例五不同地方在于，认证凭证更新由用户通过物联网UE主动触发。该触发方式可以是用户申请后，直接在物联网设备上手动操作启动更新认证凭证的功能，使得物联网UE发起认证凭证更新请求。此方法不适用于用户不能到达现场操控设备的场景。

上述实施例五和实施例六中，归属HSS/HLR和拜访HSS/HLR之间的通信可以通过两个运营商网内的3GPP AAA proxy和PGW/GGSN来进行转发。

上述实施例五和实施例六解决了跨运营商的认证凭证更新，适用于物联网设备需要在不同运营商之间更新认证凭证的场景，比如用户为了选择费用更少的运营商要求更新根密钥。

在上述实施例三至实施例六中，为了实现物联网UE自动使用更新的认证凭证附着网络，可以让UICC或eUICC上的USIM应用能够对认证凭证做一个优先级排序，总是将最近更新的认证凭证排在最高优先级，并且总是选择优先级最高的认证凭证作为网络接入的认证根密钥。

网络侧主动认证凭证更新方案和终端侧主动认证凭证更新方案相比，由网络触发更新可以避免物联网UE遭受攻击后不停地向网络发送更新认证凭证请求，降低占用网络资源的风险。

实施例七

参见图8，图中示出了物联网设备的结构，物联网设备800包括：存储有认证凭证的可插拔卡或者不可插拔卡，其特征在于，所述物联网设备还包括：

第一发送模块801，用于向网络侧发送认证凭证更新请求，所述认证凭证更新请求至少包括：可插拔卡或者不可插拔卡产生的公钥；

第一接收模块802，用于接收网络发送的认证凭证更新响应，所述认证凭证更新响应至少包括：经过所述公钥加密的新的认证凭证和所述新的认证凭证的标识，其中，所述新的认证凭证和新的认证凭证的标识是网络侧根据所述认证凭证更新请求为所述物联网设备分配的；

解密模块803，用于通过所述可插拔卡或者不可插拔卡产生的私钥至少解密出新的认证凭证和新的认证凭证的标识；

更新模块804，用于通过所述新的认证凭证更新之前存储的认证凭证。

可选地，在本实施例中，所述物联网设备还包括：

第一存储模块，用于将所述新的认证凭证中更新的根密钥和新的认证凭证的标识绑定存储。

可选地，在本实施例中，如果用户申请了同时更新根密钥和签约用户标识，所述认证凭证更新响应中经过所述公钥加密的认证凭证至少包括：更新的根密钥和更新的签约用户标识，所述更新的根密钥和更新的签约用户标识是由网络侧为物联网设备分配的，并存储在物联网设备上的可插拔卡或者不可插拔卡上的；所述解密模块进一步用于：通过所述可插拔卡或者不可插拔卡产生的私钥解密出新的认证凭证中的更新的根密钥和更新的签约用户标识、以及新的认证凭证的标识；

所述物联网设备还包括：

第二存储模块，用于将所述新的认证凭证中更新的根密钥和更新的签约用户标识与新的认证凭证的标识绑定存储。

可选地，在本实施例中，所述第一发送模块包括：

接收单元，用于接收网络侧发送的认证凭证更新命令；

第一发送单元，用于根据所述认证凭证更新命令向网络侧发送认证凭证更新请求；

或者

计时单元，用于计算认证凭证的使用时间；

第二发送单元，用于当认证凭证的使用时间到达使用期限时，向网络侧发送认证凭证更新请求。

与现有技术相比，本发明的实施例不仅适用于可插拔的UICC，还适用于不可插拔的eUICC，而且不需要有专门的卡管理平台。本发明的实施例可避免运营商的认证凭证和用户签约信息(例如IMSI)被第三方托管，不需要运营商之间传递明文的认证凭证、用户签约信息(例如IMSI)以及OTA密钥，避免运营商的这些信息被其他运营商知道。本发明的实施例可以最大化的利用现有的信令消息来传递更新认证凭证相关的信息。即使现有的认证凭证已经被攻击者获知，现有的信令消息的完整性、机密性失效，由于新的认证凭证使用了UICC或eUICC的公钥进行加密保护，所以攻击者还是不能够获取新的认证凭证。而当UICC或eUICC使用新的认证凭证进行网络附着时，攻击者即使还有原来泄密的认证凭证，也不能获取使用新认证凭证进行保护的网络信息。

实施例八

参见图9，图中示出了一种网络设备，用于对物联网设备的认证凭证更新，所述物联网设备包括：存储有认证凭证的可插拔卡或者不可插拔卡，其特征在于，所述网络设备900包括：

第二接收模块901，用于接收所述物联网设备发送的认证凭证更新请求，所述认证凭证更新请求至少包括：可插拔卡或者不可插拔卡产生的公钥；

加密模块902，用于根据所述认证凭证更新请求为所述物联网设备至少分配新的认证凭证和新的认证凭证的标识，并通过所述公钥对所述新的认证凭证和所述新的认证凭证的标识进行加密；

第二发送模块903，用于向物联网设备发送认证凭证更新响应，所述认证凭证更新响应至少包括：经过所述公钥加密的新的认证凭证和所述新的认证凭证的标识。

可选地，在本实施例中，所述第二接收模块901还用于：接收归属HSS/HLR转发的所述物联网设备发送的认证凭证更新请求，所述认证凭证更新请求包括：可插拔卡或者不可插拔卡产生的公钥和当前归属运营商网络的标识；

所述加密模块902还用于：根据所述认证凭证更新请求为所述物联网设备分配包含由拜访运营商分配的属于拜访运营商的根密钥和签约用户标识的新的认证凭证和新的认证凭证的标识，并通过所述公钥对所述新的认证凭证和所述新的认证凭证的标识进行加密；

所述第二发送模块903还用于：通过归属HSS/HLR向物联网设备发送认证凭证更新响应，所述认证凭证更新响应包括：经过所述公钥加密的新的认证凭证和所述新的认证凭证的标识。

可选地，在本实施例中，所述网络设备还包括：

检查模块，用于检查所述物联网设备是否有权限进行认证凭证更新以及更新认证凭证时是只更新根密钥还是同时更新签约用户标识；若有权限只更新认证凭证中的根密钥且不同时更新签约用户标识，则触发所述加密模块根据所述认证凭证更新请求为所述物联网设备分配只包含更新的根密钥的更新的认证凭证和新的认证凭证的标识，并通过所述公钥对所述新的认证凭证和所述新的认证凭证的标识进行加密；若有权限更新认证凭证且同时更新签约用户标识，则触发所述加密模块根据所述认证凭证更新请求为所述物联网设备分配包含更新的根密钥和更新的签约用户标识的新的认证凭证、新的认证凭证的标识，并通过所述公钥对所述新的认证凭证和所述新的认证凭证的标识进行加密；

所述第二发送模块还用于向物联网设备发送经过所述公钥加密的包含更新的根密钥和更新的签约用户标识的新的认证凭证和所述新的认证凭证的标识。

与现有技术相比，本发明的实施例不仅适用于可插拔的UICC，还适用于不可插拔的eUICC，而且不需要有专门的卡管理平台。本发明的实施例可避免运营商的认证凭证和用户签约信息(例如IMSI)被第三方托管，不需要运营商之间传递明文的认证凭证、用户签约信息(例如IMSI)以及OTA密钥，避免运营商的这些信息被其他运营商知道。本发明的实施例可以最大化的利用现有的信令消息来传递更新认证凭证相关的信息。即使现有的认证凭证已经被攻击者获知，现有的信令消息的完整性、机密性失效，由于新的认证凭证使用了UICC或eUICC的公钥进行加密保护，所以攻击者还是不能够获取新的认证凭证。而当UICC或eUICC使用新的认证凭证进行网络附着时，攻击者即使还有原来泄密的认证凭证，也不能获取使用新认证凭证进行保护的网络信息。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一项或多项实施例中。

在本发明的各种实施例中，应理解，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定

另外，本文中术语“系统”和“网络”在本文中常可互换使用。

应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

在本申请所提供的实施例中，应理解，“与A 相应的B”表示B与A 相关联，根据A可以确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。

在本申请所提供的几个实施例中，应该理解到，所揭露方法和装置，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理包括，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述收发方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述的是本发明的优选实施方式，应当指出对于本技术领域的普通人员来说，在不脱离本发明所述的原理前提下还可以做出若干改进和润饰，这些改进和润饰也在本发明的保护范围内。