API接口入門(二):API接口的簽名驗簽和加解密原理
上篇文章:《API接口入門(一):讀懂API接口文檔》已經解釋了什么是API接口,API接口的基本交互是怎么樣的?讀完后我們可以知道,API接口應用實際上是系統間通訊的過程,A向B傳輸參數,B向A返回結果。那本章將講解API接口傳輸的簽名和加密。
適合閱讀的人群:產品經理及求職者
本文目錄:
- API接口為什么要簽名加密?
- API接口如何加密?
一、API接口為什么要簽名加密?
想象一個場景:一位許久不見的好兄弟,突然在微信里面跟你說“兄弟,借我1萬應急唄”,你會怎么反應?
我想大部分人馬上的反應就是:是不是被盜號了?他是本人嗎?
實際上這是我們日常生活中常見的通訊行為,系統間調用API和傳輸數據的過程無異于你和朋友間的微信溝通,所有處于開放環境的數據傳輸都是可以被截取,甚至被篡改的。因而數據傳輸存在著極大的危險,所以必須加密。
加密核心解決兩個問題:
- 你是本人嗎?(簽名驗簽)
- 你傳過來的信息是對的嗎?(加密解密)
二、API接口如何簽名驗簽和加密解密?
古代人寫信通過郵差傳信,路途遙遠,他們為了避免重要的內容被發現,決定用密文來寫信,比如我想表達“八百標兵上北坡”,我寫成800north,并且收件人也知道怎么閱讀這份信息,即使路上的人截取偷看了,也看不懂你們在說的什么意思。同時我在文末簽上我的字跡,在盒子里放上我的信物(比如一片羽毛等等),這樣收件人也就知道這份信是我寄出的了。
這被稱為“對稱性密碼”,也就是加密的人用A方式加密,解密的人用A方式解密,有什么缺點呢?
如果你經常傳輸,這就很容易被發現了密碼規律,比如我很快就知道你寄信都會帶上一片羽毛,那我以后也可以搞一片羽毛來冒充你了。加上,如果我要給很多人寄信,我就要跟每個人告訴我的加密方式,說不準有一個臥底就把你的加密方式出賣了。
因為互聯網傳輸的對接方數量和頻率非常高,顯然搞個對稱性密碼是不安全的。于是,基于對稱性密碼延伸出“非對稱密碼”的概念。
1. 公私鑰——簽名驗簽及加解密原理
通俗的解釋:A要給B發信息,B先把一個箱子給A,A收到之后把信放進箱子,然后上鎖,上鎖了之后A自己也打不開,取不出來了,因為鑰匙在B的手里,這樣即使路上被截取了,別人也打不開箱子看里面的信息,最后B就能安全地收到A發的信了,并且信息沒有泄露。
現在我們以一個單向的A發信息給B的場景進行深入了解公私鑰工作原理。
- 發送者和接收者都有2套加解密的方法,而且他們把其中一套加密方法a和解密方法b都公開(虛線標黑);
- 這里提到的加解密,因為密碼學過于深奧,無法解釋。大家需默認加密方法是不能反推出解密方法的,解密方法是不能反推出加密方法的。a加密就必須a解密,b加密就必須b解密;
- 現在A需要向B發送一條信息,因為信息的內容很重要,他就用接收者B的加密方法c進行加密,這樣只有B自己的解密方法c才能解開,任何人獲取了都解開不了,包括A自己也解不開;
- 在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對稱加密。
- 當A向B發送信息的時候,不需要用到B的公私鑰。
- A用自己的加密方法b加密簽名和一條空信息,因為信息無關重要,被破解了也沒關系,B利用解密方法b驗證了是A發來的信息。
- 這個時候,接收者B用發送者A的加密方法a,加密一個有時效的加密方法給A(相當于告訴A,這2個小時,我們用這個暗號進行溝通),因為只有A有解密方法,所以別人獲取了也不能知道session key是什么。
- A接收到session key了以后,A用這種有時效的加密函數發送重要信息,簽名仍用加密方法b加密,B用同樣一個加密函數解密(實際上變成了對稱加密,大家都用同樣的方式加解密)
- 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協議
請問,如果破解了簽名,發送空信息給B,C會接收到B的加解密方法嗎?
牛
精簡一下,大佬看下我這寫的對不對?
簽名驗證
場景:證明信息發送者身份
過程:發送者用私鑰簽名,接受者用之前保存的公鑰進行驗證
加密解密
場景:發送者發送的信息不想被第三方看到
過程:發送者用接收者公鑰加密,接收者用自己的私鑰解密,得到明文信息
session key
場景:頻繁交換信息,非對稱密碼耗費資源較多
過程:發送者接收者協商產生一個一次性的對稱密鑰,再通過非對稱加密傳輸給對方,雙方使用對稱密鑰進行通訊
我覺得你總結得很對
第二種加解密方式怎么確認接收者B的身份呢,攪局者C可以獲取到A第一次發給B的信息,通過解密冒充接收者B與發送者A進行對話
內容包含簽名
問:攪局者C是不是可以把B發給A的session key改掉呢?雖然C解密不了session key,但是可以讓A和B無法通訊。
感覺是個簡化模型,B發送加密方法的時候,加上一個簽名就可以這種情況了吧
大佬確實很厲害 對新人也很友好
寫的太好啦~清晰易懂
非常感謝!簡直大領悟了!豁然開朗
您好,請問對簽名加密,又公開解密方法,相當于沒有加密,那為什么要做加密這一步驟呢?
首先是,不是所有人都能用同一方法加密這個簽名對吧
對不懂技術的小白我很有用~
多謝老哥
期待更多文章
大佬牛逼
寫的真好,留言一波
小白看的很是滿意。非常滿意,感謝老哥的分享。
坐等更新
等你更新