Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trezor: add support for a new Trezor-Host Protocol #775

Open
M1nd3r opened this issue Feb 14, 2025 · 2 comments
Open

Trezor: add support for a new Trezor-Host Protocol #775

M1nd3r opened this issue Feb 14, 2025 · 2 comments

Comments

@M1nd3r
Copy link

M1nd3r commented Feb 14, 2025

Rationale

New Trezor devices will use a new session-based Trezor-Host Protocol with encrypted channels. For HWI to support such devices, changes in trezorlib are necessary. Furthermore, to avoid a new handshake for each command, information about the connection needs to be temporarily stored (encryption and decryption keys, nonces, synchronization bits, channel id). Optionally, Trezor can issue a long-term pairing credential to avoid repeated pairing.

Brief description of the new protocol

Handshake, encryption:

  • Handshake is based on the XX handshake pattern as specified in Noise Protocol Framework. With a modification that instead of using Trezor's public static key directly, a masked key is used:
    trezor_masked_static_pubkey = X25519(SHA-256(trezor_static_pubkey || trezor_ephemeral_pubkey), trezor_static_pubkey).
  • Elliptic curve Curve25519, function X25519, and key pair generation are specified in RFC 7748.
  • Communication is encrypted using AES-GCM.

Pairing:

  • Newly, authentication of the host is mandatory. Trezor supports several pairing procedures.
  • The CodeEntry (user rewrites short code from Trezor's display to the host) is implemented in trezorlib.

Pairing credential:

  • After successful pairing/connection, the host can ask Trezor for a long-term pairing credential.
  • When the host presents with a valid pairing credential during the Handshake phase, the pairing is skipped.

cc: @matejcik

@matejcik
Copy link
Contributor

related: #326

back then the issue was that HWI does not want to expose "session management" functionality to callers -- even if we persist the above info on disk, every single user of HWI on the same system will live in the same session.

Also i'm not up-to-date on how HWI currently handles multiple concurrently open passphrases? I recall something like, you can specify passphrase argument on the command line and this is passed to the wallet; if you don't, AND passphrase on Trezor is enabled, HWI will invoke passphrase prompt on device.
Correct?

So if the caller app does nothing, Trezor will ask for passphrase on every HWI command, correct?
(the host is at least supposed to pass in a master fingerprint, so that HWI can tell whether the passphrase was correct)

I'm wondering whether something like fingerprint-to-session database would be appropriate, so that callers can enumerate the possible (open) passphrase wallets? But that may be problematic when the wallet is not "open" and so not enumerated?

@matejcik
Copy link
Contributor

To be clear: this issue is not about implementing THP in HWI directly, we're doing that in trezorlib ourselves.

This issue is about the HWI-side API and UX of pairing and of persisting sessions between command invocations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants