第八講電子郵件安全提綱PGPS/MIMEDKIMEmailSecurityemailisoneofthemostwidelyusedandregardednetworkservicescurrentlymessagecontentsarenotsecuremaybeinspectedeitherintransitorbysuitablyprivilegedusersondestinationsystemEmailSecurityEnhancementsconfidentialityprotectionfromdisclosureauthenticationofsenderofmessagemessageintegrityprotectionfrommodificationnon-repudiationoforiginprotectionfromdenialbysenderPrettyGoodPrivacy(PGP)widelyuseddefactosecureemaildevelopedbyPhilZimmermannselectedbestavailablecryptoalgstouseRSADSSDiffie-HellmanCAST-128IDEA3DESSHA-1integratedintoasingleprogramonUnix,PC,Macintoshandothersystemsoriginallyfree,nowalsohavecommercialversionsavailableRFC3156PGPOperation–AuthenticationsendercreatesmessagemakeSHA-1160-bithashofmessageattachedRSAsignedhashtomessagereceiverdecrypts&recovershashcodereceiververifiesreceivedmessagehashPGPOperation–Confidentialitysenderforms128-bitrandomsessionkeyencryptsmessagewithsessionkeyattachessessionkeyencryptedwithRSAreceiverdecrypts&recoverssessionkeysessionkeyisusedtodecryptmessageE(PUb,KPRS)PGPOperation–Confidentiality&Authenticationcanusebothservicesonsamemessagecreatesignature&attachtomessageencryptbothmessage&signatureattachRSA/ElGamalencryptedsessionkeyPGPOperation–CompressionbydefaultPGPcompressesmessageaftersigningbutbeforeencryptingsocanstoreuncompressedmessage&signatureforlaterverification&becausecompressionisnondeterministicusesZIPcompressionalgorithmPGPOperation–EmailCompatibilitywhenusingPGPwillhavebinarydatatosend(encryptedmessageetc)howeveremailwasdesignedonlyfortexthencePGPmustencoderawbinarydataintoprintableASCIIcharactersusesradix-64algorithmmaps3bytesto4printablecharsalsoappendsaCRCPGPalsosegmentsmessagesiftoobigPGPOperation–SummaryPGPSessionKeysneedasessionkeyforeachmessageofvaryingsizes:56-bitDES,128-bitCASTorIDEA,168-bitTriple-DESgeneratedusingANSIX12.17modeusesrandominputstakenfromprevioususesandfromkeystroketimingofuserPGPPublic&PrivateKeyssincemanypublic/privatekeysmaybeinuse,needtoidentifywhichisactuallyusedtoencryptsessionkeyinamessagecouldsendfullpublic-keywitheverymessagebutthisisinefficientratheruseakeyidentifierbasedonkeyisleastsignificant64-bitsofthekeywillverylikelybeuniquealsousekeyIDinsignatures用戶ID和密鑰ID組合可以唯一標識密鑰PGPMessageFormatPGPKeyRings（PGP中公私鑰的保存）eachPGPuserhasapairofkeyrings:public-keyringcontainsallthepublic-keysofotherPGPusersknowntothisuser,indexedbykeyID保存其他PGP用戶的公鑰private-keyringcontainsthepublic/privatekeypair(s)forthisuser,indexedbykeyID&encryptedkeyedfromahashedpassphrase

保存該用戶的公鑰/私鑰對securityofprivatekeysthusdependsonthepass-phrasesecurity

用戶在生成公鑰/私鑰后，向用戶詢問口令，使用SHA-1為口令生成160位的散列碼，使用CAST-128，以散列碼為密鑰加密私鑰。存儲在私鑰環中。當使用時，需要用戶提供口令，解密私鑰PGPKeyRingsPGPMessageGenerationPGPMessageReceptionPGPKeyManagementratherthanrelyingoncertificateauthoritiesinPGPeveryuserisownCAcansignkeysforuserstheyknowdirectlyformsa“weboftrust”基于Web的信任trustkeyshavesignedcantrustkeysothershavesignedifhaveachainofsignaturestothemkeyringincludestrustindicatorsuserscanalsorevoketheirkeys

所有者需簽發一個密鑰撤銷證書，用相應的私鑰簽名該證書。盡快廣泛散發該證書PGPTrustModelExample密鑰合法與信任密鑰持有者的簽名是分離的。如果密鑰被一個完全信任的簽名者或者被兩個部分信任的簽名者簽名，被認為該密鑰合法，但可能在簽名其他密鑰時不被信任。S是孤立點，只有當完全信任其簽名者才能使其合法多用途網際郵件擴展——MIMEMIME概覽MultipleInternetMailExtension，多用途網際郵件擴展MIME是對RFC5322框架的擴展，在RFC1426（SMTP8-bitMIME傳輸服務擴展）的支持下，解決了SMTP/5322方案的缺陷MIME的新特性增加了5個新的消息頭域（headerfield）MIME-Version ——MIME版本Content-Type ——郵件容納物的類型Content-Transfer-Encoding ——郵件容納物的傳輸編碼方式Content-ID ——郵件容納物的編號Content-Description ——郵件容納物的描述定義了多種郵件容納物數據類型，對多媒體電子郵件進行支持7種類型，15種子類型，定義了多種傳輸編碼方式6種傳輸編碼，在Content-Transfer-Encoding多用途網際郵件擴展——MIMEMIME增加的5種消息頭域MIME版本（MIME-Version）參數一般為1.0，表示消息符合RFC2045和RFC2046的規定

郵件容納物標識（Content-ID）用來標識不同的郵件容納物可選郵件容納物描述（Content-Description）對消息體中被傳輸的數據對象進行描述的自由文本可選多用途網際郵件擴展——MIMEMIME增加的5種消息頭域郵件容納物類型（Content-Type）向接收方指明消息體的中數據的類型7種類型，15種子類型（課本）Text、Multipart、Message、Image、Video、Audio、Application需要說明的是，隨著互聯網的發展，會出現很多新的子類型。IANA（TheInternetAssignedNumbersAuthority，互聯網數字分配機構）負責確認新的郵件容納物子類型，已出現但未確認的子類型前加x，如application/x-gzip等。Multipart類型最復雜，包含多個不同類型的獨立子部分每個子部分也有其自身的類型各個子部分由邊界標志分隔開初始及中間分隔符 --boundary最終分隔符 --boundary--類型（Type）子類型（Subtype）說明（Description）TextPlain普通文本，ASCII或ISO8859編碼Enriched提供了更多的可選格式MultipartMixed各部分相互獨立，共同發送，有順序Parallel各部分相互獨立，共同發送，無順序Alternative同一段信息的不同版本，目的是提高接收方的用戶體驗Digest與Mixed子類型相同，但每個部分的缺省類型是message/rfc822Messagerfc822遵循rfc822標準的封裝好的消息Partial用于將大的message分解為碎片。每個碎片有id及順序碼；有碎片總數。External-body包含一個指向別處對象的指針Imagejpegjpeg格式圖像gifgif格式圖像Videompegmpeg格式視頻AudioBasic單軌8比特ISDNmu-law編碼，采樣率8kHzApplicationPostScriptAdobePostScript格式octet-stream由8位字節構成的二進制數據塊MIME消息舉例S/MIME(Secure/MultipurposeInternetMailExtensions)securityenhancementtoMIMEemailoriginalInternetRFC822emailwastextonlyMIMEprovidedsupportforvaryingcontenttypesandmulti-partmessageswithencodingofbinarydatatotextualformS/MIMEaddedsecurityenhancementshaveS/MIMEsupportinmanymailagentsegMSOutlook,Mozilla,MacMailetc與PGP功能相似，提供簽名和加密消息的能力。S/MIME側重于適合商業和團體使用的工業標準，PGP則仍然維持為許多用戶提供個人電子郵件的安全性S/MIMEFunctionsenvelopeddata封裝數據encryptedcontentandassociatedkeys包含用會話密鑰加密的數據內容和用接收方公鑰加密的會話密鑰（例p202）signeddata簽名數據encodedmessage+signeddigest包含用Base64編碼的信息和簽名者私鑰簽名的摘要（例p203）

Base64（數據內容+經過簽名的摘要）clear-signeddata透明簽名數據cleartextmessage+encodedsigneddigest對MIME消息簽名，但只對簽名進行base64編碼數據內容+Base64（經過簽名的摘要）signed&envelopeddata簽名并封裝數據nestingofsigned&encryptedentities嵌套使用前兩種功能S/MIMECryptographicAlgorithmsdigitalsignatures:DSS&RSAhashfunctions:SHA-1&MD5sessionkeyencryption:ElGamal&RSAmessageencryption:AES,Triple-DES,RC2/40andothersMAC:HMACwithSHA-1haveprocesstodecidewhichalgstouse增強安全性的MIME——S/MIMES/MIME使用的密碼算法各密碼步驟對發送方和接收方Agent的要求功能需求（MUSTsandSHOULDs）生成消息摘要雙方都必須支持SHA-1；接收方應該支持MD5；簽名消息摘要雙方都必須支持DSS；發送方應該支持RSA；接收方應該支持密鑰大小為512-1024位的RSA；加密會話密鑰雙方都應該支持Diffie-Hellman；雙方都必須支持密鑰長度為521-1024位的RSA；加密消息雙方都必須支持3DES；發送方應該支持AES和RC2/40；增強安全性的MIME——S/MIMES/MIME中使用的密碼算法會話加密算法的選擇通過郵件成功交互的保證——接收方能夠解密經過發送方加密的數據S/MIME提供了多種可選密碼算法，故需要決策使用何種算法問題1：

發送方需要判斷，對于給定的密碼算法，接收方是否有解密能力問題2：

如果接收方不能使用給定的算法進行解密，發送方能否接受使用一個較弱的密碼算法決策過程步驟1：

若發送方保存了一份來自接收方的解密方式優先選擇列表，則應該選擇具有最高優先級的那種算法；步驟2：

若沒有上述列表，但是保存了若干來自接收方的郵件，則應該選擇接收方最近使用的那種密碼算法；步驟3：

發送方未掌握上述信息，且不能承受接收方可能無法解密所帶來的風險，用3DES；步驟4：

發送方未掌握上述信息，且能夠承受接收方無法解密帶來的風險，用RC2/40；S/MIMEMessagesS/MIMEsecuresaMIMEentitywithasignature,encryption,orbothformingaMIMEwrappedPKCSobjecthavearangeofcontent-types:envelopeddatasigneddataclear-signeddataregistrationrequest

證書請求，向認證中心申請公鑰證書（有待證實的公鑰，公鑰加密算法標識，用請求方私鑰對有待證實公鑰的簽名）certificateonlymessage

證書或證書撤銷列表，用作響應證書請求S/MIMECertificateProcessingS/MIMEusesX.509v3certificatesmanagedusingahybridofastrictX.509CAhierarchy&PGP’sweboftrusteachclienthasalistoftrustedCA’scertsandownpublic/privatekeypairs&certscertificatesmustbesignedbytrustedCA’sCertificateAuthoritieshaveseveralwell-knownCA’sVerisignoneofmostwidelyusedVerisignissuesseveraltypesofDigitalIDsincreasinglevelsofchecks&hencetrustClass IdentityChecks Usage1 name/emailcheck webbrowsing/email2 +enroll/addrcheck email,subs,s/wvalidate3 +IDdocuments e-banking/serviceaccessDomainKeysIdentifiedMailaspecificationforcryptographicallysigningemailmessagessosigningdomainclaimsresponsibilityrecipients/agentscanverifysignatureproposedInternetStandardRFC4871hasbeenwidelyadoptedbyarangeofemailproviders

corporations,governmentagencies,gmail,yahoo,andISPsInternetMailArchitectureEmailThreatsseeRFC4684-AnalysisofThreatsMotivatingDomainKeysIdentifiedMaildescribestheproblemspaceintermsof:低級lowend選擇工具偽造信息的原始發送地址職業垃圾郵件發送者spammers（商業公司，代表第三方發送信息）,使用更復雜的工具，利用包括MTA、注冊域以及染毒計算機發送電子郵件詐騙fraudsters使用上述各種手段、并且攻擊網絡基礎設施（DNSIP線路）攻擊者可能具備的能力

向不同位置的MTA、MSA遞交信息；隨意構造郵件頭；重發已經被域簽名過的信息；從染毒計算機上發送看似授權的信息；操縱IP線路，從特定或難以跟蹤的地址發送信息竊聽現有的通信。DKIM（DomainKeysIdentifiedMail）是一種電子郵件的驗證技術，在2007年2月時，DKIM被列入互聯網工程工作小組（IETF）的標準提案（ProposedStandard），并于同年5月成為正式標準（StandardsTrack）。RFC6376DKIMStrategyDKIM不在用戶程序中實現，是一種對終端用戶透明的Email認證技術。E-mail信息被行政域中的私鑰簽名，簽名包含了信息的所有內容以及一些