lecture 11 overview. key management public-key encryption helps address key distribution problems...

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


LDAP Directory services

• Useful subset of X.500

• Easier to implement than X.500

• Widely available– Uses X.509 certificates


X.509 Certificate format


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.


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)


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


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


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


Secure programs

• Evaluation of what is “Secure” is subject to the perspective of the evaluator– Managers– Developers– Technicians– Clients


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


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!


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


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!


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


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”?


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


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)


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]);


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


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


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


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


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


lecture 11 overview. key management public-key encryption helps address key distribution problems...

Documents