Security Tokens and Shortcomings in Security Protocols

Big Brother is watching?

When it comes to security tokens, privacy and security of data are of paramount importance. Perhaps largely due to the much discussed decentralised aspect of cryptocurrency and the apparent benefits this can bring, we often neglect to properly delve deeper into privacy and security protocols. Instead, the focus has remained focused on other aspects of crypto security.

Security tokens are a thorny subject. There’s a high level of technical difficulty associated with them, making them a challenge for developers. Held under close enough scrutiny, security tokens can mount a red flag against crypto security in general. While many aspects are lacking with the current era of security tokens and their architecture, it’s arguably privacy and security that are the most obvious in their shortcomings.

Comparing security tokens to securitized products

In the realm of crypto securities, a foundation premise is disintermediation of such trusted boundaries, while still ensuring activity is both compliant and in line with privacy regulation. In order for this to be achieved, a great swath of current protection and privacy regulations must be tailored to adhere to the decentralized nature of blockchain protocols.

Things become even more complicated when we consider that security tokens use Ethereum and similar blockchain networks, where a tier2 protocol is often the top-tier available in terms of privacy. Worst still, known identities are required in order for security tokens to fall under compliance with standard regulations. Chief among these regulations are KYC (know-your-customer) and anti-money laundering. As such, key draws of cryptocurrencies including anonymity can’t be realised.

The problematic implications of privacy in security tokens

It’s clear to see that security token architectures by design optimise some capabilities at the expense of others. As a general rule, only two out of three of the key capabilities of security tokens are ever optimised at any one time. These capabilities are decentralization, privacy and compliance.

For example, if a security token scores top marks for privacy and decentralisation, it’s likely to fall short of compliance with regulations. Likewise, decentralisation will suffer if a security token priorities privacy and compliance. The pattern might be simple to predict, but it’s no less frustrating. Nonetheless, this thorn in the side of security token architecture is likely to be a key area of focus and development with the next era of token protocols.

The issue of privacy and security tokens

Privacy protocols in an on-chain context

Take for example, Secure Multi-Party Computations. This is the protocol behind the blockchain known as Enigma. Secure Multi-Party Computations, otherwise known in its abbreviated form of SMC, allows for computations to be executed against inputs while maintaining the privacy of said inputs. It can be utilised in an exchange of security tokens in the context of trade assertions, while ensuring information shared remains private.

CryptoNote is another key area of focus for the future of security protocols. This is a stalwart of blockchain privacy as a whole and perhaps better known as the protocol at work behind Monero. With CryptoNote, traceable ring signatures are used to make messages on a decentralised network unintelligible. Particularly promising about CryptoNote is the success its demonstrated when scaled up, maintaining an impressive level of anonymity. When thinking about security tokens, it can be utilised as a way to ensure privacy during parts of an exchange of security tokens.

ZCash’s protocol, zk-SNARKS, is another one to watch. This protocol is a form of zero-knowledge technique that allows for one party to demonstrate to another that a statement is correct. However, in doing so, no further information is divulged. This protocol has been readily adapted by various blockchain technologies since its launch, while security tokens can effectively incorporate the protocol as a way of protecting data during a security token transfer.

It’s not all been good news for zk-SNARKS, however. In the case of zk-SNARKS, scalability has proven difficult. In short, it has proven hard to scale significantly due to the relative complexity involved. A much quicker alternative to the protocol was suggested in early 2018 instead. This alternative, dubbed zk-STARKS, approaches the perceived issue of zk-SNARKS usuing asymmetric cryptography as a means to establish security. Instead of this, zk-STARKS incorporates symmetric cryptography, a much linear alternative. In particular, it utilises hash functions that are collision resistant, negating the need to have a trusted setup for functionality. What’s more, these techniques remove the incidence of costly assumptions of the protocol and reduce the risk of attack by third-party quantum computers. The result is a protocol that’s not only faster than its predecessor, but also secure against attackers in a post-quantum context.

Looking forward

Find more information and keep up to date at