Security

Security has been an important consideration from the earliest days of Kchannels. As a Layer2 product, the system derives much of its security from its reliance on the Ethereum blockchain, and it also contains various other security features at the software architecture, code, and operations levels. Additional safety features are planned for the future to provide for a considerably secure environment without sacrificing UX.

Authentication and authorization

Since it exists in a blockchain context, Kchannels assumes its users control ECDSA keys just like those used in Ethereum (they may even be the same keys). Kchannels components also use such keys for cryptographic signatures and to identify themselves to users and to each other.

Keys (and their corresponding addresses) are used for authentication using a simple two-way authentication scheme that is similar to OAuth and SAML.

Kchannels employs component-level authorization, meaning that each component is in charge of authorization for the authenticated identity.

For more information, see Authentication and authorization.

Key management

Kchannels was written from the ground up so that there is no reason for private keys to ever be shared. This is true between our users and Kchannels, between users' own agents, and even between Kchannels' own components.

Every Kchannels components has its own Ethereum identity, which it derives from a very long random seed provisioned during deployment. The actual private key for it is never stored, is only handled in a few key areas of the code, and cannot be derived outside of the context of a particular Kchannels deployment.

Identity management

A component part of a deployment knows to trust another component part of the same deployment, by virtue of its Ethereum identity being present within the smart contract it is provisioned with. This makes it possible for one zone to trust another for the purposes of performing transactions, without the need to pre-share key pairs, or passwords. If a component key ever "leaks" and the corresponding identity stops being trusted, it is merely removed from the list of "approved" identities in the smart contract and the system will no longer interact with it.

Kchannels also has another feature for identity management that users will find interesting: the ability to delegate responsibilities for their channels. A channel definition allows an owner identity to independently delegate access to send and receive assets on its behalf, making it unnecessary for a user to use one private key for everything. The intention is to enable good security practices by allowing a user to delegate access to their individual devices, reserving the owner key for administrative (and thus sensitive) tasks such as renegotiating the channel.

Operational security

Kchannels makes extensive use of state machines to drive dialogue with users as well as internally between components. This works by binding security-sensitive operations such as an object being marked as validated, or channel balance being updated, to particular states that are being traversed in a predetermined sequence as part of a particular flow dialogue.

The state machines are the centerpieces of Kchannels' dedicated security tier, which is now responsible for the in-order, safe, and secure handling of user data. This is a well-known design pattern to improve security in applications.

One of the main state machines is for channels, and another for transactions.

Smart contract

At a few hundred lines of Solidity code, the current release of the smart contract can be considered small. This is by design, and it results in a small attack surface. The contract holds the assets of all Kchannels users, and its design is akin to that of a multisig wallet. It does not track title (ownership) of the stored assets; neither does it track channels. To function properly, the contract works in tandem with other deployment components such as zones.

The contract employs libraries of hardened code from OpenZeppelin, and it has been audited by ConsenSys Diligence.

With the release of the Dispute Resolution (DR) feature, the smart contract codebase is expected to grow in size and complexity. DR is a fundamentally important feature, and the system cannot by considered trust-minimized without it. With DR, a user will always have recourse to the Ethereum blockchain; if ever some or all of the backend were misbehaving on unavailable, he can choose to bypass it and withdraw his funds directly from the smart contract.

DR is also designed to play a significant role in a larger security and accounting mechanism aiming to quickly flag underbalance and overbalance situations, and thus provide a convenient window into the health of the Kchannels deployment.

This future version of the contact code will be audited by at least one group (and probably more) of auditors before release. The source code of the contract will also be made public to enable independent audits.

For more information, see the Smart contract section.

Security layer

The Kchannels MVP was created to implement the basic user experience of the system, so that users can see its benefits and take advantage of them as quickly as possible. It already has some significant security as illustrated above, but the "big guns" of security--dispute resolution and the security layer--are not currently present.

A security layer is something we plan to create as a deeper level of audit of transactions, as well as to make individual zones directly accountable to the smart contract for the assets under their control. It works both on a transaction level, meaning the security layer's signature is needed to perform a transaction, as well as on component level, meaning every component is made to report how it collectively handled all assets under its control to the smart contract. These reports are all put together at the smart contract to create a picture of the entire deployment. This means that the process to detect assets "created", "lost", or "unclaimed" within Kchannels and then track down discrepancies to a zone and transaction, becomes fully automated and periodic, and the result of that audit is readable at the smart contract for all to see.

The outcome from this is that Kchannels will have dedicated actors, isolated from the rest of the deployment, who aid the security features of the smart contract into making the deployment directly accountable to its users. Kchannels becomes tamper-evident.