Lecture 11 Overview
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
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
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
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
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
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
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 C 1 – Bob's public key is signed by C 2 CS 450/650 Lecture 11: Digital Certificates 8
Multiple CA Solutions • Full distribution – every user has the public key for every CA – Impractical • Cross certification – Suppose Alice presents Bob with C 1's public key – Signed by C 2 – Bob can verify the certificate C 2 – C 1's public key can be trusted – Therefore Alice's public key can be trusted CS 450/650 Lecture 11: Digital Certificates 9
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
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
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
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
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
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
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
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
Obtaining a certificate Bob’s public key + KB Bob’s identifying information CS 450/650 Lecture 11: Digital Certificates Digital signature (encrypt) CA private key + KB K- CA certificate for Bob’s public key, signed by CA 18
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
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 + KB digital signature (decrypt) CA public key CS 450/650 Lecture 11: Digital Certificates + KB Bob’s public key K CA 20
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
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
X. 509 Certificate format CS 450/650 Lecture 11: Digital Certificates 23
Directory Information Tree • Country – C=US, Canada, Mexico, etc. • Organization – O=De. Paul 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
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=De. Paul 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
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
Lecture 12 Program Security CS 450/650 Fundamentals of Integrated Computer Security Slides are modified from Wayne Summers and Ian Goldberg
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
Secure programs • Why is it so hard to write secure programs? • A simple answer [CHE 02]: – Axiom (Murphy): Programs have bugs – Corollary: Security-relevant programs have security bugs CS 450/650 Lecture 12: Program Security 29
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
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
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
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
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
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
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
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
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
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
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
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
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
Where a Buffer Can Overflow CS 450/650 Lecture 12: Program Security 43
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
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
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
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
Скачать презентацию Lecture 11 Overview Key Management public-key
af588e1afa13cf261dc3bf5d46808a8b.ppt