Je profite du calme relatif de la période pour me torturer les méninges sur
une problématique de communication entre 2 équipements. En résumé, deux
machines A et B qui doivent pouvoir échanger des données en assurant :
- l'authentification mutuelle
- la confidentialité de l'échange
- la vérification d'intégrité de l'échange
C'est à dire rien de sorcier, si ce n'est qu'on met forcément dans la
balance des clés "secrètes" (soit les clés privées de A et B dans le cas
d'une authentification asymétrique, soit la clé commune à A et B dans le cas
d'une authentification symétrique). Or, A et B sont des équipements sans IHM
(donc sans utilisateur), et sans la possibilité de placer un SAM ou autre
moyen matériel pour stocker les clés. Tout ce dont je dispose, c'est un
système de fichier (en flash). Je suis donc à la recherche de la meilleure
solution (ou plutôt de la moins pire) pour réaliser un "coffre fort
logiciel".
Actuellement je ne vois qu'une seule solution: on met les clés à protéger
dans un fichier lui même chiffré avec une clé (symétrique) stockée "en dur"
dans le programme concerné. Je crois que j'ai fait le tour des inconvénients
(le clé se retrouve en désassemblant le programme, et de toutes façon est
est écrite dans les sources qui doivent donc être stockées dans un coffre en
Suisse). Y aurait-il quelque part une autre solution un peu plus élégante ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ludovic FLAMENT
Bonjour,
Actuellement je ne vois qu'une seule solution: on met les clés à protéger dans un fichier lui même chiffré avec une clé (symétrique) stockée "en dur" dans le programme concerné. Je crois que j'ai fait le tour des inconvénients (le clé se retrouve en désassemblant le programme, et de toutes façon est est écrite dans les sources qui doivent donc être stockées dans un coffre en Suisse). Y aurait-il quelque part une autre solution un peu plus élégante ?
Si le hard est propriétaire, c'est à dire que tu as la maîtrise totale de son contenu (mémoire, disque, cartes réseaux, ...) et que personne n'est censé y apporter de modifications (sinon perte de garantie et/ou pas de garantie de fonctionnement), tu peux envisager de générer ta clef de protection de ton fichier en utilisant des informations provenant du hard.
Ainsi, tu n'es pas obligé de conserver la clef de protection. Tu peux écrire un algo déterministe qui te donne ta clef secrète en fonction des informations hard (tu peux également ajouter des informations dans le soft pour diversifier un peu plus). Il suffit de mixer les informations et de garantir que tu vas toujours récupérer les mêmes valeurs d'entrée, donc attention aux sources de ces dernières.
Un avantage, c'est que deux produits n'auront pas les mêmes clef de protection (en fonction des informations hard que tu utilises), donc si tu achètes un équipement A et que tu arrives à dérober le fichier (de clefs) d'un équipement B, tu ne pourras pas le déchiffrer pour autant, ce qui est une propriété plutôt intéressante !
Actuellement je ne vois qu'une seule solution: on met les clés à protéger
dans un fichier lui même chiffré avec une clé (symétrique) stockée "en dur"
dans le programme concerné. Je crois que j'ai fait le tour des inconvénients
(le clé se retrouve en désassemblant le programme, et de toutes façon est
est écrite dans les sources qui doivent donc être stockées dans un coffre en
Suisse). Y aurait-il quelque part une autre solution un peu plus élégante ?
Si le hard est propriétaire, c'est à dire que tu as la maîtrise
totale de son contenu (mémoire, disque, cartes réseaux, ...) et que
personne n'est censé y apporter de modifications (sinon perte de
garantie et/ou pas de garantie de fonctionnement), tu peux envisager de
générer ta clef de protection de ton fichier en utilisant des
informations provenant du hard.
Ainsi, tu n'es pas obligé de conserver la clef de protection. Tu peux
écrire un algo déterministe qui te donne ta clef secrète en fonction des
informations hard (tu peux également ajouter des informations dans le
soft pour diversifier un peu plus). Il suffit de mixer les informations
et de garantir que tu vas toujours récupérer les mêmes valeurs d'entrée,
donc attention aux sources de ces dernières.
Un avantage, c'est que deux produits n'auront pas les mêmes clef de
protection (en fonction des informations hard que tu utilises), donc si
tu achètes un équipement A et que tu arrives à dérober le fichier (de
clefs) d'un équipement B, tu ne pourras pas le déchiffrer pour autant,
ce qui est une propriété plutôt intéressante !
Actuellement je ne vois qu'une seule solution: on met les clés à protéger dans un fichier lui même chiffré avec une clé (symétrique) stockée "en dur" dans le programme concerné. Je crois que j'ai fait le tour des inconvénients (le clé se retrouve en désassemblant le programme, et de toutes façon est est écrite dans les sources qui doivent donc être stockées dans un coffre en Suisse). Y aurait-il quelque part une autre solution un peu plus élégante ?
Si le hard est propriétaire, c'est à dire que tu as la maîtrise totale de son contenu (mémoire, disque, cartes réseaux, ...) et que personne n'est censé y apporter de modifications (sinon perte de garantie et/ou pas de garantie de fonctionnement), tu peux envisager de générer ta clef de protection de ton fichier en utilisant des informations provenant du hard.
Ainsi, tu n'es pas obligé de conserver la clef de protection. Tu peux écrire un algo déterministe qui te donne ta clef secrète en fonction des informations hard (tu peux également ajouter des informations dans le soft pour diversifier un peu plus). Il suffit de mixer les informations et de garantir que tu vas toujours récupérer les mêmes valeurs d'entrée, donc attention aux sources de ces dernières.
Un avantage, c'est que deux produits n'auront pas les mêmes clef de protection (en fonction des informations hard que tu utilises), donc si tu achètes un équipement A et que tu arrives à dérober le fichier (de clefs) d'un équipement B, tu ne pourras pas le déchiffrer pour autant, ce qui est une propriété plutôt intéressante !
"Ludovic FLAMENT" a écrit dans le message de news:43b25c82$0$300$
Si le hard est propriétaire, c'est à dire que tu as la maîtrise totale de son contenu (mémoire, disque, cartes réseaux, ...) et que personne n'est censé y apporter de modifications (sinon perte de garantie et/ou pas de garantie de fonctionnement), tu peux envisager de générer ta clef de protection de ton fichier en utilisant des informations provenant du hard.
Bonjour et merci de ta réponse. Effectivement le hard est propriétaire, mais pas vraiment opaque (c'est un Linux embarqué sur un processeur Axis plus quelques périphériques "métier"). A part l'adresse MAC (write-once dans le premier secteur de la flash intégrée au processeur), je ne vois pas de source de données pertinentes.
Ainsi, tu n'es pas obligé de conserver la clef de protection. Tu peux écrire un algo déterministe qui te donne ta clef secrète en fonction des informations hard (tu peux également ajouter des informations dans le soft pour diversifier un peu plus). Il suffit de mixer les informations et de garantir que tu vas toujours récupérer les mêmes valeurs d'entrée, donc attention aux sources de ces dernières.
Moui il vaut mieux que ce genre d'algo soit déterministe... Néanmoins c'est ce qui constitue dans ce cas la partie qui semble la plus faible, il faut évidemment tenir les sources secrets, et utiliser toutes les parades possibles et (in)imaginables pour que le binaire ne permette pas de comprendre trop facilement l'algorithme...
Un avantage, c'est que deux produits n'auront pas les mêmes clef de protection (en fonction des informations hard que tu utilises), donc si tu achètes un équipement A et que tu arrives à dérober le fichier (de clefs) d'un équipement B, tu ne pourras pas le déchiffrer pour autant, ce qui est une propriété plutôt intéressante !
Oui, je confirme, c'est une amélioration déjà significative par rapport à mon idée de base.
Cordialement,
-- Johann.D
"Ludovic FLAMENT" <ludovic.flament@free.fr> a écrit dans le message de
news:43b25c82$0$300$636a55ce@news.free.fr...
Si le hard est propriétaire, c'est à dire que tu as la maîtrise
totale de son contenu (mémoire, disque, cartes réseaux, ...) et que
personne n'est censé y apporter de modifications (sinon perte de
garantie et/ou pas de garantie de fonctionnement), tu peux envisager de
générer ta clef de protection de ton fichier en utilisant des
informations provenant du hard.
Bonjour et merci de ta réponse. Effectivement le hard est propriétaire, mais
pas vraiment opaque (c'est un Linux embarqué sur un processeur Axis plus
quelques périphériques "métier"). A part l'adresse MAC (write-once dans le
premier secteur de la flash intégrée au processeur), je ne vois pas de
source de données pertinentes.
Ainsi, tu n'es pas obligé de conserver la clef de protection. Tu peux
écrire un algo déterministe qui te donne ta clef secrète en fonction des
informations hard (tu peux également ajouter des informations dans le
soft pour diversifier un peu plus). Il suffit de mixer les informations
et de garantir que tu vas toujours récupérer les mêmes valeurs d'entrée,
donc attention aux sources de ces dernières.
Moui il vaut mieux que ce genre d'algo soit déterministe... Néanmoins c'est
ce qui constitue dans ce cas la partie qui semble la plus faible, il faut
évidemment tenir les sources secrets, et utiliser toutes les parades
possibles et (in)imaginables pour que le binaire ne permette pas de
comprendre trop facilement l'algorithme...
Un avantage, c'est que deux produits n'auront pas les mêmes clef de
protection (en fonction des informations hard que tu utilises), donc si
tu achètes un équipement A et que tu arrives à dérober le fichier (de
clefs) d'un équipement B, tu ne pourras pas le déchiffrer pour autant,
ce qui est une propriété plutôt intéressante !
Oui, je confirme, c'est une amélioration déjà significative par rapport à
mon idée de base.
"Ludovic FLAMENT" a écrit dans le message de news:43b25c82$0$300$
Si le hard est propriétaire, c'est à dire que tu as la maîtrise totale de son contenu (mémoire, disque, cartes réseaux, ...) et que personne n'est censé y apporter de modifications (sinon perte de garantie et/ou pas de garantie de fonctionnement), tu peux envisager de générer ta clef de protection de ton fichier en utilisant des informations provenant du hard.
Bonjour et merci de ta réponse. Effectivement le hard est propriétaire, mais pas vraiment opaque (c'est un Linux embarqué sur un processeur Axis plus quelques périphériques "métier"). A part l'adresse MAC (write-once dans le premier secteur de la flash intégrée au processeur), je ne vois pas de source de données pertinentes.
Ainsi, tu n'es pas obligé de conserver la clef de protection. Tu peux écrire un algo déterministe qui te donne ta clef secrète en fonction des informations hard (tu peux également ajouter des informations dans le soft pour diversifier un peu plus). Il suffit de mixer les informations et de garantir que tu vas toujours récupérer les mêmes valeurs d'entrée, donc attention aux sources de ces dernières.
Moui il vaut mieux que ce genre d'algo soit déterministe... Néanmoins c'est ce qui constitue dans ce cas la partie qui semble la plus faible, il faut évidemment tenir les sources secrets, et utiliser toutes les parades possibles et (in)imaginables pour que le binaire ne permette pas de comprendre trop facilement l'algorithme...
Un avantage, c'est que deux produits n'auront pas les mêmes clef de protection (en fonction des informations hard que tu utilises), donc si tu achètes un équipement A et que tu arrives à dérober le fichier (de clefs) d'un équipement B, tu ne pourras pas le déchiffrer pour autant, ce qui est une propriété plutôt intéressante !
Oui, je confirme, c'est une amélioration déjà significative par rapport à mon idée de base.
Cordialement,
-- Johann.D
Alain
Je profite du calme relatif de la période pour me torturer les méninges sur
une problématique de communication entre 2 équipements. ...
déjà, un douloureux conseil, essaye de lire un bouquin qui initie aux protocoles crytographiques de types très divers... ca donne des idées sur ce qui est faisable, classique et parfois même ca donne une solution... ca calmera aussi tes ardeurs quand tu lira les trous de sécu de protocoles très sympa en première lecture.
moi c'est avec applied crytography de bruce schneier que j'ai pris conscience de tout ca... ca calme. il y a peut être aussi complet en plus récent.
parcontre il y a peut être un protocole qui te va dans le lot...
a première vu comme discuté ici c'est mal parti... mais si tu ajoute quelques supposition réalistes du style : -> on peut lire la mémoire flash, mais ni donc lire un code lié au hardware local (numéro de série SECRET) peut être y at'il une solution... avec l'hypothèse précedent il suffirait d'utiliser le numéro de série secret comme mot de passe de décryptage de la clé...
mais cette hypothèse ne me semble pas réaliste car soit on peux pirater la machine et tout lire comme le programme, soit on n'arrive pas a faire éxécuter un code arbitraire et on ne peux rien lire (a part le firmware générique, supposé public, sans la clé)
sinon pense à ajouter un hardware de protection, même si c'est un micro-controleur lent qui décrypte ou génère la clé une fois par jour en une heure...
en tout cas c'est sur ces suppositions et sur quelques évolutions matérielles que la solution se trouve a mon avis.
Je profite du calme relatif de la période pour me torturer les
méninges sur
une problématique de communication entre 2 équipements. ...
déjà, un douloureux conseil, essaye de lire un bouquin qui initie aux
protocoles crytographiques de types très divers... ca donne des idées
sur ce qui est faisable, classique et parfois même ca donne une
solution... ca calmera aussi tes ardeurs quand tu lira les trous de sécu
de protocoles très sympa en première lecture.
moi c'est avec applied crytography de bruce schneier que j'ai pris
conscience de tout ca... ca calme.
il y a peut être aussi complet en plus récent.
parcontre il y a peut être un protocole qui te va dans le lot...
a première vu comme discuté ici c'est mal parti...
mais si tu ajoute quelques supposition réalistes du style :
-> on peut lire la mémoire flash, mais ni donc lire un code lié au
hardware local (numéro de série SECRET)
peut être y at'il une solution...
avec l'hypothèse précedent il suffirait d'utiliser le numéro de série
secret comme mot de passe de décryptage de la clé...
mais cette hypothèse ne me semble pas réaliste car soit on peux pirater
la machine et tout lire comme le programme, soit on n'arrive pas a faire
éxécuter un code arbitraire et on ne peux rien lire (a part le firmware
générique, supposé public, sans la clé)
sinon pense à ajouter un hardware de protection, même si c'est un
micro-controleur lent qui décrypte ou génère la clé une fois par jour en
une heure...
en tout cas c'est sur ces suppositions et sur quelques évolutions
matérielles que la solution se trouve a mon avis.
Je profite du calme relatif de la période pour me torturer les méninges sur
une problématique de communication entre 2 équipements. ...
déjà, un douloureux conseil, essaye de lire un bouquin qui initie aux protocoles crytographiques de types très divers... ca donne des idées sur ce qui est faisable, classique et parfois même ca donne une solution... ca calmera aussi tes ardeurs quand tu lira les trous de sécu de protocoles très sympa en première lecture.
moi c'est avec applied crytography de bruce schneier que j'ai pris conscience de tout ca... ca calme. il y a peut être aussi complet en plus récent.
parcontre il y a peut être un protocole qui te va dans le lot...
a première vu comme discuté ici c'est mal parti... mais si tu ajoute quelques supposition réalistes du style : -> on peut lire la mémoire flash, mais ni donc lire un code lié au hardware local (numéro de série SECRET) peut être y at'il une solution... avec l'hypothèse précedent il suffirait d'utiliser le numéro de série secret comme mot de passe de décryptage de la clé...
mais cette hypothèse ne me semble pas réaliste car soit on peux pirater la machine et tout lire comme le programme, soit on n'arrive pas a faire éxécuter un code arbitraire et on ne peux rien lire (a part le firmware générique, supposé public, sans la clé)
sinon pense à ajouter un hardware de protection, même si c'est un micro-controleur lent qui décrypte ou génère la clé une fois par jour en une heure...
en tout cas c'est sur ces suppositions et sur quelques évolutions matérielles que la solution se trouve a mon avis.
Sylvain
Johann.D wrote on 28/12/2005 11:06:
le hard est propriétaire, mais pas vraiment opaque (c'est un Linux embarqué sur un processeur Axis plus quelques périphériques "métier"). [...]
ben, "y-a-qu'à" mettre un coupleur carte sur la liste de périph. métiers
les procs Axis gèrent les ports séries et USB et si c'est un developer board, "y-a-qu'à" (bis) brancher (pour une distrib. de PC/SC sous Linux, je re-répèterais MUSCLE mais tu connais déjà).
il faut tenir les sources secrets, et utiliser toutes les parades possibles et (in)imaginables pour que le binaire ne permette pas de comprendre trop facilement l'algorithme...
marchera pas ;-)
un AXIS Etrax FS qui obtiendrait une clé de session d'une carte à puce (comme résultat d'une diversification impliquant un challenge local, un challenge de la machine cible et une clé maitre propre au client) puis moulinerait les échanges à 3Gbits avec ses petits neurones cablés pourrait faire un excellent controleur de réseau ...
Sylvain.
Johann.D wrote on 28/12/2005 11:06:
le hard est propriétaire, mais pas vraiment opaque
(c'est un Linux embarqué sur un processeur Axis plus
quelques périphériques "métier"). [...]
ben, "y-a-qu'à" mettre un coupleur carte sur la liste de périph. métiers
les procs Axis gèrent les ports séries et USB et si c'est un developer
board, "y-a-qu'à" (bis) brancher (pour une distrib. de PC/SC sous Linux,
je re-répèterais MUSCLE mais tu connais déjà).
il faut tenir les sources secrets, et utiliser toutes les parades
possibles et (in)imaginables pour que le binaire ne permette pas de
comprendre trop facilement l'algorithme...
marchera pas ;-)
un AXIS Etrax FS qui obtiendrait une clé de session d'une carte à puce
(comme résultat d'une diversification impliquant un challenge local, un
challenge de la machine cible et une clé maitre propre au client) puis
moulinerait les échanges à 3Gbits avec ses petits neurones cablés
pourrait faire un excellent controleur de réseau ...
le hard est propriétaire, mais pas vraiment opaque (c'est un Linux embarqué sur un processeur Axis plus quelques périphériques "métier"). [...]
ben, "y-a-qu'à" mettre un coupleur carte sur la liste de périph. métiers
les procs Axis gèrent les ports séries et USB et si c'est un developer board, "y-a-qu'à" (bis) brancher (pour une distrib. de PC/SC sous Linux, je re-répèterais MUSCLE mais tu connais déjà).
il faut tenir les sources secrets, et utiliser toutes les parades possibles et (in)imaginables pour que le binaire ne permette pas de comprendre trop facilement l'algorithme...
marchera pas ;-)
un AXIS Etrax FS qui obtiendrait une clé de session d'une carte à puce (comme résultat d'une diversification impliquant un challenge local, un challenge de la machine cible et une clé maitre propre au client) puis moulinerait les échanges à 3Gbits avec ses petits neurones cablés pourrait faire un excellent controleur de réseau ...
Sylvain.
Johann.D
"Sylvain" a écrit dans le message de news:43b33b67$0$19688$
Johann.D wrote on 28/12/2005 11:06:
le hard est propriétaire, mais pas vraiment opaque (c'est un Linux embarqué sur un processeur Axis plus quelques périphériques "métier"). [...]
ben, "y-a-qu'à" mettre un coupleur carte sur la liste de périph. métiers
Eh oui, la solution idéale... Sauf que la carte en question est déjà en production, et que le PRU a interdit cette option... Maintenant j'essaye de faire le moins pire possible compte-tenu de l'architecture imposée, mais avec les réserves d'usages...
les procs Axis gèrent les ports séries et USB et si c'est un developer board, "y-a-qu'à" (bis) brancher (pour une distrib. de PC/SC sous Linux, je re-répèterais MUSCLE mais tu connais déjà).
Oui, j'ai même déjà pratiqué sur l'Axis...
il faut tenir les sources secrets, et utiliser toutes les parades possibles et (in)imaginables pour que le binaire ne permette pas de comprendre trop facilement l'algorithme...
marchera pas ;-)
un AXIS Etrax FS qui obtiendrait une clé de session d'une carte à puce (comme résultat d'une diversification impliquant un challenge local, un challenge de la machine cible et une clé maitre propre au client) puis moulinerait les échanges à 3Gbits avec ses petits neurones cablés pourrait faire un excellent controleur de réseau ...
C'est pas encore un FS, juste un LX, et là il s'agit juste de "contrôler" un lecteur de badges sans contact... Je sais, on ne se refait pas... La version "musclée" (sans jeu de mot) a son Gemcore et ses 3 emplacements SAMs, mais sur cette version il va falloir faire sans...
Cordialement,
-- Johann.D
"Sylvain" <noSpam@mail.net> a écrit dans le message de
news:43b33b67$0$19688$8fcfb975@news.wanadoo.fr...
Johann.D wrote on 28/12/2005 11:06:
le hard est propriétaire, mais pas vraiment opaque
(c'est un Linux embarqué sur un processeur Axis plus
quelques périphériques "métier"). [...]
ben, "y-a-qu'à" mettre un coupleur carte sur la liste de périph. métiers
Eh oui, la solution idéale... Sauf que la carte en question est déjà en
production, et que le PRU a interdit cette option... Maintenant j'essaye de
faire le moins pire possible compte-tenu de l'architecture imposée, mais
avec les réserves d'usages...
les procs Axis gèrent les ports séries et USB et si c'est un developer
board, "y-a-qu'à" (bis) brancher (pour une distrib. de PC/SC sous Linux,
je re-répèterais MUSCLE mais tu connais déjà).
Oui, j'ai même déjà pratiqué sur l'Axis...
il faut tenir les sources secrets, et utiliser toutes les parades
possibles et (in)imaginables pour que le binaire ne permette pas de
comprendre trop facilement l'algorithme...
marchera pas ;-)
un AXIS Etrax FS qui obtiendrait une clé de session d'une carte à puce
(comme résultat d'une diversification impliquant un challenge local, un
challenge de la machine cible et une clé maitre propre au client) puis
moulinerait les échanges à 3Gbits avec ses petits neurones cablés
pourrait faire un excellent controleur de réseau ...
C'est pas encore un FS, juste un LX, et là il s'agit juste de "contrôler" un
lecteur de badges sans contact... Je sais, on ne se refait pas... La version
"musclée" (sans jeu de mot) a son Gemcore et ses 3 emplacements SAMs, mais
sur cette version il va falloir faire sans...
"Sylvain" a écrit dans le message de news:43b33b67$0$19688$
Johann.D wrote on 28/12/2005 11:06:
le hard est propriétaire, mais pas vraiment opaque (c'est un Linux embarqué sur un processeur Axis plus quelques périphériques "métier"). [...]
ben, "y-a-qu'à" mettre un coupleur carte sur la liste de périph. métiers
Eh oui, la solution idéale... Sauf que la carte en question est déjà en production, et que le PRU a interdit cette option... Maintenant j'essaye de faire le moins pire possible compte-tenu de l'architecture imposée, mais avec les réserves d'usages...
les procs Axis gèrent les ports séries et USB et si c'est un developer board, "y-a-qu'à" (bis) brancher (pour une distrib. de PC/SC sous Linux, je re-répèterais MUSCLE mais tu connais déjà).
Oui, j'ai même déjà pratiqué sur l'Axis...
il faut tenir les sources secrets, et utiliser toutes les parades possibles et (in)imaginables pour que le binaire ne permette pas de comprendre trop facilement l'algorithme...
marchera pas ;-)
un AXIS Etrax FS qui obtiendrait une clé de session d'une carte à puce (comme résultat d'une diversification impliquant un challenge local, un challenge de la machine cible et une clé maitre propre au client) puis moulinerait les échanges à 3Gbits avec ses petits neurones cablés pourrait faire un excellent controleur de réseau ...
C'est pas encore un FS, juste un LX, et là il s'agit juste de "contrôler" un lecteur de badges sans contact... Je sais, on ne se refait pas... La version "musclée" (sans jeu de mot) a son Gemcore et ses 3 emplacements SAMs, mais sur cette version il va falloir faire sans...
