[DRAFT] Toxcore Threat Model
GrayHatter opened this issue · 13 comments
| 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 |
@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 this is a good start for a threat model https://conversations.im/omemo/audit.pdf
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. |
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 |
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)
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.
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.
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?
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.
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.
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.
This issue has moved and is now accessible here: TokTok/spec#50. Thus closing.