## 4 Random Oracles Proof for the Security of Our Protocols  
If the function output requires a strong randomness assumption, random oracles can be used as an ideal alternative to the cryptographic functions. We employ some security definitions in the following proposed scenarios and proofs. **Definition 1**. : _Partner._  
_We will define the partner functions here. First, we suppose that each player \(p_{i}\) has its corresponding instance \(\Pi^{k}{}_{i}\) in the k-th session, where \(i\in I\), \(I\in\{U,\,RCRS\}\), and \(k\in N\). Besides, we also assume that the player \(p_{i}\)'s partner is the j's instance, where \(j\in I\), \(I\in\{U,\,RCRS\}\) and \(k\in N\). From above definitions, we also defined what the partners are if each of them satisfied the following definitions._  
1. \(p_{i}\)'s session is equal to \(p_{j}\)'s session in the k-th session, that is, \(\text{ssid}^{k}{}_{i}=\text{ssid}^{k}{}_{j}\). 2. _Each partner's instance is matched the corresponding partner's instance, that is, \(p_{i}\)'s instance \(\Pi^{k}{}_{i}\equiv\Pi^{k}{}_{j}\)._  
**Definition 2**. : _Queries._  
_In the following, we give some definitions about query types that an attacker could use to make this request to ask the simulator respectively. By the way, we also model that the attacker's ability may control all communication during the simulation of the pre-checks phase and subsequent validations phase of the proposed scheme. We defined in a \"**Game**\" that an attacker could ask query types as follows._  
1. _Send(i, k, M) (or Send(j, k, M))query: an attacker could impersonate some player and forward the message_ \(M\) _to the instance_ \(\Pi^{k}{}_{i}\) _in the k-th session, where_ \(i\in I\) _and_ \(k\in N\)_._
2. _Reveal(i, k) (or Reveal(j, k)) query: an attacker could obtain the session key from the instance_ \(\Pi^{k}{}_{i}\) _in the k-th session, where_ \(i\in I\) _and_ \(k\in N\)_._
3. _Corrupt(i) (or Corrupt(j)): the instance_ \(\Pi^{k}{}_{i}\)_'s secret key is exposed to the attacker._
4. _Test(i, k) (or Test(j, k)): an attacker could guess the real session key with non-negligible advantage. If the attacker makes this type of query to the simulator, then the simulator could make a coin flipped by_ \(b\)_. If_ \(b\) _equals to_ \(1\)_, the simulator will output real session key_ \(\text{SK}_{i,j}{}^{k}\) _in the k-th session, where_ \(i,j\in I\)_, and_ \(k\in N\)_. Otherwise, it gives the random string chosen from_ \(\{0,1\}^{*}\) _to the attacker. Then, the attacker has to guess whether or not the session key is the real one. Besides, the attacker only could be allowed to make this type of query to the \"fresh\" instance of each player._  
**Definition 3**. : _Freshness._  
_If the following situations occur, an instance_ \(\Pi^{k}{}_{i}\) _is \"fresh\"._  
1. \(\Pi^{k}{}_{i}\) _owns the session key and the attacker does not query the player_ \(\Pi^{k}{}_{i}\) _who is_ \(p_{j}\)_'s instance, Reveal(_\(i,k\)_)._
2. _If there is a player_ \(p_{j}\)_, its instance and partner are both_ \(\Pi^{k}{}_{i}\)_. Then, none of the attackers query the_ \(p_{j}\) _and_ \(\Pi^{k}{}_{i}\) _that owns the same session key, Reveal(j, k)._
3. _An insider attacker created by the opponent cannot be for player_ \(i\) _or_ \(j\)_, where_ \(\{i,j\}\in I\) _and_ \(I\in\{U,\,RCRS\}\)_._  
**Definition 4**. : _Forward Secure (FS)._  
_In our proposed scheme, we define that our scheme satisfied \"forward secure\" if there exists an attacker that could not guess the session key successfully with a non-negligible advantage with both instances in which they were asked the corrupted queries (i.e., Corrupt(i) or Corrupt(j))._  
**Theorem 1**. : _We assume that there exists \(h\) to be a hash function that satisfies the random oracle (RO) assumptions.