Transcript Chapter 1

E-MAIL SECURITY – Chapter 15
….for authentication and confidentiality
PGP
1.Uses best algorithms as building blocks
2.General purpose
3.Package/source code free
4.Low-cost commercial version
5.No government
PGP CRYPTOGRAPHIC FUNCTIONS
Sour ce A
Destination B
EKRa[H(M)]
KUa
KRa
H
M
||
EP
Z
DP
Z-1
M
Compare
EKUb[Ks]
(a) Authentication only
Ks
M
Z
EC
H
KU b
KRb
EP
DP
DC
||
(b) Confidentiality only
KU b
EKUb[Ks]
KRb
KRa
M
Ks
EKRa[H(M)]
KUa
EP
DP
H
EP
||
Z
EC
M
Z-1
DP
||
DC
Z-1
M
Compare
H
(c) Confidentiality and authentication
Figur e 15.1 PGP Cr yptogr aphic Functions
PGP for…….
Authentication
Confidentiality
Compression
e-mail
Segmentation
DIGITAL SIGNATURES (fig 15.1a)
SHA-1 with RSA  Signature
(RSA, KUa)
 KRa
(H, KRa)
 Signed
(alternative – DSS/SHA-1)
DETACHED SIGNATURES
instead of…..
Attached Signatures
use…..
Detached Signatures
- Separate Transmission
- separate log
detect virus
many signatures – one doc
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 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
AUTHENTICATION (fig 15.c)
Authentication - plaintext mess. stored
third-party can verify signature without
needing to know secret key
Compression
Confidentiality
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 COMPATIBILITY
e-mail uses ASCII
PGP(8-bit)  ASCII
Base-64: 3x8  4 x ASCII + CRC
33% Expansion !!
(fig 15.2)
RADIX-64 FORMAT
24 bits
R64
R64
R64
R64
4 characters = 32 bits
Figure 15.11 Printable Encoding of Binary Data into Radix-64 Format
Tx and Rx of PGP Messages
X ¬ file
Signature
required?
convert from radix 64
X ¬ R64Ð1[X]
Yes
generate signature
X ¬ signature || X
No
No
Compress
X ¬ Z(X)
Confidentiality
required?
Confidentiality
required?
Yes
decrypt key, X
K ¬ D KRb[EKUb[K s]]
X ¬ DK[X]
Decompress
X ¬ ZÐ1(X)
Yes
encrypt key, X
X ¬ EKU b[K s] || EKs[ X]
No
Signature
required?
Yes
strip signature from X
verify signature
No
convert to radix 64
X ¬ R64[X]
(a) Generic Transmission Diagram (from A)
(b) Generic Reception Diagram (to B)
Figur e 15.2 Tr ansmission and Reception of PGP Messages
SEGMENTATION / REASSEMBLY
Max length restriction
e.g. internet = 50,000 x 8-bits
PGP Segments automatically
but,
One session key,signature/message
PGP KEYS
1. one-time session :
use random number gen.
key id
2. public
file of key pairs
multiple pairs
for all users
3. private
4. passphrase-based
}
SESSION-KEY GENERATION
CAST / IDEA / 3DES in CFB mode
64
64
K
plaintext
- user key strokes
K – user key strokes
and old session key
128
}
64
64
New Session Key
KEY IDENTIFIERS
Which public key?
each public key has key ID
(least 64 bits)
With high prob., no key ID collision
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]
Content
Session key
component
MESSAGE FORMAT
Oper ation
Key ID of recipient's
public key (KU b)
Session key (K
s)
EKU b
Timestamp
Signatur e
Key ID of sender's
public key (KU a)
Leading two octets
of message digest
Message Digest
EKRa
R64
Filename
Timestamp
ZI P
E Ks
M essage
Data
Notation:
EKUb =
EKRa =
EKs
=
ZIP
=
R64
=
encryption with user b's public key
encryption with user a's private key
encryption with session key
Zip compression function
Radix-64 conversion function
Fi gur e 15.3 Gener al For mat of PGP M essage (fr om A to B)
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 RINGS
Private Key Ring
Timestamp
Key ID*
Public Key
¥
¥
¥
Ti
¥
¥
¥
¥
¥
¥
KUi mod 2 64
¥
¥
¥
¥
¥
¥
KUi
¥
¥
¥
Encrypted
Private Key
¥
¥
¥
EH(Pi)[KRi ]
¥
¥
¥
User ID*
¥
¥
¥
User i
¥
¥
¥
Public Key Ring
Timestamp
Key ID*
Public Key
Owner Trust
User ID*
¥
¥
¥
Ti
¥
¥
¥
¥
¥
¥
KUi mod 2 64
¥
¥
¥
¥
¥
¥
Kui
¥
¥
¥
¥
¥
¥
trust_flag
¥
¥
¥
¥
¥
¥
User i
¥
¥
¥
i
Key
Legitimacy
¥
¥
¥
trust_flag i
¥
¥
¥
* = field used to index table
Figure 15.4 General Structure of Private and Public Key Rings
¥
¥
¥
Signature
Trust(s)
¥
¥
¥
¥
¥
¥
¥
¥
¥
Signature(s)
ENCRYPTED PRIVATE KEYS
on PRIVATE KEY-RING
1.User passphrase
2.System asks user for passphrase
3.Passphrase  160-bit hash
4.Ehash(private key)
subsequent access requires passphrase
PGP MESSAGE GENERATION
Public key ring
H
passphrase
ID B
select
Private key ring
ID A
select
Key ID
encrypted
private key
DC
Key ID
public key
KU b
private key
KRa
RNG
message
digest
H
Message
M
EP
message
||
session key
Ks
EP
signature
+ message
EC
||
Output
encrypted
signature
+ message
Figur e 15.5 PGP Message Generation (from User A to User B; no compr ession or radix 64 conversion)
PGP MESSAGE RECEPTION
passphrase
H
Private key ring
select
Public key ring
encrypted
private key
select
DC
private key
KRb
receiver's
Key ID
Encrypted
session key
encrypted
message +
signature
public key
KUa
DP
session key
Ks
sender's
Key ID
Encrypted
digest
DP
DC
Compare
message
H
Figur e 15.6 PGP Message Reception (from User A to User B; no compr ession or radix 64 conversion)
PUBLIC 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 EXAMPLE
You
A
B
C
D
E
?
F
?
G
H
?
I
J
K
L
M
N
O
?
P
X
?
= unknown signator y
Y
= X is signed by Y
Q
R
?
= 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
Figur e 15.7 PGP Tr ust Model Example
S
?
?
ZIP
freeware (c) : UNIX, PKZIP : Windows
LZ77 (Ziv,Lempel)
Repetitions  short code (on the fly)
codes re-used
algorithm MUST be reversible
ZIP (example)
(Fig 15.9)
char  9 bits = 1 bit + 8-bit ascii
look for repeated sequences
continue until repetition ends
e.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 umped over t he br own f oxy j umpi ng f r og
13
5
26
27
t he br own f ox j umped over
0b26d13d
y
Figure 15.9 Example of LZ77 Scheme
0bi27ng
d5d
f r og
COMPRESSION ALGORITHM
1.Sliding History Buffer – last N chars
2.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
Shift
source text
Discard
L ook-Ahead
Buffer
Sliding Histor y Buffer
Output
compressed text
(a) General structure
he br own f ox j umped over t he br own f oxy
own f ox j umped over t he br own f oxy j ump
(b) Example
Figur e 15.10 LZ77 Scheme
j umpi ng f r og
i ng f r og
Source
PGP RANDOM NUMBER GENERATION
dtbuf
E
E
rseed
E
rseed
E
E
rbuf
K[16..23]
rseed
E
E
rbuf
K[8..15]
rbuf
K[0..7]
Figure 15.12 PGP Session Key and IV Generation (steps G2 through G8)
rseed
S/MIME
(Secure/Multipurpose Mail Extension)
S/MIME - commercial
PGP
- private
S/MIME - based on MIME
(designed for RFC822)
RFC822 - traditional text-mail
internet standard
Envelope + Contents
CRYPTO ALGORITHMS
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 ENTITY
security
data
MIME
ENTITY
MIME
PREPARE
S/MIME
PKCS OBJECT
WRAPPED
in
MIME
S/MIME CERTIFICATE PROCESSING
Hybrid of X.509 certification authority
and PGP’s ”web of trust”
Configure each client
 Trusted Keys
Certification Revocation List