Online Store

NFC Digital signing software SDK

Digital signing source code software for µFR Series NFC RFID contactless readers

Die digitale Signatur ist die Zukunft des Online-Geschäfts, unabhängig davon, ob es sich um die einfache Dokument-, Code- und E-Mail-Signatur oder eine fortschrittlichere kryptografische Implementierung handelt, wie wir sie heutzutage in Kryptowährungen und Blockchains sehen.
Digital Logic Ltd. ist eines der ersten Unternehmen weltweit, das digitale Signaturlösungen mit kontaktlosen RFID-Karten implementiert.
Wir gehen davon aus, dass alte Systeme, die noch Visitenkarten verwenden, bald der Vergangenheit angehören werden.

Die μFR Signer-Software unterstützt sowohl kryptografische RSA- als auch ECDSA-Algorithmen zum digitalen Signieren von Dateien.
Die Software ist für die Verwendung mit unseren NFC-Geräten der μFR-Serie vorgesehen: Nano, Classic, Classic CS und Advance.
μFR Signer funktioniert mit allen Karten, die RSA und ECDSA unterstützen. In unserem Demonstrationsvideo haben wir die JCOP-Karte J3D081 verwendet.

Docs & Software Download

[spacer height=“20″]

Digital Signing and Verification Tools

DL Signer-Karten ermöglichen die digitale Signatur von Daten und Dokumenten in den Karten selbst mithilfe von asymmetrischen kryptografischen RSA- oder ECDSA-Algorithmen. PKI-Infrastruktur wird unterstützt und in den DL Signer-Karten ist es möglich, X.509-Zertifikate zu speichern, die sich auf Paare von kryptografischen Schlüsseln beziehen, die in den Karten selbst generiert wurden. Es wird unterstützt, alle X.509-Zertifikate zu speichern, die die Vertrauenskette vom Stammzertifikat bis zum Endentitätszertifikat bilden.

Der öffentliche Schlüssel, der in den DL Signer-Karten generiert wird, wird beim Erstellen der Zertifikatsignieranforderung (im Folgenden CSR) in den Textkörper der Anforderung eingefügt. Die Anfrage wird in der Karte selbst mit einem entsprechenden privaten Schlüssel signiert, der die Karte selbst niemals verlässt und in keiner Weise nach dem Generieren von Schlüsselpaaren gelesen werden kann. Darüber hinaus wird die CSR an die Zertifizierungsstelle gesendet, um das darauf basierende X.509-Zertifikat zu erstellen und zu signieren. Dieses End-Entity-Zertifikat wird zusammen mit anderen Zertifikaten aus der Vertrauenskette in der DL Signer-Karte platziert und ist bereit, Daten und Dokumente digital zu signieren. Der Benutzer kann CSR an jede Zertifizierungsstelle senden, deren Dienste er nutzen möchte. Digital Logic hat einen Mechanismus zum Ausstellen von Endentitätszertifikaten zum Testen des Systems bereitgestellt. Eines der grundlegenden Merkmale des Endentitätszertifikats besteht darin, dass der private Schlüssel, der mit dem öffentlichen Schlüssel gepaart ist, den diese Zertifikate enthalten, nicht zum Signieren anderer Zertifikate verwendet werden darf.

Die Windows-Softwaretools, die die Generierung kryptografischer Schlüsselpaare initiieren, CSRs generieren, die PIN- und PUK-Codes der DL Signer-Karten verwalten, den Inhalt der X.509-Zertifikate manipulieren und die Daten und Dateien signieren, werden als "ufr-signer" verteilt.

"Signature-Verifier" ist eine Windows-Anwendung, die digitale RSA- und ECDSA-Signaturen validiert.

Das digitale Signieren und Validieren von Signaturen kann auch aus der Anwendung Adobe Acrobat Reader DC mit dem dafür entwickelten Modul ufr-pkcs11 erfolgen. Unser PKCS#11-Modul kann auch mit dem beliebten E-Mail-Client und Webbrowser von Mozilla sowie mit anderen Software-Tools verwendet werden, die mit der PKCS#11-Spezifikation kompatibel sind.

Wir haben auch Webdienste für die Online-Überprüfung von X.509-Zertifikaten und signierten PDF-Dateien bereitgestellt.

uFR Unterzeichner

"uFR Signer" ist ein Software-Tool, das die Generierung kryptografischer Schlüsselpaare initiiert, CSR-Anfragen generiert, zur Verwaltung der PIN- und PUK-Codes der DL Signer-Karten dient, den Inhalt der X.509-Zertifikate manipuliert und die Daten und Dateien signiert.

Die Anwendung ist mithilfe einer visuellen Komponente für die Registerkartensteuerung in mehrere logische Einheiten unterteilt. Die Registerkarten sind mit den Namen der folgenden Einheiten gekennzeichnet:

"RSA-Schlüssel" und "EC-Schlüssel" werden verwendet, um RSA- oder ECC-Schlüsselpaare zu erstellen und zu bearbeiten.

RSA (Rivest, Shamir & Adleman) und ECC (Elliptic Curve Cryptography) repräsentieren zeitgenössische asymmetrische kryptographische Algorithmen. DL Signer-Karten unterstützen die separate Speicherung von 3 RSA- und 3 ECC-Schlüsseln. Jeder der kryptografischen Schlüssel kann unterschiedliche Längen und Eigenschaften haben und wird durch einen kryptografischen Algorithmus und einen Schlüsselindex angezeigt.

Die Registerkarte "PIN-Codes" bezieht sich auf die Verwaltung und Protokollierung des Benutzer-PIN-Codes auf der DL Signer-Karte, die sich im Feld uFR-Lesegerät befindet. Die PIN ist eine Abkürzung für "Personal Identification Number". Zusätzlich zu den PIN-Codes können Sie auf dieser Registerkarte auch eventuell blockierte Karten mit PUK-Codes entsperren. PUK steht für "PIN Unlock Key".

Die Registerkarte "Kartenobjekte" wird verwendet, um CA-Zertifikate und End-Entity-Zertifikate zu verwalten, die ihren jeweiligen kryptografischen Schlüsseln über ihre Indizes zugeordnet sind. Zertifikate müssen unter der X.509 Version 3 sein. Die Anmeldeinformationen für die Endentität müssen einen öffentlichen Schlüssel enthalten, der ursprünglich in der DL Signer-Karte in Paaren mit dem zugeordneten privaten Schlüssel generiert wurde. Der Hauptzweck des Zertifikats ist die Verwendung mit der Vorbereitung für das Signieren über das PKCS#11-Modul. Das Vorhandensein der X.509-Zertifikate ist für die Verwendung der DL Signer Card mit den proprietären Anwendungen nicht zwingend erforderlich.

Auf der Registerkarte "Signatur" gibt es Optionen zum Erstellen digitaler Signaturen. Es ist möglich, ein Array von Bytes, eine Texteingabe oder eine Datei zu signieren. Diese Signaturen können mit der Anwendung "signature-verifier" verifiziert werden.

Um die Leistungsprobleme effizient zu beheben, sind DL Signer Cards so konzipiert, dass Datenblöcke so prägnant wie möglich signiert werden. Daher ist es eine Praxis, die Daten mit einem RSA-Algorithmus gemäß dem PKCS#1 v1.5-Schema digital zu signieren. Für den ECDSA-Algorithmus sind in RFC 6979 Verfahren zur Generierung digitaler Signaturen, Auffüllung und Ausrichtungsmechanismen definiert.

Die neueste Version der uFRSigner-Anwendung ist 1.5.3.0 und es ist notwendig, die uFCoder-Bibliotheksversion 5.0.1 oder höher und die uFR-Firmware-Version 5.0.7 oder höher zu verwenden.

PIN-Codes

PIN Code ist eine Abkürzung für "Personal Identification Number". Die DL Signer Card enthält 2 verschiedene PIN-Codes. Dies sind SO (Security Officer) PIN und Benutzer-PIN-Code. Der sogenannte "Security Officer" ist ein Benutzer, der über Administratorrechte für den Zugriff auf Sicherheitsobjekte auf der DL Signer Card verfügt. Der PIN-Code sollte sich also vom PIN-Code des Benutzers unterscheiden.

"Security Officer" muss eingeloggt sein, um auf die Karte zugreifen zu können, wenn es notwendig ist, die PIN- und PUK-Codes zu ändern und den Inhalt des Speichers für die Schlüssel und Zertifikate zu ändern. Die Anmeldung mit einem Benutzer-PIN-Code ist erforderlich, um die digitale Signatur einer gehashten Datenzeichenfolge zu erhalten.

PIN-Codes auf den DL Signer Cards können mindestens 4 Zeichen und maximal 8 Zeichen lang sein. Hier befindet sich unter dem Zeichen ein beliebiges alphanumerisches Zeichen (Groß-/Kleinschreibung beachten) oder ein beliebiges druckbares Zeichen. Druckbare Zeichen beziehen sich hauptsächlich auf Satzzeichen auf den Standardtastaturen. Beim Ändern von PIN-Codes wird nicht empfohlen, bestimmte Zeichen zu verwenden, die nur auf einzelnen lokalisierten Tastaturen zu finden sind, sondern nur Zeichen, die im ASCII-Standard enthalten sind und auf Standardtastaturen für US-Englisch vorhanden sind.

In allen DL Signer Cards werden zunächst die Standard-PIN und die Benutzer-PIN-Codes festgelegt, die aus acht aufeinanderfolgenden numerischen Zeichen "0" (Null) oder "00000000" bestehen.

Die maximale Anzahl falscher aufeinanderfolgender PIN-Codes, die eingegeben wurden, beträgt 5. Wenn die Anzahl der fehlerhaften aufeinanderfolgenden Versuche, den PIN-Code einzugeben, überschritten wird, wird dieser PIN-Code blockiert. Während der PIN-Code nicht blockiert ist, wird durch Eingabe des richtigen PIN-Codes der falsch eingegebene PIN-Codezähler zurückgesetzt.

Die einzige Möglichkeit, Ihre PIN zu entsperren, besteht darin, den richtigen PUK-Code einzugeben. PUK ist die Abkürzung für "PIN Unlock Key". SO PUK-Code dient ausschließlich dazu, SO-PIN-Code zu entsperren, und Benutzer-PUK, um Benutzer-PIN-Code zu entsperren. Bei 10 aufeinanderfolgenden falsch eingegebenen PUK-Codes wird der PUK-Code unbrauchbar und die Funktionalität der Karte, auf der sich der gesperrte PIN-Code bezieht, bleibt für immer gesperrt.

uFR DL Unterzeichner-Pin

RSA-Schlüssel

Auf der Registerkarte "RSA-Schlüssel" finden Sie Optionen zum Erstellen und Verwalten von RSA-Schlüsseln. Vor der Arbeit mit RSA-Schlüsseln muss sich die DL Signer Card im Feld uFR-Lesegerät befinden, das mit dem Computer verbunden ist, auf dem die ufr-signer-Anwendung ausgeführt wird. Außerdem muss SO (Security Officer) eingeloggt sein.

uFR DL Signer RSA-Schlüssel

EC-Schlüssel

Auf der Registerkarte "EC-Schlüssel" gibt es Optionen zum Erstellen und Verwalten von EC-Schlüsseln. Bevor Sie mit den EC-Schlüsseln arbeiten, muss sich die DL Signer Card im Feld uFR-Lesegerät befinden, das mit dem Computer verbunden ist, auf dem die ufr-signer-Anwendung ausgeführt wird. Außerdem muss SO (Security Officer) eingeloggt sein.

uFR DL Signer ECC

Die DL Signer Cards unterstützen die folgenden Standard-ECC-Kurven:

DL Signer 22:

secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, secp256r1, secp384r1, secp521r1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1.

DL Signer 30:

secp192k1, secp192r1, secp256k1, secp256r1, secp384r1.

DL Signer 145:

secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, secp256r1, secp384r1, secp521r1.

Generieren einer Zertifikatsignieranforderung (Certificate Signing Request, CSR)

Er ist durch den PKCS#10-Standard definiert und stellt einen standardisierten Datensatz dar, der unter anderem grundlegende Informationen über den Benutzer des Zertifikats im Distinguished Name enthält. Basierend auf dem Merkmalsnamen wird im endgültigen X.509-Zertifikat das sogenannte Subjekt (Betrefffeld) gebildet. Darüber hinaus können CSR-Datensätze auch Erweiterungen enthalten, die im X.509-Standard spezifiziert sind und die die Zertifizierungsstelle (Certificate Authority, CA) je nach Zertifizierungsrichtlinie in Betracht ziehen oder verwerfen kann. Der grundlegende Teil der CSR ist sicherlich ein öffentlicher Schlüssel und seine Parameter. Alle diese Daten, verpackt in der durch den PKCS#10-Standard definierten Form, werden schließlich durch den entsprechenden kryptografischen Digest-Algorithmus geleitet und das Ergebnis wird mit dem entsprechenden privaten Schlüssel auf der Karte signiert. Die so erworbene digitale Signatur wird zu einem integralen Bestandteil von CSR.

Die CSR wird an den gewünschten Aussteller des Zertifikats gesendet, der die sogenannte Certificate Authority (CA) darstellt. Der Zertifikataussteller generiert Ihr X.509-Endentitätszertifikat, das mit seinem jeweiligen privaten Schlüssel signiert ist, der jetzt mit dem öffentlichen Schlüssel verknüpft ist, der im entsprechenden Zwischen- oder Stammzertifizierungsstellenzertifikat enthalten ist. Auf diese Weise wird Ihr Endentitätszertifikat Teil der Vertrauenskette, die von der Zertifizierungsstelle (Certification Authority, CA) garantiert wird.

Der Dialog "Certificate Signing Request (CSR)" ist eine separate Gruppe für die Eingabe von "Distinguished Name (DN)", "Extensions" und auf der oberen rechten Seite der Gruppen von Kombinationsfeldern zur Steuerung des Hash-Algorithmus und der Definition des kryptografischen Schlüssels. Unten rechts befindet sich eine Gruppe von Schaltflächen zum Auswählen von Aktivitäten im Zusammenhang mit der Generierung von CSR.

Ein definierter Name, der als DN bezeichnet wird, besteht aus einer RDN-Gruppe (Relative Distinguished Name), die die Attributgruppe darstellt. Bei der Definition eines DN ist die Reihenfolge des RDN-Feldes sehr wichtig. Es ist wichtig zu beachten, dass es möglich ist, ein einzelnes RDN-Feld innerhalb des DN mehrmals zu wiederholen. Es muss daran erinnert werden, dass die Zertifizierungsstelle (CA) nicht verpflichtet ist, ein Zertifikat mit demselben DN auszustellen, wie in der CSR definiert, aber der DN kann auf der Grundlage seiner eigenen Regeln und Daten gebildet werden, die während der zuvor implementierten Überprüfung der Identität des Benutzers erhalten wurden.

Die Bildung des DN erfolgt durch Auswahl des entsprechenden RDN aus dem Kombinationsfeld und Eingabe des gewünschten Wertes in das Textfeld. Durch Drücken der Schaltfläche "Put" wird der deklarierte RDN in die Liste (List Box) aufgenommen, die DN definiert. Wenn eines der RDN-Felder in der Liste ausgewählt wurde, wird das neue RDN zwischen dem ausgewählten und dem vorherigen Feld eingefügt. Wenn in der DN-Liste nichts ausgewählt ist, wird am Ende der Liste ein neues RDN-Feld eingefügt. Um die Auswahl in der Liste aufzuheben, drücken Sie die Schaltfläche "Auswahl aufheben". Falscher RDN kann aus der Liste entfernt werden, indem Sie auf "Entfernen" klicken. Die Reihenfolge des RDN-Felds kann mit den Schaltflächen "Nach oben" und "Nach unten" geändert werden, die sich auf die Redundanz des ausgewählten RDN in der Liste auswirken.

Erweiterungen sind ein optionaler Teil der CSR, und die Zertifizierungsstelle (Certification Authority, CA) kann sie je nach Zertifizierungsrichtlinie in Betracht ziehen oder ablehnen. Es ist möglich, weitere Attribute zuzuordnen, und es ist wünschenswert, eine E-Mail-Adresse innerhalb des alternativen Betreffs des Antragstellers (alternativer Antragstellername, abgekürzter subjectAltName) zu definieren, da dies der häufigste Zertifikatsaussteller an der für diesen Zweck üblichen Stelle ist. Bei Erweiterungen ist die Reihenfolge der einzelnen Attribute nicht wichtig. Es ist vorgesehen, dass der gewünschte Zweck von Schlüsseln, der erweiterte Zweck von Schlüsseln und Aussagen im Zusammenhang mit qualifizierten Zertifikaten weiterhin definiert werden können. Noch einmal ist zu betonen, dass Aussteller des Zertifikats Erweiterungen ignorieren können und nur einige von ihnen sogenannte qualifizierte elektronische Zertifikate ausstellen können. In jedem Fall kann der Benutzer innerhalb der Erweiterungen die gewünschten Elemente des zukünftigen Zertifikats angeben, aber auch hier hängt die endgültige Eliminierung des X.509-Zertifikats ausschließlich von seinem Aussteller ab und dass alle Details vor Abschluss des Ausstellungsvertrags vollständig mit seinen Richtlinien vertraut gemacht werden müssen.

uFR DL Unterzeichner CSR

Die Auswahl des Hash-Algorithmus erfolgt über das Kombinationsfeld, das mit dem "Signer Digest Algorithm" gekennzeichnet ist. Die Standardauswahl ist SHA-256, die sich auf den SHA2-Algorithmus bezieht, der 256 Bit an der Ausgabe oder 32 Bytes hat und für CSR empfohlen wird. SHA1 wird nicht mehr empfohlen, und SHA2 mit einer höheren Anzahl von Bytes am Ausgang (384 und 512), und der SHA3-Algorithmus ist für eine häufigere Verwendung in der Zukunft geplant.

Die Schlüssel und ihre Parameter ("Signer Cipher Algorithm" und "Signer Key Index (Card)") können hier nicht geändert werden und sind dort bereits auf der Registerkarte definiert, von der aus Sie diesen Dialog geöffnet haben ("RSA Keys" oder "EC Keys") und ihr Zweck hier ist nur informativ. Wenn die "RSA-Schlüssel" oder "EC-Schlüssel", von denen aus Sie den CSR-Dialog geöffnet haben, auf dem Etikett, das die Größe des RSA-Schlüssels angibt, kein entsprechender öffentlicher Schlüssel vorhanden war, der zuvor von der Karte gelesen wurde. Die ECDSA-Kurve wird als "Öffentlicher Schlüssel nicht gesetzt" angezeigt. Wenn kein öffentlicher Schlüssel gesetzt ist, ist es nicht möglich, "Sign and Save CSR" auszuführen, aber es ist möglich, DN und Erweiterungen aus einer bestehenden CSR oder sogenannten TBS CSR zu laden.

TBS CSR ist unser internes Datensatzformat, die sogenannte "To Be Signed" -Anfrage, die als Vorlage für die Erstellung von CSR-Anfragen mit mehreren gemeinsamen Funktionen dienen kann. TBS CSR enthält keine kryptografischen Schlüssel, sondern speichert nur DN und Erweiterungen.

Durch Drücken der Schaltfläche "Einträge löschen" werden alle Elemente im DN und der Erweiterung entfernt, sodass der Dialog für den neuen Eintrag vorbereitet ist.

Durch Drücken der Taste "CSR signieren und speichern" ist das Signieren der CSR auf der Karte und das Speichern in der ausgewählten Datei erledigt. Wenn sich die Karte nicht im Feld des angeschlossenen uFR-Readers befindet oder den falschen Benutzer-PIN-Code eingegeben hat, erhalten Sie eine Fehlermeldung mit der entsprechenden Beschreibung.

Das letzte, was nach dem Generieren der CSR zu tun ist, ist das Senden an den Zertifikataussteller, um das X.509-Zertifikat zu erhalten. Sie können einen der kommerziellen oder nichtkommerziellen Zertifikatsaussteller auswählen oder durch Klicken auf die Schaltfläche "Get Certificate Online" die CSR an unseren Webservice senden, um ein von "Digital Logic Ltd." ausgestelltes Demonstrations- und Testzertifikat zu erhalten. Prüfzertifikate. Die Demonstration, ein Testzertifikat, ist nur für die Testverwendung bestimmt und seine Gültigkeitsdauer beträgt 3 Monate. Begleitende Stamm- und Zwischenzertifizierungsstellenzertifikate können Sie von http://ca.d-logic.com herunterladen.

Wenn Sie auf die Schaltfläche "Get Certificate Online" klicken, werden Sie aufgefordert, eine zuvor gespeicherte CSR-Datei mit der Erweiterung ".pem" einzugeben, die an den HTTP-Server gesendet wird. In Verbindung mit einem Server auf dem https://certificates.d-logic.com erfolgreich ist und das X.509-Zertifikat ausgestellt wird, werden Sie aufgefordert, den Dateinamen einzugeben, um das Zertifikat zu speichern. Andernfalls erhalten Sie eine entsprechende Fehlermeldung.

X.509-Objekte

Auf dieser Registerkarte werden die X.509-Objekte verwaltet, die sich auf die Zertifikate auf DL-Signer-Karten beziehen. Um X.509-Objekte von einer Karte zu lesen, ist es nicht erforderlich, mit einem der PIN-Codes angemeldet zu sein. Um den Inhalt des Speichers für die X.509-Objekte auf der Karte zu ändern, müssen Sie mit dem SO-PIN-Code auf der Seite "PIN-Codes" angemeldet sein.

uFR DL Signer objs

Auf der Registerkarte "X.509-Objekte" versucht die Anwendung sofort, die Karte zu lesen, die im Feld des uFR-Lesegeräts vorhanden ist. Wenn sich keine DL Signer Card im Feld befindet, wird eine Fehlermeldung angezeigt, wie in der Abbildung unten gezeigt:

Fehlerbild

Wenn der X.509-Objektspeicher erfolgreich von der Karte gelesen wurde, werden die Zertifikatanzeigelisten mit diesem Inhalt aufgefüllt. Sie können diese Listen jederzeit aktualisieren, indem Sie die gewünschte Karte in das Lesefeld legen und auf die Schaltfläche "Objekte von der Karte aktualisieren" klicken.

Die Auswahl der X.509-Zertifikatsdatei erfolgt durch Drücken der Taste "Zertifikatsdatei öffnen". Es ist auch möglich, Zertifikate aus Dateien im PEM-Format (Base64-codiert) zu lesen, die normalerweise die Erweiterung ".pem" haben, oder aus den Binärdateien, die im ASN.1-Standard (DER-codiert) geschrieben sind, die die Erweiterungen ".crt", ".cer" oder ".der" haben können. Wenn eine gültige Datei ausgewählt ist, wird ein Systemdialogfeld mit dem Inhalt des ausgewählten X.509-Zertifikats angezeigt. Nach der Überprüfung der Zertifikatselemente genügt es, dies durch Drücken der Schaltfläche "OK" zu bestätigen.

Um das ausgewählte Zertifikat in einer Karte zu speichern, müssen Sie die gewünschte Objekt-ID (beliebige alphanumerische Zeichenfolge) eingeben, die in Bezug auf andere auf der Karte gespeicherte Zertifikate eindeutig sein muss. Die Objekt-ID wird in das Textfeld "Objekt-ID:" eingegeben. Der Vorschlag ist, dass Zertifikate, die öffentliche RSA-Schlüssel enthalten, mit einer ID von zB gekennzeichnet werden sollten. "0001" bis "0003" und diejenigen, die öffentliche ECDSA-Schlüssel enthalten, werden mit einer ID von zB gekennzeichnet. "1001" bis "1003". CA-Zertifikate müssen auch ein eindeutiges ID-Tag auf der Karte haben, daher ist es ein Vorschlag, sie mit z.B. "5001" bis "5012" zu kennzeichnen. Es ist immer noch notwendig, einen Schlüsseltyp auszuwählen. Bei RSA- und ECDSA-Typen ist der private Schlüsselindex in der Karte an dieses Zertifikat gebunden, und diese Indizes müssen konsistent sein. Für die CA Certificate Authority ist die Reihenfolge des Index nicht relevant, aber aufgrund der Transparenz durch Empfehlung sollten sie nacheinander in Paaren eingetragen werden, beispielsweise von root nach intermediate. Anwendungen, die das PKCS#11-Modul unterstützen und X.509-Zertifikate verwenden, lesen alle öffentlichen Objekte von der Karte und überprüfen dann die Vertrauenskette basierend auf dem Inhalt der Zertifikate selbst. Am Ende müssen Sie die Taste mit einem beschreibenden Namen "Zertifikat aus einer Datei in die Karte mit einer bestimmten ID, einem Objekttyp und einem Index" drücken.

Wir haben Stamm- und Zwischenpaare von CA-Zertifikaten erwähnt, und es kann notwendig sein, dies weiter zu klären. Hier haben wir angenommen, dass das End-Entity-Zertifikat in der Chain of Trust über das Zwischen- zum Stammzertifizierungsstellenzertifikat eingerichtet wird. Dies ist die übliche Art, eine Vertrauenskette durch die offiziellen Aussteller des Zertifikats zu bilden. Dies ist jedoch keine strenge Regel, und es sind andere Konfigurationen möglich, CA-Zertifikate zu ändern, die eine Vertrauenskette bilden. Es ist wichtig zu betonen, dass es immer zwei endgültige Zertifikate gibt, am Anfang der Kette, dem sogenannten Root-CA-Zertifikat (Root) und am Ende des Chain-End-Entity-Zertifikats (Leaf-Zertifikat)

Unterschrift

Auf der Registerkarte "Signatur" befinden sich Befehle zum Abrufen digitaler Signaturen von der Karte. Ein Datensatz aus der Eingabezeile mit der Bezeichnung "M:" (Nachricht) oder eine Datei, deren Pfad durch Klicken auf das Optionsfeld "Datei zum Signieren festlegen" festgelegt werden kann, kann signiert werden. Die Daten können im hexadezimalen (HEX) Format, Base64-codiert oder im ASCII-Code-Layout eingegeben werden.

Das hexadezimale Format (HEX) umfasst Paare von hexadezimalen Ziffern, die durch Leerzeichen getrennt werden können. Das Base64-Format wird häufig in Kryptographie und PEM-Datensätzen der X.509-Zertifikate verwendet. Hier werden wir nicht im Detail auf das Base64-Format eingehen. Das ASCII-Codelayout ist ein häufig verwendeter Standard für die Aufzeichnung von Textdatensätzen, die alle alphanumerischen Zeichen sowie alle Standardsatzzeichen enthalten. Im Prinzip wird alles, was über die US-englische Standardtastatur eingegeben werden kann, durch das ASCII-Code-Layout abgedeckt. Wenn zufällig Zeichen eingegeben werden, die nicht Teil des ASCII-Codelayouts sind, und diese Option ausgewählt ist, werden diese Zeichen intern durch das Zeichen "?" ersetzt. Zeichen, die nicht Teil des ASCII-Code-Layouts sind, können über einige lokalisierte Tastaturen oder durch Auswahl der Option "Einfügen" aus dem Kontextmenü des Textfelds "M:" eingegeben werden.

Wenn einige Daten in die Eingabezeile eingegeben werden, erfolgt die Konvertierung in einen anderen Datensatztyp durch einfache Auswahl des gewünschten Datensatzformats (HEX / Base64 / ASCII-Optionen), es sei denn, es liegt ein Eingabefehler vor.

Ein Klick auf das Optionsfeld "Datei zum Signieren festlegen" öffnet einen Dateiauswahldialog, der für Windows-Betriebssysteme Standard ist. Wenn die Datei ausgewählt ist, wird ihr Pfad auf das Textfeld "M:" festgelegt.

Durch Drücken der Schaltfläche "Nachricht in Binärdatei speichern" wird aktiviert, um ein Array von Bytes zu speichern, die in das Textfeld "M:" in der Binärdatei eingegeben wurden.

Durch Auswahl der "Signatur abrufen" durchlaufen die zu signierenden Daten den ausgewählten Hashalgorithmus (Message Digest-Algorithmus), dessen Ergebnis an die Karte gesendet wird. Die Karte generiert dann eine Signatur basierend auf dem ausgewählten kryptografischen Algorithmus aus der "Cipher Algorithm" Combo-Box (RSA oder ECDSA) und dem Schlüsselindex in der Karte ("Key index in card" Combobox). Um die Karte zu signieren, ist es notwendig, vorher mit dem Benutzer-PIN-Code angemeldet zu sein.

uFR DL Unterzeichner-Signatur

Nach erfolgreicher Signierung wird der Wert der digitalen Signatur im Textfeld "Signatur" im HEX- oder Base64-Format angezeigt, abhängig von der ausgewählten Option. Durch Ändern der HEX / Base64 Auswahl ist es möglich, die Signaturanzeige zu konvertieren. Die Signatur kann in der Binärdatei gespeichert werden, indem Sie auf die Schaltfläche "Signatur in Binärdatei speichern" klicken.

Optional wurde auch die Berechnung des Hashwerts der digitalen Signatur implementiert. Die Wahl der Hash-Algorithmen für diesen Zweck beinhaltet aus historischen Gründen auch den veralteten MD5-Algorithmus, da einige alte kryptografische Systeme immer noch auf diesen Mechanismus angewiesen sind. Der Hashwert einer digitalen Signatur kann in einer Binärdatei gespeichert werden, indem Sie auf die Schaltfläche "Hash in Datei speichern" klicken.

Software-Download

Das Software Development Kit (SDK) steht in unserem Software-Repository zum Download zur Verfügung.

Voraussetzungen

NFC-Lesegerät der μFR-Serie, μFR-Firmware-Version 3.9.53 oder höher, μFR-Bibliotheksversion 4.3.3 oder höher.

Video-Demonstration:

Software-Screenshots:

Digitale Signatur mit NFC RFID Reader uFR Classic CS 2

Weitere Links:

Um andere Softwarebeispiele zu durchsuchen oder herunterzuladen, besuchen Sie unser Gitlab Software-Repository.

Für den Kauf unserer Geräte besuchen Sie unseren offiziellen Online-Shop.

Zögern Sie nicht, unseren technischen Support zu kontaktieren , wenn Sie Fragen zu unseren Softwarebeispielen haben.