Julien a écrit 8 commentaires

ça se discute. Dans mon cas, le signeur récupère ses clés via PKCS#12. Il n'y a pas de carte à puce.

C'est pas du RGS ** ni RGS *** du coup.
Moi je suis concerné par du RGS **

Quant au RGS *, certes il n'est pas matériel, mais je crois que les clés doivent rester en possession des utilisateurs et ne pas être accessible à 'autre y compris admin sys.
Je sais que c'est très théorique, on sait que les RGS ** et *** sont très souvent dans le tiroir des secrétaires… (ce qui est encouragé implicitement au vue du bazar que c'est, je connais un élu qui avait 5 clés différentes, mais c'est encore un autre aspect discutable du RGS).

Quant à avoir la clé privée sur le serveur, s'il est mis en place un mécanisme robuste pour empêcher l'accès à la clé privée à une personne non autorisée, et si le système est certifié, je ne vois pas le problème.

Certifié ?
Sans doute pas certifié RGS, n'est ce pas ?

Pour ma part, le serveur de signature est utilisé uniquement depuis une application via une API, et n'est accessible, au niveau réseau, que par le serveur hébergeant l'appli (réseau dédié).
Donc pour accéder au serveur de signature, il faudrait avoir eu un accès au serveur applicatif. Je considère que c'est équivalent niveau sécurité, voire meilleure, que les solutions de signature via un client java pour navigateur qui fait la signature sur le poste du signeur.

C'est peut-être aussi fiable, peut-être plus.
Mais est-ce RGS ?

vu que le journal parlait à la base des logiciels libres dans le carde du RGS, je parlais du point de vue technique. Tout le reste, c'est de la procédure à mettre en place en interne. C'est compliqué mais c'est possible avec du libre.

Pour l'instant, malgré mes efforts, je n'arrive pas à le faire convenablement avec du libre.
Coté signature, nous utilisons i-parapheur qui est libre, excepté oracle (pour java).

Coté lecteur PDF (pour PAdES) par contre, c'est un échec, même avec mupdf.
De plus c'est pour avoir un outils afin que les utilisateurs finaux puissent vérifier les signatures, graphique tout ça tout ça).

Coté CAdES, pas mieux. Un document signé avec l'outil d'un éditeur n'est pas vérifiable avec l'outil d'un autre éditeur…

Et du coup, qu'est ce que tu veux que l'on te dise, exactement ?
La compatibilité avec le RGS passe par une certification variable sur une base d'exigences. A priori, il n'y a pas de solutions libres avec le tampon kivabien.

En fait, je m'étonnais justement du faible nombre de trace vis à vis de RGS dans le monde du libre.
Le RGS c'est à la base de la sécurité, et le libre est souvent en avance sur la sécurité (notamment le chiffrement, du fait de la difficulté d'avoir un code qui est exempt d'exploit). Et en fait, ben tout RGS est basé sur oracle, et ça semble ne gêner que moi.

Ben en l'espèce, ça ne semble pas être un problème de RGS, mais plus un problème de sécu opérationnelle.

Le fonctionnement de RGS encourage des comportements dangereux, alors qu'il devrait les décourager. Du coup in fine, quand il y aura contestation judiciaire (parce qu'il s'agit bien de cela, le RGS est là pour apporter une preuve) ça sera compliqué.
Mais ça sort du domaine du libre :)

Merci pour le lien, je regarderai.

Ce devrait permettre l'authentification.

Pour la signature, c'est une autre histoire

Un "token de signature matériel", un SmartCard, un key card reader sont vraisemblablement la même chose.
Et je ne les choisi pas, puisqu'ils sont fournis avec la SIM déjà dedans. Et d'après le fournisseur, faut pas toucher.
Néanmoins les tout dernier que nous avons eut sont de marque Gemalto et réponde à cette description :
Bus 001 Device 036: ID 08e6:3438 Gemplus GemPC Key SmartCard Reader.

Je ne connaissais pas mupdf, mais pour l'instant je n'ai pas réussi à lui faire afficher une signature "RGS".

J'ai créé ce journal pour aborder l'aspect open-source des implémentations.
Je peux bien évidement parler de tout plein de chose autour du RGS, j'en bouffe depuis + de 3 ans. ;)

Je vais donner une petite anecdote de ce qui ce passe ici (et pas qu'ici) :
Pour vérifier certaine signature d'ordre de payement effectuer à la DGFiP (les impôt donc), cette dernière demande parfois des "captures d'écran" du logiciel de gestion financière qui affiche "signé par …".
Alors pardonnez moi du peu. je crains que les garanties n'engages que ceux qui y croient !

Et du coup, croyez moi ou pas, mais je suis convaincu que le RGS présente d'énorme problème de sécurité.
Et que tôt ou tard des experts judiciaires et magistrats vont s'arracher quelques cheveux pour démontrer qu'un document a été ou pas falsifié.

Le RGS se classe en 3 niveaux, souvent désignés par des étoiles.
le 1 étoile est un certificat x509 presque classique.
les 2 et 3 étoiles sont des tokens de signature matériel.

Avec les tokens de signature commence un vaste bazar d'incompatibilité. Ils sont vendus avec leur driver (et/ou middleware, peut importe le nom) qui ne sont pas compatible entre eux (ni compatible linux). Leur carte SIM ne sont pas reconnues avec d'autre token, etc.

Donc ce n'est pas dans les documents du RGS, mais c'est dans les fait vue que justement le RGS n'impose justement pas d'interopérabilité.

Une fois le problème de token mis de coté, nous en arrivons à l'utilisation.
Le RGS peut servir à l'authentifier, et à signer.
La signature d'un document s'avère des plus surprenante. Je n'ai rien trouvé qui soit libre, du moins libre au sens ou je l'entend.
Il existe certes un produit : "i-parapheur" qui est libre, édité par Adullact : I-parapheur.
Mais il a besoin comme tous les autres de java, et uniquement la version Oracle de java. Si j'ai bien compris c'est parce que ces logiciels exploitent tous les fonction de crypto non-libre de java !

Et après se pose la question de la vérification d'une signature.
Les PDF peuvent être signé au format PAdES, sympa comme idée. Reste plus qu'a trouvé un lecteur PDF capable d'en lire la(es) signature(s).
Idem pour les autres formats.

Si, ce devrait être "et", mais je ne sais pas modifier le titre :(
Merci de ta remarque