从实体密保卡到动态口令令牌

背景

前段时间回顾了一下小时候玩的梦幻西游，忽然想到了小时候玩游戏时的一个问题：为什么在我手中的将军令可以用于在线的网络游戏的登录验证？是因为十几块钱的玩意还能发送信号不成？带着这个疑问，我去研究了一下。

实体/电子密保卡

梦幻西游需要充值点卡，开始的时候只是单纯的去买点卡，直到有一天，发现点卡背后多出了一个密保卡，介绍里是说密保卡可以用于登录游戏或其他安全操作时的动态密码验证。

这种验证方式比较简单，就是每个序列号都随机生成一个矩阵，用户通过序列号绑定到自己邮箱账户后，登录时界面会随机出现三个坐标，将该坐标的值填入输入框就可以了。
实体密保卡这种验证方式虽说可以一定程度上的防止被盗号的风险，但毕竟实体密保卡矩阵就这么大，而且不会改变，如果被人多记录几次，实际就可以在复制出一份一样的密保卡了。

将军令

后来网易推出了将军令，其实就是简易版的银行U盾，和账号绑定上之后，每次登录游戏时需要输入将军令上的6位动态密码，由于将军令的密码生成不会通过网络传输，所以即使账号密码被盗，也登录不上游戏。

将军令以帐号+密码+动态密码的形式对游戏id进行保护众所周知，将军令每隔一分钟变化一次6位数密码，俗称动态密码。
由于用户端（将军令）在出厂之后，同服务器端就再没有物理上直接的联系，因而，如何与服务器端保持逻辑上的同步是最大的问题，即如何保证用户端产生的动态密码与服务器端验证的动态密码是一个密码？
猜测：用户端产生的动态密码是一个与时间有关的动态密码，即密码M与时间T之间存在着关系：M=rand（TX），rand（）为随机函数，TX为随机函数的种子，X为另一因素，比如将军令的序列号等。
(1)X是一个服务器端已知的变量，出厂时就已经设定了，最大的可能是将军令的序列号、服务号或者序列号服务号所对应的一个因子，在生产将军令写入初始数据的时候，同时植入用户端和服务器端，由于每个将军令的序列号和服务号唯一，因而，拿不到将军令就无法知道X，也就无法知道动态密码M。
显然，只有因子X是不够的，M=rand（X），是产生了一个密码M，但显然无法动态变化，失去了意义。因而因子T不可缺少。

(2)分析下，植入T之后，服务器端的T1受服务器端时钟影响，用户端T2受用户端时钟影响，问题出现了，如何保证在运行一段时间以后，T1=T2？一个方法是采用高精密的材料，保证在3年的时间里T1=T2，明显成本巨大，以市场上30元左右的电子手表为例，要保证成千上万个电子手表3年内的误差不超过1分钟，可以说是天方夜谈。

(3)假设：服务器端固定T0，引入因子△t，服务器端植入△t，△t为用户端时钟同服务器端时钟之差，即△t=T2-T1。这样，用户端（将军令）端的密码M=rand（T2X），服务器端密码M=rand[（T1+△t）X]，这样，对于成千上万的用户端（将军令）在服务器端只要记录了△t，就可以了。这个△t，可以在将军令生产的时候植入服务器端予以记录。

(4)同步的问题可以这样解决，服务器端动态的调整△t。在开通将军令的时候，在提交序列号和动态密码的时候，服务器端计算M=rand[（T1+△t）X]，并且在△t的基础上，计算出…，△t-560，△t-460, △t-360, △t-260, △t-160, △t, △t+160, △t+260, △t+360, △t+460, △t+560,…这个数列。具体数列长度根据需要来定，由于是随机6位数的函数，在这个数列中是不会出现重复的M的。这样，就可以计算出△t附近前后相差n分钟所产生的密码M，只需要比对提交的动态密码与数列中的哪个值对应，就可以动态的调整△t。假设，动态密码与△t-260对应的密码相同，就可以调整△t=△t-260。这样，解决了用户端（将军令）从出厂到开通使用所产生的时间误差。这个n，根据实际需要制定，如果出厂1个月就差几个小时的话，那将军令的质量就忒差了。

(6)在确定了△t后，服务器端在每次验证的时候，只要算出M1=rand[（T1+△t-y）X]，M=rand[（T1+△t）X]，M2=rand[（T1+△t+y）X]，就可以算出△t附近y秒的时间的密码M，就是允许将军令有y秒的时间误差。在具体使用中，有人已经测试证明将军令是有时间误差的。如果服务器端的M与将军令的M不一样，而是服务器端的M1与将军令的M一样，就可以实时的进行动态调整△t=△t-y了，实现将军令同服务器端时间上的同步。