Meshtastic Capabilities

Builds / Use Cases
12

This is what ATAK does without us doing anything right?

I view many of these security suggestions as theater, this thread and others like it are full of false security assumptions (encryption means end to end encryption, dev boards can be secured once someone has physical access)

This is the security that is actually in place now

There is a whole section that is several years old on possible future areas of work (if there is enough interest). There have been some additional suggestions / issues created in what I consider the theater category but nobody has ever dug in and done any of the actual work. I would suggest this is a pretty strong indication that there is not a lot of real interest in this, especially with ATAK being available.

13

What does a relay node need to change from a message payload before repeating it, beside the hop count ?

From what I understand so far, a relay needs to listen to a LoRa channel for incoming packets, then filter Meshtastic messages, and repeat them decreasing the hop count. In this case, it should be possible repeat messages whose payload can not be decoded, isn’t it ?

BTW, for those interested, here are some thoughts about more clear separation between LoRa channels and Meshtastic channels : Encryption / Secondary Channels - #9 by Eagle

Cheers

1 Like
14

How is asking about keeping about keeping physical access to a node encrypted, theatre? Seems like a legit concern.

1 Like
15

Lol, yes. You are essentially talking about off grid decentralized internet.

Encrypting a string of text with a pre shared key is probably the fastest work around, assuming I can find a good open source app. Just copy and paste between encryption app and Meshtastic app.

I guess I could get a terminal shell and run gpg command line on the phone for encrypting and decrypting strings, but that would definitely hurt ease of use.

1 Like
16

@Edward you might find Reticulum Network Stack | unsigned.io interesting.

I’m hopeful Meshtastic might one day use it, but the C port needs to be completed first

2 Likes
17

Okay found a great app for this.
Open key chain. It is open source and uses gpg encryption standards.

For predetermined passwords

1 Install and open app

2 Go to side menu. Hit encrypt/decrypt

3 Hit encrypt text

4 Change settings to “use password”

5 Enter password and the string of text to encrypt, and hit button to copy encrypted text to clipboard

To decrypt

1 copy encrypted text and open openkeychain

2 go to side menu, hit encrypt/decrypt

3 select read from clipboard. Enter in password

The app also supports signing with public and private keys etc. Their is also an app called pgp clipper that should integrate this more seamlessly with the clipboard, but I haven’t figured out how to use it yet.

It seems that running this setup on a secure hardened, degoogled, android, like GrapheneOS, should makes this Meshtastic use case pretty freaking end to end secure, without any “theatre”.

18

If I get physical access to your android phone or windows laptop with boot loader security, I still have a decent chance of being able to compromise your device. Pretending that a captured dev board with zero boot protections can be secured once somebody has physical access is theater.

19

The Android phone won’t be the device on a solar panel hidden in the woods. And hardened android with a secure boot loader, and enhanced verified boot is pretty good anyway. GrapheneOS uses an enhanced version of the modern filesystem-based disk encryption implementation in the Android Open Source Project. The officially supported devices have substantial hardware-based support for enhancing the security of the encryption implementation. GrapheneOS has full support for the hardware-based encryption features just as it does with other hardware-based security features.

The data partition stores all of the persistent state for the operating system. Full disk encryption is implemented via filesystem-based encryption with metadata encryption. All data, file names and other metadata is always stored encrypted. This is often referred to as file-based encryption but it makes more sense to call it filesystem-based encryption. It’s implemented by the Linux kernel as part of the ext4 / f2fs implementation rather than running a block-based encryption layer. The advantage of filesystem-based encryption is the ability to use fine-grained keys rather than a single global key that’s always in memory once the device is booted.

Disk encryption keys are randomly generated with a high quality CSPRNG and stored encrypted with a key encryption key. Key encryption keys are derived at runtime and are never stored anywhere.

File data is encrypted with AES-256-XTS and file names with AES-256-CTS. A unique key is derived using HKDF-SHA512 for each regular file, directory and symbolic link from the per-profile encryption keys, or the global encryption key for non-sensitive data stored outside of profiles. The directory key is used to encrypt the file names. GrapheneOS increases the file name padding from 16 bytes to 32 bytes. AES-256-XTS with the global encryption key is also used to encrypt filesystem metadata as a whole beyond the finer-grained file name encryption.

The OS derives a password token from the profile’s lock method credential using scrypt. This is used as the main input for key derivation.

The OS stores a high entropy random value as the Weaver token on the secure element (Titan M on Pixels) and uses it as another input for key derivation. The Weaver token is stored alongside a Weaver key derived by the OS from the password token. In order to retrieve the Weaver token, the secure element requires the correct Weaver key. A secure internal timer is used to implement hardware-based delays for each attempt at key derivation. It quickly ramps up to 1 day delays before the next attempt. Weaver also provides reliable wiping of data since the secure element can reliably wipe a Weaver slot. Deleting a profile will wipe the corresponding Weaver slot and a factory reset of the device wipes all of the Weaver slots. The secure element also provides insider attack resistance preventing firmware updates before authenticating with the owner profile.

Standard delays for encryption key derivation enforced by the secure element:

  • 0 to 4 failed attempts: no delay
  • 5 failed attempts: 30 second delay
  • 6 to 9 failed attempts: no delay
  • 10 to 29 failed attempts: 30 second delay
  • 30 to 139 failed attempts: 30 × 2⌊(n - 30) ÷ 10⌋ where n is the number of failed attempts. This means the delay doubles after every 10 attempts. There’s a 30 second delay after 30 failed attempts, 60s after 40, 120s after 50, 240s after 60, 480s after 70, 960s after 80, 1920s after 90, 3840s after 100, 7680s after 110, 15360s after 120 and 30720s after 130
  • 140 or more failed attempts: 86400 second delay (1 day)

Invalid input outside the minimum or maximum length limits of the UI won’t trigger an attempt at authentication or key derivation.

The password token, Weaver token and other values like the OS verified boot key are used by the TEE as inputs to a hardware-bound key derivation algorithm provided by the SoC. The general concept is having the SoC perform hardware accelerated key derivation using an algorithm like AES or HMAC keyed with a hard-wired hardware key inaccessible to software or firmware. This is meant to prevent offloading a brute force attack onto more powerful hardware without an expensive process of extracting the hardware key from the SoC.

But, the point is if someone captures the relay node when messages are encrypted with gpg the only thing they will see is:

-----BEGIN PGP MESSAGE-----

jA0ECQMCybZb1DYq079g0kMB/Brl/vkjVWQj84NhBkDHwrPT8jP7aryXS2Jn0oQk
K+u3L1OcC6lXcOMpAliW+bAQmq/gTKuwPt8zefzB9MEKiUHz
=vtLv
-----END PGP MESSAGE-----

The node will be the hardware hidden in the woods, not the android.

20

@Edward It’s not theater. I agree with you, this should work by default.

This app seems to be one that makes it easy to encrypt/decrypt: https://play.google.com/store/apps/details?id=com.deeppradhan.encrypt_decrypt&hl=en&gl=US

@garth A device physically captured may be breached with some effort, but I don’t think anyone reasonably expects safety at the time of physical capture of the phone.

@mc-hamster It needs to be implemented somewhat similarly to encryption. A layer of user-supplied encryption over the payload. The nodes themselves won’t be able to decode the message and display it.

2 Likes
21

That’s how proofs of concept and prototypes begin. Give it a shot. Use port “PRIVATE_APP” for the prototype (aka Port 256) and if this works out, we can allocate a more permanent port.

1 Like
22

Roger that. I’ll have to l buy some hardware when I scrape together a few extra quid.

23

That app looks easy enough to use. It does however have some bad reviews on its encryption standard.

I have been playing around with open keychain all morning. I am starting to really like it because it is easy to use. It also has option between pass phase encryption and public/private key. Its is recommended by the guardian project, open source, and independently audited. It also integrates quite well with the clipboard.

24

Sorry to bring up my own message, but if someone knows the answer or can point me to the right documentation pages, I would be very thankful.

TLDR: Is there a technical reason why a repeater (relay node) needs to be able to decrypt the message payload ? If not, do we agree it would be a desirable feature to be able to configure a node as a relay-only, with parameters about what to repeat, but no key provided, so that hardware theft does NOT imply messages security break.

Cheers

1 Like
25

@Eagle

Makes sense to me, but I am still trying to read up on all the specifics of Meshtastic.

Just thinking out loud, but it might require two sets of keys. One key for the relay node to authenticate that the the transmission is coming from an authorized user/transmitter on the network even though it can’t decrypt the payload, and then a separate key to finally decrypt message by the final recipient.

2 Likes
26

This is interesting, however, I do feel like you’re kind of reinventing Nomad Network | unsigned.io but without the ~4yr development effort that’s gone into that project.

If the Meshtastic team are interested in exploring strong encryption, I wonder if working on the C port and then integrating Reticulum might be a good approach.

27

@Eagle It does not need to be able to decrypt the payload. As of now, each node has the key. In theory, the router can relay the payload without being able to decrypt it.

@Edward You are talking about an authorization key and a payload key. It can be done but someone will need to pick up this “feature”. The development targets for version 1.3 are locked if I am not wrong, so maybe this can be targeted for 1.4

28

Okay interesting. Thanks.

29

i was thinking about the same thing…
some Solar-Node, placed somewhere that it could be found by someone else.
someone else just needs to press user button, then can connect by bluetooth and copy the channels QRcode. then read all the messages with own device… not even accessing the relay node any more.

solution:
no need for double encryption…

Put the router nodes on different , encryptet channel. (Channel A )
THE User-Nodes for Messsaging put on encypted Channel B (same modem settings).
the router nodes will forward all the messages of Channel B without being able to read messages.
someone with acces to A can only read status of other router Nodes. (Or put each router node on seperate Channel…) You can Use Channel A to read out battery-status and locations of router-nodes…
btw: the router nodes dont need to have a display…

30

As long as the node in router mode has the same lora config it will re-broadcast for channels that it does not have a key for. The QR code consists of the lora config and a channelset

1 Like
31

Welcome @Edward !

This topic was discussed with @geeksville quite at the beginning of this project. However, at that time, there were no resources to be assigned for this. Furthermore, as it was pointed out, no one has been contributing for developing this.

Regardless, a decision should be made whether or not to separate networking services and user interface (including payload encryption and decryption) to “standalone” components.

I think it is important, for standalone routers/repeaters, not to be able to decrypt payloads (messages) they transmit/retransmit. Furthermore, it is almost as important, for standalone routers/repeaters not to show other nodes positions. Revealed positions makes it too easy for someone to take down all stations, when the first one is found. :confused:

Therefore, I strongly suggest to assess this issue. The first step would be using A and B channels, with different PSK-keys, as @kilroy suggested. As this can be done, @Eagle - this is already doable. :slight_smile:

The second step could be adding a feature to the Meshtastic applications for added GPG-encryption & decryption. This will increase the length of the payloads, but should be manageable, at least for demands of enhanced security. @mc-hamster should be able to assess possibilities for adding this feature.

These two first steps might satisfy the needs of @Edward.

The third step might be separation of the networking components, and the components of user interface and payload encryption. This would allow us to disable user interface (showing messages/payloads, and other nodes locations on the screen), and there would be no need for storing encryption keys, for main payloads, on standalone routers/repeaters. Moreover, a node could still be used as a standalone user node, if the encryption keys, for payloads, are set, and the user interface is configured. However, keys for maintaining the network (repeaters) would still be preferred for standalone nodes?

This third step would allow us to loose a standalone router/repeater, without compromising payload security, or locations of other nodes. Indeed, the net could become unstable, if the lost node was used to, for an example, to flood the net. What are your @garth thoughts of this?