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

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

4. 4 b. Trust Through Common Trusted Individual (1) Hierarchical structure of organizations CEO / Divisions/ Departments / Groups / Projects CEO doesn’t know engineers directly Still, CEO controls all via intermediate managers => hierarchy as basis for trust in an organization Example Ann meets Andy Andy claims he works for the same company 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 Camilla Betty Bill Ann Andy

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

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

7. 7 Certificates to Authenticate Identity (10b) We don’t want such loooong certificates! Note:The taller hierarchy the longer certificates Solution: Flatten the certificate hierarchy 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)

8. 8 2. Cryptology... 2H. The Uses of Encryption 2H.1. Cryptographic Hash Functions 2H.2. Key Exchange 2H.3. Digital Signatures 2H.4. Certificates a. Introduction – PART 1 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 Class 11 Class 12

9. 9 Certificates to Authenticate Identity (11) Requirements for a certification scheme: 1)Any participant can read Cert to determine X and K PUB-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). Q: Does our scheme satify these requirements? [cf. Stallings - „Cryptography and Network Security”

10. 10 Certificates to Authenticate Identity (12) Requirements for a certification scheme: 1)Any participant can read Cert to determine X and K PUB-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 K PUB-CA. 2)Yes: If can be decrypted with K PUB-CA, must’ve been encrypted by CA. 3)Yes: Only CA can encrypt Cert with K PUB-CA. 4)No, but...: Our scheme included no timestamps – but can be extended. [cf. Stallings - „Cryptography and Network Security”

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

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

13. 13 Trust Without a Single Hierarchy (3) Considerations for key distribution protocols (such as the ones involving TTP or CA) : What are the operational restrictions? 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]

14. 14 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!

15. 15 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

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

17. 17 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

18. 18 3.1. Secure Programs - Defining & Testing  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]

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

20. 20 Introduction (2)  Fault tolerance terminology: Error - may lead to a fault Fault - cause for deviation from intended function Failure - system malfunction caused by fault Note: [cf. A. Striegel] Faults - seen by „insiders” (e.g., programmers) Failures - seen by „outsiders” (e.g., independent testers, users) Error/fault/failure example: 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] Permanent faults Transient faults – can be much more difficult to diagnose [cf. A. Striegel]

21. 21 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.  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]

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

23. 23 Judging S/w Security by Testing Pgm Behavior (2)  Any kind of fault/failure can cause a security incident  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

24. 24 Judging S/w Security by Testing Pgm Behavior (3)  Problems with pgm behavior testing  Limitations of testing  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  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  New s/w technologies appear  Security techniques catching up with s/w technologies [cf. A. Striegel]

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

26. 26 e. Types of Pgm Flaws Taxonomy of pgm flaws: Intentional Malicious Nonmalicious Inadvertent Validation error (incomplete or inconsistent) e.g., incomplete or inconsistent input data Domain error e.g., using a variable value outside of its domain Serialization and aliasing 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]

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

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

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

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

31. 31 End of Class 12