Fully Countering Trusting Trust Through Diverse Double-Compiling

Total Page:16

File Type:pdf, Size:1020Kb

Fully Countering Trusting Trust Through Diverse Double-Compiling Fully Countering Trusting Trust through Diverse Double-Compiling A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy at George Mason University By David A. Wheeler Master of Science George Mason University, 1994 Bachelor of Science George Mason University, 1988 Co-Directors: Dr. Daniel A. Menascé and Dr. Ravi Sandhu, Professors The Volgenau School of Information Technology & Engineering Fall Semester 2009 George Mason University Fairfax, VA Copyright © 2009 David A. Wheeler You may use and redistribute this work under the Creative Commons Attribution-Share Alike (CC-BY-SA) 3.0 United States License. You are free to Share (to copy, distribute, display, and perform the work) and to Remix (to make derivative works), under the following conditions: (1) Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). (2) Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. Alternatively, permission is also granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation. As a third alternative, permission is also granted to copy, distribute and/or modify this document under the terms of the GNU General Public License (GPL) version 2 or any later version published by the Free Software Foundation. All trademarks, service marks, logos, and company names mentioned in this work are the property of their respective owners. ii Dedication This is dedicated to my wife and children, who sacrificed many days so I could perform this work, to my extended family, and to the memory of my former mentors Dennis W. Fife and Donald Macleay, who always believed in me. Soli Deo gloria—Glory to God alone. iii Acknowledgments I would like to thank my PhD committee members and former members Dr. Daniel A. Menascé, Dr. Ravi Sandhu, Dr. Paul Ammann, Dr. Jeff Offutt, Dr. Yutao Zhong, and Dr. David Rine, for their helpful comments. The Institute for Defense Analyses (IDA) provided a great deal of help. Dr. Roger Mason and the Honorable Priscilla Guthrie, former directors of IDA’s Information Technology and Systems Division (ITSD), partly supported this work through IDA’s Central Research Program. Dr. Margaret E. Myers, current IDA ITSD director, approved its final release. I am very grateful to my IDA co-workers (alphabetically by last name) Dr. Brian Cohen, Aaron Hatcher, Dr. Dale Lichtblau, Dr. Reg Meeson, Dr. Clyde Moseberry, Dr. Clyde Roby, Dr. Ed Schneider, Dr. Marty Stytz, and Dr. Andy Trice, who had many helpful comments on this dissertation and/or the previous ACSAC paper. Reg Meeson in particular spent many hours carefully reviewing the proofs and related materials, and Clyde Roby carefully reviewed the whole dissertation; I thank them both. Aaron Hatcher was immensely helpful in working to scale the Diverse Double- Compiling (DDC) technique up to a real-world application using GCC. In particular, Aaron helped implement many applications of DDC that we thought should have worked with GCC, but didn’t, and then helped to determine why they didn’t work. These “Edison successes” (which successfully found out what did not work) were important in helping to lead to a working application of DDC to GCC. Many others also helped create this work. The work of Dr. Paul A. Karger, Dr. Roger R. Schell, and Ken Thompson made the world aware of a problem that needed solving; without knowing there was a problem, there would have been no work to solve it. Henry Spencer posted the first version of this idea that eventually led to this dissertation (though this dissertation expands on it far beyond the few sentences that he wrote). Henry Spencer, Eric S. Raymond, and the anonymous ACSAC reviewers provided helpful comments on the ACSAC paper. I received many helpful comments and other information after publication of the ACSAC paper, including comments from (alphabetically by last name) Bill Alexander, Dr. Steven M. Bellovin, Terry Bollinger, Ulf Dittmer, Jakub Jelinek, Dr. Paul A. Karger, Ben Laurie, Mike Lisanke, Thomas Lord, Bruce Schneier, Brian Snow, Ken Thompson, Dr. Larry Wagoner, and James Walden. Tawnia Wheeler proofread both the ACSAC paper and this document; thank you! My thanks to the many developers of the OpenDocument specification and the OpenOffice.org implementation, who made developing this document a Joy. iv Table of Contents Page List of Tables...............................................................................................................................viii List of Figures................................................................................................................................ix List of Abbreviations and Symbols.................................................................................................x Abstract.......................................................................................................................................xiv 1 Introduction.................................................................................................................................1 2 Background and related work......................................................................................................4 2.1 Initial revelation: Karger, Schell, and Thompson.................................................................4 2.2 Other work on corrupted compilers.....................................................................................6 2.3 Compiler bootstrap test........................................................................................................9 2.4 Analyzing software............................................................................................................10 2.4.1 Static analysis............................................................................................................11 2.4.2 Dynamic analysis.......................................................................................................14 2.5 Diversity for security.........................................................................................................16 2.6 Subversion of software is a real problem...........................................................................17 2.7 Previous DDC paper..........................................................................................................21 3 Description of threat..................................................................................................................23 3.1 Attacker motivation............................................................................................................23 3.2 Triggers, payloads, and non-discovery...............................................................................27 4 Informal description of Diverse Double-Compiling (DDC).......................................................30 4.1 Terminology and notation..................................................................................................30 4.2 Informal description of DDC.............................................................................................32 4.3 Informal assumptions.........................................................................................................35 4.4 DDC does not require that different compilers produce identical executables...................37 4.5 Special case: Self-parenting compiler................................................................................38 4.6 Why not always use the trusted compiler?.........................................................................40 4.7 Why is DDC different from N-version programming?.......................................................41 4.8 DDC works with randomly-corrupting compilers..............................................................43 5 Formal proof..............................................................................................................................44 5.1 Graphical model for formal proof .....................................................................................45 5.1.1 Types..........................................................................................................................46 5.1.2 DDC components.......................................................................................................47 5.1.3 Claimed origin...........................................................................................................48 5.2 Formal notation: First-Order Logic (FOL).........................................................................49 5.3 Proof step rationales (derivation rules or rules of inference)..............................................51 5.4 Tools and rationale for confidence in the proofs................................................................54 5.4.1 Early DDC proof efforts............................................................................................54 5.4.2 Prover9, mace4, and ivy.............................................................................................54 v 5.4.3 Tool limitations..........................................................................................................56 5.4.4 Proofs’ conclusions follow from their assumptions....................................................57
Recommended publications
  • Using the GNU Compiler Collection (GCC)
    Using the GNU Compiler Collection (GCC) Using the GNU Compiler Collection by Richard M. Stallman and the GCC Developer Community Last updated 23 May 2004 for GCC 3.4.6 For GCC Version 3.4.6 Published by: GNU Press Website: www.gnupress.org a division of the General: [email protected] Free Software Foundation Orders: [email protected] 59 Temple Place Suite 330 Tel 617-542-5942 Boston, MA 02111-1307 USA Fax 617-542-2652 Last printed October 2003 for GCC 3.3.1. Printed copies are available for $45 each. Copyright c 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being \GNU General Public License" and \Funding Free Software", the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled \GNU Free Documentation License". (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. i Short Contents Introduction ...................................... 1 1 Programming Languages Supported by GCC ............ 3 2 Language Standards Supported by GCC ............... 5 3 GCC Command Options .........................
    [Show full text]
  • Katalog Elektronskih Knjiga
    KATALOG ELEKTRONSKIH KNJIGA Br Autor Naziv Godina ISBN Str. Porijeklo izdavanja 1 Peter Kent Pay Per Click Search 2006 0-471-74594-3 130 Kupovina Engine Marketing for Dummies 2 Terry Large Access 1 2007 Internet Freeware 3 Kevin Smith Excel Lassons & Tutorials 2004 Internet Freeware 4 Terry Michael Photografy Tutorials 2006 Internet Freeware Janine Peterson Phil Pivnick 5 Jake Ludington Converting Vinyl LPs 2003 Internet Freeware to CD 6 Allen Wyatt Cleaning Windows XP 2004 0-7645-7311-X Poklon for Dummies 7 Peter Kent Sarch Engine Optimization 2006 0-4717-5441-2 Kupovina for Dummies 8 Terry Large Access 2 2007 Internet Freeware 9 Dirk Dupon How to write, create, 2005 Internet Freeware promote and sell E-books on the Internet 10 Chayden Bates eBook Marketing 2000 Internet Freeware Explained 11 Kevin Sinclair How To Choose A 1999 Internet Freeware Homebased Bussines 12 Bob McElwain 101 Newbie-Frendly Tips 2001 Internet Freeware 13 Windows Basics 2004 Poklon 14 Michael Abrash Zen of Graphic 2005 Poklon Programming, 2. izdanje 15 13 Hot Internet 2000 Internet Freeware Moneymaking Methods 16 K. Williams The Complete HTML 1998 Poklon Teacher 17 C. Darwin On the Origin of Species Internet Freeware 2/175 Br Autor Naziv Godina ISBN Str. Porijeklo izdavanja 18 C. Darwin The Variation of Animals Internet Freeware 19 Bruce Eckel Thinking in C++, Vol 1 2000 Internet Freeware 20 Bruce Eckel Thinking in C++, Vol 2 2000 Internet Freeware 21 James Parton Captains of Industry 1890 399 Internet Freeware 22 Bruno R. Preiss Data Structures and 1998 Internet
    [Show full text]
  • The GNU Configure and Build System
    The GNU configure and build system Ian Lance Taylor Copyright c 1998 Cygnus Solutions Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the con- ditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan- guage, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. i Table of Contents 1 Introduction ............................... 1 1.1 Goals................................................... 1 1.2 Tools ................................................... 1 1.3 History ................................................. 1 1.4 Building ................................................ 2 2 Getting Started............................ 3 2.1 Write configure.in ....................................... 4 2.2 Write Makefile.am ....................................... 6 2.3 Write acconfig.h......................................... 7 2.4 Generate files ........................................... 8 2.5 Example................................................ 8 2.5.1 First Try....................................... 9 2.5.2 Second Try.................................... 10 2.5.3 Third
    [Show full text]
  • System Safety Engineering: Back to the Future
    System Safety Engineering: Back To The Future Nancy G. Leveson Aeronautics and Astronautics Massachusetts Institute of Technology c Copyright by the author June 2002. All rights reserved. Copying without fee is permitted provided that the copies are not made or distributed for direct commercial advantage and provided that credit to the source is given. Abstracting with credit is permitted. i We pretend that technology, our technology, is something of a life force, a will, and a thrust of its own, on which we can blame all, with which we can explain all, and in the end by means of which we can excuse ourselves. — T. Cuyler Young ManinNature DEDICATION: To all the great engineers who taught me system safety engineering, particularly Grady Lee who believed in me, and to C.O. Miller who started us all down this path. Also to Jens Rasmussen, whose pioneering work in Europe on applying systems thinking to engineering for safety, in parallel with the system safety movement in the United States, started a revolution. ACKNOWLEDGEMENT: The research that resulted in this book was partially supported by research grants from the NSF ITR program, the NASA Ames Design For Safety (Engineering for Complex Systems) program, the NASA Human-Centered Computing, and the NASA Langley System Archi- tecture Program (Dave Eckhart). program. Preface I began my adventure in system safety after completing graduate studies in computer science and joining the faculty of a computer science department. In the first week at my new job, I received a call from Marion Moon, a system safety engineer at what was then Ground Systems Division of Hughes Aircraft Company.
    [Show full text]
  • Mac OS X Server Administrator's Guide
    034-9285.S4AdminPDF 6/27/02 2:07 PM Page 1 Mac OS X Server Administrator’s Guide K Apple Computer, Inc. © 2002 Apple Computer, Inc. All rights reserved. Under the copyright laws, this publication may not be copied, in whole or in part, without the written consent of Apple. The Apple logo is a trademark of Apple Computer, Inc., registered in the U.S. and other countries. Use of the “keyboard” Apple logo (Option-Shift-K) for commercial purposes without the prior written consent of Apple may constitute trademark infringement and unfair competition in violation of federal and state laws. Apple, the Apple logo, AppleScript, AppleShare, AppleTalk, ColorSync, FireWire, Keychain, Mac, Macintosh, Power Macintosh, QuickTime, Sherlock, and WebObjects are trademarks of Apple Computer, Inc., registered in the U.S. and other countries. AirPort, Extensions Manager, Finder, iMac, and Power Mac are trademarks of Apple Computer, Inc. Adobe and PostScript are trademarks of Adobe Systems Incorporated. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Netscape Navigator is a trademark of Netscape Communications Corporation. RealAudio is a trademark of Progressive Networks, Inc. © 1995–2001 The Apache Group. All rights reserved. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd. 062-9285/7-26-02 LL9285.Book Page 3 Tuesday, June 25, 2002 3:59 PM Contents Preface How to Use This Guide 39 What’s Included
    [Show full text]
  • Bibliography of Erik Wilde
    dretbiblio dretbiblio Erik Wilde's Bibliography References [1] AFIPS Fall Joint Computer Conference, San Francisco, California, December 1968. [2] Seventeenth IEEE Conference on Computer Communication Networks, Washington, D.C., 1978. [3] ACM SIGACT-SIGMOD Symposium on Principles of Database Systems, Los Angeles, Cal- ifornia, March 1982. ACM Press. [4] First Conference on Computer-Supported Cooperative Work, 1986. [5] 1987 ACM Conference on Hypertext, Chapel Hill, North Carolina, November 1987. ACM Press. [6] 18th IEEE International Symposium on Fault-Tolerant Computing, Tokyo, Japan, 1988. IEEE Computer Society Press. [7] Conference on Computer-Supported Cooperative Work, Portland, Oregon, 1988. ACM Press. [8] Conference on Office Information Systems, Palo Alto, California, March 1988. [9] 1989 ACM Conference on Hypertext, Pittsburgh, Pennsylvania, November 1989. ACM Press. [10] UNIX | The Legend Evolves. Summer 1990 UKUUG Conference, Buntingford, UK, 1990. UKUUG. [11] Fourth ACM Symposium on User Interface Software and Technology, Hilton Head, South Carolina, November 1991. [12] GLOBECOM'91 Conference, Phoenix, Arizona, 1991. IEEE Computer Society Press. [13] IEEE INFOCOM '91 Conference on Computer Communications, Bal Harbour, Florida, 1991. IEEE Computer Society Press. [14] IEEE International Conference on Communications, Denver, Colorado, June 1991. [15] International Workshop on CSCW, Berlin, Germany, April 1991. [16] Third ACM Conference on Hypertext, San Antonio, Texas, December 1991. ACM Press. [17] 11th Symposium on Reliable Distributed Systems, Houston, Texas, 1992. IEEE Computer Society Press. [18] 3rd Joint European Networking Conference, Innsbruck, Austria, May 1992. [19] Fourth ACM Conference on Hypertext, Milano, Italy, November 1992. ACM Press. [20] GLOBECOM'92 Conference, Orlando, Florida, December 1992. IEEE Computer Society Press. http://github.com/dret/biblio (August 29, 2018) 1 dretbiblio [21] IEEE INFOCOM '92 Conference on Computer Communications, Florence, Italy, 1992.
    [Show full text]
  • Manuscript Instructions/Template
    INCOSE Working Group Addresses System and Software Interfaces Sarah Sheard, Ph.D. Rita Creel CMU Software Engineering Institute CMU Software Engineering Institute (412) 268-7612 (703) 247-1378 [email protected] [email protected] John Cadigan Joseph Marvin Prime Solutions Group, Inc. Prime Solutions Group, Inc. (623) 853-0829 (623) 853-0829 [email protected] [email protected] Leung Chim Michael E. Pafford Defence Science & Technology Group Johns Hopkins University +61 (0) 8 7389 7908 (301) 935-5280 [email protected] [email protected] Copyright © 2018 by the authors. Published and used by INCOSE with permission. Abstract. In the 21st century, when any sophisticated system has significant software content, it is increasingly critical to articulate and improve the interface between systems engineering and software engineering, i.e., the relationships between systems and software engineering technical and management processes, products, tools, and outcomes. Although systems engineers and software engineers perform similar activities and use similar processes, their primary responsibilities and concerns differ. Systems engineers focus on the global aspects of a system. Their responsibilities span the lifecycle and involve ensuring the various elements of a system—e.g., hardware, software, firmware, engineering environments, and operational environments—work together to deliver capability. Software engineers also have responsibilities that span the lifecycle, but their focus is on activities to ensure the software satisfies software-relevant system requirements and constraints. Software engineers must maintain sufficient knowledge of the non-software elements of the systems that will execute their software, as well as the systems their software must interface with.
    [Show full text]
  • Software Assurance
    Information Assurance State-of-the-Art Report Technology Analysis Center (IATAC) SOAR (SOAR) July 31, 2007 Data and Analysis Center for Software (DACS) Joint endeavor by IATAC with DACS Software Security Assurance Distribution Statement A E X C E E C L I L V E R N E Approved for public release; C S E I N N I IO DoD Data & Analysis Center for Software NF OR MAT distribution is unlimited. Information Assurance Technology Analysis Center (IATAC) Data and Analysis Center for Software (DACS) Joint endeavor by IATAC with DACS Software Security Assurance State-of-the-Art Report (SOAR) July 31, 2007 IATAC Authors: Karen Mercedes Goertzel Theodore Winograd Holly Lynne McKinley Lyndon Oh Michael Colon DACS Authors: Thomas McGibbon Elaine Fedchak Robert Vienneau Coordinating Editor: Karen Mercedes Goertzel Copy Editors: Margo Goldman Linda Billard Carolyn Quinn Creative Directors: Christina P. McNemar K. Ahnie Jenkins Art Director, Cover, and Book Design: Don Rowe Production: Brad Whitford Illustrations: Dustin Hurt Brad Whitford About the Authors Karen Mercedes Goertzel Information Assurance Technology Analysis Center (IATAC) Karen Mercedes Goertzel is a subject matter expert in software security assurance and information assurance, particularly multilevel secure systems and cross-domain information sharing. She supports the Department of Homeland Security Software Assurance Program and the National Security Agency’s Center for Assured Software, and was lead technologist for 3 years on the Defense Information Systems Agency (DISA) Application Security Program. Ms. Goertzel is currently lead author of a report on the state-of-the-art in software security assurance, and has also led in the creation of state-of-the-art reports for the Department of Defense (DoD) on information assurance and computer network defense technologies and research.
    [Show full text]
  • Infrastructure (Resilience-Oriented) Modelling Language: I®ML
    Infrastructure (Resilience-oriented) Modelling Language: I®ML A proposal for modelling infrastructures and their interconnections Andrés Silva, Roberto Filippini EUR 24727 EN - 2011 The mission of the JRC-IPSC is to provide research results and to support EU policy-makers in their effort towards global security and towards protection of European citizens from accidents, deliberate attacks, fraud and illegal actions against EU policies. European Commission Joint Research Centre Institute for the Protection and Security of the Citizen Contact information Address: TP 210, EC JRC Ispra, Ispra (Va) Italy E-mail: [email protected] Tel.: +39 0332 789936 Fax: http://ipsc.jrc.ec.europa.eu/ http://www.jrc.ec.europa.eu/ Legal Notice Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use which might be made of this publication. Europe Direct is a service to help you find answers to your questions about the European Union Freephone number (*): 00 800 6 7 8 9 10 11 (*) Certain mobile telephone operators do not allow access to 00 800 numbers or these calls may be billed. A great deal of additional information on the European Union is available on the Internet. It can be accessed through the Europa server http://europa.eu/ JRC 63302 EUR 24727 EN ISBN 978-92-79-19324-8 ISSN 1018-5593 doi:10.2788/54708 Luxembourg: Publications Office of the European Union © European Union, 2011 Reproduction is authorised provided the source is acknowledged Printed in Italy Infrastructure (Resilience-oriented) Modelling Language: I®ML A proposal for modelling infrastructures and their connections Andrés Silva1 Roberto Filippini Universidad Politécnica de Madrid JRC of the European Commission Abstract The modelling of critical infrastructures (CIs) is an important issue that needs to be properly addressed, for several reasons.
    [Show full text]
  • Capsicum: Practical Capabilities for UNIX
    Capsicum: practical capabilities for UNIX Robert N. M. Watson Jonathan Anderson Ben Laurie University of Cambridge University of Cambridge Google UK Ltd. Kris Kennaway Google UK Ltd. Abstract significant technical limitations: current OS facilities are simply not designed for this purpose. Capsicum is a lightweight operating system capabil- The access control systems in conventional (non- ity and sandbox framework planned for inclusion in capability-oriented) operating systems are Discretionary FreeBSD 9. Capsicum extends, rather than replaces, Access Control (DAC) and Mandatory Access Control UNIX APIs, providing new kernel primitives (sandboxed (MAC). DAC was designed to protect users from each capability mode and capabilities) and a userspace sand- other: the owner of an object (such as a file) can specify box API. These tools support compartmentalisation of permissions for it, which are checked by the OS when monolithic UNIX applications into logical applications, the object is accessed. MAC was designed to enforce an increasingly common goal supported poorly by dis- system policies: system administrators specify policies cretionary and mandatory access control. We demon- (e.g. “users cleared to Secret may not read Top Secret strate our approach by adapting core FreeBSD utilities documents”), which are checked via run-time hooks in- and Google’s Chromium web browser to use Capsicum serted into many places in the operating system’s kernel. primitives, and compare the complexity and robustness Neither of these systems was designed to address the of Capsicum with other sandboxing techniques. case of a single application processing many types of in- formation on behalf of one user. For instance, a mod- 1 Introduction ern web browser must parse HTML, scripting languages, images and video from many untrusted sources, but be- Capsicum is an API that brings capabilities to UNIX.
    [Show full text]
  • Sandboxing with Capsicum
    SECURITY Sandboxing with Capsicum PAWEL JAKUB DAWIDEK AND MARIUSZ ZABORSKI Pawel Jakub Dawidek is a ery few programmers have managed to successfully use the principle co-founder and CTO at Wheel of least privilege, as found in OpenSSH, Postfix, and djbdns. Capsi- Systems and a FreeBSD cum, introduced in 2010, adds a capability model designed to make it committer who lives and works V easier for programmers to reason about how to split a program into privileged in Warsaw, Poland. He is the and unprivileged portions. In this article, we describe the changes made in author of various GEOM classes, including the disk-encryption class GELI; he implemented Capsicum since 2010, compare Capsicum to earlier sandboxing techniques, the Highly Available Storage (HAST) daemon and look at the new Casperd, which makes it simpler to split programs. for distributing audit trail files (auditdistd), and Long ago, people started to recognize that security models proposed by the mainstream nowadays is mostly working on the Capsicum operating systems, including Windows, Mac OS X, and all kinds of UNIX-like systems, are framework and the Casper daemon. simply naive: All you need to do is to write programs that have no bugs. That’s indeed naive. [email protected] Let’s also state an obvious rule: The more code we write, the more bugs we introduce, some of which may jeopardize the security of our system. Once we accept this fact, where do we go? Mariusz Zaborski is currently We could only develop very small programs, which are easy to audit, but this again would be working as a software a bit naive.
    [Show full text]
  • 0.1 Problems
    0.1. PROBLEMS 1 0.1 Problems 1. Among the fundamental challenges in information security are confi- dentiality, integrity, and availability, or CIA. a. Define each of these terms: confidentiality, integrity, availability. b. Give a concrete example where confidentiality is more important than integrity. c. Give a concrete example where integrity is more important than confidentiality. d. Give a concrete example where availability is the overriding con- cern. 2. From a bank's perspective, which is usually more important, the in- tegrity of its customer's data or the confidentiality of the data? From the perspective of the bank's customers, which is more important? 3. Instead of an online bank, suppose that Alice provides an online chess playing service known as Alice's Online Chess (AOC). Players, who pay a monthly fee, log into AOC where they are matched with another player of comparable ability. a. Where (and why) is confidentiality important for AOC and its customers? b. Why is integrity necessary? c. Why is availability an important concern? 4. Instead of an online bank, suppose that Alice provides an online chess playing service known as Alice's Online Chess (AOC). Players, who pay a monthly fee, log into AOC where they are matched with another player of comparable ability. a. Where should cryptography be used in AOC? b. Where should access control used? c. Where would security protocols be used? d. Is software security a concern for AOC? Why or why not? 5. Some authors distinguish between secrecy, privacy, and confidential- ity. In this usage, secrecy is equivalent to our use of the term con- fidentiality, whereas privacy is secrecy applied to personal data, and 2 confidentiality (in this misguided sense) refers to an obligation not to divulge certain information.
    [Show full text]