I cannot understand the contents of "Hierarchical Key Model" in the official Snowflake document below.
https://docs.snowflake.com/en/user-guide/security-encryption-manage.html#snowflake-managed-keys
I understand below.
"Table master keys" ⇒ This encrypts the data of the table.
"File keys" ⇒ The stage files are encrypted.
However, I don't understand the roles of "The root key" and "Account master keys".
What is this?
Related
I've been doing some searching and still do not know if this is possible. What I want is for a message to by encrypted by our system and decrypted by a "master key" and also a 3rd party.
This encrypted message needs to be decrypted by 2 entities
-A 3rd party (which we want the control to shut off their ability to decrypt)
-Our system (which we want to always be able to decrypt no matter what, master key?)
From some research I was doing there is a concept of master key and derived keys
Does this following system exist?:
Master Key - can decrypt anything encrypted by derived keys
DerivedKey1 -> Encrypt data with this key and be able to decrypt with Master Key OR DerivedKey1
DerivedKey2 -> Encrypt data with this key and be able to decrypt with Master Key OR DerivedKey2 but NOT derivedKey1
Any terminology I should be using to search for answers would be helpful, also any crypto systems that do this already would be great to know.
Yes, I mean deny any new messages sent from our system to be decrypted
You can encrypt the content with a random key (data key).
Then you can encrypt the data key for each intended recipient (master key and any 3rd party) using its shared or public key.
Why does the Node need the network-root-truststore.jks file at initial registration? What's the relashionship between this file and the nodekeystore.jks?
EDIT: Actually, I was meant that I didn't see the relashionship between the CSR and the network-root-truststore.jks file. Is it not possible to generate the Certificate Signing Request without this file?
network-root-truststore.jks-> This is the network operator's root CA.
nodekeystore.jks -> This contains nodes identity key pairs and certificates.
As you can see in the diagram. The Root CA for Doorman and Network Map are same. The node assumes 3 level hierarchy as you can see in the picture above. ( This got fixed in version 3.3 so you can have a n-level certificate hierarchy)
For initial registration with the doorman, you'd need to create a CSR request and send it to the doorman, the doorman will then return you the requestId, Using the provided requestId you'll ask the doorman if the CSR has been signed by him or not once done, Doorman will hand you over the node certificate like below
Once you've the node certificate signed by the doorman, you want to validate it (for this you'd need the RootCA Certificate which is inside the network-root-truststore.jks now you don't need it to create the CSR, but the certificate received must be validated, as result, you need this. Also, this prevents man in the middle attack.)and generate the TLS key pair and certificates.
The above process is automatically done by the corda node for you at the time of initial registration when you start the node using this command -> java -jar corda.jar --initial-registration --network-root-truststore-password <trust store password>
One Important thing is you should remove or delete the network-root-truststore.jks file once you are done with the registration.
I am fairly new to PGP encryption. I generated a new key pair last week on a Yubikey, while previously I had only used a private key that I generated on my machine. I use thunderbird enigmail for key management. This is probably a stupid question but I don't actually understand how to encrypt an email using the private key stored on my Yubikey. I can decrypt just fine but can't figure out how to compose an encrypted email from the new key. Using my old key pair, it's automatic - how do I actually encrypt using the right private key? At what point do I enter the Yubikey and pin? (I'm not all that technical and I use encryption for one specific project, so I appreciate dumbing down something that is probably very obvious.)
Using keys generated on a Yubikey is a practically identical process to using your old keys, with one extra step of set up.
To use keys stored on a Yubikey, you need "key stubs" registered on your PGP system. Basically, these are references that tell your PGP software "This private key is located on smartcard number #123456." Once you have the stubs to the keys you need, Enigmail should treat the Yubikey-stored keys like any other PGP key.
I'm only familiar with GnuPG, so specifics may vary, but using GPG you need to
Have a copy of the public key imported to your system from a key server or the like.
Import key stubs from your smart card (in this case, your Yubikey) using:
gpg --card-status
After that, checking your private keyring should reflect that you have stubs pointing to private keys stored on a smart card (denoted by the > after sub). I.E.
gpg --list-secret-keys
----------------------------------------------------
sec# rsa2048 2018-01-02 [C] [expires: 2020-01-02]
ABCDEF123456789ABCDEF123456789ABCDEF1234
uid [ ultimate] My Name (My PGP key) <anAddress#somesite.com>
ssb> rsa2048 2018-01-02 [S] [expires: 2018-12-31]
ssb> rsa2048 2018-01-02 [E] [expires: 2018-12-31]
ssb> rsa2048 2018-01-02 [A] [expires: 2018-12-31]
At this point you can use sub keys of CDEF1234 as if there were on your system. Your PGP software ought to handle checking the card is inserted and dealing with PIN entry.
Is it possible to "retarget" keys generated via the ncipher JCE API to pkcs11? I know that you can retarget via the generatekey command but I don't see how to do it to an existing JCE key. The first prompt is for the "source application" and the options don't seem to include JCE. Does it support other options beyond the ones listed there or should I be looking at a different way of retargeting?
The ultimate goal here is to export a couple keys (asymmetric and symmetric) that were generated via nCipher's JCE API (yes, I know that an HSM's job is to secure the keys and exporting is usually not a good idea but it is a requirement here). We are able to export keys that were generated via the PKCS11 interface but not ones that were generated via the JCE so our thinking is that if we can retarget it from JCE to PKCS11 we might be able to export these keys as well. If there is another way to do this we are open to that as well.
Lastly, the JCE keys show up as "recovery enabled" when executing the nfkminfo on them. Does that mean that they are exportable or does recovery here mean something else?
Disclaimer: I work for Thales e-Security but do not speak for the company.
Yes you can retarget a jcecsp key to pkcs11. If you have any jcecsp keys in your kmdata/local, /opt/nfast/bin/generatekey will offer jcecsp as a source option. If you have no keys of that ilk, it will quietly omit that option from the source list. However, this retarget process may not do what you think it does. All retargeting does is change the application type and potentially the associated metadata: it doesn't change the fundamental capabilities of the key as those were baked into the protected key blob at generation time and cannot be changed.
The Security World uses nShield key ACLs to limit the key's capabilities (Sign, Verify, Encrypt, Decrypt, Wrap, Be Wrapped, etc.). PKCS#11 pulls its parameters (CKA_SIGN, etc.) directly from the key ACLs, and when generating keys through the API, the ACLs saved in the key blob are derived directly from the parameters in the key template. If you set CKA_SENSITIVE to FALSE, and your Security World allows it, you can generate and save an exportable key. JCE is not that sophisticated: it has no concept of key capabilities at all, so the Provider has to guess at the user's intent with the key and it defaults to a fairly generous set. However, since as you point out the whole idea of HSMs is to protect key bits and not let you have them, Export is not one of the defaults. And what's not baked into the key file when you create it, you don't get by retargeting the key.
One thing you could do if you want to use JCE is to generate the key using a different Provider and then store it in an nCipher.sworld KeyStore using the nCipherKM Provider: this will import the key into the Security World (if your World allows that) and save it as a key_jcecsp_* file. However this has nothing to do with key security so from an HSM perspective it's not recommended. Another thing you could do is to drop down to the native nCore API, generate the key with the ACL entries you require, and then polymorph it to a JCE Key Object and save it in the HSM-backed KeyStore. You can shoot yourself in the foot as many times as you want with the ACLs on the key you create. The polymorphing is very poorly documented: ask Thales Support and they can guide you.
Finally, the Recovery capability means that in addition to the Working Key blob which may be protected by an Operator Card Set, the key file has a Recovery Blob. This is in case that Operator Card Set is lost: the Recovery Blob can be opened up by the Administrator Card Set of the Security World using the rocs utility (Replace Operator Card Set), which will write a new key file under a new OCS. No, this does not mean the key is exportable. It just means that you are protected against losing the OCS. Of course losing the ACS is a non-starter as that is your Root of Trust.
I found on this forum some very interesting content for problem that I have, but I don't found answer for my question.
To change encryption password I can use command:
cryptsetup luksChangeKey /dev/sda2
... and that works. But how to encrypt /dev/sda2 partition again with new password?
If my old password is compromised and I only change password, stored data is encrypted with old password not with new.
The LUKS partition itself is not encrypted with your password: it is encrypted with a strong "master key" randomly calculated upon volume creation. Your old and new passwords only serve to encrypt the "master key". Unfortunately both passwords and the "master key" as often referred to as "keys" hence your (and others') confusion.
When in the old days cryptsetup did not rely on LUKS, every time you changed your cryptsetup password the entire disk would have to be re-encrypted!
Nowdays you only have to change your master key if someone also gains physical or administrative access to the encrypted device while the password is valid.
p.s. if not relying on temporary storage but having free space, the LUKS master key may be "changed" by shrinking a LUKS volume via "cryptsetup resize", creating another volume, moving data, deleting the first volume and expanding the second volume.