Hello Trezor Team and community,
I am a prospective Trezor user from France, and I have been thinking about an additional security layer that could be valuable to Trezor users and potentially to the wider hardware-wallet ecosystem.
I would like to propose:
ITAKT — Independent Transaction Authorization Key Technology
ITAKT is a working name for the proposed security architecture, not a claim of an existing protocol or implementation.
## Core concept
The goal is not simply to add another form of 2FA.
The goal is to create an independent cryptographic authorization layer that makes possession of the Trezor alone insufficient to authorize a transaction.
A Trezor device could optionally be configured with one or more independent physical authorization keys.
For example:
Trezor Safe 7 = primary signing authority
Independent security key = transaction authorization authority
The desired security property would be:
Trezor alone → transaction cannot be signed
Authorization key alone → transaction cannot be signed
Trezor + valid authorization from the independent key → transaction can be signed
The external key would not contain the wallet seed and would not replace the Trezor’s private key. It would act as an independent “last lock” for transaction authorization.
## This should NOT be conventional 2FA
I do not mean:
“Website detects security key → server says OK → transaction proceeds.”
That would introduce another trusted intermediary.
Instead, the external key should produce a cryptographic authorization bound to the exact transaction the Trezor is being asked to sign.
The desired security property is:
“The Trezor must refuse to produce its transaction signature unless the independently held authorization key has cryptographically authorized the same transaction.”
## Transaction binding
The authorization should mean:
“I authorize this specific transaction.”
Where technically appropriate, it should be bound to parameters such as:
- source account
- destination
- asset
- amount
- nonce
- chain/network
- relevant signing payload
The Trezor should independently verify that the transaction it is being asked to sign corresponds to the transaction authorized by the external key.
This should prevent an attacker from obtaining authorization for one transaction and substituting another before signing.
## Human-verifiable authorization
Where technically possible, ITAKT should not merely authorize an opaque payload.
The user should ideally be able to understand what they are authorizing through human-verifiable transaction information before final authorization.
The exact interface would depend on the blockchain and transaction type.
## Replay and downgrade protection
ITAKT authorizations should be protected against replay. An authorization intended for one transaction should not be reusable for another transaction, account, chain, session, or signing context.
Once ITAKT is enabled, software should not be able to downgrade the device to a mode where external authorization is no longer required.
## Protection against a compromised host
A major purpose is to strengthen the security boundary against a fully compromised host.
For example:
Computer / browser / dApp
→ prepares transaction
Independent authorization key
→ authorizes the exact transaction
Trezor
→ independently verifies the authorization
Trezor
→ signs only if the authorization is valid
Compromising the host should therefore not by itself be sufficient to obtain a valid transaction signature.
## No trusted third party
This is fundamental.
The security policy should not depend on:
- a Trezor backend server;
- a centralized authorization database;
- a cloud service;
- an online API;
- a developer-controlled permission system;
- or another trusted intermediary.
The authorization should be cryptographically verifiable within the trusted security boundary.
The availability of a Trezor server should not determine whether a transaction is permitted.
## Protection of the security policy
Once ITAKT is enabled:
- adding an authorization key should require the existing security policy;
- removing a key should require the existing policy;
- changing the authorization threshold should require the existing policy;
- disabling ITAKT should require the existing policy.
There should be no hidden administrative mechanism allowing a developer, backend operator, or remote service to silently disable the protection.
## Multiple keys and recovery
ITAKT should ideally support multiple independent authorization keys.
For example, a 2-of-3 policy could use:
- primary authorization key;
- backup authorization key;
- securely stored recovery authorization key.
This would provide resilience against loss or destruction of one physical key without weakening the security model.
Recovery should be explicitly configured by the owner and governed by the same cryptographic principles. It should never become a hidden bypass controlled by Trezor or a third party.
## Hardware independence
I would suggest designing ITAKT as an open authorization protocol rather than making it dependent on one manufacturer.
Possible authorization devices could include:
- YubiKey / FIDO2-compatible security keys;
- another hardware security key;
- another dedicated authorization device;
- potentially another Trezor device in a future implementation.
The important property is that the authorization key is physically and cryptographically independent from the primary wallet signing key.
ITAKT could potentially evolve into an open standard rather than a proprietary Trezor-only mechanism.
## Two possible security layers
I believe there are two useful levels of implementation.
### Level 1 — Device-level Transaction Guard
The Trezor itself refuses to sign unless the external authorization is valid.
This could provide an additional security boundary across many different blockchain protocols.
### Level 2 — Cryptographically enforced account policy
For blockchains supporting appropriate account-abstraction, smart-account, multisignature, or equivalent mechanisms, the authorization requirement could also be enforced at the account/protocol level.
This would provide an even stronger property:
Even if the wallet seed were somehow compromised and reconstructed outside the Trezor, the attacker would still be unable to move funds without satisfying the second authorization requirement.
I believe both levels are worth investigating.
## Open-source and independently auditable
Because this mechanism would become part of the security boundary, the protocol and implementation should ideally be open to independent security research.
Researchers should be able to verify that:
1. external authorization is genuinely mandatory;
2. authorization is bound to the intended transaction;
3. there is no server-side bypass;
4. firmware cannot silently ignore the requirement;
5. recovery cannot bypass the protection;
6. configuration changes are protected;
7. no developer or administrator possesses a hidden override;
8. downgrade paths cannot silently disable the protection.
## Why this matters
Hardware wallets already provide an extremely strong security boundary.
However, the final signing authority remains concentrated in the hardware wallet.
An independent transaction authorization key would introduce another independent physical and cryptographic boundary.
The resulting model would be:
Possession of the Trezor is insufficient.
Possession of the authorization key is insufficient.
Both independent factors are required.
This could provide additional protection against sophisticated malware, compromised browsers, malicious dApps, supply-chain attacks, third-party integrations, compromised wallet interfaces, and other attacks targeting the transaction path.
It would also offer users holding substantial amounts of cryptocurrency a stronger security model than conventional 2FA without depending on a centralized service.
## Core security property
“A Trezor should optionally be able to cryptographically refuse to sign any transaction unless an independently held physical authorization key has first approved that exact transaction.”
No server.
No database.
No cloud authorization.
No developer override.
No software-only bypass.
The user’s cryptographic authorization policy should determine whether the transaction can be signed.
I am not claiming that I have determined the complete implementation or that this concept is necessarily novel or patentable.
I am proposing a security property and architecture that I believe deserves technical evaluation by Trezor’s security and engineering teams.
I would be very interested to know whether Trezor has already explored this concept internally, and if not, whether ITAKT could be considered for a future Trezor Safe firmware, protocol, or open standard.
ITAKT is ultimately about one simple principle:
“Ownership should require more than possession of a single device.”
Security is a shared responsibility. By working together, we can make self-custody safer for everyone.
Thank you for your work on hardware-wallet security and for maintaining a strong open-source and security-focused approach.
Best regards,
A prospective Trezor user from France