[Tassadar]

@Georgexy: Kizártnak tartom, hogy a kulcsot ne lehessen exportálni.

[auth.gabor]

Végre. Egyszerûen nem értettem, hogy miért az az alapértelmezett, hogy például az SD kártyát csak akkor lehet titkosítani, ha jelszót használok, mert a feloldóminta nem elég biztonságos... nekem meg csak annyi igényem lett volna, hogy ha valaki kiveszi az SD kártyát, akkor ne lehessen csak úgy lemásolni a rajta lévõ dolgokat.

[Euro Glass]

@Asker: "es hogy mukodik ez az egész?"

Ú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.

[Euro Glass]

@Euro Glass: itt jegyezeném meg, hogy az SD kártya fájlrendszer szintû titkosítása azért nem szerencsés, mert ekkor külsõ eszközbe csatlakoztatva (tkp. rádugva egy PC-re) RAW, nyers , vagy hibás fájlrendszerként azonosítja az adathordozót és egy bit nem sok de annyi inforámciót nem tudunk belõle kinyerni a kulcs nélkül, amit viszont a telefon jó mélyen valahol a boot particióján tárol , a belsõ , integrált adathordozóján.

[Euro Glass]

@Totó779: számszerûsítve a dolgokat, nálam egy ezrelék alatti "lassulás" tapasztalható AES256 cipher esetén és ugyanúgy 30MB/s az adatátviteli sebesség van az asus phison OB SSD-n. cascade of ciphers esetén már talán érezhetõ is lassulás..

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

[Euro Glass]

Annyit fûznék még hozzá, hogy titkosított system partició esetén, van még lehetõség az SD kártyán lévõ fájlok fájlszintû titkosítására is, akár egyazon titkosító-kulccsal is.

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.

[Euro Glass]

... Más kérdés, hogy szinte borítékolható, hogy az NSA eleve hozzá tud férni, ilyen-olyan kódhibán , vagy hátsó kapun (stb.) keresztül a titkosított adatokhoz is...

[Asker]

fasza. az ember telefonja elazott akk is nyugodt volt h a microsdnek ugyse lesz baja.
igy kb felesleges a microsd.

[Modeller]

@Asker: igen, ez akkor volna használható megoldás, ha a titkositó kulcs és algoritmus elérhetõ lenne winre, tehát telefonból kiveszed a kártyát és a jelszó birtokában egy programmal dekódolni tudod a tartalmát a gépeden. Anélkül kb. használhatatlan.

[Totó779]

@Euro Glass: Na jó, hát ez nem kérdés. Úgy tudom amcsiknál törvény kötelezi a gyártókat, hogy biztosítaniuk kell kiskaput a titkosító algoritmusok mellé. Anélkül asszem ki sem adhatnak kódoló progikat, eljárásokat. Ha mégis megteszik, nagyon megfingatják õket. Szóval ez nem ellenük véd. Inkább a tolvajok, ipari kémkedés ellen. Stb.

[[Iron]]

Idézet: auth.gabor - Dátum: 2014. 09. 20. 11:41

Végre. Egyszerûen nem értettem, hogy miért az az alapértelmezett, hogy például az SD kártyát csak akkor lehet titkosítani, ha jelszót használok, mert a feloldóminta nem elég biztonságos... nekem meg csak annyi igényem lett volna, hogy ha valaki kiveszi az SD kártyát, akkor ne lehessen csak úgy lemásolni a rajta lévõ dolgokat.

É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.

[montyx]

azt nem tudom, hogy a titkosítás hogyan fog működni, de az biztos, hogy amíg a telefon lockolva van, addig a felcsatolt telefon meghajtó üres mappát mutat. ha valaki a telefonon beírja a PINt, akkor már látszik az internal storage mappa.

Ez jelenleg így működik, legalább a 4.0 óta.

[YleGreg]

@Euro Glass: "Annyit fûznék még hozzá, hogy titkosított system partició esetén, van még lehetõség az SD kártyán lévõ fájlok fájlszintû titkosítására is, akár egyazon titkosító-kulccsal is.
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?

[lugosi]

Nahát, az android fejlesztõk feltalálták azt, amit a blackberrynél már hány éve is alkalmaznak? :/

[YleGreg]

@lugosi: Egyrészt igen, egyre komolyabbá válik az Android.

Másrészt nem kellett feltalálni, csak a már 3 éve létezõ dolgot alapban bekapcsolttá tenni.

[Mykee]

A kódolástól egy dolog miatt tartok, ami mondjuk a DRM esetében is gond pl. egy digitális felvevõnél (pl. UPC): ha kiszeded belõle a háttértárat, mert megsérül a hardver, akkor lesz-e lehetõség a feloldásra? Mert említettétek az SD kártyát, ez oké, kivehetõ, de ha nem tudom feloldani a tartalmat, amiket ott tároltam, mert a készülék bedöglik és nem javítható?
Ugyanez igaz a Truecrypt és társaira is: jó, hogy ilyen kódolással használom, de ha megsérül, akkor kuka minden?

[YleGreg]

@Mykee: Igen, és nem. Ez a sérülés fajtájától függ.

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é!