Storing Secret Key for Smart Contracts

Question

I'm currently working on a project that will implement multi-signature smart contracts to process our transactions. I have a quick question and am looking for input on how best to do this.

My team is working on a platform and for simplicity let's just say we have buyers and sellers, and all buyers and sellers have a registered account and stellar address/wallet on our platform.

We will create smart contracts that include the buyer, the seller, an escrow account, and us (in total 4 parties involved) which will be created for all payment scenarios (success, cancellation, refund, etc). Depending on which stage of the payment process we are on, each of the parties involved will have to sign and authorize the tx to go to the next step. And here is how I'm wondering what is the best way to do this?

We will need users to sign with their secret key, but also want to automate these contracts and make them easier. So instead of the buyer or seller having to input their secret key all the time to sign and authorize we would store the secret key encrypted on our platform and for example, if they click a button on our platform or advance/proceed with their transaction on our platform the smart contract will automatically be signed and then continue to the next step.

But this requires storing of all users' secret keys and I know many people will not be happy or trust this. I would also be wary about anyone claiming to store and encrypt your secret key, because we've all seen and heard about the various hacks happening all the time.

So my question is, how to make this safer and more trustable? Is there an easier way to automate a multi-signature smart contract without storing secret keys and requiring all parties to input their keys to proceed with the contract?

Many thanks.

Answer 1

Generally speaking, if you're owning all the accounts and everyone trusts you then I'd suggest adding your own private keys to the accounts instead of taking theirs.

If you add your own key that is equally weighted to their key, then you can use that key to sign equal to their own. Further, this means you don't actually have to give them a signing key at all, and instead can use an authentication process to validate them and get their authorization to sign instead of applying their actually signature to a txn.

You've effectively described a completely closed network that coincidentally happens to be hosted on the Stellar Network. Since you won't be dealing with accounts outside of your own private sphere of influence; you can effectively take control over all the Stellar Accounts in their entirety and avoid pretending like the users can actually manipulate the accounts.

This will also save you tons of headache later on, because if the users can actually sign on their own accounts then they can modify the settings on those accounts, change the signers, change the custom data, make trades on the DEX, make offers on the DEX, create new accounts, send any XLM in the account to other accounts you don't control, etc. These sound like operations you don't want to enable the users of your platform to be able to execute.

The easiest way to lock them out of doing that is not giving them a signing key in the first place, and simply use your own "system signing key" on all the accounts. This way instead of having hundreds or thousands of keys; you have only 1 or 2.

If making 1 or 2 of the same keys on every account makes you feel a bit squeamish; then this is also a great use case for the bip39 libraries, where you'd have one "root key" for the system, and then every account has an index id that's derived from the root key. Every account's keypair is a deterministic derivation of the root; so you only have to protect the root key, which doesn't have to be revealed during the system's operation because you can send in requests to a "signing server" which takes care of that part for you.

Short of knowing a lot more about what you're doing; using a "signing service" to sign transactions to keep the number of places the unencrypted key secrets are seen; limiting the number of keys you're protecting (either because you've replaced the signing key on all the accounts with your own system keys or are using deterministically derived keys); and preventing your users from actually getting an actual signing key in the first place should get you started on some sane lines of thinking on how to think about these processes.

Something you should probably consider is a private Stellar network. If you aren't using the public DEX to interact with a whole lot of accounts you don't have anything to do with, and you aren't concerned about being reponsible for managing the hosting for some of your own infrastructure; a private Stellar Ledger network may be exactly what you're looking for.

Answer 2

If you can avoid taking the secret key from the user it will reduce your liability and the user will be likely to trust your application or service.

SEP-0007 introduces a custom URI Scheme web+stellar: that will allow applications/websites such as yours to delegate transaction signing to wallets. You could generate URIs like what is described in the proposal to ensure that:

1. Transactions can be signed by users
2. Your application does not touch the user's secret key

There are also provisions for handling the multisig case which can be very useful for your application.

Answer 3

On the OpenCart payment plugin escrow system we did it like this: We setup an escrow account 2 of 3 signers for the amount to be paid to the store after say 30 days. 30 days the package to the customer is expected to arrive. If all goes as planed the 3rd party escrow agent never has to sign anything. The buyer at checkout sends a pre-signed time bound transaction to the store that has to also sign that transaction and wait for the 30 day time bound window before it can submit the transaction to the stellar network to be proccessed to get it's payment.

In the event the customer fails to get the product within 30 days then the customer can contact the store and see about getting an extension of the 30 day time bound payment or ask for a refund transaction from the store that the buyer can then also sign and get the money back. In the event the store refuses to respond to the customers contact or some kind of dispute the customer can then contact the 3rd party escrow agent that can then attempt to contact the store and collect the details from both the customer of the problem issue and the stores points. The 3rd party agent can then decide to release the funds to the store or refund the customer with a transaction that 3rd party signs and the customer or store also signs to close the issue.

The wallets setup to support these escrow transactions are my_wallet and a modified stargazer wallet. As complex as the above sounds it is all performed in the background in the wallet and at the store plugin. The user just scans a QRcode or clicks a wallet URL link, analyzes the transaction to take place on the wallet and hits the SEND button to finalize the transaction. On the store side the transaction is seen by the store admin much the same as a credit card transaction as pending or processed.

If this sounds like it might be modified for your use you can see the code for the OpenCart stellar payment plugin at: https://github.com/sacarlson/OpenCart_stellar_plugin. also more code in the store escrow transaction processor server is found here: https://github.com/sacarlson/OpenCart_escrow. My_wallet code: https://github.com/sacarlson/sacarlson.github.io/tree/master/my_wallet.

Disclaimer: I made this.

You can check out the new plugin on the now active test store using testnet fake money at: https://www.funtracker.site/test_store/ . To access fake money you can use funds from this wallet link: https://sacarlson.github.io/my_wallet/?json=%7B%22seed%22:%22SAYRX7D4XXTMBKNGDG7TV2WLVJ2UEJPNGS3JQTDADX4J4X66XAMVDGHT%22%7D. Now also works with our new branched version of Stargazer android wallet with added V3.0 QR-code support. Have fun.