A Protocol’s Life After Attacks...
In the analysis of security protocols, it is customary to stop as soon as we find an attack. Tons of ink can be spilled on whether an “attack” is really an attack, but it goes without saying that there is no life after that, hence no interest in continuing the analysis. If the protocol is broken, then we ought to fix it.
Yet, fixing things is expensive and other measures may be more effective. In the physical world, most ATM safes would not resist heavy shelling with anti-tank bazookas, but banks don’t worry about that. The attack will be noisy enough that cops will come within seconds from its start. To secure ourselves, we rely on a mixture of measures including the protection from attacks but also countermeasures after detection.
In the light of these considerations, the following question becomes of interest: what can happen after an attack? Does the villain leave enough traces that we can retaliate it on-the-fly? Or, if we can’t or won’t, does a subsequent forensic analysis allow us to discover who did it (and send the cops behind him)? If even this is impossible, can we discover that we have been hacked by looking at the logs?
To address these issues, we introduce the notions of retaliation, detection, and suspicion, which can be applied after an attack. These properties introduce more sophisticated formal relations between traces of actions, which go beyond the simple existentials that formal methods have made us used to.
These concepts should allow for a more comprehensive evaluation of security protocols. A protocol may well be vulnerable to an attack, but if we can retaliate afterwards, maybe fixing it isn’t that necessary: the concrete possibilities of retaliation or detection may be enough to convince potential hackers to refrain from mounting the attack.
KeywordsModel Check IEEE Computer Society Security Protocol Cryptographic Protocol Strand Space
Unable to display preview. Download preview PDF.
- 7.Mitchell, J., Mitchell, M., Stern, U.: Automated analysis of cryptographic protocols using Murphi. In: Proceedings of the 16th IEEE Symposium on Security and Privacy, pp. 141–151. IEEE Computer Society Press, Los Alamitos (1997)Google Scholar
- 8.Paulson, L.C.: The inductive approach to verifying cryptographic protocols. Journal of Computer Security 6, 85–128 (1998)Google Scholar
- 10.Schneider, S.: Security properties and CSP. In: Proceedings of the 15th IEEE Symposium on Security and Privacy, pp. 174–187. IEEE Computer Society Press, Los Alamitos (1996)Google Scholar
- 11.Song, D.: Athena: An automatic checker for security protocol analysis. In: Proceedings of the 12th IEEE Computer Security Foundations Workshop. IEEE Computer Society Press, Los Alamitos (1999)Google Scholar
- 12.Thayer Fabrega, F., Herzog, J., Guttman, J.: Honest ideals on strand spaces. In: Proceedings of the 11th IEEE Computer Security Foundations Workshop. IEEE Computer Society Press, Los Alamitos (1998)Google Scholar