Discussion :

[BiM]

Ca n'a pas grand chose à voir avec l'algorithmique, mais il ne faut pas oublier que souvent le plus simple pour un "pirate" est de modifier l'exécutable pour qu'il saute l'étape de vérification.

Ce n'est pas un exécutable, c'est une application J2EE d'environ 3000 classes. On peut dans ce cas remplacer la classe de vérification certes

Je cherche la solution la plus efficace, il y aura toujours un moyen de passer au delà.

[Janitrix]

Et tu veux interdire l'utilisation de cette application si l'utilisateur n'a pas une licence valide ? Peut être que Sun a déjà crée une sorte de certificat pour ça, à vérifier.

[BiM]

Et tu veux interdire l'utilisation de cette application si l'utilisateur n'a pas une licence valide ? Peut être que Sun a déjà crée une sorte de certificat pour ça, à vérifier.

C'est exactement ça !

Mais je le répète, je n'ai pas accès à Internet dans ce cas. Donc une autorité de certification est inutile.

[Janitrix]

Quand je parlais de certificat, je pensais à un outil de Sun permettant la certification de la validité d'une application, en local. J'ai dis ça comme ça, je ne suis pas sur que ça existe et encore moins que c'est réalisable .

[BiM]

En parcourant le net à la recherche d'une réponse, une idée m'est venue.

Par stéganographie, je pourrais aller jusqu'où ? Je peux intégrer n'importe quoi dans une image ? C'est facile à récuperer ?

[ol9245]

D'accord.

C'est là ou est toute la difficulté. Si une personne crypte avec une clef privée à lui et il remplace ma clef publique par la sienne, alors le système ne sers plus à rien. Dans ce cas, y-a-t'il une autre solution envisageable ?

Merci pour ta patience

Mes deux grains de sel :
1) Si un client veut utiliser le logiciel frauduleusement, il va s'adresser à un hacker. les hackers du marché sont surtout spécialistes de la décompilation. beaucoup moins en cryptographie. donc le but d'une protection d'une licence, c'est que le travail pour casser la clé soit au moins égal -et du même ordre de grandeur- au travail de décompilation/crackage/recompilation. En clair, ça veut dire : pas besoin d'une serrure 5 points pour fermer une porte en contreplaqué.

2) l'ordi destinataire ne sera pas connecté a internet dis-tu. donc les clés vont circuler par voie terrestre (support papier, cd rom, etc). a priori, ce genre de media est assez facile à protéger, par rapport à une transmission par réseau qui pose en particulier le problème de l'interception de la communication, de sa signature, etc.

[BiM]

Mes deux grains de sel :
1) Si un client veut utiliser le logiciel frauduleusement, il va s'adresser à un hacker. les hackers du marché sont surtout spécialistes de la décompilation. beaucoup moins en cryptographie. donc le but d'une protection d'une licence, c'est que le travail pour casser la clé soit au moins égal -et du même ordre de grandeur- au travail de décompilation/crackage/recompilation. En clair, ça veut dire : pas besoin d'une serrure 5 points pour fermer une porte en contreplaqué.

2) l'ordi destinataire ne sera pas connecté a internet dis-tu. donc les clés vont circuler par voie terrestre (support papier, cd rom, etc). a priori, ce genre de media est assez facile à protéger, par rapport à une transmission par réseau qui pose en particulier le problème de l'interception de la communication, de sa signature, etc.

Le problème n'est pas le transfert de la licence mais la protection de la licence.

[goomazio]

D'accord.

C'est là ou est toute la difficulté. Si une personne crypte avec une clef privée à lui et il remplace ma clef publique par la sienne, alors le système ne sers plus à rien. Dans ce cas, y-a-t'il une autre solution envisageable ?

Merci pour ta patience

La clé privée doit être la même pour crypter et décrypter et donc (si c'est bien correct ce que je viens d'écrire) ce cas n'est pas possible.

[BiM]

La clé privée doit être la même pour crypter et décrypter et donc (si c'est bien correct ce que je viens d'écrire) ce cas n'est pas possible.

Pourquoi la clef privée serait-elle la même pour crypter et décrypter ?

Dans ce cas là, la clef ne sers plus à rien...

[BiM]

Merci pour toutes vos réponses, je crois que je vais arrêter mes questions sur le sujet ici (Mais le sujet n'est pas fermé, je suis ouverte à toute nouvelle proposition -crypto et stéganographique).

[Janitrix]

La clé privée doit être la même pour crypter et décrypter et donc (si c'est bien correct ce que je viens d'écrire) ce cas n'est pas possible.

Quelle est l'utilité de la clé publique dans ce cas ? Ce que tu dis est tout simplement faux, voilà comment ça se passe : si le propriétaire veux envoyer un message, il crypte le message avec sa clé privée et le destinataire le décrypte avec la clé publique de l'expéditeur. Le fait que l'expéditeur est crypté le message avec sa clé privée prouve en théorie son idéntité (puisqu'il est le seul à disposer de cette clé).

Si quelqu'un veut envoyer un message au propriétaire, il crypte avec la clé publique et le propriétaire peut décrypter avec sa clé privée.

C'est tout...

Pour toi BiM, je réfléchi à trouver un moyen, mais malheureusement, je n'en vois pas actuellement. Tu peux te renseigner pour voir si Sun n'a pas prévu quelque chose dans ce genre pour les applications Java EE, si tu as de la chance, ce que tu veux existe déjà.

Bon courage

[BiM]

Merci Janitrix, tu me rassures !

Je crois que j'ai un embryon de solution mais vous n'aurez pas le détail