We are migrating from Thales 8000 to Thales Payshield 9000. We generated an RSA Key Pair in 8000 (with EI - Generate a Public/Private Key Pair command). We stored the public key on the host and loaded the private key to the HSM's tamper-protected memory (with EK - Load a Private Key command).
The problem is we didn't keep the private key and we don't want to create a new key pair because we have to start a new certification process with the vendor if we do this. Is there a solution like storing this key on a smartcard and moving to the new version like LMK.
I read the Thales console - command reference and programmers manual but wasn't able to find a solution.
The private key that is returned from a Thales HSM keypair generation command (this is command EI on the Payshield 9000 that I have access to) is encrypted under LMK keypair 34-35. You will never see this in the clear i.e unencrypted form.
The only way you could extract this from the HSM would be if you knew that LMK keypair; you could then use this to decrypt it. This is often possible in a test environment where a set of known test LMK keypairs are sometimes used.
In a production environment, however, doing this would obviously compromise the security of the entire HSM and any system dependent upon it.
In your situation, you really have little option but to generate a new keypair and then store the encrypted private key bytes.
The problem, however, with only ever having the private key encrypted under this LMK key pair is that you need to use the HSM to sign a CSR, instead of an established tool like openssl.
I did this by using the EI command (generate an RSA keypair) to generate a keypair, storing the raw encrypted private key bytes returned in a file, constructing an unsigned CSR structure, sending that to the HSM with the private key bytes under command EW (Generate a signature), and then appending the signature to my CSR structure.
If you did not save the output (key block) of the EI command, then the chances of getting that key out of there are practically non-existant. Sorry!
Yes, on two conditions only you can Export an RSA Private Key from payshield 9000 HSM to another payshield 9000 HSM:
1st condition: by purchasing certain license which is HSM9-LIC016 and using the host command L8 which is used to export an RSA Private Key under ZMK. Please refer to
"1270A548-037 Card & Mobile Issuance LIC011,016" manual to see detailed steps of host command L8
2nd condition:You should have recorded the Private Key in a secure manner, which you firstly generated it by EI host command, it is generated encrypted under the old LMK, so you can document it securely for future usage like your critical situation you face now.
The Host command L8 function supports the export of an RSA Private Key from encryption under the LMK to encryption under a Zone Master Key.
The following security settings must be configured by console command CS to allow use of this command:
1- 'Enable import / export of RSA Private Keys?' MUST be set to 'YES' (defaults to NO).
2- 'Key export and import in trusted format only?' MUST be set to 'NO' (defaults to YES)
On the other HSM2:
Import an RSA Private Key using the Host command L6
Although, I can send you the steps in deep details if you want.
Refer to manual:
1270A548-037 Card & Mobile Issuance LIC011,016,018,023 v3.4 Release:October 2018
Related
Suppose I have created ssh keys.The server has private key and I use a ubuntu machine which has public key to connect to server. Now my public key gets stolen and the hacker know the IP of server which has private key. Then can hacker be able to connect to server using the stolen public key using ssh command?
If no, then why?
My understanding is since the same public key is used by hacker, the server will never know from which machine the ssh request came from. So the server should will validate the public key and allow to login.
Please correct if I am wrong.
As written, the answer to your question is 'no, the hacker cannot connect to the server using the public key you have obtained from the server'. They would also need the user's private key or password.
For more completeness, in case the terminology has been confused:
There can be two sets of public+private keys used when you SSH to a server from your workstation.
The server has a private key, and an associated public key. You copy the public key from the server to your workstation (normally, your ssh client will do this for you when you first connect, and it will end up in a file called known_hosts in your ~/.ssh directory). If the hacker gets the server private key, they can pretend to be the server. If the hacker gets the server public key, they can only verify the identity of the server to themselves.
The workstation (i.e. you) may have a private key, and an associated public key. The private key will normally be in ~/.ssh/id_rsa or similar. The public key will likely be the same filename but with .pub on the end. The contents of the public key will be also be stored on the server in the file ~/.ssh/authorized_keys for the user on the server that the key authenticates. If the hacker gets this private key, they can pretend to be you. If the hacker gets this public key, they can only verify that a connection comes from you. It is possible to do ssh without this workstation-side public+private key, but you would instead be using a password to authenticate to the server rather than a key.
So, the first question you would ask yourself is whether you use a password or a key on the workstation to authenticate to the ssh server. Then whether the hacker has stolen the public key or the private key from either server or workstation.
If the hacker has either public key then this is not generally considered a problem (hence the name 'public').
However, if the hacker has either private key then it is a problem, and you should change that key (on either the server or your workstation). Depending on the key that they've potentially stolen, you will want to remove the server's public key from your workstation ~/.ssh/known_hosts file on your workstation, or your public key from the server (~/.ssh/authorized_keys).
Remember that if the hacker has the server private key, then anyone who has the associated public key in their known_hosts file will still trust the old private key (i.e. a server the hacker creates) even once you've changed the key on the real server, so you will want to make sure the known_hosts files are fixed everywhere. And if they've stolen your private key from the workstation then any server that has the associated public key in it's authorized_keys file will still trust the old key even once you've changed it on your workstation, so you will want to replace the public key on all servers that you use that private key on.
By definition, private keys are private (i.e. secret) and public key are public (i.e. not secret).
A hacker doesn't need to steal a machine's public key, they can simply ask for it. For example:
$ ssh-keyscan github.com
# github.com:22 SSH-2.0-babeld-408889af
# github.com:22 SSH-2.0-babeld-456f9bbd
github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
# github.com:22 SSH-2.0-babeld-408889af
github.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=
# github.com:22 SSH-2.0-babeld-408889af
github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl
# github.com:22 SSH-2.0-babeld-408889af
$
I have heard that SSH does not need certificates.
But for RSA authentication of SSH , it should make sure that public key belong to the server and it can be done with certificates.
But it does not use certificates.
So how does it do?
No. It does NOT NEED them, but it CAN use them (but they are different then the certificates used in SSL! for various reasons). Certificates help only to delegate the verification to some certificate authority. To verify the public key, you just need to get the public key using "secure" channel.
So how you can verify the public key of the server you are connecting to?
There are several possibilities. The server admin will send you using different secure channel the public key of fingerprint of the public key. They can look like this:
Public key: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
You can store this one directly in your ~/.ssh/known_hosts prefixed with the server name and space.
Fingerprint SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1A bitbucket.org (RSA)
When you connect to the server for the first time, you are asked similar question:
The authenticity of host 'bitbucket.org (104.192.143.3)' can't be established.
RSA key fingerprint is SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1A.
Are you sure you want to continue connecting (yes/no)?
Then it is your responsibility to verify that the fingerprint is the same as the one you got from your admin.
If you don't do that, you are in danger that somebody redirected your connection to some malicious server and you are connecting somewhere completely else. The host keys are unique and this attacker would have different key (and therefore different fingerprint) unless he already compromised the original server (and then you are screwed already).
There is also possibility to add the host keys to the SSHFP DNS record, which will eliminate the burden above (you should have DNSSEC, otherwise the DNS records can be modified the same way as your direct connection). For this to work, you need to turn it on in your ssh_config using VerifyHostKeyDNS options.
And what about the certificates?
SSH can use certificates. This is common in company environment, where you are already given a known_hosts file configured with the certificate authority, which is used to sign all the host keys (and usually also the clients authentication keys). In that case, you don't need anything from above and connecting to local infrastructure "just works". Note, these certificates are not X509 as used in SSL/TLS PKI. For more info about these certificates, see manual page for ssh-keygen, which explains that in detail.
I am trying to decrypt a pcap file. This pcap file contains a capture of an HLS encrypted video stream. The pcap contains TLSv1.2 packets.
Below are some information from the pcap file
Server Hello message Cipher Suite:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
EC Diffie-Hellman server Params: pubkey (1)
The Certificate Status message:
Signature Hash Algorithm Hash: SHA256
Signature Hash Algorithm Signature: ECDSA
Client Key Exchange Message
EC Diffie-Hellman server Params: pubkey (2)
I tried to follow [this Wireshark SSL decryption tutorial][1]. But it seems that it works only for RSA encryptions.
I have been researching for a while and found [this discussion][2]. I am quoting an extract from this discussion:
There is an important parameter to mind: decryption of a passively
recorded session (with a copy of the server private key) works only if
the key exchange was of type RSA or static DH; with "DHE" and "ECDHE"
cipher suites, you won't be able to decrypt such a session, even with
knowledge of the server private key. In that case, you will need
either the negotiated "master secret", or to use the server private
key to actively intercept the connection
It's note worthy that I have the client private key. In my case, the client is FFmpeg video streamer (FFplay). I had a look also on the [TLS v1.2 RFC][3].
My question:
Is it possible to do a decryption in this scenario ? If yes, what do I need to have to do so?
Is the decryption done using the client's private key or using the pre_shared_master (i.e. Diffie-Hellman) ?
[1]: https://wiki.wireshark.org/SSL
[2]: https://security.stackexchange.com/questions/117778/how-to-decrypt-ssl-traffic-with-a-packet-sniffer-when-i-have-the-private-key
[3]: https://www.rfc-editor.org/rfc/rfc5246
First, the clients private or public key are not involved in the key exchange in any way but only used to authenticate the client (if requested by the server). What is used in the key exchange are the servers private and public key, but only if RSA key exchange is used. For DHE/ECDHE they are not used so private/public key are not sufficient. See it is possible to decrypt HTTPS with the (private, public) pair if it uses DHE? for the details why this is the case.
What you would need instead of the private key is actually the exchanged key which is unique for each TLS session even if the private key is the same. Some clients can store this key for later use and if your client can do it see Decrypting TLS Browser Traffic With Wireshark – The Easy Way! how to proceed then to decrypt the traffic.
No, it is not possible to decrypt in this scenario. That would involve breaking EC Diffie-Hellman.
Decryption is not directly performed using the pre_master_secret but it is performed by keys directly derived from the pre-master secret. That is: the client and server decryption keys that are derived from it by first deriving the master_secret and then performing the PRF and dividing the output to the session keys and IV's.
I am trying to manually decrypt TLS live stream for experimentation. In order to do so, I have to use the private key and certificate on my client. I use FFplay to stream the video. Since the traffic is encrypted, FFplay has to use a private key and a certificate to decrypt the traffic. I assume that there exist a default path to the private key and the certificate. I've been searching for a while but in vain. Any suggestions please?
FFmpeg doesn't store the keyfile or the cert in files. They're saved in a structure as in here. In order to save them, we can modify the source code and compile as indicated here
I want to access to a server (hosted in Lonex) trough SSH (for file handling). For this I use PuTTY. To do so safely, I use Pagent, it needs a public and a private key.
In the server, under the ssh folder in the root directory there are two files:
id_rsa - which has the private key.
id_rsa.pub - which has a public key.
Given this information, if posible, I would like to generate the necessary files for Pagent.
What I have tried:
Using PuTTYgen to import/load a local copy of the file id_rsa. This successfully generated the the .ppk file needed for Pagent. I referred to the .ppk file in connection -> ssh -> auth. In this .ppk file appears the public and the private key. But when I use PuTTY to connect, having the generated .ppk added to Pagent, an alert prompts stating that I do not have the server's host key cached in the registry and then shows the server's rsa key fingerprint, which I know to not be the right one from the one shown in Pagent. The fact that this alert prompts tells me that my Pagrent key is not correct. Am I correct?
Comments:
- Given that the host already has a public/private key pair I believe I should generate a local private key given the same public key from the host. I could not accomplished this (I read about ssh-keygen commands but I did not find out how to get what I wanted done).
- The ISP suggested that everything I need is in this link: http://sourceforge.net/apps/trac/sourceforge/wiki/SSH%20keys#KeyGeneration:PuTTY
I could not find the use to it given that I do not have a form where I should place a public key generated locally by me and also the fact that it does not consider the situation where I already have a public key generated in the host.
- I asked the ISP if it was possible to add a public key generated locally by me to the authorized_keys2 file and they told me no due to the fact that it is a shared hosting.
Your question really boils down to this:
The fact that this alert prompts tells me that my Pagrent key is not
correct. Am I correct?
No; this is not correct. Your agent (Pageant) is likely set up correctly. As you said,
an alert prompts stating that I do not have the server's host key
cached in the registry and then shows the server's rsa key
fingerprint,
That prompt is for the server's host key, not your user's private key. Pageant only caches your user's private key, not the host's public key (or public key fingerprint). Pageant's purpose is to hold your private key so that the server can identify you; the purpose of the prompt that you saw was for PuTTY to allow you to verify that the server that you're connecting to is really the server you meant to connect to (i.e. that you're not connecting to an attacker's machine).