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.

do góry

W dniu 2012-11-21 19:24, Bool pisze:
> 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.


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

do góry

On 2012-11-21 19:24, Bool wrote:
> 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".

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.

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

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

do góry

W dniu 2012-11-21 19:24, Bool pisze:> 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.


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

do góry

On 2012-11-24 12:33, Andrzej W. wrote:
> 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.

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

do góry

W dniu 2012-11-24 15:41, Sebastian Biały pisze:
> On 2012-11-24 12:33, Andrzej W. wrote:
>> 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.
>
> 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".

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.

do góry

On 24.11.2012 16:03, Bool wrote:
> 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.

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

> Niestety mój mikrokontroler nie ma takiej pamięci.

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

--
Pozdrawiam
Michoo

do góry

W dniu 2012-11-24 15:41, Sebastian Biały pisze:
> 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".

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

do góry

W dniu 2012-11-24 16:03, Bool pisze:
> W dniu 2012-11-24 15:41, Sebastian Biały pisze:
>> On 2012-11-24 12:33, Andrzej W. wrote:
>>> 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.
>>
>> 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".
>
> 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.


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.

do góry

On 2012-11-24 19:14, Andrzej W. wrote:
> 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.

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

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

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.

do góry