Re: Az első perctől titkosítja az adatokat az Android L
#21
Elküldve: 2014. 09. 20. 10:28
Vannak gyümölcsbor receptek normál (bóti sör (candida albicans)) élesztővel.
#22
Elküldve: 2014. 09. 20. 11:41
#23
Elküldve: 2014. 09. 20. 15:37
Úgy működik -feltehetőleg- mint az összes többi _transzparensz_ fájlrendszer-szintű titkosítás (pl. truecrypt) és -első körben legalábbis- kizárólag a telefon belső , ún. system particióját titkosítja sector-by-sector , block-by-block szinten... a külső médiumok titkosítása külön történik, illetve - természetesen ha lehetőséget adnak rá- egyazon kulccsal (jelszó, feloldópattern, pin és egyéb autentikációk)
A transzparens titkosításoknál belülről , magából a telefon OS-éből indítványozott másolási tranzakciók során a fájl szintű műveleteknél nem érinti a titkosítás, mivel az OS a fájlRENDSZER struktúrájára húz rá egy titkosító kulcsot.
#24
Elküldve: 2014. 09. 20. 15:40
#25
Elküldve: 2014. 09. 20. 15:47
különösen a mai világban, amikor már a processzorokban is van AES/Ni támogatás (legalábbis egyes inter processzorokban biztosan) ez végképp -szinte- semmiféle lassulást nem fog eredményezni.
Szerkesztette: Euro Glass 2014. 09. 20. 15:48 -kor
#26
Elküldve: 2014. 09. 21. 06:23
Ekkor az SD kártya fájlrendszere maradhat (pl. FAT32) és csak az /Android/ mappába telepített programokra kerül rá a kulcs fájlonként.. A legvalószínűbb hogy így oldották meg, legalábbis nekem ez a megoldás tűnik a legésszerűbbnek.
Így csak a rendszer és a rátelepített programok lesznek alapértelmezetten titkosítottak, és külön felhasználói interakcióval titkosítható a komplett SD kártya vagy akár egyenként is a rajta tárolt dokumentum jellegű fájlok, az SD kártya fájlrendszerének változása nélkül.
#27
Elküldve: 2014. 09. 21. 09:35
#28
Elküldve: 2014. 09. 21. 16:13
igy kb felesleges a microsd.
#29
Elküldve: 2014. 09. 21. 16:50
#30
Elküldve: 2014. 09. 21. 16:59
#31
Elküldve: 2014. 09. 22. 13:02
Idézet: auth.gabor - Dátum: 2014. 09. 20. 11:41
És hol láttad, hogy ezentúl majd feloldómintával is lehet titkosítani? Én pont azért nem akarnám ezt az automatikus titkosítást, mert a faxom fog kódokkal szarakodni minden feloldásnál.
#32
Elküldve: 2014. 09. 22. 13:13
Ez jelenleg így működik, legalább a 4.0 óta.
#33
Elküldve: 2014. 09. 22. 14:14
Ekkor az SD kártya fájlrendszere maradhat (pl. FAT32) és csak az /Android/ mappába telepített programokra kerül rá a kulcs fájlonként.. A legvalószínűbb hogy így oldották meg, legalábbis nekem ez a megoldás tűnik a legésszerűbbnek.
Így csak a rendszer és a rátelepített programok lesznek alapértelmezetten titkosítottak, és külön felhasználói interakcióval titkosítható a komplett SD kártya vagy akár egyenként is a rajta tárolt dokumentum jellegű fájlok, az SD kártya fájlrendszerének változása nélkül."
Ez így elég hebehurgyaságnak tűnik.
Nem egyszerűbb a sima dm-crypt?
A szokásos módon, vagyis indul a kernel a /boot-ból, és onnan felcsatolja a / és a /home partíciókat, a titkosított block device-okat (meg az SD kártyát) rámappelve a megfelelő mount pointokra.
File szinten minek sz4rakodni ezzel?
A file rendszer titkosítás (pl: encFS) milyen előnnyel jár a block device szintű titkosításhoz képest?
Valaki hozzáértő: Az Android L melyiket használja? dm-crypt, vagy encFS?
#34
Elküldve: 2014. 09. 22. 22:51
#35
Elküldve: 2014. 09. 23. 09:36
Másrészt nem kellett feltalálni, csak a már 3 éve létező dolgot alapban bekapcsolttá tenni.
#36
Elküldve: 2014. 09. 23. 10:58
Ugyanez igaz a Truecrypt és társaira is: jó, hogy ilyen kódolással használom, de ha megsérül, akkor kuka minden?
#37
Elküldve: 2014. 09. 23. 13:20
Alapvetően ha kiveszel a helyéről egy dm-cryp -el, vagy TrueCrypt -el titkosított kötetet (partíciót, disket, vagy egy több gigás filet) akkor azt bárhol máshol is fel tudod mountolni, gond nélkül.
Ha megsérül az állomány (vagy a hordozó hardver teljes titkosított disk esetén) akkor már a sérülés tipusától, a (belül) használt filerendszertől, valamint a titkosítás tipusától függ az adatvesztésed mértéke.
Ha a file eleje sérült meg, akkor jó eséllyel buktál mindent, mert az általad ismert jelszóval dekódolható kulcs az állomány elején van tárolva, valamint az inicializációs vector is itt van, ezek nélkül nincs miről beszélni. Néha biztonsági okokból az állomány végén is van másolat ezekről, éppen azért, mert kritikusak.
Hasonló a történet ahhoz, amikor van egy AVI filmed, de megsérül az eleje, mert akkor a pár bytos AVI header nélkül nem tudod lejátszani, akárhány giga jó adat is van mögötte.
Ha a file közepétől van a sérülés, akkor hasonlóan mint a filmeknél, egy darabig jó, aztán trágya jön a titkosított konténerből. Hogy mennyire van gáz, azt erősen befolyásolja a filerendszer, hogy az milyen (tipusú és mértékű) adatvesztést tud túlélni.
De a titkosítás alapvetően nem feladata biztosítani az adatok sérülése esetén az adatvisszaállítás lehetőségét. Az a file rendszer feladata, nameg a Kürt Computer Rendszerházé!