加密的黑盒子
在2013年5月，我去帮助一家“云计算”公司，做他们的兼职顾问，指导他们把标准CentOS操作系统加密以后整合到标准1U或2U的服务器中，做成一个“黑盒”。其关键部份就是做加密，有人就说了，这有何难，用Linux系统自带的Luks加密啊。是，很简单。
那么，我来说说这次开发的环节吧，首先，“关机加密”是很容易做到的，硬盘拔下后内容不可读；其次，关于“开机加密”——把诸多设备号组序加权所得的值对硬盘加密，引导的时候预加载驱动取设备号用相同算法对硬盘解密，然后移交给操作系统让其自举也是没问题的，关健是要让整个引导过程不被干预和破解。
所有的繁琐开发实际就集中在引导过程的编写和加密，那么我设了几个子目标：
A.引导脚本是可以拆分为多个文件分别做二进制加密的；
B.如果引导环境和编译环境不一致（订制内核引导的系统下编译），这些二进制是不能运行的；
C.这些二进制分别去取各种设备号、并且做各种混合运算；
D.这些二进制文件是“生产”它们的量产脚本结合同一群设备号产生的，而且按生成顺序，后生成的还会校验前面的文件的完整性；
E.每个片段都对整个引导相关的环境都做完整性校验；
F.“量产环境”是通过网络来引导本地的物理机，通过“量产脚本”实现边检测硬件、加密各分区、边产生引导用的二进制文件的。生产时除了每个物理机硬件不同，每生产一台黑盒的“生产号”“客户信息”也是不同的，它们做为“常量”参于计算，并且生产数据库里备案……；
……——好了，这是一个满足“测不准原理”的小环境，观测者必须得到编译环境才能让程序运行，环境稍有改变或者观察者注入一些代码就会导致运行失败，以上这些内容做成了一个initrd包。
下一步可以改变打这个包的gzip算法，再到内核树里把解包这一段换成自己的算法，然后编译内核，再把引导区再做一层加密…，基本完成了“开机加密”。
补充：
在合作的初期，我带着一套现成的路由产品“黑盒”的生产过程去演示的，从空白物理机到完全硬件加密的产品生产出来只用了5分钟。但是所有现成的脚本和程序是不能给他们的——不然以后在专利和版权上扯不清。
我只对他们做方案上的咨询。做为一个外人，在具体指导实施中，对于别人企业的产品和人事是不能做太多干预和评价的，对一些人为的问题只能望洋兴叹——
1.我不能去改他们的产品线和产品系统，为了避嫌，我也不愿意接触他们的系统去涉密：
倘若企业是我的，这就好办了，根椐他们的产品系统（同样是CentOS，他们编译的内核版本不同），定制一个小的Linux，加上他们的JRE环境和JAVA程序，不会超出200M字节；然后再按前述加密，我可以把它做到大大小小的物理主机里面，每隔5分钟就能生产一台“密盒”，开机-->网络引导-->生产脚本执行分析、加密、挂载、灌内容，重启，完成。可以完成一个和Vmware ESXi一样优秀的产品。
我的小Linux很小可以实现网络引导，在做咨询的初期实现了驱动讲解和原理讲解，按前述的加密过程——实现了加密和不加密快速灌入系统的讲解；但是对于他们的系统而言不是相同内核和C库的，我做咨询的不应当也不可以亲自为他们定制产品，也不能把我的产品硬交给他们（产权会混乱）。
需要灌装的是他们的产品系统，到需要做加密灌入系统时候，则需要一个未加密的生产系统来引导，再做出一个加密的目标系统；他们的OS太大，接近4G字节，不适合网络引导，我主张把引导用的系统做个U盘，通过把驱动模块循环modprobe、验核、不匹配则unload的机制加载对应的驱动，再加载协议；后来，为了考虑他们的“工作进度”，退而求其次建议操作人去不同的物理机上测试核对驱动程序，运行时全部加载，这样做了一个通用“全部物理机”U盘。
2.这次合作我感到一些不愉快——
A.我要求同我做配合的人员必须是一位有经验的Linux SA，但是这个Fellow有29岁了，却连基本的Linux命令mount,md5sum…都用得有问题，不懂Linux的设备驱动和控制协议(ide,sata,ext4…)之间的区别…，他喜欢通过百度去查二手资料，却不去查Linux的"man help"或者查软件参数手册…。
我是去咨询框架和项目步骤的，不是去指导命令行的基本操作的，这就造成我很累。
B.我每周去两个下午，Fellow正常坐班，他有个习惯，一遇到问题就通过邮件在公司的局域网上用电子邮件广播（人手一封，并且抄送大领导），内容上报忧（遇到问题）不报喜（阶段性进展），而且点名请我帮助和支援，这就造成我很郁闷。于是每次关于步骤和原理的讲解、进度的安排我都拉上他的直接上司来旁听，如果你做的价值公司的决策层都不知道，那可是非常麻烦。
——以上教训说明：做为一个顾问，其它人对你的领域不是很熟悉，在工作交接上必须建立签收程序（拟定咨询大纲、然后定出各步骤工作提要，再去讲解，再让干系人签收，下达任务，也让干系人签收和执行）。