維基百科

代碼簽章

代碼簽章（英語：Code signing）是對可執行檔或程式碼進行數位簽章以確認軟體作者及保證軟體在簽章後未被修改或損壞的措施。此措施使用加密雜湊來驗證真實性和完整性。[1]

代碼簽章可以提供幾大功能價值。最常用的需求是代碼簽章為部署提供了安全性。在某些程式語言中，它也可用來幫助防止命名空間衝突。幾乎每個代碼簽章的實現都提供某種數位簽章機制來驗證作者或構建系統的身分，以及校驗對象是否未被修改。它也可用來提供對象相關的版本資訊，以及儲存對象的其他元資料。[2]

代碼簽章作為軟體安全性依賴的效果取決於所支援簽章金鑰的安全性。與其他公鑰基礎設施（PKI）技術一樣，系統的完整性依賴於發布者對其私鑰免受未經授權訪問的保護。儲存在通用電腦的軟體中的金鑰易於受到影響。因此，將金鑰儲存在安全、防篡改的硬體密碼裝置（也稱硬體安全模組，HSM）是更加安全的最佳實踐。[3]

安全保證

許多代碼簽章的實現提供方法來使用涉及一組金鑰的系統來簽章代碼，這類似SSL與SSH的流程。例如，在.NET中，開發人員每次構建之時，都將使用一個私鑰來簽章自己的庫或可執行檔。此金鑰唯一且分屬給單個開發人員、小組，或者特定應用程式或實體。開發人員可以自己生成此金鑰，也可以從受信任的數位憑證認證機構（CA）取得一份金鑰。[4]

代碼簽章在分發目的下很有價值，因為所提供代碼的原始碼可能並不明顯，如Java applet、ActiveX控制項或其他類似代碼。它的另一個重要用途是，為現有軟體安全地提供更新和修補程式。[5]Windows、Mac OS X和大多數Linux發行版為更新使用代碼簽章，從而確保其他人不可能通過修補程式系統分發惡意代碼。它可以使作業系統驗證更新是否合法，即使更新是由第三方或藉助物理媒介（如光碟、USB隨身碟）分發。

在Windows和Mac OS X上，首次執行（英語：First run (computing)）軟體時將檢查代碼簽章以驗證軟體的身分，確保軟體沒有被第三方分銷商或下載網站惡意篡改。因為平台的分散性，這種代碼簽章形式沒有在Linux上使用，軟體套件管理系統是所有軟體形式（不僅僅更新和修補程式）的主要發行模式，並且允許直接檢查原始碼的開放原始碼模型（如果需要）。

使用憑證頒發機構（CA）完成受信辨識

用於代碼簽章的公鑰應該可以追溯到受信任的根機構CA，使用安全的公鑰基礎設施（PKI）是最佳做法。這雖不能保證代碼本身的可信，但可以確保它來自所聲明的來源（更明確來說，來自特定私鑰）。[6]一個CA提供者可以提供根級別的信任，並能以代理方式將信任分配給其他人。如果使用者信任一個CA，那麼使用者也相信該CA及其代理生成的金鑰所簽章的代碼合法性。許多作業系統和框架都內建對一個或多個現有CA的信任（例如VeriSign/Symantec、DigiCert、TC TrustCenter、Comodo、GoDaddy及GlobalSign等）。對大型組織來說，實現與公共CA功能相同但僅在組織內信任的私有CA也是常見的選擇。

CA的替代品

類似目的的另一種方式是——開發人員可以使用自己生成的金鑰。在此種情況下，使用者首次通常必須直接從開發人員那裡取得公鑰，以便驗證對象的來源。許多代碼簽章系統將儲存簽章中的公鑰。部分軟體框架和作業系統將在執行前檢查代碼的簽章，並允許使用者選擇是否信任該開發者。應用程式開發者可以在安裝程式中包含公鑰以提供類似的系統。然後可以使用金鑰來確保需要執行的任何後續對象（例如升級、外掛程式或其他應用程式）都是來自同一開發人員。

時間戳

時間戳旨在解決憑證過期後開始出現的信任警告。在實際應用中，時間戳將使代碼的信任期延長到憑證有效期之後。[7]

如果由於鑒權洩露或失效而必須復原憑證，則復原事件的具體時間將納入復原記錄。在這種情況下，時間戳有助於確認代碼是在憑證信任受損之前還是之後簽署。

問題

同任何安全措施一樣，代碼簽章也可以被擊破。使用者可能被誘騙而執行無簽章乃至拒絕被驗證的代碼[需要解釋]，並且系統只能儘可能保持私鑰的安全性。[8][9]

同樣重要的是，代碼簽章不會保護終端使用者免受軟體作者的惡意行為或無意破壞，而只是確認軟體未被作者以外的人修改。

實現

IBM的Lotus Notes自第一版開始有一個PKI的代碼簽章，並且客戶端和伺服器軟體都有「執行控制列表」來控制指定使用者對資料、環境和檔案系統的訪問級別。個別設計元素（栓指令碼、動作、代理等活動專案）始終使用編者的ID檔案來簽章，其中包括編者和域的公鑰。核心模板（如郵件模板）由Lotus模板開發團隊持有的專用ID簽章。

微軟公司為微軟測試的驅動程式提供了一種代碼簽章（基於Authenticode）。因為驅動程式是在核心中執行，它們可能破壞系統的穩定性或者使系統出現安全漏洞。就此原因，微軟將測試提交到其WHQL計劃的驅動程式。在驅動程式通過測試後，微軟會將此版本的驅動程式標記為安全。在32位元系統上，安裝未通過微軟驗證的驅動程式可以在使用者被警告該代碼未被簽章時選擇允許安裝。對於.NET（代管）代碼來說，它有一種稱為強名稱簽章（英語：Strong Name Signing）的額外機制，它採用公鑰/私鑰和SHA-1雜湊而不是憑證。不過，微軟不鼓勵用強名稱簽章來代替Authenticode。[10]

遊戲和消費裝置中的未簽章代碼

在諸如遊戲主機等消費者裝置語境中，未簽章代碼通常指一個未被通常必須有加密金鑰的應用程式接受和執行的軟體。大多數主機遊戲必須使用主機製造商設計的私鑰簽章，否則遊戲不會在主機上載入。使未簽章代碼被執行通常有幾種方法，包括軟體漏洞、使用modchip、運用交換技巧（英語：Swap Magic）技術，或者執行一個softmod（英語：softmod）。

對於有簽章的應用程式複製到另一張DVD上就不能啟動的原因，通常不那麼顯而易見。在Xbox上，原因是Xbox可執行檔（XBE）包含一個媒體類型標誌，它指定了XBE可引導形式的媒體類型。對幾乎所有Xbox軟體來說，此設定使得可執行檔只能從工廠生產的光碟啟動，將可執行檔複製到可燒錄媒體上將終止軟體的可執行性。

但是，因為可執行檔本已簽章，因此僅更改標記值不可行，那將使可執行檔的簽章失效，從而在最初的驗證階段就檢查失敗。

互聯裝置的增長

伴隨著物聯網（IoT）增長的互聯裝置正成為代碼簽章的新需求。隨著越來越多的感測器和裝置被接入緊密的網路生態系統，憑證頒發機制已被擴充到人員辨識以外的機器辨識。與代碼簽章一樣，該技術使用數字證明確保了代碼的物理真實性和完整性，及在產品生命周期內隨時進行代碼的驗證與升級。這正為代碼簽章創造新的緯度：提高安全意識，以及需要在專用的保護環境中儲存私有簽章金鑰，為整個系統建立信任的根源。鑑於惡意軟體和進階持久威脅（APT）的流行，許多軟體供應商、線上服務提供商、企業IT組織和高科技IoT裝置的製造商都面臨著增加其高科技製造和代碼簽章過程安全性的壓力。[11]

參見

參考資料

  1. ^ Introduction to Code Signing. （原始內容存檔於2017-08-03）. 
  2. ^ Hendric, William. A Complete overview of Trusted Certificates - CABForum (PDF). 2015 [2015-02-26]. （原始內容存檔 (PDF)於2019-04-22）. 
  3. ^ Securing your Private Keys as Best Practice for Code Signing Certificates (PDF). 
  4. ^ Hendric, William. What is Code Signing?. 17 June 2011 [26 February 2015]. （原始內容存檔於2018-06-20）. 
  5. ^ Digital Signatures and Windows Installer. （原始內容存檔於2017-08-30）. 
  6. ^ 存档副本 (PDF). [2017-03-29]. （原始內容存檔 (PDF)於2014-02-26）. 
  7. ^ Morton, Bruce. Code Signing (PDF). CASC. [21 February 2014]. （原始內容存檔 (PDF)於2014-02-26）. 
  8. ^ 存档副本. [2017-03-29]. （原始內容存檔於2014-04-16）. 
  9. ^ http://www.eweek.com/c/a/Security/Theres-A-Racket-Brewing-In-the-Code-Signing-Cert-Business/[失效連結]
  10. ^ Strong Name Bypass: .. [2017-03-29]. （原始內容存檔於2010-02-12）. 
  11. ^ Code Signing. （原始內容存檔於2017-02-24）. 

外部連結

取自「https://zh.wikipedia.org/w/index.php?title=代码签名&oldid=77840245」