一种加密芯片和SDK之间互信及加解密方法与装置

申请号 CN201611195997.6 申请日 2016-12-22 公开(公告)号 CN106789013A 公开(公告)日 2017-05-31
申请人 深圳新众诚科技有限公司; 发明人 金山; 王强; 何宇; 卢苇;
摘要 本 发明 公开了一种 门 锁 加密芯片和SDK之间互信及加解密方法与装置。所述方法包括:SDK通过蓝牙与门锁的BLE建立连接;SDK与BLE进行互信认证:建立连接之后SDK根据预先约定好的加密密钥和加密方式将数据传输给BLE,BLE根据预先约定的密钥进行数据解密,根据获得的数据进行验证并返回给SDK互信数据,SDK对返回的数据进行认证,认证通过之后互信认证连接完成建立;BLE缓存并返回密钥;SDK接收返回的密钥并缓存,为后续数据传输加密提供密钥;SDK与BLE基于当前连接的数据传输:基于预先建立的互信连接在数据传输过程中将所有数据根据SDK接收返回的密钥进行数据加密传输。
权利要求

1.一种的加密芯片和SDK之间基于蓝牙的互信及加解密方法,其特征在于:其包括以下步骤:
SDK与BLE建立连接:SDK通过蓝牙与门锁的BLE建立连接;
SDK与BLE进行互信认证:建立连接之后SDK根据预先约定好的加密密钥和加密方式将数据传输给BLE,BLE根据预先约定的密钥进行数据解密,根据获得的数据进行验证并返回给SDK互信数据,SDK对返回的数据进行认证,认证通过之后互信认证连接完成建立;
BLE缓存并返回密钥:依据SDK与BLE进行互信认证中预先建立的互信连接,BLE将密钥缓存并传输给SDK;
SDK接收返回的密钥并缓存:SDK接收BLE返回的密钥,并加密缓存在本地,为后续数据传输加密提供密钥;
SDK与BLE基于当前连接的数据传输:基于预先建立的互信连接在数据传输过程中将所有数据根据SDK接收返回的密钥进行数据加密传输。
2.如权利要求1所述的门锁的加密芯片和SDK之间基于蓝牙的互信及加解密方法,其特征在于:互信认证需要验证请求来源是否合法,请求参数是否合法。
3.如权利要求1所述的门锁的加密芯片和SDK之间基于蓝牙的互信及加解密方法,其特征在于:SDK安装在移动通讯终端上。
4.如权利要求3所述的门锁的加密芯片和SDK之间基于蓝牙的互信及加解密方法,其特征在于:移动通讯终端为手机。
5.一种门锁的加密芯片和SDK之间基于蓝牙的互信及加解密装置,其特征在于:所述互信及加解密装置还包括:
连接建立模,用于使SDK与BLE建立连接:SDK通过蓝牙与门锁的BLE建立连接;
互信认证模块,用于使SDK与BLE进行互信认证:建立连接之后SDK根据预先约定好的加密密钥和加密方式将数据传输给BLE,BLE根据预先约定的密钥进行数据解密,根据获得的数据进行验证并返回给SDK互信数据,SDK对返回的数据进行认证,认证通过之后互信认证连接完成建立;
BLE缓存并返回密钥模块,用于使BLE缓存并返回密钥:依据SDK与BLE进行互信认证中预先建立的互信连接,BLE将密钥缓存并传输给SDK;
接收模块,用于使SDK接收返回的密钥并缓存:SDK接收BLE返回的密钥,并加密缓存在本地,为后续数据传输加密提供密钥;
数据传输模块,用于使SDK与BLE基于当前连接的数据传输:基于预先建立的互信连接在数据传输过程中将所有数据根据SDK接收返回的密钥进行数据加密传输。
6.如权利要求5所述的门锁的加密芯片和SDK之间基于蓝牙的互信及加解密装置,其特征在于:互信认证需要验证请求来源是否合法,请求参数是否合法。
7.如权利要求5所述的门锁的加密芯片和SDK之间基于蓝牙的互信及加解密装置,其特征在于:SDK安装在移动通讯终端上。
8.如权利要求7所述的门锁的加密芯片和SDK之间基于蓝牙的互信及加解密装置,其特征在于:移动通讯终端为手机。

说明书全文

一种加密芯片和SDK之间互信及加解密方法与装置

技术领域

[0001] 本发明涉及一种互信及加解密方法及其互信及加解密装置,尤其涉及一种门锁的加密芯片和SDK之间基于蓝牙的互信及加解密方法与装置。

背景技术

[0002] 随着科技的发展,尤其是计算、物联网的出现,智能家居的概念也进入公众的视线。随着社会、经济平的发展,人们对家居品质的追求也越来越高,要求家居舒适化、安全化,家居生活舒适化、智能化,对智能家居系统的需求也越来越强烈。现阶段无线智能家居表现出的技术优势在于配备基于BLE技术的智能家居,只要拿着手机就能进行远程控制家居设备。让人满意的是,它不需要扒开墙壁,布置纷繁复杂的线路,方便安装;方便组网,设备扩展性强;成本低,功耗低,符合现代家庭绿色生活理念;维修方便,可以及时有效地发现故障和维修。
[0003] 当前追求市场化运作,很多企业在研发产品的过程中考虑到各方面的原因对安全的考虑不是非常完善,从而会对用户的隐私以及财产造成损失。现阶段基于BLE的物联网设备在通过手机等可连接互联网的终端在联网过程中采用普通基于https协议的互联网请求,来获取互联网的数据;基于BLE技术进行数据传输,通常由于连接的两端均可以断开网络,在不加密的情况下数据传输相对是安全的,每次传输都是建立在当前连接的基础上进行的。
[0004] 现有的基于蓝牙的物联网网络通信仅仅依赖https和BLE连接进行数据传输,https虽然解决了传输过程中的加密,但是传输的两端依然是明文的,BLE则是明文传输。基于https的请求在请求的两端数据是明文的,在手机等终端存在获取用户隐私或安全数据的危险;基于BLE技术数据传输截获终端蓝牙嗅探器的出现,使得在使用不加密数据进行传输的时候数据会被截获并被恶意使用,会导致比较严重的后果。
[0005] 其中,缩略语和关键术语定义如下。
[0006] BLE:蓝牙低能耗技术是低成本、短距离、可互操作的鲁棒性无线技术,工作在免许可的2.4GHz ISM射频频段。BLE技术采用非常快速的连接方式,因此平时可以处于“非连接”状态(节省能源),此时链路两端相互间只是知晓对方,只有在必要时才开启链路,然后在尽可能短的时间内关闭链路。
[0007] HTTPS:HTTPS(全称:Hyper Text Transfer Protocol over Secure Socket Layer),是以安全为目标的HTTP通道,简单讲是HTTP的安全版。即HTTP下加入SSL层,HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL。
[0008] 身份认证:身份认证也称为“身份验证”或“身份鉴别”,是指在计算机及计算机网络系统中确认操作者身份的过程,从而确定该用户是否具有对某种资源的访问和使用权限,进而使计算机和网络系统的访问策略能够可靠、有效地执行,防止攻击者假冒合法用户获得资源的访问权限,保证系统和数据的安全,以及授权访问者的合法利益。

发明内容

[0009] 为了解决上述技术问题,本发明提出了一种门锁的加密芯片和SDK之间基于蓝牙的互信及加解密方法与装置,本发明能在门锁的加密芯片和SDK之间之间,将从数据存储、数据传输、数据使用过程中对数据两端进行认证和加密,从而解决数据在存储中的被窃取、数据传输中的盗用、数据使用中的篡改等安全隐患。
[0010] 本发明的解决方案是:一种门锁的加密芯片和SDK之间基于蓝牙的互信及加解密方法,其包括以下步骤:
[0011] SDK与BLE建立连接:SDK通过蓝牙与门锁的BLE建立连接;
[0012] SDK与BLE进行互信认证:建立连接之后SDK根据预先约定好的加密密钥和加密方式将数据传输给BLE,BLE根据预先约定的密钥进行数据解密,根据获得的数据进行验证并返回给SDK互信数据,SDK对返回的数据进行认证,认证通过之后互信认证连接完成建立;
[0013] BLE缓存并返回密钥:依据SDK与BLE进行互信认证中预先建立的互信连接,BLE将密钥缓存并传输给SDK;
[0014] SDK接收返回的密钥并缓存:SDK接收BLE返回的密钥,并加密缓存在本地,为后续数据传输加密提供密钥;
[0015] SDK与BLE基于当前连接的数据传输:基于预先建立的互信连接在数据传输过程中将所有数据根据SDK接收返回的密钥进行数据加密传输。
[0016] 作为上述方案的进一步改进,互信认证需要验证请求来源是否合法,请求参数是否合法。
[0017] 作为上述方案的进一步改进,SDK安装在移动通讯终端上。
[0018] 进一步地,移动通讯终端为手机。
[0019] 本发明还提供一种门锁的加密芯片和SDK之间基于蓝牙的互信及加解密装置,所述互信及加解密装置还包括:
[0020] 连接建立模,用于使SDK与BLE建立连接:SDK通过蓝牙与门锁的BLE建立连接;
[0021] 互信认证模块,用于使SDK与BLE进行互信认证:建立连接之后SDK根据预先约定好的加密密钥和加密方式将数据传输给BLE,BLE根据预先约定的密钥进行数据解密,根据获得的数据进行验证并返回给SDK互信数据,SDK对返回的数据进行认证,认证通过之后互信认证连接完成建立;
[0022] BLE缓存并返回密钥模块,用于使BLE缓存并返回密钥:依据SDK与BLE进行互信认证中预先建立的互信连接,BLE将密钥缓存并传输给SDK;
[0023] 接收模块,用于使SDK接收返回的密钥并缓存:SDK接收BLE返回的密钥,并加密缓存在本地,为后续数据传输加密提供密钥;
[0024] 数据传输模块,用于使SDK与BLE基于当前连接的数据传输:基于预先建立的互信连接在数据传输过程中将所有数据根据SDK接收返回的密钥进行数据加密传输。
[0025] 作为上述方案的进一步改进,互信认证需要验证请求来源是否合法,请求参数是否合法。
[0026] 作为上述方案的进一步改进,SDK安装在移动通讯终端上。
[0027] 进一步地,移动通讯终端为手机。
[0028] 采用本发明将更有效的保证数据传输的安全并避免用户使用过程中的盗用情况。附图说明
[0029] 图1是本发明网络安全通信系统的整体构架图。
[0030] 图2是业务系统和电子凭证系统之间的网络安全通信方法的流程图
[0031] 图3是SDK和电子凭证系统之间的网络安全通信方法的流程图。
[0032] 图4是业务系统和电子凭证系统之间的网络安全通信方法的身份认证方法的流程图。
[0033] 图5是门锁的加密芯片和SDK之间基于蓝牙的互信及加解密方法的流程图。

具体实施方式

[0034] 为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
[0035] 本发明网络安全通信系统将从数据存储、数据传输、数据使用过程中对数据两端进行认证和加密,从而解决数据在存储中的被窃取、数据传输中的盗用、数据使用中的篡改等安全隐患。因此,本发明的目的是从网络数据存储、传输、使用整个过程中解决安全问题,提供全套的安全解决方案。
[0036] 请参阅图1,本发明的网络安全通信系统用于协调业务系统、电子凭证系统、移动通信终端(如手机)之间安全通信,本发明的网络安全通信系统可作为软件APP或者插件等等形式附在电子凭证系统中,实现业务系统、电子凭证系统、手机之间的安全通信。
[0037] 本发明还可以应用在移动通讯终端如手机上,SDK是给APP的提供是一些服务用的部件,与手机内部的加密芯片实现信息交换。电子凭证系统在云端生成安全加密的电子凭证数据,通过网络加密传输,在SDK侧加密存储,然后通过SDK传输到加密芯片进行解密验证。电子凭证系统可包含Sever、API接口、Json接口、身份认证机制以及具有支持自定义数据的电子凭证数据的数据存储器
[0038] 业务系统可为给基于SDK安装在移动通讯终端上的应用程序,为提供服务的后台系统。业务系统在得到电子凭证系统的信任后,对用户请求的数据进行验证、对用户请求的合法性进行身份认证;而电子凭证系统在业务系统完成验证和认证后,才会执行相应的业务逻辑并返回给业务系统其处理结果。
[0039] 电子凭证系统本身提供了数据的安全存储,数据加密存储只有电子凭证系统通过接口程序获取数据的时候才能够正常解密,其他途径均无法查看到加密数据原始内容。
[0040] 本发明中涉及到的网络通讯在每次通讯连接建立的初始均会彼此协商加密密钥,用于通讯两端对数据交互过程中的数据进行加密和解密使用,其他环节即使截获了数据也无法得到加密密钥,从而杜绝了传输过程中的数据被窃取的险。本发明在网络通讯的过程中在首次连接建立的时候会对彼此的身份进行验证,只有在身份验证成功之后才会进行后续通讯,从而杜绝了非合法用户窃取数据的风险。本发明还在业务系统和电子凭证系统之间加入了通过业务系统参与认证的验证方式,从而使系统间的数据安全性达到最高。
[0041] 电子凭证系统在云端生成安全加密的电子凭证数据,通过网络加密传输,在手机上的SDK侧加密存储,然后通过SDK传输到手机上的加密芯片进行解密验证。
[0042] 网络安全通信系统可在API接口和业务系统之间设置互信及加解密机制一,形成业务系统和电子凭证系统之间网络安全通信装置,实现相应的网络安全通信方法。
[0043] 如图2所示,业务系统与电子凭证系统的API接口之间的通讯机制,业务系统在得到电子凭证系统的信任后对请求的数据进行验证、对请求的合法性进行身份认证;当系统完成验证和认证后才会执行相应的业务逻辑并返回给业务系统处理结果。
[0044] 网络安全通信系统还可在Json接口和SDK之间设置一个互信及加解密机制二,形成SDK和电子凭证系统之间网络安全通信装置,实现相应的网络安全通信方法。
[0045] 如图3所示,SDK与电子凭证系统的JSON接口之间的通讯机制,SDK在得到电子凭证系统的信任后,电子凭证系统对请求的数据进行验证、对请求的合法性进行身份认证;当电子凭证系统完成验证和认证后才会执行相应的业务逻辑并返回给SDK处理结果。
[0046] 网络安全通信系统还可采用业务系统的HTTPS业务认证接口在业务系统和电子凭证系统之间设置身份认证机制,形成业务系统和电子凭证系统之间网络安全通信方法的身份认证装置,实现网络安全通信方法的身份认证方法。
[0047] 如图4所示,电子凭证系统对业务系统以及SDK发起的请求进行身份认证,身份认证的依据来源于业务系统,即业务系统开放第三方系统对用户有效性检查的接口,第三方系统通过接口返回值判断是否满足条件。
[0048] 网络安全通信系统还可在SDK和加密芯片之间设置一个基于蓝牙的物联网互信及加解密机制三,形成门锁的加密芯片和SDK之间的互信及加解密装置,实现门锁的加密芯片和SDK(如手机上的SDK)之间的互信及加解密方法。
[0049] 如图5所示,SDK与加密芯片之间的通讯机制,SDK在每次与加密芯片建立连接的时候完成认证;认证完成后才会执行相应的业务逻辑并返回结果给SDK进行后续处理。
[0050] 接下去对本发明的以上设计要点进行一一详细展开说明。
[0051] 一、互信及加解密机制一(即业务系统和电子凭证系统之间网络安全通信方法及其装置)
[0052] 请参阅图2,业务系统和电子凭证系统之间网络安全通信装置包括10大模块,每大模块执行一个相应的步骤。依据这10大模块,业务系统和电子凭证系统之间网络安全通信方法的主要步骤描述:
[0053] 1、请求密钥模块,用于使业务系统请求密钥功能。
[0054] 业务系统根据预先约定好的加密密钥和加密方式进行请求参数的加密,向电子凭证系统发起https的请求。
[0055] 2、请求密钥互信认证模块,用于使电子凭证系统进行请求密钥互信认证。
[0056] 电子凭证系统接收到业务系统发起的请求密钥请求之后对请求进行互信认证,需要验证请求来源是否合法,请求参数是否合法等。如果认证成功则执行后续步骤,否则直接执行第10步。
[0057] 3、请求身份认证模块,用于使电子凭证系统进行请求密钥用户请求身份认证。
[0058] 电子凭证系统对请求参数中携带的必要信息进行用户身份认证,需要调用业务系统提供的https的接口进行验证,如果验证成功则执行后续步骤,否则直接执行第10步。
[0059] 4、计算密钥并缓存模块,用于使电子凭证系统计算密钥并缓存。
[0060] 电子凭证系统计算业务系统在建立当前连接之后的请求参数加密密钥,并对密钥数据进行时效设置和加密存储,以备后续使用。
[0061] 5、接收模块,用于使业务系统接收返回的密钥并缓存。
[0062] 业务系统接收到返回的密钥,并在业务系统中实现存储,以便在后续请求中用此密钥进行参数加密,否则后续请求在互信认证(第7步)和身份认证(第8步)无法正确被认证。
[0063] 6、业务请求模块,用于使业务系统根据密钥进行请求参数加密进行业务请求。
[0064] 业务系统根据缓存的密钥(第5步获得的密钥)对业务请求参数进行加密,并通过https方式发起业务请求。
[0065] 7、互相认证模块,用于使电子凭证系统进行互相认证。
[0066] 电子凭证系统接收到业务系统发起的业务请求之后对请求进行互信认证,需要验证请求来源是否合法,请求参数是否合法,请求参数加密方式是否合法等。如果认证成功则执行后续步骤,否则直接执行第10步。
[0067] 8、用户请求身份认证模块,用于使电子凭证系统进行用户请求身份认证。
[0068] 电子凭证系统对请求参数中携带的必要信息进行用户身份认证,需要调用业务系统提供的https的接口进行验证,如果验证成功则执行后续步骤,否则直接执行第10步。
[0069] 9、请求业务执行模块,用于使电子凭证系统进行请求业务执行。
[0070] 电子凭证系统根据业务系统的请求进行电子凭证系统的业务逻辑进行计算执行,以得到请求的结果值。
[0071] 10、返回执行结果模块,用于使电子凭证系统返回执行结果。
[0072] 电子凭证系统对请求的执行结果进行返回。
[0073] 二、互信及加解密机制二(即SDK和电子凭证系统之间的网络安全通信方法及其装置)
[0074] 请参阅图3,SDK和电子凭证系统之间的网络安全通信装置也包括10大模块,每大模块执行一个相应的步骤。依据这10大模块,手机SDK和电子凭证系统之间的网络安全通信方法的主要步骤描述:
[0075] 1、SDK请求密钥模块,用于使SDK请求密钥。
[0076] SDK根据预先约定好的加密密钥和加密方式进行请求参数的加密,向电子凭证系统发起https的请求。
[0077] 2、请求密钥互信认证模块,用于使电子凭证系统进行请求密钥互信认证。
[0078] 电子凭证系统接收到SDK发起的请求密钥请求之后对请求进行互信认证,需要验证请求来源是否合法,请求参数是否合法等。如果认证成功则执行后续步骤,否则直接执行第10步。
[0079] 3、请求身份认证模块,用于使电子凭证系统进行请求密钥用户请求身份认证。
[0080] 电子凭证系统对请求参数中携带的必要信息进行用户身份认证,需要调用SDK提供的https的接口进行验证,如果验证成功则执行后续步骤,否则直接执行第10步。
[0081] 4、计算密钥并缓存模块,用于使电子凭证系统计算密钥并缓存。
[0082] 电子凭证系统计算SDK在建立当前连接之后的请求参数加密密钥,并对密钥数据进行时效设置和加密存储,以备后续使用。
[0083] 5、接收模块,用于使SDK接收返回的密钥并缓存。
[0084] SDK接收到返回的密钥,并在SDK中实现存储,以便在后续请求中用此密钥进行参数加密,否则后续请求在互信认证(第7步)和身份认证(第8步)无法正确被认证。需要指出的是,如果基于SDK的app退出则密钥也直接失效,整个流程需要重新开始。
[0085] 6、业务请求模块,用于使SDK根据密钥进行请求参数加密进行业务请求。
[0086] SDK根据缓存的密钥(第5步获得的密钥)对业务请求参数进行加密,并通过https方式发起业务请求。
[0087] 7、互相认证模块,用于使电子凭证系统进行互相认证。
[0088] 电子凭证系统接收到SDK发起的业务请求之后对请求进行互信认证,需要验证请求来源是否合法,请求参数是否合法,请求参数加密方式是否合法等。如果认证成功则执行后续步骤,否则直接执行第10步。
[0089] 8、用户请求身份认证模块,用于使电子凭证系统进行用户请求身份认证。
[0090] 电子凭证系统对请求参数中携带的必要信息进行用户身份认证,需要调用SDK提供的https的接口进行验证,如果验证成功则执行后续步骤,否则直接执行第10步。
[0091] 9、请求业务执行模块,用于使电子凭证系统进行请求业务执行。
[0092] 电子凭证系统根据SDK的请求进行电子凭证系统的业务逻辑进行计算执行,以得到请求的结果值。
[0093] 10、返回执行结果模块,用于使电子凭证系统返回执行结果。
[0094] 电子凭证系统对请求的执行结果进行返回。
[0095] 三、互信加解密机制三(即门锁的加密芯片和SDK之间基于蓝牙的物联网互信及加解密方法及其装置)
[0096] 请参阅图4,门锁的加密芯片和SDK之间基于蓝牙的互信及加解密装置包括5大模块,每大模块执行一个相应的步骤。依据这5大模块,门锁的加密芯片和SDK之间的互信及加解密方法的主要步骤描述:
[0097] 1、连接建立模块,用于使SDK与BLE建立连接。
[0098] SDK通过蓝牙与BLE建立连接。
[0099] 2、互信认证模块,用于使SDK与BLE进行互信认证。
[0100] 建立连接之后SDK根据预先约定好的加密密钥和加密方式将数据传输给BLE,BLE根据预先约定的密钥进行数据解密,根据获得的数据进行验证并返回给SDK互信数据,SDK对返回的数据进行认证,认证通过之后互信认证连接完成建立。
[0101] 3、BLE缓存并返回密钥模块,用于使BLE缓存并返回密钥模块。
[0102] 依据预先建立的互信连接(第1、2步建立的连接)BLE将密钥缓存并传输给SDK。
[0103] 4、接收模块,用于使SDK接收返回的密钥并缓存。
[0104] SDK接收BLE返回的密钥,并加密缓存在本地,为后续数据传输加密提供密钥。
[0105] 5、数据传输模块,用于使SDK与BLE基于当前连接的数据传输。
[0106] 基于预先建立的互信连接(第1、2步建立的连接)在数据传输过程中将所有数据根据密钥(第4步缓存的密钥)进行数据加密传输。
[0107] 需要指出的是,在任何过程中,只要蓝牙断开,SDK存储的密钥直接清零,整个流程需要重新开始。
[0108] 四、身份认证机制(即业务系统和电子凭证系统之间网络安全通信方法的身份认证方法及其装置)
[0109] 请参阅图5,业务系统和电子凭证系统之间网络安全通信方法的身份认证装置包括5大模块,每大模块执行一个相应的步骤。依据这5大模块,业务系统和电子凭证系统之间网络安全通信方法的身份认证方法的主要步骤描述:
[0110] 1、获取请求head数据模块,用于获取请求head数据。
[0111] 将请求head携带的数据从请求中分离出来,并从对分离出的数据进行校验,如果合法则进行后续操作,如果不合法则直接执行第5步。
[0112] 2、解密并校验head数据模块,用于解密并校验head数据。
[0113] 对第1步分离的数据进行解密,解密后验证参数是否合法,如果合法则进行后续操作,如果不合法则直接执行第5步。
[0114] 3、调用业务系统进行用户验证模块,用于调用业务系统进行用户验证。
[0115] 对解密后并校验成功的数据进行处理后,调用业务系统开放的用户验证接口验证用户是否合法,如果合法则继续执行,否则直接执行第5步。
[0116] 4、执行凭证系统业务模块,用于执行凭证系统业务。
[0117] 完成用户验证后对请求执行业务逻辑,业务执行完成后组织返回数据。
[0118] 5、返回结果模块,用于返回结果。
[0119] 将请求执行结果返回给接口调用放。
[0120] 综上所述,本发明从网络数据存储、传输、使用整个过程中解决安全问题,提供全套的安全解决方案。电子凭证系统本身提供了数据的安全存储,数据加密存储只有系统通过接口程序获取数据的时候才能够正常解密,其他途径均无法查看到加密数据原始内容。
[0121] 本发明的特点如下:
[0122] 1、基于https协议之上的安全机制,SDK与电子凭证系统进行数据交互前要先进行互信验证和密钥协商,完成互信认证和密钥协商之后使用基于协商密钥进行数据加密传输,在https的两端完成加密;
[0123] 2、电子凭证存储和传输的凭证数据由两部分组成,即通讯数据和自定义数据,通讯数据为用于和蓝牙芯片互信交互的数据;自定义数据为使用电子凭证系统的用户根据自身需要而设计的数据结构,此数据是在SDK与蓝牙芯片完成互信后直接传递给蓝牙芯片的;
[0124] 3、蓝牙连接互信机制,SDK与蓝牙芯片建立初始连接之后先进行互信验证和密钥协商,完成互信认证和密钥协商之后使用基于协商密钥进行数据加密传输;
[0125] 4、本方案整体说明网络安全通信机制。
[0126] 以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。
QQ群二维码
意见反馈