Jade DIY hardware wallet

[Cricktor]

It would be nice to understand what caused the issue in the first place.

Maybe a cosmic ray particle or photons incident at the wrong place and time affecting the startup process when apogio turned on his device? Speculation...

As I said before, I still would be scared of using that particular hardware.

I assume apogio checked thoroughly the recovery of his wallet after reflashing the device. That should be fine then, except if you're scared that some bits or registers could be instable in his device. If this were the case, instability could occur more often or worse screws things up right when you don't need it, like when you sign a large transaction.

Should we have some function tests built into the firmware to be able to check manually that all major functions are performing properly?

[apogio]

Maybe a cosmic ray particle or photons incident at the wrong place and time affecting the startup process when apogio turned on his device? Speculation...

Wow, what's that? Sounds intriguing, my knowledge in physics sucks haha

As far a the backups are concerned. Yeah, obviously nothing bad happened. In fact, as I have said, my Jade is amnesiac. Every time I turn it off it erases its memory. So I always need to scan a QR code to load my wallet. Nothing is persisted once it's shut down.

[Cricktor]

Wow, what's that? Sounds intriguing, my knowledge in physics sucks haha

You might be interested to watch The Universe is Hostile to Computers. In the first minutes an election machines glitch is explained which likely happened due to radioactive decay or this cosmic ray stuff aftermath.

In fact, as I have said, my Jade is amnesiac. Every time I turn it off it erases its memory. So I always need to scan a QR code to load my wallet. Nothing is persisted once it's shut down.

I know, that's the purpuse and part of the security model of those signing devices. You still want to be sure that after you re-instantiate your wallet, everything from that point of usage of the device is working reliably.

I think, I wouldn't be as scared as fillippone is. After you can revive the device by re-flashing the firmware and it doesn't nag with further obvious instability or hangs, I'd dismiss the previous glitch as a one-time hiccup. Am I reckless?

[apogio]

I think, I wouldn't be as scared as fillippone is. After you can revive the device by re-flashing the firmware and it doesn't nag with further obvious instability or hangs, I'd dismiss the previous glitch as a one-time hiccup. Am I reckless?

You aren't. I don't care very much to be honest, but I understand fillippone's concern, because it's a natural behaviour to be concerned when things like this happen and especially when they happen to devices that are used to hold secrets of any type. Could be private keys, gpg keys, passwords, anything like that.

[Pmalek]

I know, that's the purpuse and part of the security model of those signing devices. You still want to be sure that after you re-instantiate your wallet, everything from that point of usage of the device is working reliably.

He can always fall back on his backup phrase in case the device starts acting up or becomes unusable for the purpose it was designed for (signing transactions). The worst thing I can think of from the top of my head is that it somehow starts generating addresses whose coins you can never spend (sign) because of a serious bug. Of course, I am just throwing ideas out there, and I don't think it's a realistic scenario.

[Cricktor]

The worst thing I can think of from the top of my head is that it somehow starts generating addresses whose coins you can never spend (sign) because of a serious bug.

Something of that category came to my mind, too. I don't say lightly, I'm not scared or not concerned. I would mostly assume, if a device starts to act wonky, it would produce enough garbage that errors creep in quickly that the network would simply reject a funky transaction, hopefully! But your described nightmare may still be possible if things go when Murphy takes over as he always does.

Some bad feeling likely remains with a device that showed signs of unreliability. A one-time bad day I would brush off, kind of.

[apogio]

The worst thing I can think of from the top of my head is that it somehow starts generating addresses whose coins you can never spend (sign) because of a serious bug. Of course, I am just throwing ideas out there, and I don't think it's a realistic scenario.

It is a realistic scenario, but not a likely to happen scenario. I mean, bugs can be found in the code, but the address generation process is a core process, which, I hope, has been tested by both software unit tests and human tests. I can't believe that there will be a flaw in such an important aspect of the software.

What can happen though, is that someone can use a fake website to update their firmware and that the installed software can be malicious. This is a huge problem if it happens... I hope that the device won't work with the fake website, but since I am a developer and not a security person, I don't know how easy this scenario is.

[fillippone]

I still don’t get it.

What is the risk of a fatal hardware malfunction once you have witnessed something like that one apogio experienced? 0.1%?
1 BTC is 70,000 USD.
1 Jade costs roughly 100 USD.

So 100 USD /0.001/70,000 USDBTC≈1.42 BTC

Ok, then it is not worth handling UTXO bigger than 1.42 BTC with such an hardware.
Provided you already have a functioning backup of the seed phrase (Master key).

This is how I would approach the question.
Also, I am irrationally risk-averse when it comes to losing Bitcoin (I said irrationally!) so I would further lower that threshold.

[apogio]

This is how I would approach the question.
Also, I am irrationally risk-averse when it comes to losing Bitcoin (I said irrationally!) so I would further lower that threshold.

Some bad feeling likely remains with a device that showed signs of unreliability. A one-time bad day I would brush off, kind of.

You are both correct. And since I have been asked the question a lot, about why I keep trusting the device and why I still use it, I want to make something clear.

1. I can read and understand C, so I feel confident reading the code. Which is important for me.
2. My usage is pretty limited. Once a month, I scan a private key QR code, I sign a transaction (usually a pretty small one), I erase the memory of the device (using temporary signer option).
3. Blockstream doesn't know my address, nor my name, since I received the product elsewhere, where I don't have the ability to access now, so if I request a change, or buy a new one, I will need to use my real name and address.
4. I own other devices that I use for more frequent transactions.
5. I always know that my backups are safe.
6. I always use QR codes, which is safer than USB cables. Still, QR codes are not a panacea, but, you know, I feel more confident.
7. The Jade is a reputable device.

Warning:
Finally, always be very cautious when it comes to using browser-based products (software & updates). Always verify what you download. Always think twice before downloading something.

[BlackHatCoiner]

It is a realistic scenario, but not a likely to happen scenario. I mean, bugs can be found in the code, but the address generation process is a core process, which, I hope, has been tested by both software unit tests and human tests. I can't believe that there will be a flaw in such an important aspect of the software.

I checked Jade's github repository a little bit. It doesn't use libsecp256k1 as the library for performing elliptic curve operations, at least as far as I can see. It isn't a very good sign, considering that it's the most tested library for that sensitive purpose, and used by the most reputable pieces of software like Bitcoin Core.

To me the portion of the project that is cryptography-related is the most crucial. I wouldn't care if the UI had a bug. However, if there's a bug in cryptography like a non-random R-value in a signature, that can be catastrophic. But, again, I'm not totally sure they use another reputable library for EC operations.

[Pmalek]

the address generation process is a core process, which, I hope, has been tested by both software unit tests and human tests. I can't believe that there will be a flaw in such an important aspect of the software.

I didn't mean there would be flaws in it b default. I am sure we would have heard about it by now. The Jade doesn't have the userbase of Trezor or Ledger, but whatever it's got, we would have heard about something like that.

The bugs I was speculating about could perhaps be the result of certain software/hardware issues and not a scenario you would see if everything was working top-notch.

I checked Jade's github repository a little bit. It doesn't use libsecp256k1 as the library for performing elliptic curve operations, at least as far as I can see. It isn't a very good sign, considering that it's the most tested library for that sensitive purpose, and used by the most reputable pieces of software like Bitcoin Core.

To me the portion of the project that is cryptography-related is the most crucial. I wouldn't care if the UI had a bug. However, if there's a bug in cryptography like a non-random R-value in a signature, that can be catastrophic. But, again, I'm not totally sure they use another reputable library for EC operations.

This is a question and topic that should be directed to their customer service team, instructing them to push it further to their development team to clarify. I will do it during the weekend if I don't forget. Feel free to add something more if you want to.

[BlackHatCoiner]

Feel free to add something more if you want to.

As it turns out, I was not totally right.

It doesn't directly use libsecp256k1, indeed, but it does use secp256k1-zkp, which is a fork of the former. As you can see in here, it says that their EC library calls secp256k1_surjectionproof_verify() and secp256k1_rangeproof_verify(), which are defined only over secp256k1-zkp. You can verify by searching in libsecp256k1 (empty) and in secp256k1-zkp (non-empty).

I should think about it twice before questioning Blockstream for their lack of research. 

[apogio]

I should think about it twice before questioning Blockstream for their lack of research. 

Especially since the founder has invented the core mining mechanism of bitcoin 

Seriously though, nice catch and nice study. You have provided us with some knowledge.

[Jason Brendon]

TTGO (Lilygo) T-Display ~$10 USD

https://github.com/3rdIteration/Jade/blob/master/diy/readme.md

I think this TTGO has wifi connection embedded? How can anybody use this to store your private keys?

[Cricktor]

I think this TTGO has wifi connection embedded? How can anybody use this to store your private keys?

I'm pretty sure (though couldn't find a quick confirmation) that even when there's wifi hardware available, it isn't enabled, no driver loaded, no wifi initialized or explicitly disabled. It wouldn't make sense to have such an attack vector open when you can disable this potential connectivity.

Or the other way round, if you fear such a DIY Jade could maliciously leak your wallet secrets via wifi, the code is open-source, as far as I've seen the firmware is reproducable. Inspect the code for shady stuff. The Jade clone can't guess your or other wifi's passwords.

I have the same strategy with my DIY PiTrezor which I run on a Pi Zero W. As wifi and/or Bluetooth can't be used with a basically Trezor One firmware, there's a) no driver for wifi or Bluetooth in PiTrezor's firmware and b) I disable explicitly both wireless modules in the Pi Zero's boot config. That's safe enough for me and my PiTrezor is more an experimental project, no valuable wallet on it.

[Jason Brendon]

I think this TTGO has wifi connection embedded? How can anybody use this to store your private keys?

I'm pretty sure (though couldn't find a quick confirmation) that even when there's wifi hardware available, it isn't enabled, no driver loaded, no wifi initialized or explicitly disabled. It wouldn't make sense to have such an attack vector open when you can disable this potential connectivity.

Or the other way round, if you fear such a DIY Jade could maliciously leak your wallet secrets via wifi, the code is open-source, as far as I've seen the firmware is reproducable. Inspect the code for shady stuff. The Jade clone can't guess your or other wifi's passwords.

I have the same strategy with my DIY PiTrezor which I run on a Pi Zero W. As wifi and/or Bluetooth can't be used with a basically Trezor One firmware, there's a) no driver for wifi or Bluetooth in PiTrezor's firmware and b) I disable explicitly both wireless modules in the Pi Zero's boot config. That's safe enough for me and my PiTrezor is more an experimental project, no valuable wallet on it.

I wish there was a DIY device that by default has no wifi at all...

[HideYourKeys]

I have flashed serveral TTGO T-displays for friends, as an entry-level device, I think it is the perfect choice.

Nevertheless, I have noticed that the last two ones I flashed (I only have one available, I gave away the other one) do not "keep the data", I mean, I flash them, and set up a wallet with the recovery words, the PIN, and so on... but once turned off and on, you have to enter all the words again... Have any of you guys experienced that? I am on 1.0.29 firmware.

P.S: I even wrote a post on this topic, and made a guide, in fact I made some ammendments and tricks on top of the videos the OP made. For instance, in some cases I did not get the bootloader prompt, but there are some commands to enforce its flashing. https://hideyourkeys.io/cheap-hardware-wallet-below-diy-guide/

[Jason Brendon]

I have flashed serveral TTGO T-displays for friends, as an entry-level device, I think it is the perfect choice.

Nevertheless, I have noticed that the last two ones I flashed (I only have one available, I gave away the other one) do not "keep the data", I mean, I flash them, and set up a wallet with the recovery words, the PIN, and so on... but once turned off and on, you have to enter all the words again... Have any of you guys experienced that? I am on 1.0.29 firmware.

P.S: I even wrote a post on this topic, and made a guide, in fact I made some ammendments and tricks on top of the videos the OP made. For instance, in some cases I did not get the bootloader prompt, but there are some commands to enforce its flashing. https://hideyourkeys.io/cheap-hardware-wallet-below-diy-guide/

Is it the new 'stateless' mode where it acts like SeedSigner(another DIY project) so every time you turn off the device, it forgets things.

[HideYourKeys]

I have flashed serveral TTGO T-displays for friends, as an entry-level device, I think it is the perfect choice.

Nevertheless, I have noticed that the last two ones I flashed (I only have one available, I gave away the other one) do not "keep the data", I mean, I flash them, and set up a wallet with the recovery words, the PIN, and so on... but once turned off and on, you have to enter all the words again... Have any of you guys experienced that? I am on 1.0.29 firmware.

P.S: I even wrote a post on this topic, and made a guide, in fact I made some ammendments and tricks on top of the videos the OP made. For instance, in some cases I did not get the bootloader prompt, but there are some commands to enforce its flashing. https://hideyourkeys.io/cheap-hardware-wallet-below-diy-guide/

Is it the new 'stateless' mode where it acts like SeedSigner(another DIY project) so every time you turn off the device, it forgets things.

Yep, it feels exactly like a seedsigner, how can I change that??

[HideYourKeys]

In fact, I have gone through the whole blockstream article, and I did use the PIN, but the device is still on "stateless" mode :S

https://help.blockstream.com/hc/en-us/articles/20108678230937-Advanced-Jade-Setup

I will retry and ask on blockstream TG as well