search

iotaledger / iota-sdk

The IOTA SDK provides developers with a seamless experience to develop on IOTA by providing account abstractions and clients to interact with node APIs.
Apache License 2.0
54 stars 39 forks source link

(non-)Slip-10 interface in `SecretManage` #701

Open DeppLearning opened 1 year ago

DeppLearning commented 1 year ago

Description

The SecretManage trait assumes a Slip-10 compatible implementer, i.e. a hierarchical and deterministic wallet.

Motivation

Hardware security modules (HSM) used by larger corporations to store keys usually do not support Slip-10 (or even Bip-32). Currently, in order to support HSMs, we are forced to work around the problem, i.e. by caching the path and other Slip-10 parameters.

Requirements / Open questions (optional)

Would it make sense to provide a non-Slip-10 interface, that assumes just "normal" Ed25519 keys?

Are you planning to do it yourself in a pull request?

Maybe

Aconitin commented 10 months ago

This is blocking us quite heavily on using identity-rs properly. To make the issue a bit more clear:

Since everybody in our industry is using HSMs for key storage (as you should), but the SecretManage trait assumes "basically Stronghold" through Slip-10, you can't really build a secure application that passes the signing part off to a HSM. The result is a really dirty hack to "make it work somehow" by creating an intermediary layer that acts as if it implemented Slip-10 towards the iota-sdk.

It would help a lot of the SecretManage trait was unassuming and just dealt with normal Ed25519 keys. Would it be possible to bump this up a little? Otherwise, is there maybe some (more "canonical") preexisting implementation that could help us?

(For the identity people: Every identity will need to have its state controller / governor keypair in a Stronghold, even if you store document-level keys in an HSM, degrading the security of the whole identity to Stronghold level)

Thoralf-M commented 10 months ago

Can't you just ignore the Slip-10 stuff as in https://github.com/iotaledger/iota-sdk/pull/937/files?

DeppLearning commented 10 months ago

Can't you just ignore the Slip-10 stuff as in https://github.com/iotaledger/iota-sdk/pull/937/files?

Thx a lot for the hint, while in fact I forgot the SecretManage is implemented for private keys, that doesn't really help I guess. The point of the HSM is that the raw keys never exit the HSM. We simply don't have access to the raw private key, we can only access it via a reference and sign arbitrary data with it using PKCS#11.

Thoralf-M commented 10 months ago

My point was not about using this PrivateKeySecretManager for your case, but why can't you implement another secret manager in a similar way, where you just ignore the Slip-10 things?

DeppLearning commented 9 months ago

My point was not about using this PrivateKeySecretManager for your case, but why can't you implement another secret manager in a similar way, where you just ignore the Slip-10 things?

I guess I was stuck thinking that I'd have to implement SecretManage for the thing that generates keys rather than the (reference to the) key itself. Thanks for the help, I can work around the issue this way for now.

Aconitin commented 9 months ago

Note that this workaround does require a fork and even though "it works", it's not really a clean solution, so please don't close this ticket 😆

Giordyfish commented 8 months ago

I am having a similar issue. I have to publish a block using the Client, and the interface forces me to use the library's SecretManager enum to be able to sign the transaction. I use a threshold signature scheme, meaning I cannot access the private key nor can I use Stronghold (as Stronghold does not support multi-party signature schemes).

This interface also affects identity-rs, as I can not publish a DID document without providing a SecretManager.

Implementing my own SecretManage does not solve the issue alone, as all the client's methods require the specific SecretManager enum from this library. I have not been able to pass my own SecretManage without forking.

I have been able to work around this issue in the past release (before SDK) but it required a lot of fine-tuning and it broke every other release.

I am suggesting a more generic method/interface for the Client to sign. Using something like a trait with the scope of a simple "signer". I feel like the client should not enforce its preference on the way I want to sign data, as it compromises interoperability.