I’ve heard it said that Slack is the elephant in the room when it comes to security. From my personal experience, it’s very true. Unless one is very informed on security and takes privacy seriously there are serious security issues that arise from convenience.
When I worked for a digital agency, working across many different client projects, it was very common to get Slack messages with passwords. There are clearly better solutions to password management, but since there are agencies still not using them I thought that this would be a fun idea to run with.
Choosing an Architecture
An important step is determining the architecture with respect to user experience. I want my users to be able to easily encrypt data, their data can only be decrypted by specific individuals, and the owner of the data can quickly add or remove user’s access. Finally, as an application developer, I want a separation of concerns and don’t want to have the burden of maintaining encryption keys or controls.
The Versatility of the Trusted Data Format
The Trusted Data Format (TDF) is an open format to maintain cryptographic protections. Because the Virtru SDK is the easiest way to create and work with TDFs, this allows for data encryption with minimal development and allows my users to control who has access to their messages. These features enable me to develop to my UX needs and protect my user’s data since my application doesn’t have access to their encryption keys.
Since TDF is a file format and not a database the two types of architecture which need consideration are single-document (SDA) or multi-document (MDA).
Single Document Architecture
SDA would mean that the communication log would be stored in a single TDF document. The delivery of this document would be via streaming to all clients. The client would then be able to read and write to the stream.
As a technical advantage, a single document would mean increased speed, reduced disk space, and reduced bandwidth usage. From a usability perspective, granting or revoking permission to an entire conversation would be a single operation. Additionally, the conversation can be archived and exported without much effort.
Areas of weakness are the need to build in collision handling and ensure that the rendering on the client-side is ordered correctly. Since the encryption and data entry happens on the client-side there will also be concerns about data integrity and ensuring the messages have the correct timestamps, metadata, and user attribute. To build in this kind of data integrity check would likely take substantial effort. Usability is hampered with respect to historical access to messages and fine-grained control of messages. Users would not be able to determine, within the conversation, who has access to individual messages and could not revoke access to a specific message, such as a specific password. Lastly, since the conversation will be owned by a single person they become a bottleneck when new members need to join.
MDA means the communication log would be stored in multiple TDF documents. The delivery of these documents could be streamed or delivered as individual payloads.
Areas of technical advantages are that the meta-data, timestamps, and user attributes can be managed outside the TDF document. This allows for a lower overhead on infrastructure and a more familiar environment for developers. In terms of usability, a major advantage is that users could determine on an individual message level how they want their data to be shared.
The areas of technical concern are speed, bandwidth, client-side computing power, and meeting the users’ expectations of timeliness. From a usability perspective, if a new user wants access to previous messages each TDF will need to be updated. The same is true if a user needs to be removed.
Making a Decision
After considering the various architectures I decided to approach this with MDA. It is important to me that users can choose who has access to their specific messages. In the ideal case, some messages or conversations could be encrypted while others were in plaintext.
This brings me back to what spurred on this idea, the convenience of sharing passwords via chat. By using the MDA I could ensure that in the stream of a conversation a password could securely be shared and access management of a single message would allow users to share the password quickly with another trusted user.
Real World Use Cases
The usefulness of this architecture goes beyond convenience and slight improvements to security. This architecture would be extremely useful in any real-time communication where the parties need data privacy and control.
For instance, this could be used to power a real-time communication between a patient and their doctor while maintaining HIPAA compliance. Additionally, a specialist could be added for a time to give their opinion while limiting their access to only the necessary data and removed when their involvement is complete.
Coming up next…
In part 2 of this blog series, I am going to show the development of the chat application and how to integrate the basic Virtru’s SDK encrypt/decrypt methods and the sharing control. In part 3, I’ll show how to add additional controls and auditing so users can manage their data.
Don’t forget to follow Virtru for the next blog post in this series!