第八讲电子邮件安全

第八讲电子邮件安全提纲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信息被行政域中的私钥签名，签名包含了信息的所有内容以及一些