licenties aanmaken

[itcouldbeanyone]

Hi op mijn werk hebben we een controller.
Om te voorkomen dat deze in china nagemaakt word, het volgende.

Als de controller van de productie tafel afkomt is hij standaard gelocked.

Zodra je je pc koppelt met de juiste software en je je product registeerd is hij bruikbaar. Met geldige licentie dus

Elk product heeft dus een uniek id .

Hoe gaat zo iets in werking.
Kan dit via een simpele web server.
Hoe zorg je ervoor dat een uniek id niet vaker gebruikt kan worden.
Hoe doen andere dit

De pc software wordt geschreven in java.

[CH4OS]

En wat is nu precies je vraag?

Om toch wat vragen te proberen te beantwoorden:
Of het via een simpele webserver kan, geen idee. Ik zou daarvoor gewoon een bepaalde (semi-public) API voor beschikbaar stellen waarmee elke klant aan de hand van wat gegevens zichzelf valideert bij jullie en aan de hand daarvan functies activeert.

Hoe je een uniek ID kan meegeven? Kom op, dit is basis databases. Verdiep je eens in de unique key constraint. Hoe anderen dat doen en waarin, maakt dan uiteraard niets uit. Je moet de taal gebruiken die het beste bij de applicatie past.

[ Voor 93% gewijzigd door CH4OS op 17-05-2016 19:17 ]

[upje]

En wat heb jezelf al zoal gevonden?

[Breezers]

Wacht even.... Jouw bedrijf maakt een product met de techniek erachter en nu ga je ons vragen hoe dit werkt ?

[Hennie-M]

Ik ben ook vooral benieuwd wat je doel is.

[RGAT]

Weet niet wat voor controller dat is maar ik zou er niet al te blij mee zijn als ik m'n spullen maar op 1 systeem kan gebruiken...
Kortom: je zal eerst een soort functioneel ontwerp moeten maken waarin je duidelijk maakt, vooral voor jezelf, wat het doel is en hoe dat in de praktijk moet werken, je vraag hier 'dumpen' gaat niet helpen aangezien hier niet kant en klare oplossingen 'oplossing.exe' voor bestaan

[itcouldbeanyone]

Sorry hoor maar ik kan nergens vinden hoe een registratie via het internet verloopt vandaar dat ik het hier vraag.
Het gaat om een motor controller dus hij zal niet vaak aan de pc gekoppeld zijn.
Het product is er al. Ik zit me alleen te oriënteren hoe ik ga beveiligen tegen namaak.
Ik heb zelf totaal geen ervaring met het opzetten van zon service. Toch is het mijn verantwoording om een oplossing te zoeken

[CH4OS]

Zoek je niet gewoon een octrooi of patent?

[ Voor 8% gewijzigd door CH4OS op 17-05-2016 19:46 ]

[itcouldbeanyone]

CH40S schreef op dinsdag 17 mei 2016 @ 19:45:
Zoek je niet een octrooi of patent?

Nee. Er moet een lijst komen met de gebruikers die deze controller geïnstalleerd heeft.

Ik zat zelf te denken aan.

Je geeft je gebruikersnaam op
Je product wordt gekoppeld aan de gebruikersnaam van de monteur.

Deze gegevens inclusief het ip wordt doorgetuurd naar een server. Vraag is alleen hoe. Via websockets ofzo?

Zodra wij zien dat een product nummer vaker voorkomt onder dezelfde gebruiker maar wel verschillende ip's
Laat maar zeggen vaker dan 50 keer duidt dit op namaak en kan er eventueel actie ondernomen worden

[johnkeates]

CH40S schreef op dinsdag 17 mei 2016 @ 19:45:
Zoek je niet gewoon een octrooi of patent?

Denk je serieus dat iemand in China daar door tegen gehouden wordt?

itcouldbeanyone schreef op dinsdag 17 mei 2016 @ 19:38:
Sorry hoor maar ik kan nergens vinden hoe een registratie via het internet verloopt vandaar dat ik het hier vraag.
Het gaat om een motor controller dus hij zal niet vaak aan de pc gekoppeld zijn.
Het product is er al. Ik zit me alleen te oriënteren hoe ik ga beveiligen tegen namaak.
Ik heb zelf totaal geen ervaring met het opzetten van zon service. Toch is het mijn verantwoording om een oplossing te zoeken

Je bent niet de juiste persoon, besteed het uit. Er is geen goedkope oplossing voor, en ook geen makkelijke, en zelf wat maken gaat het niet worden om dat je niet over de juiste kennis beschikt.

Qua technologie zit je met het volgende:

- Challenge-Response
- Unieke ID's
- Verificatie

Als iemand jouw controller namaakt en een 'bekend' ID er in stopt, dan werkt die controller dus. En als iemand jouw controller namaakt maar het verificatie stukje er uit sloopt, dan werkt ie ook gewoon. En als iemand je 'activatie' afluistert en nadoet, dan werkt de 'activering' ook. Met andere woorden: de bekende wegen werken niet en gaan ook niet werken. Microsoft lukt het niet, Adobe lukt het niet, de kans dat het jou wel lukt lijkt me nogal klein.

Technisch gezien is de implementatie meestal als volgt:

- Er is een combinatie van een ID en een key
- De activatie server controleert of die combinatie geldig is
- Controller werkt wel of niet afhankelijk van wat de activatie server teruggeeft

Een iets veiligere methode is een challenge-response:

- Er is weer een ID en een key
- De server stuurt een random stuk tekst en de huidige tijd/datum mee
- Controller kijkt of de tijd/datum klopt, zo ja dan gaat ie verder, zo nee, dan stopt ie
- Als ie verder gaat codeert ie de random tekst plus de datum en tijd met de key en stuurt het gecodeerde resultaat terug naar de server
- Server stuurt terug of het wel of niet goed was

Door ook de datum en tijd mee te sturen zit er een stukje beveiliging qua replay-attacks in, maar dat werkt natuurlijk niet met een valse activatie server en aangepaste datum/tijd in de controller.

Je kan ook dubbel-RSA doen. Server en controller hebben elkaars public key en kunnen dus elkaars antwoorden controleren. Probleem dan is dat je een hele zooi keys moet gebruiken om dat het anders weer eenvoudig te vervalsen is.

Naast dit hele verhaal zal je dus (als je controller een beetje goed is) voor de komende 50 jaar een activatie server online moeten houden om dat de controllers anders nooit meer geactiveerd kunnen worden. Bovendien moet de chip/cpu/mcu/SoC beveiligd worden en dus ook geen JTAG/TAP/Serial interface hebben, geen externe ROM/PROM/Flash gebruiken voor het opslaan van keys, een shielded die hebben enz. enz.

Zolang iemand je firmware kan uitlezen kan je beveiliging er uit gehaald worden en het resultaat opnieuw geflasht worden.

[ Voor 36% gewijzigd door johnkeates op 17-05-2016 19:58 ]

[TommyboyNL]

Ik zou dus nooooooit zaken doen met jou. Ga jij mij garanderen dat als ik over 5 jaar zo'n controller in wil zetten (die in de tussentijd op de plank heeft gelegen) de activatieserver nog draait?
Die garantie WIL je misschien wel geven, maar die KAN je simpelweg niet geven. Ik koop wel de Chinese imitatie waar deze achterlijke beveiliging uit gehackt is.

[ Voor 29% gewijzigd door TommyboyNL op 17-05-2016 19:52 ]

[itcouldbeanyone]

TommyboyNL schreef op dinsdag 17 mei 2016 @ 19:51:
Ik zou dus nooooooit zaken doen met jou. Ga jij mij garanderen dat als ik over 5 jaar zo'n controller in wil zetten (die in de tussentijd op de plank heeft gelegen) de activatieserver nog draait?
Die garantie WIL je misschien wel geven, maar die KAN je simpelweg niet geven. Ik koop wel de Chinese imitatie waar deze achterlijke beveiliging uit gehackt is.

Het is dan ook geen product voor de consument.


Het is ook meer ter indicatie hoeveel onze partner er produceert.
Omdat de productie aantallen een paar procent van verekend moet worden
Ik denk dat het inderdaad beter is om het uit te besteden.

[ Voor 11% gewijzigd door itcouldbeanyone op 17-05-2016 20:00 ]

[TommyboyNL]

itcouldbeanyone schreef op dinsdag 17 mei 2016 @ 19:56:
[...]

Het is dan ook geen product voor de consument.


Het is ook meer ter indicatie hoeveel onze partner er produceert.
Omdat de productie aantallen een paar procent van verekend moet worden
Ik denk dat het inderdaad beter is om het uit te besteden.

Wie zegt dat ik als consument? Ook als ik een product of machine zou ontwerpen zou ik niet met jou in zee gaan, vanwege de hierboven genoemde bezwaren (waar jij voor het gemak geen antwoord op gaf).

[CH4OS]

johnkeates schreef op dinsdag 17 mei 2016 @ 19:50:
Denk je serieus dat iemand in China daar door tegen gehouden wordt?

Het is mij anders nog steeds niet duidelijk wat nu exact de bedoeling is, functioneel gezien. Aangezien het ook offline moet werken, zover ik begrijp, maar goed, wat nu precies de bedoeling of wens is, is mij niet duidelijk.

Daarnaast kun je jezelf die vraag natuurlijk stellen bij elke vorm van beveiliging die je inbouwd tbv licenties.

[ Voor 19% gewijzigd door CH4OS op 17-05-2016 20:14 ]

[TommyboyNL]

Dit is een klassiek DRM issue. Zodra de verkopen van het product eruglopen, wordt de productie stopgezet, en een jaar daarna gaan de activatieservers uit de lucht; die kosten immders alleen maar geld terwijl er geen geld meer binnen komt. Dit terwijl je er donder op kan zeggen dat er voldoende ongeactiveerde controllers op de plank liggen als cold-spares (welke dus onverwacht niet meer werken terwijl ze per direct hard nodig zijn).

Deze beunoplossing lijkt nodig te zijn omdat de TS zijn leverancier/partner niet vertrouwt. Daar lijkt mij een heel makkelijke oplossing voor: andere partner zoeken. Alternatieve oplossing zou zijn om de partner niet de software voor in de chips te geven, maar hem geprogrammeerde chips met leesbeveiliging te leveren, welke bovenstaande paar procent per stuk kosten.

[ Voor 5% gewijzigd door TommyboyNL op 17-05-2016 20:14 ]

[itcouldbeanyone]

TommyboyNL schreef op dinsdag 17 mei 2016 @ 20:13:
Dit is een klassiek DRM issue. Zodra de verkopen van het product eruglopen, wordt de productie stopgezet, en een jaar daarna gaan de activatieservers uit de lucht; die kosten immders alleen maar geld terwijl er geen geld meer binnen komt. Dit terwijl je er donder op kan zeggen dat er voldoende ongeactiveerde controllers op de plank liggen als cold-spares (welke dus onverwacht niet meer werken terwijl ze per direct hard nodig zijn).

Deze beunoplossing lijkt nodig te zijn omdat de TS zijn leverancier/partner niet vertrouwt. Daar lijkt mij een heel makkelijke oplossing voor: andere partner zoeken. Alternatieve oplossing zou zijn om de partner niet de software voor in de chips te geven, maar hem geprogrammeerde chips met leesbeveiliging te leveren, welke bovenstaande paar procent per stuk kosten.

ik denk dat ik ze hardware matig dan maar moet gaan beveiligen met een stukje ROM, en deze aan onze partner leveren.

zelf heb ik geen id of dit met vertrouwen of wat dan ook te maken heeft.
mijn baas begon er ineens over.
het enige wat mijn taak is, de controller ontwerpen. (hardware)

ik heb wel gevonden dat er bepaalde bedrijven dit voor je makkelijker kunnen maken
http://www.reprisesoftware.com/index.php

maar aangezien het product een geschatte looptijd heft van 20 jaar, en deze daarna in de praktijk zekers nog een jaar of 10 mee gaat, is het mischien beter om gewoon die ROM naar onze partner op te sturen.

[CH4OS]

Dan kun je wellicht een dongle overwegen?

[itcouldbeanyone]

CH40S schreef op dinsdag 17 mei 2016 @ 20:33:
Dan kun je wellicht een dongle overwegen?

daar willen we juist nu van af.
we zien het veel, dongle 3 euro aan hardware + behuizing. dongle verkoopprijs is 600+

we laten al IC's vooraf programeren bij Atmel. maar op namaak is dat niet helemaal beveiligd.
ik bedoel die chinesen maken alles na. en wil dat risico gewoon verkleinen

[H!GHGuY]

Er zijn chips die read-only zijn, waarin je een certificaat kan stoppen met daarin een unique ID.
Dat certificaat is vervolgens getekend door een CA van jouw organisatie.

Je software kan dan dit certificaat valideren.

Maar om dit secure te doen moet je trusted boot implementeren en dat is een hele hoop meer dan een extra chipje.

[itcouldbeanyone]

H!GHGuY schreef op dinsdag 17 mei 2016 @ 21:17:
Er zijn chips die read-only zijn, waarin je een certificaat kan stoppen met daarin een unique ID.
Dat certificaat is vervolgens getekend door een CA van jouw organisatie.

Je software kan dan dit certificaat valideren.

Maar om dit secure te doen moet je trusted boot implementeren en dat is een hele hoop meer dan een extra chipje.

thankzz ik zal me er eens meer in gaan verdieppen

[TommyboyNL]

Al maak je je verificatie nog zo goed, als je product het waard is om te kopieren, gaat dat gebeuren. Punt. Chinezen draaien hun hand er ook niet meer voor om om een chip te decappen, en dan handmatig de leesprotectie uit te zetten. Tenzij je een complexe en dure cryptocontroller gebruikt, (wat hoogstwaarschijnlijk niet de moeite en het geld waard is) staat je programmacode voor <$1000 op de PC van een chinees. Het is dan een klein kunstje om de check eruit te slopen.

MAAR: Gezien jouw posthistory aangaande dit product, verwacht ik niet dat dit zó uniek, revoutionair, en complex zal zijn dat het het klonen waard zal zijn. Namaken wellicht wel, maar dat ga je toch niet tegen houden met allerlei complexe certificaten, sleutels, verificaties, en echtheidschecks.

[H!GHGuY]

Even een aanvulling:

Verkijk je niet op het werk om dit secure te doen. Er bestaan ook trusted boot chips met pre-bootloader code die eerst de bootloader verifëren om die daarna op te starten, de bootloader controleert dan de kernel, etc.
Maar dit is allemaal behoorlijk veel werk en belangrijker: 1 fout en je beveiliging is niets waard.

Maar aangezien je in B2B zit en niet in de consumenten markt, zou ik het vooral simpel houden. De beste anti-namaak strategie is goede klantencontacten en goede service voor en na verkoop. Over het algemeen willen bedrijven helemaal geen namaak en al zeker geen flauw Chinees afkooksel waar dan een werknemer 3 weken extra mee bezig is om het te laten werken.

Mijn voorstel:
1) Stukje ROM met CA cert en serial number en de software die het serial number toont. Bij elk support issue vraag je de klant over welk toestel/serial het gaat. Vervolgens controleer je dat tegen je database met verkopen (klant X heeft serial numbers 1, 2, 3 en 6 gekocht). Geen serial = geen support.
= beveiliging tegen support requests voor namaak: je steekt geen tijd in zaken die je niet zelf veroorzaakt hebt
2a) Vervolgens kan je in je software code stoppen die de signature in het certificaat valideert. Dit is zonder H/W support onmogelijk waterdicht te krijgen:
= afdoende om ervoor te zorgen dat je S/W niet op namaak hardware draait in een gangbare B2B omgeving, kan met een eenvoudig PROM.
2b) Een extra validatie zou kunnen zijn als je crypto-H/W hebt (waarin het certificaat gebrand zit) waarbij je een nonce kan in de chip laden die dan gesigned met het certificaat terugkomt. Idem als hierboven maar is met een duurdere crypto-chip.
3) Volgende stap is wat mij betreft al grijze zone: je kan de software een call-home laten doen om het certificaat te laten valideren op 1 van de 2 manieren die ik in optie 2 aangaf
= afdoende om kopies van de ROM tegen te gaan, aangezien je duplicaten kan detecteren
Optioneel kun je hier ook consequenties aan verbinden: nag-screens met timers, niet opstarten, etc. Maar hou er rekening mee dat je soms ook gewoon H/W failure hebt die dit veroorzaakt. Wil je je klant die in de shit zit op zo'n moment nog meer in de shit duwen?
...)
n) the full monty: secure boot, tamper-proofing op alle niveau's en crypto-checks in elke boot-stage. Verificatie van alle ROMs en software, ....

Maar nogmaals in B2B zijn enkele eenvoudige checks met wat zichtbare meldingen dat er iets loos is meestal voldoende. Koppel daar goeie support en klantenrelaties aan en je hebt genoeg.

[Tarquin]

Je schrijft dat je dit aan het onderzoeken bent nav een opmerking van je baas.

In mijn ervaring is security altijd supersexy, en erg verleidelijk om supergave beveiligingen te bedenken.
Totdat inderdaad iemand de schroeven los draait en één draadje doorverbindt.

Verder maken de Chinezen niet alles na.
Het hangt er vooral van af wat jij verkoopt.

Verkoop je controllers? Of verkoop je de service om zo'n controller af te stellen en draaiend te houden?
Het eerste kun je namaken; het tweede niet.

Als alternatief voor beveiliging kun je ook software licenties verkopen.
Iedereen die bij jullie een controller koopt krijgt een link naar jullie server. Die activeert alle software en stuurt ook regelmatig updates.
Doordat je *geen* beveiliging inbouwt, hoeft China die er ook niet uit te slopen. Maar jullie gaan wel kijken wie de activaties en de software-updates allemaal download. En als dat namaakproducten zijn, ga je achter die gebruikers aan met een copyright-aanklacht.