Zasadniczo masz trzy wymagania:
- użycie tego samego klucza dla wielu instancji klienta nie powinno być łatwe,
- generowanie nowych ważnych kluczy nie powinno być łatwe, oraz
- nie powinno być łatwo ukraść klucza legalnego klienta.
Pierwsza część powinna być dość prosta: po prostu nie pozwól dwóm graczom zalogować się na tym samym serwerze za pomocą tego samego klucza w tym samym czasie. Możesz również poprosić serwery o wymianę informacji o zalogowanych użytkownikach lub skontaktowanie się z udostępnionym serwerem uwierzytelniania, aby nawet użycie tego samego klucza dla różnych graczy na różnych serwerach w tym samym czasie zakończyło się niepowodzeniem. Prawdopodobnie zechcesz także poszukać podejrzanych wzorców użycia klucza, a jeśli stwierdzisz, że klucz został wyciekł, dodaj go do listy zablokowanych kluczy.
W drugiej części jednym ze sposobów jest po prostu utrzymanie bazy danych wszystkich ważnych wydanych kluczy. Tak długo, jak klucze są wystarczająco długie (powiedzmy 128 bitów lub więcej) i wybrane losowo (przy użyciu bezpiecznego RNG), szanse każdego, kto zdoła odgadnąć ważny klucz, są zasadniczo zerowe. (Nawet znacznie krótsze klucze mogą być bezpieczne, jeśli użyjesz pewnego rodzaju ograniczenia prędkości w przypadku nieudanych prób logowania, aby zatrzymać próby znalezienia prawidłowych kluczy siłą.)
Alternatywnie możesz wygenerować klucze, biorąc dowolny unikalny identyfikator i dodając do niego kod uwierzytelniający wiadomość (taki jak HMAC ), obliczony przy użyciu tajnego klucza głównego. Ponownie, o ile MAC jest wystarczająco długi, szanse każdego, kto nie wie, że klucz główny jest w stanie odgadnąć prawidłowy MAC dla dowolnego identyfikatora, są znikome. Jedną z zalet tej metody, oprócz wyeliminowania potrzeby posiadania bazy danych kluczy, jest to, że identyfikator może być dowolnym unikalnym ciągiem i może kodować informacje o kliencie, dla którego klucz został wydany.
Jednym z problemów związanych z używaniem adresów MAC jest to, że oficjalne serwery gier (lub przynajmniej serwer uwierzytelniający) muszą znać klucz główny w celu weryfikacji adresu MAC, co oznacza, że w przypadku włamania do serwerów klucz główny może zostać wyciekły. Jednym ze sposobów zmniejszenia tego ryzyka może być obliczenie kilku adresów MAC dla każdego identyfikatora przy użyciu różnych kluczy głównych, ale przechowywanie tylko jednego klucza głównego na serwerach gry. W ten sposób, jeśli ten klucz główny zostanie kiedykolwiek wyciekły i użyty do wygenerowania fałszywych identyfikatorów, możesz go odwołać i przełączyć na inny klucz główny. Alternatywnie można zastąpić adresy MAC podpisami cyfrowymi , które można zweryfikować przy użyciu tylko publicznej połowy klucza głównego.
W przypadku trzeciej części jednym podejściem jest upewnienie się, że klient nie wyśle nikomu swojego klucza bez sprawdzenia, czy odbiorca jest rzeczywiście oficjalnym serwerem. Na przykład możesz użyć protokołu SSL / TLS (lub DTLS ) do procesu logowania, wydawać niestandardowe certyfikaty dla serwerów gier i wystawiać tylko certyfikaty zaufania klienta. Dogodnie, korzystanie z TLS chroni również klucze klienta (i wszelkie inne dane uwierzytelniające) przed podsłuchującymi, np. W publicznych sieciach WLAN.
Niestety takie podejście nie pozwala serwerom zewnętrznym weryfikować kluczy klienta, nawet jeśli chcą. Można obejść ten problem, konfigurując oficjalny serwer uwierzytelniania, z którego mogą korzystać serwery gier innych firm, np. Logując klienta do serwera uwierzytelniania i otrzymując losowy jednorazowy token, którego mogą użyć do zalogowania się do serwer gry (który następnie przesyła token do serwera uwierzytelniającego, aby go zweryfikować).
Alternatywnie możesz wydawać swoim klientom rzeczywiste certyfikaty klientów lub coś w tym rodzaju. Możesz użyć istniejącego protokołu (takiego jak TLS), który obsługuje uwierzytelnianie certyfikatu klienta (zalecane) lub zaimplementować własny, np .:
- Certyfikat klienta składa się z dowolnego ciągu identyfikatora, pary klucza publicznego / prywatnego oraz podpisu cyfrowego identyfikatora i klucza publicznego za pomocą klucza głównego.
- Aby się zalogować, klient wysyła swój identyfikator, klucz publiczny i podpis. Serwer odpowiada unikalnym ciągiem wyzwania (najlepiej zawierającym identyfikator serwera i znacznik czasu, które klient powinien zweryfikować), które klient podpisuje kluczem prywatnym (aby udowodnić, że zna klucz) i wysyła podpis na serwer.
- Serwer sprawdza oba podpisy, udowadniając, że klucz publiczny ID + tworzy prawidłowy klucz klienta (ponieważ zostały podpisane kluczem głównym) i że klucz klienta faktycznie należy do klienta (ponieważ klient mógł podpisać wyzwanie serwera prywatnym klawisz).
(Protokół ten można dodatkowo uprościć, jeśli klient wygeneruje „wyzwanie”, składające się z identyfikatora serwera i znacznika czasu oraz podpisuje je. Oczywiście serwer musi sprawdzić, czy identyfikator i znacznik czasu są prawidłowe. Należy również pamiętać, że ten prosty protokół sam w sobie nie powstrzyma pośrednika przed przejęciem sesji klienta, chociaż uniemożliwi mu uzyskanie prywatnego klucza klienta potrzebnego do przyszłych logowań).