Upload
brittney-robertson
View
216
Download
2
Embed Size (px)
Citation preview
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
IECS 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 C1– Bob's public key is signed by C2
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 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
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 certificateCS 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 attackCS 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
Bob’s public
key
Bob’s identifying informatio
n
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 informatio
n
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
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
K B+
digital
signature
(decrypt) K B+
CA public
key
K CA
Bob’s public
key
CS 450/650 Lecture 11: Digital Certificates 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=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
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
identifierCS 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
OID: 1.2.840.113549.1.1.5
0 (itu-t) 1 (iso) 2 (joint-iso-itu-t)
2 (member-body)
840 (us)
113549 (rsadsi)
1 (pkcs)
1 (pkcs-1)
5 (sha-1WithRASEncryption)
16 (country)
840 (us)
1 (organization)
15678 (sharons)
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 [CHE02]:
– 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 wrongA 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); orstrcpy(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
programmingCS 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