binaire : un système permet d'identifier les programmes (et documents) qui sont sur votre ordinateur. mais ici vous n'avez pas le choix d'identifier par vous même les binaires dans lesquels vous avez confiance.
Il est possible pour les constructeurs de brider des fonctionnalités de leur matériel en fonction de la séquence de boot, mais celà demande une base de données assez conséquente.
La façon dont TCPA fonctionne ne permet pas de signer un élément à part. Il y a un enchainement de hash qui donne le résultat final, c'est d'ailleurs le but. A quoi servirait d'avoir un boot sector valide si le bios a été corrompu ? De même à quoi sert de vérifier l'OS sans vérifier d'abord le boot sector (l'OS peut tourner dans une machine virtuelle après tout). Donc la norme TCPA ne permet pas de signer 'juste' un binaire. La séquence de chiffrement lors de la demande de signature d'une application est proche de celle-ci :
hash(puce)
hash(bios + hash(puce))
hash(os loader +hash(bios + hash(puce)))
hash(OS + hash(os loader +hash(bios + hash(puce))))
hash(applis + hash(OS + hash(os loader +hash(bios + hash(puce)))))
En d'autres termes la signature lorsque l'on demande le hash d'une application change dès que l'on touche à quoi que ce soit qui se trouve en dessous de l'appli. Difficile donc de certifier que l'appli est bonne a moins d'avoir une base de données sur les différents éléments possibles absolument gigansteque et de la suivre au gré des différentes mise à jour (bios et windows update notamment)
Si l'on veut faire du DRM avec TCPA on est obligé de s'arreter au niveau inférieur (hash de l'OS) et de travailler main dans la main avec le fabriquant de l'OS pour suivre les évolutions des hash. Derrière il faut que l'OS dispose lui d'un moyen de se certifier "tout seul" - ce qui est faisable mais descend la sécurité à un niveau plus bas - et de remonter cette certification via la TPM.
De plus normalement les puces TPM ne peuvent pas être livrées pré-certifiées (la norme l'interdit spécifiquement, et celà limiterait ennormément leur usage), et qu'il faut donc que l'utilisateur a) active la puce t b) la remplisse lui même au moins au début - a noter cependant que ca n'est pas techniquement impossible, et que il se peut très bien que les constructeurs changent d'avis. Mais il est plus probable qu'ils utilisent un système supplémentaire basé sur TPM mais qui possède des fonctions et des mémoires séparées pour faciliter la validation/activation du hardware et du software morceau par morceau (c'est le système LaGrande d'Intel, et c'ets de loin celui qui me fait le plus peur).
[^] # Re: Trusted computing = free software
Posté par Jerome Herman . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 10.
Il est possible pour les constructeurs de brider des fonctionnalités de leur matériel en fonction de la séquence de boot, mais celà demande une base de données assez conséquente.
La façon dont TCPA fonctionne ne permet pas de signer un élément à part. Il y a un enchainement de hash qui donne le résultat final, c'est d'ailleurs le but. A quoi servirait d'avoir un boot sector valide si le bios a été corrompu ? De même à quoi sert de vérifier l'OS sans vérifier d'abord le boot sector (l'OS peut tourner dans une machine virtuelle après tout). Donc la norme TCPA ne permet pas de signer 'juste' un binaire. La séquence de chiffrement lors de la demande de signature d'une application est proche de celle-ci :
hash(puce)
hash(bios + hash(puce))
hash(os loader +hash(bios + hash(puce)))
hash(OS + hash(os loader +hash(bios + hash(puce))))
hash(applis + hash(OS + hash(os loader +hash(bios + hash(puce)))))
En d'autres termes la signature lorsque l'on demande le hash d'une application change dès que l'on touche à quoi que ce soit qui se trouve en dessous de l'appli. Difficile donc de certifier que l'appli est bonne a moins d'avoir une base de données sur les différents éléments possibles absolument gigansteque et de la suivre au gré des différentes mise à jour (bios et windows update notamment)
Si l'on veut faire du DRM avec TCPA on est obligé de s'arreter au niveau inférieur (hash de l'OS) et de travailler main dans la main avec le fabriquant de l'OS pour suivre les évolutions des hash. Derrière il faut que l'OS dispose lui d'un moyen de se certifier "tout seul" - ce qui est faisable mais descend la sécurité à un niveau plus bas - et de remonter cette certification via la TPM.
De plus normalement les puces TPM ne peuvent pas être livrées pré-certifiées (la norme l'interdit spécifiquement, et celà limiterait ennormément leur usage), et qu'il faut donc que l'utilisateur a) active la puce t b) la remplisse lui même au moins au début - a noter cependant que ca n'est pas techniquement impossible, et que il se peut très bien que les constructeurs changent d'avis. Mais il est plus probable qu'ils utilisent un système supplémentaire basé sur TPM mais qui possède des fonctions et des mémoires séparées pour faciliter la validation/activation du hardware et du software morceau par morceau (c'est le système LaGrande d'Intel, et c'ets de loin celui qui me fait le plus peur).