Andrei Soroker, Peter Hizalev
Updated: February 2016.
Sameroom provides real-time interoperability between different instant messaging systems, such as Skype, Google Hangouts, Slack, HipChat, Fleep, and so on. The service requires the creation of “Tubes”—bridges between group or contacts in various providers—by using the Sameroom dashboard.
Because Sameroom interacts with different communication services on behalf of the user, it must store user credentials for each connected service, either in the form of an authentication token (OAuth), a security token, or a username and password combination.
The necessity to store such sensitive information means security is one of the key design goals for Sameroom. This paper explains the details behind various architectural and procedural decisions that address data security.
Sameroom does not have any provisions for persistent storage of message data. This means all questions concerning the safeguard of message histories fall entirely on service providers.
Sameroom never retrieves message history, working exclusively with data arriving in real time. Sameroom never writes messages to any persistent storage. Messages reside in RAM for a short time required for transmission across user-configured connections.
Data Security—Cryptographic Details
AWS KMS operates by establishing a domain as a cooperative collection of trusted entities (trusted entities are HSAs and human operators) within an AWS region. The Sameroom HSA is located in the us-east-1 region, US East (N. Virginia).
A domain includes a set of trusted entities, a set of rules, and a secret key, called the domain key. This key is shared through a domain state export routine—this state can be imported into any HSA within the domain. The domain key is rotated daily, to ensure compliance with NIST Recommendation for Key Management—Part 1 . This key is shared among all HSAs within the domain.
During daily domain key rotation, all existing HSA keys encrypted under the outgoing domain key are re-encrypted with AES256 GCM  under the new active domain key. HSA keys are rotated annually, with deactivated keys preserved to decrypt old ciphertexts. An HSA key is used to encrypt the data key with AES256 GCM and, optionally, additionally authenticated data (AAD).
A separate data key is issued to encrypt the credentials of each Sameroom account. The corresponding AAD includes an immutable account identifier. The per-account data key is used to encrypt the plaintext of account credentials with AES256 CBC. The resulting ciphertext and the data key ciphertext are combined into an envelope, which is stored in the Sameroom database.
HSA and data keys are never stored in plaintext. The keys are only available in plaintext (in RAM) very briefly, to perform the cryptographic operation. Encrypted data keys are only stored in the Sameroom database. Encrypted HSA keys are only stored within the AWS KMS and are never exposed outside the KMS. See  for a detailed description of the KMS HSA operation.
In addition to encrypting account credentials, Sameroom uses EBS encrypted volumes to store database files. EBS encryption uses AES256 XTS  and the Sameroom KMS HSA described above. See  for a detailed description of EBS encryption.
The Sameroom network and production environment are only accessible by personnel with appropriate security clearance, through a Virtual Private Network (VPN). VPN keys are never transmitted over the network.
Reporting Security Issues
If you find any security concerns with the Sameroom platform, please send your report to firstname.lastname@example.org.