Q:

Could a private key from JavaScript WebCrypto resist a malware attack?

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.

A:

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.

