0

Following situation: a RaspberryPI is in the local network, and has a webserver on it. it contains a local webpage where the user has to log in.

This local Raspberry is connected to a sensor that reads data. Additionally the user can make some changes to the local page's settings.

When done there is a button, the user clicks and the data is transfered from the local PI to the online webserver. Obviously only if he is logged in. (Online and local have the same accounts)

problems:

  • how to update the local username/passwords in a safe way? The local raspberry could be stolen, and that should not put all the user accounts to risk. Ideally the accounts stay stored online only, and when the user logs in locally he actually logs in online and the session is valid remotely and locally.

  • how to send the informations online in a safe way? we are talking of roughly 50 variables to send online.

sharkyenergy
  • 3,842
  • 10
  • 46
  • 97
  • Use SSL, password hashing and encryption. Encrypt the SD, so that it's unreadable if stolen. Use a database on a remote server which the Pi connects to. – soulseekah Dec 09 '13 at 07:34
  • how would i encrypt the SD? would you feel safe that way? – sharkyenergy Dec 09 '13 at 07:50
  • As long as your data is offsite, why not. http://raspberrypi.stackexchange.com/questions/10076/is-there-a-way-to-perform-a-full-system-encryption-of-rasbian and http://raspberrypi.stackexchange.com/questions/1600/how-do-i-encrypt-my-raspberry and others. Alternatively, why not use the Pi as a service, and keep everything on a real server, where the server will query the Pi for the needed data using some API key that both agree upon. – soulseekah Dec 09 '13 at 08:12
  • this sounds interesting.. could you explain it a little bit better? i would have about 30 raspberrys all working the same way. Thanks – sharkyenergy Dec 09 '13 at 08:34
  • Basically, you run a thin server on each Pi which provides sensor data via REST, XML-RPC, 0mq, or even simple ASCII over bare TCP. Your main server (which contains client login logic, the databases, etc.) will query your Pi array over your chosen protocol and get the sensor data. You can generate random "API" keys, to protect external access to the Pi data, which the main server would know. Use SSL or other encryption methods to protect API keys in transmission. Use SD encryption to protect Pi client source code in case of theft. – soulseekah Dec 09 '13 at 08:50
  • The Pi would not have any logic besides providing safe (authorized, encrypted) access to sensor data. You can implement simple logging if you need access logs. Your server would query your Pi by, for example, doing an HTTP request to `host:port/sensor?key=a7j1A8x8`, the Pi would respond with `{"sensor":value}`. Its only task would be to recognize its valid key, and provide a response with the data in an agreed-upon format. Or send TCP packet with key `a7j1A8x8` and read data back (to avoid an HTTP stack). – soulseekah Dec 09 '13 at 08:55
  • thank you will look into this. i will try to expain more or less what i need to do so you tell me if this solution would work: i have a online webpage, each customer (shop) gets a raspberry for each shop-room (ex. audio, shelfs, textiles etc..) the shop owner can login in one of these rasps and change some settings. upon submission i know what shop, what login (one for each employee), what room, what settings and how many items have been read through the sensor. these data is then available online with the same login. would this be possible? – sharkyenergy Dec 09 '13 at 08:58
  • I see what you mean, I thought your Pi devices were mere sensors that provide passive data. If the Pi devices are used actively to submit data to a main server then write a client that simply sends requests to your main server. Use HTTPS for encryption of traffic. The client can be a mere browser with a native client plugin, or a native GUI app (Qt + webkit perhaps, GTK, etc.), which would be simpler. Once the store owner logs in (by sending credentials to your main server and getting a session cookie back), and can then submit settings via the GUI, and sensor data. So the Pi is a mere client. – soulseekah Dec 09 '13 at 09:03
  • There is no need to protect the client (the Pi), it can be stolen and will only disclose the client source code (the submit URLs, variable names, etc.), but it wouldn't contain any passwords or other sensitive data. Encrypt the SD to make the less sensitive data unattainable as well. – soulseekah Dec 09 '13 at 09:05
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/42773/discussion-between-soulseekah-and-sharkyenergy) – soulseekah Dec 09 '13 at 09:05

1 Answers1

1

After a lengthy chat it became clear that the Pi devices would need to be accessed by clients using a smartphone or a web-browser.

Each Pi device would have a set of settings, and be able to read GPIO data. Each device would have to be secure (with authentication and authorization). There are several options to go about this, but using a central relay server offers a lot of advantages.

Basically, a relay server (remote, shared by everyone in the system) would maintain a list of Pi devices along with their UUIDs and owners, employees, permissions. Once booted up the device would make a persistent connection over to the server using TCP, identify itself, and be able to send and receive data (configuration, sensor data). Look into Twisted, 0MQ (zeromq), and other TCP server/client stacks.

Clients would be able to use the relay server by logging in, and reading/writing (depending on permissions) to their Pi devices. Registering devices would be simple, by adding their UUID the relay server knows who it belongs to. Discarding devices due to theft, etc. (by the way, since the Pi will contact the server, if it's reported as stolen, it can relay its IP and other data when it comes online again).

Use properly configured SSL to secure your connections.

Advantages of this approach:

  1. Works without a NAT, no need for unique IPs per device.
  2. Simple UUID-based configuration, without addresses, etc.
  3. Centralized data, secure (if properly configured)

Disadvantages:

  1. Internet connection is a must.
  2. More work required to implement than a simple decentralized stack
Community
  • 1
  • 1
soulseekah
  • 8,770
  • 3
  • 53
  • 58
  • just one quick question.. assume that in 3 jears there are 1000 PI's out there.. does this mean 1000 persistent TCP connections? isnt that a kill for the webserver? – sharkyenergy Dec 09 '13 at 12:13
  • http://stackoverflow.com/questions/651665/how-many-socket-connections-possible, and after that use a load balancer. – soulseekah Dec 09 '13 at 12:48