“灵活”的 k 出 n 签名与信任策略协商框架
1. “灵活”的 k 出 n 签名方案
在签名方案中,我们可以对签名输出形式进行修改。设 (z′ = (z+H(1))g),将哈希函数 (H) 转换为 (H′),即 (H′(L||m||z′||a) = H(L||m||z||a)),此时签名方案的输出可表示为 ((c, z′, s))。
验证签名正确性时,按以下步骤操作:
1. 计算 (a = z′syc)。
2. 检查 (c) 是否等于 (H′(L||m||z′||a))。
计算 (s) 等同于计算 (\log_{z′} \frac{a}{y^c})。由于哈希函数的单向性,(a) 的值必须在确定 (c) 之前确定,且 (c) 的值依赖于 (a),所以 (\frac{a}{y^c} \bmod p) 是 (Z_p) 中的随机值,攻击者难以确定。因此,计算 (\log_{z′} \frac{a}{y^c}) 在计算上是不可行的,其难度与计算 (\log_g z′) 相当。
下面证明环签名的一些性质:
- 即使知道长期私钥 (x),没有短期私钥 (r) 也无法闭合环。
- 没有人能知道对应于同一个短期公钥 (z_i) 的两个不同短期私钥 (r_i) 和 (r′_i)。
在每个环签名 (\sigma_j)((1 \leq j \leq k))中,(z_i) 是唯一的。若 (U_i) 想闭合下标 (j \neq i) 的第 (j) 个环,他必须拥有对应于该环中 (z_i) 的短期私钥 (r_j),满足 (g^{r_j}_i - H_i(j) = z_i = g^{r_i}_i - H_i(i) \pmod {p_i})。由于离散对数问题的难度,(U_i) 无法同时找到 (r_i) 和 (r_j)。因此,每个签名者 (U_i) 最多只能闭合一个环并形成一个 ((1, n)) 签名,(k) 个这样的签名组合起来就是所需的 ((k, n)) - 环签名方案。
定理 2 :基于离散对数问题的难度假设,所提出的 ((k, n)) - 环签名方案在随机预言模型下是无条件签名者模糊且 EUF - ACMA 安全的。
1.1 避免内部攻击
所提出方案的签名者模糊性仅被证明对外部攻击者是安全的。当存在不遵循协议的恶意签名者时,签名者模糊性将变得脆弱。然而,即使存在恶意签名者,签名者的匿名性也必须得到保留。
恶意签名者可能会说服其他签名者接受他的短期公钥 (z_i),在其他人提供 (1) 出 (n) 签名后,他可以证明自己的 (z_i) 无法由 (g^{r_i}_i - H_i(i)) 形成,例如 (z_i = H_i(d))((d) 是随机字符串),从而证明自己不是签名者之一。这意味着恶意签名者可以控制签名者的模糊性,使签名者不仅失去模糊性,还失去匿名性。
为避免这种攻击,每个潜在签名者在签名前可以通过零知识证明向其他签名者证明自己拥有短期私钥。零知识证明是一种证明者可以向验证者证明拥有某一信息而不泄露该信息的方法。
1.2 阈值 (k) 的灵活性
在某些应用中,签名者可能希望在签署(匿名)签名后改变决定,或者一些“非签名者”可能希望在签名发布前加入签名组并签署同一文档。对于基于秘密共享的环签名方案,通常需要先撤销原有的 ((k, n)) - 环签名,然后生成新的 ((k′, n)) - 阈值环签名。而我们的方案无需撤销原签名,也不需要额外的计算。
假设原始的 ((k, n)) - 环签名 (\sigma) 对消息 (m) 的表示为:
(\sigma = \left(\prod_{1\leq i\leq n} z_i, \prod_{1\leq i\leq k} \left(c_{(i,1)}, s_{(i,1)}, \cdots, s_{(i,n)}\right)\right))
若签名者 (U_k) 改变决定并希望撤销他的部分签名,签名组只需撤回 (U_k) 的签名 (\sigma_k),新的 ((k - 1, n)) - 环签名 (\sigma′) 对 (m) 的表示为:
(\sigma′ = \left(\prod_{1\leq i\leq n} z_i, \prod_{1\leq i\leq k - 1} \left(c_{(i,1)}, s_{(i,1)}, \cdots, s_{(i,n)}\right)\right))
相反,如果 (U_k) 一开始犹豫是否签署文档,他可以先参与协议的步骤 (1) 到 (3) 以生成他的短期私钥并发布短期公钥,然后单独形成他部分的环签名而不向其他签名者公开。此时,其他 (k - 1) 个签名者生成的签名 (\sigma′) 实际上是一个 ((k - 1, n)) - 环签名。当 (U_k) 决定签署文档时,他只需将自己的签名附加到 (\sigma′) 上,新的签名就是所需的 ((k, n)) - 环签名。
签名的数据大小为 (n|p| + k(n + 1)|q|),签名生成和验证的计算成本均为 (o(2knp))。
以下是阈值 (k) 灵活性的操作流程:
graph LR
classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;
A([开始]):::startend --> B{签名者是否改变决定}:::decision
B -- 是,撤销签名 --> C(撤回签名者的部分签名):::process
B -- 是,加入签名 --> D(签名者生成短期私钥和公钥):::process
D --> E(单独形成部分环签名):::process
E --> F(将签名附加到已有签名上):::process
B -- 否 --> G([结束]):::startend
C --> G
F --> G
2. 信任策略协商的形式框架
在自主系统的信任策略协商中,软约束可用于建模逻辑推理,包括演绎、溯因和归纳。我们主要关注溯因过程,并展示如何使用(软)约束移除操作符来实现它。
2.1 背景知识
一个吸收半环 (S) 可以表示为 (\langle A, +, \times, 0, 1\rangle) 元组,满足以下条件:
- (A) 是一个集合,(0, 1 \in A)。
- (+) 是可交换、可结合的,且 (0) 是其单位元。
- (\times) 是可结合的,对 (+) 分配,(1) 是其单位元,(0) 是其吸收元。此外,(+) 是幂等的,(1) 是其吸收元,(\times) 是可交换的。
定义关系 (\leq_S) 为:(a \leq_S b) 当且仅当 (a + b = b)。可以证明:
- (\leq_S) 是一个偏序。
- (+) 和 (\times) 在 (\leq_S) 上是单调的。
- (0) 是最小值,(1) 是最大值。
- (\langle A, \leq_S\rangle) 是一个完全格,对于所有 (a, b \in A),(a + b = lub(a, b))((lub) 是最小上界)。
半环结构还可以扩展为包含除法运算 (\div)。一个吸收半环 (S) 是可逆的,如果对于所有满足 (a \leq b) 的元素 (a, b \in A),存在一个元素 (c \in A) 使得 (b \times c = a)。若 (S) 是吸收且可逆的,当集合 ({x \in A | b \times x = a}) 对于所有满足 (a \leq b) 的元素 (a, b \in A) 都有最大值时,(S) 是通过剩余可逆的。如果 (S) 是吸收的,且集合 ({x \in A | b \times x \leq a}) 对于所有元素 (a, b \in A) 都有最大值(记为 (a \div b)),则 (S) 是剩余的。
一个软约束可以看作是一个约束,其中其变量的每个实例化都有一个关联的偏好。给定 (S = \langle A, +, \times, 0, 1\rangle) 和一个在有限域 (D) 上的有序变量集 (V),软约束是一个函数,它接受变量的赋值 (\eta : V \to D) 并返回半环中的一个值。使用此符号,(C = \eta \to A) 是可以从 (S)、(D) 和 (V) 构建的所有可能约束的集合。
约束的组合函数 (\otimes : C \times C \to C) 定义为 ((c_1 \otimes c_2)\eta = c_1\eta \times c_2\eta)。约束除法函数 (\ominus\div : C \times C \to C) 定义为 ((c_1 \ominus\div c_2)\eta = c_1\eta \div c_2\eta)。
给定一个约束 (c \in C) 和一个变量 (v \in V),(c) 在 (V - {v}) 上的投影 (c \Downarrow_{(V \setminus {v})}) 是一个约束 (c′),使得 (c′\eta = \sum_{d \in D} c\eta[v := d])。
约束之间的偏序 (\leq_S) 可以扩展为 (c_1 \sqsubseteq c_2 \Leftrightarrow c_1\eta \leq c_2\eta)。一个蕴含关系 (\vdash \subseteq \wp(C) \times C) 定义为:对于每个 (C \in \wp(C)) 和 (c \in C),(C \vdash c \Leftrightarrow \bigotimes C \sqsubseteq c)。因此,如果给定一个约束存储 (\sigma),(\sigma \sqsubseteq c)(或 (\sigma \vdash c)),则 (c) 是 (\sigma) 的逻辑结果。
考虑半环 (S = \langle A, +, \times, 0, 1\rangle)、变量域 (D)、有序变量集 (V) 以及相应的结构 (C),则 (S_C = \langle C, \otimes, \overline{0}, \overline{1}, \exists x, d_{xy}\rangle) 是一个圆柱约束系统。
以下是软约束相关操作的总结表格:
| 操作 | 定义 |
| ---- | ---- |
| 约束组合 (\otimes) | ((c_1 \otimes c_2)\eta = c_1\eta \times c_2\eta) |
| 约束除法 (\ominus\div) | ((c_1 \ominus\div c_2)\eta = c_1\eta \div c_2\eta) |
| 投影 (c \Downarrow_{(V \setminus {v})}) | (c′\eta = \sum_{d \in D} c\eta[v := d]) |
| 蕴含关系 (\vdash) | (C \vdash c \Leftrightarrow \bigotimes C \sqsubseteq c) |
2.2 逻辑推理的实现
在访问控制和信任管理中,演绎和溯因是两个重要的推理服务。
- 演绎 :给定一个策略和一组额外的事实和事件,演绎服务找出策略和事实的所有后果(行动或义务),即判断是否可以从策略和当前事实中推导出授予请求。
- 溯因 :大致来说,溯因是演绎的逆过程。给定一个策略和一个访问服务的请求,溯因在于找到能够授予访问权限的凭证/事件,即找到一组(可能最小的)事实,将其添加到策略中可以使请求成为逻辑结果。
在一个交互式(客户端 - 服务器)访问控制系统中,其工作流程如下:
1. 客户端提交一组凭证和服务请求。
2. 服务器根据客户端的凭证集检查访问策略是否授予请求。
3. 如果检查失败,服务器使用溯因推理找到一组(最小的)可披露的缺失凭证,这些凭证可以解锁所需资源。
4. 服务器将这些凭证返回给客户端。
5. 客户端在第二轮提供这些凭证。
此外,还可以用约束来表示归纳操作。
这些逻辑推理服务在自主网络节点中非常重要,在跨企业场景中,节点提供服务,访问决策依赖于客户端发送的属性凭证。使用软约束,用户希望以特定的信任级别获取资源,服务器的响应不仅要提供用户需要出示的凭证,还要提供这些凭证的信任级别。
以下是访问控制中演绎和溯因推理的操作流程:
graph LR
classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;
A([客户端提交请求和凭证]):::startend --> B(服务器检查请求):::process
B --> C{请求是否被授予}:::decision
C -- 是 --> D([授予访问]):::startend
C -- 否 --> E(服务器进行溯因推理):::process
E --> F(服务器返回缺失凭证):::process
F --> G(客户端提供缺失凭证):::process
G --> B
“灵活”的 k 出 n 签名与信任策略协商框架
3. 逻辑推理的约束实现
为了更具体地展示如何使用软约束实现逻辑推理,我们可以借助约束处理规则(Constraint Handling Rules,CHR)。CHR 是一种用于约束求解的声明式编程语言,它可以方便地实现演绎和溯因操作。
以下是一个简单的示例,展示如何使用 CHR 实现演绎和溯因:
% 定义约束
:- chr_constraint has_credential/1, access_granted/0, need_credential/1.
% 演绎规则:如果有特定凭证,则授予访问权限
has_credential(credential1), has_credential(credential2) <=> access_granted.
% 溯因规则:如果需要访问权限但缺少凭证,则找出需要的凭证
access_granted \ has_credential(credential1) | need_credential(credential1).
access_granted \ has_credential(credential2) | need_credential(credential2).
在这个示例中:
-
has_credential/1
表示拥有某个凭证。
-
access_granted/0
表示访问权限被授予。
-
need_credential/1
表示需要某个凭证。
演绎规则表明,当同时拥有
credential1
和
credential2
时,访问权限将被授予。溯因规则则在需要访问权限但缺少某个凭证时,找出需要的凭证。
下面是使用 CHR 实现逻辑推理的操作步骤:
1.
定义约束
:根据具体的应用场景,定义所需的约束,如凭证、访问权限等。
2.
编写演绎规则
:根据策略和事实,编写演绎规则,用于从已知的约束推导出新的约束。
3.
编写溯因规则
:根据需要实现的溯因功能,编写溯因规则,用于找出满足特定条件所需的约束。
4.
执行推理
:将已知的约束作为输入,执行 CHR 程序,得到推理结果。
4. 相关应用与优势
4.1 “灵活”的 k 出 n 签名方案的应用
“灵活”的 k 出 n 签名方案在许多领域都有重要的应用:
-
多方签名场景
:在需要多个签名者参与的场景中,如电子合同签署、分布式系统中的决策等,该方案允许签名者根据实际情况灵活调整签名的阈值 (k),提高了签名的灵活性和实用性。
-
匿名签名需求
:方案提供的签名者模糊性和匿名性,使得在一些需要保护签名者身份的场景中,如匿名投票、隐私保护的交易等,能够有效保护签名者的隐私。
以下是“灵活”的 k 出 n 签名方案应用的场景表格:
| 应用场景 | 描述 |
| ---- | ---- |
| 电子合同签署 | 多个参与方可以根据需要灵活决定签名的阈值,确保合同的有效性和安全性。 |
| 分布式系统决策 | 系统中的节点可以通过该签名方案进行决策,并且可以在决策过程中灵活调整参与签名的节点数量。 |
| 匿名投票 | 投票者的身份可以得到有效保护,同时可以根据需要调整投票的有效阈值。 |
| 隐私保护交易 | 交易双方可以在保护隐私的前提下进行签名,确保交易的安全性和匿名性。 |
4.2 信任策略协商框架的优势
信任策略协商的形式框架在自主系统中具有以下优势:
-
自动化协商
:通过软约束和逻辑推理的结合,可以实现自动化的信任策略协商,减少人工干预,提高协商效率。
-
考虑偏好和信任级别
:软约束可以将偏好和信任级别纳入考虑,使得协商结果更加符合实际需求。
-
灵活的推理服务
:提供演绎、溯因和归纳等多种推理服务,能够满足不同场景下的信任推导和授权需求。
以下是信任策略协商框架优势的对比表格:
| 优势 | 传统方法 | 本框架 |
| ---- | ---- | ---- |
| 协商效率 | 人工干预多,效率低 | 自动化协商,效率高 |
| 考虑因素 | 较少考虑偏好和信任级别 | 充分考虑偏好和信任级别 |
| 推理服务 | 单一推理服务 | 提供多种推理服务 |
5. 总结
本文介绍了“灵活”的 k 出 n 签名方案和信任策略协商的形式框架。
“灵活”的 k 出 n 签名方案是对传统签名方案的扩展,它不仅提供了阈值 (k) 的灵活性,还允许签名者的密钥对由不同的密钥生成中心(KGC)生成,密钥域也无需相同。该方案在多方签名和匿名签名场景中具有重要的应用价值,并且可以有效避免内部攻击。
信任策略协商的形式框架利用软约束来建模逻辑推理,包括演绎、溯因和归纳。通过软约束的操作,可以实现自动化的信任策略协商,同时考虑偏好和信任级别。该框架在自主系统的访问控制和信任管理中具有重要的应用前景,能够满足跨企业场景下的安全需求。
总的来说,这两个方案为签名和信任管理提供了更加灵活、安全和高效的解决方案,有望在未来的信息安全领域得到广泛应用。
以下是整个技术方案的总结流程图:
graph LR
classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;
A([开始]):::startend --> B(“灵活”的 k 出 n 签名方案):::process
B --> C(避免内部攻击):::process
B --> D(阈值 k 的灵活性):::process
A --> E(信任策略协商框架):::process
E --> F(软约束背景知识):::process
E --> G(逻辑推理实现):::process
E --> H(约束实现示例):::process
C --> I(应用场景):::process
D --> I
G --> I
H --> I
I --> J([结束]):::startend
超级会员免费看
14

被折叠的 条评论
为什么被折叠?



