Digital signing source code software for µFR Series NFC RFID contactless readers
Digitale ondertekening is de toekomst van online zakendoen, of we het nu hebben over het eenvoudige ondertekenen van documenten, code en e-mail of meer geavanceerde cryptografische implementatie zoals we tegenwoordig zien in cryptocurrencies en blockchains.
Digital Logic Ltd. is een van de eerste bedrijven ter wereld die digitale ondertekeningsoplossingen met contactloze RFID-kaarten implementeert.
We verwachten dat oude systemen die nog gebruik maken van visitekaartjes binnenkort tot het verleden behoren.
μFR Signer-software ondersteunt zowel RSA- als ECDSA-cryptografische algoritmen voor het digitaal ondertekenen van bestanden.
Software is bedoeld voor gebruik met onze μFR-serie NFC-apparaten: Nano, Classic, Classic CS en Advance.
μFR Signer werkt met alle kaarten die RSA en ECDSA ondersteunen. In onze demonstratievideo gebruikten we JCOP-kaart J3D081.
DL Signer-kaarten bieden digitale ondertekening van gegevens en documenten in de kaarten zelf met behulp van RSA- of ECDSA-asymmetrische cryptografische algoritmen. PKI-infrastructuur wordt ondersteund en in de DL Signer-kaarten is het mogelijk om X.509-certificaten op te slaan die zijn gerelateerd aan paren cryptografische sleutels die in de kaarten zelf zijn gegenereerd. Het wordt ondersteund om alle X.509-certificaten op te slaan die deel uitmaken van de vertrouwensketen van het basiscertificaat tot het certificaat van de eindentiteit.
De openbare sleutel die wordt gegenereerd in de DL Signer-kaarten wordt in de hoofdtekst van het verzoek geplaatst tijdens het maken van de certificaatondertekeningsvereiste (hierna CSR). Het verzoek wordt op de kaart zelf ondertekend met een geschikte privésleutel die de kaart zelf nooit verlaat en op geen enkele manier kan worden gelezen na het genereren van sleutelparen. Verder wordt de CSR naar de certificatie-instelling gestuurd om op basis daarvan het X.509-certificaat te maken en te ondertekenen. Dit end-entity certificaat wordt in de DL Signer-kaart geplaatst met andere certificaten uit de vertrouwensketen en is klaar om gegevens en documenten digitaal te ondertekenen. De gebruiker kan CSR sturen naar elke certificatie-instelling waarvan hij gebruik wil maken van de diensten. Digital Logic heeft een mechanisme geboden voor het uitgeven van end-entity certificaten om het systeem te testen. Een van de basiskenmerken van het certificaat van de eindentiteit is dat de persoonlijke sleutel, die is gekoppeld aan de openbare sleutel die dergelijke certificaten bevatten, niet mag worden gebruikt om andere certificaten te ondertekenen.
De Windows-softwaretools die het genereren van cryptografische sleutelparen initiëren, CSR's genereren, de PIN- en PUK-codes van de DL Signer-kaarten beheren, de inhoud van de X.509-certificaten manipuleren en de gegevens en bestanden ondertekenen, worden gedistribueerd als "ufr-signer".
"Signature-verifier" is een Windows-toepassing die digitale RSA- en ECDSA-handtekeningen valideert.
Digitale ondertekening en validatie van handtekeningen kan ook worden gedaan vanuit de Adobe Acrobat Reader DC-applicatie met behulp van de ufr-pkcs11-module die we voor dit doel hebben ontwikkeld. Onze PKCS#11-module kan ook worden gebruikt met de populaire Mozilla's e-mailclient en webbrowser, evenals met andere softwaretools die compatibel zijn met de PKCS #11-specificatie.
We leverden ook webservices voor online controle van X.509-certificaten en ondertekende pdf-bestanden.
uFR-ondertekenaar
"uFR Signer" is een softwaretool die het genereren van cryptografische sleutelparen initieert, CSR-verzoeken genereert, dient om de PIN- en PUK-codes van de DL Signer-kaarten te beheren, de inhoud van de X.509-certificaten manipuleert en de gegevens en bestanden ondertekent.
De toepassing is verdeeld in verschillende logische eenheden met behulp van een visuele component voor tabbladbesturingselementen. De tabbladen zijn gelabeld met de namen van deze eenheden:
"RSA Keys" en "EC Keys" worden gebruikt om RSA- of ECC-sleutelparen te maken en te manipuleren.
RSA (Rivest, Shamir, &Ampleman) en ECC (Elliptic Curve Cryptography) vertegenwoordigen hedendaagse asymmetrische cryptografische algoritmen. DL Signer-kaarten ondersteunen het afzonderlijk opslaan van 3 RSA- en 3 ECC-sleutels. Elk van de cryptografische sleutels kan van verschillende lengtes en kenmerken zijn en wordt aangegeven door een cryptografisch algoritme en een sleutelindex.
Het tabblad "PIN-codes" verwijst naar het beheren en loggen van de pincode van de gebruiker op de DL Signer-kaart in het uFR-lezerveld. De PINCODE is een afkorting van "Personal Identification Number". Naast pincodes kunt u op dit tabblad ook eventueel geblokkeerde kaarten ontgrendelen met PUK-codes. PUK staat voor "PIN Unlock Key".
Het tabblad 'Kaartobjecten' wordt gebruikt om CA-certificaten en certificaten van eindentiteiten te beheren die via hun indexen aan hun respectieve cryptografische sleutels zijn gekoppeld. Certificaten moeten onder X.509 versie 3 vallen. De referenties van de eindentiteit moeten een openbare sleutel bevatten die oorspronkelijk is gegenereerd op de DL Signer-kaart in paren met de bijbehorende persoonlijke sleutel. Het primaire doel van het certificaat is voor gebruik met voorbereiding voor ondertekening via de PKCS#11-module. De aanwezigheid van de X.509-certificaten is niet verplicht voor het gebruik van de DL Signer Card met de eigen toepassingen.
Op het tabblad "Handtekening" zijn er opties voor het maken van digitale handtekeningen. Het is mogelijk om een array van bytes, een tekstinvoer of een bestand te ondertekenen. Deze handtekeningen kunnen worden geverifieerd met behulp van de toepassing "signature-verifier".
Om de prestatieproblemen efficiënt aan te pakken, zijn DL Signer Cards ontworpen om blokken met gegevens zo beknopt mogelijk te ondertekenen. Daarom is het een praktijk om de gegevens digitaal te ondertekenen met een RSA-algoritme zoals gedefinieerd door het PKCS # 1 v1.5-schema. Voor het ECDSA-algoritme zijn de procedure voor het genereren van digitale handtekeningen, opvulling en uitlijningsmechanismen gedefinieerd in RFC 6979.
De nieuwste versie van de uFRSigner-toepassing is 1.5.3.0 en het is noodzakelijk om de uFCoder-bibliotheekversie 5.0.1 of hoger en de uFR-firmwareversie 5.0.7 of hoger te gebruiken.
PINCODES
PIN-code is een afkorting van "Personal Identification Number". De DL Signer Card bevat 2 verschillende pincodes. Dit zijn SO (Security Officer) PIN en gebruikers PIN code. De zogenaamde "Security Officer" is een gebruiker die beheerdersrechten heeft voor toegang tot beveiligingsobjecten op de DL Signer Card. Dus pin-code moet verschillen van de gebruiker pincode.
"Security Officer" moet ingelogd zijn om toegang te krijgen tot de kaart in gevallen waarin het nodig is om de PIN- en PUK-codes te wijzigen en de inhoud van de opslag voor de sleutels en certificaten te wijzigen. Inloggen met een pincode van een gebruiker is nodig om de digitale handtekening van een gehashte gegevensreeks te krijgen.
Pincodes op de DL Signer Cards mogen minimaal 4 tekens en maximaal 8 tekens bevatten. Hier, onder het teken, bevindt zich een alfanumeriek (hoofdlettergevoelig) of een afdrukbaar teken. Afdrukbare tekens verwijzen voornamelijk naar leestekens op de standaardtoetsenborden. Bij het wijzigen van pincodes wordt het gebruik van specifieke tekens die alleen op afzonderlijke gelokaliseerde toetsenborden te vinden zijn, niet aanbevolen, maar alleen tekens die in de ASCII-standaard zijn en die voorkomen op standaard Amerikaanse Engelse toetsenborden.
In alle DL Signer Cards worden in eerste instantie de standaard PIN en gebruikers PIN codes ingesteld, bestaande uit acht opeenvolgende numerieke tekens '0' (nul) of "00000000".
Het maximum aantal ingevoerde onjuiste opeenvolgende pincodes is 5. Als het aantal onjuiste opeenvolgende pogingen om de pincode in te voeren wordt overschreden, wordt die pincode geblokkeerd. Hoewel de pincode niet is geblokkeerd, wordt de onjuist ingevoerde pincodesteller opnieuw ingesteld als u de juiste pincode invoert.
De enige manier om uw pincode te deblokkeren, is door de juiste PUK-code in te voeren. PUK is de afkorting van "PIN Unlock Key". SO PUK-code dient uitsluitend om SO PIN-code te deblokkeren en gebruiker PUK om gebruikers PIN-code te deblokkeren. In het geval van 10 opeenvolgende onjuist ingevoerde PUK-codes, wordt de PUK-code onbruikbaar en blijft de functionaliteit van de kaart waarop de geblokkeerde pincode betrekking heeft voor altijd geblokkeerd.
RSA-toetsen
Op het tabblad "RSA-sleutels" zijn er opties voor het maken en beheren van RSA-sleutels. Voordat u met RSA-sleutels werkt, moet de DL-ondertekenaarkaart zich in het uFR-lezerveld bevinden dat is verbonden met de computer waarop de ufr-signer-toepassing wordt uitgevoerd. Ook is SO (Security Officer) verplicht om ingelogd te zijn.
EC-toetsen
Op het tabblad "EC Keys" zijn er opties voor het maken en beheren van EC-sleutel. Voordat u met de EC-sleutels werkt, moet de DL-ondertekenaarkaart zich in het uFR-lezerveld bevinden dat is aangesloten op de computer waarop de ufr-signer-toepassing wordt uitgevoerd. Ook is SO (Security Officer) verplicht om ingelogd te zijn.
De DL Signer Cards ondersteunen de volgende standaard ECC-curven:
Het wordt gedefinieerd door de PKCS#10-standaard en vertegenwoordigt een gestandaardiseerde record die onder andere basisinformatie bevat over de gebruiker van het certificaat in de DN-naam. Op basis van de karakteristieke naam wordt het zogenaamde Subject (subject field) gevormd in het uiteindelijke X.509 certificaat. Bovendien kunnen CSR-records ook extensies bevatten die zijn gespecificeerd door de X.509-standaard die de certificeringsinstantie (CA) kan overwegen of verwijderen, afhankelijk van het certificeringsbeleid. Het basisonderdeel van de CSR is zeker een publieke sleutel en zijn parameters. Al deze gegevens, verpakt in de vorm die is gedefinieerd door de PKCS #10-standaard, worden uiteindelijk doorgegeven door het juiste cryptografische samenvattingsalgoritme en het resultaat wordt op de kaart ondertekend met de juiste persoonlijke sleutel. De zo verkregen digitale handtekening wordt een integraal onderdeel van MVO.
De CSR wordt verzonden naar de gewenste uitgever van het certificaat, die de zogenaamde Certificate Authority (CA) vertegenwoordigt. De certificeringsinstantie genereert uw X.509-certificaat voor de eindentiteit, dat is ondertekend met de respectieve persoonlijke sleutel, die nu is gekoppeld aan de openbare sleutel in het juiste tussenliggende of basiscertificeringsinstantiecertificaat. Op deze manier wordt uw certificaat van de eindentiteit onderdeel van de vertrouwensketen die wordt gegarandeerd door de certificeringsinstantie (CA).
Het dialoogvenster "Certificate Signing Request (CSR)" is een aparte groep voor de invoer van "Distinguished Name (DN)", "Extensions" en rechtsboven in de groepen keuzelijsten met invoervak, voor het besturen van het hash-algoritme en de definitie van de cryptografische sleutel. Rechtsonder vindt u een groep knoppen voor het kiezen van activiteiten die verband houden met het genereren van MVO.
Een DN-naam, aangeduid als DN, bestaat uit een RDN-groep (Relative Distinguished Name) die de kenmerkgroep vertegenwoordigt. Bij het definiëren van een DN is de volgorde van het RDN-veld erg belangrijk. Het is belangrijk op te merken dat het mogelijk is om een enkel RDN-veld meerdere keren binnen de DN te herhalen. Er moet aan worden herinnerd dat de certificeringsinstantie (CA) niet verplicht is om een certificaat af te geven met hetzelfde DN als gedefinieerd in de CSR, maar dat het DN zich kan vormen op basis van zijn eigen regels en gegevens die zijn verkregen tijdens de eerder geïmplementeerde verificatie van de identiteit van de gebruiker.
De vorming van de DN gebeurt door de juiste RDN in de keuzelijst met invoervak te selecteren en de gewenste waarde in het tekstvak te typen. Door op de knop "Put" te drukken, wordt de aangegeven RDN op de lijst (List Box) geplaatst die DN definieert. Als een van de RDN-velden in de lijst is geselecteerd, wordt de nieuwe RDN ingevoegd tussen het geselecteerde en het vorige veld. Als er niets is geselecteerd in de DN-lijst, wordt een nieuw RDN-veld ingevoegd aan het einde van de lijst. Om de selectie in de lijst te annuleren, drukt u op de knop "Deselecteren". Onjuiste RDN kan uit de lijst worden verwijderd door op "Verwijderen" te drukken. De volgorde van het RDN-veld kan worden gewijzigd met behulp van de knoppen "Omhoog" en "Omlaag verplaatsen" die van invloed zijn op de redundantie van de geselecteerde RDN in de lijst.
Extensies zijn een optioneel onderdeel van de CSR en de certificeringsinstantie (CA) kan ze overwegen of afwijzen, afhankelijk van hun certificeringsbeleid. Het is mogelijk om meer attributen toe te wijzen en het is wenselijk om een e-mailadres te definiëren binnen het alternatieve onderwerp van het onderwerp (alternatieve naam van het onderwerp, afgekort subjectAltName) omdat dit de meest voorkomende certificeringsuitgever op de gebruikelijke plaats voor dit doel is. Voor extensies is de volgorde van individuele kenmerken niet belangrijk. Het is de bedoeling dat het gewenste doel van sleutels, het uitgebreide doel van sleutels en verklaringen met betrekking tot gekwalificeerde certificaten nog steeds kunnen worden gedefinieerd. Nogmaals moet worden benadrukt dat uitgevers van het certificaat extensies kunnen negeren en dat slechts enkele van hen zogenaamde gekwalificeerde elektronische certificaten kunnen uitgeven. In ieder geval kan de gebruiker binnen de extensies de gewenste elementen van het toekomstige certificaat aangeven, maar nogmaals, de uiteindelijke eliminatie van het X.509-certificaat hangt uitsluitend af van hun uitgever en dat alle details volledig vertrouwd moeten zijn met hun beleid voordat het uitgiftecontract wordt gesloten.
De keuze van het hash-algoritme wordt gedaan vanuit de keuzelijst met invoervak die is gemarkeerd met het "signer digest-algoritme". De standaardkeuze is SHA-256, wat betrekking heeft op het SHA2-algoritme met 256 bits aan de uitvoer of 32 bytes en dit wordt aanbevolen om te gebruiken voor CSR. SHA1 wordt niet meer aanbevolen, en SHA2 met een hoger aantal bytes aan de uitgang (384 en 512), en het SHA3-algoritme is gepland voor frequenter gebruik in de toekomst.
De sleutels en hun parameters ("signer cipher algorithm" en "signer key index (card)") kunnen hier niet worden gewijzigd en er zijn al gedefinieerd op het tabblad van waaruit u dit dialoogvenster hebt geopend ("RSA Keys" of "EC Keys") en hun doel hier is alleen informatief. Als de "RSA Keys" of "EC Keys" van waaruit u het CSR-dialoogvenster hebt geopend, er geen overeenkomstige openbare sleutel, eerder gelezen van de kaart, op het label stond dat de grootte van de RSA-sleutel aangeeft, wordt de ECDSA-curve aangegeven als "Openbare sleutel niet ingesteld". Wanneer een publieke sleutel niet is ingesteld, is het niet mogelijk om "Sign and Save CSR" uit te voeren, maar is het wel mogelijk om DN en extensies te laden vanuit een bestaande CSR of zogenaamde TBS CSR.
TBS CSR is ons interne recordformaat zogenaamde "To Be Signed" -verzoek dat kan dienen als een sjabloon voor het maken van CSR-verzoeken met meerdere gemeenschappelijke functies. TBS CSR bevat geen cryptografische sleutels, maar slaat alleen DN en extensies op.
Als u op de knop "Vermeldingen wissen" drukt, worden alle items in de DN en de extensie verwijderd, zodat het dialoogvenster is voorbereid op de nieuwe vermelding.
Door op de toets "Sign and Save CSR" te drukken, wordt de CSR op de kaart ondertekend en opgeslagen in het geselecteerde bestand. Als de kaart zich niet in het veld van de aangesloten uFR-lezer bevindt of de verkeerde pincode van de gebruiker heeft ingevoerd, ontvangt u een foutbericht met de juiste beschrijving.
Het laatste wat u moet doen nadat u de CSR hebt gegenereerd, is deze naar de certificeringsinstantie sturen om het X.509-certificaat te ontvangen. U kunt een van de commerciële of niet-commerciële certificaatuitgevers kiezen of door op de knop "Get Certificate Online" te drukken, kunt u de CSR naar onze webservice sturen om een demonstratiecertificaat te verkrijgen dat is uitgegeven door "Digital Logic Ltd." Test certificaten. De demonstratie, een testcertificaat is alleen bedoeld voor testgebruik en de geldigheidsduur is 3 maanden. Bijbehorende root- en intermediate CA-certificaten die u kunt downloaden van http://ca.d-logic.com.
Als u op de knop "Certificaat online ophalen" klikt, wordt u gevraagd om een eerder opgeslagen CSR-bestand met een ".pem" -extensie die naar de HTTP-server wordt verzonden. In verband met een server op de https://certificates.d-logic.com is geslaagd en het X.509-certificaat is uitgegeven, wordt u gevraagd de bestandsnaam op te geven om het certificaat op te slaan. Anders ontvangt u een passend foutbericht.
X.509 Objecten
Dit tabblad is bedoeld voor het beheren van de X.509-objecten met betrekking tot de certificaten op DL Signer Cards. Om X.509-objecten van een kaart te lezen, is het niet nodig om ingelogd te zijn met een van de pincodes. Om de inhoud van de opslag voor de X.509-objecten op de kaart te wijzigen, moet u zijn ingelogd met de SO-pincode op de pagina "PINCODES".
Op het tabblad "X.509-objecten" probeert de applicatie onmiddellijk de kaart te lezen die aanwezig is in het veld van de uFR-lezer. Als er geen DL Signer Card in het veld staat, verschijnt er een foutmelding, zoals weergegeven in de onderstaande afbeelding:
Als de opslag van X.509-objecten met succes van de kaart is gelezen, worden de certificaatweergavelijsten gevuld met die inhoud. U kunt deze lijsten op elk gewenst moment vernieuwen door de gewenste kaart in het lezersveld te plaatsen en op de knop "Objecten van de kaart vernieuwen" te drukken.
De selectie van het X.509-certificaatbestand wordt uitgevoerd door op de sleutel "certificaatbestand openen" te drukken. Het is ook mogelijk om certificaten te lezen van bestanden in PEM-formaat (Base64 gecodeerd), die meestal de extensie ".pem" hebben of van de binaire bestanden geschreven in ASN.1-standaard (DER-gecodeerd), die extensies ".crt", ".cer" of ".der" kunnen hebben. Als een geldig bestand is geselecteerd, wordt een systeemdialoogvenster weergegeven met de inhoud van het geselecteerde X.509-certificaat. Na het controleren van de certificaatitems, volstaat het om dit te bevestigen door op de knop "OK" te drukken.
Als u het geselecteerde certificaat op een kaart wilt opslaan, moet u de gewenste object-id (willekeurige alfanumerieke tekenreeks) invoeren die uniek moet zijn voor andere certificaten die op de kaart zijn opgeslagen. De object-ID wordt ingevoerd in het tekstvak met het label "Objects ID:". Het voorstel is dat certificaten met RSA-openbare sleutels moeten worden gemarkeerd met een ID van bijvoorbeeld. "0001" tot "0003" en degenen die ECDSA openbare sleutels bevatten, worden gemarkeerd met een ID van bijvoorbeeld "1001" tot "1003". CA-certificaten moeten ook een unieke ID-tag op de kaart hebben, dus het is een suggestie om ze te taggen met bijvoorbeeld "5001" tot "5012". Het is nog steeds nodig om een sleuteltype te selecteren. Voor rsa- en ecdsa-typen is de persoonlijke sleutelindex op de kaart gebonden aan dat certificaat en moeten deze indexen consistent zijn. Voor de CA-certificeringsinstantie is de volgorde van de index niet relevant, maar vanwege de transparantie door aanbeveling moeten ze in volgorde worden ingevoerd, de een na de ander in paren, bijvoorbeeld van root tot intermediate. Toepassingen die de PKCS#11-module ondersteunen en X.509-certificaten gebruiken, werken door alle openbare objecten van de kaart te lezen en vervolgens de vertrouwensketen te controleren op basis van de inhoud van de certificaten zelf. Uiteindelijk moet u op de knop drukken met een beschrijvende naam "Certificaat uit een bestand op de kaart plaatsen met een aangewezen ID, objecttype en index".
We noemden root- en tussenparen van CA-certificaten en het kan nodig zijn om dit verder te verduidelijken. Hier zijn we ervan uitgegaan dat het eindentiteitscertificaat in de vertrouwensketen tot stand komt via het tussenliggende naar het basis-CA-certificaat. Dit is de gebruikelijke manier om een vertrouwensketen te vormen door de officiële uitgevers van het certificaat. Dit is echter geen strikte regel en andere configuraties zijn mogelijk om CA-certificaten te wijzigen die een vertrouwensketen vormen. Het is belangrijk om te benadrukken dat er altijd twee definitieve certificaten zijn, aan het begin van de keten, het zogenaamde root (root) CA-certificaat en aan het einde van het chain end-entity certificate (leaf certificate)
Handtekening
Op het tabblad "Handtekening" zijn er opdrachten voor het verkrijgen van digitale handtekeningen van de kaart. Een set gegevens van de invoerregel met het label "M:" (bericht) of een bestand waarvan het pad kan worden ingesteld door op het keuzerondje "Bestand instellen om te ondertekenen" te klikken, kan worden ondertekend. De gegevens kunnen worden ingevoerd in hexadecimaal (HEX) formaat, Base64 gecodeerd of ASCII code lay-out.
De hexadecimale (HEX) indeling bevat paren van hexadecimale cijfers die kunnen worden gescheiden door spaties. Base64-indeling wordt vaak gebruikt in cryptografie en PEM-records van de X.509-certificaten. Hier zullen we het Base64-formaat niet in detail behandelen. De ASCII-codelay-out is een veelgebruikte standaard voor het vastleggen van tekstuele gegevenssets die alle alfanumerieke tekens en alle standaardinterpunctie bevatten. In principe valt alles wat via het standaard Amerikaans-Engelse toetsenbord kan worden ingevoerd, onder de ASCII-codelay-out. Als er toevallig tekens worden ingevoerd die geen deel uitmaken van de ASCII-codelay-out en deze optie is geselecteerd, worden deze tekens intern vervangen door het teken '?'. Tekens die geen deel uitmaken van de ASCII-code-indeling kunnen worden ingevoerd via sommige gelokaliseerde toetsenborden of door de optie "plakken" te selecteren in het contextmenu van het tekstvak "M:".
Wanneer sommige gegevens in de invoerregel worden ingevoerd, wordt conversie naar een ander type record uitgevoerd door eenvoudig het gewenste recordformaat te selecteren (HEX / Base64 / ASCII-opties), behalve wanneer er een invoerfout is.
Als u op het keuzerondje "Bestand instellen om te ondertekenen" klikt, wordt een dialoogvenster voor bestandsselectie geopend dat standaard is voor het Windows-besturingssysteem. Wanneer het bestand is geselecteerd, wordt het pad ingesteld op het tekstvak 'M:'.
Door op de knop "Bericht opslaan in binair bestand" te drukken, wordt het mogelijk gemaakt om een array van bytes op te slaan die zijn ingevoerd in het tekstvak "M:" in het binaire bestand.
Door de "Get signature" te selecteren, passeren de te ondertekenen gegevens het geselecteerde hash-algoritme (Message digest algorithm) waarvan het resultaat naar de kaart wordt verzonden. De kaart genereert vervolgens een handtekening op basis van het geselecteerde cryptografische algoritme uit de keuzelijst met invoervak "Cipher algorithm" (RSA of ECDSA) en de sleutelindex op de kaart ("Sleutelindex op kaart" keuzelijst met invoervak). Om de kaart te ondertekenen, is het noodzakelijk om vooraf ingelogd te zijn met de pincode van de gebruiker.
Na succesvolle ondertekening wordt de waarde van de digitale handtekening weergegeven in het tekstvak "Handtekening" in HEX- of Base64-indeling, afhankelijk van de geselecteerde optie. Door de HEX / Base64-selectie te wijzigen, is het mogelijk om de handtekeningweergave te converteren. De handtekening kan worden opgeslagen in het binaire bestand door op de knop "Handtekening opslaan in binair bestand" te drukken.
Optionele berekening van de hashwaarde van de digitale handtekening is ook geïmplementeerd. De keuze van hash-algoritmen voor dit doel omvat ook het verouderde MD5-algoritme om historische redenen, omdat sommige oude cryptografische systemen nog steeds afhankelijk zijn van dit mechanisme. De hashwaarde van een digitale handtekening kan worden opgeslagen in een binair bestand door op de knop "Hash opslaan in bestand" te drukken.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
