Tuple's Security Details

Introduction

As a remote control application, we recognize the importance of excellent security practices. While we are a small team (currently just 3 founders and a few contractors), 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.
  • We have no employees, and contractors we hire are given the lowest level of access that allows them to get their work done. This almost never 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

Tuple has no employees, but our few contractors sign an NDA before gaining access to sensitive information. Contractors are given the lowest level of privilege required to complete their tasks, which rarely includes access to production data.

Penetration testing

We had a penetration test performed in May of 2020. You can read a summary of the findings. In addition, we welcome reports from security researchers at security@tuple.app.

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. This is valid for 30 days.

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

Encryption

All data streams during a pairing session are sent peer-to-peer (avoiding our servers) and are encrypted end-to-end.

When we say "end-to-end", we mean it in the way you'd expect: your data 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 are encrypted using Datagram Transport Layer Security (DTLS) version 1.2, while video and audio streams are encrypted using Secure Real-time Transport Protocol (SRTP).

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 peer-to-peer connection. The peers exchange keys directly through an encrypted tunnel. The keys are never sent in plain text and do not pass through our servers.

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.

Architecture diagram

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, video streams are directly peer-to-peer. When using certain firewall configurations we use a relay server, but all data is encrypted end-to-end and cannot be decrypted on that server.

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?

Please email us at security@tuple.app, which will notify us very loudly and we'll get back to you ASAP.

Are you SOC 2 or ISO 27001 certified?

While we'd eventually love to achieve these certifications, we don't hold them at this time.

Any further questions?

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