Alarme sans fil gérée par µC.

Emile a ecrit

Bonjour Emile Le verbe *securiser* avec "sans fil" ça ne marchera jamais ;o) (un emetteur en continu sur la F et la liaison supposée securisée est "morte" sans avoir meme besoin de tenter de percer.

tendre a fiabiliser = oui

Puisque tu veux faire du "neuf" la solution là la plus simple est d'encoder/crypter les trames avant envoi. A chaud : envoi d'une trame cryptée watchdog aleatoirement (au moins une par periode de temps à definir pour verif de l'integrité de la liaison) envoi des evenements reels par trames cryptées.

voire à faire aussi de la pseudo evasion de frequence si les modules le permettent et/ou dupliquer les vecteurs d'emission pour augmenter le facteur "fiabilité".

Rvl

On Mar 3, 3:48 pm, Emile

Voici une technique simple =E0 mettre en oeuvre, mais suffisamment robuste aux attaques primaires :

Pour chaque trame =E0 =E9mettre, l'=E9metteur g=E9n=E8re un octet de codage pseudo-al=E9atoire, et effectue avec lui un XOR sur chaque octet de la trame, puis ajoute ce code en fin de trame. Le r=E9cepteur r=E9cup=E8re l'octet de codage et d=E9code la tra=F9me avec le m=EAme algotithme.

Ainsi les trames changent continuellement, m=EAme si les donn=E9es transmises sont toujours les m=EAmes.

Pour am=E9liorer cela, au lieu d'utiliser une valeur d'encodage sur un seul octet il vaut mieux avoir le plus de bits possible, et m=EAme, modifier ces bits =E0 chaque XOR sur un octet de trame, par exemple avec des d=E9calages, etc ...

De cette facon, m=EAme une trame compos=E9e uniquement de z=E9ros pr=E9sentera une suite de bits changeants qui ressemblera plus =E0 du bruit qu'=E0 quelque chose de sens=E9.

Il faut aussi que les trames ne soient pas trop courtes, sinon cela simplifie l'analyse de l'encodage. (si tes trames sont trop courtes, ajoute des octets bidons)

Tu peux t'inspirer d'algos d=E9ja existants du genre CRC :

Exemples de programmes C pour calcul de CRC :

0000000000000000

il faudra prevoir surtout un anti brouillage ... si le recepteur ne recoit rien pendant x minutes, brouillage en cours à vérifier ?

--
-
Jean-Yves

jeanyves a tapoté du bout de ses petites papattes :

Le watchdog de rvlegran est une bonne idée pour ça.

--
LeLapin

Merci beaucoup =E0 tous !

je pensais sachant que chaque boitier gere l'emission et la r=E9ception. Envoyer par l'emetteur 1 recevoir par le 2 , le 2 lit et confirme =E0 l'emetteur qui r=E9envoit ( le tout se fait X fois ), au bout de X fois le N=B02 valide et =E9xecute l'ordre.(le tout avec le CRC pr=E9conis=E9 par JC). De toute maniere l'appareil emet seulement lorsque il y a une intrusion ; en mode veille personne ne communique sauf toutes les 2 H par exemple pour s'assurer que la liaison est encore l=E0 et qu'il n'y a pas de brouillage , si message antibrouillage pas recu au bout de X fois , d=E9clenchement sir=E8ne chez le voisin par exemple.

J'ai aussi la possibilit=E9 en commande AT de g=E9rer plusieurs canaux d'=E9mission sur la meme fr=E9quence , donc pk pas emettre sur canal 1 ensuite 2 ensuite 3 etc...?

Emile

e i s

ar

Pour le code al=E9atoire je peux le g=E9rer avec le pic fonction " random" pour le g=E9n=E9rer , mais se pose la question de comment apr=E8s d=E9codag= e de l'autre cot=E9 savoir quoi executer , sachant que cest de l'al=E9atoire le recepteur ne pourra donc pas anticiper cette valeur .?

Emile

Emile a ecrit

Il existe une multitude de solution, mais je crois que dans ton cas il te faut rester simple.

pour exemple solution simple et efficace tu genere un nombre pseuso aleatoire sur la source tu crypte ton msg avec un algo dont la clef est fonction du nombre generé. tu transmet avec la trame cryptée le nombre aleatoire generé et tu decrypte à l'arrivée en appliquant la fonction inverse.

autre solution si tu a une reference temporelle fiable de chaque coté, tu peux aussi utiliser le timestamp comme generateur aleatoire.

De toutes façons, ne reve pas trop, si des "rigolos" en sont à essayer de decortiquer ça "ON AIR", il y a de grandes chances qu'ils choisissent une methode un peu plus brut ! :D

Au passage 2 heures entre cghque verif d'integrité de liaison, c'est AMHA quasi equivalent à pas de protection !

+/- une trame watchdog par minute est plus realiste. Rvl

rvlegran a tapoté du bout de ses petites papattes :

+1 D'autant que comme les deux µC n'auront que ça à foutre, ça ne coûte rien. Accessoirement, dans le militaire ou le civil sensible, on rajoutait des watchdogs hardware pour prévenir le risque de plantage du proc. Mais n'ayant pas d'expérience suffisante avec les PICs, je ne sais pas s'il est plantard ou pas.

--
LeLapin

A

Je peux faire un truc du genre :

Si je veux envoyer la valeur 150 par exemple qui correspondrait de l'autre cot=E9 au d=E9clenchement de l'alarme par exemple ca serait du style :

G=E9n=E9ration d'un nombre al=E9atoire d'un octet par exemple 196 ce qui fait en binaire :11000100

150 X 196 =3D 29400 Je convertis ce r=E9sultat en binaire et je viens lui coller ma clef al=E9atoire de 196 ce qui ferait : 111001011011000 et 11000100

Soit un mot de presque 3 octets soit 23 bits Donc j'envoie 11100101101100011000100 par le biais de ma liaison sans fil.

et cot=E9 recepteur je fais cela dans l'autre sens c'est ca ?

Emile

On Mar 3, 6:57 pm, Emile

"

age

e

Il est =E9vident que ce code ( la cl=E9 d'encodage/d=E9codage ) doit =EAtre transmis DANS la trame : il doit en faire partie. Tu peux par exemple ajouter cette cl=E9 en fin de trame, ou en d=E9but de trame ( ce qui permet de d=E9coder les octets suivants en temps r=E9=E9l, au fur et =E0 mesure de leur arriv=E9e )

Je pr=E9cise qu'une cl=E9 compos=E9e d'un seul octet ne me semble pas suffisant pour une protection efficace : par la force brute il n'y a que 255 possibilit=E9s =E0 essayer pour retrouver l'original ... c'est peu.

D'o=F9 l'int=E9r=EAt de modifier la cl=E9 au fur et =E0 mesure qu'on la XOR avec chaque octet de la trame =E0 transmettre : c'est aussi simple =E0 faire qu'efficace pour la prot=E9ger. D'ailleurs le XOR pur n'est qu'un r=E9flexe d'informaticien : il peut aussi =EAtre m=E9lang=E9 avec des ROR et des ROL, les bits d'une m=EAme trame peuvent =EAtres swapp=E9s, etc. ( tout ceci =E9tant bien s=FBr r=E9versible pour permettre le d=E9codage de la trame lors de la r=E9ception )

Tu peux m=EAme aller jusqu'=E0 distribuer individuellement chaque bit de la cl=E9 n'importe o=F9 dans la trame. Il existe une infinit=E9 de possibilit=E9s pour encrypter un message de fa=E7on effica=E7e, sans que cela ne devienne compliqu=E9 =E0 programmer en ASM ou en C. La th=E9orie peut faire appel =E0 des maths pouss=E9es, mais leur programmation se r=E9soud =E0 quelques lignes.

Exemple de codage simple, r=E9versible avec cl=E9 changeante :

// ptr =3D pointeur sur les donn=E9es // size =3D taille des donn=E9es en octets // key =3D cle de cryptage (16 bits, 32 bits, ...)

void Crypt( char *ptr, unsigned int size, unsigned int key ) { int i, j, s =3D sizeof(int); // util

// ajoute la cle en fin de trame for( i=3Dj=3D0; i < s; j++, i +=3D 8 ) ptr[ size + j ] =3D ( key >> i ) & 0xFF; // LSB first

// encode les donn=E9es for( s--; size--; ) { *ptr++ ^=3D key & 0xFF; // codage de l'octet trame key =3D ( key > s ) & 1 ); // cle suivante } }

dom"

codage

oire

bon d=E9j=E0 transmettre une cl=E9 dans un message, c'est stupide...

(je viens de voir de nouveaux messages et la cryptanalyse semble trop facile encore pour ce qui a =E9t=E9 propos=E9)

ensuite, ce dont il est question ici c'est juste de l'embrouillage, si une personne est suffisamment comp=E9tente pour =E9coder et lire le message, elle le comprendra...

pour le reste, il y a le bouquin de Bruce Schneier : "cryptographie appliqu=E9e"

et m=EAme des groupes sur usenet pour =E7a : fr.misc.cryptologie sci.crypt sci.crypt.research et j'en passe

enfin, j'ai entendu dire (je sais plus o=F9) que le syst=E8me Keelok de Microchip ne vaut pas grand-chose, le fait d'avoir cach=E9 le code source ne rend d=E9cid=E9ment pas le syst=E8me plus fiable.

yg

--=20

/

On Mar 3, 10:49 pm, Emile

Je ne comprends pas pourquoi tu multiplies 150 par 196 ? Outre le fait que cela augmente la taille des donn=E9es =E0 transmettre, il est bien plus simple et rapide de faire un XOR entre la cl=E9 de codage et chaque octet de donn=E9es de la trame.

Avec ton exemple : si tu veux envoyer un seul octet de valeur 150 avec une cle =E9gale =E0 196, alors ta trame non crypt=E9e vaudra =3D 0x96C4 tu cryptes en faisant un XOR entre 0x96 et 0xC4 cela donne la trame crypt=E9e =E0 transmettre =3D 0x52C4 En r=E9ception tu fais la m=EAme chose et tu retrouves =3D 0x96C4 ...

Mais j'ai d=E9ja attir=E9 ton attention sur le fait que plus une trame est courte, plus il est facile de casser son cryptage : ta bande passante est assez =E9lev=E9e pour que tes trames puissent faire au moins une centaine d'octets.

D'autre part il serait bon que le r=E9cepteur soit prot=E9g=E9 contre les erreurs de transmissions, sinon c'est n'importe quoi. Un checksum (ou mieux, un CRC qui permet de corriger certaines erreurs) ne co=FBte pas grand-chose en programmation ni en temps ...

"s=E9curit=E9 par le secret", c'est =E7a ? demandez =E0 Sony : ce qui tient longtemps c'est tout ce qui n'est pas int=E9ressant.

m=EAme en r=E9alisant SHA-1 (qui est un hash simple) dans un PIC, ce qui est tout =E0 fait possible (bien qu'indigeste) il y a toujours la possibilit=E9 de se faire avoir par des rainbow tables, une r=E9alisation mauvaise (r=E9utilisation accidentelle de vecteurs) ou une cryptanalyse de base (xorer un message avec une cl=E9 priv=E9e ? autant la transmettre !)

bon j'arr=EAte l=E0 :-)

yg

--=20

/

Jean-Christophe a ecrit

Bonsoir Jean-Christophe ha ba non ! pas d'accord ;o)

ce qui doit etre transmit et deduit d'une maniere ou d'une autre dans la trame c'est simplement la possibilité de retrouver la (bonne) clef.

Cette(les) clef doit etre déjà embarquée sur les terminaux. Sans rentrer sur de la crypto dure, il suffit de transmettre un octet A ( déjà 256 possibilitées) et d'associer la valeur A pointant sur un tableau rempli de chaque coté avec une clef identique (cryptage symetrique), clef qui reste(ra) parfaitement discrete (en contenu et taille) puisqu'elle ne sera a aucun moment "ON AIR"

mais là on sort de l'electronique Rvl

rvlegran a tapoté du bout de ses petites papattes :

Je reste persuadé que le meilleur moyen de dérouter un voleur, c'est de sortir des sentiers battus et de se faire une norme perso. Genre envoyer les bits dans le désordre, moduler hors normes, bref faire un truc absolument pas standard et totalement inattendu. Le voleur est rarement un électronicien/cracker hors pair, et avec un matos de base il ne pourra pas faire le rétroprocessing nécessaire et s'attaquera au voisin.

Mais ça n'est qu'àmha.

--
LeLapin

LeLapin a ecrit

Principe de base : Ce qui tient longtemps, n'est pas "publiquement" documenté ;o) Rvl

On Mar 3, 11:20 pm, "rvlegran"

Salut Herv=E9.

Certes, mais il me semble que tu pars du principe qu'il suffit de connaitre la cl=E9 pour d=E9crypter la trame, or :

1. Tu ne connais pas la taille de la cl=E9 (qui peut =EAtre variable)
2. Tu ne sais pas o=F9 trouver la cl=E9 dans la trame.
3. Tu ne sais pas si la cl=E9 n'est pas elle-m=EAme crypt=E9e.
4. Tu ne connais pas l'algorithme d'encryptage.

J'ajoute encore qu'il est possible de disperser les bits de la cl=E9 arbitrairement dans la trame : m=EAme en connaissant la version non crypt=E9e de la trame, ( ce qui n'est pas le cas du vilain cambrioleur lambda ) tu pourrais par exemple tenter des XOR avec la trame crypt=E9e pour retrouver la cl=E9, etc ... mais cela ne marchera pas : la combinatoire est beaucoup trop =E9lev=E9e.

A l'inverse, m=EAme si tu as =E0 la fois la trame encrypt=E9e ET la cl=E9 (en clair) tu ne sais toujours pas comment d=E9crypter la trame ...

Ah oui, c'est pas mal du tout comme =E7a, totalement opaque.

Mais (je d=E9fends a cr=E8merie :o) cela n=E9c=E9ssite une table, ( bien qu'une table ne co=FBte pas grand-chose ) tandis-qu'avec ma m=E9thode pas besoin de table; certes la cl=E9 elle-m=EAme est bien transmise, mais elle est totalement introuvable dans la trame.

Oui, mais bon, la culture g=E9n=E9rale, le plaisir d'=E9changer des id=E9es ...

si tu lis 1 trame.

admettons maintenant que Eve (Alice =E9tant Emile et Bob =E9tant le voisin gendarme, cf

) =E9coute patiemment les trames 1 jour, ou 2 semaines. combien peut-elle en stocker pour examiner les corr=E9lations ? Eve verra bien que des parties du messages ne changent pas et sont donc n=E9cessaires au protocole.

si la cl=E9 ne change pas ET est transmise dans le message, elle n'a plus de fonction de cl=E9. D'o=F9 les fonctions de hachage et d'encryption dont les propri=E9t=E9s de confusion-diffusion sont suffisamment solides.

non

la "connaissance" vient juste de l'entropie du message transmis.

la premi=E8re =E9tape de la cryptanalyse c'est de voir les corr=E9lations entre messages, trouver ce qui change, pourquoi/quand.

Ma proposition : * Une cl=E9 "priv=E9e" sur N bits. Une cl=E9 (identifiant) par appareil= =2E comme =E7a, pas possible d'en prendre un pour =E9muler un autre. * Un compteur, ou m=EAme LFSR, qui incr=E9mente =E0 chaque message. * La cl=E9 et le compteur sont m=E9lang=E9s par un SHA-1 ce qui donne 1=

60 bits. =E7a utilise de l'arithm=E9tique 32 bits mais juste additions/soustr= actions/ d=E9calage/and/or/xor/not donc on peut coder =E0 coups de macros ASM.=

=3D> Je sais, SHA-1 n'est plus s=FBr et y'a des rainbow tables dispo= nibles mais on peut l'alt=E9rer : changer le nombre de rondes (pas besoin de= 80, 40 suffiraient) et on peut changer les "constantes magiques" (parties= de la cl=E9).

• Concernant la d=E9tection/correction d'erreurs : les codes de Hamming sont tr=E8s bien :-) c'est encore que des XOR, =E7a a l'air complexe mais quand on a compris c'est super simple en fait.

• mettre en place un syst=E8me d'accus=E9 de r=E9ception pour que les c= ompteurs avancent en synchronicit=E9.

pas besoin de changement de fr=E9quence :-)

yg

--=20

/

Je ne programme pas encore en C je d=E9but j'en suis qu'au basic et l=E0 je d=E9but en ASM donc je suis lent =E0 assimiler lol

je pensais pour le CRC envoyer la trame 3 fois et si au bout de 3 X c'est la meme alors je valide... Pour la fonction XOR peux tu sil te plait m'expliquer basiquement le principe ?

Merci

Emile