Swiss Army's Threema messaging app was full of holes – at least seven

A supposedly secure messaging app preferred by the Swiss government and army was infested with bugs – possibly for a long time – before an audit by ETH Zurich researchers. The university's applied cryptography group this week published research [PDF] detailing seven vulnerabilities in Threema's home-grown cryptographic …

[Pascal Monett]

"infested with bugs – possibly for a long time"

I think it is time for governments and government institutions to realize that it is not because they say it's secure that it is.

Neither is it secure because whoever they contracted to do the job said it is.

And it's especially not secure simply because the contract said it had to be.

It's not secure until a proper security research firm has confirmed that it's secure.

[Charlie Clark]

Re: "infested with bugs – possibly for a long time"

A lot of them don't care that much as long as the servers are still in Switzerland, like many of their bank accounts.

[Anonymous Coward]

Re: "infested with bugs – possibly for a long time"

That's irrelevant is you can replay someone's account or can impersonate an ID as that ends up with a session intercept. That said, there's no statement on what happens when both the actual ID and the impersonated one try to connect at the same time.

In any case, it must have been a wake up call for Threema. I disagree with their statement of this not having real world impact - especially ID private key preservation in backups was a risk that could have been relatively easily exploited so this is more a case of getting away with it than deliberate design.

On the plus side, this has now been fixed.

[katrinab]

Re: "infested with bugs – possibly for a long time"

Switzerland is no longer a good place to hid dodgy money, and hasn’t been for many years now.

[Anonymous Coward]

Re: "infested with bugs – possibly for a long time"

It's not secure until a proper security research firm has confirmed that it's secure.

The question is who do you trust not to sell the bugs to dodgy characters like US Intelligence instead? This wasn't a "firm", btw, it was a Swiss University in Zürich.

That said, I hope this will also prompt 3rd party reviews of Telegram and Signal - might as well have a look at the whole set..

[Anonymous Coward]

Re: "infested with bugs – possibly for a long time"

Mea culpa - they have been. Time to read up on them :)

[JimboSmith]

Re: "infested with bugs – possibly for a long time"

Crypto AG anyone?

[seven of five]

serious, serious bugs

Yes, the serious bugs they found require access to the servers ("In the “compromised Threema” threat model we consider

attacks by an adversary who has gained access to Threema servers")

or an unlocked phone, an unlocked app and then running a full backup. (attacks 6 and 7 from the paper).

Or social engineering (2).

Yes, possible.

[Anonymous Coward]

If you hand someone your unlocked smartphone they can clone your account. That's not very surprising… What am I missing?

[Anonymous Coward]

Where Have I Heard These Claims Before?

@Jessica_Lyons_Hardcastle

From https://threema.ch/en:

"...Thanks to state-of-the-art end-to-end encryption..."

"...no one other than the intended recipient can read transmitted messages, not even Threema as the service operator..."

We've heard all this before. A "service operator" provides E2EE on the service provider's network-based hardware and software.

The E2EE software and the keys used for E2EE are persistent somewhere in that hardware and software.

As usual, the claims are that "your messaging is secure".......but no one mentions that it is the network and the persistent keys which ALSO need to be secure.

It seems to me that a quite different scheme is much more likely to be private:

(1) Use some publicly available transport (say Gmail)

(2) Use encryption/decryption software which exists ONLY on peer devices (i.e. controlled 100% by the customers, not by the "service operator")

(3) Use a protocol which uses a new randomly chosen key for EVERY message

(4) Use a protocol which NEVER uses persistent keys, and which destroys the randomly chosen keys immediately after use

(5) Use a protocol which NEVER transmits keys across any network

Ah, you say, the protocol requirements in items #3, #4 and #5 are completely impossible.........

.....but you would be quite wrong:

- Applied Cryptography, Bruce Schneier, Chapter 22.1

- Cryptography Engineering, Ferguson/Schneier/Kohno, Chapter 11

Around 3000 lines of vanilla C will do the job, and that includes a nice GUI client!

Another quote (William Burroughs): "The paranoid is a person who knows a little of what is going on."

[Anonymous Coward]

Re: Where Have I Heard These Claims Before?

There are a number of practical reasons why you end up with a mix of symmetric and asymmetric encryption for messaging. If you properly want to shut the door you need an out of band method to exchange the secrets that allow the other party to decrypt what you encoded.

Since that is rather hard (certainly in volume), most messaging solutions use the same approach to key exchange, and it gets even more complicated when you want to implement group based communication.

Problem one in any endeavour to encrypt is that reality tends to get in the way. You will always end up with a balance of risk versus cost (monetary as well as resources). Risk assessement will drive the choices, and that's what you have to evaluate of every solution. If that assessment model is not available, avoid altogether.

[MJB7]

Re: Where Have I Heard These Claims Before?

> the keys used for E2EE are persistent somewhere [on the service provider's network]

Only if the software is badly designed (as Threema seems to have been). When I was working for a company providing E2EE mobile comms (based in Zürich as it happens), the private keys never left the phone. That's easy to arrange.

[Anonymous Coward]

Re: Where Have I Heard These Claims Before?

@MJB7

Quote: "...the private keys never left the phone..."

Other quote: "....destroys the randomly chosen keys immediately after use..."

So.......no persistent keys anywhere.......and then there's a couple of published references as well!

.........but maybe you were not paying attention!

[BRYN]

Crypto Virus Writers

It cant be that hard to write a secure app for messaging. i mean crypto-virus writers are constantly outsmarting decrypter antivirus' apps. If the shady half of the internet can do it why does the legit half struggle?

[Anonymous Coward]

Re: Crypto Virus Writers

Ever tried to get support for a crypto virus that isn't working?

:)

[katrinab]

Re: Crypto Virus Writers

The shady side only needs to get lucky once, the legit side needs to get lucky every time.

[Anonymous Coward]

"Ideally, any application using novel cryptographic protocols should come with its own formal security analyses"

Ideally any application using novel cryptographic protocols ***should not do that***.