Segreti e autenticità digitale: quando il silicio non basta

Su Windows già infetto, un malware estrae tutte le passkey salvate in Google Password Manager. La demo di Arie Olshtein si chiama Pass‑ta‑key. Mostra che il TPM non basta se l’app carica materiale in chiaro durante l’uso. Tesi: i segreti vivono dove le applicazioni li maneggiano, non solo dove dicono di custodirli.

1) Il punto: isolamento teorico vs. pratico

Le piattaforme parlano di isolamento hardware. La pratica introduce superfici vive: memoria in chiaro, tracciati di API, cookie di sessione. Qui passano chiavi, token, ragionamenti di modelli. Dimostrazioni recenti toccano tre lati della stessa cosa: esfiltrare da host compromessi, riprodurre contenuti “nascosti” da un servizio, e legare segreti al dispositivo per limitare il furto. La domanda operativa è semplice: durante il flusso normale, cosa resta leggibile o riproducibile?

2) Passkey e host compromessi: la demo Pass‑ta‑key

Olshtein, Palo Alto Networks, parte da un presupposto netto: macchina infetta. In questo scenario, recupera tutte le passkey conservate dall’app Google Password Manager per Windows. Il nome del proof‑of‑concept gioca su “passkey” e “pass the key”.

Il punto cade su un equivoco. Si pensa che le passkey risiedano sempre nel Trusted Platform Module. Olshtein mostra un’implementazione che non vincola sempre le chiavi al TPM. Se l’host è compromesso, l’attaccante sfrutta ciò che l’app carica o maneggia in chiaro e tira fuori le passkey dell’utente. Ars Technica inquadra la questione: le tecniche non sono nuove, non riguardano solo le passkey. Conta come le applicazioni generano, archiviano e usano le chiavi su Windows.

La lezione è concreta. Il TPM protegge ciò che non esce dal suo perimetro. Ma le app devono usare le chiavi. In quel momento aprono finestre operative. Se quelle finestre non sono schermate, l’isolamento teorico si riduce a promessa.

3) Segreti nei canali: replay di “chain‑of‑thought” dalle API

L’11 agosto 2026 Simon Willison mostra un’altra finestra. Le API di Anthropic, OpenAI e Google possono restituire blocchi cifrati di “chain‑of‑thought”. Si possono catturare, rigiocare in modelli più deboli e decifrare fino a ottenere il ragionamento in chiaro. Gli autori affermano che il replay funziona tra sessioni, utenti e modelli diversi.

La tecnica segue tre mosse. Si cattura una traccia prodotta da un modello “frontier”. La si riproduce in un “weaker sibling”. Poi si effettua un jailbreak sul modello debole per far restituire il testo del ragionamento nascosto. Willison definisce il lavoro “a neat paper” e indica il dominio stolen‑thoughts.com con il materiale della ricerca. Mostra anche come individuare i blocchi cifrati in una risposta API.

L’esempio pratico usa una chiamata a https://api.openai.com/v1/responses con il modello “gpt‑5.6‑luna”. La richiesta imposta reasoning.effort su “medium”. Include reasoning.encrypted_content. Da lì, si isola il contenuto cifrato e si tenta il replay sul modello più debole.

Qui non c’è host compromesso. C’è un tracciato di servizio che contiene un segnale riutilizzabile. La cifratura offusca, ma non chiude la riproducibilità. Se il canale permette replay e il “fratello minore” esegue istruzioni simili, il testo nascosto riemerge.

4) Contromisure hardware e marcatura di provenienza: cosa fanno e dove inciampano

Chrome introduce le device‑bound session credentials (DBSCs) per frenare i takeover basati su cookie rubati. Il browser genera una chiave unica e la custodisce in hardware sicuro: TPM su Windows, Secure Enclave su macOS e iOS. Altri sistemi usano componenti con funzioni analoghe.

Il bersaglio è preciso. I cookie impostati dopo l’autenticazione permettono di evitare nuove credenziali. Se li rubano, possono assumere l’identità dell’utente senza rifare il login. Le DBSCs legano la sessione al device che ha creato la chiave. Un cookie copiato altrove perde valore. Il meccanismo sposta il segreto dal software al silicio. Quando il server valida la sessione, il browser prova il possesso della chiave legata a quel dispositivo.

La beta 5 di iOS 27 contiene riferimenti ad “Apple Reference Image”. Il sistema scrive metadati di provenienza al momento dello scatto e introduce una nuova modalità nella Fotocamera. Le note dell’anteprima segnalano la funzione “disattivata per impostazione predefinita”.

L’attivazione segue un percorso preciso: Impostazioni > Fotocamera > Reference Image > Reference Mode. Solo le foto scattate con l’opzione “Reference” conterranno le informazioni necessarie all’autenticazione. La verifica non parte in automatico. Si tocca un badge “Reference” sulla fotografia. Quel tocco invia l’immagine raw con i metadati incorporati per consentire il controllo.

Due obiettivi diversi, una stessa logica: ancorare stato o contenuto a un perimetro fisico e a un atto tracciabile. Ma restano vincoli pratici. Le DBSCs dipendono dalla prova locale della chiave; se l’applicazione lascia spazi a materiale in chiaro sull’host, il furto può spostarsi su altre superfici. La “Reference Image” richiede una scelta esplicita e un flusso dedicato; se chi scatta o chi condivide non usa la modalità, la catena di provenienza non esiste.

5) Cosa cambia per sviluppatori, sicurezza e QA

Per chi costruisce autenticazione e servizi ML, il rischio non è astratto. È operativo. Le passkey perdono protezione quando l’app le maneggia fuori dal TPM su un host compromesso. I blocchi cifrati di ragionamento diventano testo leggibile quando un canale API li rende riproducibili in un modello più debole. I cookie di sessione valgono finché non li si lega a una chiave nel dispositivo. Le foto sono verificabili se nascono con metadati scritti durante lo scatto e se l’utente avvia la verifica.

Questo impone tre pratiche di base:

• Mappare dove i segreti esistono in chiaro. Durante la generazione, in memoria, nei log e nei piani di interoperabilità tra componenti.
• Testare i vettori di replay e di esfiltrazione. Su host compromessi e su canali di servizio. Cercare segnali riutilizzabili, come tracciati cifrati “rigiocabili”.
• Integrare contromisure che riducono la superficie viva. Vincolo al dispositivo per le sessioni. Percorsi di provenienza che nascono durante lo scatto. E revisioni che verifichino l’effetto di usabilità: dove la protezione viene disattivata o aggirata per far funzionare il flusso?

La qualità oggi si misura anche così: meno segreto in chiaro, meno tracciati riutilizzabili, più controlli che vivono nel perimetro fisico. Non basta dichiarare “TPM” o “cifrato”. Serve mostrare, passo per passo, che l’app non espone materiale sensibile mentre fa il suo lavoro.

Il messaggio delle tre dimostrazioni è convergente. Le difese funzionano quando restano end‑to‑end lungo il flusso reale. Quando invece un componente espone, un’API suggerisce replay o una funzione resta spenta per impostazione predefinita, l’attaccante trova spazio. Chi progetta dovrebbe trattare assunzioni come “se sta nel TPM, non si estrae” o “se è cifrato, non si legge” come ipotesi da confutare in test, non come garanzie accettate.