签名验签服务器原理

签名验签服务器原理

       大家好，今天我想和大家探讨一下关于签名验签服务器原理的问题。在这个话题上，有很多不同的观点和看法，但我相信通过深入探讨，我们可以更好地理解它的本质。现在，我将我的理解进行了归纳整理，让我们一起来看看吧。

1.签名算法怎么来的？

2.服务器证书的工作原理

3.数字签名服务器是通用设备吗

4.数字签名和数字证书

5.CSRF攻击预防的Token生成以及验证原理

签名算法怎么来的？

       数字签名算法分析与Hash签名

       序：这篇文章我用了近一周的时间完成，其中涉及到的RSA算法已经在上一篇《公钥密码体系》中详细的介绍过，目前数字签名中人们使用很多的还是512位与1024位的RSA算法。

       摘要： 数字签字和认证机构是电子商务的核心技术。数字签名作为目前Internet中电子商务重要的技术，不断地进行改进，标准化。本文从数字签名的意义出发，详细介绍了数字签名中涉及到的内容与算法，并自行结合进行改进。

       关键词：Internet　公钥加密 Hash函数 电子商务　加密　数字签名　

       数字签名简介

       我们对加解密算法已经有了一定理解,可以进一步讨论"数字签名"（注意不要与数字认证混淆）的问题了,即如何给一个计算机文件进行签字。数字签字可以用对称算法实现，也可以用公钥算法实现。但前者除了文件签字者和文件接受者双方，还需要第三方认证，较麻烦；通过公钥加密算法的实现方法，由于用秘密密钥加密的文件，需要靠公开密钥来解密，因此这可以作为数字签名，签名者用秘密密钥加密一个签名（可以包括姓名、证件号码、短信息等信息），接收人可以用公开的、自己的公开密钥来解密，如果成功，就能确保信息来自该公开密钥的所有人。

       公钥密码体制实现数字签名的基本原理很简单，假设A要发送一个电子文件给B，A、B双方只需经过下面三个步骤即可：

       1． A用其私钥加密文件，这便是签字过程

       2． A将加密的文件送到B

       3． B用A的公钥解开A送来的文件

       这样的签名方法是符合可靠性原则的。即：

       签字是可以被确认的，

       签字是无法被伪造的，

       签字是无法重复使用的，

       文件被签字以后是无法被篡改的，

       签字具有无可否认性，

       数字签名就是通过一个单向函数对要传送的报文进行处理得到的用以认证报文来源并核实报文是否发生变化的一个字母数字串。用这几个字符串来代替书写签名或印章，起到与书写签名或印章同样的法律效用。国际社会已开始制定相应的法律、法规，把数字签名作为执法的依据。

       数字签名的实现方法

       实现数字签名有很多方法，目前数字签名采用较多的是公钥加密技术，如基于RSA Data Security公司的PKCS（Public Key Cryptography Standards）、DSA（Digital Signature Algorithm）、x.509、PGP（Pretty Good Privacy）。1994年美国标准与技术协会公布了数字签名标准（DSS）而使公钥加密技术广泛应用。同时应用散列算法（Hash）也是实现数字签名的一种方法。

       非对称密钥密码算法进行数字签名

       算法的含义：

       非对称密钥密码算法使用两个密钥：公开密钥和私有密钥，分别用于对数据的加密和解密，即如果用公开密钥对数据进行加密，只有用对应的私有密钥才能进行解密；如果用私有密钥对数据进行加密，则只有用对应的公开密钥才能解密。

       使用公钥密码算法进行数字签名通用的加密标准有： RSA，DSA，Diffie－Hellman等。

       签名和验证过程：

       发送方（甲）首先用公开的单向函数对报文进行一次变换，得到数字签名，然后利用私有密钥对数字签名进行加密后附在报文之后一同发出。

       接收方（乙）用发送方的公开密钥对数字签名进行解密交换，得到一个数字签名的明文。发送方的公钥可以由一个可信赖的技术管理机构即认证中心（CA）发布的。

       接收方将得到的明文通过单向函数进行计算，同样得到一个数字签名，再将两个数字签名进行对比，如果相同，则证明签名有效，否则无效。

       这种方法使任何拥有发送方公开密钥的人都可以验证数字签名的正确性。由于发送方私有密钥的保密性，使得接受方既可以根据结果来拒收该报文，也能使其无法伪造报文签名及对报文进行修改，原因是数字签名是对整个报文进行的，是一组代表报文特征的定长代码，同一个人对不同的报文将产生不同的数字签名。这就解决了银行通过网络传送一张支票，而接收方可能对支票数额进行改动的问题，也避免了发送方逃避责任的可能性。

       对称密钥密码算法进行数字签名

       算法含义

       对称密钥密码算法所用的加密密钥和解密密钥通常是相同的，即使不同也可以很容易地由其中的任意一个推导出另一个。在此算法中，加、解密双方所用的密钥都要保守秘密。由于计算机速度而广泛应用于大量数据如文件的加密过程中，如RD4和DES，用IDEA作数字签名是不提倡的。

       使用分组密码算法数字签名通用的加密标准有：DES，Tripl－DES,RC2,RC4,CAST等。

       签名和验证过程

       Lamport发明了称为Lamport-Diffle的对称算法：利用一组长度是报文的比特数（n）两倍的密钥A，来产生对签名的验证信息，即随机选择2n个数B，由签名密钥对这2n个数B进行一次加密交换，得到另一组2n个数C。

       发送方从报文分组M的第一位开始，依次检查M的第I位，若为0时，取密钥A的第i位，若为1则取密钥A的第i+1位；直至报文全部检查完毕。所选取的n个密钥位形成了最后的签名。

       接受方对签名进行验证时，也是首先从第一位开始依次检查报文M，如果M的第i位为0时，它就认为签名中的第i组信息是密钥A的第i位，若为1则为密钥A的第i+1位；直至报文全部验证完毕后，就得到了n个密钥，由于接受方具有发送方的验证信息C，所以可以利用得到的n个密钥检验验证信息，从而确认报文是否是由发送方所发送。

       这种方法由于它是逐位进行签名的，只有有一位被改动过，接受方就得不到正确的数字签名，因此其安全性较好，其缺点是：签名太长（对报文先进行压缩再签名，可以减少签名的长度）；签名密钥及相应的验证信息不能重复使用，否则极不安全。

       结合对称与非对称算法的改进

       对称算法与非对称算法各有利弊，所以结合各自的优缺点进行改进，可以用下面的模块进行说明：

       Hash算法进行数字签名

       Hash算法也称作散列算法或报文摘要，Hash算法将在数字签名算法中详细说明。

       Hash算法数字签字通用的加密标准有： SHA－1，MD5等。

       数字签名算法

       数字签名的算法很多,应用最为广泛的三种是: Hash签名、DSS签名、RSA签名。这三种算法可单独使用，也可综合在一起使用。数字签名是通过密码算法对数据进行加、解密变换实现的，常用的HASH算法有MD2、MD5、SHA-1，用DES算法、RSA算法都可实现数字签名。但或多或少都有缺陷，或者没有成熟的标准。

       Hash签名

       Hash签名是最主要的数字签名方法，也称之为数字摘要法（digital digest）、数字指纹法（digital finger print）。它与RSA数字签名是单独的签名不同，该数字签名方法是将数字签名与要发送的信息紧密联系在一起，它更适合于电子商务活动。将一个商务合同的个体内容与签名结合在一起，比合同和签名分开传递，更增加了可信度和安全性。下面我们将详细介绍Hash签名中的函数与算法。

服务器证书的工作原理

       写在前面：加密和签名是两回事，加密的目的是防止信息泄露，签名的目的是防止篡改和伪造

        MD5、SHA-1、SHA-256、HMAC-SHA256等属于哈希算法，计算数字摘要，不可逆，有碰撞

        DES、AES、RSA等属于加密算法，对数据进行加解密，可逆

        MD5签名通常先按照一定规则排列待签名数据，进行加盐（拼key），然后使用MD5摘要算法计算摘要，得到的散列值即为sign

        MD5验签即按照相同的规则排列待签名数据，使用相同的key，然后使用MD5摘要算法计算摘要，对比自己得到的sign值和对方传过来的sign值是否相等

       

参考资料：

MD5算法原理

        MD5作为一种散列算法，虽然很难发生散列碰撞，但是仍然存在两种不同数据会发生碰撞

        已知明文A，可以计算得到另一个明文B和A的MD5值相同，但是并不能保证B是一段有意义的文字

        未知明文A，已知MD5值X，无法计算得到明文A

        暴力枚举、字典法、彩虹表法（对字典表的优化）

       

参考资料：

MD5破解方法

        网上的这篇文章说的比较清楚： SHA1算法原理

        SHA-1一般被应用于数字证书的签名哈希算法，或者RSA签名中的哈希算法

        经过权威机构证实，sha1算法的不安全性越来越高，sha指纹造假成本越来越低，随即微软、谷歌等IT巨头相继发布弃用sha1哈希算法声明，第三方认证机构自2016年1月1日起，将全面停止签发SHA1算法的数字证书。

        网上的这篇文章说的比较清楚： SHA256算法原理

        SHA-1算法和SHA-256算法并不是近亲，SHA-256算法属于SHA-2算法。SHA-1是160位的哈希值，而SHA-2是组合值，有不同的位数，SHA-256就是256位的SHA-2。SHA-1算法和MD5算法都是由MD4算法导出，所以这俩是近亲。

        顾名思义，慢哈希就是很慢，主要为了防止暴力破解。由于慢，通常都用在客户端或者对性能没什么要求的场景

        业内通用的一般是MD5(MD5(password)+salt)或SHA256(SHA256(password)+salt)

        客户端进行SHA256(password)，并传输给服务端，服务端进行SHA256(SHA256(password)+salt)

        慢

        ps:小数据如果既要加密又要签名，可以直接使用RSA私钥加密整个数据，接收方公钥解密，不做签名

        比如赠送代金券的接口，拿到一个真实请求以后重复调用。

        解决方案：

数字签名服务器是通用设备吗

       TLS/SSL的功能实现主要依赖于三类基本算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

       解决上述身份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构CA。CA 负责核实公钥的拥有者的信息，并颁发认证"证书"，同时能够为使用者提供证书验证服务，即PKI体系。

       基本的原理为，CA负责审核信息，然后对关键信息利用私钥进行"签名"，公开对应的公钥，客户端可以利用公钥验证签名。CA也可以吊销已经签发的证书，基本的方式包括两类 CRL 文件和 OCSP。CA使用具体的流程如下：

数字签名和数字证书

       不是。专用数字签名服务器是一种经过定制的非通用设备，公安部第一研究所研发的专用数字签名服务器不兼容也不允许其他非公安部第一研究所指定的专用数字签名服务器，以杜绝非法设备接入带来安全风险。签名验签服务器又称为数字签名服务器，是对各种类型的电子数据给出基于数字证书的数字签名服务，并向签名数据验证其签名的真实性与有效性的专用服务器。

CSRF攻击预防的Token生成以及验证原理

        数字签名是一种用于信息真实性 和完整性 校验的手段，一套数字签名包含签名和验证两种运算。下面是一套简单的数字签名示意图。

        数字签名使用非对称加密 技术。每个人都有一对钥匙，私钥只有本人知道，公钥公开，私钥签名，公钥验签。

        在进行信息传递时，信息发送者用私钥生成签名并将公钥一起发送给信息接收者，接收者使用公钥验签。上述过程中信息完整性得到校验，但发送者的身份是否合法无法得知（因为任何人都可以声称自己是合法的），因此引入了身份认证机构 。

        身份认证机构是信息接收者 能信任的机构，所有的公钥必须向该机构进行注册。注册后身份认证机构给发送者颁发一数字证书 。对文件签名后，发送者把此数字证书连同文件及签名一起发给信息接收者，接收者向身份认证机构求证是否真地是用发送者密钥签发的文件。

        数字证书是一种电子档案，用来证明公钥拥有者的身份。此档案包含了公钥信息、拥有者身份信息（主体）、以及数字证书认证机构（发行者）对该文件的数字签名。

        证书的本质就是对公钥加数字签名，认证机构用自己的私钥对需要认证的人（或组织机构）的公钥进行数字签名并生成证书。

        我们需要了解以下几种类型的证书

        自签证书

        用户可以自己生成数字证书，不过没有任何可信赖的人签名，它主要用于小范围测试，这种自签名证书通常不会被广泛信任，使用时可能会遇到电脑软件的安全警告。

        根证书

        根证书获得广泛认可，通常已预先安装在各种软体（包括操作系统、浏览器、电邮软件等），作为信任链的起点，来自于公认可靠的政府机关、证书颁发机构公司、非营利组织等，与各大软件商透过严谨的核认程序才在不同的软件广泛部署。由于部署程序复杂费时，需要行政人员的授权及机构法人身份的核认，一张根证书有效期可能长达二十年以上。在某些企业，也可能会在内部电脑自行安装企业自签的根证书，以支援内部网的企业级软件；但是这些证书可能未被广泛认可，只在企业内部适用。

        中介证书

        认证机构的一个重要任务就是为客户签发证书，虽然广泛认可的认证机构都已拥有根证书，相对应的私钥可用以签署其他证书，但因为密钥管理和行政考虑，一般会先行签发中介证书，才为客户作数位签署。中介证书的有效期会较根证书为短，并可能对不同类别的客户有不同的中介证书作分工。

        TLS服务器证书

        网站在互联网上提供服务时，域名就是服务器证书上主体，相关机构名称则写在组织或单位一栏上。证书和私钥会安装在服务器。客户端的软件（如浏览器）会执行认证路径验证算（Certification path validation algorithm）以确保安全，如果未能肯定加密通道是否安全（例如证书上的主体名称不对应网站域名、伺服器使用了自签证书、或加密算法不够强），可能会警告用户。

        TLS客户端证书

        客户端证书包含电子邮件地址或个人姓名，而不是主机名。客户端证书比较不常见，因为考虑到技术门槛及成本因素，通常都是由服务提供者验证客户身份，而不是依赖第三方认证机构。通常，需要使用到客户端证书的服务都是内部网的企业级软件，他们会设立自己的内部根证书，由企业的技术人员在企业内部的电脑安装相关客户端证书以便使用。在公开的互联网，大多数网站都是使用登入密码和Cookie来验证用户，而不是客户端证书。

        根证书（自签证书）、中介证书和终端实体（TLS服务器/客户端）证书的形成如下信任链

        证书一般遵从X.509格式规范

        证书可以二进制或 Base64 形式储存，常见的文件扩展名有.cer、.crt、.der和.pem。如果把证书和私钥一起储存，则可以使用PKCS#12（.p12）格式。

        我们在写对外 API 时，针对信息传递的安全考虑，做如下设计

        我们使用 SHA256withRSA 进行签名，下面是一个Java简单例子

       token由msg、separator、signature三部分组成

        msg由客户端标识信息(uid、did)、随机字符主体、过期时间戳两部分组成。

        用符号分隔msg部分和加密后的signature签名部分，比如“$”、"."等

        signature签名，是对上面提到的msg，按照msg中提到的msg的信息部分，按照特定的密匙进行加密。

        token = base64(msg)格式化..base64(sha256("密匙", msg))

        当用户从客户端，得到token，再次提交给服务器的时候，服务器先判断token的有效性，如果有效则处理请求。

        服务器对客户端发来的token进行解构为msg、separator、signature三部分。

        服务器先验证token是否还具有时效性，如果不具有时效性则拒绝访问。

        服务器对客户端发送的信息进行签名，如果得到的签名与客户端发来的签名相同，则token有效

        JWT由以下三部分组成：

        即：

        Header 部分是一个 JSON 对象，描述 JWT 的元数据，通常是下面的样子。

        alg属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）

        typ属性表示这个令牌（token）的类型（type），JWT 令牌统一写为JWT。

        Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用。

        除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子:

        注意，JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。

        这个 JSON 对象也要使用 Base64URL 算法转成字符串。

        Signature 部分是对前两部分的签名，防止数据篡改。

        首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名:

        算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，就可以返回给用户。

        前面提到，Header 和 Payload 串型化的算法是 Base64URL。这个算法跟 Base64 算法基本类似，但有一些小的不同。

        JWT 作为一个令牌（token），有些场合可能会放到 URL（比如 api.example.com/?token=xxx）。Base64 有三个字符+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_ 。这就是 Base64URL 算法。

        客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

        此后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。

        Authorization: Bearer <token>

        另一种做法是，跨域的时候，JWT 就放在 POST 请求的数据体里面。

       好了，今天关于签名验签服务器原理就到这里了。希望大家对签名验签服务器原理有更深入的了解，同时也希望这个话题签名验签服务器原理的解答可以帮助到大家。