默默無聞的安全可能是最好的解決方案 - 還是我錯了？
想像一下下面的情況。有一個微控制器驅動系統的應用程序。利潤來自製造和銷售設備本身。但是，預計使用者稍後可以從公共網站下載軟體更新，並安裝它（例如，使用 USB 連接）。
現在的問題是，如果更新以原始編譯二進製文件的形式發布，任何人都可以複製硬體，而省去長期軟體開發的成本。
現在，讓更新以某種方式加密，微控制器中的引導載入程序（這當然不是更新的一部分，永遠不會改變）整個程序位於內部快閃記憶體中，該快閃記憶體被保護以防讀取。
問題是，引導載入程序中的空間太小（以幾十個字衡量，或者最好是一百個左右），以至於無法在那裡實現加密安全的解密算法。
因此，讓我們發布一個更新，其中包含在隨機但預先確定的位置插入的有效但隨機且無意義的指令。引導載入程序知道這一點，並將刪除它們。這個想法是，即使攻擊者知道這種方法（但不知道這些指令插入的位置），也幾乎不可能得到真正的程序，因為在你測試之前你不知道你得到了正確的程序（即便如此，如果“破解”不完美，一些隱藏的錯誤可能仍然潛伏著）。
在這種情況下，主要目標是讓攻擊者竊取軟體比自己開發軟體更耗時。
這種思維方式有明顯的缺陷嗎？
總而言之：“引導載入程序中的空間太小，以至於無法實現加密安全的解密算法”的前提可能是錯誤的；因此，默默無聞的安全不是要走的路。
問題中描述的方法試圖“防止公開發布的更新被盜”；但如果對手設法提取引導載入程序並將其逐字包含在硬體複製中，它就無法做到這一點：無論執行多麼聰明和有效的隱匿安全性，複製和引導載入程序都會愉快地載入軟體更新。
因此，引導載入程序需要一些秘密，否則這種（或任何）技術注定要允許硬體的複製執行軟體更新。一旦你假設，即使只有 10 字節的秘密數據，你也不再需要隱匿安全性：你可以使用該秘密數據作為分組密碼的密鑰，例如CBC 模式，並發布用它加密的軟體更新，並且可能使用MAC簽名完整性保護。使用適當的分組密碼（例如TEA（其設計緊湊且相當高效））的完整解密可以在大約任何微控制器上不到 200 個字節內實現。
不幸的是，在標準微控制器中很難保密：所有數據，包括密鑰，都傾向於使用廣泛可用的工具（例如 JTAG 埠）來讀取。如果這樣做不行，側通道攻擊通常會成功。“防止讀取的內部閃光燈”的前提可能是正確的，但受保護並不意味著安全。
出於這個原因，在完整性保護部分（如果需要），最好使用不需要秘密的公鑰簽名方案（但只會對問題中的目標有所幫助：它不會阻止在未經授權的硬體上使用軟體，僅防止在授權硬體上使用修改後的軟體或其精確複製）。具有公共指數的RSA簽名 $ e=3 $ 與基於雜湊的適當填充方案一起，可以在 800 字節中實現，包括 2048 位公鑰（將使用少於 128 字節；這不是錯字），並以可接受的速度執行（執行時間通常由雜湊）。
您不太可能在這裡獲得對安全性的支持：我們正式相信Kerckhoffs的原則。作為第二道防線，我只會容忍默默無聞的安全。