好久没有写日志了，倒不是这段时间没有所思，而是思得太多，做的也更多，也就没有时间写了。好了，言归正传，下面我们接着说说《谈谈网银和USB Key (四)》中最后提到的“带确定按键的USB Key仍然不够安全”的原因。

是的，带确定按键的USB Key可以做到每次使用硬件内部的私有密钥时都是持有者明确授权的（即持有者做了按下确认键的操作），但是不要忘记，你能保证被签名的数据就一定是你想要签名的数据吗？这句话听起来有点绕口，那么我们来举一个例子：

特别注明：本文中所提到的商家、银行、地点、人物等均为举例方便而用，没有任何明确或隐含的意义。如有雷同，那一定是你踩到狗屎了~~~
阅读这篇日志的剩余部分 »

自从六年前我从ASP阵营弃暗投明转向PHP阵营之后，就不时的与Apache打交道，Apache的配置也从1.3研究到2.2版。但是有一个问题一直困扰我，而且它不定时的就冒出来打击我一下，让我很是郁闷。

这个问题是这样的：把网站设置为需要进行SSL双向认证（即通过https://的方式访问网站，还需要有客户端数字证书），如果服务端是基于Apache的话，那么客户端（也就是浏览器）每次访问一个页面，对于页面上的每一份资源（一个页面通常包含很多资源，例如被html页面引用的.js/.css文件，页面中的各个图片、flash等等），都需要做一次数字签名。奇怪的是IIS服务器就没有这种情况。

每访问一个资源就做一次数字签名，这是一件恐怖的事情。一般情况下一个html页面都会包含十几个甚至几十个资源（特别是一些装饰用的小图片和一些小图标等等，每个文件也就两三KB，但是也需要进行数字签名），早期使用数字证书的时候基本上都是将数字证书保存在计算机硬盘上，数字签名也是由CPU来进行，一次数字签名也就几个毫秒，看起来影响就不大，但是随着技术的发展，后来都是以USB Key来对数字证书进行存储和运算，为了安全，数字签名就只能USB Key内部进行。试想一下，处理器速度一般就几M，高的也就几十M的USB Key处理芯片，在做数字签名的时候效率比起计算机两三个G的运算速度低了不少，即使经过特别优化，一般的USB Key做一次数字签名也需要十多二十毫秒。这种情况下，每访问一个资源就需要做一次数字签名，在打开一个网页的时候，就会发现有明显的延时，现象就是页面文字都已经显示出来了，而USB Key的指示灯还在狂闪（USB Key上通常有一个指示灯，当USB Key正在工作的时候就会闪烁，以提醒用户），然后才能够看到页面上的图片内容一个一个的显示出来。

这几年里，对于这个问题我一直都不求甚解，当初想通过修改Apache配置来解决，也试图在PHP脚本中加入Keep-alive之类的标记，但是终不得其法，渐渐的也就有了一个错误的认识，那就是Apache无法做到SSL状态的缓存，客户端访问每个SSL资源都必须重新重新经历握手、产生会话密钥等过程，所以每访问一个资源就会做一次数字签名。

这个错误的认识一直延续了好几年，在这几年中，当有人问到我这方面的问题时，我都毫不犹豫的告诉他这是Apache的问题，是出于安全性考虑才这样做的。但是另一方面，在我内心深处，还是隐约觉得事情不应该是这样的。终于，在一次封闭开发的过程中，我弄明白了事情的真相。
阅读这篇日志的剩余部分 »

本文一些内容纯属YY，如有雷同，乃是人品爆发。

好了，各位同学，现在我们已经知道黑客无所不在，无所不用其极，目标就是我们网上银行的存款，或者信用卡里的额度。前文《谈谈网银和USB Key (三)》已经简要描述了目前的USB Key的潜在不安全因素，现在我们就来看看如何应对。

关于键盘木马，有一些“软”的方法可以在一定程度上进行遏止。例如“软键盘”，就是不再让用户通过键盘来输入USB Key的个人识别码(PIN码)，而是在屏幕上显示一个虚拟键盘，用户需要通过鼠标点击虚拟按键来输入PIN码。事实上不仅仅是USB Key的PIN码输入采用这种方式，一些网银在不使用USB Key的，但是又需要更高级别安全性的一些地方，也采用“页面虚拟键盘”的方式，例如建行网银的登录页面就是这样的设计。还有一些USB Key的提供商也在键盘驱动上做文章：黑客不是想截取我的输入吗？好，我让你截个够！当进入PIN码输入状态的时候，底层键盘过滤驱动就自动产生无数的按键信息发送给上层软件，將真正的用户输入淹没在极大量的随机击键事件中，让键盘木马难以得知哪些是真的用户输入，哪些是假的。当然，上层软件知道其中的猫腻，可以从杂乱的数据中滤出真正的用户输入。

然而，这些方法都是治标不治本的，因为要完成持有者身份验证，就要將PIN码发送给USB Key，这PIN码总归会出现在电脑的内存中，这些方法只能够在一定程度上增加黑客破解的难度而已。

好了，我们不说这些小儿科的应对方法了，要真正提高USB Key的安全程度，就需要从USB Key的硬件使用方式上入手。
阅读这篇日志的剩余部分 »

因为种种原因，需要在公司的外网服务器上架构一个CA(证书认证中心)服务，于是乎，开始找免费开源的CA系统。找来找去，找到两个用得比较广泛的开源CA，一个是OpenCA，一个是EJBCA。前者是使用Perl开发的，后者，顾名思义，是Java开发的。

服务器是FreeBSD 7.0，先上的是OpenCA，是因为不想在服务器上装太多的东西，Perl是必装的，所以第一选择就是基于Perl的OpenCA了。使用FreeBSD的Ports方式安装，结果装的过程中发现有太多依赖的库，虽然这些依赖的库都会自动下载并安装，但是心里已经感觉不爽了。接下来的配置让人头疼不已，花了三天时间也没有搞定。

一怒之下，决定把OpenCA打入冷宫。上EJBCA吧，又是一大堆的东西要装，Java运行环境啦，tomcat啦，等等等等。让人郁闷的是要用到一些Java的加密函数库，还必须手工到sun的网站下一堆额外的东西，心里又是不爽起来。结果发现EJBCA的配置更是让人崩溃，近一个星期下来，一事无成。

我靠，装这两个东西，把我精心打造的服务器搞得乱七八糟。于是决定，自己开发一个CA。套一句话说：我是程序员我怕谁～～～

阅读这篇日志的剩余部分 »

注：本文涉及USB Key高级安全特性，供有一定网银使用经验及基本网络知识的同学阅读。

前面[谈谈网银和USB Key (二)]已经谈到，有了USB Key，我们的网银就“基本安全”了，那么，使用了USB Key还会有什么安全性的隐患，我们又该如何应对呢？

在进一步阅读之前，请先明确一个事实：一切安全性都是相对的。越是安全的系统，对用户的要求就越高，使用起来就越繁琐。我们只能在安全性与易用性之间找一个平衡点，而这个平衡点也会随着技术的发展朝不同的方向偏移。

阅读这篇日志的剩余部分 »