Italiano

Strumenti per sviluppatori · Decodificatore JWT

JWE Spiegato: perché un JWT crittografato ha cinque parti e nessun payload leggibile

· Sfondo

jwt crittografia formati di dati

Cinque segmenti JWE compatti che circondano un payload di testo cifrato illeggibile
Illustrazione vettoriale originale ToolAcre

Alcuni token hanno quattro punti invece di due e un carico utile che non è JSON. Questo post spiega la serializzazione compatta JWE, cosa contiene ciascuna delle sue cinque parti e perché nessuno strumento di sola decodifica può mostrare le sue affermazioni.

Quattro punti e un carico che non è JSON: i segnali che hai in mano sono un JWE, non un JWS

Quattro punti e cinque segmenti indicano una busta compatta diversa dalla familiare forma firmata in tre parti. Cercare di analizzare i suoi byte centrali come affermazioni JWT produce senza senso perché il contenuto è testo cifrato, non un'ortografia base64url del testo normale JSON.

ToolAcre controlla il conteggio dei segmenti prima della decodifica. Cinque parti attivano un messaggio INVALID_JWT che identifica un JWE e spiega perché non c'è nulla da mostrare in questo percorso di sola decodifica senza una chiave di decrittazione. Questo è un confine preciso piuttosto che un vago errore di analisi.

Le cinque parti: intestazione protetta, chiave crittografata, vettore di inizializzazione, testo cifrato e tag di autenticazione

Le parti compatte JWE rappresentano un'intestazione protetta, materiale della chiave crittografata, un valore di inizializzazione, testo cifrato e un tag di autenticazione. Ciascuno ha un ruolo crittografico distinto. La sola posizione del segmento non rende il secondo o il quarto campo un payload JWT leggibile.

Un decodificatore può dividere e decodificare base64url alcuni byte, ma i byte grezzi non vengono decrittografati. Visualizzarli come testo creerebbe caratteri sostitutivi o frammenti fuorvianti. L'azione corretta consiste nell'identificare la busta e spostarla in un'implementazione del destinatario autorizzato.

alg ed enc: gestione delle chiavi rispetto alla crittografia dei contenuti e perché un'intestazione JWE nomina due algoritmi

Un'intestazione JWE può contenere `alg` per la gestione delle chiavi e `enc` per la crittografia del contenuto. Queste etichette descrivono diverse operazioni. Come per i token firmati, i valori dell'intestazione sono input che devono corrispondere alla politica del destinatario anziché all'autorizzazione del token per selezionare algoritmi arbitrari.

Le note dell'algoritmo in tre parti di ToolAcre non implementano l'elaborazione JWE e il ramo in cinque parti esce prima dell'analisi dell'intestazione. La pagina quindi non visualizza né avalla particolari algoritmi di crittografia. Consultare la biblioteca destinataria e il contratto emittente per le scelte supportate.

Chiavi di crittografia del contenuto: come una chiave casuale protegge il carico utile e viene essa stessa incapsulata per il destinatario

La crittografia del contenuto utilizza comunemente una chiave di crittografia del contenuto generata, mentre il segmento della chiave crittografata trasmette o deriva tale chiave in base all'accordo del destinatario. La separazione consente di proteggere i byte del payload con una cifratura del contenuto mentre la policy di gestione delle chiavi determina chi può recuperare la chiave.

Questo modello concettuale spiega perché possedere la stringa compatta non è sufficiente per il recupero del testo in chiaro. I segreti e la policy del destinatario richiesti non sono codificati come istruzioni liberamente utilizzabili. Un decoder pubblico non può inventarli e non dovrebbe mai chiedere agli utenti di incollare chiavi di decrittazione private in una pagina generica.

Quando gli emittenti scelgono JWE: reclami che devono rimanere riservati da parte del cliente o degli intermediari

Gli emittenti possono selezionare la crittografia quando le richieste devono rimanere riservate da parte dei titolari o degli intermediari che possono vedere un token firmato. Se questa sia la scelta giusta dipende dal modello di minaccia, dalla distribuzione delle chiavi e dai requisiti operativi. Ridurre al minimo il contenuto delle richieste può comunque essere preferibile piuttosto che crittografare i dati non necessari.

La crittografia non elimina i problemi di autorizzazione, convalida o metadati. Il destinatario deve autenticare il contenuto protetto e applicare la policy dei token dopo la decrittografia. Un risultato leggibile ottenuto da un destinatario autorizzato non è automaticamente accettabile per ogni servizio.

Perché la decodifica si ferma all'intestazione: il carico utile è un testo cifrato, quindi solo il detentore della chiave può leggerlo

La decodifica si ferma alla struttura perché il segmento del potenziale carico utile è un testo cifrato. ToolAcre evita deliberatamente di presentare un binario arbitrario come JSON e fornisce invece un messaggio specifico. Ciò impedisce agli utenti di interpretare parole senza senso come corruzione in una busta crittografata altrimenti valida.

Se sei il destinatario previsto, utilizza un software controllato configurato con la chiave e gli algoritmi appropriati. In caso contrario, il payload illeggibile è la proprietà di sicurezza prevista. Nessun trucco di riempimento o decodificatore di caratteri alternativo può sostituire la decrittazione.

Cosa non copre: JWT nidificati firmati e quindi crittografati e serializzazione JWE JSON

Le costruzioni nidificate possono firmare il contenuto e quindi crittografare il risultato o altrimenti combinare i livelli sotto un profilo definito. JWE ha anche rappresentazioni oltre la stringa compatta in cinque parti. ToolAcre non elabora questi casi e questo articolo non deduce la nidificazione semplicemente da un'etichetta di intestazione.

Documenta il livello previsto dal tuo sistema prima della risoluzione dei problemi. Altrimenti un team potrebbe tentare la verifica della firma su un testo cifrato o decodificare un token interno che non è stato autenticato. Consenti alla libreria JOSE selezionata di gestire l'ordine in base a criteri espliciti.

Conclusione: un decodificatore può mostrare solo ciò che non è crittografato: il decodificatore ToolAcre JWT mostra l'intestazione e il payload di un token firmato; Il payload di JWE è illeggibile per impostazione predefinita

Un decoder può mostrare solo ciò che non è crittografato. ToolAcre legge JSON dall'intestazione e dal payload dell'input firmato in tre parti, mentre cinque segmenti causano un'interruzione esplicativa. Questa distinzione impedisce a un'interfaccia di sola decodifica di fingere di avere capacità di destinatario.

Utilizzare il conteggio dei segmenti come indizio di routing, non come risultato di attendibilità. Tre parti leggibili richiedono ancora la verifica della firma; cinque parti crittografate richiedono la decrittografia e la convalida autorizzate. In nessuno dei due casi l'output visivo da solo autentica le richieste o concede l'accesso.