Take EAS Back to the Drawing Board
EAS is useless.
There, I’ve said it. By regularly conducting live testing of a
one-way, non-authenticated messaging system we have managed to desensitize the
public to the warnings while simultaneously exposing them to the possibility of
mass panic, should those with evil intent manage to capture the system. As we
learned from the recent Zombie Invasion alert, it isn’t very hard.
The consensus is that the Zombie scam was the result of
unauthorized access to the Internet-facing port of an EAS encoder. Initial
reports seem to point to a particular brand of EAS device, though I suspect
many are vulnerable in various ways. In any event, we broadcasters are unlikely
to know, since the code that runs on these small embedded systems we call EAS
is mostly proprietary. Thus it does not experience the vetting that accompanies
public release of source code for encryption and authentication systems like
the Advanced Encryption Standard (AES). The functions and methods employed by
AES and other public domain security code modules are detailed extensively,
inviting members of the public to crack them. This is how you build a secure
But the biggest weakness of EAS is
the over-the-air forward delivery scheme. Thousands of old EAS encoders went to
recycling in the recent conversion to a CAP-based alerting system. Any of these
along with, for example, an old FM exciter would allow a prankster to drive up
to a radio station studio and initiate an EAS, simply by spoofing the broadcast
frequency of the local LP1 if it were an FM. The same general scheme could be
applied to an AM LP1, but might require a bit more effort. Now that an attack
has been demonstrated, others are certain to follow. Broadcasters should expect
The fundamental flaw in EAS security is the
complete lack of authentication. Because the over-the-air relay system is one
way, there is very little opportunity to secure it meaningfully. Broadcasters
operate in a receive-it, trust-it, forward-it environment that invites mischief
or worse. Yes, perhaps pre-shared passwords or authentication keys could be
introduced, hashing the messages. Under such a scheme, downstream relay
stations would decrypt the received EAS before retransmitting. Bad hash keys
would result in gibberish and no EAS forwarding. But the format of the messages
is uniform and so, eventually, with enough captured messages the key can be
Dynamically-generated keys are a possibility,
like those used for authentication fobs. Every minute an algorithm runs that
generates a new key. The theory is that the successive keys are random enough
so that a hacker cannot deduce the algorithm and replicate the key generating
process. Adding this to existing EAS would be a dramatic improvement but may be
impractical at this point.
The answer — you had to know
I’d offer one — is to abandon over-the-air relay transmission altogether.
Put the EAS device in the air chain, sure, but conduct tests
across the Internet. Use well-established handshake authentication and key
generation schemes that now serve e-commerce. EAS devices would poll the EAS
encoders of upstream stations or perhaps markets would establish cloud-based
EAS coordination. Then testing could occur every minute, much as CAP does now.
Finally, using the Internet-based encrypted back channel,
replacement keys for the over-the-air detection process could be distributed
and changed regularly. And like the fob-based authentication schemes, key
expirations could be allowed to overlap, a safety net for a station that misses
a key replacement cycle.
Finally, to test the now-unused
over-the-air alert distribution, periodically the payload that EAS relaying
stations would pull from their upstream EAS provider would include an audio
file containing an EAS test alert. In the local EAS box, this would be
converted to analog and applied to the input terminals of over-the-air detection
If a broadcaster wished, perhaps when new EAS
gear is commissioned, any of these testing protocols could be directed to
generate an over-the-air test. But once proven reliable, these should be
silenced. Thereafter, failures of any of the functions would be detected by
software with appropriate alerts sent to the responsible party. Discovery of a
problem would take, at most, a few minutes instead of as much as a month.
So I suggest this all go back to the drawing board.
Maybe having dedicated devices isn’t the way. Maybe automation
systems should incorporate these functions. Maybe PC software is the answer.
Whatever we do, the present system has demonstrated itself
insecure for obvious and predictable reasons. With the exception of CAP, the
present system should probably be scrapped. And existing EAS devices with
Internet access should only be accessible via HTTPS using well-known and
broadly disseminated socket code.
Comment on this or any story. Post below or email a letter to the editor
Frank McCoy is in what he calls his “retirement job” as chief engineer of
two Chicago stations owned by Salem. Previously he was EVP, then CEO of
American Media Services LLC, where he and his team discovered and executed
station move-ins with aggregate upside in excess of $100 million. Prior to that
he was VP of engineering for Capstar, the largest (by number of stations)
embedded unit in Clear Channel’s radio portfolio.