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.
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.