Brendan Diaz
According to the March 2020 ITAR encryption addendum, ITAR regulated data stored or transmitted in the cloud must be “end-to-end encrypted” (E2EE).
In order to properly satisfy this rule, E2EE encryption requires that the keys used for encryption and decryption be stored locally on the endpoints, not on a server or a key management system.
This is because “in-transit + at-rest” encryption, and “enterprise key management” systems, are not equivalent to end-to-end encryption.
With in-transit + at-rest encryption, or an EKM, the means of decryption are provided to intermediary servers, effectively breaking E2EE and introducing unnecessary security vulnerabilities, single points of failure for mass data breaches, insider threats and more.
In-Transit + At-Rest Encryption
When encrypting data in-transit (ex. TLS), data is encrypted between an endpoint and a server; upon reaching the server, that data is necessarily decrypted. The server may then re-encrypt the data “at-rest,” but this is almost useless because the server necessarily has the decryption key. Similarly, with a key management system, in order for the encryption and decryption to take place on the server, the keys must be shared with the server (even if only temporarily).
Inherent to the concept of server-side encryption, these keys could be retrieved by a determined attacker or a malicious insider. With this type of encryption architecture, the data is fundamentally not end-to-end encrypted between the endpoints, introducing both security vulnerabilities and noncompliance with the ITAR encryption rule.
End-to-End Encryption
Conversely, with E2EE, the encryption and decryption keys never leave the endpoints. Any servers or cloud infrastructure used to store and relay data functionally operate as switchboards, routing data from one location to another without ever having access to the keys nor the means to decrypt data.
HighSide: True End-to-End Encryption
With HighSide, all messages and files that flow through the applications and server infrastructure are 100% E2EE from the originator to the recipient. This means that all encryption and decryption takes place on the endpoints.
In order to encrypt and decrypt data locally, HighSide encryption keys are generated and stored on the device and are never sent or shared with a server or key management system. This is well documented in HighSide’s security whitepaper, as well as in the “HighSide's Distributed Private Root of Trust Cryptography Explained” blog post.
“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.
Local Keys Threat Model
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.
HighSide’s “localStorageKey”
First and foremost, it is important to note that HighSide operates a multi-key system that does not rely exclusively on users’ locally stored encryption keys for protecting access to data.
In fact, by themselves, a user’s keys are almost useless and cannot be used 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.
On both the desktop and mobile apps, locally stored sensitive data like message content 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.
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.
Admin-Forced MFA
If an organization is concerned that an attacker may gain access to, and then attempt to load a user’s keys onto a new device, admins have two ways to block this attack.
The first is with admin-forced multi factor authentication. Admins can automatically block attackers from authenticating to the server and receiving the required localStorageKey by requiring all users to configure one or more forms of multifactor authentication.
In this scenario, even if an attacker is able to steal a user’s local keys, unless they are also able to pass multiple MFA challenges, the keys are effectively useless.
HighSide’s MFA system has brute-force protections, and additionally, failed attempts to pass the MFA challenges (unusual behavior) can alert a team that a user’s keys may be compromised.
Device Management/Device Authorization
The second option for teams concerned about user keys being loaded onto new devices, or for teams concerned with malicious insiders attempting to exfil data, is to use HighSide’s “device authorization” feature.
With device authorization, admins can require all newly connected devices to be approved by an administrator before they can authenticate to the server and receive the required localStorageKey.
With this feature, if someone tries to load a user’s local encryption keys onto a new device, whether legitimately or maliciously, the device will be locked out by default and must be manually approved for use by the organization.
In this way, organizations can maintain complete control over what devices have access to sensitive company data (ex. only allowing company-controlled, up-to-date and secured devices), and can proactively prevent attackers from making use of stolen encryption keys.
Questions? Concerns?
From lost or stolen devices, to attackers with physical access to the local encryption keys, HighSide was designed to not only meet ITAR standards, but to defend against these threats and protect your organization’s data.
HighSide’s security team is happy to answer questions about the threats outlined above, as well as to help map HighSide’s key protections against your organization’s unique needs and threat model.
Please do not hesitate to contact us with any questions or concerns!