I started this thread on the QRZ site when the HSMM-MESH topic was posted earlier this week.

The issue of the use of encryption when operating HSMM-MESH on a part 97 transmitter has been heavily debated in the Amateur Radio community but never ruled upon by the FCC. I have offered to use my professional services to file a Request for Ruling with the FCC on this topic.

As part of my research, I have asked why HSMM-MESH makes use of encryption. The typical answer is that it is needed to keep the unwanted off the mesh. As I have made quite clear on the QRZ forum, this is an application for authentication, not encryption. One can keep unwanted users off the mesh through authentication alone without the need to use any encryption.

I have asked the following research question on the QRZ forum but I have not received an answer so I will ask it here:

Since authentication does not require encryption, why does HSMM-MESH use encryption?

I don't ask this to be glib, cute or for spite. This is an essential point to the request for ruling with the FCC. We need to be clear as to why the choice has been made as it has.

If anyone would like to participate in the Request for Ruling, please send me a PM via my email on QRZ.

- Glenn DJ0IQ and W9IQ

Glenn:

I appreciate your efforts, and I wish I knew the answer, but I dont.  Hopefully someone knowledgeable about the standard will chime in.

someone mentioned that encryption was used, but I see no settings for it, or any references to it either.

Hi Lee,

Thanks for the reply. It concerns me that the issue of encryption is not made clear to the users of HSMM-MESH. I have looked over the documentation and help areas and have not found a clear statement either.

The good news is that you can check this out yourself. If you have an HSMM-MESH AP, connect to with with SSH and look for this file: /etc/config/wireless. Open or cat the file and look for the following lines, typically near the end of the file:

option encryption wep

option key THEKEY

The encryption option sets or turns off encryption. Its options are "none", "wep", "wpa", "wpa2", "psk", and "psk2". I believe that for ad-hoc networks like HSMM-MESH this needs to be "none" or "wep". The key option is the authentication key that must be the same for all APs participating in a common mesh.

I am doing this from memory without an AP in front of me and it has been a while since I have configured an openwrt device. If I have it wrong, someone please correct me. Take a look at these settings and report back on this thread what you find if you have the chance, Lee.

Meanwhile, I am still hoping that someone can answer my original question on this thread.

- Glenn DJ0IQ and W9IQ

HSMM-MESH^TM does not use encryption.  Every layer of the network and every protocol is open and unencrypted.  Authentication is used when logging into the administrative interface of a mesh node, as it should be.  No other form of "obfuscation" is used.

73
ad5oo

Hi Bill and Dave,

Thanks much for that information. It looks like some of the feedback I got on QRZ was wrong. I am glad to see it is on solid footing and this doesn't warrant a request for ruling.

If I may make a suggestion, it would be to remove the reference to the CQ article that leaves one to infer encryption is used and somewhere make a clear statement that encryption is not used - perhaps in the design philosophy or the getting started section. Just a thought.

Thanks again. - Glenn DJ0IQ and W9IQ

Hi Wes,

I am sorry but I don't understand your reply. Both of your links have ellipses in them so they cannot be followed. One looks like you were intending to show the link to the CQ article that I recommend be removed from the site.

Perhaps you could correct the links and explain your point in posting them?

- Glenn DJ0IQ and W9IQ

At a minimum, the it should be explained in the FAQ and documentation that HSMM-MESH does not use encryption.  I too was confused by the CQ article and thought that HSMM-MESH used encryption.  This is the first time I have found anything to the contrary.

Thanks,

AC7BR

What I took from the CQ article is that it depends on why you're encrypting the traffic.  They mentioned network security and access control, and also repeater control codes.  This sticks  out to me because not only is a mesh node basically a repeater, but the admin pages for each one are unencrypted.  When you log in, the root password for that node is going over the air in plain text.  (Of course, something like WPA would prevent the casual listener from seeing this, but if the key could be obtained or cracked somehow, this would be moot.)

I think that using SSL for the admin page (ie, giving it an https:// url) would be a wise idea.  It would require some work on the firmware, which I am looking into, but I think it could be done technically.  Without it, there is the possibility of a casual WiFi sniffer to lift the password and tamper with a node.  If the mesh is being used for something like emergency communications a measure like this would be very important for the stability of the network.  Of course, the workaround is to just access the admin page only through a wired connection and never through the mesh, but this could be impractical for a remote site.

I think the CQ article mentioned that the encryption scheme would have to be documented, but we wouldn't have to publish they key.  Then again, it would need to be published somewhere if we want people to actually get on the network, so whether or not it's right about that doesn't really matter.

I could be wrong, but I'm pretty sure that a self-signed SSL certificate would work.  The first time you went to the SSL-protected page your browser would complain about the cert not being from a trusted authority, but if you accept the cert anyway you won't get that error again until it expires, or if someone tries to do a man-in-the-middle attack in which case you can simply choose to not accept it.  The initial accepting of the certificate could be done by the user right after flashing the firmware, presumably while plugged in with a cable.  This wouldn't quite be as streamlined as having a CA, but I think it would get the job done.

As for connecting, the nodes use OLSR to negotiate routes and addresses, but other than that it's basically a normal ad-hoc network.  You can still connect and either sit there with no IP and watch the traffic, or just pick a random IP.  All you need then is a packet sniffer - I just tried connecting to the mesh with my laptop, and was able to sniff a root password being send from one of my WRT54Gs to the other. 

I agree that under most cases, the mesh wouldn't really be much of a target, especially since it despite what I said earlier if someone blindly tries to connect they won't get very far without OLSR.  Regardless, getting on and listening around isn't the most difficult thing, and doesn't necessarily take a lot of skill.  If someone was really intent on disrupting things it would not be that far out of reach.  I do like the openness of the network, in that it is easy for anyone to join in, so I would not really agree with using something like WPA or WEP.  But we should probably be careful of critical parts of the mesh infrastructure, like the configuration page.