vrijdag, januari 13, 2006

.Net File encryption probleem

Ik heb een probleem. Ik heb er natuurlijk meer dan 1. Maar over 1 wil ik het in deze blog hebben.

Ik ben bezig met een applicatie. Deze applicatie berekend de kosten van een product. Een product bestaat uit een aantal artikelen. En deze artikelen hebben een prijs. Om de berekening uit te voeren moet het programma de prijs weten. En om het programma flexibel te houden: ik wil niet bij elke prijswijziging een nieuwe versie van het programma uitbrengen, komt de prijs informatie in een losse file. Alleen: de prijs informatie is gevoelige informatie en mag niet zonder meer in de handen van de concurrentie vallen.

Dus wat doe je dan: je encrypt de inhoud van de file. En je zorgt dat dat file een checksum oid heeft zodat foute decrypts opgemerkt worden. In .NET is dit allemaal geen probleem. Het programma decoded de file en ik kan werken met de gegevens. Voor het decoden heeft het programma de sleutel nodig waarmee het bestand ge-encrypted is.

En hier zit gelijk het probleem. Welke sleutel ik ook kies, en hoe lang hij ook is: hij is beschikbaar in het programma. Ergens staat een regel met: string key = "xjfhdfdsgfjsdgfjdgfhgsdfjgsdj";
En met een simpele decompile is de sleutel zo te vinden. En de gebruiker heeft beschikking over het programma en de DLL's anders heeft het programma weinig nut.

Het enige wat ik kan doen is te zorgen dat het programma niet bij de concurrentie komt en dat ze alleen de files met de prijzen hebben. Anders weet ik het ook niet. Ik kan de code wel obfuscaten maar dan staat er ergens: string ___3773 = "xjfhdfdsgfjsdgfjdgfhgsdfjgsdj". Niet heel erg lastig. Ook kan ik de code in een char array stoppen en wat trucjes mee uithalen. Maar dat is nog steeds valse veiligheid. Aangezien alle code om de key te ontcijferen zoiezo in het programma moet zitten..

Hoe zouden jullie dit oplossen?

3 opmerkingen:

Anoniem zei

Een website maken voor de klant waar deze de berekening op kan doen (en op moet inloggen)?

Of je programma een webservice laten benaderen waar een username / password op zit (die ze als een soort licentie moeten invullen tijdens het installeren van het programma)?

Als het idee is dat de klant berekeningen kan doen met het programma dan zal het altijd werken ook in verkeerde handen. Tenzij je een koppeling met inlog terug naar een site maakt (en de klant de login details niet weggeeft).

Anders kan een concurrent er altijd makkelijk bij denk ik. Vaak ook door simpele data in te vullen.

Stel dat je module deze berekening doet:

antwoord = aantal x prijs

Dan kan de concurrent natuurlijk altijd de stuksprijs achterhalen. Wat er ook onderwater gebeurd. Tenzij hij voor de prijs een inlog code nodig heeft.

Het voordeel van zo'n webservice is natuurlijk ook dat jullie de prijs makkelijk (lokaal) kunnen updaten

Rob L.

Hans van Leuken zei

website en webservice is geen optie. De systemen hoeven geen live verbinding te hebben met het internet.

Anoniem zei

mijn eerste ideetje:
zet een stuk tekst in het register en pak ergens een stuk uit als sleutel afhankelijk van de datum ofzo.. niet waterdicht en nog steeds te achterhalen, maar wel een stuk lastiger!!