4

The recent WebCrypto API can generate private/public keys. To prevent the private key to be extractable with JavaScript, the CryptoKey object could be stored like this in IndexedDB.

I suppose if we store it like that, a malware could read it easily, it's surely why the WebCrypto API can wrap the key with another key, so that the private key can be stored in IndexedDB encrypted. The wrapping key is stored on the server side and sent to the client after a successful authentification.

So, if the browser is closed, the malware should be able to get the private key but it's encrypted and in theory useless (excepted for brute-force attack).

But if the browser is opened, and the user log in, the server send the secret key to unwrap the private key. So at this moment, is it possible for a malware to read the network trafic, RAM, files, caches, to read/extract the unencrypted private key?

About the network trafic, I assume it's all in HTTPS, TLS 1.2 minimum with robust cipher suite, with HSTS set to max age including sub-domains, and with HPKP to prevent MITM attacks.

2

Extremely intelligent malware with root permissions (on a *nix client) can do just about anything, including redirecting /dev/random or /dev/urandom to something they control. If the malware can control the random number generation your computer uses to create TLS keys, then it can break the HTTPS communication.

If the browser is open and the user logged in, then malware with the ability to perform raw mem dumps would be able to find the key.

In short, if a user can do it, then a theoretical malware program can do it.

I suggest the question should not be is it possible for malware to... as malware with unrestricted power can do anything that you can do. Instead, the question is, what would it take for malware to...? From this perspective, we're not measuring what's possible, but what is probable.

The methodology you described sounds about as good as it can get (outside of using the user's password to lock the private key / shared secret so that the server doesn't have to receive, store, and transmit it). There is no such thing as perfect security.

  • Thanks for your answer! About the secret key for wrappring the private key, I said it's sent from the server, to prevent brute-force in the client side, I assume it's better to detect/reduce brute-force attacks from the server side. – lakano Oct 21 '17 at 16:30
  • @lakano that's a dangerous presumption. If keys are stored server-side then the server becomes a single point of failure (SPOF) - you get into the server and you get everything for everyone. If the client holds their own key, server compromise is no longer a SPOF. That doesn't mean it's somehow bad that the server sends the key, just that there are pros and cons to both methods, so presuming one is better is dangerous when it comes to security. – cegfault Oct 22 '17 at 7:32
  • @lakano P.S. a brute force attack against a good cipher is currently not computationally possible (that is, if the attacker is using a brute-force method to crack the key, it will take - literally - trillions of years). It's simply not a realistic concern. Real-world threats are not brute force attacks, but ransomware, spyware, malware, viruses; that is, you should be more concerned about things that destroy or steal data, dump memory to get access to the raw key, perform a man in the middle attack to steal the key as it transmits from server to client, etc. Not brute force attacks. – cegfault Oct 22 '17 at 7:36
  • It's not a SPOF because the attacker also need to get access to the private key of each user's browser. If I follow your advice to use the user password for the wrapKey, this mean any javascript coder could open the victim browser on the site, open the JS Console, and try some possibles password then the WebCrypto will directly return success when it's the good password. If the wrapKey is random and sent by the server, this attack could be detected/reduced. – lakano Oct 22 '17 at 9:07
  • 1
    @dandavis WebCrypto deriving a key only works on ECDH & PBKDF2 (other algorithm are not recommanded). And ECDH / PBKDF2 don't have sign/verify feature. ( check the Live API Table for details: diafygi.github.io/webcrypto-examples ) – lakano Oct 23 '17 at 10:24
0

It depends on the computer, operating system and user agent running the Javascript and the website. If either of those is compromised, then malware can get the information sent by the server to te client. For example XSS attacks can compromise the website, and the browser vendor can in theory impersonate you on any website, you are just trusting their software not to let them do it.

So yes, this is about as good as you can get. The more keys are required, the better.

The problem is, lakano, once a stored key is unwrapped in Web Crypto, I don’t think there is a way to mark the result as “non extractable”. I wish there would be a way to combine wrapping and “non extractable” keys. Have you found a way?

I have been asking for a year and no one really knows: https://gist.github.com/saulshanabrook/b74984677bccd08b028b30d9968623f5

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.