Cryptographie

Besoin

Définir un ensemble des techniques permettant de fournir :

• authentification
• intégrité
• confidentialité

Implémentation

Java offre des API cryptographiques mettant en oeuvre :

• authentification : savoir d'où vient un code
• intégrité : garantir qu'un message (code ou autre) n'a pas été modifié
• confidentialité : cryper 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ème d'authentification non-rejouables (one-time password, etc.)

Afin de permettre à tout éditeur de fournir une implémentation d'un ou de plusieurs concepts de sécurité introduits dans Java 2, tout classe de sécurité générique (engine class) 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émenter un 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 possible d'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édilection par 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" (Java Key Store) de Sun. Cette implémentation effectue la persistance de l'objet java.security.KeyStore dans un fichier au format propriétaire.

Sun fournit de plus dans le JDK 1.2 l'outil keytool, qui permet un accès utilisateur (bien qu'en ligne de commande) à un objet KeyStore 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 :

1. 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)
2. 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

• A partir de Mars 1998, le cryptage "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 19 janvier 1999, le 1er ministre annonce qu'un décret de Février va porter la limite du cryptage 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 cryptage 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 sais pas qui est Joe Schmoe.

Blowfish

Algorithme de cryptage.

Diffie-Hellman

Algorithme de cryptage du nom de ses deux auteurs, Whit Diffie (l'un des plus grands experts mondiaux en matière de sécurité) et Hellman.

Diffie Hellman est disponible dans la JCE.

Identité

Personne ou organisme identifiable par sa clé publique.

Dans Java 2, une identité est représentée par un java.security.Principal.

MAC

Acronyme pour Message Authentication Code, standard permettant de garantir l'intégrité d'un message.

MOSS

Standard de sécurisation du courrier électronique conçu pour dépasser les limites de PEM en supportant les messages MIME.

Parce que MOSS est plus un framework qu'une spécification, et parce qu'il dispose de nombreuses implémentations différentes, deux correspondants MOSS peuvent avoir des difficultés à communiquer. On pourra donc lui préférer S/MIME, clairement défini.

PBE

Acronyme pour Password-Based Encryption. Système de cryptage basé sur MD5-RC4 et standardisé dans PKCS#5.

PBE est disponible dans la JCE.

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.

SKIP

Acronyme pour Secure Key Internet Protocol.

TLS

Nouvelle génération de SSL.

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
  • Java Cryptography Architecture Security API Specification & Reference
  • How to implement a provider for the Java Cryptography Architecture
  • API for Privileged Blocks
  • Cryptography : The Ancien Art of Secret Messages
  • Java 2 Cryptography Extension (JCE) : Encrypting and Decrypting Data
• 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