ECDH-SS reads the "epk" header parameter when the key being tried is a private key

Aperta
  • Qualcosa non va?
#770 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
php
Ambito
backend-api-design, security

Direzione di ricerca

Read ECDHSS::getAgreementKey() and the parent AbstractECDH::getAgreementKey() to trace how recipient and sender keys are selected. Check the decrypt method docblocks named in the issue and existing ECDH-SS tests; add coverage for private recipient keys, sender key validation, and curve matching. Done means ECDH-SS uses the two static keys and the decrypt parameter descriptions match the supported key layout.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
Version(s) affected

Every release since 3.1.0 (3.4.x, 4.0.x, 4.1.x, 4.2.x), and the 4.3.x and 5.0.x branches.

Description

ECDHSS::getAgreementKey() checks that a sender key is given, then delegates to AbstractECDH::getAgreementKey(), which was written for ECDH-ES. When the key passed as recipient key has a private part (d), the parent takes the other public key from the epk header parameter and ignores the sender key. A static-static agreement must only be computed from the two static keys: ECDHSS never writes epk and should never read it. ECDH-SS+A128KW, ECDH-SS+A192KW and ECDH-SS+A256KW delegate to ECDHSS and behave the same.

Consequences:

  • With the argument order the JWEDecrypter::decrypt() docblock suggests (own private key as key, the partner's public key as $senderKey), every genuine ECDH-SS token is rejected with The header parameter "epk" is missing.
  • When the key set holds the recipient's own private key next to the partners' public keys (for instance one key set shared by ECDH-ES and ECDH-SS) and a sender key is passed, a token labelled ECDH-SS that carries an epk is decrypted with the recipient's private key alone. Such a token needs no partner key, so "alg": "ECDH-SS" no longer proves that the sender holds one of the static keys. DecryptionResult::getKey() then returns the recipient's own key.

Not affected: the documented layout (the sender's public key in the key set, the recipient's private key as $senderKey), JWELoader and NestedTokenLoader (they never pass a sender key), and private keys whose alg member names another algorithm.

Possible Solution
  • In ECDHSS, never take the ephemeral path. When the recipient key is private, use it as the private key and the public part of the sender key as the public key (the agreement is symmetric). Validate both static keys and require the same curve.
  • Correct the $keys/$senderKey descriptions of JWEDecrypter::decrypt(), decryptUsingKeySet() and JWEDecrypterInterface::decrypt().
  • Until then, applications using ECDH-SS should check DecryptionResult::getKey() against the expected sender key.
Additional Context

Found by the Anthropic OSS Scanner (ANT-2026-ZDSZBGFB).

Lingua principale
PHP
Stelle
954
Fork
119
Merge medio
48m
PR unite (30g)
17

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di web-token/jwt-framework

Tutte le issue di web-token/jwt-framework

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.