July 2022 - tpm2 - Ml01.01.Org

by henry.gadacz＠stud.h-da.de

Hello everyone, I am trying to accomplish the following, but did not succeed and I hope someone can help me. I want to have a docker compose with two containers. In the first container I want to run the swtpm (https://github.com/stefanberger/swtpm) and in the other a python script that uses tpm2-pytss to connect to the swtpm in the first container. When I run swtpm and the python script in the same container it works. In order to run them in separate containers I just duplicated the Dockerfile (I know this has some overhead, but to make sure don't miss any dependencies), changed the docker CMD command to either run the python script or the swtpm and renamed them to Dockerfile_app_test and Dockerfile_tpm_test. My docker compose file is looking like this: version: '3.7' services: app: container_name: app build: context: . dockerfile: Dockerfile_app_test restart: unless-stopped tpm: container_name: tpm build: context: . dockerfile: Dockerfile_tpm_test ports: - "2321:2321" - "2322:2322" restart: unless-stopped My python script is: from tpm2_pytss import * if __name__ == '__main__': print("TPM test application") tpm = ESAPI(tcti="swtpm:host=tpm,port=2321") tpm.startup(TPM2_SU.CLEAR) r = tpm.get_random(8) print("type is ", type(r)) print("r is ", str(r)) print("as int ", int(str(r), 16)) When I run it in one Dockerfile I used tpm = ESAPI(tcti="swtpm:host=localhost,port=2321") so I thought changing the host name to the docker container name should do it but I always get the following errors: app | WARNING:tcti:src/util/io.c:262:socket_connect() Failed to connect to host 172.21.0.2, port 2321: errno 111: Connection refused app | ERROR:tcti:src/tss2-tcti/tcti-swtpm.c:614:Tss2_Tcti_Swtpm_Init() Cannot connect to swtpm TPM socket app | ERROR:tcti:src/tss2-tcti/tctildr-dl.c:170:tcti_from_file() Could not initialize TCTI file: swtpm app | ERROR:tcti:src/tss2-tcti/tctildr.c:428:Tss2_TctiLdr_Initialize_Ex() Failed to instantiate TCTI app | Traceback (most recent call last): app | File "/app/main.py", line 70, in <module> app | tpm = ESAPI(tcti="swtpm:host=tpm,port=2321") app | File "/usr/local/lib/python3.10/dist-packages/tpm2_pytss/ESAPI.py", line 123, in __init__ app | tcti = TCTILdr.parse(tcti) app | File "/usr/local/lib/python3.10/dist-packages/tpm2_pytss/TCTILdr.py", line 54, in parse app | return cls(name, conf) app | File "/usr/local/lib/python3.10/dist-packages/tpm2_pytss/TCTILdr.py", line 29, in __init__ app | _chkrc(lib.Tss2_TctiLdr_Initialize_Ex(name, conf, self._ctx_pp)) app | File "/usr/local/lib/python3.10/dist-packages/tpm2_pytss/internal/utils.py", line 32, in _chkr app | raise TSS2_Exception(rc) app | tpm2_pytss.TSS2_Exception.TSS2_Exception: tcti:IO failure app exited with code 1 I know it's not a plain tpm2-tss question, but does anyone has experience with that and can help me? Kind regards, Henry

1 week, 4 days

3
5
0 / 0

Re: Lifecycle of handles and contexts

by Roberts, William C

On Tue, 2022-07-19 at 22:17 +0000, Kenneth Goldman wrote: > > On Mon, 2022-07-18 at 17:36 +0000, Kenneth Goldman wrote: > > > It depends. > > > > > > Windows seems to have a large keystore, so you probably don't > > > have to > > > ever flush. > > > > > > Linux in kernel RM manages keys across processes but not within > > > processes, so you still have to flush. > > > > This is also how TBS works on Windows. > > Not on my Windows 10. I just created 32 keys with one process. Now > there are > 32 loaded keys. Did the process exit? I always thought TBS was spec compliant: "The RM also monitors connections, and removes table entries and ContextFlushes leftover sessions when the caller closes a connection." from Section 2.3.3 of: https://trustedcomputinggroup.org/wp-content/uploads/TSS_2p0_TAB_Resource... The table entries include transient handles and their associated virtual mapping. > OK, the Windows RM swaps them out, but the application never > sees that. > > I don't know what the RM limit is, but it's certainly far more than > the TPM > itself. > > getcapability.exe -cap 1 -pr 80000000 > 32 handles > 80ffffe0 > 80ffffe1 > 80ffffe2 > 80ffffe3 > 80ffffe4 > 80ffffe5 > 80ffffe6 > 80ffffe7 > 80ffffe8 > 80ffffe9 > 80ffffea > 80ffffeb > 80ffffec > 80ffffed > 80ffffee > 80ffffef > 80fffff0 > 80fffff1 > 80fffff2 > 80fffff3 > 80fffff4 > 80fffff5 > 80fffff6 > 80fffff7 > 80fffff8 > 80fffff9 > 80fffffa > 80fffffb > 80fffffc > 80fffffd > 80fffffe > 80ffffff These look like virtual handles. The spec also states, "In responses that return handles, these handles MUST be virtualized before returning the response to the caller:  These virtual handles MUST be unique per connection". I don't think anyone actually makes them unique per connection.

2 weeks, 4 days

1
0
0 / 0

Re: Lifecycle of handles and contexts

by Roberts, William C

On Mon, 2022-07-18 at 17:36 +0000, Kenneth Goldman wrote: > It depends. > > Windows seems to have a large keystore, so you probably don't have to > ever > flush. > > Linux in kernel RM manages keys across processes but not within > processes, > so you still have to flush. This is also how TBS works on Windows. > > Why not seal (create) against the primary storage key. > > > -----Original Message----- > > From: Tim K <tpm2(a)bitzap.e4ward.com> > > Sent: Monday, July 18, 2022 1:03 PM > > To: tpm2(a)lists.01.org > > Subject: [EXTERNAL] [tpm2] Re: Lifecycle of handles and contexts > > > > > flushcontext > > > > But when using a resource manager the context gets fushed > > automatically. > Or I > > can flush it manually. But still, after a flushcontext, I can just > tpm2_unseal > > without loading the key again -- why does that work? It would help to have specific examples and your environment, very rarely do you ever need to be concerned with flushcontext calls. The details below will be very specific to Linux using a resource manager and the tpm2-tools. If your using the tpm2-tools you use a context file, so even if the object is flushed, when you call tpm2_unseal -c <context file> the context is loaded and object is created again. The context files are only good for that "tpm boot". The same is if your not using a resource manager, since the tpm2-tools act as a resource manager. This is so you can use transient objects between commands and have a resource manager automatically flush the transient resources. The end goal is that the behavior should appear the same with and without Resource Managers running in your scripts.

3 weeks, 3 days

3
2
0 / 0

Need help: Nginx and TPM2 Connection Problem

by Rajkumar K Sivasamy

Team We are running Ngnix which uses TPM 2.0 Engine through Ngnix config option "ssl_engine tpm2tss"; now when Ngnix trying to make use of the *tpm2tss *engine it is hitting following error: - The 'nginx' worker process is unable to access the 'dbus' exposed by the 'tabrmd' process. Looking into the 'nginx' error log, the following errors are seen: ** (process:8020): CRITICAL **: failed to allocate dbus proxy object: Timeout was reached ERROR:tcti:src/tss2-tcti/tctildr-dl.c:154:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-tabrmd.so.0 - ‘dbus’ shows warnings with the following logs: dbus[1928]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 30001ms) - Whenever 'nginx' is trying to connect to backend server, it is closing the connection. In the logs, SSL handshake failure messages are seen. The SSL connection is not working, it is getting closed. nginx: [info] 8020#0: *2 peer closed connection in SSL handshake while SSL handshaking, client: <IP_Address>, server: 0.0.0.0:443 Version of packages: kernel 4.14.76 nginx 1.14.0 openssl 1.1.1 tpm2-abrmd 2.3.2 Note that the openssl when executed directly it is able to make use of TPM2.0 engine and we have other processes which makes use of tpm2tss and they are all working fine, the problem is only with Ngnix. We would need your help here, can you let us know how to resolve this "*failed to allocate dbus proxy object*" error? Thanks Raj

3 weeks, 3 days

2
1
0 / 0

Recommended way to encrypt a credential

by Tim K

Let's assume I have a credential for some other remote system that I'd like to store somewhat protected so it can be used in a cron job. What is the recommended way? I see a few possibilities: 1. Create a primary key, an encryption key and seal the credential (it's small, less than 128 bytes) 2. Use an encryption key to encrypt something like a GPG passphrase (or maybe the GPG private key without a passphrase) and then gpg-encrypt a file that holds my credential 3. Use tpm2_encryptdecrypt which looks like some form of simplifying #2 above and may also work with files that may slightly exceed 128 bytes 4. Just store the credential directly at an NV index Thanks!

3 weeks, 3 days

2
3
0 / 0

Lifecycle of handles and contexts

by Tim K

Is there a good resource that describes the lifecycle of handles and contexts, in easy to understand terms? For example, if I create a primary key and then create a key and seal some data, I can keep unsealing the data without reloading the key. But if I reboot the computer, I have to create the primary key again and reload the key then I can unseal multiple times. So these keys get stored in the TPM until reboot it seems. Is there a way to flush them out of the TPM or even list what's stored? Is there a way to list what's stored, what keys are loaded? What about flushing them out without rebooting? Thanks!

3 weeks, 4 days

3
3
0 / 0

Re: Tss2_Tcti_Device_Init context not zeroed

by Roberts, William C

+ list > 1 – Is mandatory zeroing it before calling Tss2_Tcti_Device_Init? If so, is it a case of missing specification? No it shouldn't be required IIUC > 2 – No, it isn’t, so is there a bug? Looks like a bug and it looks consistent throughout all the init routines for TCTIs. ________________________________ From: Antonio de Moraes, Marcos <marcos.antonio-de-moraes(a)hpe.com> Sent: Monday, July 11, 2022 1:21 PM To: tpm2-owner(a)lists.01.org <tpm2-owner(a)lists.01.org> Subject: Tss2_Tcti_Device_Init context not zeroed Hi all, I noticed when performing subsequent tpm2 calls over a not zeroed tcti context passed to Tss2_Tcti_Device_Init I have errors such as: “WARNING:tcti:src/tss2-tcti/tcti-device.c:321:tcti_device_receive() TPM2 response size disagrees with number of bytes read from fd 3. Header says 0 but we read 29 bytes. ERROR:sys:src/tss2-sys/api/Tss2_Sys_Execute.c:118:Tss2_Sys_ExecuteFinish() Malformed response: Invalid tag in response header: 0” I made some experiments: If I put some content different than 0x00 at offset 89 in memory block passed to RC Tss2_Tcti_Device_Init it fails. That is also true for some other offsets. TSS2_RC Tss2_Tcti_Device_Init (TSS2_TCTI_CONTEXT *tctiContext, size_t *size, const char *conf); I check the description of Tss2_Tcti_Device_Init and didn’t find any observation that tctiContext parameter must point an zeroed memory block, although in the usage examples the allocated memory is zeroed , calling calloc( 1, <needed size>). Regarding tctiContext memory block passed to Tss2_Tcti_Device_Init: 1 – Is mandatory zeroing it before calling Tss2_Tcti_Device_Init? If so, is it a case of missing specification? 2 – No, it isn’t, so is there a bug? My environment: TCTI shared library: libtss2-tcti-device.so.0 OS: Enterprise Suse Linux Thanks in advance, Marcos A. de Moraes HPE Security Software Engineer

4 weeks, 1 day

2
2
0 / 0

How to initialize a used TPM2 module and thoughts on clevis

by tpm2＠bitzap.e4ward.com

Hello - New to TPM2 here. I'm adding a *used* TPM2 module to a mobo that has a header. What are best practices to initialize the TPM2 module? Should I clear it first, possibly via the BIOS? Should I set an owner password? So far I found `echo 5 > /sys/class/tpm/tpm0/ppi/request` which is probably a good idea to do as I don't know where the module comes from and whether anyone has messed with it before. I'd appreciate any pointers in the right direction and the correct commands to start with a clean TPM2. Running Ubuntu 20.04 and I installed tpm2-tools. Also, is `clevis encrypt tpm2` a good wrapper if I just want to a simple way to encrypt/decrypt a file on disk that holds other credentials? Thank you!

1 month

3
6
0 / 0

Tss2_Tcti_Device_Init context not zeroed

by Antonio de Moraes, Marcos

Hi all, I noticed when performing subsequent tpm2 calls over a not zeroed tcti context passed to Tss2_Tcti_Device_Init I have errors such as: "WARNING:tcti:src/tss2-tcti/tcti-device.c:321:tcti_device_receive() TPM2 response size disagrees with number of bytes read from fd 3. Header says 0 but we read 29 bytes. ERROR:sys:src/tss2-sys/api/Tss2_Sys_Execute.c:118:Tss2_Sys_ExecuteFinish() Malformed response: Invalid tag in response header: 0" I made some experiments: If I put some content different than 0x00 at offset 89 in memory block passed to RC Tss2_Tcti_Device_Init it fails. That is also true for some other offsets. TSS2_RC Tss2_Tcti_Device_Init (TSS2_TCTI_CONTEXT *tctiContext, size_t *size, const char *conf); I check the description of Tss2_Tcti_Device_Init and didn't find any observation that tctiContext parameter must point an zeroed memory block, although in the usage examples the allocated memory is zeroed , calling calloc( 1, <needed size>). Regarding tctiContext memory block passed to Tss2_Tcti_Device_Init: 1 - Is mandatory zeroing it before calling Tss2_Tcti_Device_Init? If so, is it a case of missing specification? 2 - No, it isn't, so is there a bug? My environment: TCTI shared library: libtss2-tcti-device.so.0 OS: Enterprise Suse Linux Thanks in advance, Marcos A. de Moraes HPE Security Software Engineer

1 month

1
0
0 / 0

Sorry about the Spam

by Roberts, William C

I keep banning emails but the spam still gets through, sorry folks.

1 month

1
0
0 / 0

2022

2021

2020

2019

2018

2017

tpm2 July 2022