数字签名和验签过程实现分析

最新推荐文章于 2025-06-20 16:43:34 发布

sweird

最新推荐文章于 2025-06-20 16:43:34 发布

阅读量2.4w

点赞数 2

CC 4.0 BY-SA版权

分类专栏： Linux 文章标签： struct authentication stream null ini reference

本文链接：https://blog.youkuaiyun.com/rosetta/article/details/7712606

本文通过openswan-2.4.7项目分析了数字签名的生成与验证过程，详细阐述了使用hash函数生成摘要，结合私钥签名，公钥解签的原理。在openswan的协商流程中，签名在第5、6个包中交换并进行验证，确保数据的完整性和发送方的可验证性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

本文档的Copyleft归rosetta所有，使用GPL发布，可以自由拷贝、转载，转载时请保持文档的完整性。

         数字签名在网络安全领域用的比较多，可实现用户身份的真实可靠性；实现信息的完整性，确保数据在存储、传输和处理的过程中免遭任何非授权的或非预期的修改、插入、删除、重发等破坏，从而实现数据的真实性、有效性和一致性；实现抗抵赖性，通过数字签名确保信息的发送方不能抵赖曾经发送的信息，不能否认自己的操作行为。
        下面结合著名的VPN开源项目openswan-2.4.7来理解数字签名和解签名的具体过程。
一、数字签名和解签（验签）过程：使用hash函数对报文数据生成摘要，使用自己的私钥对摘要进行签名（其实就是加密过程），生成签名数据，把原始数据报文和签名数据发送给对方。接收方收到原始数据报文和签名数据后，首先使用相同的hash函数对原始数据生成一个摘要，其次，用对方的公钥对签名数据进行解签名（解密过程），这个解签名的结果也是个摘要，最后比较这两个摘要是否相同，如果相同那么接收方就能确认该数字签名是发送方的。
        用以下hash1、hash2和hash3表明不同时期的摘要：
              发送方：签名值=f(hash1(msg)，私钥)； (msg表示原始报文数据)
              接收方：hash2(msg) = f^(-1)(签名值,公钥);(我觉得就是f的反函数，所以写了f^(-1)表示)
                             hash3(msg);
     正常情况下hash2通过公钥对“发送方发过来的签名值”解签后应该等于hash1。hash1和hash3都是对原始报文数据进行摘要，所以只要最后比较hash2和hash3是否相同，就能确定消息的完整性和证明数据是由对方发送的（抗抵赖）。

二、openswan协商总体流程,只关注第5、6个包即可。
                Initiator                          Responder
               -----------                        -----------
                HDR, SA                     -->
第1个包      main_outI1(发送初始化数据1)
                                            <--    HDR, SA
第2个包                                            main_inI1_outR1(接收到初始化数据1, 发送响应数据1)
                HDR, KE, Ni                 -->
第3个包        main_inR1_outI2(接收到响应数据1,发送初始化数据2)
                                            <--    HDR, KE, Nr
第4个包                                             main_inI2_outR2(接收到初始化数据2, 发送响应数据2)
                HDR*, IDii, [ CERT, ] SIG_I -->
第5个包        main_inR2_outI3(接收到响应数据2,发送初始化数据3)
                                            <--    HDR*, IDir, [ CERT, ] SIG_R
第6个包                                             main_inI3_outR3(接收到初始化数据3, 发送响应数据3)
        main_inR3(接收到响应数据3, 完成主模式协商, 建立ISAKMP SA)

        由rfc2409 5.1 使用签名方法进行IKE第一阶段认证,可知签名载荷SIG_I在第5个包中发送给对方，对方在第6个包中对签名进行验签，并发送另外一个签名给发起方，最后发起方对收到的签名进行验签。
                5.1 使用签名方法进行IKE第一阶段认证

           使用签名方法时，在第二个传输往返中交换的辅助信息是当前时间（nonce）；
           交换的认证是通过对一个相互可得到的hash值进行签名。使用签名认证的主模
           式描述如下：
                发起者                             响应者
               -----------                        -----------
                HDR, SA                     -->
                                            <--    HDR, SA
                HDR, KE, Ni                 -->
                                            <--    HDR, KE, Nr
                HDR*, IDii, [ CERT, ] SIG_I -->
                                            <--    HDR*