DE60031304T2

DE60031304T2 - Verfahren zur authentifizierung von softwarebenutzern

Info

Publication number: DE60031304T2
Application number: DE60031304T
Authority: DE
Inventors: G. Gregory Mortlake ROSE; Philip Burwood HAWKES
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 1999-12-21
Filing date: 2000-12-21
Publication date: 2007-05-24
Anticipated expiration: 2020-12-22
Also published as: DE60031304D1; BR0016507A; AU2592201A; KR100833828B1; JP4782343B2; EP1261903A2; EP1261903B2; BRPI0016507B1; HK1052570A1; WO2001046787A3; TW498233B; ATE342539T1; WO2001046787A2; DE60031304T3; CN1413320B; JP2003520467A; EP1261903B1; CN1413320A; KR20020091059A; US6944765B1

Description

Hintergrund der Erfindung
I. Gebiet der Erfindung
Die vorliegende Erfindung gehört im Allgemeinen zum Gebiet der Verschlüsselung und im Speziellen zu den Verfahren zur Authentifizierung bzw. Authentisierung von anonymen Anwendern, welche das Potential des Betruges durch „Mittelsmänner" verringern.
II. Hintergrund
Software für Computer (Rechner) wird im Allgemeinen im Internet über Vertriebsvertreter oder „Mittelsmänner" an die Endanwender (d.h. die Konsumenten) verteilt. Somit sind drei Parteien an dem Vorgang beteiligt. Die erste Partei ist der Provider (Anbieter) von Software und Inhalten (d.h. der Autor), der ein Einkommen daraus erzielt, dass er Endanwendern Inhalte liefert, und der den Vertriebsvertretern eine kleine Vermittlungsgebühr dafür bezahlt, dass diese für die Software werben und diese verteilen. Die zweite Partei ist eine Anzahl von Vertriebsvertretern, die dem Anwender die Software (die einen Mechanismus zum Betrachten des Inhaltes sowie einigen vom Inhalt unabhängigen Wert, wie z.B. Funktionen für den elektronischen Schriftverkehr (Mail) bietet) zur Verfügung stellt. Der Mittelsmann erzielt Einkommen von Anwendern, die Inhalte erhalten, also liegt es in seinem oder ihrem Interesse, die Software an einen großen Kreis zu verteilen. Die dritte Partei ist der Anwender, der als Gegenleistung für das Betrachten des Inhaltes die Software frei erhält. Der Anwender erhält keine andere Vergütung, in erster Linie, weil die Anwender anonym sind. Die Anwender sind anonym, weil Tracking-Details (elektronisch verfolgbare Spuren) normalerweise nicht aufbewahrt werden, und die Anwender nicht individuell identifiziert wurden. Anwender mögen freiwillig Informationen zur Verfügung stellen, wenn sie Inhalt abrufen, aber diese freiwillig zur Verfügung gestellte Information wird im Allgemeinen verwendet und verworfen, anstatt gespeichert und getrackt (verfolgt) zu werden. Die Par teien werden nachstehend generell als der Provider, der Mittelsmann, und der Anwender bzw. Nutzer bezeichnet.
Der Mittelsmann kann ein als Internet „Cookie" bekanntes Hilfsmittel verwenden, um demographische Informationen über Anwender zu beziehen, wenn diese sich mit dem Internet verbinden und die entsprechende Website (Angebotsstandort im Internet) besuchen. Wenn ein Anwender beispielweise Verbindungen zu bestimmten Orten im Internet herstellt, verbindet sich der Computer des Anwenders über das Internet mit einen Hostcomputer (Leitrechner), der vom Mittelsmann betrieben wird. Der Host sendet eine kleine Datei mit Daten (das Cookie), die auf dem Computer des Anwenders gespeichert wird. Wenn der Anwender und der Host miteinander kommunizieren, werden einige Daten in dem Cookie gespeichert. Wenn der Anwender die Verbindung beendet, verbleibt das Cookie auf seinem oder ihrem Computer. Nachfolgende Daten über die Internetnutzung des Anwenders werden in dem Cookie gespeichert. Wenn der Anwender sich das nächste Mal mit dem Host verbindet, liest der Host die Informationen über den Anwender aus dem Cookie aus. Die Informationen über den Anwender können vom Betreiber des Hosts verarbeitet und an Internethändler verkauft werden.
Da die Anwender anonym sind, kann der Mittelsmann einfach durch das Durchreichen von mehr Inhalten dem Provider gegenüber unnachweisbaren Betrug begehen. Dieses wiederum kann entweder durch Anfordern von mehr Inhalten im Namen eines realen Anwenders oder durch das Erzeugen von „Fake-Anwendern" (gefälschten Anwendern) erreicht werden. Es gibt eine Reihe von statistischen Verfahren zur Feststellung des Ausmaßes der Lieferung von Inhalten an bestimmte Anwender, welche die Anonymität der Details bewahren. Solche statistischen Verfahren lösen das Problem von Mittelsmännern, die durch das Anfordern von mehr Inhalten im Namen eines realen Anwenders Betrug begehen. Diese Verfahren adressieren jedoch nicht die Situation, in der der Mittelsmann dadurch betrügt, dass er eine signifikante Anzahl von gefälschten Anwendern erzeugt. Daher besteht Bedarf für ein Verfahren, welches die Vertriebsvertreter für Software daran hindert dadurch zu betrügen, dass sie eine signifikante Anzahl von nicht existierenden Anwendern vorgaukeln.
US-A-5,790,667 offenbart ein Verfahren zur personengebundenen Authentifizierung, in welchem ein Anwender i eine Nachricht bzw. Information für die Authentifizierungsanfrage unter Zuhilfenahme eines Parameters, der eine Zufallszahl enthält, berechnet und diese an eine Verkaufsgesellschaft A sendet. Bei der Verkaufsgesellschaft A wird die empfangene Nachricht mit der Authentifizierungsanfrage nicht rückkalkulierbar bzw. einweg (one-way) transformiert unter Zuhilfenahme eines Parameters, der eine Zufallszahl enthält und wird als Nachricht zur Authentifizierungsaufforderung an den Anwender i gesendet. Bei dem Anwender i werden eine Identifikationsnummer über die Mitgliedschaft des Anwenders bei einem Kreditinstitut und ein Passwort eingegeben, und die empfangene Nachricht zur Authentifizierungsaufforderung wird unter Zuhilfenahme des Passwortes transformiert, um die Nachricht zur Authentifizierungsantwort zu erzeugen. Dann werden die Identifikationsnummer des Anwenders i und die Nachricht zur Authentifizierungsantwort an die Verkaufsgesellschaft A gesendet. Bei der Verkaufsgesellschaft A wird die empfangene Nachricht zur Authentifizierungsantwort einweg transformiert, so dass der Parameter mit der Zufallszahl annulliert wird, um die Nachricht mit der Authentifizierungsreferenz zu erzeugen. Dann werden die empfangene Indentifikationsnummer und die Nachricht mit der Authentifizierungsreferenz an das Kreditinstitut b gesendet. Bei dem Kreditinstitut b wird mit Hilfe der empfangenen Identifikationsnummer, die als Schlüssel verwendet wird, eine transformierte geheime Nachricht, die zuvor gespeichert wurde, abgerufen und es wird ermittelt, ob die transformierte geheime Nachricht und die Nachricht mit der Authentifizierungsreferenz gleich sind. Wenn sie gleich sind, sendet das Kreditinstitut b der Verkaufsgesellschaft A eine Authentifizierungsnachricht, die die Richtigkeit des Anwenders i anzeigt, und wenn sie nicht gleich sind, sendet das Kreditinstitut b eine Authentifizierungsnachricht, die anzeigt, dass der Anwender i nicht als korrekter Anwender authentifiziert werden kann. Von der Verkaufsgesellschaft A wird die Authentifizierungsnachricht, die vom Kreditinstitut b gesendet wurde an den Anwender i geschickt.
Zusammenfassung der Erfindung
Die vorliegende Erfindung betrifft ein Verfahren mit dem Vertriebsvertreter von Software daran gehindert werden dadurch zu betrügen, dass sie eine signifikante Anzahl von nicht existierenden Anwendern vorgaukeln. Entsprechend ist in einem Aspekt der Erfindung ein Verfahren für einen Softwareprovider zur Authentifizierung von Anwendern der Software vorgesehen, wie in Anspruch 1 beansprucht. Das Verfahren beinhaltet vorteilshafterweise die Schritte des Konstruierens eines Rätsels als Antwort auf Information bzw. Informationen, die vom Anwender empfangen wurden, wobei das Rätsel diese Informationen enthält; des Sendens des Rätsels an den Anwender; und des Rücklieferns einer Lösung des Rätsels an den Provider.
In einem anderen Aspekt der Erfindung ist eine Vorrichtung, die einen Softwareprovider zur Authentifizierung von Anwendern der Software befähigt, vorgesehen, wie in Anspruch 4 beansprucht. Die Vorrichtung beinhaltet vorteilshafterweise Mittel zum Konstruieren eines Rätsels als Antwort auf Informationen, die vom Anwender empfangen wurden, wobei das Rätsel diese Informationen enthält; Mittel um das Rätsel an den Anwender zu senden; und Mittel um eine Lösung des Rätsels an den Provider zurückzuschicken.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockdiagramm eines Systems, in welchem Information zwischen einem Provider und einem Anwender ausgetauscht wird.
2 ist ein Blockdiagramm, welches die Passung von Bits eines verschlüsselten „Cookies" in eine Potenzierungsoperation eines „Rätsels" darstellt.
Detaillierte Beschreibung der bevorzugten Ausführungsbeispiele
In den untenstehenden Ausführungsbeispielen werden neue Anwender eines Systems auf eine Art und Weise registriert, bei der ein knappes Betriebsmittel so verbraucht wird, dass ein einzelner Anwender sich registrieren und die Kosten nicht zur Kenntnis nehmen wird, aber jede Partei, und insbesondere ein Mittelsmann, sich bei jedem Versuch, das System zu missbrauchen, mit signifikanten Kosten belasten würde. In einem Ausführungsbeispiel ist das signifikante Betriebsmittel Rechenarbeitszeit. Andere knappe Betriebsmittel könnten verwendet werden, wie z.B. Speicherplatz, Netzwerk-Bandbreite oder die Zeitspanne der Aufmerksamkeit des Anwenders (d.h., vom Anwender zu verlangen, über eine Zeitspanne hinweg zu interagieren). Rechenarbeitszeit wird bevorzugt, da sie tatsächlich für den Anwender frei zur Verfügung steht. Im Allgemeinen ist der Personal-Computer bzw. Arbeitsplatzrechner des Anwenders die meiste Zeit untätig, die Berechnung kann auf eine unaufdringliche Art und Weise ausgeführt werden, und es gibt keinen permanenten Overhead (Mehraufwand) sobald die Berechnung abgeschlossen ist. Der exakte Umfang der Berechnung kann Parametern wie z.B. den Kosten und der Rechenleistung von typischen Computern der Zeit und dem Umfang des involvierten Betrugspotentials entsprechend angepasst werden.
In 1 wird in Übereinstimmung mit einem Ausführungsbeispiel ein System 100 dargestellt, in welchem ein Anwender 102 durch Kommunikation mit einem Provider 104 Registrierung beantragt. Es sollte klar sein, dass der Anwender 102 und der Provider 104 sich auf Geräte beziehen, die vom Anwender und dem Provider verwendet werden, und zwar Geräte wie z.B. Personal-Computer oder tragbare Rechenvorrichtungen (handheld computing devices) wie persönliche digitale Assistenten (personal digital assistants) oder schnurlose Telefone für den Anwender 102, bis hin zu großen Webservern für den Provider 104. In einer Nachricht 106 sendet der Anwender 102 demographische Daten an den Provider 104. In anderen Ausführungsbeispielen könnte der Anwender 102 andere Daten, wie z.B. die Anwenderidentität anstelle von oder zusammen mit demographischen Daten in der Nachricht 106 schicken. Die Nachricht 106 an den Provider 104 kann in einer verschlüsselten Ausführung sein, um sensitive Informationen über den Anwender 102 zu schützen, oder die Nachricht kann in unverschlüsselter Ausführung sein. Die Software bei dem Anwender 102 beinhaltet irgendein Identifizierungsmerkmal des Mittelsmannes, welches wiederum ebenfalls in der Nachricht 106 enthalten ist. Der Anwender 102 kann auch Informationen zur Verfügung stellen, um anschließend inhaltliche Materialien treffsicherer auswählen zu können. Die vom Anwender 102 zur Verfügung gestellten Daten 106 werden vom Provider 104 in die Antwort auf ein Rätsel 108 hineincodiert. Die Antwort, d.h. das entschlüsselte Rätsel 110, wird vom Anwender 102 zu einem späteren Zeitpunkt, wenn der Anwender 102 Inhalt anfordert, zu dem Provider 104 zurückgeschickt.
In einem Ausführungsbeispiel wird die Antwort 110 auf das Rätsel 108 wie folgt aufgebaut. Die zur Verfügung gestellte Information 106 und ein zufälliger Identifikator (nicht dargestellt), der ausreichend lang ist, um von seiner Einzigartigkeit ausgehen zu können, werden in einem Puffer (ebenfalls nicht dargestellt) platziert. Eine verschlüsselte Hash-Funktion (Streuwertfunktion) des Inhaltes des Puffers wird berechnet. Eine beispielhafte sichere Has-Funktion ist der Secure Hash Standard (sicherer Hash Standard), der im Federal Information Processing Standard (FIPS) 180-1 spezifiziert ist, welcher vom National Institute for Standards and Technology entwickelt wurde. Der im FIPS 180-1 Dokument beschriebene Algorithmus wird nachstehend als sicherer Hash-Algorithmus (Secure Hash Algorithm, SHA) bezeichnet. Das Ergebnis der Hash-Funktion kann 160 Bits lang sein. In einem speziellen Ausführungsbeispiel werden nur die ersten vierundsechzig Bits der Hash-Funktion verwendet. In einem anderen Ausführungsbeispiel werden die ersten achtzig Bits der Hash-Funktion verwendet. Die Hash-Funktion wird in den Puffer am Anfang des Puffers eingefügt. Der gesamte Puffer wird dann mit einer symmetrischen Blockverschlüsselung (symmetric block cipher), wie z.B. dem Algorithmus nach dem Datenverschlüsselungs-Standard (Data Encryption Standrad, DES) (FIPS 46-2) unter Verwendung eines in einem Schlüssel im Provider 104 enthaltenen Geheimnisses (nicht dargestellt) verschlüsselt. In einem speziellen Ausführungsbeispiel wird der Dreifach-DES (triple-DES, 3DES) Algorithmus, wie im Entwurfstext des FIPS 46-3 spezifiziert, verwendet.
Für jeden außer dem Provider 104 ist das Resultat der Verschlüsselung vorteilshafterweise nicht von zufälligen Daten unterscheidbar. Insbesondere wenn ein Teil der Daten öffentlich zugänglich gemacht wird, kann keine Partei den Teil, der nicht offen ist, rekonstruieren. Wenn der Provider 104 nachfolgend ein verschlüsseltes Objekt empfängt, kann der Provider 104 sicher sein, dass es exakt die Daten sind, die der Provider 104 zu einer früheren Zeit er zeugte, indem er das Objekt entschlüsselt und verifiziert, ob die in dem Objekt eingebettete Hash-Funktion mit dem Ergebnis einer neuen Berechnung übereinstimmt. Der verschlüsselte Datenpuffer wird üblicherweise von Fachleuten als ein „Cookie" bezeichnet.
Es sollte klar sein, dass das Cookie länger als ein einzelner Cipher Block sein wird, also muss die Verschlüsselung im Cipher Block Chaining Modus bzw. Verkettungsmodus der Blockverschlüsselung, wie in FIPS beschrieben, erfolgen. Der Cipher Block Chaining Modus erfordert normalerweise eine Zufallszahl als Initialisierungsvektor. Der Initialisierungsvektor kann jedoch auf einen konstanten Nullwert gesetzt werden, da der erste zu verschlüsselnde Block einen Hash-Wert enthält, was ausreichend ist, um die erwarteten Angriffe zu verhindern.
Das Rätsel 108 wird aus dem Cookie konstruiert, anstatt das Cookie selber zu senden. Das Rätsel 108 ist vorteilshafterweise so konstruiert, dass ein gewisser (d.h. erwarteter) Umfang von Rechenarbeit benötigt wird, um das Rätsel 108 zu lösen und das Cookie zurückzugewinnen. Da der Provider 104 diese Funktion für viele Anwender ausführen muss, muss der Provider 104 rechnerseitig effizient sein, das Rätsel 108 zu konstruieren, während die Lösung des Rätsels 108 absichtlich ineffizient gestaltet sein muss. Diese Kombination aus rechnerseitiger Effizienz bei der Konstruktion und Ineffizienz bei der Lösung kann mit einer neuen Verwendung von bekannten Verfahren der Asymmetrischen Verschlüsselung (public-key cryptography) erreicht werden.
Für Zwecke der nachfolgenden Erläuterung kann das Cookie mit C bezeichnet werden, und andere Parameter P und g sind in der Software enthalten und so allen Beteiligten bekannt. Der Parameter P ist vorteilshafterweise eine große Primzahl. Die untere Grenze der Anzahl von Bits in P wird durch die gewünschte Komplexität der Berechnung des Rätsels 108 bestimmt. In einem speziellen Ausführungsbeispiel ist die Anzahl von Bits in P 1024. Der Parameter P hat vorteilshafterweise die zusätzliche Eigenschaft, dass ein Parameter Q, der die Gleichung Q = (P – 1)/2 erfüllt, ebenfalls eine Primzahl ist. Der Parameter g ist vorteilshafterweise ein Erzeugerelement bzw. Generator der Untergruppe der Ordnung (Kardinalität) Q der multiplikativen Gruppe der ganzen Zahlen modulo P. Die Parameter P, g und Q sind typische Parameter, die in dem bekannten Diffie-Hellman-Schlüsselaustausch-(Diffie-Hellman key agreement)-Protokoll verwendet werden. Wenn das Cookie, C, größer als Q ist, wird dem Anwender 102 ein Teil des Cookies unverschlüsselt gegeben und ein kleinerer Teil wird verwendet um das Rätsel 108 zu konstruieren. Hier wird generell angenommen, dass gilt |C| < |Q|.
Das Rätsel 108 wird zunächst durch die Berechnung von Z = g^K modulo P konstruiert. Derzeit erfordert das beste bekannte Verfahren zur Berechung von K aus einem gegebenen Z (d.h. zum Lösen des diskreten Logarithmus-Problems) sehr viel Rechenarbeit und, mit einer Länge von 1024 Bit für P wird das Verfahren als etwa gleichwertig betrachtet, wie das Entschlüsseln einer Nachricht unter Verwendung eines Block Ciphers (Verschlüsselungsblocks) mit einem unbekannten Schlüssel von 128 Bit. Solch eine Berechnung auszuführen, ist für den Anwender 102 zu aufwändig. Weil der Anwender 102 in der Lage sein soll, C zurückzugewinnen, gibt der Provider 104 dem Anwender 102 den größten Teil der Anwort 110. Das Rätsel 108 enthält somit Z und einen Rätsellösungshinweis. Der Rätsellösungshinweis beinhaltet die meisten (aber nicht alle) Informationen über C. Die Anzahl der variablen Bits in dem übermittelten Wert bestimmt den Schwierigkeitsgrad des Rätsels 108. Der für den Anwender 102 effizienteste Weg das Rätsel 108 zu lösen ist, Versuchswerte für die unbekannte Information auszuprobieren bis der Anwender 102 den Versuchswert findet, der die korrekte Antwort 110 liefert. Jeden Versuchswert zu überprüfen erfordert die Berechnung der modularen (diskreten) Exponentialfunktion für den Kandidaten K.
Es kann angenommen werden, dass die Berechnung einer solchen modularen Exponentiation etwa 1/100^stel einer Sekunde dauert (die genaue Dauer hängt von der Schnelligkeit des Prozessors (nicht dargestellt) und der Größe von P ab). Wenn gewünscht ist, dass die Berechnung eine durchschnittliche Dauer von zwölf Stunden im Hintergrund ablaufender Verarbeitung benötigt, müssen näherungsweise vier Millionen (oder 2²²) Probelauf-Kandidaten verwendet werden. Da die Lösung im Schnitt etwa auf dem halben Weg durch die Menge der Möglichkeiten gefunden werden wird, sollte der Rätsellösungshinweis aus allen, bis auf dreiundzwanzig, der Bits der Antwort 110 bestehen.
Um sicherzustellen, dass das Rätsel 108 nicht auf eine Weise gelöst werden kann, die die probeweise Exponentiation vermeidet, kann wiederum eine Einweg-Hash-Funktion verwendet werden. Wir gehen davon aus (wie dies für den Secure Hash Standard der Fall ist), dass die Ausgabe der Hash-Funktion H()160 Bits lang ist. Es ist wichtig sicherzustellen, dass |C| ein bisschen größer ist als |H|/2, so dass |C| in zwei Teile geteilt werden kann. Wenn nötig, kann C vor der Verschlüsselung aufgefüllt werden um sicherzustellen, dass |C| groß genug ist. Das Ergebnis der Hash-Funktion wird zum Teil verwendet, um C unkenntlich zu machen, und zum Teil, um den Eingabewert des Vorgangs der Exponentation zu variieren.
Ein Zwischenergebnis K wird aus C auf die folgende Weise konstruiert. Das Cookie C wird in zwei Teile, L und R, so geteilt, dass |R| achtzig Bits lang ist. Eine Zufallszahl r wird im Bereich 0, ..., N gewählt, wobei N den durchschnittlichen Schwierigkeitsgrad des Rätsels 108 bestimmt. In einem Ausführungsbeispiel gilt N = 2²³. Dann wird K mit Hilfe der folgenden Gleichung ermittelt: K = L||((R||0₈₀) ⊕ H(L||r)), wobei || eine Operation der Konkatenation (Verkettung) bezeichnet, ⊕ eine bitweise Exklusiv-Oder (XOR) Operation bezeichnet und 0₈₀ achtzig Null-Bits bezeichnet.
Es sollte zur Kenntnis genommen werden, dass in dem hier beschriebenen speziellen Ausführungsbeispiel das Ergebnis einer einzelnen Hash-Funktion vorteilshafterweise in zwei Teile geteilt und für unabhängige Zwecke genutzt wird. Es wäre für einen Fachmann leicht ersichtlich, dass zwei unabhängige Hash-Funktionen für diese Zwecke verwendet werden könnten.
Das Rätsel 108 besteht dann aus dem Ergebnis der Exponentiation Z und allen außer den letzten achtzig Bits von K. Um C zurückzugewinnen und das Rätsel 108 zu lösen, beginnt der Anwender 102 Werte von r auszuprobieren, H(L||r) zu berechnen, achtzig Bits des Ergebnisses an den gegebenen Teil von K anzuhängen, und zu überprüfen, ob das resultierende g^K gleich der Antwort Z ist. Wenn das korrekte r gefunden ist, können die linken achtzig Bits der Hash-Ausgabe in einer XOR Operation mit dem partiellen K verknüpft werden, um C zurückzugewinnen.
Folglich genügt die oben beschriebenen Technik den Anforderungen wie beschrieben. Die möglichen Lösungen des diskreten Logarithmus-Problems vari ieren in 160 Bits, viel zu viele um irgendeine Form der Vorberechnung sinnvoll anwenden zu können. Achtzig Bits von C sind unkenntlich bis K mittels probeweiser Exponentiation verifiziert werden kann. Achtzig Bits von K sind solange nicht erkenntlich, bis sie aus r abgeleitet wurden. Da K von L abhängt gibt es keinen Weg, die begrenzte Menge der sinnvollen Hash-Werte vorzuberechnen. Der Bereich der Zufallszahl r bestimmt die durchschnittliche Zeit, die zur Lösung des Rätsels 108 durch Ausprobieren gebraucht wird, während die obigen Eigenschaften sicherstellen, dass andere Abkürzungen nicht funktionieren.
Es wäre für Fachleute leicht einsichtig, dass das Rätsel 108 auch durch Senden von Versuchswerten an den Provider 104 und Warten auf Bestätigung gelöst werden könnte. Das begleitende Protokoll sollte sicherstellen, dass dies nicht effizienter ist, als die modulare Exponentiation durchzuführen (mit welcher in der Praxis vorlieb genommen werden wird).
Sobald der Anwender 102 das Rätsel 108 gelöst hat, ist der Anwender 102 im Besitz eines gültigen Cookies, das genügend Informationen enthält, um den Provider 104 in der Folge zu überzeugen, dass der Anwender 102 sich registriert hat. Das Cookie trägt ebenfalls alle ergänzenden Daten, die vom Provider 104 benötigt werden, um den Inhalt zu bestimmen.
Es sollte klar sein, dass manche der Informationen in der initialen Registrierungsanfrage 106 potentiell die Privatsphäre betreffen und zu schützen sind (privacy-sensitive). In ähnlicher Weise könnte ein Lauscher, wenn das Cookie zum Provider 104 für nachfolgende Anfragen nach Inhalt zurückgeschickt wird, die Anfragen basierend auf dem Cookie verfolgen. Daher ist es wünschenswert, dass die Kommunikation 106 zwischen dem Anwender 102 und dem Provider 104 verschlüsselt ist, und es ist relativ einfach, solch eine Verschlüsselung durch Verwendung eines auf dem diskreten Logarithmus basierenden, asymetrischen Verschlüsselungsalgorithmus, wie z.B. dem Diffie-Hellman Algorithmus, zu bewerkstelligen. Der öffentliche Schlüssel des Providers 104 könnte in der Anwendung enthalten sein, und die gemeinsamen Parameter P und g könnten verwendet werden. Trotzdem würde von Fachleuten verstanden werden, dass die Nachricht 106 vom Anwender 102 zum Provider 104 nicht verschlüsselt sein muss und, dass, falls die Kommunikation 106 verschlüsselt ist, jeder asymetrische Verschlüsselungsalgorithmus verwendet werden könnte.
In einem Ausführungsbeispiel wird ein verschlüsseltes Cookie erzeugt und dann entschlüsselt, und ein Rätsel wird aus dem verschlüsselten Cookie erzeugt und dann gelöst, wie untenstehend und mit Bezug auf 2 beschrieben. In Übereinstimmung mit diesem speziellen Ausführungsbeispiel ist die äußere Umgebung wie folgt. Von bestimmten Daten und Funktionalitäten wird angenommen, dass sie in der aufrufenden Umgebung vorhanden sind. Im speziellen wird von dem Provider mehr Funktionalität verlangt als von dem Anwender.
Die primären gemeinsamen Parameter des Rätselsystems sind P, welches 1024 Bit lang ist und eine Primzahl ist, und g, ein Erzeugerelement, dessen Wert zwei ist. Die Primzahl P ist durch 2¹⁰²⁴ – 2⁹⁶⁰ – 1 + 2⁶⁴·{[2⁸⁹⁴π] + 129093 gegeben. Der hexadezimale Wert von P ist der Folgende:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF.
Die folgende gemeinsame Funktionalität wird vorteilshafterweise verwendet. Beide, der Anwender und der Provider, benötigen Zugriff auf einen SHA-1 Hash-Algorithmus und eine Funktion zur modularen Exponentiation im Bereich großer ganzer Zahlen. Der SHA-1 Hash-Algorithmus, welcher mit H(.) bezeichnet wird, erzeugt vorteilshafterweise von jeder Eingabe, unabhängig von der Länge der Eingabe, 160 Bit Ergebnisse. Die Funktion zur modularen Exponentiation im Bereich großer ganzer Zahlen referenziert die oben beschriebenen g und P implizit und berechnet g^x modulo P effizient für einen gegebenen Wert x. Andere Funktionen der modularen Arithmetik im Bereich großer ganzer Zahlen, wie z.B. Addition, Multiplikation, usw. können anstelle der Imp lementierung der Funktionalität der modularen Exponentiation verwendet werden.
Die folgenden, nur providerseitigen Parameter und Funktionalitäten werden vorteilshafterweise angewendet. Zusätzlich zu den oben beschriebenen gemeinsamen Anforderungen an Funktionalitäten benötigt der Provider zusätzlich die Fähigkeit Cookies in einer verschlüsselungstechnisch sicheren Weise zu erzeugen und zu verifizieren. Um dies zu tun benötigt der Provider folgende Dinge: (1) den 3DES Verschlüsselungsalgorithmus; (2) einen Authentifizierungsschlüssel Ka; (3) einen Schlüssel Kp, der verwendet wird um Cookies zu verschlüsseln; und (4) eine Quelle hochqualitativer geheimer Pseudozufallszahlen. In einem Ausführungsbeispiel ist der Authentifizierungsschlüssel Ka 128 Bit lang. Es sollte klar sein, dass andere Verschlüsselungsalgorithmen als der 3DES Verschlüsselungsalgorithmus verwendet werden können. In dem Ausführungsbeispiel, in welchem der 3DES Verschlüsselungsalgorithmus verwendet wird, sollte der Schlüssel Kp zur Verschlüsselung des Cookies vorteilshafterweise 112 Bits lang sein.
In Übereinstimmung mit diesem speziellen Ausführungsbeispiel kann ein verschlüsseltes Cookie wie folgt erzeugt werden. In dem speziellen, beschriebenen Ausführungsbeispiel ist das Cookie ein Byte (Oktett)-Puffer. Es wird davon ausgegangen, dass die maximale Länge des Eingabe-Cookies von der 1024 Bitlänge der Primzahl P plus den achtzig schlussendlich angehängten Bits abhängt. Das Cookie wird mit einem oder mehreren Oktetts gefüllt, um ein Vielfaches von acht Oktetts zu sein, und hat acht Oktetts mit Authentifizierungsinformationen vorangestellt. Mit den achtzig zusätzlichen Bits, die angehängt werden, muss die Länge des Cookies kleiner als 1023 Bits bleiben. In diesem speziellen Ausführungsbeispiel darf deshalb das Eingabe-Cookie höchstens 101 Oktetts, oder 808 Bits, lang sein. Es würde von Fachleuten verstanden werden, dass längere Cookies, wenn erforderlich, mit leichten Modifikationen bewältigt werden können. Das Cookie sollte vorteilshafterweise eine minimale Länge von acht Oktetts haben. Die folgenden Pseudocode-Parameter können verwendet werden, um ein Cookie in Übereinstimmung mit diesem speziellen Ausführungsbeispiel zu verschlüsseln:
In den obigen Pseudocode-Parametern, zeigt der Parameter cookie auf einen Puffer mit cookieLength bzw. Cookielänge (höchstens 101) Oktetts mit Informationen. Der Parameter encryptedCookie bzw. verschlüsseltes Cookie zeigt auf einen Puffer mit mindestens ((cookieLength + 16) &0xF8) Oktetts verfügbarem Speicherplatz, der mit dem Ergebnis überschrieben werden wird. Die global verwendete Information beinhaltet die Parameter Ka und Kp.
Die folgenden Verfahrensschritte können verwendet werden, um ein Cookie in Übereinstimmung mit diesem speziellen Ausführungsbeispiel zu verschlüsseln. Erstens wird der SHA Hashwert H(Ka, cookie) berechnet und dann auf acht Oktetts gekürzt. Der gekürzte Hashwert wird dann in eine encryptedCookie genannte Datei kopiert. Zweitens wird eine cookie genannte Datei an die Datei encryptedCookie angehängt. Drittens wird die Anzahl der für das Auffüllen erforderlichen Oktetts, 1 <= n <= 8, berechnet, und dann wird die Anzahl von Oktetts, die den Wert n enthalten, angehängt. Dieser dritte Verfahrensschritt kann unzweideutig rückgängig gemacht werden. Viertens wird die Datei encryptedCookie verschlüsselt, dazu wird der 3DES Verschlüsselungsalgorithmus mit dem Schlüssel Kp im Cipher Block Chaining (CBC) Modus und einem Initialisierungsvektor von Null verwendet.
In Übereinstimmung mit diesem speziellen Ausführungsbeispiel kann ein verschlüsseltes Cookie unter Verwendung der folgenden Pseudocode-Parameter entschlüsselt werden:
In den obigen Pseudocode-Parametern, zeigt die Datei encryptedCookie auf einen Puffer mit cookieLength (höchstens 112) Oktetts mit Informationen. Die Datei cookie zeigt auf einen Puffer mit mindestens (cookieLength – 8) Oktetts verfügbarem Speicherplatz, der mit dem Ergebnis überschrieben werden wird. Der Rückgabewert ist die Länge des entschlüsselten Cookies, wenn die Authentifizierung erfolgreich ist. Ansonsten ist der Rückgabewert Null. Die global verwendete Information beinhaltet die Parameter Ka und Kp.
Die folgenden Verfahrensschritte können verwendet werden, um ein Cookie in Übereinstimmung mit diesem speziellen Ausführungsbeispiel zu entschlüsseln. Erstens wird eine encryptedCookie genannte Datei in einen temporären Puffer kopiert und dann entschlüsselt unter Verwendung des 3DES Verschlüsselungsalgorithmus mit dem Schlüssel Kp im CBC Modus und einem Initialisierungsvektor von Null. Zweitens wird der SHA Hashwert H(Ka, buffer + 8) nach Entfernen der Auffüllung berechnet. Der SHA Hashwert wird dann auf acht Oktetts gekürzt. Drittens wird die acht Oktett lange Ausgabe mit den ersten acht Oktetts des Puffers verglichen. Der Wert Null wird zurückgegeben, wenn die beiden verglichenen Mengen von acht Oktetts ungleich sind. Viertens, wenn der Vergleich Gleichheit ergibt, wird der temporäre Puffer plus acht Oktetts in die Datei cookie kopiert, und die nicht aufgefüllte Länge der Datei cookie wird zurückgegeben.
In Übereinstimmung mit diesem speziellen Ausführungsbeispiel kann ein Rätsel aus einem verschlüsselten Cookie erzeugt werden, wie in 2 dargestellt. Ein verschlüsseltes Cookie 200 wird konzeptionell in linke (L) und rechte (R) Komponente geteilt. Die rechte Komponente ist achtzig Bits lang. Ein Zufallszahlengenerator 202 wählt pseudo-zufällig eine Zahl in dem Bereich von Null bis 2²³. Das verschlüsselte Cookie 200 wird in einen 1024 Bit Puffer 204 kopiert und auf der linken Seite mit Nullwerten 206 aufgefüllt und auf der rechten Seite mit zehn Oktetts von Nullen (achtzig Null Bits) aufgefüllt. Eine 160 Bit SHA Hash-Funktion 208 wird über die Verkettung von der linken Komponente des verschlüsselten Cookies 200 und der Zufallszahl, die vom Zufallszahlengenerator 202 ausgewählt wurde, ausgeführt. Das Ergebnis der Hash-Funktion 208, welches zwanzig Oktetts lang ist, wird durch eine bitweise XOR Operation in die zwanzig ganz rechts gelegenen Oktetts des Puffers 204 eingebracht, wodurch die zehn ganz rechts gelegenen Oktetts des verschlüsselten Cookies 200 und die zehn Oktetts von Nullen modifiziert werden. Der Puffer 204 wird zum Exponenten erhoben, um ein Ergebnis Z der Exponentiation zu erzeugen. Das Ergebnis der Exponentiation Z wird in dem Rätsel 210, welches das Ergebnis Z und alle Bits, außer den ganz rechts gelegenen achtzig Bits (welche verworfen werden) des Puffers 204 enthält, an den Anwender, oder Client, geschickt.
In Übereinstimmung mit einem Ausführungsbeispiel kann die folgende Pseudocode-Struktur verwendet werden, um ein Rätsel aus einem verschlüsselten Cookie zu erzeugen.
Die Eingabe difficulty bzw. Schwierigkeit bestimmt die Größe der verwendeten Zufallszahl, welche wiederum die erwartete Anzahl von versuchsweisen Exponentiationen, die zur Lösung des Rätsels ausgeführt werden müssen, beeinflusst. Wenn difficulty zum Beispiel zwanzig ist, dann müssen im Durchschnitt 2¹⁹ Hash-Wert-Berechungen und Versuchsexponentiationen vom Anwender durchgeführt werden, um das Rätsel zu knacken. Der eingegebene verschlüsselte Cookie hat die Länge cookieLength. Diese Funktion kehrt zurück nach der Befüllung der Struktur, auf die p zeigt. Das encryptedCookie in der Struktur unterscheidet sich von dem eingebenen verschlüsselten Cookie und wird daher bei einer Authentifizierung scheitern.
Das verschlüsselte Cookie wird konzeptionell in zwei Teile L und R so geteilt, dass R zehn Oktetts (achtzig Bits) lang ist. Eine Zufallszahl wird im Bereich 0..2^difficulty – 1 erzeugt. Das verschlüsselte Cookie wird dann in einen temporären 1024 Bit Puffer K kopiert, der auf der linken Seite mit Nullen aufgefüllt ist und an dem rechten Ende mit zehn Oktetts von Nullen aufgefüllt ist. Eine Hash-Funktion wird über L, r ausgeführt, um den Wert h, welcher zwanzig Oktetts lang ist, zu erzeugen. Der Wert h wird durch eine XOR Operation in die letzten zwanzig Oktetts des Puffers eingebracht, wodurch die zehn letzten Oketetts des ursprünglichen verschlüsselten Cookies und die anderen zehn Oktetts von Nullen modifiziert werden. Der temporäre Puffer K wird als 1024 Bit Ganzzahl behandelt und zum Exponenten erhoben, um Z entsprechend der folgenden Gleichung zu erzeugen: Z = g^K mod P. Die Pseudocode-Struktur wird, wie in den folgenden Pseudocode-Schritten gezeigt, durch Zuweisung der entsprechenden Felder befüllt:
p->difficulty = difficulty;
p->cookieLength = cookieLength;
p->answer = Z;
p->encryptedCookie = the middle part of K.
In Übereinstimmung mit einem Ausführungsbeispiel kann ein Rätsel durch Aufruf einer mit solvePuzzle bzw. Rätsellösen bezeichneten Softwareroutine gelöst werden. Die Funktion zur Lösung des Rätsels muss wiederholt aufgerufen werden, um das Rätsel tatsächlich zu lösen. Jeder Aufruf führt eine versuchsweise Exponentiation aus. Das aufrufende Programm hat vorteilshafterweise die Verantwortung für Funktionen wie, z.B., Erzeugen von Threads (Aktivitätsträgern) im Hintergrund, periodisches Speichern von Zwischenzuständen, usw., so wie es von Fachleuten verstanden würde. Die folgende Pseudocode-Struktur definiert vollständig den Stand des Suchprozesses, und ist diejenige Information, die gespeichert und für das Weiterführen wiederhergestellt werden muss:
Die Routine solvePuzzle sollte einen Wert von Eins zurückgeben, wenn die Rountine solvePuzzle die Lösung zu dem Rätsel gefunden hat, in welchem Fall das encryptedCookie Feld der puzzlestate (Status des Rätsels) Struktur ein gültiges verschlüsseltes Cookie enthalten wird. Während die Suche andauert, soll die Routine solvePuzzle einen Wert von Null zurückgeben. In dem „unmöglichen" Fall, in dem die Routine solvePuzzle das gültige verschlüsselte Cookie nicht gefunden hat, bevor sie den gesamten Bereich durchsucht hat, soll die Routine solvePuzzle den Wert einer negativen Eins zurückgeben. Solch ein Ergebnis könnte nur in dem Fall, in dem die Übermittlung des Rätsels gestört wird oder in dem ein Fehler in dem Programm auf der Seite des Anwenders oder auf der Seite des Providers auftritt, auftreten.
Es sollte aufgezeigt werden, dass der Anwender, vor dem ersten Aufruf von solvePuzzle, das Rätsel, welches er vom Provider erhalten hat, in die oben gezeigte Struktur puzzlestate kopieren sollte. Ebenfalls vor dem ersten Aufruf von solvePuzzle sollte der Anwender das Feld upto auf null setzen.
Es sollte außerdem bemerkt werden, und würde von Fachleuten verstanden, dass verschiedene alternative Verfahren verwendet werden könnten, um das Rätsel zu lösen und die Korrektheit des Cookies zu verifizieren. Ein solches Verfahren ist die Verwendung von ,keyed message authentication codes' (verschlüsselten Codes zur Authentifizierung von Nachrichten).
Es ist wichtig, dass das Verfahren zur Lösung des Rätsels effizient ist. Obwohl das Ziel ist, Rechnerzeit zu verbrauchen, ist es wichtig, dass der Zeitverbrauch unvermeidbar und nicht Gegenstand von simpler Optimierung sein soll. Aus diesem Grund muss der erste Aufruf von solvePuzzle ein Zwischenergebnis berechnen und das Ergebnis speichern, um nachfolgende Berechnung zu vermeiden (was sicherlich das ist, was jemand, der das System kna cken wollte, tun würde). Da g^(x+y) == g^xg^y ist es möglich, den Ratewert in feste und variable Teile aufzubrechen und die Exponentiation nur für den kleineren, variablen Teil zu berechnen. Tatsächlich ist es, durch Teilung (Multiplikation mit dem Kehrwert) der Antwort durch den festen Teil nur notwendig, den 160 Bit langen variablen Teil zum Exponenten zu erheben und dann zu vergleichen, um zu prüfen, ob das Problem gelöst ist.
In Übereinstimmung mit diesem speziellen Ausführungsbeispiel kann das Rätsel durch Ausführung der folgenden Schritte gelöst werden: Erstens, wenn das upto bzw. ,bis zu' Feld null ist, wird das intermediate bzw. Zwischenwert Feld initialisiert. Die Initialisierungsprozedur wird ausgeführt durch Teilung des encryptedCookie Feldes in linke und rechte Teile (L und R), so dass R zehn Oktetts lang ist, und dann durch Berechnung des multiplikativen Kehrwertes von (L·2¹⁶⁰) und Multiplikation mit dem answer bzw. Antwort Feld, um den resultierenden Wert für das intermediate Feld zu erhalten. Zweitens wird eine Hash-Funktion über die L und upto Felder ausgeführt und ein 160 Bit langes Ergebnis wird aus R und den zehn ganz rechts liegenden Oktetts des Hash-Wertes geformt. Drittens wird das 160 Bit Ergebnis zum Exponenten erhoben, um das Ergebnis einer Exponentiation zu erhalten. Viertens wird das Ergebnis der Exponentiation mit dem Wert im intermediate Feld verglichen. Wenn die verglichenen Werte unterschiedlich sind, wird das upto Feld inkrementiert und ein Wert von Null wird zurückgegeben. (Oder, wenn der Wert des upto Feldes größer oder gleich 2^difficulty ist (d.h. wenn etwas schiefgelaufen ist), wird der Wert einer negativen Eins zurückgegeben.) Fünftens, andernfalls (d.h., wenn die im vierten Schritt verglichenen Werte die gleichen sind) werden die achtzig ganz links gelegenen Bits des Hash-Wertes von L und upto durch eine XOR Operation in die ganz rechts gelegenen Bits des encryptedCookie Feldes (welches jetzt korrekt ist) eingebracht, und ein Wert von Eins, der den Erfolg indiziert, wird zurückgegeben.
Folglich wurde ein neues und verbessertes Verfahren zur Authentifizierung von anonymen Anwendern beschrieben, in welchem das Potential des Betruges durch „Mittelsmänner" verringert wird. Fachleute würden verstehen, dass die vielfachen erläuternden logischen Blöcke, Module, Schaltungen und Schritte von Algorithmen, die in Verbindung mit den hierin offenbarten Ausfüh rungsbeispielen beschrieben wurden, als elektronische Hardware, Computersoftware oder einer Kombination aus beidem implementiert werden können. Die vielfachen erläuternden Komponenten, Blöcke, Module, Schaltungen und Schritte wurden allgemein bezüglich ihrer Funktionalität beschrieben. Ob die Funktionalität als Hardware oder Software implementiert ist, hängt von der speziellen Anwendung und den konzeptionellen Einschränkungen ab, die dem Gesamtsystem auferlegt sind. Fachleute verstehen die Austauschbarkeit von Hardware und Software unter diesen Bedingungen, und verstehen wie die beschriebenen Funktionalitäten für jede einzelne Anwendung am besten zu implementieren sind. Als Beispiele können die vielfachen erläuternden logischen Blöcke, Module, Schaltungen und Schritte von Algorithmen, die in Verbindung mit den hierin offenbarten Ausführungsbeispielen beschrieben wurden, implementiert werden mit oder ausgeführt werden mit: einem digitalen Signalprozessor (digital signal processor, DSP), einer anwendungsspezifischen integrierten Schaltung (application specific integrated circuit, ASIC), diskreter Gatter- oder Transitorlogik, diskreten Hardwarekomponenten wie, z.B., Registern und FIFO-Speichern, einem Prozessor, der ein Set von Firmware-Befehlen ausführt, jedem herkömmlichen programmierbaren Softwaremodul und einen Prozessor oder jeder Kombination hiervon. Der Prozessor kann vorteilshafterweise ein Microprozessor sein, aber alternativ kann der Prozessor jeder herkömmliche Prozessor, Controller, Microcontroller oder Zustandsautomat sein. Das Softwaremodul könnte sich im RAM-Speicher, Flash-Speicher, ROM-Speicher, in Registern, auf Festplatte, einer Wechselplatte, einer CD-ROM oder jeder anderen Form von, im Fachgebiet bekannten, Speichermedien befinden. Fachleute würden desweiteren einsehen, dass die Daten, Befehle, Kommandos, Informationen, Signale, Bits, Symbole und Chips, auf die ggf. in der obigen Beschreibung Bezug genommen wurde, vorteilshafterweise durch Spannungen, Ströme, elektromagnetische Wellen, magnetische Felder oder Partikel, optische Felder oder Partikel oder jeder Kombination hiervon dargestellt werden.
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung wurden somit aufgezeigt und beschrieben. Es wäre jedoch für einen Fachmann einsichtig, dass vielfache Veränderungen an den hierin offenbarten Ausführungsbeispie len gemacht werden könnten, ohne von dem Umfang der Erfindung, wie in den folgenden Ansprüchen definiert, abzuweichen.

Claims

Ein Verfahren für eine Rechenvorrichtung, verwendet durch einen Softwareprovider, wobei die Software elektronisch durch einen Vertreter vertrieben wird, und zwar zum Authentisieren bzw. Authentifizieren von Rechenvorrichtungen, die von Benutzern der Software verwendet werden, wobei das Verfahren folgende Schritte aufweist: Konstruieren eines Rätsels bei der Rechenvorrichtung, die von dem Provider verwendet wird ansprechend auf Informationen, die von einer Rechenvorrichtung verwendet von einem Benutzer empfangen wird, wobei das Rätsel die Informationen enthält; Senden des Rätsels an den Benutzer; Empfangen an der Rechenvorrichtung, die von dem Provider verwendet wird, eine Antwort zu dem Rätsel und eine Anfrage nach der Software; und Authentifizieren der Anfrage nach der Software als von der Rechenvorrichtung verwendet durch einen Benutzer abstammend, wenn die Antwort auf das Rätsel verifiziert wird, dadurch gekennzeichnet, dass das Rätsel mit einem Schwierigkeitseingabeparameter konstruiert ist, der eine erwartete Anzahl von Versuchskandidaten bestimmt, die benötigt werden, um das Rätsel zu lösen.
Verfahren nach Anspruch 1, wobei die Information eine demografische Information über den Benutzer aufweist.
Verfahren nach Anspruch 1, wobei die Information eine Identität des Benutzers aufweist.
Verfahren nach Anspruch 1, wobei der Schritt des Konstruierens folgende Schritte aufweist: Herleiten eines Werts von der Information, um einen hergeleiteten Wert zu erzeugen, Potenzieren des hergeleiteten Wertes, um einen potenzierten Wert zu erzeugen und Kombi nieren des potenzierten Wertes mit einem Teil des hergeleiteten Wertes.
Verfahren nach Anspruch 4, das weiterhin folgende Schritte aufweist: Speichern der Informationen und einer Zufallszahl, Ausführen einer Hash-Funktion auf die Information und die Zufallszahl, um ein erstes Hash-Ergebnis zu generieren und Verschlüsseln des ersten Hash-Ergebnisses, wobei der Herleitungsschritt folgende Schritte aufweist: Partitionieren des verschlüsselten Hash-Ergebnisses in erste und zweite Komponenten, Ausführen einer Hash-Funktion auf eine Verknüpfung der ersten Komponente und der Zufallszahl, um ein zweites Hash-Ergebnis zu erzeugen, Hinzufügen einer Vielzahl von Null-Werten an die zweite Komponente, um eine verlängerte zweite Komponente zu erzeugen, Ausführen einer Exklusiv-Oder-Operation zwischen der verlängerten zweiten Komponente und dem zweiten Hash-Ergebnis, um ein Exklusiv-Oder-Ergebnis zu generieren, und Verknüpfen bzw. Verketten der ersten Komponente und des Exklusiv-Oder-Ergebnisses, um den hergeleiteten Wert zu erzeugen.
Verfahren nach Anspruch 4, wobei der Potenzierung-Schritt folgende Schritte aufweist: Potenzieren eines Generators bzw. Erhöhen eines Generators zu einer Potenz, wobei der hergeleitete Wert der Exponent ist, Teilen des Generators potenziert mit dem hergeleiteten Wert als Exponenten durch eine Primzahl, und Erlangen des Rests der Teilungsoperation.
Eine Vorrichtung zum Ermöglichen, dass eine Rechenvorrichtung, die von einem Provider einer durch einen Vertreter elektronisch authentisiert bzw. vertriebenen Software verwendet wird, Rechenvorrichtungen authentifiziert, die von Benutzern der Software verwendet werden, wobei die Vorrichtung Folgendes aufweist: Mittel zum Konstruieren eines Rätsel bei der Rechenvorrichtung, die von dem Provider verwendet wird, ansprechen auf Informationen, Empfangen von einem Rechengerät, verwendet von einem Benutzer, wobei das Rätsel die Informationen enthält; Mittel zum Senden des Rätsels an die Rechenvorrichtung, die von einem Benutzer verwendet wird; und Mittel zum Empfangen bei der Rechenvorrichtung, die von dem Provider verwendet wird, um ein Rätsel zu beantworten und eine Anfrage nach der Software und zum Authentifizieren der Anfrage nach der Software als der von dem Benutzer verwendeten Rechenvorrichtung abstammend, wenn die Antwort zu dem Rätsel verifiziert wird, dadurch gekennzeichnet, dass die Mittel zum Konstruieren des Rätsels konfiguriert sind, zum Konstruieren des Rätsels mit einem Schwierigkeitseingabeparameter, der eine erwartete Anzahl von Lösungsversuchen bestimmt, die benötigt wird, um das Rätsel zu lösen.
Vorrichtung gemäß Anspruch 7, wobei die Information demografische Informationen über den Benutzer aufweist.
Vorrichtung nach Anspruch 7, wobei die Information eine Identität des Benutzers aufweist.
Vorrichtung nach Anspruch 7, wobei die Mittel zum Konstruieren eines Rätsels Folgendes aufweisen: Mittel zum Herleiten eines Wertes von der Information, um einen hergeleiteten Wert zu erzeugen, Mittel zum Potenzieren des hergeleiteten Wertes, um einen potenzierten Wert zu erzeugen, und Mittel zum Kombinieren des potenzierten Wertes mit einem Teil des hergeleiteten Wertes.
Vorrichtung nach Anspruch 10, die weiterhin Folgendes aufweist: Mittel zum Speichern der Information und einer Zufallszahl, Mittel zum Ausführen einer Hash-Funktion auf die Information und die Zufallszahl, um ein erstes Hash-Ergebnis zu generieren, und Mittel zum Verschlüsseln des ersten Hash-Ergebnisses, wobei die Mittel zum Herleiten Mittel aufweisen zum Partitionieren des verschlüsselten Hash-Ergebnisses in erste und zweite Komponenten, zum Ausführen einer Hash-Funktion auf eine Verkettung der ersten Komponente und der zweiten Zufallszahl, um ein zweites Hash-Ergebnis zu generieren, zum Hinzufügen einer Vielzahl von Null-Werten an die zweite Komponente, um eine verlängerte zweite Komponente zu erzeugen, zum Ausführen einer Exklusiv-Oder-Operation zwischen der verlängerten zweiten Komponente und dem zweiten Hash-Ergebnis, um ein Exklusiv-Oder-Ergebnis zu generieren, und zum Verknüpfen der ersten Komponente und dem zweiten Exklusiv-Oder-Ergebnis, um den hergeleiteten Wert zu erzeugen.
Vorrichtung nach Anspruch 10, wobei die Mittel zum Potenzieren Mittel aufweisen zum Potenzieren eines Generators zu bzw. mit einer Potenz, wobei die Potenz der hergeleitete Wert ist, Mittel zum Teilen des Generators potenziert mit der Potenz des hergeleiteten Werts, um eine Primzahl, und Mittel zum Erlangen des Rests der Teilungsoperation.