Embed Size (px)
Citation preview
Page 2
Pourquoi toujours plus de sécurité dans Java ?
Java est un langage particulier : orienté réseau / Internet / Web
le code est téléchargéprogressivement (avec possibilité de sources multiples)dynamiquement (risques de modification)
le vecteur est publique et « à risque »le code peut avoir besoin d’accéder à des ressources locales
Protéger les ressources locales contre du code ... malveillant (virus, cheval de Troie, …) indiscret / instigateur (accès à des informations personnelles)
Protéger le code et les données qu’il gère contre … leurs utilisateurs
Page 3
De quels services de sécurité a-t-on besoin ?
D’authentification de l’origine du code
on veut authentifier l’auteur / le fournisseur, pas le colporteur des utilisateurs du code
D’intégrité du code transmis des données générées / manipulées par le code
De confidentialité des données générées / manipulées par le code
De contrôle d’accès du code sur les ressources locales de l’utilisateur sur les ressources locales ou sur les
ressources applicatives
D’administration de la sécurité ! Eventuellement : de non-répudiation, d ’audit, …
Page 4
Propriétés recherchées
Généricité
Souplesse de configuration et d’utilisation
Interchangeabilité des moyens cryptographiques des services de sécurité
authentificationautorisationadministration
Besoin de changer de fournisseur, de s’adapter à des contraintes légales, de suivre l’état de l’Art, etc.
Page 5
« Sécurité » du langage
Plusieurs niveau d’accès aux classes, méthodes et attributs : private, package, protected, public
Contrôles d’intégrité à la compilation et à l’exécution variables non initialisées dépassement de tableau conversion de type illégale
Vérificateur de ‘ bytecode ’ (code intermédiaire) mini-démonstrateur de théorème ; vérifie en particulier :
que le format du fichier est correctque les classes classes finales ne sont pas sous-classéesque les contraintes générales du langage sont respectées
Chargeur de classe spécialisable
Gestionnaire de sécurité / Contrôleur d’accès contrôle tous les accès aux ressources (en particulier OS)
Page 6
Le « bac à sable »
Ou : « sandbox » Ce principe existe depuis le JDK 1.0 :
fournir un environnement d’exécution restreint au code « inconnu » (en particulier, celui arrivant du réseau)limitation des accès
aux ressources locales : §système de fichiers§moyens de communication, sauf vers le serveur ayant transmis le code
à certaines données système §liste des chemins d ’accès aux classes locales§nom de l ’utilisateur courant§...
Distinction entre « applet » et « application » une application a « tous les droits » une applet chargée localement a « tous les droits » une applet chargée depuis le réseau subit le principe du
« bac à sable »
Page 7
Modèle de sécurité du JDK 1.0
Page 8
La signature de code
A partir du JDK 1.1, Java permet d’accorder sa confiance à du code téléchargé : par le biais d’une signature digitale
réalisée au moyen d’outils livrés avec le JDK la signature associée à une classe (ou un ensemble de
classes fichiers JAR), et les choix de réseaux de confiance exprimés par le réceptionnaire, permettent de garantir à celui-ci l’origine du code téléchargé et son intégrité
le code signé et approuvé obtient les mêmes droits que le code local sur les ressources locales
La distinction entre « applet » et « application » est maintenue en JDK 1.1, mais disparaît en JDK 1.2 : les applications peuvent être soumises à des politiques de sécurité et être signées
Page 9
Modèle de sécurité du JDK 1.1
Page 10
Le contrôle d’accès (1/5)
Le JDK 1.2 introduit un modèle de contrôle d’accès fin et paramétrable, applicable aussi bien aux applets qu’aux applications, au travers des notions de : permission :
un couple droit + ressourceexemple de droit : « read », « write » , « execute », … exemple de ressource : « fichier », « port », « imprimante », … les définitions de droit et de ressource sont génériques et extensibles
le modèle est applicable aux ressources applicativestoutes les classes « permission » doivent :
implémenter une méthode « implies » :§« a implies b » signifie : si la permission « a » est accordée, alors la
permission « b » l’est aussi
Permission p1 = new FilePermission("/tmp/*", "read");Permission p2 = new FilePermission("/tmp/readme", "read");p1.implies(p2) == truep2.implies(p1) == false
(implicitement) définir une liste de droits et un système de nommage des ressources
Page 11
Le contrôle d’accès (2/5)
Page 12
Le contrôle d’accès (3/5)
politique de sécurité :un ensemble de « permissions »s’applique aussi bien au code local qu’au code réseauconfigurée par l’utilisateur ou un administrateur
grant [codebase "<URL>"] [signedBy "<alias>"]
{ permission [permission class] ["target"], ["actions"];
permission ...
};
grant codebase "http://www.sun.com/",
signedby "JavaSoft Division"{ permission java.net.SocketPermission "java.sun.com",
"connect, accept";};
les alias font référence à des clés / certificats stockés dans un fichier spécial (‘ keystore ’ maintenu par l’utilisateur)
Page 13
Le contrôle d’accès (4/5)
origine du code (« code source ») :un couple auteur + serveur d’origine
domaine de protectionensemble de classes (désignées par une « origine de code »)
dont les instances bénéficient des mêmes « permissions »une façon de se créer ses propres « bacs à sable »…
Permissions permissions =Policy.getPolicy().getPermissions(codesource);
ProtectionDomain domain =
new ProtectionDomain(codesource, permissions);
Page 14
Le contrôle d’accès (5/5)
Les applications Java peuvent utiliser ce modèle pour bâtir leur propres contrôles accès aux options de menus et aux boutons d’action accès aux données d’une table ...
Le gestionnaire de sécurité s’appuie sur ce modèle pour contrôler les accès aux ressources locales
Page 15
Modèle de sécurité du JDK 1.2Signé ou non
Chargeurde classes
Page 16
Architecture de sécurité d ’une application Java 1.2
Remote class files Local class files
Signed class files
Byte code verifierByte code verifier
Class loaderClass loader
Core Java APISecurity packageSecurity package
Core API class files
Operating system
Access controller
Security managerKey databaseKey database
Eléments jouant un rôle dans la « sandbox »
Respect dulangageChargement des
classes qui ne sont pas dans le
CLASSPATH
Limite les accèsà l ’OS
Auth. des classessignées+ crypto.
Page 17
Le chargeur de classes
Un des rôles fondamentaux d’un chargeur de classe est de maintenir une distinction de nommage entre des classes chargées sur des sites différents : deux classes de même nom (et éventuellement de même
package), chargée depuis deux sites différents ne sont pas équivalentes et peuvent avoir des permissions différentes
le JDK 1.2 facilite le développement de nouveau chargeurs de classe
Le JDK 1.2 est livré avec deux nouveaux chargeurs : le ‘ SecureClassLoader ’ :
sert de base au développement d’autres chargeurs de classeassocie un domaine de protection aux classes qu’il charge
l ’ ‘ URLClassLoader ’ :chargeur à usage général
Page 18
Gestionnaire de sécurité et contrôleur d’accès
Ou : « Security Manager » et « Access Controller »
Le gestionnaire de sécurité existe depuis le JDK 1.0 mais été remanié en 1.2 : est maintenu en 1.2 pour des raisons de compatibilité sous-traite toutes les tâches de calcul de contrôle d ’accès
au contrôleur d ’accès
Le contrôleur d’accès est un nouveau composant en 1.2 : réalise toute les prises de décision d’accès « système », sur
la base de fichiers de politique de sécurité est impliqué dans le passage de morceaux de code en mode
« privilégié »
Page 19
Blocs et objets protégés
Très utile pour les composants intermédiaires d’architectures trois tiers, ou les composants qui font de la délégation de service (serveur d ’imprimante, par exemple), etc.
Permet à un composant d’exécuter un bout de code avec ses permissions propres (ie. : celles liées à l’origine et au signataire du composant), indépendamment de celles de celui qui a appelé le composant exécutant la fonction protégée
void someMethod() {
// normal code here
try { AccessController.beginPrivileged();
// privileged code goes here
} finally { AccessController.endPrivileged(); }
Page 20
Accès aux ressources cryptographiques (1/5)
JCA : Java Cryptography Architecture introduit avec le JDK 1.1 concentre les accès aux ressources cryptographiques modèle à « fournisseur de services »
deux niveaux d ’API :les classes « moteur » : API présentant sous forme générique des
services cryptographiques de base à du code clientl’interface « SPI » : permet à un fournisseur d’implémentation de
service cryptographique de s’insérer dans l ’infrastructuredes CSP : « Cryptographic Service Provider »
le JDK 1.1 fournit des services de calcul de condensatsde signature / vérification de signature de message
le JDK 1.2 en ajoute quelques autres :création et gestion d ’espace de stockage de clés et de
certificatsgestion des paramètres liés aux algorithmes‘ Key Factory ’ : conversion de formats de clé
Page 21
Accès aux ressources cryptographiques (2/5)
‘ Certificate Factory ’ : génération de certificats et de CRL et support de plusieurs encodages
fourniture d’un service (surchargeable) de génération de nombres aléatoires
la JRE 5.2 arrive avec une implémentation minimale (Sun)DSA, MD5, SHA-1, géné. certif. et CRL, KeyStore, géné. aléa.
A cela s’ajoute un package supplémentaire : JCE (Java Cryptographic Extensions) diffusion restreinte échanges de clés chiffrement / déchiffrement calculs de MAC (Message Authentication code) implémentation Sun : DES, 3DES, PBE, DH, HMAC...
Remarques : les possibilités de signature et de vérification de signature de
classe, y compris pour le code chargé localement, prennent alors toute leur importance
Page 22
Accès aux ressources cryptographiques (3/5)
Page 23
Accès aux ressources cryptographiques (4/5)
Page 24
Accès aux ressources cryptographiques (5/5)
Autres nouveautés : classes de manipulation de certificat
décodage et gestion de certificatssupport de X509 V3mais ouvert à d ’autres formats et à d’autres encodages
classes de manipulation de clés et de paires de clésclasse ‘ engine ’ « KeyStore » + 1 fournisseur par défautdes interfaces de spécification de clé, permettant de manipuler
des clés indépendamment de leur représentation
Page 25
JAAS (1/3)
« Java Authentication and Authorization Service » Extension à la plate-forme Java Part d’une remarque :
le contrôleur d’accès s’intéresse à l’origine du code et à qui l’a signé
JAAS s ’intéresse à qui exécute ou fait exécuter le code
JAAS adresse les besoins des applications qui veulent s’adapter à leurs utilisateurs en les authentifiant, en contrôlant leurs caractéristiques avant de leur imposer des contrôles d’accès
Inclut deux composants un composant d’authentification des utilisateurs un composant d’autorisation qui travaille à la manière du
contrôleur d’accès avec en plus des informations utilisateur
Page 26
JAAS (2/3)
S’inspire des principes et de l’architecture de la technologie PAM (Pluggable Authentication Module) de Sun
Prévoit le support de modèles de contrôle d’accès orientés utilisateur, groupes d’utilisateurs ou privilèges dans les faits, ne supporte que le contrôle d’accès basé sur
le nom de principal
Principe d’extensions / remplaçabilité par des plug-ins
Page 27
JAAS (3/3)
Introduit les notions de : sujet :
entité qui peut être authentifiée identité
« nom » utilisé pour l’authentification principal :
entité authentifiée à un moment donné « credential » :
données ou preuves d’authentication domaine de technologie de sécurité :
environnement regroupant les composant utilisant un même mécanisme de sécurité (Kerberos, DCE, …)
Page 28
Les outils
Les nouveaux : keytool :
permet de gérer les clés et les certificats permettant de signer des applications et des applets
met à jour une base de données appelée ‘ keystore ’ jarsigner :
signe et vérifie la signature de JARs’appuie sur le ‘ keystore ’
policytool : crée et modifie des fichiers de politiques de sécurité
Page 29
Exemple de mise en œuvre : Role Based Management
Page 30
Conclusion
Le JDK 1.2 dispose de tout ce qu’il faut pour concevoir désormais des applications sécurisées réellement sécurisées
Les bons points : JCA le modèle à base de permissions
simple et de bon goût
Les déceptions : la disponibilité de JCE ou d’équivalents bon marché
un package JAAS prometteur mais non finalisémanques notoires dans la définition des credentialsinsuffisances dans l ’expression des identités, des privilèges et
des attributs de sécurité
