[EAS] Next Generation

[Harold Price]

While you are designing ...

Here are some items you should consider:

Preventing long delay replay problems (Bobby Bones)- just add a year 
to the protocol, define a start and end validity window in the spec, 
and problem solved.

Preventing intentional hacks - any code word or hash that is 
distributed on a public system, or via FSK (also public) is not 
giving you any real protection, as anyone can easily learn the code 
word of the day/week/month.

Requiring Internet access - Remember, FSK relayed EAN is used before 
national emergency, during the emergency, and after the 
emergency.  Maybe days after.  And on those days, the Internet may be 
down.  Any pre-delivered key system with a short timeout runs the 
risk of not being able to use the system when you need it.  Any 
system that requires real time access to the Internet to validate a 
pending message is likewise not going to work on the day.

Any type of public/private key signing or encryption scheme needs to 
have a significant number of bits in the key - you can't be secure 
with a 4 byte key - especially if your protection algorithm is 
published in the federal register.

Any system requiring a person in the loop at the radio/tv/cable end 
to play out an EAN is not viable.  Remember, the reason we have EAS 
vs. EBS is so that stations can run automated and unattended.

Any system requiring the EAN to be received via two different paths 
is making the delivery problem much harder.

You can't modify the legacy EAN as it relays through the system and 
still be able to detect duplicates - and you want to detect duplicates.

These problems aren't unsolvable, but take them into account as you 
propose new systems.

Harold