Ma situation:
Le personnel médical souhaite entrer des données sensibles des patients dans un navigateur Web (!) Pour le stocker dans une base de données et la récupérer ultérieurement.
Ces données ne sont pas autorisées à être observées par quelqu'un d'autre, à l'exception du personnel médical lui-même. Cela signifie qu'il doit être crypté en utilisant un jeton secret avant qu'il ne soit transféré sur le serveur. Cela signifie également que ni le personnel informatique (avoir accès au serveur / base de données) ni à quiconque ne devraient pouvoir le déchiffrer sans le jeton secret. (Si le jeton est perdu, les données ne seraient plus accessibles.)
Aucun logiciel supplémentaire ne doit être installé sur la machine client, à l'exception de quelques jetons (par exemple, une clé privée) que l'on voudrait exporter une fois et l'importerait dans tous les navigateurs à partir duquel l'accès des données doit être accordé.
Donc, ma question est:
Y a-t-il un moyen de chiffrer / déchiffrer des données sur le côté client (par exemple, à l'aide de JavaScript) en utilisant un jeton de navigateur secret pouvant être échangé entre les navigateurs facilement (c.-à-d., exporté / importé de la même manière que les certificats X.509)? < / p>
Sinon, quelles solutions alternatives seraient possibles? Étant donné que les conditions 1 et 2 sont obligatoires, seules la condition 3 peuvent être modifiées, si nécessaire. Cependant, toujours aussi peu d'efforts d'installation que possible devraient être nécessaires sur le côté client.
EDIT: SSL ne fait évidemment qu'une partie de la réponse à cette question!
4 Réponses :
Il y a une implémentation JavaScript du cryptage AES qui crypte le plaintre dans le navigateur. Si vous construisez quelque chose autour de ces outils, le côté serveur stockerait uniquement le texte crypté et n'aurait pas la phrase secrète.
http://www.fourmilab.ch/javascrypt/
ne doit pas nécessiter une installation supplémentaire du côté du client, mais il faudra probablement besoin d'effort de développement pour obtenir l'expérience de l'utilisateur.
Jetez un coup d'œil à Cryptage Web-navigateur des informations personnelles de la santé , dont la section "abstraite" semble décrire votre même problème. Cependant, leur "code passe" qui génère la clé de cryptage doit être partagé, ce qui ne vous permettrait pas de différencier le personnel médial.
Nous décrivons un système de saisie de données distante qui permet aux données que identifierait le patient à crypter dans le navigateur Web de la personne entrant dans les données. Ces données ne peuvent pas être déchiffrées sur le serveur par le personnel du centre de données mais peut être déchiffré par la personne entrer dans les données ou leur délégué. Nous avons développé ce système pour résoudre un problème qui se pose dans le contexte de la recherche clinique, mais c'est applicable dans une gamme de situations où l'information sensible est stocké et mis à jour dans une base de données et il est nécessaire de s'assurer qu'il ne peut être visionné par aucun sauf ces accès intentionnellement donnés.
Merci pour votre suggestion! En principe, cela fonctionne. Nous avons déjà trouvé une implémentation similaire, inspirée par code.google.com/p/memords , qui suit la même approche.
@THOMAS Un moyen de contourner la réquisition d'une seule clé est une méthode que j'ai découverte est utilisée par, je pense, Boxcryptor. Lorsque certaines données sont créées, une clé symétrique est créée sur le côté de l'utilisateur (dans ce cas le navigateur), qui est ensuite crypté avec la clé publique asymétrique des utilisateurs et envoyée au serveur. Si cet utilisateur veut partager ces données, ils doivent prendre cette clé symétrique et le chiffrer avec la clé publique asymétrique du membre du personnel et le stocker sur le serveur en plus de leur propre (et de tout autre) cryptage de cette clé symétrique. ... (suite ci-dessous)
Sur Access, un utilisateur télécharge la clé cryptée avec leur clé publique, la déchiffrer et utiliser la clé symétrique pour déchiffrer les données principales. Cela nécessite toujours que la clé symétrique soit exposée à tous ceux qui ont accès, mais ils peuvent tous utiliser différentes paires de clés asymétriques. Si un utilisateur est retiré de l'accès, les données doivent donc être retenues avec une nouvelle clé.
En raison des efforts de ProtonMail, il existe maintenant une implémentation ouverte privée Source Source dans le navigateur à: https://openpgpjs.org/
Ceci a eu plusieurs audits de sécurité et constitue la base de Protonmail.com, il a donc un assez bon rapport qualité-prix. Ils ont également un bon résumé des modèles importants de navigateur de sécurité.
the API de Crypto a
J'ai trois lettres pour vous: S, S et L.
Non, veuillez lire ma question avec soin.
Je n'ai pas la réponse, mais je cherche probablement à la manière dont les œuvres OAuth peuvent vous donner des idées SIME.
Avez-vous regardé Virgil Security? C'est ce que j'utilise. Constituée Je ne traite pas des données hospitalières, mais vous pouvez gérer l'accès en chiffrant les données pour un certain ensemble d'utilisateurs PK.