FAQ

Related FAQ

News questions

We are often asked about issues that are not necessarily related to the operation of the application. These subjects are nonetheless very important. They are sometimes technical, sensitive, controversial, and unfortunately commented on in an approximate way (in less than 280 characters). Our aim here is to find the best compromise between a presentation that is accessible to as many people as possible, without skimping on a minimum of technical explanations. There’s no escaping it 😱.

Sovereignty

The cryptography implemented by Olvid allows each user to be sovereign.Unlike almost all Internet services, data sovereignty does not depend on the location of the servers or the nationality of the solution’s publisher.

To find out more:

AWS

Our servers are hosted by AWS. Olvid’s technological breakthrough is to guarantee the security of its users via cryptographic mechanisms, which have no nationality, without having to trust the servers.

To find out more:

IP addresses

Olvid relies on the Internet to enable its users to communicate and therefore has access to their IP address. This is not unique to Olvid: when you surf the Internet, read an article or consult a social network, your IP address is accessible to the service provider simply because that is how the Internet works. Olvid does not keep these addresses.

Tracker

Some tools attempt to automate tracker detection within an application. This detection is not an exact science and there may be false positives. Olvid does not contain a tracker, but the Android version includes an indirect dependency that can lead to a false alert.

To find out more:

Feature X is still not available. Why not?

Because we developed feature Y first. And if we had done the opposite, we would have been criticised.

Free

Olvid is free. You probably know the saying: “When it’s free, you’re the product”. And why is that? Because applications that are supposedly free are generally financed by using your personal data. This is not the case with Olvid, which is financed by paying features.

Certification

Our certifications (ANSSI Security Visas) date back about 3 years, and it is mainly our cryptographic protocols that have been certified. These have not changed since then and no flaws have been reported to us: in this sense, they remain perfectly secure. The addition of new functionalities does not call into question the solidity of our cryptographic base.

To find out more:

Using Keycloak in the Enterprise offering

The use of keycloak in our Enterprise offering does not follow the usual web application deployment patterns. Some elements may therefore come as a surprise. But all our corporate and public sector customers, whose technical teams have studied our deployment scheme in detail, can confirm that it poses no problems.

Personal Data

When you want to access a web service, you are usually asked to create an account, which the service stores on a server to which it has access. This is not the case with Olvid: the account you create remains local on your device and none of the data you enter (such as your name) is shared with Olvid’s servers. Olvid uses your IP address for its operation, as discussed here.

List of sub-contractors

Apart from our servers at AWS, we do not have any subcontractors within the meaning of the RGPD.

Transparency

We have documented all of Olvid’s technology so that anyone interested can benefit from it. Publication of security targets, certification reports and ANSSI certificates; publication of the two technical evaluation reports produced by CESTI Synacktiv; publication of scientific articles. And the source code for the mobile applications is open source.

To find out more:

To find out more - Olvid operation

Olvid is an instant messaging application that lets you exchange messages, files (documents, photos, videos, voice messages, etc.) and make audio calls between two devices (to date, Olvid is compatible with Android, iOS, iPadOS, macOS, Windows and Linux).

All information exchanged via Olvid is end-to-end encrypted. In the case of messages, for example, the sender’s device uses an encryption key to encrypt the message, destroys the key (which will never be used a second time) and sends the encrypted message. The message is only decrypted in one place: on the recipient’s device, which is the only place where the decryption key can be found. Once the message has been decrypted, the decryption key is destroyed.

This mode of operation (combined with skilful refreshment of cryptographic keys) guarantees the forward secrecy of exchanges. In practice, this means that if the sender and recipient have deleted the message from their device, Olvid cryptographically guarantees that it will be impossible for a third party to recover the message, even if that third party has recorded all the Internet traffic and stolen both users’ devices to extract all the cryptographic keys.

As mentioned above, data exchanged with Olvid is systematically encrypted from end to end. Everything a device sends over the network via Olvid has the following structure:

Encrypted or random data || Recipient's public key

Given the encryption algorithms used by Olvid (in the case of messages: Encrypt-then-MAC with AES-256 in CTR mode and HMAC over SHA256), encrypted data is indistinguishable from uniformly distributed random data (in other words, indistinguishable from digital noise). It is therefore cryptographically impossible to extract any information whatsoever (apart from the size of the encrypted data, but here again, Olvid applies certain techniques to mitigate this risk). The recipient’s public key (in clear text) is used to transmit the message to the recipient (like an address on a sealed envelope). This public key cannot be used to deduce any personal information about its owner (i.e., the device holding the corresponding private cryptographic key).

The first conclusion is that an Olvid encrypted (message) cannot be used to extract any personal information about the content of the information exchanged, or about the physical identity of the sender or recipient.

Our security model is based on this initial conclusion: Olvid guarantees total communication security, even if the entire network is malicious. In other words, it doesn’t matter what network, transatlantic cable, router or server an Olvid-encrypted message might pass through. By design, the very structure of this cipher guarantees cryptographic confidentiality of the information it contains.

The importance of user-to-user authentication

Olvid is not the only solution to offer end-to-end encryption. Other instant messengers do too. A legitimate question then arises: how is Olvid different from these other solutions?

The answer lies in the means made available to users to agree on the famous encryption/decryption keys for messages. In cryptography, there are exactly two ways of proceeding:

  • The first is to use a third-party server: this is the choice made by the vast majority of other secure messaging services available to the general public. In this case, each user must first create an account on a centralized directory (a server) generally operated by the service provider. This account will necessarily contain personal data, since it must enable the service provider to link the account to the user. In particular, this directory will store a unique identifier for the user, usually a telephone number or e-mail address. This approach presents a number of security risks:

    • If the trusted third party (the centralized server serving as the user account directory) is compromised, the security of the whole solution collapses, for all users.
    • Any individual able to convince the third party that he or she is the owner of the identifier (phone number or email address) will be considered the legitimate user. For example, anyone able to intercept an SMS message will be able to hijack the legitimate user’s account.

  • The second approach (the one chosen by Olvid) is not to impose a third party on users. Instead, the third party is replaced by cryptographic protocols, executed exclusively on the user’s devices. As long as the devices are not hacked, these protocols prove that no attack can take place. Olvid implements more than a dozen protocols. While some have been custom-designed (such as the group discussion creation protocol), others are directly inspired by public research (such as the code-based protocol for adding contacts remotely, based on Serge Vaudenay’s SAS protocol). These protocols are open-source, documented and audited. Unlike the first approach, users don’t have to rely on any server infrastructure.

As a second conclusion: while Olvid is not the only consumer instant messaging solution to offer end-to-end encryption, it is (to our knowledge) the only one to also guarantee end-to-end authentication, in other words, not to rely on a centralized directory for the confidentiality and authenticity of exchanges.

« If you build a system where everything comes down to trusting the server, you might as well dispense with all the complexity and forget about end-to-end encryption ».
Matthew Green
Cryptography professor at Johns-Hopkins University
Wired

Conclusion

We’ve tried to strike the right balance between brevity and precision. These explanations are important, because they help to understand why the technology at the heart of Olvid is unique, and why Olvid is not just “another secure instant messenger”.

The most important thing to remember: many instant messengers offer end-to-end encryption. But to guarantee confidentiality, you need to trust a centralized directory (server). The latter must itself trust other third parties (such as the telephone operator when the telephone number is used as an identifier). If just one of these links fails, the user’s security may be compromised. This is not the case with Olvid, which imposes no trusted third party, no centralized directory.

To find out more - Server infrastructure

For instant messaging to be usable by as many people as possible, it is necessary to guarantee asynchronous communications: if your recipient is offline (on a plane) when you send your message, you can nevertheless expect the message to reach him/her the moment he/she comes back online (when he/she gets off the plane).

Some so-called “decentralized” solutions (in other words, without a centralized server) guarantee this result by actively testing connectivity with the recipient’s phone before sending the message, and resending the message if delivery is not confirmed. The user experience is generally much poorer: messages regularly take a long time to be delivered, battery usage is high, and so is bandwidth consumption.

Other solutions, such as Olvid, rely on a relay server to put encrypted messages “on hold” until the recipient is online. Once the recipient has downloaded the message, it is deleted from the server.

As we explained above, the very structure of the message guarantees that the relay server will not be able to extract any personal information from it, nor any information about the content of the message.

The cryptographic protocols discussed above allow us to consider the relay server in the same way we already consider all the other parts of the network (relay antennas, transatlantic cable, routers, etc.): we generally don’t trust them (with good reason), but cryptography allows us to disregard their existence. The same applies to our relay server: the cryptographic protocols implemented by Olvid allow us to ignore it, since it plays no role in communications security.

Parallels with TLS

When you connect to a website whose address starts with https://, you don’t need to worry about the security of the cables and routers (over which you have no control) between your device and the server hosting the site. This is made possible by the cryptography implemented by the TLS protocol, which guarantees the authenticity of the site (essential, for example, to ensure that a payment made on it is indeed destined for the right person) as well as the confidentiality of the data we exchange with it (so that your purchase is not necessarily known to everyone).

In the same way, the end-to-end encryption and authentication implemented by Olvid means you don’t have to worry about the security of what’s between your device and that of your correspondent: be it cables and routers (as with TLS), but also the message relay server. Cryptography makes it possible to forget all this.

Knowing who controls the server is therefore no more important than knowing who controls the various routers that must be traversed. Cryptography on your own device and that of your correspondent is enough.

How does the relay server work?

Since the relay server has no security role, its operation is relatively straightforward: when the device sends an encrypted message, it is stored on the relay server. Using the recipient’s public key, this server can notify the recipient that a message is waiting on the server. This notification is based either on push notification technologies from Apple or Google, where the user has chosen to do so, or on a websocket connection between the recipient’s phone and the relay server. Once notified, the user proves to the server (via a zero-knowledge proof of knowledge) that he or she is the legitimate recipient of the message (in order to limit the risk of denial of service), downloads the encrypted message, and the server deletes the message.

In the case of a message with attachments, the behavior is similar: the sender deposits his message on the server, indicating the number of files to be attached, and retrieves a unique signed URL for each file, authorizing him to deposit the encrypted attachment on the server. Once the last attachment has been deposited, the server notifies the recipient that he/she can retrieve the message content and again a signed URL authorizing him/her to download each attachment. The message and its attachments are deleted once the last attachment has been downloaded by the recipient.

Our server is hosted by AWS

The very simple nature of the server probably gives the impression that we could host it with any hosting provider. However, a service like Olvid needs to provide the best resilience to outages, the best availability worldwide, and the ability to scale quickly in the event of a surge in users or a one-off peak load. Nobody wants a messaging system whose messages take a long time to arrive around 7pm when everyone is using it!

So we chose to host the server with AWS, because we found it offered the best quality of service, with the least effort on our part to maintain and scale our infrastructure.

What would be the specifications for switching to a SecNumCloud hosting provider?

For all the reasons mentioned above, switching to a SecNumCloud hosting provider is far less important for a service like Olvid than for a traditional SaaS service that would have access to its users’ personal data. What’s more, we don’t see any point in transferring our entire free offering for the general public to servers that are often very expensive.

On the other hand, we are planning to offer a multicloud architecture. With this in mind, we’re obviously keeping a close eye on developments in SecNumCloud-labeled PaaS offerings (or a European qualification of at least equivalent level).

In France today, there is a SecNumCloud offering of the IaaS type, i.e., a “bare” infrastructure of servers. The offer we are using today from AWS is a PaaS-type offer (which notably abstracts server administration and scaling management issues).

There is currently no SecNumCloud PaaS offering, as it’s a colossal task to build such an offering from IaaS. Rather than trying to develop this service ourselves, we feel it would be wiser to take advantage of the know-how of French cloud players and let them build their SecNumCloud PaaS offering at their own pace.

Without being exhaustive, here is a list of the technologies that are central to Olvid’s operation today (the names used are those of AWS):

  • API Gateway: allows us to implement an API REST and an API WebSocket based on lambda functions, without managing load balancing.
  • Lambda functions: allow us to process client requests without having to manage server infrastructure.
  • DynamoDB: Databases whose scaling is fully managed.
  • SNS: enabling us to send push notifications.
  • SQS: PubSub service for asynchronous processing of certain requests.
  • S3: to store large encrypted attachments (sometimes several gigabytes).

Finally, the PaaS offering will have to be capable of guaranteeing high availability.

We already use these players (such as Scaleway, Outscale and OVH) for some of our in-house tools, and for some of our services to businesses and public authorities.

To find out more - Tracker

Olvid obviously does not have any integrated tracker, but what is detected as OpenTelemetry by the analysis tools is in fact an OpenCensus library, which is a dependency of the Google Drive connection library. This library could be used to retrieve telemetry data, but it is only used by Google Drive for bandwidth measurements.

Olvid does not therefore retrieve any telemetry data, but uses Google Drive for automatic backups to the Cloud. We would have liked to remove this dependency, but it is now essential to the operation of Google Drive. However, the open-source version of the application (available on GitHub) offers a ‘no Google’ version that removes any dependency on closed code (including the Google Drive library).

Learn more