( nikin | 2010. 12. 15., sze – 22:40 )

Ezt én nem értem.. de majd valaki remélem felvilágosít

Ugye vannak titkosítási algoritmusok. Ezeknek a működése jellemzően matematikailag
levezetett. Amikor egy ilyet valaki beépít egy titkosító szoftverbe, akkor annak is megvan a menete.
Legegyszerűbb forgatókönyv szerint így néz ki:
-A fogom az adatot. és x mennyiséget betöltök a memóriába.
-Fogok némi random számot (legtöbb titkosításnál kell)
-Fogom a kulcsot, ill. annak valamilyen módosított változatát. És az algoritmus használatával titkosítom az adatot. Ekkor van egy új adatom ami a raw titkosított forma.
Egészen eddig a szoftveren belül maradok. A hálókártya mit sem tud erről. Ha nem valamilyen hardveresen támogatott titkosítást használok akkor a rendszer többi részegysége sem. Azok csak "matekoznak".
-Az így létrejött adatot előkészítem (titkosítástól független tevékenység) és beletolom a csőbe a hálókártyának, hogy HUSS.
Amikor a kártya először látja az adatot, akkor már titkosítva van. Tehát az én logikám szerint ha maga az algoritmus nem tartalmaz backdoor-t akkor akárhány helyre is küldi el a kártya a csomagot. Minden fogadó fél szembesül a titkosítással. És ha feltételezzük hogy az algoritmus és az implementáció tiszta, akkor csak az ismeri meg az üzenetünk tartalmát, akinek birtokában van a kulcs.

Ugye ha csak az FBI nem tanult meg k gyorsan faktorálni integereket. Akkor az egyetlen út, hogy valahogy kisunnyogja a kód a kulcsot.
Na mármost a kulcs ebben az esetben ugye egy változóban van benne. Szélesebb nézőpontból egy memóriacímen csücsül.
Ahhoz, hogy leakelhető legyen a kulcs. valakinek, valahol valamikor
A) Ki kell olvasnia adatot a megadott memóriacímről.
B) Ki kell adnia a memóriacímet egy másik program részére aki megkerüli a memóriavédelmet és kiolvassa azt onnan. DMA?
Az A) esetben ugye elvben a kulcshoz csak magának a titkosító eljárásnak, és a bekérő eljárásnak van köze.
Egy egyszerűbb RSA implementáció C++ ban kevesebb mint 200 sor. És egy ismert, jól leírt matematikai feladatot hajt végre. (viszonylag könnyen auditálható).
Ha bárki más hozzányúl az adott címhez, na az gond. És avval komolyan foglalkozni kell.
Mindkét esetben igaz, hogy amire figyelni kell az annak a változónak a viszontagságos élete, amiben a kulcsot tároljuk.
Illetve fontos lehet megfigyelni még bármilyen kifelé menő kommunikációt. IPC, IO.
Továbbá a kulcsfájl életét. (aszimmetrikus titkosítás (RSA pl.) esetén nem játszik... ill mégis mivel az általában csak a kommunikáció előkészítésénél használatos. utána azon keresztül megegyeznek egy szimmetrikus kulcsban. Ami ha fájlként nem is de a memóriában ott van, és az adat evvel kerül titkosításra. Továbbá fogadó félként itt is van kulcsfájl)

Ez lehet ugye egy audit célja.

Példának okáért feltesszük az OS-t egy olyan gépre, ahol minden memória-hozzáférés naplózható (paraszt megoldásként egy olyan virtuális gép ami memória helyett is csak diszket használ. Ott az írás olvasás tutira megfigyelhető)

Kicsit más.

Logikailag érthető, hogy olyan intézmények akiknek a feladata, hogy mindenről tudjanak, megpróbálják ezt ellátni. De a backdoor-okkal jellemző probléma, hogy előbb-utóbb nem csak az használja őket aki berakta őket.

Amennyiben paranoid nézőpontból közelítünk egy ilyen problémához, úgy az egyetlen járható út az egyszerűség. Olyan alkalmazásokat kell készíteni aminek minden rétege ugye jól elkülönül egymástól. És csak egy adott API-n keresztül kommunikálnak. Továbbá az adatok áramlása nyomonkövethető. Egy ilyen rendszer természetesen komoly teljesítménybeli hátrányokkal küzdhet. De ez a biztonság ára.
Adott esetben saját hardware-t kell építeni. Pl egy olyan eszközt ami USB-re dugva működik. Azon az elven, hogy amit az egyik portba beleböfögök. az a másikon egy mondjuk SD kártyán / lyukszalagon tárolt kulccsal titkosítódva jön vissza. Ha az algoritmus bizonyítottan nem érzékeny a known plain text típusú támadásokra akkor máris megvagyunk. Egy ilyen eszköz OpenSource megvalósítása valószínűleg nem is lenne vészesen drága. és mivel egy megfigyelhető interfészen keresztül kommunikál csupán. így egy referencia eszközzel validálva máris garantáltan leak mentes.
Ennek az eszközben egyszerűnek kell lennie mint a satu. Nem tudhat semmi többet mint amit muszáj. Az alap feladaton kívül csak három dolga van.
1: logoljon minden tranzakciót.
2: legyen benne valamilyen strict self check
3: Amikor csinál valamit akkor ezt kommunikálja a user felé.
Na kb. ennyi. Várom a javításokat, ilyesmiket. El lehet engem küldeni jó messzire :P

### ()__))____________)~~~ ################
#"Ha én veletek, ki ellenetek?"#N210/Xubu