►
From YouTube: 20220718 AAAAA Office Hours
Description
Walk-through of recent work and planning for DEFCON RF Village poster.
B
B
B
B
So
let's
do
a
little
bit
of
a
walk
through
I'm
gonna
to
share
my
screen
to
present
a
little
diagram,
okay
good.
So
this
is
a
mermaid
diagram
which,
by
the
way,
is
a
very
cool
tool
for
doing
certain
kinds
of
diagrams
inside
a
markdown
document
that
shows
the
message
flow
for
authentication.
It's
not
the
whole
story,
but
is
a
key
part
of
it,
and
most
of
this
is
indistinguishable
from
what
we
did
and
what
we've
had
in
the
in
the
pipeline
for
a
couple
of
years.
Now.
B
The
basic
idea
is
that
the
satellite
is
always
broadcasting
certain
basic
information.
You
need
to
know
in
order
to
do
authentication
about
once.
A
second
is
a
suitable
broadcast
interval,
because
a
new
station
coming
online
for
the
first
time
or
even
for
the
for,
however
many
times
we'll
have
to
know
some
of
this
information
before
it
can
get
into
the
system
and
start
using
it.
B
Hopefully,
the
default
will
be
open
access
to
everybody,
but
there
may
be
certain
cases
in
which
there
this
has
to
be
restricted
to
some
extent
and
when
the
policy
decides
that
it's
time
to
to
authenticate
a
user,
make
him
prove
that
he's
really.
He
says
he
is
and
gets
set
up
to
do
further
validation
of
his
transmissions
from
then
on,
then,
the
satellite
sends
a
directed
message
which
I'm
calling
the
direct
auth
challenge.
B
B
The
station
will
notice
this
message
if
it's
complying
with
the
air
interface
spec
and
will
then
respond
with
the
auth
response
message,
which
contains
his
part
of
the
the
information
for
the
crypto,
I'm
speaking
as
if
these
stations
are
people
and
I'm
using
male
pronouns
out
of
long
habit.
But
I
don't
necessarily
mean
that
the
user
is
a
man.
B
That
message
goes
up
to
the
satellite
or
the
whatever
station.
We
have
doing
the
central
function
and
it
will
be
able
to
authenticate
the
user
using
the
certificate
from
logbook
of
the
world,
and
it
will
be
able
to
complete
a
key
exchange
procedure
with
the
the
ground
station
which
results
in
a
shared
secret
between
the
satellite
and
the
ground
station.
It's
not
a
communications,
so
it's
not
a
not
secret
communication
information.
It's
just
a
shared
secret.
B
That's
been
created
by
this
protocol,
there's
no
way
to
transmit
information
this
way
theoretically,
according
to
crypto,
and
then
it
has
everything
it
needs
in
order
to
get
started,
and
it
sends
back
an
auth
act
message
giving
the
result.
Typically,
if
everything
is
happy,
the
result
will
be
a
welcome
message
and
the
ground
station
is
allowed
to
continue
transmitting
using
the
new
crypto
authentication
tokens,
and
there
will
be
a
particular
time
designated
in
the
auth
act
message
at
which
the
new
information
takes
effect.
B
The
only
requirement
really
on
the
uplink
is
that
these
messages
get
sent
just
the
one
auth
response
message
really,
which
may
take
a
little
bit
out
of
the
the
voice
capability.
If
that's
what
the
ground
station
is
doing,
the
exact
contents
of
these
messages
has
been
so
not
maybe
not
precisely
set
out
but
set
out
in
general
in
this
document,
and
I
think
I've
got
the
fields
we
need
to
get
the
crypto
to
work.
B
The
diffie-hellman
requires
a
random
number
from
both
sides
running
through
a
computation
on
both
sides
and
then
the
results
exchanged,
and
then
both
sides
have
the
shared
secret
after
a
further
single
computation
and
then
from
then
on.
Each
individual
frame
that
gets
transmitted
will
have
a
token,
and
this
token
doesn't
have
to
be
very
big
because
only
authenticating
a
frame
or
a
small
number
of
frames
of
transmission,
but
it
has
to
be
reasonably
unpredictable
so
that
an
attacker
can't
just
start
generating
those
by
itself.
B
B
The
number
changes
and
the
server
knows
when,
when
it's
changing
and
what
the
cryptographically
secure
pattern
of
numbers
is
we
use
that
same
system,
although
we
don't
distill
it
down
to
six
digits,
we
use
the
whole
32
bytes
of
crypto
information
developed
by
the
by
the
algorithm,
which
is
called
hmac
sha-256,
we'll
call
it
hmac.
For
short,
the
hmac
can
get
re-computed
periodically.
B
Whenever
you
run
out
of
information
to
send
as
tokens
and
in
the
maximum
security
setting,
then
each
token
is
used
exactly
once
for
exactly
one
frame,
and
that
means
you
run
out
of
tokens
about
every
two
thirds
of
a
second
and
you
do
the
computation
again,
which
takes
a
fraction
of
a
millisecond
on,
say,
a
raspberry
pi,
and
then
you've
got
another
two
thirds
of
a
second
worth
of
information.
So
this
is
very
feasible.
It's
not
a
huge
computation,
not
a
big
load
on
the
ground
station.
B
That
load
gets
multiplied
in
the
satellite
by.
However,
many
users
it's
trying
to
support
it's
still
within
the
realm
of
feasibility,
but
if
it's
not
the
satellite
can
always
just
drop
some.
It
doesn't
have
to
authenticate
every
single
frame,
and
if
you
do
that,
where
the
the
token
rotates
for
every
single
frame,
then
there's
no
way
to
do
a
replay
attack.
B
If
you
want
to
reduce
the
load,
then
you
can
start
repeating
the
token
for
some
number
of
frames
and
that
slows
things
down
in
general,
but
it
does
open
up
a
window
for
a
replay
attack.
So
I
would,
I
would
hope,
to
keep
it
capable
of
doing
the
full,
fully
secure
one
token
per
frame
mode
now.
It
may
be
the
case
that
this
is
too
much
for
the
satellite,
depending
on
what
kind
of
computing
hardware
we're
able
to
spare
for
for
authentication
up
there.
B
But
not
every
user
needs
this,
because
not
every
user
has
a
nearby
attacker
who's,
specifically
trying
to
steal
their
own
uplink.
So
it
might
be
the
case
that
some
users
who
do
have
this
problem
are
going
to
authenticate
with
a
new
token.
Every
frame
and
other
users
might
be
doing
it
on
a
slower
basis.
So
the
protocol
that
I've
written
down
and
proposed
permits
that
there's
a
way
for
the
the
user
station
to
say
I
need
to
be
more
secure.
I
need
to
be
less
secure
within
a
range
permitted
by
the
sideline.
B
In
which
case
it
can
be
revoked,
there's
procedures
for
that
built
into
the
certificate
system.
So
that's
step
one
step
two:
is
this
diffie-hellman
key
exchange,
which
is
very
standard?
Lots
of
crypto
protocols
use
it,
including
over-the-air
provisioning
of
cell
phones,
which
is
a
much
higher
monetary
value
transaction
than
when
we're
doing?
B
And,
lastly,
this
hmac
procedure
for
generating
a
token
for
for
each
frame
or
for
every
few
frames,
and
all
of
this
is
existing
crypto
code.
We
don't
have
to
write
any
crypto
code.
We
can
use
the
open,
ssl
library
to
do
all
those
procedures
or
we
can
find
other
open
source
code
that
does
it.
I
found
an
hmac
implementation
that
that
can
do
a
few
dozen
of
these
computations
for
all
different
kinds
of
hmac
running
the
validation
suite
on
a
raspberry
pi
in
three
milliseconds.
B
So
I
think
it's
sub
one
millisecond,
maybe
by
quite
a
bit
so
one
millisecond
on
a
raspberry
pi
to
do
one
of
these
computations.
So
that's
that's
very
feasible.
That's
a
good
summary
of!
What's
in
that
document,
read
the
document
find
the
mistakes.
Let
me
know:
there's
lots
of
details
that
are
not
in
there.
That'll
have
to
be
written
down
for
a
fully
comprehensive
air
interface,
that
is
for
the
future
for
the
immediate
future.
C
B
Okay,
good
good
point:
I
don't
know,
I
don't
think
it
matters.
I
showed
I
put
in
elliptic
curve
to
the
almond,
because
it's
modern
and
cool
it's
supposed
to
be
a
little
bit
lighter
weight
and
if
that
turns
out
to
be
true,
then
we'll
use
it
and
if
not,
we
can
use
the
standard
different
helmet.
The
same
outcome
either
way.
I
think.
C
C
Yeah
sure
so
from
my
side
yeah,
I
spent
some
some
time
in
reading
the
document
which
paul
shared.
I
read
that
two
to
three
times
and
after
some
some
days,
I
got
a
better
clarity
of
how
it
how
it
was
working
and
yeah.
I
think
a
better
way
of
presenting
that
would
be
is
what
required
for
the
poster
right.
So
I
just
I
had
some
draft
version
of
a
diagram.
C
I
mean
just
just
I
scribbled
on
my
on
my
paper
on
how
it
could
so
that
it
so
that
with
one
that
one
diagram,
people
explain
the
whole
process.
So
that's
still
in
progress.
That's
still
not
completed
that
that's
about
putting
up
a
big
diagram,
it's
still
in
progress,
so
maybe
at
least
I
need
another
two
or
three
days
to
stitch
it
up
and
and
put
up
that
in
the
group
and
other.
B
C
C
C
So
for
that,
maybe
we
could
make
a
mandatory
requirement
in
the
face
for
ground
firmware.
That
is
the
ground
station
firmware
for
it
to
be
integrated
with
the
device
driver
of
the
power
source,
and
it
should
be
emitting
the
power
sources
measurements
continuously,
so
that
we
will
be
aware
of
how
much
how
much
bandwidth
this
guy
has.
C
C
We
could
know
what
kind
of
authorization
policy
could
we
put
in
put
him
into
so
that
we
know
maybe
he's
a
probable
probabilistic
guy
who
could
have
a
more
jamming
power,
and
probably
he
could
do
a
jamming,
maybe
still
he's
authenticated
and
he's
a
good
guy
for
now,
but
maybe
after
some
point
he
may
go
rogue
and
maybe
that
parameter
of
power
source
is
something
that
I
thought
would
would
help
us.
Maybe
you
guys
could
better
comment
on
it.
If
it's
possible
or
not
another
thing,
is
it's
just
a
reminder
for
us?
C
It's
about
the
echo
the
echo
thing
which
michelle
has
suggested
last
time,
that
is
an
uplink
transmission,
should
also
consider
container
echo
so
that
we
get
to
know
whether
the
user,
if
he
gets
to
listen,
listen
it
back,
then
it's
it's
a
confirmation
that
he
has
the
required
setup
ready
for
for
a
successful
transmission
to
happen,
and
I
think
this
echo
part,
maybe
I
thought
we
could
put
it
in
the
acquisition
process,
the
acquisition
process
of
whatever
the
mentioned
there
yeah.
This
is.
C
B
C
C
Yeah
sorry,
my
intention
of
proposing
this
is
that
not
not
to
know
it
at
the
signal
power
but
level.
The
system's
power
level,
for
example,
say
the
raspberry
pi
is
connected
to
a
five
volt
source,
whether
it's
is
it
connected
to
a
lithium-ion
battery
or
or
some
other
dc
power
source
which
could
which
could
uninterruptedly
give
more
power,
or
something
like
that.
So
I
just
wanted
to
know
at
the
system
level.
How
much
is
he
capable
of.
B
B
C
I
was
maybe,
then
we
could
think
of
something
where
let
us
come.
Let
us
list
out
some
points
of
how
a
normal
jammer
would
work.
Maybe
he
would
be
having
some
directional
antennas.
Some
specific,
I
don't
know
some
some
good
power
source
and
and
we
could
verify
that
against
against
them-
maybe
running
through
some
behavioral
modeling
to
see
if
he
really
has
that
kind
of
antenna
setup
through
the
through
the
rf
signals
that
we
get.
B
A
A
So
so
you
can
self
jam
with
a
failed
electrical
problem.
You
know
with
with
the
failed
circuit
and
and
then
there's
noise
from
from
other
people
that
are
that
are
maybe
transmitting
accidentally
on
top
of
you
for
some
reason
and
then
there's
intentional
harmful
interference
and
there's
all
different
types
of
that.
So
so
it'd
be
good
to
kind
of,
say:
okay,
this,
which
one
are
you
worried
about
and
then
and
then
tackle
it,
because
I,
I
think
the
you're
on
to
something
with
the
especially
with
that
paper.
A
So
so
you
know
if
it,
if
it
turns
out,
we
can't
get
it
for
for
no
cost,
then
we'll
we'll
go
ahead
and
purchase
it
and
see
what
it
what
it
tells
us
and
it's
it's
talking
about
intentional
jamming
and
intentional
narrowband
jamming
is
a
big
deal
on
satellites.
It
happens
all
the
time
and
you
know
we
should
look
at
this
and
see
if
there's
anything
that
we
can
do
to
make
our
system
more
resilient.
B
A
A
Cool
okay,
I
can't
wait.
It's
going
to
be
really
looking
forward
to
it.
Well,
we'll
pitch
in
we'll
we'll
help.
However,
we
can,
because
I
think,
we've
got
some
good
diagrams
for
the
protocol
and
and
the
things
that
you're
bringing
to
the
to
the
project
are
excellent
and
yeah.
We
should
definitely
take
advantage
of
this
opportunity
to
get
it
in
front
of
a
lot
of
different
people
that
at
defcon
that
have
experience
and
expertise
here.
So
all
right.
Looking
forward
to
that.
B
So
plus
we
probably
want
to
be
able
to
control
the
power
on
the
uplinks.
If
somebody's
using
more
power
than
he
needs,
then
it
might
be
desirable
to
turn
that
down.
So
all
this
stuff
will
be
in
the
air
interface
once
it's
fully
written.
It's
not
not
authentication,
not
authorization,
but
it
might
be
access
or
one
of
the
other
a's.
Maybe
we
can
find
a
sixth
a,
but
this
will
be
it'll
be
in
there.