Dosen't one of these big LoRa systems require use of a phone number or something simimilarly counterproductive? This seems to be targeting those concerns.
I think it's not entirely correct to say that it "does not use an operating system". It does not use a conventional one, like Windows or Linux, or Android, but it has an OS to run it. It may be very simple, but it still needs to do things to communicate with different hardware. So it does have an attack surface, potentially. Especially with external input that comes in and needs to be parsed... Where there is parsing - there are buffers, and where there are buffers - there are overflows. And on a non-memory-managed system (I imagine this thing does not run in protected mode) an overflow can touch literally anything with fancy enough exploitation techniques.
Thanks for the well-thought-out comment. The device is based around a single board microcontroller (currently the Adafruit M4 Express samd51). That SMB (along others I've been targeting) is single-threaded and has a boot loader that loads the ChatterBox firmware from eeprom or flash into memory. At that point, there is no OS layer, it's just the ChatterBox firmware communicating directly with hardware. Nothing (besides the ChatterBox firmware) is managing memory or resources. The conveniences an OS would provide must be handled directly by the ChatterBox firmware. Since that is the I do think it's technically correct to say it "has no OS". If you disagree with that, I would definitely like to hear more. You are certainly correct that buffers are utilized, and they can typically present all sorts of problems. I have made some deliberate design decisions to mitigate those risks, to the degree possible, and help to tilt potential issues in the user's favor as much as possible. Here are a few thoughts to provide you with insight into how I am mitigating risks of buffer overflow: The ChatterBox firmware is written in C++ and it is using FIXED-length buffers everywhere (fixed at compile time). It is not dynamically allocating memory, but rather the buffers are all set aside all at once as the system is initializing. All messages and data payloads are currently limited to a certain fixed-length size. Before transmission or storage, each message is packetized into much smaller pieces. Those much smaller packets are what gets encrypted, so at any time, I'm dealing with very small fragments of data (just big enough to meet the block cipher size). Every transmission is digitally signed. If any buffer involved in that chain of packetizing/encrypting/hashing was to overflow (which I have intentionally caused to happen during testing), the signature is no longer valid, so the entire message is ignored. I have intentionally triggered buffer overflows at various points during testing, and the result has been that malicious data is stopped dead in its tracks when a sig check fails and the device continues on as normal. To the degree possible, any potentially sensitive buffers are zeroed out immediately after the data sitting in them is no longer needed in memory. There is no file system. A file system would typically do some sort of caching, so I am not using one (not even an emulated one). All data is stored in FRAM, where again, everything is packetized into fixed length and encrypted using a block cipher algorithm (different encryption key), with each 'slot' in FRAM being long enough to handle the length of the data plus the bloat that can added by encryption. Having said all that, I'm certainly not going to claim the ChatterBox could never have a buffer overflow. But, I do test for that and if something was to trigger a buffer overflow somehow, the behavior I expect to see would be that a message or data payload would get thrown out because a signature would no longer be valid.
@@mattcalhoun61 After reading this I would agree with you. I think my comment was a bit hasty, but the line that separates an "OS" from "non-OS" is pretty blurry... For instance, I have a Flipper Zero device, which is running on a microcontroller and has a bunch of peripherals, including various radios, etc... But it does have a filesystem, external apps, etc... So it's more like an OS, but my gut tells me it's a firmware :D What would be a definitive distinction, if we are to get philosophical in YT comments? :D Do you need to have threads, or drivers, or apps, or a HAL, or to have a clear distinction between a kernel and userland software? I'd have to reflect on that...
@@VasilisOfficeHours I do not currently need threads, but do "simulated" multithreading similar to how an OS would have done so in the past, with timers, interrupts, and things like that. I do use hardware libraries in some cases, and direct SPI/I2C/UART "wire" calls in others, depending on what I think makes sense. There are no "apps", it's just the ChatterBox firmware, which does happen to be very extensible, ready to deal with other types of transceivers, sensors, etc, as I find good fits and see what people want as time goes on. These are good questions by the way, thanks
@@obstacleman thank you, great comment. It is using samd51 and not esp32 for that very reason. There is no wifi on board at all. There is capability to plug in a wifi chip as a secondary delivery method for your cluster, but I am not including that in the base device. When I start adding plug and play thermal cams and stuff, higher bandwidth might become desirable , but for now its just an rfm95w module on board
This is fantastic. I have a few questions: 1. When a message is passed through a mesh, is the intended recipient known to the nodes that are holding onto the message? 2. Can a device be a member of multiple clusters? 3. Can a device pretend to be another node by spoofing its name? would It then receive messages that weren't intended for it? could it prevent the intended recipient from recieving the message if it was closer/online earlier etc. I imagine the fake node wouldn't be able to decrypt the message but could this interfere in other ways? or perhaps there is a protocol to make sure the actual intended recipient acknowleges in a signed way? 4. It seems like all members of a cluster would have at least some ability to see what traffic is happening within the cluster (including the node names of the people talking to each other) if their device was acting as a relay in the mesh. would nearby other clusters have any transparency into this traffic? I really love this concept, you've done excellent work
These answers probably need a little more detail than I am typing in this comment, but here goes... 1. Yes, all devices participating in meshing of a particular message need to at the very least, be aware of the existence of the end recipient. Due to how knowledge of devices and their connectivity is passed around, this actually happens surprisingly quickly, even if a new device is just powered on for the first time. The video I posted on simulation of the mesh algo explains this somewhat (ruclips.net/video/0eQud9eQEXw/видео.html). If a device comes across one it has never been near before, it automatically requests a public key exchange. Along with the key exchange, each device provides a "license" which is a signature of its public key + alias, generated by the root device at onboarding. Any device can compare the sig with the root's public key to verify authenticity during this public key exchange, which can happen at any time between 2 devices. 2. Yes, a device can be in 2 clusters. A cluster can have up to 90 devices. So any device should have no trouble getting a message to any of the other 89 messages in its cluster. I am about to start "phase 2" of the meshing algo, which will involve cross-cluster delivery and routing. That would mean, linking clusters either formally or ad-hoc, and leveraging this dual cluster -per device capability would give a cluster direct connectivity to up to 90 other clusters. Even if they're listening on different frequencies, it wouldn't matter. It is possible that a cluster could be set up as a dedicated "backbone" that only exists for linking scattered clusters over large distances. Or multiple backbones or other patterns going in various directions, maybe with very large antennas. 3. The name you see is really just an alias. Each cluster and device has a unique id which is actually what's used for delivery. All messages are signed using the sender's private key. All acknowledgements are signed by the recipients key. Since RF is involved, there are always going to be ways to cause interference, but I think I have pretty much minimized potential weaknesses within the protocol in all ways I can think of. Even pings that are used for relaying connectivity info are signed (pings are broadcast using a cluster symmetric key and they are not acknowledged). 4. Yes, all members of a cluster see traffic on the cluster's frequency, even if it were for other clusters that are using the same frequency. Broadcast message payloads are unreadable to off-cluster devices. Direct messages are unreadable to any device except for the sender and recipient. A nearby cluster would not be able to acknowledge or decrypt any broadcast or direct messages from your cluster. The other cluster's messages, acknowledgements, and pings are ignored by your cluster, since the cluster ID is different (name could be the same and wouldn't matter, it's just an alias for you). Not ALL data is encrypted. Payloads certainly are, and all messages are signed (with expiry so another cluster couldn't "replay" your messages). Data used for routing (sender device id/recipient device id, expiry, various message flags) are not encrypted, mostly to reduce unnecessary decryptions and message "bloat". I suppose I could encrypt those using cluster's symmetric key, and the mesh delivery would still work OK, but at the moment I have those bits of data as clear text.
@@glemblemble forgot to mention, even routing related data that I said is not encrypted IS signed as well, so even though it could be read, it cannot be spoofed. Also device and cluster IDs that are hidden to you and actually used for routing are alphanumeric strings, not simply a one or two byte number.
Do you plan on adding GPS support? I think the added security this has over meshtastic would potentially pair well with ATAK. Anyway awesome project, good to see more LoRA based projects!
I hate to say I had not heard of ATAK until you mentioned it, but that is quite the rabbit hole, and I think you're right there could be some interesting overlap there for sure. I'm building these in such a way that it should be quite easy to integrate sensors of various types. There is no technical reason why GPS couldn't be added, but I have avoided doing so because as of now. Once you have a device running in your hand, from that point forward it has zero dependence on any centralized thing (internet, satellite, etc). It might never have connectivity to a computer/phone/wifi/etc, and it would work fine for its entire lifecycle, even recognizing devices it had never seen before, if the other devices were properly onboarded. Even recharging/powering can be done with solar. GPS relies on satellites, which as I understand could deliberately be made unusable or inaccurate to civilians at a moments notice (correct me if you think I'm wrong there). People would also obviously want maps to help interpret the location data, which would require intermittent connectivity to a centralized data source. Again, if this is not the case please correct me, but this is my reasoning. Since there is reliance on two separate centralized systems, I have not made integrating GPS a priority so far, and I guess I would have to see where interest is once I start producing these things. If that is a high priority for users, I would get it added somehow..maybe as an option you can add or remove any time.
@@mattcalhoun61 you’re 100 percent correct in regards to GPS’ potential future unreliability. I mean up until the late 90’s the government intentionally limited the accuracy of civilian GPS receivers. Additionally, we see in Ukraine GPS jamming occurring, not to mention the possibility of anti-sat warfare taking out GPS nodes. It’s an interesting thought experiment at least.
@@matchless2316 currently it doesn't work with meshtastic, because ChatterBox requires asymmetric encryption, digital signatures, pings for neighbor awareness and a few other things. I think some compatibility with meshtastic will come later on, but not just yet. Yeah if you're already set up with meshtastic, you may want to wait until some compatibility is in place
@@buysomerice I would say you described it about right. On the question of security, every message is signed, exactly like a crypto transaction, and the content is asymmetrically encrypted. Only the sender and receiver can read it. Devices that assist in mesh delivery only know where it's supposed to go and if it's expired, they cannot decrypt the payload. Security is a very high priority on these, which is also why they have no OS which could become compromised, and also no wifi or Bluetooth chip on board which could "leak" data. They do not rely on GPS or any external source for time, which could compromise digital signatures, but instead have an onboard high precision realtime clock.
@@mattcalhoun61 I know you like to say there is no OS to hack, but guys that do that just copy the data off the chips with some kind of eprom reader then load it up on a debug pc to actually hack. they would flash this new payload onto a compromised board and hand it off to someone, that person not knowingly or not has their messages be redirected or copied.
Yess, i have meshtastic, another one in kit, and i am waiting one from kickstarter, they are not compatible. The competition, emulation is good😊😊😊. Je m'abonne ❤
It depends on some factors I don't know for sure yet, but definitely less than $200 and probably more than $150. That will include everything, ready to turn on and put in your pocket or wherever. Or ready to plug your "base" antenna onto, in which case the built-in battery is more of a battery backup.
wow this is an amazing product in development, I'm really interested- Do you already have an estimate on how much a Chatterbox will cost per unit? I also wondered how your testing accounted for variables in line of site and if repeater nodes would be required at high spots to keep the cluster connected in the event of coms within a city with a lot of buildings in the way ?
As far as the price estimate, it depends on some factors I don't know yet, but for sure it should be less than $200 but likely more than $150. I have intentionally selected high quality components that allow someone with basic soldering skills to replace or swap individual components if they needed to. The complete parts list of a recent prototype (which will probably match 1.0) is here: www.chatters.io/s/chatterbox_parts_v04.pdf The way ChatterBoxes do meshing isn't just repeating. It is more like targeted forwarding, with the only limitation being the expiration set on delivery time (not so much # of hops). ChatterBoxes are sending and receiving pings every so often, which also carry useful information about what recent connectivity looks at all ends of the cluster. Using that information, routes can be planned to carry packets in the shortest number of hops, even if that means "turning corners" using strategically placed nodes that are in cars, building windows, or as you said, a high location is usually best (but maybe not always necessary). Obviously RF can't exactly turn corners, but for all intents an purposes, the packets themselves are doing that if you have a ChatterBox with line of site down two streets near an intersection, whether in your car, office window, etc. Also, the current implementation allows for up to 24 hours for mesh message delivery. So if, within 24 hours, the hops to get a message from one point to another make themselves available (people commuting, etc), the delivery can still happen. The cluster learns if there are "mules" in the cluster that touch various points, and will make use of them as necessary. For instance, a mule could be the car you commute in. It may collect packets its expected to deliver when you go out for lunch or go home for the day, and along the trip your ChatterBox is dumping packets to their next hop or final destination. It would also be picking up delivery confirmations that might be delivered the next time you go the other direction. There is no GPS involved or anything like that, it's all done using frequent RSS (signal strength) measurements.
@@dennistate5953 there are so many variables that there isn't an answer that's accurate for everyone, and I'm doing testing with many different antennas. I will be making a guide of some sort to help people think through deployments and be creative when doing so. I can tell you that I have a roof mounted omnidirectional antenna that, with reasonable line of site reliably gets 7+ miles in a single hop (have gotten as high as 13 in one hop). These this is with the out-of-the-box unit powered by the included rechargeable 3v battery, just upgraded well-placed antenna. I realize that is probably hard to believe, considering we are only talking low power .1 watt built-in transmitter with no boosters...but it is what it is. It's hard for me to believe myself sometimes. The signal will travel through some leaf cover and quite a few walls, but those will drastically lower the distance. The much smaller and more pocket sized "whip" antennas, device to device, can get anywhere from a multiacre property to several miles, again really depending on your environment. Hills kill the signal, but then again, if you can place a unit on a hill or high place, the same hill becomes a huge asset with meshing. I will definitely be putting some relevant info together, because this is probably the number one question.
It depends on many factors. You don't necessarily need perfect line of sight. The signals can penetrate some barriers, and if you use bidirectional amps, you can penetrate more. Since the devices do "smart" meshing, which involves path finding, if you have devices positioned in such a way that they can find paths around obstacles, they will do so automatically.
That is a great idea. Other meshtastic-compatible devices I've seen don't support touchscreens, which I really wanted to move toward. The tdeck does look like a very nice device though, and that might be worth considering adding support for.
@@RobR386 thanks for the note. I do have a couple of those and have been playing around with them. They are very well-designed and reasonably priced in my opinion. The only things I don't really like is they only have an sd card slot for storing state (as opposed to something like fram), and they don't have a good realtime clock, both of which I'd consider necessary for high security. I'm definitely still looking at them though, i really do like the design from a user's perspective.
Firstly, I think meshtastic looks fantastic from what I have seen. I have not personally used it, and I have so far avoided learning too much about it (sounds weird, but i wanted to arrive at original solutions and not be already biased toward doing things certain ways). I can definitely see the ChatterBoxes becoming compatible with meshtastic at some point. Having said all that, i think having multiple options is always good, but I wouldn't call ChatterBox "another meshtastic". There is obviously a lot of similarity, but what I am building is actually a secure communication platform that could use LoRa (which it is day 1), WiFi, wired connections, really any communication medium (even multiple on the same device). It is not really fixed to LoRa, I just happen to think LoRa is awesome, so I am working in that direction at the moment. On top of that medium (LoRa, etc), the "Chatters" layer adds asymmetric and/or symmetric encryption (depending on scenario), expiring digital signatures, and a system that can do mesh delivery across any combination of those channels i mentioned. I'm also building in a 'plug-in' mechanism where things like thermal cameras, relays, etc can directly and securely integrate with the system, likely by 'snapping' them back onto the back of a ChatterBox or something else super-simple. Not sure if that all made sense the way I said it, but what I'm getting at is that "texting" is actually a very small part of the system, but is what I'm highlighting at the moment. It is currently not open source. I would like it to be at some point, but I want to build up a very strong codebase first, which is highly adaptable. Strong encryption is utilized within the core of this system, so for legal reasons I really have to be careful about who can download it right now. As I interpret US law, even open sourcing something that has strong encryption can open some trouble, I'm just not ready to look into that quite yet. At some point I will have time to chase that down, but not just yet.
Meshtastic is just a protocol and firmware, like LoRaWAN they all use LoRa, I'm using meshtastic and been testing it for my use case, but i don't think Meshtastic is for everyone or every use case. Some alternatives or another option is always welcome. Plus i'm afraid Meshtastic became a bot bloated i think but that's just my opinion.
@@mrwoodcat not exactly. The last 100 (or so) messages are saved encrypted on the SD card, unless you turn that feature off. You can copy the SD card, and the original device would always be able to re display the messages that were stored, if you insert the encrypted/backed-up SD card into the same device and decrypt using the password that was utilized by the device at that previous point in time. The message logs are really designed to be unreadable to any other device though, at this point... including any PC or anything watching RF .
@@williamdeschamps9543 ecdsa for digital signatures, the encryption algos is designed to be pluggable, but is currently "chacha" 192 bit symmetric or asymmetric, depending on the context. Ultimately I want the user to be able to choose the algo, AES would work fine as well. Battery life depends on how you use it. For base stations where I'm not using the touchscreen at all, I'm getting about 2 days. A beta tester told me they get about 12 hours of they are using the touchscreen quite a bitm the battery is connected via a jst connection, and about any lipo 3.7v battery can work.
@@joshandersons6914 I don't know what the initial selling price will be, but if you want to the first to get some (you can get 2 or 3) by backing at a certain level, you can check out the Kickstarter campaign that just started last week: www.kickstarter.com/projects/altwaredevelopment/chatterbox-off-grid-secure-mesh-texting-device?ref=user_menu
Thanks for the feedback, the KS goal is tied to how much parts/production cost to do produce a batch large enough in size to get discounted pricing from manufacturers. If it doesn't reach, they will still be produced, probably just as fast (maybe faster) but lower initial quantity. The KS campaign is telling me which way to take that, more than anything else. I am quite interested in the starlink LTE connectivity that is supposed to be available this year. If that were to happen, I would probably build an LTE add-on that would "borrow" a starlink LTE connection to bridge to other LTE device(s)..which may have other neighborhoods connected. Since all packets going through LTE would be encrypted prior to getting to the LTE module, the security would still be intact, and you'd pretty much have a secure satellite mesh texting device. I think I can source decent LTE modules for < $100. Barring that, it definitely would be appropriate for neighborhood comm system, but even without LTE it definitely can go farther than just a neighborhood. It could connect multiple neighborhoods quite easily, of course depending on how far apart they are, the terrain, etc. How they can be used is a factor of what your area looks like and if you have access to hills or other high/good places.
Hey. Are you from Maryland? I hope I’m right. It’s an accent. Very vague.! 😂Hey dude. I want to talk to u about an idea for clusters and blockchain. Wish I could chatterbox u.
could you please design it like a pager and keep the cost around $20 if possible. At that form factor and price range, it would be a nonissue to wear one, have one thoughtlessly in a bag or in a pocket. Once this mesh network gets build up, make it more sophisticated, add MiniSD slots and create a web system interface, let them connect to phones over bluetooth or wifi. Wifi the signal from the phones back into the meshnetwork to enable global integrated communication
most carriers allow for 128kbps with a phone connection, so an associated app could run protocols between systems and it would also have more than enough transfer speed for messaging services
@@ChrisHillASMR I do like this thought. Right now, i'm prioritizing full functionality (whatever that ends up being for 1.0) with zero grid available. Global communication using wifi/internet/cloud is actually MUCH easier than what I've done so far, by building a simple encrypted message cache on aws or something else, but then there is this dependency on grid, wifi, and also a centralized point through which messages flow, which is exactly what I'm trying to avoid for now. I think there is definitely an opportunity for what you're talking about, but I'm just focused on being able to communicate in the absence of a functioning grid right now. Something similar to what you're saying might become an option for people who would want it, later on after I can get 1.0 out the door.
@@dontimberman5493 yes, they can show distance and direction from nodes, and also from each other (assuming the other party has location enabled). Also they show your heading/speed, and other parties ' last known heading/speed, again.. assuming other party has location sharing turned on
@@dontimberman5493 I'm getting some inventory here within the next week or so and will be ready to ship some around Halloween. It's looking like the entire batch will sell pretty much instantly, so I'm working on making it available in other ways as well .
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
Already a fully functional system in place "Meshtastic". But Competition is always good.
Dosen't one of these big LoRa systems require use of a phone number or something simimilarly counterproductive? This seems to be targeting those concerns.
@@galvanizeddreamer2051not meshtastic, at least
what difference between them?
Right. And can turn into cooperation.
Amazing project!
You could also include a section with other devices like sensors!
Yes.. already in the works
Definitely interested! Lmk when they go on sale
I think it's not entirely correct to say that it "does not use an operating system". It does not use a conventional one, like Windows or Linux, or Android, but it has an OS to run it. It may be very simple, but it still needs to do things to communicate with different hardware. So it does have an attack surface, potentially. Especially with external input that comes in and needs to be parsed... Where there is parsing - there are buffers, and where there are buffers - there are overflows. And on a non-memory-managed system (I imagine this thing does not run in protected mode) an overflow can touch literally anything with fancy enough exploitation techniques.
Thanks for the well-thought-out comment. The device is based around a single board microcontroller (currently the Adafruit M4 Express samd51). That SMB (along others I've been targeting) is single-threaded and has a boot loader that loads the ChatterBox firmware from eeprom or flash into memory. At that point, there is no OS layer, it's just the ChatterBox firmware communicating directly with hardware. Nothing (besides the ChatterBox firmware) is managing memory or resources. The conveniences an OS would provide must be handled directly by the ChatterBox firmware. Since that is the I do think it's technically correct to say it "has no OS". If you disagree with that, I would definitely like to hear more.
You are certainly correct that buffers are utilized, and they can typically present all sorts of problems. I have made some deliberate design decisions to mitigate those risks, to the degree possible, and help to tilt potential issues in the user's favor as much as possible. Here are a few thoughts to provide you with insight into how I am mitigating risks of buffer overflow:
The ChatterBox firmware is written in C++ and it is using FIXED-length buffers everywhere (fixed at compile time). It is not dynamically allocating memory, but rather the buffers are all set aside all at once as the system is initializing. All messages and data payloads are currently limited to a certain fixed-length size. Before transmission or storage, each message is packetized into much smaller pieces. Those much smaller packets are what gets encrypted, so at any time, I'm dealing with very small fragments of data (just big enough to meet the block cipher size).
Every transmission is digitally signed. If any buffer involved in that chain of packetizing/encrypting/hashing was to overflow (which I have intentionally caused to happen during testing), the signature is no longer valid, so the entire message is ignored. I have intentionally triggered buffer overflows at various points during testing, and the result has been that malicious data is stopped dead in its tracks when a sig check fails and the device continues on as normal.
To the degree possible, any potentially sensitive buffers are zeroed out immediately after the data sitting in them is no longer needed in memory.
There is no file system. A file system would typically do some sort of caching, so I am not using one (not even an emulated one). All data is stored in FRAM, where again, everything is packetized into fixed length and encrypted using a block cipher algorithm (different encryption key), with each 'slot' in FRAM being long enough to handle the length of the data plus the bloat that can added by encryption.
Having said all that, I'm certainly not going to claim the ChatterBox could never have a buffer overflow. But, I do test for that and if something was to trigger a buffer overflow somehow, the behavior I expect to see would be that a message or data payload would get thrown out because a signature would no longer be valid.
@@mattcalhoun61 After reading this I would agree with you. I think my comment was a bit hasty, but the line that separates an "OS" from "non-OS" is pretty blurry...
For instance, I have a Flipper Zero device, which is running on a microcontroller and has a bunch of peripherals, including various radios, etc... But it does have a filesystem, external apps, etc... So it's more like an OS, but my gut tells me it's a firmware :D
What would be a definitive distinction, if we are to get philosophical in YT comments? :D Do you need to have threads, or drivers, or apps, or a HAL, or to have a clear distinction between a kernel and userland software? I'd have to reflect on that...
@@VasilisOfficeHours I do not currently need threads, but do "simulated" multithreading similar to how an OS would have done so in the past, with timers, interrupts, and things like that. I do use hardware libraries in some cases, and direct SPI/I2C/UART "wire" calls in others, depending on what I think makes sense. There are no "apps", it's just the ChatterBox firmware, which does happen to be very extensible, ready to deal with other types of transceivers, sensors, etc, as I find good fits and see what people want as time goes on.
These are good questions by the way, thanks
If it uses esp32 there is likely an rtos doing wifi management.
@@obstacleman thank you, great comment. It is using samd51 and not esp32 for that very reason. There is no wifi on board at all. There is capability to plug in a wifi chip as a secondary delivery method for your cluster, but I am not including that in the base device. When I start adding plug and play thermal cams and stuff, higher bandwidth might become desirable , but for now its just an rfm95w module on board
Looks like a cool setup.
This is fantastic. I have a few questions:
1. When a message is passed through a mesh, is the intended recipient known to the nodes that are holding onto the message?
2. Can a device be a member of multiple clusters?
3. Can a device pretend to be another node by spoofing its name? would It then receive messages that weren't intended for it? could it prevent the intended recipient from recieving the message if it was closer/online earlier etc. I imagine the fake node wouldn't be able to decrypt the message but could this interfere in other ways? or perhaps there is a protocol to make sure the actual intended recipient acknowleges in a signed way?
4. It seems like all members of a cluster would have at least some ability to see what traffic is happening within the cluster (including the node names of the people talking to each other) if their device was acting as a relay in the mesh. would nearby other clusters have any transparency into this traffic?
I really love this concept, you've done excellent work
These answers probably need a little more detail than I am typing in this comment, but here goes...
1. Yes, all devices participating in meshing of a particular message need to at the very least, be aware of the existence of the end recipient. Due to how knowledge of devices and their connectivity is passed around, this actually happens surprisingly quickly, even if a new device is just powered on for the first time. The video I posted on simulation of the mesh algo explains this somewhat (ruclips.net/video/0eQud9eQEXw/видео.html). If a device comes across one it has never been near before, it automatically requests a public key exchange. Along with the key exchange, each device provides a "license" which is a signature of its public key + alias, generated by the root device at onboarding. Any device can compare the sig with the root's public key to verify authenticity during this public key exchange, which can happen at any time between 2 devices.
2. Yes, a device can be in 2 clusters. A cluster can have up to 90 devices. So any device should have no trouble getting a message to any of the other 89 messages in its cluster. I am about to start "phase 2" of the meshing algo, which will involve cross-cluster delivery and routing. That would mean, linking clusters either formally or ad-hoc, and leveraging this dual cluster -per device capability would give a cluster direct connectivity to up to 90 other clusters. Even if they're listening on different frequencies, it wouldn't matter. It is possible that a cluster could be set up as a dedicated "backbone" that only exists for linking scattered clusters over large distances. Or multiple backbones or other patterns going in various directions, maybe with very large antennas.
3. The name you see is really just an alias. Each cluster and device has a unique id which is actually what's used for delivery. All messages are signed using the sender's private key. All acknowledgements are signed by the recipients key. Since RF is involved, there are always going to be ways to cause interference, but I think I have pretty much minimized potential weaknesses within the protocol in all ways I can think of. Even pings that are used for relaying connectivity info are signed (pings are broadcast using a cluster symmetric key and they are not acknowledged).
4. Yes, all members of a cluster see traffic on the cluster's frequency, even if it were for other clusters that are using the same frequency. Broadcast message payloads are unreadable to off-cluster devices. Direct messages are unreadable to any device except for the sender and recipient. A nearby cluster would not be able to acknowledge or decrypt any broadcast or direct messages from your cluster. The other cluster's messages, acknowledgements, and pings are ignored by your cluster, since the cluster ID is different (name could be the same and wouldn't matter, it's just an alias for you).
Not ALL data is encrypted. Payloads certainly are, and all messages are signed (with expiry so another cluster couldn't "replay" your messages). Data used for routing (sender device id/recipient device id, expiry, various message flags) are not encrypted, mostly to reduce unnecessary decryptions and message "bloat". I suppose I could encrypt those using cluster's symmetric key, and the mesh delivery would still work OK, but at the moment I have those bits of data as clear text.
@@glemblemble forgot to mention, even routing related data that I said is not encrypted IS signed as well, so even though it could be read, it cannot be spoofed. Also device and cluster IDs that are hidden to you and actually used for routing are alphanumeric strings, not simply a one or two byte number.
@@mattcalhoun61 Incredible, Thanks for the detailed reply. That all sounds really well thought through. Can't wait for the next update
Do you plan on adding GPS support? I think the added security this has over meshtastic would potentially pair well with ATAK. Anyway awesome project, good to see more LoRA based projects!
I hate to say I had not heard of ATAK until you mentioned it, but that is quite the rabbit hole, and I think you're right there could be some interesting overlap there for sure. I'm building these in such a way that it should be quite easy to integrate sensors of various types.
There is no technical reason why GPS couldn't be added, but I have avoided doing so because as of now. Once you have a device running in your hand, from that point forward it has zero dependence on any centralized thing (internet, satellite, etc). It might never have connectivity to a computer/phone/wifi/etc, and it would work fine for its entire lifecycle, even recognizing devices it had never seen before, if the other devices were properly onboarded. Even recharging/powering can be done with solar.
GPS relies on satellites, which as I understand could deliberately be made unusable or inaccurate to civilians at a moments notice (correct me if you think I'm wrong there). People would also obviously want maps to help interpret the location data, which would require intermittent connectivity to a centralized data source. Again, if this is not the case please correct me, but this is my reasoning. Since there is reliance on two separate centralized systems, I have not made integrating GPS a priority so far, and I guess I would have to see where interest is once I start producing these things. If that is a high priority for users, I would get it added somehow..maybe as an option you can add or remove any time.
@@mattcalhoun61 you’re 100 percent correct in regards to GPS’ potential future unreliability. I mean up until the late 90’s the government intentionally limited the accuracy of civilian GPS receivers. Additionally, we see in Ukraine GPS jamming occurring, not to mention the possibility of anti-sat warfare taking out GPS nodes.
It’s an interesting thought experiment at least.
Like the looks of the device..but can it talk with neshtastic nodes? I hesitate to buy into anything that forces a start from scratch position.
@@matchless2316 currently it doesn't work with meshtastic, because ChatterBox requires asymmetric encryption, digital signatures, pings for neighbor awareness and a few other things. I think some compatibility with meshtastic will come later on, but not just yet. Yeah if you're already set up with meshtastic, you may want to wait until some compatibility is in place
Might still be in a dev branch, but Meshtastic has asymmetric encryption in the latest builds.
@@Cabinlab I was not aware, definitely need to check it out
@@mattcalhoun61 It's in the v2.5 Tech Preview, just released 3 days ago
This is awesome! I'd be interested in buying something like this as a kit or prebuilt.
So in simple terms you are building a self contained and secure mesh network of up to 90 devices. How secure would this mesh be? This sounds amazing.
@@buysomerice I would say you described it about right.
On the question of security, every message is signed, exactly like a crypto transaction, and the content is asymmetrically encrypted. Only the sender and receiver can read it. Devices that assist in mesh delivery only know where it's supposed to go and if it's expired, they cannot decrypt the payload.
Security is a very high priority on these, which is also why they have no OS which could become compromised, and also no wifi or Bluetooth chip on board which could "leak" data.
They do not rely on GPS or any external source for time, which could compromise digital signatures, but instead have an onboard high precision realtime clock.
Amazing! I went to the website and learned more after my comment. Appreciate your comment also. I’m following and will support if I can!
@@mattcalhoun61 I know you like to say there is no OS to hack, but guys that do that just copy the data off the chips with some kind of eprom reader then load it up on a debug pc to actually hack. they would flash this new payload onto a compromised board and hand it off to someone, that person not knowingly or not has their messages be redirected or copied.
@@mattcalhoun61 you also need to look into how easy it would be to Hardware ID spoof your device on software.
This is awesome
Yess, i have meshtastic, another one in kit, and i am waiting one from kickstarter, they are not compatible. The competition, emulation is good😊😊😊.
Je m'abonne ❤
Curious what the estimated price per node may be?
It depends on some factors I don't know for sure yet, but definitely less than $200 and probably more than $150. That will include everything, ready to turn on and put in your pocket or wherever. Or ready to plug your "base" antenna onto, in which case the built-in battery is more of a battery backup.
@@mattcalhoun61 excited to get my hands on a pair 😁
wow this is an amazing product in development, I'm really interested- Do you already have an estimate on how much a Chatterbox will cost per unit? I also wondered how your testing accounted for variables in line of site and if repeater nodes would be required at high spots to keep the cluster connected in the event of coms within a city with a lot of buildings in the way
?
As far as the price estimate, it depends on some factors I don't know yet, but for sure it should be less than $200 but likely more than $150. I have intentionally selected high quality components that allow someone with basic soldering skills to replace or swap individual components if they needed to. The complete parts list of a recent prototype (which will probably match 1.0) is here: www.chatters.io/s/chatterbox_parts_v04.pdf
The way ChatterBoxes do meshing isn't just repeating. It is more like targeted forwarding, with the only limitation being the expiration set on delivery time (not so much # of hops). ChatterBoxes are sending and receiving pings every so often, which also carry useful information about what recent connectivity looks at all ends of the cluster. Using that information, routes can be planned to carry packets in the shortest number of hops, even if that means "turning corners" using strategically placed nodes that are in cars, building windows, or as you said, a high location is usually best (but maybe not always necessary). Obviously RF can't exactly turn corners, but for all intents an purposes, the packets themselves are doing that if you have a ChatterBox with line of site down two streets near an intersection, whether in your car, office window, etc.
Also, the current implementation allows for up to 24 hours for mesh message delivery. So if, within 24 hours, the hops to get a message from one point to another make themselves available (people commuting, etc), the delivery can still happen. The cluster learns if there are "mules" in the cluster that touch various points, and will make use of them as necessary. For instance, a mule could be the car you commute in. It may collect packets its expected to deliver when you go out for lunch or go home for the day, and along the trip your ChatterBox is dumping packets to their next hop or final destination. It would also be picking up delivery confirmations that might be delivered the next time you go the other direction.
There is no GPS involved or anything like that, it's all done using frequent RSS (signal strength) measurements.
@@mattcalhoun61 thank you for this detailed response and answer to my question
I’m very excited about this project
Interesting device man, I would be interested in buying a few I will register with your site.
Technology like this is needed to keep KEKISTAN FREE! Please keep working on this open source project 🐸
I may have missed it & get terrain, etc., but any reasonable estimate of effective range between units?
@@dennistate5953 there are so many variables that there isn't an answer that's accurate for everyone, and I'm doing testing with many different antennas. I will be making a guide of some sort to help people think through deployments and be creative when doing so.
I can tell you that I have a roof mounted omnidirectional antenna that, with reasonable line of site reliably gets 7+ miles in a single hop (have gotten as high as 13 in one hop). These this is with the out-of-the-box unit powered by the included rechargeable 3v battery, just upgraded well-placed antenna. I realize that is probably hard to believe, considering we are only talking low power .1 watt built-in transmitter with no boosters...but it is what it is. It's hard for me to believe myself sometimes.
The signal will travel through some leaf cover and quite a few walls, but those will drastically lower the distance.
The much smaller and more pocket sized "whip" antennas, device to device, can get anywhere from a multiacre property to several miles, again really depending on your environment. Hills kill the signal, but then again, if you can place a unit on a hill or high place, the same hill becomes a huge asset with meshing.
I will definitely be putting some relevant info together, because this is probably the number one question.
@@mattcalhoun61 Thank you. That sounds like more than adequate tactical range for ops purposes.
whats the range of something like this if there are trees or houses in the way? Do they have to have line of sight to work?
It depends on many factors. You don't necessarily need perfect line of sight. The signals can penetrate some barriers, and if you use bidirectional amps, you can penetrate more. Since the devices do "smart" meshing, which involves path finding, if you have devices positioned in such a way that they can find paths around obstacles, they will do so automatically.
Hope you can flash this over existing meshtastic devices. Like tdeck
That is a great idea. Other meshtastic-compatible devices I've seen don't support touchscreens, which I really wanted to move toward. The tdeck does look like a very nice device though, and that might be worth considering adding support for.
The T-Deck has a touchscreen and a physical keyboard
@@RobR386 thanks for the note. I do have a couple of those and have been playing around with them. They are very well-designed and reasonably priced in my opinion. The only things I don't really like is they only have an sd card slot for storing state (as opposed to something like fram), and they don't have a good realtime clock, both of which I'd consider necessary for high security. I'm definitely still looking at them though, i really do like the design from a user's perspective.
Why another meshtastic? Is it open source?
Firstly, I think meshtastic looks fantastic from what I have seen. I have not personally used it, and I have so far avoided learning too much about it (sounds weird, but i wanted to arrive at original solutions and not be already biased toward doing things certain ways). I can definitely see the ChatterBoxes becoming compatible with meshtastic at some point.
Having said all that, i think having multiple options is always good, but I wouldn't call ChatterBox "another meshtastic". There is obviously a lot of similarity, but what I am building is actually a secure communication platform that could use LoRa (which it is day 1), WiFi, wired connections, really any communication medium (even multiple on the same device). It is not really fixed to LoRa, I just happen to think LoRa is awesome, so I am working in that direction at the moment. On top of that medium (LoRa, etc), the "Chatters" layer adds asymmetric and/or symmetric encryption (depending on scenario), expiring digital signatures, and a system that can do mesh delivery across any combination of those channels i mentioned. I'm also building in a 'plug-in' mechanism where things like thermal cameras, relays, etc can directly and securely integrate with the system, likely by 'snapping' them back onto the back of a ChatterBox or something else super-simple. Not sure if that all made sense the way I said it, but what I'm getting at is that "texting" is actually a very small part of the system, but is what I'm highlighting at the moment.
It is currently not open source. I would like it to be at some point, but I want to build up a very strong codebase first, which is highly adaptable. Strong encryption is utilized within the core of this system, so for legal reasons I really have to be careful about who can download it right now. As I interpret US law, even open sourcing something that has strong encryption can open some trouble, I'm just not ready to look into that quite yet. At some point I will have time to chase that down, but not just yet.
Meshtastic is just a protocol and firmware, like LoRaWAN they all use LoRa,
I'm using meshtastic and been testing it for my use case, but i don't think Meshtastic is for everyone or every use case.
Some alternatives or another option is always welcome.
Plus i'm afraid Meshtastic became a bot bloated i think but that's just my opinion.
can it save the chat logs and transfer it to PC for archive ?
@@mrwoodcat not exactly. The last 100 (or so) messages are saved encrypted on the SD card, unless you turn that feature off. You can copy the SD card, and the original device would always be able to re display the messages that were stored, if you insert the encrypted/backed-up SD card into the same device and decrypt using the password that was utilized by the device at that previous point in time.
The message logs are really designed to be unreadable to any other device though, at this point... including any PC or anything watching RF .
What type of encryption does it use to be secure? Also how's the battery life? Very interested in the idea of encrypted LoRa.
@@williamdeschamps9543 ecdsa for digital signatures, the encryption algos is designed to be pluggable, but is currently "chacha" 192 bit symmetric or asymmetric, depending on the context. Ultimately I want the user to be able to choose the algo, AES would work fine as well. Battery life depends on how you use it. For base stations where I'm not using the touchscreen at all, I'm getting about 2 days. A beta tester told me they get about 12 hours of they are using the touchscreen quite a bitm the battery is connected via a jst connection, and about any lipo 3.7v battery can work.
How much each ? I want to purchase two pieces
@@joshandersons6914 I don't know what the initial selling price will be, but if you want to the first to get some (you can get 2 or 3) by backing at a certain level, you can check out the Kickstarter campaign that just started last week: www.kickstarter.com/projects/altwaredevelopment/chatterbox-off-grid-secure-mesh-texting-device?ref=user_menu
@@mattcalhoun61 Got it, Thank you. Looks like a VERY good device compare with others with less feature.
Your KS goal is WAY too high.
Will this have a way to connect to smartphones?
I'm imagining it as a neighborhood comm system.
Thanks for the feedback, the KS goal is tied to how much parts/production cost to do produce a batch large enough in size to get discounted pricing from manufacturers. If it doesn't reach, they will still be produced, probably just as fast (maybe faster) but lower initial quantity. The KS campaign is telling me which way to take that, more than anything else.
I am quite interested in the starlink LTE connectivity that is supposed to be available this year. If that were to happen, I would probably build an LTE add-on that would "borrow" a starlink LTE connection to bridge to other LTE device(s)..which may have other neighborhoods connected. Since all packets going through LTE would be encrypted prior to getting to the LTE module, the security would still be intact, and you'd pretty much have a secure satellite mesh texting device. I think I can source decent LTE modules for < $100.
Barring that, it definitely would be appropriate for neighborhood comm system, but even without LTE it definitely can go farther than just a neighborhood. It could connect multiple neighborhoods quite easily, of course depending on how far apart they are, the terrain, etc. How they can be used is a factor of what your area looks like and if you have access to hills or other high/good places.
Hey. Are you from Maryland? I hope I’m right. It’s an accent. Very vague.! 😂Hey dude. I want to talk to u about an idea for clusters and blockchain. Wish I could chatterbox u.
@@mr.medicineman Midwest , but not too far off. You can email me with ideas, the contact page on the site goes directly to me. chatters.io/contact
not protected but from air gap
could you please design it like a pager and keep the cost around $20 if possible. At that form factor and price range, it would be a nonissue to wear one, have one thoughtlessly in a bag or in a pocket. Once this mesh network gets build up, make it more sophisticated, add MiniSD slots and create a web system interface, let them connect to phones over bluetooth or wifi. Wifi the signal from the phones back into the meshnetwork to enable global integrated communication
most carriers allow for 128kbps with a phone connection, so an associated app could run protocols between systems and it would also have more than enough transfer speed for messaging services
@@ChrisHillASMR I do like this thought. Right now, i'm prioritizing full functionality (whatever that ends up being for 1.0) with zero grid available. Global communication using wifi/internet/cloud is actually MUCH easier than what I've done so far, by building a simple encrypted message cache on aws or something else, but then there is this dependency on grid, wifi, and also a centralized point through which messages flow, which is exactly what I'm trying to avoid for now. I think there is definitely an opportunity for what you're talking about, but I'm just focused on being able to communicate in the absence of a functioning grid right now. Something similar to what you're saying might become an option for people who would want it, later on after I can get 1.0 out the door.
So can this do direction and distance from node? And what can I do (if anything) to help? I would buy a set right now if I could.
@@dontimberman5493 yes, they can show distance and direction from nodes, and also from each other (assuming the other party has location enabled). Also they show your heading/speed, and other parties ' last known heading/speed, again.. assuming other party has location sharing turned on
@@dontimberman5493 I'm getting some inventory here within the next week or so and will be ready to ship some around Halloween. It's looking like the entire batch will sell pretty much instantly, so I'm working on making it available in other ways as well .
@@mattcalhoun61 not a bad problem to have.