Why does Apple use One-Pass Diffie-Hellman for file encryption?

Question

I was reading the iOS Security Guide (snapshot) and stumbled upon the following file protection class on page 15:

(NSFileProtectionCompleteUnlessOpen): Some files may need to be written while the device is locked. A good example of this is a mail attachment downloading in the background. This behavior is achieved by using asymmetric elliptic curve cryptography (ECDH over Curve25519). The usual per-file key is protected by a key derived using One-Pass Diffie-Hellman Key Agreement as described in NIST SP 800-56A.

The ephemeral public key for the agreement is stored alongside the wrapped per-file key. The KDF is Concatenation Key Derivation Function (Approved Alternative 1) as described in 5.8.1 of NIST SP 800-56A. AlgorithmID is omitted. PartyUInfo and PartyVInfo are the ephemeral and static public keys, respectively. SHA-256 is used as the hashing function. As soon as the file is closed, the per-file key is wiped from memory. To open the file again, the shared secret is re-created using the Protected Unless Open class’s private key and the file’s ephemeral public key, which are used to unwrap the per-file key that is then used to decrypt the file.

Here the document explains that ECDH key exchange is used, but gives no explanation as to why it is needed at all.

It would be more obvious if there was some kind of network between two parties involved, but in this case the only network I can think of is the communication channel between the CPU and the Secure Enclave.

I guess that the answer lies in the "One-Pass Diffie-Hellman Key Agreement" scheme described in §6.2.2.2 of the NIST SP 800-56A (snapshot) document and how it is different from "normal" Diffie-Hellman, but the document goes straight into details that are rather hard to digest.

Answer 1

If you have a look in the introductory paragraph of Section 6.2.2 of the NIST SP 800-56A document, you will find an explanation of how the one-pass key-agreement protocol is supposed to work.

If I understand the description you are quoting correctly, some public ECDH key corresponding to a static ECDH key pair is used to encrypt files while the device is locked, because the actual symmetric encryption key is only available when the device is unlocked. Furthermore, each file gets encrypted with a separate per-file key. This is where the one-pass key-agreement comes into play. In particular, one uses it to derive a per-file key, which is in turn used to encrypt the actual file (one has different keys per file since the ephemeral keys are freshly chosen for each file). Then, as soon as the device gets unlocked one can use the static secret key corresponding to the ECDH key pair to obtain the per-file key using the key agreement protocol and then store/encrypt the file as it would have been stored/encrypted if the device would have been unlocked in the first place.