Internet Security Enhanced Security Services for S/MIME Thomas - - PowerPoint PPT Presentation

▶
internet security
SMART_READER_LITE
LIVE PREVIEW

Internet Security Enhanced Security Services for S/MIME Thomas - - PowerPoint PPT Presentation

May 24, 2023 211 likes •960 views

Internet Security Enhanced Security Services for S/MIME Thomas Gttlicher April 20, 2004 Agenda Basics Technical Signed receipts Security labels Secure mailing lists Signed certificates 1 Basics Basics

slide-1
SLIDE 1

Internet Security

Enhanced Security Services for S/MIME

Thomas Göttlicher

April 20, 2004

slide-2
SLIDE 2

Agenda

  • Basics
  • Technical
  • Signed receipts
  • Security labels
  • Secure mailing lists
  • Signed certificates
slide-3
SLIDE 3

1Basics

slide-4
SLIDE 4

Basics

  • S/MIME = Secure MIME
  • protect MIME e-mail
slide-5
SLIDE 5

Basics

  • S/MIME = Secure MIME
  • protect MIME e-mail
text Excel sheet Word document text

MIME e-mail

slide-6
SLIDE 6

Basics

  • S/MIME = Secure MIME
  • protect MIME e-mail
text Excel sheet Word document text

signed S/MIME e-mail

S/MIME digital signature
slide-7
SLIDE 7

Basics

  • S/MIME = Secure MIME
  • protect MIME e-mail
text S/MIME encrypted envelope Excel sheet Word document text

encrypted S/MIME e-mail

slide-8
SLIDE 8

2Technical

  • Internet Layer
  • Compatibility
  • Triple Wrapping
slide-9
SLIDE 9

Internet Layer

application layer transport layer network layer link layer physical layer S/MIME
slide-10
SLIDE 10

Compatibility

  • S/MIME v3 can read messages from S/MIME v2
  • BUT: S/MIME v3 messages are unreadable by S/MIME v2
slide-11
SLIDE 11

Triple Wrapping

  • Message has been signed, encrypted and signed again
  • Inside signature: content integrity
  • Encrypted body: confidentiality
  • Outside signature: integrity for information produced hop-by-hop
slide-12
SLIDE 12

Triple Wrapping (continued)

Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=outerboundary
  • -outerboundary
Content-type: application/pkcs7-mime; smime-type=enveloped-data Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=innerboundary
  • -innerboundary
Content-type: text/plain Original content
  • -innerboundary
Content-type: application/pkcs7-signature inner SignedData block (eContent is missing)
  • -innerboundary--
  • -outerboundary
Content-type: application/pkcs7-signature
  • uter SignedData block (eContent is missing)
  • -outerboundary--
slide-13
SLIDE 13

Triple Wrapping (continued)

Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=outerboundary
  • -outerboundary
Content-type: application/pkcs7-mime; smime-type=enveloped-data Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=innerboundary
  • -innerboundary
Content-type: text/plain Original content
  • -innerboundary
Content-type: application/pkcs7-signature inner SignedData block (eContent is missing)
  • -innerboundary--
  • -outerboundary
Content-type: application/pkcs7-signature
  • uter SignedData block (eContent is missing)
  • -outerboundary--
  • uter signature computed over
inner signature computed over encrypted data
slide-14
SLIDE 14

3 Signed Receipts

slide-15
SLIDE 15

Signed Receipts

  • Proof of delivery of a message
  • Before processing a receipt-request: the receiving agent must verify the
signature => no receipt if signature is invalid
  • Receiving user agent software should automatically create a signed
receipt when requested
slide-16
SLIDE 16

Signed Receipts (Example) A B

slide-17
SLIDE 17

Signed Receipts (Example) A B

slide-18
SLIDE 18

Signed Receipts (Example) A B

slide-19
SLIDE 19

Signed Receipts (continued)

  • Receipts can be requested from
– all recipients
slide-20
SLIDE 20

Signed Receipts (Example) A C B D

slide-21
SLIDE 21

Signed Receipts (Example) A C B D

slide-22
SLIDE 22

Signed Receipts (Example) A C B D

slide-23
SLIDE 23

Signed Receipts (continued)

  • Receipts can be requested from
– all recipients – a specific list of recipients
slide-24
SLIDE 24

Signed Receipts (Example) A C B D

slide-25
SLIDE 25

Signed Receipts (Example) A C B D

slide-26
SLIDE 26

Signed Receipts (Example) A C B D

slide-27
SLIDE 27

Signed Receipts (continued)

  • Receipts can be requested from
– all recipients – a specific list of recipients – first tier (= recipients that did not receive the message as members of a mailing list)
slide-28
SLIDE 28

Signed Receipts (Example) A C B Mail List

slide-29
SLIDE 29

Signed Receipts (Example) A C B Mail List

slide-30
SLIDE 30

Signed Receipts (Example) A C B Mail List

slide-31
SLIDE 31

Signed Receipts (continued)

  • Receipts can be requested from
– all recipients – a specific list of recipients – first tier (= recipients that did not receive the message as members of a mailing list)
  • Sender can indicate that receipts be sent to many places
– receipt not just to the sender
slide-32
SLIDE 32

Signed Receipts (Example) A B

slide-33
SLIDE 33

Signed Receipts (Example) A B

slide-34
SLIDE 34

Signed Receipts (Example) A B

slide-35
SLIDE 35

Signed Receipts (continued)

  • Receipts can be requested from
– all recipients – a specific list of recipients – first tier (= recipients that did not receive the message as members of a mailing list)
  • Sender can indicate that receipts be sent to many places
– receipt not just to the sender – not even to the sender
slide-36
SLIDE 36

Signed Receipts (Example) A B

slide-37
SLIDE 37

Signed Receipts (Example) A B

slide-38
SLIDE 38

Signed Receipts (Example) A B

slide-39
SLIDE 39

Signed Receipts (continued)

  • Receipts can be requested from
– all recipients – a specific list of recipients – first tier (= recipients that did not receive the message as members of a mailing list)
  • Sender can indicate that receipts be sent to many places
– receipt not just to the sender – not even to the sender
  • Multiple Receipt Requests: Each recipient should only return one receipt
  • No singed receipt for a signed receipt
slide-40
SLIDE 40

4 Security Labels

slide-41
SLIDE 41

Security Labels

  • Set of security information regarding the sensitivity of the content that is
protected by S/MIME encapsulation
  • Access control: receiving agent examines the security labels and
determines whether or not the recipient is allowed to see the contents
  • Security Labels must be signed attributes
  • Signature must be verified and valid, before processing a security label
  • Classification: unmarked, unclassified, restricted, confidential, secret,
top-secret; other values can be defined by any organization
slide-42
SLIDE 42

Security Labels (Example) A B

slide-43
SLIDE 43

Security Labels (Example) A B

slide-44
SLIDE 44

Security Labels (Example) A B

slide-45
SLIDE 45

Security Labels (Example) A B

slide-46
SLIDE 46

Equivalent Security Labels

  • Organizations are allowed to define their own security policies, many
different security policies will exist => Equivalences between different security policies of different
  • rganizations
  • Receiving agents have the option to process EquivalentLabels attributes
  • Receiving agent processes equivalent labels only if it trusts the signer
  • If the receiving agent understands the security label, it must ignore all
equivalent labels
slide-47
SLIDE 47

Security Labels (Example) A B

slide-48
SLIDE 48

Security Labels (Example) A B

slide-49
SLIDE 49

Security Labels (Example) A B

"unmarked" ⇒ "anyone"
slide-50
SLIDE 50

Security Labels (Example) A B

slide-51
SLIDE 51

Security Labels (Example) A B

slide-52
SLIDE 52

5 Secure Mailing Lists

  • Mail List Management
  • Mail Loops
  • Receipts
slide-53
SLIDE 53

Mail List Management

  • Sending agents must create recipient-specific data structures for each
recipient of an encrypted message.
  • Large number of recipients => resources needs
  • Mail List Agents (MLA) can take a singe message and perform the
recipient-specific encryption
slide-54
SLIDE 54

Mail List Management - Mail Loops

  • One mailing list is member of a second and the second is member of the
first.
  • MLA have to prevent Mail loops
– Each Time a MLA expands a message it adds its own identifier to the history – If own unique identifier is in the history => Mail loop
  • Don't send the message to the list again
  • Warning to a human mail list administrator
slide-55
SLIDE 55

Mail List Management - Mail Loops (Example) A MLA1 MLA2

slide-56
SLIDE 56

Mail List Management - Mail Loops (Example) A MLA1 MLA2

expanded by MLA1
slide-57
SLIDE 57

Mail List Management - Mail Loops (Example) A MLA1 MLA2

expanded by MLA1 expanded by MLA2
slide-58
SLIDE 58

Mail List Management - Mail Loops (Example) A MLA1 MLA2

expanded by MLA1 expanded by MLA2
slide-59
SLIDE 59

Mail List Management - Mail Loops (Example) A MLA1 MLA2 Admin

slide-60
SLIDE 60

Mail List Management - Receipts

  • Mail List Agent Signed Receipt Policy Processing
– A MLA often needs to propagate forward the receipt policy – Any MLA adds "insteadOf", "inAdditionTo", "none" to the history – Only last recipient needs to process
  • No receipt, if originator has not requested
  • If originator has requested, but MLA supersedes request: MLA may
inform the originator
slide-61
SLIDE 61

Mail List Management - Receipts (Example) X A B

receipts to: X
slide-62
SLIDE 62

Mail List Management - Receipts (Example) X A B

receipts to: X

A's Policy: insteadOf: A

slide-63
SLIDE 63

Mail List Management - Receipts (Example) X A B

receipts to: X receipts to: A

A's Policy: insteadOf: A

slide-64
SLIDE 64

Mail List Management - Receipts (Example) X A B

receipts to: X receipts to: A

A's Policy: insteadOf: A B's Policy: none

slide-65
SLIDE 65

Mail List Management - Receipts (Example) X A B

receipts to: X receipts to: A

A's Policy: insteadOf: A B's Policy: none

receipts to: -
slide-66
SLIDE 66

Mail List Management - Receipts (Example) X A B

receipts to: X receipts to: A

A's Policy: insteadOf: A B's Policy: none

receipts to: -
slide-67
SLIDE 67

6 Signed Certificates

  • Attacks
  • Responses
slide-68
SLIDE 68

Signing Certificate - Attacks

  • Substitution Attack
– Simple substitution of one certificate for a another – issuer and serial number in the SignerInfo is modified to refer to a new certificate
  • DoS-Attack where an invalid certificate is substituted for the valid
=> message is unverifiable, as the public key no longer matches the public key used to sign
  • Substitution of one valid certificate for the original valid certificate
where the public keys match => Message is validated under different constraints the
  • riginator intended
slide-69
SLIDE 69

Signing Certificate - Attacks (continued)

  • Reissue of Certificate Attack
– Attack deals with a certificate authority (CA) re-issuing the signing certificate – may become more frequent as CA reissue their own root certificates
  • Duplicate CA Attack
– Setting up a CA that attempts to duplicate an existing CA – Issue a new certificate with the same public keys as the signer used
slide-70
SLIDE 70

Signing Certificate - Responses

  • Substitution Response
– DoS cannot be prevented – No way to automatically identify the attack because it is indistinguishable from a message corruption. – No practical way to prevent users from getting new certificates with the same public key.
  • Reissue of Certificate Response
– A CA should never reissue a certificate with different attributes
  • Duplicate CA Response
– Only way: Never trust a duplicate CA
slide-71
SLIDE 71

7 Conclusion

  • Security Considerations
slide-72
SLIDE 72

Security Considerations

  • Mailing lists
– Mailing lists that encrypt their content my be targets for DoS-Attacks if they to not prevent Mail-Loops. Using simple RFC822-Header spoofing it is easy to subscribe on encrypted mailing list to another, thereby setting up an infinity loop. – Ciphertext Attacks: MLAs should notify an admin if a large number of undecryptable messages are receives
slide-73
SLIDE 73

Security Considerations (continued)

  • Signed Receipts
– Recipient must not send back a reply if it cannot validate the signature. – Senders should encrypt receipts to prevent a passive attacker from gleaning information
  • Security Labels
– Senders must not rely on recipients' processing software to correctly process security labels
  • some S/MIME clients may not understand security labels but
display a labeled message
  • Error response sent to originator and that error bounces back
=> unlike that the bounce message will have a proper security label
slide-74
SLIDE 74

Details: RFC 2634