Beveiliging van software voor een hele specifieke doelgroep

[Knakker]

Ik heb recentelijk een stuk analytische software ontwikkeld voor een hele specifieke doelgroep. Ik ben de eerste die dit op deze manier voor deze doelgroep ontwikkeld heeft en het programma heeft een hoge praktische waarde wat maakt dat ik er leuk geld aan kan verdienen. De eerste afnemers heb ik reeds en binnen afzienbare tijd ga ik over tot de eerste levering.

Het mooie is dat iedere gebruiker zijn eigen instellingen heeft: het programma draait daar volledig op. Zolang de gebruiker daar zelf geen wijziging in aan kan brengen (functionaliteit die de gebruiker niet nodig heeft), is kopieren totaal nutteloos: het zal voor een andere partij totaal geen waarde hebben.

De doelgroep bestaat uit enkele tientallen gebruikers, dat totaal géén IT-ers zijn. Ik wil het echter wel dusdanig goed beveiligen dat een slim neefje of een slimme buurjongen de klantspecifieke instellingen niet kan ontsleutelen en aan kan passen voor anderen, waardoor ik dus licentiegelden misloop. Binnen de doelgroep kent men elkaar en het programma heeft een hoog "dit móet ik hebben" gehalte, dus dit is best een reële 'angst'. Ik weet echter bar weinig van beveiliging of encryptie, vandaar dat ik hier post.

Het is een single workstation programma, modulair opgebouwd (men heeft ook de mogelijkheid bepaalde modules al dan niet aan te schaffen) en de gebruikersdata voor analyse wordt opgeslagen (om verscheidene redenen, maar kosten, toegankelijkheid en portabiliteit de drie belangrijkste) in een Access 2007 database (van een paar MB groot). De beveiliging daarvan is geen issue, aangezien men daar zelf verantwoordelijk voor is: als men een Excel-bestand met gevoelige informatie laat rondslingeren (totaal vergelijkbaar) dan is dat ook niet mijn probleem.

Maar hoe kan ik het beste de klant-specifieke instellingen opslaan en piraterij zo goed mogelijk tegengaan? Ik kan vanuit mijn gelimiteerde kennis 3 mogelijkheden bedenken:

1) De allermakkelijkste en snelste manier is een tweede Access DB gebruiken voor de klant-specifieke instellingen, die DB met een wachtwoord beveiligen en dat wachtwoord hardcoded in het programma zetten.

2) Werken met een versleuteld licentie- en instellingenbestand, dat iedere keer bij het opstarten van het programma ingelezen wordt. Ik zie dat .NET built-in ondersteuning heeft voor een varieteit aan algoritmes, waarbij met termen gegooid wordt als DES, DSA, MD5, RSA en SHA-1.

3) Een internetverbinding is essentieel voor het vergaren van de gegevens waarmee het programma de analyse gaat uitvoeren, dus ik zou iedere keer het programma verbinding kunnen laten maken met mijn server en de klant-specifieke instellingen laten downloaden op basis van een licentiecode, die gewoon open en bloot zichtbaar is (immers met de licentiecode worden de gegevens van mijn server gedownload, die ik alleen in kan stellen).

Bij 1 ben ik afhankelijk van de beveiligingskwaliteit van MS Access 2007. Afgezien van het feit dat dat me niet wenselijk lijkt: hoe goed is de beveiliging daarvan? Puur gevoelsmatig vind ik 3 ook niet correct: stel dat mijn server een keer niet werkt dan kan men het programma niet gebruiken, terwijl mijn server verder niet relevant is voor de werking van het programma. Men mag en moet kunnen verwachten dat het altijd en foutloos werkt.

Wat zouden jullie doen? Optie 2 met één van de versleutelingsalgoritmes? Welke zouden jullie dan kiezen? Of totaal iets anders?

Ook andere suggesties of opmerkingen zijn altijd welkom. Hartelijk dank!

[Verwijderd]

Per klant hardcoded een unieke code inbakken en die periodiek opsturen naar je server in combinatie met een md5 hash van het instellingen bestand. Kortom; als de software een kopie is, zal het volgende optreden. Twee computers gebruiken dezelfde unieke code. De een heeft namelijk een kopie van de ander waarbij de unieke ingebakken code hetzelfde is. De instellingen die openbaar zijn, zal hij aanpassen naar eigen wens. Daardoor verschilt de md5 checksum van die instellingen ten opzichte van het legale origineel. Vervolgens kan je zelf besluiten wat je wilt doen. Je kan de server een commando terug laten sturen dat de versie illegaal is. Wat je daarmee intern doet is jouw keuze; programma afsluiten, waarschuwing geven, database encrypten. Nog een kleine tip, als de server *denkt* dat het een illegale versie is, maak de gebruiker dan niet uit voor dief. Laat een politiek correcte waarschuwing zien en vraag ze contact met je op te nemen als de waarschuwing onterecht is.
Op deze manier wordt er alleen gecontroleerd als je server wel online is en er een internet verbinding is. Natuurlijk is dit geen preventie, maar repressie als het kwaad al geschied is. Toch is dat de enige correcte manier van checken voor klanten.

[eghie]

Maak een encrypted config file aan. Encrypt de hele file met bijvoorbeeld AES. Sla hierin de persoonlijke instellingen op en ook de gebruikersnaam en wachtwoord voor de access database, die je van te voren aanmaakt bij het uitleveren. Zet in de applicatie hardcoded een licentienr. Laat de applicatie de configfile + een soort van 2e licentienr downloaden. licentienr + 2elicentienr is dan de key, om de encryptie ongedaan te maken.

Wat ook kan is een private RSA key downloaden en dan licentiecode + een hardcoded code als passphrase voor die RSA key gebruiken. Encrypten gaat dan via de publieke RSA key, die jij hebt. Deze vind ik zelf wat mooier en makkelijker te beheren. Uiteraard het config bestand ook via het internet laten downloaden. Licentiecode stuur je namelijk over het internet om het betreffende config bestand te downloaden, dus dat moet niet je volledige passphrase zijn, anders is het wel heel makkelijk om de echte RSA key te achterhalen.

[ Voor 14% gewijzigd door eghie op 09-12-2007 15:39 ]

[Verwijderd]

eghie, op die manier krijg je van die Microsoft praktijken waarbij je opeens Windows opnieuw moet valideren en Microsoft je voor dief uitmaakt omdat hun eigen servers het niet doen. Ik ben absoluut van mening dat je in dit soort gevallen moet werken vanuit de repressie in plaats van preventie. In de preventie moet je namelijk een internet verbinding hebben en een goed werkende server om de applicatie te gebruiken. Die applicatie moet simpelweg altijd werken. Wanneer er wel een verbinding is, kan gecontroleerd worden of de versie legaal is.

[eghie]

Verwijderd schreef op maandag 10 december 2007 @ 09:32:
eghie, op die manier krijg je van die Microsoft praktijken waarbij je opeens Windows opnieuw moet valideren en Microsoft je voor dief uitmaakt omdat hun eigen servers het niet doen. Ik ben absoluut van mening dat je in dit soort gevallen moet werken vanuit de repressie in plaats van preventie. In de preventie moet je namelijk een internet verbinding hebben en een goed werkende server om de applicatie te gebruiken. Die applicatie moet simpelweg altijd werken. Wanneer er wel een verbinding is, kan gecontroleerd worden of de versie legaal is.

Heb je inderdaad een punt. Aangezien het een workstation programma is, die bijvoorbeeld ook op een laptop zou moeten kunnen draaien zonder internet. Dan kun je alsnog een private RSA key meegeven aan de applicatie, gewoon standaard meeleveren, en dan de licentiecode, die hardcoded is in de app, als passphrase voor de RSA key gebruiken. Aangezien het een A-synchrone vorm van encryptie is heb je de public key nodig, om het config bestand te encrypten. Als je die dan "private" houd, dan lijkt me dat ook wel te volstaan. Dus gewoon config bestand (encrypted met public RSA key) en private RSA key meeleveren met programma.

[Thralas]

Verwijderd schreef op zondag 09 december 2007 @ 14:32:
Per klant hardcoded een unieke code inbakken en die periodiek opsturen naar je server in combinatie met een md5 hash van het instellingen bestand.

Dan pas ik het programma aan zodat md5(originele_config) hardcoded is, en dan?

eghie schreef op zondag 09 december 2007 @ 15:35:
Maak een encrypted config file aan. Encrypt de hele file met bijvoorbeeld AES.

Ik zie het nut van een symmetrische cipher (AES) hier niet echt. Wat wil je ermee bereiken?

Wat ook kan is een private RSA key downloaden en dan licentiecode + een hardcoded code als passphrase voor die RSA key gebruiken. Encrypten gaat dan via de publieke RSA key, die jij hebt.

RSA is imo de enige 'juiste' methode. Je kunt het er een stuk moeilijker mee maken, maar zeker niet onkraakbaar. Sidenote: Ik meen met herinneren dat RSA (specifiek) 'zwakker' is bij grotere plaintext lengths, en het daardoor alleen echt efficient is om bijvoorbeeld een hash te signen. Dat is waarschijnlijk sowieso (slechts iets) simpeler, de config file hashen en de hash vervolgens encrypten.

offtopic:
Je haalt trouwens private en public key door elkaar. De hypotetische RSA key gebruikt door de TS om een config danwel hash te encrypten geeft hij nooit weg, en is dus private. De andere key hardcode je in je programma, dus is 'ie public.

eghie schreef op maandag 10 december 2007 @ 11:53:en dan de licentiecode, die hardcoded is in de app, als passphrase voor de RSA key gebruiken.

Een passphrase is totaal overbodig voor die clientside (public) key.

Bottomline: Je kunt het moeilijk maken met assymetrische encryptie, waardoor het aanpassen van het programma een vereiste is. Dit kun je weer moeilijker maken door een packer te gebruiken.

[simon]

als je het zo beveiligt dat het teveel opvalt wordt 't je graf he, beveiliging moet zo natuurlijk mogelijk aanvoelen. Over techniek weet ik weinig, maar useability moet niet verdwijnen in beveiligings issues.

[Boss]

Ik gebruik zelf voor een simpele settings/security combinatie het voglende:
De ini-file is voor klanten gewoon leesbaar (plain text) en bevat alle instellingen. Daarnaast bevat de ini-file 1 regel met daarop een checksum / hashcode achtige combinatie. Zodra de klant dus iets wil wijzigen in de inifile kan hij niet zelf de correcte code genereren. Bij het opstarten van het programma wordt opgemerkt dat er iets niet klopt en is de functionaliteit beperkt.

Voor simpele dingen werkt dit prima, en blijft het geheel toch heel prettig werken.

[eamelink]

Heb je al overwogen om een hardware dongle te gebruiken?

Daar zijn er genoeg van te krijgen:
http://www.keylok.com/
http://www.safenet-inc.com/products/sentinel/dongles.asp
http://www.google.com/sea...curity+dongle&btnG=Search

Dan kan je gewoon per licentie één dongle meeleveren. Geen gedoe met vaste instellingen, de klant kan zijn software zo vaak installeren als hij wil op welke computer dan ook, maar maar één exemplaar tegelijk gebruiken.

[Zyppora]

Boss schreef op donderdag 13 december 2007 @ 12:31:
Ik gebruik zelf voor een simpele settings/security combinatie het voglende:
De ini-file is voor klanten gewoon leesbaar (plain text) en bevat alle instellingen. Daarnaast bevat de ini-file 1 regel met daarop een checksum / hashcode achtige combinatie. Zodra de klant dus iets wil wijzigen in de inifile kan hij niet zelf de correcte code genereren. Bij het opstarten van het programma wordt opgemerkt dat er iets niet klopt en is de functionaliteit beperkt.

Voor simpele dingen werkt dit prima, en blijft het geheel toch heel prettig werken.

Hier zat ik ook aan te denken. Als je de configuratie doet voordat het product (kant en klaar) geleverd wordt, kun je een hash van de config(file) hardcoden en dit bij gebruik controleren: klopt de hash, mag je gebruikmaken van de software. Klopt-ie niet, vette pech voor de gebruiker.

[Niemand_Anders]

Boss schreef op donderdag 13 december 2007 @ 12:31:
Ik gebruik zelf voor een simpele settings/security combinatie het voglende:
De ini-file is voor klanten gewoon leesbaar (plain text) en bevat alle instellingen. Daarnaast bevat de ini-file 1 regel met daarop een checksum / hashcode achtige combinatie. Zodra de klant dus iets wil wijzigen in de inifile kan hij niet zelf de correcte code genereren. Bij het opstarten van het programma wordt opgemerkt dat er iets niet klopt en is de functionaliteit beperkt.

Voor simpele dingen werkt dit prima, en blijft het geheel toch heel prettig werken.

Zoals de TS al aangaf kent de doelgroep elkaar. Straks gaan ze met elkaar praten en bepalen ze wie de meeste features geeft en gebruikt iedereen dat ini bestand zodat de hash klopt.

Op wij gebruiken gebruiken eenzelfde soort oplossing als quist heeft omschreven. Als identificatie gebruiken wij X.509 certifcaten. Het certificaat bepaald daarnaast ook een aantal andere instellingen van het programma zoals de gebruiker. Onze applicatie wordt veel in de financiele wereld gebruikt en dergelijke bedrijven vinden het niet fijn dat als de provisie van een bank ineens aan een ander bedrijf wordt uitgekeerd omdat ze een certificaat hebben gekopieerd.

Het certificaat bevat ook het serienummer waarmee wij de private key van het certificaat uit de database kunnen trekken om daarmee de response te encrypten. Middels de public key (embedded in certificaat) kunnen de rechten en modules ingelezen worden.

Het certificaat is ook nodig op te controleren op updates. En aangezien financiele gegevens regelmatig veranderen (rente percentages, wettelijke regels, producten van banken) wil niemand dat risico lopen dat ze met verouderde gegevens werken.

[Knakker]

Sorry dat ik niet eerder gereageerd heb; ben erg druk geweest.

Het hoeft niet onkraakbaar te zijn, maar moet "slimme-neefjes-proof" zijn. De makkelijkste en relatief veilige oplossing is werken met een versleuteld instellingenbestand. Het geeft ook het minste werk. Enige nadeel is dat ik een wijziging in de instellingen zelf moet verwerken, maar dat is weinig werk (kleine doelgroep) en betekent automatisch ook dat ik wat controle en inzicht erover houdt.

Hartelijk dank voor de reacties in ieder geval!

[TheRookie]

Even een reactie als 'gewone' gebruiker van diverse pakketten:
Als ik ergens een broertje dood aan heb dan is het dat ik voor elke wijziging in de instellingen van een pakket contact op moet nemen met de leverancier.

Even los van de afhankelijkheid die je hiermee creert, kan het ook een vertragende factor zijn: jij moet maar net tijd hebben om de wijziging door te voeren...

Als de instellingen in jouw pakket een kwestie van 1x instellen en zelden of nooit meer (hoeven te) veranderen is, is het uiteraard een iets ander verhaal

Bovenstaande is een beetje kort door de bocht, maar ik neem aan dat je de strekking wel begrijpt

[Boss]

Zoals de TS al aangaf kent de doelgroep elkaar. Straks gaan ze met elkaar praten en bepalen ze wie de meeste features geeft en gebruikt iedereen dat ini bestand zodat de hash klopt.

En daarom zet je ook de naam van de gebruiker in de ini en op een prominente plaats in het programma