►
From YouTube: ORI "AAAAA" Office Hours
Description
Assembly, Acquisition, Access, Authentication, and Authorization for Amateur Radio and Amateur Satellite Services - what does it mean and what are we doing about it? Office hours discussion on our DEFCON 2022 poster for Radio Frequency Village.
A
A
B
A
Okay,
good,
it
must
have
been
minor
yeah.
So
that
was
a
big
step
forward,
because
it
was,
it
goes
from
completely
theoretical
to
having
something
working
in
jupiter
notebook
and
then
I
think
that
the
next
step
well
also,
I
should
back
up
and
say
that
we
just
it's
captured
in
the
opulent
voice
document-
is
some
the
beginning
of
of
some
decisions
about
the
database
in
the
in
the
payload
or,
if
you
want
to
think
of
it
in
the
central
node
of
a
terrestrial
network
or
in
in
the
payload
of
a
spacecraft.
A
So
when
I
say
payload,
I
know
that's
overloaded.
We've
we've
realized
that
you
have
a
payload
in
a
frame
and
a
payload
in
the
spacecraft,
but
for
the
most
part,
we've
been
able
to
keep
these
two
terms
separate
and
and
distinct
in
our
minds.
You
know,
but
but
there
is
some
state
that
has
to
be
kept
track
of,
and
so
we
we
started
making
some
decisions
and
really
kind
of
looking
hard
at
exactly
what
the
spacecraft
needs
to
keep
track
of
and
trying
to
decide
how
long
the
token
needs
to
be.
A
It
doesn't
really
have
to
be
that
long,
because
the
the
token
is
is
not.
It
doesn't
have
meaning
just
by
itself,
so
it
doesn't
have
to
stand
alone.
So
the
little
bit
of
math
that
I
did
a
couple
of
weeks
ago
is
not
as
critical
and
the
the
reason.
Why
is
because
the
token
is
connected
up
to
callsign
ssd
and
that
entire
string
is
really
what
you
want
to
look
at
when
you're
doing
authentication
and
authorization.
A
Yeah,
what
what
kind?
I
guess,
today's
today's
focus
should
be
on
like
what
kind
of
demonstration
is
there
anything
that
we
are
doing
now?
That
would
jeopardize
it
like.
Is
there
anything
we
need
to
do
today
or
in
the
near
future
or,
and
all-
and
I
guess
also
today
is
where
we
really
need
to
look
at
like
the
what
the
poster
session
or
the
poster
presentation
or
any
sort
of
paper
or
any
sort
of
documentation
for
for
defcon.
B
B
A
B
C
The
google
doc
updates,
I'm
not
seeing
the
authentication
part
that
was
kept
in
so
so
maybe
by
this
week
end
I'll
just
try
to
put
in
a
draft,
so
one
half
part
of
the
poster
will
contain
the
the
setup,
the
opulent
voice
demo,
with
authentication
the
certificate
and
all
and
the
other
half
would
be
the
related
to
the
jamming
and
all
the
future
work.
The
future
research
work
that
we
want
to
do.
I
was
thinking
that
I
partitioned
it
in
that
way,
and
I
started
reading
about
it.
C
A
Okay,
that
sounds
really
good.
I
think,
maybe
by
this
time
next
week,
that
we
could.
It
sounds
like
by
this
time
a
week
from
today
that
we
could
review
it
together
and
and
go
ahead
and
make
a
make
a
cut
of
it.
So
it
doesn't
have
to
be
perfect,
but,
like
I
think,
the
the
the
two
topics,
the
you
know,
defending
against
jamming
in
this
particular
environment.
There's
lots
to
be
said,
and
that
might
be
super
fun
and
yeah
the
authentication
protocol.
B
Well,
for
the
def
con
audience
in
particular,
I
would
be
inclined
to
focus
on
this.
The
authentication
part
of
it.
They
are
not
necessarily
rf
jamming
experts
and
I'm
not
sure
we're
going
to
have
very
much
to
say
about
that,
because
we're
not
an
anti-jam
protocol,
they're
a
bunch
of
well-known
things
you
can
do
to
mitigate
jamming
that
we're
not
doing.
B
A
Okay,
the
we
there
are
a
few
people
in
in
radio
frequency
village
that
that
are
pretty
good
at
recommending
things
for
jamming
it's
an
open
question
as
to
whether
or
not
we
had
implemented
any
of
those
because
it
anything
that
you
implement
to
make
it
really
really
hard
to
jam
makes
it
harder
to
use
the
system
in
the
first
place.
So
it's
a
really
interesting
trade-off,
which
I
think
would
probably
be
of
interest
to
lock.
A
I
mean
just
going
through
all
of
that
and
presenting
it
in
an
environment
that
doesn't
get
a
whole
lot
of
attention
in
channels
that,
in
terms
of
amateur
radio
are
underutilized
would
be
would
be
valuable
work
but
yeah
the
in
general.
The
defcon
crowd
is
going
to
be
able
to
critique
the
authentication
protocol
much
more
much
more
broadly,
it's
going
to
be
a
lot
of
people
that
would
be
able
to
to
critique
the
the
protocol
rather
than
rather
than
the
rf
channel.
A
C
Sure,
I
think
I
think
that
can
be
done.
Maybe
maybe
three
three
fourth
of
the
poster
can
be
dedicated
towards
the
authentication,
the
various
forms
of
authentication
or
and
the
rest
could
be
like
an
open-ended
question.
As
I
said,
you
could
put
some
bullet
points
of
whatever
what
all
could
be
done
and
what
all
do
the
crowd
thinks
about?
A
A
C
Sure
I
think
I
have
a
couple
of
questions
here
so
so,
when
you,
when
you
say
using
the
authentication
mechanism,
is
it
just
only
for
the
control
commands
or
will
it
be
for
every
digital
message
I
mean
for
every
normal
payload?
Also,
do
we
do
this
authentication,
because
I'm
thinking
it
will
be
a
lot
of
payload
for
the
processing
that
it
will
be
adding
up.
B
Each
user
transmitting
into
this
session
may
potentially
need
to
be
authenticated
in
the
in
the
most
locked
down
situation,
then,
as
any
as
soon
as
anybody
joins
the
conversation
and
transmits,
the
payload
will
have
to
make
sure
that
they
believe
that
person
is
who
they
say.
They
are
and
check
the
block
list
make
sure
they're
not
to
be
turned
off
that
doesn't
have
to
be
done.
Every
transmission.
B
B
Each
frame
does
have
to
have
a
little
bit
of
information
in
it,
which
is
assumed
to
be
hard
for
the
attacker
to
reproduce
and
at
the
very
basic
level.
It
would
be
a
token
that
might
never
change
or
might
change
only
on
demand,
and
we
could
get
a
little
more
sophisticated
than
that
depending
on
what
we
think
the
threat
model
is.
It
could
be
a
rolling
token
a
token
that
changes
with
time.
B
C
Yeah,
that's
helpful,
yeah
yeah,
so
the
other
which
I
had
is
like.
Are
we
only
sticking
to
this
lotw
based
authentication
or
are
really
open
to
researching
the
other
forms
of
authentication
like,
for
example,
using
the
channel
state
information
or
using
the
fec
codes
as
a
form
of
authentication?
There's
some
research
topics
that
which
are
in,
of
course
they
might
take
a
lot
of
time
to
implement.
But
I
just
want
to
know
the
the
flexibility
that
we
are
having
over
here.
B
B
There's
got
to
be
some
source
of
truth
and
a
way
of
distributing
that
source
of
truth
out
into
the
world,
and
that's
always
been
the
problem
for
encryption
or
authentication
on
the
internet
or
on
the
on
networks
in
general
that
the
public
key
infrastructure
is
the
hard
part
and
we're
in
the
enviable
situation
of
having
a
public
key
infrastructure.
That's
already
been
built
for
us,
that's
good
enough,
and
so
using
it
is
a
reasonable
place
to
start.
B
That's
that
points
to
the
need
for
maybe
a
couple
of
a
couple
extra
bits
in
the
in
the
frame
header
saying
you
know
what
kind
of
authentication
am
I,
but
that
might
not
have
to
be
carried
frame
by
frame.
It
might
just
be
part
of
the
network
transaction
for
responding
an
authenticate
on
an
authentication
challenge.
C
A
Yeah
cool,
no,
we
I
I
agree.
We've
got
a
pretty
good
system
to
to
go
ahead
and
prototype
and
implement,
but
if
there
is
something
that
we
want
to
look
at
in
parallel,
then
then
I
think
we're
enthusiastic
about
going
ahead
and
trying
it.
Because
I
mean
that's
a
whole
paper
in
and
of
itself
right
is
you
know,
can
you
successfully
leverage
logbook
of
the
world
and
ssl
and
and
make
it
work?
A
A
I
think
for
the
prototype,
we'll
we'll
keep
steaming
ahead
and
leverage
what
we,
what
we
have
with
a
log
book
of
the
world
and
open
ssl,
but
yeah.
Please,
please
inform
us
if
there's
something
that
we
need
to
to
consider
as
an
alternative
or
that
we
can
compare
and
contrast
and
and
get
some
some
good
results
from
like
a
an
a
b
comparison.
B
A
A
I
don't
know
if
paul
any
any
thoughts
on
on
what
what
comes
next.
It
sounds
like
the
jupiter
notebook
thing
was
a
big
step
forward,
we're,
I
think,
we're
still
at
the
point
where
we're
trying
to
get
it
to
work
over
the
air
and
and
maybe
not
yet
ready
to
implement
the
authentication
and
authorization
stuff.
B
But
I
also
know
that,
with
security
systems,
it's
very
easy
to
design
something
dumb
that
that
has
giant
gaping
holes.
You
can
drive
a
truck
through
and
I'm
afraid
that
in
my
inexperience
with
crypto
systems
and
authentication
systems
that
I
might
design
one
of
those
and
that's
the
main
reason
why
I
want
to
get
protocol
details
out
in
front
of
the
def
con
crowd.
So
they
can
see
and
point
out.
You
know
point
at
my
poster
and
laugh
and
say:
look
you
made
the
classic
mistake
here
at
step.
Three.
B
A
It's
not
in
you
know,
just
speaking
for
myself,
I
I
it's.
I've
learned
to
to
go
ahead
and
put
those
things
on
posters
or
papers
or
or
say
them
in
a
presentation
and
then
have
people
laugh
and
point,
but
I
know
that
not
everybody
else
is
enthusiastic
about
soliciting
comment
and
critique
this
way
so
yeah
we
need
to.
A
We
need
to
do
all
that
we
can
to
prepare
a
good
poster,
and
I
the
little
bit
that
I
know
from
information
theory
is
that
you
can
attack
this
or
you
can
mitigate
this
in
in
at
least
two
ways.
So
your
token
can
either
be
long
or
or
it
can
roll
it
can
change
right.
So
those
are
the
two
degrees
of
freedom
that
you
have,
and
you
know
I
mean
looking
at
the
number
of
users
that
we
expect
to
have
at
any
one
time.
A
That's
another
degree
that
you
have
that
that
kind
of
it's
not
a
real
hash,
but
it
mixes
things
up
quite
a
bit
and
then
the
threat
models
that
we've
walked
through
in
the
in
the
document
are
are
things
that
somebody
would
have
to
expend
an
awful
lot
of
effort
to
do
because
of
the
directional
nature
of
microwave
transmissions.
So
all
those
things
together,
you
know
we
for,
for
the
for
at
least
like
amateur,
microwave,
terrestrial
beacon
or
or
satellite,
I
think
we're
in
decent
shape
now
from
what
I
know
just
from
formal
learning.
A
But
then
again
I
have
limitations
too,
because
this
is
it's
an
area
that
I
know
a
lot
about,
but
not
employed
as
a
cybersecurity.
You
know
wireless
security,
professional.
So
that's
that's
the
reason
why
we're
talking
about
these
things
and
and
trying
to
work
as
much
out
in
advance
as
possible
and
get
them
on
get
them
good
on
a
poster
so
enthusiastically
agree,
but
we're
really,
we
really
haven't
screwed
up
too
badly.
Yet
you
know
is,
from
an
information
theory
perspective,
we're
we're
still
in
decent
shape.
A
So
you
know
if
we
can
get
a
draft
of
like
to
lock
do
everything
that
you
know
about
and
don't
don't
try
to
make
it
perfect,
just
whatever
draft
you
have
and
your
thoughts
and
chuck
it
out
there
as
soon
as
possible
and
then
we'll
all
take
we'll
all
plow
into
it
and
edit
it.
You
know,
just
in
some
format
that
we
can
edit
we'll
all
work
together
and
we'll
make
it
good
enough.
So
don't
worry
about
it
being
perfect.
A
We're
we're
just
going
to
get
it
to
the
point
where
it's
you
know
where
is
good
enough
for
for
defcon
and
and
then
it'll
be
a
work
in
progress
for
for
probably
months
really
or
if
not,
if
not
another
year,
it'll
be
to
the
point
where
we
go.
Oh
yeah.
This
is
all
sorts
of
things
that
we
we
now
know
and
can
prove
through
implementations.
A
So
don't
wait
anything
that
you've
got
that
you're
interested
in
including
the
jamming
part
just
go
ahead
and
get
it
down
in
whatever
form
and
and
and
publish
it
to
to
the
list
or
to
us
as
soon
as
possible,
and
then
we'll
run
with
it.
You
know,
because
there's
a
whole
lot
of
good
stuff
in
here
and
and
I
think
we've
got
a
decent
take
on
it.
You
know
getting
getting
a
review
from
from
a
from
a
crowd
like
def.
Con
is,
is
a
really
good
opportunity
for
us.
C
Sure
sure
julie
noted
so
the
one
one,
the
question
when,
when
you
guys
say
about
this
rolling
hash
or
the
rolling
time
stamp,
I
think
definitely
at
least
a
changing
timestamp
is
definitely
required,
at
least
to
mitigate
the
replay
attacks.
Right
I
mean
the
most
basic
form
of
the
attack
is
replay
attack,
so.
A
C
B
B
If
it
were
actually
impossible,
then
you
could
do
a
lot.
Nothing
would
matter.
There
would
be
no
threat
of
replay
attacks,
because
there's
no
way
an
attacker
could
ever
get
a
transmission
in
the
first
place
right.
This,
of
course,
is
not
strictly
true
and
especially
for
a
malicious
attacker
who's
trying
to
specifically
attack
one
other
station.
It's
likely
that
they're
local
to
each
other
in
some
sense
of
the
word
and
they
might
be
able
to
intercept
the
uplink.
B
A
A
There
there
are
and
another
another
take
on
this
is-
is
that
what
the
the
things
that
we're?
Assuming
that
it's
hard
for
a
bad
actor
to
intercept
the
uplink
depends
a
lot
on
the
frequency
choice
too,
that
it's
a
directional
microwave
link,
but
as
soon
as
you
go
to
something
that
is
not
directional,
you
know.
So
this
is
an
open
source
protocol
and
we
hope
that
people
use
it
and
they're
going
to
use
it
on
different
frequencies,
maybe
not
low
enough
to
where
it
can
be
omnidirectional.
A
But
you
know
I
mean
we're
talking
about
terrestrial
links
that
might
be
omnidirectional.
So
as
soon
as
you
go
omnidirectional
then
then
anybody
can
intercept
the
uplink
and
then
you
have
a.
If
it's
a
static
token,
then
then
somebody
that
wanted
to
could
could
mess
with
you,
and
I
mean
you
know
this,
but
a
lot
of
people
listening
to
this
might
go
well.
These
concerns
are
down
in
the
noise,
but
if
we
really
want
this
to
be
a
reusable
and
useful
protocol,
then
it's
going
to
be
used
out
well
outside
of
contexts
that
we're
assuming.
A
So
I
think
anything
that
we
can
use.
That's
standard
you
know
essentially,
industry
standard
would
is,
is
something
that
we
should
become
competent
at
and
and
at
least
like
try,
try
it
and
see
what
the
cost
is.
Anything
that
we
add
in
terms
of
overhead.
You
know
comes
out
of
the
budget
right,
but
as
of
today,
I
think
we
we
have
some
some
we
have
energy
to
spend
so
just
have
to
spend
it
smartly.
B
I
think
there
are
tricks
that
won't
actually
cost
any
rf
energy
that
will
only
cost
some
some
cpu
energy
and
some
complexity,
which
are
things
that
are
abundant
and
or
free.
So
I'm
not
too
worried
about
that
and
if
you're
terrestrial
it
doesn't
matter
whether
you're,
omnidirectional
or
directional,
because
the
attacker
can
always
put
a
receiver
somewhere
between
the
transmitter
and
the
in
the
central
hub.
A
B
A
Okay,
there's
another
opportunity,
that's
much
much
sooner
than
than
defcon
in
august,
and
that's
the
local
defcon
meetup
this
week,
where
we
could
trot
these
ideas
out
and
at
least
you
know,
give
people
some
eyeballs
and
and
ask
there-
may
be
some
folks
in
the
room
that
might
have
some
opinions,
they're,
mainly
networking.
This
is
a
group,
that's
mainly
computer
networking
and
either
red
team
blue
team.
You
know
industry
people,
but
you
think
maybe
that
might
be
might
be
worth
speaking
up
and
showing
it.
A
C
A
A
You
know
and
and
then
we'll
we'll
send
out
the
link
to
the
to
the
working
document
too,
because
and
and
see
if
we
can
catch
anybody
that
will
actually
go
walk
through
and
read
it
and
give
an
opinion.
It's
just
it's
a
good
idea
to
start
getting
it
in
front
of
the
more
people
the
better
to
where
we
can
catch
the
the
big
things
that
we
might
be
missing.
So
we'll
do
that.
A
Yes,
any
bullet
points
that
you're
most
interested
in
or
anything
that
you
that
you
think
that
you
currently
got
or
already
have
written
you
know
and
then
paul
and
I
will
try
to
put
together.
You
know
we'll
stand
up
there
and
and
talk
about
it.
I
think
it's.
It
might
just
be
easier
just
to
stand
up
in
front
of
these
these
folks,
because
we
know
them,
we
see
them
almost.
A
You
know
you
know,
there's
a
meeting
once
a
month
and
and
we're
we're
there
quite
a
lot,
so
it
might
just
be
easier
to
stand
up
and
talk
about
it
and
put
it
on
there
on
their
slack
and
ask
and
then
there's
a
couple
of
other
local
defcon
groups
that
I
have
that.
I
know
people
in
so
now
is
the
time
to
start
socializing
it
so
we'll
we'll
we'll
do
that
and
yeah.
If
you
can
give
us
any
ammunition,
then
that
would
be
great.
A
C
A
A
A
A
A
B
B
Okay,
it's
probably
good
enough,
so
this
is
the
python
notebook,
that's
command
line
stuff.
Only
the
original
version-
and
all
I'm
trying
to
demonstrate
here
is
that
I
can
use
the
public
key
infrastructure
from
law
book
of
the
world
to
sign
a
document
not
using
nothing
that
I
wouldn't
have
as
an
ordinary
law
book
of
the
world
user
and
then
validate
the
signature
again
without
any
special
secret
knowledge
from
awrl.
B
So
by
searching
for
this,
I'm
pulling
the
call
sign
out
of
that
document,
and
here
you
can
see
that
I
use
my
own
certificate
as
an
example,
so
it
pulls
out
my
call
sign,
and
then
I
grab
all
the
rest
of
the
stuff
too.
The
private
key,
the
public,
key,
the
certificates
and
so
on,
and
each
of
those
is
just
another
call
to
the
pkcs
module
of
the
open
ssl
program
with
the
necessary
command
line.
Arguments
to
get
the
thing
that
I
want,
and
here
I've
you
can
see
them
all.
B
B
B
And
I've
created
a
message:
here's
my
my
designated
message
and
put
that
into
a
file
using
this
line
of
code
and
then
sign
the
file
using
this
code.
Here,
the
digest
command
of
openssl
and
creating
this
signature
file
notice.
It's
only
128
bytes
long.
It's
not
a
not
a
heavyweight
thing
at
all,
so
I
can
easily
send
that
on
the
uplink,
regardless
of
how
big
the
thing
I
was
signing
was
and
the
finally
I'm
able
to
use
the
verify
sub
command
of
the
digest
module
of
openssl
to
verify
it
and
sure
enough.
B
It
verifies
okay
and
some
other
tests
that
are
not
visible
here.
Show
that
anything
you
change
will
cause
that
to
not
be
verified.
Okay,
so
this
proves
that
the
ground
station
is
able
to
use
the
public
key
infrastructure
to
sign
an
arbitrary
thing
and
that
that
can
then
be
validated
by
the
spacecraft
or
by
authentication
ground
station.
If
that's
the
way,
you
wanted
to
implement
it
without
any
special
knowledge,
and
that
is
not
the
entire
system.
B
B
A
B
Yes,
I
imagine
that
the
spacecraft
would
send
a
directed
challenge
to
one
or
more
ground
stations
that
would
contain
some
special
information.
A
nonce
or
something
of
that
nature,
and
each
ground
station
that
was
so
addressed
would
create
a
message
containing
the
nonce
containing
their
own
randomly
generated
token
or
something
having
to
do
with
generating
future
tokens.
B
Yes,
that's
really
who
it
says
says
it
is
check
his
list
of
blocked
and
accepted
stations
and
decide
whether
to
grant
access
and
make
a
database
entry
locally
on
board
to
spacecraft,
saying,
okay,
tokens
generated
according
to
this
information
are
to
be
accepted
and
then
from
then
on
the
ground
station.
Just
generates
a
token
according
to
that
information
and
appends
it
to
each
frame
that
goes
up
and
every
frame
gets
at
least
a
little
bit
of
validation
according
to
that
the
length
of
that
token.