Ross J. Anderson
- 1 Abadi M. and Needham R. M. Prudent Engineering Practice for Cryptographic Protocols. Tech Rep. 125, DEC SRC, June 1994.Google Scholar
Cross Ref
- 2 Anderson R.J. WEPS - Asecond generation Electronic Wallet. In Computer Security - ESORICS 92. Lecture Notes in Computer Science, vol. 648, Springer Verlag, New york, pp.411-418. Google Scholar
- 3 Anderson R. J. Why Cryptosystems fail. In Proceedings of the 1993 ACM Conference in Computer and Communications Security, pp. 215-227. Google ScholarDigital Library
- 4 Anderson R. J. The classification of hash functions. IN proceedings of the 4th IMA conference in Cryptography and Coding (1993). To be published.Google Scholar
- 5 Baskerville, R. Information systems secuity design methods: implications for information systems development. ACM Computing Surveys 25, 4 (Dec. 1993), 375 - 414. Google ScholarDigital Library
- 6 Boyd C., and Mao, W. B. Limitations of logical analysis of cryptographic prtocols. In Pre-proceedings of Eurocrypt 93, pp. T88-T96.Google Scholar
- 7 Brooks, F.P. Teh mythical Man-Month: Essays on software Engineering. Adisson-Wesley, Reading, Mass., 1975. Google ScholarDigital Library
- 8 Bull J. A., Gong L., and Sollins K. Towards security in an open systems federation. In proceedings of ESORICS 92. Lecture notes in Computer Science, vol. 648. Springer- Verlag, Nem York, pp. 3-20. Google ScholarDigital Library
- 9 Burrows M., Abadi M., and Needham R. M. A logic of authentication. In proceedings of the Royal Scoiety of London A, vol. 426, 1989, pp. 233 - 271.Google ScholarCross Ref
- 10 Butler R. W., and Finelli G. B. Teh infeasibility of experimnetal quantification of life-critical software reliability. In Proceedings of the ACM Symposium on Software for Critical systems, New Orleans, La., Dec. 1991, pp 66-76. Google ScholarDigital Library
- 11 Faigin D.P., Donndelinger J. J., and Jones J. R. A rigurous approach to determining objects. In Proceedings of the 9th Annual Commputer Security Applications Conference, IEEE, 1993, pp. 159-168.Google ScholarCross Ref
- 12 Gong L. Thoughts on Cryptographic protocols. In Proceedings of the 1993 Cambridge protocols Workshop. Lecture Notes in Computer Science. Springer-Verlag, NewYork. To be published.Google Scholar
- 13 Highland H.J. Perspectvices in information technology security. In PRoceedings of the 1992 IFIP Congress, Education and SOciety. IFIP A-13 vol. 2, 1992, pp. 440-446. Google ScholarDigital Library
- 14 Jack R. B. (chairman) Banking services: law and practice Review Committe, HMSO, London, 1989.Google Scholar
- 15 Dorothy Judd v Citibank, in 435 NYS, 2d series, pp. 210-212, 107 Misc. 2d 526.Google Scholar
- 16 Kahn D. The codebreakers. Macmillan, New York, 1967.Google Scholar
- 17 Landwehr C.E. Bull, A.R. McDermott J. P. and Choi, W. S. A taxanomy of computer program security flaws, with examples. U.S. Naval Research Laboratory report NRL/FR/5542-93-9591.Google Scholar
- 18 Lewis B. how tro rob a bank the cash card way, Thje Sunday Telegraph, 25 April 1993, p. 5.Google Scholar
- 19 Macrae, N. Sir Humphrey fudges his half-reforms, The Sunday Times 17 July 1994, sec.4, p.4.Google Scholar
- 20 McDermid, J.A. Issues in the development of safety critical systems. Public Lecture, Cambridge, 3 Feb. 1993.Google Scholar
- 21 Meyer, C.H., and Matyas, S.M. Cryptography: A New Dimension in Computer Data Security, John Wiley & Sons, New York, 1982.Google Scholar
- 22 Morris, R. In Proceedings of the 1993 Cambridge Protocols Workshop. Lecture Notes in Computer Science. Springer-Verlag, New York. To be published.Google Scholar
- 23 U.S. Department of Defence, Trusted Computer System Evalution Criteria, 5200.28-STD, December 1985.Google Scholar
- 24 Wiener, M.J. Efficient DES Jey Search, Technical Report TR-244, School of Computer Science, Carleton University, Ottawa, May 1994.Google Scholar
- 25 Woo., T.Y.C. and Lam, S.S. A semantic model for aythentication protocols. In Proceedings of the 1993 IEEE Computer Society Syposium on Research in Security and Privacy, pp. 178-194. Google ScholarDigital Library
Index Terms
- Why cryptosystems fail
Recommendations
Securely combining public-key cryptosystems
CCS '01: Proceedings of the 8th ACM conference on Computer and Communications SecurityIt is a maxim of sound computer-security practice that a cryptographic key should have only a single use. For example, an RSA key pair should be used only for public-key encryption or only for digital signatures, and not for both.In this paper we show ...
Fail-Stop Signatures
Fail-stop signatures can briefly be characterized as digital signatures that allow the signer to prove that a given forged signature is indeed a forgery. After such a proof has been published, the system can be stopped. This type of security is strictly ...
Chosen ciphertext secure keyed-homomorphic public-key cryptosystems
In homomorphic encryption schemes, anyone can perform homomorphic operations, and therefore, it is difficult to manage when, where and by whom they are performed. In addition, the property that anyone can "freely" perform the operation inevitably means ...
Reviews
Jonathan K. Millen
The first part of this paper presents about 20 fascinating examples of security failures, from the author's experience as a security consultant for the banking industry in the UK. The stories suggest that it is not at all paranoid for me to hide my PIN from the person behind me at the ATM, or to worry about what the clerks in the bank might be able to do. In one case where a clerk issued an extra card for himself for a customer's account, “the thief was only discovered because he suffered an attack of conscience and confessed.” This leads to the familiar observation that “almost all attacks on banking systems involved blunders, insider involvement, or both.” While strong cryptographic mechanisms are seen as necessary, they are difficult to integrate into larger systems, particularly since the day-to-day administrative staff do not have the relevant specialized knowledge. Anderson suggests that the crucial property we need for security products is robustness, which is essentially the ability to maintain adequate function despite occurrences of faults or failures of the kind that might be expected. While there is no “silver bullet” for robustness, a lesson can be learned from the more narrowly focused problems with authentication and key distribution protocols: the first step is to systematically identify assumptions on which security rests. Then ask which of those might sometimes fail, such as the honesty of a clerk. Four principles quoted from a software safety engineering paper are recommended as a way to carry out this approach. Overall, this paper is more advice than how-to, but the suggestions near the end are constructive and specific enough to be taken seriously.
Access critical reviews of Computing literature here
Become a reviewer for Computing Reviews.
Comments