I am working on a project using TPMs & am trying to figure out if the AIKs can be used to decrypt any blob of text?
I was able to get my head around AIK enrollment & am now trying to use it for identity. For that my plan is to send a blob of text encrypted with AIK public key & ask the platform to decrypt it for me.
I thought of an alternate approach to have the AIK sign a blob of text for me at first, but looks like AIKs can be used to sign only the PCRs.
No, as a signing key the AIK is not meant to be used for decryption. You may be misunderstanding the purpose of the AIK. It is almost exclusively used for signing system quotes (obtained via TPM_Quote) which is then checked against the AIK certificate signed by a CA you trust. Intro to TPM 1.2 explains well how the EK and AIK play together.
Related
I would appreciate clarification and advice on the following:
My project requires me to use symmetric data encryption (using AES), in a Nodejs environment, to secure data on a database (mongodb). Ideally, I would like to do this as follows:
Store the symmetric key in Azure Key Vault as a Key, then make 'encrypt' calls to the vault to perform AES encryption on the data with the Key. The encrypted data is sent in the response to my app and then stored in the database in its encrypted form.
I am confused after reading MS Azure's documentation and related blog posts, where some sources claim symmetric key encryption is supported, but there is no official documentation on this.
Can anyone advise whether this an exhaustive list of all key types and algorithms supported for Azure's Key Vault?
https://msdn.microsoft.com/en-us/library/azure/dn903623.aspx#BKMK_KeyTypes
It also seems this may be an option (http://www.nuget.org/packages/Microsoft.Azure.KeyVault.extensions) but only for environments on .NET. Any love for Nodejs?
If indeed symmetric keys/encryption are not currently supported, can anyone offer an alternative means to my approach described above?
Thanks and much appreciated.
I agree the documentation/blogs do seem a little confusing on this topic. From my understanding the key vault does not yet currently support symmetric encryption. I believe the closest you can get is storing symmetric keys as secrets and using them outside of the vault.
This article talks about doing such. See the section where the heading is Use Key Vault secrets
I understand your using node.js and that example is in powershell just trying to illustrate the example of symmetric encryption with a secret. Obviously the crypto operations happen outside the vault. So, at rest the keys are more secure but do get exposed in memory anytime an operation occurs.
Hope that helps.
Here is an example in PowerShell of creating a secret in Key Vault that can be used as a SymmetricKey.
SymmetricKey sec = (SymmetricKey) cloudResolver.ResolveKeyAsync(
"https://contosokeyvault.vault.azure.net/secrets/TestSecret2/",
CancellationToken.None).GetAwaiter().GetResult();
I recently created a PGP keypair using GnuPG keychain tool on mac. I can see that it automatically creates a master key and an encryption sub key. Now I want to use a key for encryption and signing on my smartphone as well.
So what is the best practice for it?
Does one create new subkeys for smartphone for this purpose or use the same which were generated?
Can you please provide an example for same?
Create an additional signing subkey (gpg --edit-key [key-id], addkey) and then only export the subkeys. If the keys on your smartphone get compromised, you only need to exchange the subkeys, and do not have to distribute your key again.
You could create an additional signing subkey for each device. For encryption subkeys this is a little bit more complicated, as the OpenPGP protocol does not know a way to bind keys to certain usage or devices; the other party's client will usually just select the newest usable encryption subkey, so you'll have to use the same encryption subkey on all devices.
I want to increase my safety of my web app in case of an attack.
The following components are present in my system:
Azure Web App
Azure Blob Storage
Azure SQL Azure
Azure KeyVault
Now there is the scenario that the app encrypts and stores uploaded documents.
This works as described:
1) User Uploads doc to the web app
2) random encryption key is generated
3) random encryption key is stored to the azure key vault
4) sql azure stores the blob url and the key url
Now my question is:
How is using the key vault safer in case of hacking the web app instance? I mean there is the client id and client secret in the app.config to access the keyvault, we need it to read and write keys. So if i use key vault or not does not increase safety in terms of hacking the web app, right?
The Key Vault is an API wrapped around an HSM. What makes the Key Vault or HSM Secure is that the keys can not be extracted from them once imported / created. Also, the crypto (encrypt / decrypt in your case) operations happen inside the vault so the keys are never exposed, even in memory.
If someone was able to hack your web application and get the credentials to your key vault they could use the vault to decrypt the data. So, in this case you could regenerate the credentials for the Key Vault and still continue to use the same keys that are in the vault - because they were never exposed. Meaning any data that is encrypted that the attacker didn't already decrypt is still safe because the keys were never exposed.
Typically HSMs aren't designed to store a large number of keys in only a few really important keys. You might want to consider using a key wrapping solution where you have one key in the vault.
You probably want to encrypt the client id and client secret in your config and decrypt them at runtime - this adds another layer of security. Now the attacker either needs to read the keys out of your application memory while it is running on your Cloud Service / VM (not an easy task). Or the attacker would need to obtain the config file and the private key of the certificate used to encrypt your config values (easier than reading memory, but still requires a lot of access to your system).
So if i use key vault or not does not increase safety in terms of
hacking the web app, right?
It all depends at what level they were able to hack the site. In the case you describe, if they obtained your source code then - yes, its game over. But it doesn't have to be that way. It truly comes down to your configuration.
However, most of the time, developers forget that security is a layered approach. When you're talking about encryption of data and related subjects, they are generally a last line of defense. So if a malicious actors has acquired access to the encrypted sensitive data they have breached other vulnerable areas.
The problem is not Key Vaults but your solution of using client secret. Client secret is a constant string which is not considered safe. You can use certificate and thumbprint as a "client secret". Your application needs to read the .pfx file which is stored in web app, then decrypt to grab thumbprint. Once thumbprint is retrieved successfully then you Key Vault secret is retrievable. Moreover, in Key Vault you are given the ability to use your own certificate rather than just a masked string in Secret. This is so-called "nested encryption".
The hacker if getting access to your app.config, he get nothing than the path of .pfx file which he does not know where to store, even how it looks like. Generating the same pfx file becomes impossible. If he could he would break the entirely crypto world.
I know a bit of authentication theory, but would like to know how is it really put in practice.
There are these software patches that must be distributed periodically. To ensure that only the genuine content reaches our users, we have been advised to sign our content before distribution.
The plan is to generate a Public-Private key pair. The patch would first be signed by our private key and recipients then authenticate the downloaded patch by using our public key. Our idea of signing is to generate a hash of the patch and encrypt the hash with our private key. The encrypted hash (signature) is to be bundled along with the patch before distribution.
We have been advised further that it is a good practice to get a digital certificate for our public key from a CA and post it on a certificate server in our premises. We are told that the CA would create this certificate using its private key. Our users are expected to download the public key certificate from our server and authenticate it using the public key of the CA. Thus our users would be confident that they have the right public key from us to authenticate the genuineness of the patch.
And finally the question:
How/where can the exact public key of the CA be downloaded for authentication of the public key certificate downloaded from our server?
In what formats are these certificates available? Are these plain text files or XMLs or ??
To answer your questions in order:
Using a browser and SSL. In that case you rely on the certificate store already in the browser. It may be a good idea to also publish the fingerprint of your own certificate. Note that you also distribute a certificate - or certificate chain - within your software. If the software download is trusted, then you may not even need an external Certificate Authority. But in that case you keep your private key of the CA very secure.
X5.09 certificates are created using ASN.1 DER encoding. DER is a binary encoding (and the textual ASN.1 definitions specifies the contents). Certificates are also often distributed in PEM format. This is a base 64 encoding of the binary certificate, with an additional header and footer.
I imported a third party CA issued PFX certificate using PFXImportCertStore. Upon successful importing, the PCERT_KEY_PROV_INFO_PROP_ID is set to the following values by default by the same call, PFXImportCertStore
Why is the dwKeySpec recognised as AT_KEYEXCHANGEkey type rather than AT_SIGNATURE?
Why is the pwszProvName set to Microsoft Base Cryptographic Provider v1.0?
The certificate in the first place was issued ONLY for Digital signing. But the key usage field indicates that the certificate can be used for Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment (f0). Enhanced key usage indicates, Client Authentication and Secure Email? Has the CA has issued the certificate correctly? The front of the certificate shows the following message(screen shot below) which makes me to suspect that this certificate was not issued for digital singing? Am i thinking correctly or not?
4.Because of these issue, i am unable to sign data using CryptSignMessage. The internal call fails to acquire context to the private key for signing. Any suggestions on how i can get around this issue?
I am able to sign with a selfsigned PFX cert which i generated. Do you think that i could export the private key in to new container and set it property to AT_SIGNATURE and the csp provider Type to PROV_RSA_AES, as i require SHA256.
I am working with XP sp3.
Thanks
Answer 1: The key is automatically classified as AT_KEYEXCHANGE because, its usage is also to encrypt session key etc. ie Though my application's main purpose is to digitally sign data, the CA has defined the key usage policy to include encipher, which forces CryptoAPI to map the key type to AT_KEYEXCHANGE.
Answer 2: I ASSUME that it is a default csp in this machine, so...? Any better explanation, please
Answer 3: From many replies from guys in Crypto Google group, AT_KEYEXCHANGE key can also be used to sign data, provided your certificate's key usage allows you to do digital signing. It seems to be common practice for third party CA's to issue certificates that can be used for multiple purposes. So the third party CA has issued the certificate correctly.
Answer 4: I managed to sign data using CryptSignMessage with the same third party issued certificate. I changed the dwProvType in PCERT_KEY_PROV_INFO_PROP_ID to PROV_RSA_AES and passed in NULL for pwsProvName. This change is performed by using CertGetCertificateContextProperty first to get the properties and then using CertSetCertificateContextProperty to set the properties of your choice. This fixed the signing issue. Now i am able to sign with SHA256/RSA1024, AT_EXCHANGE key.