Security Engineering

Ross Anderson Wiley, 2001

CH 1 -- What is SE; Examples and definitions

Security engineering is about building systems to remain dependable in the face of malice, error, or mischance. Ross Requires cross-disciplinary expertise: cryptography, computer and network security, computer and network systems and protocols, hardware (computer and network), formal methods, applied psychology, organizational methods and psychology, auditing, forensics and the law. Requirements not only based on confidentiality and privacy but also include critical infrastructure assurance: safety for human life and the environment, economic structures, and crime prevention and prosecution. Example 1 Bank Primary attack object branch bookkeeping system (master customer accounts), may be centralized but principal is the same just more so because a single compromise effects more customers Main threat bank employees. Main defense good accounting procedures. Public interface ATM, credit/debit cards plus PIN (potential attack vector), uses online/inline and offline cryptography. Internet interface for customers Web + (TSL/SSL or VPNs), new primary attack vector (phishing). Both Internet and ATM depend on quality secure messaging and secure communication systems. Example 2 military Electronic warfare with jamming, countermeasures, counter-countermeasures are precursors of information warfare on the Internet (denial of service, ~virus, etc). Communications - encryption, transmission masking (low-probability-of-intercept, spread spectrum), destination masking.
BRM-11/6/2012 CST 554 Lecture Notes (Ch1 & 2) SE-1

Security Engineering
Ross Anderson Wiley, 2001 Assurance requirements (online and offline) for logistics and inventory management for VERY large systems. Frequently require access hierarchies. Weapons systems (particularly nuclear) often require complex multifactor and/or multi-origin access. Example 3 Hospitals Distributed data and delivery systems. Special assurance issues cant lose data, cant store incorrect data or allow to become corrupt, i.e., reliability, and accuracy extremely important Privacy not only restricted to anonymity (hard to without special scrubbing), there are also role based privacy requirements. Availability of data/services also critical (sometimes, e.g., when in hospital). Think of DoS. Example 4 Homes Many/most of the above plus copyright issues. Question: What isnt included? Example 5 The Internet Open for discussion: - Old - New - Modified - Gone

Definitions
System anything or everything; product or component thereof, operating system, communications system, applications, staff, users, customers, environment in which embedded. Subject physical person in any role Person human or legal entity (company)
BRM-11/6/2012 CST 554 Lecture Notes (Ch1 & 2) SE-2

Security Engineering
Ross Anderson Wiley, 2001 Principal an entity that participates in a security system (subject, person, role, equipment, communications channel, group of principals) Role a function assumable by different persons Identity - (pure) a correspondence between a name and a person (as understood by another person) Identity - (vernacular) a name Trust - believed to be trustworthy (but may not be) Trusted system is a system is one whose failure can break a security policy Trustworthy a system or subsystem that will not fail Secrecy the effect of the mechanisms used to limit the number of principals who can access information Confidentiality the obligation to protect some other persons or organizations secrets if you know them Privacy the ability or right to protect your personal secrets Notes: - it is often insufficient to keep message contents secret, sometimes source or destination or other metadata may also need to be protected (anonymity, message content confidentiality, message source (or destination) confidentiality) - freshness recent or not a replay - integrity unchanged - authenticity integrity plus freshness - authentic copy a real copy of something that may be a fake - vulnerability a property a system that under application of a threat (attack) may lead to a security failure - threat a potential for an error or an attack mechanism (exploit) that can take advantage of a vulnerability - security policy a succinct statement of a systems security strategy - security target a detailed specification of the means of achieving the security policy - protection a property (confidentiality or integrity) defined in a sufficiently abstract way such that it is possible to reason about it (the property) in the context of general systems rather than specific implementations

BRM-11/6/2012

CST 554 Lecture Notes (Ch1 & 2)

SE-3

Security Engineering
Ross Anderson Wiley, 2001

CH 2 Protocols, basically security protocols

Security protocols are the rules that govern the communications across a variety of channels between principals in a (security?) system. Protocols are designed with (hopefully) sufficient protections to prevent damage from malicious as well erroneous attacks/threats; at least enough protections to prevent real damage. Total protection may be too much effort for the payback (return on acquired overhead). On a system level what is enough? Depends on threat and vulnerability models. Using Risk = Value X (Vulnerabilities X Threats)/Countermeasures Then a value of 0 for risk is best, of course. However, quantizing these parameters is difficult. This model (formulation) is used in man risk analysis situations but is not the only model used. A minor change is to replace Value with Impact. Simpler models are usually linear but this one allows for reducing risk in 3 ways for the same resource value. An example of the application of this formula is in a presentation found at http://www.owasp.org/docroot/owasp/misc/OWASP_DC_2005_Presentations/Track_1-Day2/AppSec2005DCIra_Winkler-Secrets_of_Superspies.ppt The presentation that went with this PPT file was good as well as funny. What is a password? Not just a string it is an authentication mechanism depending on a shared secret. Common usage (e.g., computer account) it is a short to medium string of type-able characters. In the long run without additional measures subject to brute force discovery, disclosure (post-it notes and shoulder surfing) and in most cases replay (depending on technology more later). Password choice and technology choice is vital. Nomenclature/Notation T G:T,{T,N}KT

BRM-11/6/2012

CST 554 Lecture Notes (Ch1 & 2)

SE-4

Security Engineering
Ross Anderson Wiley, 2001 Message from T to G with content T name/identity and an encrypted part consisting of T and some additional info (N) that is encrypted with some algorithm using key KT. Nonce a value; maybe a random number, timestamp or a counter in some cases (it depends ;-) Used to (attempt to) guarantee freshness. Problem with counters? Synchronization. Key diversification widespread use and knowledge of a key Challenge - Response Challenge Response E T:N T E:{T,N}K

Shared key, nonce must be truly random (or at least practically so) for challenge to not be subject to replay issues. Two factor C-R in this case a password generator (P) (many different implementations) S = server, U = user S U:N this is after providing login name 1st U P:N, Pin P U:{N, Pin} K this is an example value, reality is that as long as P and S understand what value should be, it works U S:{N,Pin}K Note: this is usually modified further by varying K for each P where P and U have been associated at S. Man-in-the-Middle (OK, OK Person-in-the-Middle) Difficult but almost always effective if interception and retransmission (with or without modification to payload) can be accomplished WITHOUT detection on the physical level (the hardest part).
BRM-11/6/2012 CST 554 Lecture Notes (Ch1 & 2) SE-5

Security Engineering
Ross Anderson Reflection attacks in mutual authentication Original challenge is reflected back to the original challenger by interloper (before any response) which provides a valid response which can be sent back as a valid response to the original challenger (F on page 21). This only works with symmetric keys and no freshness or originator information is included with the response. Trust assumptions and consequences in protocol design are IMPORTANT A common cause of protocol failure is that the environment [in which the protocol operates] changes, so that assumptions [ on which the protocol depends are no longer true], and the security protocols cannot cope with the new threats. Ross A. pg 23 Change can happen slowly and so threats may not be immediately evident. Managing Encryption Keys Authentication needed to associate principals with keys (and encryption algorithms). May embed info relative to authorization within the management structure, too. Especially important in distributed systems. In nondistributed systems or in distributed systems where key exchange (e.g., key-principal correlation) is accomplished on a personal basis, key management becomes a personal function (e.g., a key ring). In distributed systems principals may not know one another or ever have a formal meeting. In these cases a trusted third party is used to mediate the key-principal association process (introduction). Example is Kerberos, other methodologies introduced later. An general algorithm is presented on pg 26. The server gets a request from Alice to talk to Bob and server creates a session key and sends a copy to Alice so only Alice can read it. The server also sends an encrypted copy of the session key to Alice that only Bob can decrypt. Alice sends that to Bob along with a message encrypted with the session key (KAB). Bob decrypts the session key that Alice sent and then decrypts the message.
BRM-11/6/2012 CST 554 Lecture Notes (Ch1 & 2) SE-6

Wiley, 2001

Security Engineering
Ross Anderson Wiley, 2001 This protects both Bobs and Alices private keys and results in the potential for a long term association. Understand the Needham-Schroeder Protocol, especial the delay/compromise issue. Kerberos Two servers authentication, access management (introduction control) scalable management Authentication (approximate) S is authentication server A S:A,{A,N} Pwd S A:{A,T S,L,KAS }Pwd Subsequent exchange with authorization (introduction) server in book, pg 28, provides a session key, KAB A S:A, B S A:{TS, L, KAB, B,{ TS, L, KAB, A} KBS}KAS A B: { TS, L, KAB, A} KBS , {A, TA}KAB B A: { TA + 1}KAB TS and TA are timestamps. Used for freshness. Requires moderate synchronization of clocks (< 2 minutes usually but 2 seconds better). Formal verification sounds like fun but not for this course. Limitations of formal verification Even if protocol valid external assumptions may be incomplete (even erroneous). Examples abound. A major problem is incompatibilities at the boundary of two different protocol boundaries (edges). Here assumptions need to be formalized [if possible].
BRM-11/6/2012 CST 554 Lecture Notes (Ch1 & 2) SE-7

Security Engineering
Ross Anderson Wiley, 2001

BRM-11/6/2012

CST 554 Lecture Notes (Ch1 & 2)

SE-8