CS 5950/6030 – Computer Security and Information Assurance Section 2: Introduction to Cryptology (Part 2) Dr. Leszek Lilien Department of Computer Science

CS 5950/6030 –Computer Security and Information Assurance

Section 2: Introduction to Cryptology (Part 2)

Dr. Leszek LilienDepartment of Computer Science

Western Michigan University

Slides based on Security in Computing. Third Edition by Pfleeger and Pfleeger.Using some slides courtesy of:

Prof. Aaron Striegel — course taught at U. of Notre DameProf. Barbara Endicott-Popovsky and Prof. Deborah Frincke (U. Idaho) — taught at U.

WashingtonProf. Jussipekka Leiwo — taught at Vrije Universiteit (Free U.), Amsterdam, The Netherlands

Slides not created by the above authors are © 2006 by Leszek T. LilienRequests to use original slides for non-profit purposes will be gladly granted upon a written request.

2© 2006 by Leszek T. LilienSection 2-1 – Computer Security and Information Assurance – Spring 2006

Introduction to Cryptology – Part 1Covered:

2A. Terminology and Background2A.1. Threats to Messages

2A.2. Basic Terminology and Notation2A.3. Requirements for Crypto Protocols2A.4. Representing Characters

2B. Basic Types of Ciphers2B.1. Substitution Ciphers

a. The Ceasar Cipherb. Other Substitution Ciphersc. One-Time Pads

2B.2. Transposition Ciphers2B.3. Product Ciphers

2C. Making „Good” Ciphers2C.1. Criteria for „Good” Ciphers2C.2. Stream and Block Ciphers2C.3. Cryptanalysis2C.4. Symmetric and Asymm. Cryptosystems


2D. The DES (Data Encryption Standard) Algorithm

2D.1. Background and History of DES2D.2. Overview of DES2D.3. Double and Triple DES2D.4. Security of DES

2E. The Clipper Story2F. AES (Advanced Encryption Standard)

2F.1. The AES Contest2F.2. Overview of Rijndael2F.3. Strength of AES2F.4. Comparison of DES and AES

... Part 1 of Section 2 Ended Here ...

Introduction to Cryptology – Part 1 Covered (cont.)


Introduction to Cryptology – Part 2Outline (1)

2G. Public Key Encryption (PKE)2G.1. Motivation for PKE2G.2. Characteristics of PKE2G.3. RSA (Rivest-Shamir-Adelman) Encryption

2H. The Uses of Encryption2H.1. Cryptographic Hash Functions2H.2. Key Exchange2H.3. Digital Signaturesa. Problem Definitionb. Properties of Electronic Signaturesc. Using PKE for Digital Signaturesd. Using Hash Fcns for Digital Signatures


Introduction to Cryptology – Part 2Outline (2)

2H. The Uses of Encryption – cont.

2H.4. Certificates a. Introductionb. Trust Through a Common Respected Individualc. Certificates for Identity Authenticationd. Trust Without a Single Hierarchy


2G. Public Key Encryption (PKE)

Recall: Two main types of cryptosystems: Classical (= symmetric) Public key (= asymmetric)

Outline

2G.1. Motivation for PKE

2G.2. Characteristics of PKE

2G.3. RSA (Rivest-Shamir-Adelman) Encryption


2G.1. Motivation for PKE (1)

So far - cryptosystems with secret keys

Problems: A lot of keys

o(n2) keys for n users (n * (n-1) /2 keys)— if each must be able to communicate with each

Distributing so many keys securely Secure storage for the keys

User with n keys can’t just memorize them

Can have a system with significantly fewer keys?

Yes!


Motivation for PKE (2) 1976 — Diffie and Hellman — new kind of cryptosystem:

public key cryptosystem = asymmetric cryptosystem Key pairs: < kPRIVATE, kPUBLIC> Each user owns one private key Each user shares the corresponding public key with n-1

remaining users => n users share each public key

Only 2n keys for n users 2n = n * (1 + n * 1/n) Since public key is shared by n people: 1 „owner” + (n-1) others = n 1/n since each part „owns” 1/n of the public key

Even if each communicates with each Reduction from o(n2) to o(n) ! n key pairs are:

<kPRIV-1, kPUB-1 >, <kPRIV-2, kPUB-2>, ..., <kPRIV-n, kPUB-n>


2G.2. Characteristics of PKE (1)

PKE requirements1. It must be computationally easy to encipher or

decipher a message given the appropriate key

2. It must be computationally infeasible to derive kPRIV from kPUB

3. It must be computationally infeasible to determine kPRIV from a chosen plaintext attack

[cf. Barbara Endicott-Popovsky, U. Washington]


Characteristics of PKE (2)

Key pair characteristics

One key is inverse of the other key of the pair i.e., it can undo encryption provided by the

other: D(kPRIV, E(kPUB, P)) = P D(kPUB, E(kPRIV, P)) = P

One of the keys can be public since each key does only half of E ”+” D

As shown above – need both E and D to get P back


Characteristics of PKE (3) Two E/D possibilities for key pair <kPRIV, kPUB >

P = D(kPRIV, E(kPUB, P)) User encrypts msg with kPUB (kPUB” ”locks”) Recipient decrypts msg with kPRIV (kPRIV ”unlocks”)

OR P = D(kPUB, E(kPRIV, P)) (e.g., in RSA)

User encrypts msg with kPRIV (kPRIV ”locks”) Recipient decrypts msg with key kPUB (kPUB

”unlocks”)

Do we still need symmetric encryption (SE) systems? Yes, PKEs are 10,000+ times (!) slower than SEs

PKEs use exponentiation – involves multiplication and division SEs use only bit operations (add, XOR< substitute, shift) – much

faster


2G.3. RSA Encryption (1)

RSA = Rivest, Shamir, and Adelman (MIT), 1978

Underlying hard problem: Number theory – determining prime factors of a

given (large) number (ex. factoring of small #: 5 5, 6 2 *3)

Arithmetic modulo n

How secure is RSA? So far remains secure (after all these years...) Will sb propose a quick algorithm to factor large

numbers? Will quantum computing break it? TBD


RSA Encryption (2)

In RSA:P = E (D(P)) = D(E(P)) (order of D/E does not matter) More precisely: P = E(kE, D(kD, P)) = D(kD, E(kE,

P))

Encryption: C = Pe mod n KE = e Given C, it is very difficult to find P without

knowing KD

Decryption: P = Cd mod n KD = d


2H. The Uses of Encryption

PKE is much slower than SE (symmetric E) PKEs only for specialized, infrequent tasks SEs – a real workhorse

Four applications of encryption (& outline) Cryptographic Hash Functions (subsec.

2H.1) Key Exchange (subsec. 2H.2) Digital Signatures (subsec. 2H.3) Certificates (subsec. 2H.4)


2H.1. Cryptographic Hash Functions (1)

Integrity: How can you be sure that a recived msg/doc was

not modified by an attacker or malfunction? Answer: use cryptography to ensure integrity

Idea: Wax seals on letters in Middle Ages

— easy to see if broken Cryptographic „seal” on doc/msg

— so that any change to it will be readily detected


Cryptographic Hash Fcns (2)

A technique:compute a hash fcn / checksum / msg digest

More formally: Problem: How to send n-bit msg so that R can

easily verify that it is intact

Solution: Send a msg of n+k bits n bits — original msg k bits — checksum = msg digest

Generated based on the n bits



Simple Parity for Error Detection (1) Simple (non-cryptographic) technique: parity

Add a single parity bit to detect if a message is correct

Example 1: odd parityForce the block of data to have an odd # of 1’s

Data = 1011 — n = 4 Sent block = 10110 — n+k = 4+1

— looked at ‘1011’, added 0 to have odd # of 1’s Data = 0110 Sent block = 01101

— looked at ‘0110’, added 1 to have odd # of 1’s

Example 2: ASCII parity bit ASCII has 7 bits for data, 8th bit is single parity

bit Either odd or even parity used

[cf. A. Striegel, U. Notre Dame]


How parity enhances msg integrity? Can detect error in 1 bit (or in odd # of bits)

e,.g, if R gets 01001, R knows it’s wrong(S sent 01101)

Cannot detect error in 2 bits (or in even # of bits) Bec. parity stays OK -> undetectable integrity

violation e.g, if R gets 01011, R knows it’s wrong

(S sent 01101)

Cannot repair errors either E.g., R doesn’t know which bit in 01001 is wrong



Simple Parity for Error Detection (2)



Better Checksums against Errors & Attacks

There are better checksums than simple odd/even parity Can detect multiple errors Can even repair multiple errors

These checksums are to fix errors, not deal with attacks

For attacks needcryptographic checksums / strong hash functions



Strong Hash Function Formal definition:

strong hash function (cryptographic checksum) is h: A -> B such that:

1) For any x A, h(x) is easy to compute2) For any y B, it is computationally infeasible to

findinverse of y, i.e., x A such that h(x) = y

3) It is computationally infeasible to find a pair of colliding input values, i.e. x, x’ A such that x ≠ x’ and h(x) = h(x’)Alternate (stronger) form for (3):Given any x A, it is computationally infeasible to

findx’ A such that x ≠ x’ and h(x) = h(x’)

Due to (1) and (2), hash fcn is a one-way function[cf. A. Striegel, U. Notre Dame, Barbara Endicott-Popovsky, U. Washington]



Collisions & Attacks on Msg Integrity (1) Note:

n bits of msg (x) mapped into k bits of its checksum (y)

k < n => collisions must exist But it is computationally infeasible to find collisions

for good hash fcns

Goal of a successful attack on msg integrity: Change msg1 in such a way that checksum remains

unchanged (so R doesn’t detect the forgery) I.e., find msg2 that collides with the original msg1

w.r.t. checksum value Finding msg2 is computationally infeasible (for good

hash)

=> forging msg1 undetectably is computationally infeasible



Pigeonhole principle n containers for n+1 objects (n pigeonholes for n+1

pigeons)=> at least 1 container will hold two objects

Example: n = length(msg) = 5, k = length(hash)= 3 25=32 possible msgs vs. 23=8 possible hash values

=> at least 4 (= 32/8) different msgs hash into the same value (collisions!)

Real msgs and hash values are much longer than 5 or 3 bits!We know that collisions exist but:=> much tougher to find collisions=> much tougher to forge them



Collisions & Attacks on Msg Integrity (2)



File Checksum File checksum

Calculated, a fcn defined on all bits of the file Result encrypted and stored with the file Each time file used by legitimate users, checksum

recalculated, encrypted, stored with the file

File sent to R When file received by R:

R decrypts checksum c1 received in the file R independently calculates file checksum c2 If c1 = c2 => file integrity is OK Otherwise – file integrity violated



Keyed vs. Keyless Crypto Checksum (1)

Keyed crypto checksum Key needed to compute checksum

Keyed hash fcns DES, AES Use it in chaining mode:

link next msg block to value of the previous msg block

Example chaining: E(current block) XOR E(previous block)

=> connects block to all previous blocks

If file sent, file’s checksum could be the last block

If chaining used, file checksum (=last block) depends on all previous blocks => depends on all bits of the file



Keyed vs. Keyless Crypto Checksum (2)

Keyed crypto checksum – CONT. Used for integrity + authentication

Integrity: checksum makes msg modification difficult

Authentication: only S and R know symmetric keyR: if msg integrity is OK, it must have been sent by S



Keyed vs. Keyless Crypto Checksum (3) Keyless crypto checksum

No key required to compute checksum

Keyless hash functions MD5/MD4: any msg 128-bit digest (hash,

checksum) SHA/SHS: any msg 160-bit digest Other: MD2, HAVAL, Snefru, ...

Used for integrity (not authentication) Integrity: checksum makes msg modification difficult

(with truly public key anybody can send msg, but nobody but S can easily modify this msg)

No authentication: n (or all) people know public key –R can’t prove which one of them sent a given msg

[cf. A. Striegel, U. Notre Dame, Barbara Endicott-Popovsky, U. Washington]


2H.2. Key Exchange (1) Motivation:

X and Y don’t know each other X needs to send protected msg to Y

E.g., shopping on a web site

can do it if can securely exchange KE

This is the problem of key exchange Important Hard

Circular (chicken-’n-egg) problem?„To establish secure session need secure channel”

Circle can be broken – by public key cryptography

Can send public key even on insecure channel


Key Exchange (2)

Deriving Symmetric Key via PKE (1)

Given S and R / kPRIV-S, kPUB-S -- kPRIV-R, kPUB-R

Solution 1: S determines secret key K S encrypts K with kPRIV-S : C = E(kPRIV-S, K) S sends C to R R decrypts C to get K: D(kPUB-S, C) = K S & R communicate using secret (symmetric) key

K

BUT: Solution 1 is not good!!! Question: Why?


Key Exchange (3)


Given S and R / kPRIV-S, kPUB-S -- kPRIV-R, kPUB-R

Solution 1: S determines secret key K S encrypts K with kPRIV-S: C = E(kPRIV-S, K) S sends C to R R decrypts C to get K: D(kPUB-S, C) = K S & R communicate using secret (symmetric) key K

BUT: Solution 1 is not good !!! Answer:

Attacker who has kPUB-S can also perform decryption! The easier the more people know kPUB-S

Trivial if kPUB-S is truly public


Key Exchange (4)


Solution 2: S determines secret key K S encrypts K with kPUB-R: C = E(kPUB-R, K) S sends C to R R decrypts C to get K: D(kPRIV-R, C) = K S & R communicate using secret (symmetric) key K

Solution 2 is better Only R can decode K (only R knows kPRIV-R)

...but Solution 2 still is not quite good Question: Why?

Hint: what about msg authentication?


Key Exchange (5)

Deriving Symmetric Key via PKE (4) Solution 2:

S determines secret key K S encrypts K with kPUB-R: C = E(kPUB-R , K) S send C to R R decrypts C to get K: D(kPRIV-R , C) = K S & R communicate using secret (symmetric) key K

Solution 2 is better Only R can decode K (only R knows kPRIV-R)

...but Solution 2 still is not quite good Answer:

No msg authentication(R has no assurance that msg was sent by S

– anybody could have encoded with kPUB-R)


Key Exchange (6)


Solution 3: S determines secret key K S encrypts K with both kPRIV-S & kPUB-R :

C = E(kPUB-R , E(kPRIV-S, K)) S sends C to R R decrypts C to get K:

D( kPUB-S , D(kPRIV-R, C) ) -- order important ! make sure you see this

(see Fig. 2-11 p.78)

Solution 3 is good! Only R can decode K (only R knows kPRIV-R)

Authentication: R is assured that S sent C Only S could have encoded K with kPRIV-S


2H.3. Digital Signatures (1)

Outline: a. Problem Definition b. Properties of Electronic Signatures c. Using PKE for Digital Signatures d. Using Hash Fcns for Digital Signatures


Digital Signatures (2)

a. Problem Definition (1) Motivation:

Need to sign and transmit electronic doc’s or msgs, incl. checks

Analogous to signing & transmitting „paper” letters, doc’s, etc., incl. checks

Roles of signatures (for both paper a& electronic) Proves unforgeability of doc/letter/check Authenticates person S who signed doc/letter/check Provides non-repudiation: S cannot say sb else

signed it Facilitates proving integrity (e.g., 2 signed legal copies for 2

parties)

Note: signature might not identify the signing person if not legible



Problem Definition (2)

Security requirements for digital signatures: Signature will not reveal signer’s private key Only owner of private key can produce a valid

signature Verification of a correct signature succeeds Modification of a signed message can be

detected

[cf. J. Leiwo]



b. Properties of Electronic Signatures (1)

M – msg / Sg(S, M) – signature of S on MNote: M = C or M = P M = P – if authentication but no secrecy needed

Required properties for electronic signatures: Unforgeable:

Only S can produce the pair [M, Sg(S, M)]

Authenticable (can verify authenticity)/ non-repudiable:

R can verify that Sg(S,M) in [M, Sg(S, M)] comes from S

Only S could have produced M”+”Sg(S,M) Sg(S, M) is firmly attached to M

M

Sg(S, M)



Properties of Electronic Signatures (2)

Desirable properties for electr. signatures: Not alterable (assures „integrity”) :

Once sent, M”+”Sg(S,M) cannot beundetectably altered by S, R, or interceptor

[I’d rather consider this a part of „unforgeability” above]

Not reusable:If M is received again, S detects that M is „old”

E.g., can’t deposit a copy of a check to „double-deposit”

Digital signature is a protocol that mimics effect of signature on paper

M

Sg(S, M)



c. Using PKE for Digital Signatures (1)

Transmitting signed msgs with PKE Original message:

Privacy transformation: C = E(P, KPUB-R) Only R can decrypt it (with KPRIV-R)

Authenticity transformation = signing:Sg = Sg(S, C) = D(C, KPRIV-S)

Only S can produce Sg(S, C) (with KPRIV-S)

Sent message:

Note: Remember that for some PKE algorithms (incl RSA):D( E(M, _), _ ) = E( D(M, _), _ ) = M (commutativity of E-D)

C

Sg

P



Using PKE for Digital Signatures (2)

Transmitting signed msgs with PKE - cont. Received msg:

[ C = E(P, KPUB-R) ]

[Sg = Sg(S, C) = D(C, KPRIV-S)]

R verifies Sg with S’s public key KPUB-S:

If E( Sg, KPUB-S) = C, then signature is valid bec. E( Sg, KPUB-S) = E( D(C, KPRIV-S), KPUB-S) = C

R decodes C with R’s private key KPRIV-R:

P = D(C, KPRIV-R)

C

Sg



Using PKE for Digital Signatures (3) Properties:

[ C = E(P, KPUB-R) ]

[Sg = Sg(S, C) = D(C, KPRIV-S)]

Unforgeability:If C is forged,it will not „correspond” to Sg ( i.e., E( Sg, KPUB-S) ≠ C )

Authenticity:If Sg is valid, S is authenticated (only S can produce valid S’s signature)

Non-repudiation (undeniability):If Sg is valid, only S could have produced it, and have sent C”+”Sg

C

Sg



d. Using Hash Fcns for Digital Signatures

Using hash fcn H in digital signatures— signature over H(m), not over m length H(m) << length (m)

Before: Now:

[Fig — cf. J. Leiwo]

s = SgDA(x) = D(x, KPRIV-A)

EA(x) = E(x, KPUB-A)

Note:Any alteration of m is detected by B’s „Verify” step even if m is not encoded with KPUB-B —due to use of H(m)

m

Sg(S, H(m))

m

Sg(S, m)

m = P or m = C


2H.4. Certificates (1)

Outline a. Introduction b. Trust Through a Common Respected Individual c. Certificates for Identity Authentication d. Trust Without a Single Hierarchy


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


Certificates (3)

Introduction (2) Selected trust characteristics

Trust comes in degrees of trust Vs. binary trust (with a single trust threshold)

Ubiquity of trust in social and artificial systems Many users/computer systems err by trusting

blindly (trust without evidence or verification!) E.g., OS trusts all application pgms – any allowed to run E.g., sers trust unknown web sites with personal data


Certificates (4)

Introduction (3) Basic means of building trust toward person /

institution / artifact X Familiarity with X

Person: face, voice, handwriting, etc. Institution: company name, image, good will, etc Artifact: manufacturer name, perceived quality, etc

First-hand experience wih X’s activities/performance

Good or bad experience (trust or distrust grows)

Reputation of X determined by evidence / credentialsReputation = second-hand knowledge of X’s actions/perf.

Reputation databases (e.g., BBB, industry organizations, etc.) with „good” evidence or lack of „bad” evidence)

Credentials: X’s driver license, library card, credit card

Affiliation of X with person/institution/artifact Y Trust/distrust toward Y rubs off on X


Certificates (5)

Introduction (4) Basic means of verifying trust toward person / institution /

artifact X„Dovyeryay noh provyeryay” („Trust but verify”, a Russian proverb)

— Ronald Reagan (at the start of historic negotiations with Gornachev)

Verify one’s experience Check own notes about X’s activities/performance

Verify reputation evidence / credentials Call back to verify phone number Check user feedback about quality of artifact (online) Check reputation DB (e.g., consumer reports, BBB) for

data Verify affiliation

Check with employer if X still employed Check reputation of Y with which X is affiliated


Certificates (6)

Introduction (5) Often trust is based on appearance of authenticity,

without careful verification E.g., business order from Company A sent to

company B Order sent w/o careful verification of A by B Why?

Verification is expensive Trust prevails in business Risk of fraud or swindle is low B might be „insured” against being cheated

A trusted third-party intermediary assumes transaction risk

E.g., buyer’s bank guarantees a transaction payment

Appearance of authenticity can be used by fraudster


Certificates (7)

Introduction (6) Need similarly common and efficient/effective trust

mechanisms in the Cyber Space Need somebody or something to:

assume risksOR

vouch for the other party

A trusted third party is a basis for trust When two interacting parties do not trust each

other sufficiently


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


Trust Through Common Trusted Individual (2) Analogous approach for crypto key exchange Example

Ann and Andy want to comm-unicate

Ann gives KPUB-Ann to Bill Bill passes KPUB-Ann to Camilla

(or to Betty if he trusts her) Camilla passes KPUB-Ann to Betty Betty passes KPUB-Ann to Andy

Camilla is TTP (trusted third party)

Camilla

BettyBill

Ann Andy


Trust Through Common Trusted Individual (3) In reality need to pass more than just KPUB-Ann

Every sender attaches an evidence of identity Ann: Statement of Identity (SoI) Bill, Camilla Betty: Transmittal of Identity (ToI)

Andy receives KPUB-Ann with: Ann’s proof of identity Proof of identity for

all intermediaries Proof that each inter-

mediary received KPUB-Ann

from trusted sender E.g., Betty sends KPUB-Ann with the stmt:

„I am Betty and I received this key, SoI, and 2 ToIs from a person I know to be Camilla”

KPUB-Ann+SoI

KPUB-Ann+SoI+ToICamilla

BettyBill

Ann Andy

KPUB-Ann

+SoI +2 ToIs

KPUB-Ann

+SoI +3 ToIs


Trust Through Common Trusted Individual (4) In reality need to pass more than just KPUB-Ann – CONT.

Andy can verify chain of evidence (SoI + ToI’s) This assures Andy that key was sent by Ann and not

forged Public key authentication

(delivered by trusted people) Binding of key to Ann Trustworthy Ann’s

identification as senderof this key KPUB-Ann+SoI


BettyBill

Ann Andy

KPUB-Ann

+SoI +2 ToIs

KPUB-Ann

+SoI +3 ToIs


Trust Through Common Trusted Individual (5) Works pretty well within an org

There’s always sb common & trusted for any 2 employees (at the top or below)

Problems:1) If Bill, Camilla, or Betty

out of town, Ann &Andy have to wait forkey exchange

2) Person at the top workstoo hard to exchange allkeys quickly

KPUB-Ann+SoI


BettyBill

Ann Andy

KPUB-Ann

+SoI +2 ToIs

KPUB-Ann

+SoI +3 ToIs


Camilla

BettyBill

Ann Andy

Trust Through Common Trusted Individual (6) Protocol Solving Problem 1 (TTP absence):

Idea: preauthenticated public key for (single) future use

Ann asks Bill for complete chain from top down to her

Bill provides chain: <Camilla, Bill, Ann> Ann requests for TOIs for her SOI ahead of time Ann receives from Bill 2 TOIs:

TOI#637: “I, Bill, gave this TOI to Ann to confirm her identityfor SOI#27” + Bill’s signature

TOI#5492: “I, Camilla, gave this TOIto Bill to confirm his identity forTOI#637” + Camilla’s signature

Ann can use SOI+TOIs any time

Think about full scenarioHint: Andy prepares his SOI+TOIs ahead of time


Trust Through Common Trusted Individual (7) Protocol Solving Problem 2 (TTP’s heavy workload):

Idea: preauthenticated public key for unlimited future use

Top TTP (e.g., a CEO) sends his TOIs to all Division Mgr

“I, Sushil, company CEO, attest to the identity of the Auto Division Mgr Diana, and I entrust Diana with attesting identities of her subordinates.”

Each Division Mgr sends TOIs to all Dept Mgrs E.g., “I, Diana, Auto Division Mgr, attest to the identity of

the Engine Dept Mgr Debbie, and I entrust Debbie with attesting identities of her subordinates.”

Note: Division Mgr is a TTP for all people working in her Division

…<intermediate levels>...


Trust Through Common Trusted Individual (8)

Protocol Solving Problem 2 (TTP’s heavy workload):—CONT

…<intermediate levels>... Each Group Leader sends TOIs to all Task Leaders

E.g., “I, Camille, Piston Group Leader, attest to the identity of the Piston Rings Task Leader Bill, and I entrust Bill with attesting identities of his subordinates.”

Note: Group Leader is a TTP for all people working in her Group

Each Task Leader sends TOIs to all his employees E.g., “I, Bill, Piston Rings Task Leader, attest to the identity

of Piston Rings Engineer Ann.” Note: Task Leader is a TTP for all people working on his Task

Chain: Sushil—Diana—…—Camilla—Bill—Ann

Good exercise: Think about protocol details –work out full scenario


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


Certificates to Authenticate Identity (2) Creating certificates for the company example

Sushil (CEO) (chain: Sushil—Diana—…—Camilla—Bill—Ann)

Establishes <KPRIV-Sushil, KPUB-Sushil>

Posts KPUB-Sushil for every Division Mgr to copy

Receives request for certificate (encoded with KPUB-

Sushil )from Division Mgr X

Creates MX = <X, KPUB-X> (knows KPUB-X) E.g., MDiana = <‘Diana’, KPUB-Diana >

Signs MX with SgSushil

SgSushil= D(MX, KPRIV-Sushil)

‘Diana’

KPUB-Diana

‘Diana’

KPUB-Diana

SgSushil


Certificates to Authenticate Identity (3) Creating certificates ... example—CONT.

Sushil encrypts MX and SgSushil with KPRIV-Sushil,producing certificate for Div.Mgr X:

CertX = E(<MX, SgSushil>, KPRIV-Sushil) Note: Others can read certificate, but

only its issuer can update it! E.g., produces certificate for Diana:

CertDiana = E(<MDiana, SgSushil>, KPRIV-Sushil)

Sends certificate to Div. Mgr X

‘Diana’

KPUB-Diana

SgSushilCertDiana

(shading indicates encryption)

‘Diana’

KPUB-Diana

SgSushil


DIGRESSION—Note and understand these distinctions: Using asymmetric cryptosystems:

encrypt msg / sign msg / encrypt 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 certificate – after signing a (pre-)certificate, its 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 a certificate she issued!


Certificates to Authenticate Identity (4) Creating certificates ... example – CONT.

Diana (Div. Mgr) (chain: Sushil—Diana—…—Camilla—Bill—Ann)

Establishes <KPRIV-Diana, KPUB-Diana>

Posts KPUB-Diana for every subordinate to copy

Sends request for certificate to her boss (Sushil) — as mentioned above (request encoded with KPUB-Sushil)

Receives certificate from her boss CertDiana = E(<MDiana, SgSushil>, KPRIV-Sushil)

‘Diana’

KPUB-Diana

SgSushil



Diana receives request for certificate from Y, one of her Dept Mgrs

Creates MY = <Y, KPUB-Y> (knows KPUB-Y) E.g., MDebbie = <‘Debbie’, KPUB-Debbie>

Signs MY with SgDiana

Encrypts MY and signature with KPRIV-Diana,producing pre-certificate for Dept Mgr X:

preCertY = E(<MY, SgDiana>, KPRIV-

Diana)

E.g., produces pre-certificate for Debbie: preCertDebbie = E(<MDebbie,

SgDiana>, KPRIV-Diana)

‘Debbie’

SgDiana

KPUB-Debbie

preCertDebbie



Diana attaches to preCertY her owncertificate, producing certificate for Y:

CertY = preCertY || CertDiana

E.g., produces certificate for Debbie:

CertDebbie = preCertDebbie || CertDiana

Sends Y’s certificate to Y

... <procedure repetead by all mgrsfrom the chain below Diana and above Bill>...

‘Debbie’

SgDiana

KPUB-Debbie

‘Diana’

SgSushil

KPUB-Diana

‘Debbie’

SgDiana

KPUB-Debbie

CertDebbie

—incl. Debbie’s preCert (top half encr. with KPRIV-Diana) and Diana’s Cert (bootom half encr. with KPRIV-Sushil)

preCertDebbie



Bill (Task Leader) (chain: Sushil—Diana—…—Camilla—Bill—Ann)

Establishes <KPRIV-Bill, KPUB-Bill>

Posts KPUB-Bill for every subordinate to copy

Sends request for certificate to his boss (Camilla)

(request encoded with KPUB-

Camilla)

Receives certificate from his boss (Camilla) CertBill = E(<MBill, SgCamilla>, KPRIV-Camilla)

‘Bill’

KPUB-Bill

SgCamilla


Certificates to Authenticate Identity (8) Certificates for the company example – CONT.

Bill receives request for certificate from Z, one of his Engineers

Creates MZ = <Z, KPUB-Z> (knows KPUB-Z) E.g., MAnn = <‘Ann’, KPUB-Ann>

Signs MZ with SgBill

Encrypts MZ and signature with KPRIV-Bill,producing pre-certificate for Engineer Z:

preCertZ = E(<MZ, SgBill>, KPRIV-Bill)

E.g., produces pre-certificate for Ann:preCertAnn = E(<MAnn, SgBill>,

KPRIV-Bill)

‘Ann’

KPUB-Ann

SgBill

preCertAnn



Bill attaches his CertBill to preCertZ,producing certificate for Z:

CertZ = preCertZ || CertBill

Can become loooong!

CertBill = preCertBill || CertCamilla =preCertBill || preCertCamilla || Cert... = preCertBill || preCertCamilla || ... || CertDebbie = preCertBill || preCertCamilla || ... || preCertDebbie || CertDiana

(cont.)

‘Ann’

KPUB-Ann

SgBill

preCertAnn



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


Certificates to Authenticate Identity (11) 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)


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.

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”


Certificates to Authenticate Identity (13) 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”


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


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


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]


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!


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

End of: Introduction to Cryptology

Documents

CS 5950/6030 – Computer Security and Information Assurance Section 2: Introduction to Cryptology (Part 2) Dr. Leszek Lilien Department of Computer Science