diff options
Diffstat (limited to 'design-documents/024-age-restriction.rst')
| -rw-r--r-- | design-documents/024-age-restriction.rst | 240 |
1 files changed, 196 insertions, 44 deletions
diff --git a/design-documents/024-age-restriction.rst b/design-documents/024-age-restriction.rst index 6b1004fc..0445aa6d 100644 --- a/design-documents/024-age-restriction.rst +++ b/design-documents/024-age-restriction.rst @@ -1,5 +1,5 @@ -DD24: Anonymous Age Restriction Extension for GNU Taler -####################################################### +DD 24: Anonymous Age Restriction Extension +########################################## Summary ======= @@ -29,8 +29,6 @@ optional feature that can be switched on by the exchange operator. Requirements ============ -TODO - * legal requirements for merchants must allow for this kind of mechanism @@ -55,7 +53,9 @@ protocol, that gives the minor/ward a 1/κ chance to raise the minimum age for the new coin). The proposed solution maintains the guarantees of GNU Taler with respect to -anonymity and unlinkability. (TODO: refer to the paper, once published) +anonymity and unlinkability. We have published a paper +`Zero Knowledge Age Restriction for GNU Taler <https://link.springer.com/chapter/10.1007/978-3-031-17140-6_6>`_ +with the details. ¹) Once the feature is enabled and the age groups are defined, the exchange has to stick to that decision until the support for age restriction is disabled. @@ -65,31 +65,32 @@ We might reconsider this design decision at some point. Main ideas and building blocks ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The main ideas are simple: +The main ideas are as follows: #. The exchange defines and publishes M+1 different *age groups* of increasing order: :math:`0 < a_1 < \ldots < a_M` with :math:`a_i \in \mathbb{N}`. The zeroth age group is :math:`\{0,\ldots,a_1-1\}`. -#. An **unrestricted** *age commitment* is defined as a vector of length M of +#. An **unrestricted age commitment** is defined as a vector of length M of pairs of Edx25519_ public and private keys on Curve25519. In other words: one - key pair for each age group after the zeroth: - :math:`\bigl\langle (p_1, s_1), \ldots, (p_M, s_M) \bigr\rangle` + key pair for each age group after the zeroth: :math:`\bigl\langle (q_1, + p_1), \ldots, (q_M, p_M) \bigr\rangle`. Here, :math:`q_i` are the public keys + (mnemonic: **q-mitments**), :math:`p_i` are the private keys. -#. A **restricted** *age commitment* **to age group m** (or m-th age group) is - derived from an unrestricted age commitment by removing all private keys for - indices larger than m: :math:`\bigl\langle (p_1, s_1), \ldots, (p_m, s_m), - \, (p_{m+1}, \perp), \ldots, (p_M, \perp )\bigr\rangle`. - F.e. if *none* of the private keys is provided, the age commitment would be - restricted to the zeroth age group. +#. A **restricted age commitment** *to age group m* is derived from an + unrestricted age commitment by removing all private keys for + indices larger than m: :math:`\bigl\langle (q_1, p_1), \ldots, (q_m, p_m), + \, (q_{m+1}, \perp), \ldots, (q_M, \perp )\bigr\rangle`. F.e. if *none* of + the private keys is provided, the age commitment would be restricted to the + zeroth age group. #. The act of restricting an unrestricted age commitment is performed by the parent/ward. #. An *age commitment* (without prefix) is just the vector of public keys: - :math:`\vec{Q} := \langle p_1, \ldots, p_M \rangle`. Note that from - just the age commitment one can not deduce if it was originated from an - unrestricted or restricted age commitment (and what age). + :math:`\vec{Q} := \langle q_1, \ldots, q_M \rangle`. Note that from + just the age commitment one can not deduce if it originated from an + unrestricted or restricted one (and what age). #. An *attestation of age group k* is essentially the signature to any message with the private key for slot k, if the corresponding private key is @@ -100,8 +101,13 @@ The main ideas are simple: SHA256 hash value of the age commitment (i.e. the M public keys) into the signature of the coin. So instead of signing :math:`\text{FDH}_N(C_p)` with the RSA private key of a denomination with support for age restriction, we - sign :math:`\text{FDH}_N(C_p, h_a)`. Here, :math:`C_p` is the EdDSA public - key of a coin and :math:`h_a` is the hash of the age commitment. + sign :math:`\text{FDH}_N(C_p, h_Q)`. Here, :math:`C_p` is the EdDSA public + key of a coin and :math:`h_Q` is the hash of the age commitment :math:`\vec{Q}`. + **Note:** A coin with age restriction can only be validated when both, the + public key of the coin itself **and** the hash of the age commitment, are + present. This needs to be supported in each subsystem: Exchange, Wallet and + Merchant. + TODO: Summarize the design based on the five functions ``Commit()``, ``Attest()``, ``Verify()``, ``Derive()``, ``Compare()``, once the paper from @@ -151,7 +157,7 @@ registering the extension ``age_restriction`` with a value type interface ConfigAgeRestriction { // The age groups. This field is mandatory and binding in the sense // that its value is taken into consideration when signing the - // denominations in `ExchangeKeysResponse`.``age_restricted_denoms``. + // age restricted denominations in the `ExchangeKeysResponse` age_groups: AgeGroups; } @@ -193,12 +199,11 @@ in ``ExchangeKeysResponse.age_restricted_denoms``. Age restricted denominations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -If age-restriction is registered as an extension under the name -``age_restriction``, as described above, the root-object -``ExchangeKeysResponse`` in response to ``/keys`` MUST be extended by an -additional field ``age_restricted_denoms``. This is an *additional* list of -denominations that must be used during the modified ``refresh`` and ``deposit`` -operations (see below). +If age-restriction is registered as extension ``age_restriction``, as described +above, the root-object ``ExchangeKeysResponse`` in response to ``/keys`` MUST +be extended by an additional field ``age_restricted_denoms``. This is an +*additional* list of denominations that must be used during the modified +``refresh`` and ``deposit`` operations (see below). The data structure for those denominations is the same as for the regular ones in ``ExchangeKeysResponse.denoms``. **However**, the following differences @@ -242,13 +247,13 @@ changed since the given timestamp. // Similar as for ``.denoms``, if the query parameter ``last_issue_date`` // was provided by the client, the exchange will only return the keys that // have changed since the given timestamp. - age_restricted_denoms: Denom[]; + age_restricted_denoms: DenomCommon[]; //... } -SQL changes +SQL schema ----------- The exchange has to mark denominations with support for age restriction as such @@ -286,9 +291,165 @@ NULL, but only iff the corresponding denomination (indirectly referenced via table ``known_coins``) has ``.age_restricted`` set to true. This constraint can not be expressed reliably with SQL. + Protocol changes ---------------- +Withdraw +~~~~~~~~ + +The withdraw protocol is affected in the following situations: + +- A wire transfer to the exchange (to fill a reserve) was marked by the + originating bank as coming from a bank account of a minor, belonging to a of + a specific age group, or by other means. +- A KYC-process has been performed with the owner of a reserve and the user has + been identified as being a minor. +- A Peer-to-Peer transaction was performed between customers. The receiving + customer's KYC result tells the exchange that the customer belongs to a + specific age group. + +In these cases, the wallet will have to perform a zero-knowledge protocol with +exchange as part of the the withdraw protocol, which we sketch here. Let + +- :math:`\kappa` be the same cut-and-choose parameter for the refresh-protocol. +- :math:`\Omega \in E` be a published, nothing-up-my-sleeve, constant + group-element on the elliptic curve. +- :math:`a \in \{1,\ldots,M\}` be the maximum age (group) for which the wallet + has to prove its commitment. + +The values :math:`\kappa`, :math:`\Omega` and :math:`a` are known to the +Exchange and the Wallet. Then, Wallet and Exchange run the following protocol +for the withdrawal of one coin: + +- *Wallet* + 1. creates planchets :math:`C_i` for :math:`i \in \{1,\ldots,\kappa\}` as candidates for *one* coin. + #. creates age-commitments :math:`\vec{Q}^i` for :math:`i \in \{1,\ldots,\kappa\}` as follows: + + a) creates :math:`a`-many Edx25519-keypairs :math:`(p^i_j, q^i_j)` + randomly for :math:`j \in \{1,\ldots,a\}` (with public keys :math:`q^i_j`), + #) chooses randomly :math:`(M - a)`-many scalars :math:`s^i_j` for :math:`j \in \{a+1,\ldots,M\}`, + #) calculates :math:`\omega^i_j = s^i_j*\Omega` for :math:`j \in \{a+1,\ldots,M \}`, + #) sets :math:`\vec{Q}^i := (q^i_1,\ldots,q^i_a,\omega^i_{a+1},\ldots,\omega^i_M)` + + #. calculates :math:`f_i := \text{FDH}(C_i, H(\vec{Q}^i))` for :math:`i \in \{ 1,\ldots,\kappa \}`. + #. chooses random blindings :math:`\beta_i(.)` for :math:`i \in \{1,\ldots,\kappa\}`. The blinding functions depend on the cipher (RSA, CS). + #. sends :math:`(\beta_1(f_1),\ldots,\beta_\kappa(f_\kappa))` to the Exchange + +- *Exchange* + 7. receives :math:`(b_1,\ldots,b_\kappa)` + #. calculates :math:`F := \text{H}(b_1||\ldots||b_\kappa)` + #. chooses randomly :math:`\gamma \in \{1,\ldots,\kappa\}` and + #. signs :math:`r := b_\gamma` resulting in signature :math:`\sigma_r` + #. stores :math:`F \mapsto (r, \sigma_r)` + #. sends :math:`\gamma` to the Wallet. + +- *Wallet* + 10. receives :math:`\gamma` + #. sends to the Exchange the tuple :math:`\left(F, \vec{\beta}, \vec{\vec{Q}}, \vec{\vec{S}}\right)` with + + - :math:`F := \text{H}(\beta_1(f_1)||\ldots||\beta_\kappa(f_\kappa))` + - :math:`\vec{\beta} := (\beta_1,\ldots,\beta_{\gamma-1},\bot,\beta_{\gamma+1},\ldots,\beta_\kappa)` + - :math:`\vec{\vec{Q}} := (\vec{Q}^1,\ldots,\vec{Q}^{\gamma-1},\bot,\vec{Q}^{\gamma+1},\ldots,\vec{Q}^\kappa)` + - :math:`\vec{\vec{S}} := (\vec{S}^1,\ldots,\vec{S}^{\gamma-1},\bot,\vec{S}^{\gamma+1},\ldots,\vec{S}^\kappa)` + with :math:`\vec{S}^i := (s^i_j)` + +- *Exchange* + 12. receives :math:`\left(F, (\beta_i), (\vec{Q}^i), (\vec{B}^i) \right)` + #. retrieves :math:`(r, \sigma_r)` from :math:`F` or bails out if not present + #. calculates :math:`b_i := \beta_i\left(\text{FDH}(\vec{Q}^i)\right)` for :math:`i \neq \gamma` + #. compares :math:`F \overset{?}{=} \text{H}(b_1||\ldots||b_{\gamma - 1}||r||b_{\gamma+1}||\ldots||b_\kappa)` and bails out on inequality + #. for each :math:`\vec{B}^i, i \neq \gamma` + + i. calculates :math:`\tilde{\omega}^i_j := b^i_j * \Omega` for :math:`j \in \{a+1,\ldots,M\}` + #. compares each :math:`\tilde{\omega}^i_j` to :math:`q^i_j` from :math:`\vec{Q}^i = (q^i_1, \ldots, q^i_M)` and bails out on inequality + #. sends (blinded) signature :math:`\sigma_r` to Wallet + +- *Wallet* + 18. receives :math:`\sigma_r` + #. calculates (unblinded) signature :math:`\sigma_\gamma := \beta^{-1}_\gamma(\sigma_r)` for coin :math:`C_\gamma`. + + +Note that the batch version of withdraw allows the withdrawal of *multiple* +coins at once. For that scenario the protocol sketched above is adapted to +accomodate for handling multiple coins at once -- thus multiplying the amount +of data by the amount of coins in question--, but all with the same value of +:math:`\gamma`. + +The *actual* implementation of the protocol above will have major optimizations +to keep the bandwidth usage to a minimum and also ensure that a denomination in +the commitment doesn't expire before the reveal. + +Instead of generating and sending the age commitment (array of public keys) and +blindings for each coin, the wallet *MUST* derive the corresponding blindings +and the age commitments from the coin's private key itself as follows: + +Let + +- :math:`s` be the master secret of the coin, from which the private key :math:`c_s`, blinding :math:`\beta` and nonce :math:`n` are derived as usual in the wallet core +- :math:`m \in \{1,\ldots,M\}` be the maximum age (according to the reserve) + that a wallet can commit to during the withdrawal. +- :math:`P` be a published constant Edx25519-public-key to which the private + key is not known to any client. + +For the age commitment, calculate: + +1. For age group :math:`a \in \{1,\ldots,m\}`, set + +.. math:: + s_a &:= \text{HDKF}(s, \text{"age-commitment"}, a) \\ + p_a &:= \text{Edx25519\_generate\_private}(s_a) \\ + q_a &:= \text{Edx25519\_public\_from\_private}(p_a) + +2. For age group :math:`a \in \{m,\ldots,M\}`, set + +.. math:: + f_a &:= \text{HDKF}(s, \text{"age-factor"}, a) \\ + q_a &:= \text{Edx25519\_derive\_public}(P, f_a). + +Then the vector :math:`\vec{q} = \{q_1,\ldots,q_M\}` is then the age commitment +associated to the coin's private key :math:`c_s`. For the non-disclosed coins, +the wallet can use the vector :math:`(p_1,\ldots,p_m,\bot,\ldots,\bot)` of +private keys for the attestation. + +Provided with the secret :math:`s`, the exchange can therefore calculate the +private key :math:`c_s`, the blinding :math:`\beta`, the nonce :math:`n` (if +needed) and the age commitment :math:`\vec{q}`, along with the coin's public +key :math:`C_p` and use the value of + +.. math:: + + \text{TALER\_CoinPubHashP}(C_p, \text{age\_commitment\_hash}(\vec{q})) + +during the verification of the original age-withdraw-commitment. + +For the withdrawal with age restriction, a sketch of the corresponding database +schema in the exchange is given here: + +.. graphviz:: + + digraph deposit_policies { + rankdir = LR; + splines = true; + fontname="monospace" + node [ + fontname="monospace" + shape=record + ] + + subgraph cluster_commitments { + label=<<B>age_withdraw</B>> + margin=20 + commitments [ + label="age_withdraw_id\l|<hc>h_commitment\l|amount_with_fee_val\l|amount_with_fee_frac\l|noreveal_index\l|max_age\l|<res>reserve_pub\l|reserve_sig\l|<denom>[n] denominations_serials\l|[n] h_blind_evs\l|[n] denom_sigs\l" + ] + } + + commitments:res->reserves:id [ label="n:1"; fontname="monospace"]; + commitments:denom -> denominations:id [ label="n:1"; fontname="monospace"] ; + } + + Refresh - melting phase ~~~~~~~~~~~~~~~~~~~~~~~ @@ -439,9 +600,9 @@ The object ``ContractTerms`` is extended by an optional field ``minimum_age`` that can be any integer greater than 0. In reality this value will not be smaller than, say, 8, and not larger than, say, 21. -.. ts:def:: ContractTerms +.. ts:def:: DD24ContractTerms - interface ContractTerms { + interface DD24ContractTerms { ... // If the order requires a minimum age greater than 0, this field is set @@ -528,19 +689,14 @@ satisfy any minimum age requirement. Changes in the Wallet ^^^^^^^^^^^^^^^^^^^^^ -TODO. - -* choosing age-restriction during withdrawal coins from denominations with - support for age restriction. -* Define protocol to pass denominations to child/ward. - +A wallet implementation SHOULD support denominations with age restriction. In +that case it SHOULD allow to select an age group as upper bound during +withdraw. Alternatives ============ -TODO. - * ID-based systems * credit/debit card based systems @@ -548,10 +704,7 @@ TODO. Drawbacks ========= -TODO. - * age groups, once defined, are set permanently -* age restricted coins are basically shared between ward and warden. Also discuss: @@ -571,9 +724,8 @@ We had some very engaged discussions on the GNU Taler `mailing list <taler@gnu.o * `Age-restriction is about coins, not currencies <https://lists.gnu.org/archive/html/taler/2021-09/msg00021.html>`__ +* The published paper: `Zero Knowledge Age Restriction for GNU Taler <https://link.springer.com/chapter/10.1007/978-3-031-17140-6_6>`_ -The upcoming paper on anonymous age-restriction for GNU Taler from Özgür Kesim -and Christian Grothoff will be cited here, once it is published. .. _Edx25519: |