E-MAIL SECURITY – Chapter 15E-MAIL SECURITY – Chapter 15

….for authentication and confidentiality

PGP1.Uses best algorithms as building blocks2.General purpose3.Package/source code free4.Low-cost commercial version5.No government

PGP CRYPTOGRAPHIC FUNCTIONS

F igur e 15.1 P G P C r yptogr aphic F unctions

M

(c) C onfidentiality and authentication

H

M

H

DP

Compare

K U a

| |

KR a

E P Z

EP

K U b

| |EC

K s

D C

D P

KR b

Z -1

M

(b) C onfidentiality only

DP

K R b

DCM

E P

KU b

E C | |

K s

Z Z -1

H||

K Ra

E PM

(a) A uthentication only

Z Z -1

H

D P

C ompare

K U a

M

E K R a[H (M )]Sour ce A D estination B

E K U b[K s]

E K R a[H (M )]

E K U b[K s]

PGP for…….PGP for…….

Authentication

Confidentiality

Compression

e-mail

Segmentation

DIGITAL SIGNATURES (fig 15.1a)DIGITAL SIGNATURES (fig 15.1a)

SHA-1 with RSA Signature

(RSA, KUa) KRa

(H, KRa) Signed

(alternative – DSS/SHA-1)

DETACHEDDETACHED SIGNATURESSIGNATURES instead of….. Attached Signatures use…..

Detached Signatures - Separate Transmission - separate log detect virus many signatures – one doc

CONFIDENTIALITY (fig 15.1b)CONFIDENTIALITY (fig 15.1b)

CAST or IDEA or 3DES : CFB – 64

Key Distribution: RSA/Diffie-Hellman/El Gamal

Symmetric Key used once/message

Random 128-bit key, Ks

: key sent with message

SYMMETRIC/PUBLIC COMBINATIONSYMMETRIC/PUBLIC COMBINATION

• Faster than just PUBLIC• PUBLIC solves key distribution• No protocol – one-time message• No handshaking• One-time keys strengthen security

(weakest link is public)

CONFIDENTIALITY and CONFIDENTIALITY and AUTHENTICATION (fig 15.c)AUTHENTICATION (fig 15.c)

Authentication - plaintext mess. stored third-party can verify signature without needing to know secret key Compression

Confidentiality

COMPRESSION - why?COMPRESSION - why?

Benefit - efficiency Why, Signature then Compression then Confidentiality ?• Sign Uncompressed Message - off-line storage• No need for single compression algorithm• Encryption after compression is stronger

E-Mail COMPATIBILITYE-Mail COMPATIBILITY

e-mail uses ASCII PGP(8-bit) ASCII

Base-64: 3x8 4 x ASCII + CRC

33% Expansion !! (fig 15.2)

RADIX-64 FORMAT24 bits

R 64 R 64 R 64 R 64

4 characters = 32 bits

F igur e 15.11 P r intable E ncoding of B inary Data into R adix-64 F ormat

Tx and Rx of PGP MessagesX ¬ file

C onfidentialityrequired?

encrypt key, X

Y es

convert to radix 64X ¬ R 64[X]

(a) Generic T ransmission D iagram (from A ) (b) Generic R eception D iagram (to B )

F igur e 15.2 T r ansmission and R eception of P G P M essages

N o

C onfidentialityrequired?

decrypt key, X

Y es

N o

convert from radix 64X ¬ R 64Ð1[X]

C ompressX ¬ Z(X )

S ignaturerequired?

generate signatureX ¬ signature || X

Y es

N o

D ecompressX ¬ Z Ð1(X )

S ignaturerequired?

strip signature from Xverify signature

Y es

N o

X ¬ E K U b[K s] || E K s[X ]

K ¬ D K R b[E K U b[K s]]X ¬ D K [X]

SEGMENTATION / REASSEMBLYSEGMENTATION / REASSEMBLY

Max length restriction e.g. internet = 50,000 x 8-bits

PGP Segments automatically but,One session key,signature/message

PGP KEYSPGP KEYS

1. one-time session : use random number gen.2. public3. private4. passphrase-based

} multiple pairskey idfile of key pairs for all users

SESSION-KEY GENERATIONSESSION-KEY GENERATIONCAST / IDEA / 3DES in CFB mode

}New Session Key

64 64

6464

128

plaintext - user key strokes

K K – user key strokes and old session key

KEY IDENTIFIERSKEY IDENTIFIERSWhich public key?

each public key has key ID (least 64 bits)

With high prob., no key ID collision

MESSAGE FORMAT (fig 15.3)MESSAGE FORMAT (fig 15.3)

Message,m [data, filename, timestamp]

signature (optional) includes digest = hash(m(data)||T) therefore signature is:[T, EKRa

(digest),2x8(digest), KeyID]

session key (optional) [key, IDKUb]

MESSAGE FORMATC ontent

Session keycomponent

Signatur e

M essage

L eading two octetsof message digest

K ey ID of sender'spublic key (KU a)

K ey ID of recipient'spublic key (KU b)

Session key (K s)

T imestamp

M essage Digest

Filename

T imestamp

Data

O per ation

E K U b

N otation :E K U b

= encryption w ith user b's public keyE K Ra

= encryption w ith user a's private keyE K s

= encryption w ith session keyZIP = Z ip compression functionR 64 = R adix-64 conversion function

F igur e 15.3 G ener al F or mat of P G P M essage (from A to B )

Z I P

R 64E K R a

E K s

KEY RINGS (fig 15.4)KEY RINGS (fig 15.4)

Private Key Ring store public/private pairs of node A

Public Key Ring store public keys of all other nodes

KEY RINGSPrivate Key Ring

Timestamp K e y ID * Public Key EncryptedPrivate Key

User ID*

¥¥¥

¥¥¥

¥¥¥

¥¥¥

¥¥¥

T i KU i mod 2 64 KU i E H (Pi )[KR i] U ser i¥¥¥

¥¥¥

¥¥¥

¥¥¥

¥¥¥

Public Key Ring

Timestamp K e y ID * Public Key Owner Trust User ID* KeyLegitimacy

S ignature(s) S ignatureTrust(s)

¥¥¥

¥¥¥

¥¥¥

¥¥¥

¥¥¥

¥¥¥

¥¥¥

¥¥¥

T i KU i mod 2 64 K u i trust_ flag i U ser i trust_ flag i

¥¥¥

¥¥¥

¥¥¥

¥¥¥

¥¥¥

¥¥¥

¥¥¥

¥¥¥

* = field used to index table

F igure 15.4 G eneral Structure of P rivate and P ublic Key R ings

ENCRYPTED PRIVATE KEYS ENCRYPTED PRIVATE KEYS on PRIVATE KEY-RINGon PRIVATE KEY-RING

1.User passphrase2.System asks user for passphrase3.Passphrase 160-bit hash4.Ehash(private key)

subsequent access requires passphrase

PGP MESSAGE GENERATION

P rivate key ring

select encryptedprivate key

D C

M essageM

K ey ID

message

ID A

H

messagedigest

EP | |

private keyK R a

EC

R NG

session keyK s

signature+ message

E P

Public key ring

ID Bselect

public keyKU b

| |

encryptedsignature

+ message

K ey ID

Output

F igur e 15.5 P G P M essage G eneration (from U ser A to U ser B ; no compr ession or radix 64 conversion)

Hpassphrase

PGP MESSAGE RECEPTION

F igur e 15.6 P G P M essage R eception (from U ser A to U ser B ; no compr ession or radix 64 conversion)

Public key ring

H

private keyK Rb

select

passphrase

Private key ring

select encryptedprivate key

DC

encryptedmessage +signature

E ncryptedsession key

receiver'sK ey ID D P

session keyK s

DC

E ncrypteddigest

sender'sK ey ID

messageCompare

H

public keyK U a

D P

PUBLIC KEY MANAGEMENTPUBLIC KEY MANAGEMENT

Problem: need tamper-resistant public-keys (e.g. in case A thinks KUc is KUb)

Two threats: C A (forge B’s signature) A B (decrypt by C)

solution: Key-Revoking

PGP TRUST MODEL EXAMPLEY ou

A B C D E F

G H I J K L M N O

P Q R

S? ?

??

?

?

?

?X Y = X is signed by Y

= key's owner is trusted by you to sign keys

= key's owner is par tly trusted by you to sign keys

= key is deemed legitimate by you

= unknown signator y

F igur e 15.7 P G P T r ust M odel E xample

ZIPZIP

freeware (c) : UNIX, PKZIP : Windows

LZ77 (Ziv,Lempel)

Repetitions short code (on the

fly)

codes re-used

algorithm MUST be reversible

ZIP (example)ZIP (example)(Fig 15.9) char 9 bits = 1 bit + 8-bit ascii look for repeated sequences continue until repetition endse.g. the brown fox 8-bit pointer, 4-bit length, 00 12-bit pointer, 6-bit length, 01 then ’ jump’ ptr + length, ind compressed to 35x9-bit + two codes = 343 bits Compression Ratio = 424/343 = 1.24

ZIP (example)

t he br own f ox j ump ed ov er t he br own f ox y j ump i ng f r og13 5

27 26

t he br own f ox j ump ed ov er y i ng f r og0b26 d13d 0b27d5d

F igur e 15.9 E xample of L Z 77 Scheme

COMPRESSION ALGORITHMCOMPRESSION ALGORITHM1.Sliding History Buffer – last N chars2.Look-Ahead Buffer – next N chars

Algorithm tries to match chars from 2. to 1. if no match, 9 bits LAB 9 bits SHB else if match found output: indicator for length K string, ptr, length K bits LAB K bits SHB

COMPRESSION ALGORITHM

Sliding H istor y Buffer L ook -A head

B uffer

he br own f ox j umped ov er t he br own f ox y

(a) General structure

Discard

Shiftsource text

Source

O utputcompressed text

(b) Example

F igur e 15.10 L Z 77 Scheme

j umpi ng f r og

own f ox j umped ov er t he br own f ox y j ump i ng f r og

PGP RANDOM NUMBER GENERATION

E

E

E

dtbuf

E

E

E

E

rseed

rbuf

rseed

rbuf rbuf

rseed rseed

K [16..23] K [8..15] K [0..7]

F igur e 15.12 P G P Session K ey and I V G ener ation (steps G 2 thr ough G 8)

S/MIMES/MIME

(Secure/Multipurpose Mail Extension)S/MIME - commercialPGP - privateS/MIME - based on MIME (designed for RFC822)

RFC822 - traditional text-mail internet standard Envelope + Contents

CRYPTO ALGORITHMSCRYPTO ALGORITHMS USED in S/MIME USED in S/MIME

(Table 15.6)Sender/Recipients must agree on common encryption algorithm

S/MIME secures MIME entity with signature and/or encryption

MIME entity entire message subpart of message

SECURING a MIME ENTITYSECURING a MIME ENTITY

MIME

ENTITY

MIMEPREPARE S/MIME

WRAPPED in MIME

PKCS OBJECT

security data

S/MIME CERTIFICATE PROCESSINGS/MIME CERTIFICATE PROCESSING

Hybrid of X.509 certification authority and PGP’s ”web of trust”

Configure each client Trusted Keys Certification Revocation List