Hjälp mig hitta en lösning

Tråden skapades och har fått 31 svar. Det senaste inlägget skrevs .

Jag har ett problem som jag knappt kan formulera, och än mindre se någon riktigt bra lösning på, så jag vill höra om någon annan programmeringskunnig, eller annan, kan komma på något:

Jag och en kollega håller på att utveckla en omfattande server-programvara som ska kunna installeras på en server ute hos kund.

Problemet är att vi skulle vilja att ju mer de använder programvaran desto mer kostar det. Det skulle vi såklart enkelt kunna göra om programvaran "ringde hem", men det är det vi inte vill, dvs. vi kan inte vara säkra på att kundernas maskiner har nätaccess etc.

Därför går våra funderingar i att använda någon form av "skrapkoder" dvs. en lista med koder som förbrukas och sedan ej kan återanvändas, men vi kan inte se riktigt hur vi kan lösa det utan i princip lagra senast använda skrapkod etc., och det innebär att en illasinnad kund skulle kunna hitta hur systemet ska nollställas.

Kan någon se en bra lösning på hur vi ska hantera detta problem, utan att behöva "ringa hem"

På mitt företag säljer vi en typ av maskin för plåtbearbetning och i början när maskinen först installeras har kunden oftast betalt 50-90%. För att säkra full betalning går maskinen inte att köra mer än 200 timmar. Sedan stannar den och vill ha en kod. Därefter kan maskinen låsas upp för ett visst antal drifttimmar eller permanent. Skulle det vara en gångbar lösning? Detta kunde ju så klart automatiseras - i vårt fall kör man via telefon.

När den givna gränsen överskridits kommer vi såklart att införa någon form av strypning, men det är inte precis typen av strypning jag upplever som problemet, utan att på ett säkert sätt göra det möjligt att förhindra "nollställning" av programvaran. I maskinfallet gissar jag att det inte är helt trivialt att skruva isär och gå in i logiken och återställa den till leveransläge det, men om vi t.ex. skulle hålla reda på hur mycket programvaran jobbat och skriva ner i en fil så räcker det med att någon hittar filen så kan de sedan ta en tidigare fil och på så sätt förhindra att uppräkningen fortsätter och den kritiska gränsen nås.

Jag förklarar förmodligen väldigt dåligt, hoppas du förstår ändå.

Det går (nästan) aldrig att gardera sig mot illasinnade kunder. Hur mycket man än försöker, hur mycket tid och pengar man än lägger ner är det ändå någon som listar ut hur man kan gå förbi det. Nu känner jag ju inte till några detaljer om vad just ni gör för något, men generellt tror jag att det är något som man får acceptera och istället lägga resurserna på att göra produkten bättre. Jag brukar se den här typen av kontrollsystem mer som ett sätt att hålla hederliga kunder hederliga.

Låter som ett oerhört krävande DRM-system, som kund av serverprodukter skulle jag blåvägra köpa en produkt som är utformad på det sättet. Men jag vet ju inte vad det är för typ av produkt ni utvecklar.

Varför bara inte ha samma typ av licenssystem som drakar som Oracle och så använder? Typ:

* Betala per server
* Betala per processor
* Betala för mängden minne
* Betala för mängden transaktioner

Sen kan ni ju alltid, om ni känner att det är värt att göra livet surt för kunden att begränsa antalet transaktioner/operationer/m.m. per licensnyckel, de får helt enkelt fylla på med nya nycklar som med ett kontantkort.

Någonstans måste man ju lita på sina kunder också...

  • Medlem
  • Uppsala
  • 2010-08-04 16:42

Det är ett fundamentalt svårt problem. Bruce Schneier har skrivit en del om det futila i att samtidigt ge och förneka tillgång till en resurs på en dator.
Min egen erfarenhet är att alla typer av donglar och mjukvarulösningar går att ta bort mha en patch.
De du kan göra är följande:
Designa ett PCI-kort med en FPGA på som i sin tur innehåller instruktioner och data som är essentiella för programmets funktionalitet. FPGA:n kan då innehålla de engångsnycklar som du beskriver och när en sådan matas in svarar PCI-kortet på de funktionsanrop som programmet kräver.
Så som (vissa) FPGA:er är utformade förstörs konfigurationen på dem om man försöker sig på invasivt hackande. Därmed är du säker så länge inte Intel el någon annan chiptillverkare försöker komma åt innehållet på kortet.

Med en tillräckligt stor FPGA kan man få in rätt mycket av programmet i kortet.

Problemet med denna approach är naturligtvis att det är mycket dyrt då du måste konverter din källkod till typ verilog etc plus att någon måste designa kort o dyl.
Det är dock billigare än en ASIC.

Grejen är dock denna om dina kunder inte är hackers av den högre skolan är en enkel mjukvarulösning med engångskoder fullt tillräckligt. Så länge det inte är uppenbart enkelt gjort så borde det räcka.

Ursprungligen av sfalc:

Det är ett fundamentalt svårt problem. Bruce Schneier har skrivit en del om det futila i att samtidigt ge och förneka tillgång till en resurs på en dator.
Min egen erfarenhet är att alla typer av donglar och mjukvarulösningar går att ta bort mha en patch.
Det kan göra är följande:
Designa ett PCI-kort med en FPGA på som i sin tur innehåller instruktioner och data som är essentiella för programmets funktionalitet. FPGA:n kan då innehålla de engångsnycklar som du beskriver och när en sådan matas in svarar PCI-kortet på de funktionsanrop som programmet kräver. Så som FPGA:er är utformade förstörs konfigurationen på dem om man försöker göra invasivt hackande. Därmed är du säker så länge inte Intel el någon annan chiptillverkare försöker komma åt innehållet på kortet.

Med en tillräckligt stor FPGA kan man få in rätt mycket av programmet i kortet.

Problemet med denna approach är naturligtvis att det är mycket dyrt då du måste konverter din källkod till typ verilog etc plus att någon måste designa kort o dyl.
Det är dock billigare än en ASIC.

Grejen är dock denna om dina kunder inte är hackers av den högre skolan är en enkel mjukvarulösning med engångskoder fullt tillräckligt. Så länge det inte är uppenbart enkelt gjort så borde det räcka.

Du har precis förstått problemet. Nu ska jag bara försöka förstå svaret

Jag bör också nämna att vår ambitionsnivå inte är att skapa total säkerhet, utan att förhindra "the average IT guy" att knäcka hur vi gör, på ett sätt som också är rimligt enkelt för oss som utvecklare.

  • Medlem
  • Göteborg
  • 2010-08-04 17:04
Ursprungligen av Richard Rönnbäck:

Du har precis förstått problemet. Nu ska jag bara försöka förstå svaret

Jag bör också nämna att vår ambitionsnivå inte är att skapa total säkerhet, utan att förhindra "the average IT guy" att knäcka hur vi gör, på ett sätt som också är rimligt enkelt för oss som utvecklare.

Men varför förutsätter ni att de ska försöka knäcka ert system, det första de gör? Kommer det inte vara i kundens intresse att ni kan livnära er så att tjänsten ni erbjuder finns kvar och fortsätter hjälpa kunden i dennes arbete?

Ursprungligen av ibish:

Men varför förutsätter ni att de ska försöka knäcka ert system, det första de gör? Kommer det inte vara i kundens intresse att ni kan livnära er så att tjänsten ni erbjuder finns kvar och fortsätter hjälpa kunden i dennes arbete?

Som sagt, jag uppskattar även principiella synpunkter, men ser hellre en egen tråd om för- och nackdelar med kopieringsskydd etc.

Men för att svara kort: Vi känner våra kunder väl och vet att de både har förmågan till samarbete och fulspel, dvs. de är som de flesta människor en blandning av gott och ont, och vi vill göra det lite svårare att göra fel sak, och också lättare att göra rätt. Därav att vi inte vill ha programvaror som ringer hem, men ändå någon form av skydd.

Good fences make god neighbors…

Även om jag uppskattar även principiella synpunkter på kopieringsskydd så var det inte riktigt det jag frågade om

Så, för att återgå till huvudfrågan så är vår tanke att göra något i stil med betalning per transaktioner/operationer etc. men frågan är hur vi lagrar detta säkert. Låt säga att vi tillåter 1000 operationer, hur lagrar vi info om hur mycket kunden konsumerat och förhindrar manipulering av det?

Som sagt, ska servern ringa hem är det enkelt, men hur göra om man just INTE vill plåga kunden med den typen av system?

  • Medlem
  • Göteborg
  • 2010-08-04 16:52
Ursprungligen av Richard Rönnbäck:

Även om jag uppskattar även principiella synpunkter på kopieringsskydd så var det inte riktigt det jag frågade om

Så, för att återgå till huvudfrågan så är vår tanke att göra något i stil med betalning per transaktioner/operationer etc. men frågan är hur vi lagrar detta säkert. Låt säga att vi tillåter 1000 operationer, hur lagrar vi info om hur mycket kunden konsumerat och förhindrar manipulering av det?

Som sagt, ska servern ringa hem är det enkelt, men hur göra om man just INTE vill plåga kunden med den typen av system?

Kommer kunden behöva vara uppkopplad för att kunna göra transaktionen/operationen? Annars finns ju tidsbegränsningar istället, att man får förnya licensen efter en viss tid. Har ni kollat med kunderna så att de godtar betalningsmodellen ni är ute efter?

Om ni inte kan förutsätta att det finns Internetåtkomst så finns det inte så mycket mer ni kan göra annat än att lagra licensinformationen krypterat och/eller signerat och hoppas att kunden inte bemästrar en hexeditor.

  • Medlem
  • Uppsala
  • 2010-08-04 16:56

Tja mina synpunkter är inte enbart principiella, min fars företag byggde ett sådant kort. Tror att de tog typ 2000 000 kr för 100 st kort. Det var dock en liten FPGA.

Ursprungligen av sfalc:

Tja mina synpunkter är inte enbart principiella, min fars företag byggde ett sådant kort. Tror att de tog typ 200 000 kr + utvecklingskostnader för 100 st kort. Det var dock en liten FPGA.

Mitt svar om principiella synpunkter var inte riktat till dig, utan till William WM och Marcus K. Ditt svar var väldigt konkret.

  • Medlem
  • Uppsala
  • 2010-08-04 17:10

Bygg in en krypteringsnyckel i programmet per kund. Varje x omgång av tid levereras som en krypterad fil el filer. Filen innehåller information om hur länge programmet får köras. Filen innehåller även en ny nyckel. Då kan man inte använda samma biljett två gånger.

Ursprungligen av sfalc:

Bygg in en krypteringsnyckel i programmet per kund. Varje x omgång av tid levereras som en krypterad fil el filer. Filen innehåller information om hur länge programmet får köras. Filen innehåller även en ny nyckel. Då kan man inte använda samma biljett två gånger.

Intressant lösning, men borde det inte vara hur enkelt som helst att knäcka bara genom att först göra en säkerhetskopia på den förra filen?

  • Medlem
  • Uppsala
  • 2010-08-04 17:14

Sen för att göra det lite svårare för dem att fuska, kan ni ju alltid bygga in en funktion för att fråga systemet om vilken nyckel den använder, samt hur lång tid det är kvar.
Visar det sig att de använder en nyckel som redan har tagit slut eller att något annat skumt är i görningen, ja då får ni ringa BSA.

  • Medlem
  • Uppsala
  • 2010-08-04 17:18

Det finns en hel del kommersiella leverantörer av enklare säkerhetssystem för mjukvarulicensiering. Har inga i huvudet, men för dina syften borde det finnas något ute på marknaden som passar.
Vilken plattform talar vi om här? OSX? Linux? Windows? el en kombination?

  • Medlem
  • Uppsala
  • 2010-08-04 17:21

Nja alltså så fort man laddar in en ny nyckel förstörs den gamla och den kan inte dekryptera de förra filen utan enbart nästa

0. Nyckel nummer 0 dekrypterar fil 0, fil 0 innehåller Nyckel 1 samt tid för att köra programmet.
1. Nyckel 1 dekrypterar fil 1, fil 1 innehåller Nyckel 2 samt tid för att köra programmet.

ad infinitum

Viktigt är att inte skicka fel nycklar till fel kunder annars kommer supportsamtalen bli långa...

Den man i praktiken gör är att patchan sin egen programvara med nya nycklar. Nycklarna ligger ju i maskinkoden. Enda anledningen till att kryptera filerna är att se till bara en själv kan uppdatera nyckeln och räkneverket.

Ett problem kan vara att anti-virus program och NX skydd för minne kan triggas...

Det är väldigt svårt att garantera att nyckeln förstörs. Oavsett var du skriver den kan jag ju ha gjort en kopia. Med Time Machine eller vanliga snapshots är det ju inga större problem. Möjligen att det blir lite jobbigare om man jämför tiden mot systemklockan.

Eftersom nivån inte ska vara högre än att den genomsnittlige IT-människan inte med enkelhet ska kunna gå förbi systemet skulle jag nog göra något lite enklare med vanliga serienummer. Med vanlig public key-kryptering skulle det vara ganska enkelt att skapa nya serienummer som när programmet avkrypterar dem innehåller licensinformation, t. ex. vilken kund och hur länge programmet är licensierat. För att inte göra det alltför enkelt att hitta den privata nyckeln, exempelvis med strings eller liknande verktyg kan man skapa den dynamiskt i flera steg, en eller flera byte i taget. Då måste du börja analysera maskinkoden i detalj och då tror jag att vi har kommit förbi "the average IT guy."

  • Medlem
  • Uppsala
  • 2010-08-04 18:02

Den ska naturligtvis inte lagras i en fil av typen "nyckel.key", för då blir det ju hel klart trivialt att göra en kopia, utan inne i programkoden på något fiffigt sätt.

Alltså
0. En valideringssteg körs där programmet kollar att licenser finns och att den själv inte har blivit modifierad.
1. Programmet körs....
2. Användaren klickar på "Lägg till mer tid"
3. Programmet läser in filen...
4. Programmet dekrypterar filen och validerar den. Uppdaterar sin egen nyckel genom att patcha sina egna binärer, patchar även binärerna så att tiden som återstår lagras där samt i någon config-fil. Typ i header-bitar som inte syns dessutom.

Det går det inte att lagra någon data om hur länge programmet får köras på ett bra sätt. Så fort man skriver till hårddisken är man egentligen rökt. Det enda man kan göra är att dölja hur man lagrar informationen och hoppas på att användaren inte fixar att gå förbi det.
Olika varianter på steganografi behöver man nog använda.

Nu börjar vi snacka

Jag pratade just lite med min kollega, lite utifrån sfalcs tankegångar, och vid en första lös skiss så tänker vi oss ungefär såhär: Programvaran innehåller en kod som kan kryptera en sträng +kundunik salt. När kunden aktiverar programvaran får de en lista med koder, samt att vi genererar en första giltig nyckel. När de sedan förbrukat en kod skriver vi den senast förbrukade koden till en fil, och skapar en filsignatur (ursäkta om terminologin är helt uppåt väggarna, det här är inte min bollplan). Vid nästa körning kan vi då verifiera den filen och se om den manipulerats med avseende på filinnehåll och egenskaper. Likaså innebär en manipulerad signatur-fil att manipulationen avslöjas.

Om man djupdykt i filsystem så vet man att det är fruktansvärt svårt att manipulera en fil så att den blir identisk med en tidigare instans. T.ex. är alla kopieringsförsök, Time Machine etc. meningslösa, eftersom de avslöjas av en vettigt gjord signatur.

Ursprungligen av Richard Rönnbäck:

Om man djupdykt i filsystem så vet man att det är fruktansvärt svårt att manipulera en fil så att den blir identisk med en tidigare instans. T.ex. är alla kopieringsförsök, Time Machine etc. meningslösa, eftersom de avslöjas av en vettigt gjord signatur.

Det beror på vilken nivå du avser att kalla filerna för identiska. Om du bara ser till innehållet så går det naturligtvis att skapa en exakt kopia, men om du även tittar på t. ex. trädnod och liknande metainformation så är det definitivt svårare.

Ursprungligen av Marcus K:

Det beror på vilken nivå du avser att kalla filerna för identiska. Om du bara ser till innehållet så går det naturligtvis att skapa en exakt kopia, men om du även tittar på t. ex. trädnod och liknande metainformation så är det definitivt svårare.

Precis, och då är det bara en fråga om ambitionsnivå, hos en själv, och eventuella crackare.

  • Medlem
  • Stockholm
  • 2010-08-04 21:41

Så om kunden behöver återställa en kraschad disk med Time Machine så ser ni det som en otillåten manipulation?

Ursprungligen av pesc:

Så om kunden behöver återställa en kraschad disk med Time Machine så ser ni det som en otillåten manipulation?

Varför tror du det? Vilka åtgärder vi väljer att vidta är ju skilt från de villkor vi ställer upp för att trigga åtgärden:

  • Medlem
  • Stockholm
  • 2010-08-05 00:09

Utan dedicerad, och mycket väldesignad, hårdvara för att hantera säkerheten blir mer eller mindre alla lösningar relativt enkla att ta sig förbi. Alla mjukvarulösningar är relativt enkla att knäcka för den som tröttnat på inlåsningsteknik; vem som helst med lite tid och driv lär på storleksordningen en helg kunna identifiera alla säkerhetskontroller och patcha bort dem relativt enkelt.

Finns det dessutom ett intresse hos tillräckligt många att gå runt det, så kommer det snart att finnas enkla patchar att applicera för resterande, mindre drivna, personer.

Tänk PS3/XBOX360/DTV-teknik för att att skydda era grejer. Hur många andra devices/mjukvaror har undgått full jailbreak/rootning/crack på annat än väldigt kort tid?

Ursprungligen av fno:

Utan dedicerad, och mycket väldesignad, hårdvara för att hantera säkerheten blir mer eller mindre alla lösningar relativt enkla att ta sig förbi. Alla mjukvarulösningar är relativt enkla att knäcka för den som tröttnat på inlåsningsteknik; vem som helst med lite tid och driv lär på storleksordningen en helg kunna identifiera alla säkerhetskontroller och patcha bort dem relativt enkelt.

Finns det dessutom ett intresse hos tillräckligt många att gå runt det, så kommer det snart att finnas enkla patchar att applicera för resterande, mindre drivna, personer.

Tänk PS3/XBOX360/DTV-teknik för att att skydda era grejer. Hur många andra devices/mjukvaror har undgått full jailbreak/rootning/crack på annat än väldigt kort tid?

Som jag skrev i tidigare inlägg ber jag inte om synpunkter om huruvida det är önskvärt eller inte önskvärt, utan om råd på hur man praktiskt utformar ett sånt skydd.

För att förtydliga: Om jag frågar om hur jag sätter in ett tillhållarlås i min ytterdörr så är det helt meningslöst att komma med svar av typen: "Litar du inte på dina grannar?" , "Jag tycker det är fel att misstro folk" , "Vilken angelägen inbrottstjuv som helst kan forcera ett sånt lås på kort tid, om han bara vill"

Det är nämligen inte svar på min fråga, som handlar om HUR man gör något, inte om det BÖR göras.

Senast redigerat 2010-08-05 08:21
  • Medlem
  • Stockholm
  • 2010-08-05 20:15
Ursprungligen av Richard Rönnbäck:

Det är nämligen inte svar på min fråga, som handlar om HUR man gör något, inte om det BÖR göras.

För att kunna svara på något sådant, så måste man veta vad säkerheten är värd. Hur mycket får säkerheten kosta, både absolut och i förhållande till det som skall skyddas? Bra säkerhet är alltid kostsam.

Är det bara "orkafaktorn" ni vill ta er över så lägg max en arbetstimme på lite obfuscation.

Bevaka tråden