-
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.cyf-kr.edu.pl!news.nask
.pl!news.nask.org.pl!news.unit0.net!news.glorb.com!kt20no13833834pbb.1!news-out
.google.com!s9ni13304pbb.0!nntp.google.com!kr7no13595238pbb.0!postnews.google.c
om!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: pl.misc.elektronika
Date: Tue, 27 Nov 2012 10:11:01 -0800 (PST)
In-Reply-To: <50ad1c68$0$1305$65785112@news.neostrada.pl>
Complaints-To: g...@g...com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=87.206.144.240;
posting-account=-RzhIAoAAADTfStIs9D97lkO3E3zmy12
NNTP-Posting-Host: 87.206.144.240
References: <50ad1c68$0$1305$65785112@news.neostrada.pl>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8...@g...com>
Subject: Re: Embedded Linux z szyfrowanym RFS
From: m...@b...org.pl
Injection-Date: Tue, 27 Nov 2012 18:11:01 +0000
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Lines: 66
Xref: news-archive.icm.edu.pl pl.misc.elektronika:638630
[ ukryj nagłówki ]W dniu środa, 21 listopada 2012 19:24:41 UTC+1 użytkownik Bool napisał:
> Mam SBC z ARM, na którym pracuje Linux. Poszukuję rozwiązania, które umożliwi
zablokowanie dostępu
(...)
> 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.
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/file
systems/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
Najnowsze wątki z tej grupy
- Linuks od wer. 6.15 przestanie wspierać procesory 486 i będzie wymagać min. Pentium
- Propagation velocity v/c dla kabli RF
- Jakie natynkowe podwójne gniazdo z bolcem (2P+PE)
- Czujnik nacisku
- Protoków komunikacyjny do urządzenia pomiarowego
- Hiszpania bez pradu
- amperomierz w plusie
- 3G-nadal działa
- Historia pewnego miernika kalibratora
- Ustym 4k Pro i wyświetlacz
- Czemu rozwaliło celę?
- Wojna w portfelu
- Jaki trojfazowy licznik tuya lub podobny?
- Problem z dekoderem adresów
- Intel się wyprzedaje: po 10latach pchnęli pakiet kontrolny Altery za 1/4 kwoty zakupu
Najnowsze wątki
- 2025-05-13 Trawnika...
- 2025-05-13 48-latka, pracując w urzędzie, przyjmował łapówki, a w zamian wydawał pozytywne decyzje administracyjne dotyczące gospodarowania odpadami.
- 2025-05-13 według raportu Najwyższej Izby Kontroli z 2014 r. ustawiona ręcznie tolerancja fotoradarów wynosiła często nawet... 25 km na godz.!
- 2025-05-13 Na tapet wraca głośny temat niesprawiedliwe wystawianych mandatów za przekroczenie prędkości.
- 2025-05-13 Białystok => Senior Node.js Developer (Nest.js framework) <=
- 2025-05-13 Gdańsk => Controlling systems Consultant <=
- 2025-05-13 Białystok => Delphi Programmer <=
- 2025-05-13 Gdańsk => Konsultant wdrożeniowy (systemy controlingowe) <=
- 2025-05-13 zagadałem dziś babę
- 2025-05-13 W tym urządzeniu ugotujesz wodę wszędzie. Bez podłączania do prądu
- 2025-05-13 W tym urządzeniu ugotujesz wodę wszędzie. Bez podłączania do prądu
- 2025-05-13 W tym urządzeniu ugotujesz wodę wszędzie. Bez podłączania do prądu
- 2025-05-12 wyobrazcie sobie
- 2025-05-12 pojezdziłem passatem
- 2025-05-12 Ada-Europe Int.Conf. Reliable Software Technologies, AEiC 2025