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.
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ą.
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.
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.
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".
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.
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.
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.
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:
formatting link
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.