Aktualizacja RTC1307 via internet

[Elvis]

Belferek, spokojnie, w przypadku safety-critical nie jest tak źle, więc o ile nic się nie zmieniło ostatnimi laty, elektrownie jądrowe nadal mają trzykrotnie zduplikowane układy sterowania, które są całkowicie odcięte od sieci. Trzykrotna duplikacja sprawia, że pomimo awarii, dwa nadmiarowe układy mogą nadal przejąć sterowanie. A wybór układu uszkodzonego jest bardzo prosty - ten który daje inne wyniki niż pozostałe jest wyłączany. Co ciekawe są dostępne nawet mikrokontrolery ze zwielokrotnionymi rdzeniami, gdzie podobny proces realiuje się sprzętowo.

Muszę Cię niestety rozczarować co do bezpieczeństwa systemów opartych na linuksie, w tym debianie - są może bardziej bezpieczne niż inne popularne systemy operacyjne, ale nadal o wiele za mało bezpieczne (albo bardziej dziurawe), żeby mogły być stosowane w systemach krytycznych dla bezpieczeństwa (security critical). Tutaj jednak konieczne są odpowiednie procedury bezpieczeństwa, a i tak zawsze istnieje ryzyko złamania systemu.

Arduino jest jak na ironię dość bezpiecznym systemem. Po pierwsze mamy kontrolę jakie programy uruchamiamy. Po drugie, kod programu jest wykonywany z innej pamięci - Flash dla programu, RAM dla danych. Więc przepełnienie bufora nie umożliwi przejęcia kontroli nad urządzeniem. Oczywiście nadal pozostaje problem ochrony danych krytycznych, np. haseł.

Jak chodzi o internet, to proste aplikacje typowe dla Arduino implementują tylko niewielki podzbiór protokołu TCP/IP. Dzięki temu nie potrzeba firewall-a, i tak niechciane pakiety nie będą obsługiwane. Co więcej typwe ataki są nieskuteczne, bo zwyczajnie brakuje zasobów na ich przeprowadzenie (np. pamięci RAM na przechowanie szkodliwego programu). Pod tym względem Raspberry prezentuje się znacznie gorzej. I nawet stabilna dystrybucja Linux-a tego nie naprawi.

[ Dodano: 03-02-2018, 21:47 ]

A pomysł własnego protokołu to tzn. "security by obscurity", często stosowane przez producentów sprzętu. Protokół można i tak łatwo złamać, a jego utajnienie niewiele daje. Jeśli chcemy zabezpieczyć transmijsę, pownniśmy wykorzystać techniki kryptograficzne. Ale wynalezienie bezpiecznego protokołu wcale nie jest tak łatwe jak się wydaje. Więc może łatwiej i bezpieczniej skorzystać z gotowca, powiedzmy SSL.

[Belferek]

Tutaj jednak konieczne są odpowiednie procedury bezpieczeństwa, a i tak zawsze istnieje ryzyko złamania systemu.

Oczywiście, że tak - masz rację. Dlatego szkoli się specjalistów od bezpieczeństwa teleinformatycznego, opracowuje procedury bezpieczeństwa, stosuje różne metody zabezpieczeń, prowadzi się badania, testy itd. Lecz tu chyba mówimy nie o systemach krytycznych lecz o bezpieczeństwie w sieci konstruowanych przez amatorów jak ja urządzeń.

Mimo opisanych przez Ciebie zabezpieczeń STUXNET zapisał się na stronach wikipedii:

https://pl.wikipedia.org/wiki/Stuxnet

Więc może łatwiej i bezpieczniej skorzystać z gotowca, powiedzmy SSL.

No tak - tylko, że to nadal jest LAN(WAN) i certyfikaty, których autentyczność potwierdzamy (nie za darmo). Można sobie oczywiście certyfikat wystawić samemu sobie no ale ...

[Elvis]

Problem jest taki, że zawsze musisz komuś zaufać - chociażby sobie, ale to wcale nie zawsze dobry pomysł.

Tak samo jest z certyfikatami, tworzą tzw. root-of-trust, czyli każdy certyfikat zapewnia o bezpieczeństwie kolejnego. Jeśli możesz zaufać jednemu z nich to nie musisz płacić. Płacisz za to że ktoś inny sprawdzi, że firma lub osoba jest tym za kogo się podaje. Wiec w przypadku embedded możesz spokojnie wygenerować własną parę kluczy i rozpowszechniać klucz publiczny jako zaufany. Jeśli metoda jego dystrybucji, np. z firmwarem jest bezpieczna, to wszystko ok.

Najważniejsze jest coś innego - bezpieczeństwo powinno opierać się na kluczach, a nie metodach. Więć wynajdowanie własnego protokołu jest bez sensu. Zamiast tego trzeba zadbać o bezpieczeństwo klucza.

Oczywiście nadal pozostaje problem bezpieczeństwa implementacji, bo jeśli kod zawiera błedy to nawet idealny klucz nam nie pomoże. Ale nie ma idealnych zabezpieczeń - to wszystko kwestia czasu i pieniędzy. Więc definiując zabezpieczenia zawsze trzeba określić przed czym mają nas chronić. Przykładowo jeśli ktoś przyjedzie z 10 mln dolarów w gotówce za moje hasło do komputera, to ja bym się skusił i podał... a ile warte jest hasło innych użytkowników? Może 1mln, może 100mln $ - ale to tylko kwestia ceny. Więc mając nieogarniczone zasoby zawsze złamiemy zabezpieczenia. Trzeba więc dokładnie określić co i przed czym ochraniamy.