Elektronisk nøgle (også hardwarenøgle , nogle gange dongle fra engelsk dongle ) - et hardwareværktøj designet til at beskytte software (software) og data mod kopiering, ulovlig brug og uautoriseret distribution.
Grundlaget for denne teknologi er et specialiseret mikrokredsløb eller en mikrocontroller beskyttet mod læsning , som har unikke betjeningsalgoritmer for hver nøgle . Dongles har også en beskyttet ikke-flygtig hukommelse med et lille volumen, mere komplekse enheder kan have en indbygget kryptoprocessor (til hardwareimplementering af krypteringsalgoritmer ), et realtidsur. Hardwaredongler kommer i en række forskellige formfaktorer , men er oftest forbundet til en computer via USB . Findes også med LPT , SOIC eller PCMCIA interfaces.
Nøglen er knyttet til en specifik computergrænseflade . Yderligere sender det beskyttede program information til det gennem en speciel driver , som behandles i overensstemmelse med den specificerede algoritme og returneres tilbage. Hvis svaret på nøglen er korrekt, fortsætter programmet sit arbejde. Ellers kan den udføre udviklerdefinerede handlinger, såsom at skifte til demotilstand, blokere adgang til visse funktioner.
Der er specielle nøgler, der er i stand til at licensere (begrænser antallet af kopier af programmet, der kører på netværket) en beskyttet applikation over netværket. I dette tilfælde er én nøgle nok til hele det lokale netværk . Nøglen er installeret på enhver arbejdsstation eller netværksserver . Beskyttede applikationer får adgang til donglen via det lokale netværk. Fordelen er, at for at kunne arbejde med applikationen inden for det lokale netværk, behøver de ikke at have en dongle med sig.
Beskyttelse af software mod ulicenseret brug øger udviklerens fortjeneste. Til dato er der flere tilgange til at løse dette problem. Langt de fleste softwareudviklere anvender forskellige softwaremoduler, der styrer brugeradgang ved hjælp af aktiveringsnøgler, serienumre osv. En sådan beskyttelse er en billig løsning og kan ikke hævdes at være pålidelig. Internettet er fyldt med programmer, der giver dig mulighed for ulovligt at generere en aktiveringsnøgle ( nøglegeneratorer ) eller blokere en anmodning om et serienummer/aktiveringsnøgle ( patches , cracks ). Derudover må du ikke glemme, at den lovlige bruger selv kan offentliggøre sit serienummer.
Disse åbenlyse mangler førte til skabelsen af hardwaresoftwarebeskyttelse i form af en elektronisk nøgle. Det er kendt, at de første elektroniske nøgler (det vil sige hardwareenheder til beskyttelse af software mod ulovlig kopiering) dukkede op i begyndelsen af 1980'erne, men af indlysende årsager er det meget vanskeligt at etablere forrang i ideen og direkte skabelse af enheden.
Dongler er klassificeret som hardware-baserede softwarebeskyttelsesmetoder, men moderne dongler er ofte defineret som multiplatform hardware-softwareværktøjssystemer til softwarebeskyttelse. Faktum er, at ud over selve nøglen leverer virksomheder, der udsteder elektroniske nøgler, et SDK (Software Developer Kit - software developer kit). SDK'et inkluderer alt hvad du behøver for at begynde at bruge den præsenterede teknologi i dine egne softwareprodukter - udviklingsværktøjer, komplet teknisk dokumentation , support til forskellige operativsystemer , detaljerede eksempler, kodefragmenter , automatiske beskyttelsesværktøjer. SDK'et kan også inkludere demonøgler til byggetestprojekter.
Teknologien til beskyttelse mod uautoriseret brug af software er baseret på implementering af anmodninger fra en eksekverbar fil eller et dynamisk bibliotek til en nøgle med efterfølgende modtagelse og om nødvendigt analyse af svaret. Her er nogle typiske forespørgsler:
Det er værd at bemærke, at nogle moderne nøgler (Guardant Code fra Aktiv, Sentinel fra Thales, LOCK fra Astroma Ltd., Rockey6 Smart fra Feitian, Senselock fra Seculab) tillader udvikleren at gemme deres egne algoritmer eller endda separate dele af applikationskoden ( for eksempel specifikke udvikleralgoritmer, der modtager et stort antal parametre som input) og udfører dem i nøglen på sin egen mikroprocessor . Ud over at beskytte software mod ulovlig brug giver denne tilgang dig mulighed for at beskytte den algoritme, der bruges i programmet, mod at blive studeret, klonet og brugt i dets applikationer af konkurrenter. For en simpel algoritme (og udviklere begår ofte den fejl at vælge en utilstrækkeligt kompleks algoritme til at indlæse), kan krypteringsanalyse udføres ved hjælp af black box-analysemetoden.
Som det følger af ovenstående, er "hjertet" af den elektroniske nøgle konverteringsalgoritmen (kryptografisk eller anden). I moderne dongler er det implementeret i hardware - dette udelukker praktisk talt oprettelsen af en fuld nøgleemulator , da krypteringsnøglen aldrig overføres til dongleudgangen, hvilket udelukker muligheden for dens aflytning.
Krypteringsalgoritmen kan være hemmelig eller offentlig. Hemmelige algoritmer er udviklet af producenten af beskyttelsesudstyr, herunder individuelt for hver kunde. Den største ulempe ved at bruge sådanne algoritmer er umuligheden af at vurdere kryptografisk styrke . Det var kun muligt at sige med sikkerhed, hvor pålidelig algoritmen var bagefter: om den var hacket eller ej. En offentlig algoritme, eller "open source", har en uforlignelig større kryptografisk styrke. Sådanne algoritmer testes ikke af tilfældige mennesker, men af en række eksperter, der er specialiserede i analyse af kryptografi . Eksempler på sådanne algoritmer er den meget brugte GOST 28147-89 , AES , RSA , Elgamal osv.
For de fleste familier af hardware-dongles er der udviklet automatiske værktøjer (inkluderet i SDK'et ), der giver dig mulighed for at beskytte programmet "med et par museklik". I dette tilfælde er applikationsfilen "indpakket" i udviklerens egen kode. Funktionaliteten implementeret af denne kode varierer afhængigt af producenten, men oftest kontrollerer koden for tilstedeværelsen af en nøgle, kontrollerer licenspolitikken (sat af softwareleverandøren), implementerer en mekanisme til at beskytte den eksekverbare fil mod fejlretning og dekompilering ( for eksempel at komprimere den eksekverbare fil) osv.
Det vigtige er, at du ikke behøver adgang til applikationens kildekode for at bruge det automatiske beskyttelsesværktøj . For eksempel, når du lokaliserer udenlandske produkter (når der ikke er mulighed for at forstyrre softwarekildekoden), er en sådan beskyttelsesmekanisme uundværlig, men den tillader ikke at bruge det fulde potentiale af elektroniske nøgler og implementere fleksibel og individuel beskyttelse.
Udover at bruge automatisk beskyttelse, får softwareudvikleren mulighed for selvstændigt at udvikle beskyttelse ved at integrere beskyttelsessystemet i applikationen på kildekodeniveau. For at gøre dette inkluderer SDK'et biblioteker for forskellige programmeringssprog, der indeholder en beskrivelse af API -funktionaliteten for denne nøgle. API'en er et sæt funktioner designet til at udveksle data mellem applikationen, systemdriveren (og serveren i tilfælde af netværksdongler) og selve donglen. API-funktioner giver forskellige operationer med nøglen: søgning, læsning og skrivning af hukommelse, kryptering og dekryptering af data ved hjælp af hardwarealgoritmer, licensering af netværkssoftware osv.
Dygtig anvendelse af denne metode giver et højt niveau af applikationssikkerhed. Det er ret svært at neutralisere beskyttelsen, der er indbygget i applikationen på grund af dens unikke karakter og "fuzziness" i programmets krop. I sig selv er behovet for at studere og ændre den eksekverbare kode for en beskyttet applikation for at omgå beskyttelsen en alvorlig hindring for at bryde den. Derfor er sikkerhedsudviklerens opgave først og fremmest at beskytte mod mulige automatiserede hackingmetoder ved at implementere deres egen beskyttelse ved hjælp af API'et til at arbejde med nøgler.
Angriberens opgave er at tvinge det beskyttede program til at fungere i mangel af en juridisk nøgle forbundet til computeren. Uden at gå i for mange tekniske detaljer, vil vi antage, at angriberen har følgende muligheder:
Sådanne brede kapaciteter hos fjenden kan forklares ved, at han har adgang til alle åbne grænseflader , dokumentation , drivere og kan analysere dem i praksis ved hjælp af alle midler.
For at få programmet til at fungere, som det ville med nøglen, kan du enten lave rettelser til programmet ( hacke dets programmodul ), eller efterligne tilstedeværelsen af nøglen ved at opsnappe opkald til nøgleudvekslings API-biblioteket.
Det skal bemærkes, at moderne elektroniske nøgler (for eksempel Guardant- nøgler fra Sign-generationen og moderne HASP HL-nøgler) giver stærk kryptering af den elektroniske nøgleudvekslingsprotokol - API-biblioteket til at arbejde med nøglen . Som følge heraf er de mest sårbare steder kaldepunkterne for funktionerne i denne API i applikationen og logikken til at behandle deres resultat.
Under emulering sker der ingen indvirkning på programkoden, og emulatoren, hvis den kan bygges, gentager simpelthen al opførsel af den rigtige nøgle. Emulatorer er bygget baseret på analysen af opsnappede applikationsanmodninger og nøglens svar på dem. De kan enten være i tabelform (indeholde alle svar på anmodninger til den elektroniske nøgle, der er nødvendige for, at programmet kan fungere), eller komplette (de efterligner fuldstændigt betjeningen af nøglen, da hackerne er blevet opmærksomme på den interne algoritme for arbejdet).
At bygge en komplet emulator af en moderne elektronisk nøgle er en ret besværlig proces, der kræver meget tid og betydelige investeringer. Tidligere har angribere været i stand til at gøre dette: for eksempel indrømmer Aladdin, at angribere i 1999 formåede at udvikle en nogenlunde korrekt fungerende HASP3- og HASP4-dongleemulator. Dette blev gjort muligt, fordi nøglen brugte en proprietær krypteringsalgoritme , som blev hacket. Nu bruger de fleste nøgler offentlige kryptografiske algoritmer, så angribere foretrækker at angribe et specifikt beskyttet produkt frem for en generel forsvarsmekanisme. Der er ingen frit tilgængelige emulatorer til moderne HASP- og Guardant- beskyttelsessystemer, da der bruges et offentligt nøglekryptosystem .
Der var ingen information om den fulde emulering af moderne Guardant-dongler . Eksisterende tabelemulatorer implementeres kun til specifikke applikationer. Muligheden for deres oprettelse skyldtes ikke-brug (eller analfabet brug) af de vigtigste funktionaliteter af elektroniske nøgler af beskyttelsesudviklere.
Der er heller ingen information om fuld eller i det mindste delvis emulering af LOCK-nøgler eller om andre måder at omgå denne beskyttelse.
En angriber undersøger selve programmets logik for, efter at have analyseret hele applikationskoden, at isolere beskyttelsesblokken og deaktivere den. At bryde programmer udføres ved at fejlsøge (eller steppe), dekompilere og dumpe hovedhukommelsen . Disse metoder til at analysere den eksekverbare kode for et program bruges oftest af angribere i kombination.
Debugging udføres ved hjælp af et specielt program - en debugger, som giver dig mulighed for at udføre enhver applikation trin for trin og emulere driftsmiljøet for det. En vigtig funktion af en debugger er evnen til at sætte punkter (eller betingelser) for at stoppe kodeeksekvering. Ved at bruge dem er det nemmere for en angriber at spore de steder i koden, hvor adgangen til nøglen er implementeret (for eksempel stopper eksekveringen på en meddelelse som "Nøglen mangler! Tjek for tilstedeværelsen af nøglen i USB-grænsefladen" ).
Demontering er en måde at konvertere koden for eksekverbare moduler til et menneskeligt læsbart programmeringssprog - Assembler . I dette tilfælde får angriberen en udskrift ( liste ) af, hvad applikationen laver.
Dekompilering er transformationen af en applikations eksekverbare modul til en sprogprogramkode på højt niveau og opnåelse af en repræsentation af applikationen, der er tæt på kildekoden. Det kan kun gøres for nogle programmeringssprog (især for .NET-applikationer, der er oprettet i C# og distribueret i bytecode , et relativt højt niveau fortolket sprog).
Essensen af angrebet ved hjælp af et hukommelsesdump er at læse indholdet af RAM i det øjeblik, hvor applikationen begyndte at køre normalt. Som et resultat modtager angriberen arbejdskoden (eller den del af interesse for ham) i en "ren form" (hvis f.eks. applikationskoden blev krypteret og kun dekrypteres delvist under udførelsen af en bestemt sektion) . Det vigtigste for en angriber er at vælge det rigtige øjeblik.
Bemærk, at der er mange måder at modvirke fejlfinding på, og sikkerhedsudviklere bruger dem: ikke-lineær kode, ( multithreading ), ikke-deterministisk udførelsessekvens, kode "affald" (ubrugelige funktioner, der udfører komplekse operationer for at forvirre angriberen), ved at bruge ufuldkommenhederne i selve debuggerne og andre