We seem to have a communication problem here so I'll try it in English. I've never claimed that IOT devices are potentially insecure because of used protocol, whatever protocol it is. Also I've never stated that my protocol is intended to be more secure than others. I haven't claimed bit-banging to be more secure neither. The goal was to create really simple protocol - it can even be used to communicate manually with device by using switches. If both devices has enough IO pins the simple program could be created to connect these.
I hope you'll have the same fun not using it that I've had while creating it :-) Even happier hacking Mr.Holub On Sun, 18 Dec 2016 23:33:10 +0100, Tomislav Arnaudov <sargon...@gmail.com> wrote: > predstavme si ze je protokol nejaky jazyk ktory ked proste neovladas tak > si > moc nepokecas > takisto ako C , C++ , python ... atd > pokial ten nouma ktory sa ide hrabat v IoT si neporadi s SPI alebo I2C > tak > mu to asi nebude fungovat > a to sme stale u toho T z IoT ... este ten nouma si musi poradit s tym I > kde ho podla mna cakaju daleko daleko vacsie nastrahy ako komunikacny > protokol. > > nic proti tvojmu protokolu urcite ta to posunulo dalej a vela si sa > naucil > ale bitbang je nieco ako esperanto medzi jazykmi. > a tvrdit ze bitbangovane pseudoSPI je bezpecnejsie je uplny nezmysel ... > ba > prave naopak buffery,interrupty,dma-cka,clocking, polarita atd atd robi > protokol "bezpecnym" > > ako proof of koncept dobry ale nevidim dovod to zacat pouzivat :) > > happy hacking > Sargon > > > > > Dne 18. prosince 2016 22:52 Robert Holub <mrho...@hotmail.com> napsal(a): > >> - Ja netvrdil ze je neco nezabezpeceneho na samotnem pouzitem protokolu, >> ale moje vize je takova, ze v IOT bude delat jiz brzo kazdy nouma takze >> se >> vyroji spoustu zabugovanych zarizeni ktera budou mit velky potencial >> byt z >> toho duvodu spatne zabezpecena. Ne primo z duvodu protokolu ktery je >> pouzit. >> >> - >> >> - Presne tak, je to bit - banging. Cilem je propojovat obskurdni >> zarizeni >> a zkusit si vytvorit prenosovy protokol. U konkretniho vzorku ktery jsem >> predvadel to je 0-3.3v na strane RPI a 0-5V na strane Atmegy. Klidne si >> procti zdrojaky jsou jednoduche. >> IRQ jsme pouzit nezkousel, buffery take neresim. To by vsechno vec >> zeslozitilo a mym cile nebylo se chtit rovnat jinym protokolum ale >> stvorit >> neco jednodussiho. >> >> Mr.Holub >> >> >> >> On Sun, 18 Dec 2016 20:57:58 +0100, Tomislav Arnaudov >> <sargon...@gmail.com> wrote: >> >> > diky za odpovede ale : >> > - mozes uviest nejake priklady ? neviem co je spatneho zabezpeceneho >> na >> > i2c >> > alebo spi , uart/usart atd ... >> > >> > - OK >> > >> > - v SPI sa pouziva vacsinou tam kde je potreba IRQ pin ktory prave >> hovori >> > nieco ako napr "uz mam plny/prazdny buffer" alebo "nove data su >> > dostupne/zapsane vyber si je/zapis dalsie" atd... >> > >> > s cim som mnohokrat narazil napriklad tak je polarita signalov u SPI a >> > i2c >> > ... ktora napriklad sa u tvojho protokolu asi vobec neriesi kedze sa >> > jedna >> > o cisto SW implementaciu v podobe "bit-bang" ... je to tak ? >> > >> > >> > Dne 18. prosince 2016 20:00 Robert Holub <mrho...@hotmail.com> >> napsal(a): >> > >> >> - Nemel jsme na mysli nezabezpecene protokoly, ale spatne zabezpeceni >> >> jako >> >> celek z duvonu uspechaneho vyvoje , snadnosti nastaveni (napr. >> defaultni >> >> hesla) a lace (napr. stare verze sw se znamymi problemy). >> >> >> >> - To mne zmatl kamarad - spatne to pochopil, pak jsme se dohodli ze >> je >> >> asynchronni. >> >> >> >> - ACK je tam aby zarizeni mohla cekat jak dlouho chteji tj. i >> >> nepravidelne, coz byl zamer. Cilem bylo udelat jednoduchy protokol, >> >> dokonce se lze bavit se zarizenim i rucne. >> >> Chip select tam je (CS), takze paralelne by zarizeni zapojit sla. >> >> Pravda, >> >> nezminoval jsem to a vlastne dosud ani nezkousel. >> >> >> >> Mr.Holub >> >> >> >> >> >> On Sun, 18 Dec 2016 12:58:34 +0100, Tomislav Arnaudov >> >> <sargon...@gmail.com> wrote: >> >> >> >> > Ahoj mr.Holub >> >> > po skuknuti talku z Brmlabu mam par otazok >> >> > >> >> > -prednaska zacina s tym ze IoT zariadenia pouzivaju nedokonale a >> >> > ne-bezpecne protokoly , ako si k tomuto tvrdeniu dosiel ? >> >> > -tvrdis ze tvoj protokol je synchronni - nacoz nasledne tvrdis ze >> >> > zariadenie musi pockat na ack a komunikaci ridi master ... toto mi >> >> nejak >> >> > nesedi v com je ta synchronnost ? >> >> > -vychadzas z SPI protokolu ktory si degradoval pridanim uplne >> >> zbytocneho >> >> > ACK signalu na 1:1 master slave protokol ... pricom si zabudol na >> >> jednu z >> >> > najlepsich ficur tohoto protokolu a to je daisy chain >> >> > >> >> > >> >> > 2016-12-18 11:35 GMT+01:00 Robert Holub <mrho...@hotmail.com>: >> >> > >> >> >> Ahoj, >> >> >> >> >> >> tak jsem konecne publikoval svuj protokol, >> >> >> >> >> >> https://github.com/mrholub/hcp >> >> >> >> >> >> http://www.instructables.com/id/Smart-Mouse-Trap/ >> >> >> >> >> >> http://www.instructables.com/id/Simple-6-wire- >> Communication-Protocol/ >> >> >> >> >> >> Mr.Holub >> >> >> _______________________________________________ >> >> >> Brmlab mailing list >> >> >> Brmlab@brmlab.cz >> >> >> https://brmlab.cz/cgi-bin/mailman/listinfo/brmlab >> >> >> >> >> >> >> >> >> -- >> >> Using Opera's mail client: http://www.opera.com/mail/ >> >> _______________________________________________ >> >> Brmlab mailing list >> >> Brmlab@brmlab.cz >> >> https://brmlab.cz/cgi-bin/mailman/listinfo/brmlab >> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> _______________________________________________ >> Brmlab mailing list >> Brmlab@brmlab.cz >> https://brmlab.cz/cgi-bin/mailman/listinfo/brmlab >> -- Using Opera's mail client: http://www.opera.com/mail/ _______________________________________________ Brmlab mailing list Brmlab@brmlab.cz https://brmlab.cz/cgi-bin/mailman/listinfo/brmlab
