ECC partially blind signature scheme verification

Question

Continued from Is there a flaw in this ECC blind signature scheme?

The problem

I needed a partially blind signature scheme for one of my projects, but couldn't find one on the internet, so I've made one (I think).

Is there anyone who can verify my results

Actors

• Alice (signer, i.e. bank)
• Bob (requester, i.e. payer)
• Bill (Verifier, i.e payee)

All actors agree on elliptic curve parameters:

Curve: y^2 = x^3 + a*x + b mod p
Base point: P
Order of base point: n

Alice generates his private key by choosing random value x in [1, n-1] range, then she computes and publishes Q = x*P

The algorithm

Alice holds record for Bob's and Bill's account balances, Bob want's to make a payment to Bill. For that purpose:

1. Bob generates a token message M = "This is 5 dollar Serial No. 111222333"
2. Bob generates public info message Z = "Nominal: 5, Currency: USD, Expiry date: 2018-01-01 12:00:00Z",
3. Bob hashes his token message which results with m = hash(M)
4. Bob hashes his public info message z = hash(Z)
5. Bob generates random blinding factor v = random()
6. Bob blinds his token message u = (m - v) mod n
7. Bob sends (u, Z) to Alice
8. Alice by looking into Z = "Nominal: 5, Currency: USD, Expiry date: 2018-01-01 12:00:00Z" sees that Bob want to charge 5 USD from his account
9. Alice charges 5 USD from Bob's account and blindly signs u by generating pair (s', R')
   1. For that purpose Alice generates random value r = random() that will be used for protecting her private key x
   2. Then Alice computes s' = (x - r + u + hash(Z)) mod n = (x - r + u + z) mod n
   3. And R' = r * P
10. Alice sends the resulting (s', R') pair to Bob
11. By receiving (s', R') Bob unblinds the message into (s, R), this is done according to following steps:
    1. Bob generates random unblinding factor w = random()
    2. Bob then computes s = (s' + w - m) mod n
    3. Bob then computes R = R' + (m - w - v)*P
12. Bob then pays for services from Bill by sending him tuple (s, R, Z, M)

13. By receiving Bob's tuple (s, R, Z, M) Bill validates:

    1. Token message M = "This is 5 dollar Serial No. 111222333"
    2. Public info Z = "Nominal: 5, Currency: USD, Expiry date: 2018-01-01 12:00:00Z"
    3. The signature (s, R) by checking equation s*P - Q + R = z*P + m*P:
    4. Since s = s' + w - m then s is also equal to x - r + v + z + w
    5. Since R = R' + (m - w - v)P then R is also equal to r*P + (m - w - v)*P which in turn is equal to r*P + m*P - w*P - v*P

    6. Then the initial equation s*P - Q + R = z*P + m*P yields to:

       (x - r + v + z + w)*P - Q + (r*P + m*P - w*P - v*P) = z*P + m*P

       which in turn yields to:

       x*P - r*P + v*P + z*P + w*P - Q + r*P + m*P - w*P - v*P = z*P + m*P

       by applying simplification we get that:

       z*P + m*P = z*P + m*P

14. After performing validation checks Bill asks Alice to add 5 USD to his account by sending her the tuple he received from Bob (s, R, Z, M)

15. When Alice receives (s, R, Z, M)

    1. She validates Z = "Nominal: 5, Currency: USD, Expiry date: 2018-01-01 12:00:00Z"
    2. She validates M = "This is 5 dollar Serial No. 111222333"
    3. She adds (111222333, 2018-01-01 12:00:00Z) to her database of expired tokens
    4. The token will be deleted after 2018-01-01 12:00:00Z preventing the database to grow indefinitely

Alice is able to verify her own signature (s, R, Z, M) by repeating steps made by Bill though she is not able to track who made a payment to Bill. It's true because even if Alice has recorded the s' component in her database during signature phase, she will not be able to match it because during repayment phase she will receive (s, R) instead of (s', R') and so by subtracting recorded s' from s she will get:

s - s' = ((x - r + v + z + w) - (x - r + v + m + z) + m + z) mod n =
       = (x - r + v + z + w - x + r - v - m - z + m + z) mod n = 
       = w mod n

and there's no way for Alice to discover w

Here is another example with real numbers: https://dl.dropboxusercontent.com/u/51743054/PartiallyBlindSignatureExample.pdf

P.S. The scheme provided in the following paper seem like has a flaw in it (during signature phase, a signer may embed requesters identity data into h(z) which may be recovered during verification phase and so requester's identity may be disclosed by the verifier, if signer and verifier share common database):

http://ijns.femto.com.tw/contents/ijns-v14-n6/ijns-2012-v14-n6-p316-319.pdf

I've taken that paper as a base work and fixed (I think) the problems that were in it, now it shouldn't leek requester anonymity.

Answer 1

Designing such signature schemes from scratch without having strong experience is very likely to fail and very dangerous (see the tons of bad papers out there being accepted to "dubious" conferences and journals).

Your proposed scheme

Your verification relation is to check if: $sP - Q + R \stackrel{?}{=} zP + mP$ where $Q$ is the public key of the signer and lets call $hash$ simply $h$.

I just took a quick look and you have the following problem (observe that you can freely choose $s$ and $R$):

Set $R:=Q$, choose any $M$ and $Z$ of your choice, then set $s:= h(Z)+h(M) \bmod n$ and the verification relation holds. Thus, you can forge a signature for arbitrary $M$ and $Z$ of your choice.

Ok, now you could say: "Lets introduce a check if $Q=R$ and whether $s$ is not of the form $h(Z)+h(M) \bmod n$ to avoid this problem".

But you can arbitrarily "blind" $s$ and $R$ set $R=Q-aP$ for an arbitrary $a\in \mathbb{Z_n}$ and then set $s:= h(Z)+h(M)+a \bmod n$. Note that your verification relation requires that:

$$sP - Q + R = zP + mP$$

Now lets plug in

$$(h(Z)+h(M)+a)P - Q + (Q-aP) = h(Z)P+h(M)P=mP+zP$$

which is a valid forgery and also totally breaks your scheme. Now you may introduce an additional check that $s$ and $R$ are not blinded that way. But I am quite sure (since I just took a quick look) that you will find more issues (this is still a key only attack and to achieve unforgeability we speak of security against chosen message attacks).

I just want to give you the advice that designing signature schemes (irrespecitve whether they are standard signature schemes, or blind or partially blind or what else) is an art and in your situation (for a project) I think its the best advice to simply rely on established schemes (see at the bottom of the answer). If you still want to desgin signature schemes study the required security properties at first and then think about how you could meet them (and you should also provide a proof that these properties hold).

The approach in your linked paper

The authors of the paper you have linked to seem to have no idea how the accepted security model for blind signatures and in particular the blindness property is defined.

Basically blindness requires that a malicious signer who is allowed to specify two messages $(M_0,M_1)$ and executing the signing process for both messages with a honest receiver is not able to decide in which order the signing processes have been executed.

Now, in your linked paper, the signer can trivially do so for the two messages: Namely, if the signer receives a candidate "blinded message" $m_bQ$ (where $b$ is either 0 or 1, he does not know, and $m_b=H(M_b)$), then the signer simply checks if $H(M_0)Q$ equals the received $m_bQ$. If this is the case he signs $M_0$ in this process and $M_1$ otherwise. Consequently, the scheme is not providing the blindness property.

Actually, they seem to more likely want to build a partially blind signature scheme, but the scheme will also not satisfy partial blindness (for the same reason as above).

I did not even look at the unforgeability (non-forgeability as they call it) of the scheme as the above is sufficient to throw away the paper. But as their models seem very handcrafted and the "proofs" are not convincing, I guess it can be broken w.r.t. this property as well.

Existing partially blind signature schemes

A well accepted and quite standard approach to partially blind signatures is the one in this paper by Abe and Okamoto (and this can also be implemented on elliptic curves). This one (more of theoretical interest) and this one are also provably secure (in the standard model in contrast to the first) but rely on pairing friendly elliptic curves. So maybe the easiest one to implement is the first one.