System SmartAdmin - prosty i wygodny sposób programowania pilotów

Bardzo ciekawe, szczególnie przy coraz bardziej skomplikowanych konfiguracjach typu wspólny_szlaban-brama-brama_garażowa gdzie wiele budynków na osiedlu korzysta z wielu wjazdów wspólnych oraz bram i wjazdów do garażów, które są już przypisane do określonych budynków.

Ciekawa sprawa lecz mam kilka pytań:
-NIP instalatora - rozumiem, że nie ma wpływu na bezpieczeństwo i może być całkowicie jawny jest zwyczajnie numerem firmy, która obsługuje pilot SA?

-czy pilot SA podczas parowania ze sterownikiem przekazuje dane do sterownika czy odczytuje dane do sterownika?
Jeżeli odczytuje to OK można dodać kolejny pilot z tym samym NIP,
gorzej jak pilot SA przekazuje unikalne dane do sterownika, wtedy po utracie pilota SA mamy problem?

"Gdy odbiornik został uszkodzony, nowy odbiornik należy zaadresować tym samym adresem. Wymiana odbiornika jest niezauważalna dla użytkowników, gdyż użyte przyciski ponownie są automatycznie zapamiętywane przez odbiornik."

To skłania mnie do przemyślenia, że jednak pilot SA przechowuje wspólny sekret nazywany "adresem", więc jak można wyeksportować te dane aby uszkodzenie pilota SA nie spowodowało problemu? Natomiast wygląda na to, że numer przycisku jest daną w transmitowanym pakiecie i gdy zgadza się adres to reszta działa prawidłowo. Sprytne rozwiązanie.

"Każdy adres odbiornika kodowany jest innym, bezpiecznym 128-bitowym kluczem"
Jak należy to rozumieć? Czy podczas parowania odbiornika z SA losowany jest klucz 128b i ten sekret jest przechowywany w pamięci natomiast adres jest elementem jawnym (coś jak NIP). Jednak musi być tutaj element zmienności gdyż szyfrowanie tych samych danych (adresu) tym samym kluczem da zawsze ten sam wynik podatny na atak replay więc jakiś rodzaj licznika/losowości musi być dodany do procesu. To skutkuje bardziej czymś w rodzaju "podpisu" i autoryzacji (nadajnik i pilot współdzielą sekret) niż wspomnianego szyfrowania.

Coś na zasadzie:
Wysyłam:
-adres
-komendę
-zwiększający się licznik / losowe dane
-ciąg zależny od powyższych oraz współdzielonego sekretu

Odbieram:
-adres
-komendę
-zwiększający się licznik / losowe dane
-obliczam jaki powinien być ciąg "autoryzacyjny" dla powższych i współdzielonego sekretu i porównuję czy zgadza się z odebranym

Witam,
Dziękuję za pytania.

TechEkspert wrote:

-NIP instalatora - rozumiem, że nie ma wpływu na bezpieczeństwo i może być całkowicie jawny jest zwyczajnie numerem firmy, która obsługuje pilot SA?

NIP jest 10 cyfrową liczbą. Liczba ta może być każdą liczbą i służy dla odróżnienia instalatorów. Jawność nie obniża mocy kodowania,
Nawet rozważaliśmy możliwość wprowadzenia jej do pilota SmartAdmin przez instalatora, ale uznaliśmy, że instalatorzy mogą pójść na łatwiznę i nie zmieniać domyślnego "NIPu".
Bywało już tak z niektórymi naszymi produktami.

PROXIMA produkując pilota SmartAdmin dla instalatora losuje (i zapamiętuje w firmowym serwerze) 4096 128 bitowych kluczy kodujących zwanych adresami (dla organizacyjnej wygody instalatora nazwanych 512 numerami osiedli z 8 wjazdami, równie dobrze mogliśmy je ponumerować od 1 do do 4096). W każdy klucz dodatkowo wplata się się NIP instalatora.
Każdy przycisk pilota użytkownika może podać diodą LED tą 10cyfrową liczbę odróżniającą np. NIP. Łatwo więc ustalić instalatora i zwrócić się do niego pomoc mi tylko w sprawie pilotów. To taki cyfrowy grawer ułatwiający użytkownikowi życie.

TechEkspert wrote:

-czy pilot SA podczas parowania ze sterownikiem przekazuje dane do sterownika czy odczytuje dane do sterownika?
Jeżeli odczytuje to OK można dodać kolejny pilot z tym samym NIP,
gorzej jak pilot SA przekazuje unikalne dane do sterownika, wtedy po utracie pilota SA mamy problem?

Pilot Smart Admin przekazuje odbiornikowi jeden ze swoich 4096 128bitowych kluczy kodujących = liczbę zawierająca NIP = numer osiedla i numer wjazdu.
Jeżeli ktoś świadomie ukradnie pilota SmartAdmin to mamy kłopot. Złodziej posiada pełną władzę. Taki okradziony instalator powinien zwrócić się do nas o nowego pilota SA (z np NIPem zwiększonym o 1). Potem trzeba niestety zebrać piloty, przeprogramować je, a potem przeprogramować wszystkie odbiorniki. W celu usprawnieniu wymiany Instalator może otrzymać od PROXIMY stosowną liczbę wymaganych pilotów i wymienić je jeden do jeden z użytkownikami. Pozyskane piloty instalator zwraca do PROXIMY płacąc tylko za zużyte obudowy.

Jeżeli utracony pilot SA nie jest wykorzystywany, Proxima, po należytym uwierzytelnieniu INSTALATORA dostarcza klona utraconego pilota SmartAdmin.

TechEkspert wrote:

"Gdy odbiornik został uszkodzony, nowy odbiornik należy zaadresować tym samym adresem. Wymiana odbiornika jest niezauważalna dla użytkowników, gdyż użyte przyciski ponownie są automatycznie zapamiętywane przez odbiornik."
To skłania mnie do przemyślenia, że jednak pilot SA przechowuje wspólny sekret nazywany "adresem", więc jak można wyeksportować te dane aby uszkodzenie pilota SA nie spowodowało problemu? Natomiast wygląda na to, że numer przycisku jest daną w transmitowanym pakiecie i gdy zgadza się adres to reszta działa prawidłowo. Sprytne rozwiązanie.

W procesie konfiguracji pilot np. SmartAdmin przekazuje przyciskowi pilota i odbiornikowi 128 bitowy unikalny klucz kodujący zawierający NIP instalatora, nazywamy ten klucz adresem, dla organizacyjnej wygody instalatora nazwanym jednym z 512 numerów osiedli i jednym z ośmiu wjazdów.
Przycisk pilota wysyła swój unikalny numer seryjny uzyskany w PROXIMIE, licznik emisji i zakodowaną liczbę autoryzacyjną. Liczba autoryzacyjna zakodowana jest adresem (128bitowym kluczem) i zawiera NIP instalatora i numer emisji.

Jeżeli odbiornik posiada w swojej pamięci zarejestrowany serial pilota, to rozkodowuje liczbę autoryzacyjną, porównuje NIPy i o ile są takie same sprawdza czy numer emisji jest taki sam jak numer w części jawnej transmisji i jeżeli jest taki sam sprawdza czy jest jest nieco większy od numeru emisji, dla tego numeru seryjnego zapisanego w pamięci odbiornika. Jeżeli tak jest to odbiornik zapamiętuje nowy licznik w pamięci odbiornika i uruchamia swój przekaźnik.

Jeżeli odbiornik nie posiada w swojej pamięci numeru seryjny przycisku pilota którego rozkaz odebrał, rozkodowuje liczbę autoryzacyjną, porównuje NIPy, porównuje zakodowany i jawny licznik emisji i o ile wszystko się zgadza, rejestruje serial pilota, zapamiętuje jego licznik i uruchamia przekaźnik.

TechEkspert wrote:

"Każdy adres odbiornika kodowany jest innym, bezpiecznym 128-bitowym kluczem"
Jak należy to rozumieć? Czy podczas parowania odbiornika z SA losowany jest klucz 128b i ten sekret jest przechowywany w pamięci natomiast adres jest elementem jawnym (coś jak NIP). Jednak musi być tutaj element zmienności gdyż szyfrowanie tych samych danych (adresu) tym samym kluczem da zawsze ten sam wynik podatny na atak replay więc jakiś rodzaj licznika/losowości musi być dodany do procesu. To skutkuje bardziej czymś w rodzaju "podpisu" i autoryzacji (nadajnik i pilot współdzielą sekret) niż wspomnianego szyfrowania.

Coś na zasadzie:
Wysyłam:
-adres
-komendę
-zwiększający się licznik / losowe dane
-ciąg zależny od powyższych oraz współdzielonego sekretu

Odbieram:
-adres
-komendę
-zwiększający się licznik / losowe dane
-obliczam jaki powinien być ciąg "autoryzacyjny" dla powyższych i współdzielonego sekretu i porównuję czy zgadza się z odebranym

Wydaje mi się że odpowiedź można znaleźć w poprzednim punkcie. Jeżeli tak nie jest to proszę o informację.
Dodam tylko, że każdy odbiornik i współpracujące z nim przyciski pilotów kodowane są kluczem 128bitowym tylko jednego wjazdu - kluczem jednowjazdowym. Oznacza to, że nawet jeżeli osoba nieautoryzowana wejdzie w jego posiadanie, to uzyskuje władzę nad tylko nad tym jednym wjazdem. Kodowanie to silne kodowanie AES.

W kodowaniach HCS (klucz 64bitowy) i kodowaniach innych systemów poznanie klucza w pamięci odbiornika daje władzę nad całym systemem odbiorników producenta, więc również nad wszystkimi odbiornikami wszystkich instalatorów i nad odbiornikami wszystkich użytkowników.

Pozdrawiam
PROXIMILIAN

Dziękuję za wyczerpujące odpowiedzi, uważam że uzupełniły materiał.

Ilu bitowa jest liczba autoryzacyjna?

Co do kradzieży pilota SA może powinien on posiadać PIN odblokowujący,
funkcję blokowania po np. 10 minutach bezczynności oraz mechanizm niszczenia pamięci przy zbyt dużej liczbie prób?

Ciekawa sprawa z przechowywaniem zestawu 4096 128b kluczy dla każdego pilota na firmowym serwerze,
przy losowaniu pewnie sprawdzacie czy nie został już wylosowany i przydzielony taki sam klucz
oraz zakładam, że macie kopię zapasową online i offline tej bazy.

Wykorzystujecie szyfrowanie (określenie kodowanie jest tu błędne mimo, że popularne w mowie potocznej).
W tym zastosowaniu AES działa trochę jak funkcja skrótu z dzielonym sekretem dodawanym na wejściu tej funkcji.

Kolejnym krokiem w kierunku IoT było zapewnienie łączności sterowników z bramą do internetu.
Wtedy można by jeszcze bardziej usamodzielnić użytkowników.
Np. w każdym obiekcie mógłby znajdować się "panel programujący" do pilotów a każdy pilot posiadałby swój numer seryjny i klucz transportowy.
Następnie zdalne wysłanie komendy do sterownika aby czekał na pilot o określonym SN spowodowałoby, że użytkownik po podejściu do "panela programującego" ze swoim pilotem mógłby odebrać nową konfigurację dla pilota, którą przygotował instalator w panelu WEB.

Takie zdalne zaprogramowanie mogłoby zadziałać dla pilota ze znanym SN istniejącego w systemie ale także nowego pilota ze sklepu producenta lub zasobów instalatora.

Witam,
Dziękuję pochylenie nad naszym projektem.

TechEkspert wrote:

Ilu bitowa jest liczba autoryzacyjna?

Taka jak blok AESa 16Bajtów

TechEkspert wrote:

Co do kradzieży pilota SA może powinien on posiadać PIN odblokowujący,
funkcję blokowania po np. 10 minutach bezczynności oraz mechanizm niszczenia pamięci przy zbyt dużej liczbie prób?

Ciekawy pomysł, pozwolisz że zapytam innych kolegów na forum co tym myślą. Poproszę też naszych handlowców o zapytanie instalatorów którzy nabyli ten system.

TechEkspert wrote:

Ciekawa sprawa z przechowywaniem zestawu 4096 128b kluczy dla każdego pilota na firmowym serwerze,
przy losowaniu pewnie sprawdzacie czy nie został już wylosowany i przydzielony taki sam klucz
oraz zakładam, że macie kopię zapasową online i offline tej bazy.

Oczywiście tak, robimy standardowo 3 backupy naszego serwera w różnych miejscach.

TechEkspert wrote:

Wykorzystujecie szyfrowanie (określenie kodowanie jest tu błędne mimo, że popularne w mowie potocznej).
W tym zastosowaniu AES działa trochę jak funkcja skrótu z dzielonym sekretem dodawanym na wejściu tej funkcji.

Tak dziękuję za trafną uwagę.
Przy okazji opis różnic pomiędzy szyfrowaniem, kodowaniem i hashowaniem zaczerpniętym z:
https://opensecurity.pl/szyfrowanie-kodowanie-hashowanie/

Szyfrowanie (nie mylić z kodowaniem) to proces zamiany tekstu jawnego, zrozumiałego dla człowieka (cleartext, plaintext) w szyfrogram (cryptogram, ciphertext), czyli postać otrzymaną za pomocą serii przekształceń i podstawień, której nie da się odczytać, ani odszyfrować bez znajomości klucza szyfrującego.

Klucz szyfrujący (key, cryptovariable) to wartość wejściowa, która wpływa bezpośrednio na działanie algorytmu szyfrującego i otrzymywany w wyniku jego działania szyfrogram wyjściowy.

Szyfr to algorytm szyfrujący, czyli funkcja matematyczna wykorzystywana w procesie szyfrowania i deszyfrowania, dla której wejściem są czysty tekst i klucz szyfrujący, a wyjściem szyfrogram.

Kodowanie (nie mylić z szyfrowaniem) to proces zmiany formy reprezentacji tekstu. Odbywa się za pomocą podstawień, które są znane i odwracalne. Nie wymaga klucza, a co za tym idzie tekst zakodowany da się odczytać znając format użytego kodowania. Najprostszym przykładem kodowania jest alfabet Morse’a. Częstym błędem jest natomiast uznawanie kodowania Base64 za formę szyfrowania. Kodowanie takie nie daje żadnej ochrony ponieważ jest odwracalne i nie wymaga znajomości klucza (nie jest on używany przy kodowaniu).

Hashowanie to natomiast wyliczanie przy użyciu funkcji skrótu (algorytmu takiego jak np. MD5, SHA) unikalnego ciągu znaków o stałej długości dla dowolnego tekstu. Istotną cechą hashowania jest fakt, że jest to proces nieodwracalny, tzn. na podstawie konkretnego hasha nie jesteśmy w stanie stwierdzić co stanowiło zawartość tekstu wejściowego.

TechEkspert wrote:

Kolejnym krokiem w kierunku IoT było zapewnienie łączności sterowników z bramą do internetu.
Wtedy można by jeszcze bardziej usamodzielnić użytkowników.
Np. w każdym obiekcie mógłby znajdować się "panel programujący" do pilotów a każdy pilot posiadałby swój numer seryjny i klucz transportowy.
Następnie zdalne wysłanie komendy do sterownika aby czekał na pilot o określonym SN spowodowałoby, że użytkownik po podejściu do "panela programującego" ze swoim pilotem mógłby odebrać nową konfigurację dla pilota, którą przygotował instalator w panelu WEB.

Takie zdalne zaprogramowanie mogłoby zadziałać dla pilota ze znanym SN istniejącego w systemie ale także nowego pilota ze sklepu producenta lub zasobów instalatora.

Dziękuje za podpowiedź, hmm, LoraWAN? ....

Pozdrawiam
PROXIMIIAN

OK, dziękuję,
z mojej strony gdyby po Waszej stronie był na to czas to możemy nagrać podcast o rozwiązaniach PROXIMA,
tutaj przykłady: https://www.elektroda.pl/rtvforum/audio.php
w razie zainteresowania zapraszam na PW.

Wracając do kodowania to jest ono również użytecznym mechanizmem np. pozwala efektywnie wykorzystać modulację i medium transmisji (np. kodowanie manchester).

Z tymi pilotami SA to w przyszłości w ogóle możnaby zamknąć taki "pilot" w aplikacji na smarftona, która łączyłaby się z serwerwami producenta a być może też z portalem WEB z provisioningiem dla instalatora, wtedy aplikacji się nie zgubi.
Ale jak zapewnić komunikację z pilotem aby nie trzeba było do każdego pilota instalować transceivera BT?
Cóż zamiast pilota można sprzedawać interfejs BT<->RFpilota. Wtedy aplikacja po bluetoth połączy się z interfejsem i będzie komunikowała się z pilotem. Zgubienie lub zepsucie interfejsu niczym nie skutkuje gdyż nie ma tam konfiguracji, natomiast aplikację zawsze można zainstalować ponownie.

Co do komunikacji sterowników z internetem, zasięg LoraWAN czy sigfox chyba jest jeszcze zbyt słabo rozwinięty https://explorer.helium.com/ czy https://www.sigfox.com/en/coverage
Po między sterownikami to może być Lora, WiFi a nawet przewód.

Problemem jest stały dostęp sterowników do internetu, ktoś musi za to płacić a usługi smartcity, czy smart buildings również są słabo rozwinięte i nie ma co liczyć na miejskie WiFi więc pewnie kończyłoby się na SIM w jednym ze sterowników a to może być nieopłacalne...

Chyba, że panel programujący dla użytkowników w określonym miejscu osiedla komunikowałby się po BT i po zeskanowaniu QR na panelu i zainstalowaniu aplikacji użytkownika to właśnie jego smartfon byłby bramą do szyfrowanego połączenia do chmury skąd pobrane zostaną ustawienia wprowadzone przez instalatora.

OK bardzo ciekawe są rozważania o IoT i można nieźle skalować usługi ale nadal ogranicza nas brak powszechnej komunikacji dla IoT...
Hulajnogi miejskie podejrzewam, że również korzystają z SIM w każdej z nich... nadal brak jest stabilnych alternatyw dla usług o bardzo małym przesyle danych...