Tuple’s Security Details

As a remote control application, we recognize the importance of excellent security practices. While we are a small team, we work hard to punch above our weight on security.

This document covers our security practices and policies. If you are interested in the data we collect and store, please see our privacy policy.

General practices

Access to servers, source code, and third-party tools are secured with two-factor auth.
We use strong, randomly-generated passwords that are never re-used.
Employees and contractors are given the lowest level of access that allows them to get their work done. This rarely includes access to production systems or data.
We use automatic security vulnerability detection tools to alert us when our dependencies have known security issues. We are aggressive about applying patches and deploying quickly.
We don’t copy production data to external devices (like personal laptops).

Access control and organizational security

Personnel

Our employees and contractors sign an NDA before gaining access to sensitive information.

We perform a penetration test through a third party annually. The latest assessment concluded that “the security posture of the Tuple platform was found to be in line with industry’s best practices.” If you’d like a full copy of the results, send us an email.

Authentication

At sign-up, each customer is given an invite link to share with their team. Each team member can use that link to set up a new account with their email and password. User passwords are hashed using bcrypt before being stored.

When a user logs in, they are given a 20-byte authentication token, generated with the SecureRandom tool in the Ruby Standard Library. The token is invalidated after 30 days of inactivity.

All further interaction with the API is done by providing an Authorization header with this token.

Media Servers

Tuple hosts our own media servers in multiple regions on AWS:

us-east-2 (Ohio, USA)
us-west-2 (Oregon, USA)
ap-southeast-2 (Sydney, Australia)
eu-west-3 (Paris, France)

Media servers are only used when 4 or more participants are on a call. They are responsible for relaying end-to-end encrypted audio and video data.

Encryption

Definitions

Data - Clicks, keystrokes, drawings, animations, etc.
Media - Video (webcam and screenshare) and audio

All data and media during a 2 or 3-person pairing session are sent peer-to-peer (avoiding our servers) and are encrypted end-to-end.

All data during a call with 4 or more participants are sent peer-to-peer. Media is sent end-to-end encrypted and relayed through our media servers.

When we say “end-to-end”, we mean it in the way you’d expect: your data and media is not (and cannot be!) decrypted by anything other than the clients involved in the call. Stated another way: the only people that can see anything that happens in a pairing session are its participants.

Data channels in peer-to-peer connections are encrypted using Datagram Transport Layer Security (DTLS) version 1.2, while media streams are encrypted using Secure Real-time Transport Protocol (SRTP).

When there are 4 or more participants on a call, encrypted media streams are relayed through our servers using SRTP. Each frame in the stream is encoded using AES-256 encryption. Keys are randomly generated by each participant and are never reused. Keys are exchanged using peer-to-peer data channels over DTLS. We do not store any user media on these servers. Our servers never have access to the keys and cannot decode any media.

All communication between the Tuple client and our backend is encrypted with TLS 1.2. Our backend server is managed by Heroku and uses their Automated Certificate Management service. User data is stored in Heroku Postgres and details of their implementation can be found here.

Metadata about app usage and pairing sessions are stored in Mixpanel using their API. Details of their security processes can be found in their Security Questionnaire.

Data flows

All logged-in users are connected to a signaling server using the WebSocket protocol.

When a Tuple client wants to initiate a call, it sends an “Offer” through the signaling server and identifies the recipient of the call. The server then pushes that message to the intended recipient. The user on the receiving end will be prompted with an incoming call and can accept or decline. If the user accepts, the client sends an “Answer” and the peers then negotiate an encrypted connection. The peers exchange keys directly through an encrypted tunnel. The keys are never sent in plain text.

In most cases, both peers will be able to identify addressable IPs and ports on which to establish a peer-to-peer connection using the STUN protocol. Under some restrictive firewall configurations, this is impossible and traffic must be routed through an intermediate server using the TURN protocol. We use Twilio’s Network Traversal Service in this case. These servers cannot decrypt the contents of the data packets, and only route based on the UDP layer. Under no circumstances does video, audio, keystrokes, cursor movements, or clipboard data pass through our servers when using the TURN protocol.

Architecture diagram

Tuple topology

Data retention/logging

Logs are stored separate from our backend infrastructure in a private CloudWatch area.

These logs are retained for 30 days, after which they are permanently deleted.

Application analytics can be permanently deleted on request.

Software development practices

Code written by any developer is signed off by at least one other person before committing.
Code is tested in a staging environment against a QA checklist before deploying to production.
The Tuple client is code-signed with our Apple developer ID and has the Hardened Runtime mode enabled (which protects against code injection, DLL hijacking, and process memory space tampering).
The Tuple client is automatically scanned for malware and notarized by Apple on every deploy. See Apple’s notarization service for details.

Vulnerability detection

Both the client and our backend are regularly scanned for dependencies with known security vulnerabilities.

Vulnerable dependencies are patched and redeployed rapidly.

Hosting

Our backend server is hosted on Heroku, which runs on top of Amazon Web Services.

Amazon’s data center operations have been accredited under:

ISO 27001
SOC 1 and SOC 2/SSAE 16/ISAE 3402 (Previously SAS 70 Type II)
PCI Level 1
FISMA Moderate
Sarbanes-Oxley (SOX)

FAQs

Does my code pass through your servers?

No. Tuple is a screen-sharing app, so we send only the contents of your screen (and audio) during calls, but we never send any complete files over the network. Things on your filesystem stay local. In most cases, media streams are directly peer-to-peer, but with 3 or more participants they may be routed through our servers.

How are keys exchanged between clients?

When two peers begin a call, the first step is to exchange keys for encrypting the communication. This happens directly between the peers.

The exchange is encrypted with DTLS (a derivative of SSL). The clients use a self signed certificate (asymmetric-key) based on RSA to exchange the keys they will use.

Thus, the exchange of keys is a) encrypted and b) done directly peer-to-peer. The packets never touch any servers under our control. We cannot intercept the exchange of keys and would see only encrypted data if we tried.

Also, the code that handles this exchange is from WebRTC, which is open-source, frequently audited, and primarily written and maintained by Google’s security experts.

What user data do you collect?

We’re not in the business of making money off of data. We do collect information about how users are interacting with our app so we can improve the product and provide faster, more effective support when issues arise. These events include:

Sign-In and Sign-Out events
Interaction with features of the app (e.g. mouse modes, switching hosts)
Crashes and other errors
Changes in network availability status
Changes in connectivity state with our backend server and peers
Calls made

In addition, the following metadata is collected by Mixpanel:

The version of the Tuple being used
The user’s operating system version
The user’s display dimensions

Users are identified in our system by their email address and are asked to provide a name. We don’t attempt to collect any demographic information, and don’t log IP addresses on incoming connections.

Does the app automatically accept inbound calls, or does it prompt you first?

You are always prompted to accept incoming requests before screen sharing or remote control is possible. The prompt includes the calling party’s name and avatar.

How do I report a potential vulnerability or security concern?

We are continually engaged with a team of researchers in a private bug bounty program and therefore do not provide compensation for independent reports. However, if you have a concern please email us at security@tuple.app, which will notify us very loudly and we’ll get back to you ASAP.

$3M cyber liability (each occurrence)
$3M errors and omissions (each occurrence)
$1M general commercial liability (each occurrence)
$6M umbrella liability (each occurrence)

Any further questions?

Great! Please email us and we’ll happily update this doc.