Le modèle de sécurité de Java 2 SEE - Février 2000 Sécurité logique et Objets Le modèle de sécurité de Java 2 Laurent.Frerebeau@bull.net

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

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é 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, …

Propriétés recherchées Généricité Souplesse de configuration et d’utilisation Interchangeabilité des moyens cryptographiques des services de sécurité authentification autorisation administration  Besoin de changer de fournisseur, de s’adapter à des contraintes légales, de suivre l’état de l’Art, etc.

« 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 correct que les classes classes finales ne sont pas sous-classées que 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)

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 »

Modèle de sécurité du JDK 1.0

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

Modèle de sécurité du JDK 1.1

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 + ressource exemple 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 applicatives toutes 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) == true p2.implies(p1) == false (implicitement) définir une liste de droits et un système de nommage des ressources

Le contrôle d’accès (2/5)

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éseau configuré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)

Le contrôle d’accès (4/5) origine du code (« code source ») : un couple auteur + serveur d’origine domaine de protection ensemble 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);

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

Modèle de sécurité du JDK 1.2 Chargeur de classes Signé ou non

Architecture de sécurité d ’une application Java 1.2 Eléments jouant un rôle dans la « sandbox » Remote class files Local class files Respect du langage Chargement des classes qui ne sont pas dans le CLASSPATH Signed class files Byte code verifier Core API class files Class loader Core Java API Security package Limite les accès à l ’OS Auth. des classes signées + crypto. Key database Security manager Access controller Operating system

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 classe associe un domaine de protection aux classes qu’il charge l ’ ‘ URLClassLoader ’ : chargeur à usage général

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é »

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(); }

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 client l’interface « SPI » : permet à un fournisseur d’implémentation de service cryptographique de s’insérer dans l ’infrastructure des CSP : « Cryptographic Service Provider » le JDK 1.1 fournit des services de calcul de condensats de 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 certificats gestion des paramètres liés aux algorithmes ‘ Key Factory ’ : conversion de formats de clé

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

Accès aux ressources cryptographiques (3/5)

Accès aux ressources cryptographiques (4/5)

Accès aux ressources cryptographiques (5/5) Autres nouveautés : classes de manipulation de certificat décodage et gestion de certificats support de X509 V3 mais ouvert à d ’autres formats et à d’autres encodages classes de manipulation de clés et de paires de clés classe ‘ engine ’ « KeyStore » + 1 fournisseur par défaut des interfaces de spécification de clé, permettant de manipuler des clés indépendamment de leur représentation

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

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

JAAS (3/3) Introduit les notions de : sujet : identité principal : 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, …)

Les outils Les nouveaux : keytool : jarsigner : policytool : 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 JAR s’appuie sur le ‘ keystore ’ policytool : crée et modifie des fichiers de politiques de sécurité

Exemple de mise en œuvre : Role Based Management

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 credentials insuffisances dans l ’expression des identités, des privilèges et des attributs de sécurité