So I tried feeding Claude all of MtGox's original (2011) sourcecode, git history and other relevant information, and asked for a report. Here's the result which isn't news for me but covers some elements that weren't public knowledge until now.
180 karma · joined March 25, 2020
For example at VP.NET we're using SGX 1, which uses AES-CTR for memory encryption which is not susceptible to memory reply attack, and comes with a limit of 512MB of ram. It's a lot of pain working with a very small memory allocation (especially nowadays where most machines come with 128GB+). batteringram.eu calls that "Client SGX" with a checkmark on "Read", but reading the actual paper it only mentions being able to know which areas of memory were written to (see 7.1). There might be applications where memory access pattern gives detail on the underlying work performed, but this is likely coarse (encryption is likely per page) and unlikely to yield to anything useful.
This said we are also exploring other TEEs including Intel TDX, and having a wider array of options will give us the ability to instantly disable any technology for which we know security has been compromised.
When the client connects to the server, the server presents a tls certificate that includes an attestation (with OID 1.3.6.1.4.1.311.105.1) which certifies a number of things:
- the TLS certificate's own public key (to make sure the connection is secure) - The enclave hash
It is signed by Intel with a chain of custody going to intel's CA root. It's not "just a magic number" but "a magic number certified by Intel", of course it's up to you to choose to trust Intel or not, but it goes a much longer way than any other VPN.
In an older version packets were sent back in sequence to their original connection to the host, as it was faster.
We since then implemented a system where nproc (16+) buffers receiving packets running at differed intervals, meaning that while packets are processed "in order" the fact this runs in multiple threads, reading packets even from the same client will cause these to be put in queues that will be flushed at different timings.
We have performed many tests and implementing a more straightforward randomized queue (by allocating memory, handling array of pointers of buffers, shuffling these, and sending these shuffled) did not make much of a difference in terms of randomization but resulted a huge loss in performance due to the limitations of the SGX environment.
As we implement other trusted environments (TEE) we will be implementing other strategies and obfuscation methods.
This whole process is already widely used in financial and automotive sectors to ensure servers are indeed running what they claim to be running, and well documented.
When the connection is established we verify the whole certificate chain up to Intel, and we verify the TLS connection itself is part of the attestation (public key is attested).
This guarantees that your traffic isn't being linked to you, and is mixed up with others in a way that makes it difficult for someone to attribute it to you, as long as you also protect yourself on the application side (clear cookies, no tracking browser extension, etc)
This allows generating a self signed TLS certificate that includes the attestation (under OID 1.3.6.1.4.1.311.105.1) and a client connecting verifying the TLS certificate not via the standard chain of trust, but by reading the attestion, verifying the attestation itself is valid (properly signed, matching measured values, etc) and verifying the containing TLS certificate is indeed signed with the attested key.
Intel includes a number of details inside the attestation, the most important being intel's own signature of the attestation and chain of trust to their CA.
The final signature comes in the form of a x509 cerificate signed with ECDSA.
What's more important to me is that SGX still has a lot of security researchers attempting (and currently failing) to break it further.
The US government also likely learned a lesson from early attempts at backdoors (RSA, etc) that this kind of things do not stay hidden and do not reflect well.
We've thought about this long and hard and planning to mitigate this as much as possible. Meanwhile we still offer something that is a huge step forward compared to what is standard in the industry.
A lot of people have been attempting to attack SGX, and while there have been some successful attacks these have been addressed by Intel and resolved. Intel will not attest any insecure configuration as do other TEE vendors (AMD SEV, ARM Trustzone, etc).
The way this works is the enclave on launch generates a ECDSA key (which only exists inside the enclave and is never stored or transmitted outside). It then passes it to SGX for attestation. SGX generates a payload (the attestation) which itself contains the enclave measured hash (MRENCLAVE) and other details about the CPU (microcode, BIOS, etc). The whole thing has a signature and a stamped certificate that is issued by Intel to the CPU (the CPU and Intel have an exchange at system startup and from times to times where Intel verifies the CPU security, ensures everything is up to date and gives the CPU a certificate).
Upon connection we extract the attestation from the TLS certificate and verify it (does MRENCLAVE match, is it signed by intel, is the certificate expired, etc) and also of course verify the TLS certificate itself matches the attested public key.
Unless TLS itself is broken or someone manages to exfiltrate the private key from the enclave (which should be impossible unless SGX is broken, but then Intel is supposed to not certify the CPU anymore) the connection is guaranteed to be with a host running the software in question.
What this tells me however is there are a lot of people trying to attack SGX still today, and Intel has improved their response a lot.
The main issue with SGX was that its initial designed use for client-side DRM was flawed by the fact you can't expect normal people to update their BIOS (meaning downloading update, putting it on a storage device, rebooting, going into BIOS, updating, etc) each time an update is pushed (and adoption wasn't good enough for that), it is however having a lot of use server-side for finance, auto industry and others.
We are also planning to support other TEE in the future, SGX is the most well known and battle tested today, with a lot of support by software like openenclave, making it a good initial target.
If you do know of any 0-day exploit currently live on SGX, please give me more details, and if it's something not yet published please contact us directly at security@vp.net
I do not think me being involved in a new exchange would help make money for creditors. I have provided counseling to other exchanges who asked me to on how to avoid repeating what happened with MtGox and tried to push as much as possible for MtGox creditors to get as much as possible. When I was due to receive over a billion dollar as share holder in the bankruptcy I also made sure everyone knew about it because switching back to a civil rehabilitation needed the support for most creditors and wasn't something I could do (since I'm not a creditor myself).
But of course if I can help in something more I'd be happy to. You will likely receive more than you initially deposited into MtGox through the bankruptcy, but I do not know what you call "significant recompense."
Also most creditors I have been interacting with have been thankful for the help and I do not think that many people still direct much ill toward me, at least it doesn't feel that way anymore, but that may have to do with the lack of death threats and insults on Twitter and such. I'm hoping everyone will be eventually able to move on, but first the bankruptcy must end, and CoinLab is preventing exactly that from happening.
I have been choosing my words carefully, even going as far as avoiding voicing my own opinion here and instead linking to some fact checking from another MtGox creditor. I will however still say that CoinLab and more specifically Peter is clearly abusing his position and using stalling techniques to force MtGox and creditors to accept a settlement rather than having the whole process taking many more years, effectively taking everyone hostage for his own gain.
Staying silent will not do anything for creditors, and CoinLab clearly do not have creditors' benefit in mind. I do think this is important to point out.