Online Store

NFC Digital signing software SDK

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

La signature numérique est l’avenir du commerce en ligne, qu’il s’agisse de la simple signature de documents, de codes et d’e-mails ou d’une implémentation cryptographique plus avancée comme nous le voyons aujourd’hui dans les crypto-monnaies et les blockchains.
Digital Logic Ltd. est l’une des premières entreprises au monde à mettre en œuvre des solutions de signature numérique avec des cartes RFID sans contact.
Nous nous attendons à ce que les anciens systèmes qui utilisent encore des cartes de visite deviennent bientôt une chose du passé.

Le logiciel μFR Signer prend en charge les algorithmes cryptographiques RSA et ECDSA pour la signature numérique des fichiers.
Le logiciel est destiné à être utilisé avec notre série μFR d’appareils NFC : Nano, Classic, Classic CS et Advance.
μFR Signer fonctionne avec toutes les cartes qui prennent en charge RSA et ECDSA. Dans notre vidéo de démonstration, nous avons utilisé la carte JCOP J3D081.

Docs & Software Download

Digital Signing and Verification Tools

Les cartes DL Signer fournissent la signature numérique des données et des documents dans les cartes elles-mêmes à l’aide d’algorithmes cryptographiques asymétriques RSA ou ECDSA. L’infrastructure PKI est prise en charge et dans les cartes DL Signer, il est possible de stocker des certificats X.509 liés à des paires de clés cryptographiques générées dans les cartes elles-mêmes. Il est pris en charge pour stocker tous les certificats X.509 qui composent la chaîne de confiance du certificat racine au certificat d’entité finale.

La clé publique générée dans les cartes DL Signer est placée dans le corps de la demande lors de la création de l’exigence de signature de certificat (ci-après CSR). La demande est signée dans la carte elle-même avec une clé privée appropriée qui ne quitte jamais la carte elle-même et ne peut en aucun cas être lue après avoir généré des paires de clés. En outre, le CSR est envoyé à l’organisme de certification pour créer et signer le certificat X.509 basé sur celui-ci. Ce certificat d’entité finale est placé dans la carte DL Signer avec d’autres certificats de la chaîne de confiance et est prêt à signer numériquement des données et des documents. L’utilisateur peut envoyer la RSE à tout organisme de certification dont il souhaite utiliser les services. Digital Logic a fourni un mécanisme d’émission de certificats d’entité finale pour tester le système. L’une des caractéristiques de base du certificat d’entité finale est que la clé privée, qui est associée à la clé publique contenue dans ces certificats, ne doit pas être utilisée pour signer d’autres certificats.

Les outils logiciels Windows qui lancent la génération de paires de clés cryptographiques, génèrent des CSR, gèrent les codes PIN et PUK des cartes DL Signer, manipulent le contenu des certificats X.509 et signent les données et les fichiers, sont distribués en tant que « ufr-signer ».

« Signature-verifier » est une application Windows validant les signatures numériques RSA et ECDSA.

La signature numérique et la validation des signatures peuvent également être effectuées à partir de l’application Adobe Acrobat Reader DC à l’aide du module ufr-pkcs11 que nous avons développé à cet effet. Notre module PKCS#11 peut également être utilisé avec le client de messagerie et le navigateur Web populaires de Mozilla, ainsi qu'avec d'autres outils logiciels compatibles avec la spécification PKCS#11.

Nous avons également fourni des services Web pour la vérification en ligne des certificats X.509 et des fichiers PDF signés.

Signataire uFR

« uFR Signer » est un outil logiciel qui initie la génération de paires de clés cryptographiques, génère des demandes CSR, sert à gérer les codes PIN et PUK des cartes DL Signer, manipule le contenu des certificats X.509 et signe les données et les fichiers.

L’application est divisée en plusieurs unités logiques à l’aide d’un composant visuel de contrôle de tabulation. Les onglets sont étiquetés par les noms des unités suivantes :

Les « clés RSA » et les « clés EC » sont utilisées pour créer et manipuler des paires de clés RSA ou ECC.

RSA (Rivest, Shamir et Adleman) et ECC (Elliptic Curve Cryptography) représentent des algorithmes cryptographiques asymétriques contemporains. Les cartes DL Signer prennent en charge le stockage séparé de 3 clés RSA et 3 clés ECC. Chacune des clés cryptographiques peut être de longueurs et de caractéristiques différentes et elle est indiquée par un algorithme cryptographique et un index de clé.

L’onglet « Codes PIN » fait référence à la gestion et à l’enregistrement du code PIN de l’utilisateur sur la carte DL Signer située dans le champ du lecteur uFR. Le NIP est l’abréviation de « Numéro d’identification personnel ». En plus des codes PIN, sur cet onglet, vous pouvez également déverrouiller les cartes éventuellement bloquées à l’aide de codes PUK. PUK signifie « PIN Unlock Key ».

L’onglet « Objets de carte » permet de gérer les certificats d’autorité de certification et les certificats d’entité finale associés à leurs clés cryptographiques respectives via leurs index. Les certificats doivent être sous la version X.509 3. Les informations d’identification de l’entité finale doivent contenir une clé publique générée à l’origine dans la carte signataire DL par paires avec la clé privée associée. L’objectif principal du certificat est de l’utiliser avec la préparation à la signature via le module PKCS#11. La présence des certificats X.509 n’est pas obligatoire pour l’utilisation de la carte de signataire DL avec les applications propriétaires.

Dans l’onglet « Signature », il existe des options pour créer des signatures numériques. Il est possible de signer un tableau d’octets, une entrée de texte ou un fichier. Ces signatures peuvent être vérifiées à l’aide de l’application « signature-verifier ».

Pour résoudre efficacement les problèmes de performances, les cartes signataires DL sont conçues pour signer des blocs de données de la manière la plus concise possible. Par conséquent, il est pratique de signer numériquement les données avec un algorithme RSA tel que défini par le schéma PKCS#1 v1.5. Pour l’algorithme ECDSA, la procédure de génération de signature numérique, les mécanismes de remplissage et d’alignement sont définis dans la RFC 6979.

La dernière version de l’application uFRSigner est 1.5.3.0 et il est nécessaire d’utiliser la bibliothèque uFCoder version 5.0.1 ou supérieure et le firmware uFR version 5.0.7 ou supérieure.

PIN Codes

Le code PIN est l’abréviation de « Personal Identification Number ». La carte de signataire DL contient 2 codes PIN différents. Il s’agit du code PIN SO (Security Officer) et du code PIN de l’utilisateur. Le soi-disant « Agent de sécurité » est un utilisateur qui dispose de privilèges d’administration pour accéder aux objets de sécurité sur la carte de signataire DL. Le code PIN SO doit être différent du code PIN de l’utilisateur.

« Agent de sécurité » doit être connecté pour accéder à la carte dans les cas où il est nécessaire de changer les codes PIN et PUK et de modifier le contenu du stockage pour les clés et les certificats. La connexion avec un code PIN utilisateur est nécessaire pour obtenir la signature numérique d’une chaîne de données hachée.

Les codes PIN sur les cartes de signataire DL peuvent comporter un minimum de 4 caractères et un maximum de 8 caractères. Ici, sous le caractère, il y a n’importe quel caractère alphanumérique (sensible à la casse) ou tout caractère imprimable. Les caractères imprimables se réfèrent principalement aux signes de ponctuation sur les claviers standard. Lors de la modification des codes PIN, il n’est pas recommandé d’utiliser des caractères spécifiques qui ne peuvent être trouvés que sur des claviers localisés individuels, mais uniquement des caractères qui sont en norme ASCII et qui existent sur les claviers anglais américains standard.

Dans toutes les cartes signataires DL, le code PIN par défaut et les codes PIN utilisateur sont définis initialement, composés de huit caractères numériques consécutifs '0' (zéro) ou '000000000 ».

Le nombre maximal de codes PIN consécutifs incorrects saisis est de 5. Si le nombre de tentatives successives incorrectes pour entrer le code PIN est dépassé, ce code PIN est bloqué. Bien que le code PIN ne soit pas bloqué, la saisie du code PIN correct réinitialise le compteur de codes PIN mal entré.

La seule façon de débloquer votre code PIN est d’entrer le code PUK correct. PUK est l’abréviation de « PIN Unlock Key ». Le code SO PUK sert exclusivement à débloquer le code PIN SO et le code PIN utilisateur PUK à débloquer le code PIN utilisateur. Dans le cas de 10 codes PUK consécutifs mal saisis, le code PUK devient inutilisable et la fonctionnalité de la carte sur laquelle se rapporte le code PIN bloqué reste bloquée pour toujours.

Épingle du signataire uFR DL

Clés RSA

Dans l’onglet « Clés RSA », vous trouverez des options pour créer et gérer des clés RSA. Avant d’utiliser des clés RSA, la carte de signataire DL doit se trouver dans le champ du lecteur uFR connecté à l’ordinateur exécutant l’application ufr-signer. En outre, SO (Security Officer) doit être connecté.

Clés RSA du signataire uFR DL

Clés EC

Dans l’onglet « Clés EC », il existe des options pour créer et gérer la clé EC. Avant d’utiliser les clés EC, la carte de signataire DL doit se trouver dans le champ du lecteur uFR connecté à l’ordinateur exécutant l’application ufr-signer. En outre, SO (Security Officer) doit être connecté.

uFR DL Signataire ECC

Les cartes de signataire DL prennent en charge les courbes ECC standard suivantes :

Signataire DL 22 :

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

DL Signer 30 :

secp192k1, secp192r1, secp256k1, secp256r1, secp384r1.

Signataire DL 145 :

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

Génération d’une demande de signature de certificat (CSR)

Il est défini par la norme PKCS#10 et représente un enregistrement normalisé qui, entre autres choses, contient des informations de base sur l’utilisateur du certificat dans le nom unique. Sur la base du nom caractéristique, le soi-disant sujet (champ d’objet) est formé dans le certificat X.509 final. En outre, les enregistrements CSR peuvent également contenir des extensions spécifiées par la norme X.509 que l’autorité de certification (CA) peut envisager ou rejeter, en fonction de sa politique de certification. La partie fondamentale de la RSE est certainement une clé publique et ses paramètres. Toutes ces données, emballées sous la forme définie par la norme PKCS#10, sont finalement transmises via l’algorithme de digest cryptographique approprié et le résultat est signé dans la carte avec la clé privée appropriée. La signature numérique ainsi acquise devient partie intégrante de la RSE.

Le CSR est envoyé à l’émetteur souhaité du certificat, qui représente l’autorité de certification (CA). L’émetteur du certificat générera votre certificat d’entité finale X.509, qui est signé par sa clé privée respective, désormais associée à la clé publique contenue dans le certificat d’autorité de certification intermédiaire ou racine approprié. De cette façon, votre certificat d’entité finale fait partie de la chaîne de confiance garantie par l’autorité de certification (CA).

La boîte de dialogue « Demande de signature de certificat (CSR) » est un groupe séparé pour la saisie de « Nom unique (DN) », « Extensions » et en haut à droite des groupes de zones de liste déroulante, pour contrôler l’algorithme de hachage et la définition de la clé cryptographique. En bas à droite se trouve un groupe de boutons permettant de choisir les activités liées à la génération de CSR.

Un nom unique, appelé DN, se compose d’un groupe RDN (Relative Distinguished Name) représentant le groupe d’attributs. Lors de la définition d’un DN, l’ordre du champ RDN est très important. Il est important de noter qu’il est possible de répéter un seul champ RDN plusieurs fois dans le DN. Il convient de rappeler que l'autorité de certification (CA) n'est pas obligée de délivrer un certificat avec le même DN que celui défini dans le CSR, mais le DN peut se former sur la base de ses propres règles et données obtenues lors de la vérification précédemment mise en œuvre de l'identité de l'utilisateur.

La formation du DN se fait en sélectionnant le RDN approprié dans la zone de liste déroulante et en tapant la valeur souhaitée dans la zone de texte. En appuyant sur le bouton « Put », le RDN déclaré sera placé dans la liste (zone de liste) qui définit DN. Si l’un des champs RDN a été sélectionné dans la liste, le nouveau RDN sera inséré entre le champ sélectionné et le champ précédent. Si rien n’est sélectionné dans la liste DN, un nouveau champ RDN est inséré à la fin de la liste. Pour annuler la sélection dans la liste, appuyez sur le bouton « Désélectionner ». Un RDN incorrect peut être supprimé de la liste en appuyant sur « Supprimer ». L’ordre du champ RDN peut être modifié à l’aide des boutons « Monter » et « Descendre » qui affectent la redondance du RDN sélectionné dans la liste.

Les extensions sont une partie facultative de la RSE et l’autorité de certification (CA) peut les envisager ou les rejeter, en fonction de sa politique de certification. Il est possible d'attribuer plus d'attributs, et il est souhaitable de définir une adresse e-mail dans l'autre sujet de l'objet (nom alternatif de l'objet, abrégé subjectAltName) car il s'agit de l'émetteur de certificat le plus courant à l'endroit habituel à cette fin. Pour les extensions, l’ordre des attributs individuels n’est pas important. Il est envisagé que l’objectif souhaité des clés, l’objectif élargi des clés et les déclarations relatives aux certificats qualifiés puissent encore être définis. Encore une fois, il convient de souligner que les émetteurs du certificat peuvent ignorer les extensions et que seuls certains d’entre eux peuvent émettre des certificats électroniques dits qualifiés. Dans tous les cas, dans les extensions, l’utilisateur peut indiquer les éléments souhaités du futur certificat, mais, encore une fois, l’élimination finale du certificat X.509 dépend exclusivement de son émetteur et que tous les détails doivent être pleinement familiarisés avec leurs politiques avant la conclusion du contrat émetteur.

uFR DL Signer CSR

Le choix de l’algorithme de hachage se fait à partir de la zone de liste déroulante marquée avec l’algorithme de résumé du signataire. Le choix par défaut est SHA-256, qui se rapporte à l’algorithme SHA2 qui a 256 bits à la sortie ou 32 octets et il est recommandé de l’utiliser pour CSR. SHA1 n’est plus recommandé, et SHA2 avec un nombre d’octets plus élevé à la sortie (384 et 512), et l’algorithme SHA3 est prévu pour une utilisation plus fréquente à l’avenir.

Les clés et leurs paramètres (« algorithme de chiffrement du signataire » et « index de la clé du signataire (carte) ») ne peuvent pas être modifiés ici et là sont déjà définis sur l’onglet à partir duquel vous avez ouvert cette boîte de dialogue (« Clés RSA » ou « Clés EC ») et leur but ici n’est qu’informatif. Si les « Clés RSA » ou « Clés EC » à partir desquelles vous avez ouvert la boîte de dialogue CSR, il n’y avait pas de clé publique correspondante, précédemment lue à partir de la carte, sur l’étiquette indiquant la taille de la clé RSA, La courbe ECDSA sera indiquée comme « Clé publique non définie ». Lorsqu’une clé publique n’est pas définie, il n’est pas possible d’exécuter « Sign and Save CSR », mais il est possible de charger DN et des extensions à partir d’une CSR existante ou dite TBS CSR.

TBS CSR est notre format d’enregistrement interne appelé demande « À signer » qui peut servir de modèle pour créer des demandes de RSE avec de multiples fonctionnalités communes. TBS CSR ne contient pas de clés cryptographiques, mais stocke uniquement les DN et les extensions.

Appuyez sur le bouton « Effacer les entrées » pour supprimer tous les éléments du nom unique et de l’extension afin que la boîte de dialogue soit préparée pour la nouvelle entrée.

En appuyant sur la touche « Signer et enregistrer la CSR », vous devez signer la CSR dans la carte et la stocker dans le fichier sélectionné. Si la carte ne se trouve pas dans le champ du lecteur uFR connecté ou si vous avez entré le mauvais code PIN utilisateur, vous recevrez un message d’erreur avec la description appropriée.

La dernière chose à faire après avoir généré le CSR est de l’envoyer à l’émetteur du certificat pour recevoir le certificat X.509. Vous pouvez choisir l’un des émetteurs de certificats commerciaux ou non commerciaux ou en appuyant sur le bouton « Obtenir le certificat en ligne », vous pouvez envoyer le CSR à notre service Web pour obtenir un certificat de démonstration et de test émis par « Digital Logic Ltd ». Certificats de test. La démonstration, un certificat de test est destiné à une utilisation de test uniquement et sa période de validité est de 3 mois. Les certificats d’autorité de certification racine et intermédiaire qui les accompagnent peuvent être téléchargés à partir de http://ca.d-logic.com.

Si vous cliquez sur le bouton « Obtenir un certificat en ligne », vous serez invité à entrer un fichier CSR précédemment enregistré avec une extension « .pem » qui sera envoyé au serveur HTTP. En relation avec un serveur sur le https://certificates.d-logic.com réussit et que le certificat X.509 est émis, vous serez invité à entrer le nom du fichier pour enregistrer le certificat. Sinon, vous recevrez un message d’erreur approprié.

X.509 Objets

Cet onglet est destiné à gérer les objets X.509, liés aux certificats sur les cartes de signataire DL. Pour lire des objets X.509 à partir d’une carte, il n’est pas nécessaire d’être connecté avec l’un des codes PIN. Pour modifier le contenu du stockage des objets X.509 sur la carte, vous devez être connecté avec le code PIN SO sur la page « Codes PIN ».

uFR DL Signer objs

Dans l’onglet « Objets X.509 », l’application tente immédiatement de lire la carte présente dans le champ du lecteur uFR. S’il n’y a pas de carte de signataire DL dans le champ, un message d’erreur apparaîtra, comme indiqué dans l’image ci-dessous :

Image d’erreur

Si le stockage d’objets X.509 est lu avec succès à partir de la carte, les listes d’affichage des certificats seront remplies avec ce contenu. Vous pouvez actualiser ces listes à tout moment en plaçant la carte souhaitée dans le champ du lecteur et en appuyant sur le bouton « Actualiser les objets de la carte ».

La sélection du fichier de certificat X.509 se fait en appuyant sur la touche « ouvrir le fichier de certificat ». Il est également possible de lire des certificats à partir de fichiers au format PEM (codés en Base64), qui ont généralement l’extension « .pem » ou à partir des fichiers binaires écrits en norme ASN.1 (codés DER), qui peuvent avoir des extensions « .crt », « .cer » ou « .der ». Si un fichier valide est sélectionné, une boîte de dialogue système affichant le contenu du certificat X.509 sélectionné s’affiche. Après avoir vérifié les éléments du certificat, il suffit de le confirmer en appuyant sur le bouton « OK ».

Pour stocker le certificat sélectionné dans une carte, vous devez entrer l’ID d’objet souhaité (chaîne de caractères alphanumérique arbitraire) qui doit être unique par rapport aux autres certificats stockés sur la carte. L’ID d’objet est entré dans la zone de texte intitulée « ID d’objets: ». La proposition est que les certificats contenant des clés publiques RSA doivent être marqués d’un ID de par exemple. « 0001 » à « 0003 » et ceux contenant des clés publiques ECDSA seront marqués d’un ID de par exemple. « 1001 » à « 1003 ». Les certificats d’autorité de certification doivent également avoir une étiquette d’identification unique sur la carte, il est donc suggéré de les étiqueter avec, par exemple, « 5001 » à « 5012 ». Il est toujours nécessaire de sélectionner un type de clé. Pour les types RSA et ECDSA, l’index de clé privée de la carte est lié à ce certificat et ces index doivent être cohérents. Pour l’autorité de certification de l’autorité de certification, l’ordre de l’index n’est pas pertinent, mais en raison de la transparence par recommandation, ils doivent être saisis dans l’ordre, l’un après l’autre par paires, par exemple, de la racine à l’intermédiaire. Les applications qui prennent en charge le module PKCS#11 et utilisent des certificats X.509, fonctionnent en lisant tous les objets publics de la carte, puis en vérifiant la chaîne de confiance en fonction du contenu des certificats eux-mêmes. En fin de compte, vous devez appuyer sur le bouton avec un nom descriptif « Mettre le certificat d’un fichier dans la carte avec un ID, un type d’objet et un index désignés ».

Nous avons mentionné les paires racine et intermédiaire de certificats d’autorité de certification et il peut être nécessaire de clarifier davantage cela. Ici, nous avons supposé que le certificat d’entité finale dans la chaîne de confiance est établi via le certificat d’autorité de certification intermédiaire à racine. C’est la façon habituelle de former une chaîne de confiance par les émetteurs officiels du certificat. Toutefois, il ne s’agit pas d’une règle stricte et d’autres configurations sont possibles pour modifier les certificats d’autorité de certification qui forment une chaîne de confiance. Il est important de souligner qu’il y a toujours deux certificats finaux, au début de la chaîne, le certificat d’autorité de certification racine (racine) et à la fin du certificat d’entité finale de la chaîne (certificat feuille)

Signature

Dans l’onglet « Signature », il y a des commandes pour obtenir des signatures numériques à partir de la carte. Un ensemble de données de la ligne d’entrée intitulé « M: » (message) ou un fichier dont le chemin peut être défini en cliquant sur la case d’option « Définir le fichier à signer » peut être signé. Les données peuvent être saisies au format hexadécimal (HEX), codé en Base64 ou en disposition de code ASCII.

Le format hexadécimal (HEX) inclut des paires de chiffres hexadécimaux qui peuvent être séparés par des espaces. Le format Base64 est souvent utilisé dans la cryptographie et les enregistrements PEM des certificats X.509. Ici, nous ne traiterons pas le format Base64 en détail. La disposition de code ASCII est une norme couramment utilisée pour enregistrer des ensembles de données textuelles qui incluent tous les caractères alphanumériques ainsi que toutes les ponctuations standard. En principe, tout ce qui peut être entré via le clavier anglais américain standard est couvert par la disposition du code ASCII. Si, par hasard, des caractères qui ne font pas partie de la disposition du code ASCII sont saisis et que cette option est sélectionnée, ces caractères seront remplacés en interne par le caractère '?'. Les caractères qui ne font pas partie de la disposition du code ASCII peuvent être saisis via certains claviers localisés ou en sélectionnant l’option « coller » dans le menu contextuel de la zone de texte « M: ».

Lorsque certaines données sont entrées dans la ligne d’entrée, la conversion vers un autre type d’enregistrement se fait en sélectionnant simplement le format d’enregistrement souhaité (options HEX / Base64 / ASCII), sauf en cas d’erreur de saisie.

Cliquez sur la case d’option « Définir le fichier à signer » pour ouvrir une boîte de dialogue de sélection de fichier standard pour le système d’exploitation Windows. Lorsque le fichier est sélectionné, son chemin d’accès est défini sur la zone de texte « M: ».

En appuyant sur le bouton « Enregistrer le message dans un fichier binaire », il est activé pour stocker un tableau d’octets entré dans la zone de texte « M: » dans le fichier binaire.

En sélectionnant la mention « Obtenir la signature », les données à signer passent par l’algorithme de hachage sélectionné (algorithme Message digest) dont le résultat est envoyé à la carte. La carte génère ensuite une signature basée sur l’algorithme cryptographique sélectionné à partir de la zone de liste déroulante « Algorithme de chiffrement » (RSA ou ECDSA) et de l’index de clé dans la carte (zone de liste déroulante « Index de clé dans la carte »). Pour signer la carte, il est nécessaire d’être connecté au préalable avec le code PIN de l’utilisateur.

Signature du signataire uFR DL

Une fois la signature réussie, la valeur de la signature numérique s’affiche dans la zone de texte « Signature » au format HEX ou Base64, selon l’option sélectionnée. En changeant la sélection HEX / Base64, il est possible de convertir l’affichage de la signature. La signature peut être enregistrée dans le fichier binaire en appuyant sur le bouton « Enregistrer la signature dans un fichier binaire ».

Le calcul facultatif de la valeur de hachage de la signature numérique a également été implémenté. Le choix d’algorithmes de hachage à cette fin inclut également l’algorithme MD5 obsolète pour des raisons historiques, car certains anciens systèmes cryptographiques dépendent encore de ce mécanisme. La valeur de hachage d’une signature numérique peut être stockée dans un fichier binaire en appuyant sur le bouton « Enregistrer le hachage dans le fichier ».

Téléchargement de logiciels

Le kit de développement logiciel (SDK) est disponible en téléchargement à partir de notre référentiel de logiciels.

Conditions préalables

Lecteur NFC série μFR, firmware μFR version 3.9.53 ou supérieure, bibliothèque μFR version 4.3.3 ou supérieure.

Démonstration vidéo :

Captures d’écran du logiciel :

Signature numérique à l’aide du lecteur RFID NFC uFR Classic CS 2

Liens supplémentaires:

Pour parcourir ou télécharger d’autres exemples de logiciels, visitez notre référentiel de logiciels Gitlab.

Pour acheter nos appareils, visitez notre boutique en ligne officielle.

N’hésitez pas à contacter notre support technique si vous avez des questions sur nos exemples de logiciels.