The Elephant in the Room: Security and Privacy Protocols in Security Tokens

Data security and privacy are two of the most sensitive aspects in the world of security tokens. Not surprisingly, it seems that we spend much less time discussing security and privacy protocols than other aspects of crypto-security architectures. When comes to security tokens, security and privacy protocols are not only a technically challenging and often intimidating subject but also one that can challenge the current foundation of crypto-securities. From all the aspects missing in the current generation of security token architectures, security and privacy are the ones I feel can break the premise of the entire ecosystem.

To understand the security and privacy challenges in the realm of security tokens let’s try to compare it to securitized products. Financial securities operate within trusted boundaries established between a relatively small number of centralized authorities. Hundreds of regulations under umbrellas such as GDPR, SWIFT, FINRA and many others are revised every year in order to ensure privacy and protection of financial security transactions. The premise of crypto-securities is to disintermediate many of those trusted boundaries using computation logic while remaining compliant with privacy regulation. For that to happen, many of the existing privacy and protection regulations need to be adapted to decentralized, blockchain-based protocols that were created to ignore centralized boundaries in the first place.

The notion of security and privacy in crypto-securities gets a bit worse when we factor in two key aspects:

a) Security tokens operate in blockchain networks like Ethereum in which privacy is a tier2 protocol in the best-case scenario.

b) Security tokens rely on known identities to be compliant with regulations such as know-your-customer(KYC) and anti-money-laundering(AML) which means that they don’t enjoy the anonymity benefits of cryptocurrencies.

To illustrate the privacy challenges in security tokens let’s use two common examples:

1. A tokenized asset issued in Germany is subject to data protection regulation that stipulates that is can only be traded between German parties and the data related to the trade cannot leave German jurisdiction.

2. An asset-based tokenized product needs to be compliant with FINRA privacy rules that enforces the protection of sensitive information related to any trade involving the asset.

The first scenario presents a friction between privacy and decentralization while the second highlights the conflict between privacy and compliance. Both scenarios are examples of a security token dynamic I like to call “The Privacy Dilemma”.

The Privacy Dilemma in Security Tokens

The challenges summarized in the previous section can be summarized in a simple mathematical dilemma: Security token architectures can be designed to optimized two of the following three capabilities: privacy, decentralization and compliance. That means that a security token runtime can be highly decentralized and private relying on protocols like ZK-SNARKS but won’t be compliant with certain regulations. Similarly, security token networks that focus on privacy and compliance are likely to sacrifice decentralization in some reward.

The privacy dilemma is one of those dynamics that will influence the next generation of security token protocols. By enabling privacy in crypto-securities, the friction between decentralization and compliance is

Solving Privacy in Security Tokens

Enabling privacy as a first-class citizen of security token architectures is going to be a long journey. I believe the first wave of privacy solutions in crypt-securities are going to be enforced off-chain followed by solutions that rely on trusted centralized authorities. After that, we are likely to see privacy solutions that rely on side channels to handle sensitive computations off-chain and, finally, we should see privacy protocols as native components of security token architectures.

On-Chain Privacy Protocols and Security Tokens

If we assume that privacy protocols are going to become a relevant building block of security token platforms, then we should take advantage of some of the incredible work the blockchain community have done in this area. Below, I’ve listed some of the privacy protocols that can play a role in the next generation of security token architectures.

· CryptoNote & Ring Signatures: One of the grandfathers of blockchain privacy, CryptoNote(CryptoNight) is the protocol behind Monero. Conceptually, CryptoNote leverages a cryptographic technique known as traceable ring signatures to obfuscate messages among a group of nodes in a decentralized network. Improvements in the CryptoNote protocol have proven able to produce high degrees of anonymity while operating at scalable levels. In the context of security tokens, CryptoNote can be used enforce privacy for specific portions of a security token exchange.

· zk-SNARKS: The protocol behind ZCash, zk-Snarks is a novel form of zero-knowledge cryptography that allows one party (the prover) to prove to another (the verifier) that a statement is true, without revealing any information beyond the validity of the statement itself. Since the launch of ZCash, zk-Snarks have been adapted on different blockchain technologies such as J.P Morgan Quorum. Security tokens can incorporate zk-SNARKS as a first class block to protect data in a security token transfer.

· zk-STARKS: Following our triangle thesis, one of the challenges of zk-Snarks is that is hard to be applied at scale as the complexity of the proofs scale linearly with the size of the database. Earlier this year, professor Eli-Ben Sasson from the Technion-Israel Institute of Technology published a highly-anticipated paper that describes a faster alternative to zk-Snarks which (to keep things confusing) he decided to call zk-Starks. From the paper professor Ben Sasson explains that “zk-SNARKs use public key (asymmetric) cryptography to establish security. zk-STARKs instead requires a leaner symmetric cryptography, namely, collision resistant hash functions, and thus removes the need for a trusted setup. These same techniques also eliminate the number-theoretic assumptions of zk-SNARKs (and BulletProofs) that are computationally expensive and prone to attack by quantum computers. This makes zk-STARKs both faster to generate and post-quantum secure.”

· TEE: Trusted Execution Environments(TEE) have emerged as a popular way to offload confidential computations in blockchain technologies. TEE technologies such as Intel’s Software Guard Extensions (SGX) isolated code execution, remote attestation, secure provisioning, secure storage of data and trusted paths for execution of code. Applications that run in TEEs are securely protected and almost impossible to be accessed by third parties. Security tokens can use TEEs to offload privacy computations from the core blockchain.

· Secure Multi-Party Computations: The protocol behind the Enigma blockchain, secure multi-party computations(SMC) is a cryptographic techniques that allows to execute computations against a set of inputs while keeping the inputs private. SMC can be used for parties in a security token exchange to trade assertions about information while keeping the actual information private.

Is Privacy a Tier2 Protocol for Security Tokens?

The current generation of security token platforms have minimum consideration for privacy and security. A foundational question to determine how privacy will evolve in the context of crypto-securities is to establish whether privacy will be a tier1 or tier2 protocol of security token networks. At the moment, most security tokens run on Ethereum which, as a network, does not have a privacy-first protocol. In my opinion, privacy is one of those aspects that challenges the viability of Ethereum as a runtime for security tokens. Can security token platforms include privacy protocols as part of their stack or do we need a tier1 privacy runtime?