Pièges du code cryptographique

Question

Je modifie le code de sécurité existant. Les spécifications sont assez claires, il y a un exemple de code, mais je ne suis pas un expert en cryptographie. En fait, le code de l'exemple comporte une clause de non-responsabilité indiquant en effet & "N'utilisez pas ce code mot à mot. &";

Lors de l'audit du code, je dois modifier (ce qui est censé être une fonctionnalité complète), j'ai rencontré ce petit bijou utilisé pour générer le défi:

static uint16 randomSeed;

...

uint16 GetRandomValue(void)
{
  return randomSeed++;/* This is not a good example of very random generation :o) */
}

Bien sûr, la première chose que j’ai tout de suite faite, c’est de le faire circuler au bureau pour que nous puissions tous nous marrer.

Le programmeur qui a produit ce code savait que ce n'était pas un bon algorithme (comme l'indique le commentaire), mais je ne pense pas qu'ils aient compris les implications en termes de sécurité. Ils ne se sont même pas donné la peine de s’appeler dans la boucle principale pour que cela devienne au moins un compteur de course gratuit - ce n’est toujours pas idéal, mais des mondes plus lointains.

Cependant, je sais que le code que je produis va également provoquer un glouton ou un tremblement de terre chez un vrai gourou de la sécurité.

• Quels sont les problèmes de sécurité les plus courants, spécifiques à la cryptographie, que je dois comprendre?
• Quelles sont certaines des bonnes ressources qui me donneront des connaissances appropriées sur ce que je devrais savoir au-delà des erreurs courantes?

-Adam

Answer 1

Cryptographie appliquée est un excellent livre pour vous aider à comprendre la cryptographie et le code. Il aborde de nombreux aspects fondamentaux, tels que le fonctionnement des chiffreurs de blocs et pourquoi choisir un mode de chiffrement médiocre rendra votre code inutile, même si vous utilisez une version d'AES parfaitement implémentée.

Certaines choses à surveiller:

• de mauvaises sources d'aléatoire
• Essayez de concevoir votre propre algorithme ou protocole - ne le faites pas, jamais.
• Le code n'a pas été revu. De préférence en le publiant en ligne.
• N'utilisez pas une bibliothèque bien établie et essayez de l'écrire vous-même.
• La crypto comme panacée - le cryptage des données ne le protège pas comme par magie
• Gestion des clés. De nos jours, il est souvent plus facile de voler la clé avec une attaque par canal latéral que d’attaquer le crypto.

Answer 2

N'essayez pas de rouler vous-même - utilisez une bibliothèque standard autant que possible. Des modifications subtiles du code de sécurité peuvent avoir un impact énorme qui n'est pas facile à détecter, mais peut ouvrir des failles de sécurité. Par exemple, deux lignes modifiées dans une bibliothèque ont ouvert un trou qui ' t facilement apparente pendant un certain temps.

Answer 3

Votre question montre l’un des problèmes les plus courants: les mauvaises sources d’aléatoire. Peu importe que vous utilisiez une clé de 256 bits s’ils ne sont pas assez aléatoires.

Le numéro 2 suppose probablement que vous pouvez concevoir un système mieux que les experts. C’est un domaine dans lequel une mise en œuvre de qualité d’une norme sera certainement meilleure que l’innovation. N'oubliez pas qu'il a fallu 3 versions principales pour que SSL soit vraiment sécurisé. Nous pensons.

Answer 4

IMHO, il y a quatre niveaux d'attaques dont vous devez être conscient:

1. attaques d'ingénierie sociale. Vous devez former vos utilisateurs à ne pas faire de bêtises et à écrire votre logiciel de telle sorte qu'il est difficile pour les utilisateurs de faire des bêtises. Je ne connais aucune bonne référence à ce sujet.

2. n'exécute pas de code arbitraire (débordements de tampon, exploits xss, injection SQL sont tous regroupés ici). La chose minimale à faire pour en savoir plus à ce sujet est de lire la rédaction d'un code sécurisé de quelqu'un chez MS et de visionner le discours technique de Google sur la rupture du logiciel Web. Cela devrait également vous apprendre un peu sur la défense en profondeur.

3. attaques logiques. Si votre code manipule du texte brut, des certificats, des signatures, des textes chiffrés, des clés publiques ou tout autre objet cryptographique, vous devez savoir que le traitement incorrect peut entraîner de mauvaises choses. Les éléments minimaux que vous devez connaître comprennent les attaques hors ligne & Avec le dictionnaire en ligne, les attaques par rejeu, les attaques par intercepteur. http://www.soe.ucsc.edu/~abadi/Papers/gep-ieee.ps

4. attaques cryptographiques. Les vulnérabilités cryptographiques incluent:

   • éléments que vous pouvez éviter: génération de nombres aléatoires incorrecte, utilisation d'une fonction de hachage cassée, implémentation cassée d'une primitive de sécurité (par exemple, ingénieur oublie un -1 dans le code, ce qui rend la fonction de chiffrement réversible)
   • ce que vous ne pouvez pas éviter sauf en étant aussi à jour que possible: nouvelle attaque contre une fonction de hachage ou une fonction de cryptage (voir, par exemple, conversation MD5 récente), nouvelle technique d'attaque (voir, par exemple, les attaques récentes contre des protocoles d'envoi crypté). voix sur le réseau)

Cryptographie appliquée devrait en général constituer une bonne référence.

De plus, il est très préoccupant pour moi que les éléments stockés sur un appareil mobile, probablement verrouillé et difficile à mettre à jour, soient écrits par quelqu'un qui pose des questions sur la sécurité lors du stackoverflow. Je crois que votre cas serait l’un des rares cas où vous aurez besoin d’un (bon) consultant externe qui vous aidera à obtenir les détails voulus. Même si vous faites appel à un consultant en sécurité, ce que je vous recommande de faire, veuillez également lire les références ci-dessus (minimalistes).

Answer 5

  

Quels sont les problèmes de sécurité les plus courants, spécifiques à la cryptographie, que je dois comprendre?

Facile - vous (1) n'êtes pas assez intelligent pour créer votre propre algorithme.

(1) Et par vous, je parle de vous, de moi et de tous les autres lecteurs de ce site ... sauf peut-être de Alan. Kay et Jon Skeet .

Answer 6

Je ne suis pas un crypto non plus, mais les S-box peuvent être gênants quand ils sont dérangés (et ils font une différence). Vous avez également besoin d'une véritable source d'entropie, pas seulement d'un PRNG (peu importe son apparence). Les PRNG sont inutiles. Ensuite, vous devez vous assurer que la source d'entropie n'est pas déterministe et qu'elle ne peut pas être altérée.

Mon humble conseil est le suivant: respectez les algorithmes de cryptage connus, à moins d’être un expert et d’en comprendre les risques. Vous pourriez avoir intérêt à utiliser un code de source ouverte / domaine public testé et disponible au public.