Pour conclure, oui il est certain que si tous les logiciels de caisse étaient verrouillés, avec probablement juste une poignée d'éditeurs de logiciels propriétaires autorisés, alors ce serait plus dur de frauder.
Mais pourquoi donc le logiciel propriétaire serait le seul à pouvoir être certifié via un audit?
D'après ce que j'en ai vu, la norme NF525 exige :
- Inaltérabilité : données figées, traçabilité des corrections
- Sécurisation : protection contre fraudes
- Conservation : au moins 6 ans pour transactions et clôtures
- Archivage : export sécurisé en format ouvert
Cela signifie qu'il faut assurer la traçabilité à minima du code source, de l'environnement de compilation et du binaire résultant. Et mieux, d'assurer aussi la traçabilité avec les spécifications et les tests. Et ça faut le faire même en auto-certification pour prouver que tu as fait ton possible pour qu'un pirate n'ait pas corrompu ton logiciel. On part du principe que tu n'es pas un margoulin et que tu ne développes pas un logiciel permettant de frauder.
Cela se met en œuvre par des mécanismes techniques comme des sommes de contrôle et des signatures cryptographiques pour sécuriser chaque enregistrement ainsi que le logiciel en lui-même. Et il faut le hardware qui va bien pour exécuter un tel code. Cela n'a donc rien à voir avec le fait que le code source soit propriétaire ou libre.
Moi si je suis éditeur de logiciel de caisse, j'engage ma responsabilité civile (en cas de malfaçon) et pénale (si je suis fraudeur) à fournir un logiciel antifraude. Je vais donc m'engager que sur les logiciels que je distribue (et donc que je vends) moi-même. Donc je génère un binaire avec une signature qui est unique pour chaque client. Et le client dispose d'un joli papier qui dit que son logiciel dont la signature est X.Y.Z est bien conforme à la norme NF525.
Si le client veut générer son propre logiciel, libre à lui, mais le sien n'aura pas la signature de mon binaire et à charge pour lui de prouver à l'administration fiscale que sa version est elle aussi conforme. Je lui souhaite bien du courage...
[^] # Re: Canard decevant
Posté par vpo . En réponse à la dépêche Le numéro 8 du Lama déchainé promeut la diversité. Évalué à 6.
Mais pourquoi donc le logiciel propriétaire serait le seul à pouvoir être certifié via un audit?
D'après ce que j'en ai vu, la norme NF525 exige :
- Inaltérabilité : données figées, traçabilité des corrections
- Sécurisation : protection contre fraudes
- Conservation : au moins 6 ans pour transactions et clôtures
- Archivage : export sécurisé en format ouvert
Cela signifie qu'il faut assurer la traçabilité à minima du code source, de l'environnement de compilation et du binaire résultant. Et mieux, d'assurer aussi la traçabilité avec les spécifications et les tests. Et ça faut le faire même en auto-certification pour prouver que tu as fait ton possible pour qu'un pirate n'ait pas corrompu ton logiciel. On part du principe que tu n'es pas un margoulin et que tu ne développes pas un logiciel permettant de frauder.
Cela se met en œuvre par des mécanismes techniques comme des sommes de contrôle et des signatures cryptographiques pour sécuriser chaque enregistrement ainsi que le logiciel en lui-même. Et il faut le hardware qui va bien pour exécuter un tel code. Cela n'a donc rien à voir avec le fait que le code source soit propriétaire ou libre.
Moi si je suis éditeur de logiciel de caisse, j'engage ma responsabilité civile (en cas de malfaçon) et pénale (si je suis fraudeur) à fournir un logiciel antifraude. Je vais donc m'engager que sur les logiciels que je distribue (et donc que je vends) moi-même. Donc je génère un binaire avec une signature qui est unique pour chaque client. Et le client dispose d'un joli papier qui dit que son logiciel dont la signature est X.Y.Z est bien conforme à la norme NF525.
Si le client veut générer son propre logiciel, libre à lui, mais le sien n'aura pas la signature de mon binaire et à charge pour lui de prouver à l'administration fiscale que sa version est elle aussi conforme. Je lui souhaite bien du courage...