Najlepszy klucz sprzetowy w relacji cena/jakosc

"Walec drogowy przejechał". I co mi zrobisz?

Hehe. Powodzenia.

Sie nieco da. Padlem swego czasu na dwoch zabezpieczeniach. W pierwszym po dwoch dniach debugowania i przejsciu chyba z kilkudziesieciu odszyfrowan i pulapek poddalem sie - jeszcze sporo KB zostalo ktore nie zostaly uzyte.

A w drugim klucz chyba byl wrazliwy na jakies czasy ..

J.

Nic - ale co Ty mi zrobisz ? :-)

Ewentualnie cena klucza=70% ceny programu :-)

J.

Uzytkownik "Piotrek" snipped-for-privacy@NOSPAM.gazeta.pl> napisal w wiadomosci news:dd5cbr$16f2$ snipped-for-privacy@news.mm.pl...

Odezwe sie, bo jestem jednym z odpowiedzialnych za ten klucz.

Powiem tyle: Byl nam potrzebny klucz do naszego programu kontroli dostepu i rejestracji czasu pracy (system "bibi"). Program mial umozliwiac tworzenie dowolnie wielkich instalacji KDiRCP poprzez komunikowanie sie poszczególnych wezlów przez internet. Klucz mial przede wszystkim umozliwiac szyfrowanie danych przesylanych przez publicznie dostepne (do sledzenia) lacza, a nie chronic naszego programu przed kopiowaniem. Chodzilo o to, aby najistotniejsze dla bezpieczenstwa przesylania danych klucze nie byly przechowywane gdzies na dysku PC. Produkowany przez nas od 10 lat klucz HAK1 (na Centronics) nie nadawal sie do tego. Wydawalo nam sie, ze opracowanie klucza USB zajmie nam kilka miesiecy. Niestety stopniowe rozbudowywanie wymagan i ciagle debaty nad bezpieczenstwem wydluzyly to do ponad 2 lat, zanim powstal klucz, który uzywamy w naszym systemie. Poza szyfrowaniem transmisji weryfikuje on hasla uzytkowników (nie przesyla ich, tylko weryfikuje) i sprawdza podpisy licencji. Pozwolil równiez na przechowywanie calej bazy danych systemu w formie zaszyfrowanej kluczem generowanym przez administratora systemu, a wiec niemozliwej do odczytania na innych instalacjach tego samego systemu. Dzieki podpisom licencje (pliki tekstowe) mozna wysylac jawnie do klienta. Zawarcie nazwy klienta (drukowanej na kazdym raporcie) w pliku licencji jest dosc skuteczna ochrona przed uzyciem nielegalnych kopii programu, gdy odbiorcami sa firmy.

Aby legalnie te klucze sprzedawac do naszego systemu musielismy i tak zrobic ich badania EMC i nadac im CE, wiec postanowilismy zaoferowac je równiez innym, którym moga sie przydac.

Szczególów funkcjonowania klucza nie pamietam (nie meczyc mnie !). Za kazdym razem, gdy trzeba bylo sie w nie zaglebic zajmowalo mi kilka dni, zanim bylem gotów do rzeczowej dyskusji i podejmowania nie-pochopnych decyzji co do mozliwosci i sposobu dzialania HAK2. P.G.

U¿ytkownik "szlovak" snipped-for-privacy@o2.pl napisa³ w wiadomo¶ci news:dd5gum$dsr$ snipped-for-privacy@nemesis.news.tpi.pl...

szeregow±.

Jak kto¶ ma dostêp do programu, aby go skopiowaæ, ma zazwyczaj równie¿ dostêp do klucza. P.G.

U¿ytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisa³ w wiadomo¶ci news: snipped-for-privacy@4ax.com...

Nasz poprzedni klucz HAK1 by³ przypadkiem (nie zamierzone) do¶æ odporny na debuggowanie. Z Centronicsa zrobili¶my potrajacz (podwajacz czasem by³ za ma³o) napiêcia, obcinali¶my to do 5V5 i gromadzili¶my 47uF. Start rozmowy z kluczem - zasilenie GALa (50mA) z tego 47uF - starcza³o na 1ms komunikacji. Przy przechodzeniu krokowo przez te procedury wszystko by³o inaczej ni¿ normalnie. P.G.

Has³a mo¿na nie przesy³aæ - klucz rozszyfrowuje dane. P.G.

Andrzej Lawa napisał(a):

rozmawiamy o przypadku że klient przynosi zepsuty. Powiedzmy jeśłi nie przynosi zepsutego to płaci dużo że mu się nie opłaci

U¿ytkownik "szlovak" snipped-for-privacy@o2.pl napisa³ w wiadomo¶ci news:dd5qk1$c1g$ snipped-for-privacy@nemesis.news.tpi.pl...

maksymalnie

Oczywi¶cie (szlifuj±c scalaki na pewno). Ja s±dzê, ¿e ³atwiej z³amaæ program, ni¿ zrobiæ kopiê klucza.

HAK2 nigdy nie przesy³a hase³ - to on czeka na podanie prawid³owego has³a, aby umo¿liwiæ dalsze dzia³ania. Je¶li dobrze pamiêtam to zalogowanie zaczyna siê od ustalenia klucza transmisyjnego dla danej sesji (wyliczanego (DES3) z liczb losowych podanych przez PC i HAK2). Has³o jest przesy³ane do HAK2 zakodowane tym kluczem transmisyjnym. Nie da siê prosto przesy³aæ wszystkich kolejnych mo¿liwych hase³, bo ka¿de kolejne trzeba inaczej zakodowaæ. Poza tym has³a przechowywane gdziekolwiek (a wiêc i w kluczu) nie powinny nigdy w ¿yciu byæ has³ami podanymi przez u¿ytkowników (mog± byæ za krótkie, zawieraæ same litery, lub daæ siê domy¶liæ). Has³a u¿ytkowników nale¿y przekodowaæ jak±¶ funkcj± jednokierunkow± (to znaczy matematycy udowodnili, ¿e z danych wynikowych nie da siê doj¶æ do ani jednego bitu danych wej¶ciowych). Wiêc has³o konkretnego u¿ytkownika w HAK2 ma zawsze 13 bajtów (du¿o kombinacji do sprawdzenia). Ka¿dy b³±d w komunikacji (mo¿e kto¶ próbuje po zalogowaniu pod³o¿yæ swoj± transmisjê) powoduje zerwanie sesji i konieczno¶æ ponownego zalogowania siê.

P.G.

Piotr Gałka napisał(a):

Może ma ale nie znaczy że od razu skopiuje, szczególnie że nie odczyta pamięci mikrokontrolera (raczej z prawdopodobieństwem 99,99% nie uda mu się). W sumie odczyt mikroskopem z mikrokontrolera nie jest taki prosty i tani, lub metodami wysyłania impulsów itp.

Czyli cos w podobie do szyfrowania haseł w linuxie/unixie, jest "salt" i liczba , obie tworzą zakodowane hasło i trzymane są w pliku... shadow... ]-). Tylko żeby zapezpieczyć program (jak w temacie głównym wątku) nie można żądać od klucza żeby tylko powiedział czy hasło prawidłowe :-) bo to łatwo ominąć, w systemach komputerowych gdzie mamy do czynienia ze zdalnym lub lokalnym logowaniem to jest wystarczające zabezpieczenie gdyż user nie ma dostępu do "sam" w windowsie lub "shadow" w unixach

Chyba nie zrozumia³e¶ gdzie jest problem. Za³ó¿my, ¿e kupi³em program zabezpieczony kluczem takim jak

Pawe³

U¿ytkownik "szlovak" snipped-for-privacy@o2.pl napisa³ w wiadomo¶ci news:dd7qf7$baf$ snipped-for-privacy@nemesis.news.tpi.pl...

W tej ga³êzi w±tku jest mowa o zabezpieczeniu w³±czonym w RS232 wysy³aj±cym komputerowi klucz s³u¿±cy do odkodowania programu. Poza tym z definicji o sytuacji, kiedy chce skopiowaæ (odpada pewien % uczciwych). No i o kopiowaniu poprzez pods³uchanie transmisji szeregowej, a nie poprzez odczyt kodu procesora. P.G.

No jasne że twój klucz jest lepszy, nie zaprzeczam :-)

U¿ytkownik "szlovak" snipped-for-privacy@o2.pl napisa³ w wiadomo¶ci news:dd7qu7$baf$ snipped-for-privacy@nemesis.news.tpi.pl...

Zgoda, chodzi³o mi tylko o to, ¿e HAK2 nie wysy³a has³a bo napisa³e¶: "program wysy³a zapytanie o has³o do klucza...."

Dopiero po zalogowaniu mo¿na (miêdzy innymi) poprosiæ HAK2 o zakodowanie lub zdekodowanie (DES3) jakich¶ danych. HAK2 robi to w oparciu o klucz (has³o) ukryte w jego wewnêtrznej pamiêci i nigdy go w jakiejkolwiek postaci nie wysy³a. Oczywi¶cie (ze wzglêdów czasowych) nie mo¿na w ten sposób zakodowaæ ca³ego programu, ale pewne kluczowe dane lub klucze u¿ywane do faktycznego kodowania programu mo¿na - to ju¿ jest kwestia inwencji programisty.

P.G.

U¿ytkownik "szlovak" snipped-for-privacy@o2.pl napisa³ w wiadomo¶ci news:dd86hu$iv5$ snipped-for-privacy@nemesis.news.tpi.pl...

Wydawa³o mi siê, ¿e nie o to mi chodzi³o, ale jak siê zastanowiæ to mo¿e trafi³e¶ w sedno :-) P.G.

No nie do koñca. Sta³e¶ siê w³a¶cicielem dzia³aj±cego klucza do programu. Sprawê w³asnosci rozwiazuje dopiero faktura / umowa kupna-sprzeda¿y.

Je¶li chcesz dobrze zabezpieczyæ program, musisz sprawiæ by klucz sprzêtowy by³ czê¶ci± akgorytmu pracy ca³ego programu i to jak najtrudniejsz± do odtworzenia.