Praktyczne protokoły prywatnego pozyskiwania informacji

Uniwersytet Warszawski
Wydział Matematyki, Informatyki i Mechaniki
Tomasz Jadachowski
Nr albumu: 181263
Praktyczne protokoły prywatnego
pozyskiwania informacji
Praca magisterska
na kierunku INFORMATYKA
w zakresie OPROGRAMOWANIA I METOD INFORMATYKI
Praca wykonana pod kierunkiem
dra Stefana Dziembowskiego
Instytut Informatyki
Styczeń 2005
Oświadczenie kierującego pracą
Oświadczam, że niniejsza praca została przygotowana pod moim kierunkiem i stwierdzam, że spełnia ona warunki do przedstawienia jej w postępowaniu o nadanie tytułu
zawodowego.
Data
Podpis kierującego pracą
Oświadczenie autora pracy
Świadom odpowiedzialności prawnej oświadczam, że niniejsza praca dyplomowa
została napisana przeze mnie samodzielnie i nie zawiera treści uzyskanych w sposób
niezgodny z obowiązującymi przepisami.
Oświadczam również, że przedstawiona praca nie była wcześniej przedmiotem procedur związanych z uzyskaniem tytułu zawodowego w wyższej uczelni.
Oświadczam ponadto, że niniejsza wersja pracy jest identyczna z załączoną wersją
elektroniczną.
Data
Podpis autora pracy
Streszczenie
W pracy tej rozważamy protokoły prywatnego pozyskiwania informacji, koncentrując się
na ich praktycznych aspektach. Rozpoczniemy od zdefiniowania zagadnienia i opisania co
oznacza, że protokół prywatnego pozyskiwania informacji jest bezpieczny w różnych modelach obliczeniowych. Następnie, koncentrując się na modelu obliczeniowym, zaprezentujemy
protokoły prywatnego pozyskiwania informacji i udowodnimy ich bezpieczeństwo opierając się
na trudności rozwiązania problemu należenia do podgrupy. Przedstawimy też protokoły prywatnego wyszukiwania słów kluczowych, umożliwiające bardziej praktyczne wykorzystanie
protokołów prywatnego pozyskiwania informacji. Wszystko to wykorzystamy do zaprezentowania praktycznej aplikacji implementującej wyżej wymienione protokoły. Opiszemy także
użyte optymalizacje protokołów i osiągnięte wyniki wydajnościowe na praktycznym zbiorze
danych oraz wskażemy przyszłe kierunki rozwoju, tej stosunkowo młodej dziedziny jaką jest
prywatne pozyskiwanie informacji.
Słowa kluczowe
Private Information Retrieval, PIR, Symmetrically Private Information Retrieval, SPIR, Subgroup Membership Problem, PERKY, prywatne pozyskiwanie informacji, symetryczne prywatne pozyskiwanie informacji, wyszukiwanie po słowach kluczowych, problem należenia do
podgrupy, reszty kwadratowe, decyzyjny problem Diffiego-Hellmana
Dziedzina pracy (kody wg programu Socrates-Erasmus)
11.3 Informatyka
Klasyfikacja tematyczna
68 Computer Source
68P Theory of Data
68P20 Information storage and retrieval
68P25 Data encryption
Spis treści
Wstęp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1. Wprowadzenie do prywatnego pozyskiwania informacji . . . . . . . . .
1.1. Nieformalnie o prywatnym pozyskiwaniu informacji . . . . . . . . . . . . .
1.2. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Motywacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4. Podstawowe definicje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1. Prywatne pozyskiwanie informacji (Private Information Retrieval)
1.4.2. Bezpieczeństwo PIR . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.3. Decyzyjny problem reszt kwadratowych . . . . . . . . . . . . . . .
1.4.4. Decyzyjny problem Diffiego-Hellmana . . . . . . . . . . . . . . . .
1.4.5. Problem należenia do podgrupy . . . . . . . . . . . . . . . . . . . .
1.5. Warianty prywatnego pozyskiwania danych . . . . . . . . . . . . . . . . .
1.5.1. Teorio-informacyjny 1-serwerowy PIR . . . . . . . . . . . . . . . .
1.5.2. Inne modele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
8
9
9
10
10
12
14
15
15
16
2. 1-serwerowy obliczeniowy PIR . . . . . . . . . . .
2.1. Uogólniony protokół Kushlevitza i Ostrovskyego
2.1.1. Uproszczona wersja protokołu . . . . . . .
2.1.2. Właściwy protokół . . . . . . . . . . . . .
2.1.3. Przykład . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
19
19
19
21
24
3. Prywatne wyszukiwanie słów kluczowych . . . . . . . . . . . . . . . . . . . .
3.1. Praktyczne zastosowanie uogólnionego protokołu Kushlevitza i Ostrovskyego
3.2. Podstawowe definicje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Uogólniony PIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2. PERKY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3. Porównanie PIR i PERKY . . . . . . . . . . . . . . . . . . . . . . . .
3.3. Wyszukiwanie informacji po słowach kluczowych . . . . . . . . . . . . . . . .
3.3.1. Wyszukiwanie binarne . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2. Wyszukiwanie prefiksowe . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3. Wzmocnienie protokołu PERKY (wyszukiwanie prefiksowe) . . . . . .
27
27
27
28
28
28
29
29
29
31
4. Implementacja . . . . . . . . . . . . . . . .
4.1. Narzędzia . . . . . . . . . . . . . . . . .
4.2. Przyjęte założenia . . . . . . . . . . . .
4.2.1. Długość klucza . . . . . . . . . .
4.3. Architektura implementacji . . . . . . .
4.3.1. Dekompozycja logiczna systemu
33
33
33
33
34
34
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.3.2. Najważniejsze komponenty . . . . . . . . . . . . . . . . . . . . . . . .
4.4. Osiągnięte rezultaty (testy) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
36
5. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1. Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2. Kierunki rozwoju . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
41
41
A. Zawartość płyty CD
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
B. Działanie aplikacji . .
B.1. Kompilacja . . . .
B.2. Uruchamianie . . .
B.3. Działanie aplikacji
.
.
.
.
45
45
45
47
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Wstęp
W ciągu ostatnich lat obserwujemy znaczny wzrost liczby użytkowników sieci Internet na
całym świecie. Coraz więcej spraw załatwianych jest drogą elektroniczną. Szeroko stosowane
są techniki kryptograficzne, w tym podpis elektroniczny i szyfrowanie kluczem publicznym,
jednak i one są niewystarczające.
Większość używanych dziś internetowych systemów informatycznych, takich jak sklepy
internetowe czy serwisy informacyjne, korzysta z architektury klient - serwer. Systemy te są
coraz bardziej liczne i mają coraz więcej użytkowników (klientów). Wiedza o preferencjach
użytkownika nabiera więc coraz większej wartości. Może być jednak ona wykorzystana przeciwko użytkownikowi. Przez długi czas przyjmowano, że będzie ona tajemnicą dla wszystkich
za wyjątkiem serwera. Zakładano, że serwer nie zastosuje wiedzy o użytkowniku przeciwko
niemu. Założenie to jest jednak bezpodstawne.
Jedna z największych firm zajmujących się sprzedażą online (szczegóły można znaleźć
w [1]) uznała, że jej baza zawierająca miliony profili użytkowników i ich preferencji handlowych jest częścią kapitału firmy, a zatem może stać się przedmiotem umowy handlowej. W
szczególności baza może więc być sprzedana innej firmie bez zgody użytkowników.
Jest nawet gorzej. Serwer, choć uczciwy, może mieć poważne luki w zabezpieczeniach,
co pozwala na kradzież informacji o użytkownikach. Ocenia się, że około 50% największych
serwerów internetowych naraża w ten sposób prywatność swoich użytkowników na szwank.
Firma może być również zmuszona do sprzedaży bazy z informacjami o użytkownikach
na skutek bankructwa.
W dzisiejszych czasach bezpieczeństwo preferencji użytkownika zależne jest więc w dużej
mierze od dobrej kondycji firmy, od zabezpieczeń przez nią stosowanych, a także jej uczciwości.
Jasne jest, że czynniki te nie będą wszystkie wiecznie spełnione.
Choć wydaje się to niemożliwe, krokiem w kierunku rozwiązania tego problemu jest technika pozwalająca użytkownikowi utrzymywać swoje preferencje w tajemnicy przed serwerem.
Nazywana jest ona w literaturze prywatnym pozyskiwaniem informacji ( ang. Private Information Retrieval) w skrócie PIR.
Ogólnie i nieformalnie mówiąc, prywatne pozyskiwanie informacji umożliwia użytkownikowi pobranie pewnych informacji od serwera, zgodnie z jego preferencjami, w taki sposób,
że serwer nie wie jakie to informacje pobiera użytkownik. By to osiągnąć klient koduje swoje
zapytanie i przesyła je do serwera, który to przetwarza je, a następnie powstałą odpowiedź
wysyła do klienta. Następnie klient odkodowuje odpowiedź i poznaje rezultat zapytania.
Od momentu sformalizowania w 1995 roku pierwszego protokołu PIR, powstały setki prac,
z wieloma analizami i nowymi protokołami. Większość z nich dotyczy jednak przypadku
gdzie zakłada się istnienie kilku serwerów, posiadających tę samą kopię bazy danych i nie
mogących komunikować się ze sobą. My skoncentrujemy się tylko na przypadku, w którym
istnieje tylko jeden serwer, podając tylko niektóre fakty w formie ogólniejszej. Przypadek ten
jest najbardziej praktyczny i bezpieczny, gdyż nie musimy zakładać wtedy braku komunikacji
5
pomiędzy serwerami.
W pracy tej dokonamy krótkiego przeglądu jednoserwerowych protokołów prywatnego
pozyskiwanie informacji i szczegółowo zanalizujemy jeden z nich. Wybór protokołu będzie
uzasadniony jego dużym bezpieczeństwem (przedstawiony będzie jego pełny dowód bezpieczeństwa) i łatwością zaaplikowania do rzeczywistych warunków. Postawimy sobie za zadanie,
zbadanie przy jakiej ilości informacji serwer jest w stanie, w rozsądnym czasie udzielić odpowiedzi i jak dużo danych musi przekazać w odpowiedzi na zapytanie użytkownika oraz
jak duże musi być to zapytanie. Pokażemy również jak można wykorzystać protokoły PIR w
praktyce, poprzez zaprezentowanie aplikacji z opisanymi w pracy protokołami.
W rozdziale 1 przedstawimy podstawowe definicje wprowadzające do tematyki PIR. Rozdział 2 przedstawia opis uogólnionego protokołu PIR Kushlevitza i Ostrovskyego. W rozdziale
3 przedstawimy protokół umożliwiający prywatne wyszukiwanie informacji po słowach kluczowych. W kolejnym rozdziale 4 przedstawimy ogólną architekturę aplikacji implementującej
przedstawione wcześniej protokoły oraz zaprezentujemy jej analizę wydajnościową. W ostatnim rozdziale 5 podsumujemy otrzymane rezultaty oraz wskażemy co obecnie jest wąskim
gardłem protokołów PIR.
6
Rozdział 1
Wprowadzenie do prywatnego
pozyskiwania informacji
1.1. Nieformalnie o prywatnym pozyskiwaniu informacji
PIR jest pojęciem charakteryzującym protokoły pomiędzy dwiema stronami, serwerem (w
ogólności serwerów może być kilka, ale dla zaprezentowania idei założymy, że jest tylko jeden) zarządzającym bazą danych i użytkownikiem chcącym dowiedzieć się pewnych informacji
z bazy danych. Informacje te, użytkownik chce otrzymać w taki sposób, by serwer nie dowiedział się ”nic” o preferencjach użytkownika. Najprostszym rozwiązaniem tak postawionego
problemu jest wysłanie przez serwer do użytkownika całej zawartości bazy danych. W ten
sposób użytkownik pozna informację którą chciał uzyskać, bo pozna całą zawartość bazy
danych. Jasne jest, że takie rozwiązanie jest nie do przyjęcia z dwóch powodów:
• po pierwsze baza danych może być zbyt duża, żeby w rozsądnym czasie dało się ją
przesłać łączem internetowym,
• a po drugie serwer może nie chcieć zdradzać wszystkich informacji zawartych w bazie
danych (np. w przypadku dokonywania płatności za każdą pobraną informację przez
użytkownika), poza jedną.
Zadaniem praktycznych protokołów PIR jest więc minimalizacja komunikacji pomiędzy serwerem i użytkownikiem, a także utajnianie informacji zawartych w bazie danych, poza jedną
informacją, którą użytkownik chce poznać.
Gdy mamy doczynienia z większą ilością serwerów, każdy z nich przechowuje tę samą
kopię bazy danych. Zakłada się wtedy brak współpracy (wymiany informacji o komunikacji
z użytkownikiem) ze strony tych serwerów. Jest to dość silne założenie, lecz w pewnych
przypadkach model ten jest akceptowalny.
Zwykle bazę danych traktuje się jako wektor n bitów, natomiast zapytanie użytkownika jako pytanie o wartość i-tego bitu. Napotykamy jednak tutaj na pewien problem. Skąd
użytkownik ma wiedzieć który bit go interesuje? W dalszej części pracy pokażemy w jaki sposób korzystając z protokołów PIR, skonstruować protokół wyższego poziomu, dzięki któremu
możemy dowiedzieć się gdzie znajduje się interesujący nas bit.
1.2. Historia
Prywatne pozyskiwanie informacji jest stosunkowo nową dziedziną kryptografii, sformalizowaną przez Chora, Goldreicha, Kushlevitza i Sudana ([2]) w 1995 roku. Przedstawili oni wte7
dy protokół PIR, bezpieczny w modelu teorio-informacyjnym. Niestety schemat ten nie jest
zbyt praktyczny ponieważ wymaga więcej niż jednego serwera przechowującego tę samą bazę
danych, przy założeniu braku komunikacji pomiędzy poszczególnymi serwerami. Niepraktyczność tego protokołu jest również wynikiem wyboru modelu teorio-informacyjnego, w którym
przyjmuje się, że serwery posiadają nieskończoną moc obliczeniową. W takim przypadku (jak
pokazano również w tej pracy), gdy istnieje jeden serwer, niemożliwe jest skonstruowanie
bezpiecznego protokołu PIR o lepszej złożoności komunikacyjnej niż protokół przesyłający
całą zawartość bazy danych do użytkownika.
W 1997 roku Chor i Gilboa ([3]) przedstawili protokół PIR bezpieczny w modelu obliczeniowym, czyli zakładając pewne ograniczenia na moc obliczeniową serwerów. Niestety i ten
protokół wymagał istnienia więcej niż jednego serwera.
Przełomowa pod tym względem okazała się praca Kushlevitza i Ostrovskyego ([4]) z 1997
roku, w której to autorzy pokazali schemat prywatnego pozyskiwania informacji w modelu
obliczeniowym z jednym serwerem. Złożoność komunikacyjna tego protokołu wynosi O(n² ),
dla dowolnie małego epsilon, gdzie n oznacz ilość bitów w bazie danych. Bezpieczeństwo tego
protokołu bazuje na trudności odróżnienia reszt od niereszt kwadratowych.
Protokół ten został następnie uogólniony przez Akihiro Yamamure i Taiichi Saito ([5]) na
dowolny problem należenia do podgrupy. Właśnie między innymi tym protokołem będziemy
zajmować się w naszej pracy. Dowód bezpieczeństwa opisanego przez Akihiro Yamamure i
Taiichi Saito protokołu PIR został przez nich pominięty. Dlatego też w naszej pracy przedstawimy pełny jego dowód.
Pierwszym w literaturze protokołem PIR o złożoności polilogarytmicznej jest protokół
przedstawiony przez Christian Cashin, Silvio Micali i Markusa Stadlera ([6]) w 1999 roku.
Protokół ten bazuje na założeniu o trudności rozwiązania problemu φ-Hiding (na dzień dzisiejszy nie można powiedzieć, że ten problem został należycie zbadany by uznać, że nie da
się go rozwiązać w stosunkowo łatwy sposób), który ogólnie rzecz ujmując polegał na sprawdzeniu czy pewna mała liczba pierwsza dzieli φ(m), dla pewnej złożonej liczby naturalnej m
o nieznanej faktoryzacji.
Następnie w 2001 roku Aggelos Kiayias i Moti Yung w pracy ”Secure Games with Polynomial Expressions” ([7]) zaprezentowali polilogarytmiczny protokół PIR (efektywniejszy od
protokołu Micali i Stadlera), dodatkowo umożliwiający w trakcie jednego wykonania pobranie
bloku bitów zamiast tylko jednego. Bezpieczeństwo tego protokołu opierało się na trudności
rozwiązania problemu wieloinstancyjnej rekonstrukcji wielomianu (ang. Multisample Polynomial Reconstruction). Niestety założenie o trudności tego problemu okazało się fałszywe,
gdyż Don Coppersmith i Madhu Sudan zademonstrowali w pracy ”Reconstructing Curves in
Three (and Higher) Dimensional Space from Noisy Data” ([8]) efektywny probabilistyczny
algorytm rozwiązujący ten problem.
W lutym 2004 roku został zaprezentowany pierwszy protokół PIR o złożoności komunikacyjnej logarytmicznej w pracy ”Single Database Private Information Retrieval with Logarithmic Communication” ([9]) autorstwa Yan-Cheng Changa. Protokół ten bazuje na dość
dobrze zbadanym kryptosystemie Pailliera.
Jak widzimy, z zaprezentowanego przeglądu prac, dziedzina prywatnego pozyskiwania
informacji przeżywa burzliwy rozwój. Wciąż powstają nowe protokoły, niestety dla większości
z nich bezpieczeństwo nie jest dość dobre, gdyż bazuje na niedogłębnie zbadanych założeniach.
1.3. Motywacja
Przedstawimy teraz kilka przykładów zastosowania protokołów PIR w praktyce.
8
Zazwyczaj firmy farmaceutyczne zajmują się wynajdowaniem nowych leków lub też zbieraniem informacji na temat składników, z których tworzy się leki. Proces tworzenia nowego
leku wymaga informacji o właściwościach jego podstawowych składników, które to zwykle
znajdują się w bazie danych, będącej w posiadaniu innej firmy. W celu ukrycia planów, koncerny farmaceutyczne kupują więc często całą bazę danych, by w ten sposób ukryć swoje
plany na temat nowego środka. W wyniku tego ponoszą bardzo duże wydatki, których można by uniknąć, stosując protokoły prywatnego pozyskiwania informacji do kupienia tylko
interesujących ich informacji na temat kilku składników.
Przedstawimy teraz sytuację zaproponowaną przez Isabell Duchesnay w [10]. Rozważmy
szpiega posiadającego wiele sekretów, z których każdy ma swój tytuł, jak na przykład ”gdzie
jest Bin Laden”. Oczywiście szpieg nie chciałby zdradzać dwóch sekretów za cenę jednego.
Nawet częściowy wyciek informacji o innym sekrecie niż ten sprzedawany jest dla niego nie
do przyjęcia. Potencjalny kupiec, może też chcieć utrzymać w tajemnicy informację o tym
czego szuka, ponieważ wiedza na ten temat może być wartościowa dla szpiega i może być dalej
sprzedana pod tytułem ”kto szuka Bin Ladena”. W przedstawionej sytuacji stosując protokoły
prywatnego pozyskiwania informacji możemy zadowolić obie strony - kupca i szpiega.
Na koniec przedstawimy jeszcze jeden przykład zastosowania protokołu PIR. Rozważmy
bazę danych z patentami i użytkownika chcącego sprawdzić czy dany patent znajduje się w
wyżej wymienionej bazie. Przypuśćmy, że tym użytkownikiem jest pewien naukowiec, który
odkrywa genialny wzór: ’2 + 2 = 4’. Oczywiście chce go opatentować. W tym celu sprawdza
najpierw w bazie danych patentów czy wzór ten już tam jest. Administrator takiej bazy danych, może z łatwością poznać zapytanie naukowca. Następnie może spróbować opatentować
jako pierwszy skradziony wzór. Nawet jeśli wzór ten okaże się niezbyt zachęcający do opatentowania, administrator bazy danych dowiaduje się czego dotyczą badania prowadzone przez
naukowca.
1.4. Podstawowe definicje
W sekcji tej przedstawimy podstawowe definicje potrzebne do zrozumienia dalszej części
pracy.
Ograniczymy się tutaj do zdefiniowania obliczeniowego prywatnego pozyskiwania danych
z jednym serwerem. W dalszej części pracy pisząc o obliczeniowym prywatnym pozyskiwaniu danych mamy zazwyczaj na myśli istnienie tylko jednego serwera, chyba że wyraźnie
zaznaczymy, że jest inaczej.
1.4.1. Prywatne pozyskiwanie informacji (Private Information Retrieval)
Prywatne pozyskiwanie informacji jest protokołem pomiędzy dwiema stronami:
• S - serwer zarządzający bazą danych,
• U - użytkownik chcący poznać pewne informacje z tej bazy.
→
Przyjmujemy, że baza danych posiadana przez serwer S jest wektorem −
x = [x0 , x1 , ..., xn−1 ]
n
∈ {0, 1} złożonym z n bitów. Użytkownik posiada zaś liczbę naturalną i ∈ {0, ..., n − 1}. W
wyniku działania protokołu użytkownik powinien poznać bit xi , w taki sposób by serwer nie
poznał wartości i.
U możemy formalnie zdefiniować jako probabilistyczną i interaktywną maszynę Turinga
z jedną taśmą tylko do odczytu, jedną tylko do zapisu, jedną taśmą tylko do odczytu z
zapisanymi losowymi bitami i dwiema komunikacyjnymi taśmami:
9
• tylko do zapisu, przeznaczona do wysyłania wiadomości do S.
• tylko do odczytu, przeznaczona do czytania wiadomości od S
Analogicznie definiujemy S z tą różnicą, że S posiada dodatkową taśmę z zapisanym na
→
niej wektorem −
x , a komunikacja poprzez taśmy odbywa się z U.
Przedstawimy teraz schemat protokołu PIR:
1. Na początku U i S mają na swojej taśmie do odczytu ten sam parametr bezpieczeństwa
1k , natomiast taśma z losowymi bitami używana przez U jest znana tylko jemu.
2. U oblicza zapytanie Query(i), używając jego losowej taśmy, a następnie przesyła (poprzez zapisanie na odpowiedniej taśmie) je do S
3. S odbiera Query(i) i wykonuje w wielomianowym czasie obliczenia dla danych wejścio→
wych −
x , Query(i) i jego losowej taśmy. Wynikiem tych obliczeń jest odpowiedź
→
Answer(−
x , Query(i)), którą wysyła do U.
→
4. U odbiera odpowiedź Answer(−
x , Query(i)) i wykonuje na niej i na swojej prywatnej
taśmie z losowymi bitami w wielomianowym czasie obliczenia. W wyniku tych obliczeń
→
U poznaje i-ty bit xi z bazy danych, czyli z wektora −
x.
W ogólności schemat protokołu PIR może przebiegać w wielu rundach. Oznacza to tylko
tyle, że U i S mogą wysyłać i odbierać od siebie wiele zapytań i odpowiedzi.
−
Mówimy, że PIR jest poprawny, jeśli dla każdego wektora →
x tworzącego bazę danych i
→
−
każdego zapytania Query(i) o i-ty bit z wektora x , U zna xi po zakończeniu protokołu.
Mówimy, że PIR jest nietrywialny, jeśli komunikacja między U i S jest mniejsza od n
(ilość bitów w bazie danych). Dokładniej wartość funkcji CC(n, k) = maxi (|Query(i)| +
→
|Answer(−
x , Query(i))|) musi być mniejsza niż n, przynajmniej dla pewnych n i k.
Z oczywistych względów, w niniejszej pracy zajmujemy się przede wszystkim protokołami
nietrywialnymi i poprawnymi.
1.4.2. Bezpieczeństwo PIR
Definicja bezpieczeństwa PIR w modelu obliczeniowym, opiera się na założeniu, że S ma
ograniczoną moc obliczeniową. Nieformalnie, obliczeniowe bezpieczeństwo oznacza, że S nie
potrafi odróżnić dwóch zapytań, w wielomianowym czasie względem długości bazy danych i
parametru bezpieczeństwa, z większym niż zaniedbywalne prawdopodobieństwo. Formalnie,
dla każdej stałej c, dla każdej bazy danych długości n, dla każdego i i j spełniających 0 ≤
i, j < n i dla każdej wielomianowej wielkości rodziny obwodów logicznych, istnieje stała K
taka, że dla każdego k > K zachodzi:
|P (Ck (Query(i)) = 1) − P (Ck (Query(j)) = 1)| < σ, gdzie k jest parametrem bezpieczeń1
stwa protokołu, a σ = (max(k,n))
c
1.4.3. Decyzyjny problem reszt kwadratowych
Definicja 1.1 Niech
m, n ∈ Z oraz n > 0,
Niech teraz
a ∈ Z oraz N W D(a, n) = 1.
10
Liczbę a nazywamy resztą kwadratową modulo n, jeśli istnieje liczba x taka, że
x2 ≡ a (mod n).
W przeciwnym przypadku liczbę a nazywamy nieresztą kwadratową modulo n.
Definicja 1.2 Niech
Zn∗ = {x|1 ≤ x ≤ n, N W D(n, x) = 1},
gdzie n jest liczbą naturalną. Zdefiniujmy predykat Qn mówiący czy podana liczba jest resztą
kwadratową modulo n:
• ∃w ∈ Zn∗ w2 = y ⇒ Qn (y) = 0
• ∀w ∈ Zn∗ w2 6= y ⇒ Qn (y) = 1
Decyzyjny problem reszt kwadratowych polega na trudności obliczenia predykatu Qn
dla zadanej wartości y. Problem ten uważa się za najtrudniejszy gdy n jest iloczynem liczb
pierwszych tej samej długości.
Niech
Hk = {n|n = p ∗ q gdzie p i q to liczby pierwsze oraz |p| = |q| =
k
}.
2
Jeśli znany jest rozkład na czynniki pierwsze liczby n ∈ Hk , wtedy istnieje efektywny algorytm
na obliczenie Qn (y). By bliżej przybliżyć tę kwestię przypomnimy kilka znanych faktów z
teorii liczb (ich dowody można znaleźć np. w [11]).
Definicja 1.3 Niech p będzie nieparzystą liczbą pierwszą i niech a będzie liczbą całkowitą
niepodzielną przez p. Symbol Legendrea definiujemy w następujący sposób:
³ ´
• ap = 1 jeśli a jest resztą kwadratową modulo p,
³ ´
•
a
p
= −1 jeśli a jest nieresztą kwadratową modulo p.
Twierdzenie 1.1 (Kryterium Eulera) Niech p będzie nieparzystą liczbą pierwszą i niech a
będzie dodatnią liczbą całkowitą niepodzielną przez p. Wtedy
³a´
p−1
≡ a 2 (mod p).
p
Definicja 1.4 Niech n będzie liczbą całkowitą nieparzystą oraz niech
n = pα1 1 ∗ pα2 2 ∗ ... ∗ pαk k .
³ ´
Niech a będzie liczbą całkowitą względnie pierwszą z n. Symbol Jacobiego
³a´
n
=
a
n
określa wzór:
³ a ´α1 ³ a ´α2
³ a ´αk
∗
∗ ... ∗
,
p1
p2
pk
gdzie czynniki stojące z prawej strony równania są symbolami Legendrea.
Powodem dla którego rozpatrujemy symbol Jacobiego jest to, że można go efektywnie
obliczyć (istnieje algorytm wielomianowy ze względu na |n|) nie znając rozkładu na czynniki
liczby n.
11
Twierdzenie 1.2 Liczba a jest resztą kwadratową modulo n = p ∗ q wtedy i tylko wtedy gdy
a jest resztą kwadratową modulo p i a jest resztą kwadratową modulo q.
Dowód: Załóżmy, że a jest resztą kwadratową modulo n, czyli ∃x x2 ≡ a mod n. Niech
x1 = x mod p i x2 = x mod q. Zachodzą kongruencje:
• x21 ≡ x2 ≡ a (mod p)
• x22 ≡ x2 ≡ a (mod q)
Z powyższych kongruencji wynika, że a jest także resztą kwadratową modulo p i modulo q.
Załóżmy teraz, że a mod p i a mod q są resztami kwadratowymi odpowiednio modulo p
i modulo q. Mamy więc a mod p ≡ x21 (mod p) oraz a mod q ≡ x22 (mod q). Z Chińskiego
Twierdzenia o Resztach wynika, że ∃x x ≡ x1 (mod p) i x ≡ x2 (mod q). Dodatkowo wiadomo,
że istnieje tylko jedno takie x < n. Zachodzą więc równości:
• x2 ≡ a mod p (mod n)
• x2 ≡ a mod q (mod n)
co daje nam kongruencję x2 ≡ a (mod n) i kończy dowód.
³ ´ ³ ´
³ ´
³ ´
Z powyższego twierdzenia i równania na = ap ∗ aq wynika, że gdy na = −1 to
³ ´
a jest na pewno nieresztą kwadratową modulo n. Natomiast z informacji, że na = 1 nie
wynika, że a jest resztą kwadratową modulo n.
Zdefiniujmy więc zbiór:
³x´
Zn+1 = {x ∈ Zn∗ |
= 1},
n
gdzie n ∈ Hk dla pewnego k. Zbiór ten ma taką własność, że dokładnie połowa jego elementów
jest resztą kwadratową modulo n. Warto jeszcze zaznaczyć, że dla każdego x i y ze zbioru
Zn+1 iloczyn x ∗ y jest nieresztą kwadratową tylko wtedy gdy dokładnie jedna z tych liczb jest
nieresztą kwadratową. Wynika to z równości:
Qn (x ∗ y) = Qn (x) ⊕ Qn (y).
1.4.4. Decyzyjny problem Diffiego-Hellmana
Trudność obliczenia logarytmu dyskretnego w pewnych dużych grupach cyklicznych jest podstawą wielu protokołów kryptograficznych, które to od wielu lat wykorzystywane są w praktyce. Jednym z takich protokołów jest protokół Diffiego-Hellmana, uzgadniania wspólnego
klucza.
Złamanie tego protokołu nie jest trudniejsze od obliczenia logarytmu dyskretnego w grupie Zp∗ . Otwartym zagadnieniem zaś jest, czy problem Diffiego-Hellmana jest równoważny
obliczeniowo problemowi logarytmu dyskretnego (Maurer w pracy [12] wskazał pewne zależności między tymi problemami). Bardzo ważnym zagadnieniem w kryptografii jest więc
udowodnienie trudności obliczeniowej problemu logarytmu dyskretnego. Niestety dotychczas
nie udało się tego udowodnić. Zamiast tego zakłada się trudność obliczeniową pewnych problemów (jak np. trudność obliczeniowa logarytmu dyskretnego) i udowadnia się bezpieczeństwo
protokołów korzystając z tego założenia.
Jednym z problemów blisko powiązanym z protokołem uzgadniania klucza Diffiego-Hellmana
jest założenie o trudności obliczeniowej obliczeniowego problemu Diffiego-Hellmana.
12
Definicja 1.5 Rozpatrzmy cykliczną grupę G i jej generator g oraz dwa elementy a, b ∈ G,
gdzie a = g x , b = g y , dla pewnych nieznanych x, y ∈ N. Obliczeniowym problemem DiffiegoHellmana nazywamy zadanie obliczenia wartości c = g xy ∈ G.
Definicja 1.6 Przypuszczenie o trudności obliczeniowej problemu Diffiego-Hellmana jest założenie, że każdy probabilistyczny algorytm działający w wielomianowym czasie (względem
rozmiaru grupy) rozwiązuje obliczeniowy problem Diffiego-Hellmana z zaniedbywalnym prawdopodobieństwem. Dokładniej dla każdego algorytmu A oraz dla każdego c ∈ N zachodzi:
P (A(g, g x , g y ) = g xy ) <
1
,
nc
gdzie g ∈ G jest generatorem G, x, y ∈ N, n = |G|.
Założenie o trudności obliczeniowy problem Diffiego-Hellmana okazało się jednak w wielu
przypadkach niewygodnym i za słabym założeniem do udowadniania bezpieczeństwa protokołów. Dlatego też powstało sformułowane założenie o trudności obliczeniowej decyzyjnego
problemu Diffiego-Hellmana.
Definicja 1.7 Rozważmy grupę G, jej generator g oraz trzy elementy a, b, c ∈ G. Decyzyjnym
problemem Diffiego-Hellmana jest zdecydować czy h2 = g2a dla danej czwórki (g1 , h1 , g2 , h2 )
elementów z G, gdzie h1 = g1a dla pewnego a ∈ {1, .., p−1}. Jeśli tak to taką czwórkę nazywamy
czwórką Diffiego-Hellmana.
Zauważmy, że a jest zapadką (czyli pewną dodatkową informacją, umożliwiającą efektywne
rozwiązanie problemy, bez której znajomości problem jest trudny do rozwiązania) dla decyzyjnego problemu Diffiego-Hellmana. Znając a potrafimy efektywnie sprawdzić czy h2 = g2a .
Przekształcimy teraz podany decyzyjny problem Diffiego-Hellmana, tak by uzyskać instancję problemu należenia do podgrupy (patrz następny podpunkt). Niech G0 = G × G,
wtedy danymi wejściowymi dla decyzyjnego problemu Diffiego-Hellmana może być para elementów x, y ∈ G0 , gdzie x = (g1 , h1 ), y = (g2 , h2 ). Jasne jest, że (g1 , h1 , g2 , h2 ) jest czwórką
Diffiego-Hellmana wtedy i tylko wtedy gdy y należy do podgrupy H, grupy G0 generowanej
przez x = (g1 , g1a ). Decyzyjny problem Diffiego-Hellmana równoważny jest więc stwierdzeniu
czy y ∈ H, czyli problemowi należenia do podgrupy H.
Przykładem grupy G dla decyzyjnego problemu Diffiego-Hellmana jest Z∗p , gdzie p jest
liczbą pierwszą postaci p = 2 ∗ q + 1, gdzie q jest liczbą pierwszą. Liczba p jest szczególnej
postaci, ponieważ w ogólności trudno znaleźć generator dla grupy Z∗p . Gdy p = 2 ∗ q + 1 rząd
grupy Z∗p wynosi 2 ∗ q.
Twierdzenie 1.3 Niech p = 2 ∗ q + 1 oraz q będą liczbami pierwszymi. Wtedy g ∈ Z∗p jest
generatorem grupy Z∗p wtedy i tylko wtedy gdy g q 6= 1 i g 2 6= 1.
Z powyższego twierdzenia wynika, że znalezienie generatora w zdefiniowanej w twierdzeniu
grupie Z∗p jest proste, ponieważ grupa Z∗p zawiera q − 1 różnych generatorów. Wystarczy więc
wybrać losowo element g ∈ Z∗p i sprawdzić czy g q 6= 1 oraz g 2 6= 1. Jeśli test ten zawiedzie,
l
powtarzamy czynność do skutku. Prawdopodobieństwo porażki w l próbach wynosi ( q+1
2∗q ) ,
−l
co dla bardzo dużych q, jest mniej więcej równe 2 .
13
1.4.5. Problem należenia do podgrupy
Sprawdzenie czy dany element pewnej grupy należy do jej podgrupy nie jest zawsze prostym
problemem. W ogólności problem ten nie jest rekurencyjny. By zaaplikować to zagadnienie
do kryptograficznych protokołów takich jak asymetryczne kryptosystemy potrzebujemy móc
efektywnie obliczać należenie do podgrupy. Dodatkowo wymagamy by efektywne obliczenie
było wykonalne tylko gdy znamy zapadkę, czyli dodatkową informację bez której nie da się
efektywnie rozwiązać problemu należenia do podgrupy.
Niech G będzie grupą, a H jej podgrupą. Problemem należenia do podgrupy jest określenie
czy dany element g ∈ G należy do H. Zakładamy, że każdy element w G ma binarną postać
długości k, a mnożenie dwóch elementów w tej grupie jest wykonywane w wielomianowym
czasie względem k. Problem należenia do podgrupy nazwiemy trudnym gdy nie jesteśmy w
stanie sprawdzić członkostwa w podgrupie z prawdopodobieństwem znacząco większym niż
1
2 . Dodatkowo zakładamy, że członkostwo w podgrupie można sprawdzić w wielomianowym
czasie względem k, jeśli znana jest pewna dodatkowa informacja zwana zapadką. W dalszej
części pracy będziemy zajmować się jedynie trudnymi problemami należenia do podgrupy.
Niech k będzie parametrem bezpieczeństwa. Dla wejścia 1k niech IG będzie probabilistycznym algorytmem o wielomianowej złożoności czasowej, który zwraca opis grupy G, opis
grupy H ⊂ G oraz zapadkę, dzięki której można skonstruować szybki algorytm sprawdzający
należenie do podgrupy H w G. Algorytm IG jest nazywany generatorem instancji.
Możemy zdefiniować predykat należenia do podgrupy:
½
1 jeśli x ∈ H
M em(G, H, x) =
(1.1)
0 jeśli x ∈ G\H,
gdzie (G, H) jest wynikiem IG dla 1k , x ∈ G. Jeśli nie istnieje probabilistyczny i wielomianowy
algorytm, który oblicza predykat M em z prawdopodobieństwem znacząco większym niż 21 ,
wtedy możemy powiedzieć, że problem jest trudny obliczeniowo. Zakładamy także, że możemy
wybierać elementy z G i H niezależnie i losowo.
Twierdzenie 1.4 Niech G będzie grupą, a H jej podgrupą. Dla każdego g ∈ G i h ∈ H
zachodzi gh ∈ H ⇔ g ∈ H.
Definicja 1.8 Założenie o trudności obliczeniowej problemu należenia do podgrupy: dla każdej stałej c i dla każdej rodziny obwodów logicznych {Ck | k ∈ N} wielomianowej wielkości
względem k, istnieje K ∈ N takie, że dla każdego k > K zachodzi:
P rob(Ck (G, H, g) = M em(G, H, g)) <
1
1
+ c,
2 k
(1.2)
gdzie prawdopodobieństwo jest dla losowych (G, H) zwracanych przez IG(1k ) oraz losowego
b ∈ {0, 1}. Gdy b = 1 to g losowane jest z H, natomiast gdy b = 0 to g losowane jest z G\H.
Założenie to mówi, że nie istnieje rodzina obwodów wielomianowej wielkości względem k,
która potrafi obliczyć predykat M em.
Powyższe założenie można sformułować inaczej:
Definicja 1.9 Założenie o trudności obliczeniowej problemu należenia do podgrupy - wersja
2
Dla każdej stałej c i każdej rodziny obwodów logicznych {Ck | k ∈ N} wielomianowej
wielkości względem k, istnieje liczba naturalna K taka, że dla każdego k > K zachodzi:
|PH − PF | <
14
1
,
kc
(1.3)
gdzie prawdopodobieństwa PH i PF definiują wzory:
PH = P rob(Ck (G, H, g) = 1),
gdzie (G, H) są wygenerowane przez pewien generator instacji IG(1k ), natomiast g to losowo
wybrany element z H
PF = P rob(Ck (G, H, g) = 1),
gdzie (G, H) są wygenerowane przez pewien generator instacji IG(1k ), natomiast g to losowo
wybrany element z F = G\H
Przykładami problemu należenia do podgrupy są opisane w poprzednim rozdziale problemy odróżnienia reszt od niereszt kwadratowych, a także decyzyjny problem DiffiegoHellmana. W literaturze (np. [5]) można znaleźć więcej problemów tego typu, ale wymienione
tutaj są najbardziej popularne i najlepiej zbadane.
1.5. Warianty prywatnego pozyskiwania danych
W literaturze spotykamy wiele różnych wariantów prywatnego pozyskiwania danych. Najbardziej popularnym jest przede wszystkim przypadek gdzie nieistotne jest ile informacji
udało się dodatkowo, poza szukanymi, uzyskać użytkownikowi. Protokół PIR, który zapewnia pobranie tylko tej szukanej przez użytkownika (i żadnej innej) informacji jest nazywany
symetrycznym PIR. Istnieją metody przekształcające PIR w symetryczny PIR poprzez wydłużenie protokołu tylko o jedną rundę i jedną z takich metod będzie można odnaleźć w
dalszej części pracy (3.3.3).
1.5.1. Teorio-informacyjny 1-serwerowy PIR
W modelu teorio-informacyjnym nieuczciwa baza danych dysponuje nieograniczoną mocą
obliczeniową. Implikuje to zmianę definicji bezpieczeństwa. Mianowicie dla każdej stałej c,
dla każdej bazy danych długości n, dla każdego i, j ∈ N spełniających 0 ≤ i, j < n i dla
każdej wielomianowej wielkości rodziny obwodów logicznych, istnieje stała K taka, że dla
każdego k > K zachodzi: |P (Ck (Query(i)) = 1) − P (Ck (Query(j)) = 1)| = 0, gdzie k jest
parametrem bezpieczeństwa protokołu.
Przy takich założeniach najlepszym protokołem pod względem złożoności komunikacyjnej
jest przesłanie całej zawartości bazy danych do użytkownika.
Twierdzenie 1.5 [2] Nietrywialny teorio-informacyjny 1-serwerowy PIR nie istnieje.
Zanim podamy dowód tego twierdzenia, wprowadzimy kilka definicji:
Definicja 1.10 Transkryptem komunikacyjnym C między partiami nazywamy zapis komunikatów pomiędzy użytkownikiem U i serwerem S.
→
Inaczej mówiąc transkrypt komunikacyjny C jest wartością funkcji C(ru , i, rs , −
x ), gdzie i,
→
−
x są odpowiednio danymi wejściowymi użytkownika i serwera, a ru i rs odpowiednio ich
zrandomizowanymi danymi wejściowymi.
→
Definicja 1.11 Transkrypt komunikacyjny C jest możliwy dla (−
x , i) jeśli istnieją ru i rs
−
→
takie, że C = C(ru , i, rs , x ).
15
Nieformalnie mówiąc, powyższa definicja oznacza, że prawdopodobieństwo pojawienia się
transkryptu komunikacyjnego C dla danych ru , rs , i, x, nie jest zerowe.
→
Definicja 1.12 Transkrypt komunikacyjny C jest możliwy dla i, jeśli istnieje taki −
x , że
→
−
transkrypt komunikacyjny C jest możliwy dla ( x , i).
Dowód:
1. Ustalmy indeks i oraz załóżmy, wbrew twierdzeniu, istnienie nietrywialnego
teorio-informacyjnego 1-serwerowego PIR.
2. Dla dowolnego indeksu i z nietrywialności wynika, że możliwych transkryptów dla i jest
mniej niż 2n , gdzie n to rozmiar bazy danych.
→
−
3. Zatem dla ustalonego indeksu i istnieją takie −
x, →
y i transkrypt komunikacyjny C, że
−
→
−
→
−
→
−
→
x 6= y oraz C jest możliwy dla ( x , i) i ( y , i).
4. Ponieważ serwer dysponuje nieograniczoną mocą obliczeniową, musi zachodzić dla każ−
dego j, że C jest możliwe dla (→
x , j). W przeciwnym razie serwer mógłby sprawdzić
wszystkie możliwe transkrypty komunikacyjne jakie mogą powstać w trakcie wykony→
wania protokołu i stwierdzić, że C jest niemożliwe dla (−
x , j). W ten sposób dowiedziałby
się, że użytkownik nie pytał o j-ty bit.
→
−
5. Analogicznie rozumując dla −
y dostajemy, że dla każdego j, C jest możliwe dla (→
y , j).
→
−
6. Ponieważ −
x =
6 →
y , więc istnieje j, dla którego xj 6= yj .
7. Dostajemy więc sprzeczność, gdyż szukany przez użytkownika bit zależy od transkryptu
komunikacyjnego C i wartości i. Na przykład gdy i = j, xi = 0, yj = 1, użytkownik
zwraca dwie różne wartości, co jest niemożliwe, więc dostajemy sprzeczność.
1.5.2. Inne modele
Smith i Safford ([13], [14]) rozważali 1-serwerowy PIR przy założeniu istnienia specjalnego
urządzenia uniemożliwiającego manipulację po stronie serwera. Żeby dobrze zrozumieć stojącą za tym podstawową ideę, wyobraźmy sobie bezpieczny koprocesor (ang. secure coprocessor)
[15, 16, 17] zainstalowany po stronie serwera. Użytkownik koduje zapytanie o i-ty bit i wysyła
je do bezpiecznego koprocesora. Bezpieczny koprocesor odkodowuje zapytanie, przetwarza je,
a następnie uzyskaną odpowiedź koduje i wysyła do użytkownika. Serwer nie ma żadnych
wskazówek na temat zapytania użytkownika, ponieważ:
• Główną własnością bezpiecznego koporocesora jest to, że zainstalowany na serwerze,
uniemożliwia mu dostęp do wbudowanej pamięci RAM bezpiecznego koprocesora. Dlatego też serwer nie wie jak wygląda odkodowane zapytanie użytkownika.
• Żeby przetworzyć zapytanie, bezpieczny koprocesor czyta wszystkie rekordy z bazy
danych nie zdradzając w ten sposób preferencji użytkownika.
Inne podejście zaprezentowano w pracy [18], w której to przedstawiono protokół PIR,
wykorzystujący losowe serwery. Protokół ten dzięki wykorzystaniu dodatkowych serwerów,
może przerzucić większość obliczeń z serwera dysponującego bazą danych na inne serwery
nie znające zawartości bazy danych. Protokół ten może także zapewnić bezpieczeństwo przy
16
koalicji t dodatkowych serwerów, gdzie t jest parametrem protokołu, wykorzystując obliczenia
wielopodmiotowe. Niestety protokół ten nie redukuje złożoności obliczeniowej, lecz odciąża
serwer będący w posiadaniu bazy danych, który to w trakcie protokołu wykonuje tylko O(1)
obliczeń. Główną zaletą tego protokołu jest więc odciążenie głównego serwera z obliczeń,
które to niestety muszą być wykonane przez inny serwer lub serwery.
17
Rozdział 2
1-serwerowy obliczeniowy PIR
W rozdziale tym zaprezentujemy nietrywialny 1-serwerowy obliczeniowy protokół PIR. Będzie
to protokół Kushlevitza i Ostrovskyego([4]) uogólniony przez Akihiro Yamamure i Taiichi
Saito ([5]). Złożoność komunikacyjna tego protokołu to O(n² ), gdzie ² może być dowolnie
małe. Protokół ten opiera się na dowolnej instancji problemu należenia do podgrupy. Jest
to bardzo ważny fakt, gdyż do tej pory wszystkie efektywne 1-serwerowe obliczeniowe PIR,
opierały się tylko na trudności rozkładu pewnych liczb naturalnych na czynniki.
2.1. Uogólniony protokół Kushlevitza i Ostrovskyego
Protokół PIR Kushlevitza i Ostrovskyego opiera się na trudności odróżnienia reszty kwadratowej od niereszty kwadratowej (zagadnienie to opisane było w rozdziale 1). My przedstawimy
tu uogólnioną wersję tego protokołu i pokażemy czym różni się ona od oryginału.
2.1.1. Uproszczona wersja protokołu
Przedstawimy tu prosty protokół, na którego przykładzie zademonstrujemy ideę stojącą za
protokołem Kushlevitza i Ostrvskyego.
→
Rozważmy serwer S obsługujący bazę danych −
x = [x0 , x1 , ..., xn−1 ] oraz użytkownika U
chcącego poznać i-ty bit. By to osiągnąć U generuje instancję problemu należenia do podgrupy, czyli parę (G, H). Elementy grupy G mają binarną długość k, gdzie k jest parametrem
bezpieczeństwa. U traktuje bazę danych jako macierz o wymiarach t × s, określaną dalej jako
M . Przy czym M [l, j] = xs∗l+j , gdy s ∗ l + j < n, oraz M [l, j] = 0 gdy s ∗ l + j ≥ n. Natomiast
szukany przez U i-ty bit, określają współrzędne (a, b) = (b si c, i mod s).



M =

x0
xs
..
.
x1
xs+1
..
.
xs∗(t−1) xs∗(t−1)+1
. . . xs−1
. . . x2∗s−1
..
..
.
.
. . . xs∗t−1





• U wybiera losowo s elementów g0 , g1 , ..., gs−1 z G w taki sposób, że gb ∈ (G\H), a dla
każdego j 6= b, zachodzi gj ∈ H. Następnie wysyła wylosowanych s elementów (s ∗ k
bitów) do S
• Dla każdego z t wierszy S oblicza odpowiednio elementy v0 , v1 , ..., vt−1 , gdzie:
x
x
x
s∗j+s−1
vj = g0 s∗j ∗ g1 s∗j+1 ∗ ... ∗ g(s−1)
,
19
x
i wysyła je do U. Zauważmy, że gdy l 6= b to zawsze zachodzi gl s∗j+l ∈ H. Natomiast
x
gdy l = b to gl s∗j+l ∈ H wtedy i tylko wtedy gdy xs∗j+l = 0. Wynika z tego, że vj ∈ H
wtedy i tylko wtedy gdy M [j, b] = 0.
• U bierze pod uwagę tylko element va , odpowiadający w macierzy M wierszowi, w
którym stoi pożądany przez niego bit. Ponieważ element va ∈ H ⇔ M [a, b] = 0, więc
wystarczy żeby U sprawdził czy va ∈ H, co może efektywnie wykonać. W ten sposób
U dowiaduje się czy i-tym bitem jest zero (va ∈ H), czy też jedynka (va ∈
/ H).
Poprawność protokołu wynika bezpośrednio z jego opisu.
Przeanalizujmy złożoność komunikacyjną powyższego protokołu. Ilość przesłanych bitów
√
w obie strony (od U do S i od S do U) wynosi (1 + t + s) ∗ k. Przyjmując s = t = n
√
otrzymujemy złożoność komunikacyjną postaci (2 ∗ n + 1) ∗ k. Wreszcie ustalając parametr
1
bezpieczeństwa k = n² dostajemy oczekiwaną złożoność komunikacyjną równą O(n 2 +² ).
Teraz udowodnimy bezpieczeństwo protokołu. Załóżmy, że dla pewnych dwóch indeksów
i and i0 , serwer S potrafi odróżnić zapytania Query(i) o bit xi od zapytania Query(i0 ) o bit
xi0 . Użyjemy tego założenia do skonstruowania obwodu logicznego rozwiązującego problem
−
należenia do podgrupy. Zgodnie z naszym protokołem zapytanie o i-ty bit z wektora →
x jest
0
równoważne zapytaniu o element (a, b) z macierzy M . Analogicznie i odpowiada para (a0 , b0 ).
Jasne jest, że musi zachodzić b 6= b0 , gdyż w przeciwnym przypadku protokół przebiega identycznie w obu przypadkach i nie ma sposobu na rozróżnienie Query(i) od Query(i0 ). Fakt,
że S potrafi odróżnić te dwa zapytania mówi, że istnieje rodzina wielomianowej wielkości obwodów logicznych B takich, że jeśli B dostanie na wejściu Query(i) (czyli jedno z możliwych
zapytań wygenerowanych przez U dla bitu i), wtedy B zwraca wynik 1 z pewnym prawdopodobieństwem p, natomiast jeśli B dostanie na wejściu Query(i0 ) (czyli jedno z możliwych
zapytań wygenerowanych przez U dla bitu i0 ), wtedy B zwraca wynik 1 z prawdopodobieństwem p + c.
Z konstrukcji protokołu wynika, że Query(i) składa się z s − 1 elementów z H oraz
jednego elementu z G\H stojącego na pozycji b. Query(i0 ) jest zbudowane analogicznie, z tą
różnicą, że element z G\H stoi na pozycji b0 . Para (G, H) jest instancją problemu należenia
do podgrupy, wygenerowaną przez U na początku protokołu.
Opiszemy teraz obwód logiczny C, który dla danych wejściowych G, H, y, gdzie y ∈ G,
oblicza predykat M em (patrz 1.1) z prawdopodobieństwem co najmniej 21 + 2c . Konstrukcja:
1. Wybieramy losowo s−2 (zakładamy ze można wybierać elementy z G i H z jednostajnym
rozkładem) elementy z H i ustawiamy je na wszystkich pozycjach od 1 do s poza
pozycjami b oraz b0 .
2. Wybieramy losowo jedną z pozycji b lub b0 . Następnie wstawiamy na wylosowaną pozycję y, a na pozycję której nie wylosowaliśmy wstawiamy losowy element z H.
3. Uruchamiamy B na uzyskanym ciągiem elementów. Jeśli w drugim kroku wylosowaliśmy b0 , zwracamy tę samą wartość którą zwróci B. Jeśli natomiast w drugim kroku
wylosowaliśmy b, zwracamy odwrotność tego co zwróci B.
Policzmy teraz prawdopodobieństwo, że C zwróci 1 mając na wejściu G, H, y takie, że
y ∈ H. Wtedy bez względu na to co wybierze B w kroku drugim naszej konstrukcji i tak jego
danymi wejściowymi będzie ciąg elementów tylko z H. Dla takich danych wejściowych niech
prawdopodobieństwem tego, że B po wykonanych obliczeniach zwróci 1, będzie q. Prawdopodobieństwo, że C zwróci 1 w tym przypadku będzie wynosić 12 ∗ q + 12 ∗ (1 − q) = 21 . Teraz
20
załóżmy, że y ∈
/ H. W tym przypadku ciąg stworzony w drugim kroku konstrukcji będzie zawierał tylko jeden element z G\H, stojący na pozycji b lub b0 . Wtedy prawdopodobieństwo,
że C zwróci 1 jest w tym przypadku równe 21 ∗ (p + c) + 12 ∗ (1 − p) = 12 + 2c .
Z przedstawionego protokołu wynika poniższe twierdzenie:
Twierdzenie 2.1 Przy założeniu trudności rozwiązania problemu należenia do podgrupy,
1
istnieje w modelu obliczeniowym protokół PIR o złożoności komunikacyjnej O(n 2 +² ).
W porównaniu do modelu teorio-informacyjnego to już jest duży postęp, bo jak pamiętamy w tamtym modelu najlepszy protokół ma złożoność komunikacyjną Ω(n).
2.1.2. Właściwy protokół
Metodę którą zastosowaliśmy w poprzedniej sekcji (2.1.1), konstruując protokół o złożono1
ści komunikacyjnej O(n 2 +² ), możemy w specjalny sposób wywoływać rekurencyjnie tworząc
protokół PIR o złożoności komunikacyjnej (n² ), dla dowolnego ² > 0.
→
Tak jak w uproszczonym protokole rozważmy serwer S obsługujący bazę danych −
x =
n
[x0 , x1 , ..., xn−1 ] ∈ {0, 1} oraz użytkownika U chcącego poznać i-ty bit. W celu poznania xi ,
U generuje instancję problemu należenia do podgrupy, czyli parę (G, H). Elementy grupy G
mają binarną długość k, gdzie 1k jest parametrem bezpieczeństwa. Załóżmy, że n = tl , gdzie
t, l ∈ N. Jeśli n nie da się przedstawić w postaci n = tl to bierzemy najmniejsze n0 > n takie,
że n0 = tl i bazę danych traktujemy jakby miała n0 bitów, gdzie na miejscach od n do n0 − 1
stoją bity 0.
• Najpierw U konstruuje zapytanie Query(i) o i-ty bit xi , gdzie 0 ≤ i < n, w następujący
sposób. U oblicza t-rozszerzenie i. Mianowicie, niech α0 = i, wtedy t-rozszerzeniem i
jest βl βl−1 ...β1 , gdzie
α0 = α1 ∗ t + β1
0 ≤ α0 ≤ tl−1 − 1 i
0 ≤ β1 ≤ t − 1
α1 = α2 ∗ t + β2
0 ≤ α1 ≤ tl−2 − 1 i
0 ≤ β2 ≤ t − 1
...
αl−2 = αl−1 ∗ t + βl−1
0 ≤ αl−2 ≤ t − 1 i 0 ≤ βl−1 ≤ t − 1
0 ≤ αl−1 ≤ t − 1
αl = 0 i
βl = αl−1
(2.1)
Dla każdego u ∈ {1, ..., l}, U wybiera losowo i niezależnie t − 1 elementów
g(u,0) , g(u,1) , ..., g(u,βu −1) , g(u,βu +1) , ..., g(u,t−1) z podgrupy H, a także jeden element
g(u,βu ) z podgrupy G\H. Zdefiniujmy q(u) jako krotkę (g(u,0) , g(u,1) , ..., g(u,t−1) ) złożoną
z wyżej wylosowanych liczb. Wtedy ciąg q(1), q(2), ..., q(l) tworzy zapytanie Query(i), o
i-ty bit bazy danych, które U wysyła do S. Ponieważ każde q(u) składa się z t elementów
z grupy G, więc q(u) jest reprezentowane przez k ∗ t bitów, a Query(i) przez k ∗ t ∗ l
bitów.
• S odbiera zapytanie Query(i) i podobnie jak w uproszczonej wersji protokołu rozpatruje
bazę danych jako macierz o wymiarach tl−1 × t:


x0
x1
. . . xt−1
 xt
xt+1
. . . x2t−1 

(2.2)
D(0, λ) = 


...
xtl −t xtl −t+1 . . . xtl −1
21
gdzie λ oznacza pusty ciąg. Zauważmy, że bit xi ma współrzędne (α1 , β1 ) w macierzy
D(0, λ) (gdzie α1 , β1 są wzięte z 2.2) i taki docelowy bit oznaczmy przez T arget(D(0, λ)).
Rekurencyjnie definiujemy ”potomków” D(u, s) bazy D(0, λ), gdzie 0 ≤ u ≤ l − 1
oraz s ∈ {0, 1, 2, ..., k − 1}u . Przypuśćmy, że zdefiniowaliśmy bazę danych D(u, s) i jej
docelowy bit T arget(D(u, s)) i s ∈ {0, 1, 2, ..., k − 1}u . Baza danych D(u, s) składa się
z tl−u bitów, a my rozpatrujemy ją jako macierz o wymiarach tl−u−1 × t:


y0
y1
...
yt−1
 yt
yt+1
. . . y2t−1 
.
D(u, s) = 


...
ytl−u −t ytl−u −t+1 . . . ytl−u −1
Skonstruujemy teraz k ”potomków” tej bazy, D(u + 1, s × 0), D(u + 1, s × 1), ..., D(u +
1, s×(k−1)). Pamiętamy, że q(u) składa się z t elementów g(u,0) , g(u,1) , ..., g(u,t−1) z grupy
G. Definiujemy element fD(u,s),v ∈ G dla każdego wiersza v ∈ {0, 1, 2, ..., tl−u−1 − 1}:
½
f(v,w) =
g(u,v) jeśli D(u, s)[v, w] = 1
1
jeśli D(u, s)[v, w] = 0
(2.3)
Niech teraz
fD(u,s),v = f(v,0) ∗ f(v,1) ∗ ... ∗ f(v,t−1)
(2.4)
dla każdego wiersza v ∈ {0, 1, 2, ..., tl−u−1 −1} macierzy D(u, s). Łatwo zauważyć, że dla
każdego v, fD(u,s),v ∈ H ⇔ D(u, s)[v, βu ] = 0. Rozważmy r-tego ”potomka” D(u+1, s×
r), bazy danych D(u, s). Składa się on z bitów g0 (r), g1 (r), ..., gtl−u−1 −1 (r), gdzie gv (r)
oznacza r-ty bit reprezentacji elementu fD(u,s),v . Możemy zapisać następujące równanie
macierzowe:


fD(u,s),0


fD(u,s),1

 = (D(u + 1, s × 0), ..., D(u + 1, s × (k − 1))),
(2.5)


...
fD(u,s),tl−u−1 −1
gdzie każde fD(u,s),v traktujemy jako wektor wierszowy, a każde D(u + 1, s × r) traktujemy jako wektor kolumnowy. Wynika z tego, że D(u + 1, s × r) składa się z tl−u−1
bitów. Zagłębiając się dalej w rekurencji, rozpatrujemy D(u + 1, s × r) jako macierz o
wymiarach tl−u−2 × t, a jej docelowy bit T arget(D(u + 1, s × r)) określają współrzędne
(αu+1 , βu+1 ). Postępujemy tak oczywiście dla każdego r ∈ {0, 1, ..., k − 1} i tylko wtedy,
gdy D(u + 1, s × r) składa się z więcej niż t bitów.
W ostatnim kroku, S dysponuje k l−1 bazami danych D(l−1, s), gdzie s ∈ {1, 2, ..., k}l−1 .
Każda z tych baz składa się z t bitów i dla każdej z nich definiujemy element A(s). Tak
jak poprzednio(2.3) obliczamy:
½
g(u,v) jeśli D(u, s)[v, w] = 1
f(0,w) =
1
jeśli D(u, s)[v, w] = 0
oraz
fD(u,s),v = f(v,0) ∗ f(v,1) ∗ ... ∗ f(v,t−1) = A(s)
→
Ciąg elementów A(s), gdzie s ∈ {0, 1, 2, ..., k − 1}l−1 tworzy odpowiedź Answer(−
x,
Query(i)) na zapytanie Query(i), która jest wysyłana przez S do U.
22
→
• U otrzymuje odpowiedź Answer(−
x , Query(i)), składającą się z A(s), gdzie s ∈ {0,1,2,...,
l−1
k − 1}
i w wielomianowym czasie względem n i k oblicza bit xi = T arget(D(0, λ)).
Sposób obliczenia T arget(D(0, λ)) jest podany poniżej w formie ogólnej.
Jeśli U zna już docelowe bity T arget(D(u + 1, s × 0)), T arget(D(u + 1, s × 1)), ...,
T arget(D(u + 1, s × (k − 1))) to potrafi obliczyć bit docelowy T arget(D(u, s)). Mianowicie U ma pewne informacje(zapadkę), dzięki której może efektywnie sprawdzić
czy dany element z grupy G należy do podgrupy H oraz wie, że g(u,βu ) ∈ F =
G\H i g(u,0) , g(u,1) , ..., g(u,βu −1) , g(u,βu +1) , ..., g(u,t−1) ∈ H, gdzie q(u) = (g(u,0) , g(u,1) , ...,
g(u,βu −1) , g(u,βu ) , g(u,βu +1) , ..., g(u,t−1) ). Zauważmy, że liczba βu jest prywatną informacją U. Przypomnijmy teraz, że docelowym bitem T arget(D(u, s)) bazy danych
D(u, s) jest D(u, s)[αu , βu ]. Dzięki obliczeniom przeprowadzonym przez S (2.4) mamy fD(u,s),αu = f(αu ,0) ∗ ... ∗ f(αu ,t−1) . Z (1.4) oraz (2.3) mamy fD(u,s),αu ∈ H wtedy i
tylko wtedy, gdy D(u, s)[αu , βu ] = 0. Co więcej zgodnie z (2.5), fD(u,s),αu jest αu rzędem
macierzy (D(u + 1, s × 0), ..., D(u + 1, s × (k − 1)). Zauważmy, że αu -ty bit macierzy
D(u + 1, s × r) to D(u + 1, s × r)[αu+1 , βu+1 ], czyli T arget(D(u + 1, s × r)). Ponieważ U
zna T arget(D(u+1, s×0)), T arget(D(u+1, s×1)), ...,T arget(D(u+1, s×(k−1))), może
wyliczyć wartość fD(u,s),αu . Jeśli już U zna wartość fD(u,s),αu , sprawdza czy należy ona
do H. W ten sposób U poznaje, w wielomianowym czasie, docelowy bit T arget(D(u, s)).
Jasne jest, że poprzez odpowiednie rekurencyjne wykorzystanie powyższego schematu
U może obliczyć T arget(D(0, λ)).
Poprawność protokołu wynika bezpośrednio z jego opisu.
Opiszemy teraz złożoność komunikacyjną protokołu. W pierwszym kroku U wysyła zapytanie Query(i) = (Q(1), Q(2), ..., Q(l)). Każde Q(u) zawiera t elementów z G. Ponieważ każdy
element w G jest reprezentowany przez binarny ciąg długości k, więc ilość bitów wysłana w tej
fazie jest równa l ∗ t ∗ k. W drugiej fazie S wysyła odpowiedź Answer(Query(i)) zawierającą
k l−1 elementów z G, więc ilość bitów przesłana w tej fazie jest równa k ∗ k l−1 = k l . Złożoność
q
komunikacyjną określa więc wzór: l ∗ t ∗ k + k l . Przypuśćmy, że k = n² oraz l = O( log(n)
log(k) ).
q
log(n)
Wtedy dostajemy l = O( ²∗log(n)
) = O( √1² ). Dalej obliczamy k l = (2log(k) )l = 2l∗log(k) =
√
√
√
1
O(2 log(n)∗log(k) ) = O(2 log(n)∗²∗log(n) ) = O(n ² ). A ponieważ t = n l , dostajemy nierówność
l ∗ t ∗ k + k l = k l ∗ (l ∗ k + 1) < k l ∗ k l = O(n² ).
Teraz udowodnimy bezpieczeństwo protokołu. Dowód będzie analogiczny do przypadku
z uproszczoną wersją. Załóżmy, że dla pewnych dwóch indeksów i and i0 , serwer S potrafi
odróżnić zapytania Query(i) o bit xi od zapytania Query(i0 ) o bit xi0 . Użyjemy tego założenia do skonstruowania obwodu logicznego rozwiązującego problem należenia do podgrupy.
→
Zgodnie z protokołem zapytanie o bit i-ty z wektora −
x jest ciągiem elementów z1 , ..., zβ z
G, gdzie β = l ∗ t. Dla każdego indeksu i, oznaczmy poprzez Ii podzbiór zbioru {1, ..., β}
zawierający pozycje na których występują elementy z G\H. Warto zauważyć, że zbiory Ii są
ustalone z góry i niezależne od losowych wyborów dokonywanych przez U. Co więcej dla i 6= i0
musi zachodzić Ii 6= Ii0 , gdyż w przeciwnym przypadku U generuje Query(i) i Query(i0 ) w
identyczny sposób więc zapytania te byłyby nierozróżnialne.
Fakt, że S potrafi odróżnić dwa zapytania mówi, że istnieje rodzina wielomianowej wielkości obwodów logicznych B takich, że jeśli B dostanie Query(i) (jedno z możliwych zapytań
wygenerowanych przez U dla bitu i), wtedy B zwraca wynik 1 z pewnym prawdopodobieństwem p, natomiast jeśli B dostanie Query(i0 ) (jedno z możliwych zapytań wygenerowanych
przez U dla bitu i0 ), wtedy B zwraca wynik 1 z prawdopodobieństwem p + c.
23
Opiszemy teraz obwód logiczny C, który dla danych wejściowych G, H, y, gdzie y ∈ G,
oblicza predykat M em (patrz 1.1) z prawdopodobieństwem co najmniej 21 + 2c . Konstrukcja:
1. Wybieramy losowo jeden ze zbiorów Ii lub Ii0 . Tworzymy ciąg v1 , ..., vβ , w którym
na pozycjach nie należących do wylosowanego zbioru wstawiamy losowo wybrane elementy z H, natomiast na pozostałych pozycjach wstawiamy iloczyn losowo wybranego
elementu z H oraz y.
2. Uruchamiamy B na uzyskanym ciągu elementów. Jeśli w pierwszym kroku wylosowaliśmy Ii0 , zwracamy tę samą wartość którą zwróci B. Jeśli natomiast w pierwszym kroku
wylosowaliśmy Ii , zwracamy odwrotność tego co zwróci B.
Policzmy teraz prawdopodobieństwo, że C zwróci 1 mając na wejściu G, H, y takie, że
y ∈ H. Wtedy wszystkie elementy v1 , ..., vβ należą do H. Dla takich danych wejściowych niech
prawdopodobieństwem tego, że B po wykonanych obliczeniach zwróci 1, będzie q. Prawdopodobieństwo, że C zwróci 1 w tym przypadku będzie wynosić 21 ∗ q + 12 ∗ (1 − q) = 21 . Teraz
załóżmy, że y ∈
/ H. W tym przypadku ciąg stworzony w pierwszym kroku konstrukcji będzie tworzył Query(i) lub Query(i0 ) w zależności od dokonanego wyboru w pierwszym kroku.
Wtedy prawdopodobieństwo, że C zwróci 1 w tym przypadku jest 12 ∗(p+c)+ 21 ∗(1−p) = 21 + 2c .
2.1.3. Przykład
Dla dobrego zrozumienia przedstawionego w poprzednim punkcie protokołu pokażemy mały
przykład jego działania. Zakładamy, że ustalona jest już para (G, H) dla pewnego parametru
bezpieczeństwa k. Niech baza danych ma postać:
−
→
x = [x0 , x1 , x2 , x3 , x4 , x5 , x6 , x7 , x8 ] = [0, 1, 0, 1, 0, 1, 1, 1, 0].
Rozmiar bazy danych jest n = 9 = 32 . Przyjmijmy
baza danych ma postać:

0 1

1 0
D(0, λ) =
1 1
t = 3, a l = 2. W postaci macierzowej

0
1 
0
Przypuśćmy, że użytkownik U chce przeczytać bit x6 (i = 6). Zgodnie ze wzorem 2.1 obliczamy 3-rozszerzenie 6. Dostajemy 6 = 2 ∗ 3 + 0, 2 = 0 ∗ 3 + 2, czyli α0 = 6, α1 = 2,
β1 = 0, β2 = 2. U wybiera więc losowo trzy elementy z G: g(1,0) , g(1,1) , g(1,2) , gdzie g(1,1) , g(1,2)
należą do H, a g(1,0) należy do G\H(ponieważ β1 = 0). Następnie U wybiera ponownie losowo i niezależnie trzy elementy z G: g(2,0) , g(2,1) , g(2,2) , gdzie g(2,0) , g(2,1) należą do H, a
g(2,2) należy do G\H(ponieważ β2 = 2). Zapytanie Query(6) składa się z dwóch krotek
q(1) = (g(1,0) , g(1,1) , g(1,2) ) i q(2) = (g(2,0) , g(2,1) , g(2,2) ), które U wysyła do S. Przypuśćmy, że każdy element w grupie G można reprezentować za pomocą 4 bitów (k = 4). S po
odebraniu zapytania Query(6) oblicza wartości zgodnie ze wzorem 2.3 dostając f(0,0) = 1,
f(0,1) = g(1,1) , f(0,2) = 1, f(1,0) = g(2,0) , f(1,1) = 1, f(1,2) = g(2,2) , f(2,0) = g(3,0) , f(2,1) = g(3,1) ,
f(2,2) = 1. Następnie korzystając z 2.4 liczy fD(0,λ),0 = f(0,0) ∗ f(0,1) ∗ f(0,2) = g(1,1) , fD(0,λ),1 =
f(1,0) ∗ f(1,1) ∗ f(1,2) = g(2,0) ∗ g(2,2) , fD(0,λ),2 = f(2,0) ∗ f(2,1) ∗ f(2,2) = g(3,0) ∗ g(3,1) . Załóżmy
teraz, że fD(0,λ),0 , fD(0,λ),1 , fD(0,λ),2 są odpowiednio reprezentowane przez 0110, 1010, 1101.
Dla lepszego zobrazowania dalszej części protokołu zapiszemy to w postaci macierzowej:


 
fD(0,λ),0
0 1 1 0
 fD(0,λ),1  =  1 0 1 0  .
1 1 0 1
fD(0,λ),2
24
S tworzy cztery bazy danych D(1, 0), D(1, 1), D(1, 2), D(1, 3), gdzie D(1, 0) = (011)T ,
D(1, 1) = (101)T , D(1, 2) = (110)T , D(1, 3) = (001)T . Zauważmy, że zachodzi równość:


fD(0,λ),0
 fD(0,λ),1  = (D(1, 0), D(1, 1), D(1, 2), D(1, 3)).
fD(0,λ),2
Dla każdej nowo utworzonej bazy danych S oblicza wartości A(0), A(1), A(2), używając
otrzymanego na początku q(2) = (g(2,0) , g(2,1) , g(2,2) ). Dla D(1, 0) = (011)T dostaje A(0) =
g(2,1) ∗ g(2,2) , dla D(1, 1) = (101)T dostaje A(1) = g(2,0) ∗ g(2,2) , dla D(1, 2) = (110)T dostaje
A(2) = g(2,0) ∗ g(2,1) , dla D(1, 3) = (001)T dostaje A(3) = g(2,2) . Następnie S wysyła A(0),
→
→
A(1), A(2), A(3) do U, jako Answer(−
x , Query(6)). Po otrzymaniu Answer(−
x , Query(6)), U
sprawdza które elementy z A(0), A(1), A(2), A(3) należą do H, a ponieważ jest w posiadaniu
zapadki, potrafi w wielomianowym czasie to sprawdzić. Po sprawdzeniu dowiaduje się, że
elementy A(0), A(1), A(3) ∈ G\H, natomiast A(2) ∈ H i dochodzi do wniosku, że fD(0,λ),2 =
1101. Sprawdzając czy fD(0,λ),2 ∈ H, dowiaduje się, że x6 = 0.
25
Rozdział 3
Prywatne wyszukiwanie słów
kluczowych
3.1. Praktyczne zastosowanie uogólnionego protokołu Kushlevitza i Ostrovskyego
Główną niedogodnością protokołów PIR jest potrzeba znania fizycznego adresu szukanego
elementu. Niestety zazwyczaj użytkownik nie posiada takiej informacji. Zamiast tego jest
on w posiadaniu słowa, charakteryzującego szukane informacje, na podstawie którego serwer
może wyznaczyć fizyczne miejsce w bazie danych. Na przykład na podstawie słowa kluczowego
nazwy giełdowej firmy, użytkownik może uzyskać dostęp do ostatnich notowań tej firmy.
W rozdziale tym przedstawimy w jaki sposób wykorzystać protokół PIR by uzyskać dostęp
do danych z bazy danych za pomocą słowa kluczowego. Zrobimy to poprzez ogólną konstrukcję, którą będzie można zastosować do dowolnego protokołu PIR. Przedstawimy też kilka
faktów szacujących wydajność prywatnego wyszukiwania słów kluczowych w porównaniu do
protokołu PIR. Część z tych faktów będzie podana w formie ogólniejszej, w której to ilość
replik bazy danych, a co za tym idzie ilość serwerów je obsługujących będzie parametrem.
Ponieważ wyszukiwanie słów kluczowych jest uzupełnieniem funkcjonalności protokołu
PIR(jest to protokół wyższego poziomu), będzie on wykonywany tak samo jak PIR pomiędzy serwerem S będącym w posiadaniu bazy danych oraz użytkownikiem U. Będziemy więc
abstrahować w stosunku do modelu w jakim odbywa się protokół wyszukiwania słów kluczowych, ponieważ jest on wyznaczony przez model PIR. Oczywiście ze względów praktycznych,
jesteśmy zainteresowani tylko modelem, w którym bezpieczeństwo oparte jest na założeniach
obliczeniowych.
3.2. Podstawowe definicje
Ogólna idea stojąca za protokołem prywatnego wyszukiwania słów kluczowych to umieszczenie przez S zbioru słów {s1 , s2 , ..., sn } w specjalnej strukturze umożliwiającej wyszukiwanie
słów. Następnie U przeszukuje tę strukturę w poszukiwaniu słowa w. Struktura ta przeszukiwana jest przez U w taki sposób, by S nie wiedział czego poszukujemy. W wyniku
wyszukiwania U dowiaduje się, czy w ∈ {s1 , s2 , ..., sn } i gdy tak jest może poznać fizyczny
adres gdzie w bazie danych znajdują się informacje powiązane ze słowem w.
27
3.2.1. Uogólniony PIR
Podstawowa definicja PIR obejmuje tylko przypadek pobrania jednego bitu z bazy danych.
Możemy jednak rozważać protokół PIR w którym serwer (w ogólniejszym przypadku kilka
serwerów) przechowuje nie n bitów, lecz n bloków, każdy długości l bitów, a użytkownik chce
poznać i-ty blok. Zagadnienie to będziemy oznaczać poprzez P IR(l, n, m), gdzie m oznacza
ilość serwerów. Jeśli l = 1 to otrzymujemy zwyczajny protokół PIR, który oznaczać będziemy P IR(n, m). Jasne jest, że P IR(l, n, m) można rozwiązać wykonując l razy P IR(n, m).
W dalszych naszych rozważaniach na temat prywatnego wyszukiwania słów kluczowych odnosimy się do uogólnionego PIR, w którym mamy m serwerów, co w szczególności aplikuje
się do przypadku w którym m = 1.
3.2.2. PERKY
Definicja 3.1 Niech każdy serwer, spośród m serwerów, będzie w posiadaniu bazy danych
składającej się z n napisów s1 , s2 , ..., sn ∈ {0, 1}l , a użytkownik w posiadaniu w ∈ {0, 1}l .
Prywatnym wyszukiwaniem słów kluczowych nazywamy protokół, który pozwala użytkownikowi sprawdzić czy istnieje j ∈ {1, ..., n} takie, że w = sj , w taki sposób by żaden serwer nie
dowiedział się nic o w.
Stwierdzenie, że serwer nic się nie dowie o słowie w ma oczywiście różne znaczenie w
różnych modelach obliczeń. Na przykład w modelu obliczeniowym serwer może wykonywać
obliczenia nie dłużej niż w wielomianowym czasie i musimy zagwarantować, że w trakcie
tych obliczeń nie dowie się nic o w (być może jakby mógł dłużej liczyć, uzyskał by pewne
informacje o w).
Prywatne wyszukiwanie słów kluczowych oznaczymy skrótem P ERKY (l, n, m) (od angielskiej nazwy PrivatE Retreival by KeY words), gdzie l to długość napisów, n ilość napisów
w bazie danych, m ilość serwerów mających tę samą kopię bazy danych. Złożoność komunikacyjną protokołu PIR oznaczać będziemy poprzez C(l, n, m) lub C(n, m), gdy l = 1. Zaś
ilość rund analogicznie poprzez R(l, n, m) lub R(n, m), gdy l = 1.
3.2.3. Porównanie PIR i PERKY
Twierdzenie 3.1 [19] Problem P IR(n, m) można rozwiązać za pomocą protokołu o takiej
samej złożoności komunikacyjnej jak P ERKY (log(n) + 1, n, m).
→
Dowód: Zamieńmy zawartość bazy danych z wektora −
x = [x0 , ..., xn−1 ] na n słów, każde
długości log(n) + 1 bitów. Zapiszmy j ∈ {1, ..., n} w postaci binarnej j1 j2 ...jlog(n) i zamieńmy
każdy bit xj bazy danych na słowo j1 j2 ...jlog(n) xj . Przypuśćmy, że U jest zainteresowany
→
w uzyskaniu i-tego bitu z bazy −
x . Bitem tym jest 1, jeśli i-te słowo trzymane przez bazę danych to i1 i2 ...ilog(n) 1. Więc wystarczy by U i serwery S1 , ..., Sm wykonały protokół
P ERKY (log(n) + 1, n, m), w którym U szuka słowa i1 i2 ...ilog(n) 1.
Powyższa redukcja pokazuje, że nie można liczyć na to by protokół P ERKY był znacząco bardziej efektywny niż protokół P IR. Zauważmy, że poprawnym protokołem P ERKY
jest przesłanie wszystkich słów. Oczywiście takie postępowanie, z analogicznych powodów
jak dla protokołów PIR jest nie do przyjęcia.
28
3.3. Wyszukiwanie informacji po słowach kluczowych
Przedstawimy teraz dwa protokoły P ERKY , pierwszy mało efektywny działający na podobnej zasadzie jak wyszukiwanie binarne oraz drugi efektywniejszy, wykorzystujący własności
drzewa prefiksowego.
3.3.1. Wyszukiwanie binarne
Twierdzenie 3.2 [19] Istnieje protokół P ERKY (l, n, m) o złożoności komunikacyjnej
Pdlog(n)e
Pdlog(n)e
C(l, 2q−1 , m) oraz ilości rund q=1
R(l, 2q−1 , m).
q=1
Dowód: Bez zmniejszania ogólności możemy założyć, że n = 2d − 1 dla pewnego d ∈ N.
• Każdy z serwerów sortuje leksykograficznie n słów s1 , ..., sn . Następnie słowa te zostają
przypisane do d tablic różnej długości. Tablica numer q (1 ≤ q ≤ d) zawiera 2q−1 słów,
q
które występują na pozycjach 21q (n + 1), 23q (n + 1), ..., 2 2−1
q (n + 1).
• Podczas wykonania protokołu PERKY pozycję j ∈ {1, ..., n} nazywamy możliwą, jeśli jest możliwe, że w = sj na podstawie informacji, które posiada użytkownik U. U
wyszukuje binarnie słowo w, wykonując protokół PIR d razy. Na początku wszystkie
pozycje 1, ..., n są możliwe. W q-tym (1 ≤ q ≤ d) wykonaniu protokołu PIR U prywatnie pozyskuje pojedyńcze słowo spośród 2q−1 słów, które tworzą q-tą tablicę. Pozycja
pozyskanego słowa jest medianą pozycji, które są wciąż możliwe. Po każdym wywołaniu
PIR ilość możliwych pozycji jest zmniejszana o połowę, po d wywołaniach U dowiaduje
się czy w ∈ {s1 , ..., sn }. Dodatkowo jeśli dla któregoś j, w = sj , U poznaje też pozycję
j. Zauważmy, że U mógł w pierwszym kroku odkryć, że w = sj dla pewnego j. Mógłby więc przerwać dalsze przeszukiwania. Niestety postępowanie takie zdradza słowo w
serwerom, dlatego U musi kontynuować protokół, aż pobierze słowa ze wszystkich d
tablic.
Przedstawiony powyżej protokół PERKY to nic innego tylko wykonanie dlog(n)e razy protokołu PIR. Podczas q-tego wykonywania protokołu PIR jest pobierane słowo o długości l z
tablicy zawierającej 2q−1 słów. Dowodzi to, że złożoność komunikacyjna przedstawionego proPdlog(n)e
Pdlog(n)e
tokołu jest q=1
C(l, 2q−1 , m), natomiast ilość rund określa wzór q=1
R(l, 2q−1 , m).
Wyszukiwanie to ma oprócz dużej złożoności komunikacyjnej pewną wadę. Mianowicie
użytkownik dowiaduje się aż dlog(n)e spośród n słów kluczowych przetrzymywanych przez
bazę danych. Chcielibyśmy raczej tego uniknąć, gdyż informacja o istnieniu jakiegoś słowa
kluczowego w pośród słów trzymanych przez bazę danych może być cenna. Protokół wyszukiwania prefiksowego słów kluczowych nie posiada tej wady, a ponadto jest efektywniejszy
komunikacyjnie.
3.3.2. Wyszukiwanie prefiksowe
Przedstawimy teraz protokół PERKY(l, n, k) ze złożonością komunikacyjną O(l ∗ C(log(n) +
log(l), nl , k) + C(l, n, k)) oraz ilością rund O(l ∗ R(log(n) + log(l), nl , k) + R(l, n, k)).
Do przedstawienia takiego protokołu użyjemy struktury danych nazywanej drzewem prefiksowym. By skonstruować takie drzewo użyjemy tablic, które będą reprezentować poziomy
drzewa (zbiory węzłów drzewa, których ścieżka do korzenia ma jednakową długość).
Niech W = {s1 , s2 , ..., sn } będzie niepustym zbiorem słów nad alfabetem {0, 1} długości
l przetrzymywanych przez serwer S. Dla każdego i ∈ {1, ..., l} słowo si można zapisać w
29
(i)
(i)
(i)
(i)
postaci si = w1 w2 ...wl , gdzie dla każdego j ∈ {1, ..., l}, wj ∈ {0, 1}. Niech T1 , T2 , ..., Tl
będą tablicami reprezentującymi wszystkie prefiksy słów z W . Dokładniej, tablica Ti będzie
reprezentować wszystkie, parami różne, prefiksy długości i. Rozważmy prefiks p ∈ {0, 1}i
pewnego słowa z W . Jest on reprezentowany przez jeden element e w tablicy Ti . Element e
składa się z pary liczb eL oraz eR . Mamy dwa przypadki:
• p jest prefiksem właściwym, czyli i < l. Wtedy liczby eL oraz eR oznaczają odpowiednio
indeksy (najmniejszy indeks to 1) w tablicy Ti+1 pod którymi znajdują się elementy
reprezentujące prefiksy p0, p1 ∈ {0, 1}i+1 . Jeśli p0 (lub p1) nie jest prefiksem żadnego
słowa ze zbioru W to liczba eL (lub eR ) ma wartość 0.
• Jeśli i = l to p jest pewnym słowem z W . Gdy ostatnim symbolem p jest 0 to liczba eL
ma wartość 1, natomiast gdy p kończy się na 1 to liczba eR ma wartość 1. Poza tym
jeśli p jest postaci u0 dla pewnego słowa u oraz u1 ∈
/ W to eR = 0. Analogicznie, gdy
p jest postaci u1 dla pewnego słowa u oraz u0 ∈
/ W to eL = 0.
Powyżej opisana struktura tablic tworzy drzewo prefiksowe. Mając taką strukturę danych
możemy przedstawić teraz protokół PERKY wyszukiwania prefiksowego. Tak jak wcześniej
było opisywane, protokół będzie wykonywany pomiędzy użytkownikiem U (będącym w posiadaniu słowa w) oraz serwerami S1 , .., Sm posiadającymi zbiór słów W = {s1 , ..., sn }.
Protokół będzie przebiegał następująco:
• Na początku U dostaje od jednego z serwerów ogólne dane na temat struktury danych
tworzącej drzewo prefiksowe. Dokładniej U otrzymuje informacje ile elementów jest w
tablicach T1 , ..., Tl .
• Następnie U oraz S1 , ..., Sm wykonują l razy protokół PIR, po jednym wykonaniu
dla każdej z tablic T1 , ..., Tl . Niech w = w1 ...wl będzie słowem szukanym przez U.
Na początku k-tego (1 ≤ k ≤ l) wykonania protokołu PIR U zna indeks elementu
reprezentującego prefiks w1 ...wk . Z konstrukcji tablic wynika, że tablica T1 ma tylko
jeden element, więc na początku znany jest indeks elementu reprezentującego prefiks
w1 .
Ponieważ każdy element tablicy Ti składa się z pary liczb, możemy traktować ją jakby miała dwa razy więcej elementów, gdzie elementem tablicy jest jedna liczba. Jeśli
element (eL , eR ) miał wcześniej indeks w tablicy j-ty to teraz eL będzie miał indeks
2 ∗ j − 1, a eR indeks 2 ∗ j.
Tak więc U oraz S1 , ..., Sm wykonują protokół PIR w wyniku którego U pobiera liczbę z
tablicy Tk . Jeśli k = 1 oraz w1 = 0, to U pobiera element pierwszy (eL ), natomiast gdy
k = 1 oraz w1 = 1, to U pobiera element drugi (eR ). Gdy pobrany element jest równy
0 to oznacza to, że w ∈
/ W . U mógłby więc przerwać wykonywanie protokołu. Niestety
przerwanie wcześniej protokołu daje informację serwerom, że w ∈
/ W , co jest niezgodne z
założeniem. Więc by ukryć ten fakt U wykonuje dalej protokół, losując dowolną wartość
(nie przekraczającą wielkości kolejnej tablicy) i traktując ją jako pobrany element. Jeśli
l > k > 1 to U poznał w poprzednim wykonaniu protokołu PIR odpowiedni indeks
jk+1 elementu reprezentującego prefiks w1 ...wk+1 . Jeśli więc wk+1 = 0 to U pobiera
element z tablicy Tk+1 o indeksie 2 ∗ jk+1 − 1, natomiast gdy wk+1 = 1 to U pobiera
element z tablicy Tk+1 o indeksie 2 ∗ jk+1 .
• W ostatnim kroku, gdy k = l, protokół przebiega analogicznie jak w poprzednim kroku,
z tą różnicą, że pobrana liczba eL (lub eR ) określa czy w ∈ W . Dokładniej, gdy pobrana
30
liczba jest równa 0 to U wie, że w ∈
/ W , a gdy pobrana liczba jest równa 1 to U wie,
że w ∈ W .
Jak widać, przedstawiony protokół pozwala tylko stwierdzić czy w ∈ W , nie daje nam
natomiast żadnych wskazówek gdzie w bazie danych znajdują się informację dotyczące słowa
kluczowego w. Uzyskać takie informacje możemy poprzez zmianę niektórych elementów trzymanych w tablicy Tl (ostatniej tablicy). Mianowicie, gdy w pewnym elemencie tablicy Tl jest
wartość różna od zera, element ten odpowiada jednoznacznie pewnemu słowu w ∈ W . Zmieniamy więc przetrzymywaną wartość (zawsze jest to 1) na wartość określającą miejsce na dysku, gdzie znajdują się informacje dotyczące słowa w. Wykonujemy następnie P IR(D, n, 1),
gdzie D to ilość bitów wystarczająca do zapisania liczby określającej dowolne miejsce na
dysku. W ten sposób dostajemy protokół umożliwiający nam sprawdzenie, czy dane słowo
kluczowe w występuje w zbiorze słów kluczowych W oraz w przypadku, gdy w ∈ W , pobranie
informacji gdzie na dysku znajdują się dane dotyczące słowa w. Teraz możemy wykonać protokół PIR na właściwej bazie danych (znamy już miejsce z którego pobierzemy informację) i
pobieramy interesujące nas dane.
Podobną metodę pobierania adresu, gdzie na dysku znajdują się informacje dotyczące szukanego słowa kluczowego, możemy zastosować również do protokołu PERKY wyszukiwania
binarnego.
3.3.3. Wzmocnienie protokołu PERKY (wyszukiwanie prefiksowe)
Protokoły PIR i PERKY są mocno zorientowane na bezpieczeństwo użytkownika. Co jednak,
gdy chcemy zadbać również o bezpieczeństwo serwera, a w szczególności bazy danych przez
niego obsługiwanej. Sprytny użytkownik, może wysyłać specjalnie skonstruowane zapytanie
do serwera w celu poznania większej ilości informacji niż przewiduje to protokół. Protokoły
PIR nie gwarantują, że użytkownik pozna tylko jedną informację. Jak łatwo spostrzec w
definicji w ogóle brak wzmianki na temat jak dużo danych pozna użytkownik, ważne jest
tylko by poznał interesującą go informację.
Rozważmy protokół PIR przedstawiony w sekcji 2.1.2. W protokole tym użytkownik może
wybrać pewne szczególne elementy z G i G\H by poznać więcej niż jeden bit z bazy danych.
Jak wiele informacji może użytkownik uzyskać dobierając odpowiednio swoje zapytanie wymaga głębszej analizy i wykracza poza tematykę niniejszej pracy. Istnieje natomiast ogólna
metoda przekształcająca dowolny protokół PIR w symetryczny PIR (w skrócie SPIR).
SPIR różni się od zwykłego PIR (1.4.1) tym, że oprócz utrzymania w tajemnicy przed
serwerem preferencji użytkownika, gwarantuje prywatność danych serwera. Mianowicie użytkownik (nawet ten nieuczciwy, próbujący dobrać tak zapytanie by uzyskać jak najwięcej
informacji) w wyniku wykonania protokołu SPIR poznaje tylko jeden bit z bazy danych i nic
więcej.
Pokażemy teraz ogólną metodę ([20]) przekształcenia protokołu PIR na SPIR, opierającą
się na trudności obliczeniowej decyzyjnego problemu Diffiego-Hellmana. Jeśli protokół PIR
ma złożoność komunikacyjną C(n) oraz przebiega przez R(n) rund to wynikowy protokół ma
złożoność komunikacyjną C(n) + 1 oraz przebiega przez co najwyżej R(n) + 1 rund. Załóżmy,
że S jest w posiadaniu n bloków m1 , ..., mn danych oraz dla każdego i ∈ {1, ..., n}, zachodzi
mi ∈ G. U zaś chce poznać mα . Niech g będzie generatorem grupy G, a h = g z , gdzie
z ∈ {1, ..., |G|} jest losowo wybrane przez U i znane tylko jemu.
Przebieg protokołu:
• U wysyła do S y = g r ∗ hα , gdzie r jest losowym elementem wybranym ze zbioru
{1, ..., |G|}.
31
• S oblicza ci = (g ki , mi ∗ (y/hi )ki ), 1 ≤ i ≤ n, gdzie ki są losowo wybranymi elementami
ze zbioru {1, ..., |G|}.
• S traktuje otrzymane wartości ci jako bloki z danymi (zauważmy, że nie ograniczamy
się tu tylko do bloków składających się z jednego bitu). Następnie S i U wykonują
protokół PIR, w którym U chce poznać cα .
• U oblicza mα = b/ar , gdzie cα = (a, b).
Przedstawiony powyżej schemat przekształca dowolny obliczeniowy 1-serwerowy PIR w
1-serwerowy obliczeniowy SPIR.
Wiemy już jak zapewnić bezpieczeństwo obu stronom w przypadku pobierania tylko jednego bitu informacji. Czy jednak serwer jest bezpieczny gdy wykonywany jest protokół PERKY?
Okazuje się, że nie. Nieuczciwy użytkownik, w przedstawionym protokole PERKY wyszukiwania prefiksowego, może już na początku protokołu dowiedzieć się, że serwer nie posiada
szukanego przez niego słowa czyli, że w ∈
/ W . Wtedy może spróbować tak pobierać elementy
z kolejnych tablic Tj by dowiedzieć się, czy inne słowo kluczowe w0 6= w należy do W . Warto
tu zauważyć, że być może nie jest to jedyny sposób w jaki użytkownik może dowiedzieć się
pewnych dodatkowych informacji.
Wielkości tablic Ti określają szerokości drzewa prefiksowego zbudowanego ze zbioru W ,
a w przedstawionym protokole PERKY wyszukiwania prefiksowego, użytkownik poznaje ich
rozmiary, więc dowiaduje się jednocześnie pewnych własności słów ze zbioru W .
Problemy te możemy jednak w dużej mierze przezwyciężyć. Po pierwsze po skonstruowaniu tablic T1 , ..., Tl , reprezentujących drzewo prefiksowe, serwer permutuje je. Dokonuje tego
zaczynając od ostatniej tablicy Tl . Przy czym po spermutowaniu tablicy Ti (i > 1), zmienia
odpowiednio wartości w tablicy Ti−1 , które to wskazywały indeksy w tablicy Ti , w taki sposób
by wskazywały ten sam element co poprzednio. Łatwo zauważyć, że po takim przekształceniu
użytkownik dowiaduje się czy w ∈ W , dopiero gdy pobierze wartości z tablicy Tl .
Pozostaje jeszcze problem z poznaniem przez użytkownika wielkości tablic T1 , ..., Tl (daje
to użytkownikowi pewne informacje na temat zbioru W ). Możemy częściowo rozwiązać ten
problem zwiększając ilość słów, czyli dodając pewne dodatkowe słowa do zbioru W . Drugą
metodą może być dodanie pewnej losowej ilości elementów do tablic T1 , ..., Tl . Jak zmieniać
wielkości tablic wymaga głębszego zbadania, szczególnie ciekawe może być zagadnienie jak
zwiększać ich rozmiar, by zminimalizować ilość informacji, które ”wyciekają” w wyniku poznania struktury drzewa prefiksowego.
32
Rozdział 4
Implementacja
W rozdziale tym opiszemy zagadnienia związane z implementacją protokołów PERKY i PIR.
Opiszemy ogólną architekturę implementowanego systemu oraz przeanalizujemy osiągnięte
przez system rezultaty na przykładowej bazie danych.
4.1. Narzędzia
System został zaimplementowany w języku java przy użyciu darmowego narzędzia Eclipse
wspomagającego programowanie. Na wybór javy do implementacji złożyły się następujące
czynniki:
• Darmowy i łatwo dostępny kompilator
• Możliwość uruchomienia systemu na wielu platformach bez konieczności przygotowania
specjalnie na daną platformę dystrybucji.
• Dostępność wielu klas i bibliotek kryptograficznych.
• Łatwość budowy graficznego interfejsu użytkownika
4.2. Przyjęte założenia
Implementacja protokołów PIR i PERKY miała charakter eksperymentalny. Oznacza to, że
autor postawił sobie za zadanie stworzenie aplikacji sprawdzającej możliwości wykorzystania
tych protokołów w praktyce, przetestowania na jak dużych danych mogą one działać przy
dzisiejszych ograniczeniach sprzętowych oraz jak szybko się wykonują.
4.2.1. Długość klucza
W systemie zaimplentowano dwie instancję problemu należenia do podgrupy:
• Decyzyjny problem reszt kwadratowych
• Decyzyjny problem Diffiego-Hellmana w grupie Z∗p , gdzie p jest liczbą pierwszą postaci
p = 2*q +1, gdzie q jest liczbą pierwszą.
Obecnie (grudzień 2004 roku) problemy te są praktycznie nie do rozwiązania gdy odpowiednie
dla tych problemów grupy składają się z liczb 1024 bitowych (parametr bezpieczeństwa).
33
Ponieważ złożoność komunikacyjna implementowanych protokołów zależy od parametru
bezpieczeństwa, więc chcielibyśmy używać jak najkrótszego klucza. Do tego celu świetnie
nadają się grupy zbudowane przy użyciu krzywych eliptycznych. Długość klucza można wtedy
zmniejszyć do 128 bitów uzyskując bardzo zbliżony poziom bezpieczeństwa. Jednak krzywe
eliptyczne wymagają głębszego zbadania. Przewiduje się dodanie do funkcjonalności krzywych
eliptycznych w następnej wersji aplikacji.
4.3. Architektura implementacji
System składa się generalnie z dwóch części, serwera i klienta. Serwer jest odpowiedzialny
(tak jak to wynika z protokołu) za zarządzanie bazą danych oraz obsługiwanie zapytań klientów. Serwer może obsługiwać kilku klientów jednocześnie i jest to konfigurowalny parametr
systemu. Każde nowe połączenie z serwerem jest obsługiwane przez osobny wątek. Baza danych jest reprezentowana przez dwa pliki. Pierwszy z nich zawiera dane, drugi zaś zawiera
słowa kluczowe i adresy gdzie w pierwszym pliku znajdują się odpowiadające danemu słowu
kluczowemu informacje. Zalecane jest by dane zapisywać w jak najbardziej zwięzłej postaci,
gdyż protokół PIR działa w czasie liniowym, względem ilości bitów tworzących bazę danych.
Dodatkowo plik ze słowami kluczowymi zawiera informację jaka jest maksymalna długość
słów kluczowych, co jest niezbędne do prawidłowego przebiegu protokołu wyszukiwania słów
kluczowych.
Serwer udostępnia dostęp do bazy danych poprzez protokół PIR lub PERKY.
Każdy problem należenia do podgrupy musi dziedziczyć z abstrakcyjnej klasy SubgroupMembershipProblem. Klasami dziedziczącymi z klasy SubgroupMembershipProblem są w
obecnej wersji systemu QRA i DDH oznaczające odpowiednio problemy odróżnienia reszt od
niereszt kwadratowych oraz decyzyjny problem Diffiego-Hellmana.
Grupę dla danej instancji problemu należenia do podgrupy opisuje klasa Group. Klasami dziedziczącymi z klasy Group są w obecnej wersji systemu GQRA i GDDH, grupy te są
odpowiednie dla problemów opisanych w klasach QRA i DDH. Zauważmy, że klasa Group
powinna implementować interfejs Serializable, gdyż obiekty podklas Group są wysyłane pomiędzy klientem i serwerem. GUI użytkownika (klasa UserGUI ) i serwera (klasa AdminGUI )
jest zaimplementowane w javie przy użyciu graficznych komponentów Swinga.
4.3.1. Dekompozycja logiczna systemu
Dekompozycje systemu na komponenty przedstawia rysunek 4.1. Strzałki na rysunku przedstawiają poszczególne zależności między różnymi komponentami.
W systemie zostało wyróżnionych sześć komponentów:
• Interfejs użytkownika
• Interfejs administratora
• Logika biznesowa
• Moduł komunikacyjny (protokoły)
• Baza danych
• Przechowywanie konfiguracji
34
warstwa
interfejsów
Interfejs
administratora
Interfejs
uzytkownika
warstwa
logiki
Logika
biznesowa
warstwa
sieciowa
Modul komunikayjny
(protokoly)
warstwa
danych
Przechowywanie
konfiguracji
Baza
danych
Rysunek 4.1: Dekompozycjonalny model systemu - diagram komponentów
4.3.2. Najważniejsze komponenty
Interfejs użytkownika
Ten komponent jest odpowiedzialny za przedstawianie pól tekstowych z komunikatami, pól
tekstowych do wpisywania danych i wszelkich list tekstowych z możliwością zaznaczania odpowiednich pozycji, posiada także menu. Komponent ten reprezentuje klasa UserGUI.
Interfejs Administratora
Ten komponent, podobnie jak interfejs użytkownika jest odpowiedzialny za przedstawianie pól
tekstowych z komunikatami, pól tekstowych do wpisywania danych i wszelkich list tekstowych
z możliwością zaznaczania odpowiednich pozycji, posiada także menu. Dodatkowo jest w nim
możliwość konfiguracji bazy danych. Komponent ten reprezentuje klasa AdminGUI.
Moduł komunikacyjny
Moduł komunikacyjny odpowiada za komunikację użytkownika z bazą danych. Udostępnia logice biznesowej komunikację z tymi serwerami na wyższym poziomie abstrakcji (np. ”połącz”,
”pobierz bit”, ”wyszukuj słowo”, itp.). Komunikacja pomiędzy serwerem a klientem odbywa
się poprzez protokół TCP/IP. Rozwiązanie takie zostało przyjęte ze względy na niezawodność
komunikacyjną (potwierdzanie i ewentualna retransmisja pakietów) bez której protokoły PIR
i PERKY nie miały by szans działać poprawnie. Klient i serwer wymieniają informację dzięki
strumieniom zaimplementowanym w klasach ObjectInputStream i ObjectOutputStream.
Diagram 4.2 przedstawia projekt głównych klas dla komponentu moduł komunikacyjny.
35
Protocol
-ois: ObjectInputStream
-oos: ObjectOutputStream
ProtocolClient
KOProtocolClient
ProtocolServer
KOProtocolServer
KWSProtocolClient
KWSProtocolServer
Rysunek 4.2: Główne klasy wchodzące w skład modułu komunikacyjnego
Logika biznesowa
Komponent ten zna odpowiednie protokoły, dzięki czemu przekazuje w odpowiedni sposób
informacje do interfejsów użytkownika i administratora, a także modułu komunikacyjnego.
Komponent ten jest także odpowiedzialny za odpowiednie interpretowanie czynności użytkownika np. gdy użytkownik w odpowiednim menu wybierze opcje ustawienia serwera z którym chce się połączyć i wpisze nazwę serwera i będzie chciał zapisać ustawienia to zostaną
one przekazane do komponentu przechowywania konfiguracji i tam zapisane. Komponent ten
jest głównym centrum zarządzania aplikacją. W tym komponencie są podejmowane decyzje
(np. co wyświetlić, co przesłać do serwera i w drugą stronę) na podstawie akcji użytkownika i akcji serwera. Nadzorowanie nad aplikacją wiąże się z silnym powiązaniem z modułem
komunikacyjnym i interfejsem użytkownika.
Diagramy 4.3 przedstawiają projekt głównych klas dla komponentu logiki biznesowej.
Przechowywanie konfiguracji
Ten komponent przechowuje informacje o ustawieniach systemu. W szczególności umożliwia
po stronie klienta i serwera na zapisywanie i wczytywanie ustawień systemu np. wprowadzonego adresu serwera, parametru bezpieczeństwa, czy ścieżek do plików z bazą danych.
Baza danych
Jest to komponent reprezentujący bazę danych. Ma on opcje do dodawania, usuwania oraz
zapisywania na dysku słów kluczowych oraz powiązanych z nimi danych. Posiada też dane odnośnie użytkowników, którzy mogą korzystać z bazy danych, tj. login i hasło. Klasą
reprezentującą ten komponent jest klasa DataBase.
4.4. Osiągnięte rezultaty (testy)
Testy zostały przeprowadzone w sieci lokalnej umożliwiającej transmisję danych pomiędzy
komputerami z prędkością 100Mb/s. Każdy z komputerów wyposażono w procesor Intel pen36
SubgroupMembershipProblem
BitCode
QRA
Group
State
StateClient
BitDecode
DDH
StateServer
GDDH
GQRA
Rysunek 4.3: Główne klasy wchodzące w skład logiki biznesowej
tium IV 2.4 GHz i 1G pamięcią RAM. W poniższej tabeli znajduje się kilka testów uwzględniających takie czynniki jak wielkość bazy danych, parametr bezpieczeństwa oraz rodzaj instancji problemu należnia do podgrupy. Duża przepustowość łączy miała minimalne znaczenie
dla czasu wykonywania protokołów, gdyż implementowane protokoły mają niską złożoność
komunikacyjną.
Jak widać z zamieszczonych poniżej wyników (patrz tabela 4.1), protokół PIR działa w
akceptowalnym czasie dla baz danych nie przekraczających wielkością kilkudziesięciu megabajtów. Poza tym warto wspomnieć, że przedstawiona implementacja protokołu PIR, a przede
wszystkim PERKY potrzebuje znaczącej ilości pamięci operacyjnej by móc poprawnie działać.
Tabele 4.2 i 4.3 zawierają czas działania protokołu PERKY w zależności od ilości słów kluczowych przechowywanych w bazie danych. Pierwsza przedstawia wyniki przy wykorzystaniu
problemu QRA, a druga przy wykorzystaniu problem DDH.
Tabela 4.4 pokazuje wpływ ilości użytkowników na szybkość wykonywania protokołu PIR.
Jak widzimy zwiększenie ilości jednocześnie obsługiwanych użytkowników do dwóch wpływa
liniowo na czas przebiegu protokołu.
Warto jeszcze zaznaczyć, że duży wpływ na czas działania protokołu PIR ma odpowiednie
ustalenie współczynników t i l (patrz podrozdział 2.1.2). Z przeprowadzonych testów (4.5)
wynika, że współczynnik t nie powinien przekraczać 5000, natomiast współczynnik l nie
powinien być większy niż 3.
37
wielkość bazy danych (w bitach)
10000
10000
10000
10000
100000
100000
100000
100000
1000000
1000000
1000000
1000000
10000000
10000000
10000000
10000000
100000000
100000000
100000000
100000000
parametr
bezpieczeństwa
128
256
512
1024
128
256
512
1024
128
256
512
1024
128
256
512
1024
128
256
512
1024
czas w sekundach pobrania jednego bitu
(QRA)
0.3
1.0
3.8
23.5
0.9
3.0
5.6
11.8
3.1
9.8
44.9
240.1
20.2
60.0
173.7
811.9
225.4
463.7
1778.8
7437.2
czas w sekundach pobrania jednego bitu
(DDH)
0.5
1.9
7.2
30.6
1.1
6.5
7.8
13.9
8.0
20.6
74.1
384.4
50.3
118.8
301.5
1033.6
451.3
904.9
3289.6
10343.3
Tabela 4.1: Wyniki pomiarów czasowych protokołu PIR (patrz podrozdział 2.1.2) dla różnej
wielkości baz danych.
ilość słów kluczowych
10
100
800
3200
6400
12800
25600
51200
czas działania protokołu (w sekundach)
przy maksymalnej
długości słów kluczowych 15 znaków
5.3
13.0
29.1
43.0
89.2
187.9
255.2
430.8
czas działania protokołu (w sekundach)
przy maksymalnej
długości słów kluczowych 30 znaków
8.8
26.3
58.1
86.3
182.5
377.6
537.1
891.9
Tabela 4.2: Wyniki czasowe protokołu PERKY przy użyciu problemu odróżnienia reszt kwadratowych od niereszt
38
ilość słów kluczowych
10
100
800
3200
6400
12800
25600
51200
czas działania protokołu (w sekundach)
przy maksymalnej
długości słów kluczowych 15 znaków
5.4
12.3
27.7
55.6
98.6
136.4
192.2
356.7
czas działania protokołu (w sekundach)
przy maksymalnej
długości słów kluczowych 30 znaków
7.2
15.9
38.0
67.2
141.4
205.9
326.3
499.5
Tabela 4.3: Wyniki czasowe protokołu PERKY przy użyciu problemu Diffiego-Hellmana.
wielkość bazy danych (w bitach)
parametr
bezpieczeństwa
10000
100000
1000000
10000000
10000
100000
1000000
10000000
512
512
512
512
1024
1024
1024
1024
czas
w
sekundach
pobrania
jednego
bitu (QRA)
5.1
13.7
52.6
241.8
41.2
93.1
285.3
420.8
czas
w
sekundach
pobrania
jednego
bitu (DDH)
17.0
32.5
108.6
510.2
174.4
273.5
599.7
905.1
Tabela 4.4: Średnie wyniki czasowe protokołu PIR dla jednego użytkownika przy jednoczesnej
obsłudze przez serwer dwóch klientów.
39
wielkość bazy danych (w bitach)
10000
10000
10000
100000
100000
1000000
1000000
10000000
10000000
100000000
100000000
parametr
bezpieczeństwa
512
512
512
512
512
512
512
512
512
512
512
współczynnik
t
współczynnik
l
10000
100
22
317
47
1000
100
3163
216
10000
465
1
2
3
2
3
2
3
2
3
2
3
czas w sekundach
pobrania jednego
bitu (QRA)
90.2
5.4
8.9
6.1
13.1
45.6
85.6
173.8
220.3
320.4
291.8
Tabela 4.5: Wyniki czasowe protokołu PIR przy jednoczesnej obsłudze, przez serwer, dwóch
klientów.
40
Rozdział 5
Podsumowanie
W rozdziale tym przedstawimy krótkie podsumowanie, czego udało się dokonać w niniejszej
pracy. Przedstawimy ogólne rezultaty i wskażemy co można i co trzeba usprawnić by prywatne
pozyskiwanie informacji znalazło zastosowanie w dużych komercyjnych bazach danych.
5.1. Wnioski
W niniejszej pracy zaprezentowaliśmy dziedzinę PIR, koncentrując się na 1-serwerowych protokołach PIR. Opisaliśmy eksperyment polegający na implementacji protokołów PIR i PERKY oraz sprawdzeniu ich użyteczności w rzeczywistej aplikacji. W pracy tej opisaliśmy też
szczegółowo zależności pomiędzy protokołami PIR i PERKY dotyczące bezpieczeństwa i złożoności protokołów. Opisany i dostarczony razem z pracą system może stać się bardzo pomocny przy implementowaniu nowszych protokołów. System umożliwia łatwe dołączenie nowego
1-serwerowego protokołu PIR do niego i przetestowanie go w praktyce.
Implementacja opisanych w tej pracy protokołów PIR pokazują ich użyteczność dla stosunkowo niewielkich baz danych (do kilkudziesięciu MB). Ogranicza to zastosowanie przedstawionych tu protokołów PIR do wyłącznie specjalistycznych celów. Mogą je z powodzeniem
stosować duże korporację do swoich celów biznesowych. Niestety udostępnienie korzystania z
protokołów PIR jednocześnie przez dużą liczbę użytkowników jest jeszcze nie do przyjęcia ze
względu na dużą ilość obliczeń wykonywaną przez serwer podczas obsługi jednego zapytania.
5.2. Kierunki rozwoju
Prywatne pozyskiwanie informacji od kilku lat przechodzi burzliwy rozwój. Na początku
rozwoju tej dziedziny, stawiano na minimalizację komunikacji pomiędzy użytkownikiem i
serwerem. W 1-serwerowym PIR czynnik komunikacyjny odchodzi na drugi plan ze względu na ilość obliczeń jakie musi wykonać serwer. Ilość obliczeń wykonywanych przez serwer
jest w bieżącej chwili wąskim gardłem dla 1-serwerowych PIR. Potrzebna jest więc metoda
zmniejszająca ilość obliczeń. Metodą taką może być wstępne przetworzenie zawartości bazy
danych, w sposób ułatwiający późniejszą odpowiedź na zapytania użytkownika. Metoda taka
istnieje dla 2-serwerowego PIR, niestety obecnie nie wiadomo czy analogiczna metoda da się
zaaplikować do 1-serwerowego PIR.
Poważnym mankamentem jest też brak 1-serwerowych protokołów PIR, umożliwiających
pobieranie bloku danych zamiast tylko jednego bitu. Przy czym długość bloku danych powinien być modyfikowalnym parametrem protokołu. Próba konstrukcji takiego protokołu została przedstawiona w pracy [7], niestety protokół ten okazał się niedostatecznie bezpieczny.
41
Powstanie 1-serwerowego protokołu PIR, zawierającego obie wyżej wymienione cechy
umożliwi aplikację go do komercyjnych zastosowań na dużą skalę. W połączeniu z innymi
technikami kryptograficznymi takimi jak anonimizacja, prywatność użytkownika wejdzie na
wyższy poziom i znacząco zwiększy bezpieczeństwo w Internecie.
42
Dodatek A
Zawartość płyty CD
tj praca mgr.pdf
user.jar
admin.jar
srcpirp
keyWords.pir
dataBase.pir
all files.rar
Praca magisterska w formacie PDF
Skompilowana część kliencka aplikacji
Skompilowana część serwerowa aplikacji
Katalog zawierający kompletne źródła aplikacji
Przykładowy zbiór słów kluczowych
Przykładowa baza danych
Wszystkie powyższe pliki skompresowane w jedno archiwum RAR
43
Dodatek B
Działanie aplikacji
B.1. Kompilacja
Do skompilowania źródeł potrzebny jest kompilator javac z platformy J2SE w wersji 1.4.2 lub
nowszej. Po skopiowaniu źródeł z katalogu srcpirp z płyty do katalogu na dysku, wykonujemy
w tym katalogu komendę javac *.java.
B.2. Uruchamianie
Jeśli kompilowaliśmy aplikację ze źródeł to wykonujemy w środowisku graficznym polecenia:
• java UserGUI.class - uruchamia część kliencką aplikacji.
• java AdminGUI.class - uruchamia część serwerową aplikacji do administracji bazą danych
Jeśli natomiast nie kompilowaliśmy źródeł wykonujemy polecenia:
• java -jar user.jar - uruchamiające aplikację kliencką (patrz rys. B.1).
• java -jar admin.jar - uruchamiające aplikację serwerową do administracji bazą danych
(patrz rys. B.2)
Po uruchomieniu aplikacji zarządzającej bazą danych musimy odpowiednio ustawić ścieżki do
plików zawierających słowa kluczowe i bazę danych (po wpisaniu odpowiednich ścieżek trzeba
zapisać ustawienia klikając na przycisk ’Save settings’). Po ustawieniu i zapisaniu ścieżek do
plików, klikając na zakładkę ’Edition’ możemy sprawdzić co zawiera nasza baza danych i jakie
słowa kluczowe są jej przypisane (patrz rys B.3).
Po lewej stronie zakładki ’Edit data’ znajduje się lista słów kluczowych, a po prawej
dane powiązane z podświetlonym aktualnie słowem kluczowym. Możemy dodawać i usuwać
słowa kluczowe, służą do tego odpowiednio przyciski ’Add’ i ’Remove’. Po dodaniu słowa
kluczowego jest mu przypisany element w bazie danych który nie zawiera żadnych informacji.
By wprowadzić lub zmienić informacje przypisane danemu słowu kluczowemu, zaznaczamy
znacznik ’Edit element’, modyfikujemy pole tekstowe ’Element’, a następnie klikamy przycisk
’Save element’ by zapisać zmiany w danym elemencie. Żeby zapisać wprowadzone zmiany na
dysk klikamy przycisk ‘Save all changes to disk’.
By rozpocząć działanie serwera, klikamy na zakładce ‘Server’ (patrz rys. B.2) przycisk
‘Start’.
45
Rysunek B.1: Zrzut ekranu po uruchomieniu aplikacji klienckiej (zakładka ’Application’)
Rysunek B.2: Zrzut ekranu po uruchomieniu aplikacji dla administratora (zakładka ’Server’)
46
Rysunek B.3: Zrzut ekranu pokazujący zakładkę ’Edit data’ na której możemy modyfikować
zawartość bazy danych.
By połączyć się z serwerem, uruchamiamy odpowiednim poleceniem stronę kliencką i na
zakładce ‘Application’ klikamy przycisk ‘Connect’. Zakładka ‘Settings’ służy do konfiguracji
ustawień, które w większości można zmienić tylko gdy nie jest się połączonym z serwerem.
Wprowadzone zmiany zatwierdzamy klikając w przycisk ‘OK’.
B.3. Działanie aplikacji
Po uruchomieniu serwera i klienta oraz nawiązaniu połączenia, możemy wykonać protokół
PIR lub PERKY. By wykonać protokół PERKY wpisujemy w odpowiednie pole (patrz rys.
B.1) słowo kluczowe i klikamy w przycisk ’Search’. W czasie wykonywania protokołu będziemy informowani poprzez znajdujący się na dole pasek postępu, ile procent protokołu zostało
już zrealizowane. Jeśli szukane przez nas słowo kluczowe zostanie odnalezione w bazie danych jesteśmy o tym informowani odpowiednim komunikatem, a w odpowiednim polu pojawi
się informacja z adresem pod którym znajduje się element odpowiadający naszemu słowu
kluczowemu. By pobrać ten element klikamy przycisk ’Retrieve data’. Tak jak poprzednio
na pasku postępu jesteśmy informowani o procentowej realizacji protokołu. Po zakończeniu
protokołu PIR, z prawej strony ekranu na polu ’Received text’, zostanie wyświetlony tekst z
szukanymi informacjami.
Można oczywiście pobierać dane z bazy danych bez wyszukiwania przez słowa kluczowe.
Wymaga to jednak znajomości ich adresu w bazie danych.
By zakończyć działanie aplikacji klienta, klikamy przycisk ’Disconnect’ (patrz rys. B.1).
Natomiast by zatrzymać serwer klikamy w przycisk ’Stop’ (patrz rys. B.2).
47
Rysunek B.4: Zrzut ekranu z zakładki ’Settings’ z aplikacji klienckiej, w której można dokonać
modyfikacji parametrów protokołów.
48
Bibliografia
[1] C. Beaumont. What price privacy when dotcoms go down? NEW ZELAND HERALD,
2001.
[2] Benny Chor, Oded Goldreich, Eyal Kushilevitz, and Madhu Sudan. Private information
retrieval. In IEEE Symposium on Foundations of Computer Science, pages 41–50, 1995.
[3] Benny Chor and Niv Gilboa. Computationally private information retrieval (extended
abstract). In STOC ’97: Proceedings of the twenty-ninth annual ACM symposium on
Theory of computing, pages 304–313. ACM Press, 1997.
[4] Eyal Kushilevitz and Rafail Ostrovsky. Replication is NOT needed: SINGLE database,
computationally-private information retrieval. In IEEE Symposium on Foundations of
Computer Science, pages 364–373, 1997.
[5] Akihiro Yamamura and Taiichi Saito. Private information retrieval based on the subgroup membership problem. Lecture Notes in Computer Science, 2119:206–221, 2001.
[6] Christian Cachin, Silvio Micali, and Markus Stadler. Computationally private information retrieval with polylogarithmic communication. Lecture Notes in Computer Science,
1592:402–415, 1999.
[7] Aggelos Kiayias and Moti Yung. Secure games with polynomial expressions. Lecture
Notes in Computer Science, 2076:939–951, 2001.
[8] Don Coppersmith and Madhu Sudan. Reconstructing curves in three (and higher) dimensional space from noisy data. In STOC ’03: Proceedings of the thirty-fifth annual
ACM symposium on Theory of computing, pages 136–142. ACM Press, 2003.
[9] Yan-Cheng Chang. Single database private information retrieval with logarithmic communication, 2004.
[10] Gilles Brassard, Claude Crepeau, and Jean-Marc Robert. All-or-nothing disclosure of
secrets. In CRYPTO, pages 234–238, 1986.
[11] Shafi Goldwasser and Mihir Bellare. Lecture notes on cryptography. Summer Course
“Cryptography and Computer Security” at MIT, 1996–2001, 2001.
[12] Ueli M. Maurer and Stefan Wolf. The relationship between breaking the Diffie-Hellman
protocol and computing discrete logarithms. SIAM Journal on Computing, 28(5):1689–
1721, 1999.
[13] Todd Smith, Suresh Srinivas, Philipp Tomsich, and Jinpyo Park. Practical experiences
with java compilation. In HiPC, pages 149–157, 2000.
49
[14] S. W. Smith and D. Safford. Practical server privacy with secure coprocessors. IBM
Systems Journal issue, 40-3:683–695, 2001.
[15] Bennet Yee. Using secure coprocessors. PhD thesis, May 1994.
[16] Sean W. Smith, Elaine R. Palmer, and Steve Weingart. Using a high-performance,
programmable secure coprocessor. In FC ’98: Proceedings of the Second International
Conference on Financial Cryptography, pages 73–89. Springer-Verlag, 1998.
[17] Peter Gutmann. An open-source cryptographic coprocessor. In USENIX, editor, Proceedings of the Ninth USENIX Security Symposium, August 14–17, 2000, Denver, Colorado, Berkeley, CA, USA, 2000. USENIX.
[18] Yael Gertner, Shafi Goldwasser, and Tal Malkin. A random server model for private
information retrieval or how to achieve information theoretic PIR avoiding database
replication. Lecture Notes in Computer Science, 1518:200–214, 1998.
[19] B. Chor, N. Gilboa, and M. Naor. Private information retrieval by keywords, 1997.
[20] Wen-Guey Tzeng. Efficient oblivious transfer schemes, 2001.
50