Besoin

Définir un ensemble des techniques permettant de fournir :

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'authentificationnon-rejouables (one-time password, etc.)
Version 1 Commentaire
Domaine Paradigme Release 1 2
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ésest la base "JKS" (Java Key Store) 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 ordrede 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 , 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 , 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 ) 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.

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.

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