Notre société vend des moteurs automobiles. Si le moteur vendu est cassé, nous voulons que le client (que le propriétaire du moteur) puisse exécuter notre application, qui lit les données du moteur et l'enregistre dans un fichier. Mon travail consiste à écrire cette application.
Mon problème est la sécurité du fichier. Si le fichier est stocké en texte brut, le client peut le modifier sans problème et nous ne le réaliserons pas (nous ne pouvions vraiment connaître que l'authenticité de ces données si le client nous envoie ce moteur de manière phiologique et nous gérons la demande nous-mêmes - qui coûte du temps et de l'argent). Je suppose donc que j'ai besoin de chiffrer le fichier, peut-être avec le cryptage AES.
MAINTENANT Le problème (SUB) devient comment stocker le mot de passe pour le cryptage. Un peu de googling m'a dit que cela ne peut pas être fait de manière sûre à 100%. La seule chose qui peut être utilisée est l'obfuscation, comme la cryptographie de la boîte blanche. Ce qui n'est pas sûr, et nos clients auront une grande motivation pour le crier.
Alors maintenant, je suis coincé à essayer de trouver une solution appropriée. Je me demande si beaucoup plus de personnes connaissent Stackoverflow peuvent me conseiller sur la façon de résoudre mon problème.
3 Réponses :
Quelles données extrayez-vous du moteur?
OBD Port?
Propriétaire?
Si vous ne voulez pas que votre code soit facilement inversé,
Vous pouvez considérer le matériel
https://www.google.com/search?q=Collyption+ IC & TBS = QDR: Y
Pour encore plus de sécurité,
Je recommanderais un homme d'une approche intermédiaire;
Ils vous envoient des données (par email, etc.),
Ensuite, vous avez un processus de lot,
Sur un serveur / réseau séparé
Comparer les données.
Les commentaires des clients remontent de la même manière.
Le client ne sait jamais quel réseau IP tout est sauvegardé.
Le seul moyen sûr d'y parvenir est de générer et de signer les données dans un environnement de confiance. Une application exécutée sur le PC du client ne fonctionne généralement pas dans un environnement de confiance. Si vous pouvez faire confiance au moteur (je suppose qu'il exécute une sorte de micrologiciel que vous pouvez communiquer avec), le moteur doit générer et signer le fichier et votre application doit simplement le transmettre.
BTW: Ne confondez pas le cryptage avec la signature. Si vous chiffrez un fichier, vous vous assurez que personne d'autre ne peut le lire, mais il n'y a aucune garantie contre la manipulation. Si vous signerez un fichier, vous le protégeez contre la manipulation. Si vous voulez les deux (protéger contre la manipulation et empêcher la lecture non autorisée), vous devez crypter et signer. La logique du cryptage et de la signature est un type d'inverse: la signature est effectuée avec une clé privée (vérification possible par quiconque ayant la clé publique). Le cryptage est effectué avec une clé publique (ne se prépare possible que par quiconque ayant la clé privée). Cela vous montre également votre problème de confiance: pour vous inscrire, vous devez livrer la clé privée (sic!) À votre client. Vous avez besoin de mesures pour prévenir l'extraction de cette clé privée. Ceci est fondamentalement impossible sans matériel spécial.
Aussi: faire une clé privée différente pour chaque client / moteur. Même avec du matériel spécial, quelqu'un pourrait peut-être extraire cette clé. Si c'est la même chose pour tous les moteurs, votre sécurité est cassée pour tous les moteurs.
Comme déjà mentionné par d'autres puts, vous aurez besoin d'un cryptage asymétrique avec 2 clés distinctes pour le chiffrement et la déchiffrement. Ainsi, AES sous forme de système de cryptage symétrique ne vous aidera pas. Les termes "public" et "privé" sont subjectifs, ce qui signifie que chaque1 peut savoir sur la clé publique mais no1 sauf une personne spéciale connaît la clé privée. Ces termes IMHO ne s'appliquent pas à votre cas; Les deux clés sont privées selon votre application. Je préfère les appeler "serveur" et "client" pour ce projet, et le serveur fait référence au serviteur de maintenance, tandis que le client est l'ECU du moteur. Le problème principal que vous rencontrez est la possibilité d'exposer la clé cliente via le téléchargement du microcontrôleur / fpga firmware par un pirate informatique. En supposant que la connexion RS232 pour la charge ou la mise à niveau du micrologiciel [Haut / Down], vous devez vous protéger contre la manipulation non autorisée du micrologiciel. Vous devez devoir étudier la tâche de modifier le chargeur de firmware pour utiliser un mot de passe unique pour l'authentification sur RS232, avant chaque virement du micrologiciel; L'intention de l'authentification est d'identifier une autorisation de l'agent de maintenance légale. Étant donné que la manipulation du microprogramme est faite en usine - en utilisant une connexion câblée directe - il n'y a aucun risque d'attaque man-in-the-intermédiaire.
"Tous1"?!? "No1"?!?! Est-ce un message texte?
Cela ressemble à une usecase typique pour la cryptographie de clé publique. Créez un KeyPair RSA, chiffrer les données avec la clé publique fournie avec votre application, déchiffrer avec la clé privée conservée dans votre entreprise.
Utilisez des dongs matériels ou jetez un coup d'œil si votre ECU dispose d'un stockage sûr pour les mots de passe.
Pourquoi doit-il être un fichier texte brut? Peut-être une simple base de données intégrée (comme E.G. SQLite) pourrait-elle être utilisée à la place? Quel type de données sauve-vous? Combien de données? Et pensez-vous vraiment que les utilisateurs ordinaires vont entrer dans le fichier de données (texte ou non) et tenteront de le modifier? S'ils le font et corrompt le fichier ou la saisie des données inexactes, c'est le problème de votre client et non. Vous pouvez gagner du temps en ajoutant une clause de non-modification au contrat que les clients sentent pour acheter votre logiciel.
Quoi que vous fassiez, n'essayez pas de créer votre propre schéma de cryptage sécurisé. Utiliser une norme d'industrie acceptée; Obfuscation n'est pas une sécurité. Comme suggéré par @ piet.t une forme d'infrastructure clés en public serait une bonne approche
Cette question peut obtenir une meilleure réponse sur le échange de sécurité
Je pense que c'est un peu trop large. C'est une question intéressante, mais c'est un peu indéfini. Pourquoi stocker un fichier sur l'ordinateur client qu'ils ne peuvent pas voir? L'application doit-elle continuer à éditer et à modifier ce dossier? Voulez-vous simplement jeter les données pour transmettre à un serveur? Etc...
Pourquoi ne pas simplement ajouter un code de hachage au fichier. Cela devrait détecter la falsification, je n'ai pas vraiment besoin d'avoir vraiment besoin de cryptage soufflé complet.