Qqun peut-il m'aider à trouver des informations sur comment encrypter des
messages (max 50bytes/message) qui vont transiter sur réseau via une
connexion TCP/IP entre d'une entre d'une part un serveur PC et d'autre
part des clients qui sont des systèmes embarqués sur base d'un processeur
8 bits style 8051.
Qqun peut-il m'aider à trouver des informations sur comment encrypter des
messages (max 50bytes/message) qui vont transiter sur réseau via une
connexion TCP/IP entre d'une entre d'une part un serveur PC et d'autre
part des clients qui sont des systèmes embarqués sur base d'un processeur
8 bits style 8051.
Qqun peut-il m'aider à trouver des informations sur comment encrypter des
messages (max 50bytes/message) qui vont transiter sur réseau via une
connexion TCP/IP entre d'une entre d'une part un serveur PC et d'autre
part des clients qui sont des systèmes embarqués sur base d'un processeur
8 bits style 8051.
...
En général, le première version
d'un protocole poudu par un comité ou un ingénieur est une
passoire (exemple récent: le désastre du WEP)
...
...
En général, le première version
d'un protocole poudu par un comité ou un ingénieur est une
passoire (exemple récent: le désastre du WEP)
...
...
En général, le première version
d'un protocole poudu par un comité ou un ingénieur est une
passoire (exemple récent: le désastre du WEP)
...
Dans l'article <psEtc.9144$,
"DomiPi" dit:Qqun peut-il m'aider à trouver des informations sur comment encrypter
des
messages (max 50bytes/message) qui vont transiter sur réseau via une
connexion TCP/IP entre d'une entre d'une part un serveur PC et d'autre
part des clients qui sont des systèmes embarqués sur base d'un
processeur
8 bits style 8051.
Questions à se poser au préalable:
- quel est le besoin: confidentialité ou intégrité ? de quoi ?
- pour combien de pièce optimiser la conception ?
- quelles sont les contraintes: financières; délai de développement;
compétence et disponibilité du/des développeurs; environnement de
développement; taille mémoire RAM (interne/externe) et code;
fréquence CPU; limitation du canal de communication: débit, latence,
contenu, taille des messages.
- de quel genre d'attaque doit-on se garder, en sus de l'analyse
des messages échangés: rejeu / altération de message, allégation
mensongère d'une attaque ou dysfonctionnement en fait inexistant ?
extraction de données sensibles (clé, message..) par des canaux
autres que les messages échangés eux mêmes: relecture de mémoire,
analyseur de bus, mesure de courant d'alimentation, de rayonnement,
de durée d'exécution; par injection volantaire de perturbation de
fonctionnement..
- quel est le niveau de l'attaquant: opportuniste ou résolu;
faible ou fort potentiel technique/financier; ayant ou non
accès aux spécifications/code du système ?
C'est un art que de définir/choisir le bon système cryptographique
en fonction de ces critères, et ce particulièrement dans un système
embarqué, où la puissance de calcul est limitée. Il n'existe pas de
solution miracle toute faite adaptée à tous les cas (en cryptographie
informatique normale ça n'abonde déjà pas, mais en embarqué il y a
beaucoup plus de cas).
Conseils particulièrement applicables:
- Investir dans une pré-étude par, ou au moins avec, un expert.
- Définir le système, puis le faire critiquer, avant de l'implémenter.
- Le diable se niche souvent dans des détails (exemple classique:
vulnérabilité introduite par un code de test indépendant de
l'application cryptographique)
- Ne pas entreprendre de concevoir un protocole ou algorithme
cryptographique sans une conaissance approfondie du domaine,
qui ne s'apprend pas dans un (seul) livre. D'ailleurs un bon
livre intelligible à un débutant doit recommander de ne jamais
se lancer dans cette entreprise. En général, le première version
d'un protocole poudu par un comité ou un ingénieur est une
passoire (exemple récent: le désastre du WEP)
- S'il se pose un problème de performance, envisager l'assembleur,
car les compilateurs pour processeur embarqué sont particulièrement
mauvais dans le cas des algorithmes de cryptographie.
Bon, maintenant, s'il vous faut absolument, comme ça, au débotté,
un algorithme de chiffrement par bloc gratuit, implémentable
en une heure, avec 10 lignes de C, quelques centaine d'octets
de ROM, peu de RAM, et qui ne soit pas forcément un maillon
ridiculement faible, il y a par exemple TEA [1]. Il faut
l'employer dans un mode où l'existence de clés équivalentes n'est
pas un problème; on peut conseiller CBC (chiffrement), CBC-MAC
(intégrité), ou les deux (avec dans ce cas deux clés). On doit
prévoir un "padding" du message par un bit à 1, puis autant de
bits à 0 qu'il faut pour atteindre un multiple de la taille de
bloc, soit 64 bits.
TEA, CBC, CBC-MAC, le padding, sont décrits dans l'indispensable
Handbook of Applied Cryptography [2], qui est aussi gratuitement
téléchargeable.
Pour le reste (en particulier: un protocole), j'ai pas de recette
aussi simple, désolé.
François Grieu
[1] http://www.ftp.cl.cam.ac.uk/ftp/papers/djw-rmn/djw-rmn-tea.html
[2] http://www.cacr.math.uwaterloo.ca/hac
Dans l'article <psEtc.9144$yh.6032@amsnews02.chello.com>,
"DomiPi" <akuj0006@wanadoo.be> dit:
Qqun peut-il m'aider à trouver des informations sur comment encrypter
des
messages (max 50bytes/message) qui vont transiter sur réseau via une
connexion TCP/IP entre d'une entre d'une part un serveur PC et d'autre
part des clients qui sont des systèmes embarqués sur base d'un
processeur
8 bits style 8051.
Questions à se poser au préalable:
- quel est le besoin: confidentialité ou intégrité ? de quoi ?
- pour combien de pièce optimiser la conception ?
- quelles sont les contraintes: financières; délai de développement;
compétence et disponibilité du/des développeurs; environnement de
développement; taille mémoire RAM (interne/externe) et code;
fréquence CPU; limitation du canal de communication: débit, latence,
contenu, taille des messages.
- de quel genre d'attaque doit-on se garder, en sus de l'analyse
des messages échangés: rejeu / altération de message, allégation
mensongère d'une attaque ou dysfonctionnement en fait inexistant ?
extraction de données sensibles (clé, message..) par des canaux
autres que les messages échangés eux mêmes: relecture de mémoire,
analyseur de bus, mesure de courant d'alimentation, de rayonnement,
de durée d'exécution; par injection volantaire de perturbation de
fonctionnement..
- quel est le niveau de l'attaquant: opportuniste ou résolu;
faible ou fort potentiel technique/financier; ayant ou non
accès aux spécifications/code du système ?
C'est un art que de définir/choisir le bon système cryptographique
en fonction de ces critères, et ce particulièrement dans un système
embarqué, où la puissance de calcul est limitée. Il n'existe pas de
solution miracle toute faite adaptée à tous les cas (en cryptographie
informatique normale ça n'abonde déjà pas, mais en embarqué il y a
beaucoup plus de cas).
Conseils particulièrement applicables:
- Investir dans une pré-étude par, ou au moins avec, un expert.
- Définir le système, puis le faire critiquer, avant de l'implémenter.
- Le diable se niche souvent dans des détails (exemple classique:
vulnérabilité introduite par un code de test indépendant de
l'application cryptographique)
- Ne pas entreprendre de concevoir un protocole ou algorithme
cryptographique sans une conaissance approfondie du domaine,
qui ne s'apprend pas dans un (seul) livre. D'ailleurs un bon
livre intelligible à un débutant doit recommander de ne jamais
se lancer dans cette entreprise. En général, le première version
d'un protocole poudu par un comité ou un ingénieur est une
passoire (exemple récent: le désastre du WEP)
- S'il se pose un problème de performance, envisager l'assembleur,
car les compilateurs pour processeur embarqué sont particulièrement
mauvais dans le cas des algorithmes de cryptographie.
Bon, maintenant, s'il vous faut absolument, comme ça, au débotté,
un algorithme de chiffrement par bloc gratuit, implémentable
en une heure, avec 10 lignes de C, quelques centaine d'octets
de ROM, peu de RAM, et qui ne soit pas forcément un maillon
ridiculement faible, il y a par exemple TEA [1]. Il faut
l'employer dans un mode où l'existence de clés équivalentes n'est
pas un problème; on peut conseiller CBC (chiffrement), CBC-MAC
(intégrité), ou les deux (avec dans ce cas deux clés). On doit
prévoir un "padding" du message par un bit à 1, puis autant de
bits à 0 qu'il faut pour atteindre un multiple de la taille de
bloc, soit 64 bits.
TEA, CBC, CBC-MAC, le padding, sont décrits dans l'indispensable
Handbook of Applied Cryptography [2], qui est aussi gratuitement
téléchargeable.
Pour le reste (en particulier: un protocole), j'ai pas de recette
aussi simple, désolé.
François Grieu
[1] http://www.ftp.cl.cam.ac.uk/ftp/papers/djw-rmn/djw-rmn-tea.html
[2] http://www.cacr.math.uwaterloo.ca/hac
Dans l'article <psEtc.9144$,
"DomiPi" dit:Qqun peut-il m'aider à trouver des informations sur comment encrypter
des
messages (max 50bytes/message) qui vont transiter sur réseau via une
connexion TCP/IP entre d'une entre d'une part un serveur PC et d'autre
part des clients qui sont des systèmes embarqués sur base d'un
processeur
8 bits style 8051.
Questions à se poser au préalable:
- quel est le besoin: confidentialité ou intégrité ? de quoi ?
- pour combien de pièce optimiser la conception ?
- quelles sont les contraintes: financières; délai de développement;
compétence et disponibilité du/des développeurs; environnement de
développement; taille mémoire RAM (interne/externe) et code;
fréquence CPU; limitation du canal de communication: débit, latence,
contenu, taille des messages.
- de quel genre d'attaque doit-on se garder, en sus de l'analyse
des messages échangés: rejeu / altération de message, allégation
mensongère d'une attaque ou dysfonctionnement en fait inexistant ?
extraction de données sensibles (clé, message..) par des canaux
autres que les messages échangés eux mêmes: relecture de mémoire,
analyseur de bus, mesure de courant d'alimentation, de rayonnement,
de durée d'exécution; par injection volantaire de perturbation de
fonctionnement..
- quel est le niveau de l'attaquant: opportuniste ou résolu;
faible ou fort potentiel technique/financier; ayant ou non
accès aux spécifications/code du système ?
C'est un art que de définir/choisir le bon système cryptographique
en fonction de ces critères, et ce particulièrement dans un système
embarqué, où la puissance de calcul est limitée. Il n'existe pas de
solution miracle toute faite adaptée à tous les cas (en cryptographie
informatique normale ça n'abonde déjà pas, mais en embarqué il y a
beaucoup plus de cas).
Conseils particulièrement applicables:
- Investir dans une pré-étude par, ou au moins avec, un expert.
- Définir le système, puis le faire critiquer, avant de l'implémenter.
- Le diable se niche souvent dans des détails (exemple classique:
vulnérabilité introduite par un code de test indépendant de
l'application cryptographique)
- Ne pas entreprendre de concevoir un protocole ou algorithme
cryptographique sans une conaissance approfondie du domaine,
qui ne s'apprend pas dans un (seul) livre. D'ailleurs un bon
livre intelligible à un débutant doit recommander de ne jamais
se lancer dans cette entreprise. En général, le première version
d'un protocole poudu par un comité ou un ingénieur est une
passoire (exemple récent: le désastre du WEP)
- S'il se pose un problème de performance, envisager l'assembleur,
car les compilateurs pour processeur embarqué sont particulièrement
mauvais dans le cas des algorithmes de cryptographie.
Bon, maintenant, s'il vous faut absolument, comme ça, au débotté,
un algorithme de chiffrement par bloc gratuit, implémentable
en une heure, avec 10 lignes de C, quelques centaine d'octets
de ROM, peu de RAM, et qui ne soit pas forcément un maillon
ridiculement faible, il y a par exemple TEA [1]. Il faut
l'employer dans un mode où l'existence de clés équivalentes n'est
pas un problème; on peut conseiller CBC (chiffrement), CBC-MAC
(intégrité), ou les deux (avec dans ce cas deux clés). On doit
prévoir un "padding" du message par un bit à 1, puis autant de
bits à 0 qu'il faut pour atteindre un multiple de la taille de
bloc, soit 64 bits.
TEA, CBC, CBC-MAC, le padding, sont décrits dans l'indispensable
Handbook of Applied Cryptography [2], qui est aussi gratuitement
téléchargeable.
Pour le reste (en particulier: un protocole), j'ai pas de recette
aussi simple, désolé.
François Grieu
[1] http://www.ftp.cl.cam.ac.uk/ftp/papers/djw-rmn/djw-rmn-tea.html
[2] http://www.cacr.math.uwaterloo.ca/hac
Vous attisez ma curiosité. Pouvez-vous en dire plus sur ce désastre ?
Quel est le problème avec WEP ?
Vous attisez ma curiosité. Pouvez-vous en dire plus sur ce désastre ?
Quel est le problème avec WEP ?
Vous attisez ma curiosité. Pouvez-vous en dire plus sur ce désastre ?
Quel est le problème avec WEP ?
