it-swarm-eu.dev

Schemi / meccanismi che potrebbero fornire la decrittazione di una volta?

Conosco abbastanza bene la maggior parte delle basi comuni di sicurezza per studenti/laurea; ma non sono riuscito a trovare nulla di simile a questo scenario:

Uno schema/sistema in cui un pezzo di dati può essere "decrittografato" E letto solo una volta (potenzialmente in un programma per computer).

È anche possibile? Ho sentito che cose simili ci sono nel "mondo hardware" (?). Se la mia domanda è imprecisa/incompleta, sono disposto ad aggiornare. Ma in realtà sono interessato a un design/protocollo generico allo stesso tempo.

38
DaveIdito

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. Può essere possibile uno dei seguenti:

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

L'unico modo in cui potresti avvicinarti sarebbe avere il controllo totale su hardware e software, quindi potresti eliminarlo una volta che è stato 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.

62
Rory Alsop

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

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

Tale approccio, ovviamente, può essere vittima di manomissioni: un utente malintenzionato può manipolare il sistema in modo che la cancellazione non riesca, 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 da leggere anche le informazioni. Questo è, in effetti, ciò che rende sicura la crittografia quantistica in gran parte teorica: non è possibile intercettare (ascoltare) senza distruggere le informazioni, rivelando così il fatto che qualcuno sta intercettando il messaggio.

Al di fuori del regno quantico, potrebbero esserci soluzioni che utilizzano processi chimici o altri processi fisici, ma saranno anche soggetti a manomissione.

25
Tom

Se è disponibile una rete, è possibile scaricare la procedura di decrittazione (e la chiave privata) su un servizio in esecuzione su un server sicuro. È quindi possibile applicare le regole desiderate sul server.

Il client avrebbe inviato il testo opaco al servizio e gli avrebbe chiesto di decrittografarlo e restituire il contenuto in chiaro, e il server avrebbe potuto decidere se consentire il client in base alla cronologia di decrittazione, bloccando potenzialmente più di un'operazione di decrittazione.

Tuttavia non ci sarebbe nulla che impedisca al chiamante di utilizzare il risultato della decodifica più e più volte, che è più o meno lo stesso della decodifica più e più volte . Ci sono stati tentativi di farlo 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 di ingresso, o anche semplicemente puntare una videocamera HD verso il monitor e registrare il contenuto mentre viene riprodotto. Una tecnica di intercettazione simile potrebbe essere utilizzata per qualsiasi tipo di contenuto digitale. Quindi la linea di fondo è ... no, non è davvero possibile.

Un approccio più fattibile sarebbe quello di inserire un numero seriale nel contenuto stesso e di rintracciarlo in un server di autorizzazione, oppure di infornare in un timestamp di scadenza. Dovresti quindi far valere ciò sul lato ricevente, che dovrebbe essere un'applicazione sicura. Ecco come funziona na volta la password , ad esempio. Ma ciò richiede di possedere entrambe le estremità del percorso dei dati e che i dati stessi siano inutili al di fuori di esso.

10
John Wu

Non è in alcun modo pratico e fondamentalmente impossibile (in modo affidabile), ma potrebbe essere possibile in qualche misura .

L'ovvio impedimento che rende fondamentalmente impossibile lo sforzo è che qualunque cosa tu decifri, una volta letto, è nella tua testa. Quindi, per essere sicuro che il segreto rimanga segreto, dovrebbe esserci una sorta di meccanismo di pillola avvelenata. Forse una capsula che contiene un motore TTS e ti trasmette il messaggio attraverso la conduzione ossea, quindi esplode, soffiandoti la testa.
Perché, sai, finché respiri, puoi dirlo a qualcuno. Speriamo comunque di non ripetere ad alta voce ciò che il TTS ti sta sussurrando in testa.

A parte questo, esistono sistemi di archiviazione dei dati che possono essere letti una sola volta. DRAM e Ferroelectric RAM come alternativa non volatile ne sono due esempi. Questi richiedono un esplicito built-in-read-read-built-in o qualcosa di diverso (ad es. Circuito condensatore). Altrimenti, la lettura delle informazioni distrugge le informazioni. Lasciatele fuori e avete fatto un grande passo avanti.
Ora, almeno, si dovrebbero fare due copie (una su un archivio di lettura non distruttiva, e poi un'altra per averne effettivamente una copia). Tuttavia, è abbastanza nel regno di "fattibile", ma a seconda della compatibilità hardware potrebbe comunque essere un po '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 molto beh sia che si rivela un po 'più difficile di così!). Ma non siamo alla fine.

La chiave di decrittazione e anche parte dell'eseguibile di decrittazione completo (supponendo che i loop siano srotolati) potrebbe anche essere archiviata su un archivio di lettura distruttiva all'interno dell'hardware di decrittazione. La chiave di decrittazione non deve mai lasciare il chip, quindi a parte i "dati" non devono esserci corsie per trasmetterlo. Viene letto durante la decrittazione e dopo non c'è più. Quindi ... eccoti.

A meno che non si supponga che qualcuno possa praticare fori della dimensione di alcune decine di nanometri nel chip e utilizzare nano-fili per intercettare in qualche modo l'archiviazione, non c'è modo di accedere ai dati. Non sto dicendo che è impossibile, solo ... che è un po 'folle. Nessuna informazione è abbastanza preziosa da giustificarla. Inoltre, immagino che potrebbe essere una procedura piuttosto rischiosa poiché accidentalmente perdere una piccola carica o andare di qualche nanometro troppo a sinistra o a destra inevitabilmente distruggerà anche la chiave.

Poiché la chiave di decrittazione è in genere molto piccola (32 byte o meno), potrebbe in effetti essere memorizzata all'interno di un processore di enclave sicuro o simile, come avviene di solito in molti dispositivi mobili al giorno d'oggi. Tale archiviazione potrebbe anche avere letture distruttive (e nessun accesso esterno ai dati enclaved, proprio come su tutti i telefoni moderni). Ma non è nemmeno necessario.
Potresti avere fusibili come nel Samsung Knox o nel 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, quante ne desideri). Successivamente, il processore semplicemente non aggiorna (o sovrascrive esplicitamente) la chiave. O, molto meno sicuro (ma probabilmente ancora abbastanza buono), rifiuta solo di decifrare .
Pertanto, fare una copia dei dati crittografati non funzionerà molto perché non è possibile decrittografare la copia.

Certo, qualcuno può ancora banalmente copiare i dati decifrati , se ci sono mezzi per farlo. Di solito ci sono, sia digitali che analogici. Se non altro, puoi avere due o tre persone che guardano lo schermo contemporaneamente o scattare una foto.

Questo, tuttavia, è un problema che non si può sostanzialmente risolvere (se non con un dispositivo che esplode o un dispositivo che rilascia gas nervoso).

2
Damon

Da un senso puramente teorico - è possibile solo se puoi assicurarti che dopo la prima decodifica non ci siano copie esistenti di entrambi

  1. i dati decrittografati e
  2. no i dati crittografati o le chiavi necessarie per decrittografarli.

In linea di principio, puoi farlo solo con cooperazione (disponibile o forzato) delle parti che gestiscono queste informazioni che devono essere eliminate.

In pratica, questo può essere sufficiente a seconda di ciò che si desidera ottenere e di quali componenti del sistema si è disposti a fidarsi.

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

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

Questo non rimuove il "buco analogico" se stai mostrando quei dati all'utente o altrimenti li perdi in modo osservabile, ma ciò potrebbe essere accettabile per alcuni casi d'uso - ad esempio forse non li stai mostrando all'utente, ma solo utilizzando i dati decrittografati come parte di alcuni schemi di sicurezza nei dettagli di implementazione che l'utente non deve vedere direttamente.

Possiamo estendere questo esempio alla trasmissione di dati : potresti inviare i dati crittografati attraverso un canale di dati, la chiave attraverso un altro e fino a quando ti fidi di almeno uno di quei canali per essere sicuro e non conservare i dati passati attraverso di esso, oppure puoi fidarti che qualsiasi intermediario che può intercettare su un canale non sarà mai in grado di trasmettere informazioni a chiunque possa intercettare sull'altro, quindi hai una discreta garanzia che l'unica cosa che lo decodifica mai è il tuo codice cliente cooperante.

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

1
mtraceur

Questa è una delle promesse della comunicazione quantistica - in teoria, poiché l'osservazione altera sostanzialmente gli stati quantistici, sarebbe possibile creare un protocollo di comunicazione "leggi una volta".

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

0