不使用HTTPS的数据安全传输方法及系统、客户端和服务端

摘要

本申请涉及不使用HTTPS的数据安全传输方法及系统、客户端和服务端。方法包括：服务端在本地创建CA，并向相连的客户端颁发用户证书，用户证书用作客户端登录服务端的登录凭证；服务端在收到客户端的登录信息后，根据登录凭证分配密钥，并将密钥返回给客户端；服务端根据密钥加密或解密客户端发来的数据信息。本申请通过服务端自己创建CA，所有用户证书由该CA颁发，不需要额外付费购买第三方CA；服务端在收到登录信息后，分配密钥给客户端，这样客户端可以使用该密钥对数据信息加密(解密)操作，而服务端可以使用该密钥对客户端发送来的数据信息进行解密(加密)操作，从而，在不使用HTTPS协议进行传输时，也能安全传输数据，实现了数据传输的双向认证。

说明书

技术领域

本申请涉及广域物联网组网技术领域，具体涉及一种数据安全传输方法和系统、及其涉及的客户端和服务端。

背景技术

物联网是指按约定的协议，把物品与互联网连接起来，进行信息交换和通信，以实现智能化识别、定位、跟踪、监控和管理的一种网络。物联网的典型应用之一是车辆管理系统，尤其是针对车辆卡(包括基于电子标签的IC卡)的管理系统。目前，车辆卡管理系统使用传统的三层架构方案，由数据访问层、业务逻辑层、表示层组成，如图1所示。业务逻辑层使用Webserver建立后台服务器，表示层通过访问Webserver提供的接口实现业务逻辑数据传输。

在车辆卡管理系统中，终端客户的种类不唯一，不同业务对数据保密级别的要求也不一样，一些特殊的数据需要进行加密传输，传统的处理方法是使用HTTPS协议(HyperTextTransferProtocoloverSecureSocketLayer，基于安全套接字层的超文本传输协议)来进行数据的安全传输控制。对于车辆卡系统，使用HTTPS协议存在以下的不足：

1、服务器必须从CA(CertificateAuthority，证书授权中心)申请一个用于证明服务器用途类型的证书，免费证书很少，通常需要交费；

2、HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，认证过程复杂，单次认证过程比较漫长，一般用于银行、交易支付方面；

3、使用HTTPS协议的服务端和客户端之间的所有通讯都是加密的，无法定制加密数据段，如果需要定制加密接口，则需要使用两套协议方案，一套使用HTTPS传输协议，一套使用HTTP传输协议，不便于维护。

发明内容

本申请提供一种适用于车辆卡管理系统的数据安全传输方法及系统，该方法和系统也可以适用于广域物联网的其他应用。

根据本申请的第一方面，本申请提供一种不使用基于安全套接字层的超文本传输协议(HTTPS)的数据安全传输方法，该方法包括以下步骤：

注册步骤：服务端在本地创建证书授权中心(CA)，并向相连的客户端颁发用户证书，所述用户证书用作所述客户端登录所述服务端的登录凭证；

登录步骤：所述服务端在收到所述客户端的登录信息后，根据所述登录凭证分配密钥，并将所述密钥返回给所述客户端；

加解密步骤：所述服务端根据所述密钥加密或解密所述客户端发来的数据信息。

进一步地，该方法的所述登录步骤还包括生成识别步骤，在所述生成识别子步骤中，所述服务端根据所述登录凭证生成用户识别码，并将所述用户识别码返回给所述客户端；所述加解密步骤还包括用户识别步骤，在所述用户识别步骤中，所述服务端在接收到所述客户端发送的数据信息后，根据所述用户识别码确定所述数据信息对应的客户端，并响应所述对应的客户端。

进一步地，该方法还包括接口定制步骤：所述服务端根据所述客户端的类型和业务功能提供安全接口信息，并向所述客户端公布所述安全接口信息，所述安全接口信息用于指示需要加解密操作的接口；所述服务端根据所述客户端发送来的携带有与安全接口信息相关内容的数据信息，结合所述安全接口信息确定关于待传输数据的加解密操作。

进一步地，在该方法中，传输于所述服务端和所述客户端之间的数据的格式为JSON数据交换格式；和/或，所述服务端和所述客户端之间的加密数据使用BASE64进行编码后再传输。

根据本申请的第二方面，本申请提供一种使用如上所述方法实现的不使用HTTPS的数据安全传输系统。

根据本申请的第三方面，本申请提供一种用于如上所述方法的客户端。

根据本申请的第四方面，本申请提供一种用于如上所述方法的服务端。

本申请的有益效果是：通过服务端自己创建CA，所有用户证书由该CA颁发，不需要额外付费购买第三方的CA；服务端在收到登录信息后，分配密钥给客户端，这样客户端可以使用该密钥对数据信息加密(解密)操作，而服务端可以使用该密钥对客户端发送来的数据信息进行解密(加密)操作，从而，在不使用HTTPS协议进行传输时，也能安全传输数据，实现了数据传输的双向认证。

附图说明

图1为车辆卡管理系统的三层架构方案示意图；

图2示出了本申请一种实施方式中的密钥生成过程，其实际上也示出了客户端登录服务端时二者的交互；

图3至图6示出了本申请一种实施方式中的安全接口数据控制流程，其实际上也示出了客户端与服务端进行业务数据传输时二者的交互；

图7示出了本申请一种实施方式用于车辆卡管理系统中的部分接口列表；

图8示出了本申请一种实施方式中客户端和服务端之间的拓扑示意图。

具体实施方式

本申请仍以车辆卡管理系统为例，对本申请提出的不使用HTTPS的数据安全传输方法及系统以及其涉及的客户端和服务端进行描述。可以理解的是，该方法和系统及其涉及的客户端和服务端也可以应用于广域物联网的其它应用中。

对于车辆卡管理系统，需要考虑稳定性、安全性和易用性。因此，本申请在设计该车辆卡管理系统的方案中，对传输数据进行了多方面的考虑，例如引入了服务端自身认证的证书，来实现数据双向认证机制；又例如传输的用户数据使用对称加密技术，这样相比采用HTTPS协议的传输可以尽可能地提高效率；再例如还可以使用用户识别码，接口数据不包含用户信息内容，从而可以对用户信息给予保密；又例如还可以使接口参数和返回数据为字符串，从而传输数据与数据类型无关；再例如还可定制化接口数据传输的安全控制，即定制是否需要加密传输数据。

因此，在本申请的一种实施方式中，提出了不使用HTTPS的数据安全传输方法，该方法包括注册步骤、登录步骤和加解密步骤。在注册步骤中，服务端在本地创建证书授权中心，并向相连的客户端颁发用户证书，用户证书用作客户端登录所述服务端的登录凭证；在登录步骤中，服务端在收到客户端的登录信息后，根据登录凭证分配密钥，并将密钥返回给客户端；在加解密步骤中，服务端根据密钥加密或解密客户端发来的数据信息。

具体地，对于注册步骤，首先服务端自己创建证书授权中心(CA)，并在接收到所述客户端的注册信息时，向客户端颁发CA认证的用户证书，并保存客户端相关的信息及其对应的用户证书，一般地，客户端相关的信息至少包括该客户端的用户名和密码。

对于登录步骤，当服务端接收客户端发送来的登录信息，通常登录信息包括客户端的用户名和密码，在本实施方式中，该密码为使用客户端的用户证书加密后的密文；然后，服务端根据用户名取得对应的用户证书，使用用户证书解密密文得到密码，然后随机产生密钥，保存密钥，并将密钥返回给客户端。当然，本步骤或者后续一些步骤中还可以涉及一些已知的技术手段，例如，在解密得到密码后，服务端将该密码和用户名与服务端事先存储的客户端相关的信息进行校验，如果校验通过，则继续后续步骤如产生密钥等，如果校验不通过，则可以向客户端发送用户名和密码不匹配之类的提示信息。

在另一种实施方式中，除了具有上述实施方式的功能步骤外，登录步骤还可以包括生成识别步骤，对应地，加解密步骤还可以包括用户识别步骤。在生成识别子步骤中，服务端根据登录凭证，生成用户识别码(也可以称之为用户登录校验码)，并将用户识别码返回给客户端；在用户识别步骤中，服务端在接收到客户端发送的数据信息后，根据用户识别码确定数据信息对应的客户端，并响应对应的客户端。

具体地，在生成识别步骤中，服务端在接收到客户端发送来的登录信息后，根据客户端的登录凭证随机产生用户识别码，保存用户识别码，并将用户识别码返回给客户端；而在用户识别步骤中，服务端在确定出数据信息对应的客户端后，获得对应的客户端的密钥。

在又一种实施方式中，除了具有上述各实施方式的功能步骤外，本申请的不使用HTTPS协议的数据安全传输方法还可以包括接口定制步骤：服务端根据客户端的类型和业务功能提供安全接口信息，并向客户端公布安全接口信息，安全接口信息用于指示需要加解密操作的接口；当服务端接收到客户端发送来的携带有与安全接口信息相关内容的数据信息，结合该安全接口信息确定关于待传输数据的加解密操作。一种实施例中，安全接口信息包括安全接口列表，该安全接口列表中登记有需要对传输数据进行加解密操作的接口；另一种实施例中，安全接口信息包括带有安全参数值的接口函数，该安全参数值用于表征接口安全的级别。

本申请还提供一种实施方式，其除了具有上述各实施方式的功能步骤外，对于传输于服务端和客户端之间的数据，其采用的数据格式为JSON数据交换格式。另一种实施方式中，服务端和客户端之间的加密数据使用BASE64进行编码后再传输。

下面结合附图对本申请上述各实施方式作进一步详细说明。

如图2所述，为在本申请一种实施方式提供的不使用HTTPS协议的数据安全传输方法中的密钥生成过程示意图，其实际上也示出了客户端登录服务端时二者的交互。

客户端的用户使用用户名、密码进行用户登录。

一种实施例中，登录接口如下定义。

//摘要:车辆卡系统登录接口，该接口不同于其它业务数据接口，接口参数只有一个。

//用户登录，明文传输

//

//参数:

//JSONData:JSON数据序列化串，其中的用户密码节点使用了证书私钥加密后的BASE64编码串。

//

//返回：

//JSON数据串，其中返回的密钥key使用了证书公钥加密后的BASE64编码串

//

publicstringUserLogin(stringJSONData)；

客户端用户登录成功后，返回的JSON数据串里包含了密钥key和用户识别码(checkcode)。其中的登录过程涉及以下步骤a)～d)。

在步骤a)中，终端用户登录，将登录名、密码(具体实现时，可以取的用户密码MD5哈希值，使用用户证书对哈希值进行加密，并对加密后的密文进行BASE64编码，故最终传输的密码为BASE64格式的伪码串)以及其它登录信息，封装成JSON串，调用登录接口登录。

在步骤b)中，服务端收到用户登录数据，解析JSON参数，根据用户名信息获取用户对应的证书，解密用户密码并验证。密码验证过程先进行BASE64解码得到密文，然后使用该用户对应的证书公钥解密密文，得到用户密码的MD5哈希值，与服务端上该用户保存的MD5哈希值比较，如果相同，则密码验证成功，如果不相同，则密码校验失败。

在步骤c)中，服务端验证用户登录信息正确，随机产生一个密钥key(字符串，由特殊符号、数字、字符组成)并保存，并使用用户对应的证书(证书公钥)对key进行加密，将加密后的密文组装到返回的JSON数据中，同时在返回的JSON数据中还包含一个用户识别码(checkcode，也是由服务端随机生成的，一种具体实现中，为了唯一性，使用的是GUID)；在接口返回的JSON数据结构中，都有一个rt的证书节点，该节点用于描述接口业务操作状况，如果操作成功rt为0；失败则返回其它失败代号。

在步骤d)中，客户端登录成功后收到返回数据，利用用户证书(证书私钥)解密密钥key，这样就和服务端拥有相同的密钥key，同时客户端需要保存用户识别码checkcode。

客户端登录成功后获得了密钥和用户识别，就可以使用服务端提供的接口进行业务操作，车辆卡系统业务操作接口如下设计样式。

//以下两组代码片段用于展示车辆卡系统加密接口和未加密接口定义样式。

//摘要:车辆卡系统业务操作安全接口(业务数据需要进行加密传输)

//用户登出，参数和返回值需要进行加密传输

//

//参数:

//JSONData:原始内容为JSON序列化后的数据串，这里是加密后的BASE64编码串。JSON数据节点信息，参见接口文档。

//checkcode:用户登录产生的用户识别码。

//

//返回：

//原始内容JSON数据串，这里是加密后的BASE64编码串。JSON数据节点信息，参见接口文档。

//

publicstringUserLogout(stringcheckcode，stringJSONData)；

//摘要:车辆卡系统业务操作接口

//查询车辆基础信息，如车辆颜色、厂牌型号、类型等信息。

//

//参数:

//JSONData:内容为JSON序列化后的数据串。JSON数据节点信息，参见接口文档。

//checkcode:用户登录产生的用户识别码。

//

//返回：

//内容JSON数据串。JSON数据节点信息，参见接口文档。

//

publicstringQueryVehicleInfo(stringcheckcode，stringJSONData)；

对于安全接口，业务数据都是通过密文进行传输的，客户端和服务端使用相同密钥对业务数据进行加解密控制。

如图3至图6所示，示出了本申请一种实施方式提供的不使用HTTPS协议的数据安全传输方法中的安全接口数据控制流程示意图，其实际上也示出了客户端与服务端进行业务数据传输时二者的交互，所涉及的交互大体涉及如下过程a)～e)。

在过程a)中，客户端用户将业务传输数据进行JSON序列化为字符串格式。

在过程b)中，客户端调用服务端接口，根据服务端接口定义，判断接口的数据传输是否需要进行加密，对需要加密传输的业务数据使用密钥key进行对称加密。客户端业务数据请求接口，由两个字符串型参数组成，第一个参数是客户端登录的用户识别码，第二个是实际的业务数据，如果是安全接口，需要对该业务数据进行加密。由于加密后的密文是不规则数据，为了接口类型统一，需要对密文进行BASE64编码，即实际传输的业务数据参数是经过BASE64编码后的字符串内容。

在过程c)中，服务端收到客户端的业务数据请求，根据响应的接口位置，可直接判断是否是安全控制接口，如果是安全控制接口，利用用户识别码得到客户端用户的密钥key，然后对业务数据进行BASE64解码、使用密钥key解密密文，最终得到实际的JSON数据字符串，接着进行JSON反序列化及进行一系列的业务操作。

在过程d)中，服务端业务操作完成后，JSON序列化接口返回数据，如果是安全接口，使用密钥key对JSON序列化后的字符串进行对称加密，并对加密后的密文进行BASE64编码；如果不是安全接口，则直接返回JSON串。

在过程e)中，终端用户收到返回的数据，如果调用的是安全接口，首先需要BASE64解码，然后使用密钥key进行解密得到服务端返回的JSON数据串；如果不是调用安全接口，返回的数据就是实际的业务数据JSON串。

具体地，在客户端已经登录服务端后，图3是不需要考虑数据安全时客户端与服务端的交互过程：首先客户端将JSON格式的接口数据不加密地传输给服务端，服务端在接收到该明文的接口数据后，根据接口类型进行业务数据处理，并进行车辆卡核心业务逻辑处理，然后对业务处理后产生的数据进行JSON格式打包，并不使用安全控制(即不需要进行加密处理)直接返回明文数据给客户端。

图4与图3的不同之处在于，图4的服务端在对业务处理后产生的数据进行JSON格式打包(简称JSON串数据)后需要进行安全控制(即需要进行加密处理以防止非请求的客户端或其它第三方获知业务数据信息)，此时，服务端使用与该请求数据的客户端对应的密钥加密JSON串数据，形成密文，并对密文进行BASE64编码，得到伪串并将伪串通过反馈给客户端；客户端对接收到的伪串进行BASE64解码得到密文，然后用之前存储的密钥(即客户端登录服务器后服务器反馈给客户端的密钥)解密密文，从而得到明文形式的业务数据信息。

图5与图3的不同之处在于，客户端在发送数据信息(例如车辆卡相关的业务数据)时需要加密处理后再传输，即客户端首先使用密钥(即客户端登录服务器后服务器反馈给客户端的密钥)加密数据，得到密文，然后对密文进行BASE64进行编码，形成伪串，然后调用接口函数将伪串发送给服务端，该接口函数中的参数涉及客户端的用户识别码(即checkcode)和编码后的伪串。

图6中，客户端和服务端在数据传输的安全性上要求很高，即客户端需要加密传输，而服务端在处理业务后也需要进行安全控制，以安全地将数据传输回客户端。客户端和服务端具体加密的过程类似前述相关描述，在此不再详述。

通过以上描述可知，本申请提出了使用一种Webserver服务器，基于HTTP协议对传输数据进行定制化加密的数据安全传输的方案，该方案提高了传输效率和简化了加解密流程，加密数据传输接口可随意定制和扩展。

首先，本申请的一个特点是引入证书。每个客户端用户都应该有一个自己的用户证书，该证书由服务端颁发。证书的CA由服务端自己创建的，在整个车辆卡系统中唯一，所有的用户证书由该CA颁发。用户证书不仅是车辆卡终端用户的凭证，而且是数据加密传输的双向认证。客户端使用用户证书的私钥加密(解密)数据，服务端使用客户端对应的公钥进行解密(加密)数据，即实现了传输数据的双向认证。

其次，本申请采用了对称加密。对称加解密技术，需要服务端和客户端使用一个相同的密钥(key)。用户登录时，服务端随机分配一个密钥，利用证书双向认证机制，返回给客户端，这样双方都有一个相同的密钥。当然用户每次登录后的密钥都是不一样的。对称加密比使用证书双向认证加密效率要高得多，在车辆卡系统中，对基本的业务数据安全接口，都是使用对称加密的方法。

接着，本申请引入用户识别码。服务端对于客户端请求的Webserver接口，并不知道每次过来的数据是由哪个客户端请求的，简单的做法是每次数据请求都包含客户端的用户信息，这样用户的信息就很容易被暴露了。识别码是客户端用户登录成功后，服务端分配给用户的一个唯一编码。客户端用户使用识别码请求业务数据，这样服务端可以通过识别码知道该条数据的来源，就可以针对具体的用户进行业务操作。

然后，本申请在接口参数和返回定义字符串类型做出了改进。Webserver的接口和普通的函数接口使用方式基本一致，通常使用接口时，会根据不同的数据类型使用多个接口参数。而本申请的车辆卡管理系统的接口，对传输的业务数据使用一个接口参数，类型统一为字符串类型，但是该字符串类型比较特殊，它是由JSON序列化后组装成的，同样返回的数据也是JSON序列化后的字符串。这样做的好处，接口不关心具体的数据类型，对于业务数据的修改不会影响接口定义；方便数据的加解密，整体性好。

不管是加密的数据和未加密的数据，最终都是JSON数据展现的。每个接口的JSON数据是不一样的，有一个标准接口文档作为参考，在文档里面，制定了每个接口的JSON数据拼装规则，不同的节点表示不同的数据类型。当服务端收到客户端的JSON数据包时，会根据当前接口对应的标准解析JSON数据，提取需要的数据进行业务处理。

最后，本申请还可以定制安全接口。在车辆卡管理系统中，服务端根据客户端类型和业务功能拥有大量的接口，每一个接口处理不同的业务。而在使用接口进行数据传输过程中，需要对某些传输数据进行加密传输，对于服务端和客户端如何知道哪些接口的数据需要进行加密，本申请提供了两种解决方案。

其中之一是采用列表方式。虽然车辆卡系统中的接口繁多，但是可以确定需要加密传输的接口，将需要加密传输的接口认为是安全接口，登记为一个列表，服务端发布时公布其安全接口列表，这样客户端使用安全接口时，就需要对传输数据进行加解密操作。

另一种方案是为接口函数增加一个参数，专门标注接口安全级别，如0表示未进行业务数据加密；1表示使用了key对称加密；2表示使用了非对称加密。这样服务端就可以根据该参数值确定业务数据是否需要解密，和解密方式。

为便于理解，如图7所示，这里以列表方式列出了车辆卡管理系统中部分接口说明。

基于以上方法实施方式，本申请一种实施方式还提出了一种使用如上方法实现的不使用HTTPS协议的数据安全传输系统，图8示出了该系统中客户端和服务端的拓扑结构示意图。另一种实施方式还提出了用于上述方法的客户端和/或服务端。

综上，本申请实施方式提出的不使用HTTPS协议的数据安全传输方法具有如下优点：

1)使用HTTP传输协议，实现了类似HTTPS的功能；

2)使用JSON序列化业务数据传输，单一的传输参数，与接口类型无关性，数据内容灵活控制，易于后期接口的维护升级；

3)可定制安全接口，对需要进行安全控制的接口进行加密，不需要安全控制的接口可以直接进行明文传输；

4)方案容易实施，使用简单。

本领域技术人员可以理解，上述实施方式中各种方法的全部或部分步骤可以通过程序来指令相关硬件完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器、随机存储器、磁盘或光盘等。

以上内容是结合具体的实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换。