u盘加密设备



描述拥有micro-sd卡插槽,32位ARM,和硬件加密的U盘

每一个(几乎所有)磁盘加密使用XTS,我认为我们可以做得更好。

在这里Niels Ferguson写道:我们可以很容易的往密文里添加一个nonce或MAC值，但是，然而,使密文比明文还大却不可行，不管是磁盘还是操作系统工作的扇区，他们的大小都是2的幂次。
我们可以将512字节的操作系统扇区映射到1024字节的磁盘扇区，但这将导致磁盘的容量损失一半，用户不愿意这样。
我们也可以在每16个部门中保留一个部门来存储其他15个部门的MAC和nonce值，但这有几个问题：

首先，写入扇区x意味着更新了一个额外扇区的nonce和MAC。这样写入会导致读写相关性能的损失。

此外,它可能会损害nonce/MAC数据区(比如发生电源故障时),这将导致其他14个数据部门的损失;这也是不能接受的。

最后,由于不同的可用性、可管理性和部署的原因,必须能够启用和禁用对现有的磁盘驱动器加密。(想象一下用户升级到一个新的Windows版本，他要也能进行磁盘加密并且在现有磁盘上启用磁盘加密)。

添加nonce/MAC的扇区会修改磁盘布局(减少大量的可用磁盘空间)使它的就地启用和禁用变的极其复杂。再加上转换过程中可能发生的各种故障模式，以一种可靠的方式进行转换是不太可能的。

最后的结论是,我们添加一个MAC到每个磁盘扇区的方式，不能被大多数用户所接受。

是的,为消费级磁盘加密,确实不可以这样。

但是对于你我而言，为什么不把安全放在第一位,再处理其他的问题呢？

所以，我们可以在16个扇区中预留1个，用来存储nonces和MACs。
通过使用intent-log来恢复因为电源故障丢失的数据。




组件1×stm32f415



usb的快乐时光所以,短暂停留在那里我写一个新的usb堆栈。(没有ST的usb代码来达到我想要的效果)

存在模小的bug,该设备目前正在我的mac上。







现在可用的测试代码

源代码和编译后的二进制文件现在在github上。

警告:实验性代码,风险自负。



演示

见视频



相关资料请见oshpark