4 ms·

I agree that CryptoAPI is nasty, but if your key doesn't have the CRYPT_EXPORTABLE flag set when it was created then it can not be exported by CryptoAPI, and ca

I agree that CryptoAPI is nasty, but if your key doesn't have the CRYPT_EXPORTABLE flag set when it was created then it can not be exported by CryptoAPI, and can only be accessed maliciously by breaking the CryptoAPI (by patching it in memory, which requires full admin access to a running system) or accessing the OS disk offline. CryptoAPI does not hand over the key and delegate signing and encryption to the application. Instead, it provides APIs for signing and encryption and does not disclose the private key.

tialaramex 8y ago
> CryptoAPI does not hand over the key and delegate signing and encryption to the application. Instead, it provides APIs for signing and encryption and does not disclose the private key. There is no proxy, they keys live in your process. Because Windows is proprietary they can do the moral equivalent of: if (key->flags & CRYPT_EXPORTABLE) { export(key) } else { error_not_exportable } If you did this in OpenSSH, everybody would laugh because they could see it in the source code. "This doesn't make the key unexportable Beavis, you idiot". But in Windows they can solemnly announce that the key isn't exportable and as you've demonstrated, people believe them even though some introspection tells us this can't be true (Where is the key? Like, really, where - it isn't in a proxy because there isn't one... when we load it _our_ process gets bigger and in a debugger we can see it's in our memory, just CryptoAPI tells us we're not supposed to export it...)
dogma1138 8y ago
You don't need to patch anything the keys are stored in %APPDATA%\Microsoft\Crypto\Keys for user certs, they are "encrypted" if the protection flag is set but there are plenty of tools to recover the key material from those files, the protection material is stored in %AppData%\Roaming\Microsoft\Protect :)

tialaramex 8y ago

> CryptoAPI does not hand over the key and delegate signing and encryption to the application. Instead, it provides APIs for signing and encryption and does not disclose the private key. There is no proxy, they keys live in your process. Because Windows is proprietary they can do the moral equivalent of: if (key->flags & CRYPT_EXPORTABLE) { export(key) } else { error_not_exportable } If you did this in OpenSSH, everybody would laugh because they could see it in the source code. "This doesn't make the key unexportable Beavis, you idiot". But in Windows they can solemnly announce that the key isn't exportable and as you've demonstrated, people believe them even though some introspection tells us this can't be true (Where is the key? Like, really, where - it isn't in a proxy because there isn't one... when we load it _our_ process gets bigger and in a debugger we can see it's in our memory, just CryptoAPI tells us we're not supposed to export it...)

dogma1138 8y ago

You don't need to patch anything the keys are stored in %APPDATA%\Microsoft\Crypto\Keys for user certs, they are "encrypted" if the protection flag is set but there are plenty of tools to recover the key material from those files, the protection material is stored in %AppData%\Roaming\Microsoft\Protect :)