v 2.40 Copyright (C) 1999-2023 Jean-Michel DOUDOUX.
| Développons en Java v 2.40 Copyright (C) 1999-2023 Jean-Michel DOUDOUX. |
|||||||
|
|
|
|
|
|
||
 |
 |
 |
| Niveau : |  Confirmé |
Depuis sa conception, la sécurité dans le langage Java a toujours été une grande préoccupation pour Sun.
Avec Java, la sécurité revêt de nombreux aspects :
Ces deux premiers aspects ont été intégrés à Java dès sa première version.
Ce chapitre contient plusieurs sections :
 |
Ce chapitre est très incomplet : la suite de ce chapitre sera développée dans une version future de ce document |
Les spécifications du langage apportent de nombreuses fonctionnalités pour renforcer la sécurité du code aussi bien lors de la phase de compilation que lors de la phase d'exécution :
La JVM exécute un certain nombre de contrôles au moment de l'exécution :
Un système de contrôle des droits des applications a été intégré à Java dès sa première version notamment pour permettre de sécuriser l'exécution des applets. Ces applications téléchargées sur le réseau et exécutées sur le poste client doivent impérativement assurer aux personnes qui les utilisent qu'elles ne risquent pas de réaliser des actions malveillantes sur le système dans lequel elles s'exécutent.
Le modèle de sécurité relatif aux droits des applications développées en Java a évolué au fur et à mesure des différentes versions de Java.
Le modèle proposé par Java 1.0 était très sommaire puisqu'il ne distinguait que deux catégories d'applications :
Le modèle est basé sur le "tout ou rien". Les applications locales ont tous les droits et les applications téléchargées ont des droits très limités. Les restrictions de ces dernières sont nombreuses :
La mise en oeuvre de ce modèle est assurée par le "bac à sable" (sandbox en anglais) dans lequel s'exécutent les applications téléchargées.
Le modèle proposé par la version 1.0 était très efficace mais beaucoup trop restrictif surtout dans le cadre d'une utilisation personnelle telle que celle des applications pour un intranet par exemple.
Le modèle de la version 1.1 propose la possibilité de signer les applications packagées dans un fichier .jar. Une application ainsi signée possède les mêmes droits qu'une application locale.
Le modèle proposé par la version 1.1 a apporté des débuts de solution pour attribuer des droits à certaines applications. Mais ce modèle manque cruellement de souplesse puisqu'il s'appuie toujours sur le modèle "tout au rien".
Le modèle de la version 1.2 apporte enfin une solution très souple mais plus compliquée à mettre en oeuvre.
Les droits accordés à une application sont rassemblés dans un fichier externe au code qui se nomme politique de sécurité. Pour les différentes applications, l'ensemble des fichiers se situe dans le répertoire lib/security du répertoire où est installé le JRE. Par convention, ces fichiers ont pour extension .policy.
Le mot cryptographie est dérivé des mots grecs kryptos (caché) et graphie (écriture). La cryptologie est la science qui étudie la transformation d'un texte en clair (plain text) en un texte chiffré difficile à comprendre (ciphered text).
La cryptographie permet de stocker ou d'échanger des données de façon plus ou moins sécurisée.
La cryptographie utilise deux opérations :
La cryptographie est l'art de sécuriser un ensemble de données : elle est principalement utilisée pour créer une valeur de hachage d'un message ou pour chiffrer/déchiffrer un message. Dans les deux cas, des algorithmes mathématiques complexes voire très complexes sont utilisés.
La cryptographie est un élément très important de la sécurité des échanges notamment au travers des réseaux : elle est par exemple utilisée pour mettre en oeuvre les signatures digitales, les certificats, l'authentification de messages, le chiffrement/déchiffrement des messages, ...
La cryptographie est utilisée pour mettre en oeuvre plusieurs fonctionnalités notamment :
Une clé est un ensemble de données utilisée lors du chiffrement ou du déchiffrement de données afin de rendre ces opérations plus résistantes.
La cryptographie est assez ancienne : elle est utilisée depuis très longtemps avec des algorithmes initialement basiques. Par exemple, à l'époque gallo-romaine, l'empereur Jules César utilisait un système de chiffrement symétrique reposant sur un décalage alphabétique : ces principes de substitutions étaient utilisés pour crypter des messages.
|
Texte en clair |
B |
O |
N |
J |
O |
U |
R |
|
Décalage |
+3 |
+3 |
+3 |
+3 |
+3 |
+3 |
+3 |
|
Texte chiffré |
E |
R |
Q |
M |
R |
X |
U |
Cette substitution est assez facile à casser, notamment par ce que chaque lettre en clair correspond à une même lettre chiffrée.
Il existe des versions plus complexes qui font varier la valeur de décalage pour chaque lettre.
|
Texte en clair |
B |
O |
N |
J |
O |
U |
R |
|
Décalage |
+1 |
+2 |
+3 |
+1 |
+2 |
+3 |
+1 |
|
Texte chiffré |
C |
R |
Q |
K |
Q |
X |
S |
Dans l'exemple ci-dessus, la lettre O peut être cryptée en R ou Q selon sa position dans le texte.
Les algorithmes de substitution sont facilement cassables avec des machines.
Il est possible d'utiliser une clé de substitution qui associe à chaque caractère un autre caractère. L'inconvénient est que la clé doit être connue lors du chiffrement et du déchiffrement, ce qui nécessite d'une manière ou d'une autre de réaliser un échange de cette clé.
|
Caractère |
A |
B |
C |
D |
E |
F |
G |
H |
I |
J |
K |
L |
M |
N |
O |
P |
Q |
R |
S |
T |
U |
V |
W |
X |
Y |
Z |
|
Clé |
L |
O |
G |
P |
R |
T |
C |
M |
A |
Q |
S |
U |
Z |
H |
D |
I |
W |
B |
V |
J |
Y |
N |
E |
K |
X |
F |
En utilisant la clé, il est possible de chiffrer le message.
|
Texte en clair |
B |
O |
N |
J |
O |
U |
R |
|
Texte chiffré |
O |
D |
H |
Q |
D |
Y |
B |
Plusieurs types de modèles sont utilisés en cryptographie :
Il existe deux grandes familles d'algorithmes de chiffrement :
Le chiffrement symétrique utilise la même clé pour chiffrer et déchiffrer les données.
Ce procédé présente plusieurs inconvénients :
Le chiffrement asymétrique utilise deux clés distinctes qui sont liées entre elles : la clé utilisée pour chiffrer peut être utilisée pour déchiffrer ce qui a été chiffré avec l'autre clé et vice versa. Une des deux clés conservée par l'émetteur est nommée clé privée, l'autre clé diffusée est nommée clé publique.
|
Avantages |
Inconvénients |
|
|
Chiffrement symétrique |
Rapide |
Echange de la clé Ne peut pas être utilisé pour les signatures électroniques |
|
Chiffrement asymétrique |
Utilise deux clés Utilisable pour les signatures électroniques |
Lent |
Avec un chiffrement asymétrique, les deux clés sont liées mais il n'est pas possible de retrouver une clé à partir de l'autre.
Les algorithmes de chiffrements asymétriques sont généralement plus lents que les symétriques et nécessitent de nombreuses ressources lors de leurs calculs.
La cryptanalyse est la science qui étudie comment casser un algorithme de chiffrement : son but est donc de décrypter les données encodées avec un algorithme sans avoir les informations utiles pour réaliser l'opération. Pour cela, elle emploie de nombreuses techniques notamment la force brute, la factorisation, la cryptanalyse linéaire, la cryptanalyse différentielle, ...
Certains algorithmes ne possédant pourtant pas de failles connues ne sont plus utilisés car la puissance de calcul des machines actuelles permet de trouver leur clé (exemple : l'algorithme DES)
Il ne faut considérer aucun algorithme comme fiable et ils sont tous potentiellement vulnérables, si ce n'est maintenant, ce sera plus tard. La vulnérabilité d'un algorithme dépend du temps et de la puissance du hardware. Par exemple, les algorithmes DES et MD5 fréquemment utilisés sont maintenant considérés comme non sûrs et ne doivent donc plus être utilisés pour des besoins critiques.
Avec les algorithmes à clés symétriques, la même clé est utilisée pour les opérations de chiffrement et de déchiffrement. Ce type d'algorithme porte aussi le nom d'algorithme à clé secrète. Ce type de chiffrement est historiquement le plus ancien puisqu'il était déjà utilisé par les égyptiens et les romains plusieurs milliers d'années avant J.C.
La taille de la clé influe sur la robustesse de l'algorithme.
L'émetteur et le récepteur doivent partager la même clé. La clé ne doit être connue que de l'émetteur et du récepteur. Il faut donc garantir que l'échange de cette clé se soit fait de manière sécurisée.
Son principal défaut concerne donc l'échange de la clé entre l'émetteur et le récepteur. Hormis par un moyen physique, il n'est pas possible d'échanger électroniquement la clé de façon sécurisée sans la chiffrer.
Chaque paire d'acteurs (émetteur/receveur) doit avoir une clé différente sinon tous les acteurs qui partagent la même clé seront capables de déchiffrer les données. Pour des échanges sécurisés avec plusieurs acteurs indépendants, il faut une clé distincte ce qui peut rendre le nombre de clés à gérer important.
Son grand intérêt est d'être rapide lors de l'exécution des opérations car les algorithmes mathématiques sont relativement simples.
L'algorithme peut s'appliquer selon deux approches :
Il existe de nombreux algorithmes de chiffrements symétriques :
|
Algorithme |
Description |
|
DES |
DES est l'acronyme de Data Encryption Standard. Cet algorithme a été inventé en 1977 par IBM et adopté en 1978 par le NBS (National Bureau of Standards). Il a été utilisé par les administrations fédérales américaines pour chiffrer les données sensibles. Les données sont chiffrées par blocs de 64 bits (block cipher). Il utilise une clé sur 56 bits ce qui le rend vulnérable aux attaques par force brute. Cet algorithme n'est donc plus considéré comme sûr. |
|
Triple DES (3DES) |
Pour palier la faiblesse de DES, l'algorithme Triple DES applique trois fois l'algorithme DES avec deux ou trois clés différentes. Ceci rend cet algorithme plus résistant aux tentatives de déchiffrement par force brute. |
|
Blowfish |
Blowfish utilise une clé de longueur variable de 32 à 448 bits et est plus rapide et plus sûr que DES (block cipher) |
|
AES / Rijndael |
(Advanced Encryption Standard) : 128/192/256 bits, plus rapide et plus sûr que le Triple DES, finalisé en 2000 (block cipher) AES est l'acronyme de Advanced Encryption Standard. Cet algorithme a été inventé en 2000 par Vincent Rijmen et Joan Daemen pour remplacer le DES. Il est utilisé par les administrations américaines pour chiffrer les données sensibles. AES peut utiliser plusieurs longueurs de clés notamment 128 bits, 192 bits et 256 bits selon le degré de sécurité souhaité. |
|
IDEA |
(International Data Encryption Algorithm) : 128 bits IDEA est l'acronyme d'International Data Encryption Algorithm. Cet algorithme a été inventé en 1991 par J. Massey et X. Lai. Son principe de fonctionnement est similaire à DES mais il utilise une clé plus longue sur 128 bits. |
|
RC2, RC4, RC5, RC6 (Rivets Cipher 4) |
128bits, taille variable (stream cipher) RC2, RC4 et RC5 sont des algorithmes créés par Ronald Rivest. RC est l'acronyme de "Ron's Code" ou "Rivest's Cipher". Ces algorithmes permettent de choisir la longueur de la clé (jusqu'à 1024 bits). |
Le modèle symétrique possède plusieurs limitations :
Ce modèle repose sur des algorithmes mathématiques complexes qui utilisent deux clés distinctes, une dite publique et une autre dite privée :
Un grand nombre aléatoire est utilisé pour générer les deux clés. Les deux clés utilisées sont différentes et il est impossible de déduire une clé à partir de l'autre. Par contre, l'usage des deux clés est réversible : l'une peut être indifféremment la clé publique ou la clé privée et vice versa.
Chaque clé joue un rôle particulier : une clé est utilisée pour chiffrer les données et l'autre clé est pour déchiffrer.
La clé publique est utilisée pour chiffrer les données qui ne seront alors déchiffrable qu'avec la clé privée. Inversement, un message chiffré avec la clé privée ne pourra être déchiffré qu'avec la clé publique. La clé publique peut être diffusée à tout le monde mais la clé privée doit être gardée secrète.
L'utilisation de ce modèle nécessite plusieurs étapes :
A et B possèdent chacun leur clé privée. Ils se sont échangé leurs clés publiques respectives.
A utilise sa clé privée pour envoyer un message chiffré à B qui utilise la clé publique correspondante pour déchiffrer le message.
L'échange de clés publiques est facile puisque cette clé est inutilisable sans la clé privée correspondante qui elle n'est pas échangée.
Ce type d'algorithme porte aussi le nom d'algorithme à clé publique. Le développement de ces algorithmes est assez récent puisqu'ils ont débuté dans les années 1970. Ils permettent d'utiliser la cryptographie pour assurer des fonctionnalités de type confidentialité et authentification.
Il existe plusieurs algorithmes qui mettent en oeuvre ce modèle dont :
|
Algorithme |
Description |
|
RSA |
RSA est l'acronyme du nom de ses trois inventeurs (Ronald Rivest, Adi Shamir et Leonard Adleman). Le brevet relatif à RSA a expiré en septembre 2000. jusqu'à 2048 bits, publié en 1978 La clé publique est le résultat de la multiplication de deux très grands nombres premiers. La clé privée dépend de ces deux valeurs mais il est extrêmement difficile de les recalculer à partir de la clé privée. |
|
DSA |
DSA est l'acronyme de Digital Signature Algorithm |
|
Diffie-Hellman |
Diffie-Hellman est un algorithme de chiffrement asymétrique créé par Whitfeld Diffie et Martin Hellman. L'algorithme a fait l'objet d'un dépôt de brevet en 1977 qui a expiré en 1997. C'est un protocole pour l'échange de clés qui est vulnérable |
|
ElGamal |
L'algorithme ElGamal est une variante de Diffie-Hellman inventée par Taher Elgamal. |
|
Elliptic Curve Cryptography (ECC) |
La vitesse de l'AES est utilisée avec les clés RSA : le chiffrage est efficace car plus rapide avec une taille de clé réduite Améliore grandement la vitesse de traitement par rapport à l'encryptage standard avec des clés publiques Plusieurs implémentations open source (BouncyCastle, OpenSSL, ...) Implémentations de plusieurs algorithmes dans Java 7 |
Ce type de modèle est utilisé dans la signature digitale :
Ceci permet d'authentifier l'émetteur car c'est le seul qui possède la clé correspondant à la clé publique mais ne permet pas la confidentialité des données car la clé publique est diffusée.
Les algorithmes pour le chiffrement symétrique présentent plusieurs inconvénients :
Le chiffrement asymétrique ne garantit pas l'intégrité du message reçu. A chiffre un message avec sa clé publique et envoie le message chiffré à B. C intercepte le message et le remplace par un autre message chiffré avec la même clé publique que A. B reçoit le message et peut le déchiffrer avec la clé privée.
Pour garantir l'intégrité du message, il est nécessaire de le signer. La signature électronique utilise la clé privée de A pour générer une valeur de hachage du message qui sera alors envoyée chiffrée.
Il est aussi possible de signer un message sans le chiffrer.
Deux API fournies depuis Java 1.4 permettent la mise en oeuvre de la cryptographie :
Historiquement, seul l'API JCA était fournie dans le JDK car le JCE était soumis à des restrictions liées à la législation américaine. Depuis l'assouplissement de ces restrictions, les deux API sont fournies dans le JDK.
Historiquement, les API de cryptographie de Java étaient séparées en deux parties afin de permettre une restriction de diffusion :
JCE est une API qui propose de standardiser l'utilisation de la cryptographie en restant indépendant des algorithmes utilisés. Elle prend en compte le cryptage/décryptage de données, la génération de clés et l'utilisation de la technologie MAC (Message Authentication Code) pour garantir l'intégrité d'un message.
JCE a été intégrée au JDK 1.4. Auparavant, cette API était disponible en tant qu'extension pour les JDK 1.2 et 1.3.
Pour pouvoir utiliser cette API, il faut obligatoirement utiliser une implémentation développée par un fournisseur (provider). Avec le JDK 1.4, Sun fournit une implémentation de référence nommée SunJCE.
L'API JCA est contenue dans le package java.security et l'API JCE est contenue dans le package javax.crypto.
JCA |
JCE |
java.security |
javax.crypto |
java.security.acl |
javax.crypto.interfaces |
java.security.cert |
javax.crypto.spec |
java.security.interfaces |
|
java.security.spec |
|
Ces API fournissent différentes fonctionnalités nommées services. Ces services peuvent offrir la même typologie de fonctionnalités mais leurs implémentations utilisent des algorithmes différents.
L'API utilise des fabriques pour permettre d'obtenir une instance de ces services pour un algorithme et éventuellement un fournisseur donné.
La cryptographie est généralement limitée par les législations de nombreux pays. De ce fait, les algorithmes fournis par Java sont répartis en deux groupes :
La configuration utilisable dans le monde entier est fournie avec les JRE dans le fichier default_local.policy contenu dans le fichier lib/security/local_policy.jar
| Exemple : |
// Some countries have import limits on crypto strength. This policy file
// is worldwide importable.
grant {
permission javax.crypto.CryptoPermission "DES", 64;
permission javax.crypto.CryptoPermission "DESede", *;
permission javax.crypto.CryptoPermission "RC2", 128,
"javax.crypto.spec.RC2ParameterSpec", 128;
permission javax.crypto.CryptoPermission "RC4", 128;
permission javax.crypto.CryptoPermission "RC5", 128,
"javax.crypto.spec.RC5ParameterSpec", *, 12, *;
permission javax.crypto.CryptoPermission "RSA", *;
permission javax.crypto.CryptoPermission *, 128;
};Le chapitre «JCA (Java Cryptography Architecture)» détaille l'utilisation de cette API.
Le chapitre «JCE (Java Cryptography Extension)» détaille l'utilisation de cette API.
JSSE permet de mettre en oeuvre TLS (Transport Layer Security). TLS est le successeur de SSL (Secure Sockets Layer). SSL et TLS permettent de sécuriser les échanges sur le réseau en utilisant la cryptographie asymétique. SSL et TLS sont indépendants du protocole utilisé.
Plusieurs versions de TLS ont été publiées :
Par abus de langage, SSL est souvent utilisé comme synonyme de TLS.
Les classes et interfaces de cette API sont regroupées dans les packages javax.net et javax.net.ssl.
Les classes et interfaces de cette API sont regroupées dans le package javax.security.auth
Cette API a été intégrée au JDK 1.4.
|
|
|
|
|
|
||
| Développons en Java v 2.40 Copyright (C) 1999-2023 Jean-Michel DOUDOUX. | |||||||