Crate ecdsa_proof

This is a simple implementation of the work done by Ubique using ZKattest to prove that an ECDSA signature can be verified using a commitment on a public key stored in a BBS credential.

The test at the end shows how to set up a system and check that the verification is correct. For a longer explanation, see our Github Repo with Jupyter notebooks and more information.

WARNING: This is a work of a couple of days for a hands-on workshop. While the general gist of how keys are generated, signatures created and verified, ZKP written and verified is correct, I’m sure that there are:

• errors in this re-arrangement of @Lovesh’s excellent work from docknetwork/crypt
• not optimal and not secure ways of treating private keys and other random secrets
• commitment - BBS proof: nonce and context are static - it could directly integrate the revealed values in the proof.

So while this work has been done to the best of my knowledge, I definietly took a lot of shortcuts and definitely valued simplicity for a hands-on-workshop over cryptographic correctness.

May Rogaway, Chaum and Goldwasser have mercy on me :)

Modules

ecdsa

Structs

BBSPresentation

A BBSPresentation is a proof of knowledge of the VerifiedCredential. It contains a proof that the presentation has been signed by the Issuer, and can be verified by the certificate of the Issuer.

ECDSAProof

An ECDSAProof links the ECDSA signature from the SecureElement to the BBSPresentation::close messages in zero-knowledge. The commitments are randomized representations of the holder’s public key. The proofs link these commitments to the message to be signed, and between each other.

Issuer

The Issuer represents here the government issuer in Swiyu, which can create new credentials for the Holder (MobilePhones). Each new credential is bound to the public key sent by the holder. An Issuer has a private key to sign credentials for the holders. The certificate of the issuer, the public key, can be used by the Verifier to check that a certificate has been created by the Issuer

MobilePhone

The MobilePhone represents a holder. It has:

PublicSetup

Globally known public values. These values can be created by anyone and are needed by all actors.

SEKeypair

A SecureElement keypair, with the private key stored in the SecureElement only, and only accessible via its id.

SecureElement

The SecureElement is a specially hardened part of the MobilePhone which can create keypairs. However, the private key is inaccessible to the applications. An application can only request a signature from one of the private keys, but not access it directly. While this makes it much more secure, it makes it also much more difficult to create useful cryptographic algorithms.

Swiyu

A simple representation of the Swiyu app. It needs to be set up correctly by the user, which of course usually is done automatically. But for our example we want to see how the public key gets transferred from the SecureElement to the Swiyu app. In the same way you’ll have to add the VerifiedCredential manually.

VerifiedCredential

A VerifiedCredential is created by the Issuer and holds the public key of the MobilePhone in a secure way. We suppose that the first two positions are the x and y value of the holder’s public key.

Verifier

A Verifier in this demo only has to create random messages, and then verify that the ECDSAProof is correct.

VerifierMessage

The VerifierMessage is used both for the signature from the SecureElement and in the BBSPresentation. This is a very simple implementation allowing to create scalars for SecP256 and Bls12-381.

Enums

PublicCommitment

Use an enum to show that the commitments can be open, including the random value, or closed, which is secure.