Security concerns regarding Gluon and TEA

>Thanks for the application. It looks like you put a lot of effort into it, but to be honest I have a lot of concerns regarding the sharing of private keys. There are a lot of things that could go wrong (e.g. hardware, software or sybil attacks). I personally think that the combination of the Recovery Pallet with a nicer UI and promotion might be a better approach. Would you be interested in working on something like this? Regarding the application itself, it would be nice if you could focus on KSM or DOT instead of BTC.

Hi David, thank you for your comments. Your concerns are absolutely within my expectation. Believe it or not, almost everyone asked the same questions when they heard our project for the first time. Bear with me, and my answers could be pretty long. Please stay calm and read till the end. I bet you are not wasting your time by reading the detail, considering we have spent years on this project dealing with all possible attacks.

Since you have not specified which attack you care about the most, I would like to explain most attacks we have dealt with.

Hardware

TEE is the most common solution for trusted computing. Although there are side-channel attacks that exist, I still consider it one of today's best solutions. We choose a very different approach not because TEE is not secure, but trying to make it a much larger scale.

You can see the differences from the diagram above.

Instead of putting a secured enclave into (part of) a computer, we put a minimized computer into a secure enclave. This enclave is an HSM (hardware secure module, such as a hardware crypto wallet). Since it is a minimized computer, code can run at a native speed without frequent encrypt-decrypt between trust and non-trust zone. Data only need to encrypt when leaving the mini computer.

Is the TCB(Trust CodeBase) too big to protect?

Inside our HSM, there is a “minimized” computer. This computer is not a general-purpose computer like a PC or Mac. It is more like a hardware crypto wallet that can do much more. We are developing a special-purpose Linux OS with one goal — securely loading the waSCC (wascc.dev) based WebAssembly runtime. Everything else not related was ripped off. For example, the keyboard, mouse, video, USB are all gone. The only external IO is the Ethernet. The final product could have only one power port, one RJ45, and one LED, nothing else. A “so-called” black box. (Can we still call it a Tea Box?)

All custom code and some system code are running inside the wasm running. WebAssembly is a better isolation solution for both performance and security. Code running inside wasm runtime can hardly do any damage to the system. We also have TPM to check and load trusted wasm modules that have been verified by blockchain consensus.

As a black box with minimized OS and minimal outside interface, the most effective network attack could be DDoS and Sybil attacks. I will explain those in later sections.

If anything is modified within the HSM, no matter it is a file change in the OS or a UEFI hash not matching. The TEA node cannot pass the blockchain consensus verification and is isolated from the rest of the network. The TPM guarantees this.

Is TPM secure?

TPM protects the box itself with the self-destroy feature, which will be trigger by brutal break activities. Once destroyed, no data can be recovered. To do this, there is a backup battery installed.

TPM is nothing new. The computer you are using right now has one TPM chip on the motherboard. The technologies have been with us for almost 20 years. We did not pay enough attention until it jump front to stop us from doing some “funny” things. This is exactly how MS Windows or Apple knows you or a virus changed the BIOS/UEFI/Bootloader and refused to boot the OS. (Note: Apple is using similar technology but not directly follow the TPM standard from Trust Computing Group TCG)

We used TPM to generate the hashes of all loaded components and stored them into PCR. Those hashes and all runtime check-ups are all called PoT data(Proof of Trust), stored on the blockchain and sent to verifiers upon consensus request. Our consensus (also called PoT: Proof of Trust) determines a TEA node is running well or compromised. Compromised nodes will be highlighted on the chain and quarantined from the rest of the good network. There will be a financial penalty for attacking or bad maintenance caused compromise. We will explain the financial part later.

Is the hardware expensive? Can I utilize my existing computer as a mining machine?

TPM itself is very low tech and low power chip. Since our code runs at native speed. There is no performance penalty on security caused by cryptography. Any computing device can be used as a TEA mining machine as long as it can install TPM and provide PoT to get verified by blockchain consensus.

We are using Raspberry pi with a Nations Tech TPM as our testing machine. The Pi cost about $30, the TPM may cause less than $10 retail (probably $1 if OEM). The most expensive part is the custom made enclosure box. Of course, the box is just a rigid box that looks cool, nothing related to technology. Since we do not need HDMI, USB, GPU, Audio. If we can mass-produce such an ARM-based mining machine, the cost could be less than $20 per unit. Compare with the basic Bitcoin miner machine today, see the price gap.

Of course, you can run TEA on high-end computers to make more profit in the competition. Or special-purpose computing devices to run special tasks that require such hardware capabilities. An AI machine with TPUs, an FPGA hardware algorithm accelerator, or some IoT devices equipped with a temperature sensor and GPS, etc. The price varies but not because of TEA.

Your existing or retired desktop can be used as a TEA mining machine too. It will need to run the mini OS. It can no longer be used as a regular computer. It turns into a black box that makes money for you.

Hardware performance compare with today’s blockchain

If we pick any task that today’s highest performance blockchain can do and run it on the $20 Raspberry Pi TEA mining machine, you will find it runs much faster! This is not magic. The only reason that our consensus — PoT goes a very different approach. We do not consent to the result but the execution environment. This is similar to TEE, such as Intel SGX. The differences are that we need consensus on the blockchain, but Intel is centralized. If you trust Intel, everything goes smoothly. We do not require you to trust anyone but the blockchain consensus.

If you watched our milestone 1 demo video, you would see we run a Tensorflow AI algorithm to recognize a picture of a lion on our blockchain. You know it is tough for a regular blockchain to run an AI algorithm. We have made it.

Fake TPM

Every TPM has an endorsement key burned into the chip when manufactured. Unless the manufacture intended to produce faked TPM chips, it is almost no way to fake TPM chips. This is almost like the Ledger makes hardware wallet with malicious code built-in, or Intel makes CPU with a backdoor to steal user secret. I highly doubt this would happen.

Software

Once your TEA node starts running, you still physically own it, but technically you do not. The TEA consensus fully controls the node. The consensus decides what code to be installed, run, or removed on your node. Any attempt to alter the hardware or software will cause the node quarantine and loss of your deposit and credit score.

The software is carefully designed to use many zero-knowledge and modern cryptographic algorithms to increase the cost of a successful attack. The full design doc could be very long. I will list a few examples to explain.

Delegation Chain

No one knows what task is done by which node. We designed “Delegation Chains” to scrambled or encrypted such knowledge. From outside of the HSM, we can only see encrypted traffic in and out from a TEA node to other TEA nodes. There is no way to determine if a TEA node is running a valuable task. Even the size of traffic and destination IP address won’t expose too much useful information. By doing this, attackers can hardly distinguish the high-value targets from those idle ones. In most cases, we run BFT or similar consensus for higher-value tasks. Even some TEA nodes are compromised and not quarantined in time, the damages and chances are minimal. This knowledge will be released to the public only when tasks are done and posted on the blockchain. At that moment, all traces have been wiped out. There is no value to attack an empty node. Use the Gluon Wallet as an example: Assuming there are thousands of nodes running. Unless you can hack into 2/3 of those nodes simultaneously, you probably won’t get any useful data. Given all TEA nodes are running different hardware architectures, it is not that easy to find a common vulnerability.

Never Store Secret Persistently

The TEA node HSM does have storage (SD, SSD, HD), but only executable code and non-secure temp data are allowed to save to the storage. All secrets will stay in the RAM of all running nodes. It can transfer between TEA nodes when encrypted. When entering the destination node, the secret is encrypted and stored in RAM only. When any reason causes the TEA node to lose power, no secret remains in this hardware unit. It needs to run the secure “Repin” protocol to reconstruct the secret from other healthy nodes. Because every secret has many replicas on many “repin nodes” at any given time, there is a meager chance that a secret is lost forever. This design eliminates the chance that any secret is stored in an abundant hard drive.

Network

We currently run our network communication based on the IPFS libp2p protocol. We choose Libp2p because we happen to use IPFS as our blob data storage. The communication between TEA nodes is end-to-end encrypted. No matter IPFS nodes, or any sniffer will get the content. A nonce is also used to defeat man-in-the-middle attacks.

DDoS

From my point of view, DDoS or Sybil attacks can never be avoided in the long run. What we can do is duplicate. There will be many TEA nodes running in the network. From the outside world, due to zero-knowledge protection, they all look the same. It is tough to identify any valuable target to attack. As long as less than 1/3 TEA nodes down due to DDoS, our network won’t get affected.

Sybil Attack

TEA nodes only talk to other verified TEA nodes. Based on the TPM hardware protection mentioned above, a bad actor cannot pass the remote attestation unless more than 2/3 TEA nodes are compromised. Although TEA node is generally less expensive, getting a piece of hardware won’t cost much, but having it pass remote attestation is not an easy job.

Code Injection

If attackers try to convert a good node into a bad actor, the only way is to inject malicious code or alter existing code. This will cause the chained-up hash value mismatch with PCR records, therefore cause the remote attestation failure. The only way to pass remote attestation with compromised code is to hack the TPM chip. TPM is designed to be very simple and stable. It is not too much to be hacked in such simple silicon.

Gluon Wallet Specific Concerns

Among all TEA projects, Gluon is one of the simplest. It sounds scary because it stored private keys. However

• We use the Shamir Secret Sharing Schema to split the private key into pieces. Each piece store as multiple replicas in many distributed nodes. No one outside of TEA HSM knows which node stores which pieces of which private key.
• Due to replicas, it is unlikely of all replicas of k in n pieces are lost.
• Key generation and reconstruction are done within an unpredictable TEA node. No one knows when and where it is reconstructed and sign the transaction. Please refer to the zero-knowledge session above.
• For the social recovery feature. Who are assigned recovery friends is also zero-knowledge to the outside world until the social recovery actually happens. Once it happens, it is released to the public. Because social recovery is a one-time-use disposable solution, it doesn’t matter release to the public. Of course, we will suggest the user choose other friends to recover his new account.
• We are researching the replacement of the Shamir algorithm. So far, we did not find a high-performance algorithm yet. We can replace it once we find one. As long as we can find a higher performance BLS, Unbounded similar algorithm can be used practically. We will eliminate the only change to reconstruct the private keys to be much more secure.

There are too many design details to be explained here. If you have more specific concerns, we can continue the discussion. I hope we can find any threat model out of my preparation to improve our security design. I hope my explanation can make you less stressed about Gluon Wallet Project.

Thank you very much