Key Note Speech: Peter G. Neumann Peter Neumann of SRI International substituted for Taher Elgamal as the key note speaker. Most of the talk dealt with issues such as security, survivability, reliability, and predictable behavior. Neumann has many claims to fame including the moderation of comp.risks and a 1965 publication on file system access control in Multics. Neumann used stories, quotations, and ever-so-clever puns to discuss principles for good software engineering. Past efforts fundamental to software engineering include Multics, T.H.E. system, domains of protection, principles, confined execution, PSOS (a provably secure OS by PGN), and isolated kernels. But most existing commercial systems are fundamentally inadequate with respect to reliability and security. Survivability is also not well understood. Unfortunately, not much good research is finding its way into products. Developers ignore the risks, and the same old flaws appear over and over. For instance, 8 of 13 CERT reports this past year resulted from buffer overflows. Programming languages do little to prevent security problems. Few systems are easy to evolve. Neumann challenged the old adage of KISS (Keep It Simple Stupid). He argued that such advice does not work for extremely complex systems. He also disagreed the "build one to throw away" principle of Brooks because this encourages companies to perform beta testing with normal users. There remains much to be learned from past mistakes; these problems are highly multiple dimensioned. However, Neumann reasoned that we do not learn much from failures because the builders tend to move on to something else or build another system with the same problems. The insider problem is largely ignored. This is a difficult problem to solve because the insider is already authorized. In defense of Wen Ho Lee, Neumann referenced the Los Alamos National Laboratory incident as an example. Merely shutting out access of outsiders will not solve the problem. You have to worry about insiders. Neumann recommended that developers specify general requirements, create stronger protocols, use good cryptographic infrastructures, design for interoperability, force commercial developers to do the right thing (maybe with open source), perform network monitoring and analysis, and find a good way to integrate systems. The Q/A section mainly consisted of additional stories from the audience. Matt Blaze asked the rhetorical question, "Why in poorly designed systems does everything become part of the trusted computing base? Why limit [this characterization] to only poorly designed systems?" A punny John Ioannidis explained that Neumann is not "preaching to the choir" but to "lots of soloists." People do not listen to the soloists. Ioannidis argued that education of users is just as important as proper engineering practice. Otherwise uneducated users will simply bring in the Trojan horse. The discussion led to an insane number of analogies about singing and security. Causing the crowd to erupt with laughter, Greg Rose said it's amazing we can build great flight simulators and all, but we can't build good air traffic control systems. A philosophical Dan Geer quizzed Neumann on the difference between brittle and fragile. Neumann responded that brittle means an object breaks when tapped a bit; fragile means the object will probably fall off the shelf. In Multics, a failure in ring 0 would cause the whole system to collapse. A failure in ring 1 would only cause the the process to crash. In ring 2, a failure might only generate an error message. The rings contained the error. What is Neumann's final prognosis? All reports conclude that the state of practice is not good. Risks abound. For related information including a pointer to the Risks archive, see http://www.csl.sri.com/neumann/ PDAs Refereed Papers Track Session Chair: Jim Duncan, Cisco Systems, Inc. ---- The Design and Analysis of Graphical Passwords Ian Jermyn, New York University; Alain Mayer, Fabian Monrose, Michael K. Reiter, Bell Labs, Lucent Technologies; Aviel Rubin, AT&T Labs - Research Fabian Monrose analyzed the security of graphical passwords and proposed two graphical password schemes which could achieve better security than textual passwords. This paper not only won the best student paper award, but it also won the best overall paper award. In spite of textual passwords falling vulnerable to dictionary attacks, passwords still serve as the dominant authentication mechanism today. On the other hand, graphical passwords have convincing evidence showing better memorability and less information revealed about its distribution. Results from cognitive science show that people can remember pictures much better than words. Combining this with the commonly found Personal Digital Assistant (PDA) allows new graphical input capabilities. Graphical schemes can decouple position from the temporal order in which a password is entered. Monrose listed three desired properties of graphical passwords. First, it must be at least as difficult to exhaustively search as traditional passwords. Second, keys must not be stored in clear. Third, graphical passwords need to be repeatable and memorable. After building a strawman scheme where graphical passwords can emulate textual passwords, Monrose described a second scheme, dubbed Draw-a-secret. It takes as input a picture and order of its drawing. This scheme keeps track of boundary crossings and pen lifts from the screen. This information then passes though a hash function to produce a raw bit string as a password. Monrose pointed out that there is yet no characterization of the distribution of graphical passwords. This means one picture is not known to be more likely than another as a password. On the other hand, textual passwords have well-known distributions related to dictionaries. Rather than focus on the unrealistic upper bound of graphical password choices, Monrose analyzed a minimum bound by creating a grammar (similar to LOGO) which describes common ways to enter a graphical password. By further assigning complexities to the terminals, evidence indicates that graphical passwords with short complexities (pen strokes) can surpass the power of textual passwords. Peter Honeyman went into an evil thesis committee mode by shaking the earth with many difficult and antagonizing questions. Assuming at least 60 bits of entropy are necessary to protect confidential information, Honeyman questioned whether 5 pen strokes in a 5x5 grid is enough. Monrose did not answer the question directly. Another audience member asked what would be the typical graphical password (a smiley face, picture of a dog, etc). Suggesting that attacks similar to dictionary attacks may exist, the audience member asked how to classify what is memorable. Monrose explained that his team did not have enough experience to characterize distributions. Another audience member asked for anecdotal evidence about memorability. Monrose explained that in practice, a 6x6 grid results in poor memorability. It's simply too fine-grained for the average user to repeatedly enter a graphical password correctly. The 5x5 grid creates a good balance between security and memorability. Peter Neumann pointed out that written Chinese has a known key stroke order that may impose a distribution. Graphical passwords may pose a challenge for writers of Chinese. While a native writer of Chinese confirmed Neumann's point, she believed the graphical passwords have good merit. Asked about incorporating timing and pressure for entropy, Monrose replied that it has not been considered. Neumann added that his group found pen pressure useless as a source of entropy. While there is no concrete proof that graphical passwords are stronger than textual passwords, Monrose gave convincing evidence that graphical passwords stand a good chance and at least deserve further analysis. In the future, Monrose hopes to better classify memorability of graphical passwords. For source code and further information, see http://cs.nyu.edu/fabian/pilot/ ---- Hand-Held Computers Can Be Better Smart Cards Dirk Balfanz, Edward W. Felten, Princeton University Dirk Balfanz reasoned how a PDA can serve as a better smart card. By implementing a PKCS#11 plugin for Netscape Communicator and the 3Com PalmPilot, Balfanz reduced the number of components in the Trusted Computing Base (TCB). The trusted part of system remains only on the Pilot. Smart cards usually do not have a trusted authentication path to the user. The user often communicates a secret PIN to the smart card via a PC and smart card reader. This places the PC and smart card reader in the TCB! Had any malicious software existed on the PC, it could have easily obtained digital signatures of bogus data. Of course, a user interface or warning light on the smart card could prevent such malicious use. Unfortunately, most smart cards do not have a user interface. The implementation of PilotKey currently works for Linux, Win9X, Solaris, and Windows NT in concert with Netscape Communicator and the Pilot. Preliminary results show a 512-bit RSA signature takes about 5 seconds, and key generation about 2-3 minutes. However, a 1024-bit RSA signature takes 25 seconds and a whopping 30 minutes for key generation. Balfanz pointed out that the Pilot uses something like a 16MHz processor. He expects the processor to speed up in the future. The PilotKey program implements the PKCS#11 functions for the Pilot. The program enables a user to provide randomness via the user interface. Because PilotKey works directly with the user, the PC does not see the PIN. Finally, the program lets the user choose whether to send decrypted messages back to the PC. Incidentally, PilotKey cannot securely handle email attachments unless you can perform base64 decoding in your head. Alas, the Pilot does exhibit some problems acting as a smart card. First, the Pilot is not tamper resistant, and the operating system does not provide memory isolation among programs. Hence, one should not use untrusted software on the Pilot in conjunction with PilotKey. Second, it is important not to loose the Pilot. While the secret information is password-protected, this offers only limited protection. Third, the PilotKey is not appropriate for "owner-is-enemy" applications. For instance, a program keeping track of a cash balance is inappropriate. The Pilot owner could easily change the balance. Finally, HotSyncing could reveal secrets to the host computer. Balfanz claimed these problems are not show stoppers. Inciting a few chuckles, he explained that you "just need a secure OS on the Pilot." In the paper, Balfanz makes some good suggestions on how to secure the Pilot OS. Peter Honeyman began the inquisition with a hail of questions. Another audience participant reminded the rest of the crowd to turn off the Pilot's IR when not in use. One questioner asked why not to fix the OS on the PC if we can just fix the OS on Pilot as suggested. Balfanz admitted this is the same problem, but fixing the OS on the PC is not any easier. At this point, a punny Peter Neumann sought attention. He pointed out that this was the first talk where Bob does not appear with Alice. Alles in Ordnung.
You would have had to be there to understand.... A participant suggested that splitting trust seems to simply push the problem down the line. People will want more features (e.g., signed Excel spreadsheets). Balfanz explained that shifting trust to PDA comes at expense of usability. Another participant argued that removing all the software from a Pilot results in a relatively expensive smart card. Questioned about Europe's desire for autonomous smart card readers and smart cards with displays, Balfanz responded that he would not trust the ATM or the reader. Bruce Schneier wrote a similar paper on splitting trust in the first USENIX Symposium on Smart Cards last May. For more information on PilotKey, follow up with firstname.lastname@example.org. ---- Offline Delegation in the File Repository Arne Helme, Tage Stabell-Kulø, University of Tromsø, Norway Arne Helme explained mechanisms for offline delegation of access rights to files in the context of a distributed File Repository (FR). In this model each user has her own file repository, but would like to share files. Offline delegation refers to delegating authority without network connectivity. For instance, one could use verbal delegation. PDAs challenge centralized security models, provide users with personal TCBs, and support the construction of "delegation certificates." This meshes well with the design criteria for offline delegation: a delegation should not allow impersonation, credentials must form valid and meaningful access rights, and the authority granted in a certificate should not be transferable or valid for multiple use. The implementation consists of an access request protocol and a prototype for the 3Com PalmPilot. The software contains a parser/generator for SDSI-like certificates and a short digital signature scheme using elliptic curve cryptography. The access request protocol (analyzed with BAN logic in the paper) describes the process of creating, delegating, and using offline certificates. The delegator must read 16 4-digit hexadecimal numbers to convey an offline certificate (e.g., by phone). Helme's Pilot software allows the delegatee to quickly receive these numbers via a convenient user interface. Helme clarified that certificates in this scheme are valid for only one use. Servers keep a replay cache. One problem with the current signature scheme is that the FR cannot distinguish between two different files which had the same file name at different times. Helme concluded that offline delegation is a natural extension of services to the File Repository, PDAs support verbal delegation, and performance is satisfactory. For more information, contact email@example.com. Keys Refereed Papers Track Session Chair: Carl Ellison, Intel Corporation ---- Building Intrusion-Tolerant Applications with ITTC Thomas Wu, Michael Malkin, and Dan Boneh - Stanford University Tom Wu discussed how applications can store and use private keys in an intrusion tolerant manner. As a side benefit, Wu's methods also provide high availability of private keys. Existing public key architectures rely on non-shared keys or split-key storage. The private key is reconstructed, creating a single point of failure. Methods in Intrusion Tolerance via Threshold Cryptography (ITTC) create no single point of attack because private keys are never reconstructed. In Shamir's Threshold Scheme, a dealer generates a key and splits it into several shares for trustees. The trustees can later reconstruct the original key at a central location. In this scheme a dealer sees the original key and all the shares, creating a single point of failure. Compromise to the dealer's memory results in total disclosure of the key. Wu uses an intrusion-tolerant scheme which is not vulnerable to such a single point of failure. He employs methods due to Boneh and Franklin to generate a private key already in a shared form. To create shares, Wu uses an idea due to Frankel. Share servers apply the share to an operation (e.g., sign, decrypt, encrypt) rather than give the share to the application as if it were a dealer. Without a threshold number of results from the share servers, an adversary can not reconstruct the results of a private key operation. SSL protects the communication between the application and share servers. In order to break the ITTC scheme, an attacker must compromise multiple systems in a short period of time. One can also identify malicious share servers. Wu's implementation adds intrusion tolerance to a Certificate Authority and Apache web server. Integration of ITTC was trivial with the OpenSSL code. By relying on load balancing and multiple threads for parallelism, the ITTC adds only a 17% drop in throughput and 24% drop in latency when compared to non-ITTC RSA. Wu pointed out that this tolerable slowdown is insignificant considering the overhead of SSL session establishment. Wu concluded that ITTC improves security and reliability for servers and CAs. Meanwhile, the performance impact is minimal. An audience member asked about the security consequences of an intruder obtaining a core file from such an intrusion-tolerant web server. Wu happily replied that the intruder could only retrieve the result of a single decryption, not the private key of the web server. At no single point is the key entirely reconstructed. For more information, see http://www.stanford.edu/~dabo/ITTC/. ---- Brute Force Cryptanalysis on UNIX Passwords with SIMD Computer Gershon Kedem and Yuriko Ishihara, Duke University Gershon Kedem gave an overview of brute force cryptanalysis. He listed the primary barriers to brute force: expertise, non-recurring time and cost, access to tools and technology, replication costs, reusability, and performance. Based on work with a SIMD computer, he proposed a design of a SIMD computer dedicated to brute force cryptanalysis. Kedem spent a long time on a table comparing the experience, cost, and time necessary for brute force when using software, FPGAs, ASICs, and custom chips. See the paper for the table. Because the talk spent so much time summarizing past research, the audience mostly lost touch with the contributions from this paper. A Single Instruction Multiple Data (SIMD) machine is made of a large array of small processors. This configuration makes it possible to get close to the theoretical limits of the processor. PixelFlow is a SIMD machine made of many flow units. Each flow unit includes an array of 8192 processing elements. Using 147,456 PixelFlow SIMD processors, Kedem was able to perform brute force cryptanalysis of 40-bit RC4 (38,804,210 key checks/second) and the UNIX crypt scheme (24,576,000 UNIX password checks/second). PixelFlow could try all 40-bit key combinations for a particular RC4 ciphertext in about 7.87 hours. Because UNC Chapel Hill created the PixelFlow machine for image generation, it does have some limitations when used for cryptanalysis. It has few registers, no dedicated shift unit, no pipelining, and no memory indexing. The lack of memory indexing prevents fast table lookups. Had PixelFlow used memory indexing, Kedem explained there would have been a 64X speedup for RC4 and a 32X speedup for DES (but the speedups from Kedem's talk are twice that of the figures in the paper). These limitations are specific to PixelFlow, not SIMD machines in general. Kedem then proposed a SIMD design for brute force cryptanalysis and compared this to FPGA-based machines. Adi Shamir's TWINKLE project was one buzzword mentioned in this talk. However, an audience participant pointed out that TWINKLE does not take into account that LEDs fade over time. For information related to brute force cryptanalysis, see http://theory.lcs.mit.edu/~rivest/bsa-final-report.ps or contact Kedem at Duke University. ---- Antigone: A Flexible Framework for Secure Group Communication Patrick McDaniel, Atul Prakash, and Peter Honeyman - University of Michigan Patrick McDaniel introduced Antigone, a flexible framework for defining and implementing secure group policies. To demonstrate the usefulness of Antigone, McDaniel integrated it into the vic secure video conferencing system. Antigone is unique in that it focuses on the following goals: * Applications can flexibly use a wide range of security policies * The system supports a range of threat models * It is independent of specific security infrastructures * It does not depend on the availability of a specific transport protocol * The performance overheads are low Taking into account that security policies vary from application to application, Antigone provides a basic set of mechanisms to implement a range of security policies. First, a session rekeying policy allows sensitivity to certain membership changes including join, leave, process_failure, and member_eject. Second, an application message policy guarantees types of security such as confidentiality, integrity, group authenticity, and sender authenticity. A third policy specifies what kind of membership information other members can obtain. The fourth policy determines under what circumstances can Antigone recover from failures. One participant asked how to demonstrate that all policies are complete. McDaniel explained that his current work does not have a complete answer. Another participant asked for comparisons between Antigone and other software to implement security policies. McDaniel responded that Antigone currently does not take into account peer groups, voting, negotiating protocols, or ciphers. However, he sees no fundamental reason preventing Antigone from addressing these issues. In the future, McDaniel hopes to investigate adaptive and role-based policies, implement new mechanisms, benchmark Antigone, and integrate the software with real applications. For more information, see http://antigone.citi.umich.edu/ or email firstname.lastname@example.org. Security Practicum Refereed Papers Track Session Chair: Wolfgang Ley, DFN-CERT ---- The Design of a Cryptographic Security Architecture Peter Gutmann, University of Auckland, New Zealand With longer hair than last year, Peter Gutmann gave a fast-paced talk on how to design a versatile, multi-platform, cryptographic architecture. The implementation works on many platforms ranging from 16-bit microcontrollers to supercomputers and ATMs. Most security toolkits specify an API, not an architecture. In contrast to the traditional outside-in approach, Gutmann's architecture takes a general cryptographic architecture, then wraps an interface around it. Gutmann built his architecture based on two concepts: objects encapsulate the architecture functionality while a security kernel enforces a consistent security policy. Each object has tightly controlled I/O for security reasons. Objects are either action objects (e.g., encrypt, decrypt, sign) or container objects. The containers further decompose into three object types: data containers, key and certificate containers, and security attributes. Gutmann found that C did not work well for implementing this architecture. The implementation comes in several languages ranging from C/C++ to Perl and VisualBasic. Gutmann also wrote a formal specification and used the Assertion Definition Language (ADL) to verify his code. An object can be in one of two states, low or high. In the low state, one can perform all allowed operations on the object. In the high state, one can only perform a limited, safe subset of those operations. An audience member asked whether Gutmann's design prevented an object from selecting from more than two states (i.e. whether it was implemented as something like a single bit flag). In Gutmann's experience, two states are sufficient. The security kernel supports an infinite number of states, but expecting the user to manage them all is very complex (they would have to track a complex FSM as an object moves from one state to another) and so far there has not been any real need to use more than two. Questioned about flexibility of message passing, Gutmann replied that his architecture supplies a fixed set of standard messages. Another participant felt that the cryptography seemed incidental to the talk. Finally, someone asked about performance issues with message passing through the security kernel. Gutmann found surprisingly little overhead from the message passing. He believes that the extreme multi-threading mitigated such performance hits. Everything is implemented in Gutmann's cryptlib library, which lives at http://www.cs.auckland.ac.nz/~pgut001/cryptlib/. ---- Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0 Alma Whitten, Carnegie Mellon University; J. D. Tygar, University of California at Berkeley Giving a breath of fresh air to the USENIX community, Alma Whitten raised serious issues about deficiencies in cryptographic user interfaces. The audience asked lots of questions and received the talk extremely well. After explaining user interfaces (UI), she spoke about the critical results of a usability evaluation of PGP 5.0. Recognizing that security is fundamentally different from traditional software, Whitten defined usability for security as: * A user can tell what needs to be done * A user can figure out how to do it * A user does not make dangerous errors * A user does not get annoyed and give up Whitten noted that applications such as word processors would focus on the second point. But one cannot assume the second point in security. For instance, in security the undo function cannot reverse the accidental mailing of plaintext. Whitten explained that "security is not a word processor" because of: * Unmotivated users (security is a secondary goal) * The barn door problem (the undo problem) * The abstraction problem * The software is only as strong as the weakest link * Lack of feedback Whitten chose PGP 5.0 with the Eudora plugin on a Macintosh for a case study because the interface was reasonably well designed by general consumer software standards. Her team used two methods to evaluate PGP: laboratory testing (objective, limited, and expensive) and cognitive walkthroughs (subjective, comprehensive, and cheap). The cognitive walkthrough showed that visual metaphors needed more thought. For instance, the quill head can confuse users. One user mixed up a .sig file with signatures. There is also information overload with too much visual data such as displaying the whole key ring and metadata. With respect to barn door and feedback problems, we need more protection against irreversible errors such as sending plaintext. In the laboratory test, users had 90 minutes to perform a series of actions. Users worked in the scenario of a political campaign. The user had to securely coordinate five virtual campaign members. The 12 participants were of a variety of ages from 20-49 years, education from some college to a doctoral degree, and backgrounds from fine arts to computer technology. Half of the participants were male. Everyone pretty much could generate key pairs (after a few users misunderstood by generating keys for each campaign member). 25% of the users managed to send plaintext instead of ciphertext. 2 of these 3 people realized the mistake. Several users encrypted the message with their own public key instead of the recipient's key. Nearly everyone fell into this trap. Eventually after receiving error messages from the virtual campaign members, the participants were able to send encrypted mail correctly. Half of the participants eventually encrypted a message. 25% did it without much help. By the time the first tests were done, only 5 people got far enough to decrypt a message. Most could decrypt. However, some mixed up ASCII-amoured keys with PGP messages since both look the same. The study concluded that PGP 5.0 with Eudora has a nice UI, but competent people in the target group could not handle this. Whitten suggests that to fix these deficiencies, one should simplify the UI, minimize what is less important, and add the right kind of help. A participant suggested that maybe the problem is the PGP model. Can we get a reasonable interface with PGP? Whitten responded that her group looked where the PGP model did not match with users' expectations. Avi Rubin asked how much documentation and training the test subjects received. Whitten gave each subject a printed, bound copy of PGP and Eudora manuals in addition to a quick tutorial on how to send email with Eudora. In other words, the test subjects had more resources than most users. Moreover, the test subjects read the manuals. Another audience member asked how many users did an out-of-band check to see if the encrypted messages worked. These details are in the paper, but Whitten noted that one technical person noticed the keys were signed and understood that trust in the key had to do with signatures on the key. The majority of users did not understand the trust metric. Derek Atkins humorously defended himself by saying he designed much of core API, but not UI for PGP. He asked about problems relating to confusion between various key types. Whitten said that one virtual campaign member had an RSA key and would complain to the test subjects about problems decrypting email. Only one subject figured out that the email had to be encrypted once with RSA and once with DSA. Greg Rose added his anecdote that USENIX used to run a heavily scripted keysigning. It worked well, but about 2/3 of messages would require human interaction. Another participant asked about the importance of interruptions (e.g., dialog box warnings) to the user about security. Whitten explained that there was no time to look at user tolerance levels. Ideally one would make the UI sufficiently obvious to prevent such dangers in the first place. Questioned about how much of the problems resulted from poor interaction with the Eudora plugin versus the core PGP interface, Whitten explained it is hard to divide. The UI needs a display to make it obvious what is encrypted and what is not. For further information, email email@example.com. Good quotation: "Security is not a word processor" - Whitten ---- Jonah: Experience Implementing PKIX Reference Freeware Mary Ellen Zurko, John Wray, Iris Associates; Ian Morrison, IBM; Mike Shanzer, Iris Associates; Mike Crane, IBM; Pat Booth, Lotus; Ellen McDermott, IBM; Warren Macek, Iris Associates; Ann Graham, Jim Wade, Tom Sandlin, IBM John Wray described the reference implementation of the Internet Engineering Task Force's (IETF) Public Key Infrastructure (PKIX). Wray explained the motivation behind the project. IBM needed a pervasive, open PKI for business; major vendors pledged support for PKIX; and there was a need for reference code to exercise the PKIX specifications. The team implemented as a C++ class library the PKIX specifications which consist of several RFCs for X.509, Certificate Management Protocols (CMP), Certificate Request Message Format (CRMF), and LDAP V2. Wray highlighted what the team learned from this experience. What did they do right? They used: * A single data structure for protocols and persistent data * C++ destructors to minimize memory leaks * A single backend good for promoting code reuse * An unfamiliar platform (NT) for development However, Wray also noted what they did wrong: * No proper error architecture (but Wray has never seen a good one) * Interoperability testing came too late * Sloppiness with respect to case sensitivity. NT is case insensitive, but UNIX is case sensitive. * Standard Template Library (STL) problems Asked how easy is it to use the CDSA architecture, Wray replied that indeed CDSA 1.2 presented difficulties. Questioned about certificate revocation, Wray replied that the implementation publishes certificate revocation lists. For more information, see http://web.mit.edu/pfl/ or read the archives of firstname.lastname@example.org on http://www.imc.org/imc-pfl/.