Podatkovna dioda

Zanima me, če je že kdo izdelal kakšno podatkovno diodo v DIY stilu in kako ste se zadeve lotili.
Unidirectional network @ Wikipedia

V mislih sem imel, da bi uporabil kar optični S/PDIF port, ki ga imajo nekateri računalniki, pa bi preko njih pošiljal podatke na ploščo, ki ima samo sprejemnik. Zanima me pa kakšen protokol bi lahko tule uporabil. Obe plošči imata ethernet porte, samo klasični TCP tule ne pride v poštev zaradi samoumevnih razlogov. Verjetno bi pa šlo preko UDP protokola? Moram še malo preštudirati opcije.

Kaj pa ostali?

lp

Aha, z zadevo se ukvarjam bolj tako kot zanimivost v moji elektro delavnici.
Kaj pa na SI-CERT se kdo ukvarja s takimi zadevami?

Ribič je 17. feb 2015 ob 15:52 izjavil:

V mislih sem imel, da bi uporabil kar optični S/PDIF port, ki ga imajo nekateri računalniki, pa bi preko njih pošiljal podatke na ploščo, ki ima samo sprejemnik.

Hmm... ta bi bila zanimivia, ampak verjetno ne boš našel vmesnika, ki ga bi lahko neposredno krmilil, kar pomeni, da bi moral zaupati kar pravilni pretvorbi. Bi pa S/PDIF vrata zagotovo zadostila zahtevi enosmernosti.

Ribič je 17. feb 2015 ob 15:52 izjavil:

Zanima me pa kakšen protokol bi lahko tule uporabil. Obe plošči imata ethernet porte, samo klasični TCP tule ne pride v poštev zaradi samoumevnih razlogov. Verjetno bi pa šlo preko UDP protokola? Moram še malo preštudirati opcije.

Kaj točno te bolj zanima oziroma veseli? Izdelava enosmerne strojne rešitve, kjer je možen tok informacij samo in izključno v eno smer, ali izdelava protokola, ki bo uporabljal različne metode varovanja podatkov med prenosom, da se ti ne bodo izgubljali, čeprav ni možno zahtevati ponovne oddaje podatkov.

SeMiNeSanja je 17. feb 2015 ob 17:20 izjavil:

SI-CERT? Se ti hecaš?

Oni spadajo pod Arnes, tam pa velja načelo "If it's not Cisco, than it doesn't exist".

Uh je nekdo pojedel vso pamet tega sveta, pa mu je malo škodilo.

@Ribič - jaz sem 'v živo' videl samo Diode enega proizvajalca. Te so dejansko v svojem jedru premetavale podatke z enega omrežja na drugega s pomočjo optike.

S/PDIF je v tem smislu uporaben kot 'transmitter', zatakne pa se pri 'recieverju', ki bi ga moral naresti. Poraja pa se tudi vprašanje, kolikšno podatkovno prepustnost bi lahko dosegel na S/PIDF portu.
Seveda potem še ostane vprašanje protokola, ki ga je že omenil AndrejO.

AndrejO - tisti odgovor je veljal zgolj tebi 'v pojasnilo', ker si se obregnil ob moj komentar. Ne vem pa od kod si potegnil, da 'nespoštljivo' pišem OP-u. Tudi to, če koga poznam ali ne na CERT-u, kar nekaj insinuiraš. Tu bi tudi jaz lahko postavil pod vprašaj tvoje spoštovanje tujih mnenj. Pa ne bom, ker to ne prispeva k topicu.

Ribiču sem pa namenil drug odgovor 'on topic'.

Mogoče nekaj 'dvokanalnega', pri čemur bi drugi kanal služil izključno za XON/XOFF ali pa kaj kompleksnejšega za regulacijo pretoka podatkov, morda celo error control.

Ne vem sicer, če potem stvar še ustreza definiciji 'diode'. Vendar če je vsa stvar striktno omejena na enosmerni DATA flow, medtem ko drugi kanal skrbi izključno za njegovo regulacijo in ne posreduje podatkov, je vse skupaj vsaj načeloma še vedno v tem konceptu?

Brez nadzora pretoka podatkov pa si jaz teško predstavljam zadevo. Nekako mora stran A vedeti, da je na B strani zadeva nared za sprejemanje podatkov, sicer lahko pošilja podatke v nič. Glede na to, kje in zakaj se uporabljajo takšne diode, pa so običajno s tem izgubljeni tudi izhodiščni podatki (če npr. izvajamo logiranje nekih zaupnih podatkov direktno preko diode na zaščiteni strežnik).

Pri HW sem bolj kratek, tako da ti bo moral za sprejemnik + oddajnik pomagati kdo drug, če še nisi sam tega natuhtal.

Kar se tiče pretvorbe poti iz črnega (nezaščiteno) v rdeče (zaščiteno) omrežje je UDP res ena možna izbira, ne pa edina ali najboljša. Varen prehod (diodo) glej kot na proxy na katerega se povežeta črni in rdeči odjemalec, vsak na svojem omrežju, oba pa lahko uporabljata TCP, da ne boš še v IP omrežju dodatno izgubljal paketov. Če uporabiš TCP, potem si lahko zamisliš še naslednji korak, ki ti omogoča sočasno podporo večim pošiljateljem in prejemnikom.

Torej bi lahko bila fizična vezava nekako takšna:
{rdeče omrežje} <----_(ethernet)----> {rdeči proxy} ----^(toslink)----> {črni proxy} &lt----_(ethernet)----> {črno omrežje}

Komunikacija s strani rdečega odjemalca bi lahko nato potekala recimo tako:
- Rdeči odjemalec se poveže na rdeči proxy (TCP).
- V tej povezavi rdečem proxyu sporoči ID črnega prejemnika, ki naj bo naslovnik podatkov (ali pa določiš ta ID iz same povezave).
- Pošilja podatke (še vedno preko TCP) za katere verjame, da jih bo rdeči proxy pravilno posredoval naprej.

Pri tem pristopu ti tako TCP zagotavlja, da podatkov pri prenosu med rdečim pošiljateljem in proxyem ne boš izgubljal.

Komunikacija s strani rdečega proxya je nato "klasična" pretvorba na nižji nivo komunikacije. Tukaj si lahko recimo izmisliš svoj Protocol Data Unit (PDU). Ta PDU bi lahko zaradi fizične enosmernosti vseboval sledeče podatke:
- prolog, epilog da bo prejemnik vedel kje se začne in konča okvir (če me spomin ne vara, je toslink sinhron, pri asinhronem je to možno izpustiti, vendar napovedani dolžini paketa ne moreš vedno zaupati - lahko je prišlo do bit flipa pri prenosu le te)
- dolžina PDU
- koda tipa PDU (da lahko sporočiš dogodke, kot so npr. "nov pošiljatelj", "konec prenosa", "podatkovni blok", ipd.)
- podatek o ID črnega prejemnika
- podatek o ID rdečega pošiljatelja (da lahko črni prejemnik razloči več sočasnih pošiljateljev)
- blok podatkov

Ko rdeči proxy prejema tok (stream) podatkov preko TCP, jih mora "paketizirati", kjer si boš izbral neko poljubno maksimalno dolžino PDU ali čas po katerem boš pač poslal, kar imaš v začasnem pomniniku (bufferju).

Potem pa imaš na izbiro nekaj možnosti.

Vsak PDU lahko nosi zaporedno številko + kontrolno kodo (checksum) in pri pošiljanju vsakega nekajkrat ponoviš. Tako bo črni proxy vedel (in znal opozoriti) na izgubljene pakete, podvojene pa bo lahko po uspešnem prejemu ignoriral (ali pa uproabil za zaznavanje multi-bit napak, ki bi pobegnile kontrolni kodi). Tukaj si lahko pri obnavljanju podatkov zelo kreativen in zanesljivost zelo povečaš.

Lahko pa greš v drugo smer in vsakem paketu dodaš še dodatne podatke s katerimi lahko določeno količino napak pri enkratnem prenosu dejansko obnoviš. ECC je en takšen algoritem, ki ti omogoča popraviti single bit flip. V tem kontekstu si lahko pogledaš zelo popularen Reed-Solomon, lahko pa po literaturi pobrskaš za še kakšno zanimivo stvar. Išči predvsem v smeri komunikacij z sateliti v "deep space", kjer je komunikacija skoraj enosmerna, pasovna širina pa zelo dragocena in so zato podvajanje ali celo ponovitev celotnega prenosa skrajno nezaželjeni.

Seveda lahko oba pristopa tudi združiš. Bi se pa pri združevanju moral vsesti in izračunati kakšna bo tako pridobljena zanesljivost glede na tako potrošeno pasovno širino.


Črni proxy ima lahko npr. seznam črnih prejemnikov (ID prejemnika + njegov IP naslov + njegova TCP vrata, kjer prejemnik posluša). Ko prejme PDU tipa "začetek prenosa" od novega odjemalca lahko vzpostavi novo TCP povezavo do črnega prejemnika, ki ima ta določen ID. Za vsak "data" PDU nato preveri, če so bili podatki pravilno prenešeni (se igra z popravljanjem izgubljenih bitkov) in, ko je ugotovil, da ima pravilen blok podatkov, lahko te podatke preko TCP povezave posreduje prejemniku. To ponavlja vse, dokler ne naleti na PDU blok, ki ga ne more pravilno dekodirati ali pa prejme PDU "konec prenosa". V obeh primerih zapre TCP povezavo, da tudi črnem prejemniku sporoči, da je bil prenos zaključen.

Ko imaš to izdelano, imaš narejen enosmeren transportni protokol. Takšnega ga lahko uprabiš za čisto generično komunikacijo, dokler je ta enosmerna. Čisto pravi FTP ne boš mogel narediti zaradi enosmernosti, lahko pa boš naredil enosmeren prenos datotek in za njih boš lahko na strani prejemnika tudi z visoko stopnjo zanesljivosti povedal, če je bil prenos uspešen ali ne.

Veliko detajlov sem izpustil in nekatere dele razmišljanja tudi poenostavil. Predstavljena ideja tudi ni edina možna, ravno tako si lahko veliko stvari poenostaviš, če ti je cilj implementacija z mikrokontrolerjem namesto s kakšnim malo bolj "standardnim" računalnikom, kjer že imaš OS, ki skrbi za vso TCP/IP komunikacijo.

Ideja je vsekakor zanimiva in, če to ji uspe izpeljati, ni rečeno, da je ne bi uspel tudi prodati. Če ne to, pa vsaj znanje in izkušnje, ki jih boš pri temu dobil.

BTW: na RasPI imaš GPIO vrata, ki bi morala zadoščati za osnovno komunikacijo. Ne vem pa s kako hitro lahko prek teh signaliziraš.

Za ARM & prijatelje, ki ti šenkajo polno Linux jedro, palec gor. Ko sem prebral mikrokontroler, mi je bila prva reakcija nekaj tipa Arduino.

Predlagam ti tudi, da si projekt razbiješ na manjše zaključene sklope. Npr. prenos bloka podatkov preko optike je en zaključen sklop. Naslednji sklop je koda, ki bo pripravila PDU in ga predala prejšnjem sklopu za "oddajanje" in koda, ki bo od prejšnjega sklopa prejela blok in na njim izvedla "magijo" ECC preverjanja in ostalega potrebnega za omejevanje in odpravljanje napak.

In tako naprej... Priporočam ti, da si celotno stvar predstavljaš kot pristop "OSI slojev", kjer za vsakega dobro veš kaj je njegova naloga, do neke mere pa jih lahko tudi izmenjuješ. Če npr. "fiziko" implementiraš z MC, ki bo pred "višjimi" sloji skril razliko med sinhrono/asinhrono in golim "framingom", potem lahko testni toslink kadarkoli zamenjaš z npr. enosmernim 1000BASE-SX vmesnikom (predstavljaj si optiko, kjer LC transciever "razrežeš" in imaš na eni strani samo oddajnik, na drugi pa samo sprejemnik).

Če se ti pri razmišljanju kje zatakne, ali pa nisi prepričan kako potegniti meje med sloji, pa povej in lahko staknemo glave skupaj in najdemo rešitev ali rešitve.

Sam bi si sloje zastavil nekako tako (prosto po Prešernu, to niso OSI sloji):
- L1: fizika: iz L2 prejmem blok za poslati, na L2 pošljem prejet blok, kakršen koli že je.
- L2: kontrola napak: iz L3 prejmem blok, ki ga opremim z redundanco, na L3 pošljem prejet blok, ki je uspešno prestal nadzor in odpravo napak.
- L3: packetizer: iz L4 prejemam tok podatkov, ki ga opremim z informacijami o prejemniku/pošiljatelju, na L4 sprotno pošiljam podatke pravem prejemniku. Tukaj se dogaja tudi približek, tega kar OS kernel pri TCP skladu vidi kot "socket".
- L4: seja: iz L5 prejemam zahtevke za vzpostavitev povezave (incoming TCP), na L5 pošiljam zahtevke za povezavo (outgoing TCP).
- L5: zunanje viden proxy: upravljam zunanje TCP povezave ter odpiram seje na L4 oziroma se odzivam na zahtevke za odpiranje zunanjih povezav.

Kot si že sam pravilno ugotovil, oddajnik napak ali statusov ne more dobiti in bo vedno oddajal "v temo", saj bi lahko konceptualno kakršen koli signal, vključno z "link up" uporabil kot povratno zanko za sporočanje informacije v obratno smer. To je tudi razlog zakaj tega ne moreš enostavno realizirati z električno povezavo. Kvečjemu elektro-optično ali elektro-mehansko, kjer optičen oz. mehanski prehod zagotovi enosmernost. Te omejitve pa nimaš na strani prejemnika in to je tudi tista stran, ki bo obveščala o napakah na povezavi. Vse, kar potrebuješ je samo "kanarček", katerega odsotnost bo pomenila signal, da je s povezavo nekaj narobe.

"Kanračka" lahko po moji shemi dodaš npr. na L3 z oddajanjem posebnega PDU, katerih odsotnost pri prejemanju bo na črni strani pomenila napako na povezavi. Alternativno lahko to zagotoviš tudi na L1, če izgubiš npr. sinhronizacijo, ali pa začneš pogrešati L1 heartbeat okvirje. Če imaš opravka s klasičnim optičnim sprejemnikom, pa lahko zaznaš tudi loss of signal.

No, dejansko je računsko lažje preveriti hash, kot pa podpis, saj slednje vključuje najprej hash, nato pa še šifriranje z asimetrično kodo. Če imaš za to (PGP ali kakšno podobno) knjižnico, je tudi tvoj pristop OK, ni ta to optimalen način.

Tako čisto mimogrede... Za RAR imam v spominu, da je imel možnost dodajanja redundance s katero je lahko arhiv obnovil tudi, če je pri shranjevanju prišlo do napake (spomni se na diskete ). Če najdeš način kako spraviti skozi tega, potem imaš na en mah rešena dva problema. Redundanco za obnovo podatkov brez ponovnega prenosa in preverjanje pravilnosti prenosa. Pa verjetno RAR ni edini, ki je imel/ima to možnost.

Ravno tako je od tebe odvisno kje točno iščeš izziv oziroma v kaj se želiš fokusirati. Vendar pa preverjanje vsakega PDU-ja posebej prinese poleg več dela tudi globji razmislek o preprečevanju napak brez prevelike količine režije. Kar je nekaj, kar je meni zanimivo, ostalim pa morda tudi ne.

Vsekakor se da narediti veliko in uporabiti bližnjice tam, kjer te zadeva ne zanima.

AndrejO je 18. feb 2015 ob 00:34 izjavil:

No, dejansko je računsko lažje preveriti hash, kot pa podpis, saj slednje vključuje najprej hash, nato pa še šifriranje z asimetrično kodo. Če imaš za to (PGP ali kakšno podobno) knjižnico, je tudi tvoj pristop OK, ni ta to optimalen način.

Teoretično na sprejemniku ne moreš pa preveriti, da je izvor teh podatkov res TX-proxy. Lahko nekdo prestreže linijo in injektira svoje podatke v vod. Hash se pa vsak da čisto enostavno ponarediti. Sicer je pa nedavno nazaj izšel GnuPG v2.1.x, ki ima podporo za ECC podpise tipa Ed25519, ki so dosti hitrejši od RSA. Pa saj bi tudi RSA bila vredu, ker ne bomo tovorili nevem kakšnih gromozanskih količin podatkov.

Za RAR mislim, da linux nima knjižnice za kompresijo, ker so baje neki neugodni licenšni pogoji? Ne vem, nikoli se nisem kaj pretirano ukvarjal z RAR-i. Odkar sem našel 7-Zip, živim srečno in veselo.

Dobro, vidim, da je tule en kup stvari, ki jih bo potrebno še premisliti preden grem naprej.

Podoben projekt in debata z uporabo 2x rPI + CD4050 buffer:

http://www.raspberrypi.org/forums/viewt...

Živjo!

Za začetek se bi lotil nečesa takega: USB vmesnik med računalnikom in USB ključem. Zadeva preprečuje, da bi kakšni koli podatki prišli iz ključa na računalnik, v obratno smer pa je pretok informaciji dovoljen. Stvar deluje tako, da uporablja dva krmilnika (ločeno napajanje), ki sta povezana z optocoupler-jem in komunicirata preko SPI protokola (signal CLK in MOSI). Ob vklopu v računlanik se vmesnik predstavi kot prazen USB ključ. Uporabnik nato v explorerju na ta "ključ" kopira razne datoteke, ki s časoma izginejo (to pomeni, da so bile poslane na drugo stran).

Krmilnik na drugi strani pa preko SPI protokola podatke prejema in jih kopira na "pravi" USB ključ. Seveda jih tudi preveri, da med prenosom ni prišlo do napake. Ko poteka prenos, utripa rumena ledica, ko pa je prenos končan brez napak, se prižge zelena ledica, sicer pa rdeča. Premisliti bi moral kakšne krmilnike potrebujem. Verjetno bo potrebno nekaj, kar se je sposobno pretvarjati kot USB Mass Storage Device in ima dovolj rama. Na drugi strani pa krmilnik, ki zopet prepozna datotečni sistem na USB ključu oz. trem disku (fat, ntfs, ext3, ext4, xfs, btrfs, itd).

Sliši se simpl ampak se mi zdi, da bo kar veliko dela s tem.