Dodać hashowanie + solenie kluczy #1

Open
opened 2019-05-18 19:03:46 +00:00 by lechu · 12 comments
Owner
No description provided.

Mamy jakieś hasła tam? Czy też miałeś na myśli identyfikatory tagów?

Mamy jakieś hasła tam? Czy też miałeś na myśli identyfikatory tagów?
Author
Owner

Tak, mam na myśli klucze, czyli IDki. Inna sprawa jest taka, że można by na nich nie polegać.

Tak, mam na myśli klucze, czyli IDki. Inna sprawa jest taka, że można by na nich nie polegać.
lechu changed title from Dodać hashowanie + solenie haseł to Dodać hashowanie + solenie kluczy 2019-05-18 19:48:07 +00:00

Tylko przy założeniu, że używamy kart dedykowanych do HS. Kontynuacja w #9?

Tylko przy założeniu, że używamy kart dedykowanych do HS. Kontynuacja w #9?
Author
Owner

Nie. Samo zahashowanie IDków już ma sens. Nawet tych wkompilowanych w kod. Bo zabezpiecza przed atakami timingowymi.

Nie. Samo zahashowanie IDków już ma sens. Nawet tych wkompilowanych w kod. Bo zabezpiecza przed atakami timingowymi.

O ile mi wiadomo, do wyboru mamy ID i pamięć. Napisałeś "można by na nich nie polegać", zakładam, że mówiłeś o ID. Zwróciłem uwagę, że nie wszyscy używają kart dedykowanych do HS, a tylko w takich możemy bezpiecznie zapisywać dane.

Hash nie jest jakimś złym pomysłem, choć mam wątpliwości o ile zwiększy odporność (z powodu słabego procesora nie można dać zbyt wielu iteracji).

Zabezpiecza przed atakami timingowymi? Przecież hash wykonuje się w przybliżeniu w stałym czasie, nie?

O ile mi wiadomo, do wyboru mamy ID i pamięć. Napisałeś "można by na nich nie polegać", zakładam, że mówiłeś o ID. Zwróciłem uwagę, że nie wszyscy używają kart dedykowanych do HS, a tylko w takich możemy bezpiecznie zapisywać dane. Hash nie jest jakimś złym pomysłem, choć mam wątpliwości o ile zwiększy odporność (z powodu słabego procesora nie można dać zbyt wielu iteracji). Zabezpiecza przed atakami timingowymi? Przecież hash wykonuje się w przybliżeniu w stałym czasie, nie?
Author
Owner

Tak, miałem na myśli niepoleganie na ID (ale można ich użyć jako "login"), a w pamięci trzymać, ekhm, "blockchain" czyli kody tymczasowe odpowiadające za unieważnianie klonów.

Hash daje dwie rzeczy:

  • Nie wyciągniesz kluczy z pamięci procka bez łamania hashy - a hashowanie i solenie kluczy da się ogarnąć nawet compile-time (bo C++14)
  • Hashe liczą się mniej-więcej w stałym czasie i nie ma w nich otwartych porównań/xorów, więc odpadają side-channele czasowe I na zasilaniu.
Tak, miałem na myśli niepoleganie na ID (ale można ich użyć jako "login"), a w pamięci trzymać, ekhm, "blockchain" czyli kody tymczasowe odpowiadające za unieważnianie klonów. Hash daje dwie rzeczy: - Nie wyciągniesz kluczy z pamięci procka bez łamania hashy - a hashowanie i solenie kluczy da się ogarnąć nawet compile-time (bo C++14) - Hashe liczą się mniej-więcej w stałym czasie i nie ma w nich otwartych porównań/xorów, więc odpadają side-channele czasowe _I_ na zasilaniu.
Author
Owner

...a obecna metoda "xor znak po znaku plus or ze wszystkich xorów) nie daje, bo są możliwe ataki przez analizę zasilania. Been there, done that.

...a obecna metoda "xor znak po znaku plus or ze wszystkich xorów) nie daje, bo są możliwe ataki przez analizę zasilania. Been there, done that.

Hashe liczą się mniej-więcej w stałym czasie i nie ma w nich otwartych porównań/xorów, więc odpadają side-channele czasowe I na zasilaniu.

Przecież to jest na odwrót: jeżeli coś jest wykonywane w stałym czasie, nie jest zabezpieczeniem.

a w pamięci trzymać, ekhm, “blockchain” czyli kody tymczasowe odpowiadające za unieważnianie klonów.

I to jest właśnie to, co skomentowałem, jak napisałeś, że możemy nie polegać na ID.

> Hashe liczą się mniej-więcej w stałym czasie i nie ma w nich otwartych porównań/xorów, więc odpadają side-channele czasowe I na zasilaniu. Przecież to jest na odwrót: jeżeli coś jest wykonywane w stałym czasie, **nie** jest zabezpieczeniem. > a w pamięci trzymać, ekhm, “blockchain” czyli kody tymczasowe odpowiadające za unieważnianie klonów. I to jest właśnie to, co skomentowałem, jak napisałeś, że możemy nie polegać na ID.

…a obecna metoda “xor znak po znaku plus or ze wszystkich xorów) nie daje, bo są możliwe ataki przez analizę zasilania. Been there, done that.

Teraz chyba przesadziłeś. Elektronika powinna być dostępna wyłącznie po wejściu, nie przed. Jak się obawiasz ataków na obudowy, możemy je podpiąć jako sabotaż do systemu alarmowego.

> …a obecna metoda “xor znak po znaku plus or ze wszystkich xorów) nie daje, bo są możliwe ataki przez analizę zasilania. Been there, done that. Teraz chyba przesadziłeś. Elektronika powinna być dostępna wyłącznie **po** wejściu, nie przed. Jak się obawiasz ataków na obudowy, możemy je podpiąć jako sabotaż do systemu alarmowego.
Author
Owner

No chyba nie. Do takiego czytnika kart, który jest po stronie zewnętrznej też trzeba dociągnąć zasilanie.
Jak już bawić się w wykrywanie sabotażu, to można permanentnie blokować sam zamek po wykryciu np. odkręcenia panelu.

No chyba nie. Do takiego czytnika kart, który jest po stronie zewnętrznej też trzeba dociągnąć zasilanie. Jak już bawić się w wykrywanie sabotażu, to można permanentnie blokować sam zamek po wykryciu np. odkręcenia panelu.
Author
Owner

Z resztą... ataki side-channel i tak wykonuje się na biurku a nie on-site. Oba rodzaje.
Może trochę przesadzam z zabezpieczeniami, ale sądzę, że jeżeli już warto coś zrobić, to warto to zrobić najlepiej jak to możliwe.

Z resztą... ataki side-channel i tak wykonuje się na biurku a nie on-site. Oba rodzaje. Może trochę przesadzam z zabezpieczeniami, ale sądzę, że jeżeli już warto coś zrobić, to warto to zrobić najlepiej jak to możliwe.

Rzeczywiście, zapomniałem, że mieliśmy zamontować coś takiego na bramie. Możliwe jednak, że w nowym lokalu nie będzie takiej sytuacji.

Z założenia mamy kontrolę na instalacją urządzeń. Skupiłbym się raczej na ochronie obudowy, wykrywaniu otwarcia itd. niż ochronie przed atakiem przez zasilania. Jak dołożysz połączenie z LDAP, to cache aktualnych kluczy można trzymać w RAM i usuwać w razie podejrzeń ataku.

Rzeczywiście, zapomniałem, że mieliśmy zamontować coś takiego na bramie. Możliwe jednak, że w nowym lokalu nie będzie takiej sytuacji. Z założenia mamy kontrolę na instalacją urządzeń. Skupiłbym się raczej na ochronie obudowy, wykrywaniu otwarcia itd. niż ochronie przed atakiem przez zasilania. Jak dołożysz połączenie z LDAP, to cache aktualnych kluczy można trzymać w RAM i usuwać w razie podejrzeń ataku.
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#1
No description provided.