CS 5950/6030 Network SecurityClass 12 (W, 9/28/05)

Leszek LilienDepartment 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 DameProf. 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, 2005Requests to use original slides for non-profit purposes will be gladly granted upon a written

request.

2

2. Cryptology ...2H. The Uses of Encryption

2H.1. Cryptographic Hash Functions2H.2. Key Exchange 2H.3. Digital Signatures2H.4. Certificates

a. Introduction – PART 1

a. Introduction – PART 2b. Trust Through a Common Respected Individualc. Certificates to Authenticate Identity—PART 1

Class11

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

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

BettyBill

Ann Andy

5

c. Certificates to Authenticate Identity (1) Certificate for X

TTP’s signature certifies trustworthiness of binding KPUB-X with X’s identity

I.e., states that KPUB-X is really X’s public key

How are certificates created?

Identifier of X

KPUB-X

TTP’s Signature

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—Annthen the certificate for Ann is:

CertAnn = preCertAnn || preCertBill || preCertCamilla || preCertAhmet || preCertDebbie || CertDiana

Notes:- Diana has Cert defined by CEO => no preCertDiana

- Cert’s become longer closer to the bottom of hierrarchy

After creating CertZ, Bill sends it to Z E.g., sends CertAnn to Ann

‘X’

KPUB-X

SgTTP_of_X

preCertX

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

2. Cryptology ...2H. The Uses of Encryption

2H.1. Cryptographic Hash Functions2H.2. Key Exchange 2H.3. Digital Signatures2H.4. Certificates

a. Introduction – PART 1

a. Introduction – PART 2b. Trust Through a Common Respected Individualc. Certificates to Authenticate Identity – PART 1c. Certificates to Authenticate Identity – PART 2d. Trust Without a Single Hierarchy

3. Program Security3.1. Secure Programs3.2. Nonmalicious Program Errors – PART 1

Class 11

Class12

9

Certificates to Authenticate Identity (11) Requirements for a certification scheme:

1) Any participant can read Cert to determine X and KPUB-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

Certificates to Authenticate Identity (12) Requirements for a certification scheme:

1) Any participant can read Cert to determine X and KPUB-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 KPUB-CA.

2) Yes: If can be decrypted with KPUB-CA, must’ve been encrypted by CA.

3) Yes: Only CA can encrypt Cert with KPUB-CA.

4) No, but...: Our scheme included no timestamps – but can be extended.[cf. Stallings - „Cryptography and Network Security”

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

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

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

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

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

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

Program Security (2)

Outline:3.1. Secure Programs – Defining and Testing3.2. Nonmalicious Program Errors3.3. Malicious Code

3.3.1. General-Purpose Malicious Code incl. Viruses

3.3.2. Targeted Malicious Code3.4. Controls Against Program Threats

18

3.1. Secure Programs - Defining & Testing

Outlinea. Introductionb. Judging S/w Security by Fixing Faultsc. Judging S/w Security by Testing Pgm Behaviord. Judging S/w Security by Pgm Security Analysise. Types of Pgm Flaws

[cf. B. Endicott-Popovsky]

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

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

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 TeamQuick 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

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

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

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

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

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

3.2. Nonmalicious Program Errors Outline

a. Buffer overflowsb. Incomplete mediationc. Time-of-check to time-of-use errorsd. Combinations of nonmalicious program flaws

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

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

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

End of Class 12