question habituelle: numéros de page des docs offcielles TCPA où tu as lu tout ça ?
CF section 4.27 sur le storage et la migration des clefs assymetriques
section 4.30 sur les systemes d'identites
section 6.3 sur l'acces en lecture aux differents repertoires et PCR
section 7.2 sur l'ensemble des fonctions obligatoires pour lire une clef publique, binder une clef, debinder une clef, sealer une clef, liberer une clef, preparer un cryptage de migration d'une clef, crypter une clef avec son blob de migration, autoriser la migration d'une clef etc...
Je ne peux pointer dans la doc TCPA ce qui parle du DRM, vu qu'il n'y a rien.
# less spectcpa | grep -e DRM
#
Rien, que dalle. Si tu penses pouvoir utiliser TCPA pour faciliter la protection DRM, explique moi comment, moi je ne vois pas.
On finit avec le paragraphe IBM
The TCPA chip is not particularly suited to DRM. While it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use, this type of scheme would
be a nightmare for content providers to manage. Any change to the BIOS, the operating
system, or the application would change the reported values. How could content
providers recognize which reported PCR values were good, given the myriad platforms,
operating system versions, and frequent software patches?
Second, the IBM version of the TCPA chip, while evaluated to FIPS and Common
Criteria security standards, has specifically omitted tamper resistance from the evaluation
target. The IBM chip sits on the LPC bus, which is easily monitored. The chip is not
defended against power analysis, RF analysis or timing analysis. The bottom line is that
the physical owner of the machine could easily recover any DRM secrets from the chip.
This apparent lack of security in the chip makes perfect sense when you realize that the
purpose of the chip is to defend the user's data against remote (software) attack. When the
goal is to protect the user's keys and data against external attack, we simply are not
concerned with threats based on the user attacking the chip, as the user already has secure
access to his own data.
Traduction : la puce TCPA n'est pas vraiment adaptee a DRM. Bien qu' elle permette de controller des PCR signes, et que ce type d'information peut etre utilise pour empecher une lecture si l'OS et le lecteur ne sont pas des applications de confiance, ce type de modele serait un cauchemar a gerer pour les fournisseurs de contenu, n'importe quel changement au niveau du BIOS, de l'OS ou de l'applicatif changerait les valeurs. Comment ferait les fournisseurs pour connaitre les bonnes valeurs de PCR parmis la myriade de plateforme, de systemes et les frequentes mise a jour ?
Deuxiemement la puce TCPA d'IBM, pendant l'evaluation vis a vis de FIPS et des Common Criteria security standards, a specifiquement omis la resistance a l'audit de cet evaluation. La puce IBM est place sur le bus LPC qui est facile a surveiller. La puce n'a pas de defenses contre des analyse de puissance, de frequence ou de temporisattion. Au final, un utlisiateur pourrait tres facilement recuperer n'importe quel secret DRM de la puce.
Cette absence aparente de securite dans la puce, devient parfaitement logique quand vous realisez que le but de cette puce est de defendre l'utilisateur contre les attaques (logicielles) a distance. Quand on se concentre sur la protection des clefs et des donnees de l'utilisateur contre des attaques exterieures, on se moque du danger represente par un utilisateur qui attaque sa propre puce, vu que l'utilisateur a deja un acces securise a ses donnees.
Simplement : Si DRM met des clefs privees dans une TCPA IBM, il faudra pas qu'il se plaignent si elle se retrouve expose au grand jour.
[^] # Re: TCPA confirmé comme menace bien pire que le numéro du pentium
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
CF section 4.27 sur le storage et la migration des clefs assymetriques
section 4.30 sur les systemes d'identites
section 6.3 sur l'acces en lecture aux differents repertoires et PCR
section 7.2 sur l'ensemble des fonctions obligatoires pour lire une clef publique, binder une clef, debinder une clef, sealer une clef, liberer une clef, preparer un cryptage de migration d'une clef, crypter une clef avec son blob de migration, autoriser la migration d'une clef etc...
Je ne peux pointer dans la doc TCPA ce qui parle du DRM, vu qu'il n'y a rien.
# less spectcpa | grep -e DRM
#
Rien, que dalle. Si tu penses pouvoir utiliser TCPA pour faciliter la protection DRM, explique moi comment, moi je ne vois pas.
On finit avec le paragraphe IBM
The TCPA chip is not particularly suited to DRM. While it does have the ability to report signed PCR information, and this information could be used to prevent playback unless a trusted operating system and application were in use, this type of scheme would
be a nightmare for content providers to manage. Any change to the BIOS, the operating
system, or the application would change the reported values. How could content
providers recognize which reported PCR values were good, given the myriad platforms,
operating system versions, and frequent software patches?
Second, the IBM version of the TCPA chip, while evaluated to FIPS and Common
Criteria security standards, has specifically omitted tamper resistance from the evaluation
target. The IBM chip sits on the LPC bus, which is easily monitored. The chip is not
defended against power analysis, RF analysis or timing analysis. The bottom line is that
the physical owner of the machine could easily recover any DRM secrets from the chip.
This apparent lack of security in the chip makes perfect sense when you realize that the
purpose of the chip is to defend the user's data against remote (software) attack. When the
goal is to protect the user's keys and data against external attack, we simply are not
concerned with threats based on the user attacking the chip, as the user already has secure
access to his own data.
Traduction : la puce TCPA n'est pas vraiment adaptee a DRM. Bien qu' elle permette de controller des PCR signes, et que ce type d'information peut etre utilise pour empecher une lecture si l'OS et le lecteur ne sont pas des applications de confiance, ce type de modele serait un cauchemar a gerer pour les fournisseurs de contenu, n'importe quel changement au niveau du BIOS, de l'OS ou de l'applicatif changerait les valeurs. Comment ferait les fournisseurs pour connaitre les bonnes valeurs de PCR parmis la myriade de plateforme, de systemes et les frequentes mise a jour ?
Deuxiemement la puce TCPA d'IBM, pendant l'evaluation vis a vis de FIPS et des Common Criteria security standards, a specifiquement omis la resistance a l'audit de cet evaluation. La puce IBM est place sur le bus LPC qui est facile a surveiller. La puce n'a pas de defenses contre des analyse de puissance, de frequence ou de temporisattion. Au final, un utlisiateur pourrait tres facilement recuperer n'importe quel secret DRM de la puce.
Cette absence aparente de securite dans la puce, devient parfaitement logique quand vous realisez que le but de cette puce est de defendre l'utilisateur contre les attaques (logicielles) a distance. Quand on se concentre sur la protection des clefs et des donnees de l'utilisateur contre des attaques exterieures, on se moque du danger represente par un utilisateur qui attaque sa propre puce, vu que l'utilisateur a deja un acces securise a ses donnees.
Simplement : Si DRM met des clefs privees dans une TCPA IBM, il faudra pas qu'il se plaignent si elle se retrouve expose au grand jour.
Kha