为内存加密密码是否过大？

Question

我需要为 Mac 构建一个安全的应用程序。为此，我使用了仅存在于创建者头脑中的主密码。

要检索它，首先需要在安全的文本字段中输入密码*，然后才能使用它来加密和解密文件。当应用程序保持打开状态时，主密码将存储在一个变量中，这意味着它存在于内存中。在内存中加密这个密码会不会过大？

我问这个问题的原因是，在可以为内存加密主密码之前，它已经作为变量存在，这意味着它已经对内存扫描攻击开放。这是我应该担心的事情吗？

我在https://www.apple.com/macos/security/阅读了以下内容：

运行时保护是核心防御。技术成熟 macOS 中的运行时保护在 Mac 的核心工作，以提供帮助 确保您的系统安全。 XD（执行 disable) 功能在用于数据的内存之间创建了一道坚固的墙 和用于可执行指令的内存。这可以防止 试图欺骗 Mac 以相同方式处理数据的恶意软件 它处理程序以破坏您的系统。地址空间 布局随机化 (ASLR) 改变了内存位置 存储应用程序的不同部分。这使得一个人很难 攻击者通过查找和重新排序应用程序的各个部分来造成伤害 它做了一些它不打算做的事情。 macOS 将 ASLR 带入 操作系统核心内核使用的内存，所以 在 Mac 的各个级别上都可以使用相同的防御措施。

我可以断定 Mac 已经内置了防止内存扫描和劫持的保护吗？

(* 我知道这可能会导致键盘记录器漏洞)

Answer 1

在任何情况下，您都将首先从用户密码中获取一个密钥，然后使用该密钥来加密文件。因此，您可以立即使用密钥推导函数计算密钥，并将密钥保存在内存中，而不是将密码保存在内存中。你得到的好处是，攻击者只能知道密钥，它允许解密文件，而不是原始密码，它可能被重复使用。

一些操作系统提供了一个专门的SecureString，它可能是你能得到的最接近你想要的东西，它在内存中保存了一个加密的字符串，并且可以从那里删除它。我不知道 OSX 是否提供了这样的功能。

我怀疑内存中的加密密钥是否有用。如果攻击者能够分析内存，（s）他可能也能够解密内存，那么应用程序毕竟必须能够解密密钥。但当然它提高了标准，需要做更多的工作。

在我看来，链接的文章解决了另一个问题，它阻止了将可执行代码（作为输入数据）放在内存中并欺骗处理器在之后执行它。

Answer 2

mach_inject 和Cycript 等工具的存在清楚地表明您的程序的内存永远不会安全。在 iOS 世界中，钥匙串的安全性来自于钥匙被刻在单独的硬件芯片中并且永远不会复制到应用程序内存中的事实。如果您根据定义在程序内部进行加密/解密，则很容易以某种形式被劫持。需要考虑的关键事项：

• 您要保护什么？数据？加密方式？两者都有？
• 如果攻击者可以访问您的二进制程序，很可能会对其进行逆向工程，这意味着什么？
• 您是否需要在您的程序中进行实际的加密/解密？如果将数据有用所需的至少一个关键步骤移至外部后端，则可能会更安全
• 用FileVault 或TrueCrypt 等文件系统加密来补充您的解决方案将始终提高安全性