whistle.im: FaaS - Fuckup as a Service

Since the Snowden leaks showed us that the NSA and GCHQ not only have the capabilities to sniff on all cross border communications, but indeed do precisely this a new interest in hard encryption technologies for internet communications arises. This in principle good new phenomenon however gets tainted by new projects that are being built up in hurry for marketing reasons. These projects play with the new consciousness and fear of the people without offering real protection.

Besides the laughingly "E-Mail Made in Germany"-initiative a project run by two students called whistle.im prides itself in offering secure end-to-end encryption. Both take much care about the silly "Made in Germany"-slogan

Features

At a first shot, the project might look sensible:

End-to-end encryption

"Our Cryptography is open source - helping hands welcome!"

Usage of SSL,RSA,AES

DBut on a closer look, one soon recognizes these are more hollow phrases than thoughtful implemented concepts. Since event the most basic principles were violated, the only conclusion left is: This System is "Broken beyond repair"

Design-Problems

Before going into the technical Details, there are a few points to state from an overall design perspective:

The service provider runs a key server on which the RSA-keys of all participants are stored. This means that the service provider delivers the keys to the users. Of course a false key could be delivered, and the messages decrypted and read.

DThe private keys of the communicating partners are stored (albeit encrypted) on the server of the service provider. Once he gains knowledge of the password, he can decrypt all previous communications

This is a central service. As a consequence the service provider is able to find out who chatted with whom, how often, and how long.

The cryptographic code may lay open as JavaScript but not so the application itself. The label OpenSource is misleading. The code the application itself runs remains hidden.

Basic concepts of state-of-the-art encryption methods have not been understood.

The communication to the server is not safe against Man-in-the-middle attacks

All keys are, from the beginning of the communication, exchanged via the key server. So an attacker running a man-in-the-middle-attack can at all times read the communication and manipulate it. This possibility is only limited by the cryptic display of the rsa-keys fingerprint.

An attacker can hijack a session and become partner of communication itself.

How to fail SSL for dummies

Now, how does this look on a technical level?

The application communicates via JSON with the server switch.whistle.im. The connection is build up via HTTPS. Since this obviously was done by experts, we find the first deadly flaw: The SSL Certificate will not be checked for validity. The application will accept an arbitrary self-signed certificate.

For this precious present an attacker has to be grateful to the whistle.im-team. The effort to provide a self-signed certificate for the server really is wasted, the encryption could as well be unencrytped at all, it wouldn't matter.

After routing the communication through a transparent proxy that switches the pseudo-secure SSL cert against a self-generated, an attacker has access to all server communication and can modify it at will.

How to fail private key handling for dummies

The communication with the Server is unspectacular:

Query of the software version/li> Query of a Salt-Value for the password authentication Login via username/password (password seems to be hashed with a salt, not tested so far) Transmission of private- and public-keys for communication from the server.

GET /keys/blubba2/5KsGE76Nvx8gOjsy7ia2TTtCUXdAgNQi HTTP/1.1 Host: switch.whistle.im Accept-Encoding: gzip Accept-Language: de-DE, en-US Accept: */* User-Agent: Mozilla/5.0 (Linux; U; Android 2.3.7; de-de; HTC Desire Build/GRI40) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 Accept-Charset: utf-8, iso-8859-1, utf-16, *;q=0.7

HTTP/1.1 200 OK Date: Sun, 18 Aug 2013 12:03:45 GMT Content-Type: application/json; charset=utf-8 Connection: keep-alive Vary: Accept-Encoding cache-control: no-cache Content-Length: 2494 { "keys": [ "-----BEGIN ENCRYPTED PRIVATE KEY-----\r

MIIFHzBJBgkqhkiG9w0BBQ0wPDAbBgkqhkiG9w0BBQwwDgQIPuxzLnEn6okCAggA\r

MB0GCWCGSAFlAwQBAgQQTbQRk2jToiPndgnKQWI+YwSCBNB4TvHh6YsG2MFE9BEK\r

H8/WVWZswoFncqTSmFzyFegZhNOVSYSvyOFw6p8aCBv7kxeEyNi5GLaMe3COLvc7\r

wyqZrJ4zDacjnTAYouQLe87vbzt2tpzgdBF2Y7wHR6cT6Fp2VsqiSgGgm6q+vLlR\r

S+HnicoWrh3op+GogaXj+tTx1uFuXW3KFZASpAvwlQw/2YT+Q0lxTY2SmiMiNDqY\r

q3kVgQz0FZEqRqHC5G9hZJDUcKEumKiiOVYNAwm5QhdYDCsEBPC2LFY8f1B/eeRt\r

4K2e0Nt27ssFcYqIBHrMcYGjfT3x1qpaRiN+nVFQw8dA38zzfgWTUVYEx4Ng3oaa\r

ZM9HftAc87Sk3L+VV0FweeN7oJT8c/6A5dyKiAHlJC/Hz5vSBnls6I1Ngyq65SOR\r

+6zjDaJujs7oDkuPwP3IGX7DFSCDRMPubkb42ce+fW/8x8WP2c3hz0Q/VaRv45Vi\r

EkBD3oVvH/o3LBtnxjtHSwQzdBYxQuVQz5KRN+/BXGLwVYsC7R1pjvLlrvi4uUG7\r

jXl6EbBfhm61mSy/EZJL+022cQPAunynGKFLlOn2Y3+dRRQDgsTz7qsrdhROC2kn\r

ocUs8Tq0DD/pk372/m+HIkskQKDqGrLPGKM4GJqxV8zYr8prxFG0sdb8UkD2lwQ1\r

jWuv7YfzUc7JHRvlSmTnJ+2gAiogFn/DyUuu1App4jjBxTohBkyupUaz5HXpg8U8\r

/9Ao6MytrKCUZYuU7WqOdpHAo2+e4rvzFuF/HJSbYbHJjh4dnxodhwnFEStfJA1x\r

uOlmRinxYV4u4ubkSKK2mAiNms1sMwHZNNWFdRezIHOCwfNOHkm1vmOC1zVJ2LNS\r

PMiiHh4Qg3KBsy/dyhSu1c/iZdRDDGnlKbAk2XqrbL9mZsLyE1X0LsnqBErfYf8x\r

Y54l8v9ufVboYtQje8qLr66aIIjh7AezJ5vnPha1/jEExHHGUD/xcTGnQf4R+stb\r

aaNyY+Vqv4k7rnpWYUBSJ6rZmAWT9L0niqyiiKzLDHfMa5R4WrUD+yn5nyV9RmMv\r

lkmJ1zVhCXtqLrBUOPpV0aKswUWC9czXXm44IEMfmcr0ky/OoUSNr65Ee/5XbE7l\r

mIGrIAr+I6jQMv/3Q+s4JRskJD+0CR40SkDqvuFzas3A47XL7QEw/fKumdrM2gUq\r

F1m9+RB67c1vQtkCspi8C/YKO3DSQ37VSprsZdwe6yFwmwKYXFSfOEoRGqqA3I+c\r

nVa9wfshsVMNclbWYFChzQc/eAFEKrcnaieM2UnXrq9lAohm99i5z6mzzhRy5CqF\r

LukdxTUhQHdzYXqM/vLgMvfw25Uk6fZyLsm6vXHAfru8NqJvOzNVklik0vFfFXyj\r

nZuVUZxPuB48l53LC2TvcwM2HmkAioKa99nTRCdOkyR04mkHOLRIk3CEF89JDa7G\r

iqfXKg8fxd7SxuKFO0dDJTflKWeQoXtRikVhJ7AIiCnna98Sa6Z1H3MQXiYRj7dE\r

ZxPpqVdvCv+MiXRVFgDidtTRR5XuwfDuCxbGknQ5hpfhrrUpwxdlYpf87u1Zfi9B\r

sXtRYaZ4AhL597S8cWR1GDKD+o6jxwjy7basPVExUgzrDQpneWNs71pg3Do72Nql\r

JoeEq+48GgSB/rNZ6T+EyVcQ5A==\r

-----END ENCRYPTED PRIVATE KEY-----", "-----BEGIN PUBLIC KEY-----

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2ArwcK9t8DhyBTGskFz+Yw1Y8M/iSING

HfwTo0T4q+2J4zIkTP/A9QXG+jDFgfDB8Wfr7WSFtpIG5iqLz68M6bFzjwIvvWWAfceHuRNtjC79

In5NKQBJyqZEh3TT1HcYsJkwnQht4Q1JT7qRG1fIjVkhHHmaQU1YIa++oEC4t9i4tNdTeLjT2Tag

T+35XsEql0+kWHYc/7t7k+1atFW8x65RcWk+Rh137fgGh8Jor4RLO5Wm1gggAjRFPlV+foq+3CHA

8q+XiT996OBchhcgPdLrjMSNcGVSbk8uoOxba2MWLMyO0CAPaxAb+pngqyPdm6XC+bF260ax37xM

o5MCOwIDAQAB

-----END PUBLIC KEY-----" ], "symkey": "F9aneGBMe/s01AcFCSYSa5NMRmu2f7iJdiWZCl2WlDU="

Wait? What? Right. Not only the public but also the private key is stored on the server of the service provider. Though the website says the service provider has no access to the communication, the keys are stored on the server. They are encrypted, but with the knowledge of the user password the whole communication can be read on the side of the provider. Precisely here the most important rule of asymmetric crypto is being violated: Never publish your private key!

By this second, grave mistake the keys are not anymore only in the hands of the user, but one is again left to trust the provider and its software and infrastructure.

If the skills of these two young developers in system administration are es profound as their knowledge of cryptography - what should go wrong?!!1

By the way every user has to trust, that the developers always deliver software that doesn't leak the passwords for the private keys to the service provider. This really can not be called 'secure end-to-end encryption'.

How to fail key management for dummies

Lets have a look at what happens if we start a communication with another user:

GET /key/blubba2/9Xqe4hR7ZB6Y3jjK7aEsOaCrdVUxI3Fg/blubba1 HTTP/1.1 Host: switch.whistle.im Accept-Encoding: gzip Accept-Language: de-DE, en-US Accept: */* User-Agent: Mozilla/5.0 (Linux; U; Android 2.3.7; de-de; HTC Desire Build/GRI40) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 Accept-Charset: utf-8, iso-8859-1, utf-16, *;q=0.7

HTTP/1.1 200 OK Date: Sun, 18 Aug 2013 10:57:36 GMT Content-Type: application/json; charset=utf-8 Connection: keep-alive Vary: Accept-Encoding cache-control: no-cache Content-Length: 471 { "key": "-----BEGIN PUBLIC KEY-----

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoyMSuK8sb/oChvl8Y9XH8IQtHJNwTUEt

br8F+PI2ajd5GywwB1tG6ZDyGZA8heDtjPhLSmSWDQi0m4C4+FbXOUVefIfYXctVGOOGT8Yi2Cwu

4xhJGqCyXy5YCXQtddMLN9XXLotmqSX93R6JdlERHR+vDIStnRo2s5+UPARmW3ZRYu7wEKoYqBln

8Ji9ewpObIL7Q8H6jnVbMQOhrNFw35CxmES8cKJ5J0PTxssKSXQr+3hldNRFZvuIT9arz1NXzAkO

9mqzZXOtZZNizl7F+Gplr3P7SJnYzV5z3GzvMslkE1igJC1cVj1vja9dIvj48s36EAnxh7hpEWGS

ZiupKQIDAQAB

-----END PUBLIC KEY-----" }

At first the key of our communication partner gets transmitted from the server to us. At this point an attacker as well as the service provider could insert an arbitrary key. A magnificent chance to extend the end-to-end encryption by another node in the middle, and read all outgoing communication.

The app doesn't even recognize if it gets send a different key than previously known. Whoever learns the Keys of all friends by hard could notice the change of the key. In this case the different fingerprint of the wrong RSA-key is displayed below the nickname. The people this software is advertised to and targeted at, will hardly know or see.

How to fail privacy for dummies

Beyond this, the server buffers all chat protocols:

GET /msg/blubba2/9Xqe4hR7ZB6Y3jjK7aEsOaCrdVUxI3Fg/blubba1?limit=5 HTTP/1.1 Host: switch.whistle.im Accept-Encoding: gzip Accept-Language: de-DE, en-US Accept: */* User-Agent: Mozilla/5.0 (Linux; U; Android 2.3.7; de-de; HTC Desire Build/GRI40) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 Accept-Charset: utf-8, iso-8859-1, utf-16, *;q=0.7

HTTP/1.1 200 OK Date: Sun, 18 Aug 2013 10:57:36 GMT Content-Type: application/json; charset=utf-8 Connection: keep-alive Vary: Accept-Encoding cache-control: no-cache Content-Length: 3994 [ [ { "inc": null, "sig": "YZDqZc3yyViJa3eY6kY5tlk+T4UHKCQCPkNd2dmF/A8OGDu7ohTAFk7sXCTF3nkDhlht3Wi0zXtDEhZuxTb3AIxSSeN7GNKY2cei5EfLkzqWXnnXA5lWQvRuG9nuea9LIuNlOyxwgnOLHFE2yFNtilBwTBQLWh8x9eSQjc/ZDVXVc31ucbgWkQfWbw0Bof50PDx99BXARVWnccOn7WJt39Sse6Xym0G/7GT8Bm/wEFH6TpOklqHpnadQW5Vdij4wj34nRl76jJNPkeXrpyVP/e0LVe2/IZBY+NCaszWZxtdypfESLaCI3SZwf5sekE2pSsteZJKGlG8x1vklVEq7tw==", "enc": "nBv6IXtD8/LEULH6PjKJQ72Q9BBLD8J6KlGrgkovHXQAagCgx+7+7YuG+XbAaiu+LUsNBZhBUhJu5RX4f2uAPzmeRPXj16IOqN6Ub2Nj79HPJ/7aVrGS0TpQ4UaEgwElvI4LgFJ5VF2/fBeNGCArENmOT81DcqzmQygufDlDYG+fnta1caraSckzuUbO6D+NAaPm6hA6UNzoGBpKP9RhvwisAIkPeOG1x3GPoC1NbhcVlwiRNAaBvC4G5QSSFu1cq6jlj66LMmQh9MlrIFmakd0qo3/3UixF85pnfXMo1Xa8wY/TxWx2gkK7EBAGyByuTsYQ+LSah1YLnEIb0FdcWozn4qsXfSmbP2oxNdJaqlQ=", "to": "blubba2", "from": "blubba1", "_id": "5210a88383b007465601e704", "__v": 0, "time": "2013-08-18T10:57:07.009Z" }, { "inc": null, "sig": null, "enc": "m7+zsAcH17GdhpU0KYpyYI+Y9dH7nH5pIj0CXMaw3cRgx3/6yLUTbQmQP/Maye4KpSA0QOhphgOq12EWO1BnGdskRy6ZCaTR5APgBhw8JogCX9oG+7t5JfkPNS3MN+KP2s2kUo5n72GgxxagPi5GssAgTF+1BFonGwVdjF/Q22wzeqvtPbLrmlXoHv9liT5tKBZEY0rsLgnf/W+JBk3UwSw+ZwcDDwlSIsUWuzv4oDcgFlPpHsyAkSmNDMA8heqBkQ3hPiLh14AuEn8lL6kJ0qo0mAG2Ob3nvZ3cshla3iMaPnfRUxfawXFuj7VO6yljpfOuXQ6llEsE4649mbRqaKC53cDZLp64EufCWEvhokVzoisd8yKMkWAt4SO7odzW", "to": "blubba1", "from": "blubba2", "_id": "52109f5f83b007465601df0e", "__v": 0, "time": "2013-08-18T10:18:07.093Z" }, { "inc": null, "sig": null, "enc": "LodfsnfCs5JZpHm/YnQ/zYWIRqFHA5t2CihkOW42crZ0qjaqp6MePHEi3MQu6snkPDLGfFfjyyFWaGQO3l9sKlK68hHDN4/o8tJk06lKEfv4mbh/qbUXK6ujY5K0t7gAKaODibkUFdzUwAvkEhzLhpEQKFL18Y/hlPGbP+ubmfZEXNUcHbm9LNvZvNfA2X3Rl24LyEFUcMrCG6DNsHoW3j/oM0Nu7TyLp9ESJZaCLiQEw4zUxHa6ipz0HPjy7hHaVQPxBRGEPdzWBBmqFLddlQXvMq2dB3exKGEGxWum48BTolNb6ea0OKP4UEU5B3hOgzAORRW7fRdppinMu/rfZ3x/wCtB5HEesKZyMz/4DxdB2uQfAlME5e7Guj8i3rKj", "to": "blubba1", "from": "blubba2", "_id": "52109f5883b007465601df03", "__v": 0, "time": "2013-08-18T10:18:00.310Z" }, { "inc": null, "sig": "LqWR8HdI65kKOmHV6NA9SWvk9qt1xDfNCaQL1B6vli7wiMYQjBR2QSd3v6qUMnY/l++RQZjVO6UQBVwGXRqNhsh9rmQTf3V5QvxTIDsgDFw0idtVyO1Kjc24CZhtaDr8fw5HECOg7Io7bwsCF1oEatZl1VxOkItyI//wCvG2HWE1j/67PEUS4sxe8tN+7Bpjz/05afdhj310+oScC5M+AFiqJM8xdkqFSBs/JPK56DxTTDHhOexoiqlBwJ7TZSwNwco0RXEbt2J8Wet4w30YpgYl6fZKVVNMifUVQA8laKs/7mFz4rKOMNKdY+/KkKZ2493EnbjimgXs83Ww9nJ79w==", "enc": "YJ4+dqDimSiDCmeO0WVMvpMOjEmEtsAO/99QH0PCZEO6OXZF8ntcT5rwze88gvFax44B3BbAovaPDwnEFMzF1Mk++TWPhBxhu4xQtYQXIY3KtZmLS8WZI71g1sFqebT9+ZKcyuR9RaD6fKhwmNxFCmQUm1yInaO3Q/cmUSFfAU1AJ+v/TniF1wKu1h/IlSqGj/C1i0Eh1lpUIyMxRQSyXoQvwfL9wgP+v4nzQZ2dKtakGmkhdCKnjNi0fOHcznTq1KjU22An6eLyHisk80/5TMYHGhx1YKnoisnq2ax51XGcZaSua/A4BHDTkVe9Gwmw/LGBgmRW6WLxe2h1p0A74thxQf/9xv/IfsI+iLCZ2MDSt4M+ktWQWmx5kr/HBPWY", "to": "blubba2", "from": "blubba1", "_id": "52109f3583b007465601ded6", "__v": 0, "time": "2013-08-18T10:17:25.049Z" }, { "inc": null, "sig": "VOpAsdnGIVKAh4+DtrkaKhKdkxidrIDXmhHtTPZH2QhFfxc5n3P5wrhTBxL46igQEcKvtxTCP3khWcCgdYUVPV4uhqMiWVlmXA4I1InKftIB/Sc0S5MRAuLl3msklCkgAYrADpqCGulqUhT7cyFeI5jPG/VKf83OEw1FBH5ENEXDDkuNfazEJFMP81WRAgKk2n3Q7qvdWTbBrk/VaYvBnLUnvC1DRobYsI9zgoe/BanUsVd0yFT2GemrhmiBzzXQr7RoXlgIu9J2qCarU9LzHZ2V5104Gzt9xQT8v+Q295udV8LnsNN8RBN47Hugziq1V+JJlddK9eLTF/Hu/bd8Bw==", "enc": "cCh1HtsTuYpNaS3eSjKQbTJjuQQ6l8pTLIhEGSTR/WySNy76j/fZas/vd5ijO09AVU+29Q4JWR5y6xa5Wr/+yKa5WC9zt9fHVm9fF4fPx1jXeAN0s0/d1AXJ4zVdVbSenkaeDt+LX47jBRJDih3pf2XQQKsBWZzBd1fv38vHSu/CP8nDD1EpKx0HBmcWhUHwSUiDZmHVBCb1D01C8/K4WAv7nI5v9XWf7i4BPA70yzShq28poLRnk2Cn7nnvtCh4OkqG2Xm/9w9OLbN8qVUBPa2cQKcNZ2dojxchtMFQ25SzeQF5aerx/SQ8qmOleFctj7SBYkUAO/5uucqNV+xQrKafY+cIicJ7S1ORa8Vw1IQ=", "to": "blubba2", "from": "blubba1", "_id": "52109f2b83b007465601ded1", "__v": 0, "time": "2013-08-18T10:17:15.405Z" } ], true ]

his storage in advance allows the service provider to read the messages later, if he gains the password to decrypt the private keys.

whistle.im doesn't even allow a user to switch a compromised key. Once transmitted to the server, it is stored there permanently. If the mobile phone gets infected with a Trojan, the key can be sniffed. A user is forced to create a new account. Not even a usable key-management was implemented here.

Altogether this is a complete fail. The actual analyses only scratch the surface and yet show huge security deficits and a general misunderstanding of cryptographic algorithms. Instead of working with existing solutions and improving them, here, by trying a newer, more colorful method the developers crash-land in cryptography-hell.

The developers should look around and recognize there are usable solution for secure communication, that only lack a user friendly integration. OTR or GnuPG over XMPP were things to mention. Both protocols have flaws. OTR for example is vulnerable to DOS-attacks. But in contrast to whistle.im they can provide at least a little security.

The software only achieves one thing: Its actual being seen as an WhatsApp-alternative. In terms of security flaws it is in no way inferior to its shining example.