At 09:21 AM 10/2/97 -0700, you wrote:
At 11:13 PM 10/1/97 -0700, Lucky Green wrote:
Bad idea. You don't want people to have to look up keys to use your device. Some people may not want to be listed in the phone book. Not to mention that a PKI adds an additional and unnecessary layer of complexity. Just use DH and have the parties each read half of a hash of the public exponentials. No keys to store, no keys to remember, no keys to compromise.
Trouble is this exposes the system to the man-in-the-middle attack. Perhaps you could take advantage of the real time nature of the system to prevent man in the middle, by constructing a protocol such that man in the middle will invariably time out during the connection setup, or produce an audible lag problem in speech.
The MITM attack is thwarted by Lucky's note:
DH and have the parties each read half of a hash of the public ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ exponentials. No keys to store, no keys to remember, no keys to compromise. ^^^^^^^^^^^^^
Each party reads off a series of digits displayed on their screen. Out loud. To each other. Over the secure phone. The MITM attacker can't duplicate the hash on both ends, because a hash of the public keys used to make the connection are different between the MITM's public key and the real public keys. Here's a secure conversation (assume for the moment that the addition below represents a strong hash): Alice <-------------------------------------> Bob PK=1234 PK=5678 1234+5678=6912 5678+1234=6912 Alice reads 69 over the phone, and Bob reads 12 back to her. Alice and Bob proceed to have a private conversation. Now, since Mallory has to create a PK, he cannot just duplicate Alice's 1234, because he'd also need the private key to decrypt the conversation. Likewise, he cannot duplicate Bob's 5678. He has to generate his own PKs in an attempt to fool Bob & Alice. Alice <-----> Mallory <-> Mallory <---------> Bob PK=1234 PK=1111 PK=2222 PK=5678 1234+1111=2345 5678+2222=7900 Alice reads "23" over the phone, and Bob reads "00" back. Since Alice's hash function said she should hear "45" back from Bob, and Bob's screen said he should have heard "79" from Alice, Alice and Bob decide to talk about the weather, and how pretty the trees are in certain cities. Mallory could try to thwart this by impersonating Bob's voice to Alice, saying "45", and Alice's voice to Bob, saying "79" (Mallory does, of course, know these numbers), but if Bob & Alice know each other, this probably won't work too well. Mallory would have to be able to cut into the conversation real-time, undetected. Now, of course, Mallory could hire Anna & Barry to pull the whole impersonation thing off, so that for the entire conversation Alice talks to Barry and Anna talks to Bob, each thinking that they're really talking to the other, but that's also fraught with risk. I'm sure they could pull it off on TV, though :-) So, it'd go full circle back to pass phrases again. "I hear the cherry trees are lovely in Washington D.C." "I wouldn't know, I've never visited Washington in the spring." "I agree, the weather is usually too wet." John -- J. Deters "Don't think of Windows programs as spaghetti code. Think of them as 'Long sticky pasta objects in OLE sauce'." +--------------------------------------------------------------------+ | NET: mailto:jad@dsddhc.com (work) mailto:jad@pclink.com (home) | | PSTN: 1 612 375 3116 (work) 1 612 894 8507 (home) | | ICBM: 44^58'36"N by 93^16'27"W Elev. ~=290m (work) | | For my public key, send mail with the exact subject line of: | | Subject: get pgp key | +--------------------------------------------------------------------+
The MITM attack is thwarted by Lucky's note:
DH and have the parties each read half of a hash of the public ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ exponentials. No keys to store, no keys to remember, no keys to compromise. ^^^^^^^^^^^^^
Each party reads off a series of digits displayed on their screen. Out loud. To each other. Over the secure phone.
The MITM attacker can't duplicate the hash on both ends, because a hash of the public keys used to make the connection are different between the MITM's public key and the real public keys.
In addition, to keep life even more interesting, prior to exchanging the public exponentials g^x and g^y, commitments (hashes) to those values are exchanged... If the commitments don't match the final values, the protocol terminates. See http://www.comsec.com/vp1-protocol.ps for all the details. Eric
Eric Blossom <eb@comsec.com> writes:
Each party reads off a series of digits displayed on their screen. Out loud. To each other. Over the secure phone.
The MITM attacker can't duplicate the hash on both ends, because a hash of the public keys used to make the connection are different between the MITM's public key and the real public keys.
In addition, to keep life even more interesting, prior to exchanging the public exponentials g^x and g^y, commitments (hashes) to those values are exchanged... If the commitments don't match the final values, the protocol terminates.
I can't see that this prevents MITM either. Eve, the attacker, just sends commitments to the values she would have sent in performing the MITM were there no commitments. Still falls back to a belief that a well resourced attacker can't splice audio in real time. Say (for example) if someone smuggled me one of your phones, and I called up Tim. The only protection I'd have is recognizing Tim's voice after hearing him speak breifly years ago. (American accents sound similar to me). On the other hand, using persistent key public key crypto, Tim has been signing his posts recently, and I have an ancient public key of his stashed away which his new key is signed with. If we were able to construct a protocol to bolt on top of the reading of hashes, we could have much greater protection against MITM. To answer the other poster who opined that you had no business saying things to people who's voices you don't recognize: nonsense. We're saying things all the time to people who's voices we've _never_ heard with PGP. 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`
In addition, to keep life even more interesting, prior to exchanging the public exponentials g^x and g^y, commitments (hashes) to those values are exchanged... If the commitments don't match the final values, the protocol terminates.
I can't see that this prevents MITM either.
Eve, the attacker, just sends commitments to the values she would have sent in performing the MITM were there no commitments.
What the commitment prevents is a birthday attack on the verification code by Mallet. Mallet has to be able to come up with a g^x' that when concatenated with g^y and hashed computes the same verification code as g^x concatenated with g^y and hashed. Exchanging commitments to g^x and g^y prior to sending g^x and g^y severely constrain the the degree of freedom that Mallet has to work with. (Another option that works the same way is the "interlock" protocol, where each side sends half the message (g^x or g^y) and doesn't send the second half until after receipt of the first half from the other end).
Say (for example) if someone smuggled me one of your phones, and I called up Tim. The only protection I'd have is recognizing Tim's voice after hearing him speak breifly years ago. (American accents sound similar to me).
None of this is designed to provide authentication of the end point. It is designed to ensure that you've got a private channel to the end point.
On the other hand, using persistent key public key crypto, Tim has been signing his posts recently, and I have an ancient public key of his stashed away which his new key is signed with. If we were able to construct a protocol to bolt on top of the reading of hashes, we could have much greater protection against MITM.
Agreed. The primary difficulty is getting the public keys into the unit. And agreeing on what kind of certificate to use... My preference (for patent reasons) would be to use DSA or ElGamal signatures. Eric
Eric Blossom <eb@comsec.com> writes:
What the commitment prevents is a birthday attack on the verification code by Mallet. Mallet has to be able to come up with a g^x' that when concatenated with g^y and hashed computes the same verification code as g^x concatenated with g^y and hashed.
Yes. But that just means that you need commitments to prevent a MITM brute forcing a key with the same partial hash. I don't see that commitments on DH parameters do anything to prevent someone who can impersonate voices, as far as I can see it is all going to collapse back to whether the attacker can impersonate voices and splice in without audible noise.
On the other hand, using persistent key public key crypto, Tim has been signing his posts recently, and I have an ancient public key of his stashed away which his new key is signed with. If we were able to construct a protocol to bolt on top of the reading of hashes, we could have much greater protection against MITM.
Agreed. The primary difficulty is getting the public keys into the unit. And agreeing on what kind of certificate to use... My preference (for patent reasons) would be to use DSA or ElGamal signatures.
How about touch tone keypad (phone). Bit tedious? Or temporarily plug unit into a PC's modem port? What about... a key server on a phone number. You call key directory services, you type in phone number, and your phone downloads certificates and phone numbers, and uploads it's own certificate. Also put the keyserver on the internet. Too much complexity probably, if most of your users won't be using it as it will add to cost. But I do think it would be a good idea for you to include documentation on a good secure way to use a PGP signature to exchange use-once keys suitable for printing on a sheet of A4 which would keep a user going for a few hundred calls. Plus easy to follow description of how to use. Your suggestion in another post in this thread was a challenge response. Say you printed a matrix of random numbers or words which were exchanged before hand via PGP. And then use the digits of the hash on the LCD screen to do a table lookup. The attacker won't be able to do his MITM because he won't know the table, and so won't know what value he should read. 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`
At 12:05 PM 10/6/97 -0700, Eric Blossom wrote:
None of this is designed to provide authentication of the end point. It is designed to ensure that you've got a private channel to the end point.
Therefore, man-in-the-middle can be more precisely described as an unauthenticated end-point problem. Therefore, without authentication, there is no defense (yet) against MITM attacks. One of the previous threads got me thinking: the original thought was something on the order of "make it so complex it takes so long to compute that we know there was an MITM." Obviously, Mallory can be given enough resources to defeat a computationally bound challenge. However, could there be a way to use a trusted third party (Trent) to validate such a scheme? Lets say that Trent is a trusted third party that operates a Digital Notary, and will sign and datestamp any packet. Can we use the old "one oracle always lies, one oracle always tells the truth" riddle to pass a request through Bob (or in the MITM case, Mallory) to Trent, who always tells the truth? (The riddle works like this: You enter a room with two doors. In front of each sits an oracle. A sign says that, "One oracle always lies, one always tells the truth; behind one exit is a hungry tiger, and behind the other is freedom. You are allowed to ask the oracles any questions you wish." The answer is: ask one of the oracles "which door would the OTHER oracle say contains the tiger?", then you pick the OPPOSITE door to make your getaway. The idea is that you use the truth of one to include the lie of the other to ensure your safety, without attempting to discover the irrelevant fact of which oracle lies.) Can we somehow use this to force a MITM to tip his hand? Can we ask the other end "make this request of Trent, and send me the response?" Any request Alice makes of Bob will instead be made by Mallory on Bob's behalf, so it has to be for something either non-duplicatable or externally verifiable. Perhaps Alice and Bob can both ask Trent to do something externally verifiable. They could both ask Trent to lock up for a ten-second period of time. I know the MITM could use Trent for the conversation with Alice, and Terrance for the conversation with Bob, but if Trent is somehow agreed to or implied by the protocol, it might work. But, of course, nobody would want to sit around waiting for their 10 seconds of holding. And if you had to wait, it would give time for Mallory to spoof the waits. What if both sides asked Trent to display a list of all "registered" conversations that were taking place at a particular point in time? Trent could list that between 9:48:01 and 9:48:06 there were 20 conversations being authenticated. Among them are: Alice PK 1234 was talking to Bob PK 1111 and also a Bob PK 5678 was talking to an Alice PK 2222. Of course, this guarantees externally auditable traffic analysis. But if we're trying to assure that an unauthenticated Bob can talk securely to an unauthenticated Alice, it might be an acceptable tradeoff. All this assumes that the MITM can't get between Alice and Trent. If an authenticated public key is used for Trent, then Alice is OK as long as Mallory isn't Trent's operator! Obviously, the easy solution is to use authenticated public keys all around. Replace Trent in the above with Trusted Public Key Server, and authentication is guaranteed. John -- J. Deters "Don't think of Windows programs as spaghetti code. Think of them as 'Long sticky pasta objects in OLE sauce'." +--------------------------------------------------------------------+ | NET: mailto:jad@dsddhc.com (work) mailto:jad@pclink.com (home) | | PSTN: 1 612 375 3116 (work) 1 612 894 8507 (home) | | ICBM: 44^58'36"N by 93^16'27"W Elev. ~=290m (work) | | For my public key, send mail with the exact subject line of: | | Subject: get pgp key | +--------------------------------------------------------------------+
At 12:05 PM 10/6/97 -0700, Eric Blossom wrote:
None of this is designed to provide authentication of the end point. It is designed to ensure that you've got a private channel to the end point.
Therefore, man-in-the-middle can be more precisely described as an unauthenticated end-point problem. Therefore, without authentication, there is no defense (yet) against MITM attacks.
I concur from the theoretical point of view. In a practical sense I guess it all boils down to what our working definition of authentication is. If I'm using one of my phones and talking to somebody that I know (recognize voice, speech patterns, shared history, ...) and the verification codes check out, I'm highly confident that there is no man-in-the-middle. I'm free to have whatever conversation I like, modulo bugs in the room, laser window bounce listeners, etc. On the "beat the verification codes by spoofing the voice" thread: I don't think that this is a practical threat. You've got the computational challenge (described in the previous posts) and the human part. The complications come from the fact that you've got two live people having a conversation with each other. At least in the conversations I have, we don't read these things back and forth like robots to each other. In secure mode there are 6 hex digits displayed on each unit. On one unit, the first three digits are underlined. On the other unit, the last three digits are underlined. By convention, you say the three that are underlined, and listen for the other three. This seems to work out pretty well in practice. There is generally a "Hi, I'm looking at 1FC", "4D9, good. What's up?" type of interaction. <Blatant_Commercial_Pitch> I'm running a "Privacy Extremist" special on the GSP's. $795 for one, or two for $1500. Cash/Check/MO/MC/VISA/AMEX. Add $16 shipping for one, $20 for two. CA residents add sales tax. US and Canada only. 30 day money back. 1 year warranty. Communication Security Corp. 1275 Fourth St., Suite 194 Santa Rosa, CA 95404 v: 707-577-0409 f: 707-577-0413 eb@comsec.com http://www.comsec.com </Blatant_Commercial_Pitch> Eric
At 12:44 PM 10/7/97 -0700, Eric Blossom you wrote:
I wrote:
Therefore, man-in-the-middle can be more precisely described as an unauthenticated end-point problem. Therefore, without authentication, there is no defense (yet) against MITM attacks.
I concur from the theoretical point of view.
Really, that's the only point I was attacking. I agree that from a practical standpoint that you probably would be able to detect a fake voice today. However, a weakness is a weakness, and from a practical standpoint, digital audio technology is not getting worse as time goes on. The phone phreaker world has a blue box (available on the net and called bluebox, I think) that uses the sound card to generate tones to fool phone systems into giving them free long distance. It also will use a recorded human voice to "read" credit card numbers and phone numbers to a telephone operator. While it's not perfect, it does manage to get inflection and tone properly across. The imperfections are ostensibly covered up by the omnipresent telephone network noise (from which your box does not suffer.) It would not take an enormous amount of recorded conversation to have enough samples to extract the complete set of hex digits from any given speaker. But, it would take an enormous amount of chutzpah for a MITM to try it. It would be easy enough to "trick" the MITM into exposing their existance anyway, just by using digits that come up in conversation. Humans would be able to come up with unique situations that the MITM would find all but impossible to predict. "Hey, Eric, I noticed that the third digit of your IP address' second octet is the same as the second digit of our exchange. How's by you?" A sudden dropout of sound (or "accidental" loss of connection) while the MITM recognizes the trap and tries to backpedal will be instantly noticed. Human protocols are resilient, whereas mathematical protocols are precise. Having a working theory behind securing the exchange (whether or not you implement it) makes for a nice mind exercise, anyway. Your working boxes are a far cry above any theory we discuss here. If I had one of your nifty boxes, I'm sure I wouldn't lose sleep over the theoretical holes. John -- J. Deters "Don't think of Windows programs as spaghetti code. Think of them as 'Long sticky pasta objects in OLE sauce'." +--------------------------------------------------------------------+ | NET: mailto:jad@dsddhc.com (work) mailto:jad@pclink.com (home) | | PSTN: 1 612 375 3116 (work) 1 612 894 8507 (home) | | ICBM: 44^58'36"N by 93^16'27"W Elev. ~=290m (work) | | For my public key, send mail with the exact subject line of: | | Subject: get pgp key | +--------------------------------------------------------------------+
John Deters <jad@dsddhc.com> writes:
It would be easy enough to "trick" the MITM into exposing their existance anyway, just by using digits that come up in conversation. Humans would be able to come up with unique situations that the MITM would find all but impossible to predict. "Hey, Eric, I noticed that the third digit of your IP address' second octet is the same as the second digit of our exchange. How's by you?" A sudden dropout of sound (or "accidental" loss of connection) while the MITM recognizes the trap and tries to backpedal will be instantly noticed. Human protocols are resilient, whereas mathematical protocols are precise.
I wonder if we can come up with a way to formalise this technique and automate it. I think it was James voiced something similar earlier in the thread. Using your example, the MITM faces a couple of problems: he has to think on his toes, and think real fast. Perhaps he can't think fast enough. Second problem, perhaps if he doesn't speak soon enough, he will have blown it, because you are speaking continuously, and the second part of the sentence constructs a problem from information already stated. The first time the information is stated, the MITM doesn't have enough information to change it. Say he changed it to: "Hey eric I noticed the second digit..." (second instead of third), just in case this would help him. Well he doesn't know what the challenge will be so he may just have created an impossible to spoof problem for himself. (The second digit probably won't meet the challenge in the second part of the sentence). So this would force the MITM to construct a replacement challenge which does match. Given the short notice, and already decided first part, he may have difficulty constructing a plausible sounding challenge which meets his criteria. "Is the ummm... square of your first digit". How about this for a computerised method to do something similar. Aim of the game: to make the MITMs job computationally infeasible. Say that we leave some noise in the speech channel. Some of it isn't really noise but encrypted data. Say perhaps first stegoed packet is: E(k1, nonce) = packet1 and second stegoed packet is: E(k2, nonce) = packet2 and finally there is a mask which controls which bits of the noise are actually encrypted data, and which are parts of the actual message. Send this last: E(k3, mask) Then send the three keys k1, k2, k3. Then check that the packets1 and 2 reconsituted according to the mask both decrypt to the same nonce. The idea is that because of the mask, the MITM doesn't know which bits to replace. So he tries to construct his own challenge meeting that protocol. Fair enough he can do this. But he will degrade the voice quality because he will replace some more signal with noise. Can we tune this protocol so that the recipient can detect the extra noise? Well, ok, if the recipient can detect the noise, surely the MITM can too? Yes but, choosing different bits to reduce the noise isn't free, and the hope is that you can construct a system with an expensive noise estimation function which is agreed to as part of the protocol. So you find out 10 seconds into the conversation that there is a MITM. The MITM has to compute this noise function in real time, to avoid introducing lag. It's not very good, but I'm sending it along anway, so that perhaps y'all can improve on it, 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`
At 11:48 PM 10/8/97 +0100, Adam Back wrote:
I wonder if we can come up with a way to formalise this technique and automate it. I think it was James voiced something similar earlier in the thread.
I think that's the problem: once it's formalized and automated, it's spoofable by a MITM. The informal, "Hi Adam, my first digit's the third digit of your phone number today, how's your end?" type of query, perhaps made before or after the entire "I've got 78F, what's yours?" sequence, is going to remain secure. If we assume the MITM can spoof your digits, he can also spoof a whole query without weird digit splicing in the middle. It's like the cartoon cat looking the cartoon dog image in the mirror, waving and trying to trick the image. You can attempt to outmaneuver a MITM with trick questions which will almost certainly expose him, but if the stakes are high enough...where there's a will, there was a dead body. Without some external reference, be it the knowledge of the public key of the other participant, or using a trusted arbitrator, keyserver or whatever, I don't think you *can* mathematically authenticate the other end. The MITM with full knowledge will always be able to reconstruct the proper replies. Your best defenses will be: 1) External (out-of-band) authentication, as in a PGP key signing party, or even just having Bob's key fingerprint from a piece of e-mail posted to cypherpunks a year ago. 2) Wetware outclevering the MITM. Re: your noise introduction protocol. Cute idea, but what if Mallory simply audio-couples his two phones together along with a noise compander circuit a la Dolby? That kind of noise is precisely what the simple electronic filters can remove, and the digital portion is passed via the coupling computer system (the one that spoofs the voices.) "Hey, Bob, I think we've got a MITM! This connection is too clear!" :-) I think the hardest to defeat will be the case where Mallory hires Alicia and Bobby to impersonate Alice and Bob to each other. Alice <---------------------------> Bob (what they think is happening) Alice <---> Bobby______Alicia <---> Bob (what actually is happening) / \ under Mallory's control where Bobby and Alicia have the translator's gift of speaking while listening. They could fill in the cracks with idle chatter, have their own personalities, and basically run both shows. They could even run offline from each other, being intelligent humans. As long as Alice and Bob only communicate through Mallory's intermediaries (i.e. never meet in real life, out-of-band), Mallory owns the show. (Tell me you've never seen something like that on a rerun of _Mission_Impossible_! :-) Would you know if you were talking to the REAL John Deters? All I could assume about you is that if my phone rang and a voice claimed to be Adam Back, I'd expect to hear it in a British accent, and with just a bit of time delay so I'd know it was coming across the Atlantic. About 50 million people could pass themselves off as you today, and I'd never know the difference. I can't even tell a Liverpool accent from a London accent! And if I had a voice recognition system, well, then I'd hope if I was taking a voice sample from you that I'd be smart enough to exchange public keys so we could do our authentication the right way. Again, my position is: o internal authentication is *not* information-theoretically possible; o out-of-band authentication *can be* theoretically secure; o MITM attacks are *almost* infeasible, and *always* expensive; and o if you still suspect a MITM after trying to outwit one, you're just being paranoid. Stop it. John P.S. Even if I exchanged PGP keys with you face-to-face, compared picture ID's, checked your fingerprints, read a signed letter from your Mom (moms don't lie,) and *knowing* that you are indeed Adam Back, I still won't know if you work for MI-5 or not! Nothing's perfect, so lets take what we can get. -- J. Deters "Don't think of Windows programs as spaghetti code. Think of them as 'Long sticky pasta objects in OLE sauce'." +--------------------------------------------------------------------+ | NET: mailto:jad@dsddhc.com (work) mailto:jad@pclink.com (home) | | PSTN: 1 612 375 3116 (work) 1 612 894 8507 (home) | | ICBM: 44^58'36"N by 93^16'27"W Elev. ~=290m (work) | | For my public key, send mail with the exact subject line of: | | Subject: get pgp key | +--------------------------------------------------------------------+
It would be easy enough to "trick" the MITM into exposing their existance anyway, just by using digits that come up in conversation. Humans would be able to come up with unique situations that the MITM would find all but impossible to predict. "Hey, Eric, I noticed that the third digit of your IP address' second octet is the same as the second digit of our exchange. How's by you?" A sudden dropout
Another game you can play, with the audio, is to have music playing in the background, so Eve not only has to fake Alice's voice, but has to fake Alice reading numbers against a background of an arbitrarily-selected musical piece. Now, the effectiveness of the technique may depend on the musical tastes of the players ("Hey - that's not Toscanini conducting Beethoven's Fifth - that's the Furtwangler version on Deutsche Gramophon!"/ "Oh, was that Elvis? I guess so."/ "We're being MITMed - the Terrapin Station during the numbers was off the album, where Jerry remembered all the words, and now you're playing an audience tape version from Nassau in 89" ) and with some genres of music, it makes it easier to notice if there's a gap. Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Bill Stewart <stewarts@ix.netcom.com> writes:
Another game you can play, with the audio, is to have music playing in the background, so Eve not only has to fake Alice's voice, but has to fake Alice reading numbers against a background of an arbitrarily-selected musical piece.
There are two types of MITM attack: i) the eavesdropper lets your voice go through ii) the eavesdropper re-synthesizes your voice, or has two actors one for Bob, one for Alice holding separate conversations Your suggestion of having a CD playing in the back-ground only helps against type i) MITM. James's method of forcing the MITM to commit to delivering packets with sizes which he can't deliver similarly only applies to type i), as does my stego idea. I think we stand a chance against type i). Type ii) seems pretty hard to stop by either manual cleverness (mixing in comments related to the hash digits) or automated methods (such as James's or my earlier stego idea). I mean, heck, the actors could run two completely different conversations, and weave into the conversation earlier topics covered with Alice which they wanted to hear responses to, from Bob, and vice-versa. The MITM could potentially have as long as he wanted to think of something clever to say to sound consistent with a comment made by Alice or Bob relating to their hash digits. Or he could simply choose to omit saying anything related to hash digits. They could play different CDs, or no CDs, or go buy a copy of the CD, or have a nice selection on tap as radio stations do (they seem to be able to play any track with a couple of seconds notice). I think the only real way to stop MITM to a paranoidly high degree of certainty is to use authentication and web of trust. Perhaps you can get a high enough degree of certainty for your application with preventative measures against type i) MITM firm in the belief that type ii) MITM is too difficult, or too expensive to try against you. I'm not sure it's even that expensive or difficult. If I was a drug king pin, or mafia, or military intelligence I wouldn't feel safe with these approaches alone. I'd want separate authentication. Probably another kind of attack would be dangerous too: if the attacker re-routes my phone call or hi-jacks it prior to set up of secure comms. Without authentication I could have a convesation with a spook instead of Bob Gotti and not know it. Alice need never know I called, or may simultaneously, or some time afterwards have a call from another spook with faked ANI. Persistence authentication suggestion: I can see one strong protection feature which isn't currently built in to Eric's phone which could be, should be I think. Shouldn't be that hard to do. You have the situation currently that you call Bob's number to go secure, then have a conversation. Well if you make several calls to Bob with the first call being MITM free, because the MITM hadn't singled you out for investigation yet, no use of this fact is made to reduce the MITM's chance of succeeding next time. (People who know some about SSH protocols may be guessing what's coming next). A way to use the fact that you have had one or more non-MITM'd calls is for the unit to remember the number and exchange a secret with the called unit inside the encryption envelope. The next time you call the same unit (as defined by calling the same phone number), you use the shared secret to authenticate the call. If the other unit can't do this, you get suspicious. You could do better than using the phone number: you could have the units exchange public El Gamal or DSA keys (bearing in mind Eric's understandable avoidance of RSA). When you call up a unit you first send it a nonce to sign with it's EG/DSA key. It signs it and sends you it's public key. If you already have the public key, you check that the signature matches. If you don't have the public key, you save it for next time. You probably want to assign the public key some human meaningful value that can be displayed on the display. If you have no input device, I guess a sequence number would do. (First secured phone you ever call is called user 1, etc). Then the user can write down who he thinks each caller is caller 1. Black Unicorn, 2. Lucky Green. 3. Tim May, etc. You could even slap a sticker on top of the box with a few places to enter this information. In addition this feature means that you can secure one communication with a PGP emailed table of key words to lookup hash digits and speak words. After that secured communication all further communications are also authenticated. If you don't use a PGP secured email, well you still have authenticated that you are at least talking to a persistent MITM. This in itself is useful, because the MITM may make mistakes, or you may arrange to call from different numbers arranged by out of band communications. If you once get a different key, you get suspicious, as the once could be the only time you got through to the real Bob, as opposed to the MITM. Another way to authenticate yourself would be if you met face-to-face with someone you plan to use the phone with in an office with an internal switch board, or with a test rig such as Eric has to demonstrate his phones. (How easy would it be to have the units directly plugable -- plug them together, plug a phone in talk make secured call, remember or write down that user 3 is Tim May. I like this use of persistence authentication. What do you think Eric? Another method, which could be used in addition would be for Eric to install an additional key into the units, and certify that key. If the sale is in person, perhaps you could even personalise them with the users name & dob or something unique (users choice). At least that way Eric gets to profit from the MITM/spooks as they've got to buy a unit to get a certified key :-) Course it makes Eric, or Eric's laptop, a _fat_ target, but would be cheaper than including full web of trust certification capability, and could add some utility. Anyway, I like the persistence authentication idea. And I'd encourage Eric to build it in. 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`
At 01:15 PM 10/10/97 +0100, Adam Back you wrote:
Persistence authentication suggestion: A way to use the fact that you have had one or more non-MITM'd calls is for the unit to remember the number and exchange a secret with the called unit inside the encryption envelope.
The problems with this solution are twofold: 1. Eric may have to redesign the unit to have persistent read-write storage. And maybe a *lot* of storage, if you use it a lot. Maybe a lot of expen$ive $torage at that. His phone is already priced way out of the consumer market, let's not add to that. 2. I had problems with UUCP when my machines got out of sync (way back when.) Just think how bad they'll look if they refuse to light up "secure" because one guy had to change batteries. I agree with you that external authentication is the only way to fly. And if it is simply accepted, lets let Eric's unit survive unmolested and use PGP out-of-band (as per Monty's suggestion) or use PGP to exchange session keys (like in Speak Freely.) I also think the most likely avenue of attack will be a black bag job on the individual user's phone. MITM attacks seem too risky and expensive to pay off. John -- J. Deters "Don't think of Windows programs as spaghetti code. Think of them as 'Long sticky pasta objects in OLE sauce'." +--------------------------------------------------------------------+ | NET: mailto:jad@dsddhc.com (work) mailto:jad@pclink.com (home) | | PSTN: 1 612 375 3116 (work) 1 612 894 8507 (home) | | ICBM: 44^58'36"N by 93^16'27"W Elev. ~=290m (work) | | For my public key, send mail with the exact subject line of: | | Subject: get pgp key | +--------------------------------------------------------------------+
John Deters <jad@dsddhc.com> writes:
At 01:15 PM 10/10/97 +0100, Adam Back you wrote:
Persistence authentication suggestion:
The problems with this solution are twofold:
1. Eric may have to redesign the unit to have persistent read-write storage. And maybe a *lot* of storage, if you use it a lot. Maybe a lot of expen$ive $torage at that. His phone is already priced way out of the consumer market, let's not add to that.
If it cost a lot extra, that could be a problem, yes. I am unclear on how much extra this would cost. Apart from an EEPROM, it's a protocol and software update right?
2. I had problems with UUCP when my machines got out of sync (way back when.) Just think how bad they'll look if they refuse to light up "secure" because one guy had to change batteries.
Use an EEPROM?
I agree with you that external authentication is the only way to fly. And if it is simply accepted, lets let Eric's unit survive unmolested and use PGP out-of-band (as per Monty's suggestion) or use PGP to exchange session keys (like in Speak Freely.)
I also think the most likely avenue of attack will be a black bag job on the individual user's phone. MITM attacks seem too risky and expensive to pay off.
For individuals perhaps. For military intelligence or mafia boss type uses perhaps not. Or perhaps not for lower security apps too: buy a small landline phone to use as a handset, carry your box with you every where you go, never let it out of your sight, move around a lot, hotel rooms, anywhere else random you can get a phone jack socket. I reckon there would be potential clients who might fit this life-style. On the cost front, I am interested as to thoughts on how easy it would be for Eric to put one of his phones on a PCI card, or PCMCIA card. Presumably you could make some major cost savings in this way, in that you could potentially use the computers modem, memory, processor. PGP Inc's pgpfone I think is sort of compatible with Eric's phone. However pgpfone audio quality _sucks_. (Admittedly one end was using a 14.4k modem when I tried it -- but it was _terrible_, even no encryption was fairly bad). I think Eric's phone uses a 14.4k modem chip (or lower?) so it's not the bit rate as such, but more the lack of higher quality audio compression codecs which are possible in hardware. (Right?) Also the fact that with PGPfone you're using PC speakers, and room microphone probably makes it seem worse than it could be. A socket to plug a phone into to act as a speaker/microphone would be a good start, plus the audio codec part of the Eric's hardware. Now what do you reckon you could get the price of that down to? How would that work out with a PCMCIA card... I'm thinking of laptops using GSM mobile phones data links, what would the audio quality be like over the 9600 bit data rate over a GSM mobile phone? If it could work it would be neat as you'd have a fully mobile secure phone. Better than Jim McCoy's cell phone strapped to his laptop: secure phone PCMCIA card in one PCMCIA slot, PCMCIA modem in the other slot, mobile phone plugged into PCMCIA modem, al-cheapo phone handset plugged into secure phone PCMCIA card. Tangle of wires, but still neat. Pity GSM phones don't have audio in, and mike out jack sockets, which get selected when you plug in the data lead, or you could use the GSM phone handset. Course adding the whole lot to a GSM phone would be even neater, but then that'd get expensive again. Wonder how much functionality could be borrowed from components already present for the normal GSM phone hardware, and how much saving you could get from that. 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`
Adam Back writes:
John Deters <jad@dsddhc.com> writes:
At 01:15 PM 10/10/97 +0100, Adam Back you wrote:
Persistence authentication suggestion:
The problems with this solution are twofold:
1. Eric may have to redesign the unit to have persistent read-write storage. And maybe a *lot* of storage, if you use it a lot. Maybe a lot of expen$ive $torage at that. His phone is already priced way out of the consumer market, let's not add to that.
Hey, it's only a factor of two too expensive... Moore's law is your friend...
If it cost a lot extra, that could be a problem, yes. I am unclear on how much extra this would cost. Apart from an EEPROM, it's a protocol and software update right?
The units currently have 2K bytes of EEPROM and 256K bytes of FLASH. A little under half the flash is currently available, though it will probably be taken advantage of during remote upgrades (coming soon to a crypto phone near you...) There's plenty of room for long term storage of a reasonable set of public keys. Private or symmetric keys present a problem, since then you've got a long term secret to store somewhere. To forestall a bunch of questions about remote upgrades: (1) there is a jumper on the write line to the FLASH. If you're totally paranoid, leave it in the "Read Only" position. (2) upgrades will be digitally signed. (3) It'll be a "pull" upgrade. I.e., you have to request the upgrade. They're not just pushed down your throat.
On the cost front, I am interested as to thoughts on how easy it would be for Eric to put one of his phones on a PCI card, or PCMCIA card. Presumably you could make some major cost savings in this way, in that you could potentially use the computers modem, memory, processor.
I can pretty much be done all in software on a laptop. I've explained the details several times. Perhaps if folks we're paying me lots of money for the info, they would listen closer ;-) The primary thing you lose is the simple integration with the telephone. A small (cheap) hardware hack can work around this. Yes, I know you'd prefer not to have any non-standard hardware, but on the other hand, if the system is a pain in the ass to use, nobody is going to use it.
I think Eric's phone uses a 14.4k modem chip (or lower?) so it's not the bit rate as such, but more the lack of higher quality audio compression codecs which are possible in hardware. (Right?)
The unit currently runs at 14.4k. A 4800 b/s fallback mode is currently under development.
Also the fact that with PGPfone you're using PC speakers, and room microphone probably makes it seem worse than it could be.
Fixable with software and MIPS (you've got those). Take a look at those nice USR and Polycom full duplex speaker phones. There's nothing magic in them. Notice the neat little song they play when you power them up. It's a training tone used to compute the impulse response of the room.
Course adding the whole lot to a GSM phone would be even neater, but then that'd get expensive again. Wonder how much functionality could be borrowed from components already present for the normal GSM phone hardware, and how much saving you could get from that.
Pretty much everything you need is already there. It's a question of integration. Eric
Eric Blossom <eb@comsec.com> writes:
If it cost a lot extra, that could be a problem, yes. I am unclear on how much extra this would cost. Apart from an EEPROM, it's a protocol and software update right?
The units currently have 2K bytes of EEPROM and 256K bytes of FLASH. [...] There's plenty of room for long term storage of a reasonable set of public keys. Private or symmetric keys present a problem, since then you've got a long term secret to store somewhere.
What's the difference betwen storing public keys and private keys? Are you concerned that someone will tamper with the unit and replace the keys. (Borrow the phone while you're out, reset the EEPROM, and make a series of calls to put in MITM keys.) Could be dangerous. You could use a pin, but then you need an input device. However, you could also argue that if someone can borrow your phone for a while they can give it free "upgrade", and replace the RNG, or whatever anyway, so it doesn't make any difference? I don't think it does. I kind of liked the persistency authentication idea as a candidate for your remote upgrade. You could do it with symmetric keys or with asymmetric keys. It's just a trade off which depends on how many keys you're allowing. If space is short, you could do something more clever, say: - Exchange (and store in a table) a symmetric key with each new phone - Lookup keys by phone number (or unit serial number if you don't have ANI) - Authenticate using nonce and stored key. Overhead: 16 bytes per phone Allow say 50 callers = 800 bytes. Perhaps you want a button to push (hold go secure down for over 5 seconds, say) to store a caller in this table. (Prevents attacker flushing your table by making a load of dud calls). Or perhaps just wrap around and discard least used numbers/serial numbers.
[phone on PCI/PCMCIA card]
I can pretty much be done all in software on a laptop.
The primary thing you lose is the simple integration with the telephone. A small (cheap) hardware hack can work around this. Yes, I know you'd prefer not to have any non-standard hardware, but on the other hand, if the system is a pain in the ass to use, nobody is going to use it.
Fancy organising this cheap hardware hack? I reckon you'd get a few buyers. I'll pledge to buy 3 at a reasonable price. Do you have the software for PCs/MACs? Would this cheap hardware hack work with PGPfone as is? (PGP Inc don't seem to be doing much work on PGPfone right now). btw the hardware hack I presume is impedance matching to allow phone to plug into 3.5mm jack audio and mic socket? Any hardware people care to give soldering instructions?
I think Eric's phone uses a 14.4k modem chip (or lower?) so it's not the bit rate as such, but more the lack of higher quality audio compression codecs which are possible in hardware. (Right?)
The unit currently runs at 14.4k. A 4800 b/s fallback mode is currently under development.
GSM laptop secure phone, here we come :-)
Also the fact that with PGPfone you're using PC speakers, and room microphone probably makes it seem worse than it could be.
Fixable with software and MIPS (you've got those). Take a look at those nice USR and Polycom full duplex speaker phones. There's nothing magic in them. Notice the neat little song they play when you power them up. It's a training tone used to compute the impulse response of the room.
I'm not sure what PGPfone's problem is, but when I tried it, it sounded like an off tune radio station, but worse. Even turning off encryption entirely (to preserve the precious cycles for the audio codec) didn't help much. Perhaps I should retry it now with 166Mhz K5 pentium in place of 120Mhz AMD 486 at the time.
[integrating with GSM phone]
Pretty much everything you need is already there. It's a question of integration.
It's a damn, damn, shame that no-one is doing this. We couldn't bribe you to do it next could we? I was kind of figuring that eventually we'll get there with a bit of software because cellular phones and laptops functionality will merge, and the bandwidth and processing power will be there. Still a laptop with your hardware hack, would be ok for now. 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`
John Deters wrote:
At 01:15 PM 10/10/97 +0100, Adam Back you wrote:
Persistence authentication suggestion: A way to use the fact that you have had one or more non-MITM'd calls is for the unit to remember the number and exchange a secret with the called unit inside the encryption envelope.
I agree with you that external authentication is the only way to fly. And if it is simply accepted, lets let Eric's unit survive unmolested and use PGP out-of-band (as per Monty's suggestion) or use PGP to exchange session keys (like in Speak Freely.)
I also think the most likely avenue of attack will be a black bag job on the individual user's phone. MITM attacks seem too risky and expensive to pay off.
I'm not a subscriber to the CypherPunks list, but I have been monitoring the emissions from John's computer screen, and I would just like to say that I agree with him, wholeheartedly. I often tell my superiors that there are much better ways to be spending taxpayer money. I am not alone in my agreement with most of what is being said in this thread. The spook supplying heroin to Adam Back's lover agrees with most of this thread, as does the spook peeking through Eric's window (although she disagrees with the suggestion to "let Eric's unit survive unmolested"). The one exception is the grandson of Patton who is doing surveillance on Monty. His method is quite simply to beat Monty to the phone. Spooky (isn't it?)
Eric, I think you can make a stronger statement. With your phone, once you exchange the hash you have good assurance that you have a private conversation with the person whose voice you hear. How you determine that that is the person you think it is/should be is a different problem. As for proving lack of an eavesdropper, you would also need to establish that the person's earpiece wasn't bugged, the person didn't record the conversation to hand to someone else, .... For my purposes, the authentication is secure enough that I'm very pleased. The voice quality is good enough that I can recognize friends -- and if I'm calling a stranger, then the MITM is a moot point. That is, if I'm calling a stranger named Bob, there is no way for me to tell the difference between: Carl -- Eve -- Bob and Carl -- Bob -- Eve since both Bob and Eve are strangers to me and I don't know Bob well enough to rule out case 2. - Carl +------------------------------------------------------------------------+ |Carl M. Ellison cme@acm.org http://www.clark.net/pub/cme | |PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2| | "Officer, officer, arrest that man! He's whistling a dirty song." | +-------------------------------------------- Jean Ellison (aka Mother) -+
At 6:25 PM -0700 10/5/97, Adam Back wrote:
On the other hand, using persistent key public key crypto, Tim has been signing his posts recently, and I have an ancient public key of his stashed away which his new key is signed with. If we were able to construct a protocol to bolt on top of the reading of hashes, we could have much greater protection against MITM.
Of course if you can use PGP as well as the secure phone, you can use PGP to exchange a pad of one-time passwords.
To answer the other poster who opined that you had no business saying things to people who's voices you don't recognize: nonsense.
We're saying things all the time to people who's voices we've _never_ heard with PGP.
Are you really willing to discuss with Tim that suitcase you're planning on bringing to the states. :-) ------------------------------------------------------------------------- Bill Frantz | Internal surveillance | Periwinkle -- Consulting (408)356-8506 | helped make the USSR the | 16345 Englewood Ave. frantz@netcom.com | nation it is today. | Los Gatos, CA 95032, USA
Bill Frantz <frantz@netcom.com> writes:
At 6:25 PM -0700 10/5/97, Adam Back wrote:
On the other hand, using persistent key public key crypto, Tim has been signing his posts recently, and I have an ancient public key of his stashed away which his new key is signed with. If we were able to construct a protocol to bolt on top of the reading of hashes, we could have much greater protection against MITM.
Of course if you can use PGP as well as the secure phone, you can use PGP to exchange a pad of one-time passwords.
The passwords alone don't do you any good: if you read them out over the phone, Eve can just repeat them. You need to combine the password with the part of the D-H parameter hash displayed on the dinky little secure phone display in such a way that Eve can't fake it without knowledge of your password. It would be nice if you didn't need a computer to perform this operation, but I guess you could live with needing a computer. It would also be nice if the number of digits you had to read was relatively short. XOR doesn't work, because Eve can undo that; XOR isn't very easy to do mentally anyway. Encrypting the display value with a symmetric cipher and a key formed from the password and reading out a selection of digits from the ciphertext would do. But most/all symmetric ciphers worth speaking of are beyond doing in your head, or with a piece of paper in a reasonable amount of time. How many digits are on the display of one of those phones? It seems that you should be able to concoct something which is easy to compute, and offers as much surety as the few digits on the display. 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`
Bill Frantz <frantz@netcom.com> writes:
At 6:25 PM -0700 10/5/97, Adam Back wrote:
On the other hand, using persistent key public key crypto, Tim has been signing his posts recently, and I have an ancient public key of his stashed away which his new key is signed with. If we were able to construct a protocol to bolt on top of the reading of hashes, we could have much greater protection against MITM.
Of course if you can use PGP as well as the secure phone, you can use PGP to exchange a pad of one-time passwords.
The passwords alone don't do you any good: if you read them out over the phone, Eve can just repeat them.
There's no reason you couldn't use the passwords in a bidirectional challenge/response scenario. The units can pass (optionally encrypted) control messages back and forth while in secure voice mode. Eric
How many digits are on the display of one of those phones? It seems that you should be able to concoct something which is easy to compute, and offers as much surety as the few digits on the display.
You get 6 big characters that you can see from a couple of feet away, or three lines of 16 characters that you have to squint at ;-) (It's a 100 x 32 pixel graphic display). Eric
At 10:57 AM -0700 10/6/97, Adam Back wrote:
Bill Frantz <frantz@netcom.com> writes:
At 6:25 PM -0700 10/5/97, Adam Back wrote:
On the other hand, using persistent key public key crypto, Tim has been signing his posts recently, and I have an ancient public key of his stashed away which his new key is signed with. If we were able to construct a protocol to bolt on top of the reading of hashes, we could have much greater protection against MITM.
Of course if you can use PGP as well as the secure phone, you can use PGP to exchange a pad of one-time passwords.
The passwords alone don't do you any good: if you read them out over the phone, Eve can just repeat them.
One simple possibility is to send out ten word groups. Use each group only once. Use the words to encode the key hash display. ------------------------------------------------------------------------- Bill Frantz | Internal surveillance | Periwinkle -- Consulting (408)356-8506 | helped make the USSR the | 16345 Englewood Ave. frantz@netcom.com | nation it is today. | Los Gatos, CA 95032, USA
participants (7)
-
Adam Back -
Bill Frantz -
Bill Stewart -
Carl M. Ellison -
Eric Blossom -
John Deters -
The Spook