J'ai une application mobile où je voudrais stocker des clés privées de manière sécurisée . L'exigence de sécurité implique qu'il devrait être très difficile pour les attaquants de pouvoir obtenir la clé privée même si elles avaient un accès illimité à l'appareil mobile. Afin d'atteindre ce niveau de sécurité, l'application utilise une cryptographie symétrique avec une clé dérivée d'une phrase secrète spécifiée par l'utilisateur et un sel spécifique à l'appareil.
Idéalement, cela devrait être suffisamment sécurisé contre une attaque de force brute; Cependant, il y a deux facteurs limitatifs:
Étant donné que la clé privée doit être conforme à un certain format, le processus de décryptage peut tester le résultat du processus pour voir s'il est valide ou non. Par exemple, si la clé privée devait être une clé privée RSA, l'attaquant essaierait diverses combinaisons de la phrase secrète et de tester pour voir s'il peut utiliser le texte contraignant résultant en tant que clé privée de RSA valide. Étant donné que la clé privée RSA doit coder certaines informations d'une certaine manière, si le déchiffrement a échoué, le moteur RSA signalerait que la clé n'est pas valide. Cela donne à l'attaquant une façon totalement déconnectée de vérifier ses attaques. De préférence, l'attaquant doit puisque l'application s'exécute sur un appareil mobile, la complexité accrue du fonction de dérivation de clé n'aide pas avec Renforcement des essences depuis une attaque hors ligne qui a pleinement accès au dispositif mobile. vraisemblablement être entrepris sur un appareil plus capable avec des ressources plus riches. Bientôt, toute augmentation du nombre de rondes de calcul de la fonction de dérivation de clé ralentira l'expérience utilisateur (qui acceptait une certaine limite) mais serait immédiatement contrecarrée si l'attaque devait être effectuée sur un ordinateur de bureau.
Quelqu'un pourrait-il me proposer une solution à ces problèmes? Spécifiquement, quelqu'un connaît-il un algorithme de cryptographie asymétrique où la clé privée peut être une séquence d'octets aléatoires (une séquence de longueur fixe peut être une séquence de longueur fixe, et l'algorithme serait toujours en mesure de produire du ciphertext?
3 Réponses :
La clé privée pour RSA est une séquence d'octets aléatoire à longueur fixe. Vous venez de regarder un codage ASCII. Il suffit de stocker la clé dans un format non-ASCII et vous devriez être bon.
Êtes-vous sûr de cela? La clé privée RSA ne code pas un très long numéro composite, ainsi que ses facteurs primaires (je sais que je suis simplement en train de simplement, mais le détail exact n'est pas important)? Si cela fait, le résultat est tout sauf aléatoire car les pièces doivent être cohérentes les unes avec les autres (c'est-à-dire que les facteurs premiers devraient se multiplier pour donner le numéro composite).
Vous avez raison, ce n'est pas totalement aléatoire, certains bits dépendront des autres. Mais cela ne devrait pas être un vrai problème tant qu'il reste suffisamment de bits indépendants (et pour une clé privée qui devrait être une quantité assez importante - je suis à peu près sûr qu'ils ne stockent pas les numéros composites et ses facteurs primordiaux, puisque vous pouvez calculer trivialement le premier en multipliant ces derniers).
Le point Tom Hawtin fait beaucoup plus de problème pour vous, car la clé publique peut être dérivée de la clé privée, toute clé privée candidate que votre méthode de force brute a peut-être découvertes peut être vérifiée de manière triviale en dérivant sa clé publique et en comparant avec la clé publique connue!
Merci, je vois, je n'avais pas pensé à la vérification avec l'étape clé publique. :) Vous avez absolument raison, je pourrais stocker les paramètres de clé privés minimums nains dans un fichier et les nourrir au moteur RSA lorsque j'ai besoin de chiffrer / déchiffrer, de cette façon la clé privée serait suffisamment aléatoire, je suppose. Cependant, j'ai toujours le problème de la clé publique publique. Ainsi, serait-il correct si je ne distribue pas la clé publique mais que je le stocke sur le côté serveur pour correspondre aux demandes? Cela a-t-il un sens?
Ce ne serait plus un Public clé plus ;-) Mais cela vous aiderait certainement dans votre cas. Bien que vous puissiez aussi utiliser un cryptage symétrique alors.
Autre que celui-ci, un serveur pourrait imiter les utilisateurs à un autre serveur si vous avez utilisé des touches symétriques (qui peuvent ou non être une menace).
@CAF a raison. Je ne veux pas descendre de la voie de cryptage symétrique puisque toute attaque sur le serveur révélerait les clés nécessaires à l'impersonate Tous Les utilisateurs. Je voudrais limiter toute exposition du côté serveur telle que ceci. Je suppose que le meilleur moyen est de stocker des clés publiques (qui sont maintenant publiques en ce sens que ce n'est pas une menace, seule, que ces clés sont volées) du côté serveur et envoient des clés privées au client dans un format essentiellement aléatoire (c.-à-d. Pas de format / motif discernable).
L'exigence de sécurité implique qu'il devrait être très difficile pour les attaquants de pouvoir obtenir la clé privée, même si elles avaient un accès illimité à l'appareil mobile.
C'est juste
pas possible . Voici ce qu'un attaquant peut faire:
- Obtenez l'application dans un état où la clé privée doit être chargée en mémoire . L'utilisation régulière de l'application provoquera cela.
- vider le contenu de la mémoire.
- glisser à travers les bits de mémoire essayant toutes les gammes de la longueur de la clé connue.
Étant donné que la clé est en mémoire, peu importe le système intelligent que vous avez proposé de le générer des phrases et des sels de passe. Votre application effectue tout le travail pour l'attaquant. Cas classique d'échec Sécurité via obscurité .
Voici comment Blu-ray était initialement fissuré. Si l'utilisateur dispose d'un accès complet à une mission de mémoire lors de l'utilisation de l'application, il n'y a aucun moyen de les empêcher d'obtenir la clé de cette façon.
Bienvenue dans le monde des DRM.
Merci pour la réponse rapide. Je suis conscient du vecteur d'attaque dont vous parlez et je connais l'histoire de la façon dont la première HD-DVD, puis Bluray a été craquée. Cependant, c'était la raison pour laquelle j'ai dit très dur et non impossible. L'attaque que vous décrivez est très non triviale à effectuer pour un appareil mobile, cependant, un moyen plus facile d'obtenir un dépotoir de stockage et de travailler sur celui-ci au lieu de l'appareil lui-même. C'est le problème que j'essaie de résoudre, peut-être que je n'étais pas aussi clair que j'aurais dû être. Pouvez-vous m'aider avec ça?
La protection contre l'adultération d'un appareil est difficile. De manière raisonnablement, la protection contre le vol n'est pas aussi difficile.
Est-ce que vous développez pour iPhone / Android par une chance? Il existe des simulateurs de logiciels pour ces choses (et probablement pour la plupart des autres plates-formes populaires), ce qui le rend plutôt trivial d'obtenir une mémoire de mémoire de votre application en cours d'exécution ...
@WIM: la même chose pour les appareils BlackBerry et J2ME.
iPhone / Android sont parmi les plates-formes mobiles que je ciblent. Je me rends compte que les émulateurs rendent extrêmement simple d'obtenir une dépectée à mémoire de mémoire, mais que l'attaque vectoriel ne s'applique pas vraiment à mon scénario, car, l'attaquant ne peut pas copier l'application de l'appareil à l'émulateur (au moins le sel spécifié par le L'ID de périphérique unique changerait) et même s'il l'a fait, il ne peut pas obtenir le logiciel dans un état où la clé privée est en mémoire sans une attaque ou un phishing de force brute. Si cette attaque est à l'une de ces choses, il n'a plus d'intérêt pour obtenir des décharges de mémoire de toute façon.
Pensé donc (je ne les téléchargais pas encore moi-même ;-). À peu près sûr, il y a aussi un simulateur Symbian, mais je pense qu'il obtient le point.
Mais la clé privée est la même pour tous les appareils, non? Le sel aide uniquement à diversifier la clé privée cryptée , mais pas la clé en mémoire - une clé privée piratée du simulateur sera la même que celle obtenue à partir d'un appareil réel. Il les empêche de re-chiffrer la clé dans un format que votre application accepte (mais comme ils peuvent déjà lire votre contenu maintenant, cela ne vous aide probablement pas beaucoup).
@WIM: Il n'a pas dit que la même clé privée était utilisée dans chaque appareil. J'ai vu cela proposé dans certains schémas, mais c'est toujours une idée stupide. On dirait que le partycle n'est pas l'une de ces personnes entièrement désemparées qui suggèrent une telle chose; Mon hypothèse est qu'une clé privée unique est générée pour chaque utilisateur, puis protégée par un cryptage symétrique.
Qu'est-ce qui les arrête d'obtenir le sel de l'appareil? Ils peuvent regarder le code exécuté dans le simulateur pour savoir comment vous récupérez le sel. Ensuite, ils peuvent écrire une application qui fait la même chose et l'affiche à l'écran et l'exécute sur l'appareil. Maintenant, dans l'émulateur, ils modifient l'image de la mémoire du sel pour correspondre à celle trouvée sur l'appareil, puis laissez l'application décrypter la clé privée et la saisir de la mémoire. Pas facile. Mais simple une fois qu'ils trouvent les points de rupture droite.
Vous manquez les gars du point. Il n'essaie pas de cacher la clé privée d'un utilisateur légitime de l'appareil (une personne qui a la phrase secrère) - il essaie de le cacher de quelqu'un qui a volé l'appareil d'un utilisateur légitime et fait donc pas avoir la phrase secrète ou l'accès à l'application dans un état de travail.
@sylvarking et @CAF: Vous êtes parfaitement correct. Je pense que j'aurais dû être plus clair dans ma question initiale. Chaque utilisateur fait obtient une clé privée unique protégée par un cryptage symétrique avec une phrase secrète choisie par l'utilisateur. Encore une fois, il est vrai que j'essaie vraiment de protéger contre une attaque brute-force sans un utilisateur légitime autour. Comme @CAF dit, l'attaquant fait pas a l'application dans un état de travail à ce stade. D'autres vecteurs d'attaque (tels que phishing l'utilisateur pour entrer dans la phrase secrète, un logiciel espion / Troie installé sur l'appareil, etc.) ne sont pas dans la portée de ma question.
Très bonne réponse. La personne qui demande cette question ne sait pas ce qu'il fait.
Les chiffres symétriques modernes sont très résistants aux attaques en clairon. Lorsque des attaques ont été découvertes, elles peuvent nécessiter de nombreux plaintes et parfois, les plaintes doivent être correctement sélectionnés.
Ici, l'attaquant a un seul texte partiel. Je supposerais que la charge de travail soit essentiellement une recherche de force brute de l'espace clé. Si la clé symétrique est choisie au hasard dans l'ensemble du clavier, il n'est pas possible pour un attaquant de récupérer la clé privée du CIPHERText.
Les attaques indirectes sont beaucoup plus probables.
Par exemple, quelque chose d'aussi simple que l'ensemble des logiciels espions de la clignotage est suffisant pour vaincre la meilleure cryptographie. Des attaques de mémoire de démarrage à froid ou une analyse du dépotoir central pourraient également être utilisées. Ces risques peuvent être minimisés par des secrets zéro-izing de la mémoire immédiatement après utilisation, mais ils ne peuvent pas être éliminés complètement.
Étant donné que la clé dans ce cas est dérivée d'un mot de passe sélectionné par l'utilisateur, l'espace clé efficace est susceptible d'être beaucoup plus petit que l'espace clé complet. Atténuer cela en nécessitant des mots de passe plus longs qui incluent toutes les classes de caractères. En outre, ne négligez pas le renforcement de la clé. Les recommandations habituelles concernent des milliers d'itérations de la fonction de dérivation de clé, mais même si vous ne pouvez vous permettre que quelques centaines, cela impose un coût de calcul important sur un attaquant.
Merci pour la réponse éclairée. Vous êtes absolument correct que la longueur / la complexité de la phrase secrète limite considérablement l'espace clé. However, le fait qu'il s'agisse d'une application mobile rend plus difficile d'appliquer plus longtemps, ou plus de phrasephrases complexes, puisque la plupart des utilisateurs trouveraient impossible l'utilisation (imaginez avoir à entrer une phrase secrète alphanumérique de 10 caractères sur un périphérique multi-robinet dont vous avez besoin. signer une réponse). J'emploie le renforcement de la clé, mais comme je l'ai dit, si l'expérience utilisateur sur l'appareil n'est pas ralentie grandement, le coût supplémentaire sera relativement petit sur un attaquant travaillant sur un bureau.
(suite) Il reste le problème de l'attaquant pouvant être capable de Vérifier la validité du texte déchiffré purement déconnecté. Pour que l'attaque de la force brute fonctionne avec succès, l'attaquant devrait pouvoir dire si le clairext est correct ou non. Ainsi, si le texte en clair (clé privée) a un motif (au format PEM) ou peut être introduit dans une boîte en blackbox (le moteur RSA) qui échouera pour un texte en clair non valide, l'attaquant peut vérifier la validité du déchiffrement. Ce que je suis après est une méthode qui obligera l'attaquant à signer quelque chose avec le plaintext et à l'envoyer au serveur, à valider le plaintext.
Je résumerais les commentaires clarifiants: "La clé symétrique est trop petite pour se protéger contre une attaque de force brute." Compte tenu des contraintes sur la taille et la complexité du mot de passe, obtenir 64 bits d 'entropie ressemble à un étirement. Malheureusement, je ne peux pas recommander une alternative à laquelle implique un serveur. Je ne connais pas d'une méthode existante et tout ce que j'ai imaginé semble exposer trop d'informations à mesure qu'il voyage sur le réseau. Je vais continuer à y penser.
Vous savez assez pour être dangereux pour vous-même. Prenez une copie de la cryptographie pratique et lisez-la du couvercle pour couvrir.