Given that I have a shared value between two machines with their own TPMs. How can I generate the same symmetric key on both TPMs using the shared value?
Related
The Identity Server 4 documentation (here http://docs.identityserver.io/en/latest/topics/crypto.html?highlight=data%20protection ) discusses signing keys and validation keys. I know that the signing key is configured using
AddSigningCredential(<X509Certificate2>)
and there are two APIs for validation keys
AddValidationKey(<X509Certificate2>)
AddValidationKeys(<Microsoft.IdentityModel.Tokens.AsymmetricSecurityKey[]>)
The document talks about signing key rollover and adding multiple validation keys to the discovery document. Questions:
When do you use AddValidationKey with X509Certificate2? Do you need to do this even though you are using AddSigningCredential?
What does "you request/create new key material" refer to? Is this a new certificate? Or is this a Microsoft data protection key?
What is an AsymmetricSecurityKey? Is there a method to create from an X509Certificate2?
We are using cookie authentication - are the ValidationKeys the same as the keys stored PersistKeysToAzureBlobStorage in Net Core 2.0? (https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-2.1&tabs=aspnetcore2x)
IdentityServer uses asymmetric encryption. Asymmetric encryption means you have a public key and a private key. The public key is shared (obviously) and is used only to encrypt. The private key is, well, private. It should be strictly protected and never shared, and it's used to decrypt. The signing key is your public key, while the validation key is your private key, so yes, you need both. An X509Certicate can be used because certificates employ both public and private keys, but ultimately, IdentityServer is just using the cert to get at the keys.
The AddValidationKeys (plural) method is used explicitly for key rollover. Your cert, for example, will likely expire after one year (the default in most cases). At the end of that period, you would replace it with the new cert. However, clients may still have access tokens and such encrypted via the public key from the previous cert, and IdentityServer would need the private key from the previous cert to decrypt that. Using this method, you can add the previous keys only for the purpose of validating material IdentityServer can't validate with the current keys.
Data Protection is really totally separate. It too uses public and private keys to do what it does, so technically, you could use the same keys for IdentityServer as well. However, it's better to keep your keys restricted to unique purposes. That way, if you do get compromised, you aren't completely compromised, and can somewhat limit the scope of the potential leak.
I have found all over the internet that HSM is the best place to store keys, but I am left with many unanswered questions.How does interaction takes place between server,HSM and database?. Is it like the server retrieves the keys from HSM to decrypt the data from database? If we could retrieve the keys from HSM why do we need a HSM in between? we can use a secure DB to store keys.I feel like I'm missing something.
Different HSMs work differently.
Some store the keys internally but there are storage limitations. Some encrypt the keys and the encrypted keys are stored on the server.
Some will handle data encryption/decryption so the key is never outside the HSM.
HSMs also have different levels of hardening from attacks over the com port, hardware access (tampering: removing screws, etc), vibration/shock, heat, etc. When an attack is noticed the key encryption keys are erased.
Some have admin access control requiring multiple people to be present, each using a smart card and enter a password. Additional physical security may be provided by physical access control.
It would be great to know
what are they,
what are they used for
why would one prefer one versus the other.
A very simple answer:
Key
A Cryptographic key represented as JWK (JSON Web Key)
Example: store A .pfx certificate file that contains a pair of public & private keys
Secret
KV accepts any value and stores it as a binary (there is a max size limitation)
Example: A password or API key
Further Reading
About Keys and Secrets
Key Vault Keys:
Keys in Azure Key Vault are 'Cryptographic keys' used to encrypt information without releasing the private key to the consumer(users\Service). It acts like a black box to encrypt and decrypt content using the RSA algotithm.
The RSA algorithm, involves a public key and private key. The public key can be known to everyone; it is used to encrypt messages. Messages encrypted using the public key can only be decrypted with the private key.
Scenario:
Assume you have to store the customer CreditCard, the secure way to keep it in your DB is to store it encrypted, during the software design and
business requirements it is perfect clear that you should encrypt it,
what most people don't realize or don't bother is how you protect your
encryption keys, most of the time, stored as part of your software
configuration, if the attacker or employee has access to the key, the
information is not secure anymore.
Using key vault keys, you could send the CreditCard information to KeyVault and it will encrypt the information and return to the caller the enccrypted value.
On high performance scenarios, you could get the public key from KeyVault, use it for encrypting the information from Application side and store in DB already encrypted without sending the data to KV.
The only way to get the real data back would be sending the encrypted data to KV where it will return the decrypted CreditCard.
Key Vault Secrets
Secrets in Azure Key Vault are octet sequences with a maximum size of 25kb each. It is described as octet because it does not care about the data type being stored, the only limitation is the size of 25kb. Once you send the data, it is encrypted and stored, you can retrieve it at any time if you have the permissions to do so. It is used to store information like application settings, tokens and if you will database connection strings, passwords and so on.
The good side of Key Vault Secrets is that you can use pre-defined rotation values defining the Expiration/NotBefore values. So you could register temporary values that will be rotated at specified periods, while the reader has access to the Key Vault with Get permission, they will be able to read the current ones only, while the future ones are already defined and not visible to the Get operation.
The Azure Key Vault (KV) can store 3 types of items: (1) secrets, (2) keys, & (3) certificates (certs).
Secrets - provides secure storage of secrets, such as DB connection strings, account keys, or passwords for PFX (private key files). An auth app can retrieve a secret for use in its operation. More on AZ KV Secrets
(Cryptographic) Keys - keys represented as JWK (JSON Web Key). Supports multiple key types and algorithms, and enables the use of Hardware Security Modules (HSM) for high value keys. More on AZ KV Keys
Cert - is a managed X.509 certificate, which are built on top of keys and secrets and add an automated renewal feature/auto-rollover. More on AZ KV Certificate
I would like to store public cert in a database, but I need an attribute of the public cert to index the public certs in the database. I would like to make this a unique field.
Is the finger print of a public cert unique?
The fingerprint is unique (for all practical intents); two different certificates should never share the same hash. For example, per the Windows X509certificate2.thumbprint documentation:
the thumbprint is a unique value for the certificate, it is commonly used to find a particular certificate in a certificate store.
Per the OpenSSL documentation:
Because of the nature of message digests the fingerprint of a certificate is unique to that certificate and two certificates with the same fingerprint can be considered to be the same.
Note the fingerprint is not part of the certificate. Rather, it is calculated by taking a cryptographic hash of the entire certificate (including the signature). Different cryptographic implementations may use different hashing algorithms to compute the fingerprint, and thus provide different fingerprints for the same certificate. (For example, the Windows Crypto API computes the SHA-1 hash of the certificate to compute the thumbprint, whereas OpenSSL can generate the SHA-256 or SHA-1 hash.) You will thus need to ensure that clients using the database fingerprint are using the same API, or a consistent hashing algorithm.
In theory, a duplicate fingerprint shared by multiple certificates would require a hash collision. The probability of such an event occurring by chance is astronomical. Intentionally generating such a certificate pair would require a successful preimage attack on the underlying hash function, an attack not known to be feasible on SHA-1 (see Preimage Attack).
At the moment, I am building a system that deals with sensitive data. For this, I am encrypting all the information with a key that is saved (for the moment) within the script. Can anyone suggest any methods that the key could be secured somewhere secret, but is available to the system (for a multitude of users, not just the owner and administrator)?
In Diffie–Hellman key exchange scheme, each party can generate a public-private key pair. The public key can be shared with each other prior to information exchange. The private keys are not shared and work with the shared public key to decrypt the message. This is public key cryptography.