okay do you hear me the drugging okay
great so welcome to my talk I'm Dominic
and this is joint work with two of my
brightest master students Fabien and
Gregoire and yes we are looking into
that ATP it's a quite an old standard
box tool it's used so we got a nice
response from one of the authors of the
standard on Twitter and yeah he's
wondering if we can can learn something
so let's learn something here um let's
look at the current status of end-to-end
security and voice calls so keep in mind
end-to-end security not just client - -
cloud provider so public switch
telephone network what we have is not
enter and secured pretty obvious then we
have the session initiation protocol and
like RTP and SFTP it's also not
end-to-end secure by design okay let's
go on then we have something that's
called DTLS at the Datagram transport
layer security used to exchange a secret
for smtp that's end-to-end encryption
and then we have end-to-end encryption
and authentication that zip plus SATP
plus let ftp and obviously for an evil
operator it gets more difficult down the
line so we are looking into this space
so um first I wanted to introduce like
what we did in the beginning so if we
just have slipped with encryption olney
or on or no encryption there is a
similar setup like this this is a pretty
simplified view with just one tip server
but to get the point across
yes Alice and Bob they're doing a call
they're using a sip server and if you
are an evil operator
you can do some men in the middle here
from East dropping it's very very simple
we did an implementation for the server
Camarillo and so we just rewriting some
headers in the session initiation and
redirecting the caller from Ella's to
the special client that is running on
the server for example the special
client takes the call thus its own call
to Bob and then connect those multimedia
streams and you get your eavesdropping
or via typing so very very simple it
works are on Bob side is it says ellos
and ellas at example.com
so how to protect against this this is
that Ltd the same setup are what the
users are seeing is a little bit
different there is something that is
called and short of indication string
here it's pretty small here story so
it's just four characters that is shown
on the screen and on the other side also
four characters shown on the screen and
Alice involved need to compare these
strings and when they're different there
is an attack so they are different there
is an attack here this is how the ITP
works from your user user's perspective
okay what are we doing now so that a DB
is a pretty complex protocol in my
opinion and it basically boils down to
in a DC Hellman key exchange there's
authenticated using these short of a
negating strings to keep this string
short as the name suggests they are
doing a hash commitment to constrain the
tecar to just one try for call in this
paper we are doing a real world
a relation of real world implementations
and we are explicitly not looking into
closed networks we are excluding attacks
where the you assume that the attacker
do stuff some speechless entities we are
not doing this we assume that the short
authentication strings have been
compared correctly okay so in the paper
we looked into the following
implementations there is a cure with
soft form for IRSC sip simple for
Android there's jitsi it's a
cross-platform client we have lint sound
and we have signal so in in the paper we
are certain protocol tests and for non
protocol test and in the presentation I
will just show the interesting results
and skip the rest
okay so let's dive deep down into that
FTP this is an extremely simplified view
of that ATT so there see is much longer
so if you if you look into it there is a
on the left side we have the responder
on the right side the initiator they're
exchanging some hello messages and
random values that's not that important
what is important you can you can find
the diffie-hellman here so P VI is the
public value for diffie-hellman on the
initiator slide that's up there then we
have PV err it's the responder is public
value and obviously they are doing a
difficult key exchange so this is like
the shared secret we get all of this on
the initiators side and this is the one
on the responder side so what's the
trick here arm it's not sink it's not
yeah it's not doing this at the same
time they are doing a hash commitment so
instead of directly are transmitting the
public value or the initiator is
transmitting a hash of the publicly so
you're kind of committing to the public
value without revealing it over the
network and this kind of constraints the
attacker to just won't try in the
beginning so we don't have like an
offline brute-force attack of edom
instead we have an online attack of is
just one file and in the end the
shortest indication string is kind of a
key duration of the shared secret the
IDS of responder and initiator and the
hash of all messages okay so first thing
you need to notice you need this check
so it's the hash that has been committed
previously really the hash of the public
value that you received so this is one
of our test it's very obvious test and
there's one implementation failing it so
Lin phone didn't check this so we don't
have to be constrained to one try taker
in
we have well I can not unlimited but we
haven't attacker is much more ruthless
capabilities and we implemented that and
yeah it works so there are two kind of
representations of the short
authentication string one for 16-bit and
one for 20 bits that's shown here and
yeah
not many tries or needed to crack this
obviously this has been fixed and in
phone okay so next attack so if you do
this if you Hellman key exchange will
set FTP and you press the confirm button
that you're short authentication string
is the right one
let it be stores this inside a cache so
the next time you do a call to the same
person you no longer need to compare
short authentication strings because you
did in the first call this is stored
inside the cache and next time they just
use what is inside the cache duty
duration on it so it's like similar -
yeah like self-healing properties okay
so um there is a special scenario here
what is also written in the error see I
just read result if either party can't
discovers the cache mismatch the user
agent who must who makes this discovery
must treat this as a possible security
then and must alert their own you know
that there is a heightened risk of an
end until attack so this means if I do
LS does call - both are the dish secret
is safe second call to Bob on and Alice
looks into the cache and there is there
is a cache miss mesh so this doesn't fit
to the one that is used by Bob then
there is maybe a security incident here
and there is security warning in jitsi
this is displayed here and expected
retain shared secret is missing I don't
think anybody and user would understand
what is saying here but they implemented
it at least it's a must in diversity
so I think it's a questionable
requirement because n Jesus maybe just
dismiss it t sub simple and then phone
do not implement this and while checking
this out we found a bug in GT so
actually they not just show this on a
case in mismatch they also show this if
there is just one entry inside the cache
and they're creating a second entry they
also show the flag because yeah there
was one missing initiation of an object
here so we fixed it so the security
warning was raised for other
participants new clients of Bob so and
nobody complained sue
okay let's just so lots of tech I won't
present in the presentation that's what
we call the shared men in the middle
attack so let's consider the following
like LS bought and Eve are friends they
know each other they talk a lot on phone
so an elephant is to a normal phone call
they both confirm the shot of engagement
ring
the shared secret is stored inside the
cache on both sides so very nice second
time they don't need to confirm the
short vacation string then there is a
call between Ethan Bob same thing
happens
they both confirm the SAS everything is
correct nice second call no need to
check SAS and the third step arm
each is no evil
he was conducting a man-in-the-middle
attack like we showed in the beginning
like an evil operator and it's just
placing herself in the middle between
elephant Bob and yeah actually it works
because there are shared secrets between
elephant decent with leaves and Bob
so no SAS confirmation required
everything works and also the zip
address is shown on the on Ellis own
shows Bob at example.com anon box shown
so what is missing here I mean very
obvious attack why does this work so in
that edit II there is no binding of the
identity is used in 1080p to the order
protocol so they explicitly designed the
TTP to work independently of the session
protocol so the the cache look up just
uses the Zetas TP ID which is just a
random ID it's not a good address so
this just works um so in signal there is
no cash
you cannot confirm it so the secure
accurate softphone they actually
implement the RFC compliant protection
again there are C knows about this
somehow and you can actually enter a
string for the participants and that is
stored beside the Zetas TP ID inside the
cache and if you do a second call this
is like this it address its LS and this
is the z TP
ID so there is a mismatch here but I
mean the user needs to see this right
it's even I mean I don't think you I say
if it would do usability study I'm not
sure people will even get why they need
to enter a name here so and the other
implementations are insecure there is no
way to to see which set a TP ID is used
okay I have some time left right that's
good so I will do a short quiz ok
security indicators let also nice topic
we just look briefly at security
indicators and applications we did no
user study but just we will do now a
short you the study with you ok so what
is n 2 n TQ left or right who's for left
who's for right ok maybe through let's
first left left-hander and up for left
ok right ok
okay this was easy the students enter
into cute if the green lock I can write
this is this is an open locks about it's
red so okay that that is easy
here's GT by the way okay this is more
difficult okay which one is entering
secure who is for left with four eyes
okay a yeah you can see there is a cross
inside the lock right on the top so this
is insecure this is I mean even there is
a green icon but that doesn't have to do
anything with security so just the lock
I mean it's a closed lock with the cross
I don't know okay last one what is the
key what is insecure
who's for left who's for right okay what
about this yes we will also quite
confused and we couldn't really
reproduce this but but we we asked the
support about this and actually this
says dead now it comes the following so
we have that ATP for the voice
communication and for the video it's
clear it's not encrypted but there is no
voice there is no like long click or
information what is for what and yes
it's really confusing okay so that's it
come to my conclusion current status Lin
phone has been fixed the back in GT we
fix directly upstream that's what was
very very easy signal long longer uses
at ATP this is an independent decision
of Moxie knob there's not not the
influence for our research it's been
done in parallel and yen for the future
yeah most apps fall back to insecure
mode if the data P say it and if you
think about the security indicators I
don't think you will notice Chapman in
the middle tags needs to be discussed
and that's it thanks
[Applause]