返回目录：电脑怎么了
作者：微信公众号 技术管理那些事 ID jsglnxs
最近，有新闻报道Google破解了SHA-1算法，周围有朋友就询问这个是什么意思，对我们IT安全影响大不大，等问题。
为了回答问题，周末去做了一些功课，根据国外专家的估算，一个SHA-1破解大概的成本是：$2M in 2012, $700K in 2015, $173K in 2018, and $43K in 2021。
这组数字告诉我们两个事情：一是成本越来越低；二是如果你的数据价值高于17万美金就多注意，否则就先不用着急，应该没有笨黑客干赔本的事情。
言归正传，随着互联网浸入生活的方方面面，无论技术产品从业者，还是普通百姓，我们平时都能看到很多安全术语，例如：Https 、Session、 appid/secret 、公私钥、假证书、gateway、cookie、token、MD5 checksum，等等。
最近工作也需要分享这方面的知识，就把一些过去了解的安全知识也梳理一下，按照加密的发展阶段聊一聊。
互联网发展起来，本质上就是信息流网络越发发达了，有的国家也叫信息高速公路。尤其是电子商务、互联网银行、支付等流行起来之后，信息安全问题就越来越和我们普通百姓利害攸关了。
很古老的时候，人们为了安全的传输信息message，就想到了加密。所谓加密，简单的讲就是A/B双方用一个算法把明文的message变成第三方C看不懂的乱码。
刚开始的时候，就是事先（out of band）A/B协商好一个Key，可能像特工一样在咖啡馆里交付一个存Key的U盘，也可能是打个电话告知对方Key，等等。因为A/B双方用的同一个Key，所以我们也把这种方式叫对称加密。
Case1:
A（用Key加密）－密文传输－B（用Key解密）
你是不是发现Case1使用方式非常不方便呢？
人类始终是在解决问题中进步的，上世纪70年代，有一天，几个三个分别叫R、S、A的大牛脑洞大开，想到使用一对配对的公私钥代替上文说的那个Key，私钥是保密的，公钥是公开的。A把自己的公钥传给B，这时B用A的公钥加密，密文传回A，A用自己的私钥就可以解密了，现在知道这个经典加解密算法为什么叫RSA了吧。和Case1中的对称加密不同，因为A/B双方用的公私钥是不一样的两个Key，所以我们也把这种方式叫非对称加密。
Case2:
A（发A公钥给B）－明文传输－B（用A公钥加密）－密文传输－A（用A私钥解密）
你是不是发现Case2有安全漏洞？
因为A的公钥是明文传给B的，如果中间有个C截获到加密信息，再用C自己伪造的公密钥伪装成A加密传给B，会发生什呢？A/B之间的信息就泄漏了。
Case3:
A（发A公钥给B）－明文传输－C（C公钥私钥伪装代替A的）
－B（用C公钥加密）－密文传输－C（用C私钥解密）
在上面的场景里，如何解决C这个伪装的代理gateway？
如果有个权威公正组织CA（Certificate Athority）能给A的公私钥进行签名公正的话，就会让C这类非法gateway没有生存之地了吧。这种方案称之为PKI（Public Key Infrastructure）。
那么CA具体是怎么给A做公正（担保）呢？
CA给A发一个证书Certificate，就称为CertificateA吧，里面包括A的公钥和对这个公钥的签名。B提前和CA建立了信任关系，可以根据签名确认A的公钥是合法的。这种情况下，如果C再篡改A的公钥，B端就收到非法证书的报警了。
Case4:
A（发证书CertificateA给B－包括A公钥和签名）－明文传输－C（无法篡改A公钥）－B（用签名验证A公钥合法、用A公钥加密）－密文传输－A（用A私钥解密）
注意一下，其中，B用A公钥加密的其实是一个“Case1中提到的对称Key”，密文传输给A，之后A/B之间就使用这个Key对称加密真正的message通信了。换句话说，其实PKI中非对称加密和对称加密是配合使用的，非对称加密只是负责传送那个对称Key，为什么不都用非对称加密所有message呢？就是为了计算成本考虑的，不展开说了。
说了半天，从Case2，Case3，到Case4都是为了逐步解决Case1中那个咖啡馆送U盘的问题。看来这句话没错，人类的科技发展都是为了让自己更懒惰才进步的。
到这儿还没完，再坚持一下，继续烧脑。。。
Case4中提到，B提前和CA建立了信任关系，怎么建立的？
这个信任链的起始点就是根证书，是CA认证中心给自己颁发的证书。B有一个根证书，称为CertificateRoot吧，包括CA本身的公钥和签名，来验证CertificateA的合法性，PKI机制要保证根证书是让A/B提前安全拿到的。
简单地讲，就是用一套PKI证书信任链的技术确保A/B之间通信的安全。就是这个技术，让A/B双方不用去咖啡馆送U盘了。
以上只是PKI的基本思路，我们平时用到的很多现代安全技术都是基于公私钥思路的。例如HTTPS就是基于公私钥思路的典型Web协议。
如果还没有绕晕，就继续往下看，但是，下面的两个例子可能有点晦涩了。
现在，以微信为代表的第三方开放平台搞得红红火火，开放API的安全问题也是大事，我们就趁热打铁来学习一下两种典型API认证方式：
1、appID/Secret 认证方式
开放平台和可信方服务器之间使用这种方式。例如微信平台开发者就是按照类OAuth2.0协议，根据appID/Secret从微信服务器得到accessToken后再访问微信API的，如果H5开发者想使用JS-SDK，还需要根据accessToken等参数计算signature；
步骤如下：
1.1、使用APPID和APPSecret获取access_token；
1.2、使用access_token获取jsapi_ticket ；
1.3、用时间戳、随机数、jsapi_ticket和要访问的url按照签名算法拼接字符串；
1.4、对第三步的字符串进行SHA1加密，得到签名signature；
1.5、把signature通过config接口注入权限验证配置jsApiList，至此就可以使用JS-SDK相关的JSAPI了。
2、Session 认证方式
是根据客户登录后种cookie生成Session提供服务；
步骤如下：
2.1、通常https服务端有一套公私钥，明文下发公钥，如果中间有代理伪装假证书，根据PKI原则，客户端会提示非法证书；
2.2、如上文Case4中讲的，客户端会用下发的公钥加密一个对称key，发给服务端；
2.3、服务器和客户端之间就可以用这个对称key加密传输了；
2.4、登录后，服务端可以根据用户系统种cookie，生成token，给token加MD5/SHA1 checksum；
2.5、下次客户端请求服务器，把cookie带上，通过MD5/SHA1验证token，验证合法用户，则免密通过。
好吧，终于说完了，希望你有收获。
关注我们（微信公众号 技术管理那些事 ID jsglnxs），扩展阅读