[EAS] Fallout Over False Alert Continues

[Mike McCarthy]

On the security issuse concept, I don't dispute the fact a person with a
properly operating box could procure a code by simply connecting to the
IPAWS server like every one else. The real challenge would be generating
the code in the ENDEC. Since it's only the PEP box which would generate
the code, only a handful of boxes need that capabiliy. All boxes down the
line would blindly repeat that same header once validated.

In the process, it would render every remnant legacy EAS box obsolete and
unable to trigger a false EAN. For those amatuers who operate EAS on their
systems, it would still be usable for their purposes, including relaying
the EAN since the authentical would an overlay.

I would not be in favor of modifying the call sign field. We use the
licensee's name as we share one box across multiple stations.  Unlike most
other messages sent which have multiple location codes, the EAN will
contain only one location code.  As such it will be a short set. Adding a
subset code field to the EAN product identifier line (PIL) would not be
difficult.  Especially if added at either the very end of the string or
just after the location code. By doing this, the main standard remains
unchanged and all other products and equipment stand operable.

I do agree that what ever is done should be accomplished in a single and
unified process.

MM

On Thu, October 30, 2014 9:46 pm, David Turnmire wrote:
>
> 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