I am developing a library called MemoryCryptor for macOS. Its purpose is to protect sensitive data of the calling process (including launchd daemons), e.g. user passwords and other secrets, from being written to disk or read directly by debuggers or malware. This is a mandatory security requirement from our internal Security Team. On Windows we rely on DPAPI, which stores a per‑process cryptographic key outside the calling process’s address space, ensuring that key material and ciphertext never coexist in the same memory space. I have evaluated the following macOS options, but each presents limitations for our threat model:
- Secure Enclave (CryptoKit.framework). Keys generated using the Secure Enclave are not bound to the creating app. The dataRepresentation of a PrivateKey resides in the caller’s memory, allowing another process that can read a memory dump on the same machine to decrypt the data.
- Keychain API. Keys are always loaded into the calling process’s address space before any cryptographic operation, exposing them to memory‑dump attacks.
- Separate helper via XPC. While this could isolate key material, it requires full control of IPC implementation - plaintext may remain in the implementation's internal buffers.
Given these constraints, are there any macOS‑native mechanisms or recommended architectures that allow us to keep cryptographic keys completely out of the calling process’s memory while still performing encryption/decryption on behalf of that process? Any guidance, best‑practice references, or alternative APIs would be greatly appreciated. Thank you for your assistance.
