CN109714370B - 一种基于http协议端云安全通信的实现方法 - Google Patents
一种基于http协议端云安全通信的实现方法 Download PDFInfo
- Publication number
- CN109714370B CN109714370B CN201910172462.4A CN201910172462A CN109714370B CN 109714370 B CN109714370 B CN 109714370B CN 201910172462 A CN201910172462 A CN 201910172462A CN 109714370 B CN109714370 B CN 109714370B
- Authority
- CN
- China
- Prior art keywords
- signature
- data
- terminal
- cloud
- timestamp
- 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
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种基于HTTP协议端云安全通信的实现方法，包括设计一种安全API格式、在云端验证终端数据合法性过程中，设计新的终端签名数据的方式及云端验证终端签名数据的方式，在终端验证云端数据合法性过程中，设计新的云端签名的流程及终端验签的流程，其中，所述终端签名数据的方式包括签名数据的组合方式、body数据的排序方式及终端签名的流程。本发明的方法通过对接口的安全设计，可实现防伪装攻击、防篡改攻击、防重放攻击、防数据信息泄漏等安全功能，保证WEB接口通信的安全。
Description
技术领域
本发明涉及互联网WEB安全通信技术领域，特别涉及一种基于HTTP协议端云安全通信的实现方法。
背景技术
互联网的蓬勃发展也伴随各种安全问题发生，特别是针对HTTP的通信接口存在很大的安全隐患，比如重放攻击的风险，数据明文的风险、接口数据被篡改、身份认证的风险，这些问题随着业务迅速增长，接口安全问题暴露越来越多，甚至影响到业务的运营。
发明内容
本发明的目的是克服上述背景技术中不足，提供一种基于HTTP协议端云安全通信的实现方法，通过对接口的安全设计，可实现防伪装攻击(如第三方有意或恶意的调用接口)、防篡改攻击(请求头/查询字符串/在传输过程被修改)、防重放攻击(请求被截获，稍后被重放或多次重放)、防数据信息泄漏(截获用户登录请求，截获到账号、密码等)等安全功能，保证WEB接口通信的安全。
为了达到上述的技术效果，本发明采取以下技术方案：
一种基于HTTP协议端云安全通信的实现方法，包括设计一种安全API格式、在云端验证终端数据合法性过程中，设计新的终端签名数据的方式及云端验证终端签名数据的方式，在终端验证云端数据合法性过程中，设计新的云端签名的流程及终端验签的流程，其中，所述终端签名数据的方式包括签名数据的组合方式、body数据的排序方式及终端签名的流程。
进一步地，所述安全API格式为：http://host:port/service？sign＝XXX&appkey＝XXX&nonce＝XXX×tamp＝XXX，其中http://host:port/service表示正常业务接口；sign是签名值，appkey是业务参数，nonce是随机数据，timestamp是时间戳。
进一步地，所述云端验证终端数据合法性时具体为：根据请求参数，对签名进行验证，签名不合法的请求将会被拒绝，签名的数据用于计算摘要，所述签名数据的组合方式为：secretkey+(sort(body)+nonce+timestamp)+secretkey。
进一步地，所述body数据的排序方式包括：在post请求方式中，sort(body)为将body的json字符串约定以键名的ASCII升序排序；在get请求方式，sort(body)是将请求的业务参数，即将除sign、nonce、appkey、timestamp以外的参数按键名的ASCII升序排序。
进一步地，终端签名的流程包括：终端生成排序的业务数据sort(body)、随机数nonce，并根据appkey得到加密数据secretkey，然后向时间服务器请求时间戳并获取时间戳，再根据上述信息生成待签名数据：secretkey+(sort(body)+nonce+timestamp)+secretkey并进行签名，签名成功后生成签名值并发送签名值、随机数、时间戳及业务数据至业务平台进行验签，最后接收业务平台返回的验签结果。
进一步地，所述云端验证终端签名数据时验签的流程具体包括：
首先，云端先解析终端发出的报文数据，获取时间戳timestamp、随机数nonce、签名值及appkey，
云端向时间服务器请求时间戳并获取时间戳，并判断时间服务器返回的时间戳是否与报文的时间戳的差值在1分钟范围内，如果不在1分钟范围，则向终端返回验签不成功，否则，云端再对比签名值查看签名值是否在缓存中；
如果缓存已经存在该签名值，则向终端返回验签不成功，其中，缓存中保存的签名值，有效期为1分钟；如果缓存中不存在该签名值则按照终端签名的流程拼接(sort(body)+nonce+timestamp)，然后根据appkey得到secretkey并拼接secretkey：secretkey+(sort(body)+nonce+timestamp)+secretkey生成待验签数据；对待验签数据进行验签，并在验签成功后将签名值保存在缓存中。
进一步地，在终端和云端设有备用时间服务器第二地址。
进一步地，所述云端签名的流程包括：
首先，使用签名算法将返回终端的业务数据chbusycontent的值转为byte数组，然后拼接上secretkey形成待签数据，拼接公式如下：secretkey+chbusycontent+secretkey；其中，secretkey根据appkey获取，appkey从终端发起的请求中获得；且业务数据chbusyconten的值为json格式字符串，约定以键名的ASCII升序排序；然后对待签数据进行签名，并在签名成功后返回签名值chsign及向终端返回验签报文进行验签。
进一步地，所述终端验签的流程具体包括：首先，接收并解析云端反馈的验签报文，得到业务数据chbusycontent和签名值chsign，然后将业务数据chbusycontent转为byte数组并拼接上secretkey形成待验签数据，拼接公式如下：secretkey+chbusycontent+secretkey；然后再对待验签数据进行验签，若验签成功则向云端返回验签成功，否则向云端返回验签失败。
本发明与现有技术相比，具有以下的有益效果：
本发明的基于HTTP协议端云安全通信的实现方法，通过对接口的安全设计，可实现防伪装攻击(如第三方有意或恶意的调用接口)、防篡改攻击(请求头/查询字符串/在传输过程被修改)、防重放攻击(请求被截获，稍后被重放或多次重放)、防数据信息泄漏(截获用户登录请求，截获到账号、密码等)等安全功能，保证WEB接口通信的安全。
附图说明
图1是本发明的方法中终端签名的流程示意图。
图2是本发明的方法中云端验签的流程示意图。
图3是本发明的方法中云端签名的流程示意图。
图4是本发明的方法中终端验签的流程示意图。
具体实施方式
下面结合本发明的实施例对本发明作进一步的阐述和说明。
实施例：
一种基于HTTP协议端云安全通信的实现方法，包括设计一种安全API格式、在云端验证终端数据合法性过程中，设计新的终端签名数据的方式及云端验证终端签名数据的方式，在终端验证云端数据合法性过程中，设计新的云端签名的流程及终端验签的流程，其中，所述终端签名数据的方式包括签名数据的组合方式、body数据的排序方式及终端签名的流程。
其中，终端向云端进行业务请求时，需要先进行签名并由云端进行验签，具体为终端对请求业务数据进行数字签名。请求时，将签名值、业务数据、时间戳、随机数(uuid)发送至云端服务器，云端服务器获取后，解析数据，调用验签接口，验签成功说明终端为合法终端，则接收的数据合法可以进行相关业务处理。
具体的，本方法中安全API格式为：http://host:port/service？sign＝XXX&appkey＝XXX&nonce＝XXX×tamp＝XXX，其中http://host:port/service表示正常业务接口；sign是签名值，appkey是业务参数，nonce是随机数据，timestamp是时间戳，公共安全参数与接口以？隔开，公共安全参数之间以&隔开。
如本实施例中具有如下安全接口：
http://127.0.0.1:8082/test/v1/getData？sign＝8e62052ef653faa776a26e67b063f005e4e52ed858e25c755c7816c70fa900b4&appkey＝30a10e21&nonce＝cd8fe03ab9f146749c0956b0d3e234bf×tamp＝1507628322000
Post参数：
{"client":{"deviceChip":"TEST","deviceModel":"test1"}}
云端在收到终端发出的请求时会先对其进行验证，云端验证终端目的是防止终端重放攻击、采取恶意、超高频次等手段向服务端发送非正常请求，数据完整性校验可防止非法终端篡改终端数据。具体的，本实施例中是将终端签名参数sign放到url中，例如http://127.0.0.1:8082/test/v1/getData？sign＝8e62052ef653faa776a26e67b063f005e4e52ed858e25c755c7816c70fa900b4&appkey＝30a10e21&nonce＝cd8fe03ab9f146749c0956b0d3e234bf×tamp＝1507628322000，其它业务参数放到body中，其他参数包括公共参数(包含除sign的安全参数)加业务参数，键名一律采用小写。
具体的，本实施例中，各接口业务参数根据业务***的接口文档来定义，安全参数列表如下：
云端验证终端数据合法性时具体为：根据请求参数，对签名进行验证，签名不合法的请求将会被拒绝，签名的数据用于计算摘要，所述签名数据主要由安全参数和业务参数组合而成，可用于计算摘要，具体的组合方式为：secretkey+(sort(body)+nonce+timestamp)+secretkey。
其中，body数据的排序方式包括：在post请求方式中，sort(body)为将body的json字符串约定以键名的ASCII升序排序，其中，secretkey根据appkey并解密获得，假设本实施例中，secretkey值为erY8hSl8，post参数为：
{"mac":"0A:00:27:00:00:0E"，"client":{"deviceModel":"CHIQ_3","deviceChip":"TEST"},}；
则以键名的ASCII升序排序后为：
{"client":{"deviceChip":"TEST","deviceModel":"CHIQ_3"},"mac":"0A:00:27:00:00:0E",}；
将sort(body)+nonce+timestamp转为byte数组，其中，nonce，timestamp拼接值拼接键值，不拼接键名：
[123,34,97,112,112,107,101,121,34,58,32,34,51,48,97,49,48,101,50,49,34,44,34,109,97,99,34,58,32,34,48,65,58,48,48,58,50,55,58,48,48,58,48,48,58,48,69,34,44,34,110,111,110,99,101,34,58,32,34,99,100,56,102,101,48,51,97,98,57,102,49,52,54,55,52,57,99,48,57,53,54,98,48,100,51,101,50,51,52,98,102,34,44,34,112,97,114,97,109,101,116,101,114,34,58,32,123,34,99,108,105,101,110,116,34,58,32,123,34,100,101,118,105,99,101,67,104,105,112,34,58,32,34,84,69,83,84,34,44,34,100,101,118,105,99,101,77,111,100,101,108,34,58,32,34,67,72,73,81,95,51,34,125,125,44,34,116,105,109,101,115,116,97,109,112,34,58,32,49,53,48,55,54,50,56,51,50,50,48,48,48,125]
在get请求方式，sort(body)是将请求的业务参数，即将除sign、nonce、appkey、timestamp以外的参数按键名的ASCII升序排序；如：
http://127.0.0.1:8082/test/v1/getData？sign＝8e62052ef653faa776a26e67b063f005e4e52ed858e25c755c7816c70fa900b4&appkey＝30a10e21&nonce＝cd8fe03ab9f146749c0956b0d3e234bf×tamp＝1507628322000&mac＝0A:00:27:00:00:0E&username＝tom&age＝11
获得的sort(body)即为age11mac0A:00:27:00:00:0Eusernametom。
sort(body)再与nonce和timestamp的值拼接，拼接方式sort(body)+nonce+timestamp。再转为byte[]数组。
具体的，如图1所示，本实施例中，终端签名的流程包括：终端生成排序的业务数据sort(body)、随机数nonce，并根据appkey得到加密数据secretkey，然后向时间服务器请求时间戳并获取时间戳，再根据上述信息生成待签名数据：secretkey+(sort(body)+nonce+timestamp)+secretkey并进行签名，签名成功后生成签名值并发送签名值、随机数、时间戳及业务数据至业务平台进行验签，最后接收业务平台返回的验签结果。
如本实施例中，解密后的secretkey值erY8hSl8，byte数组为[101,114,89,56,104,83,108,56]
拼装形成待签名的数据如下：
[101,114,89,56,104,83,108,56,123,34,97,112,112,107,101,121,34,58,32,34,51,48,97,49,48,101,50,49,34,44,34,109,97,99,34,58,32,34,48,65,58,48,48,58,50,55,58,48,48,58,48,48,58,48,69,34,44,34,110,111,110,99,101,34,58,32,34,99,100,56,102,101,48,51,97,98,57,102,49,52,54,55,52,57,99,48,57,53,54,98,48,100,51,101,50,51,52,98,102,34,44,34,112,97,114,97,109,101,116,101,114,34,58,32,123,34,99,108,105,101,110,116,34,58,32,123,34,100,101,118,105,99,101,67,104,105,112,34,58,32,34,84,69,83,84,34,44,34,100,101,118,105,99,101,77,111,100,101,108,34,58,32,34,67,72,73,81,95,51,34,125,125,44,34,116,105,109,101,115,116,97,109,112,34,58,32,49,53,48,55,54,50,56,51,50,50,48,48,48,125,101,114,89,56,104,83,108,56]；
该字符串是byte数组utf-8编码格式，对该byte数据进行签名，得到32位byte数组的签名值，约定采用hex编码成字符串传递。
如图2所示，在本实施例中，云端验证终端签名数据时验签的流程具体包括：
首先，云端先解析终端发出的报文数据，获取时间戳timestamp、随机数nonce、签名值及appkey，
云端向时间服务器请求时间戳并获取时间戳，并判断时间服务器返回的时间戳是否与报文的时间戳的差值在1分钟范围内，如果不在1分钟范围，则向终端返回验签不成功，否则，云端再对比签名值查看签名值是否在缓存中；
如果缓存已经存在该签名值，则向终端返回验签不成功，其中，缓存中保存的签名值，有效期为1分钟；如果缓存中不存在该签名值则按照终端签名的流程拼接(sort(body)+nonce+timestamp)，然后根据appkey得到secretkey并拼接secretkey：secretkey+(sort(body)+nonce+timestamp)+secretkey生成待验签数据；对待验签数据进行验签，并在验签成功后将签名值保存在缓存中。
为了让终端和云端获取正确的时间，提供获取当前时间的API，给签名、验签提供同一时间校对。终端和云端可以设置备用时间服务器第二地址，防止第一地址的服务器DOWN掉后，可以通过第二ntp时间服务器矫正时间。
作为优选，本实施例中，Hash算法采用列如sha256单向加密算法；随机数nonce采用uuid，以保证唯一性。
同时，本实施例中还公开了终端验云端的数据流程，终端认证云端的数据可防止云端端传给终端端的数据被人截取，篡改，其具体方式包括：涉及下发图片地址、文字的相关数据的接口，在云端返回给终端的接口数据进行数字签名，终端获取后，调用验签接口，验签成功说明云端可信，接收的数据合法。
具体的，如图3所示，本实施例中云端签名的流程包括：
首先，使用签名算法将返回终端的业务数据chbusycontent的值转为byte数组，然后拼接上secretkey形成待签数据，拼接公式如下：secretkey+chbusycontent+secretkey；其中，secretkey根据appkey获取，appkey从终端发起的请求中获得；且业务数据chbusyconten的值为json格式字符串，约定以键名的ASCII升序排序；将摘要得到的字节流结果chsign使用hex编码表示，然后对待签数据进行签名，并在签名成功后返回签名值chsign及向终端返回验签报文进行验签，具体是将业务数据chbusycontent和签名值chsign，按如下格式封装成json字符串，反馈给终端验签：
{"chsign":"xxx","chbusycontent"：{xxx}}。
其中，本实施例中验签接口的接口方式具体为：http://127.0.0.1:8080/services？sign＝9dd95332a2a96bdb66f0448566c7816a635cc3447a2ad224b19c982e3311a64b&appkey＝30a10e21&nonce＝cd8fe03ab9f146749c0956b0d3e234bf×tamp＝150762832200。
终端接收云端反馈数据示例如下：
{"sign"："1BF546D3D553FAA42DE735BA923D16EB311A717D","chbusycontent"：{"code":"200","data":{"navList":[{"dlIntent":{},"icon":"http://127.0.0.1/group1/M00/00/55/Cgrs-Vkfo0GAL2FqAABKN-s2Yu4054.png","i d":219,"sort":2,"startIntent":{"action":"com.tencent.qqlivetv.open","pkgname":"com.ktcp.video","starttype":"startActivity","uri":"tenvideo2://？action＝3&channel_c ode＝hevc&channel_name＝4K专区&cover_pulltype＝2"},"stickyTop":"0","title":"UMAX","versionCode":27},{"dlIntent":{},"icon":"http://127.0.0.1/group1/M00/00/38/Cgrs-ViiXW2ATrBTAAAMrcbJhEQ443.png","id":88,"sort":9,"startIntent":{"clsname":"com.changhong.chusercenter.CHUserCenter","pkgname":"com.changho ng.chusercenter","starttype":"startActivity"},"stickyTop":"0","title":"我的","versionCode":31}],"versionCode":709},"message":"请求成功"，"timestamp":1503372055772,"transactionSn":"2017082211205127760808"}，}。
其中，具体的各接口业务参数可根据业务***的接口文档来定义，公共参数列表如下：
| 参数名 | 类型 | 是否必须 | 描述 |
| chbusycontent | 字符串 | 是 | 业务数据 |
| sign | 字符串 | 是 | API输入参数签名结果 |
如图4所示，终端验签的流程具体包括：首先，接收并解析云端反馈的验签报文，得到业务数据chbusycontent和签名值chsign，然后将业务数据chbusycontent转为byte数组并拼接上secretkey形成待验签数据，拼接公式如下：secretkey+chbusycontent+secretkey；然后再对待验签数据进行验签，若验签成功则可进行后续业务工作并向云端返回验签成功，否则向云端返回验签失败。
可以理解的是，以上实施方式仅仅是为了说明本发明的原理而采用的示例性实施方式，然而本发明并不局限于此。对于本领域内的普通技术人员而言，在不脱离本发明的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本发明的保护范围。
Claims (4)
1.一种基于HTTP协议端云安全通信的实现方法，其特征在于，包括设计一种安全API格式、在云端验证终端数据合法性过程中，设计新的终端签名数据的方式及云端验证终端签名数据的方式，在终端验证云端数据合法性过程中，设计新的云端签名的流程及终端验签的流程，其中，所述终端签名数据的方式包括签名数据的组合方式、body数据的排序方式及终端签名的流程；所述安全API格式为：http://host:port/service？sign＝XXX&appkey＝XXX&nonce＝XXX×tamp＝XXX，其中http://host:port/service表示正常业务接口；sign是签名值，appkey是业务参数，nonce是随机数据，timestamp是时间戳；所述云端验证终端数据合法性时具体为：根据请求参数，对签名进行验证，签名不合法的请求将会被拒绝，签名的数据用于计算摘要，所述签名数据的组合方式为：secretkey+(sort(body)+nonce+timestamp)+secretkey；所述body数据的排序方式包括：在post请求方式中，sort(body)为将body的json字符串约定以键名的ASCII升序排序；在get请求方式，sort(body)是将请求的业务参数，即将除sign、nonce、appkey、timestamp以外的参数按键名的ASCII升序排序；终端签名的流程包括：终端生成排序的业务数据sort(body)、随机数nonce，并根据appkey得到加密数据secretkey，然后向时间服务器请求时间戳并获取时间戳，再根据上述信息生成待签名数据：secretkey+(sort(body)+nonce+timestamp)+secretkey并进行签名，签名成功后生成签名值并发送签名值、随机数、时间戳及业务数据至业务平台进行验签，最后接收业务平台返回的验签结果；所述云端验证终端签名数据时验签的流程具体包括：
首先，云端先解析终端发出的报文数据，获取时间戳timestamp、随机数nonce、签名值及appkey，
云端向时间服务器请求时间戳并获取时间戳，并判断时间服务器返回的时间戳是否与报文的时间戳的差值在1分钟范围内，如果不在1分钟范围，则向终端返回验签不成功，否则，云端再对比签名值查看签名值是否在缓存中；
如果缓存已经存在该签名值，则向终端返回验签不成功，其中，缓存中保存的签名值，有效期为1分钟；如果缓存中不存在该签名值则按照终端签名的流程拼接(sort(body)+nonce+timestamp)，然后根据appkey得到secretkey并拼接secretkey：secretkey+(sort(body)+nonce+timestamp)+secretkey生成待验签数据；对待验签数据进行验签，并在验签成功后将签名值保存在缓存中。
2.根据权利要求1所述的一种基于HTTP协议端云安全通信的实现方法，其特征在于，在终端和云端设有备用时间服务器第二地址。
3.根据权利要求1所述的一种基于HTTP协议端云安全通信的实现方法，其特征在于，所述云端签名的流程包括：
首先，使用签名算法将返回终端的业务数据chbusycontent的值转为byte数组，然后拼接上secretkey形成待签数据，拼接公式如下：secretkey+chbusycontent+secretkey；其中，secretkey根据appkey获取，appkey从终端发起的请求中获得；且业务数据chbusyconten的值为json格式字符串，约定以键名的ASCII升序排序；然后对待签数据进行签名，并在签名成功后返回签名值chsign及向终端返回验签报文进行验签。
4.根据权利要求3所述的一种基于HTTP协议端云安全通信的实现方法，其特征在于，所述终端验签的流程具体包括：
首先，接收并解析云端反馈的验签报文，得到业务数据chbusycontent和签名值chsign，然后将业务数据chbusycontent转为byte数组并拼接上secretkey形成待验签数据，拼接公式如下：secretkey+chbusycontent+secretkey；然后再对待验签数据进行验签，若验签成功则向云端返回验签成功，否则向云端返回验签失败。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910172462.4A CN109714370B (zh) | 2019-03-07 | 2019-03-07 | 一种基于http协议端云安全通信的实现方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910172462.4A CN109714370B (zh) | 2019-03-07 | 2019-03-07 | 一种基于http协议端云安全通信的实现方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109714370A CN109714370A (zh) | 2019-05-03 |
| CN109714370B true CN109714370B (zh) | 2021-04-02 |
Family
ID=66266428
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910172462.4A Active CN109714370B (zh) | 2019-03-07 | 2019-03-07 | 一种基于http协议端云安全通信的实现方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109714370B (zh) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110611670A (zh) * | 2019-09-12 | 2019-12-24 | 贵阳叁玖互联网医疗有限公司 | 一种api请求的加密方法及装置 |
| CN111447195B (zh) * | 2020-03-23 | 2022-04-12 | 杭州小影创新科技股份有限公司 | 一种防止请求报文被篡改攻击重放的web接口设计方法 |
| CN111756749B (zh) * | 2020-06-24 | 2022-11-04 | 建信金融科技有限责任公司 | 安全访问方法、装置、设备及存储介质 |
| CN112261012A (zh) * | 2020-09-30 | 2021-01-22 | 北京鸿联九五信息产业有限公司 | 一种浏览器、服务器以及网页访问方法 |
| CN113904840A (zh) * | 2021-09-30 | 2022-01-07 | 广州海鹚网络科技有限公司 | 基于签名的医院防篡改请求验证*** |
| CN115022045B (zh) * | 2022-06-02 | 2023-09-19 | 联通(广东)产业互联网有限公司 | 一种基于边缘云的数据处理方法和*** |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9152686B2 (en) * | 2012-12-21 | 2015-10-06 | Zetta Inc. | Asynchronous replication correctness validation |
| CN106656953A (zh) * | 2016-09-23 | 2017-05-10 | 焦点科技股份有限公司 | 一种基于互联网的***间安全调用接口实现方法 |
| CN108400979A (zh) * | 2018-02-06 | 2018-08-14 | 武汉斗鱼网络科技有限公司 | 应用于客户端和服务器的通信方法及电子设备 |
| CN108494775A (zh) * | 2018-03-26 | 2018-09-04 | 四川长虹电器股份有限公司 | 防止利用合法数据或篡改合法数据进行网络攻击的方法 |
| CN108491295A (zh) * | 2018-03-28 | 2018-09-04 | 成都汇智远景科技有限公司 | 一种基于云计算的数据校验方法 |
| CN108512666A (zh) * | 2018-04-08 | 2018-09-07 | 苏州犀牛网络科技有限公司 | Api请求的加密方法、数据交互方法及*** |
-
2019
- 2019-03-07 CN CN201910172462.4A patent/CN109714370B/zh active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9152686B2 (en) * | 2012-12-21 | 2015-10-06 | Zetta Inc. | Asynchronous replication correctness validation |
| CN106656953A (zh) * | 2016-09-23 | 2017-05-10 | 焦点科技股份有限公司 | 一种基于互联网的***间安全调用接口实现方法 |
| CN108400979A (zh) * | 2018-02-06 | 2018-08-14 | 武汉斗鱼网络科技有限公司 | 应用于客户端和服务器的通信方法及电子设备 |
| CN108494775A (zh) * | 2018-03-26 | 2018-09-04 | 四川长虹电器股份有限公司 | 防止利用合法数据或篡改合法数据进行网络攻击的方法 |
| CN108491295A (zh) * | 2018-03-28 | 2018-09-04 | 成都汇智远景科技有限公司 | 一种基于云计算的数据校验方法 |
| CN108512666A (zh) * | 2018-04-08 | 2018-09-07 | 苏州犀牛网络科技有限公司 | Api请求的加密方法、数据交互方法及*** |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109714370A (zh) | 2019-05-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109714370B (zh) | 一种基于http协议端云安全通信的实现方法 | |
| US11089032B2 (en) | Signed envelope encryption | |
| US10447674B2 (en) | Key exchange through partially trusted third party | |
| US10516662B2 (en) | System and method for authenticating the legitimacy of a request for a resource by a user | |
| US8533806B2 (en) | Method for authenticating a trusted platform based on the tri-element peer authentication(TEPA) | |
| CN111586025B (zh) | 一种基于sdn的sdp安全组实现方法及安全*** | |
| US11336641B2 (en) | Security enhanced technique of authentication protocol based on trusted execution environment | |
| US20060005033A1 (en) | System and method for secure communications between at least one user device and a network entity | |
| CN105657474B (zh) | 在视频应用中使用基于身份签名体制的防盗链方法及*** | |
| CN106911684B (zh) | 一种鉴权方法及*** | |
| US20130103944A1 (en) | Hypertext Link Verification In Encrypted E-Mail For Mobile Devices | |
| CN102299930A (zh) | 一种保障客户端软件安全的方法 | |
| CN107517194B (zh) | 一种内容分发网络的回源认证方法和装置 | |
| CN110071937B (zh) | 基于区块链的登录方法、***及存储介质 | |
| CN110958119A (zh) | 身份验证方法和装置 | |
| CN112968910B (zh) | 一种防重放攻击方法和装置 | |
| CN106878324B (zh) | 短信认证方法、短信认证服务器及终端 | |
| CN111683090A (zh) | 一种基于分布式存储的区块链数字签名方法及装置 | |
| CN110943840B (zh) | 一种签名验证方法 | |
| JP2001186122A (ja) | 認証システム及び認証方法 | |
| CN112699374A (zh) | 一种完整性校验漏洞安全防护的方法及*** | |
| US8875244B1 (en) | Method and apparatus for authenticating a user using dynamic client-side storage values | |
| CN107566393A (zh) | 一种基于受信任证书的动态权限验证***及方法 | |
| CN110572392A (zh) | 一种基于Hyperledger网络的身份认证方法 | |
| CN114726606B (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 |