Error given while testing GP generated with allegedly "leaked" keys

[stefanoco]

During the last few hours news are spreading about allegedly leaked signing keys from one EU coutry. Newspapers are publishing "false" QR codes that national check apps are verifying as "correct".

In order to investigate the topic I'm using greenpass.py and I get this error, any idea on what's wrong?

Traceback (most recent call last):
  File "/home/stefanoco/.local/bin/greenpass", line 114, in <module>
    res = logic.verify_certificate(out, gpp, sm, cup)
  File "/home/stefanoco/.local/lib/python3.9/site-packages/greenpass/logic.py", line 265, in verify_certificate
    output.add_cert_info_info(cert_info[0], Manufacturer(cert_info[1]).get_pretty_name())
  File "/home/stefanoco/.local/lib/python3.9/site-packages/greenpass/data.py", line 180, in __init__
    self.pretty_name.update(self.get_tests_pn())
  File "/home/stefanoco/.local/lib/python3.9/site-packages/greenpass/data.py", line 191, in get_tests_pn
    o[el["id_device"]] = el["commercial_name"]
TypeError: string indices must be integers

[berdav]

Hi.

I'm currently looking at the same issue, can you privately send to me the certificate in question or the public links?

I don't want to spread fake certificates in this repository but I can investigate better the problem with these files. :)

For this specific certificate, it seems that the commercial name has a strange format.

You can find my email in my github profile.

[stefanoco]

Yes for sure the certificate has incomplete and strange fields but nonetheless seems to be correctly recognized by the official apps. I'd like to go further into investigation so I'm sending you what I have, by email.

[berdav]

The master branch diverged from yesterday, can you confirm if this issue is still present in the last commit?

[stefanoco]

Seems to be working now, with another error that (might) be related to the certificates revocation in place since yesterday:

$ ~/.local/bin/greenpass --qr ah.png
Traceback (most recent call last):
  File "/home/stefanoco/.local/bin/greenpass", line 138, in <module>
    res = logic.verify_certificate(out, gpp, sm, cup)
  File "/home/stefanoco/.local/lib/python3.9/site-packages/greenpass/logic.py", line 342, in verify_certificate
    key = cup.get_key_coseobj(gpp.get_kid(), alg=alg)
  File "/home/stefanoco/.local/lib/python3.9/site-packages/greenpass/api.py", line 148, in get_key_coseobj
    return self.getcoseobj(pubkey, alg)
  File "/home/stefanoco/.local/lib/python3.9/site-packages/greenpass/api.py", line 156, in getcoseobj
    return self._get_es256_cose_obj(pubkey)
  File "/home/stefanoco/.local/lib/python3.9/site-packages/greenpass/api.py", line 189, in _get_es256_cose_obj
    return CoseKey.from_dict(kattr)
  File "/home/stefanoco/.local/lib/python3.9/site-packages/cose/keys/cosekey.py", line 91, in from_dict
    key_obj = cls._key_types[received[KpKty.fullname]].from_dict(received)
  File "/home/stefanoco/.local/lib/python3.9/site-packages/cose/keys/ec2.py", line 43, in from_dict
    return cls(crv=curve, x=x, y=y, d=d, optional_params=_optional_params, allow_unknown_key_attrs=True)
  File "/home/stefanoco/.local/lib/python3.9/site-packages/cose/keys/ec2.py", line 91, in __init__
    raise CoseInvalidKey("Either the public values or the private value must be specified")
cose.exceptions.CoseInvalidKey: Either the public values or the private value must be specified

[berdav]

Strange, for now it is working for me with the current master.

Can you try removing the cache (~/.local/greenpass) and using --no-cache?

[stefanoco]

Works now (either with --no-cache or by removing cache).

The strange thing (unrelated to this issue) is that one of the QR Codes that was generated with stolen private keys a few days ago is now being recognized as correctly signed. So the revocation of compromised certificates in place yesterday (October, 27) is not effective today (October, 28).

[berdav]

I'm closing the issue for now, we can continue the discussion here if you're interested.

Also, that what's happening with VerificaC19 (the italian official application), at least on my smartphone. The AH certificates are now correctly validated by the app.

From a technical point of view, the public key relative to the private key used to sign the AH certificate was reintroduced in the keys repositories. I don't know if the generated certificates are not relevant (so it is not a problem for the authorities) or the system is not behaving well without the key and there are some management problems that required the re-introduction of the so-called "leaked" keys.