W dniu 29 maja 2014 13:46 użytkownik spin@hackerspace.pl napisał:
On 2014-05-29 13:14, Marek Zibrow wrote:
W dniu 29 maja 2014 10:47 użytkownik Paweł Zegartowski pzegar@gmail.com napisał:
Fizyczne tokeny utrudniają też łatwe zwiększenie liczby kluczy. No i oczywiscie podnoszą koszta.
Problem z wirtualnymi jest niestety podobny (plus parę innych związanych z ich tworzeniem). Niestety każde zgłoszenie utraty tokenu to powtórna generacja wszystkiego dla wszystkich. Oczywiście softtoken jest tani, można nawet stwierdzić, że bezpłatny, tylko co z tego, kiedy ponowne losowanie wszystkich tokenów (z utopijnym założeniem, że nikt nie rejestruje pobrania softtokena ze storage'u) jest niemal równie niepraktyczne jak ponowne losowanie fizycznych smartcard. Dodatkowo powtórzę jeszcze raz moją tezę, że system taki jest kompletnie nieodporny na złośliwe zgłoszenia utraty. Naprawdę nie mam ochoty nikogo onieśmielać bo jak wiadomo należy atakować problemy i szukać nowych rozwiązań ale wydaje mi się, że to było już parę razy przerabiane a sam rynek udowadnia dlaczego to nie działa... Stąd oprócz zapotrzebowania rysia postawiłbym pytanie:
Jak zrealizować to za pomocą typowego center-of-trust tak, żeby wilk był syty i owca cała?
Zgniły kompromis? Pewnie tak. Ale to jak z dzieleniem przez 0. Czy dyskusję można poprowadzić także w tym kierunku? Rysiu?
Pojadę "teorią" dlaczego uważam sprawę za z góry przegraną i mam nadzieję, że ktoś to zrozumie i przestaniemy przynajmniej powtarzać podstawowe błędy (matko jak ja nie lubię być malkontentem, ale muszę): Wszystkie znane mi systemy set-of-trust działają w przestrzeni zaufania gdzie każdy element setu jest znany wszystkim pozostałym i w każdej chwili wywoływalny. Set-of-trust w przestrzeni niezaufanej nie sprawdza się. Nie dlatego, że nie da się tego stworzyć. Tylko dlatego, że każde usunięcie elementu, brak dostępu do elementu, dodanie elementu, powoduje że set-of-trust staję się nietrust.
Ja bym poszedł w stronę ograniczenia strat.
Ponieważ ilość postów spod każdego klucza prowadzi do deanonimizacji w określonym czasie opisanym zachowaniem uzytkownika(od analizy danych po analizę semantyczną), trzeba te klucze generować ponownie co jakiś czas tak czy inaczej, więc powinny one być generowane per-project albo per-year albo coś.
Dodatkowa zmienna to generowanie kluczy jeśli zostanie zgłoszone zagubienie lub kradzieź ich 30%. "tough life bro, you don't lose your kids, your car, your money, I think you can keep a card - if not now, then maybe on the 2nd time".
Można stopień utraty ograniczyć losowaniem kilku powiązanych kluczy (jeden token, kilka kluczy. karta snap-off czy coś) i upewnieniem się ze zostanę rozmieszczone w różnych partiach ubrania delikwenta (torba, kieszeń, kurtka, whatevs). (za każdym razem jak myślę że coś jest owerkilem na głupotę ludzką, ludzkość mnie zaskakuje)
Jeżeli user jest znany z imienia i nazwiska (ale nie tokenu) to w przypadku faktycznej fizycznej utraty zgłasza ją i prosi o unieważnienie postów po określonej dacie zagubienia. Or not.
tl;dr: jeżeli utrata klucza jest problemem, trzeba doprowadzić do sytuacji w której ta utrata będzie mało prawdopodobna.
Bardzo sensowne to co powiedziałeś i popieram w całej rozciągłości. +1