Symphony and “Responsible Encryption”
The FBI has raised the alarm that cutting-edge encryption technologies enable criminals and terrorists to shield their wrongdoing from detection and investigation. To prevent wrongdoers from “going dark,” they have urged those who manufacture digital systems to engineer mechanisms to ensure law enforcement access to encrypted records.
Privacy and civil liberty advocates, including groups worried about the security of our digital infrastructure, have raised concerns that any solution that weakens strong encryption will hopelessly compromise the safety of our digital information from the prying eyes of hackers and thieves.
Symphony is a strongly encrypted, cutting-edge communications and content sharing platform. Recently, FBI Director Wray has highlighted Symphony as a model of “responsible encryption” that solves the problem of “going dark.” He has cited agreements between certain Symphony clients and the New York State Department of Financial Services (“DFS”) that require storage of encryption keys with a third party. As one might expect, the FBI’s statements have generated commentary—sometimes critical—about the Symphony model. We are pleased to be recognized for creating a responsible, strongly encrypted communication system. We are also proud that our platform puts control over security firmly in the hands of our customers, without backdoors or other features that undermine the security of our clients’ data.
Because this topic has gained national attention, and because much of the commentary raises good questions, but may misstate how Symphony operates, I’d like to review Symphony’s security model and the DFS agreements.
How Symphony Encrypts Data
Symphony encrypts its messages end-to-end, an approach demanded by sophisticated, security-sensitive institutions, especially in financial services. Symphony came about in the wake of security concerns about inappropriate access to confidential data by financial messaging vendors. And these issues echo in the current controversy about data harvesting. These are concerns which could only be addressed by strong encryption where the vendor - in this case Symphony - cannot read its clients’ data.
Unlike conventional cloud-based communications platforms like Slack and Microsoft Teams—which are not end-to-end encrypted and therefore expose customer data to potential compromise on the cloud—messages on Symphony’s enterprise offering remain encrypted the full time they are on the cloud, and are not visible to Symphony’s cloud servers. And unlike “bring your own key” cloud platforms—where customers upload their key to a vendor’s platform where it becomes vulnerable to compromise, Symphony does not have access to the keys or contents. This makes Symphony much more secure than conventional cloud platforms, and therefore attractive to institutions that care a lot about security.
End-to-end encryption is commonly used in consumer-oriented secure messaging apps like Telegram. The security model in Symphony Enterprise is similar, except that the encryption keys are stored in an on-premise key management device, rather than on individual smartphones.
Symphony uses standard cryptographic algorithms widely trusted in the security community: AES-256 as a symmetric cipher, RSA-2048 for asymmetric key exchange, SHA-256 for hashes. As is normal for end-to-end encrypted applications, Symphony also uses TLS as an additional layer of protection for data in motion, and storage encryption for data at rest, on top of the end-to-end encryption that is applied to all messages and content before they leave the client.
A hardware security module (HSM) is the leading current technology for institutions to store encryption keys, and our recommended solution. Symphony doesn’t manufacture HSMs, but the ones we support are available with certification under FIPS 140-2, level 3.
Clients typically install the HSM in a secure datacenter, with the physical controls you would expect in a financial institution’s datacenter (man traps, guards, cameras, etc). An HSM itself has physical and environmental tamperproofing, and the cryptographic processor inside the HSM allows the key to be used, but not to extract the actual key itself. Since each bank operates its own HSM, even a successful attack would only compromise a single organization’s keys—and would likely be detected.
Standard HSM units support creating an offline backup copy of the keys on a secure hardware unit called a Backup HSM. This device can be stored in an offsite archival facility, along with other critical records and data that a firm would maintain for disaster recovery. The data on the Backup HSM itself is encrypted, and cloning or using keys stored in a Backup HSM requires use of the appropriate cryptographic credentials. This unlocking would typically be done by a group of key-holders using a combination of a hardware token and a PIN code (usually an “m of n” process would be used where a defined quorum of key-holders must approve).
Encryption key management functions, like backing up a key, are normal features any user of strong encryption needs. Without being able to back-up a key, if you lose the key, you would lose access to all of your data.
Not losing your data is important for enterprises, but also in the consumer space, which is why consumer-oriented messaging apps also employ key management features.
Symphony/DFS Custodial Arrangements
Now, on to the agreements. The DFS has reached custodial agreements with its regulated clients. These are voluntary agreements between the regulator and financial institutions. Symphony is not party to the agreements. In fact, Symphony didn’t modify its encryption model to support this.
Under the agreements, firms use their ability to create a secure backup of the key and give access to that backup to a 3rd party custodian. This process is entirely under control of the institution.
Access to the backup key is controlled by possession of the physical key backup, and participation of the key-holders in the unlocking process: the custodian would control access to the backup device and token owners. It is essentially the same technical process that would be used to restore a backup in the event of a disaster, except that the third-party custodians do the unlocking.
The agreements allow the banks to select their custodians, often a trusted law firm. Furthermore, access to the key can be split across custodians, requiring multiple custodians acting in concert. No regulator or government agency is the custodian. Nor does Symphony gain any key access.
The regulator must follow legal due process to obtain the encryption keys from the third party custodian. In parallel, the regulator would also need to follow legal due process to obtain the encrypted messages stored by Symphony. If this scenario were to ever unfold, neither the third-party custodian nor Symphony could read the messages. Only the client and the DFS would have access to both the encrypted data and the encryption keys.
From a privacy and security perspective this process actually meets the critical requirements of a secure system:
- Symphony doesn’t have access to encryption keys or data of its customers. This is the fundamental premise of end-to-end encryption, and Symphony delivers on this core principle.
- This model is not based on a backdoor: there is no surreptitious entry point. A customer knows that their custodian has access to their key because they gave them access to the key.
- There is no single point of entry—no single location where all of the keys can be accessed. So the system is not subject to systemic compromise through the custodial process.
- The cryptographic algorithms used in Symphony haven’t been altered to facilitate access. Symphony uses standard, well-tested cryptographic algorithms in the normal ways that they are designed to be used.
- Legal due process is followed. To obtain access, the government must follow due process. The custodians in a DFS agreement are typically a financial institution’s own outside law firms.
Each regulator has different requirements, and the DFS model used with Symphony is mainly notable because of how it uses encryption to control the access mechanism—not because the regulator has a legal process by which they may obtain an institution’s records. We are happy to support the national dialogue and offer our expertise in how this applies at a broader scale.