Designing Reverse Firewalls for the Real World

Angèle Bossuat; Xavier Bultel; Pierre-Alain Fouque; Cristina Onete; Thyla van der Merwe

doi:10.1007/978-3-030-58951-6_10

European Symposium on Research in Computer Security

ESORICS 2020: Computer Security – ESORICS 2020 pp 193-213 | Cite as

Designing Reverse Firewalls for the Real World

Authors
Authors and affiliations

Angèle Bossuat
Xavier Bultel
Pierre-Alain Fouque
Cristina Onete
Thyla van der Merwe

Conference paper

First Online: 12 September 2020

1 Citations
786 Downloads

Part of the Lecture Notes in Computer Science book series (LNCS, volume 12308)

Abstract

Reverse firewalls (RFs) were introduced by Mironov and Stephens-Davidowitz to address algorithm-substitution attacks (ASAs) in which an adversary subverts the implementation of a provably-secure cryptographic primitive to make it insecure. This concept was applied by Dodis et al. in the context of secure key exchange (handshake phase), where the adversary wants to exfiltrate sensitive information by using a subverted client implementation. RFs are used as a means of “sanitizing” the client-side protocol in order to prevent this exfiltration. In this paper, we propose a new security model for both the handshake and record layers, a.k.a. secure channel. We present a signed, Diffie-Hellman based secure channel protocol, and show how to design a provably-secure reverse firewall for it. Our model is stronger since the adversary has a larger surface of attacks, which makes the construction challenging. Our construction uses classical and off-the-shelf cryptography.

This is a preview of subscription content, to check access.

Notes

Acknowledgements

We would like to thank Håkon Jacobsen and Olivier Sanders for their contributions to the preliminary versions of this paper, as well as Kenny Paterson for the fruitful discussions on the subject. This work was supported in part by the French ANR, grants 16-CE39-0012 (SafeTLS) and 18-CE39-0019 (MobiS5).

Supplementary material

Open image in new window

A Our Security Model Compared to Dodis et al.’s

Reverse firewalls must preserve, not create security. If a secure-channel establishment protocol is run honestly, it should guarantee end-to-end security, no matter what is or isn’t between the endpoints. This requirement is taken into account, both by Dodis et al.’s work [9] and by ours.

The use case for reverse firewalls (RFs) is one in which the adversary has tampered with the client implementation to exfiltrate information to a MitM adversary. It is expected that an honest⁴ RF will preserve security, so the adversary should not be able to distinguish a transcript involving its corrupt implementation (protected by an RF) from one only involving honest parties. This property obviously cannot hold for all tampered implementation and it is thus necessary to place some restrictions on the adversarial behaviour. In [9], this is done by requiring functionality-maintaining implementations, whose definition we adapt and re-orient to fit our criteria.

Our Model. Our first goal is to define a model that places fewer restrictions on the adversarial behaviour, while making these restrictions easy to understand and quantify, via the notion of transcript equivalence, defined in Sect. 2.4.

As mentioned before, our second goal is to design an RF that preserves security for the key agreement and the record-layer protocols in this new model, which is a non-trivial extension compared to [9], as our model is much more permissive, allowing more realistic attacks, such as key-replacement in the record layer or choosing key-dependent messages. To achieve this, we consider a more general definition of the RF, allowing it to have a public key \(\mathsf {pk}_{ {FW} }\). The existence of this public⁵ key is an important difference compared to [9]: the client is aware of the existence of the RF, which does not seem to be a significant restriction for most use-cases, such as the one of a company network. We stress that we can retain obliviousness and transparency for our protocol, meaning that the client cannot detect the status of the RF.

The firewall can, via its secret key, passively derive a shared secret \(\mathsf {\mathsf {k}_{cfs}}\) (also known to both endpoints) from any key agreement involving one of the clients it protects. This key will be used to preserve the security of the record layer even if the client is corrupt. However, since we also want to ensure privacy for the client and the server against the RF (in case the latter is malicious), we allow the endpoints to derive another shared key \(\mathsf {\mathsf {k}_{cs}}\) (unknown to the RF), which is meant to provide end-to-end security (even with respect to the RF). In our protocol, one needs both keys to learn any information about the transmitted messages; yet the strength of only one key suffices to prevent exfiltration of information and provide security with respect to Man-in-the-Middle adversaries.

The RF is unable to break the security of the channel, yet tampered implementations cannot manage to exfiltrate information through the firewall – our RF performs its task without being trusted. In particular, our model considers malicious RFs and we prove that security still holds in this case, despite its additional knowledge of \(\mathsf {\mathsf {k}_{cfs}}\). This additional key may be useful when considering more intricate key agreement protocols such as TLS 1.3, where parts of the handshake are encrypted.

Three Attack Scenarios. We first prove security in a context where everyone is honest, but we also need to separately study the case of \(\mathsf {\mathsf {k}_{cs}}\), only known to the endpoints, and of \(\mathsf {\mathsf {k}_{cfs}}\), known to the client, the firewall and the server. We also consider the possibility of a malicious client, which again is the main motivation of RFs. This leads to the three following scenarios:

1.
Security of \(\mathsf {\mathsf {k}_{cs}}\). The adversary controls a legitimate RF, situated between two honest endpoints, and its goal is to break the security of the channel, i.e., get some information on \(\mathsf {\mathsf {k}_{cs}}\). This scenario implies security without an RF, since the adversary can simply force the latter to be passive. It shows that the client server are still able to preserve their privacy even in the presence of a malicious RF.
2.
Security of \(\mathsf {\mathsf {k}_{cfs}}\). The protocol must ensure the security of the \(\mathsf {\mathsf {k}_{cfs}}\) key established between three honest parties following the protocol. Our adversaries are stronger than those of Dodis et al., since they can reveal all but the test-session keys⁶ and since they may choose the target instance adaptively. In this scenario the adversary tries to get some information on \(\mathsf {\mathsf {k}_{cfs}}\).
3.
Malicious client. For exfiltration resistance, the adversary provides a malicious client implementation, which will then interact with the firewall and the server. The goal of the adversary is to obtain information about the data sent by the tampered implementation during the executions of the key agreement and secure messaging protocol. The server is honest.

For clarity, we choose to treat each case separately. Our modelling approach follows the models of Bellare and Rogaway [2] and Canetti and Krawczyk [5], although we also use ideas from the multi-stage model of Dowling et al. [10].

B Transparency

While obliviousness allows the adversary to obtain auxiliary information, such as revealed keys, transparency is solely based on the indistinguishability of messages coming from the endpoints, and those modified by the firewall. Therefore, it is entirely linked to the content of those messages. By definition, transparency is a sub-goal of obliviousness: it is necessary, but not sufficient. Being able to tell whether a message has been modified implies being able to tell whether a firewall is involved or not. If a protocol with a reverse firewall does not achieve transparency, i.e., if there exists an PPT adversary who can distinguish the message originally issued by the client from a modified one with non-negligible probability, this protocol does not achieve obliviousness.

Definition 9 (Transparency)

An AKE protocol \(\mathrm {\Pi }\) is transparent if for all PPT adversaries \(\mathscr {A}\), Open image in new window

is negligible in \(\lambda \):

C Proof of Theorem 4

We will show that no adversary can distinguish a message sending by an entity (client or server) and a message randomized by the firewall:

Client key exchange initialization: the client sends a message \((g^x,g^c,e=\mathsf {Enc}_{\mathsf {pk}_f}(c))\) where x and c was picked at random. The firewall sends a message \((g^{x'},g^{c'},e=\mathsf {Enc}_{\mathsf {pk}_f}(c'))\) where where \(x'=x\cdot \alpha _1\) and \(c' =c\cdot {\alpha _2} \), such that \(\alpha _1\) and \(\alpha _2\) was picked at random. Since \(\alpha _1\) and \(\alpha _2\) perfectly randomizes x and y, \((g^x,g^c,e=\mathsf {Enc}_{\mathsf {pk}_f}(c))\) and \((g^{x'},g^{c'},e=\mathsf {Enc}_{\mathsf {pk}_f}(c'))\) follow the same distribution.

Server response: if the server receives \((g^x,g^c,e=\mathsf {Enc}_{\mathsf {pk}_f}(c))\) from the client, it sends a message \((\sigma ,Y,D,\beta _1,\beta _2)\) where \(\beta _1\) and \(\beta _2\) are randomly chosen in \(\mathbb {Z}_p\), and such that \(\sigma \) is a valid signature on \((Y,D,g^{x\cdot \beta _1},g^{c\cdot \beta _2})\). if the server receives \((g^{x'},g^{c'},e=\mathsf {Enc}_{\mathsf {pk}_f}(c'))\) from the firewall, it sends a message \((\sigma ,Y,D,\beta _1,\beta _2)\) where \(\beta _1\) and \(\beta _2\) are randomly chosen in \(\mathbb {Z}_p\), and such that sigma is a valid signature on \((Y,D,g^{x'\cdot \beta _1},g^{c'\cdot \beta _2})\). The firewall then returns \((\sigma ,Y,D,\gamma _1,\gamma _2)\) where \(\gamma _i=\alpha _i\cdot \beta _i\), so \(\sigma \) is a valid signature on \((Y,D,g^{x\cdot \gamma _1},g^{c\cdot \gamma _2})\), and \((\sigma ,Y,D,\beta _1,\beta _2)\) and \((\sigma ,Y,D,\gamma _1,\gamma _2)\) follow the same distribution.

Transmission of a message: the client picks r at random an sends (r, s, t) where \(s\leftarrow H_1(r\Vert \mathsf {\mathsf {k}_{cfs}}) \oplus C\), and \(t\leftarrow \mathsf {MAC}_{H_1(r\Vert \mathsf {\mathsf {k}_{cfs}})}(r\Vert s)\). The firewall picks \(\tilde{r}\) at random an sends the message \((\tilde{r}, \tilde{s},\tilde{t})\) where \(\tilde{s}\leftarrow H_1(\tilde{r}\Vert \mathsf {\mathsf {k}_{cfs}}) \oplus C\), and \(\tilde{t}\leftarrow \mathsf {MAC}_{H_1(\tilde{r}\Vert \mathsf {\mathsf {k}_{cfs}})}(\tilde{r}\Vert \tilde{s})\), so (r, s, t) and \((\tilde{r}, \tilde{s},\tilde{t})\) follow the same distribution.

References

1.
Bellare, M., Paterson, K.G., Rogaway, P.: Security of symmetric encryption against mass surveillance. In: Garay, J.A., Gennaro, R. (eds.) CRYPTO 2014. LNCS, vol. 8616, pp. 1–19. Springer, Heidelberg (2014). https://doi.org/10.1007/978-3-662-44371-2_1CrossRefGoogle Scholar
2.
Bellare, M., Rogaway, P.: Entity authentication and key distribution. In: Stinson, D.R. (ed.) CRYPTO 1993. LNCS, vol. 773, pp. 232–249. Springer, Heidelberg (1994). https://doi.org/10.1007/3-540-48329-2_21CrossRefGoogle Scholar
3.
Black, J., Rogaway, P., Shrimpton, T.: Encryption-scheme security in the presence of key-dependent messages. In: Nyberg, K., Heys, H. (eds.) SAC 2002. LNCS, vol. 2595, pp. 62–75. Springer, Heidelberg (2003). https://doi.org/10.1007/3-540-36492-7_6CrossRefzbMATHGoogle Scholar
4.
Brzuska, C., Jacobsen, H., Stebila, D.: Safely exporting keys from secure channels. In: Fischlin, M., Coron, J.-S. (eds.) EUROCRYPT 2016. LNCS, vol. 9665, pp. 670–698. Springer, Heidelberg (2016). https://doi.org/10.1007/978-3-662-49890-3_26CrossRefGoogle Scholar
5.
Canetti, R., Krawczyk, H.: Universally composable notions of key exchange and secure channels. In: Knudsen, L.R. (ed.) EUROCRYPT 2002. LNCS, vol. 2332, pp. 337–351. Springer, Heidelberg (2002). https://doi.org/10.1007/3-540-46035-7_22CrossRefGoogle Scholar
6.
Checkoway, S., et al.: A systematic analysis of the juniper dual EC incident. In: ACM SIGSAC 2016, pp. 468–479 (2016)Google Scholar
7.
Checkoway, S., et al.: On the practical exploitability of dual EC in TLS implementations. In: USENIX 2014, pp. 319–335 (2014)Google Scholar
8.
Chen, R., Mu, Y., Yang, G., Susilo, W., Guo, F., Zhang, M.: Cryptographic reverse firewall via malleable smooth projective hash functions. In: Cheon, J.H., Takagi, T. (eds.) ASIACRYPT 2016. LNCS, vol. 10031, pp. 844–876. Springer, Heidelberg (2016). https://doi.org/10.1007/978-3-662-53887-6_31CrossRefGoogle Scholar
9.
Dodis, Y., Mironov, I., Stephens-Davidowitz, N.: Message transmission with reverse firewalls—secure communication on corrupted machines. In: Robshaw, M., Katz, J. (eds.) CRYPTO 2016. LNCS, vol. 9814, pp. 341–372. Springer, Heidelberg (2016). https://doi.org/10.1007/978-3-662-53018-4_13CrossRefGoogle Scholar
10.
Dowling, B., Fischlin, M., Günther, F., Stebila, D.: A cryptographic analysis of the TLS 1.3 handshake protocol candidates. In: ACM CCS 2015, pp. 1197–1210 (2015)Google Scholar
11.
Gamal, T.E.: A public key cryptosystem and a signature scheme based on discrete logarithms. In: CRYPTO 1984, pp. 10–18 (1984)Google Scholar
12.
Grahm, R.: Extracting the SuperFish certificate (2015). http://blog.erratasec.com/2015/02/extracting-superfish-certificate.html
13.
Jager, T., Kohlar, F., Schäge, S., Schwenk, J.: On the security of TLS-DHE in the standard model. In: Safavi-Naini, R., Canetti, R. (eds.) CRYPTO 2012. LNCS, vol. 7417, pp. 273–293. Springer, Heidelberg (2012). https://doi.org/10.1007/978-3-642-32009-5_17CrossRefzbMATHGoogle Scholar
14.
Kohlweiss, M., Maurer, U., Onete, C., Tackmann, B., Venturi, D.: (De-)constructing TLS 1.3. In: Biryukov, A., Goyal, V. (eds.) INDOCRYPT 2015. LNCS, vol. 9462, pp. 85–102. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-26617-6_5CrossRefGoogle Scholar
15.
Krawczyk, H., Paterson, K.G., Wee, H.: On the security of the TLS protocol: a systematic analysis. In: Canetti, R., Garay, J.A. (eds.) CRYPTO 2013. LNCS, vol. 8042, pp. 429–448. Springer, Heidelberg (2013). https://doi.org/10.1007/978-3-642-40041-4_24CrossRefGoogle Scholar
16.
Krawczyk, H., Wee, H.: The OPTLS protocol and TLS 1.3. In: Proceedings of Euro S&P, pp. 81–96 (2016)Google Scholar
17.
Ma, H., Zhang, R., Yang, G., Song, Z., Sun, S., Xiao, Y.: Concessive online/offline attribute based encryption with cryptographic reverse firewalls—secure and efficient fine-grained access control on corrupted machines. In: Lopez, J., Zhou, J., Soriano, M. (eds.) ESORICS 2018. LNCS, vol. 11099, pp. 507–526. Springer, Cham (2018). https://doi.org/10.1007/978-3-319-98989-1_25CrossRefGoogle Scholar
18.
Mironov, I., Stephens-Davidowitz, N.: Cryptographic reverse firewalls. In: Oswald, E., Fischlin, M. (eds.) EUROCRYPT 2015. LNCS, vol. 9057, pp. 657–686. Springer, Heidelberg (2015). https://doi.org/10.1007/978-3-662-46803-6_22CrossRefGoogle Scholar
19.
Naylor, D., et al.: Multi-context TLS (mcTLS) enabling secure in-network functionality in TLS. In: SIGCOMM 2015, pp. 199–212 (2015)Google Scholar
20.
O’Neill, M., Ruoti, S., Seamons, K., Zappala, D.: TLS proxies: friend or foe. In: IMC 2016, pp. 551–557 (2016)Google Scholar
21.
Rogaway, P.: The moral character of cryptographic work (2015). http://web.cs.ucdavis.edu/rogaway/papers/moral-fn.pdf
22.
Young, A., Yung, M.: Kleptography: using cryptography against cryptography. In: Fumy, W. (ed.) EUROCRYPT 1997. LNCS, vol. 1233, pp. 62–74. Springer, Heidelberg (1997). https://doi.org/10.1007/3-540-69053-0_6CrossRefGoogle Scholar

Copyright information

Authors and Affiliations

Angèle Bossuat
- 1
Email author
Xavier Bultel
- 4
Pierre-Alain Fouque
- 1
Cristina Onete
- 2
Thyla van der Merwe
- 3

1.Univ Rennes, CNRS, IRISARennesFrance
2.University of Limoges/XLIM/CNRSLimogesFrance
3.MozillaLondonUK
4.LIFO, INSA Centre Val de Loire, Université d’OrléansBourgesFrance

Designing Reverse Firewalls for the Real World

Abstract

Notes

Acknowledgements

Supplementary material

References

Copyright information

Authors and Affiliations

Personalised recommendations

Cite paper