I've successfully signed my XML files using the RSACryptoServiceProvider. My key is stored in the Machine Key Store.
Now, I would like to check if the machinekeystore already contains the key that is related with the keycontainername or if the rsacryptoserviceprovider will need to create a new one.
How may I accomplish this?
Appreciate for your help!
Camille.
According to Key Storage and Retrieval, when Windows creates a Machine key store, it creates a file in the Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\Machine Keys directory. You could loop through the files and search for the file. See the example here called TryKeyContainerPermissionCheck for a way you might find the file.
Related
I'm new to using DPAPI so this is something I've messed up on my app because I've been redeploying between my work laptop and my personal desktop so now the key that DPAPI is using to protect my data has changed between environments.
Now I'm getting the error that the key isn't in the key ring.
I hit this answer where a link provided discusses configuring key storage so I've updated my code to persist keys to file system (while I wait for sysadmin to get back so he can set up blob storage on azure as an alternative) and this should work fine for dev anyway.
var path = this.Environment.ContentRootPath + "/Data/Keys/";
services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(path));
I can see the key files being created, but the error persists because I don't have the key that the app is looking for.
So how can I get it to generate/use/look for a new key here?
Oddly enough, it seems like completely reinitializing the app's database solved the problem.
My guess is it has something to do with the encrypted values that I stored in there (the DPAPI IDataProtector.Protect() output values). Specifically the fact that those values were encrypted with what I assume to be the key that the app was reporting couldn't be found.
Having reinitialized the database with new data, everything now works as expected.
We are generating certificates that are supposed to have an ECDSA key stored on the TPM. My understanding is that the GetECDsaPrivateKey extension method will load a handle to the algorithm for the private key in the TPM. Is this true? The certs we are testing with keep returning null and I need to know if they are simply being created incorrectly or if the test code is bad. The MSDN method description isn't very helpful in this case.
Yes, if it was told to look there.
On Windows, .NET's X509Certificate2 is backed by the Windows certificate APIs. Windows certificates have properties (in addition to their in-certificate attributes), and one of the properties identifies where the private key lives (in effect, the arguments to CngKey.Open) -- if the property is missing (and the "I have already opened the private key [here]" property is also missing) then the cert "has no private key" (cert.HasPrivateKey == false).
If your certificate is part of a Windows Certificate Store, and viewing that store via MMC shows the private key icon, then GetECDsaPrivateKey() can open it (assuming the key wasn't deleted after the fact, and that it's an ECDsa-capable key).
If you load the certificate from a .cer file, or some other means, then the cert doesn't know that there's a private key available, and it never searches for it. If you know how to find the private key and open it into an ECDsa object (e.g. ECDsaCng) then you can (in-memory) associate them by X509Certificate2 certWithKey = cert.CopyWithPrivateKey(key);. At that point, having been told where the private key lives, the new object's GetECDsaPrivateKey() works as expected.
That GetECDsaPrivateKey only gets the key if it's part of the certificate. To use a key from the TPM, you need to use the CngKey.Open() method with the name of the key and the storage provider.
I am trying to add a registry key in my C# code under
HKEY_CLASSES_ROOT\*\shell\blabla
I want the user to be able to send any file to my application, kind of like Open with UltraEdit or so.
I don't have administrator rights and the users won't have administrator privileges, too.
If I am doing that in my C# code as posted below, I get a
System.UnauthorizedAccessException
Registry.SetValue("HKEY_CLASSES_ROOT\\*\\shell\\blabla", null, "FastSearch");
string path = Application.ExecutablePath;
Registry.SetValue("HKEY_CLASSES_ROOT\\*\\shell\\blabla" + "\\Command", null, path + " \"%1\"");
If I run Regedit and attempt to do it manually myself, I get a similar error:
Error! Key could not be created. Error when writing to the registry.
BUT, if I double click a *.reg file that attempts to write the SAME KEY, everything works!
So why is that?
And do I have a chance to get this done through code?
Or should I just change my code to run that *.reg file?
UPDATE:
Actually the *.reg file did not write the SAME KEY as stated above, but
HKEY_CURRENT_USER\Software\Classes\*\shell\blabla
I didn't notice that. It seems as anything added under HKEY_CURRENT_USER\Software\Classes*\shell\blabla is also added to HKEY_CLASSES_ROOT\*\shell\blabla. Sorry for the confusion.
Although the problem is solved already and the reason for successful import of *.reg file was found out also in the meantime in comparison to C# code, here is a complete answer for this question.
HKEY_CLASSES_ROOT Key (short HKCR) as described by Microsoft shows file name extension associations and COM class registration information which are effective for the current user.
The real locations in registry for those keys are:
HKEY_LOCAL_MACHINE\Software\Classes (short HKLM\Software\Classes) containing the defaults for all users using a machine and
HKEY_CURRENT_USER\Software\Classes (short HKCU\Software\Classes) containing the user specific settings which override the default settings from HKLM\Software\Classes.
A registry write to HKEY_CLASSES_ROOT is always redirected to HKLM\Software\Classes. A write access to any key in HKLM requires administrative privileges which is the reason for the error message.
Microsoft recommends to write directly to either HKLM\Software\Classes or to HKCU\Software\Classes depending on changing the defaults or the effective file associations for the current user.
Write operations to keys under HKCU do not require administrative privileges.
HKCR should be used only for reading currently effective settings for file name extension associations and COM class registration information and not for adding or changing them.
I want to read with a simple c# application the windows key from the registry. But on a x64 machine I recieve only BBBBB-BBBBB-BBBBB-BBBBB-BBBBB as the key and that is wrong... How can I fix that problem?
RegistryKey key = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64);
RegistryKey subkey = key.OpenSubKey("SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion");
Thanks!
According to this Web Site that makes CD Key recovery software and this Windows7Forums thread, the existance of all B's for the product ID is indicative of a MAK(Multiple Activation Key) key.
From First link:
The B’s means the cd key is not stored in your computer, so cannot be recovered. That can be due to a few reasons:
A MAK was used for activation;
SLMGR was used to remove the key from the windows registry,
or You’re running a pirated version of Windows.
From Second Link
This is a big problem when an administrator sets up many PCs with a
volume license key. Because everyone can extract the VLC key and use
it for additional installations. Because this reason the VLC key is
automatically deleted from the registry after activation. And after
this all key finder show only "not available" or
BBBBB-BBBBB-BBBBB-BBBBB-BBBBB. With command line: slmgr –dli you
can get a "Partial product key" – the last 5 characters of the product
key. This "Partial product key" is saved in encrypted form in the
certificate file "tokens.dat"
(C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform\tokens.dat).
Everyone who fears that his key can be stolen can also delete manually
the product key from registry with this command line: slmgr –cpky
(cpky = clear product key = remove product key from the registry)
A quick web search shows many people with the same problem. One solution seems to be to get the DigitalProductID4 value if DigitalProductID is all B's.
In my applications web.config file I have a connection string stored.
I encrypted it using
'---open the web.config file
Dim config As Configuration = _
ConfigurationManager.OpenWebConfiguration( _
Request.ApplicationPath)
'---indicate the section to protect
Dim section As ConfigurationSection = _
config.Sections("connectionStrings")
'---specify the protection provider
section.SectionInformation.ProtectSection(protectionProvider)
'---Apply the protection and update
config.Save()
Now I can decrypt it using the code
Dim config As Configuration = _
ConfigurationManager.OpenWebConfiguration( _
Request.ApplicationPath)
Dim section As ConfigurationSection = _
config.Sections("connectionStrings")
section.SectionInformation.UnProtectSection()
config.Save()
I want to know where is the key stored, and also if somehow my web.config file is stolen, will it be possible for him/her to decrypt it using the code above.
The user keys are stored in:
[Letter]:\Documents and Settings\[User]\Application Data\Microsoft\Crypto\RSA
Machine keys are in:
[Letter]:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys
If someone has the file and the keys then yes, they'll be able to decrypt. If only the file, no they won't be able to.
Also, if they decrypt using the same code on the same server, then yes. However, if they reach your server, it's all over anyways.
EDIT to add into the answer from comments:
Q: If I copy the key and paste it in some other PC along with the web.config, will it be decrypted?
A: If i'm not mistaken, the key will only work on that machine unless you do an import/export. However, as I say, if someone has gained access do this, you will be "dead in the water" already, as the compromised server will be devastating.
Q: I created one more web application and encrypted it.I see that no new key is created there.Did it use the same key for the 2nd application?
A: As far as I know, yes. The keys are generated per machine, per user to my knowledge.