Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Cryptage, que choisir ?
Je doit crypté des infos de licence pour un soft. quel est l'algo de crypto le plus fiable et le plus adapté entre :
Blowfish
Cast 128
Cast 256
DES, 3DES
Ice, Thin Ice, Ice2
IDEA
Mars
Misty1
RC2, RC4, RC5, RC6
Rijndael (the new AES)
Serpent
Tea
Twofish
etc...
même question pour le cryptage d'un fichier complet (non texte).
Merci.
Bonjour,
Déjà, il faudrait que tu nous dises si ces informations de licence ont seulement besoin d'être comparées (pour vérifier par exemple que la licence est correcte), ou bien si elles sont succeptibles de devoir être décryptées une fois cryptées.
Dans le premier cas, implémente une simple fonction de hashage : MD5 par exemple conviendra très bien.
Ca te permet de "signer" différent fichiers de licence, puis ensuite, lorsque le client soumet une licence, tu calcules son MD5, et tu le compares aux valeurs que tu connais.
Dans le second cas, ca va dépendre de ce que tu veux : performances, résistance au crack, ... mais aussi selon le type du fichier, ...
Après réflexion, je me pense m'orienter sur un fichier "Key"Déjà, il faudrait que tu nous dises si ces informations de licence ont seulement besoin d'être comparées (pour vérifier par exemple que la licence est correcte), ou bien si elles sont succeptibles de devoir être décryptées une fois cryptées.
Je dois pouvoir extraire certaines infos du fichier de licence :
- Numéro de produit, n° de serie, Version maximal autorisée, (date d'expiration pour certains produit), Propriétaire de la licence, Nombre de Poste pour une licence réseau, info d'activation ...
Le niveau de résistance au crack doit être le plus élévé possible.
Pour la performance, l'extraction des infos du fichier ne sera fait qu"une seule fois au lancement. il ne faut pas que cà prennent 10 minutes ;-)
à ça, il faut que je trouve un moyen pour que le soft ne soit utilisable que sur un seul PC. (la copie du fichier Key sur un autre pc ne doit pas pouvoir fonctionner). l'activation doit être lié au PC.
Pour le chiffrement/déchiffrement AES Bien entendu !!
(Enfin c'est celui que j'utiliserai vu qu'en plus ton fichier licence ne doit pas depasser le Méga octets, tu n'auras pas de problème de temps !
Ensuite pour le fichier key (qui contient la clé de chiffrement/déchiffrement, je suppose) et bien c'est une problèmatique pas simple... il faut bien y réfléchir !
PS: Si tu dois utiliser une fonction de hachage, je te conseille SHA1
pour que ton logiciel marche sur un PC et pas sur un autre tu peux utiliser l'adresse MAC.
(+1 pour AES et SHA-1)
Sauf pour les pc n'ayant pas de carte réseau.
Je pensé plus au modele de processeur + n°serie processeur(facultatif) + n° de serie disque dur + taille du disque dur.
J'ai regardé pour AES. seulement, comment stocker la passphrase.
Si je met la chaine de texte en dur dans mon programme, elle se voit avec un éditeur hexa.
1- J'ai créé un fichier conteant les infos produits et le n° de licence.
2- Quand on lance le soft, il regarde le fichier licence pour savoir si le produit est activé.
si c'est le cas, il vérifie que le pc actuel et bien le pc d'activation.
si c pas le cas, activation par internet (ou par téléphone avec un contre-code)
Toutes ces infos sont dans le fichier licence qui est crypté avec AES.
Problème: pour crypter en AES, j'utilise une passphrase (en dur dans le programme). Or si on edite le programme avec un editeur hexa, on retrouve la passphrase sans problème.
Après, il ne reste plus qu'à comprendre l'algo de cryptage utilisé et on décrypte le fichier licence :-(
Il faudrait que je puisse faire :
AES.passphrase = Decode(ChaineCryptée)
Il y t'il un algo simple mais efficace pour ce genre de fonction ?
Salut,
Jpense pas qu'il existe ce genre de fonction.
Sinon y a plus d'interet a crypter
Envoyé par RamDevTeam
ça existe encore ?
Le stockage des clés est un problème souvent + complexe que le cryptage lui-même. Tu peux utiliser un algo de cryptage asymétrique (avec clé publique/clé privée). Tu code le fichier licence avec la clé privée, tu la décode avec la clé publique. Dans ton soft, il n'y aura que la clé publique, il sera impossible de recréer un fichier licence.
inconvéniant : ces algo sont plus difficiles à implémenter (exemple RSA)
bon courage.
Ce n'était hélas pas un standard il y a 3 ans.RamDevTeam a écrit:
Sauf pour les pc n'ayant pas de carte réseau.
C'est affectivement le noeud du problème en ce qui me concerne.Le stockage des clés est un problème souvent + complexe que le cryptage lui-même.
J'avais aussi pensé au cryptage asymètrique :
- avantage: licence "intouchable".
- Inconvénient : Impossible de stocker les infos d'activations dans le fichier licence pour restreindre le soft à un PC. Sauf à stocker aussi la clé privé dans l'exe. mais dans ce cas, on pert l'avantage de l'asymétrique.
Moralité, pour l'instant je tourne en rond. j'ai un fichier licence crypté en AES mais une passphrase lisible (c comme avoir une porte blindée mais laisser la fenêtre ouverte)
Je n'ai pas du tout comprendre dans ta question
Voila comment je voyais la chose :
1 - ton client execute une 1ere fois ton soft sur son PC, le soft calcule une empreinte avec des informations sur le PC (N° de série, adresse MAC, ce que tu veux...). Le client t'envoie un message (par n'importe quel moyen) contenant cette empreinte.
2 - tu crypte cette empreinte avec ta clé privé (ça s'appelle une signature) et tu renvoie tout ça au client
3 - le client enregistre cette empreinte cryptée et relance le logiciel
4 - le lociciel, lorsqu'il redemarre, recalcule l'empreinte du PC, et décrypte avec ta clé publique l'empreinte cryptée reçue, il compare, si ça correspond, c'est bon, sinon ton soft s'arrete.
comme ça tu n'as pas besoin de mettre ta clé privée dans ton soft, personne ne pourra créer à ta place l'empreinte cryptée (la signature) qui sert de licence.
c'est un peu "usine à gaz" mais ça ne prendra pas 10min
je sais pas si j'ai été clairsi besoin, pose des questions
Je n'avais pas vu les choses comme ça.
je voulais pourvoir faire l'activation directement par téléphone (certaines société interdisant l'accès internet sur les poste de travail mais l'autorise uniquement sur des pc en libre-service..
le soft se lance détecte qu'il n'est pas activé et indique à l'utilisateur d'appeler la société X en fournissant le code xxxx-xxxx-xxx (ce code n'étant valable qu'une seule fois) ou de se connecter à internet.
Par téléphone :
La societe X fournit par téléphone le complément du code que l'utilisateur saisie. et hop, le soft est activé. ce qui voulez dire, que le soft devait être capable de modifier (ou de créér) un fichier licence crypté contenant les infos du PC.
si l'utilisateur veut utiliser son contre-code sur un autre pc, ca ne marche pas car le code fournit par le logiciel aura changé. il faut donc qu'il re-téléphone
ben j'ai bien écris "par n'importe quel moyen"
ben c'est + ou - ce que j'ai écrit dans mon précédebt poste:
1 : ton logiciel calcule une empreinte avec des informations sur le pc
2 : soit il l'affiche et l'utilisateur l'envoie par téléphone, soit ça se fait par réseaux
3 : tu crype cette empreinte avec ta clé privée (chez toi) et te retourne cette empreinte cryptée (toujours soit par téléphone, soit par réseaux)
4 : l'utilisateur enregistre cette empreinte crypté
5 : au redémarrage du programme, il recalcule l'empreinte, décrypte celle qui à été reçue avec ta clé publique et compare, si c'est plus le même pc, ça ne correspondra pas
pb: une empreinte MD5 fait 128 bits soit 32 caractères hexa, ça fait un peu long par téléphone, mais tu peux réduire à 16 ou 8 caractères, tu y perd en sécurité mais ça sera moins agaçant pour l'utilisateur. N'oublie pas que de toute façon, comme tu l'as dit, tu installe un porte blindée mais tu laisse une fenetre ouverte, tout le monde pourra désassembler ton prog et court-circuiter le test, aucun logiciel n'est incrackable !!
ok pour la première phase :
mon soft se lance une première fois, il me fournit par n'importe quel moyen l'empreinte du système sur lequel il est lancé.
Si j'ai bien compris les fonctionnement des systèmes asymétrique :
L'emetteur à une 2 clé, le destinataire aussi.
Je retourne cette empreinte cryptée avec ma clé privé ET la clé publique de mon soft.
Quand mon soft ce lance, il décrypte l'empreinte stockée en utilisant sa clé privée ET ma clé publique
J'ai fouillé après les systèmes asymétriques.
Il y a entre autre RSA et PGP.
La seule solution Open Source et GPG. mais visiblement, la clé secréte (privé) est toujours associée à une passphrase.
Or, si je stocke la passphrase dans mon programme, elle sera en clair
Bien sur, c la passphrase de la clé privée du soft donc elle ne permet pas de cryptée une empreinte mais juste de décryptée. ca me semble quand même une faille.
un cracker pourrait très bien extraire ma clé publique, la clé privé du soft et la passphrase, décrypter le fichier empreinte.
remplacé ma clé publique (incluse dans le soft) par sa clé publique
et recréer un fichier empreinte avec sa clé privé. mon soft n'y verrait que du feux :-(
bon, Je suis peu être un peu parano.
Ensuite pour éviter que le test soit inverser et court-circuiter il faut éviter les lignes du type :
if Verif(empreinte) then Ok else Message('Pas bon !').
pour ça il y a des solutions.
mais non heuuuuu
tu n'as besoin que d'une clé privé (QUI RESTE CHEZ TOI, et même s'il faut une passphrase pour la créer, cette passphrase reste chez toi aussi) et de la clé publique correspondante (celle là doit être dans ton soft). Cette clé publique permettra de décrypter la licence que t'as envoyée, mais pas d'en crypter une autre.
Avec ces algos asymétriques, ce que tu crypte avec une clé n'est décryptable qu'avec l'autre clé, et il est impossible de déduire une clé quand on connait l'autre.
Effectivement, dans le cas d'une simple signature, la clé publique suffit au logiciel.
Seulement, comparer une signature est "facilement" court-circuitable en inversant le test, ce qui revient à autoriser toutes les signatures erronées.
Si je veux avoir une porte blindée ET une fenêtre fermée
Si le fichier licence contient des portions indispensables au fonctionnement du soft, il faut obligatoirement la bonne licence ce qui renforce la sécurité. Dans ce cas, il ne s'agit plus de signature mais de chiffrement du fichier (ce qui permet d'y indiquer notamment le nom du propriètaire de la licence, le type de licence, etc ...).
le principe du PGP est le suivant :
En résumé :l'opération de chiffrement se fait principalement en deux étapes :
* PGP crée une clé secrète IDEA de manière aléatoire, et chiffre les données avec cette clé
* PGP crypte la clé secrète IDEA et la transmet au moyen de la clé RSA publique du destinataire.
L'opération de décryptage se fait également en deux étapes :
* PGP déchiffre la clé secrète IDEA au moyen de la clé RSA privée (du destinataire).
* PGP déchiffre les données avec la clé secrète IDEA précédemment obtenue.
- Dans le cas du chiffrement d'un fichier, je suis bloqué par la passphrase de la clé privé du destinataire (le soft étant considéré comme le destinataire). car il faut bien la clé privé de l'emetteur (Moi) + la clé publique du destinataire (le soft) pour chiffrer un fichier, et la clé privé du destinataire (le soft) + la clé publique de l'emetteur (Moi) pour le déchiffrer.
Autre point concernant la signature tel que tu (jmv) la décris.
un cracker se génére un couple de clé Privé/publique.
il remplacé ma clé publique incluse dans le soft par sa propre clé publique.
ensuite, il lance le soft la 1er fois, le soft calcule l'empreinte du PC et lui affiche. il crypte l'empreinte avec sa clé privé et la saisie.
le soft l'enregistre.
dorénavant à chaque lancement le soft utilise la clé du cracker pour vérifier l'empreinte. donc c valable à tous les coup.
Le principe du crack est simple dans la théorie. est-il simple à mettre en pratique, c un autre pb...
De toute façon, et même si ça peut sembler être une vision "simpliste", il y aura bien à un moment un test qui entrainera l'acceptation ou le rejet de ta key c'est-à-dire l'accès ou non au programme.
Par conséquent dans tous les cas il "suffira" au cracker de trouver ce (ces) test et de sauter directement.... dites-moi si je me trompe
Dans le cas d'une comparaison de password ou de signature je suis d'accord.De toute façon, et même si ça peut sembler être une vision "simpliste", il y aura bien à un moment un test qui entrainera l'acceptation ou le rejet de ta key c'est-à-dire l'accès ou non au programme.
D'où mon idée de déporter certains paramètres du programme dans le fichier licence (crypté).
exemple : le chemin d'installation des DLL, leur nom, etc ..
Si tu n'a pas le bon fichier licence, le soft est incapable de chargé les DLL donc de fonctionner correctement.
En effet dans ce cas cela compliquera la tache du cracker.
oui mais ta clé privé ne sera pas dans le soft, donc personne d'autres que toi ne pourra créer un fichier licence.
Répondre avec citation
Partager