Monday, March 6. 2006
Lizenzierung für dotnet-Programme
Aufgabe: ein dotNet-Programm soll ein Lizenzmodul bekommen. Features sollen freischaltbar und optional mit Ablaufdatum versehen werden..
Jetzt kann man sich einen Lizenzkey wie von Windows bekannt irgendwie zusammenrechnen und damit einige Nachteile in Kauf nehmen oder man nimmt eine schöne Lösung: Anwendungslizenzen mit digitalen XML-Signaturen
Aber erstmal zu den Nachteilen eines einfachen Lizenzkey:
Ein Vorteil eines Lizenzkeys ist aber seine feste Länge.
Jetzt ein paar Überlegungen:
Warum eigentlich die Informationen verschlüsseln oder hashen? Die Information an sich muss doch nicht versteckt werden - nur ihre Validität muss gewährleistet sein.
Informationen speichert man heutzutage in XML-Dateien. Vorteil: sowohl von Maschine als auch Mensch leicht lesbar - eine beispielhafte Lizenz-Datei könnte z.B. so aussehen:
<license>
<expires>2006-12-31T00:00:00</expires>
<feature>
<name>MeinFeature</name>
<expires>2005-12-31T00:00:00</expires>
</feature>
<feature>
<name>MeinFeature2</name>
</feature>
</license>
Den Anspruch Informationen in einer XML-Datei abzusichern erfüllen digitale XML-Signaturen.
Dafür bedient man sich einfach der asymmetrischen Verschlüsslung/Signatur und setzt in dem Fall einfach die Signatur als neues Element in die XML-Datei:
[SignatureValue ist hier gekürzt, da der String sehr lang ist]
Die eigentlichen Informationen bleiben bestehen und können nun ohne die Signaturprüfung fehlschlagen zu lassen nicht mehr verändert werden. Alternativ kann die Signatur auch in eine neue Datei geschrieben werden - dann müssen aber zwei Dateien an den Kunden ausgeliefert werden: Lizenzdatei und Lizenzsignaturdatei.
Vorteile:
Ein Beispielprojekt für das ganze gibt es bei CodeProject: Using XML Digital Signatures for Application Licensing.
Jetzt kann man sich einen Lizenzkey wie von Windows bekannt irgendwie zusammenrechnen und damit einige Nachteile in Kauf nehmen oder man nimmt eine schöne Lösung: Anwendungslizenzen mit digitalen XML-Signaturen
Aber erstmal zu den Nachteilen eines einfachen Lizenzkey:
- Speichermenge begrenzt
- Key muss zurückrechenbar sein
Ein Vorteil eines Lizenzkeys ist aber seine feste Länge.
Jetzt ein paar Überlegungen:
Warum eigentlich die Informationen verschlüsseln oder hashen? Die Information an sich muss doch nicht versteckt werden - nur ihre Validität muss gewährleistet sein.
Informationen speichert man heutzutage in XML-Dateien. Vorteil: sowohl von Maschine als auch Mensch leicht lesbar - eine beispielhafte Lizenz-Datei könnte z.B. so aussehen:
CODE:
<license>
<expires>2006-12-31T00:00:00</expires>
<feature>
<name>MeinFeature</name>
<expires>2005-12-31T00:00:00</expires>
</feature>
<feature>
<name>MeinFeature2</name>
</feature>
</license>
Den Anspruch Informationen in einer XML-Datei abzusichern erfüllen digitale XML-Signaturen.
Dafür bedient man sich einfach der asymmetrischen Verschlüsslung/Signatur und setzt in dem Fall einfach die Signatur als neues Element in die XML-Datei:
CODE:
<license>
<expires>2006-12-31T00:00:00</expires>
<feature>
<name>MeinFeature</name>
<expires>2005-12-31T00:00:00</expires>
</feature>
<feature>
<name>MeinFeature2</name>
</feature>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>zy7NouuPtItDJ2H2Ronc66uZH3U=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>FkvvXy3 [....] xd8=</SignatureValue>
</Signature>
</license>
<expires>2006-12-31T00:00:00</expires>
<feature>
<name>MeinFeature</name>
<expires>2005-12-31T00:00:00</expires>
</feature>
<feature>
<name>MeinFeature2</name>
</feature>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>zy7NouuPtItDJ2H2Ronc66uZH3U=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>FkvvXy3 [....] xd8=</SignatureValue>
</Signature>
</license>
[SignatureValue ist hier gekürzt, da der String sehr lang ist]
Die eigentlichen Informationen bleiben bestehen und können nun ohne die Signaturprüfung fehlschlagen zu lassen nicht mehr verändert werden. Alternativ kann die Signatur auch in eine neue Datei geschrieben werden - dann müssen aber zwei Dateien an den Kunden ausgeliefert werden: Lizenzdatei und Lizenzsignaturdatei.
Vorteile:
- UTF8-kompatibel
- leichter zu debuggen als ein Aufwändiger Algorithmus für einen "normalen" Lizenzkey
- Neue Signatur auch vor Ort beim Kunden erstellbar - der Supporter braucht nur den privaten Key und eine kleine Anwendung
- Man kann relativ leicht neue Felder und Attribute hinzufügen - wenn man aufpasst sogar mit Rückwärtskompatiblität
- Man kann quasi beliebig viel speichern
- Lizenzdatei ist vom Supporter lesbar - er kann sofort sagen, wann Feature xy ablaufen wird
- basiert auf Standards
Ein Beispielprojekt für das ganze gibt es bei CodeProject: Using XML Digital Signatures for Application Licensing.
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Quicksearch
Statische Seiten
Calendar
|
February '12 | |||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | ||||
Kategorien
Blog abonnieren
Creative Commons
Blog Administration
Show tagged entries
26c3 cisco Coding darmstadt dhcp dotNet fachschaft Failover Foto Fun Gadgets Games General gremienarbeit Hacking Handy Hardware Internet Java Kino LAN-Party Linux Microsoft netzwerk Office openldap PHP planspiel Redundanz Server staub studierende Studium stupa switch TV twitter Verwaltung Virtual Server Wahlen Windows Work ältestenrat