Segreti nel silicio e leakage operativo: quando la protezione non basta

Arie Olshtein ha mostrato che, su Windows già infetto, un malware può estrarre tutte le passkey salvate nel Google Password Manager. La demo si chiama Pass-ta-key. Il ricercatore di Palo Alto Networks ha recuperato le chiavi sfruttando ciò che l’app carica o maneggia in chiaro durante l’uso. La tesi è qui: spostare i segreti nel silicio o sigillarli nei metadati aiuta, ma non copre il rischio operativo quando l’host, il software o la catena API diventano il punto debole.

1) Due approcci alla difesa: hardware e metadata

Chrome lega le sessioni al dispositivo con le device-bound session credentials. Il browser genera una chiave di cifratura unica e la custodisce in un modulo sicuro dell’hardware. Su Windows il Trusted Platform Module. Su macOS e iOS la Secure Enclave. L’obiettivo è ridurre i takeover basati su cookie rubati. Un cookie copiato su un altro device perde valore perché non prova il possesso della chiave locale.

Il meccanismo sposta il segreto dal software al silicio. Il browser crea la chiave nel dispositivo. La tiene nel perimetro fisico del modulo sicuro. Quando il server valida la sessione, il client dimostra di possedere quella chiave legata al device.

Apple lavora su un’altra frontiera: attestare l’origine delle immagini. La beta 5 di iOS 27 contiene riferimenti a “Apple Reference Image”. Il sistema scrive metadati di provenienza al momento dello scatto e introduce una nuova modalità nella Fotocamera. La funzione è disattivata per impostazione predefinita nella beta in circolazione. L’attivazione segue un percorso: Impostazioni > Fotocamera > Reference Image > Reference Mode. Solo le foto scattate con la nuova opzione “Reference” nell’app Fotocamera contengono le informazioni di provenienza. La verifica non parte in automatico. Si tocca un badge “Reference” sulla fotografia per avviarla. Quel tocco invia l’immagine raw con i metadati incorporati per consentire il controllo.

Qui il pattern è affine a Chrome, ma applicato alle prove di autenticità. Il legame non è con un cookie di sessione, bensì con il momento e lo strumento della cattura. L’attestazione nasce nel punto di creazione e vi resta ancorata nei metadati.

2) Cosa non risolve il vincolo hardware

Pass-ta-key entra nella zona tra aspettativa e pratica. L’idea diffusa dice che le passkey risiedono solo nel TPM e quindi non si estraggono. Olshtein mostra un’implementazione che non vincola sempre le chiavi al TPM. Su un host compromesso, l’attaccante può leggere ciò che l’applicazione carica in chiaro durante l’uso e ricavarne le passkey dell’utente.

Il presupposto è concreto: macchina infetta. In questo scenario, l’ancoraggio hardware non protegge ciò che l’app rende disponibile per funzionare. Il malware opera dove l’app opera. Ars Technica inquadra il punto: le tecniche non sono nuove e non riguardano solo le passkey. Il nodo è cosa fanno davvero le applicazioni, in pratica, quando generano, archiviano e usano le passkey su Windows.

La lezione si estende al disegno delle difese legate al dispositivo. Vincolare una chiave al TPM o alla Secure Enclave limita la clonazione. Non elimina il rischio di esposizione in memoria o nei flussi transitori. I sistemi reali caricano e trasformano dati. Ogni passaggio crea un momento in cui un segreto o un derivato transita in chiaro. L’attaccante, su un host già compromesso, cerca proprio quei momenti.

3) Leakage oltre l’host: ricostruire ragionamenti cifrati via API

L’11 agosto 2026 Simon Willison descrive un altro tipo di leakage. Non dall’hardware, ma dalla catena di servizio dei modelli. Le API di Anthropic, OpenAI e Google possono restituire blocchi di “chain-of-thought” cifrati. I ricercatori catturano una traccia prodotta da un modello “frontier”. La riproducono in un “weaker sibling”. Effettuano un jailbreak sul modello debole per far restituire il testo del ragionamento che quello forte aveva nascosto. Gli autori affermano che il “replay” funziona tra sessioni, utenti e modelli diversi. Willison rimanda al paper e al sito dedicato stolen-thoughts.com.

L’esempio pratico cita una chiamata a https://api.openai.com/v1/responses. Usa il modello “gpt-5.6-luna”. Imposta reasoning.effort su “medium”. Include reasoning.encrypted_content. Mostra come individuare i blocchi cifrati in una risposta API e come alimentarli nel modello più debole per decifrarli.

Questa dinamica sposta il discorso dalla protezione dell’endpoint alla gestione dei flussi tra componenti. Un contenuto che un modello forte “nasconde” può riemergere quando la pipeline lo riporta a un modello con policy diverse. Qui non c’è host compromesso. C’è un canale API che trasporta materiale sensibile in forma cifrata e un secondo modello che, su input mirato, lo rende leggibile.

4) Cosa conta per chi progetta sistemi, AI e QA

I tre casi disegnano una traiettoria. Vincolare un segreto all’hardware argina la clonazione. Attestare la provenienza alla cattura aggiunge un controllo verificabile. Ma il rischio effettivo nasce nell’operatività delle applicazioni, nei transiti in memoria, nelle catene API e nei rapporti tra modelli con capacità e policy diverse.

Per chi progetta:

• Definire l’obiettivo di minaccia con precisione. Le device-bound session credentials mirano ai cookie rubati, non agli host già compromessi. Puntano a bloccare la riusabilità del cookie su altri device. Pass-ta-key, al contrario, parte da macchina infetta e guarda a cosa l’app espone nel normale funzionamento.
• Limitare le esposizioni in chiaro durante l’uso. Se un’app deve manipolare una chiave, misurare dove e quando emerge in forma leggibile. Tagliare copie superflue. Ridurre la superficie delle interfacce interne.
• Governare i flussi API che trasportano materiale sensibile, anche se cifrato. Se un servizio emette blocchi di “reasoning” cifrati e un altro servizio può rivelarli con un replay, il rischio è architetturale.

Per chi fa QA:

• Testare scenari di host compromesso. Non per attaccare il TPM, ma per osservare dove l’app lascia tracce sfruttabili. Esercitare i percorsi reali di generazione, uso e archiviazione delle chiavi.
• Strumentare le pipeline. Cercare blocchi sensibili nelle risposte API. Verificare che la catena non consenta replay non intenzionali tra servizi o modelli.
• Verificare i percorsi di attivazione e di verifica delle funzioni di attestazione. Nel caso di “Apple Reference Image”, la feature è disattivata per impostazione predefinita nella beta. La validazione parte solo con un’azione utente precisa e invia l’immagine raw con i metadati incorporati. Questi vincoli operativi contano nei casi d’uso e nei test.

La direzione nelle fonti è concreta: spostare i segreti nel silicio e legare le prove al momento della creazione riduce la copiabilità. Ma la tenuta dipende da come le applicazioni usano quei segreti e da come i servizi orchestrano i propri scambi. Il passo successivo è misurare dove il sistema “parla in chiaro” e chi, nella stessa architettura, può ascoltare.