应用层安全协议

1.电子邮件安全协议（PGP、S/MIME）

1.电子邮件面临的威胁：邮件炸弹、邮件欺骗、垃圾邮件、邮件携带病毒、恶意代码等。

2.电子邮件的安全需求：机密性、认证、完整性、抗否认性。

• 机密性：关键在于密钥的分发，收发双方如何共享密钥？存在多个接收者时怎么办？
• 认证：发送者身份的认证。可以基于公钥技术，利用发送者的私钥生成数字签名。也可以基于共享密钥，事先发送者与接收者共享一个密钥，采用消息认证码对报文进行认证。
• 完整性：报文未被修改。与身份认证方法类似，通常可在一起进行。
• 抗否认性：发信者的不可抵赖性，可供第三方鉴别。基于公钥技术，采用发送者私钥签名。

3.PGP（Pretty Good Privacy,Email 安全加密系统）

      PGP提供的安全业务:

• 加密：发信人产生一次性会话密钥，以IDEA、3-DES或CAST-128算法加密报文，采用RSA算法用收信人的公钥加密会话密钥，并和消息一起发出。
• 认证：用SHA-1对报文杂凑，并以发信人的私钥签字，签名算法采用RSA或DSS。
• 压缩：ZIP，用于消息的传送或存储。在压缩前签名，压缩后加密。签名后再压缩是为了方便保存未压缩的报文和签名，为了以后存储方便，如果签名是对压缩后报文进行的，就要保存一份压缩的文档与之对应，或者增加部分计算。但相同的压缩算法可能产生略微不同的压缩结果。压缩后加密可以节约传输文件的存储空间，加快加密速度，而且压缩减少了原文中的相关性，使密码分析也更困难。
• 兼容性：采用Radix-64可将加密的报文转换成ASCII字符。
• 数据分段：PGP具有分段和组装功能，适应最大消息长度限制。 通常邮件的最大报文长度限制在50000字节，超过标准长度的报文必须分段，PGP自动对过长的报文分段，接收端再对其重组。

   4. S/MIME（安全/多用途 Internet 邮件扩展）S/MIME 旨在成为商业和机构使用的标准，PGP则为个人e-mail 提供安全。

• SMTP（简单邮件传输协议），存在诸多问题：不能传输可执行文件和其他二进制码，二进制转换成文本格式，现在方案缺乏标准。只能传输7位ASCII字符的文字，而中文字符等无法直接使用。SMTP服务器拒绝接收超长邮件。MIME是对SMTP框架的扩展，致力于解决SMTP中关于邮件格式和编码方面存在的问题。
• MIME的头标，定义了5个新字段：版本，内容类型（用于详细描述主体的数据），内容传输编码：内容采用的编码方案，内容ID：该字段主要用于多个上下文时对MIME实体的标识，内容描述：对内容的文本描述。
• S/MIME功能：与PGP类似，通过使用签名、加密或签名/加密的组合来保证MIME通信的安全，但强化了证书的规范。S/MIME安全功能：1.封装的数据：加密内容和加密的会话密钥，2.签名的数据：报文摘要+发送者的私钥签名，然后使用基64变换编码内容和签名，3.透明签名：签名但不加密.只对签名进行基64变换，这样具有MIME支持而没有S/MIME权能的接收者也能读取，但无法验证签名，4.签名和封装的数据：各种不同嵌套顺序将数据加密、签名，如签名加密的数据或加密签名的数据。

2.远程登陆的安全协议 （SSH）

• SSH 传输层协议：提供服务器主机认证，提供数据加密，提供数据完整性支持。
• SSH认证协议：为服务器提供用户的身份认证。
• SSH连接协议：将加密的信息隧道复用成若干个逻辑信道，提供给高层的应用协议使用

3.Web安全协议

1.HTTPS（http over SSL)

• 由http和SSL结合来实现浏览器和服务器之间的安全通信。
• https的功能被嵌入到所有当前的主流浏览器当中，但依赖于服务器端是否支持https通信。
• https的周知端口为443,http为80。
• 定义在 RFC2818: HTTP over TLS。
• 基于标准的SSL/TLS服务。
• 当使用HTTPS时，以下内容被加密：请求文件的URL、文件内容、浏览器的表单内容、cookie、http头标内容

2.HTTPS的使用

•  连接建立：客户端同时扮演http的客户端和TLS的客户端，首先是TLS握手过程，然后是http请求，执行标准的http过程，在一个客户端和服务器之间建立多个连接（一个会话过程包含一个或者多个连接）。
• 连接关闭：先关闭http：在http消息中包含"connection close",再关闭SSL 、TCP连接。

4.DNSSEC 协议和系统

1.简介：DNSSEC 通过为DNS中的数据添加数字签名信息，使得客户端在得到应答消息后可以通过检查此签名信息来判断应答数据是否权威和真实，从而为DNS数据提供数据来源验证和数据完整性检验，可以防止针对DNS的相关攻击。

2.DNSSEC功能：

• 为DNS数据提供来源验证
• 为数据提供完整性验证
• 为查询提供否定存在验证（即为否定应答消息提供验证，确认授权服务器上不存在所查询的资源记录）

3.DNSSEC引入新的资源记录

• DNSKEY,用于存储验证DNS数据的公钥
• PRSIG，用于存储DNS资源记录的签名信息
• NSEC，存储和对应的所有者相邻的下一个资源记录；主要用于否定存在验证。
• DS（授权签名者 ),用于DNSKEY 验证过程，存储密钥标签，加密算法和对应的DNSKEY的摘要信息。

5.SET协议

1.安全电子交易协议-SET

• SET提供了消费者、商家和银行之间的认证，确保了网上交易数据的保密性，数据的完整性以及交易的不可抵赖性。特别能保证不将消费者银行卡号暴露给商家，不将消费者的购物信息暴露给银行等优点，因此它成为目前公认的信用卡/借记卡网上交易安全标准。
• SET采用公钥密码体制，遵循X.509数字证书标准。

2.SET的系统组成

• 持卡人：由发卡行 所发行的支付卡的授权持有者。
• 商家：出售商品或服务的个人或机构，商家必须与收单行建立业务联系以接受支付卡这种付款方式。
• 发卡行：为持卡人建立一个账户，并发行支付卡的金融机构。
• 收单行：为商家建立账户并处理支付卡授权和支付的金融机构。
• 支付网关：由收单行操作的设备，实现对支付信息从Internet 到银行内部网络的转换，并对商家和持卡人进行认证。

3.商业支付系统的安全需求

• 提供支付和订购信息的机密性
• 保证所有传输数据的完整性
• 提供持卡人的身份认证
• 提供商家能否接受信用卡交易的认证
• 确保采用最好的安全系统和技术来保护电子商务交易中的所有合法参与者 的利益

4.SET的主要特征

• 信息的机密性
• 数据的完整性
• 持卡人的账户认证
• 商家认证 

5.SET协议信息结构

• 参与SET协议支付系统的实体：持卡人、商家、支付网关。
• SET协议信息结构：持卡人/商家注册流程、购买请求流程、支付授权流程、支付执行流程、持卡人查询过程。 

6.双重数字签名

• 发送者寄出两个相关信息给接收者，对这两组相关信息，接收者只能解读其中一组，另一组只能转送给第三方接收者，不能打开看其内容。此时发送者需分别加密两组明文，并针对两组明文 信息联系起来并进行签名。
• 应用场合：电子商务购物、付款。