Ross,
I might have been misunderstood.
I did not mean that we should normally use encrypted text for the
messages and almost all the time we would not. However, especially if
there was a large number of deceased, the authorities would be reluctant
to allow that traffic to go unencrypted over our networks.
The media is these days very much a wild card.
73 Barry VK2AAB
Ross Whenmouth wrote:
> Hi,
>
> I think that cryptographic authentication which does not obscure the
> message being conveyed, should not only be allowed, but should be
> encouraged for practices like repeater linking via the internet and
> remote controlled transceivers, etc
>
>
> However, I am very much against the conveyance of encrypted traffic
> (deliberately obscured messages) via amateur radio. I even consider the
> D-Star is treading a very fine line because the codec used is secret and
> the only way to decode it is with DVSI's magic black-box chip. I am not
> familiar with the HIPAA regulations. If HIPAA provides for relaxed
> privacy rules in time of emergency, then there is no problem?. Cleartext
> communications have the advantage that anyone with the right equipment,
> even just riding in the ambulance with a handheld because the
> paramedic's trunked radio system is down can make a difference without
> dealing with the issues of key managment and having the right crypto
> hardware.
>
> Thinking about it, if there has been a large scale disaster or other
> emergency situation sufficient to require hams to provide emergency
> medical communications, and I am seriously unwell, requiring urgent
> medical assistance, then secrecy of communications between whoever is
> treating me and whoever holds my medical records will be the least of my
> concerns.
>
> If this is not acceptable, then a compromise might be to allow only
> personally identifiable information to be encrypted (eg name, sex, DOB)
> with everything else sent cleartext.
>
>
> I imagine that crypto authentication could work on a "web of trust",
> like SSL/TLS.
> For instance, I generate a public/private key pair (or I may be supplied
> with one) and my public key is signed by an entity that certifies that I
> am indeed a ham. NZART confirms my licence and signs my key with their
> private key.
> ARRL and NZART trust each other as licence certifiers so they sign each
> other's keys (the IARU is probably a good way to connect the various
> licence certifiers with each other).
> A ham in say the USA has his key signed by say the ARRL (or maybe the
> FCC if the US gov't wants to handle it?)
> Then, when I try to connect to the VOIP to RF gateway in the USA, the
> remote machine sees that my key is signed by NZART, and NZART's key is
> signed by ARRL, which is marked as a trusted certifier by the repeater
> trustee, so I am granted TX privileges.
> To prevent session hijacking, each authenticated packet would need to
> contain a crypto authentication token instead of the regular CRC - maybe
> something like the method used for "rolling code" alarm remote controls
> where the token is a hash of the packet contents a rolling packets sent
> counter (this protects against replay attacks) and a shared secret
> (which would be negotiated during the authentication process). Since
> this shared secret is just a number used for authentication, is not
> "intelligible information" or a way of conveying a message, and all
> "messages" are sent clear text, the negotiation of this shared secret
> should not be considered to be "a message obscured by cryptography".
>
>
> Regarding the press listening to amateur emergency comms, should we be
> concerned about this? what is it that we are doing that we don't want to
> be public?
> My understanding is that keeping the public in the dark, feeding them
> half-truths and bull-dust is a good way to breed conspiracy theories and
> mistrust of authorities, which can be counter-productive to good
> emergency management.
>
>
> 73 ZL2WRW
> Ross Whenmouth <[email protected]>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Freetel-codec2 mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
