Quelles mines de sécurité dois-je surveiller avec JCA et AES?

Question

J'utilise l'API Java Cryptography avec AES pour crypter de courtes chaînes de texte à utiliser dans les cookies identifiant les utilisateurs. Je crois comprendre que certains algorithmes de chiffrement ne sont pas sécurisés lorsqu'ils sont utilisés avec de petites quantités de texte par rapport à la taille de la clé. Que dois-je savoir pour m'assurer que je ne laisse pas mes données non sécurisées? Dois-je m'assurer que la chaîne à chiffrer est plus longue que la clé? Y a-t-il d'autres mines terrestres?

Pour générer une clé que je fais ce qui suit avec encryptionType = "AES" et keySize = 128:

public SecretKey createKey() throws NoSuchAlgorithmException { 
    KeyGenerator keyGen = KeyGenerator.getInstance(encryptionType); 
    keyGen.init(keySize); // 192 and 256 bits may not be available 
    return keyGen.generateKey(); 
} 

public String encrypt(Key key, String str) throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, UnsupportedEncodingException, IllegalBlockSizeException, BadPaddingException { 
    Cipher ecipher = Cipher.getInstance(encryptionType); 
    ecipher.init(Cipher.ENCRYPT_MODE, key); 
    byte[] utf8 = str.getBytes("UTF8"); 
    byte[] enc = ecipher.doFinal(utf8); 
    return new BASE64Encoder().encode(enc); 
} 

public String decrypt(Key key, String str) throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, IOException, IllegalBlockSizeException, BadPaddingException { 
    Cipher dcipher = Cipher.getInstance(encryptionType); 
    dcipher.init(Cipher.DECRYPT_MODE, key); 
    byte[] dec = new BASE64Decoder().decodeBuffer(str); 
    byte[] utf8 = dcipher.doFinal(dec); 
    return new String(utf8, "UTF8"); 
} 

Answer 1

Vous aurez besoin de vous familiariser avec les principes de la conception d'un système sécurisé, qui va au-delà de choisir un algorithme de chiffrement particulier.

En principe, AES est conçu pour sécuriser le cryptage des paquets dans leur plus petite taille (16 octets). Mais vous devez faire attention à son utilisation dans le schéma de sécurité globale. Faites attention à la conception de votre protocole global. Par exemple, j'ai déjà entendu parler d'un jeu en ligne dans le passé (impossible de trouver une référence désolé), qui a crypté toutes ses données. Le problème était, il n'a pas inclus de "graine". Donc la commande de faire quelque chose en particulier, comme donner au joueur une vie supplémentaire, était la même séquence d'octets (cryptés) à chaque fois. Ainsi, un joueur pourrait simplement dupliquer ce paquet, et le renvoyer plusieurs fois au serveur, sans jamais avoir à connaître les données non cryptées contenues dans le paquet.

Answer 2

Vous pouvez commencer par cette liste de Top 25 Most Dangerous Software Errors, qui fait spécifiquement référence aux erreurs de sécurité.

Answer 3

Alors que les messages courts nécessiteront un remplissage, la question ne dit rien sur le remplissage à utiliser. Le choix du remplissage pourrait affecter la sécurité de certains chiffrements.

De même, aucun mode de chiffrement n'est spécifié dans la question. Pour des "messages" aléatoires courts, tels que des identifiants d'utilisateur choisis au hasard, le mode ECB est sécurisé et présente l'avantage qu'aucun vecteur d'initialisation n'est nécessaire pour le chiffrement. Pour les messages de plus de 16 octets, cependant, l'utilisation du mode ECB peut révéler des motifs dans le texte en clair et est vulnérable aux attaques de relecture.

L'utilisation d'autres modes (CBC est commun) nécessitera un vecteur d'initialisation différent pour chaque message. De toute évidence, le décryptage nécessitera l'IV, et cela conduit généralement à le faire circuler avec le texte chiffré.