Jak chronić swoją grę za pomocą klucza CD / numeru seryjnego?


25

Zdecydowałem więc, że chcę powstrzymać pirackie kopie mojej gry XNA przed dostępem do oficjalnych serwerów gier (które są moderowane, aby ludzie, którzy zapłacili za grę, uzyskali najlepsze wrażenia) poprzez odłączanie klientów z niewłaściwą lub wygenerowaną, zduplikowaną lub zbanowaną płytą CD klucze (lub numery seryjne, ponieważ gra jest cyfrowa i nie ma żadnych płyt CD).

Jak mogę wprowadzić ten system ochrony numerów seryjnych do mojej gry (zarówno klientów, jak i głównego serwera uwierzytelniającego), aby nie można go łatwo zhakować?


Pamiętaj, że nie mam doświadczenia w tworzeniu dobrej ochrony tego rodzaju oprogramowania.

Nigdy wcześniej tego nie robiłem, ale rozumiem podstawy. Rozumiem, dlaczego nie mogę przeprowadzać kontroli klucza na kliencie, więc w porządku jest dla mnie używanie uwierzytelnienia logowania / przekazania z jednorazowym wprowadzeniem klucza.

Obecnie celem tej ochrony jest utrzymanie potencjalnych oszustów i zakłócanie zachowania graczy poza oficjalnymi serwerami. Każdy może grać na prywatnych serwerach z kluczem lub bez niego, ale szansa na uzyskanie niepożądanego doświadczenia z innymi graczami jest większa. Sądzę, że kupowanie graczy jest dość łatwe, ponieważ muszą być online, aby grać na oficjalnych serwerach.

Ponieważ włamanie się do klienta jest zbyt łatwe, zamierzam chronić tylko procedury początkowej rejestracji (i ewentualnie uwierzytelnienia po stronie serwera), aby nikt nie mógł ukraść kluczy podczas ich przesyłania.


Zobacz też:

Jak gry wieloosobowe powinny obsługiwać uwierzytelnianie?


Jeśli ktoś głosuje negatywnie, oczekuję przynajmniej komentarza na temat tego, co jest nie tak z pytaniem. Chłopaki, naprawdę chcę, aby moje pytanie było dobre i pomogło większej liczbie osób niż tylko mnie.
user1306322

4
Domyślam się, że była to automatyczna reakcja na dodanie DRM. Ten typ nie jest szczególnie zły, ale wielu z nas ma z nim złe doświadczenia - na przykład gdy Spore zamurował moją instalację systemu Windows.
Izkata,

Czy zamiast klucza CD rozważałeś podejście podobne do MMO / Minecraft polegające na wymaganiu nazwy użytkownika / hasła do logowania i używania go do uwierzytelniania użytkowników?
Tetrad

4
Chcesz DRM w aplikacji .NET !? To się ostatecznie nie powiedzie dzięki narzędziom takim jak Reflector. Spójrz na Terraria. Rozwój został zatrzymany z powodu piractwa (i dużego dochodu ...). Podoba mi się pomysł oparty na uwierzytelnianiu @ Tetrad, ponieważ uniemożliwia on po prostu łatanie funkcji sprawdzania poprawności. Zachowaj wszystkie dane na swoim serwerze, a gdy logowanie się powiedzie, podaj im swoje dane. Jeśli przechowujesz dane lokalnie, mogą one po prostu załatać funkcję uwierzytelniania.

2
@Anko, który był odniesieniem do słynnego cytatu „Potrzebujemy więcej minerałów” . Mam na myśli fakty i wiedzę specjalistyczną. Może nawet szczegóły. Nie wiedziałbym, kiedy ważny problem miał wystarczająco dużo uwagi, po prostu czułem, że jest coś do dodania, a odwiedzający stronę mogą uznać ten temat za interesujący (i być może nowi użytkownicy), więc podniosłem nagrodę.
user1306322

Odpowiedzi:


24

Zasadniczo masz trzy wymagania:

  1. użycie tego samego klucza dla wielu instancji klienta nie powinno być łatwe,
  2. generowanie nowych ważnych kluczy nie powinno być łatwe, oraz
  3. 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ń).


2
Jedna drobna uwaga - podczas gdy całkowicie losowy klucz zapewnia maksymalną przestrzeń klawiszy (i jest doskonale wykonalny, jeśli sprawdzasz poprawność w bazie danych wydanych kluczy), nie jest przyjazny dla użytkownika. Włóż trochę sprawdzania poprawności do samego klucza, aby uchwycić większość pomyłek, zanim spróbujesz trafić na serwer.
Loren Pechtel

Wydaje mi się, że @LorenPechtel ma mocną stronę w kwestii łatwości obsługi klucza, a płatny użytkownik przypadkowo pisze i wysyła do serwera klucz „niepoprawnie wpisany / błędny w pisowni” (literówka).
Wisznu

@ Visnu Wiem jako użytkownik, który wpisuje klucze, wolałbym mieć jakieś informacje kontrolne na grupę, nawet jeśli oznaczałoby to wpisanie dłuższego klucza.
Loren Pechtel

16

Nie ma stuprocentowego wytrawności, ale możesz zacząć od dość prostego podejścia:

  • Będziesz potrzebował jakiegoś sposobu weryfikacji wygenerowanych kluczy, na przykład uwzględnionych sum kontrolnych. Oczywiście nie może być zbyt łatwo to rozgryźć.

  • Opcjonalnie (ale zalecane) istniałaby baza danych po stronie serwera weryfikująca klucze z bazą danych wszystkich wydanych kluczy, abyś nie mógł wygenerować kluczy, nawet jeśli zdarzy ci się mieć algorytm (zignorujmy go brutalnie).

Odtąd możesz mieć dwa różne podejścia, ale w obu przypadkach coś jest bardzo ważne:

  • Nie weryfikuj klucza po stronie klienta. Jest to bardzo ważne, ponieważ w rzeczywistości dość łatwo jest dekompilować pliki napisane w .net / XNA. Jeśli musisz poprosić o klucz lub przekazać go (login lub rejestracja), hash klucz (z dodatkiem soli itp.) I wyślij go na serwer.

Jeśli chodzi o rzeczywiste ścieżki:

  • Wymagaj, aby klucz skrótu (patrz powyżej) był wysyłany podczas procedury uwierzytelniania / logowania.

  • Alternatywnie (IMO jest lepszy, chociaż wielu nie lubi tego rodzaju „DRM”): Nie używaj klucza w kliencie. Zamiast tego należy zalogować się na konto i wymagać prawidłowego klucza CD (wymaga to wspomnianej wyżej bazy danych), aby utworzyć konta. W ten sposób radzą sobie z tym nowoczesne gry, np. Dowolna MMORPG typu pay-to-play.

Osobiście wybrałbym podejście do konta z prostego powodu: W końcu nie możesz powstrzymać ludzi przed kradzieżą kluczy CD (brutalizacja, inżynieria wsteczna lub oszustwo). W związku z tym Ludzie mogą po prostu utworzyć nowy klucz, aby kontynuować grę lub zablokować inne osoby w grze. Dzięki kluczom powiązanym z kontem nikt nie jest w stanie nic zrobić z kluczem, który jest już w użyciu. W przypadku, gdy ktoś kupił klucz wygenerowany przez kogoś innego, nadal możesz przenieść własność konta, zakładając, że istnieje na to wystarczający dowód.


2
Zamiast standardowych sum kontrolnych powinieneś użyć kryptograficznie bezpiecznego algorytmu mieszającego. Możesz zatrzymać klucz prywatny na serwerze i dać klientowi klucz publiczny, a wtedy wiesz, że bez dostępu do serwera system jest bezpieczny.
Adam,

@Adam: Użycie bezpiecznego algorytmu mieszającego kryptograficznego zapewni, że atakujący nie będą mogli wygenerować prawidłowych kluczy, ale problem jest równie nierozwiązywalny przez organ odpowiedzialny za wydawanie legalnych kluczy. Chociaż w rzeczywistości prosta suma kontrolna nie jest zbyt bezpieczna, funkcje jednokierunkowe nie są wykonalne w tym kontekście.
Marcks Thomas

Cóż, możesz połączyć oba, np. Czyniąc pierwszą część klucza losową kombinacją znaków i drugą połowę skrótu. Każdy, kto sprzedaje grę, nie może i tak użyć klucza (chyba że istnieje jakiś sposób, aby zapobiec kolizjom / konfliktom, np. „Identyfikator dostawcy” jako część klucza).
Mario,

1

Pangea Software - twórca kilku gier komputerowych na komputery Mac - napisał temat na temat ochrony przed kopiowaniem w (obecnie darmowej) książce do tworzenia gier. Książka wyjaśnia również, jak radzić sobie z pirackimi kluczami i innymi hackami, z których korzystają ludzie. Książka koncentruje się na rozwoju gier na komputery Mac, ale pomysły mogą być przydatne na innych platformach. Do książki dołączony jest kod źródłowy każdego rozdziału, część do pobrania poniżej. Zawiera również kod źródłowy (napisany w C) związany z ochroną przed kopiowaniem.

Książkę można pobrać tutaj .


W tych książkach nie mogłem znaleźć niczego przydatnego.
user1306322

Osobiście myślałem, że rozdział 16 miał kilka fajnych wskazówek, ale YMMV.
Wolfgang Schreurs,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.