W dniu 06.06.2024 o 17:39, Piotr Gałka pisze:
> W dniu 2024-06-06 o 12:18, io pisze:
>> Robię co mogę by się udawało.
>
> Świat się raczej tak zmienia że wróżę więcej porażek niż sukcesów.

Ale, że niby co konkretnie się nie uda?

>
>> A producentom tylko nie wierzę w odpowiedzialność za produkt
>
> Pojęcie odpowiedzialność ja wprowadziłem do dyskusji w nieco innym
> znaczeniu - odpowiedzialność za szkody wyrządzone przez produkt.

No więc nie ma takiej odpowiedzialności za produkt, która nie byłaby
związana z deklaracjami producenta wobec nabywców. To jest związane z
wprowadzeniem do obrotu.

>
>> skoro nie potrafią zadbać by ten produkt nie stał się bezużyteczny z
>> powodu w sumie pierdołowatej zmiany standardu. Powtarzam się, ale nie
>> przyjmujesz to co mam napisać.
>
> Przyjmuję. Tylko staram Ci się uzmysłowić, że producent nie wszystko
> jest w stanie przewidzieć. Jak wprowadzili standard to mógł założyć, że
> przez kilkanaście/dziesiąt lat nic już się nie zmieni. W końcu nad tym
> cyfrowym tyle się zastanawiali, że mogli podjąć raz a dobrą decyzję.
> Chyba żaden producent telefonów stacjonarnych nie przewidział możliwości
> włożenia w aparat jakiegoś modułu aby stał się on komórką.

No ale to dowodzi właśnie tego, że producent nie odpowiada. Bo odpowiada
za wprowadzenie a kiedy wprowadzał można było nadawać w starym standardzie.

>
>> No ale działa tylko nie odbiera tego, co teraz nadają. To co chcesz
>> utylizować.
>
> Ja Ci piszę za wypełnienie jakich działań odpowiada producent a Ty
> imputujesz mi, że coś chcę utylizować.

"Utylizowanie" to twoje słowa.

>
>> Dekoder można podłączyć, ale to nie dzięki producentowi.
>
> A kto jak nie producent zapewnił złącze HDMI?

I co, daje albo chociaż sprzedaje te dekodery?

>
>>> Nie myl odpowiedzialności za bezpieczeństwo wyrobu z gwarancją jakości.
>>> Odpowiedzialność za bezpieczeństwo jest wymagana prawem, a na jakości
>>> zależy producentowi budującemu swoją markę. Są producenci, którym
>>> zależy na ich marce i tacy, którym nie zależy, a reszta to działanie
>>> rynku.
>>
>> No nie, producentowi zawsze zależy na marce bo po drugiej stronie jest
>> nabywca, który tym się jednak kieruje.
>
> Mylisz się.
> Producentowi może np zależeć tylko na zysku, który zwiększy sprzedając
> produkt byle jaki, ale 2 razy taniej niż konkurencja. Jeśli dzięki temu
> jego sprzedaż wzrośnie 10x (bo większość klientów zadziała według zasady
> - 'tak samo wygląda, a tańszy').

A to nic do wiatraka nie ma, że kogoś przechytrzył. Sprzedawcy nie będą
tego produktu polecali i już marka ma znaczenie.

> Jak sprzedaje produkt byle jaki to według mojego pojęcia nie zależy mu
> na marce.

Dobra, bardziej zależy mu na szybkich pieniądzach niż na marce.

>
>> I konkurencyjne oprogramowanie zwiększy moc. No dobra, ale to ciągle
>> jakieś oprogramowanie. Może działać dobrze lub źle.
>
> Są urządzenia, które np. emitują 10x większą moc od dopuszczalnej
> średniej ale z wypełnieniem 1/10 - czyli średnio tyle ile wolno.
> Jak wstawisz oprogramowanie, które zmieni wypełnienie na 100% to
> uzyskasz urządzenie niezgodne z normami.

Ale może być odwrotnie, że Ty norm nie trzymasz i w ogóle już nie żyjesz
a nabywca ma urządzenie, które zakłóca. W kategoriach biznesowych to
nawet nie znaczy twojego osobistego nie-życia tylko twojej sp. z
ograniczoną odpowiedzialnością.

>
>> No to właśnie regulator narzucił nowy standard :-) Ja po prostu
>> twierdzę, że producenci wcale nie chcą robić dobrze nabywcom blokując
>> możliwość wgrania konkurencyjnego oprogramowania.
>
> A ja Ci mówię, że to wcale nie musi chodzić o stosunek producentów do
> nabywców. Mogą być inne powody.
>
>> Ciągle jednak nabywca może chcieć wgrać konkurencyjne oprogramowanie
>> tak jak zmienić nóżkę.
>
> Tylko czy ważniejsze jest jego chcenie, czy chcenie producenta być może
> wywołane zabezpieczaniem się przed potencjalnymi prawnymi kłopotami.
>
>>> Jak wyobrażasz sobie podatność i na co, gdy nie można wgrać i
>>> uruchomić jakiegoś programu. Nie ma takiej funkcjonalności.
>>
>> Normalnie, przyjdzie ramka RS w której zawartości będzie kod, którego
>> wystąpienia Ty wcale nie przewidywałeś a jednak kod ten zadziała i
>> umożliwi np zjedzenie pieniędzy z karty. Bo tak się wydaje, że jak nie
>> ma pendrajwa to nie można wgrać a tu niespodzianka.
>
> Dla ramki:
> - sprawdzany jest jej rozmiar z nagłówkiem, - zgodziło się
> - sprawdzany jest CRC, - zgadza się - więc raczej nie jest to losowe
> przekłamanie tylko celowo wrzucona ramka,
> - sprawdzany jest 64 bitowy podpis kryptograficzny, Jeśli to jest celowo
> tworzona ramka i prawidłowo podpisana to problem jest gdzie indziej -
> jak atakujący uzyskał klucz sesji?
> No ale załóżmy, że rozpatrywana podatność polega na tym, że jakby
> przypadkiem zgodziło się i CRC i podpis.
> - ramka jest rozszyfrowywana - jeśli zakładamy, że podpis powstał
> przypadkiem to mogą tu wyjść dowolne śmieci.
> - bajt rozkazu z ramki porównywany jest ze skończoną listą
> przewidzianych rozkazów. Jeśli nie jest żadnym z nich to odpowiedź NAK.

No i w tym właśnie może być podatność, że jednak da się użyć inaczej niż
chciałbyś. To jest dość elementarna kwestia w cybersecurity!

>
> Generalnie wszystko w ramce musi się zgodzić z przewidywaniem.
> Jak wyobrazić to sobie jako rozkaz switch(){  case...} to w default:
> jest tylko 'wyślij NAK' a nie ma jakichś procedur typu a co może by to
> innego mogło znaczyć. Się nie zgadza z dokładnym oczekiwanym obrazem - won.
>
> Ale oczywiście można sobie wyobrazić, że jest jakiś błąd w programie.
> Ale skoro normalnie ramki są rozkodowywane to znaczy, że cały proces CRC
> i podpis krypto działa. Czyli podatność jest typu losowo się zgodził i
> CRC i podpis. Prawdopodobieństwo wystąpienia śladowe.

:-) No właśnie nie.

>
> Na pewno my mamy znacznie większą szansę poprawić taki błąd niż
> użytkownik napisać program całego kontrolera ale bez tego błędu.
> Zresztą jak już pisałem, jak ma taki program to bez problemu może go w
> kontroler wgrać.

No jasne, ale jak sam swoim przykładem dowodzisz, producent nawet nie
dopuszcza, że jakaś podatność istnieje. A istnieje na pewno :-)

>
>> Tak, i podłącza się GPS by mieć ten czas.
>
> Możliwe. Jak to jest w praktyce nie wiem. Są też jakieś zegary z
> atomowym wzorcem czasu.
>
>> Czyli testy przeszły. No ale nie sprawdzili wszystkich przypadków a
>> tylko jakieś. Przyjdzie jakaś inna ekipa albo ta sama po tym jak się
>> douczy i wynik może być negatywny. Dlatego właśnie w wysokich SIL robi
>> się analizę formalną algorytmów a nie tylko testy.
>
> Jeszcze dawniej było tak. Trzech kolegów A,B,C. A namawia B na
> zastosowanie naszego systemu. C na to, że on ma we Francji ludzi, którzy
> każdy system na karty obejdą. Dostają w walizeczce nasz kontroler z
> czytnikiem i 3 kartami (jedna otwiera, jedna nie otwiera, jedna nie z
> tego systemu).
> Po miesiącu C mówi kolegom: Głupio wyszło, ale oni w żaden sposób nie
> potrafią tego systemu ugryźć.
>
> Teraz jak nas zmuszą do wprowadzenia tej normy dla RS485 to już coś im
> się uda - komunikację będą w stanie obejrzeć.

Daj spokój, w ogóle nie zrozumiałeś na czym atak mógłby polegać i że ta
podatność w ogóle nie musi dotyczyć kodu który opisywałeś.

>
>>
>>> Tylko, że teraz jesteśmy zmuszani do wdrożenia durnej normy....
>>
>> Co w niej durnego?
>>
>
> Czy ja zupełnie nic nie napisałem (nie pamiętam), czy wyciąłeś.
>
> Durne dla mnie jest przede wszystkim to, że zmusza nas do zwiększenia
> zużycia energii na wysyłanie ramek na RS485 kilkaset razy. W czasie gdy
> cały świat stara się ograniczać marnowanie energii. My odpowiadamy za
> może 2000 ciągle chodzących RS485, ale w skali świata to są pewnie
> miliony takich szyn. Zmuszanie do bezsensownego marnowania energii
> nazywam durnym.

A to nie ta norma. Ja o normie dotyczącej budowania systemów
bezpiecznych :-)

>
>> Wyrażam taką nieustającą troskę o otwartość wszystkich rozwiązań jako
>> fundamentu dobrej jakości i zdrowej konkurencji.
>
> Nie stosujemy jakieś swojej, tajnej, 'najlepszej' na świecie
> kryptografii jak w kartach mifare Clasic tylko stosujemy ogólnie
> dostępne algorytmy kryptograficzne (gwarancja dobrej jakości).

Pozostaje cała reszta.