Discussion:Vérification de bytecode Java Card

message: Ajout de l'introduction et suppression de la balise "Article incompréhensible". Shark3119 (d) 9 octobre 2012 à 09:24 (CEST)
thread_title: Modifications apportées

message: *La page manque globalement d’illustrations.
*L'ajout d'un schéma général d'une java card avec les différentes parties concernées ou utilisées par la vérification du bytecode serait un plus.
:Bonjour ! Le sujet étant étroitement lié à la structure d'une Java Card, peut-être aurait-il été souhaitable d'ajouter un schéma décrivant les différents composants de celle-ci concernés ou utilisés par la vérification du bytecode. Un tel schéma figure dans le document de Yongsang Song, Jongmoo Choi et Kyongho Han intitulé Multimodal Security Enhancement Scheme for Java Card, page 623. D’une manière générale, la page manque un peu d’illustration.
:Patrick Petitjean (d) 1 février 2013 à 13:45 (CET)
thread_title: Illustrations

message: *Il manque des références à SUN,
*Un point d'histoire permettrait d'introduire les différences entre OFF CARD et ON CARD ainsi que l'évolution des différents algorythmes de vérification.
:D’un point de vue historique, pourquoi ne pas citer la première solution de vérification  proposée par Gosling et Yellin rapportée dans le document On-Card Bytecode Verification for Java Card de Xavier Leroy  que vous citez en référence ? Dans le même ordre d’idée, ne  serait-il pas intéressant de faire référence à des documents publiés par SUN comme [Java Card Applet Developer’s Guide], [Java Car System Protection Profile Collection] ou le libre blanc Java Card 2.2 Off-Card Verifier ? Ce dernier document permettrait d'ailleurs d'introduire la comparaison entre les vérifications OFF-Card et ON-Card, la seconde méthode étant considérée à l’époque comme impossible par SUN à cause des contraintes techniques inhérentes au support. Voir à ce sujet Building an "impossible" verifier on a Java Card de Damien Deville et Gilles Grimaud.
:Patrick Petitjean (d) 1 février 2013 à 13:45 (CET)
thread_title: Historique

message: Il est important d'insister sur les contraintes techniques fortes liées à la vérification du bytecode Java Card :
* microprocesseur,
*mémoire.
:C'est pourquoi il me semble primordial d'insister sur ces contraintes techniques fortes de la vérification du bytecode Java Card, comme les limites du microprocesseur et de  la mémoire disponible. Cela permettrait aussi d’initialiser un chapitre sur l’évolution des différents algorithmes ou méthodologies de vérification.
:Patrick Petitjean (d) 1 février 2013 à 13:45 (CET)
thread_title: Contraintes techniques

message: En quoi la vérification du bytecode garantie la sécurité des données ?
:Il manque peut être un passage d'introduction pour indiquer en quoi la Sécurité des données/l'Intégrité des données et les Attaques sur les données font partis des enjeux de la vérification du bytecode.
:Sylvain Theude (d) 1 février 2013 à 09:40 (CET)
replies: text: La vérification de bytecode a pour but d'assurer que le bytecode qui sera exécuté sur la carte à puce JAVA n'effectue pas d'inscruction non souhaitée. Comme par exemple récupérer des données stockées sur la mémoire de la carte à puce ou autre. Shark3119 (d) 11 février 2013 à 12:26 (CET)
thread_title: Lien entre la vérification du bytecode et la sécurité des données

message: L'ajout d’un exemple détaillé d’attaque permettrait d'appuyer le discours.
:Le paragraphe sur les différents types d’attaques pourrait être enrichi de l’exemple récent (octobre 2012) fourni par Jean-Louis Lanet dans Attacks against smart cards: Hands on session. Il pourrait également être judicieux de mettre à profit l’état de l’art des différentes attaques que ce même auteur a réalisé avec Julien Iguchi-Cartigny dans  Evaluation de l'injection de code malicieux dans une Java Card.
:Patrick Petitjean (d) 1 février 2013 à 13:45 (CET)
replies: text: Nous avons volontairement retiré les descriptions des attaques possibles sur les Java card car nous nous sommes rendu compte que nous étions hors-sujet. En effet, le sujet repose sur les méthodes de vérification de bytecode Java et des raisons de la vérification, et non pas sur les techniques d'attaques. Vous pouvez retrouver dans notre bibliographie des ouvrages/articles décrivant des attaques physiques et logiciels.Shark3119 (d) 11 février 2013 à 12:31 (CET)
thread_title: Les attaques

message: Il manque le détail du fonctionnement de la vérification du bytecode, la description des méthodes et modèles de vérification
:*Une petite remarque, je ne vois à aucun endroit (dans une description générale, dans l'abstract ...) la notion d'analyse statique (je reprends les termes de Xavier Leroy pour illustrer mon propos) : "La vérification de bytecode est un composant de sécurité crucial pour l'exécution sans risques d'applets Java, aussi bien dans des navigateurs Web que dans des systèmes embarqués comme les cartes à puce JavaCard. Il s'agit d'une analyse statique de code compilé qui établit au moment du chargement des propriétés le bon typage du code et l'intégrité de la machine virtuelle Java." Je vois cette notion dans presque tous les articles parcourus, et elle me semble être suffisamment importante pour être mentionnée... Qu'en pensez vous ?
:*Dans l'article « Formal Development of an Embedded Verifier for Java Card Byte Code » de Ludovic Casset, Lilian Burdy et Antoine Requet, que diriez vous d'utiliser la section "2. Byte Code verification", ainsi que ses sous sections  : "The structural verification", "The type verification" et "Formal studies on byte code verification" ? Pour info, il existe une version française de ce document (la version est légèrement différente, il faut faire un mix des 2), vous la trouverez ici : http://www-sop.inria.fr/everest/Lilian.Burdy/BCR03ver.pdf
:Sylvain Theude (d) 1 février 2013 à 09:40 (CET)
thread_title: Fonctionnement de la vérification du bytecode Java Card

message: :*Concernant la méthode via Preuve embarquée, le mode de fonctionnement n’est pas très clair, notamment sur l’utilisation de la preuve et son format. Dans la phrase « En effet la vérification est guidée par la preuve lors de l'analyse du bytecode », le verbe « guider » est à mon avis trop imprécis.
:*La phrase "En plus de cela, le matériel de base est mantenu dans EEPROM (Electrically-erasable programmable read-only memory), la tension où la température peu commune, peuvent écrire des opérations" n'est pas compréhensible.
:Patrick Petitjean (d) 5 février 2013 à 14:48 (CET)
thread_title: Compréhension du texte de l’article

message: :*Dans le paragraphe intitulé Code auto-prouvé, vous citez «  un organisme de confiance extérieur s'occupe de la vérification des codes ». S’agit-il d’organismes considérés comme labellisés ? Pourriez-vous préciser cette partie en donnant des exemples et/ou des références ?
:*Existe-t-il d’autres projets similaires ou concurrents du projet Jakarta qui mériteraient de figurer ici ?
:Patrick Petitjean (d) 5 février 2013 à 14:48 (CET)
thread_title: Questions complémentaires

message: Lors de la relecture de cet article, j’ai pu noter différents points qui pourraient être améliorés pour rendre l’article plus compréhensible :
# Je pense qu’une légère restructuration du plan permettrait d’y voir plus clair, ayant eu des difficultés de compréhension lors de la relecture. Par exemple, on peut noter qu’il y a deux façons de vérifier le bytecode : On-Card et Off-Card. Il est donc possible de séparer en 2 parties les « Techniques de vérifications de bytecode java », puis de faire des sous-parties pour expliquer chaques techniques (signature du bytecode, utilisation d’outils de compilation faisant la vérification, etc…). On peut aussi parler de pourquoi les vérifications On-Card sont complexes à mettre en œuvre (comme le soulignait Patrick Petitjean dans sa relecture) dans une sous-parties, ou en transition entre les 2 parties.La partie « Les outils disponibles » n’est pas très exhaustive et l’on ne sait pas vraiment à quoi ils servent. Certaines sous-parties sont d’ailleurs vides, ne comportant qu’un lien vers un article n’existant pas. 
# Certains paragraphes manquent de clarté, et la modification de leur structure augmenterait sans doute la compréhension globale.Exemple : « En plus de cela, le matériel de base est maintenu dans EEPROM, la tension où la température peu commune, peuvent écrire des opérations. En effet, les changements de tensions peuvent libérer des serrures de sécurité sans effacer les données. »
# Ajouter un mot sur l’utilisation des Java Card en général, même si ce n’est pas le but de l’article. En effet, cela permettrait de mieux cerner les enjeux de la sécurité.
# Ajouter des références, notamment dans les « attaques sur les données ». On peut par exemple citer l’article des SSTIC 2012, expliquant une attaque de Java Card. Lien de l’article : https://www.sstic.org/media/SSTIC2012/SSTIC-actes/compromission_application_bancaire_javacard/SSTIC2012-Article-compromission_application_bancaire_javacard-lancia_1.pdf
Jonathan Decrocq
: Bonjour,
:
: L'ensemble de ces remarques sont judicieuses. En priorité, il me semble que la notion de "vérification de bytecode" doit être davantage explicité. Qu'es-ce qui est vérifié ? Comment ? Et quand ? J'insiste sur le fait que la vérification de bytecode, c'est la vérification du code compilé. Le lien avec les données, et par-delà avec les "attaques sur les données" n'est, en l'état, pas clair. S'il doit être conservé, alors c'est qu'il doit être clairement expliqué (il faut expliquer, en quoi la vérification du code protège les données). 
:
: En répondant à la question "qu'es-ce qui est vérifié" tu dois permettre de mettre bon ordre entre d'un coté la "Lightweight Bytecode Verification" de E. Rose à rapprocher des articles de X. Leroy, L. Casset ou encore le "Building an impossible bytecode verifier" de D. Deville (non cité mais identifié par Patrick Petijean) et d'un autre coté les travaux autour de Jakarta, mais aussi Jack (non cité, doi=10.1007/978-3-540-74792-5_7). En l'état la section "Les enjeux de la vérification" ne permet pas de répondre à cette simple question. 
:  
: En répondant à la question "comment" l'article doit permettre de comprendre ce qui est fait "précisément" pour "vérifier" ce qui est vérifié.
:
: En répondant à la question "Quand" l'article doit distingué les solutions "Off-Card", "On-Card" et les solutions intermédiaires qui impliquent un travail plus ou moins important, de chaque coté de cette ligne. 
:
: Je t'invite à proposer sur cette page un nouveau plan pour l'article. Pour discussion. Je note que la section "Contexte" est tellement imprécise qu'elle est à la limite "fausse". Le bytecode qui est le propos de cet article n'est pas le bytecode java, mais le bytecode Javacard. C'est de ce dernier, qu'il aurait fallu parler. qu'en au JCRE, il ne me semble vraiment pas que l'on puisse dire qu'il s'agit d'un ensemble d'applications... La section 2 ne devrait pas nous parler de sécurité des données, mais de ce qui est vérifié, en distinguant ce qui est vérifié par E. Rose, X. Leroy, L. Casset et D. Deville d'un coté, et ce qui est vérifié par Jakarta, Jack ou encore STAN (doi=10.1007/978-3-540-72354-7_16) de l'autre.  
:
: Bonne continuation,
: Gilles.Grimaud (d) 5 avril 2013 à 17:46 (CEST)
thread_title:  Bilan de relecture 

message: ===J.Wach0wiak===
Je traiterai d'abord de la forme, ensuite un peu plus du fond.
====La forme====
De manière générale des fautes d’orthographe sont présentes, le style n'est pas toujours encyclopédique ("nous allons voir", "dans cet article"...), un peu trop de jugement de valeur ("c'est relativement aisé", "triviale"...), les auteurs de travaux de recherche sont cités directement et je ne pense pas que ce soit wikipédiesque ("Xavier Leroy et son équipe", "D'après l'analyse de Xavier Leroy", "Dans cet article, nous allons parler de la méthode expliquée par Xavier Leroy"...) et la conjugaison est un peu trop variée (utiliser le présent de l'indicatif tout le temps, je pense).
Introduction : Résume bien le propos. On comprend le sujet.
Mise en situation : place bien le contexte. Par contre, pas sûr qu'il faille écrire "nous allons voir" dans un article wiki (il y aura d'autres remarques à ce sujet par la suite). Ça fait un peu trop rédaction.
Les Java Card et le développement d'applications : même remarque : "dans cet article", "nous allons nous intéresser", "nous allons voir maintenant"
Les enjeux de la vérification de bytecode Java Card : "tel des données" -> "telles des données"
Vérifications Off-Card : Type Deduction -> en italique ; "Cette partie de la vérification est relativement aisée et rapide" -> source ou ne pas juger ; "Ces quatre point" -> points ; "aient été vérifié" -> "soient vérifiées"
Vérifications On-Card : "Le schéma suivant" -> pas d'allusion au schéma dans le texte, il doit servir d'explication alternative ; "C'est ce qu'ont tenté de faire certains chercheurs..." -> pas sûr que ce soit dans le style de wikipédia, et il faudrait citer leurs travaux de recherches ici je pense
Fonctionnement : "Vu que ces 2 conditions sont..." -> "Ces deux conditions étant..." ; "quelques test effectué" -> "quelques tests effectués" ; "possible que l'on modifie" -> "possible de modifier" ; "Dans la partie suivante" -> idem
Modifications de code : "triviale", "très simple", "aisée"... -> jugements de valeur, je ne sais pas si c'est approprié ; "cet partie de l'algo..." -> "cette partie" ; "qui sorte" -> "qui sortent"
====Le fond====
Sinon on comprend le sujet et les sources présentes sont bien utilisées pour appuyer le texte.
Au départ je pensais qu'il aurait fallu développer un peu plus les attaques sur java car, mais ça aurait été hors sujet. Je trouve donc que ce qui est introduit dans la partie mise en situation est suffisant et présente bien les enjeux.
La partie sur les vérifications on-card est - je pense - trop centrée sur les recherches de X.Leroy et son équipe, il aurait fallu proposer d'autres arguments d'autres équipes de recherches en appui de X.Leroy. Ou éventuellement des équipes qui se sont inspirés de ces travaux pour faire eux-mêmes leur vérification. Par exemple  ou de , quitte à reprendre ces documents pour parler ensuite de la certification de Bytecode. D'autres travaux sur ces vérifications on-card pourraient être ajoutés, comme celui de Deville et Grimaud.
La partie sur les alternatives mériterait d'être plus développée. Jakarta par exemple avec les travaux de ,  ou la thèse de G.Defay (lien vers présentation). Ou parler du .
Je pense aussi qu'il aurait été très intéressant de parler des failles dans ces vérifieurs, en reprenant par exemple , et d'autres! Et du coup de parler des vérifieurs de vérifieurs de bytecode (!), en utilisant par exemple , si ce n'est pas hors sujet (mais je ne pense pas, ça rentre dans le cadre global de la vérification de bytecode).
Enfin il aurait été intéressant de faire une sorte d'ouverture sur les travaux en cours ou futurs qui sont prometteurs, comme les  par exemple.
====Bilan====
Du coup, la forme est à retravailler rapidement pour corriger les fautes d'orthographe et de grammaire. Le fond également pour étayer plus l'article sur ce qui a été dit, mais aussi sur ce qu'il reste à dire. On comprend le sujet, mais il manque des développements sur certains points ou carrément des points qui devraient être traités pour couvrir plus largement le sujet.
:AJOUT 24/01 : ce que j'aurai dit à l'oral
:
:Un effort est à faire sur la forme tout d'abord, parce qu'on se perd dans le sujet en corrigeant dans sa tête les fautes d’orthographe et de grammaire.
:Sinon sur le fond, il faudrait proposer d'autres sources surtout sur la partie des vérifications on-card. Les seules références sont celles des travaux de X.Leroy et son équipe, mais Rose, Barthe ou Mr.Grimaud ont également effectué des recherches académiques sur le sujet.
:Dans la partie Alternatives, il faudrait développer davantage et comparer Rose, Leroy, Casset et Deville d'un coté avec ce qui est vérifié par Jakarta, Jack ou STAN de l'autre.
:Ajout intéressant aussi peut-être et qui rentre dans le sujet : parler des failles dans cette vérification de bytecode java card. Parlez des vérifieurs de vérifieurs de bytecode, sans forcément faire un paragraphe entier si c'est hors sujet, mais au moins en mentionnant le fait que cela existe. J'ai proposé quelques sources dans mes commentaires ci-dessus.
:Voilà, c'est tout pour ma relecture.
:--Jako w (discuter) 24 janvier 2017 à 17:30 (CET)
thread_title: Relecture 2016-2017

message: Je traiterai d'abord de la forme, ensuite un peu plus du fond.
====La forme====
De manière générale des fautes d’orthographe sont présentes, le style n'est pas toujours encyclopédique ("nous allons voir", "dans cet article"...), un peu trop de jugement de valeur ("c'est relativement aisé", "triviale"...), les auteurs de travaux de recherche sont cités directement et je ne pense pas que ce soit wikipédiesque ("Xavier Leroy et son équipe", "D'après l'analyse de Xavier Leroy", "Dans cet article, nous allons parler de la méthode expliquée par Xavier Leroy"...) et la conjugaison est un peu trop variée (utiliser le présent de l'indicatif tout le temps, je pense).
Introduction : Résume bien le propos. On comprend le sujet.
Mise en situation : place bien le contexte. Par contre, pas sûr qu'il faille écrire "nous allons voir" dans un article wiki (il y aura d'autres remarques à ce sujet par la suite). Ça fait un peu trop rédaction.
Les Java Card et le développement d'applications : même remarque : "dans cet article", "nous allons nous intéresser", "nous allons voir maintenant"
Les enjeux de la vérification de bytecode Java Card : "tel des données" -> "telles des données"
Vérifications Off-Card : Type Deduction -> en italique ; "Cette partie de la vérification est relativement aisée et rapide" -> source ou ne pas juger ; "Ces quatre point" -> points ; "aient été vérifié" -> "soient vérifiées"
Vérifications On-Card : "Le schéma suivant" -> pas d'allusion au schéma dans le texte, il doit servir d'explication alternative ; "C'est ce qu'ont tenté de faire certains chercheurs..." -> pas sûr que ce soit dans le style de wikipédia, et il faudrait citer leurs travaux de recherches ici je pense
Fonctionnement : "Vu que ces 2 conditions sont..." -> "Ces deux conditions étant..." ; "quelques test effectué" -> "quelques tests effectués" ; "possible que l'on modifie" -> "possible de modifier" ; "Dans la partie suivante" -> idem
Modifications de code : "triviale", "très simple", "aisée"... -> jugements de valeur, je ne sais pas si c'est approprié ; "cet partie de l'algo..." -> "cette partie" ; "qui sorte" -> "qui sortent"
====Le fond====
Sinon on comprend le sujet et les sources présentes sont bien utilisées pour appuyer le texte.
Au départ je pensais qu'il aurait fallu développer un peu plus les attaques sur java car, mais ça aurait été hors sujet. Je trouve donc que ce qui est introduit dans la partie mise en situation est suffisant et présente bien les enjeux.
La partie sur les vérifications on-card est - je pense - trop centrée sur les recherches de X.Leroy et son équipe, il aurait fallu proposer d'autres arguments d'autres équipes de recherches en appui de X.Leroy. Ou éventuellement des équipes qui se sont inspirés de ces travaux pour faire eux-mêmes leur vérification. Par exemple  ou de , quitte à reprendre ces documents pour parler ensuite de la certification de Bytecode. D'autres travaux sur ces vérifications on-card pourraient être ajoutés, comme celui de Deville et Grimaud.
La partie sur les alternatives mériterait d'être plus développée. Jakarta par exemple avec les travaux de ,  ou la thèse de G.Defay (lien vers présentation). Ou parler du .
Je pense aussi qu'il aurait été très intéressant de parler des failles dans ces vérifieurs, en reprenant par exemple , et d'autres! Et du coup de parler des vérifieurs de vérifieurs de bytecode (!), en utilisant par exemple , si ce n'est pas hors sujet (mais je ne pense pas, ça rentre dans le cadre global de la vérification de bytecode).
Enfin il aurait été intéressant de faire une sorte d'ouverture sur les travaux en cours ou futurs qui sont prometteurs, comme les  par exemple.
====Bilan====
Du coup, la forme est à retravailler rapidement pour corriger les fautes d'orthographe et de grammaire. Le fond également pour étayer plus l'article sur ce qui a été dit, mais aussi sur ce qu'il reste à dire. On comprend le sujet, mais il manque des développements sur certains points ou carrément des points qui devraient être traités pour couvrir plus largement le sujet.
:AJOUT 24/01 : ce que j'aurai dit à l'oral
:
:Un effort est à faire sur la forme tout d'abord, parce qu'on se perd dans le sujet en corrigeant dans sa tête les fautes d’orthographe et de grammaire.
:Sinon sur le fond, il faudrait proposer d'autres sources surtout sur la partie des vérifications on-card. Les seules références sont celles des travaux de X.Leroy et son équipe, mais Rose, Barthe ou Mr.Grimaud ont également effectué des recherches académiques sur le sujet.
:Dans la partie Alternatives, il faudrait développer davantage et comparer Rose, Leroy, Casset et Deville d'un coté avec ce qui est vérifié par Jakarta, Jack ou STAN de l'autre.
:Ajout intéressant aussi peut-être et qui rentre dans le sujet : parler des failles dans cette vérification de bytecode java card. Parlez des vérifieurs de vérifieurs de bytecode, sans forcément faire un paragraphe entier si c'est hors sujet, mais au moins en mentionnant le fait que cela existe. J'ai proposé quelques sources dans mes commentaires ci-dessus.
:Voilà, c'est tout pour ma relecture.
:--Jako w (discuter) 24 janvier 2017 à 17:30 (CET)
thread_title: J.Wach0wiak

message: Du coup, la forme est à retravailler rapidement pour corriger les fautes d'orthographe et de grammaire. Le fond également pour étayer plus l'article sur ce qui a été dit, mais aussi sur ce qu'il reste à dire. On comprend le sujet, mais il manque des développements sur certains points ou carrément des points qui devraient être traités pour couvrir plus largement le sujet.
:AJOUT 24/01 : ce que j'aurai dit à l'oral
:
:Un effort est à faire sur la forme tout d'abord, parce qu'on se perd dans le sujet en corrigeant dans sa tête les fautes d’orthographe et de grammaire.
:Sinon sur le fond, il faudrait proposer d'autres sources surtout sur la partie des vérifications on-card. Les seules références sont celles des travaux de X.Leroy et son équipe, mais Rose, Barthe ou Mr.Grimaud ont également effectué des recherches académiques sur le sujet.
:Dans la partie Alternatives, il faudrait développer davantage et comparer Rose, Leroy, Casset et Deville d'un coté avec ce qui est vérifié par Jakarta, Jack ou STAN de l'autre.
:Ajout intéressant aussi peut-être et qui rentre dans le sujet : parler des failles dans cette vérification de bytecode java card. Parlez des vérifieurs de vérifieurs de bytecode, sans forcément faire un paragraphe entier si c'est hors sujet, mais au moins en mentionnant le fait que cela existe. J'ai proposé quelques sources dans mes commentaires ci-dessus.
:Voilà, c'est tout pour ma relecture.
:--Jako w (discuter) 24 janvier 2017 à 17:30 (CET)
thread_title: Bilan