数字签名与验签

题目八 数字签名与验签

【题目描述】

在网银转账，或通过商户支付订单的过程中，需要对用户的交易数据进行签名，同时，服务端对用户提交的数据签名进行验证，确保数据的有效性以及完整性。

现假设以下场景，实现数字签名与验证：

1.服务端生成CA根证书，并用CA根证书签发一张用户证书。

2.用户在网银上进行转账，并使用证书对交易数据进行签名，然后提交交易请求。

3.服务端对用户提交签名数据进行验证，验证通过则提交转账交易到后端系统，否则告知转账失败。

【试题要求】

具体要求如下：

1.新建maven工程。

2.实现数据签名程序接口，输入为签名源数据，返回base64编码的数字签名。具体要求，客户端使用user1.jks中的用户证书，调用bouncycastle相关接口对源数据进行签名，数字签名格式为PKCS#7，不包含

源数据(Detach方式)。

3.实现签名验证接口，输入为base64编码的数字签名和源数据，成功返回true，失败返回false，并打印具体失败信息。具体要求，服务端使用user1.jks中的CA证书，调用bouncycastle相关接口，对签名数据进行校验，并校验签名证书的有效性，包括是否过期，是否生效，以及校验签名证书是否由CA根证书颁发。

其他：

1、user1.jks包含用户证书的公钥、私钥以及CA证书。其中用户证书alias为user1，CA证书alias为rootca，user1.jks所有密码均为123456。

2、签名源数据为： {"orderId":"1234","amount":"100"}

3、bouncycastle 依赖版本如下：

        <dependency>

            <groupId>org.bouncycastle</groupId>

            <artifactId>bcmail-jdk15on</artifactId>

            <version>1.56</version>

        </dependency>

        <dependency>

            <groupId>org.bouncycastle</groupId>

            <artifactId>bcprov-jdk15on</artifactId>

            <version>1.56</version>

        </dependency>

【输入输出】 

1、模拟客户端数字签名，调用签名接口，输入为： {"orderId":"1234","amount":"100"}，打印出base64编码签名结果。

2、模拟服务端验证签名，调用验签接口，输入为： {"orderId":"1234","amount":"100"}，以及测试步骤1的签名结果，打印验证结果，包含具体要求中3个验证项。

【基线时间】

3小时

【评分标准】

正确性100%

完成正确的数字签名得30分，验证签名正确得70分

笔记

1.加密--公钥
  解密--私钥
  签名--私钥
  验证--公钥
2.1）公钥和私钥成对出现
  2）公开的密钥叫公钥，只有自己知道的叫私钥
  3）用公钥加密的数据只有对应的私钥可以解密
  4）用私钥加密的数据只有对应的公钥可以解密
  5）如果可以用公钥解密，则必然是对应的私钥加的密
  6）如果可以用私钥解密，则必然是对应的公钥加的密
3.公钥加密，私钥解密——用于保密信息
4.私钥加密，公钥解密——用于数字签名:
  严格来说，这里说的私钥加密是用私钥对摘要进行加密，
  接收方可以用公钥解密，解密成功则可验证信息的发送者是私钥的拥有人。
5.数字签名量两部分:
  数字签名-第一部分：证明这消息是你发的。
                  -->用私钥对摘要进行加密，接收方可以用公钥解密，解密成功则可验证信息的
                     发送者是私钥的拥有人
  数字签名-第二部分：证明这消息内容确实是完整的.也就是没有经过任何形式的篡改（包括替换、缺少、新增）
                  -->把你公告的原文做一次哈希（md5或者sha1都行），然后用你的私钥加密这段哈希
                     作为签名，并一起公布出去。当别人收到你的公告时，他可以用你的公钥解密你的
                     签名，如果解密成功，并且解密出来的哈希值确实和你的公告原文一致，那么他就
                     证明了两点：这消息确实是你发的，而且内容是完整的
6.对公钥进行认证——数字证书: 黑客可以替换你的公钥，然后用他的私钥做数字签名给你发信息，而你用黑客
                        伪造的公钥能成功验证，会让你误认为消息来源没变。
                        这种情况下需要CA(证书中心certificate authority)对公钥进行认证。
                        证书中心用自己的私钥，对信息发送者的公钥和一些相关信息一起加密，
                        生成"数字证书"（Digital Certificate）
7.对称与非对称算法:
     HTTPS一般使用了以下算法，其中就包括非对称和对称加密算法：
     非对称加密算法：RSA，DSA/DSS, 用于在握手过程中加密生成的密码
     对称加密算法：AES，RC4，3DES, 用于对真正传输的数据进行加密
     HASH算法：MD5，SHA1，SHA256, 用于验证数据的完整性
8.HTTPS的工作原理
      HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立
      双方加密传输数据的密码信息。TLS/SSL中使用了非对称加密，对称加密以及HASH算法
      1.浏览器将自己支持的一套加密规则发送给网站。
      2.网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面
        包含了网站地址，加密公钥，以及证书的颁发机构等信息。
      3.获得网站证书之后浏览器要做以下工作：
        a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），
           如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
        b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
        c) 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。
      4.网站接收浏览器发来的数据之后要做以下的操作：
        a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
        b) 使用密码加密一段握手消息，发送给浏览器。
      5.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前
        浏览器生成的随机密码并利用对称加密算法进行加密。

　　参考 链接 https://blog.csdn.net/willpower1li/article/details/79494809