• 35648

    文章

  • 23

    评论

  • 20

    友链

  • 最近新加了很多技术文章,大家多来逛逛吧~~~~
  • 喜欢这个网站的朋友可以加一下QQ群,我们一起交流技术。

一次ssl的手动实现——加密算法的简单扫荡

欢迎来到阿八个人博客网站。本 阿八个人博客 网站提供最新的站长新闻,各种互联网资讯。 喜欢本站的朋友可以收藏本站,或者加QQ:我们大家一起来交流技术! URL链接:https://www.abboke.com/jsh/2019/0612/3016.html

引言

 

  最近LZ在公司里接了一个活,要发布一些服务给公司的合作伙伴调用。这种工作LZ可谓是轻车熟路,之前已经做了无数服务端。不过与以往不同的是,这次的服务是要发布在互联网上的,因此不能再像之前的套路一样。之前的系统交互都是公司内网之间的,因此不存在数据安全问题。

  这次不得不考虑数据的安全性,因此LZ最近就苦逼的开始研究各种加密算法。前后一共用了三天时间,LZ终于把加密层做好了,尽管LZ对各种加密算法的原理一概不知,但应该也算够用了。毕竟LZ没打算做一个绝对安全的系统(事实上这也是不可能的),只要能阻止90%的黑客即可。

 

方案制定

 

  开始的时候,首先要制定方案,应用层的协议采用http,这点是确定的。对于加密,LZ想来想去,基本上有两种选择。

  第一种是传统的办法,使用自签名证书,借用jdk和web容器的ssl层实现,这种方法比较常用,也比较省事。

  第二种是手动编程的方法,类似于自己写了一层ssl的实现。原理也很简单,对方把数据加密后传给LZ的服务端,LZ这边解密后该怎么处理就怎么处理,完事以后把响应的数据加密传给客户端,客户端解密之后该怎么处理就怎么处理。

  经过一番实验和思考,LZ还是决定采用第二种方法。主要原因是,这种方式更加灵活,加密方案是LZ可以随意更改的(比如把其中的某个算法用别的算法替换)。还有一点原因是,自己写的东西更加容易掌控,如果加密层出现问题,LZ作为PM可以更快的定位问题。最后一点原因是,基于算法而不是基于Java类库,更容易制作各种语言的客户端。

   

代码设计

 

  方案基本确定,接下来就是代码设计。代码设计分为客户端和服务端,作为客户端,LZ可以提供公用的加密解密组件给合作伙伴调用(比如java客户端,php客户端,.NET客户端等等)。作为服务端,LZ只需要过滤器和定制视图就可以轻易完成加密和解密的工作。

  最终写出来的客户端API如下:

  HttpsHelper.sendJsonAndGetJson(JSONObject json);

  HttpsHelper.sendJsonAndGetJson(JSONObject json,int timeout);

  以上就是客户端组件公布的两个方法,方法的作用很好理解,LZ就不多说了。在方法的实现当中,LZ已经帮客户端完成了加密和解密操作。当然,使用这个客户端的前提是,得到LZ给予的授权码。

  服务端需要一个过滤器和一个定制的json视图。

  SecurityFilter

  JsonView

  由于LZ发布的是restful风格的服务,因此使用的mvc框架是spring mvc。这两个类的具体代码这里就不贴了,总之过滤器完成请求参数的解密,视图完成响应结果的加密。

  

ssl层实现

 

  以上基本上已经完成了整个加密解密功能的设计,接下来的工作就是将工作落实到实处,到底加密算法如何选择?

  之前LZ对加密解密算法可谓是大大的小白,就知道一个md5算法,一般是用于密码加密的。这下可难倒LZ了,不过没关系,有百度和google,还有什么不能在几天之内学到的东西吗。

  经过一番百度和google,LZ发现算法主要分为以下三种:

  1,不可逆加密算法,比如md5就是这样一种,这种算法一般用于校验,比如校验用户的密码对不对。

  2,对称加密算法,这种算法是可逆的,两边拥有同一个密钥,使用这个密钥可以对数据加密和解密,一般用于数据加密传输。特点是速度快,但安全性相对于非对称加密较低。

  3,非对称加密算法,这种算法依然是可逆的,两边拥有不同的密钥,一个叫公钥,一个叫私钥,两边也都可以对数据加密和解密,一般用于数字签名。特点是速度较慢,但安全性相对于对称加密更高。

  之前LZ听说过ssl的实现是几种算法混合使用的,这给了LZ很大的启示。既然每种算法都有它的优势,我们为何不混合使用呢。

  于是,LZ想来想去(主要是在公车上以及厕所思考),决定使用md5(不可逆加密)+des(对称加密)+rsa(非对称加密)的加密方式,编码格式可以使用Base64。来看看LZ的需求,主要有两点。

  1,客户端需要LZ授权,也就是说LZ发布的服务不是谁想调就能调的。

  2,数据在传输过程中是加密的,并且安全性要等同于非对称加密算法的安全性,但性能要等同于对称加密的速度。

  我们来看看以上的算法实现能否满足需要,过程是这样的。

  1,假设LZ给客户端一个授权码,比如123456。再假设客户端现在需要传的数据是{"name":"xiaolongzuo"}。(请求数据和响应数据都是json格式)

  2,客户端需要先对123456进行md5加密,然后放入到传输数据中。也就是传输的数据会变成{"name":"xiaolongzuo","verifyCode":"md5(123456)"}

  3,客户端生成des的随机密钥(注意,对称密钥每次都是随机生成的),假设是abcdef,客户端使用该密钥对传输数据进行des加密,并且对随机密钥进行rsa加密,最终拼成一个json。也就是最终传输的数据会变成{"privateKey":"rsa(abcdef)","data":"des({"name":"xiaolongzuo","verifyCode":"md5(123456)"})"}

  4,服务端使用相反的过程对数据进行解密即可,并验证解密后的授权码md5(123456)是否存在,如果不存在,则认为该客户端未被授权。当服务端返回数据时,依旧使用abcdef对数据进行des加密即可。

  安全性分析:假设以上的数据被黑客拦截,那么黑客最主要做的就是破解rsa算法的私钥(私钥只有LZ有,客户端组件中会附带公钥),这个问题听说是比较难的,具体为什么,这就不是LZ需要考虑的了,LZ还没这个能力。基于这个前提,LZ可以认为传输的数据还是比较安全的。

  性能分析:由于我们的rsa只对长度比较短的des私钥进行加密,因此非对称加密速度慢的特点并不会影响我们太多。几乎上所有的传输数据,我们都是使用的des进行加密,因此在速度上,几乎等同于对称加密的速度。

 

小结

 

  由于源代码是公司所有,因此LZ这里不方便贴出来,但是整个思路这里已经阐述的非常清晰了。

  通过这次的简单学习,也不难发现,带着目的的学习才是最高效率的学习。试想一下,如果LZ只是闲来无事,随便看看加密算法,相信不会在这么短的时间内搞清楚,并且学会一些基础的使用方法。所以事实证明,学习任何知识,最好的办法就是利用这个知识做一个东西出来。


相关文章

暂住......别动,不想说点什么吗?
  • 全部评论(0
    还没有评论,快来抢沙发吧!