Declaration des revenus par Internet

On Tue, 5 Apr 2005, Laurent Blume wrote:

Je ne peux pas remonter ces infos, mais je sais que ça ne sert à rien,
tout sera changé pour la prochaine campagne.

Bonne chose, parce que ce matin, derechef, l'authentification de mon proxy ne
passe plus. Étrange, un coup oui, un coup non.

Ils l'ont bien dit aux infos, ils sont ras la gueule. En fait, les années
précédentes, les prévisions étaient correctes, mais cette année ça a
explosé.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----

Tu peux être plus claire ?
il veut te sauter patate !

-+-in: GNU - Les patates se sautent, les téléphones sans fils -+-

Cedric Blancher wrote:

Amha, une signature électronique ne peut pas avoir plus de poids qu'une
signature manuelle, ne serait-ce que parce que sa valeur est limitée à
la durée de vie de clé qui l'a générée. Si on ajoute à cela toutes
les questions concernant la sécurité de l'environnement informatique,
ça devient vite très chaud.

Tous les lecteurs de FCS s'accorderont sur ce point. Mais pour
les non-spécialistes, une signature crypto finira probablement
par avoir plus de poids qu'une analyse graphologique. Idem pour
la saisie du code PIN d'une carte bancaire, la biométrie
(pourtant, dans le genre authentification rejouable, on ne fait
pas pire) et les comparaisons d'ADN.

Quand le PC de Mme Michu tournera sous TCPA et que sa clé sera
stockée sur une carte à puce délivrée par l'administration, elle
aura du mal à prouver sa bonne foi. On lui demandera de livrer
son disque dur et toutes ses données personnelles et d'attendre
qu'un expert décide si sa clé privée a pu être utilisée à l'insu
de son plein gré ou non.

C'est pourquoi il est aussi important de former les gens
à la sécurité que de les habituer à installer des applets
(même signées), à protéger des clés par des mots de passe
courts, et à cliquer "je signe ma déclaration" sans se
demander ce qu'ils signent exactement.

Certes, la FAQ de la DGI est remarquablement détaillée sur
les notions de crypto asymétrique, mais le paragraphe sur la
non-répudiation insiste un peu trop à mon goût sur ce qui
rassure (intégrité et horodatage), et fait rimer "authenticité"
avec authentification ("carte d'identité électronique") alors
que la non-répudiation, c'est plus que ça.

http://static.ir.dgi.minefi.gouv.fr/public/faq/site/aQuoiSert.html#p14

AC

Quelle serait la sécurité apportée par un applicatif externe, non signé?
On met de côté la lourdeur de l'utilisation (utilisation d'un autre
programme pour ça, copier/coller d'un charabia long comme le bras), ainsi
que les limites en terme de développement: pas certain que quelqu'un
penserait à en faire une version pour Linux sur Sparc64, ou OpenBSD sur
MIPS, par exemple...

En meme temps je suis pas sur que Mr Sun il ai pense a toutes les
versions pour sa JVM ;-)

Damien

Le Tue, 05 Apr 2005 12:24:35 +0000, Erwann ABALEA a écrit :

que l'administration n'en possède pas la clé publique.
Non.

s/publique/privée

La clé publique ne sert évidemment à rien à l'administration pour
générer une déclaration signée ;) De même, ils doivent forcément
avoir la clé publique, pour vérifier la signature d'une déclaration...

J'allais dire: "et les études des flux ne le montrent pas", mais tout est
en SSL. Je sais ce qui est envoyé, mais je ne peux rien en dire. Je peux
simplement dire, avec le peu de valeur que ça peut avoir, que tout est
fait proprement, dans les règles de l'art.

Des gens (compétents) ont étudié l'applet et sont arrivés à cette
conclusion. Par contre, je ne crois pas qu'il y ait eu publication de tels
études (en tout cas, je n'en connais pas).


--
Il faudrait créer fr.smic.* pour les discussions pas chères.
Avec fr.smic.arts.* en dessous.
-+- MB in: Guide du Cabaliste Usenet - La Cabale brade -+-

Bonjour.

"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de news:
Pine.LNX.4.58.0504051017110.11397@shining.seclogd.org...

Bonjour,

On Tue, 4 Apr 2005, Patrick 'Zener' Brunet wrote:

"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de news:
Pine.LNX.4.58.0504041636020.21140@shining.seclogd.org...
[...]

Pour résumer mon point de vue, un navigateur Web n'est pas supposé
accéder

ni en lecture ni (encore moins) en écriture, à une quelconque donnée de
la

machine cliente (sauf éventuellement des données à lui qui viennent du
Web

et sont susceptibles d'y retourner en respectant normalement certaines
conditions - ie les cookies).

Tu exclues donc les clés privées et les certificats? Ca va être coton pour
Mme Michu.

J'ai peut-être lésiné sur l'énumération complète... Mea culpa, dixit Sandra
(la chanteuse).

Ce que je veux dire, c'est que normalement, en aucune manière le serveur,
via la page web (assimilable à un programme par ses contenus divers) qu'il a
injectée dans le navigateur local, ne doit être en mesure d'accéder à des
données locales qui ne soient pas issues du Web (mon annuaire ou ma compta
par exemple).
Sinon le navigateur constitue une fenêtre par laquelle n'importe qui depuis
la rue peut prendre ou déposer ce qu'il veut dans votre logis et ceci à
votre insu (les techniques sont connues).

Même dans le cas présent, in real life, c'est vous qui faites une
déclaration au Fisc, ce n'est pas l'agent du fisc qui vient fouiller et
choisir dans vos archives. Or par le Web c'est exactement ce qui deviendrait
virtuellement possible.

Et par ailleurs comme la sécurité attachée à cet accès éventuel ne
reposerait que sur la probité et le devoir de réserve ... d'une
administration énorme avec un grand turn-over et d'innombrables prestataires
etc., on imagine les dérives techniquement possibles. D'ailleurs l'actualité
récente a soulevé une affaire de fuite (?) de dossiers... ce n'est qu'une
question d'enjeu.

Donc je pars du principe que toute donnée devant résulter en un fichier
durable (hors-session) doit être mise en oeuvre de manière volontaire et
consciente par l'utilisateur. D'où la procédure qui consisterait à :

La saisie d'un mot de passe, et le cochage des cases expliquant qu'il
s'engage à blablabla, c'est pas assez volontaire?

Si on peut être absolument certain qu'il y a identité absolue entre le
blablabla et ce que fait effectivement le code de la page, oui. Mais en
pratique ça n'est jamais le cas (un exemple que j'ai cité est la procédure
de "paiement unique" qui conduit à l'obligation de signer une autorisation
de prélèvement illimitée).

- importer par téléchargement "manuel" un fichier "certificat du client"
construit sur mesure par le serveur durant une première session
sécurisée,

C'est ce que fait l'applet Java. Elle génère une clé privée, envoit au
serveur une requête PKCS#10 et des infos d'identification, et reçoit un
certificat. Ce que tu souhaites, c'est que l'application qui fait ce
travail soit séparée du navigateur? Donc avec encore plus de manipulations
pour l'utilisateur?

La transaction doit rester en ligne, ce n'est pas gênant puisque la fenêtre
du navigateur est une extension at home du serveur. Par contre
l'implantation locale du résultat (le fichier ou la donnée "certificat")
doit être "volontaire" (cf infra). Cela dit cette procédure n'est pas
forcément complexe : télécharger un fichier ou copier-coller une chaîne de
texte...
Cela dit, dans ce sens c'est pas ***trop*** dangereux (par usurpation il
pourrait seulement y avoir en fait implantation non annoncée d'un trojan ou
autre saloperie), c'est dans l'autre sens que ça le devient.

- faire sa saisie de déclaration dans le cadre d'une session sécurisée,
à

l'intérieur de laquelle on peut de même à la fin récupérer par
téléchargement un fichier récapitulatif de la saisie,

C'est le cas, sauf pour le récapitulatif, mais tu peux consulter ton
dossier fiscal en ligne, donc ça revient à peu près au même...

- importer au préalable par téléchargement un module exécutable adapté
au

système, et capable de fusionner le certificat, le récapitualtif, la
date,

etc., et de générer avec tout ça un pattern textuel avec checksum et
tout,

que l'utilisateur pourrait copier et coller dans un champ de formulaire
de

la session sécurisée, ou alternativement on pourrait passer par un
fichier à

uploader sur le serveur.

C'est ce que fait l'applet Java. Elle prépare un ensemble de documents
XML, demande à l'utilisateur le mot de passe de sa clé privée, et effectue
2 signatures:
- une pour un contrat moral
- une pour le formulaire proprement-dit
Tout ça est fait proprement, ce sont des messages PKCS#7 signés, et c'est
envoyé au serveur.

Quelle serait la sécurité apportée par un applicatif externe, non signé?
On met de côté la lourdeur de l'utilisation (utilisation d'un autre
programme pour ça, copier/coller d'un charabia long comme le bras), ainsi
que les limites en terme de développement: pas certain que quelqu'un
penserait à en faire une version pour Linux sur Sparc64, ou OpenBSD sur
MIPS, par exemple...

Ca c'est un problème de déploiement classique (cela dit, j'ignore si les
plates-formes en question sont répandues dans le grand public et si leurs
détenteurs seraient alors rompus ou pas à la recompilation). Il y a des
travaux en cours visant la portabilité automatique du code sans autoriser sa
modification. C'est en soi un enjeu industriel reconnu. D'ailleurs Java
répond à cet objectif, le problème se reporte sur la disponibilité de la JVM
pour ladite plate-forme.
Mais ce n'est pas le noeud du problème : cf infra.

Il me semble qu'en procédant ainsi, on peut obtenir la même qualité de
signature qu'avec la méthode actuelle, mais sans utiliser des solution
d'accès aux fichiers de données par le navigateur, ce qui constitue le
problème technique majeur dont la solution actuelle relève du "hack
légitime".

Ca n'est pas la navigateur qui accède aux fichiers, c'est la machine
virtuelle Java. Tu proposes de remplacer ça par un binaire spécifique à ta
machine, sans signature.

La JVM bosse pour le navigateur, donc pour la page Web et donc pour le
serveur, ce n'est qu'un problème de délégation.

L'avantage d'un programme lancé manuellement (ce que je signifie par
"volontairement") et produisant un résultat "uploadé" tout aussi
volontairement,
... même s'il est aussi écrit en Java,
... c'est que matériellement il ne ***pourra pas*** se lancer autrement ni
voir son fonctionnement "mis à jour" en douce, même si les meilleurs hackers
du monde prennent une nuit le contrôle du www.fisc.fr,
... et qu'un utilisateur compétent et soupçonneux (il y en aura bien un)
peut le passer au debugger pour vérifier que pendant tout le temps où il
fonctionne, il ne touche à rien d'autre qu'aux deux fichiers prévus, et
faire un scandale dans la presse dans le cas contraire.
Donc si ensuite le programme en question est téléchargé uniquement depuis
une source identifiée, qu'on en vérifie le MD5, etc., cette solution fait
bien sauter **sans risque** la nécessité pour le contenu de la page de
devoir accéder automatiquement aux données locales.

Donc cette impossibilité matérielle d'agir imposée au navigateur et à tous
ses composants constituerait si elle était réalisée une garantie presque
absolue d'immunité aux "exports illicites d'information" pour le client,
quoi qu'il puisse se passer n'importe où sur le Web.
Il est vrai que lorsque le système (le plus répandu) est fortement soupçonné
d'intégrer lui-même des spywares et un firewall conçu pour être sélectif en
conséquence, cette sensation de sécurité a du plomb dans l'aile...

Mais donc ce point de vue "anti-intrusionniste" est tout à fait dans le
sujet de ce newsgroup, non ?
Je suis fondamentalement un technicien, et donc j'ai ma version sécuritaire
de la loi de Finnagle (je n'irai pas jusqu'à l'extension de Murphy) :
"Si c'est techniquement possible, alors il n'existe pas de garantie que cela
ne puisse pas être mis en oeuvre".
Donc le seul moyen d'être sûr que le navigateur n'exportera jamais de
données locales de lui-même (donc sans qu'on les colle à la main dans un
champ d'une page Web, ou uploade manuellement un fichier), c'est de lui
amputer cette fonctionnalité d'accès ainsi que la capacité de s'en doter par
une extension quelconque.

C'est une question de choix : sécurité ou compromis de sécurité ?

Cordialement,

--

/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

Erwann ABALEA wrote:

Ils l'ont bien dit aux infos, ils sont ras la gueule. En fait, les années
précédentes, les prévisions étaient correctes, mais cette année ça a
explosé.

Non, non, ce n'est pas un problème de surcharge (il y a ça aussi, mais pas là):
en fait, j'ai fait un petit coup d'ethereal, et il apparaît que les en-tête HTTP
envoyés au proxy sont incorrects.
Si je mets "utiliser la configuration du navigateur", il n'envoie pas
l'authentification, et essaie ensuite de se connecter en direct (sans passer par
le proxy).
Si je mets une configuration manuelle, il envoie bien l'authentification, mais
sans mettre le type d'authentification ("Basic") avant le login/mot de passe
encodé, et le proxy refuse, logique.
Donc, j'ai ouvert ce serveur dans le FW, et ça passe.
Mais je suis persuadé que hier, cela a fonctionné sans ça (jusqu'au moment de
signer, où la il y a eu échec apparemment lié à la surcharge).

Il faudrait que je regarde les logs, tout ça, mais bon, pour l'instant,
j'aimerais bien réussir juste à la signer, cette déclaration :-)

Laurent

On Tue, 5 Apr 2005, A. Caspis wrote:

Erwann ABALEA wrote:

Outre le fait que le HTML n'est pas la meilleure forme pour stocker des
informations manipulées par une machine, quelle est réellement ta
question?

La console Java suggère que j'ai signé numériquement non
seulement ma déclaration, mais aussi le contrat d'utilisation
du service de télédéclaration, qui est justement en HTML

Kestensais que c'est du HTML? Tu vois juste un début de balise XML au
début, et tu n'as pas de DTD, ni de specs, donc tu ne sais pas que c'est
du HTML... ;)

| formToSign <?xml version="1.0" encoding="ISO-8859-1"?>
| <FORM_XML VALUE=CONTRAT>
| <html><head><title>Contrat d'adhesion</title>
| <meta http-equiv="Content-Type" content="text/html;
| charset=iso-8859-1">
| <link rel="stylesheet" href="/css/teleIR.css">
| </head>
| [...]

[...]

Si tu décides de signer ça, tu t'engages sur des c*nneries, et
tant pis pour toi. [...]

Sur le moment je n'étais pas conscient d'avoir signé
numériquement ce contrat d'utilisation. Et vous ?

Honnètement, non. Mais je n'ai pas vérifié ma déclaration papier, et il
me semble qu'il y a un laïus sur mon engagement que tout est vrai, que je
n'ai pas triché, et toussa. Pareil qu'ici, donc.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Alcotest> OUi, mais aussi pour la création des 2 autres ducon,
Expliquez moi, pourquoi voulez vous créer deux autres ducon ?
Vous vous sentez seul ?
-+- FF in Guide du Neuneu sur Usenet - Les deux font l'impair -+-

On Tue, 5 Apr 2005, Tzim [MVS] wrote:

Client au sens humain, pas au sens navigateur. On délivre un certificat
pour un usager. On a plusieurs solutions pour ça:
- type DGI: des infos d'un niveau de confidentialité variable sont
envoyées à l'usager, et sont stockées sur les serveurs de la DGI. Une
comparaison est effectuée quand l'usager veut un certificat,

Je pense qu'une grosse partie du probleme viens de là...
Quelle est la valeur d'une signature électronique dont on a pas la certitude
que le certificat et sa clé privée sont bien uniquement en la possession de
la personne physique (et morale) ?

Cette valeur est bien déterminée. Elle est moindre que la valeur d'une
signature dite "sécurisée", avec un certificat dit "qualifié", mais elle a
une valeur certaine, en droit (va falloir que j'aille voir ma juriste
préférée pour avoir plus d'infos, j'ai bien lu des choses à ce sujet,
mais c'est pas extrèmement clair).

J'entends par là deux problèmes :
- Qu'est-ce qui empeche une tierce personne de générer un certificat a mon
nom ?

Qu'est-ce qui empêche cette même tierce personne de signer en ton nom, en
imitant ta signature?

- Qu'est-ce qui empeche une tierce personne de me voler mon certificat sur
mon poste informatique (bon, je suis parano, ca peux être difficile, mais
sur une machine d'utilisateur lambda...) ?

Même question.

Pour moi, le certificat tel qu'il est généré n'a que peux de valeur... voire
même moins de valeur qu'une signature manuscrite.
On peut imiter ma signature, mais ca reste une imitation, on ne me volera
pas ma main pour signer a ma place...

Mais ta main, rassure moi, tu la gardes? Parce que ce que tu laisses sur
ta déclaration papier, c'est juste une signature effectuée avec ta main.
S'il y a litige, ça se fera devant un tribunal, et accroche toi pour
prouver que tu n'as pas signé ta déclaration.

En ce sens, je pense que l'approche belge de la carte d'identitée
electronique est une avancée. La clé privée ne sortant pas de la carte, on
peux avancer que le signataire est bien en possession de sa propre carte...
en cas de perte ou de vol, le certificat est révoqué.. rendant les
signatures effectuées après la date du vol ou de la perte invalides.

Exact. On appelle ça un certificat qualifié. Ca n'est pas une invention
belge, c'est le résultat d'une étude européenne, et ça viendra chez nous,
en son temps. Il y a même une RFC à ce sujet (RFC3739), et des documents
de l'ETSI (j'ai oublié la référence).

Après, il reste quand même le problème de la diffusion initiale de cette
carte. Il faut qu'elle ne contienne aucune clé quand on la remet au
destinataire légitime, et qu'on puisse l'authentifier quand même pour
qu'il obtienne un certificat. Ca peut se faire en Mairie, à l'Etat Civil
par exemple. Mais si le certificat est déjà dans la carte quand le porteur
la reçoit, ça ne vaut pas mieux qu'une clé soft.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
RR> Ce que je cherche à démontrer, c'est qu'il est injuste de faire
RR> l'amalgame entre du bulk mail et du courrier non-solicité très ciblé
un suppositoire non reclamé, meme tres bien ciblé, reste un suppositoire.
-+-OS in : Guide du Neuneu d'Usenet - Plein le cul de la pub à neuneu -+-

On Tue, 5 Apr 2005, damien gautherin wrote:

Quelle serait la sécurité apportée par un applicatif externe, non signé?
On met de côté la lourdeur de l'utilisation (utilisation d'un autre
programme pour ça, copier/coller d'un charabia long comme le bras), ainsi
que les limites en terme de développement: pas certain que quelqu'un
penserait à en faire une version pour Linux sur Sparc64, ou OpenBSD sur
MIPS, par exemple...

En meme temps je suis pas sur que Mr Sun il ai pense a toutes les
versions pour sa JVM ;-)

J'ai une Sparc64 sous Linux (noyo 2.6), et j'ai bien une JVM. Bon,
d'accord, elle ne me permet pas d'utiliser le service de la DGI, mais
quand même. Il ne doit pas manquer grand chose, j'ai un plantage sauvage,
avec des messages d'erreurs inintéressants.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
"RECHERCHONS HOMMES" présentant peau sensible utilisant déodorant sans
alcool, pour tester produits cosmétiques, rémunération en fin d'essai.
-+- in Guide du Neuneu d'Usenet-Halte à l'expérimentation neuneutale -+-

Eric PETIT a écrit le Lundi 04 Avril 2005 16:27 :

Et d'autre part bien
qu'ayant mené une procédure à priori au bout je n'ai RIEN qui me permette
de penser que cela s'est passé correctemment (je suis méfiant car je l'ai
fait sous Firefox), ni une page l'indiquant comme réussie à la fin (ça a
boucle sur la page pour rentrer dans la déclaration) ni un mail pour
confirmer le tout.

Tu peux retourner sur le site consulter ton dossier fiscal qui contient ta
déclaration.

@+
--
Jules BEGINPOURAILE (signature aléatoire)
Deux gars :
- Moi, ma femme c'est un ange !
- Tu es bien chanceux, la mienne est toujours en vie !