2010-06-04 15 views
7

Tworzę system licencjonowania, gdy klienci pytają mojego serwera o licencję i wysyłam im licencję, jeśli mogą ją mieć.Mylić o szyfrowaniu z kluczami publicznymi i prywatnymi (które mają być używane do szyfrowania)

W moim bieżącym systemie szyfruję licencję za pomocą jednego klucza prywatnego i klucz publiczny jest osadzony w aplikacji klienckiej, której używają do odszyfrowania licencji. To działa!

Inni powiedzieli mi, że powinienem szyfrować klucz publiczny na serwerze i dystrybuować klucz prywatny do klientów. Przeszukałem internet i widzę, że czasami używają klucza prywatnego do szyfrowania, a czasami do szyfrowania używają klucza publicznego.

W takim razie co mam zrobić?

Odpowiedz

8

Inni mówili mi, że powinienem być szyfrowania z kluczem publicznym na serwerze i dystrybucję prywatną klucz do klientów.

Ci ludzie są w błędzie. Nazwa prywatny klucz oznacza, że ​​jest to prywatny znak, że tylko ty powinieneś mieć do niego dostęp.

W takim razie co mam zrobić?

Użyj podpisów cyfrowych. Podpisz plik licencji swoim kluczem prywatnym i użyj swojego klucza publicznego w aplikacji, aby sprawdzić, czy podpis na licencji pochodzi od Ciebie.

+1

To jest złe. W przypadku szyfrowania asymetrycznego szyfrujesz za pomocą klucza publicznego odbiorcy. –

+1

@Matthew Nie powiedziałem inaczej. Powiedziałem, że nie powinien * nie * rozpowszechniać swojego prywatnego klucza. – Kevin

+0

, więc w moim przypadku, co powinienem robić? Zakładając, że będę używał tego samego klucza publicznego i prywatnego dla wszystkich klientów. – jax

0

Jeśli korzystasz z publicznego i prywatnego (asymetrycznego) szyfrowania, zawsze szyfrujesz za pomocą klucza publicznego odbiorcy, który odszyfrowuje kluczem prywatnym. W przypadku podpisów cyfrowych podpisujesz kluczem prywatnym, a odbiorca weryfikuje podpis za pomocą swojego klucza publicznego.

Pojawia się pytanie, w jaki sposób można utworzyć bezpieczny system DRM? Jeśli korzystasz z szyfrowania i dajesz odbiorcom klucz prywatny, mogą dystrybuować klucz lub odszyfrowaną zawartość. Jeśli korzystasz z podpisów, mogą po prostu usunąć część weryfikacji podpisu z twojego programu.

Odpowiedź brzmi, że to niemożliwe. Koncepcja DRM jest zasadniczo wadliwa.

1

Jeśli szyfrujesz coś, co ma być odczytywane tylko przez jednego odbiorcę, to zaszyfrujesz klucz publiczny tego odbiorcy i użyjesz jego klucza prywatnego, aby go przeczytać.

Jeśli szyfrujesz wielu adresatów, możesz zaszyfrować klucz prywatny i przekazać swój klucz publiczny tym, którym chcesz go przeczytać. Zwykle nazywa się to "podpisaniem", ponieważ każdy, kto ma dostęp do Twojego klucza publicznego, może go przeczytać, więc nie jest to forma prywatnej komunikacji.

Generalnie bardziej niezawodnym rozwiązaniem dla Twojej aplikacji jest generowanie pary kluczy na instalację, wysłanie klucza publicznego, który został wygenerowany z powrotem do serwera, który następnie użyjesz do zaszyfrowania, aby tylko ta pojedyncza instalacja mogła użyj utworzonej licencji (przez odszyfrowanie jej za pomocą klucza prywatnego).

+0

Podpisywanie nie jest szyfrowaniem, kropka. Ludzie mogą czytać wiadomości nawet bez klucza publicznego. Potrzebują tego tylko do zweryfikowania podpisu. W twoim "niezawodnym rozwiązaniu" nie ma nic, co zapobiegałoby udostępnianiu kluczy prywatnych. –

+0

Matthew, potrzebujesz klucza publicznego, aby zweryfikować wiadomość. –

+0

@ Matthew - Powiedziałem "bardziej krzepki", to względne twierdzenie, a nie bezwzględne. Jak zauważyłeś w swojej odpowiedzi, każdy DRM jest skazany na niepowodzenie, jeśli ktoś chce ominąć go wystarczająco, chodzi o to, aby ludzie dorywczy byli uczciwi, a nie całkowicie bezpieczni. – Donnie

1

Przynajmniej w typowym algorytmie szyfrowania klucza publicznego (np. RSA) nie ma istotnej różnicy między kluczem publicznym a kluczem prywatnym. Podczas generowania kluczy otrzymujesz dwa klucze.Zachowujesz jedno prywatne i publikujesz drugie - ale nie ma znaczenia, który z nich publikujesz i który zachowujesz jako prywatny.

Wszystko, co zaszyfrujesz jednym kluczem, można odszyfrować innym kluczem. W normalnych celach publikujesz jeden klucz, który pozwala każdemu zaszyfrować coś, co tylko ty możesz odszyfrować. Z technicznego punktu widzenia odwrotne działanie działa dobrze: jeśli zaszyfrujesz coś swoim kluczem prywatnym, każdy z kluczem publicznym może go odszyfrować. Zazwyczaj jest to używane do weryfikacji podpisu (tzn. Każdy, kto ma klucz publiczny, może sprawdzić, czy podpis musiał zostać utworzony za pomocą klucza prywatnego). Zwykle chcesz używać oddzielnych par kluczy do szyfrowania i podpisywania.

Dla twojej sprawy, jest otwarte na pewne pytanie, co naprawdę zamierzasz osiągnąć. Z pewnością można zaszyfrować niektóre dane niezbędne do korzystania z programu, więc użytkownik potrzebuje klucza do odszyfrowania go i korzystania z programu - ale jeśli użytkownik chce przekazać kopię kodu nieautoryzowanej osobie, prawdopodobnie wygrał nie wahaj się też przekazać im kopię klucza. W związku z tym, mimo że szyfrowanie/odszyfrowywanie spełni swoje zadanie, jest mało prawdopodobne, aby zapewniło prawdziwą ochronę.

Bardziej typowy schemat licencjonowania jest powiązany z czymś w rodzaju określonego adresu IP, więc można zrobić coś w rodzaju zaszyfrowania adresu IP, a następnie użyć wyniku jako klucza do odszyfrowania danych potrzebnych do korzystania z programu. Jeśli adres IP jest nieprawidłowy, dane nie zostaną poprawnie odszyfrowane, a program nie działa. Dopóki użytkownik ma statyczny adres IP, może to działać dobrze, ale spowoduje problemy w połączeniu z DHCP.

Moja natychmiastowa porada po prostu tego nie zrobiłaby. Jeśli mimo to nalegasz na zrobienie tego, nie rób tego sam - uzyskaj coś w rodzaju FlexNet, aby sobie z tym poradzić. Bez tego lepiej się czuć, ale przynajmniej w ten sposób uzyskasz coś, co działa pod rodzajami, a Ty nie będziesz tracić czasu ani wysiłku na to, co można by lepiej wykorzystać do ulepszenia twojego oprogramowania.

+1

Natknąłem się na to przez przypadek dwa lata później i chcę podkreślić, że Jerry jest w błędzie - to * nie ma znaczenia, który klucz trzymasz w sekrecie. Biorąc pod uwagę klucz prywatny RSA, możesz obliczyć klucz publiczny. Nigdy nie podawaj klucza prywatnego. Cf. http://stackoverflow.com/questions/696472/given-a-private-key-is-it-possible-to-derive-its-public-key –

4

Gratulacje, właśnie wymyśliliście podpis RSA. (W każdym razie powinno się z tego korzystać). Aby komunikować się z systemem klucza publicznego, musisz raz użyć klucza prywatnego i klucza publicznego, ale RSA obsługuje dwa różne zamówienia: 1) Szyfruj za pomocą klucza publicznego, odszyfruj z prywatnym: odbiorca nie wie nic o źródle wiadomości, ale nadawca wie, że tylko odbiorca (posiadacz klucza prywatnego) może ją odczytać. To klasyczne "szyfrowanie". 2) "Zaszyfruj" kluczem prywatnym, a następnie "odszyfruj" publiczne. Jest to podpis cyfrowy i zapewnia uwierzytelnienie. Każdy może przeczytać wiadomość, ale mógł ją wysłać tylko prywatny właściciel klucza.

Zakładając, że twoja licencja jest dostosowana do klienta (co może być tak proste, jak dodanie kopii losowego numeru wygenerowanego przez klienta), to jest ona bezużyteczna dla każdego, ale klient może być pewien, że serwer ją wysłał.

Symetria nie jest tak schludna w praktyce; różne tryby działania mają różne słabości i błędy, więc implementacja jest zazwyczaj znacząco różna, ale taka jest ogólna idea.

Jedną z pierwszych i najważniejszych lekcji w kryptologii jest zrozumienie uwierzytelniania i kiedy go używać. Jest potrzebny co najmniej tak często, jak szyfrowanie i nie wiedząc, kiedy go użyć, pozostawia Cię w sytuacji.

0

Mam nadzieję, że ten link z Wikipedii pomaga. PKI opiera się na wzajemnym zaufaniu. Jednak klucz prywatny musi być chroniony przez właściciela. Publiczne, jak sama nazwa wskazuje, jest otwarte dla wszystkich. Cała architektura została stworzona, aby pomóc w scenariuszu zdefiniowanym powyżej w pytaniu.

Powiązane problemy