Security and Data Transfer

TeamDrive combines several encryption methods to ensure total privacy for users within a Space and for their shared files. The core principle is end-to-end encryption. In other words, all data leaving a client device (endpoint) is encrypted and remains encrypted during transfer and storage. Encryption keys are generated on the endpoint and, when required, are transported securely to another endpoint.

Details of the procedures involved, and encryption methods used are described in the following sections.

Encryption in TeamDrive

TeamDrive uses the following encryption mechanisms:

AES 256 (Advanced Encryption Standard)

The Advanced Encryption Standard is the encryption algorithm used by U.S. government agencies. It is a symmetric encryption algorithm (the same key used for both encryption and decryption) that accepts key lengths of 128, 196 or 256 bits. TeamDrive uses the 256-bit AES, with CBC block cypher chaining and PKCS7 padding.

The AES implementation uses the C-code implementation of the OpenSSL library (www.openssl.org)

RSA 3072 / 4096

RSA is widely used public-key cryptosystems used for secure data transmission. The RSA implementation that is used is the C-code implementation provided by the OpenSSL Library (www.openssl.org).

In order to exchange data using RSA a user locally creates a matching Public and Private Key pair. The Public Key is published and made accessible to anyone wanting to communicate securely with the user. The Public Key is used to encrypt a message, which can only be decrypted by the holder of the Private Key.

TeamDrive uses RSA encryption to provide a secure messaging system which is used to exchanges AES symmetric encryption keys used to encrypt Spaces. This mechanism allows TeamDrive to securely exchange keys of any length.

TeamDrive uses 3072-bit RSA keys on the clients that are rated as secure for the next 15 years. The TeamDrive Server components use 4096-bit RSA keys. All systems have been coded to handle encryption keys of any size so that they can be increased as computing power grows in the future.

bcrypt

TeamDrive uses bcyrpt to hash encrypt passwords on the Registration Server. bcrypt is a key derivation function for passwords based on the Blowfish cipher. Besides incorporating a salt to protect against rainbow table attacks, bcrypt is an adaptive function: over time, the iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computation power.

TLS (Transport Layer Security)

TeamDrive uses HTTPS (the secure HTTP protocol based on TLS - Transport Layer Security) to communicate between client and server and for all server-to-server connections. The use of HTTPS provides security in addition to the use of the end-to-end encryption based on the RSA and AES standards used by TeamDrive.

Registration

When the TeamDrive Client software is installed for the first time, the user must be registered on a TeamDrive Registration Server. This requires the user enter their username (optional), an email address, and password.

An exception to this is if the user logs in using an External Authentication Service. In this case, a user account is automatically created on the TeamDrive Registration Server. The data stored in this case includes the user’s email and an “Ext Auth ID” (External Authorization Identifier) which is issued by the External Authentication Service.

Registered users that install TeamDrive must login using their username or email and password. All enduser devices are registered on the Registration Server where they are associated with particular user account.

After completing initial registration, the TeamDrive Registration Server sends the user an email with an activation link. Before TeamDrive can be used, the user account must be “activated” by clicking on the link. The purpose of this is to confirm the validity of the email address provided.

TeamDrive supports two-factor authentication. When enabled, after login users will be prompted to provide additional authorization based on the type of two-factor authentication in use. This is currently either an OTP (one-time password) sent via email or a code provided by the Google Authenticator App.

The Registration Process

The registration process entails the following steps:

  1. After installation is completed successfully, the TeamDrive Client retrieves the Public Key of the TeamDrive Registration Server.
  2. The TeamDrive Client generates a temporary RSA key and sends the Public Key and the data entered during registration to the server encrypted using the Public Key of the Registration Server. The data includes: a username selected by the user (this is optional), the user’s email address and the password. The server creates a new user account and stores the user data. The password is hashed using the bcrypt algorithm for storage purposes.
  3. The Registration Server generates a new Device ID and an associated Authorization Token, which it encrypts with the temporary RSA Public Key and returns them to the TeamDrive Client in the reply. The installation is set to the “deactivated” state while activation is pending.
  4. The Registration Server generates a unique activation code and sends an email to the user with a link containing the activation code.
  5. The user confirms the validity of the email address by clicking on the activation link. When the link is clicked, the Registration Server sets the client installation to the “email confirmed” state.
  6. The TeamDrive Client waits for the installation to be activated by polling the Registration Server. It then generates a new 3072-bit RSA Public/Private Key.
  7. The TeamDrive Client sends the Device ID, Authorization Token, and the Public Key of the new RSA key to the Registration Server, in a message encrypted using server’s public key.
  8. The Registration Server verifies the Authorization Token and then checks that the installation is in the “email confirmed” state. If so, the server saves the public key, and sets the state of the installation to “activated”. The Registration Server will not allow the client software to use the new installation until it is in the “activated” state.

After activation all messages sent from the Registration Server to the client are encrypted using the RSA public key of the client installation, stored on the Registration Server.

Requests to the Registration Server are authenticated using the Device ID and Authorization Token sent by the client. The Authorization Token is invalidated and a new token is generated whenever the user’s password changes. It is also possible to invalidate the Authentication Token manually or automatically on the Registration Server which requires the user to login again on all client installations.

Creating a Space

To create a Space, the user must have access to a Depot and the associated TDSV credentials document. The TDSV document contains all the information required by the TeamDrive Client to access the Host Server and create a Space in the Depot. This includes the Host Server URL, the Depot ID and an Authorization Token.

Procedure for Creating a Space

  1. When creating a Space in the TeamDrive Client, the user selects the Depot in which the Space is to be created. A default Depot is provided during user registration. After this, the user enters the name of the new Space.

  2. The TeamDrive Client requests the public key of the Host Server from the TeamDrive Registration Server.

  3. The client sends the username, device Public Key, User Authentication Token, the Depot ID and Authorization Token, and the name of the Space in an encrypted message to the TeamDrive Host Server.

  4. The Host Server verifies the Depot ID and Authorization Token. The server also checks that the username is in the access list of users that have been authorized to access the Depot by the Registration Server.

  5. The Host Server verifies the User Authentication Token by sending an encrypted message to the TeamDrive Registration Server, and retrieves the matching User ID and email address (optional) of the user’s installation.

    Before returning the data, the Registration Server verifies the identity of the TeamDrive Host Server (all Host Servers must be registered in the TeamDrive Registration Server Network) and encrypts the reply using Public Key of the Host Server.

  6. The TeamDrive Host Server creates a new Space in the specified Depot. A unique Space ID and a 128-bit Authorization Code is generated for the new Space. The Space ID, Authorization Code and a URL used to access the Space are sent back to the client in a message encrypted with the client public key.

  7. The client completes Space setup by generating a 256-bit AES key that is used to encrypt all data uploaded to the Space. The Space ID and Authorization Code are used to read and write the Space data (as explained in the section: Host Server Authentication below). These values are saved in encrypted form in the TeamDrive Client database.

Joining a Space (Accepting an Invitation)

Messaging

Joining a Space is done by using the secure messaging service provided by the Registration Server. This requires that the Registration Server act as a relay for messages. The server collects the messages and forwards them as required.

To send a message to another user, the TeamDrive Client software needs the email address or username of the enduser (recipient). For each device belonging to the recipient, the TeamDrive Client requests the user’s Public Key from the Registration Server. The client then encrypts the message with this key and sends it to the Registration Server.

The Registration Server stores the messages for the TeamDrive Client on each device. All TeamDrive Clients check the Registration Server at a certain interval to see if a new message is waiting. If this is the case, the message is retrieved and deleted from the server.

Using the Public/Private Key system, only the client running on the device to which the message is addressed can decrypt the message.

The Space Invitation Document

The Space Invitation Document contains all information required by the software for connecting a user to a Space. It includes the Space URL, the Space ID, the 126-bit Authorization Code and the 256-bit AES data encryption key for the Space. To invite a new user to join a Space a message containing the invitation document is sent to each device belonging to the user. This message is encrypted with the Public Key of the target recipient.

This ensures that the message exchange is secure and only the specified invitee can view the contents of the space invitation document.

Identifying the Recipient

It is essential to ensure that invitations are sent to the correct user.

To ensure that the correct recipient receives the message, users should first contact the message recipient and request his/her TeamDrive username or current email address and then send the invitation. Only by performing an independent verification is it possible for the user to be sure he or she is not sending messages or invitations to intruders. For this reason, TeamDrive supports the additional password encryption of invitations. This requires that the sender of the invitation enter a password during the invitation process. The password is hashed using MD5 to produce a 128-bit key which is then used to encrypt the invitation using AES.

When this is done, the recipient must enter the password in order to accept the invitation. This means that the password must be sent from the inviter to the invitee via a different communication channel, for example, in person, by telephone or using an instant messaging service that is considered sufficiently secure.

Inviting Unregistered Users

In order to use the system easily and universally, TeamDrive provides a service that allows a user to invite someone who is not yet registered as a TeamDrive user.

This is done using the following procedure:

  1. The user selects the Space and enters the email address of the user whom he or she wants to invite. In this case, it is strongly recommended to use a password-encrypted invitation, as described above.
  2. The TeamDrive Client sends an encrypted message to the Registration Server, requesting the username of the user with the given email. The Registration Server indicates that a user with the specified email address does not exist.
  3. The TeamDrive Client then creates a Space Invitation Document and encrypts this with the Registration Server’s Public Key (and the password from (1) if specified) and sends this to the Registration Server, along with the email address of the unregistered user. The invitation is saved by the Registration Server.
  4. The Registration Server then sends a normal unencrypted email to the unregistered user. This email message explains to the invited user how to download and install the TeamDrive Client software. The message may also include a personal message from the inviter explaining to the recipient why he or she should install the software, as well as how to obtain the additional password.
  5. Once the unregistered user registers using the email address with which they were invited, the Registration Server sends the invitation document to the TeamDrive Client of the user.
  6. If the invitation is not retrieved by the unregistered user within a certain amount of time (usually a number of days), the invitation is deleted from the Registration Server.

Accessing a Space

To obtain access to a Space, TeamDrive requires a Space URL, the Space ID, the 128-bit Authorization Code, and the 256-bit AES data encryption key. The URL contains the internet address of the Host Server. The Space ID identifies the Space, which in turn identifies the Depot in which the Space data is stored.

Changes are uploaded to- and downloaded from the Space using the HTTPS GET, PUT and POST methods. Before any file or Space meta-data leaves the client device, it is compressed and encrypted with the Space key.

Object Store Access

If the Host Server is connected to an Object Store, then the credentials for accessing the Object Store are stored in the database of the Host Server, and are not accessible to the client. Direct upload to the Object Store is not permitted. All uploaded data is first stored locally by the Host Server and transferred by a background process to the Object Store.

Direct download from the Object Store may be enabled on the Host Server. In this case, the client must first make a request to the Host Server which is authenticated as described below. The Host Server then generates a temporary read authorization for the requested data on the Object Store, and sends a re-direct to the client. The client is then able to download the data directly from the Object Store. To access the downloaded data the 256-bit AES data encryption key is still required, of course.

Host Server Authentication

Access to a Host Server is stateless. In order to send or retrieve data from the Host Server the TeamDrive Client does the following:

  1. Create a URL with the required arguments, including: the Space ID, BLOB ID, read/write offset, data length and recovery ID (used to detect a server-side restore).
  2. If the request is a POST then the client creates an MD5 hash of the data in the body of the request and adds this value as an argument to the URL.
  3. The client adds a timestamp argument, which is the current time in seconds.
  4. The client generates an authentication token by calculating the SHA-256 hash of the final URL concatenated with the Authentication Code of the Space. The resulting authentication token is then added as the last argument to the URL.

On receipt of the request, the server extracts the Space ID from the URL, and uses the Authentication Code stored in the Host Server database to verify the URL. If this is correct the server also checks that the timestamp is current.

If not the server returns an error with information about the server’s current time so that the client can synchronize its clock with that of the server. Finally, if the request includes a body then the MD5 argument in the URL is verified. In cases where a request is particularly sensitive to a repeat (this includes the adding of events to a Space and the creation of a Space) the server also checks that the authentication code has not been used previously. For this purpose the server stores the authentication code of the request for a certain amount of time (long enough to ensure that the request is otherwise rejected for an incorrect timestamp).

Host Server Reply

The reply generated by the server (which is returned in the body of the HTTP reply) consists of three parts: a JSON header, a checksum and an optional binary data body.

The JSON header contains the reply parameters, including the structure of the binary data, and MD5 hash of the binary data and the Authentication Token sent with the request.

The server then generates a checksum, which is calculated using the SHA-256 hash of the JSON header concatenated with the Authentication Code of the Space.

On receipt, the TeamDrive Client confirms that the reply belongs to the request, by checking the authentication token. It then verifies the checksum by performing the same calculation as the server using the Authentication Code of the Space. The MD5 of any binary data returned is then also verified.

Space Access Security Features

The authentication mechanism described above serves a number of purposes for the security of a Space:

  1. It ensures that the space cannot be accessed without a valid Authentication Code.
  2. It prevents data or any part of the request from being modified while in transit, either to or from the server.
  3. The client is able to verify that a reply belongs to the request sent.
  4. It ensures that requests are not repeatable in cases where a repeated request can be damaging to the integrity of a Space or result in DOS (Denial-of-Service) attack.

These security features, including the fact that all Space data is already encrypted before leaving the client ensure a secure and reliable connection between TeamDrive Client and the Host Server. In addition, the TLS-based HTTPS protocol is used by default between client and server adding further security.

File Publishing

TeamDrive allows users to publish files in a Space that can be downloaded using a “Publish URL” by users that are not necessarily members of the Space. The TeamDrive client publishes a file by uploading (using the HTTPS protocol – HTTP over TLS) the current version of the file to a download area on the Host Server. Before upload, the client generates a 256-bit key that is used to encrypt the file on the server.

After upload, the server replies with the Publish URL. The URL includes the Global ID of the Space file that has been published. The Host Server does not store the encryption key. Instead the TeamDrive client adds the key to the Publish URL. When the published file is downloaded (using HTTPS), the server uses the encryption key from the URL to decrypt the published file while streaming the file to the user. In this way, published files are never stored unencrypted on disk.

Registration Server Key Repository

The Registration Server provides a “Key Repository” in which users can securely store their Space keys. Usage of the repository is optional so it can be disabled by each user individually, or globally via a setting on the Registration Server.

The Key Repository serves as a backup for a users Space keys, and also enables immediate access to Spaces when TeamDrive is installed on a new device. If the Key Repository is disabled, a user’s Space keys are not stored centrally, which means that the new device can only gain access to Spaces by way of invitation (self-invitation in this case).

The Key Repository works as follows:

  1. To initialize the Key Repository, the client software generates new 3072-bit RSA Private/Public Key pair (note that this is different to other RSA keys generated during the Registration Process, as described in the section: The Registration Process).
  2. The client encrypts the Private Key with the so-called “user secret”, which is a salted SHA256 hash of the user’s password. The user secret is stored locally on the client in an encrypted form. Since the user’s password is always sent to Registration Server in a hashed form (as described in The Registration Process section), there is no way that the user secret can be obtained without access to the user’s device.
  3. The RSA Public Key and the encrypted Private Key are sent to the Registration Server where they are stored in the Key Repository.
  4. If the Key Repository is enabled then, whenever the user creates or joins a Space, the client software encrypts the Space key (and other access data as described in Procedure for creating a Space) with the Public Key, and uploads the encrypted data to the Registration Server where it is stored in the Key Repository.
  5. When the user creates a new TeamDrive device, after login, the client software downloads the contents of the user’s Key Repository and uses the password to decrypt the Private Key. After this is done, the Private Key is used to decrypt the Space keys (and other Space access data), so that the new installation has access to all the Spaces belonging to the user.
  6. If the user’s password changes, only the Private Key from the Key Repository is re-encrypted by the client and uploaded to the Key Repository.

The secure mechanism used by the Key Repository ensures that no-one other than the user has access to his/her Space keys. In particular, the keys are not accessible, even by those who have access to the Registration Server.

However, it is possible for a user to lose access to his/her Space keys. This can only occur when the following two conditions hold:

  1. The user has forgotten his/her password, and
  2. the user has lost all TeamDrive installations.

As long as a user has a previous TeamDrive installation, the Key Repository remains accessible, even if the user’s password is lost.

Nevertheless, to further guarantee access to Spaces it is recommended to make a backup of the local Space key backup file that is written to the client device whenever a Space is created or joined.