Introduction

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

Key management [3] is implemented with a Hardened Security Appliance (HSA) provided by the AWS Key Management Service (KMS) [4].

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 [5]. 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 [6] 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 [7] for a detailed description of the KMS HSA operation.

VPN

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 it@sameroom.io.