feat(ton): address validation and explicit blind-sign warning#57
Merged
BitHighlander merged 5 commits intodevelopfrom Mar 18, 2026
Merged
feat(ton): address validation and explicit blind-sign warning#57BitHighlander merged 5 commits intodevelopfrom
BitHighlander merged 5 commits intodevelopfrom
Conversation
7 tasks
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.
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)
- Validate to_address CRC16 even when amount is not provided. Previously validation was gated by (has_to_address && has_amount), so a malformed address without amount would reach signing unchecked. - Restrict workchain to 0 (basechain) or -1 (masterchain) in both GetAddress and SignTx handlers. ton_get_address truncates workchain to uint8 for the user-friendly address but prints the full sint32 in raw_address — out-of-range inputs would produce inconsistent addresses.
BitHighlander
force-pushed
the
feature/ton-clear-signing
branch
from
fc3de78 to
ef79baf
Compare
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.
Summary
ton_validateAddress(): Base64 URL-safe decode + CRC16-XMODEM checksum + tag byte validationSecurity context
TON uses Cell/BoC encoding which cannot be parsed on embedded devices. PR #52 identified this as a HIGH finding — the device was displaying host-supplied
to_address/amountas if verified, with no warning that the signedraw_txCell could contain different data.This PR adds:
Full Cell reconstruction (reconstruct-then-sign, matching what TRON does) is a future improvement tracked separately.
Base
Built on top of upstream keepkey#387 (feat/tron-ton-support)
Test plan