That's why I think we'd need to use fakeroot to simulate changing gid/uid ... I can look into doing this. Thanks ... I think if we know that we can be pretty certain that the chown below should succee

Without it handle abstraction can't be done properly, so it is fairly essential to the operation of the TSS. Signed-off-by: James Bottomley <James.Bottomley@...> --- configure.ac | 8

Is there an additional test or tests that could be added to check_tpm_dir.sh to make sure this code works so we can prevent regressions? I know this is a bit nasty because make check is usually run by

It was pointed out to me privately that because the Intel TSS seems unaccountably to be lacking exports of a lot of the support routines used to do necessary operations for key import, like inner and

The Intel TSS doesn't seem to be able to use the NULL seed correctly as a key parent. NULL seed parents are useful for secret keys that can't live beyond a reboot, but the number of consumers for this

Using the previously created abstrations, insert wrappers for the Intel TSS. There are significant annoyances like the IBM constants are taken from the TCG TPM guides, which all begin TPM_ and the Int

Apparently no-one at the TCG read the memo on pointless abstractions, so they have an internal and an external representation for the TPM handles. The really annoying thing is that the two are represe

The IBM TSS uses a single execute primitive whereas the Intel one uses a functional primitive. Neither can be exactly mapped, so create a new functional primitive which can fill the gap between them.

The eventual goal is to support either the Intel or the IBM TSS. One of the many differences between them is the TPM2B structures are mostly unions in the IBM TSS and straight definitions in the Intel

A long time ago I had hoped that the Intel and IBM TSS could be combined in a single package, so everyone could get the advantages of both (the IBM TSS would become and additional library in the Intel

This is a diagnostic message coming out of engine_ctrl ... it just says the engine didn't understand the control option ... whatever it was. I'd be curious to know what it was, but likely enough we sh

I think what you want is a certificate for an attestation key signed by a CA, right? The problem is that all CA commands consume CSRs which are supposed to be self signed to prove the person sending t

That's correct. In order to sign anything with a restricted signing key, you have to prove to the TPM that it generated the hash ... that's the missing TPMT_TK_HASHCHECK which causes the TPM_RC_TICKET

The original design of this project was to export TPM key operations using PKCS#11, so TPM keys could be used by any crypto system that supports PKCS#11. The specific targets I had in mind were gnutls

The fixes since 2.4.1 are: James Bottomley (7): tpm2-common: add support for every currently specified TPM2 curve wrap_ecc.sh: Add tests for explicit curve parametrisation tpm2-common.c: make openssl

The openssl rsa and pkey commands will import a public engine key with the -pubin option, so add this and remove the password to exercise the new public key option. Signed-off-by: James Bottomley <Jam

Users are slightly perplexed when we ask for a password to read the public part of the key, since there's no password protected information in there. This is because we implement only the private key

The current engine key behaves exactly like a private key. Namely that if you want to obtain the public components from it you have to provide the key password. This is in-line with standard encrypted

OK upstream accepted this was a bug and say they've uploaded a fix in the latest release: https://sourceforge.net/p/ibmtpm20tss/tss/ci/92c75ee8e0f9ef46f1dcca12a61192facfeb2958/ James

In addition to tpm_server there's another tpm emulator called swtpm. Avoid forcing distributions to support both by adjusting the test suite to run with either emulator and detecting in configure whic