[EAS] Fallout Over False Alert Continues

[David Turnmire]

I may be missing something, but doesn't this essentially only provide a 
solution to the recent scenario where the real problem is the box not 
knowing what year the alert was sent for?  Aside from that particular 
issue, the system already knows how to recognize an expired alert.   My 
general view on technical problems is to fix the root problem when 
possible. In this scenario, the root problem is not knowing the year.  
If you are going to do something that requires changing software and 
rules... then fix that core problem.

The other problem we have is validating a deliberately false alert.   
And if I understand Mike's proposal correctly (and... I may very well 
not), all a "bad guy" has to do is intercept that weekly transmission, 
get the code, and use it in the bogus alert. Admittedly, that is harder 
than the scenario we currently have... but not by a lot.  Am I 
misunderstanding the proposal?

IPAWS already uses digital signatures both to accept alerts and in the 
distribution.  So, unless I'm missing something, we are already pretty 
secure in that aspect.  With enough effort, sooner or later someone will 
likely find a vulnerability and exploit it, but you can say the same for 
your bank account.  In my view, the more critical item is seeing if we 
can make the "legacy" part of this system less vulnerable.  Right now it 
takes very little resources (equipment, knowledge) to exploit the 
system.  As others have noted, we have been just lucky so far.

Still, we have, I believe, an opportunity in the fact that the early 
generation EAS equipment won't be with us that much longer. Indeed, some 
will become effectively illegal next June.  Once we have unsupported 
equipment that can only be upgraded by swapping firmware chips, we have 
more options.  For various reasons, it seems we'll likely continue 
having SAME as part of the EAS system for some time.  But that doesn't 
mean we can't find a clever way to "tweak" the protocol that is 
backwards compatible with consumer weather radios, while still providing 
enhanced security where we need it the most... at broadcasters and cable 
companies.

For instance... we have 8 characters devoted to a "callsign". Could we 
get by with using only 4 of those for a callsign and use the rest for 
carrying some extra bytes related to an authentication scheme?  Your 
consumer weather receiver would just ignore the that part, so no problem 
there.  We already have cases where three and even four broadcasters are 
using the same encoder and just pick 2 of those callsigns to include in 
alert.  Not much different to drop that to just using one 4 character 
callsign.  If all the associated stations are in the same building, that 
is likely "close enough" for identification purposes.  If I did my math 
right, and using only alphanumeric characters (upper and lower case), we 
end up with something like 14 million possibilities.

Is there some clever mathematical way that we could change the above 
code automatically in some fashion, that is easily "solved for" in the 
decoder, yet not predictable based upon interception of the broadcast 
code?  That is outside of my expertise, but I suspect so.  Maybe in one 
of the ways Rich mentioned earlier (using the Julian date, or 
whatever).  Or maybe you'd need to combine this with getting a periodic 
updated number such as Mike described via a secure system like IPAWS.  
The key thing in my view is that if the system required a second number, 
you need to get that number far enough in advance to avoid any temporary 
internet outage issues, while not so far in advance that it allows a 
hacker to know which one of those 14 million possibilities above to use 
in his fake alert.

Whatever the solution, IMHO, if we are going to do something that 
requires modifying software AND FCC rules... lets address both the event 
YEAR issue.... AND the sender authentication issue... at the same time.  
In a way that is useable with RF delivered alerts that essentially use 
SAME... with a few tweaks that consumer receivers don't mind.  It 
needn't be the same security system as used with CAP (present or 
future)... but that doesn't mean it can't leverage the fact that the 
same box knows about CAP.

Dave

On 10/30/2014 6:41 PM, Mike McCarthy wrote:
> Since it was my idea, let me elaborate. The authentication code would be
> made available and circulated either as the RWT or a referenced attached
> file to the RWT retrieved by the EAS box each week. The code would then
> be stored in the local unit until updated the following week. Thus when
> there is such an alert, the box need not reach back to the mother ship
> and probably through a very congested internet and server.
>
> A safety would be either a two week overlap where either of two codes
> would work and/or the box "phone home" if it should receive a request it
> doesn't recognize or can confirm.
>
> The key here is to 1) Make the authentication process lightning fast so
> the relaying box can react accordingly. The process could be similar to
> Kerbos to insure the code remains uncompromised. And 2) create something
> in the message header compels the ENDEC to refer to that authentication
> code and cross check to the companion code in the header.
>
...