Discussion :

[oieretxe]

Bonjour,

je viens de trouver un exemple de chiffrement RSA sous Android et j'aurais aimé savoir si c'était la bonne méthode comparé à la description faite sur ce lien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
import java.security.Key;
import java.security.KeyPair;
import java.security.KeyPairGenerator;
 
import javax.crypto.Cipher;
 
import android.app.Activity;
import android.os.Bundle;
import android.util.Base64;
import android.util.Log;
import android.widget.TextView;
 
public class AsymmetricAlgorithmRSA extends Activity {
	static final String TAG = "AsymmetricAlgorithmRSA";
 
	@Override
	public void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
 
		setContentView(R.layout.asym);
 
		// Original text
		String theTestText = "This is just a simple test!";
		TextView tvorig = (TextView)findViewById(R.id.tvorig);
		tvorig.setText("\n[ORIGINAL]:\n" + theTestText + "\n");
 
		// Generate key pair for 1024-bit RSA encryption and decryption
		Key publicKey = null;
		Key privateKey = null;
		try {
			KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
			kpg.initialize(1024);
			KeyPair kp = kpg.genKeyPair();
			publicKey = kp.getPublic();
			privateKey = kp.getPrivate();		
		} catch (Exception e) {
			Log.e(TAG, "RSA key pair error");
		}
 
		// Encode the original data with RSA public key
		byte[] encodedBytes = null;
		try {
			Cipher c = Cipher.getInstance("RSA");
			c.init(Cipher.ENCRYPT_MODE, publicKey);
			encodedBytes = c.doFinal(theTestText.getBytes());
		} catch (Exception e) {
			Log.e(TAG, "RSA encryption error");
		}		
		TextView tvencoded = (TextView)findViewById(R.id.tvencoded);
		tvencoded.setText("[ENCODED]:\n" + 
				Base64.encodeToString(encodedBytes, Base64.DEFAULT) + "\n");
 
		// Decode the encoded data with RSA private key
		byte[] decodedBytes = null;
		try {
			Cipher c = Cipher.getInstance("RSA");
			c.init(Cipher.DECRYPT_MODE, privateKey);
			decodedBytes = c.doFinal(encodedBytes);
		} catch (Exception e) {
			Log.e(TAG, "RSA decryption error");
		}		
		TextView tvdecoded = (TextView)findViewById(R.id.tvdecoded);
		tvdecoded.setText("[DECODED]:\n" + new String(decodedBytes) + "\n");
	}
}

D'autre part, j'aimerais ne pas générer des clés à chaque fois car j'aimerai envoyer ma clé publique à d'autre device pour qu'ils puissent m'envoyer des messages.
Du coup, j'aimerais stocker ces clés dans le téléphone, mais de manière sécurisée. J'ai entendu que des applications stockent des données dans la carte SIM pour les sécuriser, mais je n'ai pas trouvé le moyen de le faire. Une idée ?

Merci d'avance !

[Flodelarab]

Bonjour,

Qu'entends-tu par "sécurisé" ? Ca relève plus de la parano que de la sécurité

La clé privée est destinée à n'être jamais transmise, donc stockée à l'endroit de production. La clé publique n'a aucune importance; tu peux la diffuser largement.

Dans la théorie, une chaîne de sécurité a la résistance du maillon le plus faible. Si tu te mets à considérer ton téléphone comme peu sûr, ton cryptage n'aura pas la résistance de RSA mais la résistance du système que tu mets en place pour protéger la clé privée...
J'ajoute que cette clé privée doit être utilisable (pour recevoir des messages) donc tu ne va pas imaginer un coffre-fort inviolable, car il faudra toujours l'ouvrir.

[oieretxe]

D'accord je comprends,

Une dernière petite question : lorsqu'on sauvegarde des données à l'aide de SharedPreferences, ces données sont-elles facilement lisibles ? Accessibles ?
Oui j'avoue que ça ressemble un peu à de la parano, mais j'aimerai rendre mon projet "fiable" en apportant le maximum d'élément sécuritaire que je peux, à la limite du raisonnable bien sûr

[nicroman]

En fait... si c'est possible....

On a deux entités: A et B
Aucune des deux n'est "sûre".
Mais on veut sécuriser un dialogue entre A et B.

Le principe est simple:
à chaque "communication", A génère une clé privée / clé publique, et envoie la clé publique à B
cette clé privée étant unique pour une communication, elle n'est pas stockée.

Le problème est maintenant qu'une entité C peut se faire passer pour A ou B.
On revient donc à une problème d'authentification.
Et ce ne peut être fait que par un organisme O (commun à A et B) qui va certifier que A (ou B) ne sont pas C.
La communication avec O se fait par le même principe, sauf que la clé privée de O n'est connue que par O, et la clé publique de O est connue par tout le monde (c'est le principe des "certificats").

A noter qu'on n'a pas parlé de smartphone, mais d'entité... A peut être un logiciel, et B un site web... ou deux logiciels sur le même téléphone... bref... il faut à un moment une authorité de certification: O

[oieretxe]

En fait moi ce que je pensais mettre en place pour l'authentification c'est ceci :
- L'entité A créé 1 clé privée Kpriv_A et une clé publique Kpub_A, ainsi qu'un nombre aléatoire Alea_A
- L'entité B créé 1 clé privée Kpriv_B et une clé publique Kpub_B, ainsi qu'un nombre aléatoire Alea_B
- Les deux entités s'échangent leur clé publique, puis envoient leur nombre aléatoire chiffré avec la clé publique reçu
- Les deux entités déchiffrent le nombre aléatoire chiffré reçu avec leur clé privée, puis le multiplie (ou autre opération) avec leur propre nombre aléatoire
- Les deux entités s'échangent le résultat de l'opération en le chiffrant
- Si le résultat obtenue est le même que celui qui est calculé, alors ça signifie que les deux entités sont authentifiés.

Le risque peut donc survenir lors de l'échange des clés publiques, mais sinon ça doit fonctionner non ?

[Flodelarab]

à chaque "communication", A génère une clé privée / clé publique, et envoie la clé publique à B
cette clé privée étant unique pour une communication, elle n'est pas stockée.

Elle n'est pas stockée ? Alors quand B crypte avec la clé publique de A le message pour A, comment A décrypte-t-il le message puisqu'il a jeté la clé privée ?
Quel intérêt de générer une clé privée, si c'est pour la jeter ?

@oieretxe: Les objections ne sont que théoriques. Ton processus est globalement bon. Mais quand A et B utilisent la clé reçue, ils pré-supposent qu'ils ont la bonne clé. Donc la vérification que tu proposes est caduque.
Par exemple, si C se met entre A et B, C donnera à A et B ce qu'ils attendent (en l'occurence, une clé publique), et C suivra tranquillement tous les échangent de manière transparente pour A et B. Voilà pourquoi nicroman parle de certificats et d'authentification. Mais moi, je te souligne qu'à partir du moment où A et B utilisent les clés, c'est qu'ils ont confiance en elles. Donc pas de vérification.

[oieretxe]

Justement pour s'assurer que les clés publiques reçus proviennent d'utilisateurs autorisés, je pensais faire comme ceci :
L'entité A est un smartphone, et l'entité B un microcontrôleur.
- L'entité A entame la conversation avec B, en lui signalant que les clés n'ont pas encore été changés
- L'entité B lui envoi sa clé publique, et demande à ce que l'utilisateur de l'entité A entre un code (que seul lui peut connaitre car c'est un utilisateur autorisé) sur le smartphone, puis envoie ce code chiffré avec la clé publique de B
- L'entité B déchiffre le code reçu, et s'il est correcte (le code est donc stocké en dur dans le microcontrôleur), il accepte de recevoir la clé publique de A car il saura que c'est un utilisateur autorisé, sinon il coupe la communication
Des failles dans mon plan ?

Sinon tu parles d'entité C qui viendrait se placer entre A et B. Moi je vais partir sur un échange par liaison Bluetooth, et je sais que ce genre d'attaque par man in the middle existe, mais est-il facile à mettre en place ? Le système d'appairage entre les périphériques gêne considérablement ce type d'attaque non ?

Merci pour votre aide en tout cas

[Flodelarab]

Pour le Bluetooth, je ne sais pas. C'est pour ça que je dis que c'est théorique.

Pour ton procédé, tu sembles vouloir faire un système de signature plutôt que de transmission sécurisée. Non?
Pour la signature, on crypte avec la clé privée et on décrypte avec la clé publique.
Pour la transmission sécurisée des données, on crypte avec la clé publique et on décrypte avec la clé privée.

[oieretxe]

En effet je pense que je mélange un peu les deux là.
Je vais poser ça plus clairement et réfléchir à la méthode que je vais appliquer. Parce qu'en fait je voudrais tout d'abord réaliser un système de signature, puis de transmission sécurisée ^^

Je reviens vers vous dès que tout ça est clair

[Flodelarab]

un système de signature, puis de transmission sécurisée ^^

Logique. Tout peut être fait avec seulement 2 clés.

Un certificat, c'est une identité, une clé, et les signatures de tous les "tiers de confiance", c'est-à-dire ceux qui attestent que le certificat est valide. Il suffit qu'un seul tiers de confiance que tu juges bon soit présent pour que le certificat soit bon. Mais s'il n'y en a pas, même si le certificat est signé 1000 fois, il ne vaut rien. Il faut alors rejeter la clé.
Dans la vie, personne n'ayant défini les humains ou organisations en qui il avait confiance, le système RSA n'est en fait pas totalement sûr. On s'en remet à des organismes publiques, ce qui limite les fraudes. Mais le problème demeure.

Voilà pourquoi on observe des professionnels qui génèrent des clés en se moquant des certificats. Time is money.

Pour finir, les serveurs ssh permettent l'exécution de commandes shell sur un ordinateur distant. On peut déposer sa clé publique sur le serveur, ce qui dispense d'authentification les personnes autorisées. Sans doute, tu pourrais t'en inspirer.