Nous avons configuré un produit Java à utiliser uniquement des fournisseurs de crypto de RSA Validés. Cependant, le produit ne fonctionnera pas lorsque seuls em> Les bibliothèques RSA sont répertoriées dans Java.Security. Par conséquent, quelque chose demande des algorithmes non-FIPS d'un autre fournisseur. P>
Par le processus d'élimination, nous pouvons dire quels pots sont nécessaires pour une opération réussie, mais cela ne nous dit pas quels algorithmes sont demandés, ou par qui. p>
Cela semble être une question fréquemment posée, mais nous n'avons évidemment pas trébuché sur la bonne documentation ou la chaîne de recherche Google: existe-t-il un mécanisme fiable, pratique et cohérent pour déterminer quels fournisseurs de la JCE sont utilisés dans un Exécution d'une instance JVM? em> p>
4 Réponses :
fait system.setproperty ("javax.net.debug", "tout") code> vous donne quelque chose d'utile? p>
Merci Dave, mais non, cela ne semble pas fournir le type d'informations que nous recherchons (nous utilisons plus que des SSL / TLS). Ce que nous recherchons vraiment, je suppose, est un "crochet" dans JCE qui nous donnerait une trace de pile (ou quelque chose) qui indiquerait quelles cyphères sont allouées deux que (ou qui). L'architecture JCE ne semble pas supporter ce genre de comportement.
Eh bien, vous pouvez énumérer des fournisseurs en utilisant Security.getProviders () ; P>
voici Un exemple de fournisseur d'inscriptions et les algorithmes qu'ils implémentent . < / p>
Merci Bruno. Avoir cette liste est utile, mais je suis toujours à perte de déterminer quels clients reçoivent des algorithmes à partir de quels fournisseurs au moment de l'exécution. Le produit doit fonctionner uniquement avec des algorithmes certifiés FIPS, ou si cela n'est pas possible, nous devons être en mesure d'expliquer / justifier quels clients ne le sont pas et pourquoi pas. Jusqu'à présent, nous n'avons pas découvert un moyen d'obtenir cette information.
Aucune idée tbh, sauvegarder l'instrumentation du code au moment de l'exécution qui semble tout à fait l'arme émoussée.
Je vais suggérer de mettre en œuvre votre propre chargeur de classe a>, et avoir des informations de débogage du journal. p>
Cependant, je ne suis pas sûr de savoir si cela vous permettra de savoir chaque classe qui charge FOOJCEProvider, et pas seulement la première classe à charger FOOJCEProvider. P>
Alternativement, avez-vous essayé d'utiliser JConsole ? "La classe Chargement MBean possède également l'attribut verbose, qui peut être réglé pour activer ou désactiver le chargement de la classe tracing verbose" p>
J'ai été mis à jour momentanément lorsque vous avez mentionné le chargeur de classe, mais comme vous le soulignez, cela pourrait également avoir des lacunes. Je pense que je vais toujours enquêter plus loin cependant, pour voir quel est le comportement réel.
Comme Bruno indiquait, vous pouvez parcourir tous les fournisseurs. p>
au moment de l'exécution Vous pouvez vérifier quel fournisseur votre chiffrement utilise avec le getProvider méthode. P>
Peut-être que je n'étais pas assez clair dans mon message original ... Ceci est un produit tiers, que nous devons configurer pour utiliser des fournisseurs validés de FIPS seulement i> (RSA). Étant donné que le produit ne fonctionnera pas correctement avec uniquement i> RSA installé dans la JRE, nous essayons de déterminer quelles fonctionnalités / composants utilisent les fournisseurs non-FIPS. Cela doit être fait "de l'extérieur" d'un produit assez complexe, qui comprend des services / des démons, ainsi que des éléments d'interface graphique basés sur l'éclipse et basé sur le navigateur. Notre tentative initiale de créer notre propre fournisseur JCE à «Hook» Les demandes de moteur Crypto n'ont pas été couronnées de succès.