Jak zmusić drużynę do uczciwości (przestrzegać zasad protokołu)?
Widziałem pewne mechanizmy, takie jak zobowiązania, dowody itp., Ale wydaje się, że nie rozwiązują one całego problemu. Wydaje mi się, że struktura projektu protokołu i takie mechanizmy muszą działać. Czy ktoś ma dobrą klasyfikację tego.
Edytuj
Podczas projektowania bezpiecznych protokołów, jeśli zmusisz stronę do uczciwości, projekt byłby o wiele łatwiejszy, chociaż wymuszenie ma swoją własną korzyść. Widziałem, projektując bezpieczne protokoły, projektanci zakładają coś, co nie wydaje mi się realistyczne, na przykład zakładają, że wszystkie strony są uczciwe w najgorszym przypadku lub zakładają uczciwość serwera, który utrzymuje dane użytkownika. Ale patrząc na projektowanie protokołów w bardziej rygorystycznych modelach rzadko widzi się takie założenia (przynajmniej tego nie widziałem - przeważnie studiuję protokoły nadRamy UC Canetti, które moim zdaniem nie są jeszcze całkowicie sformalizowane). Zastanawiałem się, czy istnieje jakaś dobra klasyfikacja sposobów, w jaki można zmusić imprezę do uczciwości, czy też istnieje jakiś kompilator, który może przekonwertować protokół wejściowy na taki, który ma uczciwe strony?
Teraz wyjaśnię, dlaczego uważam, że to po prostu nie działa, choć może się to wydawać nieistotne. Podczas projektowania protokołów w ramach UC, które korzystają z idealnego / rzeczywistego paradygmatu, każde łącze komunikacyjne w modelu idealnym jest uwierzytelniane, co nie jest prawdą w modelu rzeczywistym. Dlatego projektanci protokołów poszukują alternatywnych metod implementacji tego kanału za pomocą założenia PKI lub CRS (Common Reference String). Ale podczas projektowania protokołów uwierzytelniania błędne jest zakładanie uwierzytelnionych kanałów. Załóżmy, że projektujemy protokół uwierzytelniania w ramach UC, istnieje atak, w którym przeciwnik fałszuje tożsamość strony, ale z powodu założenia uwierzytelnionych łączy w idealnym modelu tego ataku nie zakłada się w tej strukturze! Możesz się odnieść doModelowanie ataków wewnętrznych na protokoły wymiany kluczy grupowych . Można zauważyć, że Canetti w swojej przełomowej pracy Uniwersalne pojęcia wymiany kluczy i bezpiecznych kanałów wspominają wcześniejsze pojęcie bezpieczeństwa o nazwie SK-Security, które jest po prostu wystarczające do zapewnienia bezpieczeństwa protokołów uwierzytelniania. Jakoś wyznaje (stwierdzając, że jest to kwestia techniczna), że definicja UC w tym kontekście jest zbyt restrykcyjna i zapewnia zrelaksowany wariant zwany wyrocznią nieinformacyjną (która mnie pomyliła, ponieważ nigdzie nie widziałem tego modelu bezpieczeństwa , Nie mogę dopasować tego wzorca bezpieczeństwa do żadnego innego wzorca bezpieczeństwa, prawdopodobnie mój brak wiedzy: D).
[Na marginesie, możesz prawie przekonwertować dowolny protokół Sk-bezpieczny na bezpieczny UC, niezależnie od czasu symulatora. Na przykład możesz po prostu usunąć podpisy wiadomości i poprosić symulator o symulację wszystkich interakcji w sposób pozorny. Zobacz dowód wymiany uniwersalnej grupy kontrybucyjnej grupy kontrybucyjnej ! Załóżmy teraz, że jest to protokół wymiany kluczy grupowych z wielomianowo wieloma stronami, jaka byłaby wydajność symulatora? To jest pochodzenie mojego drugiego pytania na tym forum .]
W każdym razie, z powodu braku zaangażowania w zwykły model (nad UC), szukałem innych środków, aby zabezpieczyć protokół, po prostu omijając potrzebę tego rozluźnienia. Pomysł ten jest tak bardzo podstawowy w mojej głowie i przyszedł mi do głowy, po prostu przestudiowałem najnowszy schemat zobowiązań canetti w prostym modelu: twardość adaptacyjna i bezpieczeństwo kompozycyjne w modelu prostym ze standardowych założeń .
BTW, nie szukam dowodów zerowej wiedzy, ponieważ z przyczyn, których nie znam, ilekroć ktoś używał jednego z nich w równoległym protokole (w ramach UC), inni wspominali o protokole jako nieefektywnym (może być z powodu przewinięcia symulatora).