Dipende dall'implementazione e dai requisiti di sicurezza. Ci sono soluzioni che non hanno back-channel, nel qual caso non puoi mai essere sicuro al 100% che i dati vengano ricevuti dall'altra parte. Si può cercare di compensare inviando i dati abbastanza spesso o con una correzione degli errori sufficiente, ma alla fine non si noterà se il sistema ricevente è semplicemente rotto - perché non c'è modo esplicito per ottenere riconoscimenti.
E poi ci sono soluzioni che cercano di trovare un diverso compromesso tra usabilità e sicurezza fornendo un back-channel minimo. Un prodotto che conosco più a fondo consiste di tre parti: un micro-kernel nel mezzo e i firewall su entrambi i lati del micro-kernel. La funzionalità unidirezionale è implementata utilizzando un task micro-kernel che utilizza solo un codice minimo e può quindi essere meglio controllato per la correttezza di funzionalità e robustezza. E su entrambi i lati di questo micro-kernel sono i firewall più complessi in cui le applicazioni traducono il traffico TCP, UDP, FTP o SMTP nel protocollo unidirezionale personalizzato trasferito dal micro-kernel e viceversa. Il back-channel minimo fornito da questo protocollo può segnalare solo successi o insuccessi che è sufficiente per fornire un feedback tempestivo, ad esempio nel caso in cui il ricevitore si arresti e non possa ricevere più dati o anche se il trasferimento FTP non è riuscito perché la password è sbagliata. Controllo del flusso TCP e caratteristiche simili sono implementate dalle applicazioni sul firewall e non viaggiano sul micro-kernel.
It seems that firewalls and proxy servers would pretty much do the same thing?
Non proprio vero e non proprio sbagliato. Più grande è la base di codice che implementa la funzionalità a senso unico essenziale più difficile diventa assicurarsi che ci sia davvero solo la strada a senso unico per comunicare. La cosa bella dei diodi dati basati su una proprietà fisica unidirezionale (come emettitore di luce e ricevitore) è che sono ovviamente a senso unico e possono essere bypassati solo se l'attaccante ha accesso fisico al sistema. Ma più si sposta la proprietà a senso unico dall'evidenza più difficile è assicurarsi che sia davvero solo a senso unico.
Ad esempio: con la fisica a una via si potrebbe ovviamente compromettere entrambi i lati del diodo ed essere sicuri che la proprietà a senso unico venga mantenuta. Con le soluzioni basate sul micro-kernel ho delineato i firewall su entrambi i lati potrebbe essere compromesso anche senza perdere la proprietà a senso unico. Ma andrà male se il micro-kernel venisse compromesso. Ma questo è considerato impossibile senza l'accesso fisico in questa soluzione perché il micro-kernel è proprio quello che dice: base di codice minimale, interazione con l'esterno solo attraverso l'attività a senso unico e questo compito minimo è sperabilmente sicuro contro gli exploit. Con una soluzione proxy su un singolo firewall, invece, sarebbe sufficiente compromettere questo firewall per aggirare la proprietà a senso unico. Dato che i firewall sono complessi, questo può essere considerato più probabile che sfruttare un micro-kernel o anche una separazione fisica.
Quindi: potresti ottenere funzionalità a senso unico usando una semplice soluzione proxy, ma è difficile dimostrare che funziona a senso unico in tutti i casi, anche se attaccato. E il mercato in cui vengono utilizzati i diodi di dati ha solitamente elevati requisiti di sicurezza e spesso richiede che tu non solo affermi che la tua soluzione è sicura e resistente agli attacchi, ma anche che puoi dimostrarla più o meno (es. Certificati, valutazioni indipendenti ...) . Ed evidente robustezza di design aiuta davvero in questo caso.