Cryptographic Authentication for Remote COP Commands - Integration Project

Third-Party Apps
1

Hello AllStarLink community,

I'm working on integrating cryptographic authentication into app_rpt to enable secure remote management of repeaters. I'd like to share the concept and get feedback before submitting a pull request.

Background

I maintain gr-linux-crypto, an open-source cryptographic library for GNU Radio that provides Linux kernel keyring integration and Brainpool elliptic curve cryptography. The library has undergone extensive testing including formal verification and fuzzing (805+ million test executions).

The Problem

Currently, remote repeater management often requires physical access to sites, sometimes in difficult or dangerous conditions. While AllStarLink enables remote connectivity, there's no cryptographic authentication for control operator commands or configuration changes.

Proposed Solution

Add optional cryptographic authentication to app_rpt for:

  • Control Operator (COP) commands issued remotely

  • Configuration changes to repeater settings

The implementation uses:

  • Brainpool ECC for digital signatures (ECDSA)

  • Linux kernel keyring for secure key storage

  • Optional hardware security module support (Nitrokey, TPM)

Key Design Principles

  1. Completely optional - Authentication is disabled by default

  2. Backward compatible - No breaking changes to existing deployments

  3. Gradual adoption - Three modes: disabled, optional, mandatory

  4. No protocol changes - Authentication data embedded in existing IAX2 frames

Implementation Approach

The integration adds gr-linux-crypto as an optional dependency. When authentication is disabled (the default), app_rpt behaves exactly as it does today. When enabled, commands can be cryptographically signed and verified before execution.

Configuration example:
[general]
authentication_mode = disabled ; disabled (default), optional, mandatory

Technical Details

  • Challenge-response authentication using ECDSA signatures

  • Timestamp validation to prevent replay attacks

  • Per-node authorization policies

  • Audit logging of all authenticated operations

  • Build-time optional dependency (app_rpt can be built with or without authentication support)

Current Status

I'm preparing to fork app_rpt and create the integration layer. The cryptographic library is complete and tested, but has not been tested with actual radio hardware. The integration work can be done and tested in software before requiring RF validation.

Questions for the Community

  1. Is there interest in cryptographic authentication for remote repeater management?

  2. Are there specific COP commands or configuration parameters that should be prioritized?

  3. What would be the preferred key management approach for your use case?

  4. Any concerns about the proposed backward-compatible implementation?

Links

I'm open to feedback and suggestions before proceeding with the integration work. If there's interest from the community, I'll create a more detailed technical specification and submit a pull request for review.

Thanks for your time.

2

Reading through this seems interesting, but I have some questions/discussion points:

Strategically, are you intending a complete fork of app_rpt? Or are you wanting to branch with the eventual goal of having the code pulled back into app_rpt?

What is the method by which you would propose remote administration of the node? If it is network-based, wouldn't the right starting location be the Asterisk AMI interface? There is TLS encryption for the connection itself and user authentication already exists in a fashion. I just wonder if that is a base you can build upon since it exists and would make is easier to integrate with the Asterisk ecosystem. Lots of additional logic would be needed inside the app_rpt code to improve the AMI hooks and such.

However, you also mentioning testing with radios, so are you intending to encrypt the traffic over the air? AllStarLink is an amateur radio project and, historically, hews very closely to the ITU rules of amateur radio worldwide. In those rules, cryptography is generally prohibited in the amateur service bands. Who is the target audience for an RF-based encrypted management system if that is what you intend?

You want to embed some sort of AAA service into the IAX protocol stream it sounds like? Is the goal to have one system pass administration commends over IAX to another system? One of the ways that you could really help the community at large is helping with a transition of the current node authentication being IP-based to some sort of token basis. If you are going to be hacking on the IAX2 protocol, a general purpose authentication system that authorizes individual calls and actions within those calls would really help move the ball downfield on our IPv6 problem.

Finally, would you foresee any need to have some sort of centralized registry for the public keys? Would you be asking ASL to be that repository?

3

Thank you for the detailed questions. Let me address each point:

Fork vs. Pull Request

My intention is to branch with the goal of having the code pulled back into app_rpt, not to maintain a permanent fork. The authentication layer is designed to be an optional addition that doesn't change core app_rpt functionality. If the community and maintainers find it useful, it should merge cleanly.

Method of Remote Administration

You raise a good point about the Asterisk AMI interface. I hadn't considered building on top of AMI with TLS, and that's worth exploring. My initial thinking was to authenticate at the IAX2/app_rpt layer because:

  1. It authenticates the command itself, not just the connection

  2. It allows per-command authorization policies

  3. It works within the existing node-to-node communication pattern

However, if AMI with TLS provides a cleaner integration path and the additional AMI hooks you mentioned are something the project needs anyway, I'm open to that approach. Could you elaborate on what AMI improvements you think would benefit the broader project?

RF Encryption - Absolutely Not

To be completely clear: I am NOT proposing to encrypt anything over the air. I'm well aware of ITU regulations prohibiting encryption in amateur radio bands, and this project fully respects those rules.

The authentication is for network-based remote administration only - specifically, authenticating commands sent over the internet via IAX2 between nodes. The RF side remains completely unencrypted and compliant with amateur radio regulations. The use case is: operator at home sends authenticated command over internet to remote repeater site, which then operates normally on amateur frequencies. Its also possible to send those commands by RF.

IAX2 Authentication vs. IP-Based

Yes, the goal is to move beyond IP-based authentication to token/signature-based authentication. Your point about this helping with IPv6 transition is excellent - I hadn't considered that benefit. If individual call and action authentication within IAX2 would solve broader problems for the project, that sounds like the right scope.

This is actually a more general problem than just my specific use case. Would you suggest the authentication system should be:

  1. General-purpose for all IAX2 operations (broader benefit)

  2. Specific to app_rpt COP commands (narrower scope)

I'm willing to work on the broader solution if that's what the project needs.

Public Key Registry

I had not planned to ask ASL to be a centralized key repository. My initial thinking was:

  • Node operators manage their own keys locally

  • Public keys distributed peer-to-peer or via existing node lookup mechanisms

  • Similar to how SSH keys are managed

However, there's precedent for public key infrastructure in the amateur radio community. GnuPG, for example, uses public key servers where users can upload and retrieve public keys. A similar model could work here:

  • Node operators upload public keys to a key server (could be community-run, not necessarily ASL-operated)

  • Nodes query the key server to retrieve public keys for authentication

  • Follows the established pattern that hams are already familiar with

Alternatively, if a centralized registry would be useful for the project (perhaps for the general IAX2 authentication system you mentioned), I'm open to discussing the architecture. What are your thoughts on centralized vs. distributed key management for this use case?

Next Steps

Based on your feedback, I should probably:

  1. Research the Asterisk AMI approach more thoroughly

  2. Clarify the scope - narrow (COP commands) vs. broad (general IAX2 auth)

  3. Understand the IPv6 transition problems better

  4. Define key distribution architecture (possibly using a GnuPG-style key server model, or use existing key servers)

Would you be willing to discuss the AMI approach and IPv6 challenges in more detail? I want to make sure any work I do aligns with the project's broader needs rather than just solving my specific use case.

Thanks again for the constructive feedback.

4

Lots to unpack above and probably some "realtime" conversations would be easier about some of these topics, especially because there are people who would have key insight that aren't frequent commenters on the forum.

To things I will state though:

  1. The current registration system is horribly ancient and needs to be replace entirely. Right now, many people have to jump through network hoops to make stuff work. And if you're behind a CGN forget it. Of if you're behind some sort of traffic accelerator, forget it. Or if you want to roam between connections... or if you're IPv6 native... etc. etc. I've mapped out some of the very basics, but we need a new registration/authentication/authorization system that:

    a. Split the concepts of a repeater and/or hub from a "hotspot". The former are "services" that should be handled differently from the latter "lightweight client". There's kind of a model for this with WebTransceiver but it's not an integrated system.

    b. "Services" should be expected to have reachable IPv4 and IPv6 addressing and ports that are "well known" and "published". However "clients" should be able to connect and provide address/port information on demand and not require IP/port mappings in the registration system.

    c. Everything has to have an option to operate "offline" such that Internet/registration system access isn't required if desired or in an emergency.'

    d. Unify the concept of the "registration" and "directory" elements.

    e. Provide for a dynamic transition mechanism so that "Services" can fall back to old IP-based registrations.

  2. A central registry that's more-or-less "automatic" for most users will be necessary. I understand completely what you mean by SSH keys but a large portion of our userbase won't deal well with having to manage the keys. A desired end state would be some sort of CDN-delivered key trove with a predictable naming scheme. We have the infrastructure to make that happen.

5

Registration/Authentication System Overhaul

Your points about the current registration system's limitations are well-taken. The issues you describe (CGN, traffic accelerators, IPv6, roaming) are exactly the kind of problems that modern authentication can help solve. Your outlined requirements make a lot of sense:

a. Service vs. Client distinction - This is a good architectural split. Repeaters/hubs as "always-on services" versus hotspots as "lightweight clients" have fundamentally different needs. The WebTransceiver model sounds like a good starting point to study.

b. Reachable services vs. dynamic clients - This aligns well with a token-based authentication approach. Services can have stable identities and well-known endpoints, while clients can authenticate dynamically regardless of their current network location. This is actually one of the strengths of cryptographic authentication - identity is tied to keys, not IP addresses.

c. Offline operation - Critical for emergency communications. A proper authentication system should allow for pre-shared keys and offline verification without requiring constant registry access.

d. Unified registration/directory - Makes sense. These are logically related functions that shouldn't be separated.

e. Graceful fallback - Essential for any transition. The backward compatibility approach I outlined should support this - services can accept both old IP-based and new token-based authentication during the transition period.

Central Registry with CDN

Your point about user experience is important. While SSH-style key management works for technical users, the broader ham radio community needs something more automatic. A CDN-delivered key repository with predictable naming (similar to how the current node lookup works) sounds like the right approach:

  • Node generates keypair locally

  • Public key uploaded to central registry (one-time setup, could even be automated)

  • Keys distributed via CDN for performance and reliability

  • Predictable lookup: keys.allstarlink.org/node-12345.pub or similar

  • Keys cached locally after first retrieval

This would provide the security benefits of cryptographic authentication while keeping the user experience simple.

Scope Clarification

Based on your feedback, it sounds like the authentication work should be:

  1. Broader scope - General IAX2/registration system authentication, not just COP commands

  2. Service/client aware - Different authentication patterns for services vs. clients

  3. Part of larger overhaul - Integrated with the registration/directory system redesign

This is a bigger project than my initial proposal, but it sounds like it addresses real pain points the project is facing.

I want to make sure I'm solving the right problem in the right way. If the project is already planning a registration system overhaul, integrating authentication properly from the start makes more sense than bolting it on afterward.

Before I start any implementation work, I'd like to make sure I'm building the right foundation.
So,- I need

  1. Current registration system architecture - How the existing IP-based registration works in the codebase

  2. WebTransceiver model - You mentioned this has a service/client model worth studying

  3. Existing IAX2 implementation - To understand what protocol extensions might be needed

Additional Information

If you have:

  • Your registration system mapping/design notes for the planned overhaul

  • Technical requirements or architectural decisions not yet in the public repos

  • Specific design directions you'd like the authentication system to follow

...that would be very helpful for ensuring my work aligns with where the project is heading.

My Contribution Plan

Once I understand both the current system and your planned architecture, I can:

  1. Adapt gr-linux-crypto to provide exactly the key management and signing functions you need

  2. Prototype the authentication layer based on your specifications

  3. Test against your requirements for services, clients, and offline operation

  4. Iterate based on feedback before integrating into app_rpt

6

Since you mentioned possibly making IAX changes/enhancements, a current issue is that as IAX packets are forwarded through intermediary nodes, no metadata indicating the source of the IAX audio is retained/forwarded. This causes issues if a user accidentally bridges larger networks together ie. makes it harder to figure out which user it is or to prevent those connections in the first place, and could create security issues. In addition on a larger network no one has any idea what node is keyed up at any particular time. In the digital radio modes such as DMR or DSTAR etc. the callsign / radioID is propagated and shown on the radio or in dashboard tools, which is very useful and helpful. Would be great if the originating node# (and maybe a token) could be attached to IAX packets (probably just on the first packet after a node keys up so as to not take up excessive space in all packets) and retained as packets are forwarded through intermediary nodes. Ideally each intermediary node would also add their node# and token info so it’s clear what nodes an IAX packet traversed.

I’m not an expert on this but the ASL node directory is a text file with node#, callsign, desc., and location text (astdb.txt file or more recently similar data written to a sqlite db file) along with a rpt_extnodes file with the IP and IAX port of each node. For authentication why not just add a public key for each node as an extra column in one of these existing files? That would solve the issue of authentication if the allstarlink servers were down or inaccessible, would seem simple to implement, and then the need for IP addresses in rpt_extnodes could be phased out. Seems this could handle all cases (server, ‘lightweight client’, web transceiver) thus maybe no need to then bother with those distinctions or make things any more complicated than necessary. Would be interested to hear your thoughts on this. Thanks

7

That could possibly be fixed.
note that I am in slack.