Contemporary encryption is practically unbreakable. Because of that, attackers don’t bother breaking it but look for ways to bypass it and still access users’ data. Whether these workarounds work or not, comes down to the implementation of encryption algorithms. Here’s what the methods are and why they wouldn’t work against Secure Group’s products.
Encryption workarounds are the topic of a recent paper by cryptographer Bruce Schneier and law professor Orin Kerr. The techniques they go over are all known because law enforcement has been using them – and the police need a way to justify and explain how they got hold of pieces of evidence in court. Criminals don’t have to report to anyone but, as the authors of the report note, can use the same methods.
Here are the top workarounds to encryption and the ways our products are devised to withstand them.
1. Finding the encryption key
The most obvious way to break encryption is to decrypt it the same way the user does – with the encryption key. The problem is how you get hold of that key. And the first way to do that would be to extract it from a place where it is stored. There are providers of encrypted communications solutions who store the keys of their users on their servers. It is common for servers to be compromised – giving ungranted access to thousands of encrypted communications.
Secure Group does not store user keys on its servers. In fact, the only place where those keys are stored is the user’s device. Our PGP email client Secure Email generates and stores keys only locally, while our chat and voice over IP clients – Secure Chat and Secure Voice, respectively – use ephemeral, per-session keys which are protected via the Diffie-Hellman key exchange. The keys never leave the device without being encrypted themselves and are destroyed after each use.
2. Guessing the key
The cipher used by our apps – 256-bit AES – uses, as you can guess, 256-bit keys. It is impossible for humans to memorize such long sequences of information. Hence, why modern cryptographic systems use two-step encryption – the key itself is encrypted with a PIN or password, which is what the user inputs into the device. Passwords are much easier to remember than long strings of random digits.
And they are also much easier to guess. There are numerous documented cases where law enforcement has unlocked suspects’ devices by trying out their birthday as a PIN. This is an informed guess – as would be popular passwords such as “123456,” “qwerty,” or the most popular one, “password.” The counter here is to have a really strong password – read here about how to come up with one.
3. Force to submit the key
The third way to get your encryption key is to force it out of you. In that case, it makes a huge difference whether you are dealing with law enforcement or with criminals. The police, for example, operates within the confines of the law, and the best way to approach your encounter is to cooperate – unless doing so violates your rights. Then you need a lawyer. Dealing with criminals who want to force you to give up your key or password is a much scarier situation.
How you react could literally mean life or death. As far as the data on your device goes, if it is a Secure Phone, there is a way to at least erase everything on the phone. You can do it via the so-called duress password – a phrase which you enter from the lock screen and wipes the device. The idea is to give you a chance to erase everything on the phone, while pretending that you are doing a simple phone unlock.
4. Exploit a flaw in the encryption process
There are two types of holes in cryptographic systems: backdoors and zero-day vulnerabilities. The former are intentional design flaws in the process that are supposed to give administrators elevated access to users’ data. Zero-day vulnerabilities, on the other hand, are just unintentional bugs or oversights that the developers don’t know about, but someone else found and told no one so they could exploit them.
Backdoors are something we at Secure Group are strictly against. Any holes in a security system – no matter how secret they are – could be exploited by malicious parties. This is a compromise we cannot afford. In fact, we have gone to great lengths to protect users’ privacy even from ourselves by not storing copies of keys or messages on our servers. And as far as zero-day vulnerabilities go, our solutions are all open source – and subject to constant peer review, which makes finding and fixing bugs fast and easy.
5. Access plaintext while using the device
Data is never in an encrypted state while the user deals with it. But attackers can still try to steal information by grabbing a phone out of a person’s hands, running away with it and keep swiping the screen to keep it unlocked. However, it makes much more sense to somehow install malware or tracking software on the user’s phone and have it record keyboard input or take screenshots of the plaintext messages.
To counter that, one must not get malware on their device. It is advised to avoid the shadier parts of the internet, to be cautious when opening emails, and to audit app permissions. But even with all these good practices, malware may find its way on your phone. This is why we disabled Internet browsing on Secure Phone – as well as several of the Google Services APKs. The combination of these two modifications closes the door for malware on the one hand, and guarantees there is no available data for it to mine, on the other. On top of that, Secure Chat doesn’t allow taking screenshots of messages.
6. Locate plaintext copy elsewhere
This is similar to the previous method – why bother with encryption when there are plaintext versions to access? Many services use encryption but how much security it provides boils down to implementation. What if plaintext copies of documents are stored in the device memory while they are being edited, and encrypted only after that? Or what if those temporary backups are stored in the cloud?
Secure Group’s implementations of PGP, OTR, and ZRTP have no such oversights. Every message that goes through our servers does so in encrypted form. Since we don’t store user keys, we cannot decrypt messages even if we wanted to. But we also don’t store the messages themselves – they are discarded as soon as they are sent from the server to the end recipient. No copies are stored on our servers. This applies for all of our encrypted communications apps.
Comments