I Écrivez un logiciel qui traite de diverses informations sensibles telles que des adresses électroniques, des mots de passe et des numéros de carte de crédit.
Lorsque nous avons des problèmes de mémoire, ce serait bien d'avoir l'application écrire un dépotoir de tas. Un problème est que le décharge de tas peut contenir des informations sensibles en texte brut si un thread arrive à travailler dans la région ... Nous ne voulons pas vraiment que l'écrit sur disque lorsque nous prenons de si grandes douleurs à crypter partout ailleurs.
Y a-t-il des moyens de traiter avec cela, comme causer la JVM d'écrire un vidage crypté?
3 Réponses :
La réponse courte n'est pas complètement. À un moment donné, vous devez avoir les données en clair pour l'utiliser et dans les VMS collectés à la poubelle, vous ne pouvez pas contrôler lorsque des objets sont physiquement retirés de la mémoire. La seule stratégie réelle visant à minimiser les risques consiste à supprimer toutes les références aux données confidentielles non cryptées le plus rapidement possible. Il ne garantira pas qu'aucune donnée confidentielle ne sera écrite dans une décharge mémoire, mais si quelqu'un peut le faire, ils peuvent déjà accéder aux informations critiques.
Mais assurez-vous de nuke la zone de mémoire avant de la différencier! (Ainsi, ne stockez jamais les mots de passe dans string objets, mais utilisez char [] à la place.)
Sur une note connexe, je devais faire des choses dans le passé, comme accepter le mot de passe d'un utilisateur, puis le transmettre à un appel WS, mais Jaxb n'a aucun moyen d'utiliser un tableau d'octets pour passer une valeur de chaîne. Est-ce que quelqu'un sait un moyen autour de cela?
@Chris, la mémoire "Nuking" en Java ne fonctionne pas. Le collecteur des ordures est libre de copier le contenu à tout moment, il serait donc laissé avec un objet non noué. Le seul que vous puissiez faire consiste à utiliser DirectChacterbuffer, pas de caractère [], il suffit d'utiliser un gros tampon et de la trancher car les tampons directs prennent au moins une page en mémoire. Et pour aggraver les choses, vous devez effacer toutes les traces dans les tampons de la prise. Dans l'ensemble, c'est un effort sans valeur.
@Chris, le JIT peut être assez bon pour optimiser la plupart des formes de "nuking" dans un non-op. S'il y avait un moyen de cacher ce type de données dans des programmes, il aurait été utilisé pour créer un logiciel de travail DRM / CopyProtection.
J'ai envisagé de manipuler cela à l'extérieur si le VM. Une approche naïve pourrait être d'avoir la JVM écrire le vidage à un périphérique de bouclage crypté. Bien sûr, cela n'est pas totalement sécurisé que quiconque ayant accès root peut accéder au point de montage, mais c'est le genre de solution que je m'attends. Je pourrais voir si je peux mettre en place une FIFO que la JVM finit par écrit. Je connais le nom de fichier que le VM utilisera, cela pourrait donc fonctionner en fonction de la manière dont la machine virtuelle va-t-elle faire face à cela (plus tard: cela ne fonctionne pas. Le JVM se plaint avec "fichier existant")
Utilisation de charcuterie n'hésite que le problème, mais il est toujours possible que la matrice contienne du texte brut au-delà.
Je vous enregistreriez, vous auriez eu le représentant sur un seul compte.
Même si vous le faites, les données ne vivent toujours pas comme un objet de tas géré à un moment donné. Je ne suis pas sûr de savoir où le point de rédaction de rendements est en perte de risque.
PayPal a récemment publié un outil pour supprimer les données sensibles des décharges de tas:
Wow, je suis intéressé à voir s'il y a une solution - c'est cher et boiteux, mais crypter tout dans vos objets
Toute personne avec un accès racine peut obtenir le vidage et / ou modifier l'application. Donc, je ne vois pas vraiment une raison de crypter quoi que ce soit. Vous pouvez obtenir une cuvette de tas avec n'importe quel processus Java.
Vous pouvez signer une NDA et des accords de sécurité avec quiconque pourraient regarder le dépotoir de tas ... J'essaie simplement de réfléchir ici.