Digital Certificates, Email Security

CEN585 – Computer and Network Security
Digital Certificates,
Email Security
Dr. Mostafa Hassan Dahshan
Computer Engineering Department
College of Computer and Information Sciences
King Saud University
[email protected]
http://faculty.ksu.edu.sa/mdahshan
Digital Certificates
2
Public-Key Certificates

Certificate contains



Certificate encrypted using PRauth



public key of certificate holder
ID of certificate holder
serves as a trusted signature
Users can verify certificate using PUauth
Certificate authority

government agency or financial institution
3
Digital Certificates

Participant A applies to auth for certificate



Authority provides certificate



supplies PUA and request certificate
in person or by secure communication
CA = E (PRauth, [T||IDA||PUA])
A may pass this certificate to others (B)
B can verify certificate

D(PUauth, CA) = (T||IDA||PUA)
4
Digital Certificates



Timestamp serves as expiration date
Sufficiently old certificate assumed expired
If PR is compromised




A applies for new certificate
still at risk until other communicants are aware
X.509 is universally accepted standard for
certificate format
Used in IPSec, SSL, S/MIME
5
Digital Certificates
6
X.509 Certificates




ITU-T recommendation
Part of X.500 series for directory service
Framework for provision of authentication
service to X.500 directory users
Directory


server(s) maintain database of user
information
information: mapping username to net address
7
X.509 Certificates




Heart of X.509
Public-key certificate associated with user
Assumed created by trusted CA
Placed in directory server


provides easily accessible location
not responsible for creating PK or cert function
8
X.509 Certificates

Based on PK crypto and digital signatures


PK: no specific algorithm, recommends RSA
digital signature



requires using hash function
no specific hash algorithm
Used in S/MIME, IPSec and SSL/TLS
9
Certificate
Format
10
Certificate Format

Issuer name


Subject name


name of user to whom certificates refers
Subject’s public-key information


name of CA created and signed this certificate
public-key of subject + algorithm id +
parameters
Signature

hash code of other fields, encrypted with CA PR
11
Notation


CA <<A>> = CA {V, SN, AI, CA,TA, A, Ap}
Y <<X>>


certificate of user X issued by cert auth Y
Y {I}


signing of I by Y
consists of I with encrypted hash code
appended
12
Obtaining User’s Certificate



Any user having PU of CA can verify cert
No one other than CA can modify cert
without this being detected
If both users (A, B) are with same CA


A can directly use CA PU to verify cert
If A with CA X1, B with CA X2


A obtains cert of X2 signed by X1, get PU of X2
A obtains cert of B signed by X2, get PU of B
13
Obtaining User’s Certificate

A obtain B’s PU


B obtain A’s PU


X1 <<X2>> X2 <<B>>
X2 <<X1>> X1 <<A>>
If N CA’s in the path

X1 <<X2>> X2 <<X3>> … XN <<B>>
14
Obtaining User’s Certificate
A get PU of B
X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>>
B get PU of A
Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>
Forward certificate
Reverse certificate
15
Revocation of Certificates

Reasons




CA maintains certificate revocation list
(CRL)


PR of user is compromised
user is no longer certified
CA’s certificate is compromised
CRL posted to directory
User must check if cert is revoked

cache can be used to avoid delays
16
Revocation of Certificates
17
Email Security


Pretty Good Privacy (PGP)
S/MIME
18
Pretty Good Privacy





Provides confidentiality, authentication
Can be used for email, file storage
Combines best cryptographic algorithms
Integrated into general-purpose application
Platform independent, simple commands
19
Reasons for PGP Popularity





Available for free, multi platforms
Based on known secure algorithms
Wide range of users: corps to individuals
Not controlled by govt. or std. organization
On Internet standards track (RFC 3156)
20
PGP Operation





Authentication
Cryptographic functions
Confidentiality
Compression
E-mail compatibility
Segmentation
21
PGP Operation
22
Terminology








EP = public-key encryption
DP = public-key decryption
EC = symmetric encryption
DC = symmetric decryption
Ks = session key used in symmetric crypt
H = hash function
Z = compression using ZIP algorithm
R64 = conversion using radix 64 ASCII
23
PGP Operation
24
Authentication (Message)



Sender creates message
SHA-1 used to generate 160-bit hash
Hash encrypted with RSA, sender’s PR



result prepended to message
Receiver decrypts with RSA, sender’s PU
Receiver generates hash from message


compare with decrypted hash
match: message accepted as authentic
25
Confidentiality

Sender generates message + 128-bit key


Message encrypted (symmetric, using Ks)



CAST-128, IDEA, 3DES
Ks encrypted with RSA, recipient’s PU


key only used once: session key (Ks)
prepended to message
Receiver decrypts Ks with RSA, PR
Receiver decrypts message with Ks
26
Notes


Combining symmetric, PK encryption is
faster than using PK for whole message
Using PK solves key distribution problem





Ks used for one message only
no need for key distribution protocol
handshaking unsuitable for email exchange
Using one Ks per message  strong crypt
Security depends on strength of PK crypt
27
Confidentiality & Authentication




Signature generated, prepended to message
Message+sig encrypted with symmetric
crypt
Ks encrypted with RSA (or ElGamal)
Sign then crypt better than crypt then sign


signature stored with plaintext message
third-party verification no need Ks, EC
28
Compression



Compression after sig, before encryption
Save space: email sending or file storage
Signature before compression




uncompressed message stored with signature
simpler verification
better interoperability
Compression before encryption


strengthens crypto security
less redundancy, harder cryptanalysis
29
E-mail Compatibility




PGP always has encrypted part
Arbitrary binary 8-bit octets
Email can only transmit printable ASCII
Radix64




convert binary to ASCII, append CRC code
each 3 octets mapped to 4 ASCII characters
size expanded by 33%
compression compensates for expansion
30
Segmentation & Reassembly

Email facilities restrict message length





50,000 octet limit typical on the Internet
PGP divides large messages into segments
Segmentation done after all processing
Each segment sent with its own header
Segments reassembled at receiver’s end
31
32
S/MIME



Secure Multipurpose Internet Mail
Extension
Security enhancement to MIME
More likely to become industry standard


PGP more used for personal email security
Before covering S/MIME, background on


Text message format (RFC 822)
Multipurpose Internet Mail Extension (MIME)
33
RFC 822






Format for text messages sent using email
Message viewed as envelope, contents
Envelope contains information needed for
transmission and delivery
Contents include header and body
Header separated from body by blank line
Header format “Keyword: arguments”

“From:”, “To:”, “Subject:”, “Date:”
34
RFC 822 – Example
Date: Wed, 31 Dec 2008 10:37:17 (CST)
From: “Ahmed Mohammad" <[email protected]>
Subject: The Syntax in RFC 822
To: [email protected]
Cc: [email protected]
Hello. This section begins the actual
message body, which is delimited from the
message heading by a blank line.
35
MIME


Extension to RFC 822
Address limitations in SMTP, RFC 822






cannot transmit binary files
cannot transmit text of some languages
may reject mail over certain size
character code translation problems
non-standard SMTP implementations
MIME specification: RFCs 2045 – 2049
36
MIME

Adds five new message header fields
• MIME Version
• Content-Type
• Content-ID
• Content-Description
• Content-Transfer Encoding

Defines number of content formats


support multimedia and other types
Transfer encodings defined

for content format conversion
37
MIME Header Fields

MIME-Version


Content-Type


how data is represented: e.g. base64, radix64
Content-ID


info for user agent to display content properly
Content-Transfer-Encoding


must be 1.0 to conform to RFC 2045, 2046
identify MIME entities uniquely
Content-Description

text description of object, useful if object unreadable
38
39
MIME Types and Subtypes
40
MIME Transfer Encodings
41
S/MIME Functions

Enveloped data


encrypted content of any type and encrypted
session keys
Signed data



digital sig: hash encrypted with signer’s PR
content + signature encoded with base64
can only be viewed with S/MIME capable client
42
S/MIME Functions

Clear-signed data



only digital signature is encoded as base64
recipients without S/MIME capability can read
message but cannot verify signature
Signed and enveloped data



singed-only, encrypted-only can be nested
encrypted data can be signed
signed data, clear-signed data can be encrypted
43
S/MIME Cryptographic Algorithms
44
S/MIME Content Types
45
Examples
Content-Type: application/pkcs7-mime; smime-type=envelopeddata; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
rfvbnj75.6tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V
Content-Type: application/pkcs7-mime; smime-type=signeddata; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75
46
Examples
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
boundary42
Content-Type: text/plain
This is a clear-signed message.
boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
boundary42
47
S/MIME Certificate Processing



S/MIME uses X.509 v3 certificate format
Key management hybrid X.509, PGP
S/MIME users must configure clients with



list of trusted keys
certificate revocation lists
Certificates are signed by certificate
authorities
48
User Agent Role

Key generation



Registration


generate Diffie-Hellman and DSS key pairs
generate RSA key pairs
PU of user must be registered with CA so that
user can receive X.509 certificate
Certificate storage and retrieval

certificate list must be maintained locally
49
References

Cryptography and Network Security, 5E



Chapter 14: 14.4
Chapter 18: 18.1, 18.2
Computer Networks, 5E

Chapter 7: 7.2.3
50