This is the second in a series delving into specific proposals in the Federal Communications Commission further notice of proposed rulemaking (FNPRM), intended to improve the Emergency Alert System and Wireless Emergency Alerts. The commission is now taking public comments on these proposals.
Read Part 1 in this series, “Polygons and Circles: FCC Seeks to ‘Incentivize’ EAS.”
Hoping to strengthen the Emergency Alert System against cyberattacks, the FCC wants to require that broadcasters and other EAS participants reject CAP EAS messages that do not include a valid digital signature.
It noted that such signatures work by encrypting a hash or fingerprint of data with a private encryption key known only by the signer.
“The corresponding ‘public key’ — typically made publicly or semi-publicly available — can decrypt a message encrypted using the ‘private key.’ Thus, the ‘public key’ ensures that a message encrypted using the corresponding ‘private key’ is authentic (since only the entity that possesses the ‘private key’ could have produced that encrypted message).”
The FCC said the process works properly by controlling the issuing, distribution and revocation of public and private keys so that both originator and receiver have valid keys.
“Public keys are issued as ‘digital certificates,’ typically by certificate authorities that issue and manage certificates for public, private and government entities. For CAP alerts sent through IPAWS, IPAWS maintains the public keys for all alert originators including itself,” the FCC continued.
“Because IPAWS digitally signs all alerts it issues, EAS devices acquire IPAWS’s digital certificate (with the IPAWS public key) to authenticate alerts issued by IPAWS.”
But while digital signatures are already required by IPAWS, the FCC said, EAS participants are only required to reject EAS messages that include an invalid digital signature. The rules still allow EAS participants to transmit EAS messages that have no digital signature at all.
Several organizations have called on the commission to require authentication and digital signatures for every CAP message received by an EAS CAP device, not just those received from FEMA IPAWS.
They say EAS systems should incorporate end-to-end authentication including digital signatures, secure handoffs between IPAWS and carriers, and safeguards to ensure an alert received by the public matches exactly what the originator sent.
Call for comment
The FCC believes its proposal represents “a major step forward” in securing CAP EAS alerts and thinks the requirement would be “technically straightforward” because EAS equipment already must authenticate signed CAP EAS messages. But it wants public comment.
Among its questions: Do alerts that lack digital signatures pose a high risk? What kinds of harm could they cause? Are there other public safety benefits if all EAS CAP alerts were authenticated?
It wants to know how its requirement would affect alerting authorities that originate CAP EAS messages. It wants to know the extent to which state and local CAP systems other than IPAWS support digital signatures and whether its proposal would undermine their ability to send alerts.
It also wants to hear about risks, such as delaying delivery of alerts or increasing the chance that a valid alert will be rejected as invalid.
“Have those risks materialized since the commission required the rejection of CAP EAS alerts with invalid digital signatures in 2018? Have there been any notable cases in which valid alerts have been erroneously delayed or rejected?”
And what about requiring EAS participants to authenticate legacy EAS alerts, which are sent via the EAS Protocol?
The FCC noted that unlike CAP alerts, legacy EAS “is severely limited in how much data it can convey because the data that comprises the alert is converted into audio for transmission over broadcast.”
Adding data necessary for a digital signature would delay transmission. The FCC said this delay could be significant because legacy alerts may be relayed from one EAS participant to another.
“All entities sending the alert would need to create a hash of the alert using their digital signature before repackaging it for rebroadcast. In the legacy EAS ‘daisy chain’ in which EAS participants monitor one another as sources of alerts, the time it takes to authenticate an alert would likely be multiplied for each EAS participant in the chain.” How much of a problem would this be?
The FCC is also concerned about relying on the internet for checking the encryption key certificates, as well as other matters around key management.
If certificates typically are valid for one year and are constantly being renewed, what happens if internet access is lost, preventing acquisition of a current certificate needed for alert validation involving an originator or EAS participant that is relaying an alert whose certificate was updated since the version stored in the EAS device?
Also, would the National Weather Service, which originates the vast majority of EAS alerts, be able to digitally sign the alerts it issues over the air via NOAA Weather Radio?
Would adding a digitally signed hash in a legacy alert affect the operability of emergency radios that trigger from the EAS protocol header codes?
The FCC wants to know if the audio portion of an EAS message would remain susceptible to attacker manipulation and attacks even if the alert header itself had been authenticated? How much of a concern overall are weaknesses in legacy alerts?
And the FCC asks a series of questions about how its solution would be implemented technically.
For instance: Where should the digital signature be placed in relation to the header codes? Could it replace part of the attention signal? What specific protocols and standards would need to be developed or modified to add digital signatures to legacy EAS and how long would it take to develop them?
The FCC noted that technology provider Sage Alerting Systems believes that if the FCC were to require authentication for legacy EAS, every participant and alerting authority would require its own digital signature to maintain the capabilities of the current system. The FCC asks whether that’s the case.
“One approach to streamline and simplify key management could be to limit the ability to sign legacy EAS alerts to only certain entities within each state. Could this approach work?”
And could access to signing certificates be compromised? If the FCC does allow EAS to be run in software, as I proposes to do, could that create a special opportunity to introduce legacy EAS authentication at a time when costs could be lowest?
Near the end of this discussion the FCC looks farther ahead: “To what degree should we consider the potential impact of future quantum computers on any authentication requirement we impose, and should we account for that risk through post-quantum cryptography?”
Comments are due Aug. 31. You can read the FCC’s discussion about this particular topic in paragraphs 41 to 48, starting on page 25 of the FNPRM.
Read Part 3 in this series, “EAS in Software: What the FCC Wants to Know”.
[Do you receive the Radio World SmartBrief newsletter each weekday morning? We invite you to sign up here.]
