When I import a public/private pair into windows certificate store, Windows does not require any password of any kind to encrypt the keys.
From that I conclude that if it is a user's store, it uses the user's password (or probably the user's hashed password) to encrypt the private key, and, if it is the local machine store, it is probably some kind of hardware-based key to encrypt the private key.
Did I get it right???
And if I did, what is the point of non-exportable keys if I can decrypt the keys???
And last question - If I got it right up to here, what are the alternatives?
As "SLanks" link explains, the private keys are encrypted with the user's password or the machines's password (depends on the location of the keys in the store).
Therefore, anyone who can log to the machine can obtain to this user's keys and anyone who has access to the machine can obtain keys stored for the local machine.
Related
I have used PFXExportCertStoreEx API to successfully export public and private key of a RSA certificate from Windows key store.
Can the same PFXExportCertStoreEx be used to export public and private keys of DSS and ECDSA certificates from the Windows key store?
If not what other API needs to be used?
Thanks in advance.
After days of analysis and discussions, finally I was able to identify the root cause. It is related to privileges. If I run with Admin privilege, I can use PFXExportCertStoreEx to extract keys for ECDSA certificate as well from the Local Machine certificate store.
If you do not intend to use Admin privilege, just take the certificate manager or mmc and select the certificate, take All tasks > Manage Private Keys give privileges as required.
I have a password manager that I'm implementing in Ruby. Encrypting the passwords is pretty easy thanks to OpenSSL, but I also need to ask the user for a master password, which is a password to view, change, and add passwords. Once the user enters their master password in, I intend for it to be encrypted and stored in the passwords file somehow. But OpenSSL encrypting and decrypting requires a password. For normal passwords, the key is the master password, so what should I make the encryption key for the master password?
I have a self-hosted WCF application, which acts as a server and I want to install/deploy it on a Windows machine.
The application uses a self-signed certificate, which I created with makecert.exe. So the PFX, CER and PVK are there and available. Everything works fine.
At this point of time and only for testing, the application reads the certificate and the private key from an embedded resource. That means both are compiled into the application, which is a high security risk.
I already know, that the most common way to store this data, is the windows certificate store. And I also know, how to save and read from the windows certificate store.
But there is something, that I still do not get:
Where do I store the private key (PVK) for the certificate (CER), so that my application is able to use the CER?
I mean, if my application can read it, then anybody, who has access to this machine, can read it. Or is this wrong?
Do I have to take care myself or is there any "industry standard" for windows machines, to save and read the PVK?
Windows certificate store is the most common place to store certificates (i.e. CA) or certificates with private key (End entity).
If you store certificate ( with private key - PFX) in LocalMachine\My store then you can assign privileges who (what account) can access private key. It is done through certlm.msc tool. System account has access by default so any system service can use the private key.
There are other ways to store private key (like smartcard, HSM, net HSM etc.) and other ways to access private key (like PKCS#11).
I'm trying to figure out how to Windows credential roaming is implemented. I have found that it will roam certs that have been strongly protected with a password (optional entropy to CryptProtectData()).
I can't see how this could be done unless Windows keeps a copy of the password somewhere when the cert is imported. Copying the files in %APPDATA%/Crypto/RSA{UserSID} to another machine would not work as the keys are encrypted with the users DPAPI master key and optionally a password.
Other than using ProcMon and I have no idea what else to try or look at in order to figure this out. Any pointers to help figure this out would be much appreciated!
CryptProtectData does a little something more that makes the whole thing possible.
DPAPI will generate a key for encryption. The DPAPI key will then be encrypted with another key derived from your password.
What is sent in credential roaming is the DPAPI key, not your password.
It is the same thing that also allows DPAPI to keep working (locally) when you change your password. Otherwise, Windows would have to track DPAPI encrypted blobs stored everywhere (files, registry keys, etc.) to encrypt to the new password derived key. There is an infinite number of applications, making it impossible.
Instead, the key is in one well known and well hidden location, never seen by the user. Windows can easily rencrypt the DPAPI with the new password, shielding applications using it from password changes.
The same mechanism is also used by credential roaming to stay indenpendent of the user's password.
This website has code to extract the SYSTEM's account DPAPI key, and some information about the structure, it might help you debugging.
I want to encrypt passwords using the DPAPI like this
ProtectedData.Protect(plain, optionalEntropy, DataProtectionScope.CurrentUser);
and wonder if the domain administrator could decrypt the generated blob, as
Using Passwords Effectively states:
However, in a domain environment a
domain administrator can safely change
your password, and you'll still have
access to your encrypted files.
It seems like the domain administrator would have to decrypt the data (or rather, the encrypted master keys) first, in order to be able to re-encrypt it using a different password.
The answer is yes, provided he also has acces to the entropy key(if one is created), or if he is willing and capable enough to hack into the blobs (see links below).
For the Master key in DPAPI (in CurrentUser mode), the windows login username and password are used to generate the master key.
If the administrator updates the user's domain password, DPAPI wil reencode the master key for that user. The same goes if the user updates his password due to eg. a monthly password change policy.
However, if he doesn't have access to the optional entropy key or the data that composes that key, the file will remain encrypted and all he will get is invalid data.
If DPAPI is used in CurrentMachine mode, the file can only be decrypted on the computer that encrypted it, however the file will be readable to all accounts on that computer, again provided they can also muster the content of the entropy key.
A good repository for information is DPAPI Secrets and this paper on reverse-enginerring DPAPI + link to a tool that can recover data from DPAPI blobs
Short answer : he probably can't right out of the box, but Domain Admin is powerfull. There are many ways they can get to your key if they really want it.
Long answer : DPAPI encrypts your data with a key. IIRC, it uses AES with a key that changes every 90 days. The key is stored on your computer, encrypted with your password. That's the default and it saves your key out of reach of anyone but you.
Unless your domain admin remotely installs a key logger, steals your password, impersonnate you and steal your key (or go straight to the data which he now sees in plain text).
Another somewhat less known fact is that when Credential Roaming is enabled on Active Directory, it will send your encrypted keys to a server. A domain admin could use that copy for an offline attack. But it is hard and unless your data is very valuable, I woulnd't worry about it.
The answer is yes. PoC utility with description: Vulnerability of DPAPI data protection in Win2K, Win2K3, Windows Server 2008, and Windows Server 2012
Works in Win Server 2016/2019 as well.