Draft
Conversation
- Point device-protocol and python-keepkey submodules to upstream master (includes BIP-85, Solana, Tron, TON wire IDs and proto definitions) - Add nanopb .options files for Solana, Tron, TON (field size constraints) - Add Bip85Mnemonic.mnemonic max_size:241 to messages.options - Update lib/transport/CMakeLists.txt with new proto sources, options, headers, and protoc compilation commands - Fix CI: use pre-installed clang-format instead of apt-get install (eliminates 3-minute timeout on GitHub runners) - Update Zcash transparent branch ID from Sapling to NU6
BitHighlander
force-pushed
the
feat/tron-ton-support
branch
2 times, most recently
from
8b53910 to
1b50b34
Compare
TRON: secp256k1 + Keccak256 address derivation, SHA256 tx signing TON: Ed25519 address derivation with CRC16 + Base64url, Ed25519 tx signing Both use existing trezor-crypto primitives only.
- Fix bounceable flag no-op: use ternary (0x11 vs 0x51) instead of OR - Check ecdsa_uncompress_pubkey return value in tron_getAddress - Add BIP44 path validation: m/44'/195'/... for Tron, m/44'/607'/... for TON - Change signTx functions to return bool (was void, silent failures) - Check signTx return in FSM handlers, send proper failure on error Note: TON address derivation uses SHA-256(pubkey) which produces non-standard addresses. Standard TON addresses require SHA-256(StateInit cell) which includes wallet contract code — too large for firmware flash. This is a known limitation documented for future resolution.
ton_get_address() was computing sha256(pubkey) directly, which does not correspond to any deployable TON wallet contract. The correct TON v4r2 address is sha256(StateInit(code_cell, data_cell)) where the data cell contains seqno=0, walletId=698983191, and the ed25519 public key. The fix hardcodes the well-known v4r2 code cell hash and depth, computes the data cell representation hash from the public key, then derives the StateInit hash. This produces addresses compatible with the standard v4r2 wallet contract used by TonKeeper, MyTonWallet, and @ton/ton SDK.
BitHighlander
force-pushed
the
feat/tron-ton-support
branch
from
1b50b34 to
2bf5c47
Compare
BitHighlander
force-pushed
the
feat/tron-ton-support
branch
from
40ffd80 to
65b63f5
Compare
BitHighlander
added a commit
to BitHighlander/keepkey-firmware
that referenced
this pull request
Mar 18, 2026
Security improvement: firmware reconstructs protobuf from structured fields (TronTransferContract, TronTriggerSmartContract) and signs the reconstruction. Display shows verified data, not host-asserted strings. - Structured mode: host sends transfer/trigger_smart fields, firmware rebuilds raw_data protobuf, displays verified amount/address, signs - Legacy mode: raw_data field still works with explicit blind-sign warning - TRC-20 ABI decoding: recognizes transfer(address,uint256) selector - 12 hardcoded TRC-20 tokens (USDT, USDC, SUN, BTT, etc.) - Bounded protobuf serialization with capacity checks - Address validation BEFORE display (prevents confusion attacks) - C unit tests for address, TRC-20 decoding, formatting - Device-protocol updated with structured message definitions Based on upstream keepkey#387 (feat/tron-ton-support)
Merged
6 tasks
BitHighlander
added a commit
to BitHighlander/keepkey-firmware
that referenced
this pull request
Mar 18, 2026
TON uses Cell/BoC encoding which cannot be parsed on embedded devices. This commit adds the minimum viable clear-signing improvements: - Add ton_validateAddress(): Base64 URL-safe decode + CRC16-XMODEM checksum verification + tag byte validation. Destination address is now validated BEFORE being displayed to the user. - Add explicit "Blind Signature" warning on all TON signing paths. Users must acknowledge that TX details cannot be verified on-device. - Reject invalid destination addresses with FailureType_Failure_SyntaxError instead of showing unvalidated data. - C unit tests: address validation (NULL, wrong length, bad checksum, bad tag), round-trip generate+validate, amount formatting. Note: Full Cell reconstruction (reconstruct-then-sign) for TON is a future improvement. Cell/BoC bit-level encoding is too complex for this pass. The blind-sign warning makes the security model explicit. Based on upstream keepkey#387 (feat/tron-ton-support)
Merged
6 tasks
BitHighlander
added a commit
to BitHighlander/keepkey-firmware
that referenced
this pull request
Mar 18, 2026
TON uses Cell/BoC encoding which cannot be parsed on embedded devices. This commit adds the minimum viable clear-signing improvements: - Add ton_validateAddress(): Base64 URL-safe decode + CRC16-XMODEM checksum verification + tag byte validation. Destination address is now validated BEFORE being displayed to the user. - Add explicit "Blind Signature" warning on all TON signing paths. Users must acknowledge that TX details cannot be verified on-device. - Reject invalid destination addresses with FailureType_Failure_SyntaxError instead of showing unvalidated data. - C unit tests: address validation (NULL, wrong length, bad checksum, bad tag), round-trip generate+validate, amount formatting. Note: Full Cell reconstruction (reconstruct-then-sign) for TON is a future improvement. Cell/BoC bit-level encoding is too complex for this pass. The blind-sign warning makes the security model explicit. Based on upstream keepkey#387 (feat/tron-ton-support)
BitHighlander
added a commit
to BitHighlander/keepkey-firmware
that referenced
this pull request
Mar 18, 2026
Security improvement: firmware reconstructs protobuf from structured fields (TronTransferContract, TronTriggerSmartContract) and signs the reconstruction. Display shows verified data, not host-asserted strings. - Structured mode: host sends transfer/trigger_smart fields, firmware rebuilds raw_data protobuf, displays verified amount/address, signs - Legacy mode: raw_data field still works with explicit blind-sign warning - TRC-20 ABI decoding: recognizes transfer(address,uint256) selector - 12 hardcoded TRC-20 tokens (USDT, USDC, SUN, BTT, etc.) - Bounded protobuf serialization with capacity checks - Address validation BEFORE display (prevents confusion attacks) - C unit tests for address, TRC-20 decoding, formatting - Device-protocol updated with structured message definitions Based on upstream keepkey#387 (feat/tron-ton-support)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
TRON (TRX): Top-15 chain by market cap, widely used in Asia-Pacific markets. TRON uses secp256k1 (same curve as Bitcoin/Ethereum), making the cryptographic implementation straightforward. Users holding TRC-20 tokens (especially USDT-TRC20, the most-used stablecoin transfer rail) need hardware wallet support.
TON (The Open Network): Originally developed by Telegram, TON has grown to top-10 by active addresses. It uses Ed25519 (same as Solana/Nano) but has a unique address derivation scheme based on wallet contract StateInit hashing. Adding TON expands KeepKey into the Telegram ecosystem.
Changes
TRON (
tron.c,fsm_msg_tron.h):m/44'/195'/account'/change/index0x41prefix (T-address format)44'/195'prefixTronGetAddress(1400) →TronAddress(1401),TronSignTx(1402) →TronSignedTx(1403)TON (
ton.c,fsm_msg_ton.h):m/44'/607'/account'/change/indexSHA256(StateInit(v4r2_code_hash, data_cell(pubkey)))using hardcoded v4r2 wallet code cell hash (32 bytes), avoiding the need to store the full contract code on-device.44'/607'prefixTonGetAddress(1500) →TonAddress(1501),TonSignTx(1502) →TonSignedTx(1503)Code review fixes included:
0x11 | 0x11(no-op) tobounceable ? 0x11 : 0x51tron_signTx/ton_signTxreturnboolfor proper error propagationTonAddressresponse includes both user-friendly and raw formatRisk assessment
Both chains are isolated in new source files with no modifications to existing signing paths. TRON reuses the existing secp256k1/ECDSA stack. TON reuses the existing Ed25519 stack. The v4r2 address derivation uses a hardcoded 32-byte hash constant — if the v4r2 contract standard changes (unlikely, it's been stable since 2022), the constant would need updating, but the address would simply not match any deployed contract (fail-safe, not fail-dangerous).
Testing