ACM Transactions on Computer Systems (TOCS)
Reasoning about knowledge
An attack on the Needham-Schroeder public-key authentication protocol
Information Processing Letters
IEEE Transactions on Software Engineering
The inductive approach to verifying cryptographic protocols
Journal of Computer Security
Verifying security protocols as planning in logic programming
ACM Transactions on Computational Logic (TOCL) - Special issue devoted to Robert A. Kowalski
Honest Ideals on Strand Spaces
CSFW '98 Proceedings of the 11th IEEE workshop on Computer Security Foundations
Athena: a New Efficient Automatic Checker for Security Protocol Analysis
CSFW '99 Proceedings of the 12th IEEE workshop on Computer Security Foundations
Automated analysis of cryptographic protocols using Mur/spl phi/
SP '97 Proceedings of the 1997 IEEE Symposium on Security and Privacy
SP'96 Proceedings of the 1996 IEEE conference on Security and privacy
Electronic Notes in Theoretical Computer Science (ENTCS)
On Mobile Agents Resistance to Traffic Analysis
Electronic Notes in Theoretical Computer Science (ENTCS)
| Hi-index | 0.00 |
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.