Do not model the attacker

Authors:
Jan Meier
Affiliations:
Security in Distributed Applications, Hamburg University of Technology, Germany
Venue:
Security'08 Proceedings of the 16th International conference on Security protocols
Year:
2008

Citing 12
Cited 0

An attack on the Needham-Schroeder public-key authentication protocol

Information Processing Letters
Timestamps in key distribution protocols

Communications of the ACM
A method for obtaining digital signatures and public-key cryptosystems

Communications of the ACM
Using encryption for authentication in large networks of computers

Communications of the ACM
The security of the cipher block chaining message authentication code

Journal of Computer and System Sciences
Handbook of Applied Cryptography

Handbook of Applied Cryptography
Breaking and Fixing the Needham-Schroeder Public-Key Protocol Using FDR

TACAs '96 Proceedings of the Second International Workshop on Tools and Algorithms for Construction and Analysis of Systems
A Concrete Security Treatment of Symmetric Encryption

FOCS '97 Proceedings of the 38th Annual Symposium on Foundations of Computer Science
Logic in Computer Science: Modelling and Reasoning about Systems

Logic in Computer Science: Modelling and Reasoning about Systems
Key Infection: Smart Trust for Smart Dust

ICNP '04 Proceedings of the 12th IEEE International Conference on Network Protocols
Computer Security 2e

Computer Security 2e
Challenges in Securing Networked J2ME Applications

Computer

Quantified Score

Hi-index	0.00

Visualization

Abstract

We identify attacker modelling as major obstacle when searching for ways to defeat security protocols. For protocols verified to be secure, attacks are discovered. Since this problem is not limited to the Dolev-Yao attacker but applies to all modelled attackers, we propose a new approach. We argue that formal verification methods should be used to show the impact of analyst provided actions have on protocols. This approach frees verification tools from having to know all the actions an attacker could perform. We show the benefits of having both the security proof and an explicit list of considered actions. Implementers can easily determine if the protocol is suited for their application. Additionally, developers understand the requirements an implementation has to fulfil. Lastly, our approach allows proofs to be adapted to new environments without changing the verification tool.