EAS Participants Seek Resolution to Unauthorized Use of EAS Alerts
Emergency alert system participants weighed in on potential solutions to the security and improved function of the EAS process following unauthorized use of an EAS alert during The Bobby Bones Show on AT&T U-verse this year (see 1411100038). AT&T supported use of a year field in the time stamp, and NAB backed an industrywide effort to achieve better authentication of EAS alerts. The comments came last week in docket 14-200. Replies are due Dec. 19, and comments on a public notice concerning EAS security best practices are due Dec. 30.
Sign up for a free preview to unlock the rest of this article
If your job depends on informed compliance, you need International Trade Today. Delivered every business day and available any time online, only International Trade Today helps you stay current on the increasingly complex international trade regulatory environment.
The Oct. 24 incident affected AT&T’s U-verse IPTV video service, AT&T said in comments. The U-verse IPTV EAS processed the emergency alert notifications (EAN) because they were received from an authorized source, it said. The U-Verse Video Operations Center manually issued a global abort message to terminate the October EAN. It performed flawlessly, AT&T said. A major flaw in the EAS/EAN alerts broadcast over-the-air “is that the EAS header does not include a year field in the timestamp,” it said. Including a year field in the EAS header would reduce the likelihood of false EAN/EAS alerts being processed by any EAS equipment listening to the LP-1/LP-2 stations in the various market areas, it said.
The “force-tuning” of set-top boxes is a factor, AT&T said. If an unauthorized alert passes the filtering/validating processes in place, set-top boxes will be force-tuned to the appropriate local EAS channel, it said. U-verse IPTV has employed measures, and will employ additional measures, “that reduce the impact of any force-tuning and the likelihood that such situations will occur in the future,” it said.
NAB wants the FCC to refrain from pursuing enforcement actions related to the incident, “at least with respect to broadcasters and other EAS participants who passively retransmitted that EAN in keeping with the rules,” it said. It noted potential solutions, like changing the format of EAN date and time stamps to include the year, and establishing more uniform standards and settings for EAS boxes. Despite these efforts, “improved authentication of EAS messages will persist as a critical issue until a uniform process is clarified,” it said. “The potential for mischief is substantial.” The next situation “could involve a more purposeful, malicious breach,” it said. A joint industry effort can best address the complex authentication issue in a timely manner, NAB said.
Sage Alerting Systems has equipment that stops an alert relay after two minutes of audio and automatically transmits an end of message (EOM) code for standard alerts that aren’t emergency alert notification alerts, it said. For an EAN event, there's no limit and the equipment, an encoder-decoder (endec), will continue to transmit “until an EOM is received, the user aborts the alert from the front panel, or an invalid alert sequence is detected,” it said. In the case of the October false alert, a second set of headers was played 29 seconds after the end of the first set of headers, it said. “The ENDEC assumes that the incoming alert has been damaged, and ends the alert.” An FCC Communications Security, Reliability and Interoperability Council task group recommended the alert not be terminated in the case of having an extra set of headers, Sage said. In the October case, “this would have led to an additional delay in clearing the false alert,” it said.
Monroe Electronics advised the FCC of the presence of a time setting in certain devices that would allow an EAS alert to be transmitted “regardless of the timestamp in the header of the message,” Monroe said. “This particular setting apparently allowed the unauthorized EAN of 24 October 2014 to enter the EAS relay in several markets.” At least one design of EAS encoder/decoder provides for an option to ignore the “time of transmission,” an option referred to as “fuzz” time, it said. This option's existence was the principal reason the false EAN tones from that broadcast were allowed to enter the EAS relay system, it said. The particular EAN capability has been relatively untested in a live operational environment, it said.
The call for “strict time” filters is problematic, Monroe said. It’s a feature that's provided by only one manufacturer of EAS equipment, it said. “The referenced concepts of ‘strict time’ is unique to that particular device, and is not utilized by any of the other principal manufacturers of EAS equipment.” The government’s call for EAS participants to implement the filter had the unintended consequence of distracting resources from many EAS participants and EAS manufacturers that don’t support this single-vendor feature, it said.
NCTA said it issued an advisory to members as soon as it was made aware of the unauthorized EAN transmission. Based on follow-up contact with members, “no cable system inadvertently retransmitted the unauthorized EAN” Nov. 9, 2014, it said. The difference in the way different types of EAS participants' equipment responded “related more to the equipment vendor and equipment configuration than to the type of participant,” it said. The government should explore ways to verify the source of the message through implementation of Common Alerting Protocol, it said. CAP may be an avenue for improved authentication once the technology is fully utilized at the federal and state levels, NCTA said.