Validating a signature

[sirpy]

Hey @JonahGroendal Is it possible to also validate a signature by one of the certificates?

[JonahGroendal]

If I understand you correctly you want to verify a signature against a certificate in the tree, correct? If so it's not possible since the public key of the certificates isn't stored on-chain (would be too expensive). But if you have the certificate data, you could check that it's valid by looking for it in the tree then use another repo of mine called sig-verify-algs (which is a dependency of this repo) to verify a signature. Of course you would have to extract the public key from the certificate first but for that you could use another repo of mine called asn1-decode (also a dependency of this repo). The best example for how to use those contracts is by seeing how they're used in this contract, particularly the addCert function.

[rgex]

We are currently trying to asset the feasibility of implementing a proof-of-passport within a smart contract. To do so a chain of trust is established between a signature signed by a Document Signing Certificate that is itself signed by a Country Signing Certificate Authority.

Signature
 | Signed by
 V
Document Signing Certificate (x509)
 | Signed by
 V
Country Signing Certificate Authority (x509)

It seems that your smart contract currently only supports 'sha256WithRSAEncryption', what about other certificate types such as 'sha384WithRSAEncryption', 'RSA-PSS' or 'ecdsaWithSHA256' for example, would it be difficult to implement them?

Bonus: Just verifying the signature is not enough as such a transaction would be malleable (some one could intercept it and send it with his own address and claim it is his passport) so a non-transferability should be implemented. This could be done using a Non-transferable proof of Signature Knowledge as described here: https://github.com/UBIC-repo/Whitepaper#non-transferable-proof-of-signature-knowledge

What is your opinion on the complexity and feasibility of implementing this in solidity?

Kind regards,

Jan

[JonahGroendal]

I didn't actually write the signing algorithm, it's a modified version of an algorithm in the guthub repo ensdomains/dnssec-oracle. FYI they also have P256SHA256Algorithm and RSASHA1Algorithm, in case those are of any use to you guys.

As for sha384WithRSAEncryption, I've searched for a solidity implementation of sha384 before but wasn't able to find one so it may be difficult. A solution might be just to wait for eWASM to be implemented so you can use existing crypto libraries written in more built-out languages.

[sirpy]

@JonahGroendal thanks! i've read somewhere that sha384 is similar to sha512, i did see somewhere a solidity implementation of sha512, so it could probably be modified if in did they are similar

[JonahGroendal]

@sirpy I would definitely be interested in a sha384 library if you get one working. I've been wanting to add support for sha384WithRSAEncryption so I can validate email certificates issued by the popular CAs. That way I can create an OpenID oracle for authenticating Google, Facebook, Twitter, Twitch, etc. users.

Also, that UBIC project you linked looks pretty cool and using a proof-of-passport system to stop sylbil attacks is a great idea IMO.

Using a Non-transferable proof of Signature Knowledge may not be required tho to ensure non-transferability (as you described earlier). I encountered a similar problem when figuring out how an eth account holder can prove his ownership of a certificate in the tree without someone else being able to replay the same signature. My solution was to include the eth account's address in the challenge that's signed by the certificate. That way, if another account resubmits the signature, the verification fails because the sender's address doesn't match. So maybe you could incorporate the prover's eth account in the challenge text that's signed by the e-passport?

If so, you may actually be able to use this contract as-is to verify ownership of a passport (assuming all the signature algorithms you need get added). The function proveOwnership takes, as a parameter, a certificate's signature of [the sender's address + the current blockhash], then, if the signature is valid, sets the sender as the certificate's owner. This is then proof that the eth account owns the certificate.

[sirpy]

@JonahGroendal I saw there's already some kind of sha512 here: https://github.com/SmartPool/contracts/blob/develop/contracts/Ethash.sol to convert to sha384 see: https://crypto.stackexchange.com/a/75576

i dont think the passport can sign data, but @rgex should be able to explain more. he's the creator of UBIC btw Jonah can you join t.me/OpenUBI we can continue the discussion and maybe collaborate on an identity solution

[JonahGroendal]

Awesome just joined the chat