I'm trying to understand the key exchange happening with CurveMQ described here.
http://curvezmq.org/page:read-the-docs
My understanding of public key cryptography is you use a public key to encrypt data that can then be decrypted by the corresponding private key. In the CurveMQ specification it describes encrypting data from a key to a key. See the excerpts below they reference 2 keys. What does this mean in layman's terms?
The signature box (80 octets). This SHALL contain 64 zero octets,
encrypted from the client's transient key C' to the server's permanent
key S.
and
A welcome box (144 octets) that encrypts the server public transient
key S' (32 octets) and the server cookie (96 octets), from the server
permanent key S to the client's transient key C'.
Related
I have a question related to bitstream encryption using eFUSE option. If my FPGA has bitstream encryption key stored in the eFUSE, how Vivado will know the encryption key when generating new encrypted bitstream? Does Vivado has a method to readback the key from eFUSE and use it for encryption?
How can Vivado know the encryption key?
Vivado uses an NKY file that is generated when setting the encryption key. For instance when executing
set_property BITSTREAM.ENCRYPTION.KEY0 56’h12345678ABCDDCBA12345678ABCDDCBA12345678ABCDDCBA12345678ABCDDCBA current_design]
An NKY file will be create, whose format is:
KEY 0 <hex string> (256 bit AES key)
For example: (top.nky)
Device xc7k325t;
Key 0 12345678ABCDDCBA12345678ABCDDCBA12345678ABCDDCBA12345678ABCDDCBA;
Key StartCBC 7115e9aa80085ea3ed65d26d3a8ab608;
Key HMAC d293d51c6058430262b05521f8f67279c9abce27d5fcafcf839bbe1af46713cc;
Can Vivado read back the key?
Quoting XAPP1239
The encryption key can only be loaded onto a device through the JTAG interface
After the key is programmed and the key-access mode is exited, the key cannot be read out of the device by any means, and it cannot be reprogrammed without clearing the entire device.
I have service that runs in background, manages cryptographic keys. I want to transfer those keys from one end to another.
This transfer includes RSA's Private Key also. During this transfer I encrypt actual Key value with some other public key. AES "key value" encryption working as expected. But RSA private key transfer it throws following error.
error=crypto/rsa: message too long for RSA public key size
I understand that only limited amount of bytes can be encrypted by particular length of key length.
For 3072 bit public key it shows, "Data must not be longer than 373
bytes"
For 4096 bit public key it shows, "Data must not be longer than 501
bytes"
Reference -> https://www.devglan.com/online-tools/rsa-encryption-decryption
But in my case, actual key length of private key is 1624(2048 key length). To encrypt this I need to create key pair with 15360 encrypt key with public key(15360)and it is working.
But I've key supported length up to 15360 in my service. So again to transfer this length of private key I need to create again 115200(i'm not sure about this length) of length keypair? Whether this approach is correct or there is any other way for this problem ?
I need to
run .exe on client machine, which will create key pair within TPM.
And then I will create CSR with public key part of key pair generated by TPM.
My concerns are how do i ensure that keys are created inside TPM , and not by spoofed TPM. Which would enable private key to be migrated and copied.
I heard that is what AIKs are for , but i don't understand how can this prevent TPM for being spoofed?
One solution that i can think of is : I go to client, boot from USB with trusted OS, and then obtain EKpub.
The process of proving that a key originates from a TPM is known as:
For TPM 2.0: Credential activation, enforced with TPM2_ActivateCredential
For TPM 1.2: Identity activation, enforced with TPM_ActivateIdentity
This technique accomplishes many things, but one of them is proving that the key generated after issuing a request to the TPM actually originates from a trusted TPM and was not spoofed. For TPM 1.2, since that's what the question is about, identity activation is an 8-step process that goes like this (what follows is an excerpt from TCG's AIK Certificate Enrollment):
Step 1: Platform asks the TPM to create the AIK key pair.
(a) The platform (or application software on the platform) issues to the TSS the CollateIdentityRequest command. In turn the TSS
issues the MakeIdentity command to the TPM. This results in the TPM
generating a fresh AIK public key pair.
(b) Within the MakeIdentity function the TPM creates the IDENTITY_CONTENTS structure containing the following items: (i) The
structure version, (ii) TPM command ordinal, (iii) PrivCADigest
label and (iv) AIK_pub_key.
(c) The TPM signs IDENTITY_CONTENTS structure using the AIK_priv_key, with the resulting signature portion being referred to
as the identityBinding.
(d) The TPM outputs two (2) items as a result of the MakeIdentity command: AIK_pub_key and the identityBinding.
Step 2: TSS produces proof structure concerning the AIK
(a) Following from the previous step, the TSS creates the IDENTITY_PROOF structure. This structure consists of the following
items: (i) The identityBinding structure from Step 1(d). (Note: The
identityBinding structure is the signature portion only over the
IDENTITY_CONTENTS structure). Note: It must be noted that the
identityBinding structure is NOT cryptographic proof that the AIK is
a TPM-resident key and that the AIK has been certified using the EK.
It only demonstrates that some key pair exists. (ii) The TPM spec
version (iii) The SubjectPublicKeyInfo (i.e. the AIK_pub_key) (iv)
The IdentityLabel (v) EK certificate (vi) Platform certificate
(b) The TSS then generates a symmetric key K1 (local random number from the TPM) and encrypts the IDENTITY_PROOF structure using
this symmetric key K1.
(c) The TSS then encrypts key K1 using the public key of the ACA. This encryption using public-key of the Attestation CA is
intended to limit disclosure of K1 to the ACA only. The results of
this step are two items: the encrypted IDENTITY_PROOF structure and
the encrypted symmetric key K1. Encrypted IDENTITY_PROOF and
encrypted K1 are bundled into an IDENTITY_REQ structure that
includes identifiers for the symmetric and asymmetric algorithms used
to encrypt the structures plus sizes of the encrypted structures.
Step 3: Platform sends AIK certificate request to the ACA. The platform (or application software on the platform) takes the
IDENTITY_REQ resulting from the previous step, encrypts it, and
sends it to the ACA.
Step 4: ACA verifies certificate request. Upon receiving the certificate request, the ACA must perform a number of verifications.
(a) To get access to the AIK certificate request structure, ACA must first decrypt the key K1 using its ACA private key.
(b) The ACA then uses K1 to decrypt the IDENTITY_PROOF structure.
(c) The ACA must then recreate the IDENTITY_CONTENTS structure and verify that the signature (as represented by the received
identityBinding) is correct. The ACA can perform the verification
because it now has the items listed in Step 2 above and can assemble
the same PrivCADigestLabel as was provided to the TPM. As part of
the verification, the ACA is expected to validate the received
certificates (ie. EK and Platform Certificates). It is expected that
the ACA will use standard X.509 certificate validation techniques,
such as CRL checking [14] and/or querying the appropriate OCSP
responders [15] to the issuer of the EK certificate (e.g. TPM
manufacturer site).
Step 5: ACA issues a new AIK certificate. The ACA then creates a new AIK certificate, using (as the public key) the received AIK public
key in the previous step. The ACA issues (signs) the new AIK
certificate using its own AIK signing key.
Step 6: ACA encrypts the new AIK certificate. In this phase, the ACA must prepare the newly issued AIK certificate in a form
recognizable by the TPM. As part of the TPM_ActivateIdentity command
(Section 15.2 of [5]), the TPM expects input in the TPM_EK_BLOB or
the (older spec version) ASYM_CA_CONTENTS structure. The ACA
performs the following tasks:
(a) The ACA generates a random symmetric encryption key K2. This random K2 is unique for each AIK certificate request.
(b) The ACA encrypts the new AIK certificate using key K2.
(c) The ACA then creates either a TPM_EK_BLOB or ASYM_CA_CONTENTS (depending on the TPM version) structure which
contains the following: (i) The hash of the AIK public key (namely the
AIK public key as found in the original request). (ii) The symmetric
key K2. (iii) Optional PCR information – for TPM_EK_BLOB only. The
TPM checks to ensure that the TPM PCR’s and locality are in the
correct state as anticipated by the ACA to unlock K2.
(d) The ACA encrypts the TPM_EK_BLOB or ASYM_CA_CONTENTS structure using the EK public key (as found in the EK certificate in
the original request). The purpose of the last step is to ensure that
only the same requesting TPM will be the sole entity that can decrypt
the newly issued AIK certificate, since only that TPM possesses the EK
private key (which is a TPM-resident key).
Step 7: ACA delivers the new AIK certificate to the TPM on the Platform. The ACA then delivers the encrypted result (encrypted AIK
certificate + either the blob or ASYM struct) to the requestor
platform/TPM.
Step 8: Decryption of new AIK certificate by the TPM. Upon receiving the (encrypted) AIK certificate from the ACA, the platform
must input the structure (either the blob or ASYM struct) (into the
TPM and activate it using the TSS Tspi_TPM_ActivateIdentity command.
This command decrypts the (encrypted) symmetric key K2 from the ACA
using the EK-private-key (which resides only in the TPM) after
ensuring an AIK with a matching pub key resides in the TPM. It then
uses the symmetric key K2 to decrypt the AIK certificate.
The crucial part here is the next-to-last sentence:
This command decrypts the (encrypted) symmetric key K2 from the ACA
using the EK-private-key (which resides only in the TPM) after
ensuring an AIK with a matching pub key resides in the TPM.
It is enforced by the spec that the EK will not decrypt the TPM_EK_BLOB object unless the private key that the activation is requested for is found within the TPM. And because the object was encrypted by the TSS without using the TPM secrets, and you have already verified the EK public key up the manufacturer's CA cert chain, it is ensured that the key that identity activation is requested for has originated within a TPM manufactured by a trusted entity.
I need to generate a keypair and give the public key to someone. They say it needs to be:
AES-256 CBC 128-bit block size.
random Initialization Victor IV of 16b fixed length.
PKCS7Padding
I don't even know if these are the defaults or not or even if I'm asking in the right place. How can I make a key like this?
Your requirements cannot be correct. AES is a symmetric algorithm, which means both parties should have the same secret key. Key pairs are generated for asymmetric encryption such as RSA.
Most of the time AES and RSA are used together for encryption. This is called hybrid encryption: a random AES key is generated and used to encrypt the plaintext. Then the AES key is encrypted with the RSA public key (using OAEP padding, for instance). Then the resulting ciphertext and the encrypted key are send to the other party, which can decrypt the AES key using the private key, and then the ciphertext with the AES key.
If you just need to give a secret key you must use secure transport. An AES key can be 256 bits secure random key, which can easily be extracted from /dev/urandom, e.g.:
dd bs=1 count=32 if=/dev/urandom of=aes-256-key.bin
for RSA, use the openssl command line, for instance.
Can anyone explain why the CryptImportKey function accepts an hPubKey of 0 (the decryption key handle), when importing an encrypted session-type key-blob from another computer?
The environment is this:
PC #1: Generates a key exchange key-pair (public/private) in a local key-container (CryptGenKey w/ AT_KEYEXCHANGE), then exports the public portion as a PUBLICKEYBLOB and sends it to PC #2
PC #2: Takes the public key-blob from PC #1 and imports it to a local key-container. Creates a session key in the same local key-container. Exports the local key-container session key to a SIMPLEBLOB (CryptExportKey), using the public key that was imported from the client's key blob (this is used to encrypt the session key).
PC #1: Takes the encrypted session key-blob from PC #2 and calls CryptImportKey, providing the local key container hProv, the key-blob buffer pointer and length, 0 (zero) for hPubKey and flags, and a pointer to an HCRYPTKEY handle.
After doing the above I get a valid handle back, and can call CryptEncrypt and CryptDecrypt using the handle I got back. Yes, if I specify on CryptImportKey the handle of the key exchange key-pair generated from the first step above on PC #1, that works as well. I just don't understand why a 0 for hPubKey works, it's as if the CryptoAPI "knows" what the private key was to encrypt the data.
Thanks.
The only thing I can think of is that you use this within a session (which has context, thus knows the private key), or that you are not actually encrypting the data. Note that it is actually possible to look up the private key using the modulus as a unique key, but I could not fathom that they would use such a method without telling the user.
PS sorry, I cannot make comments to your question directly (yet), so I posted this because of the long time frame.