CAN201-网络安全2
CAN201-网络安全2
迟然认证（Authentication）
认证的目标
- 认证的主要目标是让一方（例如Bob）能够确认另一方（例如Alice）的身份。这在网络通信中至关重要，因为在网络环境中，双方可能无法直接看到对方，所以需要一种可靠的方法来确保对方的身份真实性。
协议ap1.0的问题
- 协议ap1.0中，Alice仅说“I am Alice”来证明自己的身份。但在网络中，Bob无法直接看到Alice，所以攻击者Trudy可以简单地宣称自己是Alice，这种方式完全无法保证身份的真实性，因为没有任何机制来验证声明者是否真的是Alice。
- 协议ap1.0中，Alice仅说“I am Alice”来证明自己的身份。但在网络中，Bob无法直接看到Alice，所以攻击者Trudy可以简单地宣称自己是Alice，这种方式完全无法保证身份的真实性，因为没有任何机制来验证声明者是否真的是Alice。
协议ap2.0的问题
- 协议ap2.0中，Alice在包含源IP地址的IP数据包中声明自己是Alice。然而，Trudy可以通过创建一个“欺骗”Alice地址的数据包来冒充Alice。这意味着仅依靠IP地址来证明身份是不安全的，因为IP地址可以被伪造，攻击者可以轻易地伪装成其他人的IP地址进行通信。
- 协议ap2.0中，Alice在包含源IP地址的IP数据包中声明自己是Alice。然而，Trudy可以通过创建一个“欺骗”Alice地址的数据包来冒充Alice。这意味着仅依靠IP地址来证明身份是不安全的，因为IP地址可以被伪造，攻击者可以轻易地伪装成其他人的IP地址进行通信。
协议ap3.0的问题
- 协议ap3.0中，Alice发送自己的秘密密码来证明身份。但存在回放攻击的风险，即Trudy可以记录Alice的数据包，然后在之后的某个时间将其回放给Bob。这样，Bob会误以为是Alice再次发送的数据包，而实际上可能是攻击者在重放之前截获的信息，从而导致身份验证被绕过。
- 协议ap3.0中，Alice发送自己的秘密密码来证明身份。但存在回放攻击的风险，即Trudy可以记录Alice的数据包，然后在之后的某个时间将其回放给Bob。这样，Bob会误以为是Alice再次发送的数据包，而实际上可能是攻击者在重放之前截获的信息，从而导致身份验证被绕过。
协议ap3.1的问题
- 协议ap3.1中，Alice发送加密的秘密密码来证明身份。然而，记录和回放攻击仍然有效，因为攻击者可以直接重放加密后的密码数据包，Bob无法区分这是实时的密码还是重放的密码，所以这种方式也不能有效防止回放攻击。
- 协议ap3.1中，Alice发送加密的秘密密码来证明身份。然而，记录和回放攻击仍然有效，因为攻击者可以直接重放加密后的密码数据包，Bob无法区分这是实时的密码还是重放的密码，所以这种方式也不能有效防止回放攻击。
协议ap4.0的改进与问题
- 协议ap4.0为了证明Alice“实时”存在，引入了一次性随机数（nonce）。Bob发送一个nonce $R$给Alice，Alice必须用共享密钥加密$R$并返回。由于只有Alice知道共享密钥且$R$是一次性使用的，所以可以确保返回加密$R$的一定是Alice本人，从而一定程度上避免了回放攻击。但它要求双方事先拥有共享对称密钥，这在某些情况下可能不太方便或不安全，例如密钥的分发和管理可能存在问题。
- 协议ap4.0为了证明Alice“实时”存在，引入了一次性随机数（nonce）。Bob发送一个nonce $R$给Alice，Alice必须用共享密钥加密$R$并返回。由于只有Alice知道共享密钥且$R$是一次性使用的，所以可以确保返回加密$R$的一定是Alice本人，从而一定程度上避免了回放攻击。但它要求双方事先拥有共享对称密钥，这在某些情况下可能不太方便或不安全，例如密钥的分发和管理可能存在问题。
协议ap5.0的改进与安全漏洞
- 协议ap5.0尝试使用公钥技术来解决认证问题。Bob发送一个nonce $R$给Alice，Alice用自己的私钥加密$R$后返回，Bob通过计算$K_{A}^{+}\left(K_{A}^{-}(R)\right)=R$来验证。这种方式不需要事先共享对称密钥，但存在中间人攻击（man - in - the - middle attack）的安全漏洞。Trudy可以在中间冒充Alice和Bob，截获双方的通信，使得Bob和Alice都以为在与对方通信，而实际上他们的通信都被Trudy控制，并且很难检测到这种攻击，因为Bob和Alice之间的消息传递看似正常，但Trudy可以获取所有消息。
- 协议ap5.0尝试使用公钥技术来解决认证问题。Bob发送一个nonce $R$给Alice，Alice用自己的私钥加密$R$后返回，Bob通过计算$K_{A}^{+}\left(K_{A}^{-}(R)\right)=R$来验证。这种方式不需要事先共享对称密钥，但存在中间人攻击（man - in - the - middle attack）的安全漏洞。Trudy可以在中间冒充Alice和Bob，截获双方的通信，使得Bob和Alice都以为在与对方通信，而实际上他们的通信都被Trudy控制，并且很难检测到这种攻击，因为Bob和Alice之间的消息传递看似正常，但Trudy可以获取所有消息。
认证部分主要是围绕如何让一方在网络中可靠地证明自己的身份展开，从简单的声明身份逐步发展到使用密码、加密技术和随机数等，但也不断面临新的安全挑战，如各种欺骗和攻击手段，后续需要不断改进和完善认证机制来保障网络通信的安全。
数字签名（Digital Signatures）
数字签名的概念与功能
- 数字签名类似于手写签名，是一种加密技术。其主要功能是确定文档的所有者/创建者，具有可验证性和不可伪造性。这意味着接收者（如Alice）可以向其他人证明某个文档是由特定的发送者（如Bob）签署的，并且没有其他人（包括Alice自己）能够伪造这个签名，从而保证了文档来源的真实性和完整性。
简单数字签名的过程
- 对于消息$m$，Bob通过用自己的私钥$K_{B}^{-}$加密消息来创建“已签名”消息$K_{B}(m)$。例如，Bob要发送消息“Dear Alice, Oh, how I have missed you. I think of you all the time! …(blah blah blah)”，他使用自己的私钥对该消息进行加密，生成签名后的消息。
- 对于消息$m$，Bob通过用自己的私钥$K_{B}^{-}$加密消息来创建“已签名”消息$K_{B}(m)$。例如，Bob要发送消息“Dear Alice, Oh, how I have missed you. I think of you all the time! …(blah blah blah)”，他使用自己的私钥对该消息进行加密，生成签名后的消息。
数字签名的验证过程
- 当Alice收到带有签名的消息$m$和$K_{B}^{-}(m)$时，她通过应用Bob的公钥$K_{B}^{+}$来验证签名。具体操作是计算$K_{B}^{+}(K_{B}^{-}(m))$，如果结果等于$m$，则可以证明消息是由Bob签名的，因为只有Bob拥有对应的私钥来加密消息，其他人无法使用Bob的公钥正确解密出原始消息，从而实现了对签名者身份的验证，同时也确保了消息的完整性，即消息在传输过程中没有被篡改。这种验证过程还提供了不可抵赖性（non - repudiation），意味着Bob无法否认他签署了该消息，Alice可以将消息和签名作为证据提交给法庭等。
消息摘要在数字签名中的作用
- 由于对长消息进行公钥加密计算成本较高，所以引入了消息摘要。消息摘要通过哈希函数$H$应用于消息$m$，得到固定大小的消息摘要$H(m)$。哈希函数具有多个重要属性，如它是多对一的（many - to - 1），会产生固定大小的消息摘要（作为数字“指纹”），并且给定一个消息摘要$x$，在计算上几乎不可能找到一个消息$m$使得$x = H(m)$。Bob发送数字签名消息时，实际上是对消息摘要进行签名，即发送$H(m)$和$K_{B}^{-}(H(m))$。Alice验证签名时，先使用Bob的公钥解密签名得到$H(m)$，然后对收到的消息$m$计算哈希值，比较两者是否相等，若相等则验证通过。
- 由于对长消息进行公钥加密计算成本较高，所以引入了消息摘要。消息摘要通过哈希函数$H$应用于消息$m$，得到固定大小的消息摘要$H(m)$。哈希函数具有多个重要属性，如它是多对一的（many - to - 1），会产生固定大小的消息摘要（作为数字“指纹”），并且给定一个消息摘要$x$，在计算上几乎不可能找到一个消息$m$使得$x = H(m)$。Bob发送数字签名消息时，实际上是对消息摘要进行签名，即发送$H(m)$和$K_{B}^{-}(H(m))$。Alice验证签名时，先使用Bob的公钥解密签名得到$H(m)$，然后对收到的消息$m$计算哈希值，比较两者是否相等，若相等则验证通过。
哈希函数算法
- 常见的哈希函数算法有MD5和SHA - 1。MD5广泛使用（RFC 1321），它通过4步过程计算128位消息摘要，对于任意128位字符串$x$，很难构造出消息$m$使其MD5哈希值等于$x$。SHA - 1也是常用的哈希函数，它是美国标准（NIST, FIPS PUB 180 - 1），能产生160位消息摘要。需要注意的是，Internet checksum虽然具有一些哈希函数的属性，如产生固定长度的摘要（16位和）且是多对一的，但它不是一个良好的加密哈希函数，因为给定一个消息及其哈希值，很容易找到另一个消息具有相同的哈希值，这在安全应用中是不可接受的。
- 常见的哈希函数算法有MD5和SHA - 1。MD5广泛使用（RFC 1321），它通过4步过程计算128位消息摘要，对于任意128位字符串$x$，很难构造出消息$m$使其MD5哈希值等于$x$。SHA - 1也是常用的哈希函数，它是美国标准（NIST, FIPS PUB 180 - 1），能产生160位消息摘要。需要注意的是，Internet checksum虽然具有一些哈希函数的属性，如产生固定长度的摘要（16位和）且是多对一的，但它不是一个良好的加密哈希函数，因为给定一个消息及其哈希值，很容易找到另一个消息具有相同的哈希值，这在安全应用中是不可接受的。
数字签名部分通过使用私钥加密和公钥验证的机制，结合消息摘要技术，为网络通信中的消息提供了来源认证、完整性保证和不可抵赖性，同时哈希函数算法的选择也对数字签名的安全性和性能有重要影响。
安全电子邮件（Secure e - mail）
机密性保证
- 当Alice想要向Bob发送机密电子邮件$m$时，为保证邮件内容不被他人窃取，她首先生成一个随机对称私钥$K_S$。然后，她使用$K_S$对消息$m$进行加密，得到$K_S(m)$。接着，Alice用Bob的公钥$K_{B}^{+}$对$K_S$进行加密，得到$K_{B}^{+}(K_S)$。最后，Alice将$K_S(m)$和$K_{B}^{+}(K_S)$都发送给Bob。Bob收到后，先用自己的私钥$K_{B}^{-}$解密$K_{B}^{+}(K_S)$，从而得到$K_S$，再用$K_S$解密$K_S(m)$，最终恢复出原始消息$m$。这种方式利用了对称加密的高效性和非对称加密的密钥分发优势，确保只有Bob能够使用自己的私钥获取对称密钥$K_S$，进而解密消息，保证了邮件在传输过程中的机密性。
- 当Alice想要向Bob发送机密电子邮件$m$时，为保证邮件内容不被他人窃取，她首先生成一个随机对称私钥$K_S$。然后，她使用$K_S$对消息$m$进行加密，得到$K_S(m)$。接着，Alice用Bob的公钥$K_{B}^{+}$对$K_S$进行加密，得到$K_{B}^{+}(K_S)$。最后，Alice将$K_S(m)$和$K_{B}^{+}(K_S)$都发送给Bob。Bob收到后，先用自己的私钥$K_{B}^{-}$解密$K_{B}^{+}(K_S)$，从而得到$K_S$，再用$K_S$解密$K_S(m)$，最终恢复出原始消息$m$。这种方式利用了对称加密的高效性和非对称加密的密钥分发优势，确保只有Bob能够使用自己的私钥获取对称密钥$K_S$，进而解密消息，保证了邮件在传输过程中的机密性。
认证与消息完整性提供
- 为了提供发送者认证和消息完整性，Alice使用自己的私钥$K_{A}^{-}$对消息$m$的哈希值$H(m)$进行签名，得到$K_{A}^{-}(H(m))$。然后，她将消息$m$（未加密的原文）和数字签名$K_{A}^{-}(H(m))$一起发送给Bob。Bob收到后，先使用Alice的公钥$K_{A}^{+}$对签名$K_{A}^{-}(H(m))$进行解密，得到$H(m)$，然后对收到的消息$m$计算哈希值$H(m)$，比较两者是否相等。如果相等，Bob就可以确认消息是由Alice发送的，并且消息在传输过程中没有被篡改，从而实现了发送者认证和消息完整性的保证。
- 为了提供发送者认证和消息完整性，Alice使用自己的私钥$K_{A}^{-}$对消息$m$的哈希值$H(m)$进行签名，得到$K_{A}^{-}(H(m))$。然后，她将消息$m$（未加密的原文）和数字签名$K_{A}^{-}(H(m))$一起发送给Bob。Bob收到后，先使用Alice的公钥$K_{A}^{+}$对签名$K_{A}^{-}(H(m))$进行解密，得到$H(m)$，然后对收到的消息$m$计算哈希值$H(m)$，比较两者是否相等。如果相等，Bob就可以确认消息是由Alice发送的，并且消息在传输过程中没有被篡改，从而实现了发送者认证和消息完整性的保证。
综合考虑机密性、认证和完整性
- 当Alice希望同时提供邮件的机密性、发送者认证和消息完整性时，她会使用三个密钥。首先，如前面所述，生成随机对称私钥$K_S$来加密消息$m$，用Bob的公钥加密$K_S$。然后，用自己的私钥对消息$m$的哈希值进行签名。这样，Bob在接收邮件时，可以通过解密$K_{B}^{+}(K_S)$得到$K_S$来解密消息，通过验证Alice的数字签名来确认消息的来源和完整性。这种综合的方法确保了安全电子邮件在各个方面的安全性，防止邮件内容被窃取、伪造或篡改，保障了邮件通信的安全可靠。
- 当Alice希望同时提供邮件的机密性、发送者认证和消息完整性时，她会使用三个密钥。首先，如前面所述，生成随机对称私钥$K_S$来加密消息$m$，用Bob的公钥加密$K_S$。然后，用自己的私钥对消息$m$的哈希值进行签名。这样，Bob在接收邮件时，可以通过解密$K_{B}^{+}(K_S)$得到$K_S$来解密消息，通过验证Alice的数字签名来确认消息的来源和完整性。这种综合的方法确保了安全电子邮件在各个方面的安全性，防止邮件内容被窃取、伪造或篡改，保障了邮件通信的安全可靠。
安全电子邮件部分通过使用对称和非对称加密技术以及数字签名，实现了邮件在传输过程中的机密性、发送者认证和消息完整性，有效地保护了电子邮件通信的安全。
SSL: Secure Sockets Layer
SSL的概述与重要性
- SSL是一种广泛部署的安全协议，几乎被所有浏览器和Web服务器所支持，在网络安全中起着至关重要的作用。例如，在进行网上购物时，我们常见的https协议就是基于SSL实现的，它确保了在客户端和服务器之间传输的数据的安全性，涉及数十亿的交易金额每年。SSL提供了机密性（确保数据不被未授权方获取）、完整性（保证数据在传输过程中未被篡改）和认证（确认通信双方的身份）等功能，其最初的目标是保障Web电子商务交易的安全，特别是对信用卡号码等敏感信息的加密，以及实现Web服务器认证和可选的客户端认证，使得用户在与新商家进行业务往来时能够以最小的麻烦确保交易安全，并且它可用于所有TCP应用，为应用提供了安全的套接字接口。
SSL与TCP/IP的关系
- SSL在TCP/IP协议栈中位于应用层和TCP层之间，为应用程序提供了应用编程接口（API）。这使得开发人员可以方便地在应用中使用SSL来增强安全性。例如，在C和Java等编程语言中，都有现成的SSL库或类可供使用，开发人员可以利用这些库来实现安全的网络通信，如安全的网页浏览、文件传输等，确保数据在应用层和传输层之间的安全传递。
- SSL在TCP/IP协议栈中位于应用层和TCP层之间，为应用程序提供了应用编程接口（API）。这使得开发人员可以方便地在应用中使用SSL来增强安全性。例如，在C和Java等编程语言中，都有现成的SSL库或类可供使用，开发人员可以利用这些库来实现安全的网络通信，如安全的网页浏览、文件传输等，确保数据在应用层和传输层之间的安全传递。
Toy SSL的工作流程
握手阶段（Handshake）：Alice和Bob使用各自的证书和私钥进行相互认证，并交换共享秘密（master secret）。例如，Alice首先建立与Bob的TCP连接，然后向Bob发送“hello”消息、自己的公钥证书以及用Bob的公钥加密的主密钥（master secret）$K_{B}^{+}(MS)=EMS$（其中$MS$是主密钥，$EMS$是加密后的主密钥）。这个阶段的目的是确保双方的身份真实性，并建立一个安全的通信基础，后续的通信都将基于这个共享秘密进行加密和认证。
密钥派生阶段（Key derivation）：考虑到使用同一个主密钥进行多种加密操作存在安全风险，Alice和Bob使用共享秘密（master secret）派生一组密钥。具体来说，从主密钥派生出用于客户端到服务器数据加密的密钥$K_{c}$、用于客户端到服务器数据的消息认证码（MAC）密钥$M_{c}$、用于服务器到客户端数据加密的密钥$K_{s}$以及用于服务器到客户端数据的MAC密钥$M_{s}$。这些密钥是通过密钥派生函数（KDF）根据主密钥和可能的一些额外随机数据生成的，不同的密钥用于不同的加密和认证操作，提高了安全性。
数据传输阶段（Data transfer）：为了解决将数据加密成连续流可能存在的问题，如MAC放置位置和消息完整性检查的时机问题，SSL将数据分成一系列记录进行传输。每个记录都携带一个消息认证码（MAC），MAC的计算方式为$MAC = H(m + s)$（其中$m$是消息，$s$是MAC密钥）。接收方可以在每个记录到达时对其进行处理，通过验证MAC来确保数据的完整性和真实性。同时，为了防止攻击者捕获和重放记录或重新排序记录，在MAC中加入了序列号，例如$MAC = H(M_{x})，sequence || data$，并且为了进一步防止攻击者重放所有记录，还可以使用一次性随机数（nonce）。
连接关闭阶段（Connection closure）：为了防止截断攻击（如中间人攻击者伪造TCP连接关闭段（FIN），导致一方认为数据比实际少），SSL使用不同的记录类型来安全地关闭连接，例如定义类型0为数据记录，类型1为关闭记录，并且在MAC的计算中加入记录类型，即$MAC = H(M_{x})，sequence || type || data$，确保连接关闭的安全性。
Toy SSL的局限性与SSL cipher suite
- Toy SSL存在一些局限性，如未明确字段长度、未指定具体的加密协议、未考虑客户端和服务器的协商需求等。为了解决这些问题，SSL支持多种密码套件（cipher suite）。密码套件包括公共密钥算法（如RSA）、对称加密算法（如DES、3DES、RC2、RC4等）和MAC算法。在通信时，客户端会提供它支持的密码套件列表，服务器从中选择一个，双方通过协商确定使用的加密算法，这样可以允许客户端和服务器支持不同的加密算法，并在数据传输前共同选择特定的算法，以满足不同的安全需求和性能要求。
Real SSL的握手过程
- 目的：Real SSL的握手过程有多个重要目的，包括服务器认证（让客户端确认服务器的身份）、协商（双方就加密算法达成一致）、建立密钥（生成用于后续通信的加密和MAC密钥）以及可选的客户端认证（在需要时让服务器确认客户端的身份）。
- 具体步骤:
- 客户端发送它支持的算法列表以及客户端随机数（nonce）。
- 服务器从列表中选择算法，然后发送回选择的算法、服务器证书和服务器随机数。
- 客户端验证服务器证书，提取服务器的公钥，生成预主密钥（pre_master_secret），并用服务器的公钥加密后发送给服务器。
- 客户端和服务器独立地根据预主密钥和随机数计算加密和MAC密钥。
- 客户端发送所有握手消息的MAC。
- 服务器发送所有握手消息的MAC。最后两步通过对握手消息进行MAC计算，可以保护握手过程免受篡改，防止中间人攻击。例如，如果中间人试图删除客户端提供的较强算法，由于最后两步的MAC验证，服务器可以检测到握手消息被篡改，从而保证了协商过程的安全性。此外，使用两个随机数（分别在客户端和服务器发送的消息中）可以防止重放攻击，因为每次连接的随机数不同，导致加密密钥也不同，攻击者重放的消息将无法通过完整性检查。
SSL部分通过一系列复杂而有序的机制，包括握手、密钥派生、数据传输和连接关闭等阶段，以及密码套件的协商，为网络通信提供了全面的安全保障，确保了数据在网络传输过程中的机密性、完整性和认证性，是保障网络安全通信的重要技术之一。
