Add random key padding

[pithumke]

Summary:

• Generate a fixed number of random diagnosis keys for every real submitted key
  • Random diagnosis keys share all properties of the real key, except for the key_data
• Add configurable random-key-padding-multiplier property
• Improves Aggregate File Creation: Skip packages if payload too small #108
• Related to https://github.com/corona-warn-app/cwa-documentation/issues/236
• Addresses CCC "Prüfstein" Point 9 "Unlinkability" without introducing additional delay:
  • https://github.com/corona-warn-app/cwa-documentation/blob/master/pruefsteine.md#unlinkability

Documentation for the random-key-padding-multiplier property from application.yaml:

# The number of keys to save to the DB for every real submitted key.
# Example: If the 'random-key-padding-multiplier' is set to 10, and 5 keys are being submitted,
# then the 5 real submitted keys will be saved to the DB, plus an additional 45 keys with
# random 'key_data'. All properties, besides the 'key_data', of the additional keys will be
# identical to the real key.

[pithumke]

TODOs for tomorrow.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

100.0% Coverage
0.0% Duplication

[pinkit-cwa]

@pithumke Is there a specific reason why you chose to just add random TEKs for every TEK instead of rounding up the number of TEKs to the next 10 or maybe 32?
I am not into statistics, but these guys seem to be, and comment:

For some reason the German server publishes 10 keys for every one really uploaded. (See this github issue.) I don't really buy that as a privacy win TBH - just rounding up to a multiple of 10 would be fine, but at least I think I now understand the numbers.

The discussion for the issue "just" requested to add random TEKs in case there is a small number of TEKs (less than 10 / round up to at least 10 TEKs).

[pithumke]

Hello @pinkit-cwa,
as outlined in this comment and this comment, we chose this approach, because we want to avoid DPP problems arising from statistical analysis of random TEKs while still keeping the 140 threshold required by the RKI (but reaching it faster). Simply duplicating all real keys N times and only forging the key_data portion, avoids this potential problem, was quick and easy to implement and was signed off by the RKI. If we were to instead "round up" the total number of TEKs, we would need to randomly generate full TEKs from scratch (including the transmission risk level and the rolling start interval number), potentially risking those fake keys to be identifiable by statistical analysis.

[hilmarf]

@ChristopherSchmitz - luckily Pit made this padding already configurable and the default is only 1. So as long as security/DPP has no other concerns, we can simply change the value, if required.