Einführung in MQL5 (Teil 36): Beherrschen der API und der Funktion WebRequest in MQL5 (X)

Einführung

Willkommen zurück zu Teil 36 der Serie „Einführung in MQL5!“ In Teil 31 dieser Serie haben wir besprochen, wie man mit externen Plattformen wie Binance kommuniziert, aber die Kommunikation war direkt und beinhaltete keinen Austausch von sensiblen Informationen. In diesem Artikel werden wir uns mit dem Sicherheitsaspekt der API-Konnektivität befassen. Wir befassen uns mit wichtigen Themen wie Signaturen, HMAC (Hash-based Message Authentication Code) und SHA256-Hashing, die zur Authentifizierung von Anfragen, zur Bestätigung der Integrität von Anfragen und zur Verhinderung von Manipulationen verwendet werden. Bei kritischen API-Aufrufen, wie dem Platzieren von Aufträgen oder der Verwaltung von Handelsgeschäften, sind diese Sicherheitsmaßnahmen äußerst wichtig. 

Es ist wichtig zu wissen, dass die Theorie und die Bausteine die einzigen Themen sind, die in diesem Artikel behandelt werden. Sensible Informationen werden in Live-Abfragen noch nicht übermittelt. Im nächsten Artikel werden wir diese Konzepte kombinieren, um eine sichere Verbindung mit einem Server herzustellen. Am Ende dieses Abschnitts werden Sie ein grundlegendes Verständnis dafür haben, wie HMAC, SHA256 und Signaturen zusammen die Grundlage für sichere MQL5-API-Aufrufe bilden.

 

Was ist eine Signatur?

In APIs funktioniert eine Signatur ähnlich wie ein spezielles Siegel, das an jede Anfrage angehängt wird. Mit diesem Siegel kann der Server zwei Dinge überprüfen: Die Anfrage stammt wirklich von Ihnen, und es wurde vor ihrem Eintreffen nichts verändert. Anders ausgedrückt: Die Signatur teilt dem Server mit, dass „diese Anfrage vertrauenswürdig ist“. Ohne sie kann sich jeder für Ihre Anfragen ausgeben, was bei heiklen Transaktionen wie der Erteilung von Aufträgen oder dem Abschluss von Geschäften ein Risiko darstellt.

Zur Überprüfung der Anträge sind Signaturen unerlässlich. Die Authentizität einer Anfrage muss von Servern überprüft werden. Dazu werden kryptografische Verfahren wie HMAC-SHA256 eingesetzt, um eine Signatur unter Verwendung der Anfragedaten und eines geheimen Schlüssels zu erstellen. Diese Signatur wird zusammen mit der Anfrage an den Server gesendet, wo die gleiche Berechnung durchgeführt wird. Die Rechtmäßigkeit der Anfrage wird durch ein übereinstimmendes Ergebnis bestätigt. Für ein leichtes Verständnis stellen Sie sich einen unterschriebenen Brief vor. Man kann sicher sein, dass ein handgeschriebener Brief, der unten Ihre Unterschrift trägt, von Ihnen verfasst wurde. Der Empfänger könnte erkennen, dass der Brief gefälscht ist, wenn Ihre Unterschrift fehlt. Ähnlich wie bei APIs garantiert die Signatur, dass Ihre Anfrage als von Ihnen stammend identifiziert wird und während der Übermittlung nicht von jemand anderem verändert wurde.

Verstehen von HMAC-SHA256

Bevor wir über HMAC sprechen, ist es wichtig zu verstehen, wofür MAC steht. Der Message Authentication Code wird als MAC bezeichnet. Eine Nachricht und ein geheimer Schlüssel werden verwendet, um einen MAC zu erstellen, der ein kleines Datenstück ist. Das vorrangige Ziel besteht darin, gleichzeitig nachzuweisen, dass die Nachricht tatsächlich vom angegebenen Absender stammt und sie nicht verändert wurde. Der Server verwendet denselben geheimen Schlüssel, um den MAC nach Erhalt einer Nachricht neu zu berechnen. Die Mitteilung wird als echt anerkannt, wenn die Ergebnisse übereinstimmen. MACs gibt es in verschiedenen Varianten. Einige werden mit Hash-Funktionen erstellt, andere mit Blockchiffren. Sie haben alle den gleichen Zweck, nämlich die Authentifizierung und Integritätsprüfung von Nachrichten, unabhängig von ihrem Typ. HMAC ist eine der beliebtesten und sichersten Methoden unter diesen.

Sie wird verwendet, um eine Signatur zu erstellen, die bestätigt, dass eine API-Anfrage legitim ist und nicht manipuliert wurde. Bei der Übermittlung sensibler Anfragen, wie z. B. bei der Aufgabe von Aufträgen, wird sie von Plattformen wie Binance häufig eingesetzt. Wir werden in diesem Artikel nicht auf alle internen mathematischen Details von HMAC-SHA256 eingehen. Vielmehr werden wir uns ausschließlich auf die Komponenten konzentrieren, die Sie verstehen müssen, um richtig zu erstellen und MQL5-API-Abfragen zu signieren. Hier ist das praktische Verständnis wichtiger als die Beherrschung der Kryptografie. Die grundlegenden Komponenten dieses Mechanismus sind eine Methode zur Nachrichtenauthentifizierung und der Hash-Algorithmus SHA256. Das Endprodukt ist eine Signatur, also ein Wert mit fester Länge. Die Methode WebRequest wird dann verwendet, um die Anfrage zu senden, nachdem diese Signatur zur Anfrage-URL hinzugefügt wurde.

Diese kryptografische Hash-Methode erzeugt ein festes 256-Bit-Ergebnis, das Eingaben unterschiedlicher Länge akzeptiert. Unabhängig von der Eingabe bleibt die Ausgabegröße die gleiche. Das Ergebnis ist deterministisch und garantiert wiederholbare und vorhersehbare Ergebnisse für dieselben Eingabedaten, auch wenn sie zufällig erscheinen. Der Avalanche-Effekt ist ein wichtiges Merkmal von SHA256. Eine einzige Zeichenänderung in der Eingabe führt zu einem vollkommen anderen Hash. SHA256 ist daher besonders hilfreich, um Datenänderungen zu erkennen. Mit SHA256 allein lässt sich jedoch der Absender der Daten nicht ermitteln. Eine Nachricht kann von jedem gehasht werden. Hierin liegt die Rolle von HMAC.

HMAC bezieht einen geheimen Schlüssel in den Hashing-Prozess ein und erweitert SHA256. Dieser private Schlüssel wird nur von Ihnen und dem Server gemeinsam genutzt, z. B. zwischen Binance und Ihrer MT5-Software. Eine Signatur, die nur von jemandem mit dem richtigen geheimen Schlüssel erstellt werden kann, wird erzeugt, indem die Nachricht und der geheime Schlüssel kombiniert und mit SHA256 gehasht werden. Dies bedeutet, dass ein Angreifer ohne den geheimen Schlüssel keine legitime Signatur erstellen kann, auch wenn er die zugestellte Nachricht einsehen kann. Es ist nicht notwendig, die Funktionsweise der internen Hashing-Verfahren für unseren Anwendungsfall im Detail zu erläutern. Die wichtigste Lektion ist, dass man bei Verwendung derselben Nachricht und desselben geheimen Schlüssels immer dieselbe Signatur erhält; ändert man eines der beiden Elemente, erhält man eine andere Signatur.

In Wirklichkeit ist die signierte „Nachricht“ in der Regel ein Abfrage-String, der aus Anfrageelementen wie dem Zeitstempel besteht. Ihr geheimer API-Schlüssel und diese Zeichenfolge werden an den HMAC-SHA256-Prozess gesendet. Die Signatur ist das, was produziert wird. Ein zusätzlicher Parameter der Anfrage-URL ist die erstellte Signatur. Der Server berechnet die Signatur nach Erhalt der Anfrage mit der gleichen kryptografischen Technik und einer Kopie Ihres geheimen Schlüssels neu. Der Antrag wird genehmigt, wenn die neu erstellte Signatur mit der von Ihnen gelieferten übereinstimmt; andernfalls wird er abgelehnt. Obwohl dieses Verfahren auf ausgefeilten kryptografischen Prinzipien beruht, erfordert die normale Verwendung der MQL5-API diese Besonderheiten nicht. Dieser Artikel geht nicht auf grundlegende Mechanismen wie Padding, Blockgrößen oder Hash-Runden ein; stattdessen konzentriert er sich darauf, was Sie benötigen, um Signaturen effektiv zu erstellen und ihre Funktion zu verstehen.

Diese gezielte Methode garantiert, dass Sie getrost zum nächsten Abschnitt der Serie übergehen können, in dem wir tatsächliche API-Anfragen mit HMAC-SHA256 signieren und sie mit der WebRequest-Funktion von MQL5 sicher übermitteln werden. Zwei wesentliche Komponenten werden benötigt, um eine Signatur für die Binance-API zu erstellen. Der erste ist ein Zeitstempel, der den genauen Zeitpunkt der Anfrage angibt und ständig aktualisiert wird. Der zweite ist Ihr geheimer Schlüssel, den Sie von Binance erhalten und den Sie stets vertraulich behandeln müssen. Auch wenn alle anderen Parameter gleichbleiben, garantiert der Zeitstempel, dass jede Anfrage eindeutig ist.

Binance erhält Ihren privaten Schlüssel nicht sofort, wenn Sie einen Antrag stellen. Stattdessen erzeugt Ihr System eine Signatur mit HMAC-SHA256 unter Verwendung dieses geheimen Schlüssels und der Anfragedaten, einschließlich des Datums. Danach wird der Antrag mit dieser Signatur an Binance gesendet. Binance verwendet eine Kopie Ihres geheimen Schlüssels, den sie bereits besitzen, um die gleiche Berechnung auf ihrer Seite durchzuführen. Der Antrag wird genehmigt, wenn die vorgelegte Signatur mit der von Ihnen übermittelten übereinstimmt.

Dieses Verfahren stellt sicher, dass die Anfrage nicht geändert wurde, während sie sich im Netz befindet. Die Überprüfung würde fehlschlagen, wenn selbst eine geringfügige Änderung der Anfrageparameter zu einer ganz anderen Signatur führen würde. Dies ist von entscheidender Bedeutung für die Sicherheit, insbesondere bei heiklen Aufgaben wie der Auftragserteilung.

Ein weiteres entscheidendes Element ist, dass die Anfrage niemals den geheimen Schlüssel selbst enthält. Sie könnte abgefangen werden, wenn sie über das Netz gesendet wird. Wenn Sie eine kryptografische Signaturtechnik verwenden, wird nur eine abgeleitete Signatur gesendet; der geheime Schlüssel bleibt sicher auf Ihrem Computer. Daher liefert das Abfangen der Anfrage einem Angreifer keine ausreichenden Informationen, um legitime Anfragen zu fälschen oder den geheimen Schlüssel zu reproduzieren.

Analogie:

Stellen Sie sich vor, Sie würden in einer Stadt voller Briefträger einen wichtigen Brief an einen zuverlässigen Freund überbringen. Vergewissern Sie sich, dass Ihr Freund weiß, dass der Brief wirklich von Ihnen stammt und niemand seinen Inhalt verändert hat. Sie haben ein geheimes Wachssiegel, das nur Sie und Ihr Freund erstellen können, um dies zu erreichen. Ähnlich wie Ihr privater Schlüssel befindet sich dieses Siegel immer in Ihrem Besitz und kann von niemandem dupliziert werden. Stellen Sie sich vor, dass auf jedem Brief, den Sie verschicken, die genaue Zeit aufgedruckt ist, zu der er geschrieben wurde. Dieser Zeitstempel ist von entscheidender Bedeutung, da die Buchstaben selbst dann unterschiedlich erscheinen, wenn Sie die gleiche Nachricht aufgrund unterschiedlicher Zeitpunkte zweimal senden. Ohne den Zeitstempel könnte jemand versuchen, Ihren Freund zu täuschen, indem er einen alten Brief erneut verschickt. Der Zeitstempel ist wie ein Fingerabdruck für einen bestimmten Zeitpunkt und garantiert, dass jeder Buchstabe eindeutig ist.

Sie versehen den Brief mit dem Zeitstempel und Ihrem geheimen Wachssiegel, bevor Sie ihn abschicken. Durch diese Kombination erhält der Brief ein einzigartiges Zeichen, das seine Echtheit bestätigt. Ähnlich wie bei der HMAC-SHA256-Signatur ist die Markierung spezifisch für diese Nachricht zu diesem Zeitpunkt, da sie unter Verwendung Ihres geheimen Wachssiegels und der Uhrzeit erstellt wird. Ihr Bekannter prüft das Zeichen auf dem Brief mit einer Kopie Ihres Wachssiegels. Um sich zu vergewissern, dass das Schreiben auf dem neuesten Stand ist, prüfen sie auch den Zeitstempel. Ihr Bekannter erkennt die Echtheit und Unverfälschtheit des Briefes, wenn das Zeichen korrekt ist und die Uhrzeit stimmt. Andernfalls lehnen sie es sofort ab.

Dank der Eleganz dieses Systems verlässt das geheime Wachssiegel nie Ihren Schreibtisch. Das Schreiben wird nur mit dem Stempel oder der Signatur versandt. Ihr Siegel kann nicht nachgeahmt oder ein neuer Brief gefälscht werden, auch wenn ein gewiefter Postbote den Brief und das Siegel entdeckt. Ihr Geheimsiegel und der Zeitstempel sorgen gemeinsam dafür, dass jeder Brief sicher, authentisch und unverwechselbar ist. Der geheime Schlüssel und ein Zeitstempel werden verwendet, um eine Signatur zu erstellen, wenn Anfragen an die Binance-API gestellt werden. Der Zeitstempel verhindert, dass dieselbe Anfrage erneut verwendet wird, und der geheime Schlüssel verifiziert, dass sie von Ihnen stammt. Die Legitimität und Integrität der Anfrage werden dann von Binance durch Validierung der Signatur und des Zeitstempels überprüft.

 

Erstellen von API-Signaturen in MQL5

Der Prozess der Erstellung von API-Signaturen mit HMAC SHA256 in MQL5 ist der Punkt, an dem alle zuvor untersuchten Theorien auf nützliche Weise zusammenkommen. Das Ziel ist nun klar: eine Signatur zu erstellen, die einem externen Dienst, z. B. einer Börsen-API, zeigt, dass die Anfrage tatsächlich von Ihnen stammt und unterwegs nicht geändert wurde. Dieser Prozess findet ausschließlich auf Ihrem lokalen Computer in MQL5 statt, bevor die Anfrage über die WebRequest-Funktion ausgeliefert wird.

Zunächst ist es wichtig, dass wir genau wissen, was wir unterschreiben. Die meisten APIs, einschließlich Binance, generieren die Signatur nicht mithilfe von Zufallsdaten. Vielmehr werden die Anfrageparameter durch eine Zeichenkette dargestellt, die zur Generierung der Anfrage verwendet wird. Werte wie ein Zeitstempel, Auftragsinformationen, Mengen oder andere für den Endpunkt erforderliche Parameter sind häufig in dieser Zeichenfolge enthalten. Da er sich ständig ändert, ist der Zeitstempel von großer Bedeutung. Dadurch wird sichergestellt, dass jede Anfrage eindeutig ist, auch wenn alle anderen Parameter unverändert bleiben. Es besteht ein ernsthaftes Sicherheitsrisiko, wenn eine gültige Anfrage ohne Zeitstempel protokolliert und später erneut abgespielt wird.

Dieser Parameterstring wird mit Ihrem geheimen Schlüssel zusammengeführt, sobald er fertig ist. Der API-Anbieter stellt Ihnen den geheimen Schlüssel zur Verfügung, der niemals über das Netz weitergegeben oder kommuniziert werden darf. Dieser geheime Schlüssel wird in MQL5 nur als Eingabe für das Verfahren HMAC SHA256 verwendet. Der eigentliche Schlüssel verlässt nie Ihren Computer. Vielmehr fungiert er als unsichtbare Komponente, die das Endprodukt beeinflusst. Die identische Signatur für dieselbe Nachricht kann nur von jemandem erstellt werden, der diesen geheimen Schlüssel kennt.

In MQL5 wird ein einzigartiges Hashing-Verfahren auf die Nachricht und den geheimen Schlüssel angewendet. Die Hauptidee ist das Ergebnis, sodass Sie sich nicht um die komplizierten Berechnungen kümmern müssen. Das Ergebnis ist eine Zeichenkette mit fester Länge, die trotz ihres zufälligen Aussehens vollkommen konsistent ist. Ihre Signatur ist diese Zeichenfolge. Sie erhalten dieselbe Signatur, wenn Sie dieselbe E-Mail erneut mit demselben geheimen Schlüssel signieren. Die Signatur wird völlig anders aussehen, wenn Sie eine andere Tonart verwenden oder nur ein Zeichen ändern.

Die Signatur wird erstellt und dann der Anfrage hinzugefügt, normalerweise als zusätzlicher URL-Parameter. Der Server verwendet seine gespeicherte Kopie Ihres geheimen Schlüssels und die übergebenen Parameter, um die gleiche Signaturberechnung durchzuführen, wenn die Anfrage den Server erreicht. Eine übereinstimmende Signatur zeigt dem Server an, dass die Daten während der Netzwerkübertragung nicht verändert wurden und die Anfrage vom autorisierten Schlüsselinhaber gestellt wurde. Die Funktion CryptEncode in MQL5 wird zur Erstellung von Signaturen und Hashes verwendet. Sie kann Hashes wie SHA256 oder HMAC-basierte Signaturen erzeugen und ist eines der integrierten Kryptografie-Tools der Plattform. Im Wesentlichen nimmt CryptEncode eingehende Daten entgegen, wandelt sie mit einer kryptografischen Methode um, fügt bei Bedarf einen Schlüssel hinzu und gibt einen Binärwert aus. Wir verwenden diesen Binärwert als Signatur oder Hash.

Umwandlung der Nachricht und des geheimen Schlüssels in Byte-Daten

Die Umwandlung der Nachricht und des geheimen Schlüssels in ein zeichenbasiertes Format, das für kryptografische Operationen geeignet ist, ist der erste Schritt zur Erstellung einer Signatur. Normale Zeichenketten eines Textes sind nicht direkt mit Hashing- und HMAC-Operationen in MQL5 kompatibel. Vielmehr arbeiten sie mit unbearbeiteten Byte-Daten. Das bedeutet, dass die für Menschen lesbare Nachricht und der geheime Schlüssel in eine Low-Level-Darstellung umgewandelt werden müssen, bevor eine kryptografische Verarbeitung beginnen kann. Bei den zu schützenden Daten handelt es sich in der Regel um die umzuwandelnde Nachricht, z. B. eine aus Anforderungsparametern bestehende Abfragezeichenfolge. Um sicherzustellen, dass jede Anfrage eindeutig ist, enthält diese häufig einen Zeitstempel. Der private Wert, den Sie vom API-Anbieter erhalten, wird als geheimer Schlüssel bezeichnet. Um sicherzustellen, dass dieselbe Eingabe sowohl auf Ihrem System als auch auf der Serverseite konsistent dieselbe Signatur erzeugt, müssen beide Werte sorgfältig behandelt und konsistent übersetzt werden.

Bei diesem Umwandlungsverfahren wird eine Standard-Textkodierung verwendet, um jeden Buchstaben in der Nachricht und den geheimen Schlüssel in den entsprechenden Byte-Wert umzuwandeln. UTF-8 wird häufig verwendet, weil es weithin unterstützt wird und gewährleistet, dass die Daten auf vielen Systemen einheitlich interpretiert werden. Zwei Bytefolgen, eine für die Nachricht und die andere für den geheimen Schlüssel, sind das Ergebnis dieser Phase. Da kryptografische Techniken von präzisen Bytefolgen abhängen, ist diese Übersetzung unerlässlich. Eine Signatur wäre ganz anders, wenn es auch nur eine kleine Abweichung in der Codierung oder Darstellung gäbe. Wir garantieren die Genauigkeit des anschließenden kryptografischen Prozesses und die Fähigkeit des Servers, die identische Signatur zur Überprüfung zu replizieren, indem wir sowohl die Nachricht als auch den geheimen Schlüssel auf kontrollierte und vorhersehbare Weise in Byteform umwandeln.

Die Nachricht und der geheime Schlüssel haben das richtige Format, um im Verfahren HMAC SHA256 verwendet zu werden, sobald dieser Schritt abgeschlossen ist. Alle nachfolgenden Operationen arbeiten mit diesen Darstellungen auf Byte-Ebene, sodass eine sichere Signatur erstellt werden kann, ohne dass der geheime Schlüssel jemals offengelegt wird.

Beispiel:

//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
//---

   string message = "71772777";
   string key = "ABCDER2y8VAzqopxzLVEhVYABCDEV2AxIYLueComud3aSEez8Z8fvgHPZTXABCDE";

   uchar uMsg[], uKey[];

   StringToCharArray(message, uMsg, 0, StringLen(message), CP_UTF8);
   StringToCharArray(key, uKey, 0, StringLen(key), CP_UTF8);
  }

Erläuterung:

Die Definition der Nachricht und des geheimen Schlüssels in einem lesbaren Format ist der erste Schritt. Die Daten, die signiert werden müssen, werden durch die Nachricht dargestellt; in der tatsächlichen API-Nutzung ist dies häufig ein Zeitstempel oder eine Mischung aus Anforderungsparametern. Nur Ihr System und der Server sollten den geheimen Schlüssel kennen, d. h. den von der Plattform bereitgestellten privaten Wert. Beide sind jetzt nur noch als Klartext verfügbar, was für Menschen nützlich, aber für kryptografische Operationen ungeeignet ist.

Der nächste Schritt ist die Einrichtung eines Speichers, in dem Byte-Rohdaten gespeichert werden können. Da es sich bei dem Text um eine abstrakte Darstellung handelt, können kryptografische Verfahren nicht direkt mit ihm umgehen. Vielmehr benötigen sie Bytes. Deswegen werden spezielle Byte-Container für die Speicherung des geheimen Schlüssels und der transformierten Versionen der Nachricht eingerichtet. Während des Umwandlungsprozesses werden diese Container aus ihrem leeren Ausgangszustand heraus gefüllt. Die Nachricht wird dann von Text in ihre Byte-Darstellung umgewandelt. Die Konsistenz wird durch die Verwendung der UTF-8-Codierung für diese Konvertierung gewährleistet. Dieselben Zeichen werden dank UTF-8 immer in dieselbe Bytefolge umgewandelt. Dies ist von entscheidender Bedeutung, da eine geringfügige Abweichung bei den Bytes zu einer ganz anderen Signatur führen kann.

Der geheime Schlüssel wird dann demselben Umwandlungsverfahren unterzogen. Die Zeichen des Schlüssels werden in Bytes umgewandelt und in separaten Containern aufbewahrt. Der geheime Schlüssel wurde noch nicht weitergegeben und ist noch vertraulich. Es wurde nur so hergestellt, dass es für kryptografische Funktionen verständlich ist. Die Byte-Arrays für die Nachricht und den geheimen Schlüssel werden nun im System gespeichert, wenn beide Konvertierungen abgeschlossen sind. Signierung und Hashing haben noch nicht stattgefunden. Die Vorbereitung ist der einzige Zweck dieses Schrittes. Damit das Verfahren HMAC SHA256 in der nächsten Phase eine legitime und überprüfbare Signatur erzeugen kann, muss sichergestellt sein, dass die Daten im richtigen Format vorliegen.

Analogie:

Angenommen, der geheime Schlüssel und die Nachricht sind zwei handschriftliche Notizen. Die Informationen, die Sie übermitteln möchten, wie ein Zeitstempel oder spezifische Angaben zur Anfrage, sind in einer einzigen Notiz enthalten. Nur Sie und der Empfänger kennen den eindeutigen Code auf der anderen Note. Beide Vermerke sind nun in einfacher Handschrift verfasst, die zwar von Menschen gelesen werden kann, aber für Sicherheitskontrollen durch Maschinen unzuverlässig ist. Im nächsten Schritt werden zwei leere Envelopes vorbereitet. Diese Envelopes sind lediglich Container, in die die Notizen in einem maschinenlesbaren Format eingelegt werden; sie sind noch nicht für den Postversand bestimmt. Die Envelopes sind nun leer und warten darauf, gefüllt zu werden. Stellen Sie sich nun vor, dass Sie die Nachricht aus der ursprünglichen handschriftlichen Notiz nehmen und jedes Wort in eine starre, standardisierte Sprache umwandeln, auf die Sie und der Empfänger sich geeinigt haben.

Dies ist vergleichbar mit der Umwandlung von Handschrift in maschinengeschriebenen Text unter Verwendung eines bestimmten Alphabets, bei dem jeder Buchstabe das gleiche Aussehen hat. Dadurch wird sichergestellt, dass die Nachricht immer auf die gleiche Weise und ohne Mehrdeutigkeit verstanden wird. Mit dem geheimen Schlüssel verfahren Sie dann genauso. Sie kopieren es in derselben maschinenfreundlichen, standardisierten Sprache und stecken es in einen eigenen Envelope, aber es bleibt privat und verlässt nie Ihren Schreibtisch. Der Trick besteht darin, für den nächsten Schritt bereit zu sein; er wird nicht geteilt. Sie haben dann zwei Envelopes: einen mit dem übersetzten geheimen Schlüssel und den anderen mit der übersetzten Nachricht. Beide sind nur darauf vorbereitet, im nächsten Schritt zur Erstellung einer sicheren Signatur verwendet zu werden; noch ist nichts versiegelt oder gesichert.

Vorbereiten der inneren und äußeren Pads für die Unterzeichnung

Ziel ist es nun, den geheimen Schlüssel in zwei eindeutige Arbeitsformen umzuwandeln, die zur sicheren Kombination von Schlüssel und Nachricht verwendet werden. Diese beiden Typen werden häufig als Außen-Pad und Innen-Pad bezeichnet. Sie werden nicht irgendwohin geschickt und sind nicht willkürlich. Sie sind nur während des Unterzeichnungsvorgangs anwesend. Der Vorgang ist vergleichbar mit der Erstellung von zwei unterschiedlichen Siegelstempeln mit demselben Hauptschlüssel. Obwohl beide Stempel aus demselben Geheimnis stammen, werden sie leicht modifiziert, um unterschiedliche Funktionen während des Verifizierungsprozesses zu erfüllen. Der Prozess beginnt mit dem einen Stempel und endet mit dem anderen. Eine zusätzliche Sicherheitsebene wird hinzugefügt, und die Signatur ist weitaus schwieriger zu fälschen, wenn zwei separate Pads statt nur eines verwendet werden.

Hier ist die feste Größe entscheidend. HMAC verwendet Blöcke mit einer bestimmten Länge; bei SHA256 beträgt diese Länge 64 Byte. Die Technik garantiert Konsistenz und Sicherheit, indem sie den Schlüssel in genau diese Größe bringt und ihn dann auf zwei verschiedene Arten mischt. Das Verfahren folgt immer einer vorhersehbaren Struktur, unabhängig davon, wie lang oder kurz der ursprüngliche geheime Schlüssel war.

Beispiel:

//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
//---

   string message = "71772777";
   string key = "ABCDER2y8VAzqopxzLVEhVYABCDEV2AxIYLueComud3aSEez8Z8fvgHPZTXABCDE";

   uchar uMsg[], uKey[];

   StringToCharArray(message, uMsg, 0, StringLen(message), CP_UTF8);
   StringToCharArray(key, uKey, 0, StringLen(key), CP_UTF8);



   int blockSize = 64;

   uchar ipad[], opad[];
   ArrayResize(ipad, blockSize);
   ArrayResize(opad, blockSize);

   for(int i = 0; i < blockSize; i++)
     {
      ipad[i] = uKey[i] ^ 0x36;
      opad[i] = uKey[i] ^ 0x5C;
     }

  }

Erläuterung:

Die Einstellung der Blockgröße für das Verfahren SHA-256-Hashing ist das erste, was wir in dieser Phase tun. Die Daten werden von SHA-256 in Blöcken mit fester Größe von 64 Byte verarbeitet. Die Länge des inneren Pads (ipad) und des äußeren Pads (opad), die in HMAC verwendet werden, wird durch diese Blockgröße bestimmt. Wir garantieren, dass beide Pads die richtige Länge für die HMAC-Berechnung haben, indem wir die Blockgröße angeben. Die inneren und äußeren Pads werden dann in zwei Arrays, ipad und opad, gespeichert. Diese Arrays sind auf eine Blockgröße von 64 Byte eingestellt. An jeder Stelle des Arrays wird ein einzelnes Byte gespeichert, das dem geheimen Schlüssel entnommen und so verändert wurde, dass es für den Hashing-Vorgang geeignet ist.

In dieser Phase wird jedes Byte des geheimen Schlüssels nacheinander in einer Schleife verarbeitet. Um jedes Byte für das innere und äußere Auffüllen vorzubereiten, wird es mit einer festen Konstante gekoppelt. Dadurch wird gewährleistet, dass der Schlüssel für das Hashing-Verfahren entsprechend geändert wird, ohne dass der ursprüngliche Schlüssel verändert wird. In dieser Phase wird im Wesentlichen der Schlüssel für den Hashing-Prozess verschlüsselt, indem jedes Byte auf konsistente und vorhersehbare Weise verändert wird. Zur Unterscheidung der inneren und äußeren Pads werden zwei eindeutige Konstanten gewählt. Da die inneren und äußeren Pads in verschiedenen Hashing-Phasen verwendet werden, die zusammen eine sichere Signatur ergeben, ist diese Unterscheidung entscheidend.

Wenn diese Phase abgeschlossen ist, haben wir zwei vorbereitete Pads. Eine für den inneren Teil und eine für den äußeren Teil. Beide basieren auf dem geheimen Schlüssel, wurden aber leicht verändert, um sie für das Hashing vorzubereiten. Die Nachricht und der innere Block werden zunächst verkettet und gehasht. Die endgültige Signatur wird dann durch Kombination dieses Hashes mit dem äußeren Pad erstellt. Damit ist gewährleistet, dass die Signatur ausschließlich für Ihren Schlüssel gilt und nicht verändert werden kann.

Analogie:

Nehmen wir an, Sie verwenden ein sicheres Mailing-System, um ein besonders wichtiges Dokument zu versenden. Dieses System unterliegt einer strengen Beschränkung, nach der alle Dokumente in Envelopes gleicher Größe verschlossen werden müssen, bevor sie bearbeitet werden können. Die Blockgröße von 64 ist diese feste Größe der Envelopes. Bevor es losgeht, muss alles genau auf diese Größe zugeschnitten sein, unabhängig davon, wie lang oder kurz Ihre Nachricht ist. Betrachten Sie nun den geheimen Schlüssel als einen eindeutigen Beweis dafür, dass das Dokument wirklich von Ihnen stammt. Sie müssen diesen Streifen verwenden, um zwei einzelne Schutzschichten zu erzeugen, bevor Sie das Dokument versiegeln. Das innere und das äußere Pad sind diese beiden Schichten.

Sie können mit zwei speziell entworfenen Sicherheitshüllen verglichen werden, die die Nachricht in verschiedenen Überprüfungsphasen umschließen würden. Jede Hülle wird genau auf die benötigte Größe abgestimmt, da sie die gleiche Größe wie der Envelope haben muss. Es folgt die Customizing-Phase. Ein Teil des geheimen Schlüssels wird mit einem vorbestimmten Muster für jeden Punkt in diesen Hülsen kombiniert. Die äußere Hülle hat ein anderes Muster als die innere Hülle. Dieses Mischverfahren ist vergleichbar mit der Verwendung von zwei verschiedenen Stempelmustern, um Ihr unverwechselbares Siegel in beide Hüllen zu prägen. Das Endprodukt wird zu etwas, das nur Sie und der Empfänger duplizieren können, da die Muster festgelegt sind und das Siegel vertraulich ist.

Generierung der Signatur

Die eigentliche Signatur wird in dieser Phase unter Verwendung der zuvor erstellten inneren und äußeren Pads erstellt. Der innere Hash und der äußere Hash sind die beiden primären Hashing-Schritte des Verfahrens. Die zu signierende Nachricht wird zunächst mit dem inneren Pad verbunden, und diese kombinierten Daten werden dann gehasht. Der innere Hash ist das Ergebnis dieses ersten Hashes. Das äußere Pad und die innere Hash werden dann miteinander verbunden. Der endgültige Hashwert wird dann durch erneutes Hashing dieser neuen Kombination erzeugt. Die ursprüngliche Nachricht und der geheime Schlüssel werden durch diesen Endwert, der als sichere Signatur fungiert, eindeutig dargestellt.

Schließlich wird der von uns erzeugte Hash aus einer Bytefolge in ein lesbares Format, in der Regel hexadezimal, umgewandelt, so wie ein Geheimcode in eine schriftliche Nachricht umgewandelt wird. Diese Nachricht wird als Signatur für die API-Anforderung verwendet. Er wird vom Server verwendet, um zu überprüfen, dass die Nachricht tatsächlich vom Inhaber des geheimen Schlüssels stammt und während der Übertragung nicht verändert wurde. In dieser Phase wird ein sicheres „digitales Siegel“ erstellt, das zur Verwendung bereit ist, indem die Nachricht und der Schlüssel zusammengeschlossen werden.

Beispiel:

//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
//---

   string message = "71772777";
   string key = "ABCDER2y8VAzqopxzLVEhVYABCDEV2AxIYLueComud3aSEez8Z8fvgHPZTXABCDE";

   uchar uMsg[], uKey[];

   StringToCharArray(message, uMsg, 0, StringLen(message), CP_UTF8);
   StringToCharArray(key, uKey, 0, StringLen(key), CP_UTF8);



   int blockSize = 64;

   uchar ipad[], opad[];
   ArrayResize(ipad, blockSize);
   ArrayResize(opad, blockSize);

   for(int i = 0; i < blockSize; i++)
     {
      ipad[i] = uKey[i] ^ 0x36;
      opad[i] = uKey[i] ^ 0x5C;
     }


   uchar innerData[], innerHash[];
   ArrayCopy(innerData, ipad);
   ArrayCopy(innerData, uMsg, blockSize);
   CryptEncode(CRYPT_HASH_SHA256, innerData, uKey, innerHash);


   uchar outerData[], finalHash[];
   ArrayCopy(outerData, opad);
   ArrayCopy(outerData, innerHash, blockSize);
   CryptEncode(CRYPT_HASH_SHA256, outerData, uKey, finalHash);

   string signature = "";
   for(int i = 0; i < ArraySize(finalHash); i++)
      signature += StringFormat("%02x", finalHash[i]);

   Print(signature);

  }

Erläuterung:

Die inneren Daten und das Ergebnis des inneren Hashes werden in zwei Arrays gespeichert, die im ersten Abschnitt erstellt werden. Das innere Pad (iPad) und die Nachricht, die Sie unterschreiben möchten, werden kombiniert, um die inneren Daten zu erstellen. Die Nachricht wird direkt nach dem Kopieren des inneren Pads in das neue Array mit der Methode ArrayCopy angehängt. Dies garantiert, dass die Nachricht nach dem inneren Pad in der richtigen Byte-Reihenfolge für die innere Hash-Eingabe kommt. Da auch nur ein falsches Byte zu einem ganz anderen Hashwert führt, ist die richtige Reihenfolge entscheidend. Das Programm verwendet die Funktion CryptEncode, den SHA256-Algorithmus und den geheimen Schlüssel, um den inneren Hash zu berechnen, sobald die inneren Daten fertig sind. Dieser innere Hash fungiert als sicherer Fingerabdruck der Nachricht und des inneren Pads zusammen und ist mit Ihrem geheimen Schlüssel verbunden. Sie ist die erste Hashing-Schicht von HMAC-SHA256 und stellt sicher, dass die endgültige Signatur sowohl von der Nachricht als auch von Ihrem geheimen Schlüssel abhängt.

Die Aufbereitung der externen Daten ist die nächste Phase. Diese Prozedur ist vergleichbar mit der inneren Datenvorbereitung: Es wird ein Array gebildet, und ArrayCopy wird verwendet, um das äußere Pad (opad) in dieses zu kopieren. Der innere Hash wird dann demselben Array hinzugefügt, das dem äußeren Pad folgt. Die Eingabe für die endgültige Hash-Berechnung setzt sich aus dem äußeren Pad und dem inneren Hash zusammen. Damit HMAC ordnungsgemäß funktioniert, muss auch hier die genaue Reihenfolge eingehalten werden. Der endgültige Hashwert wird durch erneute Anwendung der Funktion CryptEncode unter Verwendung von SHA256 und des geheimen Schlüssels erstellt, nachdem die äußeren Daten vorbereitet worden sind. Der endgültige Hash ist die Signatur von HMAC-SHA256. Es handelt sich um ein spezielles Byte-Array fester Länge, in dem der geheime Schlüssel und die Nachricht sicher gespeichert werden. Mit dem gleichen Verfahren kann der Server dann bestätigen, dass die Nachricht von einer Person erstellt wurde, die den geheimen Schlüssel kennt, und dass nicht verändert wurde.

Man kann den endgültigen Hash nicht direkt über das Internet verschicken; er ist wie ein Stapel von Rohstoffen. Das Programm beginnt mit einem leeren Container, der als Signatur bezeichnet wird, um sie nutzbar zu machen. Jedes Byte aus dem Hash wird in ein zweistelliges hexadezimales Fragment umgewandelt, bevor es in den Container gelegt wird. Die sichere Signatur wird als eine einzige, saubere hexadezimale Zeichenfolge dargestellt, die Sie an Ihre API-Anforderung anhängen können, nachdem Sie diesen Vorgang für jedes Byte wiederholt haben. Schließlich wird die hexadezimale Signatur von der Software gedruckt. API-Anfragen können nun diese Signatur enthalten, die die Legitimität der Anfrage garantiert. Ihr geheimer Schlüssel muss Ihren Computer nie verlassen, da nur jemand mit dem richtigen geheimen Schlüssel eine passende Signatur erstellen kann. Da die Signatur nicht zurückverfolgt werden kann, um den geheimen Schlüssel zu enthüllen, bietet dies Sicherheit, auch wenn das Netz abgehört wird.

Analogie:

Stellen Sie sich den Vorgang so vor, als würden Sie einem Freund eine verschlossene Schatztruhe mit einem einzigartigen Siegel überreichen. Der erste Schritt besteht darin, das Innere der Truhe vorzubereiten. Nachdem Sie Ihre Nachricht eingegeben haben, sperren Sie sie mit einem Pad, das nur mit Ihrem geheimen Schlüssel verwendet werden kann. Die Nachricht und das innere Pad werden kombiniert, um den Inhalt fälschungssicher mit Ihrem Geheimnis zu verknüpfen, ähnlich wie bei der Erstellung des inneren Hashes. Danach sichern Sie die Truhe, indem Sie mithilfe der Nachricht und des Innenblocks ein spezielles Schlossmuster entwerfen. Der innere Hash wird durch dieses Sperrmuster dargestellt. Ähnlich wie bei einem komplizierten Schloss führt selbst eine geringfügige Änderung der Nachricht oder des Pads zu einem anderen Muster, sodass es für jeden unmöglich ist, die Truhe heimlich zu manipulieren.

Der äußere Teil der Truhe wird vorbereitet, sobald das innere Schloss angebracht ist. Sie setzen das innere Schloss ein, nachdem Sie eine Abdeckung hinzugefügt haben, die ebenfalls von Ihrem geheimen Schlüssel als zusätzliche Sicherheitsebene stammt. Ähnlich wie bei der Erstellung der äußeren Daten stellt diese doppelte Strategie sicher, dass jemand das Schloss nicht ohne den geheimen Schlüssel duplizieren kann, auch wenn er die innere Hälfte sieht. Das Versiegeln des äußeren Schlosses, das der Berechnung des äußeren Hash entspricht, ist der letzte Schritt. So entsteht die Signatur, ein unverwechselbares Zeichen, das belegt, dass die Truhe von Ihnen stammt und ihr Inhalt nicht verändert wurde. Sie können die Signatur gefahrlos mit Ihrem Freund teilen. Ihr Freund kann die Schlösser mit seiner Kopie Ihres geheimen Schlüssels überprüfen, nachdem er die Truhe erhalten hat. Wenn alles übereinstimmt, können sie sicher sein, dass die Truhe echt und unverfälscht ist.

Schließlich wandeln Sie das Sperrmuster in ein Format um, das jeder verwenden kann, z. B. in einen eindeutigen Code auf einem Etikett, da es sich um eine schwer lesbare Buchstaben- und Zahlenfolge handelt. Dies ist die hexadezimale Zeichenfolge der Signatur. Sie fügen diesen Code in Ihre API-Anfrage ein. Ähnlich wie Ihr Freund das Siegel der Truhe prüft, um sicherzustellen, dass sie wirklich von Ihnen stammt, überprüft der Server die Echtheit, indem er diesen Code mit seinen eigenen Berechnungen vergleicht.

 

Schlussfolgerung

In diesem Artikel haben Sie gelernt, wie man eine API-Signatur in MQL5 erstellt. Sie haben gelernt, innere und äußere Pads zu verwenden, Nachrichten und geheime Schlüssel in Hash-Werte umzuwandeln und eine Signatur zu erstellen, mit der Anfragen ordnungsgemäß validiert werden können, ohne sensible Informationen preiszugeben. Wir haben auch gesehen, dass Zeitstempel und geheime Schlüssel notwendig sind, um zu gewährleisten, dass jede Anfrage eindeutig und unmanipulierbar ist. Wir werden dies im nächsten Beitrag in die Tat umsetzen, indem wir eine Signatur erstellen und diese nutzen, um Binance nach sensiblen Daten zu fragen.