Using tink key pairs error - no enabled keys found about cross-media-measurement HOT 8 CLOSED

@MargaridaFaria2

1. The steps to reproduce are unclear. Do you get this error during the MC creation process?
2. There is no "test MC" component in Halo. Is this from the Reporting server? From the Kingdom?
3. What do you mean by DEV and TEST environments? Does DEV mean the halo-cmm-dev Google Cloud project?

Please include the appropriate context, e.g. the relevant request and response messages from logs.

from cross-media-measurement.

@SanjayVas just updated the issue with more context and a log with the error message.

from cross-media-measurement.

@MargaridaFaria23 It still didn't quite include the correct information. The steps highlight the MC creation process you followed, but is missing the step(s) which actually result in the error. What do you mean by "when we try to use them? e.g. are you calling GetMeasurementConsumer to get the MC key?

The logs I'm seeking are the requests/responses from the Halo service methods. Ideally the response that actually includes the public key. (Public keys and certificates are not sensitive and can be shared. It's only the private keys that shouldn't be shared.) The screenshot you included appears to be from some non-Halo code.

See related Slack thread: https://cross-mediaworkspace.slack.com/archives/C0312M4HE3F/p1680007667082469

Tip: If you're getting logs from Kubernetes pods in GKE via Google Cloud Monitoring, you will likely find it difficult to copy and paste multiple lines cleanly. Once you've narrowed down the right section, you can use kubectl logs with options to limit to the right lines. e.g. --since-time.

from cross-media-measurement.

@SanjayVas the error is not coming directly from the Kingdom itself. We have created the tink keys and created MCs as per the guides. Then when trying to encrypt metadata to create event groups first we fetch the MC's data by doing getMeasurementConsumers call, grab the public key and proceed to encrypt. At this points the tink library is throwing the error on the screenshot above about not having an enabled key.

On slack you helped me validate one of the keys which happened to be Halo's, it seems the ones we have created are the ones having the issue, hence I am assuming we didn't create them correctly, but we followed the tink creation guide - hence why we are following up on this topic

from cross-media-measurement.

the error is not coming directly from the Kingdom itself. We have created the tink keys and created MCs as per the guides. Then when trying to encrypt metadata to create event groups first we fetch the MC's data by doing getMeasurementConsumers call, grab the public key and proceed to encrypt. At this points the tink library is throwing the error on the screenshot above about not having an enabled key.

I assumed this was the case. I was trying to indicate that the bug filing process was not being followed with the appropriate information.

I suspect that this is not a Halo issue given that the correctness test and manual usage in the dev/QA environment works. I suspect this is an issue either with generating/serializing the key for CreateMeasurementConsumer or with deserializing the key at the other end. Hence why the first thing I'd like to see is the GetMeasurementConsumer response so I can see if the key format is correct.

from cross-media-measurement.

@SanjayVas here's a document with the gRPCurl call response, our code that calls the getMeasurementConsumer method and the response we get back from our grpc client
PublicKey.docx

from cross-media-measurement.

Decoding the public key data gives the following EncryptionPublicKey message:

format: TINK_KEYSET
data: "\010\202\236\233\304\004\022\334\001\n\317\001\n=type.googleapis.com/google.crypto.tink.EciesAeadHkdfPublicKey\022\213\001\022D\n\004\010\002\020\003\022:\0228\n0type.googleapis.com/google.crypto.tink.AesGcmKey\022\002\020\020\030\001\030\001\032!\000\266\375\257=?\226\n\344zD\202O\250\277?\301Yd\034\231\010\351\230\212\336\235\312\372@d\364$\" \034\005n\345\227\343\263\257d\021\221T\314\034>\212\0228\204W\321Z\261S\336\212,Z\253\300U\255\030\003\020\001\030\202\236\233\304\004 \001"

Decoding this data field as a Tink Keyset message gives:

primary_key_id: 1216794370
key {
  key_data {
    type_url: "type.googleapis.com/google.crypto.tink.EciesAeadHkdfPublicKey"
    value: "\022D\n\004\010\002\020\003\022:\0228\n0type.googleapis.com/google.crypto.tink.AesGcmKey\022\002\020\020\030\001\030\001\032!\000\266\375\257=?\226\n\344zD\202O\250\277?\301Yd\034\231\010\351\230\212\336\235\312\372@d\364$\" \034\005n\345\227\343\263\257d\021\221T\314\034>\212\0228\204W\321Z\261S\336\212,Z\253\300U\255"
    key_material_type: ASYMMETRIC_PUBLIC
  }
  status: ENABLED
  key_id: 1216794370
  output_prefix_type: TINK
}

There is indeed a key with status ENABLED here. I suspect something is off in the code that deserializes the Tink Keyset and calls the Tink library. I assume you're not using the consent-signaling-client library and have written your own code to do this. I don't see any problems in the Halo code here as it appears to have no issues passing the key through, so this issue can be considered closed.

If you separately share your code, I can see about helping debug that.

from cross-media-measurement.

Thanks Sanjay - Agree that it is not a Halo code issue but lack of familiarity with the library dependencies and how to incorporate them on the client side. It would be worth having some of these processes documented for future reference and future EDPs who might run into this situation. We will look into including the consent signalling and use it as intended, if we are blocked we can use next Thursday support call to go trough it.

Thanks again for the support

from cross-media-measurement.