Non c'è modo di farlo: questo è un sottoinsieme di ciò che gli schemi DRM tentano di fare.

Se un utente finale può decifrare qualcosa una volta per vederlo, può vederlo di nuovo. Potrebbe essere possibile una qualsiasi delle seguenti azioni:

• prima fai una copia e decifrala
• copia lo schermo
• modifica l'applicazione

L'unico modo in cui potresti avvicinarti sarebbe avere il controllo totale sull'hardware e il software, quindi potresti cancellarlo una volta mostrato, ma anche in questo caso qualcuno potrebbe usare una fotocamera per scattare foto dello schermo ecc.

Quindi, vorrei invece chiederti per cosa intendi utilizzare un tale schema, poiché ci sono modi per avere lo stesso effetto in molti scenari.

Come hai già accennato, una cosa del genere è possibile solo nell'hardware. Un software o una soluzione di dati crittografati soffrirebbero sempre dell'opzione di fare una copia prima della decrittografia.

Nell'hardware, lo schema sarebbe quello di distruggere le informazioni sulla decrittografia. Un approccio ingenuo sarebbe semplicemente leggere un blocco in memoria, distruggerlo in memoria e quindi decrittografarlo.

Questo approccio, ovviamente, può cadere vittima di manomissioni: un utente malintenzionato potrebbe manipolare il sistema in modo che il la cancellazione fallisce, ma qualunque cosa stia facendo la decrittazione crede che sia riuscita e quindi procede con la decrittazione.

Un approccio più sofisticato sarebbe quello di sfruttare alcune proprietà fisiche in modo tale che anche la lettura delle informazioni le distrugga. Questo è, infatti, ciò che rende sicura la crittografia quantistica in gran parte teorica: non puoi origliare (ascoltare) senza distruggere le informazioni, rivelando così il fatto che qualcuno sta intercettando il messaggio.

Al di fuori del regno quantistico, potrebbero esserci soluzioni che utilizzano processi chimici o altri processi fisici, ma saranno anche soggette a manomissioni.

Se è disponibile una rete, è possibile scaricare la procedura di decrittografia (e la chiave privata) su un servizio in esecuzione su un server protetto. Potresti quindi applicare le regole che desideri sul server.

Il client invierà il testo opaco al servizio e gli chiederà di decrittografarlo e restituire il contenuto di testo normale, e il server potrebbe decidere se il client deve essere consentito in base alla cronologia della decrittografia, bloccando potenzialmente più di un'operazione di decrittografia.

Tuttavia non ci sarebbe nulla che impedisca al chiamante di utilizzare il risultato della decrittografia più e più volte, il che è più o meno lo stesso che decifrarlo più e più volte. Ci sono stati tentativi in ​​tal senso per musica e film (vedi percorso multimediale protetto), ma è una battaglia persa. Se non altro, un hacker potrebbe falsificare l'hardware del monitor e registrare il segnale in ingresso, o anche semplicemente puntare una videocamera HD verso il monitor e registrare il contenuto durante la riproduzione. Una tecnica di intercettazione simile potrebbe essere utilizzata per qualsiasi tipo di contenuto digitale. Quindi la linea di fondo è ... no, non è realmente possibile.

Un approccio più fattibile sarebbe inserire un numero di serie nel contenuto stesso e rintracciarlo in un server di autorizzazione, o in un data e ora di scadenza. Dovresti quindi applicarlo all'estremità ricevente, che dovrebbe essere un'applicazione sicura. Ecco come funziona una password monouso, ad esempio. Ma ciò richiede di possedere entrambe le estremità del percorso dati e che i dati stessi siano inutili al di fuori di esso.

Non è in alcun modo pratico e fondamentalmente impossibile (in modo affidabile), ma può essere possibile in una certa misura.

L'ovvio ostacolo che rende Lo sforzo fondamentalmente impossibile è che qualunque cosa sia la decifri, una volta che l'hai letta, è dentro la tua testa. Quindi, per essere sicuri che il segreto rimanga segreto, dovrebbe esserci una sorta di meccanismo della pillola velenosa. Forse una capsula che contiene un motore di sintesi vocale e ti trasmette il messaggio attraverso la conduzione ossea, e poi esplode, soffiando via dalla tua testa.
Perché, sai, finché respiri, puoi semplicemente dirlo a qualcuno. Tuttavia, speriamo che non ripeta ad alta voce ciò che il TTS sussurra nella tua testa.

A parte questo, esistono sistemi di archiviazione dati che possono essere letti una sola volta. DRAM e RAM ferroelettrica come alternativa non volatile sono due esempi di ciò. Questi richiedono un built-in esplicito di scrittura dopo lettura o qualcosa di diverso (ad esempio il circuito del condensatore). Altrimenti, leggere le informazioni distrugge le informazioni. Lascia perdere e hai fatto un grande passo avanti.
Ora, almeno, si dovrebbero fare due copie (una su un archivio di lettura non distruttivo, e poi un altro per averne effettivamente una copia). Tuttavia, è abbastanza all'interno del regno del "fattibile", ma a seconda della compatibilità hardware potrebbe essere comunque un peso (non sono sicuro che puoi semplicemente collegare due tipi di archiviazione completamente diversi e incompatibili e copiare dati come in Star Trek, potrebbe beh, si rivela un po 'più difficile di così!). Ma non siamo alla fine.

La chiave di decrittazione, e anche parte di, o il completo eseguibile di decrittografia (supponendo che i cicli siano srotolati) potrebbero anche essere archiviati in un archivio di lettura distruttivo all'interno della decrittografia hardware. La chiave di decrittazione non deve mai lasciare il chip, quindi a parte i "dati", non devono esserci corsie per la trasmissione. Viene letto durante la decrittazione, dopodiché non c'è più. Quindi ... ecco fatto.

A meno che non si presuma che qualcuno possa praticare fori delle dimensioni di poche dozzine di nanometri nel chip e utilizzare nanofili per intercettare in qualche modo la memoria, non c'è modo di accedere ai dati. Non sto dicendo che sia impossibile, solo ... che è un po 'folle. Nessuna informazione è abbastanza preziosa per garantirlo. Inoltre, immagino che potrebbe essere una procedura piuttosto rischiosa poiché la fuoriuscita accidentale di una piccola carica o il passaggio di alcuni nanometri troppo a sinistra oa destra inevitabilmente distruggerà anche la chiave.

Poiché la chiave di decrittazione è di solito molto piccolo (32 byte o meno), potrebbe infatti essere memorizzato all'interno di un processore enclave sicuro o simile, come avviene abitualmente in molti dispositivi mobili oggigiorno. Quella memoria potrebbe anche avere letture distruttive (e nessun accesso esterno ai dati codificati, proprio come su ogni telefono moderno). Ma non è nemmeno necessario.
Potresti avere fusibili come in Knox di Samsung o SEP di Apple, che in linea di principio ti consentono di decrittografare i dati N volte (non solo esattamente una volta, ma esattamente N volte, fino a ti piace). Dopodiché, il processore semplicemente non aggiorna (o sovrascrive esplicitamente) la chiave. Oppure, molto meno sicuro (ma probabilmente ancora abbastanza buono), rifiuta di decrittografare.
Pertanto, fare una copia dei dati crittografati non servirà a molto perché non puoi decrittografare il copia.

Ovviamente, qualcuno può ancora copiare banalmente i dati decriptati , se ci sono mezzi per farlo. Di solito ci sono, sia digitali che analogici. Se non altro, puoi fare in modo che due o tre persone guardino lo schermo contemporaneamente o che scattino una foto.

Questo, tuttavia, è un problema che fondamentalmente non puoi risolvere (tranne che da un dispositivo che esplode o da un dispositivo che rilascia gas nervino).

Da un punto di vista puramente teorico, è possibile solo se puoi assicurarti che dopo la prima decrittografia non ci siano copie esistenti di entrambi”

1. il decrittografato dati e
2. o i dati crittografati o le chiavi necessarie per decrittografarli.

In linea di principio , puoi farlo solo con la collaborazione (volontaria o coatta) delle parti che gestiscono queste informazioni che devono essere eliminate.

In pratica , questo può essere sufficiente a seconda di ciò che desideri ottenere e di quali componenti del sistema sei disposto a fidarti.

Ad esempio, se ti fidi di un tipico iPhone (non dovresti , in senso assoluto, ma come tutte le cose in materia di sicurezza, ci sono pochi assoluti, di solito c'è solo probabilità e quanto rischio sei disposto ad accettare), potresti scegliere di presumere che un'app per iPhone che hai scritto ei suoi dati non possano essere manomesso dal malware o dall'utente umano, perché questo è il genere di cose che Apple sembra cercare di garantire, quindi puoi eseguire la decrittazione e assicurarti di eliminare i dati nel codice dopo.

(Puoi sempre immaginare un dispositivo meticolosamente protetto e controllato che ti sei fatto se l'iPhone si sente troppo insicuro o inaffidabile per te.)

Questo non rimuove il "buco analogico" se mostri quei dati all'utente o altrimenti li diffondi in modo osservabile, ma ciò potrebbe essere accettabile per alcuni casi d'uso, ad esempio forse non lo stai mostrando all'utente, ma solo usando i dati decrittografati come parte di uno schema di sicurezza nei dettagli di implementazione che l'utente non ha bisogno di vedere direttamente.

Possiamo estendere questo esempio alla trasmissione dei dati: potresti inviare i dati crittografati attraverso un canale di dati, la chiave attraverso un altro e fintanto che ritieni che almeno uno di quei canali sia sicuro e per non conservare i dati passati attraverso di esso, o puoi fidarti che qualsiasi intermediario che può origliare su un canale non sarà mai in grado di passare informazioni a nessuno che può origliare sull'altro, quindi hai una buona garanzia che l'unico cosa che decifra mai è il codice del tuo client che collabora.

TL; DR : Se capisci perché in linea di principio non esiste una soluzione perfetta a questo problema, puoi identificare alcune situazioni dove puoi ottenerlo con probabilità abbastanza alte da essere a tuo agio nella pratica. Ma queste situazioni potrebbero non coincidere con ciò che speravi di fare.

Questa è una delle promesse della comunicazione quantistica: in teoria, poiché l'osservazione altera fondamentalmente gli stati quantistici, sarebbe possibile creare un protocollo di comunicazione "read once".

Ovviamente, rimangono ancora problemi pratici come "l'utente può ancora scattare una foto del proprio schermo con il telefono".