传输协议制定案例

一、昨天一个做共享汽车的朋友向我咨询关于蓝牙开车门的安全方案（因为最近他们公司的服务器被黑客攻击，所以所有研发项目都要考虑安全性了）。（2017年12月8日）

具体需求：手机APP连接车上车BLE模块控制门锁，要求整个流程不能被别人破解其中的数据。其中任何车辆和手机之间都不是一对一关系， 需要任意时刻都能改变授权。据述数据量在80字节左右。

探究过程：

1、根据 BLE的特点，需要兼容旧设备的话数据包就不能超过20字节，并且现在需要的是安全方案，那就要用到AES128，所以数据包定在16字节内是必须的。

2、为避免数据被直接copy，这样就必须包含一个变化的参数（随机码、时间戳、流水号等）。然而手机终端每次都可能不一样的，又怎样知道对方的随机码呢？（这里当然是可以通过网络来同步了，但是车辆和手机都是无线设备，是否有信号、网络的实时性、服务器瘫痪等都是致命硬伤，所以不得考虑走网络通道）此时想到可以用RTC时间（手机UTC）， 其中手机时间误差是比较小的， 而BLE模块可以设定一定的误差范围就可以了，只要在每次合法连接后都同步时间，那时间就不会造成累积误差了。可是这样在短时间内还是有可能被直接copy数据进行同样的操作（因为有时间误差）。这样就必须有流水号来区分了。

3、以上所述：要用到流水号，若有流水号了，那时间戳就不一定必须的了，并且流水号又应该怎样同步呢？问题似乎又回到了原点。

怎样同步流水号？怎样同步流水号？怎样同步流水号？......

OK！终于想到了，BLE有31字节的广播数据包，只需要占用广播数据包的16个字节进行 AES128加密，同步的流水号就加载到这加密的广播数据里面，APP在操作时读取这个广播数据里面的信息就顺利操作了。

4、还有一些小问题。

停车场里面有多辆共享汽车怎么办？广播里面包含车牌号不就得了。

这全部的80字节的数据该怎么传输？这关系到协议的操作流程问题。按照合理的思路，整个流程应该要有“确权”的概念。就是连接上以后，要经过1-3次的握手，确定对方的合法性，确权后在连接断开前的所有操作都是合法的。这样，确权后这80字节的数据想怎么传就怎么传了（当然也要经过AES128加密了）。

到此，基本上整个流程都是完整的、安全的了，除非AES被破解或者KEY泄露，否则无人能破了。

现在梳理一些整个流程：

1、车载BLE模块广播加密后的车牌和流水号信息

2、手机终端通过广播的车牌信息连接到目标车辆，然后通过广播的流水号“确权”，然后进行正常的通讯、操作。

3、连接断开后BLE模块更新“流水号”再开启新的广播。