Bon, c'est bien "joli" tout ça, mais
Est-ce que le fait que les binaires soient signés empêchent qu'il y ait des erreurs de programmation dans le programme qui est exécuté ?
Non.
Est-ce que le programme signé en cours d'exécution a les même droits que d'habitude ?
Oui. (au moins pour le moment, mais ça va durer encore plus longtemps)
Conclusion : il n'y aura pas moins de failles qu'avant, et elles ne seront pas moins exploitables (je pense aux virus).
C'est là-dessus qu'on peut communiquer : Trusted ou pas, le programme exécuté n'a aucune raison d'avoir moins de failles. Ça ne protège donc de rien face aux attaques "grand public/entreprise" par rapport aux technologies existantes (protection de pile, bit d'exécution (vieux comme l'informatique ou presque quoiqu'on puisse en penser)).
Pire, ça laisse encore plus à la merci de l'éditeur pour ce qui est de la correction de la faille ;-) À l'heure où le logiciel libre gagne du terrain par l'importance du côté standardisé et ouvert, ça tombe mal. Sans compter l'évolution constante vers les services en lignes, et la mobilité d'un même utilisateur entre plusieurs machines.
Par contre ça peut très bien servir aux DRM évidemment.
Vous avez déjà vu un algorithme cryptographique symétrique dont la clef est confiée à celui en qui on n'a pas confiance ?
Oui. Deux fois : DRM (mais tant que ça se passe en mémoire -> poubelle) et téléphone portable (GSM = chiffrement symétrique. En plus il n'y a qu'une seule clef "d'authentification"). Mais dans ce denier cas elle est dans la carte SIM où se font toutes les opérations cryptographiques évidemment.
Rappelez-vous d'Intel et son Processor-ID sur les Pentium-!!!, ça avait fait du bruit et la chose avait disparu...
# Information.
Posté par khivapia . En réponse au journal TCPA le retour bis. Évalué à 5.
Est-ce que le fait que les binaires soient signés empêchent qu'il y ait des erreurs de programmation dans le programme qui est exécuté ?
Non.
Est-ce que le programme signé en cours d'exécution a les même droits que d'habitude ?
Oui. (au moins pour le moment, mais ça va durer encore plus longtemps)
Conclusion : il n'y aura pas moins de failles qu'avant, et elles ne seront pas moins exploitables (je pense aux virus).
C'est là-dessus qu'on peut communiquer : Trusted ou pas, le programme exécuté n'a aucune raison d'avoir moins de failles. Ça ne protège donc de rien face aux attaques "grand public/entreprise" par rapport aux technologies existantes (protection de pile, bit d'exécution (vieux comme l'informatique ou presque quoiqu'on puisse en penser)).
Pire, ça laisse encore plus à la merci de l'éditeur pour ce qui est de la correction de la faille ;-) À l'heure où le logiciel libre gagne du terrain par l'importance du côté standardisé et ouvert, ça tombe mal. Sans compter l'évolution constante vers les services en lignes, et la mobilité d'un même utilisateur entre plusieurs machines.
Par contre ça peut très bien servir aux DRM évidemment.
Vous avez déjà vu un algorithme cryptographique symétrique dont la clef est confiée à celui en qui on n'a pas confiance ?
Oui. Deux fois : DRM (mais tant que ça se passe en mémoire -> poubelle) et téléphone portable (GSM = chiffrement symétrique. En plus il n'y a qu'une seule clef "d'authentification"). Mais dans ce denier cas elle est dans la carte SIM où se font toutes les opérations cryptographiques évidemment.
Rappelez-vous d'Intel et son Processor-ID sur les Pentium-!!!, ça avait fait du bruit et la chose avait disparu...