Security Roadmap (architecture change + new features)

[FrancisPouliot]

Security roadmap

Currently, Cyphernode security is based on the premise that the application connecting to the cyphernode will be part of the docker network. Different components of Cyphernode can run on different machines, but it is important to note that if one of the machines has root access compromised, they can take over all other parts of the network. To provent this, they can be run on a single machine where security is increased.

We did it in this way originally because that was functional for our own apps, but then again this does place constraints on people that may not want to have the same setup.

We realised two problems with this:

• People don't necessarily want to have to run their entire app through the docker Swarm
• People managing the application may not want developpers that have access to the application to also have access to the cyphernode instance.

A solution to this is simply to enable a public API with authentification system.

This has two main vulnerabilities:

• Whoever has access to the API keys can send commands to components of the Cyphernode docker swarm, including to bitcoin core wallets for withdrawals.
• If a user interface is connected to the API, anybody with access to the user interface (e.g. a web-wallet, an admin panel, etc.) then they can also use the API to get access to the docker network.

There are solutions to this:

• Leverage hardware wallets for authentification to user interfaces, as well as SSH access to the virtual machines where the Cyphernode is hosted (required for updates and all server access)
• Enable security policies that delay and mitigate the risks of unwanted access to the docker network, so that human intervention to prevent it is streamlined and almost completely automated.
• Rely on off-line signing for all outflow of funds from a Cyphernode instance. This means that all or some transactions must be signed remotely, and there are no funds held in the Bitcoin Core wallet. This can be done using the PSBT BIP174 standard. In addition, we can add the Python-Trezor library as a docker component, which act as a wallet interface for the Trezor.
• IP whitelisting
• Generate new API keys server side and send them to app only after auth.
• Remote killswitch to API access

Security policy proposal: have all outbound transactions included in a batch by default. The option to send outside of a batch is disabled, re-enabled only with hardware auth. Set a maximum threshold per batch. All batches exceding a certain size must be approved by admin via offline signing. Under a certain size, they are simply signed withing Bitcoin Core. You can set a batching schedule for office hours, so that an admin is always expected to sign transactions a few times per day. If an attacker gets access to the Cyphernode, he will not be able to exceed the limit without having to wait between batches or forcing the admin to notice as he manually signs.

Infrastructure

• [ ] Create a system for API authentification which allows apps to connect remotely to Cyphernode without becoming part of the swarm. This would be exactly the same user experience as for commerical APIs such as Bitgo

• [ ] Create default configurations for spender node vs. watch node. Spender node doesn't expose ports publicly, while watcher nodes do. Spender nodes would be encryped and connecting to them would require password additional to the API authentification.

• [ ] IP address whitelist for API connections

Features

• [ ] Enable the Trezor Pyton library to allow for Trezor wallet integration

• [ ] Enable ColdCard integration and BIP174 for remote signing

Spending policies

The danger in having an app connect to a secure Cyphernode is that controlling the app would give direct control to the funds in the cyphernode.

We have an idea for spending policies, which is the following (in combination)

• [ ] Add option to force all hot-wallet operations to be done via batch spend an disable instant "Send Bitcoins" API call, giving the cyphernode operator the option to completely remove the "send bitcoins" functions without going through a batching process. This means that an attacker could, at best, add the transactions he is attempting to do to withdraw funds from the wallt to a batch.

• [ ] Add a "maximum batch size" threshold, either in BTC amount of % of funds available. If a batch hits the treshhold, the app operator is notified (callback and email). These batches require off-line signing and cannot be sent from the hot wallets

What this prevents

• If an internal person or attacker takes control of the app, he cannot withdraw bitcoins, he can only send to batches.

• He will only be able to withdraw the maximum batch size at the frequency of the batching schedules

• The app operator can manually approve batches, and if he thinks something is off, he can detect it before it's too later.

• The tradeoff between convenience and security is then lowered, and prevents large frauds/hacks without inhibiting small withdrawals

[FrancisPouliot]

The Bitcoin core hot wallet would be only as secure as the app which controls it. It can be used as a hot wallet for service operators in their own dashboard.

[Kexkey]

features/authapi branch merged, containing: authentication and authorization on a HTTP API in front of the proxy.

• Auth API key (client ID + key)
• Group per ID (watcher, spender, admin and internal groups) for more granular access rights
• Documentation on how to create keys, use SSL, configure groups...
• IP whitelist tentative -- not working, will be worked on later, docker obfuscates real client IP when a Swarm is used