recommendations for non-standard modes (station identification)

Hi all,

I am part of a group of people of the amateur radio club of Oostende (Belgium) who want to set up a QO100 station. The reception side is already done, so now working on completing the transmit chain.

My personal interest is digital communicatio, so I would like to use QO100 as a platform to learn and developing new modes using GNU Radio. This would also be part of the 'SDR Belgium meetup' group.

So, question.
Say you would create a non-standard digital mode, what is the correct way to identify your station on QO-100. After all, people who do not have the proper software will just see some kind of digital stream on the waterfall and have no way to identify or decode it.

For identification, some years ago, I played around with a self-modified version of DSTAR, and for that I added a module that sends out my callsign in front of every transmission (either morsecode or as spoken audio).

Another option is to add a CW carrier next to the transmission that carries my callsign.

However, even if this allows a transmission to be identified, that does not allow for people to decode it. And, without the ability to decode, it is very difficult to see the difference between a genuine station and a pirate-station.

So it would be interesting to have a way to transmit some digital text in a standardised way, say with the callsign of the transmissing station and the URL of a github repo for the decoding software, so that everybody has a way to properly identifiy a non-standard signal on QO100. (and perhaps, a way to 'sign' that information with a digitial certificate, so help combat pirates)

Is there a standised way to do this? Does AMSAT-DL have a formal advice on this subject?


73
kristoff - ON1ARF

Hallo Peter,

Thank you for replying.

Yes, that's also how I did with the tools I made before.
That is OK if you use a local VHF/UHF frequency with a limited range, but do you think this is good enough for QO100?

I once had a simular discussion about transmitting encrypted traffic for emergency communication over amateur-radio spectrum.

In essence, the issue is the same as here: just sending a callsign in morse-code or voice in front of a digital stream only provides an identification of a station, based on good faith.

If the message itself cannot be decoded -because it is encrypted emergency communication or some new experimental mode-, the listeners have no way to verify if that is indeed a message from that station.

What would stop somebody (a pirate, a commercial entity, or even somebody with criminal intend) from using QO100 to send encrypted messages by just slaping some callsign in front of it? (especially the callsign of stations that are known to have transmitted "new mode" transmssions on QO100 before).

As I see it, the best way to protect QO100 from being used by other people, is to design some system so that any traffic that cannot be decoded (experimental modes, encrypted emercomm traffic) can add a identication-tag to their transmission, using -say- X509 certificates so that the signature can be verified; even if the message itself cannot be decoded.

If the identification is well defined, it would be possible for "LEILA" to automatically verify all digital transmissions on the transponder and transmit a signal on top of all the signals that do not have a valid identification; so helping to prevent QO100 to be used by random people.

After all, what QO100 does is provide 500 KHz of radio-spectrum that allows roughly one thirth of th population of the earth to reach eachother for just some hunderd euro of equipement. That is something that has a lot of value; especially for people outside the amateur-radio community who do not care about the ITU or local regulators.

73

kristoff - ON1ARF

Hi Peter,

Yes, that was exactly the question. How do I do this?
Does AMSAT-DL propose a recommended way to 'annotate' a transmission, so to direct people to -say- a github code repo?

A packet-radio packet in front of the emission? A PSK31 carrier next to the transmission?


73
kristoff - ON1ARF

Hallo Matthias,

OK. Sound like a fair deal: a voice-segment in USB in front of the transmission seams like a feasable thing to do.


One note, concerning encryption on amateur-radio.
It is indeed the 'general rule' that encryption is not allowed on allowed on amateur-radio. but things do are more complex that that.

At least here in ON-country- there are in fact situation where encryption is not only allowed but even mandatory.
- emergency communication carrying information about individuals.
- to remotely control amateur-radio infrastructure,
- to remotely control amateur-satellite radio infrastructure.
Rule 1 is the results from the fact that the regulator has concluded that EU privacy legislation determines that the privacy concerns for the victims in emergency communication overwrites the normal ban on encryption.
Rule 2 results from a law on the protection of critical infrastructure.
Rule 3 is -I think- the result on an international treaty on satellites which states that the national gouvernements must take any step possible to safeguard the safe operation of a spaceverhical. (after all, you do not want somebody to take over your satellite, do you?)

Just to be clear.

This does *NOT* mean that every ham can just start using encryption as he/she wants. The Belgian laws says that "the regulator can allow encryption in this situations" and that "the implementation has to be done supervised by the regulator".
So everything has to be done in a way that is conform the law, under strict control of the regulator.

As I interprete this (but this is my personal opinion) a rule like "just add your callsign in morse-code in front of the transmission" would not pass the normal requirements, as it is to simply to spoof.
It would require some additional level of authentication (like the use of signing based on certificates)

But, as said, this is a discussion that is not relevant to what I want to do.
I do not have the intend (or the knowledge) to write encyption-tools for amateur-radio. My interest are much more in the DSP and SDR field. I just want to experiment with DSP, SDR and digital communication, and QO100 is -for me- an ideal tool for this as it allows "point to point" radiolinks with much more people than here no local VHF/UHF.

As I write only open-source software, I have absolutely no problem with providing specifications and source-code!


73
kristoff - ON1ARF

Hallo Matthias,

I'm sorry for the delay.
I had some issues on the "IT" side of things, so the ham-stuff got pushed to the background for a couple of weeks.

Quote from DD1US

By the way you are welcome to join in the future development of the AMSAT-DL Highspeed Modem. There are many things which could be added to it andI think it would be a good idea to have a common user interface for different modes / applications. Maybe you can have a look and we can talk offline involving Kurt DJ0ABR who is the developer.

http://www.dd1us.deBy the way you are welcome to join in the future development of the AMSAT-DL Highspeed Modem. There are many things which could be added to it andI think it would be a good idea to have a common user interface for different modes / applications. Maybe you can have a look and we can talk offline involving Kurt DJ0ABR who is the developer.

Well, my knowledge of SDR at not at all at the level of Kurt.
I have seen his talk at the online version SDR-academy of last year. Really impressive.


For SDR, my first goal is to try do something with a digital version of SSTV that allows more experimentation, not just as a 'tool to use', but also as a developement and learning platform for the "SDR Belgium" group.

Fromt the SDR-side, I will start with something very simple like MSK.
But first I need to work out a good way on how to send JPEG images over radio, i.e. have the jpeg decoding mechanism be able to deal with biterrors. Without that, all the rest is useless.

But I will surely contact you or post on this forum when I start experimenting.

Note. I am not really a fan of webforums for discussions.
It feels like an attempt to artificially shoehorn mail and online chat onto a platform that is not really intended for it.

Is there no normal mailing-list or IRC/matrix channel for this kind of discussions?

73
kristoff - ON1ARF

Peter,

Quote from DB2OS

Yes - protocol description and other details must be placed in the public and easily accessible.

In the past this was mainly publishing articles in widely available media, for example magazines etc.

Nowadays Internet is indeed very well suited if it can be easily found, for example via Google or GitHub, etc...

Well, I must say that I have come across a number of digital signals on QO100 where I have no clue what kind of signal it is and how to decode is.

It's a bit strange as there does exists a system called 'rsid' (*) that does allow easy identification of a digital signal.
Why do people not use this feature?
Do people not know that this exist? It is a standard feature of gqrx, so I guess other SDR software will also have it.

As said, a standard way to identify signals would allow you to build an automated system to check the validy of signals on the transponder as part of LEILA.


73
kristoff - ON1ARF
(*) http://www.w1hkj.com/RSID_description.html

Hallo Peter,

Quote from DB2OS

There is a general misunderstanding between 'security', 'safety', 'privacy' and 'authentication'

In particular for Point 2. and Point 3. encryption is absolutely not required. On all P3-Satellites we never used encryption, but authentication.. There was no need to hide the commands, but indeed you wanted to make sure that only real command stations could execute commands. So instead of encryption, the protection was using a kind of trustable signature..

73s Peter

This is getting a bit of topic here, so just one more remark.

As I see it, that's an argument based on "minimalistic" view of cybersecurity.
Yes, authentifcation -determing that a message is indeed from a certain person- and obfuscation -hiding the content of a message- is not the same thing and, yes, with signing, you can do the former without the latter; ... but that is not the complete story.

If you look at the hacking methology as defined by the CE council, one of the earlier steps in the process is 'enumeration' i.e. finding technical information about a target. This can be open-ports, routing-information, etc., ... including things like what kind of software a device is using and what version of software.
This then provides information for the next step, e.g. look for know vulnerabilities in firmware image x.y.z.

From a legal point of view, managing critical infrastructure requires you to use every possible means to protect it from misuse (hence the term *critical* infrastructure ).
From a blue-team perspective, it your job to make it as difficult for the attacker to find to any information about your infrastructure, and obfuscation is part of that.

But, as said, I guess we are quite of-topic here, so I propose to close this part of the discussion here.

73
kristoff - ON1ARF

Hallo Peter,

Quote from DB2OS

I assume most people on QO-100 might even not know GQRX and thus not about RSID.

Oeps ... I meant fldigi, not gqrx.
My error. Sorry.



73
kristoff - on1arf