研究其他部分的鏈接
- (你在這裡)
本文完成了致力於確保銀行非現金支付資訊安全的系列出版物。 這裡我們將看看中提到的典型威脅模型 :
- .
- .
- .
- .
哈布羅-警告！！！ 親愛的哈布羅維特人，這不是一個有趣的貼文。
隱藏在切口下的 40 多頁資料旨在 幫助工作或學習 專門從事銀行或資訊安全的人員。 這些材料是研究的最終產品，以乾巴巴、正式的語氣編寫。 本質上，這些是內部資訊安全文件的空白。嗯，傳統的—— “將文章中的信息用於非法目的將受到法律懲罰”。 富有成效的閱讀！
從本出版物開始熟悉該研究的讀者提供的資訊。
研究內容是什麼？
您正在閱讀一本針對負責確保銀行支付資訊安全的專家的指南。
呈現邏輯
一開始在 и 給出了受保護對象的描述。 然後在 描述如何建立安全系統並討論了建立威脅模型的必要性。 在 討論存在哪些威脅模型以及它們是如何形成的。 在 и 提供了對真實攻擊的分析。 и 包含威脅模型的描述，該模型是根據之前所有部分的資訊建構的。
典型的威脅模型。 網路連線
應用威脅模型（範圍）的保護對象
保護的物件是透過在基於 TCP/IP 堆疊建構的資料網路中運行的網路連線傳輸的資料。
架構
建築元素描述：
- “末端節點” — 交換受保護資訊的節點。
- “中間節點” — 資料傳輸網路的元素：路由器、交換器、存取伺服器、代理伺服器和其他裝置 — 透過它們傳輸網路連接流量。 一般來說，網路連線可以在沒有中間節點的情況下運作（直接在端節點之間）。
頂級安全威脅
分解
U1。 未經授權存取傳輸的資料。
U2。 未經授權修改傳輸的資料。
U3。 侵犯傳輸資料的作者權。
U1。 未經授權存取傳輸的數據
分解
U1.1。 <…>，在最終或中間節點執行：
U1.1.1。 <...> 透過讀取主機儲存裝置中的資料：
U1.1.1.1。 <...> 在記憶體中。
U1.1.1.1 的說明。
例如，在主機網路堆疊進行資料處理期間。
U1.1.1.2。 <...> 在非揮發性記憶體中。
U1.1.1.2 的說明。
例如，將傳輸的資料儲存在快取、暫存檔案或交換檔案中。
U1.2。 <…>，在資料網路的第三方節點上進行：
U1.2.1。 <...> 透過擷取到達主機網路介面的所有封包的方法：
U1.2.1 的說明。
透過將網路卡切換到混雜模式（有線轉接器的混雜模式或 Wi-Fi 轉接器的監控模式）來擷取所有資料包。
U1.2.2。 <...> 透過執行中間人（MiTM）攻擊，但不修改傳輸的資料（不包括網路協定服務資料）。
U1.2.2.1。 關聯： .
U1.3。 <…>，由於實體節點或通訊線路透過技術管道（TKUI）的資訊洩漏而進行。
U1.4。 <…>，透過在末端或中間節點安裝特殊技術手段（STS）來進行，旨在秘密收集資訊。
U2。 未經授權修改傳輸數據
分解
U2.1。 <…>，在最終或中間節點執行：
U2.1.1。 <...> 透過讀取和更改節點儲存設備中的資料：
U2.1.1.1。 <...> 在記憶體中：
U2.1.1.2。 <...> 在非揮發性記憶體中：
U2.2。 <…>，在資料傳輸網路的第三方節點上進行：
U2.2.1。 <...> 透過執行中間人 (MiTM) 攻擊並將流量重新導向到攻擊者的節點：
U2.2.1.1。 攻擊者設備的實體連線會導致網路連線中斷。
U2.2.1.2。 對網路協定進行攻擊：
U2.2.1.2.1。 <...> 虛擬本機網路 (VLAN) 管理：
U2.2.1.2.1.1。 .
U2.2.1.2.1.2。 未經授權修改交換器或路由器上的 VLAN 設定。
U2.2.1.2.2。 <...> 流量路由：
U2.2.1.2.2.1。 未經授權修改路由器靜態路由表。
U2.2.1.2.2.2。 攻擊者透過動態路由協定發布虛假路由。
U2.2.1.2.3。 <...> 自動設定：
U2.2.1.2.3.1。 .
U2.2.1.2.3.2。 .
U2.2.1.2.4。 <...> 尋址與名稱解析：
U2.2.1.2.4.1。 .
U2.2.1.2.4.2。 .
U2.2.1.2.4.3。 對本機主機名稱檔案（hosts、lmhosts 等）進行未經授權的更改
U3。 侵犯傳輸資料的版權
分解
U3.1。 透過指示有關作者或資料來源的虛假資訊來中和確定資訊作者身份的機制：
U3.1.1。 更改所傳輸資訊中包含的有關作者的資訊。
U3.1.1.1。 中和傳輸資料的完整性和作者身份的加密保護：
U3.1.1.1.1。 關聯： .
U3.1.1.2。 中和傳輸資料的版權保護，使用一次性確認碼實現：
U3.1.1.2.1。 .
U3.1.2。 變更有關傳輸資訊來源的資訊：
U3.1.2.1。 .
U3.1.2.2。 .
典型的威脅模型。 基於客戶端-伺服器架構的資訊系統
應用威脅模型（範圍）的保護對象
保護的對像是建立在客戶端-伺服器體系結構基礎上的資訊系統。
架構
建築元素描述：
- “客戶” – 資訊系統用戶端部分運作的設備。
- "伺服器" – 資訊系統伺服器部分運作的設備。
- “資料儲存” — 資訊系統伺服器基礎架構的一部分，旨在儲存資訊系統處理的資料。
- “網路連線” ——客戶端和伺服器之間透過資料網路進行資訊交換的通道。 元素模型的更詳細描述在 .
限制
在對物件進行建模時，設定以下限制：
- 使用者在有限的時間內與資訊系統進行交互，稱為工作會話。
- 在每個工作會話開始時，使用者都會被識別、驗證和授權。
- 所有受保護的資訊都儲存在資訊系統的伺服器部分。
頂級安全威脅
分解
U1。 攻擊者代表合法使用者執行未經授權的操作。
U2。 在資訊系統的伺服器部分處理受保護的資訊期間未經授權對其進行修改。
U1。 攻擊者代表合法使用者執行未經授權的操作
說明
通常在資訊系統中，操作與執行這些操作的使用者相關，使用：
- 系統操作日誌（logs）。
- 資料物件的特殊屬性，包含有關建立或修改它們的使用者的資訊。
就工作會話而言，這種威脅可以分解為：
- <...> 在使用者會話中執行。
- <...> 在使用者會話之外執行。
可以啟動使用者會話：
- 由使用者自己。
- 犯罪分子。
在此階段，該威脅的中間分解將如下所示：
U1.1。 在使用者會話中執行了未經授權的操作：
U1.1.1。 <...> 由受攻擊的使用者安裝。
U1.1.2。 <...> 由攻擊者安裝。
U1.2。 在使用者會話之外執行了未經授權的操作。
從可能受到攻擊者影響的資訊基礎設施物件的角度來看，中間威脅的分解將如下所示：
分子
威脅分解
U1.1.1。
U1.1.2。
U1.2。
顧客
U1.1.1.1。
U1.1.2.1。
網路連線
U1.1.1.2。
服務器
U1.2.1。
分解
U1.1。 在使用者會話中執行了未經授權的操作：
U1.1.1。 <...> 由受攻擊的使用者安裝：
U1.1.1.1。 攻擊者的行為獨立於客戶端：
U1.1.1.1.1 攻擊者使用標準資訊系統存取工具：
У1.1.1.1.1.1。 攻擊者使用客戶端的實體輸入/輸出手段（鍵盤、滑鼠、顯示器或行動裝置的觸控螢幕）：
U1.1.1.1.1.1.1。 攻擊者在會話處於活動狀態、I/O 設施可用且使用者不在場的時間內進行操作。
У1.1.1.1.1.2。 攻擊者使用遠端管理工具（標準的或由惡意程式碼提供的）來控制客戶端：
U1.1.1.1.1.2.1。 攻擊者在會話處於活動狀態、I/O 設施可用且使用者不在場的時間內進行操作。
У1.1.1.1.1.2.2。 攻擊者使用遠端管理工具，受攻擊的使用者看不到其操作。
U1.1.1.2。 攻擊者替換了客戶端和伺服器之間的網路連線中的數據，對其進行修改，使其被視為合法使用者的操作：
U1.1.1.2.1。 關聯： .
U1.1.1.3。 攻擊者使用社會工程方法強迫使用者執行他們指定的操作。
У1.1.2 攻擊者安裝的<…>：
U1.1.2.1。 攻擊者從客戶端（И):
U1.1.2.1.1。 攻擊者破壞了資訊系統的存取控制系統：
U1.1.2.1.1.1。 關聯： .
U1.1.2.1.2。 攻擊者使用標準資訊系統存取工具
U1.1.2.2。 攻擊者從資料網路的其他節點進行操作，可以從這些節點建立到伺服器的網路連線（И):
U1.1.2.2.1。 攻擊者破壞了資訊系統的存取控制系統：
U1.1.2.2.1.1。 關聯： .
U1.1.2.2.2。 攻擊者使用非標準方式存取資訊系統。
解釋 U1.1.2.2.2。
攻擊者可以在第三方節點上安裝資訊系統的標準客戶端，或者可以使用在客戶端和伺服器之間實現標準交換協定的非標準軟體。
U1.2 在使用者會話之外執行了未經授權的操作。
U1.2.1 攻擊者執行未經授權的操作，然後對資訊系統操作日誌或資料物件的特殊屬性進行未經授權的更改，表明其執行的操作是由合法使用者執行的。
U2。 在資訊系統的伺服器部分處理受保護資訊期間未經授權對其進行修改
分解
U2.1。 攻擊者使用標準資訊系統工具修改受保護的訊息，並代表合法使用者執行此操作。
U2.1.1。 關聯： .
U2.2。 攻擊者透過使用資訊系統正常操作未提供的資料存取機制來修改受保護的資訊。
U2.2.1。 攻擊者修改包含受保護資訊的檔案：
U2.2.1.1。 <…>，使用作業系統提供的檔案處理機制。
U2.2.1.2。 <...> 透過從未經授權的修改備份副本中還原檔案。
U2.2.2。 攻擊者修改資料庫中儲存的受保護資訊（И):
U2.2.2.1。 攻擊者破壞 DBMS 存取控制系統：
U2.2.2.1.1。 關聯： .
U2.2.2.2。 攻擊者使用標準 DBMS 介面修改資訊來存取資料。
U2.3。 攻擊者透過未經授權修改處理受保護資訊的軟體的操作演算法來修改受保護的資訊。
U2.3.1。 軟體的原始碼可能會被修改。
U2.3.1。 軟體的機器碼可能會被修改。
U2.4。 攻擊者利用資訊系統軟體中的漏洞修改受保護的資訊。
U2.5。 當受保護的資訊在資訊系統的伺服器部分的元件（例如資料庫伺服器和應用程式伺服器）之間傳輸時，攻擊者會修改受保護的資訊：
U2.5.1。 關聯： .
典型的威脅模型。 門禁系統
應用威脅模型（範圍）的保護對象
應用此威脅模型的防護對象對應於威脅模型的防護對象：「典型威脅模型。 建立在客戶端-伺服器架構之上的資訊系統。”
在這個威脅模型中，使用者存取控制系統是指資訊系統中實現以下功能的元件：
- 用戶識別。
- 用戶認證。
- 用戶授權。
- 記錄使用者操作。
頂級安全威脅
分解
U1。 代表合法使用者未經授權建立會話。
U2。 未經授權增加資訊系統中的使用者權限。
U1。 代表合法使用者未經授權建立會話
說明
這種威脅的分解通常取決於所使用的使用者識別和認證系統的類型。
在此模型中，僅考慮使用文字登入名稱和密碼的使用者識別和認證系統。 在這種情況下，我們將假設使用者登入是攻擊者已知的公開資訊。
分解
U1.1。 <...> 由於憑證外洩：
U1.1.1。 攻擊者在儲存使用者憑證時洩漏了這些憑證。
解釋 U1.1.1。
例如，可以將憑證寫在貼在顯示器上的便條紙上。
U1.1.2。 使用者意外或惡意地將存取詳細資訊傳遞給攻擊者。
U1.1.2.1。 使用者輸入時大聲說出憑證。
U1.1.2.2。 用戶故意分享他的憑證：
U1.1.2.2.1。 <...> 給同事。
解釋 U1.1.2.2.1。
例如，以便他們可以在生病期間更換它。
U1.1.2.2.2。 <...> 對資訊基礎設施對象執行工作的雇主承包商。
U1.1.2.2.3。 <...> 給第三方。
解釋 U1.1.2.2.3。
實施這種威脅的一種（但不是唯一）選擇是攻擊者使用社會工程方法。
U1.1.3。 攻擊者使用暴力方法選擇憑證：
U1.1.3.1。 <...> 使用標準存取機制。
U1.1.3.2。 <…> 使用先前攔截的程式碼（例如密碼雜湊）來儲存憑證。
U1.1.4。 攻擊者使用惡意程式碼來攔截使用者憑證。
U1.1.5。 攻擊者從客戶端和伺服器之間的網路連線中提取憑證：
U1.1.5.1。 關聯： .
U1.1.6。 攻擊者從工作監控系統的記錄中提取憑證：
U1.1.6.1。 <...>視訊監控系統（如果在操作過程中記錄了鍵盤上的擊鍵）。
U1.1.6.2。 <...> 用於監控員工在電腦上的行為的系統
解釋 U1.1.6.2。
這種系統的一個例子是 .
U1.1.7。 由於傳輸過程中的缺陷，攻擊者破壞了使用者憑證。
解釋 U1.1.7。
例如，透過電子郵件以明文形式發送密碼。
U1.1.8。 攻擊者透過使用遠端管理系統監視使用者會話來獲取憑證。
U1.1.9。 攻擊者透過技術管道 (TCUI) 洩漏而獲得了憑證：
U1.1.9.1。 攻擊者觀察使用者如何透過鍵盤輸入憑證：
U1.1.9.1.1 攻擊者距離使用者很近，親眼看到憑證的輸入。
解釋 U1.1.9.1.1
此類情況包括同事的操作或組織訪客可以看到使用者鍵盤的情況。
U1.1.9.1.2 攻擊者使用了額外的技術手段，例如雙筒望遠鏡或無人機，並透過窗戶看到憑證的輸入。
U1.1.9.2。 當鍵盤和電腦系統單元透過無線電介面（例如藍牙）連接時，攻擊者會從鍵盤和電腦系統單元之間的無線電通訊中提取憑證。
U1.1.9.3。 攻擊者透過寄生電磁輻射和乾擾 (PEMIN) 通道洩漏憑證來攔截憑證。
解釋 U1.1.9.3。
攻擊範例 и .
U1.1.9.4。 攻擊者透過使用旨在秘密獲取資訊的特殊技術手段（STS）攔截從鍵盤輸入的憑證。
解釋 U1.1.9.4。
Примеры .
U1.1.9.5。 攻擊者使用以下方法攔截了從鍵盤輸入的憑證
分析使用者擊鍵流程調製的 Wi-Fi 訊號。
解釋 U1.1.9.5。
例子 .
U1.1.9.6。 攻擊者透過分析擊鍵聲音來攔截從鍵盤輸入的憑證。
解釋 U1.1.9.6。
例子 .
U1.1.9.7。 攻擊者透過分析加速度計讀數攔截了行動裝置鍵盤上的憑證輸入。
解釋 U1.1.9.7。
例子 .
U1.1.10。 <...>，先前已儲存在客戶端上。
解釋 U1.1.10。
例如，使用者可以在瀏覽器中儲存登入名稱和密碼以存取特定網站。
U1.1.11。 由於撤銷使用者存取權限的過程中存在缺陷，攻擊者破壞了憑證。
解釋 U1.1.11。
例如，用戶被解僱後，他的帳戶仍然未被封鎖。
U1.2。 <...> 利用存取控制系統中的漏洞。
U2。 資訊系統中未經授權的使用者權限提升
分解
U2.1 <…> 對包含使用者權限資訊的資料進行未經授權的變更。
U2.2 <…> 透過利用存取控制系統中的漏洞。
U2.3。 <...> 由於使用者存取管理過程中的缺陷。
解釋 U2.3。
範例 1. 使用者獲得的工作存取權限多於其出於業務原因所需的權限。
範例2：使用者調任其他職位後，先前授予的存取權限並未被撤銷。
典型的威脅模型。 整合模組
應用威脅模型（範圍）的保護對象
整合模組是一組資訊基礎設施對象，旨在組織資訊系統之間的資訊交換。
考慮到在企業網路中並不總是能夠明確地將一個資訊系統與另一個資訊系統分開這一事實，整合模組也可以被視為一個資訊系統內的組件之間的連接鏈路。
架構
整合模組的概括圖如下所示：
建築元素描述：
- “交換伺服器（SO）” – 資訊系統的節點/服務/組件，執行與另一個資訊系統交換資料的功能。
- “調解人” – 旨在組織資訊系統之間互動的節點/服務，但不是資訊系統的一部分。
例子 “中間人” 可能有電子郵件服務、企業服務總線（企業服務總線/SoA架構）、第三方檔案伺服器等。 一般來說，整合模組可能不包含「中介體」。 - 《數據處理軟體》 – 一組實作資料交換協定和格式轉換的程式。
例如，將資料從UFEBS格式轉換為ABS格式、傳輸過程中改變訊息狀態等。 - “網路連線” 對應於標準「網路連線」威脅模型中所述的物件。 上圖中顯示的某些網路連線可能不存在。
整合模組範例
方案1.透過第三方檔案伺服器整合ABS和AWS KBR
為了執行付款，授權的銀行員工從核心銀行系統下載電子付款文件並將其保存到文件伺服器上網路資料夾 (...SHARE) 上的文件（以其自己的格式，例如 SQL 轉儲）。 然後使用轉換器腳本將該文件轉換為一組 UFEBS 格式的文件，然後由 CBD 工作站讀取。
此後，授權員工（自動化工作場所 KBR 的使用者）對收到的文件進行加密和簽名，並將其發送到俄羅斯銀行的支付系統。
當收到俄羅斯銀行的付款時，KBR 的自動化工作場所會對其進行解密並檢查電子簽名，然後以 UFEBS 格式的一組文件的形式將其記錄在文件伺服器上。 在將付款單據匯入 ABS 之前，使用轉換器腳本將其從 UFEBS 格式轉換為 ABS 格式。
我們假設在該方案中，ABS運行在一台實體伺服器上，KBR工作站運行在一台專用電腦上，轉換器腳本運行在檔案伺服器上。
所考慮的圖表的物件與整合模組模型的元素的對應關係：
“ABS 端的交換伺服器” – ABS 伺服器。
“AWS KBR 端的交換伺服器” – 電腦工作站 KBR。
“調解人” – 第三方檔案伺服器。
《數據處理軟體》 – 轉換器腳本。
方案 2. 將包含付款的共用網路資料夾放置在 AWS KBR 上時整合 ABS 和 AWS KBR
一切都與方案1類似，但沒有使用單獨的文件伺服器；而是將帶有電子支付文件的網路資料夾（...SHARE）放置在具有CBD工作站的電腦上。 轉換器腳本也可以在 CBD 工作站上執行。
所考慮的圖表的物件與整合模組模型的元素的對應關係：
與方案1類似，但是 “調解人” 不曾用過。
方案 3. 透過 IBM WebSphera MQ 整合 ABS 和自動化工作場所 KBR-N 以及「在 ABS 端」簽署電子文檔
ABS 在 CIPF SCAD 簽章不支援的平台上運作。 外發電子文件的簽章是在專門的電子簽章伺服器（ES Server）上進行的。 同一台伺服器檢查來自俄羅斯銀行的文件的電子簽名。
ABS 將帶有自己格式的付款單據的檔案上傳到 ES 伺服器。
ES 伺服器使用轉換器腳本將檔案轉換為 UFEBS 格式的電子訊息，然後將電子訊息簽署並傳送到 IBM WebSphere MQ。
KBR-N 工作站存取 IBM WebSphere MQ 並從那裡接收簽署的付款訊息，之後授權員工（KBR 工作站的使用者）對這些訊息進行加密並將其發送到俄羅斯銀行的支付系統。
當從俄羅斯銀行收到付款時，自動化工作場所 KBR-N 會對其進行解密並驗證電子簽名。 成功處理的付款以 UFEBS 格式的解密和簽署電子訊息的形式傳輸到 IBM WebSphere MQ，電子簽署伺服器從那裡接收這些訊息。
電子簽名伺服器驗證收到的付款的電子簽名並將其保存在ABS格式的檔案中。 此後，授權員工（ABS 使用者）以規定方式將產生的文件上傳到 ABS。
所考慮的圖表的物件與整合模組模型的元素的對應關係：
“ABS 端的交換伺服器” – ABS 伺服器。
“AWS KBR 端的交換伺服器” — 計算機工作站 KBR。
“調解人” – ES 伺服器和 IBM WebSphere MQ。
《數據處理軟體》 – 腳本轉換器、ES 伺服器上的 CIPF SCAD 簽章。
方案4.透過專用交換伺服器提供的API將RBS伺服器與核心銀行系統集成
我們假設銀行使用多個遠距銀行系統 (RBS)：
- 個人「網路客戶銀行」（IKB FL）；
- 法人實體的「網路客戶銀行」(IKB LE)。
為了確保資訊安全，ABS與遠端銀行系統之間的所有互動都是透過在ABS資訊系統框架內運行的專用交換伺服器進行的。
接下來，我們將考慮IKB LE的RBS系統與ABS之間的互動過程。
RBS 伺服器在收到來自客戶端的經過正式認證的付款訂單後，必須基於該訂單在 ABS 中建立相應的文件。 為此，它使用 API 將資訊傳輸到交換伺服器，交換伺服器將資料輸入 ABS。
當客戶的帳戶餘額變更時，ABS 會產生電子通知，並使用交換伺服器將其傳輸到遠端銀行伺服器。
所考慮的圖表的物件與整合模組模型的元素的對應關係：
“RBS 端的交換伺服器” – IKB YUL 的 RBS 伺服器。
“ABS 端的交換伺服器” – 交換伺服器。
“調解人” - 缺席的。
《數據處理軟體》 – RBS伺服器元件負責使用交換伺服器API，交換伺服器元件負責使用核心銀行API。
頂級安全威脅
分解
U1。 攻擊者透過整合模組注入虛假資訊。
U1。 攻擊者透過整合模組注入虛假訊息
分解
U1.1。 透過網路連線傳輸時對合法資料進行未經授權的修改：
U1.1.1連結： .
U1.2。 代表合法交易參與者透過通訊管道傳輸虛假資料：
U1.1.2連結： .
U1.3。 在 Exchange 伺服器或中介上處理合法資料期間對合法資料進行未經授權的修改：
U1.3.1。 關聯： .
U1.4。 代表合法交換參與者在 Exchange 伺服器或中介上建立虛假資料：
U1.4.1。 關聯：
U1.5。 使用資料處理軟體處理資料時未經授權的修改：
U1.5.1。 <...> 由於攻擊者對資料處理軟體的設定（配置）進行未經授權的更改。
U1.5.2。 <...> 由於攻擊者對資料處理軟體的可執行檔進行未經授權的變更。
U1.5.3。 <…>由於攻擊者對資料處理軟體的互動控制。
典型的威脅模型。 密碼資訊保護系統
應用威脅模型（範圍）的保護對象
保護的對像是用來確保資訊系統安全的密碼資訊保護系統。
架構
任何資訊系統的基礎都是實現其目標功能的應用軟體。
加密保護通常是透過從應用軟體的業務邏輯呼叫加密原語來實現的，這些原語位於專門的庫 - 加密核心中。
加密原語包括低階加密函數，例如：
- 加密/解密資料塊；
- 建立/驗證資料區塊的電子簽名；
- 計算資料塊的雜湊函數；
- 產生/載入/上傳關鍵資訊；
- 等等
應用程式軟體的業務邏輯使用加密原語實現更高層級的功能：
- 使用所選收件人的金鑰加密檔案；
- 建立安全的網路連線；
- 告知電子簽名檢查結果；
- 等等。
業務邏輯與加密核心的互動可以進行：
- 直接透過業務邏輯從加密核心的動態程式庫呼叫加密原語（.DLL for Windows，.SO for Linux）；
- 直接透過加密介面 - 包裝器，例如 MS Crypto API、Java Cryptography Architecture、PKCS#11 等。在這種情況下，業務邏輯存取加密接口，並將呼叫轉換為相應的加密核心，其中這種情況稱為加密提供商。 加密介面的使用允許應用軟體從特定的加密演算法中抽像出來並且更加靈活。
組織加密核心有兩種典型的方案：
方案 1 – 單晶片加密核心
方案2——分裂加密核心
上圖中的元素可以是在一台電腦上運行的單獨軟體模組，也可以是在電腦網路內互動的網路服務。
當使用根據方案1建構的系統時，應用軟體和加密核心在加密工具（SFC）的單一操作環境中運行，例如，在運行相同作業系統的同一台電腦上。 通常，系統使用者可以在同一操作環境中執行其他程序，包括那些包含惡意程式碼的程式。 在這種情況下，私鑰外洩的風險非常嚴重。
為了最小化風險，採用方案2，其中加密核心分為兩部分：
- 第一部分與應用程式軟體一起在不可信的環境中運行，有感染惡意程式碼的風險。 我們將這部分稱為「軟體部分」。
- 第二部分在專用裝置上的受信任環境中工作，其中包含私鑰儲存。 從現在開始，我們將這部分稱為「硬體」。
將加密核心劃分為軟體和硬體部分是非常任意的。 市場上有一些系統是根據分割加密核心的方案建構的，但其「硬體」部分以虛擬機器映像的形式呈現－虛擬 HSM（).
加密核心的兩個部分的交互以這樣的方式發生：私人加密金鑰永遠不會傳輸到軟體部分，因此，不能使用惡意程式碼來竊取。
在這兩種情況下，加密核心向應用軟體提供的互動介面（API）和加密原語集是相同的。 差別在於它們的實作方式。
因此，當採用分核方案時，軟體和硬體的交互作用依照以下原則進行：
- 不需要使用私鑰的加密原語（例如，計算雜湊函數、驗證電子簽章等）由軟體執行。
- 使用私鑰的加密原語（建立電子簽章、解密資料等）由硬體執行。
讓我們使用創建電子簽名的範例來說明劃分的加密核心的工作：
- 軟體部分計算簽署資料的雜湊函數，並透過加密核心之間的交換通道將該值傳輸到硬體。
- 硬體部分使用私鑰和雜湊產生電子簽名的值，並透過交換通道將其傳輸到軟體部分。
- 軟體部分將接收到的值傳回給應用軟體。
檢查電子簽名正確性的特點
當接收方收到電子簽署的資料時，必須執行幾個驗證步驟。 只有成功完成驗證的所有階段，才能獲得檢查電子簽名的正面結果。
第 1 階段。控制資料完整性和資料作者身分。
舞台內容。 使用適當的加密演算法驗證資料的電子簽章。 該階段的成功完成表明資料自簽署那一刻起就沒有被修改過，並且簽名是使用與驗證電子簽署的公鑰相對應的私鑰進行的。
舞台位置： 加密核心。
第二階段，控制簽署人公鑰的信任度和電子簽章私鑰有效期限的控制。
舞台內容。 此階段由兩個中間子階段組成。 首先是確定用於驗證電子簽名的公鑰在對資料進行簽署時是否可信。 第二個確定電子簽章的私鑰在簽署資料時是否有效。 一般來說，這些金鑰的有效期限可能不一致（例如，對於電子簽章驗證金鑰的合格憑證）。 建立對簽署者公鑰的信任的方法由互動方採用的電子文檔管理規則決定。
舞台位置： 應用軟體/加密核心。
第三階段：簽署人權力的控制。
舞台內容。 根據電子文件管理既定規則，檢查簽名人是否有權證明受保護的資料。 舉個例子，我們舉一個違反職權的情況。 假設有一個組織，所有員工都有電子簽名。 內部電子文檔管理系統接收來自經理的訂單，但由倉庫經理的電子簽名簽署。 因此，此類文件不能被視為合法。
舞台位置： 應用程式軟體。
描述保護物件時所做的假設
- 訊息傳輸通道除密鑰交換通道外，還透過應用軟體、API和加密核心。
- 有關對公鑰和（或）證書的信任的資訊以及有關公鑰所有者的權力的資訊被放置在公鑰儲存中。
- 應用程式軟體透過加密核心與公鑰儲存一起工作。
使用 CIPF 保護的資訊系統範例
為了說明前面給出的圖表，讓我們考慮一個假設的資訊系統並突出顯示其上的所有結構元素。
資訊系統說明
兩個組織決定在彼此之間引入具有法律意義的電子文件管理 (EDF)。 為此，他們簽訂了一份協議，規定文件將透過電子郵件傳輸，同時必須對其進行加密並使用合格的電子簽名進行簽署。 應使用 Microsoft Office 2016 軟體套件中的 Office 程式作為建立和處理文件的工具，並應使用 CIPF CryptoPRO 和加密軟體 CryptoARM 作為加密保護手段。
組織基礎設施描述1
組織 1 決定在使用者的工作站（一台實體電腦）上安裝 CIPF CryptoPRO 和 CryptoARM 軟體。 加密和電子簽署金鑰將儲存在 ruToken 金鑰媒體上，以可檢索金鑰模式運作。 使用者將在自己的電腦上本地準備電子文檔，然後使用本地安裝的電子郵件用戶端對其進行加密、簽署和發送。
組織基礎設施描述2
組織 2 決定將加密和電子簽章功能移至專用虛擬機器。 在這種情況下，所有加密操作都會自動執行。
為此，在專用虛擬機器上組織了兩個網路資料夾：「...In」、「...Out」。 從對方以開放式形式收到的檔案將自動放置在網路資料夾「...In」中。 這些文件將被解密並驗證電子簽名。
用戶將需要加密、簽名並發送給對方的文件放在「…Out」資料夾中。 使用者將在自己的工作站上自行準備文件。
為了執行加密和電子簽章功能，虛擬機器上安裝了 CIPF CryptoPRO、CryptoARM 軟體和電子郵件用戶端。 虛擬機器所有元素的自動管理將使用系統管理員開發的腳本進行。 腳本的工作記錄在日誌檔案中。
電子簽署的加密金鑰將放置在具有不可檢索的 JaCarta GOST 金鑰的令牌上，用戶將其連接到本機。
令牌將使用安裝在使用者工作站和虛擬機器上的專用 USB-over-IP 軟體轉送到虛擬機器。
將手動調整組織 1 中使用者工作站上的系統時鐘。 組織 2 中的專用虛擬機器的系統時鐘將與管理程式系統時鐘同步，而管理程式系統時鐘將透過 Internet 與公用時間伺服器同步。
CIPF結構要素的識別
基於上面對IT基礎設施的描述，我們將重點放在CIPF的結構要素並將其寫在表格中。
表 - CIPF 模型元素與資訊系統元素的對應關係
物品名稱
組織1
組織2
應用程式軟體
CryptoARM 軟體
CryptoARM 軟體
加密核心的軟體部分
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
加密核心硬體
沒有
雅卡塔GOST
API
微軟加密API
微軟加密API
公鑰儲存
使用者工作站：
- 硬碟;
- 標準 Windows 憑證儲存。
管理程序：
- 硬碟.
虛擬機器：
- 硬碟;
- 標準 Windows 憑證儲存。
私鑰儲存
ruToken 金鑰載體以可檢索金鑰模式運行
JaCarta GOST 鑰匙架以不可拆卸鑰匙模式運行
公鑰交換通道
使用者工作站：
- 內存。
管理程序：
- 內存。
虛擬機器：
- 內存。
私鑰交換通道
使用者工作站：
— USB匯流排；
- 內存。
沒有
加密核心之間的交換通道
缺少（無加密核心硬體）
使用者工作站：
— USB匯流排；
- 內存;
— USB-over-IP軟體模組；
- 網路介面。
2. 組織的企業網絡
管理程序：
- 內存;
- 網路介面。
虛擬機器：
——網路介面；
- 內存;
— USB-over-IP 軟體模組。
開放資料通道
使用者工作站：
——輸入輸出裝置；
- 內存;
- 硬碟.
使用者工作站：
——輸入輸出裝置；
- 內存;
- 硬碟;
- 網路介面。
2. 組織的企業網絡
管理程序：
——網路介面；
- 內存;
- 硬碟.
虛擬機器：
——網路介面；
- 內存;
- 硬碟.
安全的資料交換通道
因特網。
1. 組織的企業網絡
使用者工作站：
- 硬碟;
- 內存;
- 網路介面。
因特網。
2. 組織的企業網絡
管理程序：
——網路介面；
- 內存;
- 硬碟.
虛擬機器：
——網路介面；
- 內存;
- 硬碟.
時間通道
使用者工作站：
——輸入輸出裝置；
- 內存;
- 系統計時器。
因特網。
組織2的公司網絡，
管理程序：
——網路介面；
- 內存;
- 系統計時器。
虛擬機器：
- 內存;
- 系統計時器。
控制指令傳輸通道
使用者工作站：
——輸入輸出裝置；
- 內存。
（CryptoARM軟體的圖形使用者介面）
虛擬機器：
- 內存;
- 硬碟.
（自動化腳本）
工作成果接收管道
使用者工作站：
——輸入輸出裝置；
- 內存。
（CryptoARM軟體的圖形使用者介面）
虛擬機器：
- 內存;
- 硬碟.
（自動化腳本的日誌檔）
頂級安全威脅
說明
分解威脅時所做的假設：
- 使用強大的加密演算法。
- 加密演算法在正確的操作模式下安全地使用（例如 不用於加密大量數據，考慮到金鑰上允許的負載等）。
- 攻擊者知道使用的所有演算法、協定和公鑰。
- 攻擊者可以讀取所有加密資料。
- 攻擊者能夠複製系統中的任何軟體元素。
分解
U1。 私人加密密鑰的洩漏。
U2。 代表合法發送者加密虛假資料。
U3。 非資料合法接收者（攻擊者）對加密資料進行解密。
U4。 根據虛假資料建立合法簽名人的電子簽名。
U5。 透過檢查偽造資料的電子簽名獲得肯定的結果。
U6。 由於電子文件管理組織存在問題，導致電子文件錯誤接受執行。
U7。 CIPF 處理受保護資料期間未經授權存取這些資料。
U1。 私人密鑰的洩露
U1.1。 從私鑰儲存中檢索私鑰。
U1.2。 從加密工具操作環境中的物件取得私鑰，私鑰可能暫時駐留在其中。
解釋 U1.2。
可以暫時儲存私鑰的物件包括：
- 內存，
- 臨時文件，
- 交換文件，
- 休眠文件，
- 虛擬機器「熱」狀態的快照文件，包括已暫停虛擬機器的 RAM 內容的文件。
U1.2.1。 透過凍結 RAM 模組、刪除它們然後讀取資料（凍結攻擊），從工作 RAM 中提取私鑰。
解釋 U1.2.1。
例子 .
U1.3。 從私鑰交換通道取得私鑰。
解釋 U1.3。
將給出實施此威脅的範例 .
U1.4。 未經授權修改加密核心，導致攻擊者獲知私鑰。
U1.5。 由於使用技術資訊洩漏通道 (TCIL) 導致私鑰洩漏。
解釋 U1.5。
例子 .
U1.6。 由於使用專為秘密檢索資訊而設計的特殊技術手段 (STS)（「錯誤」）而導致私鑰洩露。
U1.7。 私鑰在 CIPF 外部儲存期間遭到外洩。
解釋 U1.7。
例如，使用者將其密鑰媒體儲存在桌面抽屜中，攻擊者可以輕鬆地從中檢索它們。
U2。 代表合法寄件者加密虛假數據
說明
僅針對具有發送者身份驗證的資料加密方案才考慮此威脅。 標準化建議中指出了此類方案的範例 。 對於其他加密方案，這種威脅不存在，因為加密是在接收者的公鑰上執行的，而且攻擊者通常知道它們。
分解
U2.1。 洩漏發送者的私鑰：
U2.1.1。 關聯： .
U2.2。 在開放資料交換通道中取代輸入資料。
註釋U2.2。
下面給出了實施這種威脅的範例。 и .
U3。 非資料合法接收者（攻擊者）對加密資料進行解密
分解
U3.1。 加密資料接收者的私鑰遭到外洩。
U3.1.1連結： .
U3.2。 在安全資料交換通道中取代加密資料。
U4。 使用虛假資料建立合法簽署者的電子簽名
分解
U4.1。 合法簽署者的電子簽名私鑰遭到洩漏。
U4.1.1連結： .
U4.2。 在開放資料交換通道中取代簽章資料。
注意U4.2。
下面給出了實施這種威脅的範例。 и .
U5。 透過檢查偽造數據的電子簽名獲得肯定結果
分解
U5.1。 攻擊者在傳輸工作結果的通道中攔截電子簽名檢查結果為陰性的訊息，並將其替換為陽性結果的訊息。
U5.2。 攻擊者攻擊簽署憑證的信任（SCRIPT - 所有元素都是必需的):
U5.2.1。 攻擊者產生電子簽名的公鑰和私鑰。 如果系統使用電子簽名金鑰證書，那麼他們會產生一個電子簽名證書，該證書與他們想要偽造其訊息的資料的預期發送者的證書盡可能相似。
U5.2.2。 攻擊者對公鑰儲存進行未經授權的更改，從而為他們產生的公鑰提供必要級別的信任和權限。
U5.2.3。 攻擊者使用先前產生的電子簽署金鑰簽署虛假數據，並將其插入安全數據交換通道。
U5.3。 攻擊者使用合法簽署人的過期電子簽章金鑰進行攻擊（SCRIPT - 所有元素都是必需的):
U5.3.1。 攻擊者洩漏合法寄件者的電子簽名的過期（目前無效）私鑰。
U5.3.2。 攻擊者將時間傳輸通道中的時間替換為洩漏金鑰仍然有效的時間。
U5.3.3。 攻擊者使用先前洩漏的電子簽署金鑰簽署虛假數據，並將其註入安全數據交換通道。
U5.4。 攻擊者使用合法簽署人的受損電子簽署金鑰進行攻擊（SCRIPT - 所有元素都是必需的):
U5.4.1。 攻擊者製作公鑰儲存的副本。
U5.4.2。 攻擊者破壞了合法寄件者之一的私鑰。 他注意到了妥協，撤銷了金鑰，並將有關金鑰撤銷的資訊放置在公鑰儲存中。
U5.4.3。 攻擊者用之前複製的公鑰替換了公鑰儲存。
U5.4.4。 攻擊者使用先前洩漏的電子簽署金鑰簽署虛假數據，並將其註入安全數據交換通道。
U5.5。 <…>由於電子簽章驗證第二階段和第三階段的實作有錯誤：
解釋 U5.5。
給出了實施此威脅的範例 .
U5.5.1。 僅透過對其進行簽署的憑證是否存在信任來檢查對電子簽署金鑰憑證的信任，而不進行 CRL 或 OCSP 檢查。
解釋 U5.5.1。
實施例 .
U5.5.2。 建立憑證信任鏈時，不分析憑證授權單位
解釋 U5.5.2。
針對 SSL/TLS 憑證的攻擊範例。
攻擊者為其電子郵件購買了合法證書。 然後他們製作了一個欺詐性的網站證書並用他們的證書進行了簽名。 如果不檢查憑證，那麼在檢查信任鏈時，它會被證明是正確的，相應地，欺詐性證書也將是正確的。
U5.5.3。 建立憑證信任鏈時，不會檢查中間憑證是否被撤銷。
U5.5.4。 CRL 的更新頻率低於憑證授權單位所發布的頻率。
U5.5.5。 信任電子簽章的決定是在收到有關憑證狀態的 OCSP 回應之前做出的，該回應是根據晚於簽章產生時間或早於簽章產生後下一個 CRL 發出的請求發送的。
解釋 U5.5.5。
在大多數CA的規定中，憑證撤銷時間被認為是包含憑證撤銷資訊的最近的CRL的頒發時間。
U5.5.6。 接收簽署資料時，不檢查屬於發送者的憑證。
解釋 U5.5.6。
攻擊範例。 對於SSL憑證：可以不檢查被叫伺服器位址與憑證中CN欄位值的對應關係。
攻擊範例。 攻擊者洩漏了支付系統參與者之一的電子簽名金鑰。 之後，他們侵入了另一名參與者的網絡，並代表他將使用洩露密鑰簽署的支付文件發送到支付系統的結算伺服器。 如果伺服器只分析信任而不檢查合規性，那麼欺詐性文件將被視為合法。
U6。 由於電子文件管理組織存在問題，導致電子文件錯誤接受執行。
分解
U6.1。 接收方未發現收到的文件有重複。
解釋 U6.1。
攻擊範例。 攻擊者可以攔截正在傳輸給收件人的文檔，即使該文檔受到加密保護，然後透過安全資料傳輸通道重複傳送該文檔。 如果收件者未識別重複項，則所有收到的文件將被視為不同的文件並進行處理。
U7。 CIPF 處理受保護資料期間未經授權存取這些數據
分解
U7.1。 <...> 由於透過側通道洩漏資訊（側通道攻擊）。
解釋 U7.1。
例子 .
U7.2。 <…> 由於對 CIPF 上處理的資訊的未經授權存取的保護失效：
U7.2.1。 CIPF 的操作違反了 CIPF 文件中所述的要求。
U7.2.2。 <...>，由於以下方面存在漏洞而執行：
U7.2.2.1。 <…> 防止未經授權存取的手段。
U7.2.2.2。 <...> CIPF 本身。
U7.2.2.3。 <…> 加密工具的運作環境。
攻擊範例
下面討論的場景顯然包含資訊安全錯誤，僅用於說明可能的攻擊。
情境 1. 威脅 U2.2 和 U4.2 的實作範例。
對象的描述
AWS KBR 軟體和 CIPF SCAD 簽章安裝在未連接到電腦網路的實體電腦上。 FKN vdToken 在使用不可拆卸密鑰的模式下用作密鑰載體。
結算規則假設結算專家從他的工作電腦上從特殊的安全文件伺服器以明文形式下載電子訊息（舊KBR工作站的方案），然後將其寫入可傳輸的USB隨身碟並將其傳輸到KBR工作站，它們被加密和簽署。 此後，專家將安全的電子訊息傳輸到異化介質，然後透過他的工作電腦將它們寫入文件伺服器，從那裡它們到達UTA，然後到達俄羅斯銀行的支付系統。
在這種情況下，交換開放資料和受保護資料的管道將包括：文件伺服器、專家的工作電腦和異化媒體。
攻擊
未經授權的攻擊者在專家的工作電腦上安裝遠端控制系統，並在將付款指令（電子訊息）寫入可傳輸媒體時，以明文取代其中一個的內容。 專家將付款訂單傳輸到 KBR 自動化工作場所，對其進行簽名和加密，而不會注意到替換（例如，由於航班上有大量付款訂單、疲勞等）。 此後，偽造的支付指示透過技術鏈進入俄羅斯銀行的支付系統。
情境 2. 威脅 U2.2 和 U4.2 的實作範例。
對象的描述
一台安裝了工作站 KBR、SCAD 簽章和連接的金鑰載體 FKN vdToken 的電腦在專用房間中運行，無需人員存取。
計算專家透過RDP協定以遠端存取模式連接到CBD工作站。
攻擊
攻擊者攔截計算專家連接 CBD 工作站並與之合作的詳細資訊（例如，透過其電腦上的惡意程式碼）。 然後他們代表他連接並向俄羅斯銀行支付系統發送虛假付款指令。
場景 3. 威脅實施範例 U1.3。
對象的描述
讓我們考慮為新方案 (AWS KBR-N) 實施 ABS-KBR 整合模組的假設選項之一，其中傳出文件的電子簽章發生在 ABS 端。 在這種情況下，我們將假設 ABS 在 CIPF SKAD 簽章不支援的作業系統基礎上運行，因此，加密功能將轉移到單獨的虛擬機器 - “ABS-KBR”整合模組。
以可檢索密鑰模式運行的常規 USB 令牌用作密鑰載體。 將密鑰媒體連接到虛擬機管理程式時，發現系統中沒有空閒的 USB 端口，因此決定透過網路 USB 集線器連接 USB 令牌，並在虛擬機器上安裝 USB-over IP 用戶端機器，它將與集線器通信。
攻擊
攻擊者從USB集線器和虛擬機器管理程式之間的通訊通道截獲了電子簽署的私鑰（資料以明文形式傳輸）。 攻擊者擁有私鑰後，產生虛假支付訂單，使用電子簽名對其進行簽名，並將其發送到 KBR-N 自動化工作場所執行。
場景 4. 威脅 U5.5 的實作範例。
對象的描述
讓我們考慮與前面場景相同的電路。 我們假設來自 KBR-N 工作站的電子訊息最終位於 ...SHAREIn 資料夾中，而發送到 KBR-N 工作站並進一步發送到俄羅斯銀行支付系統的電子訊息則轉到 ...SHAREout。
我們還將假設在實現整合模組時，僅在重新頒發加密金鑰時更新已撤銷憑證的列表，並且僅檢查…SHAREIn資料夾中收到的電子訊息的公鑰中的完整性控制和信任控制。電子簽名。
攻擊
攻擊者利用在上一場景中竊取的密鑰，簽署了一份虛假支付訂單，其中包含有關欺詐客戶帳戶收款信息，並將其引入安全數據交換通道。 由於無法驗證該付款指示是否由俄羅斯銀行簽署，因此接受執行。
來源： www.habr.com