CSC 607 Meeting 2 Charts

CSC 607 Meeting 2 Charts - Security in Computing – CSC...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Security in Computing – CSC 607 Wireless Security – WCM 605 Meeting 2 Thursday, Jan 7, 2010 1/7/2010 1/7/2010 1 Week 1 Schedule Tuesday 1/5 The Security Problem in Computing and Networks Security and Cryptography I Video – Decoding Nazi Secrets Form teams for Week 1 Small Groups Thursday 1/7 Security and Cryptography II Program Security Operating System Security Small group work on Week 1 Projects Week 1 Reading – Pfleeger & Pfleeger 4th Edition Chapters 1, 3 and 4 Chandra pp xi­xxiv and Chapter 1 1/7/2010 1/7/2010 2 Security and Cryptography – Security Part II Part 1/7/2010 1/7/2010 3 Stream Ciphers Block ciphers are more secure Stream ciphers are the most common approach for securing wireless communications • Faster to encode by your cellphone’s processor • Easier to decode by your cellphone’s processor Stream ciphers operate on plaintext 1 bit at a time Two components of a stream cipher • Key­stream generator Generates pseudorandom numbers • Same pseudorandom number is generated at each end of the call Changes from one cipher to the next (think “one call to the next”) • Mixing function (typically an XOR) 1/7/2010 1/7/2010 4 Typical Stream Cipher Operation Plaintext Keystream Ciphertext 1001100001111010100010101000… XOR 1100011110101000011111010110… Keystream 0101111111010010111101111110… XOR 1100011110101000011111010110… Plaintext 1001100001111010100010101000… •Sender and Receiver must use identical keystreams •Keystream XORed with Plaintext yields Ciphertext •Keystream XORed with Ciphertext yields Plaintext 1/7/2010 1/7/2010 5 Key-Stream Extremes If: Key­stream is endless stream of zeros Then: Ciphertext = Plaintext If: Key­stream is completely random string of bits Then: Perfect security In practice: • Sender and receiver negotiate a key Typically uses PKC • Key is input to identical pseudorandom number generation algorithms in sender and receiver 1/7/2010 1/7/2010 6 Key-stream Generator Imperative Security of the system depends entirely on how the key­stream pseudorandom number generator works There is an inherent contradiction in generating random numbers (key­stream) with a computer (or by any algorithm) Optimal key­stream generator period =2N for an N­bit key • “Period” = time to regenerate same key Key­stream generator MUST have a period much longer than the number of bits the generator will output between key­exchanges 1/7/2010 1/7/2010 7 Illustration – Key-Stream Length Illustration Requirement Requirement T­1 link – 1.544 Mb/s X 60 sec/min X 60 min/hour X 24 hours/day = 1.334 X 1011 bits/day ≈ 237 bits/day 210 = 1024 230 = 1024 X 1024 X 1024 = 1.074 X 109 237 = 128 X 1.074 X 109 = 1.374 X 1011 • Period of Key­Stream Generator to encrypt 237 bits day must be orders of magnitude larger – say 240 •True even if new key is exchanged daily 1/7/2010 1/7/2010 8 Stream Cipher Modes Synchronous Stream Cipher • Key­stream generator depends only on key Self­Synchronizing Stream Cipher • Key­stream generator depends on key PLUS some previously produced ciphertext 1/7/2010 1/7/2010 9 Synchronous Stream Cipher Key Generator Key Generator ki ki Plaintext (Pi) Ciphertext (Ci) Plaintext (Pi) •Sender and receiver must be perfectly synchronized •Security is completely compromised if key is compromised 1/7/2010 1/7/2010 10 Synch Stream Cipher Pros and Cons Advantage: No error propagation • If a bit of ciphertext is corrupted during transmission, only one bit of plaintext is affected Disadvantages: Highly vulnerable to insertions/deletions • Insertion/deletion of even one bit causes complete loss of synchronization • The remainder of the message is completely corrupted Insertion attack can lead to compromise of message 1/7/2010 1/7/2010 11 Synch Stream Cipher Attack-I 1. 2. Eve sends P to Alice and asks Alice to encrypt P Alice sends as follows: P = P0, P1, P2, … Pi, … Pn XOR K = K0, K1, K2, … Ki, … Kn C = C0, C1, C2, … Ci, … Cn 1. 1/7/2010 1/7/2010 Eve captures C 12 Synch Stream Cipher Attack-II 1. 2. Eve inserts Pa at front of P, sends P’ to Alice and asks Alice to encrypt P’ Alice sends as follows: P = Pa, P0, P1, P2, … Pi, … Pn XOR K = K0, K1, K2, … Ki, … Kn C = C’0, C’1, C’2, … C’i, … C’n 1/7/2010 1/7/2010 1. Eve captures C’ 13 Synch Stream Cipher Attack-III 1. 2. Eve now knows C and C’ Eve can compute as follows: Pa XOR C’0 = K0 K0 XOR C0 = P0 P0 XOR C’1 = K1 … to derive the whole key stream K0 through Kn •Key streams should never be reused •Key streams should have sufficiently long periods 1/7/2010 1/7/2010 14 Self Synchronizing Stream Cipher Key Generator Key Generator ki ki Plaintext (Pi) Ciphertext (Ci) pi= ci XOR ki ki = f(ci) Plaintext (Pi) ci= pi XOR ki and ki = f(ci) Key stream generator (and its output) is function of fixed number (n) of previous ciphertext bits Two key stream generators can self synchronize by exchanging n­bit Initialization Vector • Normally done at start of message exchange 1/7/2010 1/7/2010 15 Self Synchronizing Stream Cipher Self Pros and Cons Pros Advantage: Better security • Attacker needs complete session (or at least n bits) to decrypt any cipher bit Disadvantages: Slower than stream ciphers • Key­stream cannot be precomputed Error in one ciphertext bit corrupts n plaintext bits at the receiver 1/7/2010 1/7/2010 16 In Class Exercise In You want to transmit secure information over a WiFi 802.11g connection, operating at 54 Mb/s. You are using a key stream generator, and XORing the result with the stream of plaintext bits being transmitted. What is the period you want your key stream to be to ensure that sessions lasting up to 15 minutes are reasonably secure? Write your answer below, showing your calculations and submit. 1/7/2010 17 Answer to the exercise Answer 54 X 106 bits/sec X 60 sec/min X 15 minutes = 48600 X 106 bits = 4.8 X 1010 bits transmitted per 15 minutes = N To keep a 15 minute transmission secure the period of the keystream should be 2N = 9.6 X 1010 bits, or 30 minutes, and the key should be changed for each new transmission. 1/7/2010 18 Program Security Program Pfleeger & Pfleeger Chapter 3A 1/7/2010 19 Key Issues in Program Security 1/7/2010 1/7/2010 How do we keep programs free from flaws? How do we protect computing resources against programs that contain flaws? 20 Terminology & Definitions IEEE Standard 729 • • Human mistake = error Error MAY lead to a fault Fault = incorrect step, command, process, etc. Failure = departure from systems required behavior Program Security Terminology • Program Security Flaw = “inappropriate behavior caused by a program vulnerability” • A flaw may be a fault or a failure • Vulnerability = Class of flaws, e.g. buffer overflow 1/7/2010 1/7/2010 21 Program Security Flaws Inadvertent Human Error Malicious, intentionally introduced •Greatest cost, •Most damage •Greatest press, •Significant damage There is NO technique to eliminate or even address all program security flaws 1/7/2010 1/7/2010 22 Taxonomy of Program Security Taxonomy Flaws Flaws Intentional • Malicious • Non­malicious Inadvertent • • • • • • Validation Error Domain Error Serialization and Aliasing Inadequate identification and authentication Boundary condition violation Other exploitable logic errors “By understanding what can go wrong and how to protect against it, we can devise techniques and tools to secure most computer applications.” Pfleeger & Pfleeger, p. 100 1/7/2010 1/7/2010 23 Classic Program Error Types Buffer Overflows Incomplete Mediation Time­of­Check to Time­of­Use Errors •Have plagued programmers and security professionals for decades •Not likely to disappear 1/7/2010 1/7/2010 24 Buffer Overflows Buffer – a space in which data can be held Example: • Y = F(m), m=1 to 10 • But program inadvertently or deliberately tries to do something with F(11) 1/7/2010 1/7/2010 How serious the problem is depends on what is next to the array F(m) 25 Buffer Overflow Illustration Security Implications Examples: 1. Buffer overflow into System Program space; Attacker inserts overflow data that are really code 2. Attacker uses overflow to stack pointer to redirect execution to attacker’s code 1/7/2010 1/7/2010 26 Incomplete Mediation Typically, an out­of­range parameter in an unchecked data value • Non­existent month, Nonsense data range,Non­existent area code or zip code Example: custID=101&part=555A&qy=20&price= 10$ship=boat&shipcost=5&total=205 • Customer alters to “total=20” instead of “205” 1/7/2010 1/7/2010 Common variation used today for phishing attacks 27 Time-of-Check to Time-of-Use Time-of-Check Errors Errors A serialization or synchronization flaw • A “bait and switch” flaw • Check is made too far in advance of execution Change made AFTER the check, but before the execution exploits the delay Example: Your instruction The attackers substitution 1/7/2010 1/7/2010 28 Steganography The art and science of hiding information inside other, seemingly ordinary messages or documents Unlike sending an encrypted message, you do not know when steganography is hiding a secret message within a document Current example: take “random” pixels from an image and replace them with hidden data • Changing low order bits in a JPEG pixel does not change appearance of image enough to be detectable by the human eye 1/7/2010 1/7/2010 29 Malicious Code Types Code Type Characteristics Virus Trojan horse Contains unexpected additional functionality Logic Bomb Action triggered by condition Time Bomb Action triggered by date/time Trapdoor Allows unauthorized access Worm Propagates copies of itself throughout network Rabbit 1/7/2010 1/7/2010 Attaches to program and propagates copies of itself to other programs Replicates itself without limit to exhaust resource 30 Virus Writer’s Goals Make it: Hard to detect Not easily destroyed or deactivated Able to spread infection widely So that it can reinfect its home program or other programs • Easy to create • Machine independent and operating system independent • • • • Few viruses can do all of the above 1/7/2010 1/7/2010 31 How Viruses Get In CDs and Floppy Disks Email attachment • Use to be file extension .exe, but now mostly disguised • May be embedded in graphics or a photo Download from Web Site 1/7/2010 1/7/2010 32 How Viruses Attach Append Surround Integrate 1/7/2010 1/7/2010 33 How Viruses Gain Control T=Target V = Virus The majority of viruses today execute only once! 1/7/2010 1/7/2010 34 Homes for Viruses Boot Sector • The original home for viruses Memory Resident • Attaches to code that always remains in memory Others • Application programs, libraries, compilers, loaders, linkers, runtime monitors, runtime debuggers, and EVEN virus control programs 1/7/2010 1/7/2010 35 Identifying Viruses Virus Scanners look for Virus Signatures Virus signatures may be: • Unique character pattern, e.g. unique set of characters at start of virus code • Unique storage pattern • Unique execution pattern • Unique transmission pattern, e.g. sending email to all addresses in Address Book Polymorphic viruses attempt to disguise their appearance by randomly redistributing themselves in memory and randomly changing their fixed data 1/7/2010 1/7/2010 36 Virus Prevention 1/7/2010 1/7/2010 Use only commercial software from reliable, well established vendors Test all new software on an isolated computer (i.e. not connected to your network) Open attachments only when you KNOW them to be safe Make a recoverable system image and store in safely Make and retain backups of executable system files Use virus detectors/scanners and UPDATE them DAILY 37 Controls Against Program Threats Developmental Controls ­ Programming • • • • • Peer Reviews Testing Good Designs Configuration Management Proof of Correctness Operating System Controls Administrative Controls 1/7/2010 1/7/2010 38 Programming Controls Modularity Encapsulation Information Hiding 1/7/2010 1/7/2010 39 Peer Reviews Review (typically informal) Walk­Through (led by software creator) Inspection (Creator does not lead) Figure 3-19 Fault Discovery Rate Reported at Hewlett-Packard. “Unfortunately, many organizations give only lip service to peer reviews” 1/7/2010 1/7/2010 40 Developmental Techniques Kinds of Testing Function Testing Performance Test Acceptance Testing Installation Testing Regression Testing Black Box Testing Clear­box Testing INTEGRATION TESTING! Independent Testing is highly desirable 1/7/2010 1/7/2010 41 Developmental Techniques Key Design-Related Processes Employ a philosophy of fault tolerance • Isolate the damage from a fault • Design code defensively (like defensive driving) Have a consistent policy for handling failures • Retrying vs. Correcting vs. Reporting Capture the design rationale and history • Helps to integrate the design of security functions without compromising overall integrity of system design Use of design patterns • Reuse patterns that have been successful, e.g. in preventing buffer overflows, ensuring data integrity, and user password checks 1/7/2010 1/7/2010 42 Developmental Techniques Configuration Management 1/7/2010 1/7/2010 The process by which changes are controlled during development and maintenance Who is making changes to what? and When are the changes being made? Types of changes: • Corrective • Adaptive • Perfective • Preventive Scrutinizes new/changed code to ensure that security flaws have not been inserted intentionally or accidentally 43 Configuration Management Configuration Activities Activities Configuration Identification Configuration Control and Change Management Configuration Auditing Status Accounting 1/7/2010 1/7/2010 44 Developmental Techniques: Other Controls on Code Formal Proofs of Program Correctness • Difficult to do but can be very powerful Operating System Controls on Use of Programs • Some software security enforcement is implemented by the Operating System • Highly desirable to use an OS that is “trusted software” with the following characteristics: 1/7/2010 1/7/2010 Functional Correctness Enforcement of Integrity Limited Privilege Appropriate Confidence Level 45 Administrative Controls 1/7/2010 1/7/2010 Standards of Program Development • Standards of design • Standards of documentation, language and coding control • Standards of programming (peer reviews, code audits for correctness, etc.) • Standards of testing • Standards of configuration management Separation of Duties • Use of deliberately separate design teams for separate modules 46 Protection in General Protection Purpose Operating Systems Systems Chapter 4A 1/7/2010 1/7/2010 47 Outline Protected Objects and Methods of Protection Memory Protection • • • • • Fences Base/Bounds Registers Tagged Architecture Paging Segmentation File Protection General Control of Access to Objects User Authentication • Passwords • Authentication other than passwords 1/7/2010 1/7/2010 48 Protection of Objects Multiprograming/multiple users led to need for Operating System to protect: • • • • • 1/7/2010 1/7/2010 Memory Sharable I/O devices Sharable programs and subprocedures Networks Sharable Data Operating Systems (OS) had to assume responsibility for security protection 49 OS Security Methods The basis of protection is separation Separation methods: • Physical Different physical objects/printers for different levels of security • Temporal (time) Programs with different security levels execute at different times • Logical User program cannot access objects outside its domain • Cryptographic 1/7/2010 1/7/2010 Processes conceal their data and logic through use of encryption 50 Levels of OS Protection • Each process has its own address space, files, etc. All or Nothing Sharing • Owner declares an object “public” or private” Share via Access Limitations • OS checks allowability of every attempt to access an object Share by capabilities • Dynamic creation of sharing rights Limit Use of an Object • Limits both access to and use of object 1/7/2010 1/7/2010 Increasing implementation difficulty No Separation Isolation 51 Memory and Memory Address Protection Address Definition: • Prevent one program from affecting the memory of the other Methods • • • • • 1/7/2010 1/7/2010 Fence Base/Bound Register Tagged Architecture Segmentation Paging 52 Fence Fixed Fence •Hardware confines user to one side of a boundary Fence Register – Contains address of end of OS •Protects OS from users •Does not protect users from each other 1/7/2010 1/7/2010 53 Variable Fence Register Introduces ability to relocate programs •Relocation Factor added to each address in program Guarantees that no program can access a location in memory lower than the fence address 1/7/2010 1/7/2010 54 Base/Bounds Registers Variable Fence Register = Base Register = Lower Bound Bounds Register = Upper Limit OS Changes contents of Base/Bounds Registers when execution changes from one user to another •This is called a Context Switch 1/7/2010 1/7/2010 55 Two Pairs of Base/Bounds Two Registers Registers 1/7/2010 1/7/2010 Use of 2 pairs can protect user from inadvertently overwriting her/his own data Can also be used to split program into 2 pieces that can be relocated separately 56 Tagged Architecture Every word of memory has one or a few bits that define access rights to that word Used on very few OS today Implementation would require fundamental changes to most OS code 1/7/2010 1/7/2010 57 Segmentation Enables dividing a program into pieces • Each piece has a logical unity, e.g. all instructions, all data, etc. • Each piece has its own access rights 1/7/2010 1/7/2010 Has effect of a large number of base/bounds registers 58 Translation of Segment Addresses 1/7/2010 1/7/2010 OS maintains directory of <segment names, segment address> Hides actual addresses • Any segment can be moved anywhere, even after execution starts • Segment can be moved from main memory • Every address can be checked for access rights 59 Pros and Cons of Segmentation Pros: • Each address reference can be checked for protection • Different levels of protection can be given to different classes of data • Different users can share access to a segment with different access rights for the same segment • User cannot access or address an unpermitted segment Cons: • OS must maintain current segment length and compare every address generated • OS lookup of segment names slows it down • Segmentation causes fragmentation 1/7/2010 1/7/2010 60 1/7/2010 1/7/2010 Program divided into equal sized pieces called pages • Normally 2n Memory is divided into page frames Address translation like segmentation, but fragmentation eliminated Programmer not aware of mechanism An alternative to segmentation Can be combined with segmentation Paging Concerns: • Addition of just one instruction can cause overflow to new page, with security implications • No unity of data types on page → no way to establish same protection 61 for all values on a page File Protection All­or­None • • • A few system files protected with passwords All others visible to all Presumes “trust” among users Group Protection • Users share all files within their group • Issues with users in multiple groups Single Permissions • Password or Token Same general problems as with authentication • Temporary Acquired Permission User access to files only through special programs to which temporary access can be given • Per­Object and Per­User Protection 1/7/2010 1/7/2010 Problem with creating meaningful groups of users 62 Kinds of Objects for Which Kinds Protection is Desirable Protection 1/7/2010 1/7/2010 Memory File or Data Set on auxiliary storage An executing program in memory Directory of files Hardware Device Data structure (e.g. a stack) OS table Instructions (especially privileged instructions Passwords and other user authentication mechanisms The protection mechanism itself 63 General Object Access Control General Mechanisms Mechanisms Directory Access Control List Access Control Matrix Capabilities (tickets) Procedure Oriented Access Control 1/7/2010 1/7/2010 64 Directory Control “Owner” of object grants access rights One list per user • Names all objects user is allowed to access Pro: Easy to implement Cons: • List can become large • Revocation of rights can become difficult • Pseudonyms (same name for different files) can be problematic 1/7/2010 1/7/2010 Probably too simple for most object protection situations 65 Access Control List One list per object • Shows all users authorized access and what level of authorization A directory is created for each subject Pros: • Specific users can have explicit rights while all other have default rights • Allows sharing of public file/ program by all users without having to make entry in individual user directories • Use of “wildcards” allows shared public objects to have very short access list for special privileges 1/7/2010 1/7/2010 66 Access Control Matrix Directory: List of objects accessible by single subject Access Control List: List of users who can access a single object Access Control Matrix • • • 1/7/2010 1/7/2010 Rows list subjects Columns list Objects Each cell is a triple of the form <users, object, rights> Searching a large number of triples is inefficient enough that an Access Control Matrix is seldom used 67 Control by Capability Capability = Unforgeable token that gives possessor certain rights to an object • Operating system may hold all tickets • Capability may be encrypted with key available only to access control mechanism • Capabilities must be stored in memory inaccessible to normal users • Capabilities can be revoked 1/7/2010 1/7/2010 68 1/7/2010 1/7/2010 Domain: a collection of objects to which a process has access A capability identifies one object in a domain The collection of capabilities defines the domain When a process calls a subpro­ cedure, it can pass certain capabilities with the call The OS then creates new capabilities for the subprocedure Domains 69 Procedure Oriented Access Control Procedure controls access to objects Procedure controls what a subject can DO to an object Essentially forms a capsule around the object Implements the principle of “hiding” information (Chapter 3) Less efficiency, increases delay One key use: entering/changing passwords 1/7/2010 1/7/2010 70 ...
View Full Document

{[ snackBarMessage ]}

Ask a homework question - tutors are online