Permissioning

Access to SETL’s blockchain is through an online GUI or through API calls. Any request through either route is subject to permission checking by the Wallet Node that the user is connected to. Users are only able to view and interact with data to which they have permissioned access. SETL deploys role-based permissioning. This means that rather than each user having to be individually configured, a number of template roles can be set up and users are assigned to one or more of those roles. Where roles have conflicting permissions, the least permissive will apply.

Online Access, OpenCSD

For GUI access, users log in through a secure web application, OpenCSD. Users authenticate using username/password, two factor authentication or industry standard token schemes.

The secure web application comprises both server-side and client-side code. Communication between the two is encrypted by use of an HTTPS connection and is also encrypted at the application level using symmetric encryption initiated via a Diffie Hellman key exchange.

Any request made from the client side needs to be accompanied by a session token which is be granted when the user authenticates. The session token will expire after a set period of inactivity.

The server side of the application runs a number of sentinel or lookout processes designed to detect and block malicious activity.

Users are presented with an app which allows them to create transactions, examine balances and create and execute contracts on the blockchain. All interaction is subject to permissioning.

The primary means of communication between client and server side of the app is by WebSocket.

RESTful Access

Users are able to interact with the blockchain via a REST interface which requires an API key.

The API key makes an initial request for a session token. It is an option to receive the session token fully in the HTTPS response or partially via a callback. All requests via the REST interface are made using JWS standard calls HMAC’d (signed) using the API key, although the key is never transmitted in any request.

Calls made by the user are accompanied by a session token, which will automatically expire after a set period of inactivity.

The server runs a number of sentinel processes designed to detect and block malicious requests submitted via the API endpoints.

All interaction via the RESTful APIs are subject to permissioning.

WebSocket Access

Users are also able to interact with the blockchain via secure WebSocket connections.

Users will require a WebSocket API key to establish a connection and will be granted a session token.

On establishing a connection, user will be required to undertake a Diffie Hellman key exchange to allow all data passed through the socket to be encrypted using symmetric encryption techniques.

All calls made via the socket will require a session token which will expire after a set period of inactivity.

Calls made through the WebSocket API are also permissioned.

  • User Nodes (or Audit Nodes)

SETL does not require a user to run a node to participate in its distributed ledger. Users can interact with the SETL blockchain environment using the GUI or using API access – both to put data onto the blockchain and to retrieve it from the blockchain.

For a richer interaction with one of SETL’s blockchains, a user can deploy the SETL Connect node which maintains a live segment of the blockchain in the user’s own environment. SETL Connect also provides a rich graphical low-code environment that allows the user to orchestrate activity and build private workflows around the SETL blockchain environment.

The SETL Connect environment has a wide range of built in tools for general messaging (bespoke, ISO and SWIFT), API management, database access and file management to allow users to easily interface with their own systems forming a bridge between internal systems and the SETL blockchain environment. Workflows constructed in the SETL Connect environment can be packaged as apps and distributed internally or externally and run by other users of SETL Connect.

  • Connected Private Environments

Core to SETL’s proposition is that certain information is private to certain parties but must be maintained in a manner which is consistent with a global ‘golden record’. This gives rise to the classic inter-ledger problem where a party maintains a global balance centrally and a private record of client balances locally. SETL deals with this by allowing private ledgers to be linked via witness nodes to form networks of communicating private chains.

  • Communicating Private Chains

Communicating private chains are a collection of blockchains where each blockchain is privately run by an organisation or parties trusted by that organisation. The chains can send and receive assets from other chains. Under this arrangement, SETL blockchains can be configured such that information held on each blockchain is only accessible to the organisation that runs it – i.e. all the nodes are controlled and run by the owner organisation.

Technically, each of the chains are linked via witness nodes which are specialist nodes which can transmit transactions between chains. Witness nodes can transmit to chains which they are linked to but cannot see transactions or balances on the receiving chains – i.e. they are one-way gateways onto other chains. A Witness node will be owned and controlled by the sending chain so that any information it is privy to is still within the bounds of the controlling organisation.

An example configuration is shown below. Under such a configuration, the financial manager’s client positions are known only to the manager while its aggregate position is known to itself and to its custodian or sub-custodian. Similarly, the CSD knows the custodian’s aggregate position but not the underlying beneficial owners of the securities – which are on the blockchain of the custodian or the sub-custodian. In effect, the privacy model is identical to the model currently in place in the financial services industry.

image0

Privacy Profiles

Blockchain privacy generally falls into 3 categories

  • Organisational

The strongest form of privacy is to organise data transmission so that data does not get passed to participants who are not permissioned to see it.

  • Cryptographic

Cryptographic schemes allow for more widely distributed data on the basis that data is encrypted in a manner which can only be read by permissioned participants. Other participants may be able to perform some useful function without decrypting the data. Such operations are called homomorphic. Whilst such schemes are provably secure at the moment, it may be possible for participants to save information and decrypt it in years to come as certain cryptographic protocols are breached.

  • Behavioral

The weakest form of privacy is practiced by many of the public blockchains. Under these schemes, all participants see everything but do not know the identity associated with any particular public key. However, identity can often be extracted using out of channel information and statistical analysis. Under such schemes, users are encouraged to adopt behavioral techniques – such as one time key use – to obscure their behavior.

SETL’s Approach

SETL has opted for the strongest privacy model where data is only distributed to parties that have a right to that data.

The scheme described above mimics and is modelled upon the existing infrastructure for maintaining ledgers of ownership. Each of the blockchains is private with all of the nodes on each chain being controlled by a single party. Transactions and balances on each of the blockchains can only be seen by the controlling party (a party might be a set of independent infrastructure providers).

Transactions between parties are transmitted in a manner that updates the intermediate ledgers of the sub-custodian, the custodian and the CSD as required. At each level, only the bulk holding of the subsequent level is maintained – again analogous to the existing approach.

The method allows for the issuer to query the location of the assets within the network with such queries being authenticated and permission being in the control of each chain.