Скачать презентацию CS 5950 6030 Network Security Class 12 W 9 28 05 Скачать презентацию CS 5950 6030 Network Security Class 12 W 9 28 05

8b061ada19afcfee8acf6136d65669af.ppt

  • Количество слайдов: 31

CS 5950/6030 Network Security Class 12 (W, 9/28/05) Leszek Lilien Department of Computer Science CS 5950/6030 Network Security Class 12 (W, 9/28/05) Leszek Lilien Department of Computer Science Western Michigan University Based on Security in Computing. Third Edition by Pfleeger and Pfleeger. Using some slides courtesy of: Prof. Aaron Striegel — at U. of Notre Dame Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. Washington Prof. Jussipekka Leiwo — at Vrije Universiteit (Free U. ), Amsterdam, The Netherlands Slides not created by the above authors are © by Leszek T. Lilien, 2005 Requests to use original slides for non-profit purposes will be gladly granted upon a written request.

2. Cryptology. . . 2 H. The Uses of Encryption 2 H. 1. Cryptographic 2. Cryptology. . . 2 H. The Uses of Encryption 2 H. 1. Cryptographic Hash Functions 2 H. 2. Key Exchange 2 H. 3. Digital Signatures 2 H. 4. Certificates a. Introduction – PART 1 Class 11 2 a. Introduction – PART 2 b. Trust Through a Common Respected Individual c. Certificates to Authenticate Identity—PART 1

Certificates (2) a. Introduction (1) Need for trust in human interactions n n Trust Certificates (2) a. Introduction (1) Need for trust in human interactions n n Trust w. r. t. : n Individuals n Institutions (e. g. , bank, hospital, car dealer) n Artifacts (e. g. , car, Internet browser, software house) Trust in small village vs. big city n n n Small village: implicit trust n Everybody knows everybody n Mr. X „feels” how much to trust Ms. Y Big city: need to consider trust explicitly n Ask around to find trusted entities n n Inquire friends, office mates, etc. about good car dealer, dentist, etc. Check „reputation databases” E. g. , BBB=Better Business Bureau 3

b. Trust Through Common Trusted Individual (1) n n Hierarchical structure of organizations n b. Trust Through Common Trusted Individual (1) n n Hierarchical structure of organizations n CEO / Divisions/ Departments / Groups / Projects n CEO doesn’t know engineers directly n Still, CEO controls all via intermediate managers => hierarchy as basis for trust in an organization Example Camilla n Ann meets Andy Betty Bill n Andy claims he works for the same company Ann Andy n Ann can verify via common trusted individual / trusted third party (TTP) § via Bill and Betty if Bill knows/trusts Betty § via Bill and Camilla, otherwise 4

c. Certificates to Authenticate Identity (1) Certificate for X n Identifier of X KPUB-X c. Certificates to Authenticate Identity (1) Certificate for X n Identifier of X KPUB-X TTP’s Signature TTP’s signature certifies trustworthiness of binding KPUB-X with X’s identity n n n 5 I. e. , states that KPUB-X is really X’s public key How are certificates created?

Certificates to Authenticate Identity (10 a) n ‘X’ KPUB-X Sg TTP_of_X Certificates for the Certificates to Authenticate Identity (10 a) n ‘X’ KPUB-X Sg TTP_of_X Certificates for the company example – CONT. pre. Cert. X n E. g. , if the full certification chain is: Sushil—Diana—Debbie—Ahmet—Camilla—Bill—Ann the certificate for Ann is: Cert. Ann = pre. Cert. Ann || pre. Cert. Bill || pre. Cert. Camilla || pre. Cert. Ahmet || pre. Cert. Debbie || Cert. Diana n n After creating Cert. Z, Bill sends it to Z n 6 Notes: - Diana has Cert defined by CEO => no pre. Cert. Diana - Cert’s become longer closer to the bottom of hierrarchy E. g. , sends Cert. Ann to Ann

Certificates to Authenticate Identity (10 b) We don’t want such loooong certificates! n n Certificates to Authenticate Identity (10 b) We don’t want such loooong certificates! n n n Note: The taller hierarchy the longer certificates Solution: Flatten the certificate hierarchy n The ultimate: 1 -level „hierarchy: Everybody (in a given organization) gets certificates from a single trusted Certificate Authority (CA) Note: If there is only single CA (not a chain of certifiers), there are no pre-certificates, only (flat) certificates (signed by CA only) 7

2. Cryptology. . . 2 H. The Uses of Encryption 2 H. 1. Cryptographic 2. Cryptology. . . 2 H. The Uses of Encryption 2 H. 1. Cryptographic Hash Functions 2 H. 2. Key Exchange 2 H. 3. Digital Signatures 2 H. 4. Certificates a. Introduction – PART 1 Class 12 a. Introduction – PART 2 b. Trust Through a Common Respected Individual c. Certificates to Authenticate Identity – PART 1 c. Certificates to Authenticate Identity – PART 2 d. Trust Without a Single Hierarchy 3. Program Security 3. 1. Secure Programs 3. 2. Nonmalicious Program Errors – PART 1 8

Certificates to Authenticate Identity (11) n Requirements for a certification scheme: 1) Any participant Certificates to Authenticate Identity (11) n Requirements for a certification scheme: 1) Any participant can read Cert to determine X and KPUB-X. 2) Any participant can verify that Cert originated from CA (Certificate Authority) and is not counterfeit. 3) Only CA can create and update Cert. 4) Any participant can verify the currency of Cert. To this end, each Cert must include a timestamp (not discussed by us). n 9 Q: Does our scheme satify these requirements? [cf. Stallings - „Cryptography and Network Security”

Certificates to Authenticate Identity (12) n n 10 Requirements for a certification scheme: 1) Certificates to Authenticate Identity (12) n n 10 Requirements for a certification scheme: 1) Any participant can read Cert to determine X and KPUB-X. 2) Any participant can verify that Cert originated from CA (Certificate Authority) and is not counterfeit. 3) Only CA can create and update Cert. 4) Any participant can verify the currency of Cert. A to the Q: „Does our scheme satify these requirements? ” 1) Yes: Can decrypt with KPUB-CA. 2) Yes: If can be decrypted with KPUB-CA, must’ve been encrypted by CA. 3) Yes: Only CA can encrypt Cert with KPUB-CA. 4) No, but. . . : Our scheme included no timestamps – but can be extended. [cf. Stallings - „Cryptography and Network Security”

d. Trust Without a Single Hierarchy (1) n n 11 Certificate structure relies on d. Trust Without a Single Hierarchy (1) n n 11 Certificate structure relies on TTP at the top of certificate hierarchy n TTP is not certified by anybody! n Must be very trustworthy If a „natural” hierarchy exists, certificate infrastructure can be based on it n E. g. , in a company Q: What if there is no „natural” hierarchy to use? n E. g. , Web sites on the Internet A: Can designate a person/organization to vouch for authenticity of people or documents n E. g. , a notary public for legal documents n E. g. , Registrar’s Office for grades

Trust Without a Single Hierarchy (2) n Q: How to find a trusted entity Trust Without a Single Hierarchy (2) n Q: How to find a trusted entity on the Internet? n Not hierarchical organization n n No „top” entity A: Some entities that are widely trusted outside Cyberspace, create certification entities in the Cyberspace n n n E. g. , C&W HKT, Secure. Net, Verisign, e. Trust in US Each one is at the „top” n n 12 Despite hierarchy of naming Each one has its users who trust it Different people, applications, etc. , can and do use different TTPs (CAs) for certification

Trust Without a Single Hierarchy (3) n Considerations for key distribution protocols (such as Trust Without a Single Hierarchy (3) n Considerations for key distribution protocols (such as the ones involving TTP or CA): n What are the operational restrictions? n n n 13 E. g. , need for 7/24 operation What are the trust requirements? How are failures dealt with? How efficient is the protocol? How easy to implement is the protocol? . . . [cf. J. Leiwo]

Remember and understand these distinctions: § Symmetric vs. asymmetric crypto systems § Asymmetric used: Remember and understand these distinctions: § Symmetric vs. asymmetric crypto systems § Asymmetric used: § to provide secure channel for exchange of symmetric keys § to encrypt vs. sign vs. whole certificate encryption § Asymmetric crypto system: Encrypt msg vs. sign msg vs. encrypt (pre-)certificate § Encrypt msg – S encrypts (E) with R’s public key § R decrypts msg with R’s private key § Sign msg – to sign a msg, S uses decryption algorithm D with S’s private key § R authenticates signature using encryption algorithm E with S’s public key § Encrypt (pre-)certificate – after signing a (pre-)certificate, certificate issuer encrypts (E) the whole (pre-)certficate with his own private key § Anybody who receives certificate can verify it by using decryption alg. D with certificate issuers’ public keys § But only certificate issuer can update certificates she issued! 14

Exercise scenarios to see you understand this well § Symmetric/asymmetric crypto systems § Asymmetric Exercise scenarios to see you understand this well § Symmetric/asymmetric crypto systems § Asymmetric used to exchange symmetric keys § Using asymmetric cryptosystems: encrypt msg vs. sign msg vs. encrypt (pre-)certificate 15

3. Program Security (1) § Program security – Our first step on how to 3. Program Security (1) § Program security – Our first step on how to apply security to computing n Protecting programs is the heart of computer security n n n All kinds of programs, from apps via OS, DBMS, networks Issues: n How to keep pgms free from flaws n How to protect computing resources from pgms with flaws Issues of trust not considered: n How trustworthy is a pgm you buy? n How to use it in its most secure way? n 16 Partial answers: n Third-party evaluations n Liability and s/w warranties

Program Security (2) § Outline: 3. 1. Secure Programs – Defining and Testing 3. Program Security (2) § Outline: 3. 1. Secure Programs – Defining and Testing 3. 2. Nonmalicious Program Errors 3. 3. Malicious Code 3. 3. 1. General-Purpose Malicious Code incl. Viruses 3. 3. 2. Targeted Malicious Code 3. 4. Controls Against Program Threats 17

3. 1. Secure Programs - Defining & Testing § 18 Outline a. Introduction b. 3. 1. Secure Programs - Defining & Testing § 18 Outline a. Introduction b. Judging S/w Security by Fixing Faults c. Judging S/w Security by Testing Pgm Behavior d. Judging S/w Security by Pgm Security Analysis e. Types of Pgm Flaws [cf. B. Endicott-Popovsky]

a. Introduction (1) § n Pgm is secure if we trust that it provides/enforces: a. Introduction (1) § n Pgm is secure if we trust that it provides/enforces: § Confidentiality § Integrity § Availability What is „Program security? ” Depends on who you ask n user - fit for his task n programmer - passes all „her” tests n manager - conformance to all specs n n 19 Developmental criteria for program security include: Correctness of security & other requirements Correctness of implementation Correctness of testing

Introduction (2) § Fault tolerance terminology: n Error - may lead to a fault Introduction (2) § Fault tolerance terminology: n Error - may lead to a fault n Fault - cause for deviation from intended function n Failure - system malfunction caused by fault n Note: [cf. A. Striegel] Faults - seen by „insiders” (e. g. , programmers) Failures - seen by „outsiders” (e. g. , independent testers, users) Error/fault/failure example: n n 20 Programmer’s indexing error, leads to buffer overflow fault Buffer overflow fault causes system crash (a failure) Two categories of faults w. r. t. duration [cf. A. Striegel] n Permanent faults n Transient faults – can be much more difficult to diagnose [cf. A. Striegel]

b. Judging S/w Security by Fixing Faults § An approach to judge s/w security: b. Judging S/w Security by Fixing Faults § An approach to judge s/w security: penetrate and patch § Red Team / Tiger Team tries to crack s/w § If you withstand the attack => security is good § Is this true? Rarely. § 21 Too often developers try to quick-fix problems discovered by Tiger Team Quick patches often introduce new faults due to: § Pressure – causing narrow focus on fault, not context § Non-obvious side effects § System performance requirements not allowing for security overhead [cf. A. Striegel]

c. Judging S/w Security by Testing Pgm Behavior (1) n Better approach to judging c. Judging S/w Security by Testing Pgm Behavior (1) n Better approach to judging s/w security: testing pgm behavior n Compare behavior vs. requirements (think testing/SW eng) n Program security flaw = = inappropriate behavior caused by a pgm fault or failure n Flaw detected as a fault or a failure Important: If flaw detected as a failure (an effect), look for the underlying fault (the cause) n Recall: fault seen by insiders, failure – by outsiders n 22 If possible, detect faults before they become failures Note: Texbook defines flaw-vulnerability-flaw in a circular way – a terminology soup!

Judging S/w Security by Testing Pgm Behavior (2) Any kind of fault/failure can cause Judging S/w Security by Testing Pgm Behavior (2) Any kind of fault/failure can cause a security incident § § § 23 Misunderstood requirements / error in coding / typing error In a single pgm / interaction of k pgms Intentional flaws or accidental (inadvertent) flaws Therefore, we must consider security consequences for all kinds of detected faults/failures § Even inadvertent faults / failures § Inadvertent faults are the biggest source of security vulnerabilities exploited by attackers § Even dormant faults § Eventually can become failures harming users

Judging S/w Security by Testing Pgm Behavior (3) § Problems with pgm behavior testing Judging S/w Security by Testing Pgm Behavior (3) § Problems with pgm behavior testing § Limitations of testing § § Complexity – malicious attacker’s best friend § § Too complex to model / to test Exponential # of pgm states / data combinations a faulty line hiding in 10 million lines of code Evolving technology § § 24 Can’t test exhaustively Testing checks what the pgm should do Can’t test what the pgm should not do § i. e. , can’t make sure that pgm does only what it should do – nothing more New s/w technologies appear Security techniques catching up with s/w technologies [cf. A. Striegel]

d. Judging S/w Security by Pgm Security Analysis Best approach to judging s/w security: d. Judging S/w Security by Pgm Security Analysis Best approach to judging s/w security: pgm security analysis n n Analyze what can go wrong n At every stage of program development! n n After deployment n n Configurations / policies / practices Protect against security flaws n Specialized security methods and techniques n Specialized security tools n 25 From requirement definition to testing E. g. , specialized security meth/tech/tools for switching s/w [cf. B. Endicott-Popovsky]

e. Types of Pgm Flaws n Taxonomy of pgm flaws: n Intentional n Malicious e. Types of Pgm Flaws n Taxonomy of pgm flaws: n Intentional n Malicious n Nonmalicious n Inadvertent n Validation error (incomplete or inconsistent) n n Domain error n n n 26 e. g. , using a variable value outside of its domain Serialization and aliasing n n e. g. , incomplete or inconsistent input data serialization – e. g. , in DBMSs or OSs aliasing - one variable or some reference, when changed, has an indirect (usually unexpected) effect on some other data Inadequate ID and authentication (Section 4—on OSs) Boundary condition violation Other exploitable logic errors [cf. B. Endicott-Popovsky]

3. 2. Nonmalicious Program Errors § 27 Outline a. Buffer overflows b. Incomplete mediation 3. 2. Nonmalicious Program Errors § 27 Outline a. Buffer overflows b. Incomplete mediation c. Time-of-check to time-of-use errors d. Combinations of nonmalicious program flaws

a. Buffer Overflows (1) n n Buffer overflow flaw — often inadvertent (=>nonmalicious) but a. Buffer Overflows (1) n n Buffer overflow flaw — often inadvertent (=>nonmalicious) but with serious security consequences Many languages require buffer size declaration n C language statement: char sample[10]; n Execute statement: sample[i] = ‘A’; where i=10 n Out of bounds (0 -9) subscript – buffer overflow occurs n Some compilers don’t check for exceeding bounds n C does not perform array bounds checking. n Similar problem caused by pointers n 28 No reasonable way to define limits for pointers [cf. B. Endicott-Popovsky]

Buffer Overflows (2) n n 29 Where does ‘A’ go? n Depends on what Buffer Overflows (2) n n 29 Where does ‘A’ go? n Depends on what is adjacent to ‘sample[10]’ n Affects user’s data - overwrites user’s data n Affects users code - changes user’s instruction n Affects OS data - overwrites OS data n Affects OS code - changes OS instruction This is a case of aliasing (cf. Slide 26) [cf. B. Endicott-Popovsky]

Buffer Overflows (3) n n Implications of buffer overflow: n Attacker can insert malicious Buffer Overflows (3) n n Implications of buffer overflow: n Attacker can insert malicious data values/instruction codes into „overflow space” Supp. buffer overflow affects OS code area n Attacker code executed as if it were OS code n Attacker might need to experiment to see what happens when he inserts A into OS code area n n 30 Can raise attacker’s privileges (to OS privilege level) n When A is an appropriate instruction Attacker can gain full control of OS [cf. B. Endicott-Popovsky]

End of Class 12 31 End of Class 12 31