Secure access to the IC
This article started as a response to a recent post by Point Network (PN), but it may also serve as background information to recent Tweets about ECDSA integration on the Internet Computer (IC) and its use for integration with the Web technology stack.
Reading the chain
One aspect mentioned by PN but often neglected in web3 is authenticity of data obtained from a blockchain. Traditionally, there have been three options:
- Run a full node: A full node replicates the entire blockchain, validates and executes transactions. Running a full node is somewhere between a significant effort and a serious investment; it is not an option for average users and impossible on mobile devices or within web browsers.
- Use a light client: Some blockchains (e.g. Bitcoin, Ethereum) support light clients that retrieve and validate parts of the blockchain but not all transactions. While light clients require less resources than full nodes, they still need to keep up with the chain. For most chains, that again rules out mobile devices and definitely web browsers.
- Trust a third party: Most of today's "web3" applications instead depend on either centralized services like Infura or RPC endpoints of individual blockchain nodes. This, as rightfully pointed out by PN, of course undermines claims of decentralization.
The Internet Computer instead uses threshold cryptography. In a nutshell, you can think about this as the IC having a single signature public key. Messages from the IC are cryptographically signed, and clients can validate the authenticity of those messages by validating the signature. This validation can easily be performed on any contemporary device, and the only required state is the IC's public key, which can easily be distributed with software.
Of course, there is a lot more happening under the hood. Threshold cryptography ensures that the private key is securely shared among (a group of) nodes, and creating a signature requires contribution of 2/3 of the relevant nodes. Chain-key cryptography ensures that the public key remains the same even when network membership changes. Subnet delegations and Merkle trees provide tools for scalability. But that all doesn't change that the client only has to validate a signature against a known public key.
Accessing the blockchain from a web browser
Web browsers do not communicate with blockchains natively. So how does one equip a web browser with this additional functionality? There are two main options:
- Have the user install additional software on their devices. That additional software can communicate natively with the blockchain, and – in the case of the IC – it can contain the IC's public key. We have ongoing internal work on a Firefox Web Extension that validates the signatures issued by the IC. A community project called IC Naming provides extensions for several browsers that resolve ".icp" names. Installing additional client software is the approach that PN promotes, apparently bundling a (light?) node with a customized Firefox browser.
- Provide access for plain browsers in the best possible way. The software necessary to interact with the blockchain is served into plain web browsers without the need for pre-installed software. This "bootstrapping" inherently depends on existing browser security mechanisms, which severely restricts the design space for solutions.
The two approaches serve different user bases: Users that (use one of the supported devices/operating systems/browsers and) are willing to install additional software on their systems will have the best-possible security with the first approach. Users that do not want to jump through additional hoops will still be served by the second option. Note that PN states that they provide a web2 gateway, so they think about the second group of users, too.
HTTP gateways to the IC
As described by PN, the main method of accessing canisters on the IC is through URLs such as https://5ba5l-caaaa-aaaag-qaoja-cai.ic0.app. The .app namespace is owned by Google, the .ic0.app namespace is owned by the DFINITY Foundation, and DNS records for that namespace are (currently) managed through Cloudflare. Certificates for .ic0.app are obtained from Let's Encrypt. Thus, in its current state, this particular method of accessing the IC is not really decentralized.
Future plans for HTTP gateways: Near-term work
Some ongoing and near-term work eases the dependency on .ic0.app by supporting:
- Custom domains: Access a dapp such as DSCVR through dscvr.one, this is obviously possible today.
- Alternative gateways: Access any canister via its canister id under an alternative domain, such as https://5ba5l-caaaa-aaaag-qaoja-cai.example.com.
These efforts will remove the single dependency on .ic0.app; they provide redundancy but do not fundamentally change the nature of HTTP gateways.
Future plans for HTTP gateways: Longer-term work
Accessing a blockchain through an HTTP gateway has three aspects that carry centralization risk:
- The DNS system, as each TLD, with all domains below it, is controlled by a single entity.
- The PKI system, as each CA can per-default issue certificates for each domain.
- The delivery of initial assets into the browser through an HTTPS connection, terminated by a single server.
All of these are solvable, and for each of these the threshold ECDSA functionality that will be rolled out on the IC in the coming weeks is an essential component. Yet none of these problems are easy to solve, even given threshold ECDSA:
- DNS: Effectively requires the use of a TLD, since for any other domain there is a single entity (the owner of the TLD) that controls the domain. (Yes, ICANN controls the namespace of TLDs, but they at least have a pretty sophisticated process unlikely to get hacked.) The DNSSEC records for a TLD could be signed using threshold ECDSA signatures.
- PKI: Once threshold ECDSA is supported, building a decentralized CA is actually not hard. What will likely be harder is getting the CA accepted by major browsers. Note that DNS enables restrictions on permitted CAs through CAA records, so once a decentralized CA is accepted by browsers, its use can even be enforced.
- HTTPS: Browsers nowadays require HTTPS connections. Two approaches we are actively exploring are decentralizing HTTPS serving by thresholdizing it, and serving assets that can be signed out-of-band through signed HTTP exchanges.
In each of these longer-term plans, threshold ECDSA is a crucial component. Each of these will improve security of access from plain browsers in a different, valuable way. At the same time, solving each of these still requires significant additional effort.
Conclusion
Providing access through additional software (such as a web extension on the user's device, or a mobile app that wraps a web browser) or by serving the assets directly into a plain web browser are not contradictory; they are complementary. They serve different user bases with different needs for security and interoperability. This is true for any blockchain, including the IC.
At this level of comparing additional software with plain browser access, I do not see a contradiction with PN – I do see different strategies in developing both options and different strategies in interoperability with vs. separation from web2. And that's perfectly legitimate.
As far as I understood, PN intends to serve dapp front ends from their own chain but have them interact with smart contracts on other chains. If that is true, it still seems difficult to validate the outputs of those smart contracts. The IC's threshold signatures make that type of validation easy – even in standard browsers; whether via a Web Extension or by code served through HTTPS, and on any device. That seems to be the fundamental difference.
And so, just to answer the question posed in the title of PN's post ("Is Point Network a Threat to Internet Computer ($ICP)/Dfinity?"): No, it's not. (Nor is it doing anything that the IC cannot do today.)