W tym artykule opisano sposoby ominięcia sprzętowych systemów zabezpieczeń. Jako przykład rozważmy technologię HASP (Hardware Against Software Piracy) opracowaną przez Aladdin Knowledge Systems Ltd. W przeszłości tę technologię był jednym z najpopularniejszych systemów ochrony oprogramowania sprzętowego.
Z mocy ochrony sprzętu HASP korzysta wielu poważnych twórców oprogramowania, którzy nie chcą, aby ich produkt był rozpowszechniany bez pozwolenia. Hasp chroni na przykład pakiety „1C.Accounting” lub „1C.Enterprise”, bez których żadna mniej lub bardziej zorganizowana firma nie może przetrwać. Popularny katalog prawniczy „ConsultantPlus” zabezpiecza także dostęp do danych za pomocą kluczy elektronicznych. Aby korzystać z wyżej wymienionego lub innego równie drogiego oprogramowania nie płacąc nikomu ani grosza, nie wystarczy po prostu surfować po Internecie w poszukiwaniu narzędzia txt z kluczami. Jednak haker zawsze wymyśli, co zrobić z ochroną, nawet sprzętową. I nie potrzebuje do tego lutownicy.
Z przesadą można powiedzieć, że HASP składa się z dwóch części: sprzętu i oprogramowania. Sprzętem jest klucz elektroniczny w postaci pęku kluczy USB, karty PCMCIA, urządzenia LTP, a nawet wewnętrznej karty PCI. Zainstalowane oprogramowanie będzie działać tylko na maszynie, do której włożony zostanie klucz elektroniczny. Właściwie dobrym pomysłem byłoby odzwyczajenie oprogramowania od tak nieprzyjemnego dla portfela nawyku.
Część oprogramowania składa się ze sterowników kluczy elektronicznych i różnych programów, które wiążą klucze elektroniczne ze sterownikami bezpośrednio z chronionym produktem lub z niektórymi zaszyfrowanymi danymi. W tym artykule przyjrzymy się i ominiemy ochronę za pomocą pęku kluczy USB - prawdopodobnie najpopularniejszego obecnie klucza elektronicznego.
Sam brelok praktycznie nas nie interesuje, w przeciwieństwie do dołączonego do niego oprogramowania. Najbardziej interesuje nas moduł Hardlock.sys. Nie wchodząc w szczegóły, zauważę, że ten sterownik jest odpowiedzialny za interakcję z kluczem sprzętowym. Zawiera dwa obiekty urządzeń, z których jeden ma symboliczną nazwę DeviceFNT0. Korzystając z tego obiektu, chroniona aplikacja za pośrednictwem menedżera I/O sprawdza licencję na korzystanie z tego oprogramowania.
Główną wadą takiego systemu ochrony jest możliwość przechwytywania wywołań do menedżera we/wy i emulowania klucza sprzętowego. Istnieje również możliwość opracowania sterownika klucza wirtualnego, jednak jest to znacznie bardziej złożone zadanie techniczne niż przechwytywanie połączeń.
Jak wiadomo, model sterownika jest opisany w strukturze DRIVER_OBJECT po załadowaniu modułu. Przechowuje tablicę procedur obsługi wiadomości. Co więcej, nikt nie przeszkadza Ci w przepisywaniu tych adresów i przejęciu kontroli poprzez wykonanie naszego kodu. W ten sposób możliwe jest przechwytywanie i zastępowanie pakietów IRP poprzez podstawianie danych licencyjnych. Innymi słowy, jeśli masz zrzut klucza bezpieczeństwa, możesz przekazać go programowi, który sprawdzi poprawność danych licencyjnych!
Aby zastosować inną metodę, wymagany jest również zrzut klucza, ale podstawienie danych odbywa się inaczej, a mianowicie w emulacji oprogramowania. Oznacza to, że sterownik bezpieczeństwa będzie mógł obsługiwać klucz wirtualny w taki sam sposób, jak klucz fizyczny.
Jak już wspomniano, koncepcja przechwytywania polega na nadpisaniu procedur obsługi pakietów IRP. Aby to zrobić, musisz mieć możliwość zmiany pól struktury DRIVER_OBJECT. Na szczęście istnieje funkcja o nazwie IoGetDevicePointer, która zwraca wskaźnik na górę nazwanego obiektu stosu urządzeń i wskaźnik do odpowiedniego obiektu pliku. Oto fragment kodu funkcji ustawiającej hak:
UNICODE_STRING Nazwa urządzenia;
PDEVICE_OBJECT Obiekt urządzenia;
PFILE_OBJECT Obiekt pliku;
RtlInitUnicodeString(&NazwaUrządzenia, lpDevice);
IoGetDeviceObjectPointer(&DeviceName, 1u, &FileObject, &DeviceObject);
Po otrzymaniu wskaźnika do struktury DEVICE_OBJECT mamy wskaźnik do DRIVER_OBJECT. Zamieńmy teraz adresy handlerów i funkcji rozładunku sterowników na nasze własne:
Urządzenie hakowe NTSTATUS (LPWSTR lpDevice)
gDriverObject = DeviceObject->DriverObject;
gDeviceControl = gDriverObject->MajorFunction;
gDriverObject->MajorFunction = HookDispatch;
gInternalDeviceControl = gDriverObject->MajorFunction;
gDriverObject->MajorFunction = HookDispatch;
gDriverUnload = gDriverObject->DriverUnload;
gDriverObject->DriverUnload = HookUnload;
ObfDereferenceObject(Obiekt pliku);
Ostatnia linia wywołuje funkcję ObfDereferenceObject, która zmniejsza liczbę odniesień do obiektu pliku. Należy to zrobić, aby poprawnie zwolnić sterownik, aby uniknąć wycieków zasobów i podobnych błędów.
Ponieważ wskaźnik do obiektu sterownika ochrony jest zapisany, aby usunąć pułapkę, wystarczy przywrócić poprzednie procedury obsługi pakietów IRP:
void Odczep urządzenie (void)
gDriverObject->MajorFunction = gDeviceControl;
gDriverObject->MajorFunction = gInternalDeviceControl;
gDriverObject->DriverUnload = gDriverUnload;
Oczywiście musimy dodać odpowiednie kontrole ważności wskaźników i tak dalej.
Teraz musisz zaimplementować prawidłowe ładowanie sterowników. Ponieważ system zabezpieczający z jakiegoś powodu może zakończyć swoją pracę przed naszym sterownikiem, aby uniknąć awarii systemu z powodu nieprawidłowych wskaźników, przetworzymy to zdarzenie w funkcji HookUnload:
void HookUnload(PDRIVER_OBJECT DrvObj)
Odczep urządzenie();
gDriverUnload(DrvObj);
Tutaj przywracane są pola struktury DRIVER_OBJECT, a kontrola przekazywana jest do oryginalnego kodu w celu wyładowania przechwyconego sterownika urządzenia.
Podobnie postępujemy, jeśli nasz sterownik zakończy pracę przed systemem zabezpieczającym. Wystarczy zwolnić przechwycone zasoby i nie wywoływać zapisanego gHookUnload.
Jak działa emulator
Znając podstawowe zasady najprostszego przechwytywania pakietów IRP, przejdźmy do implementacji samego przechwytywacza do dalszej analizy. W tym celu utworzymy obiekt sterownika zawierający symboliczną nazwę (na przykład DosDevicesHook) i punkty wejścia CREATE, CLOSE, READ.
IoCreateDevice(DriverObject, 0, &usDeviceName, FILE_DEVICE_NULL, 0, 0, &pDeviceObject);
IoCreateSymbolicLink(&usSymbolicDeviceName, &usDeviceName);
DriverObject->MajorFunction = DriverDispatch;
DriverObject->MajorFunction = DriverDispatch;
DriverObject->MajorFunction = DriverDispatch;
DriverObject->DriverUnload = DriverUnload;
Jest to konieczne, aby nasz przechwytywacz mógł pracować jako plik, korzystając z funkcji CreateFileReadFileCloseHandle. Przy takiej realizacji wymiany danych pomiędzy aplikacją a przechwytywaczem nie ma możliwości natychmiastowego przesłania ich do programu użytkownika, dlatego konieczne jest stworzenie jakiejś struktury przechowującej niezbędne dane o przechwyconym pakiecie. Na przykład pojedynczo połączona lista, zaimplementowana przeze mnie. Teraz musisz zdecydować, jakie informacje należy buforować. Są to ogólne informacje o pakiecie (typ, flagi itp.) i oczywiście o buforach. Możesz także dodać czas przechwytywania. Kopiując zawartość buforów trzeba pamiętać o ich typie, inaczej nastąpi awaria. Patrząc w przyszłość, zauważę, że sterownik zabezpieczający wykorzystuje buforowane wejścia/wyjścia, co nieco upraszcza kod.
HookWysyłkowy kod
if (idlTail->IrpData.InputLength)
{
idlTail->InputBuffer = ExAllocatePool(NonPagedPool, idlTail->IrpData.InputLength);
RtlCopyMemory(idlTail->InputBuffer, Irp->AssociatedIrp.SystemBuffer, idlTail->IrpData.InputLength);
}
if (IoSL->MajorFunction == IRP_MJ_DEVICE_Control)
Status = pHookedDriverDispatch(DeviceObject, Irp);
if (idlTail->IrpData.OutputLength)
{
idlTail->OutputBuffer = ExAllocatePool(NonPagedPool, idlTail->IrpData.OutputLength);
RtlCopyMemory(idlTail->OutputBuffer, lpBuffer, idlTail->IrpData.OutputLength);
}
Pozostaje tylko zaimplementować odczyt ze sterownika. Ponieważ pakiet zawiera bufory, których zawartość jest interesująca, rozmiar wiadomości nie jest z góry znany. Dlatego postępujemy w następujący sposób: w pierwszym czytaniu otrzymujemy informacje ogólne o pakiecie i rozmiarze buforów; powtarzając, czytamy zawartość, usuwamy link z listy pakietów i nie zapominamy o blokadach spinowych do sekwencyjnej pracy z danymi:
Kod wysyłkowy kierowcy
Długość = IoSL->Parametry.Długość odczytu;
if (Długość == rozmiar(IRP_DATA) && idlHead)
RtlCopyMemory(Irp->UserBuffer, &idlHead->IrpData, długość);
else if (idlHead && Długość == (idlHead->IrpData.InputLength + idlHead->IrpData.OutputLength))
{
RtlCopyMemory(Irp->UserBuffer, idlHead->InputBuffer, idlHead->IrpData.InputLength);
RtlCopyMemory((PVOID)((ULONG)Irp->UserBuffer + idlHead->IrpData.InputLength), idlHead->OutputBuffer, idlHead->IrpData.OutputLength);
}
else if (Długość == 1 && idlHead)
{
if (idlHead->Bufor wejściowy)
ExFreePool(idlHead->Bufor wejściowy);
if (idlHead->Bufor wyjściowy)
ExFreePool(idlHead->Bufor wyjściowy);
idlTemp = idlHead->ldlNext;
ExFreePool(idlHead);
idlHead = idlTemp;
jeśli (!idlTemp)
idlTail = NULL;
}
Gdy przechwytywacz będzie gotowy, najpierw go uruchamiamy, a następnie chronioną aplikację z kluczami i bez. Z otrzymanych logów staje się jasne, jakie kody kontrolne są wysyłane i jakie są ich wyniki. Można również zobaczyć, że żądania i odpowiedzi na dwa różne kody (9c402450, 9c4024a0) nie ulegają zmianie. Wydawać by się mogło, że da się zbudować emulator tabeli, jednak po serii uruchomień jesteśmy przekonani, że jest to niemożliwe, gdyż zawartość buforów jest różna i nie wiadomo w jaki sposób jest ona tworzona.
Przechwycone pakiety bez klucza
Przechwycone pakiety z kluczem
Następnie istnieje kilka opcji dalszych działań:
Obie opcje dają niezbędne informacje. Okazuje się więc, że zawartość pakietów jest szyfrowana przy użyciu publicznego algorytmu symetrycznego AES (Advanced Encryption Standard). Logicznym celem jest uzyskanie klucza szyfrującego.
Jeśli jednak zagłębimy się w badania nad projektem systemu bezpieczeństwa, okaże się, że klucz sprzętowy ma unikalny numer i zawiera wszystkie niezbędne informacje, ale aby uzyskać do niego dostęp, wymagane są klucze programowe.
Przykład zrzutu klucza
Dlatego pierwszą rzeczą, którą musisz zrobić, to zdobyć klucz. Problem można rozwiązać za pomocą prostej brutalnej siły:
krótki klucz bez znaku;
unsigned char RefKey, VerKey;
for (Klucz = 0; Klucz<= 0x7fff, Key++)
{
if (!HL_LOGIN(Klucz, 1, RefKey, VerKey))
{
HL_LOGOUT();
Przerwa;
}
}
Funkcje HL_LOGIN, HL_LOGOUT są dostępne z HASP SDK dla twórców aplikacji chronionych na tej platformie i mają następujące prototypy:
WORD HL_LOGIN(WORD ModAd, Word Access, bajt *RefKey, bajt *VerKey);
WORD HL_LOGOUT(void);
Pierwsza funkcja służy do otwarcia sesji pracy z kluczem zabezpieczającym za pomocą sterownika, druga kończy sesję. Są to prototypy starszych wersji pakietu HASP SDK, ale współpracują także z nowymi typami kluczy, gdyż twórcy zadbali o kompatybilność wsteczną.
Nowe API niewiele różni się od starego i nie wpływa to w żaden sposób na zasadę działania brute-force. Szczegółową dokumentację Hasp API, gotowe implementacje brute force i key dumper można znaleźć na stronie.
Teraz masz wszystko, czego potrzebujesz, aby moduł działał poprawnie. Pozostaje tylko wdrożyć zamianę informacji o licencji. Co więcej, tylko niektóre pakiety IRP mogą zostać przechwycone. Tutaj wszystko zależy od konkretnej wersji klucza i chronionego programu.
Lepiej nie osadzać zrzutu klucza w sterowniku, ale ładować go dynamicznie z rejestru. Lepiej polegać na gotowym przechwytywaczu żądań, ułatwi to debugowanie sterownika poprzez wysyłanie przechwyconych/podstawionych pakietów do analizy do aplikacji użytkownika. Zasadniczo logika przechwytywacza będzie wyglądać następująco:
NTSTATUS HookDispatch():
PIO_STACK_LOCATION Stos = Irp->Tail.Overlay.CurrentStackLocation;
Kod ULONG IoControl;
if (Stack->MajorFunction == 14)
{
IoControlCode = Stack.DeviceIoControl.IoControlCode;
Jeśli (IoControlCode!= 0x9c402458)
{
Zwróć gDeviceControl(DeviceObject, Irp);
}
w przeciwnym razie
{
Szyfruj(Irp->AssociatedIrp.SystemBuffer);
Crypt(Irp->AssociatedIrp.SystemBuffer, Key, DumpMemory);
}
}
Zwróć STATUS_FAILED;
Pakiet żądania sterownika jest szyfrowany, więc dostęp do jego zawartości wymaga odszyfrowania, a następnie zaszyfrowania. Powstaje pytanie: jaki algorytm i jaki klucz został użyty do szyfrowania? Po zagłębieniu się w kod źródłowy twórców systemu można uzyskać następujący podstawowy algorytm szyfrowania pakietów:
Zaszyfruj() kod
void Szyfruj (BAJT * Bufor)
{
SŁOWO Nasienie = ((SŁOWO)Bufor + 0x5e);
SŁOWO Ver = ((SŁOWO)Bufor + 0xba);
jeśli (wer.)
{
for (int i = 0; tj< 0xB9; i++) {
(SŁOWO)(Bufor + i) += Ziarno;
Nasienie = (Nasiono >> 15) | (Nasionko<< 1);
Nasienie -= (SŁOWO)(Bufor + i) ^ i;
}
for (int i = 0xBE; i< 0xFF; i++) {
(SŁOWO)(Bufor + i) -= Ziarno;
Nasienie = (Nasiono >> 15) | (Nasionko<< 1);
Nasienie += (SŁOWO)(Bufor + i) ^ i;
}
((SŁOWO)Bufor + 0xba) = Ziarno;
}
}
Można zauważyć, że algorytm jest znacznie bardziej złożony niż zwykłe przesunięcie i wyłączne „lub”. A oto algorytm deszyfrowania:
Odszyfruj kod()
void Odszyfruj (BAJT* Bufor)
{
SŁOWO Nasienie = ((SŁOWO)Bufor + 0x5e);
SŁOWO Ver = ((SŁOWO)Bufor + 0xba);
jeśli (wer) (
for (int i = 0xFE; i > 0xBD; i—) (
Nasienie -= (SŁOWO)(Bufor + i) ^ i;
Nasiona = (Nasiona<< 15) | (Seed >> 1);
(SŁOWO)(Bufor + i) += Ziarno;
}
for (int i = 0xB8; i >= 0; i—) (
Nasienie += (SŁOWO)(Bufor + i) ^ i;
Nasiona = (Nasiona<< 15) | (Seed >> 1);
(SŁOWO)(Bufor + i) -= Ziarno;
}
((SŁOWO)Bufor + 0xba) = Ziarno;
}
}
Następnie następuje kolejny etap konwersji danych, bardziej złożony i całkowicie zależny od struktury żądania. Nie da się tego zrobić bez dezasemblera; będziesz musiał sięgnąć do kosza i pożyczyć trochę kodu od twórców. Nie jest to łatwe, ponieważ kod sterownika bezpieczeństwa jest mocno zaciemniony, ale nie ma w nim wielu sztuczek. Wystarczy nie całkowicie zdekompilować sterownik, a jedynie niektóre fragmenty kodu.
Podsumowując, zauważam, że zbudowanie emulatora tabeli opartego na przechwytywaniu DeviceIoControl jest zadaniem dość trudnym. Ale tę zasadę emulatora można zastosować na innym poziomie interakcji: do stworzenia wirtualnej magistrali USB.
To nie jedyny sposób na pozbycie się systemu bezpieczeństwa. Istnieją inne, bardziej zaawansowane metody. Zaprezentowane w artykule zasady można wykorzystać także do analizy działania sterowników przechwytujących pakiety IRP. W ten sposób możesz dodać dobre narzędzie do swojego zestawu wykonanego na kolanie. Powodzenia!
Bezpieczeństwo dowolnego algorytmu kryptograficznego zależy od użytego klucza kryptograficznego. Dobre klucze kryptograficzne muszą mieć odpowiednią długość i losowe wartości bitów. W tabeli 4.3 pokazuje długości kluczy symetrycznych i asymetrycznych kryptosystemów, zapewniających taką samą odporność na atak brute-force (atak brute-force).
Aby uzyskać klucze, wykorzystuje się sprzęt i oprogramowanie do generowania losowych wartości kluczy. Z reguły stosowane są czujniki liczb pseudolosowych (PRN). Jednakże stopień losowości w generowaniu liczb musi być dość wysoki. Idealne generatory to urządzenia bazujące na „naturalnych” procesach losowych, np biały szum radiowy.
W sieci o średnich wymaganiach bezpieczeństwa całkiem akceptowalne są programowe generatory kluczy, które obliczają PRSP jako złożoną funkcję aktualnego czasu i (lub) liczby wprowadzonej przez użytkownika.
Jedną z metod generowania klucza sesyjnego dla symetrycznych kryptosystemów opisano w standardzie ANSI X9.17. Zakłada zastosowanie algorytmu kryptograficznego DES (chociaż można zastosować inne algorytmy szyfrowania symetrycznego).
Oznaczenia:
E K (X) – wynik szyfrowania wartości X algorytmem DES;
K – klucz zarezerwowany do generowania tajnych kluczy;
V 0 – tajne ziarno 64-bitowe;
T – znacznik czasu.
Schemat generowania losowego klucza sesyjnego R i zgodnie ze standardem ANSI X 9.17 pokazano na ryc. 7.1. Losowy klucz R i jest generowany poprzez obliczenie wartości
R ja = mi K (E K (T i) Å V i).
Rysunek 7.1 – Schemat generowania losowego klucza R i zgodnie
z normą ANSI X9.17
Następną wartość V i+1 oblicza się w następujący sposób:
V i+1 = mi K (E K (T i) Å R i).
Jeśli potrzebny jest 128-bitowy klucz losowy, wygeneruj parę kluczy Ri, R i + 1 i połącz je ze sobą.
Jeśli klucz nie będzie regularnie zmieniany, może to doprowadzić do jego ujawnienia i wycieku informacji. Regularną wymianę klucza można przeprowadzić, korzystając z procedury modyfikacji klucza.
Kluczowa modyfikacja to generowanie nowego klucza z poprzedniej wartości klucza za pomocą funkcji jednokierunkowej (jednokierunkowej). Uczestnicy wymiany informacji mają ten sam klucz i jednocześnie wprowadzają jego wartość jako argument do funkcji jednokierunkowej, uzyskując ten sam wynik. Następnie pobierają określone bity z tych wyników, aby utworzyć nową wartość klucza.
Procedura modyfikacji klucza jest wykonalna, ale musimy o tym pamiętać nowy klucz jest bezpieczny w takim samym stopniu, jak poprzedni klucz był bezpieczny. Jeśli atakującemu uda się zdobyć poprzedni klucz, wówczas będzie mógł przeprowadzić procedurę modyfikacji klucza.
Generowanie kluczy dla asymetrycznych kryptosystemów za pomocą klucze publiczne znacznie bardziej skomplikowane, ponieważ te klucze muszą mieć pewne właściwości matematyczne (muszą być bardzo duże i proste itp.).
Gdzie są drzwi
Problemy ochrony oprogramowania przed piracką dystrybucją lub ochrony danych przed nieuprawnionym kopiowaniem nieuchronnie pojawiają się na całym świecie, powodując wiele kłopotów dla producentów oprogramowania i opiekunów poufnych danych. Naturalnie rozwiązanie tych problemów nie obędzie się bez dodatkowych niedogodności, jakie sprawiają zwykłym użytkownikom. Obecnie wszystkie metody ochrony oprogramowania lub danych można podzielić na dwie główne grupy:
Jeden z najskuteczniejszych i wygodne sposoby zabezpieczeniem jest zastosowanie kluczy sprzętowych - małych mikro urządzenia elektryczne, bez którego program nie zostanie uruchomiony, a dane nie zostaną odszyfrowane.
Zasada działania systemów wykorzystujących sprzętowe klucze zabezpieczające (przynajmniej zewnętrznie) jest w przybliżeniu taka sama: program uzyskuje dostęp do określonego urządzenia i w odpowiedzi otrzymuje kod, który pozwala mu uruchomić określoną funkcję lub odszyfrować dane. W przypadku braku klucza program albo w ogóle nie działa, albo działa w trybie demonstracyjnym (wyłączona jest jakakolwiek funkcjonalność, nie są odczytywane dane itp.). Ponadto takie urządzenie samo w sobie może zawierać pamięć nieulotną, w której przechowywane są dane lub fragmenty kodu.
Z elektronicznymi „odcinkami” można pracować zarówno lokalnie, jak i w wersji sieciowej. W przypadku korzystania z klucza sieciowego nie ma potrzeby instalowania kluczy lokalnych na każdym z nich Miejsce pracy. Licencjonowanie w w tym przypadku realizowane za pomocą jednego klucza z serwera oprogramowania, który przetwarza żądania z chronionych aplikacji. Przykładowo, jeśli na serwerze zainstalowany jest klucz i obsługujący go sterownik (mały program obsługujący klucz jest wygodnie rejestrowany w Windows NT/2000/XP jako usługa uruchamiana przy starcie systemu, a w Windows 95/98/Me jako usługa program rezydentny), wówczas dowolny zdalny program może zażądać licencji od serwera i dopiero po jej otrzymaniu może kontynuować pracę. Można konkretnie ustawić liczbę licencji dla każdego klucza i w zależności od tego, dla ilu jednocześnie uruchomionych kopii przeznaczony jest zakupiony program, zostanie on uruchomiony lub nie. W tym przypadku dystrybucja licencji odbywa się z reguły według prostej zasady: „jeden komputer – jedna licencja”. Oznacza to, że jeśli na danym komputerze uruchomionych jest kilka kopii aplikacji, to zostanie na to przydzielona tylko jedna licencja. Tym samym istnieje ograniczenie liczby stanowisk roboczych, z których można jednocześnie korzystać z programu.
Do niewątpliwych zalet tej metody ochrony należy jej prostota i niezawodność. Ponadto takie zabezpieczenie natychmiast odstraszy niedoświadczonych użytkowników od nieautoryzowanych działań. Wadą takiego systemu jest konieczność zainstalowania specjalnych sterowników do klucza wraz z programem, a także zadbania o sam klucz i, w razie potrzeby, noszenie go przy sobie. Dodatkowo dodatkowe ograniczenia na tego typu zabezpieczenia może nałożyć obecność lub brak wymaganego portu lub czytnika kart inteligentnych, a także możliwe problemy sprzętowe przy interakcji z innymi urządzeniami korzystającymi do swojego działania z tego samego portu.
Naturalnie, należy chronić w ten sposób swój program lub dane tylko wtedy, gdy ich koszt (lub wartość niematerialna) jest porównywalny z ceną sprzętowego klucza zabezpieczającego (nawet najbardziej prymitywny podobny klucz do portu równoległego kosztuje około 10 dolarów).
Poza tym prawda życiowa jest taka, że w żadnym podejściu nie można w zasadzie mówić o ochronie absolutnej. Aby aplikacja była niemożliwa do zhakowania, konieczne byłoby całkowite wykluczenie jakiegokolwiek dostępu do niej. Dlatego stopień bezpieczeństwa musi być adekwatny do zagrożenia. Jak podpowiada zdrowy rozsądek, im trudniejszy jest dostęp do aplikacji lub danych, tym mniej wygodna jest praca. Dobrze zbudowany system bezpieczeństwa jest w stanie wytrzymać włamanie na poziomie, na jaki może być podatny, i nie więcej.
Klucz elektroniczny to urządzenie przeznaczone do ochrony programów i danych przed nieuprawnionym użyciem, kopiowaniem i replikacją. Jest to z reguły małe urządzenie mikroelektroniczne, które posiada dwa złącza: jedno z nich przeznaczone jest do podłączenia do portu równoległego lub szeregowego komputera, a drugie służy do podłączenia drukarki, modemu lub innego urządzenia współpracującego z komputerem. tego portu. W takim przypadku klucz nie powinien wpływać na działanie portu i powinien być całkowicie „przezroczysty” dla podłączonych przez niego urządzeń (czyli nie powinien zakłócać ich normalnej pracy). Istnieją jednak inne rodzaje kluczy do różnych portów i w różnych wersjach (wewnętrzne, zewnętrzne, w formie breloczka, w postaci PCMCIA lub karty inteligentnej itp.). Klucze mogą pracować kaskadowo, gdy do jednego portu podłączonych jest jednocześnie kilka kluczy, w tym różnych typów. Protokół wymiany danych pomiędzy kluczem a portem jest zwykle zmieniany dynamicznie, kodowany i „zaszumiony” w celu zabezpieczenia przed emulacją.
Wiele nowoczesne typy Klucze wyposażone są w elektrycznie programowalną pamięć nieulotną. Zazwyczaj klucz sprzętowy nie posiada wbudowanych źródeł zasilania, jest całkowicie pasywny i po odłączeniu od komputera zachowuje zapisane w nim informacje. Jednak modyfikacje z wbudowanym zegarem i autonomiczna bateria moc, która pozwala budować różne modele sprzedaż, wynajem, leasing i licencjonowanie chronionego oprogramowania. Możliwości intelektualne i fizyczne klucza w dużej mierze zależą od podstawy, na której jest on wykonany.
W oparciu o sprzęt nowoczesne klucze można podzielić na następujące typy:
Ze względu na wygląd zewnętrzny największą popularnością cieszą się klucze produkowane w formie breloków do podłączania do portów USB.
Dodatkowe informacje na temat konstrukcji i działania kluczy zabezpieczających można znaleźć na rosyjskiej stronie internetowej (http://www.aladdin.ru/) firmy Aladdin Knowledge Systems (http://www.aks.com/), twórcy system ochrony HASP.
Jak zabezpieczyć aplikację za pomocą klucza elektronicznego?
Taki klucz może zapewniać kilka poziomów i metod ochrony programów i danych. Najprostszą metodą jest automatyczna ochrona, polegająca na dołączeniu klucza do gotowych programów za pomocą specjalnego narzędzia za pomocą zaledwie kilku kliknięć myszką. Jednakże moduł autoochrony zaimplementowany w programie nie może tworzyć z nim jednej całości, dlatego istnieje niebezpieczeństwo, że hakerowi uda się oddzielić moduł autoochrony od aplikacji.
Więcej złożone metody opierają się na wykorzystaniu specjalizowanego API, które producenci kluczy elektronicznych dostarczają twórcom chronionego oprogramowania. Funkcje tego interfejsu API służą do wykonywania różnych operacji w celu interakcji programu z kluczem: wyszukiwanie wymagany kod, odczyt/zapis pamięci klucza sprzętowego, uruchamianie algorytmów sprzętowych klucza sprzętowego i konwertowanie kodu aplikacji i danych przy ich użyciu.
W celu dodatkowej kontroli nad dystrybucją oprogramowania klucze elektroniczne umożliwiają przechowywanie unikalnych numerów – może to być numer rejestracyjny użytkownika lub numer wersji oprogramowania. Co więcej, system bezpieczeństwa można zbudować w taki sposób, aby z tym kluczem mogły współpracować tylko te aplikacje, których numery wersji nie przekraczają wartości zapisanej w kluczu, a przy pomocy zdalnego programowania można w to pole wpisać nowe informacje, które będą upewnij się, że aktualizowane są tylko legalni, zarejestrowani użytkownicy.
Ponadto klucze mogą nakładać różne ograniczenia na korzystanie z chronionych aplikacji, w wyniku czego można ograniczyć czas korzystania z programów lub danych, a także liczbę uruchomień aplikacji lub modułu. W tym celu w pamięci klucza sprzętowego zorganizowany jest specjalny licznik, którego wartość może się zmniejszać w określonych odstępach czasu lub przy każdym uruchomieniu aplikacji. W ten sposób możesz dostarczać wersje demonstracyjne lub limitowane aplikacji, a płacąc lub zmieniając warunki umowy, możesz usunąć ograniczenia poprzez zdalne programowanie kluczy.
Http://glasha.zap.to/ Emulatory klucza HASP są oferowane każdemu).
A co jeśli mówimy o O oprogramowanie, to znacznie skuteczniejsze jest zwalczanie piractwa dobra obsługa pomoc techniczna i przechowuj tajne dane w bezpiecznym miejscu...
ComputerPress 3” 2002
Do zwalczania piractwa komputerowego wykorzystuje się także specjalne oprogramowanie, sprzęt i oprogramowanie. Polegają one na wykorzystaniu urządzeń elektronicznych podłączanych albo do wewnętrznej magistrali komputera, albo do jego zewnętrznych złączy. Jeśli oceniamy stopień niezawodności ochrony na podstawie ilości pracy potrzebnej do jej „złamania”, to sprzęt i oprogramowanie są „silniejsze” niż czyste oprogramowanie.
Rzeczywiście, aby ujawnić taką obronę, nie wystarczy rozwikłać sztuczki w programie. Konieczne jest przywrócenie protokołów i treści wymiany programów z dodatkowym sprzętem. Rozwiązanie tych problemów zwykle wymaga użycia specjalnego sprzętu, takiego jak analizatory logiczne.
Klucz elektroniczny to kompaktowe urządzenie, które podłącza się do portów równoległych lub szeregowych komputera i nie wpływa na interakcję komputera z nim urządzenia zewnętrzne. Ideą ochrony kluczem elektronicznym jest wykorzystanie specjalnego algorytmu interakcji z kluczem w chronionym programie, który nie pozwala na wykonanie programu bez niego. W takim przypadku do każdej kopii programu dołączony jest klucz elektroniczny. Kryteria oceny jakości klucza elektronicznego: klucz musi być jakimś generatorem funkcji, a nie tylko pamięcią stałych; klucz musi być wykonany w oparciu o niestandardowy układ scalony, co wyklucza możliwość jego legalnego zwielokrotnienia.
Klucze elektroniczne mogą służyć do rozwiązywania następujących zadań:
1. Programy są chronione na dwa sposoby. Pierwsza metoda (nazwijmy ją ręczną) polega na tym, że programista sam włącza do swojego programu fragmenty, które wchodzą w interakcję z kluczem elektronicznym. Druga metoda opiera się na automatyczne włączenie do chronionego pliku wymiany za pomocą klucza. W takim przypadku specjalny program dostarczany wraz z kluczem automatycznie przetwarza pliki wykonywalne w taki sposób, że bez klucza nie będą one mogły działać. Korzyść automatyczna ochrona przed instrukcją jest prawie zerowa pracochłonność tej procedury. Dodatkowo program automatycznej ochrony tworzony jest przez wysoko wykwalifikowanych specjalistów, co zapewnia jego większą niezawodność.
2. Ochrona danych przed ujawnieniem zawartych w nich informacji następuje poprzez szyfrowanie. Jest wystarczająco dużo skuteczne metody szyfrowanie, takie jak algorytm DES. Jednakże bezpieczeństwo szyfrowania nie może być wyższe niż bezpieczne przechowywanie i przesyłanie klucza szyfrującego. W tym przypadku klucza szyfrującego nie trzeba zapamiętywać, zapisywać i co bardzo ważne, nie trzeba go wprowadzać do komputera z klawiatury. Dane przechowywane na komputerze można odszyfrować tylko wtedy, gdy dostępny jest klucz. Dodatkowo, aby zwiększyć niezawodność, sam program szyfrujący/deszyfrujący może być chroniony przy użyciu tego samego klucza.
3. Ochrona komputera przed osobami niepowołanymi polega na pobieraniu system operacyjny wyłącznie dla uprawnionych użytkowników, a także zapewnienie każdemu użytkownikowi dostępu jedynie do przydzielonych mu zasobów, do których mogą należeć dyski logiczne, katalogi i pojedyncze pliki. Wdrożenie takiego zabezpieczenia wiąże się z identyfikacją użytkownika. Można do tego wykorzystać klucze elektroniczne. W tym przypadku możliwe są dwa podejścia.
Pierwsze podejście zakłada, że każdy uprawniony użytkownik dysponuje unikalnym kluczem elektronicznym. Rozpoznawanie użytkownika odbywa się bez podawania haseł po podłączeniu klucza do złącza. W tym przypadku można postawić tezę, że klucz do tajemnic użytkownika trzymany jest w jego kieszeni. Ale jeśli w organizacji używany jest komputer, administracja z reguły chce mieć dostęp do wszystkich plików i kontrolować pracę wszystkich użytkowników. Aby to zrobić, musisz mieć co najmniej dwa identyczne zestawy kluczy, z których jeden jest przechowywany przez kierownika organizacji.
Drugie podejście zmniejsza koszty ochrony poprzez użycie tylko jednego klucza dla wszystkich użytkowników. Kluczem zarządza administrator systemu wyznaczony przez kierownictwo organizacji. System operacyjny można załadować tylko po podłączeniu klucza sprzętowego. Identyfikacja użytkownika odbywa się poprzez podanie hasła.
Pytania autotestowe
Integralność danych odnosi się do systemu reguł Microsoft Access, który pozwala w przypadku zmiany jednego obiektu na automatyczną zmianę wszystkich powiązanych obiektów i zapewnia ochronę przed przypadkowym usunięciem lub modyfikacją powiązanych danych.
Listę wartości można określić albo za pomocą stałego zestawu wartości wprowadzanych przez użytkownika podczas tworzenia pola, albo za pomocą listy wartości z tabeli referencyjnej lub zapytania.
Indeks to narzędzie Microsoft Access, które przyspiesza wyszukiwanie i sortowanie w tabeli. Pole kluczowe tabeli jest indeksowane automatycznie. Nie można tworzyć indeksów w polach MEMO i Hiperłącze ani w polach obiektów OLE.
Indeks unikalny to indeks zdefiniowany dla właściwości Pole indeksowane o wartości „Tak (niedozwolone dopasowania)”. W takim przypadku wprowadzenie zduplikowanych wartości do pola indeksowanego staje się niemożliwe. Dla pól kluczowych tworzony jest automatycznie unikalny indeks.
