jv

Thanks, Ken. Just to make sure I'm clear on what you're saying... In using any of these methods, I want to make sure that the original private key does not exit the TPM into say a client like OpenSSL.

Hi all, Let's say that I have a key pair that is created external to a TPM. The private portion of the pair is to be distributed to a number of TPMs. Is there a way to distribute that private key outside of key wrapping (i.e. distributing the private key such that it becomes locked within the TPM, never to see the light of day)? Thanks.

Good guess. I don't recall the owner password being set to something non-empty. I cleared the TPM and things are working as expected. I'm using the nvread from Ubuntu 18.04.3. If I leave off the -of, I get no output. Thanks for the help.

Hi, My goal is to create two ordinary NV locations using platform authorization. Both locations need to allow platform read and write access. One location needs to be readable by everyone and the other location needs to be writable by everyone. I started like this for the globally readable location: tssnvdefinespace -hi p -ha 01000010 -sz 500 +at rst +at ppw +at ppr +at wd +at or +at ar +at aw and wrote its content. I then set a random platform password. Finally, I attempted to read it using owner...

Hi, I'm using ibmtss1470. I'm executing the following: $ tssgetrandom -by 10 -nz -of /dev/stdout|xxd 00000000: e721 08bc 80ae 428d 465f 00 .!....B.F_. Notice the zero-byte at the very end even though -nz is specified. Is the "noZeros" check in getrandom.c perhaps turned around? if ((rc == 0) && (outFilename != NULL)) { rc = TSS_File_WriteBinaryFile(randomBuffer, bytesRequested + (noZeros ? 1 : 0), outFilename); } Thanks.

Hi, I'm using ibmtss1470. I'm seeing the above error when executing the following on a real TPM: $ tsscreateprimary -hi p -ecc nistp256 -st Handle 80000000 $ tssflushcontext -ha 80000000 flushcontext: failed, rc 000b0091 TSS_RC_NO_OBJECTPUBLIC_SLOT - TSS context has no object public slot for handle The operation seems to work, but the error code is causing a problem with various tools. The package was configured as follows: ./configure --disable-tpm-1.2 --prefix=$(pwd)/rootfs/usr --disable-rmtpm...

I think rollback is okay. The content of the NVRAM index will be a root-of-trust certificate. The reason for replacement will likely be because of updated expiration dates in the certificate. If somebody puts an old ROT cert. back into the index, it simply renders some portion of the platform unusable -- which is okay. As long as attacker can't insert their own ROT -- which is prevented by the signing...

While I can appreciate the flexibility and power here, my required implementation will be a minor miracle to achieve -- with next to no feedback as to source of error. :-)