使用 ECDSA 的 BLE 應用層的挑戰響應
需要離線 BLE 設備來驗證電話。我計劃使用此處略述的挑戰響應。
有一個小的變化。而不是共享秘密。我打算使用公鑰和私鑰。
基本上只要手機連接到ble設備。設備給出隨機消息（最多 20 個字節）。手機使用確定性 ECDSA 簽名讀取並生成簽名並將其發送回設備。
設備驗證簽名。建立該會話的真實性。
公鑰嵌入在設備中。私鑰通過使用者手冊或設備上的二維碼提供給所有者。
問題：
- 對於 20 字節的小隨機消息，確定性 ECDSA 有多好？
- 流程有任何明顯的問題嗎？
關於您的 Q1，好吧，只要您在簽名者端有一個好的隨機生成器，ECDSA 就可以了，而確定性 ECDSA 試圖解決隨機性問題，因此很好（只要您的模型中不包含故障攻擊） . 在確定性簽名方案中，我個人更喜歡 Ed25519，但我想說，這是個人品味的問題。
現在，因為您的挑戰是 20 個字節，如果您有足夠的熵來確保生成隨機挑戰，或者有一種方法可以確保以不可逆的方式在每個挑戰上增加計數器值，那麼您將不會擔心重放攻擊（否則這將是一個非常小的挑戰的問題）。
至於 Q2，您最擔心的是缺少 Threat 模型！或者，如果您有一個，您應該向我們提供它，因為如果您只考慮主動竊聽者，該方案可能看起來不錯，但一旦您考慮威脅模型中的故障攻擊（即攻擊者擁有設備並且可以使它在計算過程中執行錯誤）。
由於執行簽名的設備是電話，我想說您不會因故障而受到私鑰恢復的影響。
另一方面，離線 BLE 設備最有可能出現故障，這可能會欺騙簽名驗證。例如，參見 Riscure使用故障注入繞過安全啟動的工作，他們很容易繞過這樣的單一驗證。
現在，另一個問題是您必須使用 OOB（越界）通道將私鑰傳輸到手機，這意味著您也可能已經使用相同的 OOB 方法傳輸了安全的 LTE 密鑰，並且您可以說（不要打我）達到了同樣的目標：只有知道該密鑰的設備才能與您的設備通信……（好吧，根據您的方案，如果離線設備被盜，它不允許恢復私鑰，但如果有人有能力從 BLE 設備中恢復密鑰，我會說他們有能力在簽名驗證過程中執行錯誤並欺騙設備相信他正在與擁有密鑰的人交談……因此達到相同的結果。除非您要對發送到設備的每條消息進行身份驗證，在這種情況下可能會有點困難，但 LE 設備的故障通常很容易執行。）
據我所知，除了低能耗設備通常沒有執行 ECDSA 簽名的能力之外，我沒有看到您的設計有任何其他問題……但也許這是舊消息，不再是這種情況了。
順便說一句，您可能想查看http://www.gattack.io/網站，更具體地說是閱讀他們的白皮書（即使它看起來有點過時）。根據我的閱讀，您似乎真的應該使用 BLE 4.2，它具有用於 LTE 密鑰交換的ECDH 。（然而，我還沒有找到關於該主題的太多資訊）。如果您被迫使用先前的規範，或者不能依賴 ECDH，那麼似乎只有 OOB 模式下的 BLE 鏈路層實際上是安全的。