Transcript Document

Email Security
Pretty Good Privacy (PGP)
S/MIME
Introduction
•
•
Email is one of the most heavily used network-based application.
There are two widely used schemes for providing authentication and
confidentiality for email security, PGP and S/MIME.
SMTP
• Internet email is originally based on SMPT-protocol (Simple Mail Transfer
Protocol)
• SMPT transfers a message consisting of header lines and a body (all ASCII)
using a packet relay network.
• SMPT does not have any security services. The messages can easily be read or
modified. Also the senders address of routing information is easy to change.
MIME
• ”Multipurpose Internet Mail Extensions” is an extension to solve many
limitations of using text-based messages and SMPT.
• MIME does not have security sercvices either.
PGP
•
•
•
•
•
•
•
•
PGP provides a confidentiality and authentication service that can be used for
file storage and electronic mail applications.
PGP was developed be Phil Zimmermann in 1991 and since then it has grown
in popularity. There have been several updates to PGP.
A free versions of PGP is available over the Internet, but only for noncommercial use. The latest (Jan. 2000) current version is 6.5.
Commercial versions of PGP are available from the PGP Division of Network
Associates
For three years, Philip Zimmermann, was threatened with federal prosecution
in the United States for his actions. Charges were finally dropped in January
1996.
At the close of 1999, Network Associates, Inc. announced that it has been
granted a full license by the U.S. Government to export PGP world-wide,
ending a decades-old ban.
PGP enables you to make your own public and secret key pairs.
PGP public keys are distributed and certified via an informal network called
"the web of trust".
PGP
• Most experts consider PGP very secure if used correctly. PGP is based
on RSA, DSS, Diffie-Hellman in the public encryption side, and
CAST.128, IDEA, 3DES for conventional encryption. Hash coding is
done with SHA-1.
• PGP has a wide range of applicability from corprorations that wish to
enforce a standardized scheme for encryptin files and messages to
individuals who wish to communicate securely with each others over
the interent.
PGP – Operational description
• The actual operation of PGP consists of five services: authentication,
confidentiality, compression, e-mail compatibility and segmentation
(Table 12.1.)
Authenticaiton
• The digital signature service is illustrated in Fig 12.1a.
– EC is used for conventional encryption, DC for decryption, and EP and
ED correspondingly for public key encryption and decryption.
• The algorithms used are SHA-1 and RSA. Alternatively digital
signatures can be generated using DSS/SHA-1.
• Normally digital signatures are attached to the files they sign, but there
are exceptions
– a detached signature can be used to detect a virus infection of an
executable program.
– sometimes more than one party must sign the document.
– a separate signature log of all messages is maintained
PGP – Operational description
Confidentiality
• Confidentiality service is illustrated in Fig 12.1b.
• Confidentiality can be use for storing files locally or transmitting them over
insecure channel.
• The algorithms used are CAST-128 or alternatively IDEA or 3DES. The
ciphers run in CFB mode.
• Each conventional key is used only once.
– A new key is generated as a random 128-bit number for each message.
– The key is encrypted with the receivers public key (RSA) and attached to the
message.
– An alternative to using RSA for key encryption, ELGamal, a variant of DiffieHellman providing also encryption/decryption, can be used.
•
•
The use of conventional encryption is fast compared to encryption the whole
message with RSA.
The use of public key algorithm solves the use session key distribution
problem. In email application any kind of handshaking would not be practical.
PGP – Operational description
Confidentiality and authentication
• Confidentiality with authentication is illustrated in Fig 12.1c.
• Firs a signature is generated for the message and prepended to the message.
Then conventional enctryption is applied to message and signature. Finally the
session key is encrypted using RSA.
• The order of operations is important: the signature must be computed fromm
the plaintext message. Otherwise a trird party would need the session key to
verify the signature.
Compression
• As a default PGP compresses the message after the signature but before
encryption (Fig 12.1. compression and decompression are noted as Z and Z-1)
• The signature is generated before compression for two reasons
– it now suffices to store only the plaintext version plus signature for later
verification.
– PGP’s compression algorithm is not deterministic; various implementations of the
algorithm achieve different tradeoff in running speed and compression rate. Thus
recompression for the verification would not work if the signature was generated
from the compressed message.
PGP – Operational description
Compression
• Message encryption is applied after compression to strenghten cryptographic
security.
– compressed message has less redundancy making cryptanalysis more difficult.
E-mail compatibility
• Encrypted parts of the message form a stream of 8-bit octets. PGP uses aradix64 conversion to convert this stream into printable ASCII characters.
• The length of the converted part of the message increases by 33%.
• Fig. 12.2. illustrates the the transmission and reception of PGP messages. As
an option, radix-64 conversion can be applien only to the signature if the
message is in plaintext. This enables a non-PGP recipient to read the message.
Segmentation and reassembly
• PGP automatically subdivides messages into segments that are small enough to
be sent via email. In the receiving end, the reassembly is also automatic.
PGP – Cryptographic keys and key rings
• PGP makes use of four types of keys: one-time session conventional
keys, public keys, private keys and passphrase-based conventional
keys.
• One-time session keys are generated with a ”random number
generator” using time intervals of the users keystrokes as the seed.
CAST-128 is used as a generator to produce 128-bit sesion keys.
• There are several reasons for one user to have multiple public/private
key pairs
– change the key from time to time for security
– use different keys for communication with different correspondant groups
• There is not a one-to-one correspondence between users and their
public keys. This problem is solved by using key ID’s.
• The overall scheme for key storage is that each PGP entityu maintains
two files, one for his own private keys, and the other for the public
keys of the correspondents.
PGP – Cryptographic keys and key rings
Key Identifiers
• The combination of user and key ID identifies the key uniquely.
• A key ID is consists of 64 least significant bits of the key being identified
(public or private).
– this identifies the key with a very high propability
– other solutions would have either space wasting or key management overhead.
•
•
•
•
•
The sender simply adds the key ID of the public key used into the message.
This allowes the receiver to determine which private key to use for encryption.
A key ID is also required for the PGP digital signature. The recipient must
know which of the many private keys was used in the signature. This ID is
also a 64 least significant bits of the corresponding public key.
The general format of the PGP message is presented in Fig. 12.3.
The message has three components: message component, signature
component and session key component.
Normally the entire block is encoded with radix-64, but the conversion can be
applied also only to selected components.
PGP – Cryptographic keys and key rings
Key Rings
• The keys and key ID’s need to be stored and organized in a systematic way in
order to be used efficiently by all parties.
• The scheme in PGP is to use a pair of tables in each node, the public key ring
stores the public keys of other users known to this node, and the private key
ring to store this nodes own public/private key pairs.
• The private key ring stores the timestamp, key ID, public key, private key in an
encrypted form and the user ID.
– private key is stored encrypted with conventional algorithm for security reasons.
The key used in the encryption is a hash-code from a user selected passphrase.
When the user needs to retrieve the private key he must provide for the passphrase.
•
The public key ring stores the timestamp, key ID, public key, owner trust, user
ID, key legitimacy, signature(s) and signature trust(s).
– owner trust, key legitimacy, signature(s) and signature trust(s) are used to build a
”web of trust” for public key management (explained later)
•
Now we can show the message transmission and reception in total (omitting
the radix-64 conversion). See Fig. 12.5 and 12.6.
PGP – Public key management
”This whole business of protecting public keys from tampering is the single
most difficult problem in practical public key applications. It is the ”Achilles
heel” of public key cryptography, and a lot of software complexity is tied up in
solving this one problem.”
- Phil Zimmermann –
•
•
PGP provides a structure for solving the problem. Unlike the solution used in
S/MIME, PGP has no rigid public key management scheme is used in PGP.
A number of approaches are possible for minimizing the risk that a user’s
public key ring contains false public keys. Suppose A wishes to obtain a
reliable public key from B.
– A can get the key physically. This is very secure but unpractical.
– The key could be verified in telephone. Also very secure but unpractical.
– A could obtain the key from a mutual trusted individual D. This is a variation of the
public-key certificate scheme discussed before.
– A could obtain the key from a trusted certifying authority, i.e. use the public-key
certificate scheme discussed before.
PGP – Public key management
•
•
•
•
•
•
The solution used by PGP is to build a ”web of trust” using public key
certificates of several variably trusted individuals. With this web, trust
information can be explited and associated with public keys.
In the public-key ring there were several fields for each stored public key for
this purpose. Each entry in the ring is a public key certificate.
Key legitimacy field indicates the extent to which PGP will trust that this is a
valid public key for this user. This field is computed by PGP.
Assiciated with each entry there are zero or more signatures that the ring
owner has collected that sign this public key certificate.
Each signature has a signature trust fiela that indecates the degree to which
this PGP user trusts the signer to certify public keys. The key legitimacy is
derived from the collection of signature trust fields in the entry.
Each entry defines a public key associated with a particular owner. Owner
trust field is included to indicate the degree to which this public key is trusted
to sing other public key certificates. This level of trust is assigned by the user.
• A Trust Flag Byte contains the three metioned filelds (table below)
• The trust processing operates as follows:
– A inserts a new public key on the key ring. If the key is A’s own, then
ultimate trust is assigned. Otherwise A has to enter his assessment of trust to
be assigned to the owner of this key.
– When the new public key is entered. one or more signatures can be
associated with it. When a signature is enrered, PGP searches the key ring to
see if the author of the signature is among the known public key owners.
PGP – Public key management
• Trust processing continues....
– If the author was found, the OWNERTRUST value of this owner is
assiged to the SIGTRUST field for this signature. If not, an unknown user
value is assigned.
– The value of the KEYLEGIT field is calculated on the basis of the
signature trust fields present in this entry. If at least one signature has a
SIGTRUST value ultimate then the key legitimacy is set to be complete.
Otherwise a weighted sum of trust values is computed. This derivation of
trust can be controlled by used-defined parameters.
• PGP processes the public.key ring periodically to achieve consistency
going from OWNERTRUST to SIGTRUST fields and finally
computing the KEYLEGIT values.
• Figure 12.7. is an example of the way in which signature trust and key
legitimacy are related. (the node ”You” refers to the entry in the publickey ring corresponding to this user).
PGP – Public key management
• A user may wish to revoke his or her public key for a variety of
reasons. In this case the owner issues a revocation certificate signed by
the owner. This certificate is then dissiminated as widely as possible to
enable the correspondents to update their public key rings.
Introduction
• S/MIME is the de-facto industry standard for secure mail over the
Internet. Secure MIME (S/MIME) was developed by an industry
consortium, and is now appearing in a number of major products.
• MIME is an extencion to the RFC 822 addressing many limitations of
the use of SMPT.
• MIME specification includes
– new message headers
– a number of content formats supproting multimedia electronic mail
– transfer encodings
• The MIME content types are listed in table 12.3.
S/MIME Functionality (messages)
• The general functionality of S/MIME is very similar to PGP buth
offering the ability to sign and/or encrypt messages.
S/MIME Functions
The S/MIME functions are implemented as new MIME content
types.These are listed in table 12.7.
• Enveloped data
– This content type consists of encrypted content of any type and encrypted
content encryption keyys for one or more receipients.
– An enveloped data entity is prepared as follows: 1) Generate the pseudo
random session key. 2) Encrypt the session key with each recipients public
RSA key. 3) For each recipient prepare a RecipientInfo block containing
senders public key certifcate, an identifier of the encryption algorithm and
the encrypted session key. 4) Encrypt the message content with the session
key.
S/MIME Functionality
• Signed data
– A digital signature is formed by taking the message digest of the content
to be signed and encrypting that with the private key of the signer.
– 1) Compute the message digest with SHA or MD5.
– 2) Encrypt the message digest with senders private key
– 3) prepare SignerInfo block containing singer’s public key certificate, an
identifier of the message digest algorithm, and identifier of the encryption
algorithm and the encrypted message digest.
– A signed data message can only be read by a recipient having S/MIME
capabilities
• Clear signed data
– Same as previous but now the message contents are readable without
S/MIME, which is needed if the recipient wishes to verify the identity if
the sender.
• Signed and enveloped data
– Signed-only and encrypted-only messages can be nested in both
orderings.
S/MIME Functionality
• Registration request
– An application or a user typically applies to a CA for a public-key
certificate. This content format is used to transfer such request.
• Certificates-only message
– this is a message containing only certificates or a certificate revocation
list. It is sent as a response to registration request.
S/MIME – cryptographic algorithms
• The used algorithms are summarized in table 12.6.
• There are two requirement levels:
– MUST means an absolute requirement in order to be in conformance with
the specification.
– SHOULD allows an implementation to ignore this feature for valid
reasons. it is however recommended that all implementations include
these features.
• S/MIME incorporates three public-key algorithms
– DSS is recommended.
– ElGamal (a varition of D-H that allows also encryption) or RSA as
alternatives
• The recommended hash-function is SHA-1. The alternative MD5.
• For message encryption, three-key triple DES is recommended. All
compliant implementations must support RC2 using a key of only 40
bits, which is a weak encryption algorithm.
S/MIME – Certificate Processing
• S/MIME uses public key certificates that conform to X.509v3
directory services.
• The public key management scheme is a hybrid between the strict
X.509 certification hierarchy and PGP’s ”web of trust”.
• As with PGP, S/MIME administrators/users must configure each client
with a list of trusted trusted keys and certificate revocation lists.
– the responsibility for maintaining certificates needed to verify incoming
messages and encrypt outgoin ones is local.
– however, the cerificates are signed by certification authorities.
User’s role
• An S/MIME user has several key-management functions to perform
• Key generation: the user MUST be able to generate DSS and D-H key
pairs and SHOULD be able to generate RSA key pairs.
• Registration: a user’s public key must be registered with a CA in order
to receive an X.509 certificate.
• Certificate storage and retrieval: a list of certificates can be
maintained by the user or some local administrative entity.
S/MIME – Certification Authorities
• "Certificate Authority" (CA), or "Trust Center", is the name used for an
organisation that acts as the agent of trust in a PKI (Public Key
Infrastructure) and also for the piece of software. PKI needed for
secure use of public key based protocols
• A CA performs 5 main functions:
– Verifies users' identities - this may be done by the CA itself, or on its
behalf by a Local Registration Authority (LRA)
– Issues users with keys (though sometimes users may generate their own
key pair)
– Certifies users' public keys
– Publishes users’certificates
– Issues certificate revocation lists (CRLs)
• There are several companies that provide CA services.
• CA services exist in the full range from individual users wishing to
secure personal mail to full scale enterprise CA solutions.
• An examlple of the types and uses of public key certificates is shown
in table 12.8.
OpenPGP
• Email is one of the most heavily used network-based application.
• There are two widely used schemes for providing authentication and
confidentiality for email security, PGP and S/MIME.