MagicalTux

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.

Battering RAM has been demonstrated to work well against Intel's "Scalable SGX" which is also known as SGX 2, and uses static encryption key to allow SGX to use more of the system's memory.

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.

The SGX certificate is signed by intel and includes a certification of the hash of the code loaded in the secure enclave ("MRENCLAVE").

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.

The comment was added before the implementation of the IPC buffer & shuffling and was left there, sorry about that.

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.

Similar to TLS, the attestation includes a signature and a x509 certificate with a chain of trust to Intel's CA. The whole attestation is certified by Intel to be valid and details such as the enclave fingerprint (MRENCLAVE) are generated by the CPU to be part of the attestation.

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.

Intel SGX comes with an attestation process aiming at exactly that. The attestation contains a number of details, such as the hardware configuration (cpu microcode version, BIOS, etc) and the hash of the enclave code. At system startup the CPU gets a certificate from Intel confirming the configuration is known safe, which is used by the CPU to in turn certify the enclave is indeed running code with a given fingerprint.

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 is the server-side part of things. It receives encrypted traffic from your (and other customers) device, and routes it to the Internet.

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)

The way this works is by generating a private key inside the enclave and having the CPU attest its public key.

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.

Let me clarify, it guarantees your connection is being served by the enclave itself. The TLS encryption keys are kept inside the enclave, so whatever data is exchanged with the host, it can only be read from within the secure encrypted enclave.

You're welcome to use cryptocurrencies (we have a page for that), and our system only links your identity at connection time to ensure you have a valid subscription. Your traffic isn't tied to your identity, and you can look at the code to verify that.

Intel audits configuration on system launch and verifies it runs something they know safe. That involves CPU, CPU microcode, BIOS version and a few other things (SGX may not work if you don't have the right RAM for example).

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 might be able to pressure Intel into doing something with SGX, but there are way too many eyes on this for it to go unnoticed in my opinion, especially considering SGX has been around for so long and messed with by so many security researchers.

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.

Yes crypto payments, a bit difficult to find since you need to look at the bottom of the page however, but we have some plans to improve that in the coming days.