Adressen und Signaturen

Seeds werden zum Erstellen von privaten Schlüsseln verwendet, und private Schlüssel werden wiederum zum Erstellen von Adressen und Signaturen verwendet. Adressen sind öffentlich und können im Netzwerk sicher mit anderen geteilt werden. Signaturen sind ein kryptografischer Nachweis des Inhabers einer Adresse. Wenn also eine Transaktion eine gültige Signatur enthält, wurde sie vom Eigentümer des richtigen Seeds erstellt.

Jeder private Schlüssel wird aus einer kryptografischen Hashfunktion erstellt wobei ein Seed, ein Index und eine Sicherheitsstufe benötigt wird. Private Schlüssel werden zum Erstellen von Adressen verwendet. Daher wirken sich Index und Sicherheitsstufe des privaten Schlüssels auf die Adresse aus.

Ein privater Schlüssel kann eine von drei Sicherheitsstufen haben, die von seiner Länge abhängig sind. Je höher die Sicherheitsstufe, desto länger und sicherer ist der private Schlüssel.

Neben der Sicherheitsstufe hat ein privater Schlüssel auch einen Index. Immer wenn der Index erhöht wird, wird ein neuer privater Schlüssel erstellt.

Private Schlüssel wie auch Seeds sind geheim und sollten niemals an Dritte weitergegeben werden.

Wie werden private Schlüssel erstellt?

Seed und Index werden kombiniert und gehasht, um einen 81-Tryte-SubSeed zu erstellen:

hash(seed + index)

Um einen privaten Schlüssel zu erstellen, wird der SubSeed an eine cryptographic sponge function (Kryptographische Schwammfunktion) übergeben, die ihn absorbiert und pro Sicherheitsstufe 27-mal durchknetet.

Das Ergebnis der Schwammfunktion ist ein privater Schlüssel, der je nach Sicherheitsstufe aus 2.187, 4.374 oder 6.561 Trytes besteht.

Adressen sind öffentlich. Clients senden Token und Nachrichten mithilfe des address Feldes einer Transaktion an Adressen.


Mit einem privaten Schlüssel wird eine Adresse mit demselben Index und derselben Sicherheitsstufe erstellt. Daher führen derselbe Seed, der gleiche Index und dieselbe Sicherheitsstufe immer auch zum gleichen privaten Schlüssel und derselben Adresse.

Tipp: Erstellen Sie verschiedene Adressen mit der IOTA-JavaScript-Clientbibliothek.

Wie werden Adressen erstellt?

Um eine Adresse zu erstellen, wird der private Schlüssel in 81-Tryte-Segmente aufgeteilt. Danach wird jedes Segment 26-mal gehasht.

Eine Gruppe von 27 Hash-Segmenten wird als Schlüsselfragment bezeichnet. Da ein privater Schlüssel aus 2.187, 4.374 oder 6.561 Trytes besteht, hat ein privater Schlüssel für jede Sicherheitsstufe ein Schlüsselfragment. Ein privater Schlüssel mit Sicherheitsstufe 1 besteht beispielsweise aus 2187 Trytes, also 27 Segmenten, was zu einem Schlüsselfragment führt.

Jedes Schlüsselfragment wird einmal gehasht, um für jede Sicherheitsstufe einen Schlüsselauszug zu erstellen. Beispielsweise führt ein Schlüsselfragment zu einem Schlüsselauszug.

Dann werden die Schlüsselauszüge zusammengefasst und einmal gehasht, um eine 81-Tryte-Adresse zu erstellen.

Clients benötigen einen Nachweis, dass sie eine Adresse besitzen, bevor IRI-Knoten eine Transaktion validieren und damit die IOTA-Tokenauf der Adresse belasten.
Zum Nachweis des Eigentums müssen Eingangstransaktionen mit dem selben privaten Schlüssel signiert werden, mit dem auch die Adresse erstellt wurde. Diese Signatur wird in das signatureMessageFragmentFeld einer Transaktion gestellt.

Eine Signatur wird sowohl aus dem privaten Schlüssel einer Adresse als auch aus dem Bundle-Hash der Transaktion erstellt, die von der Adresse ausgegeben wird.

Durch die Verwendung des Bundle-Hashs zum Erstellen einer Signatur ist es Angreifern nicht möglich, ein Bundle abzufangen und Transaktionen zu ändern, ohne den Bundle-Hash zu ändern und die Signatur ungültig zu machen.

Wie werden Signaturen erstellt?

Signaturen werden mit dem einmaligen Signaturschema von Winternitz (Winternitz one-time signature scheme) erstellt. Dieses Signaturschema ist quantenresistent, was bedeutet, dass Signaturen gegen Angriffe von Quantencomputern resistent sind.

Um eine Signatur zu erstellen, wird der Bundle-Hash einer Transaktion normalisiert um sicherzustellen, dass nur die Hälfte des privaten Schlüssels in der Signatur enthalten ist.

Hinweis zur Adresswiederverwendung:

Dieser Schritt ist aufgrund des einmaligen Signaturschemas von Winternitz erforderlich. Wenn der Bundle-Hash nicht normalisiert wurde, würde das Schema einen unbekannten Teil des privaten Schlüssels anzeigen. Durch Aufdecken dieser Hälfte des privaten Schlüssels kann eine Adresse zwar sicher einem Mal abgebucht werden aber wenn eine Adresse mehr als einmal belastet wird, wird auch mehr von dem privaten Schlüssel aufgedeckt, wodurch ein sehr geschickter Angreifer seine Signatur entdecken (brute forcen) und die IOTA-Token stehlen kann.

Abhängig von der Anzahl der Schlüsselfragmente die ein privater Schlüssel besitzt, werden 27, 54 oder 81 Trytes des normalisierten Bündel-Hashes ausgewählt. Diese Trytes entsprechen der Anzahl der Segmente in einem Schlüsselfragment.

Die ausgewählten Trytes des normalisierten Bündelhashes werden in ihre Dezimalwerte konvertiert. Dann wird bei jedem von ihnen die folgende Berechnung durchgeführt:

13 - decimal value

Das Ergebnis dieser Berechnung ist die Häufigkeit, mit der jedes der 27 Segmente im Schlüsselfragment gehasht werden muss, um das Signaturfragment zu erstellen. Jedes Signaturfragment hat 2187 Trytes.

Da das signatureMessageFragmentFeld einer Transaktion nur 2187 Trytes enthalten kann, muss jede Eingabeadresse mit einer Sicherheitsstufe von mehr als 1 den Rest der Signatur über Ausgangstransaktionen mit einem Wert von null fragmentieren.

Wie IRI-Nodes Signaturen überprüfen

IRI-Knoten verifizieren eine Signatur in einer Transaktion, indem sie die Signatur und den Bundle-Hash verwenden, um die Adresse der Eingangstransaktion zu ermitteln.

Um eine Signatur zu überprüfen, wird der Bundle-Hash einer Transaktion normalisiert.

Je nach Länge der Signatur werden 27, 54 oder 81 Trytes des normalisierten Bündelhashs ausgewählt. Diese Trytes entsprechen der Anzahl von 81-Tryte-Segmenten in einem Signaturfragment.

Die ausgewählten Trytes des normalisierten Bündelhashs werden in Dezimalwerte konvertiert. Dann wird bei jedem von ihnen die folgende Berechnung durchgeführt:

13 + decimal value

Das Ergebnis dieser Berechnung ist die Häufigkeit, mit der jedes der 27 Segmente in den Signaturfragmenten gehasht werden muss, um die Schlüsselfragmente zu erstellen.

Jedes Schlüsselfragment wird einmal gehasht, um die Schlüsselzusammenfassungen zu erstellen, die kombiniert und einmal gehackt werden, um eine 81-Tryte-Adresse zu erstellen.

Wenn die Adresse mit der Adresse in der Transaktion übereinstimmt, ist die Signatur gültig.


Anmerkung:

Der Inhalt kann durch die Übersetzung verfälscht sein. Im Zweifel gilt das englische Original der IOTA Foundation.

Quelle:https://docs.iota.org/docs/iota-basics/0.1/concepts/addresses-and-signatures

  • Zuletzt geändert: 2019/02/13 19:30
  • von thoralf