> Tak tajny firmware i tajny klucz prywatny bylby 'jakos' wgrywany do
> urzadzenia. Jak ? Nie wiem. Moze przez system plikow, moze przez karte
> (czyli czytnik kart dodatkowo), moze jakos inaczej.

Nie, mam inną wizję. Specjalizowany program na peceta,
napisany i udostępniony użytkownikowi. Ten program, przez
to samo złącze USB by wgrywał część firmware - bo druga część,
odpowiedzialna za odbiór danych z peceta przez USB byłaby
nieruszana. Ta druga część by tylko nasłuchiwała na USB,
czy ktoś (czyli ów specjalizowany program) nie chce czegoś
wgrywać. I nie wtrącała by się w "rzeczywistą" pracę klucza.

Pozdrowienia,
MKi

do góry

MKi wrote:

>> Tak tajny firmware i tajny klucz prywatny bylby 'jakos' wgrywany do
>> urzadzenia. Jak ? Nie wiem. Moze przez system plikow, moze przez karte
>> (czyli czytnik kart dodatkowo), moze jakos inaczej.
>
> Nie, mam inną wizję. Specjalizowany program na peceta,
> napisany i udostępniony użytkownikowi. Ten program, przez
> to samo złącze USB by wgrywał część firmware - bo druga część,
> odpowiedzialna za odbiór danych z peceta przez USB byłaby
> nieruszana. Ta druga część by tylko nasłuchiwała na USB,
> czy ktoś (czyli ów specjalizowany program) nie chce czegoś
> wgrywać. I nie wtrącała by się w "rzeczywistą" pracę klucza.

To nawet lepsze (dodałbym tylko jednak switch/przełącznik hardwerowy by nie
wgrac bez wyraźnej mojej wiedzy)

Trudno taki klucz by bylo zrobić?

do góry

>>> Tak tajny firmware i tajny klucz prywatny bylby 'jakos' wgrywany do
>>> urzadzenia. Jak ? Nie wiem. Moze przez system plikow, moze przez karte
>>> (czyli czytnik kart dodatkowo), moze jakos inaczej.
>> Nie, mam inną wizję. Specjalizowany program na peceta,
>> napisany i udostępniony użytkownikowi. Ten program, przez
>> to samo złącze USB by wgrywał część firmware - bo druga część,
>> odpowiedzialna za odbiór danych z peceta przez USB byłaby
>> nieruszana. Ta druga część by tylko nasłuchiwała na USB,
>> czy ktoś (czyli ów specjalizowany program) nie chce czegoś
>> wgrywać. I nie wtrącała by się w "rzeczywistą" pracę klucza.
>
> To nawet lepsze (dodałbym tylko jednak switch/przełącznik hardwerowy by nie
> wgrac bez wyraźnej mojej wiedzy)

Że niby użytkownik bez Twojej wiedzy nie przełączy tego switcha?
Jak chcesz kontrolować zmiany, możesz razem z firmwarem
do wgrania dawać użytkownikowi sumę kontrolną - program
by ją weryfikował i nie wgrał nic bez poprawnej sumy.

>
> Trudno taki klucz by bylo zrobić?
>
Nie. Albo tak.
Jakie pytanie, taka odpowiedź - ja bym takie programy
(dwa, na peceta i na procesor) napisał w tydzień, w
przerwach obiadowych. Ale nie znam poziomu wiedzy
potencjalnego twórcy.

Pozdrowienia,
MKi

do góry

MKi pisze:

>> To nawet lepsze (dodałbym tylko jednak switch/przełącznik hardwerowy
>> by nie wgrac bez wyraźnej mojej wiedzy)
>
> Że niby użytkownik bez Twojej wiedzy nie przełączy tego switcha?
> Jak chcesz kontrolować zmiany, możesz razem z firmwarem
> do wgrania dawać użytkownikowi sumę kontrolną - program
> by ją weryfikował i nie wgrał nic bez poprawnej sumy.

Za proste do obejścia.

Zdecydowanie lepszym rozwiązaniem jest wysyłanie z peceta zaszyfrowanego
apgrejdu (wystarczy do tego choćby AES-128), a klucz deszyfrowania
będzie zaszyty w bootloaderze "klucza" USB. W zależności od potrzeb
można albo generować jeden klucz szyfrowania dla całej serii urządzeń,
albo - ale to już hardcore - indywidualne klucze dla każdego urządzenia,
co wymaga oznaczenia urządzeń np. numerami seryjnymi i generowania
oddzielnego apgrejdu dla każdego egzemplarza.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

MKi wrote:

>>>> Tak tajny firmware i tajny klucz prywatny bylby 'jakos' wgrywany do
>>>> urzadzenia. Jak ? Nie wiem. Moze przez system plikow, moze przez karte
>>>> (czyli czytnik kart dodatkowo), moze jakos inaczej.
>>> Nie, mam inną wizję. Specjalizowany program na peceta,
>>> napisany i udostępniony użytkownikowi. Ten program, przez
>>> to samo złącze USB by wgrywał część firmware - bo druga część,
>>> odpowiedzialna za odbiór danych z peceta przez USB byłaby
>>> nieruszana. Ta druga część by tylko nasłuchiwała na USB,
>>> czy ktoś (czyli ów specjalizowany program) nie chce czegoś
>>> wgrywać. I nie wtrącała by się w "rzeczywistą" pracę klucza.
>>
>> To nawet lepsze (dodałbym tylko jednak switch/przełącznik hardwerowy by
>> nie wgrac bez wyraźnej mojej wiedzy)
>
> Że niby użytkownik bez Twojej wiedzy nie przełączy tego switcha?

Raczej ze program bez wiedzy uzytkownika nie przelaczy tego przelacznika.
Uzytkownik to wie co robi a jak nie wie niech nie uzywa.

> Jak chcesz kontrolować zmiany, możesz razem z firmwarem
> do wgrania dawać użytkownikowi sumę kontrolną - program
> by ją weryfikował i nie wgrał nic bez poprawnej sumy.

A jak bedziesz zmienial firmware na nowszy ;)



>> Trudno taki klucz by bylo zrobić?
>>
> Nie. Albo tak.
> Jakie pytanie, taka odpowiedź - ja bym takie programy
> (dwa, na peceta i na procesor) napisał w tydzień, w
> przerwach obiadowych. Ale nie znam poziomu wiedzy
> potencjalnego twórcy.

No cóż to jest odpowiedź ;)

do góry

Adam Dybkowski wrote:

> MKi pisze:
>
>>> To nawet lepsze (dodałbym tylko jednak switch/przełącznik hardwerowy
>>> by nie wgrac bez wyraźnej mojej wiedzy)
>>
>> Że niby użytkownik bez Twojej wiedzy nie przełączy tego switcha?
>> Jak chcesz kontrolować zmiany, możesz razem z firmwarem
>> do wgrania dawać użytkownikowi sumę kontrolną - program
>> by ją weryfikował i nie wgrał nic bez poprawnej sumy.
>
> Za proste do obejścia.
>
> Zdecydowanie lepszym rozwiązaniem jest wysyłanie z peceta zaszyfrowanego
> apgrejdu (wystarczy do tego choćby AES-128), a klucz deszyfrowania
> będzie zaszyty w bootloaderze "klucza" USB. W zależności od potrzeb
> można albo generować jeden klucz szyfrowania dla całej serii urządzeń,
> albo - ale to już hardcore - indywidualne klucze dla każdego urządzenia,
> co wymaga oznaczenia urządzeń np. numerami seryjnymi i generowania
> oddzielnego apgrejdu dla każdego egzemplarza.


Ale to ma byc open source haker friendly etc.
;)

Wszystko wiem. Dziekuje wszystkim odpowiadającym za odpowiedź.
Jeśli ktoś będzie ten tydzień miał wolny chętnie zajme się programem na
Linux-a lub skryptowe (ruby,php,perl etc.) Jesli bede umial to moze bym
poprawil i ten w kluczu. Zaplace tez za egz. testowy by moc samodzielnie cos
robic.
To taki pomysl oczywiście. Nic więcej.

do góry

>
> Raczej ze program bez wiedzy uzytkownika nie przelaczy tego przelacznika.
> Uzytkownik to wie co robi a jak nie wie niech nie uzywa.

Czy jesteś pewien?
Ale czy jesteś pewien, że jesteś pewien?
Czy na pewno jesteś pewien?

(Z życia, widziałem taki program)


>> Jak chcesz kontrolować zmiany, możesz razem z firmwarem
>> do wgrania dawać użytkownikowi sumę kontrolną - program
>> by ją weryfikował i nie wgrał nic bez poprawnej sumy.
>
> A jak bedziesz zmienial firmware na nowszy ;)

Bootloader by się wgrywało tylko w fabryce.
Reszta, wykonująca właściwe zadanie, wgrywana
byłaby przez bootloader. Gdy ta właściwa "reszta"
dostałaby odpowiednie polecenie z komputera,
przekazywałaby sterowanie do bootlodera
i odchodziła w niebyt.

> No cóż to jest odpowiedź ;)

;P

Pozdrowienia,
MKi

do góry

MKi pisze:

> Bootloader by się wgrywało tylko w fabryce.
> Reszta, wykonująca właściwe zadanie, wgrywana
> byłaby przez bootloader. Gdy ta właściwa "reszta"
> dostałaby odpowiednie polecenie z komputera,
> przekazywałaby sterowanie do bootlodera
> i odchodziła w niebyt.

Dobry pomysł. Należałoby również po każdym włączeniu zasilania/resecie
jeszcze w bootloaderze sprawdzać integralność właściwego programu
(chociażby sumę kontrolną CRC32) i przechodzić w tryb "aktualizacji
firmware" jeżeli coś się pokwasi w pamięci Flash. To przy okazji zapewni
automatyczne wejście do pierwszego programowania podczas produkcji
(wystarczy tylko wgrać na początku goły bootloader).

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

> Dobry pomysł. Należałoby również po każdym włączeniu zasilania/resecie
> jeszcze w bootloaderze sprawdzać integralność właściwego programu
> (chociażby sumę kontrolną CRC32) i przechodzić w tryb "aktualizacji
> firmware" jeżeli coś się pokwasi w pamięci Flash. To przy okazji zapewni
> automatyczne wejście do pierwszego programowania podczas produkcji
> (wystarczy tylko wgrać na początku goły bootloader).
>

Dodam jeszcze, że ratuje też w przypadku przerwy
(np. zanik napięcia) podczas wgrywania firmware.

Jeden z moich projektów dokładnie tak działa,
jak opisałeś. Szpiegostwo przemysłowe?

;)

Pozdrowienia,
MKi

do góry

MKi pisze:

>> Dobry pomysł. Należałoby również po każdym włączeniu zasilania/resecie
>> jeszcze w bootloaderze sprawdzać integralność właściwego programu
>> (chociażby sumę kontrolną CRC32) i przechodzić w tryb "aktualizacji
>> firmware" jeżeli coś się pokwasi w pamięci Flash.

> Dodam jeszcze, że ratuje też w przypadku przerwy
> (np. zanik napięcia) podczas wgrywania firmware.
>
> Jeden z moich projektów dokładnie tak działa,
> jak opisałeś. Szpiegostwo przemysłowe?

Nie, raczej standard absolutny w takich przypadkach.

Inny pomysł (jeżeli jest do dyspozycji więcej Flasha) to trzymanie dwóch
kopii firmware (ostatnio wgranej i przedostatniej) i stwierdzanie w
bootloaderze, którą uruchomić. Na podstawie np. sprawdzenia
integralności, numeru wersji czy daty apgrejdowania. To umożliwia
prawidłowe pełne działanie urządzenia nawet gdy podczas apgrejdowania
coś się pokwasi. A przy kolejnym apgrejdzie wybrać do nadpisania właśnie
ten popsuty obszar (ew. starszą wersję firmware jeżeli obie są integralne).

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry