The post Factures électroniques rejetées par TTN : comprendre les erreurs et les corriger efficacement appeared first on NGSIGN.

The post Comprendre l’entête du format TEIF : identification fournisseur et client appeared first on NGSIGN.

Un format XML basé sur un schéma XSD

Le format TEIF repose sur une structure XML définie par un schéma XSD (XML Schema Definition). Ce schéma est partagé et mis à disposition par la TTN (Tunisie TradeNet) afin de garantir que toutes les factures électroniques respectent les mêmes règles de structuration.

Concrètement, cela signifie que :

• Chaque facture suit un même modèle de balises XML (ex. identification du fournisseur, détails des lignes de facturation, montants HT/TTC, taxes, etc.).

• Les systèmes des entreprises (ERP, solutions comptables, plateformes de facturation) peuvent générer et lire ces fichiers sans ambiguïté.

• La validation automatique est facilitée, réduisant les erreurs et les rejets.

La mise en place de la facturation électronique en Tunisie s’appuie sur un format normalisé, le TEIF (Tunisian Electronic Invoice Format). Ce standard vise à uniformiser la structure des factures électroniques et à garantir leur conformité légale, leur interopérabilité technique et leur sécurité.

The post Comprendre le format XML TEIF pour la facturation électronique en Tunisie​ appeared first on NGSIGN.

The post Facture électronique en Tunisie : workflows et intégration avec NGSign appeared first on NGSIGN.

The post Facture électronique en Tunisie : Votre plan d’actions avec NGSign appeared first on NGSIGN.

• Un certificat électronique : C’est une information publique qui identifie son porteur de manière unique. Ce certificat contient vos informations personnelles: votre nom et prénom, le nom de votre organisation, votre email, … D’autres données publiques peuvent y être ajoutées. Ce certificat indique les types d’utilisation de votre identité : signature, authentification, … Vous ne pouvez pas utiliser votre certificat en dehors des usages déclarés.
• Une clé privée : La clé privée est une information critique. Comme son nom l’indique, vous DEVEZ être le seul à détenir cette clé privée et contrôler son utilisation. Elle est hébergée EXCLUSIVEMENT dans un support cryptographique sécurisé.
  Elle est soit dans votre token USB protégé par un PIN soit dans un HSM distant protégé par un PIN et par un OTP (d’autres moyens d’authentification sécurisés sont possibles). Les deux supports doivent présenter des niveaux de sécurité équivalents.

Une fois vous avez votre identité électronique (votre clé privée associée à votre certificat électronique public), vous êtes prêt pour la signature.
Le processus de signature est le suivant, indépendamment du support cryptographique utilisé pour sauvegarder les clés privée :

Première étape

Cette étape (appelée ‘preparation phase’ par l’équipe NGSign) consiste à calculer les données à signer. Il s’agit d’un ensemble de données dont certaines sont obligatoires et d’autres sont optionnelles tel que :

Exemples de données obligatoires

• Le digest / hash de votre document : c’est l’empreinte du document, toute modification sur le document implique la modification de ce digest. Si le document est modifié après la signature, une simple comparaison de son empreinte actuelle à son empreinte au moment de la signature permet de détecter cette anomalie. Ceci permet de garantir l’intégrité des documents.
• L’identité du signature : certains pensent que signer un document revient à signer son empreinte. Ce n’est pas faux, mais ce n’est pas totalement correct. Au moment de signature, vous vous engagez (signez) sur votre identité aussi (vous signez des données de votre certificat). Ceci permet (entre autres) d’éviter des attaques du type substitution de certificat. Un autre blog post sera réservé pour cette attaque.
  Votre certificat est public, vous DEVEZ être capable de l’avoir à portée de main (ou à portée de votre application de signature) avant d’entamer la signature !
• L’heure de signature: C’est une autre information qui sera signée pour être conforme à un certain nombre de normes.

Exemples de données optionnelles

D’autres informations peuvent être signées selon le contexte :

• Le lieu de la signature
• Le rôle du signataire
• L’identifiant d’un document représentant le contexte dans lequel la signature est générée. Un bon exemple est dans le contexte de la facture électronique en Tunisie par TTN ou le contexte est défini par une politique sous format d’un document PDF. Chaque signataire accepte les termes de ce document au moment de la signature

 
Une fois toutes ces données sont calculées en respectant le format de signature (PAdES pour des PDF, XAdES pour des XML, …), nous obtenons ce qu’on appelle un TBS : les données To Be Signed.
Nous revenons avec d’amples détails techniques sur les formats de signature dans un prochain blog post.
 

Deuxième étape

Cette étapes consiste à générer la signature cryptographique. A ce niveau, votre clé privée et la cryptographie entrent en jeu. Vous serez sollicités pour activer l’utilisation de votre clé (PIN, PIN + OTP, …).
Le support cryptographique prendra en charge le calcul de la signature cryptographique à partir du TBS (et non du digest du document) et nous aurons une signature dite cryptographique à la fin de ce processus.

Dernière étape

A la fin de cette étape la signature avancée sera générée. Nous appelons cette étape : ‘finalization / acting phase’.
Cette étape diffère légèrement d’un format de signature à un autre (PDS, XML, …). L’idée générale simplifiée est qu’il faut ‘insérer’ la signature cryptographique, les données signées (les données qui ont donné lieu à un TBS), les données publiques dans le document (sauf pour des cas particuliers que nous traiterons dans des posts ultérieurs).
La signature avancée contient des données signées, et aussi des données permettant à toutes application de valider cette signature.
 

Conclusion

Pour finir, un document signé électroniquement est surtout protégé contre :

• La falsification : Grâce à l’utilisation des fonctions de digest, toute altération aussi minime soit elle, sur le document est détectée. La signature est considérée invalide.
• La répudiation : un signataire n’est pas en position de nier avoir signé un document. Une signature avancée permet d’identifier de manière irréfutable le signataire.

The post [TECH] C'est quoi une signature avancée ? appeared first on NGSIGN.

1. First, it is now possible to use NGSign and sign with your DigiGo certificate. All you need is to get your certificate from any ANCE reseller ; then you are ready to NGSign !
2. Also, the signature workflow management is enhanced by a new feature. Any signer have now the ability to refuse to sign a document if he does not agree with its terms with a mandatory refusal reason. The inviter (the transaction creator) will be automatically notified of the refusal and its causes.

Many minor improvements and bug corrections were also implemented.
 

Front client

New feature

• [NGWWW-175] – Add the possibility to « refuse to sign a document » (with a mandatory  refusal reason)
• [NGWWW-178] – Integrate the PDS with the new DigiGo API
• [NGWWW-179] – Add a message « signature goes here » to mark the signing zone

Bug

• [NGWWW-171] – The redirection after signature is not correctly working in the PDS
• [NGWWW-173] – Make the signature pad responsive
• [NGWWW-177] – Don’t allow signers to view the documents of CANCELED transactions

Task

• [NGWWW-168] – Fix PDS display for signatures of type DigiGo and SSCD

Server

New feature

• [NGWS-140] – Add a WS refuse to sign a document and notify the transaction creator of the refusal reason
• [NGWS-143] – Integrate the new DigiGo API and handle the DigiGo missing WS to get the public certificates
• [NGLIBS-61] – Implement the signature and registration processes of DigiGo 2.0

Bug

• [NGWS-142] – Errors occur when the phone number starts with +216
• [NGWS-144] – The certificate validity range is not correctly checked for signature with SSCD

The post [TECH] Release Notes of NGSign 2.10 appeared first on NGSIGN.

• All the signers can now perform advanced signature using their cryptographic USB tokens on a Windows environment.
• The signer may choose his own signature mode (Simple signature, Signature with a cryptographic token or signature with DigiGo) in the signing page.
• The PDS has also an integrated configuration page that allows the creator to place the visible stamps without authentication. This feature did exist in older versions of NGSign but is now made public under [NGSign_URL]/pds/# instead of [NGSign_URL]/web/

On the server side, many new features were added:

• The creators may send minimal user information to create a signature transaction and fill the missing data later (user name, email, …)
• The server can now be configured to delete or not the documents when the transaction is signed.
• The transaction creator may ask to “remind” the “current signer” after a predefined time limit
• The transaction creator may choose a signature type “LATER” and let the signer decide at the signing time to either use a cryptographic token, a simple signature or his own DigiGo account

In this version, we also allowed an unlimited number of tokens for signatures with a cryptographic USB token.
 

NGSign – Front client

New Features

• [NGWWW-165] – Implement a local signer to communicate with tokens
• [NGWWW-166] – Integrate the local signer in the PDS to allow the signature with a cryptographic token
• [NGWWW-164] – Implement a new PDS that allows to sign with a cryptographic token and allows signers to choose their signature mode

Tasks

• [NGWWW-163] – Update the web client to use the new transaction statuses as defined in the server, add ToS
• [NGWWW-162] – Externalize the PDS server (Use a separate server for the signing page).

Bugs

• [NGWWW-167] – Fix the PDS to scroll to the signature pad when the checkbox is selected

NGSign – Server side

New Features

• [NGWS-116] – Create a transaction with minimal user information and allow adding the missing information later
• [NGWS-118] – Make sending emails to signers configurable (activate – deactivate emails sent to users by API and configuration).
• [NGWS-119] – Make sending the final signed document to the signers configurable depending on the signer configuration.
• [NGWS-120] – Make deleting the signed documents after signature configurable
• [NGWS-121] – Allow the transaction creators to “remind” the signers after a fixed time limit.
• [NGWS-122] – Add a new signature mode “LATER” that allows the signer to choose his own signature canal
• [NGWS-125] – Add a cachet placement page that may be called without authentication to the new PDS server
• [NGWS-126] – Allow the creator to configure for each signer a success and an failure redirection URLs
• [NGWS-131] – Implement the WS that allow signing with a cryptographic token and grunt all users with an unlimited number of SSCD tokens
• [NGWS-107] – Allow signing with Remote Trust in NGSign

Tasks

• [NGWS-124] – Move DigiGo client to an independent server and invoke it from NGSign
• [NGWS-114] – Update the main server to allow events enabling or disabling

The post [TECH] Release Notes of NGSign 2.9 appeared first on NGSIGN.

ECDSA est un algorithme cryptographique : Elliptic Curve Digital Signature Algorithm.
ECDSA fait partie de la famille des algorithmes asymétriques. L’algorithme repose dans ce cas sur une paire de clé, une dite privée connue uniquement par son porteur et stockée sur un support dédié (carte ou token cryptographique, HSM, un fichier software pour des raisons de test, …) et une deuxième clé dite publique connue par tout le monde et stockée sous forme d’un certificat X.509 émis par une autorité de confiance (fichier .crt, .cer, .pem, …).
Dans le contexte du métier de signature électronique, le signataire utilise sa clé privée pour chiffrer des données. Le résultat de cette opération étant appelée signature cryptographique (par opposition à la signature avancée qui à son tour inclut la signature cryptographique mais y rajoute d’autres informations, conditions et contraintes).
La clé publique est à son tour utilisée pour déchiffrer (décrypter) la signature cryptographique. Cette opération permet d’assurer l’authentification de l’émetteur de la signature cryptographique.

Pourquoi ECDSA

Il est important de rappeler qu’une signature cryptographique générée avec un algorithme ECDSA ayant la taille 64 bits a le même niveau de sécurité d’une signature cryptographique RSA de taille 2048 bits.
Sachant que la norme 2D-Doc cherche à optimiser la taille de toutes ses composantes afin de générer un code à barre d’une taille raisonnable, le choix de l’utilisation de l’algorithme ECDSA devient raisonnable et évident.
La norme 2D-Doc indique qu’il faut obligatoirement utiliser des clés ECDSA en utilisant la courbe elliptique dite P-256. Rien n’interdit d’utiliser des clés d’une taille supérieure (Des clés de signature avec la courbe dite P-384 pour une plus longue validité des 2D-Doc générés, ceci est le cas de la carte Labes générée par QRSecure)
Selon les recommandations NIST https://www.keylength.com/en/4/ on peut même remarquer que les clés ECDSA avec la courbe elliptique P-256 ont le même niveau de sécurité que les clés de signature RSA de taille 3072. Dans les deux cas, les clés et les signatures sont protégés au delà de 2030.

La signature cryptographique ECDSA

La signature cryptographique est une opération purement mathématique. Dans le cadre des signatures ECDSA, ceci revient à appliquer une fonction elliptique à partir d’une base donnée.
Le résultat étant deux nombres d’une taille fixe appelés R et S. La taille de ces membres est fixe en fonction de la taille de la clé de chiffrement.
Par exemple, pour une clé de chiffrement utilisant la courbe P-256, R et S ont chacun la taille 32 alors que pour une clé de chiffrement suivant la courbe P-384, la taille de R et S est de 46.
R et S étant deux nombres, ils peuvent naturellement être soit négatifs ou positifs. Dans la pratique, un bit de valeur 0 est ajouté pour que R et/ou S qui a une valeur négative devienne positif.

Représentation de la signature cryptographique ECDSA

La signature cryptographique ECDSA peut-être représentée de plusieurs façons différentes. Nous allons nous concentrer dans ce qui suit sur deux représentations directement liées à 2D-Doc.

Représentation ASN.1 en encodage DER

Nous pouvons définir ASN.1 comme une représentation abstraite permettant de décrire des données binaires. DER étant une des implémentations de ASN.1, et celle la plus utilisée dans le cadre des signatures électroniques.
DER étant l’abréviation de Distinguished Encoding Representation. Il permet de définir une représentation universelle des données binaires. DER repose sur la notion TLV qui est l’abréviation de Tag, Length and Value.
TLV consiste à décrire toute donnée par :

• TAG : (un code, une constante, …)
• LENGTH : qui est la taille de la donnée protégée par le TAG en question
• VALUE : la valeur en question.

La définition de la signature ECDSA en ASN.1 est la suivante :

ECDSA-Sig-Value ::= SEQUENCE {
     r  INTEGER,
     s  INTEGER
   }

La représentation de la signature sera alors sous forme de
[TAG SEQUENCE] [TAILLE DE TOUTE LA SEQUENCE] [TAG INT] [TAILLE DE R] [R] [TAG INT] [TAILLE DE S] [S]
Nous distinguons dans cette représentations les TAG, les Length et les VALUE qui sont principalement R et S.
Sachant que :

• Chaque TAG est représenté par un seul octet
• Chaque LENGTH est représenté par un seul octet

Pour un exemple d’une paire de clé suivant la courbe P-256, nous pouvons avoir les combinaisons suivantes :

• R et S positifs : La taille de chacun est de 32 bits. La taille totale de la signature est alors de 70 octets.
• L’un est positif, l’autre est négatif : La taille du nombre négatif est de 33 octets que le nombre positif est de taille 32 octets. La taille totale de la signature est alors de 71 octets.
• R et S négatifs : Les deux nombres sont de taille 33 octets chacun. La taille totale de la signature est de 72 octets.

Représentation de la signature cryptographique avec 2D-Doc (CEV)

The post [TECH] L'algorithme ECDSA – Application dans 2D-Doc appeared first on NGSIGN.

Signature cryptographique

Avant d’entrer dans les détails de 2D-Doc, nous devons comprendre les notions de base de la signature cryptographique.

• Paire de clé: La cryptographie asymétrique repose sur la distinction entre deux clés: une dite privée connue seulement par son propriétaire et généralement gardée dans des conteneurs sécurisés de type smart card ou HSM et une clé publique connue par tout le monde et qui est gardée dans des fichiers de type certificat X.509.
• Le hachage : En appliquant des algorithmes adéquats, le hachage permet de calculer une empreinte digitale d’un document. A partir d’un document donné, et en appliquant un algorithme de hachage préalablement choisi, l’empreinte digitale est toujours inchangée ;
• Le chiffrement : Le chiffrement revient à protéger des données en utilisant la clé privée d’un utilisateur. La valeur obtenue est dite donnée chiffrée (ou cryptée). Pour pouvoir retrouver les données de départ, nous devons utiliser la clé publique de ce même utilisateur. Autrement dit, des données chiffrées par une clé privée ne peuvent être déchiffrées qu’avec la clé publique correspondante.

Ainsi la signature permet de :

• Protéger un document contre la falsification: grâce aux algorithmes de hachage, tout changement sur les données protégées change l’empreinte digitale du document. Les applications de validations de signature peuvent alors assurer de manière sûre si un document signé électroniquement a été falsifié.
• Assurer l’authenticité du signataire: Un document signé électroniquement a forcément été chiffré par une clé privée. Si, en utilisant un certificat public, nous arrivons à déchiffrer la signature électronique, les applications de validation peuvent alors identifier de manière sûre le créateur de la signature.

Structure d’un 2D-Doc

Méta-Données

Nous pouvons identifier deux familles d’informations dans la section des méta-données:

• Des données permettant de valider le document: Un identifiant du certificat émettant le 2D-Doc, l’autorité ayant émis le certificat de signature, le pays d’émission du certificat, … Toutes ces informations sont utiles pour la validation du 2D-Doc.
• Des données sur le document: La date d’émission du document, le type du document (facture, ..) et son périmètre. Ceci permet d’interpréter les données en respectant des structures prédéfinies.

Données

Le type des données peut être déduit des informations contenues dans les méta-données. Les données varient alors selon le type du document 2D-Doc. Nous pouvons voir ces données comme une carte de clé-valeur où pour chaque information nous trouvons un identifiant (une clé) et sa valeur.

Signature de données

Un algorithme de hachage (SHA-256) est utilisé pour calculer l’empreinte des méta-données et des données. Cette empreinte est par la suite chiffrée avec une clé privée de type ECDSA. Ces deux opérations permettent de garantir l’intégrité des données et l’authentification de leur émetteur.
Liens utiles :
L’arrêté du ministère des Technologies de la communication et de l’économie numérique (TCEN) relatif à l’amendement de l’arrêté du 19 juillet 2001 sur la fixation des spécificités techniques du cachet électronique visible a été publié le 21 février 2018.
QRSecure : Comment sécuriser un document papier avec la technologie 2D-Doc

The post QRSecure, La solution derrière la carte "Labes" de la CNAM appeared first on NGSIGN.