PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2024 → Sécurisation par signature electronique
Sécurisation par signature electronique
Débuté par Laurent, 03 déc. 2014 18:38 - 21 réponses
Posté le 03 décembre 2014 - 18:38
Bonjour à tous,

On me demande de mettre en place une sécurisation de l'enregistrement de données par une signature electronique dans un logiciel existant.

Avez vous eu des cas similaires?
La sécurité de hmodifie ou hajoute ne peut pas tenir compte d'une signature electronique d'apres ce que j'ai lu.

Avez vous des trucs sur le sujet. Je pense que beaucoup de logiciel vont avoir cette question bientôt.

Merci

>Laurent
Membre enregistré
392 messages
Popularité : +12 (12 votes)
Posté le 04 décembre 2014 - 05:04
Bonjour, il est facile d'ajouter un champ contenant un checksum calculé entre l'enregistrement lui-même, et une signature électronique. Lors dela lecture on vérifie la valeur trouvée, CRC OK, pas de modif des données, CRC différent, données modifiées ...

A+.

--
>If it works, don't touch it, don't look at it, AND don't fix it ! No patches, no SP ! JUST DONT FIX IT.
Posté le 04 décembre 2014 - 10:24
Bonjour,

Merci. En effet j'avais pas vu sous cet angle.
Je pensais qu'il fallait proteger la transaction entre le serveur HFCS et le logiciel.
Donc je rajoute champ CRC.
Je calcule CRC avec les données de l'enregistrement et la siganture electronique.

Si quelqu'un modifie on le retrouvera qu'il y a eu modification car le CRC n'est plus correct.
(Si atteint la base, il peut tomber su le bon CRC mais c'est un grand hasard)

La meilleure sécurité pour un tel cas, est ce plus prudent se stocker le CRC dans le même fichier ou d'avoir la liste des CRC pour chaque enregistrement dans un autre fichier?

Pour la signature électronique, il y a un organisme officiel pour celà?

J'ai bien tout compris?

Merci

>Lauren
Membre enregistré
280 messages
Popularité : +22 (28 votes)
Posté le 04 décembre 2014 - 11:01
Pour la mise en oeuvre regarde aussi du coté des triggers serveur :
http://doc.pcsoft.fr/fr-FR/?3044369&name=Trigger_serveur

--
Cordialement.

Olivier
http://www.impulse-web.com>
Posté le 04 décembre 2014 - 11:06
Le 04/12/2014 09:24, Laurent a écrit :
Bonjour,

Merci. En effet j'avais pas vu sous cet angle.
Je pensais qu'il fallait proteger la transaction entre le serveur HFCS
et le logiciel.
Donc je rajoute champ CRC.
Je calcule CRC avec les données de l'enregistrement et la siganture
electronique.

Si quelqu'un modifie on le retrouvera qu'il y a eu modification car le
CRC n'est plus correct.
(Si atteint la base, il peut tomber su le bon CRC mais c'est un grand
hasard)

La meilleure sécurité pour un tel cas, est ce plus prudent se stocker le
CRC dans le même fichier ou d'avoir la liste des CRC pour chaque
enregistrement dans un autre fichier?

Pour la signature électronique, il y a un organisme officiel pour celà?

J'ai bien tout compris?

Merci

Lauren


Bonjour,

Si ta question porte sur la NF 525 (www.nf525.com) et la sécurisation
des logiciels d'encaissement cela va un peu plus loin.

1) Ce n'est pas un simple checksum mais une signature électronique de
type clé privé / clé publique (RSA ou elliptic curve)

2) L'enregistrement doit être signé et chainé avec le précédent (tu fais
ça en ajoutant aux données de la ligne la signature de la ligne
précédente. (cela permet d'être sur qu'aucune ligne n'a été supprimée)

3) La signature des lignes est enregistrée dans la ligne (c'est plus sur
et plus simple) et stocké dans un format lisible en base 64

4) la clé privé (qui doit être sécurisé à mort et être hyper
confidentielle) peut être généré par tes soins et la clé publique doit
être disponible pour qu'un contrôleur externe (fisc ?) puisse vérifier
la validité des données.

Ca c'est les grandes lignes, va jeter un oeil sur le le site de la 525

Bon dev,

>Fred
Posté le 04 décembre 2014 - 13:35
Bonjour,

Gagné,

en effet c'est pour la 525. J'ai commencé à lire mais je ne perçois pas encore tout les changements à faire dans la base

Merci

>Laurent
Posté le 04 décembre 2014 - 17:20
Le 04/12/2014 12:35, Laurent a écrit :
Bonjour,

Gagné,
en effet c'est pour la 525. J'ai commencé à lire mais je ne perçois pas
encore tout les changements à faire dans la base

Merci

Laurent


Salut,

Le plus important, c'est que plus tu stocke d'info "en clair"
directement dans les fichiers de ventes moins tu seras embêté (par
exemple, tu stocke dans la ligne de vente le code tva ET le taux, le
code opérateur et le nom, ...) idem pour tous les champs "calculés" ex,
le prix net, le pu HT, ... doivent être stockés et non pas recalculé.

Ne te focalise pas trop sur la partie "technique", ce n'est pas le plus
dur, un truc qu'on avait pas réalisé et c'est pourtant bête comme choux
: pour être audité (et obtenir la 525) il faut être auditable et se
rapprocher des normes ISO (notamment la 25051)

Il faut donc :
- Cartographie logicielle (tableau excel qui fait le lien entre l'IHM,
le code, l'exigence 525 et la base de donnée)
- Plan de tests <= hyper important !!! surtout pour tout ce qui concerne
la 525.
- Documentation utilisateur à jour
- Suivi des modifications (le gds ne suffit pas)
- ... pleins d'autre trucs qui garantissent à l'auditeur que tu as un
minimum de suivi sur ton produit.

Si tu as des questions, n’hésite pas à les poser sur ce forum (tagge le
sujet en [NF525] et j’essaierai de t'aider au mieux.

Bon dev,

>Fred.
Posté le 05 décembre 2014 - 09:10
Bonjour,

Merci Fredo.

Je fait un petit topo sur mes questions et je refait un sujet propore à la 525.

Merci
>Laurent
Membre enregistré
34 messages
Posté le 22 décembre 2014 - 18:26
bonjour à tous, je dois moi aussi travailler sur cette norme nf 525, mon problème est d'utiliser ces fameuse clef privé et clef public.
Jusqu'à présent j'utilisai un cryptage de ma ligne ticket et de mon ticket afin de sécuriser ma ligne est mon ticket mais en utilisant seulement une clef de cryptage. Comment mettre en place cette gestion de clefs ?
>Merci pour votre aide.
Posté le 23 décembre 2014 - 11:24
Le 22/12/2014 17:26, maverick a écrit :
bonjour à tous, je dois moi aussi travailler sur cette norme nf 525, mon
problème est d'utiliser ces fameuse clef privé et clef public.
Jusqu'à présent j'utilisai un cryptage de ma ligne ticket et de mon
ticket afin de sécuriser ma ligne est mon ticket mais en utilisant
seulement une clef de cryptage. Comment mettre en place cette gestion de
clefs ?
Merci pour votre aide.


Salut,

Le but est de signer tes données avec ta clé privé (qui ne doit jamais
être divulgué à l’extérieur de ta boite) et de fournir la clé publique
aux impôts qui pourront ainsi contrôler que la signature est en
adéquation avec les données que tu as signé.

Il existe plusieurs types de signature, celles demandées par la NF 525
sont le RSA ou l'ellyptic curve.

Si tu va sur le sitehttp://www.openssl.org/tu as tout ce qu'il faut
pour générer un duo clé privé / clé publique ainsi que des DLL que tu
peux utiliser avec windev.

Bon dev,

>Fred.
Posté le 09 janvier 2015 - 12:24
Bonjour,

Je ne sais pas si Laurent a posté sur un sujet plus global concernant la certification NF525, comme il l'avait dit le mois dernier ... fouillé, rien trouvé.

Post plus global concernant le NF 525 :
http://forum.pcsoft.fr/fr-FR/pcsoft.fr.windev/178777-certification/read.awp…

Je rebondis sur la réponse de Fredo, que je reprends ci-après et je crée un nouveau post plus global :

"ll faut donc :
- Cartographie logicielle (tableau excel qui fait le lien entre l'IHM,
le code, l'exigence 525 et la base de donnée)
- Plan de tests <= hyper important !!! surtout pour tout ce qui concerne
la 525.
- Documentation utilisateur à jour
- Suivi des modifications (le gds ne suffit pas)
- ... pleins d'autre trucs qui garantissent à l'auditeur que tu as un
minimum de suivi sur ton produit."

________________________________________________________________________________

1 - Signature électronique => Il me semble qu'il n'est pas obligatoire de signer chaque ligne mais uniquement l'entête ? La dernière mouture de la certification le prévoit-elle ? Risque de ralentir drastiquement l'encaissement tout ça : j'imagine un ticket comportant une cinquantaine de lignes.

2 - Cartographie au format excel => nous avions commencé sous forme de logigrammes ... ? Obligatoire au format excel donc (?!). Serait-il possible d'avoir un exemple, afin d'avoir une idée des colonnes à placer dans le fichier ? Jusqu'à quel niveau de précision aller ? Toutes les fonctions doivent-elles être listées lors de l'Audit ou il faut axer la carto' sur l'aspect sécurisation spécifié sur la 'norme' ?

3 - Plan de test ... certainement une question idiote. Combien de tests envisager ?

A vous lire.

MERCI !

>Yo!
Membre enregistré
7 messages
Popularité : +1 (1 vote)
Posté le 05 août 2015 - 10:32
Bonjour

Je me retrouva dans la même situation que vous, je dois chiffrer à l'aide d'un couple clé privée / clé publique certaines données. Cela ne concerne pas nécessairement la NF525, c'est pourquoi je n'ai pas continué le post en question mais plutôt celui-ci. J'ai vu qu'une solution consistait à utiliser openSSL mais j'aurai souhaité ne pas avoir à faire appel à un programme externe.

Un appel à DLL ou encore une méthode intégrée m'aurait plus intéressé.

>Avez vous eu des pistes concernant tout ceci ?
Posté le 12 août 2015 - 14:25
Le 05/08/2015 08:32, Arno_INOVAXO a écrit :
Bonjour

Je me retrouva dans la même situation que vous, je dois chiffrer à
l'aide d'un couple clé privée / clé publique certaines données. Cela ne
concerne pas nécessairement la NF525, c'est pourquoi je n'ai pas
continué le post en question mais plutôt celui-ci. J'ai vu qu'une
solution consistait à utiliser openSSL mais j'aurai souhaité ne pas
avoir à faire appel à un programme externe.

Un appel à DLL ou encore une méthode intégrée m'aurait plus intéressé.

Avez vous eu des pistes concernant tout ceci ?


Salut,

Pour des questions de performance, nous avons développé notre propre dll
de cryptage en c. Il n'y a pas de méthode intégrée à windev.

>Fred
Membre enregistré
12 messages
Posté le 15 octobre 2015 - 00:28
Bonjour, je rebondis (avec quelques mois de retard) sur le propos de Fred :

Bonjour,
...

2) L'enregistrement doit être signé et chainé avec le précédent (tu fais
ça en ajoutant aux données de la ligne la signature de la ligne
précédente. (cela permet d'être sur qu'aucune ligne n'a été supprimée)

...

Fred


Stocker la signature de l'enregistrement est en effet très sécurisé.
Mais quid de la première ou de la dernière ligne du fichier ?
Cela ne veut-il pas dire que la dernière ligne est violable tant qu'il n'y a pas d'enregistrement à suivre ?

--
>Martial - ACDL informatique
Posté le 14 juin 2016 - 11:30
Je dois implementer la base pour en mettre la securité afin que les données ne soit pas supprimer. Que dois-je faire? Je ne comprend rien concernant les clé publique et privée. Qui peut m'expliquer en détails.
Posté le 14 juin 2016 - 11:34
Je ne sais pas comment créer la clé publique et la clé privé. Et comment les utiliser dans la base. Qui peut detailler?
Posté le 15 juin 2016 - 14:10
Le 14/06/2016 à 09:30, zazou a écrit :
Je dois implementer la base pour en mettre la securité afin que les
données ne soit pas supprimer. Que dois-je faire? Je ne comprend rien
concernant les clé publique et privée. Qui peut m'expliquer en détails.


Le principe de signature par algo de type clé privé, clé publique
consiste à signer avec ta clé privé (que tu cache dans ton code) et de
fournir à l'utilisateur (fisc dans notre cas) un clé "publique" qui
permet de vérifier si la signature est valide ou pas.

>Fred
Membre enregistré
5 messages
Posté le 19 août 2016 - 19:28
Je me sens moins seul à présent...
J'ai en effet commencé par créer des clefs privées et publiques avec l'utilitaire Puttygen
Je hash ma chaîne de caractères avec la fonction Hash de WinDev.

Puis j'avoue, je bloque sur le cryptage de mon Hash en méthode RSA 2048 ou Elliptic Curve.
J'ai bien trouvé une DLL, RSA.DLL, mais qui ne semble pas s'importer dans WinDev.
Autre piste il y a CryptoAPI de Windows, mais je ne trouve pas le moyen de l'implémenter...
>Help my friend.
Membre enregistré
2 574 messages
Popularité : +222 (260 votes)
Posté le 20 août 2016 - 07:52
Salut,

Y'a bien une solution, attendre la 22 y'aura forcement tout ce qu'il faut dedans...:p

Trêve de plaisanteries, il y a toujours la possibilités de développer une dll en .net pour l'importer dans le projet. Tu cryptes avec la clé publique et tu peux décrypter avec la clé privé.

Bon dev,

--
Cordialement,

Philippe SAINT-BERTIN
>Géode Informatique
Posté le 28 février 2018 - 18:08
Bonjour, j'ai une question concernant la clé privée. Vous proposez de la cacher dans le code. Est-ce vraiment inviolable ? Et lorsqu'on la trouve, ne peut-on pas recalculer tous les enregistrements depuis le début, tout en en supprimant quelques-uns ou en les modifiant, et pourtant avoir une base de données apparemment non modifiée puisque tous les enregistrements auront des hash corrects et la signature ?
Posté le 28 février 2018 - 18:10
Bonjour, j'ai une question concernant la clé privée. Vous proposez de la cacher dans le code. Est-ce vraiment inviolable ? Et lorsqu'on la trouve, ne peut-on pas recalculer tous les enregistrements depuis le début, tout en en supprimant quelques-uns ou en les modifiant, et pourtant avoir une base de données apparemment non modifiée puisque tous les enregistrements auront des hash corrects et la signature ?
Posté le 25 mars 2018 - 15:38
Bonjour,

Je suis en version 23, et voilà mon dilemme !!
Il Faut choisir entre "fichier inaltérable" et "enregistrement chaîné" !
Ou est-ce qu'un fichier inaltérable est déjà chaîné ??

Car un enregistrement chaîné est lié certes avec l'enregistrement précédent mais AUSSI avec l'enregistrement suivant.
Hors pour cela il faut MODIFIER l'enregistrement précédent afin d'ajouter la référence de la clef actuelle !!! Mais si le fichier est inaltérable ... pas de modification possible !!

Par contre un fichier géré avec un chaînage me paraît plus souple car on a encore la maîtrise (peut être délicat)
(même si on peut avec un peu de rigueur gérer une modification d'analyse d'un fichier inaltérable)

Une idée ?;(
>Merci, cordialement.