[EAS] Next Generation

[Mike McCarthy]

I want to address Ed's and other's questions, keeping in mind Adrianne's
very salient perspective comment.

My interest in this is very simple: It is imperative (my) stations can not
be taken over by a rougue message no matter the source and/or intent. It's
that simple.

I don't think we need to get overly zealous on how to go about this
either. In that I agree with Adrianne. Something simple within the
existing opertating framework and which everyone who has been around since
1997 and before will remember and understand. It's been 18 years since the
EAS was first rolled out and this is the first willful incident. So we
need not get too crazy.  Just vigilent and measured.

1) I'm envisioning the verification code would be distributed (at first)
weekly with the RWT through IPAWS. If the system managers feel that
greater security through frequency is needed, then so be it. But weekly
with the RWT is my starting point for discussion with a rolling fall back
of two prior weeks.

2) The verification or repudiation trigger would be a message header field
addition with respect to the EAN and EAT only. (And maybe the compulsory
national warning product as well.) At the end of the entire EAS header,
there would be an added alpha-numeric field with a leading and ending sync
code of say "^^^".

eg.:  ^^^h=Da^^^R2 at k^^^v&dE^^^.  (^^^week1^^^week2^^^week3^^^)

The EAN and EAT codes would trigger the decoding of the string and look-up
comparision. If any of the the strings in that field matches any of the
previously circulated "Red Envelope" codes from the past three weeks, the
message is verified as authentic.

4) This would require a modification to the SAME standard codified by
rule. Such a supplimental addition would not require any other SAME
message creator to ammend or change anything they are doing today.
Complete backwards compatibility.

5) The only endec's generating such a code string would be situated at the
presidental level where the "Red Envelop" codes would be created and
entered in the equipment the Office of the President would use for their
message.

While anyone could create such an encoder and run such a message with a
verification code, they would be missing the correct code.

6) Given the planned location code will be a single code, the message
string will be rather short.  So adding a 24 digit field would not add an
apprecible amount of time to any transmission, nor exceed the capacity of
the total message length register.

7)Downstream endec's on confirming authentication would resend the entire
string with the entire authentication string automatically as part of the
triple header. No operator involvement needed. All aspects of the
authentication would be internal to the equipment.

8) I would pefer to stay with a single verified message to proceed rather
than wait on a 2nd independant souce. If there is a crisis in progress,
some part of the system may already be compromised. Requiring a Boolean
"AND" to proceed will create confusion, delay, and possibly panic. That's
the reason why we have two monitoring sources today. Get one and move on
the first confirmed message.

9) An endec receiving an EAN without the verification would be logged as
unverified, flagged/alarmed/requesting the operator review the message and
determine whether it should be acted upon or ignored.

I hope this better clarifies my concept proposal.

Cheers...

MM

On Thu, November 13, 2014 2:30 pm, Ed Czarnecki wrote:
> This would be a machine-to-machine transaction.  Most sites are
> unattended anyway.
>
> There are two concepts floating here - authenticity and non-repudiation
>
> Authenticity is about one party (say, IPAWS) interacting with another