Fix/jwt algorithm confirmation - #72
Open
1456055067 wants to merge 2 commits into
Open
Conversation
…n-token HMAC key Close two JWT issues in takserver-core: - Algorithm confusion: verifiers built via the legacy jjwt setSigningKey(Key) API selected the algorithm from the attacker-controlled `alg` header, allowing an RS256 token to be re-signed as HS256 using a published RSA public key as the HMAC secret. All verifiers now use a SigningKeyResolver that pins the expected algorithm (RS256 for OAuth/OIDC, HS384 for mission tokens) and rejects mismatches. - Mission tokens were HMAC-signed using the raw RSA private-key DER bytes as the symmetric secret. They now use a dedicated key derived via HMAC-SHA384 (PRF/KDF) with domain separation; derivation stays deterministic so multi-server/missionTls verification continues to work. Mission-token signing/verification moves HS256 -> HS384 (FIPS 198-1 approved, CNSA/Suite-B minimum). In-flight mission tokens are invalidated on upgrade.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Hardens JWT handling in
takserver-coreto close two issues found during a security review:Algorithm confusion on token verification. Verifiers were built with the legacy
jjwt
setSigningKey(Key)API, which selects the verification algorithm from thetoken's own
algheader. A token signed RS256 could be re-presented as HS256, causingthe RSA public key to be used as the HMAC secret. All verifiers now use a
SigningKeyResolverthat pins the expected algorithm (RS256 for OAuth/OIDC,HS384 for mission tokens) and rejects any mismatch before signature validation.
Asymmetric key used as a symmetric secret. Mission tokens were HMAC-signed using
the raw RSA private-key DER bytes as the secret. They now use a dedicated key derived
via HMAC-SHA384 (PRF/KDF) with domain separation. Derivation remains deterministic, so
the existing multi-server /
missionTlsshared-key verification model is preserved.Changes
JwtUtils: addpinnedResolver(...)(algorithm-pinnedSigningKeyResolver) andderiveHmacKey(...)(HMAC-SHA384 KDF); route all external/OAuth and mission-tokenverifiers through them.
MissionTokenUtils: sign with the derived key.Compatibility / deployment notes
invitation/access tokens; re-issued automatically). During a rolling upgrade,
mixed-version servers will not verify each other's mission tokens until all are upgraded.
Testing
:takserver-core:takserver-war:compileJava✅:takserver-core:compileTestJava✅MissionAuthorizationTests) not run in this environment (require DB/Ignite).Follow-ups (not in this PR)
FederationJwtUtils(federation hub) shares the asymmetric-key-as-HMAC-secret pattern;lower exploitability (HMAC-only, secret key) but worth the same treatment.