API接口入門(二):API接口的簽名驗簽和加解密原理

21 評論 36063 瀏覽 321 收藏 10 分鐘
🔗 产品经理的核心价值是能够准确发现和满足用户需求,把用户需求转化为产品功能,并协调资源推动落地,创造商业价值

上篇文章:《API接口入門(一):讀懂API接口文檔》已經(jīng)解釋了什么是API接口,API接口的基本交互是怎么樣的?讀完后我們可以知道,API接口應(yīng)用實際上是系統(tǒng)間通訊的過程,A向B傳輸參數(shù),B向A返回結(jié)果。那本章將講解API接口傳輸?shù)暮灻图用堋?/p>

適合閱讀的人群:產(chǎn)品經(jīng)理及求職者

本文目錄:

  1. API接口為什么要簽名加密?
  2. API接口如何加密?

一、API接口為什么要簽名加密?

想象一個場景:一位許久不見的好兄弟,突然在微信里面跟你說“兄弟,借我1萬應(yīng)急唄”,你會怎么反應(yīng)?

我想大部分人馬上的反應(yīng)就是:是不是被盜號了?他是本人嗎?

實際上這是我們?nèi)粘I钪谐R姷耐ㄓ嵭袨椋到y(tǒng)間調(diào)用API和傳輸數(shù)據(jù)的過程無異于你和朋友間的微信溝通,所有處于開放環(huán)境的數(shù)據(jù)傳輸都是可以被截取,甚至被篡改的。因而數(shù)據(jù)傳輸存在著極大的危險,所以必須加密。

加密核心解決兩個問題:

  1. 你是本人嗎?(簽名驗簽)
  2. 你傳過來的信息是對的嗎?(加密解密)

二、API接口如何簽名驗簽和加密解密?

古代人寫信通過郵差傳信,路途遙遠,他們?yōu)榱吮苊庵匾膬?nèi)容被發(fā)現(xiàn),決定用密文來寫信,比如我想表達“八百標(biāo)兵上北坡”,我寫成800north,并且收件人也知道怎么閱讀這份信息,即使路上的人截取偷看了,也看不懂你們在說的什么意思。同時我在文末簽上我的字跡,在盒子里放上我的信物(比如一片羽毛等等),這樣收件人也就知道這份信是我寄出的了。

這被稱為“對稱性密碼”,也就是加密的人用A方式加密,解密的人用A方式解密,有什么缺點呢?

如果你經(jīng)常傳輸,這就很容易被發(fā)現(xiàn)了密碼規(guī)律,比如我很快就知道你寄信都會帶上一片羽毛,那我以后也可以搞一片羽毛來冒充你了。加上,如果我要給很多人寄信,我就要跟每個人告訴我的加密方式,說不準(zhǔn)有一個臥底就把你的加密方式出賣了。

因為互聯(lián)網(wǎng)傳輸?shù)膶臃綌?shù)量和頻率非常高,顯然搞個對稱性密碼是不安全的。于是,基于對稱性密碼延伸出“非對稱密碼”的概念。

1. 公私鑰——簽名驗簽及加解密原理

通俗的解釋:A要給B發(fā)信息,B先把一個箱子給A,A收到之后把信放進箱子,然后上鎖,上鎖了之后A自己也打不開,取不出來了,因為鑰匙在B的手里,這樣即使路上被截取了,別人也打不開箱子看里面的信息,最后B就能安全地收到A發(fā)的信了,并且信息沒有泄露。

現(xiàn)在我們以一個單向的A發(fā)信息給B的場景進行深入了解公私鑰工作原理。

  1. 發(fā)送者和接收者都有2套加解密的方法,而且他們把其中一套加密方法a和解密方法b都公開(虛線標(biāo)黑);
  2. 這里提到的加解密,因為密碼學(xué)過于深奧,無法解釋。大家需默認(rèn)加密方法是不能反推出解密方法的,解密方法是不能反推出加密方法的。a加密就必須a解密,b加密就必須b解密;
  3. 現(xiàn)在A需要向B發(fā)送一條信息,因為信息的內(nèi)容很重要,他就用接收者B的加密方法c進行加密,這樣只有B自己的解密方法c才能解開,任何人獲取了都解開不了,包括A自己也解不開;
  4. 在A向B發(fā)送信息的同時,需要帶上自己的簽名,這個時候A用自己才知道的加密方法b進行加密,因為任何人都知道解密方法b,所以任何人都可以看到A的簽字,也就是任何人都知道這條是A發(fā)出來的信息,但因為簽名不是不能公開的信息,所以被解密了也沒有關(guān)系。

總結(jié):

(1)簽名會被任何人獲取,但因為簽名內(nèi)容不涉及核心內(nèi)容,被獲取破解是OK的。

(2)重要內(nèi)容只能接收方解密,任何人獲取了都無法解密。

(3)接收者B只有驗證簽名者是A的信息,才會執(zhí)行接下來的程序。阿貓阿狗發(fā)來的信息不予執(zhí)行。

搗局者C可能的情況:

(1)他獲取到這條信息是A發(fā)出的,但看不明白加密的內(nèi)容。

(2)他可以也用接受者B的加密方法c向接收者B發(fā)信息,但他無法冒充發(fā)送者A的簽名,所以B不會接受C的請求。

(2)公私鑰的非對稱加密+session key對稱加密

2. 公私鑰的非對稱加密+session key對稱加密

上一小節(jié)解釋的公私鑰加密是標(biāo)準(zhǔn)和安全的,但因為這類非對稱加密對系統(tǒng)運算的需求比較大,在保證安全的前提下,還是盡量希望提升程序響應(yīng)的時效。所以目前主流應(yīng)用的另一種加密方式是公私鑰的非對稱加密+session key對稱加密。

  1. 當(dāng)A向B發(fā)送信息的時候,不需要用到B的公私鑰。
  2. A用自己的加密方法b加密簽名和一條空信息,因為信息無關(guān)重要,被破解了也沒關(guān)系,B利用解密方法b驗證了是A發(fā)來的信息。
  3. 這個時候,接收者B用發(fā)送者A的加密方法a,加密一個有時效的加密方法給A(相當(dāng)于告訴A,這2個小時,我們用這個暗號進行溝通),因為只有A有解密方法,所以別人獲取了也不能知道session key是什么。
  4. A接收到session key了以后,A用這種有時效的加密函數(shù)發(fā)送重要信息,簽名仍用加密方法b加密,B用同樣一個加密函數(shù)解密(實際上變成了對稱加密,大家都用同樣的方式加解密)
  5. 2小時后,再重復(fù)第2步,更新加密方法。

3. 總結(jié)

(1)當(dāng)B向A發(fā)出臨時有效的加密方法之后,通訊的過程變?yōu)榱藢ΨQ加密;

(2)這類加密方式的核心是時效性,必須在短時間內(nèi)更新,否則固定的規(guī)律容易被獲取破解。

搗局者C可能的情況:

(1)他獲取到B發(fā)出的session key的加密文件,無法破解session key是什么。因為解密方法在A手上;

(2)通過各種手段,C破解出session key的加解密方法,但因為時效已到,session key更新,C徒勞無功;

(3)C在時效內(nèi)破解出session key,但無法冒充A的簽名。

以上是2種常見的加解密方式,每個開放平臺會在概述中最開始介紹API調(diào)用的安全加解密方法,這是每個對接過程中必須的準(zhǔn)備流程,如微信企業(yè)平臺在概述中就已介紹利用第2種方法(企業(yè)微信命名為access_token)進行加解密傳輸。

三、最后

以上就是API簽名驗簽和加解密的基本原理,接下來我會繼續(xù)更新API的請求方式等問題,同時以企業(yè)微信,微信開放平臺等大型開放平臺的業(yè)務(wù)解釋各平臺支持的現(xiàn)有功能。

綜上,水平有限,如有紕漏,敬請指出。

 

作者:就是愛睡覺;已任職電商和金融業(yè)行業(yè)的產(chǎn)品崗位3年時間,目前業(yè)務(wù)以TO B業(yè)務(wù)為主,文章是用于記錄自己在產(chǎn)品工作的思考和想法,希望有想法的小伙伴共同交流。

本文由 @就是愛睡覺 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 請問,如果破解了簽名,發(fā)送空信息給B,C會接收到B的加解密方法嗎?

    來自香港 回復(fù)
  2. 來自安徽 回復(fù)
  3. 精簡一下,大佬看下我這寫的對不對?

    簽名驗證
    場景:證明信息發(fā)送者身份
    過程:發(fā)送者用私鑰簽名,接受者用之前保存的公鑰進行驗證

    加密解密
    場景:發(fā)送者發(fā)送的信息不想被第三方看到
    過程:發(fā)送者用接收者公鑰加密,接收者用自己的私鑰解密,得到明文信息

    session key
    場景:頻繁交換信息,非對稱密碼耗費資源較多
    過程:發(fā)送者接收者協(xié)商產(chǎn)生一個一次性的對稱密鑰,再通過非對稱加密傳輸給對方,雙方使用對稱密鑰進行通訊

    來自重慶 回復(fù)
    1. 我覺得你總結(jié)得很對

      來自廣東 回復(fù)
  4. 第二種加解密方式怎么確認(rèn)接收者B的身份呢,攪局者C可以獲取到A第一次發(fā)給B的信息,通過解密冒充接收者B與發(fā)送者A進行對話

    來自湖北 回復(fù)
    1. 內(nèi)容包含簽名

      來自廣東 回復(fù)
  5. 問:攪局者C是不是可以把B發(fā)給A的session key改掉呢?雖然C解密不了session key,但是可以讓A和B無法通訊。

    來自浙江 回復(fù)
    1. 感覺是個簡化模型,B發(fā)送加密方法的時候,加上一個簽名就可以這種情況了吧

      來自廣東 回復(fù)
  6. 大佬確實很厲害 對新人也很友好

    來自湖南 回復(fù)
  7. 寫的太好啦~清晰易懂

    來自浙江 回復(fù)
  8. 非常感謝!簡直大領(lǐng)悟了!豁然開朗

    來自安徽 回復(fù)
  9. 您好,請問對簽名加密,又公開解密方法,相當(dāng)于沒有加密,那為什么要做加密這一步驟呢?

    來自廣東 回復(fù)
    1. 首先是,不是所有人都能用同一方法加密這個簽名對吧

      回復(fù)
  10. 對不懂技術(shù)的小白我很有用~

    來自重慶 回復(fù)
  11. 多謝老哥

    來自北京 回復(fù)
  12. 期待更多文章

    來自福建 回復(fù)
  13. 大佬牛逼

    來自陜西 回復(fù)
  14. 寫的真好,留言一波

    來自上海 回復(fù)
  15. 小白看的很是滿意。非常滿意,感謝老哥的分享。

    來自浙江 回復(fù)
  16. 坐等更新

    回復(fù)
  17. 等你更新

    來自北京 回復(fù)
专题
17017人已学习16篇文章
ERP是一种以系统化的方式,将企业内部所有的业务流程和数据进行整合和管理的软件系统。本专题的文章分享了ERP系统设计指南。
专题
124643人已学习33篇文章
小程序时代,产品经理和运营人员该如何拥抱这种变化?
专题
12561人已学习12篇文章
本专题的文章分享了系统首页设计指南。
专题
32152人已学习19篇文章
一个合格的购物车是怎么设计出来的?
专题
29400人已学习16篇文章
系统如何恰当、清晰、及时地传达给用户操作的结果或者操作对象状态的变更?本专题的文章提供了有效的页面操作反馈设计指南。
专题
13615人已学习12篇文章
本专题的文章分享了CRM的入门知识,分享了CRM是什么。