Questions and slides from my "Tokenization in Blockchain" webinar

I upload the slides from my BrightTALK webinar “What is tokenization in Blockchain”? at https://www.slideshare.net/ulfmattsson/what-is-tokenization-in-blockchain-195523128 .

We did not have time to answer all questions during the webinar. The first unanswered questions from the live audience was:

·       What is the threat model/attack tree for your tokenization system? How would you tamper with/attack a tokenization system?

Answer:

For the vaulted solution from TokenEx, the tokens are mathematically unrelated to the underlying value to the most effective attack vector is through our customers. The tokens themselves cannot be attacked but the ability to detokenize sensitive data is only as strong as our customer’s environment and the controls they put in place to protect their API credentials.

In general, I’d follow protecting against attacks by using best practices for tokenization systems:

1.      The tokenization product should implement monitoring to detect any malfunctions, anomalies, and suspicious behavior.

2.      Mechanisms should be in place to ensure the integrity of the token-generation process.

3.      Critical functions (e.g., the API code) within the tokenization application must be protected by integrity-checking mechanisms (e.g., cryptographic integrity techniques, independent parallel processing with comparisons, read-only memory, or other high-assurance techniques).

4.      Only authenticated users and system components should be allowed access to the tokenization system and tokenization/detokenization processes.

5.      The tokenization product should have access and tokenization/de-tokenization logging functionality.

6.      Tokenization and de-tokenization requests should be logged and the logs should not contain PAN.

7.      Tokenization product should support multi-factor authentication for all user access to the tokenization product, including administrative access, tokenization and detokenization requests, maintenance, vendor access, etc

8.      Converting from a token produced under one system (or cryptographic key or noncryptographic process) to a token produced under another independent system (or cryptographic key or non-cryptographic process) should require an intermediate PAN state—i.e., invocation of de-tokenization. This assures that the old token is independent of the new token.

9.      Where the vendor uses cryptographic primitives, those primitives should be based on published national or international standards—e.g., AES or ECC.

The other question was “Its the blockchain or tokens viable for the quantum computing era, when each of silicon valley fishes own their functional quantum supercomp ?”

My answer would be:

·       It will take 3 years for NIST (US National Institute of Standards and Technology) to complete review of quantum safe algorithms (started in November 2017).

·       4-6 year from now for NIST Standards to be released. 3-5 years to produce new industry standards based on NIST algorithms from NIST Standards.

·       5-7 years for the industry to fully implement the new industry standards.

·       Full industry adoption could take 20 years from now. Guidelines for Immediate Steps that can be taken are Upgrade to AES, preferably AES-256.

·       Use SHA-512 for hashing. Use stateful hash-based signatures for signing, especially for protecting upgrades of firmware/cryptographic software.

·       Use hybrid cryptography to protect against both weaknesses in RSA/ECC and potential weaknesses in post-quantum algorithms.

·       Protecting Data in Transit: As of 2018, there were no large-scale quantum computers capable of cryptographic attacks.