WSJT-X has published a release candidate which includes a new fox mode called SuperFox which promises a +10dB total system gain compared to the old fox mode. It also comes with a “SuperFox digital signature” in attempt to alleviate dx-pedition pirates. Verification of dx-peditions is an excellent idea, and I really want to see this problem be solved.
There’s a few problems with the SuperFox signature system, however. Let’s talk about it.
How does SuperFox signatures work?
The basic flow is this:
- Before a dx-pedition, the group running the dx-pedition applies to Northern California DX Foundation to receive a “SuperFox key”
- During the dx-pedition, the fox transmitter configures the “SuperFox key” into their WSJT-X application
- When transmitting in SuperFox mode, WSJT-X will encode a verification signature into each message
- Hounds will receive this verification signature and ensure its valid
- If the message is valid, a “Verified” message is displayed in WSJT-X
Governance issues
The first problem to dive into is how the dx-peditions keys are distributed. We are reliant to a single org to distribute keys for all dx-peditions world wide. This can pose issues if the org doesn’t accept your dx-peditions credentials or is uncontactable for some reason.
Given the global reach of this hobby it’s frustrating to see this approach taken.
What could be done better
Public/private keys could be generated by any dx-peditions and used within WSJT-X. The public key could be uploaded to the dx-pedition website where users could check for validity. This allows anyone to use the new SuperFox mode. WSJT-X might want to have a certificate download system where wsjt-x could download certificates automatically that have been vetted.
GPL source code and amateur radio ethos
SuperFox decoders and the signature check are packaged as binary blobs and not covered by the GPL. This means that users installing through open source channels will not be able to use the SuperFox mode as the binary blobs need to be stripped from the packages.
Additionally, the use of binary blobs may not be in line with the project’s GPL licence, but I’ll leave that debate up to the legal people.
Regardless of the legal aspects, I’m a strong believer that amateur radio should focus on using open standards, protocols and modulation schemes where possible, and this very much goes against that. Keeping the modulation and verification scheme a secret prevents innovation and limits the lifetime of the service.
What could be done better
Develop the digital signature process in public with open source code. This allows feedback and improvements. It also ensures that the project can live on.
Security by obscurity is a bad idea
I’m sure you already know this one. Security by hiding the algorithm is a bad idea. You might have noticed that when I walked through how SuperFox is meant to work, that there was no step for where “WSJT-X downloads latest keys” or “user inserts public key”. That’s because the only security provided by this system is from the algorithm used to “sign” the messages.
The good news is that it’s no longer obscure…
mwheeler@foxbook superfox_keygen % gcc -I. main.c <censored>.c
mwheeler@foxbook superfox_keygen % ./a.out N0CALL
OP0C-COPY
I spent a little bit of time looking at how the binaries worked and made my own implementation of the key generator.
A public release of this code as GPL will be available after the Jarvis Island 2024 dx-pedition.
What could be done better
Including some people knowledgable in secure system design would be a great start. This system was very hand crafted without much experience and didn’t use any existing open standards for signing messages. Being amateur radio, we don’t need anything fancy. In fact, H40WA implemented a reasonably workable solution using TOTP tokens to verify that the station wasn’t a pirate. Alternatively, some basic public/private key cryptography could have helped here.
Oh no.
So what’s going on here. (note: I’m no cryptography expert)
The major problem with SuperFox is the system design for the digital “signature”. The system is symmetrical which means the receiver needs to know how the key and the process used to “sign” the message. This means the only thing protecting someone from generating a SuperFox key is client side security - a terrible place to be in.
In a future post after the Jarvis Island 2024 dx-pedition I’ll write up the steps I took in discovering how SuperFox and foxchk work. This work was done with the intention of creating open source versions of the closed binaries to allow SuperFox to work on Debian, however as the security issues were discovered it was important to document the issues publicly (while keeping the details private for now) to allow developers a chance to hopefully change their approach to something more open and sustainable.
With help/love from
- the6p4c
- isomer
- kitty
- my insomnia