Authentication

如何使用 CA 對兩台設備進行身份驗證?

  • September 12, 2018

我正在嘗試為某些設備找出一種中間人安全身份驗證方案。我知道這可以通過 CA 來實現。

但我不清楚的是如何在這樣的設置中保證設備的真實性。在我看來,DEV3(冒名頂替者)似乎可以輕鬆地將其公鑰發送給 CA,然後由 CA 簽名。此外,DEV3 可能有 CA PUB 密鑰。

這是一個塗鴉:

在此處輸入圖像描述

提出的問題並不容易解決。要以 Dev3 不允許模仿的方式使用密碼術作為 Dev1 進行身份驗證,Dev1 必須知道 Dev3 現在包含(或不允許提取或濫用)的某個密鑰(或私鑰),但CA 可以驗證,因為它知道它(或知道相應的公鑰)。傳統的密碼學(包括公鑰密碼學,但可能不是基於PUF的密碼學或/和量子密碼學的新用途,我不會進一步考慮)沒有其他可提供的。

最簡單的解決方法是考慮 Dev1 是任何可以證明能夠使用與 CA 為據稱名為 Dev1 的東西計算證書的第一個公鑰相關聯的私鑰的東西,並讓 CA 拒絕任何進一步的獲取證書的嘗試在名稱 Dev1 下(可能:除了經過適當身份驗證的證書續訂請求,如果這些在圖片中)。如果處理得當,當可以模擬 Dev1 時,它可以完全阻止它工作,這總比沒有好。

解決問題而不是解決問題的一種方法是在假定的安全位置(例如工廠)執行步驟 2,其中 Dev1 的身份驗證是通過非加密方式執行的。

另一種方法是在 Dev1 中的一個安全位置(CA 也知道)注入一個密鑰,以便可以使用密鑰密碼術進行身份驗證來執行步驟 2。該密鑰可以是在安全位置分配的隨機八位字節字元串,並與 CA 安全地通信(與標識符 Dev1 或 Dev1 的公共媒體訪問控制地址 (MAC)相關聯,如果它在該階段沒有名稱),或相反。

作為上述更方便的變體,秘密密鑰可以是所謂的多樣化密鑰,使用從主密鑰(操作安全位置的實體和CA已知)和任何標識Dev1的密鑰推導函式獲得;好處是只有主密鑰需要與 CA 進行安全通信,CA 可以重新計算所有設備的多樣化密鑰。注意:對於密鑰多樣化,我們不需要熵拉伸密鑰推導函式,可以使案例如HMAC或 AES(以主密鑰為密鑰,標識為其他輸入);或NIST SP 800-108中的任何功能。

密鑰可以是媒體訪問控制地址的消息驗證碼。TLA中的碰撞是偶然的。

還有其他方法,例如在所有設備中嵌入相同的秘密,並希望它不會被提取或濫用;但是當有 CA 時,它們與前一個相比往往沒有操作優勢,並且更脆弱。

引用自:https://crypto.stackexchange.com/questions/32797