TeamDrive uses various technologies to make all communication secure. The TeamDrive Clients and the Registration Server use a Public-/Private Key mechanism to encrypt all data. The Registration Server generates a Public- and Private Key after the first start. A TeamDrive Client will ask for the Registration Server Public-Key when a user tries to register or login with a client. All requests from the client will be encrypted using a symmetric AES-256 key which will be generated based on the Public-Key of the Registration Server. The encrypted data can be send over standard HTTP without an additional SSL connection.

The Registration Server will decrypt the request using its Private Key. The type of answer returned to the client depends on the data returned. Most functions only return a success or failure informations, like checking a new license key. In this case the answer is not encrypted.

In other cases, like searching, a user will be encrypted. The way back to a client uses the Public-Key of the client installation. During the registration or login process, a TeamDrive Client will generate its own Public- and Private-Key. The Private-Key will be kept local in the local key store. The Public-Key will be uploaded to the Registration Server, so that the Public-Keys are available for other users.


Users don’t have personal Public-/Private-Key; every installation made by a user has its own Public-/Private-Key. This is important to understand, since even the different devices under the same user will have their own Public-/Private-Key.

A typical way how sharing data is working:


  1. A user X will create a new Space on a WebDAV, TDPS or Hosting Service server. During the Space creation the client will create a new AES-256 Space key which will be used to encrypt all data in this Space
  2. User X invites User Y to their Space. User X will generate an invitation document with the URL, access credentials, the AES-256 key of the Space, and other statistic informations for the Space. The user X’s client looks for all registered devices of user Y on the Registration Server. The client checks if all Public-Keys of the devices are already in his local key store. If not, it will download the missing Public-Keys (1). If all Public-Keys were not stored on the Registration Server, invitations could not be encrypted. Clients can only access the Registration Server. They cannot directly connect to each other.
  3. User X encrypts the invitation document using the Public-Keys User Y’s devices. Before the encrypted invitation is uploaded to the Registration Server, the request to the Registration Server is again encrypted using the Public-Key of the Registration Server (2).
  4. The Registration Server decrypts the request from the client and stores the encrypted invitation document in its database. It practically impossible to decrypt and read the encrypted invitation on the server side. The invitation document will be stored until User Y’s client polls for new invitations.
  5. The client of User Y downloads the invitation and decrypts the invitation document using their Private-Key (3). Upon accepting the invitation, the data in the Space on the WebDAV, TDPS, or Hosting Service server will be downloaded and decrypted using the Space’s AES-256 key (which was extracted from the invitation document).