ZeroDark.cloud vs AWS Encryption
I was recently asked about how ZeroDark.cloud does data-at-rest protection compared with AWS Server Side Encryption.
Its a good question that goes to the root of what zero-trust and zero-knowledge means. Let’s start with a quote from the AWS documentation:
When you use server-side encryption, Amazon S3 encrypts an object before saving it to disk in its data centers and decrypts it when you download the objects.
…As long as you authenticate your request and you have access permissions
And there it is. Your data is uploaded un-encrypted (even it’s wrapped in TLS on the way) and the server is responsible for encryption.
Everything depends on you setting things up properly. But ultimately, AWS holds the keys and manages them based on access permissions. Even if the keys are stored in a hardware security modules (HMS), AWS still has a copy of the keys and they dole them out based on proper access credentials.
There is a lot that go wrong…
Even if you employ some form of 2-Factor authentication, the credentials are still vulnerable to insider attack.
Most incidents were caused by insider negligence. Specifically, the careless employee or contractor was the root cause of most incidents reported. The most expensive incidents are due to imposters stealing credentials and were the least reported.
— Cost of a Data Breach Report, conducted by the Ponemon Institute.
The ZeroDark.cloud alternative
In contrast, the ZeroDark.cloud framework automatically performs encryption on the data you sync to AWS S3 bucket before any of it ever leaves your device. Only your devices and those people you explicitly share with, have access.
Here is how ZeroDark.cloud encryption works:
- When you create a ZeroDark.cloud user account for the first time a ECC Curve41417 private/public key pair is automatically generated on your device.
- The binding between your user identity (social ID) and your key is self-signed into your key and that public key is uploaded to the ZeroDark.cloud server.
- The server then adds an entry to the Ethereum blockchain, binding the public key to that customer. Mitigating man-in-the-middle attacks.
- Each object, any associated metadata, thumbnails, and attributes you upload to the cloud is protected with a separate, randomly generated, ThreeFish 512-bit key. Even the filename is encrypted and never exposed.
- Similarly the objects names in the cloud are created by a cryptographic pseudo random number generator (PRNG)
- The 512-bit file encryption symmetric keys are then encrypted to each user that you share the file with using the ECC Curve41417 public key algorithm in a form of ECC–DH Encryption. Similar, but not exactly compliant to ANSI X9.63, we produce a random key, hash it, and XOR the digest against the file encryption key.
All of this is done for the app developer automatically. They don’t need to have extensive cryptography knowledge. They don’t need to spend months obtaining AWS expertise or risk fumbling AWS credentials.
They just need to make the API calls to ZeroDark.cloud to map their data. Inform the framework when they change something. The rest is done for them, including all the push notifications and data syncing.
True zero-trust
AWS or the ZeroDark.cloud serverless code never has ability decrypt the objects or the object metadata that your sync to the cloud. This is why it’s called a zero-trust zero-knowledge system. No amount of credential fumbling will make your data vulnerable.
More information and details can be found:
ZeroDark.cloud Cryptography white paper
To find out more about ZeroDark.cloud:
- ZeroDarkTodo sample code
- ZeroDark,cloud website
- Docs (high-level discussion of the framework, how it works, what it does, etc)
- API Reference (low-level code documentation for the framework)
