CN113824566B - 证书认证方法、码号下载方法、装置、服务器及存储介质 - Google Patents

证书认证方法、码号下载方法、装置、服务器及存储介质 Download PDF

Info

Publication number
CN113824566B
CN113824566B CN202111214327.5A CN202111214327A CN113824566B CN 113824566 B CN113824566 B CN 113824566B CN 202111214327 A CN202111214327 A CN 202111214327A CN 113824566 B CN113824566 B CN 113824566B
Authority
CN
China
Prior art keywords
center
certificate
target
trusted
public key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202111214327.5A
Other languages
English (en)
Other versions
CN113824566A (zh
Inventor
钱京
何碧波
崔可
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hengbao Co Ltd
Original Assignee
Hengbao Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hengbao Co Ltd filed Critical Hengbao Co Ltd
Priority to CN202111214327.5A priority Critical patent/CN113824566B/zh
Publication of CN113824566A publication Critical patent/CN113824566A/zh
Application granted granted Critical
Publication of CN113824566B publication Critical patent/CN113824566B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请提供一种证书认证方法、码号下载方法、装置、服务器及存储介质，方法包括：服务端接收智能卡的待认证证书；若待认证证书不是第一目标CA中心签发的证书，从上级可信CA中心处获取待认证证书所属的第二目标CA中心的公钥证书；第一目标CA中心为已向服务端签发证书的CA中心；上级可信CA中心为第一目标CA中心中的任一CA中心；上级可信CA中心与第二目标CA中心位于同一可信环境中；使用第二目标CA中心的公钥证书对待认证证书进行认证。上述方案解决了现有技术中，如果服务端没有存储与智能卡端对应的证书则无法实现证书认证的问题。此外，当所有合法的CA中心都位于该可信环境中时，上述方案可以实现对于所有证书的认证。

Description

证书认证方法、码号下载方法、装置、服务器及存储介质
技术领域
本申请涉及智能卡技术领域，具体而言，涉及一种证书认证方法、码号下载方法、装置、服务器及存储介质。
背景技术
随着智能卡的普及，目前许多智能卡(如eSIM(Embedded Subscriber IdentityModule，嵌入式客户识别模块)卡等)被广泛应用到各种穿戴、物联网终端设备上。这类产品上的智能卡往往能支持运营商码号的下载、安装、激活和去激活，从一定程度上解决了运营商码号资源管理浪费的问题。
参考GSMA(Global System for Mobile Communications Association，全球移动通讯***协会)推广的现有运营商码号下载技术中，运用了证书认证机制，在服务端与智能卡端进行双向认证，来确保下载过程和数据的安全，服务端和智能卡端各使用的证书都必须是同一CA(Certification Authority，数字证书认证***)证书签发中心签发的。同时，智能卡端和服务端都可以支持多套证书管理，即智能卡端和服务端中各自存储和管理不同的多个CA中心签发的证书，并能根据实际情况适配合适的证书进行双向认证并完成码号下载。
但是，智能卡作为存储资源有限的终端芯片，能存储的证书是有限的，而现有方案中，智能卡端只能和服务端交互认证同时在智能卡端和服务端都存储有对应同一CA中心签发的证书，无法实现对于所有证书的认证。
发明内容
本申请实施例的目的在于提供一种证书认证方法、码号下载方法、装置、服务器及存储介质，用以解决现有技术中存在的，如果服务端内没有存储与智能卡对应同一CA中心签发的证书，则无法实现证书认证的问题。
本申请实施例提供了一种证书认证方法，应用于服务端，所述方法包括：接收智能卡的待认证证书；若所述待认证证书不是第一目标CA中心签发的证书，从上级可信CA中心处，获取所述待认证证书所属的第二目标CA中心的公钥证书；所述第一目标CA中心为已向所述服务端签发证书的CA中心；所述上级可信CA中心为所述第一目标CA中心中的任一CA中心；所述上级可信CA中心与所述第二目标CA中心位于同一可信环境中；使用所述第二目标CA中心的公钥证书对所述待认证证书进行认证。
在上述实现过程中，通过预先构建一个CA中心之间的可信环境，然后在服务端本地没有保存与智能卡的待认证证书相应的证书时，服务端即可从该可信环境中，获取该智能卡存储的认证证书所属CA中心的公钥证书，从而实现对于该智能卡的证书认证。这样，就解决了现有技术中存在的，如果服务端内没有存储与智能卡端对应的同一CA中心签发的证书，则无法实现证书认证的问题。此外，对于移动终端用户而言，其希望智能卡能接入所有运营商码号服务器，从而下载所有运营商码号。而采用本申请实施例的方案，当所有合法的CA中心都一起加入该可信环境中时，智能卡与服务端就都可以摆脱需要自身存储多种证书的限制，通过上述实现过程，即可以实现对于所有证书的认证，从而满足用户需求。
进一步地，所述可信环境为由可信的CA中心构成的区块链；从上级可信CA中心处，获取所述待认证证书所属的第二目标CA中心的公钥证书时，使用所述第二目标CA中心的公钥证书对所述待认证证书进行认证之前，所述方法还包括：从所述上级可信CA中心处，获取所述区块链的链路逻辑信息和所述第二目标CA中心的可信签名；所述链路逻辑信息包括所述区块链中所具有的各CA中心的连接关系；采用第三目标CA中心的公钥对所述第二目标CA中心的可信签名进行验证；所述第三目标CA中心为所述区块链中对所述第二目标CA中心进行签名的CA中心；确定验证通过。
在上述实现过程中，通过将CA中心构成区块链，基于区块链技术，实现去中心化的CA中心可信环境管理。同时通过区块链的链路逻辑信息，实现对于待认证证书对应的第二目标CA中心的可信验证，从而进一步保证获取到的公钥证书的安全性。此外，由于区块链的链路逻辑信息包括所述区块链中所具有的各CA中心的连接关系，以及各所述CA中心的公钥和可信签名，而公钥本身是公开的，不存在安全风险。
进一步地，在采用第三目标CA中心的公钥对所述第二目标CA中心的可信签名进行验证之前，所述方法还包括：根据所述第二目标CA中心的唯一中心标识，在所述链路逻辑信息中，确定出所述第二目标CA中心的位置；根据所述区块链中所具有的各CA中心的连接关系，以及预设的签名规则，确定出对所述第二目标CA中心进行签名的第三目标CA中心。
在上述实现过程中，基于第二目标CA中心的唯一中心标识即可在链路逻辑信息中快速确定出第二目标CA中心的位置，进而可以快速确定出对第二目标CA中心进行签名的第三目标CA中心，从而保证了对于第二目标CA中心的可信验证的正常进行。此外，由于唯一中心标识也并非CA中心的涉密数据，因此本申请的方案也不存在安全风险。
进一步地，所述签名规则为，所述区块链中的前一CA中心对后一CA中心进行签名。
在上述实现方式中，通过采用区块链中的前一CA中心对后一CA中心进行签名，这就使得新的CA中心在加入区块链中时，得以按照固定规则不断实现交替签名，从而相比于采用固定的一个CA中心来对新加入的CA中心签名的方式而言，CA中心的签名被破解的概率得以降低，提高区块链中各CA中的安全性。
进一步地，所述可信签名为：对CA中心中的所有公钥证书的唯一证书标识进行的签名。
应理解，在实际应用过程中，一个CA中心内可能管理有多个公钥证书。通过对CA中心中的所有公钥证书的唯一证书标识进行的签名，这就使得在请求该CA中心内的任一公钥证书时，都可以通过签名验证实现对于该证书的可信验证。此外，由于公钥证书本身是可公开的，其唯一证书标识也并非CA中心的涉密数据，因此本申请的方案也不存在安全风险。
本申请实施例还提供了一种码号下载方法，应用于服务端，包括：在根据前述证书认证方法认证通过后，按照所述公钥证书的体系生成临时公私钥对；使用所述临时公私钥对中的临时私钥与所述待认证证书中的公钥协商生成会话密钥；采用所述会话密钥对码号数据进行加密并发送。
通过上述实现过程，服务端通过按照第二目标CA中心的公钥证书的体系生成临时公私钥对，这就使得生成的临时公私钥对可以适用于智能卡的待认证证书，从而可以保证后续码号数据的正常加密传输与识别，保证了码号数据下载过程的安全性。
本申请实施例还提供了一种证书认证装置，应用于服务端，包括：接收模块、获取模块以及认证模块；所述接收模块，用于接收智能卡的待认证证书；所述获取模块，用于若所述待认证证书不是第一目标CA中心签发的证书，从上级可信CA中心处，获取所述待认证证书所属的第二目标CA中心的公钥证书；所述第一目标CA中心为已向所述服务端签发证书的CA中心；所述上级可信CA中心为所述第一目标CA中心中的任一CA中心；所述上级可信CA中心与所述第二目标CA中心位于同一可信环境中；所述认证模块，用于使用所述第二目标CA中心的公钥证书对所述待认证证书进行认证。
本申请实施例还提供了一种码号下载装置，应用于服务端，包括：证书认证模块、生成模块和加密模块；所述证书认证模块，用于根据上述证书认证方法进行智能卡的待认证证书的认证；所述生成模块，用于在认证通过后，按照所述公钥证书的体系生成临时公私钥对；以及用于使用所述临时公私钥对中的临时私钥与所述待认证证书中的公钥协商生成会话密钥；所述加密模块，用于采用所述会话密钥对码号数据进行加密并发送。
本申请实施例还提供了一种服务器，包括处理器、存储器及通信总线；所述通信总线用于实现处理器和存储器之间的连接通信；所述处理器用于执行存储器中存储的一个或者多个程序，以实现上述任一种的证书认证方法，或实现上述码号下载方法。
本申请实施例中还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述任一种的证书认证方法，或实现上述码号下载方法。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1为本申请实施例提供的一种证书认证方法的流程示意图；
图2为本申请实施例提供的一种CA中心区块链的示意图；
图3为本申请实施例提供的一种码号下载方法的流程示意图；
图4为本申请实施例提供的一种具体的从证书认证到码号下载的流程示意图；
图5为本申请实施例提供的一种证书认证装置的结构示意图；
图6为本申请实施例提供的一种码号下载装置的结构示意图；
图7为本申请实施例提供的一种服务器的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。
实施例一：
为了解决现有技术中存在的，如果服务端内没有存储与智能卡端对应的同一CA中心签发的证书，则无法实现证书认证的问题，本申请实施例中提供了一种证书认证方法。可以参见图1所示，图1为本申请实施例中提供的证书认证方法的流程示意图，包括：
S101：接收智能卡的待认证证书。
需要说明的是，在执行本申请实施例所提供的方案之前，本申请需要预先构建各CA中心之间的可信环境。
所谓可信环境，即是构建出一个CA中心之间相互信任，且具有较高安全可信的各CA中心之间可相互网络连接的环境。
在本申请实施例中，在构建可信环境时，可以由工程师等人员进行线下核查认证，确保需加入可信环境的CA中心是具有实际安全主体的可信CA中心。此外，在可信环境中，各CA中心之间通过专用的安全网络实现网络连接，并可以为每一个CA中心在可信环境中配置一个独立的网络地址，以保证网络通信安全。通过以上两方面的措施，即可有效避免恶意制造假冒的CA中心加入到该可信环境中。
在本申请实施例中，该可信环境可以但不限于采用区块链的形式构建得到。
示例性的，参见图2所示，在本申请实施例中可以按照图2所示的区块链形式，构建出由可信的CA中心构成的区块链。
在该区块链中，每个节点的实体即为每个CA证书中的证书服务器，而为了便于管理，在本示例中，以标识的方式进行区块链的管理。
以图2所示的情况为例，区块链中的每个节点具有一个唯一中心标识，而节点下的每一个根公钥证书(以下简称公钥证书)，也具有一个唯一证书标识(应理解，节点表征的是CA中心，而一个CA中心，其内通常管理有多个用于签发证书的根公钥证书，在本申请实施例中，可以为每一个公钥证书分配一个唯一证书标识)。
这里需要注意的是，在本申请实施例的一种实现方式中，不同节点下的公钥证书，可以具有相同的唯一证书标识，但是同一节点下的不同公钥证书应当具有不同的唯一证书标识。此外，在本申请实施例的另一种实现方式中，也可以设定所有节点下的所有公钥证书都具有不同的唯一证书标识，从而便于管理。
应理解，在每个CA中心中，具有一个用于链表管理的非对称算法公私钥对，该非对称算法公私钥对中的公钥是公开的，私钥是不公开的，且该公钥是独立于CA中心的各公钥证书之外的，因此可以采用该公钥来实现CA中心的唯一中心标识，比如可以计算该公钥的HASH(哈希)值，以该公钥的HASH值来作为所属CA中心的唯一中心标识。
而对于公钥证书的唯一证书标识，则可以采用该公钥证书中的公钥来实现该公钥证书的唯一证书标识，比如可以计算该公钥证书中的公钥的HASH值，以该公钥的HASH值来作为该公钥证书的唯一证书标识。
应理解，在本申请实施例中，也可以通过预先设定好的编码规范或者标识生成规则来为各CA中心分配唯一中心标识，或为各公钥证书分配唯一证书标识。
这样，整个区块链是以公钥或公钥证书的唯一信息(即CA中心的唯一中心标识和公钥证书的唯一证书标识)来标识，数据量小，方便认证核查。且从数据安全角度考虑，由于公钥本身是公开的，也不存在安全风险。
而考虑到服务端在使用可信环境进行证书验签过程中，还存在服务端与可信环境之间的数据交互，那么为了保证服务端获取到的数据的可信与安全，在本申请实施例中，可信环境中的各CA证书之间可以按照预设的签名规则进行签名，得到可信签名。从而在向服务端发送数据时，还一并发送该可信签名，从而使得服务端得以通过验证可信签名的方式，通过判断可信签名是否能够通过验签，从而确定本次收到的数据的可信与否。
在本申请实施例中，签名规则可以但不限于是，可信环境中的某一或某些特定CA中心对另一CA中心进行签名。
以上述图2所示的区块链为例，签名规则可以是，区块链中的前一CA中心对后一CA中心进行签名，或者可以是，区块链中的第一个CA中心对其他CA中心进行签名。应理解，以上仅为本申请实施例中示例出的两种可行签名规则，但不作为对本申请实施例方案的限制。
在本申请实施例中，为保证后续的验签效果可以覆盖CA中心的每一个公钥证书，在本申请实施例中，可以对需签名的CA中心的所有公钥证书的唯一证书标识进行的签名，从而得到可信签名。
应理解，在每个CA中心中，都各自维护有不同的用于节点添加、删除和废止等操作的非对称算法密钥对，在本申请是实施例中，可以采用该非对称算法密钥对中的私钥来对需签名的CA中心进行签名。
在本申请实施例中，在对需签名的CA中心的所有公钥证书的唯一证书标识进行的签名时，可以将该需签名的CA中心的所有公钥证书的唯一证书标识进行累积或拼接，得到一个标识数据，然后对该标识数据进行签名。
在构建好可信环境后，即可采用本申请实施例的方案进行证书认证。
应理解，本申请实施例所提供的证书认证方案应用于服务端，如码号服务器等设备上。而在实际应用过程中，智能卡(如SIM(Subscriber Identity Module，客户识别模块)卡、eSIM卡(Embedded-SIM，嵌入式SIM)卡等)通常是设置在终端等电子设备上的，其需要通过终端实现与服务端的连接，从而将智能卡的待认证证书发送至服务端。
S102：若待认证证书不是第一目标CA中心签发的证书，从上级可信CA中心处，获取待认证证书所属的第二目标CA中心的公钥证书。
需要说明的是，上述第一目标CA中心是指已向该服务端签发过证书的CA中心。而上级可信CA中心为第一目标CA中心中的任一CA中心。而第二目标CA中心则是签发该待认证证书的CA中心。在本申请实施例中，上级可信CA中心应当与第二目标CA中心位于同一可信环境中，否则无法执行本申请实施例的方案。
在本申请实施例中，服务端在接收到智能卡的待认证证书后，首先判断本地是否存储有与该待认证证书相对应的公钥证书(或者判断待认证证书不是第一目标CA中心签发的证书，两者达到的效果是一致的)。
若本地存储有与该待认证证书相对应的公钥证书(待认证证书是第一目标CA中心签发的证书)，那么只需按照现有方式进行认证即可。
但是，若本地未存储有与该待认证证书相对应的公钥证书(待认证证书不是第一目标CA中心签发的证书)，那么服务端目前并不能进行认证，此时即需要从可信环境中获取与该待认证证书所属的第二目标CA中心的相应公钥证书。
而为了保证安全性，在本申请实施例中，服务端通过上级可信CA中心接入可信环境中。由于上级可信CA中心是已向该服务端签发过证书的CA中心，因此两者之间的建立有信任关系，数据交互更为可信。
在本申请实施例中，为了从上级可信CA中心处，获取待认证证书所属的第二目标CA中心的公钥证书，服务端可以对待认证证书进行解析，从而识别得到第二目标CA中心的唯一中心标识以及该待认证证书的对应标识。然后，可以将第二目标CA中心的唯一中心标识以及该待认证证书的对应标识携带在请求中发送给上级可信CA中心，从而转发到第二目标CA中心。第二目标CA中心即可根据该待认证证书的对应标识，将相应的公钥证书返回给该上级可信CA中心，进而给到该服务端。
而为了保证认证过程的安全性，防止使用到假冒的公钥证书，在返回相应的公钥证书的同时，还可以一并返回可信环境的链路逻辑信息以及第二目标CA中心的可信签名，从而采用第三目标CA中心的公钥对第二目标CA中心的可信签名进行验证，当验证通过后，才执行后续步骤S103。若不通过，则认为接收到的公钥证书不可信，可以结束认证，返回认证失败信息。
需要说明的是，上段中所述的第三目标CA中心是指可信环境中对第二目标CA中心进行签名的CA中心。上段中所述的链路逻辑信息包括可信环境中的各CA中心的连接关系。
在本申请实施例中，可以根据解析出的第二目标CA中心的唯一中心标识，在链路逻辑信息中，确定出第二目标CA中心的位置。进而根据链路逻辑信息包括可信环境中的各CA中心的连接关系，以及构建可信环境时的签名规则，确定出对第二目标CA中心进行签名的第三目标CA中心。
在本申请实施例中，链路逻辑信息还可以包括各CA中心中用于进行可信签名验证的公钥。此时，通过构建可信环境时的签名规则以及链路逻辑信息中确定出第三目标CA中心后，即可确定出用于对第二目标CA中心的可信签名进行验证的公钥。
此外，链路逻辑信息中也可以不携带各CA中心中用于进行可信签名验证的公钥。此时，通过构建可信环境时的签名规则以及链路逻辑信息中确定出第三目标CA中心后，可以通过上级可信CA中心获取到第三目标CA中心用于进行可信签名验证的公钥。
S103：使用第二目标CA中心的公钥证书对待认证证书进行认证。
使用公钥证书对待认证证书进行认证的过程可以采用现有的通用技术实现，在此不再展开说明。
在按照前述证书认证方法对智能卡的待认证证书认证通过后，还可以参见图3所示，可以按照图3所示的码号下载方法实现码号数据的下载。
该码号下载方法包括：
S301：按照第二目标CA中心的公钥证书的体系生成临时公私钥对。
需要说明的是，由于智能卡的待认证证书是第二目标CA中心签发的，那么为了可以与待认证证书一起完成后续加密解密过程，需要按照第二目标CA中心的公钥证书的体系生成临时公私钥对，以保证后续流程得以正常进行。
S302：使用临时公私钥对中的临时私钥与待认证证书中的公钥协商生成会话密钥。
S303：采用会话密钥对码号数据进行加密并发送。
在本申请实施例中，在生成会话密钥后，可以采用该会话密钥对profile(即码号数据)进行分块加密处理，将加密好的profile密文发送给智能卡。
需要注意的是，为了保证profile下载过程的安全性，在将加密好的profile密文发送给智能卡之前，还可以采用该会话密钥对智能卡的唯一标识(比如eID(ElectronicIdentity，公民网络电子身份标识))计算签名，得到SIGN_DP。将临时公私钥对中的临时公钥和该SIGN_DP返回给智能卡。
智能卡可以使用该临时公钥和自身具有的待认证证书中的私钥协商得到该会话密钥，进而通过该会话密钥对自身的唯一标识计算签名并验证SIGN_DP是否正确。如果正确，则可以返回验证通过消息，从而让服务端下发加密好的profile密文。否则，流程结束。
应理解，上述码号下载方法与证书认证方法均应用于服务端。对于大多数情况而言，实现码号数据下载的服务器与实现证书认证的服务器是一个，因此本申请实施例中所提供的证书认证方法与码号下载方法可以被同一个执行主体所实现。但是，某些情况下，实现码号数据下载的服务器与实现证书认证的服务器是不同服务器，那么此时本申请实施例中所提供的两种方法则需要分别在这两种服务器上实现。
本申请实施例所提供的证书认证方法和码号下载方法，通过预先构建一个CA中心之间的可信环境，然后在服务端本地没有保存与智能卡的待认证证书对应的同一CA中心签发的证书时，服务端即可从该可信环境中，获取该智能卡的待认证证书所属CA中心的公钥证书，从而实现对于该智能卡的待认证证书。这样，就解决了现有技术中存在的，如果服务端内没有存储与智能卡端对应的同一CA中心签发的证书，则无法实现证书认证的问题。此外，对于移动终端用户而言，其希望智能卡能接入所有运营商码号服务器，从而下载所有运营商码号。而采用本申请实施例的方案，当所有合法的CA中心都一起加入该可信环境中时，智能卡与服务端就都可以摆脱需要自身存储多种证书的限制，通过上述实现过程，即可以实现对于所有证书的认证，从而满足用户需求。此外，本申请实施例中，服务端通过按照第二目标CA中心的公钥证书的体系生成临时公私钥对，这就使得生成的临时公私钥对可以适用于智能卡的待认证证书，可以与智能卡的待认证证书进行会话密钥协商，从而可以保证后续码号数据的正常加密传输与识别，保证了码号数据下载过程的安全性。
实施例二：
本实施例在实施例一的基础上，以智能卡为eSIM卡的一个具体的码号数据下载过程为例，为本申请做进一步示例说明。其中，eSIM卡设置在终端上，终端通过LPA(LocalProfile Assistant，本地配置助手)实现与服务端(本实施例中为码号服务器，同时提供证书认证与码号下载服务)的连接。
参见图4所示，整个过程包括：
1.LPA向eSIM卡发送获取信息指令，请求获取eSIM卡的eID，厂商证书CERT_EUM，eSIM卡证书CERT_EUICC。
2.eSIM卡将自身的eID、厂商证书CERT_EUM、eSIM卡证书CERT_EUICC返回给LPA。
3.LPA向码号服务器发送码号下载请求，码号下载请求中包括：eID、CERT_EUM、CERT_EUICC、终端证书CERT_LPA。
在本申请实施例中，终端可以通过扫码、用户输入、预先配置等方式获取到码号服务器的网络地址，从而实现连接。
在本申请实施例中，假设LPA发送的码号下载请求中包含的证书是由CA中心A签发的。假设码号服务器中只存在CA中心B签发的公钥证书。
4.码号服务器收到码号下载请求后，检查码号下载请求中的证书数据。
本实施例中，码号服务器会发现CA证书签发中心不同，从而向CA中心B请求获取区块链的链路逻辑信息及CA中心A的公钥证书。
5.CA中心B实时获得最新的链路逻辑信息及CA中心A的公钥证书，返回给码号服务器。
6.码号服务器通过链路逻辑信息，获取区块链中CA中心A的上一CA中心的公钥，对CA中心A的可信签名进行验证。
通过后，使用CA中心A的公钥证书验证CERT_EUM和CERT_LPA证书的合法性，然后再用CERT_EUM验证CERT_EUICC证书合法性。
如果认证失败，流程结束，通知LPA下载申请失败。
如果认证通过，生成与CA中心A的公钥证书相同体系的临时公私钥对eKEY_PUB(临时公钥)和eKEY_PRI(临时私钥)。使用eKEY_PRI与CERT_EUICC中的公钥EUICC_PUB进行密钥协商，生成会话密钥S(会话密钥是对称密钥)，用S对profile进行分块加密处理，用S对eID计算签名，得到SIGN_DP。最后，将eKEY_PUB和SIGN_DP返回给LPA。
7.LPA将eKEY_PUB和SIGN_DP转发给eSIM卡。
8.eSIM卡收到eKEY_PUB和SIGN_DP后，用在卡内存储的CERT_EUICC证书的私钥与eKEY_PUB进行密钥协商，生成会话密钥S，用S对eID计算签名并验证SIGN_DP是否正确。如果不正确，流程结束，通知LPA请求失败。如果正确，则返回验证结果给LPA端。
9.LPA端收到验证通过的结果后，向码号服务器请求开始下载profile。
10.码号服务器端将加密好的profile下发给LPA。
11.LPA将加密好的profile转发给eSIM卡。
12.eSIM卡完成profile解密以及保存后，返回下载结果给LPA。
13.LPA可以将结果展示给用户并通知码号服务器。
通过上述方案，实现了不同CA中心之间的证书可信认证，解决了eSIM卡与码号服务器之间，存在不同证书的认证问题，无需eSIM卡存储大量的CA证书中心签发的证书，可以为eSIM卡节省了大量空间。
实施例三：
基于同一发明构思，本申请实施例中还提供了一种证书认证装置500和码号下载装置600。请参阅图5和图6所示，图5示出了采用图1所示的方法的证书认证装置，图6示出了采用图3所示的方法的码号下载装置。应理解，装置500和装置600具体的功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。装置500和装置600包括至少一个能以软件或固件的形式存储于存储器中或固化在装置500、装置600的操作***中的软件功能模块。具体地：
参见图5所示，装置500应用于服务端，包括：接收模块501、获取模块502以及认证模块503。其中：
所述接收模块501，用于接收智能卡的待认证证书；
所述获取模块502，用于若所述待认证证书不是第一目标CA中心签发的证书，从上级可信CA中心处，获取所述待认证证书所属的第二目标CA中心的公钥证书；所述第一目标CA中心为已向所述服务端签发证书的CA中心；所述上级可信CA中心为所述第一目标CA中心中的任一CA中心；所述上级可信CA中心与所述第二目标CA中心位于同一可信环境中；
所述认证模块503，用于使用所述第二目标CA中心的公钥证书对所述待认证证书进行认证。
在本申请实施例的一种可行实施方式中，所述可信环境为由可信的CA中心构成的区块链。
在从上级可信CA中心处，获取所述待认证证书所属的第二目标CA中心的公钥证书时，使用所述第二目标CA中心的公钥证书对所述待认证证书进行认证之前，所述获取模块502还用于从所述上级可信CA中心处，获取所述区块链的链路逻辑信息和所述第二目标CA中心的可信签名；所述链路逻辑信息包括所述区块链中所具有的各CA中心的连接关系。
所述认证模块503还用于采用第三目标CA中心的公钥对所述第二目标CA中心的可信签名进行验证，并确定验证通过。所述第三目标CA中心为所述区块链中对所述第二目标CA中心进行签名的CA中心。
在本可行实施方式的一种可行示例中，在采用第三目标CA中心的公钥对所述第二目标CA中心的可信签名进行验证之前，所述获取模块502还用于，根据所述第二目标CA中心的唯一中心标识，在所述链路逻辑信息中，确定出所述第二目标CA中心的位置；根据所述区块链中所具有的各CA中心的连接关系，以及预设的签名规则，确定出对所述第二目标CA中心进行签名的第三目标CA中心。
在本申请实施例中，所述签名规则为，所述区块链中的前一CA中心对后一CA中心进行签名。
在本申请实施例中，所述可信签名为：对CA中心中的所有公钥证书的唯一证书标识进行的签名。
参见图6所示，装置600应用于服务端，包括：证书认证模块601、生成模块602和加密模块603。其中：
所述证书认证模块601，用于根据实施例一中的证书认证方法进行智能卡的待认证证书的认证；
所述生成模块602，用于在认证通过后，按照所述公钥证书的体系生成临时公私钥对；以及用于使用所述临时公私钥对中的临时私钥与所述待认证证书中的公钥协商生成会话密钥；
所述加密模块603，用于采用所述会话密钥对码号数据进行加密并发送。
需要理解的是，出于描述简洁的考量，部分实施例一中描述过的内容在本实施例中不再赘述。
实施例四：
本实施例提供了一种服务器，参见图7所示，其包括处理器701、存储器702以及通信总线703。其中：
通信总线703用于实现处理器701和存储器702之间的连接通信。
处理器701用于执行存储器702中存储的一个或多个程序，以实现上述实施例一和/或实施例二中服务端所执行的证书认证方法和/或码号下载方法。
可以理解，图7所示的结构仅为示意，服务器还可包括比图7中所示更多或者更少的组件，或者具有与图7所示不同的配置。比如，其还具有外部通信接口等组件。
本实施例还提供了一种计算机可读存储介质，如软盘、光盘、硬盘、闪存、U盘、SD(Secure Digital Memory Card，安全数码卡)卡、MMC(Multimedia Card，多媒体卡)卡等，在该计算机可读存储介质中存储有实现上述各个步骤的一个或者多个程序，这一个或者多个程序可被一个或者多个处理器执行，以实现上述实施例一和/或实施例二中服务端所执行的证书认证方法和/或码号下载方法。在此不再赘述。
在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。
在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
在本文中，多个是指两个或两个以上。
以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种证书认证方法，其特征在于，应用于服务端，所述方法包括：
接收智能卡的待认证证书；
若所述待认证证书不是第一目标CA中心签发的证书，从上级可信CA中心处，获取所述待认证证书所属的第二目标CA中心的公钥证书；所述第一目标CA中心为已向所述服务端签发证书的CA中心；所述上级可信CA中心为所述第一目标CA中心中的任一CA中心；所述上级可信CA中心与所述第二目标CA中心位于同一可信环境中；所述可信环境为由可信的CA中心构成的区块链，所述区块链中的每个CA中心具有一个唯一中心标识；
使用所述第二目标CA中心的公钥证书对所述待认证证书进行认证；
所述从上级可信CA中心处，获取所述待认证证书所属的第二目标CA中心的公钥证书，包括：
对所述待认证证书进行解析，得到所述第二目标CA中心的唯一中心标识；
将所述第二目标CA中心的唯一中心标识以及所述待认证证书的对应标识携带在请求中，并将所述请求发送至所述上级可信CA中心，以使所述上级可信CA中心将所述请求转发至所述第二目标CA中心，且使得所述第二目标CA中根据所述对应标识，将相应的公钥证书返回至所述上级可信CA中心；
接收所述上级可信CA中心处发送的所述公钥证书。
2.如权利要求1所述的证书认证方法，其特征在于，从上级可信CA中心处，获取所述待认证证书所属的第二目标CA中心的公钥证书时，使用所述第二目标CA中心的公钥证书对所述待认证证书进行认证之前，所述方法还包括：
从所述上级可信CA中心处，获取所述区块链的链路逻辑信息和所述第二目标CA中心的可信签名；所述链路逻辑信息包括所述区块链中所具有的各CA中心的连接关系；
采用第三目标CA中心的公钥对所述第二目标CA中心的可信签名进行验证；所述第三目标CA中心为所述区块链中对所述第二目标CA中心进行签名的CA中心；
确定验证通过。
3.如权利要求2所述的证书认证方法，其特征在于，在采用第三目标CA中心的公钥对所述第二目标CA中心的可信签名进行验证之前，所述方法还包括：
根据所述第二目标CA中心的唯一中心标识，在所述链路逻辑信息中，确定出所述第二目标CA中心的位置；
根据所述区块链中所具有的各CA中心的连接关系，以及预设的签名规则，确定出对所述第二目标CA中心进行签名的第三目标CA中心。
4.如权利要求3所述的证书认证方法，其特征在于，所述签名规则为，所述区块链中的前一CA中心对后一CA中心进行签名。
5.如权利要求2-4任一项所述的证书认证方法，其特征在于，所述可信签名为：对CA中心中的所有公钥证书的唯一证书标识进行的签名。
6.一种码号下载方法，其特征在于，应用于服务端，包括：
在根据权利要求1-5任一项所述的证书认证方法认证通过后，按照所述公钥证书的体系生成临时公私钥对；
使用所述临时公私钥对中的临时私钥与所述待认证证书中的公钥协商生成会话密钥；
采用所述会话密钥对码号数据进行加密并发送。
7.一种证书认证装置，其特征在于，应用于服务端，包括：接收模块、获取模块以及认证模块；
所述接收模块，用于接收智能卡的待认证证书；
所述获取模块，用于若所述待认证证书不是第一目标CA中心签发的证书，从上级可信CA中心处，获取所述待认证证书所属的第二目标CA中心的公钥证书；所述第一目标CA中心为已向所述服务端签发证书的CA中心；所述上级可信CA中心为所述第一目标CA中心中的任一CA中心；所述上级可信CA中心与所述第二目标CA中心位于同一可信环境中；所述可信环境为由可信的CA中心构成的区块链，所述区块链中的每个CA中心具有一个唯一中心标识；
所述认证模块，用于使用所述第二目标CA中心的公钥证书对所述待认证证书进行认证；
所述获取模块具体用于对所述待认证证书进行解析，得到所述第二目标CA中心的唯一中心标识；将所述第二目标CA中心的唯一中心标识以及所述待认证证书的对应标识携带在请求中，并将所述请求发送至所述上级可信CA中心，以使所述上级可信CA中心将所述请求转发至所述第二目标CA中心，且使得所述第二目标CA中根据所述对应标识，将相应的公钥证书返回至所述上级可信CA中心；接收所述上级可信CA中心处发送的所述公钥证书。
8.一种码号下载装置，其特征在于，应用于服务端，包括：证书认证模块、生成模块和加密模块；
所述证书认证模块，用于根据权利要求1-5任一项所述的证书认证方法进行智能卡的待认证证书的认证；
所述生成模块，用于在认证通过后，按照所述公钥证书的体系生成临时公私钥对；以及用于使用所述临时公私钥对中的临时私钥与所述待认证证书中的公钥协商生成会话密钥；
所述加密模块，用于采用所述会话密钥对码号数据进行加密并发送。
9.一种服务器，其特征在于，包括：处理器、存储器及通信总线；
所述通信总线用于实现处理器和存储器之间的连接通信；
所述处理器用于执行存储器中存储的一个或者多个程序，以实现如权利要求1-5任一项所述的证书认证方法，或实现如权利要求6所述的码号下载方法。
10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如权利要求1-5任一项所述的证书认证方法，或实现如权利要求6所述的码号下载方法。
CN202111214327.5A 2021-10-19 2021-10-19 证书认证方法、码号下载方法、装置、服务器及存储介质 Active CN113824566B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111214327.5A CN113824566B (zh) 2021-10-19 2021-10-19 证书认证方法、码号下载方法、装置、服务器及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111214327.5A CN113824566B (zh) 2021-10-19 2021-10-19 证书认证方法、码号下载方法、装置、服务器及存储介质

Publications (2)

Publication Number Publication Date
CN113824566A CN113824566A (zh) 2021-12-21
CN113824566B true CN113824566B (zh) 2022-12-02

Family

ID=78916981

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111214327.5A Active CN113824566B (zh) 2021-10-19 2021-10-19 证书认证方法、码号下载方法、装置、服务器及存储介质

Country Status (1)

Country Link
CN (1) CN113824566B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116506134B (zh) * 2023-06-28 2023-09-15 山东海量信息技术研究院 数字证书管理方法、装置、设备、***及可读存储介质
CN117156440B (zh) * 2023-10-27 2024-01-30 中电科网络安全科技股份有限公司 一种证书认证方法、***、存储介质和电子设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109218028A (zh) * 2018-09-19 2019-01-15 江苏恒宝智能***技术有限公司 一种在线签发eSIM证书的方法、装置及***

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1306749C (zh) * 2003-12-04 2007-03-21 上海格尔软件股份有限公司 数字证书跨信任域互通方法
US10123202B1 (en) * 2017-07-11 2018-11-06 Verizon Patent And Licensing Inc. System and method for virtual SIM card
CN108900305B (zh) * 2018-06-28 2021-06-04 公安部第三研究所 基于智能安全芯片的多证书签发及验证方法
CN110011988B (zh) * 2019-03-21 2021-08-10 平安科技（深圳）有限公司 基于区块链的证书验证方法及装置、存储介质、电子装置
CN110198537A (zh) * 2019-05-13 2019-09-03 深圳杰睿联科技有限公司 支持多数字证书的eSIM管理方法、***及eSIM开通方法
CN111918274B (zh) * 2020-07-30 2021-05-14 恒宝股份有限公司 码号配置、管理方法、装置、电子设备及可读存储介质
CN112862487A (zh) * 2021-03-03 2021-05-28 青岛海链数字科技有限公司 一种数字证书认证方法、设备及存储介质

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109218028A (zh) * 2018-09-19 2019-01-15 江苏恒宝智能***技术有限公司 一种在线签发eSIM证书的方法、装置及***

Also Published As

Publication number Publication date
CN113824566A (zh) 2021-12-21

Similar Documents

Publication Publication Date Title
EP3800909B1 (en) Remote management method, and device
JP5099139B2 (ja) 公開鍵証明書状態の取得および確認方法
US20170099148A1 (en) Securely authorizing client applications on devices to hosted services
CN108848496B (zh) 基于TEE的虚拟eSIM卡的认证方法、TEE终端和管理平台
CN113824566B (zh) 证书认证方法、码号下载方法、装置、服务器及存储介质
US11689367B2 (en) Authentication method and system
CN101777978A (zh) 一种基于无线终端的数字证书申请方法、***及无线终端
EP2747377B1 (en) Trusted certificate authority to create certificates based on capabilities of processes
CN110740038B (zh) 区块链及其通信方法、网关、通信***和存储介质
CN114978635B (zh) 跨域认证方法及装置、用户注册方法及装置
CN113285932B (zh) 边缘服务的获取方法和服务器、边缘设备
CN110650478A (zh) Ota方法、***、设备、se模块、程序服务器和介质
CN112235301B (zh) 访问权限的验证方法、装置和电子设备
CN113536284B (zh) 一种数字证书的验证方法、装置、设备和存储介质
CN111414640B (zh) 秘钥访问控制方法和装置
CN111814131B (zh) 一种设备注册和配置管理的方法和装置
CN111800426A (zh) 应用程序中原生代码接口的访问方法、装置、设备及介质
CN112861106A (zh) 数字证书处理方法及***、电子设备及存储介质
CN114117551B (zh) 一种访问验证方法及装置
CN113784354B (zh) 基于网关的请求转换方法和装置
CN112583588B (zh) 一种通信方法及装置、可读存储介质
US20210135864A1 (en) Private key updating
CN114338091B (zh) 数据传输方法、装置、电子设备及存储介质
CN115622812A (zh) 基于区块链智能合约的数字身份验证方法及***
CN111163466B (zh) 5g用户终端接入区块链的方法、用户终端设备及介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant