Flexible BIP32 path for cointype

[sidhujag]

Hello in light of the PR #292 that was rejected here is another attempt to try to leverage bitbox for application agnostic support for HW key management. I don't see the need to enforce the cointype especially when there are many applications (alt coins, digital identity intiatives) that can benefit from a BIP44 strategy around application specific HD key strategies leveraging DPKI. It seems bitbox is a flexible design in that no other coin specific things are checked which I like, the only bottleneck is enforcement of the cointype. This PR is meant to be a starting point to discuss how to enable other applications which require self-sovereign/custodial key management. Saying no to these applications will greatly hinder adoption and underline the premise of why we are here hopefully working together to oversee the usage of blockchain technology and all the benefits it brings.

[benma]

Hi @sidhujag

Removing the restriction on the coin type has security implications. Opening up the BitBox01 is an interesting idea, but is not a trivial change. Our focus currently is not with extending support for other coins/applications. This might change in the future.

Thanks for the effort and your understanding.

[sidhujag]

What security implications are there if cointype level is hardened?

[KasparEtter]

You find more information on this in https://medium.com/shiftcrypto/bitbox-desktop-app-4-6-0-with-firmware-6-0-3-release-ec46937afe7c#64e7 and https://blog.sia.tech/a-ransom-attack-on-hardware-wallets-534c075b3a92.

[sidhujag]

@KasparEtter thanks for that. After reading that it makes sense that the display would show address derivation to confirm, and ledger/trezor do this. I assume bitbox also does this but it is not-related to cointype it is related to the key index which is not hardened. The attacker would not be able to create adjacent keys to cointype as it is hardened and the attack is relevant wether or not we look at cointype. The OLED should show that you are generating a new address at a keypath that is the fix for this attack correct me if im wrong.

So how does cointype relate to this attack? specifically how would a hardened derivation index relate to such at attack?

"An attacker who successfully compromised your computer could make you lose your change by choosing an arbitrary derivation path unknown to you. This is due to the range of potential keys, which is too vast to be searched thoroughly when recovering a wallet from a backup."

The attacker cannot generate or change anything directly above or below the cointype if it is hardened and enforced as hardened. They can only modify the index for change address which is not hardened and thus tricking users to send to a key index outside of the normal range of wallet lookup.

[KasparEtter]

No, a compromised app can request the xpub at any keypath (except m itself) from the firmware without user confirmation/interaction. Hardened or non-hardened derivation does not matter. The BitBox01 (for whose firmware you made the PR) does not have a screen and while we could have rewritten the logic of the mobile verification app to warn the user in case of non-standard keypaths, we decided to be more restrictive in the firmware instead. While this is not ideal, we will not revisit this decision now. Thank you for your understanding.