Bonsoir mon journal,
Je viens de tomber sur une faille (possible) de l'open source dans un raisonnement se faisant dans ma tête il y a un bon quart d'heure ...
Imaginons un protocole X implémenté par un logiciel Y sur le principe du client/serveur ou du p2p.
Si le logiciel comme le client sont à source fermés, je peux
- définir un protocole obscur
- valider le code du logiciel donc
- valider les données qu'il échange sur le réseau.
Si le même logiciel est opensource et/ou le protocole ouvert, apparaîtront
- de nouveaux logiciels implémentant ce protocole
- des versions modifiées du logiciel, n'ayant pas forcément le même comportement.
Je me suis donc demandé s'il y avait une solution algorithmique de validation de logiciel "à distance" ? Avec un logiciel libre, cela me parait impossible.
Prenons un exemple (ça n'est pas le cas que je traite, mais il est proche ...) un jeu massivement multijoueurs, distribué (pas de serveur central) et libre (protocole et source ouvert).
Comment peut-on être sur que les joueurs ne modifient pas le logiciel pour que leur joueur triche et gagne ? Une validation des actions par les autres joueurs me parait très difficile, et une validation de code ou de protocole impossible vu que tout est opensource donc connu, donc trichable ...
Cruelle question ...
Tout en écrivant ce journal, je me demande d'ailleurs si ça n'est pas un des problèmes que les systèmes p2p n'arrivent pas à régler, (les clients p2p qui trichent et monopolisent la bande passante) y compris les propriétaires (ce qui rend ce problème tout aussi insolvable) comme kazaa
des avis d'expert dans la salle ?
Journal Faille de l'open-source ?
23
jan.
2005
# Comment être sur de ne pas tricher
Posté par plagiats . Évalué à 3.
Comment peut-on être sur que les joueurs ne modifient pas le logiciel pour que leur joueur triche et gagne ?
De la même manière que l'on crypte les mots de passe: Avec un hash "injectif" (genre MD5)...
J'ai bon?
[^] # Re: Comment être sur de ne pas tricher
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
NGBSC et TCPA proposent une solution a ce problème, mais il y a des effets de bord qui ne sont pour moi pas acceptables.
[^] # Re: Comment être sur de ne pas tricher
Posté par Sébastien Bonnefoy (site web personnel) . Évalué à 1.
[^] # Re: Comment être sur de ne pas tricher
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Non, il repose sur le fait que l'executable soit signé, et que la clé secrete qui l'a signé ne soit pas divulgée.
> c'est pas viable pour l'open source.
C'est clair : le principe est qu'une version modifiée n'a plus acces aux fonctionnalités "sécurisées", donc, par exemple, ne peut plus s'identifier comme client officiel dans un jeu multi-joueur. Bref, en pratique, ca empêcherait de faire des versions modifiées, ce qui est contraire au principe même de l'open-source.
[^] # Re: Comment être sur de ne pas tricher
Posté par Calim' Héros (site web personnel) . Évalué à 2.
Ca empeche juste ces versions de tourner sur des serveur "officiel". Mais rien ne t'empeche de faire de nouveau serveurs et de nouveaux clients, il ne pourront alors tournées que dans un "nouveau" reseau.
Cela peut même etre util pour eviter la surpopulation d'un "serveur" par rapport la surface virtuel du jeu.
De même la/les personnes phisiques ou morales gerent une instance du monde peuvent validers differents clients alternatifs. Le probleme reside surtout dans le fait que tu ne peut jouer avec un client compiler à la mano.
[^] # Re: Comment être sur de ne pas tricher
Posté par Hardy Damien . Évalué à 2.
Dam
[^] # Re: Comment être sur de ne pas tricher
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
# Je ne suis de loin pas un expert...
Posté par Jux (site web personnel) . Évalué à 7.
Prenons un FPS (First Person Shooter = quake 3, half-life). En gros, le client envoies ses déplacements et la direction de ses tirs. Tout cela passe par le serveur.
Une implémentation simple du serveur consisterais à simplement renvoyer aux autres clients les données reçues. Dans ce cas-là, on peut effectivement tricher facilement.
Maintenant, le serveur peut vérifier les données du client (il stock la position précédente du client et compare avec le déplacement envoyé par le client, si c'est au-delà de la vitesse limite, il réagit).
En prenant le problème dans l'autre sens, à savoir quelles infos le serveur envoie au client, si on prend un modèle simple dans lequel chaque client connait la position de tout les autres, alors on peut facilement faire des wallhacks (vision a travers les murs).
Ceci dit, le serveur peut, pour chaque client, n'envoyer que les positions des joueurs que ledit client voit.
Le seul problème, c'est que ça demande beaucoup de calcul côté serveur....
Maintenant pour le p2p, ou il n'y a pas de serveur central, pour éviter le monopole de bande passante:
Imaginons un client A qui est "gentil" et un client B qui tente de monopoliser la bande passante de A.(B aurait mis sa vitesse de download très haut et sa vitesse d'upload très bas)
Quand B demande à A de lui envoyer un fichier, A peut regarder à quelle vitesse il télécharge chez B et fixer une vitesse d'envoie maximum vers B en fonction de ça.
Voilà, je ne suis pas sûr d'avoir été très clair... et je peux très bien me tromper.
# Et ?
Posté par pifou . Évalué à 5.
En gros tu pronnes le "vaut mieux essayer de cacher les failles du système en fermant le code" plutôt que de chercher une méthode pour empécher efficacement toute triche de façon ouverte. Aux dernières nouvelles il existe des protocoles de cryptographie utilisant des algos connus (avec du code source libre), ce n'est pas pour autant qu'ils sont vulnérables !
Effectivement dans le cas de logiciel massivement réparti, le contrôle est plus dur à tenir ... mais toujours faisable en identifiant par exemple quelques "serveurs" comme "de confiances".
Je ne suis pas un spécialiste de la question, mais franchement je ne vois pas en quoi le fait d'avoir un logiciel libre puisse poser plus de problème qu'un logiciel propriétaire ! Ce n'est pour moi qu'une question (complexe) de choix d'architecture/algorithme.
Finalement je crois que mon post ne fait que reposer ta question:), mais au moins je renie le sujet et le début de ton journal sur la possible faille du modèle Open Source sur ce point là :). Comme tu le dis à la fin, ça n'ai pas un problème de code accessible ou non.
[^] # Re: Et ?
Posté par Benjamin (site web personnel) . Évalué à 1.
et bien ca m'embête bien, parce qu'au final, libre ou pas, j'ai pas trouvé de solution, si ce n'est avoir quelques serveurs "de confiance" ... pas glop hein ...
Sinon, je ne remet pas du tout en cause le modèle open source, bien au contraire ;)
[^] # Re: Et ?
Posté par Sixtiz (site web personnel) . Évalué à 2.
Pour en revenir au débat principal : le fait que les sources de Quake 3 ou d'autres jeux comme Counter Strike ne soient pas disponnibles n'empêche pas de voir fleurir des aimbots et autres cracks qui permettent de tricher, loin de là.
[^] # Re: Et ?
Posté par jeff110 . Évalué à 1.
Je me souviens encore des codes pour le minerais illimité dans starcraft...
Ceci dit, lorsqu'on jout avec des amis, on est là pour s'amuser; et si on triche, c'est pas marrant.
Donc on ne triche pas et c'est tout, meme si on en a la possibilité.
ça, c'est valable pour les jeus.
Par contre, c'est vrai que pour des applications plus critiques, ça peu être un probleme.
[^] # Re: Et ?
Posté par JoeBar . Évalué à 2.
> Je me souviens encore des codes pour le minerais illimité dans starcraft...
Euuuh c'est pas vraiment la même chose dont vous parlez ! Les codes dont tu parles ont été développés par les concepteurs du jeu, alors que l'auteur du journal se demande s'il est possible d'empecher que quelqu'un ne modifie un client pour tricher.
[^] # Re: Et ?
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 1.
Certaines légendes ont la peau dure...
ftp://ftp.idsoftware.com/idstuff/quake3/source/(...)
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Et ?
Posté par Larry Cow . Évalué à 3.
Avec le code source que tu nous proposes, tu ne pourras pas obtenir un binaire de quake3, tout au plus le binaire du "mod" par défaut.
Comme quoi, la peau dure des légendes, elle sert aussi à les protéger contre les petits malins ;)
# Triche
Posté par Mathieu Pillard (site web personnel) . Évalué à 7.
La reponse est simple: quand tu fais du code, tu dois admettre que le gars qui voudra tricher, il voit tout. Ya des trucs pour tricher pour chaque jeu proprio, et generalement quand une solution est fournie par l'editeur sous la forme de patch, les programmes de triche se mettent a jour dans les heures qui suivent. Ya aussi des tres bons papiers qui en parlent, et qui montrent bien que les tricheurs ont bien plus de ressources que l'ont ne croit...
Conclusion, quand on code, on se debrouille un maximum pour que, meme si un méchant aurait un acces au code, qu'il en ait vraiment un (dans le cas d'un projet open source donc) ou non, il ne peut faire qu'un minimum de choses. Ca passe par des verifications diverses et variées coté serveur par exemple - dans le cas d'un jeu solo, on s'en fiche un peu -.
# Précisions ...
Posté par Benjamin (site web personnel) . Évalué à 2.
... Bon, quelques précisions, parce que visiblement on parle surtout du thème des jeux :
L'idée que j'ai en tête ne serait pas un jeu, mais une sorte de moteur de recherche p2p. L'idée serait excellente si le groupe de développeur par exemple, pouvait valider les clients du réseau par quelque système que ce soit, (crypto, hash, protocole...) mais je ne trouve rien de satisfaisant, si ce n'est d'avoir des clients de confiance, donc peu de clients, ou de mettre en place un système de "points de confiance" qui pourrait donc tout aussi bien être falsifié, bref, je suis un peu perdu ...
Ou alors on part comme sur l'idée wiki : il y aura une magnitude de plus de bons clients que de mauvais, qui seront donc plus ou moins invisibles ...
# protocole ouvert != danger
Posté par Jean Roc Morreale . Évalué à 1.
La première source de triche sur ce type de jeu étant l'automatisation des taches et la seconde loin derrière étant le piratage du serveur directement. Un des moyens mis en oeuvre contre ces nuisances est une vérification de l'intégrité des fichiers au démarrage du jeu
Le principe reste le même pour les FPS où la triche se fait au niveau de l'affichage pas du protocole/serveur. Et ça, ça peut se faire sans même toucher au fichier du jeu (ex:aimbot,wallhack)
Pareil pour les logiciels de p2p, un client de leech basé sur emule peut bloquer tout upload mais ça sera à son détriment puisque les autres clients le note selon la participation qu'il a eu à leur égard. A moins de pouvoir forcer et trifouiller dans les clients des autres usagers, le leecheur finira vite par ne rien télécharger du tout.
# solution possible dans les jeux distribués
Posté par Monsieur Flynn . Évalué à 2.
exemple il n'y a pas de solution parfaite.
On peut juste trouver des solutions qui marchent presque tout le temps comme par exemple la validation se basant sur les probas.
Explication : Puisqu'il n'y a pas de serveurs, ce sont chaque client qui s'occupent de gérer une petite partie du monde. Il "suffit" alors que la même partie du monde soit gérée par plusieurs clients entrevérifiant leurs calculs .. On peut alors partir du principe que les résultats minoritaires seront alors des résultats faux.
On peut également partir sur des architectures mixtes, par exemple pour un mmorpg, un serveur central ne gardant que les carac des persos et validant leurs augmentation etc etc et les clients qui s'occuperaient de la gestion de petit bout de monde ( deplacement, combat, etc etc ). On peut alors penser que les parties gérées par des clients tricheurs seront rapidement désertées et dénoncées par les clients non tricheurs que l'on suppose plus nombreux.
Enfin on peut imaginer un principe "d'arbitrage". La encore ca necessite la mise en place d'un serveur arbitre. Lorsque qu'un client est connecté sur un autre client qui gere une partie de monde, le premier client vérifie épisodiquement les calculs du second, si il detecte un problème il envoit un rapport a l'arbitre.
Une autre facon d'utiliser le principe d'arbitrage est d'utiliser un serveur qui ne serait le point d'entrée vers la grille de client gérant le monde. Tout le traffic entre les clients joueurs et les clients
gestionnaires passerait par ce "routeur". De temps en temps, ce routeur arbitre, vérifieraient ce que font les clients gestionnaires.
Voila ce n'était que quelques idées jetées en vrac au petit matin.
Mais l'un des trucs qu'il ne faut pas oublier dans le cas d'une architecture répartie, c'est que si vous utilisez un arbitre central pour vérifier les calculs, la vérification étant au moins aussi couteuse que le calcul du "calcul à vérifier".... suivant le nombre de vos vérifications, l'architecture répartie perds tout son charme.
[^] # Re: solution possible dans les jeux distribués
Posté par Calim' Héros (site web personnel) . Évalué à 2.
Les differentes noeuds du serveurs devant assurées l'intégretité du "serveur" même si une partie de ces noeuds tombe (que se soit piratage ou simple extinction).
On peut donc imaginé que pour un groupement de N noeuds on ait un ou plusieurs serveur referents dont le status est assuré selon plusieurs critère comme :
- La personne qui a mis le noeud en place
- L'uptime du serveur
- La cooptation (i.e. se serveur n'a pas envoyer de fausses info, il est fiable, il passe en referent)
Il est donc bon de donner des niveau de "referent" un peut dans le meme genre des chaines de confiances des cle gpg.
Dans le cadre d'un mmorpg chaque serveur peut etre (auto)parametré (en fct des besoin) pour assurée le boulot de serveur pour une zone géographique.
Apres il faudrait que les actions des clients soient validées par 2+ noeuds de manieres a eviter la triche. Ces noeud verifiant la validité des actions. Le fait de rendre obligatoire la validation par plusieurs serveurs par exemaple en obtenant ainsi un certain score de confiance (i.e 1 noeud top confiance suffit mais il faut plusieurs noeud avec peut de confiance pour valider) permet d'eviter les clients qui tentents d'abuser et les serveurs frauduleux.
En effet si un client frauduleux agit, les actions ne seront pas validées.
Si elles sont validées par un serveur frauduleux, celui ci n'ayant que peut de confiance ne sera pas pris en compte, voire meme exclu en cas de trop grand nombre de tentative de fraude.
[^] # Re: solution possible dans les jeux distribués
Posté par Calim' Héros (site web personnel) . Évalué à 2.
Je presise aussi qu'un noeud ne se proclame pas referent de niveau N, mais qu'il est designé (élu) conne tel par les autres.
Il est a noter aussi qu'il faut prevoir un coté serveur et un coté client parce qu'il est fort probable que dans une archie distribué d'une structure mellant les deux (un pgm a la fois client et serveur) des parties clientes tiers apparaitront qui elles ne gereront pas le coté serveurs.
[^] # Re: solution possible dans les jeux distribués
Posté par Monsieur Flynn . Évalué à 2.
On pourrait même imaginer qu'avec un réseau suffisamment important de tricheurs, ce seront les non tricheurs qui seront considérés comme tricheurs et seront éjectés.
[^] # Re: solution possible dans les jeux distribués
Posté par Calim' Héros (site web personnel) . Évalué à 2.
D'ailleur c'est un coup a syndé automatiquement le jeux avec d'un coté les tricheurs et de l'autre les non tricheurs, la confiance des deux reseaux s'entre exluant. Le but etant de garder le taux de non confiance des exclus de maniere a les blacklisté.
# Il suffit de valider les données recues
Posté par Lucas . Évalué à 1.
Dans ton cas, un protocole fermé ne t'assure en rien que personne ne pourra tricher : il suffit de reverse-engineerer le proto pour pouvoir le faire. Donc tu es obligé, au niveau du serveur (s'il y en a un) ou de l'ensemble des pairs (si n'y a pas de serveur) de vérifier que les données par un client sont valides.
Dans le cas d'un réseau pair à pair, ça peut se faire avec des algos d'élection ou de consensus. Mais en général, ca fonctionne plutot en assurant une redondance des calculs (calculer la même chose sur plusieurs noeuds, et comparer les résultats). Certains réseaux à la BOINC/Seti et cie utilisent un système de notation de noeud : plus tu envoies des résultats justes, plus il te fait confiance, et moins il revérifie.
# C'est pas lié au libre
Posté par Yusei (Mastodon) . Évalué à 3.
Quoi qu'il en soit, ça se rapproche du problème qu'a eu le SETI@Home, puis les autres projets de calcul distribué. Ils ont opté pour la fermeture du code en prétendant que c'était pour s'assurer de la qualité des résultats, mais malgré tout, ils ont compris que la sécurité ne reposait pas sur l'obscurité, et ils ont choisi la seule véritable solution: faire les calculs plusieurs fois.
Dans le cas d'un jeu en P2P, tu peux faire en sorte qu'un joueur calcule une partie du jeu "éloignée" de lui, ce qui diminue son intention de fausser les résultats. En misant sur le fait que:
- il y a beaucoup de joueurs, donc il est difficile de rendre négligeable leur part de calcul avec de la force brute
- il est difficile de trouver qui calcule quoi
- tous les calculs sont fait plusieurs fois par des joueurs différents
On obtient un truc relativement sûr.
Maintenant si tu veux un système encore plus sûr, tu peux calculer la confiance que tu as en chaque joueur, qui dépend du nombre d'unités de calcul en "conflit" avec le résultat communément admis.
Solution parfaite ? Non, car sans serveur centralisé c'est très compliqué à mettre en place.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.