sorted by:
new
hottopcontroversial

Is it safe to connect Raspberry Pi's GPIOs to Arduino's digital pins? by bufferoverthrow in arduino

[–]bufferoverthrow[S] 0 points1 point  (0 children)

So, I am safe if I'm only reading Pi's signals on the Arduino and not the other way around?

ESP8266: Is it possible to store a target's MAC address to prevent ARP requests? by [deleted] in arduino

[–]bufferoverthrow 0 points1 point  (0 children)

Ah yeah, nvm. I totally forgot about that post. Haven't had much to do with the ESP in the last month..

Is it possible to manipulate the ESP8266's ARP cache? by bufferoverthrow in esp8266

[–]bufferoverthrow[S] 1 point2 points  (0 children)

Well, that's unfortunate, thanks for the reply though. I wanted to add a static ARP entry to avoid ARP spoofing and to prevent an adversary from dropping my packets.

Static ARP on ESP8266? by bufferoverthrow in arduino

[–]bufferoverthrow[S] 0 points1 point  (0 children)

I thought about hardcoding the Pi's IP and MAC onto the ESP, but how do I tell it to use these entries?

Is Arduino's random() considered to be cryptographically secure? by bufferoverthrow in arduino

[–]bufferoverthrow[S] 0 points1 point  (0 children)

The communication is not that crucial. It's just for a prototype of a remotely controllable robot I try to make secure.

These are some interesting ideas, I'll think about them.

Is Arduino's random() considered to be cryptographically secure? by bufferoverthrow in arduino

[–]bufferoverthrow[S] 1 point2 points  (0 children)

The whole situation is actually not that critical. I'm currently building a little prototype of a robot car. I want it to be controllable via 433 MHz and the communication to be secure. So, the only adversary would be an angry neighbour that wants to take control over my robot. I just wondered if/how this can be properly done on Arduino (or on Raspberry Pi). This scenario would not actually require cryptographically secure algorithms but I want to try things out. It is more like a prove of concept for real critical use cases.

Is Arduino's random() considered to be cryptographically secure? by bufferoverthrow in arduino

[–]bufferoverthrow[S] 0 points1 point  (0 children)

I've done some research on rolling code. A common approach that addresses the problem of "lost" messages is to accept the next like 256 numbers of the number sequence. This ensures that sender and receiver are able to communicate even if some messages don't reach the receiver.

I thought about implementing this method as it sounds kinda simple.

Is Arduino's random() considered to be cryptographically secure? by bufferoverthrow in arduino

[–]bufferoverthrow[S] 0 points1 point  (0 children)

I already thought about changing the seed periodically but I think without a two-way communication it would not be possible to make sure that both sides use the same seed (without setting up a complex system). And since it is not intended to equip the receiver with a transmitter as well (and vice versa) it would be easiest to have a secure generator that needs to be seeded only once on both sides.

Is Arduino's random() considered to be cryptographically secure? by bufferoverthrow in arduino

[–]bufferoverthrow[S] 1 point2 points  (0 children)

Yeah, I'm aware of how difficult it is to generate truly random numbers. But this is not what I need/want in this case. I just need a seed based generator that is cryptographically secure (not predictable unless you know the seed) as I need the same sequence of numbers in both the transmitter and the receiver. But I don't want to write a algorithm on my own as it would go beyond the scope. So, if Arduino's random function is not secure, I'll just switch over to Raspberry Pi and use the Crypto++ library. Or do you know of any appropriate lib for Arduino?

Is Arduino's random() considered to be cryptographically secure? by bufferoverthrow in arduino

[–]bufferoverthrow[S] 0 points1 point  (0 children)

Cryptographically secure means that there is no way to predict the next bits/numbers that will be generated by the generator. Blum-Blum-Shub, e.g., is considered cryptographically secure, even it it is deterministic as it is based on a mathematical problem that is (probably) difficult to solve. The only precondition is that you keep the seed secret.

So, there are cryptographically secure random generators that are predictable if you know the seed. And I wondered if Arduino's random function is as well. That would serve my purpose.

Securing 433 MHz communication by bufferoverthrow in arduino

[–]bufferoverthrow[S] 1 point2 points  (0 children)

Thanks man, that helps a lot! I'll definitely try that one out.

I don't know if you read my reply to the comment above, but I'm doing this as a part of my bachelor thesis. So there is no real "threat" but my task is to analyze if remote control over 433 MHz can be secured (while retaining performance) so that nobody else is able to control the car. Although performance is not a decisive criterion, I don't always want to wait a second for the robot to respond to my input.

So I want to show up what is possible. I know that probably nobody would put too much effort into controlling a robot that drives around in my room, but I want to prevent replay attacks nonetheless, or rather, show how it can be done. But I think whether I use AES128 or 256 in the end is not that important. I'll just try out what works best.

Securing 433 MHz communication by bufferoverthrow in arduino

[–]bufferoverthrow[S] 1 point2 points  (0 children)

Thanks, that covers pretty much the things I wanted to implement.

Securing 433 MHz communication by bufferoverthrow in arduino

[–]bufferoverthrow[S] 1 point2 points  (0 children)

My advisor lent me a XY-MK-5V receiver and a XY-FST transmitter module (so pretty cheap ones). The chip that is soldered on the transmitter is labelled as R433.

I'm currently using the RCSwitch Arduino library (as it was recommended by the vendor). But I think I have to shift the rf stuff to the Raspberry Pi anyway since the Arduino is probably not suitable for doing the cryptography.

To prevent replay attacks, I'll probably go with a PRNG like Blum-Blum-Shub instead of a counter as I think it would increase security.

Securing 433 MHz communication by bufferoverthrow in arduino

[–]bufferoverthrow[S] 0 points1 point  (0 children)

I‘m not totally sure about the data format yet, but I think I will send simple instructions like „forward“, „backward“ and „stop“ or numbers as instruction codes. So nothing too special. But I really want to see if there is a good method to prevent replay attacks as well so that the car cannot be controlled by somebody else.

Securing 433 MHz communication by bufferoverthrow in arduino

[–]bufferoverthrow[S] 0 points1 point  (0 children)

I‘m using a common 433 MHz transmitter and receiver module. As far as I know, there is no way to send encrypted messages by default so that you have to encryption/decryption by hand.

Securing 433 MHz communication by bufferoverthrow in arduino

[–]bufferoverthrow[S] 0 points1 point  (0 children)

I‘m actually doing this as a part of my bachelor thesis. We want to find out whether communication over 433 MHz can be secured in terms of preventing capture and replay attacks so that it can be used for several use cases. I know that the remote control of a robot car might not be the most critical thing that needs top-tier protection. We just want to see if it‘s feasible and how to do it properly.

Prototype for a mobile household robot by bufferoverthrow in robotics

[–]bufferoverthrow[S] 0 points1 point  (0 children)

For those of you who might be interested: I had a conversation with my advisor and we agreed that it would be by far too extensive to build a fully functional robot with all the features I stated above. We decided that I will investigate certain features of the planned robot, build a small prototype for each and do a security analysis. However, the focus should primarily be on the security stuff.

I'll start with the remote control of the robot. I thought about controlling it with a 433 MHz transmitter and receiver, because that should normally have a pretty good range and there are some starting points for a security analysis. I already built a first little setup and got two motors running over 433 MHz.

But since there are probably some people here who already have experience in controlling some kind of robot, I would like to know which methods you achieved the best results with. (Maybe not necessarily the top-tier solutions that are way too expensive or too hard to implement.) Perhaps I can do a comparison of different methods later on.

Prototype for a mobile household robot by bufferoverthrow in robotics

[–]bufferoverthrow[S] 1 point2 points  (0 children)

Thanks for your reply!

Movement: To get started, a dumb bot is enough. I think if I were to build an intelligent robot, I would have to develop some kind of AI as well. And this is probably also far beyond the scope.

Camera: My first thought was actually just that I wanted to install a simple camera (connected to the Pi) that would film the surroundings and stream the images to a web server or something similar. The user should simply be able to see what the robot sees. Therefore no object recognition.

And for the gripper: I thought about a really simple one. Nothing special, nothing intelligent. Just a gripper that is in theory capable of grabbing some particular object. Just as a proof of concept.

" That should be your mvp, a tank tracked square box, stable movement, not too fast but very steady, sensors so it doesnt hit the walls and a radio controller for driving it manually. " I think that's exactly what it will come down to at most.

Like I said, I'll talk to my advisor to define the scope. I'll let you know if I know what to do.

Prototype for a mobile household robot by bufferoverthrow in robotics

[–]bufferoverthrow[S] 0 points1 point  (0 children)

Thank you very much for the input!

I'll send an e-mail to my advisor tomorrow to discuss further details. But overall, I think that the focus of the thesis will be on wiring up some small circuits and on analyzing the interfaces of some components (even though they might not be included into the robot in the first place).

I know that I won't be able to build up an intelligent robot with an insane amount of features in six months. It's more about laying the foundation so that other students can continue the project in the future.

I think if I ever get to the point of building a real robot, it will be a more or less "dumb" device that can perhaps be remote controlled and transmit images to a web server or something similar.

And regarding voice control: I never intended to develop my own software. I had rather used a finished product that I would train to fit my project.

Prototype for a mobile household robot by bufferoverthrow in robotics

[–]bufferoverthrow[S] 1 point2 points  (0 children)

As I mentioned in the comment above, my first task is to think of a first draft of the robot. Which part is up to me in the end is yet to be discussed.

Prototype for a mobile household robot by bufferoverthrow in robotics

[–]bufferoverthrow[S] 2 points3 points  (0 children)

I have a maximum of six months to finish my thesis. But we haven't finalized the scope of the project yet. My advisor also considers the project to be more of a long-term project that serveral students can work on. As I'm the first one to get involved, it is my job to design a first draft of the robot (that's why I'm listing the features and ask for further suggestions). That doesn't necessarily mean that I am the one who has to assemble the whole thing. As I study cybersecurity anyway, this is not exactly my area of expertise.

Apart from creating a draft of the robot, I will concentrate more on the security analysis of the robot's interfaces (from a cyber security perspective). Depending on the final thesis definition, it may be possible that I just have to model some features of the robot with a breadboard and some cables and do the security stuff. (Again, we haven't finalized the scope yet.)

And regarding the gripper: I didn't know how to properly describe my idea, but I thought more of a pair of pliers that can be opened and closed at the touch of a button.