Bezpieczne szyfrowanie RFS w Embedded Linux na SBC z ARM - najlepsze rozwiązania?

Wed Nov 21, 2012 7:24 pm   

Mam SBC z ARM, na którym pracuje Linux. Poszukuję rozwiązania, które umożliwi zablokowanie dostępu
do systemu plików użytkownikowi "z zewnątrz".
Rozważam trzy opcje:
1) bootloader + kernel umieszczone we flashu, RFS (lub tylko wybrane pliki z danymi) na karcie SD,
2) wszystko w NAND flashu,
3) wszystko na karcie SD.
Zakładam że ktoś może mieć możliwość pełnego odczytu pamięci Flash oraz karty SD.
W uproszczeniu chodzi o to, że jeśli ktoś dostanie się do karty SD lub do NAND flasha, to mimo że
odczyta dane to i tak będę one bezwartościowe.

Będę wdzięczny za jakieś propozycje.

Wed Nov 21, 2012 7:54 pm   

W dniu 2012-11-21 19:24, Bool pisze:


To moze zamiast Linux'a wlasny system . Zaleta to dowolnosc wszystkiego
co robisz. Po jakiego grzyba szyfrowac Linux'a ?

Thu Nov 22, 2012 7:42 pm   

On 2012-11-21 19:24, Bool wrote:

LUKS/dm-crypt.

http://code.google.com/p/cryptsetup/

Nie używałem w embedded, narzut na dekompresje w locie jest jednak nie
do pominiecia. Nie wiem czy jajko aktualnie supportuje jakieś hardware
do AES.


Jeśli zapewnisz niemożnośc odzyskania klucza to kryptowanie filesystemu
załatwia sprawę.

Mając klucz możesz takie partycje na SD/NAND spokojnie przygotowywać na
normalnym PC i bedą kompatybilne.

Nie wiem czy w jądrze da się zaszyć montowanie na dm-crypt podczas
initu, ale zawsze możesz mieć w jajku initramfs w którym przemontujesz
partycję na kryptowaną.

Sat Nov 24, 2012 12:33 pm   

W dniu 2012-11-21 19:24, Bool pisze:> Mam SBC z ARM, na którym pracuje
Linux. Poszukuję rozwiązania, które


Musisz też zabezpieczyć się przed przełamaniem działającego systemu.
Co z tego, że partycja na karcie SD będzie zaszyfrowana, skoro system po
starcie będzie miał do niej nieograniczony niczym dostęp i "grzecznie"
poproszony przekaże wszystkie dane gdzie trzeba.


--
Pozdrawiam,
Andrzej

Sat Nov 24, 2012 3:41 pm   

On 2012-11-24 12:33, Andrzej W. wrote:

Czy możesz przedstawić scenariusz takie ataku kiedy:

a) jądro jest niemożliwe do odczytania
b) nie działa debugowanie jtag
c) filesystem jest zakryptowany, dostarczony z zewnatrz

Oczywiste błedy typu odpalone ssh z pustym hasłem roota pomijam. Chodzi
o to "grzeczne".

Sat Nov 24, 2012 4:03 pm   

W dniu 2012-11-24 15:41, Sebastian Biały pisze:

Dzięki za namiar na LUKS/dm-crypt.

Ja mam problem z pkt. a. Przecież jądro też będzie umieszczone na nośniku który może być odczytany
(NAND, SD). Oczywiście można je też zaszyfrować, ale wtedy trzeba zastosować bootloader, który je
zdeszyfruje. Tylko ten bootloader też musi być na tym samym nośniku, czyli też można go odczytać i
kółko się zamyka. Dla mnie idealne byłoby gdyby procesor miał wbudowaną pamięć flash w której
umieszczałbym bootloader z obsługą szyfrowanego kernela i blokował był dostęp do tej pamięci.
Niestety mój mikrokontroler nie ma takiej pamięci.

Sat Nov 24, 2012 4:22 pm   

On 24.11.2012 16:03, Bool wrote:

Dokładnie. Większość procesorów ma coś takiego


No to NIC nie zrobisz. Skoro dane w pewnym momencie są widoczne
niezaszyfrowane to odpowiednio zdeterminowany atakujący sobie poradzi.

--
Pozdrawiam
Michoo

Sat Nov 24, 2012 7:14 pm   

W dniu 2012-11-24 15:41, Sebastian Biały pisze:

Jeśli urządzenie nie ma możliwości jakiejkolwiek komunikacji ze światem
zewnętrznym to taki atak jest niemożliwy.
Natomiast jeśli jest jakaś interakcja to zawsze można próbować
wprowadzać błędne dane, wykorzystać luki w zabezpieczeniach usług itd.
Jeśli ma się takie urządzenie fizycznie w ręku to dodatkowo można
próbować obserwować magistrale danych lub wstrzykiwać w nie dane
fałszywe w celu załamania się konkretnych usług.
Ludzka pomysłowość nie zna granic.
Myślę, że takie teoretyczne dywagacje nie mają sensu puki autor nie
wyjaśni dokładnie "po co" i "za ile".

--
Pozdrawiam,
Andrzej

Sat Nov 24, 2012 7:43 pm   

W dniu 2012-11-24 16:03, Bool pisze:


Musisz sie zastanowc czy to oplacalne juz abstrachujac od tego ze jesli
korzystasz z darmowego kodu GNU to ten twoj tez powinien byc ogolnie
dostepny.

Sat Nov 24, 2012 9:08 pm   

On 2012-11-24 19:14, Andrzej W. wrote:

Super, czyli Ty ogólnie, a nie o tym przypadku.


Ciężko będzie jeśli jedyna magistrala danych dostępna bez trawienia
plastiku to zaszyfrowany szum.

Kluczowy jest tutaj kawałek Flasha którego nie można odczytać i
debugować. Wystarczyło by pare kB żeby wykonać bootloader a potem
chain-of-trust kończąc na czytaniu zaszyfrowanego kernela z sd z
filesystemem.

Czy taki ficzer istnieje w tym uC nie wiem, ale gdyby istniał cała
reszta nie wydaje sie specjalnie trudna.

Sat Nov 24, 2012 10:47 pm   

W dniu 2012-11-24 16:22, Michoo pisze:

Większość? Ja z ARMów z MMU znam tylko AT91SAM9X z wbudowanym flashem. Niestety w tym projekcie
odpada ze względu na brak sterownika grafiki.

Możesz podać jakieś inne?

Sat Nov 24, 2012 11:12 pm   

On 24.11.2012 22:47, Bool wrote:



--
Pozdrawiam
Michoo

Sat Nov 24, 2012 11:18 pm   

On 11/24/2012 04:47 PM, Bool wrote:

Poszukaj jakiegoś procesora z wbudowaną TrustZone. To jest mały kawałek
procesora, który wykonuje swój zabezpieczony program, który może
odszyfrować bootloader przed uruchomieniem, albo wykonywać fragmenty
kodu które są krytyczne ze względu na bezpieczeństwo. Być może będziesz
musiał podpisać NDA żeby dostać dokumentację, ale to będzie chyba
najprostsze i najbezpieczniejsze rozwiązanie.

pzdr.
j.

Sun Nov 25, 2012 1:01 am   

W dniu 2012-11-24 22:47, Bool pisze:

To wszystko zalezy co ty chcesz zrobic i czy to jest oplacalne dla
potencjalnego łamacza. Bo wiesz ze wszelkie kodowanie np TV cyfrowej
jest łamane w ciagu kilku max kilkunastu miesiecy. Połamanie np
zabezpieczeń TV-n zajęło ponad poł roku i sukces. Fakt trzeba było
lutować procesory i pamieci ale udało sie tak wiec zastanow sie czy warto.


Jesli komus sie oplaci dostac sie do twojego wynalazku to zrobi to
chocbys nawet umieścił to na słońcu.

Tue Nov 27, 2012 8:11 pm   

W dniu środa, 21 listopada 2012 19:24:41 UTC+1 użytkownik Bool napisał:

W Linuksie można zrealizować szyfrowanie na kilka sposobów, na różnych warstwach.

Od "dołu":
- Procesor, który uruchamia tylko podpisany cyfrowo/zaszyfrowany kod. Z tego, co wiem, np. Freescale i.MX coś takiego potrafią (nazywa się chyba secure boot). Procesor (Bootloader w procesorze) ładuje do RAM-u z karty SD lub NAND-a tzw. Boot Stream - może to być kernel + ramdysk - odszyfrowuje go i uruchamia (to nie jest reklama tej firmy .

- Bootloader (np.: u-boot) zmodyfikowany tak, żeby przed załadowaniem jądra i ramdysku do pamięci odszyfrowywał je. Wymaga zmodyfikowania bootloadera i ogranicza zastosowanie tylko do zaszyfrowania obrazu filesystemu.

- Szyfrowanie urządzeń blokowych na poziomie jądra: wspomniany w tej dyskusji dm-crypt (z lub bez LUKS) lub cryptsetup. W ten sposób można zaszyfrować tylko urządzenie blokowe (czyli takie, które obsługuje swobodne zapisy/odczyty), czyli np. kartę SD. Rozwiązanie nie nadaje się do szyfrowania NANDa (który wymaga kasowania przed zapisem, ma bad-sectory i się zużywa w miarę kasowań). Istnieją wprawdzie sterowniki implementujące mapowanie NAND-a na urządzenie blokowe (FTL, gluebi), ale w Linuksie powszechnie stosuje się specjalizowane filesystemy dla NAND (jffs2, ubifs).

- Szyfrowanie plików na poziomie filesystemu. Linux wspiera coś takiego, jak ecryptfs: http://lxr.linux.no/#linux+v3.6.8/Documentation/filesystems/ecryptfs.txt. W dowolnym systemie plików (na karcie SD lub np. ubifs na NAND) tworzony jest katalog (źródło), który następnie montujemy w innym katalogu (cel) pod kontrolą ecryptfs-a: mount -t ecryptfs źródło/ cel/ . Plik umieszczony w katalogu cel/ jest automatycznie szyfrowany i przechowywany w źródło/. Mogą być też szyfrowane nazwy plików (wsztsko zależy od opcji montowania). Oczywiście żeby to działało, konieczne jest wsparcie ze strony kernela i odpowiednie narzędzia pomocnicze.

Pozostaje jeszcze problem dostarczenia do systemu klucza do odszyfrowania (poza pierwszym przypadkiem):
- użytkownik może wprowadzać PIN podczas uruchamiania
- można użyć jakiegoś wbudowanego w urządzenie tokenu (smartcard), jakiś dedykowany chip itp. (ale to niestety podnosi koszty)
- można zastosować security-by-obscurity i w jakiś nieoczywisty sposób zaszyć klucz w kodzie: bootloadera, Linuksa lub jakiejś usługi - ale to jest najprostsze do złamania jak się ktoś uprze.

W praktyce:
W jednym z projektów zastosowałem ecryptfs do szyfrowania plików na NAND-zie - działał bez problemów na 200MHz ARM9. Zaszyfrowane (AES) było kilkanaście megabajtów danych (aplikacja, ustawienia). Narzut na czas startu był niewielki, tak samo zapisy, czas pracy na baterii itp. Widać było spowolnienie jedynie w przypadku zapisywania tam dużej ilości danych.

Pozdrawiam
--
Marcin Bis
http://bis.org.pl