Antoine a écrit :Existe-t'il une solution cryptographique pour protéger du code ?
[..pour faire..] différentes > versions d'un logiciel: personal,
> pro, et "enterprise" avec des limites arbitraires, et certainement
> pas plus de quelques octets de différence entre eux.
Mis à part les barrières d'ordre légal, les deux principales voies
techniques sont:
1) L'exécution du programme, ou d'une partie de celui-ci, dans un
environnement de confiance; par exemple, une carte à puce dans laquelle
certaines parties du code exécutable du programme sont en java card, et
non accessible à l'adversaire. Celui-ci peut seulement capter les
échanges entre le programme principal et l'environnement de confiance.
Il semble que les moins mauvaises techniques d'attaque sont de
comprendre ce que fait la fraction du programme s'exécutant dans
l'environnement de confiance, et de la réécrire; ou de compromettre
l'environnement de confiance.
2) L'"obfuscation" qui tente de rendre la décompilation et/ou la
modification du code exécutable difficile, bien qu'il s'exécute dans un
environnement ouvert type PC standard. Je ne crois pas que l'on sache
faire quelque chose qui corresponde aux critère cryptographiques normaux
(en particulier, algorithme d'"obfuscation" public) et qui soit vraiment
résistant, mais cela fonctionne en pratique comme stratégie de
retardement. L'augmentation de la taille du code des applications
déplace plutôt l'équilibre protection/attaque en faveur de la première.
Dans les deux cas, un obstacle pratique majeur est que c'est difficile à
automatiser d'une manière transparentes aux multiples outils en
constante évolution qui produisent du code exécutable, tout en
maintenant une protection efficace. Dans le premier cas, il y a en plus
le problème de commodité d'installation, et de rapport performance/cout,
de l'environnement de confiance.
François Grieu
Antoine a écrit :
Existe-t'il une solution cryptographique pour protéger du code ?
[..pour faire..] différentes > versions d'un logiciel: personal,
> pro, et "enterprise" avec des limites arbitraires, et certainement
> pas plus de quelques octets de différence entre eux.
Mis à part les barrières d'ordre légal, les deux principales voies
techniques sont:
1) L'exécution du programme, ou d'une partie de celui-ci, dans un
environnement de confiance; par exemple, une carte à puce dans laquelle
certaines parties du code exécutable du programme sont en java card, et
non accessible à l'adversaire. Celui-ci peut seulement capter les
échanges entre le programme principal et l'environnement de confiance.
Il semble que les moins mauvaises techniques d'attaque sont de
comprendre ce que fait la fraction du programme s'exécutant dans
l'environnement de confiance, et de la réécrire; ou de compromettre
l'environnement de confiance.
2) L'"obfuscation" qui tente de rendre la décompilation et/ou la
modification du code exécutable difficile, bien qu'il s'exécute dans un
environnement ouvert type PC standard. Je ne crois pas que l'on sache
faire quelque chose qui corresponde aux critère cryptographiques normaux
(en particulier, algorithme d'"obfuscation" public) et qui soit vraiment
résistant, mais cela fonctionne en pratique comme stratégie de
retardement. L'augmentation de la taille du code des applications
déplace plutôt l'équilibre protection/attaque en faveur de la première.
Dans les deux cas, un obstacle pratique majeur est que c'est difficile à
automatiser d'une manière transparentes aux multiples outils en
constante évolution qui produisent du code exécutable, tout en
maintenant une protection efficace. Dans le premier cas, il y a en plus
le problème de commodité d'installation, et de rapport performance/cout,
de l'environnement de confiance.
François Grieu
Antoine a écrit :Existe-t'il une solution cryptographique pour protéger du code ?
[..pour faire..] différentes > versions d'un logiciel: personal,
> pro, et "enterprise" avec des limites arbitraires, et certainement
> pas plus de quelques octets de différence entre eux.
Mis à part les barrières d'ordre légal, les deux principales voies
techniques sont:
1) L'exécution du programme, ou d'une partie de celui-ci, dans un
environnement de confiance; par exemple, une carte à puce dans laquelle
certaines parties du code exécutable du programme sont en java card, et
non accessible à l'adversaire. Celui-ci peut seulement capter les
échanges entre le programme principal et l'environnement de confiance.
Il semble que les moins mauvaises techniques d'attaque sont de
comprendre ce que fait la fraction du programme s'exécutant dans
l'environnement de confiance, et de la réécrire; ou de compromettre
l'environnement de confiance.
2) L'"obfuscation" qui tente de rendre la décompilation et/ou la
modification du code exécutable difficile, bien qu'il s'exécute dans un
environnement ouvert type PC standard. Je ne crois pas que l'on sache
faire quelque chose qui corresponde aux critère cryptographiques normaux
(en particulier, algorithme d'"obfuscation" public) et qui soit vraiment
résistant, mais cela fonctionne en pratique comme stratégie de
retardement. L'augmentation de la taille du code des applications
déplace plutôt l'équilibre protection/attaque en faveur de la première.
Dans les deux cas, un obstacle pratique majeur est que c'est difficile à
automatiser d'une manière transparentes aux multiples outils en
constante évolution qui produisent du code exécutable, tout en
maintenant une protection efficace. Dans le premier cas, il y a en plus
le problème de commodité d'installation, et de rapport performance/cout,
de l'environnement de confiance.
François Grieu
Francois Grieu wrote:Antoine a écrit :Existe-t'il une solution cryptographique pour protéger du code ?
[..pour faire..] différentes > versions d'un logiciel: personal,
> pro, et "enterprise" avec des limites arbitraires, et certainement
> pas plus de quelques octets de différence entre eux.
Mis à part les barrières d'ordre légal, les deux principales voies
techniques sont:
1) L'exécution du programme, ou d'une partie de celui-ci, dans un
environnement de confiance; par exemple, une carte à puce dans
laquelle certaines parties du code exécutable du programme sont en
java card, et non accessible à l'adversaire. Celui-ci peut seulement
capter les échanges entre le programme principal et l'environnement de
confiance. Il semble que les moins mauvaises techniques d'attaque sont
de comprendre ce que fait la fraction du programme s'exécutant dans
l'environnement de confiance, et de la réécrire; ou de compromettre
l'environnement de confiance.
2) L'"obfuscation" qui tente de rendre la décompilation et/ou la
modification du code exécutable difficile, bien qu'il s'exécute dans
un environnement ouvert type PC standard. Je ne crois pas que l'on
sache faire quelque chose qui corresponde aux critère cryptographiques
normaux (en particulier, algorithme d'"obfuscation" public) et qui
soit vraiment résistant, mais cela fonctionne en pratique comme
stratégie de retardement. L'augmentation de la taille du code des
applications déplace plutôt l'équilibre protection/attaque en faveur
de la première.
Dans les deux cas, un obstacle pratique majeur est que c'est difficile
à automatiser d'une manière transparentes aux multiples outils en
constante évolution qui produisent du code exécutable, tout en
maintenant une protection efficace. Dans le premier cas, il y a en
plus le problème de commodité d'installation, et de rapport
performance/cout, de l'environnement de confiance.
Arf je pensais que la question était pour pc donc un environement de
confiance sur PC :D
Il est vrai que l'environnement de confiance est bien sauf que si il y a
necessite de sortie de l'environnement de confiance, dans ce cas cela ne
sert a rien: les attaques se porteront sur les echanges
espionnage/modifications des communications, pas sur l'algorithme protege
Par contre le fait de packer des executables est legerement different de
l'obfuscation:
- l'obfuscation s'applique surtout au code source et est utilise pour
les applications dont on peut retrouver l'integralite des sources avec
les fichiers compiles. Elle est utilise pour tout ce qui est
pseudo-compile Java et .Net Rien ne se passe à l'execution du programme
- le fait de packer un soft fait que le programme se decrypte avant ou
au fur et a mesure de son execution.
C est malheureusement une methode plus qu'utilisee dans les virus
Francois Grieu wrote:
Antoine a écrit :
Existe-t'il une solution cryptographique pour protéger du code ?
[..pour faire..] différentes > versions d'un logiciel: personal,
> pro, et "enterprise" avec des limites arbitraires, et certainement
> pas plus de quelques octets de différence entre eux.
Mis à part les barrières d'ordre légal, les deux principales voies
techniques sont:
1) L'exécution du programme, ou d'une partie de celui-ci, dans un
environnement de confiance; par exemple, une carte à puce dans
laquelle certaines parties du code exécutable du programme sont en
java card, et non accessible à l'adversaire. Celui-ci peut seulement
capter les échanges entre le programme principal et l'environnement de
confiance. Il semble que les moins mauvaises techniques d'attaque sont
de comprendre ce que fait la fraction du programme s'exécutant dans
l'environnement de confiance, et de la réécrire; ou de compromettre
l'environnement de confiance.
2) L'"obfuscation" qui tente de rendre la décompilation et/ou la
modification du code exécutable difficile, bien qu'il s'exécute dans
un environnement ouvert type PC standard. Je ne crois pas que l'on
sache faire quelque chose qui corresponde aux critère cryptographiques
normaux (en particulier, algorithme d'"obfuscation" public) et qui
soit vraiment résistant, mais cela fonctionne en pratique comme
stratégie de retardement. L'augmentation de la taille du code des
applications déplace plutôt l'équilibre protection/attaque en faveur
de la première.
Dans les deux cas, un obstacle pratique majeur est que c'est difficile
à automatiser d'une manière transparentes aux multiples outils en
constante évolution qui produisent du code exécutable, tout en
maintenant une protection efficace. Dans le premier cas, il y a en
plus le problème de commodité d'installation, et de rapport
performance/cout, de l'environnement de confiance.
Arf je pensais que la question était pour pc donc un environement de
confiance sur PC :D
Il est vrai que l'environnement de confiance est bien sauf que si il y a
necessite de sortie de l'environnement de confiance, dans ce cas cela ne
sert a rien: les attaques se porteront sur les echanges
espionnage/modifications des communications, pas sur l'algorithme protege
Par contre le fait de packer des executables est legerement different de
l'obfuscation:
- l'obfuscation s'applique surtout au code source et est utilise pour
les applications dont on peut retrouver l'integralite des sources avec
les fichiers compiles. Elle est utilise pour tout ce qui est
pseudo-compile Java et .Net Rien ne se passe à l'execution du programme
- le fait de packer un soft fait que le programme se decrypte avant ou
au fur et a mesure de son execution.
C est malheureusement une methode plus qu'utilisee dans les virus
Francois Grieu wrote:Antoine a écrit :Existe-t'il une solution cryptographique pour protéger du code ?
[..pour faire..] différentes > versions d'un logiciel: personal,
> pro, et "enterprise" avec des limites arbitraires, et certainement
> pas plus de quelques octets de différence entre eux.
Mis à part les barrières d'ordre légal, les deux principales voies
techniques sont:
1) L'exécution du programme, ou d'une partie de celui-ci, dans un
environnement de confiance; par exemple, une carte à puce dans
laquelle certaines parties du code exécutable du programme sont en
java card, et non accessible à l'adversaire. Celui-ci peut seulement
capter les échanges entre le programme principal et l'environnement de
confiance. Il semble que les moins mauvaises techniques d'attaque sont
de comprendre ce que fait la fraction du programme s'exécutant dans
l'environnement de confiance, et de la réécrire; ou de compromettre
l'environnement de confiance.
2) L'"obfuscation" qui tente de rendre la décompilation et/ou la
modification du code exécutable difficile, bien qu'il s'exécute dans
un environnement ouvert type PC standard. Je ne crois pas que l'on
sache faire quelque chose qui corresponde aux critère cryptographiques
normaux (en particulier, algorithme d'"obfuscation" public) et qui
soit vraiment résistant, mais cela fonctionne en pratique comme
stratégie de retardement. L'augmentation de la taille du code des
applications déplace plutôt l'équilibre protection/attaque en faveur
de la première.
Dans les deux cas, un obstacle pratique majeur est que c'est difficile
à automatiser d'une manière transparentes aux multiples outils en
constante évolution qui produisent du code exécutable, tout en
maintenant une protection efficace. Dans le premier cas, il y a en
plus le problème de commodité d'installation, et de rapport
performance/cout, de l'environnement de confiance.
Arf je pensais que la question était pour pc donc un environement de
confiance sur PC :D
Il est vrai que l'environnement de confiance est bien sauf que si il y a
necessite de sortie de l'environnement de confiance, dans ce cas cela ne
sert a rien: les attaques se porteront sur les echanges
espionnage/modifications des communications, pas sur l'algorithme protege
Par contre le fait de packer des executables est legerement different de
l'obfuscation:
- l'obfuscation s'applique surtout au code source et est utilise pour
les applications dont on peut retrouver l'integralite des sources avec
les fichiers compiles. Elle est utilise pour tout ce qui est
pseudo-compile Java et .Net Rien ne se passe à l'execution du programme
- le fait de packer un soft fait que le programme se decrypte avant ou
au fur et a mesure de son execution.
C est malheureusement une methode plus qu'utilisee dans les virus