Subject: [Tm-rid] UAS Provisioning

From: "Wiethuechter, Adam" <[email-masked]>
Date: Tue, 7 Jan 2020 17:38:31 -0500

Hello all,

Happy New Decade! I hope everything is going well wherever you are at the
start of this new year. I'd like to start some discussion here about
provisioning of UAS under TM-RID with HIP; an area we have yet to discuss
and I would like to bring it up.

For a TL;DR I am looking at the various ways provisioning a UAS under HIP
would work, what technologies would be needed, how to make the process easy
for end users, and the scope of it in the WG. All comments are appreciated
in this area.

First some background for my reasoning in this email. In many cases the UAS
may not have the required ability to generate keypairs in a timely manner -
this is increasingly less likely as general purpose processors are
included, however it could still be an issue in some cases. A UAS may also
not have the connectivity required to register to the Registry the Operator
wishes without external assistance.

This all depends on the class of UAS we are talking about. For example a
special built UAS for emergency services would have enough power and
connectivity during provisioning. Other devices, like consumer grade UAS
(think a DJI drone) may not have the ability to perform what is needed. In
some cases the Remote ID functionality will be added on later with extra
hardware/payload.

I personally see three classes: specialized, consumer, legacy/DYI.
Specialized class refers to UAS that are custom built (think military or
delivery drones). Consumer is drones with Remote ID built into their
systems by design. Legacy/DYI is the rest of the drone population that most
likely get Remote ID added on later via "pucks" and the like. Note that a
quick look at the FAA proposed rule makes this last area a bit unclear if
it would be valid (not that it exactly matters to IETF).

With all this in mind, there are a couple different approaches I have been
considering and want some feedback on focusing initially on where the
keypairs are generated on the device which performs registration.

UAS Keypair Generation, UAS Registration:
Under its own computation power UAS generates a keypair, stores it safely
and registers the HI/HHIT to the specified Registry (how does the UAS
obtain this?) using its own LTE/Wifi connectivity.

OD Keypair Generation, UAS Registration:
In this scenario the Operator Device (OD) generates the HIP keypair. Then
using a secure mechanism (is this in scope for us?) transfers this
information to the UAS being provisioned, removing the information upon
success. The UAS would then perform registration using its own LTE/Wifi
connection.

UAS Keypair Generation, OD Registration:
Here the UAS would generate the keypair onboard. The OD would then pull the
HI/HHIT out of the UAS for it to complete registration (again is how this
is done in scope?). The User would provide any addition information (such
as choice of Registry) via the OD.

OD Keypair Generation, OD Registration:
In this final scenario the OD would generate the keypair and securely
transfer it onto the UAS (how? in scope?). Then it would use the
information to perform registration on behalf of the UAS. Upon completion
the OD would remove the information as it is no longer needed.

There is of course also the scenarios where the UAS would use the OD as a
proxy to obtain connectivity to the outside world. Would this be
acceptable? We are talking about _trust_ here, so such an action can
undermine the whole thing. Can we really trust the OD to do such things?

The provisioning wouldn't just be the passing of HI/HHIT into Registries
and DNS servers. There is also a back and forth of certificates being
created during this whole process. To what level would we need certs to be
created and where do they end up? My thinking up to now has been obviously
a certificate signed by the Registry for the UAS, but with the OD
in-between how do we handle this? Do we also generate certs for the OD and
have a multi-tiered sign? This makes the cert bloated and if this is the
cert that is sent in the Authentication Message, well we are already out of
space.

The idea also floated into my head of using HIP (and other technologies;
RDAP?) for the connections between the Registry and provisioning party; I
mean why not we have the HIP keypair right there, lets use it! This would
require HIP-enabled Registries and end devices (be it the UAS or OD). This
is something not out of reach, but is probably more of a optional thing as
some devices won't be capable of running HIP. Without HIP this would be
standard secure fair for the Internet (HTTPS/SSL, etc.). Some Registries
will have user accounts and their own security, so this is also added in to
this process.

The biggest thing of all this is that UAS operators will want this to be
painless and easy provisioning procedure. Think power on the drone, sync
your phone up to it and hit an "Accept" button for terms and conditions
after entering some basic information (the desired Registry to register to
is one such field). No extensive waiting (other than for the drone battery
to charge) and no filling out a massive complicated form. It also should be
light enough (and extensible) to encourage manufactures to include it in
their process.

This discussion will ultimately become a new draft (at least as I see it)
under the WG. So any comments and suggestions would be appreciated to form
how exactly this would flow and work.
-- 
73's,
Adam T. Wiethuechter

---

From: "Card, Stu" <[email-masked]>
Date: Thu, 9 Jan 2020 15:46:07 -0500

My first cut at the process...

registry self-generates HIr
registry registers HIr in higher layer registry and/or public blockchain
operator self-generates HIo
operator generates UA's HIa
operator uses HIo to sign HIa (thereby creating certificate Coa)
operator registers HIo (associated data, vetting, payment, etc.)
operator registers HIa (likewise, also providing Coa)
registry uses HIr to sign HIa (thereby creating certificate Cra)
registry uses HIr to sign Coa (thereby creating certificate Croa)
registry provides Cra & Croa to operator
operator retains Croa as proof of registration of specific UA
operator provisions UA w/HIa & Cra (any benefit to provisioning UA w/Coa
also?)
UA broadcasts Cra (maintaining privacy of operator while proving
registration of UA)

What about key revocation? How do we handle registry key compromise
(affecting many)?
Can Chaumian blinding be used to reduce the degree to which operators must
trust registries?

Per latest FAA info, UAS RID SP = UTM USS, so it might as well be the
registry.

On Tue, Jan 7, 2020 at 5:38 PM Wiethuechter, Adam <
[email-masked]> wrote:

> First some background for my reasoning in this email. In many cases the
> UAS may not have the required ability to generate keypairs in a timely
> manner - this is increasingly less likely as general purpose processors are
> it would be valid (not that it exactly matters to IETF)..
>
> Here the UAS would generate the keypair onboard. The OD would then pull
> the HI/HHIT out of the UAS for it to complete registration (again is how
> this is done in scope?). The User would provide any addition information
> (such as choice of Registry) via the OD.
>
> information to perform registration on behalf of the UAS.. Upon completion
> created during this whole process.. To what level would we need certs to be
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>