維基百科

代碼簽名

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

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

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

安全保證

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

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

在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」