tpm2_protocol / tpm2sh 0.9.0

tpm2_protocol / tpm2sh 0.9.0

[Jarkko Sakkinen]

Hi

0.9.0 is the first "feature complete" version of tpm2_protocol except
couple of minor glitches.

Errata:

    1. SetCapability due this remark below table 137 in the Structures
       specification:
    
       "The TPMU_SET_CAPABILITIES Structure may be defined by a TCG Registry."
    
    2. No TPM_CC_MAC defined as its code conflicts with TPM_CC_HMAC reasoned
       with the most illogical reasoning ever in the end of section 5.2 of
       Structures specification:
    
       "A TPM can implement either TPM2_HMAC()/TPM2_HMAC_Start() or
       TPM2_MAC()/TPM2_MAC_Start() but not both, as they have the same command
       code and there is no way to distinguish them. A TPM that supports
       TPM2_MAC()/TPM2_MAC_Start() will support any code that was written to
       use TPM2_HMAC()/TPM2_HMAC_Start(), but a TPM that supports
       TPM2_HMAC()/TPM2_HMAC_Start() will not support a MAC based on symmetric
       block ciphers."
    
       I.e. reasoning that tells no reasons for overriding a CC, which here
       is the problem, not the "xor relationship" between these commands.
       Neither all other commands work on all TPMs but still they don't
       share the same magic cookie.

I started this project originally in 2024 then I got quickly stuck.
After one year of processing how to do it the result is no_std, zero
dependency crate, which does not require memory allocator. It can
empower both chips, clients, emulators and operating systems. Even tho
most of the code was written in three weeks (11K of 12K for both
protocol and client) the ideas have been developing for a long time.

Next steps are of course slimming up and tightening the implementation
as there must be extra fat scattered here and there, and fix the bugs.
Response handling has a few scoped rough edges that I will look into
first. I think also (and have experience on the topic further to
back it up) that this after maturizing is the solution also for
Linux kernel.

Unlike other TPM2 tools and alike tpm2sh is not designed for human
readable output but instead a programming interface for bash and
similar (e.g. it could be used to enhance tools like 'pass') but
I've developed a human solution i.e. "print-stack" command so it
is the demo for this release:

❯ sudo ./target/debug/tpm2sh create-primary --alg rsa:2048:sha256 | sudo ./target/debug/tpm2sh pcr-read "sha256:0" | sudo ./target/debug/tpm2sh print-stack

⠦ Waiting for TPM...
⠏ ✔ TPM operation complete.                                                                                      Type: pcr-values
  Update Counter: 86
  Bank (sha256):
    PCR 0: b9a5bf5fc2ffbca9b75f75567c84d1f660d4a77d1413f7a4b15de162cd27e6f0
Type: context
  Context:
    Sequence: 0x8b
    Saved Handle: 0x80000000
    Hierarchy: TPM_RH_OWNER

Now it's time to a short break (ignored other life to get this
vomitted out) ... :-)

BR, Jarkko

Re: tpm2_protocol / tpm2sh 0.9.0

[Jarkko Sakkinen]

On Wed, Aug 20, 2025 at 03:13:11AM +0300, Jarkko Sakkinen wrote:
> I started this project originally in 2024 then I got quickly stuck.
> After one year of processing how to do it the result is no_std, zero
> dependency crate, which does not require memory allocator. It can
> empower both chips, clients, emulators and operating systems. Even tho
> most of the code was written in three weeks (11K of 12K for both
> protocol and client) the ideas have been developing for a long time.

Also tpm2_protocol byte granular precision in its understanding of the
protocol.

We don't need to validate anymore just length or trivial metrics like
that. The power of Rust here is really that we can structurally say
what "is" and what "is not".

It's not just a security property. It increases the overall stability
of the system. One particular benefit that it gives for kernel hacking
is the ability in some cases to differentiate the stimulus of a bug
between kernel, hardware and firmware.

My crate takes byte granularity seriously. E.g. day ago I noticed
that spec had enums with signed discriminants, which I hadn't paid
attention but compiler reminded  me of that by complaining that
building and parsing traits were not available for 'i8' :-) (it
event has separate building and parsing traits for u8).

BR, Jarkko