RPi SD kódolás (encryption)

Miniszámítógépek, SBC-k

Üdv!
RPi SD kártyájának a tartalmát (egész SD v. könyvtárát) mivel érdemes lekódolni?
Olvastam a neten:

sudo apt-get install ecryptfs-utils
sudo apt-get install lsof
sudo ecryptfs-migrate-home -u pi

Ezzel lehet az egész SD-t is kódolni?

Van hátránya? (A visszafejtő kulcsot tárolni kell... stb. ez ok.) Erőforrásigénye van ennek?

  • 9619 megtekintés

( dotnetlinux | 2016. 05. 21., szo – 00:06 )

Minden bootnal be kell irni a kodot (?)

dotnetlinux: Igen, és pont ezért nem használja a kutya sem ezt a megoldást...

makgab: Ezzel a megoldással, csak a home könyvtár kódolható, de ahhoz is körülményes!

Inkább ajánlom a Cryptsetup-os (Luks) megoldást, a boot-on kívül mindent le tudsz vele titkosítani.
https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=80265

vagy itt egy bővebb leírás is róla:
https://gist.github.com/martijnvermaat/7864115

Oykawa

Boot távoli SSH elérésig, majd
Cryptsetup ---> partíció, amelyet esetleg célszerű LVM-mel tovább bontani logikai kötetekre.
Oka:
- home - ugye innen indultunk
- tmp - ide kerülhetnek érzékeny tmp file-k
- swap - memória leképezés, érzékeny adatrészletek

Erőforrásigény:
- Intel i3-ason kevésbé érezhető
- klasszikus Intel ATOM-on és HP Microserver (N54) esetén jelentős lassulás a fájlműveleteknél
- ARM Cortex: érezni fogod, bár általánosságban nem az erőteljes I/O-ról híres.

Odroid-U3 esetén, amely egy Rpi3-nál nagyobb számítási tempójú vas USB-s HDD-t teszteltem "hdparm -t" módszerrel. Ha natív USB-s meghajtó (/dev/sda) 19 MB/s tempóval olvasódott, cryptsetup után a létrejövő /dev/mapper/teszt 15 MB/s tempóval. Közben a top szerint 40 %-os terhelést okozott egyetlen szálon, azaz egyetlen magnak.

( fathom | 2016. 05. 21., szo – 11:37 )

Hello,

Haver LUKS-al próbálkozott 1es Pi-n. Nagy előny, hogy mint fentebb írták SSH-n keresztül is be lehet tolni a jelszót (vagy mondjuk egy pendrive-ra, amit kiszedegetsz).
Amiért ő eldobta a megoldást az pont az erőforrásigénye volt, az amúgy se túl fickós egyes Rpi teljesítményét nagyon csúnyán lerántotta, igaz itt kérdés, hogy mire akarod majd használni.
Kicsit offtopic, mivel windows és mcafee féle titkosítás, de azért szerintem mutat valamit, hogy a céges i5ös laptopon a bootidő titkosítással 10-20 perc (jó van ott minden más is nyílván), titkosítás nélkül 2-3...

FathoM

Pedig ez a helyzet. Van egy-két olyan laptop, ami laborban van ott nem kell titkosítani a vinyót (de nem is lehet kivinni onnan), 100%ig ugyanolyan HP laptopok, i5ös procival, 8GB rammal.
Ez a McAfee-féle titkosítóprogram amúgy sebesség szempontjából hírhedten szar.

FathoM

Ui.: A 10-20 perc úgy értendő, hogy valamiért idővel egyre lassabbak lesznek, de ezt inkább a windows 7 számlájára írnám.

Nem, sajna valami lassított energiatakarékos normál vinyó, alapjáraton is nagyon soknak tartom a 2-3 perces boot időt főleg, hogy ennek elenyésző része a domainba lépés és hasonló cuccok, a legtöbb amíg eljut addig (windows ikon középen), plusz amíg a vírusirtót meg a citrixes szarokat betölti.
De igazából ezen úgysem lehet változtatni, csak érdekességnek említettem.

FathoM

Tudomásom szerint minden i5-ös hardveresen gyorsítja az AES titkosítást (fixme). Ha ilyen lassú, akkor vagy azért lehet, mert nem használja ki a hardveres gyorsítást, vagy használ valami nem-AES algoritmust is. A hardveres AES titkosítás sebessége egy i5-2540M processzoron négy szálon 1.7 GB/sec, a VeraCrypt 1.17 benchmark-ja szerint. Ez egy szálra vetítve is ~425 MB/sec, ami szerintem nem szabad észrevehetően lelassítsa a gépet.

szerintem lehet különböző algoritmusokat választani. LUKS esetén a cryptsetup benchmark beszédes,

Persze az is kérdés, hogy mennyire kell biztonságosnak lennie. Engem itthoni himihumi titkosításnál baromira nem zavarva, ha pl. az nsa percek alatt tudná törni és tízezer dolláros befektetéssel mondjuk 1 nap alatt törhető lenne, inkább legyen gyors. Valóban érzékeny adatoknál nyilván más a helyzet.

Hát, még mindig az a kérdés, hogy mire használod/használnád a pit?

Ha a home mappából csak a pár config fájlt olvastatod néha fel, akkor gondolom nulla erőforrás igénye van, de ha mondjuk ott van a böngésző cache, vagy valami média fájlt onnan osztasz meg/játszol le, akkor bizzosan észrevehető. (állandó írás - olvasás)

Egyébként próbáld ki, az a biztos, aztán majd látod. Ha csak egy magon/egy szálon tud futni a dekódolás, akkor az majdnem biztosan az egyébként sem gyorsat is lassúvá teszi. A pi-nek egy magot tekintve eléggé nulla a teljesítménye, több magot használó alkalmazások jól futnak.