Intel SGX Protected File System Security Assurances

[nyxon]

Hello, I read the documentation of Intel Protected File System Library and some Intel Community Threads together with some SGX File System Papers, but I still have some questions, regarding the security assurances of this file system implementation. Intel SGX adversary model, suggests a malicious OS.

Intel protected fs guarantees the integrity and confidentiality of data, as it states, but not their recoverability.

there is no protection against malicious file deletion or modification:

Now, for example lets suppose a user reads/writes a file under a honest OS throughout a day and at some point the OS is compromised and an attacker gains privileges. This mean that the user can no longer read or write contents of the file securely, because the attacker can highjack the system calls and see the content right?

Or, in case the user closes the file before the OS is compromised, the malicious user can tamper/overwrite the already stored files (suppose for simplicity that he will overwrite many locations, so some of the encrypted ones will be overwritten as well) but nothing more that that or he can wait till the user tries to open the file again for read/write and eavesdrop? (previous case basically again)

Also, in case the OS is already compromised and a user will try to initiate an enclave for some fs operations, the attacker can now forge an enclave himself to read/write files, stored by the user, because he is able to see even the private key that will be used to start the enclave? (sure, he must have other user's file names knowledge)

So, intel protected fs and (dare to say) many fs that are implemented with the assistance of SGX [let's suppose under an ordinary OS, not one that can utilise SGX for kernel assistance or an SGX cointainer (graphene-sgx)], can only guarantee that a privileged attacker cannot violate the integrity (he can, but it will result in error after the enclave will try to verify that nothing was tampered, even if himself can forge an enclave) and confidentiality of already stored data but no other file system operation under the malicious OS, even operations that target these already stored data?

This question targets the use of the intel protected file system library under a local OS scope and not a transfer of data between a cloud server (with even a malicious hypervisor or OS) and a local honest OS.

[Iffa_Intel]

Hi,

we are investigating this and will clarify this issue back to you as soon as possible.

Cordially,

Iffa

[Sahira_Intel · Accepted solution]

Hi,

Now, for example lets suppose a user reads/writes a file under a honest OS throughout a day and at some point the OS is compromised and an attacker gains privileges. This mean that the user can no longer read or write contents of the file securely, because the attacker can highjack the system calls and see the content right?

Or, in case the user closes the file before the OS is compromised, the malicious user can tamper/overwrite the already stored files (suppose for simplicity that he will overwrite many locations, so some of the encrypted ones will be overwritten as well) but nothing more that that or he can wait till the user tries to open the file again for read/write and eavesdrop? (previous case basically again)

No, not necessarily true. The hacker could definitely prevent access to the files by hijacking system calls - which is a denial-of-service or DOS attack. SGX does not prevent against DOS. But with Intel Protected File System, the content is encrypted inside the enclave before it becomes an actual fwrite in the external OS via an SGX ocall. So even if the OS syscalls are hijacked, the data the malicious user would see is encrypted.

Also, in case the OS is already compromised and a user will try to initiate an enclave for some fs operations, the attacker can now forge an enclave himself to read/write files, stored by the user, because he is able to see even the private key that will be used to start the enclave? (sure, he must have other user's file names knowledge)

What "private key" are you referring to here? An enclave is signed by a developers private key, but it is not stored in the enclave - it is of course stored somewhere securely by the developer (HSM, USB key locked in a secured cabinet, etc.) Also, to use his own enclave to try to read the encrypted files would depend on the way the key was derived that does the file encryption/decryption. If it is derived from MRSIGNER (a hash of the developer's private key), the malicious user would need to have access to that private key, which he wouldn’t. If it was derived on MRENCLAVE (the measurement of the enclave binary), then the malicious user couldn’t use his own enclave to read the files, as the measurement would not ever be the same.

So, intel protected fs and (dare to say) many fs that are implemented with the assistance of SGX [let's suppose under an ordinary OS, not one that can utilise SGX for kernel assistance or an SGX container (graphene-sgx)], can only guarantee that a privileged attacker cannot violate the integrity (he can, but it will result in error after the enclave will try to verify that nothing was tampered, even if himself can forge an enclave) and confidentiality of already stored data but no other file system operation under the malicious OS, even operations that target these already stored data?

If you are implying that all SGX can do is protect someone from getting the data stored inside a file encrypted by PFS, then yes that is true.

Sincerely,

Sahira