現在指紋登入是一種很常見的登入方式，特别是在金融類APP中，使用指紋進行登入、支付的特别多。指紋登入本身是一種指紋身份認證技術，通過識别目前使用者的指紋資訊，進而确認使用者在系統内的注冊身份。
指紋認證得以流行，我認為有兩個關鍵點：
一是簡便，沒有了忘記密碼的煩惱，也免去了輸入密碼的繁瑣。
二是安全，能夠用在支付環節，這就說明其可以達到金融級别的安全。
這篇文章就來簡單看下指紋認證是如何做到以上兩點的，其中有哪些坑，有哪些坎。
指紋識别的原理
指紋認證的曆史其實是很悠久的，在我國唐代指紋已經廣泛應用于文書契約，宋代手印已正式成為刑事訴訟的物證，這說明人們早就認識到了個體指紋的獨特性，并且有了成熟的識别方法。對于計算機指紋識别，也是去尋找指紋的獨特性，這裡僅做簡單的介紹：
有一個關鍵概念：指紋特征點，常見的特征點有指紋中的端點和分叉點，算法中通常記錄它們的位置和方向。程式通過光學傳感器采集指紋圖像，提取指紋特征點，用數學表達式描述它們，稱為指紋模版。注冊指紋時把指紋模版儲存到資料庫或其它存儲中；驗證指紋時，先提取目前指紋的特征點，再和已記錄的指紋模版進行比對，比對度達到一定的門檻值就算比對成功。
對于指紋識别的兩個安全問題：
- 指紋圖像洩漏問題：程式可以不儲存指紋圖像；指紋模版進行某種加密處理後，可以做到無法還原出指紋圖像。當然能做和做不做是兩碼事。指紋洩漏還有另一種情況，2014年德國黑客從照片中成功提取了德國國防部長的指紋，是以以後拍照時不要比劃剪刀手了，但是大部分人的賬戶應該不值得冒着巨大的風險、花費很大的力氣這樣搞，是以平常也不用太擔心，注意下就行了。
- 假指紋識别問題：萬一指紋被别人采集到了，或者制作成了指模，是不是就可以暢通無阻了呢？對應這類問題，有活體指紋檢測技術。硬體上采用電容傳感器采集溫度、心率等資料，加上光學傳感器的指紋紋路資料，進行綜合判斷；軟體上的實作則一般通過機器學習的方式進行識别。但是兩者對假指紋的識别率可能都不太理想，可見的廠商宣傳也不多，其中原因可能是因為仿生技術太牛逼了，這裡也沒找到太多有價值的資訊。實際應用在金融領域時，金融服務商必然采取了更多的手段來降低安全風險，而不是單純的看指紋認證結果，畢竟出了問題生意可能就做不下去了，是以大規模應用時的安全風險應該是有所控制的。
門禁中的指紋認證
在移動裝置廣泛采用指紋認證之前，這一技術已經得到了大範圍的應用，很多人應該都接觸過刷指紋的門禁或者考勤機。從老闆的角度看，刷指紋比刷卡更能有效的驗證員工的身份，而且成本也不高。從員工的角度看，不用多帶一張卡，更友善高效。從安全的角度考慮，指紋識别技術比較成熟，隻要不洩漏，一般也不會出問題，裝置做得好安全性還更高一些；出問題也僅在門禁這個環節，即使沒有指紋認證，也有别的方法開門，複制門禁卡或者鑰匙可能更友善；對于更重要的保護對象，應該還有更安全的的保護措施。
在門禁中使用指紋一般是先注冊，将使用者和指紋進行綁定，提取出的指紋特征資料就儲存在本地，具體注冊過程如下圖所示：
當使用者需要開門時，在指紋機刷指紋，指紋機會提取目前指紋的特征值，然後和本地存儲的指紋資料進行一一比對，如果比對度達到一定的門檻值，則指紋識别成功，向門禁下達開門指令，具體認證過程如下圖所示：
APP中的指紋認證
這裡說的APP指的是移動裝置系統中的第三方應用，移動裝置系統特指目前比較流行的Android和iOS等手機作業系統。
APP中的指紋認證目前常見于登入或者支付功能，因為涉及到APP自身的使用者和業務資料操作，必然需要和APP後端服務進行互動，基于安全考慮，用戶端和服務端之間也需要進行身份認證，是以APP中的指紋認證被分成了兩部分：手機本地認證和遠端認證。
本機認證
手機系統本身的指紋認證和門禁系統中的指紋認證并無本質差別：使用者首先錄入指紋，基于安全考慮，指紋的特征資料也是儲存在手機本地；使用指紋進入系統時也是先提取目前的特征值，然後和本地的指紋庫進行比對，比對上了就能進手機入系統。
和門禁系統不同的一點是，手機中使用者需要有一個能進入系統的密碼，可以是字元密碼，也可以是手勢密碼，當使用者的指紋無法使用時（可能是指紋子產品故障，也可能是使用者指紋問題），仍然能有其它方式進入手機；門禁系統中使用者則可以隻有指紋認證這一種方式，進不了門時，還可以找管理者。
當然隻使用手機本地認證也是有意義的，每次APP從背景切換到前台時都需要使用者刷指紋，以驗證目前操作使用者的身份，很多的銀行APP就是這樣做的（其實我并未确認這些APP此時有沒有去背景再次驗證，隻是認為這是一種有意義的認證方式）。
本機認證的安全性手機作業系統廠商們已經做的很好了，指紋的注冊和識别都在安全區域内進行，指紋識别的結果可以加密的方式傳回給APP，這塊直接應用就可以了。
遠端認證
遠端認證就是用戶端和服務端之間的認證，完整的方式就是雙向認證：用戶端要驗證服務端的身份，以免被套取資訊；服務端要驗證用戶端的身份，以免使用者身份被冒充。
- 用戶端驗證服務端的身份：現在都使用https了，https證書就是服務端身份的保證，至少可以保證通路到位址就是你想通路的域名位址，進階點的證書還能辨別證書所有者的身份；使用https時資料也是加密傳輸的，是以一般應用場景是沒問題的。但是也發生過濫發證書的情況，是以如果需要更高的安全級别，服務端可以再生成一對非對稱密鑰。公鑰發給APP，私鑰自己儲存好，每次認證時，用戶端先采用服務端的公鑰對資料進行加密，然後再發送出去，服務端再采用自己的私鑰進行解密，如此假冒的服務端就不能解密資料，就什麼也得不到；服務端傳回給用戶端的資料帶上私鑰對資料的簽名，用戶端可以驗證簽名，驗證通過則代表是服務端傳回的，就可以應用這些資料。
- 服務端驗證用戶端的身份：也是通過非對稱密鑰的方式，用戶端生成一對非對稱密鑰，私鑰自己儲存好，公鑰發送到服務端。指紋認證通過後用戶端使用私鑰對請求參數進行簽名，然後再發送出去，服務端使用用戶端公鑰對接收到的資料簽名進行驗證，如果驗證通過，則說明資料沒有被篡改，可以處理用戶端發起的業務請求。
開啟指紋認證
這裡以登入為例，來看看如何使用指紋認證來做APP登入。還是先要注冊指紋，具體過程如下圖所示：
- 5開啟指紋：開啟指紋登入的時機，一般都是先用别的方式登入了APP，然後再開啟指紋登入。但是也有一些例外，使用者使用APP時直接使用第三方登入，第三方提供了指紋登入的方式，比如使用Apple Id登入。上邊圖中是先用賬号密碼登入了系統，然後才開啟的指紋認證。
- 12對比系統存在的指紋：指紋資料始終儲存在手機本地，不會上傳到遠端。目前市面上的手機都是這樣做的，Android和iOS提供的指紋認證API都隻傳回true或者false的認證結果，這樣可以避免雲服務被攻破時導緻大規模洩漏的嚴重後果，最大限度的保護使用者生物特征資料的安全。
- 13指紋驗證成功：本地指紋認證通過就代表使用者身份驗證通過，不管是哪個手指。早期的作業系統版本中可能能夠獲得是使用的哪個指紋，但是現在一般都不開放了，隻能得知指紋集是否發生了變化（删除或者添加了指紋），此時App可以強制使用者退出，再使用其它安全的方式登入，然後再讓使用者決定是否開啟指紋，支付寶就是這樣做的。
- 重播攻擊問題：步驟16中的請求可能被人截獲，雖然無法解密，但是可以多次發向服務端，造成重播攻擊的問題，可以引入一個挑戰碼來解決這個問題。步驟8初始化指紋注冊請求時服務端可以生成這個挑戰碼，然後在步驟16中攜帶這個挑戰碼，然後在服務端進行驗證。
使用指紋認證
下邊再來看下使用指紋登入的過程：
- 登入時的本機指紋認證和注冊時的本機指紋認證方法相同，隻不過這次是在使用者選擇指紋登入時彈出指紋刷取頁面。
- 10簽名登入資料：主要是用用戶端私鑰簽名裝置的唯一辨別和挑戰碼，在開啟指紋認證時指定了必須采用指紋授權的方式才能使用私鑰，這樣能確定簽名是由認證過的使用者發起的（準确的說是手機上登入過指紋的所有使用者，在開啟指紋認證時已經提示使用者所有錄入的指紋都将可以用來登入，同時如果指紋發生變化，會讓使用者重新确認，是以可以認為他們都是有權限的使用者）；服務端如果驗證簽名通過，則代表資料在傳輸過程中沒有被篡改，登入是在可信的用戶端發起的；前後端的認證結果結合起來就代表登入是由認證過的使用者發起的。
- 在開啟指紋階段，已經将裝置唯一辨別、用戶端公鑰綁定到了使用者記錄，是以簽名驗證通過後，就可以生成目前使用者的登入Token，并在後續的用戶端與服務端的一般互動中使用這個Token。在關鍵的互動，比如支付中，還是要使用指紋認證這種安全性更高的方式。
以上就是APP中的指紋認證原理，指紋登入和指紋登入的過程差不多，隻不過支付需要更高的安全等級，指紋認證可以滿足這個安全要求。
用戶端身份認證的問題
在上文APP的指紋注冊階段，用戶端生成了一對非對稱密鑰，用于後續服務端認證用戶端的身份，這個密鑰在目前的手機中已經有了成熟的安全存儲和使用方法，這就是TEE（可信執行環境）：
用戶端私鑰被TEE安全密鑰加密存儲在手機中，目前沒有破解之法；同時還可以指定隻有通過了本機指紋認證才能使用私鑰對資料進行簽名和加密；再者如果手機中加入了新的指紋或者删除了指紋，存儲的私鑰就會失效；是以密鑰的存儲和使用是可以保證安全的。
但是還存在其它的安全隐患：
1、服務端無法确認上傳的用戶端公鑰能否代表用戶端身份，任何程式都可以生成一對非對稱密鑰，然後對資料進行簽名，再把公鑰一起發到服務端，服務端僅能驗證簽名的正确性，但是無法驗證公鑰的來源，也就無法驗證用戶端的身份。某些解決方案中會在用戶端內建一個認證器SDK，這個SDK生成的認證資訊中會攜帶一些特殊識别資訊，而且每個應用每個機器不同，很難破解，後端可以據此判斷是在內建了認證器SDK的應用中發起的。但是也有一些難題，識别資訊的生成方法可能會被破解，還有怎麼确認是使用者發起的還是惡意程式發起的？
2、密鑰生成過程中可能被黑客替換，存儲和使用再怎麼安全也無濟于事了。這個在微信的技術資料中提到過，Android的密鑰生成有被攔截的可能，不确定目前是不是解決了。這也說明底層架構和作業系統也可能是不可信的，在某些場景下必須慎重考慮。
3、以上兩個問題在Root或者越獄之後的手機中更嚴重，APP、SDK和作業系統都無法信任了，是以很多金融類APP不支援在Root或者越獄的手機上使用指紋認證，不過道高一尺魔高一丈，還是有一些方法來欺騙APP，這也不乏部分使用者的支援（自作X啊）。
這個問題有好的辦法解決嗎？有，裝置出廠前就把私鑰儲存到TEE中。
Android中的密鑰安全
大家應該知道Android系統是開源的，很多手機廠商都在生産Android手機，市面上有多個廠商在競争，誰也不服誰，是以要想推廣上文提到的出廠前内置私鑰的方法，就必須統一标準。在國内騰訊和阿裡具備這樣的影響力，騰訊搞了SOTER，阿裡搞了IFAA，兩者都要求手機廠商在産線上生成一對非對稱密鑰，私鑰寫入手機TEE，即使拿到了手機目前也沒有破解之法，私鑰也就不會被洩漏，除非手機廠商搞事情，不過如果手機廠商真的這樣做了，就離倒閉不遠了；公鑰上傳到認證伺服器，認證的時候用于驗證手機APP上傳的資料簽名，驗證通過了就能代表是在對應的手機發起的認證。
同時為了推廣這個技術，這種協定還支援别的廠商APP接入進來。但是這樣就很容易洩漏APP的商業隐私 ，比如SOTER每次支付都要去騰訊的認證伺服器認證一下，據此就可以推斷你的業務行為和交易量，是以SOTER又搞了應用密鑰和業務密鑰，來盡量消除這個商業風險；同時針對Android密鑰生成可能被攔截的問題，讓手機廠商裝個更新檔包就解決了，比如替換掉不安全的中間環節。下邊來看下應用密鑰和業務密鑰的産生過程。
應用密鑰産生流程：應用密鑰在應用首次安裝的時候生成，應用密鑰的私鑰儲存在手機端，并使用出廠前内置的私鑰簽名，然後發到騰訊的認證伺服器驗證簽名，此時應用密鑰的公鑰會儲存到應用的背景。
業務密鑰産生流程：在使用登入或者支付的指紋認證注冊的時候，應用會再生成一個業務密鑰，業務密鑰的私鑰還是儲存在手機端，業務密鑰使用手機端的應用密鑰進行簽名，驗證也隻需要在應用的背景驗證就可以了，此時和騰訊的認證伺服器就沒有關系了。
這樣騰訊就不知道你的實際業務營運情況了，比如每天線上支付多少筆，但是APP安裝量還是免不了會暴漏出來，話說APP都要上應用市場的，這個資訊其實早就公開了。
關于SOTER詳細介紹，可以看官方文檔：https://github.com/Tencent/soter/wiki
IFAA的應用過程和SOTER差不多，這裡就不再贅述了。另外國外還有一個FIDO聯盟，也是解決這個問題的，國内是聯想集團的子公司國民認證在推廣這個，技術原理也都差不多。
iOS中的密鑰安全
iPhone的作業系統和硬體都是自己控制的，是以對于安全控制它可以做的很好。
對于本機指紋認證，蘋果也提供了Touch ID的API，可以在前端調用指紋認證，但是如果要發送到服務端去驗證，基于各種安全考慮，就還是需要一個用戶端密鑰，這個用戶端密鑰有沒有安全的産生方式呢？我沒有找到官方的文檔說明，很多基于這個方案的第三方應用可能都是自己生成的吧，盡量做到安全。當然這個也是猜測。
但是微信或者支付寶這種應用怎麼能忍呢？SOTER曾經說要支援iOS，最後也是不了了之；IFAA宣傳的是相容支援iPhone 5s 以上所有 iOS 手機，不過它不開源。可能蘋果最終還是不想把這塊放開，同時基于蘋果的強勢地位，最有可能是蘋果專門給這種應用開放了特定的API，不許外傳。
如果是做指紋登入，其實可以直接使用蘋果開放的Apple ID登入協定，支援指紋和刷臉認證，會給應用傳回認證Token和授權碼，應用背景拿着這兩個再去找蘋果驗證。從這個邏輯上看，蘋果的背景必然能安全的确認發起請求的用戶端身份，是以估計和Android的原理差不多，隻不過前後端的每次認證都得蘋果來驗證。
Web中的指紋認證
上面提到過一個FIDO聯盟，它和W3C搞了一個WebAuthn标準，它的目的是标準化使用者對基于 Web 的應用程式和服務的公鑰認證的接口，說人話就是定了一個Web程式中使用公鑰認證的标準，所謂的公鑰認證就是上文提到的用戶端密鑰認證技術。這個國内産品好像使用的不多見，不過這件事挺牛的。它可以在Windows、Linux、Mac OS、Android、iOS、智能手表等各種裝置中使用指紋識别、面部識别、虹膜識别、聲音識别、實體密鑰（USB連接配接、藍牙連接配接、NFC連接配接）等多種方式進行認證，盡可能的擺脫對密碼的依賴。
這個技術标準和APP中的公鑰認證技術是一脈相承的，主要差別在于APP換成了浏覽器，認證子產品除了作業系統本身支援，還增加了對專用硬體的支援。有興趣的可以去了解下。
以上就是本文的主要内容，因能力有限，可能存在部分錯漏，歡迎指正。
收獲更多架構知識，請關注公衆号 螢火架構。原創内容，轉載請注明出處。