Najlepszy klucz sprzetowy w relacji cena/jakosc

Piotrek napisał(a):

Wszystko zależy do czego to ma być, jak drogi program, czy powszechny. Ja bym to zrobił na USB (ale jako RS232 przez układ FT232) albo na zwykłym RS232 (zasilanie pobierane bezpośrednio z portu) i w oparciu o procesor PIC, który miałby w sobie klucz który rozkodowuje program lub jego podstawową jakąś część. Nie będzie to takie zabezpieczenie jak na tej stronie ale być może wystarczająco skuteczne. Koszt seryjnej produkcji byłby niższy o rząd wielkości , właściwie to kilka złoty w wersji na RS232, a na usb droższy bo dochodzi jeszcze układ FT232. Możliwość skopiowania klucza oczywiście będzie łatwiejsza niż to co jest na tej stronie, no ale trzeba mieć taki klucz ( ten mojej propozycji) w ręku żeby skopiować, podsłuchując transmisję szeregową.

Gdyby np. komputer nie miał złącza szeregowego to wystarczyłoby zastosować przejściówkę USB-> RS232 .

w sumie logika była by taka sama , ten klucz ze stronki też wysyła jakieś hasło do komputera, aplikacja może jedynie czekać na to hasło które rozkodowuje program. W ten sposób nie mając klucza, od strony komputera nie rozgryzie się hasła. Tylko że oni zastosowali możliwość szyfrowania DESem jako standardu pewnego, i umozliwiają też kodowanie. W tym kluczu co proponuję można wpisać klucz jaki się chce, tylko od Ciebie zależy jak długim hasłem chcesz zakodować, możesz też zastosować kodowanie DES i to tylko kwestia odczytu danych z klucza sprzętowego

Wystarczy, że cracker raz dorwie się do oryginalnego klucza i skopiuje hasło użyte do szyfrowania. BTW Według mnie największym grzechem osób odpowiedzialnych za zabezpieczenia programów jest wywoływanie jednej i tej samej procedury sprawdzającej zabezpieczenie, oraz wyświetlanie zaraz za nią komunikatu o braku klucza/numeru seryjnego (to wręcz pokazywanie palcem, gdzie są sprawdzane zabezpieczenia). Dlatego warto skupić się na opracowaniu kilkunastu różnych procedur/algorytmów sprawdzających obecność zabezpieczenia i rozsiać je w różnych miejscach programu.

Ale współczesne mikrokontrolery mają zabezpieczenia przed odczytaniem kodu. Oczywiście można to odczytać, ale to powinno być droższe niż licencja programu.

Zbych napisał(a):

Nie o to mi chodziło, właśnie takie rozśanie jest bez sensu. Wystarczy że klucz na prawdę będzie coś odkodowywał, wtedy żaden kraker nie pomoże bez klucza.

A możliwość skopiowania klucza zawsze istnieje, należy to maksymalnie utrudnić, ale nie jest to możliwe do wykluczenia. Powiedzmy nawet że użyje się tego klucza z tej stronki, program wysyła zapytanie o hasło do klucza i jaki by on nie był to da się go łatwiej lub trudniej skopiować. To tak jak z kluczami do domu, siła ich zabezpieczenia polega na niedostępności dla osób postronnych.

Prawde mówiąc żeby zabezpieczyć taki program w 100% to trzeba by program zaszyć chyba w jakimś procku i wstawić w złącze PCI hehe. I niektórzy tak robią , coś mi się kojarzy.

Filip Ozimek napisał(a):

No ale zapis hasła w mikrokontrolezrze to nie wszystko. Przeciez mikrokontroler komunikuje się z aplikacją w komputerze wiec jakie by po drodze nie były utrudnienia to można odczytać hasło z transmisji i skrakować program. Więc najważniejszym ogniwem jest klucz i ważne jest żeby nie było banalne jego skopiowanie. Więcej nie da się zabezpieczyć programu inaczej jak w formie całkowicie hardware'owej kości w systemie

Miałem na myśli podejrzenie przesyłu hasła użytego do odszyfrowania programu, a nie łamanie samego klucza. Nawet gdyby samą transmisję hasła szyfrować i tak,w którymś momencie musi się ono pojawić w formie pierwotnej/jawnej po to, żeby się nadawało do deszyfracji programu chronionego.

To znaczy chcesz wrzucać zakodowaną część programu do klucza i odebrać jego rozszyfrowaną wersję ? Żeby to miało sensowny czas wykonania trzeba by wsadzić do klucza całkiem wydajnego procka i transmitować dane z prędkością przynajmniej kilku MB/s (usb 2?). To chyba nie będzie tani klucz.

Pierwsz myśl: klucz miesza algorytmem np. MD5 ciąg który powstanie z przetwarzania tego co dostanie od komputera (losowe dane) + nr licencji

• coś jeszcze zaszytego i wysyła do porównania; program porównuje to samo. Za każdym razem co innego jest wysyłane. To można zrealizować chyba na prostym Atmelu :)

Ale wysyłanie za każdym razem tego samego to chyba najgłupsze rozwiązanie.

A teraz wystarczy w programie po porównaniu obydwu ciągów zmodyfikować kilka instrukcji tak, żeby wynik porownania zawsze był pozytywny i klucz nie będzie już do niczego potrzebny :-)

A znasz jakiś dobry algorytm, który potrafi rozszyfrować dane przy pomocy różnych haseł ? Hasło musi być to samo, można je najwyżej na czas transmisji szyfrować.

I właśnie niezależnie od wymyślej postaci super-duper klucza wystarczy odpowiedni zcrackować soft. Podobnie jak z superlaską ;) na kierownicę wykonaną z ekstratwardego metalu - na nic to, jeżeli 10x prościej wyłamać kierownicę (takie opisy obchodzenia zabezpieczeń opisywali kiedyś w AutoŚwiecie). Trudniej się robi, gdy część softu siedzi w kluczu i jest wydawana tylko po np. weryfikacji dodatkowego hasła.

Paweł napisał(a):

zapomniałeś że wtedy trzeba zwrócic ten zepsuty...

Pozostaje tak napisać kod, aby nie dało się tego debuggerem obejżeć :)

To nie jest kwestia algorytmu a metody. Po prostu ta metoda ma słabe punkty (wysyłanie, szyfrowanie itp).

Zbych napisał(a):

To byłoby fajne ale nie to miałem na myśli. Zresztą taka wydjność nie jest konieczna, zależy jak duży program. Mam na myśli to że ten klucz to nie ma być proste porównanie w aplikacji, czy się zgadza bo to łatwo zkrakować. Tylko to hasło ma służyć do odszyfrowania danych. Najprostsze zastosowanie to nasuwa się na myśl pamięć I2C podłączona na zasadzie programatora JDM ,tylko to jest za proste. Trzeba jeszcze namieszać w transmisji i wstawić choćby najprostszego procka zamiast eeproma no i włączyć codeprotect żeby nie było możliwe skopiowanie programu procka. I na przykład stosowane byłyby różne hasła do róznych części aplikacji. Zresztą długo można gadać na ten temat bo dużo jest mozliwości kombinowania.