If I were to implement a remote computer control system using amateur radio, would using hashes (such as md5, sha-*, etc...) for authentication be permissible under the United States rules?
$\begingroup$
$\endgroup$
Add a comment
|
3 Answers
$\begingroup$
$\endgroup$
4
Yes, they are. Generally speaking, authentication is legal, obfuscating is not legal. So you could do a cryptographically signed hash that would be legal in the United States to transmit over Amateur Radio.
It's worth mentioning that there is some debate as to how legal a cryptographically signed hash would be. I believe it would be legal, so long as it was a signature, intended to ensure that the message came from a particular person.
MD5 type hashes are definitely legal, they merely provide a signature of data already sent, and are used to ensure the data that was sent is correct.
answered Aug 30, 2015 at 20:04
-
2
-
1$\begingroup$ I'm sure as an error detection mechanism is legal. It's basically a fancy checksum. A more interesting question is the use of a cryptographic signature. This usually means that the hash is encrypted with the private key of the sender. The receiver, if he has the sender's public key, can verify who really sent it and conversely, the sender cannot deny that he sent it. Is that legal? Maybe it's a gray area but I think probably yes provided that the message content is not encrypted. $\endgroup$– KT1FCommented Sep 1, 2015 at 17:31
-
$\begingroup$ The word Encryption doesn't actually appear in Part 97, only the word Obscure. I don't believe this obscures the meaning to have a crypto signature, but I'm not an expert in the law, so... $\endgroup$ Commented Sep 1, 2015 at 17:40
-
$\begingroup$ CRC checksums in APRS packets are also allowed. This would set the precedent for hashes like MD5 and friends as well. $\endgroup$– captchaCommented Nov 30, 2015 at 23:39
$\begingroup$
$\endgroup$
Please see:
§97.309 RTTY and data emission codes.
(a) Where authorized by §§97.305(c) and 97.307(f) of the part, an amateur station may transmit a RTTY or data emission using the following specified digital codes:
(1) The 5-unit, start-stop, International Telegraph Alphabet No. 2, code defined in ITU-T Recommendation F.1, Division C (commonly known as “Baudot”).
(2) The 7-unit code specified in ITU-R Recommendations M.476-5 and M.625-3 (commonly known as “AMTOR”).
(3) The 7-unit, International Alphabet No. 5, code defined in IT--T Recommendation T.50 (commonly known as “ASCII”).
(4) An amateur station transmitting a RTTY or data emission using a digital code specified in this paragraph may use any technique whose technical characteristics have been documented publicly, such as CLOVER, G-TOR, or PacTOR, for the purpose of facilitating communications.
(b) Where authorized by §§97.305(c) and 97.307(f), a station may transmit a RTTY or data emission using an unspecified digital code, except to a station in a country with which the United States does not have an agreement permitting the code to be used. RTTY and data emissions using unspecified digital codes must not be transmitted for the purpose of obscuring the meaning of any communication. When deemed necessary by a Regional Director to assure compliance with the FCC Rules, a station must:
(1) Cease the transmission using the unspecified digital code;
(2) Restrict transmissions of any digital code to the extent instructed;
(3) Maintain a record, convertible to the original information, of all digital communications transmitted.
[54 FR 25857, June 20, 1989, as amended at 54 FR 39537, Sept. 27, 1989; 56 FR 56172, Nov. 1, 1991; 60 FR 55486, Nov. 1, 1995; 71 FR 25982, May 3, 2006; 71 FR 66465, Nov. 15, 2006; 80 FR 53753, Sept. 8, 2015]
$\begingroup$
$\endgroup$
3
While some of this discussion ventures into cryptography terminology, your understanding of it may not automatically mean that the FCC will see it the same way. A hash is a one-way cryptographic function, and as such, it cannot be "decoded" on the other end with a password (or key). This is clearly not obfuscation.
Now, if this hash is sent out in the open as a "signature", there is no guarantee that someone else cannot intercept it and send it from his or her own station later. One way to prevent that is to have a list of one-time strings shared in advance, out of band (off-air). Once a string is used, it is scratched off by both parties. (You can automate this process with an OTP mobile app based on just one pre-shared string. These strings are strictly used for authentication, and can change every few seconds. Nobody can predict the next one without access to the secret string. They also only take a few digits, so they do not look suspicious as "obfuscation".)
The vague area comes from encrypting a hash with a private key. As the name of the process implies, it is actual encryption, since you use the recepient's public key that derived from his private key, and your private key remains secret. The purpose of Public Key Cryptography is in fact, would satisfy the FCC's definition of obfuscation, because the process hides the meaning of the message from those who intercept the transmission. That would be a clear violation of FCC rules.
In addition, someone intercepting the message would not immediately know that your string is "just a hash signature"; you may be accused of sending an AES-256 encrypted string, which is actually two-way encryption, and as such, "obfuscation".
The rules were most likely not written with all these technicalities in mind, so the best bet is to keep it safe and minimize cyphertext traffic.
-
$\begingroup$ I don't agree with your third paragraph. Firstly, it's technically incorrect. If I sign a message, I hash it and then encrypt the hash with my private key. The recipient uses my public key to decrypt the hash, and then compares it with the hash that he computes. No recipient key is involved. Assuming the message content is sent in clear text, what is being obscured? Anyone can receive the message without my key. They just can't be sure that I sent it. I know it hasn't been ruled on by the FCC so nobody knows the real answer but ... I find it hard to see how this would be against the rules. $\endgroup$– KT1FCommented Dec 1, 2015 at 18:21
-
$\begingroup$ Someone could accuse me of putting encrypted messages into my RST reports, too. So should I avoid those too? $\endgroup$ Commented Dec 1, 2015 at 21:55
-
$\begingroup$ KT1F, you are correct, I made the assumption in that paragraph that we were talking about using private and public keys to encrypt the message itself. In fact, the subject I should have been discussing was limited to the signature, not the message. $\endgroup$ Commented Dec 5, 2015 at 8:55