可选的内存查看器模式,可避免将明文暴露给外部应用程序

当您安装一个卷时，该部分是固定的。但是一旦您使用外部应用程序（图像查看器、PDF阅读器、媒体播放器）打开文件时，VeraCrypt就失去了对其的控制。该应用程序可以缓存缩略图、写入临时文件、将文件名添加到最近文件列表中，或者只是让操作系统分配解锁的内存以进行交换。这些都不是 VeraCrypt 的错，但在实际应用中，保密性保证在您实际使用文件（而不是仅安装容器）的那一刻就消失了。最近添加的屏幕截图保护可以保护 VeraCrypt 的窗口，但无法保护打开文件的任何应用程序。隐藏卷解决了不同的问题（不可否认性，而不是此问题）。将文件挂载到 RAM 磁盘也无法帮助 - 外部程序从中读取仍然以完全相同的方式行为。我建议的方案是：用户可以直接从 VeraCrypt 浏览文件列表，打开文件则直接解密到锁定的内存缓冲区中，通过内置的小型查看器（文本、图像、PDF）显示 - 没有外部进程、没有挂载路径、没有操作系统缓存或索引。处理内存的方式与您目前处理敏感缓冲区的方式相同：锁定、关闭时清零、活动期间不产生核心数据丢失。我知道这不是免费的。将图像/PDF 解析器放置在安全性至关重要的进程中是一个真正的攻击面 - 解析器 bug 是 CVEs 的主要来源之一（libpng、pdfium 等）。如果您有机会实现此功能，我会从小处着手 - 文本、一个图像格式、基本 PDF - 老实说，解析应该在一个单独的沙箱进程中运行，与核心进程通过一个窄通道进行通信，而不是放置在受权代码中。没有与磁盘进行任何交互的视频/音频是真正的跨平台难题（解码器通常需要真实的文件句柄），因此我会在第一个版本中完全将其排除在外。这不会取代“挂载为驱动器”功能，后者仍然需要处理真正的文件 I/O。它是针对特定情况的，即在不将文件交给 VeraCrypt 外部的任何东西的情况下查看少量敏感文件。我构建了一个端到端工作的概念证明（Python，并不是提出代码本身，只是展示它是可行的）：双层 AES-GCM+CBC 容器完全保存在 RAM 中，锁定/清零内存，内置的图像、PDF、文本、音频和视频查看器，对每个窗口都进行屏幕截图保护。仓库：https://GitHub.com/zmykerd/bcypherpy