APRS-IS Passcode Has Become An Utter and Total Joke....

[Stephen H. Smith]

I was Googling for information on the APRS-IS today, and discovered that there
are now numerous webpages that have interactive self-serve passcode generators
for APRS-IS "validated" log-ins on them. Many will accept absolutely any
random alphanumeric string such as tactical calls, CB handles, cipher groups or
anything else.

Here are some of the ones I found:

<http://callpass.kf5jwc.us/>
This one DOES verify that the string entered is a real callsign.

<http://apps.magicbug.co.uk/passcode/index.php/passcode>
This one will accept anything as input

If you don't want to go online to generate your passcode, this downloadable
Windows program will do the job locally:

<http://blog.eagleflint.com/software-downloads/aprs-is-passcode-generator/>

K4HG has been warning for ages that the APRS passcode scheme is totally
non-secure, but it has now reached a new level of uselessness with these
ready-to-run interactive pages and apps.

I.e. you no longer need to know how to translate the documented algorithm into
actual program code in some language.


_____________________________________________________


--

Stephen H. Smith wa8lmf (at) aol.com
Skype: WA8LMF
EchoLink: Node # 14400 [Think bottom of the 2-meter band]
Home Page: http://wa8lmf.net


Long-Range APRS on 30 Meters HF
http://wa8lmf.net/aprs/HF_APRS_Notes.htm

High Performance Sound Systems for Soundcard Apps
http://wa8lmf.net/ham/imic.htm
http://wa8lmf.net/ham/uca202.htm

"APRS 101" Explanation of APRS Path Selection & Digipeating
http://wa8lmf.net/DigiPaths

[Andrew Pavlin]

You mean I've been wasting my time validating callsigns before issuing passcodes to users of my software? ;-)

Bear in mind that the open-source Xastir software includes the callpass program as well, so self-service has been out there for years. It's just become ridiculously easy lately. Not sure why all those people thought they should provide that "service".

So what shall we do in the meantime? Migrate to a new authentication scheme in APRS-IS servers and eventually drop support for the old one? That would be rough on all the die-hard UIView users. :-)

Just FYI, I am currently working on an HMAC scheme for authenticated telecommand over APRS. Maybe something like that would work for APRS-IS.

The key is to make sure the ability to issue authenticated identities doesn't get into the "wrong hands", as always. It would be a bear for the network itself to have to issue ID's, but that may be what we have to go to, since, if anyone can issue authorization, then everyone can.

Andrew Pavlin, KA2DDO
author of YAAC ("Yet Another APRS Client")
http://www.ka2ddo.org/ka2ddo/YAAC.html

Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: "Stephen H. Smith" <wa8lmf2-***@public.gmane.org>
Sender: aprssig-bounces-***@public.gmane.org
Date: Fri, 28 Mar 2014 16:08:38
To: TAPR APRS Mailing List<aprssig-***@public.gmane.org>
Reply-To: TAPR APRS Mailing List <aprssig-***@public.gmane.org>
Subject: [aprssig] APRS-IS Passcode Has Become An Utter and Total Joke....

I was Googling for information on the APRS-IS today, and discovered that there
are now numerous webpages that have interactive self-serve passcode generators
for APRS-IS "validated" log-ins on them. Many will accept absolutely any
random alphanumeric string such as tactical calls, CB handles, cipher groups or
anything else.

Here are some of the ones I found:

<http://callpass.kf5jwc.us/>
This one DOES verify that the string entered is a real callsign.

<http://apps.magicbug.co.uk/passcode/index.php/passcode>
This one will accept anything as input

If you don't want to go online to generate your passcode, this downloadable
Windows program will do the job locally:

<http://blog.eagleflint.com/software-downloads/aprs-is-passcode-generator/>

K4HG has been warning for ages that the APRS passcode scheme is totally
non-secure, but it has now reached a new level of uselessness with these
ready-to-run interactive pages and apps.

I.e. you no longer need to know how to translate the documented algorithm into
actual program code in some language.


_____________________________________________________


--

Stephen H. Smith wa8lmf (at) aol.com
Skype: WA8LMF
EchoLink: Node # 14400 [Think bottom of the 2-meter band]
Home Page: http://wa8lmf.net


Long-Range APRS on 30 Meters HF
http://wa8lmf.net/aprs/HF_APRS_Notes.htm

High Performance Sound Systems for Soundcard Apps
http://wa8lmf.net/ham/imic.htm
http://wa8lmf.net/ham/uca202.htm

"APRS 101" Explanation of APRS Path Selection & Digipeating
http://wa8lmf.net/DigiPaths

[Steve Dimse]

The first web page generator appeared less than three days after I published the algorithm on the aprssig. Many have come and gone over the years, often chased away through the harassment of self-appointed police that think they are making themselves useful. The generator program callpass has been in every version of aprsd since before I made the algorithm public (which was why I made it public); it is in xastir. Install either of these programs and type 'callpass k4hg' at the prompt and you get my code, 28817.

This is nothing new, you never needed to write code.

There is only one level of uselessness. Something is either useful or useless! ;-)

But it is also important to remember that this was never intended to be cryptographically secure. I would have used more than 15 bits, even in the 90s! The purpose was to provide cover for the FCC rule that offered IGate operators shelter from responsibility for the contents of the message if it was known to come from a ham. In the absence of that proof the transmitting station assumes all regulatory liability for the contents of the transmitted message. That is why the passcode has been useless ever since aprsd included the source code for the algorithm.

IGate operators have not had that shelter for many years, and nothing bad has happened. Knock on wood.

Steve K4HG

On Mar 28, 2014, at 4:08 PM, Stephen H. Smith <WA8LMF2-***@public.gmane.org> wrote:

> I was Googling for information on the APRS-IS today, and discovered that there are now numerous webpages that have interactive self-serve passcode generators for APRS-IS "validated" log-ins on them. Many will accept absolutely any random alphanumeric string such as tactical calls, CB handles, cipher groups or anything else.
>
> Here are some of the ones I found:
>
> <http://callpass.kf5jwc.us/>
> This one DOES verify that the string entered is a real callsign.
>
> <http://apps.magicbug.co.uk/passcode/index.php/passcode>
> This one will accept anything as input
>
> If you don't want to go online to generate your passcode, this downloadable Windows program will do the job locally:
>
> <http://blog.eagleflint.com/software-downloads/aprs-is-passcode-generator/>
>
> K4HG has been warning for ages that the APRS passcode scheme is totally non-secure, but it has now reached a new level of uselessness with these ready-to-run interactive pages and apps.
>
> I.e. you no longer need to know how to translate the documented algorithm into actual program code in some language.
>
>
> _____________________________________________________
>
>
> --
>
> Stephen H. Smith wa8lmf (at) aol.com
> Skype: WA8LMF
> EchoLink: Node # 14400 [Think bottom of the 2-meter band]
> Home Page: http://wa8lmf.net
>
>
> Long-Range APRS on 30 Meters HF
> http://wa8lmf.net/aprs/HF_APRS_Notes.htm
>
> High Performance Sound Systems for Soundcard Apps
> http://wa8lmf.net/ham/imic.htm
> http://wa8lmf.net/ham/uca202.htm
>
> "APRS 101" Explanation of APRS Path Selection & Digipeating
> http://wa8lmf.net/DigiPaths
>
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig-***@public.gmane.org
> http://www.tapr.org/mailman/listinfo/aprssig

[Samúel Úlfr Þór Guðjónsson]

Like Steve notes in his post, there hasn't been much harm done even tho'
it's been easy to create your own passcode to whatever callsign (or not so
much of a callsign) one desires.
However, as already discussed in earlier threads here on APRSSIG, it might
be bad for countries who already are on the gray zone, with the RF to
Internet connection (or vice versa).
There is a hope however, it's called SSL. Via LOTW or similar methods.
Which has already been tested and proven to work.

How to move the whole APRS community on to that idea, that's the real
challenge...

Till that day, we'll have to accept the fact that the aprs passcode is not
so much of a security against none-hams...



73 de TF2SUT - Samúel


On 28 March 2014 20:46, Steve Dimse <steve-***@public.gmane.org> wrote:

> The first web page generator appeared less than three days after I
> published the algorithm on the aprssig. Many have come and gone over the
> years, often chased away through the harassment of self-appointed police
> that think they are making themselves useful. The generator program
> callpass has been in every version of aprsd since before I made the
> algorithm public (which was why I made it public); it is in xastir. Install
> either of these programs and type 'callpass k4hg' at the prompt and you get
> my code, 28817.
>
> This is nothing new, you never needed to write code.
>
> There is only one level of uselessness. Something is either useful or
> useless! ;-)
>
> But it is also important to remember that this was never intended to be
> cryptographically secure. I would have used more than 15 bits, even in the
> 90s! The purpose was to provide cover for the FCC rule that offered IGate
> operators shelter from responsibility for the contents of the message if it
> was known to come from a ham. In the absence of that proof the transmitting
> station assumes all regulatory liability for the contents of the
> transmitted message. That is why the passcode has been useless ever since
> aprsd included the source code for the algorithm.
>
> IGate operators have not had that shelter for many years, and nothing bad
> has happened. Knock on wood.
>
> Steve K4HG
>
> On Mar 28, 2014, at 4:08 PM, Stephen H. Smith <WA8LMF2-***@public.gmane.org> wrote:
>
> > I was Googling for information on the APRS-IS today, and discovered that
> there are now numerous webpages that have interactive self-serve passcode
> generators for APRS-IS "validated" log-ins on them. Many will accept
> absolutely any random alphanumeric string such as tactical calls, CB
> handles, cipher groups or anything else.
> >
> > Here are some of the ones I found:
> >
> > <http://callpass.kf5jwc.us/>
> > This one DOES verify that the string entered is a real callsign.
> >
> > <http://apps.magicbug.co.uk/passcode/index.php/passcode>
> > This one will accept anything as input
> >
> > If you don't want to go online to generate your passcode, this
> downloadable Windows program will do the job locally:
> >
> > <
> http://blog.eagleflint.com/software-downloads/aprs-is-passcode-generator/>
> >
> > K4HG has been warning for ages that the APRS passcode scheme is totally
> non-secure, but it has now reached a new level of uselessness with these
> ready-to-run interactive pages and apps.
> >
> > I.e. you no longer need to know how to translate the documented
> algorithm into actual program code in some language.
> >
> >
> > _____________________________________________________
> >
> >
> > --
> >
> > Stephen H. Smith wa8lmf (at) aol.com
> > Skype: WA8LMF
> > EchoLink: Node # 14400 [Think bottom of the 2-meter band]
> > Home Page: http://wa8lmf.net
> >
> >
> > Long-Range APRS on 30 Meters HF
> > http://wa8lmf.net/aprs/HF_APRS_Notes.htm
> >
> > High Performance Sound Systems for Soundcard Apps
> > http://wa8lmf.net/ham/imic.htm
> > http://wa8lmf.net/ham/uca202.htm
> >
> > "APRS 101" Explanation of APRS Path Selection & Digipeating
> > http://wa8lmf.net/DigiPaths
> >
> >
> >
> >
> > _______________________________________________
> > aprssig mailing list
> > aprssig-***@public.gmane.org
> > http://www.tapr.org/mailman/listinfo/aprssig
>
> _______________________________________________
> aprssig mailing list
> aprssig-***@public.gmane.org
> http://www.tapr.org/mailman/listinfo/aprssig
>

[Cap Pennell]

No news. Perhaps the sky would be falling but for the continuing good faith
and civility of our self-policing radio service. If there appear immoral
interlopers pirating amateur RF, they must be "crowd-sourced" and not
encouraged. <grin>
73, Cap KE6AFE

[Gerhard.F5VAG]

> There is a hope however, it's called SSL. Via LOTW or similar methods.
> Which has already been tested and proven to work.

If you have a LotW certificate installed on an Android device, you can test
it yourself. Just connect to
ssl.aprs2.net
with APRSdroid.

It works very well.

73 de Gerhard, F5VAG

[Andrew P.]

I just tried connecting APRSdroid to ssl.aprs2.net without a certificate, and it still works (using my old passcode).

So that isn't keeping me out.

Andrew, KA2DDO

Date: Fri, 28 Mar 2014 22:28:32 +0100
From: f5vag.eu-***@public.gmane.org
To: aprssig-***@public.gmane.org
Subject: Re: [aprssig] APRS-IS Passcode Has Become An Utter and Total Joke....

> There is a hope however, it's called SSL. Via LOTW or similar methods.

> Which has already been tested and proven to work.

If you have a LotW certificate installed on an Android device, you can test it yourself. Just connect to
ssl.aprs2.net

with APRSdroid.

It works very well.

73 de Gerhard, F5VAG

[Gerhard.F5VAG]

Probably not. Did you look at the server's status page?

It may not yet work in all cases. I am connected here (look for the "Cert"):
http://iad.aprs2.net:14501/

73 de Gerhard, F5VAG

[Andrew P.]

Ah, fine details: SSL is on a different port, and they haven't closed the non-SSL port 14580. That explains how I got in (I was still on 14580, not 24580).

Thanks for the update.

Andrew, KA2DDO

Date: Sat, 29 Mar 2014 00:11:38 +0100
From: f5vag.eu-***@public.gmane.org
To: aprssig-***@public.gmane.org
Subject: Re: [aprssig] APRS-IS Passcode Has Become An Utter and Total Joke....

Probably not. Did you look at the server's status page?

It may not yet work in all cases. I am connected here (look for the "Cert"):
http://iad.aprs2.net:14501/


73 de Gerhard, F5VAG

[Javier Henderson]

That is the intended behavior, to allow SSL if present, otherwise with the code.

73,
-jav k4jh

On Mar 28, 2014, at 6:52 PM, Andrew P. <AndrewEMT-***@public.gmane.org> wrote:

> I just tried connecting APRSdroid to ssl.aprs2.net without a certificate, and it still works (using my old passcode).
>
> So that isn't keeping me out.

[Heikki Hannikainen]

On Fri, 28 Mar 2014, Andrew P. wrote:

> I just tried connecting APRSdroid to ssl.aprs2.net without a certificate, and it still works (using my old passcode).
>
> So that isn't keeping me out.

Yup, it's an experimental feature, and naturally, passcode-only clients
are not rejected, since that would make a lot of users unhappy. The same
servers still provide normal service on port 14580. Actually, using SSL,
you're not getting anything extra at this point, it's a proof-of-concept
showing that it can be done and doesn't break things as such.

* The server just knows for sure that ARRL has given you a certificate,
and that they do a stronger validation of license status than most APRS-IS
passcode-giving software authors would do. The server's status page shows
that knowledge by showing a clickable "Cert" instead of "Yes" or "No" in
the Validated column (F5VAG-10 is still on http://iad.aprs2.net:14501/).

* The server at this point doesn't do anything else than that, but it
could be improved to pass that knowledge onwards to other servers together
with the packets, and then onwards to other clients. For that to be
useful, the servers also need to authenticate with each other in a strong
way (not just passcode). aprsc can do SSL between servers.

* At least from overseas, you can easily send in fake documents to ARRL,
of course, and they will then give you a certificate. This can, however,
be battled. It takes a couple of weeks for the mailed documents to go
through, and it takes actual manual work to go through the process of
*mailing* the documents. The certificate you get is unique, and once it
turns out to be in the hands of a pirate, that single certificate can be
rejected by the services by configuration. The pirate then needs to get
another certificate, and since it's easier and quicker to block the cert
than to get a new cert, the battle is easy to fight. The balance of effort
is uneven.

* The services can block based on callsign embedded in the certificate, if
the callsign itself is invalid (N0CALL, or some P1RATE, or such). The
services can also block based on certificate identifier, if a pirate has
obtained a cert for a legitimate callsign assigned to a licensed ham
somewhere. The legitimate user can continue using his callsign.

* The certificates are digitally signed by the ARRL (or other CA), you
cannot adjust your own certificate to contain someone else's callsign -
the certificate won't validate if you alter its contents.

* A lot of people don't want to be involved with the ARRL, but it's not
limited to ARRL. If other organisations start giving out client
certificates, and demonstrate that they validate the license status
properly, the services can be configured to accept the certificates from a
large number of different Certificate Authorities. Other leagues, clubs,
APRS software authors. Even commercial entities, as long as they show
they're doing it right.

* Ah, you want to run this over radio (2.4 GHz or 5 GHz HamWAN data
links), and you're not allowed to encrypt the data? The server has been
tuned to accept the use of 'NULL' crypto, where the transferred data is
_not_ encrypted. You're still authenticated in the beginning with the
certificate, and the data is tamper-proof (thanks to HMAC), but the data
contents are not encrypted while in transit. The client app can select
whether to encrypt, or to not encrypt.

* It's not limited to APRS-IS. It's quite easy to configure for web
services: https://authtest.aprs.fi/

* Yes, it can be used with UI-View32 - just run a client-side SSL Proxy
app such as 'stunnel' to make the SSL connection to the server :)

- Hessu

[Steve Dimse]

On Mar 29, 2014, at 4:10 AM, Heikki Hannikainen <hessu-***@public.gmane.org> wrote:
>
> * The server at this point doesn't do anything else than that, but it could be improved to pass that knowledge onwards to other servers together with the packets, and then onwards to other clients. For that to be useful, the servers also need to authenticate with each other in a strong way (not just passcode). aprsc can do SSL between servers.

This is where the problem I hit with the original APRS IS will bite. If you just have a small number of trusted servers a system like this where access is controlled at the entry points can work. But when you have a large number of server operators, and especially where the source code is available and can be modified by any one of those sysops, it becomes impossible to assure there are no weak links, accidental or intentional. Even in a system where all the servers are connected by SSL and all internet users are connected to the servers by SSL it is still possible for someone with a certificate to put any data on the APRS IS in an untraceable manner, and therefore impossible to block it.

The way to solve this is to individually sign each packet in a way that allows tracing of the packet to an authenticator. Note that this does nothing to insure the data on the APRS IS is actually authentic, or to prevent a Denial of Service (DoS) attack; it is only a means to assign blame if bad data is found and then close the door to that particular certificate in the future.

What I haven't heard is exactly what problem all this is aiming to solve. Is this a regulatory issue?

In the US things are fine from the regulatory standpoint; there have been no problems yet the possibility exists there could be. To become a problem the FCC would have to capture a particular problem packet IGated by a specific station that violated its rules about profanity or commercial use, prove it came from a specific IGate operator (and since anyone in the LAN could have changed their call to the IGate operator call they need technical proof like T-hunting, not just the presence of the callsign in the packet), and issue a citation. This is a highly unlikely sequence of events.

Are there countries that do not allow IGating from the present APRS IS but would if verification that every packet on the APRS IS was vouched for by someone with a LOTW certificate were assured? I'm no expert on international ham rules but I've never heard of anything like this, in all the examples I know countries either allow internet interconnection or don't.

If not a regulatory issue, then is it is a general security issue? You don't want to wait until the horse is stolen to lock the door. Good sentiment, but we aren't locking something up with intrinsic value. Yes, I'd hate to see someone start a DoS attack on the APRS IS. If the SSL-based system prevented that, maybe it would be worth the effort. But it only prevents people that can't get ahold of a LOTW certificate from doing so. Few outside the ham community know about the APRS IS, and fewer care. Obviously none so far care enough to mount a DoS attack, since none have occurred with no barriers in place. Does eliminating the negligible threat of DoS from a non-ham make the effort worth it?

Or is there some other reason I'm missing?

It seems to me before we start discussing solutions there should be a clear consensus on the problem!

Steve K4HG

[Andrew P.]

Let me see if I can summarize to ensure we all agree on the problem.

"Because there is no strong validation of the license status of any connector to the APRS-IS, it is possible for a non-ham to make illegal RF transmissions through the APRS-IS."

As Steve pointed out, licensed hams can cause DoS attacks (although that technically could be considered a violation due to jamming on RF, that probably wouldn't hold up in court against the originator, but might be put against the TX-IGater). So authentication won't help there.

The US FCC regs specifically state that the first forwarding station is liable for illegal transmissions and ensuring the originator is legally allowed to send the data; subsequent stations are not liable, but are expected to stop forwarding the illegal transmissions once they become aware of them. Can't speak for other nations' regulations, but assuming something similar or more stringent would be safe.

So, we need a way for anybody Tx-IGating to confirm that the packet originator is licensed to transmit to RF, and/or the Igater is allowed to transmit third-party traffic on behalf of the originator. So they have to be able to confirm the originator's license status and/or country of origin (per international agreements regarding third-party traffic handling).

Due to the possibility of forging callsigns, every single packet routed through the APRS-IS would need to be identified with its origination point (client injecting into the APRS-IS) in a form that rogue APRS-IS servers couldn't forge. That doesn't fully help with Rx-Igated traffic (the original station using RF, but if they are transmitting illegally to get to the IGate, that's a separate issue anyway).

Due to the distributed nature of the APRS-IS, we would need a way to ensure all servers were compliant with enforcing origination ID's. So servers that didn't provide origination ID's in their sideways or upwards links to other APRS-IS servers would eventually have to be removed from the network.

So, we would need:

1. Strong and non-repudiable identification of the license status and country of origin of every APRS-IS client instance (not the authors, but the users).

2. Attaching that identification to each packet from that client passed through the APRS-IS.

3. Allowing the selective rejection of traffic from users found to be in violation (perhaps through blacklists and/or Certificate Revocation Lists).

Does that about sum it up?

Andrew Pavlin, KA2DDO

> From: steve-***@public.gmane.org
> Date: Sat, 29 Mar 2014 09:05:10 -0400
> To: aprssig-***@public.gmane.org
> Subject: Re: [aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption
>
>
> On Mar 29, 2014, at 4:10 AM, Heikki Hannikainen <hessu-***@public.gmane.org> wrote:
> >
> > * The server at this point doesn't do anything else than that, but it could be improved to pass that knowledge onwards to other servers together with the packets, and then onwards to other clients. For that to be useful, the servers also need to authenticate with each other in a strong way (not just passcode). aprsc can do SSL between servers.
>
> This is where the problem I hit with the original APRS IS will bite. If you just have a small number of trusted servers a system like this where access is controlled at the entry points can work. But when you have a large number of server operators, and especially where the source code is available and can be modified by any one of those sysops, it becomes impossible to assure there are no weak links, accidental or intentional. Even in a system where all the servers are connected by SSL and all internet users are connected to the servers by SSL it is still possible for someone with a certificate to put any data on the APRS IS in an untraceable manner, and therefore impossible to block it.
>
> The way to solve this is to individually sign each packet in a way that allows tracing of the packet to an authenticator. Note that this does nothing to insure the data on the APRS IS is actually authentic, or to prevent a Denial of Service (DoS) attack; it is only a means to assign blame if bad data is found and then close the door to that particular certificate in the future.
>
> What I haven't heard is exactly what problem all this is aiming to solve. Is this a regulatory issue?
>
> In the US things are fine from the regulatory standpoint; there have been no problems yet the possibility exists there could be. To become a problem the FCC would have to capture a particular problem packet IGated by a specific station that violated its rules about profanity or commercial use, prove it came from a specific IGate operator (and since anyone in the LAN could have changed their call to the IGate operator call they need technical proof like T-hunting, not just the presence of the callsign in the packet), and issue a citation. This is a highly unlikely sequence of events.
>
> Are there countries that do not allow IGating from the present APRS IS but would if verification that every packet on the APRS IS was vouched for by someone with a LOTW certificate were assured? I'm no expert on international ham rules but I've never heard of anything like this, in all the examples I know countries either allow internet interconnection or don't.
>
> If not a regulatory issue, then is it is a general security issue? You don't want to wait until the horse is stolen to lock the door. Good sentiment, but we aren't locking something up with intrinsic value. Yes, I'd hate to see someone start a DoS attack on the APRS IS. If the SSL-based system prevented that, maybe it would be worth the effort. But it only prevents people that can't get ahold of a LOTW certificate from doing so. Few outside the ham community know about the APRS IS, and fewer care. Obviously none so far care enough to mount a DoS attack, since none have occurred with no barriers in place. Does eliminating the negligible threat of DoS from a non-ham make the effort worth it?
>
> Or is there some other reason I'm missing?
>
> It seems to me before we start discussing solutions there should be a clear consensus on the problem!
>
> Steve K4HG
> _______________________________________________
> aprssig mailing list
> aprssig-***@public.gmane.org
> http://www.tapr.org/mailman/listinfo/aprssig

[Steve Dimse]

On Mar 29, 2014, at 10:02 AM, Andrew P. <andrewemt-***@public.gmane.org> wrote:

> Let me see if I can summarize to ensure we all agree on the problem.

I don't even agree there is a problem ;-)
>
> "Because there is no strong validation of the license status of any connector to the APRS-IS, it is possible for a non-ham to make illegal RF transmissions through the APRS-IS."

I would clarify this to make it clear that any illegality is done by the IGate operator, not the non-ham. There are no laws that preclude anyone from sending through the APRS IS.

> The US FCC regs specifically state that the first forwarding station is liable for illegal transmissions and ensuring the originator is legally allowed to send the data; subsequent stations are not liable, but are expected to stop forwarding the illegal transmissions once they become aware of them.

There is an important subtlety here in the US rules. The RF-originating station of an automatic message forwarding system accepts responsibility for the content of the message, unless s/he has verified the non-RF originator was a ham. If there is nothing in the message that a ham cannot transmit (e.g. profanity, commercial or encrypted traffic), it does not matter that it originates with a non-ham. Is is not whether "the originator is legally allowed to send the data", it is whether the message content is legal for ham frequencies.

So an IGate that retransmits a CWOP weather report is not violating the law, unless the comment on the weather report is "F**k you" or "Eat at Joe's". Nor is there a violation if a non-ham husband uses messaging on findU that results in a transmission to a ham wife "Buy milk on the way home". There must be BOTH illegal message content and non-ham origination to make an IGate operator liable for a violation of the rules. And then the FCC must prove that the original transmission originated from the IGate operator's transmitter.

With the FM band brimming with pirates with 100% duty cycle the FCC is extremely unlikely to dedicate a field team to tracking down something as ephemeral as an IGated message. We will notice an ongoing problem long before the FCC, and we can handle it ourselves without generating any adverse consequences for the IGate operator.

> Due to the distributed nature of the APRS-IS, we would need a way to ensure all servers were compliant with enforcing origination ID's. So servers that didn't provide origination ID's in their sideways or upwards links to other APRS-IS servers would eventually have to be removed from the network.

But the key point to me is that all of this effort, which requires the mandatory signing of each and every packet, does nothing except indemnify IGate operators from the regulatory risk of retransmitting profane, encrypted, or commercial messages - something which AFAIK has never happened, which certainly has never brought the involvement of the FCC, and which because of the legalities involved in proving it, is extremely unlikely to involve the FCC. Two extremely rare events are extremely-extremely rare to occur together ;-)

As you mention this is the US viewpoint, and I'd like to hear if there are any other countries where this makes more of a difference.

Unless something more significant can be accomplished I'd say that is not worth the effort and the contraction of the network involuntary removal would cause.

Steve K4HG

[Andrew P.]

Hi, Steve.

I agree with some of your statements, but I have some questions about others.

> From: steve-***@public.gmane.org
> There is an important subtlety here in the US rules. The RF-originating station
> of an automatic message forwarding system accepts responsibility for the
> content of the message, unless s/he has verified the non-RF originator was
> a ham. If there is nothing in the message that a ham cannot transmit (e.g.
> profanity, commercial or encrypted traffic), it does not matter that it originates
> with a non-ham. Is is not whether "the originator is legally allowed to send the
> data", it is whether the message content is legal for ham frequencies.

Actually, aren't there 3rd-party traffic rules, such that, for example, Internet traffic from certain countries can't be transmitted by a US ham (because the US doesn't have an agreement with that country to allow 3rd-party traffic)?

> So an IGate that retransmits a CWOP weather report is not violating the law,
> unless the comment on the weather report is "F**k you" or "Eat at Joe's".

Agreed.

> Nor is there a violation if a non-ham husband uses messaging on findU that
> results in a transmission to a ham wife "Buy milk on the way home".

Unless that non-ham is prohibited from being a third-party for whatever reason.

> We will notice an ongoing problem long before the FCC, and we can handle it
> ourselves without generating any adverse consequences for the IGate operator.

Uh, how _can_ and _do_ we handle it at the present time? Do we have blacklisting
ability in every I-gate to block an offender? That's asking a lot of the thousands of
Tx-IGate operators, who probably aren't monitoring every single station gating to
RF through them. The problem still exists (in a smaller scale) in the APRS-IS
servers, because it only takes one party not enforcing the blockade to let
offenders through.

Frankly, I don't think this whole thread would have gotten started if it weren't for the problem that we _don't_ have a way to handle it. APRS-IS doesn't have the central
authority and resources to automatically and selectively censor traffic.

> But the key point to me is that all of this effort, which requires the mandatory
> signing of each and every packet, does nothing except indemnify IGate
> operators from the regulatory risk of retransmitting profane, encrypted, or
> commercial messages - something which AFAIK has never happened, which
> certainly has never brought the involvement of the FCC, and which because
> of the legalities involved in proving it, is extremely unlikely to involve the FCC.
> Two extremely rare events are extremely-extremely rare to occur together ;-)

I tend to concur with your legal assumption; I was merely stating technical issues
in my previous email.

> As you mention this is the US viewpoint, and I'd like to hear if there are any other countries where this makes more of a difference.
>
> Unless something more significant can be accomplished I'd say that is not worth the effort and the contraction of the network involuntary removal would cause.
>
> Steve K4HG

Andrew, KA2DDO

[Steve Dimse]

On Mar 29, 2014, at 11:13 AM, Andrew P. <andrewemt-***@public.gmane.org> wrote:

> Hi, Steve.
>
> I agree with some of your statements, but I have some questions about others.
> ...
> Actually, aren't there 3rd-party traffic rules, such that, for example, Internet traffic from certain countries can't be transmitted by a US ham (because the US doesn't have an agreement with that country to allow 3rd-party traffic)?
>
Foreign third party rules apply to transmissions to destinations outside the US, not to the country of origination. As long as the destination of the third party message is inside the US this restriction does not apply.

> > Nor is there a violation if a non-ham husband uses messaging on findU that
> > results in a transmission to a ham wife "Buy milk on the way home".
>
> Unless that non-ham is prohibited from being a third-party for whatever reason.

The only restriction which might come into play is the restriction on a third party participating in stating the message "The third party is not a prior amateur service licensee whose license was revoked or not renewed after hearing and re-licensing has not taken place; suspended for less than the balance of the license term and the suspension is still in effect; suspended for the balance of the license term and re- licensing has not taken place; or surrendered for cancellation following notice of revocation, suspension or monetary forfeiture proceedings. The third party may not be the subject of a cease and desist order which relates to amateur service operation and which is still in effect."

Rare, and very hard to detect! Does LOTW suspend certs for this reason? If so, this is indeed another example where an large amount of effort would prevent an unprecedented and extremely unlikely threat.
>
> > We will notice an ongoing problem long before the FCC, and we can handle it
> > ourselves without generating any adverse consequences for the IGate operator.
>
> Uh, how _can_ and _do_ we handle it at the present time? Do we have blacklisting
> ability in every I-gate to block an offender? That's asking a lot of the thousands of
> Tx-IGate operators, who probably aren't monitoring every single station gating to
> RF through them. The problem still exists (in a smaller scale) in the APRS-IS
> servers, because it only takes one party not enforcing the blockade to let
> offenders through.
>
This is not an APRS IS level issue, it is an RF LAN issue. How _do_ we do it? We don't because it AFAIK has never been an issue.

We would handle it the old fashioned way, person to person. Say I'm an IGate transmitting the weather report for CWxxxx, which has "Eat at Joe's". If it is an issue it is only because someone notices it on RF, and they will get in touch with me and I'll remove the station from my blessed list. The FCC is not driving around the country looking for commercial traffic on 144.39!

There can never be a blacklist because any traffic can look like it originates from anywhere.

Suppose a guy starts bootlegging my call, and send on the APRS IS messages to every other station saying "Eat at Joe's". Those destination stations which are on RF will cause the message to be IGated, and lots of IGate operators will be in violation of FCC rules. Blocking my call does not good even if you had a blacklist, he'll just switch to your call. We'll know it because everyone is getting the message. Dealing with this would be harder than if we had per-packet signing. But true authentication doesn't prevent attack on the APRS IS, it just changes the manner.

If someone is determined to ruin the APRS IS, they will do it. Even if you wave the magic wand and sign every packet and have a blacklist, the same guy can just rent a botnet and DoS the APRS IS servers.

We aren't protecting a bank's assets. The APRS IS is not a target, guys with the skills to hack aim at the Targets of the world.

> Frankly, I don't think this whole thread would have gotten started if it weren't for the problem that we _don't_ have a way to handle it. APRS-IS doesn't have the central
> authority and resources to automatically and selectively censor traffic.

The APRS IS also does not have a way to slice bread. It doesn't need it.

The thread started because people are reacting to an extremely unlikely, theoretical threat with effort intensive solutions that modify but don't prevent attack. The best way to be sure the APRS IS does not become a target is to remain useless to hackers. And we will!

Steve K4HG

[Andre]

op 29-03-14 15:45, Steve Dimse schreef:
> As you mention this is the US viewpoint, and I'd like to hear if there
> are any other countries where this makes more of a difference.

In Region 1 (europe and africa) trafic from non hams is out of the
question period but as most countries need additional licencing for
unattended opperation and/or for running an Igate the responcibilety to
stop it only starts as soon as they become aware of it. In the past this
has resulted in the Netherlands at least in repeaters temperary shutting
down because there was abuse of pirates or ATV repeaters being told to
shut down the 13 cm input for a few days because it is a shared band
with police helicopter tv downlink, so it is not limited to internet
based trafic.

73 Andre PE1RDW

[q***@public.gmane.org]

Did the rules change?

Initiating a RF transmission on Ham bands has always required
that the originator be a Ham licensed for that mode, band,
power, etc.

That the "microphone" and "ptt" (for illustrative purposes) is
connected via a "long wire" (the internet) appears irrelevant
to the law/regs.

Where, precisely, do the law/regs allow for a non-Ham to
cause ("ptt") an RF transmission on Ham spectrum?

David KD4E

> Steve Dimse wrote:
> There is an important subtlety here in the US rules. The
> RF-originating station of an automatic message forwarding system
> accepts responsibility for the content of the message, unless s/he
> has verified the non-RF originator was a ham. If there is nothing in
> the message that a ham cannot transmit (e.g. profanity, commercial or
> encrypted traffic), it does not matter that it originates with a
> non-ham. Is is not whether "the originator is legally allowed to send
> the data", it is whether the message content is legal for ham
> frequencies.


--

David (NOT Dave) Colburn, KD4E - Nevils, Georgia USA

Safe & Secure Search Engine: duckduckgo.com

Android for Hams: groups.yahoo.com/group/hamdroid
Creative Tech: groups.yahoo.com/group/ham-macguyver
Raspi Alternative: groups.yahoo.com/group/beagleboneblack/

Restored to design-spec at Heaven's gate 1Cor15:22

[Steve Dimse]

On Mar 29, 2014, at 12:03 PM, qrv-JH0e/***@public.gmane.org wrote:

> Did the rules change?

Automatic message forwarding systems became legal before I became a ham in 1990, perhaps someone who actually qualifies for QWCA can give a precise date. Somewhere in the early to mid 90s there was an issue where a commercial message was passed through the packet system. The FCC issued some NALs. The end result of a lot of grinding and gnashing of teeth was the rules were changed to place the onus on the first station to transmit a message in an automatic message forwarding system. That station must either verify the message originates from a ham or accept liability for the content of the message.
>
> Initiating a RF transmission on Ham bands has always required
> that the originator be a Ham licensed for that mode, band,
> power, etc.

Yes, and the control op of an automatic station must be ham.

> Where, precisely, do the law/regs allow for a non-Ham to
> cause ("ptt") an RF transmission on Ham spectrum?
>
Third party rules. "No station may transmit third party communications while being automatically controlled except a station transmitting a RTTY or data emission" So you can't have a dial in number for non-hams to talk on a repeater, but you can have an email address or web site that non-hams can use to send messages.

Steve K4HG

[q***@public.gmane.org]

No licensed-op validation has yet been implemented or no validation
is required?

A non-Ham may effectively initiate an RF transmission, absent the
presence of a human (to validate that it is Ham-appropriate)
- via the Internet - to then be repeated by numerous unattended
Ham digis, and that is OK?

May a "data emission" theoretically include embedded text & images?

So this essentially means that a Ham license is not necessary for
re-transmitted "RTTY" and "data emission(s)" on Ham spectrum?

Wait until the pirates, pranksters, and CB-scofflaw spectrum-
poachers discover this. Is not some mischief to be had, & a
convenient new medium to be abused, by clever minds?

I hesitate to give them any ideas ...

David KD4E

> Third party rules. "No station may transmit third party
> communications while being automatically controlled except a station
> transmitting a RTTY or data emission" So you can't have a dial in
> number for non-hams to talk on a repeater, but you can have an email
> address or web site that non-hams can use to send messages.
>
> Steve K4HG



--

David (NOT Dave) Colburn, KD4E - Nevils, Georgia USA

Safe & Secure Search Engine: duckduckgo.com

Android for Hams: groups.yahoo.com/group/hamdroid
Creative Tech: groups.yahoo.com/group/ham-macguyver
Raspi Alternative: groups.yahoo.com/group/beagleboneblack/

Restored to design-spec at Heaven's gate 1Cor15:22

[Steve Dimse]

On Mar 29, 2014, at 1:02 PM, qrv-JH0e/***@public.gmane.org wrote:
>
> A non-Ham may effectively initiate an RF transmission, absent the
> presence of a human (to validate that it is Ham-appropriate)
> - via the Internet - to then be repeated by numerous unattended
> Ham digis, and that is OK?

Depends on what you mean by "OK". Understand that a radio amateur is always responsible for a transmission, and the FCC rules spell out who it is. In the case of an non-ham (or an unvalidated ham) initiating a message on the internet it will be the first ham to transmit it on RF. In the case of an APRS LAN, that equates to the IGate operator. The "numerous unattended ham digi" operators have no legal liability.

So it is fully within the rules to have a system that makes this possible, but if the FCC captures an RF message that is inappropriate for ham radio (profanity, commercial, etc) it is the IGate operator that will be NALed if the FCC can prove its origin. The non-ham on the internet, the web site operator, and the APRS IS hub operators have no legal liability because part 97 does not apply to the Internet.
>
> May a "data emission" theoretically include embedded text & images?
>
Sure, data is data.

> So this essentially means that a Ham license is not necessary for
> re-transmitted "RTTY" and "data emission(s)" on Ham spectrum?

Correct, if some ham is willing to accept liability for the content of the message.
>
> Wait until the pirates, pranksters, and CB-scofflaw spectrum-
> poachers discover this. Is not some mischief to be had, & a
> convenient new medium to be abused, by clever minds?
>
If by new medium you mean 25+ years, then yes, just wait. Of course it was far more likely that this would be abused back before the internet provided much more fertile fields for amusement.

The first Internet to RF app I know if was TCPIP/NOS. It existed before WWW. In those days of Gopher there wasn't a lot to do on the net, and this was one of the cooler things. To gain full access to the RF network all you had to do was answer the question "What is the normal 2 meter split in kHz". Type in 600 and you were good to go!

That system was never abused that I know of. The APRS IS has not been abused by the scofflaws in the decade plus the validation algorithm has been known. I can't emphasize enough nothing has changed in the last decade! This is not anything new.

Steve K4HG

[Georg Lukas]

Hi Steve,

* Steve Dimse <steve-***@public.gmane.org> [2014-03-29 14:05]:
> What I haven't heard is exactly what problem all this is aiming to
> solve. Is this a regulatory issue?

Actually, there is a basic problem: providing amateur radio services
over the Internet (besides of APRS, we have Echolink and HamNet as the
contenders, plus of course the LotW project; online logins to your radio
club etc. are possible future use cases).

Currently, all of these are solving the problem by different means, but
all of them require significant manual work. The manual passcode issuing
service we run on aprsdroid.org alone is approaching 20k total
applications, most of which have to be manually checked, and with a
large subset requiring additional communication with the applicants.

If you see no problems with providing a fully automatic,
no-checks-performed, passcode generator like the ones in the original
post, I will be the first one to cease all this tedious work and make
the passcode generation faster and easier for my users, at the cost of
allowing everybody onto APRS-IS.

However, if you consider the other groups doing amateur radio over IP,
we are here at the starting point of a great opportunity to reduce the
total amount of work (maybe by delegating certificate issuing to radio
clubs or regulators like the FCC), and to provide a common mechanism for
Internet-enabled amateur radio services.

73 de Georg DO1GL
--
APRSdroid - Open Source APRS Client for Android | http://aprsdroid.org/m
https://play.google.com/store/apps/details?id=org.aprsdroid.app | @APRSdroid

[Steve Dimse]

On Mar 29, 2014, at 10:25 AM, Georg Lukas <georg-***@public.gmane.org> wrote:

> Hi Steve,
>
> * Steve Dimse <steve-***@public.gmane.org> [2014-03-29 14:05]:
>> What I haven't heard is exactly what problem all this is aiming to
>> solve. Is this a regulatory issue?

> If you see no problems with providing a fully automatic,
> no-checks-performed, passcode generator like the ones in the original
> post, I will be the first one to cease all this tedious work and make
> the passcode generation faster and easier for my users, at the cost of
> allowing everybody onto APRS-IS.

I don't know how many times I can say it. Everyone IS allowed on the APRS IS, or more correctly no one can be prevented from being on the APRS IS. It has been that way since Dale Heatherington open-sourced aprsd. Anyone that thinks otherwise is burying their head in the sand. I do not consider fully automatic passcode generators OK. I wish dearly the passcode was still secret. At 15 bits a brute force cracker could solve it in a minute or two, but it would still serve the original purpose, to provide cover for IGate operators.

While I might wish the secret was only known to a few it is not. So from a practical, realistic point of view I think you have been wasting your time generating all those codes when aprsd users have been generating their own for perhaps 15 years and xastir users for, what, 10 years?
>
> However, if you consider the other groups doing amateur radio over IP,
> we are here at the starting point of a great opportunity to reduce the
> total amount of work (maybe by delegating certificate issuing to radio
> clubs or regulators like the FCC), and to provide a common mechanism for
> Internet-enabled amateur radio services.

I don't have any trouble with hubs offering validation through SSL. What I object to is the idea that implementing this in any way makes the APRS IS more secure. It is OK, even cool that APRSC accepts LOTW certs. But I strenuously object to concepts that start there, make it mandatory, link the hubs with SSL, rewrite the APRS IS protocol, and then exclude legacy apps when all that accomplishes is to protect IGate operators from something that has never happened and has a vanishingly small possibility of ever happening.

Steve K4HG

[Gerhard.F5VAG]

> * It's not limited to APRS-IS. It's quite easy to configure for web
services: https://authtest.aprs.fi/
>

There is one further site I use. PSKREPORTER makes use of the LotW
certificate to let you manage your reporting history.

I'm now on T2HAM with IPv6 & SSL:
http://amsterdam.aprs2.net:14501/

73 de Gerhard, F5VAG

[Gregory A. Carter]

While everyone knows the current passcode is completely vulnerable, how
much of a problem is it today? As in, I haven't really seen a huge avenue
of abuse via this method; SSL certs and ARRL verifications seems a bit
overblown.

I'm not necessarily suggesting this as a solution but I've had pretty good
success charging $5 for verification and though I don't go through the
hassle of checking paperwork, call signs are checked and abuse is monitored
and I have a controlled means of disabling abusive accounts. After all who
really wants to pay $5 just to a abuse a hobby network that really doesn't
peeve anyone off like IRC or other types of networks.

If someone has ill intent for the network they'll simply DoS it out of
existence. This may sound insensitive but really no one cares about APRS
but us. The most abuse we seem to get is uninformed legit hams with
misconfigured stations.

Greg


On Sat, Mar 29, 2014 at 2:10 AM, Heikki Hannikainen <hessu-***@public.gmane.org>wrote:

> On Fri, 28 Mar 2014, Andrew P. wrote:
>
> I just tried connecting APRSdroid to ssl.aprs2.net without a
>> certificate, and it still works (using my old passcode).
>>
>> So that isn't keeping me out.
>>
>
> Yup, it's an experimental feature, and naturally, passcode-only clients
> are not rejected, since that would make a lot of users unhappy. The same
> servers still provide normal service on port 14580. Actually, using SSL,
> you're not getting anything extra at this point, it's a proof-of-concept
> showing that it can be done and doesn't break things as such.
>
> * The server just knows for sure that ARRL has given you a certificate,
> and that they do a stronger validation of license status than most APRS-IS
> passcode-giving software authors would do. The server's status page shows
> that knowledge by showing a clickable "Cert" instead of "Yes" or "No" in
> the Validated column (F5VAG-10 is still on http://iad.aprs2.net:14501/).
>
> * The server at this point doesn't do anything else than that, but it
> could be improved to pass that knowledge onwards to other servers together
> with the packets, and then onwards to other clients. For that to be useful,
> the servers also need to authenticate with each other in a strong way (not
> just passcode). aprsc can do SSL between servers.
>
> * At least from overseas, you can easily send in fake documents to ARRL,
> of course, and they will then give you a certificate. This can, however, be
> battled. It takes a couple of weeks for the mailed documents to go through,
> and it takes actual manual work to go through the process of *mailing* the
> documents. The certificate you get is unique, and once it turns out to be
> in the hands of a pirate, that single certificate can be rejected by the
> services by configuration. The pirate then needs to get another
> certificate, and since it's easier and quicker to block the cert than to
> get a new cert, the battle is easy to fight. The balance of effort is
> uneven.
>
> * The services can block based on callsign embedded in the certificate, if
> the callsign itself is invalid (N0CALL, or some P1RATE, or such). The
> services can also block based on certificate identifier, if a pirate has
> obtained a cert for a legitimate callsign assigned to a licensed ham
> somewhere. The legitimate user can continue using his callsign.
>
> * The certificates are digitally signed by the ARRL (or other CA), you
> cannot adjust your own certificate to contain someone else's callsign - the
> certificate won't validate if you alter its contents.
>
> * A lot of people don't want to be involved with the ARRL, but it's not
> limited to ARRL. If other organisations start giving out client
> certificates, and demonstrate that they validate the license status
> properly, the services can be configured to accept the certificates from a
> large number of different Certificate Authorities. Other leagues, clubs,
> APRS software authors. Even commercial entities, as long as they show
> they're doing it right.
>
> * Ah, you want to run this over radio (2.4 GHz or 5 GHz HamWAN data
> links), and you're not allowed to encrypt the data? The server has been
> tuned to accept the use of 'NULL' crypto, where the transferred data is
> _not_ encrypted. You're still authenticated in the beginning with the
> certificate, and the data is tamper-proof (thanks to HMAC), but the data
> contents are not encrypted while in transit. The client app can select
> whether to encrypt, or to not encrypt.
>
> * It's not limited to APRS-IS. It's quite easy to configure for web
> services: https://authtest.aprs.fi/
>
> * Yes, it can be used with UI-View32 - just run a client-side SSL Proxy
> app such as 'stunnel' to make the SSL connection to the server :)
>
> - Hessu
>
> _______________________________________________
> aprssig mailing list
> aprssig-***@public.gmane.org
> http://www.tapr.org/mailman/listinfo/aprssig
>



--
NV6G
OpenAPRS.Net
OpenAPRS iPhone Edition
Find RC sites and weather in your area on iPhone/iPad with WhereBRC

[Andre]

op 29-03-14 09:10, Heikki Hannikainen schreef:
>
> * Yes, it can be used with UI-View32 - just run a client-side SSL
> Proxy app such as 'stunnel' to make the SSL connection to the server :)
>
> - Hessu
Is it limited to tcp or can it be used for udp as wel so we can use it
for direct links between stations that want to bridge to a remote
alternate frequentie using ax/udp? (mostly usefull for remote monitoring
an event etc. on rf but can have other implementations as wel)
If it is limited to tcp it would leave PBQ32's ax/tcp implementation for
this task or mess around with range filtering adjusting trottle settings
and non intended use of is to rf gating.

73 de Andre PE1RDW

[Matti Aarnio]

On Sat, Mar 29, 2014 at 04:22:14PM +0100, Andre wrote:
> op 29-03-14 09:10, Heikki Hannikainen schreef:
> >
> >* Yes, it can be used with UI-View32 - just run a client-side SSL
> >Proxy app such as 'stunnel' to make the SSL connection to the
> >server :)
>
> Is it limited to tcp or can it be used for udp as wel so we can use
> it for direct links between stations that want to bridge to a remote
> alternate frequentie using ax/udp? (mostly usefull for remote
> monitoring an event etc. on rf but can have other implementations
> as well)

As long as you stick to very old software and platforms, you can not
take new better protocols to good use. Intro of such does not mean
you have to abandon old clients. They can still be supported, but
to get full benefits the clients need to be revised too.

Reasons for AX/UDP are:
* It is easy to send UDP datagrams of arbitrary record limited data
(Up to about 1400 bytes, before fragmentation becomes necessary and
things get complicated..)
* TCP is not datagram protocol, and requires additional wrapper around
packets, especially as it must be BINARY TRANSPARENT.
* TCP does retransmission until rather long timeout, which causes
unpredictable delivery delays (Ok for most uses, bad for having
APRS radio links behind them)
* UDP does produce realiably low delivery latency because it does
not do _any_ retransmission.

There are two ways to get reliable retransmission with control/indication
of outdated packets:

1) Send them over TCP in wrappers with second (or centisecond or
millisecond) timestamps; that requires network connected systems
doing time synchronization - for example NTP

2) Use SCTP protocol with explicitly controlled retransmission
deadline per datagram, plus a wrapper for end-to-end time
delay tracking, and other such possible aspects
(Deliver it in 3.00 seconds, or indicate abandonement.)

Both need different protocol than just plain throwing TNC2 monitor
text lines over the links. As a side-feature that would mean capability
of sending binary transparent data over the APRS-IS.

When introducing new protocol, one can get for free also things like
pre-parse rx-igated packet at the igate, and feeding canonical type
information, coordinates in radians, symbols, callsigns. Now every
APRS-IS core server can avoid parsing the packet, and instead just
read pre-parsed information and process filters - very fast.
Support for older clients is done by entry server parsing the packet,
and sending it in pre-parsed form to others.
(Or by making a gateway software to which UIVIEW32 users connect
within their own machine.)


The old Mozilla proprietary protocol was called Secure Socket Layer
(SSL), and when it was reworked at IETF it got named Transport Layer
Security (TLS).

The TLS protocol has a cousin called DTLS which runs over UDP or SCTP.
http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security

It is still throwing up occasional spanners from the wood-word, and
implementations are being developed. Both closed and open source.


Where you can run the SCTP?
* Any modern Linux
* Any modern BSD
* Any modern Solaris

There both C and Java programmers can use it.

Additionally:
* Cisco IOS based systems
* Commercial 3rd-party stacks for Windows
* OpenSource 3rd-party stacks for Windows (problems with Windows 8?)

For Windows you seem to be out of your luck. But maybe Microsoft
will deliver it in next 10 years or so, they took lots of time for
delivering IPv6 too in the standard product...


I am interpreting some of the opinions stated at this email list as
"because windows users can not use it, it is not worth for anyone".
Actually most of the APRS-IS network servers run on top of UNIXes,
there are some rare Windows hold-outs there too.


> If it is limited to tcp it would leave PBQ32's ax/tcp implementation
> for this task or mess around with range filtering adjusting trottle
> settings and non intended use of is to rf gating.

AX/SCTP would be better, but SCTP not being available on Windows
not be available to many of you.


> 73 de Andre PE1RDW

73 de Matti, OH2MQK

[Ya'akov Sloman]

I'd like to make a couple of suggestions for consideration.

The need for TCP might be reduced to an authentication handshake rather than every frame. If something akin to SMTP AUTH is used, along with some other *temporary* form of shared secret exchanged at the time of the authentication, and combined with the source address, it would reduce the possible abuse window to the horizon of the authenticated "session".

That is, using TLS or equivalent, the station can authenticate to the server using TCP. It is handed an expiring secret, and the session state is retained by the server which includes the call, secret, and source address. After that, UDP frames are used as usual, with the secret acting just as the current passcode does, but with expiration.

It might be beneficial to use the model of DHCP and have the client request a new secret (via the TCP mechanism) at 1/2-expiry.

The method of authentication *could* be PKI or something else since TLS will hide the exchange. PKI has the advantage of not requiring the maintenance of a password file and managing access to it.

There is also the possibility of WoT (Web of Trust) using PGP (or GnuPG, most likely) to decentralize the CA. If we used some method to record trusted signers (which could be completely open since it is not, in itself, confidential), and we required one or more signatures from previously trusted operators, no CA would be needed.

These are just some thoughts, for what they are worth.

Ya'akov
N1EWO

[p***@public.gmane.org]

Just thinking out loud here, but how about a separate authentication/verification system in which I/SGATE operators login to an SSL web-based application and provide something like callsign, current grid, IS passcode and the current IP address of their IGATE. A T2 server must see data coming from that IP(s), and perhaps rough lat/long coordinates, or it is rejected. UDP contains source IP.

A strategy like this would have its problems, especially with mobile (wi-fi hotspots) and DHCP situations. It would be irritating to update your IP periodically, and it's possible that your IP could change without your knowledge -- throwing your IGATE offline. And it would require a centralized database.

Regards,
Paul / KD0KZE

----- Original Message -----
From: "Ya'akov Sloman" <yaakov-8tpoA/b0G6azQB+***@public.gmane.org>
To: "TAPR APRS Mailing List" <aprssig-***@public.gmane.org>
Sent: Sunday, March 30, 2014 5:33:29 AM
Subject: Re: [aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption

I'd like to make a couple of suggestions for consideration.

The need for TCP might be reduced to an authentication handshake rather than every frame. If something akin to SMTP AUTH is used, along with some other *temporary* form of shared secret exchanged at the time of the authentication, and combined with the source address, it would reduce the possible abuse window to the horizon of the authenticated "session".

That is, using TLS or equivalent, the station can authenticate to the server using TCP. It is handed an expiring secret, and the session state is retained by the server which includes the call, secret, and source address. After that, UDP frames are used as usual, with the secret acting just as the current passcode does, but with expiration.

It might be beneficial to use the model of DHCP and have the client request a new secret (via the TCP mechanism) at 1/2-expiry.

The method of authentication *could* be PKI or something else since TLS will hide the exchange. PKI has the advantage of not requiring the maintenance of a password file and managing access to it.

There is also the possibility of WoT (Web of Trust) using PGP (or GnuPG, most likely) to decentralize the CA. If we used some method to record trusted signers (which could be completely open since it is not, in itself, confidential), and we required one or more signatures from previously trusted operators, no CA would be needed.

These are just some thoughts, for what they are worth.

Ya'akov
N1EWO

_______________________________________________
aprssig mailing list
aprssig-***@public.gmane.org
http://www.tapr.org/mailman/listinfo/aprssig

[Jason KG4WSV]

On Mon, Mar 31, 2014 at 3:47 PM, <pfbram-***@public.gmane.org> wrote:
> Just thinking out loud here, but how about a separate
> authentication/verification system in which I/SGATE operators login to an
> SSL

Involving SSL doesn't magically make a system secure. SSL is about
encrypting traffic in flight - that's it. Forcing use of SSL can
provide some measure of authentication, based on the whole CA system.

> And it would require a
> centralized database.

That little aside _is_ the problem. Who do you trust? Who do you
trust to keep a list of people that can be trusted?

For any authentication system to work, someone has to keep a list, and
then be willing to deal with all the extra work involved in certifying
everyone on the list.


I'm with Steve K4HG on this one - as far as APRS is concerned all I'm
seeing are solutions in search of problems.

-Jason
kg4wsv

[p***@public.gmane.org]

The SSL would be for a (separate) verification/authentication system, not the APRS packets themselves, to ensure that the user's app. password doesn't travel plain-text, and is not sniffable. It would be largely a self-policing model. Each operator would maintain his own profile, keeping it current with his callsign, passcode, his IGATE's current IP address, etc. The only thing that would need to be added to the T2 network is (a) noting the IP in the incoming packets and (b) some sort of API to ensure that the IP matches the one noted as "valid+current" by the operator in a hypothetical profile/validation system. I agree, this approach has its problems.

I've worked with SSL, Shibboleth, made my own certs/CA's, etc. and other systems professionally for several years. I'd definitely advise against Shibboleth due to its complexity, moving parts, etc.

Usually it's a matter of approaching the "business problem" itself from a different angle, not just throwing technology at it. Who knows? Maybe there is something to be gained with VPN's, SSL + ssh keys, GnuPG, etc. Certainly with security there is no such thing as a single magic bullet.

But if you could better manage your own IGATE/call against someone spoofing it -- and have a tool on hand to easily block out/filter troublesome stations (point-and-click), then you'd have a more resilient system -- driven mainly by (a) more information available to you and (b) self-policing.

Paul / KD0KZE

----- Original Message -----
From: "Jason KG4WSV" <kg4wsv-***@public.gmane.org>
To: "TAPR APRS Mailing List" <aprssig-***@public.gmane.org>
Sent: Monday, March 31, 2014 4:28:15 PM
Subject: Re: [aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption

On Mon, Mar 31, 2014 at 3:47 PM, <pfbram-***@public.gmane.org> wrote:
> Just thinking out loud here, but how about a separate
> authentication/verification system in which I/SGATE operators login to an
> SSL

Involving SSL doesn't magically make a system secure. SSL is about
encrypting traffic in flight - that's it. Forcing use of SSL can
provide some measure of authentication, based on the whole CA system.

> And it would require a
> centralized database.

That little aside _is_ the problem. Who do you trust? Who do you
trust to keep a list of people that can be trusted?

For any authentication system to work, someone has to keep a list, and
then be willing to deal with all the extra work involved in certifying
everyone on the list.


I'm with Steve K4HG on this one - as far as APRS is concerned all I'm
seeing are solutions in search of problems.

-Jason
kg4wsv
_______________________________________________
aprssig mailing list
aprssig-***@public.gmane.org
http://www.tapr.org/mailman/listinfo/aprssig

[Andrew Rich]

Do we really need it. ?

Given that the current situation is open to abuse

Seems the pass code is just a pain

The only security the current setup offers is "if you know about it" rather than true security

Andrew

Sent from my iPhone

> On 1 Apr 2014, at 8:03 am, pfbram-***@public.gmane.org wrote:
>
> The SSL would be for a (separate) verification/authentication system, not the APRS packets themselves, to ensure that the user's app. password doesn't travel plain-text, and is not sniffable. It would be largely a self-policing model. Each operator would maintain his own profile, keeping it current with his callsign, passcode, his IGATE's current IP address, etc. The only thing that would need to be added to the T2 network is (a) noting the IP in the incoming packets and (b) some sort of API to ensure that the IP matches the one noted as "valid+current" by the operator in a hypothetical profile/validation system. I agree, this approach has its problems.
>
> I've worked with SSL, Shibboleth, made my own certs/CA's, etc. and other systems professionally for several years. I'd definitely advise against Shibboleth due to its complexity, moving parts, etc.
>
> Usually it's a matter of approaching the "business problem" itself from a different angle, not just throwing technology at it. Who knows? Maybe there is something to be gained with VPN's, SSL + ssh keys, GnuPG, etc. Certainly with security there is no such thing as a single magic bullet.
>
> But if you could better manage your own IGATE/call against someone spoofing it -- and have a tool on hand to easily block out/filter troublesome stations (point-and-click), then you'd have a more resilient system -- driven mainly by (a) more information available to you and (b) self-policing.
>
> Paul / KD0KZE
>
> From: "Jason KG4WSV" <kg4wsv-***@public.gmane.org>
> To: "TAPR APRS Mailing List" <aprssig-***@public.gmane.org>
> Sent: Monday, March 31, 2014 4:28:15 PM
> Subject: Re: [aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption
>
> On Mon, Mar 31, 2014 at 3:47 PM, <pfbram-***@public.gmane.org> wrote:
> > Just thinking out loud here, but how about a separate
> > authentication/verification system in which I/SGATE operators login to an
> > SSL
>
> Involving SSL doesn't magically make a system secure. SSL is about
> encrypting traffic in flight - that's it. Forcing use of SSL can
> provide some measure of authentication, based on the whole CA system.
>
> > And it would require a
> > centralized database.
>
> That little aside _is_ the problem. Who do you trust? Who do you
> trust to keep a list of people that can be trusted?
>
> For any authentication system to work, someone has to keep a list, and
> then be willing to deal with all the extra work involved in certifying
> everyone on the list.
>
>
> I'm with Steve K4HG on this one - as far as APRS is concerned all I'm
> seeing are solutions in search of problems.
>
> -Jason
> kg4wsv
> _______________________________________________
> aprssig mailing list
> aprssig-***@public.gmane.org
> http://www.tapr.org/mailman/listinfo/aprssig
> _______________________________________________
> aprssig mailing list
> aprssig-***@public.gmane.org
> http://www.tapr.org/mailman/listinfo/aprssig

[Javier Henderson]

On Mar 31, 2014, at 5:28 PM, Jason KG4WSV <kg4wsv-***@public.gmane.org> wrote:


>> And it would require a
>> centralized database.
>
> That little aside _is_ the problem. Who do you trust? Who do you
> trust to keep a list of people that can be trusted?
>
> For any authentication system to work, someone has to keep a list, and
> then be willing to deal with all the extra work involved in certifying
> everyone on the list.

If we use LotW certificates, we’d be trusting the ARRL. They consider those secure enough to trust them for DXCC credit, so I’m sure we can trust them for this purpose as well.

And in the future, other suitable CA’s could be accepted if they’re ran by equally trusted sources, such as ARRL counterparts in other countries, StartSSL, Verisign, etc.

Hessu OH7LZB did a presentation about all of this at DCC last year, which is available on youtube:

https://www.youtube.com/watch?v=wQxtvvhf4K8

73,
-jav k4jh

[Paul Bramscher]

Maybe where some hesitation comes is in centralization of trust (as
opposed to community trust or self-policing). Centralization is a whole
different sort of trust, and might imply managing a very large database
of users/credentials.

CA's can be handmade for free. As long as the "fingerprint" is
documented and matches what sits on a reputable organization's web site
which offers it, they could be trusted by manually adding the homemade
Certificate Authority to any modern browser.

The philosophy behind public keyrings (web of trust) is generally
community-maintained. It's just a big bucket of public keys.
Advertising yours is your responsibility, and accepting someone is your
judgement call. The idea is that you can't have trust without identity
and security.

Could be more trouble than it's worth here, though. Looks like a
Wikipedia article does a good job of distinguishing between the models:
http://en.wikipedia.org/wiki/Web_of_trust.

I watched parts of the video, pretty good summary.

-Paul / KD0KZE

On 3/31/2014 8:44 PM, Javier Henderson wrote:
>
> On Mar 31, 2014, at 5:28 PM, Jason KG4WSV <kg4wsv-***@public.gmane.org> wrote:
>
>
>>> And it would require a
>>> centralized database.
>>
>> That little aside _is_ the problem. Who do you trust? Who do you
>> trust to keep a list of people that can be trusted?
>>
>> For any authentication system to work, someone has to keep a list, and
>> then be willing to deal with all the extra work involved in certifying
>> everyone on the list.
>
> If we use LotW certificates, we’d be trusting the ARRL. They consider those secure enough to trust them for DXCC credit, so I’m sure we can trust them for this purpose as well.
>
> And in the future, other suitable CA’s could be accepted if they’re ran by equally trusted sources, such as ARRL counterparts in other countries, StartSSL, Verisign, etc.
>
> Hessu OH7LZB did a presentation about all of this at DCC last year, which is available on youtube:
>
> https://www.youtube.com/watch?v=wQxtvvhf4K8
>
> 73,
> -jav k4jh
> _______________________________________________
> aprssig mailing list
> aprssig-***@public.gmane.org
> http://www.tapr.org/mailman/listinfo/aprssig
>

[Steve Dimse]

On Apr 1, 2014, at 12:21 AM, Paul Bramscher <pfbram-***@public.gmane.org> wrote:

> Could be more trouble than it's worth here, though.

I've been trying to imaging how even with magic wands there could be an APRS IS that was secure. I don't see one; as long as there is any way to get illegitimate data onto the APRS IS it cannot be called secure. Here is a scenario for you optimists to chew on.

A basic principle of the present APRS IS and the US rules is that a transmission on amateur RF can be retransmitted without any repercussion. Transmission on RF is accepted as authentication (e.g. a repeater trustee has no responsibility for retransmitting bootleggers). Imagine there is suddenly a steady stream of profane messages on the newly-secured APRS IS that appear to be originated by NNN4XYZ on RF. They appear on the APRS IS signed with the certificate of IGate operator WWW4ABC.

So use your complex hypothetical proposals to differentiate between these two possibilities: Is IGate operator WWW4ABC trying to poison the reputation of NNN4XYZ? Or is a third party trying to poison the rep of WWW4ABC and/or NNN4XYZ by placing this data on RF making it appear to be from one ham and signed by a second? Unless the RF packets are also signed individually (way too bandwidth-intenstive) I don't see any way to tell (other than by sitting in front of the QTH of the IGate to see if it is on RF - the monitor must be very close because it could be a milliwatt xmitter hidden in a nearby tree) to differentiate between these two.

There is a huge difference in liability between these two scenarios. Someone that transmits profane data on 144.39 is violating Part 97. Someone who injects the same data into the APRS IS violates no FCC rule, instead liability is with any IGate operator that retransmits the data. So long as I can legally inject data into the APRS IS that causes an IGate operator to break the rules, there is no shield for the IGate operator, and the whole exercise of securing the APRS IS is pointless.

In other words, not only do I think reaching any level of security on the APRS IS is a waste of time, not only do I think it would require every APRS IS packet be individually signed, but I'm beginning to think it also would require packet level signing of the RF network as well.

Steve K4HG

[p***@public.gmane.org]

I'm pretty much in agreement. At best, a few techniques might slightly improve the situation, but not stop an even casually determined person. About the only end-to-end secure (+identity) system I see would basically be like secure wi-fi, which would entail new kinds of hardware with built-in encryption, ability to drop an SSL cert or public/private ssh key pair into it, or something along those lines.

The tinkerer might instead consider dabbling in wireless mesh networks which have the lower-level fundamentals already in place. That whole direction looks like a rabbit hole that leads nowhere feasible given the open spirit of amateur radio, rules against crypto over RF and so on. Arguably no reason to reinvent the wheel for amateur radio frequencies.

In the pre-computer days, operators gave their callsign over phone or CW and that was that. In the relatively rare cases of trouble, eventually someone might be able to trace the source of transmissions. TCP/IP/UDP is also traceable, but a determined person on wi-fi, anonymizer systems, routing through international sites, etc. can commit mischief with some anonymity. Ultimately, though, it would seem that people with those sorts of skills have financial motive in mind, so they would have other pickings.

73
Paul / KD0KZE

----- Original Message -----
From: "Steve Dimse" <steve-***@public.gmane.org>
To: "TAPR APRS Mailing List" <aprssig-***@public.gmane.org>
Sent: Tuesday, April 1, 2014 12:02:18 AM
Subject: Re: [aprssig] APRS-IS Passcode alternative: SSL + Certificates, with no data encryption

On Apr 1, 2014, at 12:21 AM, Paul Bramscher <pfbram-***@public.gmane.org> wrote:

> Could be more trouble than it's worth here, though.

I've been trying to imaging how even with magic wands there could be an APRS IS that was secure. I don't see one; as long as there is any way to get illegitimate data onto the APRS IS it cannot be called secure. Here is a scenario for you optimists to chew on.

A basic principle of the present APRS IS and the US rules is that a transmission on amateur RF can be retransmitted without any repercussion. Transmission on RF is accepted as authentication (e.g. a repeater trustee has no responsibility for retransmitting bootleggers). Imagine there is suddenly a steady stream of profane messages on the newly-secured APRS IS that appear to be originated by NNN4XYZ on RF. They appear on the APRS IS signed with the certificate of IGate operator WWW4ABC.

So use your complex hypothetical proposals to differentiate between these two possibilities: Is IGate operator WWW4ABC trying to poison the reputation of NNN4XYZ? Or is a third party trying to poison the rep of WWW4ABC and/or NNN4XYZ by placing this data on RF making it appear to be from one ham and signed by a second? Unless the RF packets are also signed individually (way too bandwidth-intenstive) I don't see any way to tell (other than by sitting in front of the QTH of the IGate to see if it is on RF - the monitor must be very close because it could be a milliwatt xmitter hidden in a nearby tree) to differentiate between these two.

There is a huge difference in liability between these two scenarios. Someone that transmits profane data on 144.39 is violating Part 97. Someone who injects the same data into the APRS IS violates no FCC rule, instead liability is with any IGate operator that retransmits the data. So long as I can legally inject data into the APRS IS that causes an IGate operator to break the rules, there is no shield for the IGate operator, and the whole exercise of securing the APRS IS is pointless.

In other words, not only do I think reaching any level of security on the APRS IS is a waste of time, not only do I think it would require every APRS IS packet be individually signed, but I'm beginning to think it also would require packet level signing of the RF network as well.

Steve K4HG

_______________________________________________
aprssig mailing list
aprssig-***@public.gmane.org
http://www.tapr.org/mailman/listinfo/aprssig

[Andrew Elwell]

>> That little aside _is_ the problem. Who do you trust? Who do you
>> trust to keep a list of people that can be trusted?

> And in the future, other suitable CA's could be accepted if they're ran by equally trusted sources, such as ARRL counterparts in other countries, StartSSL, Verisign, etc.

Declaration of interest: I used to look after grid computing sites &
software that depended on delegated authentication / authorization
systems, and it's not a trivial problem.

Using the passcode works. There's very little overhead in the
transaction. It's more of a deterrent than a security feature, same as
CTCSS.

How do you ensure that each 'ARRL counterpart"' follows some sort of
acceptable verifcation of the individual? keeps their certificate
chain secure? has proper policies for revocation / updates etc?

Each client would then need to trust all the CAs that issue
certificates. In the grid world we did this through the IGTF
(http://www.gridpma.org/) and even that needed 3 policy areas
(Americas, EMEA, Asia-Pacific) and the amount of work that was needed
on *each* grid server to follow changes in the list was non-trivial.
see https://dist.eugridpma.info/distribution/igtf/current/ for an
indication of how many *accredited* CAs there are, let alone test and
unaccredited ones. Remember you have to check *each* of those for a
revocation list.

Yes, it can work, but it's a lot of work for possibly very little gain.

Andrew

[q***@public.gmane.org]

Is it possible that someone(s) could flood APRS with bogus traffic
using genuine callsigns?

Just curious about potential vulnerability if APRS is tasked as a
significant technology during a major incident.

Not paranoid, just thinking ahead strategically.

David KD4E

> No news. Perhaps the sky would be falling but for the continuing good faith
> and civility of our self-policing radio service. If there appear immoral
> interlopers pirating amateur RF, they must be "crowd-sourced" and not
> encouraged. <grin>
> 73, Cap KE6AFE



--

David (NOT Dave) Colburn, KD4E - Nevils, Georgia USA

Safe & Secure Search Engine: duckduckgo.com

Android for Hams: groups.yahoo.com/group/hamdroid
Creative Tech: groups.yahoo.com/group/ham-macguyver
Raspi Alternative: groups.yahoo.com/group/beagleboneblack/

Restored to design-spec at Heaven's gate 1Cor15:22

[Steve Dimse]

On Mar 28, 2014, at 7:24 PM, qrv-JH0e/***@public.gmane.org wrote:

> Is it possible that someone(s) could flood APRS with bogus traffic
> using genuine callsigns?
>
Of course. I've said this a hundred times on this sig: anyone can send anything on the APRS IS. Any legit packet that appears on the APRS IS can be exactly spoofed. You could send with your own call, bootlegged calls, or Dr. Seuss rhyming calls.

Steve K4HG

[Lawrence LaBranche]

Yes, the aprs network could be flooded. The only safeguard is moving to more secure, or prohibiting all is to rf traffic.

Lawrence LaBranche KI6ZQY

> On Mar 28, 2014, at 7:24 PM, "qrv-JH0e/***@public.gmane.org" <qrv-JH0e/***@public.gmane.org> wrote:
>
> Is it possible that someone(s) could flood APRS with bogus traffic
> using genuine callsigns?
>
> Just curious about potential vulnerability if APRS is tasked as a
> significant technology during a major incident.
>
> Not paranoid, just thinking ahead strategically.
>
> David KD4E
>
>> No news. Perhaps the sky would be falling but for the continuing good faith
>> and civility of our self-policing radio service. If there appear immoral
>> interlopers pirating amateur RF, they must be "crowd-sourced" and not
>> encouraged. <grin>
>> 73, Cap KE6AFE
>
>
>
> --
>
> David (NOT Dave) Colburn, KD4E - Nevils, Georgia USA
>
> Safe & Secure Search Engine: duckduckgo.com
>
> Android for Hams: groups.yahoo.com/group/hamdroid
> Creative Tech: groups.yahoo.com/group/ham-macguyver
> Raspi Alternative: groups.yahoo.com/group/beagleboneblack/
>
> Restored to design-spec at Heaven's gate 1Cor15:22
> _______________________________________________
> aprssig mailing list
> aprssig-***@public.gmane.org
> http://www.tapr.org/mailman/listinfo/aprssig

[Lawrence LaBranche]

Good!

Lawrence LaBranche KI6ZQY

> On Mar 28, 2014, at 4:08 PM, "Stephen H. Smith" <wa8lmf2-***@public.gmane.org> wrote:
>
> I was Googling for information on the APRS-IS today, and discovered that there are now numerous webpages that have interactive self-serve passcode generators for APRS-IS "validated" log-ins on them. Many will accept absolutely any random alphanumeric string such as tactical calls, CB handles, cipher groups or anything else.
>
> Here are some of the ones I found:
>
> <http://callpass.kf5jwc.us/>
> This one DOES verify that the string entered is a real callsign.
>
> <http://apps.magicbug.co.uk/passcode/index.php/passcode>
> This one will accept anything as input
>
> If you don't want to go online to generate your passcode, this downloadable Windows program will do the job locally:
>
> <http://blog.eagleflint.com/software-downloads/aprs-is-passcode-generator/>
>
> K4HG has been warning for ages that the APRS passcode scheme is totally non-secure, but it has now reached a new level of uselessness with these ready-to-run interactive pages and apps.
>
> I.e. you no longer need to know how to translate the documented algorithm into actual program code in some language.
>
>
> _____________________________________________________
>
>
> --
>
> Stephen H. Smith wa8lmf (at) aol.com
> Skype: WA8LMF
> EchoLink: Node # 14400 [Think bottom of the 2-meter band]
> Home Page: http://wa8lmf.net
>
>
> Long-Range APRS on 30 Meters HF
> http://wa8lmf.net/aprs/HF_APRS_Notes.htm
>
> High Performance Sound Systems for Soundcard Apps
> http://wa8lmf.net/ham/imic.htm
> http://wa8lmf.net/ham/uca202.htm
>
> "APRS 101" Explanation of APRS Path Selection & Digipeating
> http://wa8lmf.net/DigiPaths
>
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig-***@public.gmane.org
> http://www.tapr.org/mailman/listinfo/aprssig