本申请涉及网络安全技术领域，尤其涉及一种运营商码号与账号的关联管理方法与系统。
背景技术
手机号码作为个人账号，具有唯一性、易记性、便利性等优势，在日常生活中广泛被使用，尤其是在社交领域、金融领域作为与个人账号绑定的移动端，与银行业务相关的个人手机银行服务，如：短信提醒、交易动态验证码、密码重置、重要信息推送等。由此可见，生活中的很多活动、服务都习惯性的依赖基于手机号码的移动终端。手机号码作为账号的服务一般是基于验证码的在线验证，流程如下：
步骤1：个人用户通过手机申请交易、密码重置、登录等服务。
步骤2：服务提供方向动态验证平台申请动态身份验证。
步骤3：动态验证平台生成动态校验码，推送给手机端和服务提供方。
步骤4：个人手机端提交验证数据，用于交易、密码重置、登录等服务验证。
如果因个人手机丢失导致更换手机号码，或者个人主动更换，则需要将与旧手机号码绑定的业务变更为与新的手机号码绑定。然而，因个人业务较多，或者个人疏忽拖沓，往往不能做到及时变更，甚至遗忘。然而，手机号码作为一种资源，在运营商的服务中，会被重复使用，也就是说，个人旧的手机号码被注销后，会间隔一段时间，被重新投放到市场中，如果不法分子拿到这样的手机号码，作为账号，在社交服务、金融服务等领域的移动端，进行账号密码重置，就能完全掌握账号和密码，从而可以进行盗取个人资产，损害他人利益。因此，基于手机号码的移动服务，在给大家带来便利的同时，也引入了潜在的风险。
另外，通过短信通道推送动态验证码，建立动态验证机制，该过程中数据是明文传输，容易被软件截获，也存在一定的安全隐患，即便能有效的解决机器冒充人的问题，但不能解决账号的安全使用问题。
技术实现要素：
本申请的目的在于提供一种运营商码号与账号的关联管理方法与系统，以保障数据安全。
为达到上述目的，本申请提供一种运营商码号与账号的关联管理方法，包括如下步骤：接收终端app应用发起的应用账号与运营商码号的绑定请求；经终端app应用向运营商码号的sim或esim发起获取网络电子身份标识的请求；接收终端app应用转发的运营商码号的sim或esim的第一网络电子身份标识；查询运营商码号、第一网络电子身份标识与应用账号是否绑定；若未绑定，则与运营商码号的sim或esim发起双向认证；若双向认证通过，则建立应用账号信息、终端app应用的服务身份标识、第一网络电子身份标识以及运营商码号的绑定关系；向终端app应用返回绑定成功信息。
如上的，其中，应用账号信息为应用账号的sha摘要。
如上的，其中，若双向认证通过，则将(e)sim的第一唯一标识加密且签名，通过数据短信发送给运营商码号持有实体；接收运营商码号持有实体对(e)sim的第一唯一标识的验证结果；若第一唯一标识验证通过，则建立应用账号信息、终端app应用的服务身份标识、第一网络电子身份标识以及运营商码号的绑定关系。
如上的，其中，若对第一唯一标识的验证通过，则接收终端app应用转发的对应用账号信息、终端app应用的服务身份标识、sim或esim的第二网络电子身份标识以及(e)sim的第二唯一标识进行加密和签名获得的第一密文和第一签名；验证第一签名，第一签名验证通过后，解密第一密文，获得应用账号信息、终端app应用的服务身份标识、sim或esim的第二网络电子身份标识以及(e)sim的第二唯一标识，校验第二网络电子身份标识与第一网络电子身份标识是否一致，(e)sim第二唯一标识与(e)sim第一唯一标识是否一致；若第二网络电子身份标识与第一网络电子身份标识一致，且(e)sim第二唯一标识与(e)sim第一唯一标识一致，则建立应用账号信息、终端app应用的服务身份标识、第一网络电子身份标识以及运营商码号的绑定关系。
如上的，其中，还包括如下步骤：响应于接收终端app应用发起的登陆请求，查询终端app应用的服务身份标识、应用账号与运营商码号是否绑定；若已经绑定，则与运营商码号的sim或esim发起双向认证；若双向认证通过，则验证从双向认证时获取的sim或esim的网络电子身份标识与绑定信息中的第一网络电子身份标识是否一致；若网络电子身份标识验证通过，则向终端app应用发送允许登陆信息。
如上的，其中，在登陆状态下，还包括：接收终端app应用发起的变更请求，变更请求包括应用账号信息和与应用账号信息绑定的运营商码号；与sim或esim发起双向认证，双向认证过程中生成会话密钥；若双向认证通过，则接收终端app应用转发的用会话密钥对变更请求所需的信息的加密和签名，获得第二密文和第二签名；用会话密钥验证第二签名，第二签名验证通过后，解密第二密文，获得变更请求所需的信息，并处理变更请求；向终端app应用返回变更成功信息。
如上的，其中，若第二网络电子身份标识与第一网络电子身份标识不一致，并且(e)sim第二唯一标识与(e)sim第一唯一标识一致，则解绑与运营商码号绑定的所有应用账号。
本申请还提供一种运营商码号与账号的关联管理系统，包括：安全账号平台，用于执行权利要求1-7的关联管理方法；运营商码号的sim或esim，用于对绑定所需信息进行加密和签名并发送加密和签名结果；终端app应用，用于向安全账号平台发起账号绑定请求转发安全账号平台与sim或esim的传输数据。
如上的，其中，安全账号平台记录运营商码号与多个应用账号之间的绑定信息。
如上的，其中，安全账号平台中的应用账号信息为应用账号的sha摘要。本申请实现的有益效果如下：
本申请利用安全账号平台对运营商码号与所有终端应用的关联关系进行统一管理，并在不依赖动态验证码机制的前提下，通过安全账号平台安全地绑定用户的账号与运营商码号，实现了不需要输入密码或者验证码就能安全登陆，能自动识别运营商码号注销后重新使用的情景，有效避免此情景中的安全风险，只有在实现安全绑定及解绑的基础上，服务端才能有效的依赖动态验证机制，验证请求的安全性。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域技术人员来讲，还可以根据这些附图获得其他的附图。
图1为根据本申请实施例的运营商码号与账号的关联管理系统的结构图；
图2为根据本申请实施例的手机号与账号的绑定流程图；
图3为根据本申请实施例的登陆的流程图；
图4为根据本申请实施例的变更请求的流程图。
具体实施方式
下面结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
实施例一
图1为根据本申请实施例的运营商码号与账号的关联管理系统的结构图。如图1所示，该关联管理系统包括安全账号平台110、终端app应用120、运营商码号的持有实体sim或esim130(后续称作(e)sim)。安全账号平台110分别与终端app应用120和(e)sim130通信连接，终端app应用120与(e)sim130通信连接。终端app应用120与其对应的服务提供方之间存在交互，属于现有技术，因此，本申请中省略了终端app应用120与其服务提供方之间的交互描述。
作为一个实施例，本申请的关联管理系统适用于智能移动终端(如手机、pad、平板电脑等)上的应用程序与智能移动终端上的(e)sim(如运营商下发的手机号的(e)sim)的关联管理，也适用于物联网设备上的应用程序与物联网设备上的(e)sim(如运营商下发的物联网码号的(e)sim)的关联管理。
实施例二
本申请还包括与实施例一的关联管理系统对应的关联管理方法。本实施例中的运营商码号以智能移动终端的应用程序与智能移动终端上的手机号为例，该关联管理系统可实现手机号与账号的绑定以及在终端app应用中利用该手机号进行相关的业务。
图2为根据本申请实施例的手机号与账号的绑定流程图。手机号可以与多个终端app应用的应用账号进行绑定，绑定信息的记录都会存储到安全账号平台中，这里的应用账号信息只是账号的sha摘要，不涉及密码、交易等机密数据的存储。
如图2所示，绑定流程包括如下步骤：
1.终端app应用向安全账号平台发起手机号与应用账号的绑定请求，绑定请求中包括手机号number，安全账号平台将收到手机号number。
2.安全账号平台给终端app应用发送获取eid(electronicidentity，网络电子身份标识)的请求。
3.终端app应用发送获取eid的指令给(e)sim。
4.(e)sim将eid返回给终端app应用，以验证(e)sim实体的合法性。
5.终端app应用将获得的eid返回给安全账号平台。安全账号平台通过eid、手机号和应用账号信息查询是否绑定。如已绑定，则提示用户，流程退出。否则，流程继续。
6.安全账号平台向终端app应用发送获取证书请求，获取证书请求包括安全账号平台的证书cert_sp。
7.终端app应用向(e)sim发送证书获取指令getcert(cert_sp)，该指令包括安全账号平台的证书cert_sp。(e)sim用证书签发中心的根证书cert_ci验证安全账号平台的证书cert_sp是否合法有效。如果验证失败，返回错误信息，流程结束。否则继续流程。
8.验证通过后，(e)sim向终端app应用返回(e)sim的证书cert_sim和16字节随机数r1以及(e)sim的厂商证书cert_eum，并用(e)sim的私钥对上述数据r1||cert_eum||cert_sim计算签名signature。
9.终端app应用将(e)sim返回的数据发给安全账号平台。
10.安全账号平台用证书签发中心的根证书cert_ci验证cert_eum，cert_sim的合法性和有效性，提取cert_sim的公钥pk_sim和eid，验证signatures和eid是否正确。如果正确，则记录随机数r1，否则返回错误信息，结束流程。
若正确，则安全账号平台生成临时公私钥(ot_pk,ot_sk)和随机数r2，用ecka算法对ot_sk和(e)sim公钥pk_sim生成共享数据shs，用shs+r1+r2分散出会话密钥s。
11.安全账号平台用ot_sk对ot_pk和随机数r2签名得到signature(r2,ot_pk)，将得到的数据r2||ot_pk||signature(r2,ot_pk)发送给终端app应用，申请协商密钥。
12.终端app应用将密钥协商数据发送给(e)sim。(e)sim用ot_pk验证签名signature(r2,ot_pk)。若验证错误，返回错误信息。验证成功后，用ecka算法对(e)sim的私钥sk_sim和ot_pk生成共享数据shs，用shs+r1+r2分散出会话密钥s。(e)sim用会话密钥s对(e)sim产生的随机数r3计算签名，返回r3和签名给终端app应用。
13.终端app应用将返回的结果发送给安全账号平台校验。若签名正确，则密钥协商成功，否则，流程退出。
14.若密钥协商成功，则安全账号平台用会话密钥s作为kic(keyandalgorithmidentifierforciphering，加密密钥)、kid(keyandalgorithmidentifierforcryptographicchecksum，签名密钥)，将(e)sim的第一唯一标识加密且签名，通过数据短信发送给手机号持有实体(e)sim。
15.手机号持有实体(e)sim校验签名，解密出(e)sim的第一唯一标识进行验证，并返回执行结果，确保申请绑定操作的是(e)sim实际操作的，防止其他装置冒充、伪造进行操作。若成功，则流程继续，否则，流程退出。
16.提示终端app应用继续执行绑定。
17.终端app应用将需要绑定的应用账号user计算出摘要sha(user)和服务提供方的服务身份标识serviceid等用户信息，交给(e)sim进行加密和签名。serviceid为银行或者微信等服务提供方的唯一标识。
18.(e)sim使用会话密钥s对(sha(user)||eid||serviceid||(e)sim的第二唯一标识)进行加密并签名，返回给终端app应用。
19.终端app应用将密文和签名提交给安全账号平台，安全账号平台用会话密钥s验证签名。如果签名错误，则绑定失败，否则解密出账号摘要sha(user)、eid、serviceid和(e)sim的第二唯一标识，校验该eid与获取的eid是否一致。校验(e)sim的第二唯一标识是否与(e)sim的第一唯一标识一致。如eid或手机号不一致，则绑定失败。否则，建立sha(user)与手机号number、eid和serviceid的绑定关系，完成绑定，如：{"eid","serviceid","number","sha(user)"}。
作为一个实施例，本流程中(e)sim的唯一标识可以是手机号，也可以是其他内容，如：eid，iccid等。
一个eid可以对应多个手机号，一个手机号可以与多个应用账号绑定，但一个应用账号只能与一个serviceid匹配，一个手机号也只能与一个serviceid匹配。因账号数据是唯一的，且eid是唯一的，一旦手机号相同，eid不同，说明手机号被注销过，此时可销毁该手机号的绑定数据，并要求用户重新绑定，因此，不存在重新启用码号后的安全风险。
绑定信息中必须包含(e)sim的eid，用来标识当前执行绑定操作的实体，因eid是唯一的，即便手机号码被注销后重新被使用，通过识别绑定数据中的eid，就能得知该手机号码的持有实体是否是执行绑定的实体。
现有技术中，绑定过程是在用户通过账号登陆后，自动识别并发起的，通过(e)sim实体与终端app本地交互实现，但这并不能证明持有手机号的实体与(e)sim实体是相同的，因此，本申请中安全账号平台将唯一标识通过数据短信加密发送给该手机号的持有实体，并使手机号参与后续账号信息数据的安全上报，因数据短信是安全的，所以这样做就能证明需要绑定的手机号即为当前本地(e)sim实体。
当用户使用手机号在终端app登陆时，首先需要用手机号和serviceid在安全平台查询是否存在绑定的账号，如果没有找到账号，则需要提示用户进行绑定，进入账号绑定流程。如果已有绑定账号，则进入登陆流程。图3为根据本申请实施例的登陆的流程图。
如图3所示，登陆流程包括如下步骤：
1.用户在终端app应用上用手机号作为账号，向安全账号平台发起登陆请求，登陆请求包括手机号和serviceid。
2.安全账号平台查询serviceid、应用账号与手机号是否绑定。如果没有绑定，则提示用户进行绑定，否则流程继续。
3.安全账号平台向终端app应用发送获取证书的请求，请求中带有安全平台的证书cert_sp。
4.终端app应用收到请求后，向(e)sim发送获取证书指令，(e)sim用证书签发中心的根证书cert_ci验证cert_sp的合法性。验证通过后，生成随机数r1，用(e)sim的私钥sk_sim对(r1||cert_eum||cert_sim)计算签名得到signature。
5.返回r1||cert_eum||cert_sim数据以及signature给终端app应用。
6.终端app应用转发返回的数据给安全账号平台。安全账号平台用证书签发中心的根证书cert_ci验证cert_eum证书是否合法有效，然后从cert_eum中提取公钥pk_eum，并用此公钥验证cert_sim证书是否合法，从cert_sim中提取公钥pk_sim，验证签名signature是否正确。在此验证过程中若出现错误，均返回登陆失败。验证通过后，从cert_sim证书中提取eid，与安全账号平台中查询到的绑定数据中的eid进行校验，因eid、serviceid和手机号三者就能确定账号的唯一性，而通过(e)sim获取的数据是真实唯一的，所以在eid验证通过后，就能确定申请登陆的实体为合法绑定的实体。
7.若eid校验成功，则允许用户登陆。
本申请无需输入任何验证码，也不需要密码，借助安全平台的绑定机制，只需验证登陆实体的合法性，就能实现安全登陆。
在安全登陆的前提下，用户可以主动申请变更绑定的(相同esim的)手机号或者解除绑定的应用账号。图4以变更已绑定的手机号或者解绑为例示出了变更请求的流程图。包括如下步骤：
1.终端app应用向安全账号平台发起变更手机号或者解绑应用账号的请求。
2.安全账号平台发送获取证书请求给终端app应用，获取证书请求中包括安全账号平台的证书cert_sp。
3.终端app应用向(e)sim发送获取证书指令。(e)sim用证书签发中心的根证书cert_ci验证cert_sp的合法性。若验证错误，流程退出。否则，流程继续。
4.(e)sim生成随机数r1,使用(e)sim的私钥sk_sim对(r1||cert_eum||cert_sim)计算签名得到signature，将明文r1||cert_eum||cert_sim和signature一起发送给终端app应用。
5.将r1||cert_eum||cert_sim和signature转发给安全账号平台，安全账号平台用证书签发中心的根证书cert_ci验证cert_eum，cert_sim的合法性和有效性，提取cert_sim的公钥pk_sim和eid，验证signature和eid是否正确。如果正确，则记录随机数r1，否则返回错误信息，结束流程。如果正确，则安全账号平台生成临时公私钥(ot_pk,ot_sk)和随机数r2，用ecka算法对ot_sk和(e)sim公钥pk_sim生成共享数据shs，用shs+r1+r2分散出会话密钥s。
6.安全账号平台用ot_sk对ot_pk和随机数r2签名得到signature(r2,ot_pk)，将得到的数据r2||ot_pk||signature(r2,ot_pk)发送给终端app，申请协商密钥。
7.(e)sim用ot_pk验证签名signature(r2,ot_pk)。若验证错误，则返回错误信息，验证成功后，用ecka算法对(e)sim的私钥sk_sim和ot_pk生成共享数据shs，用shs+r1+r2分散出会话密钥s。
8.(e)sim用会话密钥s对随机数r3计算签名，返回r3和签名给终端app应用。
9.终端app应用将返回的结果r3和签名发送给安全账号平台。用会话密钥s验证签名是否正确。若验证失败，流程退出，否则流程继续。
10.返回协商成功结果给终端app应用。
11.终端app应用将新的手机号码或者要解绑的应用账号交给(e)sim用会话密钥s加密并计算签名。
12.(e)sim返回密文和签名给终端app应用。
13.终端app应用将密文和签名发给安全账号平台。安全账号平台用会话密钥验证签名是否正确。若错误，则流程退出，否则，解密出要变更的手机号或者要解绑的应用账号，至此，安全账号平台可将原有手机号码替换成新的手机号，或者将需要解绑的应用账号对应的绑定信息删除。
在登陆流程中，如果(e)sim的eid与绑定的信息中的eid不同，则无法登陆，因此在变更流程中无需校验eid。
在登陆过程中，为了区别人与机器程序，可以同时使用动态验证码的验证机制，防止恶意攻击。
本申请实现的有益效果如下：
本申请利用安全账号平台对手机号码与所有终端应用的关联关系进行统一管理，并在不依赖动态验证码机制的前提下，通过安全账号平台安全地绑定用户的账号与手机号码，实现了不需要输入密码或者验证码就能安全登陆，能自动识别手机号注销后重新使用的情形，有效避免此情景中的安全风险，只有在实现安全绑定及解绑的基础上，服务端才能有效的依赖动态验证机制，验证请求的安全性。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。