去中心化的jwt（二）HS256、RS256、分级；rsa签名与对称签名【重要】

1

HS256

发送端：原文+签名

签名=sha256（原文+对称密钥）

接收端：sha256（原文+自己的对称密钥），跟发送来的签名比较

 

2

RS256

发送端：原文+签名

签名=私钥（sha256（原文））

接收端：

公钥解开签名，自己sha256（原文）与解开的内容比较

 

3

用jwt无状态应该建立分级接口制度，哪些接口容忍黑名单的token的，则继续保持其无状态

关键接口退化为中心化

 

 

 

4 设计openapi

4.1 现代公钥密码学里面，公钥加密和私钥加签是解决截然不同的问题

公钥加密：解决窥视问题
私钥加签：解决篡改问题

为什么我们openai request加签？
防止接口伪造的报文直接进入

为什么request不加密？
因为唯一的参数userId不是敏感信息，没有加密价值

为什么我们response加密？
因为PII信息，必须公钥加密，全世界能看报文的只有他们的私钥

为什么我们response不加签？
因为没有篡改价值

 

4.2 公钥不同于证书，具有公开属性，理论上可以hardcode

证书具有私钥属性，所以证书需要限制访问权限，比如KMS

 

非对称加密：

后端生成临时pair，公钥给前端，再生成随机数+过期时间戳，都给前端

前端公钥（大脑里的pin，或面容token，或totp token ++ 随机数+时间戳）

后端解开，先看随机数存在不存在（随机数只存到过期时间戳结束），存在则处理，处理完了删了随机数防重放

是否可以对称加密？

后端生成随机数+过期时间戳给前端

前端 hs256（随机数+过期timestamp+对称密钥即PIN）

后端先看明文随机数存在不存在（随机数只存到过期时间戳结束），存在则拿着数据库里的PIN加上明文随机数和时间戳，处理完了删了随机数防重放

如果超过时间戳来重放，伪造一个期限内的时间戳，则验签过不了

 

 

 

4.3 为什么我们不信任传输层的TLS
因为握手发起方是三方，而大多数后端程序员握手时不会验证对方的公钥/证书/CA链，意味着传输层是不可信的

 

 

5 hs256 vs rs256

选HS256:仅限单一内部服务或网关与后端服务之间，且网络绝对可信、密钥极易轮转的场景。
选RS256(更推荐):微服务多系统调用、第三方开放平台(如OAuth2.0)、或前端直接验证JWT的场景。因为这能确保只有认证中心能发Token，下游服务只能验，即使公钥泄露也无法伪造。
避坑提醒:千万别把HS256的密钥硬编码在前端代码里，这等于把门钥匙交给所有人;而RS256的公钥可以放心放在前端用于本地验签

一句话，假如jwt token要签发者和验证者分权，则RS256；比如要只有网关签发，普通应用只有验证而没有签发权限

 

6 根公钥 vs 根证书

6.1 签名

6.1.1 CA根证书（公钥）内嵌操作系统

6.1.2 中间CA上报给CA公钥，

CA私钥（sha256（中间CA公钥+等等）== 中间CA证书

6.1.3 末端服务上报给中间CA公钥，中间CA验证域名所有权

中间CA私钥（sha256（末端公钥+等等common name-CN和subject alternative name-SAN等）==末端证书

6.2 验证

6.2.1 解开中间CA证书，拿出公钥，验证签名和CN和SAN与地址栏

6.2.2 拿根证书（公钥）验证中间CA签名

6.2.3 至于为什么要根证书，不要根公钥，ds也不知道

我：如果操作系统的根公钥能篡改，根证书一样能篡改
ds：你这个推理完全正确，逻辑上无懈可击!
如果攻击者都能替换你系统里的根公钥了，那确实也能替换完整的根证书。从防篡改的角度看，存公钥和存证书，安全性没有区别。