1
$\begingroup$

In some cryptographic protocols I have seen messages protected for confidentiality, authenticity, replaying attacks, reordering attacks, etc.

What protects a protocol from an attacker in a privileged network position (e.g. in control of a majority of the fibre networks connecting countries) from just dropping messages altogether, thus stopping the two parties from communicating (a “Denial Of Service”)?

For example: if a protocol includes a sequence number, the receiver sees messages #233, #234, and #236. What should the receiver do if they missed receiving the #235 message?

Improve this question
$\endgroup$
0
2
$\begingroup$

Message sequencing AND hash-tabling for a trail of backward messages. The loss of a single message is not a disaster, actually. To be not over-paranoid, implement "resend request" in your protocol. If it works and hashes are matched - it can be just a communication error. But if it fails - a line should be dropped immediately. Try to use Tor by the way, and when requesting a re-send use a different chain. That will help you greatly with low implementation costs

Improve this answer
$\endgroup$
3
$\begingroup$

Not much in the cryptographic protocols themselves. But you can do other things to get around such attacks:

  • Request signed read receipts, or received receipts. So, if I send a message from my phone to yours, it sends back a reply that your phone has received the message (or that you have opened it). If such a receipt is signed, your attacker might be able to drop the messages, but won't be able to hide that fact from you.
  • Have another mode of communication to verify. I'll send you a message over wifi, and if I can't verify whether or not you received it over wifi, I will send you a text message over my cellular network. I might even call you. Hopefully, your attacker doesn't have serious control over both networks.
  • Distribute the work of sending the message broadly. Send each message through multiple channels through a protocol that can handle such sending without displaying the same message multiple times. Perhaps this protocol is advanced enough to make sure that no one party sees all of its traffic... otherwise, you're living in a post-apocalyptic world much like the one we happen to be in. Whoops.

At the end of the day, this would probably only be an issue if you're a competitor of Verizon's or a merged TWC/Comcast, or something like that. Maybe Microsoft could build some such bullshit into Windows. But none of those corporations would, because they'd be hit with gigantic criminal sanctions and civil lawsuits and face legitimate market harms as well.

But... I don't think cryptography is meant to handle this problem.

Improve this answer
$\endgroup$
1
$\begingroup$

Assuming that your question excludes any kind of “regular” transmission error (which might also lead to one of the messages not reaching the receiver) the receiver should regard message #236 to be potentially malicious since the “ticket” (what you call “sequence number”) for message #236 can not be verified as genuine.

The specific reaction to such a detection will strongly depend on the individual scenario, protocol goals, and its implementation. In most cases, receiver would (immediately) drop the established communication, regarding message #236 to have potentially been modified by an attacker. If possible, sender and receiver could/should restart the protocol from scratch (including authorization etc.).

Under no circumstances should message #236 be trusted.

The reason is simple: in the described situation, the ticket for message #236 is (let’s just call it) “out of sequence”, which practically breaks the protocol.

Otherwise, there wouldn’t be much reason to use those “tickets” in the first place. The main reason for their existence within certain protocols is to be able to detect (among a few other things) the situation you described, and to react accordingly by not trusting messages that are “out of sequence”.

Improve this answer
$\endgroup$
11
  • $\begingroup$ Is it okay to trust the message if #235 was resent? If no, would it be okay if #235 and #236 were resent in correct order? $\endgroup$ – Nova Nov 30 '14 at 4:23
  • $\begingroup$ @Nova Sure it would be okay to trust #235 if it were resend. As I wrote in the first line – the missing #235 might have just been the result of a network hickup or some network connection issue. If #235 is resend before #236 is send, the protocol will still hold. Order is important here though… receiving #236 and getting #235 at a later time might point to an attacker who’s trying to “fill the holes” (depending on the implementation, network protocols may already help to notice if messages were received or not, so that sender would not send #236 before receiver doesn’t confirm he’s got #235). $\endgroup$ – e-sushi Nov 30 '14 at 4:35
  • $\begingroup$ And what if the attacker is continually dropping the packets? I.e. sender re-sends #235 and #236 but the attacker drops both of those as well. Sender keeps retrying? It means the sender has to store their messages locally until it is confirmed they have been received correctly. What protections can be implemented in a protocol to prevent DOS attacks like this? $\endgroup$ – ushadm Nov 30 '14 at 4:59
  • $\begingroup$ @ushadm This is becoming more of a security related question instead of a cryptographic one. In the end, it will depend on the type of DOS we’re talking about (UDP,NTP,…) which is why I keep saying it’ll depend on the exact scenario. A random example of what I mean: there are things like the Gossamer protocol (PDF) which can be used to prevent most DOS attacks on RFID systems, but the (original) protocol is vulnerable to “de-synchronization”. As far as my knowledge goes, there is no “one protocol to rule all DOS attacks” which will work in all situations/scenarios. $\endgroup$ – e-sushi Nov 30 '14 at 12:42
  • $\begingroup$ @ushadm Erm… and since your comment might be hinting at a nation-sized attacker, I would like to note a little heads-up aside: if you can’t establish a minimally stable connection from where you reside due to the government interfering with your digital transmissions, you should most probably be using a different communication channel. One of many reasons is that the fine line between “interfering” (for example by dropping packets) and ”intercepting” (secret services seem to love doing that) tends to vanish when the attacker happens to be a country you (temporarily or permanently) reside in. $\endgroup$ – e-sushi Nov 30 '14 at 12:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.