Message encryption protocol

[aspexin]

@armin

Re: “state actors” and the false distinction fallacy

I really have to disagree with this point. State actors have a mission and that one mission is to gain access to Alice’s phone no matter what. They will have advanced knowledge of exploits, hardware to find those exploits, money to pay to build that hardware, people to throw at the problem, etc. The local person down the street isn’t going to have any access that a state has access to. Look at how many security holes have been out there for decades while the manufacturers were never contacted to fix those security holes. There is a reason the manufacturer didn’t find those security holes through their own testing (lack of time and money and laziness). State actors are involved in solving problems like the “air gap”. Certainly no one local to me is looking into that capability. Do you use a computer made in China? Does it have the snooping “chip” everyone has been talking about? Or the routers all your data flows through infected with the same snooping “chip”? That is why state actors have the upper hand that we as commoners will never be able to overcome. We can have all the greatest security in the world undermined by some unscrupulous state actor that beat us to the punch.

@armin

@aspexin, if you need to rely on phone’s encryption and screen lock as your single line of defense, you’ve lost. Ask me why.

I’m not sure why I’ve lost. I don’t do anything on my phone that is “important”. I didn’t say I only depended on screen lock and password. I merely stated that is good enough for most people. If I lived in a suppressive country then I might be taking other precautions. As it is I’m pretty good that my phone is secure enough for its primary purpose (to make and receive phone calls). All other uses are secondary and non-critical. I do not have any sensitive personal accounts installed on my phone (bank, credit card, etc).

I’m also not worried about anyone sending a gotenna text as I know for a fact I’m the only gotenna mesh user in my neighborhood and all the mesh units I’ve distributed have never been paired to a phone and are in stationary relay mode. My wife has one but it is never on. Probably will not be unless we are in the middle of an emergency.

Again, if there is a reason for security that needs more than what has been done and if there are mitigating factors that can be used I’m fine with it.

[MikeL]

@armin

A cryptosystem is either secure or insecure.

That statement is simply false. It does make for stirring up passions, as well as being dismissive of the obvious.

This statement is true.

All cryptosystems are insecure.

How insecure they are is purely relative, never absolute.

But whether you’re simply an operator who’s been told their system is encrypted and they assume anything can be communicated in perfect privacy OR they are the sort of person who simply likes arguing for their favorite means of encryption that makes them feel all warm and fuzzy, there is no absolutely secure system. The very fact that you suggest that such a thing exists shows you barking up the wrong tree with this entire argument.

Your line of reasoning on this just happens to be the Golden Strawman of Crypto, something that is ethereal, at best, but something no one has yet be able to get their hands on. It’s nothing more than chasing a mirage.

And, seriously, does anyone really think that the example that they might have in mind as (mistakenly) representing a secure system – and I can think of many, all broken in the dust, but which at one time were thought quite highly of considering the millions (maybe billions) invested in them – should nonetheless serve as a comparable counterexample to a tiny device that is readily available to consumers for under a $100?

The goTenna Mesh is not meant, intended, or sold as representing such a (realistically) unavailable device. It is intended to secure ordinary communications against snoopy people.

If you’re worried about people following you home and doing whatever, then you’ve got bigger issues than worrying about getting some sort of Consumer Report for the Paranoid so you won’t, in your eyes anyway, think you’re being frivolous with your purchasing power.

For what it is, at its low price, the GTM provides a lot of value and a pretty good amount of security for dealing with the ordinary trials of life. Think of it this way. You don’t need a munitions license to export it, so it’s not something that Uncle Sam worries about ending up in the wrong hands. Which is not reassuring if you’re worried about state level actors ruining your day. But to get better security than that you would need a device that requires an export license to ship outside the US in order to legally get your hands on something better. Unless there’s something you can refer that actually IS more secure than the GTM and is as readily available, this is largely a moot question anyway and beyond the practical needs of most GTM users.

You might consider stepping up to the goTenna Pro, if you have the licensing/credentialing to acquire them. Still not totally secure.

Ultimately, there is no viable market competitor here that is more secure than the GTM. Be wise in your use of the GTM, just like any cryptography. That’ll get you further down the road than hand-wringing over it not being something that no other crypto system has yet to achieve either, no matter what its cost.

[Legs]

Hi @armin, all,

On the subject of MITM, I’ve got bad news and good news.

The bad: yes, there’s a MITM vulnerability in the protocol, and not just in the initial handshake but at any later time. An attacker can send a crafted public key response message (content-type 15 if you’re familiar with the message format) from Alice’s GID to Bob with Eve’s public key, and it will overwrite Alice’s original key in Bob’s records, so all messages from Bob to Alice going forward will be encrypted with Eve’s public key. Eve wins.
Bill of materials: one laptop (or Pi for covert deployment), one goTenna Mesh, no exotic hardware required.

The good: some mild mitigation exists that would make an attacker’s work somewhat harder:

• Every time a public key is replaced using the method above, a warning message will pop up on Bob’s screen that Alice’s key has changed. However, the message is purely informative and offers no options or countermeasures.

• Every time Alice’s app receives a message that it can’t decrypt (which will happen every time Bob sends to Alice’s GID with Eve’s key), the app will initiate a key exchange (content-type 14) with Bob using her original key, which may overwrite Eve’s key and “heal” the key agreement. This won’t stop the attack, it just means that Eve needs to monitor the healing attempts and keep re-injecting the new key.

The ugly: At the end of the day, all these mitigations didn’t prevent this attacker from achieving and retaining a full MITM position. In the tests, Eve was able to recover 100% of the messages content in real time, however it was an ugly, noisy, messy attack that wouldn’t have gone unnoticed in the wild and left me feeling more dirty than happy.

@armin,

If you haven’t yet, definitely indulge yourself some goTenna’s this Xmas. It’s a really great system with serious potential and lots of fun. OK, so maybe the app sucks, but this doesn’t change the fundamentals of the platform. Join one of the open source projects to write a better app or wait for the next version.

@MikeR and team,

I know you’re good people and you’re listening:

1. Is there a legitimate reason for accepting unsolicited type-15 messages outside of a key exchange? If not, consider taking a more stateful approach and dropping any type-15 messages not received in response to a (recent) type-14 message. See above for why.

2. You need some better user interaction around the action of replacing a key (a highly suspicious action with critical impact as shown above). If the only option is “OK”, the user will take it. At a minimum, better wording and a YES/NO dialog would be helpful. Or a key lock/unlock switch to make the changes more deliberate.
   Or even better, why not let the user show and compare key fingerprints, like everyone else does?

[aspexin]

@Legs

I know you’re good people and you’re listening:

1. Is there a legitimate reason for accepting unsolicited type-15 messages outside of a key exchange? If not, consider taking a more stateful approach and dropping any type-15 messages not received in response to a (recent) type-14 message. See above for why.
2. You need some better user interaction around the action of replacing a key (a highly suspicious action with critical impact as shown above). If the only option is “OK”, the user will take it. At a minimum, better wording and a YES/NO dialog would be helpful. Or a key lock/unlock switch to make the changes more deliberate.
   Or even better, why not let the user show and compare key fingerprints, like everyone else does?

I know when my Pixel XL was warranty replaced we saw the warning dialog and I was surprised that OK was the only option. I agree that showing the fingerprint so people can compare them would be a good thing.

[armin]

Hey @Legs, thanks a lot for the confirmation, impressive stuff.

(off-topic paragraph removed with apologies)

@MikeR and app devs, I’d like to add a suggestion to what @Legs and @aspexin have discussed, for hardening of key exchanges UI without altering the existing protocols and formats.

You could add an out-of-band key exchange method, using QR codes for example, along with a switch to turn off over-the-air key exchanges completely.
When adding a new contact, the app could offer the options to exchange keys via direct screen-to-camera QR scanning if physically practical, or turn on the OTA key exchanges for a limited time only (30-60 seconds) to minimize the window of opportunity for a MITM attack.

[armin]

@Legs

The key is generated by the app on first run and stored on the phone in a weakly obfuscated form (encrypted with a strong algorithm, then the key stored nearby).

@MikeR any comment about the above? I was able to capture the SECP384R1 private key from a rooted Android phone (a mandatory step that @Legs and Donncha forgot to mention), so it’s definitely confirmed.

For the wishlist:
It would nice to have an optional user password in addition to the obfuscation key from SharedPreferences. By default, only the shared key would be used (like you do now), however, if the user opts to use a password, just mix it with the shared key in the PBKDF2_HMAC step and prompt for it on app startup.
This would raise the bar for private key capture from simple at-rest device imaging to harder tricks to pull covertly like keyloggers, live seizure or rubberhose.