digitalbitbox/mcu

MCU code for the BitBox01 hardware wallet

The Bitbox01 is a hardware wallet that simplifies secure handling of crypto coins through storing private keys and signing transactions. The content of this repository is the bootloader and firmware used on the device. The BitBox01 is meant to be used primarily with the BitBox App, although third party integration is possible through the BitBox01 API.

The main functionality of the firmware is the following:

• Safely receive and send coins
• Back up the seed to a microSD card
• Generate a random seed from multiple strong sources of entropy
• Protect the seed from attackers
• Derive keys from the seed according to BIP39 and BIP32
• Return the extended public key for a keypath so that the app can find all unspent transaction outputs
• Second factor authentication (FIDO U2F compliant)

Building the code

All communication to the hardware wallet enters and exits a single gateway char *commander(const char *command) that receives an encrypted command and returns an encrypted reply. The communication protocol is described in the API. A Python script to interact with the device is in the py/ folder.

The code can be compiled and tested locally without the need for a device, e.g., tests/tests_api.c tests the full API. The tests_api.c code will also test a live device if one is plugged into a USB slot. This requires installation of the hidapi library for USB communication, a micro SD card in the device, and a number of touch button presses to permit erase and sign commands.

ECDSA signatures are performed with either the bitcoin core secp256k1 library or using a simplified version of the smaller micro ECC library, depending on a setting in the CMakeLists.txt file. Each library is resistant to known side channel attacks.

Build instructions

Dependencies:

• GNU ARM Embedded Toolchain
• HIDAPI (For live testing)
• cmake
• Doxygen (Optional, to generate source code documentation)
• Graphviz (Optional, to generate graphs for the Doxygen documentation)

Build:

git clone https://github.com/digitalbitbox/mcu && cd mcu
make test  #  or `make firmware` or `make bootloader`
make run-test

Load the firmware by the bootloader (requires a bootloader already on the device):

• If you used the device with the desktop app, your bootloader will be locked
  • Unlock it by sending the message = '{"bootloader":"unlock"}' command with send_command.py (see python API documentation)
  • Long touch the device when the LED turns on
  • You should receive a Reply: {"bootloader":"unlock"} reply
• Long touch the device after plugging in to enter the bootloader
• Flash the new firmware with ./load_firmware.py ../build/bin/firmware.bin debug from the py directory

Deterministic builds

See the releases page for instructions or to download deterministically built firmware.

Contributing

Please use the coding style set by AStyle version 3.0 (http://astyle.sourceforge.net/; also available from homebrew) with the following parameters:

astyle --style=kr --indent-switches --indent-labels --pad-oper --pad-header --align-pointer=name --add-braces --convert-tabs --max-code-length=90 --break-after-logical --suffix=none *.c *.h --recursive --exclude=src/yajl --exclude=src/secp256k1 --exclude=src/drivers --exclude=tests/hidapi | grep Formatted

Pull requests will automatically fail if the coding style is not met. For convenience, enable a Git hook to trigger the astyle styling whenever a git commit operation is performed. This is done by typing in the repository directory:

cd .git/hooks
ln -s ../../contrib/git/pre-commit

All commits must be signed with PGP. To set Git to auto-sign your commits:

git config --global user.signingkey YourGPGKeyID
git config --global commit.gpgsign true

The PGP public keys of the contributors can be found in contrib/contributors_gpg_keys. Please add your PGP key with your first pull request.

Reporting a Vulnerability

See our security policy.

mcu's Issues

Digital Bitbox fw 6.x fails to sign transactions with pubkeys on certain derivation paths. Multisig UTXOs unspendable

The most recent firmware update has caused havoc on BitBoxes used for multisig.

It's a particularly hairy issue as existing multisig UTXOs have become unspendable absent manually exporting a private key.

Full details are here: spesmilo/electrum#5275

Fully open source

Any plans to make the rest of the source code open source too?
E.g. the part it talks to the hardware.

Like Trezor has it: https://github.com/trezor/trezor-mcu

If the hardware files provided from the chip manufacturer aren't open source you might consider using libopencm3 (http://libopencm3.org/wiki/Main_Page) too.

The libopencm3 project (previously known as libopenstm32) aims to create a free/libre/open-source (LGPL v3, or later) firmware library for various ARM Cortex-M0(+)/M3/M4 microcontrollers, including ST STM32, Ti Tiva and Stellaris, NXP LPC 11xx, 13xx, 15xx, 17xx parts, Atmel SAM3, Energy Micro EFM32 and others.

https://opensource.com/business/15/7/why-open-hardware-winning

Tezos support

Support tezos

getting master xpub is not possible

Not sure if I'm doing it wrong. But it looks like that i can't retrieve the master key at 'm'.

  [DEBUG]  main: encrypting raw json: {"xpub" : "m"}
Sending command: 4oivxqirFxug4E9M7nxja7O7A3rP/WcX1NQJtpsGZhs=
try to read some bytes...
 OK, read 2048 bytes.
result: {
  "error": {
    "message": "Could not generate key.",
    "code": 251,
    "command": "xpub"
  }
}

tests_api seg fault

/home/lucas/.clion10/system/cmake/generated/36d6158c/36d6158c/Debug/tests/tests_api
Internal API Result:
tests_echo_2FA: OK
tests_aes_cbc: OK
Signal: SIGSEGV (Segmentation fault)
Process finished with exit code 0

System:

uname -a
Linux lucas_hp_9470m 4.1.4-1-ARCH #1 SMP PREEMPT Mon Aug 3 21:30:37 UTC 2015 x86_64 GNU/Linux

gcc --version
gcc (GCC) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

clang --version
clang version 3.6.2 (tags/RELEASE_362/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

This seg-fault only happens on gcc, not with clang.

Full cmake .. output with gcc: http://pastebin.com/raw.php?i=gGbUNf6H

It stops in tests_sign. My IDE says in commander.c line 917, but that line looks good to me.

No problems on Travis. There we have a older CMake and a older gcc.

Any ideas?

mcu part needs to call secp256k1_context_randomize() with 256bit entropy from ATAES132A

Upgraded to 6.03 Firmware / No signing in MEW

Using latest firmware (6.04) Bitbox consistently across latest MEW and legacy MEW reports failed signing.
In Chrome and Opera. Has this issue been identified?

allow `https://app.essentia.one` access to web usb iface

We are integrating different dapps and hardware wallets in our service. We have already integrated Trezor and Ledger Nano S as hardware wallets. And users ask to integrate Digital Bitbox.

Live-device unit tests for hijack api fail on OSX Catalina

Live unit tests (tests_api) work on the previous OSX High Sierra, and MEW works on OSX Catalina (using the hijack interface and Chrome browser). Therefore, it seems that something changed with how OSX Catalina is handling USB communication with the hidapi interface. Specifically, the live unit tests fail if there is an API call to the device that requires a user touch and the user does not immediately do a touch confirmation on the device.

Add Bitcore BTX

I want to add Bitcore BTX support to Bitbox Hardware Wallet
Whit steps are needed?

[lowprio] add error codes to json responses

As example, a user could retrieve { "input":{ "error": "Please set a password." } }. The only way of detecting if a new password needs to be set is by parsing the string. Not urgent, but it would be great if there where error codes.

AES timing attack countermeasure

I don't have a full understanding of this [1] and as far as i know symmetric encryption is not very vulnerable to timing attacks, though i think adding a constant time behavior would be a good countermeasure (example from a bitcoin-core PR [2]).

[1] http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
[2] https://github.com/bitcoin/bitcoin/pull/5949/files#diff-caa129d4183d0a0943a8b84710fd4427R1184

device:lock should not be possible if device is not seeded

device:info returns xpub

Not sure if we want that device:info returns the xpub. I think it would be better if we would response with seeded:true/false... It would allow bypassing of the xpub export verification... not bad, but let's discuss it.

Support for Cardano

Any news on when we can expect it?

Unable to load modified firmware to the device

Hi,
I made some changes to the firmware that I'd like to load to a device used for tests. I made some changes to commander.c and built the firmware.bin file as the readme suggested, not using vagrant.
After putting the device in bootloader mode, I tried loading the firmware using both apps dbb-app, dbb-cli, and the load_firware.py [sic :) ] script, but the process never succeeds.
In the gui, the error is Error while upgrading firmware. Please unplug and replug your Digital Bitbox.
In the cli, Firmware upgrade failed!
And using the python script, ERROR: invalid firmware signature
I also tried setting debug as the version in with using the python script, but that didn't work either.

Is there no way to load a self modified firmware to the dbb?

feature request: add `info` command

A good UX would require to show the user...

• ... if he has set a password
• ... version number of DBB
• ... personal name (to distinct between devices if he uses more than one)
• ... if he has seeded the DBB

To avoid a chain of initial commands (device:version,name, xpub [to check if wallet is seeded]) , it might help to have one getinfo (or just info) command that responses serval informations. Need to be specified in detail.

{"backup":"list"} use json array or remove whitespace

low prio
Currently the output looks like:

"autobackup_1.aes, autobackup_2.aes, autobackup_3.aes, autobackup_4.aes, autobackup_5.aes, autobackup_6.aes, autobackup_7.aes, autobackup_8.aes, autobackup_9.aes, autobackup_10.aes, new.file, "

I think its okay as a CSV, but should use , instead of , (no space after comma). Also the last comma should be removed if possible.

Otherwise use ["x", "y"].

add simulator build into travis file, example python script, and instructions to README

ref #253

sign: wrong JSON encoding

{ "touchbutton": "accept" , "sign": [{"sig":8784540a5e6f2cfdfe135f9aca673b205913ef5be75ff6a950474b897fb1d91843ef2f70594c8f9ff3e3146aa200f3c8051e75df77b6c599f27ae706fea46776, "pubkey":03cafb64f419309362bcd02035a509aebca3997e36dd009a1a010feb9b70723043}] }

The "sig" value should also be wrapped in ".

{"device" : "lock"} response `{"lock": true}` instead of `"locked"`)

Needs update of API documentation.
https://digitalbitbox.com/api.html

Consider adding a simulator

Please consider adding a Digital Bitbox simulator. It would allow for projects implementing support for the bitbox to have a way to run automated tests.

I don't think this would be very hard to do. The api tests already use the bitbox firmware as a library and can send commands and get responses back. A simulator would just need to wrap that library and just forward the data to and from the outside world to the library functions. It could have an external interface using a UDP socket.

sign/checkpub should use pubkeys

See counterpart: BitBoxSwiss/dbb-app#36

GPG sign git commits

Invalid JSON returned on DB_ERR_SD_OPEN_DIR

After https://github.com/digitalbitbox/mcu/blob/c8ea0e02135653ad0d7b11e096c36348a2d34947/src/sd.c#L565,

Those lines are missing:

utils_zero(files, sizeof(files));
return DBB_ERROR;

As a result, in that error case, the api call for {"backup":"list"} returns:

{"error":{"message":"Could not open the directory.","code":403,"command":"backup"},"backup":}

which is invalid json (no value for the backup key).

1. Add the lines to correctly return the error.
2. Somewhere in the json api there is a bug in that it produces invalid json, instead of adding a null or similar on an empty value (or the json api returned an error that was not checked). Fix if easy.

Update to 4.0.0 firmware locked out hidden wallet

Not sure if this best belongs here or in desktop app, but...

After updating firmware to 4.0.0, wallet will accept hidden wallet password and opens a wallet, but shows no history/no balance. This occurs with the new desktop app and the old one. Main wallet seems to be unaffected. All help appreciated.