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

发布时间:2014-11-09 20:37:00作者:左潇龙阅读(924 )评论(3)

    引言

     

      最近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只是闲来无事,随便看看加密算法,相信不会在这么短的时间内搞清楚,并且学会一些基础的使用方法。所以事实证明,学习任何知识,最好的办法就是利用这个知识做一个东西出来。


    版权声明:本文版权归作者(左潇龙)所有,欢迎转载。但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

    3
    精彩
    0
    感动
    0
    搞笑
    0
    开心
    0
    愤怒
    0
    无聊
    0
    灌水
    0
    惊讶
#1楼     时间:2014-11-10 02:42:00      来源:Monn
这本来就是SSL的基本原理,RSA用于key exchange
#2楼     时间:2014-11-10 08:33:00      来源:小狮儿
楼主发明了PGP :P
不过自己动手做确实很有意思
#3楼     时间:2014-11-14 12:39:00      来源:催夜凉风
等着啊,我去截取你的数据破解下,呵呵!
发表评论

站内搜索

最新评论