FTAPI SecuTransfer – the secure alternative to emails? Not quite…

Emails aren’t private, so much should be known by now. When you communicate via email, the contents are not only visible to yours and the other side’s email providers, but potentially also to numerous others like the NSA who intercepted your email on the network. Encrypting emails is possible via PGP or S/MIME, but neither is particularly easy to deploy and use. Worse yet, both standard were found to have security deficits recently. So it is not surprising that people and especially companies look for better alternatives.

It appears that the German company FTAPI gained a good standing in this market, at least in Germany, Austria and Switzerland. Their website continues to stress how simple and secure their solution is. And the list of references is impressive, featuring a number of known names that should have a very high standard when it comes to data security: Bavarian tax authorities, a bank, lawyers etc. A few years ago they even developed a “Secure E-Mail” service for Vodafone customers.

I now had a glimpse at their product. My conclusion: while it definitely offers advantages in some scenarios, it also fails to deliver the promised security.

Quick overview of the FTAPI approach

The primary goal of the FTAPI product is easily exchanging (potentially very large) files. They solve it by giving up on decentralization: data is always stored on a server and both sender and recipient have to be registered with that server. This offers clear security benefits: there is no data transfer between servers to protect, and offering the web interface via HTTPS makes sure that data upload and download are private.

But FTAPI goes beyond that: they claim to follow the Zero Knowledge approach, meaning that data transfers are end-to-end encrypted and not even the server can see the contents. For that, each user defines their “SecuPass” upon registration which is a password unknown to the server and used to encrypt data transfers.

Why bother doing crypto in a web application?

The first issue is already shining through here: your data is being encrypted by a web application in order to protect it from a server that delivers that web application to you. But the server can easily give you a slightly modified web application, one that will steal your encryption key for example! With several megabytes of JavaScript code executing here, there is no way you will notice a difference. So the server administrator can read your emails, e.g. because of being ordered by the company management, the whole encryption voodoo didn’t change that fact. Malicious actors who somehow gained access to the server will have even less scruples of course. Worse yet, malicious actors don’t need full control of the server. A single Cross-site scripting vulnerability is sufficient to compromise the web application.

Of course, FTAPI also offers a desktop client as well as an Outlook Add-in. While I haven’t looked at either, it is likely that no such drawbacks exist there. The only trouble: FTAPI fails to communicate that encryption is only secure outside of the browser. The standalone clients are being promoted as improvements to convenience, not as security enhancements.

Another case of weak key derivation function

According to the FTAPI website, there is a whitepaper describing their SecuTransfer 4.0 approach. Too bad that this whitepaper isn’t public, and requesting at least in my case didn’t yield any response whatsoever. Then again, figuring out the building blocks of SecuTransfer took merely a few minutes.

Your SecuPass is used as input to PBKDF2 algorithm in order to derive an encryption key. That encryption key can be used to decrypt your private RSA key as stored on the server. And the private RSA key in turn can be used to recover the encryption key for incoming files. So somebody able to decrypt your private RSA key will be able to read all your encrypted data stored on the server.

If somebody in control of the server wants to read your data, how do they decrypt your RSA key? Why, by guessing your SecuPass of course. While the advise is to choose a long password here, humans are very bad at choosing good passwords. In my previous article I already explained why LastPass doing 5000 PBKDF2 iterations isn’t a real hurdle preventing attackers from guessing your password. Yet FTAPI is doing merely 1,000 iterations which means that bruteforcing attacks will be even faster, by factor 5 at least (actually more, because FTAPI is using SHA-1 whereas LastPass is using SHA-256). This means that even the strongest passwords can be guessed within a few days.

Mind you, PBKDF2 isn’t a bad algorithm and with 100,000 iterations (at least, more is better) it can currently be considered reasonably secure. There days, there are better alternatives however — bcrypt and scrypt are the fairly established ones, whereas Argon2 is the new hotness.

And the key exchange?

One of the big challenges with end-to-end encryption is always the key exchange — how do I know that the public key belongs to the person I want to communicate with? S/MIME solves it via a costly public trust infrastructure whereas PGP relies on a network of key servers with its own set of issues. On the first glance, FTAPI dodges this issue with its centralized architecture: the server makes sure that you always get the right public key.

Oh, but we didn’t want to trust the server. What if the server replaces the real public key by the server administrator’s (or worse: a hacker’s), and we make our files visible to them? There is also a less obvious issue: FTAPI still uses the insecure email for bootstrapping. If you aren’t registered yet, email is how you get notified that you received a file. If somebody manages to intercept that email, they will be able to register at the FTAPI server and receive all the “secure” data transfers meant for you.

Final notes

While sharing private data via an HTTPS-protected web server clearly has benefits over sending it via email, the rest of FTAPI’s security measures is mostly appearance of security right now. Partly, it is a failure on their end: 1,000 PBKDF2 iterations were already offering way too little protection in 2009, back when FTAPI prototype was created. But there are also fundamental issues here: real end-to-end encryption is inherently complicated, particularly solving key exchange securely. And of course, end-to-end encryption is impossible to implement in a web application, so you have to choose between convenience (zero overhead: nothing to install, just open the site in your browser) and security.