1. Lecture 11 Overview

2. Key Management public-key encryption helps address key distribution problems have two aspects of this: – distribution of public keys – use of public-key encryption to distribute secret keys CS 450/650 Lecture 11: Digital Certificates 2

3. Digital Certificates A digital certificate is a digital file that certifies the identity of – an individual, – an institution, – a server, – a router seeking access to computer- based information. It is issued by a Certification Authority (CA). CS 450/650 Lecture 11: Digital Certificates 3

4. Trusted third party Certification authority (CA) They issue digital certificates and validate holders’ identity and authority. CA can – meet with Alice – look at her driver's license / birth certificate / etc – take her fingerprints CA will then – sign her public key CS 450/650 Lecture 11: Digital Certificates 4

5. Man-in-the-middle? When Trudy tries to substitute her public key for Alice's – Bob will either notice that the key isn't certified, or – Notice that it is certified but not for Alice, for someone else CS 450/650 Lecture 11: Digital Certificates 5

6. Masquerading as CA? Trudy could falsely issue a certificate – sign the certificate pretending to be the CA But – strong interest in making CA’s correct public key well known Multiple sources to access the CA's public key – Some public keys are actually bundled with IE CS 450/650 Lecture 11: Digital Certificates 6

7. Public key certificate Certificate by the CA – Embed public key along with other identifying information – cryptographically sign it as a tamper-proof seal verifying the integrity of the data within the certificate validating its use During the valid period – public key is valid for use – association with identity assumed correct – revocation notifications will be published CS 450/650 Lecture 11: Digital Certificates 7

8. Issues Trust in the CA – issuance policies Security of the CA's private key – very important!!! Multiple CAs – Alice's public key is signed by C1 – Bob's public key is signed by C2 CS 450/650 Lecture 11: Digital Certificates 8

9. Multiple CA Solutions Full distribution – every user has the public key for every CA – Impractical Cross certification – Suppose Alice presents Bob with C1's public key – Signed by C2 – Bob can verify the certificate C2 – C1's public key can be trusted – Therefore Alice's public key can be trusted CS 450/650 Lecture 11: Digital Certificates 9

10. Hierarchical trust model Root CA – a generally-trusted CA e.g. Federal Reserve Bank – all parties trust root Non-root CAs – have certificates signed by root CA, or – signed by another non-root CA closer to the root CA Certification path – the chain of certifications from the root to a particular public key certificate CS 450/650 Lecture 11: Digital Certificates 10

11. Validity Public key is not valid forever – limits risk associated with key compromise – 1 year is typical Certificates have a valid period – expired certificate may still be useful non-repudiation – new certificate issued when old one expires Possibly the same key re-certified CS 450/650 Lecture 11: Digital Certificates 11

12. Revoking a certificate Reasons for revocation – Detected or suspected compromise – Change of data e.g. subject name – Change of relationship between subject and CA e.g. employee quitting a job from an organization which uses the current CA CS 450/650 Lecture 11: Digital Certificates 12

13. Certificate Revocation List CRL is a time-stamped list of revoked certificates, – digitally signed by the CA – available to all users Each revoked cert is identified by a certificate serial number CRL contains digital signatures, thus can be sent via unprotected channels Users of public key certificates should check a suitably-recent CRL CS 450/650 Lecture 11: Digital Certificates 13

14. Certificate Revocation List The user of a public key – must check the CRL – every time the key is used – not enough to check when the certificate is originally accepted CA – must keep a revoked certificate in the CRL until it expires – list could get large CS 450/650 Lecture 11: Digital Certificates 14

15. CRL Distribution Pull method – CA periodically updates CRL depository – users check when using a public key Push method – broadcast new CRL when it changes Both subject to denial of service attacks CS 450/650 Lecture 11: Digital Certificates 15

16. Online Certificate Status Protocol Request / response protocol – Verifier receives up-to-the-minute status info Alice checks Bob's public key directly with CA – most effective – most costly Costs – handling traffic for every public key use – handling cryptographic operations at high spped – maintaining high security in Internet environment subject to denial of service attack CS 450/650 Lecture 11: Digital Certificates 16

17. Short-Lived Certificates Certificate valid for 1 day at a time – re-requested each day – possibly the same public key Revocation not necessary – client stops asking for a new certificate Suitable for limited resource systems – e.g. mobile wireless systems Assumes efficient certificate generation CS 450/650 Lecture 11: Digital Certificates 17

18. Bob’s public key Bob’s identifying information CA private key K B + certificate for Bob’s public key, signed by CA Digital signature (encrypt) K B + K CA - Bob’s public key Bob’s identifying information CA private key K B + certificate for Bob’s public key, signed by CA K B + K CA Obtaining a certificate CS 450/650 Lecture 11: Digital Certificates 18

19. Directory services General case for public key discovery Online access to a directory – request a public key certificate for a given user In this case – Alice sends only the signed message – Bob is responsible for getting Alice's certificate CS 450/650 Lecture 11: Digital Certificates 19

20. Obtaining an Individual’s Public Key – When Alice wants Bob’s public key: Alice gets Bob’s certificate (from Bob or elsewhere). apply CA’s public key to Bob’s certificate, get Bob’s public key K B + digital signature (decrypt) K B + CA public key K CA Bob’s public key CS 450/650 Lecture 11: Digital Certificates 20

21. X.500 Directory services Developed by the international standards bodies Extremely general – look up by name – browse available entities – representing people, devices, applications, etc. Extension for public key certificates – X.509 CS 450/650 Lecture 11: Digital Certificates 21

22. LDAP Directory services Useful subset of X.500 Easier to implement than X.500 Widely available – Uses X.509 certificates CS 450/650 Lecture 11: Digital Certificates 22

23. X.509 Certificate format CS 450/650 Lecture 11: Digital Certificates 23

24. Directory Information Tree Country – C=US, Canada, Mexico, etc. Organization – O=DePaul University, UIC, Northwestern University, etc. Organizational unit – OU=CTI, LA&S, Commerce, Theater, etc. Common Name – CN=Robin Burke, Yonghe Yan, etc. CS 450/650 Lecture 11: Digital Certificates 24

25. Distinguished name A collection of choices at each level of the DIT – leading to an individual Not necessarily a person – printer, router, application, web server DN – {C=US, O=DePaul University, OU=CTI, CN=Robin Burke} To prevent collision – augment the common name with some other identifier CS 450/650 Lecture 11: Digital Certificates 25

26. Object identifiers Problem – different organization may want their own "objects" – impossible to create a list of legal values in advance Like DIT tree – but with integers Used to label – algorithms – certificate types CS 450/650 Lecture 11: Digital Certificates 26

27. Lecture 12 Program Security CS 450/650 Fundamentals of Integrated Computer Security Slides are modified from Wayne Summers and Ian Goldberg

28. Secure programs Security implies some degree of trust that the program enforces expected – confidentiality, – integrity, and – availability. How can we look at software component and assess its security? CS 450/650 Lecture 12: Program Security 28

29. Secure programs Why is it so hard to write secure programs? A simple answer [CHE02]: – Axiom (Murphy): Programs have bugs – Corollary: Security-relevant programs have security bugs CS 450/650 Lecture 12: Program Security 29

30. Flaws, faults, and failures A flaw is a problem with a program A security flaw is a problem that affects security in some way – Confidentiality, integrity, availability Flaws come in two types: faults and failures A fault is a mistake “behind the scenes” – An error in the code, data, specification, process, etc. – A fault is a potential problem CS 450/650 Lecture 12: Program Security 30

31. Flaws, faults, and failures A failure is when something actually goes wrong – You log in to the library's web site, and it shows you someone else's account – “Goes wrong” means a deviation from the desired behaviour, not necessarily from the specified behaviour! The specification itself may be wrong A fault is the programmer/specifier/inside view A failure is the user/outside view CS 450/650 Lecture 12: Program Security 31

32. Secure programs Evaluation of what is “Secure” is subject to the perspective of the evaluator – Managers – Developers – Technicians – Clients CS 450/650 Lecture 12: Program Security 32

33. Secure programs The quantity and types of faults in requirements design and code implementation are often used as evidence of a product‘s quality or security A program that undergoes very rigorous testing and is found to have 100 errors that are fixed, or A program that undergoes less scrutiny but only locates 20 errors that are found and fixed? – Programs with a large number of identified faults tend to exhibit even more faults as time progresses – Fewer faults up front is usually an indicator of well designed and fault free implementations even when less rigorous testing is done CS 450/650 Lecture 12: Program Security 33

34. Finding and fixing faults How do you find a fault? – If a user experiences a failure, you can try to work backwards to uncover the underlying fault What about faults that haven't (yet) led to failures? – Intentionally try to cause failures, then proceed as above Remember to think like an attacker! CS 450/650 Lecture 12: Program Security 34

35. Finding and fixing faults Once you find some faults, fix them – Usually by making small edits (called patches) to the program – This is called “penetrate and patch” – Microsoft's “Patch Tuesday” is a well-known example second Tuesday of each month, Microsoft releases security patches CS 450/650 Lecture 12: Program Security 35

36. Problems with patching Patching sometimes makes things worse! – Pressure to patch a fault is often high causing a narrow focus on the observed failure, instead of a broad look at what may be a more serious underlying problem – The fault may have caused other, unnoticed failures, and a partial fix may cause inconsistencies or other problems – The patch for this fault may introduce new faults, here or elsewhere! CS 450/650 Lecture 12: Program Security 36

37. Unexpected behaviour When a program's behaviour is specified, spec usually lists the things the program must do – ls command must list the names of files in the directory whose name is given on the command line, if the user has permissions to read that directory Most implementers wouldn't care if it did additional things as well – Sorting list of filenames alphabetically before outputting them is fine CS 450/650 Lecture 12: Program Security 37

38. Unexpected behaviour But from a security / privacy point of view, extra behaviours could be bad! – After displaying the filenames, post the list to a public web site – After displaying the filenames, delete the files When implementing a security or privacy relevant program, consider “and nothing else” to be implicitly added to the spec – “should do” vs. “shouldn't do” – How would you test for “shouldn't do”? CS 450/650 Lecture 12: Program Security 38

39. Types of security flaws Genesis (where they came from)‏ Some flaws are intentional – Malicious flaws are intentionally inserted to attack systems If it's meant to attack some particular system, we call it a targeted malicious flaw – Nonmalicious (but intentional) flaws are often features that are meant to be in the system are correctly implemented, but can cause a failure when used by an attacker CS 450/650 Lecture 12: Program Security 39

40. Types of security flaws Most security flaws are caused by unintentional program errors Most common sources of unintentional security flaws – Buffer overflows – Incomplete mediation – TOCTTOU errors (race conditions)‏ CS 450/650 Lecture 12: Program Security 40

41. Buffer overflows The single most commonly exploited type of security flaw Simple example: #define LINELEN 1024 char buffer[LINELEN]; gets(buffer); or strcpy(buffer, argv[1]); CS 450/650 Lecture 12: Program Security 41

42. What's the problem? The gets and strcpy functions don't check that the string they're copying into the buffer will fit in the buffer! Some languages would give an exception here, and crash the program. – Is this an OK solution C doesn't even notice something bad happened, and continues on its merry way – the most commonly used language for systems programming CS 450/650 Lecture 12: Program Security 42

43. Where a Buffer Can Overflow CS 450/650 Lecture 12: Program Security 43

44. Smashing The Stack For Fun And Profit This is a classic (somewhat dated) exposition of how buffer overflow attacks work Upshot: if the attacker can write data past the end of an array on the stack, he can usually overwrite things like the saved return address – When the function returns, it will jump to any address of his choosing Targets: programs on a local machine that run with setuid (superuser) privileges, or network daemons on a remote machine CS 450/650 Lecture 12: Program Security 44

45. Kinds of buffer overflows In addition to the classic attack which overflows a buffer on the stack to jump to shellcode, there are many variants: – Attacks which work when a single byte can be written past the end of the buffer often caused by a common off-by-one error – Overflows of buffers on the heap instead of the stack – Jump to other parts of the program, or parts of standard libraries, instead of shellcode CS 450/650 Lecture 12: Program Security 45

46. Defences against buffer overflows Use a language with bounds checking – And catch those exceptions! Non-executable stack – memory page is either writable or executable Stack (and code) at random addresses – Linux 2.6 does this “Canaries” that detect if the stack has been overwritten before return from each function – This is a compiler feature CS 450/650 Lecture 12: Program Security 46

47. Integer overflows Machine integers can represent only a limited set of numbers – might not correspond to programmer's model Program assumes integer is always positive – overflow will make (signed) integer wrap and become negative, which will violate assumption Program casts large unsigned integer to signed integer Result of a mathematical operation causes overflow Attacker can pass values to program that will trigger overflow CS 450/650 Lecture 12: Program Security 47