New app release notes: v 5.0.2 (Android) & v 5.3.1 (iOS)

[danielagotenna]

Hi all, we have yet another release today — that’s 5.0.2 on the Play Store (Android) and 5.3.1 on the App Store (iOS)…

Primarily there are 2 updates in this release:

1. A vulnerability fix. (More below.)
2. A stability fix for v1 non-meshing goTennas on very, very old firmware. (Doesn’t likely apply to most anyone here on Mesh Community.)

Enjoy & thanks!

===============================

goTenna Vulnerability Description

Due to how the goTenna Messaging Protocol is setup, it is possible for a malicious individual to sniff the goTenna RF or BLE packets and determine the exact GID (goTenna ID) of any individual who is sending messages over goTenna. When you send a message, your individual GID is included with the message in plaintext, this is by design, we need to know who sent the message in-order to decrypt it on the other side.

This however brings up an issue. If someone knows your individual GID, they can then use the Developer SDK we provide to set their GID as an existing user’s GID (there is no way to prevent this in the SDK. We need to allow developer’s to set their own GIDs). This means that someone could essentially pretend to be you on the goTenna network.

Alice - goTenna User
Bob - goTenna User being impersonated
Charlie - Hacker who is pretending to be Bob

• Alice and Bob have been talking to each other using goTenna for a while.
• Charlie sniffs goTenna RF/BLE packets while Bob is transmitting and figures out Bob’s personal GID.
• Charlie uses the goTenna SDK to set his goTenna GID to be the same as Bob’s
• Charlie can now can pretend to be Bob on the goTenna network, sending messages to Alice, while Alice has no clue this is not actually Bob.

Vulnerability Fix

In the situation where Charlie pretends to be Bob, Charlie still has his own private Public/Private Encryption Key pair. When Charlie then talks to Alice for the first time (pretending to be Bob), a new key exchange will need to occur. We now detect when a suspicious key exchange has occurred (Alice already has Bob’s public key, why is Bob handing Alice a new one? Suspicious!) and alert the user that a suspicious key exchange has occurred using an Alert or Push Notification. It is then up to the user to confirm the identity of the person they are talking to.

It is possible in rare cases that this alert will be triggered when there is no real threat, and instead, a legitimate additional key exchange needed to occur. An example of such a situation is below

• Alice on-boards using a random GID or cell phone number
• Bob on-boards using his cell phone number
• Alice and Bob initiate a conversation with one another
• Bob for some reason, needs to uninstall and reinstall the mobile application
• Bob uses the same cell phone number to onboard again
• Bob re-initiates a conversation with Alice
• Alice will get an alert that a potentially suspicious key exchange has occurred.

This same issue could also occur if Bob has the goTenna app on-boarded using the same cell phone number on two different mobile devices, and likes to switch between the two of them. Most normal users should not see these edge cases. There is no way to effectively distinguish between these edge cases occurring, or a legitimate impersonation attack.

If any further questions, @tcolligan and @anon62894636 can answer questions!

[aspexin]

Version numbers need correcting. Play store says Android version is 5.0.2. And the iOS version numbers are different in the title from the text. But overall thanks for the update!

[MikeL]

Downloaded and installed the 5.3.1 app update from the App Store in less than 2 minutes onto my iP5. Absolutely painless.

[setuid]

@danielagotenna

In the situation where Charlie pretends to be Bob, Charlie still has his own private Public/Private Encryption Key pair. When Charlie then talks to Alice for the first time (pretending to be Bob), a new key exchange will need to occur. We now detect when a suspicious key exchange has occurred (Alice already has Bob’s public key, why is Bob handing Alice a new one? Suspicious!) and alert the user that a suspicious key exchange has occurred using an Alert or Push Notification. It is then up to the user to confirm the identity of the person they are talking to.

Speaking with my “NetSec” hat on for a moment, there should be a way within the app itself, to ‘reset secure session’, much like the Signal Messenger app does for example.

Signal also has the notion of ‘disappearing messages’ which is really nice to have too. With that, you can have conversations ‘in the clear’, that expire and don’t get seen after the expiry (or in the case of mesh, erased from the nodes that transmitted them after their expiry).

The bigger problem with the key exchange, and one that is regularly used to break WPA on WiFi networks, is forcing the clients off, then causing them to re-auth, which would initiate that key exchange, where in this case Charlie would talk to Alice pretending to be Bob, and then Alice would reject Bob’s key as invalid (because she’s already talking to “Bob”, so who is this 2nd Bob?).

That has to be accommodated, or you end up solving one problem, but leaving another one open to exploitation.

Something to think about. It’s defintely heading in the right direction, but we have to make sure we have the ability to reset, or force re-auth in the client-side as well. “This doesn’t seem like Bob, let me reset and try again.”

Thoughts?

[MikeL]

@setuid

Signal also has the notion of ‘disappearing messages’ which is really nice to have too. With that, you can have conversations ‘in the clear’, that expire and don’t get seen after the expiry (or in the case of mesh, erased from the nodes that transmitted them after their expiry).

IIRC, once the relay forwards the message, it’s gone.

[MrTSolar]

Disappearing messages is an awesome feature if an endpoint device is compromised (phone stolen while unlocked for instance), however it wouldn’t help with this scenario as the messages are being sniffed while in transit.

Would you folks agree that most times that a chat is initiated between two goTenna users (or even a group) that everyone is near each other? Perhaps have an option to do a key exchange using a QR code or SMS (if cellular is available)?

[MikeL]

Here, messaging can start several hops away just as easily as close by. But I still like the idea of a key exchange/update option. That could be a good practice for groups starting a day out, whether at the amusement park or canvassing for a political campaign.

[tcolligan]

I think I understand the situation you are describing, but let me try to re-explain it to make sure we are on the same page.

• Alice and Bob setup their goTenna devices.
• Charlie determines Bob’s GID before Bob has a chance to talk to Alice.
• Charlie then initiates a conversation with Alice, pretending to be Bob. Alice is none the wiser.
• Bob then tries to initiate a conversation with Alice, but then Alice goes “who is this new Bob?” when actually it is the real Bob.

To solve this, you think a “force re-auth” button of some kind would help, which would force a key exchange to occur again, or wipe out a locally stored key to start the whole process over.

If I am right about what you are saying (and please correct me if I got something wrong), I don’t really see how the client side “force re-auth” would truly help. It could force another key exchange to occur, but there is no way to guarantee that this new key exchange is occurring with the real Bob or the fake Bob. Since this is an offline distributed network, there is no single trusted source that is able to validate someone’s identity.

Also with regards to ‘disappearing messages’, the way the system is setup, messages are already fairly ephemeral. A node only holds onto a message to transmit for limited period of time, as soon as it gets an ack confirming receipt then the message will be wiped. Received messages are also stored in flash on your goTenna until the mobile app connects to it and pulls the stored messages. As soon as the app pulls the message from the goTenna, it is deleted from that goTenna device, so the message would only exist on your phone and the sender’s phone.

[aspexin]

I think they mean to have messages disappear on the gotenna app in the phone too.

[MikeL]

@aspexin

I think they mean to have messages disappear on the gotenna app in the phone too.

Everyone has their own levels of comfort with security. Phone with its own data shredder app, anyone?

Personally, so long as I physically control the asset with the data secured on it, i.e. the phone, I’m OK, While recent news stories have related efforts to crack iPhones, doing so remains not trivial

[setuid]

@MikeL

Personally, so long as I physically control the asset with the data secured on it, i.e. the phone, I’m OK, While recent news stories have related efforts to crack iPhones, doing so remains not trivial

We’re not talking about ‘cracking into’ phones, we’re talking about plausible deniability. This is especially important in places where your device can be demanded, cloned and its data stored for later perusal by authorities or other nefarious agencies.

This is also why you should never, Ever, EVER use a fingerprint or biometric to secure or ‘lock’ your device (at least not in the US), because fingerprints and facial recognition is not protected against discovery.

This means law enforcement can walk into a room, demand everyone’s phones and fingerprints and unlock each one of them, clone the device and walk away with its contents. There is already precedent here, and it has already happened in a few cases.

Using a passcode/passphrase is protected, and cannot be demanded by law enforcement to unlock your device, but fingerprints can.

For those who may be using a mesh network to communicate ‘off the grid’, or assemble groups for a political rally or any other legitimate or questionable use, being able to have the device digitally shred those messages is critically important.

If protesters at Occupy Wall Street for example used GTM devices, had their phones seized, fingerprints used to unlock those devices and the contents of the Shouts gathered and catalogued, it would probably have been a lot more damaging and litigous than it currently was (with telco privacy laws in place at the time; those have been eroded now).

I’m all for the various discussions and opinions about what should-and-should-not be possible, adding this capability to the goTenna app makes it more flexible and could increase adoption in areas where this is a concern.

Protests in Turkey and most-recently the students in India where Internet was physically turned off by the government are two great examples of where GTM and mesh networking could continue to provide services to the people without having to use the public Internet.

[setuid]

@setuid

We’re not talking about ‘cracking into’ phones, we’re talking about plausible deniability. This is especially important in places where your device can be demanded, cloned and its data stored for later perusal by authorities or other nefarious agencies.

Something else that may be relevant, is that you don’t control what comes across your GTM, Shouts, relayed messages or otherwise. Other than shutting it off, you can’t filter what your GTM receives or relays on your behalf or on behalf of others “near” you.

What if someone decided to use the mesh network you’re on to conduct illegal business? Send updates for where drug drops could be found? CP? Terrorist movements?

Your device, having cached those messages, is now discoverable in the eyes of law enforcement, whether you like it or not. You can’t be asked for information you don’t posess, and if goTenna messages were set to disappear after ‘n’ minutes/hours/days, it makes that position much easier to defend.

This is part of the reason why many VPN providers proudly advertise that they shred logs to avoid any culpability in their user’s activities. VPNs aren’t anonymous, so you can be found using a VPN and your logs and activity can be subponead, but theirs can’t, if they don’t have them.

Food for thought…

[MikeL]

@setuid

We’re not talking about ‘cracking into’ phones, we’re talking about plausible deniability. This is especially important in places where your device can be demanded, cloned and its data stored for later perusal by authorities or other nefarious agencies.

I don’t disagree with this, but I do not think this is a feature that goTenna claims for the Mesh. Theirs is a qualified assertion that it is a reasonably private and secure. As the part of my comment you didn’t cite suggests, some users may need a higher level of security. As you pointed out, the choices the user makes are what is determinant in systems that are NOT asserted to be unbreakable by current known technology. Want the goTenna to be relatively more private and secure? Then don’t use your cell # as a GUID, for just one example. GoTenna can’t make those choices for you, only you can and thus only the user is responsible for that. Same thing with your example about the use of biometric data to secure a device. Yep, use a code, not you fingerprint, etc

Yes, it’s the user who has to make the choice, once again EXACTLY where goTenna has always placed itself by giving users multiple choices about privacy and security. Yep, it can be confusing, frustrating, and at a certain point, even counterproductive to become too obsessed with security unless you actually have a clear need for it.

What’s the biggest clue that goTenna is making no such excessive claims about the GTM’s security? There is no munitions export licensing required of customers overseas. If there was high-level encryption built into the GTM, then it would be treated like any other munition in terms of the paperwork. GoTenna has a product like that, which I assume proper licensing is needed for pretty much that reason.

Does it mean that the GTM is not secure? Hardly, because even civilian-grade cryptography is pretty powerful stuff these days, good enough to discourage most everyone except nation-states from routinely trying to break it. Sure there are a few agencies below the federal level who might pursue this sort of thing, but it’s just not in the skill set of those other than the NSA and the military services. They tend to use products they can purchase or consultants they hire and the NSA for the most part discourages anything other than very limited competition for its nearly exclusive control over making and breaking codes that have strength beyond that found in commercial applications of crypto. How that is done goes way beyond this discussion.

You mention Occupy and allude to many similar situations in the past where goTenna would have been handy. Yes, if people thought it was only the device that protected them against official scrutiny, that is mistaken thinking. And to me the very first necessary belief about this is to understand that they are not completely secure, but provisionally secure depending on the best practices of their users. And there are a number of things that can be implemented in messaging in general that certainly can be applied to messaging with the GTM. The biggest exception to that would be invisible ink, which I don’t think has been digitized yet other than in conce ptual form.

@setuid

Something else that may be relevant, is that you don’t control what comes across your GTM, Shouts, relayed messages or otherwise. Other than shutting it off, you can’t filter what your GTM receives or relays on your behalf or on behalf of others “near” you.

Sorta, maybe. Since most messaging on mesh network is directed to specific addresses - and they can be blocked from replying to you - there stills things one can do about this.

Even Shouts can be blocked, in general. And sure, cops are notorious (depending on the jurisdiction) for charging all sorts of stuff to pressure people that later gets thrown out. But I doubt any judge would convict anyone over a Shout that ended up on their phone in the absence of something more to tie that to a defendant’s alleged crime. Anyone with a GTM can make a Shout to anyone within reception range who has a GTM on and Shouts not blocked. Similar rules apply to the SMS relay. There would need to be substantive additional evidence to prevent a defense attorney from being granted a motion against introduction of a Shout as evidence against their client if they understand how Shout works.

@setuid

Your device, having cached those messages, is now discoverable in the eyes of law enforcement, whether you like it or not.

Didn’t say I was liking it. I was only suggesting I’m comfortable enough with the encryption and what might be on my “phone”* that the GTM meets my needs.

Nowadays, I’ll bet that’s probably very similar to 95% of the rest of GTM users. I say that not to be dismissive of the needs of the other 5%. Indeed, I champion their use of GTM to achieve good in a society that all too often rewards, admires, and holds up those who coarsen and degrade our society for their own benefit and their unfortunate-for-the-rest-of-us decision to use state power against those who oppose injustice. Is that a mistake?

Not if they pay attention to the principles I’ve articulated here. In fact, for probably 95% of what they do, there’s nothing illegal or unwarranted on the table. If they’re smart, there will be zero% of that on their goTenna app’s record of their use. As I discussed in another note about navigation expectations, you shouldn’t relay only a GTM for sensitive communication any more than you should rely solely on it for emergency comms when they are needed. Use your backup or some other means more ephemeral than a goTenna Mesh if you’re up to something that is short-term naughty, but long-term nice. There are other strategies, too.

All suggest to me that it’s the user’s skill in discerning what’s appropriate to do on your GTM that goes a very long way towards resolving such security concerns. This takes education, message discipline, and a stubborn will to communicate on the part of the security-conscious user. I think the goTenna Mesh is a great base on which to apply those principles, but I agree with you that it should not be considered a panacea for such security issues.

[MikeL]

@MikeL

Downloaded and installed the 5.3.1 app update from the App Store in less than 2 minutes onto my iP5. Absolutely painless.

Things did seem OK on 5.3.1 after the update. Then I was doing some inventory and checking up on the last couple of GTMs pulled from stationary nodes this evening with the iP5. I unpaired, then started trying to pair with various GTMs. I could not get any of them to pair! Hmmm.

Went to the truck to get the iP6 out of it and try my luck with it. I happened to notice is had not received the push to update from 5.02. It paired with the first couple of GTMs I tried, then it hung up, too. A check showed it had also gone to 5.3.1. Dang, something’s just not right. Then it somehow reverted back to 5.0.2 after several more failed pairing attempts and it was good to go with pairing again.

I tried the iP5 again and it was a dog still on 5.3.1, won’t pair with anything right now. Bluetooth is ON, I’m connected to the wifi, but it shows iOS 10.3.3 as “up to date.”

The iP6 got an update to iOS 11.4.1 it’s digesting. Then the GTM it’s paired with right say it’s about 4 minutes to installing the 1.1.8 firmware, which it did and finished. I took it back out to the truck and repaired it with the GTM on its roof. As I was finishing that I notced it had again advanced to 5.3.1, but this time it seemed OK with pairing. It’s late and Ii’ll do more testing in the morning.

My iP5 is definitely having issues starting just today. Anyone else having similar problems with the iP5 after the iOS 5.3.1 update?

[giqcass]

SMS is not very secure. I would NEVER use it for a key exchange. I don’t even like it as a second factor method. I Don’t think QR is appropriate for key exchange either. QR could be used after the key exchange to verify identity but a simple number on the screen or code word would be more suitable.

[setuid]

@giqcass

I don’t even like it as a second factor method.

Not only is it bad, it’s one of the most insecure methods of verification there is. Even NIST is recommending not to use SMS for 2FA.

• This is why you shouldn’t use texts for two-factor authentication - The Verge
• Standards body warned SMS 2FA is insecure and nobody listened • The Register
• End of SMS-based 2-Factor Authentication; Yes, It's Insecure!
• https://www.howtogeek.com/310418/why-you-shouldnt-use-sms-for-two-factor-authentication/
• The Limits of SMS for 2-Factor Authentication – Krebs on Security

At one client I support, we have a small, credit-card sized device that is effectively 4FA. It has an OLED screen on the front + fingerprint reader and a light sensor on the back of the card. It’s about the thickness of 2-3 credit cards stacked together and has a micro-USB charging port for flashing the device and keeping it powered.

Authentication and authorziation goes like this:

1. Log ito machine/app with standard username/password (“Something I know”)
2. Launch applicaton or browser page to specific internal site protected by this authen+authz
3. Provide SSO credentials (required to be different than OS/machine login)
4. I am prompted to swipe my finger on the credit-card sized device. Successful swipe returns a 6-digit code, which I must enter to proceed. (“Something I have” [card] + “Something I am” [biometric])
5. Upon successful acceptance of the 6-digit code, the browser or mobile device will show me a small, rectangular pattern of rapidly flashing dots/pixels.
6. I hold the back of the credit card device (the side with the light sensor) up to the screen, where the light sensor can interpret the flashing pattern. The OLED screen on the front shows a progress bar while it reads this pattern of flashing dots.
7. Once the progress bar on the card reaches 100%, I am given a 4-character alphanumeric code, which I must enter into the wepage or app to authorize myself to that application or internal site.

This works very seamlessly, across phone, tablet, OS and in-browser without any plugins.

It’s impractical for this to be implemented across all websites and devices, but it’s something to think about, because standard biometric, SMS intercept and other 2FA is inherently insecure.

[giqcass]

I like that! What I really want right now is a device that does U2F and is a hardware password manager for sites that don’t support U2F. I also want the device to require a pin or fingerprint before it can be used. I found something really close but I need it to also self delete if too many failed attempts are made well trying to activate it. I could not get an answer regarding whether it does that.

Amazon.com: OnlyKey with Stealth Black Case - Hardware Password Manager, 2 Factor, Secure Communication (U2F, YubiKey OTP, Google auth, SSH, PGP/GPG) Make Password Hackers Obsolete.: Computers & Accessories

[MrTSolar]

Would the Trezor do what you are looking for?

What I was proposing by QR/SMS was simply some method of verification that didn’t rely on using the goTenna radios, cutting the imposter out of the loop.

[giqcass]

@MrTSolar

Would the Trezor do what you are looking for?

That’s on my short list but I’m still evaluating options.

I’ve been thinking about the imposter problem as well. I think suspected imposter messages should pop up in red in a new chat window. The app should then ask if you want to verify them as a current contract or a new contact.

There could be an option for verified contacts. For them you would share a short key or “safe word” that they could use across multiple devices.

[aspexin]

The only problem with a hardware solution is it works until it doesn’t. I had a FIDO bluetooth key for a specific phone. One day the phone had issues and my only option was a factory reset. After that I couldn’t get the phone and the FIDO key to see each other anymore and this appeared to be an issue with the FIDO key as I could connect the phone to other bluetooth devices.

The short key or safe word would be my preference.