trezor/trezor-firmware

:lock: Trezor Firmware Monorepo

Trezor Firmware

Repository Structure

• ci: Gitlab CI configuration files
• common/defs: JSON coin definitions and support tables
• common/protob: Common protobuf definitions for the Trezor protocol
• common/tools: Tools for managing coin definitions and related data
• core: Trezor Core, firmware implementation for Trezor T
• crypto: Stand-alone cryptography library used by both Trezor Core and the Trezor One firmware
• docs: Assorted documentation
• legacy: Trezor One firmware implementation
• python: Python client library and the trezorctl command
• storage: NORCOW storage implementation used by both Trezor Core and the Trezor One firmware
• tests: Firmware unit test suite
• tools: Miscellaneous build and helper scripts
• vendor: Submodules for external dependencies

Contribute

See CONTRIBUTING.md.

Using Conventional Commits is strongly recommended and might be enforced in future.

Also please have a look at the docs, either in the docs folder or at docs.trezor.io before contributing. The misc chapter should be read in particular because it contains some useful assorted knowledge.

Security vulnerability disclosure

Please report suspected security vulnerabilities in private to [email protected], also see the disclosure section on the Trezor.io website. Please do NOT create publicly viewable issues for suspected security vulnerabilities.

Documentation

See the docs folder or visit docs.trezor.io.

trezor-firmware's Issues

add support for PSBT (BIP-174)

Create testing framework for UI

We'd like to have a framework for testing the user interface.

It should be able to output the scene in two different formats:

a) high-level: list of rendered elements with its internal states (position, color, innerText, etc.)
b) low-level: raw pixel data currently in the framebuffer

Add validation tests for protobuf definitions

We should validate our protobuf definitons meet the following criteria:

• no required fields are used, only optional (this needs to be addressed first)
• only supported data types are used (uint32 uint64 sint32 sint64 bool string bytes)
• etc.

We can write a quick hack in bash, but I guess it's better to use python-protobuf to perform better checks.

Implement Shamir secret sharing SLIP-0039

Allow creating recovery seeds using Shamir secret sharing, and allow device recovery from such seeds.

https://github.com/satoshilabs/slips/blob/master/slip-0039.md

Document trezorlib API

Feature request: It would be nice to have the trezorlib API docs available via readthedocs.org or a similar service.

ed25519-donna refactoring

It's pain to write code using ed25519-donna since:

• It's a one-purpose library aiming only at signing, verifying and performing Diffie-Hellman key exchange.
• It has almost no abstraction for other functions (especially for private and public key operations).
• It uses several number and point representations.
• It's badly documented. In particular, it's not clear what representations of inputs and outputs of functions are used.
• It's difficult to review any code using the library.

I suggest creating a well-documented abstraction for private and public key operations.

Separate ButtonRequests in device

We have 2 step verifying in this section(screenshot). First one is an address, second one is a message. We want to know which one is verifying. Currently both responses have "ButtonRequest_Other".

Redesign Passphrase

Make the workflow same for client for both non-passphrase device and passphrase device. Currently, client receives state only when passphrase is enabled.

Support air-gapped tx signing over sd-card

Trezor will read unsigned transaction template from sd-card, let user confirm the transaction on the display and put signed transaction back to the card. This will let people use trezor in completely air-gapped environment as powering the device through power bank is enough.

Display dry run result on device display

The device responds with a success or failure message after a recovery_device with dry_run: true is completed. It would be nice if it also displayed the result of the dry run on display.

This is mostly for consistency with T1 and web wallet. The risks of not displaying the result on device are minimal, since modifying it doesn't really benefit potential attacker.

[meta] Future improvements of the boot process

This is an issue to discuss future improvements of the boot process.

• update the firmware so it works with the original VTOR table from the bootloader
• update the firmware so it works in unprivileged mode, most probably enabling the supervisor calls will do the trick: trezor/trezor-mcu#323
• create a mechanism so SIGNED firmware can indicate the bootloader it needs to use its own VTOR table and/or it needs privileged mode

Bootloader: make install progress circle more smooth

Currently, the first quarter is the erasure of the blocks. The last three quarters are firmware blocks being loaded.

We can do two optimizations:

a) 16 KiB block is erased 8x faster than 128 KiB block, let's take this into the account

b) if the upload firmware is small, the second part of the process is much shorter than the erasure of all blocks

This is just a nit-pick, so I am not assigning a particular milestone.

Add type annotations using MyPy

http://mypy-lang.org/

See https://mypy.readthedocs.io/en/latest/python2.html for Py2 syntax.

diceware/cointoss initialization

T2 has display so we can show head/tails or 1-2-3-4-5-6 user interface for cointoss/diceware initialization to generate user entropy.

Bootloader: too aggressive communication checks

FATAL ERROR:
expr: sectrue * (r == USB_PACKET_SIZE)
file: embed/bootloader/messages.c:182
func: _usb_read
rev: 4ad6a7a

If USB communication is disrupted from the host side, this fatal error is shown.

We can probably make the checks less strict, but TBH I like how strict they are.

This error is not malign and user can restart the firmware update process.

macOS: disable CONFIDENTIAL='__attribute__((section("confidential")))' on emulator build

on macOS build, CONFIDENTIAL='__attribute__((section("confidential")))' does not work and causes error

error: argument to 'section' attribute is not valid for this target: mach-o section specifier requires a segment and section separated by a comma static CONFIDENTIAL HDNode node; ^ <command line>:2:45: note: expanded from here #define CONFIDENTIAL __attribute__((section("confidential")))

I solved it locally by changing the line in Makefile.include to -DCONFIDENTIAL=''; not sure what is the Right Way here

[Epic] Port Core codebase to Trezor One hardware

• HAL
  • display
  • touch
  • usb
• modules
  • modtrezorconfig
  • modtrezorcrypto
  • modtrezorio
  • modtrezorui
  • modtrezorutils
• boardloader/bootloader
  • Modify T1 bootloader to run both Core and Legacy #1045
• #1865
• Hardware optimalization

Dry-run recovery should display words on screen

Dry-run recovery should display words on screen to prevent malware lying to device about used words.

macOS `stat` does not support `-c` option

macOS stat does not support -c option, as that is GNU extension and not unix standard (macOS uses BSD version of stat).

macOS users need to do the following:

• brew install coreutils
• edit build.sh and rewrite stat to gstat

Redesign USB protocol (encryption + sessions)

Since TREZOR 2 will include a new USB protocol, we could add session encryption. This could either be optional or it could be required for the v2 protocol.

We could use ECDH to generate an ephemeral session key and display it on both the TREZOR and the computer. It could be encoded with the BIP39 word list to make it easier for the user to compare.

One reason to include this is that it would make use with Qubes OS more secure, where the USB qube can currently MITM communication with the hardware wallet.

Confidential Assets tracking issue

It would be great to have support for Confidental Assets (CA), which is used in the Elements blockchain platform and in Liquid, the commercial sidechain based on Elements. I'm happy to help move this forward, and am available by email at apoelstra at blockstream.com for any clarification or guidance.

CA is described in this blog post: https://blockstream.com/2017/04/03/blockstream-releases-elements-confidential-assets.html
It is essentially the same as Confidential Transactions, which involves the use of Pedersen commitments in place of amounts, alongside rangeproofs, which I believe is already supported as part of Trezor's Monero support. CA mades one of the two EC generators variable and adds a new "asset surjection proof" which is described here: https://github.com/ElementsProject/secp256k1-zkp/blob/secp256k1-zkp/src/modules/surjection/surjection.md

We've implemented CA in full as part of libsecp256k1-zkp, our fork of the Bitcoin Core libsecp256k1 library.

For referenc, the API for making surjection proofs is here: https://github.com/ElementsProject/secp256k1-zkp/blob/secp256k1-zkp/include/secp256k1_surjectionproof.h
and the core crypto functionality is here:
https://github.com/ElementsProject/secp256k1-zkp/blob/secp256k1-zkp/src/modules/surjection/main_impl.h
https://github.com/ElementsProject/secp256k1-zkp/blob/secp256k1-zkp/src/modules/surjection/surjection_impl.h

Cheers

boardloader-bootloader-firmware reverse crosscheck

T1 firmware checks bootloader hash against the known whitelist, see https://github.com/trezor/trezor-mcu/blob/9afaeff36ff891ab9dbe48b0f514a273975f8cd0/firmware/bl_check.c#L29-L46

Maybe we should do the same for T2, that is:

• bootloader checks the boardloader hash against the whitelist
• firmware checks the bootloader hash against the whitelist

Emphasize coin in each screen

Rethink passphrase protobuf workflow

Currently, Trezor Wallet uses GetPublicKey with an address m/1/0/0 to find out the state of the device. In other words to find out if Trezor is unlocked or if PIN/passphrase needs to be entered.

This is a little bit hackish and in a slight conflict with #326. There are three proposed solutions:

a) declare m/1/0/0 as a valid path
b) use m/44'/1'/0' which is a testnet path for every coin and therefore should be valid every time
c) add a new protobuf message GetState or similar

Race condition when signing NEM transactions on emulator with DebugLink

I managed to reproduce this race condition approximately 6 times out of total 10 runs.

I'm using connect together with an emulator. The emulator is loaded with DebugLink.
Transport is started with both the emulator and DebugLink support - ./trezord-go -e 21324 -e 21325.

Once the emulator is ready and the device__connect event is received nemSignTransaction method is called via connect with the following payload

{
    timeStamp: 1,
    fee: 2000000,
    type: 4100,
    deadline: 74735615,
    otherTrans: {
        timeStamp: 2,
        amount: 2000000,
        fee: 15000,
        recipient: 'TALICE2GMA34CXHD7XLJQ536NM5UNKQHTORNNT2J',
        type: 257,
        deadline: 67890,
        message: {
            payload: '746573745f6e656d5f7472616e73616374696f6e5f7472616e73666572',
            type: 1,
        },
        version: -1744830464,
        signer: 'c5f54ba980fcbb657dbaaa42700539b207873e134d2375efeab5f1ab52f87844',
    },
    version: -1744830464,
}

After last confirmation button is pressed emualtor returns 'Failure_Firmware'.
This is output from the emulator

Traceback (most recent call last):
 	 File "/trezor-core/src/trezor/wire/__init__.py", line 120, in session_handler
	 File "/trezor-core/src/trezor/wire/__init__.py", line 117, in session_handler
	 File "/trezor-core/src/trezor/wire/__init__.py", line 153, in protobuf_workflow
	 File "/trezor-core/src/trezor/wire/__init__.py", line 153, in protobuf_workflow
	 File "/trezor-core/src/trezor/wire/__init__.py", line 142, in protobuf_workflow
	 File "/trezor-core/src/apps/nem/signing.py", line 32, in sign_tx
	 File "/trezor-core/src/apps/nem/multisig/__init__.py", line 26, in aggregate_modification

Similar issues happens when calling nemSignTransaction with the following payload

{
    timeStamp: 74649215,
    fee: 2000000,
    type: 16386,
    deadline: 74735615,
    message: {},
    mosaicId: {
        namespaceId: 'hellom',
        name: 'Hello mosaic',
    },
    supplyType: 1,
    delta: 1,
    version: -1744830464,
    creationFeeSink: 'TALICE2GMA34CXHD7XLJQ536NM5UNKQHTORNNT2J',
    creationFee: 1500,
}

Results in

Traceback (most recent call last):
    File "/trezor-core/src/trezor/wire/__init__.py", line 120, in session_handler
    File "/trezor-core/src/trezor/wire/__init__.py", line 117, in session_handler
    File "/trezor-core/src/trezor/wire/__init__.py", line 153, in protobuf_workflow
    File "/trezor-core/src/trezor/wire/__init__.py", line 153, in protobuf_workflow
    File "/trezor-core/src/trezor/wire/__init__.py", line 142, in protobuf_workflow
    File "/trezor-core/src/apps/nem/signing.py", line 30, in sign_tx
    File "/trezor-core/src/apps/nem/mosaic/__init__.py", line 15, in supply_change

However it seems that this race condition doesn't happen when transport is started without DebugLink support - ./trezord-go -e 21325

power subsystem

This is for tracking hardware/software issues related to the power subsystem.

• bug: Insertion of microSD card while device is powered on causes a power fault. Add decoupling capacitors near the microSD pins and/or add more advanced power switching and in-rush current protection.

• potential bug: Verify that all hardware design manual recommended capacitors for the STM32F427VIT6 are included. Reference RM0090 Figure 10. "Power supply overview for STM32F42xxx" and AN4488 section 2.2.

• potential upgrade: Implement the power supply to target 3.3V in the operating range 2.7V - 3.6V for MCU and microSD and max 3.3V for display and touch panel. This would stay farther away from the operating limits, allow targeting PVD level 7, and keep the USB interface out of degraded operation.

• potential upgrade: Add MCU controlled switch to allow control of LCD + ST7789V power. Potential benefits are control of display module startup sequence and startup screen flash/flicker.

• potential upgrade: Add MCU controlled switch to allow control of CTPM + FT6236 power.

• potential upgrade: Add MCU controlled switch to allow control of microSD power.

Helpful Information:

• STM32F427 datasheet: Table 18. Limitations depending on the operating power supply range

• RM0090: sections 3.5, 3.6.2

• AN4488: sections 8.1, 3.2.2, 3.2.3, etc...

• AN1709: section 3.1 on BOR and PVD

• AN3430: section 2.1.3

Code areas that are tightly coupled to the power subsystem:

• PVD (programmable voltage detector + interrupt), see lowlevel.c

• BOR (brown out reset flash option byte), see lowlevel.c

• reset flag checking, see reset_flags_init in lowlevel.c

• SystemInit clock and flash wait state configuration, and SystemCoreClock CMSIS variable, see stm32.c

• INSTRUCTION_CACHE_ENABLE and PREFETCH_ENABLE, see stm32f4xx_hal_conf.h. Related impacts on SDIO functionality, see: trezor/trezor-core#81

Related prior discussion:

• trezor/trezor-core#75

• trezor/trezor-core@a08f18c

• trezor/trezor-core@6ea9b10

Peripheral operating voltage ranges (min, target, max):

• ST7789V (display driver)
  VDDI: 1.65, 1.8, 3.3
  VDD : 2.4, 2.75, 3.3

• FT6236 (touch panel driver)
  VDDA, VDD3: 2.8, - , 3.3

• USB
  VDD: 3.0, -, 3.6
  datasheet: "The voltage range for USB full speed PHYs can drop down to 2.7 V. However the electrical characteristics of D- and D+ pins will be degraded between 2.7 and 3 V"

• microSD
  VDD: 2.7, - , 3.6

Strange font spacing

There is some strange spacing behind letters, for example small 'r' and large 'T'

install: cannot stat '/src/build/firmware/firmware/trezor-emulator.bin'

Trezor emulator build (build.sh EMU) throws this

install: cannot stat '/src/build/firmware/firmware/trezor-emulator.bin'

Not sure if related to https://github.com/trezor/trezor-mcu/issues/423 ; I am building on macOS

Support for Erase PIN

Allow setting of special PIN, which will immediately erase Trezor storage, ideally returning device to factory defaults.

Expected changes:
a) New enum PinType with choices STANDARD, ERASE
b) New flag 'type' in ChangePin, using PinType
c) Check in ChangePin, that both PINs are different
d) In Pin dialog in boot time, if entered PIN == Erase PIN, drop device's storage

There are various use cases for such feature, including tricks like hand-writen PIN nearby Trezor, so random thief will erase the device himself.

Validate BIP32 paths according to BIP44, etc.

trezor/trezor-core#326
I believe this should be fixed for Trezor 1 as well.

multi-vendor firmware vulnerability brainstorming

This issue is to brainstorm possible vulnerabilities of the multi-vendor firmware concept with the goal of determining if there are countermeasures that can/should be added to the boardloader.

Basically, I was wondering if there are non-volatile storage areas within any part of the system that a malicious firmware could alter that would affect a subsequent non-malicious firmware? Are there more areas that the boardloader should wipe or check for badness?

For example, could a bad firmware leave a nugget it in the display driver IC that would replace displayed addresses, or change SRAM at runtime etc... Specifically, I have NOT found such a vulnerability, but I also don't know the very detailed specifics of the ICs used (the datasheets are not that complete). From what I can tell, the display driver only has 30-bits of NVRAM that is not that interesting.

One potentially interesting area is the FT6236. It contains a 16-bit MCU with a 32KB flash and 4KB SRAM. If that is programmable and has useful bus connections it could be troublesome. This tangents with hardware implants, but those are out of scope for this issue.

firmware: Simple on-device management

Allow device management directly from simple menu accessible from homescreen app.

Features:

1. Create new wallet if device is not initialized
2. Recovery from seed backup if device is not initialized
3. Set/change PIN
4. Wipe device
5. Access to air-gapped signing #72

Configurable auto-lock feature

Trezor One have constant-time timeout for locking device, which may be too long for some and frustrating for heavy users who works in trusted environment.

Model T does not have auto-locking yet. Let's make the timeout configurable over ApplySettings() with the possibility to turn the feature off completely.

Also, the wake event should be a human interaction (touch event), not wire communication, to protect device from misbehaving app on desktop.

Add option to indicate passphraseless mode in Initialize message

Pin entry: Auto-confirm PIN after delay.

It would be amazing to do not need to press "confirm" button in PIN entry. The dialog would just auto-confirm after (one, two sec?) delay with no button press. That would save 20% of clicks for 4-digit PIN.

Displaying fingerprint while FW update

Allow displaying firmware fingerprint in FW update process.

Currently, it is not a big issue as an user can display fingerprint of installed firmware even before he runs that firmware (by clicking to "i" icon in bootloader screen "Connect to host"), but it would be much more intuitive and easier to understand if they'd have a chance to check before the installation itself.

Simplify, document and de-duplicate code in Bitcoin signing

Revisit coins UI

The UI needs a complete revisit and unification of all coins. Each coin now does it a bit differently, which lowers the user experience.

Besides this, this issue also sets out to collect all minor tasks that we need to look into:

• Cardano uses pagination for every screen and it is not needed
• Cardano does not have hold to confirm
  - [ ] rethink if hold to confirm is a good idea, because it does not have a cancel button (or simply add a cancel button?) done in #76
• GetAddress dialogs show paths, we should show coin name, qualified paths (e.g. Bitcoin Segwit Account #3 Address #132) and show raw paths only for unrecognized paths
• Show qualified paths in SignTx output dialogs
• Show full addresses everywhere (e.g. Stellar truncates them #107)
  - [ ] Popup is used just once - do we need it? moved to #549

bootloader: Upload firmware over SD card

Allow updating of both bootloader and firmware over SD card. Currently, only bootloader can be updated this way.

add the option to cancel Wipe and SignTx button requests on device display

After user initiates a wipe or signtx action, they may change their mind and decide to cancel it. However, a cancel button is not displayed anywhere on the device and unplugging the device to cancel the request is inconvenient.

Once a button request is initiated, it is a convention for the web wallet to display a blocking modal that doesn't allow user to navigate elsewhere and doesn't close until the action is finished or cancelled on device. There are ways to close this modal and cancel the action from the web app but they are hacky and go against UX consistency.

Better display ethereum function calls

Currently when calling ethereum functions you only see the raw hex data - also often you do not see all of it as the hex gets long fast and I was not able to scroll.
The hex can be easily made shorter and more digestible by humans by resolving the function from the 4byte signature - e.g. via https://github.com/ethereum-lists/4bytes and then displaying the function name with parameters. So a really long hex string that might not fit on the trezor and is hard to parse by a human can easily fit on the display of the trezor and better digested by humans.
A problem might be the size of the signature database - I see 2 solutions here:

• leverage the SD-Card
• reduce the database to commonly used signatures only - we can parse all transactions currently done on chain - sort the 4bytes by usage and define a cut-off point

Support 'EXTERNAL' for TransactionInput.ScriptType

The firmware doesn't appear to support 'EXTERNAL' for TransactionInput.ScriptType, which is essential for coinjoins. I'm trying to build a simple bip79 front-end for trezor, but this appears to make it impossible.

Comment from issue: trezor/connect#247

prusnak wrote:

If you want to try implementing it, you should add another case when txi.script_type == InputScriptType.EXTERNAL here:
https://github.com/trezor/trezor-core/blob/b9926a9fffe8a593beb3adb79e5fc429233e41a3/src/apps/wallet/sign_tx/signing.py#L148

Investigate upgrading to Protobuf v3

https://developers.google.com/protocol-buffers/docs/proto3

The only possible problem now seems to be the default values. Cases where the explicit (v2) default value does not match the implicit (zero) values from v3:

https://github.com/trezor/trezor-common/blob/7d618036ab50504e245ad8651c4558d413596228/protob/messages-bitcoin.proto#L128

• Is version == 0 a valid value?

https://github.com/trezor/trezor-common/blob/7d618036ab50504e245ad8651c4558d413596228/protob/messages-bitcoin.proto#L207

• Is sequence == 0 a value value?

If we decide we need to keep the compatibility with v2, there is one trick we can use: https://stackoverflow.com/a/33204511

bootloader: Add "Wipe device" button

Allow to wipe device without connecting to the computer.

Related to #62, where USB is disabled in bootloader, and complement to on-device management #61 in cases PIN is not known.

sdcard: disable card detect pull-up resistor in card with ACMD42

Pin 2 of the microSD socket is CD/DAT3 (MCU pin PC11).
When the microSD card gets powered-on, it enables a pull-up resistor internal to the card on CD/DAT3.
This acts as a card detect pin since the card starts up in 1-bit mode and thus DAT3 is unused for data transfer at that time.
Later we change to use a 4-bit data bus, but don't disable the card's internal card detect pull-up resistor with ACMD42.
We should probably do that just to be safe before switching to 4-bit mode at https://github.com/trezor/trezor-core/blob/cb9e7b5885a47f900c24153e22e4f93b39cbb792/embed/trezorhal/sdcard.c#L149

vendor/micropython/lib/stm32lib/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_sdmmc.c is useful for seeing how the HAL does its work.

Here's some more example code:
https://github.com/LonelyWolf/stm32/blob/master/cube-usb-msc/sdcard-sdio.c

Will probably end up with something functionally similar to this, but need to factor code, etc...

    // disable the card's internal CD/DAT3 card detect pull-up resistor
    // to send ACMD42, we have to send CMD55 (APP_CMD) with with the card's RCA as the argument followed by CMD42 (SET_CLR_CARD_DETECT)
    if(SDMMC_CmdAppCommand(sd_handle.Instance, (uint32_t)(sd_handle.SdCard.RelCardAdd << 16U)) != SDMMC_ERROR_NONE) {
    	goto error;
    }
    SDIO_CmdInitTypeDef  sdmmc_cmdinit;
    sdmmc_cmdinit.Argument         = 0U; // disable card detect resistor
    sdmmc_cmdinit.CmdIndex         = SDMMC_CMD_SD_APP_SET_CLR_CARD_DETECT;
    sdmmc_cmdinit.Response         = SDIO_RESPONSE_SHORT;
    sdmmc_cmdinit.WaitForInterrupt = SDIO_WAIT_NO;
    sdmmc_cmdinit.CPSM             = SDIO_CPSM_ENABLE;
    SDIO_SendCommand(sd_handle.Instance, &sdmmc_cmdinit);

    if (SDMMC_GetCmdResp1(sd_handle.Instance, SDMMC_CMD_SD_APP_SET_CLR_CARD_DETECT, SDIO_CMDTIMEOUT) != SDMMC_ERROR_NONE) {
    	goto error;
    }

Reference:

http://envoydatamemory.com/datasheets/EN-L0J%20Industrial%20microSD%20Card%20Spec%20Rev1.6.pdf

https://www.kingston.com/datasheets/SDCIT-specsheet-8gb-32gb_en.pdf

trezor/trezor-core#279 (comment)

Enable derivation paths checks for GetPublicKey

When trezor/trezor.js#73 is fixed enable paths checks for GetPublicKey.

bootloader: jump_to_firmware can lead to undefined behavior

currently the jump_to_firmware function can lead to undefined behavior if an exception is taken after SCB_VTOR is set and before the firmware's reset_handler has completed. what i mean is that the firmware exception handlers are written in C and the sections that get initialized in SRAM are put there by the reset_handler. this is an informational issue right now because i don't see this being exploitable with the firmware's current set of exception handlers. the model t already considered this possibility and handles it differently.

to see this in action in a dev board, set a break point at https://github.com/trezor/trezor-mcu/blob/master/util.h#L65 and touch the reset pin on your board to cause clock instability which will trigger the nmi_handler for the clock security system. since the firmware's vectors are now in use, when you step in the debugger, you'll be transported to the exception handler at the firmware's flash memory address. thus, we're running firmware code before completing the bootloader and the subsequent firmware initialization.

EDIT: adding a note that the model t also clears out the registers just in-case anything sensitive was in them. reference https://github.com/trezor/trezor-core/blob/master/embed/trezorhal/util.s

trezorctl: common exception handling

Currently, every command has to handle its own exceptions. So most canceled actions throw a stack trace, unless specifically coded against.

That is stupid.

We should have a common exception handler for the subcommands and output nice messages whenever it makes sense.

Also maybe stop for a minute and rethink raising exceptions when an action is canceled?

Return better info than FirmwareError when a ValueError is thrown

Currently trezor-core returns Firmware Error, for example when modtrezorcrypto raises a ValueError. In some cases we want this to propagate into a wire.ProcessError, however not each time.

This should be investigated further to figure out how we want to approach this and make it somewhat compatible with trezor-mcu.

bootloader: Add flag to FW header for disabling "Connect to host"

Add flag to firmware header for defining that bootloader should not enable USB stack and allow connecting to host.

Related to #64, will allow completely air-gapped configuration, with disabled USB in bootloader and firmware.