¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Open source is the key to new ideas


 

I can't remember if it was here that someone was recently mentioning "little green check marks", so this has already been discussed. I don't remember by whom, but I would like to fill this out a bit, and, at the same time, discuss why an open source environment is key to the success of innovative digital ham methods. The Linux / Windows / MacOS paradigm is a great starting point...
?
Isn't it interesting that nearly all high security web servers run on Linux? How can that be? If the code for the Linux kernel is available to anyone, wouldn't it be easy to find a flaw and break into such a server?
?
Well no, it's not that easy. Why?
?
Because the the open source community has a thousand eye constantly looking over every line of that code. When chinks in the armor are found, or when a break-in (hack) has occurred, a team will create a security update that will be made available to all the flavors of Linux. There are strict rules for how pull requests are reviewed and accepted to the repository that holds that code. Everyone who want's to see the process can closely follow it, and, like I said, there's a lot of eyes on both the process and the code.
?
Fun fact There is actually a very that occurs every year in Las Vegas where security experts, governments and hackers get together and talk about such things. That becomes part of the open source environment and it's an important reason why companies that require security use Linux based servers and not Windows or MacOS. The best open source programmers (and hackers) that attend that meeting are aggressively recruited by companies that also attend that meeting. The open source development system works and it works well. Drop . the . mic .
?
Now, let's switch gears...
?
If you've been a ham long enough, you've probably encountered an outrageous, profane or obnoxious operator, maybe a rouge operator, using a made up callsign, or, even worse one who didn't own the callsign he was using. Or sadly, maybe it's a ham who has snapped for some awful, personal reason and is now behaving poorly. Or maybe your an EMCOMM net controller and need to be sure about your information sources.
?
Wouldn't it be nice if you could quickly identify those situations? Well, Wojciech Kaczmarski SP5WWP has already opened the door to providing a solution. I first saw his a few months ago. This is big, really big! He shows that in just a little over 8 ms, you can transmit a digital signature on an M17 transmission with a private key. Anyone listening to that transmission with access to the public the key can verify the signature. I know, it confusing. of how digital signature works.
?
So what do we need to work out the details? First, the the originator needs to attach a unique digital signature, based on the transmission and the private key. Well mvoice is open source. So is DroidStar. The CS7000-M17 firmware is open source. MMDVM is open source!
?
Okay, that's doable! Note that I'm not saying it's easy, but we've had great examples where open source folk have worked miracles (see the Linux kernel discussion above). For an amateur radio miracle example, Jonathan Naylor G4KLX pretty much alone worked out the open source solution to dealing not only with the complex DMR data stream, but also the incredibly convoluted Yaesu data stream. Another example you ask? How about the OPEN RTX team developing M17 firmware for the MD-380. The MD-380 manufacturer doesn't supply supply manuals for how to do this.
?
The key pairs are easy to generate, the tools are all ready there. Anyone can generate a unique private/public key pair.
?
So the final piece that is needed is for the receiver to use the signer's public key to verify the signature matches the transmission. The signature verifies that the transmission data is signed by the holder of the private key and using the public key is the only way to verify that transmission. But wait, where does he get the public key? Ideally for US callsigns, it would come from a already verified source, like a field in the FCC's callsign lookup or from ARRL, or maybe from the DMR ID registration org. It's got to be somebody that knows the public key belongs to you.
?
Yikes, you say! How are you ever going to make that happen? Yeah, I admit, that might take a while. But in the meantime, we are in an open source environment with M17. A few cleaver programmers could set up a demonstration public key server. This could be used by open source reflectors and repeaters to display a little green check mark on the dashboard of their last heard page verifying that that transmission has a unique and correct signature.
?
Wow! That's really something very awesome. and is something that could only happen in an open source world. The big three manufactures could never be persuaded to do this on their own.
?
The fact that I can even think about this is the coolest part of an open source development.


 

¿ªÔÆÌåÓý

Great example of open source innovation that has already happened.? I felt much the same when I saw the post on Discord about M17 signing.? I can also see the potential for it to be a game changer.? From simply confirming that who is transmitting is the holder of the key to adding some more authentication for data services - I always found "logging in" on AX.25 packet BBSs rather amusing, being either assuming you're using your correct callsign or at best using a plaintext password (when just about every packet TNC defaults to being a packet sniffer when in monitor mode!).? Now we have something that could be more appropriate for accessing data services.

On 18/8/24 2:23 pm, Tom Early via groups.io wrote:
I can't remember if it was here that someone was recently mentioning "little green check marks", so this has already been discussed. I don't remember by whom, but I would like to fill this out a bit, and, at the same time, discuss why an open source environment is key to the success of innovative digital ham methods. The Linux / Windows / MacOS paradigm is a great starting point...
?
Isn't it interesting that nearly all high security web servers run on Linux? How can that be? If the code for the Linux kernel is available to anyone, wouldn't it be easy to find a flaw and break into such a server?
?
Well no, it's not that easy. Why?
?
Because the the open source community has a thousand eye constantly looking over every line of that code. When chinks in the armor are found, or when a break-in (hack) has occurred, a team will create a security update that will be made available to all the flavors of Linux. There are strict rules for how pull requests are reviewed and accepted to the repository that holds that code. Everyone who want's to see the process can closely follow it, and, like I said, there's a lot of eyes on both the process and the code.
?
Fun fact There is actually a very that occurs every year in Las Vegas where security experts, governments and hackers get together and talk about such things. That becomes part of the open source environment and it's an important reason why companies that require security use Linux based servers and not Windows or MacOS. The best open source programmers (and hackers) that attend that meeting are aggressively recruited by companies that also attend that meeting. The open source development system works and it works well. Drop . the . mic .
?
Now, let's switch gears...
?
If you've been a ham long enough, you've probably encountered an outrageous, profane or obnoxious operator, maybe a rouge operator, using a made up callsign, or, even worse one who didn't own the callsign he was using. Or sadly, maybe it's a ham who has snapped for some awful, personal reason and is now behaving poorly. Or maybe your an EMCOMM net controller and need to be sure about your information sources.
?
Wouldn't it be nice if you could quickly identify those situations? Well, Wojciech Kaczmarski SP5WWP has already opened the door to providing a solution. I first saw his a few months ago. This is big, really big! He shows that in just a little over 8 ms, you can transmit a digital signature on an M17 transmission with a private key. Anyone listening to that transmission with access to the public the key can verify the signature. I know, it confusing. of how digital signature works.
?
So what do we need to work out the details? First, the the originator needs to attach a unique digital signature, based on the transmission and the private key. Well mvoice is open source. So is DroidStar. The CS7000-M17 firmware is open source. MMDVM is open source!
?
Okay, that's doable! Note that I'm not saying it's easy, but we've had great examples where open source folk have worked miracles (see the Linux kernel discussion above). For an amateur radio miracle example, Jonathan Naylor G4KLX pretty much alone worked out the open source solution to dealing not only with the complex DMR data stream, but also the incredibly convoluted Yaesu data stream. Another example you ask? How about the OPEN RTX team developing M17 firmware for the MD-380. The MD-380 manufacturer doesn't supply supply manuals for how to do this.
?
The key pairs are easy to generate, the tools are all ready there. Anyone can generate a unique private/public key pair.
?
So the final piece that is needed is for the receiver to use the signer's public key to verify the signature matches the transmission. The signature verifies that the transmission data is signed by the holder of the private key and using the public key is the only way to verify that transmission. But wait, where does he get the public key? Ideally for US callsigns, it would come from a already verified source, like a field in the FCC's callsign lookup or from ARRL, or maybe from the DMR ID registration org. It's got to be somebody that knows the public key belongs to you.
?
Yikes, you say! How are you ever going to make that happen? Yeah, I admit, that might take a while. But in the meantime, we are in an open source environment with M17. A few cleaver programmers could set up a demonstration public key server. This could be used by open source reflectors and repeaters to display a little green check mark on the dashboard of their last heard page verifying that that transmission has a unique and correct signature.
?
Wow! That's really something very awesome. and is something that could only happen in an open source world. The big three manufactures could never be persuaded to do this on their own.
?
The fact that I can even think about this is the coolest part of an open source development.


-- 
73 de Tony VK3JED/VK3IRL


 

Excellent summary!
?
The big three manufactures could never be persuaded to do this on their own.
This is so true. The source of innovation is everything but them, most of the time.
?
I still need to add the signature definition to the spec document. My plan is to do this in early September (when I'm back from the JARL Ham Fair).


 

Kinda wish this wasn't my first post to the group. But here we go anyway...
?
One of the issues I have with digital modes in general is that there's a requirement for a central server to keep track of all the callsigns, numbers or whatever authentication systems are implemented. First thing that I had to do with my D-Star radio is figure out who could register my call. And if there's one central server, that basically means there eventually will be two, because hams like to take their ball and go home when someone gets bent out of shape. Yes, there are bad operators and men who behave like children who need to be removed from the sandbox. But I'm more concerned with hard drive failures, lighting strikes and missed payments to the hosting center shutting down access for a time (the last one more likely to be the rent going way up and losing the facility). Not to mention the Cloudstrike global outage a few weeks ago or the LOTW issues earlier this year.
?
Seems to me a distributed database, run by as many hams as wish to participate, might be the way to go. Given the number of hams world wide is about 3 million it shouldn't be a massive database to maintain, even if every licensed ham added their keys. Download an image for a Pi4 or other light-duty Linux box and that's it. Let it sit on your network and chug along. Or at least have the various national clubs work out the details amongst themselves, but then again they'd probably go with a single central authority because that's easier to sell than "but who will host these nodes?" Repeaters and reflectors would probably need to maintain a fairly large cache to prevent too many hits on the chain -imagine a long running QSO or big net with a lot of check-ins, but they could also be nodes themselves. And it would also allow for everyone to see the database too, albeit probably more work than most hams will want to put in.