CN114978648B - 一种云端和芯片间离线安全通信方法 - Google Patents

一种云端和芯片间离线安全通信方法 Download PDF

Info

Publication number
CN114978648B
CN114978648B CN202210524313.1A CN202210524313A CN114978648B CN 114978648 B CN114978648 B CN 114978648B CN 202210524313 A CN202210524313 A CN 202210524313A CN 114978648 B CN114978648 B CN 114978648B
Authority
CN
China
Prior art keywords
data
cloud
chip
field
algorithm
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
CN202210524313.1A
Other languages
English (en)
Other versions
CN114978648A (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.)
Wuhan Jahport Technology Co ltd
Original Assignee
Wuhan Jahport Technology 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 Wuhan Jahport Technology Co ltd filed Critical Wuhan Jahport Technology Co ltd
Priority to CN202210524313.1A priority Critical patent/CN114978648B/zh
Publication of CN114978648A publication Critical patent/CN114978648A/zh
Application granted granted Critical
Publication of CN114978648B publication Critical patent/CN114978648B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/3297—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 time stamps, e.g. generation of time stamps

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

本发明公开了一种云端和芯片间离线安全通信方法，包括认证和数据传输两部分，其中认证部分用于显式的云端与芯片双向认证或隐式的芯片对云端单向认证，确定本次会话要使用的密码算法套件，云端生成本次通信需要的密钥信息，芯片收到云端生成的本次通信需要的密钥信息；数据传输部分用于云端完成数据的加密与封装,并将数据离线发行，芯片或者终端收到数据进行解密。本发明能够为云端和芯片(或终端)之间建立一条安全传输通道，确保云端的应用数据能够安全地以离线形式下发至芯片内。

Description

一种云端和芯片间离线安全通信方法
技术领域
本发明属于计算机信息技术领域，涉及一种通信方法，具体涉及一种基于国密算法的云端和芯片间离线安全通信方法。
背景技术
目前云端和终端芯片之间的离线通信技术并不多见，常见的是基于SCP02或SCP03协议的在线通信技术，这些技术要求云端和终端实时交互，对网络稳定性要求很高，如果网络出现波动，则通信很容易意外中断。但本发明中提出的协议可一次性将待发送的所有数据都处理好后下发给终端，由终端逐条解密处理，或通过离线方式传输给终端，再由终端进行处理。
发明内容
本发明的目的在于提供一种基于国密算法的云端和芯片间离线安全通信方法、系统及设备，为云端和芯片(或终端)之间建立一条安全传输通道，确保云端的应用数据能够安全地以离线形式下发至芯片内。
本发明提供了一种云端和芯片间离线安全通信方法，当由芯片发起通信请求时，具体实现包括以下步骤：
步骤A1：终端发送GET AUTHENTICATE指令给芯片，向芯片请求认证数据；
步骤A2：芯片封装认证数据Auth_Data_SE，并发回终端；
步骤A3：终端将芯片的Auth_Data_SE数据包发送云端；
步骤A4：云端验证；
判断Alg_Ver字段，确定要使用的算法套件；对芯片的Auth_Data_SE数据进行验签与解析；
步骤A5：云端准备数据，获得密文应用数据；所述密文应用数据为云端将下发给芯片的数据，包括N条，组成指令序列；
确定Alg_Ver字段指定的算法套件，对应用数据进行加密，包括对相关信息进行加密，对标识信息进行签名；所述相关信息包括会话密钥SessKey、初始向量GCM_IV、和下一包数据的完整性验证数据Tag；所述标识信息包括协议版本号、云端时间戳、初始向量CBC_IV、和密文数据cipher0；
步骤A6：云端下发指令序列，其中第一条指令为MUTUAL AUTHENTICATION指令，包含Auth_Data_Cloud数据；后续N-1条指令均是PUTDATA指令，密文应用数据封装在PUTDATA指令序列中；
步骤A7：终端将云端的指令序列发回芯片；
终端按顺序将指令序列发回芯片，即先发送MUTUAL AUTHENTICATION指令，终端收到芯片的响应后，决定是否要发送GET SESSKEY指令后，形成处理分支：一条分支是发送GET_SESSKEY指令，获取到会话密钥SessKey，然后自己处理剩下的所有PUT_DATA指令；另一条分支不发送GET_SESSKEY指令，继续将剩下的PUT_DATA指令依次按顺序发送给芯片；
步骤A8：芯片根据自己支持的算法套件对指令数据Auth_Data_Cloud进行验签，并且得到会话密钥；
步骤A9：当终端使用GET SESSKEY指令向芯片导出本次会话的密钥，则后续向云端发送请求或者是对数据的解密操作均由终端进行，芯片导出会话密钥后不参与后续工作；
当终端未使用GET SESSKEY指令导出会话密钥，则后续的解密操作仍由芯片进行，终端只参与数据转发；
步骤A10：终端或芯片根据Alg_Ver字段确定算法套件，并对PUT DATA指令序列内的应用数据密文进行解密；
步骤A11：终端或芯片得到应用数据明文并交给应用进行处理。
本发明还提供了一种云端和芯片间离线安全通信方法，当由云端发起通信请求时，具体实现包括以下步骤：
步骤B1：云端准备数据，获得密文应用数据；所述密文应用数据为云端将下发给芯片的数据，包括N条，组成指令序列；
确定Alg_Ver字段指定的算法套件，对应用数据进行加密，包括对相关信息进行加密，对标识信息进行签名；所述相关信息包括会话密钥SessKey、初始向量GCM_IV、和下一包数据的完整性验证数据Tag；所述标识信息包括协议版本号、云端时间戳、初始向量CBC_IV、和密文数据cipher0；
步骤B2：云端下发指令序列，其中第一条指令为MUTUAL AUTHENTICATION指令，包含Auth_Data_Cloud数据；后续N-1条指令均是PUT_DATA指令，密文应用数据封装在PUT_DATA指令序列中；
步骤B3：终端将认证指令MUTUAL AUTHENTICATION转交芯片；
步骤B4：芯片确认是否支持Alg_Ver指定的算法套件，并对Auth_Data_Cloud进行验签与解密；
步骤B5：芯片使用会话密钥对PUT DATA指令序列内的密文应用数据解密，将明文内容转交应用进行处理。
常用的安全通道协议都是一来一回的形式，交互次数非常多，不适用于网络上的远程交互场景，本发明可以把所有的交互数据一次性下发下来，把交互次数从N次下降到1次；同时还支持离线数据交互，不需要网络也可以交互，对网络的要求进一步降低。
附图说明
图1为本发明实施例的当由芯片发起通信请求时云端和芯片间离线安全通信方法流程图；
图2为本发明实施例的当由云端发起通信请求时云端和芯片间离线安全通信方法流程图；
图3为本发明实施例的芯片发起的双向认证流程图；
图4为本发明实施例的云端发起的双向认证流程图；
图5为本发明实施例的数据加密原理图；
图6为本发明实施例的数据解密原理图。
具体实施方式
为了便于本领域普通技术人员理解和实施本发明，下面结合附图及实施例对本发明作进一步的详细描述，应当理解，此处所描述的实施示例仅用于说明和解释本发明，并不用于限定本发明。
本发明的目的在于为云端和芯片(或终端)之间建立一条安全传输通道，确保云端的应用数据能够安全地以离线形式下发至芯片内。本实施例的离线，即云端在生成认证数据之后，将认证数据与封装好的所有加密应用数据指令一次性下发，同时本次通信结束。
本发明严格来说工作在网络通信的传输层之上，所以不受通信时使用的网络协议限制，本发明中出现的+均代表有序连接，本发明中出现的数据均以小端方式存储。
本发明的方法共分为两部分：认证过程和数据传输过程；其中认证过程包括显式的云端与芯片双向认证或隐式的芯片对云端单向认证，确定本次会话要使用的密码算法套件，云端生成本次通信需要的密钥信息，芯片收到云端生成的本次通信需要的密钥信息。数据传输过程包括云端完成数据的加密与封装,并将数据离线发行，和芯片或者终端收到数据进行解密。
本实施例的认证过程中认为是云端和芯片进行认证，云端下发的认证指令均交付到了对端芯片内进行解析；但是中途有终端的参与，终端只做认证数据传输的中间者，不参与实际的认证过程。
本实施例的数据传输过程中认为是云端和芯片进行通信，但是可能会有终端参与进行数据解密的过程，也就是在此部分芯片需要具有能够将会话密钥导出给终端的能力。
本实施例首先对会出现的一些缩写词解释如下，其中数据相关的缩写词解释请见表1，密码算法相关的缩写词解释请见表2，
表1
表2
本实施例中，数据相关中解释了常用的数据缩写词，其中每一个缩写都代表一个要占用一定空间的数据字段。密码算法相关中解释了本协议中要使用到的字段和密码算法的抽象定义，其中Func_xxx是指用于某个功能的一类算法，如在表达式中出现，视作一个抽象函数；Func_xxx_Params则是该算法所需要的参数(包含所需的密钥)，是抽象表达，参数具体包含什么由算法决定。
请见图1和图3，本发明提供的一种云端和芯片间离线安全通信方法，当由芯片发起通信请求时，具体实现包括以下步骤：
步骤A1：终端发送GET AUTHENTICATE指令给芯片，向芯片请求认证数据；
步骤A2：芯片封装认证数据Auth_Data_SE，并发回终端；
步骤A3：终端将芯片的Auth_Data_SE数据包发送云端；
步骤A4：云端验证；
判断Alg_Ver字段，确定要使用的算法套件；对芯片的Auth_Data_SE数据进行验签与解析；
本实施例对芯片的Auth_Data_SE数据进行验签，具体步骤如下：
(1)确认密码套件；云端首先解包获得其中的Alg_Ver字段，根据该字段确定本次会话中要与终端使用的密码套件；
(2)验证签名；按照Alg_Ver字段中指定的签名算法对签名信息Sign_Data_SE部分进行验签；
如果是公私钥验签，则首先对公钥证书Cert_SE_Sign进行验证；验证成功后，使用Cert_SE_Sign中包含的芯片签名密钥对的公钥PK_SE_Sign进行验签；公钥证书只包含服务端对芯片公钥的签名以及芯片的公钥；
如果是IBC验签，则使用芯片身份标识ID_SE和签名IBC算法的公开主密钥IBC_Master_PK_Sign进行验签；
本实施例公钥证书Cert_SE_Sign和芯片身份标识ID_SE均包含在Auth_Data_SE数据的pub_info字段中；本实施例pub_info字段，为芯片的证明信息；
(3)确认时间戳；在(2)验签成功之后，计算云端生成的时间戳Time_Cloud与芯片内保存的最近一次的时间戳Time_SE之间的差值，如果未超出云端设置的阈值Time_Ctl限制，则认为认证成功，否则是重放的无效请求。此处由时间戳格式可知，时间戳数值大小可以用来比较时间的先后。
本实施例中，如果是明文通信，则没有验证签名操作。
步骤A5：云端准备数据，获得密文应用数据；本实施例密文应用数据为云端将下发给芯片的数据，包括N条，组成指令序列；
确定Alg_Ver字段指定的算法套件，对应用数据进行加密，包括对相关信息进行加密，对标识信息进行签名；本实施例相关信息包括会话密钥SessKey、初始向量GCM_IV、和下一包数据的完整性验证数据Tag；本实施例标识信息包括协议版本号、云端时间戳、初始向量CBC_IV、和密文数据cipher0；
请见图5，本实施例中，云端对应用数据进行加密，若要发送的应用数据共N组，则其中每一份数据编号为Data[i]，1<＝i<＝N；加密过程采取链式加密，且从最后一个分组Data[N]开始进行，每次对Data[i]+Tag[i+1]进行加密，即Cipher[i]，Tag[i]＝Func_Data_Wrap(Data[i]+Tag[i+1],Func_Data_Wrap_Params)，其中Tag[]是GCM模式下的认证码，由于第一次加密时尚未生成Tag[]，因此规定Tag[N+1]为全0比特；最终将得到N个Cipher[i]和Tag[i]，其中Cipher[i]将被封装到N个PUT DATA指令的数据域中。
整个加密过程从最后一个分组开始，从后往前进行，便于之后芯片能够从前往后进行解密。
步骤A6：云端下发指令序列，其中第一条指令为MUTUAL AUTHENTICATION指令，包含Auth_Data_Cloud数据；后续N-1条指令均是PUTDATA指令，密文应用数据封装在PUTDATA指令序列中；
步骤A7：终端将云端的指令序列发回芯片；
终端按顺序将指令序列发回芯片，即先发送MUTUAL AUTHENTICATION指令，终端收到芯片的响应后，决定是否要发送GET SESSKEY指令后，形成处理分支：一条分支是发送GET_SESSKEY指令，获取到会话密钥SessKey，然后自己处理剩下的所有PUT_DATA指令；另一条分支不发送GET_SESSKEY指令，继续将剩下的PUT_DATA指令依次按顺序发送给芯片；
步骤A8：芯片根据自己支持的算法套件对指令数据Auth_Data_Cloud进行验签，并且得到会话密钥；
本实施例芯片根据自己支持的算法套件对指令数据Auth_Data_Cloud进行验签，具体步骤如下：
(1)解包获取Alg_Ver字段，确认自己是否支持对应的算法；
(2)验证签名芯片使用自己支持的签名算法对数据域中的签名部分进行验签；
如果是公私钥验签，则使用芯片预置的云端用于签名的公私钥对中的公钥PK_Sign_Cloud进行验签；
如果是IBC算法，则使用预置的ID_Cloud和IBC_Master_PK_Sign进行验签；
(3)确认时间戳将收到的认证数据中的时间戳与Time_SE进行比对，若云端发来的时间戳大于Time_SE，则通过；否则认为是重放的无效请求；
(4)认证成功后使用这一次云端发来的时间戳更新Time_SE的值；
(5)解密Cipher[0]，SessKey，GCM_IV，Tag[1]＝Func_SessKey_Dec()Cipher[0]，Func_SessKey_Dec_Params)；其中，Func_SessKey_Dec与Func_SessKey_Enc是配对的；
Func_SessKey_Dec_Params与使用的具体算法类型有关；
如果是公私钥算法或IBC算法，则是对应的私钥或者用户私钥，均预置在芯片内；
如果是对称算法，则与加密时的参数Func_SessKey_Enc_Params一致，密钥预置在芯片内，随机生成的CBC_IV通过Auth_Data_Cloud明文传递。
本实施例中，如果是明文通信，则没有验证签名操作。
步骤A9：当终端使用GET SESSKEY指令向芯片导出本次会话的密钥，则后续向云端发送请求或者是对数据的解密操作均由终端进行，芯片导出会话密钥后不参与后续工作；
当终端未使用GET SESSKEY指令导出会话密钥，则后续的解密操作仍由芯片进行，终端只参与数据转发；
步骤A10：终端或芯片根据Alg_Ver字段确定算法套件，并对PUT DATA指令序列内的应用数据密文进行解密；
请见图6，本实施例中，在解密Cipher[0]得到SessKey之后，按序从前往后依次对PUT DATA指令序列进行处理，从数据域中依次获得Cipher[i]，依次执行：
(1)使用Tag[i]执行GMAC校验；
(2)解密Data[i]，Tag[i+1]＝Func_Data_Wrap(Cipher[i]，Func_Data_Wrap_Params)；
最后在解密Cipher[N]得到Tag[N+1]时，需要验证Tag[N+1]是否为全0序列。
步骤A11：终端或芯片得到应用数据明文并交给应用进行处理。
请见图2和图4，本发明提供的一种云端和芯片间离线安全通信方法，当由云端发起通信请求时，具体实现包括以下步骤：
步骤B1：云端准备数据，获得密文应用数据；本实施例密文应用数据为云端将下发给芯片的数据，包括N条，组成指令序列；
确定Alg_Ver字段指定的算法套件，对应用数据进行加密，包括对相关信息进行加密，对标识信息进行签名；本实施例相关信息包括会话密钥SessKey、初始向量GCM_IV、和下一包数据的完整性验证数据Tag；本实施例标识信息包括协议版本号、云端时间戳、初始向量CBC_IV、和密文数据cipher0；
请见图5，本实施例中，云端对应用数据进行加密，若要发送的应用数据共N组，则其中每一份数据编号为Data[i]，1<＝i<＝N；加密过程采取链式加密，且从最后一个分组Data[N]开始进行，每次对Data[i]+Tag[i+1]进行加密，即Cipher[i]，Tag[i]＝Func_Data_Wrap(Data[i]+Tag[i+1],Func_Data_Wrap_Params)，其中Tag[]是GCM模式下的认证码，由于第一次加密时尚未生成Tag[]，因此规定Tag[N+1]为全0比特；最终将得到N个Cipher[i]和Tag[i]，其中Cipher[i]将被封装到N个PUT DATA指令的数据域中。
整个加密过程从最后一个分组开始，从后往前进行，便于之后芯片能够从前往后进行解密。
步骤B2：云端下发指令序列，其中第一条指令为MUTUAL AUTHENTICATION指令，包含Auth_Data_Cloud数据；后续N-1条指令均是PUT_DATA指令，密文应用数据封装在PUT_DATA指令序列中；
步骤B3：终端将认证指令MUTUAL AUTHENTICATION转交芯片；
步骤B4：芯片确认是否支持Alg_Ver指定的算法套件，并对Auth_Data_Cloud进行验签与解密；
本实施例芯片根据自己支持的算法套件对指令数据Auth_Data_Cloud进行验签，具体步骤如下：
(1)解包获取Alg_Ver字段，确认自己是否支持对应的算法；
(2)验证签名芯片使用自己支持的签名算法对数据域中的签名部分进行验签；
如果是公私钥验签，则使用芯片预置的云端用于签名的公私钥对中的公钥PK_Sign_Cloud进行验签；
如果是IBC算法，则使用预置的ID_Cloud和IBC_Master_PK_Sign进行验签；
(3)确认时间戳将收到的认证数据中的时间戳与Time_SE进行比对，若云端发来的时间戳大于Time_SE，则通过；否则认为是重放的无效请求；
(4)认证成功后使用这一次云端发来的时间戳更新Time_SE的值；
(5)解密Cipher[0]，SessKey，GCM_IV，Tag[1]＝Func_SessKey_Dec()Cipher[0]，Func_SessKey_Dec_Params)；其中，Func_SessKey_Dec与Func_SessKey_Enc是配对的；
Func_SessKey_Dec_Params与使用的具体算法类型有关；
如果是公私钥算法或IBC算法，则是对应的私钥或者用户私钥，均预置在芯片内；
如果是对称算法，则与加密时的参数Func_SessKey_Enc_Params一致，密钥预置在芯片内，随机生成的CBC_IV通过Auth_Data_Cloud明文传递。
本实施例中，如果是明文通信，则没有验证签名操作。
步骤B5：芯片使用会话密钥对PUT DATA指令序列内的密文应用数据解密，将明文内容转交应用进行处理。
请见图6，本实施例中，在解密Cipher[0]得到SessKey之后，按序从前往后依次对PUT DATA指令序列进行处理，从数据域中依次获得Cipher[i]，依次执行：
(1)使用Tag[i]执行GMAC校验；
(2)解密Data[i]，Tag[i+1]＝Func_Data_Wrap(Cipher[i]，Func_Data_Wrap_Params)；
最后在解密Cipher[N]得到Tag[N+1]时，需要验证Tag[N+1]是否为全0序列。
本实施例的Alg_Ver字段，包括Ctl字段、Sign_Alg字段、Hash_Alg字段、SessKey_Enc_Alg字段和Data_Wrap_Alg字段；本实施例Ctl字段为控制字段,用于指明是否使用了密码套件；本实施例Sign_Alg字段，用于指明签名算法Func_Sign；本实施例Hash_Alg字段，用于指明哈希算法Func_Hash；本实施例SessKey_Enc_Alg字段，用于指明对会话密钥加解密时使用的算法Func_SessKey_Enc与Func_SessKey_Dec；本实施例Data_Wrap_Alg字段，用于指明会话密钥对应用数据进行加密时使用的对称算法Func_Data_Wrap。
本实施例的Alg_Ver字段，用于芯片向云端发起认证时，指明芯片支持的密码套件，长度为3字节；当使用明文通信时，本实施例流程不变,只不过所有涉及的加密算法均视作无效果的函数，且所有和加密相关的参数均不出现在通信中，即没有对应的字段；本实施例的Alg_Ver字段具体组成请见表3；
表3
各字段取值含义如下表4-表8，从上至下为优先级，且尽可能的在同种算法内不同类型算法强度大致相同。
表4：Ctl
表5：Sign_Alg，指明签名时的算法:
取值 含义
0000 未使用密码套件(Ctl字段为0x00时)
0001 使用256位SM2算法
0010 使用SM9算法
0011 使用3072位RSA算法
表6：Hash_Alg
取值 含义
0000 未使用密码套件(Ctl字段为0x00时)
0001 使用256位SM3哈希算法
0010 使用256位SHA算法
0011 使用MD5算法
表7：SessKey_Enc_Alg，指明对会话密钥(i.e.Cipher[0])加解密时使用的算法
取值 含义
0000 未使用密码套件(Ctl字段为0x00时)
0001 使用256位SM2算法
0010 使用SM9算法
0011 使用128位SM4算法
0100 使用3072位RSA算法
0101 使用128位AES算法
表8：Data_Wrap_Alg，指明使用会话密钥对应用数据进行加密时使用的对称算法,算法需要工作在GCM模式下
取值 含义
0000 未使用密码套件(Ctl字段为0x00时)
0001 使用128位SM4对称算法
0010 使用128位AES对称算法
本实施例中涉及到的密码算法共有四类，分别是：
(1)签名算法Func_Sign；
(2)哈希算法Func_Hash；
(3)会话密钥加解密算法Func_SessKey_Enc/Func_SessKey_Dec；
(4)数据加密算法Func_Data_Wrap；
对应算法涉及到的具体参数在协议里用Func_xxx_Params来表示，用来抽象表示任意类型算法的参数。
本实施例的签名算法Func_Sign可支持公私钥与IBC两种签名算法。
本实施例的公私钥算法可以支持SM2,RSA等算法，所有的公私钥对和证书需要事先生成，然后按照下表9的要求进行预置。签名时使用私钥签名，验签时使用公钥进行验签。
表9
本实施例的IBC算法支持SM9算法，所有的主密钥对和用户密钥对需要事先生成完毕，再按下表10进行预置。签名时使用用户私钥与公开主密钥进行签名，验签时使用IBC算法标识符与公开主密钥进行验签。
表10
本实施例的SM2和SM9的签名算法是对任意长的数据进行签名，即签名算法内部包含使用SM3进行哈希计算的过程。
本实施例的SM2签名算法中的用户身份标识使用规范推荐的16字节默认值，即从左至右为:
0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38。
本实施例的RSA的签名算法认为只能对固定长度的数据进行签名，且需要使用哈希算法进行摘要计算，必要时需要使用填充算法进行填充。
本实施例的哈希算法Func_Hash，无密钥和参数需求。
本实施例的加解密会话密钥算法Func_SessKey_Enc/Func_SessKey_Dec，不同类型算法对应的加解密参数组成如下表11所示。
表11
每个算法对密钥的需求如下：
公私钥算法可以支持SM2,RSA等算法，密钥对在云端生成，然后按要求进行预置，密钥情况如下表12所示。
表12
缩写 含义 预置
PK_SessKey 云端用来加密会话密钥的公钥 云端预置
SK_SessKey 芯片用来解密会话密钥的私钥 芯片预置
IBC算法支持SM9算法，密钥情况如下表13所示.
表13
对称算法可以支持SM4,AES等算法，且使用CBC模式，密钥和参数情况如下表14所示。
表14
缩写 含义 预置
Static_Key 对称算法的密钥,云端随机生成 云端和芯片均预置
CBC_IV 初始向量,由云端随机生成 -
本实施例的数据加密算法Func_Data_Wrap，支持SM4,AES等对称密码，且工作在GCM模式下，SessKey由云端使用随机算法生成，加密时使用m2填充算法对输入内容进行填充。Func_Data_Wrap_Params包含GCM模式的密钥与一些参数,如下表15所示。
表15
本实施例的填充算法，均使用m2填充方式：设M为待填充数据,数据以字节为最小单位，则首先在数据末尾添加一个0x80字节，然后再向该字节后面填充若干个0x00字节，直到满足需要的块大小整数倍。具体示意如下：
M||0x80||0x00||...||0x00。
本实施例芯片的Auth_Data_SE数据，包括Alg_Ver字段、Time_SE字段、CID字段、pub_info字段和Sign_Data_SE字段；本实施例Time_SE字段，为芯片内保存的最近一次的时间戳，该时间戳只在收到云端的Auth_Data_Cloud认证数据时,用云端发送的时间戳进行更新；本实施例CID字段，为芯片的标识符；本实施例pub_info字段，为芯片的证明信息；本实施例Sign_Data_SE字段，为Alg_Ver、Time_SE、CID、和pub_info的签名信息。
本实施例的Auth_Data_SE包含的内容(从上往下按顺序)具体请见下表16。
表16
其中，有密码套件时：Auth_Data_SE＝Alg_Ver+Time_SE+CID+pub_info+Sign_Data_SE；明文时：Auth_Data_SE＝Alg_Ver+Time_SE+CID。
本实施例的时间戳是自定义的8字节时间戳.各字节如下表17所示：
表17
也就是这8个字节内，低6字节是直接在对应位置上使用数字表示时间信息的有效时间戳。如低6字节是0x150b19123227则表示"21年11月25日18时50分39秒"。高1字节未使用，保留为全0字节。高2字节容错字节用于使服务端在生成时间戳时有一定的容错能力，当低6字节代表的时间生成有误导致时间过大时，可能会导致芯片收到并更新一个很久之后的时间戳。此时云端下一次下发时间戳时，需要将该字节加1来使得时间戳在芯片端被正确比较大小。
本实施例的证明信息pub_info，若使用公私钥算法(e.g.SM2)，则为Cert_SE_Sign(i.e.芯片端用于签名的公私钥的公钥证书)。其中，证书格式采用自定义的短证书格式，即只包含服务端对芯片公钥的签名以及芯片的公钥。Cert_SE_Sign＝服务端对公钥签名+芯片公钥。这有两个好处：一是节省空间。二是长度确定。
本实施例的短证书的签名输入都是不进行填充处理的，若使用IBC算法(e.g.SM9)，则为ID_SE(i.e.芯片端用于签名的IBC算法标识符)。
本实施例的签名Sign_Data_SE，SM2或者SM9算法时Sign_Data_SE＝Func_Sign(Alg_Ver+Time_SE+CID+pub_info,Func_Sign_Params)，此处没有显式计算哈希的过程，因为按照SM2和SM9规范，算法内部已经包含了使用SM3计算哈希值的过程。RSA算法时Sign_Data_SE＝Func_Sign(Func_Hash(Alg_Ver+Time_SE+CID+pub_info)，Func_Sign_Params)即先对内容进行一次哈希计算，然后对哈希值使用m2填充算法填充至需要的算法输入长度，再进行签名。
本实施例指令数据Auth_Data_Cloud，包括Alg_Ver字段、Time_Cloud字段、CBC_IV字段、Cipher[0]字段和Sign_Data_Cloud字段；本实施例Time_Cloud字段，为云端生成的时间戳；本实施例CBC_IV字段，为加密会话密钥时CBC模式的初始向量，当Func_SessKey_Enc/Func_SessKey_Dec是对称算法时，字段才不为空,且该字段是CBC模式的初始向量；当使用公私钥和IBC算法时，该字段为空；本实施例Cipher[0]字段，为一个包含会话信息的密文块；本实施例Sign_Data_Cloud字段，为Alg_Ver、Time_Cloud、CBC_IV、和Cipher[0]的签名信息。本实施例Cipher[0]字段，当使用算法套件时，密文块里包含了本次通信的密钥与解密数据包的所需要的算法参数；当Func_SessKey_Enc为SM2和SM9时，加密时无需填充；当Func_SessKey_Enc为CBC模式的SM4时，加密时使用m2填充；当明文通信时，此字段为空。
本实施例Auth_Data_Cloud包含内容(从上往下按顺序)具体请见下18；
表18
/>
即：有密码套件时：Auth_Data_Cloud＝Alg_Ver+Time_Cloud+CBC_IV+Cipher[0]+Sign_Data_Cloud；明文时：Auth_Data_Cloud＝Alg_Ver+Time_Cloud。
本实施例的Time_Cloud，格式与Time_SE相同，均是自定义8字节时间戳。
实施例的CBC_IV，只有当Func_SessKey_Enc/Func_SessKey_Dec是对称算法时，该字段才不为空，且该字段是CBC模式的初始向量。使用公私钥和IBC算法时，该字段为空，因为解密所需参数是固定且预置的。
本实施例的Cipher[0]，为对本次会话密钥以及会话加密用到的参数信息的密文块。
本实施例的Sign_Data_Cloud，采用SM2或SM9算法时，Sign_Data_Cloud＝Func_Sign(Alg_Ver+Time_Cloud+CBC_IV+Cipher[0],Func_Sign_Params)；此处没有显式计算哈希的过程，因为按照SM2和SM9规范，算法内部已经包含了使用SM3计算哈希值的过程。采用RSA算法时，Sign_Data_Cloud＝Func_Sign(Func_Hash(Alg_Ver+Time_Cloud+CBC_IV+Cipher[0]),Func_Sign_Params)，即先对内容进行一次哈希计算，然后对哈希值使用m2填充算法填充至需要的算法输入长度，再进行签名。
本实施例的指令集概览表请见下表19；
表19
通用响应状态码请见表20；
表20；
/>
本实施例GET AUTHENTICATE指令，由终端向芯片发送，用于协议中终端向芯片请求认证信息；包括CLA字段，取值为0x80；INS字段，取值为0x01；P1字段0x00；P2字段，取值为0x00；Lc字段，取值同GP规范；Data字段，取值同GP规范；Le字段，取值为0x00。
本实施例MUTUAL AUTHENTICATION指令，是云端向芯片发送的第一条指令,携带云端的认证数据；包括CLA字段，取值为0x80；INS字段，取值为0x02；P1字段，取值为0x00；P2字段，取值为0x00；Lc字段，取值同GP规范；Data字段，包含Auth_Data_Cloud；Le字段，取值同GP规范。该指令无响应数据，只有响应状态码。
本实施例PUT DATA指令，云端推送数据指令，用于推送数据密文；包括CLA字段，取值为0x80；INS字段，取值为0x03；P1字段，取值为0x00或0x80，0x00代表还有后续PUT DATA指令序列,0x80代表是最后一条PUT DATA指令；P2字段，取值为0x00至0xFF，代表该条指令在PUT DATA序列中的编号；Lc字段，取值同GP规范；Data字段，包含密文数据Cipher[i]和认证码Tag[i]；Le字段，取值同GP规范。该指令无响应数据，只有响应状态码。
本实施例GET SESSKEY指令，用于终端向芯片请求导出会话信息；包括CLA字段，取值为0x80；INS字段，取值为0x05；P1字段，取值为0x00；P2字段，取值为0x00；Lc字段，取值同GP规范；Data字段，取值同GP规范；Le字段，取值同GP规范。该指令为可选指令，如果被终端使用，则需要在芯片完成认证之后发送，且后续的PUT DATA指令不再发送给芯片，而是由终端对指令内密文进行解密；否则正常将后续的PUT DATA指令发送给芯片进行解密。
本实施例云端下发指令序列，其中MUTUAL AUTHENTICATION指令和PUT DATA指令通过离线的方式下发给终端；云端在生成认证数据之后，将认证数据与封装好的所有加密应用数据指令一次性下发，同时本次通信结束。本发明的方法不是只能用于离线场景，也可以用于在线场景。支持离线传输是本发明的一个特点和优势，并不是仅限于这种应用场景。
应当理解的是，上述针对较佳实施例的描述较为详细，并不能因此而认为是对本发明专利保护范围的限制，本领域的普通技术人员在本发明的启示下，在不脱离本发明权利要求所保护的范围情况下，还可以做出替换或变形，均落入本发明的保护范围之内，本发明的请求保护范围应以所附权利要求为准。

Claims (10)

1.一种云端和芯片间离线安全通信方法，其特征在于：当由芯片发起通信请求时，具体实现包括以下步骤：
步骤A1：终端发送GET AUTHENTICATE指令给芯片，向芯片请求认证数据；
步骤A2：芯片封装认证数据Auth_Data_SE，并发回终端；
步骤A3：终端将芯片的Auth_Data_SE数据包发送云端；
步骤A4：云端验证；
判断Alg_Ver字段，确定要使用的算法套件；对芯片的Auth_Data_SE数据进行验签与解析；
步骤A5：云端准备应用数据，获得密文应用数据；所述密文应用数据为云端将下发给芯片的包括N条数据组成的指令序列；
确定Alg_Ver字段指定的算法套件，对应用数据进行加密，包括对相关信息进行加密，对标识信息进行签名；所述相关信息包括会话密钥SessKey、初始向量GCM_IV、和下一包数据的完整性验证数据Tag；所述标识信息包括协议版本号、云端时间戳、初始向量CBC_IV、和密文数据cipher[0]；
步骤A6：云端下发指令序列，其中第一条指令为MUTUAL AUTHENTICATION指令，包含Auth_Data_Cloud数据；后续N-1条指令均是PUT_DATA指令，密文应用数据封装在PUT_DATA指令序列中；
步骤A7：终端将云端的指令序列发回芯片；
终端按顺序将指令序列发回芯片，即先发送MUTUAL AUTHENTICATION指令，终端收到芯片的响应后，决定是否要发送GET_SESSKEY指令后，形成处理分支：一条分支是发送GET_SESSKEY指令，获取到会话密钥SessKey，然后自己处理剩下的所有PUT_DATA指令；另一条分支不发送GET_SESSKEY指令，继续将剩下的PUT_DATA指令依次按顺序发送给芯片；
步骤A8：芯片根据自己支持的算法套件对认证数据Auth_Data_Cloud进行验签，并且得到会话密钥；
步骤A9：当终端使用GET_SESSKEY指令向芯片导出本次会话的密钥，则后续向云端发送请求或者是对数据的解密操作均由终端进行，芯片导出会话密钥后不参与后续工作；
当终端未使用GET_SESSKEY指令导出会话密钥，则后续的解密操作仍由芯片进行，终端只参与数据转发；
步骤A10：终端或芯片根据Alg_Ver字段确定算法套件，并对PUT_DATA指令序列内的密文应用数据进行解密；
步骤A11：终端或芯片得到应用数据明文并交给应用进行处理。
2.一种云端和芯片间离线安全通信方法，其特征在于：当由云端发起通信请求时，具体实现包括以下步骤：
步骤B1：云端准备应用数据，获得密文应用数据；所述密文应用数据为云端将下发给芯片的包括N条数据组成的指令序列；
确定Alg_Ver字段指定的算法套件，对应用数据进行加密，包括对相关信息进行加密，对标识信息进行签名；所述相关信息包括会话密钥SessKey、初始向量GCM_IV、和下一包数据的完整性验证数据Tag；所述标识信息包括协议版本号、云端时间戳、初始向量CBC_IV、和密文数据cipher[0]；
步骤B2：云端下发指令序列，其中第一条指令为MUTUAL AUTHENTICATION指令，包含Auth_Data_Cloud数据；后续N-1条指令均是PUT_DATA指令，密文应用数据封装在PUT_DATA指令序列中；
步骤B3：终端将认证指令MUTUAL AUTHENTICATION转交芯片；
步骤B4：芯片确认是否支持Alg_Ver指定的算法套件，并对Auth_Data_Cloud进行验签与解密；
步骤B5：芯片使用会话密钥对PUT_DATA指令序列内的密文应用数据解密，将明文内容转交应用进行处理。
3.根据权利要求1或2所述的云端和芯片间离线安全通信方法，其特征在于：所述Alg_Ver字段，包括Ctl字段、Sign_Alg字段、Hash_Alg字段、SessKey_Enc_Alg字段和Data_Wrap_Alg字段；所述Ctl字段为控制字段,用于指明是否使用了密码套件；所述Sign_Alg字段，用于指明签名算法Func_Sign；所述Hash_Alg字段，用于指明哈希算法Func_Hash；所述SessKey_Enc_Alg字段，用于指明对会话密钥加解密时使用的算法Func_SessKey_Enc与Func_SessKey_Dec；所述Data_Wrap_Alg字段，用于指明会话密钥对应用数据进行加密时使用的对称算法Func_Data_Wrap；
所述芯片的Auth_Data_SE数据，包括Alg_Ver字段、Time_SE字段、CID字段、pub_info字段和Sign_Data_SE字段；所述Time_SE字段，为芯片内保存的最近一次的时间戳，该时间戳只在收到云端的Auth_Data_Cloud认证数据时,用云端发送的时间戳进行更新；所述CID字段，为芯片的标识符；所述pub_info字段，为芯片的证明信息；所述Sign_Data_SE字段，为Alg_Ver、Time_SE、CID、和pub_info的签名信息；
所述认证数据Auth_Data_Cloud，包括Alg_Ver字段、Time_Cloud字段、CBC_IV字段、Cipher[0]字段和Sign_Data_Cloud字段；所述Time_Cloud字段，为云端生成的时间戳；所述CBC_IV字段，为加密会话密钥时CBC模式的初始向量，当
Func_SessKey_Enc/Func_SessKey_Dec是对称算法时，字段才不为空,且该字段是CBC模式的初始向量；当使用公私钥和IBC算法时，该字段为空；所述Cipher[0]字段，为一个包含会话信息的密文块；所述Sign_Data_Cloud字段，为Alg_Ver、Time_Cloud、CBC_IV、和Cipher[0]的签名信息。
4.根据权利要求1所述的云端和芯片间离线安全通信方法，其特征在于：所述Cipher[0]字段，当使用算法套件时，密文块里包含了本次通信的密钥与解密数据包的所需要的算法参数；当Func_SessKey_Enc为SM2和SM9时，加密时无需填充；当Func_SessKey_Enc为CBC模式的SM4时，加密时使用m2填充；当明文通信时，此字段为空。
5.根据权利要求1所述的云端和芯片间离线安全通信方法，其特征在于：步骤A4中所述对芯片的Auth_Data_SE数据进行验签，具体步骤如下：
(1)确认密码套件；云端首先解包获得其中的Alg_Ver字段，根据该字段确定本次会话中要与终端使用的密码套件；
(2)验证签名；按照Alg_Ver字段中指定的签名算法对签名信息Sign_Data_SE部分进行验签；
如果是公私钥验签，则首先对公钥证书Cert_SE_Sign进行验证；验证成功后，使用Cert_SE_Sign中包含的芯片签名密钥对的公钥PK_SE_Sign进行验签；公钥证书只包含服务端对芯片公钥的签名以及芯片的公钥；
如果是IBC验签，则使用芯片身份标识ID_SE和签名IBC算法的公开主密钥IBC_Master_PK_Sign进行验签；
所述公钥证书Cert_SE_Sign和芯片身份标识ID_SE均包含在Auth_Data_SE数据的pub_info字段中；所述pub_info字段，为芯片的证明信息；
(3)确认时间戳；在(2)验签成功之后，计算云端生成的时间戳Time_Cloud与芯片内保存的最近一次的时间戳Time_SE之间的差值，如果未超出云端设置的阈值Time_Ctl限制，则认为认证成功，否则是重放的无效请求。
6.根据权利要求1或2所述的云端和芯片间离线安全通信方法，其特征在于：所述云端下发指令序列，其中MUTUAL AUTHENTICATION指令和PUT_DATA指令通过离线的方式下发给终端；云端在生成认证数据之后，将认证数据与封装好的所有加密应用数据指令一次性下发，同时本次通信结束。
7.根据权利要求3所述的云端和芯片间离线安全通信方法，其特征在于：云端对应用数据进行加密，若要发送的应用数据共N组，则其中每一份数据编号为Data[i]，1<＝i<＝N；加密过程采取链式加密，且从最后一个分组Data[N]开始进行，每次对Data[i]+Tag[i+1]进行加密，即Cipher[i]，Tag[i]＝Func_Data_Wrap(Data[i]+Tag[i+1],Func_Data_Wrap_Params)，其中Tag[]是GCM模式下的认证码，由于第一次加密时尚未生成Tag[]，因此规定Tag[N+1]为全0比特；最终将得到N个Cipher[i]和Tag[i]，其中Cipher[i]将被封装到N个PUT_DATA指令的数据域中。
8.根据权利要求7所述的云端和芯片间离线安全通信方法，其特征在于：芯片端对应用数据进行解密，在解密Cipher[0]得到会话密钥SessKey之后,按序从前往后依次对PUT_DATA指令序列进行处理，从数据域中依次获得Cipher[i],依次执行：使用Tag[i]执行GMAC校验，解密Data[i],Tag[i+1]＝Func_Data_Wrap(Cipher[i],Func_Data_Wrap_Params)；最后在解密Cipher[N]得到Tag[N+1]时，验证Tag[N+1]是否为全0序列。
9.根据权利要求5所述的云端和芯片间离线安全通信方法，其特征在于：芯片根据自己支持的算法套件对认证数据Auth_Data_Cloud进行验签，具体步骤如下：
(1)解包获取Alg_Ver字段，确认自己是否支持对应的算法；
(2)验证签名芯片使用自己支持的签名算法对数据域中的签名部分进行验签；
如果是公私钥验签，则使用芯片中预置的云端用于签名的公私钥对中的公钥PK_Sign_Cloud进行验签；
如果是IBC算法，则使用预置的ID_Cloud和IBC_Master_PK_Sign进行验签；
(3)确认时间戳将收到的认证数据中的时间戳与Time_SE进行比对，若云端发来的时间戳大于Time_SE，则通过；否则认为是重放的无效请求；
(4)认证成功后使用这一次云端发来的时间戳更新Time_SE的值；
(5)解密Cipher[0]，SessKey，GCM_IV，Tag[1]＝Func_SessKey_Dec(Cipher[0]，
Func_SessKey_Dec_Params)；其中，Func_SessKey_Dec与Func_SessKey_Enc是配对的；
Func_SessKey_Dec_Params与使用的具体算法类型有关；
如果是公私钥算法或IBC算法，则是对应的私钥或者用户私钥，均预置在芯片内；
如果是对称算法，则与加密时的参数Func_SessKey_Enc_Params一致，密钥预置在芯片内，随机生成的CBC_IV通过Auth_Data_Cloud明文传递。
10.根据权利要求1所述的云端和芯片间离线安全通信方法，其特征在于：所述GETAUTHENTICATE指令，由终端向芯片发送，用于协议中终端向芯片请求认证信息；包括CLA字段，取值为0x80；INS字段，取值为0x01；P1字段0x00；P2字段，取值为0x00；Lc字段，取值同GP规范；Data字段，取值同GP规范；Le字段，取值为0x00；
所述MUTUAL AUTHENTICATION指令，是云端向芯片发送的第一条指令,携带云端的认证数据；包括CLA字段，取值为0x80；INS字段，取值为0x02；P1字段，取值为0x00；P2字段，取值为0x00；Lc字段，取值同GP规范；Data字段，包含Auth_Data_Cloud；Le字段，取值同GP规范；
所述PUT_DATA指令，由云端推送数据指令，用于推送数据密文；包括CLA字段，取值为0x80；INS字段，取值为0x03；P1字段，取值为0x00或0x80，0x00代表还有后续PUT_DATA指令序列,0x80代表是最后一条PUT_DATA指令；P2字段，取值为0x00至0xFF，代表该条指令在PUT_DATA序列中的编号；Lc字段，取值同GP规范；Data字段，包含密文数据Cipher[i]和认证码Tag[i]；Le字段，取值同GP规范；
所述GET_SESSKEY指令，用于终端向芯片请求导出会话信息；包括CLA字段，取值为0x80；INS字段，取值为0x05；P1字段，取值为0x00；P2字段，取值为0x00；Lc字段，取值同GP规范；Data字段，取值同GP规范；Le字段，取值同GP规范。
CN202210524313.1A 2022-05-13 2022-05-13 一种云端和芯片间离线安全通信方法 Active CN114978648B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210524313.1A CN114978648B (zh) 2022-05-13 2022-05-13 一种云端和芯片间离线安全通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210524313.1A CN114978648B (zh) 2022-05-13 2022-05-13 一种云端和芯片间离线安全通信方法

Publications (2)

Publication Number Publication Date
CN114978648A CN114978648A (zh) 2022-08-30
CN114978648B true CN114978648B (zh) 2024-03-29

Family

ID=82983937

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210524313.1A Active CN114978648B (zh) 2022-05-13 2022-05-13 一种云端和芯片间离线安全通信方法

Country Status (1)

Country Link
CN (1) CN114978648B (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007073659A1 (fr) * 2005-12-27 2007-07-05 Zte Corporation Methode d'acces des terminaux a base de protocole h.323 applique a un reseau de paquets
CN110601859A (zh) * 2019-10-12 2019-12-20 武汉珈港科技有限公司 一种基于25519椭圆曲线的无证书公钥密码签名方法
CN114173653A (zh) * 2019-05-29 2022-03-11 德克斯康公司 用于分析物数据的无线通信的系统和方法
CN114422205A (zh) * 2021-12-30 2022-04-29 广西电网有限责任公司电力科学研究院 一种电力专用cpu芯片网络层数据隧道建立方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007073659A1 (fr) * 2005-12-27 2007-07-05 Zte Corporation Methode d'acces des terminaux a base de protocole h.323 applique a un reseau de paquets
CN114173653A (zh) * 2019-05-29 2022-03-11 德克斯康公司 用于分析物数据的无线通信的系统和方法
CN110601859A (zh) * 2019-10-12 2019-12-20 武汉珈港科技有限公司 一种基于25519椭圆曲线的无证书公钥密码签名方法
CN114422205A (zh) * 2021-12-30 2022-04-29 广西电网有限责任公司电力科学研究院 一种电力专用cpu芯片网络层数据隧道建立方法

Also Published As

Publication number Publication date
CN114978648A (zh) 2022-08-30

Similar Documents

Publication Publication Date Title
US11290869B2 (en) Method for managing communication between a server and a user equipment
US9525557B2 (en) Certificate issuing system, client terminal, server device, certificate acquisition method, and certificate issuing method
US10903991B1 (en) Systems and methods for generating signatures
CN108377190B (zh) 一种认证设备及其工作方法
US10015159B2 (en) Terminal authentication system, server device, and terminal authentication method
CN111416807B (zh) 数据获取方法、装置及存储介质
CN101828357B (zh) 用于证书提供的方法和装置
US8130961B2 (en) Method and system for client-server mutual authentication using event-based OTP
US20230353390A1 (en) Method for upgrading certificate of pos terminal, server, and pos terminal
EP3518458A1 (en) Method and device for secure communications over a network using a hardware security engine
WO2016165900A1 (en) Method to check and prove the authenticity of an ephemeral public key
CN107104795B (zh) Rsa密钥对和证书的注入方法、架构及系统
CN108809633B (zh) 一种身份认证的方法、装置及系统
WO2018120938A1 (zh) 密钥离线传输方法、终端和存储介质
CN115378587B (zh) 密钥获取方法、装置、设备及可读存储介质
CN114172745A (zh) 一种物联网安全协议系统
CN101789863B (zh) 数据信息安全传输方法
CN110266485A (zh) 一种基于NB-IoT的物联网安全通信控制方法
WO2022115143A1 (en) Scalable key management for encrypting digital rights management authorization tokens
US8539236B2 (en) Re-authentication apparatus and method in downloadable conditional access system
CN114978648B (zh) 一种云端和芯片间离线安全通信方法
US20210044435A1 (en) Method for transmitting data from a motor vehicle and method for another vehicle to receive the data through a radio communication channel
CN113422753B (zh) 数据处理方法、装置、电子设备及计算机存储介质
CN116318784A (zh) 身份认证方法、装置、计算机设备和存储介质
CN109327310B (zh) 一种基于无证书的链路保护方法

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