n Email Security PGP SMIME n Certificates and

n. E-mail Security –PGP, S/MIME n. Certificates and PKI 1

E-mail Security n E-mail is one of the most widely used network services – One of the old killer applications of the Internet n Normally message contents not secured – Can be read/modified either in transit or at destination by the attacker n E-mail service is like postcard service – just pick it and read it 2

Email Security Enhancements n confidentiality – protection from disclosure n authentication – of sender of message n message integrity – protection from modification n non-repudiation of origin – protection from denial by sender 3

Pretty Good Privacy (PGP) n widely used secure e-mail software – originally a file encryption/decryption facility n developed by Phil Zimmermann – a security activist who has had legal problems due to PGP best available crypto algorithms are employed n available on several platforms with source code n originally free, now commercial versions exist n not controlled by a standardization body n – although there are RFCs 4

PGP Mechanisms n Digital Signatures (and consequently message authentication and integrity) – RSA, DSS, and others n Message Encryption – CAST, IDEA, 3 DES, AES, etc. (all at least 128 bits) – symmetric keys are used once and encrypted using RSA or El. Gamal (based on discrete logs) Compression using ZIP n Radix-64 conversion (to ASCII) n – for e-mail compatibility 5

PGP Operation – Digital Signatures n Classical application of public key crypto – This figure is actually for RSA – for DSA refer to previous lectures Z is zip function n radix-64 conversion is done after zip at sender, before Z-1 at receiver n – may be done only for signature or for the whole message 6

PGP Operation – Confidentiality E[PUb, Ks] n One-time session key, Ks – generated at random – encrypted using a public key cryptosystem, EP • RSA or El. Gamal n Message is compressed before encryption – This is the default case 7

PGP Operation – Confidentiality and Authentication n 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 8

PGP Operation – radix-64 conversion Encrypted text and signatures create binary output n however email was designed only for text – hence PGP must encode raw binary data into printable ASCII characters n uses radix-64 algorithm (See CS 408 notes) – maps 3 bytes to 4 printable chars n 9

PGP Operation – Summary 10

PGP Key ID concept n since a user may have many public/private keys in use, there is a need to identify which is actually used to encrypt the 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) n Key IDs are used in signatures too – key ID for the public key corresponding to the private key used for signature n Key IDs are sent together with messages 11

PGP Key Rings n 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 * Key ID, Used ID combination uniquely identifies a key 12

PGP Key Rings n private-key ring contains the public/private key pair(s) for this user, n private keys are encrypted using a key derived from a hashed passphrase * Key ID, Used ID combination uniquely identifies a key 13

Key rings and message generation 14

Key rings and message reception 15

PGP Key Management - 1 n From PGP documentation: “This whole business of protecting public keys from tampering is the most difficult problem in practical public key applications” n 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 16

PGP Key Management - 2 n 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 n 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 17 – “web of trust”

PGP Key Management - 3 n A trusted signature on a public key means that – the key really belongs to its owner n 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 n Keys and signatures on them are generally obtained from PGP public keyservers n – there might be several signatures on a single key 18

PGP Key Management - 4 A public key ring owned by “you” These are assigned by you This is calculated 19

S/MIME n n n 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 n S/MIME handles digital signatures – Also provides encryption 20

Quick E-mail History n SMTP and RFC 822 (later RFC 5322) – SMTP is the email transfer protocol running over TCP – RFC 822/5322 defines the message format and headers • only ASCII messages (7 -bit) n MIME (Multipurpose Internet Mail Extensions) – content type • Almost any type of information can appear in an email message – transfer encoding • specifies how the message body is encoded into textual form (radix 64 is common) n S/MIME: Secure MIME – new content types, like signature, encrypted data 21

More on Internet Email Architecture 22

More on MIME n Multipurpose Internet Mail Extensions – Addresses the limitations of SMTP/5322 scheme • Most important one: binary data transfer • Attachments n Adds some fields to the email messages: Important ones: – Content-Type • Describes the data contained in the body with sufficient detail that the receiving user agent can pick an appropriate agent or mechanism to represent the data to the user – Content-Transfer-Encoding • Indicates the type of transformation that has been used to represent the body of the message in a way that is acceptable for mail transport 23

MIME Content Types (Table is on page 602 in textbook) 24

MIME Transfer Encodings (Table is on page 605 in textbook) 25

S/MIME Functions n enveloped data – encrypted content and associated keys n signed data – encoded message + encoded signed message digest (hash) n clear-signed data – cleartext message + encoded signed message digest (hash) n signed and enveloped data – Nested signed and encrypted entities 26

S/MIME Cryptographic Algorithms hash functions: switched to SHA 256 n digital signatures: Mostly RSA is used n session key encryption: Mostly RSA is used n message encryption: Triple-DES, AES and others, but AES-128 is preferred n Base 64 (radix 64) encoding is used for email compatibility (ASCII conversion) n sender should know the capabilities of the receiving entity (public announcement or previously received messages from receiver) n – otherwise sender takes a risk of sending unintelligible e-mail. 27

S/MIME Security Functionality: Simplified View 28

Scope of S/MIME Security n 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 n This message and other security related data (algorithm identifiers, certificates, etc. ) are processed by S/MIME n and packed as one of the S/MIME content type n 29

S/MIME Content Types 30

Enveloped. Data For message encryption n Similar to PGP n – create a random session key, encrypt the message with that key and a conventional crypto, encrypt the session key with recipient’s public key n Unlike PGP, recipient’s public key comes from an X. 509 certificate – trust management is different 31

Signed. Data n 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 n Similar to PGP – first message is hashed, then the hash is encrypted using sender’s private key n Message, signature, identifiers of algorithms and the sender’s certificate are packed together – again difference between S/MIME and PGP in trust management 32

Clear Signing n 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 n multipart/signed content type – 2 parts • Clear text message • Signature – Let’s see an example 33

S/MIME Certificate Processing n S/MIME uses X. 509 v 3 certificates – Certification Authorities (CAs) issue certificates – unlike PGP, a user cannot be a CA n each client has a list of trusted CA certificates – actually that list comes with e-mail client software or OS n and own public/private key pairs and certs n It is very hard for an average user to maintain the list of trusted CAs – Generally OS and/or email client software default trusted CA certificate lists are directly used. – So trust management is not user-centric in practice 34

S/MIME Certificate Processing and CAs One should obtain a certificate from a CA in order to send signed messages n Certificates classes (common practice by most CAs) n – Class 1 – Class 2 – Class 3 n Stronger identity validation Easier to issue CA certification policies (Certificate Practice Statement) – ID-control practices • Class 1: only email address check • Class 2: class 1 + against third party database / fax documents • Class 3: class 1 + apply in person and submit picture IDs and/or paper documents 35

X. 509 Certificates and PKIs n 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) 36

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

Certificates 38

Certificates n Certificates are verified by the verifiers to find out correct public key of the target entity n Certificate verification is the verification of the signature on certificate n In order to verify a certificate, the verifier – must know the public key of the CA – must trust the CA 39

Certificates CA Certified Entity Albert Levi Verifier 40

Issues Related Certificates n 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 paper-based documentation 41

Issues Related Certificates n TRUST – verifiers must trust CAs – CAs need not trust the certified entities – certified entities need not trust its CA n What is “trust” in certification systems? – Answer to the question: “How correct is the certificate information? ” – related to certification policies 42

Issues Related Certificates n Certificate types – ID certificates • discussed here – authorization certificates • no identity • binding between public key and authorization info n Certificate storage and distribution – along with a signed message – distributed/centralized databases 43

Issues Related Certificates n 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 44

Real World Analogies n Is a certificate an “electronic identity”? n 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 else’s certificate – one must submit its certificate to identify itself, but submission is not sufficient, the key must be used in a protocol 45

Real World Analogies n Result: Certificates are not picture IDs n So, what is the real world analogy for certificates? – Endorsed document/card that serves as a binding between the identity and signature 46

Public Key Infrastructure (PKI) n PKI is a complete system and welldefined mechanisms for certificates – certificate issuance – certificate revocation – certificate storage – certificate distribution 47

PKI n Business Practice: Issue certificates and make money – several CAs n Several CAs are also necessary due to political, geographical and trust reasons n 3 interconnection models – hierarchical – cross certificates – hybrid 48

Hierarchical PKI Example Root CA Upper level CAs End users 49

Cross Certificate Based PKI Example CAs End users Cross certificates 50

Hybrid PKI example 51

Certificate Paths 52

Certificate Paths n Verifier must know public key of the first CA n Other public keys are found out one by one n All CAs on the path must be trusted by the verifier 53

Certificate Paths with Reverse Certificates Reverse certificates 54

Organization-wide PKI n Local PKI for organizations – may have global connections, but the registration facilities remain local – generally to solve local problems • local secure access to resources 55

Organization-wide PKI Server Certificate Processor/Authority CP (CA) Databases / Directories Administration Registration Authority Certificate Distribution CD RA PKI Client Architecture of a typical organization-wide PKI 56

Hosted vs. Standalone PKI n Hosted (outsourced) PKI – PKI vendor acts as CA – PKI owner is the RA n Standalone PKI – PKI owner is both RA and CA 57

Hosted vs. Standalone PKI 58

X. 509 n ITU-T standard (recommendation) – ISO 9495 -2 is the equivalent ISO standard n 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 59

X. 509 n Defines identity certificates – attribute (authorization) certificates are added in 4 th edition (2000) n Defines certificate structure, not PKI n Supports both hierarchical model and cross certificates n End users cannot be CAs 60

X. 509 Certificate Format 61

X. 509 v 3 Extensions n Not enough flexibility in X. 509 v 1 and v 2 – 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 v 1 and v 2) • avoidance of blind trust was not possible in v 1 and v 2 n Rather than explicitly naming new fields a general extension method is defined – An extension consists of an extension identifier, value and criticality indicator 62

n X. 509 v 3 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 n Certificate path constraints n – For CA certs and to restrict certificate issuance based on • path length (restricting number of subordinate CAs) • policy identifiers • names n Verifier could exercise its own restrictions during verification as well – No blind trust to CAs 63

Domain. Keys Identified Mail (DKIM) n Started as an industrial effort but later defined in RFC 6376 – Adopted widely by a range of e-mail providers and Internet Service Providers (ISPs) n Basically, signing the emails. – But not by the sender; but by the sending mail server – Similarly, the verifier is not the recipient user, but the receiving mail server. – So not end-to-end, but between sending MTA and receiving MTA (or agents on behalf of the MTAs) n By signing an email, – The sending domain (via its MTA or its agent) claim responsibility for the email – it says “my server is sending it” – Thwarts server-spoofing attacks cryptographically – But it does not provide any proof about the individual who wrote the email n Public-private key pairs belong to the domains – Public keys are stored as DNS records n Receiving domain (via its MTA or its agent) verifies the signature before passing the email to the ultimate recipient. – Public key of the sender is obtained via a DNS query 64

65

Sender Policy Framework (SPF) n Current email infrastructure allows to use any domain name while sending during SMTP messaging and in the email header. – This is the problem that SPF addresses S: 220 foo. com Simple Mail Transfer Service Ready C: HELO mta. example. net S: 250 OK C: MAIL FROM: <alice@example. org> S: 250 OK C: RCPT TO: <Jones@foo. com> S: 250 OK C: DATA S: 354 Start mail input; end with <CRLF> C: To: bob@foo. com C: From: alice. sender@example. net C: Date: Today C: Subject: Meeting Today. . . No domain name check is done 66

Sender Policy Framework (SPF) SPF is the standardized way for a sending domain to identify and assert the mail senders for that domain n RFC 7208 defines the SPF n – Domain admins can authorize hosts to use their domain names in “MAIL FROM” or “HELLO” identities during SMTP transactions n SPF works by checking a sender’s IP address against the policy encoded in any SPF record found at the sending domain DNS records – This means that SPF checks can be applied before the message content is received from the sender (from: field in the message header is not checked) n SPF policies are stored in TXT type DNS resource records (SPF TXT RR) 67

SPF on the Sender Side n Basically formation of the policy and adding it to DNS of the sender’s domain – Sending domain identifies all the allowed senders – Creates a policy using SPF syntax and adds to DNS SPF policy is made of “SPF Mechanisms” and “Mechanism Modifiers” n SPF mechanisms n – IP addresses (v 4 or v 6): a list or a range (mostly to allow as sender) – MX: to allow the mail servers registered at DNS of that domain as legitimate senders. – include: a domain name proceeds “include” and generally this mechanism is used to check other domain’s SPF policies for allowed senders. Generally it is used when the email service is outsourced (e. g. to Microsoft or Google) – all: all others n SPF Mechanism Modifiers + mechanism allowed (default one, so if no modifier mentioned, it is +) - mechanism not allowed ~ soft fail: mechanism allowed but marked as suspicious; triggers extra checks ? neutral: SPF does not say anything, system’s default is applied (mostly +) 68

SPF Policy Examples (not in the book) n v=spf 1 include: spf. protection. outlook. com –all q “v=spf 1” means spf version 1; not so important q There is a default + before “include” that means the same policy could have been written as: v=spf 1 +include: spf. protection. outlook. com –all q include: spf. protection. outlook. com means check Microsoft for the SPF policies; I do not know any q –all means reject the rest n v=spf 1 mx ip 4: 67. 138. 237. 135 include: spf. protection. outlook. com -all mx (could also be written as +mx ) means the mail servers in the DNS are allowed A particular IP address (67. 138. 237. 135) is allowed The rest is the same as previous example 69

SPF Policy Examples (not in the book) n Sabancı University’s SPF policy as of April 25, 2019. v=spf 1 ip 4: 193. 255. 135. 0/23 ip 4: 64. 18. 0. 0/20 ip 4: 74. 125. 148. 0/22 ip 4: 74. 125. 244. 0/22 ip 4: 207. 126. 144. 0/20 include: _spf. google. com ~all – A couple of IP address ranges are allowed (CIDR notation) – Otherwise, google. com’s spf records must be checked – Otherwise soft fail; i. e. accept but mark as suspicious to trigger some other checks (beyond the scope of SPF) 70

SPF on the Receiver Side n Receiver first gets the IP address of the sender (TCP connection) n Locates SPF policies for the domains listed as HELO and MAIL FROM identities n If the IP address is allowed for the domains as senders than SMTP continues with mail content transfer – Otherwise, stops 71

73