computer network briefs

8/13/2019 computer network briefs

1/74

E-mail Security:PGP, S/MIME, and PEM

Dijiang Huang


2/74

2

Email: Distribution List Simplest:

Single recipient per email message.

Distribution List Send mail to a set of recipients.

Remote Exploder Model

Sender

Distribution List Maintainer

recipient

msg

recipient

msg

recipient

msg

recipient

msg

msg

msgrecipient


3/74

3

Email: Distribution List Distribution List

Send mail to a set of recipients.

Remote Exploder Model

Local Exploder Model

Sender

Distribution List Maintainer

Get list

List

recipientmsg

msg recipientmsg recipient

msg recipient

msg recipient


4/74

4

Email: Distribution List Local Exploder

Easier to prevent mail forwarding loops. Caused by distribution lists contained in distribution

lists.

Easier to prevent multiple copies of the same

message. By weeding out duplicates in the list.

Bandwidth consumption is known to user. Important when we start billing per email message.


5/74

5

Email: Distribution List Remote Exploder

Allows the membership to be kept secret fromsender.

Can be cheaper if recipients are geographicallyclustered around the list maintaining site.

More efficient if list size is bigger thanmessage size.

Faster when distribution lists are contained in

distribution lists.


6/74

6

Mail Handling

Simplest: Send message directly from

senders machine to recipients machine. Works only if the recipients machine is always on.

Need Electronic Post Boxes.

Send mail to a machine permanently connected.


7/74

7

Mail Infrastructure

Two Standards

X.400 family of protocols Defined by International Telecommunications Union

ITU and International Standardization Organization

ISO

SMTP

Simple Mail Transfer Protocol

Defined by the Internet Engineering Task Force

IETF.


8/74

8

Mail Infrastructure

Mail infrastructure consists of a mesh of

mail forwarders. Called Message Transfer Agents (MTA)

Processing at source and destination done by

User Agent (UA)

MTA

MTA

MTA

MTA

UA UA


9/74

9

Mail Infrastructure

Typically more than one path.

Deals with intermittent connections.

MTA could insist on authentication.

Security gateways through which all company

mail is forwarded.

Routing typically done manually.


10/74

10

Email Security Services I Privacy Keep anyone but the recipient from reading the message.

Authentication Receiver is reassured of the identity of the sender.

Integrity Receiver is reassured that the message has not been altered since transmission by

sender.

Non-repudiation Ability of recipient to prove (to a third party) that the sender really did send this

message.

A.k.a. third party authentication.

Proof of submission Verification given to the sender that the message was handed to the mail delivery

system.

Not the same as a receipt by recipient / proof of delivery.

Possible to prove the identity of the message.

Proof of delivery Verification given to the sender that the message was handed to the UA of the

recipient.

Not the same as proof of submission.

Possible to prove the identity of the message.


11/74

11

Email Security Services II Message flow confidentiality.

Third party cannot tell whether email is exchanged between sender andrecipient.

Anonymity The ability to send a message so that the receiver cannot tell the identity of

the recipient.

Containment Ability of the network to keep security levels of information from leaking out

of a particular region.

Audit Capacity to log security relevant events.

Accounting Capacity to maintain system usage statistics and charge individual users.

Self Destruct

User should not be capable of forwarding or storing the message. Message Sequence Integrity

Reassurance that an entire sequence of messages arrived in the ordertransmitted and without losses.


12/74

12

Key Establishments Establishing Public Keys:

Out-of-band transmission PGP public key hash on business card.

PKI

Piggy-backing of certificates on email messages.

Establishing Secret Keys Out-of-band transmission

Ticket via KDC.

Alice would obtain a ticket for Bob and attach it to her

message to him.


13/74

13

Privacy Threatened by Eavesdropping.

Relay nodes might store messages.

Fundamentally, at sender and receivers machine. End-to-End Privacy

Sender and recipient use encryption.

Complicated by multiple recipients.

Keys should be only used sparingly to avoid cipher attacks. Alice chooses a secret key S.

Alice encrypts S with the key she shares with each recipient.

To: Bob, Carol, Dexter

From: Alice

Key-info: Bob 98932472138, Carol 129834298732, Dexter 100231098432

Message: qewroiu3219087v90(87sdh32198y*&97slknseiahfusdfiu39587(*


14/74

14

Privacy With Distribution List Exploders

Remote exploding: Alice chooses a secret key S and encodes her

message.

Alice attaches S encrypted to all recipients.

Distribution list exploder decodes S and attaches itencrypted to all recipients.

Local exploding: Alice needs to exchange keys with all people on the

list.


15/74

15

Source Authentication

With Public Key Technology

Alice can sign a message to Bob By encrypting the whole message with her private key.

Then Bob would have to know Alices public key.

Alice could embed her public key in the message together

with a certificate or certificate chain. By calculating a hash (MD5) of the message and

encrypting it with her private key.

Then Bob does not need to know Alices public key to read

the mail.


16/74

16

Source Authentication With secret key technology

Alice and Bob share a secret S.

She can prove her identity by performing a computation on the

message using S. Result called

MIC Message Integrity Code

MAC Message Authentication Code.

Various methods:

MAC is the encryption of the MD5 of message.

Then Alice only needs to repeat the encryption for various recipients.

MAC is the CBC residue of the message encrypted with S.


17/74

17

Source Authentication

With Distribution Lists

Public Keys: Easy. Anyone can get Alices public key.

Secret Keys: Hard. Alice needs to share a key with the distribution list

exploder. Exploder will have to recalculate authentication data.

E.g. recalculate the encrypted hash with the recipientskey.


18/74


19/74

19

Repudiation

Repudiation = Act of denying that a message was sent.

Public Key Technology Alice signs with her private key.

Bob can prove that Alice signed it. Hence non-repudiation.

Alice picks secret key S.

She encrypts S with Bobs public key: {S}Bob.

She signs {S}Bob with her private key: [{S}Bob]Alice

She uses S to compute a MAC for the message. She sends the message, the MAC, and [{S}Bob]Alice to Bob.

Bob knows that the message came from Alice because of Alicesprivate key.

Bob can create any other message with S, therefore, he cannotprove that Alice send him that particular message.

Hence repudiation.


20/74

20

Repudiation

Secret Key Technology with non-repudiation

Needs a notary N.

Alice sends message to Bob first to N with source authentication.

Notary creates a seal.

Seal is something based on the message and Alices name with asecret key that N does not share.

For example, encryption of message digest and Alices name.

Bob needs to be able to verify the seal.

If Bob and N share a key, then N could verify the seal by sending anencryption of the message digest, Alices name, and the seal.

Bob asks N to verify the seal.

Bob can prove that Alice sent this message.

Hence non-repudiation.


21/74

21

Proof of Submission / Delivery

Email system can generate proof of receiving

a message at any way station. By handing out seals of sent messages.


22/74

22

Message Flow Confidentiality

Needs an intermediary.

Alice sends her email to Ivy, who forwards itto Bob.

Alice periodically sends fake messages to

Ivy.

Ivy periodically sends fake messages to

random recipients.


23/74

23

Anonymity

Needs anonymity server.

Freely available, but have difficulty withbusiness model.


24/74


25/74

25

Text Formatting Issues

No canonical text format RFC 822 provides one format with characters to

separate lines. But only works with SMTP.

Some mail servers remove white space at the end of lines, addline breaks to lines that are too long, etc.

This can break hashes and other MACs

Data needs to be disguised as text. uuencode

Uses 64 safe characters.

Data is encoded in these 64 characters 6 bits encoded in 8 bits

S/MIME, PEM, PGP do something similar The result is not readable by humans.


26/74

26

Verifying dates

Preventing Backdating

Use a notary to verify messages. Calculate MD5 of received message.

Send MD5 to notary.

Notary creates an encryption of MD5 and date.

Can include certificates used to establish senders identity.

Preventing Postdating Include something in the message that you could only have

known at the time that the message was sent.


27/74

27

Pretty Good Privacy

More than just a mail protocol.

Interesting history.

Number of incompatible versions


28/74

28

PGP: Pretty Good Privacy

PGP uses public key cryptography.

Anarchic certificate model: Everybody issues certificates and forwards public keys.

Users decide on trust rules.

Elaborate system of generating public-private keys.

Data on public keys, certificates, and people is combined ina key ring.

Key rings can be exchanged to build up trust databases.


29/74

29


Transfer Encoding

User specifies type of file for handling Binary

Text file

Binary files are encoded at most once in order toprepare them for mail transit.

All files are compressed.


30/74

30


PGP messages

PGP uses IDEA. Message is prefaced with the IDEA key encrypted

with the recipients public key.


31/74


32/74

32

PGP services

messages

authentication

confidentiality compression

e-mail compatibility

segmentation and reassembly

key management

generation, distribution, and revocation ofpublic/private keys

generation and transport of session keys and IVs


33/74

33

Message authentication based on digital signatures

supported algorithms: RSA/SHA and DSS/SHA

hashhash encenc

hashhash decdeccomparecompare

accept / reject

m h

Ksnd-1

Ksnd

m h h

sender

receiver


34/74

34

Message confidentiality symmetric key encryption in CFB mode with a random

session key and IV

session key and IV is encrypted with the public key of thereceiver

supported algorithms:

symmetric: CAST, IDEA, 3DES

asymmetric: RSA, ElGamal

prngprng

s.encs.enc

m

Krcv

sender

a.enca.enck, iv

{m}k

{k, iv}Krcv


35/74

35

Compression applied after the signature

enough to store clear message and signature for later

verification

it would be possible to dynamically compress messagesbefore signature verification, but

then all PGP implementations should use the same

compression algorithm

however, different PGP versions use slightly different

compression algorithms

applied before encryption

compression reduces redundancy makescryptanalysis harder

supported algorithm: ZIP


36/74

36

E-mail compatibility encrypted messages and signatures may contain arbitrary octets

most e-mail systems support only ASCII characters

PGP converts an arbitrary binary stream into a stream of printable

ASCII characters radix 64 conversion: 3 8-bit blocks 4 6-bit blocks

0 7 0 7 0 7

0 5 0 5 0 5 0 5

character

encoding

6-bit

value

52 0

61 9

62 +

63 /

(pad) =

0 A

...25 Z

26 a

51 z

character

encoding

6-bit

value


37/74

37

Combining services

X := fileX := file

signature?signature?

compress

X := Z(X)

compress

X := Z(X)

encryption?encryption?

radix 64

X := R64(X)

radix 64

X := R64(X)

generate signatureX := (X) || X

generate signature

X := (X) || X

generate envelop

X := {k}Krcv || {X}k

generate envelop

X := {k}Krcv || {X}k

yes

yes

no

no


38/74

38

PGP message format

session key

component

signature

message

key ID of Krcv

session key k

timestamp

key ID of Ksnd

leading two octets of hash

hash

filename

timestamp

data

{}K

rcv

{}K

snd-1

{}k

ZIP

R64


39/74


40/74

40

Private-key ring

used to store the public key private key pairs owned by

a given user

essentially a table, where each row contains the

following entries:

timestamp

key ID (indexed)

public key

encrypted private key

user ID (indexed)

encencpassphrase hashhash

private key

encrypted private key


41/74

41

Public-key ring

used to store public keys of other users

a table, where each row contains the following entries: timestamp

key ID (indexed)

public key

user ID (indexed)

owner trust

signature(s)

signature trust(s)

key legitimacy


42/74

42

Web of Trust

Users exchange keys and establish trust with

each other

Users decide for themselves which keys are valid

Users can also sign the keys of others, leading to

a web of trust

Organizations are not able to enforce security

policies regarding the trust relationship

Key management is time-consuming, dependent

on a great deal of manual intervention


43/74

43

Trust management Owner trust: the level of trust the user places on the key that the

key's owner can serve as certifier of others' keys

assigned by the user

possible values: unknown user

usually not trusted to sign

usually trusted to sign

always trusted to sign

ultimately trusted(own key, present in private key ring)

Signature trust

assigned by the PGP system

if the corresponding public key is already in the public-key ring,

then its owner trust entry is copied into signature trust

otherwise, signature trust is set to unknown user


44/74

44

Trust management key legitimacy

computed by the PGP system

if at least one signature trust is ultimate, then the key legitimacy is 1

(complete) otherwise, a weighted sum of the signature trust values is computed

always trusted signatures has a weight of 1/X

usually trusted signatures has a weight of 1/Y

X, Y are user-configurable parameters example: X=2, Y=4

1 ultimately trusted, or

2 always trusted, or

1 always trusted and 2 usually trusted, or

4 usually trusted signatures are needed to obtain full legitimacy


45/74

45

Example key legitimacyX = 1, Y = 2

user

A

B

C

D

E

F

G H

I

J

K

ML

untrusted / usually untrusted

usually trusted

always trusted

ultimately trusted (you)

signature

legitimate


46/74

46

Public-key revocation why to revoke a public key?

suspected to be compromised (private key got known by

someone)

re-keying

the owner issues a revocation certificate

has a similar format to normal public-key certificates

contains the public key to be revoked

signed with the corresponding private key and disseminates it as widely and quickly as possible

if a key is compromised:

e.g., Bob knows the private key of Alice

Bob can issue a revocation certificate to revoke the public key ofAlice

even better for Alice


47/74

47

S/MIME

/


48/74

48

What is S/MIME?

Secure / Multipurpose Internet Mail Extension

a security enhancement to MIME provides similar services to PGP

based on technology from RSA Security

industry standard for commercial and

organizational use

RFC 2630, 2632, 2633


49/74

49

MIME

defines new message header fields

defines a number of content formats(standardizing representation of multimedia

contents)

defines transfer encodings that protects thecontent from alteration by the mail system

RFC 822


50/74

50

RFC 822 defines a format for text messages to be sent using e-mail

Internet standard

structure of RFC 822 compliant messages

header lines (e.g., from: , to: , cc: ) blank line

body (the text to be sent)

example

Date: Tue, 22 Nov 2005 10:37:17 (EST)

From: Alice Polen

Subject: Test

To: [email protected]

Blablabla

MIME N h d fi ld


51/74

51

MIME - New header fields

MIME-Version

Content-Type

describes the data contained in the body

receiving agent can pick an appropriate method to represent the

content

Content-Transfer-Encoding

indicates the type of the transformation that has been used to

represent the body of the message

Content-ID

Content-Description

description of the object in the body of the message

useful when content is not readable (e.g., audio data)

MIME C d b


52/74

52

MIME Content types and subtypes

text/plain, text/enriched

image/jpeg, image/gif

video/mpeg

audio/basic

application/postscript, application/octet-stream

multipart/mixed, multipart/parallel, multipart/alternative,

multipart/digest (each part is message/rfc822)

message/rfc822, message/partial, message/external-

body

MIME T f di


53/74

53

MIME Transfer encodings 7bit

short lines of ASCII characters

8bit

short lines of non-ASCII characters binary

non-ASCII characters

lines are not necessarily short

quoted-printable

non-ASCII characters are converted into hexa numbers (e.g., =EF)

base64 (radix 64)

3 8-bit blocks into 4 6-bit blocks

x-token

non-standard encoding


54/74


55/74


56/74

S/MIME services


57/74

57

S/MIME services

enveloped data (application/pkcs7-mime; smime-type = enveloped-

data)

standard digital envelop

signed data (application/pkcs7-mime; smime-type = signed-data)

standard digital signature (hash and sign)

content + signature is encoded using base64 encoding

clear-signed data (multipart/signed)

standard digital signature

only the signature is encoded using base64

recipient without S/MIME capability can read the message but

cannot verify the signature

signed and enveloped data

signed and encrypted entities may be nested in any order

Cryptographic algorithms


58/74

58

Cryptographic algorithms message digest

must: SHA-1

should (receiver): MD5 (backward compatibility)

digital signature must: DSS

should: RSA

asymmetric-key encryption

must: ElGamal

should: RSA

symmetric-key encryption

sender:

should: 3DES, RC2/40

receiver:

must: 3DES

should: RC2/40

Securing a MIME entity


59/74

59

Securing a MIME entity

MIME entity is prepared according to the

normal rules for MIME message preparation prepared MIME entity is processed by

S/MIME to produce a PKCS (public key

cryptography standard by RSA) object the PKCS object is treated as message

content and wrapped in MIME


60/74

PKCS7 enveloped data


61/74

61

PKCS7 enveloped data

Version

Encrypted Content Info

Recipient Info

Version

Recipient ID (issuer and s.no.)

Key Encryption Algorithm

Encrypted Key

Content Encryption Alg.

Content type

Encrypted Content

Originator Info

Enveloped data Example


62/74

62

Enveloped data ExampleContent-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=smime.p7m

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6

7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H

f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4

0GhIGfHfQbnj756YT64V

Clear-signed data Example


63/74

63

Clear signed data ExampleContent-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: base64Content-Disposition: attachment; filename=smime.p7s

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6

4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj

n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4

7GhIGfHfYT64VQbnj756

--boundary42--

Key management


64/74

64

Key management

S/MIME certificates are X.509 conformant

key management scheme is between strict certificationhierarchy and PGPs web of trust

certificates are signed by certification authorities (CA) key authentication is based on chain of certificates

users/managers are responsible to configure their clientswith a list of trusted root keys

K


65/74

65

Privacy Enhanced Mail: PEM

Described in RFC 1421, 1422, 1423, 1424. Pretty much dead now.



66/74

66


PEM is implemented in software at the

sender and the receiver, not in-between. PEM messages need to pass unchanged

through mail-servers.

PEM provides integrity protection andencryption



67/74

67

v cy c d

PEM message

Can consists of several blocks.

PEM flags them as separate, treated blocks. Ordinary, unsecured data.

Integrity protected, unmodified data Integrity protected encoded data

Encoded = safe to transmit through all mailers

Integrity protected, encoded, and encrypted data



68/74

68

y

Establishing keys

Per message key (random number) Interchange key (public key)

To encrypt message key.



69/74

69

y

PEM Certificate Hierarchy

Single root CA (certification authority) Internet Policy Registration Authority

Managed by the internet society

Public Certification Authorities

PCAs have different assurance levels.

There is only one path from the root CA to an individual



70/74

70

y

Certification

PEM allows Alice to send Bob her relevantcertificates by including them in the PEM header.

Certification Revocation Lists

Not included in header, hence Two message types

CRL-Retrieval-Request to CRL service

CRL



71/74

71

y

Data canonicalization

How to get data through mail forwarders? PEM encodes 6 bits into an 8b character


72/74



73/74

73

y

Integrity protection

Message integrity code MD2

MD5

Protected by cryptography

Alice signs the MIC with her private key. When message is encrypted, the signed MIC needs to be

encrypted as well.

Alice encrypts the MIC with the interchange key.



74/74

74

Multiple recipients

No problem for signed messages.

Encrypted messages are encrypted with the same key. The per-message key is encrypted for each recipient individually.

Forwarding

Should allow recipient to verify the signature of the original

sender. Only works with public keys.

If only integrity protected, only forwarding is necessary.

If encrypted, first receiver decrypts the per-message key, reencryptsit with the final receivers public key, and forwards.

computer network briefs

Documents

Transcript of computer network briefs