Code Monkey home page Code Monkey logo

jade's Introduction

Jade Firmware

NOTE: the below instructions are for Jade developers with access to Jade development boards or for those wanting to build and flash their own esp32 consumer devices - eg. M5Stack or TTGO T-Display boards. They are not for updating the firmware of an official Blockstream Jade hw unit - these can only be updated in-app, or using the 'update_jade_fw.py' script - see FWUPDATE.md

  • DO NOT ATTEMPT THE BELOW WITH BLOCKSTREAM OFFICIAL BLOCKSTREAM JADE HW UNITS

To build you can use the docker image (see Dockerfile) or install the esp-idf toolchain and repo following the commands in this readme.

DIY Hardware & Programming Notes

For information about suitable DIY hardware, as well as suggested configuration profiles and notes on secure boot. DIY Guide

Use docker

If you are on MacOS, you are better off setting up the environment locally (see next step) than trying to get access to your device from the docker container. For more, see this article.

Note the supplied docker-compose.yml assumes the Jade device is at dev/ttyUSB0.

Note the below instructions assume an original Jade v1.0 hardware with a true wheel. When using the later Jade v1.1 hw revision with a rocker/jog-wheel, use 'configs/sdkconfig_jade_v1_1.defaults' in place of 'configs/sdkconfig_jade.defaults'.

(local)$ docker-compose up -d
(local)$ docker-compose exec dev bash
(docker)$ cp configs/sdkconfig_jade.defaults sdkconfig.defaults
(docker)$ idf.py flash

The docker-compose.yml also mounts the local git repo so that it is the origin of the repo in the docker.

Set up the environment

Jade requires the esp-idf sdk.

More information is available in the Espressif official guide.

Get the esp-idf sdk and required tools:

mkdir ~/esp
cd ~/esp
git clone -b v5.1.4 --recursive https://github.com/espressif/esp-idf.git
cd ~/esp/esp-idf && git checkout d7b0a45ddbddbac53afb4fc28168f9f9259dbb79 && ./install.sh --enable-gdbgui esp32 esp32s3

Set up the environmental variables:

. $HOME/esp/esp-idf/export.sh

On MacOS: You will need cmake on your system for this step (brew install cmake).

If you encounter Python dependencies issue, make sure to use a recent Python version (e.g. Python 3.11) as the current system version which is used by the install script.

Build dependencies

Cmake is needed to build the firmware, you can install in on debian based distros with:

sudo apt install cmake

Serial port

In order to have permissions using serial port to load firmware, your user should be in dialout group on debian based distros, other distros can use a different group name, you can figure out by checking the group of the serial port 'file' using ls -l command:

(serial port is usually /dev/ttyACM0 or /dev/ttyUSB0)

$ ls -l /dev/ttyACM0                                                                                                                     14:37:07
crw-rw----+ 1 root dialout 166, 0 Apr 15 14:37 /dev/ttyACM0

You can check that dialout appear in your user groups by running:

$ groups
docker libvirt dialout storage kvm wheel plugdev

if not present you should add your user to the group:

sudo usermod -aG dialout $USER

(you should then login/logout or reboot)

Build the firmware

git clone --recursive https://github.com/Blockstream/Jade.git $HOME/jade
cd $HOME/jade
cp configs/sdkconfig_jade.defaults sdkconfig.defaults
idf.py flash monitor

Use a config file from the configs folder that is specific to your hardware (if available).

For example for the TTGO T-Display:

cp configs/sdkconfig_display_ttgo_tdisplay.defaults sdkconfig.defaults

If you flash multiple devices or make changes to the original config file that you used, make sure to delete the sdkconfig file that gets created from sdkconfig.defaults. Otherwise, your changes will not get picked up when building and re-flashing the firmware.

Some hardware configurations (eg: M5StickC-Plus) may not support the default baud rate and won't be detected, so you can force a specific baud rate for flash/monitor by using the -b argument.

For example, the last line of the above code block would change be:

idf.py -b 115200 flash monitor

Build configurations

There are various build configurations used by the CI in the configs/ directory, which may be required for specific builds eg. without BLE radio, with the screen enabled (or disabled, as with the CI tests), or for specific hardware (eg. the m5-fire).

The menuconfig tool can also be used to adjust the build settings.

idf.py menuconfig

Note: for any but the simplest CI-like build with no GUI, no camera, no user-interaction etc. it is recommended that PSRAM is available and enabled. ( Component Config -> ESP-32 specific -> Support external SPI connected RAM )

Run the tests

cd $HOME/jade
virtualenv -p python3 venv3
source venv3/bin/activate
pip install -r requirements.txt

python test_jade.py

deactivate

Emulator/Virtualizer (qemu in Docker)

The following will build a docker image running the headless ci-test (approves every request):

docker build -t jade-qemu-ci -f Dockerfile.qemu .
docker run --rm -p 30121:30121 -it jade-qemu-ci

The python 'jadepy' api can talk to it as if it were a serial interface, if given the device string 'tcp:localhost:30121'.

python -c "from jadepy.jade import JadeAPI; jade = JadeAPI.create_serial(device='tcp:localhost:30121'); jade.connect(); print(jade.get_version_info()); jade.disconnect()"

Similarly, for a manually driven web-enabled 'virtual jade' (at 'http://localhost:30122/'):

docker build -t jade-qemu-web -f Dockerfile.qemu --build-arg="SDK_CONFIG=configs/sdkconfig_qemu_psram_webdisplay.defaults" .
docker run --rm -p 30121:30121 -p 30122:30122 -it jade-qemu-web

For more 'hands-on' development with qemu, run these commands inside the jade source repo root directory, it will enter a docker container

DOCKER_BUILDKIT=1 docker build . -t testjadeqemu
docker run -v ${PWD}:/jade -p 30121:30121 -it testjadeqemu bash

Note: You can skip the build step if you want by fetching the prebuilt image and running with

docker pull blockstream/verde
docker run -v ${PWD}:/jade -p 30121:30121 -it blockstream/verde bash

Now inside the container

. /root/esp/esp-idf/export.sh
cd /jade
rm -fr sdkconfig
cp configs/sdkconfig_qemu.defaults sdkconfig.defaults
idf.py all
apt-get update -qq && apt-get install virtualenv -yqq
virtualenv -p python3 ./venv3
source ./venv3/bin/activate
pip install -r requirements.txt
./tools/fwprep.py build/jade.bin build
./main/qemu/make-flash-img.sh

# To run the CI tests
./main/qemu/qemu_ci_flash.sh

# To reboot the qemu instance
./main/qemu/qemu_reboot.sh

# To reboot the qemu instance and attach gdb to the Jade fw
./main/qemu/qemu_gdb.sh

At this point the Jade fw running in the qemu emulator should be available on 'tcp:localhost:30121' from inside and outside the docker container.

Reproducible Build

See REPRODUCIBLE.md for instructions on locally reproducing the official Blockstream Jade firmware images (minus the Blockstream signature block).

License

The collection is subject to gpl3 but individual source components can be used under their specific licenses.

jade's People

Contributors

3rditeration avatar akarve avatar deviavir avatar epiccurious avatar fametrano avatar greenaddress avatar jamiedriver avatar jgriffiths avatar jkauffman1 avatar leocomandini avatar moneymanolis avatar pythcoiner avatar rcasatta avatar tzapu avatar valerio-vaccaro avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

jade's Issues

Issue using personal blind oracle with webpage (emscripten esp32 bc-ur)

Hi,
I have a problem during the first setup of my personal webpage with Jade.
Here are the steps I've done to explain at my best:

  1. I set up my personal blind oracle and the esp32 webpage using emscripten.sh script;
  2. I've exposed both oracle and webpage with 2 different onion services, to reach them outside;
  3. I've done a factory reset of Jade and I've pointed it to my personal blind oracle's onion service (+port);
  4. All fine; Jade asked: "how do you want to connect?" I chose QR;
  5. I set up first my pin, repeat to confirm;
  6. I went to my onion webpage (qrpin.html) and I scanned the qr from my Jade;
  7. The webpage remained stuck ad "step 1 of 4" and did not reply with its qr code.

If I skip the 3rd step (not point to blind oracle, and using default server), all goes fine and I can use my webpage to unlock the Jade.
If I don't use the webpage, I can unlock Jade with my blind oracle with cable+companion and all works fine.

How do I fix that? Did I missed something?
Thanks in advance

Feature Request: Airgap functionality

Hi, I couldn't find any issues mentioning this, but am wondering if there is a roadmap for this. Bought multiple Jades for airgapped multi-sig based on this Blockstream blogpost:

https://blog.blockstream.com/en-secure-your-bitcoin-and-liquid-assets-with-blockstream-jade/
specifically this paragraph:

Where We’re Going, We Don’t Need Cables
Blockstream Jade also has a few “dormant” features that we’ll be activating through software updates over the course of 2021. Many bitcoiners (especially us!) are looking forward to the ability to properly airgap their hardware wallets. So we’ve equipped Blockstream Jade with an on-board camera.

Once activated, the camera will enable you to complete all incoming and outgoing transactions entirely through QR codes, ensuring that you don’t even need to connect your Blockstream Jade to your device through a cable.

Since 2021 is over, just wanted to see how this is going.

Thank you guys!

Compatibility of Jade with externally blinded txs on Liquid

It looks like Jade only can sign transactions that were blinded by Jade itself - values and assets are displayed correctly only if I pass commitments that contain hmac field received from Jade during blinding.

If I pass None for all commitments it displays garbage on screen and then throws an error:

JadeError: -32602 - Failed to verify asset_generator from commitments data

If I pass correct commitments but without hmac field - it throws a different error:

JadeError: -32602 - Failed to extract trusted commitments from parameters

This means that:

  1. It's not possible to use Jade in multisig unless Jade is creating the transactions (so 2 Jades will never be able to sign multisig transaction)
  2. It's not possible to use Jade for transactions containing outputs that are blinded by someone else (for example swaps, coinjoins or payjoins)

I suggest that you allow commitments that do not contain hmac field because HW still can verify correctness of asset commitment and value commitment just by running secp256k1_generator_generate_blinded and secp256k1_pedersen_commit.

Also would be nice if blinded outputs with unknown blinding factors are displayed as ??? for values and assets, not some random values.

Wallet loses Bluetooth connection.

When trying to receive payment across multiple bitcoin accounts Jade loses connection and I am unable to generate a new receive address. I have to force quit the blockstream green app and reconnect the Jade.

This general purpose hardware with wireless really needs an anti-phishing feature,

Seems like a big challenge without a secure element but I think it's sorely needed given how easy it is to build flash one with an evil firmware that's sending the ping over the local wifi.

The combination of the mobile device and the Jade could display something unique and memorable after pairing that someone stealing the device could not ever replicate.

Not possible to use Testnet or Liquid

After setting up the HW Wallet with a 24-seed, I tried to change the network in the Android Green Wallet App to Liquid (same with Testnet). Got the response from the app: "The network chosen in the Green App is not the same as the network chosen on the hardware wallet. Please choose same network on both devices".
Also, on the HW device, I did not find an option for changing the network.
So, it is effectively not possible to use Liquid or Testnet at the moment?

Allow Liquid Web Apps to integrate Jade

Is there a plan to support Web USB and/or Web Bluetooth protocols?

What

Allow browser apps to interact with Jade for doing various lifecycle activities, such get new addresses or signing PSBT/PSET?

Why

Especially on Liquid, a vibrant ecosystem of web apps that offers advanced use cases is growing

The only solution is using Marina Wallet, a browser extension at the moment, Although this makes a very nice UX on for desktop users, it degrades their security.

How

I know Jade is tightly coupled with GDK, but IMHO this may not be the best API and maybe will put too much pressure on the GDK team which could slow down this. What if we could offer a greenfield API, tailored to web/mobile apps developers?

Marina Web Provider could be a starting point for the discussion

https://docs.vulpem.com/marina/api

Feature request - Please add monochrome display option

There's no option to switch between monochrome or color display. I noticed after several wallets switched from monochrome to color display, it got way brighter and 'tough' on the eyes, especially if you need to do multiple transactions or use the wallet for extended periods of time. Monochrome would be helpful option to have.

Register CSV accounts on the Jade

It would be nice to be able to register CSV accounts on the Jade similar to the multisig implementation. If an account is registered with an xPub that isn't Blockstream's, a warning could be displayed during registration.

I think it would also be more secure because an attacker could pass a non-standard csv_blocks parameter, and ask for ransom (not sure if this would trigger a warning currently).

Left button for PIN entry not functioning on Windows USB for TTGO Jade wallet DIY

Description:
I would like to report a bug for the TTGO Jade wallet DIY. I have tested the wallet on USB on Windows, Linux, and Android. When I went to enter my PIN, the left button on the TTGO did not work on Windows, while the right button was functional. I have a video recording of the issue, which I can share with the developers. I consistently experienced this issue even after restarting both the wallet and the computer on Windows. On the other hand, on Linux and Android on USB, everything worked fine. Additionally, Bluetooth on Android worked as expected, and both buttons functioned correctly when entering my PIN.

Details:

  • Issue: The left button on the TTGO did not work when entering my PIN on Windows
  • Reproduction Steps:
    1. Power on the TTGO Jade wallet DIY
    2. Connect it to a Windows computer via USB
    3. Try to enter your PIN using the left button
  • Expected Result: The left button should work correctly, allowing me to enter my PIN.
  • Actual Result: The left button does not work on Windows, preventing me from entering my PIN.
  • Video Evidence: I have a video recording of the issue, which I can share with the developers.
  • Firmware version: 0.1.47-19-ga509904
  • Secure Boot enabled: Yes

Additional Notes:

  • The issue was not present on Linux and Android on USB.
  • Bluetooth on Android worked as expected, and both buttons functioned correctly when entering my PIN.
  • I would appreciate it if the developers could investigate this issue and provide a fix as soon as possible.

How to obtain the bootloader? How to sign files?

I followed all the steps to build the firmware, and successfully created a build directory.
After moving the build directory to /tmp/jade, I attempted to flash:

$ DEVNAME=/dev/ttyACM0 ./flash.sh

Device /dev/ttyACM0 can now be flashed
esptool.py v3.0
Serial port /dev/ttyACM0
Connecting......
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 30:c6:f7:1f:6b:84
Uploading stub...
Running stub...
Stub running...
MAC: 30:c6:f7:1f:6b:84
Hard resetting via RTS pin...
esptool.py v3.0
Serial port /dev/ttyACM0
Connecting.....
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 30:c6:f7:1f:6b:84
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...
usage: esptool write_flash [-h] [--erase-all]
                           [--flash_freq {keep,40m,26m,20m,80m}]
                           [--flash_mode {keep,qio,qout,dio,dout}]
                           [--flash_size FLASH_SIZE]
                           [--spi-connection SPI_CONNECTION] [--no-progress]
                           [--verify] [--encrypt]
                           [--ignore-flash-encryption-efuse-setting]
                           [--compress | --no-compress]
                           <address> <filename> [<address> <filename> ...]
esptool write_flash: error: argument <address> <filename>: [Errno 2] No such file or directory: '/tmp/jade/build/bootloader/bootloader_signed.bin'

But there is no bootloader? I dont see it mentioned in the docs, and therefore I'd assume it should be built, but I am not really sure.

I am running the latest tagged version.

Later on...

I was able to build using this command, which DID build the bootloader:
idf.py build

I had to update the flash_jade.sh script, since the generated outputs arent "signed"

esptool.py ${COMMON_ESPTOOL_OPTIONS} --flash_size 4MB \
-u 0x1000 ${FLASHROOT}/build/bootloader/bootloader.bin \
0x9000 ${FLASHROOT}/build/partition_table/partition-table.bin 0xE000 \
${FLASHROOT}/build/ota_data_initial.bin 0x10000 ${FLASHROOT}/build/jade.bin | tee -a ${OUTPUTLOG}

(notice bootloader.bin vs bootloader_signed.bin and jade.bin vs jade_signed.bin)

I was able to successfully flash, but now the device doesn't turn on. I still see the device connecting to the serial port, but the display doesnt turn on, and Sparrow wallet is telling me the device is responding with an EOF.

Derivation path for Jade with Passphrase

I have a wallet (single sig, with passphrase) created on a Jade hardware wallet and I would like to recover the wallet in Electrum. After all it should be BIP39 compatible.

I entered the seed, checked the BIP39 marks, typed in my password as "additional words" (which works fine for ledger or trezor for example), and then chose the right derivation path (which should be p2sh-segwit, since my addresses all start with 3), but I dont get the same addresses as in the green software.

I tried changing the account number of the derivation path (so m/49'/0'/1' instead of m/49'/0'/0') but it is also not working.

Does anyone know why this is incompatible and what could be done to fix it?

Unusual multisig change path warning using Jade with Sparrow wallet

I've set up a 2-of-3 multisig using 3 Jades and Sparrow wallet. When I try to sign a transaction to spend from the wallet, I get a warning message: Unusual multisig change path.

Sparrow wallet uses path ../1/0 for the change, which I believe is standard. It also uses m/48'/0'/0'/2' as derivation paths.

How is binary transparency of the firmware achieved?

I'm keeping track of reproducible builds of various Bitcoin wallets and miss various details about how Jade works. The only thing about Jade firmware binaries I can find is that one should update the firmware during initial setup:

Screenshot from 2021-10-16 11-43-09

but as that doesn't involve downloading the binary first, I wonder where do I get the firmware binary? Next, not having a Jade myself, I am not sure how a user would be able to verify he's installing the correct update. Does the Jade display the binary's hash prior to installation? Lastly: Does the Jade verify the signature of an update? If so, how can I accomplish build reproduction? Which bytes is the signature?

You can find the current state of my analysis on WalletScrutiny.

wallet erase pin != duress pin

be cool if there was a real duress pin that unlocked a second privk... rather than erasing the wallet. as it stands, the "wallet erase pin" is ... obviously something you should not be recommending as a duress pin!

Does the Jade check the existence of a change address in the output of a transaction?

This is a continuation of the thread from: #22 (comment) . I had referenced this article: https://shiftcrypto.ch/blog/the-pitfalls-of-multisig-when-using-hardware-wallets/

I see that the Jade checks that the multisig change address in the output of the transaction is registered on the device: https://github.com/Blockstream/Jade/blob/master/main/process/sign_tx.c#L87

I was wondering though: Does it also check the existence of a change address in the output of a send transaction? I noticed that the Jade will ask the user confirm the change address, but the user has no way of knowing that this address is a "change" address. I'm thinking of the scenario where a malicious computer sends a send-to-many transaction to the Jade, where the second output is not a change address, but an address controlled by the hacker. Can this happen?

Stuck at connect screen

Previously paired the jade with both phone (iOS) and PC. Device shows up in Blockstream Green via USB or iOS via Bluetooth, but when try to Login to any wallet the Jade is stuck at "Connect Jade to a Blockstream Green companion app" screen. Power cycle brings me right back to this screen, no option to factory reset.

Firmware 0.1.27

Jade stuck at "Persisting PIN data..."

was setting up the wallet by scanning an existing seed qr code and entered the new PIN twice.

It ended up working but there might have been a communication error with BS server that didn't retry in time.

it is possible to flash inside a ESP32 Basic Core

I ran the following commands

git clone --recursive https://github.com/Blockstream/Jade.git $HOME/jade
cd $HOME/jade
cp configs/sdkconfig_jade.defaults sdkconfig.defaults
idf.py flash monitor

But I'm not able to boot after the fash my ESP32 Basic Core https://shop.m5stack.com/products/esp32-basic-core-iot-development-kit-v2-6

I keep receiving the following info

Writing at 0x00124122... (79 %)
Writing at 0x0012bbe2... (81 %)
Writing at 0x001362da... (83 %)
Writing at 0x0013dd30... (85 %)
Writing at 0x00143670... (87 %)
Writing at 0x001490c3... (88 %)
Writing at 0x001509b0... (90 %)
Writing at 0x001565cb... (92 %)
Writing at 0x0015bda3... (94 %)
Writing at 0x0016173f... (96 %)
Writing at 0x00166d17... (98 %)
Writing at 0x0016c69f... (100 %)
Wrote 1437664 bytes (875724 compressed) at 0x00010000 in 21.5 seconds (effective 534.9 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 126...
Writing at 0x00009000... (100 %)
Wrote 3072 bytes (126 compressed) at 0x00009000 in 0.1 seconds (effective 374.7 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 31...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (31 compressed) at 0x0000e000 in 0.1 seconds (effective 492.8 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
Executing action: monitor
Serial port /dev/ttyUSB3
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting.......
Detecting chip type... ESP32
Running idf_monitor in directory /home/vincent/Github/Jade
Executing "/home/vincent/.espressif/python_env/idf4.4_py3.10_env/bin/python /home/vincent/Github/Jade/tmp/esp-idf/tools/idf_monitor.py -p /dev/ttyUSB3 -b 115200 --toolchain-prefix xtensa-esp32-elf- --target esp32 --revision 1 /home/vincent/Github/Jade/build/jade.elf -m '/home/vincent/.espressif/python_env/idf4.4_py3.10_env/bin/python' '/home/vincent/Github/Jade/tmp/esp-idf/tools/idf.py'"...
--- idf_monitor on /dev/ttyUSB3 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0138,len:1496
load:0x40078000,len:14572
ho 0 tail 12 room 4
load:0x40080400,len:2956
0x40080400: _init at ??:?

entry 0x400805d4
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0138,len:1496
load:0x40078000,len:14572
ho 0 tail 12 room 4
load:0x40080400,len:2956
0x40080400: _init at ??:?

I'm doing something wrong? or it is not possible to use the firmware inside the https://shop.m5stack.com/products/esp32-basic-core-iot-development-kit-v2-6

Display a warning if multisig suffix paths don't match

Thanks. So with Jade we opted to be quite strict in this regard - in order to use multisig the user first needs to register the setup on Jade - ie. as a separate registration step the user inspects/confirms:

* all co-signer xpubs (the hw checks that at least one belongs the Jade)

* threshold

* script type

* (and now) whether bip67 key sorting applies

Once that has been confirmed, future requests to get receive addresses or change addresses will use the registered setup - the only additional data passed per request is the bip32 path suffixes. The full key derivation paths are validated against bip45/48/87, and that the final element is within a reasonable range. If this validation fails, a warning is displayed and the user must explicitly check/confirm the path.

We believe this should cover the known attack scenarios - but obviously are happy to hear if you think otherwise! ;-)

I think I thought of a scenario.

I noticed that to get an address, the computer sends the following to the Jade:

INFO:jade:Sending: {'method': 'get_receive_address', 'id': '468131', 'params': {'network': 'mainnet', 'paths': [[0, 2], [0, 2], [0, 2]], 'multisig_name': 'hwi'}} as cbor of size 108

However, I see that the Jade accepts paths that don't match like:

INFO:jade:Sending: {'method': 'get_receive_address', 'id': '865589', 'params': {'network': 'mainnet', 'paths': [[0, 1], [0, 2], [0, 3]], 'multisig_name': 'hwi'}} as cbor of size 108

which I think is non-standard in most companion wallets.

Could an attacker pass something like [[0, 2333], [0,3999], [0,4383]] and perform a type of ransomware attack on get_address or sign_tx, where they will only reveal the paths in return for some BTC?

I saw that there's actually some validation on paths here:

bool wallet_is_expected_multisig_path(
, but I don't think this case is covered. I think this wouldn't be a problem for 2 of 3 multisig, as the victim could easily brute force the paths because there's a check on MAX_PATH_PTR of 10000, so 10000^3=10^12 combinations to try (for comparison, bitcoin network hashrate is in the order of 10^20 Hashes/second), but this might be a problem for larger multisigs (I see up to 8 signers are supported). Should we be checking that the paths are all equal to each other for multisig wallets?

Originally posted by @georgantas in #22 (comment)

Bug in xpub export

I found a problem when exporting the xpub from the Wrapped Segwit wallet (BIP 49), when importing into the Blue Wallet, it imports addresses that are Native Segwit, but Jade checks these addresses and does not identify them as belonging to my seed.
I'm using the latest version of the firewall, I'm investigating further to find out if it's a problem with Jade or BlueWallet.

What other android apps could I use to import a Watch-Only?

I should send more information about the bug and how to replicate it soon.

Jade and normal multisig compatibility

Are there plans to add support for standard multisig wallets?

I see that you have support for Green-specific 2-of-2 or 2-of-3 or 2-of-2+csv, but would be nice to be able to use Jade in standard multisig with other hardware wallets.

For example, software wallet could pass receiving and change descriptors to the HW and it could verify that all scriptpubkeys in inputs and change outputs are derived from these descriptors.

Missing cbor dependency?

I tried running the docker image and got this during the idf.py flash step:

-- Building ESP-IDF components for target esp32
CMake Error at /root/esp/esp-idf/tools/cmake/build.cmake:185 (message):
  Failed to resolve component 'cbor'.

Jade on Liquid - sign with sighash ALL | RANGEPROOF

Signatures returned from Jade are not commiting to rangeproofs. This can cause lock of funds.

Malicious software wallet can generate invalid rangeproof in change output of the transaction using an attacker's blinding key. Then the user will not be able to unblind change output and will not be able to spend this money.

It's not a loss of funds, but certainly lock of funds and an opportunity for ransomware attacks.

Button A (previous) not responding on M5 stack

I set the environment, compiled and flashed Jade on a standard M5 stack and soon noticed Button A was not responding.
I tried to debug input.c and tinker with the code but didn't manage to find out why "btn_handle_prev" was not responding and "button_A" was not being called.
Log warned about "handler already registered, overwriting" but I wasn't able to find out if it has to do with this issue

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.