W dniu 2022-08-23 o 13:35, J.F pisze:

Cieszę się, że się czepiasz :)
Traktuję to jako pomoc w przygotowaniu się na ewentualne dyskusje bo w
normie jest:
"If you wish to give us your feedback on this publication...." i
"W sprawach merytorycznych dotyczących treści normy można zwracać się.."

> A jaki timeout dla potwierdzenia? Ile trzeba czekac az drzwi sie
> otworzą ? :-)

Nie mam pojęcia (to nie ja, to brat :) ).
Zakładam, że system jest idealny według mojego pomysłu. O ile wiem brat
nie wszystko wdrożył, bo zrobił próby (typu 10 urządzeń dostaje wspólnym
drutem informację o zmianie stanu, który trzeba wysłać) i stwierdził
skoro wszystko działa to nie ma co przesadzać.

Najważniejsze jest oszacowanie jakie jest prawdopodobieństwa zderzenia.
Jeśli jest odpowiednio małe to jak nawet z takim prawdopodobieństwem
zdarzy się, że ktoś poczeka dodatkowe 100ms to świat się raczej nie zawali.

W tym idealnym rozwiązaniu mamy system priorytetów o którym wcześniej
nie wspominałem. Są rozdzielne zakresy opóźnień dla różnych rodzajów
ramek. Jeśli na koniec aktualnie nadawanej ramki czeka ramka powolnego
poolingu i ramka z odczytaną kartą to prawdopodobieństwo, że się zderzą
jest 0 bo mają rozdzielone okna czasowe.
Czyli jeśli czytnik nabiera ochoty na transmisję podczas trwania ramki
poolingu to jedynym problemem może być drugi czytnik. Ramka trwa 1ms.
Jakie jest prawdopodobieństwo, że dwie osoby zbliżą karty w czasie tej
samej 1ms. Myślę, że znikome i w tym fragmencie trzeba to jeszcze
pomnożyć przez 0,25% bo tak szacowałem zajętość szyny poolingiem.
Jest jakieś śladowe prawdopodobieństwo i teraz z kolei, aby się zderzyć
obaj muszą wygenerować tę samą liczbę losową, co nawet wtedy nie daje
gwarancji, że się zderzą.
Druga sytuacja to dwa czytniki, gdy nie ma akurat ramki poolingu. Można
założyć, że tak jest prawie zawsze. Oba czytniki już od jakiegoś czasu
uważają, że szyna jest wolna więc jak tylko będą miały ramkę to ją
nadadzą. Ale tu zbieżność musi być na poziomie 3us. Załóżmy, że stawiamy
dwie osoby przy dwu czytnikach i niech próbują trafić tak dokładnie :)
Aby policzyć trzeba założyć, jak często do n czytników ktoś podchodzi.
Wstępnie bym zsumował po 3us z n-1 czytników, podzielił przez rozważany
okres i to byłaby gęstość prawdopodobieństwa, że n-ty czytnik trafi. Tak
bym ocenił ryzyko dla tego jednego. Że wśród n się zdarzy to mniej
więcej (ale tu można mniej więcej) razy n.

>> Na początku nie mieliśmy tych opóźnień i trafiliśmy raz (może 1996) na
>> parę urządzeń, które wiecznie się zderzały - mijało kilka sekund (wiele
>> ramek) zanim któremuś udało się być pierwszym.
>
> Tak tak, ethernet mial ciekawy pomysl :-)

Nie rozumiem.

>> Załóżmy mały system - 5 urządzeń podległych na szynie. Norma wymaga, aby
>> najdalej po 5s wykryć brak urządzenia. Czyli np raz na 4s kontroler
>> wysyła 5 ramek (nie broadcast, bo każdy ma inny klucz sesji) i potem
>> niezależny proces zbiera odpowiedzi.
>
> Ale to juz brzmi jak polling.

Ale co innego (zasadniczo co innego) maksymalnie szybki pooling, aby dać
urządzeniom szansę wysłania pilnych komunikatów a co innego kilkanaście
1ms ramek raz na 4s.
Nie przeczytałem jeszcze całej normy i nie wiem ile mi zejdzie. O ile
się orientuję, to pooling jest tam nie szyfrowany. Zakładają, że mogą
być urządzenia o małej mocy obliczeniowej które by opóźniały. To
oznacza, że w tym grade, gdy norma (inna, główna) wymaga szyfrowania
komunikacji to dodatkowo trzeba zrobić szyfrowany pooling raz na te 4s
bo zwykły pooling daje się oszukać.
Przy grade 4 jest założenie, że atakujący ma nieograniczony czas i
środki na przygotowanie ataku.

>> Możliwe, że jak chce wysłać 3-ą
>> ramkę to odpowiedź pierwszego urządzenia wetnie się przed nią - zależy
>> co kto wylosuje. Czyli w stanie normalnym raz na 4s leci 10 ramek.
>> Typowa zajętość linii 10ms/4000ms = 0,25%.
>>
>>> Przy niewielkiej ilosci szybkich urzadzen - moze to nie problem.
>>> Bedą odpytywane co poł sekundy ...
>>
>> A pro po szybkich. Ten ich system powoduje, że tylko kontroler może
>> optymalizować czas szyfrowania robiąc to w czasie gdy inna ramka leci.
>> Urządzenie po odebraniu musi sprawdzić podpis, rozszyfrować, wypracować
>> odpowiedź, zaszyfrować, podpisać i w tym czasie na szynie cisza - się czeka.
>
> No ale i tak to robisz.

Chyba nie zrozumiałeś co chciałem powiedzieć.
Ten fragment "Możliwe, że jak chce wysłać 3-ą.." powinien wyjaśniać.
Kontroler nie czeka, aż odpytywany sobie zdekoduje i zakoduje. W tym
czasie szyna może być normalnie używana przez wszystkich potrzebujących.
Wszystkie operacje kryptograficzne u wszystkich uczestników pogaduszek
odbywają się poza czasem zajętości szyny. Urządzenie dopiero jak ma
gotową ramkę to staje się uczestnikiem walki o dostęp.

> Tyle tylko, ze jak rozumiem - to sluzy do
> sprawdzania obecnosci - zdarzenie urządzenia przekazują w miare
> natychmiast.

Tak, służy tylko temu, ale chciałem tu pokazać, że ten pooling nie
blokuje w żaden sposób szyny w związku z operacjami krypto.
Jakbyśmy dołączyli urządzenie, które będzie liczyło AES na przekaźnikach
to nie spowolni to w żaden sposób komunikacji na szynie.

> No fakt, moglby byc problem ... wiekszy radiator :-)

W szczelnie zalanym czytniku ...

>>> Rozumiem, ze to twoje zyczenie, ale jak czytnik ma sprawdzic gdzies
>>> "na serwerze", serwer sprawdzic "w bazie danych", to czas rosnie :-(
>>
>> Chyba nawet norma wymaga, że w przypadku odcięcia komunikacji z serwerem
>> wszystko ma nadal działać. W każdym razie u nas wszystkie informacje są
>> w kontrolerze (mała skrzyneczka na szynę DIN) zasilanym zasilaczem
>> buforowym.
>
> Pisząc "serwer" mam na mysli jakis "kontroler systemu".
> Gdzies tam macie przeciez zapisane ktore karty sa aktywne, jakie maja
> uprawnienia itp.

Kiedyś mając słabsze procesory kombinowaliśmy układając wszystkie karty
w 64 kupki i na podstawie jakiejś sumy wybierając tylko jedną z nich do
przejrzenia. Ale teraz całą bazę 32 tysięcy kart AtXmega daje radę
przejrzeć liniowo chyba w 50ms (szczegółowego obliczenia nie znam, ale
nie sądzę, aby dłużej).

>> W tej chwili nie umiałbym tego udowodnić, ale to dotyczy RS485.
>> Standardu Wiegand też nikt nie przenosi na ethernet :)
>
> Jak widac jednak sporo elementow Ethernetu sie w koncu w systemie
> znalazlo :-)

Znów nie rozumiem.
Musisz łopatologicznie bo Ethernet to dla mnie czarna magia.
P.G.