Brendan Diaz
When HighSide does anything, we carefully consider the "threat model" to ensure we have eliminated 99.99% of the possibilities of data compromise. While I'd like to say 100%, unfortunately there is no perfect system - but with HighSide, our system starts with a metaphorical solid cement box. If your data were inside, it would be completely secure - however it would not be very usable. To give you access to your data, HighSide gives admins permissions and controls to "poke holes" in the box, but put bars on those holes, install security cameras, and even self detonate the contents of the box if needed.
In our blog series, Threat Modeling, we are exploring the various points of compromise that plague traditional networked file shares, cloud data management platforms and collaboration tools - and highlighting how HighSide's system mitigates those risks.
Today's focus is on encryption key management.
E2E encryption has been hailed as the savior for modern security teams trying (almost aimlessly) to protect their sensitive and regulated data. However, traditional implementations have really fallen short of a true security "silver bullet". The main reason? The centralization of encryption keys poses an existential threat (or centralized point of failure) for the entire system.
To this effect, eliminating a central point of failure in a private / public key system is a major enhancement to security. But how do you do that? You need to decentralized or distribute the private root of trust (or the private key material) so a single point compromise can't lead to a failure of the entire system.
In the HighSide system, this is exactly what's been accomplished. The HighSide decentralized key model has allowed us to eliminate the most common and pervasive forms of cyber compromise - be it phishing, escalation of privileges or direct EKM compromise. In HighSide's system, the local application generates cryptographically unique encryption keys. These keys are never shared with the HighSide server, a central repository, or team admins.
But, what about a physical device compromise you say? What if an attacker gains access to a users device? Couldn't they use these encryption keys to compromise the system? That's a great question! Let's dig in...
HighSide was carefully designed to prevent attackers and malicious insiders from making use of the locally stored encryption keys, even if they physically have access to a lost/stolen device, or the keys themselves.
Digging Into HighSide's Decentralized Encryption System
HighSide's platform is a multi-key system that doesn't rely on any one set of keys (including the unique keys stored & generated by a users local application) for protecting access to data.
In fact, by themselves, a user’s local encryption keys are almost useless, and have no ability to decrypt the HighSide data stored on their own device, nor to authenticate to their HighSide team and access, send or receive any additional data. This is, as some call, defense in depth - or layered security.
On both the desktop and mobile apps, locally stored sensitive data like message content or file transfers is encrypted not only with users’ keys, but also with an additional key that is controlled by the team and is stored in the server.
One might call it... a hybrid model!
After a user opens HighSide and authenticates successfully, the server sends down a “localStoragekey” to their device for the HighSide client to temporarily store in memory and use to read/write their locally stored data to disk. AES-256-CTR+HMAC is used for this operation.
Alone, neither the locally-stored user keys, nor the server-stored team key, can decrypt the data. Both keys must be used in conjunction.
This way if a device is lost or stolen, team administrators can easily block either that specific device, or the affected user’s entire account (and all associated devices), from being able to authenticate to the server and receive the local storage key.
This is also useful if a team administrator wants to use HighSide’s “Remote Wipe” feature. With remote wipe, if the lost or stolen device attempts to authenticate to the server, instead of sending down the local storage key, the server sends down a command telling the HighSide client to erase all messages, keys, and all other ancillary information. The wipe command is cryptographically signed by the admin and verified by the recipient.
In this way, local storage encryption can prevent an attacker who images the user’s hard drive from getting the message content even with the voluntary assistance of a malicious user.
“Unencrypted” Encryption Keys
A common question we receive is why HighSide’s user keys are stored in an unencrypted format locally on the device?
The answer is because there is no practical or useful way to encrypt them without introducing additional complexity and friction for HighSide users. The more complex and difficult a system is for its end users, the less secure it becomes in practice.
This fact is not unique to HighSide; from PGP/GPG to the highly sophisticated encrypted radios used by the U.S. Secret Service (leveraging a protocol called P25), keys are stored unencrypted on the devices.
Rather than adding impractical complexity for users, there are better and more efficient ways to address potential security risks associated with encryption keys being stored in an unencrypted format on the endpoints. But... we'll cover these in future Threat Modeling blog posts!
Still have more questions about HighSide's decentralized encryption system? Want to ask our cryptographers about local key storage or tunnel further into how things work? Just drop us a line here and we'll get something set up.
And... if you want some light reading on the HighSide protocol, check out this How it Works Whitepaper.