Friday, November 27, 2020

Encryption and Zero Knowledge


While “email” is relatively flat:


They’re after an unusual target, these criminals aren’t after credit card numbers or bank accounts. They’re after financial statements and insider information, which can be used (pseudo)anonymously to turn a profit. This laser-guided-spear-phising meets insider trading; picture Martha Steward on a boat hunting sharks with a laser.

Now that we’ve identified a problem lets talk about solutions. After The Fappening, Apple quickly introduced encryption features to make this sort of attack much more difficult. Google wasn’t far behind, albeit with less egg on their face.

Attempts have been made to make email more secure. Google and Yahoo are working to secure their email infrastructure against both State-sponsored actors and cyber-criminals. Email’s security problems stem from a couple places but primarily it’s older legacy features. Email servers are intended to interoperate even if this means reducing security. This is common in scenarios where one server only supports an older encryption scheme and the other (seemingly) secure server falls back to the old protocol. Many of these old protocols have been demonstrated to be insecure whether intentionally or unintentionally.

Beyond securing data in transit data needs to be encrypted from end-to-end. This is generally what “Zero Knowledge” means, one user has a private key, another the public key, and a third party the data. A public key can often be derived from a private key, but not vise-versa. In order to compromise such a system one would need both the private key and the data.

Once a hacker has gained access to an email server they generally control both the keys and the data. Bugs like HeartBleed and ShellShock reminded us that there are many lurking security flaws out there. In systems that use end-to-end encryption such a breach would result in loss encrypted data, but not the keys to decrypt that data.