Privacy Enhanced Email

1
Privacy Enhanced E-mail
2
Privacy Enhanced E-mail

• services for electronic mail transfer in the
  Internet

3
Terminology

• Majority of the terminology is based on the OSI
  MHS Model (Message Handling System Model.).
• User -- A person or a computer application. May
  be referred to as an originator or a recipient.
• Originator -- Prepares messages with the
  assistance of his User Agent.

4
More Terms

• User Agent (UA) -- Is an application process that
  interacts with the Message Transfer System (MTS)
  to submit messages.
• MTS is composed of a number of Message Transfer
  Agents (MTAs). Operating together, the MTAs
  relay messages and deliver them to the intended
  recipient UAs, which then make the messages
  available to the intended recipients. collection
  of UAs and MTAs is called the Message Handling
  System.

5
PEM functions

• 1. PEM is not restricted to a particular host
  or operating system, but rather allow
  interoperability among a broad range of systems.
  All privacy enhancements are implemented at the
  application layer, and are not dependent on any
  privacy features at lower protocol layers.

6

• 2. PEMs offer compatibility with non- enhanced
  Internet components and will be implemented in an
  end-to-end fashion. Which does not impact mail
  processing by intermediate relay hosts which do
  not incorporate privacy enhancement
  facilities. It is necessary, however, for a
  message's sender to be cognizant of whether a
  message's intended recipient implements privacy
  enhancements, in order that encoding and
  encipherment will not be performed on a message
  whose destination is not equipped to perform the
  corresponding inverse transformations.

7

• 3. PEMs offer compatibility with a range of
  mail transport facilities (MTAs). Within the
  Internet, electronic mail transport is effected
  by a variety of SMTP implementations. Certain
  sites, accessible via SMTP, forward mail into
  other mail processing environments (e.g., USENET,
  CSNET, BITNET). The privacy enhancements must be
  able to operate across the SMTP realm it is
  desirable that they also be compatible with
  protection of electronic mail sent between the
  SMTP environment and other connected environments.

8

• 4. PEMs offer compatibility with a broad range
  of electronic mail user agents (UAs). A large
  variety of electronic mail user agent programs,
  with a corresponding broad range of user
  interface paradigms, is used in the Internet. In
  order that an electronic mail privacy enhancement
  be available to the broadest possible user
  community, it is desirable that the selected
  mechanism be usable with the widest possible
  variety of existing UA programs. For purposes of
  pilot implementation, it is desirable that
  privacy enhancement processing be incorporable
  into a separate program, applicable to a range of
  UAs, rather than requiring internal modifications
  to each UA with which enhanced privacy services
  are to be provided.

9

• 5. PEMs allow electronic mail privacy
  enhancement processing to be performed on
  personal computers (PCs) separate from the
  systems on which UA functions are implemented.
  Given the expanding use of PCs and the limited
  degree of trust which can be placed in UA
  implementations on many multi-user systems, this
  attribute can allow many users to process
  privacy-enhanced mail with a higher assurance
  level than a strictly UA-based approach would
  allow.

10

• 6. PEMs support privacy protection of
  electronic mail addressed to mailing lists.

11
In order to achieve applicability to the broadest
possible range of Internet hosts and mail
systems, and to facilitate pilot implementation
and testing without the need for prior
modifications throughout the Internet, three
basic restrictions are imposed.
12

• 1. Measures will be restricted to
  implementation at endpoints and will be amenable
  to integration at the user agent (UA) level or
  above, rather than necessitating integration into
  the message transport system (e.g., SMTP servers).

13

• 2. The set of supported measures enhances
  rather than restricts user capabilities. Trusted
  implementations, incorporating integrity features
  protecting software from subversion by local
  users, cannot be assumed in general. In the
  absence of such features, it appears more
  feasible to provide facilities which enhance user
  services (e.g., by protecting and authenticating
  inter-user traffic) than to enforce restrictions
  (e.g., inter-user access control) on user actions.

14

• 3. The set of supported measures focuses on a
  set of functional capabilities selected to
  provide significant and tangible benefits to a
  broad user community. By concentrating on the
  most critical set of services, we aim to maximize
  the added privacy value that can be provided with
  a modest level of implementation effort. As a
  result of these restrictions, the following
  facilities can be provided

15
-- disclosure protection-- sender
authenticity-- message integrity measures but
the following privacy-relevant concerns are not
addressed -- access control,
-- traffic flow security, -- address
list accuracy, -- routing control,
-- issues relating to the serial reuse of PCs
by multiple users, -- assurance of
message receipt and non-deniability of receipt,
and -- automatic association of
acknowledgments with the messages to
which they refer
16
Privacy Enhancement is an end to end service
between sender and recipient UAs

• Two distinct privacy enhancement service options
  are supported
• 1. an option providing sender authentication and
  integrity verification.
• 2. an option providing sender authentication and
  integrity verification in addition to
  confidentiality service through encryption

17

• A message's sender will determine whether privacy
  enhancements are to be performed on a particular
  message. This will necessitate mechanisms by
  which a sender can determine whether particular
  recipients are equipped to process
  privacy-enhanced mail. In a general
  architecture, these mechanisms will be based on
  server queries thus, the query function could be
  integrated into a UA to avoid imposing burdens or
  inconvenience on electronic mail users.

18
Processing of Messages

• A two-level keying hierarchy is used to support
  privacy-enhanced message transmission
• Data Encrypting Keys (DEKs) are used for
  encryption of message text and for computation of
  message authentication codes (MACs).
• Interchange Keys (IKs) are used to encrypt DEKs
  for transmission.

19
Data Encrypting Keys (DEKs)

• required for message text decryption and/or MAC
  verification
• are generated individually for each transmitted
  message.
• no predistribution of DEKs is needed to support
  privacy-enhanced message transmission.
• used for message encryption and/or
  authentication, encrypted under an individual IK
  per named recipient.

20
Interchange Keys (IKs)

• are used to encrypt DEKs for transmission.
• may either be a single symmetric cryptographic
  key or, where asymmetric (public-key)
  cryptography
• each transmitted message includes a
  representation of the DEK
• an identifier (IK ID) enables the recipient to
  determine which IK was used

21
Encoding

• represents encrypted message text in a
  universally transmissible form
• enables message encrypted on one type of system
  to be decrypted on a different type of system
• Four phases are involved in this process

22
Four Phases

• A plaintext message is accepted in local form,
  using the host's native character set and line
  representation
• It is converted to a canonical message text
  representation, defined as equivalent to the
  inter-SMTP representation of message text.
• The representation is padded to an integral
  multiple of eight octets, as required by the
  encryption algorithm.
• MAC computation is performed, and (if disclosure
  protection is required), the padded canonical
  representation is encrypted. The output of this
  step is then encoded into a printable form.

23
Encryption Algorithms and Modes

• uses hexidecmal numbering system
• must be a 64-bit block cipher, enciphering and
  deciphering in 8 octet blocks
• are usable in the ECB and CBC modes defined in
  DIS8372
• be appropriate for MAC computation
• cryptographic key field lengths are limited to 16
  octets in length

24
Canonical Encoding

• Any encryption scheme compatible with the
  transparencyconstraints of its underlying
  electronic mail facilities.
• established based on expected user requirements
  and on the characteristics of anticipated
  endpoint transport facilities.
• an example is SMTP

25
An outbound PEM is transformed between four
forms, in sequence

• (Local_Form) The message text is created
• (Canonicalize) The message text is converted to
  the universal canonical form, equivalent to the
  inter-SMTP representation
• (Encipher/Authenticate) A padded version of the
  canonical plaintext till length is multiple of 8
  octects
• (Encode to Printable Form) The bits resulting
  from the encryption operation are encoded into
  characters which are universally representable at
  all sites

26
Value Encoding Value Encoding Value Encoding
Value Encoding 0 A 17 R 34 i
51 z 1 B 18 S
35 j 52 0 2 C 19
T 36 k 53 1 3 D
20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56
4 6 G 23 X 40 o
57 5 7 H 24 Y
41 p 58 6 8 I
25 Z 42 q 59 7 9
J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62
12 M 29 d 46 u
63 / 13 N 30 e
47 v 14 O 31 f 48
w (pad) 15 P 32 g
49 x 16 Q 33 h
50 y (1)
27
-----PRIVACY-ENHANCED MESSAGE BOUNDARY-----
X-Proc-Type 1,E X-Pad-Count 1
X-IV F8143EDE5960C597 X-IK-ID JL3ECB
X-Key-Info 9FD3AAD2F2691B9A,B70665BB9BF7CBCD
X-IK-ID JL1ECB X-Key-Info
161A3F75DC82EF26,E2EF532C65CBCFF7
LLrHB0eJzyhP/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHE
USoH1nvNSIWL9M 8tEjmF/zxBbATMtPjCUWbz8Lr9wl
oXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoKoNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBW
GGsDLpTpSCnpot dXd/H5LMDWnonNvPCwQUHt----
-PRIVACY-ENHANCED MESSAGE BOUNDARY-----
Example Encapsulated Message
28

• X-IK-ID This field is placed in the
  encapsulated header portion of a message to
  identify the Interchange Key used for encryption
  of an associated Data Encrypting Key or keys
  (used for message text encryption and/or MAC
  computation). This field is used for messages
  authenticated without confidentiality service and
  for messages authenticated with confidentiality
  service.
• X-IV Is placed in the encapsulated header
  portion of a message to carry the Initializing
  Vector used for message encryption
• X-Key-Info Is placed in a message's
  encapsulated header portion to transfer two items
• X-Pad-Count Is placed in the encapsulated
  header portion of a message to indicate the
  number of zero-valued octets which were added to
  pad the input
• X-Proc-Type Is placed in the encapsulated
  header portion of a message to identify the type
  of processing performed on the transmitted
  message.

29
Certificates are central to the key management
architecture for X.509 and PEM.

• Including
• version
• facilitates orderly changes in certificate
  formats over time. The initial version number
  for certificates used in PEM is the X.509 default
  which has a value of zero (0), indicating the
  1988 version.
• serial number
• a short form, unique identifier for each
  certificate generated by an issuer. An issuer
  must ensure that no two distinct certificates
  with the same issuer DN contain the same serial
  number.
• signature (algorithm ID and parameters)
• the algorithm used by the issuer to sign the
  certificate, and any parameters associated with
  the algorithm
• issuer name
• representation of its issuer's identity, in the
  form of a Distinguished Name.
• validity period
• date and time indications of the start and end
  time period over which a certificate is intended
  to be used.
• subject name
• representation of its subject's identity in the
  form of a Distinguished Name (DN)
• subject public key (and associated algorithm ID)
• the public component of its associated subject,
  as well as an indication of the algorithm

30
The use of Certificates

• asymmetric key management architecture
• binds an entity's public key component to a
  representation of the entity's identity
• A certificate's issuing authority signs the
  certificate, vouching for the correspondence
  between the entity's identity, attributes, and
  associated public key component.
• Once signed, certificate copies may be posted on
  multiple servers

31
Certificates cont.

• allows privacy-enhanced mail to be sent between
  an originator and a recipient without prior
  placement of a pairwise key
• authority-applied signature make it unnecessary
  to be concerned about the prospect that servers,
  or other entities, could undetectably modify
  certificate contents
• Certificates must be certified by IPRA

32
Certificate Syntax The X.509 certificate
format is defined by the following ASN.1
syntax Certificate SIGNED SEQUENCE
version 0 Version DEFAULT v1988,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo
Version INTEGER v1988(0)
CertificateSerialNumber INTEGER
Validity SEQUENCE notBefore
UTCTime, notAfter
UTCTime SubjectPublicKeyInfo
SEQUENCE algorithm
AlgorithmIdentifier, subjectPublicKey
BIT STRING AlgorithmIdentifier
SEQUENCE algorithm OBJECT
IDENTIFIER, parameters ANY
DEFINED BY algorithm OPTIONAL
33
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type 4,ENCRYPTED Content-Domain RFC822
DEK-Info DES-CBC,BFF968AA74691AC1
Originator-Certificate MIIBlTCCAScCAWUwDQYJKo
ZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEw
ZCZXRhIDExDzAN BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQ
xODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cm
l0eSwgSW5jLjEU MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTA
KBgRVCAEBAgICAANLADBIAkEAwHZHl7i
yJcqDtjJCowzTdBJrdAiLAnSCCnnjOJELyuQiBgkGrgIh3j8/
x0fMYrsyF1u3F LZPVtzlndhYFJQIDAQABMA0GCSqGSIb
3DQEBAgUAA1kACKr0PqphJYw1jYPtcIq
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs
2wfX5byMp2X3U/ 5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUg
N4w Key-Info RSA, I3rRIGXUGWAF8js5wCzRTkd
hO34PTHdRZY9Tuvm03MNM7fx6qc5udixps2Lng0
wGrtiUm/ovtKdinz6ZQ/aQ Issuer-Certificate
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEB
hMCVVMxIDAeBgNV BAoTF1JTQSBEYXRhIFNlY3VyaXR5LC
BJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMD
c1OTU5WjBRMQsw CQYDVQQGEwJVUzEgMB4GA1UEChMXUlN
BIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQ
gBAQICArwDYgAw XwJYCsnp6lQCxYykNlODwutF/jMJ3kL
3PjYyHOwk/9rLg6X65B/LD4bJHtO5XW
cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoPDkZ8k1gCk
7hQHpbIwIDAQAB MA0GCSqGSIb3DQEBAgUAA38AAICPv4f
9Gx/tY4p4DB7MVtKZnvBoy8zgoMGOx
dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7C
MxpUWRBcXUpEx EREZd932ofGBIXaialnOgVUn0OzSY
gugiQ077nJLDUj0hQehCizEs5wUJ35a5h MIC-Info
RSA-MD5,RSA, UdFJR8u/TIGhfH65ieewe2lOW4tooa3vZ
CvVNGBZirf/7nrgzWDABz8w9NsXSexv
AjRFbHoNPzBuxwmOAFeA0HJszL4yBvhG
Recipient-ID-Asymmetric MFExCzAJBgNVBAYTAlVTM
SAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk,
66 Key-Info RSA, O6BS1ww9CTyHPtS3bMLDL0
hejdvX6Qv1HK2ds2sQPEaXhX8EhvVphHYTjwekdWv
7x0Z3Jx2vTAhOYHMcqqCjA qeWlj/YJ2Uf5ng9yznPbtD
0mYloSwIuV9FRYxgzY8iXd/NQrXHfi6/MhPfPF3d
jIqCJAxvld2xgqQimUzoS1a4r7kQQ5c/Iua4LqKeq3ciFzEv/M
bZhA -----END PRIVACY-ENHANCED MESSAGE-----
Example Encapsulated ENCRYPTED Message
(Asymmetric Case)
Figure 3 Figure 3 illustrates an example
encapsulated ENCRYPTED message in which
asymmetric key management is used.