 Welcome to the ROC3! Hello everyone. Welcome to the talk of Tobi Buchberger from FH Campus Wien. Here we'll talk about the special feature of TOX, a new kind of distributed instant messenger. Tobi will talk about the authenticated key exchange in TOX and how to do it right and secure. If you have any questions on the TOX, please click on the chat tab below the video and leave us a message. Thank you. Hello, welcome to Tobi here. Yeah, welcome everybody to my talk about adopting the noise key exchange in TOX. In this talk I will present the results of my master thesis which I conducted this year also on FH Campus Wien. Yeah, and I will start by shortly explaining what is TOX. TOX is a peer-to-peer messaging protocol and a free and open source library implementation thereof. This protocol provides features like instant messaging, voice calls, readers calls, screen and screen oil byshadowing. The development of TOX started in 2013 as a reaction to Snowden's leaks regarding the NSA's mass surveillance of the internet and is intended as an entrant encrypted distributed Skype replacement and to avoid confusion a short intro to the terminology in the context of TOX. So there is TOX, which is the name of the protocol in general. Then there is the implementation of the TOX protocol, which is called TOXCOR. This is a network library written in C and the clients. So the actual check lines that use TOXCOR have specific names like UDOC for example. So then a few more details on TOX. It is based on a cryptographic network library from Daniel J. Bernstein, which is called SOLT. And the protocol consists of multiple modules. And the module which is relevant for this talk is the net crypto module where the handshake is implemented. But there are other modules like distributed hash table module and the general crypto module and so on. The cryptographic primitives that are used in TOX are the X25-519-DV-Helman function for the key exchange, the XSR20 stream cipher for symmetric encryption and PULI-1305 for authentication. Then there is a distributed hash table, which is used to store peer information. And to add a friend in TOX, you need this user's TOXAT. And this TOXAT includes the static long-term public key of this user. So why am I doing this talk? Because there is a problem in the TOX handshake. And for TOX to establish an entrant encrypted communications channel, there is something that is called an authenticated key exchange. And authenticated key exchanges are protocols to set up a shared secret key for a communication session. This enables two parties to communicate securely over an untrusted public network like the internet. And such protocols are, for example, based on asymmetric cryptography like DVHelman. And the problem in TOX authenticated key exchange is that users are possibly affected by a so-called key compromise impersonation vulnerability. This vulnerability is in the TOX handshake because it is a home-brewed cryptographic protocol. And shortly, what does KCI mean? So key compromise impersonation enables reverse impersonation if a static long-term private key of a user is stolen. So if an attacker stole the private key of a user, it is trivial to impersonate this user. Because in TOX, if you stole the key of someone, you are more or less dispersing in TOX. And so you can start up a TOX client using the key and you are dispersing. But with KCI, it gets even worse because an attacker can also impersonate other people to you. So he can impersonate your TOX friends to you. So he uses your key and you then think you're talking to a friend of yours, but actually you're talking to someone else. So this KCI vulnerability can also be used to mount many of the middle attacks. The vulnerability was reported by Jason Donofeld in 2017, where Jason Donofeld is the creator of the WireGuard VPN. So to understand what this KCI issue is about, I will shortly explain how the TOX handshake looks like. So in the TOX handshake, there is an initiator, which is called Alice, and a responder, which is called Bob. And in fact, both peers can be initiated and responded at the same time. But to simplify this explanation, I will assume that only one peer is initiated. So at the beginning of the TOX handshake, there is a cookie face, which is in place to mitigate some kind of denial of service attacks. Then there is an authenticated gear exchange phase, which is in place to establish a secret key to encrypt the packets afterwards. And in the end, then there is a transport phase where just encrypted packets or messages or audio packets, etc., are exchanged. So during such a TOX handshake to establish this encrypted communications channel, there are in total three X2519 key pairs involved. There is a key pair necessary for the cookie phase of the handshake, which is a distributed hash table keeper. Then there is a static long-term keeper used during the authenticated key exchange. So this public key is the one that's also included in the TOX setting. And then there is an ephemeral keeper used, which is then there to establish this session secret key. And to use this key afterwards by using symmetric cryptography. And symmetric cryptography in TOX is established by using X20 polyethylene file. So let's shortly take a look at the authenticated key exchange phase of the TOX handshake. So as I said, both peers that want to perform such a handshake need to own a static long-term keeper, which identifies them. And a ephemeral keeper to establish the session secret. And the PRLIS is the initiate of the handshake. And PRBOP, which is abbreviated as B, is the responder to the handshake. And it starts like that. Alice sends the handshake message to POP. This handshake message is encrypted by using a shared secret, which is based on the static long-term keys, the private key of Alice and the public key of POP. This key is then used to encrypt the ephemeral public key from Alice for this session. Then POP does the same by responding with a handshake message to Alice. And POP uses his static private key and the public key from Alice and encrypts his ephemeral public key. After both peers successfully receive the handshake message of the other peer, we can use the electric curve differential operation to calculate the same shared secret session key. Alice by using her ephemeral private key, or by using his ephemeral private key, and by using the ephemeral public key from the other peer. So what does this authenticated key exchange provide for security? This authenticated key exchange as it is currently provides forward secrecy. It also provides mutual authentication, which means that both parties get authenticated during the handshake. Also, it provides key confirmation, which means that both peers prove the possession of the secret key. And it also provides deniability, which means that POP users can deny having taken part in a specific communication session because the communications are authenticated but not signed. But as I said, it provides no KCI resistance, therefore it is vulnerable to KCI attacks. So I will show you now how a simplified KCI attack works. To perform such a KCI attack, there needs to be a few prerequisites met. So our setting is that the attacker, which is called Mallory, abbreviated with M, impersonates POP to Alice. To do so, it is necessary that POP is a POP's friend of Alice. And then the attacker, Mallory, needs to compromise the static long-term private key from Alice. He also needs to know the static long-term public key from POP, for example, by knowing his toxicity. And he also needs to generate an ephemeral text 25.519 key pair. So to perform such an attack, it works like this. So in this case, the attacker, Mallory, is sending a handshake message to Alice and he does so by using the same shared secret that Alice would generate by using Alice's private key and POP's public key. With this, he can encrypt his ephemeral public key. Then Alice will think she received a handshake message from POP and will answer the handshake message with the same shared secret. Also can connect it with the same private key and the same public key as the attacker and encrypting their ephemeral public key. And in the end, the attacker and Alice are both able to direct the same session key by again using the exchanged public keys from the other and their private key. So, but during my research, I found out that the... So as I said, this really can be used to amount a minute to middle attack on a tox session. But during my research, I found out that the DHT key pairs involved in the cookie face of the handshake make an actual KCI attack on the tox handshake more complicated. This is because of this cookie face. The attacker's malware is not able to send a cookie response packet on their own, which means that it is necessary that Alice and POP need to be on at the same time and initiate a handshake on their own. So the attacker is not able to initiate a handshake on his own as I showed you on the slide before. And if Alice and POP initiate the handshake, then the attacker malware needs to interfere with the handshake packets after the cookie face. He does so by intercepting the handshake packet from Alice. This handshake packet contains enough information to send valid handshake packets to both peers. Then the attacker performs a handshake with Alice and POP separately and establishes two connections. And therefore, he also needs even more key pairs for both connections. And if this was successful, then the attacker is now able to eavesdrop, modify, insert or drop messages, which are exchanged between Alice and POP. And Alice and POP just think they are just talking to each other like normally. So as people don't like just to hear about theoretical vulnerabilities and also want to see actual exploit of these vulnerabilities, I tried to implement such a minute and middle attack program. But I discovered a few more difficult things for this attack because if the attacker is using Alice's private key to start the TOX core instance, like TOX is designed, this TOX core instance from the attacker would announce itself in the distributed hash table. So if Alice and the attacker use the same private key at the same time, this would mess up the state in the distributed hash table. And I didn't find out if it's possible to start the TOX core instance without announcing the distributed hash table because this would require more detailed understanding of the DHT module and I didn't have time to look at this in detail during my thesis. So this may, maybe there is a solution to this problem, but if not, this attack may not be possible at all to exploit in practice. Additionally, it would be necessary to adapt TOX to further to be able to use the handshake information from my peer in one handshake with another peer. So if I intercept as a table the packet from Alice, I need to use the information from Alice's handshake packet in the connection with Bob. And there would also be needed to implement a way to pass messages between two TOX connections because otherwise the attacker would need to paste their messages manually. Overall, this means that a complete redesign of the TOX category would be necessary to possibly make this attack available, which means that unfortunately I cannot show you a POC attack, but I will show you a proof of concept of the KCI resistant TOX handshake implementation. So how did I fix the KCI vulnerability in the TOX handshake? There is a framework which is called NOISE. This framework can be used to create so-called secure channel protocols based on DfM and key agreement. A secure channel protocol is for example SSL or TLS or SSH. This framework was created by Trevor Perrin, who is the co-author of the signal protocol. So from the signal messenger, this framework provides formally verified authenticated key exchange constructions, which are also designed to protect against this KCI vulnerability. The framework is there so that developers do not roll their own crypto and just use the formally verified construction from NOISE instead. Crypto protocols based on this NOISE framework are already used in, for example, the WireGuard VPN. It's also used in WhatsApp for client-to-server communication, and it's also used in Slack, for example, for internal server communication. I didn't implement the NOISE framework myself, but instead I used the available open source library, which is called NOISE C. And then this is just the implementation of the NOISE framework, which was implemented by Bruce Wendley. So, shortly an introduction to the NOISE protocol framework. In the crypto protocol based on NOISE, the parties involved have either long-stem static DfM and key pairs, and or ephemeral DfM and key pairs. Every NOISE protocol starts with two parties exchanging handshake messages. There are different handshake patterns available in the NOISE framework. These define which DfM and public keys are exchanged and a sequence of DfM operations which is performed. The results of these DfM operations get hashed into their secret keys, which are used later to send encrypted transfer messages. And the handshake messages which are exchanged in the NOISE protocol can already contain encrypted application chosen payloads. And such a NOISE handshake pattern is instantiated by a specific DfM functions, cyber functions and hash functions to give a concrete NOISE protocol. And in the NOISE specification, there is defined which cryptographic derivatives are available. So how does a NOISE protocol for TOX look like? So as I already mentioned, there are these public keys which are exchanged using the TOX IDs in advance. So TOX users friend each other. So these are exchanged out of the band, for example via email. The matching NOISE pattern for this is called KAK. But I discovered that in the actual TOX core implementation, the responder of a TOX connection receives the public key of the initiator from the initiator's handshake packet. So therefore this is not compatible with the KAK pattern because to be able to receive a NOISE-based handshake message, it is necessary to initialize a handshake state beforehand with both pure static non-term keys. But yeah, so currently the TOX handshake is incompatible with the KAK pattern, but it may be possible to use the KAK pattern by redesigning a little bit and let's flip the structure a little bit. So I didn't want to do that yet. Therefore my solution was to use the so-called IK handshake pattern. This handshake pattern requires that the initiator senses static public key already encrypted in the handshake message. For a security point of view, it doesn't make a difference if I use the KAK or the IK pattern because they both provide the same security properties including the KCA resistance. So we'll try to show you how such handshake pattern works like in NOISE. So there is a pre-message from the responder to the initiator where he sent his static public key. Then this is the delimiter for the active exchanged handshake messages. And then the first message is sent by the initiator. This includes the initiator's ephemeral public key, then already development operation which already gives us a secret key. So I used to encrypt the initiator's static public key and then there is another development operation performed. Then the responder was presiding his ephemeral public key performing and performing two additional development operations which are all into the same shared secret key. And this is the handshake pattern and the full noise protocol that is used in TOGST is shown here. So this string just tells us that the NOISE IK pattern is used, that the X25-519 D.V. Hammond function is used, then charge 20 is used as stream cypher for symmetric encryption, there is poly-325 used for authentication and the charge 512-512 function. This noise protocol provides zero runtime encryption which means that in the handshake messages there are already encrypted payloads. But you need to be aware of that the security properties for the handshake payloads are weaker than for the transport payloads. The egg phase is 1.5 roundtrip time because so this would be one roundtrip which means that one message from the initiator and one from the responder. But the egg phase is 1.5 roundtrip time because the responder needs to receive the first transport message from the initiator to be assured of forward secrecy. And then the result of a handshake based on this noise protocol are two so-called cypher state objects and the cypher state objects contain key used for symmetric encryption and the corresponding nodes. This is for the symmetric encryption. So how does this noise protocol fit in the talk's handshake? As I mentioned, there are three phases and the first phase, the cookie phase remains unchanged in this noise-based handshake. And as you may already noticed the handshake payload encryption uses Charger 20 instead of Excelsior 20 which is used in other places in talks. This is because Excelsior 20 is not supported by the noise framework. Then in the transport phase there are two symmetric keys used instead of one because there is one key for encrypting packets to send them to the other peer and one key for decrypting packets received by the other peer. And so this noise-based handshake using this noise protocol is now a formally verified construction instead of a home protocol like before. And I implemented this noise protocol in the talk score in two different approaches. In my first approach I used Charger 20 for encryption during the handshake and also during the transport phase. In the second approach I used Charger 20 during the handshake phase and then Excelsior 20 during the transport phase. And I will now shortly explain why there are these two different approaches. In the Charger 20-based approach I just adapted the existing functions in talk score for the handshake to the new handshake and this was possible by only adding one new function and only adapt the existing functions. The handshake packets look now slightly different because the firmware public keys are sent unencrypted and the initiative is to include his encrypted static long-term key. You may remember from the slides before that in the old vulnerable handshake the firmware public keys were sent encrypted and it was not necessary for the initiator to include his encrypted static long-term key. Also, I didn't include a base nonce in the handshake packets because the nonces are now handled in this cypher state object by the noise stealer. And I adapted the functions in talk score which I used to encrypt and decubed messages to use noise c functions based on Charger 20 instead of the XS20 base functions with Charger talk score. So then I finished this implementation then I needed to test it. I did this by building my modified version of talk score together with midi-talks which is a minible talk client and together with noise c. Then I started multiple midi-talks instances on the DB and VMware and then I added these midi-talks instances as friends and tested packet loss between these instances by using predicate. And then I discovered that this implementation solution works only if there are no encrypted packets lost which is most likely to happen with a UDB based protocol. This is because the nonces are saved in the cypher state and if a packet is lost and the next packet is received then the wrong nonce will be used for encryption and therefore the nonce is for descent and for the perceived error out of sync which means that the decryption will not be possible. So the solution to this problem could be that the nonce could be sent together with an encrypted message and after receiving sets this nonce in the cypher state which is providing a function which is provided by an OSC but I discovered that the OSC library is not compliant with the null specification in this case. This is because the nonce needs to be greater or equal than the current nonce in the cypher state but this is not always the case if packets are received out of order. Also, if I would do this I would need to implement the packet loss functionality but there is already a packet loss functionality in Dockscar implemented which is based on XS220 which leads me to my second implementation approach. This implementation approach uses XS220 during the transport phase and is a solution to this packet loss problem from my first implementation because as I already mentioned XS220 is not supported by the null framework to circumvent this I added two functions to the OSC library to be able to retrieve the symmetric keys after a successful handshake instead of these cypher state objects then I can use these symmetric keys with the existing XS220.0755 encryption functions and these functions are also using then the existing packet loss and out of order packet functionality in Dockscar. This means that I need to include the base nonces again in the handshake packets as it is the case in the KCA everywhere handshake. I finished this implementation I tested it again by using Minitox and Playkinnet and now I discovered that the handshakes are also successful if there are up to 50% packets loss on both sides of the connection and also discovered that compared it to a normal handshake so a non-noise based handshake and I discovered that if more than 50% packet loss is too much for the Dockscar protocol in general to establish a stable connection. So my work is not finished here there is still some work to do in the future for example I could work or I could continue working on the PUC attack program but with the difficulties I mentioned I most likely think that this vulnerability cannot be exploited in the wild there are a few other things I could work on as I mentioned in the noise based handshake it's a noise will differentiate between an initiate and a responder but as I said in the Dockscar protocol as it is designed both peers can be initiated and responded at the same time so this is not ideal in the current implementation and could lead to practical problems which means that the handshake could take longer than an old KCI protocol handshake and also the error handling during the handshake implementation is further testing at review as I said the noise based handshake I implemented using the noise seal algorithm where the noise seal algorithm implements the whole noise framework and therefore supports all handshake patterns and cryptographic primitives but there is not everything necessary for the usage in Dockscar therefore we could implement the noise AK pattern explicitly for the use in Dockscar then we would have no noise seal algorithm as a dependency for Dockscar and in general less lines of code which means less possible vulnerable lines of code further future work could be a redesign of the Dockscar handshake as I said the current proof of constant implementation of the noise based handshake uses two different ciphers for symmetric encryption judge the 22nd handshake and access the 23rd transport phase this could maybe streamline to only use one of these two ciphers also my noise based handshake is currently not backwards compatible which means that clients using a Dockscar version with the vulnerable handshake would not be able to establish a connection to the noise based handshake Dockscar instances and when we already redesigned the Dockscar handshake we could maybe change the implementation to use the KK pattern instead of the IK pattern there is also some other interesting functionality which noise could provide noise enables session rig key which means that the key used to a far symmetric encryption could be updated after a defined number of messages also it is possible with noise to add quantum resistance by using an optional 256-bit pre-shared key this is for example already implemented in the wire guard window and besides the handshake it would be nice to conduct a full security analysis of the protocol and also of its implementation Dockscar because this wasn't done until now so if you want to have additional information there is the link to my full master's thesis right before my talk there was an introduction to Dockscar from Enceli from Q-Tux then there is also a Dockscrypt part here which is organized by SOF and in general for further information you can visit us at our assembly and and order on the 3.ioc channel this is just a few related work these are the references that I used during the talk and I thank you for your attention and special thanks to frankonin.net and the Hackerspace Bumpback for hosting the talk and now I open the questions Thanks a lot Tobi Buchberger for your talk if you have any questions on this talk please use the addresses you see if you press the chat tab below the video then you can send us a question there are no questions by now but I have a personal question Tobi why is it called noise protocol what is the noise in this protocol any idea about this to be honest I don't know actually where the noise is coming from or if I I already forgot it ok ok so maybe in such sophisticated talks people maybe have to think a bit about all this information you gave us because we have no questions so far but again thanks a lot for your talk and hope to see you again oh one question from the IRC channel please wait a second oh there's somebody on the IRC channel asking about getting backwards compatibility by using a cookie which would indicate which kind of handshake the responder expects yes we already thought about ok so this is a problem that can be solved here ok ok and another question from the IRC channel is coming in but somebody making a joke is there a COVID-19 friendly way alternative to avoid handshakes between users but ok but this is just a joke I think so COVID-19 is not a problem of using talks I think even if talks sounds a little bit toxic ok so no more questions I see Tobi thanks again for having your talk here with us and have a good day and see you again bye bye