La sécurité peut être abordée sous différents angles :
C'est au travers d'une approche par composants qu'il convient de considérer les problématiques de sécurité, chaque composant pouvant se situer dans un des domaines cités. Chacun de ces domaines ne suffit à lui seul à proposer une véritable solution de sécurité, et plus que cela, chacun se doit de fournir une interface avec les autres.
| DP | Description |
|---|---|
| Session | suite d'échanges entre deux objets... |
| Proxy | objet auquel on délègue l'accès à un autre objet. |
| Objet gardé | objet encapsulé par un autre, l'objet englobant régissant les opérations autorisées sur l'objet englobé. De manière plus générale l'objet gardé est généralement un objet encapsulant un objet garde et un ou plusieurs objets dont l'accès est contrôlé par le garde. Le principe d'encaspulation des objets gardés permet de transporter un objet avec ses règles d'accès. Ils permettent donc de répondre aux problématiques où l'on doit fournir l'accès à un objet sans connaître le contexte de sécurité du demandeur (celui-ci est distant et ne veut pas transmettre son contexte trop sensible par exemple). Dans ce cas, les objets gardés permettent de déléguer le test de sécurité au demandeur lui-même, en retournant l'objet demandé encapsulé avec son garde. Tout accès à l'objet demandé ne pourra se faire directement, et devra forcément être soumis à l'approbation du garde. |
| Objets constants | Les objets constants (non mutables ou immutables) sont des objets dont l'état n'est accessible qu'en lecture seule On peut voir les objets constants comme un objet gardé n'autorisant que la lecture. |
| Objets opaques / transparents | objet dont le contenu n'est pas accessible par celui qui le manipule (une clé par exemple). |
La sécurité au niveau implémentation concerne :
Java offre des API cryptographiques ainsi que des moyens de s'interfacer avec des composants matériels (réseau typiquement) tels que les proxies ou suites cryptographiques via des API adéquates.
Les objectifs de Java en matière de sécurité sont de :
Java se donne les moyens de la sécurité qu'il propose au travers de garanties de :
Afin de permettre à tout éditeur de fournir une implémentation d'un ou plusieurs de ces concepts de sécurité, à toute classe de sécurité générique (engine class) est associée une 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 :
| Version | 1 | Commentaire | |||
|---|---|---|---|---|---|
| Domaine | Paradigme | Release | 1 | 2 | |
| Architecture | Sandbox | Bac à sable ou TCB (Trusted Computing Base) = Ligne Maginot : tout ou rien : une fois franchie, la guerre est perdue. Un bug, tout est perdu. Franchir la ligne maginot, attaquer là où on ne s'y attend pas, attaquer d'une manière non prévue par l'auteur du TCB : la guerre est perdue. | |||
| Permission | Par nature (fonction de la provenance du code) | ||||
| Cryptographie | Implémentations | JDK | Pluggable | API cryptographiques standardisées et donc pluggables et interopérables | |
| Identité | Classe java.security.Identity |
Interface java.security.Principal |
|||
| Propriétés | Non | java. security. manager |
Gestionnaire de sécurité à utiliser par l'application | ||
| Non | java. class. path |
Liste de répertoires ou fichiers JAR d'où charger des classes locales non privilégiées (non système) | |||
| Non | java. security. policy |
URL du fichier de politique de sécurité à utiliser (=) ou ajouter (==) à la politique courante. Avec le JDK
1.2, il est possible de l'exprimer facilement à l'aide de l'outil graphique (AWT) %java_home%/bin/policytool.exe.
|
|||
Java possède divers atouts pour l'élaboration d'une solution sûre. Parmi ceux-ci, beaucoup sont liés au principe de la JVM. Il s'agit de :
private, protected, final). Encore
une fois, ceci permet à plusieurs applis de coopérer dans le même espace d'adressage de manière sécurisée.
Réelles limitations, contrairement au C++.String) ou les wrappers de
types simples (Integer, Long, Float, etc.). Ceci permet de retourner
un objet en lecture seule (la modification d'une chaîne retournée ne doit pas modifier la chaîne d'origine
par exemple). On peut voir les objets constants comme un objet gardé n'autorisant que la lecture.final sur un objet)Acronyme pour Joint Electronic Payment Initiative.
Le protocole JEPI défini en 1997 a l'avantage d'être indépendant du protocole de paiement (il le négocie). Cependant, il ne spécifie pas d'interface permettant à l'utilisateur d'exploiter de nouveaux protocoles de paiement.
La première implémentation de JEPI est celle de CommerceNet, en Java, mais n'exploite pas la possibilité de Java de télécharger des nouveaux gestionnaires de protocoles (JAF ?) et du code (applications) en général.
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.
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.
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).
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.
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.
Acronyme pour Secure Key Internet Protocol.
Acronyme pour Secure Wide Area Network.
Permet d'intégrer de la sécurité pour les WAN au sein de réseaux privées virtuels.
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.
Comme pour les plugins, le modèle de sécurité ActiveX :
Evolution de OLE.
-> OLE inventé pour rendre Office plus flexible
--> Patch way of life
Sécurité Windows : non multi-utilsiateur non multisession, non network... etc, C history ; patch way not designed for all this stuff.
La sécurité est dans l'OS Windows et non dans les composants (sécurité au niveau du langage comme Java).