Here we describe the cryptographic protocol that is implemented.
Preliminaries
TBD (Group etc.)
Generation of issue certificate
The input for this step are the 4 attributes that are certified, namely OU, Role, EnrollmentID and RevocationHandle (call them $a_{0}, \ldots, a_{3}$).
Given these attributes, the CA samples the issuer secret key at random
$ISK \gets_{\scriptscriptstyle\$} \mathbb{Z}_{r}$
And then computes
$W \leftarrow g_{2}^{ISK}$
For each attribute $a_{i} \in \{a_{0}, \ldots, a_{3}\}$ the CA picks a random element $r_{i} \gets_{\scriptscriptstyle\$} \mathbb{Z}_{r}$ and generates a base for that attribute
$H_{a_{i}} \leftarrow g_{1}^{r_{i}}$
The CA randomly selects $r_{ISK}, r, \bar{r}$ and computes bases
If $B \neq B'$ the user aborts. Otherwise it verifies the signature by checking whether the following equality
$e(g_{2}^E \cdot W, A) = e(g_{2}, B)$
holds. If so, the user accepts private key $SK_{C} \leftarrow \{ sk_{c} \}$ and the user public key is $PK_{C} \leftarrow \{ A, B, E, S \}$.
Generation of signature
To sign message $m$ and simultaneously disclose a subset of attributes $a_{c0}, \ldots, a_{c3}$ (tracked by the bits $d_{0}, \ldots, d_{3}$ such that if the bit is one the corresponding attribute is disclosed; notationally, $\bar{d}_{i} = d_{i} %2B 1 mod 2$), the client chooses a new random element $r_{n} \gets_{\scriptscriptstyle\$} \mathbb{Z}_{r}$ and generates a new pseudonym
and for each attribute $a_{i}$ that requires disclosure, it generates
$S_{a_{i}} \leftarrow r_{a_{i}} %2B a_{i} C$
The signature $\sigma$ is $\sigma \leftarrow \{ Nym, A', \bar{A}, B', C, S_{sk_{c}}, S_{E}, S_{r_2}, S_{r_3}, S_{S'}, S_{r_{n}}, \ldots S_{a_{i}} \ldots, d_{0}, \ldots, d_{3}, \ldots a_{i} \ldots, n \}$.
Verification of a signature
Upon receipt of a signature $\sigma$ is $\sigma \leftarrow \{ Nym, A', \bar{A}, B', C, S_{sk_{c}}, S_{E}, S_{r_2}, S_{r_3}, S_{S'}, S_{r_{n}}, \ldots S_{a_{i}} \ldots, d_{0}, \ldots, d_{3}, \ldots a_{i} \ldots, n \}$ over message $m$ the verifier checks whether the following equality holds
This verification also verifies the disclosed subset of attributes.
Generation of a pseudonymous signature
Differently from a standard signature, a pseudonymous signature does not prove that the pseudonym possesses a user certificate signed by a CA. It only proves that the pseudonym $Nym$ signed message $m$. The signature is generated starting from the pseudonym (as generated in the section above) together with secret key $sk_{c}$ and randomness $r_{n}$ as follows: at first it picks random elements
Adding a pseudonym as a function of the Enrollment ID (eid)
The enrollment id is one of the cerified attributes ($a_{2}$ with value $a_{c2}$). This extension introduces a pseudonym which is a function of the enrollment ID, together with a proof that it was correclty generated.
Signature generation is similar to the scheme above; in particular, the term $r_{a_{2}}$ is the same used by the original sign algorithm. The extensions include:
the client computes an additional value $t_4 \leftarrow H_{a_{2}}^{r_{a_{2}}} \cdot H_{r}^{r_{r_{eid}}}$;
the client includes $(Nym_{eid}, t_4)$ in the challenge computation: $C \leftarrow H(H(t_1||t_2||t_3||t_4||A'||\bar{A}||B'||Nym||Nym_{eid}||h_{CA}||d_0||\ldots||d_3||m)||n)$ (if $d_2$ is included, it should always be set to 0 otherwise the value of the enrollment ID would be revealed);
the client computes an additional proof $S_{r_{eid}} \leftarrow r_{r_{eid}} %2B r_{eid} C$;
The signature includes the additional proof $S_{r_{eid}}$ and pseudonym $Nym_{eid}$.
Signature verification
Signature verification is the same as above except that
We do a lot of big fingers some time and unfortunately many time from these big fingers on configuration we have panic on fsc node which doesn't help to find source of errors.
In that perspective, a configuration validator would help a lot.
Currently, idemixgen uses math.FP256BN_AMCL as backend for Curve's computation. This should be customizable with an additional parameter -curve that can assume values:
Currently, we can generate an Idemix signature attaching a commitment to the enrolment ID (EID) with a proof that it is the same of that in the signature. This can be enabled by setting the SignatureType to EidNym.
This issue asks to add a new SignatureType that attaches both a commitment to EID and to Revocation Handle (RH).
Currently, an idemix signature leaks the organisation the credential's owner belongs to.
In many situations this is not desirable.
The MSP code to validate an Idemix Identity should be able to validate Idemix identity with hidden organizations.
In more details, the function verfiyProof (