Keepassxc: Add SGX-protected memory access to KeePassXC

[conz27]

Use Intel SGX for sensitive operations involving the encryption/decryption and in-memory storage. This has the ability to provide resistance against memory dumps, protect encryption/decryption keys and operations on the KeePassXC database, and generate secure random numbers.

Users with CPUs on this list will benefit from it:
https://ark.intel.com/Search/FeatureFilter?productType=processors&SoftwareGuardExtensions=true

For more information on SGX:
https://software.intel.com/en-us/sgx

[droidmonkey]

SGX is not free, or at least the sdk isn't. https://software.intel.com/en-us/license/intel-software-guard-extensions-licensee-guide

I would much prefer to secure sensitive memory locations using a TPM chip instead.

[conz27]

I read somewhere that Intel was subsidizing the license costs for open-source projects ... if that is in fact true, then this project would surely qualify.

[droidmonkey]

There is also OpenSGX

[simon-struk]

Hello, I am interested in implementing the protections using a TPM, if you can give me any directions or suggestions, I will be grateful :)

[droidmonkey]

Do you have any experience integrating TPM? If not, I do not recommend you work on this issue as your first one for this project.

[conz27]

@droidmonkey, who would be the right person to scope this feature out with?

I'm not too familiar with the code base and might need some help scoping out what SGX support actually means in the context of KeePassXC.

[simon-struk]

@droidmonkey I don't have previous experience, but I would still like to try (I'm actually writing my master thesis on TPMs). Is there a particular reason why you don't recommend it?

[phoerious]

Because it is advisable to have some prior experience with both SGX and our code base in order to contribute a correct implementation.

[conz27]

@phoerious / @droidmonkey ... any answer to my question?

[conz27]

@droidmonkey, who would be the right person to scope this feature out with?

I'm not too familiar with the code base and might need some help scoping out what SGX support actually means in the context of KeePassXC.

@phoerious / @droidmonkey ... any answer to my question?

[droidmonkey]

@conz27 sorry missed the reply on this. The right person would be someone who has done an SGX integration, or for TPM someone who has done cross platform in-memory encryption using TPM. I am not comfortable doing it myself, and that is saying something because I love a good challenge. This is kind of like "don't write your own crypto".

[conz27]

@droidmonkey I've been working with SGX for the last year and a bit - I don't claim to be an expert in SGX but my company sees fit to pay me for my efforts with it :). It's one of the core technologies we work with day in and day out.

The analogy to "don't write your own crypto" isn't quite accurate in this case because SGX would only provide a secure "container" (or "enclave" in SGX terminology) for you to execute your crypto. By adding SGX support, you can't become less secure because there is no Trusted Execution Environment (TEE) solution in KeePassXC to begin with.

The only way I'd feel comfortable merging any of my work is if it's peer-reviewed by other cyber-security developers. So I'm in no rush to integrate and merge right away - I'd add it as an experimental/beta feature and see the feedback.

I just need someone who is familiar with the code base for me to ask questions and bounce ideas when it comes to implementation / feature behavior as I go along.

[droidmonkey]

If you push your branch to your personal fork of KeePassXC I will take a look and leave comments

[conz27]

Sounds good - I'll get started on it in the coming week and see where it goes from there.

[rugk]

I looked into how that SGX works a little and I think it is...

• really complex, so also your enclave code is hardly bug-free (not to speak with the Intel code they have there)
• your dev computer needs to be 100% trusted
• code must be constant time, everything
• you need to be have some Intel license to even distribute that code
• you need to do all fancy handshakes to "communicate" with the enclave
• I am not sure whether it is even possible to built it in a secure way without remote attestation (a remote server that has a direct connection to the SGX) as secrets need to be passed in and out of the enclave
  Edit: Actually see slide 14 of the PDF I linked, they say "SGX mostly useless without [remote attestation]"...
• And slide 16: To store data, you need to encrypt it and store it outside of the enclave. 😄
• finally maybe the most problematic thing: (slide page 12)

No secure human I/O: enclave may compute the right result, but the system may show the wrong one on the screen

And obviously at some point we need to show the password to the user or enter it into an application or so. As such, it has to leak out of the secure enclave and be even sent to browsers or so.

That all seen, I doubt SGX is really applicable here and makes not really much sense as you cannot run the whole password manager in the secure enclave. While it may possible to implement it, I think it would be unneccessary complexity and in the end does not provide that much protection.

That said, I also only know the points listed above of that technology and possibly it helps in some circumstance/way, as I really cannot completly judge the technology for that use case here. However, I think the pointers/problems I've given show it may not be _at least_ the intended use case of the technology...

Edit: Also a useful link: https://eprint.iacr.org/2016/086.pdf

[droidmonkey]

The biggest problem is, as of today, you must use Visual Studio 2012 to even use the SDK! It is also not open source.

[conz27]

The biggest problem is, as of today, you must use Visual Studio 2012 to even use the SDK! It is also not open source.

That's not true. Here is the source code for the SGX SDK (https://github.com/intel/linux-sgx) - I develop against it in a Linux environment every day, so let's actually try to be accurate about the statements we make.

[conz27]

@rugk

I looked into how that SGX works a little and I think it is...

* really complex, so also your enclave code is hardly bug-free (not to speak with the Intel code they have there)

False, your enclave code is very small compared to untrusted coded hence much easier to make it bug-free.

* your dev computer needs to be 100% trusted

False, you dev computer can be anything .... the machine you use to sign the enclave has to be trusted as it uses a secret signing key.

* code must be constant time, everything

I don't understand what the means, I can have loops (i.e O(N)) or recursions (i.e. O(NlogN))in the code in the enclave.

* you need to be have some Intel license to even distribute that code

You need to sign the final version of the enclave, because Intel is one root of trust. Future versions will allow third parties to also be roots of trust.

* you need to do all fancy handshakes to "communicate" with the enclave

False, you load it as a dynamic library (i.e. dlopen())

* I am not sure whether it is even possible to built it in a secure way without remote attestation (a remote server that has a direct connection to the SGX) as secrets need to be passed in and out of the enclave
  **Edit:** Actually see slide 14 of the PDF I linked, they say "SGX mostly useless without [remote attestation]"...

False, remote attestation is just a means to proving to the client that it's talking to a secure enclave. Similar to the little HTTPS lock you see in the browser. If someone chose not to have a visual feature like that, it doesn't mean HTTPS doesn't exist.

* And slide 16: To store data, you need to encrypt it and store it outside of the enclave. smile

Yes, in encrypted form ... is that a problem?

* finally maybe the **most problematic thing**: (slide page 12)
  > No secure human I/O: enclave may compute the right result, but the system may show the wrong one on the screen

You're missing the point as to what an enclave does - securing human I/O is not an SGX feature.

  And obviously at some point we need to show the password to the user or enter it into an application or so. As such, it **has to leak** out of the secure enclave and be even sent to browsers or so.

The password on its own is not enough, but the enclave can add additional security.

That all seen, I doubt SGX is really applicable here and makes not really much sense as you cannot run the whole password manager in the secure enclave. While it may possible to implement it, I think it would be unneccessary complexity and in the end does not provide that much protection.

That said, I also only know the points listed above of that technology and possibly it helps in some circumstance/way, as I really cannot completly judge the technology for that use case here. However, I think the pointers/problems I've given show it may not be _at least_ the intended use case of the technology...

Edit: Also a useful link: https://eprint.iacr.org/2016/086.pdf

[droidmonkey]

Sorry I was going by Intel's own website, see bottom of the page

https://software.intel.com/en-us/sgx/details

[conz27]

Let me remind everyone of the fundamental issue for applications without SGX:

I can dump your process' memory and view anything that is stored in RAM, which includes user names and passwords anything that the user is accessing. Also, steal any encryption keys you've used to encrypt the database with.

I'm sure we've all seen this: https://it.slashdot.org/story/19/02/21/070204/severe-vulnerabilities-uncovered-in-popular-password-managers

[rugk]

Yes, but if a process can run as the same user, they can also key-log your master password and copy the database file. Or so.

I am not arguing against memory protection, but SGX is flawed and security-by-obscurity. And likely so hard to implement that handing data in and out of that secure enclave. "Hardware security" is always kinda cheeky…
But I've brought up these arguments already.

---

What I actually wanted to propose is an alternative that OpenSSH devs currently implement(ed), see issue https://github.com/keepassxreboot/keepassxc/issues/3309

[conz27]

@rugk

1. Key-logging the master password can be mitigated through the use of a YubiKey. Additionally, if SGX is enabled then the master password simply becomes the means for user authentication rather than the means to decrypt the database file.

2. Copying the database file is useless because the encryption key is bound to the CPU of the machine that encrypted it in the first place. Therefore, copying the database file is useless if the intent is to try decrypt it on another machine.

Your comments about hardware security lack merit in my opinion because anything software that runs in an environment where the OS or Kernel itself is untrusted can suffer defeat. Hardware Security is the only proven way to operate securely when your OS or Kernel are rooted and in control of malicious users.

[rugk]

BTW more and more security vulnerabilities in Intels SGX become apparent: The latest being https://plundervolt.com/ that directly targets SGX.

Of course, also the old ones like Meltdown can be used to extract data from SGX (or at least that should be assumed). Here is an overview over all the old ones (5 listed): https://cpu.fail/

[rugk]

Thing is again: At some point you have to show the password to the user or even hand it to the browser via the browser add-on. No fancy hardware security can protect you from attackers there, as at this point we are again at user space (outside of your TEE) and, after all, malware on the host OS could even just take screenshots or so. To illustrate the simplest case.

[phoerious]

B...b...but... I want my super cyber secure feelgood enclave... and TCATO!!11eleven

[rugk]

Here we are again, I guess this is another new vulnerabilities on TPMs: https://tpm.fail/

[droidmonkey]

Given the security state of SGX, the amount of work required to actually use it, and the requirement of being registered... this is never going to be implemented.