Long-winded way of saying “connect to the SAFE network and check for new versions”. Presented in RFC format but really just meant for discussion.
Secure Self Update
- Status: proposed
- Type: enhancement
- Related components: vault
- Start Date: 24-02-2020
- Discussion: TBD
- Supersedes: None
- Superseded by: None
Summary
Software components of the network (such as the vault) require periodic updating. This can be done automatically and directly from the SAFE network and should not require interaction with the old internet.
Conventions
- The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
Motivation
An autonomous self-healing network requires updates to add security patches or new features.
Currently upgrades are done using the self_update crate which allows the vault to download new versions from sources such as github or AWS S3.
The self_update crate requires use of the https protocol and a dependency on OpenSSL, which introduces large amounts of complexity and legacy that could be eliminated if this crate is removed.
The changes proposed in this RFC would improve the ability to audit the vault codebase and therefore improve the security of the network.
The short term goal of this RFC is to remove the OpenSSL dependency and the self_update crate.
The long term goal of this RFC is to enable autonomous governance and feature discovery for the network.
Detailed design
The protocol for updating is potentially extremely complex. In a way, the update process determines the governance of the network, so it’s an extremely powerful and sensitive aspect of the network.
- The vault software is started by the user.
- The configuration is parsed and the vault uses it to connect to the SAFE network (as a client, not as a vault).
- The vault fetches the list of available vault versions.
- If there’s a newer version
- The new vault version is downloaded.
- The updated vault is started.
- If there’s not a newer version
- The vault initialises as normal.
Configuration Requirements
provider: the root of the Name Resolution Service (NRS) for vault binaries. Initially this could be hardcoded as maidsafe but in the future could (should) be flexible. This is used to generate the standardised location safe://<provider>/vault/versions. This may also be a fixed xorurl which removes any dependency on NRS.
eg
{
"hardcoded_peers": [...],
"self_update": {
"provider": "maidsafe"
}
}
Downloading
The vault will check (using NRS) safe://<provider>/vault/versions
The list of vault versions will be plain text of the form
<version>,<xorurl for vault binary>
eg
0.19.2,safe://hygjd...wky
0.20.1,safe://hyfkc...iqw
Verifying
Initially signatures were proposed for binaries, however this was not found to ensure any greater security from an attacker (see Attacks below). It may be decided that signatures are worth including, which could easily be appended on each row of the vault/versions list as an xorurl.
Starting the New Version
The vault might halt after having downloaded the new version, notifying the user to instead run the new version. If the old version is started again it would simply redownload the latest version and exit again, so it becomes unusable.
A more sophisticated approach in the future may be to have the vault launcher be only able to coordinate starting new vault processes and stopping existing vault processes, which would allow the newly downloaded vault to be started automatically by the launcher.
This may be further abstracted to have the vault load separate binaries for each feature, so individual features can be updated and loaded on-the-fly rather than bundling all the features into a single vault binary.
Future Directions
- staggered rollout of updates rather than the whole network at once.
- hotloading updates without restarting the vault.
- separation of updates for features / consensus / etc into a more modular design.
- voting mechanisms for standard / proposed / experimental updates, windows of backward compatibility etc.
Attacks
Change the configuration for provider. This allows an attacker to download arbitrary data to the machine, and possibly execute it. A possible mitigation is to show the provider name before downloading, and require confirmation from the user (or a flag --no-update-confirmation to be passed). In theory a properly secured configuration file should be adequate to prevent this, but in reality this has proven difficult.
Change the configuration for initial peers. This allows the attacker to present a fake network to the user where the attacker controls the provider name, and the user will think they are downloading from the correct provider but they are not. This is equivalent to the prior attack because the configuration must be changed, but it allows the attacker to use the correct provider name so confirmation is not a preventative. It might be expected that signatures would help in this case since the attacker could not create a suitable signature, but the signing key would also be part of the configuration so would also be changed by the attacker. The only way to improve this is to have the signing key be separate to the provider/peers configuration, which seems impractical in an autonomous update situation.
Losing control of the NRS name or the list of versions allows an attacker to update vaults. This is an attack on the vault binary provider rather than the consumer. In this case signatures may be useful to include, however there must be strong separation from the signature key and the uploading key. If the NRS account is compromised it seems reasonable to assume the signing key may also be compromised. This is open to debate and possibly a standardised process for releasing vault binaries may be beneficial for provider security.
In summary, attacks come from altering the configuration of the vault operators or controlling the provider.
Scope
Since secure self update only requires client level features (ie no vault or consensus features) it could be used by any software that can communicate with the SAFE network, such as SAFE-browser or SAFE-api.
Drawbacks
This success of this approach depends heavily on either a) hardcoding values into the binary and securing the binary or b) securing the configuration file. However this seems true of any self_update style of feature.
Alternatives
The current alternative is to download using self_update crate from the existing https internet.
A hybrid approach may be possible.
A more community-driven approach may be possible where users source their own updates and do not depend on the vault automatically updating itself.
It may be desirable to add some kind of web-of-trust type features.
Reproducable builds may assist the security of the vault ecosystem. The relation between source code and binary is important but is out of scope for this RFC.
Unresolved questions
Should the process be known as update or upgrade?
Fault detection and rollback may be a significant aspect of this feature, but are not addressed here. This is especially tricky since some new features may be ambiguous, maybe seen as faulty inclusions or maybe seen as desirable inclusions depending on each particular vault operator (eg bitcoin segwit).
What can we learn from existing systems such as bitcoin and IPFS?
