Jak wygenerować i zweryfikować klucz licencyjny oprogramowania?

Obecnie jestem zaangażowany w opracowywanie produktu (opracowanego w języku C #), który będzie dostępny do pobrania i zainstalowania za darmo, ale w bardzo ograniczonej wersji. Aby uzyskać dostęp do wszystkich funkcji, użytkownik musi uiścić opłatę licencyjną i otrzymać klucz. Ten klucz zostanie następnie wprowadzony do aplikacji w celu „odblokowania” pełnej wersji.

Ponieważ używanie takiego klucza licencyjnego jest czymś zwyczajnym, zastanawiam się:

1. Jak to zwykle rozwiązuje się?
2. Jak mogę wygenerować klucz i jak można go zweryfikować w aplikacji?
3. Jak mogę również uniknąć publikowania klucza w Internecie i używania go przez osoby, które nie zapłaciły licencji (klucz, który w zasadzie nie jest „ich”).

Myślę, że powinienem jakoś powiązać klucz z wersją aplikacji, aby można było pobierać opłaty za nowe klucze w wersjach funkcji.

Czy jest jeszcze coś, o czym powinienem pomyśleć w tym scenariuszu?

Zastrzeżenie: nie możesz uniemożliwić użytkownikom piractwa, ale tylko ułatwisz uczciwym użytkownikom robienie właściwych rzeczy.

Zakładając, że nie chcesz tworzyć specjalnej kompilacji dla każdego użytkownika, to:

• Wygeneruj sobie tajny klucz do produktu
• Weź nazwę użytkownika
• Połącz nazwę użytkownika oraz tajny klucz i skrót z (na przykład) SHA1
• Rozpakuj skrót SHA1 jako ciąg alfanumeryczny. To jest „klucz produktu” indywidualnego użytkownika
• W ramach programu wykonaj ten sam skrót i porównaj z kluczem produktu. Jeśli jest równy, OK.

Ale powtarzam: to nie zapobiegnie piractwu

Niedawno przeczytałem, że takie podejście nie jest bardzo kryptograficznie uzasadnione. Ale to rozwiązanie jest już słabe ( ponieważ samo oprogramowanie musi zawierać gdzieś tajny klucz ), więc nie sądzę, że to odkrycie unieważnia rozwiązanie w takim zakresie, w jakim się posuwa.

Pomyślałem, że naprawdę powinienem o tym wspomnieć; jeśli planujesz czerpać z tego coś innego, strzeż się.

Istnieje wiele sposobów generowania kluczy licencyjnych, ale bardzo niewiele z nich jest naprawdę bezpiecznych. Szkoda, bo dla firm klucze licencyjne mają prawie taką samą wartość jak prawdziwa gotówka.

Idealnie byłoby, gdyby klucze licencyjne miały następujące właściwości:

1. Tylko twoja firma powinna być w stanie generować klucze licencyjne dla twoich produktów, nawet jeśli ktoś całkowicie dokona inżynierii twoich produktów (co się stanie, mówię z doświadczenia). Ukrywanie algorytmu lub ukrywanie klucza szyfrowania w oprogramowaniu naprawdę nie wchodzi w rachubę, jeśli poważnie myślisz o kontrolowaniu licencjonowania. Jeśli twój produkt odniesie sukces, ktoś stworzy generator kluczy w ciągu kilku dni od wydania.

2. Klucz licencyjny powinien być użyteczny tylko na jednym komputerze (a przynajmniej powinieneś być w stanie bardzo ściśle kontrolować)

3. Klucz licencyjny powinien być krótki i łatwy do wpisania lub dyktowania przez telefon. Nie chcesz, aby każdy klient dzwonił do pomocy technicznej, ponieważ nie rozumie, czy klucz zawiera literę „l” czy „1”. Twój dział wsparcia podziękowałby Ci za to, a Ty poniesiesz niższe koszty w tym obszarze.

Jak więc rozwiązać te wyzwania?

1. Odpowiedź jest prosta, ale trudna technicznie: podpisy cyfrowe z wykorzystaniem kryptografii klucza publicznego. Twoje klucze licencyjne powinny być w rzeczywistości podpisanymi „dokumentami”, zawierającymi przydatne dane, podpisanymi kluczem prywatnym firmy. Podpisy powinny być częścią klucza licencyjnego. Produkt powinien zweryfikować klucze licencyjne odpowiednim kluczem publicznym. W ten sposób nawet jeśli ktoś ma pełny dostęp do logiki produktu, nie może wygenerować kluczy licencyjnych, ponieważ nie ma klucza prywatnego. Klucz licencyjny wyglądałby tak: BASE32 (CONCAT (DANE, PRIVATE_KEY_ENCRYPTED (HASH (DANE)))) Największym wyzwaniem jest tutaj to, że klasyczne algorytmy klucza publicznego mają duże rozmiary sygnatur. RSA512 ma 1024-bitową sygnaturę. Nie chcesz, aby klucze licencyjne miały setki znaków. Jednym z najbardziej skutecznych podejść jest zastosowanie kryptografii krzywej eliptycznej (z ostrożnymi implementacjami, aby uniknąć istniejących patentów). Klucze ECC są 6 razy krótsze niż klucze RSA, dla tej samej siły. Możesz dodatkowo zmniejszyć rozmiary podpisów za pomocą algorytmów takich jak algorytm podpisu cyfrowego Schnorr (patent wygasł w 2008 roku - dobrze :))

2. Można to osiągnąć przez aktywację produktu (dobrym przykładem jest Windows). Zasadniczo dla klienta z ważnym kluczem licencyjnym musisz wygenerować „dane aktywacyjne”, które są podpisanym komunikatem zawierającym identyfikator sprzętu komputera jako podpisane dane. Zwykle odbywa się to przez Internet, ale tylko RAZ: produkt wysyła klucz licencyjny i identyfikator sprzętu komputerowego do serwera aktywacyjnego, a serwer aktywacyjny odsyła podpisaną wiadomość (która może być również krótka i łatwa do dyktowania telefon). Od tego momentu produkt nie sprawdza klucza licencyjnego podczas uruchamiania, ale dane aktywacyjne, które wymagają tego samego komputera w celu weryfikacji (w przeciwnym razie dane byłyby inne, a podpis cyfrowy nie sprawdzałby poprawności).

3. Cóż, po prostu wyeliminuj zbędne znaki, takie jak „1”, „l”, „0”, „o” z klawiszy. Podziel ciąg klucza licencyjnego na grupy znaków.

Prosta odpowiedź - bez względu na to, jakiego schematu używasz, możesz go złamać.

Nie karaj uczciwych klientów systemem, który ma zapobiegać hakerom, ponieważ hakerzy złamią go niezależnie od tego.

Prosty skrótowy kod powiązany z ich adresem e-mail lub podobnym jest prawdopodobnie wystarczająco dobry. Identyfikatory sprzętowe zawsze stają się problemem, gdy ludzie muszą ponownie zainstalować lub zaktualizować sprzęt.

Dobry wątek na ten temat: http://discuss.joelonsoftware.com/default.asp?biz.5.82298.34

Podczas generowania klucza nie zapomnij o połączeniu wersji i numeru kompilacji z ciągiem, na którym obliczasz skrót. W ten sposób nie będzie jednego klucza, który odblokuje wszystko, co kiedykolwiek wydałeś.

Gdy znajdziesz jakieś klucze lub łatki unoszące się w astalavista.box.sk , będziesz wiedział, że udało ci się stworzyć coś na tyle popularnego, że ktoś chciał się złamać. Cieszyć!

Poza tym, co już zostało powiedziane ....

Każde użycie aplikacji .NET jest z natury możliwe do złamania z powodu problemów z językiem pośrednim. Prosty demontaż kodu .NET otworzy Twój produkt dla każdego. W tym momencie mogą łatwo ominąć kod licencyjny.

Nie można nawet użyć wartości sprzętowych do utworzenia klucza. Maszyny wirtualne pozwalają teraz komuś stworzyć obraz „licencjonowanej” maszyny i uruchomić ją na dowolnej platformie, którą wybiorą.

Jeśli jest to drogie oprogramowanie, istnieją inne rozwiązania. Jeśli nie, po prostu utrudnij przypadkowemu hakerowi. I zaakceptuj fakt, że w końcu będą tam nielicencjonowane kopie.

Jeśli Twój produkt jest skomplikowany, nieodłączne problemy ze wsparciem zapewnią ci pewną ochronę.

Silnik C # / .NET, którego używamy do generowania kluczy licencyjnych, jest teraz obsługiwany jako open source:

https://github.com/appsoftware/.NET-Licence-Key-Generator .

Opiera się na systemie „Częściowej Weryfikacji Klucza”, co oznacza, że ​​tylko podzbiór klucza, którego używasz do wygenerowania klucza, musi zostać wkompilowany do twojej dystrybucji. Sam tworzysz klucze, więc implementacja licencji jest unikalna dla twojego oprogramowania.

Jak wspomniano powyżej, jeśli kod można zdekompilować, stosunkowo łatwo można obejść większość systemów licencjonowania.

Jestem jednym z programistów platformy licencjonowania oprogramowania Cryptolens i pracuję nad systemami licencjonowania od 14 roku życia. W tej odpowiedzi zamieściłem kilka wskazówek opartych na doświadczeniu zdobytym przez lata.

Najlepszym sposobem na rozwiązanie tego problemu jest skonfigurowanie serwera kluczy licencyjnych, który będzie wywoływał każde wystąpienie aplikacji w celu weryfikacji klucza licencyjnego.

Korzyści z serwera kluczy licencyjnych

Zalety serwera kluczy licencyjnych polegają na tym, że:

1. zawsze możesz zaktualizować lub zablokować klucz licencyjny ze skutkiem natychmiastowym.
2. każdy klucz licencyjny może być zablokowany na określonej liczbie komputerów (pomaga to użytkownikom nie opublikować klucza licencyjnego online, aby inni mogli z niego korzystać).

Uwagi

Chociaż weryfikacja licencji online daje większą kontrolę nad każdą instancją aplikacji, połączenie internetowe nie zawsze jest obecne (szczególnie jeśli kierujesz reklamy do większych przedsiębiorstw), dlatego potrzebujemy innego sposobu przeprowadzania weryfikacji klucza licencyjnego.

Rozwiązaniem jest zawsze podpisywanie odpowiedzi klucza licencyjnego z serwera za pomocą kryptosystemu klucza publicznego, takiego jak RSA lub ECC (być może lepiej, jeśli planujesz uruchomić na systemach wbudowanych). Twoja aplikacja powinna mieć tylko klucz publiczny do weryfikacji odpowiedzi klucza licencyjnego.

Jeśli więc nie ma połączenia z Internetem, możesz użyć poprzedniej odpowiedzi klucza licencyjnego. Pamiętaj, aby przechowywać w odpowiedzi zarówno datę, jak i identyfikator komputera i sprawdź, czy nie jest on zbyt stary (np. Zezwalasz użytkownikom na wyłączanie się przez co najwyżej 30 dni itp.) Oraz czy odpowiedź klucza licencyjnego należy do właściwego urządzenia.

Pamiętaj, że zawsze powinieneś sprawdzać certyfikat odpowiedzi klucza licencyjnego, nawet jeśli masz połączenie z Internetem), aby upewnić się, że nie został on zmieniony, ponieważ opuścił serwer (to nadal musi być zrobione, nawet jeśli interfejs API do serwer kluczy licencyjnych używa https)

Ochrona tajnych algorytmów

Większość aplikacji .NET można dość łatwo poddać inżynierii wstecznej (Microsoft udostępnia zarówno diassembler do pobierania kodu IL, jak i niektóre produkty komercyjne mogą nawet odzyskać kod źródłowy np. W C #). Oczywiście zawsze możesz zaciemnić kod, ale nigdy nie jest w 100% bezpieczny.

W większości przypadków celem każdego rozwiązania w zakresie licencjonowania oprogramowania jest pomoc uczciwym ludziom w uczciwości (tj. Uczciwi użytkownicy, którzy są gotowi zapłacić, nie zapominają o płatności po wygaśnięciu wersji próbnej itp.).

Jednak nadal możesz mieć kod, którego w żadnym wypadku nie chcesz ujawnić publicznie (np. Algorytm do przewidywania cen akcji itp.). W takim przypadku jedynym sposobem jest utworzenie punktu końcowego interfejsu API, który aplikacja będzie wywoływać za każdym razem, gdy metoda powinna zostać wykonana. Wymaga połączenia z Internetem, ale zapewnia, że ​​Twój tajny kod nigdy nie zostanie wykonany przez maszynę klienta.

Realizacja

Jeśli nie chcesz wdrażać wszystkiego samodzielnie, polecam rzucić okiem na ten samouczek (część Cryptolens )

W przeszłości używałem Crypkey . Jest to jeden z wielu dostępnych.

Oprogramowanie można chronić tylko do pewnego momentu za pomocą dowolnego schematu licencyjnego.

Nie wiem, jak bardzo chcesz się starać

ale wierzę, że .net może uzyskać dostęp do numeru seryjnego dysku twardego.

możesz mieć program, który ci to wyśle ​​i coś innego (np. nazwę użytkownika i adres MAC nic)

na tej podstawie obliczasz kod i wysyłasz mu e-mailem klucz.

powstrzymają ich przed zamianą maszyn po otrzymaniu klucza.

Jedynym sposobem na zrobienie wszystkiego, o co prosiłeś, jest wymaganie dostępu do Internetu i weryfikacji za pomocą serwera. Aplikacja musi zalogować się na serwerze za pomocą klucza, a następnie musisz zapisać szczegóły sesji, takie jak adres IP. Zapobiegnie to użyciu klucza na kilku różnych komputerach. Zwykle nie jest to zbyt popularne wśród użytkowników aplikacji i jeśli nie jest to bardzo droga i skomplikowana aplikacja, nie jest tego warta.

Możesz po prostu mieć klucz licencyjny dla aplikacji, a następnie sprawdzić po stronie klienta, czy klucz jest dobry, ale łatwo jest przekazać ten klucz innym użytkownikom, a dzięki dekompilatorowi można wygenerować nowe klucze.

Wdrożyłem jednorazową aktywację internetową w oprogramowaniu mojej firmy (C # .net), która wymaga klucza licencyjnego, który odnosi się do licencji przechowywanej w bazie danych serwera. Oprogramowanie uderza serwer kluczem i otrzymuje informacje o licencji, które są następnie szyfrowane lokalnie za pomocą klucza RSA wygenerowanego z niektórych zmiennych (kombinacji CPUID i innych rzeczy, które nie będą się często zmieniać) na komputerze klienckim, a następnie zapisuje je w rejestr.

Wymaga to trochę kodowania po stronie serwera, ale działało dla nas naprawdę dobrze i mogłem korzystać z tego samego systemu, kiedy rozszerzyliśmy się o oprogramowanie oparte na przeglądarce. Daje również sprzedawcom świetne informacje o tym, kto, gdzie i kiedy oprogramowanie jest używane. Każdy system licencjonowania obsługiwany tylko lokalnie jest w pełni podatny na wykorzystanie, szczególnie w przypadku .NET . Ale, jak wszyscy mówili, żaden system nie jest całkowicie bezpieczny.

Moim zdaniem, jeśli nie korzystasz z licencjonowania internetowego, ochrona oprogramowania nie ma żadnego sensu. Z powodu bólu głowy, jaki może powodować DRM, niesprawiedliwe jest dla użytkowników, którzy faktycznie zapłacili za to cierpienie.

Mocno wierzę, że tylko system licencjonowania oparty na kryptografii klucza publicznego jest tutaj właściwym podejściem, ponieważ nie musisz dołączać niezbędnych informacji do wygenerowania licencji do swojego kodu źródłowego.

W przeszłości wiele razy korzystałem z Biblioteki licencyjnej Treka , ponieważ spełnia ona te wymagania i oferuje naprawdę dobrą cenę. Używa tej samej ochrony licencji dla użytkowników końcowych i dla siebie i nikt tego nie złamał. Możesz również znaleźć dobre wskazówki na stronie internetowej, aby uniknąć piractwa i włamań.

Jak kilku innych wspomnianych, jestem ogromnym przeciwnikiem domyślnej wrogości wobec klientów - coś, z czego przemysł licencjonowania jest znany. Więc rozwinę dobre rozwiązanie twojego problemu, które oferuje również dobry interfejs użytkownika .

Na początek wspomniałeś, że masz „ograniczoną” wersję oprogramowania, którego używasz do próby przekonwertowania klientów na „uaktualnienie” w celu uzyskania dodatkowych funkcji. Więc co szukasz są licencje funkcji dla danego produktu, np klient może zakupić licencję dla funkcji-X lub funkcji Y .

Zbudowałem Keygen z myślą o tego rodzaju licencjach. Keygen to licencjonowany interfejs API REST, który pozwala zarządzać kontami użytkowników, licencjami, a także śledzić wykorzystanie / powiązania maszyn.

Chciałbym skonfigurować 2 typy licencji ( polisa w Keygen), gdzie jedna jest polisą podstawową dla ograniczonej wersji darmowej, a druga polisą dla wersji płatnej.

Nie jestem pewien, czego używasz do płatności, ale załóżmy, że używasz czegoś takiego jak Stripe (obecnie dość standardowy), który oferuje haczyki internetowe . Keygen ma również haki internetowe (niezależnie od tego, czy z niego korzystasz, czy nie, wszystko to nadal obowiązuje). Możesz zintegrować Keygen, aby rozmawiać z dostawcą płatności za pomocą haczyków internetowych z obu stron (pomyśl: customer.created-> utwórz licencję podstawową dla klienta, license.created-> obciąż klienta za nową licencję).

Dzięki wykorzystaniu haków internetowych możemy zautomatyzować tworzenie licencji dla nowych klientów. A co z weryfikacją licencji w samej aplikacji? Można to zrobić na wiele sposobów, ale najbardziej popularnym jest wymaganie od klienta wprowadzenia długiego klucza licencyjnego w polu wejściowym, które można następnie zweryfikować; Myślę, że to okropny sposób na sprawdzenie poprawności licencji w twojej aplikacji.

Dlaczego tak myślę? Po pierwsze, wymagasz od klienta wprowadzenia żmudnie długiego klucza licencyjnego przeznaczonego na zużycie maszyny, a po drugie, wymaganie od ciebie i twojego klienta śledzenia tego żmudnie długiego klucza licencyjnego .

Okej, więc jaka jest alternatywa? Myślę, że najlepszą alternatywą jest zrobienie czegoś, do czego wszyscy klienci są przyzwyczajeni: umożliwienie im utworzenia konta dla twojego produktu za pomocą adresu e-mail / hasła . Następnie możesz powiązać wszystkie ich licencje i ich maszyny z tym kontem. Teraz zamiast wprowadzać klucz licencyjny, mogą po prostu zalogować się przy użyciu swoich poświadczeń.

Jakie to daje ci korzyści? Po pierwsze, pozbywa się potrzeby śledzenia kluczy licencyjnych przez ciebie i twoich klientów, ponieważ wszystko to jest obsługiwane za kulisami na koncie użytkownika, a co najważniejsze: możesz teraz oferować klientom samoobsługową licencję i maszynę aktywacja! tzn. ponieważ wszystkie ich licencje i komputery są powiązane z ich kontem użytkownika, możesz poprosić ich o zakup licencji, gdy uruchomią aplikację na nierozpoznanym komputerze.

Teraz do sprawdzania licencji : ilekroć dzienniki klientów do aplikacji z ich e-mail / hasło, można wyszukać swoje konto użytkownika na licencji są właścicielami w celu ustalenia, czy mogą wykorzystywać funkcje X lub funkcja-Y . A ponieważ Twoja aplikacja jest teraz samoobsługowa , możesz pozwolić klientom na zakup dodatkowych funkcji bezpośrednio z poziomu aplikacji!

Dlatego wprowadziliśmy mnóstwo automatyzacji do naszego systemu licencyjnego, możemy licencjonować poszczególne funkcje (tj. Wersję ograniczoną vs. pełną), zaoferowaliśmy naszym klientom niesamowity UX, a także złagodziliśmy jeden z największych powodów w przypadku wniosków o wsparcie: odzyskiwanie klucza licencyjnego.

W każdym razie to trwało długo, ale mam nadzieję, że komuś pomaga!

Nie można całkowicie zapobiec piractwu oprogramowania. Możesz zapobiec przypadkowemu piractwu i to właśnie robią wszystkie rozwiązania licencyjne.

Licencjonowanie zablokowane w węźle (maszynowym) jest najlepsze, jeśli chcesz zapobiec ponownemu użyciu kluczy licencyjnych. Używam Cryptlex od około roku do mojego oprogramowania. Ma również bezpłatny plan , więc jeśli nie spodziewasz się zbyt wielu klientów, możesz go użyć za darmo.

Możesz skorzystać z darmowego rozwiązania innej firmy, aby poradzić sobie z tym za Ciebie, takiego jak Quantum-Key.Net Jest bezpłatny i obsługuje płatności przez PayPal za pośrednictwem strony internetowej, którą dla Ciebie tworzy, wydawania kluczy przez e-mail i blokowania użycia klucza na określonym komputerze, aby zapobiegać piractwu.

Powinieneś również zadbać o zaciemnienie / zaszyfrowanie swojego kodu lub można go łatwo poddać inżynierii wstecznej za pomocą oprogramowania takiego jak De4dot i .NetReflector. Dobrym darmowym zaciemniaczem kodu jest ConfuserEx, który jest szybki i prosty w użyciu i skuteczniejszy niż drogie alternatywy.

Powinieneś uruchomić gotowe oprogramowanie za pośrednictwem De4Dot i .NetReflector, aby poddać go inżynierii wstecznej i zobaczyć, co zobaczyłby cracker, gdyby zrobił to samo i upewnić się, że nie pozostawiłeś żadnego ważnego kodu odsłoniętego lub ukrytego.

Twoje oprogramowanie będzie nadal nadawać się do krakowania, ale dla zwykłego crackera może być wystarczające, aby je odłożyć, a te proste kroki zapobiegną również wyodrębnieniu i ponownemu użyciu kodu.

https://quantum-key.net

Jak korzystać z ConfuserEx?

https://github.com/0xd4d/de4dot

https://www.red-gate.com/dynamic/products/dotnet-development/reflector/download