An important part of communicating over the internet is having some security in place. For my own project this will have the server setup so that it only accepts connections from known devices. It will also encrypt data before it is sent and decrypted when the server receives it.
Encryption:
There are many ways to encrypt data:
- Inverting all bits in the data being sent. This was handy in the very old days of 8-bit cpu’s to hide data in memory to stop people spying on code and data in memory.
- Apply a key to the data. A good method of securing data which could be a password protected to unlock on the receiving side. However, it doesn’t take long for key to be found.
- Apply a key and add salt. Skewing the data like in method 2 is good, but when adding salt, it makes it almost impossible to decrypt without having access to the code.
I’ll be using a system which adds a key and pours in some salt. Now how this is done is using a key to skew the data, and then by splitting the bits of the data up randomly and adding random bits in between, the bitstream will be larger but impossible to decrypt. 2 things will be needed to decrypt the data, the code itself and the key.
Security:
Most of the time, security means logging in with a username and password. The final project will require the device to first log in which will have a timeout feature on it. This is just like session handling in GWT for the web. The login data will still be sent encrypted.
Fortunately, I’ve worked with encryption since 8-bit cpu’s, so this shouldn’t pose a problem for me at all. I’ll have some generic classes written that can be used on both client and server for de/encryption. Apart from the usual login credentials, the client and server will have some hardcoded (still encrypted) transport keys, which can be updated when software is updated. The server can also handle software updates which includes data security updates. This will mean that software that isn’t updated will no-longer work unless it gets an update.
Obviously, this means a lot of boilerplate code, but it will be worth it. And hiding it from a web interface by using TCP, it will be more secure.
One last thing to note about security is server/port attacks. On each socket connection, the server will log the number of requests from an IP address. It it gets too many then it will ignore that IP address for 30 minutes or another set time. This will reduce DoS attacks on the servers port/s.
When the application is transferring data back and forth to the server, most of the communication will be done in one connection. Too many connection attempts will simply be denied.
