Tokenization, Digital Assets and why LinuxONE

In Part 1 of this blog, I covered the fundamentals of Tokenization, and some of the barriers to adoption. In this blog, I will take a deep dive into one approach for handling the security of tokenized assets. Let’s go through some of the approaches to address the security of digital assets and tokens:
Hardware Security Module
Hardware Security Modules (HSM’s) are dedicated components designed to hold, protect, and secure master crypto keys. Without HSM’s, encryption keys would be held in main system memory. When held in memory keys are vulnerable if an attacker breaches application security.
IBM HSM’s support a concept known as “cryptographic domains”. Secure keys generated and wrapped with the master key in one domain are not usable by another domain using a different master key. Humans are prevented from keying in these extremely sensitive keys through domain separations in hardware.

HSMs are well proven in the financial services industry, but they are still not common enough. Moreover, HSM’s vary a great deal in quality and capabilities. IBM Crypto Express HSMs are special because they are certified to FIPS 140-2 Level 4 standards. There is no other commercially available Level 4 HSM. There are significant differences between Level 3 and Level 4 certified HSM’s.

While Level 3 HSM’s respond to tampering with their doors or covers, they can still be attacked through other paths.  It’s like securing your doors and windows, only to have an intruder drill through the floor below.  In banking, should a Level 3 HSM be breached, new keys would be generated and transactions reversed. However, reversing transactions is not possible with digital assets, once the private keys are revealed the wallet can be emptied.
When an IBM Level 4 HSM is attacked by probing, chemical, voltage, electromagnetic, or temperature, it self-destructs. For example, in a cryogenic attack where the HSM is frozen to slow down the electrons, the Level 4 HSM will destroy the keys as soon as the threshold is exceeded. The same applies in instances where an x-ray proton beam is used to flip bits.  Furthermore, it is IBM’s policy to destroy any tampered HSMs, rather than try to repair them and re-encapsulate them in a protective enclosure.  This policy assures that the devices are protected from the time they leave the manufacturing facility to the time they are destroyed.
It is common for some vendors to replace the native HSM operating system with their own. Many HSM vendors add wallet and multi-signature signing capabilities beyond managing a master key. These firms are becoming OEMs by replacing the operating system. These firms will also not certify these aspects of their HSM under FIPS 140-2 criteria. Often these firms certify only the enclosure. IBM believes that HSM’s should protect the master key, and anything else represents a larger attack surface. IBM’s Crypto Express 6S memory is designed to last 30 years without failure. It is not uncommon for other HSM vendors to manage cost by installing memory with an MTBF of months not years. When it comes to performance, HSMs are not built like CPUs and do not have extra I/O that would help keep the operating temperature down. The service life of these jailbroken HSM’s may also be reduced when under heavy loads for transaction signing. The greatest restriction is when an ECC needs to be updated due to a vulnerability or a new ECC should be deployed or deprecated. Responding to these events may be delayed by the HSM release and standard maintenance cycles.
These issues could go away if the HSM protections were extended into protected, encrypted memory and these actions could be done simply by taking a Docker container offline and making the software update.
Running in protected memory would also for all the smart contracts to execute as if they were logically inside a FIPS Level 140-2 Level 4 HSM. These smart contracts could perform all sorts of capabilities from wallet upgrades, blockchain forks, coin swapping (like ERC-20 to EOS), Proof of Stake staking, as well as running key stores. Key stores deployed as Docker applications can be taken offline into an encrypted persisted state in the form of cold storage or brought into memory but not accessible as a warm wallet, or entirely online as a hot wallet. Each of these Docker applications is running in an encrypted Hyper Protect Virtual Machine (HPVM) as an appliance. When persisted they are wrapped again by another layer of encryption. HPVMs run inside the Secure Service Container (SSC) which is a 16TB logical partition that provides a third layer of encryption.
Secure Service Container: 16 TB of encrypted, protected memory.
The IBM Secure Service Container (SSC) is like Fort Knox for Crypto. Isolation, encryption, protection, privacy, confidentiality: these are the fundamental security requirements for crypto exchanges. Many crypto exchange attacks are due to compromised root user credentials made possible by phishing, wallet address redirects, container exploits, and architectural flaws in software design. Once you become a root user in Linux you can do anything, you could look at any data.
The entire cryptosystem is deployed into the IBM LinuxONE trusted execution environment. The SSC not only encrypts all data in flight and at rest, but it also encrypts the keys used to encrypt the data, and stores the keys in a tamper responding Hardware Security Module (HSM). To protect against insider threats, there is no command line access, no operating system Root access, no ability to run scripts or introduce new contents into the container. Even a memory dump will only provide encrypted data, so no insider attacks are possible with Secure Service Container. The appliance automatically logs encryption activity and decryption attempts, so it is audit-ready and tamper responding.
True Random Number Generator
Cryptographic algorithms rely on random seeds. Pseudorandom number generators are flawed, allowing attackers to identify and exploit patterns (in what should be random numbers) in order to break encryption. True Random Number Generators (TRNGs) stop this class of attacks. IBM LinuxONE systems incorporate built-in TRNGs into the processor cores. The TRNGs are designed to support the most demanding cryptographic security requirements.
Firmware Tamper Protection
IBM LinuxONE systems comply with National Standards and Technology (NIST) Special Publication 800-147B and raise an alarm if anyone attempts to tamper with firmware booting. Dedicated Hardware Management Consoles support multi-factor authentication (per IETF RFC 6238) and separate role-based security profiles. These dedicated HMC’s prevent operators from exceeding defined responsibilities.
Logical Partitions
IBM LinuxONE is designed for Common Criteria Evaluation Assurance Level 5+ (EAL5+) certification. This is achieved through the use of logical partitions (LPARs). An application in one operating system image in an LPAR, cannot access an application running on a different operating system image on another LPAR. LPAR’s enable separation of application elements, database components, into strictly defined, isolated security zones.
Time Source Security
Accurate timekeeping is a critical element in maintaining security. Timekeeping is vital for checking and rejecting expired credentials and certificates. Some exchange attacks have taken advantage of poor clock synchronization. IBM LinuxONE systems incorporate high-quality system clocks in redundant form, with continuous, automatic error checking. This allows for the isolation and removal of any failed clock component before it produces an inaccurate time.
Even the highest quality clocks require synchronization with the world’s most trusted time bureaus. LinuxONE systems are equipped with Server Time Protocol (STP), a system feature that makes regular inquiries with trusted time bureaus. STP can also check the validity of time information using symmetric key and Autokey authentication per IETF RFCs 1305 and 5906, to assure that time messages are not falsified or altered. STP also helps the system handle the periodic leap seconds that global time standards mandate.
How you secure your Tokenized assets is vital if you want to get into the Asset custody or Tokenization space. IBM is your partner as you embark on this journey. For more information on how LinuxONE can help click here.

One thought on “Tokenization, Digital Assets and why LinuxONE

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.