Secure Phone: Making man in the middle audible.
Here is a method to render Man in the Middle audible on a telephone connection. Before speech can be encrypted, it is digitized and compressed. It is turned into digital packets. There is some choice in the size and other properties of the digital packets. Suppose that Bob's computer from time to time formulates a plan to do groups of a particular size and form, and sends Ann's computer a hash of that plan and the DH negotiated shared secret. Malloc (the man in the middle) cannot send this hash to Ann's computer for Ann would discover the shared secret she is using is not the same as the shared Bob is using. So his computer must formulate its own plan, and send its own hash, which will not agree with Bob's plan, because Bob's computer does not reveal the plan except by actually sending the packets. So malloc must decompress Bob's speech packets, repacketize them, and recompress them, Often he will not be able to send off a packet, until he has received two of Bob's packets. So this triples the delay, and increases the speech degradation. This should quite noticeable, noticeable enough to provoke Bob and Ann into verifying their connection by reading the hash digits of their shared secret. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd@echeque.com
James Donald <jamesd@echeque.com> writes:
Suppose that Bob's computer from time to time formulates a plan to do groups of a particular size and form, and sends Ann's computer a hash of that plan and the DH negotiated shared secret.
So malloc must decompress Bob's speech packets, repacketize them, and recompress them,
Often he will not be able to send off a packet, until he has received two of Bob's packets.
So this triples the delay, and increases the speech degradation.
Good. Sounds as though this could work. Much better than my stego ramblings. One minor point: if I was Mallet faced with the problem your solution presents the MITM with I would compose a plan which used a whole row of minimum sized packets (or small upward random variations). That would minimise the chance that I would have to wait to compose packets. Clearly you can fix this: you can insist on a certain standard deviation, or whatever as part of the protocol. Another point is that you are making the unstated assumption that you can't stream packets. That is, you are assuming that you must receive the whole packet before you can start to resend decoded and re-encoded. Perhaps this is already the case anyway, I don't know much about audio compression algorithms or codecs. Eric can tell us whether this will already be the case for his algorithm set. If not, I think it should be easy enough to enforce this property (immediate solution which comes to mind: send the bits in a packet backwards!) I'm wondering also whether you couldn't generalise the sort of stretched interlock protocol which is going on here, with in your solution the readers ears telling him something is wrong, to come up with something where the firmware in Eric's fine box could detect and just flip out of secure mode, or flash the leds, or whatever in protest to indicate it had detected a MITM attempt. Perhaps what you have already is enough -- if the inter-packet delay gets longer than whatever you caculate as the highest possible time which could normally happen you flag MITM. If you can ensure that transatlantic delays are lower than the delays MITM will introduce with this protocol, you've got it covered. Being paranoid, I still see a couple of dangers: - if the packets are quite small you may be able to have a neural net setup fill in the gaps when the packets lengths arrive awkwardly for the MITM without it sounding too strange. - there is no guarantee of real-time, you can make something sound like it is coming in real time when it has lag. For example: if you insert some throat clearing, or ponderous "errr". Some peoples speech patterns are that way already. This second one causes me to suggest that you'd be safer to have the box detect the MITM induced lag if you can, rather than rely on human ears. I'm going to think on this some more. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
participants (2)
-
Adam Back -
James A. Donald