Wątek: Szyfrowanie wiadomości - pomysł do rozpatrzenia

Strona: 1 z 1

1 z 5: pajper

Troszkę nad tym myślałem. Najłatwiej byłoby stworzyć coś w rodzaju PGP, w którym użytkownicy generują klucze asymetryczne podczas rejestracji i tak wiadomości są szyfrowane. Na drodze stoją jednak dwa spore problemy praktyczne:
1. Wymagałoby to używanie klucza przy każdym logowaniu, jakiegoś sposobu na jego skopiowanie podczas logowania na stronie, mobilkach.
2. Uniemożliwiałoby odzyskanie konta na wypadek jego zgubienia.

Trzeba tu wyjść z założenia, że w portalu jak Elten bezpieczeństwo jest bardzo ważne, ale nie może być implementowane kosztem używalności dla mniej technicznych użytkowników, bo Ci bardziej techniczni i tak znajdą sobie Signala czy inny protokół End-To-End Encrypted.
Z drugiej strony szyfrowanie wiadomości z jednoczesnym trzymaniem klucza w bazie danych ma sens porównywalny z trzymaniem klucza do domu pod wycieraczką.
Tak kombinowałem, kombinowałem i coś wymyśliłem. To, co proponuję, to właściwie szyfrowanie End-To-End, ale z pewną celową luką.


1. Dla każdego użytkownika wygenerowana zostanie para kluczy: publiczny, prywatny.
2. Każda wiadomość zostanie zaszyfrowana symetrycznym kluczem AES, który zostanie podwójnie zaszyfrowany kluczami nadawcy i odbiorcy.
Szyfrowanie odbywać się będzie lokalnie, serwer nigdy nie otrzyma tekstu jawnego.
3. Przy odczycie wiadomości, serwer przekaże szyfrogram oraz zaszyfrowany klucz. Użytkownik najpierw odszyfruje klucz swoim kluczem prywatnym, a potem uzyskanym wynikiem szyfrogram.

Powyższe jest standardową procedurą End-To-End. Różnica będzie jednak taka, że klucze prywatne będą... gdzieś zapisywane.
W miejscu, które podczas logowania umożliwi ich odczyt, ale tylko po pozytywnym zweryfikowaniu użytkownika. Co jeszcze ważniejsze, odczyt tyc kluczy będzie wymagał potwierdzenia 2FA, przez co będzie wiadomo o każdorazowym ich odczytu.
Usługa przechowująca klucze nie będzie w żaden sposób osiągalna przez serwer HTTP prócz oficjalnego gniazda.
Jak to zrobić? Najlepiej na osobnym serwerze, ale na to nas nie stać.
Tak więc odpowiedź brzmi: jeszcze nie wiem, ale pomyślę. :)
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
24.10.2019 16:15

2 z 5: papierek

hm, a ewentualne monitorowanie odczytywania kluczy prywatnych, ktore teoretycznie można przejąć?
po co mi sygnatura?
24.10.2019 16:16

3 z 5: pajper

Wyjaśnisz?
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
24.10.2019 16:19

4 z 5: papierek

teoretycznie klucze zapisane na serwerze można przejąć.
po co mi sygnatura?
24.10.2019 16:25

5 z 5: pajper

Tak, dokładnie. I to jest spora wada rozwiązania.
Można jednak zminimalizować to ryzyko, ustawiając uprawnienia. Teoretycznie, jeśli założyć dla nich osobnego użytkownika Unixowego, nie istnieje podatność serwera HTTP, która pozwoliłaby je zdobyć, ponieważ serwer HTTP nie może ich zdobyć.
Innymi słowy wymagałoby to przejęcia konta Roota, co nie wynika z zabezpieczeń portalu, a zabezpieczeń SSH.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
24.10.2019 16:27