Re: Public Key Extraction in Implicit Certificates (ECQV)

Hi Manuel,
I think issues with the compressed point encoding is very unlikely.
Based on what you say, it's probably not a math issue either.

When you say "Certicom's Public Key Extraction algorithms" (CPKEA), what
specifically do you mean here? Is there a spec for it somewhere?

- Is this a hardware device, or some sort of testing library or what?
- Do you pass it the CA public key, or is it pre-configured? Does it
have a configured (alternate) CA public key for testing?
- Do you pass it your calculated hash and reconstruction data, or does
it work from the certificate itself?

There are a few points of failure I can see here (more than one might
apply!):

1. Domain parameters: you (via BC) are using the recommended basepoint
for sect163k1 (SEC 2, 3.2.1); do you know for sure that CPKEA hasn't
specified a different one?

2. CA public key mismatch (if it is pre-configured somehow, can you
print it out?).

3. Hash disagreement. If you pass it the hash, try passing 0 so that it
should just return you the CA public key. If it calculates its own hash:
have you configured the hash algorithm correctly, are you able to see
the hash outputs, have you tried other hash algorithms e.g. SHA-256?

Regards,
Pete Dettman

On 16/7/19 7:29 pm, biscas wrote:
> Hi All,
> 
> I am currently using BouncyCastle 1.61 to create an application to generate
> Implicit Certificates  (see
> https://en.wikipedia.org/wiki/Implicit_certificate) and sign messages as
> well as an application to extract the ECDSA Public Key, and verify the ECDSA
> signature.
> 
> The goal is to use the application to generate Implicit Certificates AND
> Signatures (it is a strange use case) so that devices in the field are able
> to verify the ECDSA signature. 
> The applications so far developed are working correctly against each other
> that is:
> 1. The Verifier Application is able to extract the ECDSA Public Key from an
> implicit certificate computed by the Signer Application.
> 2. The Verifier Application is then able to verify the ECDSA Signature.
> 
> Moreover:
> 3. the Verifier Application is able to extract ECDSA Public Keys and verify
> signatures from third-parties.
> 
> However the devices themselves when receiving an implicit certificate
> generated by the Signer Application are not able to extract the correct
> ECDSA Public Key. We are absolutely sure that this is not due to the Hash
> computations, as the implicit certificate hashes are correctly computed.
> Given 1. 2. and 3. we are also quite sure that from the algorithmic point of
> view the Verifier application is mathematically correct.
> In particular Public Key extraction is done in BouncyCastle 1.61, where
> CURVE = new SecT163K1Curve() by:
> 
> ECPoint certPublicKey = CURVE.decodePoint(publicReconstKey);
> 
> //CryptoClassUtils.matyasMeyersOseasHashing is the chosen hashing function
> that returns a 16 byte //array, so well within floor(Log_2(CURVE.getN())))
> byte[] hash = CryptoClassUtils.matyasMeyersOseasHashing(implicitCert));         
> BigInteger ECDSA_SIGNING_CERTIFICATE_HASH = new BigInteger(1,hash);
> 
> ECPoint ecdsaPublicKey = certPublicKey
>                 .multiply(ECDSA_SIGNING_CERTIFICATE_HASH)
>                 .add(CURVE.decodePoint(caPublicKey));
> 
> Now, given this I wonder whether there is some encoding/decoding regarding
> compressed points. For instance:
> 
> With:
> 
> implicitCert = {0x02, 0x03, 0x7f, 0xf5, 0x63, 0x64, 0x52, 0x15, 0x78, 0xf3,
> 0x09, 0xf4, 0x70, 0x39, 0x24, 0x1a, 0xa4, 0xf2, 0xac, 0x30, 0x72, 0x66,
> 0x00, 0x0f, 0x93, 0xff, 0xfd, 0x03, 0x06, 0x9e, 0x54, 0x45, 0x53, 0x54,
> 0x53, 0x45, 0x43, 0x41, 0x01, 0x09, 0x00, 0x00, 0x10, 0x63, 0x00, 0x00,
> 0x00, 0x00};
> 
> caPublicKey = {0x03, 0x00, 0x86, 0x0b, 0xda, 0x66, 0xb4, 0xf0, 0xb9, 0x2c,
> 0x7c, 0xac, 0x1c, 0xaa, 0xb5, 0x15, 0xac, 0x78, 0xda, 0x80, 0xa0, 0x89};
> 
> publicReconstrKey = {0x02, 0x03, 0x7f, 0xf5, 0x63, 0x64, 0x52, 0x15, 0x78,
> 0xf3, 0x09, 0xf4, 0x70, 0x39, 0x24, 0x1a, 0xa4, 0xf2, 0xac, 0x30, 0x72,
> 0x66};
> 
> hash = {0x4b, 0x1a, 0x9c, 0xb5, 0xfa, 0x64, 0x8a, 0x6a, 0x75, 0x20, 0xff,
> 0x19, 0x6c, 0x68, 0x08, 0x5d};
> 
> ECDSA_SIGNING_CERTIFICATE_HASH = 99830277875878979416225826737509369949;
> 
> The developed Verifier will output ECDSA Public Key:
> 
> ecdsaPublicKey = {0x02, 0x07, 0xb2, 0xcb, 0xfd, 0x35, 0xa2, 0x38, 0x01,
> 0xdc, 0x65, 0x3e, 0x54, 0x0d, 0x75, 0x89, 0x4e, 0xec, 0x23, 0x74, 0xa3,
> 0x1c}
> 
> Certicom's Public Key Extraction algorithms will output instead:
> 
> ecdsaPublicKeyByCerticom = {0x02,0x00,0x2F,0x4A,0x8C,0xE8,0xAB,
> 0xCA,0xAE,0x3A,0x56,0xAC, 0x5E, 0xD1, 0x54, 0xE9, 0x5E, 0xE8, 0x5D, 0xDF,
> 0x77, 0xE4};
> 
> This behaviour is completely deterministic. 
> 
> At this moment all I suspect is some kind of issue on encoding/decoding
> elliptic curve points on these curves against Certicom's implementation. Do
> you guys have any past experience integrating elliptic curve crypto against
> Certicom's libs, specially those used in ZigBee?
> 
> Kindly,
> 
> Manuel