in virtuellen Umgebungen Rüdiger Kügler, Professional Services Security Expert, WIBU-SYSTEMS AG www.wibu.com
Inhalt Einleitung 3 Bedrohungen und Herausforderungen durch virtuelle Maschinen 4 Bedrohungen und Herausforderungen durch Terminal Server 5 Veraltete Lösungsansätze 6 Die moderne Lösung: 6 Wir zählen für Sie: License Quantity 7 Lizenz auf einem Lizenzserver im Netzwerk 7 CmDongle: Nur einer kann ihn haben 8 CmDongle auf dem Host-System 10 CmDongle am USB-over-Ethernet 10 CmActLicense auf dem Host-System 11 CmActLicense in einem -System 12 Lizenzmanagement für den Anwender 13 Terminalserver Client 14 Hochverfügbarkeit und Sicherheit 14 Fazit 15 Autor: Seine ersten en entwickelte Rüdiger Kügler während seines Physikstudiums in FORTRAN, C und Assembler. Nach dem Abschluss seines Studiums 1995 war er als Projektmanager und Abteilungsleiter für Projekte in den Bereichen Software-Schutz, Software-Distribution, Internet-Banking und Multimedia verantwortlich. Seit 2003 arbeitet Rüdiger Kügler als Security Expert bei Wibu-Systems und leitet das Professional Services Team. Kernkompetenzen sind der Schutz von Software gegen Reverse Engineering, die Integration von Lizenzierung in die internen Geschäftsprozesse von Softwareherstellern und die Optimierung der Verteilungs- und Verwaltungsprozesse für Software und Lizenzen. In dieser Position war er maßgeblich an der Entwicklung der Blurry Box Technology beteiligt, die 2014 den ersten Platz beim 5. Deutschen IT-Sicherheitspreis der Horst Görtz Stiftung belegte. 2
Einleitung IT-Abteilungen schätzen die Vorteile von virtuellen Maschinen und Terminal Servern: weniger Hardware kann effektiver genutzt werden und im Fehlerfall ist eine Wiederherstellung sehr einfach. Als Softwarehersteller betrachten Sie virtuelle Maschinen vermutlich mit gemischten Gefühlen. Auf der einen Seite bieten Ihnen virtuelle Maschinen eine einfache Möglichkeit, Ihre Software in einer definierten Umgebung zu testen. Auf der anderen Seite stellen Sie diese, ebenso wie Terminal Server, vor große Herausforderungen bei der Lizenzierung ihrer Software. Dabei sind Lizenzierung und Schutz gegen Raubkopien ein wichtiger Punkt für den Erfolg Ihrer Software. bietet Ihnen ein mächtiges Werkzeug, welches eine sichere und zuverlässige Lizenzierung sowohl in virtuellen Maschinen, als auch auf Terminal Servern erlaubt. Dieses Whitepaper beschreibt die unterschiedlichen sfälle und zeigt Ihnen die Realisierungsmöglichkeiten mit. Software Abbildung 1: Überblick Runtime Service Dongle Lizenz-Datei Lizenz-Server Cloud-Lizenz bietet Ihnen hierbei die Option für jeden Kunden individuell zwischen den folgenden Lizenzträgern zu wählen: <Dongle < (CmDongle: Speichert alle Lizenzen in einer sicheren externen Hardware) <Lizenz-Datei < (CmActLicense: Rechnergebundene und verschlüsselte Lizenzdatei) <Lizenz-Server < (Server im LAN oder WAN) <Cloud-Lizenz < (CmCloud: Speichert alle Lizenzen in der Cloud) 3
Bedrohungen und Herausforderungen durch virtuelle Maschinen Eine virtuelle Maschine ist eine simulierte Hardware auf einem Rechner (Host, bzw. Master). In dieser simulierten Hardware läuft ein komplettes (, bzw. Child). Die Interaktionsmöglichkeiten des -Systems mit der Umgebung sind in der Regel stark eingeschränkt. Alle -Systeme und der Host teilen sich die real existierende Hardware, wobei die -Systeme oft keinen direkten Zugriff auf die reale Hardware haben. Das -System sieht eine simulierte virtuelle Hardware. Virtuelle Maschinen können einfach gesichert und später wiederhergestellt, d.h. auf einen früheren Zustand zurückgesetzt, werden. Abbildung 2: Architektur virtueller Maschinen Virtualisierungssoftware Host Host Virtuelle Maschinen stellen aus der Sicht der Lizenzierung damit folgende Bedrohungen dar: Bei Nutzung eines Dongles: <Mehrfachnutzung < einer Lizenz durch gleichzeitige Verwendung eines Dongles in mehreren -Systemen. Bei Nutzung einer reinen Softwarelizenzierung: <Zurücksetzen < von zeitlich limitierten Lizenzen und Pay-Per-Use Lizenzen durch einspielen eine Kopie oder eines Snapshots. <Duplizieren < von rechnergebundenen Lizenzen durch Klonen der kompletten virtuellen Maschine. Aber auch für den Anwender Ihrer Software sind die folgenden Herausforderungen zu meistern: <Anschließen < eines Dongles an eine virtuelle Maschine. <Hochverfügbarkeit < für einen Lizenzserver in virtuellen Maschinen. 4
Bedrohungen und Herausforderungen durch Terminal Server Bei einem Terminal Server wird die Software auf dem Server installiert. Die Software wir auf dem Server ausgeführt und der Anwender besitzt lediglich einen Client, der den Bildschirm vom Server auf den Rechner des Anwenders überträgt. Auf einem Terminal Server können dabei viele Anwender gleichzeitig arbeiten. Jeder Anwender hat seine eigene Session, in der er sich unabhängig von anderen Anwendern befindet. Alle Sessions teilen sich die Hardware auf dem Server. Lediglich Maus, Tastatur und andere Peripheriegeräte werden vom Client bereitgestellt. Abbildung 3: Architektur eines Terminalservers Session Verbundenes lokales Gerät Verbundenes lokales Gerät Terminal Server Software Session Server Hier existieren die folgenden Bedrohungen: <Mehrfachnutzung < einer Lizenz in mehreren Sessions auf dem Terminal Server gleichzeitig. <Nutzung < einer Einzelplatzlizenz als Floating Netzwerk Lizenz. Als Herausforderung stellt sich das folgende Szenario dar: <Wie < kann ich eine Lizenz auf dem Terminal Server für definierte User zugänglich machen. <Wie < kann eine Lizenz, die sich auf dem Client befindet, auf dem Terminal Server verwenden. 5
Veraltete Lösungsansätze Ein Lösungsansatz ist die Erkennung von virtuellen Maschinen und Terminal Servern in Ihrer Software. Sobald Sie eine entsprechende unerwünschte Umgebung entdecken, beenden Sie Ihre Software mit einer Fehlermeldung. Dieser Lösungsansatz ist veraltet: Bei diesem Ansatz verschenken Sie Umsatz, da Sie sich der virtuellen Welt komplett entziehen. Jeder Rechner mit einem Remote Desktop Zugang ist automatisch ein Terminal Server und kann somit auch nicht mit Ihrer Software verwendet werden. Hinzu kommen Aufwand für Integration und Pflege der Erkennung in Ihrer Software. Abbildung 4: Veraltete Lösungsansätze Verbundenes lokales Gerät Verbundenes lokales Gerät Virtualisierungssoftware Host Host Terminal Server Software Server Bei diesem Ansatz steht die Frage Wo läuft die Software? im Vordergrund. Aber ist die entscheidende Frage ist eigentlich: Wo befindet sich die Lizenz? verfolgt diesen Ansatz und bietet Ihnen damit eine generische, flexible und automatisch einsetzbare Lösung. Die moderne Lösung: Ein wesentlicher Bestandteil der Architektur ist der Runtime Service (.exe). Dies ist ein Dienst / Dämon, den Sie mit Ihrer Software auf dem Rechner des Anwenders installieren. Die Installation des Runtime Service können Sie komplett und unsichtbar in Ihrer Installation integrieren. Der Runtime Service ist für Windows, Linux und OS X verfügbar. Abbildung 5: im Netzwerk Software Runtime Service Runtime Service Dongle Lizenz-Datei Cloud-Lizenz Netzwerk Lizenzserver Netzwerk Client Der Runtime Service verwaltet alle angeschlossenen CmDongles und alle verfügbaren CmActLicenses und stellt die Lizenzen für Ihre Software zur Verfügung. 6
Auf einem Lizenzserver im Netzwerk installiert der Anwender lediglich den Runtime Service und konfiguriert diesen als Netzwerk-Lizenzserver. In diesem Fall kommuniziert Ihre Software mit einem lokalen Runtime Service. Dieser kommuniziert mit dem Runtime Service auf dem Netzwerkserver und dieser verwaltet und verteilt seine verfügbaren Lizenzen. Wir zählen für Sie: License Quantity Jede Lizenz im Universum besitzt eine License Quantity. Diese setzen Sie als Softwarehersteller beim Erzeugen der Lizenz. Der Standardwert ist 1. In Ihrer Software legen Sie bei der Integration von fest, wie gezählt werden soll. Sie können dabei zwischen: pro Zugriff, pro Rechner und nicht zählen wählen. Lizenzen in einem CmDongle, in einer lokalen CmActLicense oder auf einem License Server werden dabei komplett gleich behandelt. Pro Zugriff - UserLimit Bei der Zählweise pro Zugriff wird bei jedem Zugriff (API Befehl CmAccess2) automatisch eine Lizenz belegt. Beim Freigeben der Lizenz (API Befehl CmRelease) wird diese Lizenz freigegeben. Die Lizenz kann nur so oft gleichzeitig belegt werden, wie es der Wert in License Quantity erlaubt. Pro Rechner - StationShare Bei der Zählweise pro Rechner werden von automatisch Informationen über die Umgebung der Software (Session, IP Adresse, Prozess-ID, ) erfasst und an den Runtime Service geschickt. Diese Informationen werden verwendet, um automatisch jeden Rechner, jede Session auf einem Terminal Server und jede virtuelle Maschine als separaten Rechner zu identifizieren. Eine Lizenz mit der License Quantity von drei kann beispielsweise in zwei Terminal Server Sessions und einer virtuellen Maschine gleichzeitig verwenden werden. In jeder der beiden Sessions und in der virtuellen Maschine beliebig oft. Automatische Freigabe Über die Prozess-ID erkennt der Runtime Service, ob Ihre Software noch läuft. Selbst wenn Sie die Freigabe der Lizenz in Ihrer Software vergessen würden oder im unwahrscheinlichen Fall Ihre Software abstürzt, der Runtime Service erkennt dies und gibt die Lizenz automatisch wieder frei. Lokale Lizenz Eine besondere Bedeutung hat die License Quantity 0. Dies stellt eine lokale Einzelplatzlizenz dar. Es wird dabei gezählt wie bei einer License Quantity von 1, aber die Lizenz, d.h. der CmDongle oder die CmActLicense, muss sich am selben Rechner, bzw. in derselben virtuellen Maschine befinden. unterscheidet automatisch zwischen einem echten Terminal Server und einem Remote Desktop. Die Nutzung einer Lizenz mit License Quantity 0 ist in einer Session auf einem echten Terminal Server verboten, auf einem lokalen Rechner mit Remote Desktop aber erlaubt. Lizenz auf einem Lizenzserver im Netzwerk Der Runtime Service wird vom Anwender auf einem Server im Netzwerk installiert und als Netzwerk- Lizenzserver konfiguriert. Der CmDongle wird mit diesem Rechner verbunden, bzw. die CmActLicense wird anhand von Eigenschaften des Servers aktiviert und an diesen Server gebunden. Alle verfügbaren Lizenzen auf diesem Lizenzserver können sofort in virtuellen Maschinen und auf einem Terminalserver verwendet werden. Anhand der License Quantity zählt der Netzwerk-Lizenzserver automatisch die gleichzeitig erlaubten Rechner, virtuellen Maschinen und Sessions auf Terminal Servern. Als Softwarehersteller liefern Sie lediglich eine Lizenz mit einer entsprechenden License Quantity an den Anwender aus. 7
CmDongle: Nur einer kann ihn haben Sie können einen CmDongle wahlweise als Mass Storage Device (MSD) oder als Human Interface Device (HID) konfigurieren. Da dabei ein Standardtreiber verwendet wird, ist eine Zuweisung zu einer virtuellen Maschine in allen aktuellen en möglich. Durch eine verschlüsselte Kommunikation wird die Sicherheit bei der Verwendung eines Standardtreibers für HID, bzw. MSD sichergestellt. CmDongle nur im exklusiven Modus Verwendet Ihr Anwender ein USB Gerät (wie z.b. einen CmDongle) auf einem Host mit mehreren -Systemen, dann bietet die Virtualisierungssoftware wahlweise eine exklusiven oder einen geteilten Modus. Im exklusiven Modus steht das USB Gerät nur einem oder dem Host exklusiv zur Verfügung. Im geteilten Modus können mehrere Systeme gleichzeitig auf das USB Gerät zugreifen. Der Runtime Service in einem -System erkennt und verwendet nur CmDongles, die exklusiv diesem -System zugewiesen wurden. CmDongles im geteilten Modus werden automatisch blockiert. Damit ist die gleichzeitige Verwendung eines CmDongles in mehreren -Systemen ausgeschlossen. Abbildung 6: Ein CmDongle exklusiv in einem -System Nutzung der Lizenzen möglich Virtualisierungssoftware Host Host 8
Abbildung 7: Ein CmDongle im geteilten Modus Nutzung der Lizenzen nicht möglich Virtualisierungssoftware Host Host Keine Mehrfachnutzung des CmDongles möglich Doch was ist mit einem automatischen nacheinander Durchreichen eines CmDongles von einem -System zum nächsten -System. Auch hier gibt es im Runtime Service und in jedem CmDongle Automatismen, die dies verhindern. Ein Runtime Service kann zwar gleichzeitig auf mehrere CmDongles und CmActLicenses zugreifen. Aber ein CmDongle wird immer nur exklusiv von einem Runtime Service verwendet. Dies wird technisch durch einen Zustand im CmDongle realisiert, der beim Aufbau der verschlüsselten Kommunikation zwischen Runtime Service und CmDongle gesetzt wird. Wird der CmDongle jetzt mit einem anderen Runtime Service verbunden, dann wird dieser Zustand zerstört. Die im ersten Runtime Service belegte Lizenz wird automatisch freigegeben und Ihre Software kann darauf entsprechend reagieren. Ein weiterer Automatismus sorgt dafür, dass ein automatisches schnelles Umstecken (sowohl ein Wechsel zwischen virtuellen Maschinen, als auch ein Reverse USB-Hub) eines CmDongles vom Normalbetrieb unterschieden wird. Wird dieses Angriffsszenario erkannt, dann wir der CmDongle automatisch für 5 Minuten gesperrt. Als Softwarehersteller können Sie sich zurücklehnen, erledigt alles automatisch für Sie. 9
CmDongle auf dem Host-System Falls das Host-System ein Standard- wie Windows, Linux oder OS X ist, dann kann der Anwender den Runtime Service auf diesem Host-System installieren und diesen als Netzwerk-Lizenzserver zu konfigurieren. Er belässt den CmDongle direkt im Host-System und weist ihn keinem -System zu. Unter der Voraussetzung, dass das entsprechende -System eine TCP/IP Verbindung zum Host-System besitzt und die License Quantity in der Lizenz mindestens 1 beträgt, kann eine Software in diesem -System wie eine Software auf einem Client im Netzwerk agieren und die Lizenz auf dem Netzwerk-Lizenzserver des Host-Systems belegen. Der Netzwerk-Lizenzserver auf dem Host-System stellt automatisch sicher, dass die Lizenz nicht öfter gleichzeitig verwendet wird, als in License Quantity vorgegeben. Bei einer License Quantity von 1, kann die Lizenz maximal in einem -System zur gleichen Zeit verwendet werden. Abbildung 8: Lizenzserver auf dem Host-System Virtualisierungssoftware License Quantity > 0 Host Host License Quantity > 0 Als Softwarehersteller liefern Sie lediglich eine Lizenz mit einer entsprechenden License Quantity, in der Regel mit dem Wert = 1, an den Anwender aus. CmDongle am USB-over-Ethernet Ein CmDongle kann mittels eines USB-over-Ethernet Gerätes auch in einer virtuellen Umgebung verwendet werden, die kein Durchreichen eines USB-Anschlusses ermöglicht. Hier gelten die gleichen Regeln wie beim direkten Durchreichen an eine virtuelle Maschine auf USB- Ebene. Ein CmDongle kann nur exklusiv von einem Runtime Service gleichzeitig verwendet werden. Ein Umstecken des CmDongles wird erkannt und führt zur automatischen Freigabe der Lizenz, auf den die Software reagieren kann. Ein schnelles automatisches Wechseln zwischen vielen Geräten wird als Angriff erkannt und führt zur 5-minütigen Sperre des CmDongles. Auch hier können Sie sich als Softwarehersteller zurücklehnen, da alles automatisch für Sie erledigt. 10
CmActLicense auf dem Host-System Eine CmActLicense auf dem Host-System funktioniert analog zu einem CmDongle. Der Anwender installiert den Runtime Service und konfiguriert diesen als Netzwerk-Lizenzserver auf dem Host-System. In diesem Fall wird der Fingerabdruck für die Bindung der CmActLicense anhand der realen Hardwareeigenschaften auf dem Host-System erzeugt. SmartBind ermittelt dabei viele Eigenschaftswerte der realen Hardware, gewichtet diese nach Ihrer Güte und bildet so einen Fingerabdruck. Die von Ihnen als Softwarehersteller erzeugte CmActLicense ist dann an dieses Host-System gebunden und kann nur auf diesem Host-System verwendet werden, bzw. durch einen Netzwerk-Lizenzserver auf diesem Host-System an andere Rechner oder -Systeme zur Verfügung gestellt werden. Durch das Setzen der License Quantity legen Sie als Softwarehersteller fest, ob die Lizenz nur lokal auf dem Host-System oder auch als Netzwerkclient in einem -System verwendet werden kann. Als Softwarehersteller legen Sie ebenfalls fest, wie tolerant die CmActLicense gegenüber Änderung an der Hardware des Host-Systems ist. Sie können zwischen Lose, Medium und Strikt wählen. Abbildung 9: CmActLicense an das Host-System gebunden Virtualisierungssoftware License Quantity > 0 Host Host License Quantity > 0 Kann der Anwender die gleiche CmActLicense nicht in jedem -System auf dem gleichen Host-System verwenden? Alle Systeme teilen sich ja die gleiche Hardware. Nein: Eine Lizenzvervielfältigung durch den Versuch die gleiche CmActLicense direkt in einem -System auf der gleichen Hardware zu verwenden wird durch automatisch verhindert. 11
CmActLicense in einem -System Eine CmActLicense kann in einem -System aktiviert werden. Als Softwarehersteller haben Sie die Möglichkeit dies zu erlauben oder zu verbieten. SmartBind angepasste Rezeptur Der Runtime Service erkennt automatisch, dass er sich in einem -System befindet. Bei der Ermittlung und der Gewichtung der Hardwareeigenschaften verwendet SmartBind automatisch eine auf virtuelle Umgebungen angepasst Rezeptur. Damit werden Eigenschaften, die von der realen Hardware stammen automatisch höher gewichtet als Eigenschaften, die nur virtuell vorhanden sind. Eigenschaften, die sich beim Umziehen auf einen anderen Computer ändern erhalten ebenfalls eine entsprechend höhere Gewichtung. Abbildung 10: CmActLicense in einem - System Virtualisierungssoftware Host Host Schutz gegen Klonen eines -Systems Durch SmartBind ist eine CmActLicense maximal gegen das Klonen des kompletten -Systems geschützt. In den Toleranz-Stufen Medium und Strikt wird das Kopieren des -Systems auf eine andere Hardware automatisch erkannt und die CmActLicense ist gebrochen und kann nicht mehr verwendet werden. Da der Fingerabdruck bei als kryptographischer Schlüssel in die Sicherheit eingeht, kann die CmActLicense nicht einfach durch das Patchen einer Abfrage repariert werden. Ohne die passenden Hardwareeigenschaften ist eine Nutzung der CmActLicense nicht möglich. Verschieben des -Systems Wird ein -System innerhalb desselben Host-Systems verschoben, dann bleibt die CmActLicense gültig. Damit führen Änderungen an der Konfiguration durch den Anwender nicht gleich zu einem Supportfall bei Ihnen als Softwarehersteller. Dies stellt keine Bedrohung für Sie als Softwarehersteller dar, da ein verschobenes -System in der Regel nicht mehrmals gleichzeitig auf einem Host-System verwendet werden kann. Das Verschieben eines -Systems auf ein anderes Host-System hat zwei Aspekte. Auf der einen Seite stellt dies eine Bedrohung dar, weil danach das gleiche -System und damit auch die gleiche Lizenz doppelt vorhanden sind. Auf der anderen Seite ist dies aber genau die Hochverfügbarkeitslösung. Als Softwarehersteller können Sie sich entscheiden, in welche Richtung Sie konfigurieren können. SmartBind in den Stufen Medium und Strikt erkennt das Verschieben auf ein anderes Host-System mit mehr als 98%iger Zuverlässigkeit. Dies ist die beste Erkennungsrate die mit dem aktuellen Stand der Technik möglich ist. Durch Wahl von SmartBind in der Stufe Lose oder durch die Wahl einer schwächeren Bindung wie Zufallszahl oder IP- Adresse können Sie Softwarehersteller definieren, dass eine Lizenz in einem -System mit dem Verschieben auf ein anderes Host-System mitwandert. Damit haben Sie Möglichkeit eine Hochverfügbarkeit bei Kunden einfach zu realisieren. 12
Lizenzmanagement für den Anwender bietet dem Anwender der Software die Möglichkeit, Lizenzen für bestimmte Rechner, Benutzer oder Benutzergruppen aus dem Active Directory zu reservieren. Damit kann der Anwender sicherstellen, dass nur berechtigte Mitarbeiter die verfügbaren Lizenzen benutzen. Vor allem in dem Fall, dass sowohl die geschützte Software, als auch der Runtime Service auf einem Terminalserver laufen, kann damit sichergestellt werden, dass Lizenzen nicht durch Unberechtigte blockiert werden. Bei Floating Netzwerk Lizenzen kann der Anwender diese ganz flexibel seinen Mitarbeitern zuordnen. 10 verfügbare Lizenzen können z.b. in 3 Lizenzen für die Supportabteilung, 4 Lizenzen für Entwicklungsabteilung und 3 weitere Lizenzen zur freien Verfügung verteilt werden. Ebenfalls ist es möglich, den Zugriff für Rechner, Benutzer und Gruppen einzuschränken. Die entsprechenden Geräte oder Personen dürfen dann eine eingestellte Maximalanzahl nicht übersteigen. Über eine detaillierte Aufstellung der Belegungszeiten kann der Anwender die Benutzung der Lizenzen auswerten und somit sowohl Engpässe als auch Reserven erkennen. 13
Terminalserver Client In einigen sfällen ist es notwendig, dass sich die Lizenz am Terminal Server Client befindet. In diesem Fall wird auf dem Client der Runtime Service installiert und als Netzwerkserver konfiguriert. Die geschützte Software auf dem Terminalserver erhält die IP-Adresse oder den Rechnernamen des Client und öffnet eine Verbindung zum Lizenzserver auf dem Client. Über die Zugriffskontrolle am Client kann der Anwender sicherstellen, dass die Lizenz nur von ihm selber verwendet werden kann. Der Terminalserver benötigt für diese Installation lediglich eine direkte TCP/IP Verbindung zum Client über Port 22350. Abbildung 11: CmDongle am Client Verbundenes lokales Gerät Terminal Server Software Session Server Client Hochverfügbarkeit und Sicherheit Eine Hochverfügbarkeit im nicht vertrauenswürdigen Umfeld erfordert die Einführung einer Netzwerk-Lizenzserver Lösung mit einer 2 aus 3 Redundanz. Ihr Anwender erhält von Ihnen als Softwarehersteller drei identische zusammengehörige Netzwerk-Lizenzserver. Ihre Software verbindet sich zu allen drei Servern. Dabei müssen mindestens zwei Server jeweils verfügbar sein und entsprechende Lizenzen auf allen verfügbaren Servern vorhanden sein. Damit ist sichergestellt, dass im Fall, dass ein Server ausfällt Ihre Software auch weiterhin verfügbar ist. Die drei Netzwerk-Lizenzserver können Sie dabei wahlweise mit einem CmDongle oder einer CmActLicense ausstatten. Auch eine Mischung zwischen CmDongle und CmActLicense ist möglich. Im Falle eines CmActLicense können Sie definieren, ob der Netzwerk-Lizenzserver auf einem realen System oder in einer virtuellen Maschine laufen darf und wie tolerant die CmActLicense gegenüber Veränderung und Verschiebung reagieren soll. 14
Fazit ist für den Einsatz in virtuellen Umgebungen und auf Terminal Servern bestens gerüstet und bietet Ihnen eine schlüsselfertige Lösung, die alle sszenarien abdeckt. < < bietet Ihnen eine einheitliche Lösung für reale und virtuelle Systeme. < < bietet höchsten Schutzlevel gegen Lizenzmissbrauch. < < ist einfach in Ihre Software zu integrieren. < < zählt die Lizenzbenutzung so, wie Sie es erwarten. < < kann flexibel an Ihre individuellen Bedürfnisse angepasst werden. Mit behalten Sie die Kontrolle über ihr Geschäft und gestalten ihre Lizenzmodelle in virtuellen Umgebungen genauso flexibel und sicher wie bei realer Hardware. 15
Zentrale WIBU-SYSTEMS AG Rüppurrer Str. 52-54, 76137 Karlsruhe Tel.: +49 721 93172-0 Fax :+49 721 93172-22 sales@wibu.com www.wibu.com WIBU-SYSTEMS Niederlassungen WIBU-SYSTEMS (Shanghai) Co., Ltd. Shanghai: +86 21 556 617 90 Peking: +86 10 829 615 60 info@wibu.com.cn WIBU-SYSTEMS NV/SA Belgien Luxemburg +32 3 808 03 81 sales@wibu.be WIBU-SYSTEMS sarl Frankreich +33 1 86 26 61 29 sales@wibu.fr WIBU-SYSTEMS USA, Inc. USA: +1 800 6 Go Wibu +1 425 775 6900 sales@wibu.us WIBU-SYSTEMS LTD Vereinigtes Königreich Irland +44 20 314 747 27 sales@wibu.co.uk WIBU-SYSTEMS BV Niederlande +31 74 750 14 95 sales@wibu-systems.nl WIBU-SYSTEMS IBERIA Spanien Portugal + 34 91 123 07 62 sales@wibu.es WIBU-SYSTEMS, 1989 von Oliver Winzenried und Marcellus Buchheit gegründet, ist Technologieführer für Softwareschutz und Lizenz-Lifecycle-Management weltweit. Die einzigartige, äußerst sichere und flexible -Technologie unterstützt Softwarehersteller und Hersteller intelligenter Geräte. Wibu-Systems hat umfangreiche, vielfach ausgezeichnete Lösungen mit softwarebasierter Aktivierung oder hochsicherer Schutzhardware entwickelt, die international patentiert sind und zum Integritätsund Kopierschutz digitaler Werte und geistigen Eigentums eingesetzt werden. Mit dem Motto Perfection in Protection, Licensing and Security widmet sich Wibu-Systems dem Schutz geistigen Eigentums in Geräten und en vor widerrechtlicher und unzulässiger Nutzung, Nachbau, Sabotage, Spionage oder Cyberangriffen und gleichzeitig dem erfolgreichen Einsatz neue Geschäftsmodelle und deren Integration in bestehenden ERP-, CRM- und E-Commerce-Plattformen. Wibu-Systems behält sich das Recht vor, Programme oder Dokumentationen ohne Ankündigung zu ändern. Wibu-Systems,, SmartShelter, SmartBind, Blurry Box sind eingetragene Markenzeichen der WIBU-SYSTEMS AG. Alle anderen Firmen- und -Produktnamen sind eingetragene Marken der jeweiligen Eigentümer. 5062-005-02/20161118 Wibu-Systems 2016