CN118041695A - 信息交互方法、装置、电子设备、存储介质及程序产品 - Google Patents

信息交互方法、装置、电子设备、存储介质及程序产品 Download PDF

Info

Publication number
CN118041695A
CN118041695A CN202410431494.2A CN202410431494A CN118041695A CN 118041695 A CN118041695 A CN 118041695A CN 202410431494 A CN202410431494 A CN 202410431494A CN 118041695 A CN118041695 A CN 118041695A
Authority
CN
China
Prior art keywords
key
information
sender
receiver
fusion
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.)
Pending
Application number
CN202410431494.2A
Other languages
English (en)
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.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen 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 Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202410431494.2A priority Critical patent/CN118041695A/zh
Publication of CN118041695A publication Critical patent/CN118041695A/zh
Pending legal-status Critical Current

Links

Landscapes

  • Storage Device Security (AREA)

Abstract

本申请提供了一种信息交互方法、装置、电子设备、存储介质及程序产品;方法包括:获取信息发送方的发送方密钥以及信息接收方的接收方密钥;按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合,得到融合密钥;基于融合密钥,对待交互信息进行加密,得到待交互信息对应的加密交互信息;向服务后台发送加密交互信息,以使服务后台将加密交互信息转发至信息接收方。通过本申请,能够有效提高信息交互的信息安全性。

Description

信息交互方法、装置、电子设备、存储介质及程序产品
技术领域
本申请涉及计算机技术领域,尤其涉及一种信息交互方法、装置、电子设备、存储介质及程序产品。
背景技术
信息交互是信息处理和通信的基本活动,是信息系统的核心组成部分。信息交互在日常生活、工作、教育和科研等多个领域中都非常重要,它是人类社会和现代社会功能的基础。随着信息技术的发展,信息交互的方式和效率也在不断进步,为人们提供了更加便捷和高效的沟通方式。
在相关技术中,针对信息发送方和信息接收方之间的信息交互,通常是通过服务后台实现待交互信息的加解密,从而保证在信息交互的过程中的信息安全,由于服务后台能够实现对待交互信息的加解密,导致待交互信息在服务后台存在安全隐患,导致信息交互的信息安全性较差。
发明内容
本申请实施例提供一种信息交互方法、装置、电子设备、计算机可读存储介质及计算机程序产品,能够有效提高信息交互的信息安全性。
本申请实施例的技术方案是这样实现的:
本申请实施例提供一种信息交互方法,包括:
获取所述信息发送方的发送方密钥,并获取信息接收方的接收方密钥;
按照与所述信息接收方协商确定的密钥融合方式,将所述发送方密钥和所述接收方密钥进行融合,得到融合密钥;
基于所述融合密钥,对待交互信息进行加密,得到所述待交互信息对应的加密交互信息;
向服务后台发送所述加密交互信息,以使所述服务后台将所述加密交互信息转发至所述信息接收方。
本申请实施例提供一种信息交互装置,包括:
获取模块,用于获取所述信息发送方的发送方密钥,并获取信息接收方的接收方密钥;
融合模块,用于按照与所述信息接收方协商确定的密钥融合方式,将所述发送方密钥和所述接收方密钥进行融合,得到融合密钥;
加密模块,用于基于所述融合密钥,对待交互信息进行加密,得到所述待交互信息对应的加密交互信息;
发送模块,用于向服务后台发送所述加密交互信息,以使所述服务后台将所述加密交互信息转发至所述信息接收方。
上述方案中,上述信息交互装置,还包括:认证模块,用于获取能够与所述信息发送方会话的多个认证接收方,并获取所述信息发送方所对应的至少一个候选接收方;针对各所述候选接收方,将所述候选接收方分别与各所述认证接收方进行比较,当比较结果指示所述多个认证接收方中存在所述候选接收方时,将所述候选接收方确定为所述信息接收方。
上述方案中,上述获取模块,还用于针对各所述信息接收方分别执行以下处理:在所述信息发送方本地对所述信息接收方的接收方密钥进行查询,得到查询结果;当所述查询结果指示所述信息发送方本地存储有所述信息接收方的接收方密钥时,将所述接收方密钥的版本号,发送至所述服务后台,并接收所述服务后台针对所述版本号返回的返回信息,基于所述返回信息,确定所述信息接收方的接收方密钥;当所述查询结果指示所述信息发送方本地未存储所述信息接收方的接收方密钥时,向所述服务后台发送针对所述信息接收方的密钥获取请求,并接收所述服务后台针对所述密钥获取请求返回的所述接收方密钥。
上述方案中,上述返回信息中包括用于指示所述版本号是否为最新版本的版本指示信息,上述获取模块,还用于当所述版本指示信息指示所述版本号为最新版本时,将本地存储的接收方密钥,确定为所述信息接收方的接收方密钥;当所述版本指示信息指示所述版本号不是最新版本时,将所述返回信息中携带的接收方密钥,确定为所述信息接收方的接收方密钥。
上述方案中,上述获取模块,还用于获取发送方密钥库,所述发送方密钥库用于供所述信息发送方进行密钥存储;当所述发送方密钥库中未存储任何版本的发送方密钥时,生成所述发送方密钥;当所述发送方密钥库中存储有至少一个版本的发送方密钥时,将所述发送方密钥库中最新版本的发送方密钥,确定为候选发送方密钥;获取所述候选发送方密钥在所述发送方密钥库中的存储时长,基于所述存储时长,确定所述信息发送方的发送方密钥。
上述方案中,上述获取模块,还用于将所述存储时长与存储时长阈值进行比较,得到时长比较结果;当所述时长比较结果指示所述存储时长大于或等于所述存储时长阈值时,生成所述信息发送方的发送方密钥;当所述时长比较结果指示所述存储时长小于所述存储时长阈值时,将所述候选发送方密钥,确定为所述信息发送方的发送方密钥。
上述方案中,上述获取模块,还用于将所述信息发送方的发送方密钥,存储至所述发送方密钥库中,得到所述发送方密钥库对应的更新密钥库;向所述服务后台发送所述信息发送方的发送方密钥,以使所述服务后台将所述发送方密钥发送至所述信息接收方。
上述方案中,上述获取模块,还用于响应于所述信息发送方的信息交互请求,获取对所述信息发送方的发送方密钥进行加密所得到的加固密钥;向所述服务后台发送第一加密信息,以使所述服务后台对所述第一加密信息进行信息解密,得到用于对所述加固密钥进行解密的目标密钥;接收所述服务后台返回的所述目标密钥,并基于所述目标密钥,对所述加固密钥进行解密,得到所述信息发送方的发送方密钥。
上述方案中,上述信息交互装置,还包括:加固模块,用于向所述服务后台发送针对所述信息发送方的发送方密钥的密钥加固请求,以使所述服务后台对所述目标密钥进行更新,并对更新得到的更新目标密钥进行加密,得到第二加密信息;接收所述服务后台返回的所述更新目标密钥和所述第二加密信息,基于所述更新目标密钥,对所述发送方密钥进行密钥加固,得到更新加固密钥;将所述加固密钥更新为所述更新加固密钥,并将所述第一加密信息,更新为所述第二加密信息。
上述方案中,所述发送方密钥包括至少一个子发送方密钥,所述接收方密钥包括至少一个子接收方密钥,上述融合模块,还用于按照所述密钥融合方式,将各所述子发送方密钥和各所述子接收方密钥进行融合,得到所述融合密钥;其中,所述子发送方密钥的数量和所述子接收方密钥的数量的加和,与所述融合密钥的加密性能正相关。
上述方案中,上述融合模块,还用于针对各所述子发送方密钥,将所述子发送方密钥分别与各所述子接收方密钥进行融合,得到所述子发送方密钥对应的至少一个初始融合密钥,并基于各所述初始融合密钥,确定子发送方密钥对应的中间融合密钥;将各所述中间融合密钥进行融合,得到所述融合密钥。
上述方案中,上述加密模块,还用于生成初始密钥,并基于所述初始密钥,对所述待交互信息进行信息加密,得到加密信息;基于所述融合密钥,对所述初始密钥进行密钥加密,得到所述初始密钥对应的加密密钥;将所述加密密钥和所述加密信息进行信息融合,得到所述加密交互信息。
本申请实施例提供一种信息交互装置,包括:
接收模块,用于接收服务后台发送的加密交互信息,并获取所述信息接收方的接收方密钥以及信息发送方的发送方密钥;
融合模块,用于按照与所述信息接收方协商确定的密钥融合方式,将所述接收方密钥和所述发送方密钥进行融合,得到融合密钥;
解密模块,用于基于所述融合密钥,对所述加密交互信息进行解密,得到所述加密交互信息对应的待交互信息。
本申请实施例提供一种电子设备,包括:
存储器,用于存储计算机可执行指令或者计算机程序;
处理器,用于执行所述存储器中存储的计算机可执行指令或者计算机程序时,实现本申请实施例提供的信息交互方法。
本申请实施例提供一种计算机可读存储介质,存储有计算机可执行指令,用于引起处理器执行时,实现本申请实施例提供的信息交互方法。
本申请实施例提供了一种计算机程序产品,该计算机程序产品包括计算机程序或计算机可执行指令,该计算机程序或计算机可执行指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机可执行指令,处理器执行该计算机可执行指令,使得该电子设备执行本申请实施例上述的信息交互方法。
本申请实施例具有以下有益效果:
通过按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合,得到融合密钥,基于融合密钥,对待交互信息进行加密,得到待交互信息对应的加密交互信息,向服务后台发送加密交互信息,以使服务后台将加密交互信息转发至信息接收方。如此,由于密钥融合方式是信息接收方和信息发送方协商确定的,密钥融合方式为信息接收方和信息发送方所私有的,因此,按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合所得到的融合密钥,服务后台对融合密钥无感知,通过基于融合密钥,对待交互信息进行加密,得到的待交互信息对应的加密交互信息,服务后台无法对加密交互信息进行解密,通过向服务后台发送加密交互信息,以使服务后台将加密交互信息转发至信息接收方,从而使得信息发送方和信息接收方之间的信息交互过程,服务后台不能够实现对待交互信息的解密,使得待交互信息在服务后台不存在安全隐患,从而有效提高了信息交互的信息安全性。
附图说明
图1是本申请实施例提供的信息交互系统的架构示意图;
图2是本申请实施例提供的用于信息交互的电子设备的结构示意图一;
图3是本申请实施例提供的用于信息交互的电子设备的结构示意图二;
图4是本申请实施例提供的信息交互方法的流程示意图一;
图5是本申请实施例提供的信息交互方法的流程示意图二;
图6是本申请实施例提供的信息交互方法的流程示意图三;
图7是本申请实施例提供的信息交互方法的流程示意图四;
图8是本申请实施例提供的信息交互方法的流程示意图五;
图9是本申请实施例提供的信息交互方法的流程示意图六;
图10是本申请实施例提供的信息交互方法的流程示意图七;
图11是本申请实施例提供的设置加密成员的界面示意图;
图12是本申请实施例提供的客户端私钥安全加固的原理示意图一;
图13是本申请实施例提供的客户端私钥安全加固的原理示意图二;
图14是本申请实施例提供的生效名单列表的原理示意图;
图15是本申请实施例提供的密钥存储的原理示意图;
图16是本申请实施例提供的信息发送方与服务后台之间的密钥更新的流程示意图;
图17是本申请实施例提供的获取信息接收方的公钥信息的流程示意图;
图18是本申请实施例提供的信息交互方法的流程示意图八;
图19是本申请实施例提供的多设备进行信息交互的原理示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请作进一步地详细描述,所描述的实施例不应视为对本申请的限制,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本申请保护的范围。
在以下的描述中,涉及到“一些实施例”,其描述了所有可能实施例的子集,但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集,并且可以在不冲突的情况下相互结合。
在以下的描述中,所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象,不代表针对对象的特定排序,可以理解地,“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序,以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
除非另有定义,本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的,不是旨在限制本申请。
对本申请实施例进行进一步详细说明之前,对本申请实施例中涉及的名词和术语进行说明,本申请实施例中涉及的名词和术语适用于如下的解释。
1)信息交互(Information Interaction):是指在两个或多个实体之间进行的关于信息的交换和处理的过程。这些实体可以是人类、机器、系统或任何其他能够处理和传递信息的实体。信息交互是信息处理和通信的基本活动,是信息系统的核心组成部分。信息交互在日常生活、工作、教育和科研等多个领域中都非常重要,它是人类社会和现代社会功能的基础。随着信息技术的发展,信息交互的方式和效率也在不断进步,为人们提供了更加便捷和高效的沟通方式。
2)密钥(Key):在密码学中,是指用于加密或解密信息的代码或字符串。密钥是加密算法中不可或缺的组成部分,它用于将明文(即未加密的数据)转换为密文(即加密的数据),反之亦然。密钥的长度和复杂度直接影响到加密的安全性。
3)信息接收方(Information Recipient):是指在信息交互过程中接收信息的一方。信息接收方可以是个人、组织、系统或其他能够处理和理解信息的实体信息接收方的角色是接收、处理和响应发送方传递的信息。在信息交互中,信息接收方扮演着至关重要的角色。他们需要能够准确、及时地接收和处理信息,以做出正确的决策和采取有效的行动。同时,信息接收方也需要保护接收到的信息,防止数据泄露和滥用。
4)信息发送方(Information Sender)是指在信息交互过程中发起信息传递的一方。信息发送方通常是信息的来源,负责产生、编辑和发送信息给信息方。
5)响应于:用于表示所执行的操作所依赖的条件或者状态,当满足所依赖的条件或状态时,所执行的一个或多个操作可以是实时的,也可以具有设定的延迟;在没有特别说明的情况下,所执行的多个操作不存在执行先后顺序的限制。
6)端到端加密(E2EE):是一种消息传递类型,它使消息对所有人保持私密,包括消息传递服务(即后台),使用端到端加密时,消息仅在发送消息的设备和接收消息的设备上以解密形式出现。发送者是对话的一个“端”,而接收者是另一个“端”,因此得名“端到端”。
7)Signal协议(Signal Protocol):是一种端到端加密协议,用于为短信、电话通话和即时消息提供加密保护。该协议的设计目标是确保内容的安全性,即使数据在传输过程中被拦截,攻击者也无法读取或篡改信息。 Signal协议的核心特点包括:端到端加密:Signal协议确保通信内容在发送方的设备上加密,然后在接收方的设备上解密,中间传输过程中不泄露任何明文信息。密钥交换:协议使用双棘轮密钥交换(Double Ratchet)算法来生成和交换加密密钥,确保通信双方能够安全地协商密钥。前向保密:Signal协议的密钥管理机制能够实现前向保密,即即使密钥被泄露,也无法解密之前的历史通信内容。抗中间人攻击:Signal协议通过验证通信双方的密钥和身份,确保通信双方是真实身份,从而抵抗中间人攻击。开放源代码:Signal协议的实现是开源的,允许第三方进行审查和验证,增强用户对协议安全性的信任。
8)DH协议(Diffie-Hellman Protocol):是一种安全的密钥交换协议,该协议允许两个实体在不安全的信道中协商一个密钥,而这个密钥可以用于后续的安全通信,例如加密和解密信息。DH协议的核心特点和步骤包括:密钥协商:DH协议允许两个通信方在不直接交换密钥的情况下,通过算法生成一个共享的密钥。安全性:DH协议的安全性基于离散对数问题的难解性。攻击者无法从公开的交换过程中推断出共享密钥。步骤:DH协议典型步骤包括选择一个公共的基底g和一个大质数p,然后每个通信方选择一个秘密数a和b,分别计算公钥A和B,最后通过交换公钥来计算共享密钥。应用:DH协议广泛应用于各种安全协议和加密算法中,如SSL/TLS、IKE(Internet Key Exchange)等。DH协议是现代密码学中非常关键的一个组成部分,它使得安全的密钥交换成为,从而为保护通信内容提供了基础。
9)一次性预共享密钥对(One-Time Pre-Shared Key Pair):是一种安全机制,用于在两个实体之间建立一个临时的密钥,该密钥仅用于一次通信会话。这种密钥对在会话开始前被共享,并在会话结束后销毁,以保证通信的安全性和不可追溯性。一次性预共享密钥对在需要高度安全通信的场景中非常有用,如通信、高级别的商业交易和某些加密协议中。它可以帮助保护通信内容,防止被未授权的第三方截获和破解。
10)密钥派生算法:在密码学中,密钥派生函数(Key derivation function,KDF)使用伪随机函数从诸如主密钥或密码的秘密值中派生出一个或多个密钥。KDF可用于将密钥扩展为更长的密钥或获取所需格式的密钥,常用的KDF是基于HMAC(消息认证码)的HKDF。
11)对称加密算法(Symmetric Encryption Algorithm)是一种加密方法,其中使用相同的密钥进行数据的加密和解密。这意味着发送方和接收方都使用相同的密钥来加密数据,然后使用相同的密钥来解密数据。对称加密算法在需要高速、高效加密和解密的应用中非常受欢迎,如加密文件、加密数据库和加密通信通道等。然而,密钥管理和分发是使用对称加密算法的关键挑战,需要确保密钥的安全性和保密性。
在本申请实施例的实施过程中,申请人发现相关技术存在以下问题:
在相关技术中,针对信息发送方和信息接收方之间的信息交互,通常是通过服务后台实现待交互信息的加解密,从而保证在信息交互的过程中的信息安全,由于服务后台能够实现对待交互信息的加解密,导致待交互信息在服务后台存在安全隐患,导致信息交互的信息安全性较差。
本申请实施例提供一种信息交互方法、装置、电子设备、计算机可读存储介质及计算机程序产品,能够有效提高信息交互的信息安全性,下面说明本申请实施例提供的信息交互系统的示例性应用。
参见图1,图1是本申请实施例提供的信息交互系统100的架构示意图,终端(示例性示出了终端400)通过网络300连接服务器200,网络300可以是广域网或者局域网,又或者是二者的组合。
终端400用于供用户使用客户端410,在图形界面410-1(示例性示出了图形界面410-1)显示待交互信息。终端400和服务器200通过有线或者无线网络相互连接。
在一些实施例中,服务器200可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content DeliveryNetwork,CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能电视、智能手表、车载终端等,但并不局限于此。本申请实施例提供的电子设备可以实施为终端,也可以实施为服务器。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接,本申请实施例中不做限制。
在一些实施例中,终端400获取发送方密钥和接收方密钥,按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合,得到融合密钥;基于融合密钥,对待交互信息进行加密,得到待交互信息对应的加密交互信息,并将加密交互信息发送至服务器200,以使服务器200将加密交互信息转发至信息接收方。
在另一些实施例中,服务器200获取发送方密钥和接收方密钥,按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合,得到融合密钥;基于融合密钥,对待交互信息进行加密,得到待交互信息对应的加密交互信息,并将加密交互信息发送至终端400,以使终端400将加密交互信息转发至信息接收方。
在另一些实施例中,本申请实施例可以借助于云技术(Cloud Technology)实现,云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来,实现数据的计算、储存、处理和共享的一种托管技术。
云技术是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、以及应用技术等的总称,可以组成资源池,按需所用,灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源。
参见图2,图2是本申请实施例提供的用于信息交互的电子设备500的结构示意图一,其中,图2所示出的电子设备500可以是图1中的服务器200或者终端400,图2所示的电子设备500包括:至少一个处理器430、存储器450、至少一个网络接口420。电子设备500中的各个组件通过总线系统440耦合在一起。可理解,总线系统440用于实现这些组件之间的连接通信。总线系统440除包括数据总线之外,还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见,在图2中将各种总线都标为总线系统440。
处理器430可以是一种集成电路芯片,具有信号的处理能力,例如通用处理器、数字信号处理器(DSP,Digital Signal Processor),或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等,其中,通用处理器可以是微处理器或者任何常规的处理器等。
存储器450可以是可移除的,不可移除的或其组合。示例性的硬件设备包括固态存储器,硬盘驱动器,光盘驱动器等。存储器450可选地包括在物理位置上远离处理器430的一个或多个存储设备。
存储器450包括易失性存储器或非易失性存储器,也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM,Read Only Memory),易失性存储器可以是随机存取存储器(RAM,Random Access Memory)。本申请实施例描述的存储器450旨在包括任意适合类型的存储器。
在一些实施例中,存储器450能够存储数据以支持各种操作,这些数据的示例包括程序、模块和数据结构或者其子集或超集,下面示例性说明。
操作系统451,包括用于处理各种基本系统服务和执行硬件相关任务的系统程序,例如框架层、核心库层、驱动层等,用于实现各种基础业务以及处理基于硬件的任务;
网络通信模块452,用于经由一个或多个(有线或无线)网络接口420到达其他电子设备,示例性的网络接口420包括:蓝牙、无线相容性认证(WiFi,Wireless Fidelity)、和通用串行总线(USB,Universal Serial Bus)等。
在一些实施例中,本申请实施例提供的信息交互装置可以采用软件方式实现,图2示出了存储在存储器450中的信息交互装置455,其可以是程序和插件等形式的软件,包括以下软件模块:获取模块4551、融合模块4552、加密模块4553、发送模块4554,这些模块是逻辑上的,因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。
参见图3,图3是本申请实施例提供的用于信息交互的电子设备的结构示意图二,其中,图3所示出的电子设备600可以是图1中的服务器200或者终端400,图3所示的电子设备600包括:至少一个处理器530、存储器550、至少一个网络接口520。电子设备600中的各个组件通过总线系统540耦合在一起。可理解,总线系统540用于实现这些组件之间的连接通信。总线系统540除包括数据总线之外,还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见,在图3中将各种总线都标为总线系统540。
处理器530可以是一种集成电路芯片,具有信号的处理能力,例如通用处理器、数字信号处理器(DSP,Digital Signal Processor),或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等,其中,通用处理器可以是微处理器或者任何常规的处理器等。
存储器550可以是可移除的,不可移除的或其组合。示例性的硬件设备包括固态存储器,硬盘驱动器,光盘驱动器等。存储器550可选地包括在物理位置上远离处理器530的一个或多个存储设备。
存储器550包括易失性存储器或非易失性存储器,也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM,Read Only Memory),易失性存储器可以是随机存取存储器(RAM,Random Access Memory)。本申请实施例描述的存储器550旨在包括任意适合类型的存储器。
在一些实施例中,存储器550能够存储数据以支持各种操作,这些数据的示例包括程序、模块和数据结构或者其子集或超集,下面示例性说明。
操作系统551,包括用于处理各种基本系统服务和执行硬件相关任务的系统程序,例如框架层、核心库层、驱动层等,用于实现各种基础业务以及处理基于硬件的任务;
网络通信模块552,用于经由一个或多个(有线或无线)网络接口520到达其他电子设备,示例性的网络接口520包括:蓝牙、无线相容性认证(WiFi,Wireless Fidelity)、和通用串行总线(USB,Universal Serial Bus)等。
在一些实施例中,本申请实施例提供的信息交互装置可以采用软件方式实现,图3示出了存储在存储器550中的信息交互装置555,其可以是程序和插件等形式的软件,包括以下软件模块:接收模块5551、融合模块5552,解密模块5553,这些模块是逻辑上的,因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。
在另一些实施例中,本申请实施例提供的信息交互装置可以采用硬件方式实现,作为示例,本申请实施例提供的信息交互装置可以是采用硬件译码处理器形式的处理器,其被编程以执行本申请实施例提供的信息交互方法,例如,硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC,Application Specific IntegratedCircuit)、DSP、可编程逻辑器件(PLD,Programmable Logic Device)、复杂可编程逻辑器件(CPLD,Complex Programmable Logic Device)、现场可编程门阵列(FPGA,Field-Programmable Gate Array)或其他电子元件。
在一些实施例中,终端或服务器可以通过运行计算机程序或计算机可执行指令来实现本申请实施例提供的信息交互方法。举例来说,计算机程序可以是操作系统中的原生程序(例如,专用的信息交互程序)或软件模块,例如,可以嵌入到任意程序(如即时通信客户端、相册程序、电子地图客户端、导航客户端)中的信息交互模块;例如可以是本地(Native)应用程序(APP,Application),即需要在操作系统中安装才能运行的程序。总而言之,上述计算机程序可以是任意形式的应用程序、模块或插件。
将结合本申请实施例提供的服务器或终端的示例性应用和实施,说明本申请实施例提供的信息交互方法。
参见图4,图4是本申请实施例提供的信息交互方法的流程示意图一,将结合图4示出的步骤101至步骤105进行说明,本申请实施例提供的信息交互方法可以由服务器或终端单独实施,或者由服务器及终端协同实施,下面将以终端单独实施,应用于信息发送方为例进行说明。
在步骤101中,获取信息发送方的发送方密钥。
在一些实施例中,上述信息发送方是指在信息交互过程中发起信息传递的一方。信息发送方通常是信息的来源,负责产生、编辑和发送信息给信息方。
在一些实施例中,上述发送方密钥是指在信息发送方生成,且信息发送方自身特有的密钥。
在一些实施例中,参见图5,图5是本申请实施例提供的信息交互方法的流程示意图二,在执行上述步骤101之前,还可以通过图5所示出的步骤106至步骤107确定信息接收方。
在步骤106中,获取能够与信息发送方会话的多个认证接收方,并获取信息发送方所对应的至少一个候选接收方。
在一些实施例中,上述能够与信息发送方会话的认证接收方,是指能够与信息发送方进行安全通信,且拥有正确认证和授权的待交互信息的接收方。能够与信息发送方会话的多个认证接收方是指在安全通信中,能够与信息发送方进行加密和认证的通信的实体,且每个实体都拥有相应的身份验证和授权。
在一些实施例中,信息发送方和信息接收方所交互的待交互信息,可以是文字信息、视频信息等各种信息类型,信息发送方和信息接收方所交互的待交互信息的信息类型不构成对本申请实施例的限定。
作为示例,在企业或组织内部的应用场景中,认证接收方可以是被授权与特定的发送方进行通信的企业员工,认证接收方都有各自的身份验证和授权机制,以确保只有认证的接收方,也即认证接收方才能参与会话。
作为示例,在商业环境中,发送方可能需要与多个合作伙伴或客户进行通信。这些接收方也必须经过适当的认证和授权,以确保只有被认可的实体才能参与会话。
在一些实施例中,上述候选接收方(Candidate Recipient)是指信息发送方当前的待交互信息期望进行交互的接收方,候选接收方是指在信息发送方当前的通信过程中,被认为是潜在的接收方,即发送方期望与之交互接收信息的实体。
在步骤107中,针对各候选接收方,将候选接收方分别与各认证接收方进行比较,当比较结果指示多个认证接收方中存在候选接收方时,将候选接收方确定为信息接收方。
在一些实施例中,上述信息接收方是指为认证接收方的候选接收方,也即能够与信息发送方进行安全通信,且拥有正确认证和授权的待交互信息,且信息发送方当前的待交互信息期望进行交互的接收方。
作为示例,针对候选接收方A,将候选接收方A分别与认证接收方A、认证接收方B和认证接收方C进行比较,当比较结果指示多个认证接收方中存在候选接收方A时,将候选接收方A确定为信息接收方。
作为示例,针对候选接收方D,将候选接收方D分别与认证接收方A、认证接收方B和认证接收方C进行比较,当比较结果指示多个认证接收方中不存在候选接收方A时,不将候选接收方D确定为信息接收方。
如此,获取能够与信息发送方会话的多个认证接收方,并获取信息发送方所对应的至少一个候选接收方,针对各候选接收方,将候选接收方分别与各认证接收方进行比较,当比较结果指示多个认证接收方中存在候选接收方时,将候选接收方确定为信息接收方,从而通过确保只有经过认证的接收方能够与发送方会话,可以显著提高通信的安全性,有助于防止未授权的访问和数据泄露,认证接收方的机制可以帮助保护用户的隐私,确保待交互信息只被授权的接收方看到,从而有效提高了信息交互的信息安全性。
在一些实施例中,参见图6,图6是本申请实施例提供的信息交互方法的流程示意图三,图4所示出的步骤101可以通过执行图6所示出的步骤1011A至步骤1014A实现。
在步骤1011A中,获取发送方密钥库,发送方密钥库用于供信息发送方进行密钥存储。
在一些实施例中,上述发送方密钥库(Sender's Key Store)是指搭载与信息发送方本地,供信息发送方进行密钥存储的数据库,发送方密钥库可以存储不同版本的发送方密钥,随着发送方密钥的版本更新而更新,发送方密钥库是一个安全的数据结构或组件,用于存储和管理信息发送方在加密通信中使用的密钥,这些密钥用于确保信息在传输过程中的机密性和完整性。
在步骤1012A中,当发送方密钥库中未存储任何版本的发送方密钥时,生成发送方密钥。
在一些实施例中,当发送方密钥库中未存储任何版本的发送方密钥时,说明此时信息发送方还从未生成任何版本的发送方密钥,此时可以生成第1个版本的发送方密钥。
在一些实施例中,上述发送方密钥的生成方式可以是通过随机数生成方式,量子密钥分发生成方式等方式,上述发送方密钥的具体生成方式不构成对本申请实施例的限定,例如,通过随机数生成方式,通过使用伪随机数生成器(PRNG)或真随机数生成器(TRNG)来创建一个随机数,这个随机数用作密钥。为了保证安全性,生成的随机数应该具有足够的长度和熵;量子密钥分发生成方式,使用量子态的测量结果来创建一个只有通信双方知道的秘密钥,任何尝试识别量子密钥分发的尝试都会被检测到,从而保证密钥的安全性。
在步骤1013A中,当发送方密钥库中存储有至少一个版本的发送方密钥时,将发送方密钥库中最新版本的发送方密钥,确定为候选发送方密钥。
在一些实施例中,当发送方密钥库中仅存储有一个版本的发送方密钥时,将发送方密钥库中的发送方密钥,确定为候选发送方密钥;当发送方密钥库中存储有至少一个版本的发送方密钥时,将发送方密钥库中最新版本的发送方密钥,确定为候选发送方密钥。
作为示例,发送方密钥库中存储有第1个版本的发送方密钥、第2个版本的发送方密钥和第3个版本的发送方密钥,将第3个版本的发送方密钥,确定为候选发送方密钥。
在步骤1014A中,获取候选发送方密钥在发送方密钥库中的存储时长,基于存储时长,确定信息发送方的发送方密钥。
在一些实施例中,上述候选发送方密钥在发送方密钥库中的存储时长与候选发送方密钥在发送方密钥库的版本号的大小负相关,上述存储时长是指候选发送方密钥在存储至发送方密钥库的时间至当前时间之间的时间长度。
在一些实施例中,上述基于存储时长,确定信息发送方的发送方密钥,可以通过如下方式实现:将存储时长与存储时长阈值进行比较,得到时长比较结果;当时长比较结果指示存储时长大于或等于存储时长阈值时,生成信息发送方的发送方密钥;当时长比较结果指示存储时长小于存储时长阈值时,将候选发送方密钥,确定为信息发送方的发送方密钥。
在一些实施例中,上述存储时长阈值,用于指示发送方密钥库中的发送方密钥的版本更新时间,当时长比较结果指示存储时长大于或等于存储时长阈值时,则需要进行发送方密钥的版本更新,则可以生成信息发送方的发送方密钥。当时长比较结果指示存储时长小于存储时长阈值时,则暂时无需进行发送方密钥的版本更新,则可以直接将候选发送方密钥,确定为信息发送方的发送方密钥。
如此,通过将存储时长与存储时长阈值进行比较,得到时长比较结果;当时长比较结果指示存储时长大于或等于存储时长阈值时,生成信息发送方的发送方密钥;当时长比较结果指示存储时长小于存储时长阈值时,将候选发送方密钥,确定为信息发送方的发送方密钥,通过动态地根据存储时长与阈值的比较来生成新的密钥,可以确保密钥不会因为长时间的存储而变得不再安全。这有助于提高通信的安全性,因为即使密钥被泄露,也不会长时间地暴露在潜在的攻击者面前。允许系统根据实际情况调整存储时长阈值,从而提供灵活的密钥管理策略。不同的应用和环境可能需要不同的安全措施和密钥更新频率。存储时长小于阈值,可以避免不必要的密钥生成和更换,从而节省计算资源和时间。
在一些实施例中,上述生成信息发送方的发送方密钥之后,还可以执行如下处理:将信息发送方的发送方密钥,存储至发送方密钥库中,得到发送方密钥库对应的更新密钥库;向服务后台发送信息发送方的发送方密钥,以使服务后台将发送方密钥发送至信息接收方。
在一些实施例中,在生成新版本的信息发送方的发送方密钥之后,将信息发送方的发送方密钥,存储至发送方密钥库中,得到发送方密钥库对应的更新密钥库,从而实现发送方密钥库中的发送方密钥的版本更新。
如此,通过定期生成新版本的密钥并更新密钥库,可以实现密钥的轮换,这有助于提高通信的安全性。即使某个密钥被破解,由于密钥的频繁更换,攻击者难以利用同一密钥对多个通信会话进行攻击。更新密钥库确保了使用的密钥始终保持在其最佳安全状态。随着密码学的发展和攻击技术的进步,使用最新的加密标准和方法可以提高抵抗未来攻击的能力。在某些情况下,即使密钥没有泄露,长时间使用同一个密钥也可能使其变得不再安全。通过定期更新密钥库,可以维护密钥的新鲜度,减少密钥疲劳带来的安全风险。
在一些实施例中,在生成新版本的信息发送方的发送方密钥之后,向服务后台发送信息发送方的发送方密钥,以使服务后台将发送方密钥发送至信息接收方,从而实现信息发送方和信息接收方的密钥共享,保证信息交互的正常进行。
如此,通过在生成新版本的信息发送方的发送方密钥之后,向服务后台发送信息发送方的发送方密钥,以使服务后台将发送方密钥发送至信息接收方,通过服务后台作为中介来分发密钥,可以简化密钥的传输过程,特别是当发送方和接收方位于不同的网络或需要跨越不安全网络时,服务后台可以支持多个发送方和接收方,提供灵活的密钥服务,并且能够根据需要扩展其容量和处理能力,服务后台可以自动化密钥的分发和更新过程,减少人工干预的需求,提高系统的效率和可靠性。
在一些实施例中,参见图7,图7是本申请实施例提供的信息交互方法的流程示意图四,图4所示出的步骤101可以通过执行图7所示出的步骤1011B至步骤1013B实现。
在步骤1011B中,响应于信息发送方的信息交互请求,获取对信息发送方的发送方密钥进行加密所得到的加固密钥。
在一些实施例中,加固密钥(Hardened Key)是信息发送方的发送方密钥的加密形式,加固密钥是指通过对信息发送方的发送方密钥进行加密处理后所得到的密钥,这种加密方式可以增加密钥的安全性,确保密钥在存储和传输过程中的安全性。
作为示例,参见图13,图13是本申请实施例提供的客户端私钥安全加固的原理示意图二,加固密钥可以是图13中所示出的加密后的私钥数据,通过从信息发送方本地获取加固密钥,以便后续对加固密钥进行解密得到发送方密钥,从而在信息发送方采用加固密钥的方式对发送方密钥进行存储,从而有效提高了发送方密钥的存储安全性。
在步骤1012B中,向服务后台发送第一加密信息,以使服务后台对第一加密信息进行信息解密,得到用于对加固密钥进行解密的目标密钥。
在一些实施例中,第一加密信息是用于对加固密钥进行解密的目标密钥的加密形式,第一加密信息是指在加密通信过程中,发送方首先加密并发送给服务后台的信息,这个信息是加密通信链的起点,它通常包含了用于后续解密过程的必要信息。
作为示例,参见图13,信息发送方(图13中所示出的客服端)向服务后台发送第一加密信息(图13中所示出的加密后的随机密钥),以使服务后台通过后台密钥对第一加密信息进行信息解密,得到用于对加固密钥进行解密的目标密钥(图13中所示出的随机密钥)。
在步骤1013B中,接收服务后台返回的目标密钥,并基于目标密钥,对加固密钥进行解密,得到信息发送方的发送方密钥。
在一些实施例中,信息发送方接收服务后台返回的目标密钥,由于目标密钥用于对加固密钥进行解密,那么则基于目标密钥,对加固密钥进行解密,得到信息发送方的发送方密钥。
作为示例,参见图13,接收服务后台返回的目标密钥(图13所示出的随机密钥),并基于目标密钥,对加固密钥(图13中所示出的加密后的随机密钥)进行解密,得到信息发送方的发送方密钥(图13所示出的随机密钥)。
如此,通过响应于信息发送方的信息交互请求,获取对信息发送方的发送方密钥进行加密所得到的加固密钥,向服务后台发送第一加密信息,以使服务后台对第一加密信息进行信息解密,得到用于对加固密钥进行解密的目标密钥,接收服务后台返回的目标密钥,并基于目标密钥,对加固密钥进行解密,得到信息发送方的发送方密钥。通过加固密钥和目标密钥的双层加密机制,显著提高了密钥的安全性。即使加固密钥被泄露,目标密钥,攻击者也无法解密密钥。将密钥分为加固密钥和目标密钥两个部分,可以降低密钥泄露的风险。密钥的分段存储和传输可以减少密钥被一次性泄露的风险。通过服务后台进行密钥的管理和分发,可以提供更灵活的密钥管理策略。服务后台可以集中管理密钥,并确保密钥的安全存储和分发。服务后台对第一加密信息进行解密,确保了密钥在传输过程中的安全性。即使密钥在传输过程中被截获,没有目标密钥,攻击者也无法解密密钥。
在步骤102中,获取信息接收方的接收方密钥。
在一些实施例中,接收方密钥是指在信息接收方生成,且信息接收方自身特有的密钥。上述信息接收方的数量可以是至少一个,上述获取信息接收方的接收方密钥,可以是获取各信息接收方的接收方密钥,上述信息接收方与接收方密钥一一对应。
在一些实施例中,参见图8,图8是本申请实施例提供的信息交互方法的流程示意图五,图4所示出的步骤102可以针对各信息接收方执行图8所示出的步骤1021至步骤1023实现。
在步骤1021中,在信息发送方本地对信息接收方的接收方密钥进行查询,得到查询结果。
在一些实施例中,上述查询结果,用于指示信息发送方本地是否存储有信息接收方的接收方密钥。
在一些实施例中,在信息发送方本地对信息接收方的接收方密钥进行查询,信息发送方可以快速地确定接收方密钥的存在性和详细信息,从而有效地管理密钥并提供安全的通信服务。
在步骤1022中,当查询结果指示信息发送方本地存储有信息接收方的接收方密钥时,将接收方密钥的版本号,发送至服务后台,并接收服务后台针对版本号返回的返回信息,基于返回信息,确定信息接收方的接收方密钥。
在一些实施例中,当查询结果指示信息发送方本地存储有信息接收方的接收方密钥时,由于无法确定信息发送方本地存储的信息接收方的接收方密钥是否为最新版本的接收方密钥,因此,可以将本地存储的接收方密钥的版本号发送至服务后台,以使服务后台进行信息发送方本地存储的信息接收方的接收方密钥的版本与最新版本的比较后,返回针对版本号的返回信息,从而确定信息发送方本地存储的信息接收方的接收方密钥是否为最新版本的接收方密钥。
在一些实施例中,上述返回信息中包括用于指示版本号是否为最新版本的版本指示信息。
在一些实施例中,上述基于返回信息,确定信息接收方的接收方密钥,可以通过如下方式实现:当版本指示信息指示版本号为最新版本时,将本地存储的接收方密钥,确定为信息接收方的接收方密钥;当版本指示信息指示版本号不是最新版本时,将返回信息中携带的接收方密钥,确定为信息接收方的接收方密钥。
在一些实施例中,当版本指示信息指示版本号为最新版本时,则说明信息发送方本地存储的信息接收方的接收方密钥为最新版本的接收方密钥,那么则可以直接将本地存储的接收方密钥,确定为信息接收方的接收方密钥。
在一些实施例中,当版本指示信息指示版本号不是最新版本时,则说明信息发送方本地存储的信息接收方的接收方密钥不是最新版本的接收方密钥,那么将返回信息中携带的接收方密钥,确定为信息接收方的接收方密钥,从而保证所确定的接收方密钥为最新的版本。
如此,当版本指示信息指示版本号为最新版本时,将本地存储的接收方密钥,确定为信息接收方的接收方密钥;当版本指示信息指示版本号不是最新版本时,将返回信息中携带的接收方密钥,确定为信息接收方的接收方密钥。当版本指示信息指示版本号不是最新版本时,信息发送方可以直接使用接收方密钥,而不是从服务后台请求新的密钥,这样减少了数据传输量,提高了通信效率。确保信息接收方使用的是最新的密钥版本,可以减少由于密钥版本过时而带来的安全风险。尽管接收方密钥可以在本地存储,但仍然可以通过服务后台进行集中管理和更新,从而保证确保密钥的安全性和一致性。
在步骤1023中,当查询结果指示信息发送方本地未存储信息接收方的接收方密钥时,向服务后台发送针对信息接收方的密钥获取请求,并接收服务后台针对密钥获取请求返回的接收方密钥。
在一些实施例中,当查询结果指示信息发送方本地未存储信息接收方的接收方密钥时,此时信息发送方只能够从服务后台获取接收方密钥,可以向服务后台发送针对信息接收方的密钥获取请求,并接收服务后台针对密钥获取请求返回的接收方密钥。
如此,通过在信息发送方本地对信息接收方的接收方密钥进行查询,得到查询结果,当查询结果指示信息发送方本地存储有信息接收方的接收方密钥时,将接收方密钥的版本号,发送至服务后台,并接收服务后台针对版本号返回的返回信息,基于返回信息,确定信息接收方的接收方密钥,当查询结果指示信息发送方本地未存储信息接收方的接收方密钥时,向服务后台发送针对信息接收方的密钥获取请求,并接收服务后台针对密钥获取请求返回的接收方密钥。通过查询接收方密钥的版本号并将其发送至服务后台,可以实现接收方密钥的版本控制。这有助于确保信息发送方使用的是最新的密钥版本,从而提高通信的安全性。结合本地存储和远程服务后台的密钥管理,可以提供灵活的密钥管理策略。本地存储可以快速访问密钥,而服务后台可以集中管理和更新密钥。当查询结果指示信息发送方本地存储有信息接收方的接收方密钥时,可以直接使用本地存储的密钥,减少了向服务后台发送密钥请求的需要,从而减少数据传输量。确保信息发送方使用的是最新的密钥版本,可以减少由于密钥版本过时而带来的安全风险。
在步骤103中,按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合,得到融合密钥。
在一些实施例中,上述发送方密钥包括至少一个子发送方密钥,接收方密钥包括至少一个子接收方密钥。上述密钥融合方式可以是信息接收方和信息发送方向信息交互的管理方所获取的,且信息交互的管理方不会向服务后台发送密钥融合方式。
在一些实施例中,上述步骤103可以通过如下方式实现:按照密钥融合方式,将各子发送方密钥和各子接收方密钥进行融合,得到融合密钥。
在一些实施例中,上述子发送方密钥的数量和子接收方密钥的数量的加和,与融合密钥的加密性能正相关,上述加密性能是指融合密钥对待加密信息的加密强度,加密强度越大,采取融合密钥加密后的加密交互信息在面对强大的计算资源和复杂的攻击手段时的安全性能更高。
在一些实施例中,上述按照密钥融合方式,将各子发送方密钥和各子接收方密钥进行融合,得到融合密钥,可以通过如下方式实现:针对各子发送方密钥,将子发送方密钥分别与各子接收方密钥进行融合,得到子发送方密钥对应的至少一个初始融合密钥,并基于各初始融合密钥,确定子发送方密钥对应的中间融合密钥;将各中间融合密钥进行融合,得到融合密钥。
在一些实施例中,上述基于各初始融合密钥,确定子发送方密钥对应的中间融合密钥,可以通过如下方式实现:当初始融合密钥的数量为一个时,将初始融合密钥,确定为子发送方密钥对应的中间融合密钥;当初始融合密钥的数量为多个时,将各初始融合密钥进行融合,得到子发送方密钥对应的中间融合密钥。
作为示例,子发送方密钥包括子发送方密钥A、子发送方密钥B和子发送方密钥C,子接收方密钥包括子接收方密钥D和子接收方密钥E,针对子发送方密钥A,将子发送方密钥分别与各子接收方密钥进行融合,得到子发送方密钥对应的初始融合密钥AD和初始融合密钥AE,将各初始融合密钥,确定子发送方密钥对应的中间融合密钥ADAE,针对子发送方密钥B,将子发送方密钥分别与各子接收方密钥进行融合,得到子发送方密钥对应的初始融合密钥BD和初始融合密钥BE,针对子发送方密钥C,将子发送方密钥分别与各子接收方密钥进行融合,得到子发送方密钥对应的初始融合密钥CD和初始融合密钥CE;将各中间融合密钥进行融合,得到融合密钥ADAEBDBECDCE。
如此,针对各子发送方密钥,将子发送方密钥分别与各子接收方密钥进行融合,得到子发送方密钥对应的至少一个初始融合密钥,并基于各初始融合密钥,确定子发送方密钥对应的中间融合密钥;将各中间融合密钥进行融合,得到融合密钥,由于密钥融合方式是信息接收方和信息发送方协商确定的,密钥融合方式为信息接收方和信息发送方所私有的,因此,按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合所得到的融合密钥,服务后台对融合密钥无感知。
在步骤104中,基于融合密钥,对待交互信息进行加密,得到待交互信息对应的加密交互信息。
在一些实施例中,加密交互信息是基于融合密钥对待信息进行加密处理后得到的信息,确保了待交互信息在传输过程中的机密性和完整性。
在一些实施例中,参见图9,图9是本申请实施例提供的信息交互方法的流程示意图六,图4所示出的步骤104可以通过执行图9所示出的步骤1041至步骤1043实现。
在步骤1041中,生成初始密钥,并基于初始密钥,对待交互信息进行信息加密,得到加密信息。
在一些实施例中,上述初始密钥可以是随机生成的密钥,上述初始密钥的具体生成方式不构成对本申请实施例的限定,上述加密信息是基于初始密钥对待信息进行加密处理后得到的信息。
在步骤1042中,基于融合密钥,对初始密钥进行密钥加密,得到初始密钥对应的加密密钥。
在一些实施例中,上述加密密钥是基于融合密钥对初始密钥进行密钥加密所得到的密钥。通过基于融合密钥对初始密钥进行加密,得到加密密钥,从而使得融合密钥无法被窃取,从而使得加密信息无法被解密,从而有效保证了待交互信息的信息安全。
在步骤1043中,将加密密钥和加密信息进行信息融合,得到加密交互信息。
在一些实施例中,上述加密交互信息包括加密密钥和加密信息,从而只需知晓融合密钥,就能够通过融合密钥对加密密钥进行解密得到初始密钥,然后通过初始密钥对加密信息进行解密,得到待交互信息,从而实现信息交互双方之间的信息交互。
在步骤105中,向服务后台发送加密交互信息,以使服务后台将加密交互信息转发至信息接收方。
在一些实施例中,按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合所得到的融合密钥,服务后台对融合密钥无感知,通过基于融合密钥,对待交互信息进行加密,得到的待交互信息对应的加密交互信息,服务后台无法对加密交互信息进行解密,通过向服务后台发送加密交互信息,以使服务后台将加密交互信息转发至信息接收方,从而使得信息发送方和信息接收方之间的信息交互过程,服务后台不能够实现对待交互信息的解密,使得待交互信息在服务后台不存在安全隐患,从而有效提高了信息交互的信息安全性。
在一些实施例中,在执行上述步骤105之后,可以通过如下方式进行密钥加固:向服务后台发送针对信息发送方的发送方密钥的密钥加固请求,以使服务后台对目标密钥进行更新,并对更新得到的更新目标密钥进行加密,得到第二加密信息;接收服务后台返回的更新目标密钥和第二加密信息,基于更新目标密钥,对发送方密钥进行密钥加固,得到更新加固密钥;将加固密钥更新为更新加固密钥,并将第一加密信息,更新为第二加密信息。
在一些实施例中,基于更新目标密钥,对发送方密钥进行密钥加固,得到更新加固密钥,也即通过更新目标密钥,对发送方密钥进行密钥加密,得到更新加固密钥。
在一些实施例中,向服务后台发送针对信息发送方的发送方密钥的密钥加固请求,以使服务后台对目标密钥进行更新,并对更新得到的更新目标密钥进行加密,得到第二加密信息;接收服务后台返回的更新目标密钥和第二加密信息,基于更新目标密钥,对发送方密钥进行密钥加固,得到更新加固密钥,从而实现了在每轮会话中采取不同的密钥对发送方密钥进行加密,从而有效提高了发送方密钥在信息发送方本地的存储安全性。
如此,通过服务后台对目标密钥进行更新,并对更新后的密钥进行加密,可以确保密钥始终保持最新和最安全的状态。这有助于提高通信的安全性,防止密钥被破解。服务后台对更新后的密钥进行加密,得到第二加密信息,确保密钥在传输过程中的安全性。即使密钥在传输过程中被截获,没有正确的解密方法,攻击者也无法使用或破解密钥。基于更新后的目标密钥,对发送方密钥进行密钥加固,得到更新加固密钥。这种加固过程可以进一步增强密钥的安全性,使其更难被破解。
如此,通过按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合,得到融合密钥,基于融合密钥,对待交互信息进行加密,得到待交互信息对应的加密交互信息,向服务后台发送加密交互信息,以使服务后台将加密交互信息转发至信息接收方。如此,由于密钥融合方式是信息接收方和信息发送方协商确定的,密钥融合方式为信息接收方和信息发送方所私有的,因此,按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合所得到的融合密钥,服务后台对融合密钥无感知,通过基于融合密钥,对待交互信息进行加密,得到的待交互信息对应的加密交互信息,服务后台无法对加密交互信息进行解密,通过向服务后台发送加密交互信息,以使服务后台将加密交互信息转发至信息接收方,从而使得信息发送方和信息接收方之间的信息交互过程,服务后台不能够实现对待交互信息的解密,使得待交互信息在服务后台不存在安全隐患,从而有效提高了信息交互的信息安全性。
参见图10,图10是本申请实施例提供的信息交互方法的流程示意图七,将结合图10示出的步骤601至步骤603进行说明,本申请实施例提供的信息交互方法可以由服务器或终端单独实施,或者由服务器及终端协同实施,下面将以终端单独实施,应用于信息接收方为例进行说明。
在步骤601中,接收服务后台发送的加密交互信息,并获取信息接收方的接收方密钥以及信息发送方的发送方密钥。
在一些实施例中,上述发送方密钥是指在信息发送方生成,且信息发送方自身特有的密钥,上述接收方密钥是指在信息接收方生成,且信息接收方自身特有的密钥。
在步骤602中,按照与信息接收方协商确定的密钥融合方式,将接收方密钥和发送方密钥进行融合,得到融合密钥。
在一些实施例中,由于密钥融合方式是信息接收方和信息发送方协商确定的,密钥融合方式为信息接收方和信息发送方所私有的,因此,在信息接收方和信息发送方,按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合所得到的融合密钥是相同的。
在步骤603中,基于融合密钥,对加密交互信息进行解密,得到加密交互信息对应的待交互信息。
在一些实施例中,由于密钥融合方式是信息接收方和信息发送方协商确定的,密钥融合方式为信息接收方和信息发送方所私有的,因此,在信息接收方和信息发送方,按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合所得到的融合密钥是相同的,因此,在信息发送方能够实现对待加密信息的加密,在信息接收方能够实现对待加密信息的解密。
如此,接收服务后台发送的加密交互信息,并获取信息接收方的接收方密钥以及信息发送方的发送方密钥,按照与信息接收方协商确定的密钥融合方式,将接收方密钥和发送方密钥进行融合,得到融合密钥,基于融合密钥,对加密交互信息进行解密,得到加密交互信息对应的待交互信息。如此,由于密钥融合方式是信息接收方和信息发送方协商确定的,密钥融合方式为信息接收方和信息发送方所私有的,因此,按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合所得到的融合密钥,服务后台对融合密钥无感知,通过于融合密钥,对加密交互信息进行解密,得到加密交互信息对应的待交互信息,服务后台无法对加密交互信息进行解密,通过向服务后台发送加密交互信息,以使服务后台将加密交互信息转发至信息接收方,从而使得信息发送方和信息接收方之间的信息交互过程,服务后台不能够实现对待交互信息的解密,使得待交互信息在服务后台不存在安全隐患,从而有效提高了信息交互的信息安全性。
下面,将说明本申请实施例在一个实际的信息交互的应用场景中的示例性应用。
信息交互是信息处理和通信的基本活动,是信息系统的核心组成部分。信息交互在日常生活、工作、教育和科研等多个领域中都非常重要,它是人类社会和现代社会功能的基础。随着信息技术的发展,信息交互的方式和效率也在不断进步,为人们提供了更加便捷和高效的沟通方式。
本申请实施例提供的信息交互方法,可以在保证安全的前提下,简化了基本流程,工程上快速实现了消息端到端加密。安全上,每条消息都是独立协商出的消息密钥,前后向安全,只有发送发和接收方设备可解读消息。性能上,消息按需分发减少消息体大小,密钥复用优化策略减少性能开销。
在一些实施例中,参见图11,图11是本申请实施例提供的设置加密成员的界面示意图,可以自主选择开启/关闭端到端加密功能(例如,图11中所示出的已开启控件),并能设置使用范围,例如,加密成员包括成员A、成员B和成员C,支持单聊的端对端加密,支持群聊的端对端加密,支持离线的端对端加密聊天,即接收方不在线时,发送方也能与其进行端到端加密发送消息;后续接收方上线后,能正常解密消息,支持多设备同时使用,即每个人的多台设备均能正常加密/解密消息,如成员A发给成员B消息,成员B的多台设备都能收到加密消息,并解密。
在一些实施例中,参见图12,图12是本申请实施例提供的客户端私钥安全加固的原理示意图一,图12所示出的是客户端本地无加密后的随机密钥,请求随机密钥和加密后的随机密钥的情形,客户端向服务后台发送私钥数据加固请求,服务后台生成随机密钥,并通过后台密钥对随机密钥进行加密,得到加密后的随机密钥,并将加密后的随机密钥以及随机密钥发送至客户端,客户端通过随机密钥对私钥数据进行加密,得到加密后的私钥数据,并将加密后的私钥数据和随机密钥进行落盘存储。
在一些实施例中,参见图13,图13是本申请实施例提供的客户端私钥安全加固的原理示意图二,图13所示出的是客户端本地有加密后的随机密钥(非首次使用,之前获取过),携带本地的加密后的随机密钥请求后台解开随机密钥,并获取最新的加密后的随机密钥的情形。客户端向服务后台发送加密后的随机密钥,服务后台通过后台密钥,对加密后的随机密钥进行解密,得到随机密钥,并将随机密钥和再次加密后的随机密钥发送至客户端,客户端通过随机密钥对加密后的私钥数据进行数据解密,得到私钥数据。
在一些实施例中,参见图14,图14是本申请实施例提供的生效名单列表的原理示意图,每个企业存储着功能开关,还存储着生效名单(含成员列表、部门列表、标签列表),命中任一的成员均在生效范围内,由于含有部门列表和标签列表,判断一个成员是否在部门/标签代价很大,因此这里引入了生效名单列表(包括成员1、成员2、成员3至成员n),用于存储生效范围打散后的成员(成员列表、部门列表->成员列表、标签列表->成员列表),生效名单列表通过定时读取和检测生效范围存储层中的数据变化,以实现定时更新。
在一些实施例中,判断一个人是否在生效范围内:读取企业功能开关,若关,则认为不在。再读取打散后的生效名单列表(保存着打散后的成员列表),若不在,则认为不在。若通过了上述检查,则认为在生效范围内。用户A自身需要上传相关公钥信息(IK、SPK、OPKs),目的是为了让其联系人如用户B可以从后台获取用户的公钥,而无需用户A实时在线,即可发起加密聊天。
在一些实施例中,参见图15,图15是本申请实施例提供的密钥存储的原理示意图,以用户id(vid)为key,value保存着该用户上传的公钥信息,版本号,每次该用户的公钥信息有变更,都会提升。用于后续客户端校对本地与后台的数据是否落后。IK、SPK、OPK为图15中所示出的密钥A1、密钥A2和密钥A3,密钥B1、密钥B2和密钥B3,以及客户端设备信息和设备标识。
在一些实施例中,参见图16,图16是本申请实施例提供的信息发送方与服务后台之间的密钥更新的流程示意图,信息发送方与服务后台之间的密钥更新可以通过图16所示出的步骤201至步骤214实现。
在步骤201中,信息发送方检查更新自身公钥信息。
在一些实施例中,信息发送方检查更新自身公钥信息是指信息发送方定期或不定期地检查其公钥信息,以确保其公钥是最新的,并且与服务后台或密钥分发中心保持一致。
在步骤202中,信息发送方发送读取版本号请求至服务后台。
在一些实施例中,信息发送方发送读取版本号请求至服务后台,以使服务后台判断信息发送方的公钥信息是否为最新版本。
在步骤203中,服务后台读取版本号。
在一些实施例中,服务后台读取最新版本的公钥信息的版本号。
在步骤204中,服务后台向信息发送方返回密钥。
在一些实施例中,服务后台向信息发送方返回最新版本的公钥信息,也即密钥。
在步骤205中,信息服务方检查是否更新本地密钥。
在一些实施例中,当本地数据库中无存储时,使用curve25519生成IKa,SPKa,OPKa,生成DKa;当本地数据库有存储时,检查IK、SPK、OPK、DK是否落后,按需生成IKa、SPKa、OPKa,DKa,SPK、OPK过期则重新生成-旧的密钥对保留extra_save_interval时间;不需要重新生成则返回。
在步骤206中,当需要更新时,本地数据库向信息发送方更新返回版本号。
在一些实施例中,当不需要更新时,结束流程。本地数据库进行更新版本号查询,版本号对应的本地数据库签名:
DKSign(DKa_s,{IKa_p,OPKa_p)selfCreds=(IKa_p,SPKa_p,list(OPKa_p),DKa_p,DK_Sign),req =(seq,selfCreds)。
在步骤207中,信息发送方向本地数据库请求获取存储数据。
在一些实施例中,信息发送方向本地数据库请求获取存储数据,也即信息发送方向从本地数据库读取存储数据。
在步骤208中,本地数据库返回存储数据。
在一些实施例中,本地数据库检查需要删除的SPK、OPK,更新私钥:
secretSelfCreds= Encrypt(storekey,(IKa-s,list(SPKa_s),list(OPKa_s)});
更新公钥:
publicSelfCreds={Ka_p,list(SPKa_p),list(OPKa_p);
在步骤209中,落地存储。
在一些实施例中,落盘数据:
storeSelfCreds=(seq,secretSelfCreds,publicSelfCreds,DK,storeKeyinfo)。
在步骤210中,更新公钥信息。
在一些实施例中,信息发送方更新服务后台的公钥信息。
在步骤211中,服务后台进行有效性检查。
在一些实施例中,服务后台检查签名有效性,相同IK下检查SPK_ver、OPK_ver,提升seq,后续好友/群友定期更新比对版本号落后拉取最新数据,保存:seq、IKa_p、SPK_a、list(OPKa_p)、DK_a,返回版本号、最新相关配置项。
在步骤212中,服务后台向信息发送方返回公钥信息。
在一些实施例中,服务后台向信息发送方返回最新版本的公钥信息。
在步骤213中,进行本地数据库的更新。
在一些实施例中,本地数据库更新版本号,并标记密钥可用。
在步骤214中,重新获取存储数据,并落地存储。
在一些实施例中,下面针对信息接收方的公钥信息的获取过程进行说明,X3DH协议密钥协商需要知道接收方的IP_p、SPK_p、OPK_p,发送每条单聊消息都需要进行一次X3DH、群聊消息需要进行n(群人数-1)次X3DH。接收方相关公钥信息的获取有以下两种方式,参见下表1,下表1是本申请实施例提供的信息接收方的公钥信息的获取过程的方案示意表。
表1 信息接收方的公钥信息的获取过程的方案示意表
在一些实施例中,下面以上述方案2为例,进行说明本申请实施例中信息接收方的公钥信息的获取过程,参见图17,图17是本申请实施例提供的获取信息接收方的公钥信息的流程示意图,下面将结合图17所示出的步骤301至步骤309进行说明。
在步骤301中,信息发送方进入单聊/群聊会话定期更新。
在一些实施例中,信息发送方定期更新单聊,信息发送方定期更新群聊。
在步骤302中,信息发送方从本地数据库获取版本号。
在一些实施例中,信息发送方从本地数据库获取本地最新版本的版本号。
在步骤303中,本地数据库查询版本号。
在一些实施例中,依次获取保存在本地的memberlist成员的公钥信息(没有seq填0):
contactCred=(member_vid、seq、list(IKb_p、SPKb_ver、OPKb_ver,device_type,device_id));
contactCreds.add(contactCred);
req =(contactCreds)。
在步骤304中,信息发送方向服务后台发送加密后的随机密钥。
在一些实施例中,信息发送方向服务后台发送加密后的随机密钥,信息发送方向服务后台发送加密后的随机密钥是指信息发送方在安全的环境中生成一个随机的密钥,然后使用某种加密算法对这个随机密钥进行加密,最后将加密后的密钥发送给服务后台。
在步骤305中,服务后台进行检验关系。
在一些实施例中,单聊校验好友关系、圈子、集团架构等关系(参考chat校验关系);群聊校验head_vid和contactCreds里的member_vid都在群中。
在步骤306中,增量计算需要更新的公钥数据。
在一些实施例中,依次检查contactCreds的数据seq是否落后;计算增量更新的contactCredsUpdate=list(vid、seq、list(ik_p、SPK_p、list(OPK_p),device_type,device_id))。
在步骤307中,返回更新的随机密钥。
在一些实施例中,服务后台向信息发送方返回更新的随机密钥。
在步骤308中,信息发送方更新加固密钥。
在一些实施例中,信息发送方更新加固密钥,从而能够有效保证加固密钥的更新频率,有效提高了加固密钥的安全性能。
在步骤309中,本地数据库返回加固密钥,并落地存储。
在一些实施例中,参见图18,图18是本申请实施例提供的信息交互方法的流程示意图八,本申请实施例提供的信息交互方法可以通过图18所示出的步骤401至步骤425实现。
在步骤401中,信息发送方向服务后台上传/更新密钥。
在一些实施例中,信息发送方向服务后台上传/更新密钥,服务后台向信息发送方返回密钥。
在步骤402中,信息接收方A向服务后台上传/更新密钥。
在一些实施例中,信息接收方A向服务后台上传/更新密钥,服务后台向信息接收方A返回密钥。
在步骤403中,信息接收方B向服务后台上传/更新密钥。
在一些实施例中,信息接收方B向服务后台上传/更新密钥,服务后台向信息接收方B返回密钥。
在步骤404中,信息发送方向服务后台获取会话成员密钥。
在一些实施例中,信息发送方,以及信息发送方的其他设备向服务后台获取会话成员密钥。
在步骤405中,服务后台向信息发送方返回会话成员密钥。
在一些实施例中,服务后台向信息发送方返回信息接收方的接收方密钥。
在步骤406中,当部分会话成员无有效密钥时,进行无加密聊天。
在一些实施例中,当部分会话成员无有效密钥时,则无需对待交互信息进行加密,进行无加密聊天。
在步骤407中,信息发送方随机生成消息密钥。
在一些实施例中,信息发送方可以随机生成消息密钥,也可以采取其他方式生成消息密钥,消息密钥的具体生成方式不构成对本申请实施例的限定。
在步骤408中,生成加密消息。
在一些实施例中,生成加密消息 encryptMsg=aes_gcm(senderkey,msg)。
在步骤409中,生成协商密钥。
在一些实施例中,生成协商密钥:
key=KDF(X3DH(IKpri_a,EK_pri_a,IK_pub_b,SPK_pub_b,OPK_pub_b)
在步骤410中,生成加密密钥。
在一些实施例中,生成加密密钥:encrypt_senderkey=aes_hcm(key,senderkey)。
在步骤411中,进行信息加密。
在一些实施例中,进行信息加密:
receiver_creds.add(vidb,Ik_pub_b,SPK_ver_b,OPK_ver_b,encrypt_senderkey,device_b)。
在步骤412中,信息发送方向服务后台发送加密消息。
在一些实施例中,信息发送方向服务后台发送加密消息,以使服务后台进行加密消息的转发。
在步骤413中,服务后台插入发送方存储。
在一些实施例中,服务后台将信息发送方发送的加密信息进行存储。
在步骤414中,异步扩散。
在一些实施例中,信息发送方将待交互信息扩散到信息发送方对应的多台设备中。
在步骤415中,信息接收方返回信息。
在一些实施例中,信息接收方返回信息至服务后台。
在步骤416中,信息接收方返回信息。
在一些实施例中,服务后台将信息接收方返回的信息返回至信息发送方。
在步骤417中,从receiver_creds过滤自身vid的密钥信息。
在一些实施例中,从receiver_creds过滤自身vid的密钥信息是指在处理接收方凭证(receiver_creds)时,只选择与自身虚拟标识符(vid)相关的密钥信息。
在步骤418中,插入接收方存储。
在一些实施例中,信息接收方对密钥信息进行落地存储。
在步骤419中,信息接收方A拉消息。
在一些实施例中,信息接收方A获取消息。
在步骤420中,遍历消息列表中的端到端加密消息,泣滤指定deviceid的密钥(无则为空)。
在步骤421中,服务后台返回信息。
在一些实施例中,服务后台向信息接收方A返回消息。
在步骤422中,检查IK、SPK_ver、OPK_ver是否存在;不存在解密失败。
在一些实施例中,信息接收方检查IK、SPK_ver、OPK_ver是否存在,当不存在时,则信息接收方的解密失败。
在步骤423中,计算协商密钥。
在一些实施例中,按照协商确定的融合方式,对发送方密钥和接收方密钥进行融合,得到协商密钥。
在一些实施例中,计算协商密钥:
key=KDF(X3DH(IK_pub,EK_pub_a,IK_pri_b,SPK_pri_b,OPK_pri_b))。
步骤424:解出消息密钥。
在一些实施例中,解出消息密钥:
senderkey=aes_gcm_decrypt(key,encrypt_senderkey)。
步骤425:解密消息。
在一些实施例中,解密消息:msg=aes_gcm_decrypt(senderkey,encrypt_msg)。
在一些实施例中,参见图19,图19是本申请实施例提供的多设备进行信息交互的原理示意图。支持多设备(一个主设备,多个附设备)同时登陆使用,因此需要支持多设备同时进行端对端加密聊天。发送方的多台设备(A设备)均可收发端对端加密消息。接收方的多台设备(B设备)均可收到端对端加密消息。在发消息时,也把自身的其他设备当成接收方即可,与其进行协商加密扩散即可。设备数量的维护,对于每个用户,后台最多保存指定数量设备的公钥信息,避免无限扩增。当数量超限时,选择不在线的设备且按时间选择较久的设备,进行淘汰。A设备向B设备发送消息,可以将消息扩散到A设备中的设备1、设备2以及B设备中的设备3和设备4。
如此,企业可以指定成员使用端到端加密,加密成员的设备自行生成和存储消息密钥,聊天成员外任何第三方(包括后台)均无法获取密钥和解密消息,以更全面地保障消息在传输和存储过程中的安全性。
可以理解的是,在本申请实施例中,涉及到待交互信息等相关的数据,当本申请实施例运用到具体产品或技术中时,需要获得用户许可或者同意,且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
下面继续说明本申请实施例提供的信息交互装置455的实施为软件模块的示例性结构,在一些实施例中,如图2所示,存储在存储器450的信息交互装置455中的软件模块可以包括:获取模块,用于获取信息发送方的发送方密钥,并获取信息接收方的接收方密钥;融合模块,用于按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合,得到融合密钥;加密模块,用于基于融合密钥,对待交互信息进行加密,得到待交互信息对应的加密交互信息;发送模块,用于向服务后台发送加密交互信息,以使服务后台将加密交互信息转发至信息接收方。
在一些实施例中,上述信息交互装置,还包括:认证模块,用于获取能够与信息发送方会话的多个认证接收方,并获取信息发送方所对应的至少一个候选接收方;针对各候选接收方,将候选接收方分别与各认证接收方进行比较,当比较结果指示多个认证接收方中存在候选接收方时,将候选接收方确定为信息接收方。
在一些实施例中,上述获取模块,还用于针对各信息接收方分别执行以下处理:在信息发送方本地对信息接收方的接收方密钥进行查询,得到查询结果;当查询结果指示信息发送方本地存储有信息接收方的接收方密钥时,将接收方密钥的版本号,发送至服务后台,并接收服务后台针对版本号返回的返回信息,基于返回信息,确定信息接收方的接收方密钥;当查询结果指示信息发送方本地未存储信息接收方的接收方密钥时,向服务后台发送针对信息接收方的密钥获取请求,并接收服务后台针对密钥获取请求返回的接收方密钥。
在一些实施例中,上述返回信息中包括用于指示版本号是否为最新版本的版本指示信息,上述获取模块,还用于当版本指示信息指示版本号为最新版本时,将本地存储的接收方密钥,确定为信息接收方的接收方密钥;当版本指示信息指示版本号不是最新版本时,将返回信息中携带的接收方密钥,确定为信息接收方的接收方密钥。
在一些实施例中,上述获取模块,还用于获取发送方密钥库,发送方密钥库用于供信息发送方进行密钥存储;当发送方密钥库中未存储任何版本的发送方密钥时,生成发送方密钥;当发送方密钥库中存储有至少一个版本的发送方密钥时,将发送方密钥库中最新版本的发送方密钥,确定为候选发送方密钥;获取候选发送方密钥在发送方密钥库中的存储时长,基于存储时长,确定信息发送方的发送方密钥。
在一些实施例中,上述获取模块,还用于将存储时长与存储时长阈值进行比较,得到时长比较结果;当时长比较结果指示存储时长大于或等于存储时长阈值时,生成信息发送方的发送方密钥;当时长比较结果指示存储时长小于存储时长阈值时,将候选发送方密钥,确定为信息发送方的发送方密钥。
在一些实施例中,上述获取模块,还用于将信息发送方的发送方密钥,存储至发送方密钥库中,得到发送方密钥库对应的更新密钥库;向服务后台发送信息发送方的发送方密钥,以使服务后台将发送方密钥发送至信息接收方。
在一些实施例中,上述获取模块,还用于响应于信息发送方的信息交互请求,获取对信息发送方的发送方密钥进行加密所得到的加固密钥;向服务后台发送第一加密信息,以使服务后台对第一加密信息进行信息解密,得到用于对加固密钥进行解密的目标密钥;接收服务后台返回的目标密钥,并基于目标密钥,对加固密钥进行解密,得到信息发送方的发送方密钥。
在一些实施例中,上述信息交互装置,还包括:加固模块,用于向服务后台发送针对信息发送方的发送方密钥的密钥加固请求,以使服务后台对目标密钥进行更新,并对更新得到的更新目标密钥进行加密,得到第二加密信息;接收服务后台返回的更新目标密钥和第二加密信息,基于更新目标密钥,对发送方密钥进行密钥加固,得到更新加固密钥;将加固密钥更新为更新加固密钥,并将第一加密信息,更新为第二加密信息。
在一些实施例中,发送方密钥包括至少一个子发送方密钥,接收方密钥包括至少一个子接收方密钥,上述融合模块,还用于按照密钥融合方式,将各子发送方密钥和各子接收方密钥进行融合,得到融合密钥;其中,子发送方密钥的数量和子接收方密钥的数量的加和,与融合密钥的加密性能正相关。
在一些实施例中,上述融合模块,还用于针对各子发送方密钥,将子发送方密钥分别与各子接收方密钥进行融合,得到子发送方密钥对应的至少一个初始融合密钥,并基于各初始融合密钥,确定子发送方密钥对应的中间融合密钥;将各中间融合密钥进行融合,得到融合密钥。
在一些实施例中,上述加密模块,还用于生成初始密钥,并基于初始密钥,对待交互信息进行信息加密,得到加密信息;基于融合密钥,对初始密钥进行密钥加密,得到初始密钥对应的加密密钥;将加密密钥和加密信息进行信息融合,得到加密交互信息。
下面继续说明本申请实施例提供的信息交互装置555的实施为软件模块的示例性结构,在一些实施例中,如图3所示,存储在存储器550的信息交互装置555中的软件模块可以包括:接收模块,用于接收服务后台发送的加密交互信息,并获取信息接收方的接收方密钥以及信息发送方的发送方密钥;融合模块,用于按照与信息接收方协商确定的密钥融合方式,将接收方密钥和发送方密钥进行融合,得到融合密钥;解密模块,用于基于融合密钥,对加密交互信息进行解密,得到加密交互信息对应的待交互信息。
本申请实施例提供了一种计算机程序产品,该计算机程序产品包括计算机程序或计算机可执行指令,该计算机程序或计算机可执行指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机可执行指令,处理器执行该计算机可执行指令,使得该电子设备执行本申请实施例上述的信息交互方法。
本申请实施例提供一种存储有计算机可执行指令的计算机可读存储介质,其中存储有计算机可执行指令,当计算机可执行指令被处理器执行时,将引起处理器执行本申请实施例提供的信息交互方法,例如,如图4示出的信息交互方法。
在一些实施例中,计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器;也可以是包括上述存储器之一或任意组合的各种电子设备。
在一些实施例中,计算机可执行指令可以采用程序、软件、软件模块、脚本或代码的形式,按任意形式的编程语言(包括编译或解释语言,或者声明性或过程性语言)来编写,并且其可按任意形式部署,包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
作为示例,计算机可执行指令可以但不一定对应于文件系统中的文件,可以可被存储在保存其它程序或数据的文件的一部分,例如,存储在超文本标记语言(HTML,HyperText Markup Language)文档中的一个或多个脚本中,存储在专用于所讨论的程序的单个文件中,或者,存储在多个协同文件(例如,存储一个或多个模块、子程序或代码部分的文件)中。
作为示例,计算机可执行指令可被部署为在一个电子设备上执行,或者在位于一个地点的多个电子设备上执行,又或者,在分布在多个地点且通过通信网络互连的多个电子设备上执行。
综上,本申请实施例具有如下有益效果:
(1)通过按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合,得到融合密钥,基于融合密钥,对待交互信息进行加密,得到待交互信息对应的加密交互信息,向服务后台发送加密交互信息,以使服务后台将加密交互信息转发至信息接收方。如此,由于密钥融合方式是信息接收方和信息发送方协商确定的,密钥融合方式为信息接收方和信息发送方所私有的,因此,按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合所得到的融合密钥,服务后台对融合密钥无感知,通过基于融合密钥,对待交互信息进行加密,得到的待交互信息对应的加密交互信息,服务后台无法对加密交互信息进行解密,通过向服务后台发送加密交互信息,以使服务后台将加密交互信息转发至信息接收方,从而使得信息发送方和信息接收方之间的信息交互过程,服务后台不能够实现对待交互信息的解密,使得待交互信息在服务后台不存在安全隐患,从而有效提高了信息交互的信息安全性。
(2)获取能够与信息发送方会话的多个认证接收方,并获取信息发送方所对应的至少一个候选接收方,针对各候选接收方,将候选接收方分别与各认证接收方进行比较,当比较结果指示多个认证接收方中存在候选接收方时,将候选接收方确定为信息接收方,从而通过确保只有经过认证的接收方能够与发送方会话,可以显著提高通信的安全性,有助于防止未授权的访问和数据泄露,认证接收方的机制可以帮助保护用户的隐私,确保待交互信息只被授权的接收方看到,从而有效提高了信息交互的信息安全性。
(3)通过将存储时长与存储时长阈值进行比较,得到时长比较结果;当时长比较结果指示存储时长大于或等于存储时长阈值时,生成信息发送方的发送方密钥;当时长比较结果指示存储时长小于存储时长阈值时,将候选发送方密钥,确定为信息发送方的发送方密钥,通过动态地根据存储时长与阈值的比较来生成新的密钥,可以确保密钥不会因为长时间的存储而变得不再安全。这有助于提高通信的安全性,因为即使密钥被泄露,也不会长时间地暴露在潜在的攻击者面前。允许系统根据实际情况调整存储时长阈值,从而提供灵活的密钥管理策略。不同的应用和环境可能需要不同的安全措施和密钥更新频率。存储时长小于阈值,可以避免不必要的密钥生成和更换,从而节省计算资源和时间。
(4)通过定期生成新版本的密钥并更新密钥库,可以实现密钥的轮换,这有助于提高通信的安全性。即使某个密钥被破解,由于密钥的频繁更换,攻击者难以利用同一密钥对多个通信会话进行攻击。更新密钥库确保了使用的密钥始终保持在其最佳安全状态。随着密码学的发展和攻击技术的进步,使用最新的加密标准和方法可以提高抵抗未来攻击的能力。在某些情况下,即使密钥没有泄露,长时间使用同一个密钥也可能使其变得不再安全。通过定期更新密钥库,可以维护密钥的新鲜度,减少密钥疲劳带来的安全风险。
(5)在生成新版本的信息发送方的发送方密钥之后,向服务后台发送信息发送方的发送方密钥,以使服务后台将发送方密钥发送至信息接收方,从而实现信息发送方和信息接收方的密钥共享,保证信息交互的正常进行。
(6)通过在生成新版本的信息发送方的发送方密钥之后,向服务后台发送信息发送方的发送方密钥,以使服务后台将发送方密钥发送至信息接收方,通过服务后台作为中介来分发密钥,可以简化密钥的传输过程,特别是当发送方和接收方位于不同的网络或需要跨越不安全网络时,服务后台可以支持多个发送方和接收方,提供灵活的密钥服务,并且能够根据需要扩展其容量和处理能力,服务后台可以自动化密钥的分发和更新过程,减少人工干预的需求,提高系统的效率和可靠性。
(7)通过从信息发送方本地获取加固密钥,以便后续对加固密钥进行解密得到发送方密钥,从而在信息发送方采用加固密钥的方式对发送方密钥进行存储,从而有效提高了发送方密钥的存储安全性。
(8)通过响应于信息发送方的信息交互请求,获取对信息发送方的发送方密钥进行加密所得到的加固密钥,向服务后台发送第一加密信息,以使服务后台对第一加密信息进行信息解密,得到用于对加固密钥进行解密的目标密钥,接收服务后台返回的目标密钥,并基于目标密钥,对加固密钥进行解密,得到信息发送方的发送方密钥。通过加固密钥和目标密钥的双层加密机制,显著提高了密钥的安全性。即使加固密钥被泄露,目标密钥,攻击者也无法解密密钥。将密钥分为加固密钥和目标密钥两个部分,可以降低密钥泄露的风险。密钥的分段存储和传输可以减少密钥被一次性泄露的风险。通过服务后台进行密钥的管理和分发,可以提供更灵活的密钥管理策略。服务后台可以集中管理密钥,并确保密钥的安全存储和分发。服务后台对第一加密信息进行解密,确保了密钥在传输过程中的安全性。即使密钥在传输过程中被截获,没有目标密钥,攻击者也无法解密密钥。
(9)当版本指示信息指示版本号为最新版本时,将本地存储的接收方密钥,确定为信息接收方的接收方密钥;当版本指示信息指示版本号不是最新版本时,将返回信息中携带的接收方密钥,确定为信息接收方的接收方密钥。当版本指示信息指示版本号不是最新版本时,信息发送方可以直接使用接收方密钥,而不是从服务后台请求新的密钥。这减少了数据传输量,提高了通信效率。确保信息接收方使用的是最新的密钥版本,可以减少由于密钥版本过时而带来的安全风险。尽管接收方密钥可以在本地存储,但仍然可以通过服务后台进行集中管理和更新,从而保证确保密钥的安全性和一致性。
(10)通过在信息发送方本地对信息接收方的接收方密钥进行查询,得到查询结果,当查询结果指示信息发送方本地存储有信息接收方的接收方密钥时,将接收方密钥的版本号,发送至服务后台,并接收服务后台针对版本号返回的返回信息,基于返回信息,确定信息接收方的接收方密钥,当查询结果指示信息发送方本地未存储信息接收方的接收方密钥时,向服务后台发送针对信息接收方的密钥获取请求,并接收服务后台针对密钥获取请求返回的接收方密钥。通过查询接收方密钥的版本号并将其发送至服务后台,可以实现接收方密钥的版本控制。这有助于确保信息发送方使用的是最新的密钥版本,从而提高通信的安全性。结合本地存储和远程服务后台的密钥管理,可以提供灵活的密钥管理策略。本地存储可以快速访问密钥,而服务后台可以集中管理和更新密钥。当查询结果指示信息发送方本地存储有信息接收方的接收方密钥时,可以直接使用本地存储的密钥,减少了向服务后台发送密钥请求的需要,从而减少数据传输量。确保信息发送方使用的是最新的密钥版本,可以减少由于密钥版本过时而带来的安全风险。
(11)企业可以指定成员使用端到端加密,加密成员的设备自行生成和存储消息密钥,聊天成员外任何第三方(包括后台)均无法获取密钥和解密消息,以更全面地保障消息在传输和存储过程中的安全性。
(12)向服务后台发送针对信息发送方的发送方密钥的密钥加固请求,以使服务后台对目标密钥进行更新,并对更新得到的更新目标密钥进行加密,得到第二加密信息;接收服务后台返回的更新目标密钥和第二加密信息,基于更新目标密钥,对发送方密钥进行密钥加固,得到更新加固密钥,从而实现了在每轮会话中采取不同的密钥对发送方密钥进行加密,从而有效提高了发送方密钥在信息发送方本地的存储安全性。
(13)通过服务后台对目标密钥进行更新,并对更新后的密钥进行加密,可以确保密钥始终保持最新和最安全的状态。这有助于提高通信的安全性,防止密钥被破解。服务后台对更新后的密钥进行加密,得到第二加密信息,确保密钥在传输过程中的安全性。即使密钥在传输过程中被截获,没有正确的解密方法,攻击者也无法使用或破解密钥。基于更新后的目标密钥,对发送方密钥进行密钥加固,得到更新加固密钥。这种加固过程可以进一步增强密钥的安全性,使其更难被破解。
(13)由于密钥融合方式是信息接收方和信息发送方协商确定的,密钥融合方式为信息接收方和信息发送方所私有的,因此,在信息接收方和信息发送方,按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合所得到的融合密钥是相同的,因此,在信息发送方能够实现对待加密信息的加密,在信息接收方能够实现对待加密信息的解密。
(14)接收服务后台发送的加密交互信息,并获取信息接收方的接收方密钥以及信息发送方的发送方密钥,按照与信息接收方协商确定的密钥融合方式,将接收方密钥和发送方密钥进行融合,得到融合密钥,基于融合密钥,对加密交互信息进行解密,得到加密交互信息对应的待交互信息。如此,由于密钥融合方式是信息接收方和信息发送方协商确定的,密钥融合方式为信息接收方和信息发送方所私有的,因此,按照与信息接收方协商确定的密钥融合方式,将发送方密钥和接收方密钥进行融合所得到的融合密钥,服务后台对融合密钥无感知,通过于融合密钥,对加密交互信息进行解密,得到加密交互信息对应的待交互信息,服务后台无法对加密交互信息进行解密,通过向服务后台发送加密交互信息,以使服务后台将加密交互信息转发至信息接收方,从而使得信息发送方和信息接收方之间的信息交互过程,服务后台不能够实现对待交互信息的解密,使得待交互信息在服务后台不存在安全隐患,从而有效提高了信息交互的信息安全性。
以上所述,仅为本申请的实施例而已,并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等,均包含在本申请的保护范围之内。

Claims (18)

1.一种信息交互方法,其特征在于,应用于信息发送方,所述方法包括:
获取所述信息发送方的发送方密钥,并获取信息接收方的接收方密钥;
按照与所述信息接收方协商确定的密钥融合方式,将所述发送方密钥和所述接收方密钥进行融合,得到融合密钥;
基于所述融合密钥,对待交互信息进行加密,得到所述待交互信息对应的加密交互信息;
向服务后台发送所述加密交互信息,以使所述服务后台将所述加密交互信息转发至所述信息接收方。
2.根据权利要求1所述的方法,其特征在于,所述获取所述信息发送方的发送方密钥之前,所述方法还包括:
获取能够与所述信息发送方会话的多个认证接收方,并获取所述信息发送方所对应的至少一个候选接收方;
针对各所述候选接收方,将所述候选接收方分别与各所述认证接收方进行比较,当比较结果指示所述多个认证接收方中存在所述候选接收方时,将所述候选接收方确定为所述信息接收方。
3.根据权利要求1所述的方法,其特征在于,所述获取信息接收方的接收方密钥,包括:
针对各所述信息接收方分别执行以下处理:
在所述信息发送方本地对所述信息接收方的接收方密钥进行查询,得到查询结果;
当所述查询结果指示所述信息发送方本地存储有所述信息接收方的接收方密钥时,将所述接收方密钥的版本号,发送至所述服务后台,并接收所述服务后台针对所述版本号返回的返回信息,基于所述返回信息,确定所述信息接收方的接收方密钥;
当所述查询结果指示所述信息发送方本地未存储所述信息接收方的接收方密钥时,向所述服务后台发送针对所述信息接收方的密钥获取请求,并接收所述服务后台针对所述密钥获取请求返回的所述接收方密钥。
4.根据权利要求3所述的方法,其特征在于,所述返回信息中包括用于指示所述版本号是否为最新版本的版本指示信息,所述基于所述返回信息,确定所述信息接收方的接收方密钥,包括:
当所述版本指示信息指示所述版本号为最新版本时,将本地存储的接收方密钥,确定为所述信息接收方的接收方密钥;
当所述版本指示信息指示所述版本号不是最新版本时,将所述返回信息中携带的接收方密钥,确定为所述信息接收方的接收方密钥。
5.根据权利要求1所述的方法,其特征在于,所述获取所述信息发送方的发送方密钥,包括:
获取发送方密钥库,所述发送方密钥库用于供所述信息发送方进行密钥存储;
当所述发送方密钥库中未存储任何版本的发送方密钥时,生成所述发送方密钥;
当所述发送方密钥库中存储有至少一个版本的发送方密钥时,将所述发送方密钥库中最新版本的发送方密钥,确定为候选发送方密钥;
获取所述候选发送方密钥在所述发送方密钥库中的存储时长,基于所述存储时长,确定所述信息发送方的发送方密钥。
6.根据权利要求5所述的方法,其特征在于,所述基于所述存储时长,确定所述信息发送方的发送方密钥,包括:
将所述存储时长与存储时长阈值进行比较,得到时长比较结果;
当所述时长比较结果指示所述存储时长大于或等于所述存储时长阈值时,生成所述信息发送方的发送方密钥;
当所述时长比较结果指示所述存储时长小于所述存储时长阈值时,将所述候选发送方密钥,确定为所述信息发送方的发送方密钥。
7.根据权利要求6所述的方法,其特征在于,所述生成所述信息发送方的发送方密钥之后,所述方法还包括:
将所述信息发送方的发送方密钥,存储至所述发送方密钥库中,得到所述发送方密钥库对应的更新密钥库;
向所述服务后台发送所述信息发送方的发送方密钥,以使所述服务后台将所述发送方密钥发送至所述信息接收方。
8.根据权利要求1所述的方法,其特征在于,所述获取所述信息发送方的发送方密钥,包括:
响应于所述信息发送方的信息交互请求,获取对所述信息发送方的发送方密钥进行加密所得到的加固密钥;
向所述服务后台发送第一加密信息,以使所述服务后台对所述第一加密信息进行信息解密,得到用于对所述加固密钥进行解密的目标密钥;
接收所述服务后台返回的所述目标密钥,并基于所述目标密钥,对所述加固密钥进行解密,得到所述信息发送方的发送方密钥。
9.根据权利要求8所述的方法,其特征在于,所述向服务后台发送所述加密交互信息,以使所述服务后台将所述加密交互信息转发至所述信息接收方之后,所述方法还包括:
向所述服务后台发送针对所述信息发送方的发送方密钥的密钥加固请求,以使所述服务后台对所述目标密钥进行更新,并对更新得到的更新目标密钥进行加密,得到第二加密信息;
接收所述服务后台返回的所述更新目标密钥和所述第二加密信息,基于所述更新目标密钥,对所述发送方密钥进行密钥加固,得到更新加固密钥;
将所述加固密钥更新为所述更新加固密钥,并将所述第一加密信息,更新为所述第二加密信息。
10.根据权利要求1所述的方法,其特征在于,所述发送方密钥包括至少一个子发送方密钥,所述接收方密钥包括至少一个子接收方密钥,所述按照与所述信息接收方协商确定的密钥融合方式,将所述发送方密钥和所述接收方密钥进行融合,得到融合密钥,包括:
按照所述密钥融合方式,将各所述子发送方密钥和各所述子接收方密钥进行融合,得到所述融合密钥;
其中,所述子发送方密钥的数量和所述子接收方密钥的数量的加和,与所述融合密钥的加密性能正相关。
11.根据权利要求10所述的方法,其特征在于,所述按照所述密钥融合方式,将各所述子发送方密钥和各所述子接收方密钥进行融合,得到所述融合密钥,包括:
针对各所述子发送方密钥,将所述子发送方密钥分别与各所述子接收方密钥进行融合,得到所述子发送方密钥对应的至少一个初始融合密钥,并基于各所述初始融合密钥,确定子发送方密钥对应的中间融合密钥;
将各所述中间融合密钥进行融合,得到所述融合密钥。
12.根据权利要求1所述的方法,其特征在于,所述基于所述融合密钥,对待交互信息进行加密,得到所述待交互信息对应的加密交互信息,包括:
生成初始密钥,并基于所述初始密钥,对所述待交互信息进行信息加密,得到加密信息;
基于所述融合密钥,对所述初始密钥进行密钥加密,得到所述初始密钥对应的加密密钥;
将所述加密密钥和所述加密信息进行信息融合,得到所述加密交互信息。
13.一种信息交互方法,其特征在于,应用于信息接收方,所述方法包括:
接收服务后台发送的加密交互信息,并获取所述信息接收方的接收方密钥以及信息发送方的发送方密钥;
按照与所述信息接收方协商确定的密钥融合方式,将所述接收方密钥和所述发送方密钥进行融合,得到融合密钥;
基于所述融合密钥,对所述加密交互信息进行解密,得到所述加密交互信息对应的待交互信息。
14.一种信息交互装置,其特征在于,应用于信息发送方,所述装置包括:
获取模块,用于获取所述信息发送方的发送方密钥,并获取信息接收方的接收方密钥;
融合模块,用于按照与所述信息接收方协商确定的密钥融合方式,将所述发送方密钥和所述接收方密钥进行融合,得到融合密钥;
加密模块,用于基于所述融合密钥,对待交互信息进行加密,得到所述待交互信息对应的加密交互信息;
发送模块,用于向服务后台发送所述加密交互信息,以使所述服务后台将所述加密交互信息转发至所述信息接收方。
15.一种信息交互装置,其特征在于,应用于信息接收方,所述装置包括:
接收模块,用于接收服务后台发送的加密交互信息,并获取所述信息接收方的接收方密钥以及信息发送方的发送方密钥;
融合模块,用于按照与所述信息接收方协商确定的密钥融合方式,将所述接收方密钥和所述发送方密钥进行融合,得到融合密钥;
解密模块,用于基于所述融合密钥,对所述加密交互信息进行解密,得到所述加密交互信息对应的待交互信息。
16.一种电子设备,其特征在于,所述电子设备包括:
存储器,用于存储计算机可执行指令或者计算机程序;
处理器,用于执行所述存储器中存储的计算机可执行指令或者计算机程序时,实现权利要求1至13任一项所述的信息交互方法。
17.一种计算机可读存储介质,存储有计算机可执行指令,其特征在于,所述计算机可执行指令被处理器执行时实现权利要求1至13任一项所述的信息交互方法。
18.一种计算机程序产品,包括计算机程序或计算机可执行指令,其特征在于,所述计算机程序或计算机可执行指令被处理器执行时实现权利要求1至13任一项所述的信息交互方法。
CN202410431494.2A 2024-04-11 2024-04-11 信息交互方法、装置、电子设备、存储介质及程序产品 Pending CN118041695A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410431494.2A CN118041695A (zh) 2024-04-11 2024-04-11 信息交互方法、装置、电子设备、存储介质及程序产品

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202410431494.2A CN118041695A (zh) 2024-04-11 2024-04-11 信息交互方法、装置、电子设备、存储介质及程序产品

Publications (1)

Publication Number Publication Date
CN118041695A true CN118041695A (zh) 2024-05-14

Family

ID=90989634

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202410431494.2A Pending CN118041695A (zh) 2024-04-11 2024-04-11 信息交互方法、装置、电子设备、存储介质及程序产品

Country Status (1)

Country Link
CN (1) CN118041695A (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190020631A1 (en) * 2017-07-12 2019-01-17 Wickr Inc. Sending Secure Communications Using A Local Ephemeral Key Pool
CN111478911A (zh) * 2020-04-10 2020-07-31 苏州极光无限信息技术有限公司 一种采用轻量化密钥交换算法的即时通信加密方法
CN115118458A (zh) * 2022-05-31 2022-09-27 腾讯科技(深圳)有限公司 数据处理方法、装置、计算机设备及存储介质
CN116668137A (zh) * 2023-06-06 2023-08-29 浪潮云洲(山东)工业互联网有限公司 一种工业互联网设备间端到端加密通信方法、设备及介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190020631A1 (en) * 2017-07-12 2019-01-17 Wickr Inc. Sending Secure Communications Using A Local Ephemeral Key Pool
CN111478911A (zh) * 2020-04-10 2020-07-31 苏州极光无限信息技术有限公司 一种采用轻量化密钥交换算法的即时通信加密方法
CN115118458A (zh) * 2022-05-31 2022-09-27 腾讯科技(深圳)有限公司 数据处理方法、装置、计算机设备及存储介质
CN116668137A (zh) * 2023-06-06 2023-08-29 浪潮云洲(山东)工业互联网有限公司 一种工业互联网设备间端到端加密通信方法、设备及介质

Similar Documents

Publication Publication Date Title
CN106911513B (zh) 一种基于去中心化网络的可信设备管理方法
US8196186B2 (en) Security architecture for peer-to-peer storage system
CN109327481B (zh) 一种基于区块链的全网统一在线认证方法及系统
CN1905436B (zh) 保证数据交换安全的方法
US20020191797A1 (en) Secure ephemeral decryptability
CN110225050B (zh) Jwt令牌的管理方法
CN109361663B (zh) 一种访问加密数据的相关方法、系统和相关装置
CN110932850B (zh) 通信加密方法及系统
CN112332986B (zh) 一种基于权限控制的私有加密通信方法及系统
CN109698746A (zh) 基于主密钥协商生成绑定设备的子密钥的方法和系统
US11936689B2 (en) Transmission of data or messages on board a vehicle using a SOME/IP communication protocol
CN110519222B (zh) 基于一次性非对称密钥对和密钥卡的外网接入身份认证方法和系统
CN110581829A (zh) 通信方法及装置
US20240064143A1 (en) Methods, mediums, and systems for verifying devices in an encrypted messaging system
CN112073182A (zh) 一种基于区块链的量子密钥管理方法及系统
US11658955B1 (en) Methods, mediums, and systems for verifying devices in an encrypted messaging system
US11743035B2 (en) Methods, mediums, and systems for verifying devices in an encrypted messaging system
CN112906032B (zh) 基于cp-abe与区块链的文件安全传输方法、系统及介质
CN118041695A (zh) 信息交互方法、装置、电子设备、存储介质及程序产品
EP2668737A1 (en) Controlled security domains
CN112787821A (zh) 非对称加密Token验证方法、服务器、客户端及系统
CN112135278A (zh) 一种面向5g的d2d通信隐私保护方法
US11153087B1 (en) Hub-based token generation and endpoint selection for secure channel establishment
CN112910846B (zh) 一种基于可信第三方认证的通信方法
Dimeo et al. SoK: Multi-Device Secure Instant Messaging

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