My name is Johan Pascal, I've been contributing on the LinFON project for the past 10 years,
more or less, and going to talk about the introduction of post-contempt cryptography
in the voice of our IP soft phone.
So quickly the agenda for some context, then we'll dive into the RTP protocol, and then
how we had to modify it to use post-contempt cryptography, and then a few words about
hybrid post-quantum and classic key exchange, and some conclusions.
So first some context for advertising for LinFON first, it's a project which is around
for now more than 20 years, it's available on lots of platforms, the idea that we have
like a common library, and then on top of that different application for different platforms.
It's tried to use at most SIP standards and everything standardized, IFC and so on, for
audio, video, instant messaging, we also provide secure group messaging, it's based on a derivative
of Signal Protocols that we presented years ago.
We also provide a SIP proxy, which is called Flexi SIP, also open source, everything is
open source, and encourage you to use our free service on SIP, which is SIP.linfon.org.
So basically I don't know if you are familiar with voice, but basically you have two streams
of data, first stream is a signaling path, which connects the endpoints together, and
then you have the media stream, which actually send data, video, audio encrypted, and this
one we enter into it.
So how it works, there is an IFC for that, and a protocol which is called SRTP, and SRTP
is Symmetric Encryption, so far we are not very concerned by quantum computers.
Main problem with that is that it requires an external command engine, so we have to
exchange our symmetric keys.
So for that we have three choices, the historical one is called SDS, so on this one the keys
are transmitted in the signaling path, which if the signaling path is protected, which
is normally the case by TLS, is okay, the only weakness is that the SIP proxy gets
access to the symmetric keys, so we are not actually end to end encrypted.
So basically the people running the service would decrypt your media stream.
So there is another one, which also gets an RFC, which is called DTLS SRTP, basically
on this one, on the media stream you perform a TLSN check, actually a DTLSN check because
it's over UDP, and this one works well, but you have to deploy a PKI and you have to
manage certificates for all of your clients and everything, so it's a bit heavy, and also
you still have to trust someone, you trust certificates, sure, but still.
And then there is another one that we favor, well all of three are available in the info,
but the last one is called the RTP, which is one we'll focus on this one today.
And this one on the media pass, you perform the RTP protocol, which is based on Diffie
Elman, which using electric curve or a simple Diffie Elman.
This one has no third party required, so which is good, the only small thing is that you
have to confirm, make some kind of spy thing that you have, tell secrets on the phone,
but as you are talking one with each other, it for the user and user is a bit an annoyance,
but you have to do it once in the call list, the world call history with your other endpoint.
So we think it's acceptable for users, obviously one has to get involved in security, but normally
it works, and the experience tells that people focus on security tends to not be driven away
by this small drawback on the protocol.
So it's an RTP which is now more than 10 years old, it has been mainly written by Filsie
Elman, the guy behind PGP, which are always focused on avoiding third parties.
And it's probably different properties, I won't explain the key continuity and stuff
because this one is unchanged, and I will focus on managing the middle attack detection.
So first a small reminder of what is Diffie Elman, so basically it's a protocol where
it's completely symmetric, one part, both parts will generate key pair, and then they
exchange public keys, and with this secret key and other side public keys will get to
share secret.
So far so good, it's kind of easy, on a drawback it's obviously vulnerable as many key exchange
protocol to manage middle attack.
So managing middle attack, what it is, it's basically someone putting ourself in the middle
and exchanging keys with both sides, so the side cannot know, basically Alice cannot
know that Eve is sending her key, she thinks that Bob is sending the key, and she performs
the exchange, and at the end what you get is that Alice gets a shared secret with Eve,
and Eve gets another shared secret with Bob, but Alice is convinced that she exchanged keys
with Bob, and she has no ways to actually detect this, well she has actually some ways,
no?
Yeah?
Okay.
No?
Yeah?
Sorry.
So the DRTPN check is, there is first phase of discovery, so what is happening is both
endpoints will exchange their capabilities, their choice of preferred algorithms, stuff
like this, and then start the actual DRTPN check.
So first you have one packet of commits, I will go into detail now, and then you actually
perform the DH, Diffie-Ellman exchange, so Alice is sending a public key, Bob is sending
his, and they both compute from this, they will compute the shared secret, and adding
all the transcripts of the communication, they will generate S0, which is the base secret,
the output of the DRTPN check.
From the S0, they will derive the SRTP keys, which is what we are trying to do now here,
and they also derive something called SAS, short authentication string, that will be
vocally compared over the phone, because we are, Alice and Bob are talking, actually talking
to each other.
So the end of the protocol is just some updates and writing in cash for key continuities mechanisms
and stuff, so it's not really interesting now, and then after that, the SRTP strings
start, actually, and they can talk, and once they start to talk, once in the call history,
they will do this vocally sus comparison, what it's for, this sus comparison is basically
if they want to detect a man in the middle attacks, they have to ensure that Alice is
using the keys that Bob has sent, and also Bob wants to know that the key that was sent
by Alice is the one he actually got.
So what they could do, as they are talking, is they could basically read their own keys
to the other, but the key is something which is a few hundred bytes, so it's a bit long
to read a few hundred bytes of the decimal chain over the phone, no one would do that.
So what they do instead, we derive this short authentication string which is only four digits
and has 20 bits, actually derived from 20 bits, and this sus is also derived from the
secret zero, which is the output of the protocol.
The only problem with that is that you can actually perform a sus collision with that
because the sus is very short, how it will work, so actually the beginning of the protocol,
as soon as Alice sent a public key to Bob, Bob is able to compute s zero because he has
his own secret key, and he is able to compute the sus then.
So what one could do is that if you perform first the RTP exchange with Alice, she got
the sus one, and then she received Bob's public key.
When she got Bob's public key, she can generate a huge set of key pairs until she finds a sus
that collides.
Basically she will try to generate a lot of pairs, sus is only 20 bits, so if you generate
one million keys and try to hold them, you will for sure find a collision on the sus.
So to prevent this, Eve is forced to send a commit packet.
In the commit packet what we have, we do not have our public key, but we have hash of the
public key, and so when you receive the hash of the public key, Alice will say for example
Bob's hash public key, she will store it, and then when Bob sends the public key, she
will compare, she will just hash Bob's public key, and she will compare, so that way she
is sure that Bob did not wait for receiving a public key and cannot generate millions
of key pairs to find a collision on the sus.
So this is quite effective, and so far so good.
Now we want to switch to using, to use post quantum cryptography.
The problem with post quantum is that on the next call for standardization, they required
all the algorithm to use key encapsulation mechanism, and not deferment.
So key encapsulation mechanism is a bit different, because the two sides are not the same.
In deferment, the two sides were exactly doing the same thing.
They are both generating keys, exchanging public keys, and then computing secrets.
There we have one side generating keys, one side encapsulating a key, a secret, and the
other side will be able to decapsulate the secrets that was encapsulated by the first
one.
So it's not symmetric, so we cannot switch directly from deferment to KM form of key exchange.
Obviously, KM is still vulnerable to man's middle attack, because nothing is changed.
You can still put someone in the middle and perform the exchange with the other side without
them knowing.
So what we have to do is adapt the RTP and change a little bit the actual handshake,
the central part of the protocol.
So S0 is still derived from the exchange secret and transcript of all the conversations.
I've got only commits and two packets, but you have also yellow packets and stuff.
So in the commit packet, the one which used to hold only the hash of the second packet
from Bob, Bob will now insert his public key.
Why would he do that?
So Alice can encapsulate the secret.
So at this point Alice receives the public key from Bob, she encapsulates the secret,
but at this point she's not able to compute S0 because she's missing the second packet
from Bob.
So she'll send back the ciphertext, so the output of the encapsulation, and at this point
she has the share secret from the key encapsulation, but she cannot compute S0.
Bob now retrieves the share secret, and he can compute S0, but he already committed on
DH part 2 that he has to send to Alice, so still he cannot manipulate the secret, the
final secret in S0.
And what's in this packet?
It's just a random number that is used once.
So now another problem is that we don't want to use, to focus only, of using only post
quantum algorithm, because we know that sometimes they got broken, like for example Psyche,
which was broken a bit late in the standardization process.
So it might happen or not in the future, so to protect against this weakness, its possible
weakness, we still want to use a mix of post quantum and a classic algorithm.
So we use both at the same time, and in order to not complexify the protocol too much, the
idea is to have one version of the protocol which is doing DFIRMAN, and the other one
key encapsulation mechanism.
And the protocol won't know exactly if it's using a mix or not, because probably in the
future, at some point we'll be confident in us with some post quantum algorithm, and
then we'll stop using the classical one, maybe or not.
But still the protocol should not be modified at this point.
So the protocol is done to use a carry a mental fast without even knowing if it is a mix of
classical and post quantum or just post quantum or several post quantum.
So we made, first we have to make a carry interface from DFIRMAN, this is quite a standard
construction, you generate, instead of, you can directly use the DFIRMAN construction
to generate a keeper, then you can send your public key to the other side, the other side
will encapsulate, how would the other side do that?
It would just generate a keeper for DFIRMAN, compute the DFIRMAN, and then hash it with
the transcript of the exchange, and send back its public key to the other side.
So the encapsulation is quite obvious, same thing on the other side.
And then we combine two or more occurrences together, so one we just built from a classical
DFIRMAN or electrical DFIRMAN, with a post quantum one.
So this way of doing it has been published by Nina Binder, a few years ago, so it's
a bit convoluted, but if you want more details on why we are doing this, I encourage you
to read the paper, it's quite interesting.
So basically what you do, you generate the keeper, you generate keeper for sets of algorithm,
in my example there, it's only two, but you can do more of that, and send concatenated
both public keys or all the public keys to the other side.
The encapsulation would just split your public keys to retrieve the individual ones, and
perform the encapsulations on all the components.
Then you use HMAC to combine your results, chaining it, so first you combine key one and
then key two, and you can add several layers there, and the final step is to use the transcript
of all the public keys you received, and the encapsulation is obviously completely symmetric.
The paper from Nina Binder is quite clear on why these steps are needed, I have no time
to explain it here.
Two more words, we also tweak the protocol packets, because in the D-Filman form, the
maximum size you can get is around a few hundred bytes, but if you start using Kyber, for example,
or HQC, the one you will use, you'll reach several kilobytes, and several kilobytes you
cannot send in one datagram over UDP, it's not possible, you probably won't arrive.
So what we have to add is a way of fragment the RTP packet, so it's kind of classical
way, just as DTLS is doing it, or other protocols using UDP, the only thing is that we made
it in a way that packets are not fragmented, and the header is modified, but if it's not
needed, the packet remains exactly the same as the old packet.
The objective in this was to be able to start deploying the new ration of the RTP, but still
keep compatibility with the old one, old deployment.
So how it's done, in the end, we use crypto libraries LibOQS, which is from the open quantum
safe project, which basically collects all the NIST candidates, and Kyber also, which
is a normal candidate, in a convenient way, and we use LibDecaf and embed TLS for the
ECDH and HASHMAC functions that we need.
So we packed it all in an independent module, so our RTP library will use this module, but
it's completely independent actually from it, so if anyone wants to directly use this
hybrid KM, mixing varieties of fast quantum and classic exchange, it's fully available.
You can combine it with more than two KMs, as it was printed, it's written in C++.
And in our RTP implementation, we deployed it with some already preset combination, so
we have X, well, we can see them, and we try to mix algorithms with more or less the same
level of security, so mixing the Kyber 5012 with X250, this one.
And it is, as I said before, fully compatible with the order version, so the deployment
is progressive.
It's basically in the agreement phase at the beginning, if most parties support this
version of the RTP with this algorithm, they will use it, if one is old and don't support
it, they will just fall back on classical Diffilman or electrical Diffilman.
So just how it looks like.
So first, you have the RTP and shake going, and the call is starting.
And once the call is started, if it's the first one, the two endpoints are calling each
other, you will get a pop-up that asks you to confirm the security string, so most parties
will just confirm it, if, well, they just say it on the phone, it's written like you
have to say this, the other one confirms, you said what it's expecting to say, and you
confirm it, then this will be saved in the RTP cage, and you will never be asked again
to do that.
During, at any time during the call, you can check on the call start and see what kind
of algorithm you use to perform the exchange.
So on this screenshot, you see that it was using Kiber 512 and X225519.
Here are some links, just if some of you download the presentation, so once a live
in-phone website, directly pointing to the GitLab where you can find the source code
of both the RTP and our post-quantum crypto module, and to the publication from Niana
Bindel explaining how to hybrid server curves.
Here we are, thank you for your attention.
So we've got time for questions, and I've got one question on metrics, and there is
a question, why post-quantum encryption is not enabled in the pre-compiled LinFone SDK?
Sorry, I didn't.
If, why the post-quantum encryption is not enabled in the pre-compiled LinFone SDK?
It is now.
It is now?
It is now.
Okay.
It is now.
Yeah.
Yes, sorry.
Hi, given that we're dealing with threat actors that might be capable of, you know, cracking
quantum cryptography, okay, given that we're dealing with threat actors that might have
a lot of resources, it seems like one particular attack vector might be to essentially use
real-time deep-pick technology to intercept the vocal assay-ass comparison.
Do you see any particular mitigation for an attack like that?
Well, some kind of attack like this has been already studied and published, so basically
what came out of what I found is that it's kind of easy to synthesize, to use speech
synthesizer to synthesize the voice of someone else.
The main problem there would be to insert the ass at the right moment in conversation
without adding a huge daily in the conversation so that people won't be able to talk, basically,
if you had like two to three second delays because you have to analyze the signal and
like buffer it to be able to insert back your ass.
People won't talk with three seconds, three to four second delays, there is no way people
will be able to keep talking.
I agree.
I think it's going to be very difficult to do something like that in real-time, but
I think that's probably, you know, because your solution looks really, really solid in
terms of being able to fix it like that, so it looks like that might be one of the weaker
aspects of it.
Yeah.
But since now I've been trying to monitor the publication on the subject and I never
found someone able to publish an actual attack on the RTP working really, so it might depend
on some point.
That's great.
Thank you.
Can we be quiet to a question, please?
Thank you.
I think I missed it, but then in this particular method that you are doing, is it actually
trusting the middle server that you're using, or is it using keys from another like a phone
or something, SIP, assuming, is this running with the SIP protocol you said?
I'm sorry.
I cannot.
Hello.
The sound is very low.
Hello.
Better has.
Yeah.
So I wanted to ask if this was being used with a mobile phone to connect to the SIP server
and then use post-quantum cryptography as you demonstrate.
Can you go back to the two slides before, please?
Yeah.
So the phone, is it actually trusting the server, which is running, or is it like the
end-to-end, the actual key is being checked with the other host?
Yeah.
This is the main point of the RTP, that basically the idea is to not trust anyone, not your
server.
The server will be in charge just of connecting the two phones, and then the media will go
directly from one to the other one.
The media pass will go straight from one phone to another one, and it won't go through the
server.
And that's why the RTP exchange is performed on the media pass and not on the SIP signaling
pass.
When you establish your connection, actually, you'll go through ICE protocol, I don't know
if you're familiar with that, which basically find a way to connect directly, because at
the end, you don't want the media to be relayed, because you lose too much time, you have to
send media packets directly from one endpoint to the other endpoint.
Hi.
You said that you have to compare the SAS only once.
Yeah.
Is it once per phone or once per user?
It's one endpoint, basically, in each endpoint, you have a cache of previous, each time you
end the RTP exchange, you'll keep some shared secret that you'll use the next time.
And so during the exchange, at some point, you will compare these shared secrets, and
if they're the same, you'll use them to compute a SAS, which is always a verb, and you can
always ask to compare the SAS, but it won't pop, because the protocol will know that you
performed the exchange before, but it's just one phone to another phone, this cache is
not shared.
Okay.
So in practical terms, if I buy a new phone and then install the same app with the same
account, I have to do it.
You have to do it again.
You have to do it again with all your correspondence.
Okay.
Thanks.
We've got time for our last question.
Is there any other last question?
If not, thank you for your call.
Thank you.