Zaufanie w Cyberspace : Protokół zarządzania kluczami oparty na chmurze

W proponowanym protokole właściciel danych tworzy V_r, zmaterializowany widok przypisany do roli r. Następnie generuje wirtualny klucz α (zestaw cieni s₁, s₂, … s_n) i używa α do szyfrowania widoku V_r przed outsourcingiem poszczególnych cieni si na serwer ksi należący do zestawu k_s w chmurze. Również właściciel danych współdzieli z serwerami w k_s swoją politykę, wysyłając do każdego serwera ksi skojarzenie między α, reprezentowane przez cień si, który posiada każdy serwer, a zbiorem użytkowników, na przykład w postaci tokenów identyfikacyjnych. Każdy interfejs użytkownika przypisany do roli r otrzymuje od właściciela danych inny plik klucza, podczas gdy cienie (s₁, s₂,… S_n) klucza roli α są umieszczane na wybranych serwerach kluczy w chmurze. Ui użytkownika pełniący rolę ri, aby uzyskać wynik zapytania q, najpierw szyfruje q swoim lokalnym kluczem bui i wysyła go do pierwszego serwera k_s, tego, który zatrzymuje cień s₁. Zapytanie jest następnie szyfrowane we współpracy przez serwery posiadające zestaw cieni s₁, s₂,. . ., s_n. Ostatni serwer k_sn odsyła zaszyfrowane zapytanie do klienta, który odszyfrowuje je za pomocą bui i wysyła wynik Eα (Q) do niezaufanego DBMS i zwraca wynik do interfejsu użytkownika. Użytkownik szyfruje go bui i wysyła na serwery k_s w celu odszyfrowania w odniesieniu do α, czyniąc go czytelnym dla użytkownika końcowego. Odwołanie interfejsu użytkownika może zostać dokonane przez właściciela danych poprzez rozgłoszenie komunikatu kill-token (ui) do wszystkich serwerów w k_s. Wtedy serwery w ks zapomną o odszyfrowywaniu zapytań zaszyfrowanych bui. Ignorowanie instrukcji właściciela danych wymagałoby zgody wszystkich serwerów na k_s.

Zalety. Proponowany protokół wykorzystuje statyczną dystrybucję kluczy, która zmniejsza liczbę kluczy posiadanych przez użytkowników. Ponadto podejście to upraszcza unieważnianie poprzez oddzielenie kluczy lokalnych przechowywanych przez użytkowników i odpowiadających im kluczy ochrony do ról.

Ograniczenia. Jeden widok danych na rolę może prowadzić do nadmiernej nadmiarowości, nawet przy niższych kosztach przechowywania.