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
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 mrholub@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
- 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 sargonout@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 mrholub@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
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 mrholub@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 sargonout@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 mrholub@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
- 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 sargonout@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 mrholub@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 sargonout@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 mrholub@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
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 mrholub@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 sargonout@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 mrholub@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 sargonout@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 mrholub@hotmail.com:
Ahoj,
tak jsem konecne publikoval svuj protokol,
https://github.com/mrholub/hcp
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
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 sargonout@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 mrholub@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 sargonout@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 mrholub@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 sargonout@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 mrholub@hotmail.com:
Ahoj,
tak jsem konecne publikoval svuj protokol,
https://github.com/mrholub/hcp
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
-
Robert Holub -
Tomislav Arnaudov