研究其他部分的链接
- (你在这里)
本文完成了致力于确保银行非现金支付信息安全的系列出版物。 在这里我们将看看中提到的典型威胁模型 :
- .
- .
- .
- .
哈布罗-警告！！！ 亲爱的哈布罗维特人，这不是一个有趣的帖子。
隐藏在切口下的 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 设施可用且用户不在场的时间段内进行操作。
U1.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。 关联： .
У1.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文件夹中收到的电子消息的公钥中的完整性控制和信任控制的电子签名。
攻击
攻击者利用在上一场景中窃取的密钥，签署了一份虚假支付订单，其中包含有关欺诈客户账户收款信息，并将其引入安全数据交换通道。 由于无法验证该付款指令是否由俄罗斯银行签署，因此接受执行。
来源： habr.com