端点鉴别

端点鉴别

端点鉴别（end-point authentication）是一个实体经过计算机网络向另一个实体证明其身份的过程，这种鉴别应当在报文和数据交换的基础上，作为某鉴别协议的一部分独立完成。鉴别协议通常会在两个通信实体运行其他协议之前运行，鉴别协议首先建立相互满意的各方的标识；仅当鉴别完成之后，各方继续开始下面的工作。

鉴别协议ap 1.0——发送者直接发送一个报文表明身份

假设Alice要向Bob鉴别她自己的身份。
最简单的就是：Alice直接发送一个报文给Bob，说她就是Alice。
缺陷是Bob无法判断发送报文“I am Alice ”的人就是Alice，因为Trudy（入侵者）也可以发送这样的报文。

鉴别协议ap 2.0——ap1.0 的基础上，接收者对报文的来源IP地址进行鉴别

Alice说 “I am Alice ” ，并在她发送的IP数据包中包含了她的IP地址。
缺陷是Trudy可以生成一个分组，包括伪造的Alice的地址。

鉴别协议ap 3.0——使用秘密口令，口令为鉴别者和被鉴别者之间共享的秘密

Alice说 “I am Alice ” ，而且传送她的密码来证明。
口令为鉴别者和被鉴别者之间共享的秘密。比如Gmail、Telnet（远程终端协议）、FTP（文件传输协议）和许多服务都是使用口令鉴别。
缺陷是若Trudy窃听了Alice的通信，则可以得到Alice的口令。Trudy记录了Alice的分组，事后向Bob发送。
例子：

鉴别协议ap 3.1——对秘密口令进行加密，但是容易收到回放攻击（Playback Attack）威胁

完善鉴别协议ap 3.0 的下一个想法就是加密口令，通过加密口令，能够防止Trudy得知Alice的口令。假设Alice和Bob共享一个对称秘密秘钥K（A-B），则Alice可以加密口令，并向Bob发送其识别报文“ I am Alice ” 和加密的报文。Bob则解密口令，若口令正确，则鉴别了Alice。
虽然防止Trudy得知Alice的口令，缺陷是Bob受制于回放攻击，Trudy只需要窃听Alice的通信，并记录下该口令的加密版本，并向Bob回放该口令的加密版本，以假装她就是Alice。

鉴别协议ap 4.0

失败情形是由于Bob无法区分Alice的初始鉴别报文和后来入侵者回放的Alice的初始鉴别报文所导致的。也就是说，Bob 无法分辨 Alice 是否是活跃的（即当前是否还在连接的另一端），或者他接收到的报文是否就是前面鉴别Alice时录制的回放。
可以联想到TCP三次握手协议需要处理相同的问题。此处，我们可以采用同样的思路来进行身份验证。
不重数（Nonce）：是在一个协议的生存期中只使用一次的数。也就是说，协议一旦使用了一个 nonce，就不会再使用该数字。ap 4.0 协议使用 nonce 的方式如下：
1、Alice向Bob发送信息 “ I am Alice ”。
2、Bob选择一个不重数 R，并将这个值发送给Alice。
3、Alice使用她与Bob共享的对称秘密密钥K（A-B）来加密这个不重数，然后把加密之后的不重数发回给Bob。由于Alice知道密钥，并用它加密一个值，Bob就知道收到的报文是Alice产生的。这个不重数用于确认Alice是活跃的。
4、Bob解密收到的报文，若解密得到的不重数等于Bob发送给Alice的那个不重数，则可以鉴别Alice的身份。
过程简单概括如下：
被鉴别者向鉴别者发送报文表明身份。
鉴别者选择一个不重数发送给被鉴别者。
被鉴别者用私钥加密不重数发送给鉴别者。

安全电子邮件

电子邮件的安全威胁

电子邮件的安全威胁：
（1）电子邮件的内容是公开的和可获取的。
（2）邮件在网络上反复复制，传输路径不确定，易遭到窃取、篡改、假冒甚至破坏。
电子邮件的安全需求：
1、机密性——只有真正的接收方才能阅读邮件。
2、完整性——电子邮件在传输过程中不被修改。
3、认证性——信息的发送者不被假冒。
4、抗抵赖性——发信人无法否认发过电子邮件。

安全电子邮件基本原理

加密性

Alice用对称秘钥Ks加密 明文邮件m，生成Ks(m)。同时用Bob的公钥加密Ks 得到KB+(Ks)。把加密邮件Ks(m) 和 加密秘钥KB+(Ks) 形成一个包发送给Bob。Bob可以根据私钥KB-得到秘钥Ks，再用Ks解密 Ks(m)得到解密报文m。

发送方鉴别和报文完整性

报文完整性用报文摘要，身份认证用数字签名。
Alice用散列函数对报文生成散列值H，得到报文摘要，Alice用私钥KA-对散列值进行签名，得到数字签名。把初始报文（未加密）和该数字签名级联起来生成一个包，发送给Bob。
Bob通过Alice公钥KA+解密数字签名，得到报文摘要。如果能解密成功，就证明了是Alice所发，否则无法用Alice公钥解密。
Bob用相同散列函数对明文 m 计算，如果摘要相同，证明没被篡改。

机密性、发送方鉴别和报文完整性

Alice生成一个预备包，包含她的初始报文和该报文数字签名过的散列。Alice把这个预备包看作一个报文，按照加密性那的步骤发送这个报文，即生成一个新包发送给Bob。
Bob收到这个包后，首先应用根据私钥KB-得到秘钥Ks，再用Ks解密 Ks(m)得到解密报文m。通过Alice公钥KA+解密数字签名，得到报文摘要。如果能解密成功，就证明了是Alice所发，否则无法用Alice公钥解密。Bob用相同散列函数对明文 m 计算，如果摘要相同，证明没被篡改。
Alice期望提供保密、发送者认证与报文完整性。
Alice私钥用于签名，身份认证；Bob共用用于加密的对称秘钥，传输对称秘钥。对称秘钥用于加密、解密报文。

安全电子邮件标准

1、PEM（privacy enhanced mail，增强型邮件保密）标准

• 在邮件标准格式上增加加密、认证和密钥管理 ；
• 依赖一个既存的、完全可操作的 PKI，发展被限制；
• PEM 像一个 OSI 标准，PGP 像一个 Internet 软件包；
  2、PGP（pretty good privacy，高质量保密）标准
• 符合 PEM 的绝大多数规范，但不要求存在PKI；
• 创造性结合公钥加密的方便和对称加密的高速度；
• 数字签名和密钥管理机制设计巧妙；
• 不仅功能强大，速度快，而且源代码公开；
  3、S/MIME 标准
  S/MIME：secure/multipurpose Internet mail extensions —— 安全/多用途因特网邮件扩展
• 并非只能用于邮件传输，任何支持 MIME 的传输机制都可使用，如 HTTP；
• 对电子邮件最有效，因为必须保证邮件本身安全；
• 认证机制依赖于层次结构的 CA（Tree of Trust）；
• 证书格式采用 X.509 规范，但支持的厂商比较少；

PGP 标准（pretty good privacy，高质量保密）

可在各种平台（Windows、UNIX等）免费运行，还可用于普通文件加密及军事目的，所用算法被证实为非常安全：
1、公钥加密算法 RSA、DSS 和 Diffie-Hellman；
2、对称加密算法 IDEA、3DES 和 CAST-128；
3、散列算法 SHA-1。

PGP 的特点

1、使用散列函数对邮件内容签名，保证信件内容不被篡改；
2、使用公钥和对称加密保证邮件内容机密且不可否认；
3、公钥的权威性由收发双方所信任的第三方签名认证；
4、事先不需要任何保密信道来传递对称的会话密钥。

PGP过程

1、对报文用SHA-1摘要；
2、对摘要RSA加密，用Alice的私钥，形成签名；
3、把前面和 报文m一起压缩；
4、压缩后，进行DES加密，DES用到了对称秘钥；
5、对称秘钥用Bob的公钥加密；
6、把压缩和 对称秘钥加密结果 用Base64 编码，编码后发送。

使TCP连接安全：TLS

SSL（Secure Socket Layer），即安全套接字层，是对 TCP 的强化。HTTPS 使用 SSL，而 HTTP 不使用。
SSL 通过采用机密性、数据完整性、服务器鉴别和客户鉴别来强化 TCP。
SSL 使 TCP 安全了，所以它能被应用于运行在 TCP 之上的任何应用程序。
如何增强TCP，提供包括保密性、数据完整性和端点认证在内的安全服务，这个增强版的TCP通常被称为传输层安全（TLS）。这个协议的早期版本和类似版本是SSL版本3。自从其诞生以来，SSL及其继任者TLS已经得到了广泛的部署。TLS被所有流行的Web浏览器和Web服务器支持，并且被Gmail和几乎所有的互联网商务网站（包括亚马逊、eBay和淘宝）使用。实际上，如果曾经使用信用卡在互联网上购买过任何东西，浏览器和服务器之间的通信几乎可以肯定地是通过TLS进行的。（可以通过浏览器的URL以https:而不是http开头来判断TLS正在被使用。）

以一个典型的互联网商务场景，理解TLS的需求：Bob正在网上冲浪，来到了Alice公司的网站，该网站正在销售香水。Alice公司的网站显示了一个表格，Bob应该在其中输入他想要的香水类型和数量、他的地址和他的支付卡号码。Bob输入这些信息，点击提交，并期望通过普通邮寄收到他购买的香水；他还期望在他的下一个支付卡对账单中收到他订单的费用。这一切都听起来不错，但如果不采取安全措施，Bob可能会遇到一些惊喜。

• 如果不使用保密性（加密），入侵者可以拦截Bob的订单并获得他的支付卡信息。入侵者随后可以以Bob的名义进行购买。
• 如果不使用数据完整性，入侵者可以修改Bob的订单，让他购买比他想要的多十倍的香水。
• 最后，如果不使用服务器认证，服务器可以显示Alice公司的著名标志，而实际上该站点由Trudy维护，她伪装成Alice公司。在收到Bob的订单后，Trudy可以拿走Bob的钱并逃跑。或者Trudy可以通过收集Bob的姓名、地址和信用卡号码来实施身份盗窃。

TLS通过增强TCP的保密性、数据完整性、服务器认证和客户端认证来解决这些问题。TLS通常用于保护在HTTP上进行的交易的安全。然而，由于TLS保护TCP，它可以被任何运行在TCP上的应用程序使用。TLS提供了一个简单的应用程序编程接口（API）与套接字，这与TCP的API类似且类似。当应用程序想要使用TLS时，应用程序包括SSL类/库。如图所示，尽管从技术上讲TLS位于应用层，但从开发人员的角度来看，它是一个传输协议，提供增强了安全服务的TCP服务。

宏观描述

首先描述一个简化版的TLS，这将能够从宏观上理解TLS的原因和方法。将这个简化版的TLS称为“类-TLS”。在描述了类-TLS之后，将在下一个子节中描述真正的TLS，填补细节。类-TLS（和TLS）有三个阶段：握手、密钥导出和数据传输。现在描述这三个阶段，用于客户端（Bob）和服务器（Alice）之间的通信会话，Alice拥有一个私钥/公钥对和将她的身份与其公钥绑定的证书。

握手

在握手阶段，Bob需要（a）与Alice建立TCP连接，（b）验证Alice确实是Alice，（c）向Alice发送一个主密钥。这个密钥将被Alice和Bob用来生成他们需要的所有对称密钥进行TLS会话。这三个步骤如图所示。注意，一旦TCP连接建立，Bob向Alice发送一个hello消息。Alice随后用她的证书响应，其中包含她的公钥。因为证书已经由CA认证，Bob知道证书中的公钥属于Alice。Bob然后生成一个主密钥（MS）（这只用于这个TLS会话），用Alice的公钥加密MS以创建加密的主密钥（EMS），并将EMS发送给Alice。Alice用她的私钥解密EMS以获得MS。在这个阶段之后，Bob和Alice（没有其他人）都知道这个TLS会话的主密钥。

密钥导出

原则上，MS此时已由Bob和Alice共享，可以被用作所有后续加密和数据完整性检查的对称会话密钥。然而，通常认为更安全的做法是，Alice和Bob各自使用不同的加密密钥，并且对于加密和完整性检查使用不同的密钥。因此，Alice和Bob都使用MS生成四个密钥：

• EB ，从Bob发送到Alice的数据的会话加密密钥
• MB ，从Bob发送到Alice的数据的会话MAC密钥，其中MAC是标准化的哈希消息认证码（MAC）
• EA ，从Alice发送到Bob的数据的会话加密密钥
• MA，从Alice发送到Bob的数据的会话MAC密钥

Alice和Bob各自从MS生成这四个密钥。这可以通过简单地将MS分成四个密钥来完成。在密钥导出阶段结束时，Alice和Bob都有四个密钥。两个加密密钥将用于加密数据；两个MAC密钥将用于验证数据的完整性。

数据传输

现在Alice和Bob共享相同的四个会话密钥（EB、MB、EA和MA），他们可以开始通过TCP连接安全地相互发送数据。由于TCP是字节流协议，一个自然的方法将是TLS在传输中加密应用数据，然后将加密的数据在传输中传递给TCP。但我们并不想等到整个TCP会话结束时才验证Bob发送的所有数据的完整性！
为了解决这个问题，TLS将数据流分成记录，为每个记录附加MAC以进行完整性检查，然后加密该“ 记录+HMAC”。为了创建MAC，Bob将记录数据和密钥MB输入到哈希函数中。为了加密“ 记录+HMAC”这个包，Bob使用他的会话加密密钥EB。然后这个加密包被传递给TCP以通过互联网传输。尽管这种方法非常有效，但在提供整个消息流的数据完整性方面仍然不是无懈可击的。特别是，假设Trudy是一个中间女人，并且有能力在Alice和Bob之间发送的TCP段流中插入、删除和替换段。例如，Trudy可以捕获Bob发送的两个段，反转段的顺序，调整TCP序列号（这些序列号没有加密），然后将两个反转顺序的段发送给Alice。假设每个TCP段恰好封装了一个记录，让我们现在看看Alice将如何处理这些段。

1. 在Alice中运行的TCP会认为一切正常，并将两个记录传递给TLS子层。
2. Alice中的TLS将解密这两个记录。
3. Alice中的TLS将使用每个记录中的HMAC来验证这两个记录的数据完整性。
4. 然后TLS将两个记录的解密字节流传递给应用层；但由于记录的反转，Alice接收到的完整字节流将不在正确的顺序中！

这个问题的解决方案，你可能已经猜到了，就是使用序列号。TLS如下所示。Bob维护一个序列号计数器，它从零开始，并且对于他发送的每个TLS记录都会增加。Bob实际上并不在记录本身中包含序列号，但是当他计算HMAC时，他将序列号包含在HMAC计算中。因此，HMAC现在是数据加上HMAC密钥MB加上当前序列号的哈希。Alice跟踪Bob的序列号，允许她通过在HMAC计算中包含适当的序列号来验证记录的数据完整性。这种使用TLS序列号的方法防止了Trudy进行例如重新排序或重放报文段等中间人攻击。

TLS记录

TLS记录（以及almost-TLS记录）如图所示。记录由类型字段、版本字段、长度字段、数据字段和HMAC字段组成。注意，前三个字段没有被加密。
类型字段指示记录是握手消息还是包含应用程序数据的消息。它也用于关闭TLS连接。接收端的TLS使用长度字段从传入的TCP字节流中提取TLS记录。版本字段是自解释的。

更完整的描述

TLS握手

SSL不强制Alice和Bob使用特定的对称密钥算法或特定的公钥算法。相反，TLS允许Alice和Bob在握手阶段，在TLS会话开始时，就密码算法达成一致。此外，在握手阶段，Alice和Bob相互发送不重数，这些nonce用于创建会话密钥（EB、MB、EA和MA）。实际TLS握手的步骤如下：

1. 客户端发送它支持的密码算法的列表，连同一个客户的不重数。
2. 从列表中，服务器选择一个对称算法（例如AES）和一个公钥算法（例如具有特定密钥长度的RSA），以及HMAC算法（MD5或SHA-1）以及HMAC密钥。它将它的选择，以及证书和服务器不重数返回给客户。
3. 客户验证证书，提取服务器的公钥，生成一个前主密钥（PMS），用服务器的公钥加密PMS，并将加密的PMS发送给服务器。
4. 使用相同的密钥派生函数（由TLS标准指定），客户和服务器独立地从PMS和不重数计算主密钥（MS）。然后MS被分割以生成两个加密和两个HMAC密钥。此外，当选择的对称密码使用CBC（如3DES或AES）时，从MS中为连接的两侧各获得两个初始化向量（IV）。此后，客户端和服务器之间发送的所有消息都被加密和认证（使用HMAC）。
5. 客户端发送所有握手消息的HMAC。
6. 服务器发送所有握手消息的HMAC。

最后两步保护握手免受篡改。为了看到这一点，观察在步骤1中，客户端通常提供一个算法列表——有些强，有些弱。这个算法列表以明文发送，因为加密算法和密钥尚未达成一致。作为中间人的Trudy可以删除列表中的更强算法，迫使客户端选择一个弱算法。为了防止这种篡改攻击，在步骤5中，客户端发送其发送和接收的所有握手消息的HMAC。服务器可以将这个HMAC与其接收和发送的握手消息的HMAC进行比较。如果存在不一致，服务器可以终止连接。类似地，服务器发送其看到的握手消息的HMAC，允许客户端检查不一致性。
你可能会想知道为什么在步骤1和2中有nonce。序列号难道不足以防止段重放攻击吗？答案是是的，但它们本身并不能防止“连接重放攻击”。考虑以下连接重放攻击。假设Trudy嗅探了Alice和Bob之间的所有消息。第二天，Trudy伪装成Bob，向Alice发送了与前一天Bob向Alice发送的完全相同的消息序列。如果Alice不使用nonce，她将对前一天发送的完全相同的消息序列做出响应。Alice不会怀疑任何有趣的业务，因为她接收到的每条消息都将通过完整性检查。如果Alice是一个电子商务服务器，她将认为Bob正在下第二个订单（完全相同的东西）。另一方面，通过在协议中包含一个nonce，Alice将为每个TCP会话发送不同的nonce，导致两天的加密密钥不同。因此，当Alice从Trudy接收到播放回放的TLS记录时，记录将无法通过完整性检查，伪造的电子商务交易将不会成功。总之，在TLS中，nonce用于防御“连接重放攻击”，序列号用于防御在正在进行的会话期间重放单个数据包。

连接关闭

在某个时候，Bob或Alice将想要结束TLS会话。一种方法是让Bob通过简单地终止底层TCP连接来结束TLS会话——即，让Bob向Alice发送一个TCP FIN段。但这样的简单设计为截断攻击设置了舞台，Trudy再次进入正在进行的TLS会话中间，并提前用TCP FIN结束会话。如果Trudy这样做，Alice会认为她收到了Bob的所有数据，而实际上她只收到了部分数据。解决这个问题的方法是在类型字段中指示记录是否用于终止TLS会话。（尽管TLS类型是以明文发送的，但它在接收器处使用记录的HMAC进行认证。）通过包含这样一个字段，如果Alice在没有收到关闭TLS记录的情况下收到TCP FIN，她就会知道有些有趣的事情发生了。