Ceci est une question de brainstorming sur ce qui est possible dans Java (ou non). Je veux savoir s'il est possible de cacher un secret au sein d'une classe et de prévenir plus que d'y accéder Voici ce que j'ai à l'esprit jusqu'à présent: peut-il être amélioré? Devrait-il être amélioré? Est l'idée de verrouiller un secret dans une classe de sécurité impossible à réaliser? EDIT Pertinence: Certaines personnes interrogent la pertinence de la question que je soumets ici. Bien que je pose une question générale afin de déclencher une conversation ouverte, il existe une application très concrète à cette classe: clarification: faits: problèmes résolus: concernant l'environnement d'exécution, nous devons distinguer deux cas: Si nous définissons un SecurityManager approprié de réflexion et de limiter les autorisations sur tout code sans fourchette chargé, notre secret est sûr. Le pirate informatique peut créer sa propre application avec son propre gestionnaire de sécurité et sécuriser le chargeur de classe. Cela pourrait charger notre code de la classe de classe et l'exécuter comme si c'était notre propre application. Dans ce cas, il pourrait briser le coffre-fort.
12 Réponses :
Non, vous ne pouvez pas intégrer un secret dans une classe de cette façon. Si vous avez compilé cela, je pouvais alors exécuter Une façon dont vous pouvez faire cela si vous n'essayez que de la valider, c'est de stocker un hash. Une fois que vous souhaitez valider l'entrée, HASH et comparez les hachages. strings sur le fichier de classe résultant et il pourrait y être là-bas.
Que voulez-vous dire exactement par 'Run Strings'? Comment ça fait la classe?
@ Jvstry: sur une boîte Unix, CD dans le répertoire où il y a le fichier class , puis faire strings - Safe.class . Il listera toutes les chaînes de caractères ASCII avec une longueur de quatre ou plus.
D'accord. J'ai édité le poste pour plus de clarification. Les instances de la classe ne sont créées que lors de l'exécution. Si oui, l'attaque des cordes tombe, correcte?
Les chaînes ne fonctionneront pas sur une classe Java car Java Strings sont des multiles et des chaînes à la recherche d'ASCIIZ. Peu de confort dans cela, bien que ...
@road à Yambourg: c'est vrai, mais si les chaînes sont uniquement composées d'ASCII, Strings les trouveront. Je l'ai essayé et cela a travaillé sur le code source de l'OP, au moins.
Non, ce n'est pas à l'abri de l'autre code Java. Votre secret pourrait être récupéré à partir d'une instance de update: Si vous contrôlez le chargement de l'autre code Java Que vous souhaitez cacher le secret de votre part, vous pouvez probablement utiliser un Votre question modifiée est toutefois mentionnée que le code peut exécuter sur n'importe quel bureau ou périphérique. Dans ce cas, vous ne pouvez vraiment rien faire pour protéger le secret des autres processus qui pourraient faire à peu près n'importe quoi. Même si vous le cryptez dans la mémoire, un autre processus peut simplement intercepter la clé ou même le secret de la nature comme étant transmis. Si vous ne contrôlez pas l'environnement dont vous avez besoin de quelque chose pour être en sécurité besoin d'envisager une approche différente. Peut-être que vous pouvez éviter de stocker le secret en mémoire? Safe comme ceci: CustomingMeyManager ou Classloader pour empêcher l'accès à celui-ci. Vous devez contrôler l'environnement que cela fonctionne pour travailler, par exemple. Un serveur que vous limitez l'accès à.
Ok, alors crypterait le secret de faire toute différence?
Le cryptage de la chaîne peut fonctionner si la clé est indisponible pour l'autre code. Cela pourrait être capable de le trouver ailleurs, par exemple. le système de fichiers.
La classe ne pourrait-elle pas être protégée par un chargeur de classe sécurisé empêchant la réflexion?
Ceci est vrai, mais pas vrai à la notion de "sécurité" car cela signifie organiser l'orientation. Si vous êtes en mesure d'utiliser la réflexion, vous pouvez tout aussi facile à utiliser sun.misc.unsafe ou une bibliothèque C pour numériser la RAM. Rien n'est vraiment sûr.
@GlowCoder Pouvez-vous clarifier ce que vous entendez par: "Sécurité" car cela signifie organiser l'orientation? Est-ce juste une question de sémantique ou voyez-vous une autre violation?
@GlowCoder Sun.Misc.unsafe est une caractéristique de Java, le reste n'est pas (il ne fait donc pas partie de la question). Savez-vous si on peut casser le chargeur de classe sécurisé avec Sun.Misc.unsafe?
Ce que je veux dire, c'est que l'orientation objet (et la langue java) fournit des mécanismes pour la dissimulation d'informations. La définition typique de la sécurité en ce qui concerne l'orientation de l'objet est que vous utilisez des mécanismes oo-mécanismes disponibles pour masquer vos informations. En ce sens, vous êtes aussi sûr que vous pouvez obtenir. Pour que vous puissiez considérer cela une question de sémantique, mais je considérerais qu'il était fondamental de la nature de la POO.
@Jvestry no, je ne sais pas hors tension ce que dangereux peut casser.
@GlowCoder, j'obtiens ce que tu veux dire. Je comprends la définition que vous parlez. Ce n'est pas ce que je veux dire par «sûr», c'est plus comme si j'essaie de verrouiller un secret (si possible).
@ Whitefang34 J'ai vu votre édition et après avoir fait plus de lecture, j'arrive à la même conclusion que vous. Je vais mettre une prime à soulever plus d'attention à cette question et à voir si quelqu'un vient avec un nouvel angle.
Vous pouvez l'empêcher de le fichier .Class en utilisant Proguard ou des outils similaires. Vous pouvez également signer votre pot afin que d'autres packages ne peuvent pas y accéder. Signer votre pot peut vous aider aussi.
J'ai édité le poste pour plus de clarification. Les instances de la classe ne sont créées que lors de l'exécution.
L'obfuscation et la signature peuvent ralentir, mais ne vous aidera pas.
@ Jverstry - qu'entendez-vous par là? Où d'autre serait-il créé des exemples? C'est inutile que route de Yambourg souligne ci-dessus.
@Mebigfatguy Certains des commentaires apportés auparavant impliquaient que le secret pourrait être stocké dans le code lui-même. Par conséquent, on pourrait analyser ce code.
Vous pouvez faire un secret "fort" à accéder, mais vous ne pouvez pas le rendre impossible. Il y a un dicton (Bruce Schneier je crois): contre un utilisateur occasionnel, tout fonctionne. Contre un cracker déterminé rien ne fonctionne.
@Seandes Oui, oui, je sais que je pourrais ouvrir mon PC et utiliser un outil pour analyser la RAM, mais la question est limitée à l'utilisation du code Java et ses fonctionnalités pour y parvenir.
@ Jorstry comprise; Mais gardez tout simplement à l'esprit que vous venez de l'enterrer sous feuilles; Ce n'est pas une sécurité serrée. Ceci est fait tout le temps dans le monde réel cependant. (ex. DVD 'Security')
Ce n'est pas une sécurité par l'obscurité. La sécurité par l'obscurité est lorsque des charnières de protection sur l'algorithme sont secrètes. Cela ne le fait pas. Cela dépend de la JVM préservant ses informations qui cachent des abstractions contre la sérialisation, la réflexion et similaires.
@ Mike "Security Bien que l'obscurité" ne soit peut-être pas le terme précisément correct ici, mais nous nous appuyons sur l'accès à la restriction JVM. Et ça ne va pas empêcher un cracker d'empêcher d'autres moyens.
@Seand, s'il vous plaît ne jetez pas autour des énoncé vagues comme "la sécurité par l'obscurité". Les vagues craintes non fondées peuvent conduire les gens à adopter des alternatives moins sûres.
Mike est correct, ce n'est pas "via obscurité". Juste un choix inadéquat de mesures de sécurité.
Cette "sécurité" est risible.
Où est-ce qu'il court? Sur mon bureau? Je me connecte à la JVM avec du débogueur et affiche tous les secrets dans Texte clair.
ou je place mon code à côté de lui et utilisez la réflexion pour vider le contenu.
ou j'injecte ma propre modification de code via BCEC et modifiez le constructeur de sécurité pour vider la valeur "Secret" à un fichier.
ou je remplace simplement l'ensemble de l'ensemble avec le mien avec le même nom en le plaçant dans la chargeur de classe Bootstrap.
ou je peux même modifier et compiler des sources Java pour obtenir une JVM modifiée.
ou ... mon, on peut énumérer des dizaines de façons d'extraire une valeur d'une instance d'exécution!
La vraie question dans n'importe quel design de sécurité est la suivante: Qui est un attaquant ? Quel est le modèle de menace? Sans répondre à cela, le sujet est inutile.
Pour ce cas, vous ne pouvez pas utiliser de débogueur (c.f. question). Un chargeur de classe sécurisé vous empêchera d'utiliser une réflexion. À propos de BCEL, le secret est passé à l'exécution du constructeur, je ne vois pas comment BCEC aiderait ici. Si vous voyez toujours une violation dans ces contraintes / faits, veuillez partager. Merci.
Je contrôle jvm. Je peux définir une politique de sécurité que je veux. Je peux pré-charger toutes les classes que je veux, y compris ma propre implémentation de SecureClassloader. Je suis un dieu et un tsar sur mon jvm.
Roadto Yambourg a raison. Soit vous faites confiance au client et vous n'avez pas à vous soucier de votre secret pour être volé ou que vous ne lui faites pas confiance, vous ne pouvez pas faire n'importe quoi pour le pirater. Si vous ne faites pas confiance au client, vous devriez garder le secret de votre côté ou sur un autre côté de la violence.
Nice liste, et observation sur place que si le plateforme d'exécution est compromis, rien de programme ne peut faire. Pour compléter votre liste: On pourrait également faire en sorte que la JVM déverrouille son tas en envoyant le signal de système d'exploitation approprié, on pourrait inspecter la mémoire du processus JVM, en RAM ou au fichier de swap. Si tout le reste échoue, on pourrait simplement tirer le cordon d'alimentation, déplacer les copeaux de RAM sur un autre ordinateur, le démarrer avec un système d'exploitation spécialisé et lisez le contenu de la RAM de cette façon. (RAM maintient son état pendant quelques minutes après la mise hors tension).
@road à Yambourg, vous avez oublié de mentionner JNI, qui ne prend aucun avis de responsables de la sécurité / de sécurité. @meriton, je suis à peu près sûr que Dram ne garde que son état pendant quelques secondes.
@Peter Lawrey: secondes à quelques minutes à la température de fonctionnement, des dizaines de minutes si refroidi, conformément à la recherche par Ed Felten et al.: Freedom-a-Tinker.com/blog/felten/...
http://code.google.com/p/joe-e/ est un sous-ensemble de capacités d'objet de Java, qui est censé permettre une sécurité décomposable - la capacité d'une partie d'un programme de préserver ses propriétés de sécurité, même lorsque d'autres parties du programme sont contrôlées, compromises ou manipulées par un attaquant. < / p>
Cela dit, des JVM valides sont autorisés à étendre la sémantique de la langue avec des installations linguistiques supplémentaires, telles que la possibilité d'attacher un débogueur à l'exécution. Code qui peut utiliser Joe-e désactive beaucoup d'abus réfléchissants de cachette de l'information qui pourrait compliquer cela, et bien sûr désactive un accès non filtré à exécution pour invoquer l'accès à Shell pourrait attacher un débogueur à de nombreux actions et contourner des limitations d'accès privées si le JVM est configuré de manière à ce que la réflexion normale respecte le champ privé ness.
Runtime . .
Intéressant. Mais vous auriez besoin de plus que des fonctionnalités de code Java et de Java pour accéder au secret (c'est-à-dire un débogueur), correct? De plus, Calling Exec peut être désactivé par le chargeur de classe sécurisé.
Droit. Donc, un pirate informatique doit gérer ce Joe-e pour m'empêcher de briser ce code ... Hmm ... quelque chose ne va pas dans cette image. Peut-être que c'est le fait qu'un pirate informatique exécuterait plus probablement une version spécialement modifiée de JVM que aide lui pour casser le code?
@road à Yambourg, non, une équipe se développe à l'aide de Joe-e peut être convaincue que le développeur le plus faible entre eux ne peut pas compromettre les propriétés de sécurité du code de tous. Pensez à un système d'exploitation. Les développeurs de noyau utilisent des modes de processeur de sorte que la sécurité du système d'exploitation ne puisse être brisée par chaque pilote de périphérique et auteur d'applications. Joe-E fournit la même chose pour le code de la bague utilisateur, mais au lieu de modes de processeur, les limites des objets sont la barrière.
Je pense que vous pouvez le faire, mais vous finissez par pousser le problème de sécurité ailleurs. Y a-t-il une raison quel "secret" ne peut-il pas être crypté en utilisant (pour simplicité) votre algorithme de clé symétrique préféré? La méthode gimméthesecret () devrait prendre un paramètre supplémentaire étant l'utilisation de la clé secrète pour déchiffrer le secret.
Bien sûr, le problème devient que cette clé secrète doit être connue et entrée par un utilisateur ou une machine qui le stocke quelque part en toute sécurité. Vous pouvez utiliser une sorte de module de sécurité matérielle en fonction de la sensibilité des données et de la quantité que vous souhaitez dépenser!
Je pourrais en effet demander un certificat de l'utilisateur lorsqu'il demande des informations d'identification et appliquer les méthodes cryptographiques traditionnelles pour renvoyer le secret. Je ne suis pas sûr que l'on acceptait de me donner sa clé privée, car je pourrais la copier, mais je pourrais lui donner une copie du secret crypté.
Si je le poursuit, cela signifie que j'ai besoin d'une clé de cryptage pour commencer (pour mon constructeur) ou que l'on devrait fournir le secret crypté à mon constructeur. Angle très intéressant. Même si on tripes avec le code, ils n'acciteraient que le secret crypté. Merci!
Bien sûr, si le pirate informatique contrôle sur le contexte du code crypter le secret, nous sommes toastés, mais toujours ...
Oui, cela suppose que le secret est crypté pour commencer et est chargé sous sa forme cryptée.
En supposant que les informations passées aux appels de méthode soient sûres, une clé est une bonne solution. La clé n'a pas besoin d'être stockée nulle part dans l'application et, à cette fin, les informations ne sont pas accessibles via Java uniquement. Il devient intéressant si vous voulez un moyen de partager le secret avec d'autres sans leur donner votre clé, ce que la méthode Sharesecret est inférieure. Cependant, il devient difficile de gérer cela. Un processus pourrait être:
1) Le demandeur secret demande accès, entrant une clé Temp stockée
2). Le gardien secret accède à leur clé, la clé temporaire est supprimée et une temp. L'objet sécurisé est créé qui fonctionne pour la clé tempe.
3) Le chercheur secret entre dans la touche Temp et une clé permanente, l'objet Temp Safe est supprimé et un nouvel objet de sécurité permanent est créé qui peut être créé. accessible avec la clé permanente.
Encore une fois, en supposant que les paramètres passés à des appels de méthode sont sûrs, le principal problème de la procédure ci-dessus est que quelqu'un aurait pu pirater la clé temporelle entre 1 et 2 et l'utiliser pour afficher le secret de Temps entre les étapes 2 et 3. Cependant, cela rendrait plus difficile de fissurer que de le stocker dans une chaîne de texte brut.
Comme mentionné avec @alpian, les clés de passage de mon coffre-fort ne sont pas en sécurité, à moins que ce ne soient publics (ou certificats). Certains algorithmes de cryptage permettent à DRIP (A, ENCR (B, ENCR (A, SECRET))) = ENCR (B, SECRET), qui éviterait de faire passer la clé privée / décodante à Sharesecret. Cette méthode reviendrait aucr (B, ENCR (A, Secret)). Si l'utilisateur ne sait pas DRIP (A, SECRET), nous pouvons décider de ne pas encoder le secret de la classe en premier lieu et retour (ENCRB, (secret)) qui ne serait lisible que pour cet utilisateur ... i Je ne suis pas vraiment sûr quel angle / problème vous essayez de résoudre ici, pouvez-vous clarifier?
@ Jverstry Oui, vous auriez besoin de sauvegarder le processus de saisir et de passer des clés. Le problème que j'essayais de résoudre est le suivant: Disons que l'utilisateur 1 et l'utilisateur 2 ont plusieurs secrets et chacun utilise une seule touche unique pour accéder à tous leurs secrets. Le problème que j'essayais de résoudre concerne la manière dont l'utilisateur 1 et l'utilisateur 2 pourrait partager un seul secret les uns avec les autres sans que l'application stocke jamais ses clés. Toute méthode de ré-chiffrement Quelque chose besoin de la clé de décodage et de la nouvelle clé, ainsi que la raison pour laquelle j'ai suggéré une clé temporaire au milieu qui est le seul qui est stocké.
@ Jvestry dans un "environnement contrôlé" où les utilisateurs peuvent exécuter "code non approuvé tente de casser notre" coffre-fort "", je pense toujours que vous seriez mieux avec crypter le secret, car l'utilisateur pourrait exécuter le code pointé par Whitefang34 à accéder au secret.
@ Jvestry également, dans un "environnement incontrôlé" où un pirate informatique doit commencer l'application, car aucun secrets ne serait là, il n'y aurait rien à protéger.
Certaines personnes interrogent la pertinence de Le problème que je soumets ici. Même si Je demande une question générale dans afin de déclencher une conversation ouverte, Il y a une application très concrète à cette classe:
Si je veux déchiffrer des messages, je besoin de charger des données de clé privées dans un classer. Si je ne peux pas empêcher d'autres java code d'y accéder, alors il est impossible de créer un système sécurisé. Bien sûr, si je veux déchiffrer un message, je devrais plutôt le faire dans le classe que de donner le secret, mais Néanmoins, le coffre-fort doit rester incassable.
Premier en sécurité, incassable n'existe pas. Il y a de petites chances que, par hasard, je trouve votre clé d'entreprise en écrivant des choses aléatoires sur mon clavier. Si votre clé est complexe, vous feriez un homme vraiment malchanceux, mais cela est possible.
Deuxième point, à l'aide d'une paire de valeurs de clé publique / privée pour protéger les communications entre un client et un serveur est vraiment courante et fonctionne parfaitement si elle est bien faite. Mais il faut comprendre que cela protégeait vraiment la communication entre les deux ordinateurs. Cela ne protège pas l'ordinateur eux-mêmes. Le tout est basé sur la confiance totale de l'ordinateur de l'autre.
Troisième point, lorsque vous avez Accès physique à un ordinateur, vous pouvez faire tout ce que vous voulez avec elle, notamment en espionnant tout un programme. Et tout le contenu de l'ordinateur. Le contenu peut être crypté oui, mais tout en étant utilisé, il n'est plus crypté. C'est un problème majeur du système de clé publique / privé: la clé privée est stockée quelque part, vous devez donc être sûr que cet endroit est sûr.
Ce flux peut être parfaitement acceptable pour vous si vous faites confiance aux ordinateurs impliqués dans la communication. C'est le cas de l'exemple lorsque vous vous connectez à votre compte bancaire.
Les ordinateurs bancaires font confiance à la banque et l'accès fourni au mot externe est vraiment restreint et contrôlé. Ils sont "sûrs".
Si vous donnez votre propre clé privée ou votre identification d'accès à la banque. Vous êtes compromis, mais c'est votre responsabilité et votre problème. Parce que ce n'est pas dans votre interrest d'être compromis, vous ferez de votre mieux pour éviter cela. C'est bien, parce que vous êtes celui avec le contrôle total sur votre ordinateur.
Mais laissez-vous accéder à votre banque d'un ordinateur public ou d'un ordinateur d'une autre personne. Ensuite, un simple keylogger peut simplement enregistrer les touches et le déplacement de la souris que vous faites lorsque vous entrez votre mot de passe.
La sécurité de la clientèle est basée sur la confiance que vous pouvez avoir sur le client. Si vous pouvez lui faire confiance, c'est parfait, ça marche. Si vous ne pouvez pas, alors il est cassé.
Il y a un autre angle à ce problème: Java a livré des autorisations. Dans un contexte où l'environnement est contrôlé, on peut attribuer un ensemble d'autorisations aux classes chargées avec un chargeur de classe sécurisé.
Java fournit 3 objets d'autorisations relatives à la mise en œuvre de la sécurité:
PrivatEcrefredEnpermission SecurityPermission Authermission
Ceux-ci peuvent aider à améliorer et à contrôler l'accès aux fonctionnalités lors de la mise en œuvre d'un système de cryptographie. Ils sont nécessairement suffisants pour sécuriser le système.
Si vous devez exécuter un code non approuvé, le meilleur moyen de le faire est de l'exécuter dans une JVM séparée. De cette façon, le code non approuvé peut recevoir les limitations les plus strictes et même être tué si, par exemple, vous avez une cpu à l'écart ou une crash de la JVM. Le seul accès que le code peut faire est via les moyens que vous lui fournissez une réflexion d'utilisation ne vous donnera pas accès à des classes dans un autre JVM, peu importe ce que vous faites.
Vous pouvez même construire une prison ou un labyrinthe pour votre application. Cela peut permettre au code non approuvé de fonctionner dans ce qui semble être un système réel, mais en réalité ce n'est pas le cas. (Le but dont il est de vous attacher tout le pirate de hackeur suffisamment longtemps pour voir ce qu'ils font)
Vous pouvez même exécuter le JVM dans sa propre machine virtuelle, il semble que vous ayez un système complet (mais factice) pour "envahir". Une machine virtuelle peut être sauvegardée pour analyse et essuyée à un état prédéfini très facilement.
La solution ultime consiste à placer le code non approuvé sur un réseau local mannequin. (Quelque chose qu'ils ont fait pour analyser le ver Stuxnet.;)
Ajout d'un commentaire pour quelqu'un d'autre qui trébuche sur ce vieux fil ....
Parfois, tout ce dont vous avez besoin est une valeur "signée", pas une valeur "cryptée". E.G., (codé) Les jetons de licence doivent être signés mais ils ne devraient pas nécessairement être cryptés. Dans ces cas, vous pouvez distribuer la clé publique et ce n'est pas un problème que quiconque peut le voir. Vous êtes toujours protégé puisque personne d'autre ne peut créer le jeton signé.
Vous pouvez également utiliser la clé publique pour envoyer des messages cryptés au serveur.
Bien sûr, cela n'arrêtera pas un attaquant compétent et déterminé - voir les autres réponses. Dans ce cas, quelqu'un pourrait simplement remplacer votre clé publique avec leur propre, en particulier. Si vous ne validez pas la chaîne CERT. Mais si vous pouvez utiliser des signatures au lieu d'un cryptage, cela vous permettra de sauvegarder des maux de tête majeurs.
Non, il n'y a pas. La sécurité par l'obscurité échoue dans tous les cas à peu près.
@Brian Roach Ok, mais dans ce cas, comment rompez-vous la classe décrite ci-dessus?
Pouvez-vous clarifier ce que vous essayez spécifiquement de vous protéger? Où se passe ce code et quelles menaces potentielles sont là? Par exemple. Est-ce dans un environnement de serveur déployé et vous êtes inquiet à propos de l'autre code d'accès à un secret ou est-il en cours d'exécution sur un périphérique client comme un téléphone ou une applet.
@ Whitefang34 J'ai fait une autre modification. L'objectif est de s'assurer que d'autres personnes ne peuvent pas avoir accès au secret.
Si vous faites un hasch du secret et que vous magasinez, alors personne ne peut l'obtenir, mais vous pouvez vérifier qu'une classe client a le secret en comparant un hachage de leur "secret" fourni au hash. en.wikipedia.org/wiki/cryptographic_hash_function
@Yar OK, mais la classe doit restaurer le secret simple, non seulement stocker un hachage
Ouais, les hachages sont une sorte d'agressive de cette façon. Il est difficile de récupérer vos données.
J'ai apprécié les "instances ne sont pas fabriquées au moment de la compilation", BTW.
J'ajoute une prime pour attirer l'attention. Si quelqu'un a plus d'angle de partager sur cette question, faites-le nous savoir. Merci.
La question est plus ce que voulez-vous atteindre avec ce secret? Pourquoi avez-vous besoin du tout pour le stocker sur le client? Quel est le besoin de l'entreprise? Répondre à cette question nous permettrait de mieux comprendre le problème et quelles sont les meilleures pratices dans ce cas.
La question est une question générale sur la sécurité et la sécurité Java. Je veux savoir ce qui est possible quand il s'agit de tenir un secret (facteurs, conditions, etc.). C'est une question d'exploration.
Cette question n'a pas de réponse générale, tout comme "quelle serrure est la meilleure pour ma porte?". Dans quel quartier vivez-vous? Certains ne nécessitent aucun verrouillage du tout, dans certains, vous feriez mieux d'avoir une porte en métal avec des barres à travers. Idem ici: la question n'a pas de sens jusqu'à ce que vous décidiez qui est votre attaquant.
Vous avez votre question générale. Ici, une réponse générale: vous ne pouvez pas stocker et utiliser un secret dans un environnement incontournable. Il n'y a pas de bonne affaire pour cela. Nous avons déjà expliqué pourquoi. Même sur votre serveur bien-aimé, vous devez faire confiance à votre administrateur, vous devez faire confiance au gardien ... Ce n'est pas lié à Java. Vous êtes-vous déjà demandé pourquoi tous les logiciels que vous pouvez installer endup être piraté? Pensez-vous vraiment que vous pouvez faire mieux que Sony ou Microsoft? Si une solution était disponible et bien savoir pourquoi en enfer ne l'utiliserait pas au lieu d'être piraté?