Linphone Instant Messaging Encryption
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 490 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/47323 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Extension (kinesiology)Communications protocolStandard deviationImplementationSession Initiation ProtocolEncryptionInformation securityIntegrated development environmentMultiplicationDisintegrationSource codeProxy serverLocal GroupAndroid (robot)VideoconferencingAuthenticationIdentity managementRatsche <Physik>Message passingMenu (computing)Open setGroup theoryWechselseitige InformationGroup actionLine (geometry)ImplementationKey (cryptography)Message passingServer (computing)RoutingEncryptionInformation securityMobile appSession Initiation ProtocolArchaeological field surveyComputer programmingNumeral (linguistics)Confidence intervalInsertion lossProduct (business)Self-organizationData conversionVideoconferencingStreaming mediaCryptographyPoint (geometry)Open sourceSystem callCommunications protocolInstant MessagingProxy serverMultiplicationOperator (mathematics)Metropolitan area networkFocus (optics)Presentation of a groupInternet service providerView (database)Projective planeFree groupStandard deviationLattice (order)SoftwareGoodness of fitLevel (video gaming)Instance (computer science)Link (knot theory)AuthenticationConnected space
06:55
MereologyElectronic signatureCommunications protocolPoint (geometry)Category of beingMultiplication signChainDoubling the cubeKey (cryptography)RootMessage passingField (computer science)Ratsche <Physik>Information managementWebsiteSet (mathematics)Computer animation
08:51
Communications protocolUniqueness quantificationServer (computing)Keyboard shortcutFunction (mathematics)Message passingLevel (video gaming)Communications protocolConnected spaceImplementationEquivalence relationCurveRoutingLibrary (computing)1 (number)Information securityDifferent (Kate Ryan album)Server (computing)
10:04
Session Initiation ProtocolTransport Layer SecurityLocal GroupMessage passingConnected spaceSession Initiation ProtocolKey (cryptography)Set (mathematics)RoutingProxy serverAddress spaceElectronic mailing listOnline chatServer (computing)BitMessage passingConfiguration spacePublic-key cryptographyComputer animation
12:36
Computer wormKey (cryptography)Message passingSpacetimeDoubling the cubeAlgorithmComputer animation
13:22
Information managementGroup theoryEncryptionElement (mathematics)Overhead (computing)Convex hullCommunications protocolCryptographyPeer-to-peerMaizeMaxima and minimaMessage passingMereologyServer (computing)VideoconferencingEncryptionMessage passingInformation managementDoubling the cubeNumbering schemeNumberRatsche <Physik>DigitizingQR codeAssociative propertyPublic-key cryptographyInheritance (object-oriented programming)Web browserKey (cryptography)Group actionInternet service providerFocus (optics)Function (mathematics)Metropolitan area networkAlgorithmInformation securityMultiplication signOrder (biology)Identity managementFingerprintCommunications protocolRevision controlSystem callPoint (geometry)Computer animation
20:44
AuthenticationCorrespondence (mathematics)String (computer science)Data storage deviceAttribute grammarComputer animation
21:24
Public-key cryptographyServer (computing)Key (cryptography)Numbering schemeIdentity managementMessage passingComputer animation
22:10
Table (information)Multiplication signBuildingGame controllerInterface (computing)Link (knot theory)Computer animation
22:52
Point cloudFacebookOpen sourceComputer animation
Transcript: English(auto-generated)
00:05
Okay, fine. So hi everyone, thank you for joining. So my name's Yuhan, I've been working on the Linform project for now eight years, mainly on everything regarding security encryption and this kind of stuff.
00:20
No, yes. So the agenda quickly will reuse security requirements to implement some things that we want, that means encrypting instant messaging. Then we'll have another view of the protocol we use. Then how it integrates with Linform, and at the end, we'll focus on the dreadful
00:41
man in the video attack. So a quick introduction, if you don't know, Linform is around since now, nearly 20 years. It is available on any kind of platform, Android, iOS, desktop, Windows, Mac Linux, and it uses SIP standards, so it's interoperable with other SIP phones,
01:02
to provide audio, video call, conferences, and messaging, instant messaging, always using SIP standards. Two years ago, Simon Mola made a presentation about how we integrated the SIP standards to make group chat messaging. It's available for the website, if you're interested.
01:21
You'll get more details on it. So Linform's team also provide FlexiSIP, which is a SIP proxy, which basically routing all the messages in the call operation. And also, you can use, if you want to try it, I encourage you to do that. You can use the free SIP service on Linform.org.
01:44
So what are the major security requirements for encrypting messaging? So first of all, we obviously need to protect our data. So we need to end-to-end encryption our content, which means encryption is done on the sending device, and decryption is done on the receiving device.
02:02
So the server operating the service is not shown to be able to decrypt your data. This is kind of basic. Then you also need to be able to know who is sending you a message, and to be sure that the message was actually intended for you, which is another point, because you can receive a message,
02:21
and someone pretends to be someone else. So this is another thing, another layer of security we want to add. And then there are two major features, which are, if you're okay, at some point your phone may be compromised, you want to be sure of two things. First, that if your past conversations were registered,
02:40
maybe like you are living in a dystopian future where some huge organization are registering all the data stream on the internet, hoping to decrypt them later. So if your phone is compromised, you want to be sure that your past conversations are still secure, they won't be able to decipher them. And so this is called forward security.
03:01
And then you have another property, which is called future security, which means that if your phone is compromised, you want to be sure that you will just lose confidence in few messages, and that if you continue your conversation with peers, it will get back on a safe level of encryption, but the attacker won't be able to decrypt them.
03:22
Okay? And then one last but major feature of a security protocol is that it has to be accessible for user. If user has to make efforts to use this, they won't use them. If it's too complicated, they just won't do it, and they won't use your product or your protocol, and then it's useless.
03:41
Oops, sorry. So we made the first attempt on that back in 2014, but which was working quite well as of for end-to-end encryption, authentication of user, but we had only forward security. We lacked a good feature on future security,
04:01
and most of it, it was not related to group chat messaging. Why? Because at that time, Linfone weren't preventing it. So we had to rework that, make something better, and a software quick survey decided to use the signal protocol that you may know, which is used by obviously the signal app, but also numerous other application,
04:22
like for example, WhatsApp is using it. Why we decided to use it? Because it had all the features we needed, most of them. It's very well documented, this protocol itself. You have an open source implementation that is freely available, and it has a lot of reviews,
04:41
as there are large deployments, so many people studied it, and no one found a flaw for now. So it's supposed to be safe. What we've done is we needed to, so the signal protocol is aimed to encrypt message from one device to one device.
05:01
It's not really good for encrypting on multiple device programs or group messaging. So we had to extend it, and also it's like an easy way to authenticate each other. So now for some simple scheme,
05:23
how it works basically in Relev. So we have two users with their device. We need a proxy to route messages and to manage accounts, and we also need a public key server, where we will publish some keys. So what we'll do first, Alice installs the app and creates an account.
05:41
When she does that, she will push on the public key server some public keys, while there are some details, I'll just skip that, but anyway. And then at some point, Bob wants to establish a session with Alice, but Alice may or may not be online. That's why she needed to push first our keys on the server. So Bob will ask the server for Alice keys,
06:03
server gives them. Bob then will create a line session, line is the acronym of link for instance messaging encryption, a session to talk with Alice, then encrypts the message. Send them to the proxy, which will then if Alice is online, or when Alice will come back online,
06:20
will route as a message, encrypted message to Alice, with some data enabling Alice to initialize the session. Okay. So Alice will create the session and decrypt the message. So far so good, it seems quite easy. And then she can answer back, and when she answers back, she doesn't need to contact the public key server,
06:41
because she already has a session ongoing with Bob. So now the public key server is out of the scheme, because we just needed to establish a first connection. Okay, so then the encrypted answer will just go through the same server, and that's it. So I thought I had 25 minutes,
07:00
so I plan to go deep into details on the signal protocol, which is quite complicated, interesting, but I don't have time for that at the end. So I'll just skip this slide, but basically you can find them on the website. Which is how, basically the protocol is in two parts. You have one part for establishing the session,
07:21
which is this one, basically it's a set of the field management signatures implemented, and then you have another part, which is encrypting the message. So the other part is slightly simpler. It's called double ratchet, double ratchet Y, because we have one symmetric ratchet, which is basically deriving keys, a chain of keys to get a message key,
07:44
which you use to encrypt the message. Watch, that would give us the property of forward secrecy, because basically if at some point someone has access to the chain key, it will never be able to get back on time and to find the previous one. So this is one ratchet, it's called double ratchet,
08:00
so we have another one, which is actually a Diffie-Man ratchet. So basically, each time you want to to exchange messages, you will have to create, to generate a new pair of keys, which then given a root key, which was given by the previous protocol, will help you to create the chain key to send messages.
08:22
And you will need then to give, to integrate into a message your public key, so then Alice will be able to decrypt it. And when she replies, she gives a new public key for, you get it, you make a new Diffie-Man ratchet, which gives you the key for decryption, and you make a new one,
08:41
which gives you the key for a new sending chain. Sounds complicated, but then it's not that much more. If you're interested, feel free to ask some questions later on, or read the documentation. All right, so what we've done, we've done an implementation of this library, because we are not really happy with the official signal ones. So our library is all in C++,
09:00
it's obviously available on our lead lab. One of the main differences of the main, that we have regarding the official signal library, is the protocol itself is designed to be used either with curve 259, or curve 448,
09:20
which are two levels of security, basically one is set to the same level of security of AES to 128 bits, while the other one is higher security level, which is the equivalent of AES to 256 bits. And so our implementation allows you to use either one. The implementation also,
09:40
even if it was driven to be integrated in Lint1, is aimed to be usable with anything. So there is nothing related really to Lint1 inside the library. Basically you can use it with anything which route messages provide unique identifier for devices. And you'll need also to manage a connection
10:01
to the key server. So how it integrates in Lint1? So we need, as I said before, device identification, so the Lint1 ecosystem is based on SIP. SIPs will give us user address, and through the group, which is an RFC defined,
10:22
we have a device address. So just one thing we needed. We need also the FlexCC proxy, we will manage these devices, manage the groups, the conferences, and route all the messages for us. And we need a secure connection to our different server, which is done using TLS and digested configuration.
10:40
So now for more accurate data flow. So let's say Alice and Bob, first they start with one device, because they want to try Lint1, they're all about it at first, they're thinking, wow, it's cool, let's try it. So they install it. When they install it, they register on the C proxy, and they also publish their set of public keys.
11:01
And now Bob wants to talk with Alice. So Bob will create a chat room, so he'll say that to the server, so C proxy, and C proxy will say, okay, I want to create a chat room with Alice and I. So the C proxy will answer with a list of devices which are in this chat room, which for now are only two.
11:21
And so Bob will say, okay, I don't have Alice one public key, so I have to ask them to the server. When she does, server answers the key, we get an encrypted message, and it sits. So now things are a bit more complicated, is that both Alice and Bob really likes Lint1, so they install them on several devices,
11:41
maybe their desktop, maybe their tablet, anything else, and they also convinced Carl to join their chat room. Okay, so we are Bob one, and Bob one for now, just as about Alice one, the other devices are not win. So we get back online, and the server will push him with some notice, he'll say, okay, in your chat room,
12:01
we have these new devices now, yes, you have to take an account. We say, okay, I want to send message to the chat room. I'm missing Alice two, Bob two, and Carl one devices public key. So he'll ask just this one, the missing one to the server if he got all the keys, he don't need to do this step.
12:21
Server answer, he sends the encrypted message, and then servers find out the encrypted message to everyone. So now how it works, because obviously the encrypted message is not the same for everyone, because everyone got his set of keys. How it works, it works that we got our payload, which is what we want to encrypt,
12:41
and we'll first randomly generate a key. This key will be used to encrypt the payload, so it gives us unencrypted payloads. So far so good. And now we'll encrypt the key using our double Rochester algorithm to everyone. Why would we do that? Because obviously the key is 32 bytes,
13:00
while the message might be several kilobytes, so we'll save a lot of space doing this kind of stuff. You'll see that our message includes the payload once, and then for Alice one, we have the key encrypted for. For Alice two, it says we have the key encrypted for, and what we need to initialize the session. Same for the other device, which are new.
13:23
This is received to the server, and the server will find out the message, but only the part that they really need, they actually need, to all the other device, okay? So now the other way to implement group chat would be to encrypt a key from the beginning,
13:45
sorry, would be to encrypt the key from the beginning, send it to all our peers, recipients in the group, and then derive from this key using a symmetric ratchet
14:01
for all new messages. So you will define what is called a sender key. So we'll say, okay, in this group, my sender key will be this one, I distribute it to everyone, but you will lose the future secrecy, which is given by the double Rochester algorithm. And this solution is actually used by Signal and WhatsApp.
14:23
But we prefer to implement this one, because we thought it gives you better security, and it also gives you a complete management of the group, because each time you send a message, you will know who will be able to decrypt it. While if you send your key, then your key may be passed to someone else,
14:42
and you will know. The other thing also, why we did it this way, is that the library, the encryption library, the LIME library, is completely independent of the group management in this way. So it seems easier to do it this way, so maybe someone want to reuse it, and want to apply the same scheme,
15:01
you can use something else. So obviously, the problem is that it won't handle massive groups, because each participant have an override of something like 100 byte, and you got to perform additional encryption, in the beginning, so on portable device,
15:20
you can go up to few hundred device in group. More than that, it'll start to be a bit slow. But on the desktop, you can use way larger groups. Okay, so now, for the conclusion, we will focus on the man in middle attack. So what is this man in middle attack?
15:41
Maybe you know it, maybe you don't. We'll go quick. So let's say that your service provider is not very friendly, and want to spy on you, or he's been compromised, attacked anyway, but I mean, the easiest consideration is to think that he's actually wanting to spy on you. So what you'll start with, same as usual,
16:00
Alice will publish the keys on server, then Bob will ask for the keys, but server won't reply with Alice keys, but with Eve's one, pretending they are Alice. Okay, so now Bob is encrypting his message, but he's not encrypting it for Alice, he's actually encrypting it for Eve, but you don't know that. So we can do that, send it to the server,
16:22
but server is Eve, so yes, you got the keys, so server will easily decrypt the message, then you can re-encrypt it using Alice's key, and send the message encrypted to Alice, pretending to be Bob, so Alice will get a message, and server will give the message, saying this is Bob sending you a message, here it is, so Alice will decrypt it, and she has no way to know that actually the server
16:42
did this dirty trick in the middle. So now you say, okay, what was all the fuzz? You're being saying since the beginning that this protocol is super cool, secure, and actually not, because it seems so easy to break it, because you just have to compromise the server, or be the server in the middle, and you can easily spy on your users.
17:01
Fortunately, this problem is very common in every public scheme, so people have thought about it. Oops, sorry. So what you need to do is you need to create an association between your public key and your device ID.
17:20
You need to be sure that if someone is sending you a message saying this is Bob, and this is my public key, you need to get a way to check that this is true. So let's, so I just quote the senior documentation in it, which really precise that if you don't do that, basically this whole protocol is crap, you have no guarantees that you are actually
17:40
talking to someone you think you are. So what is the solution implemented by senior or WhatsApp is basically you need to find a way to check that the key someone is using is actually his key. So we'll make, if you want to help me a quick survey, Wu here, raise your hand if you have WhatsApp on your phone.
18:01
I confess I do, don't be ashamed, I won't take names, okay? So it's not everyone, but still, some people are. Now Wu of this WhatsApp user knew that in WhatsApp you can tap your friend's name, then you got this browser profile, then you tap again on encryption, and you get to a scheme where you got a QR code
18:24
or a key fingerprint, which is basically 40 to 50 double digit numbers, and you're supposed to compare them, either by scanning the QR code of your friend with your phone, which means you have to meet physically, or you have to manage to call them and read them with this long list of numbers.
18:43
Anyone, raise your hand. So we are now three, okay, now four, yeah? Five, four, right? Now Wu actually did it, at least once. And now we are less, and now Wu actually did it with all his contacts, and Wu take, I mean, trace,
19:02
because WhatsApp won't tell you if you did it or not. You have to trace it yourself. You have to know, okay, this one is secure, this one is not. So basically no one, so no one is using this feature. So the whole protocol is actually, it's nice, well-designed, but it's not usable, really usable, you cannot be confident on the security of your WhatsApp messages,
19:20
even if it's written end-to-end encrypted. It's actually maybe end-to-end encrypted or not. So our solution for that problem was to leverage ZRTP. So ZRTP and a few others did it. So the same problem occurs for everything, and ZRTP is aimed to solve this problem for all your calls.
19:43
Basically, you're calling someone, at some point you have to agree on some keys, and so you have this key agreement protocol, and this key agreement protocol is sensitive to exactly the same attacks, the main and middle, which is the playing of all key agreement protocol. And what ZRTP does is basically doing the same thing like key fingerprint comparison, but the key fingerprint is only four characters,
20:01
which make it way easier. And so there is an RFC, obviously, on that. We implemented this in front for audio calls and video calls, basically. Whoop, one minute, okay, I'll be quick. The RFC lets you, let's say,
20:24
extend your main and middle detection to other data. So what we've done is that we integrated in our version of ZRTP the identity key of used for the messaging encryption
20:41
in order to associate them with the detection. So how it works, quickly, you make your call, you get an SDP invite. In your SDP invite, we use a custom attribute which gives you the key. Then when you reply, you got the SDP 200 OK, you will set your key. Then you compute this short authentication string
21:02
using both keys. At the end, your phone will tell you, okay, you have your correspondence saying you, these two characters, you say the same, and now everybody say the same thing, you're good, you accept, and your phone will store, so Alice will store Bob's key,
21:22
and Bob will store Alice's key. So now we're back with our evil scheme. We have reached the keys, then they make the call, and so Bob already has just the identity key, so we still need to ask for the other keys to establish the session. Server will enter with the public key.
21:43
Bob will try to create the LEM session, we say, oh, no, there is something wrong here because the key I have exchanged with Alice during our ZRTP session is not a good one. So you'll detect this with the attack. Obviously, if you do the other way around, you can also start exchanging messages
22:00
and then make a call, and at that point, he will also tell you that the messages you exchanged before were using the wrong key, so you'll be noticed. And what we add in the interface is that you can easily spot the status you have with your friends. Friends can be interested,
22:20
that means you are exchanging messages, but you never already checked the identity. Anyway, over, basically, sorry. Let's see, it's how it looks in Infone, actually. You have everything under control. Few links if you want to get deeper on it. Thank you, I have no time for questions, I guess, sorry.
22:44
Thanks a lot. Alas, we have no time for questions, but they do have a table in the K building in the RTC lounge, so feel free to drop by. And ask them anything.