Tassa’s Hierarchical Threshold Secret Sharing

Table of Contents

1. 分层门限秘密共享简介

我们知道,利用 Shamir's Secret Sharing 方案可以把一个秘密值 S 分散保存到 n 个参与者中,至少需要 t 个参与者配合才能重新恢复出密码值 S 。在 Shamir 门限秘密共享方案中,得到秘密的每个参与者的地位是相同的,没有等级之分。

但是,在某些场景中,我们需要参与者有等级之分。比如,银行金库的电子钥匙,它被分散保存在员工手中,员工有两种角色:出纳员和部门经理。我们希望有一种秘密分享方案能实现: 至少 3 个员工参与,且其中必须有 1 个部门经理才能恢复出电子钥匙。 这个场景中,参与者其实是有等级之分的,部门经理的等级高于出纳员。这就是分层门限秘密共享(Hierarchical Threshold Secret Sharing)的应用场景。

本文主要讨论 Tassa 的论文 Hierarchical Threshold Secret Sharing

1.1. 形式化定义

关于 Hierarchical Threshold Secret Sharing 的形式化定义如图 1 所示。

tassa_htss_def.gif

Figure 1: Hierarchical Threshold Secret Sharing

下面通俗地介绍一下 Hierarchical Threshold Secret Sharing 的定义。 n 个参与者被分为了 0,1,,m 等级,共 m+1 个等级,数字越小等级越高,同一等级 i 的参与者记为集合 Ui ,所有 n 个参与者组成的集合记为 U

Hierarchical Threshold Secret Sharing 可用记号 ({k0,k1,k2,,km},n) 表示,其中 0<k0<k1,<km ,它表示要恢复出秘密值 S ,则至少需要 k00 等级的参与者, k10 等级或 1 等级(即小于等于 1 等级)的参与者, k20 等级或 1 等级或 2 等级(即小于等于 2 等级)的参与者, km 个小于等于 m 等级的参与者。在前面介绍的“银行金库电子钥匙”的例子中,假设部门中有 12 个人参与秘密分享,其中 8 个出纳员和 4 个部门经理。“至少 3 个员工参与,且其中必须有 1 个部门经理才能恢复出电子钥匙”的方案可以表示为 ({1,3},12) 。部门经理属于 0 等级,出纳员属于 1 等级, k0=1 表示恢复电子钥匙时至少有 1 个部门经理, k1=3 表示恢复电子钥匙时部门经理和出纳员不能小于 3 ,下面是所有可能恢复出电子钥匙的 3 人组合:

# 可能恢复出电子钥匙的 3 人组合:
“1 个部门经理 + 2 个出纳员” 或:
“2 个部门经理 + 1 个出纳员” 或:
“3 个部门经理 + 0 个出纳员”

Hierarchical Threshold Secret Sharing 有两个要求:

  1. Accessibility,表示对于符合门限方案的参与者组合,一定能恢复出秘密值;
  2. Perfect Security,表示对于不符合门限方案的参与者组合,不能恢复出秘密值。比如上面例子中, 3 个(或更多)出纳员不能恢复出秘密值。

2. 简单方案

记待分享的秘密为 S ,下面介绍一种简单的 Hierarchical Threshold Secret Sharing 方案,可以把这个秘密分享到 m+1 个等级的参与者中。

Dealer 按下面方法准备 m+1 个秘密。首先,Dealer 随机选择 m 个秘密 Si,1im ,然后定义 S0=Si=1mSi ,这样 Dealer 手头共有 m+1 个秘密了,其中后 m 个秘密是随机产生的,而首个秘密 S0 不是随机产生的,它由后 m 个秘密和待分享的秘密为 S 通过式子 S0=Si=1mSi 计算而来。注:并不一定要使用这个计算式子,只要由后 m 个秘密和待分享的秘密为 S 能唯一确定 S0 即可,比如使用 S0=SS1S2Sm 计算 S0 也行。

Si,0im 作为秘密值,通过 Shamir 门限秘密共享方案 (ki,j=0iUj) 分享给所有 j=0iUj 。这里有 m+1 个秘密值需要分享,所以要运行 m+1 次 Shamir 门限秘密共享方案。

重新恢复出秘密值 S 的过程:先重新恢复出 m+1 个秘密值 Si,0im ,然后通过这些值,利用 S=i=0mSi 计算出 S

2.1. 方案实例

我们以前面介绍的“银行金库电子钥匙”为例介绍上面的过程。Dealer 随机选择 S1 ,通过 S0=SS1 计算出 S0 。然后, Dealer 把 S0 作为秘密值,通过 (1,4) 方案分享给 4 个部门经理;把 S1 作为秘密值,通过 (3,12) 方案分享给 4 个部门经理和 8 个出纳员。

要重新恢复出 S 时,首先,需要至少 1 个部门经理(记为 M1 )恢复出 S0 ,然后在剩下的 3 个部门经理和 8 个出纳员中找 2 个人,和前面的部门经理 M1 一共是 3 个人恢复出 S1 ,最后,由 S=S0+S1 计算出秘密值 S 即可。

2.2. 方案缺点

这种方案有个缺点:等级越高(即等级数字越小)的参与者需要保存的秘密分片越多。 这种方案中,等级最高的参与者需要保存 m+1 个秘密分片,所以方案的 Information Rate 为 ρ=1/(m+1) 。比如前面例子中,每个部门经理(等级为 0 )需要保存两个秘密分片,一个秘密分片用于恢复 S0 ,另一个秘密分片用于恢复 S1

后文将介绍 ρ=1 的 Hierarchical Threshold Secret Sharing 方案,即每个参与者需要保存的秘密分片和待分享的秘密值 S 是同样大小的。

3. Tassa 方案

Tassa 给出了一个 Hierarchical Threshold Secret Sharing 方案,这种方案克服了节 2 中方案中的缺点:等级越高的参与者需要保存的秘密分片越多。Tassa 方案中, ρ=1 ,即每个参与者不管什么等级,他们需要保存的秘密分片和待分享秘密值 S 的大小相同。

下面介绍一下 Tassa 的方案(注:这个方案需要满足节 3.3 中介绍的条件时,才会符合分层门限秘密共享的两个要求,即 Accessibility 和 Perfect Security),如图 2 所示。

tassa_htss.gif

Figure 2: Tassa's Hierarchical Threshold Secret Sharing

假设一个分层门限方案中,所有参与者 U 被分为 3 个等级,即 U=U0U1U2 。阈值 (k0,k1,k2)=(2,4,7) ,也就是说至少 7 个参与者、且其中 U0U1 的参与者至少 4 个, U0 的参与者至少 2 个才能恢复出秘密值。这个例子中 k=k2=7 ,Dealer 随机选择一个 6 次( k1=6 )多项式, P(x)=i=06aixi ,这个多项式中 a0=S 是待分享的秘密值,而 a1,,a6 是 Dealer 随机产生。所有参与者都分配一个编号(比如共有 14 个参与者,可以分配编号为 1,2,,14 ,下面把参与者编号记为 u

  1. 对于 U0 中的参与者,我们把 P(k01)(u)=P(k1)(u)=P(u) 做为秘密分片分享给他(假设编号 1,2,3 的参与者属于等级 0 ,则等级 0 的这三个参与者得到的秘密分片为函数值 P(1),P(2),P(3) );
  2. 对于 U1 中的参与者,我们把 P(k11)(u)=P(k0)(u)=P(u) 做为秘密分片分享给他(假设编号为 4,5,6,7,8 的参与者属于等级 1 ,则等级 1 的这五个参与者得到的秘密分片为 2 阶导数值 P(4),P(5),P(6),P(7),P(8) );
  3. 对于 U2 中的参与者,我们把 P(k21)(u)=P(k1)(u)=P(4)(u) 做为秘密分片分享给他(假设编号为 9,10,11,12,13,14 的参与者属于等级 2 ,则等级 2 的这五个参与者得到的秘密分片为 4 阶导数值 P(4)(9),,P(4)(14) )。

3.1. 满足分层门限要求时能恢复秘密值(Accessibility)

上一节只介绍了秘密值的共享方案,但没有介绍如何恢复秘密值 S (即 a0 )。

满足分层门限要求(即至少 7 个参与者、且其中 U0U1 的参与者至少 4 个, U0 的参与者至少 2 个)的参与者组合有很多,比如:

# 情况一:
2 个等级 0 的参与者
2 个等级 1 的参与者
3 个等级 2 的参与者

# 情况二:
2 个等级 0 的参与者
3 个等级 1 的参与者
2 个等级 2 的参与者

对于情况一,这 7 个参与者要恢复秘密值 a0 ,下面介绍一下方法。设 P(x)=a0+a1x++a6x6 二次求导后,可得 P(x)=2a2+6a3x+12a4x2+20a5x3+30a6x4 再经过二次求导,可得 P(4)(x)=24a4+120a5x+360a6x2 已知 3 个等级为 2 的参与者的秘密分片,相当于已知 4 阶导函数 P(4)(x) 上的 3 个点,我们通过拉格朗日插值可以计算出 4 阶导函数 P(4)(x) (由于它是 2 次多项式, 3 个点恰好可唯一确定),从而知道 a4,a5,a6 ;把求得的 a4,a5,a6 代入到二次导函数 P(x) 中,那么 P(x) 中只有系数 a2,a3 是未知的了,由于我们还已知二次导函数上的两个点(即 2 个等级为 1 的参与者的秘密分片),代入两个点后可得两个方程,这样可以求得两个未知系数 a2,a3 了; P(x) 只剩下 a0,a1 未知了,使用类似的方法,代入 2 个等级为 0 的参与者的秘密分片(即 P(x) 中的两个点),可以求出 a0,a1 。从而,我们恢复出了秘密值 a0

对于情况二,我们也能采用类似的方法,即已知 7 个方程(代入每个秘密分片可得一方程),可求解出 7 个未知系数 a0,,a6

参与者的秘密分片相当于函数(或某阶导函数)上一个点,每代入一个点,可得一方程, k 个参与者可得 k 方程。这里有一个重要问题: 已知 k 个方程,不一定可确定 k 个未知数。 因为,方程之间可能线性相关,有效方程可能没有那么多。

其实,上面的问题就是 Birkhoff Interpolation 问题。简单来说 Birkhoff Interpolation 问题就是:已知 k 个函数值(或者某阶导函数值),求解一个次数小于 k 的多项式满足给定的点。显然 Birkhoff Interpolation 是拉格朗日插值的一个推广,关于 Birkhoff Interpolation 相关知识点可参考 https://aandds.com/blog/hermite-birkhoff-interpolation.html 。和拉格朗日插值有唯一解不同,对于 Birkhoff Interpolation 来说,它并不一定有唯一解,如果 a0 没有唯一解,显然无法满足分层门限方案的第一个要求(即 Accessibility)。

Tassa 证明了在一定条件(节 3.3 将介绍具体条件)下,节 3 中描述的方案一定具备 Accessibility 要求。

3.2. 不满足分层门限要求时不能恢复秘密值(Perfect Security)

下面是不满足分层门限要求的例子:

# 例子 1(不满足分层门限要求,因为没有等级 0 参与者):
0 个等级 0 的参与者
4 个等级 1 的参与者
3 个等级 2 的参与者

# 例子 2(不满足分层门限要求,因为等级 0 参与者太少,分层门限要求至少 2 个等级 0 参与者):
1 个等级 0 的参与者
3 个等级 1 的参与者
3 个等级 2 的参与者

为什么这些组合不能恢复出秘密值 a0 呢?对于例子 1 来说,比较好理解,因为对 P(x) 求导函数时, a0 作为常数项,不会出现在大于等于 1 阶的导函数中,联立方程组时,要把 a0 包含在某个方程中,则必须代入 P(x) 上的点(只有等级 0 的参与者才对应 P(x) 上的点,其它等级的参与者对应的是某阶导函数上的点)。在例子 1 中,根本没有等级 0 的参与者,所以不可能求解出 a0

上面说明了在例子 1 的情况下不能恢复出秘密值 a0 ,并不能说明其它不满足分层门限要求的组合不能恢复出秘密值。即无法说明它具备 Perfect Security 要求。

Tassa 证明了在一定条件(节 3.3 将介绍具体条件)下,节 3 中描述的方案一定具备 Perfect Security 要求。

3.3. 同时具备 Accessibility 和 Perfect Security 要求的条件

在什么条件下,节 3 中介绍的分层门限秘密共享才具备 Accessibility 和 Perfect Security 这两个要求呢?

Tassa 在论文的 3.3 节给出两种形式的条件。这两种形式都要求参与者的编号(即求参与者秘密分片时所使用的 x 值)满足 Monotonic Principle。

所谓 Monotonic Principle 就是: uUi,vUj,i<ju<v 也就是说 参与者等级数字越小,则计算他们秘密分片所采用的 x 值越小。 即计算 U0 中参与者秘密分片时所使用的 x 值,一定要小于计算 U1 中参与者秘密分片时所使用的 x 值;而计算 U1 中参与者秘密分片时所使用的 x 值,一定要小于计算 U2 中参与者分片时所使用的 x 值;依次类推。举例来说,假设 (k0,k1,k2)=(2,4,7) 方案中 U0 有三个成员,它们的秘密分片分别由 F(1),F(4),F(6) 计算而来,那么计算 U1 的成员的秘密分片时所采用的 x 值必须大于 6 ,可以采用 F(7),F(10) 等,但不能采用 F(2),F(4) 等。

N=maxU ,即 N 是参与者最大编号值。记 k=km ,即 k 是恢复秘密值的最少参与者个数。记 q 为计算所在有限域 F 的 Order。

条件 29(论文中相关公式编号为 29): 如果参与者的编号满足 Monotonic Principle,并且有 2k(k+1)(k+1)/2N(k1)k/2<q=|Fq| 那么节 3 中介绍的分层门限秘密共享一定满足 Accessibility 和 Perfect Security。

条件 35(论文中相关公式编号为 35): 如果参与者的编号满足 Monotonic Principle,并且有 2k+2(k1)(k1)/2(k1)!N(k1)(k2)/2<q=|Fq| 那么节 3 中介绍的分层门限秘密共享一定满足 Accessibility 和 Perfect Security。

假设我们用分层门限秘密共享方案来保存 128 位的 AES 密钥(即 q 为 128 比特位),那么条件 29 和条件 35 对 kN 的约束关系如表 1 所示。

Table 1: Values of k and N that satisfy conditions (29) and (35)
k Condition 29 Confition 35
5 N5497 N1234795
6 N296 N3637
7 N56 N200
8 N19 N38

k=3,4 时的情况可以参考原论文的附录,它们对 N 的限制更加宽松。

3.4. Tassa 实例

假设有 5 个参与者(A/B/C/D/E),其中两个参与者(A/B)等级为 0 ,另外三个参与者(C/D/E)等级为 1

下面介绍如何实现一个 ({1,3},5) 分层门限秘密共享方案,也就是说 5 个参与者中等级为 0 的参与者至少 1 个,等级为 01 的参与者至少 3 个才能恢复出秘密值。设待分享的秘密值为 S=4

第一步,Dealer 随机选择一个 2 次多项式(由于至少 3 个参与者才能恢复秘密值,所以是 31 次多项式) P(x)=a0+a1x+a2x2 其中 a0 就是待分享的秘密值 4 ,假设随机选择的 a1,a2 分别为 3,2 ,即 Dealer 确定的多项式为 P(x)=4+3x+2x2

第二步,Dealer 把 P(1)=9,P(2)=18 分别分发给等级 0 的两个参与者 A 和 B。Dealer 把 P(3)=15,P(4)=18,P(5)=23 分别分发给等级 1 的三个参与者 C/D/E。

这种分配方式符合节 3.3 中的条件,所以一定满足 Accessibility 和 Perfect Security。

假设现在 B 和 D 和 E 想恢复出秘密值 a0 ,他们如何操作呢?

利用 Birkhoff 插值公式(下面相关细节可参考 https://aandds.com/blog/hermite-birkhoff-interpolation.html ),有 f(x)=a0+a1x+a2x2=det(A(E,X,φ0))det(A(E,X,φ))+det(A(E,X,φ1))det(A(E,X,φ))x+det(A(E,X,φ2))det(A(E,X,φ))x2 所以 a0=det(A(E,X,φ0))det(A(E,X,φ)) 其中 A(E,X,φ) 和秘密分片本身无关 A(E,X,φ)=(1222012×4012×5)A(E,X,φ0) 是把 A(E,X,φ) 中第 1 列换为 3 个秘密分片而来,即 A(E,X,φ0)=(182221912×42312×5) 所以 a0=det(A(E,X,φ0))det(A(E,X,φ))=82=4

3.4.1. Additive Sharing

利用 Laplace Expansion (即求 A(E,X,φ0) 行列式时按第 1 列展开来计算),参与者 B/D/E 可独自(不依赖于其它参与者的秘密分片)算出秘密值 a0 的 Additive Sharing。然后,把 3 个 Additive Sharing 加起来也可以得到 a0 。论文 Dynamic and Verifiable Hierarchical Secret Sharing 的 5.1 节提到这点。

B 的 Additive Sharing 为 w1=1det(A(E,X,φ))(18(1)11+0det(12×412×5))=18

D 的 Additive Sharing 为 w2=1det(A(E,X,φ))(19(1)21+0det(22212×5))=152

E 的 Additive Sharing 为 w3=1det(A(E,X,φ))(23(1)31+0det(22212×4))=138

所以 a0=w1+w2+w3=18152+138=4

4. 参考

  1. Tassa 论文 Hierarchical Threshold Secret Sharing
  2. Dynamic and Verifiable Hierarchical Secret Sharing
  3. 利用分层门限秘密共享方案来实现分层门限签名方案 https://github.com/getamis/alice

Author: cig01

Created: <2023-05-03 Wed>

Last updated: <2023-05-06 Sat>

Creator: Emacs 27.1 (Org mode 9.4)