add support types for license verification #385
Conversation
This patch adds some infra to support license verification: The main change is the addition of LicenseAuthenticator and LicenseChecker. LicenseAuthenticator is responsible for taking a license document, verifying that it is signed correctly, and then returning the contained signed LicenseInfo. LicenseChecker takes a LicenseInfo and validates that the license it describes can be used. These new classes operate on the pojo types defined under the model package that define the structure of the license documents, and the key registry (SigningKeys) that's to be packaged into the jar. Finally, this patch also includes a utility class for parsing pem files, which we'll use to store public keys. I opted to write our own parser (rather than using something like bouncycastle) because the format it's simple and I'd rather not include a dependency on a foundational artifact like bouncycastle that is likely to conflict with a user's dependencies.
| // Given: | ||
| final var store = new ResponsiveKeyValueStore( | ||
| ResponsiveKeyValueParams.keyValue("test"), | ||
| ResponsiveKeyValueParams.keyValue("license-test"), |
There was a problem hiding this comment.
damn it intellij you're not as smart as you think
| import java.util.Base64; | ||
| import java.util.List; | ||
|
|
||
| public class PublicKeyPemFileParser { |
There was a problem hiding this comment.
I could have used bouncycastle to parse these, but I didn't want to bring it in as a dependency just to do that because it's likely the user will also depend on bouncycastle (possibly at a conflicting version).
| } | ||
| } | ||
|
|
||
| private void verifyTimedTrialV1(final TimedTrialV1 timedTrial) { |
There was a problem hiding this comment.
I'm thinking about what attack vectors there might be. I'm not at all worried about any attack vector for timed trial (should I be?), but when we start adding more complicated ones (i.e. usage based) the bad types of attacks open up (like an organization trying to use up credits for another organization by spoofing some part of this).
For that, doing any kind of client-side validation won't be possible since you could always attach a debugger and change things after the signature is verified.
I don't think this has any bearing on this PR, but we'll probably need to attach some kind of cryptographic license identifier to any metric we send home -- so just something to keep in mind to see if that changes the design here for anything.
This patch adds some infra to support license verification:
The main change is the addition of LicenseAuthenticator and LicenseChecker. LicenseAuthenticator is responsible for taking a license document, verifying that it is signed correctly, and then returning the contained signed LicenseInfo. LicenseChecker takes a LicenseInfo and validates that the license it describes can be used.
These new classes operate on the pojo types defined under the model package that define the structure of the license documents, and the key registry (SigningKeys) that's to be packaged into the jar.
Finally, this patch also includes a utility class for parsing pem files, which we'll use to store public keys. I opted to write our own parser (rather than using something like bouncycastle) because the format it's simple and I'd rather not include a dependency on a foundational artifact like bouncycastle that is likely to conflict with a user's dependencies.