►
From YouTube: Kubernetes WG IoT Edge 20210224
Description
February 24, 2021 meeting of the Kubernetes IoT Edge Working Group. Presentation on secure device onboarding by Geoff Cooper/Bryan Rodriguez followed by group discussion.
A
So
welcome
to
the
february
24th
meeting
of
the
kubernetes
iot
edge
working
group
at
today's
meeting.
We've
currently
got
two
items
on
the
agenda.
As
usual,
members
are
welcome
to
submit
items
for
that
agenda.
If
you
put
it
on
right
now,
as
the
meeting
started,
I
can't
guarantee
we'll
have
time
to
get
to
it,
but
we'll
we'll
try
if
we
do
have
time
and
if
not,
we
can
roll
anything
that
you
want
to
talk
about,
discuss
or
present
into
the
next
meeting.
A
B
Cool
yeah
thanks
so
yeah,
so
the
cncf
is
trying
to
help
kind
of
provide
like
research
into
like
different
areas
where
cloud
native
computing
is
going
and
one
of
them
is
being
edge,
computing
and
so
kind
of
in
lead
up
to
the
kubernetes
on
edge
day.
We
want
to
do
a
survey
about
the
usage
of
kubernetes
like
for
edge
computing
and
so
we're
putting
together
a
survey
that
we're
going
to
like
collect
responses
on
and
kind
of
like
produce
it.
A
I've
got
one
idea
in
that,
and
we've
done
this
before,
but
it'll
be
interesting
to
see
how
things
trend
and
we
didn't
do
it
formally.
We
just
asked
for
show
of
hands
back
in
the
days
when
there
were
physical
conferences,
but
getting
people
to
cat
self-categorize
based
on
their
use
case,
I
think,
is
useful
to
know.
A
The
platform's
another
way
to
approach
platform
for
the
users
would
even
be
what
I
call
thick
versus
thin.
You
know:
are
they
running
on
tiny
little
microcontrollers?
That
really
have
are
so
small.
They
have
no
hope
of
becoming
kubernetes
cluster
nodes,
yet
they
want
to
use
the
kubernetes
control
plane
to
manage
them,
or
is
there
edge
use
case
such
that
they
have
enough
resource
out
there
at
the
edge
that
they
can
run
a
full,
regular
kubernetes
cluster.
B
A
C
Yeah,
and
are
they
wanting
to
manage
multiple,
I'm
gonna
put
the
word
micro
cluster
around
it
is
it
you
know,
is
the
control
plane
at
it
on
on-prem
in
multiple
locations,
think
of
like
industrial
kitchens
or
like
a
venue,
so
they
might
want
to
have
control
planes
or
a
robot
that
has
a
control
button
on
it.
Am
I
wrap
managing
you
know
a
thousand
robots
with
makes
sense.
C
A
C
A
Perhaps
if
you
just
put
a
google
spreadsheet
or
doc
out
there
that
you
grant
added
authority
to,
if
you
don't
think,
that'll
get
out
of
hand,
that'd
be
a
way
for
people
who
maybe
have
an
idea
come
to
them
tomorrow
to
go,
throw
it
in
there
or
you
can
use
our
slack
channel.
I
guess
just
okay,
we'll
put
the
question
there
and
get
invite.
A
There's
a
blanket
email
for
the
group
as
a
whole,
so
you
could
give
edit
permission
to
the
group
and
then
you
know,
I
don't
think
you
want
it
to
be
the
wild
west.
On
the
kubernetes
project,
we've
had
people
who
are
so
bored
that
for
entertainment,
they
can't
think
of
anything
better
to
do
than
to
troll
new
meanings
and
shared
documents.
So
putting
it
out
there
completely
wide
open
might
be
a
mistake,
but.
E
Yeah
another
thing
for
for
for
the
initial
set
of
questions
I
I
think,
would
be
good
to
have
like
a
survey
of
what
additional
cncf
ecosystem
projects
are
being
used
for
the
edge
on
top
of
the
kubernetes.
So
is
it
you
know,
search
mesh,
okay
native,
you
know
monitoring
stuff
water.
People
are
mostly
used
for
app
development.
A
Yeah
absolutely
finally,
the
one
to
ask-
I
don't
see
her
here
at
the
meeting,
but
one
of
the
leads
of
this
group
is
in
the
of
microsoft
and
she's
done
these
surveys
in
the
past.
So
she
might,
I
think,
she'd
be
a
good
resource
for
asking,
because
I
think
she
might
have
some
it's
cindy
xing
on
the
kubernetes
slack,
but
I
I
think
that
she'd
have
some
valuable.
B
A
B
This
is
great
yeah.
I
really
appreciate
it
so
I'll
come
back
to
you
with
kind
of
like
a
proposed
document,
and
then
I
guess
we'll
kind
of
go
from
there
and
then
yeah.
I'm
super
excited
to
see
the
results
and
then
I
think
it'll
really
like
help
build
the
momentum
going
into
the
kubernetes
on
edge
day
and
a
lot
more
people
excited
about
this.
A
Just
so
you
know
the
the
program
committee
for
that
kubernetes
on
edge
day
is
still
forming
the
actual
agenda.
We
don't
have
it
yet
because
we're
still
evaluating
cfps,
but
I've
proposed
to
have
kind
of
one
of
these
birds
of
a
feather
things
at
end
of
day,
where
we
split
into
small
tables,
maybe
based
on
people
with
common
use
cases.
So
I
don't
know
if
we
can
use
that
to
categorize
or
the
survey
defeated.
B
C
A
A
A
C
D
Absolutely,
let's
have
it's
a
smaller
group:
let's
have
a
conversation
so
feel
free
I've
got
enough
slides.
I
can
once
when
somebody
tells
me
to
start
talking.
I
can
talk
for
the
rest
of
the
hour
on
this,
so
here's
a
here's,
a
presentation
on
secure
device
on
board
and
I'm
not
going
to
show
that
presentation,
because
we
have
something
else
that
that
is
actually
replacing
secure
device
onboard,
and
I
think
that
we're
playing
around
with
my
screen
here.
D
Let's
see
if
I
can
still
see
what
I
need
to
see
yeah,
because
I've
got
the
zoom
thing
in
the
way,
so
so
intel
felt
that
this
was
onboarding
was
something
that
needed
to
be
shared
to
be
effective.
For
example,
you
know
we
have
large
customers
who
will
come
to
us
and
say
yes,
we
onboard
intel
devices,
but
we
also
on
board
arm
and
other
types
of
devices,
so
we're
not
interested
in
a
solution
that
is
for
intel
devices.
D
Of
course
we
were
trying
to
do
an
open
device,
but
we
need
a
third
party
to
do
that.
So
what
we
did
is
we
got
together
with
this,
the
fido
alliance.
Now
you
guys
might
not
be
familiar
with
them.
Fido
is
an
organization
that
was
set
up
to
remove
passwords
from
the
world
and
they
they
do
these
authenticators
that's
their
their
main
effort
to
date
and
about
a
year
and
a
bit
ago
they
decided
that
they
would
do.
Let's
see,
there's
a
way
to
make
this
thing.
D
D
So
we
started
off
by
putting
together
use
cases,
we
turned
the
use
cases
into
requirements.
We
got
together
in
december
of
2019
to
say:
well,
how
are
we
going
to
get
there
and
we
said:
look
we
don't
have
a
lot
of
time
to
to
to
address
this
in
the
market.
I'm
going
to
have
one
of
these
things
where
just
a
minute.
Let's
see
if
I
can
turn
off
the
automated
slideshow
thing,
use
timings
off:
okay,.
D
So
we
we
don't
have
a
lot
of
time
in
the
market
to
address
this
problem
before
all
of
the
various
ad
hoc
solutions
become
the
de
facto
solutions.
So
what
are
we
going
to
do
about
it?
And
the
idea
was
well:
let's
take
an
existing
technology
that
meets
many
of
the
requirements,
let's
add
gab
technologies
and
then
think
about
other
modifications
that
engineers
like
to
do
because
they
because
they're
there
right
that
we're
engineers
and
we
like
to
to
make
things
slightly
better.
D
So
so
that's
that's
the
way
to
think
about
what
the
context
of
this
is.
There
were
a
few
things
in
that
fido
had
in
mind
that
were
a
little
bit
different
from
sdo
and
and
some
of
those
have
turned
out,
and
some
of
those
have
not
actually
made
it
to
the
spec.
Yet
the
other
thing
I'll
point
out
is
that
we
have
a
group
of
editors
on
the
spec
here
that
are
coming
from
chip
companies
that
compete
viciously
with
each
other
and
cloud
companies
that
compete
viciously
with
each
other.
D
D
So
what
is
the
problem?
Well,
the
problem
is
that
we
want
to
have
device
provisioning.
That
means
we
want
to
have
onboarding
and
activation.
We
want
the
devices
to
become
up
and
running
in
service,
generating
data,
moving
device,
moving
actuators,
putting
sensor
data
up,
and
we
want
that
all
to
be
fast,
scalable
and
secure,
and
the
way
to
think
about
that
is,
you
know
if
you
were
at
the
the
frankfurt
airport
in
the
days
when
we
went
to
airports
and
you
and
you
wanted
to
replace
all
of
the
light
bulbs
on
the
runways.
D
There
are
10
000
of
them
with
iot
light
bulbs,
and
you
thought
about
doing
that
as
a
manual
process
and
we
we
actually
got
some
metrics
from
the
companies.
Two
people
20
minutes,
you'd
be
there
for
a
long
time.
In
fact,
you'd
be
there
for
long
enough
that
you
might
hit
the
mtbf
of
the
light
bulb,
so
you
might
be
painting
the
eiffel
tower.
You
might
never
finish
right
so
to
actually
do
a
project
large
projects
with
with
iot.
D
You
have
to
actually
to
get
the
velocity
of
the
iot.
You
have
to
be
able
to
have
the
devices
come
on
and
and
onboard
automatically,
and
how
are
we
going
to
do
that?
Well,
let's
define
what
it's
supposed
to
look
like,
so
we
want
to
drop
ship
the
device
to
the
place
where
we're
going
to
install
it,
and
then
we
want
to
have
somebody
connect
it
to
the
wall,
attach
it
to
the
wall.
D
We
want
to
have
it
attached
to
the
network,
there's
a
whole
business
about
network
versus
application
onboarding,
and
I
can
get
into
that.
If
you
guys
want
to
talk
about
it,
but
it's
a
separate
issue.
Let's
say
we
have
it
powered
up
and
connect
to
a
network,
and
then
we
press
the
power
button.
So
the
button
we
press
is,
let's
mentions
that
one
press
the
power
button
and
we
don't
press
any
other
buttons
and
then
we
walk
away
and
then
the
device
is
up
and
sometime
later
the
device
is
running.
D
Maybe
a
minute
could
be
longer
if
we're
installing
an
os,
for
example,
and
the
device
is
now
running
on
the
cloud
that
we
chose.
So
maybe
there's
an
assumption
in
there
about
the
fact
that
we
chose
the
cloud.
The
person
wasn't,
the
the
target
device
chooses
the
cloud
and
it's
up
and
there's
it's
secure,
because
if
we're
going
to
do
something
like
this,
it
has
to
be
secure
enough
to
make
it
work,
and
we
can
choose
any
hardware
that
we
want.
D
We
can't
it
doesn't
have
to
be
any
specific
one
and
the
device
is
now
running,
not
at
the
point
where
a
cloud
can
minimally
talk
to
it
with
credentials,
but
that
the
point
at
which
the
data
is
flowing
and
the
device
is
in
service.
Okay.
So
we
want
to
go
from
drop
ship
open.
The
box
device
and
service
with
one
press,
okay
and-
and
that's
that's
the
term
that
people
have
been
talking
about
zero
touch
onboarding.
D
D
So
if
we
look
at
what
other
industries
have
done,
they
said
no,
that's
not
the
way
we
want
to
do
it.
We
want
to
do
a
built
plan,
so
we
want
to
build
one
kind
of
sku
for
every
kind
of
device
and
we
want
to
send
that
through
the
supply
chain.
So
what
is
the
requirement
now?
We
have
to
say
that
we're
going
to
be
able
to
bind
the
device
at
the
end
of
the
supply
chain.
D
So
when
the
device
first
connects
to
its
customer,
it's
going
to
have
to
figure
out
what
it
needs
to
change
inside
of
itself
to
match
the
customer
ecosystem,
and
this
is
the
term
that
we
call
late
binding,
and
I
think
this
is
probably
the
most
important
thing
that
is
in
the
sdo
fdo
chain.
That
is
not
in
some
of
the
other
automatic
onboarding
mechanisms.
D
So
so,
let's
think
about
what
you
would
have
to
do
to
make
light
binding
work.
Okay,
so
the
manufacturer
credentials.
Well,
if
the
manufacturer
credentials
are
used
for
onboarding,
then
you've
got
the
others
to
see
ecosystem.
That's
not
working,
so
you've
got
to
have
manufacturer
credentials
used
for
onboarding
and
then
the
real
credentials
that
you're
going
to
use
when
an
everyday
use
are
going
to
come
during
the
onboarding
late
blind
late
bound
when
you
warehouse
the
device,
you
might
not
know
exactly
where
it's
going
to
go.
D
So
if
you
have
even
for
industrial
devices,
if
you
have
a
huge
palette
of
devices
coming
in
that's
being
stored
somewhere
in
a
warehouse
in
denver,
you
don't
know
exactly
whether
that
whole
palette
is
going
to
one
place
or
you're.
Gonna
have
to
break
the
palette,
send
half
of
it
to
boston
and
half
of
it
to
washington.
Two
different
customers
use
different
keys
use
different
ecosystems,
so
you
have
to
have
some
kind
of
mechanism
for
flexibility
in
the
supply
chain.
D
Obviously,
if
you
don't
have
that
needs
flexibility
in
the
supply
chain,
you
shouldn't
have
to
pay
for
it,
but
you
have
to
have
this
capability
to
do
that.
You
have.
You
need
lots
of
different
kinds
of
credentials
because
you
don't
know.
First
of
all,
the
obvious
thing,
if
I'm
going
to
say
I
have
certificate,
trust
and
everybody's
going
to
do
tls,
which
is
not
that
far
off.
D
I
don't
know
what
the
ca
is,
so
I
have
to
at
least
be
able
to
bind
to
trust
at
the
end
of
the
supply
chain.
I
have
to
do
a
late,
binding
of
trust,
but
actually
devices
usually
have
multiple
routes.
They
have
multiple
kinds
of
keys
and
they
have
multiple
kinds
of
credentials.
So
you'll
often
see
tokens
and
you'll,
see,
say
one
kind
of
route
of
trust
for
update
for
software
update.
D
So,
for
example,
you
know,
if
you
think
about
linux,
world
right,
there's
a
there's,
a
whole
operating
system
based
route
of
trust,
and
then
there
might
be
a
vendor
route
of
trust
for
the
for
the
actual
iot
solution.
And
then
you
might
have
the
the
device
management
service,
which
has
yet
a
totally
different
route
of
trust.
D
So
there's
you're
going
to
have
to
have
a
lot
of
different
kinds
of
credentials
and
that's
also
going
to
have
to
be
lake
bound
what
those
credentials
are
okay
and
then,
when
you
get
down
to
network
topology,
you
can't
make
any
assumptions.
You
can't
say
this
is
going
to
be
an
internet
service.
I'm
going
to
pick
it
up,
I'm
going
to
attach
it
to
my
internet
service.
D
Logically
pick
it
up,
and
then
I'm
going
to
transfer
it
over
to
here.
Your
internet
service
people
have
done
that
and
it
works
in
situations
where
you're
on
the
internet.
But
what?
If
you're?
In
a
closed
network,
an
iot
could
it
could
be
in
a
closed
network?
What,
if
you're,
in
an
intranet
kind
of
a
business
environment?
So
you
have
to
support
different
network
technology,
network
technologies
or
network
topologies
that
you
might
find
in
the
iot
world.
D
So
these
two
sides
we
developed
something
called
an
ownership
voucher
and
because
this
is
a
more
technical
audience
I'll
give
you
a
little
bit
more
information,
see
I've
been
putting
dangerous
curves
up
in
the
corner
and,
and
then
these
two
here
is
what
we
call
service
info
and
service
info
is
saying
that
once
you've
authenticated
you're
not
finished.
Yet
you
still
have
more
work
to
do
in
your
onboarding
protocol
in
order
to
get
completely
up
okay.
D
So
the
ownership
voucher
is
a
data
structure
that
we
created
for
authenticating
from
the
manufacturer
to
the
owner
of
the
device,
and
so
we
use
this
term
owner
being
the
the
guy
who's
going
to
onboard
the
device,
and
this
is
the
owner's
actually
up
in
the
cloud
or
the
owner's.
The
guy
who's
who's
actually
controlling
the
device,
but
not
necessarily
the
guy
who's
got
the
device
in
his
hand,
and
then
we've
got
the
device
credentials,
so
there's
owner
credentials,
device
credentials,
manufacturing
credentials
and
what
we
do
is
in
the
ownership
voucher.
D
And
then
the
ownership
voucher
is
mated
with
the
device
credentials
using
the
fdo
protocols
so
that
the
device
can
use
the
ownership
voucher
to
verify
that
this
guy
who's
got
the
ownership.
Voucher
is
actually
proving
that
he's
the
guy
at
the
end
of
the
chain.
Okay
and
and-
and
so
that's
the
way.
We
say
that
the
device
says
yes,
I've
gotten
connected
to
the
correct
guy.
A
D
What
we
did
is
we
put
some
verification
mechanisms
in
it.
You'll
see
here,
the
private
keys
are
actually
at
each
entity
and
we
set
it
up
in
such
a
way
that
that
the
ownership
voucher
can
be
transmitted
actually
through
anything
as
simple
as
email,
and
so
it's
a
self-securing
textual
document
that
we
send
through
the
supply
chain.
Now,
if
you
had
a
back-end
cloud
that
allowed
you
to
transmit
credentials,
supply
supplier
documents
ordering
systems
that
kind
of
thing,
this
would
go
with
it,
it
would
fit
into
the
same
place.
D
D
Are
some
assumptions
in
there
and-
and
there
are
some
assumptions
of
what
you're
you're
getting
in
supply
chain,
so
you
don't
have
a
free
hand
to
say
any.
I
can
trust
any
supplier.
You
have
to
have
some
trust
in
the
supply
chain
and
then
the
ownership
voucher
will
be
based
on
your
trust
in
the
supply
chain.
A
And
then,
at
the
end
of
this
chain,
that's
building
you
know.
By
end
I
mean
the
beginning
is
manufacturer.
The
middle
is
supply
chain.
The
end
is
the
actual
owner.
The
owner
gets
the
final
bite
at
the
apple,
in
other
words,
the
manufacturer
has
no
mechanism
to
say
I'm
not
willing
to
allow
these.
These
five
owners
right.
B
D
A
D
A
D
That's
a
bit
of
a
chicken
and
egg.
We,
you
normally
think
that
of
it
going
through,
maybe
with
the
with
the
shipping
papers
on
the
device
more
likely,
and
there
is,
of
course,
one
per
device
and
that's
sort
of
the
way
these
onboarding
type
credentials
tend
to
work
yeah
and
the
device
certificate
is
actually
shipped
inside
of
the
ownership
voucher.
D
So
that
gives
you
information
for
how
the
owner
will
verify
the
device
the
device
can
use
the
the
the
chain
of
ownership
in
the
device
credentials
to
get
in
the
ownership
voucher
to
verify
the
owner.
So
that's
that's
sort
of
the
basic
idea
and
that's
this
is
one
of
the
key
mechanisms
for
doing
light,
binding.
D
D
D
When
the
device
comes
up,
it's
got
two
problems
to
figure
out.
It's
got
to
figure
out
how
it's
going
to
find
the
person
who
owns
it
right
now,
and
it's
got
to
figure
out
how
it's
going
to
authenticate
with
that
person.
So
the
authentication
I
gave
you
a
hint
is
going
to
be
based
on
the
ownership,
voucher
and
the
device
key.
The
way
it
finds
it
is
we
created
this
server
called
a
rendezvous
service.
D
The
device
has
instructions
to
get
to
it,
built
in
its
device
credentials.
The
ownership
voucher
has
the
same
instructions,
and
so
they
they,
the
ownership
voucher,
is
registered
into
the
rendezvous
service
and
to
identify
that
this
is
the
target
cloud.
So
what's
happening
is
there's
a
there's.
A
guide
in
there
saying
this
is
the
good
that
identifies
this
device.
D
It's
not
a
permanent
guide,
it's
it's
just
for
the
purpose
of
onboarding
it.
It
says:
here's
a
good
and
an
ip
address.
This
is
where
you
can
find
the
guy
who
claims
to
have
ownership
he'll
go
over
to
when
the
device
comes
up,
it'll,
go
over
query,
the
rendezvous
service
it'll
get
the
ip
address
and
then
it'll
be
able
to
open
the
actual
connection
where
it
does
the
provisioning
and
all
of
the
the
authentication.
D
Any
authentication
steps
are
all
repeated,
so
the
device
and
the
the
target
cloud
now
authenticate
each
other
and
the
device
is
using.
It's
a
certificate,
a
signature,
the
go.
The
goal
is
it's
a
signature
based
on
root
of
trust,
with
the
device
certificate
sitting
in
the
ownership
voucher,
it
could
be
less
than
that.
You
can
sort
of
logically
say
well,
it
needs
to
be
the
onboarding
entity
needs
to
be
as
secure
as
everything
else
on
the
device
as
sort
of
a
minimum
and
we
sort
of
we
think
of
the
world.
D
Incrementally
so
we
say:
well,
you
you
would
you
want
to
be
able
to
take
an
iot
device
that
is
not
using
automatic,
onboarding
and
think
about
how
you're
going
to
make
it
do
automatic
onboarding,
and
that
should
not
require
that
you
totally
revamp
the
device.
So
you
might
have
to
start
off
with
with
the
key
not
being
a
root
of
trust,
key
being
stored
somewhere
in
the
device
that
you
think
is
as
secure
as
you
can
get
it.
D
But
the
idea
is
that
it
can
work
with
a
device
in
it
with
a
t
running
the
protocol.
It
can
do
all
the
the
most
secure
things
and
then
the
the
target
cloud
will
go.
The
device
management
system
will
go
and
authenticate
itself
using
the
ownership
voucher
and
then,
after
authentication
you'll
get
into
this
service
info
phase.
Where
you
can,
you
can
provision
the
device
and
and
that's
that's
a
whole
other
negotiation
where
the
device
management
system
can
actually
go
and
download
capsules.
D
A
A
D
So
so
that
that
sort
of
very
nicely
segues
into
the
next
in
the
next
slide,
which
is
what
can
you
do
with
it?
And
so
we're
not
saying
that
we're
doing
a
photo
mechanism?
So
we
do
have
the
ability
to
download
files.
It's
not
intended
to
download
large
files,
but
we
do
have
the
ability
to
download
data
into
the
device.
But
if
you
had
a
photo
mechanism,
we
could
set
up
the
photo
mechanism
and
let
it
run
so.
Okay.
D
D
You
can
invoke
that
by
downloading
an
instruction,
a
script
over
the
the
device
manager
to
the
over
the
the
fdo
service
info
channel,
and
you
can
have
the
device
do
that
while
you're
running
your
onboard
and
and
that's
the
and
the
question,
is
you
know,
do
you
want
to
do
that?
Well,
what
you
would
do
is
probably
that
the
function
of
doing
the
full
upgrade
is
the
one
that
you
needed.
You.
D
You
probably
needed
to
do
that
in
your
device
management
service
anyway,
but
you
might
have
certain
specific
modules
that
have
to
be
up
to
date.
So
you
probably
would
update
those
modules
and
say
look
for
example.
I
want
to
make
sure
my
my
my
firewall
is
running
properly.
I
want
to
make
sure
if
there's
any
you
know
significant
vulnerabilities
that
have
crept
in,
that
those
modules
get
updated,
but
I'm
not
going
to
do
the
full
system
upgrade
because
I
have
that
capability
in
my
device
manager
anyway,
and
so
I'll.
D
D
You
can
download
scripts
to
invoke
an
agent
if
you
wanted
to.
You
could
download
an
agent,
probably
a
small
agent,
unless
you
used
an
existing,
say,
rpm
install
you
can
download
crypto
and
you
can
download
any
kinds
of
credentials
you
want
and
as
many
as
you
want,
you
can
arrange
for
keys
to
be
sitting
in,
say
a
tpm
such
that
only
the
tpm
has
has
the
only
copy
of
the
private
key
and
associate
them
with
certificate.
D
You
can
and
you
can
send
data
files
that
that
are
needed.
For
example,
you
know
ip
addresses
and
certificates
and
things
that
are
needed
for
the
device
in
operations,
and
then
you
can
also
use
other
facilities.
So
if
you
have
a
t,
you
may
need
to
interact
with
the
t
to
go
and
set
it
up,
set
up
credentials
in
the
t
you
you,
you
may
actually
want
to
set
up
other
iot
this
device
to
be
the
the
base
for
other
iot
devices.
D
You
can
introduce
you
to
my
wife
here
and
you
you,
you
may
want
to
have
this
guy,
be
the
the
device
manager
for
other
iot
devices
that
are
in
your
ecosystem
and
you
could
set
up
fdo
as
a
server
on
this
device.
If
you
wanted
to
do
that,
and
you
could
send
ownership
vouchers
down
into
it,
you
could
do
set
up
software
updates
and
you
can
set
up
agents
so
it
there
there's
a
lot
of
latitude
about
what
you
can
set
up.
D
A
So
this
device
manager,
then
could
be,
if
you
choose
to
governed
by
the
actual
physical
device
owner,
then
so
that
you
know
one
of
the
things
that
some
classes
of
users
have
concerns
with.
Here,
I'm
going
to
deploy
some
number
of
these
devices,
but
I
don't
even
want
my
supplier,
the
manufacturer,
to
know
whether.
A
D
Notice,
there's
no
line
that
goes
backwards
in
this.
That
goes
back
to
the
manufacturer,
so
there's
so
we're
passing
credentials
forwards
in
the
supply
chain
and
ultimately,
we
have
credentials
that
are
on
the
device
that
were
provisioned
into
the
device
at
some
time
that
the
manufacturer
has
no
no
longer
has
any
control
over
and
we
have
device
credentials
that
arrive
in
the
tar
in
the
manager
or
the
cloud
that
again
nobody,
nobody
in
the
supply
chain
has
any
control
over
and
those
are
used
to
negotiate
trust.
D
So
so
you
can
that's
why
you
can
do
this
in
a
closed
network
right.
That's
how
it
works
to
make
it
be
possible
in
a
closed
network.
Okay,
okay,
so
it's
important
because
you
know
I
you
will
find
if
you
look
at
other
schemes,
that
there
are
things
like
automatic
oracles
where
there's
a
cloud
service
that
makes
a
decision
dynamically
and
it's
really
hard
to
see
how
that
happens
in
a
closed
network.
D
D
A
F
D
So
so
so
you
need
a
two-way
mechanism:
laura
works,
fine,
but
the
way
people
bill
laura
does
not
work
right.
So
so
the
way
people
bill
laura
is
that
that,
although
laura
provides
plenty
of
bandwidth
for
doing
both
directions,
typically
the
the
way
people
bill
it,
they
assume
that
maybe
a
hundred
machines
are
going
to
use
256
kbytes
of
data
over
over
a
day
or
something
and-
and
you
might
do
that
in
one
of
these
transactions.
D
It
probably
won't
be
reasonable
to
claim
that
until
we
actually
do
so,
there
are
probably
a
few.
There
are
a
few
places
I
can
see
in
there
the
rendezvous
protocol
and
things
where
we
might
get
into
trouble,
but
we
did
design
the
protocol
so
that
it
can
actually
run
over
any
any
kind
of
a
stream
transport.
So
it
should
be
possible
to
to
get
the
protocol
to
run
in
on
a
non-ip
network.
D
D
Yeah,
so
we
because
of
because
we're
do
we're,
you
know
we're
we're
funding
this
through
intel
at
the
moment.
We're
doing
these
proof
of
concept
and-
and-
and
you
know,
linux
style,
onboarding
suites,
so
right
now,
where
we
are,
is
probably
in
the
like
50
70k
of
code,
but
I
think
it
actually,
if
you
had
crypto
acceleration,
some
of
that
would
go
away
and
I
think
that
there's
actually
room
for
for
people
to
optimize
that
down.
D
A
D
D
No,
no!
This
is
not
a.
This
is
not
a
phyto
authenticator,
that's
in
the
device.
This
is
an
understanding
that
devices
use
similar
technologies
to
identify
themselves,
so
you
may
have
a
device
that
has
that
kind
of
technology
in
the
device.
For
example,
every
intel
device
does,
but
you
and
and
many
arm
devices
do
as
well,
but
but
you're
you're
not
actually
required
to
have
that
to
run
fdo.
A
D
F
F
Basically,
as
you
know,
jeff
was
talking
about.
We
support
the
intel.
Secure
trusted
execution
environment
in
the
form
of
you
know,
convert
security
management,
engine
csme,
which
can
host
a
hardware
route
of
trust
in
the
form
of
epic
key
or
an
ecdsa
key
available
for
intel,
x86
and
arm
platforms.
Then
we
also
support
ppm
right
and
then
we
also
do
a
software
file
system
based.
You
know,
creation
of
a
root
of
trust
and
use
it.
So
in
vms
we
are
using
that,
but
I
think
we
are
also
adding
what
we
call
it.
F
You
should
be
able
to
use
it
eventually.
Once
we
have
all
of
that
up
and
running.
Okay
thanks,
you
can
actually
individual
vms
right.
For
example,
if
you
remember
seeing
the
slide
jeffers
showing
that
at
manufacturing
you,
you
do
a
device
in
it,
if
we
call
it
sdodi,
right
or
fdodi,
which
is
in
embedding
the
credentials
into
the
device,
we
have
the
infrastructure.
Now,
which
is
also
now
becoming
secure
even
for
for
any
location
right
where
you
can
do
the
die
on
the
fly,
you
start
a
vm.
F
Let
it
talk
to
the
the
you
know:
the
device
in
initialized
infrastructure,
where
the
origin
voucher
is
created
and
the
device
specific
credentials
are
made
available
in
the
device.
So
that
can
be
done
on
a
vm.
You
can
start
with
a
vanilla,
vm,
nothing
on
it,
do
a
die
and
then
do
sdo
to
do
rest
of
it.
You
can
install
the
selected
choice
of
your
operating
system
on
that
vm
and
then
provision
with
multi-stage
onboarding
to
a
management
service,
orchestration
service
and
any
other
service.
So
you
can
do
so.
D
So
I
would
say,
we've
experimented
with
these
things
and
it's
there.
I've
kind
of
wondered
in
my
mind
as
to
whether
you
know
it,
whether
that's,
whether
this
is
the
right
protocol
to
do
that,
it
certainly
is
capable
of
doing
it
and
it
may
be
it,
but
on
the
other
hand
it
because
of
because
it's
designed
for
for
bare
hardware
and
for
for
for
doing
doing
devices
that
are
sent
through
a
a
channel
distribution
channel.
D
You
might
find
that
it's
harder
to
use
some
of
the
features
that
are
generally
available
in
in
a
hypervisor
to
help
you
in
this
situation.
So
you
might
say
well
if
I
had
a
if
I
had
a
hardware
device
that
was
on
boarding
with
with
fdo,
and
I
moved
it
into
a
virtual
machine
as
a
virtual
hardware
device
and
it
could
still
use
fdo,
and
I
think
that
would
be
a
really
good
application
for
it.
D
But
then,
when
I
got
up
there,
I
think
I
would
want
to
sit
down
and
say:
okay,
do
I
really
want
to
go
and
use
a
protocol
that
is
not
willing
to
use
any
of
my
other
understanding
of
the
system
because
it
was
designed
for
raw
hardware
or
do
I
want
to
use
an
onboarding
protocol?
That's
built
on
top
of
the
the
mechanisms
that
I
already
have
in
the
os
and
then
the
hypervisor.
So
so
that
would
be
where
I'd
go
on
that
and
and
we've
put
we've
tried
it
all
yeah.
D
So,
okay,
let's
so,
then
you
know.
Where
are
we
on
this?
Well,
we
have
a
an
lf
edge
project
as
well,
and
it's
called
the
elf
edge
secure
device
on
board.
So
it
tells
you
sort
of
historically
that
the
when
you
go
there
you
will
find
software
for
sdo
and
but
you
will
also
find
software
for
fdo.
Currently,
what
you'll
see
is
you'll
see
just
protocol
testing
releases
and
in
in
probably
in
a
few
months,
you'll
see
real
releases
and
you
can.
D
This
project
has
its
own
governance,
so
you
can
actually
go
and
look
on
that
project
and
find
out
when,
when
they're
expecting
to
get
what
piece
is
available
and-
and
this
is
all
sitting
out
there,
so
you
can.
You
can
go
ahead
and
if
you
wanted
to
download
some
seo
code
today,
you
could
go
ahead
and
do
it.
And
if
you
wanted
to
test
out
the
the
fto
protocols,
you
can
go
ahead
and
do
it.
D
So
you
can
actually
see
the
extent
to
which
you're
functionally
equivalent
within
these
two
with
the
in
these
two
suites
and-
and
this
is
the
one
intel
slide
that
I
wanted
to
include
here,
which
is
just
explaining
what
the
modules
are
that
you
have
in
here.
So
there
are,
there
are
actually
components
that
are
available
in
each
level,
for
the
manufacturer
level,
for
the
reseller
and
and
to
do
the
installer.
D
This
is
what
what
rakesh
was
talking
about
and
then
to
actually
do
the
the
iot
platform
or
that
that's
sort
of
the
clout,
what
we
kind
of
ended
up,
calling
the
cloud
the
cloud
side
and
and
there's
open
source
components
that
are
scattered
around
there's
a
binary
component
that
we
we
didn't
release
because
it's
for
an
intel
t.
So
nobody
can
do
anything
with
it,
except
for
run
the
binary
on
an
intel
t.
D
If
you
probably,
nobody
in
this
group
needs
to
understand
some
of
these
things.
But
there
is,
you
know
if
you've
had
experience
with
sdo.
What
you'll
see
is
that
the
coatings
are
different
because
we're
using
some
of
the
later
ietf
mechanisms
that
appeared
between
the
two
as
as
as
the
base
for
encoding
and
so
one
of
the
things
you're
getting,
is
that
the
code
size
will
go
down
as
we
go
to
fdo
and
the
team
is
kind
of
selling
us.
D
This,
but
we're
too
early
to
give
you
a
real
answer
on
how
much
and
and
some
of
the
crypto
options
are
increased
because
cos
a
actually
offers
additional
crypto
modes
that
weren't
in
the
original
protocol,
and
we,
we
also
added
a
feature
to
make
sure
the
service
info
even
more
powerful
in
an
sdo.
When
we
first
did
it,
we
we
had
only
one
round
of
service
info,
it
could
be
as
large
as
you
wanted,
but
it
was
only
one
round.
D
We
said:
okay,
well,
that
that
actually
works
in
a
wide
variety
of
circumstances,
but
we
we
thought
it
actually
was
more
modular
if
we
did
multiple
rounds,
and
so
we
added
that
capability
into
the
fighter
protocol.
And
then
you
know
the
the
normal
things
that
are
in
here.
This
rendezvous
bypass
mechanism
is
actually
something
to
make
it
possible
for
people
to
experiment
with
non-ip
protocols.
D
D
System
so
the
the
way
we
do
it
in
the
existing
lfe
software
is
we
we
have.
We
have
the
ability
to
have
a
an
sdo
subsystem.
So
this
is,
you
know,
fdo
hasn't
happened
yet
so
it's
an
sdo
subsystem
that
you
would
run
say
as
a
virtual
machine
within
a
cloud
and
and
it
it
communicates
using
api,
calls
out
to
your
your
manager,
and
so
that's
how
you
do
the
service
info.
D
So
you
you
say
the
ownership
voucher
gets
passed
into
this
and
it
does
all
the
protocols
and
it
interacts
backwards
with
it,
with
its
own
api
protocol
to
allow
you
to
interact
with
the
system,
and
so
so
that
mechanism
is
actually
sitting
up
there
on
in
github
and
that
level
of
of
spec
we've.
We've
pushed
off
to
lfh
cool
cool
I'll.
Definitely
take
a
look
at
it.
Thanks
and
you're
welcome
to
participate.
A
D
D
Well,
one
of
the
things
you
know
we
didn't
require
that
it
run
in
a
container,
but
one
of
the
things,
for
example,
that
rakesh
has
done
is,
is
to
run
specifically
in
a
container
which
solves
the
problem
of
allows
us
to
have
a
linux
version
of
of
the
client
software
that
runs
on
the
device
that
is
independent
of
the
of
which
linux
you're
running
on
the
device.
So,
yes,
the
answer
is
yes,
you
can
do
that.
D
C
Me
interject
something.
So
the
idea
is
this:
you
might
have
multiple
swim
lanes
where
you'd
want
this
technology
at.
Like
you
know,
jeff
just
went
through
this
fundamental
lower
layer,
bare
metal,
onboarding
in
the
operating
system,
etc.
Then
the
next
level
would
be
the
gating
factor
of
joining
nodes
to
that
cluster.
F
C
C
D
D
If
you
wanted
to
build
up
a
set
of
nodes
and
a
kubernetes
cluster
that
was
out
in
an
edge
somewhere
and
you
wanted
to
ship
nodes
out
and
you
you,
you
were
buying
nodes
that
had
fdo
on
them.
Then
you
could
set
up
the
cluster
that
way
now,
there's
a
certain
amount
of
software
required
right
to
get
that
all
to
happen
and
and
and
you
you
guys,
probably
know
more
about
it
than
I
do,
but
but
but
it's
certainly
something
that
we
intend
and
we
always
intended
to
make
possible.
C
Code
and
we
call
this
kind
of
thing-
lego
blocks
for
the
edge,
and
it
literally
is
like
jeff
just
said.
Imagine
just
dropping
your
nodes
in
sdo,
you
know
you
have
a
gating
factor
to
say:
hey.
Can
this
join
this
particular
cluster
at
this
location
and
then
autonomously,
you
know,
says:
hey
I'm
the
this
guy.
I
need
the
keys
to
join
your
cluster
and
boom
itself
builds,
and
you
know
also
in
addition,
heals
itself
in
when
the
in
an
event
of
a
failure
of
the
control,
plane
or
worker
promotion,
demotion,
yeah.
So.
A
F
A
D
Right
right
right
right
and
we
the
the
way
we
that
came
out
in
in
the
fido
discussions.
We
had
this
discussion
about
a
trusted
installer
versus
an
untrusted
installer,
so
the
installer
is
the
person
who's
standing
there
beside
the
device-
and
the
question
is:
is
this
in
in
many
corporate
or
or
commercial
environments
the
installer
is
not
actually
in
is
not
actually
trusted
to
interact
with
the
device
and
so
the
so.
So
this
mechanism
is
actually
an
untrusted
installer
mechanism.
A
You
guys
want
to
work
together
on
a
little
demo
of
that.
I
think
you
know
some
of
this.
Some
of
us
in
this
group
are
involved
with
education
of
the
community
and
I
think
there
are
a
class
of
people
who
don't
want
to
see
kind
of
the
underlying
math
and
protocol
diagrams,
but
just
want
to
see
the
live
demo
of
let's
use
three
intel
nooks
or
some
other
brand
name
of
small
devices
and
throw
up
a
mini,
kubernetes
cluster.
A
F
That
we've
got
our
own,
you
know
software,
which
uses
kubernetes
and
creates
a
cluster
for
the
industrial
systems.
We
call
them
software
devices
define
industrial
systems
and
that
we
onboard
to
that.
You
know
we
call
it
a
we
call
it
castle
lake.
I
don't
know
if
you've
heard
about
it
or
not,
it
uses
kubernetes
under
the
hood
to
manage
all
the
containers
which
are
running
on
the
on
these
nodes
in
the
cluster,
and
you
can
move
the
containers
or
vms
from
one
node
to
another
code.