The Meeting Businessmen Problem: Requirements and Limitations

– Let us assume that some businessmen wish to have a meeting. For this to happen, they usually have to meet somewhere. If they cannot meet physically, then they can take part in a video (or audio) conference to discuss whatever needs to be discussed. But what if their meeting is meant to be private? In this case they need a cryptographic protocol that allows them to exchange their ideas remotely, while keeping them secure from any potential eavesdropper. In this paper we list all the necessary requirements that a cryptographic protocol must have in order to allow several businessmen to exchange their ideas securely over the Internet. Moreover, and based on the standard taxonomy of cryptographic protocols, we suggest several approaches on how to design cryptographic protocols that enable us to achieve our aim. Finally, we propose the design of a protocol that solves the meeting businessmen problem.

with what happens during an actual meeting where several persons gather to discuss private issues.
Moreover, we list all the limitations inherent in the meeting businessmen protocol. In other words, we state the assumptions under which this problem has a solution.
In our opinion, the approach we adopt can serve as a guideline to anyone who intends to design a solution to the problem.
We next give some basic terminology that will be helpful throughout the remaining of the text.
Definition 1. 1. The person who calls for a meeting is referred to as the moderator.
2. The persons who are at a meeting are called the participants. 3. Any person that is not supposed to be part of the meeting is called an outsider.
Let us assume that several persons are at a meeting. Obviously, the following conditions hold: -Every person is aware of the identities of the other participants; -If a person says something, then it is heard by all the others, and they know who said it; -No person outside the meeting room is allowed to hear what is being discussed.
Hence the following 3 requirements: 1. Every businessman is fully aware of the identities of all the other participants in the meeting. 2. All the participants are aware of each other's communications. In other words, two businessmen should not be able to exchange any message without revealing its content to the others. 3. Their communications are kept confidential; meaning that no outsider can eavesdrop on their conversation. 4. Proof of origin: for each exchanged message, the participants must be aware of the identity of the person who wrote it. Now basic encryption schemes (i.e. public or private key based cryptography) cannot solve this problem since they are concerned with securing the commu-nications between just two parties. We need a specific protocol that solves our problem while meeting the abovementioned requirements. But before suggesting some guidelines on how to build such protocol, we next state the main limitations inherent to any cryptographic protocol that intends to solve the meeting businessmen problem. This part is of utmost importance since there may be some serious limitations that forbid us from finding a solution to our problem.
Let us assume that all the n participants share a secret key K n . Two different scenarios may undermine any implementation of the meeting businessmen protocol: -Scenario 1. During the meeting, a participant could reveal sensitive infor-mation to an outsider by using another medium than the protocol itself. For example by using a phone, by allowing him/her to sit next to him/her, or even by sending him/her messages using a secret key they both share. -Scenario 2. Two participants may send each other a message using the key K n , without sharing its content with the others.
The problem with the first scenario is that we cannot protect against it. This is because the participants are not physically present in the same room, and thus no one can control what the others are doing. It violates the first requirement since a participant may share all the conversations he/she is having with an outsider. In other words, it is as if n +1 persons were meeting instead of n, and the (n +1)st identity is kept secret to all the participants except for his/her accomplice.
The second scenario violates the second requirement. But we will see that we can deal with it.
Based on our previous analysis, the meeting businessmen problem has a solution under the following assumption: All the participants are honest, in the sense that no one allows an outsider to share any part of his/her conversation.
This assumption is true in many real-life cases where a group of people who know each other wish to meet and do not wish to share any of their ideas with outsiders.
It is worth noting that the above assumption also applies to an actual meeting where the participants gather in the same room, since no one can control the actions of all the participants. One could cheat (for example by hiding a wire, or a camera, or an audio receptor placed near his/her ear) and insidiously invite an outsider to the meeting. We next state 2 obvious remarks. Remark 1. The above assumption does not forbid two or more participants from colluding together. This should be enforced by requirement number 2.
Remark 2. Any solution to the meeting businessmen problem under the above assumption is at least as secure as any other means (e.g. phone or video confer-ence) used to allow people to meet remotely.
In the following sections, we suggest several approaches to help us design a solution to our problem, taking into account the previously mentioned assump-tion.
Needless to say, any solution should start by authenticating the participants of a meeting.
Case 3 Without an arbiter but using public-key cryptography. Case 4 Without an arbiter and without public-key cryptography.
In this section we indicate how to design protocols that use an arbiter (i.e. case 1 and case 2 above). These are just suggestions for future work. One may use them as guidelines to write a protocol that solves the meeting businessmen problem.
The main steps for designing a protocol with an arbiter are the following: Step 1. With the help of the arbiter, authenticate the participants.
Step 2. Generate a session key (with or without the help of the arbiter) and distribute it to the participants.
Step 3. For each sent message, verify that all the participants read it.
Steps 1 and 2 are done once. Note that in Step 2 we have the option to let the arbiter read the content of the exchanged messages or not. The former case applies when the arbiter generates the session key and distributes it to the participants.
Step 3 is the most costly since it probably needs to be repeated each time a new message is exchanged among the participants. We next suggest several approaches to address this problem.
Case 1: Designing a protocol with an arbiter and with public-key cryptography.
1. Use a modified version of an authentication protocol (e.g. the Woo-Lam protocol [7], or the Needham-Schroeder protocol [6], or the Denning-Sacco protocol [17]) to authenticate the users and to generate a session key. This step is done once. 2. Each time a participant wishes to send a message, he/she has to send it to the arbiter (or the moderator) who signs it and then sends it to the other participants.
No message is considered to be valid unless signed by the arbiter (or the moderator). 3. The meeting ends upon the request of the mediator (e.g. directly, or by sending a special request to the arbitrator to signal the end of the meeting).
We need to use a modified version of any current authentication protocol, because they are all concerned with authenticating two users. Moreover, it was shown that all initial versions of these protocols were flawed (see for example [18]). A more detailed explanation of the security of these protocols is provided in Section 5.
One might replace Case 1 (1.) by any basic authentication protocol using an arbiter, and then let the participants (or just the moderator) generate a session key. In this case the arbiter will not be able to read the content of the exchanged messages.
In the above scenario (i.e. Case 1), the moderator initiates the protocol with the arbiter to authenticate all the users and to generate a session key. The second point in the above case is very costly and involves a lot of interactions on behalf of the arbiter. A better solution would be to replace the arbiter with the moderator, since we assume that all the participants trust the moderator. Trying to reduce the amount of work to be done by the moderator in Case 1 (2.) does not seem to work. For example, if we replace this step by the following ones: 2'. Each participant sends his/her message to the others.
Then 2 persons could cheat by sending each other a message without sharing it with the remaining participants. In this case the moderator will be unaware of the existence of that message! For this to work, no one must cheat; but then step (2".) becomes useless.
Case 2: Designing a protocol that uses an arbiter but without public-key cryptography.
1. Use a modified version of the Otway-Rees protocol [19] (or the Neuman-Stubblebine protocol [20]) to authenticate the users and to generate a session key. This step is done once. 2. Each participant sends his/her message to the others. 3. The meeting ends upon the request of the mediator.
If we do not wish to use timestamps then we use the Otway-Rees protocol, otherwise we could use the Neuman-Stubblebine one.
In this protocol no message can be signed, so validating the origin of a message among a group of n persons who share the same secret key is impossible; unless in some extreme cases where all the participants trust each other and do not cheat. In other words, each time someone writes a message, he/she sends that message to all the other participants. This concludes this section. We now deal with the case where do not have an arbiter.

Protocols without an arbiter
Case 4 of Section 3 cannot have a practical solution. Indeed, we need public keycryptography to hope to find a solution to our problem. Consider for example the following protocol, where we assume that all the participants share a secret master key with the moderator: Case 4: Designing a protocol without an arbiter and without public-key cryptography.
1. The moderator generates a session key. He/she then sends it to the participants encrypted using the master key he/she shares with each of them, together with any additional information (e.g. identities of the other participants). 2. Each participant sends his/her message to the others. 3. The meeting ends upon the request of the mediator.
In this case the participants cannot collaborate in order to generate a secret session key. All they can do is to rely on the moderator to generate and distribute a new one. Implicitly, the moderator plays the role of an arbiter here. In Step 2 above, sending the message to the moderator in order to forward it adds no security to the Pobrane z czasopisma Annales AI-Informatica http://ai.annales.umcs.pl Data: 27/07/2023 19:31:42 U M C S protocol. Indeed, a participant may cheat by sending a message to a strict subset of the participants using the session key generated and distributed by the moderator. The fundamental problem that arises without the use of public-key cryptography is that there is no means of validating a message (e.g. by signing it). There is also the problem of message origin. Upon the receipt of a message, no one can be sure of the identity of the sender. In the last case described below, we also assume that the moderator shares a secret master key with all the other participants.
Case 3: Designing a protocol without an arbiter but with public-key cryptography.
1. The participants authenticate themselves using a one-way function for ex-ample, or any basic authentication protocol. 2. The participants use secure multiparty computation to generate a session key. 3. Each time a participant wishes to send a message, he/she has to send it to the moderator who signs it and then sends it to the other participants. No message is considered to be valid unless signed by the moderator. 4. The meeting ends upon the request of the mediator.
This protocol assumes that the participants can verify the signature of the moderator. They can use secure multi-party computation (SMPC) as introduced by Yao [4]t o generate a session key because there is no arbiter, and maybe not all of the participants trust the moderator to generate a secure session key (e.g. maybe the random number generator that he/she uses is weak).
Secure multi-party computation allows a set of n players to compute an arbi-trary agreed function of their private inputs, even if an adversary may corrupt and control some of the players. Research related to SMPC can be found in [21,22,23,24,25].
Based on our analysis in this section and in Section 3, we can certify that no practical solution to our problem exists without the use of public-key cryptogra-phy. Thus practical implementations of the meeting businessmen protocol must be based on Case 1 or Case 3 described in Section 3.

The meeting businessmen protocol: An example
In this section we propose a protocol based on Case 1 as explained in Section 3, where the moderator generates the session key to be used by the participants. Selecting a secure authentication protocol can be a daunting task, as we next explain for the cases of the Woo-Lam and the Needham-Schroeder protocols. The original Woo-Lam protocol [7] contains several security flaws. A series of fixes for the Woo-Lam protocol proposed by Woo and Lam [26] was also flawed, since they suffer from reflection attack. An early attack on this protocol was discovered by Abadi and Needham [16], where they illustrate a parallel session attack and suggest a fixed version of the protocol. Later on, Clark and Jacob [18] showed that the fixed version is also vulnerable to a reflection attack. On the other hand, Denning and Sacco [17] and, later on, Lowe [27] discovered an attack on the Needham-Schroeder public-key authentication protocol [6].
Pobrane z czasopisma Annales AI-Informatica http://ai.annales.umcs.pl Data: 27/07/2023 19:31:42 U M C S As explained by Mao [5], the fixed version is also insecure. Mao and Boyd [28] provide a fixed version of the Woo-Lam and Needham-Schroeder protocols that is based on the specification of authentication protocols described in their paper. We illustrate our protocol for 3 users in order to make it easier to read, bearing in mind that it can be extended naturally to include any number of participants. Our solution is based on the refined version of the Needham-Schroeder protocol given by Abadi and Needham [16].
Recall that the mediator is a trusted party, as explained in Section 3. The notation used here is given below.
-The participants are denoted by the capital letters A; B; C; and the arbiter by T .
-PU A (resp. PR A ) denotes the public (resp. private) key of A.
-Cert A is the Alice's public-key certificate (it contains the identity and the public key of A among other information, all of which are signed by the arbiter T ).
The below authentication protocol is almost the same as Authentication and key distribution We next comment on the protocol's steps. In the first step, the mediator (who is also a trusted party) informs the arbiter of the identities of all the participants. In step 2, T sends to A the certificates of the participants. A retrieves from them the current public keys of the participants (which are signed by T ). In step 3, A sends to each participant their certificates, together with an en-crypted message using the participant's public key. The message, which is signed by A, contains the identities of all the participants, the session key K to be used by them, and a timestamp issued by A. After completing this protocol, each participant is aware of the others' identities and possesses the session key K. Now each time a participant wishes to send a message, he/she has to send it first to the mediator, who then signs it and sends it to all the others. For example, if B wants to say something, we could have: But the problem here is that A cannot be sure that B wrote M , since all the participants possess the key K and someone could have impersonated A. Furthermore, step 2 is very costly since the whole message is encrypted using E PR A .
We can overcome this problem by combining hash functions with public-key cryptography, since the hash of a message is of small size.
In step 1, A decrypts the second part of the message to ensure that the message has not been modified, and that it has been sent by B. An outsider cannot read its content because it has been encrypted with K. The timestamp T 1 protects against replay attack: The moderator decrypts the message and verifies that the decrypted value of the timestamp matches the one sent in clear text.
In step 2, A sends the message to all the participants. Upon receipt of this message, C verifies that it is not a replay one and that B wrote it. In order to save encryption/decryption time, A signs with his/her private key the hash of the message, the ID of B, and the timestamp T 2 .
Note that the last two steps can be repeated as many times as needed. Once the meeting is over, the mediator sends a special message to all the participants to announce it. For example A may send to all the participants. The timestamp T is necessary to thwart replay attacks. In this case an attacker may replay the above message (if it does not contain T ) to falsely announce the end of the meeting.

Conclusion and future work
In this paper we formulated and studied a new problem where several people wish to meet securely over an insecure channel. After a quick overview of some authentication protocols, we listed the requirements and the limitations of any possible solution to the meeting businessmen problem. In order to be able to solve our problem, we saw for example that the moderator (i.e. the person who calls for the meeting in the real world) must be a trusted entity by the others, and that any cryptographic protocol that does not use public-key cryptography cannot solve it. Then we suggested several designs of cryptographic protocols based on the presence or absence of an arbiter. Finally, we proposed in Section 5 a solution to our problem that is partially based on a modified version of the Needham-Schroeder protocol.
There is still a lot of work to be done, at least in two directions.
1. Implement the protocol given Section 5. But prior to this step we need to prove that our proposed solution is not vulnerable to known attacks such as replay, manin-the-middle, reflection, or parallel-session.

2.
Design a generalized version of the protocol where participants can join/leave a meeting. This would capture the real case where people may arrive late to a meeting, or when some of the participants leave the meeting before it ends.