2.1. Patente und Linux

Microsoft ist die Nummer eins unter den kommerziellen Unternehmen, die gegen Linux schwere Vorwürfe erhebt, noch vor SCO.com. Unter http://www.microsoft.com/mscorp/ip/tech/fat.asp erhebt Microsoft Patentansprüche für das FAT File - System, welches früher in DOS und heutzutage noch in USB - Sticks und Kameras verwendet wird. Diese Patente betreffen die gleichzeitige Nutzung von überlangen Dateinamen in der FAT, sie auch US - Patentoffice Datenbank:

• U.S. Patent #5,579,517

• U.S. Patent #5,745,902

• U.S. Patent #5,758,352

• U.S. Patent #6,286,013

Eines der Patente wurde vorläufig zurückgewiesen, die anderen Patente erteilt. User, die FAT unter Linux nutzen, müssen also mit 0.25$ je Linux Workstation plus evtl. Kosten für Microsoft Patentanwälte rechnen. Problematisch für Linux Anwender sind nach Angabe von Steven Ballmer, Microsoft - Chef, insgesamt 283 Patente, wie er am 18.11.2004 bei einem Vortrag bei einem Treffen aller asiatischen Regierungs - Chefs in Singapur erwähnte. Insgesamt wurden bisher 283 Patente gefunden, davon stammen 60 von IBM, 20 von HP/Compaq, 11 von Intel, 27 von Microsoft, 98 von Firmen, die Linux, ähnlich wie IBM und Novell, sehr positiv gegenüber gesonnen sind, und 59 von diversen anderen Firmen, darunter auch SCO. Micosoft, HP/Compaq und IBM melden jährich zwischen 1700 und 3500 neue Patente an.

Microsoft selber hingegen verletzt(e) selber über 511 Patente, und hat diese Prozesse bereits verloren: Timeline Inc.: US Patent # 5,802,511, 6,023,694, 6,026,392

Brisant daran ist, daß diese drei Patente von Timeline nicht nur weitere 511 Patente beinhalten, sondern Microsoft diese Patente zwar lizensiert hat, jedoch diese nicht in jedem Fall genutzt werden dürfen. Diese beinhalten u.a. Patentrechte an folgenden Techniken:

• Automatische Erkennung des Datenformates und automatische Generierung eines Treibers.

• Write Back Caching in eine Datenbank

• Daten aus mehreren Quellen in eine Zieldatenbank umleiten.

• Natürlichsprachliche Abfrage von Datenbanken (siehe "Frage und Antwort")

• Reporting Tools für Datenbanken.

• Caching von Query - Results. ...

Siehe auch Microsofts Stellungnahme zu den Timeline - Patenten. Hier scheint es, daß Microsoft seine Kunden vor Ansprüchen gegenüber Timeline durch Lizensierung dieser Technik schützt. Dies ist leider nicht in jedem Fall so. Wer mit Hilfe von Microsoft - Programmierwerkzeugen, Office und SQL Server eigene Programme entwickelt, und hierbei die von Microsoft lizensierte, von Timeline patentierte Technik nutzt, läuft in Gefahr, daß für diese Programme direkt von Timeline Rechte erworben werden müssen. Der Patentschutz, den Microsoft gewährt, bezieht sich nämlich nur auf die direkte Nutzung von Office 2000+ und SQL Server 7+, nicht aber auf Eigenentwicklungen, die auf Microsoft Code beruhen, welchen Microsoft von Timeline lizensiert hat. Da kein Quellcode zur Verfügung steht, ist schwer nachzuvollziehen, welcher Microsoft Code von Timeline - Patenten betroffen ist. Timeline fordert in diesem Falle 5% des Brutto - Umsatzes, oder zwischen 250.000$-5.000.000US$ pauschal.

Bisher jedoch hat noch keine Firma, die eine der 283 Patente besitzt, die Linux angeblich verletzt, auch nur eine einzige Codezeile öffentlich genannt. In dem Moment, wo die betreffende Stelle vor Gericht öffentlich genannt würde, wäre sofort ein Software - Patch verfügbar, der dieses Problem beseitigt oder umgeht. Der menschlichen Kreativität sind hier keinerlei Grenzen gesetzt, und eine Linux Community mit 300.000 aktiven Programmierern hat sicher immer eine schnelle Lösung parat, wie z.B. bei Amazons Patent auf 1-click-buy, siehe auch folgende U.S. Patente: 5,715,399; 5,960,411; 6,006,225; 6,029,141; 6,064,980; 6,144,958; 6,169,986; 6,185,558; 6,266,649; 6,317,722; 6,360,254; 6,366,910; 6,401,084; 6,466,918; 6,489,968.

Alle Programmierer von SHOP - Software haben einfach noch eine Abfrage hinterher geschaltet: "Bitte bestätigen Sie den Kauf nochmals mit einem Klick!". Damit ist es ein "2-click-buy" und frei von Patenten. Auch das Problem mit den Microsoft - Patent für FAT läßt sich einfach umgehen: locate fat zeigt Linux Kernel - Module an, welche Code für fat, vfat enthalten. Die Entfernung dieses Codes, sowie einiger Binaries, wie z.B. der sogenannten mtools und fdformat ist kein wirkliches Problem, die Technik FAT ist restlos überholt. Und zur Formatierung von USB - Sticks stehen viele andere Varianten zur Verfügung: affs, cramfs, minix, isofs, romfs.

Software Patente sind recht interessant, weil sie oft so formuliert wurden, daß niemand wirklich versteht, wie einfach manchmal die Idee dahinter ist, wie z.B. bei Diffie-Hellmann US Patent # 4,218,582, 1980 (Public Key Cryptographic Apparatus and Method). Wer hat sich noch nicht darüber gewundert, wie ein Browser einen Crypto - Tunnel via HTTPS (HTTP mit SSL Layer) für z.B. Homebanking aufbaut, ohne daß jemand mitlauschen kann?

Für jede Art Ver - und Entschlüsselung werden ja normalerweise zuvor Passworte ausgetauscht, sodaß Datenströme zwischen beiden Partnern ver- und entschlüsselt werden können. Ohne ein sogenanntes shared secret funktioniert dies nicht. Daher haben sich Whitfield Diffie und Martin Hellmann ein Verfahren ausgedacht, welches sie asymetrisches Verfahren genannt haben, dessen Sicherheit u.a. auf der folgenden Idee beruht:

Eine Nachricht soll verschickt werden von User A nach B, in einer verschlossenen Kiste, die hier stellvertretend für eine "unknackbare" Verschlüsselung stehen soll. Das Problem ist, daß der Empfänger den Schlüssel benötigt, um diese zu öffnen, und die Nachricht lesen zu können. Wenn also zeitversetzt elektronisch die verschlüsselte Nachricht (die Kiste) und der Schlüssel selber über dieselbe Verbindung übermittelt werden (Passwort Faxen ist nicht praktikabel!), so kann ein "man in the middle" diese ja einfach mitlesen. Egal, wie man hin - und herüberlegt - man kommt nicht auf die Lösung. Dabei ist diese so einfach:

A legt die Nachricht in die Kiste und schließt mit seinem Schlüssel ab, behält diesen für sich. Diese verschlossene Kiste übermittelt A nun an B mit der Bitte, die Kiste mit einem zusätzlichen, 2. Schloß nochmals abzuschließen, und diese nun, mit zwei Schlössern versehen, zurück zu senden, wobei auch B den Schlüssel für sich behält. Nun kann A sein eigenes Schloß entfernen, und die Kiste wieder an B senden, der nun schließlich die Kiste öffnet, und die Nachricht lesen kann. Das witzige daran ist, daß zu keinem Zeitpunkt die Kiste unverschlossen war, aber auch keine Schlüssel übermittelt werden mußten. Wenn man genauer recherchiert, findet man alte Truhen, die bereits vor Jahrhunderten schon Vorrichtungen für zwei Schlösser hatten, warum nur? Und wenn man nun ganz genau nachdenkt, kommt man leicht auf die Lösung, wie man das angeblich sichere Verfahren für Homebanking leicht überlisten kann, und zwar ganz elegant, ohne die Kiste aufbrechen zu müssen:

Nun? Die Lösung liegt auf der Hand: Der "man in the middle" fängt die Kiste ab, bringt sein eigenes Schloß an, und schickt die Kiste wieder zurück. A entfernt sein Schloß und schickt die Kiste wieder (vermeintlich an B) zurück an den M.I.T.M., der die Nachricht dann liest, sein Schloß wieder anbringt, und diese weiter sendet an B, mit der Bitte ...

Übrigends ist dieses Verfahren in SSLv2 angewandt. Wer also nicht sicher ist, wie er innerhalb seines Browsers den SSLv2 Code entfernt (Quellcode und C- Programmierkenntnisse erforderlich!), und damit die Verwendung von SSLv3, dem Nachfolger des unsicheren SSLv2 zwischen Browser und seiner Bank erzwingt, der kann sich nicht sicher sein, daß niemand die Verbindung abhört. Wer über NAT oder Masquerading, also eine Firewall seine Homebanking - Verbindung aufbauen kann, verwendet SSLv2, also das gerade beschriebene, unsichere Verfahren.

Es ist überaus schwierig, die impliziten Logiken der modernen Crypto - Verfahren aus dem Quellcode bzw. den Patentschriften heraus zu verstehen, und noch schwieriger, diese so einfach darzustellen, daß jeder die Idee dahinter versteht, wobei ich hoffe, daß mir dies gelungen ist ... Wie SSLv2 bzw. SSLv3 (TLS) funktioniert, siehe www.ietf.org, RFC 2246.

Weder das Bundesamt für Sicherheit in der Informationstechnik (BSI) noch Banken warnen vor, daß dieses Verfahren *prinzipiell*, also unabhängig von Verschlüsselungsart und Schlüssellänge, unsicher ist, bzw. erklären, warum. Beim BSI hat vermutlich auch niemand verstanden, warum:

Zitat: "SSL sollte nur ab Version 3 eingesetzt werden, da hier durch die zusätzliche Server-Authentikation keine "Man-in-the-Middle"-Angriffe wie bei SSLv2 mehr möglich sind.". Diese Aussage ist definitiv falsch!

Ein Tip: Auch SSLv3 (TLS) läßt sich einfach knacken, hierzu muß man jedoch die impliziten Logiken verstanden haben, die sich hinter dieser langen Reihe von Sätzen verbergen! - TIP: Jedem Apache Webserver liegt eine Software bei, die eine CA (Certification Authority) simuliert!

Have fun!