前几天在网上学会《使用人际关系软件 Obsidian 高效可视化管理好你的人脉》,就做了一些简单的测试,发现该程序都是一些 .md 常规文件,很容易就被其他的看到,或者被他人看到。而且缙哥哥还是使用了云盘同步了这些内容,那么怎么样才能安全的加密文件呢?不至于让文件泄密!
通过大量的查阅、学习。首先排除使用《Windows Server 使用 Bitlocker 驱动器加密磁盘保护数据》,因为它是加密整个磁盘分区,而不能针对性加密。加上需要云盘同步,这个加密性几乎为零。最终我选择了免费开源的 Cryptomator 加密程序,它完美的符合我的需求,今天就与大家分享。
Cryptomator 适用性
Cryptomator 旨在解决将文件保存到云存储时的隐私问题,也就是说哪怕你使用云端同步,该软件也能帮你进行加密。目前缙哥哥认为它仅适用于 PC 端,移动端用起来非常麻烦,且需要程序付费。
为了允许与云进行工作同步,Cryptomator 不加密一些元信息。 这些是:
- 访问、修改和创建文件和文件夹的时间戳,
- Vault 和文件夹中的文件和文件夹数,以及
- 存储文件的大小。
此外,您必须牢记 Cryptomator 不是什么。 保护本地计算机上的文件不是 Cryptomator 的重点。 如果上述元信息应该加密,Cryptomator 不能完全替代其他基于容器文件的加密工具。 如果程序在使用加密文件时创建加密文件的备份副本,则 Cryptomator 不提供保护。 Cryptomator 不会检测到此类文件,即使在解锁保险库后也可能保留在计算机上。 如果本地计算机感染了读取输入的密码和文件内容(例如,未锁定的保管库中的文件)的恶意软件,则 Cryptomator 无法提供保护。
为了防范此类风险,需要其他方法,例如完整的磁盘加密(如 Bitlocker)、立即安装系统和软件更新以及使用适用的防病毒软件(需要注意的是,请选择一些保护隐私的安全软件)。
Cryptomator 加密优点
虚拟文件系统
Cryptomator提供了一个虚拟驱动器(可以自定义盘符,就像C盘D盘)。添加、编辑、删除文件,就跟平时一样使用。在这里文件是正常状态(解密的状态),硬盘驱动器上没有未加密的副本。 每次访问虚拟驱动器内的文件时,Cryptomator 都会即时解密这些文件,而你自己感觉不到。
加密库配置
每个加密库 Vault 都必须在 Vault 的根目录中具有一个名为 Vault 配置文件。 它是一个 JWT,包含有关保管库的基本信息和规范要使用的密钥。 JWT 使用 512 位原始主密钥进行签名。该文件名及后缀为vault.cryptomator
。
主密钥
每个保管库都有自己的 256 位加密以及 MAC 主密钥,分别用于加密文件特定密钥和文件身份验证。这些密钥是由 CSPRNG 生成的随机序列。 我们将 SecureRandom 与 SHA1PRNG 一起使用,以 440 位为种子。SecureRandom.getInstanceStrong()
这两个密钥都使用 RFC 3394 密钥包装进行加密,并使用 scrypt 从用户密码派生的 KEK。然后,将包装的密钥和派生 KEK 所需的参数存储为整数或 Base64 编码的字符串,该文件位于保管库的根目录中。masterkey.cryptomator
解锁保管库时,KEK 用于解包(即解密)存储的主密钥。当你没有运行 Cryptomator 主程序时,双击masterkey.cryptomator
即可进入到解密界面。
文件头加密
文件头存储文件内容加密所需的某些元数据。 它由 68 个字节组成。
- 标头有效负载加密期间使用的 12 字节随机数。
- 40 字节 AES-GCM 加密有效负载,包括:
- 8 个字节,其中填充 1 以备将来使用(以前用于文件大小)和
- 32 字节文件内容密钥。
- 加密有效负载的 16 字节标记。
文件内容加密
这是您的实际文件内容被加密的地方。
明文被分解为多个块,每个块最多 32 KiB + 28 字节,包括:
- 12 字节随机数,
- 使用 AES-GCM 和文件内容密钥,最多 32 KiB 加密有效负载,以及
- GCM 使用以下 AAD 计算的 16 字节标记:
- 块数为 32 位大端整数(以防止未检测到的重新排序),
- 文件头随机数(将此块绑定到文件头),
之后,加密块被连接起来,保留明文块的顺序。 最后一个块的有效负载可能小于 32 KiB。
目录 ID
每个目录都有一个唯一的 ID,在文件名加密期间需要该 ID。 由于历史原因,目录 ID 是一个字符串,即使任何字节序列都可以完成这项工作。
根目录的目录 ID 为空字符串。 对于所有其他目录,它是最多 36 个 ASCII 字符的随机序列。 我们建议使用随机 UUID。
dirId := createUuid()
遍历目录时,将分四个步骤处理给定子目录的目录 ID,以确定保管库内的存储路径:
- 使用 AES-SIV 加密目录 ID,以便加密目录层次结构。
- 创建加密目录 ID 的 SHA1 哈希以获得统一的长度。
- 使用 Base32 对哈希进行编码以获得一串可打印的字符。
- 从 Base32 编码的哈希中构造目录路径。
dirIdHash := base32(sha1(aesSiv(dirId, null, encryptionMasterKey, macMasterKey)))
dirPath := vaultRoot + '/d/' + substr(dirIdHash, 0, 2) + '/' + substr(dirIdHash, 2, 30)
无论明文路径的层次结构如何,密文目录始终存储在扁平化结构中。 因此,所有目录实际上都是同级。
文件名加密
文件的明文名称在规范化形式 C 中使用 UTF-8 进行编码,以获得唯一的二进制表示形式。
Cryptomator 使用 AES-SIV 来加密名称。 父文件夹的目录 ID 将作为关联数据传递。 这样可以防止在目录之间未检测到文件移动。
ciphertextName := base64url(aesSiv(cleartextName, parentDirId, encryptionMasterKey, macMasterKey)) + '.c9r'
根据节点的类型,加密名称将用于创建文件或目录。
- 文件存储为文件。
- 非文件存储为目录。然后,节点的类型取决于目录内容。
- 目录由包含上述目录 ID 的名为的文件表示。dir.c9r
- 符号链接由名为的文件表示,其中包含加密链接目标。symlink.c9r
- 在将来的版本中可能会附加更多类型。
因此,明文目录结构如下所示:
.
├─ File.txt
├─ SymlinkToFile.txt
├─ Subdirectory
│ └─ ...
└─ ...
变成密文目录结构,如下所示:
.
├─ d
│ ├─ BZ
│ │ └─ R4VZSS5PEF7TU3PMFIMON5GJRNBDWA
│ │ ├─ 5TyvCyF255sRtfrIv**83ucADQ==.c9r # File.txt
│ │ ├─ FHTa55bH*sUfVDbEb0gTL9hZ8nho.c9r # Subdirectory
│ │ │ └─ dir.c9r # contains dirId
│ │ └─ gLeOGMCN358*UBf2Qk9cWCQl.c9r # SymlinkToFile.txt
│ │ └─ symlink.c9r # contains link target
│ └─ FC
│ └─ ZKZRLZUODUUYTYA4457CSBPZXB5A77 # contains contents of Subdirectory
│ └─ ...
├─ masterkey.cryptomator
├─ masterkey.cryptomator.DFD9B248.bkup
└─ vault.cryptomator
名称缩短
提示:此层不提供任何额外的安全性。 其唯一目的是最大限度地提高兼容性。
为了最大限度地提高兼容性,需要确保密文名称的长度不超过 255 个字符。 因为某些云盘在云端同步服务可能希望在发生冲突时向文件添加后缀,因此加密最多使用 220 个字符。
如果加密名称(包括其扩展名)超过这 220 个字符,我们将创建一个以其短得多的 SHA-1 哈希和扩展名命名的目录。 此外,我们将创建一个名为反向映射文件,其中包含此目录中的原始文件。.c9r
/.c9s
/name.c9s
备份目录 ID
注意:此层是可选的,对于完整实现 Cryptomator 加密方案不是必需的。 它不提供任何额外的安全性。 其唯一目的是在目录文件丢失或损坏的情况下提高数据可恢复性。
通过使用包含目录 ID 的文件对明文路径的层次结构进行模糊处理,目录结构更容易受到同步不完整或位腐烂等问题的影响。dir.c9r
当目录文件丢失或损坏时,无法计算,这实际上使虚拟文件系统中无法访问目录内容。 从理论上讲,这些文件的加密内容的内容是可以恢复的。 但是,由于文件名加密依赖于父文件夹的目录 ID(仅存储在目录文件中),因此所有项目(文件、目录或符号链接)的名称都将丢失。dirPath
为了缓解此问题,在创建目录期间将存储备份目录文件。 在密文目录中,将创建一个名为的文件,其中包含其父文件夹的目录 ID。 它像常规密文文件一样被加密。dirid.c9r
评论前必须登录!
注册