Discussion :

[bombseb]

Bonjour,

Pour la mise aux normes de notre application de caisse, nous devons certifier notre application. Je ne comprend pas comment marchent les certificat...je vous laisse le texte ici :

Condition 2
Identification du logiciel :
Le logiciel du système de caisse doit être claireme
nt identifié par une version fixe ou une version
majeure selon les principes ci-dessous.
340
On entend par version majeure d'un logiciel ou syst
ème toute nouvelle version de ce système ou
logiciel obtenue en ayant modifié, dans la précéden
te version de ce logiciel ou système, un ou
plusieurs paramètres impactant le respect des condi
tions d'inaltérabilité, de sécurisation, de
conservation et d'archivage des données.
A l'inverse, on entend par version mineure toute ve
rsion de ce logiciel ou système obtenue sans que
les paramètres impactant le respect des conditions
précitées aient été modifiés par rapport à la
précédente version de ce logiciel ou système.
380
(pris pour référence pour les certifications)
Il sera admis que le certificat demeure valable pou
r attester du respect des conditions
d'inaltérabilité, de sécurisation, de conservation
et d'archivage des données par les versions
mineures ultérieures du logiciel ou système :
-
si ce certificat identifie clairement la racine de
la dernière version majeure à sa date
d'émission et les subdivisions de cette racine qui
sont ou seront utilisées pour l'identification
des versions mineures ultérieures ;
-
et si l'éditeur s'engage à n'utiliser ces subdivisi
ons que pour l'identification des versions
mineures ultérieures, à l'exclusion de toute versio
n majeure.
Notes spécifiques
1.
L'identification doit inclure les pilotes spécialem
ent programmés pour une tâche spécifique
impactant le respect des conditions d'inaltérabilit
é, de sécurisation, de conservation, et
d'archivage des données ainsi les pilotes de bas ni
veau (comme les pilotes vidéo, les pilotes
des disques, etc.) impactant le respect des conditi
ons d'inaltérabilité, de sécurisation, de
conservation, et d'archivage des données.
2.
Si les fonctions impactant le respect des condition
s d'inaltérabilité, de sécurisation, de
conservation, et d'archivage des données et les com
ptes associés sont protégées par une
configuration spécifique du système d’exploitation,
les fichiers de la configuration
considérée doivent avoir une identification additio
nnelle.
3.
L'identification du logiciel doit être aisément aff
ichable lors d’une vérification ou d’une
inspection (facilement signifie grâce à une interfa
ce utilisateur standard, sans outil
additionnel).
Référentiel système de caisse
Version 1.2
10
4.
Les identifications peuvent s’appliquer à différent
s niveaux, comme des programmes
complets, des modules, des fonctions, etc.
5.
Si les fonctions du logiciel peuvent être désactivé
es par des paramètres spécifiques, chaque
fonction ou variante doit être identifiée séparémen
t. Autrement, le progiciel entier devrait
être identifié dans son ensemble.
Documentation requise
La documentation doit établir la liste des identifi
cations du logiciel. Elle doit également expliquer
comment l'identification du logiciel est créée et c
omment elle est inextricablement liée au logiciel
lui-même. La documentation doit aussi préciser la m
anière dont on peut accéder à l'identification
sur l'écran et comment elle est structurée pour dif
férencier les changements de versions nécessitant
ou non un examen.
Les documents doivent indiquer les mesures prises p
our protéger l'identification du logiciel d'une
quelconque falsification.
Vérification à partir de la documentation
Examiner la documentation décrivant comment l’ident
ification du logiciel est générée et affichée.
Vérifier que tous les programmes possédant des fonc
tions ou des paramètres impactant le respect
des conditions d'inaltérabilité, de sécurisation, d
e conservation, et d'archivage des données sont
clairement identifiés et décrits afin que l'organis
me de certification et l'éditeur n'aient aucun dout
e
sur les fonctions dont la modification entraine un
passage en version majeure.
Vérifier que le fabricant a fourni une valeur nomin
ale de l'identification (numéro de version et
somme de contrôle fonctionnelle à indiquer dans le
rapport d'évaluation).
Vérification fonctionnelle
Vérifier que l'identification du logiciel est visua
lisée conformément à sa description dans la
documentation. Vérifier que l'identification présen
tée est correcte.
Vérifier que l'algorithme permettant de générer l’i
dentification a intégré toutes les parties logiciel
les
concernées. Vérifier que l'algorithme est utilisé c
orrectement.
Vérifier que les mesures prises pour éviter la fals
ification sont appropriées par rapport à l'état de
l'art.
Exemples de solutions acceptables
Exemples d'algorithmes à l'état de l'art pour réali
ser les empreintes des logiciels ou sous-parties de
s
logiciels dans un but d'identification précise : SH
A-2, SHA-3, Whirlpool, Blake.
Exemples d'algorithmes non considérés comme intrins
èquement robustes par le RGS de l'ANSSI
mais suffisants pour réaliser les empreintes des lo
giciels ou sous-parties des logiciels dans un but
d'identification précise : SHA-1, MD5.
Exemples d'algorithmes non acceptables : CRC16, CRC
32 et toutes autres formes de sommes de
contrôles non cryptographiques.
Les empreintes utilisées pour l'identification des
versions doivent idéalement être faites à partir du
binaire mais une empreinte faite à partir du code s
ource est également acceptable. L'empreinte
peut être stockée à côté du code source.
Modalités de réalisation des vérifications de robus
tesse
Accès au code source de plusieurs versions mineures
successives.
Accès au journal des versions ("changelog").
Vérification de la robustesse
Vérifier que les algorithmes employés pour l'identi
fication précise des logiciels ou sous-parties des
logiciels sont suffisamment robustes, c’est-à-dire
qu'ils suivent les critères de l'annexe B1 du RGS o
u,
a minima, qu'ils sont résistants à une attaque par
seconde pré-image (i.e. étant donné une
empreinte cible, il ne doit pas être possible de fo
rger des données qui produisent une telle
empreinte).
Référentiel système de caisse
Version 1.2
11
Vérifier au travers d'une analyse de plusieurs code
s sources de versions mineures successives que
les modifications réalisées n'impactent pas le resp
ect des conditions d'inaltérabilité, de sécurisatio
n,
de conservation et d'archivage des données.
Vérifier que les subdivisions employées pour l'iden
tification des versions mineures sont bien
respectées sur un échantillon de versions successiv
es

Est-ce que quelqu'un connait ce genre de truc ?
Apparemment on peut générer des certificats directement dans visual studio ? J'ai vu qu'on peut passer par des organismes comme Verisign mais c'est payant...

Bref je patauge, si quelqu'un pouvait m'éclairer ca super cool...

[Arsiezis]

Bonjour,

Rien à voir avec des certificats à générer par l'application.

Dans le cadre de la lutte contre la fraude à la TVA, à partir du 1er janvier 2018 tout logiciel de caisse devra être certifié par un organisme accrédité. Actuellement seuls 2 organismes ont la possibilité de certifier ton application; infocert via la norme NF525 et le LNE.

Il y a un cahier des charges à respecter, des documents à fournir et un audit de ton code par une de ces organisations sera nécessaire. Et bien entendu ils ne font pas ça gratuitement

En dehors de la certification il reste la possibilité à l'éditeur du logiciel de fournir une attestation nominative indiquant que son application est conforme à la législation en vigueur (respectant les conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données, etc...)

Pour plus de détails je t'invite à aller voir les liens suivants et les sites de la NF525 et du LNE;

https://www.service-public.fr/profes...ualites/A10279
https://www.economie.gouv.fr/entrepr...e-janvier-2018

Bon courage !

[bombseb]

Merci,

Oui justement le texte que j'ai collé provient du site du LNE....