Last Updated: May 15th, 2018
When you start Trillian on the desktop, a connection is made from your device to Cerulean's servers and authenticated with a unique Trillian username (your "Trillian Username") and password (your "Trillian Password") using our internally-developed instant messaging and presence protocol ("IMPP"). All IMPP connections are always protected with the industry standard Transport Layer Security Protocol ("TLS"). IMPP serves two purposes:
1. To expose a complete instant messaging environment including text IM, file transfers, voice and video, and visibility lists. For example, two people with Trillian can communicate using IMPP without the need for any additional third-party accounts.
2. To act as the synchronization engine between devices in the event that multiple devices are connected at the same time. For example, Trillian's continuous client feature relies on communication between your desktop and phone to keep chats in sync; this communication is done using IMPP.
Connections to third-party instant messaging service providers, when available, are made directly from your device to the third-party provider you choose to connect to. Many third-party providers now offer the option to use TLS when communicating with them, and Trillian uses TLS whenever possible.
When you start a version of Trillian on a mobile device, a connection is made from your device to Cerulean's servers and authenticated with your Trillian Username using our internally-developed, HTTP-based "Octopus" protocol. All Octopus connections are protected with TLS.
The purpose of the Octopus servers is to host Trillian sessions on your behalf and communicate with your device exclusively using the HTTP protocol. This eliminates the need for your mobile device to maintain connections to different IM services and provides additional resilience against both volatile network connections and the unavailability of application backgrounding on certain mobile platforms.
The environment that hosts the Trillian Services maintains multiple certifications for its data centers, including PCI Certification, and undergoes periodic audits under AICPA AT 101 (i.e., SOC 2 audits). Additional information about the certifications and compliance status of our data center operators, subject to confidentiality clauses, is available upon request.
Cerulean's servers are housed in SOC 2 Type II data centers within nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access datacenter floors.
All remote access to Cerulean's servers and devices is done using secure protocols like SSH and HTTPS. In addition, access to all devices for administrative reasons is firewalled when possible; for example, a public-facing webserver will need to open access to TCP ports 80 and 443, but the SSH port will be firewalled to an administrative IP range only.
Cerulean's employees are required to conduct themselves in a manner consistent with our internal guidelines regarding confidentiality, business ethics, appropriate usage, and professional standards. We conduct background checks on all new employees before employment and require that everyone reads and signs a confidentiality agreement.
Before onboarding Subprocessors, we conduct an audit of the security and privacy practices of the Subprocessor to ensure they provide a level of security and privacy appropriate to their access to data and the scope of the services they are engaged to provide. Once we've assessed the risks presented by the Subprocessor, they are then required to enter into appropriate security, confidentiality and privacy contract terms.
Cerulean's servers run a locked down version of CentOS Linux. We perform automated vulnerability scans on our servers and remediate any findings that present a risk to our environment. We also enforce screen lockouts and the usage of full disk encryption for all company devices, including laptops and mobile devices.
Cerulean has built and deployed a centralized logging solution for our production environment which contains information pertaining to security, monitoring, availability, access, and other metrics about the Trillian Services. These logs are constantly analyzed for security events by our security team.
In the event of a security breach, Cerulean will promptly notify you of any unauthorized access to your data. We have incident management policies and procedures in place to handle such an event.
All customer data is encrypted at rest via a combination of disk-level encryption (e.g., Bitlocker, LUKS) and file-level encryption (e.g., database-specific encryption methods). In addition, all communication to the Trillian Services is protected with TLS, and we follow two important practices when implementing TLS on both clients and servers:
1. When connecting to a server, clients attempt to check to ensure server certificates have been signed by an approved certificate authority. Clients also attempt to check to ensure that the name asserted by a server matches the name expected by the client. In the event that either of these conditions is not met, a warning is presented to you and the connection itself is terminated.
2. When possible, our clients and servers favor the use of key exchange mechanisms that provide the forward secrecy property, meaning that an attacker who compromises one of our long-term keys will not be able to compromise past TLS sessions. Our clients and servers always prefer the use of the latest recommended secure cipher suites and protocols to encrypt all traffic in transit.
Your Trillian Password is not stored in plaintext. Instead, your password is used as the input to the PBKDF2 HMAC-SHA1 key derivation function. The resulting 20 byte derived key is then stored on our servers for authentication purposes along with a corresponding 16 byte salt; the salt is unique to each user and to each password. We currently utilize 4096 rounds of PBKDF2.
Authentication happens in the following order:
1. The client establishes a TLS-secured connection to the server.
2. The client securely sends its username and password to the server.
3. The server looks up the salt and derived key associated with the username it received from the client.
4. The server derives a key using the password it received from the client and the salt it just looked up.
5. If the newly-derived key matches the derived key stored in the database, authentication succeeds.
We use key derivation so that individual passwords are unreadable by intruders (because the passwords are not stored in plaintext) and unusable for authentication purposes (because keys stored in the database are never sent to us directly by clients). The best method of breaking a derived key is therefore to brute force all possible password combinations, which should take a large enough amount of time that customers should have a chance to change their password(s) in the event of a security breach. We have the ability to increase the number of PBKDF2 rounds transparently to you, and we will continue to increase the rounds as our hardware improves, ensuring we maintain a reasonable balance between security and server performance.
When you choose to store third-party account information on Cerulean's servers, we first encrypt it with the AES cipher in CBC mode. The initialization vector is randomly generated by a cryptographically strong pseudorandom number generator and plaintext is padded according to PKCS #7. As a result of this encryption, in the event that you lose your Trillian Password you will also lose any stored third-party account information and need to recreate it.
We've chosen to use the same PBKDF2 key derivation method discussed in Section 2.6 for the purpose of generating a 256-bit AES key. When Trillian derives a key from your Trillian Password, 52 bytes of total data are derived. The first 20 bytes of data are stored on our servers and used for authentication as discussed in Section 2.6. The next 32 bytes are used as an AES key by clients and are not stored on our servers.