Informacje w bazie w formie niejawnej - najlepiej zakodowanej

Cześć,

zastanawiam się nad tematem przechowywania w bazie danych w formie nie jawnej. Konkretnie chodzi o głosowanie. Odpowiedzi mają być zakodowane, tak by nawet admin bazy, a również administrator serwerowy mając dostęp do bazy i plików nie mógł odkodować odpowiedzi bez hasła, które user sobie ustawi przy tworzeniu głosowania.

Stwierdziłem, że wykorzystam funkcję openssl_encrypt decrypt. User tworzy głosowanie, wskazuje hasło, dalej tym hasłem koduje odpowiedzi i zapisuje id głosowania i hash z w/w funkcji do bazy. Po zakończeniu głosowania twórca głosowania klika przycisk wyniki wyborów, podaje hasło i odpowiedzi są zdekodowane - zapisane w bazie już jawnie. Natomiast hasło ustawione na początku musiało by być jawnie zapisane w bazie, bo inaczej nie zakoduję odpowiedzi innych użytkowników, ale z kolei hasło nie może być w bazie jawnie bo wtedy admin mając dostęp do hasła w bazie i plików na serwerze mógłby sobie tę odpowiedź zdekodować.

Jak byście to rozwiązali?

imo jeśli rozważasz scenariusz, w którym to nawet administrator serwera może coś nabruździć, to nie da się zrobić za wiele - jakiegokolwiek zabezpieczenia byś nie zaimplementował, admin serwera może podmienić aplikację na swoją, która np. zrzuca surowe dane z formularzy do specjalnego pliku albo robi inny wariant ataku man-in-the-middle.

Jednym z moich początkowych pomysłów było to, że komputer użytkownika tworzącego głosowanie mógłby:

• wygenerować klucz publiczny oraz prywatny,
• wysłać do aplikacji klucz publiczny,
• aplikacja szyfrowałaby wszystkie wyniki głosowań tym kluczem publicznym,
• kończąc głosowanie, użytkownik je tworzący wysłałby do aplikacji klucz prywatny (dotychczas trzymany np. wyłącznie w local storage przeglądarki), co pozwoliłoby na odkodowanie rezultatów.

... ale to nie zabezpiecza przed atakiem MITM, w którym aplikacja odbierając klucz publiczny po prostu podmienia go na jakiś statyczny, który tylko ona zna, i szyfruje wszystko tym znanym kluczem

(albo nie szyfruje w ogóle, bo atakujący mógłby równie dobrze wyciąć tę funkcjonalność i napisać aplikację, która jedynie udaje, że coś szyfruje.)

Wydaje mi się, że jedynym podejściem fully-trustless byłaby sytuacja, w której użytkownik tworzący głosowanie generuje klucz publiczny oraz prywatny, a następnie zaufanym kanałem wysyła klucz publiczny do osób głosujących (tak, że ten klucz nie przechodzi przez niezaufaną aplikację); ale to wymaga ustanowienia wcześniej takiego zaufanego kanału, więc w gruncie rzeczy jedynie przerzuca odpowiedzialność dokądś indziej.

Nie wiem jaka głębsza historia za tym stoi. Ale generalnie to możesz sobie zapisać hash klucza użytego przez użytkownika, coś jak zwykle hasło do logowania.
Potem przy próbie odszyfrowania treści sprawdzać czy hasło podane przez użytkownika odpowiada hashowi i jeśli tak zdekodować treść.

Kiedyś robiłem mały system do głosowania. Tak naprawdę musisz zaufać, że ktoś kto ma dostęp nie będzie wpływał na wyniki. Przecież tak zawsze można wykasować wiersz, zmienić jego zawartość, podmienić jego zawartość przy zapisie, czy zalogować do pliku jak pisał @Patryk27 .

co17rey napisał(a):

Jak byście to rozwiązali?

Nie specjalnie da się to wykonać, bo nawet najlepiej zakodowane/zaszyfrowane dane prędzej czy później będziesz musiał odkodować, żeby pokazać użytkownikowi. A skoro tak, to admin takiego serwisu mógłby się podpiąć pod ten element i po prostu odczytać wszystkie głosy jakie chcesz.

Jedyne co mógłbyś zrobić, to wysłać użytkownikowi dane podpisane kluczem asymetrycznym, żeby sobie rozkodował to u siebie, ale wtedy ciężko byłoby to nazwać stroną internetową. Nie mógłbyś nawet udostępnić JS'a który by to rozkodował po stronie frontu, bo admin mógłby wtedy tez podpiąć się pod to i odczytać klucz.

Więc ja bym zrobił krok wstecz, i zapytał - co dokładnie chcesz uzyskać, jaki problem próbujesz rozwiązać?

Dosyć pogmatwany use-case prezentujesz. Duże firmy dostarczające soft dla baz danych (ale też opensource'y) raczej skupiają się na data at rest encryption - czyli szyfrowaniu danych, które nie są na bieżąco wykorzystywane (najczęściej chodzi o wymagania compliance). Reszta to zabezpieczenie proceduralne, ale tak czy inaczej ktoś gdzieś będzie miał dostęp do tych danych. Może rozwiązaniem jest samo podpisywanie danych, tak aby mieć pewność, że nie zostały zmienione przez inną osobę niż ta, która dane wprowadzała? Tutaj to już temat w miarę ograny - podpisywanie z wykorzystaniem kryptografii klucza publicznego, przykład opisany chociażby tutaj: https://dev.mysql.com/blog-archive/protecting-data-with-digital-signatures-by-example-using-mysql-enterprise-edition/

jurek1980 napisał(a):

Nie wiem jaka głębsza historia za tym stoi.

brzezmac napisał(a):

Dosyć pogmatwany use-case prezentujesz.

Dla mnie też niejasne.

Zależnie od odczytania,
a) albo "atomem" danych jest jeden głos, można go zaszyfrować wg klucza publicznego odbiorcy, ale tu jest o wiele, wiele większy problem: skasowanie wiersza, dołożenie innego (klucz publiczny jest jawny). (a na poziomie procedur demokratycznych tak je rozumiemy w realu nie jest to w pełni tajne głosowanie, bo pojedynczy głos poddaje się analizie)
b) albo daną jest suma głosów - jednokierunkowe zaszyfrowanie tu nie jest przydatne.

Patryk27 napisał(a):

imo jeśli rozważasz scenariusz, w którym to nawet administrator serwera może coś nabruździć, to nie da się zrobić za wiele

Nawet zrobić backup bazy przed większą falą głosów, podnieść z backupu etc...
A prawo backupu jest zwykle o wiele rozleglejsze, niż autoryzacje do czynności w apliakcji

@co17rey:

Może doprecyzuj, czego bronisz. Tajnosci pojedycznego głosu, tajemnicy wyniku przed finałem (cisza wyborcza), integralności głosowania i nienaruszlaności. Na razie sypiesz o pomysłach technicznych, a nie celach.

Bo każde z tych zagadnień jest nieco innym (a ich zgrupowanie jest szczególnie trudnym)

Łeeee to w sumie prosta sprawa ale jak @ZrobieDobrze pyta, doprecyzuj czy nie chcesz znac uzytkownika ktory oddal glos, czy nie chcesz zeby administrator mogl oddany glos zmienic? bo jesli ma nikt nie widziec zakodowanego wyniku to po co ci glosowanie? Ja kiedys zrobilem taka palikacje ze wlasnie nie da sie zmienic danych. to bylo dosc dwno ale proste jak drut

Generalnie po przeczytaniu Waszych postów wymyśliłem coś takiego. Generuję parę kluczy, prywatny i publiczny. Przy tworzeniu głosowania generuję te klucze, klucz prywatny wysyłam do użytkownika w formie pliku. Klucz publiczny przechowuję w bazie danych. Przy oddaniu głosu koduję głos kluczem publicznym i w formie nie jawnej przechowuję również w bazie. Po zakończeniu głosowania twórca głosowania wysyła klucz prywatny do skryptu i ujawnia wyniki.

W takim rozwiązaniu czy to administrator bazy czy to administrator serwera nie będzie w stanie podejrzeć wyników głosowania.

Administrator serwera może np. podmienić aplikację na taką, która zawsze generuje znany uprzednio atakującemu klucz publiczny oraz prywatny; ew. może nasłuchiwać na ruchu sieciowym (w szczególności jeśli wykorzystujesz ssl termination) i stamtąd wyciągać generowane na bieżąco klucze.

Patryk27 napisał(a):

Administrator serwera może np. podmienić aplikację na taką, która zawsze generuje znany uprzednio atakującemu klucz publiczny oraz prywatny; ew. może nasłuchiwać na ruchu sieciowym (w szczególności jeśli wykorzystujesz ssl termination) i stamtąd wyciągać generowane na bieżąco klucze.

To prawda, admin webowy podmienić może, ale osoba która dodała głosowanie klucz prywatny ma swoim komputerze. Głosy są kodowane publicznym przy każdym głosie, więc jak podmieni klucze to dodający głosowanie później przy odtajnianiu wyników wyborów nie odkoduje, co będzie równe z ingerencją w dane. A klucz prywatny tak naprawdę jest użyty tylko dwa razy, raz podczas tworzenia wyborów, czyli admin webowy jeszcze nie wie, że może coś podsłuchać, a drugi raz podczas dekodowania wyników, gdzie już wyniki mogą być znane i jawne, także nie mam obaw co do nasłuchiwania.

Korzystam z OpenSSL, jeśli to ma jakieś znaczenie.

ale osoba która dodała głosowanie klucz prywatny ma swoim komputerze

Początkowo napisałeś, że to aplikacja generuje parę kluczy (Przy tworzeniu głosowania generuję te klucze, klucz prywatny wysyłam do użytkownika w formie pliku.), stąd moja sugestia.

Głosy są kodowane publicznym przy każdym głosie, więc jak podmieni klucze to dodający głosowanie później przy odtajnianiu wyników wyborów nie odkoduje, co będzie równe z ingerencją w dane

Skoro to założyciel głosowania tworzy parę kluczy, pozostaje problem bezpiecznego transportu tego klucza publicznego do głosujących (kwestia zaufanego kanału wzmiankowana przeze mnie na samym początku).

Tzn. co stoi na przeszkodzie, aby bazodanowiec / sysadmin zrobili sztuczkę w wyniku której założyciel głosowania wygeneruje klucz publiczny X, wyśle ten klucz do aplikacji, a następne aplikacja do głosujących wyśle klucz Y (znany atakującym)? (tj. skąd głosujący będą wiedzieli, że klucz publiczny, którym podpisują dane, został rzeczywiście wygenerowany przez założyciela głosowania)

To co chcesz zrobic nie ma sensu najprosciej to oddajac glosowanie mozesz zrobic ze generujesz pare kluczy prywatny i publiczny po stronie uzytkownika . frontendowy skrypt i podczas oddania glosowana wrzucasz jako token do blockchaina wraz z oddanym glosem, id uzytkownika i kluczem publicznym. Wtedy masz id transakcji ktory wrzucasz do bazy i masz potwierdzenie dowod ktorego nie da sie oszukac.
Jesli chcesz poprosic uzytkownikow o proces weryfikacji glosu, bierzesz klucz publiczny kazdego kto oddal glos i kodujesz zapytanie np generujesz znaki: dla kazdego inne np 5654 itd , uzytkownik odkodowuje po froncie ten ciag i jak odesle taki sam uznajesz ze dane glosowanie jest prawidlowe. Adminitrsator nie moze nic ingerowac bo wszystko jest w blockchain i ma tylko ID transakcji, najwyzej moze skasowac ale to sie rowna z wywaleniem go z pracy itd. a baza i tak powinna mic backapy.

Inaczej masz prblem z transportowaniem klucza prywatnego za kazdym razem gdy wygenerowalbys go loklanie u siebie na serwerze

co17rey napisał(a):

Generalnie po przeczytaniu Waszych postów wymyśliłem coś takiego. Generuję parę kluczy, prywatny i publiczny. Przy tworzeniu głosowania generuję te klucze, klucz prywatny wysyłam do użytkownika w formie pliku. Klucz publiczny przechowuję w bazie danych. Przy oddaniu głosu koduję głos kluczem publicznym i w formie nie jawnej przechowuję również w bazie. Po zakończeniu głosowania twórca głosowania wysyła klucz prywatny do skryptu i ujawnia wyniki.

W takim rozwiązaniu czy to administrator bazy czy to administrator serwera nie będzie w stanie podejrzeć wyników głosowania.

Widzę, że bez udzielenia SOBIE i nam odpowiedzi co jest celem, proponujesz implementację.
Podejrzec nie bedzie mógł, ale skasuje / wstawi takie wyniki głosowania, jakie sobie wymyśli.

Jesli TYLKO to jest twoim problemem, co pośrednio z postu wynika, nie moja sprawa. Ale moim zdaniem wymyślone mniejszościowe zagrożenie wyniesione na najwazniejsze (jedyne)

Patryk27 napisał(a):

ale osoba która dodała głosowanie klucz prywatny ma swoim komputerze

Początkowo napisałeś, że to aplikacja generuje parę kluczy (Przy tworzeniu głosowania generuję te klucze, klucz prywatny wysyłam do użytkownika w formie pliku.), stąd moja sugestia.

Głosy są kodowane publicznym przy każdym głosie, więc jak podmieni klucze to dodający głosowanie później przy odtajnianiu wyników wyborów nie odkoduje, co będzie równe z ingerencją w dane

Skoro to założyciel głosowania tworzy parę kluczy, pozostaje problem bezpiecznego transportu tego klucza publicznego do głosujących (kwestia zaufanego kanału wzmiankowana przeze mnie na samym początku).

Tzn. co stoi na przeszkodzie, aby bazodanowiec / sysadmin zrobili sztuczkę w wyniku której założyciel głosowania wygeneruje klucz publiczny X, wyśle ten klucz do aplikacji, a następne aplikacja do głosujących wyśle klucz Y (znany atakującym)? (tj. skąd głosujący będą wiedzieli, że klucz publiczny, którym podpisują dane, został rzeczywiście wygenerowany przez założyciela głosowania)

Czyli najlepiej by było sprawdzać przy oddaniu każdego głosu czy dany klucz publiczny przechowywany w bazie danych w pozycji głosowania pasuje do klucza prywatnego głosowania, ale wtedy musiałbym przechowywać go na serwerze. Więc na ten moment głosujący oddaje głos i tyle. W gestii twórcy jest zapewnienie odpowiedniej infrastruktury, żeby przez FTP nikt się nie dostał i nie podmienił appki i nie miał dostępu do bazy danych.

W aktualnej wersji, jeśli twórca głosowania nie będzie mógł odkodować wyników to będzie znaczyło, że było grzebane w bazie. Takie założenie mi wystarczy w aplikacji.

ZrobieDobrze napisał(a):

co17rey napisał(a):

Generalnie po przeczytaniu Waszych postów wymyśliłem coś takiego. Generuję parę kluczy, prywatny i publiczny. Przy tworzeniu głosowania generuję te klucze, klucz prywatny wysyłam do użytkownika w formie pliku. Klucz publiczny przechowuję w bazie danych. Przy oddaniu głosu koduję głos kluczem publicznym i w formie nie jawnej przechowuję również w bazie. Po zakończeniu głosowania twórca głosowania wysyła klucz prywatny do skryptu i ujawnia wyniki.

W takim rozwiązaniu czy to administrator bazy czy to administrator serwera nie będzie w stanie podejrzeć wyników głosowania.

Widzę, że bez udzielenia SOBIE i nam odpowiedzi co jest celem, proponujesz implementację.
Podejrzec nie bedzie mógł, ale skasuje / wstawi takie wyniki głosowania, jakie sobie wymyśli.

Jesli TYLKO to jest twoim problemem, co pośrednio z postu wynika, nie moja sprawa. Ale moim zdaniem wymyślone mniejszościowe zagrożenie wyniesione na najwazniejsze (jedyne)

Generalnie założenie jest takie, żeby admin bazy danych, admin serwerowy, autor aplikacji nie mógł podejrzeć wyników wyborów w trakcie głosowania.

Po głosowaniu wszystko będzie jawne.

W gestii twórcy jest zapewnienie odpowiedniej infrastruktury, żeby przez FTP nikt się nie dostał i nie podmienił appki i nie miał dostępu do bazy danych.

Otóż to; ale w takiej sytuacji w ogóle zabawa w jakieś klucze prywatne oraz publicznie nie ma sensu, bo w obydwu sytuacjach (zapisywaniu głosów tak po-prostu-do-bazy oraz zapisywaniu głosów zaszyfrowanych RSA) bezpieczeństwo wynika wyłącznie z tego, że nikt nie ma wjazdu do aplikacji -- dodatkowe szyfrowanie tutaj nie daje żadnego ekstra bezpieczeństwa, chyba że celujesz w security by obscurity.

Nie, chodzi o to, żeby:
admin bazodanowy mając dostęp tylko do bazy nie mógł podejrzeć wyników w trakcie głosowania
admin webowy nie mógł podejrzeć wyników w trakcie głosowania
twórca głosowania mając dostęp tylko do panelu nie mógł podejrzeć wyników w trakcie głosowania

Kim w tym scenariuszu jest admin webowy i jakie ma dostępy?

Administrator hostingu. Taki normalny człowiek bez złych zamiarów.

co17rey napisał(a):

Administrator hostingu. Taki normalny człowiek bez złych zamiarów.

Generalnie wszyscy sa dobrymi ludźmi bez złych zamiarów - więc po co ten wątek.

Nie ma takiej opcji by nie widziec wynikow czasie glosowania, sadzac po twojej wypowiedzie typu FTP. Tu nie ma co dalej rozkminiac bo jestes w tyle za najnowszymi technologiami o lata swietlne

chomikowski napisał(a):

Nie ma takiej opcji by nie widziec wynikow czasie glosowania, sadzac po twojej wypowiedzie typu FTP. Tu nie ma co dalej rozkminiac bo jestes w tyle za najnowszymi technologiami o lata swietlne

Jak to nie ma? Mając dostęp do FTP, pobierze sobie dane z bazy. I co z tego, że będzie miał zakodowany ciąg znaków, jak bez klucza prywatnego go nie odkoduje? To skąd będzie wiedział jaki to głos?

co17rey napisał(a):

Administrator hostingu. Taki normalny człowiek bez złych zamiarów.

Może w takim razie pomiń bazę danych i odpowiedzi zrzucaj do pliku na hostingu, plain-text?

Zdaję sobie sprawę, że to brzmi trochę jak trolling, ale skoro jedynym zaufanym ogniwem jest właściciel hostingu (a wszyscy inni są potencjalnymi adwersarzami), no to jest to jedyne logiczne wyjście.

Brakuje mi fachowego słownictwa infosec, ale problemem tutaj jest fakt, że nie potrafisz określić przed czym tak naprawdę chcesz się bronić:

• jeśli przed bazodanowcem (ale hostingowiec jest zaufany), to zrzucaj dane do pliku na hostingu,
• jeśli przed hostingowcem, to podpisz z nim umowę (aby legalny aspekt przerzucić częściowo na jego stronę) albo wykorzystaj podejście trust-less w stylu "każdy głosujący ma własny yubikey oraz ekstra zaufany kanał komunikacyjny" (z tym że to wymaga głosujących, którzy są w miarę ogarnięci technicznie).

co17rey napisał(a):

Nie, chodzi o to, żeby:
admin bazodanowy mając dostęp tylko do bazy nie mógł podejrzeć wyników w trakcie głosowania

Bez sensu... Musi być KTOŚ, kto będzie miał dostęp do tych informacji chociażby po to, żeby te głosowanie móc zdekodować. Skoro zliczać będzie sobie skrypt (napisany przez osobę) to równie dobrze może być to też i admin.

admin webowy nie mógł podejrzeć wyników w trakcie głosowania

To akurat jest proste do zrobienia - blokujesz widok, który pozwala na przeglądanie wyników (ewentualnie dekodowanie)

twórca głosowania mając dostęp tylko do panelu nie mógł podejrzeć wyników w trakcie głosowania

To również - jw.

Reasumując, nie wiem po co chcesz to tak "utrudniać". Zakładając, że mamy pytanie z odpowiedziami TAK/NIE i te wartości są zakodowane z użyciem kluczy prywatnych. Teraz tak, żeby podliczyć to głosowanie musisz te odpowiedzi "zdekodować" i je policzyć. I teraz, co stoi na przeszkodzie, aby admin hostingu nie wszedł sobie w skrypt i sam sobie tych rzeczy nie zdekodował?

leonpro778 napisał(a):

co17rey napisał(a):

Nie, chodzi o to, żeby:
admin bazodanowy mając dostęp tylko do bazy nie mógł podejrzeć wyników w trakcie głosowania

Bez sensu... Musi być KTOŚ, kto będzie miał dostęp do tych informacji chociażby po to, żeby te głosowanie móc zdekodować. Skoro zliczać będzie sobie skrypt (napisany przez osobę) to równie dobrze może być to też i admin.

admin webowy nie mógł podejrzeć wyników w trakcie głosowania

To akurat jest proste do zrobienia - blokujesz widok, który pozwala na przeglądanie wyników (ewentualnie dekodowanie)

twórca głosowania mając dostęp tylko do panelu nie mógł podejrzeć wyników w trakcie głosowania

To również - jw.

Reasumując, nie wiem po co chcesz to tak "utrudniać". Zakładając, że mamy pytanie z odpowiedziami TAK/NIE i te wartości są zakodowane z użyciem kluczy prywatnych. Teraz tak, żeby podliczyć to głosowanie musisz te odpowiedzi "zdekodować" i je policzyć. I teraz, co stoi na przeszkodzie, aby admin hostingu nie wszedł sobie w skrypt i sam sobie tych rzeczy nie zdekodował?

Admin hostingu nie zdekoduje bo nie ma klucza prywatnego. Klucz prywatny ma twórca głosowania u siebie na komputerze.

Może sobie zsumować, ale nie wie który hash jest odpowiedzialny za którą odpowiedź. Klucz prywatny jest przy każdym głosowaniu inny.

To ja mam pytanie.

Jesli każdy głosujący ma osobny klucz prywatny, to jak potem sumarycznie pokazać te głosy? No bo skoro jest głosowanie to chcesz chyba jakoś potem pokazać sumę tych głosów?