Subject: Re: [Drip] PRIV-02

From: "Stuart W. Card" <[email-masked]>
Date: Tue, 14 Jul 2020 12:08:59 -0400

(responses interspersed)
On 7/14/2020 11:02 AM, Robert Moskowitz wrote:
> (responses interspersed)
> On 7/14/20 10:13 AM, Stuart W. Card wrote:
>> Bob --
>>
>> I added Amelia (only) but think we should take discussion to the list?
> 
> Hello Amelia.  We will take this to the list.
> 
>> I just added this clause, based on our discussions.
>>
>> Transparency of safety-critical data to authorized personnel trumps
>> privacy of Operators.
>>
>> If an UA is doing Broadcast only -- which would happen in the EU unless
>> regulatory changes currently under discussion move forward, but would
>> never happen in the US (unless it is running Standard RID outside the
>> reach of wireless Internet connectivity) -- it has no way of guessing
>> whether any local Observers have any way of getting the plaintext needed
>> to contact the Pilot in an emergency.
> 
> There is no way a UA could meaningfully encrypt PII without some
> authority having the key.  Otherwise why include the encrypted content
> at all?  Just supply garbage.
> 
> Following the rules for encryption that I laid out in
> drip-operator-privacy, which I think are much better than what you have
> in PRIV-02, an authorized Observer will be able to get the PII even if
> the UA is only performing Broadcast RID.
> 
> So no guessing is needed if the rules I have outlined are followed.

"some authority" may have the key, but some local Observer might not.

To get the PII plaintext from cyphertext in Broadcast RID, that local
Observer needs to get the USS either to decrypt it or to supply the key
for its decryption. If the local Observer lacks Internet connectivity,
this can't happen (unless the key was obtained in advance, which raises
other issues, as Kenji Sugahara pointed out in one of our meetings).

>> Whereas an UAS running both is already required to confirm that the
>> Network RID is getting through to the USS (which in turn is assumed to
>> have good connectivity to the rest of the UTM system and the Internet in
>> general). So those confirmations show:
>>
>> - it is likely that a local Observer will be able to reach the USS via
>> the same wireless Internet connectivity being used by the UAS; and
>>
>> - any Observer (local or remote) w/Internet connectivity will be able to
>> pull the needed information from the USS or a NetRID-DP (if authorized).
> 
> Again I think I have covered this more thoroughly in my draft.
> 
>> Note the phrase "safety critical data". This requires interpretation by
>> AAA policy writers. I take it to mean that PII of Operators, perhaps
>> needed to do things that can occur in non-real-time, could always be
>> encrypted; but knowing how (or where) to contact the Pilot, I would
>> consider essential to an authorized local Observer in an emergency.
> 
> Agreed.  Please read sections 4.1 and 5.1 of drip-operator-privacy.

Will do. Solution approaches should not drive requirements, but I am
probably equally guilty of that kind of thinking myself in writing them.

>> On 7/14/2020 7:45 AM, Robert Moskowitz wrote:
>>
>>>> DRIP MUST NOT encrypt safety critical data to be
>>>> transmitted over Broadcast RID unless also concurrently
>>>> sending that data via Network RID and obtaining frequent
>>>> confirmations of receipt.
>>>
>>> Where does this text come from?
>>> I have serious operational issues with it.

-- 
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 14 Jul 2020 12:45:44 -0400

> other issues, as Kenji Sugahara pointed out in one of our meetings).

The USS for the UAS has the key, initially.

Any Observer will have to inquire of the USS to either get the PII or 
the key (based on authorization).

This is true even if the UAS is doing both Network and Broadcast RID or 
only Broadcast.  Somehow the USS MUST have the key, or nothing other 
than the UAS can decrypt to get the PII, so why bother including it at 
all in the messages?  Circular problem/argument.

There are always a bunch of edge cases.  The Observer is in a hole and 
has no Internet connectivity, but has a good sky view for Broadcast 
RID.  This does not 'fly'.

If there are reasonable rules on when PII can be protected (this is what 
should be in req for PRIV-02), then Observers also have to follow the rules.

> probably equally guilty of that kind of thinking myself in writing them.

After I looked into what the PII was and thought about protecting it, 
then I did requirements on when protection should be permitted. So the 
requirement DID drive the solution; just not what was high-level 
presented in PRIV-02.

This IS a tough one as it is heavily laced with policy and politics...

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: "Stuart W. Card" <[email-masked]>
Date: Tue, 14 Jul 2020 13:26:16 -0400

On 7/14/2020 12:45 PM, Robert Moskowitz wrote:
> ...

Already understood.

> the key (based on authorization).

Already understood.

> only Broadcast.

Already understood.

> Somehow the USS MUST have the key, or nothing other

Already understood.

> There are always a bunch of edge cases.

Already understood.

> The Observer is in a hole and has no Internet connectivity,
> but has a good sky view for Broadcast RID.  This does not 'fly'.

So this reduces to whether that is an "edge case". If an UAS is at the
moment running Broadcast RID _only_, I don't think it is.

There are only 2 reasons AFAIK to run Broadcast RID only:

(1) It is all the rules require of your current operation (possible in
EU under current rules, not possible in US if FAA NPRM rules are
finalized more or less as written).

(2) Your UAS currently lacks Internet connectivity so cannot also do
Network RID (the norm in wide rural areas in the US, including much of
the areas of large military bases and national forests).

In case (2) above, the UAS lacking Internet connectivity is a strong
predictor of the local Observer also lacking it. Yet that Observer must
be able to contact (or possibly arrest) the Pilot, so needs to be able
to get the necessary information from Broadcast RID.

I added the clause so that local Observers authorized to get such info
can get it with high confidence:

(a) via current Internet connectivity from a Network RID DP;

(b) via current Internet connectivity from the UAS Operator's USS, the
USS having decrypted cyphertext sent to it by the local Observer, who
captured it from Broadcast RID;

(c) with the help of current Internet connectivity, by locally
decrypting cyphertext captured from Broadcast RID, using a key obtained
dynamically by requesting it from the UAS Operator's USS, which was
identified from cleartext found in the Broadcast RID (i.e. the HDA in
the HHIT used as the UAS ID);

(d) with the help of prior Internet connectivity, by locally decrypting
cyphertext captured from Broadcast RID, using a key obtained _a priori_
by requesting it from the UAS Operator's USS (directly or via the UTM
system), despite having no _a priori_ knowledge of what UAS might be
operating in the area and to which USS they might be subscribed; or

(e) without Internet connectivity, from cleartext in the Broadcast RID.

I don't think (d) is reasonable: it requires Observers _a priori_
downloading large numbers of individual UAS keys or small numbers of
shared keys (ugh!).

IMO the cleanest thing is to demand that safety critical information,
when transmitted via Broadcast RID, be sent as cleartext; unless the
sender has high confidence that a local Observer (if authorized) will be
able to access it (fetch it or fetch a key to decrypt it, either way
needing current Internet connectivity).

That high confidence could come from receiving Network RID ACKs, which
show that information both:

- is safely in a place from which it can be fetched (Network RID DP/SP)
in response to authorized queries; and

- can be decrypted locally by an authorized Observer, using a key
_dynamically_ fetched via the Internet, which connectivity the Observer
is presumed to have in that very localized Broadcast RID coverage area
if the UAS in that same area is able to get Network RID ACKs.

This is the fallback previously in the same -reqs section, moved from
explanatory text into the numbered requirement to which it applies,
rewritten not as a fallback mode, but as a limitation on the privacy
requirement, to also require the necessary transparency of safety
critical data only.

> should be in req for PRIV-02), then Observers also have to follow the rules.
Agreed. The question is whether the rules the Observers are required to
follow involve broad _a priori_ key dissemination. If everyone who can
credibly present themselves as e.g. volunteer firemen can get keys
enabling them to decrypt Broadcast PII from any UAS conceivably
operating anywhere near them, there is little point to encryption.

I have to knock off for a few hours (never did find time to take that
post draft cutoff walk in the woods, must go to the RF lab now).