"Authentic" license key forgery vulnerability

[ezekg]

There is a possible vulnerability where if an account is simply validating a license key's signature "authenticity" and not utilizing the dataset within the license key at all, an attacker could potentially utilize a signed response payload and signature from a public endpoint, such as /validate-key, to forge a "license key" that would pass the cryptographic verification.

1. Perform a call to /validate-key with a bogus license key
2. Extract response body and base64 encode it
3. Extract signature
4. Combine encoded response and signature: BODY.SIG to craft a "license key"
5. Utilize the key within the software that only checks for license authenticity

[ezekg]

Possible remediation steps without having to manage separate keypairs for each signing subject:

• Deprecate X-Signature header in favor of X-Keygen-Signature. Remove legacy signature header for all accounts moving forward, add an upgrade path for legacy accounts. (See: Stripe-Signature header)
  1. Generate signature by signing the following contents: authorization: Bearer admin-xxx\nmethod: GET\nuri: /v1/accounts\ndate: Fri, 09 Oct 2020 14:29:55 GMT\nbody: Zm9vCg== (or similar) [nonce?]
  2. Allow Ed25519 (default), RSA-2048-PKCS1-PSS and RSA-2048-PKCS1 in X-Keygen-Accept-Signature header.
• Prefix license key and activation proof data before signing? E.g. sign('key:Zm9vCg=='), sign('proof:Zm9vCg==')
  1. Deprecate v1 schemes in favor of v2 versions which utilize the new prefixes

[ezekg]

Let's include #362 in this convo so that it doesn't get lost.