Meanwhile, while I'm on a #Ghidra bender this evening - I just found this neat tutorial on using Zynamics #BinDiff with Ghidra, via the #BinExport plugin:
https://www.0x90.se/reverse%20engineering/install-binexport-and-bindiff/

I'm planning to give this a go - while I had access to IDA+Bindiff, I used it a fair bit.

Edit - in case you missed it, BinDiff and BinExport are also now open-source:
BinDiff: https://github.com/google/bindiff
BinExport: https://github.com/google/binexport

Here’s the next steps for tpm2-cli.

Transient objects:

• tpm2-cli flush
  • TPM2_FlushContext
• tpm2-cli create
  • TPM2_Create
• tpm2-cli load
  1. ASN.1 decode.
  2. TPM2_Load
• tpm2-cli save
  1. TPM2_Import
  2. ASN.1 encode.

Persistent objects:

• tpm2-cli punch.
  • Inspired by fallocate(2) FALLOC_FL_PUNCH_HOLE.
• tpm2-cli persist
  • TPM2_EvictControl

So the basic gist here is that the command-line I/O goes always in ASN.1 format. Obviously other formats could be supported too but that is what I care myself ATM.

After that I’ll see how much the smoke test transcripts in my kernel patch set cover letter simplify:

https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/

@Foxboron @duxsco that's a shame but at least it. can be now supported. i.e. could be worse ;-) K1 is not even the registry and getting to the registry is mandatory requirement for anyone to consider a new algorithm.

For kernel maintainers RSA + NIST does provide quite a good coverage for certificate keys, so as an opt-in feature, not required but can ease the workflow, it is level up even with just those two curves (and that was anyway my original take) :-)

@Foxboron @duxsco

OK so this is how these are:

• K1/R1: {256,384,521} bits finite field: ECDSA + SHA-{256,384,512}
• 25519: 255 bits finite field: EdDSA + SHA-512
• 448: 224 bits finite field: EdDSA + SHAKE256

They are all in the TCG Algorithm Registry so it is up to firmware updates to support it. TCG specifications have all assets to implement 448 signing (I just checked).

#factcheck

@Foxboron @duxsco ok so does it have shorter bit length than 255bits?
Less bits => new signing algorithm ;-)

@duxsco It is pretty shameful that so common curve P256K1 is not already there.

I could be wrong but is P256K1 even used as part of #Estonia social security number blockchain? Maybe I could get a state level actor to help me to get that curve in :-)

I spent some time ago hours going through Est government pages looking for exact algorithms in their blockchains but all I could find was typical blockchain whitepaper/markerting crap, how great Estonia is and 200 years ahead rest of the world, and I like all that and admire but... ... ... could you also put the boring stuff i.e. ciphers used there ?

@duxsco

NOT true. TPM_ECC_CURVE_448 exists in the TCG algorithm registry. Table 5.1 in this same specifications enumerates ECC curves supported by TPM firmware (or in the spec TCG “TPM 2.0 Library”) interface.

Sometimes features can even land through firmware updates. especially for fTPM’s in Intel, ARM (via SMC AMD CPU’s this is feasible approach.

I’ve been also started to lobby the idea of getting P256K1 to the registry based on principle of equally feasible playing field for established corporations and growth companies of variable side (aka startups):

1. Corporates need to have their NIST curves.
2. There’s a critical mass of blockchain associated startups, in varying levels. So to have working capitalism also “Bitcoin curve” should be there.

I’m going to also write P256K1 software primitives to Linux kernel to enable more secure options for managing that sort of assets.

I do it part of my role as Linux kernel key-ring co-maintainer. My job is to identity widely use key types, enable them and call it a day, i.e. create equal capitalist market place for every actor.

I would enable P256K1 even if I hated blockchains by guts because it is my freaking job :-) Liking and disliking about stuff is part of leisure time (or when getting drunk which is part of leisure time ;-)).

@duxsco

NOT true. TPM_ECC_CURVE_448 exists in the TCG algorithm registry. Table 5.1 in this same specifications enumerates ECC curves supported by TPM firmware (or in the spec TCG “TPM 2.0 Library”) interface.

Sometimes features can even land through firmware updates. especially for fTPM’s in Intel, ARM (via SMC AMD CPU’s this is feasible approach.

I’ve been also started to lobby the idea of getting P256K1 to the registry based on principle of equally feasible playing field for established corporations and growth companies of variable side (aka startups):

1. Corporates need to have their NIST curves.
2. There’s a critical mass of blockchain associated startups, in varying levels. So to have working capitalism also “Bitcoin curve” should be there.

I’m going to also write P256K1 software primitives to Linux kernel to enable more secure options for managing that sort of assets.

I do it part of my role as Linux kernel key-ring co-maintainer. My job is to identity widely use key types, enable them and call it a day, i.e. create equal capitalist market place for every actor.

I would enable P256K1 even if I hated blockchains by guts because it is my freaking job :-) Liking and disliking about stuff is part of leisure time (or when getting drunk which is part of leisure time ;-)).

@duxsco TPM2 does have already 25519 supported so it can communicate with SSH and PGP sheanigans quite nicely

@duxsco TPM2 is simple and standardized keystore/smartcard framework in this context and for cert-keys its non-mobility is an asset. For subkeys yubikey is super-convenient :-)

It is those overcomplex frameworks that Intel and IBM are pushing that make it look complex with their command arbitrators etc.

TPM2 itself is in principle same as Yubikey or #Nitrokey but with a standardized binary protocol and non-mobility ;-)

I started this weekend from scratch to do a completely new streamlined and dead simple tools for using the chip for fun and profit:

- https://crates.io/crates/tpm2_cli
- https://crates.io/crates/tpm2_call

I know what would work for user because I am a user as I need to test all the kernel patches with IBM/Intel crap... The first two commands are like top picks from my most hated list in the aforementioned stack done right :-)

If that gets accepted Ill aim for demo on this too 💣💣💣

100% guaranteed to be part of my presentation, if gets accepted to the kernel summit 😉

A use case for #OpenPGP #signing that would combine best of #Yubikey and a #TPM2 chip:

1. A/S/E subkeys inside Yubikey.
2. C (#certificate) key as TPM2 ASN.1 blob.

The C key can be tied a to single chip during its creation. If someone gets a copy it is useless without that exact chip.

For the sake of defense in depth, a maintainer would keep that exact blob still in USB stick.

This scheme would be pretty airtight as even certification creation while the machine is online, would have quite low risks. E.g. if the ASN.1 blob is stolen while online, the key is useless by itself.

So in the context of #Linux #kernel #PGP #maintainer #guide this would make the whole process way more relaxed and convenient with the help of TPM2 chip.

How we deal with subkeys that part is smooth but there's still room for improving The Maintainer Experience when dealing with your Certification key :-)

I will work on user space shenanigans for this maintainer flow upgrade after this patch set is finished: https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/T/#t. I.e. find good route for gnupg to access the TPM2 (RSA4096/Curve25519) key, which is imported OpenPGP cert key...

lnav is a terminal-based log file viewer (TUI) for #Linux, #FreeBSD, #macOS, and other #Unix like systems. It combines the functionality of tools like tail, grep, awk, sed, and cat into a single interface. It also allows you to run SQL queries against your log files to build reports and offers basic support for Linux containers like Docker. lnav – Awesome terminal log file viewer https://www.cyberciti.biz/open-source/lnav-linux-unix-ncurses-terminal-log-file-viewer/

My question would be this why you want to do anything to address the (context-dependent) conclusion that “Python is slow”? ;-)

How I would address [1] with any Python3 dot release would be:

1. LATENCY: Manual driver/controller in the app for gc.* for the sake of predictability in timing. Run it when your app is idling. Do not run it at the hot spots.
2. BANDWIDTH: Use a freaking C-library for the payload processing. By practical means all of them have Python bindings.

[1] https://thenewstack.io/why-python-is-so-slow-and-what-is-being-done-about-it/

#Python #Python3 #PyCon #performance #gc

@hunger There's some irony in this though.

I've been slandering Rust community for making forks of every possible thing but I do think I'm in different grounds here ;-)

But in this case I disagree with core ideas of the architecture, cannot do the tasks that I need to now as an end user, and I have my own code base starting from epoch.

So literally I will never get the tool that I need myself, if I do not create a competing platform. Now I got first essential pieces what I needed in 48h. Thus, I think I'm in legit grounds with this and doing the right thing.

@hunger And there’s one huge contradiction between how I see the stack should work in the user space and how TCG sees it.

I did not believe in TrouSerS and neither do I believe in TSS2. User space arbitrator is just a bad idea as far as I’m concerned. And tpm-rs crate’s docs already have hints that they want to do something similar at very least.

I think a single chip can at most exactly two tasks:

• Managing persistent and transient with /dev/tpm0
• Managing transient only bu per open file with /dev/tpmrm0.

Anything that tries to scale up from this with a crazy and complex daemon is just totally misguided in architecture [1]. Never try to scale anything beyond what it has capabilities for.

For multiplex, e.g. for guests or containers, a decent vTPM implementation (posssibly attestated by the hardware chip, and thus doing arbitration in different layer or by the means of SGX/TDX/SNP) would be so much better approach, despite having challenges of its own.

It is something that one can understand is within limits of scalability of a chip (literally I mean think of more complex task like primary key generation).

[1] https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/

I finally released b4-0.14.0 with some neat features. Read the announcement for details:

https://lore.kernel.org/tools/20240614-flashy-inquisitive-beaver-ddcfea@lemur/T/#u

@hunger I don't have as mature design as tpm-rs but I think my process is a winning horse. I.e. kernel standard way acting, no vision at all, or roadmap of any kind, just be a golfish and impact with the world where you use your tools.

@hunger I have also somewhat clear milestone deriving from a kernel patch set: https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/

For v8, one of the goals is to have the smoke testing transcripts described in tpm2-cli.

Main gist of upcoming changes for my crate are scoped in the this:

tpm2_createprimary --hierarchy o -G rsa2048 -c owner.txt
tpm2_evictcontrol -c owner.txt 0x81000001
openssl genrsa -out private.pem 2048
tpm2_import -C 0x81000001 -G rsa -i private.pem -u key.pub -r key.priv
tpm2_encodeobject -C 0x81000001 -u key.pub -r key.priv -o key.priv.pem
openssl asn1parse -inform pem -in key.priv.pem -noout -out key.priv.der

[and similar for ECDSA]

In my project tpm2_call has the protocol layer and zero OS specific shenangians, i.e. it is ultra-portable.

However, in tpm2-cli I can just add a command that does the equivalent flow using openssl and asn1 crates. Generally the winds and stream in this project go in a way that I let shit grow in tpm2-cli and abstract away stuff that is agnostic and mature enough to tpm2_call. This way abstraction formalize by evolution and stimulus and not by top-down design…