EBS-安全性配置文件的作用、定义及使用

1、路径：HRMS->安全性->配置文件 

在MOAC中主要是使用按组织限制访问，在按组织访问设置的过程中该处定义的OU既是多OU的根本。

安全性配置文件的类型如下图所示，按组织层次结构和（或）组织列表列出的安全组织，就能实现多OU操作。

按组织层次结构和（或）组织列表列出的安全组织：

1.1通过预定义组织层次结构，来定义安全性配置文件。每次新增组织的时候，不需修改已有的安全性配置文件，只需要在组织层次结构里面新增组织即可。

组织层次结构里面可选择已经定义好的组织层次。

1.2组织层次结构的定义 HRMS->工作结构->组织->层次结构

1.3通过安全性配置文件的组织列表进行组织隔离，对下面列表的组织进行选择，并进行区分是要包括还是要排除，来限制组织的安全性。这种方法也可以针对一个组织，下面的列表里面只填写一个组织既可。

2、安全性配置文件定义或者修改后，需要运行以下请求，新的安全性配置文件才会生效。

路径：HRMS->[查看]-请求 

在定义好安全性控制文件后需要在HRMS职责下运行请求“维护安全性清单请求”，否则在打开业务实体首选项页面时会出现如下错误：APP-FND-02901: 您没有访问任何业务实体的权限。请检查您的配置文件选项“MO：安全性配置文件”是否包括任何业务实体，或是否设置了配置文件选项“MO：业务实体”。

3、安全性配置文件生效之后，可以根据职责或者用户等维度，进行分配。

系统管理员->配置文件->系统

 如下图示例：将能看到所有组织的安全性配置文件1000-XX分配给所有地点，然后再根据责任进行区分。

系统管理员的责任给与能查到所有组织的安全性配置文件，单个组织的责任，分配给只能查看这个组织的安全性配置文件。

作者简介

Gavin，程序员、软件架构师、企业架构师，关注智能制造。

本文是专栏《智能制造系统架构》中的文章，其它文章请参阅入坑智能制造系统架构。

软件安全性需求是指系统可靠地控制、监控和审计谁能够在哪种资源上执行哪种动作的能力，以及检测安全漏洞并从中恢复的能力。

安全策略与安全机制

软件系统通过安全策略定义安全性需要。安全策略定义了系统对资源的控制和保证，以及应该给当事人赋予的表示，以确定对系统中的每种资源（或者每种类型的资源）有什么样的访问。典型的安全策略会根据系统内不同类型的当事人，各种类型的信息，以及每组当事人所需要的访问类型来定义信息访问策略。安全性策略还需要定义如何控制特定敏感系统操作的执行。策略也应该定义必须执行的信息完整性约束以及保护信息不会收到授权变更。

安全策略通过安全机制来保证。安全机制是执行安全策略确定规则所需的技术、配置选项以及过程，它还会提供系统所需的机密性、完整性、可说明性和可用性的保证。

常见安全机制包括：

• 验证、授权和审计
• 信息私有性和完整性机制
• 不可否认机制
• 系统可用性机制
• 安全监控机制

分析软件安全性需求的步骤

分析软件安全性需求的步骤包括：

1. 确定敏感资源：首先要确定要确保哪些资源的安全。系统所有的安全性都需要由关键的关注点来驱动。
2. 定义安全策略：通过安全策略定义谁应该被信任、对哪些系统资源做出什么样的访问（以及所有在这种访问上的约束，如限制在特定的时间段或者每周特定的几天）、系统需要确保的完整性，以及访问敏感资源时所需要的可说明性。策略一般应该根据资源和用户的分组来定义（通常基于组织的单元和角色），而不是列举大量特定的情况。并且注意策略不是设计，因此它需要定义哪种访问会提供给谁，而不是定义如何到达这种访问方式。
3. 识别对系统的威胁：识别出对安全策略可能存在的威胁。识别威胁清晰地定义了需要保护什么，以及需要针对什么威胁来保护。
4. 设计安全实现：设计系统范围的安全性基础架构，从而可以在面临威胁模型中的风险时执行系统安全策略。这个步骤中，要考虑使用特定的安全技术，像单点登录系统、网络防火墙、SSL通信链接安全性、加密技术、策略管理系统等。
5. 评估安全风险：为系统设计好安全性基础架构之后，需要重新评估风险，考虑安全性基础架构是否达到了可接受的成本和风险之间的平衡。

安全性原则

安全性原则包括：

• 尽可能赋予最少量的权限：总是给安全性用户赋予他们执行任务所需的最少量权限。
• 保证最弱环节的安全性：识别并改善系统安全性的最弱环节，直到安全性风险达到一种可接受的等级。
• 深度防御：与其依赖于一种安全措施来应对系统的所有威胁，不如考虑对防御进行分层来提供更好的防护。
• 分离和划分：应该尽量清晰地分离不同的责任，从而在需要的情况下，把各种责任的权限分配给不同的用户，并划分系统不同部分的职责，以实现独立控制。
• 保持安全设计简单：安全性需求较强的系统需要足够简单，以使我们能够保证它的安全并加以验证。
• 不要依赖于隐晦：系统的设计假设潜在的攻击者知道它如何实现。
• 使用安全默认值：确保安全的默认行为对使用的系统安全性有效。
• 安全地出现故障：确保即使系统出现了故障，也能安全地处理。
• 假设外部实体不受信任：要确保所有外部实体在验证之前都是不受信任的，从而避免意料之外的情况违背安全性原则。
• 审计敏感事件：大多数系统都包含了大量与安全相关的关键事件，如重新设置密码，分配强大的角色，以及操作审计轨迹等。这些敏感事件需要安全地进行审计，从而监控对它们的使用。

安全性需求

在软件架构设计时，应该考虑如下安全性相关的需求：

遵守安全性原则

对用户进行身份验证

身份验证是要可靠地识别使用系统的参与者。特别是对于制造企业，随着网络化建设，互联网与企业的进一步融合，用户和设备及应用程序和数据正在向传统企业边界和控制区域之外迁移。这意味着，如果有人拥有正确的用户凭据，则他们将被允许进入他们请求的任何站点、应用程序或设备。这导致暴露的风险增加，从而瓦解了曾经值得信任的企业控制区域，并使许多公司面临数据泄露、恶意软件和勒索软件攻击的风险。因此企业网络的内部越来越不值得信任。因此，基于严格身份验证过程，定义了称为零信任的网络安全模式，只有经过身份验证和授权的用户和设备才能访问应用程序和数据。

具体要求包括：

• 唯一标识：系统中的每位参与者都应该由唯一标识
• 账户管理方式：账户的产生、修改、变更、删除以及身份认证应采用统一的身份认证平台来实现。当参与者可能需要通过多种身份验证技术在不同系统作多重登录时，推荐在不同的底层系统上使用某种形式的单点登录技术作统一层。
• 认证失败后的处理方式设计，防止黑客暴力猜测：连续失败登录后锁定账户。账户锁定后可以由系统管理员解锁，也可以在一段时间后自动解锁。
• 区分公共区域和受限区域：将站点分割为公共访问区域和受限访问区域，受限区域只能接受特定用户的访问，而且用户必须通过站点的身份验证。当未经认证的用户试图访问受限资源时，应用应自动提示用户认证。
• 使用强密码策略：内部系统的口令规则需要符合口令管理规则， 要求输入至少 8 位字符，其中要包含大写字母、小写字母、数字和特殊字符。
• 能够禁用账户：在系统受到威胁时使凭证失效或禁用账户，则可以避免遭受进一步的攻击。
• 不在用户存储中存储密码：如果必须验证密码，可以不实际存储密码。相反，可以存储一个单向哈希值，然后使用用户所提供的密码重新计算哈希值。为减少对用户存储的词典攻击威胁，可以使用强密码，并将随机 salt 值与该密码结合使用。
• 支持密码有效期：密码不应固定不变，而应作为常规密码维护的一部分，通过设置密码有效期对密码进行更改。
• 不在网络上以纯文本形式发送密码：以纯文本形式在网络上发送的密码容易被窃听。为了解决这一问题，应确保通信通道的安全，例如，使用 SSL 对数据流加密。
• 保护身份验证 Cookie：身份验证 cookie 被窃取意味着登录被窃取。可以通过加密和安全的通信通道来保护验证凭证。另外，还应限制验证凭证的有效期，以防止因重复攻击导致的欺骗威胁。
• 同一用户同时只允许登录一个：对进入保护区域的用户需要进行重新认证(比如从普通用户操作改变到管理员级别权限的操作、修改个人密码的操作)。
• 不使用多重关键字查找：使用多重关键字查找用户记录可能会导致SQL或LDAP注入问题。比如同时使用用户名和密码作为键来查找用户记录，且不检测SQL或LDAP注入，则任一字段都可能产生风险。

授权访问

一旦识别了参与者，授权就会涉及限制和强迫允许那些参与者在系统中能做什么。具体要求包括：

• 应用软件应包含用户权限分配和管理功能设计。如：
  • 系统读、写、执行权限设计。
  • 系统查看、配置、修改、删除、登录、运行等权限设计。
  • 数据访问范围的权限设计
  • 应用功能模块使用权限的设计
  • 限制用户对系统级资源的访问（系统级资源包括文件、文件夹、注册表项、Active Directory 对象、数据库对象、事件日志等。）
  • 应用使用的数据库账户必须是普通权限账户，只能访问允许的数据库；
  • 应用启动进程的权限应遵循“最小授权”原则
• 应用使用的系统账号（运行环境中的）应遵循“最小授权”原则。不使用“Administrator”, “root”, “sa”, “sysman”, “Supervisor”或其它所有的特权用户被用来运行应用程序或连接到网站服务器，数据库，或中间件。
• 调用方被映射到应用程序逻辑中间层中的角色，并基于角色成员身份限制对类和方法的访问权限。使用由当前调用方的角色成员身份所确定的有限标识集来执行下游资源访问。
• 在条件允许的情况下，尽量采用统一的访问控制机制。

确保信息保密性

保密性确保只有信息的所有者以及他们选择的共享者才能够读取信息。

保护敏感信息，具体要求包括：

• 尽量避免存储机密：在软件中以完全安全的方式存储机密是不可能的。可以接触到服务器的系统管理员可以访问这些数据。例如，当仅仅是验证用户是否知道某个机密时，则没有必要存储该机密。在这种情况下，可以存储代表机密的哈希值，然后使用用户提供的值计算哈希值，以验证该用户是否知道该机密。
• 不要在代码中存储机密：不要在代码中对机密进行硬编码。即使不将源代码暴露在 Web 服务器上，但从编译过的可执行文件中仍然可以提取字符串常量。配置漏洞可能会允许攻击者检索可执行文件。
• 不要在永久性 cookie 中存储敏感数据：避免在永久性 cookie 中存储敏感数据。如果存储的是纯文本数据，最终用户能够看到并修改该数据。如果对其加密，必须考虑密钥管理。
• 不要使用 HTTP-GET 协议传递敏感数据：避免使用 HTTP-GET 协议存储敏感数据，因为该协议使用查询字符串传递数据。使用查询字符串不能确保敏感数据的安全性，因为查询字符串经常被服务器记录下来。
• 对数据进行加密或确保通信通道的安全：如果在网络上向客户端发送敏感数据，应对数据进行加密或确保通信通道的安全。通常的做法是在客户端与 Web 服务器之间使用 SSL。当应用系统无法达到此要求时可以通过网络访问控制等手段限制可以访问应用系统的用户。
• 不要向客户端泄漏信息：发生故障时，不要暴露将会导致信息泄漏的消息。例如，不要暴露包括函数名以及调试内部版本时出问题的行数的堆栈跟踪详细信息。应向客户端返回一般性错误消息。
• 记录详细的错误信息：向错误日志发送详细的错误消息。应该向服务或应用程序的客户发送最少量的信息，如一般性错误消息和自定义错误日志 ID，随后可以将这些信息映射到事件日志中的详细消息。确保没有记录密码或其他敏感数据。
• 捕捉异常：使用结构化异常处理机制，并捕捉异常现象。这样做可以避免将应用程序置于不协调的状态，这种状态可能会导致信息泄漏。它还有助于保护应用程序免受拒绝服务攻击。

选择合适的加密方法，具体要求包括：

• 不使用自创加密方法：成功开发出加密算法和例程是非常难的。因此，应尽量使用平台提供的经过验证和测试的加密服务。
• 使用正确的算法和密钥大小：选择了正确的算法非常重要，另外，应确保所使用的密钥大小能提供足够的安全级别。密钥越大，安全性越高。
• 确保加密密钥的安全：加密密钥是输入加密及解密进程的秘密数字。为保证加密数据的安全，必须保护好密钥

确保信息完整性

完整性确保信息在未授权的情况下不会被变更（特别是在消息传递的过程中）。正确的输入验证是防御目前应用程序攻击的最有效方法之一。具体要求包括：

• 对所有的输入进行安全验证：开始输入验证时，首先假定所有输入都是恶意的，除非有证据表明它们并无恶意。无论输入是来自服务、共享文件、用户还是数据库，只要其来源不在可信任的范围之内，就应对输入进行验证。
• 采用集中验证方法：将输入验证策略作为应用程序设计的核心元素。考虑集中式验证方法，例如，通过使用共享库中的公共验证和筛选代码。这可确保验证规则应用的一致性。此外，还能减少开发的工作量，且有助于以后的维护工作。
• 在服务器端进行验证：应使用服务器端代码执行其自身的验证。使用客户端验证可以造成攻击者绕过客户端或关闭客户端脚本例程（例如，通过禁用JavaScript 脚本）。
• 确保用户没有绕过检查：确保用户没有通过操作参数而绕过检查。防止最终用户可以通过浏览器地址文本框操作 URL 参数。
• 不信任 HTTP 头信息：HTTP 头在 HTTP 请求和响应开始时发送。应确保 Web 应用程序的任何安全决策都不是基于 HTTP 头中包含的信息，因为攻击者很容易操作 HTTP 头。
• 注意标准化问题：标准化是指将数据转化为标准形式的过程。接受输入文件名、URL或用户名时必须先进行标准化。
• 限制、拒绝和净化：输入输入验证的首选方法是从开始就限制允许输入的内容。按照已知的有效类型、模式和范围验证数据。使用以下策略：
  • 限制输入：定义一个筛选器，根据类型、长度、格式和范围来筛选输入的数据。定义应用程序字段可以接受的数据输入，并强制应用该定义。拒绝一切有害数据。
  • 验证数据的类型、长度、格式和范围：在适当的地方对输入数据使用强类型检查，检查字符串字段的长度，检查字符串的格式是否正确。
  • 拒绝已知的有害输入：要拒绝有害数据，需假定应用程序知道恶意输入的所有变体。
  • 净化输入：向客户端写回数据时，对用户输入的数据进行 HTML 编码和 URL 编码检查，过滤特殊字符（包括HTML关键字以及&,\r\n,两个\n等字符）。
• SQL注入防范：进行数据库操作的时候，对用户提交的数据必须过滤 ’ ; -- 等特殊字符。
• XML注入防范：当使用XML文件格式存储数据时，若使用Xpath和XSLT功能，必须过滤用户提交数据中的< >  / ' = " 等字符。

确保可负责性

很多系统都要求某些或者所有用户对他们的动作负责。在信息系统中可能需要两种不同形式的可负责性：消息的审计和不可抵赖性。审计通过记录系统用户所执行的操作日志，用于确定特定的情况是如何发生的。不可抵赖性要求能够以某种方式确定地识别出消息的创建者，而让他无法抵赖。

审计的要求包括：

• 审核并记录跨应用层的访问：审核并记录跨应用层的访问，以便用于认可。考虑应用程序如何在多重应用层间传送调用方标识。
• 确保日志数据的安全：限制对日志数据的访问，加大了攻击者篡改日志数据以掩饰其攻击行为的难度。应将有权操作日志数据的个人数量减到最小。只为高度信任的账户（如管理员）授予访问权限。
• 定期备份和分析日志数据：如果从不对日志数据进行分析，则记录活动没有任何意义。应定期（至少一月一次）备份生产服务器上的日志数据。

保护可用性

系统可用性既包括可靠性、软件复制、灾难恢复等，也包括可用性相关的安全性内容，保护系统使其免受降低可用性的恶意攻击。这样的攻击叫做拒绝服务（Denial Of Service, Dos）。

应能设置系统会话时间，防止会话劫持和重复攻击的风险。

• 限制会话寿命：对于高度保护的应用系统，可将超时时间设置为5分钟，低风险的应用系统设置不能超过20分钟。
• 对身份验证 cookie 的内容进行加密：如果Cookie信息包含了身份验证信息，则必须对 cookie 内容进行加密。

整合安全性技术

安全性一般需要跨系统的多个部分来实现，所以需要对如何在系统中实现端到端的安全性尽早做出设计决定。在系统的安全设计方面，部分重要工作使确保安全性一致地实现，并且将不同部分的技术组合到一起，组成完整、整合的安全系统。

提供安全性管理

要确保计划和安全性实现能够得到有效的管理。

对配置管理必须的安全要求包括：

• 确保配置存储的安全：基于文本的配置文件、注册表和数据库是存储应用程序配置数据的常用方法。应避免在应用程序的 Web 空间使用配置文件，以防止可能出现的服务器配置漏洞导致配置文件被下载。应避免以纯文本形式存储机密，如数据库连接字符串或账户凭据。通过加密确保这些项目的安全，然后限制对包含加密数据的注册表项、文件或表的访问权限。
• 使用最少特权进程和服务账户：应用程序配置的一个重要方面是用于运行 Web 服务器进程的进程账户，以及用于访问下游资源和系统的服务账户。应确保为这些账户设置最少特权。

使用第三方的安全性基础架构

尽可能地策略执行推到系统的底层基础设备中。

检查列表

获取需求的检查列表

• 你是否确定了系统中包含的敏感资源？
• 你是否确定了一系列需要访问资源的用户？
• 你是否确定了系统对信息完整性保证的需求？
• 你是否确定了系统的可用性需求？
• 你是否确定了一种安全性策略，来定义系统所需要的安全性，包括允许哪些用户在哪些资源上执行哪些操作以及需要实施的信息完整性？
• 安全策略是否简单？
• 你是否已创建出正式的威胁模型，来识别系统所面临的安全性风险？
• 你是否考虑了系统外部人员和内部人员的威胁？
• 你是否考虑了系统外部人员和内部人员的威胁？
• 你是否考虑了系统的部署环境如何根据系统的威胁而改变？
• 你是否和利益相关者一起推出了示例场景，从而他们理解计划使用的安全策略以及系统所面临的安全性风险？
• 你是否与外部专家一起对安全性需求进行了评审？

架构定义的检查列表

• 你是否在威胁模型中按照要求程度说明了每种威胁？
• 你是否尽可能多地使用了第三方安全技术？
• 你是否为安全性解决方案创建了集成的总体设计？
• 在设计安全性基础架构的时候，你是否考虑了所有标准的安全性原则？
• 你的安全性基础架构是是否尽量简单？
• 你是否定义了如何识别违背安全性的情况以及如何从中恢复？
• 你是否对所有影响到的视图都应用了安全性视角？
• 外部专家是否评审了你的安全设计？

参考资料

• Software Systems Architecture, 2nd. 中文版 《软件系统架构》
• https://mp.weixin.qq.com/s/hRbgD6wcg8bMkKd1QfD1kA
• https://blog.csdn.net/momo_sleet/article/details/83054215

1，评估密码系统安全性主要有三种方法：

（1）无条件安全性

这种评价方法考虑的是假定攻击者拥有无限的计算资源，但仍然无法破译该密码系统。

（2）计算安全性

这种方法是指使用目前最好的方法攻破它所需要的计算远远超出攻击者的计算资源水平，则可以定义这个密码体制是安全的。

（3）可证明安全性

这种方法是将密码系统的安全性归结为某个经过深入研究的数学难题（如大整数素因子分解、计算离散对数等），数学难题被证明求解困难。这种评估方法存在的问题是它只说明了这个密码方法的安全性与某个困难问题相关，没有完全证明问题本身的安全性，并给出它们的等价性证明。

2，实际安全性

对于实际应用中的密码系统而言，由于至少存在一种破译方法，即强力攻击法，因此都不能满足无条件安全性，只提供计算安全性。密码系统要达到实际安全性，就要满足以下准则：
（1）破译该密码系统的实际计算量（包括计算时间或费用）十分巨大，以致于在实际上是无法实现的。
（2）破译该密码系统所需要的计算时间超过被加密信息有用的生命周期。例如，战争中发起战斗攻击的作战命令只需要在战斗打响前需要保密；重要新闻消息在公开报道前需要保密的时间往往也只有几个小时。
（3）破译该密码系统的费用超过被加密信息本身的价值。
如果一个密码系统能够满足以上准则之一，就可以认为是满足实际安全性的。

3，可证明安全性

3.1 可证明安全性体系的三大要素

在可证明安全体系中，有三大要素：安全模型，安全性定义和困难性问题。
安全模型分为安全目标和敌手能力。安全目标描述了安全模型要达到什么程度的安全，例如，对于加密算法的不可区分性（Indistinguishablity 简称 IND）、对于签名算法的存在性不可伪造（Existable Unforgeble 简称 EU）等。

其中不可区分性（IND）也称为语义安全（Semantic scurity），其定义如下。敌手即使获得了密文，也不能得到其对应明文的任何信息，哪怕是 1bit 的信息。其形式化的表示方法为：已知 m0，m1以及 Cb=Enc(pk，mb)，其中 m0是 m0或 m1中的任意一个，即 Cb是 m0、m1其中之一的密文，敌手无法有效判断加密过程中 b 到底是 0 还是 1。

3.2 安全性定义

刻画敌手的能力，主要有四类，选择明文攻击（Chosen Plaintext Attacke 简称 CPA）、选择密文攻击（Chosen Ciphertext Attack 简称 CCA）、惟密文攻击（Ciphertext-Only Attack）、已知明文攻击（Known Plaintext Attack）。常用的刻画敌手能力是前面两类，选择明文攻击（CPA）是指由敌手选择明文并且可以得到对应的密文。选择密文攻击（CCA）是指敌手不仅可以选择明文获得密文，还能选择有限次的密文，获得对应的明文。CCA比 CPA 描述敌手的能力更强。

下面介绍一下常用的安全性定义。

CPA 安全。我们把选择明文攻击（CPA）描述成一个游戏以方便我们更好的理解。首先声明一点，这个游戏的目的是在选择明文攻击的前提下攻破系统的不可区分性（Indistinguishablity），所以下面简称这个游戏为 IND-CPA。其次，还要定义两个角色挑战者 C 和敌手 A。挑战者（challenger）的任务相当裁判，主持游戏并且对敌手的行为进行反馈。敌手顾名思义，就是去攻击当前系统，而且对于这个游戏来说是采用选择明文攻击的方法进行攻击。游戏的描述如下：

A. 初始化：挑战者 C 创建 IND-CPA 系统，并且将公钥发送给敌手 A。

B. 敌手 A 选择两个长度相同的明文 m0，m1发送给挑战者 C。挑战者 C 随机选择 b∈｛0,1｝，并将 mb加密记作 cb，然后将密文cb发送给敌手 A。

C. 敌手 A 猜测挑战者 C 上一步进行加密的明文是 m0还是 m1，并且将猜测结果输出，输出结果记为 b‘。若 b‘=b，那么敌手攻击成功。

敌手攻击的优势可以定义为如下函数：

其中 w 是加密方案密钥的长度。因为随机猜测就有 1/2 的概率赢得 IND-CPA 游戏。所以

才是敌手经过努力得到的优势。如果对任何多项式时间的敌手 A，存在一个可忽略的优势σ，使得

那么就称这个加密算法在选择明文攻击下具有不可区分性，或者称为 IND-CPA 安全。

3.3 困难问题

有了安全模型和安全性定义，通常使用规约到困难问题的方法来进行安全性证明。密码学中常用的困难问题有离散对数困难问题（discrete logarithm problem，简称 DLP）、CDH 问题（Computational Diffie-Hellman） 、DDH 问题（Decisional Diffie-Hellman）以及 BDH 问题（Bilinear Diffie-Hellman）。

The Discrete Logarithm Problem(DLP)

The Computational Diffie-Hellman Problem(CDH)

The Decisional Diffie-Hellman Problem (DDH)

3.4 可证明安全性理论

有了前面叙述了安全模型，安全性定义，困难性问题，可证有了前面叙述了安全模型，安全性定义，困难性问题，可证明安全体系也变得可行。可证明安全性是指利用“规约”的方法，将攻击密码算法或安全协议的方法规约到一个攻击困难问题上。首先确定加密体制的安全目标，如签名体制的安全目标是签名的不可伪造性（Existable Unforgeble），加密体制的安全目标是信息的不可区分性（Indistinguishablity）。然后根据安全性定义确定敌手的能力构建一个安全性模型。

规约是复杂性理论中的概念， 一个问题P1规约到问题P2是指，已知解决问题 P1的算法 M1，我们能构造另一算法 M2，M2可以以 M1作为子程序，用来解决问题 P2。

将规约的方法应用在密码算法或安全协议的安全性证明上，例如，可以将敌手对密码算法或安全协议（P1）的攻击规约到一些已经得到深入研究的困难问题（P2）。即若敌手能够对算法或协议发起有效的攻击，就可以利用敌手构建一个算法来攻破困难问题，然而困难问题是已经被证明无法攻破的，这样就出现矛盾。根据反证法，敌手可以攻破算法或协议假设不成立，证明完毕。

一般来说，为了证明方案 1 的安全性，我们可以将方案 1 规约到方案 2，即如果敌手 A 可以攻破方案 1，那么敌手 B 同样也可以攻击方案 2，而方案 2 已经被证明是安全的，或者是一个难题。

证明过程通过一个思维游戏来描述。首先，挑战者创建方案2，B 表示方案 2 中的敌手，A 表示方案 1 中的敌手。B 为了攻破方案 2，利用 A 作为子程序来攻击方案 1。B 想要利用 A，就需要对 A 进行训练，所以 B 模拟了 A 的挑战者。

例如，如果要对加密算法进行安全性证明，那么方案 1 就是具 体 的 加 密 算 法 。 假 设 安 全 目 标 是 信 息 的 不 可 区 分 性（Indistinguishablity），敌手 A 的能力是可以选择明文攻击，即 CPA。敌手 B 模拟敌手 A 的挑战者，与 A 进行 IND-CPA 游戏。在游戏过程中，B 为了实现自己的目的利用 A。如果 A 无法判断自己是与 B 还是与挑战者做游戏，那么称 B 的模拟是完备的。

对于其他加密算法或加密协议，我们必须首先确定它想要实现的安全目标，例如签名方案的不可伪造性，然后根据安全性定义确定敌手的能力构建一个安全性模型，再把对加密算法或加密协议的攻击规约到已被证明的困难问题上。 这就是可证明安全性。

结语：可证明安全性理论是密码学理论与计算复杂性理论的一次完美结合，也是现代密码学的基石。在过去的 30 年终，现代密码学最大的突破就是把密码学体系建立在计算复杂理论上，这使得密码学从一门艺术发展成为一门严谨的学科。

转载链接：https://www.cnblogs.com/xdyixia/p/11610091.html
参考链接：https://www.cnblogs.com/zhuowangy2k/p/11901028.html