Là en utilisant les keychains une routine de cryptage maison devient largement moins vulnérable. Même en désassemblant le programme, ça ne servirait à rien car les données seraient cryptées avec un mot de passe enregistré dans les keychains.
Et qu'est-ce qui te permet d'assurer que ton algo n'est pas crackable sans avoir le mot de passe enregistré dans les keychains? Je ne met pas en doute tes qualités de developpeur, mais un système de cryptage fiable et éprouvé est un système de cryptage qui a été soumis à des audits independants..
Mais si tu m'indiques une bonne doc ou même pourquoi pas un framework pour OpenSSL, je veux bien oublier ma roue.
Si tu stocke une clé dans KeyChain, alors le plus simple est d'utiliser un algo symétrique comme par exemple BlowFish, AES (utilisé par FileFault selon Apple)..
Les noms des méthodes sont un peu tordus, c'est en partie dû au différents modes de cryptages possibles (ECB, CBC, CFB, OFB...), en fait seule une poignée est nécessaire en fonction du mode choisi.. http://www.openssl.org/docs/crypto/des_modes.html
Par contre, en fouillant sur le site de l'ADC, j'ai vu qu'Apple recommandais plutôt d'utiliser la Common Data Security Architecture (CDSA) (utilisé par KeyChain Service) pour les applis natives OS X.. (Si la portabilité Unix est recherchée, il vaut mieux utiliser OpenSSL)
Personnellement, j'avais utilisé OpenSSL dans une appli Cocoa pour créer des "empreintes" SHA-1, mais comme j'ai constaté des problèmes de link lorsqu'OpenSSL est mis à jour (comme c'est déjà arrivé lors de mise à jour de sécurité d'OS X), alors je vais me pencher sur CDSA..
Pour revenir à l'application de stockage de mot de passe, je me demande si ca sera pas plus simple d'utiliser KeyChain pour stocker tous les mots de passes..
Non je n'ai pas eu le temps, ce n'est pas ma priorité pour l'instant car j'ai bien d'autres chats a fouetter...je fais partis de ceux qui aimeraient avoir des journées de 30 heures.
dans 1099487524:
Et qu'est-ce qui te permet d'assurer que ton algo n'est pas crackable sans avoir le mot de passe enregistré dans les keychains? Je ne met pas en doute tes qualités de developpeur, mais un système de cryptage fiable et éprouvé est un système de cryptage qui a été soumis à des audits independants..
Et bien nucleus, je suis pas développeur de formation, mais autodidacte, et j'apprends tout sur le tas, pendant mes temps libre. Je crois que je commence à avoir un peu d'expérience depuis le temps... Avec l'idée que j'ai actuellement, si tu veux décrypter un fichier, il te faut non seulement désassembler l'algo, mais aussi casser les keychains car tout les paramètres de cryptage qui seraient aléatoires et configurés en partie par l'utilisateur et utilisés par l'algo seraient en sécurité dans les keychains. Donc avoir l'algo sans les paramètres ça serait un peu comme avoir une voiture sans carburant. Donc si tu veux décrypter le fichier, faut casser les keychains... En ce qui concerne la soumission du système de cryptage à des audits indépendants, c'est une autre histoire, et je te répondrais que je ne connais pas meilleur audit que les hackers....
dans 1099487524:
Personnellement, j'avais utilisé OpenSSL dans une appli Cocoa pour créer des "empreintes" SHA-1, mais comme j'ai constaté des problèmes de link lorsqu'OpenSSL est mis à jour (comme c'est déjà arrivé lors de mise à jour de sécurité d'OS X), alors je vais me pencher sur CDSA..
Merci pour toutes ces informations, le framework a pas l'air mal, il y a même un authorization.framework (Oxitan ! ) c'est cool! Quels sont ces problèmes dont tu parles lors des mises à jour d'OpenSSL ? Problèmes de compatibilités ? Sinon le CDSA effectivement a l'air assez intéressant, s'il permet d'éviter les problèmes dont tu parles avec OpenSSL.
Avec l'idée que j'ai actuellement, si tu veux décrypter un fichier, il te faut non seulement désassembler l'algo, mais aussi casser les keychains car tout les paramètres de cryptage qui seraient aléatoires et configurés en partie par l'utilisateur et utilisés par l'algo seraient en sécurité dans les keychains. Donc avoir l'algo sans les paramètres ça serait un peu comme avoir une voiture sans carburant.
En sécurité, un système, c'est comme une chaine en métal.. Le niveau de sécurité du système complet correspond au niveau de sécurité du maillon le plus faible. Tu aura beau protéger la clé avec KeyChain, protéger l'accès à ton ordi avec le top de la biométrie, si ton algo est le point faible c'est celui qui rendra le système le plus vulnérable.. Le maillon sur lequelle un attaquant se penchera en premier..
Donc si tu veux décrypter le fichier, faut casser les keychains...
Justement c'est ca le problème, tu n'as pas forcement besoin des clés pour casser un algo de cryptage (et je parle pas de "force brute").. Et puis le keychain peut être temporairement dévérouillé pendant qu'un cheval de troie recupère des infos?
C'est juste pour dire que la sécurité c'est pas toujours aussi simple qu'on pense..
Tous les créateurs d'un nouveau système de sécurité pensent que leur système est inviolable.. Evidement.. s'ils savait qu'il y avait une vulnérabilité ils l'auraient corrigé (à moins d'avoir de mauvaises intentions).. Mais le problème c'est que les attaquants sont d'autres personnes, avec peut-être des moyens plus grands, une approche différente, etc..
Par exemple, je me rapelle d'un gars qui prétendait que sa protection était la plus sofistiquée sur Atari et qu'elle était incrackable.. Effectivement c'était une des plus complexe que j'ai vu, mais j'ai trouvé qu'en faisant tourner sa protection un contexte particulier on pouvait la craquer en une poignée d'heure.. et c'est ce que j'ai fait.. :-)
En ce qui concerne la soumission du système de cryptage à des audits indépendants, c'est une autre histoire, et je te répondrais que je ne connais pas meilleur audit que les hackers....
Les hackers c'est parfait pour trouver une faille dans un système, mais à mon avis pour trouver une faille dans un algo de cryptage ca prend plutôt des mathematiciens ou des crypto-analystes..
Connais-tu un algo de cryptage propriétaire qui ait resisté? DeCSS, Wifi.. sont des tristes exemples
Alors c'est quoi ton algo? :-)
Quels sont ces problèmes dont tu parles lors des mises à jour d'OpenSSL ? Problèmes de compatibilités ?
Ca vient de la façon dont est linké le programme (j'ai fait un -lcrypto il me semble) .. Si une mise à jour Apple change la library dynamique, l'application peut crasher au lancement
J'ai eut le même problème problème avec libxml peut après la mise à jour vers 10.3.4 (javais compilé en 10.3.4 mais ceux en 10.3.3 ne pouvaient pas lancer l'appli) :
Link (dyld) error:<br /><br />dyld: /Users/class/Desktop/Chmox.app/Contents/MacOS/Chmox version mismatch for library: /usr/lib/libxml2.2.dylib (compatibility version of user: 9.0.0 greater than library's version: 8.0.0)
Bon ca vient peut-être de la façon dont j'ai linké la library.. si quelqu'un à une autre solution (linker en static juste sur certaines libs?) je suis preneur..
Justement c'est ca le problème, tu n'as pas forcement besoin des clés pour casser un algo de cryptage (et je parle pas de "force brute").. Et puis le keychain peut être temporairement dévérouillé pendant qu'un cheval de troie recupère des infos?
Oui tout est possible, je suis bien conscient qu'aucune protection n'est inviolable. :-\
dans 1099654653:
Connais-tu un algo de cryptage propriétaire qui ait resisté? DeCSS, Wifi.. sont des tristes exemples
Alors c'est quoi ton algo? :-)
Mon algo n'a rien à voir avec des usines genre 128 bits (enfin je pense ), tout est dans le paramétrage de l'algo en faites. Ensuite je me contente de faire du brouillage pur et simple.
dans 1099654653:
Ca vient de la façon dont est linké le programme (j'ai fait un -lcrypto il me semble) .. Si une mise à jour Apple change la library dynamique, l'application peut crasher au lancement
Ca me donne pas trop envie d'utiliser OpenSSL ce genre de problème.... ;D Je pense que je regarderais le CDSA le moment venu.
Mon algo n'a rien à voir avec des usines genre 128 bits (enfin je pense ), tout est dans le paramétrage de l'algo en faites. Ensuite je me contente de faire du brouillage pur et simple.
Salut, J'ai un petit soucis de compilation avec xcode 2.1 en mode deployment. Tout se passe bien en mode development... Qui peut m'interpréter ces erreurs :
Tu utilises un framework (en l'occurence Authorization Services) que tu n'as pas inclus dans ton projet XCode.
Sous le mode Development, avec ZeroLink, le linker n'a pas besoin d'accéder à ce framework, puis qu'il utilise les "caches" de ZeroLink.
Par contre , en mode Deployment, point de ZeroLink, d'où les erreurs.
Ajoute le framework (menu Project>add Framework ou add existing files) puis recompile.
Je ne comprends pas. Moi j'ai deux classes qui utilisent ce framework. Mais où se cache t-il? S'il est dans le système, pourquoi avoir besoin de l'attacher au projet?
Je te dirais bien : "c'est comme ça"... mais ce n'est pas une réponse.
Par contre, le linker est plateforme-indépendant. Donc, c'est de ta responsabilité de lui fournir les chemins d'accès vers les portions de code qu'utilise ton projet et qui sont extérieures au-dit projet.
Ces portions de code extérieures, ce sont les bibliothèques dynamiques et les frameworks.
Dans XCode, pour "enregistrer" ces chemins qui seront nécessaires au linker, il suffit d'ajouter les frameworks/bibliothèques au groupe "Frameworks" du projet. (clic-droit>add Frameworks, ou menu Project>add...).
Par défaut, un projet cocoa/objective-c ajoute 2 frameworks de manière automatique : l'Application kit et le Foundation Kit ; mais il en existe plein d'autres (notamment carbon, qui tu dois inclure si tu mixes du carbon et du cocoa dans ton projet).
Par défaut, les frameworks Apple sont localisés dans /System/Library/Frameworks, c'est donc là que tu dois chercher Authorization Service.
C'est juste 2 petits fichiers (un .h et son .m) à ajouter au projet pour bénéficier d'une nouvelle classe KEYCHAINAccess.
Les méthodes :
+ (id)loginKeychain retourne le keychain de la session utilisateur (utilisé par safari, etc...).
+ (id)applicationKeychain retourne un keychain spécialement créé pour l'application. Le keychain se trouve dans /library/application support/nom-du-bundle.
- (BOOL)addGenericPassword:(NSString *)password serviceName:(NSString *)servicename account:(NSString *)account ajoute un password à la rubrique servicename sous-rubrique account.
- (NSString *)passwordForServiceName:(NSString *)servicename account:(NSString *)account récupère un password à la rubrique servicename sous-rubrique account.
- (BOOL)deletePasswordAtServiceName:(NSString *)servicename account:(NSString *)account supprime le password à la rubrique servicename sous-rubrique account.
- (BOOL)modifyAtServiceName:(NSString *)servicename account:(NSString *)account newPassword:(NSString *)password modifie le password à la rubrique servicename sous-rubrique account.
Voilà .
Si vous examinez les sources vous pourrez voir qu'on peu facilement mélanger du C standard, du cocoa et du CoreFoundation dans le même programme !
Bonne prog.
.
Je me permet de remonter le topic car j'aimerai savoir s'il est possible, et si oui, comment faire, d'empêcher l'attribution d'un mot de passe pour le nouveau trousseau créée. Car l'application demande le mot de passe quasiment tout le temps au lancement et c'est chiant :adios!:
Réponses
Mais as-tu cherché? :-)
http://www.openssl.org/
Et qu'est-ce qui te permet d'assurer que ton algo n'est pas crackable sans avoir le mot de passe enregistré dans les keychains?
Je ne met pas en doute tes qualités de developpeur, mais un système de cryptage fiable et éprouvé est un système de cryptage qui a été soumis à des audits independants..
Avec plaisir! :-)
http://www.openssl.org/docs/crypto/crypto.html
Si tu stocke une clé dans KeyChain, alors le plus simple est d'utiliser un algo symétrique comme par exemple BlowFish, AES (utilisé par FileFault selon Apple)..
Les noms des méthodes sont un peu tordus, c'est en partie dû au différents modes de cryptages possibles (ECB, CBC, CFB, OFB...), en fait seule une poignée est nécessaire en fonction du mode choisi..
http://www.openssl.org/docs/crypto/des_modes.html
J'ai trouvé un Framework Objective-C qui encapsule OpenSSL:
http://septicus.com/products/opensource/
Par contre, en fouillant sur le site de l'ADC, j'ai vu qu'Apple recommandais plutôt d'utiliser la Common Data Security Architecture (CDSA) (utilisé par KeyChain Service) pour les applis natives OS X.. (Si la portabilité Unix est recherchée, il vaut mieux utiliser OpenSSL)
Voiçi des exemples de mise en oeuvre de CDSA (en C):
http://developer.apple.com/samplecode/CryptoSample/CryptoSample.html
http://developer.apple.com/darwin/projects/security/
Personnellement, j'avais utilisé OpenSSL dans une appli Cocoa pour créer des "empreintes" SHA-1, mais comme j'ai constaté des problèmes de link lorsqu'OpenSSL est mis à jour (comme c'est déjà arrivé lors de mise à jour de sécurité d'OS X), alors je vais me pencher sur CDSA..
Pour revenir à l'application de stockage de mot de passe, je me demande si ca sera pas plus simple d'utiliser KeyChain pour stocker tous les mots de passes..
Ouch le niveau des discussions...
Tu as raison Nucleus (et ClicCool). Dès que je m'y remets, j'essaierai avec les keychain.
Non je n'ai pas eu le temps, ce n'est pas ma priorité pour l'instant car j'ai bien d'autres chats a fouetter...je fais partis de ceux qui aimeraient avoir des journées de 30 heures.
Et bien nucleus, je suis pas développeur de formation, mais autodidacte, et j'apprends tout sur le tas, pendant mes temps libre. Je crois que je commence à avoir un peu d'expérience depuis le temps...
Avec l'idée que j'ai actuellement, si tu veux décrypter un fichier, il te faut non seulement désassembler l'algo, mais aussi casser les keychains car tout les paramètres de cryptage qui seraient aléatoires et configurés en partie par l'utilisateur et utilisés par l'algo seraient en sécurité dans les keychains. Donc avoir l'algo sans les paramètres ça serait un peu comme avoir une voiture sans carburant.
Donc si tu veux décrypter le fichier, faut casser les keychains...
En ce qui concerne la soumission du système de cryptage à des audits indépendants, c'est une autre histoire, et je te répondrais que je ne connais pas meilleur audit que les hackers....
Merci pour toutes ces informations, le framework a pas l'air mal, il y a même un authorization.framework (Oxitan !
Sinon le CDSA effectivement a l'air assez intéressant, s'il permet d'éviter les problèmes dont tu parles avec OpenSSL.
En sécurité, un système, c'est comme une chaine en métal..
Le niveau de sécurité du système complet correspond au niveau de sécurité du maillon le plus faible.
Tu aura beau protéger la clé avec KeyChain, protéger l'accès à ton ordi avec le top de la biométrie, si ton algo est le point faible c'est celui qui rendra le système le plus vulnérable..
Le maillon sur lequelle un attaquant se penchera en premier..
Justement c'est ca le problème, tu n'as pas forcement besoin des clés pour casser un algo de cryptage (et je parle pas de "force brute")..
Et puis le keychain peut être temporairement dévérouillé pendant qu'un cheval de troie recupère des infos?
C'est juste pour dire que la sécurité c'est pas toujours aussi simple qu'on pense..
Tous les créateurs d'un nouveau système de sécurité pensent que leur système est inviolable.. Evidement.. s'ils savait qu'il y avait une vulnérabilité ils l'auraient corrigé (à moins d'avoir de mauvaises intentions)..
Mais le problème c'est que les attaquants sont d'autres personnes, avec peut-être des moyens plus grands, une approche différente, etc..
Par exemple, je me rapelle d'un gars qui prétendait que sa protection était la plus sofistiquée sur Atari et qu'elle était incrackable.. Effectivement c'était une des plus complexe que j'ai vu, mais j'ai trouvé qu'en faisant tourner sa protection un contexte particulier on pouvait la craquer en une poignée d'heure.. et c'est ce que j'ai fait.. :-)
Les hackers c'est parfait pour trouver une faille dans un système, mais à mon avis pour trouver une faille dans un algo de cryptage ca prend plutôt des mathematiciens ou des crypto-analystes..
Connais-tu un algo de cryptage propriétaire qui ait resisté? DeCSS, Wifi.. sont des tristes exemples
Alors c'est quoi ton algo? :-)
Ca vient de la façon dont est linké le programme (j'ai fait un -lcrypto il me semble) ..
Si une mise à jour Apple change la library dynamique, l'application peut crasher au lancement
J'ai eut le même problème problème avec libxml peut après la mise à jour vers 10.3.4 (javais compilé en 10.3.4 mais ceux en 10.3.3 ne pouvaient pas lancer l'appli) :
Bon ca vient peut-être de la façon dont j'ai linké la library.. si quelqu'un à une autre solution (linker en static juste sur certaines libs?) je suis preneur..
Oui tout est possible, je suis bien conscient qu'aucune protection n'est inviolable. :-\
Mon algo n'a rien à voir avec des usines genre 128 bits (enfin je pense
Ca me donne pas trop envie d'utiliser OpenSSL ce genre de problème.... ;D
Je pense que je regarderais le CDSA le moment venu.
Tu va nous le donner ton algo oui ou non? :P
1->A
1->B
A+B->C
;D ;D ;D
Voilà vous savez tout maintenant.
J'ai un petit soucis de compilation avec xcode 2.1 en mode deployment. Tout se passe bien en mode development...
Qui peut m'interpréter ces erreurs :
[Fichier joint supprimé par l'administrateur]
Tu utilises un framework (en l'occurence Authorization Services) que tu n'as pas inclus dans ton projet XCode.
Sous le mode Development, avec ZeroLink, le linker n'a pas besoin d'accéder à ce framework, puis qu'il utilise les "caches" de ZeroLink.
Par contre , en mode Deployment, point de ZeroLink, d'où les erreurs.
Ajoute le framework (menu Project>add Framework ou add existing files) puis recompile.
.
Moi j'ai deux classes qui utilisent ce framework. Mais où se cache t-il? S'il est dans le système, pourquoi avoir besoin de l'attacher au projet?
Je te dirais bien : "c'est comme ça"... mais ce n'est pas une réponse.
Par contre, le linker est plateforme-indépendant. Donc, c'est de ta responsabilité de lui fournir les chemins d'accès vers les portions de code qu'utilise ton projet et qui sont extérieures au-dit projet.
Ces portions de code extérieures, ce sont les bibliothèques dynamiques et les frameworks.
Dans XCode, pour "enregistrer" ces chemins qui seront nécessaires au linker, il suffit d'ajouter les frameworks/bibliothèques au groupe "Frameworks" du projet. (clic-droit>add Frameworks, ou menu Project>add...).
Par défaut, un projet cocoa/objective-c ajoute 2 frameworks de manière automatique : l'Application kit et le Foundation Kit ; mais il en existe plein d'autres (notamment carbon, qui tu dois inclure si tu mixes du carbon et du cocoa dans ton projet).
Par défaut, les frameworks Apple sont localisés dans /System/Library/Frameworks, c'est donc là que tu dois chercher Authorization Service.
.
En fait, c'est security framework que je dois importer, je chercher un Authorization Framework...
Je me permet de remonter le topic car j'aimerai savoir s'il est possible, et si oui, comment faire, d'empêcher l'attribution d'un mot de passe pour le nouveau trousseau créée. Car l'application demande le mot de passe quasiment tout le temps au lancement et c'est chiant :adios!: