[DRAFT] Toxcore Threat Model

[SkyzohKey]

Issue by GrayHatter
25 Oct 2016 at 22:26 UTC+2
Originally opened as TokTok/c-toxcore#210

---

Attacker goal	Security property	How ToxCore deals with that?
Compromise messages	Confidentiality of messages	Messages encryption provided by NaCl.
Alter sent messages	Integrity of messages	Provided by NaCl, if the message is altered in anyway, decryption will fail, and the message will be dropped.
Inject false messages	Authenticity of messages	NaCl provides authentication via crypto_box (poly1305).
Identify as another person	Authentication of communication partner	Once Identity is established through Long Term Public Keys, Communication will only be established with that keypair. (Side
Block communication	Availability of communications	P2P connections, and Nat Hole punching makes Tox censor resistant but not completely unblockable.
Learn communication metadata	Privacy protection	Toxcore doesn't leak personal metadata above IP:Ports, but makes no attempt to obfuscate it's data usage profile.
Prove what was said	Deniability of message content	NaCl crypto_box provides deniablity
Prove that two persons communicated	Deniability of the conversation	Unknown
Learn past communication after compromise	Forward secrecy	Forward Secrecy from instance to instance (instances can last years).
Prolong a successful attack	Future secrecy	Unknown

[SkyzohKey]

Comment by SkyzohKey
27 Oct 2016 at 14:09 UTC+2

---

@GrayHatter could you elaborate on the main objectives that this threat model should defines, and why ? Would be easier if someone wish to write something like that :)

[SkyzohKey]

Comment by GrayHatter
4 Nov 2016 at 10:46 UTC+1

---

@SkyzohKey this is a good start for a threat model https://conversations.im/omemo/audit.pdf

[SkyzohKey]

Comment by SkyzohKey
6 Nov 2016 at 12:24 UTC+1

---

I think we first needs to define why an attacker would attack the network (profit, data leaks, etc) and then define the potential target of that attack. Next to that we have to list if every potential target has any kind of protection from the toxcore point and if not, push some code to fix.

This is a tentative list and I'm probably missing points, but that's a start. Nb: I'll use the same conventions as OMEMO's pdf here to gain time, as we share some points with it.

Attacker goal	Security property	How ToxCore deals with that?
Compromise messages	Confidentiality of messages	Messages encryption.
Alter sent messages	Integrity of messages	AFAIK it doesn't.
Inject false messages	Authenticity of messages	It doesn't, integrity check related.
Identify as another person	Authentication of communication partner	It doesn't. If .tox/secret key gets stolen, user can be impersonated. (#426)
Block communication	Availability of communications	P2P network.
Learn communication metadata	Privacy protection	AFAIK it does leak metadata.
Prove what was said	Deniability of message content	It doesn't + clients keeps unencrypted logs.
Prove that two persons communicated	Deniability of the conversation	It doesn't.
Learn past communication after compromise	Forward secrecy	AFAIK it doesn't.
Prolong a successful attack	Future secrecy	AFAIK it doesn't.

[SkyzohKey]

Comment by GrayHatter
6 Nov 2016 at 21:24 UTC+1

---

I've added the threat model @SkyzohKey generated with some fixes to the first post, and that version here as well.

Attacker goal	Security property	How ToxCore deals with that?
Compromise messages	Confidentiality of messages	Messages encryption provided by NaCl.
Alter sent messages	Integrity of messages	Provided by NaCl, if the message is altered in anyway, decryption will fail, and the message will be dropped.
Inject false messages	Authenticity of messages	NaCl provides authentication via crypto_box (poly1305).
Identify as another person	Authentication of communication partner	Once Identity is established through Long Term Public Keys, Communication will only be established with that keypair. (Side
Block communication	Availability of communications	P2P connections, and Nat Hole punching makes Tox censor resistant but not completely unblockable.
Learn communication metadata	Privacy protection	Toxcore doesn't leak personal metadata above IP:Ports, but makes no attempt to obfuscate it's data usage profile.
Prove what was said	Deniability of message content	NaCl crypto_box provides deniablity
Prove that two persons communicated	Deniability of the conversation	Unknown
Learn past communication after compromise	Forward secrecy	Forward Secrecy from instance to instance (instances can last years).
Prolong a successful attack	Future secrecy	Unknown

[SkyzohKey]

Comment by aaannndddyyy
7 Nov 2016 at 04:17 UTC+1

---

Deniability of the conversation is not given. Both deniability of the conversation and future secrecy are provided by axolotl protocol, or as it is called now, signal protocol. It also offers all the other features we currently have. Additionally, it allows for securing asynchronous messages, so if we ever want to have real offline messages, this protocol is really worth looking into.
However, it was not designed for a p2p network..... (This is only an issue for real offline messages, not for anything we currently support)

[SkyzohKey]

Comment by GrayHatter
7 Nov 2016 at 05:48 UTC+1

---

Deniability of the conversation is not given. Both deniability of the conversation and future secrecy are provided by axolotl protocol, or as it is called now, signal protocol.

I'm not sure what this means. Toxcore already has both, as noted above.

It also offers all the other features we currently have. Additionally, it allows for securing asynchronous messages, so if we ever want to have real offline messages, this protocol is really worth looking into.

It's okay, it's not bad. But I don't see a reason to use this protocol instead of something else. All it add is async keys, but they have to be stored somewhere, like a server. I'm sure we can come up with something better.

[SkyzohKey]

Comment by aaannndddyyy
7 Nov 2016 at 06:28 UTC+1

---

Has both? No. As noted above? No, above it says "Unknown", and toxcore does NOT have it.
I guess you mean content deniability. No problem, they sound very similar.
What it means?
Content deniability means that if your contacts want to prove to a third party that you said what you said, they cannot. Toxcore has that.

Deniability of conversation means that if your contact wants to prove the fact that you had a communication, they cannot. Toxcore does NOT have this.
Axolotl has both, plus the others toxcore currently has (secrecy, authentication, PCs, and future secrecy (dunno, of toxcore has this))

So it would add to what we currently have: deniability of conversation and, if we don't have it yet, also future secrecy , and thirdly secure offline messages.
I don't think you will need a server for this.
Adittionally it's a highly respected protocol that has been audited.

[SkyzohKey]

Comment by GrayHatter
7 Nov 2016 at 08:14 UTC+1

---

Has both? No. As noted above? No, above it says "Unknown", and toxcore does NOT have it.
What it means?

Content deniability means that if your contacts want to prove to a third party that you said what you said, they cannot. Toxcore has that.

Ah, I misunderstood you the first time. I thought we were talking about deniability of content.

Deniability of conversation means that if your contact wants to prove the fact that you had a communication, they cannot. Toxcore does NOT have this.

Axolotl has both, plus the others toxcore currently has (secrecy, authentication, PCs, and future secrecy (dunno, of toxcore has this))

I wonder how Axolotl provides this. According to the audit (here: https://conversations.im/omemo/audit.pdf ) for OMEMO derived from the Signal Protocol. It's theoretical at best. The audit says...

The researchers prove that the Signal Protocol achieves the former [deniability of content], but they claim that the latter [deniability of conversation] might only be theoretical. Because clients authenticate to the Open Whisper Systems server (similar to how an XMPP client authenticates to an XMPP server) and this server needs to know the addresses of the sender and recipient in order to guarantee delivery, the logs that might be stored by the server can reveal that a conversation took place.
The fact that a conversation took place might leak, but through another layer than the application layer of the core Signal Protocol. The solution to such leaking of metadata should also be contained in the appropriate layer and should stay out of scope for the OMEMO specication.

So the audit it self suggests, that Deniability of conversation should remain out of scope.

So it would add to what we currently have: deniability of conversation and, if we don't have it yet, also future secrecy , and thirdly secure offline messages.

No, it wouldn't because from the the quotation from the OMEMO audit says that protection of the conversation, would have to go through a server. An adversary sitting on the wire between you and the person you're talking to would be able to prove you exchanged traffic. And with Tox, without deep packet inspection, it could just as easily be DHT traffic.

I don't think you will need a server for this.

What part makes you think a server is optional?

[SkyzohKey]

Comment by aaannndddyyy
7 Nov 2016 at 10:45 UTC+1

---

So the audit it self suggests, that Deniability of conversation should remain out of scope.

No. They say if leaks can occur on other layers, other layers should take those into account too, or such a claim cannot be made.
It says that proof of conversation having taken place can be taken from the server logs.
Of course it can. It's a crypto protocol, not a network protocol. It cannot hide ip addresses that are used.
That's not in the scope of a crypto library and should be addressed on the network layer, that's what the audit says. Tor can do that.
But it can take care of not proving via cryptographic means that a conversation took place.
cf.

The solution to such leaking of metadata […]

"such", meaning server logs.
The protocol, however, protects here against your communication partner, just as it does wrt content deniability, there also the server is not involved.
See in my previous comment the explanation of what it is meant to protect against:

Deniability of conversation means that if your contact wants to prove […]

Your contact, not a server or ISP or wirehog.

No, it wouldn't because from the the quotation from the OMEMO audit says that protection of the conversation, would have to go through a server.

I do not think so.
Why would you need a server to protect your conversation??
The audit does not say that it needs a server. It just mentions that if a server is used the server will be able to log connections and that this should be taken into account if such deniabiliy is claimed, and that this should then be done at the network layer.
If you use a server, the server knows your ip and your contact's ip, if you use p2p, your isp knows your name and your contact's ip plus your contact knows your ip. In either case if you want no one to know, use tor.

An adversary sitting on the wire between you and the person you're talking to would be able to prove you exchanged traffic. And with Tox, without deep packet inspection, it could just as easily be DHT traffic.

I don't think that this DHT traffic is a feature of libsodium, so it's orthogonal to the key exchange discussion. That means, you'd still have the same DHT traffic as before, and it would be equally hard for the adversary sitting on the wire to prove it.

What part makes you think a server is optional?

Because there are p2p solutions that use DH key exchanges which need no server (cf. toxcore) and direct p2p communication.
The point where axolotl relies on the server is for fetching pre-keys of offline contacts.
But that can be worked around by sharing pre-keys directly with the peer while he is still online.
Online key exchanges instead of pre-key server are supported.
This would then mean you cannot send an offline message to a contact that you have never chatted with, because he never sent you pre-keys for future communications, and there is no server to query for it. But I think this would be a very minor limitation. And this without storing pre-keys in the DHT.
So what makes you think it would need a server?

From OMEMO website:

OMEMO not only gives you a better encryption features than OpenPGP and OTR but is also much easier to setup. OMEMO is the encryption you can actually use in your daily life. Turn it on once and forget you ever did.

Sounds pretty much like what tox wants to accomplish

Finally I can send encrypted messages to someone who is currently offline, uses mulitple clients and simultaneously receive a copy of that message on all of my devices.

Sorry for the long reply, but I hope it makes the axolotl threat model clearer and shows how it could fit into the big picture.

[SkyzohKey]

Comment by aaannndddyyy
7 Nov 2016 at 11:24 UTC+1

---

It is a provenly secure protocol.

For a quick overview, cf. wikipedia: https://en.wikipedia.org/wiki/Signal_Protocol

Otherwise, I recommend reading this: https://eprint.iacr.org/2016/1013.pdf

And I think, widespread adoption of that protocol will lead to constant improvement.

[SkyzohKey]

Comment by iphydf
12 Janv 2017 at 13:18 UTC+1

---

Can someone move this issue to the https://github.com/TokTok/spec repo? I wonder if there is some way to do that with the github api. Either way, this issue is high priority but doesn't belong in toxcore. It is a documentation issue.

[SkyzohKey]

Comment by GrayHatter
12 Janv 2017 at 14:18 UTC+1

---

I will if someone promises to leave the formatting static for > 24h for the
pull to merge?

On Jan 12, 2017 04:19, "iphydf" notifications@github.com wrote:

Can someone move this issue to the https://github.com/TokTok/spec repo? I
wonder if there is some way to do that with the github api. Either way,
this issue is high priority but doesn't belong in toxcore. It is a
documentation issue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
TokTok/c-toxcore#210 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAO20GLgBeCBBNVhFy4KckDb2UODZqMIks5rRhobgaJpZM4KgcZk
.