Closed Bug 1552315 Opened 4 months ago Closed 4 months ago

Rotate and hard code Prio public keys

Categories

(Data Platform and Tools :: Operations, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: englehardt, Assigned: whd)

References

Details

(Whiteboard: [DataOps])

Attachments

(1 file)

We've decided that we should rotate and hard code the Prio public keys prior to landing Bug 1543712.

The keys are currently specified in prefs (prio.publicKeyA and prio.publicKeyB). We should hard code them, preferably such that they'll end up in the binary or in one of our libraries to benefit from signing. When we make the move, we can also take the opportunity to rotate the keys.

Anthony, mind to post the new public keys to this bug once they're generated?

Flags: needinfo?(amiyaguchi)

We reached out to Anthony on this and have the steps needed to do this work.

https://github.com/mozilla/python-libprio` build the docker container and then prio keygen

Flags: needinfo?(amiyaguchi)
Component: Telemetry → Operations
Product: Toolkit → Data Platform and Tools
QA Contact: moconnor
Whiteboard: [DataOps]
Assignee: nobody → whd

I've generated the following key pairs:

dev:
a:
public_key: 209A3CC721E661E1B00CFACFA7A647E8A9F1C6C94ED67A5088D1DF3DC4223542
b:
public_key: 6A544DABEA8AA2D00670879AB2048ECD81A460ECD0BF272DE937ABE0DFCC2538
stage:
a:
public_key: E724B5334187C7BEF270F6DFE123F7C0251685F1CD49520F38C7AA0AC7475E06
b:
public_key: 7E3034385C02E69AB540A5EC59DD22B9C79708DED700992A6DE3844E6AA3C109
prod:
a:
public_key: E780C1A9C50E3FC5A9B39469FCC92D62D2527BAE6AF76BBDEF128883FA400846
b:
public_key: F992B575840AEC202289FBF99D6C04FB2A37B1DA1CDEB1DF8036E1340D46C561

Of these, only prod should be hard-coded into the client. The others may be used for testing purposes in our testing of various components of the pipeline as per standard operating procedure.

The private keys are stored in our KMS-encrypted secrets store (currently under misc/prio.yaml since we haven't finalized the method by which this job will run).

When we hardcode these keys we'll be losing test flexibility. For example, PrioEncoder.BadPublicKeys and PrioEncoder.VerifyFull become irrelevant or unimplementable with a naive implementation.

How concerned should we be about losing these tests? How much effort should we go to in order to keep this coverage?

Flags: needinfo?(rhelmer)

(In reply to Chris H-C :chutten from comment #4)

When we hardcode these keys we'll be losing test flexibility. For example, PrioEncoder.BadPublicKeys and PrioEncoder.VerifyFull become irrelevant or unimplementable with a naive implementation.

How concerned should we be about losing these tests? How much effort should we go to in order to keep this coverage?

Henry suggested before that the constructor could take the public keys as arguments, which would let us preserve the flexibility to change our minds and be able to reverse the hardcoding decision without undue burden, wdyt?

Flags: needinfo?(rhelmer) → needinfo?(chutten)

I went a slightly different way looking forward to a time when we may wish to rotate the keys at runtime. Take a look and let me know if that's what you were thinking?

Flags: needinfo?(chutten)

As a plus this gives us an API we could use if we ever need to rotate the keys
at runtime.

Pushed by chutten@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/45c8ab7db844
Hardcode the new prio keys to avoid misconfiguration. r=rhelmer
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
See Also: → 1555162
You need to log in before you can comment on or make changes to this bug.