Problembeskrivelse

Lad os antage et par antagelser. Software er opdelt i funktionelle komponenter. Licenser er til funktionelle komponenter inden for denne softwarepakke. Licenser kan baseres på tid, på version eller på et antal anvendelser, dvs. du kan bruge funktionaliteten indtil et sæt tid, du kan muligvis funktionaliteten i den version, du har købt, eller noget mindre afledt af den, eller du kan bruge den en antal gange. Der er to hovedscenarier, du skal løse, hvor en angriber ikke har adgang til en licens, og hvor han har.

Angriber uden licens

Det første scenario er, hvor din hacker ikke har adgang til en gyldig licens til dit produkt. Dette problem er let at løse. Du skal blot tildele en separat krypteringsnøgle til hver af de funktionelle licenserede dele af din software. Krypter hver funktionel del med krypteringsnøglen designet til den del. Nu kan du distribuere din software uden bekymring for, at nogen kan dekryptere funktioner, som de ikke har licens, da du aldrig sender dem nøglen.

Angriber med adgang til licens

Det andet scenario, som er meget sværere at løse, er når din hacker har en gyldig licens til din software, men han enten ønsker at omfordele de funktioner, han har licens, eller at udvide sin licens tidsmæssigt.

Nu har du brug for en pålidelig tidskilde, dette kan løses ved:

• at integrere en offentlig nøgle i en dongle og lade donglen udgive en tilfældig udfordring, som skal sendes til en tidsserver. Tidsserveren reagerer ved at underskrive det aktuelle tidspunkt og udfordringen og returnere den til klienten, som derefter sender den til nøglen, og nøglen opdaterer derefter sit interne ur og låses op.
• opdatering af det interne ur baseret på gang den er tilsluttet computeren. USB-porten leverer strøm til din dongle hele tiden, mens den er tilsluttet.
• opdatering af det interne ur baseret på tidsstempler sendt fra drivere installeret på maskinen, det er knyttet til. Tillad kun tidsstempler fremad i tiden. Tillad kun bevægelse baglæns i tiden, hvis tidskilden er en ekstern pålidelig tidsserver, der leverer en underskrevet tidsstempel.

Hvis din licens er baseret på versioner, har du faktisk et angreb, der ikke har adgang til en licens, fordi din nøgleafledningsfunktion for den funktionelle enhed tager både identifikatoren for den funktionelle enhed og versionen af ​​den som input.

Nøgledistribution

Så når du har separate nøgler til hver funktionel enhed, bliver dine licenser stort set et spørgsmål om at distribuere symmetriske nøgler, så de kan sendes til donglen. Dette gøres normalt ved at integrere en hemmelig symmetrisk nøgle i donglen, kryptere licensdekrypteringsnøglerne med den delte hemmelige nøgle og derefter underskrive de krypterede nøgleopdateringsfiler. De underskrevne opdateringsfiler sendes derefter til donglen, der validerer signaturen på opdateringen, dekrypterer de nye nøgler med den delte symmetriske nøgle og gemmer dem til senere brug.

Nøgleopbevaring

Alle dongler skal have adgang til sikker opbevaring for at kunne gemme licensdekrypteringsnøgler, udløbstidsstempler og så videre. Generelt implementeres dette ikke på ekstern flashhukommelse eller EEPROM. Hvis det er, skal det krypteres med en intern nøgle til ASIC eller FPGA og underskrives således, at den ikke kan ændres.

Almindelig teksthul

Når brugeren har en licens til din funktionelle komponent, selvom han ikke kan udtrække din hemmelige nøgle, kan han bruge din dongle til at dekryptere den funktionelle komponent. Dette fører til problemet, at han muligvis udtrækker al din almindelig tekst og erstatter dekrypteringsopkaldet med et direkte opkald til den udpakkede almindelige tekst. Nogle dongler dækker dette problem ved at integrere en processor i donglen. Den funktionelle komponent sendes derefter krypteret til donglen, der dekrypterer komponenten og udfører den internt. Dette betyder, at donglen i det væsentlige bliver en sort boks, og at de funktionelle komponenter, der sendes til donglen, skal undersøges individuelt for at finde deres egenskaber.

Orakler

Mange dongler er krypterings- og dekrypteringsorakler, hvilket fører til potentielle problemer med Valgte ciphertext-angreb, f.eks. De nylige padding-oracle-angreb.

Sidekanalangreb

Udover oracle-problemerne har du også en masse bekymringer med alle de hidtil kendte sidekanalangreb. Du skal også være bekymret over enhver potentiel, men uopdaget sidekanal.

Dekapsulation

Vær opmærksom på, at der er en række virksomheder i verden, der specialiserer sig ved plukning og revision af sikre chips. Nogle af de mest kendte virksomheder er sandsynligvis Chris Tarnovsky fra flylogic, nu en del af IOActive og chipworks. Denne form for angreb er dyrt, men kan være en reel trussel afhængigt af værdien af ​​dit mål. Det ville overraske mig, hvis kun få, muligvis ingen af ​​dongler i dag er i stand til at modstå denne slags angriber med højt budget.

Fungerer de

Givet en dongle, der er baseret på stærk kryptering, er ikke tidsbaseret, da du ikke kan udløbe krypteringsnøgler baseret på tid, og heller ikke er tiden absolut, fri for sidekanalangreb og udfører koden på chippen, ja det vil gøre det at opdage den underliggende kode svarende til sondering af en sort boks. De fleste af pauserne, der sker med disse dongler, er baseret på implementeringssvagheder hos licenshaverne af hardwarelicenssystemet på grund af, at implementøren ikke er bekendt med reverse engineering og computersikkerhed generelt.

Vær også opmærksom på, at selv software, hvor størstedelen af ​​logikken er implementeret på en internetvendt server, er blevet brudt simpelthen ved at undersøge den sorte boks og udlede serverens sidekode baseret på klientkodens forventninger. Forbered dig altid på, at din ansøgning bliver brudt, og udvikl en plan for, hvordan du skal håndtere den, når den sker.

Det er klart, at Peter har taget fat på hovedpunkterne for korrekt gennemførelse. I betragtning af at jeg - uden at offentliggøre resultaterne - har "knækket" to forskellige donglesystemer tidligere, vil jeg også gerne dele min indsigt. user276 antyder allerede dels, hvad problemet er.

Mange softwareleverandører tror, ​​at de køber en slags sikkerhed til deres licensmodel, når de licenserer et donglesystem. De kunne ikke være længere væk fra sandheden. Alt, hvad de gør, er at få de værktøjer, der giver dem mulighed for at implementere et relativt sikkert system (inden for de grænser, der er påpeget i Peters svar).

Hvad er problemet med kopibeskyttelse generelt? Hvis en software bruger matematisk lydkryptering til sin licensordning, har dette ingen indflydelse på sikkerheden ved kopibeskyttelsen som sådan. Hvorfor? Nå, ender du i en fangst 22-situation. Du stoler ikke på brugeren (fordi brugeren kunne kopiere softwaren), så du krypterer ting eller bruger kryptering på en eller anden måde i din kopibeskyttelsesplan. Ak, du skal have din private nøgle i produktet for at bruge krypteringen, hvilket helt modsiger tanken om mistillid til brugeren. Dongles forsøger at placere den private nøgle (og / eller algoritme og / eller andre ingredienser) i hardware, så brugeren i første omgang ikke har adgang.

Men da mange leverandører er under det indtryk, at de køber sikkerhed ud af kassen, lægger de ikke kræfter i den korrekte implementering. Hvilket bringer mig til det første eksempel. Det er et CAD-program, som min mor brugte. Af den viden, at dongler, der opretter forbindelse til LPT, har tendens til at fejle oftere end deres nyere USB-kolleger, satte jeg mig for at "omgå" denne. Det var omkring 2005.

Det tog mig ikke for lang tid. Faktisk brugte jeg et simpelt DLL-placeringsangreb (navnet, under hvilket scenariet senere blev kendt) til at indsprøjte min kode. Og den kode var ikke alt for detaljeret. Kun en bestemt funktion returnerede den værdi, donglen normalt læste op (serienummer), og det var det. Resten af ​​funktionerne ville jeg videregive til den oprindelige DLL, som dongle-leverandøren skal installeres sammen med driveren.

Den anden dongle var lidt før det. Problemet her var, at jeg arbejdede for en underentreprenør, og vi havde kun begrænset adgang til den software, som vi skulle udvikle. Det var virkelig et spørgsmål om bureaukrati mellem det firma, der licenserede softwaren, og softwareleverandøren, men det forårsagede store problemer for os. I dette tilfælde var det lidt mere udfordrende at arbejde rundt om donglen. Først og fremmest skulle der skrives en driver for at snuse IRP'erne fra og til enheden. Derefter skulle algoritmen, der blev brugt til kryptering, findes. Heldigvis blev ikke alt gjort i hardware, som gav løkkehullet til os. I sidste ende havde vi en lille driver, der ville udgøre som donglen. Dens funktionalitet blev udvidet så langt, at man læste en ægte dongle op, gemte dataene (faktisk sendte den til et brugertilstandsprogram, der gemte den) og derefter indlæste den tilbage for at fremstå som denne dongle. Konklusion: dongler, uanset hvilken slags, hvis de implementerer kernefunktionaliteten i det program, som de tilhører, er svære at knække. For alt andet afhænger det for det meste af beslutsomhed og vilje til at sætte tid til den eller de personer, der satte sig ud på at arbejde rundt om donglen. Som sådan vil jeg sige, at dongler udgør en betydelig hindring - hvis de implementeres korrekt - men i tilfælde af uagtsomhed over for en del af softwareleverandøren, der søger at beskytte sin oprettelse, også blot slangeolie.

Vær opmærksom på det sidste afsnit i Peters svar. Men jeg vil gerne tilføje endnu en tanke. Software, der virkelig er værd at beskytte, fordi den er unik i en forstand, bør ikke beskyttes på basis af kundechikane (== de fleste kopibeskyttelsesordninger). I stedet overveje eksemplet med IDA Pro, som helt sikkert kan betragtes som temmelig unik software. De vandmærker softwaren for at kunne spore den person, der lækkede et bestemt bundt. Som vi så med ESET-lækagen hjælper det selvfølgelig ikke altid, men det skaber afskrækkelse. Det er mindre sandsynligt, at en krakkergruppe f.eks. Får fat i en kopi.

Som Peter har antydet, er det at se på, hvordan donglen bruges til sikkerhed, udgangspunktet for at identificere angrebsvektorerne. I de fleste tilfælde er softwareudviklerne, der implementerer donglesikkerheden, det svageste punkt.

Tidligere da jeg har testet software med dongler, har jeg brugt gratis værktøjer som ProcessMonitor og RegShot til at identificere enkle sårbarheder for at besejre dårlige implementeringer af donglesikkerhed.

Jeg har set software, der ved opstart kontrollerer for tilstedeværelsen af ​​dongle og derefter fortsætter med dens drift uden at bruge donglen, indtil den genstartes. I disse tilfælde er det ikke så svært at fortælle appen at køre applikationen med OllyDbg at køre med fuld funktionalitet, så længe donglen IKKE er tilsluttet systemet.

Jeg har også set software, der tillader en brugeren skal klikke på en knap i softwaren, så brugeren ikke behøver at have donglen indsat. Softwaren hævdede, at det er en ekstra funktionalitet som "Husk mig". RegShot og ProcessMonitor viste mig, at en fil er skrevet med nogle oplysninger, og så længe filen er til stede i den forventede mappe, kan jeg køre softwaren på flere systemer uden en dongle.

Bare fordi nogen bruger AES eller hardware-dongler eller en hvilken som helst XYZ betyder ikke, at de er sikre. Alt, hvad der passer sammen, er, om de implementerer disse sikkerhedsforanstaltninger på den rigtige måde, forudsat at der nu er kendt (eller 0-dages sårbarheder) i sikkerhedsforanstaltningen.