Cryptographie

Besoin

Définir un ensemble des techniques permettant de fournir :

Implémentation

Java offre des API cryptographiques mettant en œuvre :

authentification : savoir d'où vient un code
intégrité : garantir qu'un message (code ou autre) n'a pas été modifié
confidentialité : chiffrer le transit
Non-rejouabilité : Même en ne comprenant rien aux messages échangés entre deux parties, une partie intermédiaire peut toujours enregistrer ces messages pour les réémettre ("rejouer") ensuite. Il est donc important de toujours introduire une partie variable dans chaque message (identifiant de session ou token, fonction du temps...) et d'éviter l'utilisation de mots de passe constants et donc rejouables, que l'on préférera remplacer par des systèmes d'authentification non-rejouables (one-time password, etc.)

Domaine	Paradigme	Release	1	2	Commentaire
		Version	1		Commentaire
	Permission		Par nature (fonction de la provenance du code)
Cryptographie	JCA		Signatures et condensés de messages uniquement.	Oui
		JCE		1.1
		Signature	Stockage	Base de la sandbox	Indissociable du code
		Implémentations		JDK	Pluggable	API cryptographiques standardisées et donc pluggables et interopérables
	Identité		Classe `java. security. Identity`	Interface `java. security. Principal`

Afin de permettre à tout éditeur de fournir une implémentationd'un ou de plusieurs concepts de sécurité introduits dans Java2, tout classe de sécurité générique (engineclass) est implémentée sous forme de fabrique (factory)retournant les implémentations paramétrées dans la plate-forme (on retrouve là le modèle de SPI)

Tout fournisseur est effectivement susceptible de ne pas implémenterun protocole demandé par une application (il pourra fournir une implémentation de signature RSA/MD2 mais pas de RSA/MD5 par exemple). Il est donc possibled'installer dans la plate-forme plusieurs implémentations des classes de sécurité, avec un ordre de préférence. Pour un algorithme donné, la première implémentation trouvée dans cette liste de préférence sera utilisée. Il est également possible pour une application de spécifier son fournisseur de prédilectionpar programmation.

Les concepts implémentables par un fournisseur sont :

les clés publiques et privées (génération DSA ou RSA, mapping sur une clé abstraite)
les condensés de message (MD2, MD5, SHA)
les signatures (DSA + SHA, RSA + MD5...)
les certificats (X.509) et leurs listes de révocation (CRL)
la base locale d'informations sur les clés et certificats (permettant différentes implémentation du stockage, sur une carte à puce, sur un Java Ring, par exemple)
Paramètres d'algorithme
Générateur de paramètres d'algorithme
Générateur de nombres aléatoire

Base de clés

L'implémentation par défaut de la base de clés est la base "JKS" de Sun. Cette implémentationeffectue la persistance de l'objet java.security.KeyStore dansun fichier au format propriétaire.

Sun fournit de plus dans le JDK 1.2 l'outil keytool, qui permetun accès utilisateur (bien qu'en ligne de commande) à un objetKeyStore stocké dans un tel fichier.

Si l'on utilise la base de clé JKS de Sun, le fichier chargépar défaut par la plate-forme (et par keytool) est par ordre de préférence :

le fichier .keystore trouvé dans le répertoire HOME de l'utilisateur courant (d:\WINNT\Profiles\Administrateur par exemple, mais c'est à l'utilisateur de le créer)
le fichier spécifié par :
1. l'entrée keystore du fichier %JAVA_HOME%/lib/security/java.policy
2. l'entrée keystore du fichier %HOME%/.java.policy

Il est cependant possible d'utiliser une autre implémentation de KeyStore installée, soit :

en modifiant les entrées correspondantes dans le fichier java.security (keystore.type définit le KeyStore JKS comme KeyStore par défaut)
soit par programmation via la fabrique de base de clé (KeyStore myKeyStore = KeyStore.getInstance (keystoreType, keystoreProvider)).

Limitations

L'approche cryptographique n'est pas suffisante en elle-même pour assurer une sécurité. D'autres aspects doivent être pris en compte (architecture, langage, OS).

Notes

À partir de en mars 1998, le chiffrement "fort" (utilisant des clés de plus de 40 bits) peut être (enfin) autorisé s'il est déclaré auprès d'un "tiers de confiance", une société agréée "secret-défense" tenue de révéler le secret de ses coffres aux militaires (on doit y déposer les clés utilisées). Il n'existe en fait qu'une société de ce type en France : Trithème, filiale de Thomson-CSF. Le le mardi 19 janvier 1999, le 1er ministre annonce qu'un décret de février va porter la limite du chiffrement libre de 40 (déchiffrable en 2 semaines avec un PC) à 128 bits. Cependant, des accords internationaux (accords de Wassenaar signés en décembre 1998) interdisent l'exportation de logiciels de chiffrement utilisant des clés supérieures à 56 bits. On a donc le droit de crypter, mais avec des logiciels nationaux (ce qui n'est pas le cas de PGP par exemple).
Comme pour les plugins, le modèle de sécurité ActiveX autorise tout par défaut (non signé), alors que Java n'autorise rien par défaut. ActiveX repose entièrement sur le jugement de l'utilisateur. Lorsqu'une fenêtre s'affiche en indiquant que Verisign garantit que Joe Schmoe est bien l'auteur du programme téléchargé, on ne peut prendre de décision raisonnable si l'on ne sait pas qui est Joe Schmoe.

RIPEMD-160

Acronyme pour RIPE Message Digest, algorithme de hâchage permettant de générer des condensés de messages.

RIPEMD-160 ou SHA sont considérés comme plus sûr que MD5, dans la mesure ou MD5 a été cassé (pour des messages courts cependant). RSA elle-même ne recommande plus l'utilisation de MD5.

RNG

Acronyme pour Random Number Generation, algorithme sécurisé de génération de nombres aléatoires (non périodiques), utilisés pour la génération de clés.

Java 2 ne fournit qu'une implémentation de nombres pseudo-aléatoires (PRNG).

PRNG

Acronyme pour Pseudo Random Number Generation, algorithme sécurisé de génération de nombres pseudo-aléatoires (pérodiques), utilisé pour la génération de clés.

Java 2 inclut une implémentation de PRNG, via le générateur java.security.SecureRandom.

SET

Acronyme pour Secure Electronic Transactions.

Protocole de commerce électronique situé au-dessus de SSL, permettant les authentifications des clients porteurs de cartes de crédit, des commerçants et des fournisseurs, l'intégrité et la confidentialité des informations de paiement (du client vers le commerçant) et de commande (du commerçant vers le fournisseur).

Comme SSL, SET exploite les certificats X509.

TIPEM

Acronyme pour Toolkit for Interoperable Privacy Ehanced Mail, librarie de RSA permettant de développer des produits intégrant S/MIME dans les applications de courrier électronique.

Voir

IBM Java Education - White Papers, Tutorial and articles - Security
Securing Java
Adresses de courrier électronique
- JavaSoft Forum
- Java Security Team
FAQ
- W3C Security FAQ
- JavaSoft Frequently Asked Questions - Applet Security
JCA
Applets signées
- Exemple d'applet signée
- Applets signées, navigateurs, et accès aux fichiers
Formation
- Security in JDK 1.2 - The Java Tutorial
- Java Security par Scott Oaks (The Java Series, O'Reilly 1998)
Outils de sécurité Java 2
- keytool
- jarsigner
Cryptographie
- La Science du Secret de Jacques Stern (Odile Jacob).
- Liberation du 29 janvier 1999 - Les Clés du Secret
- RSA Laboratories - FAQ about today's cryptography