Restricted Environments. In our work, we consider a weakened variation of UC security with restricted environments. To this end, we adopt the approach by Xxxxxx, Du¨rmuth, Xxxxxxxx, and Ku¨sters [7] originally developed for the Reactive Simulatability framework. Note that a similar approach has been used by Xxxx, Xxxxxx, and Xxxxxxxxx [31] in the realm of ratcheting in the Constructive Cryptography framework. F F F More formally, we make secure realization statements that only quantify over admissible environments. Whether an environment is admissible or not is defined by the ideal functionality . More concretely, the pseudo-code description of our ideal functionalities can contain statements of the form req cond. An environment is then called admissible for , if it has negligible probability of violating any of those conditions cond when interacting with the ideal functionality . So far, this however does not allow us to disable corruptions: Given that corruptions are triggered by the adversary and not the environment, if our functionality were to use req to disallow corruptions, then such a secure realization statement would become trivial — the simulator could just immediately trigger such a prohibited corruption, disqualifying all environments. To remedy this issue, we only consider corruption respecting adversaries that trigger a corruption if and only if instructed by the environment.32 Fen We then say that a protocol Π securely realized an ideal functionality under restricted vironments, if for every corruption respecting adversary A, there exists a corruption respecting simulator S, such that EXECΠ,A,Z ≈ EXECF,S,Z , F Z for all (with respect to ) admissible environments . For hybrid-world statements, the environment has to be admissible with respect to both the ideal, as well as the hybrid functionality. We note that our results live in the global UC (GUC) framework [17], and are proven in the externalized UC (EUC) framework, relying on the well-known lifting from EUC to GUC. There is no reason to assume our workaround for the commitment problem should affect this lifting result.
Restricted Environments. Recall that in the passive setting we assume that the adversary does not inject messages, which corresponds to authenticated network. However, with the above modeling, one obviously cannot assume authenticated channels. Instead, we consider a weakened variant of UC security, where state- ments quantify over a restricted class of admissible environments, e.g. those that only deliver control messages outputted by the CGKA functionality, and pro- vide no guarantees otherwise. Whether an environment is admissible or not is defined by the ideal functionality F. Concretely, the pseudo-code description of F can contain statements of the form req cond and an environment is called admissible (for F), if it has negligible probability of violating any such cond when interacting with F. See the full version [5] for a formal definition. Apart from modeling authenticated channels, we also use this mechanism to avoid the so-called commitment problem (there, we restrict the environment not to corrupt parties at certain times, roughly corresponding to “trivial wins” in the game-based language). We always define two versions of our functionalities, with and without this restriction.
Restricted Environments. In order to avoid the so-called commit- ment problem, caused by adaptive corruptions in simulation-based frameworks, we restrict the environment not to corrupt parties at certain times. (This roughly corresponds to ruling out “trivial at- tacks” in game-based definitions. In simulation-based frameworks, such attacks are no longer trivial, but security against them requires strong cryptographic tools and is not achieved by most protocols.) To this end, we use the technique used in [7] (based on prior work by Xxxxxx et al. [10] and Xxxx et al. [32]) and consider a weakened Dec ,Cor ∗2 𝑏 𝑏′ ← A2 (𝑐 , st) variant of UC security that only quantifies over a restricted set of so-called admissible environments that do not exhibit the com- req leak(𝑚→0) = leak(𝑚→1) req ∀𝑗 : e→k∗ [ 𝑗 ] ∈ {ek𝑖 : 𝑖 ∈ [𝑁 ] } \ Corr ∨ 𝑚0∗ [ 𝑗 ] = 𝑚1∗ [ 𝑗 ] return ′ 𝑏 mitment problem. Whether an environment is admissible or not is defined as part of the ideal functionality F: The functionality Oracle Dec1 (𝑖, 𝑐) req 𝑖 ∈ [𝑁 ] return Dec(d→k[𝑖 ], 𝑐) ← ∈ [ ] Oracle Cor(𝑖) req 𝑖 𝑁 Corr + 𝑖 return dk𝑖 Oracle Dec2 (𝑖, 𝑐) req 𝑖 ∈ [𝑁 ] 𝑚 ← Dec(d→k[𝑖 ], 𝑐) if ∃ 𝑗 : e→k∗ [ 𝑗 ] = ek𝑖 return ∧ 𝑚 ∈ {𝑚→ 0∗ [ 𝑗 ], 𝑚→ 1∗ [ 𝑗 ] } then ‘test’ else return 𝑚 can specify certain boolean conditions, and an environment is then called admissible (for F), if it has negligible probability of violating any such condition when interacting with F.
