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

21 評論 35841 瀏覽 318 收藏 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. 等你更新

    來自北京 回復