Securing HSMM systems without violating FCC rules

There's a common thread to conversations about implementing HSMM (aka souped-up WIFI): If you cannot use encryption to secure links (because encryption is almost completely prohibited to amateur radio), how do you secure them from access by non-hams?

Let's start with a review of the FCC rule.  §97.113 (Prohibited transmissions) prohibits, in part:

messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein;

 It seems to me that this prohibition rests on two things: (a) the purpose of the encoding and (b) the obscuring of the meaning.

Let's take an example of communications that everyone agrees do not violate this section: the CRC codes in AX.25 messages.

In a packet radio message, the contents of the message include a CRC (cyclic redundancy code) at the end of the message, which is used to verify that the message was received undamaged. Is the purpose to obscure the meaning of the message? Not at all.  The bulk of the message is in plain text, and the CRC merely allows any receiver (intended or otherwise) to verify that the contents of the message.  Does it in fact obscure the message? No, because the CRC can be computed via known algorithms.

Now, lets consider what would happen if we added public key encryption into the mix.  In public key encryption, there are two encryption keys used.  One is private and one is public. Let's say the public key is registered with the ARRL, who makes it available to everyone, amateur or not.  Thus, it is commonly known how to find the public key for any ham.

Messages encrypted with your private key can be decoded by everyone (who has looked up your public key), and if they decrypt successfully with your public key it can be safely assumed that you and only you encrypted them.  This allows you to "sign" messages.  Similarly, any message encrypted using your public key can only be decrypted using your private key.  Thus, anyone can encrypt messages for you and have them be readable only by you.

Let's apply this to the CRC.  What if the sender of the message (who is clearly identified in the packet) encrypts the CRC using their private key?

Anyone (intended receiver or not) can decrypt the CRC using the sender's public key (which they found on the ARRL website).  And if the decrypted CRC is correct for the packet, we know two things: we know that the message was received without errors, and we know that the sender specified in the header did, in fact, send the message (i.e., it was not spoofed).

OK, how does this work with the law?

Is the purpose to obscure the meaning of the message? Not at all.  Consider:

• The actual message -- the rest of the packet -- is not encoded.
• The CRC is just as readable as it was before; you decode it using the sender's public key, and then you match it to the message to validate the contents.  Even the meaning of the CRC is not obscured; it is readable by all who posses common knowledge.
• What is the purpose of the encoding? The base CRC encodes the data to ensure that there is no error in it.  The "enhanced" CRC is encoded to ensure that the sender is properly identified.

So, will you agree with me that you can use a public key encryption to "sign" messages to authenticate the sender?

(If not, stop now.)

If that's possible, then, of course, there is going to be something analogous with HSMM.  It will be possible to authenticate the sender even while the message is in cleartext, and the receiving system can decide if the sender is authorized to use the system.  If not, the message can be ignored. Again, if the ARRL (or some other recognized body) keeps the list of call signs and public keys, then "open" systems will merely need to look-up an unknown call sign to add its public key to a cache and then allow all hams in and keep all non-hams (who, we assume, do not have a valid call sign with an entry in the ARRL database) out.

Did I miss something? Tell me in the comments!