E-mail Security

PGP, S/MIME
Certificates and PKI
E-mail Security
E-mail is one of the most widely used
network services
killer application of the Internet
Normally message contents not secured
Can be read/modified either in transit or at
destination by the attacker
E-mail service is like postcard service
just pick it and read it
Email Security Enhancements
confidentiality
protection from disclosure
authentication
of sender of message
message integrity
protection from modification
non-repudiation of origin
protection from denial by sender
Pretty Good Privacy (PGP)
widely used secure e-mail software
originally a file encryption/decryption facility
developed by Phil Zimmermann
a security activist who has had legal problems due to
PGP
best available crypto algorithms are employed
available on several platforms with source code
originally free, now commercial versions exist
not controlled by a standardization body
although there are RFCs
PGP Mechanisms
Digital Signatures (and consequently
message authentication and integrity)
RSA, DSS
Message Encryption
CAST, IDEA, 3DES, AES (all at least 128 bits)
symmetric keys are used once and encrypted
using RSA or ElGamal (based on discrete logs)
Compression using ZIP
Radix-64 conversion (to ASCII)
for e-mail compatibility
PGP Operation Digital
Signatures
Classical application of public key crypto
This figure is actually for RSA
for DSA refer to previous lectures
Z is zip function
radix-64 conversion is done after zip at sender,
before Z
-1
at receiver
may be done only for signature or for the whole message
PGP Operation Confidentiality
One-time session key, K
s
generated at random
encrypted using a public key cryptosystem, EP
RSA or ElGamal
Message is compressed before encryption
This is the default case
E[PU
b
, K
s
]
PGP Operation Confidentiality
and Authentication
uses both services on same message
create signature and attach to message
compress and encrypt both message & signature
attach encrypted session key
radix-64 conversion is for everything at the end
PGP Operation radix-64 conversion
Encrypted text and signatures create binary output
however email was designed only for text
hence PGP must encode raw binary data into
printable ASCII characters
uses radix-64 algorithm (See appendix 18A)
maps 3 bytes to 4 printable chars
PGP Operation Summary
PGP Key ID concept
since a user may have many public/private
keys in use, there is a need to identify which is
actually used to encrypt session key in a
message
PGP uses a key identifier which is least significant
64-bits of the public key
uniqueness?
very likely, at least for a particular user ID (e-mail address)
Key IDs are used in signatures too
key ID for the public key corresponding to the
private key used for signature
Key IDs are sent together with messages
PGP Key Rings
each PGP user has a pair of keyrings to
store public and private keys
public-key ring contains all the public-keys
of other PGP users known to this user
PGP Key Rings
private-key ring contains the
public/private key pair(s) for this user,
private keys are encrypted using a key
derived from a hashed passphrase
Key rings and message generation

Key rings and message reception

PGP Key Management - 1
From PGP documentation:
This whole business of protecting public keys from
tampering is the most difficult problem in practical
public key applications
You have to make sure about the legitimacy
of the public key of your party
exchange public-keys manually (using CDs, USB
sticks, etc.)
verify fingerprint of a public key over the phone
trust another individual who signs public keys
public key signatures
PGP Key Management - 2
Public keys could be signed by
Certification Authorities (CA)
trusted entities
the mechanism of S/MIME, not in PGP
in PGP each user is a CA
everybody can sign keys of users they know directly
other users key signatures can also be used, if those users are
trusted
The only ultimately trusted entity is yourself
all other keys should either be directly signed by you or
there should be a trusted path of key signatures
you reflect your own trust assessment in your public key
ring (no system enforcement)
key ring includes trust indicators
web of trust
PGP Key Management - 3
A trusted signature on a public key means that
the key really belongs to its owner
But does not mean that key owner is trusted to
sign other keys
key owner can sign other keys, but their
trustworthiness is determined by the verifier (the
owner of the pubkey ring)
Making sure about the legitimacy of a key and
trusting the key owner to find out other keys
are two different concepts
Keys and signatures on them are generally
obtained from PGP public keyservers
there might be several signatures on a single key
PGP Key Management - 4
A public
key ring
owned by
you

This is calculated
These are
assigned by
you
S/MIME
Secure/Multipurpose Internet Mail Extensions
A standard way for email encryption and
signing
IETF effort (RFCs 2632, 2633 for version
3.0; RFCs 3850, 3851 for version 3.1; 5750,
5751 for version 3.2)
Industry support
Not a standalone software, a system that is to
be supported by email clients
such as MS Outlook and Thunderbird
S/MIME handles digital signatures
Also provides encryption
Quick E-mail History
SMTP and RFC 822
only ASCII messages (7-bit)
MIME (Multipurpose Internet Mail Extensions)
content type
Almost any of information can appear in an email
message
transfer encoding
specifies how the message body is encoded into textual
form (radix64 is common)
S/MIME: Secure MIME
new content types, like signature, encrypted data
S/MIME Functions
enveloped data
encrypted content and associated keys
signed data
encoded message + encoded signed message
digest
clear-signed data
cleartext message + encoded signed message
digest
signed and enveloped data
Nested signed and encrypted entities
S/MIME Cryptographic Algorithms
hash functions: SHA-1 & MD5
digital signatures: DSS & RSA
session key encryption: ElGamal & RSA
message encryption: Triple-DES, AES and
others
sender should know the capabilities of the
receiving entity (public announcement or
previously received messages from receiver)
otherwise sender takes a risk
Scope of S/MIME Security
S/MIME secures a MIME entity
a MIME entity is entire message except the
headers
so the header is not secured
First MIME message is prepared
This message and other security related data
(algorithm identifiers, certificates, etc.) are
processed by S/MIME
and packed as one of the S/MIME content
type
S/MIME Content Types

EnvelopedData
For message encryption
Similar to PGP
create a random session key, encrypt the
message with that key and a conventional crypto,
encrypt the session key with recipients public key
Unlike PGP, recipients public key comes
from an X.509 certificate
trust management is different
SignedData
For signed message
both message and signature are encoded so that
the recipient only sees some ASCII characters if he
does not use an email client with S/MIME support
Similar to PGP
first message is hashed, then the hash is encrypted
using senders private key
Message, signature, identifiers of algorithms
and the senders certificate are packed
together
again difference between S/MIME and PGP in trust
management
Clear Signing
Another mechanism for signature
but the message is not encoded, so an email
client with no S/MIME support could also
view the message
of course the signature will not be verified and
will be seen as a meaningless attachment
multipart/signed content type
2 parts
Clear text message
Signature
Lets see an example

S/MIME Certificate Processing
S/MIME uses X.509 v3 certificates
Certification Authorities (CAs) issue certificates
unlike PGP, a user cannot be a CA
each client has a list of trusted CA certificates
actually that list comes with e-mail client software
or OS
and own public/private key pairs and certs
Our textbook says S/MIME key management
is a hybrid of a strict X.509 CA hierarchy and
PGPs web of trust
but I do not believe that this is the case, because it
is very hard for an average user to maintain the list
of trusted CAs
S/MIME Certificate Processing
and CAs
One should obtain a certificate from a CA in order to
send signed messages
Certificates classes (common practice by most CAs)
Class 1
Class 2
Class 3
CA certification policies (Certificate Practice
Statement)
ID-control practices
Class 1: only email address check
Class 2: class1 + against third party database / fax documents
Class 3: class1 + apply in person and submit picture IDs and/or
paper documents
Stronger
identity
validation
Easier to
issue
X.509 Certificates and PKIs
SSL and S/MIME uses X.509
certificates
now we will see the details of them
later we will continue with PKIs (Public Key
Infrastructures)

Certificates
Yet another public-key distribution
method
first (conceptually) offered by Kohnfelder
(1978)
Binding between the public-key and its
owner
Issued (digitally signed) by the
Certificate Authority (CA)

Certificates
Certificates
Certificates are verified by the verifiers
to find out correct public key of the
target entity
Certificate verification is the verification
of the signature on certificate
In order to verify a certificate, the verifier
must know the public key of the CA
must trust the CA
Certificates
Certified Entity
CA
Verifier
Albert
Levi
Albert
Levi
Albert
Levi
Issues Related Certificates
CA certification policies (Certificate
Practice Statement)
how reliable is the CA?
certification policies describe the
methodology of certificate issuance
ID-control practices
loose control: only email address
tight control: apply in person and submit picture
IDs and/or hard documentation
Issues Related Certificates
TRUST
verifiers must trust CAs
CAs need not trust the certified entities
certified entities need not trust its CA
What is trust in certification systems?
Answer to the question: How correct is the
certificate information?
related to certification policies
Issues Related Certificates
Certificate types
ID certificates
discussed here
authorization certificates
no identity
binding between public key and authorization info
Certificate storage and distribution
along with a signed message
distributed/centralized databases
Issues Related Certificates
Certificate Revocation
certificates have lifetimes, but they may be revoked
before the expiration time
Reasons:
certificate holder key compromise/lost
CA key compromise
end of contract (e.g. certificates for employees)
Certificate Revocation Lists (CRLs) hold the list of
certificates that are not expired but revoked
each CA periodically issues such a list with digital signature
on it
Real World Analogies
Is a certificate an electronic identity?
Concerns
a certificate is a binding between an identity
and a key, not a binding between an identity
and a real person
anyone can submit someone elses certificate
one must submit its certificate to identify itself,
but submission is not sufficient, the key must
be used in a protocol
Real World Analogies
Result: Certificates are not picture IDs
So, what is the real world analogy for
certificates?
Endorsed document/card that serves as a
binding between the identity and signature
Public Key Infrastructure (PKI)
PKI is a complete system and well-
defined mechanisms for certificates
certificate issuance
certificate revocation
certificate storage
certificate distribution
PKI
Business Practice: Issue certificates and
make money
several CAs
Several CAs are also necessary due to
political, geographical and trust reasons
3 interconnection models
hierarchical
cross certificates
hybrid
Hierarchical PKI Example
CAs
End users
Upper level CAs
Root CA
Cross Certificate Based PKI
Example
CAs
End users
Cross certificates
Hybrid PKI example
Certificate Paths
Certificate Paths
Verifier must know public key
of the first CA
Other public keys are found
out one by one
All CAs on the path must be
trusted by the verifier
Certificate Paths with Reverse
Certificates
Reverse certificates
Organization-wide PKI
Local PKI for organizations
may have global connections, but the
registration facilities remain local
generally to solve local problems
local secure access to resources
Organization-wide PKI
CP (CA)
Administration
RA CD
PKI Server
Databases / Directories
PKI Client


Architecture of a typical organization - wide PKI
Certificate
Processor/Authority
Registration
Authority
Certificate
Distribution
Hosted vs. Standalone PKI
Hosted (outsourced) PKI
PKI vendor acts as CA
PKI owner is the RA
Standalone PKI
PKI owner is both RA and CA
Hosted vs. Standalone PKI
Advantages of hosted PKI over standalone PKI
Standalone PKI Hosted PKI
Organization has to have a secure server
for certificate issuance and processing.
Organization does not need to run a secure
server for certificate processing.
Organization must issue cross certificates
or has to have some other arrangements for
universal connection of its PKI. Otherwise,
the PKI remains local.
PKI provider (host) already has such
arrangements. Organization does not have
to worry about worldwide visibility of its
PKI.
More administrative work for organization. Less administrative work for organization.


Disadvantages of hosted PKI over standalone PKI
Standalone PKI Hosted PKI
No continuous dependency on the PKI
vendor. Organization does not have to pay
periodic fees.
Continuous dependency on the PKI vendor
(host). The organization must pay regular
fees to the host based on the certificate
volume.
Security of the PKI is in the organizations
hands.
Although the organization is responsible
for the security of its PKI, they are
dependent on the hosts security.
Organization does not have to trust the PKI
vendor as different than its other software
vendors.
Ultimate trust to host is indispensable.
The only user of the private key is the
organization itself.
Private key is being used by the host for
certificate issuance.

X.509
ITU-T standard (recommendation)
ISO 9495-2 is the equivalent ISO standard
part of X.500 family for directory services
distributed set of servers that store user information
an utopia that has never been carried out
X.509 defines the authentication services and the
pubic-key certificate structure (certificates are to be
stored in the directory)
so that the directory would contain public keys of the
users
X.509
Defines identity certificates
attribute (authorization) certificates are added
in 4
th
edition (2000)
Defines certificate structure, not PKI
Supports both hierarchical model and
cross certificates
End users cannot be CAs

X.509 Certificate Format

X.509v3 Extensions
Not enough flexibility in X.509 v1 and v2
mostly due to directory specific fields
real-world security needs are different
email/URL names should be included in a certificate
key identification was missing (so should be included)
policy details should indicate under which conditions a
certificate can be used (was not the case in v1 and v2)
avoidance of blind trust was not possible in v1 and v2
Rather than explicitly naming new fields a
general extension method is defined
An extension consists of an extension identifier,
value and criticality indicator
X.509v3 Extensions
Key and policy information
subject & issuer key identifiers
indicators of certificate policies supported by the cert
key usage (list of purposes like signature, encryption, etc)
Alternative names, in alternative formats for
certificate subject and issuer
Certificate path constraints
For CA certs and to restrict certificate issuance based on
path length (restricting number of subordinate CAs)
policy identifiers
names
Verifier could exercise its own restrictions during
verification as well
No blind trust to CAs