API接口入门(二):API接口的签名验签和加解密原理

21 评论 34742 浏览 308 收藏 10 分钟

上篇文章:《API接口入门(一):读懂API接口文档》已经解释了什么是API接口,API接口的基本交互是怎么样的?读完后我们可以知道,API接口应用实际上是系统间通讯的过程,A向B传输参数,B向A返回结果。那本章将讲解API接口传输的签名和加密。

适合阅读的人群:产品经理及求职者

本文目录:

  1. API接口为什么要签名加密?
  2. API接口如何加密?

一、API接口为什么要签名加密?

想象一个场景:一位许久不见的好兄弟,突然在微信里面跟你说“兄弟,借我1万应急呗”,你会怎么反应?

我想大部分人马上的反应就是:是不是被盗号了?他是本人吗?

实际上这是我们日常生活中常见的通讯行为,系统间调用API和传输数据的过程无异于你和朋友间的微信沟通,所有处于开放环境的数据传输都是可以被截取,甚至被篡改的。因而数据传输存在着极大的危险,所以必须加密。

加密核心解决两个问题:

  1. 你是本人吗?(签名验签)
  2. 你传过来的信息是对的吗?(加密解密)

二、API接口如何签名验签和加密解密?

古代人写信通过邮差传信,路途遥远,他们为了避免重要的内容被发现,决定用密文来写信,比如我想表达“八百标兵上北坡”,我写成800north,并且收件人也知道怎么阅读这份信息,即使路上的人截取偷看了,也看不懂你们在说的什么意思。同时我在文末签上我的字迹,在盒子里放上我的信物(比如一片羽毛等等),这样收件人也就知道这份信是我寄出的了。

这被称为“对称性密码”,也就是加密的人用A方式加密,解密的人用A方式解密,有什么缺点呢?

如果你经常传输,这就很容易被发现了密码规律,比如我很快就知道你寄信都会带上一片羽毛,那我以后也可以搞一片羽毛来冒充你了。加上,如果我要给很多人寄信,我就要跟每个人告诉我的加密方式,说不准有一个卧底就把你的加密方式出卖了。

因为互联网传输的对接方数量和频率非常高,显然搞个对称性密码是不安全的。于是,基于对称性密码延伸出“非对称密码”的概念。

1. 公私钥——签名验签及加解密原理

通俗的解释:A要给B发信息,B先把一个箱子给A,A收到之后把信放进箱子,然后上锁,上锁了之后A自己也打不开,取不出来了,因为钥匙在B的手里,这样即使路上被截取了,别人也打不开箱子看里面的信息,最后B就能安全地收到A发的信了,并且信息没有泄露。

现在我们以一个单向的A发信息给B的场景进行深入了解公私钥工作原理。

  1. 发送者和接收者都有2套加解密的方法,而且他们把其中一套加密方法a和解密方法b都公开(虚线标黑);
  2. 这里提到的加解密,因为密码学过于深奥,无法解释。大家需默认加密方法是不能反推出解密方法的,解密方法是不能反推出加密方法的。a加密就必须a解密,b加密就必须b解密;
  3. 现在A需要向B发送一条信息,因为信息的内容很重要,他就用接收者B的加密方法c进行加密,这样只有B自己的解密方法c才能解开,任何人获取了都解开不了,包括A自己也解不开;
  4. 在A向B发送信息的同时,需要带上自己的签名,这个时候A用自己才知道的加密方法b进行加密,因为任何人都知道解密方法b,所以任何人都可以看到A的签字,也就是任何人都知道这条是A发出来的信息,但因为签名不是不能公开的信息,所以被解密了也没有关系。

总结:

(1)签名会被任何人获取,但因为签名内容不涉及核心内容,被获取破解是OK的。

(2)重要内容只能接收方解密,任何人获取了都无法解密。

(3)接收者B只有验证签名者是A的信息,才会执行接下来的程序。阿猫阿狗发来的信息不予执行。

捣局者C可能的情况:

(1)他获取到这条信息是A发出的,但看不明白加密的内容。

(2)他可以也用接受者B的加密方法c向接收者B发信息,但他无法冒充发送者A的签名,所以B不会接受C的请求。

(2)公私钥的非对称加密+session key对称加密

2. 公私钥的非对称加密+session key对称加密

上一小节解释的公私钥加密是标准和安全的,但因为这类非对称加密对系统运算的需求比较大,在保证安全的前提下,还是尽量希望提升程序响应的时效。所以目前主流应用的另一种加密方式是公私钥的非对称加密+session key对称加密。

  1. 当A向B发送信息的时候,不需要用到B的公私钥。
  2. A用自己的加密方法b加密签名和一条空信息,因为信息无关重要,被破解了也没关系,B利用解密方法b验证了是A发来的信息。
  3. 这个时候,接收者B用发送者A的加密方法a,加密一个有时效的加密方法给A(相当于告诉A,这2个小时,我们用这个暗号进行沟通),因为只有A有解密方法,所以别人获取了也不能知道session key是什么。
  4. A接收到session key了以后,A用这种有时效的加密函数发送重要信息,签名仍用加密方法b加密,B用同样一个加密函数解密(实际上变成了对称加密,大家都用同样的方式加解密)
  5. 2小时后,再重复第2步,更新加密方法。

3. 总结

(1)当B向A发出临时有效的加密方法之后,通讯的过程变为了对称加密;

(2)这类加密方式的核心是时效性,必须在短时间内更新,否则固定的规律容易被获取破解。

捣局者C可能的情况:

(1)他获取到B发出的session key的加密文件,无法破解session key是什么。因为解密方法在A手上;

(2)通过各种手段,C破解出session key的加解密方法,但因为时效已到,session key更新,C徒劳无功;

(3)C在时效内破解出session key,但无法冒充A的签名。

以上是2种常见的加解密方式,每个开放平台会在概述中最开始介绍API调用的安全加解密方法,这是每个对接过程中必须的准备流程,如微信企业平台在概述中就已介绍利用第2种方法(企业微信命名为access_token)进行加解密传输。

三、最后

以上就是API签名验签和加解密的基本原理,接下来我会继续更新API的请求方式等问题,同时以企业微信,微信开放平台等大型开放平台的业务解释各平台支持的现有功能。

综上,水平有限,如有纰漏,敬请指出。

 

作者:就是爱睡觉;已任职电商和金融业行业的产品岗位3年时间,目前业务以TO B业务为主,文章是用于记录自己在产品工作的思考和想法,希望有想法的小伙伴共同交流。

本文由 @就是爱睡觉 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 请问,如果破解了签名,发送空信息给B,C会接收到B的加解密方法吗?

    来自香港 回复
  2. 来自安徽 回复
  3. 精简一下,大佬看下我这写的对不对?

    签名验证
    场景:证明信息发送者身份
    过程:发送者用私钥签名,接受者用之前保存的公钥进行验证

    加密解密
    场景:发送者发送的信息不想被第三方看到
    过程:发送者用接收者公钥加密,接收者用自己的私钥解密,得到明文信息

    session key
    场景:频繁交换信息,非对称密码耗费资源较多
    过程:发送者接收者协商产生一个一次性的对称密钥,再通过非对称加密传输给对方,双方使用对称密钥进行通讯

    来自重庆 回复
    1. 我觉得你总结得很对

      来自广东 回复
  4. 第二种加解密方式怎么确认接收者B的身份呢,搅局者C可以获取到A第一次发给B的信息,通过解密冒充接收者B与发送者A进行对话

    来自湖北 回复
    1. 内容包含签名

      来自广东 回复
  5. 问:搅局者C是不是可以把B发给A的session key改掉呢?虽然C解密不了session key,但是可以让A和B无法通讯。

    来自浙江 回复
    1. 感觉是个简化模型,B发送加密方法的时候,加上一个签名就可以这种情况了吧

      来自广东 回复
  6. 大佬确实很厉害 对新人也很友好

    来自湖南 回复
  7. 写的太好啦~清晰易懂

    来自浙江 回复
  8. 非常感谢!简直大领悟了!豁然开朗

    来自安徽 回复
  9. 您好,请问对签名加密,又公开解密方法,相当于没有加密,那为什么要做加密这一步骤呢?

    来自广东 回复
    1. 首先是,不是所有人都能用同一方法加密这个签名对吧

      回复
  10. 对不懂技术的小白我很有用~

    来自重庆 回复
  11. 多谢老哥

    来自北京 回复
  12. 期待更多文章

    来自福建 回复
  13. 大佬牛逼

    来自陕西 回复
  14. 写的真好,留言一波

    来自上海 回复
  15. 小白看的很是满意。非常满意,感谢老哥的分享。

    来自浙江 回复
  16. 坐等更新

    回复
  17. 等你更新

    来自北京 回复