I am working on a project where an Arduino will send measurements and receive commands through an Ethernet interface and a REST API to open and lock a door. For all means, we can consider that the devices are protected, but that the Ethernet network may be accessed. Therefore, a Man-in-the-middle attack is plausible.
The commands to open/lock the door will be part of the reply of an HTTP GET request. In order to prevent a MITM attack where the response is faked to open the lock, I want to use some kind of encrypted response. Now, Arduinos lack the power to use HTTPS, and I want it to be Arduinos because of costs and ease of development.
I have come up with the following scheme:
Both the Arduino and the server have an identical set of index-value registers. The value will be used as a code to encrypt using AES-128.
When the Arduino sends its GET request, it also sends a randomly selected index, indicating to the server which value to use to encrypt the open/lock command.
The server sends a clear text response (JSON) where the command field is an encrypted text.
The Arduino will decode it and apply the required action.
The Arduino will also send some sensor data from time to time. In this case, it will send the index of the code it used to encrypt the data and the encrypted data.
The set of index-value keys is large, so repetitions are rare (but may occur from time to time).
My question is, is this scheme secure? Am I missing something? Is there any other more tested alternative for securing these interactions that doesn't involve using a more advanced platform?
Thanks in advance!
Use an ESP2866 based Arduino. It does not cost significantly more, it uses the same tools but you can use SSL instead of rolling your own solution. I have used the Wemos D1 boards and they work as a drop in Arduino replacement.
I have a physical IOT device with an ePROM in it that contains a unique serial number (userID) and generated random password. it connects via sFTP and http services to our server, using these credentials.
I figure we can use Diffie-Hellman to protect ourselves from impostors who lack physical access to our devices, from sending false data and getting free service charged to someone else.
But because our devices are "in the wild" it might be easy for some one to get physical access to one our units and clone our ePROM.
My question is what is the best way to protect ourselves from such attacks.
I think you would need something like the TPM module in Lenovo laptops. It is a small hardware module that can store a private key, and you cannot get the key once it is written. This way you could write the private key to the TPM, then deploy it, and nobody would be able to impersonate. They would be able to change the private key, but then you would notice since the public key would not match.
Now, I am not sure how costly such a module is, and I am not sure about extra battery cost, but this would secure your device.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have a game server where clients can connect and communicate with via TCP. Any device can connect the server if it knows the IP and port.
I am wondering if I need to add some security to the server. For example,
(1) Add some encryption for the messages sent/received. (To prevent the protocol content is revealed)
(2) Add some key to the message so if the server cannot recognize the key after decryption, the message will be dropped. (To prevent unknown connections/messages flooding in)
Do you think these things are necessary and is there any other thing I should add for such a game server.
I would have rather posted this to the gamedev question but the mods there are apparently faster than here. Before you quote me, I'd like to point out that the following isn't based on 100% book-knowledge, nor do I have a degree in any of these topics. Please improve this answer if you know better, rather than comment and/or compete.
This is a pretty comprehensive list of client/server/security issues that I've gathered from research and/or experience:
Data
The "back-end" server contains everyone's username, password, credit card details, etc., and should be a fortress. This server is for authentication only and should be on a private subnet; it will communicate only with the login server, only when a well-formed login request is received, and will only reply with "allow" or "deny". If you take people's personal information, you are obligated to protect it, and it would be wise to off-load the liability of everything security-related to a professional or hosting company. There is no non-critical attack to this server; if it is breached, you are finished. Many/most/all companies now draw their pretty login screen on top of another companies' back-end credit card/billing system.
Login
Connections to the login server should be secure. The login server is just a message pump between the public login mechanism, the private data store, and the client/server connection state. For security purposes, any HTTP access to the login system should be hosted on a separate HTTP server; the WWW server crashing should not shut down your online game (my opinion).
World/UDP
Upon successful login and authentication, the server informs the client to begin listening for "bulk data" or to initiate an in-bound connection on a specific UDP port (could be random and per-connection-attempt). Either way, the server should remain silent and wait for the client to IDENT with some type of handshake to verify that the "alleged client" is actually your code. It is easier to guess when the server asks for input sequentially; instead rely on the client knowing the proper handshake when connecting to the world and drop those that don't. The correct handshake to use can be a function of the CPU clock-ticks or whatever. The TCP will be minimally used and/or disconnected from that point on. The initial bulk data is a good place to advertise the current server-side software revision so clients that are out-of-date can update. A common pool of UDP ports can be handed out among multiple servers and the clients can be load-balanced into the correct port/server. Within the game, "zone transfers" can mean a literal disconnect from one server/port and reconnection to a different server/port. In MMO's, this usually appears as a <2 second loading screen; enough time to disconnect, reconnect, start getting data, and synchronize to the new server clock, not to mention the actual content loading.
"World server" describes a single, multiple-client, state-pumping thread running on a single core of a single processor of a single blade. One, physical, server-of-worlds can have many worlds running on it at once. Worlds can be dynamically split/merged (in a quad-tree fashion), dividing the clients between them, again, for load-balancing; synchronization between the servers occurs at LAN speeds or better. The world server will probably only serve UDP connections and should have nothing to do except process state-changes to/from the UDP connections. UDP is "blind, deaf, and dumb", so-to-speak. Messages are sent with no flow control, no error checking, etc; they are basically assumed to be received as soon as they are sent and may actually arrive late, in the wrong order, or just never arrive. Using UDP, neither the server nor the client are ever stalled, hand-shaking, error-correcting, or waiting for data. Messages need time-stamps because they may arrive late and/or out-of-order. If a UDP channel gets clogged, switch valid clients dynamically to another (potentially random) port. The world server only initiates UDP connections with successfully authenticated clients and ignores all other traffic (world servers hosted separately from HTTP and everything else).
Overly simplified and, using only the position data as an example, each client tells the server "Time:Client###:(X, Y)" over and over. If the server doesn't hear, oh well. The server says "Time:listOfClients(X, Y)" over and over, to everyone at once. If one or more of the clients doesn't hear, oh well.
This implies using prediction/extrapolation on the client; the clients will need to "guess" what should be happening and then correct themselves to agree with the server when they start getting data again. Any time you get a packet with a "future" time, even if the packet doesn't make sense or isn't useful, you can at least advance the client clock to that point and discard any now-late packets, helping a lagging client to catch up.
Un-verified supposition:
Besides the existing security concerns, I don't see a reason why two or more clients could not maintain independent, but server-managed, UDP channels between each other. By notifying other clients within close game-proximity in addition to the server, the clients, themselves, can help to load-balance. The server should always verify that what the clients say happened could/should/would happen, and has the ability to undo all of it and reset both clients to it's own known-good state. The information that the clients are able to share, internally, should be extremely restricted; basically just the most-time-critical positional and/or state-data. Client's should probably not be allowed to request specific information and, again, rely only on "dumb" broadcasts. This begins to approach distributed/cloud computing, where the clients are actually doing a lot of the server work, while the server just watches and "referees," calling foul, when appropriate.
Client1 - "I fought Client2 and won"
Client2 - "I fought Client1 and won"
Server - "I watched and Client2 cheated. Client1 wins. (Client2 is forced to agree)"
The server doesn't necessarily even need to watch; if Client2 damages Client1 in an unusual/impossible way, Client1 can request arbitration from the server.
Side-effects
If the player moves around, but the data isn't getting to the server, the player experiences "rubber-banding", where the player appears to be moving on the client but, server-side, they are not. When the client gets the next server state, the client snaps the player back to where they were when the server stopped getting updates, creating the rubber-band effect.
This often manifests another way, too. If the server sees a player moving, then fails to receive the "stopped moving" message, the server will predict their continued path for all of the other clients. In MMO-RPG's, for example, you can see "lagging" players running directly into/at walls.
Holes
The last thing I can think of is just basic code security. This is especially important if your game is moddable. Mods are, by definition, a way for users to insert their own code into yours. If you are careless about the amount of "API" access you give away, inevitably, someone WILL feel the need to be malicious. Pay particular attention to string termination/handling if the language you are using requires it. Do not build your game from plain-text ASCII content files. If your game has even one "text box," someone WILL be trying to feed HTML/LUA/etc. code into it.
Lastly, paths should use appropriate system variables whenever possible to avoid platform shenanigans and/or access violations (x86/x64, no savegames in ProgramFiles, etc.)
Currently we are setting up a Bluetooth LE device specification and we are running against the following:
The client doesn't want to pair the device via the settings menu. There is a mobile app which should connect to the peripheral.
Now the following, this is the problem:
When connecting, how do we secure our characteristics? We were thinking about prefixing a write request, but what about read requests?
We don't want everybody to see the not so sensitive data. Since it's not sensitive we don't need high security but we still need to secure it some way just in case.
Does anybody know how to do this? How to secure a characteristic?
Thanks in advance,
You could implement a challenge-response system on connection - when you connect to the peripheral you read a value from a characteristic which is randomised by the peripheral. This value has to be hashed in some way using a shared-secret and then written back to the characteristic. The peripheral then verifies the hashed value. If it matches then it populates the other characteristics and accepts write requests.
Once the central disconnects from the peripheral it ignores write requests and zeros its read characteristics until the next connection/hash handshake.
You must add Security Mode 1 Level 3 to your Services. Then, all the Service's characteristics will be protected.
It doesn't relate specifically to any programming language or technique, but still:
You know how you can use programs like Wireshark to read packets going through your computer (or router, more accurately)? These packets can contain secret information that must be encrypted somehow, like username and password for some systems. But even without this information, one can recreate these packets and obtain the same information, no? For example, I can send these packets from my computer, pretend that I've requested the service and obtain access that way to the given system. How is that prevented?
Also, a kind-of-related question: when a router receives a packet, how does it know to which computer to direct it to if multiple computers are connected to it in an LAN?
What you describe is called a replay-attack - to prevent this sort of attack the respective protocol needs to have some built-in features (like some unique ID per request and becomes invalid after being received the very first time and/or becomes invalid after a certain amount of time and/or some timestamp etc.).