Zaimplementować zabezpieczenie przed klonowaniem #9

Open
opened 2019-05-18 19:50:27 +00:00 by lechu · 9 comments
Owner

Zaimplementować zabezpieczenie przed klonowaniem poprzez zapisywanie ostatniego timestampu (zahashowanego i posolonego) na karcie i w czytniku - wtedy użycie karty natychmiast unieważnia jej nieautoryzowaną kopię.

Zaimplementować zabezpieczenie przed klonowaniem poprzez zapisywanie ostatniego timestampu (zahashowanego i posolonego) na karcie i w czytniku - wtedy użycie karty natychmiast unieważnia jej nieautoryzowaną kopię.

Wymaga aktualnego czasu w czytnikach, czego nie możemy zagwarantować (fajnie by było nie uzależniać wejścia do HS od dostępności internetu, a docelowo karty miałyby zastąpić klucze) oraz wymaga kart dedykowanych dla HS. Nie wiem jak inni, ale ja używam karty, którą i tak noszę. Pewnie nie tylko ja. Nie znam jej haseł zapisu.

Wymaga aktualnego czasu w czytnikach, czego nie możemy zagwarantować (fajnie by było nie uzależniać wejścia do HS od dostępności internetu, a docelowo karty miałyby zastąpić klucze) oraz wymaga kart dedykowanych dla HS. Nie wiem jak inni, ale ja używam karty, którą i tak noszę. Pewnie nie tylko ja. Nie znam jej haseł zapisu.
Author
Owner

Na obecnym HW nie. W nowym - tak, byle jaki mocniejszy MCU niż AVR zazwyczaj ma RTC na pokładzie. Z resztą, nie trzeba nawet używać RTC jako źródła timestampu... Można użyć poprzedniego hasha jako jednego ze składników. To na razie pomysł.
Ja używam akurat dedykowanej karty, ale myślę, że noszenie dedykowanej w portfelu nie będzie dużym problemem.

Na obecnym HW nie. W nowym - tak, byle jaki mocniejszy MCU niż AVR zazwyczaj ma RTC na pokładzie. Z resztą, nie trzeba nawet używać RTC jako źródła timestampu... Można użyć poprzedniego hasha jako jednego ze składników. To na razie pomysł. Ja używam akurat dedykowanej karty, ale myślę, że noszenie dedykowanej w portfelu nie będzie dużym problemem.
Author
Owner

Also, domyślne klucze do Mifare są znane. Więc można by je albo zostawić albo zmienić przy tworzeniu klucza.

Also, domyślne klucze do Mifare są znane. Więc można by je albo zostawić albo zmienić przy tworzeniu klucza.

W nowym - tak, byle jaki mocniejszy MCU niż AVR zazwyczaj ma RTC na pokładzie.

RTC to nie wszystko, trzeba będzie dodać baterię podtrzymania czasu (i ją sprawdzać).

Można użyć poprzedniego hasha jako jednego ze składników.

Ile haseł wstecz zezwolisz? Czy jeżeli ktoś 10 razy nie otworzy konkretnych drzwi (np. warsztatu), to już się tam nie dostanie bez ręcznego zresetowania licznika?

Also, domyślne klucze do Mifare są znane. Więc można by je albo zostawić albo zmienić przy tworzeniu klucza.

Gorzej, jak ktoś używa jakiejś karty ze zmienionymi kluczami, co raczej nie jest zbyt rzadkie.

Ja używam akurat dedykowanej karty, ale myślę, że noszenie dedykowanej w portfelu nie będzie dużym problemem.

Tak. Oczywiście. Można. Pytanie, czy warto? Przypominam, że chodzi tylko o otwarcie drzwi. Niezależnie od tego jest system alarmowy, który się rozbraja PIN-em.

> W nowym - tak, byle jaki mocniejszy MCU niż AVR zazwyczaj ma RTC na pokładzie. RTC to nie wszystko, trzeba będzie dodać baterię podtrzymania czasu (i ją sprawdzać). > Można użyć poprzedniego hasha jako jednego ze składników. Ile haseł wstecz zezwolisz? Czy jeżeli ktoś 10 razy nie otworzy konkretnych drzwi (np. warsztatu), to już się tam nie dostanie bez ręcznego zresetowania licznika? > Also, domyślne klucze do Mifare są znane. Więc można by je albo zostawić albo zmienić przy tworzeniu klucza. Gorzej, jak ktoś używa jakiejś karty ze zmienionymi kluczami, co raczej nie jest zbyt rzadkie. > Ja używam akurat dedykowanej karty, ale myślę, że noszenie dedykowanej w portfelu nie będzie dużym problemem. Tak. Oczywiście. Można. Pytanie, czy warto? Przypominam, że chodzi tylko o otwarcie drzwi. Niezależnie od tego jest system alarmowy, który się rozbraja PIN-em.
Author
Owner

RTC to nie wszystko, trzeba będzie dodać baterię podtrzymania czasu (i ją sprawdzać).
Nowy HW i tak ma mieć podtrzymanie całości. Można użyć akumulatorka. Trzeba zebrać na niego wymagania, to nie jest na to miejsce.

Ile haseł wstecz zezwolisz? Czy jeżeli ktoś 10 razy nie otworzy konkretnych drzwi (np. warsztatu), to już się tam nie dostanie bez ręcznego zresetowania licznika?

Jedno wstecz. Po to by wykryć nieautoryzowane użycie od razu. Tu nie ma miejsca na fail-open.

Gorzej, jak ktoś używa jakiejś karty ze zmienionymi kluczami, co raczej nie jest zbyt rzadkie.

Nie ryzykowałbym mieszania kilku funkcji na jednej karcie. Założeniem jest dedykowana karta do HSu.

Tak. Oczywiście. Można. Pytanie, czy warto? Przypominam, że chodzi tylko o otwarcie drzwi. Niezależnie od tego jest system alarmowy, który się rozbraja PIN-em.

Myślę, że tak, bo to jednak kolejny stopień prewencji (zamiast reakcji jaką jest alarm) który nie ugryzie mocno ludzi - tylko jedna karta lub breloczek ekstra.

> RTC to nie wszystko, trzeba będzie dodać baterię podtrzymania czasu (i ją sprawdzać). Nowy HW i tak ma mieć podtrzymanie całości. Można użyć akumulatorka. Trzeba zebrać na niego wymagania, to nie jest na to miejsce. > Ile haseł wstecz zezwolisz? Czy jeżeli ktoś 10 razy nie otworzy konkretnych drzwi (np. warsztatu), to już się tam nie dostanie bez ręcznego zresetowania licznika? Jedno wstecz. Po to by wykryć nieautoryzowane użycie od razu. Tu nie ma miejsca na fail-open. > Gorzej, jak ktoś używa jakiejś karty ze zmienionymi kluczami, co raczej nie jest zbyt rzadkie. Nie ryzykowałbym mieszania kilku funkcji na jednej karcie. Założeniem jest dedykowana karta do HSu. > Tak. Oczywiście. Można. Pytanie, czy warto? Przypominam, że chodzi tylko o otwarcie drzwi. Niezależnie od tego jest system alarmowy, który się rozbraja PIN-em. Myślę, że tak, bo to jednak kolejny stopień prewencji (zamiast reakcji jaką jest alarm) który nie ugryzie mocno ludzi - tylko jedna karta lub breloczek ekstra.

Jedno wstecz. Po to by wykryć nieautoryzowane użycie od razu. Tu nie ma miejsca na fail-open.

Przypominam, że mamy mieć kilka zamków. Czy może oczekujesz, że ludzie będą nosić ze sobą wiele kart?

Nie ryzykowałbym mieszania kilku funkcji na jednej karcie. Założeniem jest dedykowana karta do HSu.

Pierwsze słyszę o takim założeniu. Na pewno obecnie nie jest spełnione.

Myślę, że tak, bo to jednak kolejny stopień prewencji (zamiast reakcji jaką jest alarm) który nie ugryzie mocno ludzi - tylko jedna karta lub breloczek ekstra.

Dla mnie każda dodatkowa rzecz pogrubia portfel i mnie irytuje. Dla iluzji zwiększonego bezpieczeństwa nie widzę sensu. Co innego, jeżeli rzeczywiście ma to znaczący wpływ na bezpieczeństwo, ale mam co do tego wątpliwości. Ryzyko, że ktoś spróbuje skopiować kartę (zamiast np. ukraść) żeby przy jej użyciu wejść do HS i nie wykona ataku natychmiast (używanie pamięci nie pomoże jeżeli atakujący dotrze wcześniej) oceniam jako niskie. Przed takimi sytuacjami (i wieloma innymi, jak choćby włamanie się przez zbicie szyby, wyważanie okna/drzwi, czy otwarcie zamka wytrychem) zabezpiecza system alarmowy.

Pewnie da się użyć sensowne pamięci, żeby odrobinę zwiększyć bezpieczeństwo. Ale znacznie ważniejsze jest np. dopracowanie alarmu. Choćby dlatego, że przecież nie zrezygnujemy z tradycyjnego zamka na wypadek niespodziewanych problemów, prawda? A tradycyjny zamek można otworzyć bez kluczy. Tylko kwestia doświadczenia włamywacza i czasu.

> Jedno wstecz. Po to by wykryć nieautoryzowane użycie od razu. Tu nie ma miejsca na fail-open. Przypominam, że mamy mieć kilka zamków. Czy może oczekujesz, że ludzie będą nosić ze sobą wiele kart? > Nie ryzykowałbym mieszania kilku funkcji na jednej karcie. Założeniem jest dedykowana karta do HSu. Pierwsze słyszę o takim założeniu. Na pewno obecnie nie jest spełnione. > Myślę, że tak, bo to jednak kolejny stopień prewencji (zamiast reakcji jaką jest alarm) który nie ugryzie mocno ludzi - tylko jedna karta lub breloczek ekstra. Dla mnie każda dodatkowa rzecz pogrubia portfel i mnie irytuje. Dla iluzji zwiększonego bezpieczeństwa nie widzę sensu. Co innego, jeżeli rzeczywiście ma to znaczący wpływ na bezpieczeństwo, ale mam co do tego wątpliwości. Ryzyko, że ktoś spróbuje skopiować kartę (zamiast np. ukraść) żeby przy jej użyciu wejść do HS i nie wykona ataku natychmiast (używanie pamięci nie pomoże jeżeli atakujący dotrze wcześniej) oceniam jako niskie. Przed takimi sytuacjami (i wieloma innymi, jak choćby włamanie się przez zbicie szyby, wyważanie okna/drzwi, czy otwarcie zamka wytrychem) zabezpiecza system alarmowy. Pewnie da się użyć sensowne pamięci, żeby odrobinę zwiększyć bezpieczeństwo. Ale znacznie ważniejsze jest np. dopracowanie alarmu. Choćby dlatego, że przecież nie zrezygnujemy z tradycyjnego zamka na wypadek niespodziewanych problemów, prawda? A tradycyjny zamek można otworzyć bez kluczy. Tylko kwestia doświadczenia włamywacza i czasu.
Author
Owner

Przypominam, że mamy mieć kilka zamków. Czy może oczekujesz, że ludzie będą nosić ze sobą wiele kart?

Zamki będą musiały ze sobą gadać i trzymać te tokeny "wyżej". Trzeba dodać zależność.

Pierwsze słyszę o takim założeniu. Na pewno obecnie nie jest spełnione.

Ja nie zakładałbym że dostawcy tych innych kart przyjęli takie założenie i że nasza ekstra funkcja nie będzie kolidować z ichnymi.

Dla mnie każda dodatkowa rzecz pogrubia portfel i mnie irytuje. Dla iluzji zwiększonego bezpieczeństwa nie widzę sensu. Co innego, jeżeli rzeczywiście ma to znaczący wpływ na bezpieczeństwo, ale mam co do tego wątpliwości. Ryzyko, że ktoś spróbuje skopiować kartę (zamiast np. ukraść) żeby przy jej użyciu wejść do HS i nie wykona ataku natychmiast (używanie pamięci nie pomoże jeżeli atakujący dotrze wcześniej) oceniam jako niskie. Przed takimi sytuacjami (i wieloma innymi, jak choćby włamanie się przez zbicie szyby, wyważanie okna/drzwi, czy otwarcie zamka wytrychem) zabezpiecza system alarmowy.

Pewnie da się użyć sensowne pamięci, żeby odrobinę zwiększyć bezpieczeństwo. Ale znacznie ważniejsze jest np. dopracowanie alarmu. Choćby dlatego, że przecież nie zrezygnujemy z tradycyjnego zamka na wypadek niespodziewanych problemów, prawda? A tradycyjny zamek można otworzyć bez kluczy. Tylko kwestia doświadczenia włamywacza i czasu.

Zgoda. To na razie tylko pomysł, jeszcze do przegadania.

> Przypominam, że mamy mieć kilka zamków. Czy może oczekujesz, że ludzie będą nosić ze sobą wiele kart? Zamki będą musiały ze sobą gadać i trzymać te tokeny "wyżej". Trzeba dodać zależność. > Pierwsze słyszę o takim założeniu. Na pewno obecnie nie jest spełnione. Ja nie zakładałbym że dostawcy tych innych kart przyjęli takie założenie i że nasza ekstra funkcja nie będzie kolidować z ichnymi. > Dla mnie każda dodatkowa rzecz pogrubia portfel i mnie irytuje. Dla iluzji zwiększonego bezpieczeństwa nie widzę sensu. Co innego, jeżeli rzeczywiście ma to znaczący wpływ na bezpieczeństwo, ale mam co do tego wątpliwości. Ryzyko, że ktoś spróbuje skopiować kartę (zamiast np. ukraść) żeby przy jej użyciu wejść do HS i nie wykona ataku natychmiast (używanie pamięci nie pomoże jeżeli atakujący dotrze wcześniej) oceniam jako niskie. Przed takimi sytuacjami (i wieloma innymi, jak choćby włamanie się przez zbicie szyby, wyważanie okna/drzwi, czy otwarcie zamka wytrychem) zabezpiecza system alarmowy. > Pewnie da się użyć sensowne pamięci, żeby odrobinę zwiększyć bezpieczeństwo. Ale znacznie ważniejsze jest np. dopracowanie alarmu. Choćby dlatego, że przecież nie zrezygnujemy z tradycyjnego zamka na wypadek niespodziewanych problemów, prawda? A tradycyjny zamek można otworzyć bez kluczy. Tylko kwestia doświadczenia włamywacza i czasu. Zgoda. To na razie tylko pomysł, jeszcze do przegadania.

Ja nie zakładałbym że dostawcy tych innych kart przyjęli takie założenie i że nasza ekstra funkcja nie będzie kolidować z ichnymi.

Pisząc, że obecnie założenie nie jest spełnione chodziło mi o to:

Założeniem jest dedykowana karta do HSu.

Dlatego pytam, czy potrzebujemy użyć pamięci kart zamiast samego ID, co jest raczej standardem w tego typu rozwiązaniach.

> Ja nie zakładałbym że dostawcy tych innych kart przyjęli takie założenie i że nasza ekstra funkcja nie będzie kolidować z ichnymi. Pisząc, że obecnie założenie nie jest spełnione chodziło mi o to: > Założeniem jest dedykowana karta do HSu. Dlatego pytam, czy potrzebujemy użyć pamięci kart zamiast samego ID, co jest raczej standardem w tego typu rozwiązaniach.
Author
Owner

Tak, w tym przypadku potrzebna jest zapisywalna pamięć na karcie.

Tak, w tym przypadku potrzebna jest zapisywalna pamięć na karcie.
This repo is archived. You cannot comment on issues.
No Label
No Milestone
No Assignees
2 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: HSWro/zamek-hswro#9
No description provided.