Lessons Learned in Implementing and Deploying Crypto Software

Although the basic building blocks for working with strong encryption have become fairly widespread in the last few years, experience has shown that implementers frequently misuse them in a manner that voids their security properties. At least some of the blame lies with the tools themselves, which often make it unnecessarily easy to get things wrong. Just as no chainsaw manufacturer would think of producing a model without a finger-guard and cutoff mechanism, so security software designers need to consider safety features that will keep users from injuring themselves or others. This paper examines some of the more common problem areas that exist in crypto security software, and provides a series of design guidelines that can help minimise damage due to (mis-)use by inexperienced users. These issues are taken from extensive real-world experience with users of security software, and represent areas that frequently cause problems when the software is employed in practice.

[1]  John T. Kohl,et al.  The Kerberos Network Authentication Service (V5 , 2004 .

[2]  Ravi Ganesan,et al.  Yaksha: augmenting Kerberos with public key cryptography , 1995, Proceedings of the Symposium on Network and Distributed System Security.

[3]  FrazerKen Building secure software , 2002 .

[4]  Gene Tsudik,et al.  KryptoKnight Authentication and Key Distribution System , 1992, ESORICS.

[5]  Ravi Ganesan,et al.  The Yaksha security system , 1996, CACM.

[6]  Peter G. Neumann,et al.  Inside risks: the clock grows at midnight , 1991, CACM.

[7]  Peter Gutmann,et al.  The Design of a Cryptographic Security Architecture , 1999, USENIX Security Symposium.

[8]  J. Doug Tygar,et al.  Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0 , 1999, USENIX Security Symposium.

[9]  Leslie Lamport,et al.  Time, clocks, and the ordering of events in a distributed system , 1978, CACM.

[10]  Martín Abadi,et al.  Prudent engineering practice for cryptographic protocols , 1994, Proceedings of 1994 IEEE Computer Society Symposium on Research in Security and Privacy.

[11]  Robert R. Moeller,et al.  Network Security , 1993, Inf. Secur. J. A Glob. Perspect..

[12]  Moti Yung,et al.  The KryptoKnight family of light-weight protocols for authentication and key distribution , 1995, TNET.

[13]  Dan Boneh,et al.  Proceedings of the 11th USENIX Security Symposium , 2002 .

[14]  Tara Whalen,et al.  ssmail: Opportunistic Encryption in sendmail , 1999, LISA.

[15]  Moti Yung,et al.  Systematic Design of Two-Party Authentication Protocols , 1991, CRYPTO.

[16]  Ross J. Anderson Why cryptosystems fail , 1994, CACM.

[17]  Moshe Rozenblit,et al.  Security for telecommunications network management , 1999 .

[18]  Peter Gutmann,et al.  PKI: It's Not Dead, Just Resting , 2002, Computer.

[19]  Carlisle M. Adams,et al.  Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) , 2001, RFC.

[20]  Radia Perlman,et al.  Network Security , 2002 .

[21]  Mary Ellen Zurko,et al.  User-centered security , 1996, NSPW '96.

[22]  Li Gong,et al.  A security risk of depending on synchronized clocks , 1992, OPSR.

[23]  B. Clifford Neuman,et al.  A note on the use of timestamps as nonces , 1993, OPSR.

[24]  David A. Wagner,et al.  Intercepting mobile communications: the insecurity of 802.11 , 2001, MobiCom '01.

[25]  Mary Ellen Zurko,et al.  Jonah: Experience Implementing PKIX Reference Freeware , 1999, USENIX Security Symposium.

[26]  Bruce Schneier,et al.  Practical cryptography , 2003 .

[27]  David LeBlanc,et al.  Writing Secure Code , 2001 .

[28]  Steven M. Bellovin,et al.  Limitations of the Kerberos authentication system , 1990, CCRV.