Securing Automated Decryption

In this article, we are writing about how to secure automated decryption, based on Nathaniel McCallum’s presentation at DevConf 2017.

One thing is certain, the security of our data is one of the most important things in this digital day and age. We always had a plan to protect our data, but as time changes, that plan has to change as well. Yesterday we had standards that gave us the base of the protection. Today we try to automate the protection, so it can be more secure and problem free. And for tomorrow, we have to come up with policies which allow us to scale the layers of security.

Automation can be a bit problematic. First, we have the data, which we are trying to protect with an encryption key, but we also need to encrypt that key with a password. We have to communicate with a server but of course, mutual authentication on both ends of the connection is needed as well. We might also need a trusted third party to help securing the data exchange, and we definitely need backups, otherwise, we are risking data loss. Despite all this, we might still have to face the heartbleed problem, which is an OpenSSL cryptography bug that results in more data read than what is allowed, so our data is still not secure. With every layer of protection, we introduced a new point of vulnerability. To solve this problem, “We're gonna need a bigger boat”, as it was stated in the movie Jaws.

The goal was to protect the information exchange, but what if we wouldn't even have to protect it to keep it safe? We could use asymmetric encryption for the keys, like the Diffie-Hellman key exchange. This protocol is a method to generate a shared private key for two computers, and with that the users can exchange data safely over an insecure medium without compromising any prior secrets. The shared key is not transmitted but computed on both sides. The transmitted information just seems like random data, cannot be used for decryption by a third party.
But wait, there is an even more secure way than the asymmetric encryption. It is the McCallum-Relyea key exchange, which is an advanced version of the Diffie-Hellman key exchange algorithmThe first half of the algorithm works just like the Diffie-Hellman exchange, but after that, it literally “throws away the key”, the shared key is only used for additional computation. It computes with additional variables, which look even more random to the outside world. The client stays completely anonymous to the server and there is absolutely no encryption needed when this seemingly random data is transferred through TCP or UDP connection. 

When creating this algorithm the main focus was on data protection, so McCallum and his team laid the foundation for that. They created a protocol called Tang, and with its client-side sidekick Clevis, it implements a network bound encryption. In other words, Tang uses the McCallum-Relyea exchange to protect the data on the connected devices on a secure network.

We are already in the planning phase of the future, so let's talk about how the policies could help us with data security. The idea is based on the Shamir's Secret Sharing algorithm, which divides the secret into several separate parts, but we only need some of them at once for unlocking. For example, if the threshold is two, we are only required to have two parts to get to the data. The simplest case would be the authorization for a computer, the user can log in with a password, but the admin has a different password, which works just as well. Here the threshold is one, so we only need one out of the two secret passwords.

Now let's see how the sliding scale of security works in a corporate environment. Companies want to secure their data any way they can, so they need multi-factor authentication. Let's say the company has Tang for drive protection, password and fingerprint identification for the user, and connection to the Bluetooth network as well, but only two of those are required at the same time. If we are connected to the corporate network, so we are at work, we would only need one other step, like a password. 

But what if we leave the premises? We would surely need stronger security, like password and fingerprint at the same time. That is where the scaling came in, the farther we go from a secure hub, the more security we need.

As we can see it, the security professionals, like Nathaniel McCallum, are working hard to ensure, that our data is safe. There is always room for improvement, but I can safely say that we are in good hands.

If you have no more queries, 
take the next step and sign up!
Don’t worry, the installation process is quick and straightforward!
AICPA SOC BitNinja Server Security
Privacy Shield BitNinja Server Security
GDPR BitNinja Server Security
CCPA BitNinja Server Security
2024 BitNinja. All Rights reserved.
Hexa BitNinja Server SecurityHexa BitNinja Server Security