feat: verify PKAM with the enrollment's own signing algorithm - #2736
Open
gkc wants to merge 2 commits into
Open
Conversation
Adds the mldsa65 branch, without which a post-quantum APKAM keypair could never authenticate: the signature was well formed and the public key correct, but an unrecognised signingAlgo fell through to the RSA default and was interpreted under the wrong algorithm. For an APKAM-authenticated connection the algorithm now comes from the enrollment record rather than being restated by the client on every connect. This is hardening, not a fix, and worth saying so plainly: the signature is checked against the stored public key either way, so a client that misstates the algorithm only fails its own verification and cannot downgrade anything. What it closes off is cross-algorithm confusion, where one key blob parses under more than one algorithm. Legacy PKAM keeps reading the value from the wire. It has no enrollment record to be authoritative about, and it may legitimately present ecc_secp256r1 — the functional suite covers exactly that, authenticating with an ECC key over the legacy path, so pinning it to rsa2048 would have broken real behaviour rather than tightened it. A legacy enrollment predating the signingAlgo field records none, so it keeps the existing default too. Parity is owed from the other atServer implementations before a post-quantum client can rely on this: at least one rejects signingAlgo:mldsa65 while parsing the command, so a PQ client meets an invalid-syntax error rather than an authentication failure, and it carries no ML-DSA support to add a branch to yet.
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.
- What I did
mldsa65branch to PKAM signature verification. Without it a post-quantum APKAM keypair could never authenticate: an unrecognisedsigningAlgofell through to the RSA default, so a well-formed signature over a correct public key was simply interpreted under the wrong algorithm.ecc_secp256r1key — so pinning it torsa2048would have broken working behaviour rather than tightened anything. A legacy enrollment predating thesigningAlgofield records none and keeps the existing default.- How I did it
See commit & diffs.
- How to verify it
Tests pass.
enroll_verb_test.dartis green (87), and theat_client_sdkfunctional pack runs green (104) against an atServer built from this branch — every enrollment test there authenticates over the APKAM path this changes.- Description for the changelog
PKAM verification accepts
signingAlgo:mldsa65, and an APKAM connection's signing algorithm is read from its enrollment record rather than from the wire. Legacy PKAM is unchanged.Part of the PQ programme's SS-3; the rulings behind it are recorded in
at_client_sdkdocs/projects/pq/decisions.mdsection 21.