Bonjour,
Je recherche des informations sur les méthodes qui permettent, en système embarqué notamment, de s'assurer de l'authenticité du code exécuté par le processeur (càd de s'assurer que personne n'a modifié un programme sur le disque dur lorsque on l'exécute).
Je m'intéresse principalement aux solutions matérielles (mais également aux solutions logicielles).
On m'a parlé de composants qui, installés sur la carte mère d'un système, permettent de vérifier l'authenticité du code qui est exécuté sur le processeur. Mais personne n'a été capable de me donner une référence ou un fabricant de tels composants.
Je suppose que dans l'histoire il doit également y avoir des clés privées/publiques.
Bref, si quelqu'un peut me donner le moindre renseignement à ce sujet, ça m'intéresse car je n'ai pas trouvé grand chose.
Si vous connaissez également des noms de méthodes logicielles à cet effet, ça peut aussi m'intéresser.
Si vous connaissez des méthodes spécifiques à Linux, ça m'intéresse également :)
Je vous remercie d'avoir lu jusqu'ici ;)
A bientôt!
Forum Linux.embarqué Authentification de code exécutable
10
déc.
2009
# TPM, Trusted Computing
Posté par NeoX . Évalué à 2.
on appellait ca le Trusted Computing
=> certifier un OS puis demarrer cet OS
=> lancer une appli, la certifier => l'executer
il fallait que la fonction soit dispo dnas le bios (et forcement sur la carte mere)
et il me semble avoir lu un paragraphe la dessus pour le noyau 2.6.31 ou 32...
[^] # Re: TPM, Trusted Computing
Posté par bluelambda . Évalué à 1.
# elfsign/elfverify
Posté par Octabrain . Évalué à 3.
[^] # Re: elfsign/elfverify
Posté par bluelambda . Évalué à 1.
# question ?
Posté par bubar🦥 (site web personnel) . Évalué à 3.
J'avoue ne pas comprendre la question :
>de s'assurer de l'authenticité du code exécuté par le processeur
Pourquoi vouloir s'assurer de l'authenticité du code exécuté par le processeur ? A la limite je peux comprendre que cela vienne en toute dernière sécurité, tout au bout de la longue chaine de confiance. Mais voilà, j'avoue que je ne comprends pas trop : pourquoi vouloir vérifier cette authenticité au moment où le code va être exécuté par le processeur ?? Pourquoi ne pas, plutot et plus tôt, vérifier l'authenticité de ce que contient le système ? Du coup d'une part le champ des possibilités est plus vaste, et la consommation plus réduite. Par exemple des sommes de contrôle sur des binaires prog&biblios.
Consommation aussi parceque j'imagine que sur un système embarqué, la rapidité d'accès est souvent importante, alors s'il faut vérifier cette intégrité uniquement avant de charger tel ou tel bousin dans le proco ou dans la ram... forcément ça va 'blesser' ton système embarqué.
Moi j'aurai plutôt vu une chaine de validation complète, faite de différentes manières complémentaires, et faites avant.
Avec éventuellement en complément un process interne qui le vérifie de temps en temps, voire un couple tpm/watchdog en hard au côté du système, et en toute dernière étape, cette vérification avant exécution dont tu parles, si le binaire devant être exécuté vient d'une autre partie physique ou d'un autre embarqué, et transite sur un looong 'trajet' auquel on ne fait confiance... genre un lien ip/autre. Mais là encore c'est sur ce looong trajet que j'essairai de voir. Mais peut être que je me gourre complètement ?
[^] # Re: question ?
Posté par bluelambda . Évalué à 1.
De plus, les avantages (autres que la Tivoisation) peuvent être multiples, sans pour autant "blesser" les performances, si ce traitement est effectué par un composant HW dédié, ou en interne du processeur en vérifiant l'intégrité de la pile (certains processeurs sont faits pour supporter cette fonctionnalité visiblement).
Exemple dans le domaine des cartes à puce :
on ne veut pas que l'on puisse modifier facilement un programme exécuté par la carte, parce qu'on ne veut pas qu'un pirate puisse extraire de la carte des informations confidentielles. Or, il y a de nombreuses techniques "d'ingénierie inverse" qui permettent de modifier le code exécuté par la carte (que ce soit avant ou pendant l'exécution). Cette méthode permet d'ajouter une sécurité supplémentaire à ce niveau.
On peut aussi imaginer toute sorte de systèmes critiques où les programmes sont installés sur un disque dur et où on ne veut pas qu'une personne mal intentionné puisse modifier le comportement du système simplement en modifiant le contenu du disque dur.
Un exemple plus parlant est peut être situé au niveau des box Internet, qui sont, je le rappelle, la propriété des FAI qui les louent à l'utilisateur, l'utilisateur n'a donc pas le droit légalement de modifier le logiciel. Mais les FAI préfèrent s'assurer de façon technique que le logiciel ne sera pas modifié facilement. Il faut savoir qu'en modifiant le logiciel d'une box Internet, on peut parfois avoir accès à toutes les chaines TV payantes fournies par le FAI... sans les payer.
Bref, je fais aussi ces recherches pour comprendre comment est mise en œuvre la Tivoisation ;) bien que je sois plutôt contre cette pratique (mais c'est pas interdit de vouloir comprendre comment ça marche).
[^] # Re: question ?
Posté par bubar🦥 (site web personnel) . Évalué à 2.
La seule fois ou une puce de type tpm pourrait être vraiment efficace, c'est en étant autonome, ou lié à un autre composant matériel indépendant et à accès direct pour elle (tpm+cartes par exemple). Donc d'avoir, il me semble, une chaine matérielle complète dédiée à cela. Ce qui bien sûr inclue des firmwares, voir des micronoyaux ou des hyperviseurs. (et encore il semble aujourdhui de notoriété que même l'hyperviseur de la ps3 a été fumé, bien que aucun trucs 'pirates' ne semble circuler (ouf) ... quant à la téléphonie, faudrait se renseigner...)
Tout ces exemples, passionnants au demeurant, ont un arrière goût chez moi de "tpm c'est vachement ça permet de faire plein de rtucs sympas"... certes, mais ne peux t on pas les faire autrement d'une part, et surtout, que peut on faire en plus avec ça, hors du contrôle de l'usager et de nombeuses personnes. Bref l'informatique de confiance avec comme unique point d'entrée des solutions comme des tpm, ça me fait toujours froid dans le dos, même s'il est vrai que ça permet aussi de faire des trucs géniaux apparement. Mais bon rien n'emĉhe donc de remplacer les composants logiciels en charge de la gestion de ce matériel, que cela soit un driver dans le noyau, voire même une extraction de firmware, non ? Ce n'est qu'une question de temps et d'accès... Et cela relève 'juste' le niveau de compétences nécessaires pour réaliser la manipulation afin de contourner la protection.
Mettons : j'ai une machine très sensible car elle contient des données ultra-confidentielles ayant trait à des inventions industrielles. Dois je plus faire confiance à un fabricant de tpm, et ainsi laisser la machine 'as-it' parceque "aucun code malveillant ne sera exécuté dessus"... Ou plutôt dois je faire confiance aux contrôles des accès physique et (pas de) réseau à cette machine ? Je serai déssaideur pressé, je me presserai peut être pas autant que ça, sur ce coup. Le temps et l'accès...
Mais je le repète : je me gourre certainement complètement... Mais à priori je reste attaché aux contrôle d'accès physiques, au couple interne-externe, ainsi qu'au temps de validité de clefs.
J'espère que tu fera quelques comptes rendus de tes recherches ici, je te lirai certainement avec passion !
# Open Tripwire
Posté par xwt . Évalué à 1.
Et la je viens de voir qu'une version open source existe.
«Open Source Tripwire software is a security and data integrity tool useful for monitoring and alerting on specific file change(s) on a range of systems. The project is based on code originally contributed by Tripwire, Inc. in 2000. »
[http://sourceforge.net/projects/tripwire/]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.