-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jade and normal multisig compatibility #22
Comments
This is something in the pipeline for an upcoming release. |
Merged to master, for the next fw release, |
|
NOTE: fyi support has also been added to the relevant HWI PR |
fyi: the next release of the Jade fw should add support for bip67/sortedmulti(), and a PR to enable that on HWI will follow. |
fyi: Jade fw |
Awesome, thank you! |
Interesting article: https://shiftcrypto.ch/blog/the-pitfalls-of-multisig-when-using-hardware-wallets/ Wonder if multisig with Jade is vulnerable to some of these attacks. |
Thanks.
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 am trying to implement that and currently have a problem registering multisig on the device, here are the parameters for
I receive an error:
|
The same happens with the current master of HWI when I am trying to display address for unsorted multisig descriptor:
|
Is one of the cosigners derived from the Jade key/fingerprint - and it is correct ? ie. the jade master key plus the derivation given, definitely yields that xpub ? Jade itself and HWI have tests which [should] be covering the above. |
OK, I loaded the test seed (from the jade tests) into jade and got the xpub we want to use:
to get: I then switched out the first signer fingerprint/xpub of your multisig to my jade fingerprint/xpub, and got the following:
|
With your first example, I added my Jade test key, so the multisig became a 2-of-4:
(Note the fingerprints are sent as bytes, not hex strings)
|
fyi: I do have 'Add api/cbor-message documentation' as an outstanding task! |
Thank you for the clarification, Jamie. I had one more doubt, but I created a new issue not to go off-topic on this issue: #29 |
@JamieDriver this is very strange, I tried again, the same issue. Firmware version 0.1.32. from jadepy import JadeAPI
from hwilib import _base58 as base58
NETWORK = "testnet"
HARD = 0x80000000
PATH = [HARD+48, HARD+1, HARD, HARD+2]
params = {
'network': NETWORK,
'multisig_name': 'tmp',
'descriptor': {
'variant': 'wsh(multi(k))',
'sorted': True,
'threshold': 2,
'signers': [
{'fingerprint': 'fb7c1f11', 'derivation': PATH, 'xpub': 'tpubDExnGppazLhZPNadP8Q5Vgee2QcvbyAf9GvGaEY7ALVJREaG2vdTqv1MHRoDtPaYP3y1DGVx7wrKKhsLhs26GY263uE6Wi3qNbi71AHZ6p7', 'path': []},
{'fingerprint': '47fc1ba1', 'derivation': PATH, 'xpub': 'tpubDFa3rRFxivQmR3dcgfStqsry6QXHrjpV1FjyXKE8BroySBRTL1SD8ddh2sWXUZxF6wRZufhpkaiR9qqmc7mzEUr4ddvpN7ZHkvJ7vTbgRJD', 'path': []}
]}
}
with JadeAPI.create_serial("/dev/ttyUSB0") as d:
d.auth_user(NETWORK)
xpub = d.get_xpub(NETWORK, PATH)
print(xpub)
child0 = d.get_xpub(NETWORK, [0])
fgp = base58.get_xpub_fingerprint(child0)
print(fgp.hex())
params["descriptor"]["signers"].append({
"fingerprint": fgp.hex(),
"derivation": PATH,
"xpub": xpub,
"path": [],
})
print(d._jadeRpc('register_multisig', params=params)) |
As I say above (and as in my example) fingerprint should be bytes, not hex-string.
with these changes, your script works for me. I know I need to generate some documentation so totally my bad. It is high on my list for the new year! |
Sorry, I missed it. Works now, thanks a lot! |
I think I thought of a scenario. I noticed that to get an address, the computer sends the following to the Jade:
However, I see that the Jade accepts paths that don't match like:
which I think is non-standard in most companion wallets. Could an attacker pass something like I saw that see there's actually some validation on paths here: Line 343 in 34a1814
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?
|
Might be a good idea. Let's continue discussion on #30 - cheers. |
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.
The text was updated successfully, but these errors were encountered: