I've got a bunch of servers with TPM2 onboard and I'd like to authenticate their TPMs. How can I accomplish that using tpm2-tools? I would like to do the following:
Get TPM Attestation certificate (where can I find such a certificate?)
Generate a key pair inside a TPM
Make TPM sign the generated private key with it's attestation key
Make TPM sign a random challenge with the generated private key
Just to clarify all the things I'd like to get something close to PIV Attestation in Yubikeys as it's easy to use and to understand. Can I do the same with TPM2 and tpm2-tools?
Related
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.
I'm building an application and want it to securely transfer data to a server.
Thinking to use public/private keys for initial handshake to encrypt a key with which to encrypt subsequent data.
Is it reasonable to have the private key integrated in the executable which will be distributed out in the wild for anyone to reverse-engineer?
I also thought of using three-pass protocol, but read about some of its weaknesses and it probably won't work for me
I followed Martin's advice and posted to security exchange (https://security.stackexchange.com/questions/158650/distribute-private-key-with-application).
There I received an answer that I accepted, by user Serverfrog:
Generate the Private/Public Keypair on the client, encrypt this with a
password (maybe choose from the User itself).
The send the Public Key encrypted via Server Public Key to the Server
and you have your entire Public/Private Stack.
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'm currently researching on PGP and authentication schemes.
Let's say i'm communicating with someone who claims to be an admin of a ftp site. (say, his email address is admin#genuine-website.com)
Assume both of us have one another's PGP public keys.
Say first, we exchange fingerprints and verify them (by directly transmitting them and not using out of band authentication like phone/sms). In the second step, we exchange a signed message and then verify the signature.
Are these two steps good enough to establish authenticity?
By means of this fictitious example, the basic question i'm trying to ask is whether these steps are "enough" or should i opt for another mutual authentication scheme on top of this?
That's enough, however the most tricky is to verify fingerprints.
For PGP this is done via cross-signing keys with other keys. While in X.509 it is hierarchical structure (top CAs and signed by them certificates), in PGP it is done as 'web of trust'.
No, that's not good enough. A man-in-the-middle can substitute his public keys for yours and your partner's, and then do the same thing with the fingerprints so that everything appears to check out okay.
You'll need to use PGP's web of trust, or exchange fingerprints in another medium that you trust, to verify the public key you received is authentic.
I am trying to understand how SSH authorization method work because I am trying to setup an git server using gitolite.
As far as I know gitolite will use the ssh to authorize users and give access to them to a specific repository with personal write and read permissions. But I am confused about how the authorization will work.
I've watched some videos in YouTube and they use some analogy with colors to explain. If I understand right, for two persons that are going to communicate between each other in a secret way, they need a secret and public key.
The two persons know each other public keys, and to communicate between each other they agree to use one public key. To establish a connection they encrypt they private key using the same public key and send the result to each other. When they receive the result they add the private key to that message and like magic they got the same message.
But I don't think I understand this right because I can't see how the server will verify the the client. I know the server had to hold the public keys from the clients that will connect to him, but he also got a private key?
When the client tries to connect to a server, he sends his private key encrypted with his public key, and the server encrypt his private key using the client public key and send to the client?
How the server check if the user is really him? I also read that to decrypt the information encrypted with a public key, only the person that holds the private key can decrypt the message. So how the server can decrypt the message send by the client if he don't have the client private key?
If someone could explain me how the authentication, authorization, and exchange of information work using this public and private keys I would be very happy.
SSH works roughly like the following. Note that this is merely a high level explanation:
Each party has two keys: a public key and a private key. The public/private keys are related mathematically, such that they are functionally inverse. Thus an operation performed by one can only be undone exactly by the other. It is complex, but think of it like calculating x^nnn versus the nnnth root of x. The former is easy but the latter is difficult, making it computationally unfeasible to guess with enough accuracy to undo the operation. This gives us some desirable attributes that allow SSH to do the following with them:
The client connects to the server. The server proves its identity by presenting a certificate signed with its private key. The client uses the server's public key to decrypt the certificate and knows that only the client could have encrypted it since it requires the private key. The server then does the same with a certificate presented by the client. Identification can only be performed with 100% assurance using a trusted third party to manage the public keys. Without the third party only identity changes can be detected.
Now that identities are verified, the server generates a symmetric secret key, encrypts it with the client's public key, and send it to the client (who is the only one that can decrypt the message since it requires the private key). From this point on, both the client and server have the symmetric secret key, and all communication is encrypted with this key. This is done for performance reasons because symmetric encryption operations are roughly 100 times faster than asymmetric operations.
This is how SSL verifies identities, and encrypts the information. Note that more granular access control are provided by higher level applications (such as *nix file permissions), not SSL.
Explanation of this subject is a little bit excessive for Stackoverflow format.
Few days ago Coursera started a free course on Cryptography (part I) that explains exactly the matters you are interested in.
I welcome you to cryptography course to find the answers for your questions