[EAS] Fallout Over False Alert Continues

Rich Parker rparker1 at gmail.com
Wed Oct 29 14:44:14 CDT 2014


Well put - the elephant in the room for EAS continues to be issues of authentication and non-repudiation - which we had a pretty high level of in the days of the 'red envelope' ;)
But simply using a 'date stamp' alone to verify anything is madness - and clearly there is no 'real' form of authentication and non-repudiation - otherwise, the You-Tube 'brapps' could not have caused receivers down the line to respond and react. 

A system whereby authentication codes (as part of the digital brapps) are sent as part of RMT's (for instance), especially in the case of Premier, NPR EMNet, and others, as part of a strict program to ensure that a unit 'checks' the hash and confirms it is coming from a 'known provider' (i.e. one of their monitoring assignments which have previously sent RMT's - or even RTW's) to verify that it is 'valid' signal would be a good start. And it isn't rocket science - the 'hash' could be something as simple as a rolling combination of the 'ID' of the sending device and the Julian time once a month when the RMT is sent, and perhaps another unique number - box serial number or similar -  to produce a unique 'ID'code/hash that would be checked against a known 'list' of 'good actors' before a message was relayed or forwarded. This would get stored and updated on receivers down the line each time an RMT was issued, ensuring that any subsequent 'alerts' came from where they were supposed to be coming from.

Otherwise, not only can random jocks play random recordings of EAS alerts, tones and all, generating another incident as we have just seen, but what you have is the even more alarming possibility of a planned disruption (a la the WTTW Max Headroom incident) where a rogue actor overpowers an STL link, uses a readily available bit of hardware, and generates a fake EAN or similar.

This is not random fear mongering - there was a well known set of 'incidents' in Texas where several stations' transmitter sites were broken into and 'disabled' in various ways - ways that required a fair amount of knowledge of the systems involved - and which all seemed like 'isolated events' until folks started comparing notes, and the FBI and others got involved. What would be the purpose in disabling major broadcast outlets serving a major metro (Houston as I recall)? Perhaps just plain mischief, or perhaps a test to see if it could be done in a coordinated fashion to allow an 'event' to occur and create the maximum FUD due to poor communications.We're not in Kansas anymore, Toto....

No system is 'idiot proof' - but leaving a piece of burlap over an open trap-door and expecting that a 'sign' saying 'don't walk here' is adequate protection is magical thinking of the highest order....

Rich Parker
Director of Engineering
CoastAlaska, Inc
Juneau, Alaska
(formerly SECC of Vermont EAS and CSRIC Working Group participant)

On Wed, Oct 29, 2014 at 11:18 AM, Dave Turnmire <eassbelist at cableone.net> wrote:
 
>[snip}  Some problems need to get fixed systemically and in this case, IMHO, the problem is basically a
>technical one at its heart.  As is often the case, fixing a technical problem involves politics and bureaucracy to approve the fixes.  And
>some fixes aren't easy in practice due to "backwards compatibility" issues. 
 
>But at the heart... we need a technical fix.  As long as we have a system that "breaks" simply because someone re-played a recording
>of an earlier alert... that system is going to keep getting broke. Blaming people who innocently (in some cases at least) made a bad
>content decision that they had no realistic way to know was a bad decision... is... IMHO... wrong.  We are engineers (mostly).  Lets do
>what we do best and engineer a fix....

>Dave

>__________________________________________________________
>The EAS Forum Discussion List is hosted by the BWWG (Broadcast Warning Working Group). http://eas.radiolists.net
>Please invite your friends to join our Forum! The sign up is at: http://lists.radiolists.net/mailman/listinfo/eas
>___________________________________________________________



More information about the EAS mailing list