You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
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:
trezor_masked_static_pubkey = X25519(SHA-256(trezor_static_pubkey || trezor_ephemeral_pubkey), trezor_static_pubkey)
.Pairing:
trezorlib
.Pairing credential:
cc: @matejcik
The text was updated successfully, but these errors were encountered: