Comment implémenter le cryptage AES Java 256 bits avec CBC
J'ai lu les threads suivants et ils ont aidé un peu, mais je suis à la recherche d'un peu plus d'infos.
Fondamentalement, ce que je suis en train de faire est d'écrire un programme qui permet de chiffrer une demande afin d'être envoyés sur TCP/IP, puis déchiffré par un programme serveur. Le codage doivent être AES, et en faisant quelques recherches, j'ai découvert que j'avais besoin d'utiliser la SRC et PKCS5Padding. Donc en gros j'ai besoin d'une clé secrète et un IV ainsi.
L'application que je suis en développement est pour un téléphone, donc je veux utiliser le java logiciels de sécurité pour maintenir la taille vers le bas. J'ai le design, mais pas sûr de la mise en œuvre de la IV et la clé partagée.
Voici un code:
//My user name
byte[] loginId = "login".getBytes();
byte[] preSharedKey128 = "ACME-1234AC".getBytes();
byte[] preSharedKey192 = "ACME-1234ACME-1234A".getBytes();
//256 bit key
byte[] preSharedKey256 = "ACME-1234ACME-1234ACME-1234".getBytes();
byte[] preSharedKey = preSharedKey256;
//Initialization Vector
//Required for CBC
byte[] iv ={0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00};
IvParameterSpec ips = new IvParameterSpec(iv);
byte[] encodedKey = new byte[loginId.length + preSharedKey.length];
System.arraycopy(loginId, 0, encodedKey, 0, loginId.length);
System.arraycopy(preSharedKey, 0, encodedKey, loginId.length, preSharedKey.length);
//The SecretKeySpec provides a mechanism for application-specific generation
//of cryptography keys for consumption by the Java Crypto classes.
//Create a key specification first, based on our key input.
SecretKey aesKey = new SecretKeySpec(encodedKey, "AES");
//Create a Cipher for encrypting the data using the key we created.
Cipher encryptCipher;
encryptCipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
//Initialize the Cipher with key and parameters
encryptCipher.init(Cipher.ENCRYPT_MODE, aesKey, ips);
//Our cleartext
String clearString = "33,8244000,9999,411,5012022517,0.00,0,1,V330";
byte[] cleartext = clearString.getBytes();
//Encrypt the cleartext
byte[] ciphertext = encryptCipher.doFinal(cleartext);
//Now decrypt back again...
//Decryption cipher
Cipher decryptCipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
//Initialize PBE Cipher with key and parameters
decryptCipher.init(Cipher.DECRYPT_MODE, aesKey, ips);
//Decrypt the cleartext
byte[] deciphertext = decryptCipher.doFinal(ciphertext);En un mot ce qu'il doit faire est de chiffrer un message qui peut décrypté par le serveur sans serveur besoin d'obtenir une clé ou IV à partir du téléphone. Est-il une manière que je pourrais le faire si je pouvais fixer le IV et la clé sur le téléphone, et toujours avoir la clé et IV connues par le serveur? Hésitez pas à me dire pour rendre les choses plus claires si elles ne le sont pas.
source d'informationauteur Stevus
Vous devez vous connecter pour publier un commentaire.
Il y a quelques problèmes avec le code. Tout d'abord, vous devriez vraiment utiliser un générateur de clé pour générer des clés secrètes. Juste à l'aide du texte directement pourrait fonctionner pour certains algorithmes, mais d'autres ont des clés faibles et ainsi de suite qui ont besoin d'être testé.
Même si vous voulez faire du chiffrement par mot de passe, le mot de passe par le biais d'un algorithme de dérivation pour produire une clé, comme indiqué dans ma réponse à la question que vous avez déjà cité.
Aussi, vous ne devriez pas utiliser le pas-arg
getBytes()méthode deString. C'est dépendants de la plateforme. Si toutes les chaînes que vous êtes encodage contenir uniquement des caractères de l'caractères US-ASCII, en précisant que l'encodage explicite. Sinon, si le téléphone et le serveur de plates-formes utilisent différents encodages de caractères, la clé et IV n'est pas le même.Pour le mode CBC, il est préférable d'utiliser une nouvelle IV pour chaque message que vous envoyez. Généralement, CBC IVs sont générées aléatoirement. D'autres modes de transport comme le CFB et OFB besoin Vi uniques pour chaque message. IVs sont généralement envoyés sur le cryptogramme—IVs n'avez pas besoin d'être gardé secret, mais de nombreux algorithmes se cassent si prévisible IV.
Le serveur n'a pas besoin d'obtenir le secret ou IV, directement depuis le téléphone. Vous peut configurer le serveur avec la clé secrète (ou mot de passe, à partir de laquelle la clé secrète est dérivé), mais dans de nombreux cas, ce serait une mauvaise conception.
Par exemple, si l'application va être déployée pour les téléphones de plusieurs personnes, il n'est pas une bonne idée pour eux d'utiliser la même clé secrète. Un utilisateur malveillant peut récupérer la clé et de briser le système pour tout le monde.
Une meilleure approche est de générer de nouvelles clés secrètes au téléphone, et l'utilisation d'un accord de clé de l'algorithme d'échange de clés du serveur. L'échange de clés Diffie-Hellman accord peut être utilisé pour cela, ou la clé secrète peut être chiffré avec RSA et envoyés au serveur.
Mise à jour:
L'échange de clés Diffie-Hellman dans "éphémère-statique de la mode" (et "statique statique" mode trop, même si c'est moins souhaitable) est possible sans un message initial à partir du serveur au téléphone, aussi longtemps que la clé publique du serveur est intégré dans l'application.
La clé publique du serveur ne pose pas le même risque que l'incorporation d'une commune de la clé secrète dans le téléphone. Puisque c'est une clé publique, la menace serait un attaquant d'obtenir ses mains sur (ou à distance pirater), le téléphone et le remplacement de la vraie clé publique avec une fausse clé qui lui permet d'usurper l'identité du serveur.
Statique statique de la mode peut être utilisé, mais il est en fait plus compliqué et un peu moins en sécurité. Chaque téléphone doit disposer de sa propre et unique paire de clés, ou vous tomber en arrière dans le secret de la clé du problème. Au moins il n'y aurait pas besoin pour le serveur de garder une trace de téléphone a la clé (en supposant qu'il existe certaines mécanisme d'authentification au niveau de l'application, comme un mot de passe).
Je ne sais pas à quelle vitesse les téléphones. Sur mon bureau, en générant une clé éphémère paire prend environ 1/3 de seconde. Génération de clés Diffie-Hellman paramètres est très lent; vous auriez certainement envie de ré-utiliser les paramètres de la clé du serveur.
Fait des projets similaires dans un midlet avant, j'ai des conseils suivants pour vous: