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 system environment.
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 them.
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 deduced.
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 circuitry.
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 to [email protected].
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.
